From: Christian Couder <chriscool@tuxfamily.org>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Jonathan Nieder <jrnieder@gmail.com>
Subject: Re: What's cooking in git.git (Mar 2010, #01; Wed, 03)
Date: Fri, 5 Mar 2010 18:32:15 +0100 [thread overview]
Message-ID: <201003051832.16001.chriscool@tuxfamily.org> (raw)
In-Reply-To: <7vk4trlhim.fsf@alter.siamese.dyndns.org>
On Friday 05 March 2010 01:49:21 Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
> > $ git branch branch2 <2>
> >
> > I take it that this is supposed to be "checkout -b branch2".
> >
> > $ git reset --keep start <3>
> > ------------
> >
> > <1> This commits your first edits in branch1.
> > <2> This creates branch2, but unfortunately it contains the previous
> > commit that you don't want in this branch.
> > <3> This removes the unwanted previous commit, but this keeps the
> > changes in your working tree.
> >
> > The above sequence is not very convincing. After you edited the second
> > time, you create branch2 and that is presumably because you realized that
> > the change in the work tree belongs to a separate topic. It would be a
> > lot more natural to do this:
> >
> > $ git tag start ;# we do not have to tag, but just to make the
> > remainder of the illustration easier to read...
> > $ git checkout -b branch1
> > $ edit ;# do the work for the first topic
> > $ git commit ;# and commit
> > $ edit ;# start working more and then realize that the
> > change belongs to a separate topic, and the previous
> > commit is unrelated to that new topic
> > $ git checkout -b branch2 start
> > $ edit ;# continue working
> > $ git commit ;# and conclude it
> >
> > so the example makes the use of "reset --keep" look artificial.
>
> Nah, what was I thinking. If I rephrase your side note <2> and <3> a
> little bit, everything makes sense. Perhaps like so:
>
> <2> In the ideal world, you could have realized that the earlier
> commit did not belong to the new topic when you created and switched
> to branch2 (i.e. "git checkout -b branch2 start"), but nobody is
> perfect.
>
> <3> But you can use "reset --keep" to remove the unwanted commit after
> you switched to "branch2".
>
> And it becomes very clear that "reset --keep" is a sensible way to recover
> from this mistake. No need to do "read-tree -m -u" followed by "reset"
> anymore.
>
> Do you think I finally understood what "reset --keep" is about?
Yes I think so. Thanks for that.
I will rework the documentation patch according to your remarks and perhaps
Jonathan Nieder's remarks too.
Thanks both,
Christian.
next prev parent reply other threads:[~2010-03-05 17:33 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-04 0:02 What's cooking in git.git (Mar 2010, #01; Wed, 03) Junio C Hamano
2010-03-04 0:36 ` Adam Simpkins
2010-03-04 8:26 ` Björn Gustavsson
2010-03-04 18:26 ` Junio C Hamano
2010-03-04 12:09 ` Tay Ray Chuan
2010-03-04 18:26 ` Junio C Hamano
2010-03-04 21:42 ` Junio C Hamano
2010-03-05 0:49 ` Junio C Hamano
2010-03-05 16:25 ` git reset --keep (Re: What's cooking in git.git (Mar 2010, #01; Wed, 03)) Jonathan Nieder
2010-03-05 21:08 ` Christian Couder
2010-03-05 17:32 ` Christian Couder [this message]
2010-03-04 22:21 ` What's cooking in git.git (Mar 2010, #01; Wed, 03) Thomas Rast
2010-03-05 1:30 ` Mark Lodato
2010-03-05 1:32 ` Mark Lodato
2010-03-05 3:23 ` Junio C Hamano
2010-03-06 0:39 ` [PATCH] Add tests for git format-patch --to and format.to config option Miklos Vajna
2010-03-06 2:21 ` Junio C Hamano
2010-03-06 21:06 ` [PATCH] format-patch --to: overwrite format.to contents, don't append it Miklos Vajna
2010-03-07 0:06 ` [PATCH] Add tests for git format-patch --to and format.to config option Stephen Boyd
2010-03-07 1:20 ` Miklos Vajna
2010-03-07 3:42 ` Junio C Hamano
2010-03-07 9:43 ` Stephen Boyd
2010-03-07 18:38 ` Junio C Hamano
2010-03-07 21:33 ` [PATCH 0/4] format-patch and send-email ignoring config settings Stephen Boyd
2010-03-07 22:46 ` [PATCHv2 0/3] " Stephen Boyd
2010-03-07 22:46 ` [PATCHv2 1/3] format-patch: use a string_list for headers Stephen Boyd
2010-03-07 22:46 ` [PATCHv2 2/3] format-patch: add --no-cc, --no-to, and --no-add-headers Stephen Boyd
2010-03-07 22:46 ` [PATCHv2 3/3] send-email: add --no-cc, --no-to, and --no-bcc Stephen Boyd
2010-03-09 2:44 ` [PATCH 0/4] format-patch and send-email ignoring config settings Junio C Hamano
2010-03-07 21:33 ` [PATCH 1/4] send-email: actually add bcc headers Stephen Boyd
2010-03-07 21:53 ` Stephen Boyd
2010-03-07 21:33 ` [PATCH 2/4] format-patch: use a string_list for headers Stephen Boyd
2010-03-07 21:44 ` Erik Faye-Lund
2010-03-07 21:54 ` Stephen Boyd
2010-03-07 22:13 ` Johannes Schindelin
2010-03-07 21:33 ` [PATCH 3/4] format-patch: add --no-cc, --no-to, and --no-add-headers Stephen Boyd
2010-03-07 21:33 ` [PATCH 4/4] send-email: add --no-cc, --no-to, and --no-bcc Stephen Boyd
2010-03-10 3:53 ` [PATCH] Add tests for git format-patch --to and format.to config option Steven Drake
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=201003051832.16001.chriscool@tuxfamily.org \
--to=chriscool@tuxfamily.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jrnieder@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).