git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Catalin Marinas <catalin.marinas@gmail.com>
To: Daniel Barkalow <barkalow@iabervon.org>
Cc: Jan Veldeman <jan.veldeman@gmail.com>, git@vger.kernel.org
Subject: Re: [RFC] Stgit - patch history / add extra parents
Date: Wed, 31 Aug 2005 10:27:50 +0100	[thread overview]
Message-ID: <tnxaciyo3qh.fsf@arm.com> (raw)
In-Reply-To: <Pine.LNX.4.63.0508231731370.23242@iabervon.org> (Daniel Barkalow's message of "Tue, 23 Aug 2005 18:23:57 -0400 (EDT)")

Daniel Barkalow <barkalow@iabervon.org> wrote:
> On Tue, 23 Aug 2005, Jan Veldeman wrote:
>> The parents which should be visible to the outside, will always be versions
>> of my development tree, which I have previously pushed out. My way of
>> working would become:
>> * make changes, all over the place, using stgit
>> * still make changes (none of these gets tracked, intermittent versions are
>>   lost)
>> * having a good day: changes looks good, I want to push this out:
>>   * push my tree out
>>   * stgit-free (which makes the pushed out commits, the new parents of my
>>     stgit patches)
>> * restart from top
>
> I'm not sure how applicable to this situation stgit really is; I see stgit
> as optimized for the case of a patch set which is basically done, where
> you want to keep it applicable to the mainline as the mainline advances.
>
> For your application, I'd just have a git branch full of various stuff,
> and then generate clean commits by branching mainline, diffing development
> against it, cutting the diff down to just what I want to push, and
> applying that. Then the clean patch goes into stgit.

StGIT has the 'refresh' command which allows a patch to be
indefinitely modified (that's pretty much how I use StGIT). I use it
for the case where I would like to keep the changes in separate
logical entities (patches) but they are not independent enough to
create separate branches.

Take for example a new platform port, you can have some of the
existing code re-worked in a patch, some CPU support in the next
patch, basic platform support in another patch, some device drivers
specific to this platform in yet another patch. Subsequent patches are
dependent on the previous ones. Branching from the mainline for each
of these features might not make sense and keeping all of them in the
same branch can make maintenance a bit more difficult.

-- 
Catalin

  parent reply	other threads:[~2005-08-31  9:29 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-18 19:57 [RFC] Stgit - patch history / add extra parents Jan Veldeman
2005-08-19  9:53 ` Catalin Marinas
2005-08-19 18:27   ` Jan Veldeman
2005-08-19 22:15     ` Catalin Marinas
2005-08-19 19:48   ` Jan Veldeman
2005-08-20 21:12     ` Catalin Marinas
2005-08-21  9:40       ` Jan Veldeman
2005-08-22 22:10         ` Daniel Barkalow
2005-08-23 16:55           ` Catalin Marinas
2005-08-23 18:05             ` Daniel Barkalow
2005-08-23 21:23               ` Jan Veldeman
2005-08-23 22:23                 ` Daniel Barkalow
2005-08-25  7:09                   ` Jan Veldeman
2005-08-25 19:41                     ` Daniel Barkalow
2005-08-31  9:27                   ` Catalin Marinas [this message]
2005-08-31  9:12                 ` Catalin Marinas
2005-08-30 21:41               ` Catalin Marinas
2005-08-31  8:59                 ` Jan Veldeman
2005-08-31 17:17                 ` Daniel Barkalow
2005-08-24  0:23             ` Junio C Hamano
2005-08-24  2:26               ` Linus Torvalds
2005-08-23  1:06         ` Junio C Hamano

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=tnxaciyo3qh.fsf@arm.com \
    --to=catalin.marinas@gmail.com \
    --cc=barkalow@iabervon.org \
    --cc=git@vger.kernel.org \
    --cc=jan.veldeman@gmail.com \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).