Re: Git User's Survey 2007 unfinished summary continued

From: Steven Grimm <koreth@midwinter.com>
Date: Oct 22, 2007, 22:53 UTC
Message-ID: <471D2A07.7070201@midwinter.com>
In-Reply-To: <Pine.LNX.4.64.0710212308540.25221@racer.site>

Johannes Schindelin wrote:

Show 5 quoted lines

> 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