On Mon, Aug 2, 2010 at 12:41 PM, Santi Béjar <santi@xxxxxxxxxxx> wrote: > On Mon, Aug 2, 2010 at 4:54 AM, Avery Pennarun <apenwarr@xxxxxxxxx> wrote: >> On Sun, Aug 1, 2010 at 5:25 AM, Santi Béjar <santi@xxxxxxxxxxx> wrote: >>> Add prune mode (flag --prune) with the following properties: >>> >>> * The history must be as clean as possible >>> * The directory content must be equal to the external module, >>> at least when you add/update it[b] >>> * The subproject should be able to switch back and forth between >>> different versions. >>> >>> [b] A consequence of this is that it loses all changes >>> made in the subtree. If they are important you have to extract >>> them, apply them and add the subproject back. >> >> I think I started to reply to this before but I can't quite remember >> what happened. Anyway, I have several concerns with this patch: >> >> - calling it "prune" is pretty incorrect. It doesn't remove anything >> from your history. > > It removes the history of the subproject. > And --squash does not squash your history. We are talking about the > subproject, not the superproject. > >> It silently loses patches from your tree, but >> that's not "pruning" really. I suggest "--squash >> --discard-local-changes" or something. ie. it's a variant of squash, >> and it throws things away. We want both of those to be clear. > > It's not a variant of squash, it is completely different, but it > shares some properties. One tries to keep your local changes, the > other no. I just wanted to add one thing. For me "--squash --discard-local-changes" would be something like --squash but with "git merge -s theirs", so totally different from the --prune mode. I cannot be a flag to --squash. I'm open to discuss the name of the flag, but for now I found --prune the best one. And as it is only used with "git subtree add" I don't think it should be about "discard local changes". Have fun, Santi -- 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