User: Password:
|
|
Subscribe / Log in / New account

The trouble with firmware

The trouble with firmware

Posted Jan 6, 2011 15:13 UTC (Thu) by ibukanov (subscriber, #3942)
Parent article: The trouble with firmware

It is unfortunate that the term "rewriting history" was used. The issue is about been able *not to* download things one do not want that live in a history of some remote git repository. So it is more in line of not receiving unwanted mail together with some wanted one.


(Log in to post comments)

The trouble with firmware

Posted Jan 6, 2011 18:31 UTC (Thu) by cesarb (subscriber, #6266) [Link]

Well, git-filter-branch *is* rewriting history. It is what it was designed to do: create a new "history" by copying another one while changing parts of it.

What they seem to be wanting is something different, and not something which can be done with normal git tools: to do a partial clone, ignoring some parts of the history. Some thing like "clone me that tree except blobs abcdef1 and def2abc", and being able to checkout a commit which references these blobs even though they do not exist. This might need some deep changes in the git code; AFAIK it does assume that if it has a particular commit, it has all the trees and blobs referenced by it (but perhaps not the parent commits, due to shallow clones).

A clone made with that magic git would not have the bits for all the blobs they decided to ignore, while keeping the same commit, tree, blob, and even tag hashes (the trees would simply be referencing blobs which do not exist).

Of course, this does not work when downloading from a normal git server; the remote server will create (or reuse one it already has) a highly-compressed pack with all the history for the requested commits. But after that, they could unpack and clone from *that* with their magic git, and since both sides are now the same hacked git, it will omit the bits they are scared of.

The trouble with firmware

Posted Jan 6, 2011 23:05 UTC (Thu) by bronson (subscriber, #4806) [Link]

It sounds like the FSF would disagree with the "except blobs abcdef1 and def2abc" bit. The user is still "obligated to refer to that nonfree code" even if it's just by SHA1.

The trouble with firmware

Posted Jan 8, 2011 3:41 UTC (Sat) by gjmarter (guest, #5777) [Link]

It seems plausible to create a git that does not store certain blobs that it claims to have. What seems more difficult is to have a git which would alter the trees so that the offending filename is not listed. How would you do that and still be able to verify the integrity of the tree against the SHA1?

I think the filename in the tree is even a bigger concern than the blob references.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds