Re: Git workflow #2

[Pavel Sanda]

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 for bug 1234 in stage and put changeset: pointer into
trac there is no guarantee I find it again?

 Now, you plan to to replace stage after main release by devel tree and 
 start from there again development, now with clearer history? What commit 
 checksum is primary for the pruposes of trac for example then?

 Whenever a feature gets into the official repo, it will not change anymore, 
 and the sha1 will be definite.

So your plan is to play with stage history (eg merge commits) and from time
to time push such repaired history into official? From that time no changes
will be done to those commits in stage as well?

Pavel

Re: Git workflow #2

[Vincent van Ravesteijn]

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 fixed history.

So if I commit fix for bug 1234 in stage and put changeset: pointer into
trac there is no guarantee I find it again?


Yes. If the commit-id changes later on, this must mean that the commit 
has been corrected and thus you'd have to update trac anyway (also in 
svn). I guess you don't want to point at a faulty commit.


There are other options as well. We can add a line in the commit log or 
use 'git notes' to indicate which bug is fixed by a commit. For example:


git notes add -m 'trac:#1234'

When merging with the stable lyx repo, we could automatically add a note 
to the bug report using a post-***-hook.




Now, you plan to to replace stage after main release by devel tree and
start from there again development, now with clearer history? What commit
checksum is primary for the pruposes of trac for example then?

Whenever a feature gets into the official repo, it will not change anymore,
and the sha1 will be definite.

So your plan is to play with stage history (eg merge commits) and from time
to time push such repaired history into official? From that time no changes
will be done to those commits in stage as well?


Yes, the staging repo will always be based on the stable repo.


Statistics on the commits to the master repo:

1 whitespace change
3 commits that fix a previous commit/series
2 commits that duplicate changes from 2.0.x branch
2 commits with bug fixes that could use some correction

Vincent

Re: Git workflow #2

[Abdelrazak Younes]

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 else's latest 
feature branch, let alone setup my own copy of the repo on the server. 
I'm looking for a central place to have access and contribute to the 
latest LyX development. (I'm also looking for a tool that is stupid 
easy to use.) I hope that if it's not lyx.git, then please let 
lyx-staging.git be this central place. Then it would be the main LyX 
repo in my mind.


Anyway, that's just me. I'm curious to hear what others have to say.


I agree with you, lyx-staging.git is the way to go :-)

Abdel.

Re: Git workflow #2

[Pavel Sanda]

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 for bug 1234 in stage and put changeset: pointer into
trac there is no guarantee I find it again?

>> Now, you plan to to replace "stage" after main release by "devel" tree and 
>> start from there again development, now with clearer history? What commit 
>> checksum is primary for the pruposes of trac for example then?
>
> Whenever a feature gets into the official repo, it will not change anymore, 
> and the sha1 will be definite.

So your plan is to play with stage history (eg merge commits) and from time
to time push such repaired history into official? From that time no changes
will be done to those commits in stage as well?

Pavel

Re: Git workflow #2

[Vincent van Ravesteijn]

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 fixed history.

So if I commit fix for bug 1234 in stage and put changeset: pointer into
trac there is no guarantee I find it again?


Yes. If the commit-id changes later on, this must mean that the commit 
has been corrected and thus you'd have to update trac anyway (also in 
svn). I guess you don't want to point at a faulty commit.


There are other options as well. We can add a line in the commit log or 
use 'git notes' to indicate which bug is fixed by a commit. For example:


git notes add -m 'trac:#1234'

When merging with the stable lyx repo, we could automatically add a note 
to the bug report using a post-***-hook.




Now, you plan to to replace "stage" after main release by "devel" tree and
start from there again development, now with clearer history? What commit
checksum is primary for the pruposes of trac for example then?

Whenever a feature gets into the official repo, it will not change anymore,
and the sha1 will be definite.

So your plan is to play with stage history (eg merge commits) and from time
to time push such repaired history into official? From that time no changes
will be done to those commits in stage as well?


Yes, the staging repo will always be based on the stable repo.


Statistics on the commits to the master repo:

1 whitespace change
3 commits that fix a previous commit/series
2 commits that duplicate changes from 2.0.x branch
2 commits with bug fixes that could use some correction

Vincent

Re: Git workflow #2

[Abdelrazak Younes]

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 else's latest 
feature branch, let alone setup my own copy of the repo on the server. 
I'm looking for a central place to have access and contribute to the 
latest LyX development. (I'm also looking for a tool that is stupid 
easy to use.) I hope that if it's not lyx.git, then please let 
lyx-staging.git be this central place. Then it would be the main LyX 
repo in my mind.


Anyway, that's just me. I'm curious to hear what others have to say.


I agree with you, lyx-staging.git is the way to go :-)

Abdel.

Re: Git workflow #2

[Pavel Sanda]

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 fix a typo, fix 
 a warning on a different platform, fix a commit error, fix whitespace, fix 
 monolithic build, commit a forgotten file, etc.

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.

 When looking at the commits after a week of absence, I should get an easy 
 overview of which features are being developed

To me new branch is worth for work like bigger chunk of lyx2lyx commits
done last year by Richard or perhaps IPA-inset from last days. If these get 
branches you have easy overview of features developed but I believe that most
of nowadays commit traffic doesn't belong to this category. It's rather
chaotic mixture of cherishing things here and there and trying to impose
branch structure on that is more annoying tham having not so clean history.

 Would it be better for you if you could commit directly on the staging repo 
 of my proposal ?

Yes, probably (Richard's note about being overwhelmed apllies to me as well,
I don't see clearly into your proposal.)

 In principle, one should see this staging repo as current trunk.

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.

Now, you plan to to replace stage after main release by devel tree and start
from there again development, now with clearer history? What commit checksum
is primary for the pruposes of trac for example then?

 You only have to test the less stable one.

You mean staging, right?

Pavel

Re: Git workflow #2

[Vincent van Ravesteijn]

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, there are way too many commits that fix a typo, fix
a warning on a different platform, fix a commit error, fix whitespace, fix
monolithic build, commit a forgotten file, etc.

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 to branches, while I can't work without 
them anymore.



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.

Now, you plan to to replace stage after main release by devel tree 
and start from there again development, now with clearer history? What 
commit checksum is primary for the pruposes of trac for example then?


Whenever a feature gets into the official repo, it will not change 
anymore, and the sha1 will be definite.




You only have to test the less stable one.

You mean staging, right?


Yes.

Vincent

Re: Git workflow #2

[Richard Heck]

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 someone else's latest 
feature branch, let alone setup my own copy of the repo on the server. 
I'm looking for a central place to have access and contribute to the 
latest LyX development. (I'm also looking for a tool that is stupid 
easy to use.) I hope that if it's not lyx.git, then please let 
lyx-staging.git be this central place. Then it would be the main LyX 
repo in my mind.


Anyway, that's just me. I'm curious to hear what others have to say.

I don't see any need to *require* people to use private repos. For 
feature development, etc, one can continue to work locally, in private 
branches, in what is otherwise a clone of the main LyX repository. If 
one does want to work that way, then the only difference will be that 
pushes to the stable branch should be less frequent than they have been: 
Only when the feature is essentially done should any of it be pushed. 
Comments on code would go through the list only.


That said, this is less difficult than it seems. There's a bit of a 
learning curve here, to be sure, and I'm working pretty hard right now 
to understand it all. But once I have it figured out, I think I will be 
able to write instructions for setting up an appropriate development 
environment that are easy to follow and easy to use.


In this case, I don't think it's necessary to have extra repositories to 
fetch other people's feature branches and the like. I suppose one could 
do so, but my sense is that commentary, etc, on these branches will 
mostly happen through the online browser, rather than through checkout, 
or through people posting patch sets to the list, like before.


That said,

Richard

Re: Git workflow #2

[André Pönitz]

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 developers to create branches,
 | then maybe such branches can be allowed in the lyx-staging repo? Can
 | we have branches in this one, please?
 
 That would be better, but I do not understand why you couldn't have this
 in your own repo.
 
 
 And I don't understand why we couldn't have branches in our repo.
 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.

Additional repos are really easy to handle with git remotes.
I'd even argue you won't really notice it. 

 I honestly cannot be bothered at the moment to setup remote
 repositories to fetch someone else's latest feature branch, let alone
 setup my own copy of the repo on the server.

You are ready to write a 20-line-mail because you can't be bothered
to write a single 'git remote add name git://...' line when you
need it? This does not make much sense to me. 

 I'm looking for a central place to have access and contribute to the
 latest LyX development. (I'm also looking for a tool that is stupid
 easy to use.) I hope that if it's not lyx.git, then please let
 lyx-staging.git be this central place. Then it would be the main LyX
 repo in my mind.
 
 Anyway, that's just me. I'm curious to hear what others have to say.

There is no need to clutter The LyX Sources with work-in-progress
branches and lots of needless merges. It's not only ugly, but also
impacts stuff like 'git bisect'. Some things are simply better kept
linear...

You want to keep it simple. Using git remotes _is_ simple.

Andre'

Re: Git workflow #2

[André Pönitz]

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 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 different platform, fix a commit error, fix whitespace, fix
 monolithic build, commit a forgotten file, etc.
 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 to branches, while I can't work without
 them anymore.

There is a difference between (a) using branches for work (implementing
stuff, checking out other people's work etc) and (b) having branches in
the main repo. (a) does not imply (b).

Andre'

Re: Git workflow #2

[Vincent van Ravesteijn]

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 to branches, while I can't work without
them anymore.

There is a difference between (a) using branches for work (implementing
stuff, checking out other people's work etc) and (b) having branches in
the main repo. (a) does not imply (b).


(a) does not imply (b), but both (a) and (b) imply branching mania. 
So, given (a), branching mania can't be a reason to refuse (b).



Andre'


Vincent

Re: Git workflow #2

[André Pönitz]

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 there is some difference between svn and git.
 You seem to have an aversion to branches, while I can't work without
 them anymore.
 There is a difference between (a) using branches for work (implementing
 stuff, checking out other people's work etc) and (b) having branches in
 the main repo. (a) does not imply (b).
 
 (a) does not imply (b), but both (a) and (b) imply branching
 mania. So, given (a), branching mania can't be a reason to refuse
 (b).

(a) is everybody own's business. Nobody will ever know how many
local branches you have used to end up with that single patch or
two that finally go to the main repo. Same for branches in any
private repos you might have used to share previews of your work.
As long as it's not in the main repo, nobody should really care,
and you can use whatever make you feel happy. 

Branching mania is only a problem when this kind of structure
gets set in stone in the main repo by merging, instead of, say,
squashing stuff to palatable chunks and cherry-picking the result
to a mostly linear main repo.

Andre'

Re: Git workflow #2

[Julien Rioux]

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 that we cannot allow trusted developers to create branches,
| then maybe such branches can be allowed in the lyx-staging repo? Can
| we have branches in this one, please?

That would be better, but I do not understand why you couldn't have this
in your own repo.



And I don't understand why we couldn't have branches in our repo.
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.


Additional repos are really easy to handle with git remotes.
I'd even argue you won't really notice it.



Distribution of source code by dvd sent by mail is also really easy.

Look, it's not that hard but is additional maintenance burden to keep 
stuff in sync, and one is much more likely to do something stupid with 
merging commits or messing up any other way. I find branches simpler 
than remotes. I also do like having things centralized.



I honestly cannot be bothered at the moment to setup remote
repositories to fetch someone else's latest feature branch, let alone
setup my own copy of the repo on the server.


You are ready to write a 20-line-mail because you can't be bothered
to write a single 'git remote addname  git://...' line when you
need it? This does not make much sense to me.



Those are completely different. Since I got asked, it's polite to spent 
the time to answer. I also value the input of different opinions and 
voicing mine. Finally we're talking about a one-off discussion 
establishing a long term workflow for LyX coding which I do on a regular 
free-time permitting basis.


When I code with LyX, I test my own features thoroughly most of the 
time, but I rarely do it for others work. I like testing new stuff, but 
I will test run it most likely only when it comes into the main repo. 
More time spent on version control tasks spreads my coding time thinner. 
That's the bottom line personally.



I'm looking for a central place to have access and contribute to the
latest LyX development. (I'm also looking for a tool that is stupid
easy to use.) I hope that if it's not lyx.git, then please let
lyx-staging.git be this central place. Then it would be the main LyX
repo in my mind.

Anyway, that's just me. I'm curious to hear what others have to say.


There is no need to clutter The LyX Sources with work-in-progress
branches and lots of needless merges. It's not only ugly, but also
impacts stuff like 'git bisect'. Some things are simply better kept
linear...



No cluttering, no littering. Did I even mention merges? We need to agree 
on when, why and how to use branches, as said. Still don't see why not 
allow branches and require everyone to fork.



You want to keep it simple. Using git remotes _is_ simple.



Then it's great for you.


Andre'



Regards,
Julien

Re: Git workflow #2

[Lars Gullik Bjønnes]

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 nifty feature or particularly tough bug, he shouldn't
 recognize there is some difference between svn and git.
 You seem to have an aversion to branches, while I can't work without
 them anymore.
 There is a difference between (a) using branches for work (implementing
 stuff, checking out other people's work etc) and (b) having branches in
 the main repo. (a) does not imply (b).
 
 (a) does not imply (b), but both (a) and (b) imply branching
 mania. So, given (a), branching mania can't be a reason to refuse
 (b).

| (a) is everybody own's business. Nobody will ever know how many
| local branches you have used to end up with that single patch or
| two that finally go to the main repo. Same for branches in any
| private repos you might have used to share previews of your work.
| As long as it's not in the main repo, nobody should really care,
| and you can use whatever make you feel happy. 

| Branching mania is only a problem when this kind of structure
| gets set in stone in the main repo by merging, instead of, say,
| squashing stuff to palatable chunks and cherry-picking the result
| to a mostly linear main repo.

Hmm... non-linearity has little to do with branches. It only has to do
with parallel development.

Forcing something that really is non-linear into somthing that is not
good methinks.

But sure, it really takes disipline to not end up with merge-hell, we
you let history be non-linear. I rebase for small patches and one-off
changes, do real merges for feature branches etc.

-- 
   Lgb

Re: Git workflow #2

[Lars Gullik Bjønnes]

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 branches,
 | then maybe such branches can be allowed in the lyx-staging repo? Can
 | we have branches in this one, please?

 That would be better, but I do not understand why you couldn't have this
 in your own repo.


| And I don't understand why we couldn't have branches in our repo.

| I want it simple, and I want it centralized.

I have a suspision that you are new to git and distributed VCS? At least
before you decide what you really want I think you should try to do it
the git way.

-- 
   Lgb

Re: Git workflow #2

[Julien Rioux]

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 we cannot allow trusted developers to create branches,
| then maybe such branches can be allowed in the lyx-staging repo? Can
| we have branches in this one, please?

That would be better, but I do not understand why you couldn't have this
in your own repo.




| And I don't understand why we couldn't have branches in our repo.



| I want it simple, and I want it centralized.

I have a suspision that you are new to git and distributed VCS? At least
before you decide what you really want I think you should try to do it
the git way.



I've been pulling some projects for a few years, but I started really 
using git for contributions about 9 months ago. Not much experience with 
other distributed tools though, besides pulling from time to time.


--
Julien

Re: Git workflow #2

[Pavel Sanda]

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 fix a typo, fix 
> a warning on a different platform, fix a commit error, fix whitespace, fix 
> monolithic build, commit a forgotten file, etc.

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.

> When looking at the commits after a week of absence, I should get an easy 
> overview of which features are being developed

To me new branch is worth for work like bigger chunk of lyx2lyx commits
done last year by Richard or perhaps IPA-inset from last days. If these get 
branches you have easy overview of features developed but I believe that most
of nowadays commit traffic doesn't belong to this category. It's rather
chaotic mixture of cherishing things here and there and trying to impose
branch structure on that is more annoying tham having not so clean history.

> Would it be better for you if you could commit directly on the staging repo 
> of my proposal ?

Yes, probably (Richard's note about being overwhelmed apllies to me as well,
I don't see clearly into your proposal.)

> In principle, one should see this staging repo as current trunk.

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.

Now, you plan to to replace "stage" after main release by "devel" tree and start
from there again development, now with clearer history? What commit checksum
is primary for the pruposes of trac for example then?

> You only have to test the less stable one.

You mean staging, right?

Pavel

Re: Git workflow #2

[Vincent van Ravesteijn]

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, there are way too many commits that fix a typo, fix
a warning on a different platform, fix a commit error, fix whitespace, fix
monolithic build, commit a forgotten file, etc.

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 to branches, while I can't work without 
them anymore.



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.

Now, you plan to to replace "stage" after main release by "devel" tree 
and start from there again development, now with clearer history? What 
commit checksum is primary for the pruposes of trac for example then?


Whenever a feature gets into the official repo, it will not change 
anymore, and the sha1 will be definite.




You only have to test the less stable one.

You mean staging, right?


Yes.

Vincent

Re: Git workflow #2

[Richard Heck]

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 someone else's latest 
feature branch, let alone setup my own copy of the repo on the server. 
I'm looking for a central place to have access and contribute to the 
latest LyX development. (I'm also looking for a tool that is stupid 
easy to use.) I hope that if it's not lyx.git, then please let 
lyx-staging.git be this central place. Then it would be the main LyX 
repo in my mind.


Anyway, that's just me. I'm curious to hear what others have to say.

I don't see any need to *require* people to use private repos. For 
feature development, etc, one can continue to work locally, in private 
branches, in what is otherwise a clone of the main LyX repository. If 
one does want to work that way, then the only difference will be that 
pushes to the stable branch should be less frequent than they have been: 
Only when the feature is essentially done should any of it be pushed. 
Comments on code would go through the list only.


That said, this is less difficult than it seems. There's a bit of a 
learning curve here, to be sure, and I'm working pretty hard right now 
to understand it all. But once I have it figured out, I think I will be 
able to write instructions for setting up an appropriate development 
environment that are easy to follow and easy to use.


In this case, I don't think it's necessary to have extra repositories to 
fetch other people's feature branches and the like. I suppose one could 
do so, but my sense is that commentary, etc, on these branches will 
mostly happen through the online browser, rather than through checkout, 
or through people posting patch sets to the list, like before.


That said,

Richard

Re: Git workflow #2

[André Pönitz]

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 developers to create branches,
> >| then maybe such branches can be allowed in the lyx-staging repo? Can
> >| we have branches in this one, please?
> >
> >That would be better, but I do not understand why you couldn't have this
> >in your own repo.
> >
> 
> And I don't understand why we couldn't have branches in our repo.
> 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.

Additional repos are really easy to handle with git remotes.
I'd even argue you won't really notice it. 

> I honestly cannot be bothered at the moment to setup remote
> repositories to fetch someone else's latest feature branch, let alone
> setup my own copy of the repo on the server.

You are ready to write a 20-line-mail because you can't be bothered
to write a single 'git remote add  git://...' line when you
need it? This does not make much sense to me. 

> I'm looking for a central place to have access and contribute to the
> latest LyX development. (I'm also looking for a tool that is stupid
> easy to use.) I hope that if it's not lyx.git, then please let
> lyx-staging.git be this central place. Then it would be the main LyX
> repo in my mind.
> 
> Anyway, that's just me. I'm curious to hear what others have to say.

There is no need to clutter The LyX Sources with work-in-progress
branches and lots of needless merges. It's not only ugly, but also
impacts stuff like 'git bisect'. Some things are simply better kept
linear...

You want to keep it simple. Using git remotes _is_ simple.

Andre'

Re: Git workflow #2

[André Pönitz]

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 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 different platform, fix a commit error, fix whitespace, fix
> >>monolithic build, commit a forgotten file, etc.
> >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 to branches, while I can't work without
> them anymore.

There is a difference between (a) using branches for work (implementing
stuff, checking out other people's work etc) and (b) having branches in
the main repo. (a) does not imply (b).

Andre'

Re: Git workflow #2

[Vincent van Ravesteijn]

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 to branches, while I can't work without
them anymore.

There is a difference between (a) using branches for work (implementing
stuff, checking out other people's work etc) and (b) having branches in
the main repo. (a) does not imply (b).


(a) does not imply (b), but both (a) and (b) imply "branching mania". 
So, given (a), "branching mania" can't be a reason to refuse (b).



Andre'


Vincent

Re: Git workflow #2

[André Pönitz]

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 there is some difference between svn and git.
> >>You seem to have an aversion to branches, while I can't work without
> >>them anymore.
> >There is a difference between (a) using branches for work (implementing
> >stuff, checking out other people's work etc) and (b) having branches in
> >the main repo. (a) does not imply (b).
> 
> (a) does not imply (b), but both (a) and (b) imply "branching
> mania". So, given (a), "branching mania" can't be a reason to refuse
> (b).

(a) is everybody own's business. Nobody will ever know how many
local branches you have used to end up with that single patch or
two that finally go to the main repo. Same for branches in any
private repos you might have used to share previews of your work.
As long as it's not in the main repo, nobody should really care,
and you can use whatever make you feel happy. 

"Branching mania" is only a problem when this kind of structure
gets set in stone in the main repo by merging, instead of, say,
squashing stuff to palatable chunks and cherry-picking the result
to a mostly linear main repo.

Andre'

Re: Git workflow #2

[Julien Rioux]

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 that we cannot allow trusted developers to create branches,
| then maybe such branches can be allowed in the lyx-staging repo? Can
| we have branches in this one, please?

That would be better, but I do not understand why you couldn't have this
in your own repo.



And I don't understand why we couldn't have branches in our repo.
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.


Additional repos are really easy to handle with git remotes.
I'd even argue you won't really notice it.



Distribution of source code by dvd sent by mail is also really easy.

Look, it's not that hard but is additional maintenance burden to keep 
stuff in sync, and one is much more likely to do something stupid with 
merging commits or messing up any other way. I find branches simpler 
than remotes. I also do like having things centralized.



I honestly cannot be bothered at the moment to setup remote
repositories to fetch someone else's latest feature branch, let alone
setup my own copy of the repo on the server.


You are ready to write a 20-line-mail because you can't be bothered
to write a single 'git remote add  git://...' line when you
need it? This does not make much sense to me.



Those are completely different. Since I got asked, it's polite to spent 
the time to answer. I also value the input of different opinions and 
voicing mine. Finally we're talking about a one-off discussion 
establishing a long term workflow for LyX coding which I do on a regular 
free-time permitting basis.


When I code with LyX, I test my own features thoroughly most of the 
time, but I rarely do it for others work. I like testing new stuff, but 
I will test run it most likely only when it comes into the main repo. 
More time spent on version control tasks spreads my coding time thinner. 
That's the bottom line personally.



I'm looking for a central place to have access and contribute to the
latest LyX development. (I'm also looking for a tool that is stupid
easy to use.) I hope that if it's not lyx.git, then please let
lyx-staging.git be this central place. Then it would be the main LyX
repo in my mind.

Anyway, that's just me. I'm curious to hear what others have to say.


There is no need to clutter The LyX Sources with work-in-progress
branches and lots of needless merges. It's not only ugly, but also
impacts stuff like 'git bisect'. Some things are simply better kept
linear...



No cluttering, no littering. Did I even mention merges? We need to agree 
on when, why and how to use branches, as said. Still don't see why not 
allow branches and require everyone to fork.



You want to keep it simple. Using git remotes _is_ simple.



Then it's great for you.


Andre'



Regards,
Julien

Re: Git workflow #2

[Lars Gullik Bjønnes]

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
>> >>>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 to branches, while I can't work without
>> >>them anymore.
>> >There is a difference between (a) using branches for work (implementing
>> >stuff, checking out other people's work etc) and (b) having branches in
>> >the main repo. (a) does not imply (b).
>> 
>> (a) does not imply (b), but both (a) and (b) imply "branching
>> mania". So, given (a), "branching mania" can't be a reason to refuse
>> (b).
>
| (a) is everybody own's business. Nobody will ever know how many
| local branches you have used to end up with that single patch or
| two that finally go to the main repo. Same for branches in any
| private repos you might have used to share previews of your work.
| As long as it's not in the main repo, nobody should really care,
| and you can use whatever make you feel happy. 
>
| "Branching mania" is only a problem when this kind of structure
| gets set in stone in the main repo by merging, instead of, say,
| squashing stuff to palatable chunks and cherry-picking the result
| to a mostly linear main repo.

Hmm... non-linearity has little to do with branches. It only has to do
with parallel development.

Forcing something that really is non-linear into somthing that is not
good methinks.

But sure, it really takes disipline to not end up with "merge-hell", we
you let history be non-linear. I rebase for small patches and one-off
changes, do real merges for feature branches etc.

-- 
   Lgb

Re: Git workflow #2

[Lars Gullik Bjønnes]

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 developers to create branches,
>> | then maybe such branches can be allowed in the lyx-staging repo? Can
>> | we have branches in this one, please?
>>
>> That would be better, but I do not understand why you couldn't have this
>> in your own repo.
>>
>
| And I don't understand why we couldn't have branches in our repo.
>
| I want it simple, and I want it centralized.

I have a suspision that you are new to git and distributed VCS? At least
before you decide what you really want I think you should try to do it
the git way.

-- 
   Lgb

Re: Git workflow #2

[Julien Rioux]

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 that we cannot allow trusted developers to create branches,
| then maybe such branches can be allowed in the lyx-staging repo? Can
| we have branches in this one, please?

That would be better, but I do not understand why you couldn't have this
in your own repo.




| And I don't understand why we couldn't have branches in our repo.



| I want it simple, and I want it centralized.

I have a suspision that you are new to git and distributed VCS? At least
before you decide what you really want I think you should try to do it
the git way.



I've been pulling some projects for a few years, but I started really 
using git for contributions about 9 months ago. Not much experience with 
other distributed tools though, besides pulling from time to time.


--
Julien

Re: Git workflow #2

[Vincent van Ravesteijn]

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 different platform, fix a commit error, fix 
whitespace, fix monolithic build, commit a forgotten file, etc.


When looking at the commits after a week of absence, I should get an 
easy overview of which features are being developed


Would it be better for you if you could commit directly on the staging 
repo of my proposal ?


In principle, one should see this staging repo as current trunk.



I don't see we have enough testing power to afford two (moreless stable) 
trunks,
but no hard opinion about experimenting with it.



You only have to test the less stable one.





Last but not least:
For devs starting with git, there could be created with wiki page showing the
usual git-command workflow for these three typical cases and letting them
to join development process again and without reading books about git unless
they are pleased.


Yes, of course (when we know how developers are supposed to handle).

Vincent

Re: Git workflow #2

[Julien Rioux]

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 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 no
need to even remember that ever touch it.

2. Medium-time, e.g. ordinary bug fixing, in the order of hours/few days,
sometimes needs following commits.

3. Long-time goals, e.g. new-features, refactoring some aspect of the code,
in the range of weeks or days.

1  2:

Looking at the recent commit history shows that most of trunk movement consists
of 1  2 and I don't see much point for any feature-branch business
-- no matter whether technical solution is just another branch I would like to
see place where things can be pushed without practicing
git cloning/branching/merging, or even some later signaling that 'fixing typo in
PrefDocument.ui can be really merged now'. If maintainer is pleased there can
still be some separate stable tree where things go merged once a day/week, but
its his burden to take care of it or about potential merge conflicts.

I see that in some cases of 2. additional commit are applied but we shouldn't
value clean commit history at such high rates.


3:
Each feature has its own branch and if maintainer is pleased he can create
the whole cascade of stabilizing steps via merging. Vincent's proposal applies 
here.

I don't see we have enough testing power to afford two (moreless stable) 
trunks,
but no hard opinion about experimenting with it.
For sure no such distinction should be in 2.0.x branch.


Last but not least:
For devs starting with git, there could be created with wiki page showing the
usual git-command workflow for these three typical cases and letting them
to join development process again and without reading books about git unless
they are pleased.

Pavel
BTW Lars, can we get wiki and web working again? Christian stop to respond 
altogether..



Generally +1 and, unless someone is really pleased to work on his/her 
own dev/lyx-copy.git, it should be allowed to have feature branches 
directly in the main repo.


Regards,
Julien

Re: Git workflow #2

[Georg Baum]

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
no need to even remember that ever touch it.
 
 2. Medium-time, e.g. ordinary bug fixing, in the order of hours/few days,
sometimes needs following commits.
 
 3. Long-time goals, e.g. new-features, refactoring some aspect of the
 code,
in the range of weeks or days.
 
 1  2:
 
 Looking at the recent commit history shows that most of trunk movement
 consists of 1  2 and I don't see much point for any feature-branch
 business -- no matter whether technical solution is just another branch I
 would like to see place where things can be pushed without practicing
 git cloning/branching/merging, or even some later signaling that 'fixing
 typo in PrefDocument.ui can be really merged now'. If maintainer is
 pleased there can still be some separate stable tree where things go
 merged once a day/week, but its his burden to take care of it or about
 potential merge conflicts.
 
 I see that in some cases of 2. additional commit are applied but we
 shouldn't value clean commit history at such high rates.
 
 
 3:
 Each feature has its own branch and if maintainer is pleased he can create
 the whole cascade of stabilizing steps via merging. Vincent's proposal
 applies here.
 
 I don't see we have enough testing power to afford two (moreless stable)
 trunks, but no hard opinion about experimenting with it.
 For sure no such distinction should be in 2.0.x branch.

I agree completely with what you wrote, Pavel. For example, I do not test 
any work of other developers explicitly. I either test it implicitly if it 
comes in with git pull on the repo I am working on, or not at all. The 
reason is simply lack of time.

I addition, I strongly vote for disabling history rewriting on all public 
repos. This is something that is fine in personal working branches, but once 
a developer decides that a certain change is ready to leave the private area 
it should not be possible to alter it without leaving another record in the 
history. Otherwise you do not only create problems for other people using 
the public repo and need to set up rules like do not base your work on that 
repo, but you also open up a philosophical issue. Rewriting history in the 
real world is always manipulation, and it would smell like that also for a 
software repository.

Of course I realize that some developers really want to exercise the new 
flexibility offered by git. IMHO we should try to find a solution that both 
allows the more traditional style of working and the git power users one.


Georg

Re: Git workflow #2

[Lars Gullik Bjønnes]

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 goals and that everyone else will see,
it should not contain interim/changing work.

-- 
   Lgb

Re: Git workflow #2

[Lars Gullik Bjønnes]

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, distributions, git, gitolite etc.
but the wiki and how you do that is not something I have done anything
with before.

I'll try to if requried though. I will need very cleare reproducible
steps to see what is not working, and need to be told what really should
have happened as well. With.a.tea.spoon.

-- 
   Lgb

Re: Git workflow #2

[Julien Rioux]

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 in the main repo.



Please? I promise I'll behave!

To be precise I'm not talking about touching any of the sacred, pristine 
history branch(es) that Vincent wants. I'm talking about long-time 
features on the order of weeks. We can agree on a naming convention and 
a purpose for branches so that it is not what ever branch I want but 
whatever branches we want. In svn some branches were allowed and it 
would seem that git promotes this practice.



This is the repo with the higher goals and that everyone else will see,
it should not contain interim/changing work.



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 in the lyx-staging repo? Can we have 
branches in this one, please?


Regards,
Julien

Re: Git workflow #2

[Lars Gullik Bjønnes]

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 should
 not be allow to create what ever branch you want in the main repo.


| Please? I promise I'll behave!

But why?

This is the perfect case for a separate repo.


| To be precise I'm not talking about touching any of the sacred,
| pristine history branch(es) that Vincent wants. I'm talking about
| long-time features on the order of weeks. We can agree on a naming
| convention and a purpose for branches so that it is not what ever
| branch I want but whatever branches we want. In svn some branches
| were allowed and it would seem that git promotes this practice.

it svn that was the only way to share your work, not so with git.
And it is not what git promotes either.

 This is the repo with the higher goals and that everyone else will see,
 it should not contain interim/changing work.


| 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 in the lyx-staging repo? Can
| we have branches in this one, please?

That would be better, but I do not understand why you couldn't have this
in your own repo.

-- 
   Lgb

Re: Git workflow #2

[Julien Rioux]

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 in the lyx-staging repo? Can
| we have branches in this one, please?

That would be better, but I do not understand why you couldn't have this
in your own repo.



And I don't understand why we couldn't have branches in our repo.

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 else's latest feature branch, let 
alone setup my own copy of the repo on the server. I'm looking for a 
central place to have access and contribute to the latest LyX 
development. (I'm also looking for a tool that is stupid easy to use.) I 
hope that if it's not lyx.git, then please let lyx-staging.git be this 
central place. Then it would be the main LyX repo in my mind.


Anyway, that's just me. I'm curious to hear what others have to say.

Thanks for your replies and your time.
Regards,
Julien

Re: Git workflow #2

[Vincent van Ravesteijn]

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 different platform, fix a commit error, fix 
whitespace, fix monolithic build, commit a forgotten file, etc.


When looking at the commits after a week of absence, I should get an 
easy overview of which features are being developed


Would it be better for you if you could commit directly on the staging 
repo of my proposal ?


In principle, one should see this staging repo as current trunk.



I don't see we have enough testing power to afford two (more stable) 
trunks,
but no hard opinion about experimenting with it.



You only have to test the less stable one.





Last but not least:
For devs starting with git, there could be created with wiki page showing the
usual git-command workflow for these three typical cases and letting them
to join development process again and without reading books about git unless
they are pleased.


Yes, of course (when we know how developers are supposed to handle).

Vincent

Re: Git workflow #2

[Julien Rioux]

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 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 no
need to even remember that ever touch it.

2. Medium-time, e.g. ordinary bug fixing, in the order of hours/few days,
sometimes needs following commits.

3. Long-time goals, e.g. new-features, refactoring some aspect of the code,
in the range of weeks or days.

1&  2:

Looking at the recent commit history shows that most of trunk movement consists
of 1&  2 and I don't see much point for any feature-branch business
-- no matter whether technical solution is just another branch I would like to
see place where things can be pushed without practicing
git cloning/branching/merging, or even some later signaling that 'fixing typo in
PrefDocument.ui can be really merged now'. If maintainer is pleased there can
still be some separate stable tree where things go merged once a day/week, but
its his burden to take care of it or about potential merge conflicts.

I see that in some cases of 2. additional commit are applied but we shouldn't
value clean commit history at such high rates.


3:
Each feature has its own branch and if maintainer is pleased he can create
the whole cascade of stabilizing steps via merging. Vincent's proposal applies 
here.

I don't see we have enough testing power to afford two (more stable) 
trunks,
but no hard opinion about experimenting with it.
For sure no such distinction should be in 2.0.x branch.


Last but not least:
For devs starting with git, there could be created with wiki page showing the
usual git-command workflow for these three typical cases and letting them
to join development process again and without reading books about git unless
they are pleased.

Pavel
BTW Lars, can we get wiki and web working again? Christian stop to respond 
altogether..



Generally +1 and, unless someone is really pleased to work on his/her 
own dev/lyx-copy.git, it should be allowed to have feature branches 
directly in the main repo.


Regards,
Julien

Re: Git workflow #2

[Georg Baum]

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
>no need to even remember that ever touch it.
> 
> 2. Medium-time, e.g. ordinary bug fixing, in the order of hours/few days,
>sometimes needs following commits.
> 
> 3. Long-time goals, e.g. new-features, refactoring some aspect of the
> code,
>in the range of weeks or days.
> 
> 1 & 2:
> 
> Looking at the recent commit history shows that most of trunk movement
> consists of 1 & 2 and I don't see much point for any feature-branch
> business -- no matter whether technical solution is just another branch I
> would like to see place where things can be pushed without practicing
> git cloning/branching/merging, or even some later signaling that 'fixing
> typo in PrefDocument.ui can be really merged now'. If maintainer is
> pleased there can still be some separate stable tree where things go
> merged once a day/week, but its his burden to take care of it or about
> potential merge conflicts.
> 
> I see that in some cases of 2. additional commit are applied but we
> shouldn't value clean commit history at such high rates.
> 
> 
> 3:
> Each feature has its own branch and if maintainer is pleased he can create
> the whole cascade of stabilizing steps via merging. Vincent's proposal
> applies here.
> 
> I don't see we have enough testing power to afford two (more stable)
> trunks, but no hard opinion about experimenting with it.
> For sure no such distinction should be in 2.0.x branch.

I agree completely with what you wrote, Pavel. For example, I do not test 
any work of other developers explicitly. I either test it implicitly if it 
comes in with git pull on the repo I am working on, or not at all. The 
reason is simply lack of time.

I addition, I strongly vote for disabling history rewriting on all public 
repos. This is something that is fine in personal working branches, but once 
a developer decides that a certain change is ready to leave the private area 
it should not be possible to alter it without leaving another record in the 
history. Otherwise you do not only create problems for other people using 
the public repo and need to set up rules like "do not base your work on that 
repo", but you also open up a philosophical issue. Rewriting history in the 
real world is always manipulation, and it would smell like that also for a 
software repository.

Of course I realize that some developers really want to exercise the new 
flexibility offered by git. IMHO we should try to find a solution that both 
allows the more traditional style of working and the "git power users" one.


Georg

Re: Git workflow #2

[Lars Gullik Bjønnes]

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 higher goals and that everyone else will see,
it should not contain interim/changing work.

-- 
   Lgb

Re: Git workflow #2

[Lars Gullik Bjønnes]

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, distributions, git, gitolite etc.
but the wiki and how you do that is not something I have done anything
with before.

I'll try to if requried though. I will need very cleare reproducible
steps to see what is not working, and need to be told what really should
have happened as well. With.a.tea.spoon.

-- 
   Lgb

Re: Git workflow #2

[Julien Rioux]

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 want in the main repo.



Please? I promise I'll behave!

To be precise I'm not talking about touching any of the sacred, pristine 
history branch(es) that Vincent wants. I'm talking about long-time 
features on the order of weeks. We can agree on a naming convention and 
a purpose for branches so that it is not "what ever branch I want" but 
"whatever branches we want". In svn some branches were allowed and it 
would seem that git promotes this practice.



This is the repo with the higher goals and that everyone else will see,
it should not contain interim/changing work.



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 in the lyx-staging repo? Can we have 
branches in this one, please?


Regards,
Julien

Re: Git workflow #2

[Lars Gullik Bjønnes]

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. Plainly: no, you should
>> not be allow to create what ever branch you want in the main repo.
>>
>
| Please? I promise I'll behave!

But why?

This is the perfect case for a separate repo.

>
| To be precise I'm not talking about touching any of the sacred,
| pristine history branch(es) that Vincent wants. I'm talking about
| long-time features on the order of weeks. We can agree on a naming
| convention and a purpose for branches so that it is not "what ever
| branch I want" but "whatever branches we want". In svn some branches
| were allowed and it would seem that git promotes this practice.

it svn that was the only way to share your work, not so with git.
And it is not what git promotes either.

>> This is the repo with the higher goals and that everyone else will see,
>> it should not contain interim/changing work.
>>
>
| 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 in the lyx-staging repo? Can
| we have branches in this one, please?

That would be better, but I do not understand why you couldn't have this
in your own repo.

-- 
   Lgb

Re: Git workflow #2

[Julien Rioux]

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 in the lyx-staging repo? Can
| we have branches in this one, please?

That would be better, but I do not understand why you couldn't have this
in your own repo.



And I don't understand why we couldn't have branches in our repo.

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 else's latest feature branch, let 
alone setup my own copy of the repo on the server. I'm looking for a 
central place to have access and contribute to the latest LyX 
development. (I'm also looking for a tool that is stupid easy to use.) I 
hope that if it's not lyx.git, then please let lyx-staging.git be this 
central place. Then it would be the main LyX repo in my mind.


Anyway, that's just me. I'm curious to hear what others have to say.

Thanks for your replies and your time.
Regards,
Julien