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 13:42:19 -0800 [thread overview]
Message-ID: <7vmxynydac.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <7v7hptt0mr.fsf@alter.siamese.dyndns.org> (Junio C. Hamano's message of "Wed\, 03 Mar 2010 16\:02\:20 -0800")
Junio C Hamano <gitster@pobox•com> writes:
> * cc/reset-keep (2010-01-19) 5 commits
> - reset: disallow using --keep when there are unmerged entries
> - reset: disallow "reset --keep" outside a work tree
> - Documentation: reset: describe new "--keep" option
> - reset: add test cases for "--keep" option
> - reset: add option "--keep" to "git reset"
>
> I am not sure if this series is useful, and even less sure if the
> usefulness of it outweighs the confusion factor.
Regarding this, I've been thinking about how I would explain this new
feature to end users (both new ones and old timers) as a good addition. I
still haven't reached a satisfactory explanation, but here is my "WIP" try
to describe a scenario.
I understand that in essense, "reset --keep" does exactly a "checkout
<commit>" does but without detaching the HEAD. I often deliberately stay
on detached HEAD because I find it highly useful that I can jump around
freely with "checkout <commit>" once the head is detached (I would stay in
a detached HEAD state and keep local changes around). I think there must
be a similar usefulness I can gain by "reset --keep".
But I am not really succeeding to explain that to potential users.
I have built commits A, B and C on my 'topic' branch, and the contents
in the working tree is a checkout of C (which is at the tip of the
branch). I can make a small improvement, and start hacking. And then
I realize that the change I just did, which I haven't committed nor
even added, is an improvement to commit A.
I could do:
$ git checkout topic~2 ;# to detach at A
$ git commit --amend -a ;# to improve on A
$ git rebase --onto HEAD @{1} topic ;# rebase the rest and come back
to fix up A and rebuild B and C on top of it. With "reset --keep",
I could do this instead:
$ last=$(git rev-parse HEAD)
$ git reset --keep topic~2
$ git commit --amend -a
$ git rebase --onto HEAD @{1} @{2} ;# rebase the reset
$ git branch -f topic ;# and come
$ git checkout topic ;# back
The above however is clearly not an improvement.
So far, the _only_ use case I can think of that "reset --keep" may be
superiour than anything existing is this:
I have built commits A, B and C on my 'topic' branch, and the contents
in the working tree is a checkout of C (which is at the tip of the
branch). I can make a small improvement, and start hacking. And then
I realize that the change I just did, which I haven't committed nor
even added, is an improvement to commit A. Also I realize that B and
C are completely bogus, and I want to get rid of them.
I could do:
$ git checkout topic~2 ;# to detach at A
$ git commit --amend -a ;# fix it
$ git branch -f topic ;# the rest I do not need
$ git checkout topic ;# and now on the branch
but it would be far easier if I can do this:
$ git reset --keep topic~2
$ git commit --amend -a
You have some addition in Documentation/git-reset.txt in this topic, and
the last example (starting at around line 350) may be describing this
situation, but it was not very clear to me.
Keep changes in working tree while discarding some previous commits::
Suppose you are working on something and you commit it, and then you
continue working a bit more, but now you think that what you have in
your working tree should be in another branch that has nothing to do
with what you commited previously. You can start a new branch and
reset it while keeping the changes in your work tree.
------------
$ git tag start
$ git branch branch1
I take it that this is supposed to be "checkout -b branch1".
$ edit
$ git commit ... <1>
$ edit
$ 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.
next prev parent reply other threads:[~2010-03-04 22: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 [this message]
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 ` 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=7vmxynydac.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