Ooops. It seems that each time somebody says these two words together,
people hate him, and he is scorned by friends and family.
However,
- gitolite implement it (but gitolite is not git).
- In the documentation, each time the need is evocated, it is replace
by "do communication, don't use git for that". I'm still looking for
the good way to communicate this information. In my humble opinion,
git is a communication tool.
I won't explain here why it could be a if not good, at least helpfull
new feature (and everybody is not mandatory to use new feature),
I've still heard no argument about why it could not be accepted in git
better than "locking is bad".
I want to explain how I could implement it.
Firstly, it would (in the general form ; some options could be added)
alter no existing command of git.
It would add 3 new commands :
- git lock [path]
- git unlock [path]
- git lslock
It would add 2 new files in .git :
- lockserver containing a ssh url of the git repository, not necessary
the source of the clone (in fact, the same content of the lockserver
file in the source of the clone so that people gets the same lock
server)
- lockedfiles containing the list of pathes of locked files (plus name
of the people locking, date) on the lock server.
git push would not be altered, however, you can imagine an option to
unlock all locked files by yourself.
the 3 new commands would require a communication to the lock server.
note that the idea is that everybody get the same lock server in any workflow.
In case there was no server defined on the original git repository,
you have to communicate so that people configure the lockserver file.
git lock would put the path provided into the lock server
git unlock would remove the path provided from the lock server
git lslock would ask pathes to the lock server
You must have rules on your project, for example, lock a .doc file
each time you modify it.
If you follow that guideline, you’ll be fine. If you don’t, people
will hate you, and you’ll be scorned by friends and family.
If you push a file which is not locked by you, any problem, it will
push (eventually, telling you that the file was locked and that your
project has some rules).
What about automatic unlocking to prevent from forgetting to unlock :
Something like pushing when the push server is the same as the lock
server could automatically unlock the file.
The question is when to unlock when you have a complex workflow with a dictator.
I agree i've not the best answer for the moment. Something like when
the developper have the files back, identically from the source of the
dictator. This point could be think more.
Scenario :
@alice : git lock src/main.c
@bob : git lock src/main.c
fatal: file src/main.c locked by alice
@alice : git unlock src/main.c
@bob : git lock src/main.c
For the moment, i want a first feedback, an intermediate between
"locking is bad" and "ok", but i would prefer in the negativ answer
something with arguments ("Take CVS as an example of what not to do;
if in doubt, make the exact opposite decision." is one), and in the
positiv answer, good remarks about problems with my implementation
that could make it better.
Perhaps this subject has already been discussed and is closed, in this
case, sorry, just give me the link i've not found please.
Nicolas Adenis-Lamarre
--
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