Dear Stephen Warren,
In message 5076F9BD.5050802@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:
- commit series A to downstream branch X
- pull downstream branch X into u-boot/next
- 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