Yes I don't disagree: that notion of locking a file makes no sense in Git.
I just wanted to emphasis the importance for teams to stay in communication
if they want to reduce any annoying conflicts during merging because of
this feature. Just like when you're renovating a house, a little
communication, planning and some policies can prevent two or three people
from painting the same wall a different color at the same time. The nice
thing about Git is that the worse case scenario--where two people edited
the same code in some conflicting way--isn't really that big of a problem.
You just need to review and make some decisions.

On Thu, Sep 27, 2012 at 1:27 AM, Konstantin Khomoutov <> wrote:

> On Wed, 26 Sep 2012 08:33:43 -0700 (PDT)
> maxhodges <> wrote:
> [...]
> > The problem you are probably worried about if when two users make
> > changes to the exact same code; that is, when two developers edit the
> > same lines of code in the same source file. It's still possible to
> > merge the files, but Git will recognize that there is a merge
> > conflict and someone will need to review and resolve the conflict.
> A true problem with Git's approach to things (let everyone work away,
> and reconcile conflicts later, if any) does not work for stuff which
> can't really be merged.  One obvious example of such stuff is binary
> files with artwork being a glaring example, for instance, textures or
> maps or models in game development.  For cases like these,
> lock-edit-unlock reportedly works better.  Git also might perform worse
> than other systems, like Subversion, when it comes to huge files --
> a property which is, again, common when it comes to binaries.
> [...]
> > Konstantin, I see you wrote ,  "the whole point of 'I am editing this
> > source file at the moment' becomes quite moot.", but is that really
> > true?
> What I wanted to point out, is that it's not a centralized system where
> there's only one reference copy of everything, including branches and
> files on them, so one can naturally point to a file on a branch at that
> branch's tip revision *as recorded on the central server* and say "OK,
> now I'm locking this file".  If everyone has their own repository,
> everyone has their very own set of local branches and files on them.
> Suppose my enterprise has a reference Git repo for a project (a quite
> common setup) so everyone pushes there.  Now I'm fetching from that
> repo and update my local branch "master" to be the same as that
> reference repo's "master" (so they're in sync).  Now let's suppose the
> tip commit on that branch contains a file foo.c, and I'm forking a
> local branch "feature" and start modifying foo.c -- does this count
> like I "sort of locked" that foo.c on the reference repo's "master"
> branch?  What if after some number of commits on my local "feature"
> branch I forked a "crazy-idea" branch off "feature" and continued to
> fiddle with foo.c on it, -- does this still count as locking foo.c in
> the reference repo's "master"?
> Hence I thought more about technical difficulties of exactly defining
> what to "lock" (even if such a lock would be possible).
> [...]

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To post to this group, send email to
To unsubscribe from this group, send email to
For more options, visit this group at

Reply via email to