git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: "Sam Vilain" <sam@vilain.net>, "Petr Baudis" <pasky@suse.cz>,
	"Chuck Lever" <cel@citi.umich.edu>,
	"Karl Hasselström" <kha@treskal.com>,
	"Catalin Marinas" <catalin.marinas@gmail.com>,
	git@vger.kernel.org
Subject: Re: [ANNOUNCE] pg - A patch porcelain for GIT
Date: Wed, 15 Feb 2006 14:45:35 -0500	[thread overview]
Message-ID: <20060215194535.GA22007@fieldses.org> (raw)
In-Reply-To: <20060215065411.GB26632@spearce.org>

On Wed, Feb 15, 2006 at 01:54:11AM -0500, Shawn Pearce wrote:
> "J. Bruce Fields" <bfields@fieldses.org> wrote:
> > On Tue, Feb 14, 2006 at 07:35:10PM -0500, Shawn Pearce wrote:
> > > Publishing a repository with a stg (or pg) patch series isn't
> > > a problem; the problem is that no clients currently know how to
> > > follow along with the remote repository's patch series.  And I can't
> > > think of a sensible behavior for doing so that isn't what git-core is
> > > already doing today for non patch series type clients (as in don't go
> > > backwards by popping but instead by pushing a negative delta).  :-)
> > 
> > If you represent each patch as a branch, with each modification to the
> > patch a commit on the corresponding branch, and each "push" operation a
> > merge from the branch corresponding to the previous patch to a branch
> > corresponding to the new patch (isn't that what pg's trying to do?),
> > then it should be possible just to track the branch corresponding to the
> > top patch.
> 
> Yes that's pg in a nutshell.
> 
> But what happens when I pop back two patches (of three) and then push
> down a different (fourth) patch?  The tree just rewound backwards
> and then forwards again in a different direction.

So you've got p1, p2, and p3 applied, each with its corresponding
branch--respectively, b1, b2, and b3.  Popping two patches just checks
out b1, and doesn't affect the repository at all.  If you push a new
patch, p4, you've just created a new branch, b4--you haven't touched the
existing branches.  If you push p2 and p3 back on, you're just merging
the new changes from b4 into b2 and then merging the newly merged b2
into b3.

>From the point of view of someone tracking b3, this is all fine.  OK,
maybe it's excessively complicated, but pulls should work, because it
never sees history diseappear as it does when you represent each patch
with a commit on a single branch.

> > If you really want revision control on patches the simplest thing might
> > be just to run quilt or Andrew Morton's scripts on top of a git
> > repository--the documentation with Andrew's scripts recommends doing
> > that with CVS.
> 
> True but you also then run into problems about needing to know which
> base each patch revision was applied against so you can reproduce
> a source tree plus patch at a specific point in time.

Right, so you keep the tree under revision control as well as the
patches.

--b.

  reply	other threads:[~2006-02-15 19:45 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-10 19:59 [ANNOUNCE] pg - A patch porcelain for GIT Shawn Pearce
2006-02-10 20:41 ` Greg KH
2006-02-10 21:04   ` Shawn Pearce
2006-02-10 23:20     ` Greg KH
2006-02-10 21:17 ` Petr Baudis
2006-02-10 21:38   ` Shawn Pearce
2006-02-10 21:47     ` Petr Baudis
2006-02-10 22:07       ` Junio C Hamano
2006-02-13 21:00   ` Petr Baudis
2006-02-14  9:26     ` Catalin Marinas
2006-02-14 10:08       ` Karl Hasselström
2006-02-14 15:22         ` Chuck Lever
2006-02-14 16:07           ` Karl Hasselström
2006-02-14 20:58             ` Chuck Lever
2006-02-14 22:29               ` Petr Baudis
2006-02-15  0:22                 ` Sam Vilain
2006-02-15  0:35                   ` Shawn Pearce
2006-02-15  1:14                     ` Petr Baudis
2006-02-15  4:11                     ` J. Bruce Fields
2006-02-15  6:54                       ` Shawn Pearce
2006-02-15 19:45                         ` J. Bruce Fields [this message]
2006-02-16 10:24                         ` Junio C Hamano
2006-02-16 10:33                           ` Catalin Marinas
2006-02-16 10:42                             ` Fernando J. Pereda
2006-02-16 10:52                               ` Junio C Hamano
2006-02-16 11:10                                 ` Catalin Marinas
2006-02-15 17:25                 ` Catalin Marinas
2006-02-16  7:54                   ` Karl Hasselström
2006-02-17  4:27                   ` [PATCH 0/2] stg uncommit Karl  Hasselström
2006-02-17  4:31                     ` [PATCH 1/2] Update .git/refs/heads/base after patch deletion Karl  Hasselström
2006-02-17  4:31                     ` [PATCH 2/2] Add 'stg uncommit' command Karl  Hasselström
2006-02-19 10:51                       ` Catalin Marinas
2006-02-19 13:45                         ` Karl Hasselström
2006-02-19 14:47                           ` Karl Hasselström
2006-02-19 21:15                             ` Sam Vilain
2006-02-20 17:20                             ` Catalin Marinas
2006-02-20 17:30                               ` Karl Hasselström
2006-02-20 22:49                                 ` Catalin Marinas
2006-02-21  7:55                                   ` Karl Hasselström
2006-02-15 10:11               ` [ANNOUNCE] pg - A patch porcelain for GIT Karl Hasselström
2006-02-15 10:42                 ` Andreas Ericsson
2006-02-15 11:25                   ` Karl Hasselström
2006-02-15 11:27                     ` Karl Hasselström
2006-02-17 21:57     ` Catalin Marinas
2006-02-13  2:49 ` Sam Vilain
2006-02-13  3:29   ` Shawn Pearce
2006-02-13  4:40     ` Sam Vilain
2006-02-13  6:03       ` Shawn Pearce
2006-02-13 14:40 ` Catalin Marinas
2006-02-14  4:56   ` Shawn Pearce
2006-02-14  6:14     ` Shawn Pearce
2006-02-15 17:20       ` Catalin Marinas
2006-02-15 17:12     ` Catalin Marinas
2006-02-15 17:55       ` Shawn Pearce

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=20060215194535.GA22007@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=catalin.marinas@gmail.com \
    --cc=cel@citi.umich.edu \
    --cc=git@vger.kernel.org \
    --cc=kha@treskal.com \
    --cc=pasky@suse.cz \
    --cc=sam@vilain.net \
    /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).