21–30 of 144 posts
Earlier quoted context omitted.
Rebasing unpushed commits is ok. But I have yet to see a workflow that provides good enough guardrails to make it something you can do safely.
Protect your main branch?
I wont claim to understand C and the reason why is better than “”. I assume it is. But the fact that a merge can have arbitrary changes in it always bothers me! This is a case for rebase over merge if there are conflicts. You could have a merge of 2 empty repo parents where the result is the complete source of the latest version of Kubernetes!
I have to admit that I never really understood the advantages of rebase, and what I mean by this is they I actually don’t understand how the dangers of rebase out-weighs any form of advantages. Especially because on of the major advantages of merge is that you can squash your local commit history when you submit it to your main branch.
What we do is that we tie every pull request to a relatively small feature task, and because we do this, we genuinely don’t care about the individual commits developers do. Which means they can commit really silly messages if they are heading to a meeting or if they are just tired at the end of the day. It also helps with them merging main into their branch often, because it doesn’t taint the history.
The biggest advantage we’ve seen, that maybe we didn’t expect, is that nobody ever fucks up our tree in a way that needs someone who actually understands git to solve. We’ve also locked down the use of force push so that is not available to anyone unless it’s absolutely needed. Part of the reason I set this up initially was to protect myself from me, but it’s been a good thing since.
But I’m actually curious if it’s wrong.
Earlier quoted context omitted.
Protect your main branch?
One of the great advantages of git is being able to pull from other people's feature branches, not just master. So protecting just master isn't good enough.
Earlier quoted context omitted.
One idiot with rebase destroys history with no trace. I worked with such an idiot in a parallel team. I can't say how many weeks of work randomly got destroyed by said idiot. I hate rebase on shared code I don't care how clean jt looks. Don't mess with history.
I really don't understand how you can lose weeks of work. The person that would have done the force push would have the original commit in their reflog. ORIG_HEAD would be set. Everyone else that had a copy of the repo would have had a copy of the "lost" commits. I really cannot imagine how many things would have to go wrong for weeks of work to be lost.
- Person who destroys git history
- Person who hates destroying git history
- Person who knows how to recover "destroyed" history
- Person who knows how to truly destroy git history
I wont claim to understand C and the reason why is better than “”. I assume it is. But the fact that a merge can have arbitrary changes in it always bothers me! This is a case for rebase over merge if there are conflicts. You could have a merge of 2 empty repo parents where the result is the complete source of the latest version of Kubernetes!
A "merge commit" is nothing more than a commit claiming any number of parents greater than one. It is still its own file tree reference that decides how the tree looks, and nothing dictates that it should be related to the parents.
I wont claim to understand C and the reason why is better than “”. I assume it is. But the fact that a merge can have arbitrary changes in it always bothers me! This is a case for rebase over merge if there are conflicts. You could have a merge of 2 empty repo parents where the result is the complete source of the latest version of Kubernetes!
One idiot with rebase destroys history with no trace. I worked with such an idiot in a parallel team. I can't say how many weeks of work randomly got destroyed by said idiot. I hate rebase on shared code I don't care how clean jt looks. Don't mess with history.
Rebase is a necessary part of a workflow even if you like merge commits. You're severely missing out if interactive rebases are not part of your toolbox.
Earlier quoted context omitted.
One of the great advantages of git is being able to pull from other people's feature branches, not just master. So protecting just master isn't good enough.
Yeah so you have them go through the workflow that doesn’t ruin things, like pull requests?
Earlier quoted context omitted.
I really don't understand how you can lose weeks of work. The person that would have done the force push would have the original commit in their reflog. ORIG_HEAD would be set. Everyone else that had a copy of the repo would have had a copy of the "lost" commits. I really cannot imagine how many things would have to go wrong for weeks of work to be lost.
There is a hierarchy to these things: - Person who destroys git history - Person who hates destroying git history - Person who knows how to recover "destroyed" history - Person who knows how to truly destroy git history
… tell me more!
Earlier quoted context omitted.
Yeah so you have them go through the workflow that doesn’t ruin things, like pull requests?
I don't want to have to go back and forth with someone to pull their branch. I want to just be able to pull anything they've pushed.
git reset --hard origin/branch-nameEarlier quoted context omitted.
I really don't understand how you can lose weeks of work. The person that would have done the force push would have the original commit in their reflog. ORIG_HEAD would be set. Everyone else that had a copy of the repo would have had a copy of the "lost" commits. I really cannot imagine how many things would have to go wrong for weeks of work to be lost.
There is a hierarchy to these things: - Person who destroys git history - Person who hates destroying git history - Person who knows how to recover "destroyed" history - Person who knows how to truly destroy git history
The Gitsatz Haderach