On Fri, Jul 22, 2011 at 10:45:30PM +0200, Bertrand Bordage wrote:
> What are we doing then? We only update git-cl's repository in the CG?
I guess so? :(
It would be nice to start a discussion with the rietveld people
about allowing uploads of an actual git patch (regardless of
whether numerous p
What are we doing then? We only update git-cl's repository in the CG?
Bertrand
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
2011/7/17 Carl Sorensen :
> On 7/16/11 5:37 PM, "Graham Percival" wrote:
>
>> On Sat, Jul 16, 2011 at 05:13:29PM -0600, Carl Sorensen wrote:
>>>
>>> IMO, we should be aiming at one commit per Rietveld issue, rather than a
>>> series of commits per Rietveld issue.
>>
>> That's beside the point, at
On Sat, Jul 16, 2011 at 07:35:50PM -0600, Carl Sorensen wrote:
> Now Bertrand's repository doesn't have one commit on this branch, he has
> three or four commits on his branch. And the first two or three are not
> right -- they haven't passed code review.
oh, I see. I personally always just modi
On 7/16/11 4:55 PM, "Graham Percival" wrote:
> On Sat, Jul 16, 2011 at 08:34:56PM +0200, Jan Warchoł wrote:
>> 2011/7/16 Bertrand Bordage :
>>> Furthermore, there's something we should solve : upload.py is just uploading
>>> diffs instead of full git commit patches.
>>> By changing a line on u
On 7/16/11 5:37 PM, "Graham Percival" wrote:
> On Sat, Jul 16, 2011 at 05:13:29PM -0600, Carl Sorensen wrote:
>>
>> IMO, we should be aiming at one commit per Rietveld issue, rather than a
>> series of commits per Rietveld issue.
>
> That's beside the point, at least as far as I understand it.
Am Sonntag, 17. Juli 2011, 01:37:42 schrieb Graham Percival:
> But that's silly and stupid. Bertrand's git tree has a beautiful
> commit. Why can't I get that commit when I want to push it? Why
> does Rietveld and/or git-cl throw away that nice metadata?
Because Rietveld is the problem: It was
On Sat, Jul 16, 2011 at 05:13:29PM -0600, Carl Sorensen wrote:
>
> IMO, we should be aiming at one commit per Rietveld issue, rather than a
> series of commits per Rietveld issue.
That's beside the point, at least as far as I understand it.
- Bertrand writes some code.
- Bertrand makes a git com
On 7/16/11 5:00 PM, "Graham Percival" wrote:
> On Sat, Jul 16, 2011 at 04:53:15PM -0600, Carl Sorensen wrote:
>> Why are we trying to eliminate git-cl? What is the problem it causes?
>
> git-cl isn't the problem.
>
> The problem is that when I click on "download raw patch set" on a
> codere
On Sat, Jul 16, 2011 at 04:53:15PM -0600, Carl Sorensen wrote:
> Why are we trying to eliminate git-cl? What is the problem it causes?
git-cl isn't the problem.
The problem is that when I click on "download raw patch set" on a
codereview issue, I get a raw patch set. This loses the commit
messa
On Sat, Jul 16, 2011 at 08:34:56PM +0200, Jan Warchoł wrote:
> 2011/7/16 Bertrand Bordage :
> > Furthermore, there's something we should solve : upload.py is just uploading
> > diffs instead of full git commit patches.
> > By changing a line on upload.py, we can easily change this "git diff" for a
On 7/16/11 10:38 AM, "Bertrand Bordage" wrote:
>> Would it be possible to make upload.py sent multiple commits? For
>> casual contributors, a single commit is fine, but serious
>> developers like Mike require the ability to upload multiple
>> commits for a single issue.
>
> Yes, this will be po
On Sat, Jul 16, 2011 at 09:42:10PM +0200, Bertrand Bordage wrote:
>
> I finally made a good patch (bug-free), but we need to update codereview's
> server.
> The "temporary fork" option can't work.
hmm, that makes things more complicated.
Fortunately, Google code now supports git, so this could b
>
> I would like to rewrite the CG, but first I would like somebody
> (not me) to change upload.py
> - ideally the changes should be sent upstream
> - I'm willing to have a temporary "fork" of upload.py while we're
> waiting for a new official version of upload.py
>
I finally made a good patch (b
2011/7/16 Bertrand Bordage :
> Hi all,
> As mentioned in the title, git-cl's repository on neugierig.org is down.
> It looks like this project isn't supported anymore.
> I suggest we rewrite the last part of CG 3.3.4 "Uploading a patch for
> review".
> In fact, why were we using git-cl ? What is gi
>
> git-cl stored the issue number inside each git branch, so that you can
> easily update an issue with a new pathcset without having to look up the
> issue number.
>
Hum, this is true.
> Plus, you don't have to create a patch file on disk that you can then
> upload. So, git-cl is basically onl
>
> Would it be possible to make upload.py sent multiple commits? For
> casual contributors, a single commit is fine, but serious
> developers like Mike require the ability to upload multiple
> commits for a single issue.
Yes, this will be possible.
Do you mean something like this ?
http://coder
On Sa., 16. Jul. 2011 17:42:36 CEST, Graham Percival
wrote:
> On Sat, Jul 16, 2011 at 10:56:28AM +0200, Bertrand Bordage wrote:
> > In fact, why were we using git-cl ? What is git-cl providing that
> > can't be done with upload.py from Rietveld codereview ?
git-cl stored the issue number inside
On Sat, Jul 16, 2011 at 10:56:28AM +0200, Bertrand Bordage wrote:
> In fact, why were we using git-cl ? What is git-cl providing that can't be
> done
> with upload.py from Rietveld codereview ?
I'm not certain that upload.py allowed us to use git patches in
the past; I definitely did not think th
Hi all,
As mentioned in the title, git-cl's repository on neugierig.org is down.
It looks like this project isn't supported anymore.
I suggest we rewrite the last part of CG 3.3.4 "Uploading a patch for
review".
In fact, why were we using git-cl ? What is git-cl providing that can't be
done with
20 matches
Mail list logo
