Git repository: Resetting the Master branch

[Rachael]

Am I the only one who has open notepad windows with a bunch of temporary clipboard pastes to use later, precisely for operations like this? >.>

Nevertheless the point I am trying to make is resetting branches is a bit alienating to contributors (as evidenced by Phantom's reaction - trust me I know from experience doing this myself, that she's not the only one) and often unnecessary - and should only be done in extreme circumstances.

[Xeotroid]

Am I the only one who has open notepad windows with a bunch of temporary clipboard pastes to use later, precisely for operations like this? >.>

And then weeks later I go through a bunch of unsaved Notepad++ tabs with text in them that I have no clue what it is for anymore.

[Graf Zahl]

Seriously, I'd say use the proper tools. The entire notion that there is only one way to handle Git - and for too many hardcore developers this is the command line tools - is just ridiculous. Git is so complex and so powerful that for the more involved tasks it's a losing proposition. A good GUI tool is just magnitudes faster here. That goes particularly for scenarios where it is necessary to clean up a messed up repo. This last reset was harmless to just get some unfinished code out of the commit tree, but the other one was a complex rebuild of a clean commit history - I wouldn't know how I should have done this with the command line tools.

[Rachael]

"Faster" is very subjective. I'm very fast with the command line, but that's likely because it's my normal mode of working.

I'm not saying there's only one way to work with Git or that there's even a superior way - the reason why I post command-line commands for Git is because it's what I know - and I tend to be the type not to accept a "you can't do this" answer to most questions.

I use TortoiseGit when it is necessary. I've found it's actually magnitudes faster and more efficient for dealing with merge conflicts. So it's really not about command line being the only way to work.

For moving around inside of, as well as manipulating, a commit history tree though, I do find the command line more efficient - but that's just me and that works well with my workflow.

[Graf Zahl]

You can't be fast with the command line when rebuilding a commit tree. But that's a task that occurs sooner or later. I've never worked on a project where nothing went wrong ever. And then there's 3 options:

1. Revert the bad commits and live with the pollution they cause.
2. Start a new branch and forget about the old one.
3. Reset the branch.

1. is the only option here that doesn't involve manual repo editing, but it's also the one that incurs the most long term damage if the reverted changes are larger. But as it stands with editing, it involves reviewing the changes before adding them back, and for that a visual editor is a requirement. I'd never trust a repo editing job done from the command line, the risk of something being overlooked is far too high.

The command line is fine for simple tasks that can be fired off without much typing. Even the staged commit procedure can become very awkward if you want to do a selective commit by reviewing what was changed.

[Redneckerz]

The term ''master'' is going to be defunct according to Github and its going to be ''main'' instead. They also plan on giving users the option to name their main branch a different name. As found on Twitter