Re: git lock files
might contain good thoughts about locking + git: Jan 12, 2010 Interest in locking mechanism? http://git.661346.n2.nabble.com/Interest-in-locking-mechanism-td4293383.html Jul 04, 2013 intend-to-edit flag http://git.661346.n2.nabble.com/intend-to-edit-flag-tp7591127.html Sep 17, 2013 Locking files / git http://git.661346.n2.nabble.com/Locking-files-git-tp7596435.html -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git lock files
Stefan Beller writes:
> I could imagine a "git lock" command which looks like this:
>
> git config lock.centralServer origin
> git config lock.defaultBranch master
>
> git lock add [branch] [--]
> git lock remove [branch] [--]
> git lock ls []
>
> And the way this is implemented is roughly (unoptimized, just showing
> how you would achieve this with todays command set):
> ...
> git fetch --depth=1 $(git config --get lock.centralServer)
> refs/locks/$(git config --get lock.defaultBranch)
> git checkout refs/locks/$(git config --get lock.centralServer)/$(git
> config --get lock.defaultBranch)
> switch(option) {
> case add:
> if exist
> return -1
> else
> echo $(git config --get user.name) $(date) >
> git add && git commit "add new lock"
> fi
> case remove:
> if exist
> # todo: check if the same user locked it before
> rm
> else
> return -1
> fi
> case ls:
> ls -R .
> }
> git push $(git config --get lock.centralServer) refs/locks/$(git config
> --get lock.defaultBranch)
> git
>
> That said you could just manipulate the git objects directly, no need
> to check out to the working dir.
>
> The server would only need to allow pushes to a refs/locks directory and be
> done.
> the client side would need to have a plumbing command, so you could easily
> integrate
> a git locking to your application if you don't want to provide a merge driver.
I do not think that would be very useful nor even be a good starting
point, even though I think it is a good tangent to think about how
to improve the support for the centralized workflow.
You cannot afford to force clients keep polling the central server
for the refs/locks/my-branch, if you want a good "everybody relies
on central-server to coordinate" workflow experience.
And even without "file locking", once you start assuming "everybody
relies on central-server to coordinate" workflow (which is common in
corporate settings), you would be better off introducing a mechanism
to push notification from the server side to the clients to improve
support for other things, like "the client watches these branches,
doing a hanging Get or whatever, waiting for the server to notify"
anyway. The kind of notification that distributed use of Git can do
without.
And once that kind of mechanism is there, "the client is notified
not to touch these paths on this branch", "the client is notified
that it is now OK to touch these paths on this branch after
updating", etc., would be a natural addition.
I highly doubt that exchanging data via the "git fetch" and "git
push" will be a good vehicle to implement such an async notification
mechanism.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git lock files (Was: GIT for Microsoft Access projects)
On Wed, Jun 10, 2015 at 12:47 AM, Fredrik Gustafsson wrote: > On Tue, Jun 09, 2015 at 10:19:43AM -0700, Stefan Beller wrote: >> Just because Git allows distributed workflows, doesn't mean we >> should only focus on being distributed IMHO. >> >> The question for content not being mergable easily pops up all >> the time. (Game/Graphics designers, documents, all this binary >> stuff, where there is no good merge driver). >> >> I could imagine a "git lock" command which looks like this: > > You do know that gitolite has locking functionality? > Yes, and it's cooking its own thing, it's not upstream (in git core I mean) Locking is useful not just when using gitolite, but any hosting solution I believe. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git lock files (Was: GIT for Microsoft Access projects)
On Tue, Jun 09, 2015 at 10:19:43AM -0700, Stefan Beller wrote: > Just because Git allows distributed workflows, doesn't mean we > should only focus on being distributed IMHO. > > The question for content not being mergable easily pops up all > the time. (Game/Graphics designers, documents, all this binary > stuff, where there is no good merge driver). > > I could imagine a "git lock" command which looks like this: You do know that gitolite has locking functionality? -- Fredrik Gustafsson phone: +46 733-608274 e-mail: iv...@iveqy.com website: http://www.iveqy.com -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git lock files (Was: GIT for Microsoft Access projects)
On Tue, Jun 9, 2015 at 11:21 AM, wrote: > Thanks folks, I am digesting all you have said. I did not intend to answer your original question, but to start a discussion on the feasibility of a dedicated "git lock" command. There are lots of things which are checked in alongside the code (The code is which is why you want to use Git in the first place), such as Graphics, CAD, design documents (maybe in binary format such as ODF, MS Excel). All I did was proposing a new command and laying out its behavior. By being careful at what to use as the porcelain command line and what to use as a stable plumbing command, other programs could rely on that. (Some proprietary CAD tools such as Altium have a subversion integration [1], maybe Git wants to offer an easy interface to allow for Git integration as easily?) > > Now the command line I can do (I'm a programmer) but the secretary here I > doubt. > > So is there at GUI interface for this? Does it work on Windows systems? As all I was saying is dreaming out new concepts, there is currently no code. > > Thanks, > > Paul [1] http://techdocs.altium.com/display/ADOH/Version+Control+and+Altium+Designer -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git lock files (Was: GIT for Microsoft Access projects)
On Tue, 9 Jun 2015 13:21:44 -0500 wrote: > Thanks folks, I am digesting all you have said. > > Now the command line I can do (I'm a programmer) but the secretary > here I doubt. > > So is there at GUI interface for this? Does it work on Windows > systems? That's why I asked whether the thing you do really want is a document management system, not a version control system. Yes, Git works on Windows thanks to folks behind the Git for Windows project (often and errorneously called "msysGit" in the internets) and yes there do exist mature Windows GUI front-ends to it, with TortoiseGit and Git Extensions being supposedly the most visible picks. But there's such thing as an irreducible complexity: while these tools strive to be user-friendly, and TortoiseGit even tries to make you think you're using Subversion rather than Git, they won't hide all the underlying complexity of a DVCS tool, which Git is, from the user. So... I bet for your random user, it would be much easier to switch to the browser window and upload another version of their document there, with a short note describing what they do and why. This is how a typical DMS works. You won't get all that awesomness Git gives you to fiddle with your source code files but in return you'll get a system which requires next to zero training for any layman to use it. Please rememeber about [1]. Many of the statements that post does are outdated but its essense remains to be true when it comes to handing off Git to users not possessing ninja-level computer skills. I especially recommend to think through this particular passage: | They often struggle to use version control at all; are you now going | to teach them the difference between “pull” and “update”, between | “commit” and “push”? Look me in the eyes and say that with a straight | face. I also wonder how do you intend to explain them why they can't push because someone else had just did that, and what to do about this, and why. (And whose version should win, in the end, as the files you intend to work with are not subject for merging in the usual sense of this word -- when it comes to plain text files.) 1. http://blog.red-bean.com/sussman/?p=79 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git lock files (Was: GIT for Microsoft Access projects)
Thanks folks, I am digesting all you have said.
Now the command line I can do (I'm a programmer) but the secretary here I doubt.
So is there at GUI interface for this? Does it work on Windows systems?
Thanks,
Paul
Stefan Beller wrote:
> Just because Git allows distributed workflows, doesn't mean we
> should only focus on being distributed IMHO.
>
> The question for content not being mergable easily pops up all
> the time. (Game/Graphics designers, documents, all this binary
> stuff, where there is no good merge driver).
>
> I could imagine a "git lock" command which looks like this:
>
> git config lock.centralServer origin
> git config lock.defaultBranch master
>
> git lock add [branch] [--]
> git lock remove [branch] [--]
> git lock ls []
>
> And the way this is implemented is roughly (unoptimized, just showing
> how you would achieve this with todays command set):
>
> git fetch --depth=1 $(git config --get lock.centralServer)
> refs/locks/$(git config --get lock.defaultBranch)
> git checkout refs/locks/$(git config --get lock.centralServer)/$(git
> config --get lock.defaultBranch)
> switch(option) {
> case add:
> if exist
> return -1
> else
> echo $(git config --get user.name) $(date) >
> git add && git commit "add new lock"
> fi
> case remove:
> if exist
> # todo: check if the same user locked it before
> rm
> else
> return -1
> fi
> case ls:
> ls -R .
> }
> git push $(git config --get lock.centralServer) refs/locks/$(git config
> --get lock.defaultBranch)
> git
>
> That said you could just manipulate the git objects directly, no need
> to check out to the working dir.
>
> The server would only need to allow pushes to a refs/locks directory and be
> done.
> the client side would need to have a plumbing command, so you could easily
> integrate
> a git locking to your application if you don't want to provide a merge driver.
>
> Thanks,
> Stefan
>
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
