53

I don't know why it gives you that, just force push ...

Comments
  • 2
    I once did a force push and fucked up the whole repository. Luckily I had a copy and it was my private repo so noone was hurt. Never again. Never.
  • 0
    lol I love force pushing a rebase. I hate merge commits.

    Everyone else in the shop won't get near force push.

    Just gotta communicate and be careful.
  • 0
    Honestly sometimes when Im working on a personal repo between 2 of my computers and I know both are up to date but git is giving me shit, I'll just git push -f. I know it's bad practice and I wouldn't do it in production, but git pull says "up to date", so does status, and then push is like nah you need to get them changes first. WHICH IS IT GIT?
  • 1
    @hughmunguswot That must be hilarious. "Don't commit anything, I'm making a force push". This should be posted in wk66 tag xD
  • 0
    I have heard this one so many times. I am seriously going to throw my keyboard at the next person who says so.
  • 0
    @beriba we all branch off of a protected integration branch. We rarely do shared branching. We are a team of four. I'm talking rebasing locally on top of the integration branch to be conflict free for the pull request. If it were a shared branch, all you have to do is make sure you are up to date before force pushing and also make sure someone isn't pushing at the same time. If you can avoid that, it's pretty painless. Just git pull --rebase. I'm all about minimizing micro merge commits, and keeping a clean history that's all. I will admit though, minimize not eliminate...because be realistic, it's risky and a hassle in shared branching with poor communication.
  • 0
    @hughmunguswot Let's be honest, merge commits aren't doing any harm to anyone so why do you even think about minimizing the number of them? That's a micro optimization which optimizes nothing. In my whole life I haven't seen a single dev that care about overall number of commits in the project. Merging is the right way to go. Force push is very bad habit and can mess up the whole repo. And it can happen by accident in the worst possible moment. Murphy law. It doesn't matter how big/small is your team or whether you communicate or not. Force push is not a replacement for merge. Please consider not using it just to get rid of that habit.

    PS. If you want to sync with the repo before pushing your changes, always use
    git pull --rebase
  • 0
    @beriba well, for the most part I agree. We merge our branches into integration and then we merge integration into master. I'm talking about local branch, updating from origin while branched. As for why I even care about micro merge commits, it started with a peer who had a number of commits and often back to back "merge origin into branch" commits well over 50% of the substance of the pull request. So we tried coaching then squashing his prs... He kept trying to stay branched after squashing... I digress.
  • 0
    @hughmunguswot So look, you created the whole mechanism to get rid of the mess that someone created with the wrong behavior. But this way you also created wrong behavior so in some way you're doing the same thing.

    Be better, encourage good practices. Give a try to git pull --rebase. It'll solve your problem without using force push
  • 0
    @beriba I think you misunderstood what I said.

    I thought I was verbose enough. Apparently not.

    I literally said that I use git pull --rebase.

    Is there even a point in typing out a thoughtful reply here? Apparently not.

    I don't have bad git habits, I'm literally on the same page as you.
  • 0
    @hughmunguswot Sorry if I misunderstood you. I didn't mean to be rude or something. I was trying to convince you that force push is a bad habit. It should be used only in one case and this is not your case. Out.
Add Comment