[U-Boot] U-Boot git usage model

[Jason Cooper <u-boot@lakedaemon.net>]

On Thu, Oct 11, 2012 at 09:19:22AM +0200, Wolfgang Denk wrote:
> Dear Stephen Warren,
> 
> In message <5075F48A.2080504@wwwdotorg.org> you wrote:
> >
> > I believe that's (part of) why Linux is tending towards pull requests of
> > a (signed) tag rather than a branch, since the tag always points at a
> > specific commit, and incremental pull requests can just create a new tag
> > name. Of course, the ability to sign tags also also a motivator.
> 
> I tend to disagree here. Tags can easily be removed. As such, they
> are in no way different from or better than a specific commit in a
> branch that does not get rebased.

I agree with Wolfgang, I move signed tags around all the time _before_ I
push to a public branch.  That tends to happen because I'm still
learning the process, *not* as a part of a proper workflow.

For me, signed tags serve two purposes.  The first is sub-maintainer
verification.  Arnd Bergmann and Olof Johansson both signed my gpg key
at the last Kernel Summit.  So, when they pull a branch, they know I
created it.  Second, using git v1.7.9 and newer, request-pull will
insert the tag message into the body of the pull-request.  This provides
a nice summary of the branch in the email, as opposed to the branch-name
chaos we see now.  This summary, stays with the branch regardless of the
number of times the maintainer merges it.

I suppose there is a third advantage.  The signed tag is attached to a
specific sha1 commit.  If a maintainer inadvertently changes the commit
history of a branch by doing a rebase or similar, the tag would
disappear from the tip of the branch.  Kind of like the canary in the
mine.

Which brings me to another point I haven't seen mentioned in this thread
yet, git-rerere (1).  Arnd and Olof make extensive use of this command
to remember how they have resolved merge conflicts.  afaict, since I
don't need it at my level, they are continuously merging branches over
and over again.  Against new branches, new versions of widespread
changes (iomem, platform_data in the last window).  rerere makes that
workload possible.

hth,

Jason.