Hi Hazen and Alan
Did you see the email I sent last night saying you can tag a branch head, then
if the branch is deleted the tag remains?
This makes it trivial to delete branches but make sure they can be restored
providing nobody deletes the tag - and even if they did you could probably
search the log to find where and when and find the sha of the tag, especially
if we start all tags with "deletedBranch" or something.
one view might be that this just clutters our tag space instead of branch
space, but putting a file of shas in the project just clutters our file space.
To me it is all equivalent in one sense, but I do se that there is a niceness
associated with having clean branch space.
Phil
________________________________
From: Hazen Babcock <hbabc...@mac.com>
To: Alan W. Irwin <ir...@beluga.phys.uvic.ca>
Cc: Plplot-devel mailing list <plplot-devel@lists.sourceforge.net>
Sent: Sunday, 17 August 2014, 12:56
Subject: Re: [Plplot-devel] Fwd: Re: [Plplot-core] git conversion status
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"."
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? 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. 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? This would also get things
ready our conversion to the next great thing in version control system
in 5-10 years :).
-Hazen
------------------------------------------------------------------------------
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
------------------------------------------------------------------------------
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
