# Re: git guidance

9 messages from 2007-11-28 to 2007-11-29. Participants: Al Boldi, Rogan Dawes, Johannes Schindelin, Jakub Narebski, Kyle Moffett.
Thread: https://gitlist.dev/t/11040

## Al Boldi, 2007-11-28 12:49

Subject: Re: git guidance
Message-ID: <200711281549.02663.a1426z@gawab.com>
URL: https://gitlist.dev/e/200711281549.02663.a1426z%40gawab.com
In-Reply-To: <20071127235237.GF15227@1wt.eu>

```
Willy Tarreau wrote:
> It should not turn into an endless thread led by people who want to
> redefine GIT's roadmap, but experience sharing helps a lot with GIT.

Well, now that you mentioned it, if there is one thing I dislike, it's for 
version control to start mutilating your sources.  Version Control should be 
completely transparent.  GIT isn't.


Thanks!

--
Al

```

## Rogan Dawes, 2007-11-28 13:45

Subject: Re: git guidance
Message-ID: <474D70DD.4020601@dawes.za.net>
URL: https://gitlist.dev/e/474D70DD.4020601%40dawes.za.net
In-Reply-To: <200711281549.02663.a1426z@gawab.com>

```
Al Boldi wrote:
> Willy Tarreau wrote:
>> It should not turn into an endless thread led by people who want to
>> redefine GIT's roadmap, but experience sharing helps a lot with GIT.
> 
> Well, now that you mentioned it, if there is one thing I dislike, it's for 
> version control to start mutilating your sources.  Version Control should be 
> completely transparent.  GIT isn't.
> 
> Thanks!
> 
> --
> Al
> 

Care to explain? Git is quite happy handling arbitrary binary content, 
so I find it difficult to believe that it is changing your source code 
in strange ways.

Rogan

```

## Johannes Schindelin, 2007-11-28 15:46

Subject: Re: git guidance
Message-ID: <Pine.LNX.4.64.0711281545170.27959@racer.site>
URL: https://gitlist.dev/e/Pine.LNX.4.64.0711281545170.27959%40racer.site
In-Reply-To: <474D70DD.4020601@dawes.za.net>

```
Hi,

On Wed, 28 Nov 2007, Rogan Dawes wrote:

> Al Boldi wrote:
>
> > Willy Tarreau wrote:
> >
> > > It should not turn into an endless thread led by people who want to 
> > > redefine GIT's roadmap, but experience sharing helps a lot with GIT.
> > 
> > Well, now that you mentioned it, if there is one thing I dislike, it's 
> > for version control to start mutilating your sources.  Version Control 
> > should be completely transparent.  GIT isn't.
> 
> Care to explain? Git is quite happy handling arbitrary binary content, 
> so I find it difficult to believe that it is changing your source code 
> in strange ways.

It is nice of you to ask him to explain: Unless this handwaving claim is 
substantiated, it is quite hard to argue with.

Ciao,
Dscho

```

## Al Boldi, 2007-11-28 17:14

Subject: Re: git guidance
Message-ID: <200711282014.27299.a1426z@gawab.com>
URL: https://gitlist.dev/e/200711282014.27299.a1426z%40gawab.com
In-Reply-To: <Pine.LNX.4.64.0711281545170.27959@racer.site>

```
Johannes Schindelin wrote:
> Hi,

Hi!

git@vger sometimes bounces, so let's leave lkml as backup.

> On Wed, 28 Nov 2007, Rogan Dawes wrote:
> > Al Boldi wrote:
> > > Willy Tarreau wrote:
> > > > It should not turn into an endless thread led by people who want to
> > > > redefine GIT's roadmap, but experience sharing helps a lot with GIT.
> > >
> > > Well, now that you mentioned it, if there is one thing I dislike, it's
> > > for version control to start mutilating your sources.  Version Control
> > > should be completely transparent.  GIT isn't.
> >
> > Care to explain? Git is quite happy handling arbitrary binary content,
> > so I find it difficult to believe that it is changing your source code
> > in strange ways.
>
> It is nice of you to ask him to explain: Unless this handwaving claim is
> substantiated, it is quite hard to argue with.

Sure, the problem with GIT is that it stores the sources inside a backend 
container that is only accessible via GIT; iow, you can't retrieve your 
sources directly / transparently.

One way to achieve transparency could be to allow mounting GIT on a dir-mount 
point.  And just use that dir normally, while GIT manages all the rest in 
the background.


Thanks!

--
Al

```

## Johannes Schindelin, 2007-11-28 18:14

Subject: Re: git guidance
Message-ID: <Pine.LNX.4.64.0711281811500.27959@racer.site>
URL: https://gitlist.dev/e/Pine.LNX.4.64.0711281811500.27959%40racer.site
In-Reply-To: <200711282014.27299.a1426z@gawab.com>

```
Hi,

On Wed, 28 Nov 2007, Al Boldi wrote:

> git@vger sometimes bounces, so let's leave lkml as backup.

Fair enough.

> Johannes Schindelin wrote:
> > On Wed, 28 Nov 2007, Rogan Dawes wrote:
> > > Al Boldi wrote:
> > > > Willy Tarreau wrote:
> > > > > It should not turn into an endless thread led by people who want 
> > > > > to redefine GIT's roadmap, but experience sharing helps a lot 
> > > > > with GIT.
> > > >
> > > > Well, now that you mentioned it, if there is one thing I dislike, 
> > > > it's for version control to start mutilating your sources.  
> > > > Version Control should be completely transparent.  GIT isn't.
> > >
> > > Care to explain? Git is quite happy handling arbitrary binary 
> > > content, so I find it difficult to believe that it is changing your 
> > > source code in strange ways.
> >
> > It is nice of you to ask him to explain: Unless this handwaving claim 
> > is substantiated, it is quite hard to argue with.
> 
> Sure, the problem with GIT is that it stores the sources inside a 
> backend container that is only accessible via GIT; iow, you can't 
> retrieve your sources directly / transparently.

That is a very funny way to define a "transparent SCM".  Are you 
complaining about SQL servers being "not transparent"?

By that definition, no SCM, not even CVS, is transparent.  Nothing short 
of unpacked directories of all versions (wasting a lot of disk space) 
would.

IOW the issue you raised is a non-issue.

Ciao,
Dscho

```

## Al Boldi, 2007-11-28 18:30

Subject: Re: git guidance
Message-ID: <200711282130.12864.a1426z@gawab.com>
URL: https://gitlist.dev/e/200711282130.12864.a1426z%40gawab.com
In-Reply-To: <Pine.LNX.4.64.0711281811500.27959@racer.site>

```
Johannes Schindelin wrote:
> By that definition, no SCM, not even CVS, is transparent.  Nothing short
> of unpacked directories of all versions (wasting a lot of disk space)
> would.

Who said anything about unpacking?

I'm talking about GIT transparently serving a Virtual Version Control dir to 
be mounted on the client.


Thanks!

--
Al

```

## Jakub Narebski, 2007-11-28 18:41

Subject: Re: git guidance
Message-ID: <fikcns$mte$1@ger.gmane.org>
URL: https://gitlist.dev/e/fikcns%24mte%241%40ger.gmane.org
In-Reply-To: <200711282130.12864.a1426z@gawab.com>

```
Al Boldi wrote:
> Johannes Schindelin wrote:

>> By that definition, no SCM, not even CVS, is transparent.  Nothing short
>> of unpacked directories of all versions (wasting a lot of disk space)
>> would.
> 
> Who said anything about unpacking?
> 
> I'm talking about GIT transparently serving a Virtual Version Control dir to 
> be mounted on the client.

Are you talking about something like (in alpha IIRC) gitfs?

  http://www.sfgoth.com/~mitch/linux/gitfs/


Besides, you can always use "git show <revision>:<file>". For example
gitweb (and I think other web interfaces) can show any version of a file
or a directory, accessing only repository.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

```

## Al Boldi, 2007-11-29 05:27

Subject: Re: git guidance
Message-ID: <200711290827.04950.a1426z@gawab.com>
URL: https://gitlist.dev/e/200711290827.04950.a1426z%40gawab.com
In-Reply-To: <200711282130.12864.a1426z@gawab.com>

```
Jakub Narebski wrote:
> Al Boldi wrote:
> > Johannes Schindelin wrote:
> >> By that definition, no SCM, not even CVS, is transparent.  Nothing
> >> short of unpacked directories of all versions (wasting a lot of disk
> >> space) would.
> >
> > Who said anything about unpacking?
> >
> > I'm talking about GIT transparently serving a Virtual Version Control
> > dir to be mounted on the client.
>
> Are you talking about something like (in alpha IIRC) gitfs?
>
>   http://www.sfgoth.com/~mitch/linux/gitfs/

This looks like a good start.

> Besides, you can always use "git show <revision>:<file>". For example
> gitweb (and I think other web interfaces) can show any version of a file
> or a directory, accessing only repository.

Sure, browsing is the easy part, but Version Control starts when things 
become writable.


Thanks for the link!

--
Al

```

## Kyle Moffett, 2007-11-29 12:57

Subject: Re: git guidance
Message-ID: <6DFD2A04-1D18-4B04-98BA-AE14F6BDB4C7@mac.com>
URL: https://gitlist.dev/e/6DFD2A04-1D18-4B04-98BA-AE14F6BDB4C7%40mac.com
In-Reply-To: <200711290827.04950.a1426z@gawab.com>

```
On Nov 29, 2007, at 00:27:04, Al Boldi wrote:
> Jakub Narebski wrote:
>> Besides, you can always use "git show <revision>:<file>". For  
>> example gitweb (and I think other web interfaces) can show any  
>> version of a file or a directory, accessing only repository.
>
> Sure, browsing is the easy part, but Version Control starts when  
> things become writable.

But... git history is very inherently completely immutable once  
created... that's the only way you can index everything with a simple  
SHA-1.  If you want to write to the "git filesystem" by adding new  
commits then you need to use the appropriate commands, same as every  
other VCS on the planet.

Cheers,
Kyle Moffett

```
