Re: Working copy revision and push pain

[Jonathan Watt <jwatt@jwatt.org>]

Elijah Newren wrote:
> On Sun, Mar 23, 2008 at 7:54 AM, Jonathan Watt <jwatt@jwatt.org> wrote:
>> Elijah Newren wrote:
>>  > On Sun, Mar 23, 2008 at 7:19 AM, Jonathan Watt <jwatt@jwatt.org> wrote:
>>  >>  Hi Dscho. I think you've misread my email. (Or not read it. ;-)) I do not expect
>>  >>  git-push to update the working copy of the repository being pushed to. In fact
>>  >>  my complaint would be more that it *does* appear to modify the working copy
>>  >>  (well, not so much modify the working copy as get confused about which revision
>>  >>  the working copy came from) when the working copy came from HEAD.
>>  >
>>  > Ah, I hadn't thought of it that way before.  I think you are
>>  > suggesting that pushing to the active branch of a repository with an
>>  > associated working copy should cause the HEAD to become detached.  Is
>>  > that right?
>>
>>  To be honest, I'm not sure what you mean by "HEAD to become detached". If you
>>  mean that the git-push should, if necessary, stop associating the working copy
>>  with HEAD if it's going to change HEAD, then absolutely. It wasn't the same
>>  solution as I was thinking of (stop associating the working copy with HEAD and
>>  instead associate it with the sha1 HEAD currently points to), but I guess it's
>>  the same result. :-)
> 
> In git, HEAD always refers to the currently active branch...if there
> is one.  (Also note that each branch tracks its most recent commit.)
> If there is no currently active branch because you checked out a tag
> or some arbitrary commit, then HEAD is said to be detached, and HEAD
> will track the particular commit you checked out.  The end result is
> that HEAD is always the most recent commit to which your working copy
> is relative to.  See also
> http://www.kernel.org/pub/software/scm/git/docs/glossary.html

I see. Thanks.

> So, it sounds like we're both saying that in your case, you'd like the
> HEAD become detached and track the sha1 that it previously pointed to
> before your push rather than continuing to track the updated branch.

Yes, indeed. From my novice perspective it seems like that's absolutely what
should happen, since that's where the working copy came from. Certainly I see no
reason for git-push to leave the working copy/revision relationship in a bad state.

Jonathan