threads / discuss / 15491

StGit question

Subject: StGit question

## tl;dr

6 messages between Sep 11, 2008 and Sep 12, 2008.

replies: 5people: 3as markdown or json

Clark Williams· Sep 11, 2008, 17:04 UTC · lore
-----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· Sep 12, 2008, 07:51 UTC · re: Clark Williams · lore

Re: StGit question

On 2008-09-11 12:04:06 -0500, Clark Williams wrote:
> Are there any guidelines or best-practices for sharing StGit trees?
See below. ;-)
Show 15 quoted lines
> 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· Sep 12, 2008, 12:41 UTC · re: Karl Hasselström · lore

Re: StGit question

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Karl Hasselström wrote:
Show 34 quoted lines
> 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 :).

Show 11 quoted lines
> 
> 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· Sep 12, 2008, 15:40 UTC · re: Clark Williams · lore

Re: StGit question

On 2008-09-12 07:41:11 -0500, Clark Williams wrote:
Show 5 quoted lines
> 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· Sep 12, 2008, 22:15 UTC · re: Clark Williams · lore

Re: StGit question

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· Sep 12, 2008, 22:18 UTC · re: Catalin Marinas · lore

Re: StGit question

On 12/09/2008, Catalin Marinas <catalin.marinas@gmail.com> wrote:
Show 14 quoted lines
> 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

← back to recent threads