New XFS git tree on oss.sgi.com

New XFS git tree on oss.sgi.com

[Lachlan McIlroy]

Hi all,

We've got a new xfs git tree on oss.sgi.com at:

git://oss.sgi.com/xfs/xfs

This tree is an automatic mirror of our internal tree so will always
be up to date.

It supercedes the old xfs-2.6 tree which has a few problems with it's
merge history.

There's a few branches there already:

'master'      This will contain all the latest xfs changes not yet pushed
               to mainline.
'mainline'    This is vanilla mainline and will updated regularly.
'for-linus'   Our staging branch for pull requests
'xfs-dev'     This branch will contain KDB and other supporting code for
               development and should be identical to the old CVS tree.

Feel free to start using it and let us know if you have any issues.

Thanks,
Lachlan

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: New XFS git tree on oss.sgi.com

[Christoph Hellwig]

On Tue, Nov 25, 2008 at 06:22:21PM +1100, Lachlan McIlroy wrote:
> There's a few branches there already:
> 
> 'master'      This will contain all the latest xfs changes not yet pushed
>                to mainline.
> 'mainline'    This is vanilla mainline and will updated regularly.
> 'for-linus'   Our staging branch for pull requests
> 'xfs-dev'     This branch will contain KDB and other supporting code for
>                development and should be identical to the old CVS tree.
> 
> Feel free to start using it and let us know if you have any issues.

Any chance to have these as separate git trees instead of branches?

In either case, do you expect patches against the xfs-dev or the master
tree?  It would also be useful if the trees and which one to be used
could be documented on oss.sgi.com/projects/xfs or xfs.org.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: New XFS git tree on oss.sgi.com

[Christoph Hellwig]

Looking over the -dev tree, can you please revert

	http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/xfs.git;a=commitdiff;h=c79ae33eebac1c15aa435fb77362fdc5eff2be4d

All this wasn't needed in the old ptrace tree either, no need to carry it forward.


_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: New XFS git tree on oss.sgi.com

[Russell Cattelan]

Christoph Hellwig wrote:
> On Tue, Nov 25, 2008 at 06:22:21PM +1100, Lachlan McIlroy wrote:
>   
>> There's a few branches there already:
>>
>> 'master'      This will contain all the latest xfs changes not yet pushed
>>                to mainline.
>> 'mainline'    This is vanilla mainline and will updated regularly.
>> 'for-linus'   Our staging branch for pull requests
>> 'xfs-dev'     This branch will contain KDB and other supporting code for
>>                development and should be identical to the old CVS tree.
>>
>> Feel free to start using it and let us know if you have any issues.
>>     
>
> Any chance to have these as separate git trees instead of branches?
>
> In either case, do you expect patches against the xfs-dev or the master
> tree?  It would also be useful if the trees and which one to be used
> could be documented on oss.sgi.com/projects/xfs or xfs.org.
>
>   
Specifically this page please.
http://xfs.org/index.php/Getting_the_latest_source_code

Maybe add a quick tutorial on git branches and how to create tracking 
branches for this tree.

Also can we have something other than "unnamed repository" in the 
description file?

> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
>   

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: New XFS git tree on oss.sgi.com

[Mark Goodwin]

Russell Cattelan wrote:
> Christoph Hellwig wrote:
>> On Tue, Nov 25, 2008 at 06:22:21PM +1100, Lachlan McIlroy wrote:
>>
>>> There's a few branches there already:
>>>
>>> 'master'      This will contain all the latest xfs changes not yet pushed
>>>                to mainline.
>>> 'mainline'    This is vanilla mainline and will updated regularly.
>>> 'for-linus'   Our staging branch for pull requests
>>> 'xfs-dev'     This branch will contain KDB and other supporting code for
>>>                development and should be identical to the old CVS tree.
>>>
>>> Feel free to start using it and let us know if you have any issues.
>>>
>> Any chance to have these as separate git trees instead of branches?

Why? Is it just a bandwidth issue with the initial clone, or some
other reason?

>> In either case, do you expect patches against the xfs-dev or the master
>> tree?

I'll let Lachlan reply to that, but normally master I think. One thing that
is important is that any commit against the xfs-dev tree should split out
kdb and dmapi changes into separate commits from changes to fs/xfs.

>  It would also be useful if the trees and which one to be used
>> could be documented on oss.sgi.com/projects/xfs or xfs.org.

yes certainly.

> Specifically this page please.
> http://xfs.org/index.php/Getting_the_latest_source_code

Been waiting for the WIKI on oss to be set up - these two sites
can simply mirror each other I guess for some or all documentation.

> Maybe add a quick tutorial on git branches and how to create tracking
> branches for this tree.

Yes that's a good idea: git remote add ....

> Also can we have something other than "unnamed repository" in the
> description file?

Yep. Niv, can you fix that up please.

> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs

Russell, would it be possible somehow for this footer to include the URL
of the archive reference for the message containing it?

Cheers
-- Mark

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: New XFS git tree on oss.sgi.com

[Lachlan McIlroy]

Christoph Hellwig wrote:
> On Tue, Nov 25, 2008 at 06:22:21PM +1100, Lachlan McIlroy wrote:
>> There's a few branches there already:
>>
>> 'master'      This will contain all the latest xfs changes not yet pushed
>>                to mainline.
>> 'mainline'    This is vanilla mainline and will updated regularly.
>> 'for-linus'   Our staging branch for pull requests
>> 'xfs-dev'     This branch will contain KDB and other supporting code for
>>                development and should be identical to the old CVS tree.
>>
>> Feel free to start using it and let us know if you have any issues.
> 
> Any chance to have these as separate git trees instead of branches?
That was the original plan.  Not sure why that got changed.  If there is
good reason for it we can change it.

> 
> In either case, do you expect patches against the xfs-dev or the master
> tree?  It would also be useful if the trees and which one to be used
> could be documented on oss.sgi.com/projects/xfs or xfs.org.
We would prefer patches based on the master branch but patches can be
against the mainline, master or xfs-dev branches.  If a patch against
mainline or xfs-dev doesn't apply cleanly to the master branch we may
ask the author to rebase that patch against the master branch.  If a
patch to the master branch needs auxillary changes to files that only
exist in the xfs-dev branch (ie xfsidbg stuff) we may ask for an
additional patch from the author.

We'll update the docs, thanks for that.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: New XFS git tree on oss.sgi.com

[Lachlan McIlroy]

Russell Cattelan wrote:
> Christoph Hellwig wrote:
>> On Tue, Nov 25, 2008 at 06:22:21PM +1100, Lachlan McIlroy wrote:
>>  
>>> There's a few branches there already:
>>>
>>> 'master'      This will contain all the latest xfs changes not yet 
>>> pushed
>>>                to mainline.
>>> 'mainline'    This is vanilla mainline and will updated regularly.
>>> 'for-linus'   Our staging branch for pull requests
>>> 'xfs-dev'     This branch will contain KDB and other supporting code for
>>>                development and should be identical to the old CVS tree.
>>>
>>> Feel free to start using it and let us know if you have any issues.
>>>     
>>
>> Any chance to have these as separate git trees instead of branches?
>>
>> In either case, do you expect patches against the xfs-dev or the master
>> tree?  It would also be useful if the trees and which one to be used
>> could be documented on oss.sgi.com/projects/xfs or xfs.org.
>>
>>   
> Specifically this page please.
> http://xfs.org/index.php/Getting_the_latest_source_code
Sure.  I didn't even know that page existed.

> 
> Maybe add a quick tutorial on git branches and how to create tracking 
> branches for this tree.
Can we just point people at an existing git tutorial?  Or are you wanting
something specific to our processes?

> 
> Also can we have something other than "unnamed repository" in the 
> description file?
Okay, how do we change that?

> 
>> _______________________________________________
>> xfs mailing list
>> xfs@oss.sgi.com
>> http://oss.sgi.com/mailman/listinfo/xfs
>>   
> 
> 

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: New XFS git tree on oss.sgi.com

[Lachlan McIlroy]

Christoph Hellwig wrote:
> Looking over the -dev tree, can you please revert
> 
> 	http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/xfs.git;a=commitdiff;h=c79ae33eebac1c15aa435fb77362fdc5eff2be4d
> 
> All this wasn't needed in the old ptrace tree either, no need to carry it forward.

Is this code needed for the BSD port?

There may be other code that can be removed too.  We moved a lot of the code
that existed only in ptools into the xfs-dev branch so that branch and ptools
are in sync.  This allows us to automatically merge changes back to the old
ptools tree (yes it still lives).  Any merge failures will now be handled
between git branches and not between different scms.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: New XFS git tree on oss.sgi.com

[Timothy Shimmin]

Lachlan McIlroy wrote:
> 
>> Also can we have something other than "unnamed repository" in the 
>> description file?
> Okay, how do we change that?
I've changed it.
description file at top of bare repository used by gitweb.

--Tim

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: New XFS git tree on oss.sgi.com

[Dave Chinner]

On Wed, Nov 26, 2008 at 12:00:41PM +1100, Lachlan McIlroy wrote:
> Christoph Hellwig wrote:
> > On Tue, Nov 25, 2008 at 06:22:21PM +1100, Lachlan McIlroy wrote:
> >> There's a few branches there already:
> >>
> >> 'master'      This will contain all the latest xfs changes not yet pushed
> >>                to mainline.
> >> 'mainline'    This is vanilla mainline and will updated regularly.
> >> 'for-linus'   Our staging branch for pull requests
> >> 'xfs-dev'     This branch will contain KDB and other supporting code for
> >>                development and should be identical to the old CVS tree.
> >>
> >> Feel free to start using it and let us know if you have any issues.
> > 
> > Any chance to have these as separate git trees instead of branches?
> That was the original plan.  Not sure why that got changed.  If there is
> good reason for it we can change it.
> 
> > 
> > In either case, do you expect patches against the xfs-dev or the master
> > tree?  It would also be useful if the trees and which one to be used
> > could be documented on oss.sgi.com/projects/xfs or xfs.org.
> We would prefer patches based on the master branch but patches can be
> against the mainline, master or xfs-dev branches. If a patch against
> mainline or xfs-dev doesn't apply cleanly to the master branch we may
> ask the author to rebase that patch against the master branch. If a
> patch to the master branch needs auxillary changes to files that only
> exist in the xfs-dev branch (ie xfsidbg stuff) we may ask for an
> additional patch from the author.

IIUC correctly, you are saying that we'll have to provide two
different versions of every patch set? i.e. one that applies to
the -master branch and potentially another that applies to the
-xfs-dev branch?

If so, this really means that if I write a patch for xfs-dev, I
can't just merge it to -master because the merge won't always apply
cleanly and I'll have to munge the patch set before I can commit the
changes. Hence if I have to change the xfs-dev version as a result
of reviews, I'll need to redo the merge to -master and all of the
required changes.

IOWs, to do this cleanly the -xfs-dev patches need to be exported
as patches and then imported into the -master branch so that it
is a separate set of commits. i.e. it needs rebasing. At that point,
the two branches may as well be separate trees - the point of
having branches is that commits can be merged between branches
without modification....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: New XFS git tree on oss.sgi.com

[Russell Cattelan]

Lachlan McIlroy wrote:
> Russell Cattelan wrote:
>> Christoph Hellwig wrote:
>>> On Tue, Nov 25, 2008 at 06:22:21PM +1100, Lachlan McIlroy wrote:
>>>  
>>>> There's a few branches there already:
>>>>
>>>> 'master'      This will contain all the latest xfs changes not yet 
>>>> pushed
>>>>                to mainline.
>>>> 'mainline'    This is vanilla mainline and will updated regularly.
>>>> 'for-linus'   Our staging branch for pull requests
>>>> 'xfs-dev'     This branch will contain KDB and other supporting 
>>>> code for
>>>>                development and should be identical to the old CVS 
>>>> tree.
>>>>
>>>> Feel free to start using it and let us know if you have any issues.
>>>>     
>>>
>>> Any chance to have these as separate git trees instead of branches?
>>>
>>> In either case, do you expect patches against the xfs-dev or the master
>>> tree?  It would also be useful if the trees and which one to be used
>>> could be documented on oss.sgi.com/projects/xfs or xfs.org.
>>>
>>>   
>> Specifically this page please.
>> http://xfs.org/index.php/Getting_the_latest_source_code
> Sure.  I didn't even know that page existed.
>
>>
>> Maybe add a quick tutorial on git branches and how to create tracking 
>> branches for this tree.
> Can we just point people at an existing git tutorial?  Or are you wanting
> something specific to our processes?
most git tutorials seem to be specific to one particular process so 
maybe a link to
a reasonable howto and then a few extra examples blurbs on how to create 
and deal
with tracking branches.

Maybe how to create tracking clones for each branch if that is what 
people want to do.

Personally I like branches as they help keep the tree cluster down and I 
don't have to think
up naming schemes to help me remember what is what, but sounds like some 
people may
like having multiple clones.
>
>>
>> Also can we have something other than "unnamed repository" in the 
>> description file?
> Okay, how do we change that?
>
>>
>>> _______________________________________________
>>> xfs mailing list
>>> xfs@oss.sgi.com
>>> http://oss.sgi.com/mailman/listinfo/xfs
>>>   
>>
>>
>

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: New XFS git tree on oss.sgi.com

[Christoph Hellwig]

On Wed, Nov 26, 2008 at 12:11:33PM +1100, Lachlan McIlroy wrote:
> Christoph Hellwig wrote:
> > Looking over the -dev tree, can you please revert
> > 
> > 	http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/xfs.git;a=commitdiff;h=c79ae33eebac1c15aa435fb77362fdc5eff2be4d
> > 
> > All this wasn't needed in the old ptrace tree either, no need to carry it forward.
> 
> Is this code needed for the BSD port?

According to Russell it may be need, but he'll probably need a newer
version than the one check-ed in once he resyncs.  And he'll have his
own support dir with the rest of the BSD code.

> There may be other code that can be removed too.  We moved a lot of the code
> that existed only in ptools into the xfs-dev branch so that branch and ptools
> are in sync.  This allows us to automatically merge changes back to the old
> ptools tree (yes it still lives).  Any merge failures will now be handled
> between git branches and not between different scms.

The xfs-dev also fortunately doesn't have the modular quota code.  So
for both these I'd suggest removing them from the ptools tree, too.


Also
http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/xfs.git;a=commitdiff;h=ca830fdf6231d0683f4ea4e9223e234c3a509063
doesn't seem to be needed.  None of those symbols seems to be used by
either dmapi or xfsidbg, the only two modules using xfs symbols in the
tree.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: New XFS git tree on oss.sgi.com

[Christoph Hellwig]

On Wed, Nov 26, 2008 at 12:00:41PM +1100, Lachlan McIlroy wrote:
> We would prefer patches based on the master branch but patches can be
> against the mainline, master or xfs-dev branches.  If a patch against
> mainline or xfs-dev doesn't apply cleanly to the master branch we may
> ask the author to rebase that patch against the master branch.  If a
> patch to the master branch needs auxillary changes to files that only
> exist in the xfs-dev branch (ie xfsidbg stuff) we may ask for an
> additional patch from the author.

Seems like a complicated setup, and not very friendly to patch
submitters.  Why acn't we just submit all patches against the -dev
branch?  Especially for dmapi-related patches everything else will
be a real pain.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: New XFS git tree on oss.sgi.com

[Timothy Shimmin]

Dave Chinner wrote:
> On Wed, Nov 26, 2008 at 12:00:41PM +1100, Lachlan McIlroy wrote:
>> Christoph Hellwig wrote:
>>> On Tue, Nov 25, 2008 at 06:22:21PM +1100, Lachlan McIlroy wrote:
>>>> There's a few branches there already:
>>>>
>>>> 'master'      This will contain all the latest xfs changes not yet pushed
>>>>                to mainline.
>>>> 'mainline'    This is vanilla mainline and will updated regularly.
>>>> 'for-linus'   Our staging branch for pull requests
>>>> 'xfs-dev'     This branch will contain KDB and other supporting code for
>>>>                development and should be identical to the old CVS tree.
>>>>
>>>> Feel free to start using it and let us know if you have any issues.
>>> Any chance to have these as separate git trees instead of branches?
>> That was the original plan.  Not sure why that got changed.  If there is
>> good reason for it we can change it.
>>
>>> In either case, do you expect patches against the xfs-dev or the master
>>> tree?  It would also be useful if the trees and which one to be used
>>> could be documented on oss.sgi.com/projects/xfs or xfs.org.
>> We would prefer patches based on the master branch but patches can be
>> against the mainline, master or xfs-dev branches. If a patch against
>> mainline or xfs-dev doesn't apply cleanly to the master branch we may
>> ask the author to rebase that patch against the master branch. If a
>> patch to the master branch needs auxillary changes to files that only
>> exist in the xfs-dev branch (ie xfsidbg stuff) we may ask for an
>> additional patch from the author.
> 
> IIUC correctly, you are saying that we'll have to provide two
> different versions of every patch set? i.e. one that applies to
> the -master branch and potentially another that applies to the
> -xfs-dev branch?
> 
No, that's not how I was envisaging this.
If you are not interested in modifying xfsidbg.c or dmapi
then I'd expect you to only send patches against the master branch.
If you are interested in also updating xfsidbg.c or dmapi
then I'd expect you to send patches against xfs-dev.
I was expecting the xfs-team when they pull in or git-am the
patches to update the other branch accordingly.

--Tim

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: New XFS git tree on oss.sgi.com

[Christoph Hellwig]

On Tue, Nov 25, 2008 at 08:27:09AM -0600, Russell Cattelan wrote:
> Specifically this page please.
> http://xfs.org/index.php/Getting_the_latest_source_code

But also the oss.sgi.com page.  Or given that it hasn't been updated for
a year the oss page should just redirect to xfs.org after we've
assimilated the last oss-only information..

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: New XFS git tree on oss.sgi.com

[Christoph Hellwig]

On Wed, Nov 26, 2008 at 08:42:56AM +1100, Mark Goodwin wrote:
> Why? Is it just a bandwidth issue with the initial clone, or some
> other reason?

It's just a lot more confusing.  E.g. you can't diretly clone a branch,
it alwasys needs at least two commands.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: New XFS git tree on oss.sgi.com

[Russell Cattelan]

Mark Goodwin wrote:
>
>
> Russell Cattelan wrote:
>> Christoph Hellwig wrote:
>>> On Tue, Nov 25, 2008 at 06:22:21PM +1100, Lachlan McIlroy wrote:
>>>
>>>> There's a few branches there already:
>>>>
>>>> 'master'      This will contain all the latest xfs changes not yet 
>>>> pushed
>>>>                to mainline.
>>>> 'mainline'    This is vanilla mainline and will updated regularly.
>>>> 'for-linus'   Our staging branch for pull requests
>>>> 'xfs-dev'     This branch will contain KDB and other supporting 
>>>> code for
>>>>                development and should be identical to the old CVS 
>>>> tree.
>>>>
>>>> Feel free to start using it and let us know if you have any issues.
>>>>
>>> Any chance to have these as separate git trees instead of branches?
>
> Why? Is it just a bandwidth issue with the initial clone, or some
> other reason?
>
>>> In either case, do you expect patches against the xfs-dev or the master
>>> tree?
>
> I'll let Lachlan reply to that, but normally master I think. One thing 
> that
> is important is that any commit against the xfs-dev tree should split out
> kdb and dmapi changes into separate commits from changes to fs/xfs.
>
>>  It would also be useful if the trees and which one to be used
>>> could be documented on oss.sgi.com/projects/xfs or xfs.org.
>
> yes certainly.
>
>> Specifically this page please.
>> http://xfs.org/index.php/Getting_the_latest_source_code
>
> Been waiting for the WIKI on oss to be set up - these two sites
> can simply mirror each other I guess for some or all documentation.
I suppose we could just move the xfs.org wiki to oss (once the machine 
is up/upgraded/wiki installed)
>
>> Maybe add a quick tutorial on git branches and how to create tracking
>> branches for this tree.
>
> Yes that's a good idea: git remote add ....
>
>> Also can we have something other than "unnamed repository" in the
>> description file?
>
> Yep. Niv, can you fix that up please.
>
>> xfs mailing list
>> xfs@oss.sgi.com
>> http://oss.sgi.com/mailman/listinfo/xfs
>
> Russell, would it be possible somehow for this footer to include the URL
> of the archive reference for the message containing it?
Hmm that my be difficult since the archive web stuff is generated 
periodically after that fact,
so I'm not sure if mailman has the ability build the url as part of 
sending out the email.

I'll do some googling and see if it is possible.
>
> Cheers
> -- Mark
>

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: New XFS git tree on oss.sgi.com

[Eric Sandeen]

Lachlan McIlroy wrote:
> Hi all,
> 
> We've got a new xfs git tree on oss.sgi.com at:
> 
> git://oss.sgi.com/xfs/xfs
> 
> This tree is an automatic mirror of our internal tree so will always
> be up to date.
> 
> It supercedes the old xfs-2.6 tree which has a few problems with it's
> merge history.
> 
> There's a few branches there already:
> 
> 'master'      This will contain all the latest xfs changes not yet pushed
>                to mainline.
> 'mainline'    This is vanilla mainline and will updated regularly.
> 'for-linus'   Our staging branch for pull requests
> 'xfs-dev'     This branch will contain KDB and other supporting code for
>                development and should be identical to the old CVS tree.
> 
> Feel free to start using it and let us know if you have any issues.

First off, cool.  Glad to see this progressing.

TAKE messages currently have Russell-magic added to the body to link to
a cvs commit for that change.  (however, it always takes up to 24h to
sync...)

Will cvs still be around & updated?  If not, those messages should be
removed (or changed to point to git commits if possible (probably not
possible).

-Eric

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: New XFS git tree on oss.sgi.com

[Dave Chinner]

On Wed, Nov 26, 2008 at 02:29:11PM +1100, Timothy Shimmin wrote:
> Dave Chinner wrote:
> > On Wed, Nov 26, 2008 at 12:00:41PM +1100, Lachlan McIlroy wrote:
> >> Christoph Hellwig wrote:
> >>> In either case, do you expect patches against the xfs-dev or the master
> >>> tree?  It would also be useful if the trees and which one to be used
> >>> could be documented on oss.sgi.com/projects/xfs or xfs.org.
> >> We would prefer patches based on the master branch but patches can be
> >> against the mainline, master or xfs-dev branches. If a patch against
> >> mainline or xfs-dev doesn't apply cleanly to the master branch we may
> >> ask the author to rebase that patch against the master branch. If a
> >> patch to the master branch needs auxillary changes to files that only
> >> exist in the xfs-dev branch (ie xfsidbg stuff) we may ask for an
> >> additional patch from the author.
> > 
> > IIUC correctly, you are saying that we'll have to provide two
> > different versions of every patch set? i.e. one that applies to
> > the -master branch and potentially another that applies to the
> > -xfs-dev branch?
> > 
> No, that's not how I was envisaging this.
> If you are not interested in modifying xfsidbg.c or dmapi
> then I'd expect you to only send patches against the master branch.

Ok, but that conflicts with "we may ask for an additional patch".

I'm trying to understand how we (i.e. those of us outside SGI) are
expected to use these branches. The new setup doesn't seem any
different to the old trees - there's one repository but really it is
still two "trees" that will require "external merging" to move
complex changes between them.

> I was expecting the xfs-team when they pull in or git-am the
> patches to update the other branch accordingly.

It might help to describe how you're expecting patches to flow
from the developers up to Linus - that might help us understand
how we should use these trees (i.e. describe the workflow you
expect to be using)....

Also, how does a "pull request" from a developer fit into this?

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: New XFS git tree on oss.sgi.com

[Timothy Shimmin]

Dave Chinner wrote:
> On Wed, Nov 26, 2008 at 02:29:11PM +1100, Timothy Shimmin wrote:
>> Dave Chinner wrote:
>>> On Wed, Nov 26, 2008 at 12:00:41PM +1100, Lachlan McIlroy wrote:
>>>> Christoph Hellwig wrote:
>>>>> In either case, do you expect patches against the xfs-dev or the master
>>>>> tree?  It would also be useful if the trees and which one to be used
>>>>> could be documented on oss.sgi.com/projects/xfs or xfs.org.
>>>> We would prefer patches based on the master branch but patches can be
>>>> against the mainline, master or xfs-dev branches. If a patch against
>>>> mainline or xfs-dev doesn't apply cleanly to the master branch we may
>>>> ask the author to rebase that patch against the master branch. If a
>>>> patch to the master branch needs auxillary changes to files that only
>>>> exist in the xfs-dev branch (ie xfsidbg stuff) we may ask for an
>>>> additional patch from the author.
>>> IIUC correctly, you are saying that we'll have to provide two
>>> different versions of every patch set? i.e. one that applies to
>>> the -master branch and potentially another that applies to the
>>> -xfs-dev branch?
>>>
>> No, that's not how I was envisaging this.
>> If you are not interested in modifying xfsidbg.c or dmapi
>> then I'd expect you to only send patches against the master branch.
> 
> Ok, but that conflicts with "we may ask for an additional patch".
:-)
Note the "may".
We're still trying to see what will be the best approach.
I think it is simpler just to expect a patch for one branch that
is convenient to how the external developer works.
SGI is responsible for keeping the branches in sync (is what
I was thinking).

> 
> I'm trying to understand how we (i.e. those of us outside SGI) are
> expected to use these branches.
I understand.
That's why I'd like it to be simple if possible.


> The new setup doesn't seem any
> different to the old trees - there's one repository but really it is
> still two "trees" that will require "external merging" to move
> complex changes between them.
> 
Yeah, there is no magic we can do with kdb and dmapi.
I think Niv tried to reduce some changes between xfs-dev and mainline.

>> I was expecting the xfs-team when they pull in or git-am the
>> patches to update the other branch accordingly.
> 
> It might help to describe how you're expecting patches to flow
> from the developers up to Linus - that might help us understand
> how we should use these trees (i.e. describe the workflow you
> expect to be using)....
> 
> Also, how does a "pull request" from a developer fit into this?
I was just thinking that if an external developer is working on a clone of
say the master branch and they have a fix, that they might post a patch
and say where sgi can pull from (the developer's tree) to receive the patch(es)
as an easier way to bring stuff in.
Otherwise, we can just work with the patches and use git-am to bring them in.

I was expecting the master and for-linus branches to be working similarly
to how they have in the past except now we'd be directly working with the
master branch (instead of a nominated sgi developer having to move ptools
mods over every so often etc..).

--Tim

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: New XFS git tree on oss.sgi.com

[Niv Sardi]

Russell Cattelan <cattelan@thebarn.com> writes:

> Lachlan McIlroy wrote:
>
>> Russell Cattelan wrote:
>>> Christoph Hellwig wrote:
>>>> On Tue, Nov 25, 2008 at 06:22:21PM +1100, Lachlan McIlroy wrote:
>>>>  
>>>>> There's a few branches there already:
>>>>>
>>>>> 'master'      This will contain all the latest xfs changes not yet 
>>>>> pushed
>>>>>                to mainline.
>>>>> 'mainline'    This is vanilla mainline and will updated regularly.
>>>>> 'for-linus'   Our staging branch for pull requests
>>>>> 'xfs-dev'     This branch will contain KDB and other supporting 
>>>>> code for
>>>>>                development and should be identical to the old CVS 
>>>>> tree.
>>>>>
>>>>> Feel free to start using it and let us know if you have any issues.
>>>>>     
>>>>
>>>> Any chance to have these as separate git trees instead of branches?
>>>>
>>>> In either case, do you expect patches against the xfs-dev or the master
>>>> tree?  It would also be useful if the trees and which one to be used
>>>> could be documented on oss.sgi.com/projects/xfs or xfs.org.
>>>>
>>>>   
>>> Specifically this page please.
>>> http://xfs.org/index.php/Getting_the_latest_source_code> Sure.  I didn't even know that page existed.
>>
>>>
>>> Maybe add a quick tutorial on git branches and how to create tracking 
>>> branches for this tree.
>> Can we just point people at an existing git tutorial?  Or are you wanting
>> something specific to our processes?
> most git tutorials seem to be specific to one particular process so 
> maybe a link to
> a reasonable howto and then a few extra examples blurbs on how to create 
> and deal
> with tracking branches.
>
> Maybe how to create tracking clones for each branch if that is what 
> people want to do.
>
> Personally I like branches as they help keep the tree cluster down and I 
> don't have to think
> up naming schemes to help me remember what is what, but sounds like some 
> people may
> like having multiple clones.

Sorry, I've been droped out, the mailining list change confused my
procmail.

$ git clone git://oss.sgi.com/xfs/xfs.git

# checking out xfs-dev and making it track the repo:
$ git checkout -b xfs-dev --track origin/xfs-dev

# adding a remote
$ git remote add $name $remoteurl
$ git remote udpate

that will put your remote branches in the $name/$branch namespace.

Anything else ? 

>>> Also can we have something other than "unnamed repository" in the 
>>> description file?
>> Okay, how do we change that?
>>
>>>
>>>> _______________________________________________
>>>> xfs mailing list
>>>> xfs@oss.sgi.com
>>>> http://oss.sgi.com/mailman/listinfo/xfs>>>   
>>>
>>>
>>
>
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs

-- 
Niv Sardi

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: New XFS git tree on oss.sgi.com

[Niv Sardi]

[Catching up on old mail]
Dave Chinner <david@fromorbit.com> writes:
> On Wed, Nov 26, 2008 at 02:29:11PM +1100, Timothy Shimmin wrote:
>
>> Dave Chinner wrote:
>> > On Wed, Nov 26, 2008 at 12:00:41PM +1100, Lachlan McIlroy wrote:
>> >> Christoph Hellwig wrote:
>> >>> In either case, do you expect patches against the xfs-dev or the master
>> >>> tree?  It would also be useful if the trees and which one to be used
>> >>> could be documented on oss.sgi.com/projects/xfs or xfs.org.
>> >> We would prefer patches based on the master branch but patches can be
>> >> against the mainline, master or xfs-dev branches. If a patch against
>> >> mainline or xfs-dev doesn't apply cleanly to the master branch we may
>> >> ask the author to rebase that patch against the master branch. If a
>> >> patch to the master branch needs auxillary changes to files that only
>> >> exist in the xfs-dev branch (ie xfsidbg stuff) we may ask for an
>> >> additional patch from the author.
>> > 
>> > IIUC correctly, you are saying that we'll have to provide two
>> > different versions of every patch set? i.e. one that applies to
>> > the -master branch and potentially another that applies to the
>> > -xfs-dev branch?
>> > 
>> No, that's not how I was envisaging this.
>> If you are not interested in modifying xfsidbg.c or dmapi
>> then I'd expect you to only send patches against the master branch.
>
> Ok, but that conflicts with "we may ask for an additional patch".
>
> I'm trying to understand how we (i.e. those of us outside SGI) are
> expected to use these branches. The new setup doesn't seem any
> different to the old trees - there's one repository but really it is
> still two "trees" that will require "external merging" to move
> complex changes between them.

you can work with xfs-dev or master as you please, if you work on
xfs-dev, we would like changes to xfs-dev only files (and bits), to be
in separated patches, so that we can push back only those changes to
master.

branches make sense, as we want to keep those trees as close as
possible, and merges will work (from master to xfs-dev, we need, for
obvious reasons, to cherry-pick the other way around).

>> I was expecting the xfs-team when they pull in or git-am the
>> patches to update the other branch accordingly.
>
> It might help to describe how you're expecting patches to flow
> from the developers up to Linus - that might help us understand
> how we should use these trees (i.e. describe the workflow you
> expect to be using)....
>
> Also, how does a "pull request" from a developer fit into this?

[DEV]-(am||pull)->[master]->[LINUS]
                   +-(merge)->[xfs-dev]

OR

[DEV]-(am||pull)->[xfs-dev,xfs-dev/{kdb,idbg,dmapi}]
                   +-(cherry pick)->[master]->[LINUS]

Cheers,
-- 
Niv Sardi

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: New XFS git tree on oss.sgi.com

[Niv Sardi]

Christoph Hellwig <hch@infradead.org> writes:

> On Wed, Nov 26, 2008 at 12:11:33PM +1100, Lachlan McIlroy wrote:
>
>> Christoph Hellwig wrote:
>> > Looking over the -dev tree, can you please revert
>> > 
>> > 	http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/xfs.git;a=commitdiff;h=c79ae33eebac1c15aa435fb77362fdc5eff2be4d> > 
>> > All this wasn't needed in the old ptrace tree either, no need to carry it forward.
>> 
>> Is this code needed for the BSD port?
>
> According to Russell it may be need, but he'll probably need a newer
> version than the one check-ed in once he resyncs.  And he'll have his
> own support dir with the rest of the BSD code.
>
>> There may be other code that can be removed too.  We moved a lot of the code
>> that existed only in ptools into the xfs-dev branch so that branch and ptools
>> are in sync.  This allows us to automatically merge changes back to the old
>> ptools tree (yes it still lives).  Any merge failures will now be handled
>> between git branches and not between different scms.
>
> The xfs-dev also fortunately doesn't have the modular quota code.  So
> for both these I'd suggest removing them from the ptools tree, too.
>
>
> Also
> http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/xfs.git;a=commitdiff;h=ca830fdf6231d0683f4ea4e9223e234c3a509063doesn't seem to be needed.  None of those symbols seems to be used by
> either dmapi or xfsidbg, the only two modules using xfs symbols in the
> tree.

That's exactly why it's there, the revertion is actually moving from
what was in ptools to something sane.
-- 
Niv Sardi

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: New XFS git tree on oss.sgi.com

[Christoph Hellwig]

On Wed, Dec 03, 2008 at 02:48:57PM +1100, Niv Sardi wrote:
> > Also
> > http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/xfs.git;a=commitdiff;h=ca830fdf6231d0683f4ea4e9223e234c3a509063doesn't seem to be needed.  None of those symbols seems to be used by
> > either dmapi or xfsidbg, the only two modules using xfs symbols in the
> > tree.
> 
> That's exactly why it's there, the revertion is actually moving from
> what was in ptools to something sane.

??  The commit above adds tons of unused exports.  But hey, I'll just
submit a patch to sort it out when I get some time..

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: New XFS git tree on oss.sgi.com

[Niv Sardi]

Christoph Hellwig <hch@infradead.org> writes:

> On Wed, Dec 03, 2008 at 02:48:57PM +1100, Niv Sardi wrote:
>
>> > Also
>> > http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/xfs.git;a=commitdiff;h=ca830fdf6231d0683f4ea4e9223e234c3a509063doesn't seem to be needed.  None of those symbols seems to be used by
>> > either dmapi or xfsidbg, the only two modules using xfs symbols in the
>> > tree.
>> 
>> That's exactly why it's there, the revertion is actually moving from
>> what was in ptools to something sane.
>
> ??  The commit above adds tons of unused exports.  But hey, I'll just
> submit a patch to sort it out when I get some time..

Yes, I already did that …that's the previous commit… but Lachland wanted
the tree not too move too much at first.
The patch you want is the exact revert of the commit you pointed out,
it'll be checked in soon.

Cheers,
-- 
Niv Sardi

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: New XFS git tree on oss.sgi.com

[Christoph Hellwig]

On Thu, Dec 04, 2008 at 10:58:48AM +1100, Niv Sardi wrote:
> Christoph Hellwig <hch@infradead.org> writes:
> 
> > On Wed, Dec 03, 2008 at 02:48:57PM +1100, Niv Sardi wrote:
> >
> >> > Also
> >> > http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/xfs.git;a=commitdiff;h=ca830fdf6231d0683f4ea4e9223e234c3a509063doesn't seem to be needed.  None of those symbols seems to be used by
> >> > either dmapi or xfsidbg, the only two modules using xfs symbols in the
> >> > tree.
> >> 
> >> That's exactly why it's there, the revertion is actually moving from
> >> what was in ptools to something sane.
> >
> > ??  The commit above adds tons of unused exports.  But hey, I'll just
> > submit a patch to sort it out when I get some time..
> 
> Yes, I already did that ???that's the previous commit??? but Lachland wanted
> the tree not too move too much at first.
> The patch you want is the exact revert of the commit you pointed out,
> it'll be checked in soon.

Ah, makes sense.  Thanks for the clarification.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: New XFS git tree on oss.sgi.com

[Christoph Hellwig]

On Wed, Nov 26, 2008 at 04:41:29PM +1100, Timothy Shimmin wrote:
> I was just thinking that if an external developer is working on a clone of
> say the master branch and they have a fix, that they might post a patch
> and say where sgi can pull from (the developer's tree) to receive the patch(es)
> as an easier way to bring stuff in.

So do you want git trees or not now?  I spent quite some time to set up
a tree for my last set of patches, but what got in was slightly
different, so when I pulles I got a merge and duplicates in my tree and
had to git-reset to a point before my patches.  If you do apply from
the list anyway I can avoid that overhead.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: New XFS git tree on oss.sgi.com

[Niv Sardi]

Christoph Hellwig <hch@infradead.org> writes:

> On Wed, Nov 26, 2008 at 04:41:29PM +1100, Timothy Shimmin wrote:
>
>> I was just thinking that if an external developer is working on a clone of
>> say the master branch and they have a fix, that they might post a patch
>> and say where sgi can pull from (the developer's tree) to receive the patch(es)
>> as an easier way to bring stuff in.
>
> So do you want git trees or not now?  I spent quite some time to set up
> a tree for my last set of patches, but what got in was slightly
> different, so when I pulles I got a merge and duplicates in my tree and
> had to git-reset to a point before my patches.  If you do apply from
> the list anyway I can avoid that overhead.

I believe that if you don't work in git, and prefer to send patches (as
long as git-am likes them) it's not harder for us to merge things (We
can't pull because we want to add a signed-off-by anyway). If you do use
git, publishing your tree makes it a bit easier to track your work, and
our delta. but that is in no way mandatory.

Cheers,
-- 
Niv Sardi

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: New XFS git tree on oss.sgi.com

[Christoph Hellwig]

Now that the xfs-dev branch was updated after a while I tried a git pull
an get a useless error message:

hch@bigmac:~/work/xfs-dev$ git-pull 
You asked me to pull without telling me which branch you
want to merge with, and 'branch.origin/xfs-dev.merge' in
your configuration file does not tell me either.  Please
name which branch you want to merge on the command line and
try again (e.g. 'git pull <repository> <refspec>').
See git-pull(1) for details on the refspec.

If you often merge with the same branch, you may want to
configure the following variables in your configuration
file:

    branch.origin/xfs-dev.remote = <nickname>
    branch.origin/xfs-dev.merge = <remote-ref>
    remote.<nickname>.url = <url>
    remote.<nickname>.fetch = <refspec>

See git-config(1) for details.


Can you please make each of the current branches a proper git tree
that is easy to work with?  Alternatively I'll just completely stop
bothering with the dev tree if it's such a pain in the ass.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: New XFS git tree on oss.sgi.com

[Russell Cattelan]

Christoph Hellwig wrote:
> Now that the xfs-dev branch was updated after a while I tried a git pull
> an get a useless error message:
>
>   
I agree that is a worthless error message and does nothing to really 
tell you what the problem is.

The problem is that you have a tracking branch for xfs-dev so git wants 
to leave your branch untouched
until you actually want to update it from the remote branch origin/xfs-dev
What you can do is:
% git-fetch
% git-pull . xfs-dev

That will pull the latest xfs-dev stuff into your current branch.

> hch@bigmac:~/work/xfs-dev$ git-pull 
> You asked me to pull without telling me which branch you
> want to merge with, and 'branch.origin/xfs-dev.merge' in
> your configuration file does not tell me either.  Please
> name which branch you want to merge on the command line and
> try again (e.g. 'git pull <repository> <refspec>').
> See git-pull(1) for details on the refspec.
>
> If you often merge with the same branch, you may want to
> configure the following variables in your configuration
> file:
>
>     branch.origin/xfs-dev.remote = <nickname>
>     branch.origin/xfs-dev.merge = <remote-ref>
>     remote.<nickname>.url = <url>
>     remote.<nickname>.fetch = <refspec>
>
> See git-config(1) for details.
>
>
> Can you please make each of the current branches a proper git tree
> that is easy to work with?  Alternatively I'll just completely stop
> bothering with the dev tree if it's such a pain in the ass.
>
>   
of course this would be so damn confusing if somebody would document the 
procedures someplace?!

Hmm I wonder where we could do that.... ohh wait maybe the WIKI!



_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: New XFS git tree on oss.sgi.com

[Christoph Hellwig]

On Tue, Dec 09, 2008 at 10:20:04AM -0600, Russell Cattelan wrote:
> The problem is that you have a tracking branch for xfs-dev so git wants 
> to leave your branch untouched
> until you actually want to update it from the remote branch origin/xfs-dev
> What you can do is:
> % git-fetch
> % git-pull . xfs-dev
> 
> That will pull the latest xfs-dev stuff into your current branch.

It might.  But remember more than a single command to update a
repository is just a braindead design.  Especially if I have to remember
a branch name.  Even CVS got this right..

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: New XFS git tree on oss.sgi.com

[Russell Cattelan]

Christoph Hellwig wrote:
> On Tue, Dec 09, 2008 at 10:20:04AM -0600, Russell Cattelan wrote:
>   
>> The problem is that you have a tracking branch for xfs-dev so git wants 
>> to leave your branch untouched
>> until you actually want to update it from the remote branch origin/xfs-dev
>> What you can do is:
>> % git-fetch
>> % git-pull . xfs-dev
>>
>> That will pull the latest xfs-dev stuff into your current branch.
>>     
>
> It might.  But remember more than a single command to update a
> repository is just a braindead design.  Especially if I have to remember
> a branch name.  Even CVS got this right..
>
>   
Agreed,  I'm not going to defend git cmds, frankly I find most of them 
confusing
and poorly documented. It seems like the only way to figured this stuff 
out is
read as many howto's as possible and then make some swags.

What I did was clone the tree and then have my "master" branch track 
origin/xfs-dev
vs origin/master. That way I can just do git-pulls and have an to date 
xfs-dev tree.

-Russell

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: New XFS git tree on oss.sgi.com

[Niv Sardi]

[-- Attachment #1: Type: text/plain, Size: 2025 bytes --]

Russell Cattelan <cattelan@thebarn.com> writes:

> Christoph Hellwig wrote:
>
>> Now that the xfs-dev branch was updated after a while I tried a git pull
>> an get a useless error message:
>>
>>   
> I agree that is a worthless error message and does nothing to really
> tell you what the problem is.
>
> The problem is that you have a tracking branch for xfs-dev so git
> wants to leave your branch untouched
> until you actually want to update it from the remote branch origin/xfs-dev
> What you can do is:
> % git-fetch
> % git-pull . xfs-dev
>
> That will pull the latest xfs-dev stuff into your current branch.
>
>> hch@bigmac:~/work/xfs-dev$ git-pull You asked me to pull without
>> telling me which branch you
>> want to merge with, and 'branch.origin/xfs-dev.merge' in
>> your configuration file does not tell me either.  Please
>> name which branch you want to merge on the command line and
>> try again (e.g. 'git pull <repository> <refspec>').
>> See git-pull(1) for details on the refspec.
>>
>> If you often merge with the same branch, you may want to
>> configure the following variables in your configuration
>> file:
>>
>>     branch.origin/xfs-dev.remote = <nickname>
>>     branch.origin/xfs-dev.merge = <remote-ref>
>>     remote.<nickname>.url = <url>
>>     remote.<nickname>.fetch = <refspec>
>>
>> See git-config(1) for details.
>>
>>
>> Can you please make each of the current branches a proper git tree
>> that is easy to work with?  Alternatively I'll just completely stop
>> bothering with the dev tree if it's such a pain in the ass.

Please read git documentation.
   
You don't want to be pulling xfs-dev into a xfs/master tree, you should
setup a remote properly and have local branch tracking them.

> of course this would be so damn confusing if somebody would document
> the procedures someplace?!

> Hmm I wonder where we could do that.... ohh wait maybe the WIKI!

http://xfs.org/index.php?title=Main_Page&action=submit
--> out of captcha images; this shouldn't happen

you can read this:

[-- Attachment #2: workflow.txt --]
[-- Type: text/plain, Size: 10854 bytes --]

-----------------------------------------------------------
* Where is it?
* Checking out a tree
* Tree Status
* Modifying files before checkins
* Commiting/checking in
* Going back in history - changing one's mind
* Tracking remote trees
* Publishing one's tree
* Reviews and requesting them
* Importing changes to our development tree
* Lost your quilt ?
-----------------------------------------------------------

* Where is it?

    A git server is setup on git.melbourne.sgi.com which is serving
    out of /git.  A user, git, has been setup with the home directory
    of /git.  The xfs trees are located under /git.  The main
    development tree is a bare repository under /git/xfs.git.  (So it
    has no checked out files just the .git database files at the top
    level) So far, it has a master, a mainline and an xfs-dev branch.
    The master branch is used for the checking in of development, it
    is mainline+latest XFS. xfs-dev will be set up to track ptools,
    checkins are currently closed to that branch.

    Additionally the config of the git setup (gitconfig,
    gitdescription, and git-hooks) as well as some home scripts
    (git-finalize and git-ptools) can be found in
    git+ssh://git.melbourne.sgi.com/git/git-ptools)

* Checking out a tree:
  o Ptools:
    $ mkdir isms/2.6.x-xfs; vi isms/2.6.x-xfs/.workarea; cd fs/xfs; p_tupdate

  o Git:
    $ git clone git+ssh://git.melbourne.sgi.com/git/xfs/
      ( for local trees you can use the path directly, if the machine is
        running a git-daemon you can use git://, but that will not
	auto-setup push syntax )

      this will clone the tree (all the commit objects), and checkout
      the HEAD branch (master for our case, other branches can be seen
      with git branch -a, to checkout a branch (local or remote) just
      use:
    $ git checkout $branch

* Tree Status:
  o Ptools:
    $ p_list -c # shows file you've informed ptools about

  o Git:
    $ git status # lists modified, unmerged and untracked files.
    $ git log    # shows all commited modifications
      ( you can use git log $remote/branch to see the log of a remote )

* Modifying files before checkins:
  o Ptools:
    $ p_modify file # modify
    $ p_fetal file  # add
    $ p_delete file # remove

  o Git: # no need to mark files for modification, git will find out
           about them automagically, just edit them.
    $ git add file # add
    $ git rm file  # remove
    Note: that if one uses "git-commit -a" or "git-finalize -a"
    then you don't have to add files which have been modified or
    deleted as git will detect them, you only have to add new files.

* Commiting/checking in:
  o Ptools:
    $ p_finalize file

  o Git:
    $ git commit
    From man page - useful options:
    --------------------------------
    -a|--all::
    Tell the command to automatically stage files that have
    been modified and deleted, but new files you have not
    told git about are not affected.

    --amend::
    Used to amend the tip of the current branch. Prepare the tree
    object you would want to replace the latest commit as usual
    (this includes the usual -i/-o and explicit paths), and the
    commit log editor is seeded with the commit message from the
    tip of the current branch. The commit you create replaces the
    current tip -- if it was a merge, it will have the parents of
    the current tip as parents -- so the current top commit is
    discarded.

    -s|--signoff::
    Add Signed-off-by line at the end of the commit message.

    I do like to git commit -asm "Commit message"
    --------------------------------
    remember that a git commit, only commits to YOUR local tree, you
    then need to push things over:

    General form is:
    $ git push git://uri/of/the/other/rep +refspec

    ----------------
    For XFS project:
    ----------------
    Using the wrapper script, git-finalize, this would become:

    $ git-finalize -a # it asks questions to set up commit description

    git-finalize: [-d] [-a] [-p pv] [-u author] [-r reviewer] [-s summary] [-F desc_file] [files]
    noting:
    -d:         debug option - doesn't run the commit command
    -a:         the all option passed thru to git-commit
    pv:         bugworks pv number which will be looked up using bwx
    author:     author in format: Andrew Morton <akpm@linux-foundation.org>
    reviewer:   in author format and can have multiple -r options
    summary:    summary 1 line description of the commit
    desc_file:  a file containing body of the commit description
    [files]:    explicit files for commit (can't use with -a option)

    $ git push melbourne

    Where in workarea/.git/config it has the few lines:

    [remote "melbourne"]
    url = ssh://git.melbourne.sgi.com/git/xfs.git
    push = master

    (Or modify the config file using "git remote add" mentioned below)

* Going back in history - changing one's mind
  o Ptools:
    $ p_unmodify file

  o Git:
    [the STUPID (ptools) way]
    $ git revert $mod
      will introduce a new commit reverting $mod.

    [ the OH GOD WE ARE DISTRIBUTED way (for mods not pushed anyway)]

      if the mods to revert are the last n one:
    $ git reset HEAD^n

      if not (dangerous)
    $ git rebase -i $mod^1 # considered harmfull read documentation !

    Other related commands:
    $ git reset     # see doc for --hard

* Tracking remote trees:
  o Ptools: remote what ? there shall be only one tree, MY TREE

  o Git:
    $ git remote add $name $uri # adds a remote tracking
    $ git remote update         # updates all remotes
    $ git branch -a             # shows all accessible branches
                                  ( including remotes in the
                                    $remote_name/ namespace )
    $ git checkout -b $local_branch_name --track $remote_name/$remote_branch
          # creates a tracked local branch, git will warn whenever the
            remote adds commits.

* Publishing one's tree:
  o Ptools: Be Andy.

  o Git:
    give shell access to your tree, use git+ssh://machine/path or
    direct path

    or

    $ sudo git-daemon --export-all --base-path=/srv/git --base-path-relaxed --reuseaddr --user-path=public_git
           # exports all git trees found under ~/public_git and /srv/git

    Or set up indetd etc.

* Reviews and requesting them
  o Git: [ Developer ]
    (A) From a git tree:
      ə publishes a git tree at git://dev/tree, containing his feature1 branch
      ə Requests a pull from the reviewer.

      or

    (B) publishes a series of patches:
        $ git format-patch $since_head # create ordered patches since
                                         head $since_head, i.e. on
                                         branch linus-create-ea, I'd
                                         $since_head would be linus/master
        $ git send-email --compose *.patch

* Importing changes to our development tree
  o Git: [ Reviewer - typically us at SGI ]
    (A) From a git tree:
      ə Adds a remote locally called "dev":
        $ git remote add dev git://dev/tree

      ə Looks at the differences between his tree (dev) and feature1:
        $ git log HEAD...dev/feature1 # differences in both ways,
	      	  	       	        read man for more detail…
        List patches of commits from HEAD or dev/feature1 but not in both
        (A...B in one branch but not both)
        (A..B in branch B but not in A)

      ə Reviews the diffs: (-p adds commit change in patch form)
        $ git log -p dev/feature1..HEAD

      ə For each commit he accepts, imports it to his tree, adding a
        Signed-off-by: automatically:
        Whilst in our own development tree, cherry-pick from the remote
        $ git cherry-pick -s -e $commit # easily scriptable with git cherry 

      ə The only trick there is putting the description into our preferred format,
        with summary line with [XFS] prefix, body, and SGI-PV.
        I guess we'll need to do that manually.

      ə Pushes it to tree git+ssh://git.melbourne.sgi.com/git/xfs.git
        $ git push melbourne # if you've set up tracking remotes correctly

	if not
          $ git push git://chook/xfs/xfs-dev <refspec> # read man…
        of form: git push repository <refspec>
        where <refspec> of form:
          The canonical format of a <refspec> parameter is
          `+?<src>:<dst>`; that is, an optional plus `+`, followed
          by the source ref, followed by a colon `:`, followed by
          the destination ref.
          The local ref that matches <src> is used
          to fast forward the remote ref that matches <dst>.  If
          the optional plus `+` is used, the remote ref is updated
          even if it does not result in a fast forward update.

      or

    (B) From emailed patches:

    · From a plain patch:
      $ git apply $patch # evil
    · From a mailbox:
      $ git am -s $mailbox # the way to go, adds Signed-off-by

    In order to modify the commit description, it may work to apply the committed
    patches in another branch and then "cherry-pick -e" them into the development
    branch.

* Lost your quilt ?
    Hope you use underwear.

    if not, you can look at many projects made of awesome:
    guilt (written by Jeffpc, an XFS hacker):     

     quilt for git; similar to Mercurial queues Guilt (Git Quilt) is a
     series of bash scripts which add a Mercurial queues-like
     functionality and interface to git.  The one distinguishing
     feature from other quilt-like porcelains, is the format of the
     patches directory. _All_ the information is stored as plain text
     - a series file and the patches (one per file). This easily lends
     itself to versioning the patches using any number of of SCMs.

    stgit:

     manage stacks of patches in a git repository stgit provides
     similar functionality to quilt (i.e. pushing/popping patches
     to/from a stack) on top of git.

     These operations are performed using git commands and the patches
     are stored as git commit objects, allowing easy merging of the
     stgit patches into other repositories using standard git
     functionality.

     Homepage: http://www.procode.org/stgit/

    topgit (house favourite, we may want to impose this one, but needs
    a bit of git knowledge to fully understand):

     a Git patch queue manager TopGit manages a patch queue using Git
     topic branches, one patch per branch. It allows for patch
     dependencies and can thus manage non-linear patch series.

     TopGit is a minimal layer on top of Git, which does not limit use
     of Git's functionality (such as the index). It rigorously keeps
     history until a patch is accepted upstream. It is also fully
     usable across distributed repositories.

     Homepage: http://repo.or.cz/w/topgit.git



[-- Attachment #3: Type: text/plain, Size: 68 bytes --]


if you s/git.melbourne.sgi.com/oss.sgi.com/

Cheers,
-- 
Niv Sardi

[-- Attachment #4: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: New XFS git tree on oss.sgi.com

[Russell Cattelan]

Niv Sardi wrote:
> Russell Cattelan <cattelan@thebarn.com> writes:
>
>   
>> Christoph Hellwig wrote:
>>
>>     
>>> Now that the xfs-dev branch was updated after a while I tried a git pull
>>> an get a useless error message:
>>>
>>>   
>>>       
>> I agree that is a worthless error message and does nothing to really
>> tell you what the problem is.
>>
>> The problem is that you have a tracking branch for xfs-dev so git
>> wants to leave your branch untouched
>> until you actually want to update it from the remote branch origin/xfs-dev
>> What you can do is:
>> % git-fetch
>> % git-pull . xfs-dev
>>
>> That will pull the latest xfs-dev stuff into your current branch.
>>
>>     
>>> hch@bigmac:~/work/xfs-dev$ git-pull You asked me to pull without
>>> telling me which branch you
>>> want to merge with, and 'branch.origin/xfs-dev.merge' in
>>> your configuration file does not tell me either.  Please
>>> name which branch you want to merge on the command line and
>>> try again (e.g. 'git pull <repository> <refspec>').
>>> See git-pull(1) for details on the refspec.
>>>
>>> If you often merge with the same branch, you may want to
>>> configure the following variables in your configuration
>>> file:
>>>
>>>     branch.origin/xfs-dev.remote = <nickname>
>>>     branch.origin/xfs-dev.merge = <remote-ref>
>>>     remote.<nickname>.url = <url>
>>>     remote.<nickname>.fetch = <refspec>
>>>
>>> See git-config(1) for details.
>>>
>>>
>>> Can you please make each of the current branches a proper git tree
>>> that is easy to work with?  Alternatively I'll just completely stop
>>> bothering with the dev tree if it's such a pain in the ass.
>>>       
>
> Please read git documentation.
>   
seriously?! you need to say this?

>    
> You don't want to be pulling xfs-dev into a xfs/master tree, you should
> setup a remote properly and have local branch tracking them.
>   
Ya and this is a non trivial thing to do without proper instructions.

>   
>> of course this would be so damn confusing if somebody would document
>> the procedures someplace?!
>>     
>
>   
>> Hmm I wonder where we could do that.... ohh wait maybe the WIKI!
>>     
>
> http://xfs.org/index.php?title=Main_Page&action=submit
> --> out of captcha images; this shouldn't happen
>   
Ok fixed.
> you can read this:
>   
Sigh ....
Honestly you think ptools info is useful here?

> ------------------------------------------------------------------------
>
>
> if you s/git.melbourne.sgi.com/oss.sgi.com/
>
> Cheers,

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: New XFS git tree on oss.sgi.com

[Mark Goodwin]

Russell Cattelan wrote:
> Niv Sardi wrote:
>> You don't want to be pulling xfs-dev into a xfs/master tree, you should
>> setup a remote properly and have local branch tracking them.
>>
> Ya and this is a non trivial thing to do without proper instructions.

well, see the man page for: git-remote add ...
But maybe Niv could spell out some specific examples for the XFS trees

> Sigh ....
> Honestly you think ptools info is useful here?

the original document was written to help SGI internal developers
migrate from ptools to git - and given most XFS oss developers
are familiar with ptools, the analogies in that doc are probably
useful.  But whatever we put up on the wiki for longer term reference
should probably have the ptools crud stripped out.

Cheers
-- Mark

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: New XFS git tree on oss.sgi.com

[Niv Sardi]

Russell Cattelan <cattelan@thebarn.com> writes:
> Niv Sardi wrote:
>> Please read git documentation.
>>   
> seriously?! you need to say this?

OK, ok, pre-coffee mail was a bit harsh, but it's not all that hard.

>> http://xfs.org/index.php?title=Main_Page&action=submit> --> out of captcha images; this shouldn't happen
>>   
> Ok fixed.

http://xfs.org/index.php/Git

please edit accordingly

>> you can read this:
>>   
> Sigh ....
> Honestly you think ptools info is useful here?

nope, edited on the wiki, this was just a dump of the document that was
produced for in-house use.

Cheers,
-- 
Niv Sardi

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: New XFS git tree on oss.sgi.com

[Christoph Hellwig]

On Wed, Dec 10, 2008 at 09:20:05AM +1100, Niv Sardi wrote:
> Please read git documentation.
>    
> You don't want to be pulling xfs-dev into a xfs/master tree, you should
> setup a remote properly and have local branch tracking them.

Sorry, I'm not gona waste my time on this shit.  It works just fine with
a separate git repository that has zero downsides.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs