# StGit question

6 messages from 2008-09-11 to 2008-09-12. Participants: Clark Williams, Karl Hasselström, Catalin Marinas.
Thread: https://gitlist.dev/t/15491

## Clark Williams, 2008-09-11 17:04

Subject: StGit question
Message-ID: <48C94F86.6080707@gmail.com>
URL: https://gitlist.dev/e/48C94F86.6080707%40gmail.com

```
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Are there any guidelines or best-practices for sharing StGit trees?

I'm working with the Linux -rt patchset and I need to be able to share my tree with
other people. What I'd *like* to do is push git tree's up to a git server, let other
people fetch them and have them be able to 'stg uncommit' to get back to my stack
state. The problem is that when someone uncommits, you lose the patch names.  If
you're trying to create an RPM out of a stack, this causes problems :).

Is there something I can do or something that we can do to StGit to make it possible
for an 'uncommit' to restore the original patch name? It looks like I could modify
the commit message, so that the first line is the patch name, but that's not very
nice for people scanning commits.

Or am I missing something completely trivial that will make my life easier?

Thanks,
Clark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkjJT4UACgkQqA4JVb61b9d1tgCfeVNG1BkaZ9czZpeHrFumU+xW
3/kAnj307N0Wx5nLSmtIPr5d+UetAxEG
=uol3
-----END PGP SIGNATURE-----

```

## Karl Hasselström, 2008-09-12 07:51

Subject: Re: StGit question
Message-ID: <20080912075116.GA26685@diana.vm.bytemark.co.uk>
URL: https://gitlist.dev/e/20080912075116.GA26685%40diana.vm.bytemark.co.uk
In-Reply-To: <48C94F86.6080707@gmail.com>

```
On 2008-09-11 12:04:06 -0500, Clark Williams wrote:

> Are there any guidelines or best-practices for sharing StGit trees?

See below. ;-)

> I'm working with the Linux -rt patchset and I need to be able to
> share my tree with other people. What I'd *like* to do is push git
> tree's up to a git server, let other people fetch them and have them
> be able to 'stg uncommit' to get back to my stack state. The problem
> is that when someone uncommits, you lose the patch names. If you're
> trying to create an RPM out of a stack, this causes problems :).
>
> Is there something I can do or something that we can do to StGit to
> make it possible for an 'uncommit' to restore the original patch
> name? It looks like I could modify the commit message, so that the
> first line is the patch name, but that's not very nice for people
> scanning commits.
>
> Or am I missing something completely trivial that will make my life
> easier?

You've probably already found this and dismissed it, but

  $ stg uncommit foo bar baz woo wee aaahh

will uncommit six patches and give them those names. So if you just
share the output of

  $ stg series --applied --noprefix

along with your branch, the other end will be able to recreate a
series with the same names. (In not-quite-bleeding-edge stg's, "series
--applied" is spelled "applied".)

As for merging your work once both of you have made changes to the
series, the current solution is "stg sync", which you'll have to ask
Catalin about. The patch stack log in my experimental branch is
designed to allow for true 3-way merging of patch series, so that
you'd be able to get your colleague's latest modifications with a
simple "stg merge" command, but that merge currently exists only in a
couple of mails to this list -- there isn't even a prototype
implementation -- so I expect you'll have more luck with "stg sync"
right now ...

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle

```

## Clark Williams, 2008-09-12 12:41

Subject: Re: StGit question
Message-ID: <48CA6367.9020300@gmail.com>
URL: https://gitlist.dev/e/48CA6367.9020300%40gmail.com
In-Reply-To: <20080912075116.GA26685@diana.vm.bytemark.co.uk>

```
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Karl Hasselström wrote:
> On 2008-09-11 12:04:06 -0500, Clark Williams wrote:
> 
>> Are there any guidelines or best-practices for sharing StGit trees?
> 
> See below. ;-)
> 
>> I'm working with the Linux -rt patchset and I need to be able to
>> share my tree with other people. What I'd *like* to do is push git
>> tree's up to a git server, let other people fetch them and have them
>> be able to 'stg uncommit' to get back to my stack state. The problem
>> is that when someone uncommits, you lose the patch names. If you're
>> trying to create an RPM out of a stack, this causes problems :).
>>
>> Is there something I can do or something that we can do to StGit to
>> make it possible for an 'uncommit' to restore the original patch
>> name? It looks like I could modify the commit message, so that the
>> first line is the patch name, but that's not very nice for people
>> scanning commits.
>>
>> Or am I missing something completely trivial that will make my life
>> easier?
> 
> You've probably already found this and dismissed it, but
> 
>   $ stg uncommit foo bar baz woo wee aaahh
> 
> will uncommit six patches and give them those names. So if you just
> share the output of
> 
>   $ stg series --applied --noprefix
> 
> along with your branch, the other end will be able to recreate a
> series with the same names. (In not-quite-bleeding-edge stg's, "series
> --applied" is spelled "applied".)


Ahhhh, no I hadn't found this. Cool! I wonder if I could save the series in the
branch, so that someone could just checkout the branch and do:

$ stg uncommit $(cat stg-series)

Or, maybe I'll look at adding a --series or --file option to uncommit?

I suspect some chicken-and-egg problems here, but this is workable. And when you're
talking >500 patches, anything you can do to automate is a wonderful thing :).

> 
> As for merging your work once both of you have made changes to the
> series, the current solution is "stg sync", which you'll have to ask
> Catalin about. The patch stack log in my experimental branch is
> designed to allow for true 3-way merging of patch series, so that
> you'd be able to get your colleague's latest modifications with a
> simple "stg merge" command, but that merge currently exists only in a
> couple of mails to this list -- there isn't even a prototype
> implementation -- so I expect you'll have more luck with "stg sync"
> right now ...
> 

Most of the time it's not more than one or two patches difference, so I think that it
can be handled manually for now. I'll definitely keep an eye on sync and merge though...

Thanks,
Clark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkjKY2cACgkQqA4JVb61b9cVYgCfZE8//UgP11+D3AKMCsDGN8Qs
KpsAni8gLlZn088lQr/1nbzQf4uKHxn/
=A6MK
-----END PGP SIGNATURE-----

```

## Karl Hasselström, 2008-09-12 15:40

Subject: Re: StGit question
Message-ID: <20080912154036.GC31240@diana.vm.bytemark.co.uk>
URL: https://gitlist.dev/e/20080912154036.GC31240%40diana.vm.bytemark.co.uk
In-Reply-To: <48CA6367.9020300@gmail.com>

```
On 2008-09-12 07:41:11 -0500, Clark Williams wrote:

> Ahhhh, no I hadn't found this. Cool! I wonder if I could save the
> series in the branch, so that someone could just checkout the branch
> and do:
>
>   $ stg uncommit $(cat stg-series)

The patch stack log contains all the required info, so this should be
doable (given that you share your <branchname>.stgit branch, which is
the patch stack log).

> Or, maybe I'll look at adding a --series or --file option to
> uncommit?

Sure, that sounds like a good idea. I believe there are existing
commands that take a series file argument; check what they call their
flag.

> I suspect some chicken-and-egg problems here, but this is workable.
> And when you're talking >500 patches, anything you can do to
> automate is a wonderful thing :).

Nice to know StGit is being used with series of that size. I usually
never go beyond about 30 myself, so there are certain types of
scalability problems that I won't see.

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle

```

## Catalin Marinas, 2008-09-12 22:15

Subject: Re: StGit question
Message-ID: <b0943d9e0809121515v53c6d593o8211b3cbbb8dfba4@mail.gmail.com>
URL: https://gitlist.dev/e/b0943d9e0809121515v53c6d593o8211b3cbbb8dfba4%40mail.gmail.com
In-Reply-To: <48CA6367.9020300@gmail.com>

```
On 12/09/2008, Clark Williams <clark.williams@gmail.com> wrote:
> Most of the time it's not more than one or two patches difference, so I think that it
>  can be handled manually for now. I'll definitely keep an eye on sync and merge though...

As Karl said, we have some plans to allow collaboration between
multiple StGit repositories but we didn't have much time to look at it
recently. Karl's "merge" stuff looks promising though.

What "sync" does is that it allow the same set of patches between two
branches to be synchronised in case modifications happened on one of
these branches. In your situation, you would have to fetch the remote
branch, uncommit as in Karl's method and either import or sync the
remote patches with those on your local branch.

-- 
Catalin

```

## Catalin Marinas, 2008-09-12 22:18

Subject: Re: StGit question
Message-ID: <b0943d9e0809121518p38f60733v3857fa66ac80d152@mail.gmail.com>
URL: https://gitlist.dev/e/b0943d9e0809121518p38f60733v3857fa66ac80d152%40mail.gmail.com
In-Reply-To: <b0943d9e0809121515v53c6d593o8211b3cbbb8dfba4@mail.gmail.com>

```
On 12/09/2008, Catalin Marinas <catalin.marinas@gmail.com> wrote:
> On 12/09/2008, Clark Williams <clark.williams@gmail.com> wrote:
>  > Most of the time it's not more than one or two patches difference, so I think that it
>  >  can be handled manually for now. I'll definitely keep an eye on sync and merge though...
>
>
> As Karl said, we have some plans to allow collaboration between
>  multiple StGit repositories but we didn't have much time to look at it
>  recently. Karl's "merge" stuff looks promising though.
>
>  What "sync" does is that it allow the same set of patches between two
>  branches to be synchronised in case modifications happened on one of
>  these branches. In your situation, you would have to fetch the remote
>  branch, uncommit as in Karl's method and either import or sync the
>  remote patches with those on your local branch.

BTW, "sync" allows synchronisation with a series of patches stored in
a directory. So you can also share patches using exported repositories
with import and sync.

-- 
Catalin

```
