Re: [Plplot-devel] git (again)

[Hazen B. <hba...@ma...>]

> Date: Wed, 5 Feb 2014 16:01:25 -0700
> From: Jerry <lan...@qw...>
>>>
>>> Here is a related question.  My understanding from superficial reading
>>> is that git users normally have a local repository (unlike the svn
>>> case where there is normally just one repository).  But if someone is
>>> worried about the disk space that is required by that local git
>>> repository, is there also a detached repository mode for git (i.e., so
>>> the user could simply use the SourceForge repository without copying
>>> all of the repository to his own computer)?
>>
>> This is no longer true? I checked out PLplot using git (master branch) and svn (trunk), which I believe to be roughly equivalent and the sizes are:
>>
>> (svn checkout http://svn.code.sf.net/p/plplot/code/trunk plplot)
>> SVN: 36.2MB (43.8MB on disk)
>>
>> (git clone https://github.com/HazenBabcock/PLplot.git)
>> GIT: 40.1MB (44.0MB on disk)
>
> That's interesting. My superficial understanding of git (also) is that the user stores the entire history of a project locally (with the advantage that checking stuff in and out is very fast). That means that apparently the PLplot history is stored very efficiently since the git size is only a little larger than the svn size. Also, I didn't spend enough time learning git to figure out what advantage there is when updating the master with a local repo--there still must be issues with conflicts. And is there any mechanism to lock a file while it is being edited, since it is checked out from the local repo and the master has no clue of the file's status. I recall we had a discussion of this recently w.r.t. svn where most agreed that conflicts like this are a rare event but there is indeed a locking mechanism of some sort if one chooses to use it.

I think the work flow is that if you are going to work on issue X then 
you create a local branch called issue X. You periodically merge it with 
the master branch, which you keep in sync with the public repository. 
Then when issueX is ready to go you merge this branch back into master, 
resolve any conflicts, make sure it still works as expected and then 
push the updated master to the public repository. I'm not that familiar 
with git's merging abilities since the projects that I'm involved with 
that use it have only a few members at most, so there is not a lot of 
potential for file conflicts.

There is no locking mechanism that I know of.

-Hazen