Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reproducible Git Bundles

baecher.dev

Post reply on HN
Print view View original

21–30 of 38 posts

Re: Reproducible Git Bundles

#21

Post by Dylan16807 »

dartos wrote: post #3
Hackbraten wrote: post #2

[flagged]

This comment is baffling. Reproducibility in general is a key part of all sciences. Practically speaking, it’s important from a security perspective. If you can make a secure configuration of some system you’d want to be 100% certain you can reproduce that same configuration on some other system. Deep and provable reproducibility doesn’t matter too much for most web servers, unless security is a top priority.

Your science comparison is also baffling, to be honest. A typical "non-reproducible" compile meets the scientific standard of "reproducible". Imagine if recreating an experiment was expected to give you the same date points, in the same order, with the same timestamps. The two definitions of "reproducible" are worlds apart.

Re: Reproducible Git Bundles

#22

Post by dartos »

Dylan16807 wrote: post #21
dartos wrote: post #3

Earlier quoted context omitted.

This comment is baffling. Reproducibility in general is a key part of all sciences. Practically speaking, it’s important from a security perspective. If you can make a secure configuration of some system you’d want to be 100% certain you can reproduce that same configuration on some other system. Deep and provable reproducibility doesn’t matter too much for most web servers, unless security is a top priority.

Your science comparison is also baffling, to be honest. A typical "non-reproducible" compile meets the scientific standard of "reproducible". Imagine if recreating an experiment was expected to give you the same date points, in the same order, with the same timestamps. The two definitions of "reproducible" are worlds apart.

What “scientific standard” are you talking about?

I think if it was possible to configure the universe (time included) in the exact same way, save for a single variable, that would be the _only_ way science experiments would be done.

We almost have the ability to do that with software, but we just don’t most of the time. That’s okay for many applications, but not all of them.

Re: Reproducible Git Bundles

#24

Post by wkennington »

stepupmakeup wrote: post #8

Why not just use tar or any other archive tool on the repository .git folder? Unless your repository is a un-gc'd mess with millions of unpacked objects...

This is also non-deterministic between versions of tar, but I guess for this usecase that would be fine. It’s just not good for reproducible build systems when trying to recreate tarballs after years.

Re: Reproducible Git Bundles

#25

Post by wkennington »

avar wrote: post #16
CuriousCosmic wrote: post #15

Earlier quoted context omitted.

git bundles have a standardised format (defined in [1]) while git archives did not and continue to not have one. Git can still handle all previous bundle versions and you can specify which version of the bundle standard you want to use when creating bundles. So no the git 2.38 issue should not be a problem for bundles even if the format changes in the future. 1. https://git-scm.com/docs/gitformat-bundle

Standardized format != guaranteed reproducible. Git makes no promises that it'll keep PACK contents stable, just that they're guaranteed to "deflate" to the same contents. Which is what the linked article discovered. Threading is a trivial way to discover this, but there's other ways PACK contents might differ across versions.

Yeah, even tar is not stable bit for bit across versions.

Re: Reproducible Git Bundles

#26

Post by Dylan16807 »

dartos wrote: post #22
Dylan16807 wrote: post #21

Earlier quoted context omitted.

Your science comparison is also baffling, to be honest. A typical "non-reproducible" compile meets the scientific standard of "reproducible". Imagine if recreating an experiment was expected to give you the same date points, in the same order, with the same timestamps. The two definitions of "reproducible" are worlds apart.

What “scientific standard” are you talking about? I think if it was possible to configure the universe (time included) in the exact same way, save for a single variable, that would be the _only_ way science experiments would be done. We almost have the ability to do that with software, but we just don’t most of the time. That’s okay for many applications, but not all of them.

The standard that real world experiments are held to to qualify as "reproduction". Your hypothetical is interesting but it's clearly a different standard from what we actually use.

Re: Reproducible Git Bundles

#27

Post by remram »

nektro wrote: post #20

> The naive solution of simply backing up the entire file-system tree is clearly not desirable since that would clutter the backup with useless build artifacts. `git rm -r --cached .` > One solution is to create a fresh clone (with --mirror), but that will typically consist of many small files which isn't ideal for backups, either. this is precisely what tar(1) was made for..

Do you mean `git clean`?

Re: Reproducible Git Bundles

#29

Post by RcouF1uZ4gsC »

>The naive solution of simply backing up the entire file-system tree is clearly not desirable since that would clutter the backup with useless build artifacts.

Just ignore the files in .gitignore and backup the entire file-system tree.

Don’t be clever. This is a backup of source code that took many hours/days/weeks of effort to create. Since git is mainly source code, it is not that big of space hog.

Disk space is cheap. Time is not.

Re: Reproducible Git Bundles

#30

Post by chx »

git bundle is the answer to the question "I need to keep my development trees in sync on different computers, with no network connection between them." https://stackoverflow.com/q/3635952/308851 buried in comments is a great script automating the process https://github.com/cxw42/git-tools/blob/master/wormhole alas it's abandoned but still, it's pretty great.
Post reply on HN