Junio C Hamano <junkio@xxxxxxx> wrote: > "Shawn O. Pearce" <spearce@xxxxxxxxxxx> 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. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html