"Shawn O. Pearce" <spearce@xxxxxxxxxxx> writes: > Junio C Hamano <junkio@xxxxxxx> wrote: >> ... >> 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... ;-) Don't worry. I am not asking you to actually perform such a merge and make the relut as a part of _official_ git-gui.git history. > 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. 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. - 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