Hi,
On Thu, 15 Jan 2009, Thomas Rast wrote:
> 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.
But once it is, you could also have something like "git checkout -{5}"
meaning the 5th last branch you were on.
No, I am not married to that syntax
> > - 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.
See below.
> > - 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?
That is not free-form, as the "<tool>:" is a hard convention all obey
(and therefore, git checkout - only relies on _checkout_ not changing the
format), and checkout is sufficiently plumbing that we will not change it
all that lightly, certainly not when "git checkout -" depends on it.
So I think that those free-form concerns are totally unfounded.
Oh, and before you say that people could mess with GIT_REFLOG_ACTION, git
checkout is no longer a script, and creates the message itself. So we
have full control over it.
They could edit the logs directly, but that applies to virtually the whole
repository, and can safely be ignored as a lemming behavior.
> > - 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.
To the contrary. The reflog has this information together with the
message "moved from ...".
> > - 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.
If you can convince me that there are benefits from introducing yet
another file in $GIT_DIR and duplicating information that is in the
reflogs already, then no, it's not an uphill battle.
I mean, I _like_ the feature. Otherwise I would not spend so much time
suggesting what I think would be a method more in line with what we have
already.
Ciao,
Dscho
--
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
