Re: [PATCH] A new merge stragety 'subtree'.

From: Shawn O. Pearce <spearce@spearce.org>
Date: Feb 17, 2007, 08:53 UTC
Message-ID: <20070217085305.GF27864@spearce.org>
In-Reply-To: <7vzm7duqzf.fsf@assigned-by-dhcp.cox.net>

Junio C Hamano <junkio@cox.net> wrote:

Show 16 quoted lines

> "Shawn O. Pearce" <spearce@spearce.org> writes:
> > 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.
> 
> Actually, I do not think you even need to ask them to do that.
> I am not planning to apply patches to git.git that touch
> git-gui/ subdirectory myself, but if you see such a patch on the
> list, you could first apply it to your copy of git.git
> repository, and run your private edition of cherry-pick that
> uses merge-subtree instead of merge-recursive to pick it out
> onto your 'master' branch of git-gui.git repository.  That way,
> the next time I'll pull from your git-gui.git repository, I will
> get the change through you.

Or... I/we implement -p2 in git-am. Then I can apply it right to my git-gui repository. :-)

Wait, isn't there a patch floating around for that? Wasn't it sent in by Andy Parkins just before 1.5.0?

Just for the record: I am perfectly happy taking patches for git-gui
that were made against the git.git repository.  Obviously I can
easily apply it onto git-gui.git by stripping the path.  I'm also
happy directly pulling worthwhile commits, but I won't pull something
that is based on a git.git commit, for the reason stated above.

> And the procedure would actually work _even_ _if_ (repeat, I do
> not plan to do this) I applied such a patch to my tree before I
> pull from you --- it will just result in an accidental clean
> merge.

Yes, of course.  One of the insanely nice things about git. :)

-- 
Shawn.