Subject: Re: [RFC] Patches exchange is bad?

From: Catalin Marinas <[email-masked]>
Date: Thu, 18 Aug 2005 12:16:59 +0100

Marco Costalba <[email-masked]> wrote:
> Catalin Marinas wrote:
>>That's how you would normally do development on Linux using StGIT -
>>clone the mainline kernel, create patches in your StGIT tree and submit
>>them either via e-mail or ask the gatekeeper to pull directly from your
>>tree (assuming that you only push those patches that need to be merged).
>>Doing a 'stg pull' would retrieve the latest changes from the mainline
>>kernel (including the changes made by your patches which were merged
>>upstream).
>
> If I uderstand correctly you never commit patches from StGIT stack directly
> in your base git repository, in this example git HEAD, but you always round 
> trip to MAIN.

One usually doesn't maintain MAIN. That's an example for the Linux
kernel development where you can't control what get merged into MAIN.

There is a bit of confusion here since you said in a previous e-mail
that more people can commit to the stable branch. In this case, you
would need a separate repository for stable with a maintainer pulling
changes from others.

> Then you don't have two git repository: HEAD and MAIN
>
> Infact there is only one git repository, MAIN, cloned on your box
> and called HEAD and with a StGIT stack added on top.

The StGIT usage idea is that you only know what patches you have on
top of a main repository. Since you expect your patches to be merged
upstream or just updated every time the main repository changes, it
might not make sense to commit the patches onto the base.

If you want to keep a stable branch (and only you comitting to it), I
would recommend having separate branches for stable and development in
the same tree (and avoid having separate trees) rather than directly
modifying the base. StGIT doesn't support this directly (didn't think
anyone would ask) but you can do the following steps:

1. Use 'stg clone <remote repository>' to create the initial
   clone. The 'master' branch will be used for development. You can
   use 'git-init-db' and 'stg init' if you don't follow a remote
   repository

2. 'git checkout -b stable' will create the stable branch. This will
   initially be the same as the master one since there are not patches
   applied to the master stack

3. switch back to the devel branch with 'git checkout master' and do
   the normal StGIT development (create patches, commit them etc.). If
   you are tracking a remote respository, you could pull the latest
   changes with 'stg pull'

4. Once you have a set of patches applied and your stack is stable
   (some patches can be unapplied, they don't affect the head of the
   development branch), you can switch to the stable branch with 'stg
   checkout stable' and merge the changes in master with
   'git-resolve-script'.

   I think it might make more sense to simply do a 'cp
   .git/refs/heads/master .git/refs/heads/stable' instead of the
   previous paragraph since the stable branch doesn't have additional
   data from what's in master. The remote repository tracking is done
   via master.

5. You can advance the base of the stack to what's in stable with an
   'stg pull stable' but it's not clear for me whether this makes any
   sense since you lose the StGIT patches already added to stable and
   you will might later get conflicts when pulling the changes from
   the remote repository you are tracking.

For the 2, 3 and 4 steps above I will add a 'snapshot' command to
StGIT but I'm not sure why one would want step 5 since this would mean
that the devel branch needs to track both the remote repository and
the stable branch.

Some questions: do you track a remote repository? Do you need a stable
repository or branch where more people can update? If you track the
remote repository, do you want the latest remote changes merged into
the stable branch directly (i.e. is the stable branch tracking the
remote repository)?

I need a bit more clarification about your work flow.

-- 
Catalin