Re: Git workflow #2

Vincent van Ravesteijn wrote: Fine. If I understand correctly the shift stage-devel stable can help you to rewrite history (e.g. by merging fix of fix commits). So then we would have 2 incompatible histories in two repos. No, the staging repo has no own fixed history. So if I commit fix

Re: Git workflow #2

Op 15-3-2012 10:57, Pavel Sanda schreef: Vincent van Ravesteijn wrote: Fine. If I understand correctly the shift stage-devel stable can help you to rewrite history (e.g. by merging fix of fix commits). So then we would have 2 incompatible histories in two repos. No, the staging repo has no own

Re: Git workflow #2

On 14/03/2012 02:05, Julien Rioux wrote: I want it simple, and I want it centralized. It's nice to allow private new repos to developers, thank you for that, but it seems overkill to require their use. I honestly cannot be bothered at the moment to setup remote repositories to fetch someone

Re: Git workflow #2

Vincent van Ravesteijn wrote: >> Fine. If I understand correctly the shift "stage"->"devel" stable can help >> you to rewrite history (e.g. by merging fix of fix commits). So then we >> would have 2 incompatible histories in two repos. > > No, the staging repo has no own fixed history. So if I

Re: Git workflow #2

Op 15-3-2012 10:57, Pavel Sanda schreef: Vincent van Ravesteijn wrote: Fine. If I understand correctly the shift "stage"->"devel" stable can help you to rewrite history (e.g. by merging fix of fix commits). So then we would have 2 incompatible histories in two repos. No, the staging repo has

Re: Git workflow #2

On 14/03/2012 02:05, Julien Rioux wrote: I want it simple, and I want it centralized. It's nice to allow private new repos to developers, thank you for that, but it seems overkill to require their use. I honestly cannot be bothered at the moment to setup remote repositories to fetch someone

Re: Git workflow #2

Vincent van Ravesteijn wrote: I see that in some cases of 2. additional commit are applied but we shouldn't value clean commit history at such high rates. These additional commits are the number 1 reason for me to propose what I proposed. To my liking, there are way too many commits that

Re: Git workflow #2

Op 14-3-2012 14:11, Pavel Sanda schreef: Vincent van Ravesteijn wrote: I see that in some cases of 2. additional commit are applied but we shouldn't value clean commit history at such high rates. These additional commits are the number 1 reason for me to propose what I proposed. To my liking,

Re: Git workflow #2

On 03/13/2012 09:05 PM, Julien Rioux wrote: I want it simple, and I want it centralized. It's nice to allow private new repos to developers, thank you for that, but it seems overkill to require their use. I honestly cannot be bothered at the moment to setup remote repositories to fetch

Re: Git workflow #2

On Tue, Mar 13, 2012 at 09:05:17PM -0400, Julien Rioux wrote: On 13/03/2012 8:13 PM, Lars Gullik Bjønnes wrote: But why? This is the perfect case for a separate repo. [...] | Assuming that the pristinity of the lyx repo as a whole is so | important that we cannot allow trusted

Re: Git workflow #2

On Wed, Mar 14, 2012 at 08:33:05PM +0100, Vincent van Ravesteijn wrote: Op 14-3-2012 14:11, Pavel Sanda schreef: Vincent van Ravesteijn wrote: I see that in some cases of 2. additional commit are applied but we shouldn't value clean commit history at such high rates. These additional commits

Re: Git workflow #2

Yes, that's where we disagree. I don't see these additional commits as good enough reason to drown people in branching mania. Unless someone develops new nifty feature or particularly tough bug, he shouldn't recognize there is some difference between svn and git. You seem to have an aversion

Re: Git workflow #2

On Wed, Mar 14, 2012 at 09:54:29PM +0100, Vincent van Ravesteijn wrote: Yes, that's where we disagree. I don't see these additional commits as good enough reason to drown people in branching mania. Unless someone develops new nifty feature or particularly tough bug, he shouldn't recognize

Re: Git workflow #2

On 14/03/2012 4:37 PM, André Pönitz wrote: On Tue, Mar 13, 2012 at 09:05:17PM -0400, Julien Rioux wrote: On 13/03/2012 8:13 PM, Lars Gullik Bjønnes wrote: But why? This is the perfect case for a separate repo. [...] | Assuming that the pristinity of the lyx repo as a whole is so | important

Re: Git workflow #2

André Pönitz andre.poen...@mathematik.tu-chemnitz.de writes: | On Wed, Mar 14, 2012 at 09:54:29PM +0100, Vincent van Ravesteijn wrote: Yes, that's where we disagree. I don't see these additional commits as good enough reason to drown people in branching mania. Unless someone develops new

Re: Git workflow #2

Julien Rioux jri...@physics.utoronto.ca writes: | On 13/03/2012 8:13 PM, Lars Gullik Bjønnes wrote: But why? This is the perfect case for a separate repo. [...] | Assuming that the pristinity of the lyx repo as a whole is so | important that we cannot allow trusted developers to create

Re: Git workflow #2

On 14/03/2012 7:14 PM, Lars Gullik Bjønnes wrote: Julien Riouxjri...@physics.utoronto.ca writes: | On 13/03/2012 8:13 PM, Lars Gullik Bjønnes wrote: But why? This is the perfect case for a separate repo. [...] | Assuming that the pristinity of the lyx repo as a whole is so | important that

Re: Git workflow #2

Vincent van Ravesteijn wrote: >> I see that in some cases of 2. additional commit are applied but we >> shouldn't value clean commit history at such high rates. > > These additional commits are the number 1 reason for me to propose what I > proposed. To my liking, there are way too many commits

Re: Git workflow #2

Op 14-3-2012 14:11, Pavel Sanda schreef: Vincent van Ravesteijn wrote: I see that in some cases of 2. additional commit are applied but we shouldn't value clean commit history at such high rates. These additional commits are the number 1 reason for me to propose what I proposed. To my liking,

Re: Git workflow #2

On 03/13/2012 09:05 PM, Julien Rioux wrote: I want it simple, and I want it centralized. It's nice to allow private new repos to developers, thank you for that, but it seems overkill to require their use. I honestly cannot be bothered at the moment to setup remote repositories to fetch

Re: Git workflow #2

On Tue, Mar 13, 2012 at 09:05:17PM -0400, Julien Rioux wrote: > On 13/03/2012 8:13 PM, Lars Gullik Bjønnes wrote: > >But why? > > > >This is the perfect case for a separate repo. > > > > [...] > > > >| Assuming that the pristinity of the lyx repo as a whole is so > >| important that we cannot

Re: Git workflow #2

On Wed, Mar 14, 2012 at 08:33:05PM +0100, Vincent van Ravesteijn wrote: > Op 14-3-2012 14:11, Pavel Sanda schreef: > >Vincent van Ravesteijn wrote: > >>>I see that in some cases of 2. additional commit are applied but we > >>>shouldn't value clean commit history at such high rates. > >>These

Re: Git workflow #2

Yes, that's where we disagree. I don't see these additional commits as good enough reason to drown people in branching mania. Unless someone develops new nifty feature or particularly tough bug, he shouldn't recognize there is some difference between svn and git. You seem to have an aversion

Re: Git workflow #2

On Wed, Mar 14, 2012 at 09:54:29PM +0100, Vincent van Ravesteijn wrote: > > >>>Yes, that's where we disagree. I don't see these additional commits as > >>>good enough reason to drown people in branching mania. Unless someone > >>>develops new nifty feature or particularly tough bug, he shouldn't

Re: Git workflow #2

On 14/03/2012 4:37 PM, André Pönitz wrote: On Tue, Mar 13, 2012 at 09:05:17PM -0400, Julien Rioux wrote: On 13/03/2012 8:13 PM, Lars Gullik Bjønnes wrote: But why? This is the perfect case for a separate repo. [...] | Assuming that the pristinity of the lyx repo as a whole is so | important

Re: Git workflow #2

André Pönitz writes: | On Wed, Mar 14, 2012 at 09:54:29PM +0100, Vincent van Ravesteijn wrote: >> >> >>>Yes, that's where we disagree. I don't see these additional commits as >> >>>good enough reason to drown people in branching mania. Unless someone >>

Re: Git workflow #2

Julien Rioux writes: | On 13/03/2012 8:13 PM, Lars Gullik Bjønnes wrote: >> But why? >> >> This is the perfect case for a separate repo. >> >> [...] >> >> | Assuming that the pristinity of the lyx repo as a whole is so >> | important that we cannot allow trusted

Re: Git workflow #2

On 14/03/2012 7:14 PM, Lars Gullik Bjønnes wrote: Julien Rioux writes: | On 13/03/2012 8:13 PM, Lars Gullik Bjønnes wrote: But why? This is the perfect case for a separate repo. [...] | Assuming that the pristinity of the lyx repo as a whole is so | important

Re: Git workflow #2

I see that in some cases of 2. additional commit are applied but we shouldn't value clean commit history at such high rates. These additional commits are the number 1 reason for me to propose what I proposed. To my liking, there are way too many commits that fix a typo, fix a warning on a

Re: Git workflow #2

On 13/03/2012 11:39 AM, Pavel Sanda wrote: Lars Gullik Bj?nnes wrote: You, the lyx developers, have to agree on process, but the git repo has been open for writing since sunday evening. From what I see there are roughly 3 kinds of things committed into trunk as far as time and testing is

Re: Git workflow #2

Pavel Sanda wrote: From what I see there are roughly 3 kinds of things committed into trunk as far as time and testing is concerned 1. Short-time one shots, e.g. fixing small glitches, doc changes, translations. Sometimes can take few minutes to produce and once committed there is

Re: Git workflow #2

Julien Rioux jri...@physics.utoronto.ca writes: | it should be allowed to have feature branches | directly in the main repo. This is the part that I really disagree with. Plainly: no, you should not be allow to create what ever branch you want in the main repo. This is the repo with the higher

Re: Git workflow #2

Pavel Sanda sa...@lyx.org writes: | Pavel | BTW Lars, can we get wiki and web working again? Christian stop to | respond altogether.. I was really hoping that I should not have to look at this, this is something that I really have not playing with before. I'll handle apache config, deamons,

Re: Git workflow #2

On 13/03/2012 5:58 PM, Lars Gullik Bjønnes wrote: Julien Riouxjri...@physics.utoronto.ca writes: | it should be allowed to have feature branches | directly in the main repo. This is the part that I really disagree with. Plainly: no, you should not be allow to create what ever branch you want

Re: Git workflow #2

Julien Rioux jri...@physics.utoronto.ca writes: | On 13/03/2012 5:58 PM, Lars Gullik Bjønnes wrote: Julien Riouxjri...@physics.utoronto.ca writes: | it should be allowed to have feature branches | directly in the main repo. This is the part that I really disagree with. Plainly: no, you

Re: Git workflow #2

On 13/03/2012 8:13 PM, Lars Gullik Bjønnes wrote: But why? This is the perfect case for a separate repo. [...] | Assuming that the pristinity of the lyx repo as a whole is so | important that we cannot allow trusted developers to create branches, | then maybe such branches can be allowed

Re: Git workflow #2

I see that in some cases of 2. additional commit are applied but we shouldn't value clean commit history at such high rates. These additional commits are the number 1 reason for me to propose what I proposed. To my liking, there are way too many commits that fix a typo, fix a warning on a

Re: Git workflow #2

On 13/03/2012 11:39 AM, Pavel Sanda wrote: Lars Gullik Bj?nnes wrote: You, the lyx developers, have to agree on process, but the git repo has been open for writing since sunday evening. From what I see there are roughly 3 kinds of things committed into trunk as far as time and testing is

Re: Git workflow #2

Pavel Sanda wrote: > From what I see there are roughly 3 kinds of things committed into trunk > as far as time and testing is concerned > > 1. Short-time one shots, e.g. fixing small glitches, doc changes, > translations. >Sometimes can take few minutes to produce and once committed there is

Re: Git workflow #2

Julien Rioux writes: | it should be allowed to have feature branches | directly in the main repo. This is the part that I really disagree with. Plainly: no, you should not be allow to create what ever branch you want in the main repo. This is the repo with the

Re: Git workflow #2

Pavel Sanda writes: | Pavel | BTW Lars, can we get wiki and web working again? Christian stop to | respond altogether.. I was really hoping that I should not have to look at this, this is something that I really have not playing with before. I'll handle apache config, deamons,

Re: Git workflow #2

On 13/03/2012 5:58 PM, Lars Gullik Bjønnes wrote: Julien Rioux writes: | it should be allowed to have feature branches | directly in the main repo. This is the part that I really disagree with. Plainly: no, you should not be allow to create what ever branch you

Re: Git workflow #2

Julien Rioux writes: | On 13/03/2012 5:58 PM, Lars Gullik Bjønnes wrote: >> Julien Rioux writes: >> >> | it should be allowed to have feature branches >> | directly in the main repo. >> >> This is the part that I really disagree with.

Re: Git workflow #2

On 13/03/2012 8:13 PM, Lars Gullik Bjønnes wrote: But why? This is the perfect case for a separate repo. > [...] > | Assuming that the pristinity of the lyx repo as a whole is so | important that we cannot allow trusted developers to create branches, | then maybe such branches can be allowed