Doc: CG: add instructions for staging branch

Doc: CG: add instructions for staging branch

[Graham Percival, 2011-12-03 00:52:28]

first pass at updated instructions for staging.

It relies on the developer running
  git format-patch
to create patches they want to apply to staging, since I don't know how to do it
the proper way.  Reviews giving better command lines are appreciated.

[Keith, 2011-12-03 03:39:07]

Putting commits on the local master branch is inviting an accidental push
directly to origin/master.  Assume instead that developers have their work on
some other branch and merge it to stable before pushing.

http://codereview.appspot.com/5440080/diff/1/Documentation/contributor/source...
File Documentation/contributor/source-code.itexi (right):

http://codereview.appspot.com/5440080/diff/1/Documentation/contributor/source...
Documentation/contributor/source-code.itexi:1696: 
Assuming your work is on branch @code{pq} do:
git checkout staging
git pull -r
git merge pq
git push origin staging

http://codereview.appspot.com/5440080/diff/1/Documentation/contributor/source...
Documentation/contributor/source-code.itexi:1697: You will not see your patch on
@code{master} until some automatic
on @code{origin/master}

http://codereview.appspot.com/5440080/diff/1/Documentation/contributor/source...
Documentation/contributor/source-code.itexi:1700: been lost.  Note that you can
check the commits on @code{staging}
on @code{origin/staging}

[Graham Percival, 2011-12-03 04:01:51]

On 2011/12/03 03:39:07, Keith wrote:
> Putting commits on the local master branch is inviting an accidental push
> directly to origin/master.  Assume instead that developers have their work on
> some other branch and merge it to stable before pushing.

But the lily-git.tcl tool automatically puts commits on master, and the current
git instructions are aimed at working directly on master.  I don't think I can
assume that developers have their work on other branches.

However, perhaps we need to explain this (and modify lily-git.tcl).  I'll take a
look at lily-git.tcl and see how hard it would be to modify it.

Cheers,
- Graham

[c_sorensen, 2011-12-03 04:05:49]

On 12/2/11 9:01 PM, "graham@percival-music.ca" <graham@percival-music.ca>
wrote:

>On 2011/12/03 03:39:07, Keith wrote:
>> Putting commits on the local master branch is inviting an accidental
>push
>> directly to origin/master.  Assume instead that developers have their
>work on
>> some other branch and merge it to stable before pushing.
>
>But the lily-git.tcl tool automatically puts commits on master, and the
>current git instructions are aimed at working directly on master.  I
>don't think I can assume that developers have their work on other
>branches.
>
>However, perhaps we need to explain this (and modify lily-git.tcl).
>I'll take a look at lily-git.tcl and see how hard it would be to modify
>it.

We can make lily-git.tcl aware of master and staging.  We could even add a
separate branch on which the patches would be worked.

I'll see if I can work something up.

Carl

[Graham Percival, 2011-12-03 06:27:40]

On Sat, Dec 03, 2011 at 04:05:45AM +0000, Carl Sorensen wrote:
> On 12/2/11 9:01 PM, "graham@percival-music.ca" <graham@percival-music.ca>
> wrote:
> >However, perhaps we need to explain this (and modify lily-git.tcl).
> >I'll take a look at lily-git.tcl and see how hard it would be to modify
> >it.
> 
> We can make lily-git.tcl aware of master and staging.  We could even add a
> separate branch on which the patches would be worked.
> 
> I'll see if I can work something up.

Thanks, that would be great.

I wonder if we can/should assume that no developer (i.e. person
with push ability) is using lily-git.tcl.  If we make that
assumption, then lily-git.tcl would only need to track master (to
keep the source up-to-date) and "working" (the branch that all
that contributor's work is done on -- maybe even call it
dev/USERNAME ?).  I'd like to have contributor's work being done
on a separate branch, even though it'll be strictly local, just to
get them used to the idea of branches.  If "master" is always seen
as a mirror of origin/master, that removes one layer of possible
confusion.

I can then use the idea of a "working" branch in the
developer-oriented git docs; making the assumption that people do
their work in "working" (or any other branchname), reserving
"master" and "staging" for special cases.

Cheers,
- Graham

[Keith, 2011-12-03 07:10:15]

On Fri, 02 Dec 2011 22:27:38 -0800, Graham Percival <graham@percival-music.ca>
wrote:

> I wonder if we can/should assume that no developer (i.e. person
> with push ability) is using lily-git.tcl.

I think yes,
that it is reasonable to expect people to use the command-line git on their own
computer before using it to push.

[mail_philholmes.net, 2011-12-03 10:51:51]

----- Original Message ----- 
From: "Graham Percival" <graham@percival-music.ca>
To: "Carl Sorensen" <c_sorensen@byu.edu>
Cc: "Keith OHara" <k-ohara5a5a@oco.net>; 
<reply@codereview-hr.appspotmail.com>; <lilypond.patchy.graham@gmail.com>; 
<lilypond-devel@gnu.org>
Sent: Saturday, December 03, 2011 6:27 AM
Subject: Re: Doc: CG: add instructions for staging branch (issue 5440080)


> On Sat, Dec 03, 2011 at 04:05:45AM +0000, Carl Sorensen wrote:
>> On 12/2/11 9:01 PM, "graham@percival-music.ca" <graham@percival-music.ca>
>> wrote:
>> >However, perhaps we need to explain this (and modify lily-git.tcl).
>> >I'll take a look at lily-git.tcl and see how hard it would be to modify
>> >it.
>>
>> We can make lily-git.tcl aware of master and staging.  We could even add 
>> a
>> separate branch on which the patches would be worked.
>>
>> I'll see if I can work something up.
>
> Thanks, that would be great.
>
> I wonder if we can/should assume that no developer (i.e. person
> with push ability) is using lily-git.tcl.  If we make that
> assumption, then lily-git.tcl would only need to track master (to
> keep the source up-to-date) and "working" (the branch that all
> that contributor's work is done on -- maybe even call it
> dev/USERNAME ?).  I'd like to have contributor's work being done
> on a separate branch, even though it'll be strictly local, just to
> get them used to the idea of branches.  If "master" is always seen
> as a mirror of origin/master, that removes one layer of possible
> confusion.

FWIW I use a combination of lily-git and git command line.  I like the 
convenience of being able to update master, create commits and patches and 
abandon work without all the "oh my god, am I doing this right" with git. 
My (simple) workflow is that I use lily-git to pull, make my changes, use 
lily-git to commit and create a patch, then I usually abort my changes.  I 
then use command line to fetch staging, apply my patch and push to staging, 
using David's instructions on how to do this.  We might consider that kind 
of work flow in the CG, for people like me who aren't experienced with git. 
It would also need the comment that if you know what you're doing, you 
needn't follow this, but don't mess up.

--
Phil Holmes

[Graham Percival, 2011-12-03 11:19:35]

On Sat, Dec 03, 2011 at 10:51:49AM -0000, Phil Holmes wrote:
> My (simple) workflow is that I use lily-git to
> pull, make my changes, use lily-git to commit and create a patch,
> then I usually abort my changes.  I then use command line to fetch
> staging, apply my patch and push to staging, using David's
> instructions on how to do this.  We might consider that kind of work
> flow in the CG, for people like me who aren't experienced with git.

I like it!  and that's basically what I do, anyway, although I use
git command-line to create my patch.  I'm never certain what's in
git in which branch, so I like seeing an actual .patch file
(created from git format-patch).  I think it's easier to explain
this way of working rather than the fully branch-based approach,
since it leaves those explicit patch files floating around.

How about I explain that method in detail in the CG, prepended by
the warning "if you know git, all you need to know is that you
should push to staging" ?  We'll keep the links to git tutorials
in case anybody who doesn't know git still wants to learn the
"proper" way of working with git.

Cheers,
- Graham

[mail_philholmes.net, 2011-12-03 13:59:24]

----- Original Message ----- 
From: "Graham Percival" <graham@percival-music.ca>
To: "Phil Holmes" <mail@philholmes.net>
Cc: "Carl Sorensen" <c_sorensen@byu.edu>; "Keith OHara" 
<k-ohara5a5a@oco.net>; <reply@codereview-hr.appspotmail.com>; 
<lilypond.patchy.graham@gmail.com>; <lilypond-devel@gnu.org>
Sent: Saturday, December 03, 2011 11:19 AM
Subject: Re: Doc: CG: add instructions for staging branch (issue 5440080)


> On Sat, Dec 03, 2011 at 10:51:49AM -0000, Phil Holmes wrote:
>> My (simple) workflow is that I use lily-git to
>> pull, make my changes, use lily-git to commit and create a patch,
>> then I usually abort my changes.  I then use command line to fetch
>> staging, apply my patch and push to staging, using David's
>> instructions on how to do this.  We might consider that kind of work
>> flow in the CG, for people like me who aren't experienced with git.
>
> I like it!  and that's basically what I do, anyway, although I use
> git command-line to create my patch.  I'm never certain what's in
> git in which branch, so I like seeing an actual .patch file
> (created from git format-patch).  I think it's easier to explain
> this way of working rather than the fully branch-based approach,
> since it leaves those explicit patch files floating around.
>
> How about I explain that method in detail in the CG, prepended by
> the warning "if you know git, all you need to know is that you
> should push to staging" ?  We'll keep the links to git tutorials
> in case anybody who doesn't know git still wants to learn the
> "proper" way of working with git.

This is the instructions I wrote to myself:

Before you start thinking about pushing a patch to staging, you
need to ensure you have the correct local branches up to date.
One time only, edit the .git/config file to look like this (there
will be other lines and sections, don't touch these):

@example
[remote "origin"]
 fetch = +refs/heads/*:refs/remotes/origin/*
 url = ssh://git.sv.gnu.org/srv/git/lilypond.git
@end example

Now, each time you want to make a change and push to staging, do
the following:

@example
git fetch # (to be sure you have the current version of staging)
git checkout origin/staging
# ... make and commit your change ... e.g. with git am patchname
git push origin HEAD:staging
@end example

Note that this does not work well for complex changes on other
branches - if you're doing this you'll need to have better git
understanding.


--
Phil Holmes

[pkx166h, 2011-12-03 14:08:11]

Hello,

On 3 December 2011 13:59, Phil Holmes <mail@philholmes.net> wrote:

>
>>
> This is the instructions I wrote to myself:
>
> Before you start thinking about pushing a patch to staging, you
> need to ensure you have the correct local branches up to date.
> One time only, edit the .git/config file to look like this (there
> will be other lines and sections, don't touch these):
>
> @example
> [remote "origin"]
> fetch = +refs/heads/*:refs/remotes/**origin/*
> url =
ssh://git.sv.gnu.org/srv/git/**lilypond.git<http://git.sv.gnu.org/srv/git/lilypond.git>
> @end example
>
> Now, each time you want to make a change and push to staging, do
> the following:
>
> @example
> git fetch # (to be sure you have the current version of staging)
>

What is the difference between doing 'git fetch' and 'git pull -r' (which
is what I do and lilygit.tcl does I believe)?

Otherwise I pretty much do what Phil does.

I don't work with branches but make my changes, make a patch, upload to
Rietveld and the use lilygit to reset --hard and I then simply keep the
patch file in a safe place and reapply it when I need to make a change or
push it.

That way I work on many small patches by editing/amending and resetting and
saving the updated patch file.

I find that much easier to understand conceptually :)

-- 
--

James

[lilypond.patchy.graham, 2011-12-09 14:21:50]

sorry, I uploaded this with the wrong account.  The patch continues here:
http://codereview.appspot.com/5467051/