git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@gmail.com>
To: Marco Costalba <mcostalba@yahoo.it>
Cc: git@vger.kernel.org
Subject: Re: [RFC] Patches exchange is bad?
Date: Wed, 17 Aug 2005 22:27:55 +0100	[thread overview]
Message-ID: <1124314075.7130.49.camel@localhost.localdomain> (raw)
In-Reply-To: <20050817173522.14386.qmail@web26305.mail.ukl.yahoo.com>

On Wed, 2005-08-17 at 10:35 -0700, Marco Costalba wrote:
> Sorry if the answer is silly, but I still don't know well StGIT .

It's probably because there is no document really explaining the
concepts. The Quilt documentation would be a good starting point since
StGIT uses the same ideas but implemented on top if GIT instead of a
series of GNU diff files.

> What you describe it's an asymmetrical or one way scenario, new code 
> goes always from HEAD to MAIN. But how is the workflow if:

It is asymmetrical since HEAD uses StGIT and MAIN uses plain GIT but it
is a two way data flow: 'git pull HEAD' in MAIN and 'stg pull MAIN' in
HEAD.

> 1) There is more then one contributor feeding MAIN and you need to update 
> the StGIT patch stack from MAIN.

The base of the StGIT stack in the HEAD repository (branch) should
always be the head of the MAIN repository. You update it via the 'stg
pull' command, which takes care of updating the patches so that they are
seen as individual commits on top of the base.

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).

> 2) You made something terribly wrong with HEAD (I don't know what can be 
> 'terribly wrong') and you need to recreate a clean base from MAIN.
> 
> In this cases, if I understand correctly, you need to clone a new StGIT archive from 
> MAIN and push the interesting stuff from old/broken HEAD.

This is not clear for me. What do you mean by 'terribly wrong'? Broken
HEAD because of a bug in StGIT or GIT? Quite unlikely but in this case
the repository would be corrupt. I would recommend periodically doing a
'stg export' to keep the series of patches in GNU diff files.

If you refer to a patch which breaks the code, you can simply pop it
from the stack and even delete it with 'stg delete'. Popping it removes
the changes it makes to HEAD and the corresponding commit won't be seen
with 'git log'. You don't need to clone a new repository since StGIT
allows you to choose which of your patches (commits) are included in
HEAD (via 'stg push' and visible with 'stg applied').

> Or you can always merge back pulling from MAIN as in case of two pure git archives?

The base of the StGIT stack is identical to MAIN. Doing a 'stg pop -a'
makes the HEAD and MAIN identical.

Please let me know if this needs further clarification.

-- 
Catalin

  reply	other threads:[~2005-08-17 21:28 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-17 17:35 [RFC] Patches exchange is bad? Marco Costalba
2005-08-17 21:27 ` Catalin Marinas [this message]
2005-08-17 21:37   ` Johannes Schindelin
2005-08-18 10:27     ` Catalin Marinas
  -- strict thread matches above, loose matches on Subject: below --
2005-08-18 13:34 Marco Costalba
2005-08-18 13:41 ` Catalin Marinas
2005-08-18 10:00 Marco Costalba
2005-08-18 11:16 ` Catalin Marinas
2005-08-17 18:03 Marco Costalba
2005-08-17  8:27 Marco Costalba
2005-08-17  9:07 ` Martin Langhoff
2005-08-16 22:09 Marco Costalba
2005-08-16 22:45 ` Daniel Barkalow
2005-08-16 21:47 Marco Costalba
2005-08-16 20:01 Marco Costalba
2005-08-16 20:39 ` Johannes Schindelin
2005-08-16 21:02 ` Junio C Hamano
2005-08-16 21:31 ` Martin Langhoff
2005-08-17 17:12 ` Catalin Marinas

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=1124314075.7130.49.camel@localhost.localdomain \
    --to=catalin.marinas@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=mcostalba@yahoo.it \
    /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).