Git development
 help / color / mirror / Atom feed
From: Robin Rosenberg <robin.rosenberg.lists@dewire.com>
To: Josef Sipek <jsipek@fsl.cs.sunysb.edu>
Cc: "Michael S. Tsirkin" <mst@dev.mellanox.co.il>,
	Junio C Hamano <junkio@cox.net>,
	Catalin Marinas <catalin.marinas@arm.com>,
	git@vger.kernel.org, "Josef 'Jeff' Sipek" <jsipek@cs.sunysb.edu>
Subject: Re: using stgit/guilt for public branches
Date: Wed, 25 Apr 2007 23:37:05 +0200	[thread overview]
Message-ID: <200704252337.05851.robin.rosenberg.lists@dewire.com> (raw)
In-Reply-To: <20070425191838.GA6267@filer.fsl.cs.sunysb.edu>

onsdag 25 april 2007 skrev Josef Sipek:
> On Wed, Apr 25, 2007 at 03:20:49PM +0300, Michael S. Tsirkin wrote:
[...]
> > I am concerned that publishing a git branch managed by stg/guilt
> > would present problems: it seems that every time patches are re-ordered,
> > a patch is re-written or removed, or we update from upstream,
> > everyone who pulls the tree branch will have a hard-to-resolve conflict.
> > 
> > Is that really a problem? If so, would it be possible to work around this
> > somehow?
> 
> I thought about this problem a while back when I was trying to decide how to
> manage the Unionfs git repository. I came to the conclusion, that there was
> no clean way of doing this (at least not using guilt - I can't really speak
> for stgit, as I don't know how it does things exactly).

StGit has the same problem. Publishing such a branch is only for viewing if
you want to publish the tip, like the pu branch in the Git repo. You shouldn't
merge from pu either.

Patches your are done and not stored as patches anymore can be propagated 
to a "stable" branch using git branch -f stable HEAD~$(stg applied|wc -l) 
which is then pushed like  any other branch. Don't play the stg uncommit game 
too much to avoid a mess.

I'm  not sure the branch command is the best way, but you get the idea.

-- robin

  parent reply	other threads:[~2007-04-25 21:37 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-25 12:20 using stgit/guilt for public branches Michael S. Tsirkin
2007-04-25 19:18 ` Josef Sipek
2007-04-25 19:52   ` Michael S. Tsirkin
2007-04-25 20:40     ` Josef Sipek
2007-04-25 21:37   ` Robin Rosenberg [this message]
2007-05-03 20:58     ` Yann Dirson
2007-05-03 23:10       ` Robin Rosenberg
2007-05-03 23:31         ` Robin Rosenberg
2007-05-04 21:28           ` Yann Dirson
2007-05-04  5:20       ` Michael S. Tsirkin
2007-05-04 21:37         ` Yann Dirson
2007-05-04 23:12       ` Yann Dirson

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=200704252337.05851.robin.rosenberg.lists@dewire.com \
    --to=robin.rosenberg.lists@dewire.com \
    --cc=catalin.marinas@arm.com \
    --cc=git@vger.kernel.org \
    --cc=jsipek@cs.sunysb.edu \
    --cc=jsipek@fsl.cs.sunysb.edu \
    --cc=junkio@cox.net \
    --cc=mst@dev.mellanox.co.il \
    /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