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:
pgpHggQJcaVuX.pgp
Description: PGP signature