On 17 October 2012 04:27, Angelo Borsotti <angelo.borso...@gmail.com> wrote:
> 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

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


Andrew Ardill
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to