Re: Missing features in git

From: Junio C Hamano <junkio@cox.net>
Date: Nov 14, 2006, 22:13 UTC
Message-ID: <7vy7qdy8vb.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20061114134958.5326.qmail@science.horizon.com>

linux@horizon.com writes:

Show 5 quoted lines

> One thing I noticed is that with ref logs, you've just re-invented the
> CVS problem of associating history with a name.  If you want to rename
> a branch (say, from "mischacks" to something suitable for publication),
> do you rename the log or not?  It's a less virulent form, but it seems
> like the same disease.

I do not think we currently rename the log but it is probably a bug. Renaming tag should also be made easier.

> Another minor quibble: AFAICT, "git checkout -f -m" is meaningless (-f
> overrides -m), but doesn't complain.

It should be made to complain.

Show 9 quoted lines

> An example of when you'd want to do this is performing a "git bisect"
> with a local "#define DEBUG 1" change.  Particularly if you
> hit a non-compiling version and need to back up.
> or the way git-bisect does it
>   
>         echo "$rev" > "$GIT_DIR/refs/heads/new-bisect"
>         git checkout new-bisect || exit
>         mv "$GIT_DIR/refs/heads/new-bisect" "$GIT_DIR/refs/heads/bisect" &&
>         GIT_DIR="$GIT_DIR" git-symbolic-ref HEAD refs/heads/bisect

The name new-bisect is really temporary the code just shows it punts on a situation it does not expect (it essentially expects a clean tree and working with a local change is by accident) and being ony half helpful to the user while recovering from that unexpected situation. In other words, that's a room for improvement. We should be rewrite the above with something like what we have in the else clause in git-checkout around line 150. It might make sense to make it a shell function and sharable between checkout and bisect (perhaps there are other uses). Then we do not need the temporary branch.

> Either way, it reserves a second branch name, and seems like a bit of
> a hack.

You are correct to call it a hack. git-bisect started as a technology demonstration of the underlying rev-list --bisect feature. The thing is that the technology was so nice and useful that we started using it before cleaning up these implementation details. I think instead of documenting the duct tape that holds git-bisect together ("rev-list --bisect" is great, and what "git-bisect" does is basically great but with minor glitches like you noticed and with hacky implementation details; I am calling the latter "duct tape"), we should redo the hackish part.

Enough with bisect. And jumping the head while forward/back porting the local change would also involve the same kind of change, so "git reset --merge-local-change" might be a good addition, but I am not sure about the details yet.