From: Junio C Hamano <gitster@pobox•com>
To: Christian Couder <chriscool@tuxfamily•org>
Cc: git@vger•kernel.org
Subject: Re: What's cooking in git.git (Mar 2010, #01; Wed, 03)
Date: Thu, 04 Mar 2010 16:49:21 -0800 [thread overview]
Message-ID: <7vk4trlhim.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <7vmxynydac.fsf@alter.siamese.dyndns.org> (Junio C. Hamano's message of "Thu\, 04 Mar 2010 13\:42\:19 -0800")
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?
next prev parent reply other threads:[~2010-03-05 1:02 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 [this message]
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 ` What's cooking in git.git (Mar 2010, #01; Wed, 03) Christian Couder
2010-03-04 22:21 ` 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=7vk4trlhim.fsf@alter.siamese.dyndns.org \
--to=gitster@pobox$(echo .)com \
--cc=chriscool@tuxfamily$(echo .)org \
--cc=git@vger$(echo .)kernel.org \
/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