Re: [PATCH] New git-seek command with documentation and test.

Carl Worth wrote:
> Add git-seek which allows for temporary excursions through the
> revision history. With "git seek <revision>" one gets a working tree
> corresponding to <revision>. When done with the excursion "git seek"
> returns back to the original branch from where the first seek began.
> 

I've said it before, and I'll say it again. This tool provides less 
flexibility and much less power than "git checkout -b branch 
<commit-ish>" (although it would be nice to have '-o' for 'overwrite 
existing branch' as an argument to git checkout)

> Signed-off-by: Carl Worth <cworth@cworth.org>
> 
> ---
>  
>  I had planned to just let this drop as my original need was some
>  historical exploration that I've already finished. But now I've found
>  a common use case in my everyday workflow that could benefit from
>  git-seek. Here it is:
>  
>  I receive a bug-fix patch that updates a test case to demonstrate the
>  bug. I can apply both the fix and the test case and see it succeed.
>  But what I really want to do is first commit the test case, see it
>  fail, and only then commit the fix and see the test now succeed.  I'd
>  also like the history to reflect that order. So what I do is:
>  
>  	$ git-am
>  	$ git update-index test.c ; git commit -m "Update test"
>  	$ git update-index buggy.c ; git commit -m "Fix bug"
>  
>  At that point, without git-seek I can get by with:
>  
>  	$ git checkout -b tmp HEAD^
>  	$ make check # to see failure
>  	$ git checkout <branch_I_was_on_to_begin_with>
>  	$ git branch -d tmp # easy to forget, but breaks the next time otherwise
>  	$ make check # to see success
>  
>  But what I'd really like to do, (and can with the attached patch), is:
>  
>  	$ git seek HEAD^
>  	$ make check # to see failure
>  	$ git seek
>  	$ make check # to see success
>  
>  This avoids me having to:
> 1) invent a throwaway name,

All programmers have at least five throwaway names that are only ever 
used as such (mine are, in order of precedence, foo, bar, tmp, fnurg, 
sdf and asd).

> 2) remember the branch I started on,

With topic branches, you need to pick more careful topic names. Without 
topic branches you're always on "master". Surely you know what the 
patches touch, so you know what branch they should be in.

> 3) remember to actually throwaway the temporary branch.
> 

This isn't always a bad thing, since you after applying some patch or 
other decide you want to go back to this point in history, or want to 
keep the point so you can show the author some problem or other with the 
patch. With git-seek you'll then have to remember the hard-to-learn 
SHA1, or how far below HEAD or some other easily remembered point in 
history it is. In that case, you need to remember to add the 
branch/tag/whatever to where you seeked rather than just go on with the 
work. Removing a branch later is simple. Finding the right spot to 
create it later can be trouble-some.

If I had a vote, I'd say no to this patch, and to this tool entirely.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html