Carl, could you close this Rietveld issue?
Janek
http://codereview.appspot.com/5539062/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On 2/26/12 9:34 AM, janek.lilyp...@gmail.com janek.lilyp...@gmail.com
wrote:
Carl, could you close this Rietveld issue?
Janek
http://codereview.appspot.com/5539062/
Done, thanks.
Carl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
LGTM. Good job, Carl!
http://codereview.appspot.com/5539062/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On 2012/01/17 20:31:24, Graham Percival wrote:
On Tue, Jan 17, 2012 at 08:24:35PM +,
mailto:janek.lilyp...@gmail.com wrote:
could we change this (and other similar) prefix so that it doesn't
contain a slash? I mean, change dev/ to dev- or something like
that.
The slash confused me a
On 2012/01/19 16:07:59, Carl wrote:
On 2012/01/17 20:31:24, Graham Percival wrote:
On Tue, Jan 17, 2012 at 08:24:35PM +,
mailto:janek.lilyp...@gmail.com
wrote:
could we change this (and other similar) prefix so that it doesn't
contain a slash? I mean, change dev/ to dev- or something
I've responded to comments. Thanks for all the input.
Carl
http://codereview.appspot.com/5539062/diff/3004/Documentation/contributor/source-code.itexi
File Documentation/contributor/source-code.itexi (right):
Janek Warchoł janek.lilyp...@gmail.com writes:
2012/1/17 Graham Percival gra...@percival-music.ca:
http://codereview.appspot.com/5539062/diff/3004/Documentation/contributor/source-code.itexi#newcode297
Documentation/contributor/source-code.itexi:297: git branch dev/cg
I think it would be good
On 2012/01/17 21:31:01, janek wrote:
http://codereview.appspot.com/5539062/diff/3004/Documentation/contributor/source-code.itexi
File Documentation/contributor/source-code.itexi (right):
http://codereview.appspot.com/5539062/diff/3004/Documentation/contributor/source-code.itexi#newcode297
Le 17/01/2012 21:31, Graham Percival disait :
On Tue, Jan 17, 2012 at 08:24:35PM +, janek.lilyp...@gmail.com wrote:
could we change this (and other similar) prefix so that it doesn't
contain a slash? I mean, change dev/ to dev- or something like that.
The slash confused me a lot, because
Some thoughts on making all this less confusing to beginners.
http://codereview.appspot.com/5539062/diff/3004/Documentation/contributor/source-code.itexi
File Documentation/contributor/source-code.itexi (right):
On Tue, Jan 17, 2012 at 08:24:35PM +, janek.lilyp...@gmail.com wrote:
could we change this (and other similar) prefix so that it doesn't
contain a slash? I mean, change dev/ to dev- or something like that.
The slash confused me a lot, because it's also used to separate a remote
name from
2012/1/17 Graham Percival gra...@percival-music.ca:
http://codereview.appspot.com/5539062/diff/3004/Documentation/contributor/source-code.itexi#newcode297
Documentation/contributor/source-code.itexi:297: git branch dev/cg
I think it would be good to be verbose, because it will give people more
http://codereview.appspot.com/5539062/diff/3004/Documentation/contributor/source-code.itexi
File Documentation/contributor/source-code.itexi (right):
http://codereview.appspot.com/5539062/diff/3004/Documentation/contributor/source-code.itexi#newcode297
On 2012/01/16 07:54:41, Graham Percival wrote:
On Sun, Jan 15, 2012 at 11:12:49PM +,
mailto:carl.d.soren...@gmail.com wrote:
At this point, you have pushed dev/cg to staging without polluting
dev/cg with staging. And you can continue to rebase dev/cg with
master
as needed/desired.
2100: Explanation of branches for CG (issue 5539062)
On 2012/01/16 07:54:41, Graham Percival wrote:
On Sun, Jan 15, 2012 at 11:12:49PM +,
mailto:carl.d.soren...@gmail.com wrote:
At this point, you have pushed dev/cg to staging without polluting
dev/cg with staging. And you can continue
On 2012/01/16 16:16:40, Carl wrote:
Having just spent half an hour fixing up my lilygit.tcl branch, I
have personally validated the benefit of the approach now reflected
in this patch.
I will *never* again rebase a working branch to origin/staging. In
fact, I will never again have a local
On 1/16/12 9:26 AM, Phil Holmes m...@philholmes.net wrote:
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
On Mon, Jan 16, 2012 at 04:26:04PM -, Phil Holmes wrote:
@example
[remote origin]
fetch = +refs/heads/*:refs/remotes/origin/*
url = ssh://git.sv.gnu.org/srv/git/lilypond.git
@end example
This is precisely what we should avoid. Explaining how to modify
.git/config by hand is tedious,
http://codereview.appspot.com/5539062/diff/1/Documentation/contributor/source-code.itexi
File Documentation/contributor/source-code.itexi (right):
http://codereview.appspot.com/5539062/diff/1/Documentation/contributor/source-code.itexi#newcode450
Documentation/contributor/source-code.itexi:450:
http://codereview.appspot.com/5539062/diff/1/Documentation/contributor/source-code.itexi
File Documentation/contributor/source-code.itexi (right):
http://codereview.appspot.com/5539062/diff/1/Documentation/contributor/source-code.itexi#newcode491
Documentation/contributor/source-code.itexi:491:
On 2012/01/15 08:05:35, Graham Percival wrote:
http://codereview.appspot.com/5539062/diff/1/Documentation/contributor/source-code.itexi
File Documentation/contributor/source-code.itexi (right):
On Sun, Jan 15, 2012 at 12:18:57PM +, carl.d.soren...@gmail.com wrote:
I think you misunderstand what git rebase does. git rebase
origin/staging does *not* bring origin/staging into dev/cg;
really? wow, I completely misunderstood that.
If origin/staging is bad, and then deleted, and
On 2012/01/15 08:17:35, Graham Percival wrote:
Could this entire @subsubheading be changed to read:
Done
http://codereview.appspot.com/5539062/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
On 2012/01/15 12:18:57, Carl wrote:
On 2012/01/15 08:05:35, Graham Percival wrote:
http://codereview.appspot.com/5539062/diff/1/Documentation/contributor/source-code.itexi
File Documentation/contributor/source-code.itexi (right):
On 2012/01/15 12:32:21, Graham Percival wrote:
On Sun, Jan 15, 2012 at 12:18:57PM +,
mailto:carl.d.soren...@gmail.com wrote:
I think you misunderstand what git rebase does. git rebase
origin/staging does *not* bring origin/staging into dev/cg;
really? wow, I completely
Graham Percival gra...@percival-music.ca writes:
On Sun, Jan 15, 2012 at 12:18:57PM +, carl.d.soren...@gmail.com wrote:
I think you misunderstand what git rebase does. git rebase
origin/staging does *not* bring origin/staging into dev/cg;
really? wow, I completely misunderstood that.
On 2012/01/15 12:43:03, Carl wrote:
On 2012/01/15 12:32:21, Graham Percival wrote:
On Sun, Jan 15, 2012 at 12:18:57PM +,
mailto:carl.d.soren...@gmail.com
wrote:
I think you misunderstand what git rebase does. git rebase
origin/staging does *not* bring origin/staging into dev/cg;
On 2012/01/15 12:50:21, dak wrote:
On 2012/01/15 12:43:03, Carl wrote:
On 2012/01/15 12:32:21, Graham Percival wrote:
On Sun, Jan 15, 2012 at 12:18:57PM +,
mailto:carl.d.soren...@gmail.com
wrote:
I think you misunderstand what git rebase does. git rebase
origin/staging does
After doing some testing, it appears that the following should be able
to get my dev/cg applied to origin/staging, while preserving my dev/cg:
git rebase origin/staging dev/cg~0
git push origin HEAD:staging
David, is this correct?
Thanks,
Carl
http://codereview.appspot.com/5539062/
LGTM
On 2012/01/15 08:05:35, Graham Percival wrote:
With this recipe, the
broken-staging will be in the developer's personal dev/cg branch.
Is there any way we can avoid this?
1) We could accept it as a consequence of re-writing the public history
on origin/staging. When the developer
On 2012/01/15 19:47:10, Keith wrote:
LGTM
On 2012/01/15 08:05:35, Graham Percival wrote:
With this recipe, the
broken-staging will be in the developer's personal dev/cg branch.
Is there any way we can avoid this?
1) We could accept it as a consequence of re-writing the public
history
On 2012/01/15 14:54:22, dak wrote:
An occasional
git rebase origin dev/cg
(which permanently rebases dev/cg on origin/master which we don't
reset ever by
gentlemen's agreement, meaning that if somebody does that, everybody
else stops
being a gentleman) should take care that most of
On 2012/01/15 23:15:01, Carl wrote:
On 2012/01/15 14:54:22, dak wrote:
git rebase origin dev/cg
My thoughts (almost) exactly. My set of commands would be
git checkout dev/cg
git rebase origin/master
which does exactly the same thing, only with different words.
I think it reaches
On Sun, Jan 15, 2012 at 11:12:49PM +, carl.d.soren...@gmail.com wrote:
Yes, but I wouldn't leave it in that state. The full set of commands is
git rebase origin/staging dev/cg~0
git push origin HEAD:staging
git checkout dev/cg
LGTM
At this point, you have pushed dev/cg to staging
Reviewers: Graham Percival, Keith, janek,
Message:
Here's a revision of Graham's info for the CG on branches. I think it
can go in as-is.
Please review.
Thanks,
Carl
Description:
Issue 2100: Explanation of branches for CG
Explain branches, by Graham Percival
Changes to git commands by
On 2012/01/14 22:56:32, Carl wrote:
Here's a revision of Graham's info for the CG on branches. I think it
can go in
as-is.
Please review.
Thanks,
Carl
LGTM
Ian
http://codereview.appspot.com/5539062/
___
lilypond-devel mailing list
36 matches
Mail list logo
