On Sat, Feb 28, 2015, at 10:48 AM, Colin Walters wrote:
Hi,
TL;DR: Let's define a standard for embedding stronger checksums in tags and
commit messages:
https://github.com/cgwalters/homegit/blob/master/bin/git-evtag
[time passes]
I finally had a bit of time to pick this back up again
On 03/03/2015 12:44 AM, Junio C Hamano wrote:
[...]
I was about to suggest another alternative.
Pretend as if Git internally used SHA-512 (or whatever hash you
want to use) instead of SHA-1, compute the object names that
way. Recompute the contents of a tree object is by
On Tue, Mar 3, 2015 at 1:12 AM, Joey Hess i...@joeyh.name wrote:
I support this proposal, as someone who no longer releases tarballs
of my software, when I can possibly avoid it. I have worried about
signed tags / commits only being a SHA1 break away from useless.
As to the implementation,
Duy Nguyen pclo...@gmail.com writes:
On Tue, Mar 3, 2015 at 1:12 AM, Joey Hess i...@joeyh.name wrote:
I support this proposal, as someone who no longer releases tarballs
of my software, when I can possibly avoid it. I have worried about
signed tags / commits only being a SHA1 break away from
On Tue, Mar 3, 2015 at 6:44 AM, Junio C Hamano gits...@pobox.com wrote:
Duy Nguyen pclo...@gmail.com writes:
On Tue, Mar 3, 2015 at 1:12 AM, Joey Hess i...@joeyh.name wrote:
I support this proposal, as someone who no longer releases tarballs
of my software, when I can possibly avoid it. I
On 03/02/2015 12:08 PM, Junio C Hamano wrote:
I have a
hazy recollection of what it would take to replace SHA-1 in git with
something else; it should be possible (though tricky) to do it lazily,
where a tree entry has bits (eg, some of the currently unused file
mode bits) to denotes which hash
On Sat, Feb 28, 2015, at 03:34 PM, Morten Welinder wrote:
Is there a point to including a different checksum inside
a git tag? If someone can break the SHA-1 checksum
in the repository then the recorded SHA-256 checksum can
be changed. In other words, wouldn't you be just as well
off
I support this proposal, as someone who no longer releases tarballs
of my software, when I can possibly avoid it. I have worried about
signed tags / commits only being a SHA1 break away from useless.
As to the implementation, checksumming the collection of raw objects is
certainly superior to
On 03/02/2015 10:12 AM, Joey Hess wrote:
I support this proposal, as someone who no longer releases tarballs
of my software, when I can possibly avoid it. I have worried about
signed tags / commits only being a SHA1 break away from useless.
As to the implementation, checksumming the collection
Sam Vilain s...@vilain.net writes:
As to the implementation, checksumming the collection of raw objects is
certainly superior to tar. Colin had suggested sorting the objects by
checksum, but I don't think that is necessary. Just stream the commit
object, then its tree object, followed by the
Hi,
TL;DR: Let's define a standard for embedding stronger checksums in tags and
commit messages:
https://github.com/cgwalters/homegit/blob/master/bin/git-evtag
I think tarballs should go away as a source distribution mechanism in favor of
pure git. I won't go into too many details of the why
Is there a point to including a different checksum inside
a git tag? If someone can break the SHA-1 checksum
in the repository then the recorded SHA-256 checksum can
be changed. In other words, wouldn't you be just as well
off handing someone a SHA-1 commit id?
If you can guard the SHA-256 with
On Sat, Feb 28, 2015 at 09:48:05AM -0500, Colin Walters wrote:
The above strawman code allows embedding the SHA256(git archive | tar). Now,
in order to make this work, the byte output of git archive must never change
in the
future. I'm not sure how valid an assumption this is. Timestamps are
13 matches
Mail list logo
