lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: duplicate commits in git (was: 2.13.18 might not contain everything


From: Francisco Vila
Subject: Re: duplicate commits in git (was: 2.13.18 might not contain everything)
Date: Sat, 17 Apr 2010 18:01:30 +0200

2010/4/17 Graham Percival <address@hidden>:
> On Sat, Apr 17, 2010 at 03:18:24PM +0200, Francisco Vila wrote:
>> > I'm not concerned about the release (any missing bugfixes will be
>> > in .19 anyway), but does this matter for the commit history?
>>
>> Not too much. Just a bit of noise.
>
> Is that noise important?  I know that you don't think it's a
> problem, but what about Jan, Patrick, and all the people who spent
> ages working on fixing the ancient (pre-2000) git history?

Great work they did, which I've not ruined completely, just added 5 or
6 repeated commits which git handles well enough not to be concerned.
BTW I also spent time testing.

> I
> mean, if they care about stuff that old, wouldn't they care about
> 2010?

History is not perfect after 2000, either. I like to keep the lovely
4f4a65910 and fec91b4e613 as examples of how all of us commit slight
mistakes from time to time. Many developers (which I'll not name) NOT
suspicious of being git lamers have committed 6 or 7 contiguous merge
commits and we are still alive.  Some have their system clocks months
out of sync. 9f3572d98b (git/start) still goes four months backwards
in time.

Native Git history is good with all its mistakes. Earlier history was
non-git and contained absurdities as to cumulate all file-deleting
commits at the end. THAT was a mess.

> Won't these extra commits mess up the gitstats and the like?

'Mess' is exactly the word if you can not live with a given author
being the third-but-best author of the month, instead of the fourth.
We have 18 thousand commits, for the mao's sake. gitstats are rather
simple stats, I think; naive about timezones, etc. I'm not to say that
nobody cared about stats before I made them, but I am tempted about
thinking it.

>From a certain POV, mistakes in git history mean there is any activity
at all, this is absolutely good for a project. As for the consequences
of those mistakes, git is handling them well.

>> >  I
>> > mean, we had a week of git not-really-working while Jan made
>> > multiple different versions of the repository; would something
>> > like that be required in the future?
>>
>> Something like what exactly? Our latest repo works fine for me and my
>> habits have not changed.
>
> We had a week without doc work due to constantly-changing
> repositories.  If you weren't active during that week, then you
> wouldn't have noticed it.

I can not agree; everyone had to start a fresh repo, having been active or not.

>> > Or does it only affect lilypond/translation, which we don't look
>> > at the stats for?
>>
>> In the long term, stats for all branches are identical as long as they
>> got merged periodically.
>
> Then it sounds like we have a problem.

You are too much concerned about stats these days, IMO. Judge by
yourself, http://paconet.org/lilypond-statistics/ [updated]

> Does any git experts know how to remove duplicate commits from the
> history?

5 or 6 repeated commits are the *least* of my concerns.

-- 
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com




reply via email to

[Prev in Thread] Current Thread [Next in Thread]