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

Hi,

On Thu, 15 Jan 2009, Thomas Rast wrote:

Johannes Schindelin wrote:

quoted

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

quoted

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

quoted

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

quoted

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

quoted

- 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