Johannes Schindelin wrote:
> There are a number of issues why I would like to avoid introducing
> LAST_HEAD:
>
> - it does not work when you are using different Git versions on the same
> repository,
>
> - it does not work when you switched recently,
If you switch once, you'll be able to use the feature one checkout
later than if it was reflog-based.
If you switch a lot, the feature won't be in your git half the time
anyway.
> - you are storing redundant information,
AFAIK it's the first instance of this data in a non-free-form field.
There's also the precedent of ORIG_HEAD.
> - yes, the field is meant for user consumption, but no, it is not
> free-form,
It's a field of almost arbitrary character data, filled by 70% of the
update-ref calls I can find in git.git in a "<tool>: <comment>" format
and by the rest with things such as "initial pull" or
"refs/remotes/git-svn: updating HEAD". (The latter is so informative
that it probably deserves a fix.) How is that not free-form?
> - AFAICT your version could never be convinced to resurrect deleted
> branches, without resorting to reflogs anyway.
Neither can any other use of git-checkout without the user manually
recovering some valid revspec referring to the old branch tip from the
reflog. I wanted to be able to abbreviate the previous branch's name,
and it does just that.
> - the reflog method reflects pretty much exactly how people work around
> the lack of "checkout -" currently, so why not just use the same proven
> approach?
So you can make me fight an uphill battle against your idea how it
should be done.
--
Thomas Rast
trast@{inf,student}.ethz.ch
Attachment:
signature.asc
Description: This is a digitally signed message part.
