Re: Cloning errors - SOLVED

Ethan A Merritt <[email protected]>
Newsgroups gmane.comp.graphics.gnuplot.devel
Organization University of Washington
Message-ID <3642472.QPiRCz3cr3@stonelion>
On Saturday, 27 June 2020 11:55:25 PDT Dima Kogan wrote:
> Ethan A Merritt <[email protected]> writes:
> 
> >> It isn't particularly difficult to fix this for the master branch,
> >> but since this would be a history rewrite, the resulting tree would
> >> be a fork, effectively. There aren't a ton of people committing to
> >> this repo, so fixing it wouldn't be too disruptive. Strong feelings
> >> either way?
> >
> > Really? It's fixable? I thought you guys all told me it was basically
> > impossible to edit a commit log entry deep in the tree.
> 
> /I/ never told you anything about it :)
> 
> Commits are immutable. A fix would be to edit the offending commits to
> create new commits with a more reasonable date. Then everything in the
> future from those rewritten commits would be replayed to create a new
> master branch that doesn't have the tainted history.
> 
> 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?

> > What's the recipe for doing so?
> 
> "git filter-branch"

Thanks. I will read up on it.
 
> > 
> > FWIW there is at least one other date error in the history. But really
> > there are many places I'd go back to correct typos if it were
> > possible. I think git would be much improved by keeping the commit
> > messages in such a way that they could be edited later without
> > disruption.
> 
> You can go back and change whatever you like, but each time you do that,
> you're making a new fork. In my view it could be justified to fix a
> failure (like the one that started this thread), but not for anything
> else. Even in this case, it's not obviously justified: you need an old
> git and/or i686 AND the failure only shows up if you "git fsck"

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. 

> This is relatively straightforward. I can make a fixed master branch, if
> you'd like to look at it.

I'd rather learn about the process and experiment on my own.
I'm not sure that looking at the result of someone else's fix teaches
me everything needed.

	thanks,
		Ethan





_______________________________________________
gnuplot-beta mailing list
[email protected]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.