"George Spelvin" <linux@xxxxxxxxxxx> writes:
> (Prompted by the 1.6.2-rc0 announcement.)
>
> Myself, I always thought the obvious way to handle this problem was to
> detach the HEAD. Is there a reson there's no "detach" option for this?
Let's first think about why pushing into the current branch with the
traditional behaviour is bad.
If you are in control of the remote whose current branch was checked out
when push was made, there are two cases:
(1) You do not know what you are doing. The first time you do "git diff
HEAD", or perhaps "git status", you suddenly see a lot of reverts,
sctach your head and cry for help;
If you set 'detach' option, this clueless user is not helped; he will
happily keep working and would make tons of commits on detached HEAD,
and next time he switches to another branch, will lose all of them.
In a sense, this is a lot worse than the current behaviour, because
you will do a lot more damage than just a single commit that has many
uninteniontal reverts as what currently happens---which can be sorted
out.
(2) You know what you are doing. You'd say:
: detach HEAD at the commit before the push updated the branch
$ git checkout @{1}
$ work work work
$ git commit
to detach the HEAD, finish the work you were doing in the pushed-into
repository and then:
: check out the previous branch (i.e. go back)
$ git checkout @{-1}
: merge the last commit, i.e. the work you done on detached HEAD
$ git merge @{1}
If you allow 'detach' option, then you saved him from typing "git
checkout @{1}". Not a big gain, especially if you compare this with
increased pain you are causing to people in category (1).
The case where the pushed-into repository is not yours was discussed
previously by Jeff King in the second thread below.
Previous discussions.
http://thread.gmane.org/gmane.comp.version-control.git/35770/focus=36291
http://thread.gmane.org/gmane.comp.version-control.git/100339/focus=100731
--
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
