From: linux@horizon.com
To: git@vger.kernel.org
Cc: junkio@cox.net, linux@horizon.com
Subject: More merge questions
Date: 30 Nov 2005 08:10:45 -0500 [thread overview]
Message-ID: <20051130131045.28149.qmail@science.horizon.com> (raw)
In-Reply-To: <7vwtiqzljr.fsf@assigned-by-dhcp.cox.net>
I'm working my way through a thorough understanding of merging.
First I got git-read-tree's 3-way merge down to 6 conditionals, where
a missing entry is considered equal to a missing entry, and a missing
index entry is considered clean.
a) If stage2 == stage3, use stage2
b) If stage1 == stage3, use stage2
c) If the index entry exists and is dirty (working dir changes), FAIL
d) If stage1 == stage2, use stage3
e) If trivial-only, FAIL
f) Return unmerged result for 3-way resolution by git-merge-index.
Case c is needed so you don't change the world out from under
your working directory changes. You could move it earlier and
make things strictire, but that's the minimal restriction.
Then I started thinking about 2-way merge, and how that differed
from a 3-way merge where stage2 was the previous index contents.
If you apply the same rules (with trivial-only true), the only differences
to the big 22-case table in the git-read-tree docs are:
3) This says that if stage1 and state3 exist, use stage3.
3-way says if they're equal, delete the file, while if they're
unequal, it's fail.
If 3-way git-merge-index were allowed, then the conditions that would
change to do it are cases 8 and 12.
The full list of cases and the conditional that applies, is:
0) a
1) d
2) a
3) see above. It's b or e by my logic, but d by the table.
4) b
5) b
6) a
7) a
8) e
9) c
10) d
11) c
12) e
13) c
14) a or b
15) a or b
16) e
17) c
18) a
19) a
20) d
21) c
Given that it all matches up so nicely, I'd like to honestly ask if
case 3 of the conditions is correct. I'd think that if I deleted
a file form te index, and the file wasn't changed on the head I'm
tracking, the right resolution is to keep it deleted. Why override
my deletion?
Sorry if this is a dumb question, but it's not obvious to me.
next prev parent reply other threads:[~2005-11-30 13:10 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-28 23:42 git-name-rev off-by-one bug linux
2005-11-29 5:54 ` Junio C Hamano
2005-11-29 8:05 ` linux
2005-11-29 9:29 ` Junio C Hamano
2005-11-30 8:37 ` Junio C Hamano
2005-11-29 10:31 ` Petr Baudis
2005-11-29 18:46 ` Junio C Hamano
2005-12-04 21:34 ` Petr Baudis
2005-12-08 6:34 ` as promised, docs: git for the confused linux
2005-12-08 21:53 ` Junio C Hamano
2005-12-08 22:02 ` H. Peter Anvin
2005-12-09 0:47 ` Alan Chandler
2005-12-09 1:45 ` Petr Baudis
2005-12-09 1:19 ` Josef Weidendorfer
2005-11-29 21:40 ` git-name-rev off-by-one bug linux
2005-11-29 23:14 ` Junio C Hamano
2005-11-30 0:15 ` linux
2005-11-30 0:53 ` Junio C Hamano
2005-11-30 1:27 ` Junio C Hamano
2005-11-30 1:51 ` Linus Torvalds
2005-11-30 2:06 ` Junio C Hamano
2005-11-30 2:33 ` Junio C Hamano
2005-11-30 3:12 ` Linus Torvalds
2005-11-30 5:06 ` Linus Torvalds
2005-11-30 5:51 ` Junio C Hamano
2005-11-30 6:11 ` Junio C Hamano
2005-11-30 16:13 ` Linus Torvalds
2005-11-30 16:08 ` Linus Torvalds
2005-12-02 8:25 ` Junio C Hamano
2005-12-02 9:14 ` [PATCH] merge-one-file: make sure we create the merged file Junio C Hamano
2005-12-02 9:15 ` [PATCH] merge-one-file: make sure we do not mismerge symbolic links Junio C Hamano
2005-12-02 9:16 ` [PATCH] git-merge documentation: conflicting merge leaves higher stages in index Junio C Hamano
2005-11-30 6:09 ` git-name-rev off-by-one bug linux
2005-11-30 6:39 ` Junio C Hamano
2005-11-30 13:10 ` linux [this message]
2005-11-30 18:37 ` More merge questions Daniel Barkalow
2005-11-30 20:23 ` Junio C Hamano
2005-12-02 9:19 ` More merge questions (why doesn't this work?) linux
2005-12-02 10:12 ` Junio C Hamano
2005-12-02 13:09 ` Sven Verdoolaege
2005-12-02 20:32 ` Junio C Hamano
2005-12-05 15:01 ` Sven Verdoolaege
2005-12-02 11:37 ` linux
2005-12-02 20:31 ` Junio C Hamano
2005-12-02 21:32 ` linux
2005-12-02 22:00 ` Junio C Hamano
2005-12-02 22:12 ` Linus Torvalds
2005-12-02 23:14 ` linux
2005-12-02 21:56 ` More merge questions linux
2005-11-30 16:12 ` git-name-rev off-by-one bug Linus Torvalds
2005-11-30 7:18 ` Junio C Hamano
2005-11-30 9:05 ` Junio C Hamano
2005-11-30 9:42 ` Junio C Hamano
2005-11-30 3:15 ` linux
2005-11-30 18:11 ` Daniel Barkalow
2005-11-30 17:46 ` Daniel Barkalow
2005-11-30 20:05 ` Junio C Hamano
2005-11-30 21:06 ` Daniel Barkalow
2005-11-30 22:00 ` Junio C Hamano
2005-11-30 23:12 ` Daniel Barkalow
2005-12-01 7:46 ` Junio C Hamano
2005-12-01 10:14 ` Junio C Hamano
2005-12-01 21:50 ` Petr Baudis
2005-12-01 21:53 ` Randal L. Schwartz
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20051130131045.28149.qmail@science.horizon.com \
--to=linux@horizon.com \
--cc=git@vger.kernel.org \
--cc=junkio@cox.net \
/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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).