linux-kernel - Re: git guidance

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

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