From: Jerry Van Baren <gerald.vanbaren@ge.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] Revised custodian git writeup
Date: Tue, 22 Jan 2008 08:50:13 -0500 [thread overview]
Message-ID: <4795F495.70101@ge.com> (raw)
In-Reply-To: <20080122105016.313d8f88@dhcp-252-066.norway.atmel.com>
Haavard Skinnemoen wrote:
> On Tue, 22 Jan 2008 09:55:33 +0100
> Wolfgang Denk <wd@denx.de> wrote:
>
>> Rebasing the master branch, i. e. the one I'll be pullung from?
>>
>> Are you sure that is a good idea? Note that I (and probably others)
>> will be pulling from that branch, and not only once!
>
> That depends on whether or not you want your commit history filled with
> "merge with upstream/master" crap or not.
>
> You should only pull when explicitly requested to do so. In that case,
> if the branch was newly rebased, there will be a clean, linear history
> from the tip of your master branch to the tip of the one being pulled.
>
> If there are conflicting changes and the merge needs manual
> intervention, you abort the merge and tell the one sending the pull
> request that it didn't merge cleanly, please rebase.
>
>> When you rebase a branch, you are changing its history in a
>> way that will cause problems for anyone who already has a copy
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> of the branch in their repository and tries to pull updates
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> from you. You should understand the implications of using git
>> ^^^^^^^^^
>> rebase on a repository that you share.
>
> And that is, IMO, exactly why you shouldn't be pulling from the master
> branch in the first place. People who pull regularly to test stuff that
> is in progress will run into this problem, and they are most likely to
> pull the master branch because that's the default.
>
> There are two different kinds of users involved here: You (and other
> maintainers that are "upstream" from someone), and regular users who
> want to test stuff. Upstream maintainers should receive a clean
> history, i.e. from a branch that is frequently rebased. At the same
> time, we should avoid exposing testers to the problems of dealing with
> a branch that is rebased all the time.
I don't see this as a big deal because my methodology (and the proper
one, IMHO) is to create a branch in my local repo, pull the current
state of the target repo into the branch, and then either merge or
cherrypick the "foreign" subrepo changes into my working branch in my
repo. At that point, I discard the foreign repo branch because it has
served its purpose. Because I discard the foreign repo branch, I don't
care of the foreign repo gets rebased and its history is rewritten, I've
already discarded that history.
If more things change in the foreign repo, I do the same thing over,
starting with creating a new branch.
I'm sure that is how Wolfgang pulls subrepos to - not directly, but into
a testing branch and then, if it is OK, into the main u-boot.git repo.
Here are my Cliff Notes(R) for a real example of this interaction with
u-boot.git and between myself and Kumar, pulling his libfdt updates into
my u-boot-fdt.git repo:
<http://www.denx.de/wiki/view/UBoot/UBootFdtInfo#All_Your_Base_are_Belong_to_Us>
This ultimately was merged by Wolfgang into u-boot.git with no problems
(yet ;-).
> So we need (at least) two different branches that are maintained in
> different ways, and I think it's easier to tell you, Wolfgang and other
> upstream maintainers, to pull from a non-master branch than to tell
> everyone else in the world.
>
> Just my two cents.
>
> Haavard
+ my 2c,
gvb
next prev parent reply other threads:[~2008-01-22 13:50 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-22 1:44 [U-Boot-Users] Revised custodian git writeup gvb.uboot
2008-01-22 7:52 ` Markus Klotzbücher
2008-01-22 8:55 ` Wolfgang Denk
2008-01-22 9:50 ` Haavard Skinnemoen
2008-01-22 13:45 ` Wolfgang Denk
2008-01-22 14:20 ` Haavard Skinnemoen
2008-01-22 14:42 ` Mike Frysinger
2008-01-22 16:34 ` Wolfgang Denk
2008-01-22 18:23 ` Joakim Tjernlund
2008-01-22 18:39 ` Haavard Skinnemoen
2008-01-22 13:50 ` Jerry Van Baren [this message]
2008-01-22 14:10 ` Wolfgang Denk
2008-01-22 13:32 ` Jerry Van Baren
2008-01-22 14:03 ` Wolfgang Denk
2008-01-22 14:26 ` Markus Klotzbücher
2008-01-22 16:36 ` Wolfgang Denk
2008-01-22 22:47 ` Jerry Van Baren
2008-01-22 23:32 ` Wolfgang Denk
2008-01-23 3:15 ` gvb.uboot
2008-01-23 12:04 ` Martin Krause
2008-01-23 12:47 ` Wolfgang Denk
2008-01-23 17:27 ` Martin Krause
2008-01-23 17:30 ` Haavard Skinnemoen
2008-01-22 14:38 ` Haavard Skinnemoen
2008-01-22 14:35 ` Jerry Van Baren
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=4795F495.70101@ge.com \
--to=gerald.vanbaren@ge.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox