Hi Matthew, > Clarification: The current documentation (correctly) doesn't > actually claim to support "split --squash", but it does erroneously > claim to support "push --squash ».
Yes indeed. ;) > It looks like your patch is basically squashing the new subtree commits > together, throwing out those commits completely, and only keeping > the squashed commit in the split —branch. Exactly. > 3. (new/better) Use "split --rejoin --squash" (or some other > invocation to be defined). The subtree branch is generated > exactly like normal, including fine-grained history. But > instead of merging the subtree branch directly, --rejoin > will squash all the changes to that branch, and merge in > just the squash (referencing the unsquashed split > branch tip in the commit message, but not the > parent). Subsequent splits can run very fast, while the > "--rejoin" only generated two commits instead of the > potentially thousands of (mostly) duplicates it would pull > in without the "--squash ». Isn’t this similar to "my" way? I mean I too generate the fine-grained history and make a squash afterwards, no? I also don’t get why would your solution generate any duplicates. Would mine generate some? I suppose the two answers are linked. > I have this third option half-coded already, but I still need > to finish it. I’m eager to test it! > Does anyone have any suggestions about the UI? Do we need to also > support Pierre Penninckx's "split --squash" semantics somehow? If > so, what command line options would allow for distinguishing the > two cases? Maybe `split --rejoin-squash` since it’s really a third way? I intended to use `push --squash` to send a squash of the commits to hide the actual tinkering. So if your way allows to do it, I vote to stick with yours. Regards, Pierre Penninckx-- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
