[U-Boot] U-Boot git usage model

[Wolfgang Denk]

Dear Stephen Warren,

In message <5076F9BD.5050802 at wwwdotorg.org> you wrote:
>
> However, U-Boot is reported to only use Signed-off to indicate the
> original author(s), so I can see how the git committer field isn't

Delete the "original" here.  Once a patch has been commited to a tree,
it cannot be changed in any way (such as additional authors could do).

> considered important in U-Boot. I'm not convinced it's a good idea to be
> so cavalier about git metadata though; wouldn't it be better to take
> simple steps (never rebase any other committer's commits) so that the
> metadata is always correct?

Sorry, I cannot parse that.  I don't see what rebasing has to do with
that.  We are talking about the public trees which don't get rebased,
neverever.

As soon as you allow any rewriting of the hsitory, you will lose _all_
protection given by git through the strong cecksumming of all history.
If you give this up, then anything can be modified and faked as you
like, including code and metadata.


> > Why would I need to know that?
> 
> Personally I believe it's a good idea to document the whole commit/merge
> process fully. That's for all the same reasons that git contains

No, definitely not.  You do not want to ever know how many different
repositories and branches I am using in my own specific development
process.  Normally, any patch or pullrequest processed by me wil go
through 5...8 different repositories (and some eventually some
branches) before it hist mainline.  You would hate me if each of the
"git fetc" I'mdoing would create a merge commit.  And others might do
the same.

If the commits allow fast-forwarding, then there is zero sense in
recording a merge commit.

> metadata for author, committer, datestamps, log messages, etc. The whole
> point of source control is to document the development process;

Yes, but "development" here means actually changing something.   As
long as I don't change anything and just pass data around unchanged,
it is not necessary to recode any intermediate step I may take.

> If you have two commits or series that depend on each-other, e.g. series
> A introduces a new feature and series B makes use of that new feature,
> and those two series must be applied to different downstream trees for
> some reason, then the process would be:
> 
> 1) commit series A to downstream branch X
> 2) pull downstream branch X into u-boot/next
> 3) either re-create downstream branch Y from u-boot/next, or merge
> u-boot/next into existing downstream branch Y
> 4) commit series B to downstream branch Y

What has u-boot/next to do with this?  This should be unrelated.

If your tree needs A and B, then just do a "git pull A B" in that
tree.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
...when fits of creativity run strong, more than  one  programmer  or
writer  has  been  known to abandon the desktop for the more spacious
floor.                                             - Fred Brooks, Jr.