From: Steven Grimm <koreth@midwinter.com>
Date: Mon, 22 Oct 2007 22:53:59 GMT
Subject: Re: Git User's Survey 2007 unfinished summary continued
Message-ID: <471D2A07.7070201@midwinter.com>
In-Reply-To: <Pine.LNX.4.64.0710212308540.25221@racer.site>

Johannes Schindelin wrote:
> I'd really like people to respond not so much with broad and general 
> statements to my mail (those statements tend to be rather useless to find 
> how to make git more suitable to newbies), but rather with concrete top 
> ten lists of what they do daily.
>   

Maybe not top 10 per se, but here are a couple of my common command 
sequences and some comments about how they could maybe be simplified. I 
mostly use git to talk to an svn repo, which in some sense is a corner 
case but which I suspect is both (a) really common already, and (b) 
potentially even *more* common if we can make git an even easier way to 
work with svn repositories.

Pulling updates from svn:

git stash
git svn rebase
git stash apply

A "git svn up" command could do the above automatically (svn users are 
accustomed to doing "svn up" with dirty working copies.)

Committing my work:

git commit -a
(ask someone for a code review, usually involves "git diff" or "git show")
git commit --amend (to indicate in my commit message who did the review)
git svn rebase
git svn dcommit

This isn't too bad as is. I could save myself the "git commit --amend" 
if there were an option to "git svn dcommit" to pop up a commit message 
editor (using the existing text as the default, of course) but it 
doesn't bother me much.

A more extreme possibility which I predict approximately 0 people on 
this list will like: if the working copy is dirty but there is no local 
commit, "git svn dcommit" could pop up an editor for a commit message, 
make a local commit, then send it to svn. That would simplify the 
git-based workflow even further for svn users who don't care about local 
versioning. I'm not sure *I* even like this idea, mind you, but it would 
certainly address the "Why this extra step I don't need in svn?" 
complaint svn users sometimes raise.

Working in a topic branch:

git checkout whateverbranch
git svn rebase
git commit -a   (a bunch of times)
git checkout -b temp trunk
git merge --squash whateverbranch
git commit
(get code review)
git commit --amend
git svn dcommit

This could be shortened a bit with the above idea (edit commit message) 
plus an option to git-svn dcommit to squash everything into one svn commit.

Of course, whether adding more options like that would make things more 
newbie-friendly is a valid question in and of itself; a shorter workflow 
is not necessarily a more discoverable one.

-Steve