git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Fredrik Kuivinen <freku045@student.liu.se>
To: Junio C Hamano <junkio@cox.net>
Cc: Fredrik Kuivinen <freku045@student.liu.se>,
	Daniel Barkalow <barkalow@iabervon.org>,
	Linus Torvalds <torvalds@osdl.org>,
	cel@citi.umich.edu, git@vger.kernel.org
Subject: Re: [RFH] Merge driver
Date: Tue, 13 Sep 2005 22:33:06 +0200	[thread overview]
Message-ID: <20050913203252.GA1737@c165.ib.student.liu.se> (raw)
In-Reply-To: <7vmzmi9ebj.fsf@assigned-by-dhcp.cox.net>

On Mon, Sep 12, 2005 at 02:16:48PM -0700, Junio C Hamano wrote:
> Fredrik Kuivinen <freku045@student.liu.se> writes:
> 
> > git-read-tree A
> > git-update-cache --refresh
> > git-read-tree -u -m T A B
> >
> > We need the second step because otherwise git-read-tree will complain
> > that the cache isn't uptodate. But we _know_ that the contents are
> > uptodate, so the second step is unnecessary and just eats time.
> 
> If we _know_ it should match, isn't there a way to tell the
> first "git-read-tree A" not to mess with the dirtiness, like,
> ah, one-way merge?
> 

I don't think a one way merge will do what we want in this case.

At the start of the merge we know that the working directory is in
sync with the index. But during the merge we will merge the common
ancestors, and the index file will be overwritten. When we are done
with merging the common ancestors we want to merge the heads that we
wanted to merge from the begining (A and B) using T as the common
ancestor. When 'git-read-tree A' is executed we get a cache which has
zeroed stat data, but SHAs and mode information which match the
working directory. If we do 'git-update-cache --refresh' the stat data
will be updated to match the working directory.

Using 'git-read-tree -m A' will not work because the stat data in the
cache is zeroed before we run this command.

I see two solutions, either allow passing '-i' together with '-u' to
git-read-tree or use a temporary index file when we are merging the
common ancestors.

Thinking a bit more about it, maybe it's better to use a temporary
index file. If go this way we could, at least in principle, allow
merges which starts with a dirty working directory.

- Fredrik

  reply	other threads:[~2005-09-13 20:33 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-07 16:47 [PATCH 0/2] A new merge algorithm, take 3 Fredrik Kuivinen
2005-09-07 16:50 ` [PATCH 1/2] Add '-i' flag to read-tree to make it ignore whats in the working directory Fredrik Kuivinen
2005-09-11  2:54   ` Unified merge driver pushed out to "master" branch Junio C Hamano
2005-09-11 21:05     ` Fredrik Kuivinen
2005-09-12  1:23       ` Junio C Hamano
2005-09-14  5:56     ` Another merge test case from the kernel tree Junio C Hamano
2005-09-14 16:11       ` Daniel Barkalow
2005-09-14 16:30         ` Junio C Hamano
2005-09-14 17:42       ` Fredrik Kuivinen
2005-09-14 17:51         ` Junio C Hamano
2005-09-15  0:47       ` Yet another set of merge test cases " Junio C Hamano
2005-09-19 16:13         ` Fredrik Kuivinen
2005-09-20  1:53           ` Junio C Hamano
2005-09-20  5:50             ` Fredrik Kuivinen
2005-09-07 16:51 ` [PATCH 2/2] A new merge algorithm Fredrik Kuivinen
2005-09-07 18:33 ` [PATCH 0/2] A new merge algorithm, take 3 Daniel Barkalow
2005-09-08  6:06   ` Fredrik Kuivinen
2005-09-08 15:27     ` Daniel Barkalow
2005-09-08 20:05       ` Fredrik Kuivinen
2005-09-08 21:27         ` Daniel Barkalow
2005-09-07 18:36 ` Junio C Hamano
     [not found]   ` <431F34FF.5050301@citi.umich.edu>
     [not found]     ` <7vvf1cz64l.fsf@assigned-by-dhcp.cox.net>
2005-09-08 15:06       ` Chuck Lever
2005-09-08 16:51         ` Junio C Hamano
2005-09-08 17:19           ` Linus Torvalds
2005-09-08 17:51             ` Junio C Hamano
2005-09-08 18:16             ` Chuck Lever
2005-09-08 18:35               ` Linus Torvalds
2005-09-08 18:58                 ` Chuck Lever
2005-09-08 20:59                   ` Linus Torvalds
2005-09-09  7:44                   ` [RFH] Merge driver Junio C Hamano
2005-09-09 16:05                     ` Daniel Barkalow
2005-09-09 16:43                       ` Junio C Hamano
2005-09-09 17:25                         ` Daniel Barkalow
2005-09-11  4:58                     ` Junio C Hamano
2005-09-12 21:08                     ` Fredrik Kuivinen
2005-09-12 21:16                       ` Junio C Hamano
2005-09-13 20:33                         ` Fredrik Kuivinen [this message]
2005-09-13 20:46                           ` Junio C Hamano
2005-09-08 20:54   ` [PATCH 0/2] A new merge algorithm, take 3 Junio C Hamano
2005-09-08 21:23     ` A Large Angry SCM

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=20050913203252.GA1737@c165.ib.student.liu.se \
    --to=freku045@student.liu.se \
    --cc=barkalow@iabervon.org \
    --cc=cel@citi.umich.edu \
    --cc=git@vger.kernel.org \
    --cc=junkio@cox.net \
    --cc=torvalds@osdl.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.
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).