Mark McLoughlin wrote:
I could add a
bisectability test but that would take a long time to run...
Testing that each commit builds could be easily automated and quick to
run. I try to do that before sending a series.
It's certainly doable. I used to do that as part of my regular process.
Alternatively, cooperating among each other to stagger submissions could
help.
Given the lag between submission and pushing, waiting until the first
series is pushed probably isn't what we want.
One way I tried solving this before was pulling conflicting patches into
my tree, re-basing on top of them and then asking you to pull from my
tree, but that was ignored.
My process is really optimized to avoid losing patches. It gets
difficult to maintain this fidelity when dealing with subtree pulls
unless there's an absolute clear set of rules about what patches can be
dropped from my normal process.
Subtree pulls have worked great for linux-user because I can drop
linux-user patches very easily and they never touch anything else.
Riku also batches linux-user patches on the mailing list which is
helpful when dealing with subtrees.
As we get better at modularity and some of these touch everything series
slow down, I think we'll be able to more sanely do subtree pulls.
I'd have been happy to re-base my series on-top of Gerd's and re-send to
the list, but I fear you might then have tried to apply my series first
and then dropped it. Also, I hate spamming the list with large series of
patches that have only trivially been changed.
How about a simple "I've merged Gerd's into staging, yours conflicts,
please re-base" on-list? Then I could reply with "Cool, re-base pushed
to vnet-hdr.v2 in my tree" and you could merge that?
I do this for non-trivial rebases. It would slow things down
considerably to do this for everything because as I've said before,
everything conflicts in some way. It offers little value to the process
too. This was a simple conflict resolution that a trained monkey would
have been capable of resolving :-)
The big problem is squashing the commits. It gets challenging because
it requires every change to be an individual commit and then it often
takes a lot of manual tinkering to find the right commits to squash
with. Using git branch merging would really simplify my life here and
it's something I've been considering for some time now.
It also helps with review because it demonstrates exactly what I did to
resolve the conflict.
Personally, I prefer a linear history but this implies re-basing series.
A conflicting re-base should be usually be done by the submitter,
though.
However, if you are to resolve a conflict, it probably should be done as
a merge commit rather than as a re-base.
Yeah, I've been leaning toward something like this for a while and I
think I might take a stab at it. We'll lose a linear history anyway
once we start using sub trees more so it's not a huge loss.
Regards,
Anthony Liguori