On 17 October 2012 04:27, Angelo Borsotti <angelo.borsotti@xxxxxxxxx> 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 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html