On 10/10/2012 10:55:33 AM, Stephen Warren wrote:
On 10/09/2012 06:20 PM, Scott Wood wrote:
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.
One big problem is the ability to look back and see easily what's been merged and what work has been committed since then.
If I run "git log u-boot-xxx/master", and look backwards through the list of commits, looking for those committed by the owner of u-boot-xxx, and stop when I see a commit by someone else, I'll end up stopping at the merge commit where u-boot/master was merged back down.
Very often that ends up being a fast forward.
Plus, what about commits that were merged from a tree futher downstream?
If there commits to u-boot-xxx/master between the point where u-boot/master merged u-boot-xxx/master and where u-boot-xxx/master merged u-boot/master back down, then they'll be hidden before that merge point.
Now, I probably could just do git log u-boot/master..u-boot-xxx/master, but that's a but more complicated (and I can never remember which order to give the two branches).
I have a hard time remembering the order too (it seems backwards from what's intuitive), but it's usually obvious when I get the order wrong. And it's faster and more robust than scanning for a commit that looks like it came from somewhere else.
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?
Well, the two possibilities are:
a) Send pull request b) Wait for pull request to be merged c) Here, or later, merge back down u-boot/master. Note this cannot happen before (b) has completed, or the merge of this branch upstream may pick up extra commits that weren't in the pull request. d) Continue merging commits to the same branch without reset/...
or:
a) Send pull request b) Wait for pull request to be merged c) Reset u-boot-xxx/master to u-boot/master or some rc or ... d) Continue merging commits
In either case, one must always wait for the pull request send in (b) to be completely merged so that when the pull request is merged, it doesn't pick up commits to the branch that were added after the pull request was sent. So, there isn't a tree ready to take new patches until a pull request has been completely processed.
Ideally once a pull request happens the pull happens quickly. If that doesn't happen, you could reply to the pull request asking that it be ignored in favor of a new pull request, or create a new temporary branch. IMHO pull requests ought to request a pull of a specific SHA1 along with the branch name (it'd be nice if the command to pull could verify that the SHA1 is in the history of the branch name, and include the branch name in the commit message, but merge based on the SHA1).
> (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.
The whole reason I started this thread was because rebasing was still being used.
Rebasing is no longer supposed to be part of the standard workflow, as you portrayed it. I'm not sure why the rebasing happened in this particular instance.
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.
Since u-boot/next appears to be a rolling/parallel model, where changes can be pulled into it at arbitrary times even when u-boot/master is being used to stabilize a release, the way to resolve conflicts for U-Boot is simply to have the branch containing the dependency push their /next into u-boot/next, then the branch needing the dependency to branch from or merge u-boot/next into their /next, then apply the patch with the dependency.
Again, it's not always obvious in advance. The patches that conflict may have already been applied to their respective custodian trees.
-Scott