"Parallelizing" review units

[JeffFaer]

Let's say I'm working on a new feature, and I've broken it up into 3 separate pieces:

main -> A -> B -> C

C relies on the changes in both A and B, but A and B aren't actually all that related. They touch different parts of the code base, and they're unrelated enough that it actually makes sense for me to have them reviewed by different people. I think it'd be pretty neat if git branchless would let me easily rework history to look like

    /-> A -\
main        -> C
    \-> B -/

and then I could send A and B out for review while C still works as expected.

I suspect something like this might be significantly more useful (at least for me) after git stage / git split from #48 are implemented, since I generally expect I'd be carving off unrelated pieces of the commit into separate standalone commits so that they're easier to review and merge.

I guess this maybe also broaches a broader topic of how does git branchless handle merge commits. I did some local testing, and it doesn't look like it handles merge commits all that gracefully (happy to try and whip up some reproduction steps if this is interesting to you)

[mlcui-corp]

Re: git-branchless handling merge commits: I've encountered similar issues with merge commits and filed #672. As @arxanas mentioned, you could try out Jujutsu, which could handle merge commits better (and for Google employees, might replace the internal Mercurial workflow).

One workaround is possibly having a commit graph like:

    /-> A -> B -> C
main
    \-> B'

and cherry-picking B to main as B' whenever B gets modified.

[martinvonz]

I saw this feature request and it looked familiar because we had received the request for Mercurial from Jeffrey in our Google-internal bug tracker for Fig :) I remember saying that it should be easy to implement in the next generation of Fig. I've now filed martinvonz/jj#1079 to track it.

[arxanas]

In practice, I just create a stack of commits without spurious dependencies, and then git move -x <commit> -d 'main()' individual commits out of the stack if I want to land them separately, or I commute them to the bottom of the stack with git rebase -i.

See also the discussion at #553, which addresses more or less the same workflow. I think using Jujutsu and relying on automatically-rebased merge commits is probably the best way to accomplish your workflow.