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@xxxxxxxxxx>
---
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@xxxxxx
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
-
: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html