Re: [PATCH] checkout: implement "-" shortcut name for last branch

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jan 15, 2009, 18:34 UTC
Message-ID: <alpine.DEB.1.00.0901151922360.3586@pacific.mpi-cbg.de>
In-Reply-To: <200901151805.44747.trast@student.ethz.ch>

Hi,

On Thu, 15 Jan 2009, Thomas Rast wrote:

Show 14 quoted lines

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

Show 8 quoted lines

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

Show 6 quoted lines

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

Show 6 quoted lines

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