All of lore.kernel.org
 help / color / mirror / Atom feed
* The coolest merge EVER!
@ 2005-06-22 21:46 Linus Torvalds
  2005-06-23  0:12 ` Jon Seymour
  2005-06-24  0:44 ` Junio C Hamano
  0 siblings, 2 replies; 7+ messages in thread
From: Linus Torvalds @ 2005-06-22 21:46 UTC (permalink / raw)
  To: Git Mailing List


Ok, Junio had some cool octopus merges, but I just one-upped him.

I just merged the "gitk" repository into git, and I did it as a real git
merge, which means that I actually retained all the original gitk
repository information intact. IOW, it's not a "import the data" thing,
it's literally a merge of the two trees, and the result has two roots.

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

Now, I don't know how often this ends up being actually used in practice, 
but at least in theory this is a totally generic thing, where you create a 
"union" of two git trees. I did the union merge manually, but in theory it 
should be easy to automate, with simply something like

	git fetch <project-to-union-merge>
	GIT_INDEX_FILE=.git/tmp-index git-read-tree FETCH_HEAD
	GIT_INDEX_FILE=.git/tmp-index git-checkout-cache -a -u
	git-update-cache --add -- (GIT_INDEX_FILE=.git/tmp-index git-ls-files)
	cp .git/FETCH_HEAD .git/MERGE_HEAD
	git commit

(this is not exactly how I did it, but that's just because I'd never done
this before so I didn't think it through and I had some stupid extra steps
in between that were unnecessary).

Of course, in order for the union merge to work, the namespaces have to be
fit on top of each other with no clashes, otherwise future merges will be 
quite painful. In the case of gitk, Paul's repository only tracked that 
single file, so that wasn't a problem.

Anyway, you shouldn't notice anything new, except for the fact that "gitk" 
now gets automatically included with the base git distribution. And the 
git repository has two roots, but hey, git itself doesn't care.

			Linus

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: The coolest merge EVER!
  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
  1 sibling, 1 reply; 7+ messages in thread
From: Jon Seymour @ 2005-06-23  0:12 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Git Mailing List

On 6/23/05, Linus Torvalds <torvalds@osdl.org> wrote:
> 
> Ok, Junio had some cool octopus merges, but I just one-upped him.
> 
> I just merged the "gitk" repository into git, and I did it as a real git
> merge, which means that I actually retained all the original gitk
> repository information intact. IOW, it's not a "import the data" thing,
> it's literally a merge of the two trees, and the result has two roots.
> 
> Now, the advantage of this kind of merge is that Paul's original gitk
> repository is totally unaffected by it, yet because I now have his history
> (and the exact same objects), the normal kind of git merge should work
> fine for me to continue to import Paul's work - we have the common parent
> needed to resolve all differences.
> 

You do realise what this means, don't you?

The Borg can now start accumulating software into one massive
repository of everything ever written and it will never forget -
resistance will be futile.

Of course, it may run out of disk space.

jon.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: The coolest merge EVER!
  2005-06-23  0:12 ` Jon Seymour
@ 2005-06-23  0:24   ` Jeff Garzik
  0 siblings, 0 replies; 7+ messages in thread
From: Jeff Garzik @ 2005-06-23  0:24 UTC (permalink / raw)
  To: jon; +Cc: Linus Torvalds, Git Mailing List

Jon Seymour wrote:
> You do realise what this means, don't you?
> 
> The Borg can now start accumulating software into one massive
> repository of everything ever written and it will never forget -
> resistance will be futile.
> 
> Of course, it may run out of disk space.


The kernel.org robots will melt before that happens :)

git has already increased the kernel.org file publish time over an hour. 
  Hopefully inotify and an improved rsync will fix some of that.

	Jeff



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: The coolest merge EVER!
  2005-06-22 21:46 The coolest merge EVER! Linus Torvalds
  2005-06-23  0:12 ` Jon Seymour
@ 2005-06-24  0:44 ` Junio C Hamano
  2005-06-24 11:54   ` Matthias Urlichs
  1 sibling, 1 reply; 7+ messages in thread
From: Junio C Hamano @ 2005-06-24  0:44 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: git

>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> 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,
   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.


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: The coolest merge EVER!
  2005-06-24  0:44 ` Junio C Hamano
@ 2005-06-24 11:54   ` Matthias Urlichs
  2005-06-24 17:49     ` Daniel Barkalow
  2005-06-24 19:22     ` Linus Torvalds
  0 siblings, 2 replies; 7+ messages in thread
From: Matthias Urlichs @ 2005-06-24 11:54 UTC (permalink / raw)
  To: git

Hi, Junio C Hamano wrote:

> 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 don't think that's possible; after all, the trees are now merged, so any
pull would fetch all of Linus' tree.

Paul could do it as patches, or Linus could do it in a branch, or we could
write something entirely different from git that happens to support
cherrypicking. ;-)

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
What's so funny 'bout peace, love, and understanding?



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: The coolest merge EVER!
  2005-06-24 11:54   ` Matthias Urlichs
@ 2005-06-24 17:49     ` Daniel Barkalow
  2005-06-24 19:22     ` Linus Torvalds
  1 sibling, 0 replies; 7+ messages in thread
From: Daniel Barkalow @ 2005-06-24 17:49 UTC (permalink / raw)
  To: Matthias Urlichs; +Cc: git

On Fri, 24 Jun 2005, Matthias Urlichs wrote:

> Hi, Junio C Hamano wrote:
> 
> > 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 don't think that's possible; after all, the trees are now merged, so any
> pull would fetch all of Linus' tree.

Linus could do:

 git-read-tree gitk-head
 git-update-cache gitk
 git-commit-tree `write-tree` -p gitk-head > gitk-patched-head
 git-read-tree HEAD
 git merge gitk-patched-head

(or, better, use a separate index file for the gitk index)

(to commit changes to the gitk script made in a git working directory)

The change I proposed earlier would be so that the system would know what
was going on and users wouldn't have to. Then someone who didn't know that
gitk was (also) a separate project and just committed changes to it would
still generate gitk commits when appropriate.

	-Daniel
*This .sig left intentionally blank*


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: The coolest merge EVER!
  2005-06-24 11:54   ` Matthias Urlichs
  2005-06-24 17:49     ` Daniel Barkalow
@ 2005-06-24 19:22     ` Linus Torvalds
  1 sibling, 0 replies; 7+ messages in thread
From: Linus Torvalds @ 2005-06-24 19:22 UTC (permalink / raw)
  To: Matthias Urlichs; +Cc: git



On Fri, 24 Jun 2005, Matthias Urlichs wrote:

> Hi, Junio C Hamano wrote:
> 
> > 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 don't think that's possible; after all, the trees are now merged, so any
> pull would fetch all of Linus' tree.

No no. 

A merge is a one-way thing. I merged Paul's tree, but Paul didn't merge 
mine. His is still independent, and you can still pull his tree without 
getting the rest of git, and Paul can still continue to work on his tree 
as if I never merged it at all.

Now, merging back isn't as easy: if any gitk changes get done in my 
"union" tree, Paul can't just pull those, becasue they now end up being 
linked to the history of the unified thing, so when pulling, he'd now end 
up getting all of the regular git stuff too.

Which is probably acceptable, but Junio's point was that this is not a 
symmetric setup: git is like a black hole that never lets any information 
escape, and once you've been sucked into a git archive, you end up not 
being able to separate it.

Or rather, you _can_ separate out pieces of it, but now it's a matter of
cherry-picking, not automatic merges. Of course, people want to be able to 
do that anyway, and normally that will also merge back perfectly, so 
there's no huge downside, except that we should make it fairly easy.

		Linus

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2005-06-24 19:19 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
2005-06-24 11:54   ` Matthias Urlichs
2005-06-24 17:49     ` Daniel Barkalow
2005-06-24 19:22     ` Linus Torvalds

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.