Auto detaching head options (update) (Re: Working copy revision and push pain)

[Jan Hudec <bulb@ucw.cz>]

Hello All,

Since the original proposal is not quoted here, I should repeat it:
On Tue, Mar 25, Jan Hudec wrote:
>     Also I believe that it would be very useful to have a ref defined "the
>     revision your work tree is derived from", be it HEAD or not. It would:
>      - make the behaviour of push to non-bare repository defined.
>      - make additional work trees for a repository (created by
>        contrib/workdir/git-new-workdir) safe (the mechanizm could than be an
>        option for submodules).

First of all, I should apologise for proposing to introduce something that
already exists. It's been resting in the reflog all the time.

Excluding push to non-bare repository and extra work trees, the local
branches are only ever updated through the HEAD. And as long as they are
updated with update-ref, it writes the value to the reflog, so HEAD^{0}
should always equal HEAD.

Therefore the option to prevent users shooting themselves in the foot when
using multiple worktrees for the same repository (the more useful case) or
pushing to a non-bare repo (which is usually just shooting oneselves in the
feet because of lack of knowledge) would be to introduce an option to commit
to verify, that rev-parse HEAD and rev-parse HEAD^{0} give the same revision.

That would have only one casuality -- currently to create a new parentless
commit in non-new repository, one has to modify the HEAD manually. But that
just needs a command-line override to disable the check for cases when one
knows what he's doing.

On Wed, Mar 26, 2008 at 11:49:44 -0700, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
> > FWIW, I also initially thought this was only a "HEAD" problem, but I
> > think Junio's recent argument makes a lot of sense: the problem is not
> > one of working tree and HEAD sync, nor even of detached versus ref HEAD.
> > The problem is that somebody is using the non-bare repository to do
> > stuff (why else would it be non-bare), and you are changing the state
> > behind their back.
> 
> For people who are overwhelmed by the volume of the list traffic, the
> relevant thread is:
> 
>   http://thread.gmane.org/gmane.comp.version-control.git/77955/focus=78062

Thanks for the pointer.

There are actually two use-cases for this. One is this pushing to non-bare
repo, which is indeed just shooting oneself in the foot out of lack of
knowledge most of the time. Though it would still be nice to ask user "do you
really want to shoot yourself in the foot?" if we can find out.

But the other usecase is using additional work trees
(contrib/workdir/git-new-workdir), which is rather useful for many people.
There it again does not make sense to commit to the same branch from two
work-trees, but it may easily happen by accident. Being able to check and
prevent such accidents would improve support for extra work-trees a lot,
maybe even to a point it could be made official.

> > Isn't this essentially the 'base' index extension that Junio did a
> > while back? It was eventually reverted (or perhaps never merged, I don't
> > recall).
> 
> It was in 'next' for a while but was reverted before it hit 'master':
> 
>   http://thread.gmane.org/gmane.comp.version-control.git/44360/focus=44508

Again, thanks for the pointer.

> > But maybe you are referencing it here:
> >
> >>    It would really be similar to the revision number in index proposal,
> >>    except less invasive and I actually believe there is a case (some form of
> >>    checkout or reset), where we want to read-tree, but not change this ref.
> >
> > I don't recall the reasons the base extension was not accepted, but I
> > think it would make sense to frame your argument as "this is like X;
> > people didn't like X for reason Y, but my proposal fixes this by..."
> 
> But if you take the position "work tree belongs to the repository owner
> and nobody has any business pushing into it sideways; push into acceptance
> branch and let the work tree owner merge it when able", the history of the
> failed index base experiment becomes irrelevant.

Ok. This proposal is indeed similar to the base-in-index one, but has some
significant differences. See below.

Besides whith the update above, I no longer propose to keep any new
information -- just to add a safety-check.

On 2007-04-15 19:56:55 GMT, Junio C Hamano wrote:
> [...]
> This is primarily because updating the branch tip is not tied
> closely to writing out a commit, and writing out a commit is not
> tied closely to writing out a tree (to be contained in that
> commit) out of the index.
> [...]

This is a big difference between the base-in-index and
base-somewhere-separately. The reflog is indeed tied to updating of the
branch tip, which is what we need here. It also does not add any new logic to
the low-level plumbing (read-tree, write-tree), that the base-in-index
proposal did.

For the BASE ref proposal, it would be equally tied to update of the branch
tip, except that all porcelain that does it would have to be changed, while
the reflog it already updates.

-- 
						 Jan 'Bulb' Hudec <bulb@ucw.cz>