Re: pushing changes to a remote branch

From: Jeff King <peff@peff.net>
Date: Jul 10, 2007, 22:04 UTC
Message-ID: <20070710220458.GA2295@coredump.intra.peff.net>
In-Reply-To: <844FC382-DFB3-4762-93C2-6512612136AC@silverinsanity.com>

On Tue, Jul 10, 2007 at 02:10:01PM -0400, Brian Gernhardt wrote:

> Perhaps git-commit should also also output a warning?  "Commit made on 
> detached HEAD.  Use "git branch <new_branch_name>" to save your commit"?  
> That's bad wording, but the idea is there.

There was much discussion in this area, and the conclusion (and current behavior) is:

1. Notify about the state change to detached HEAD, since some commands
   will be subtly different.
2. Don't warn about commiting on detached HEAD, since there is nothing
   technically wrong with it.
3. When moving away from detached HEAD, print the previous HEAD
   position, so the user knows what might have been lost.

See this message (and a bunch of surrounding messages):

  http://article.gmane.org/gmane.comp.version-control.git/38254

It would be nice if we could allow (3) only when commits weren't being lost, but that would require doing a reachability analysis from all refs, which is expensive. The reflog for HEAD makes those commits recoverable, as well.

Personally, I think (2) (commits on detached HEAD) should simply be disallowed, since it is simple enough to 'git checkout -b newbranch' as an override (and I have not personally found a need for commits on detached HEAD, anyway), and it saves the exact newbie error that Martin ran into. But others obviously disagree.

-Peff