git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: git@vger.kernel.org
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Subject: [PATCH 0/6] Reusing "checkout [-m]" logic for "reset --merge"
Date: Fri,  5 Dec 2008 17:54:09 -0800	[thread overview]
Message-ID: <1228528455-3089-1-git-send-email-gitster@pobox.com> (raw)

"checkout" that switches the branches, and "reset" that updates the HEAD,
have some similarities.  Their major difference is that "checkout" affects
which branch HEAD symref points at, while "reset" affects what commit such
a branch pointed at by the HEAD symref points at.  Interestingly, when
your HEAD is detached, they operate on the same thing.

They both change the commit pointed at by your HEAD from one commit to
another.  And what "checkout" and "reset --merge" do to the index and the
work tree while doing so are exactly the same.  Keep your local changes,
while updating everything else from what is in the current commit to the
one we are switching to.

There is one difference, though.

"reset --merge" does not have an equivalent of "checkout -m" that falls
back to three-way merge to resolve the conflicts at the content level.
This series, which is still a WIP, is an attempt to do so.

There are few things to notice that this series doesn't do:

 - What "reset --hard" and "checkout -f HEAD" do to the index and work
   tree (at least in naive thinking) ought to be the same.  This series
   does not attempt to unify these.

 - "reset --merge" is left as posted by Linus, and it does only "git
   checkout" equivalent, without "-m" (yet).

The latter can be enabled by changing a single line (see comment in
reset_index_file() in [Patch 6/6]), but I haven't done so yet.

While investigating for the former possibility, I noticed one interesting
thing what "checkout -f" does *NOT* do.  Starting with an index with
conflicts, "git checkout -f HEAD" keeps higher stage entries.

For example, you can insert "exit" before the "D/F resolve" test in t1004,
run the test (this leaves a handful higher stages in the index), go to the
trash directory and say "git checkout -f HEAD".

It leaves a single stage #1 entry (subdir/file2).  It probably is a bug in
unpack-trees, but I didn't take a very deep look at it.

Junio C Hamano (6):
  builtin-checkout.c: check error return from read_cache()
  read-cache.c: typofix in comment
  Make reset_tree() in builtin-checkout.c a bit more library-ish
  builtin-checkout.c: refactor merge_working_tree()
  builtin-commit.c: further refactor branch switching
  builtin-reset.c: use reset_index_and_worktree()

 builtin-checkout.c |  193 +++++++++++++++++++++++++++++-----------------------
 builtin-reset.c    |   66 +++++++++++++++++-
 read-cache.c       |    2 +-
 reset.h            |   11 +++
 4 files changed, 183 insertions(+), 89 deletions(-)
 create mode 100644 reset.h

             reply	other threads:[~2008-12-06  1:55 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-06  1:54 Junio C Hamano [this message]
2008-12-06  1:54 ` [PATCH 1/6] builtin-checkout.c: check error return from read_cache() Junio C Hamano
2008-12-06  1:54   ` [PATCH 2/6] read-cache.c: typofix in comment Junio C Hamano
2008-12-06  1:54     ` [PATCH 3/6] Make reset_tree() in builtin-checkout.c a bit more library-ish Junio C Hamano
2008-12-06  1:54       ` [PATCH 4/6] builtin-checkout.c: refactor merge_working_tree() Junio C Hamano
2008-12-06  1:54         ` [PATCH 5/6] builtin-commit.c: further refactor branch switching Junio C Hamano
2008-12-06  1:54           ` [PATCH 6/6] builtin-reset.c: use reset_index_and_worktree() Junio C Hamano
2008-12-06  2:08           ` [PATCH 5/6] builtin-commit.c: further refactor branch switching Linus Torvalds

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=1228528455-3089-1-git-send-email-gitster@pobox.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /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).