git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: feature request

From
Andrew Ardill <andrew.ardill@gmail.com>
Date
Oct 16, 2012, 12:15 UTC
Message-ID
<CAH5451=1VU6oUzAyGXZvOW-Pk3+Os1mq1neum572venNjRfT+g@mail.gmail.com>
In-Reply-To
<CAB9Jk9AwTVM4TPwPg1Gmi8TCnnXWUsMAfaz8DdfcEhBNW_15Ug@mail.gmail.com>
On 16 October 2012 22:36, Angelo Borsotti <angelo.borsotti@gmail.com> wrote:
Show 12 quoted lines
>
> 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

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

Previous: Angelo BorsottiNext: Angelo Borsotti
Message 2 of 6 in “feature request”
  1. Angelo BorsottiOct 16, 2012
  2. Andrew ArdillOct 16, 2012
  3. Angelo BorsottiOct 16, 2012
  4. Sitaram ChamartyOct 16, 2012
  5. Andrew ArdillOct 17, 2012
  6. Christian ThaeterOct 16, 2012

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.