linux@xxxxxxxxxxx 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.
-
To unsubscribe from this list: 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