[U-Boot] U-Boot git usage model

[Scott Wood]

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