All of
 help / color / mirror / Atom feed
From: Junio C Hamano <>
To: Linus Torvalds <>
Subject: Re: The coolest merge EVER!
Date: Thu, 23 Jun 2005 17:44:29 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <> (Linus Torvalds's message of "Wed, 22 Jun 2005 14:46:51 -0700 (PDT)")

>>>>> "LT" == Linus Torvalds <> writes:

LT> Now, the advantage of this kind of merge is that Paul's original gitk
LT> repository is totally unaffected by it, yet because I now have his history
LT> (and the exact same objects), the normal kind of git merge should work
LT> fine for me to continue to import Paul's work - we have the common parent
LT> needed to resolve all differences.

This clearly shows that you are in the "project lead" integrator
mindset.  Making it easy for you, the integrator, to pull
changes made in Paul's tree is what this "coolest merge ever" is
all about, but I suspect there would be a massive additional
support needed if you want to make it easy for Paul to pull
changes made to gitk in your tree.

I am not saying I do not like it, however, to make it easy for
Paul to pull changes made in your tree relevant only to gitk
part, off the top of my head:

 - If a contributor to GIT wants to make a change to gitk that
   adds a new file that is used by gitk (say, some common tcl
   library thing to be included), we either need to feed them to
   Paul and get the changes propagate to you through him, or we
   need a way to mark that file somehow belonging to the
   development history rooted at gitk root, not GIT root.

 - Similarly, if a contributor to GIT wants to make a change to
   gitk file itself, feeding the change through Paul to you
   would lesson both your burden and Paul's.

 - Alternatively Paul can keep track of which files are relevant
   to gitk, slurp and merge commits while ignoring the files the
   gitk package does not care about.  This one would involve
   interesting scripting somebody may want to tackle (hint,

Long time ago I had a discussion with somebody (I vaguely recall
it was with Dan Barkalow but I am not sure) about this exact
issue.  He wanted to have a way to distinguish Cogito-only part
and core GIT part in a Cogito source tree, and help developers
feed core changes to you and Cogito changes to Petr.

Back then I dismissed that approach by saying that what is
broken was Cogito's source tree structure, which overlays two
projects that are theoretically separable and practically
managed separately, and it is not worth supporting such a broken
source tree structure.  Now you are making GIT source tree such
an overlayed one.

  parent reply	other threads:[~2005-06-24  0:41 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-22 21:46 The coolest merge EVER! Linus Torvalds
2005-06-23  0:12 ` Jon Seymour
2005-06-23  0:24   ` Jeff Garzik
2005-06-24  0:44 ` Junio C Hamano [this message]
2005-06-24 11:54   ` Matthias Urlichs
2005-06-24 17:49     ` Daniel Barkalow
2005-06-24 19:22     ` 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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.