On 2014-08-17 07:56-0400 Hazen Babcock wrote: > On 8/17/2014 2:41 AM, Alan W. Irwin wrote: >> On 2014-08-16 22:37-0400 Hazen Babcock wrote: >>> >>> "git reflog doesn't traverse HEAD's ancestry at all. The reflog is an >>> ordered list of the commits that HEAD has pointed to: it's undo >>> history for your repo. The reflog isn't part of the repo itself (it's >>> stored separately to the commits themselves) and isn't included in >>> pushes, fetches or clones; it's purely local." >> >> Thanks for looking further at reflog, but local doesn't sound like what >> I want >> since that would be a single point of failure (e.g., if I am keeping >> this information on my local disk repo, that disk could fail), and >> nobody could access that information other than me. > > Now I'm confused, I thought you were against deleting branches in the SF repo > because you were worried that some variant of the git reflog command would > cause them to disappear forever from any and all records in the SF repo? I > was responding specifically to your statement: > > "That method does not seem fool-proof. See the expire subcommand for "git > reflog"."
My understanding (which might have been wrong) when you first wrote about this and referred to the relevant stackoverflow discussion) is reflog contains (along with a lot of other information) SHA id's corresponding to branch heads and therefore could be used to resurrect deleted branches. But that is no good if reflog is expired (e.g., the default 90-day expiration that is used to keep all that information managable). Because that expiration would essential remove the needed SHA id information from the reflog. But regardless of whether I was confused or not on that subject, the local nature of the reflog makes this idea not practicable for the reasons I have mentioned so I prefer storing those essential SHA id's for deleted branch heads in a file instead. > > If you agree that git reflog is local then perhaps you could what other > sequence of commands might lead to such a permanent loss of history? Or maybe > you meant that once the branch is gone you might not be able to figure out > from the log which SHA corresponded to the head of that particular branch? Exactly the latter. > I > agree that this could be difficult. Anyway I'm Ok with your proposed > solution, see below. > >> Remember, my basic motivation is to allow access to our history by >> anybody that is interested in the future. Therefore, I far prefer to >> store the information in a file in the repo since that file is >> available to everyone, automatically backed up by everyone cloning it, >> and even in the unlikely event someone deletes that file in error you >> can still restore it from finding the parent of the associated commit >> in the log that deleted that file. (For git newbies here, see >> <http://stackoverflow.com/questions/953481/restore-a-deleted-file-in-a-git-repo>.) >> >> >> To make this file proposal concrete, I am suggesting storing the file >> in PLplot_repo_information/README_svn2git_conversion (a directory and >> name that are unlikely to be deleted by accident by anyone) that >> states the commands we used to do the conversion and test it (the >> contents of the AWIREADME file I sent you plus additional >> documentation of the subversion branches that were converted to git >> and then deleted with explicit instructions on how to resurrect each >> one of them). I think we should also store in that directory the 4 >> files we used for the conversion, i.e., the two files used with >> svn-all-fast-export, the convert tags bash script that was sourced, >> and my standalone bash script to test the results in that directory. >> Do you see git (or any other) issues with these ideas? > > This is fine with me. Good. > Perhaps the directory should be called something like > "historical" and "vcs_conversions", and you could include what was done for > the CVS to SVN conversion as well? Good ideas. I don't remember any of the CVS to SVN conversion except the pain, but I could go through the e-mail list conversations at the time to resurrect a description of what was done. > This would also get things ready our > conversion to the next great thing in version control system in 5-10 years > :). You are a cruel guy even to bring up that possibility, but I forgive you! :-) Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------------ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
