Re: Cloning errors - SOLVED

Ethan A Merritt <[email protected]> writes:

> On Saturday, 27 June 2020 11:55:25 PDT Dima Kogan wrote:
>
>> From git's point of view this new master branch would be a fork that has
>> branched off at the time of the date fix: in 2006.
>
> What state would that leave the 5.2 and 5.4 stable branches in,
> that split off after 2006?  Do they see the same fix?
> Does the branch structure even survive?

Each git commit has a hash (a long hex sequence) that is used to
uniquely refer to it. A branch or a tag is just a convenient alias to a
specific hash.

If we go back to fix the date, then that commit gets a new hash AND ALL
DOWNSTREAM COMMITS get a new hash too. I.e. we made a fork. The original
hashes that we had before the fix are still there: the filter-branch
command creates a new sequence of commits, without deleting the old
ones.

What we do with that new sequences of commits is up to us. Since
branches are aliases to existing hashes, by creating a new sequence of
commits with a fixed date we haven't actually changed anything about
existing branches or tags. Each branch or tag we want to fix would need
to be fixed with filter-branch and then force-pushed to the server
(because this wouldn't be the usual append-only push). Probably the best
bet would be to leave all the old tags and branches alone, and to only
fix the under-development master branch. But that's a choice we make.


> Yeah, I don't think this particular glitch warrants a fork. I don't
> really see why a date typo is any worse than any other typo in the
> commit message - the structure and sequence of the commit chain is not
> affected.

I think I agree. It doesn't sound like many people are experiencing this
failure.


_______________________________________________
gnuplot-beta mailing list
[email protected]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta