Please stop force-pushing commits to the master branch

[guixxx]

Describe the feature

Every day I look at the commit activity of this project, and every day the commits timestamp is very recent.

But that's just an illusion, because I noticed that most (if not all) of these commits are old, and just have their date modified to appear recent:

https://github.com/X11Libre/xserver/activity?ref=master&activity_type=force_push

Is there a valid reason for that? If there's not, can you please add a protection to the master branch to prevent force-pushes?

It should be implemented because

Rewriting git history on the master branch is a bad practice.

What are the alternatives?

No response

Additional context

No response

Extra fields

• I have checked the existing issues
• I have read the Contributing Guidelines
• I'd like to work on this issue

[callmetango]

Thank you for reporting this issue!

Would you mind to provide a little bit more details to why rewriting git history on the master branch is a bad practice? Not that I don't know, but it would be good if you could add some arguments.

[guixxx]

Would you mind to provide a little bit more details to why rewriting git history on the master branch is a bad practice?

Because when you do so, you're actively destroying history. Which not only doesn't make sense, because one of SCM's main purposes is to preserve history, but it's even worse when you're destroying other people's history, too.

Don't get me wrong, rewriting history is fine (and even encouraged) when you're doing it locally, on a separate branch you're working on and need to constantly clean up stuff, but once you merge it into your main branch and release it to the public, it's part of history now. And history, as we know it, is immutable (or, in this context, it should be).

The official git documentation says it better:

Note: Don’t push your work until you’re happy with it
One of the cardinal rules of Git is that, since so much work is local within your clone, you have a great deal of freedom to rewrite your history locally. However, once you push your work, it is a different story entirely, and you should consider pushed work as final unless you have good reason to change it. In short, you should avoid pushing your work until you’re happy with it and ready to share it with the rest of the world.

In my opinion, the only valid reason to force-push commits to your main branch, is when you mistakenly commit sensitive information that must not be out in the public, which I don't think it's the case here.

[rstms]

As I understand things, the master git history is designed to be the ultimate source of truth for a project. There are many reasons to defend the integrity of this record. Allowing any history modification opens the door to malicious changes being slipped into the the software and then hidden. Search for 'xz supply chain attack' for an example of how complex such shenanigans can become.
On the Linux Kernel Mailing List, there was a recently a bit of controversy (cleared up - no malice was intended) when a core dev made an error preparing a merge commit for a pull request which overwrote history. Linus considered it important enough to suspend write privileges to the dev until this was cleared up. There is some discussion of the importance of immutable git history in the ensuing thread. see that thread here

[shamefulCake1]

Looool. 🤦‍♂️

Force-pushing to master breaks most standard git workflows. Rebasing becomes very hard.

[kkofler]

Nonsense. All you need to do is to always pull with --rebase rather than with the default "merge" strategy, which is always a good idea anyway because it will avoid pointless merge commits when you push your changes. Then it will not matter at all that master was force-pushed, git pull --rebase will do the right thing on its own.

[ibakirov]

Good practice is to protect master/main branch from direct commits and only accept pull requests

[Dudemanguy]

I'm guilty of abusing force pushes sometimes for small projects no one cares about, but please don't do it for xlibre. I understand force pushing in emergency situations but those were not it as far as I can tell. I bring this up since master was forced pushed again since this issue was opened. You only create more work for yourself and contributors since all the PRs go out of sync with the master branch. Either you have to go manually rebase the branch yourself or the contributor has to do it (e.g. I just did a rebase for my PR just now).

I would highly suggest at least branch protection against force pushes on master to prevent this.

[powerboat9]

@metux

[magiruuvelvet]

Just adding my 2 cents. Everyone who has a clone of the repository checked out locally can't do a simple git pull after a force-push. git will tell you the branches are diverged and refuse to update your local worktree. This makes force-pushes immediately noticeable. Unless for extreme emergency cases like accidentally pushing credentials, this is suspicious behavior and causes trust issues.

[kkofler]

That is because the default behavior of git pull (defaulting to "merge") is broken. Always use git pull --rebase. That will also do the right thing if you have local changes, automatically rebasing them onto the current master instead of creating a merge commit.

[felipec]

Yeah, @kkofler is right. As I said I'm a git developer and most of us say you should never do git pull unless you know what you are doing, which most people don't. git pull is for maintainers, not for you to synchronize your local branch with upstream.

[waynesbrain]

My thoughts after seeing this issue:

Is this fork actually an agent-provocateur/black-propaganda honeypot? Let me subscribe so I can find out what the deal is.

So yeah, trust issues will be created from this.

[Dudemanguy]

@metux: Why do you keep force pushing and rewriting history? It just happened again.

[dec05eba]

Metux answered that here: X11Libre/xserver#394 (comment) but I dont get it

[guixxx]

His reasons don't make any sense to me either. Maybe he just couldn't express himself well.

He says he force pushes "in order to have a cleaner history", but I don't understand how the git history in master could get "dirty" in the first place? If that's happening, it's only him that could be doing it.

[metux]

Metux answered that here: #394 (comment) but I dont get it

Please have a look at the history how it is right now: master is a direct descendant (w/o any merges) of maint-25.0.
If anything gets added to maint-25.0 and master is rebased afterwards, then master automatically has everything from maint-25.0 - no chance of forgetting anything.

Later when we're doing another release from master, then looking at that one's history will show it's based (almost) directly on the 25.0.0.x bugfix release at the time the master release had been made. The few bugfixes we might have to do in 25.0.0.x after that then have to be cherry-pick'ed, but these (hopefully) will be rare.

Downside: we sometimes have to rebase some PR branches, as github's getting confused (since it's not recording the point-of-fork at push time, but always looking at what's currently the last common ancestor).

Alternative a)
always cherry-pick -- hard to tell what has landed where, and creating change lists (aka: what happened since last release) is complicated or imprecise (eg. will also show things that already are in bugfixes of previous release)

Alternative b)
merge from maint-25.0 to master -- making history even more complicated and has potential of merge conflicts (resolving conflicts within merge nodes is even much uglier)

Summing it all up, IMHO the current approach is the lesser evil here.

[callmetango]

@metux

Alternative b)
merge from maint-25.0 to master -- making history even more complicated and has potential of merge conflicts (resolving conflicts within merge nodes is even much uglier)

Could you please describe in more detail what you mean by “making the story even more complicated” And what do you mean by “resolving conflicts within merge nodes is even more difficult”?

[callmetango]

@metux ping
Could you please answer my questions above? I would like to consider your concerns while working on Create a Git branching and overall release strategy · Issue #281 · X11Libre/misc.

[metux]

the problem is
a) we're getting merge nodes across huge number of changes, thus history will be hard to understand
b) as master develops much more rapidly, there's great change that directly merging from maint back into master won't be possible w/o conflicts - and resolving merge conflicts within merge nodes makes the diff even much harder to read
c) with more release, we're going to have more than just one maint-* branch.

[callmetango]

Ok, thank you!

as master develops much more rapidly, there's great change that directly merging from maint back into master won't be possible w/o conflicts

Yes, pretty sure.

with more release, we're going to have more than just one maint-* branch.

Yes, also pretty sure.

[metux]

His reasons don't make any sense to me either. Maybe he just couldn't express himself well.

He says he force pushes "in order to have a cleaner history", but I don't understand how the git history in master could get "dirty" in the first place? If that's happening, it's only him that could be doing it.

please see my other reply - hope that's clearing it up a bit

[waynesbrain]

@Dudemanguy dang dude don't blame the guy for continuing to work just because y'all decided what the outcome should be. Maybe he's head-down obsessed with doing whatever he's doing and he doesn't want to change his ways just yet. Time will tell.

Maybe this project will go nowhere and we'll look forward to your own expertly managed fork.

At the very least, the behavior was explained and it's not really that suspicious for some developer to use or misuse a tool compared to whatever perceived normality exists. I'd bet that he views all of the issues that people are coming at him with suspicion as well because they're not "the core thing" and just trolls or minor distractions. Some people are better engineers than they are managers.

[callmetango]

I think, XLibre is a community project and it should be easy to contribute and to maintain as well.

Having a look at this example (out of many):

... shows me that the current way of doing things is not in harmony with our tools and I understand the frustration.

I'll take the issue and draft a Git workflow that is hopefully better including the current way and what's proposed. When doing so, I like to understand and will document the pro and contra.

[Dudemanguy]

dang dude don't blame the guy for continuing to work just because y'all decided what the outcome should be

The problem is that his workflow actively breaks everyone else's branches for no good reason. At the very least, I consider that rude and the fact that he definitely discounted what everyone said by force pushing again after replying in this thread more than warrants my response imo. And sure he dropped one comment explaining why in the thread but to anyone else not aware, the huge history of force pushes in this repository would be concerning.

[felipec]

I'm actual git developer, who started using in 2005, so I know how it's meant to be used and I have to say there's a lot of misinformation in this thread.

@Dudemanguy said:

I think it's completely absurd to break every contributor's branches constantly just because you don't want to do proper backports of fixes. I can't speak for everyone but I know I was pretty irked that I had to rebase my branch for no reason other than an arbitrary force push.

Nobody forced you to rebase.

Do you know you can request a pull from a base that is not the tip of the master branch?

That's the whole reason git is a distributed version control system: so changes in one repository don't affect your personal repository.

And on the flipside, the gain is what? So you don't have to manually track commits to backport fixes? But I'm not even sure any work is being saved in this scheme because you just artificially create a bunch of work for all contributors with open PRs instead.

Wrong. There's no extra work for the contributors, because they are not forced to rebase.

And the flipside is actually very big. I spent several days trying to figure out which commits from Xorg's master branch were not in the stable branch, all because they are following the model you suggest.

I'm not going to claim @metux current model is necessarily better, but as I maintainer I 100% understand why it makes things easier for him.

On the other hand take a look at Xorg's "standard" model, they have not made a release in 4 years, precisely because their master branch is not clean, and therefore not easy make a release out of it.

But if that was the case, why put this up on github with open issues and open PRs in the first place?

If GitHub users don't know how to properly use git, I say screw them and only accept patches through the mailing list.

People who know how to send patches through email generally know how to use git.

Breaking a high quality patch just because you don't want to backport properly is something a maintainer should never do.

This shows beyond a shadow of a doubt you don't understand how git works.

Rebasing does not change the code tree, so why would that break your patch?

But the ask is not really a big one.

It's not big, it's just stupid.

Nobody else, as far as I know, develops in this fashion.

Have you heard of Linus Torvalds, the creator of git? He explicitly tells people to not to base their patches on his master branch, precisely because it's constantly changing.

So no, I think this is just a git skill issue.

---

If people who don't understand how git works are going to complain about a moving master branch, then I suggest to call it next, make the master branch point to 25.0.0 and don't move it until the next minor release.

This will force contributors to avoid the moving branch for their patches and maintainers to do minor releases more often to avoid fixing merge conflicts.

[callmetango]

@felipec

I suggest to call it next, make the master branch point to 25.0.0 and don't move it until the next minor release.

This will force contributors to avoid the moving branch for their patches and maintainers to do minor releases more often to avoid fixing merge conflicts.

Could you describe that in more detail, please?

[felipec]

I don't know what else I should describe.

If contributors have trouble understanding that they don't have to rebase their branches on top of the latest "master", then don't call that branch "master", so they don't wrongly feel they have to do that.

I think that was clear from what I said.

[callmetango]

I'm locking this conversation due to being too heated until 2025-07-21 12:00 UTC.

I wish you all a nice weekend and maybe there will be a chance to relax a little and put your minds at rest. Enjoy and see you Monday.

@felipec I am anything but happy with your tone and will contact you by e-mail.

[callmetango]

Quoting X11Libre/xserver#394 (comment):

We should also avoid having merge nodes, instead we should rebase.

@metux force pushing fucked shit up again. I dont want to contribute more changes after this until @metux stops force pushing things.

okay, I can stop doing so, but then somebody really needs to take care of tracking and backporting changes into maint branches.

[callmetango]

Quoting X11Libre/xserver#394 (comment):

@cepelinas9000

my suggestion maybe @callmetango can step in as 'accountant' and somebody doing packages maintenance for example @stefan11111 , @artist4xlibre, @b-aaz call'ing PR's for backporting

Yes, if this helps our contributors and ourselves then I'm willing to take this kind of task but have to know the details. As promised in #242 I will work on a draft for a solution. Probably today once #148 is done. Which almost is.

[callmetango]

In the next step this will be moved to X11Libre General · Discussions · GitHub and and any remaining concerns will be asked about.

[metux]

I believe this issue is closed, because I've already agreed not to rebase master branch anymore for quite some time now.

[roryyamm]

I'm fairly certain the problem force-pushing had was that it forced people to always rebase whenever something was force-pushed.

[callmetango]

Doing a rebase once in a while might be a good idea.

As far as I understand it rebase always rewrites history. And this is not a good thing because one looses all the old references and trust as well. Quoting the Git manual as done above:

However, once you push your work, it is a different story entirely, and you should consider pushed work as final unless you have good reason to change it.

[felipec]

@roryyamm force-pushing does not force people to always rebase. I already explained that.

@callmetango that is not true either. Git allows you to rewrite history as much as you want. The dogma of not rewriting history comes from Mercurial, and it's one of the reasons people abandoned that VCS.

History is always being rewritten no matter what, and there's nothing wrong with that.

[callmetango]

Okay, maybe I wasn't precise enough: AFAIK the hashes of the Git commits stay always the same on a publicly avialable branch such as master as long as one does not rebase. That's what I was referring to.

@felipec What do you mean with:

History is always being rewritten no matter what

[Dudemanguy]

If the branch that normally gets merged to (master for most projects) gets forced pushed, then anybody with an open PR against that branch will no longer have their branches be cleanly mergeable if commit hashes that were within their branch change (what was happening early). There's no avoiding that. You can either rebase, cherry-pick, etc. but something has to be done beyond simply hitting merge. That's the issue.

[felipec]

@callmetango on my machine I always do git rebase, so do many people (especially experienced git users), therefore the history is always being rewritten no matter what policy you choose to apply in your project.

@Dudemanguy that is not true, there's absolutely nothing that prevents a maintainer from merging such a branch.

However, ideally people should base their development on the latest tag (e.g. 25.0.0.6) not the master branch.

That's why I suggested to rename master to next so people unfamiliar with this process don't get confused and send pull requests based on that.

[Dudemanguy]

he is already doing it.

Except he wasn't. He commented on several PRs asking people to rebase.

Didn't I just say linux-next does that?

But not linux. There's a difference.

Also Linus Torvalds doesn't accept pull requests based on his master branch for a reason.

And that reason is not because Linus force pushes the master branch and changes git hashes.

[felipec]

@guixxx wrote:

Cool story, but I think I prefer to believe what's literally in front of my eyes, thanks.

Your eyes are perfectly capable of seeing hallucinations. Which mythical "linux" repository are your eyes seeing?

Are you usually this passionate about irrelevant stuff?

Facts are dispassionate. Just because the facts contradict your beliefs, that does not make them any less factual.

So you're a fortune teller, too?

He literally said "for quite some time now". How does that not mean "for now"?

@Dudemanguy wrote:

Except he wasn't. He commented on several PRs asking people to rebase.

Some ≠ all. This is a black swan fallacy. I'm saying there are some black swans, and you are saying there can't be black swans because you saw some white swans. Sound logic.

But not linux. There's a difference.

There is no "linux" repository.

And that reason is not because Linus force pushes the master branch and changes git hashes.

What is the reason? Hint: I already explained it.

---

As I already explained, I'm a git developer, and I'm telling you how git is supposed to work.

If you don't want to learn git and instead keep repeating the same mistakes everyone who doesn't understand git does, then go ahead.

You will end up exactly in the same situation as Xorg, and having commits on the master branch that don't get released for years.

If you want to differentiate from Xorg, doing exactly the same thing the do is not the way to go.

[Dudemanguy]

I'm not sure what twisted logic you are using to not count torvalds's mainline kernel tree as the linux repository but I don't really care. This entire discussion is a waste of time. Xorg's problem of not having releases has nothing to do with the way they use git so that's just another fallacy. Metux already relented, so really can we just close this discussion.

How linux uses git is not appropriate for 99% of projects because almost nobody has that giant sense of scale. But again, linux doesn't force push the master branch of the mainline kernel or the stable trees. And for good reason.

[callmetango]

Yes, I think it would be ok to agree to disagree.

[felipec]

@Dudemanguy wrote:

I'm not sure what twisted logic you are using to not count torvalds's mainline kernel tree as the linux repository

There is no "the linux repository". The whole point of git is that it's a distributed version control system, and as such there is no canonical central repository.

You have not watched Linus Torvalds' talk on git, have you? Linus Torvalds & git.

no single place is more important than any other single place -- Linus Torvalds

In that talk he explicitly says his linux repository is not special. He is literally saying it should not be considered "the repository". But if I repeat what the creator of git explained literally, you say it's "twisted logic".

There's a reason he called his personal repository "torvalds/linux", and not "linux".

This entire discussion is a waste of time.

It's a waste of time because you have zero interest in learning how git is supposed to work, even from the words of Linus Torvalds himself.

How linux uses git is not appropriate for 99% of projects

You don't get it.

The point is not to use git like the Linux project does, the point is that the Linux project understands how git is supposed to be used, and you are unwilling to learn.

@callmetango wrote:

Yes, I think it would be ok to agree to disagree.

Yeah, except you are disagreeing with a git developer that has been using git for 20 years, and Linus Torvalds' own literal statements.

[callmetango]

@felipec

However, ideally people should base their development on the latest tag (e.g. 25.0.0.6) not the master branch.

That's why I suggested to rename master to next so people unfamiliar with this process don't get confused and send pull requests based on that.

I think I'm slowly getting where you're trying to go with this but I'm not involved in Linux kernel development so maybe lacking some context.

My questions:

• Where would the latest tag (e.g. 25.0.0.6) live on?
• Who would integrate the commits from the something with to latest tag (e.g. 25.0.0.6) into next?
• How would this integration be done?

[callmetango]

Both branches would point to the same commit.

Branches in git are nothing more than pointers.

Yes, I remember and I did some research. Having a branch "point" to another one seems okay-ish, but to switch from let's say release/25.0 to release/25.1 would mean a rebase and so forced push, no?

[felipec]

Yes, I remember and I did some research. Having a branch "point" to another one seems okay-ish,

No, one branch would not point to another branch. Both branches would point to a commit, because that's all branches ever do.

It would just so happen that it will be the same commit.

but to switch from let's say release/25.0 to release/25.1 would mean a rebase and so forced push, no?

No. The next branch would be rebased regularly, which would mean forced pushes, yes.

But that would mean release/25.1 would be directly on top of release/25.0 (direct descendant), because release/25.1 is going to point to the same commit as next when 25.1 is released.

That means master would fast-forward from release/25.0 to release/25.1 and therefore no forced push would be necessary.

It would look something like this:

e4f5g6a (next, tag: v25.1.0, release/25.1) Release 25.1
d3c4b5f Merge pr/2
c2b3a4d Merge pr/1
b1a2c3d Fix
a0b1d2c (HEAD -> master, tag: v25.0.8, release/25.0) Release 25.0.8

[callmetango]

At the moment the major version is 25.0, not 25. Don't ask me why, AFAIK it was a mistake. But I - well, not only me - would really like to switch to Semantic Versioning and I will create an RFC for doing so.

That is the RFC to Switch to semantic versioning and make the next release a 25.1.0 · X11Libre · Discussion #299.

[felipec]

@callmetango I don't think this is the way to go, and it will create problems when Xorg releases version 26, or 27, and their drivers start using their ABI requirements.

[callmetango]

@felipec Could you explain that a little more, please? Best in the discussion Switch to semantic versioning and make the next release a 25.1.0 · X11Libre · Discussion #299.

[guixxx]

I'd suggest everyone to stop engaging with whatever lunacy Felipe Contreras says, because he's clearly a certified troll.

I'll just quote Linus Torvalds' literal words about rewriting public git history, back in 2009:

People can (and probably should) rebase their private trees (their own work). That's a cleanup. But never other peoples code. That's a "destroy history"

So the history part is fairly easy. There's only one major rule, and one minor clarification:

• You must never EVER destroy other peoples history. You must not rebase commits other people did.
  [...]
• Minor clarification to the rule: once you've published your history in some public site, other people may be using it, and so now it's clearly not your private history any more.

He then explains it further:

So "git rebase" is not wrong. But it's right only if it's YOUR VERY OWN PRIVATE git tree.

That's fairly straightforward, no?

Clearly not that straightforward to some people, Linus.

[felipe19930]

Following your logic, @metux should keep the master branch in his private git tree and never update the master branch in the GitHub repository until he makes a release.

LOL. Get a load of this guy... 🤦‍♂️

You really need to work on your reading comprehension, dude.

When Torvalds said "your very own private git tree" he was obviously referring to your local repository. Because the opposite of a "private tree" is literally a "public tree", i.e. it can be seen and used by everyone else, and not just you.

[felipec]

When Torvalds said "your very own private git tree" he was obviously referring to your local repository.

That's literally what I said.

It seems you are the one with comprehension issues.

[callmetango]

I would like to politely ask you to tone down a little. We all have different opinions, and I am very glad that we can discuss them. However, the personal tone could be improved. Specifically, I suggest rethinking sentences that begin with “You...” and perhaps starting them with “I...” instead. That could make everything sound a little nicer and focus more on the arguments. Please remember:

Anybody who's treating others nicely is welcomed.

[powerboat9]

The equivalent of a GitHub pull request with one commit in the linux world is a patch sent by email, ...

No, a pull request references a commit object, which can reference parent commits

[felipec]

@powerboat9 that has nothing to do with what I said.

[b-aaz]

This thread made me hate git even more :) .

[callmetango]

git - the stupid content tracker

😆 Source: git(1): stupid content tracker - Linux man page

But it is not that bad after all and the tool at hand. I am quite confident that we will be able to come up with a reasonably acceptable and more or less easy-to-use branching and release strategy.

[callmetango]

As stated in https://github.com/orgs/X11Libre/discussions/243#discussioncomment-13882031 I'm taking the task and will work on Create a Git branching and overall release strategy · Issue #281 · X11Libre/misc in it's associated discussion Create a Git branching and overall release strategy · X11Libre · Discussion #282.

This discussion will be kept open until the open questions above have been answered.