Junio C Hamano <junkio@xxxxxxx> wrote: > 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. > 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. > 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. ;-) > 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. > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html