From: Ingo Molnar <mingo@elte•hu>
To: Pekka Enberg <penberg@cs•helsinki.fi>
Cc: Stephen Rothwell <sfr@canb•auug.org.au>,
Vegard Nossum <vegard.nossum@gmail•com>,
linux-next@vger•kernel.org,
Eduard - Gabriel Munteanu <eduard.munteanu@linux360•ro>,
Christoph Lameter <cl@linux-foundation•org>
Subject: Re: linux-next: manual merge of the kmemcheck tree
Date: Wed, 13 Aug 2008 13:52:10 +0200 [thread overview]
Message-ID: <20080813115210.GD18660@elte.hu> (raw)
In-Reply-To: <1218627433.7813.320.camel@penberg-laptop>
* Pekka Enberg <penberg@cs•helsinki.fi> wrote:
> Hi Ingo,
>
> On Wed, 2008-08-13 at 10:58 +0200, Ingo Molnar wrote:
> > what's your current workflow, what causes the sha1's for commits to
> > change frequently? Do you work with patches (i.e. it's not really a Git
> > workflow at all and you regenerate the git tree all the time you export
> > it from your patch queue), or do you perhaps git-rebase often to clean
> > up patches?
>
> No, I don't work with patches. A lot of the churn comes from the fact
> that I have been dropping and re-applying SLUB defrag patches from
> Christoph lately. I keep them in a topic branch and pull them for my
> 'for-next' branch that appears in linux-next.
>
> The basic workflow for me is as follows:
>
> - Whenever someone sends me a patch, I apply it to my 'testing'
> branch, do a little bit testing there and if everything seems fine,
> I pull the branch to my 'for-next' branch.
>
> - After few days, I pull (or cherry pick) the patches to 'for-linus'
> branch and ask Linus to pull. Whenever he pulls, I usually rebase
> all of my branches to Linus' master.
>
> - For development, I maintain topic branches that are _not_
> append-only (such as SLUB defrag and kmemtrace). Whenever something
> changes there I do a git-reset --hard on 'for-next' and re-pull the
> topic branches there.
>
> - Also, I usually rebase my whole tree after an -rc release or two
> just to keep my tree in-sync with mainline. That usually doesn't
> affect my patches at all.
>
> So AFAICT most of the changes to SHA1s are due to me doing development
> in the topic branches and recreating the 'for-next' branch.
seems pretty sane to me. We use something quite similar in -tip, with
the distinction that after a very short initial period [a few days at
most] we try to keep development branches append-only as well.
There are 5 main advantages of doing that:
- trust: the end result, despite being a slighly bit messy, is easier to
trust. The commits are in true historic order, development activities
and timeline is easy to review.
- integration: creating the next branch is just a matter of doing an
incremental git-merge.
- guaranteed no-brains preservation of information: no patch is lost
ever in a pure append-only flow. Doing a git-reset --hard anytime
always risks the loss of patches - and even if only history is lost,
that is valuable too most of the time. Whenever i do it i have to use
additional safeguards against the loss of patches.
- bisection quality: statistically, the newest commits tend to have
the most bugs. By doing delta patches - even if the end result is a
higher patch count - makes the risky portion of a stream of
append-only changes drastically smaller. [this assumes that there is
an adequate QA effort and that commits do not just sit there unused:
that the topic branch is tested well enough and is exposed to others
via linux-next, etc.]
- other contributors: derived work (people basing trees off topic
branches) do not get sha1's pulled from under their feet. Back/forth
merging is easy. Having history of development in a tree (as long as
it's not totally insane history) is beneficial in general.
btw., when you send something to Linus and he pulls, generally you dont
have to rebase/reset to 'clean up the house' - as long as you dont
cherry-pick into the release branch. A "git-merge linus/master" will
fast-forward your topic branch and will turn it into a pure
upstream-based branch.
Ingo
next prev parent reply other threads:[~2008-08-13 11:52 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-13 5:29 linux-next: manual merge of the kmemcheck tree Stephen Rothwell
2008-08-13 7:32 ` Ingo Molnar
2008-08-13 7:31 ` Pekka Enberg
2008-08-13 7:58 ` Ingo Molnar
2008-08-13 8:14 ` Pekka Enberg
2008-08-13 8:58 ` Ingo Molnar
2008-08-13 11:37 ` Pekka Enberg
2008-08-13 11:52 ` Ingo Molnar [this message]
2008-08-13 11:57 ` Pekka Enberg
2008-08-13 12:05 ` Ingo Molnar
2008-08-13 7:41 ` Stephen Rothwell
-- strict thread matches above, loose matches on Subject: below --
2008-12-30 12:18 Stephen Rothwell
2008-12-30 12:14 Stephen Rothwell
2008-10-28 5:14 Stephen Rothwell
2008-10-28 8:15 ` Ingo Molnar
2008-10-21 5:29 Stephen Rothwell
2008-10-21 7:32 ` Ingo Molnar
2008-10-21 8:07 ` Vegard Nossum
2008-10-21 8:28 ` Ingo Molnar
2008-10-21 5:15 Stephen Rothwell
2008-08-20 6:40 Stephen Rothwell
[not found] <20080815164909.3d8beb10.sfr@canb.auug.org.au>
2008-08-15 7:04 ` Vegard Nossum
2008-08-15 8:00 ` Stephen Rothwell
2008-08-15 6:45 Stephen Rothwell
2008-08-15 6:43 ` Pekka Enberg
2008-08-15 8:17 ` Ingo Molnar
2008-08-13 5:26 Stephen Rothwell
2008-08-13 5:22 Stephen Rothwell
2008-07-28 4:09 Stephen Rothwell
2008-07-28 9:06 ` Ingo Molnar
2008-07-28 17:19 ` Stephen Rothwell
2008-07-28 4:01 Stephen Rothwell
2008-07-28 9:05 ` Ingo Molnar
2008-07-28 9:17 ` Vegard Nossum
2008-07-28 9:29 ` Ingo Molnar
2008-07-22 6:16 Stephen Rothwell
2008-07-22 6:52 ` Ingo Molnar
2008-07-22 8:18 ` Stephen Rothwell
2008-07-21 6:47 Stephen Rothwell
2008-07-11 6:32 Stephen Rothwell
2008-07-03 6:19 Stephen Rothwell
2008-07-03 6:12 Stephen Rothwell
2008-07-03 6:26 ` Ingo Molnar
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=20080813115210.GD18660@elte.hu \
--to=mingo@elte$(echo .)hu \
--cc=cl@linux-foundation$(echo .)org \
--cc=eduard.munteanu@linux360$(echo .)ro \
--cc=linux-next@vger$(echo .)kernel.org \
--cc=penberg@cs$(echo .)helsinki.fi \
--cc=sfr@canb$(echo .)auug.org.au \
--cc=vegard.nossum@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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