{"thread":{"id":"11059","subject":"Re: git guidance","startedAt":"2007-11-29T15:52:20Z","lastAt":"2009-08-28T12:30:46Z","messageCount":25,"participants":["Jing Xue","Linus Torvalds","Al Boldi","Phillip Susi","Andreas Ericsson","Johannes Schindelin","Jakub Narebski","valdis.kletnieks@vt.edu","david@lang.hm","Björn Steinbrink","Luke Lu","Martin Langhoff"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"61404","messageId":"20071129105220.v40i22q4gw4cgoso@intranet.digizenstudio.com","threadId":"11059","inReplyTo":null,"subject":"Re: git guidance","fromName":"Jing Xue","fromEmail":"jingxue@digizenstudio.com","sentAt":"2007-11-29T15:52:20Z","receivedAt":"2007-11-29T15:52:20Z","isPatch":false,"sender":{"key":"jingxue@digizenstudio.com","avatar":null},"body":"\nQuoting Al Boldi <a1426z@gawab.com>:\n\n> Sure, browsing is the easy part, but Version Control starts when things\n> become writable.\n\nBut how is that supposed to work?  What happens when you make some\nchanges to a file and save it?  Do you want the \"git file system\" to\ncommit it right aways or wait until you to issue a \"commit\" command?\nThe first behavior would obviously be wrong, and the second would make\nthe \"file system\" not operationally transparent anyways. Right?\n\nBy the way, the only SCM I have worked with that tries to mount its\nrepository (or a view on top of it) as a file system is ClearCase with\nits dynamic views. And, between the buggy file system implementation,\nthe intrusion on workflow, and the lack of scalability, at least in\nthe organization I worked for, it turned out to be a horrible,\nhorrible, horrible idea.\n\nCheers.\n-- \nJing Xue\n"},{"id":"61407","messageId":"alpine.LFD.0.9999.0711290810170.8458@woody.linux-foundation.org","threadId":"11059","inReplyTo":"20071129105220.v40i22q4gw4cgoso@intranet.digizenstudio.com","subject":"Re: git guidance","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-11-29T16:19:58Z","receivedAt":"2007-11-29T16:19:58Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 29 Nov 2007, Jing Xue wrote:\n> \n> By the way, the only SCM I have worked with that tries to mount its\n> repository (or a view on top of it) as a file system is ClearCase with\n> its dynamic views. And, between the buggy file system implementation,\n> the intrusion on workflow, and the lack of scalability, at least in\n> the organization I worked for, it turned out to be a horrible,\n> horrible, horrible idea.\n\nDoing a read-only mount setup tends to be pretty easy, but it's largely \npointless except for specialty uses. Ie it's obviously not useful for \nactual *development*, but it can be useful for some other cases.\n\nFor example, a read-only revctrl filesystem can be a _very_ useful thing \nfor test-farms, where you may have hundreds of clients that run tests on \npossibly different versions at the same time. In situations like that, the \nread-only mount can actually often be done as a user-space NFS server on \nsome machine.\n\nThe advantage is that you don't need to export close to infinite amounts \nof versions from a \"real\" filesystem, or make the clients have their own \ncopies. And if you do it as a user-space NFS server (or samba, for that \nmatter), it's even portable, unlike many other approaches. The read-only \npart also makes 99% of all the complexity go away, and it turns out to be \na fairly easy exercise to do.\n\nSo I don't think the filesystem approach is _wrong_ per se. But yes, doing \nit read-write is almost invariably a big mistake. On operatign systems \nthat support a \"union mount\" approach, it's likely much better to have a \nread-only revctl thing, and then over-mount a regular filesystem on top of \nit.\n\nTrying to make it read-write from the revctl engine standpoint is almost \ncertainly totally insane.\n\n\t\t\t\tLinus\n"},{"id":"61567","messageId":"200712010950.15628.a1426z@gawab.com","threadId":"11059","inReplyTo":"alpine.LFD.0.9999.0711290810170.8458@woody.linux-foundation.org","subject":"Re: git guidance","fromName":"Al Boldi","fromEmail":"a1426z@gawab.com","sentAt":"2007-12-01T06:50:15Z","receivedAt":"2007-12-01T06:50:15Z","isPatch":false,"sender":{"key":"a1426z@gawab.com","avatar":null},"body":"Jing Xue wrote:\n> Quoting Al Boldi <a1426z@gawab.com>:\n> > Sure, browsing is the easy part, but Version Control starts when things\n> > become writable.\n>\n> But how is that supposed to work?  What happens when you make some\n> changes to a file and save it?  Do you want the \"git file system\" to\n> commit it right aways or wait until you to issue a \"commit\" command?\n> The first behavior would obviously be wrong, and the second would make\n> the \"file system\" not operationally transparent anyways. Right?\n\nNot sure what you mean by operationally transparent?  It would be transparent \nfor the updating client,  and the rest of the git-users would need to wait \nfor the commit from the updating client; which is ok, as this transparency \nis not meant to change the server-side git-update semantic.\n\nLinus Torvalds wrote:\n> On Thu, 29 Nov 2007, Jing Xue wrote:\n> > By the way, the only SCM I have worked with that tries to mount its\n> > repository (or a view on top of it) as a file system is ClearCase with\n> > its dynamic views. And, between the buggy file system implementation,\n> > the intrusion on workflow, and the lack of scalability, at least in\n> > the organization I worked for, it turned out to be a horrible,\n> > horrible, horrible idea.\n\nJudging an idea, based on a flawed implementation, doesn't prove that the \nidea itself is flawed.\n\nAnd...\n> Doing a read-only mount setup tends to be pretty easy, but it's largely\n> pointless except for specialty uses. Ie it's obviously not useful for\n> actual *development*, but it can be useful for some other cases.\n>\n> For example, a read-only revctrl filesystem can be a _very_ useful thing\n> for test-farms, where you may have hundreds of clients that run tests on\n> possibly different versions at the same time. In situations like that, the\n> read-only mount can actually often be done as a user-space NFS server on\n> some machine.\n>\n> The advantage is that you don't need to export close to infinite amounts\n> of versions from a \"real\" filesystem, or make the clients have their own\n> copies. And if you do it as a user-space NFS server (or samba, for that\n> matter), it's even portable, unlike many other approaches. The read-only\n> part also makes 99% of all the complexity go away, and it turns out to be\n> a fairly easy exercise to do.\n>\n> So I don't think the filesystem approach is _wrong_ per se. But yes, doing\n> it read-write is almost invariably a big mistake. On operatign systems\n> that support a \"union mount\" approach, it's likely much better to have a\n> read-only revctl thing, and then over-mount a regular filesystem on top of\n> it.\n\nYou could probably do that, or you could instead use cp -al.  Both would \nrequire some hacks to allow some basic version control.\n\n> Trying to make it read-write from the revctl engine standpoint is almost\n> certainly totally insane.\n\nSure, you wouldn't want to change the git-engine update semantics, as that \nsits on the server and handles all users.  But what the git model is \ncurrently missing is a client manager.  Right now, this is being worked \naround by replicating the git tree on the client, which still doesn't \nprovide the required transparency.\n\nIOW, git currently only implements the server-side use-case, but fails to \ndeliver on the client-side.  By introducing a git-client manager that \nhandles the transparency needs of a single user, it should be possible to \nclearly isolate update semantics for both the client and the server, each \nhandling their specific use-case.\n\n\nThanks!\n\n--\nAl\n"},{"id":"61954","messageId":"4755D2E8.5050402@cfl.rr.com","threadId":"11059","inReplyTo":"200712010950.15628.a1426z@gawab.com","subject":"Re: git guidance","fromName":"Phillip Susi","fromEmail":"psusi@cfl.rr.com","sentAt":"2007-12-04T22:21:28Z","receivedAt":"2007-12-04T22:21:28Z","isPatch":false,"sender":{"key":"psusi@cfl.rr.com","avatar":null},"body":"Al Boldi wrote:\n> Judging an idea, based on a flawed implementation, doesn't prove that the \n> idea itself is flawed.\n\nIt isn't the implementation that is flawed, it is the idea.  The entire \npoint of a change control system is that you explicitly define change \nsets and add comments to the set.  The filesystem was designed to allow \nchanges to be made willy-nilly.  If your goal is to perform change \ncontrol only with filesystem semantics, then you have a non starter as \ntheir goals are opposing.  Requiring an explicit command command is \nhardly burdensome, and otherwise, a git tree is perfectly transparent to \nnon git aware tools.\n\n> Sure, you wouldn't want to change the git-engine update semantics, as that \n> sits on the server and handles all users.  But what the git model is \n> currently missing is a client manager.  Right now, this is being worked \n> around by replicating the git tree on the client, which still doesn't \n> provide the required transparency.\n\nIt isn't missing a client manager, it was explicitly designed to not \nhave one, at least not as a distinct entity from a server, because it \ndoes not use a client/server architecture.  This is very much by design, \nnot a work around.\n\nWhat transparency are you requiring here?  You can transparently read \nyour git tree with all non git aware tools, what other meaning of \ntransparency is there?\n\n> IOW, git currently only implements the server-side use-case, but fails to \n> deliver on the client-side.  By introducing a git-client manager that \n> handles the transparency needs of a single user, it should be possible to \n> clearly isolate update semantics for both the client and the server, each \n> handling their specific use-case.\n\nAny talk of client or server makes no sense since git does not use a \nclient/server model.  If you wish to use a centralized repository, then \ngit can be set up to transparently push/pull to/from said repository if \nyou wish via hooks or cron jobs.\n\n"},{"id":"62173","messageId":"47583E57.9050208@op5.se","threadId":"11059","inReplyTo":"200712072035.47359.a1426z@gawab.com","subject":"Re: git guidance","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-12-06T18:24:23Z","receivedAt":"2007-12-06T18:24:23Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Al Boldi wrote:\n> Phillip Susi wrote:\n>> Al Boldi wrote:\n>>> IOW, git currently only implements the server-side use-case, but fails\n>>> to deliver on the client-side.  By introducing a git-client manager that\n>>> handles the transparency needs of a single user, it should be possible\n>>> to clearly isolate update semantics for both the client and the server,\n>>> each handling their specific use-case.\n>> Any talk of client or server makes no sense since git does not use a\n>> client/server model.\n> \n> Whether git uses the client/server model or not does not matter; what matters \n> is that there are two distinct use-cases at work here:  one on the \n> server/repository, and the other on the client.  \n> \n\nGit is distributed. The repository is everywhere. No server is actually needed.\nMany use one anyway since it can be convenient. It's not, however, necessary.\n\n>> If you wish to use a centralized repository, then\n>> git can be set up to transparently push/pull to/from said repository if\n>> you wish via hooks or cron jobs.\n> \n> Again, this only handles the interface to/from the server/repository, but \n> once you pulled the sources, it leaves you without Version Control on the \n> client.\n> \n\nNo, that's CVS, SVN and other centralized scm's. With git you have perfect\nversion control on each peer. That's the entire idea behind \"fully\ndistributed\".\n\n> By pulling the sources into a git-client manager mounted on some dir, it \n> should be possible to let the developer work naturally/transparently in a \n> readable/writeable manner, and only require his input when reverting locally \n> or committing to the server/repository.\n> \n\nHow is that different from what every SCM, including git, is doing today? The\nuser needs to tell the scm when it's time to take a snapshot of the current\nstate. Git is distributed though, so committing is usually not the same as\npublishing. Is that lack of a single command to commit and publish what's\nnagging you? If it's not, I completely fail to see what you're getting at,\nunless you've only ever looked at repositories without a worktree attached,\nor you think that git should work like an editor's \"undo\" functionality,\nwhich would be quite insane.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"},{"id":"62195","messageId":"Pine.LNX.4.64.0712062119090.21625@wbgn129.biozentrum.uni-wuerzburg.de","threadId":"11059","inReplyTo":"200712072155.04643.a1426z@gawab.com","subject":"Re: git guidance","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-12-06T20:22:18Z","receivedAt":"2007-12-06T20:22:18Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 7 Dec 2007, Al Boldi wrote:\n\n> Andreas Ericsson wrote:\n> > Al Boldi wrote:\n> >\n> > > By pulling the sources into a git-client manager mounted on some \n> > > dir, it should be possible to let the developer work \n> > > naturally/transparently in a readable/writeable manner, and only \n> > > require his input when reverting locally or committing to the \n> > > server/repository.\n> >\n> > How is that different from what every SCM, including git, is doing \n> > today? The user needs to tell the scm when it's time to take a \n> > snapshot of the current state. Git is distributed though, so \n> > committing is usually not the same as publishing. Is that lack of a \n> > single command to commit and publish what's nagging you? If it's not, \n> > I completely fail to see what you're getting at, unless you've only \n> > ever looked at repositories without a worktree attached, or you think \n> > that git should work like an editor's \"undo\" functionality, which \n> > would be quite insane.\n> \n> You need to re-read the thread.\n\nI don't know why you write that, and then say thanks.  Clearly, what you \nwrote originally, and what Andreas pointed out, were quite obvious \nindicators that git already does what you suggest.\n\nYou _do_ work \"transparently\" (whatever you understand by that overused \nterm) in the working directory, unimpeded by git.\n\nAnd whenever it is time to revert or commit, you cry for help, invoking \ngit.\n\nSo either you succeeded in making yourself misunderstood, or Andreas had \nquite the obvious and correct comment for you.\n\nNot that diffcult,\nDscho\n"},{"id":"62203","messageId":"47586DB0.5040706@cfl.rr.com","threadId":"11059","inReplyTo":"200712072155.04643.a1426z@gawab.com","subject":"Re: git guidance","fromName":"Phillip Susi","fromEmail":"psusi@cfl.rr.com","sentAt":"2007-12-06T21:46:24Z","receivedAt":"2007-12-06T21:46:24Z","isPatch":false,"sender":{"key":"psusi@cfl.rr.com","avatar":null},"body":"Al Boldi wrote:\n> When you read server, don't read it as localized; a server can be \n> distributed.  What distinguishes a server from an engine is that it has to \n> handle a multi-user use-case.  How that is implemented, locally or remotely \n> or distributed, is another issue.\n\nAnd again, git handles both use cases, so what's your point?\n\n> As explained before in this thread, replicating the git tree on the client \n> still doesn't provide the required transparency.\n\nIt has been pointed out to you that it DOES.  Either that or nobody else \nunderstands your nebulous use of \"transparency\" so maybe you should \ndefine it like we've been asking you.  Furthermore, the comment you \nreplied to said nothing about transparency, nor did your comment it was \nin reply to; rather it was pointing out the fact that your statement \nthat the git can not perform version control on the client is patently \nfalse.\n\n>> How is that different from what every SCM, including git, is doing today?\n>> The user needs to tell the scm when it's time to take a snapshot of the\n>> current state. Git is distributed though, so committing is usually not the\n>> same as publishing. Is that lack of a single command to commit and publish\n>> what's nagging you? If it's not, I completely fail to see what you're\n>> getting at, unless you've only ever looked at repositories without a\n>> worktree attached, or you think that git should work like an editor's\n>> \"undo\" functionality, which would be quite insane.\n> \n> You need to re-read the thread.\n\nPerhaps you should.  We have been trying to get you to explain how you \nthink git isn't \"transparent\" while at the same time pointing out how we \nthink it is.  You have failed to demonstrate any evidence to back up \nyour claims, all of which have been shown to be false.\n"},{"id":"62238","messageId":"200712070737.18519.a1426z@gawab.com","threadId":"11059","inReplyTo":"Pine.LNX.4.64.0712062119090.21625@wbgn129.biozentrum.uni-wuerzburg.de","subject":"Re: git guidance","fromName":"Al Boldi","fromEmail":"a1426z@gawab.com","sentAt":"2007-12-07T04:37:18Z","receivedAt":"2007-12-07T04:37:18Z","isPatch":false,"sender":{"key":"a1426z@gawab.com","avatar":null},"body":"Johannes Schindelin wrote:\n> Hi,\n\nHi\n\n> On Fri, 7 Dec 2007, Al Boldi wrote:\n> > You need to re-read the thread.\n>\n> I don't know why you write that, and then say thanks.  Clearly, what you\n> wrote originally, and what Andreas pointed out, were quite obvious\n> indicators that git already does what you suggest.\n>\n> You _do_ work \"transparently\" (whatever you understand by that overused\n> term) in the working directory, unimpeded by git.\n\nIf you go back in the thread, you may find a link to a gitfs client that \nsomebody kindly posted.  This client pretty much defines the transparency \nI'm talking about.  The only problem is that it's read-only.\n\nTo make it really useful, it has to support versioning locally, disconnected \nfrom the server repository.  One way to implement this, could be by \ncommitting every update unconditionally to an on-the-fly created git \nrepository private to the gitfs client.\n\nWith this transparently created private scratch repository it should then be \npossible for the same gitfs to re-expose the locally created commits, all \nwithout any direct user-intervention.\n\nLater, this same scratch repository could then be managed by the normal \ngit-management tools/commands to ultimately update the backend git \nrepositories.\n\nBTW:  Sorry for my previous posts that contained the wrong date; it seems \nthat hibernation sometimes advances the date by a full 24h.  Has anybody \nnoticed this as well?\n\n\nThanks!\n\n--\nAl\n"},{"id":"62261","messageId":"475906F7.5010309@op5.se","threadId":"11059","inReplyTo":"200712070737.18519.a1426z@gawab.com","subject":"Re: git guidance","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-12-07T08:40:23Z","receivedAt":"2007-12-07T08:40:23Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Al Boldi wrote:\n> Johannes Schindelin wrote:\n>> Hi,\n> \n> Hi\n> \n>> On Fri, 7 Dec 2007, Al Boldi wrote:\n>>> You need to re-read the thread.\n>> I don't know why you write that, and then say thanks.  Clearly, what you\n>> wrote originally, and what Andreas pointed out, were quite obvious\n>> indicators that git already does what you suggest.\n>>\n>> You _do_ work \"transparently\" (whatever you understand by that overused\n>> term) in the working directory, unimpeded by git.\n> \n> If you go back in the thread, you may find a link to a gitfs client that \n> somebody kindly posted.  This client pretty much defines the transparency \n> I'm talking about.  The only problem is that it's read-only.\n> \n> To make it really useful, it has to support versioning locally, disconnected \n> from the server repository.  One way to implement this, could be by \n> committing every update unconditionally to an on-the-fly created git \n> repository private to the gitfs client.\n> \n\nEarlier you said that you need to be able to tell git when you want to make\na commit, which means pretty much any old filesystem could serve as gitfs.\nNow you're saying you want every single update to be committed, which would\nmake it mimic an editor's undo functionality. I still don't get what it is\nyou really want.\n\n> With this transparently created private scratch repository it should then be \n> possible for the same gitfs to re-expose the locally created commits, all \n> without any direct user-intervention.\n> \n> Later, this same scratch repository could then be managed by the normal \n> git-management tools/commands to ultimately update the backend git \n> repositories.\n> \n\nThat's exactly what's happening today. I imagine whoever wrote the gitfs\nthing did so to facilitate testing, or as some form of intellectual\nmasturbation.\n\n\nSo, to get to the bottom of this, which of the following workflows is it you\nwant git to support?\n\n### WORKFLOW A ###\nedit, edit, edit\nedit, edit, edit\nedit, edit, edit\nOops I made a mistake and need to hop back to \"current - 12\".\nedit, edit, edit\nedit, edit, edit\npublish everything, similar to just tarring up your workdir and sending out\n### END WORKFLOW A ###\n\n### WORKFLOW B ###\nedit, edit, edit\nok this looks good, I want to save a checkpoint here\nedit, edit, edit\nlooks good again. next checkpoint\nedit, edit, edit\noh crap, back to checkpoint 2\nedit, edit, edit\nooh, that's better. save a checkpoint and publish those checkpoints\n### END WORKFLOW B ###\n\nIf you could just answer that question and stop writing \"transparent\" or\nany synonym thereof six times in each email, we can possibly help you.\n\nAs it stands now though, nobody is very interested because you haven't\nexplained how you want this \"transparency\" of yours to work in an every\nday scenario.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"},{"id":"62271","messageId":"200712071353.11654.a1426z@gawab.com","threadId":"11059","inReplyTo":"475906F7.5010309@op5.se","subject":"Re: git guidance","fromName":"Al Boldi","fromEmail":"a1426z@gawab.com","sentAt":"2007-12-07T10:53:11Z","receivedAt":"2007-12-07T10:53:11Z","isPatch":false,"sender":{"key":"a1426z@gawab.com","avatar":null},"body":"Andreas Ericsson wrote:\n> So, to get to the bottom of this, which of the following workflows is it\n> you want git to support?\n>\n> ### WORKFLOW A ###\n> edit, edit, edit\n> edit, edit, edit\n> edit, edit, edit\n> Oops I made a mistake and need to hop back to \"current - 12\".\n> edit, edit, edit\n> edit, edit, edit\n> publish everything, similar to just tarring up your workdir and sending\n> out ### END WORKFLOW A ###\n>\n> ### WORKFLOW B ###\n> edit, edit, edit\n> ok this looks good, I want to save a checkpoint here\n> edit, edit, edit\n> looks good again. next checkpoint\n> edit, edit, edit\n> oh crap, back to checkpoint 2\n> edit, edit, edit\n> ooh, that's better. save a checkpoint and publish those checkpoints\n> ### END WORKFLOW B ###\n\n### WORKFLOW C ###\nfor every save on a gitfs mounted dir, do an implied checkpoint, commit, or \npublish (should be adjustable), on its privately created on-the-fly \nrepository.\n### END WORKFLOW C ###\n\nFor example:\n\n  echo \"// last comment on this file\" >> /gitfs.mounted/file\n\nshould do an implied checkpoint, and make these checkpoints immediately \nvisible under some checkpoint branch of the gitfs mounted dir.\n\nNote, this way the developer gets version control without even noticing, and \nworks completely transparent to any kind of application.\n\n\nThanks!\n\n--\nAl\n"},{"id":"62274","messageId":"m3prxiu3oo.fsf@roke.D-201","threadId":"11059","inReplyTo":"200712071353.11654.a1426z@gawab.com","subject":"Re: git guidance","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-12-07T11:47:49Z","receivedAt":"2007-12-07T11:47:49Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Al Boldi <a1426z@gawab.com> writes:\n> Andreas Ericsson wrote:\n\n>> So, to get to the bottom of this, which of the following workflows is it\n>> you want git to support?\n>>\n>> ### WORKFLOW A ###\n>> edit, edit, edit\n>> edit, edit, edit\n>> edit, edit, edit\n>> Oops I made a mistake and need to hop back to \"current - 12\".\n>> edit, edit, edit\n>> edit, edit, edit\n>> publish everything, similar to just tarring up your workdir and sending\n>> out ### END WORKFLOW A ###\n>>\n>> ### WORKFLOW B ###\n>> edit, edit, edit\n>> ok this looks good, I want to save a checkpoint here\n>> edit, edit, edit\n>> looks good again. next checkpoint\n>> edit, edit, edit\n>> oh crap, back to checkpoint 2\n>> edit, edit, edit\n>> ooh, that's better. save a checkpoint and publish those checkpoints\n>> ### END WORKFLOW B ###\n> \n> ### WORKFLOW C ###\n> for every save on a gitfs mounted dir, do an implied checkpoint, commit, or \n> publish (should be adjustable), on its privately created on-the-fly \n> repository.\n> ### END WORKFLOW C ###\n\nIt looks like it is WORKFLOW A (with the fact that each ',' is file\nsave stated explicitely rather than implicitely).\n \n> For example:\n> \n>   echo \"// last comment on this file\" >> /gitfs.mounted/file\n> \n> should do an implied checkpoint, and make these checkpoints immediately \n> visible under some checkpoint branch of the gitfs mounted dir.\n> \n> Note, this way the developer gets version control without even noticing, and \n> works completely transparent to any kind of application.\n\nWhy not use versioning filesystem for that, for example ext3cow\n(which looks suprisingly git-like, when you take into account that\nfor ext3cow history is linear and centralized, so one can use date\nor sequential number to name commits).\n\nSee GitLinks page on Git Wiki, \"Other links\" section:\n  http://www.ext3cow.com/\n\nVersion control system is all about WORKFLOW B, where programmer\ncontrols when it is time to commit (and in private repository he/she\ncan then rewrite history to arrive at \"Perfect patch series\"[*1*]);\nsomething that for example CVS failed at, requiring programmer to do\na merge if upstream has any changes when trying to commit.\n\n[*1*] I have lost link to post at LKML about rewriting history to\n      arrive at perfect patch _series_. IIRC I have found it first\n      time on this mailing list. I would be grateful for sending this\n      link if you have it. TIA.\n\n-- \nJakub Narebski\nShadeHawk on #git\n"},{"id":"62277","messageId":"47593D00.9030003@op5.se","threadId":"11059","inReplyTo":"200712071353.11654.a1426z@gawab.com","subject":"Re: git guidance","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-12-07T12:30:56Z","receivedAt":"2007-12-07T12:30:56Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Al Boldi wrote:\n> Andreas Ericsson wrote:\n>> So, to get to the bottom of this, which of the following workflows is it\n>> you want git to support?\n>>\n>> ### WORKFLOW A ###\n>> edit, edit, edit\n>> edit, edit, edit\n>> edit, edit, edit\n>> Oops I made a mistake and need to hop back to \"current - 12\".\n>> edit, edit, edit\n>> edit, edit, edit\n>> publish everything, similar to just tarring up your workdir and sending\n>> out ### END WORKFLOW A ###\n>>\n>> ### WORKFLOW B ###\n>> edit, edit, edit\n>> ok this looks good, I want to save a checkpoint here\n>> edit, edit, edit\n>> looks good again. next checkpoint\n>> edit, edit, edit\n>> oh crap, back to checkpoint 2\n>> edit, edit, edit\n>> ooh, that's better. save a checkpoint and publish those checkpoints\n>> ### END WORKFLOW B ###\n> \n> ### WORKFLOW C ###\n> for every save on a gitfs mounted dir, do an implied checkpoint, commit, or \n> publish (should be adjustable), on its privately created on-the-fly \n> repository.\n> ### END WORKFLOW C ###\n> \n\nSo you *do* want an editor's undo function, but for an entire filesystem.\nThat's a handy thing to have every now and then, but it's not what git\n(or any other scm) does.\n\n> For example:\n> \n>   echo \"// last comment on this file\" >> /gitfs.mounted/file\n> \n> should do an implied checkpoint, and make these checkpoints immediately \n> visible under some checkpoint branch of the gitfs mounted dir.\n> \n> Note, this way the developer gets version control without even noticing, and \n> works completely transparent to any kind of application.\n> \n\nOne other thing that's fairly important to note is that this can never\never handle changesets, since each write() of each file will be a commit\non its own. It's so far from what git does that I think you'd be better\noff just implementing it from scratch, or looking at a versioned fs, like\nJakub suggested in his reply.\n\nYou're also neglecting one very important aspect of what an SCM provides\nif you go down this road, namely project history. You basically have two\nchoices with this \"implicit save on each edit\":\n* force the user to supply a commit message for each and every edit\n* ignore commit messages altogether\n\nObviously, forcing a commit message each time is the only way to get some\nsort of proper history to look at after it's done, but it's also such an\nappalling nuisance that I doubt *anyone* will actually like that, and since\nchangesets aren't supported, you'll have \"implement xniz api, commit 1 of X\"\nmessages. Cumbersome, stupid, and not very useful.\n\nIgnoring commit messages altogether means you ignore the entire history,\nand the SCM then becomes a filesystem-wide \"undo\" cache. This could\nofcourse work, but it's something akin to building a nuclear powerplant\nto power a single lightbulb.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"},{"id":"62168","messageId":"200712072035.47359.a1426z@gawab.com","threadId":"11059","inReplyTo":"4755D2E8.5050402@cfl.rr.com","subject":"Re: git guidance","fromName":"Al Boldi","fromEmail":"a1426z@gawab.com","sentAt":"2007-12-07T17:35:47Z","receivedAt":"2007-12-07T17:35:47Z","isPatch":false,"sender":{"key":"a1426z@gawab.com","avatar":null},"body":"Phillip Susi wrote:\n> Al Boldi wrote:\n> > IOW, git currently only implements the server-side use-case, but fails\n> > to deliver on the client-side.  By introducing a git-client manager that\n> > handles the transparency needs of a single user, it should be possible\n> > to clearly isolate update semantics for both the client and the server,\n> > each handling their specific use-case.\n>\n> Any talk of client or server makes no sense since git does not use a\n> client/server model.\n\nWhether git uses the client/server model or not does not matter; what matters \nis that there are two distinct use-cases at work here:  one on the \nserver/repository, and the other on the client.  \n\n> If you wish to use a centralized repository, then\n> git can be set up to transparently push/pull to/from said repository if\n> you wish via hooks or cron jobs.\n\nAgain, this only handles the interface to/from the server/repository, but \nonce you pulled the sources, it leaves you without Version Control on the \nclient.\n\nBy pulling the sources into a git-client manager mounted on some dir, it \nshould be possible to let the developer work naturally/transparently in a \nreadable/writeable manner, and only require his input when reverting locally \nor committing to the server/repository.\n\n\nThanks!\n\n--\nAl\n"},{"id":"62181","messageId":"200712072155.04643.a1426z@gawab.com","threadId":"11059","inReplyTo":"47583E57.9050208@op5.se","subject":"Re: git guidance","fromName":"Al Boldi","fromEmail":"a1426z@gawab.com","sentAt":"2007-12-07T18:55:04Z","receivedAt":"2007-12-07T18:55:04Z","isPatch":false,"sender":{"key":"a1426z@gawab.com","avatar":null},"body":"Andreas Ericsson wrote:\n> Al Boldi wrote:\n> > Phillip Susi wrote:\n> >> Al Boldi wrote:\n> >>> IOW, git currently only implements the server-side use-case, but fails\n> >>> to deliver on the client-side.  By introducing a git-client manager\n> >>> that handles the transparency needs of a single user, it should be\n> >>> possible to clearly isolate update semantics for both the client and\n> >>> the server, each handling their specific use-case.\n> >>\n> >> Any talk of client or server makes no sense since git does not use a\n> >> client/server model.\n> >\n> > Whether git uses the client/server model or not does not matter; what\n> > matters is that there are two distinct use-cases at work here:  one on\n> > the server/repository, and the other on the client.\n>\n> Git is distributed. The repository is everywhere. No server is actually\n> needed. Many use one anyway since it can be convenient. It's not, however,\n> necessary.\n\nWhen you read server, don't read it as localized; a server can be \ndistributed.  What distinguishes a server from an engine is that it has to \nhandle a multi-user use-case.  How that is implemented, locally or remotely \nor distributed, is another issue.\n\n> >> If you wish to use a centralized repository, then\n> >> git can be set up to transparently push/pull to/from said repository if\n> >> you wish via hooks or cron jobs.\n> >\n> > Again, this only handles the interface to/from the server/repository,\n> > but once you pulled the sources, it leaves you without Version Control\n> > on the client.\n>\n> No, that's CVS, SVN and other centralized scm's. With git you have perfect\n> version control on each peer. That's the entire idea behind \"fully\n> distributed\".\n\nAs explained before in this thread, replicating the git tree on the client \nstill doesn't provide the required transparency.\n\n> > By pulling the sources into a git-client manager mounted on some dir, it\n> > should be possible to let the developer work naturally/transparently in\n> > a readable/writeable manner, and only require his input when reverting\n> > locally or committing to the server/repository.\n>\n> How is that different from what every SCM, including git, is doing today?\n> The user needs to tell the scm when it's time to take a snapshot of the\n> current state. Git is distributed though, so committing is usually not the\n> same as publishing. Is that lack of a single command to commit and publish\n> what's nagging you? If it's not, I completely fail to see what you're\n> getting at, unless you've only ever looked at repositories without a\n> worktree attached, or you think that git should work like an editor's\n> \"undo\" functionality, which would be quite insane.\n\nYou need to re-read the thread.\n\n\nThanks!\n\n--\nAl\n\n"},{"id":"62302","messageId":"200712072204.48410.a1426z@gawab.com","threadId":"11059","inReplyTo":"m3prxiu3oo.fsf@roke.D-201","subject":"Re: git guidance","fromName":"Al Boldi","fromEmail":"a1426z@gawab.com","sentAt":"2007-12-07T19:04:48Z","receivedAt":"2007-12-07T19:04:48Z","isPatch":false,"sender":{"key":"a1426z@gawab.com","avatar":null},"body":"Jakub Narebski wrote:\n> Al Boldi <a1426z@gawab.com> writes:\n> > For example:\n> >\n> >   echo \"// last comment on this file\" >> /gitfs.mounted/file\n> >\n> > should do an implied checkpoint, and make these checkpoints immediately\n> > visible under some checkpoint branch of the gitfs mounted dir.\n> >\n> > Note, this way the developer gets version control without even noticing,\n> > and works completely transparent to any kind of application.\n>\n> Why not use versioning filesystem for that, for example ext3cow\n> (which looks suprisingly git-like, when you take into account that\n> for ext3cow history is linear and centralized, so one can use date\n> or sequential number to name commits).\n>\n> See GitLinks page on Git Wiki, \"Other links\" section:\n>   http://www.ext3cow.com/\n\nSure, Linus mentioned the cow idea before in this thread, but you would still \nneed a few hacks to get some basic Version Control features.  \n\n> Version control system is all about WORKFLOW B, where programmer\n> controls when it is time to commit (and in private repository he/she\n> can then rewrite history to arrive at \"Perfect patch series\"[*1*]);\n> something that for example CVS failed at, requiring programmer to do\n> a merge if upstream has any changes when trying to commit.\n\nBecause WORKFLOW C is transparent, it won't affect other workflows.  So you \ncould still use your normal WORKFLOW B in addition to WORKFLOW C, gaining an \nadditional level of version control detail at no extra cost other than the \ngit-engine scratch repository overhead.\n\nBTW, is git efficient enough to handle WORKFLOW C?\n\n\nThanks!\n\n--\nAl\n"},{"id":"62309","messageId":"11272.1197056185@turing-police.cc.vt.edu","threadId":"11059","inReplyTo":"200712072204.48410.a1426z@gawab.com","subject":"Re: git guidance","fromName":"","fromEmail":"valdis.kletnieks@vt.edu","sentAt":"2007-12-07T19:36:25Z","receivedAt":"2007-12-07T19:36:25Z","isPatch":false,"sender":{"key":"valdis.kletnieks@vt.edu","avatar":null},"body":"On Fri, 07 Dec 2007 22:04:48 +0300, Al Boldi said:\n\n> Because WORKFLOW C is transparent, it won't affect other workflows.  So you \n> could still use your normal WORKFLOW B in addition to WORKFLOW C, gaining an \n> additional level of version control detail at no extra cost other than the \n> git-engine scratch repository overhead.\n> \n> BTW, is git efficient enough to handle WORKFLOW C?\n\nImagine the number of commits a 'make clean; make' will do in a kernel tree, as\nit commits all those .o files... :)\n\n"},{"id":"62312","messageId":"Pine.LNX.4.64.0712071259020.12607@asgard.lang.hm","threadId":"11059","inReplyTo":"200712071353.11654.a1426z@gawab.com","subject":"Re: git guidance","fromName":"","fromEmail":"david@lang.hm","sentAt":"2007-12-07T21:17:38Z","receivedAt":"2007-12-07T21:17:38Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Fri, 7 Dec 2007, Al Boldi wrote:\n\n> Andreas Ericsson wrote:\n>> So, to get to the bottom of this, which of the following workflows is it\n>> you want git to support?\n>>\n>> ### WORKFLOW A ###\n>> edit, edit, edit\n>> edit, edit, edit\n>> edit, edit, edit\n>> Oops I made a mistake and need to hop back to \"current - 12\".\n>> edit, edit, edit\n>> edit, edit, edit\n>> publish everything, similar to just tarring up your workdir and sending\n>> out ### END WORKFLOW A ###\n>>\n>> ### WORKFLOW B ###\n>> edit, edit, edit\n>> ok this looks good, I want to save a checkpoint here\n>> edit, edit, edit\n>> looks good again. next checkpoint\n>> edit, edit, edit\n>> oh crap, back to checkpoint 2\n>> edit, edit, edit\n>> ooh, that's better. save a checkpoint and publish those checkpoints\n>> ### END WORKFLOW B ###\n>\n> ### WORKFLOW C ###\n> for every save on a gitfs mounted dir, do an implied checkpoint, commit, or\n> publish (should be adjustable), on its privately created on-the-fly\n> repository.\n> ### END WORKFLOW C ###\n>\n> For example:\n>\n>  echo \"// last comment on this file\" >> /gitfs.mounted/file\n>\n> should do an implied checkpoint, and make these checkpoints immediately\n> visible under some checkpoint branch of the gitfs mounted dir.\n>\n> Note, this way the developer gets version control without even noticing, and\n> works completely transparent to any kind of application.\n\nso if you have a script that does\n\necho \"mail header\" >tmpfile\necho \"subject: >>tmpfile\necho >>tmpfile\necho \"body\" >>tmpfile\n\nyou want to have four seperate commits\n\nwhat if you have a perl script\n\nopen outfile \">tmpfile\";\nprint outfile \"mail header\\n\";\nprint outfile \"subject:\\n\\n\";\nprint outfile \"body\\n\";\nclose ourfile;\n\nhow many seperate commits do you think should take place?\n\nwhat if $|=1 (unbuffered output, so that each print statement becomes \nvisable to other programs immediatly)?\n\nwhat if the file is changed via mmap? should each byte/word written to \nmemory be a commit? or when the mmap is closed? or when the kernel happens \nto flush the page to disk?\n\n'recording every change to a filesystem' is a very incomplete definition \nof a goal.\n\nDavid Lang\n"},{"id":"62338","messageId":"20071207220025.GD2001@atjola.homenet","threadId":"11059","inReplyTo":"200712071353.11654.a1426z@gawab.com","subject":"Re: git guidance","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2007-12-07T22:00:25Z","receivedAt":"2007-12-07T22:00:25Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2007.12.07 13:53:11 +0300, Al Boldi wrote:\n> Andreas Ericsson wrote:\n> > So, to get to the bottom of this, which of the following workflows is it\n> > you want git to support?\n> >\n> > ### WORKFLOW A ###\n> > edit, edit, edit\n> > edit, edit, edit\n> > edit, edit, edit\n> > Oops I made a mistake and need to hop back to \"current - 12\".\n> > edit, edit, edit\n> > edit, edit, edit\n> > publish everything, similar to just tarring up your workdir and sending\n> > out ### END WORKFLOW A ###\n> >\n> > ### WORKFLOW B ###\n> > edit, edit, edit\n> > ok this looks good, I want to save a checkpoint here\n> > edit, edit, edit\n> > looks good again. next checkpoint\n> > edit, edit, edit\n> > oh crap, back to checkpoint 2\n> > edit, edit, edit\n> > ooh, that's better. save a checkpoint and publish those checkpoints\n> > ### END WORKFLOW B ###\n> \n> ### WORKFLOW C ###\n> for every save on a gitfs mounted dir, do an implied checkpoint, commit, or \n> publish (should be adjustable), on its privately created on-the-fly \n> repository.\n> ### END WORKFLOW C ###\n> \n> For example:\n> \n>   echo \"// last comment on this file\" >> /gitfs.mounted/file\n> \n> should do an implied checkpoint, and make these checkpoints immediately \n> visible under some checkpoint branch of the gitfs mounted dir.\n> \n> Note, this way the developer gets version control without even noticing, and \n> works completely transparent to any kind of application.\n\nOuch... That looks worse than \"plain\" per-file versioning. Not only do\nyou per definition get \"broken\" commits if there's a change that affects\ntwo dependent files, you also get an insane amount of commits just for\ntesting stuff, or fixing bugs.\n\nAnd unless you use some kind of union-fs on top (or keep ignored files\nin special unversioned area in your gitfs, which seems somewhat ugly),\nyou'll probably also have to track lots of files in the working\ndirectory that are generated, unless you want to re-generate them after\neach reboot. And that leads to even more absolutely useless revisions.\n\nJust thinking of my vim .swp files (which I definitely don't want to\nloose on a crash/power outtage/pkill -9 .<ENTER> dammit) makes me scream\nbecause of the gazillion of commits they will produce (and no, I don't\nwant them in some special out of tree directory).\n\nPlus, I have vim setup to _replace_ files on write, so that I can more\neasily use hard-linked copies with changing all copies at once _unless_\nI explicitly want to, meaning that I'd get full remove/add commits,\nwhich are absolutely useless. And trying to detect such patterns\n(rename, then write the changed file with the old name and then delete\nthe renamed file) is probably not worth the trouble, because you\ncoincidently might _want_ to have just these three steps recorded when\nyou happen to perform them manually. And if you go for heuristics,\nyou'll complain each time you get a false-positive/negative.\n\n\nThat said, out of pure curiousness I came up with the attached script\nwhich just uses inotifywait to watch a directory and issue git commands\non certain events. It is extremely stupid, but seems to work. And at\nleast it hasn't got the drawbacks of a real gitfs regarding the need to\nhave a \"separate\" non-versioned storage area for the working directory,\nbecause it simply uses the existing working directory wherever that\nmight be stored. It doesn't use GIT_DIR/WORK_DIR yet, but hey, should be\neasy to add...\n\nFeel free to mess with that thing, hey, maybe you even like it and\nextend it to match your proposed workflow even more. I for sure won't\nuse or even extend it, so you're likely on your own there.\n\nSide-note: Writing that script probably took less time than writing this\nemail and probably less time than was wasted on this topic. Makes me\nwant to use today's preferred \"Code talks, b...s... walks\" statement,\nbut I'll refrain from that... Just because I lack the credibility to say\nthat, and the script attached is quite crappy ;-)\n\nBjörn\n\n\n#!/bin/bash\ninotifywait -m -r --exclude ^\\./\\.git/.* -e close_write -e move -e create -e delete . 2>/dev/null |\nwhile read FILE_PATH EVENT FILE_NAME\ndo\n\tFILE_NAME=\"$FILE_PATH$FILE_NAME\"\n\tFILE_NAME=${FILE_NAME#./}\n\n\t# git doesn't care about directories\n\tif [ -d \"$FILE_NAME\" ]\n\tthen\n\t\tcontinue\n\tfi\n\n\tcase \"$EVENT\" in\n\t\t*CLOSE_WRITE*)\n\t\tACTION=change\n\t\t;;\n\t\t*MOVED_TO*)\n\t\tACTION=create\n\t\t;;\n\t\t*MODIFY*)\n\t\tACTION=change\n\t\t;;\n\t\t*DELETE*)\n\t\tACTION=delete\n\t\t;;\n\t\t*MOVED_FROM*)\n\t\tACTION=delete\n\t\t;;\n\t\t*CREATE*)\n\t\tACTION=create\n\t\t;;\n\t\t*)\n\t\tcontinue\n\t\t;;\n\tesac\n\n\tcase $ACTION in\n\t\tcreate)\n\t\tgit add \"$FILE_NAME\"\n\t\tgit commit -m \"$FILE_NAME created\"\n\t\t;;\n\t\tdelete)\n\t\tgit rm --cached \"$FILE_NAME\"\n\t\tgit commit -m \"$FILE_NAME removed\"\n\t\t;;\n\t\tchange)\n\t\tgit add \"$FILE_NAME\"\n\t\tgit commit -m \"$FILE_NAME changed\"\n\t\t;;\n\tesac\ndone\n"},{"id":"62342","messageId":"1D40FF54-64FD-4507-8E5D-02A01F2DD8EB@vicaya.com","threadId":"11059","inReplyTo":"11272.1197056185@turing-police.cc.vt.edu","subject":"Re: git guidance","fromName":"Luke Lu","fromEmail":"git@vicaya.com","sentAt":"2007-12-07T22:07:29Z","receivedAt":"2007-12-07T22:07:29Z","isPatch":false,"sender":{"key":"git@vicaya.com","avatar":null},"body":"On Dec 7, 2007, at 11:36 AM, Valdis.Kletnieks@vt.edu wrote:\n> On Fri, 07 Dec 2007 22:04:48 +0300, Al Boldi said:\n>\n>> Because WORKFLOW C is transparent, it won't affect other  \n>> workflows.  So you\n>> could still use your normal WORKFLOW B in addition to WORKFLOW C,  \n>> gaining an\n>> additional level of version control detail at no extra cost other  \n>> than the\n>> git-engine scratch repository overhead.\n>>\n>> BTW, is git efficient enough to handle WORKFLOW C?\n>\n> Imagine the number of commits a 'make clean; make' will do in a  \n> kernel tree, as\n> it commits all those .o files... :)\n\nMy guess is that Al is not really a developer (product management/ \nmarketing?), what he has in mind is probably not an SCM but a backup  \nsystem a la Mac's time machine or Netapp's snapshots that also  \nsupport disconnected commits. I think that git could be a suitable  \nengine for such systems, after a few tweaks to avoid compressing  \nalready compressed blobs like jpeg, mp3 and mpeg etc.\n\n__Luke\n"},{"id":"62370","messageId":"200712080756.21980.a1426z@gawab.com","threadId":"11059","inReplyTo":"11272.1197056185@turing-police.cc.vt.edu","subject":"Re: git guidance","fromName":"Al Boldi","fromEmail":"a1426z@gawab.com","sentAt":"2007-12-08T04:56:21Z","receivedAt":"2007-12-08T04:56:21Z","isPatch":false,"sender":{"key":"a1426z@gawab.com","avatar":null},"body":"Valdis.Kletnieks@vt.edu wrote:\n> On Fri, 07 Dec 2007 22:04:48 +0300, Al Boldi said:\n> > Because WORKFLOW C is transparent, it won't affect other workflows.  So\n> > you could still use your normal WORKFLOW B in addition to WORKFLOW C,\n> > gaining an additional level of version control detail at no extra cost\n> > other than the git-engine scratch repository overhead.\n> >\n> > BTW, is git efficient enough to handle WORKFLOW C?\n>\n> Imagine the number of commits a 'make clean; make' will do in a kernel\n> tree, as it commits all those .o files... :)\n\n.o files???\n\nIt probably goes without saying, that gitfs should have some basic \nconfiguration file to setup its transparent behaviour, and which would most \nprobably contain an include / exclude file-filter mask, and probably other \nbasic configuration options.  But this is really secondary to the \nimplementation, and the question remains whether git is efficient enough.\n\nIOW, how big is the git commit overhead as compared to a normal copy?\n\n\nThanks!\n\n--\nAl\n"},{"id":"62378","messageId":"7135.1197090987@turing-police.cc.vt.edu","threadId":"11059","inReplyTo":"200712080756.21980.a1426z@gawab.com","subject":"Re: git guidance","fromName":"","fromEmail":"valdis.kletnieks@vt.edu","sentAt":"2007-12-08T05:16:27Z","receivedAt":"2007-12-08T05:16:27Z","isPatch":false,"sender":{"key":"valdis.kletnieks@vt.edu","avatar":null},"body":"On Sat, 08 Dec 2007 07:56:21 +0300, Al Boldi said:\n\n> It probably goes without saying, that gitfs should have some basic \n> configuration file to setup its transparent behaviour\n\nBut then it's not *truly* transparent, is it?\n\nAnd that leaves another question - if you make a config file that excludes\nall the .o files - then what's backing the .o files?  Those data blocks need\nto be *someplace*.  Maybe you can do something ugly like use unionfs to\ncombine your gitfs with something else to store the other files...\n\nBut at that point, you're probably better off just creating a properly\ndesigned versioning filesystem.\n"},{"id":"62380","messageId":"46a038f90712072233v4ee1143cx68a82d15cfaa4402@mail.gmail.com","threadId":"11059","inReplyTo":"200712010950.15628.a1426z@gawab.com","subject":"Re: git guidance","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2007-12-08T06:33:00Z","receivedAt":"2007-12-08T06:33:00Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On Dec 1, 2007 7:50 PM, Al Boldi <a1426z@gawab.com> wrote:\n> Not sure what you mean by operationally transparent?  It would be transparent\n> for the updating client,  and the rest of the git-users would need to wait\n> for the commit from the updating client; which is ok, as this transparency\n> is not meant to change the server-side git-update semantic.\n\nI guess what he means is that when your write to the file -- from your\neditor -- it can't be considered a commit. During an editing session\nyou might write a dozen times, only to commit it once you are happy\n(that it compiles, passes tests, etc).\n\n> Sure, you wouldn't want to change the git-engine update semantics, as that\n> sits on the server and handles all users.  But what the git model is\n> currently missing is a client manager.  Right now, this is being worked\n> around by replicating the git tree on the client, which still doesn't\n> provide the required transparency.\n\nIf you want a dumb-ish client CVS-style, you can try git-cvsserver.\nBut the git model is definitely superior -- \"replicating the tree on\nthe client\" is not a workaround but a central strategy.\n\nHave you used git and other DSCMs much? From your writing, it sounds\nlike you may have misunderstood how some of the principles of git work\nout in practice.\n\ncheers,\n\n\nm\n"},{"id":"62397","messageId":"200712081341.54589.a1426z@gawab.com","threadId":"11059","inReplyTo":"7135.1197090987@turing-police.cc.vt.edu","subject":"Re: git guidance","fromName":"Al Boldi","fromEmail":"a1426z@gawab.com","sentAt":"2007-12-08T10:41:54Z","receivedAt":"2007-12-08T10:41:54Z","isPatch":false,"sender":{"key":"a1426z@gawab.com","avatar":null},"body":"Valdis.Kletnieks@vt.edu wrote:\n> On Sat, 08 Dec 2007 07:56:21 +0300, Al Boldi said:\n> > It probably goes without saying, that gitfs should have some basic\n> > configuration file to setup its transparent behaviour\n>\n> But then it's not *truly* transparent, is it?\n\nDon't mistake transparency with some form of auto-heuristic.  Transparency \nonly means that it inserts functionality without impeding your normal \nworkflow.\n\n> And that leaves another question - if you make a config file that excludes\n> all the .o files - then what's backing the .o files?  Those data blocks\n> need to be *someplace*.  Maybe you can do something ugly like use unionfs\n> to combine your gitfs with something else to store the other files...\n\nOr any number of other possible implementation scenarios...\n\n> But at that point, you're probably better off just creating a properly\n> designed versioning filesystem.\n\nBut gitfs is not about designing a versioning filesystem, it's about \ndesigning a transparent interface into git to handle an SCM use-case.\n\n\nThanks!\n\n--\nAl\n"},{"id":"62402","messageId":"Pine.LNX.4.64.0712081106200.27959@racer.site","threadId":"11059","inReplyTo":"200712072204.48410.a1426z@gawab.com","subject":"Re: git guidance","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-12-08T11:13:55Z","receivedAt":"2007-12-08T11:13:55Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 7 Dec 2007, Al Boldi wrote:\n\n> Jakub Narebski wrote:\n>\n> > Version control system is all about WORKFLOW B, where programmer \n> > controls when it is time to commit (and in private repository he/she \n> > can then rewrite history to arrive at \"Perfect patch series\"[*1*]); \n> > something that for example CVS failed at, requiring programmer to do a \n> > merge if upstream has any changes when trying to commit.\n> \n> Because WORKFLOW C is transparent, it won't affect other workflows.  So \n> you could still use your normal WORKFLOW B in addition to WORKFLOW C, \n> gaining an additional level of version control detail at no extra cost \n> other than the git-engine scratch repository overhead.\n> \n> BTW, is git efficient enough to handle WORKFLOW C?\n\nThe question is not if git is efficient enough to handle workflow C, but \nif that worflow is efficient enough to help anybody.\n\nGuess what takes me the longest time when committing?  The commit message.  \nBut it is really helpful, so there is a _point_ in writing one, and there \nis a _point_ in committing when I do it: it is a point in time where I \nexpect the tree to be in a good shape, to be compilable, and to solve a \nspecific problem which I describe in the commit message.\n\nSo I absolutely hate this \"transparency\".  Git _is_ transparent; it does \nnot affect any of my other tools; they still work very well \nthankyouverymuch.\n\nWhat your version of \"transparency\" would do: destroy bisectability, make \nan absolute gibberish of the history, and more!\n\nNobody could read the output of \"git log\" and form an understanding what \nwas done.  Nobody could read the commit message for a certain \"git blame\"d \nline that she tries to make sense of.\n\nIOW you would revert the whole meaning of the term Source Code Management.\n\nHth,\nDscho\n"},{"id":"121998","messageId":"alpine.DEB.1.00.0908281424100.7434@intel-tinevez-2-302","threadId":"11059","inReplyTo":"20071207220025.GD2001@atjola.homenet","subject":"inotify-commit, was Re: git guidance","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-08-28T12:30:46Z","receivedAt":"2009-08-28T12:30:46Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\n[long Cc: list culled, as they probably forgot about this thread]\n\nOn Fri, 7 Dec 2007, Björn Steinbrink wrote:\n\n> That said, out of pure curiousness I came up with the attached script \n> which just uses inotifywait to watch a directory and issue git commands \n> on certain events. It is extremely stupid, but seems to work. And at \n> least it hasn't got the drawbacks of a real gitfs regarding the need to \n> have a \"separate\" non-versioned storage area for the working directory, \n> because it simply uses the existing working directory wherever that \n> might be stored. It doesn't use GIT_DIR/WORK_DIR yet, but hey, should be \n> easy to add...\n> \n> Feel free to mess with that thing, hey, maybe you even like it and\n> extend it to match your proposed workflow even more. I for sure won't\n> use or even extend it, so you're likely on your own there.\n> \n> Side-note: Writing that script probably took less time than writing this\n> email and probably less time than was wasted on this topic. Makes me\n> want to use today's preferred \"Code talks, b...s... walks\" statement,\n> but I'll refrain from that... Just because I lack the credibility to say\n> that, and the script attached is quite crappy ;-)\n\nI could not agree more with the statement.\n\nAs it happens, I have a very delicate setup that we tested in a test \nenvironment as much as possible, but now we have to deploy it and I want \nto be able to rewind very quickly to a known-good state.\n\nSo I adjusted your script a little.  It now reads like this:\n\n-- snip --\n#!/bin/sh\n\n# Originally by Bjoern Steinbrink, simplified by Johannes Schindelin\n\ninotifywait -m -r --exclude ^\\./\\.git/.* \\\n        -e close_write -e move -e create -e delete . 2>/dev/null |\nwhile read FILE_PATH EVENT FILE_NAME\ndo\n        FILE_NAME=\"$FILE_PATH$FILE_NAME\"\n        FILE_NAME=${FILE_NAME#./}\n\n        # git doesn't care about directories\n        test -d \"$FILE_NAME\" && continue\n\n        case \"$EVENT\" in\n        *MOVED_TO*|*CREATE*)\n                git add \"$FILE_NAME\"\n                git commit -m \"$FILE_NAME created\"\n                ;;\n        *CLOSE_WRITE*|*MODIFY*)\n                git add \"$FILE_NAME\"\n                git commit -m \"$FILE_NAME changed\"\n                ;;\n        *DELETE*|*MOVED_FROM*)\n                git rm --cached \"$FILE_NAME\"\n                git commit -m \"$FILE_NAME removed\"\n                ;;\n        esac\ndone\n-- snap --\n\nThanks for your original script!\n\nCiao,\nDscho\n"}]}