Junio C Hamano <junkio@cox.net> wrote:
quoted text
> I do not want to think about the consequences of adding more
> cruft under .git/ directory.  For example, should PREV be
> noticed by fsck and prune?  What should various forms of
> 'git-reset' do with it?  How does it interact with 'git-bisect'?

I agree.  The reachability list for those is already starting to
get out of control, and the rules for making sure those files are
always in sync with every command is getting crazy.  Didn't we just
fix `git reset --hard` to throw away .git/MERGE_MSG?  That's been
a longstanding bug right there, and that's something that has been
in the tree for a loooooooong time.
 
quoted text
> Being able to test merge or even make commits without being on a
> branch is vastly useful.  It might or might not lead to anywhere
> even after you make a handful commits -- and I would imagine
> that it would be very handy to be able to be lazy and not having
> to decide if it is worth a new branch.

I agree.  I'm always creating and deleting `foof` because I need
someplace to work real quick.  Being able to work on a detached HEAD
would just slightly streamline the process, especially given that
`git checkout -b a-real-name` is readily available to move that
detached HEAD state into a real branch and continue on with it.
 
quoted text
> If Carl wants to do a patch to teach
> 'git-commit' (and all other things that can create commits) not
> to do things from working in a detached HEAD

My concern here is to hit all of the corner cases.  reset.  bisect.
am.  rebase.  merge.  cherry-pick/revert.  Did I get all of 'em?
I'm not sure actually.  ;-)

quoted text
> It's tempting to forget about this whole "safety" business.
> Because we allow "reset --hard" and other forms of operations
> that can lose history if they were done while on a branch, only
> giving the safety to "git checkout" feels somewhat silly.

But isn't the --hard switch the safety valve here?  And lets not
forget that reflogs are enabled by default now so even a `reset
--hard` on a real branch isn't a total loss (its only a loss for
uncommitted files in the working directory).

But a detached HEAD has no reflog. Which means operations that
update it in a non-fastforward way would orphan work.  A subsequent
gc/prune/repack might destroy it, unless an existing ref contains
that previous commit.

quoted text
> Which makes the "merge-base --check-ancestry" stuff I did last
> night pretty much unnecessary, but that's Ok.  It will find
> other uses.

Pity.  It looked like it was a good change and would be useful here
as a safety valve.  Though based on what you said above I would
think we'd actually want it in both checkout and reset (--soft and
--hard versions).

-- 
Shawn.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html