Re: Missing features in git

[Junio C Hamano <junkio@cox.net>]

linux@horizon.com writes:

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

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