Phillip Susi <psusi@cfl.rr.com> writes:

> Goswin von Brederlow wrote:
>> If you have 2 similar files, not identical, in different locations?
>> I highly doubt that.
>>
>> If the files are identical then git will see the same hash for both
>> and only store one copy. But not if the differ slightly.
>
> You tell git when you move a file and it records the fact in the
> change record. Because of this it knows the predecessor file even
> though it has changed location, and can properly diff with it.

And you are going to tell git about every single file that is in a
different location in debian and for example redhat?

Or every file that gets moved in a debian package between versions?

Have fun.

MfG
Goswin


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Goswin von Brederlow wrote:

And you are going to tell git about every single file that is in a
different location in debian and for example redhat?

Or every file that gets moved in a debian package between versions?

Have fun.


That's kind of the whole idea of a revision control system. Rather than
tell git to remove the file, manually move the file, then tell git to
add the file, you just tell git to move the file.



--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Hi,

On Mon, 2008-06-23 at 17:25:00 -0400, Phillip Susi wrote:
> Zenaan Harkness wrote:
> > I've had the thought a few times that it could make sense to store a
> > repo's files in a git hierarchy, rather than in a package pool.
> >
> > As in, raw files, with package description files which lookup the SHA
> > for each file in the package, when a package is installed.
>
> The package files are compressed tar archives, and because of this, they
> are binary files which alter radically between versions, and thus, would
> have horrible delta compression.

Probably what you are looking for instead is something like debdelta?

<http://packages.debian.org/sid/debdelta>

> > My primary thought is that repository size might be drastically reduced.
> > Perhaps some md5sum numbers could be run to test this.
>
> It would not be reduced by much and would have a tremendous overhead to
> access as a result, which the mirrors could never handle, and it would
> break backwards compatibility since http or ftp could no longer be used
> to fetch packages.

I think debdelta does not have those problems, but I've not used it
ever.

regards,
guillem


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Joey Hess wrote:

Phillip Susi wrote:
You tell git when you move a file and it records the fact in the change
record.


No, that's how every VCS *except* git works.


I'm afraid you have it backwards. In CVS when you move a file it thinks
you removed one file and added a totally new file somewhere else. In
SVN, it thinks that you copied the old file to a new location, and then
removed it. In git, the diff clearly shows fileA -> fileB.




--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Phillip Susi wrote:
> I'm afraid you have it backwards. In CVS when you move a file it thinks
> you removed one file and added a totally new file somewhere else. In
> SVN, it thinks that you copied the old file to a new location, and then
> removed it. In git, the diff clearly shows fileA -> fileB.

"Git does not explicitly record file revision relationships at any level
below the source code tree; content copying and moving between files (so
called "rename detection") is done at runtime."
-- http://git.or.cz/gitwiki/Git

HTH

--
see shy jo