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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 07 Dec 2007 09:40:23 +0100
From:	Andreas Ericsson <>
To:	Al Boldi <>
CC:	Johannes Schindelin <>,
	Phillip Susi <>,
	Linus Torvalds <>,
	Jing Xue <>,,
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

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

### 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

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         
OP5 AB                   
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
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists