Re: [PATCH] subtree: add squash handling for split and push

From: Pierre Penninckx <ibizapeanut@gmail.com>
Date: Nov 28, 2013, 22:58 UTC
Message-ID: <1B2468D5-F0B7-4D11-8710-A3A7C8D66215@gmail.com>
In-Reply-To: <20131128182309.GA3655@comcast.net>

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.

Show 11 quoted lines

> 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