Re: GIT as vcs for lyx documents

[Rainer M Krug]

So - could somebody guide me into the direction where I could look at the
code for vcs handling in LyX?

Rainer

On Mon, Jul 11, 2011 at 4:52 PM, Pavel Sanda sa...@lyx.org wrote:

 Rainer M Krug wrote:
  On Mon, Jul 11, 2011 at 4:40 PM, Pavel Sanda sa...@lyx.org wrote:
  This mustn't happen - but isn't this risk higher when we are trying to
 use
  own / copied routines to check then using an established command like
 git
  status?

 this is not about using our code vs parsing git output but
 detecting git vs ignore git VCS.

  For the medium term: what about per file or general options, which enable
  certain vcs?

 general (by default disabled) option like git support was the only
 solution
 i was able to come with.

 pavel




-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax (F):   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug

Re: GIT as vcs for lyx documents

[Richard Heck]

On 07/13/2011 05:23 AM, Rainer M Krug wrote:
 So - could somebody guide me into the direction where I could look at
 the code for vcs handling in LyX?

src/VCBackend.cpp

rh

Re: GIT as vcs for lyx documents

[Rainer M Krug]

On Wed, Jul 13, 2011 at 3:53 PM, Richard Heck rgh...@comcast.net wrote:

 On 07/13/2011 05:23 AM, Rainer M Krug wrote:
  So - could somebody guide me into the direction where I could look at
  the code for vcs handling in LyX?
 
 src/VCBackend.cpp


Thanks

Rainer



 rh




-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax (F):   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug

Re: GIT as vcs for lyx documents

[Rainer M Krug]

So - could somebody guide me into the direction where I could look at the
code for vcs handling in LyX?

Rainer

On Mon, Jul 11, 2011 at 4:52 PM, Pavel Sanda  wrote:

> Rainer M Krug wrote:
> > On Mon, Jul 11, 2011 at 4:40 PM, Pavel Sanda  wrote:
> > This mustn't happen - but isn't this risk higher when we are trying to
> use
> > own / copied routines to check then using an established command like
> "git
> > status"?
>
> this is not about "using our code" vs "parsing git output" but
> "detecting git" vs "ignore git VCS".
>
> > For the medium term: what about per file or general options, which enable
> > certain vcs?
>
> general (by default disabled) option like "git support" was the only
> solution
> i was able to come with.
>
> pavel
>



-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax (F):   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug

Re: GIT as vcs for lyx documents

[Richard Heck]

On 07/13/2011 05:23 AM, Rainer M Krug wrote:
> So - could somebody guide me into the direction where I could look at
> the code for vcs handling in LyX?
>
src/VCBackend.cpp

rh

Re: GIT as vcs for lyx documents

[Rainer M Krug]

On Wed, Jul 13, 2011 at 3:53 PM, Richard Heck  wrote:

> On 07/13/2011 05:23 AM, Rainer M Krug wrote:
> > So - could somebody guide me into the direction where I could look at
> > the code for vcs handling in LyX?
> >
> src/VCBackend.cpp
>

Thanks

Rainer


>
> rh
>
>


-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax (F):   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug

Re: GIT as vcs for lyx documents

[Richard Heck]

On 07/11/2011 07:52 AM, Rainer M Krug wrote:
 Hi,

 / /I know that git is not integrated as a vcs for LyX documents, but
 how much work would t be to include it? I remember reading somewhere
 that just a few scripts have to be changed - could somebody point me
 into the right direction?

 Richard Heck wrote (on 4/30/2010):
  
  Pavel,
  
  I seem to remember that there were some issues you ran into when
  thinking about adding git as backend for LyX VC. What were those?

 1. detection we are inside repo.
 2. different workflow than rcs/cvs/svn especially difference between
committing and pushing.

 it would need to re-think VCS API we have and possibly do some brainstorming
 especially about point 2, because it is not clear to me what operations /
 workflow should we actually support.

 all this is doable but in the order of magnitude harder than it was with
 adding(fixing) CVS support.

(i) is certainly fixable, in the sense that we can spawn git status
and check the return value, but it is not as easy as looking for .svn,
say. (ii) is definitely a different issue.

Richard

Re: GIT as vcs for lyx documents

[Vincent van Ravesteijn]

(i) is certainly fixable, in the sense that we can spawn git status 
and check the return value, but it is not as easy as looking for .svn, 
say.


We can just copy-paste the code that git uses itself to detect whether 
it is in a repo or not ?



(ii) is definitely a different issue.


it depends on how complex you want to make. You can easily mimick the 
svn workflow: push after every commit. Or you can make two options: 
commit and push. Not so big deal, right ?


Richard


Vincent

Re: GIT as vcs for lyx documents

[Rainer M Krug]

On Mon, Jul 11, 2011 at 3:32 PM, Vincent van Ravesteijn v...@lyx.org wrote:

OK - so not as easy as I rememeber - well..


 (i) is certainly fixable, in the sense that we can spawn git status and
 check the return value, but it is not as easy as looking for .svn, say.


 We can just copy-paste the code that git uses itself to detect whether it
 is in a repo or not ?


  (ii) is definitely a different issue.


 it depends on how complex you want to make. You can easily mimick the svn
 workflow: push after every commit. Or you can make two options: commit and
 push. Not so big deal, right ?


Why not having a simple commit, and leave the push to the user? I really see
one maina dvantage of using git in having it local - and when one is online
(and has an remote repo - I wouldn't in most cases), push manually.

Cheers,

Rainer



 Richard

  Vincent




-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax (F):   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug

Re: GIT as vcs for lyx documents

[Richard Heck]

On 07/11/2011 09:32 AM, Vincent van Ravesteijn wrote:

 (i) is certainly fixable, in the sense that we can spawn git status
 and check the return value, but it is not as easy as looking for
 .svn, say.

 We can just copy-paste the code that git uses itself to detect whether
 it is in a repo or not ?

I'm a bit curious how it does this, actually. I mean: In such a way as
properly to follow symlinks. I run into this kind of problem often.
E.g., what .. means seems to vary in a way I do not understand if you
are in a symlinked directory.

Anyway, there is git status and there is also git rev-parse
--git-dir, if we want to find the .git directory, for some reason.

 (ii) is definitely a different issue.

 it depends on how complex you want to make. You can easily mimick the
 svn workflow: push after every commit. Or you can make two options:
 commit and push. Not so big deal, right ?

I don't think we'd want to do the former. Certainly you can do the
latter, but it does mean doing something different from what we do with
other VCs, which means different menu options, etc. Not impossible, but
more work. Or we can just commit, as Rainer suggested, and leave pushing
to the user. I suspect that in many cases, pushing may not even be an
option, as there may be no remote. That's one of the great things about
git, that I use all the time now: totally local repos.

Richard

Re: GIT as vcs for lyx documents

[Rainer M Krug]

On Mon, Jul 11, 2011 at 3:47 PM, Richard Heck rgh...@comcast.net wrote:

 **
 On 07/11/2011 09:32 AM, Vincent van Ravesteijn wrote:


(i) is certainly fixable, in the sense that we can spawn git status
 and check the return value, but it is not as easy as looking for .svn, say.


 We can just copy-paste the code that git uses itself to detect whether it
 is in a repo or not ?

  I'm a bit curious how it does this, actually. I mean: In such a way as
 properly to follow symlinks. I run into this kind of problem often. E.g.,
 what .. means seems to vary in a way I do not understand if you are in a
 symlinked directory.

 Anyway, there is git status and there is also git rev-parse --git-dir,
 if we want to find the .git directory, for some reason.


  (ii) is definitely a different issue.


 it depends on how complex you want to make. You can easily mimick the svn
 workflow: push after every commit. Or you can make two options: commit and
 push. Not so big deal, right ?

  I don't think we'd want to do the former. Certainly you can do the latter,
 but it does mean doing something different from what we do with other VCs,
 which means different menu options, etc. Not impossible, but more work. Or
 we can just commit, as Rainer suggested, and leave pushing to the user. I
 suspect that in many cases, pushing may not even be an option, as there may
 be no remote. That's one of the great things about git, that I use all the
 time now: totally local repos.


Exactly. And the push can always be added later.

Rainer


 Richard




-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax (F):   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug

Re: GIT as vcs for lyx documents

[Richard Heck]

On 07/11/2011 09:47 AM, Richard Heck wrote:
 On 07/11/2011 09:32 AM, Vincent van Ravesteijn wrote:

 (i) is certainly fixable, in the sense that we can spawn git
 status and check the return value, but it is not as easy as looking
 for .svn, say.

 We can just copy-paste the code that git uses itself to detect
 whether it is in a repo or not ?

 I'm a bit curious how it does this, actually. I mean: In such a way as
 properly to follow symlinks. I run into this kind of problem often.
 E.g., what .. means seems to vary in a way I do not understand if
 you are in a symlinked directory.

For example: Suppose I am in /home/rgheck/; there is symlink from texmf
to files/texmf. (Here files/ is the mount point for an NFS directory.)
If I cd to /home/rgheck/texmf/, then:
(i) cd .. takes me to /home/rgheck/, as expected
(ii) ls .. gives me the files in /home/rgheck/files/, as not expected.
It looks like git acts like ls. If you have a symlink in a git repo,
then the symlink is in the repo, but the stuff in the directory to which
it points is not (unless that directory is in the repo anyway).

So this means that we can figure out if we are in a repo by looking up
the tree (apparently, stopping at the mount point, too, if I'm reading
things correctly). But we have to follow the REAL parent, not just strip
off path elements. I do not know how to do that, myself. Maybe the
easiest way would be first to get the real path to whatever directory we
are in, then we can strip off path elements looking for .git. I'm not
sure about how to stop at mount points, though.

Richard

Re: GIT as vcs for lyx documents

[Pavel Sanda]

Richard Heck wrote:
 I'm a bit curious how it does this, actually. I mean: In such a way as
 properly to follow symlinks. I run into this kind of problem often.
 E.g., what .. means seems to vary in a way I do not understand if you
 are in a symlinked directory.

thats where the fun begins. another thing i was not comfortable with
is that we should automatically start some directory climbing or running
external commands (git status) for each opened file.

unrelated (99.9% of people will never use .git) sniffing on the directories
around files i'm trying to access gave me headaches on both win and linux archs
on varieties of programs when networking drives/mount points are used. one
connection hangs and the program freezes although i'm working in independent
folder etc.

pavel

Re: GIT as vcs for lyx documents

[Rainer M Krug]

On Mon, Jul 11, 2011 at 4:01 PM, Richard Heck rgh...@comcast.net wrote:

 **
 On 07/11/2011 09:47 AM, Richard Heck wrote:

 On 07/11/2011 09:32 AM, Vincent van Ravesteijn wrote:


(i) is certainly fixable, in the sense that we can spawn git status
 and check the return value, but it is not as easy as looking for .svn, say.


 We can just copy-paste the code that git uses itself to detect whether it
 is in a repo or not ?

  I'm a bit curious how it does this, actually. I mean: In such a way as
 properly to follow symlinks. I run into this kind of problem often. E.g.,
 what .. means seems to vary in a way I do not understand if you are in a
 symlinked directory.

  For example: Suppose I am in /home/rgheck/; there is symlink from texmf to
 files/texmf. (Here files/ is the mount point for an NFS directory.) If I cd
 to /home/rgheck/texmf/, then:
 (i) cd .. takes me to /home/rgheck/, as expected
 (ii) ls .. gives me the files in /home/rgheck/files/, as not
 expected.
 It looks like git acts like ls. If you have a symlink in a git repo, then
 the symlink is in the repo, but the stuff in the directory to which it
 points is not (unless that directory is in the repo anyway).

 So this means that we can figure out if we are in a repo by looking up the
 tree (apparently, stopping at the mount point, too, if I'm reading things
 correctly). But we have to follow the REAL parent, not just strip off path
 elements. I do not know how to do that, myself. Maybe the easiest way would
 be first to get the real path to whatever directory we are in, then we can
 strip off path elements looking for .git. I'm not sure about how to stop at
 mount points, though.


I might be missing something basic, but are there any problems with using

git status FILE_OF_LYX_FILE

and to parse the output?

Rainer



 Richard




-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax (F):   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug

Re: GIT as vcs for lyx documents

[Pavel Sanda]

Rainer M Krug wrote:
 I might be missing something basic, but are there any problems with using
 
 git status FILE_OF_LYX_FILE
 
 and to parse the output?

1. it feels wrong to spawn new external command for each file/child opened.
2. there is no guarantee that the output to be parsed remain the same accross
   git versions.
3. possible network problems written in other mail.

pavel

Re: GIT as vcs for lyx documents

[Rainer M Krug]

On Mon, Jul 11, 2011 at 4:22 PM, Pavel Sanda sa...@lyx.org wrote:

 Rainer M Krug wrote:
  I might be missing something basic, but are there any problems with using
 
  git status FILE_OF_LYX_FILE
 
  and to parse the output?

 1. it feels wrong to spawn new external command for each file/child opened.


True - but the alternative is to code the tests, which is, as discussed,
quite problematic.

2. there is no guarantee that the output to be parsed remain the same
 accross
   git versions.


There is this option for git status which could be used:
--porcelain
   Give the output in a stable, easy-to-parse format for scripts.
   Currently this is identical to --short output, but is guaranteed
   not to change in the future, making it safe for scripts.



 3. possible network problems written in other mail.


But if git status does not work, I do not expect the other git commands
to work?

Rainer


 pavel




-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax (F):   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug

Re: GIT as vcs for lyx documents

[John McCabe-Dansted]

On Mon, Jul 11, 2011 at 10:01 PM, Richard Heck rgh...@comcast.net wrote:
     (i) cd .. takes me to /home/rgheck/, as expected

I understand that the bash builtin cd command reinterpreting .. to
mean slice off part of the path.

     (ii) ls .. gives me the files in /home/rgheck/files/, as not expected.

I understand this is the standard POSIX interpretation of ..; .. is a
hardlink to the parent directory that is created when the directory is
first created.

More discussion is at:
http://stackoverflow.com/questions/2105572/unix-softlinks-and-paths

 It looks like git acts like ls. If you have a symlink in a git repo, then
 the symlink is in the repo, but the stuff in the directory to which it
 points is not (unless that directory is in the repo anyway).

 So this means that we can figure out if we are in a repo by looking up the
 tree (apparently, stopping at the mount point, too, if I'm reading things
 correctly). But we have to follow the REAL parent, not just strip off path
 elements. I do not know how to do that, myself.

This is easy; pretty much everything follows the real parent, except
for shell builtins that try to be smart.

There is a mountpoint utility to find mountpoints. We could paste
some code in from mountpoint.c (attached). It seems to be a matter of
using lstat to find the device number, and probably also checking if
we've hit the root directory.

-- 
John C. McCabe-Dansted

Re: GIT as vcs for lyx documents

[Pavel Sanda]

Rainer M Krug wrote:
 True - but the alternative is to code the tests, which is, as discussed,
 quite problematic.

or to steal them from git.

 There is this option for git status which could be used:
 --porcelain
Give the output in a stable, easy-to-parse format for scripts.
Currently this is identical to --short output, but is guaranteed
not to change in the future, making it safe for scripts.

good to know, thanks.

  3. possible network problems written in other mail.
 
 
 But if git status does not work, I do not expect the other git commands
 to work?

the problem i'm pointing to is that user who doesn't work with any RCS system
may experience freezes when loading file just because we are playing in 
unrelated
parts of the file system.

pavel

Re: GIT as vcs for lyx documents

[Rainer M Krug]

On Mon, Jul 11, 2011 at 4:40 PM, Pavel Sanda sa...@lyx.org wrote:

 Rainer M Krug wrote:
  True - but the alternative is to code the tests, which is, as discussed,
  quite problematic.

 or to steal them from git.


But I assume that these can also change over time, especially as they are
internal.


  There is this option for git status which could be used:
  --porcelain
 Give the output in a stable, easy-to-parse format for scripts.
 Currently this is identical to --short output, but is
 guaranteed
 not to change in the future, making it safe for scripts.

 good to know, thanks.

   3. possible network problems written in other mail.
  
 
  But if git status does not work, I do not expect the other git
 commands
  to work?

 the problem i'm pointing to is that user who doesn't work with any RCS
 system
 may experience freezes when loading file just because we are playing in
 unrelated
 parts of the file system.


This mustn't happen - but isn't this risk higher when we are trying to use
own / copied routines to check then using an established command like git
status?

For the medium term: what about per file or general options, which enable
certain vcs? these could then be enabled by the user, and when loading the
files afterwards be checked automatically.

Rainer


 pavel




-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax (F):   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug

Re: GIT as vcs for lyx documents

[Pavel Sanda]

Rainer M Krug wrote:
 On Mon, Jul 11, 2011 at 4:40 PM, Pavel Sanda sa...@lyx.org wrote:
 This mustn't happen - but isn't this risk higher when we are trying to use
 own / copied routines to check then using an established command like git
 status?

this is not about using our code vs parsing git output but
detecting git vs ignore git VCS.

 For the medium term: what about per file or general options, which enable
 certain vcs?

general (by default disabled) option like git support was the only solution
i was able to come with.

pavel

Re: GIT as vcs for lyx documents

[Richard Heck]

On 07/11/2011 07:52 AM, Rainer M Krug wrote:
> Hi,
>
> / /I know that git is not integrated as a vcs for LyX documents, but
> how much work would t be to include it? I remember reading somewhere
> that just a few scripts have to be changed - could somebody point me
> into the right direction?
>
> Richard Heck wrote (on 4/30/2010):
>> > 
>> > Pavel,
>> > 
>> > I seem to remember that there were some issues you ran into when
>> > thinking about adding git as backend for LyX VC. What were those?
>>
> 1. detection we are inside repo.
> 2. different workflow than rcs/cvs/svn especially difference between
>committing and pushing.
>
> it would need to re-think VCS API we have and possibly do some brainstorming
> especially about point 2, because it is not clear to me what operations /
> workflow should we actually support.
>
> all this is doable but in the order of magnitude harder than it was with
> adding(fixing) CVS support.
>
(i) is certainly fixable, in the sense that we can spawn "git status"
and check the return value, but it is not as easy as looking for .svn,
say. (ii) is definitely a different issue.

Richard

Re: GIT as vcs for lyx documents

[Vincent van Ravesteijn]

(i) is certainly fixable, in the sense that we can spawn "git status" 
and check the return value, but it is not as easy as looking for .svn, 
say.


We can just copy-paste the code that git uses itself to detect whether 
it is in a repo or not ?



(ii) is definitely a different issue.


it depends on how complex you want to make. You can easily mimick the 
svn workflow: push after every commit. Or you can make two options: 
commit and push. Not so big deal, right ?


Richard


Vincent

Re: GIT as vcs for lyx documents

[Rainer M Krug]

On Mon, Jul 11, 2011 at 3:32 PM, Vincent van Ravesteijn  wrote:

OK - so not as easy as I rememeber - well..


> (i) is certainly fixable, in the sense that we can spawn "git status" and
> check the return value, but it is not as easy as looking for .svn, say.
>
>
> We can just copy-paste the code that git uses itself to detect whether it
> is in a repo or not ?
>
>
>  (ii) is definitely a different issue.
>
>
> it depends on how complex you want to make. You can easily mimick the svn
> workflow: push after every commit. Or you can make two options: commit and
> push. Not so big deal, right ?
>

Why not having a simple commit, and leave the push to the user? I really see
one maina dvantage of using git in having it local - and when one is online
(and has an remote repo - I wouldn't in most cases), push manually.

Cheers,

Rainer


>
> Richard
>
>  Vincent
>



-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax (F):   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug

Re: GIT as vcs for lyx documents

[Richard Heck]

On 07/11/2011 09:32 AM, Vincent van Ravesteijn wrote:
>
>> (i) is certainly fixable, in the sense that we can spawn "git status"
>> and check the return value, but it is not as easy as looking for
>> .svn, say.
>
> We can just copy-paste the code that git uses itself to detect whether
> it is in a repo or not ?
>
I'm a bit curious how it does this, actually. I mean: In such a way as
properly to follow symlinks. I run into this kind of problem often.
E.g., what ".." means seems to vary in a way I do not understand if you
are in a symlinked directory.

Anyway, there is "git status" and there is also "git rev-parse
--git-dir", if we want to find the .git directory, for some reason.

>> (ii) is definitely a different issue.
>
> it depends on how complex you want to make. You can easily mimick the
> svn workflow: push after every commit. Or you can make two options:
> commit and push. Not so big deal, right ?
>
I don't think we'd want to do the former. Certainly you can do the
latter, but it does mean doing something different from what we do with
other VCs, which means different menu options, etc. Not impossible, but
more work. Or we can just commit, as Rainer suggested, and leave pushing
to the user. I suspect that in many cases, pushing may not even be an
option, as there may be no remote. That's one of the great things about
git, that I use all the time now: totally local repos.

Richard

Re: GIT as vcs for lyx documents

[Rainer M Krug]

On Mon, Jul 11, 2011 at 3:47 PM, Richard Heck  wrote:

> **
> On 07/11/2011 09:32 AM, Vincent van Ravesteijn wrote:
>
>
>(i) is certainly fixable, in the sense that we can spawn "git status"
> and check the return value, but it is not as easy as looking for .svn, say.
>
>
> We can just copy-paste the code that git uses itself to detect whether it
> is in a repo or not ?
>
>  I'm a bit curious how it does this, actually. I mean: In such a way as
> properly to follow symlinks. I run into this kind of problem often. E.g.,
> what ".." means seems to vary in a way I do not understand if you are in a
> symlinked directory.
>
> Anyway, there is "git status" and there is also "git rev-parse --git-dir",
> if we want to find the .git directory, for some reason.
>
>
>  (ii) is definitely a different issue.
>
>
> it depends on how complex you want to make. You can easily mimick the svn
> workflow: push after every commit. Or you can make two options: commit and
> push. Not so big deal, right ?
>
>  I don't think we'd want to do the former. Certainly you can do the latter,
> but it does mean doing something different from what we do with other VCs,
> which means different menu options, etc. Not impossible, but more work. Or
> we can just commit, as Rainer suggested, and leave pushing to the user. I
> suspect that in many cases, pushing may not even be an option, as there may
> be no remote. That's one of the great things about git, that I use all the
> time now: totally local repos.
>

Exactly. And the "push" can always be added later.

Rainer


> Richard
>
>


-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax (F):   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug

Re: GIT as vcs for lyx documents

[Richard Heck]

On 07/11/2011 09:47 AM, Richard Heck wrote:
> On 07/11/2011 09:32 AM, Vincent van Ravesteijn wrote:
>>
>>> (i) is certainly fixable, in the sense that we can spawn "git
>>> status" and check the return value, but it is not as easy as looking
>>> for .svn, say.
>>
>> We can just copy-paste the code that git uses itself to detect
>> whether it is in a repo or not ?
>>
> I'm a bit curious how it does this, actually. I mean: In such a way as
> properly to follow symlinks. I run into this kind of problem often.
> E.g., what ".." means seems to vary in a way I do not understand if
> you are in a symlinked directory.
>
For example: Suppose I am in /home/rgheck/; there is symlink from texmf
to files/texmf. (Here files/ is the mount point for an NFS directory.)
If I cd to /home/rgheck/texmf/, then:
(i) "cd .." takes me to /home/rgheck/, as expected
(ii) "ls .." gives me the files in /home/rgheck/files/, as not expected.
It looks like git acts like ls. If you have a symlink in a git repo,
then the symlink is in the repo, but the stuff in the directory to which
it points is not (unless that directory is in the repo anyway).

So this means that we can figure out if we are in a repo by looking up
the tree (apparently, stopping at the mount point, too, if I'm reading
things correctly). But we have to follow the REAL parent, not just strip
off path elements. I do not know how to do that, myself. Maybe the
easiest way would be first to get the real path to whatever directory we
are in, then we can strip off path elements looking for .git. I'm not
sure about how to stop at mount points, though.

Richard

Re: GIT as vcs for lyx documents

[Pavel Sanda]

Richard Heck wrote:
> I'm a bit curious how it does this, actually. I mean: In such a way as
> properly to follow symlinks. I run into this kind of problem often.
> E.g., what ".." means seems to vary in a way I do not understand if you
> are in a symlinked directory.

thats where the fun begins. another thing i was not comfortable with
is that we should automatically start some directory climbing or running
external commands (git status) for each opened file.

unrelated (99.9% of people will never use .git) sniffing on the directories
around files i'm trying to access gave me headaches on both win and linux archs
on varieties of programs when networking drives/mount points are used. one
connection hangs and the program freezes although i'm working in independent
folder etc.

pavel

Re: GIT as vcs for lyx documents

[Rainer M Krug]

On Mon, Jul 11, 2011 at 4:01 PM, Richard Heck  wrote:

> **
> On 07/11/2011 09:47 AM, Richard Heck wrote:
>
> On 07/11/2011 09:32 AM, Vincent van Ravesteijn wrote:
>
>
>(i) is certainly fixable, in the sense that we can spawn "git status"
> and check the return value, but it is not as easy as looking for .svn, say.
>
>
> We can just copy-paste the code that git uses itself to detect whether it
> is in a repo or not ?
>
>  I'm a bit curious how it does this, actually. I mean: In such a way as
> properly to follow symlinks. I run into this kind of problem often. E.g.,
> what ".." means seems to vary in a way I do not understand if you are in a
> symlinked directory.
>
>  For example: Suppose I am in /home/rgheck/; there is symlink from texmf to
> files/texmf. (Here files/ is the mount point for an NFS directory.) If I cd
> to /home/rgheck/texmf/, then:
> (i) "cd .." takes me to /home/rgheck/, as expected
> (ii) "ls .." gives me the files in /home/rgheck/files/, as not
> expected.
> It looks like git acts like ls. If you have a symlink in a git repo, then
> the symlink is in the repo, but the stuff in the directory to which it
> points is not (unless that directory is in the repo anyway).
>
> So this means that we can figure out if we are in a repo by looking up the
> tree (apparently, stopping at the mount point, too, if I'm reading things
> correctly). But we have to follow the REAL parent, not just strip off path
> elements. I do not know how to do that, myself. Maybe the easiest way would
> be first to get the real path to whatever directory we are in, then we can
> strip off path elements looking for .git. I'm not sure about how to stop at
> mount points, though.
>

I might be missing something basic, but are there any problems with using

git status FILE_OF_LYX_FILE

and to parse the output?

Rainer


>
> Richard
>
>


-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax (F):   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug

Re: GIT as vcs for lyx documents

[Pavel Sanda]

Rainer M Krug wrote:
> I might be missing something basic, but are there any problems with using
> 
> git status FILE_OF_LYX_FILE
> 
> and to parse the output?

1. it feels wrong to spawn new external command for each file/child opened.
2. there is no guarantee that the output to be parsed remain the same accross
   git versions.
3. possible network problems written in other mail.

pavel

Re: GIT as vcs for lyx documents

[Rainer M Krug]

On Mon, Jul 11, 2011 at 4:22 PM, Pavel Sanda  wrote:

> Rainer M Krug wrote:
> > I might be missing something basic, but are there any problems with using
> >
> > git status FILE_OF_LYX_FILE
> >
> > and to parse the output?
>
> 1. it feels wrong to spawn new external command for each file/child opened.
>

True - but the alternative is to code the tests, which is, as discussed,
quite problematic.

2. there is no guarantee that the output to be parsed remain the same
> accross
>   git versions.
>

There is this option for git status which could be used:
--porcelain
   Give the output in a stable, easy-to-parse format for scripts.
   Currently this is identical to --short output, but is guaranteed
   not to change in the future, making it safe for scripts.



> 3. possible network problems written in other mail.
>

But if "git status" does not work, I do not expect the other "git" commands
to work?

Rainer

>
> pavel
>



-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax (F):   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug

Re: GIT as vcs for lyx documents

[John McCabe-Dansted]

On Mon, Jul 11, 2011 at 10:01 PM, Richard Heck  wrote:
>     (i) "cd .." takes me to /home/rgheck/, as expected

I understand that the bash builtin cd command reinterpreting ".." to
mean slice off part of the path.

>     (ii) "ls .." gives me the files in /home/rgheck/files/, as not expected.

I understand this is the standard POSIX interpretation of ..; .. is a
hardlink to the parent directory that is created when the directory is
first created.

More discussion is at:
http://stackoverflow.com/questions/2105572/unix-softlinks-and-paths

> It looks like git acts like ls. If you have a symlink in a git repo, then
> the symlink is in the repo, but the stuff in the directory to which it
> points is not (unless that directory is in the repo anyway).
>
> So this means that we can figure out if we are in a repo by looking up the
> tree (apparently, stopping at the mount point, too, if I'm reading things
> correctly). But we have to follow the REAL parent, not just strip off path
> elements. I do not know how to do that, myself.

This is easy; pretty much everything follows the real parent, except
for shell builtins that try to be smart.

There is a "mountpoint" utility to find mountpoints. We could paste
some code in from mountpoint.c (attached). It seems to be a matter of
using lstat to find the device number, and probably also checking if
we've hit the root directory.

-- 
John C. McCabe-Dansted

Re: GIT as vcs for lyx documents

[Pavel Sanda]

Rainer M Krug wrote:
> True - but the alternative is to code the tests, which is, as discussed,
> quite problematic.

or to steal them from git.

> There is this option for git status which could be used:
> --porcelain
>Give the output in a stable, easy-to-parse format for scripts.
>Currently this is identical to --short output, but is guaranteed
>not to change in the future, making it safe for scripts.

good to know, thanks.

> > 3. possible network problems written in other mail.
> >
> 
> But if "git status" does not work, I do not expect the other "git" commands
> to work?

the problem i'm pointing to is that user who doesn't work with any RCS system
may experience freezes when loading file just because we are playing in 
unrelated
parts of the file system.

pavel

Re: GIT as vcs for lyx documents

[Rainer M Krug]

On Mon, Jul 11, 2011 at 4:40 PM, Pavel Sanda  wrote:

> Rainer M Krug wrote:
> > True - but the alternative is to code the tests, which is, as discussed,
> > quite problematic.
>
> or to steal them from git.
>

But I assume that these can also change over time, especially as they are
internal.


> > There is this option for git status which could be used:
> > --porcelain
> >Give the output in a stable, easy-to-parse format for scripts.
> >Currently this is identical to --short output, but is
> guaranteed
> >not to change in the future, making it safe for scripts.
>
> good to know, thanks.
>
> > > 3. possible network problems written in other mail.
> > >
> >
> > But if "git status" does not work, I do not expect the other "git"
> commands
> > to work?
>
> the problem i'm pointing to is that user who doesn't work with any RCS
> system
> may experience freezes when loading file just because we are playing in
> unrelated
> parts of the file system.
>

This mustn't happen - but isn't this risk higher when we are trying to use
own / copied routines to check then using an established command like "git
status"?

For the medium term: what about per file or general options, which enable
certain vcs? these could then be enabled by the user, and when loading the
files afterwards be checked automatically.

Rainer

>
> pavel
>



-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax (F):   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug

Re: GIT as vcs for lyx documents

[Pavel Sanda]

Rainer M Krug wrote:
> On Mon, Jul 11, 2011 at 4:40 PM, Pavel Sanda  wrote:
> This mustn't happen - but isn't this risk higher when we are trying to use
> own / copied routines to check then using an established command like "git
> status"?

this is not about "using our code" vs "parsing git output" but
"detecting git" vs "ignore git VCS".

> For the medium term: what about per file or general options, which enable
> certain vcs?

general (by default disabled) option like "git support" was the only solution
i was able to come with.

pavel