github VS Git

While looking for solutions, I realized that many developers face similar challenges. This issue is widely discussed, particularly in a GitHub thread: Track traffic to GitHub repo longer than 14 days #399.

Probably the older email address is still the primary one for the GitHub account.

GitHub took it upon themselves to change email addresses and author names when merging via the UI buttons like "Squash and Merge" in 2018 and then again in 2019. See <https://github.com/isaacs/github/issues/1368> for the tedious details.

Essentially the post-2019 behaviour seems to be that where possible with "Squash and Merge" they will set noreply@github as the committer so that they can sign the merged commit themselves, and set author name & email to what they have recorded for the GH account involved (and the signature is then a record that GH have verified that account's involvement).

Personally I think it is shocking that they ignore the name and email address that the actual author of the commit has selected. This is both a violation of the author's intentions -- for example, you may set work and personal email addresses in different repositories as discussed here, but GitHub will rewrite them all to the same thing when other people press "Squash and Merge" on your pull requests -- and potentially a doxxing security risk.

I have considered re-reporting this to GitHub via the newer community discussions or via support again, but given the extent to which they've ignored all such reports over the last five years it is hard to find the motivation to do so.

However, there is a massive issue. Github by default truncates insights to t-14 days (where t = today). This is super annoying as there is a discontinuity in data. There is also an archived issue on Github regarding this. The issue has a whopping 119 comments and has been around for over 8 years now. Basically, from the discussions there - Data you don't persist today will be gone 14 days from now. And looks like Github hasn't done anything about it.

> Hi, people have made money using my code and I also don’t care

looks like everyone's missing the point.

> I understand this is upsetting to you

Again, maybe I am on another level of comprehension, so I don't understanda why it is so hard for someone to get it, but I am not upset by that, at all.

I simply know that those who think "it will be fine" are delusional and don't know what they are talking about!

So I just will paste some link to relevant news here, maybe it will make things clearer.

It includes the opinion of Antirez, father of one of the most successful OSS ever: Redis. Maybe his words will open your eyes and tear the veil of Maya.

(spoiler ahead alert!)

Basically you work for free and people don't even thank you and the maintainer ends up being doxed or blamed or pushed aside and in the long term the only solution to keep sanity is to resign

https://www.jeffgeerling.com/blog/2022/burden-open-source-ma...

https://www.theregister.com/2022/01/13/opensource_apacheplc4...

https://nolanlawson.com/2017/03/05/what-it-feels-like-to-be-...

https://old.reddit.com/r/linux/comments/z14tt2/reason_why_op...

https://github.com/isaacs/github/issues/167

http://web.archive.org/web/20221217180915/http://antirez.com...

I don't know what the fuss is all about. It was publicly known that Github was breaking automatic git archives consistency for many years. Here is a bug on a project to stop relying on fake github archives (as opposed to stable git-archive(1)):

https://bugzilla.tianocore.org/show_bug.cgi?id=3099

At some point it was impossible to go a few weeks (or even days) without a github archive change (depending on which part of the "CDN" you hit), I guess they must have stabilized it at some point. Here is an old issue before GitHub had a community issue tracker:

https://github.com/isaacs/github/issues/1483

Hello, I see you stepped on my favourite personal soapbox! :)

https://github.com/isaacs/github/issues/1017

I really, really like semi-linear branching/merging. I.e. always rebase-merging, but with a merge commit.

Reasons, in comparison to Github's "rebase merge" which doesn't produce a merge commit:

1. It makes it clear which commits were part of one PR

2. It makes it clear who did the merge

3. It's okay to not have every commit build. but the one being merged will.

4. Still pretty bisectable. You'll narrow things down at least to the PR that caused an issue, and from there it's usually quite simple.

5. Looks very tidy in gitk & Co

Not to say that the feature isn't coming to FOSS git services.. Just that even proprietary organizations have had issues with taking a while to implement them.

Oh this is cool actually! Nice! One of the grievances I have with github commit signing is this issue https://github.com/isaacs/github/issues/1099

In addition, you probably want to read this discussion. https://github.com/isaacs/github/issues/1138

Look at any PR/patch series that got merged into the Git project. https://github.com/git/git/

Any random one. Because those that did not meet the minimum criteria for a well-crafted history would not have passed review.

Boy, I can't find this either (but also, the kernel mailing list is _really_ difficult to search). I really remember Linus saying something like "it's not a real SCM, but maybe someone could build one on top of it someday" or something like that, but I cannot figure out how to find that.

You _can_ see, though, that in his first README, he refers to what he's building as not a "real SCM":

https://github.com/git/git/commit/e83c5163316f89bfbde7d9ab23...

Here is the direct link, as HN somehow removes the query string: https://github.com/git/git/commits?author=peff&since=2023-10...

I understand all that.

I'm saying, if you write a survey and one of the possible answers is "diff", but you don't clearly define what you mean by "diff", then don't be surprised if respondents use any reasonable definition that makes sense to them. Ask an ambiguous question, get a mishmash of answers.

The thing that Git uses for packfiles is called a "delta" by Git, but it's also reasonable to call it a "diff". After all, Git's delta algorithm is "greatly inspired by parts of LibXDiff from Davide Libenzi"[1]. Not LibXDelta but LibXDiff.

Yes, how Git stores blobs (using deltas) is orthogonal to how Git uses blobs. But while that orthogonality is useful for reasoning about Git, it's not wrong to think of a commit as the totality of what Git does, including that optimization. (Some people, when learning Git, stumble over the way it's described as storing full copies, think it's wasteful. For them to wrap their heads around Git, they have to understand that the optimization exists. Which makes sense because Git probably wouldn't be practical if it lacked that optimization.)

The reason I'm bringing all this up is, if you're trying to explain Git, which is what the original article is about, then it's very important to keep in mind that someone who is learning Git needs to know what you mean when you say "diff". Most people who already know Git would tend to gravitate toward the definition of "diff" that you're assuming (the thing that Git computes on the fly and never stores), but people who already know Git aren't the target audience when you're teaching Git.

---

[1] https://github.com/git/git/blob/master/diff-delta.c