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

[Carl Worth <cworth@cworth.org>]

[-- Attachment #1: Type: text/plain, Size: 3134 bytes --]

On Fri, 24 Feb 2006 11:00:29 +0100, Andreas Ericsson wrote:
> 
> 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>"

Yes, that's by design. It's not intended to be a replacement for git
checkout -b. It's intended to be easier to use than that when its
purpose fits what you want to 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).

Sure, and when I use "git checkout -b" I have to keep trying these
linearly until I found one that is available. That's what I've been
doing, and it's painful enough that I wrote this. (Though yes,
something like checkout -o would help here).

> > 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.

I almost put "remember" in quotation marks. Obviously I know what I'm
working on. It's more a matter of just having to type the name, (I do
use very careful topic names so they tend to be longish). Having
tab-completion for git-checkout would help here.

So (1) and (2) have potential workarounds, but neither exists, and
even then they would still be harder to use than git-seek.

> > 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,

That assumes that I've made any change though. If you're going back in
the past to make changes, then "git checkout -b" is the right thing to
use. It's when you're not planning to make changes, but just exploring
the past that "git seek" is helpful.

So (3) is just extra pain when using git-seek for what its designed to
be good for, (exploring history when not planning on writing to it).

But note that the git-seek I've implemented *does* provide a writable
branch, so if you discover that you do want to commit something, then
that's always available. Linus gave compelling arguments for this.

>                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.

Yes. And that's why git-seek stops and warns you before it leaves
dangling commits by moving the branch. (Though it might make sense to
add a -f option to force it to seek regardless of the things it
currently balks at.)

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

One argument in favor is that seeking already exists in git privately
within git-bisect. Exposing git-seek makes it easier to code new
operations along the lines of git-bisect. It's certainly consistent
with git's current implementation strategy to have the more primitive
pieces of complex operations exported and available.

-Carl

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]