From: Stefan Roese <stefan.roese@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] ARM Workflow: rebase on ARM repositories
Date: Mon, 03 Sep 2012 15:13:09 +0200 [thread overview]
Message-ID: <5044ACE5.9030708@gmail.com> (raw)
In-Reply-To: <5044A44F.2050204@denx.de>
Hi Stefano,
On 09/03/2012 02:36 PM, Stefano Babic wrote:
> I was thinking about the way we are usual to manage our trees. This
> comes because I know about issues from users who set their development
> on ARM-repositories.
>
> One of them uses u-boot-imx for his development, and of course after I
> rebased my tree he got into trouble, due to using a commit that does not
> exist anymore.
> Nevertheless there are boards, where the official documentation explain
> how to set patches on bases of u-boot-arm. For example,
>
> http://www.ti.com/tool/tmdsevm3530
>
> Detlev discovers that the official documentation refers directly to
> commit cf6ec699a6dc21a538b039a0392cd38132072090 in u-boot-arm. After a
> rebase this commit does not exist anymore.
>
> Of course, we can really say that setting a development on a ARM
> repository instead of main repository is not the best ;-). But we know
> that sometimes setting on a partial repository is the best because some
> patches that are strictly required are already merged. And I do not know
> if we can say that our trees are "private" or "development" only: they
> are published, and available for everybody.
>
> Albert has described the way we are currently using in
> http://www.denx.de/wiki/view/U-Boot/CustodianGitTrees. I think you konow
> very well and it is the way we follow, and we usually rebase our tree
> after u-boot-arm is merged by Wolgang in mainline. I want to discuss
> here if we really need it and if this is the correct way to do.
>
> In Linux, every maintainer makes a "git pull" from Linus' tree. Nobody
> rebases, and I had never had the problem that my tree diverges when I
> update my kernel's trees from a mainatiner tree. However, this happens
> continuosly for the users of u-boot-imx. The way we are following can
> be seen in the linux-next trees, not in the main trees.
>
> The worst thing I think is that we lose the history of our tree, and the
> behavior can be different. Rebased patches can be different, and testing
> done until the rebase can be worthless and should be (theoretically)
> done again. Testers can say they have successfully test a patch, but it
> was on a pre-rebased tree. A tested-by in a rebased tree can be worthless.
>
> My big question is if we should not to come back using "git pull" to
> downstream mainline from Wolfgang's tree, instead of continuos rebase. I
> know that we switched to rebase to avoid a lot of "git merge commits",
> but maybe this is not so bad as rebasing.
>
> What is your opinion ?
I'm quite astonished about this rebasing you mention here. I'm not an
RAM custodian, so thats probably why I was not aware of it. But I do
manage 3 U-Boot custodian repositories (non-ARM). And I can't remember
that I had to rebase my custodian repositories ever. My workflow is the
one you describe with "git pull" based on Wolfgangs mainline tree. And
this definitely should be preferred over rebasing.
Aren't those merge problems solvable without rebasing in the ARM trees?
Thanks,
Stefan
next prev parent reply other threads:[~2012-09-03 13:13 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-03 12:36 [U-Boot] ARM Workflow: rebase on ARM repositories Stefano Babic
2012-09-03 13:13 ` Stefan Roese [this message]
2012-09-03 14:15 ` Stefano Babic
2012-09-03 18:02 ` Albert ARIBAUD
2012-09-03 19:13 ` Wolfgang Denk
2012-09-03 19:47 ` Albert ARIBAUD
2012-09-03 20:52 ` Wolfgang Denk
2012-09-04 9:37 ` Stefano Babic
2012-09-04 12:45 ` Albert ARIBAUD
2012-09-04 15:32 ` Stephen Warren
2012-09-03 19:06 ` Wolfgang Denk
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=5044ACE5.9030708@gmail.com \
--to=stefan.roese@gmail.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