git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] Documentation/git-bundle.txt: Dumping contents of any bundle

From
jidanni@jidanni.org <jidanni@jidanni.org>
Date
Jan 2, 2009, 22:03 UTC
Message-ID
<87mye9wekg.fsf@jidanni.org>
In-Reply-To
<20090102082709.GA3498@coredump.intra.peff.net>
Some options are:
1) just add a line or two to my man page patch showing
what recovery can and can't presently be done. (No need for my
temporary file, use a pipe too.)
2) Also implement that step where everything is uncompressed and put
into lost+found, and document that they should expect to just see a
lot of connector markings, and if there are useful strings in there
then they are just lucky. We did the job asked: recovered to the best
extent of what they gave us.

JK> So I am inclined to leave it as-is: a patch in the list archive. If and JK> when the day comes when somebody loses some super-important data and JK> somehow matches all of these criteria, then they can consult whatever JK> aged and senile git gurus still exist to pull the patch out and see if JK> anything can be recovered.

I've read too many cases in RISKS Digest, news:comp.risks, about years later organizations trying to recover some weird format or media. Therefore I urge you to strike while the iron is hot and hook up the function into the code.

Maybe some have never tried to recover data, but for those that one day might, they will be thanking you over and over for taking this opportunity to give them a chance. In many cases the few shreds they can recover might be all they need.

Also one can see the innards of git -- no more black box.

If I were creating a new binary format, I would be sure to also provide decoder tools. Otherwise it is just like it requires its own proprietary environment to reveal any of its innards. Sure, you can say well that data is mainly useless... but it is better than nothing -- we did the best with what they gave us.

Previous: Jeff KingNext: jidanni@jidanni.org
Message 16 of 32 in “How to extract files out of a "git bundle", no matter what?”
  1. jidanni@jidanni.orgDec 19, 2008
  2. Shawn O. PearceDec 19, 2008
  3. Mark LevedahlDec 19, 2008
  4. jidanni@jidanni.orgDec 19, 2008
  5. Jeff KingDec 19, 2008
  6. jidanni@jidanni.orgDec 19, 2008
  7. Jeff KingDec 19, 2008
  8. Documentation/git-bundle.txt: Dumping contents of any bundlejidanni@jidanni.org, Jan 1, 2009
  9. Johannes SchindelinJan 1, 2009
  10. Jeff KingJan 1, 2009
  11. jidanni@jidanni.orgJan 1, 2009
  12. Jeff KingJan 1, 2009
  13. jidanni@jidanni.orgJan 2, 2009
  14. Shawn O. PearceJan 2, 2009
  15. Jeff KingJan 2, 2009
  16. jidanni@jidanni.orgJan 2, 2009
  17. git ls-tree prints wacko file sizes if it can't find the blobjidanni@jidanni.org, Jan 1, 2009
  18. jidanni@jidanni.orgJan 1, 2009
  19. Handle sha1_object_info failures in ls-tree -lAlex Riesen, Jan 1, 2009
  20. git-bundle(1): add no references required simplest casejidanni@jidanni.org, Jan 26, 2009
  21. Junio C HamanoJan 26, 2009
  22. git-bundle(1): add no references required simplest casejidanni@jidanni.org, Jan 29, 2009
  23. jidanni@jidanni.orgFeb 1, 2009
  24. Johannes SchindelinFeb 2, 2009
  25. Junio C HamanoFeb 2, 2009
  26. jidanni@jidanni.orgFeb 4, 2009
  27. Junio C HamanoFeb 4, 2009
  28. jidanni@jidanni.orgFeb 4, 2009
  29. git-bundle doc: update examplesNanako Shiraishi, Feb 4, 2009
  30. Jeff KingFeb 4, 2009
  31. Junio C HamanoFeb 4, 2009
  32. Junio C HamanoDec 19, 2008

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.