From: Jerry Van Baren <vanbaren@cideas.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] RFC: Custodian conventions update
Date: Wed, 15 Aug 2007 19:34:03 -0400 [thread overview]
Message-ID: <46C38D6B.6050501@cideas.com> (raw)
Hi all,
The merge window is closing. Now that we've gotten some real git usage
under our belts and done some non-trivial multi-repository pushing and
pulling, I thought it would be good to memorialize some Best
Practices[tm]. As a result, I've updated the Custodian page based on
what worked well for me, and extrapolating slightly beyond that.
What I added is the bullet list in:
<http://www.denx.de/wiki/view/UBoot/CustodianGitTrees#Tips_for_maintaining_custodian_t>
Potentially controversial parts:
* I propose publishing a "testing" branch for not quite ready for prime
time work-in-progress (appeared to work well for Kim)
* I propose publishing a "merge" branch for work that is ready to be
merged when the next window opens.
I found this branch technique to work *extremely* well, keeping my
queued but unmerged changes separate and clearly identified and allowing
me to rebase the changes to track the master repo. Rebasing identified
and allowed me to fix conflicts before Wolfgang stepped in them.
Trivia: I used the branch "fdt-cmd" initially and am using "fdt"
currently, and noticed Kim used "83xx". If we standardize on "merge"
(or, if someone has a better name...), it will lessen confusion and
simplifies the instructions. In addition, since it is difficult
(impossible?) for custodians to remove branches from their denx.de
subrepos, it lessens the dead branch namespace pollution.
If the above is adopted, the CustodianGitTrees page can be further
simplified by removing redundant information, but I didn't want to
totally rewrite the page before publishing a RFC.
Best regards,
gvb
next reply other threads:[~2007-08-15 23:34 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-15 23:34 Jerry Van Baren [this message]
2007-08-16 1:10 ` [U-Boot-Users] RFC: Custodian conventions update Andy Fleming
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=46C38D6B.6050501@cideas.com \
--to=vanbaren@cideas.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.