Stacked GIT 0.1 (a.k.a. quilt for git)

Stacked GIT 0.1 (a.k.a. quilt for git)

[Catalin Marinas]

StGIT is a Python application providing similar functionality to quilt
(i.e. pushing/poping patches to a stack) on top of git. These
operations are performed using the git merge algorithms. StGIT also
allows working with the standard repository commands without having
any patch on the stack (though not all the expected functionality is
implemented yet - see the TODO file in the archive).

The project page is at http://www.procode.org/stgit/

Below is a cut&paste of the README file in the archive.

Catalin



Basic Operations
----------------

For a full list of commands:

	stg help

For help on individual commands:

	stg <cmd> (-h | --help)

To initialise a tree:

	stg init

If there already is a .git directory, it only creates the
.git/patches/ infrastructure. Otherwise, it creates the whole .git
directory structure and imports the existing files.

To commit changes:

	stg commit

To add/delete files:

	stg add [<file>*]
	stg rm [<file>*]

To inspect the tree status:

	stg status

To get a diff between 2 revisions:

	stg diff [-r rev1[:[rev2]]]

A revision name can be of the form '([patch]/[bottom | top]) | <tree-ish>'
If the patch name is not specified but '/' is passed, the topmost
patch is considered. If neither 'bottom' or 'top' follows the '/', the
whole patch diff is displayed (this does not include the local
changes).

Note than when the first patch is pushed to the stack, the current
HEAD is saved in the .git/refs/heads/base file for easy reference.

To create/delete a patch:

	stg new <name>
	stg delete [<name or topmost>]

The 'new' command also sets the topmost patch to the newly created
one.

To push/pop a patch to/from the stack:

	stg push [<name or first unapplied>]
	stg pop [<name or topmost>]

Note that the 'push' command can apply any patch un the unapplied
list. This is useful if you want to reorder the patches.

To inspect the patches applied:

	stg series
	stg applied
	stg unapplied
	stg top

To export a patch series:

	stg export [<dir-name or 'patches'>]

The 'export' command supports options to automatically number the
patches (-n) or add the '.diff' extension (-d).

StGIT does not yet provide support for cloning or pulling changes from
a different repository. Until this becomes available, run the
following commands:

	stg pop -a
	your-git-script-for-pulling-and-committing
	stg push -a

If you forget to pop the patches, the changes will be included in the
topmost patch. StGIT gives a warning on the first commit or patch
operation and you can revert the changes. If this was the intended
behaviour, you either commit the changes with 'stg commit' or do a
'stg refresh' command to synchronise the top of the patch with the
current HEAD.

You can also look in the TODO file for what's planned to be
impelmented in the future.


Directory Structure
-------------------

.git/
  objects/
    ??/

refs/
  heads/
    master		- the master commit id
    base		- the bottom id of the stack (to get a big diff)
    ...
  tags/
    ...
  branches/
    ...
  patches/
    applied		- list of applied patches
    unapplied		- list of not-yet applied patches
    current		- name of the topmost patch
    patch1/
      first		- the initial id of the patch (used for log)
      bottom		- the bottom id of the patch
      top		- the top id of the patch
    patch2/
    ...

HEAD			-> refs/heads/<something>


A Bit of StGIT Patch Theory
---------------------------

We assume that a patch is a diff between two nodes - bottom and top. A
node is a commit SHA1 id or tree SHA1 id in the GIT terminology:

P - patch
N - node

P = diff(Nt, Nb)

	Nb - bottom (start) node
	Nt - top (end) node
	Nf - first node (for log generation)

For an ordered stack of patches:

P1 = diff(N1, N0)
P2 = diff(N2, N1)
...

Ps = P1 + P2 + P3 + ... = diff(Nst, Nsb)

	Ps  - the big patch of the whole stack
	Nsb - bottom stack node (= N0)
	Nst - top stack node (= Nn)

Applying (pushing) a patch on the stack (Nst can differ from Nb) is
done by diff3 merging. The new patch becomes:

P' = diff(Nt', Nb')
Nb' = Nst
Nt' = diff3(Nst, Nb, Nt)

(note that the diff3 parameters order is: branch1, ancestor, branch2)

The above operation allows easy patch re-ordering.

Removing (popping) a patch from the stack is done by simply setting
the Nst to Nb.

Re: Stacked GIT 0.1 (a.k.a. quilt for git)

[Daniel Barkalow]

On Thu, 16 Jun 2005, Catalin Marinas wrote:

> StGIT is a Python application providing similar functionality to quilt
> (i.e. pushing/poping patches to a stack) on top of git.

It might be worth making the system work for having multiple series in the
same tree. You could do this by saving the base commit for
.git/refs/heads/<name> as .git/refs/bases/<name>, and putting patches in
.git/patches/<name>/. Some people do a lot with
.git/refs/heads/something; I, at least, symlink .git/HEAD to whichever one
I'm using, so that might be the right way to tell what the user is doing.

I think it would worth exploring defining a git type for patches and
storing the patches inside git as well. Then a commit could identify the
patch it applies (when it is from applying a patch), and a rebased patch
could reference the patch it replaces, and then (with a certain amount of
handwaving of implementation) the system could notice when the patch
you're pushing got applied upstream. Or, at least, git could avoid 
throwing away the history information when it goes through patches. I keep
thinking that this would be an important feature, but I haven't got the
familiarity with quilt to know how it should work.

	-Daniel
*This .sig left intentionally blank*

Re: Stacked GIT 0.1 (a.k.a. quilt for git)

[Jon Seymour]

> 
> I think it would worth exploring defining a git type for patches and
> storing the patches inside git as well. Then a commit could identify the
> patch it applies (when it is from applying a patch), and a rebased patch
> could reference the patch it replaces, and then (with a certain amount of
> handwaving of implementation) the system could notice when the patch
> you're pushing got applied upstream. Or, at least, git could avoid
> throwing away the history information when it goes through patches. I keep
> thinking that this would be an important feature, but I haven't got the
> familiarity with quilt to know how it should work.
> 

I also think it would be good if patches extracted from git
repositories included some information about exactly where the patch
was extracted from...something like...



signed-off-by: Name <user@host.domain>
---
commit: sha1 -> sha1
tree: sha1 -> sha1

The reason for including the commits is to allow the maintainer to
track exactly where the a given rev of a patch was from. The reason
for including the treeids is to allow appliers to verify that the
patch has produced the same result as the patch submitter.

Re: Stacked GIT 0.1 (a.k.a. quilt for git)

[Catalin Marinas]

Jon Seymour <jon.seymour@gmail.com> wrote:
> I also think it would be good if patches extracted from git
> repositories included some information about exactly where the patch
> was extracted from...something like...
>
> signed-off-by: Name <user@host.domain>
> ---
> commit: sha1 -> sha1
> tree: sha1 -> sha1
>
> The reason for including the commits is to allow the maintainer to
> track exactly where the a given rev of a patch was from. The reason
> for including the treeids is to allow appliers to verify that the
> patch has produced the same result as the patch submitter.

See my (long) reply to Daniel. A StGIT patch is a collection of git
commits, mixed in time with commits for other patches. There might not
be a single author. For example, I create a patch called
'stabilisation' where I gather different git changesets from different
authors and commit them one by one.

I think what you mean is similar to the cg-mkpatch command. The 'stg
export' is totally different. While it might be possible to generate a
set of changesets for a StGIT patch, this is not intended for the near
future.

-- 
Catalin

Re: Stacked GIT 0.1 (a.k.a. quilt for git)

[Catalin Marinas]

Daniel,

Thanks for your feedback.

Daniel Barkalow <barkalow@iabervon.org> wrote:
> It might be worth making the system work for having multiple series in the
> same tree. You could do this by saving the base commit for
> .git/refs/heads/<name> as .git/refs/bases/<name>, and putting patches in
> .git/patches/<name>/. Some people do a lot with
> .git/refs/heads/something; I, at least, symlink .git/HEAD to whichever one
> I'm using, so that might be the right way to tell what the user is
> doing.

Having different series would be a good idea but it might complicate
the tool usage. I will thing about it once I'm sure the basic
operations work fine.

Before commenting further on your or Jon's e-mail, I want to clarify
how I think this tool should be used (this might be misunderstood if
someone never used quilt before). First of all, a StGIT patch is a
collection of git commits. This tool *doesn't* remove or modify git
changesets.

Quilt or StGIT are intended for people maintaining their own (big)
patch on top of the Linux kernel. I will take the example of Con
Kolivas' kernel. His big patch for the -ck kernel is at
http://ck.kolivas.org/patches/2.6/2.6.12-rc6/2.6.12-rc6-ck2/patch-2.6.12-rc6-ck2.diff.bz2.
This big patch is provided mainly for the convenience of the people
wanting to test this kernel. If you want to get deeper into this
patch, you can get it split in several smaller patches
(http://ck.kolivas.org/patches/2.6/2.6.12-rc6/2.6.12-rc6-ck2/patches/).
This set of patches is called a 'series'. You even get a 'series' file
which defines the order in which the patches should be applied.

These patches in a series represent changes to different files grouped
after some criteria. Let's say you have 2 schedulers, you keep them in
2 separate patches. You can modify a scheduler and refresh
(re-generate) its patch with quilt or simply do a 'stg commit' with
StGIT and the change is taken into account for the topmost patch.

Note that the series might remain the same for a long time but the
patches it contains can change. When you want to upgrade the series of
patches to a new kernel version, with quilt or StGIT you pop all the
patches from the stack, upgrade the base (i.e. the mainline kernel)
and push the patches back onto the stack. You can have some of the
patches rejected in quilt or get merge conflicts with StGIT.

While you can simply use quilt patches on top of a git repository,
there are advantages in using StGIT:

- easier integration with a git repository with common commands like
  diff etc.

- there aren't separate commands for adding/removing files to/from the
  git repository and the StGIT patch since a StGIT patch is simply
  represented as two commit ids - the base (bottom) and the top of the
  patch (those familiar with quilt know what it means to modify a file
  without adding it first to the topmost patch)

- every time you commit some changes (with 'stg commit'), this
  changeset is added to the topmost patch on the stack (by replacing
  the top id of the patch with the new commit id). If you want to
  modify a patch, simply push/pop until it becomes the topmost one,
  make the changes and commit. All the commit history is preserved
  (unlike quilt where you update the patch with a 'refresh'
  command). With a future StGIT release you will be able to see the
  log for individual StGIT patches

- pushing a patch to the stack when the base changed is done by
  merging with a diff3 algorithm. I find this slightly superior to a
  simple 'patch -p1 < file.diff' (well, some people do not agree with
  this point)

> I think it would worth exploring defining a git type for patches and
> storing the patches inside git as well. Then a commit could identify the
> patch it applies (when it is from applying a patch), and a rebased patch
> could reference the patch it replaces, and then (with a certain amount of
> handwaving of implementation) the system could notice when the patch
> you're pushing got applied upstream. Or, at least, git could avoid 
> throwing away the history information when it goes through patches. I keep
> thinking that this would be an important feature, but I haven't got the
> familiarity with quilt to know how it should work.

I don't know whether this is still valid after clarifying the intended
use of StGIT. When a patch was merged upstream, the local push
operation should detect that the patch being pushed doesn't change
anything and, at this point, you can safely delete it.

-- 
Catalin

Re: Stacked GIT 0.1 (a.k.a. quilt for git)

[Daniel Barkalow]

On Sat, 18 Jun 2005, Catalin Marinas wrote:

> Having different series would be a good idea but it might complicate
> the tool usage. I will thing about it once I'm sure the basic
> operations work fine.

You could future-proof yourself a bit by simply saving the base as
.git/refs/bases/master and making the patches be
.git/patches/master/. That way, you'd be ready when you start to support
multiple series.

> Before commenting further on your or Jon's e-mail, I want to clarify
> how I think this tool should be used (this might be misunderstood if
> someone never used quilt before). First of all, a StGIT patch is a
> collection of git commits. This tool *doesn't* remove or modify git
> changesets.

(snip)

Okay; this fits what I thought quilt and StGIT did. 

An aside:

> - pushing a patch to the stack when the base changed is done by
>   merging with a diff3 algorithm. I find this slightly superior to a
>   simple 'patch -p1 < file.diff' (well, some people do not agree with
>   this point)

diff3 is clearly superior to patch in how effective it is; the
disagreement is only over how useful the output format is. But diff3 gets
all the information that patch gets, plus more, so it would have to be
buggy if it did worse, aside from by patch getting lucky. (Also, patch can
be used in situations where diff3 couldn't, due to having no known common
ancestor). IIRC, diff3 can generate .rej files if you tell it to, rather
than reporting conflicts inline.

> I don't know whether this is still valid after clarifying the intended
> use of StGIT. When a patch was merged upstream, the local push
> operation should detect that the patch being pushed doesn't change
> anything and, at this point, you can safely delete it.

If you're lucky, it will generate only a warning that changes are present
in both trees, the push will have no effect, and StGIT can determine that
the rebased patch is now empty. But consider this situation:

You have three patches stacked on a base.

The mainline takes a patch from somewhere else, then the first of your
patches, then a second patch from somewhere else. The last of these is
based on your first patch (or on mainline after your patch went in).

Then you update.

When you try to push your first patch, merge sees the common base, your
change, and the current mainline. There is no way to tell, from the
information available, that the correct merge is to ignore your change in
favor of mainline's version; the program only sees that there were two
different changes to the same area. The information which would resolve
this were patches not used would be that there was a mainline commit that
merged your first patch; the left side of the merge is an ancestor of the
right side, so the merge is the right side. My goal is to get the same
information into the system so it can reach the same conclusion when
patches are used.

Note that it gets more complex if mainline takes only your second patch
(due to it not requiring your first, and your first not being as
acceptable). In this case, it needs to entire mainline as a patch, because
merges can't cherrypick, whereas patches can act arbitrarily. But it would
be nice to store the information of what happened even with patches that
cherrypick, such that we have a better chance for managing things later.

The above situation is not actually particular to StGIT or quilt; any case
where something gets exported as a patch and applied to a different base
has this problem. But I think that you have the right ideas about how
patches should be represented, and it would be good to get your
representation implemented inside git, because operations more central to
git would benefit from having this information.

	-Daniel
*This .sig left intentionally blank*

Re: Stacked GIT 0.1 (a.k.a. quilt for git)

[Catalin Marinas]

Daniel Barkalow <barkalow@iabervon.org> wrote:
> On Sat, 18 Jun 2005, Catalin Marinas wrote:
>> Having different series would be a good idea but it might complicate
>> the tool usage. I will thing about it once I'm sure the basic
>> operations work fine.
>
> You could future-proof yourself a bit by simply saving the base as
> .git/refs/bases/master and making the patches be
> .git/patches/master/. That way, you'd be ready when you start to support
> multiple series.

You are right. I will do this for the next release (0.2, probably of
the end of this week), something like the tree structure below:

.git/refs/bases/<head>
.git/series/<head>/
.git/series/<head>/applied
.git/series/<head>/unapplied
.git/series/<head>/current
.git/series/<head>/patches/*

I don't know whether a git-diff-* command would look into
.git/refs/bases (I can do this in stgit but, this was only for
convenience).

[...]
> Note that it gets more complex if mainline takes only your second patch
> (due to it not requiring your first, and your first not being as
> acceptable). In this case, it needs to entire mainline as a patch, because
> merges can't cherrypick, whereas patches can act arbitrarily. But it would
> be nice to store the information of what happened even with patches that
> cherrypick, such that we have a better chance for managing things
> later.

You can cherry-pick the second patch by first commuting it with the
previous patches. If they are independent, the commuting via diff3
wouldn't generate any conflict. Even with the current stgit, you can
pop all the patches and only push those to be merged upstream. HEAD
would only contain the those patches.

If you want to implement a full-featured patch treacking, you might
end up with something like darcs which doesn't scale to the size of
the Linux kernel. On the other hand, you might not agree with the
changes to your accepted patch and a conflict is welcomed so that you
can choose whether to keep the old version or not.

> But I think that you have the right ideas about how
> patches should be represented, and it would be good to get your
> representation implemented inside git, because operations more central to
> git would benefit from having this information.

Do you mean creating a new git type like the blob, tree or commit? I
would prefer not to modify git or have my own version of git. StGIT
should be a tool running directly on top of an existing installation
of git.

Instead of having a directory for every patch (with bottom, top
etc. files), I could create a git blob to store this information and
the series files (applied/unapplied files) would only contain the blob
id. This could simplify things if, in a future version, stgit would
allow patch cherry-picking.

-- 
Catalin

Re: Stacked GIT 0.1 (a.k.a. quilt for git)

[Paul Jackson]

Interesting idea.  Thanks.

I am just firing it up now - noticing a couple of nits:

 1) "Unknown" is misspelled as "Unkown" in a couple places.

 2) I tried doing an "stg init" in the stgit subtree that I had
    just unpacked and installed (python setup.py install).  This
    did several lines of "Adding ..." and then displayed the
    number "16" and sat there.  I typed some random guesses at
    it, and realized I was inside my $EDITOR=/bin/ed.

    Before invoking an editor, it would be a good idea to tell the
    user you are doing so.  If someone is on a telnet session to
    a system with their $DISPLAY set wrong, they might not even
    get the terse "16" clue that I got, that they are editing
    something.

 3) My editor 'ed' exits with non-zero status if I make even the most
    trivial editing error.  This resulted in this "stg init" failing
    with:
	stg init: Editor (ed .commitmsg) failed
    I'd recommend ignoring the exit status of externally invoked
    editors.

 4) I tried rerunning that "stg init" without further ado, and it
    failed again (due to the incomplete init above, no doubt), with:

	Traceback (most recent call last):
	  File "/usr/bin/stg", line 25, in ?
	    main()
	  File "/usr/lib/python2.4/site-packages/stgit/main.py", line 557, in main
	    command.func(parser, options, args)
	  File "/usr/lib/python2.4/site-packages/stgit/main.py", line 91, in init
	    stack.init()
	  File "/usr/lib/python2.4/site-packages/stgit/stack.py", line 187, in init
	    patch_dir = get_patch_dir()
	  File "/usr/lib/python2.4/site-packages/stgit/stack.py", line 36, in get_patch_dir
	    return os.path.join(git.base_dir, 'patches', git.get_head_file())
	  File "/usr/lib/python2.4/posixpath.py", line 60, in join
	    if b.startswith('/'):
	AttributeError: 'NoneType' object has no attribute 'startswith'

 5) I tried again, doing:

	rm -fr .git
	stg init
	# on the commit message edit - just quit 'q', to avoid any error exit

    This failed again, leaving my new git tree in god only knows what bogus state.
    It failed with:

	stg init: Commit message not modified

    I'm getting a little frustrated by now.  Guess I will just nuke the .git subtree
    and try again, as I have no clue what useful or bogus state this left me in.

    Try generating fewer fatal errors, and try giving a tiny clue what state (ok or
    not or how bad) one is left in after an apparently fatal error, and for extra
    credit, a clue what to do next.

 6) Ok - got through the init that time.

Since I am fond of both quilt and Python, and since I need to be using git and/or cogito,
I will poke around some more with this - it's promising.

I see something about a patch emailer on the todo list -- you're welcome to make use of
my patch emailer (I use with quilt, though it's not tightly bound to quilt) at:

  http://www.speakeasy.org/~pj99/sgi/sendpatchset

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.925.600.0401

Re: Stacked GIT 0.1 (a.k.a. quilt for git)

[Catalin Marinas]

Hi Paul,

Thanks for trying it. As a note, for the moment you should try the
latest daily snapshot since it contains less bugs than the main
(alpha) releases.

Paul Jackson <pj@sgi.com> wrote:
>  1) "Unknown" is misspelled as "Unkown" in a couple places.

Thanks.

>     Before invoking an editor, it would be a good idea to tell the
>     user you are doing so.  If someone is on a telnet session to
>     a system with their $DISPLAY set wrong, they might not even
>     get the terse "16" clue that I got, that they are editing
>     something.

Done.

>     I'd recommend ignoring the exit status of externally invoked
>     editors.

OK, fixed.

>  4) I tried rerunning that "stg init" without further ado, and it
>     failed again (due to the incomplete init above, no doubt), with:
>
[...]
> 	AttributeError: 'NoneType' object has no attribute
> 	'startswith'

The problem here is that the .git/HEAD link is not valid if init
failed. I will fix it for the tonight's snapshot.

>  5) I tried again, doing:
>
> 	rm -fr .git
> 	stg init
> 	# on the commit message edit - just quit 'q', to avoid any error exit
>
>     This failed again, leaving my new git tree in god only knows what bogus state.
>     It failed with:
>
> 	stg init: Commit message not modified

I can remove this condition for init only. The problem is that if it
no longer exists on an non-zero editor exit status, it should at least
check whether the commit message was modified.

>     Try generating fewer fatal errors, and try giving a tiny clue
>     what state (ok or not or how bad) one is left in after an
>     apparently fatal error, and for extra credit, a clue what to do
>     next.

I will try to add as much as information as possible. I initially
wanted to get something working and be able to push/pop patches. I
haven't tried the init command with different editors etc.

>  6) Ok - got through the init that time.

Good.

> Since I am fond of both quilt and Python, and since I need to be
> using git and/or cogito,
> I will poke around some more with this - it's promising.

Great. Pushing/popping works fine at the moment with my kernel tree
(but with less than 10 patches on the stack). It even detected when
the patches I submitted were merged upstream.

The next thing on my plan a log command. I would like to be able to
preserve the history of a patch but this probably won't be available
in an upstream tree pulling from yours.

> I see something about a patch emailer on the todo list -- you're
> welcome to make use of my patch emailer (I use with quilt, though
> it's not tightly bound to quilt) at:
>
>   http://www.speakeasy.org/~pj99/sgi/sendpatchset

Thanks. I will try to include this in a future version.

-- 
Catalin

Re: Stacked GIT 0.1 (a.k.a. quilt for git)

[Paul Jackson]

> it should at least
> check whether the commit message was modified.

I suspect not.

Beware that quilt has tended toward the philosophy of doing just
what you said, with no more, perhaps less than, the minimum critical
consistency checking.  If you tried to shoot you foot off with it,
it shot your foot off, quickly.

If I try to make a change without a meaninguful log entry, what
business of stgit is that?  And it certainly should not leave the
tree in some unspecified, inconsistent state without prior warning
on account of such.

Don't add inessential sanity checks on user input.  It won't sell
well to the "quilt replacement" market.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.925.600.0401

Re: Stacked GIT 0.1 (a.k.a. quilt for git)

[Catalin Marinas]

Paul Jackson <pj@sgi.com> wrote:
>> it should at least
>> check whether the commit message was modified.
>
> I suspect not.
>
> Beware that quilt has tended toward the philosophy of doing just
> what you said, with no more, perhaps less than, the minimum critical
> consistency checking.  If you tried to shoot you foot off with it,
> it shot your foot off, quickly.
>
> If I try to make a change without a meaninguful log entry, what
> business of stgit is that?

The way to modify a patch with stgit is via 'stg commit'. The problem
is that you can end up with a commit log you didn't want simply
because the editor crashed or $EDITOR is invalid and there is no way
to modify the log history.

With stgit you don't have files only specific to a patch (the 'quilt
add' command equivalent is missing). When you modify a file and commit
the changes, it will be included in the topmost patch. IMO, this
simplifies the command set and avoids having two different add
commands (or a single add command with different behaviours). Now,
some people might not run a 'stg status' before a commit but they find
out from the commit msg that an unrelated file was modified. You could
simply exit without saving the commit msg and the changes won't be
checked in (and the tree is left in a consistent state - the one
before the commit).

Anyway, if you don't care about the commit history for individual
patches, I can simply remove all this commit/editor/msg check and just
use a standard text, maybe a description of the patch so that people
pulling from your git tree would know what it is about.

> And it certainly should not leave the
> tree in some unspecified, inconsistent state without prior warning
> on account of such.

'commit' failing doesn't leave the tree in an unspecified state (at
least not the yesterday's snapshot). There are other commands that do
this, unfortunately, but I'm still working on this.

> Don't add inessential sanity checks on user input.  It won't sell
> well to the "quilt replacement" market.

I'm not keen on keeping these sanity checks but see my reasons above
for the commit message. Anyway, I'm open to suggestions. The main
advantage of stgit over quilt is that it uses diff3 instead of patch
for pushing patches. For this to work properly, the top and bottom of
a patch have to be valid commit or tree objects containing the whole
tree even if most of the files are not modified by this patch.

-- 
Catalin

Re: Stacked GIT 0.1 (a.k.a. quilt for git)

[Paul Jackson]

> there is no way to modify the log history.

Aha.  If that means what I think it does, then I suspect I will remain
with quilt.  The per-patch comment is often about the last thing that
I put in the patch.

The special thing about quilt is that the patch set in every regard
is infinitely changeable - the selection and order of the patches,
the contents of the patches, and the comments and metadata associated
with the patch can all be edited trivially.

Quilt is not a change management system; it's a patch set composition
system.

That stgit is layered on git (a persistent data store), and that
it has something (the log history you mention above) that cannot
be modified, suggests that stgit is not a 'better quilt for git',
but some other sort of tool.

Good luck ;).


-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.925.600.0401

Re: Stacked GIT 0.1 (a.k.a. quilt for git)

[Catalin Marinas]

Paul Jackson <pj@sgi.com> wrote:
>> there is no way to modify the log history.
>
> Aha.  If that means what I think it does, then I suspect I will remain
> with quilt.  The per-patch comment is often about the last thing that
> I put in the patch.

I think you got it a bit wrong.

That was the initial idea. Anyway, in a future version you will have
one commit which is trackable via HEAD and which represents the whole
patch. This commit's log should always contain the patch description
so that people pulling your HEAD know what it is about.

If this is useful, a patch can have a second commit (or chain of
commits) refering to the same tree but not trackable via .git/HEAD but
which can be useful to track the individual changes of a patch. This
would be stored under .git/patches/<head>/<name>/ and not accessible
to anyone pulling the HEAD (well, rsync might bring the object but it
can be cleaned-up). This might be useful if you have a bigger patch
and want to track its changes, only internally.

Anyway, I think I won't implement this second commit handling and the
per-patch history would be trashed. Now I think I understand why you
mean by not caring about the commit message.

> The special thing about quilt is that the patch set in every regard
> is infinitely changeable - the selection and order of the patches,
> the contents of the patches, and the comments and metadata associated
> with the patch can all be edited trivially.

Almost all of this can be done with stgit. A patch in stgit is a just
a diff between 2 snapshots of the tree. The patch is indefinitely
changeable via commit. This weekend I will implement the proper commit
handling so that every new commit represents the whole patch and not
just the last modification.

You can easily reorder patches by popping all of them and pushing in a
different order. This is done via diff3 merging.

> Quilt is not a change management system; it's a patch set composition
> system.

I think the confusion comes from the fact that I wanted to put both
patch composition and change management in the same tool without a
clear separation.

> That stgit is layered on git (a persistent data store), and that
> it has something (the log history you mention above) that cannot
> be modified, suggests that stgit is not a 'better quilt for git',
> but some other sort of tool.

Again, the log history should only be internal, if useful, and not
visible to the outside world.

> Good luck ;).

Thanks. At least it is good that you tried it and provided some ideas
about what's needed as a quilt replacement. I will release a 0.3
version this weekend with the above things and you can try it.

-- 
Catalin

Re: Stacked GIT 0.1 (a.k.a. quilt for git)

[Catalin Marinas]

Paul Jackson <pj@sgi.com> wrote:
>> there is no way to modify the log history.
>
> Aha.  If that means what I think it does, then I suspect I will remain
> with quilt.  The per-patch comment is often about the last thing that
> I put in the patch.

OK, you convinced me :-). I will upload a new StGIT version tonight. I
removed the 'commit' command completely. To add changes into the
repository, you would use the 'refresh' command. There is only one git
commit object for each patch and they can be seen with tools like
cg-log on top of the stack base (i.e. the HEAD of the pulled tree).

There is no per-patch history anymore. The patch diff and information
(description, author name etc.) are indefinitely changeable via the
'refresh' command but only one commit with the latest information is
seen in the tree log for each patch.

To pull new changes from the master repository:

   stg pop -a
   cg-udpate (or whatever people use to pull and merge)
   stg push -a

The 'push' command re-bases all the commits corresponding to the StGIT
patches.

Does this make it closer to quilt in functionality?

-- 
Catalin

Re: Stacked GIT 0.1 (a.k.a. quilt for git)

[Paul Jackson]

Catalin wrote:
> Does this make it closer to quilt in functionality?

It could - right now I'm playing with Matt Mackall's Mercurial.  Sorry.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.925.600.0401