Re: Re: Updates to gitolite progress

[Kornel Benko]

Am Donnerstag, 29. März 2012 um 00:53:28, schrieb Pavel Sanda sa...@lyx.org
 Abdelrazak Younes wrote:
  On 21/03/2012 17:44, Jean-Marc Lasgouttes wrote:
  Le 21/03/2012 16:14, Vincent van Ravesteijn a écrit :
  There is also a 2.0.x branch in your first clone, so you can just
  cherry-pick the commit to master directly onto this 2.0.x branch, and
  push from there.
 
  But If I want to compile both the master and the branch without doing a 
  full rebuild everytime, I have to have two checkouts living in different 
  places, right?
 
  No. You just need two build directories. At least with cmake... With 
  autoconf, you still need to run autogen.sh in source directory, which is 
  quite bad.
  With cmake, your source directory will stay as virgin of any generated file 
  as ever :-)
 
 You mean that cmake won't check for newer timestamps when you switch to 
 different
 branch?
 
 Pavel

Pavel, it is _make_, which is checking. And if we configured the dependencies 
correct,
then make will do also a correct check.

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: Re: Updates to gitolite progress

[Kornel Benko]

Am Donnerstag, 29. März 2012 um 00:53:28, schrieb Pavel Sanda 
> Abdelrazak Younes wrote:
> > On 21/03/2012 17:44, Jean-Marc Lasgouttes wrote:
> >> Le 21/03/2012 16:14, Vincent van Ravesteijn a écrit :
> >>> There is also a 2.0.x branch in your first clone, so you can just
> >>> cherry-pick the commit to master directly onto this 2.0.x branch, and
> >>> push from there.
> >>
> >> But If I want to compile both the master and the branch without doing a 
> >> full rebuild everytime, I have to have two checkouts living in different 
> >> places, right?
> >
> > No. You just need two build directories. At least with cmake... With 
> > autoconf, you still need to run autogen.sh in source directory, which is 
> > quite bad.
> > With cmake, your source directory will stay as virgin of any generated file 
> > as ever :-)
> 
> You mean that cmake won't check for newer timestamps when you switch to 
> different
> branch?
> 
> Pavel

Pavel, it is _make_, which is checking. And if we configured the dependencies 
correct,
then make will do also a correct check.

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: Updates to gitolite progress

[Abdelrazak Younes]

On Thu, Mar 29, 2012 at 12:53 AM, Pavel Sanda sa...@lyx.org wrote:
 Abdelrazak Younes wrote:
 On 21/03/2012 17:44, Jean-Marc Lasgouttes wrote:
 Le 21/03/2012 16:14, Vincent van Ravesteijn a écrit :
 There is also a 2.0.x branch in your first clone, so you can just
 cherry-pick the commit to master directly onto this 2.0.x branch, and
 push from there.

 But If I want to compile both the master and the branch without doing a
 full rebuild everytime, I have to have two checkouts living in different
 places, right?

 No. You just need two build directories. At least with cmake... With
 autoconf, you still need to run autogen.sh in source directory, which is
 quite bad.
 With cmake, your source directory will stay as virgin of any generated file
 as ever :-)

 You mean that cmake won't check for newer timestamps when you switch to 
 different
 branch?

No, I thought that git would also restore time stamps! I just checked
under Linux and it does not, that's weird, I was really sure that
would do that under Windows...

Abdel.

Re: Updates to gitolite progress

[Abdelrazak Younes]

On Thu, Mar 29, 2012 at 12:53 AM, Pavel Sanda  wrote:
> Abdelrazak Younes wrote:
>> On 21/03/2012 17:44, Jean-Marc Lasgouttes wrote:
>>> Le 21/03/2012 16:14, Vincent van Ravesteijn a écrit :
 There is also a 2.0.x branch in your first clone, so you can just
 cherry-pick the commit to master directly onto this 2.0.x branch, and
 push from there.
>>>
>>> But If I want to compile both the master and the branch without doing a
>>> full rebuild everytime, I have to have two checkouts living in different
>>> places, right?
>>
>> No. You just need two build directories. At least with cmake... With
>> autoconf, you still need to run autogen.sh in source directory, which is
>> quite bad.
>> With cmake, your source directory will stay as virgin of any generated file
>> as ever :-)
>
> You mean that cmake won't check for newer timestamps when you switch to 
> different
> branch?

No, I thought that git would also restore time stamps! I just checked
under Linux and it does not, that's weird, I was really sure that
would do that under Windows...

Abdel.

Re: Updates to gitolite progress

[Abdelrazak Younes]

On 21/03/2012 17:44, Jean-Marc Lasgouttes wrote:

Le 21/03/2012 16:14, Vincent van Ravesteijn a écrit :

There is also a 2.0.x branch in your first clone, so you can just
cherry-pick the commit to master directly onto this 2.0.x branch, and
push from there.


But If I want to compile both the master and the branch without doing 
a full rebuild everytime, I have to have two checkouts living in 
different places, right?


No. You just need two build directories. At least with cmake... With 
autoconf, you still need to run autogen.sh in source directory, which is 
quite bad.
With cmake, your source directory will stay as virgin of any generated 
file as ever :-)


Best is to put your 2 build dirs out of the git repo. But if you put 
them in there you can still add them to top-level .gitignore.


Cheers,
Abdel.

Re: Updates to gitolite progress

[Pavel Sanda]

Abdelrazak Younes wrote:
 On 21/03/2012 17:44, Jean-Marc Lasgouttes wrote:
 Le 21/03/2012 16:14, Vincent van Ravesteijn a écrit :
 There is also a 2.0.x branch in your first clone, so you can just
 cherry-pick the commit to master directly onto this 2.0.x branch, and
 push from there.

 But If I want to compile both the master and the branch without doing a 
 full rebuild everytime, I have to have two checkouts living in different 
 places, right?

 No. You just need two build directories. At least with cmake... With 
 autoconf, you still need to run autogen.sh in source directory, which is 
 quite bad.
 With cmake, your source directory will stay as virgin of any generated file 
 as ever :-)

You mean that cmake won't check for newer timestamps when you switch to 
different
branch?

Pavel

Re: Updates to gitolite progress

[Abdelrazak Younes]

On 21/03/2012 17:44, Jean-Marc Lasgouttes wrote:

Le 21/03/2012 16:14, Vincent van Ravesteijn a écrit :

There is also a 2.0.x branch in your first clone, so you can just
cherry-pick the commit to master directly onto this 2.0.x branch, and
push from there.


But If I want to compile both the master and the branch without doing 
a full rebuild everytime, I have to have two checkouts living in 
different places, right?


No. You just need two build directories. At least with cmake... With 
autoconf, you still need to run autogen.sh in source directory, which is 
quite bad.
With cmake, your source directory will stay as virgin of any generated 
file as ever :-)


Best is to put your 2 build dirs out of the git repo. But if you put 
them in there you can still add them to top-level ".gitignore".


Cheers,
Abdel.

Re: Updates to gitolite progress

[Pavel Sanda]

Abdelrazak Younes wrote:
> On 21/03/2012 17:44, Jean-Marc Lasgouttes wrote:
>> Le 21/03/2012 16:14, Vincent van Ravesteijn a écrit :
>>> There is also a 2.0.x branch in your first clone, so you can just
>>> cherry-pick the commit to master directly onto this 2.0.x branch, and
>>> push from there.
>>
>> But If I want to compile both the master and the branch without doing a 
>> full rebuild everytime, I have to have two checkouts living in different 
>> places, right?
>
> No. You just need two build directories. At least with cmake... With 
> autoconf, you still need to run autogen.sh in source directory, which is 
> quite bad.
> With cmake, your source directory will stay as virgin of any generated file 
> as ever :-)

You mean that cmake won't check for newer timestamps when you switch to 
different
branch?

Pavel

Re: Updates to gitolite progress

[Pavel Sanda]

Lars Gullik Bj?nnes wrote:
 | 1. Checkout full repo 
 | git clone g...@git.lyx.org:lyx trunk
 | 2. Full mirror of branch as well, not through clone
 | cp -r trunk branch; cd branch
 
 No...
 (perhaps... it does not seem optimal, does not take advantage that
 things are on same fs f.ex.))

It depends how you define optimal. Not optimal from hard drive free space.

However people here are asking how to start using git and take a few
first steps. Immediately they are fed by subtleties which will
bring error messages which are hard to understand.

It seems to me absurd that people who are not sure how to commit or
even use ssh keys are adviced to read about git internals or play
with git remote. 

Pavel

Re: Updates to gitolite progress

[Jean-Marc Lasgouttes]

Le 22/03/12 09:44, Pavel Sanda a écrit :

It seems to me absurd that people who are not sure how to commit or
even use ssh keys are adviced to read about git internals or play
with git remote.


Please, be polite with me! I may be an older person, but I know how to 
use ssh keys :)


JMarc

Re: Updates to gitolite progress

[Vincent van Ravesteijn]

On Thu, Mar 22, 2012 at 9:44 AM, Pavel Sanda sa...@lyx.org wrote:

 Lars Gullik Bj?nnes wrote:
  | 1. Checkout full repo
  | git clone g...@git.lyx.org:lyx trunk
  | 2. Full mirror of branch as well, not through clone
  | cp -r trunk branch; cd branch
 
  No...
  (perhaps... it does not seem optimal, does not take advantage that
  things are on same fs f.ex.))

 It depends how you define optimal. Not optimal from hard drive free space.

 However people here are asking how to start using git and take a few
 first steps. Immediately they are fed by subtleties which will
 bring error messages which are hard to understand.

 It seems to me absurd that people who are not sure how to commit or
 even use ssh keys are adviced to read about git internals or play
 with git remote.

 Pavel



On the other hand, they have had over a year to get some experience.

Vincent

Re: Updates to gitolite progress

[Pavel Sanda]

Jean-Marc Lasgouttes wrote:
 Le 22/03/12 09:44, Pavel Sanda a écrit :
 It seems to me absurd that people who are not sure how to commit or
 even use ssh keys are adviced to read about git internals or play
 with git remote.

 Please, be polite with me! I may be an older person, but I know how to use 
 ssh keys :)

I was talking about you? :)
Pavel

Re: Updates to gitolite progress

[Pavel Sanda]

Lars Gullik Bj?nnes wrote:
> | 1. Checkout full repo 
> | git clone g...@git.lyx.org:lyx trunk
> | 2. Full mirror of branch as well, not through clone
> | cp -r trunk branch; cd branch
> 
> No...
> (perhaps... it does not seem optimal, does not take advantage that
> things are on same fs f.ex.))

It depends how you define optimal. Not optimal from hard drive free space.

However people here are asking how to start using git and take a few
first steps. Immediately they are fed by subtleties which will
bring error messages which are hard to understand.

It seems to me absurd that people who are not sure how to commit or
even use ssh keys are adviced to read about git internals or play
with git remote. 

Pavel

Re: Updates to gitolite progress

[Jean-Marc Lasgouttes]

Le 22/03/12 09:44, Pavel Sanda a écrit :

It seems to me absurd that people who are not sure how to commit or
even use ssh keys are adviced to read about git internals or play
with git remote.


Please, be polite with me! I may be an older person, but I know how to 
use ssh keys :)


JMarc

Re: Updates to gitolite progress

[Vincent van Ravesteijn]

On Thu, Mar 22, 2012 at 9:44 AM, Pavel Sanda  wrote:

> Lars Gullik Bj?nnes wrote:
> > | 1. Checkout full repo
> > | git clone g...@git.lyx.org:lyx trunk
> > | 2. Full mirror of branch as well, not through clone
> > | cp -r trunk branch; cd branch
> >
> > No...
> > (perhaps... it does not seem optimal, does not take advantage that
> > things are on same fs f.ex.))
>
> It depends how you define optimal. Not optimal from hard drive free space.
>
> However people here are asking how to start using git and take a few
> first steps. Immediately they are fed by subtleties which will
> bring error messages which are hard to understand.
>
> It seems to me absurd that people who are not sure how to commit or
> even use ssh keys are adviced to read about git internals or play
> with git remote.
>
> Pavel
>


On the other hand, they have had over a year to get some experience.

Vincent

Re: Updates to gitolite progress

[Pavel Sanda]

Jean-Marc Lasgouttes wrote:
> Le 22/03/12 09:44, Pavel Sanda a écrit :
>> It seems to me absurd that people who are not sure how to commit or
>> even use ssh keys are adviced to read about git internals or play
>> with git remote.
>
> Please, be polite with me! I may be an older person, but I know how to use 
> ssh keys :)

I was talking about you? :)
Pavel

Re: Updates to gitolite progress

[Jean-Marc Lasgouttes]

Le 12/03/2012 19:56, Vincent van Ravesteijn a écrit :

If you want a tree for both 2.0.x and 2.1.0svn, you can do the following:

Assume you have a git clone in home/lyx, you can clone this with

git clone -s -b 2.0.x home/lyx home/lyx20x

This will clone your repo, but it will reuse the objects. This means
that the second repo is much smaller than the first one.


OK, I have done that, and now I am trying to backport a patch to branch. 
I don't want to be a git jedi just now, so I applied the patch I had to 
my 2.0.x branch checkout, did 'git add' for the modified files,

a commit for good measure.

I am happy, I can do 'git format-patch' and see a nice formated patch 
like the grown ups do.


Alas, now comes the time to put my patch to the git.lyx.org server. I do 
a 'git push' in my 2.0.x branch to see what happens. Things happen 
(cryptic messages I do not have anymore), but nothing in the lyx-cvs list.


OK, I think, the stuff has been committed from my shared 2.0.x directory 
to the original lyx checkout on my computer, so I have to push there too.


But when I push in lyx/ (which is the full checkout), I get:

fantomas: git push
To g...@git.lyx.org:lyx
 ! [rejected]2.0.x - 2.0.x (non-fast-forward)
error: failed to push some refs to 'g...@git.lyx.org:lyx'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes before pushing again.  See the 'Note about
fast-forwards' section of 'git push --help' for details.


Where do I go from there? There has to be a simple way to commit a patch 
to branch (please tell me there is!). I understand that plenty of 
probably exciting and complicated ways of working on a branch have been 
given, but I would like to start with trivial stuff like making a commit 
of a bite-size patch on a branch.


JMarc

Re: Updates to gitolite progress

[Vincent van Ravesteijn]

Op 21-3-2012 15:51, Jean-Marc Lasgouttes schreef:

Le 12/03/2012 19:56, Vincent van Ravesteijn a écrit :
If you want a tree for both 2.0.x and 2.1.0svn, you can do the 
following:


Assume you have a git clone in home/lyx, you can clone this with

git clone -s -b 2.0.x home/lyx home/lyx20x

This will clone your repo, but it will reuse the objects. This means
that the second repo is much smaller than the first one.


OK, I have done that, and now I am trying to backport a patch to 
branch. I don't want to be a git jedi just now, so I applied the patch 
I had to my 2.0.x branch checkout, did 'git add' for the modified files,

a commit for good measure.


There is also a 2.0.x branch in your first clone, so you can just 
cherry-pick the commit to master directly onto this 2.0.x branch, and 
push from there.




I am happy, I can do 'git format-patch' and see a nice formated patch 
like the grown ups do.


Alas, now comes the time to put my patch to the git.lyx.org server. I 
do a 'git push' in my 2.0.x branch to see what happens. Things happen 
(cryptic messages I do not have anymore), but nothing in the lyx-cvs 
list.


OK, I think, the stuff has been committed from my shared 2.0.x 
directory to the original lyx checkout on my computer, so I have to 
push there too.


Yes.

You can also push directly from your 2.0.x clone by adding the remote to 
this clone:


$ git remote add lyx g...@git.lyx.org:lyx

Now you can push your branch to lyx:

$ git push lyx 2.0.x

Use

$ git remote -v

to see the remotes that are set up for a clone. For your 2.0.x clone 
you'll indeed see that the origin the your original clone.




But when I push in lyx/ (which is the full checkout), I get:

fantomas: git push
To g...@git.lyx.org:lyx
 ! [rejected]2.0.x - 2.0.x (non-fast-forward)
error: failed to push some refs to 'g...@git.lyx.org:lyx'
To prevent you from losing history, non-fast-forward updates were 
rejected

Merge the remote changes before pushing again.  See the 'Note about
fast-forwards' section of 'git push --help' for details.


Where do I go from there? There has to be a simple way to commit a 
patch to branch (please tell me there is!). I understand that plenty 
of probably exciting and complicated ways of working on a branch have 
been given, but I would like to start with trivial stuff like making a 
commit of a bite-size patch on a branch.


The hint in the error message says that you have to merge the remote 
changes before you push. This is the same as that svn would tell you 
that your repo is not up to date.


Most probably the following will solve this:

$ git pull --rebase

(though I recommend to do 'git fetch', 'git merge --ff-only', and only 
rebase your feature branch on top of master when you really want to push 
it).





JMarc


Vincent

Re: Updates to gitolite progress

[Vincent van Ravesteijn]

There has to be a simple way to commit a patch to branch (please tell 
me there is!).




I forgot to mention: Ideally, if we do it the git-way completely, you 
would only have to commit a patch to the 2.0.x branch. Later, the 2.0.x 
will automatically be merged into the master. This can be done, because, 
in general, all fixes that go into 2.0.x are in master too.


Vincent

Re: Updates to gitolite progress

[Jean-Marc Lasgouttes]

Le 21/03/2012 16:56, Vincent van Ravesteijn a écrit :



There has to be a simple way to commit a patch to branch (please tell
me there is!).




I forgot to mention: Ideally, if we do it the git-way completely, you
would only have to commit a patch to the 2.0.x branch. Later, the 2.0.x
will automatically be merged into the master. This can be done, because,
in general, all fixes that go into 2.0.x are in master too.


That would mak sense. I intend t eventually understand the git way, but 
my first goal is to walk a few baby steps by myself.


JMarc

Re: Updates to gitolite progress

[Jean-Marc Lasgouttes]

Le 21/03/2012 16:14, Vincent van Ravesteijn a écrit :

There is also a 2.0.x branch in your first clone, so you can just
cherry-pick the commit to master directly onto this 2.0.x branch, and
push from there.


But If I want to compile both the master and the branch without doing a 
full rebuild everytime, I have to have two checkouts living in different 
places, right? And moreover, I have to update satus.20x.



You can also push directly from your 2.0.x clone by adding the remote to
this clone:

$ git remote add lyx g...@git.lyx.org:lyx


OK

Now you can push your branch to lyx:

$ git push lyx 2.0.x


How come I have to specify lyx 2.0.x. Isn't it possible to setup the 
branch so that git push will do the right thing?



The hint in the error message says that you have to merge the remote
changes before you push. This is the same as that svn would tell you
that your repo is not up to date.

Most probably the following will solve this:

$ git pull --rebase


In which repository?

Thanks.

JMarc

Re: Updates to gitolite progress

[Vincent van Ravesteijn]

Now you can push your branch to lyx:

$ git push lyx 2.0.x


How come I have to specify lyx 2.0.x. Isn't it possible to setup the 
branch so that git push will do the right thing?


git push will by default push to the remote which is tracked by the 
current branch. If the current branch does not track anything it will 
push to origin.


To see and edit what is being tracked by a branch, you can type

$ git config -e

There will be something like:

[branch 2.0.x]
remote = origin
merge = refs/heads/2.0.x

So, the branch 2.0.x tracks the branch 2.0.x from the remote origin. 
So, you can configure it however you want it.






The hint in the error message says that you have to merge the remote
changes before you push. This is the same as that svn would tell you
that your repo is not up to date.

Most probably the following will solve this:

$ git pull --rebase


In which repository?


In the one from where you are trying to push to the git.lyx.org from.

Vincent

Re: Updates to gitolite progress

[Pavel Sanda]

Jean-Marc Lasgouttes wrote:
 Le 21/03/2012 16:14, Vincent van Ravesteijn a écrit :
 There is also a 2.0.x branch in your first clone, so you can just
 cherry-pick the commit to master directly onto this 2.0.x branch, and
 push from there.

 But If I want to compile both the master and the branch without doing a 
 full rebuild everytime, I have to have two checkouts living in different 
 places, right? And moreover, I have to update satus.20x.

I believe more repositories are necessary and while its possible to clone
locally one from the other (and thus save some disk space), it will bring
problems with cryptic error messages for newcomers as you could see.

The simplest SVN-like scenario:

1. Checkout full repo 
git clone g...@git.lyx.org:lyx trunk
2. Full mirror of branch as well, not through clone
cp -r trunk branch; cd branch
3. Checkout branch 2.0.x
git checkout 2.0.x
   (by default you commit  push directly to 2.0.x branch in branch dir from 
now on)

Now for the commit backporting:
(4. commit  push change into trunk 5. go to branch directory)

6. git pull (receive trunk change to the branch repo as well)

One problem is that the commit never equals thanks to status.20x changes,
so one of many ways could be to remember hash from the trunk commit (say ) 
and:

7. git show  | git apply   (patch the current tree with the commit XXX)
8. add your changes to status.20x
9. git commit
10. git push

Pavel

Re: Updates to gitolite progress

[Tommaso Cucinotta]

Il 21/03/2012 16:44, Jean-Marc Lasgouttes ha scritto:

Le 21/03/2012 16:14, Vincent van Ravesteijn a écrit :

There is also a 2.0.x branch in your first clone, so you can just
cherry-pick the commit to master directly onto this 2.0.x branch, and
push from there.


But If I want to compile both the master and the branch without doing 
a full rebuild everytime, I have to have two checkouts living in 
different places,


that's how I'm used to work, also because normally I have different 
configure options for trunk/master (more debug) w.r.t. branch (less 
debug, more optimiz., try system libs). I've noted down the receipt I 
followed to share the patches between the two separate folders/repos, at:


  http://wiki.lyx.org/Devel/LyXGit

(last bullet of Cloning the Repository). I can't count how many warnings 
I received from git seniors about using --shared, still it's just what 
I need :-), as my disk-space is finite and my mobile broadband has a 
GB/month cap :-(.


T.

Re: Updates to gitolite progress

[Lars Gullik Bjønnes]

Vincent van Ravesteijn v...@lyx.org writes:

 There has to be a simple way to commit a patch to branch (please
 tell me there is!).


| I forgot to mention: Ideally, if we do it the git-way completely, you
| would only have to commit a patch to the 2.0.x branch. Later, the
| 2.0.x will automatically be merged into the master. This can be done,
| because, in general, all fixes that go into 2.0.x are in master too.

Hmm... that would be a very bad idea.
And the premise is in general not true.

-- 
   Lgb

Re: Updates to gitolite progress

[Lars Gullik Bjønnes]

Pavel Sanda sa...@lyx.org writes:

| Jean-Marc Lasgouttes wrote:
 Le 21/03/2012 16:14, Vincent van Ravesteijn a écrit :
 There is also a 2.0.x branch in your first clone, so you can just
 cherry-pick the commit to master directly onto this 2.0.x branch, and
 push from there.

 But If I want to compile both the master and the branch without doing a 
 full rebuild everytime, I have to have two checkouts living in different 
 places, right? And moreover, I have to update satus.20x.

| I believe more repositories are necessary and while its possible to clone
| locally one from the other (and thus save some disk space), it will bring
| problems with cryptic error messages for newcomers as you could see.

| The simplest SVN-like scenario:

| 1. Checkout full repo 
| git clone g...@git.lyx.org:lyx trunk
| 2. Full mirror of branch as well, not through clone
| cp -r trunk branch; cd branch

No...
(perhaps... it does not seem optimal, does not take advantage that
things are on same fs f.ex.))

-- 
   Lgb

Re: Updates to gitolite progress

[Jean-Marc Lasgouttes]

Le 12/03/2012 19:56, Vincent van Ravesteijn a écrit :

If you want a tree for both 2.0.x and 2.1.0svn, you can do the following:

Assume you have a git clone in /lyx, you can clone this with

git clone -s -b 2.0.x /lyx /lyx20x

This will clone your repo, but it will reuse the objects. This means
that the second repo is much smaller than the first one.


OK, I have done that, and now I am trying to backport a patch to branch. 
I don't want to be a git jedi just now, so I applied the patch I had to 
my 2.0.x branch checkout, did 'git add' for the modified files,

a commit for good measure.

I am happy, I can do 'git format-patch' and see a nice formated patch 
like the grown ups do.


Alas, now comes the time to put my patch to the git.lyx.org server. I do 
a 'git push' in my 2.0.x branch to see what happens. Things happen 
(cryptic messages I do not have anymore), but nothing in the lyx-cvs list.


OK, I think, the stuff has been committed from my shared 2.0.x directory 
to the original lyx checkout on my computer, so I have to push there too.


But when I push in lyx/ (which is the full checkout), I get:

fantomas: git push
To g...@git.lyx.org:lyx
 ! [rejected]2.0.x -> 2.0.x (non-fast-forward)
error: failed to push some refs to 'g...@git.lyx.org:lyx'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes before pushing again.  See the 'Note about
fast-forwards' section of 'git push --help' for details.


Where do I go from there? There has to be a simple way to commit a patch 
to branch (please tell me there is!). I understand that plenty of 
probably exciting and complicated ways of working on a branch have been 
given, but I would like to start with trivial stuff like making a commit 
of a bite-size patch on a branch.


JMarc

Re: Updates to gitolite progress

[Vincent van Ravesteijn]

Op 21-3-2012 15:51, Jean-Marc Lasgouttes schreef:

Le 12/03/2012 19:56, Vincent van Ravesteijn a écrit :
If you want a tree for both 2.0.x and 2.1.0svn, you can do the 
following:


Assume you have a git clone in /lyx, you can clone this with

git clone -s -b 2.0.x /lyx /lyx20x

This will clone your repo, but it will reuse the objects. This means
that the second repo is much smaller than the first one.


OK, I have done that, and now I am trying to backport a patch to 
branch. I don't want to be a git jedi just now, so I applied the patch 
I had to my 2.0.x branch checkout, did 'git add' for the modified files,

a commit for good measure.


There is also a 2.0.x branch in your first clone, so you can just 
cherry-pick the commit to master directly onto this 2.0.x branch, and 
push from there.




I am happy, I can do 'git format-patch' and see a nice formated patch 
like the grown ups do.


Alas, now comes the time to put my patch to the git.lyx.org server. I 
do a 'git push' in my 2.0.x branch to see what happens. Things happen 
(cryptic messages I do not have anymore), but nothing in the lyx-cvs 
list.


OK, I think, the stuff has been committed from my shared 2.0.x 
directory to the original lyx checkout on my computer, so I have to 
push there too.


Yes.

You can also push directly from your 2.0.x clone by adding the remote to 
this clone:


$ git remote add lyx g...@git.lyx.org:lyx

Now you can push your branch to "lyx":

$ git push lyx 2.0.x

Use

$ git remote -v

to see the remotes that are set up for a clone. For your 2.0.x clone 
you'll indeed see that the origin the your original clone.




But when I push in lyx/ (which is the full checkout), I get:

fantomas: git push
To g...@git.lyx.org:lyx
 ! [rejected]2.0.x -> 2.0.x (non-fast-forward)
error: failed to push some refs to 'g...@git.lyx.org:lyx'
To prevent you from losing history, non-fast-forward updates were 
rejected

Merge the remote changes before pushing again.  See the 'Note about
fast-forwards' section of 'git push --help' for details.


Where do I go from there? There has to be a simple way to commit a 
patch to branch (please tell me there is!). I understand that plenty 
of probably exciting and complicated ways of working on a branch have 
been given, but I would like to start with trivial stuff like making a 
commit of a bite-size patch on a branch.


The hint in the error message says that you have to merge the remote 
changes before you push. This is the same as that svn would tell you 
that your repo is not up to date.


Most probably the following will solve this:

$ git pull --rebase

(though I recommend to do 'git fetch', 'git merge --ff-only', and only 
rebase your feature branch on top of master when you really want to push 
it).





JMarc


Vincent

Re: Updates to gitolite progress

[Vincent van Ravesteijn]

There has to be a simple way to commit a patch to branch (please tell 
me there is!).




I forgot to mention: Ideally, if we do it the git-way completely, you 
would only have to commit a patch to the 2.0.x branch. Later, the 2.0.x 
will automatically be merged into the master. This can be done, because, 
in general, all fixes that go into 2.0.x are in master too.


Vincent

Re: Updates to gitolite progress

[Jean-Marc Lasgouttes]

Le 21/03/2012 16:56, Vincent van Ravesteijn a écrit :



There has to be a simple way to commit a patch to branch (please tell
me there is!).




I forgot to mention: Ideally, if we do it the git-way completely, you
would only have to commit a patch to the 2.0.x branch. Later, the 2.0.x
will automatically be merged into the master. This can be done, because,
in general, all fixes that go into 2.0.x are in master too.


That would mak sense. I intend t eventually understand the git way, but 
my first goal is to walk a few baby steps by myself.


JMarc

Re: Updates to gitolite progress

[Jean-Marc Lasgouttes]

Le 21/03/2012 16:14, Vincent van Ravesteijn a écrit :

There is also a 2.0.x branch in your first clone, so you can just
cherry-pick the commit to master directly onto this 2.0.x branch, and
push from there.


But If I want to compile both the master and the branch without doing a 
full rebuild everytime, I have to have two checkouts living in different 
places, right? And moreover, I have to update satus.20x.



You can also push directly from your 2.0.x clone by adding the remote to
this clone:

$ git remote add lyx g...@git.lyx.org:lyx


OK

Now you can push your branch to "lyx":

$ git push lyx 2.0.x


How come I have to specify "lyx 2.0.x". Isn't it possible to setup the 
branch so that "git push" will do the right thing?



The hint in the error message says that you have to merge the remote
changes before you push. This is the same as that svn would tell you
that your repo is not up to date.

Most probably the following will solve this:

$ git pull --rebase


In which repository?

Thanks.

JMarc

Re: Updates to gitolite progress

[Vincent van Ravesteijn]

Now you can push your branch to "lyx":

$ git push lyx 2.0.x


How come I have to specify "lyx 2.0.x". Isn't it possible to setup the 
branch so that "git push" will do the right thing?


"git push" will by default push to the remote which is tracked by the 
current branch. If the current branch does not track anything it will 
push to "origin".


To see and edit what is being tracked by a branch, you can type

$ git config -e

There will be something like:

[branch "2.0.x"]
remote = origin
merge = refs/heads/2.0.x

So, the branch 2.0.x tracks the branch "2.0.x" from the remote "origin". 
So, you can configure it however you want it.






The hint in the error message says that you have to merge the remote
changes before you push. This is the same as that svn would tell you
that your repo is not up to date.

Most probably the following will solve this:

$ git pull --rebase


In which repository?


In the one from where you are trying to push to the git.lyx.org from.

Vincent

Re: Updates to gitolite progress

[Pavel Sanda]

Jean-Marc Lasgouttes wrote:
> Le 21/03/2012 16:14, Vincent van Ravesteijn a écrit :
>> There is also a 2.0.x branch in your first clone, so you can just
>> cherry-pick the commit to master directly onto this 2.0.x branch, and
>> push from there.
>
> But If I want to compile both the master and the branch without doing a 
> full rebuild everytime, I have to have two checkouts living in different 
> places, right? And moreover, I have to update satus.20x.

I believe more repositories are necessary and while its possible to clone
locally one from the other (and thus save some disk space), it will bring
problems with cryptic error messages for newcomers as you could see.

The simplest SVN-like scenario:

1. Checkout full repo 
git clone g...@git.lyx.org:lyx trunk
2. Full mirror of branch as well, not through clone
cp -r trunk branch; cd branch
3. Checkout branch 2.0.x
git checkout 2.0.x
   (by default you commit & push directly to 2.0.x branch in "branch" dir from 
now on)

Now for the commit backporting:
(4. commit & push change into trunk 5. go to branch directory)

6. git pull (receive trunk change to the branch repo as well)

One problem is that the commit never equals thanks to status.20x changes,
so one of many ways could be to remember hash from the trunk commit (say ) 
and:

7. git show  | git apply   (patch the current tree with the commit XXX)
8. add your changes to status.20x
9. git commit
10. git push

Pavel

Re: Updates to gitolite progress

[Tommaso Cucinotta]

Il 21/03/2012 16:44, Jean-Marc Lasgouttes ha scritto:

Le 21/03/2012 16:14, Vincent van Ravesteijn a écrit :

There is also a 2.0.x branch in your first clone, so you can just
cherry-pick the commit to master directly onto this 2.0.x branch, and
push from there.


But If I want to compile both the master and the branch without doing 
a full rebuild everytime, I have to have two checkouts living in 
different places,


that's how I'm used to work, also because normally I have different 
configure options for trunk/master (more debug) w.r.t. branch (less 
debug, more optimiz., try system libs). I've noted down the receipt I 
followed to share the patches between the two separate folders/repos, at:


  http://wiki.lyx.org/Devel/LyXGit

(last bullet of Cloning the Repository). I can't count how many warnings 
I received from git seniors about using "--shared", still it's just what 
I need :-), as my disk-space is finite and my mobile broadband has a 
GB/month cap :-(.


T.

Re: Updates to gitolite progress

[Lars Gullik Bjønnes]

Vincent van Ravesteijn  writes:

>>> There has to be a simple way to commit a patch to branch (please
>>> tell me there is!).
>>
>
| I forgot to mention: Ideally, if we do it the git-way completely, you
| would only have to commit a patch to the 2.0.x branch. Later, the
| 2.0.x will automatically be merged into the master. This can be done,
| because, in general, all fixes that go into 2.0.x are in master too.

Hmm... that would be a very bad idea.
And the premise is in general not true.

-- 
   Lgb

Re: Updates to gitolite progress

[Lars Gullik Bjønnes]

Pavel Sanda  writes:

| Jean-Marc Lasgouttes wrote:
>> Le 21/03/2012 16:14, Vincent van Ravesteijn a écrit :
>>> There is also a 2.0.x branch in your first clone, so you can just
>>> cherry-pick the commit to master directly onto this 2.0.x branch, and
>>> push from there.
>>
>> But If I want to compile both the master and the branch without doing a 
>> full rebuild everytime, I have to have two checkouts living in different 
>> places, right? And moreover, I have to update satus.20x.
>
| I believe more repositories are necessary and while its possible to clone
| locally one from the other (and thus save some disk space), it will bring
| problems with cryptic error messages for newcomers as you could see.
>
| The simplest SVN-like scenario:
>
| 1. Checkout full repo 
| git clone g...@git.lyx.org:lyx trunk
| 2. Full mirror of branch as well, not through clone
| cp -r trunk branch; cd branch

No...
(perhaps... it does not seem optimal, does not take advantage that
things are on same fs f.ex.))

-- 
   Lgb

Re: Updates to gitolite progress

[Richard Heck]

On 03/14/2012 07:13 PM, Lars Gullik Bjønnes wrote:

Vincent van Ravesteijnv...@lyx.org  writes:

| How can you make your repo public ? (without the need of specifying
| all devs in the setperms)

The special user @all, gives every one with ssh keys access. daemon
enables anon access through git://..., gitweb enables web access.

| I wanted to fetch from Richard's repo.

richard must enable READERS @all

If you all agree on it, I can make that the default for developer repos.

I'd enable READERS @all gitweb by default. People can change it if 
they wish.


Richard

Re: Updates to gitolite progress

[Lars Gullik Bjønnes]

Richard Heck rgh...@comcast.net writes:

| On 03/14/2012 07:13 PM, Lars Gullik Bjønnes wrote:
 Vincent van Ravesteijnv...@lyx.org  writes:

 | How can you make your repo public ? (without the need of specifying
 | all devs in the setperms)

 The special user @all, gives every one with ssh keys access. daemon
 enables anon access through git://..., gitweb enables web access.

 | I wanted to fetch from Richard's repo.

 richard must enable READERS @all

 If you all agree on it, I can make that the default for developer repos.

| I'd enable READERS @all gitweb by default. People can change it if
| they wish.

No... changing the default is not possible methinks.
(not with the setperms mechanism)

But I can set R @all gitweb is default if you want, but then you
won't be able to turn it off.

-- 
   Lgb

Re: Updates to gitolite progress

[Richard Heck]

On 03/14/2012 07:13 PM, Lars Gullik Bjønnes wrote:

Vincent van Ravesteijn  writes:

| How can you make your repo public ? (without the need of specifying
| all devs in the setperms)

The special user "@all", gives every one with ssh keys access. "daemon"
enables anon access through git://..., "gitweb" enables web access.

| I wanted to fetch from Richard's repo.

richard must enable "READERS @all"

If you all agree on it, I can make that the default for developer repos.

I'd enable "READERS @all gitweb" by default. People can change it if 
they wish.


Richard

Re: Updates to gitolite progress

[Lars Gullik Bjønnes]

Richard Heck  writes:

| On 03/14/2012 07:13 PM, Lars Gullik Bjønnes wrote:
>> Vincent van Ravesteijn  writes:
>>
>> | How can you make your repo public ? (without the need of specifying
>> | all devs in the setperms)
>>
>> The special user "@all", gives every one with ssh keys access. "daemon"
>> enables anon access through git://..., "gitweb" enables web access.
>>
>> | I wanted to fetch from Richard's repo.
>>
>> richard must enable "READERS @all"
>>
>> If you all agree on it, I can make that the default for developer repos.
>>
| I'd enable "READERS @all gitweb" by default. People can change it if
| they wish.

No... changing the default is not possible methinks.
(not with the setperms mechanism)

But I can set "R @all gitweb" is default if you want, but then you
won't be able to turn it off.

-- 
   Lgb

Re: Updates to gitolite progress

[Jean-Marc Lasgouttes]

Le 12/03/2012 19:56, Vincent van Ravesteijn a écrit :

If you want a tree for both 2.0.x and 2.1.0svn, you can do the following:

Assume you have a git clone in home/lyx, you can clone this with

git clone -s -b 2.0.x home/lyx home/lyx20x

This will clone your repo, but it will reuse the objects. This means
that the second repo is much smaller than the first one.


When I try that, git tells me:

fantomas: git clone -s -b 2.0.x lyx 2.0.x
Initialized empty Git repository in /home/local/lasgoutt/lyx/2.0.x/.git/
warning: Remote branch 2.0.x not found in upstream origin, using HEAD 
instead



How do I know what branches exist in my lyx clone? I read a bit the git 
branch help, but was not really successful.


JMarc

Re: Updates to gitolite progress

[Vincent van Ravesteijn]

Op 14-3-2012 14:59, Jean-Marc Lasgouttes schreef:

Le 12/03/2012 19:56, Vincent van Ravesteijn a écrit :
If you want a tree for both 2.0.x and 2.1.0svn, you can do the 
following:


Assume you have a git clone in home/lyx, you can clone this with

git clone -s -b 2.0.x home/lyx home/lyx20x

This will clone your repo, but it will reuse the objects. This means
that the second repo is much smaller than the first one.


When I try that, git tells me:

fantomas: git clone -s -b 2.0.x lyx 2.0.x
Initialized empty Git repository in /home/local/lasgoutt/lyx/2.0.x/.git/
warning: Remote branch 2.0.x not found in upstream origin, using HEAD 
instead



As I also answered to Stephan, you need to checkout the 2.0.x first in 
the lyx clone, so that this branch is created and set up to track 
git.lyx.org.


How do I know what branches exist in my lyx clone? I read a bit the 
git branch help, but was not really successful.


'git branch' shows you the local branches. 'git branch -r' shows you the 
branches that exist in the remote.


Vincent

Re: Updates to gitolite progress

[Vincent van Ravesteijn]

| How can I assign rewrite or forced updates right to me for my own clone ?

You can't. But that you can't is a misconfiguration on my side. The
creator of that clone should have all rights.

I'll fix this.


Thanks, it's ok now.


You can give basic write and read access to others, but no rewind or
deletion. Nor branch cration (methinks).
If the demand is there I can setup so that this is possible as well.


How can you make your repo public ? (without the need of specifying all 
devs in the setperms)


I wanted to fetch from Richard's repo.

Vincent

Re: Updates to gitolite progress

[Lars Gullik Bjønnes]

Vincent van Ravesteijn v...@lyx.org writes:

 | How can I assign rewrite or forced updates right to me for my own clone ?

 You can't. But that you can't is a misconfiguration on my side. The
 creator of that clone should have all rights.

 I'll fix this.

| Thanks, it's ok now.

 You can give basic write and read access to others, but no rewind or
 deletion. Nor branch cration (methinks).
 If the demand is there I can setup so that this is possible as well.

| How can you make your repo public ? (without the need of specifying
| all devs in the setperms)

The special user @all, gives every one with ssh keys access. daemon
enables anon access through git://..., gitweb enables web access.

| I wanted to fetch from Richard's repo.

richard must enable READERS @all

If you all agree on it, I can make that the default for developer repos.

-- 
   Lgb

Re: Updates to gitolite progress

[Jean-Marc Lasgouttes]

Le 12/03/2012 19:56, Vincent van Ravesteijn a écrit :

If you want a tree for both 2.0.x and 2.1.0svn, you can do the following:

Assume you have a git clone in /lyx, you can clone this with

git clone -s -b 2.0.x /lyx /lyx20x

This will clone your repo, but it will reuse the objects. This means
that the second repo is much smaller than the first one.


When I try that, git tells me:

fantomas: git clone -s -b 2.0.x lyx 2.0.x
Initialized empty Git repository in /home/local/lasgoutt/lyx/2.0.x/.git/
warning: Remote branch 2.0.x not found in upstream origin, using HEAD 
instead



How do I know what branches exist in my lyx clone? I read a bit the "git 
branch" help, but was not really successful.


JMarc

Re: Updates to gitolite progress

[Vincent van Ravesteijn]

Op 14-3-2012 14:59, Jean-Marc Lasgouttes schreef:

Le 12/03/2012 19:56, Vincent van Ravesteijn a écrit :
If you want a tree for both 2.0.x and 2.1.0svn, you can do the 
following:


Assume you have a git clone in /lyx, you can clone this with

git clone -s -b 2.0.x /lyx /lyx20x

This will clone your repo, but it will reuse the objects. This means
that the second repo is much smaller than the first one.


When I try that, git tells me:

fantomas: git clone -s -b 2.0.x lyx 2.0.x
Initialized empty Git repository in /home/local/lasgoutt/lyx/2.0.x/.git/
warning: Remote branch 2.0.x not found in upstream origin, using HEAD 
instead



As I also answered to Stephan, you need to checkout the 2.0.x first in 
the lyx clone, so that this branch is created and set up to track 
git.lyx.org.


How do I know what branches exist in my lyx clone? I read a bit the 
"git branch" help, but was not really successful.


'git branch' shows you the local branches. 'git branch -r' shows you the 
branches that exist in the remote.


Vincent

Re: Updates to gitolite progress

[Vincent van Ravesteijn]

| How can I assign rewrite or forced updates right to me for my own clone ?

You can't. But that you can't is a misconfiguration on my side. The
creator of that clone should have all rights.

I'll fix this.


Thanks, it's ok now.


You can give basic write and read access to others, but no rewind or
deletion. Nor branch cration (methinks).
If the demand is there I can setup so that this is possible as well.


How can you make your repo public ? (without the need of specifying all 
devs in the setperms)


I wanted to fetch from Richard's repo.

Vincent

Re: Updates to gitolite progress

[Lars Gullik Bjønnes]

Vincent van Ravesteijn  writes:

>> | How can I assign rewrite or forced updates right to me for my own clone ?
>>
>> You can't. But that you can't is a misconfiguration on my side. The
>> creator of that clone should have all rights.
>>
>> I'll fix this.
>
| Thanks, it's ok now.
>
>> You can give basic write and read access to others, but no rewind or
>> deletion. Nor branch cration (methinks).
>> If the demand is there I can setup so that this is possible as well.
>
| How can you make your repo public ? (without the need of specifying
| all devs in the setperms)

The special user "@all", gives every one with ssh keys access. "daemon"
enables anon access through git://..., "gitweb" enables web access.

| I wanted to fetch from Richard's repo.

richard must enable "READERS @all"

If you all agree on it, I can make that the default for developer repos.

-- 
   Lgb

Re: Updates to gitolite progress

[Stephan Witt]

Am 12.03.2012 um 19:56 schrieb Vincent van Ravesteijn:

 Op 11-3-2012 22:43, Richard Heck schreef:
 On 03/11/2012 05:37 PM, Richard Heck wrote:
 On 03/11/2012 12:59 PM, Lars Gullik Bjønnes wrote:
 lar...@gullik.org (Lars Gullik Bjønnes) writes:
 
 | | 5. Enable the new lyx-devel git repo at git.lyx.org.
 
 The new repo has been made available to developers, and the git
 installation has opend up for developers to create their own repos and
 forks.
 
 Developers that have registered their public keys can clone the repo by:
 
 git clone g...@git.lyx.org:lyx
 
 Just so I understand where we are: This is just devel, or are the branches 
 also supposed to be in here? If so, where are they?
 
 Ahh, I see it now: git co 2.0.x will do what I wanted.
 
 
 If you want a tree for both 2.0.x and 2.1.0svn, you can do the following:
 
 Assume you have a git clone in home/lyx, you can clone this with
 
 git clone -s -b 2.0.x home/lyx home/lyx20x
 
 This will clone your repo, but it will reuse the objects. This means that the 
 second repo is much smaller than the first one.

% git clone -s -b 2.0.x lyx lyx20x
Cloning into 'lyx20x'...
done.
warning: Remote branch 2.0.x not found in upstream origin, using HEAD instead
%

What does this mean?
I suppose it is not possible to clone a branch after doing the mentioned git 
clone g...@git.lyx.org:lyx command.
I guess I have to create a full clone of the repository first to have that 
possibility.

Stephan

Re: Updates to gitolite progress

[Vincent van Ravesteijn]

First, you have to do

git checkout 2.0.x

This will create the branch from the upstream branch.

Vincent
Op 13 mrt. 2012 07:26 schreef Stephan Witt st.w...@gmx.net het volgende:


 Am 12.03.2012 um 19:56 schrieb Vincent van Ravesteijn:

  Op 11-3-2012 22:43, Richard Heck schreef:
  On 03/11/2012 05:37 PM, Richard Heck wrote:
  On 03/11/2012 12:59 PM, Lars Gullik Bjønnes wrote:
  lar...@gullik.org (Lars Gullik Bjønnes) writes:
 
  | | 5. Enable the new lyx-devel git repo at git.lyx.org.
 
  The new repo has been made available to developers, and the git
  installation has opend up for developers to create their own repos and
  forks.
 
  Developers that have registered their public keys can clone the repo
 by:
 
  git clone g...@git.lyx.org:lyx
 
  Just so I understand where we are: This is just devel, or are the
 branches also supposed to be in here? If so, where are they?
 
  Ahh, I see it now: git co 2.0.x will do what I wanted.
 
 
  If you want a tree for both 2.0.x and 2.1.0svn, you can do the following:
 
  Assume you have a git clone in home/lyx, you can clone this with
 
  git clone -s -b 2.0.x home/lyx home/lyx20x
 
  This will clone your repo, but it will reuse the objects. This means
 that the second repo is much smaller than the first one.

 % git clone -s -b 2.0.x lyx lyx20x
 Cloning into 'lyx20x'...
 done.
 warning: Remote branch 2.0.x not found in upstream origin, using HEAD
 instead
 %

 What does this mean?
 I suppose it is not possible to clone a branch after doing the mentioned
 git clone g...@git.lyx.org:lyx command.
 I guess I have to create a full clone of the repository first to have
 that possibility.

 Stephan

Re: Updates to gitolite progress

[Vincent van Ravesteijn]

| After that I will gradually make the new repo more and more accessiable:
| -  add to gitweb

added, viewable at http://git.lyx.org/

| -  add to daemon (enable + add)

added, anon access to close with

git clone git://git.lyx.org/lyx

is now enabled.


How can I assign rewrite or forced updates right to me for my own clone ?

Vincent

Re: Updates to gitolite progress

[Lars Gullik Bjønnes]

Vincent van Ravesteijn v...@lyx.org writes:

 | After that I will gradually make the new repo more and more accessiable:
 | -  add to gitweb

 added, viewable at http://git.lyx.org/

 | -  add to daemon (enable + add)

 added, anon access to close with

 git clone git://git.lyx.org/lyx

 is now enabled.

| How can I assign rewrite or forced updates right to me for my own clone ?

You can't. But that you can't is a misconfiguration on my side. The
creator of that clone should have all rights.

I'll fix this.

You can give basic write and read access to others, but no rewind or
deletion. Nor branch cration (methinks).
If the demand is there I can setup so that this is possible as well.

-- 
   Lgb

Re: Updates to gitolite progress

[Stephan Witt]

Am 12.03.2012 um 19:56 schrieb Vincent van Ravesteijn:

> Op 11-3-2012 22:43, Richard Heck schreef:
>> On 03/11/2012 05:37 PM, Richard Heck wrote:
>>> On 03/11/2012 12:59 PM, Lars Gullik Bjønnes wrote:
 lar...@gullik.org (Lars Gullik Bjønnes) writes:
 
 | | 5. Enable the new lyx-devel git repo at git.lyx.org.
 
 The new repo has been made available to developers, and the git
 installation has opend up for developers to create their own repos and
 forks.
 
 Developers that have registered their public keys can clone the repo by:
 
 git clone g...@git.lyx.org:lyx
 
>>> Just so I understand where we are: This is just devel, or are the branches 
>>> also supposed to be in here? If so, where are they?
>>> 
>> Ahh, I see it now: git co 2.0.x will do what I wanted.
>> 
> 
> If you want a tree for both 2.0.x and 2.1.0svn, you can do the following:
> 
> Assume you have a git clone in /lyx, you can clone this with
> 
> git clone -s -b 2.0.x /lyx /lyx20x
> 
> This will clone your repo, but it will reuse the objects. This means that the 
> second repo is much smaller than the first one.

% git clone -s -b 2.0.x lyx lyx20x
Cloning into 'lyx20x'...
done.
warning: Remote branch 2.0.x not found in upstream origin, using HEAD instead
%

What does this mean?
I suppose it is not possible to clone a branch after doing the mentioned "git 
clone g...@git.lyx.org:lyx" command.
I guess I have to create a "full" clone of the repository first to have that 
possibility.

Stephan

Re: Updates to gitolite progress

[Vincent van Ravesteijn]

First, you have to do

git checkout 2.0.x

This will create the branch from the upstream branch.

Vincent
Op 13 mrt. 2012 07:26 schreef "Stephan Witt"  het volgende:

>
> Am 12.03.2012 um 19:56 schrieb Vincent van Ravesteijn:
>
> > Op 11-3-2012 22:43, Richard Heck schreef:
> >> On 03/11/2012 05:37 PM, Richard Heck wrote:
> >>> On 03/11/2012 12:59 PM, Lars Gullik Bjønnes wrote:
>  lar...@gullik.org (Lars Gullik Bjønnes) writes:
> 
>  | | 5. Enable the new lyx-devel git repo at git.lyx.org.
> 
>  The new repo has been made available to developers, and the git
>  installation has opend up for developers to create their own repos and
>  forks.
> 
>  Developers that have registered their public keys can clone the repo
> by:
> 
>  git clone g...@git.lyx.org:lyx
> 
> >>> Just so I understand where we are: This is just devel, or are the
> branches also supposed to be in here? If so, where are they?
> >>>
> >> Ahh, I see it now: git co 2.0.x will do what I wanted.
> >>
> >
> > If you want a tree for both 2.0.x and 2.1.0svn, you can do the following:
> >
> > Assume you have a git clone in /lyx, you can clone this with
> >
> > git clone -s -b 2.0.x /lyx /lyx20x
> >
> > This will clone your repo, but it will reuse the objects. This means
> that the second repo is much smaller than the first one.
>
> % git clone -s -b 2.0.x lyx lyx20x
> Cloning into 'lyx20x'...
> done.
> warning: Remote branch 2.0.x not found in upstream origin, using HEAD
> instead
> %
>
> What does this mean?
> I suppose it is not possible to clone a branch after doing the mentioned
> "git clone g...@git.lyx.org:lyx" command.
> I guess I have to create a "full" clone of the repository first to have
> that possibility.
>
> Stephan

Re: Updates to gitolite progress

[Vincent van Ravesteijn]

| After that I will gradually make the new repo more and more accessiable:
| ->  add to gitweb

added, viewable at http://git.lyx.org/

| ->  add to daemon (enable + add)

added, anon access to close with

git clone git://git.lyx.org/lyx

is now enabled.


How can I assign rewrite or forced updates right to me for my own clone ?

Vincent

Re: Updates to gitolite progress

[Lars Gullik Bjønnes]

Vincent van Ravesteijn  writes:

>> | After that I will gradually make the new repo more and more accessiable:
>> | ->  add to gitweb
>>
>> added, viewable at http://git.lyx.org/
>>
>> | ->  add to daemon (enable + add)
>>
>> added, anon access to close with
>>
>> git clone git://git.lyx.org/lyx
>>
>> is now enabled.
>
| How can I assign rewrite or forced updates right to me for my own clone ?

You can't. But that you can't is a misconfiguration on my side. The
creator of that clone should have all rights.

I'll fix this.

You can give basic write and read access to others, but no rewind or
deletion. Nor branch cration (methinks).
If the demand is there I can setup so that this is possible as well.

-- 
   Lgb

Re: Updates to gitolite progress

[Vincent van Ravesteijn]

Op 12-3-2012 0:44, Lars Gullik Bjønnes schreef:

lar...@gullik.org (Lars Gullik Bjønnes) writes:

| lar...@gullik.org (Lars Gullik Bjønnes) writes:
| | -  write access for developers  (this might be moved up in the queue)
| I'll enable write access now, but with some limitations: you are not
| allowed to create new branches nor delete them. Also history rewind is
| not allowed.
| Also: try to avoid pointless merge commits.
| - multi commit features/work should be done on a separate branch (in
|   your local repo) and merged into the master branch when finished.
| - single commit work can with benefit be rebased on top of master
| A nice way to look at what the branch looks like (parallel-)history wise
| is to use gitk.

Also if you are bit unsure how to do all this, please do not just muddle
along and create a mess. What you should do is get some guidance:
(substitue larsbj with your own username)

   - fork the lyx repo:
  $ ssh g...@git.lyx.org fork lyx developers/larsbj/lyx
   - clone this repo:
  $ git clone g...@git.lyx.org:developers/larsbj/lyx lyx-larsbj
   - try to do all the changes to the best of you abilities,
 ask if you have any questions.
   - instead of doing a push to the real upstream repo, ask some of
 the other developers to have a look at your repo.
 (you have to anable read access for others to your repo: read
  ssh g...@git.lyx.org help)
   - this other developer can possibly help, or even to the upstream
  push for you (after he pulls your changed branch into his own
  repo)

If we play around a bit with this instead of just hitting the main repo
hard I really think we will end up in a lot better state, both process
wise and repo wise.

If we want to introduce a staging repo and can also be done, but we
shouldn't change to much at the same time.


Usually it is quite problematic to have a fellow developer to look at 
your proposed changes. Especially if the developers should look at ten 
different repositories.


That's why I would like a staging branch/repo. To have a single place 
where all the finished but not yet pushed work can be found.


Also, I would say it would be ok to rewrite the history in your personal 
branch. People should not base work on your personal branch. It's one of 
the advantages of git, that you can publish the work, that people can 
comment on it, and you reshape it before pushing it to the main repo/branch.


Vincent

Vincent

Re: Updates to gitolite progress

[Abdelrazak Younes]

On Mon, Mar 12, 2012 at 1:03 PM, Vincent van Ravesteijn v...@lyx.org wrote:
 Op 12-3-2012 0:44, Lars Gullik Bjønnes schreef:

First of all, thank you for this work Lars, this is a truly great
achievement :-)

 If we want to introduce a staging repo and can also be done, but we
 shouldn't change to much at the same time.

I strongly think that one repo per developper is way too complicated.

 Usually it is quite problematic to have a fellow developer to look at your
 proposed changes. Especially if the developers should look at ten different
 repositories.

 That's why I would like a staging branch/repo. To have a single place where
 all the finished but not yet pushed work can be found.

Fully agreed. I've tried both methods withing my team at work (using
mercurial not git but the idea is the same). Initially, one branch per
developper is really the way to go: It's easy to understand and to
follow:

You just do like you did with svn but committing only to your personal
branch. The only 2 additional steps is to merge from lyx-devel from
time to time. The lyx-devel maintainer will actually take care of
merging your personal branch to lyx-devel.

 Also, I would say it would be ok to rewrite the history in your personal
 branch. People should not base work on your personal branch. It's one of the
 advantages of git, that you can publish the work, that people can comment
 on it, and you reshape it before pushing it to the main repo/branch.

Agreed. But I actually think that the main repo should be pushed only
by the current maintainers: Richard and Vincent.
I would go even further:

The main repo would be automatically synchronized (only the 2.0 and
2.1 branches); either via a git hook or a cron script at server side.
The cron idea is better if only we had some automatic regression
testing in place. Then only those commits that passes regression on
the cooking repo would be pushed to the main repo.

Cheer,
Abdel.

Re: Updates to gitolite progress

[Rob Oakes]

On Mar 12, 2012, at 10:59 AM, Abdelrazak Younes wrote:

 The main repo would be automatically synchronized (only the 2.0 and
 2.1 branches); either via a git hook or a cron script at server side.
 The cron idea is better if only we had some automatic regression
 testing in place. Then only those commits that passes regression on
 the cooking repo would be pushed to the main repo.

Would it be possible to have the main repo also synchronized with the existing 
SVN? git-svn can transparently push right to an SVN repository. That would 
prevent a lot of things from breaking. For example, I've been keeping a mirror 
of SVN on Launchpad that I use for development, testing, and (hopefully) daily 
builds. Retooling this mirror to pull from git would require re-importing the 
whole thing (a multi-day affair).

If there is any way to keep our current SVN branch active with the canonical 
developer sources, that would be a wonderful thing. (Even if most of the 
development is happening in git.)

Cheers,

Rob

Re: Updates to gitolite progress

[Vincent van Ravesteijn]

Op 11-3-2012 22:43, Richard Heck schreef:

On 03/11/2012 05:37 PM, Richard Heck wrote:

On 03/11/2012 12:59 PM, Lars Gullik Bjønnes wrote:

lar...@gullik.org (Lars Gullik Bjønnes) writes:

| | 5. Enable the new lyx-devel git repo at git.lyx.org.

The new repo has been made available to developers, and the git
installation has opend up for developers to create their own repos and
forks.

Developers that have registered their public keys can clone the repo 
by:


git clone g...@git.lyx.org:lyx

Just so I understand where we are: This is just devel, or are the 
branches also supposed to be in here? If so, where are they?



Ahh, I see it now: git co 2.0.x will do what I wanted.



If you want a tree for both 2.0.x and 2.1.0svn, you can do the following:

Assume you have a git clone in home/lyx, you can clone this with

git clone -s -b 2.0.x home/lyx home/lyx20x

This will clone your repo, but it will reuse the objects. This means 
that the second repo is much smaller than the first one.


Vincent

Re: Updates to gitolite progress

[Vincent van Ravesteijn]

Op 12-3-2012 18:15, Rob Oakes schreef:

On Mar 12, 2012, at 10:59 AM, Abdelrazak Younes wrote:


The main repo would be automatically synchronized (only the 2.0 and
2.1 branches); either via a git hook or a cron script at server side.
The cron idea is better if only we had some automatic regression
testing in place. Then only those commits that passes regression on
the cooking repo would be pushed to the main repo.

Would it be possible to have the main repo also synchronized with the existing 
SVN? git-svn can transparently push right to an SVN repository.


Not anymore, the HEAD of the git repo has a different sha1 as the svn 
repo imported by git-svn. This because some tags and strange commits 
have been corrected in the git repo.



That would prevent a lot of things from breaking. For example, I've been 
keeping a mirror of SVN on Launchpad that I use for development, testing, and 
(hopefully) daily builds. Retooling this mirror to pull from git would require 
re-importing the whole thing (a multi-day affair).


Would it be really a multi-day affair ? Cloning the git repo is done 
within a minute, and you have the whole history with it.


Vincent

Re: Updates to gitolite progress

[Vincent van Ravesteijn]

Op 12-3-2012 0:44, Lars Gullik Bjønnes schreef:

   - fork the lyx repo:
  $ ssh g...@git.lyx.org fork lyx developers/larsbj/lyx


My personal repo does not appear in gitweb. Is it supposed to ?

Vincent

Re: Updates to gitolite progress

[Lars Gullik Bjønnes]

Vincent van Ravesteijn v...@lyx.org writes:

| Op 12-3-2012 0:44, Lars Gullik Bjønnes schreef:
- fork the lyx repo:
   $ ssh g...@git.lyx.org fork lyx developers/larsbj/lyx

| My personal repo does not appear in gitweb. Is it supposed to ?

It will only appear there if you give gitweb read access.

-- 
   Lgb

Re: Updates to gitolite progress

[Lars Gullik Bjønnes]

Vincent van Ravesteijn v...@lyx.org writes:

| Op 11-3-2012 22:43, Richard Heck schreef:
 On 03/11/2012 05:37 PM, Richard Heck wrote:
 On 03/11/2012 12:59 PM, Lars Gullik Bjønnes wrote:
 lar...@gullik.org (Lars Gullik Bjønnes) writes:

 | | 5. Enable the new lyx-devel git repo at git.lyx.org.

 The new repo has been made available to developers, and the git
 installation has opend up for developers to create their own repos and
 forks.

 Developers that have registered their public keys can clone the
 repo by:

 git clone g...@git.lyx.org:lyx

 Just so I understand where we are: This is just devel, or are the
 branches also supposed to be in here? If so, where are they?

 Ahh, I see it now: git co 2.0.x will do what I wanted.


| If you want a tree for both 2.0.x and 2.1.0svn, you can do the following:

| Assume you have a git clone in home/lyx, you can clone this with

| git clone -s -b 2.0.x home/lyx home/lyx20x

| This will clone your repo, but it will reuse the objects. This means
| that the second repo is much smaller than the first one.

Note that when using shared repos (-s), if you delete the first one the
second one dies as well.

If you just do a clone, you still get a massive (initial) space saving
sine git will just hardlinks to duplicate objects.

-- 
   Lgb

Re: Updates to gitolite progress

[Vincent van Ravesteijn]

Op 12-3-2012 20:17, Lars Gullik Bjønnes schreef:

Vincent van Ravesteijnv...@lyx.org  writes:

| Op 12-3-2012 0:44, Lars Gullik Bjønnes schreef:

- fork the lyx repo:
   $ ssh g...@git.lyx.org fork lyx developers/larsbj/lyx

| My personal repo does not appear in gitweb. Is it supposed to ?

It will only appear there if you give gitweb read access.


Thank you.

Vincent

Re: Updates to gitolite progress

[Vincent van Ravesteijn]

Op 12-3-2012 0:44, Lars Gullik Bjønnes schreef:

lar...@gullik.org (Lars Gullik Bjønnes) writes:

| lar...@gullik.org (Lars Gullik Bjønnes) writes:
| | ->  write access for developers  (this might be moved up in the queue)
| I'll enable write access now, but with some limitations: you are not
| allowed to create new branches nor delete them. Also history rewind is
| not allowed.
| Also: try to avoid pointless merge commits.
| - multi commit features/work should be done on a separate branch (in
|   your local repo) and merged into the master branch when finished.
| - single commit work can with benefit be rebased on top of master
| A nice way to look at what the branch looks like (parallel-)history wise
| is to use gitk.

Also if you are bit unsure how to do all this, please do not just muddle
along and create a mess. What you should do is get some guidance:
(substitue "larsbj" with your own username)

   - fork the lyx repo:
  $ ssh g...@git.lyx.org fork lyx developers/larsbj/lyx
   - clone this repo:
  $ git clone g...@git.lyx.org:developers/larsbj/lyx lyx-larsbj
   - try to do all the changes to the best of you abilities,
 ask if you have any questions.
   - instead of doing a push to the real upstream repo, ask some of
 the other developers to have a look at your repo.
 (you have to anable read access for others to your repo: read
  ssh g...@git.lyx.org help)
   - this other developer can possibly help, or even to the upstream
  push for you (after he pulls your changed branch into his own
  repo)

If we play around a bit with this instead of just hitting the main repo
hard I really think we will end up in a lot better state, both process
wise and repo wise.

If we want to introduce a staging repo and can also be done, but we
shouldn't change to much at the same time.


Usually it is quite problematic to have a fellow developer to look at 
your proposed changes. Especially if the developers should look at ten 
different repositories.


That's why I would like a staging branch/repo. To have a single place 
where all the finished but not yet pushed work can be found.


Also, I would say it would be ok to rewrite the history in your personal 
branch. People should not base work on your personal branch. It's one of 
the advantages of git, that you can "publish" the work, that people can 
comment on it, and you reshape it before pushing it to the main repo/branch.


Vincent

Vincent

Re: Updates to gitolite progress

[Abdelrazak Younes]

On Mon, Mar 12, 2012 at 1:03 PM, Vincent van Ravesteijn  wrote:
> Op 12-3-2012 0:44, Lars Gullik Bjønnes schreef:

First of all, thank you for this work Lars, this is a truly great
achievement :-)

>> If we want to introduce a staging repo and can also be done, but we
>> shouldn't change to much at the same time.

I strongly think that one repo per developper is way too complicated.

> Usually it is quite problematic to have a fellow developer to look at your
> proposed changes. Especially if the developers should look at ten different
> repositories.
>
> That's why I would like a staging branch/repo. To have a single place where
> all the finished but not yet pushed work can be found.

Fully agreed. I've tried both methods withing my team at work (using
mercurial not git but the idea is the same). Initially, one branch per
developper is really the way to go: It's easy to understand and to
follow:

You just do like you did with svn but committing only to your personal
branch. The only 2 additional steps is to merge from lyx-devel from
time to time. The lyx-devel maintainer will actually take care of
merging your personal branch to lyx-devel.

> Also, I would say it would be ok to rewrite the history in your personal
> branch. People should not base work on your personal branch. It's one of the
> advantages of git, that you can "publish" the work, that people can comment
> on it, and you reshape it before pushing it to the main repo/branch.

Agreed. But I actually think that the main repo should be pushed only
by the current maintainers: Richard and Vincent.
I would go even further:

The main repo would be automatically synchronized (only the 2.0 and
2.1 branches); either via a git hook or a cron script at server side.
The cron idea is better if only we had some automatic regression
testing in place. Then only those commits that passes regression on
the cooking repo would be pushed to the main repo.

Cheer,
Abdel.

Re: Updates to gitolite progress

[Rob Oakes]

On Mar 12, 2012, at 10:59 AM, Abdelrazak Younes wrote:

> The main repo would be automatically synchronized (only the 2.0 and
> 2.1 branches); either via a git hook or a cron script at server side.
> The cron idea is better if only we had some automatic regression
> testing in place. Then only those commits that passes regression on
> the cooking repo would be pushed to the main repo.

Would it be possible to have the main repo also synchronized with the existing 
SVN? git-svn can transparently push right to an SVN repository. That would 
prevent a lot of things from breaking. For example, I've been keeping a mirror 
of SVN on Launchpad that I use for development, testing, and (hopefully) daily 
builds. Retooling this mirror to pull from git would require re-importing the 
whole thing (a multi-day affair).

If there is any way to keep our current SVN branch active with the "canonical" 
developer sources, that would be a wonderful thing. (Even if most of the 
development is happening in git.)

Cheers,

Rob

Re: Updates to gitolite progress

[Vincent van Ravesteijn]

Op 11-3-2012 22:43, Richard Heck schreef:

On 03/11/2012 05:37 PM, Richard Heck wrote:

On 03/11/2012 12:59 PM, Lars Gullik Bjønnes wrote:

lar...@gullik.org (Lars Gullik Bjønnes) writes:

| | 5. Enable the new lyx-devel git repo at git.lyx.org.

The new repo has been made available to developers, and the git
installation has opend up for developers to create their own repos and
forks.

Developers that have registered their public keys can clone the repo 
by:


git clone g...@git.lyx.org:lyx

Just so I understand where we are: This is just devel, or are the 
branches also supposed to be in here? If so, where are they?



Ahh, I see it now: git co 2.0.x will do what I wanted.



If you want a tree for both 2.0.x and 2.1.0svn, you can do the following:

Assume you have a git clone in /lyx, you can clone this with

git clone -s -b 2.0.x /lyx /lyx20x

This will clone your repo, but it will reuse the objects. This means 
that the second repo is much smaller than the first one.


Vincent

Re: Updates to gitolite progress

[Vincent van Ravesteijn]

Op 12-3-2012 18:15, Rob Oakes schreef:

On Mar 12, 2012, at 10:59 AM, Abdelrazak Younes wrote:


The main repo would be automatically synchronized (only the 2.0 and
2.1 branches); either via a git hook or a cron script at server side.
The cron idea is better if only we had some automatic regression
testing in place. Then only those commits that passes regression on
the cooking repo would be pushed to the main repo.

Would it be possible to have the main repo also synchronized with the existing 
SVN? git-svn can transparently push right to an SVN repository.


Not anymore, the HEAD of the git repo has a different sha1 as the svn 
repo imported by git-svn. This because some tags and strange commits 
have been corrected in the git repo.



That would prevent a lot of things from breaking. For example, I've been 
keeping a mirror of SVN on Launchpad that I use for development, testing, and 
(hopefully) daily builds. Retooling this mirror to pull from git would require 
re-importing the whole thing (a multi-day affair).


Would it be really a multi-day affair ? Cloning the git repo is done 
within a minute, and you have the whole history with it.


Vincent

Re: Updates to gitolite progress

[Vincent van Ravesteijn]

Op 12-3-2012 0:44, Lars Gullik Bjønnes schreef:

   - fork the lyx repo:
  $ ssh g...@git.lyx.org fork lyx developers/larsbj/lyx


My personal repo does not appear in gitweb. Is it supposed to ?

Vincent

Re: Updates to gitolite progress

[Lars Gullik Bjønnes]

Vincent van Ravesteijn  writes:

| Op 12-3-2012 0:44, Lars Gullik Bjønnes schreef:
>>- fork the lyx repo:
>>   $ ssh g...@git.lyx.org fork lyx developers/larsbj/lyx
>
| My personal repo does not appear in gitweb. Is it supposed to ?

It will only appear there if you give "gitweb" read access.

-- 
   Lgb

Re: Updates to gitolite progress

[Lars Gullik Bjønnes]

Vincent van Ravesteijn  writes:

| Op 11-3-2012 22:43, Richard Heck schreef:
>> On 03/11/2012 05:37 PM, Richard Heck wrote:
>>> On 03/11/2012 12:59 PM, Lars Gullik Bjønnes wrote:
 lar...@gullik.org (Lars Gullik Bjønnes) writes:

 | | 5. Enable the new lyx-devel git repo at git.lyx.org.

 The new repo has been made available to developers, and the git
 installation has opend up for developers to create their own repos and
 forks.

 Developers that have registered their public keys can clone the
 repo by:

 git clone g...@git.lyx.org:lyx

>>> Just so I understand where we are: This is just devel, or are the
>>> branches also supposed to be in here? If so, where are they?
>>>
>> Ahh, I see it now: git co 2.0.x will do what I wanted.
>>
>
| If you want a tree for both 2.0.x and 2.1.0svn, you can do the following:
>
| Assume you have a git clone in /lyx, you can clone this with
>
| git clone -s -b 2.0.x /lyx /lyx20x
>
| This will clone your repo, but it will reuse the objects. This means
| that the second repo is much smaller than the first one.

Note that when using shared repos (-s), if you delete the first one the
second one dies as well.

If you just do a clone, you still get a massive (initial) space saving
sine git will just hardlinks to duplicate objects.

-- 
   Lgb

Re: Updates to gitolite progress

[Vincent van Ravesteijn]

Op 12-3-2012 20:17, Lars Gullik Bjønnes schreef:

Vincent van Ravesteijn  writes:

| Op 12-3-2012 0:44, Lars Gullik Bjønnes schreef:

- fork the lyx repo:
   $ ssh g...@git.lyx.org fork lyx developers/larsbj/lyx

| My personal repo does not appear in gitweb. Is it supposed to ?

It will only appear there if you give "gitweb" read access.


Thank you.

Vincent

Re: Updates to gitolite progress

[Lars Gullik Bjønnes]

lar...@gullik.org (Lars Gullik Bjønnes) writes:

| Lars Gullik Bjønnes lar...@gullik.org writes:

| | 3. Cleanup and verify the svn-git conversion that I already have in place.
| |   - Unless I have to redo anything this will be quite easy.

| | 4. Make the subversion repo read-only

| I am pretty much ready to do this now.

As of now the subversion repo is read-only.
(the lyx-devel part of it.)

-- 
   Lgb

Re: Updates to gitolite progress

[Vincent van Ravesteijn]

As of now the subversion repo is read-only. (the lyx-devel part of it.)

I'm waiting to see the lyx repo to appear on gitolite:)..

Vincent

Re: Updates to gitolite progress

[Lars Gullik Bjønnes]

lar...@gullik.org (Lars Gullik Bjønnes) writes:

| | 5. Enable the new lyx-devel git repo at git.lyx.org.

The new repo has been made available to developers, and the git
installation has opend up for developers to create their own repos and
forks.

Developers that have registered their public keys can clone the repo by:

git clone g...@git.lyx.org:lyx

Note that the forks and developer repos are intended as the developers
public repo in a sharing scenario. So these repos should be handled as
public repos, that means little or no history rewrites and rebases.

-- 
   Lgb

Re: Updates to gitolite progress

[Lars Gullik Bjønnes]

lar...@gullik.org (Lars Gullik Bjønnes) writes:

| | 5. Enable the new lyx-devel git repo at git.lyx.org.

| After that I will gradually make the new repo more and more accessiable:
| - add to gitweb

added, viewable at http://git.lyx.org/

| - add to daemon (enable + add)

added, anon access to close with

git clone git://git.lyx.org/lyx

is now enabled.

-- 
   Lgb

Re: Updates to gitolite progress

[Richard Heck]

On 03/11/2012 12:59 PM, Lars Gullik Bjønnes wrote:

lar...@gullik.org (Lars Gullik Bjønnes) writes:

| | 5. Enable the new lyx-devel git repo at git.lyx.org.

The new repo has been made available to developers, and the git
installation has opend up for developers to create their own repos and
forks.

Developers that have registered their public keys can clone the repo by:

git clone g...@git.lyx.org:lyx
Just so I understand where we are: This is just devel, or are the 
branches also supposed to be in here? If so, where are they?


Richard

Re: Updates to gitolite progress

[Richard Heck]

On 03/11/2012 05:37 PM, Richard Heck wrote:

On 03/11/2012 12:59 PM, Lars Gullik Bjønnes wrote:

lar...@gullik.org (Lars Gullik Bjønnes) writes:

| | 5. Enable the new lyx-devel git repo at git.lyx.org.

The new repo has been made available to developers, and the git
installation has opend up for developers to create their own repos and
forks.

Developers that have registered their public keys can clone the repo by:

git clone g...@git.lyx.org:lyx

Just so I understand where we are: This is just devel, or are the 
branches also supposed to be in here? If so, where are they?



Ahh, I see it now: git co 2.0.x will do what I wanted.

Richard

Re: Updates to gitolite progress

[Julien Rioux]

On 11/03/2012 12:59 PM, Lars Gullik Bjønnes wrote:

lar...@gullik.org (Lars Gullik Bjønnes) writes:

| | 5. Enable the new lyx-devel git repo at git.lyx.org.

The new repo has been made available to developers, and the git
installation has opend up for developers to create their own repos and
forks.

Developers that have registered their public keys can clone the repo by:

git clone g...@git.lyx.org:lyx

Note that the forks and developer repos are intended as the developers
public repo in a sharing scenario. So these repos should be handled as
public repos, that means little or no history rewrites and rebases.



Can we drop the git part of the repo's name? The LyX Source Repository 
makes it more official and less confusing.


Regards,
Julien

Re: Updates to gitolite progress

[Lars Gullik Bjønnes]

Julien Rioux jri...@physics.utoronto.ca writes:

| On 11/03/2012 12:59 PM, Lars Gullik Bjønnes wrote:
 lar...@gullik.org (Lars Gullik Bjønnes) writes:

 | | 5. Enable the new lyx-devel git repo at git.lyx.org.

 The new repo has been made available to developers, and the git
 installation has opend up for developers to create their own repos and
 forks.

 Developers that have registered their public keys can clone the repo by:

 git clone g...@git.lyx.org:lyx

 Note that the forks and developer repos are intended as the developers
 public repo in a sharing scenario. So these repos should be handled as
 public repos, that means little or no history rewrites and rebases.


| Can we drop the git part of the repo's name?

The repo's name is lyx or lyx.git

| The LyX Source Repository makes it more official and less confusing.

This would just be the description.

But sure.

-- 
   Lgb

Re: Updates to gitolite progress

[Lars Gullik Bjønnes]

lar...@gullik.org (Lars Gullik Bjønnes) writes:

| - add to trac

Trac also made available now. Might require some more work.

-- 
   Lgb

Re: Updates to gitolite progress

[Lars Gullik Bjønnes]

lar...@gullik.org (Lars Gullik Bjønnes) writes:

| - write access for developers  (this might be moved up in the queue)

I'll enable write access now, but with some limitations: you are not
allowed to create new branches nor delete them. Also history rewind is
not allowed.

Also: try to avoid pointless merge commits.
- multi commit features/work should be done on a separate branch (in
  your local repo) and merged into the master branch when finished.
- single commit work can with benefit be rebased on top of master

A nice way to look at what the branch looks like (parallel-)history wise
is to use gitk.

-- 
   Lgb

Re: Updates to gitolite progress

[Lars Gullik Bjønnes]

lar...@gullik.org (Lars Gullik Bjønnes) writes:

| lar...@gullik.org (Lars Gullik Bjønnes) writes:

| | - write access for developers  (this might be moved up in the queue)

| I'll enable write access now, but with some limitations: you are not
| allowed to create new branches nor delete them. Also history rewind is
| not allowed.

| Also: try to avoid pointless merge commits.
| - multi commit features/work should be done on a separate branch (in
|   your local repo) and merged into the master branch when finished.
| - single commit work can with benefit be rebased on top of master

| A nice way to look at what the branch looks like (parallel-)history wise
| is to use gitk.

Also if you are bit unsure how to do all this, please do not just muddle
along and create a mess. What you should do is get some guidance:
(substitue larsbj with your own username)

  - fork the lyx repo:
 $ ssh g...@git.lyx.org fork lyx developers/larsbj/lyx
  - clone this repo:
 $ git clone g...@git.lyx.org:developers/larsbj/lyx lyx-larsbj
  - try to do all the changes to the best of you abilities,
ask if you have any questions.
  - instead of doing a push to the real upstream repo, ask some of
the other developers to have a look at your repo.
(you have to anable read access for others to your repo: read
 ssh g...@git.lyx.org help)
  - this other developer can possibly help, or even to the upstream
 push for you (after he pulls your changed branch into his own
 repo)

If we play around a bit with this instead of just hitting the main repo
hard I really think we will end up in a lot better state, both process
wise and repo wise.

If we want to introduce a staging repo and can also be done, but we
shouldn't change to much at the same time.

-- 
   Lgb

Re: Updates to gitolite progress

[Lars Gullik Bjønnes]

Vincent van Ravesteijn v...@lyx.org writes:

| Op 5-3-2012 1:03, Lars Gullik Bjønnes schreef:
 I have added some more gitolite functionality.
 (only viewable for the people that has sent me their ssh public key.)

 ssh g...@git.lyx.org help

 You will not be able to fork anything yet, but as you can see at

 http://git.lyx.org/

| Browsing the repos seems to be broken right now.


 this is basically what it will look like.

 The plan forward is:

 1. Get the required hooks in place
- This is mostly the post-commit (post-receive really) hook that
 sends messages to lyx-...@lists.lyx.org

 2. See if we can get the trac connection setup.
- Should just be config, and a another hook to get updates to
 the repo signaled to trac.

 3. Cleanup and verify the svn-git conversion that I already have in place.
- Unless I have to redo anything this will be quite easy.

 4. Make the subversion repo read-only

 5. Enable the new lyx-devel git repo at git.lyx.org.

 I might be able to do this within the week.

 Comments or objections to the plan forward?

| We need to agree on how the workflow will be in the future. I'm
| convinced that a three-step approach is the best:
| 1. A developer develops a feature in a branch in his personal fork,
| 2. The branch gets pulled/pushed into a 'cooking' repo. It will stay
| in this repo until the feature is really finished, good and cleaned
| up.
| 3. Finally the feature gets merged into a release branch in the main repo.

I am not sold on the cooking repo.

I agree completely on step 1, except that I think it should be compbined
with the parts from step 2 about staying there until the feature is
finished and cleaned up. This repo should be shared with other
developers by using a public repo (developers/larsbj/lyx), or even
email,

One reason why I am not sole on the cooking repo is that we have very
limited testing resources and I am not sure if dividing those between a
cooking repo and a master repo is a good idea.



| Trivial features might get skip step 1, and might get to step 3
| quickly, whereas more complicated features take much more time to
| travel.


| My main motivation for this workflow is to make sure:
| - features do not change anymore after being merged into the main
| repo, therefore not cluttering the history,

There will be bugs.

| - it's easier to review groups of commits (branches) than to review
| all seperate commits of which a large part is not interesting or does
| not seem interesting (documentation updates, translations, cosmetics,
| small corrections to previous commits, fixing typos etc.

This means that all features/changes should as much as possible we
developed in their own branches and shown to others with a public repo
(developers/larsbj/lyx)

| This might also have consequences to which messages get send to the
| cvs-log list.

I think only the master repo should send anything to the cvs-log list.

| Last, I propose to have some mechanism to keep track of the status of
| a branch. This can be git notes, or a thread in the mailing list (with
| the subject designating the branch). Then it is easy to review all
| comments and changes to a certain branch before deciding whether it is
| ready or not.

This really seems awfully complex. And IMHO any kindo of freetext status
storage is bound to be incomplete and wrong.

Use the log and shortlog, and refere to bugs in commit messages.

-- 
   Lgb

Re: Updates to gitolite progress

[Lars Gullik Bjønnes]

lar...@gullik.org (Lars Gullik Bjønnes) writes:

| Lars Gullik Bjønnes  writes:
>
| | 3. Cleanup and verify the svn->git conversion that I already have in place.
| |   - Unless I have to redo anything this will be quite easy.
>>
| | 4. Make the subversion repo read-only
>
| I am pretty much ready to do this now.

As of now the subversion repo is read-only.
(the lyx-devel part of it.)

-- 
   Lgb

Re: Updates to gitolite progress

[Vincent van Ravesteijn]

As of now the subversion repo is read-only. (the lyx-devel part of it.)

I'm waiting to see the lyx repo to appear on gitolite:)..

Vincent

Re: Updates to gitolite progress

[Lars Gullik Bjønnes]

lar...@gullik.org (Lars Gullik Bjønnes) writes:

| | 5. Enable the new lyx-devel git repo at git.lyx.org.

The new repo has been made available to developers, and the git
installation has opend up for developers to create their own repos and
forks.

Developers that have registered their public keys can clone the repo by:

git clone g...@git.lyx.org:lyx

Note that the forks and developer repos are intended as the developers
public repo in a sharing scenario. So these repos should be handled as
public repos, that means little or no history rewrites and rebases.

-- 
   Lgb

Re: Updates to gitolite progress

[Lars Gullik Bjønnes]

lar...@gullik.org (Lars Gullik Bjønnes) writes:

| | 5. Enable the new lyx-devel git repo at git.lyx.org.
>
| After that I will gradually make the new repo more and more accessiable:
| -> add to gitweb

added, viewable at http://git.lyx.org/

| -> add to daemon (enable + add)

added, anon access to close with

git clone git://git.lyx.org/lyx

is now enabled.

-- 
   Lgb

Re: Updates to gitolite progress

[Richard Heck]

On 03/11/2012 12:59 PM, Lars Gullik Bjønnes wrote:

lar...@gullik.org (Lars Gullik Bjønnes) writes:

| | 5. Enable the new lyx-devel git repo at git.lyx.org.

The new repo has been made available to developers, and the git
installation has opend up for developers to create their own repos and
forks.

Developers that have registered their public keys can clone the repo by:

git clone g...@git.lyx.org:lyx
Just so I understand where we are: This is just devel, or are the 
branches also supposed to be in here? If so, where are they?


Richard

Re: Updates to gitolite progress

[Richard Heck]

On 03/11/2012 05:37 PM, Richard Heck wrote:

On 03/11/2012 12:59 PM, Lars Gullik Bjønnes wrote:

lar...@gullik.org (Lars Gullik Bjønnes) writes:

| | 5. Enable the new lyx-devel git repo at git.lyx.org.

The new repo has been made available to developers, and the git
installation has opend up for developers to create their own repos and
forks.

Developers that have registered their public keys can clone the repo by:

git clone g...@git.lyx.org:lyx

Just so I understand where we are: This is just devel, or are the 
branches also supposed to be in here? If so, where are they?



Ahh, I see it now: git co 2.0.x will do what I wanted.

Richard

Re: Updates to gitolite progress

[Julien Rioux]

On 11/03/2012 12:59 PM, Lars Gullik Bjønnes wrote:

lar...@gullik.org (Lars Gullik Bjønnes) writes:

| | 5. Enable the new lyx-devel git repo at git.lyx.org.

The new repo has been made available to developers, and the git
installation has opend up for developers to create their own repos and
forks.

Developers that have registered their public keys can clone the repo by:

git clone g...@git.lyx.org:lyx

Note that the forks and developer repos are intended as the developers
public repo in a sharing scenario. So these repos should be handled as
public repos, that means little or no history rewrites and rebases.



Can we drop the git part of the repo's name? "The LyX Source Repository" 
makes it more official and less confusing.


Regards,
Julien

Re: Updates to gitolite progress

[Lars Gullik Bjønnes]

Julien Rioux  writes:

| On 11/03/2012 12:59 PM, Lars Gullik Bjønnes wrote:
>> lar...@gullik.org (Lars Gullik Bjønnes) writes:
>>
>> | | 5. Enable the new lyx-devel git repo at git.lyx.org.
>>
>> The new repo has been made available to developers, and the git
>> installation has opend up for developers to create their own repos and
>> forks.
>>
>> Developers that have registered their public keys can clone the repo by:
>>
>> git clone g...@git.lyx.org:lyx
>>
>> Note that the forks and developer repos are intended as the developers
>> public repo in a sharing scenario. So these repos should be handled as
>> public repos, that means little or no history rewrites and rebases.
>>
>
| Can we drop the git part of the repo's name?

The repo's name is "lyx" or "lyx.git"

| "The LyX Source Repository" makes it more official and less confusing.

This would just be the description.

But sure.

-- 
   Lgb

Re: Updates to gitolite progress

[Lars Gullik Bjønnes]

lar...@gullik.org (Lars Gullik Bjønnes) writes:

| -> add to trac

Trac also made available now. Might require some more work.

-- 
   Lgb

Re: Updates to gitolite progress

[Lars Gullik Bjønnes]

lar...@gullik.org (Lars Gullik Bjønnes) writes:

| -> write access for developers  (this might be moved up in the queue)

I'll enable write access now, but with some limitations: you are not
allowed to create new branches nor delete them. Also history rewind is
not allowed.

Also: try to avoid pointless merge commits.
- multi commit features/work should be done on a separate branch (in
  your local repo) and merged into the master branch when finished.
- single commit work can with benefit be rebased on top of master

A nice way to look at what the branch looks like (parallel-)history wise
is to use gitk.

-- 
   Lgb

Re: Updates to gitolite progress

[Lars Gullik Bjønnes]

lar...@gullik.org (Lars Gullik Bjønnes) writes:

| lar...@gullik.org (Lars Gullik Bjønnes) writes:
>
| | -> write access for developers  (this might be moved up in the queue)
>
| I'll enable write access now, but with some limitations: you are not
| allowed to create new branches nor delete them. Also history rewind is
| not allowed.
>
| Also: try to avoid pointless merge commits.
| - multi commit features/work should be done on a separate branch (in
|   your local repo) and merged into the master branch when finished.
| - single commit work can with benefit be rebased on top of master
>
| A nice way to look at what the branch looks like (parallel-)history wise
| is to use gitk.

Also if you are bit unsure how to do all this, please do not just muddle
along and create a mess. What you should do is get some guidance:
(substitue "larsbj" with your own username)

  - fork the lyx repo:
 $ ssh g...@git.lyx.org fork lyx developers/larsbj/lyx
  - clone this repo:
 $ git clone g...@git.lyx.org:developers/larsbj/lyx lyx-larsbj
  - try to do all the changes to the best of you abilities,
ask if you have any questions.
  - instead of doing a push to the real upstream repo, ask some of
the other developers to have a look at your repo.
(you have to anable read access for others to your repo: read
 ssh g...@git.lyx.org help)
  - this other developer can possibly help, or even to the upstream
 push for you (after he pulls your changed branch into his own
 repo)

If we play around a bit with this instead of just hitting the main repo
hard I really think we will end up in a lot better state, both process
wise and repo wise.

If we want to introduce a staging repo and can also be done, but we
shouldn't change to much at the same time.

-- 
   Lgb

Re: Updates to gitolite progress

[Lars Gullik Bjønnes]

Vincent van Ravesteijn  writes:

| Op 5-3-2012 1:03, Lars Gullik Bjønnes schreef:
>> I have added some more gitolite functionality.
>> (only viewable for the people that has sent me their ssh public key.)
>>
>> ssh g...@git.lyx.org help
>>
>> You will not be able to fork anything yet, but as you can see at
>>
>> http://git.lyx.org/
>
| Browsing the repos seems to be broken right now.
>
>>
>> this is basically what it will look like.
>>
>> The plan forward is:
>>
>> 1. Get the required hooks in place
>>- This is mostly the post-commit (post-receive really) hook that
>> sends messages to lyx-...@lists.lyx.org
>>
>> 2. See if we can get the trac connection setup.
>>- Should just be config, and a another hook to get updates to
>> the repo signaled to trac.
>>
>> 3. Cleanup and verify the svn->git conversion that I already have in place.
>>- Unless I have to redo anything this will be quite easy.
>>
>> 4. Make the subversion repo read-only
>>
>> 5. Enable the new lyx-devel git repo at git.lyx.org.
>>
>> I might be able to do this within the week.
>>
>> Comments or objections to the plan forward?
>
| We need to agree on how the workflow will be in the future. I'm
| convinced that a three-step approach is the best:
| 1. A developer develops a feature in a branch in his personal fork,
| 2. The branch gets pulled/pushed into a 'cooking' repo. It will stay
| in this repo until the feature is really finished, good and cleaned
| up.
| 3. Finally the feature gets merged into a release branch in the main repo.

I am not sold on the cooking repo.

I agree completely on step 1, except that I think it should be compbined
with the parts from step 2 about staying there until the feature is
finished and cleaned up. This repo should be shared with other
developers by using a public repo (developers/larsbj/lyx), or even
email,

One reason why I am not sole on the cooking repo is that we have very
limited testing resources and I am not sure if dividing those between a
cooking repo and a master repo is a good idea.


>
| Trivial features might get skip step 1, and might get to step 3
| quickly, whereas more complicated features take much more time to
| travel.

>
| My main motivation for this workflow is to make sure:
| - features do not change anymore after being merged into the main
| repo, therefore not cluttering the history,

There will be bugs.

| - it's easier to review groups of commits (branches) than to review
| all seperate commits of which a large part is not interesting or does
| not seem interesting (documentation updates, translations, cosmetics,
| small corrections to previous commits, fixing typos etc.

This means that all features/changes should as much as possible we
developed in their own branches and shown to others with a public repo
(developers/larsbj/lyx)

| This might also have consequences to which messages get send to the
| cvs-log list.

I think only the master repo should send anything to the cvs-log list.

| Last, I propose to have some mechanism to keep track of the status of
| a branch. This can be git notes, or a thread in the mailing list (with
| the subject designating the branch). Then it is easy to review all
| comments and changes to a certain branch before deciding whether it is
| ready or not.

This really seems awfully complex. And IMHO any kindo of freetext status
storage is bound to be incomplete and wrong.

Use the log and shortlog, and refere to bugs in commit messages.

-- 
   Lgb

Re: Updates to gitolite progress

[Lars Gullik Bjønnes]

Lars Gullik Bjønnes lar...@gullik.org writes:

| 2. See if we can get the trac connection setup.
|   - Should just be config, and a another hook to get updates to
| the repo signaled to trac.

I have added the git testing repo to trac. It seems to work fine. I have
not added any trac specific hooks, but I'll to that if required later.

http://www.lyx.org/trac/browser

-- 
   Lgb

Re: Updates to gitolite progress

[Lars Gullik Bjønnes]

Lars Gullik Bjønnes lar...@gullik.org writes:

| 3. Cleanup and verify the svn-git conversion that I already have in place.
|   - Unless I have to redo anything this will be quite easy.

| 4. Make the subversion repo read-only

I am pretty much ready to do this now.
From the moment I turn off the svn repo (read: make it read-only), I
need about an hour to do final de-grafting and empty commit removal.
(The resulting repo is then about 146MB)

After I move this shiny new repo to the lyx server I will at first only
enable it for those of the developers that has sent me their public ssh
keys. First they will only get read-only access, hopefully someone will
clone the repo and help verify that everything is fine and that I have
not missed anything. Look especially at branches and tags.

If I have to ready stuff that might very well mean a delay of several
days, so in that case I will turn on write access to the svn repo again.

| 5. Enable the new lyx-devel git repo at git.lyx.org.

After that I will gradually make the new repo more and more accessiable:
- add to gitweb
- add to trac
- add to daemon (enable + add)
- write access for developers  (this might be moved up in the queue)

| Comments or objections to the plan forward?
any?

-- 
   Lgb