From: Mike Frysinger <vapier@gentoo.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] Attn Maintainers: git advise needed (how to fix messed up repo)
Date: Mon, 28 Nov 2011 22:31:21 -0500 [thread overview]
Message-ID: <201111282231.22883.vapier@gentoo.org> (raw)
In-Reply-To: <CALButCK--qf9qsCH94goHDF1jY2ofcfcgOf9si8Z259Ht+qQWQ@mail.gmail.com>
On Monday 28 November 2011 19:02:20 Graeme Russ wrote:
> > cd Source/U-Boot/x86 (my local version of the u-boot-x86 repo)
> > git fetch u-boot (as per the 'new' methodology of not having a seperate
> > u-boot branch)
> > git checkout master
> > git rebase u-boot/master
> > git push ssh://gu-x86 at git.denx.de/u-boot-x86
> > git checkout next
> > git rebase master
> > git push ssh://gu-x86 at git.denx.de/u-boot-x86
ok, i've read the official recommended workflow [1]. it seems to contradict
itself. for example, it starts with:
Philosophy of custodian trees
... it is the custodian's responsibility to provide a permanently
accessible, consistent view of his repository to users.
i read that as saying "no rewriting of published history". but later on it
says to do just that:
Tips for maintaining custodian trees
- Keep in sync with the upstream repository by pulling it.
- Rebase the master, testing and any "work in progress" branches to the
${upstream}/master remote branch.
- Push the appropriate branch(es) to the denx.de repo:
- Pushing the testing and/or rebased master branches often requires
the -f force flag. This is because the state/content/order of the
patches in the branch changed due to the rebase operations.
so i guess your example workflow is fine, you just need to use the --force flag.
and you should specify the branches to push rather than leaving that to be
implicit. so change:
git push ssh://gu-x86 at git.denx.de/u-boot-x86
to:
git push --force ssh://gu-x86 at git.denx.de/u-boot-x86 next
git push --force ssh://gu-x86 at git.denx.de/u-boot-x86 master
> Do the above periodically so anyone working off u-boot-x86 can keep
> up-to-date
the expected behavior of downstream users is apparently to always fetch+rebase
rather than fetch+merge (what "pull" normally does). this is pretty unusual
(and in most git circles, unforgivable as the "default" workflow). but as i'm
not a consumer of any of these trees except Wolfgang's, i'm not going to argue
over it. so your x86 users have to do (assuming they've cloned your tree):
git fetch
git rebase origin/master
instead of the more normal:
git pull
-mike
[1] http://www.denx.de/wiki/U-Boot/CustodianGitTrees
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20111128/165980f9/attachment.pgp>
next prev parent reply other threads:[~2011-11-29 3:31 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-28 22:31 [U-Boot] Attn Maintainers: git advise needed (how to fix messed up repo) Graeme Russ
2011-11-28 23:02 ` Mike Frysinger
2011-11-28 23:05 ` Graeme Russ
2011-11-28 23:13 ` Mike Frysinger
2011-11-28 23:16 ` Andy Fleming
2011-11-28 23:20 ` Graeme Russ
2011-11-28 23:43 ` Mike Frysinger
2011-11-29 0:02 ` Graeme Russ
2011-11-29 3:31 ` Mike Frysinger [this message]
2011-11-29 3:35 ` Graeme Russ
2011-11-29 4:01 ` Mike Frysinger
2011-11-29 4:17 ` Graeme Russ
2011-11-29 4:49 ` Mike Frysinger
2011-11-29 5:04 ` Graeme Russ
2011-11-29 5:31 ` Andy Fleming
2011-11-29 5:36 ` Mike Frysinger
2011-11-29 10:51 ` Graeme Russ
2011-11-29 15:08 ` Mike Frysinger
2011-11-29 22:57 ` Graeme Russ
2011-11-29 23:35 ` Mike Frysinger
2011-11-29 23:48 ` Graeme Russ
2011-11-30 3:52 ` Mike Frysinger
2011-11-30 4:12 ` Graeme Russ
2011-11-30 16:41 ` Mike Frysinger
2011-11-29 9:55 ` Graeme Russ
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=201111282231.22883.vapier@gentoo.org \
--to=vapier@gentoo.org \
--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.