From: Petr Baudis <pasky@ucw.cz>
To: Daniel Barkalow <barkalow@iabervon.org>
Cc: git@vger.kernel.org
Subject: Re: Git fork removal?
Date: Thu, 28 Apr 2005 11:10:39 +0200 [thread overview]
Message-ID: <20050428091039.GI8612@pasky.ji.cz> (raw)
In-Reply-To: <Pine.LNX.4.21.0504272221030.30848-100000@iabervon.org>
Dear diary, on Thu, Apr 28, 2005 at 04:47:24AM CEST, I got a letter
where Daniel Barkalow <barkalow@iabervon.org> told me that...
> > If this breaks your workflow, could you please describe it? Perhaps we
> > could find a good semantics to support both.
>
> The part that I'm worried about is the way I turn a mass of debugging and
> little local commits into a clean patch series. I've got a working fork
> "barkalow", which is the result of a bunch of stuff and a dozen
> commits. It is derived from "linus". I want to split up the changes and
> make a series of commits, each of which will be a patch to submit.
>
> 1) I fork "linus" into "for-linus". I go into "for-linus".
>
> 2) I do "git diff this:barkalow > patch". This gives me the complete set
> of changes I want to submit.
>
> 3) I cut down the diff to a single logical change by removing all of the
> other hunks.
>
> 4) I do "git apply < patch". I do "git commit". I describe the logical
> change.
>
> 5) I go back to step 2, unless I'm done.
>
> 6) For each of the commits between "linus" and "for-linus", I do
> "git patch <commit>", and send out the result.
>
> The thing that I think requires the symlinks is step 2, which requires
> that there be somewhere I can run git and have it able to see a pair of
> unrelated local heads and the relevant trees.
Just do cg-pull barkalow, to get the latest changes from that repository
(perhaps clone should inherit branches information?).
But if you want Linus to pull from your tree, you generally want it to
be clean - that is, you want to manage clean separation (as Pavel Machek
describes in his document). That is another advantage of hardlinking -
you don't get any unrelated stuff in if you don't explicitly pull it, so
you can keep your for-linus branch clean. I'd do cg-diff linus:this in
the barkalow branch instead to keep this property.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
next prev parent reply other threads:[~2005-04-28 9:11 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-28 1:31 Git fork removal? Daniel Barkalow
2005-04-28 2:12 ` Petr Baudis
2005-04-28 2:47 ` Daniel Barkalow
2005-04-28 9:10 ` Petr Baudis [this message]
2005-04-28 15:29 ` Daniel Barkalow
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=20050428091039.GI8612@pasky.ji.cz \
--to=pasky@ucw.cz \
--cc=barkalow@iabervon.org \
--cc=git@vger.kernel.org \
/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