Andy Whitcroft <apw@xxxxxxxxxxxx> writes:
>> Right now pushing into the current branch makes the index become
>> way out of sync from HEAD. This causes git-runstatus to display a
>> large number of differences, basically undoing any of the changes
>> introduced by HEAD@{1}..HEAD. The user is left with a dirty
>> working tree that they can commit - and committing it will just
>> revert the prior commits. The user will later cuss at Git for
>> losing their changes. Not pretty.
>
> Ok, both seem to be bad. Can I re-ask if this would be solved by having
> the 'dangling head' support we talked about. Such that pulling into or
> pushing into the current head could break the link and make the current
> head a dangling head?
Push does not do any working tree operation, so you _could_
detach the HEAD to point at the commit that used to be at the
tip of the branch and advance the tip of the branch as the push
instructs. The user could start a new branch out of the
detached HEAD (which is behind the tip of the original branch),
make necessary commits and then merge that branch locally to the
branch the push advanced if s/he wants to.
However, I am not sure if that is easy to understand for the
users. It would be sane to deny pushing into the current branch
for a non-bare repositories by default, and if we do allow it
(perhaps with 'git-push --force'), then detach the HEAD as you
suggest. On the other hand, pushing into the current branch of
a bare repository should just work; the HEAD pointer in a bare
repository is not about the commit the index and the working
tree are based on, but which branch is the primary branch of the
repository.
I haven't thought things through, but I think the fetch side
could be handled in a similar way.
-
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