git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Koch <thomas@koch.ro>
To: Petr Baudis <pasky@suse.cz>
Cc: git@vger.kernel.org, vcs-pkg-discuss@lists.alioth.debian.org
Subject: Re: rethinking patch management with GIT / topgit
Date: Tue, 23 Mar 2010 09:09:16 +0100	[thread overview]
Message-ID: <201003230909.16414.thomas@koch.ro> (raw)
In-Reply-To: <20100322193035.GM3533@machine.or.cz>

Petr Baudis:
> On Mon, Mar 22, 2010 at 08:59:40AM +0100, Thomas Koch wrote:
> > In all three cases you're free to either keep or throw away the old
> > patchset.
> 
> Yes, but to the same degree e.g. with StGIT I'm free to keep the head of
> the old patch series. That does not mean the operation *preserves* the
> history, only that the history is still around somewhere in the
> repository, however it won't be around in other incarnations of the
> repository and it will not be connected in any way to the current
> version of the patchset.
> 
> Yes, if you are lucky you can figure out the name of the previous
> version, but it's like starting development of each new kernel version
> by a clean import of the sources.

Hi Petr,

let me copy the list of methods from my last mail:

1) checkout new patch branches from the top of the old patch branches and 
merge upstream into each of them

2) recreate (like rebase) the full history of the patch branches on top of the 
new upstream

3) collapse the branch history and create one commit per patch branch on top 
of the new upstream

>From these methods, 3) loses all history, 2) loses some history but preserves 
the individual history of one patch branch on a new base and 1) preserves all 
history. Let me give an example for method 1). 
You've got a patchset identified by the prefix debian/. Now you want to 
package a new upstream but need to retain the old patchset in case of security 
updates in Debian stable. Debian stable has version 0.1, new upstream is 0.2.
So you
- rename the old patchset from debian/ to debian-0.1/
- clone/copy/recreate (pick a name) a new patchset debian/ on top of 
upstream/0.2. This is done by merging upstream/0.2 into each debian/* branch.
- Once you don't maintain version 0.1 anymore, you can delete the debian-0.1/* 
branches

After these steps, the debian/ branch still contains pointers to all commits 
from the debian-0.1/* branches.
It's an additional question, how to deal with commits that are done in 
debian-0.1/* after the new upstream merge.

Best regards,

Thomas Koch, http://www.koch.ro

      reply	other threads:[~2010-03-23  8:09 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-20 17:02 rethinking patch management with GIT / topgit Thomas Koch
2010-03-20 17:47 ` Petr Baudis
2010-03-20 18:53   ` Thomas Koch
     [not found]     ` <201003201953.34666.thomas-5j3myg3OO4w@public.gmane.org>
2010-03-21 20:36       ` Petr Baudis
2010-03-22  7:59         ` Thomas Koch
2010-03-22 19:30           ` Petr Baudis
2010-03-23  8:09             ` Thomas Koch [this message]

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=201003230909.16414.thomas@koch.ro \
    --to=thomas@koch.ro \
    --cc=git@vger.kernel.org \
    --cc=pasky@suse.cz \
    --cc=vcs-pkg-discuss@lists.alioth.debian.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;
as well as URLs for NNTP newsgroup(s).