On 10/09/2012 06:25:47 PM, Stephen Warren wrote:
On 10/09/2012 05:00 PM, Scott Wood wrote:
On 10/09/2012 05:14:23 PM, Stephen Warren wrote:
I don't quite follow that; linux-next is also purely merge-based.
Are
you referring to the fact that it's re-created every day, and the source branches that go into the merge can be rebased if needed?
What's the difference between "re-created every day" and "rebased
every
day"?
The linux-next model (and what I mean by "re-created every day") is roughly the following approximately daily:
git fetch --all git branch -D tmp git checkout -b tmp u-boot/master # or latest rc in fact git merge u-boot-arm/next git merge u-boot-i2c/next git merge u-boot-video/next etc. git tag next-${datestamp}
I'm not sure what "rebased every day means"; perhaps it's running the following on u-boot/next every day?
git rebase u-boot/master
That doesn't pull in any new commits from child trees though.
By "rebasing" I was referring to rewriting history in any form. It looks like the difference is that linux-next gives the result a new name each time, instead of working a branch with a fixed name.
How does merging back down prevent incremental pull requests?
It doesn't prevent incremental pull requests, but it does pollute the history if you merge back down. Instead of a fairly simple:
(M* == main branch, B* == side branch)
B1-B2-B3-B4-B5-B6/ \ \ M1-M2-M3-M4-M4-M5-M6-M7
you might end up with:
B1-B2-B3-B4-X1-B6/ \ / \ M1-M2-M3-M4-M4-M5-M6-M7
... where X1 is the merge back from main to the side-branch. That doesn't look a lot more complex, but once there are many side-branches, and the master branch ends up merging a whole bunch of side-branches between M4 and M5 above, the commits in B* that add actual new work are split between a point before the X1 merge-back and after it. This can make tracking down what exactly will get merged into M* when B* is re-merged a bit trickier. git log M..B can probably show it fine, but if you start looking at gitk it'll look quite complex.
I don't use gitk much, but wouldn't it just show the mergeback as another edge in the graph (plus the merge commit itself of course)? It doesn't seem like a big deal.
Or often when u-boot/master has made a complete new release does:
b) Creates a new branch based on the latest rc or release from u-boot/master.
That's a rebase. How is that better than a (likely fast-forward)
merge?
No, that's not a rebase.
Fine, a reset. Or a new branch name, which in practice is the same thing except with a much more cluttered branch list, unless you have a specific need to refer to an older iteration of this process.
Rebase is when you take some existing commits based on one commit and apply them to a different baseline commit instead. If you're creating a new branch to take commits for a new release, you're simply not applying the commits for release N+1 until there's a branch ready to take them.
There is a branch ready to take them -- the custodian tree. Why wait until there's an upstream tree ready to pull?
(in practice, downstream branches typically end up with
something
like for-3.5 based on v3.4-rcN, for-3.6 based on v3.5-rcN, for-3.7 based on v3.6-rcN, some running in parallel containing either important bugfixes for the release or new development as determined by the current state of the various releases in the mainline tree).
I thought you said your way was less work? :-)
And I believe it is; no rebasing required. The difference probably isn't that big though I admit. Still, creating a fresh branch from scratch for each release one time and only then applying patches for that release seems a lot simpler that constantly rebasing stuff all over the place.
We've already dropped the rebasing. I'd rather do merges than constantly create new branches.
but with the Linux model, you simply:
a) Send pull request.
Admittedly the recipient then might need to resolve some merge conflicts. However, hopefully people have been planning for these
and
have avoided them.
How do you plan for them and avoid them, and how is that less work
that
what we do now?
People have to be aware what is going on.
If you're submitting a bunch of patches which depend on each-other, the submitter had better call that out when sending the patch series.
Sometimes it's not obvious in advance. Not all conflicts (whether they be merge conflicts, build breaks, or runtime failures) come from intrusive tree-wide changes.
I especially do not want to have to work with some artificially
chosen
old tree as my base. I also do not want to create a bunch of named branches for each
Linux requires that branches be based only on rc or release tags in the equivalent of u-boot/master.
So how do you sort out dependencies? If I have a patch that depends on some patches that have been already applied by custodian X, and others that have already been applied by custodian Y (yes, this happened recently), I have to wait until the next release to deal with them?
U-Boot could choose to be different, and
U-Boot is already different in what RCs mean -- the merge window ends well before rc1. So I couldn't even use my tree to send fixes for issues caused by the merge, until shortly before release. Or rather, I'd have to awkwardly backport the fixes to an old tree and hope that they make it OK when merged into the real tree.
-Scott