Shawn O. Pearce wrote:
> Junio C Hamano <junkio@xxxxxxx> wrote:
>> Andy Whitcroft <apw@xxxxxxxxxxxx> writes:
>>
>>> Special casing the 'current' branch makes any sort of automated push
>>> setup unreliable. Indeed the special case preventing a fetch into the
>>> current branch is pretty annoying for the same reason. I would almost
>>> prefer to relax that than add the same for push.
>> How would you relax the fetch case? Fetching into the current
>> branch, unless the repository is bare, is always a fishy
>> operation.
>
> And so is pushing into the current branch, so long as the current
> branch has a working directory attached to it.
>
> Most new users to Git expect to be able to push into the current
> branch of a repository and `just have it work`. Only they don't
> really seem to have an idea of _how_ that operation should behave,
> which means they really don't want it to work at all. I certainly
> don't want an operation to succeed if I can't reason about what
> its success means!
>
> 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? In my mind thats very similar to creating a
temporary branch for the user before updating the head they were on, but
without having to actually make one.
-apw
-
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