From: Junio C Hamano <junkio@cox•net>
To: "J. Bruce Fields" <bfields@fieldses•org>
Cc: Jeff King <peff@peff•net>, git@vger•kernel.org
Subject: Re: [PATCH] Detached HEAD (experimental)
Date: Tue, 09 Jan 2007 14:37:35 -0800 [thread overview]
Message-ID: <7vy7obj07k.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <20070109213117.GB25012@fieldses.org> (J. Bruce Fields's message of "Tue, 9 Jan 2007 16:31:17 -0500")
"J. Bruce Fields" <bfields@fieldses•org> writes:
> On Tue, Jan 09, 2007 at 01:20:27PM -0800, Junio C Hamano wrote:
>> Jeff King <peff@peff•net> writes:
>>
>> > For example, with what's in next now, I can do this:
>> >
>> > git checkout v1.4.0
>> > hack hack hack
>> > git commit -m -a 'some changes which will never be seen again'
>> > git checkout v1.2.0
>> >
>> > I thought the _point_ of the safety valve was not to lose those changes.
>>
>> Fair enough.
>>
>> We could always do the check upon "git checkout" from a detached
>> HEAD state, whether it takes you back on some existing branch or
>> leaves your HEAD still detached.
>
> Stupid question: why can't checkout do something like this?
>
> if we're currently not on a branch, fail if .git/PREV
> doesn't point to the same commit as .git/HEAD.
>
> if we're checking out a non-branch, store its SHA1 into
> .git/PREV.
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'?
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.
But that may be just my imagination; I generally prefer any
feature that allows me to defer decision over something that
makes me decide early. 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, I would probably
not opposed to it too much, but I am fairly certain that I won't
be coding it myself.
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. And
the primary motive for detached HEAD as I understand it is for
sightseeing, and not allowing "reset --hard" to jump around is
just plain silly.
That is, after:
git checkout v1.4.0
you are not on any branch, and we would still allow
git reset --hard v1.2.0
which is exactly the same as:
git checkout v1.2.0
You can still say:
git checkout master
and we do not even check.
Which makes the "merge-base --check-ancestry" stuff I did last
night pretty much unnecessary, but that's Ok. It will find
other uses.
next prev parent reply other threads:[~2007-01-09 22:37 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-02 7:45 [PATCH] Detached HEAD (experimental) Junio C Hamano
2007-01-02 19:59 ` Edgar Toernig
2007-01-02 21:56 ` Carl Worth
2007-01-02 22:18 ` Jakub Narebski
2007-01-03 0:34 ` Carl Worth
2007-01-06 18:58 ` J. Bruce Fields
2007-01-06 20:48 ` Alan Chandler
2007-01-06 22:52 ` J. Bruce Fields
2007-01-02 22:44 ` Junio C Hamano
2007-01-02 23:34 ` Carl Worth
2007-01-03 2:45 ` Junio C Hamano
2007-01-08 11:19 ` Junio C Hamano
2007-01-08 13:17 ` Jeff King
2007-01-09 0:19 ` Junio C Hamano
2007-01-09 0:43 ` Carl Worth
2007-01-09 1:05 ` Junio C Hamano
2007-01-09 1:15 ` Carl Worth
2007-01-09 3:26 ` Shawn O. Pearce
2007-01-09 7:07 ` Junio C Hamano
2007-01-09 10:41 ` [PATCH 0/6] Expose in_merge_bases() via merge-base Junio C Hamano
2007-01-09 8:12 ` [PATCH] Detached HEAD (experimental) Luben Tuikov
2007-01-09 14:21 ` Jeff King
2007-01-09 21:20 ` Junio C Hamano
2007-01-09 21:31 ` J. Bruce Fields
2007-01-09 21:43 ` Carl Worth
2007-01-09 21:53 ` J. Bruce Fields
2007-01-09 23:44 ` Shawn O. Pearce
2007-01-10 0:26 ` Jakub Narebski
2007-01-10 0:34 ` Shawn O. Pearce
2007-01-10 1:03 ` J. Bruce Fields
2007-01-10 1:07 ` Shawn O. Pearce
2007-01-10 1:15 ` Nicolas Pitre
2007-01-10 1:24 ` Junio C Hamano
2007-01-10 1:40 ` Shawn O. Pearce
2007-01-10 1:54 ` Nicolas Pitre
2007-01-10 2:28 ` Shawn O. Pearce
2007-01-10 1:37 ` Jakub Narebski
2007-01-10 9:08 ` Andreas Ericsson
2007-01-10 9:46 ` Junio C Hamano
2007-01-10 16:30 ` Daniel Barkalow
2007-01-11 9:45 ` Andreas Ericsson
2007-01-10 9:40 ` Junio C Hamano
2007-01-09 22:37 ` Junio C Hamano [this message]
2007-01-09 23:39 ` Shawn O. Pearce
2007-01-09 23:46 ` Linus Torvalds
2007-01-10 0:10 ` Junio C Hamano
2007-01-10 0:18 ` Shawn O. Pearce
2007-01-10 0:54 ` Linus Torvalds
2007-01-10 0:51 ` Carl Worth
2007-01-10 8:02 ` Junio C Hamano
2007-01-10 9:04 ` Andy Parkins
2007-01-10 9:05 ` Shawn O. Pearce
2007-01-10 9:33 ` Junio C Hamano
2007-01-10 10:10 ` Andy Parkins
2007-01-10 10:25 ` Shawn O. Pearce
2007-01-10 16:18 ` Junio C Hamano
2007-01-10 14:04 ` Jeff King
2007-01-11 0:34 ` Junio C Hamano
2007-01-11 4:31 ` J. Bruce Fields
2007-01-03 10:46 ` Jeff King
2007-01-03 11:59 ` Jeff King
2007-01-02 23:22 ` [PATCH] git-branch: show detached HEAD Lars Hjemli
2007-01-03 5:18 ` Shawn O. Pearce
2007-01-03 6:53 ` Junio C Hamano
2007-01-03 7:50 ` Lars Hjemli
2007-01-03 7:52 ` Junio C Hamano
2007-01-03 7:05 ` Junio C Hamano
2007-01-03 7:37 ` Lars Hjemli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vy7obj07k.fsf@assigned-by-dhcp.cox.net \
--to=junkio@cox$(echo .)net \
--cc=bfields@fieldses$(echo .)org \
--cc=git@vger$(echo .)kernel.org \
--cc=peff@peff$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox