> 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.
> 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
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.
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