Re: feature request

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