feature request

Hello,

some VCS, e.g. ClearCase, allow to control the fetching of files so as to warn, or disallow parallel changes to the same files. As of today, there is no way to implement the same kind of workflow with git because there are no fetch hooks. Would it be a good idea to provide them?

-Angelo Borsotti

On 16 October 2012 22:36, Angelo Borsotti <angelo.borsotti@gmail.com> wrote:

It seems like you want to be able to lock a file for editing once someone has 'checked-out' the file. This really only makes sense for binary files (or files which there is no straightforward way to merge) as otherwise you are throwing away the usefulness of git without any gain. Git is designed so that multiple people can work on a file at the same time. Easy merging means that collating those changes is an easy task, and so locking a file has no use. If a file cannot be easily merged then it does make sense to lock the file. Is this what you need to do, or is there some other reason for wanting a lock?

In any case, locking a file is a hard thing to do right in a distributed system, and doesn't really make sense (although it may be useful!) When you clone a git repository you have the entire history of the repository on your computer. What does it mean to have a locked file? Does the file get deleted from everyone's repository every time someone else locks it? That would seem silly. Perhaps everyone simply can't write to that file once it has been locked - how do you impose that restriction in a distributed system (you can't)?

Instead you can only refuse pushes that change the locked file (which is normal - you would have to force the push for any non fast-forward changes), and you can try to warn users that somebody else has locked the file. This warning system might be doable in some fashion, by using hooks to write the locked files to a text file somewhere and checking that, however it would be near impossible to get right or would hamstring the distributed nature of git by forcing constant server checks.

Instead of continuing making the point here, let me point you towards some other discussions around file locks, in particular how git handles binary files. You should be able to find many more, but as a starter, look at [1] and [2].

In general, I would reconsider why two users shouldn't be able to change the same file at the same time.

Regards,

Andrew Ardill

[1] http://stackoverflow.com/questions/119444/locking-binary-files-using-git-version-control-system [2] http://git.661346.n2.nabble.com/Lock-binairy-files-in-Git-td2422894.html

Hi Andrew,

one nice thing is to warn a developer that wants to modify a source file, that there is somebody else changing it beforehand. It is nicer than discovering that at push time. Take into account that there are changes in files that may be incompatible to each other, or that can be amenable to be automatically merged producing wrong results. So, knowing it could help.

-Angelo

On Tue, Oct 16, 2012 at 10:57 PM, Angelo Borsotti <angelo.borsotti@gmail.com> wrote:

Andrew:

also see http://sitaramc.github.com/gitolite/locking.html for a way to do file locking (and enforce it) using gitolite.

This does warn, as long as the user remembers to try to acquire a lock before working on a binary file. (You can't get around that requirement on a DVCS, sorry!)

On 17 October 2012 04:27, Angelo Borsotti <angelo.borsotti@gmail.com> wrote:

If you simply want to know when a file has been changed by someone else, git already has this capability, but as you note it only occurs when you try to push. Unless you force push, you have to merge changes before committing to upstream. In a distributed situation you can only inform the user when they 'touch-base' with the server, and if that is what you want than one of the locking systems others have proposed might be a good choice.

There are two concerns to deal with here. The first is when any
conflicts at all will cause problems, as there is no way to merge
them. This often happens with binary files, and is a good reason to
use a locking system. The second concern is situations where a merge
happens 'silently' (i.e. no conflicts) thus allowing potential logic
bugs to be introduced even though semantically the merge was fine. For
this situation the best option is to require whoever is merging to
check the merge output for logical errors. This has to happen anyway,
as it is possible for logical errors to be introduced across different
files, although it's probably more common to see logic conflicts
within the one file. To make it easier to discover such changes early
in the process you could write a tool that did some (or all) of the
following:
1. Automatically fetch changes from remote repositories at a regular interval.
2. Compare files changed in the working tree and index to changes
fetched from remote repositories. This would need to find the merge
base of the two and compare files touched since then.
3. Notify the user of the files that have been changed through some fashion.
4. Automatically push changes to a 'wip' branch so that others can see
what you are modifying. Alternatively, automatically publish a list of
changed files for the same purpose, though this seems a lot more hacky
(though both options are surely hacky).

2 and 3 could be combined into a single tool run whenever the user wants to check for potential logic changes down the track. Automating it would allow for this information to be communicated a bit faster. Running it after each fetch would be a nice to have. Pushing the work in progress branch is something I am not sure is a good idea, but it would be the only way to know when someone else is working on something before they commit and push it manually. Pushing a single file with files being worked on is less invasive, but would require the other aspects of the tool to use it as well (hence forming a stronger coupling and reducing the usefulness of the other components as standalone tools).

There is no way that I know of to force merge to stop every time the file is changed on both theirs and ours (regardless of whether or not it is an actual conflict or not). It could potentially be done with a pre-merge hook, but no such hook exists to my knowledge. If this were implemented, using it would make merging a potentially tiresome affair, however I could see its usefulness for people who were very concerned about introducing logic errors with merges on the same file.

The best solution is in my opinion to check what is going to be merged before you merge it, but a tool to warn that someone else is modifying the same file would have its uses.

Regards,

Andrew Ardill

Am Tue, 16 Oct 2012 13:36:04 +0200 schrieb Angelo Borsotti <angelo.borsotti@gmail.com>:

I've actually implemented a 'git lock' command to lock pathnames from concurrent editing for a customer. Normally one would say this is a rather ill and ugly feature for git but there where some reasons to do it anyways (imagine robots crashing into each other on a production line because of bad (developer-)communication).

The code is GPL and I can distribute it, but I didn't consider it ready for an open announcement yet. Noteworthy some problems with msys led to some ugly solution (the uniq command doesn't know the -z option there).

I hope this might be useful to you. I'd also like to get contributions and fixes if there are any problems I am not aware of.

Short into; the doc:

 http://git.pipapo.org/?p=git;a=blob_plain;f=Documentation/git-lock.txt;h=dcc7a5c34dea657ab5819e8def54e154d5d97219;hb=25ee09cf35daa03a7c2ef10537561a50db2d17b2

the code is available at

 git://git.pipapo.org/git

in the 'ct/git-lock' branch.

It is a bit fallen behind the current git version, I will update/merge it sometime next (to keep in par with msysgit, thats what is required here)

	Christian