| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <475906F7.5010309@op5.se> Date: Fri, 07 Dec 2007 09:40:23 +0100 From: Andreas Ericsson <ae@....se> To: Al Boldi <a1426z@...ab.com> CC: Johannes Schindelin <Johannes.Schindelin@....de>, Phillip Susi <psusi@....rr.com>, Linus Torvalds <torvalds@...ux-foundation.org>, Jing Xue <jingxue@...izenstudio.com>, linux-kernel@...r.kernel.org, git@...r.kernel.org Subject: Re: git guidance Al Boldi wrote: > Johannes Schindelin wrote: >> Hi, > > Hi > >> On Fri, 7 Dec 2007, Al Boldi wrote: >>> You need to re-read the thread. >> I don't know why you write that, and then say thanks. Clearly, what you >> wrote originally, and what Andreas pointed out, were quite obvious >> indicators that git already does what you suggest. >> >> You _do_ work "transparently" (whatever you understand by that overused >> term) in the working directory, unimpeded by git. > > If you go back in the thread, you may find a link to a gitfs client that > somebody kindly posted. This client pretty much defines the transparency > I'm talking about. The only problem is that it's read-only. > > To make it really useful, it has to support versioning locally, disconnected > from the server repository. One way to implement this, could be by > committing every update unconditionally to an on-the-fly created git > repository private to the gitfs client. > Earlier you said that you need to be able to tell git when you want to make a commit, which means pretty much any old filesystem could serve as gitfs. Now you're saying you want every single update to be committed, which would make it mimic an editor's undo functionality. I still don't get what it is you really want. > With this transparently created private scratch repository it should then be > possible for the same gitfs to re-expose the locally created commits, all > without any direct user-intervention. > > Later, this same scratch repository could then be managed by the normal > git-management tools/commands to ultimately update the backend git > repositories. > That's exactly what's happening today. I imagine whoever wrote the gitfs thing did so to facilitate testing, or as some form of intellectual masturbation. So, to get to the bottom of this, which of the following workflows is it you want git to support? ### WORKFLOW A ### edit, edit, edit edit, edit, edit edit, edit, edit Oops I made a mistake and need to hop back to "current - 12". edit, edit, edit edit, edit, edit publish everything, similar to just tarring up your workdir and sending out ### END WORKFLOW A ### ### WORKFLOW B ### edit, edit, edit ok this looks good, I want to save a checkpoint here edit, edit, edit looks good again. next checkpoint edit, edit, edit oh crap, back to checkpoint 2 edit, edit, edit ooh, that's better. save a checkpoint and publish those checkpoints ### END WORKFLOW B ### If you could just answer that question and stop writing "transparent" or any synonym thereof six times in each email, we can possibly help you. As it stands now though, nobody is very interested because you haven't explained how you want this "transparency" of yours to work in an every day scenario. -- Andreas Ericsson andreas.ericsson@....se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists