From: "Shawn O. Pearce" <spearce@spearce.org>
To: Junio C Hamano <junkio@cox.net>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] A new merge stragety 'subtree'.
Date: Sat, 17 Feb 2007 02:14:25 -0500 [thread overview]
Message-ID: <20070217071425.GD27864@spearce.org> (raw)
In-Reply-To: <7vfy95y2n9.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> For normal merge strategies, if you are on branch A and merge
> branch B into it, what you will get is exactly the same as what
> you would get by merging branch A while being on branch A
> (modulo the direction of conflict markers). With the subtree
> merge, it is not the case anymore. If I pull from git-gui.git,
> the resulting tree look like git.git with Shawn's updates. If
> Shawn pulls from git.git, even after I did some changes on my
> own to git-gui subdirectory, bypassing his tree, he will get a
> merged result pertaining to git-gui.git repository
> (i.e. git-gui/ subdirectory of what I have). This way, we can
> continue merging from each other.
>
> Although I do not plan to commit anything in git-gui/ part of my
> tree myself, bypassing Shawn, it is nice to know that it will
> not introduce problems down the road.
This does actually cause a problem if you merge a git.git commit
into git-gui.git (by stripping the git-gui/ part off). The problem
is the entire git.git history would then become the second parent
of the git-gui.git merge commit, and suddenly the git-gui.git
repository increases by >11 MiB in size... ;-)
With regards to maintaining git-gui: I'll apply all patches to my
tree and do testing there, then ask Junio to merge a tagged release
over to git.git for inclusion in the next git release.
To avoid pulling the entire git.git history into git-gui, I'd ask
that anyone bypassing me (e.g. if I'm being horribly unresponsive
one week) checkout the git-gui branch from git.git, apply the
change(s) there, then merge that branch into git.git using the
subtree strategy. This way I can later fast-forward git-gui.git
to the fixed commit, without sucking in more than I bargained for.
For example:
git log -n1 -- git-gui
# copy the second parent...
git checkout -b fixgg <secondparent>
# do fixes...
git checkout master
git merge -s subtree fixgg
Then I can later obtain `fixgg` from the merge commit in git.git
and update git-gui.git, without sucking in git.git's objects.
--
Shawn.
next prev parent reply other threads:[~2007-02-17 7:14 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-17 1:49 [PATCH] A new merge stragety 'subtree' Junio C Hamano
2007-02-17 7:14 ` Shawn O. Pearce [this message]
2007-02-17 8:29 ` Junio C Hamano
2007-02-17 8:53 ` Shawn O. Pearce
2007-02-17 18:02 ` Junio C Hamano
2007-02-17 8:45 ` Shawn O. Pearce
2007-02-17 8:51 ` Junio C Hamano
2007-02-17 9:02 ` Shawn O. Pearce
2007-02-17 18:04 ` Junio C Hamano
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=20070217071425.GD27864@spearce.org \
--to=spearce@spearce.org \
--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.
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.