From: Catalin Marinas <catalin.marinas@gmail.com>
To: Martin Langhoff <martin.langhoff@gmail.com>
Cc: Joel Becker <Joel.Becker@oracle.com>,
Junio C Hamano <junkio@cox.net>,
git@vger.kernel.org, Petr Baudis <pasky@suse.cz>
Subject: Re: git versus CVS (versus bk)
Date: Tue, 01 Nov 2005 13:25:39 +0000 [thread overview]
Message-ID: <tnxd5lkwld8.fsf@arm.com> (raw)
In-Reply-To: <46a038f90510311702wfb43281rf4464a02e8e3be2@mail.gmail.com> (Martin Langhoff's message of "Tue, 1 Nov 2005 14:02:43 +1300")
Martin Langhoff <martin.langhoff@gmail.com> wrote:
> On 11/1/05, Joel Becker <Joel.Becker@oracle.com> wrote:
>> > is possible) offhand. Sometimes, when you want truly logical
>> > steps, you would end up needing intermediate steps that never
>> > existed in your true history (i.e. "in the hindsight, my
>> > development should have progressed in these steps.")
>>
>> Yes, I always do. But I'm not talking about that sort of large
>> feature add or whatever. I'm talking about merely doing something on a
>> small scale, but in a temporary repository.
>
> I'm really surprised that Calalin hasn't chimed in.
Well, it was night here when this discussion took off :-).
> If you are into rewriting/merging/splitting your patches, StGIT is
> your friend. Check out: http://www.procode.org/stgit/
StGIT mainly resembles Quilt workflow but there are no patches, only
commit objects which are indefinitely replaceable (push/pop/refresh).
What I usually do is create smaller commits for different features and
just stack them together. That's usually for features which are
dependent on each-other and you can control them with a finer grain
than having separate branches. One can push/pop patches (commits) to
bring the patch to be modified at the top. After modification, a
refresh command would save it as a commit. All the patches (commits)
in the stack are accessible via HEAD and are seen as GIT commits.
It may happen to just have a bigger patch which needs splitting. What
I usually do in this case is import the patch as an StGIT patch
(i.e. GIT commit object), pop it from the stack so that it is no
longer applied, split the physical patch (diff file) into smaller, logical
changes and apply them one by one with StGIT. When you think al the
big patch was completely applied, pushing it should result in an empty
patch, otherwise you might have missed something that needs applying.
With StGIT you can also pick a commit object from a different branch
as a StGIT patch or you could merge two patches into one.
Once you are OK with the patches in the stack, just ask the gatekeeper
to pull the changes from your tree using plain GIT or mail them
automatically with StGIT.
--
Catalin
next prev parent reply other threads:[~2005-11-01 13:26 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-31 1:50 git versus CVS (versus bk) walt
2005-10-31 1:59 ` Martin Langhoff
2005-10-31 2:03 ` H. Peter Anvin
2005-10-31 2:35 ` Linus Torvalds
2005-10-31 10:24 ` Johannes Schindelin
2005-10-31 16:18 ` Linus Torvalds
2005-10-31 18:18 ` wa1ter
2005-10-31 19:44 ` Randal L. Schwartz
2005-10-31 23:41 ` walt
2005-11-01 0:15 ` Daniel Barkalow
2005-11-01 0:21 ` Linus Torvalds
2005-10-31 19:50 ` Joel Becker
2005-10-31 20:28 ` Martin Langhoff
2005-10-31 21:30 ` Joel Becker
2005-11-01 9:15 ` Petr Baudis
2005-11-01 16:17 ` Joel Becker
2005-11-01 17:35 ` Petr Baudis
2005-11-07 22:56 ` Petr Baudis
2005-11-08 10:50 ` Josef Weidendorfer
2005-11-08 12:04 ` Petr Baudis
2005-11-01 2:17 ` Randal L. Schwartz
2005-11-01 2:23 ` Linus Torvalds
2005-11-01 2:34 ` Randal L. Schwartz
2005-11-01 2:47 ` Linus Torvalds
2005-11-01 2:35 ` Junio C Hamano
2005-11-01 23:56 ` Horst von Brand
2005-11-02 8:54 ` Andreas Ericsson
2005-11-02 9:26 ` Junio C Hamano
2005-10-31 21:00 ` Junio C Hamano
2005-10-31 21:36 ` Joel Becker
2005-10-31 21:53 ` Linus Torvalds
2005-10-31 22:14 ` Junio C Hamano
2005-10-31 22:42 ` Joel Becker
2005-11-01 0:20 ` Junio C Hamano
2005-11-01 0:42 ` Joel Becker
2005-11-01 1:02 ` Martin Langhoff
2005-11-01 1:29 ` Joel Becker
2005-11-01 1:48 ` Linus Torvalds
2005-11-01 9:17 ` Petr Baudis
2005-11-01 13:25 ` Catalin Marinas [this message]
2005-11-01 0:25 ` Theodore Ts'o
2005-11-01 9:08 ` hgmq vs. StGIT Petr Baudis
2005-11-01 9:23 ` Catalin Marinas
2005-11-01 10:10 ` Petr Baudis
2005-11-01 17:34 ` Catalin Marinas
2005-11-01 15:20 ` Chuck Lever
2005-11-01 15:36 ` Chris Mason
2005-11-01 17:18 ` Catalin Marinas
2005-11-01 18:13 ` Chris Mason
2005-11-01 21:30 ` Catalin Marinas
2005-11-02 15:41 ` Chris Mason
2005-11-05 20:23 ` Catalin Marinas
2005-11-09 23:32 ` Petr Baudis
2005-11-10 0:08 ` Pavel Machek
2005-11-10 16:20 ` Catalin Marinas
2005-11-01 14:11 ` Chris Mason
2005-11-01 16:00 ` Linus Torvalds
2005-11-01 17:13 ` Catalin Marinas
2005-11-01 17:29 ` Catalin Marinas
2005-11-01 17:59 ` Chris Mason
2005-11-01 21:22 ` Catalin Marinas
2005-11-01 0:31 ` git versus CVS (versus bk) Daniel Barkalow
2005-10-31 21:35 ` Linus Torvalds
2005-10-31 13:00 ` wa1ter
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=tnxd5lkwld8.fsf@arm.com \
--to=catalin.marinas@gmail.com \
--cc=Joel.Becker@oracle.com \
--cc=git@vger.kernel.org \
--cc=junkio@cox.net \
--cc=martin.langhoff@gmail.com \
--cc=pasky@suse.cz \
/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;
as well as URLs for NNTP newsgroup(s).