Surely the correct solution is a better log output that can filter out these unwanted merges.As an added bonus, here’s a diagram illustrating the commands a typical developer on a traditional Subversion project needed to know about to get their work done.There is essentially no distinction between implementation detail and user interface.It’s understandable that an advanced user might need to know a little about how features are implemented, to grasp subtleties about various commands.
It combines email reading with patch applying, and thus uses a different patch syntax (specifically, one with email headers at the top). They describe the commands from the perspective of a computer scientist, not a user.
A common response I get to complaints about Git’s command line complexity is that “you don’t need to use all those commands, you can use it like Subversion if that’s what you really want”. That’s like telling an old granny that the freeway isn’t scary, she can drive at 20kph in the left lane if she wants.
Git doesn’t provide any useful subsets – every command soon requires another; even simple actions often require complex actions to undo or refine. Just rev to 6000, dump the clutch, and use wheel spin to get round the first corner.
Git dumps the burden of understanding complex version control on everyone – while making the maintainer’s job easier.
Why would you do this to new contributors – those with nothing invested in the project, and every incentive to throw their hands up and leave?
What a pity that it’s so hard to learn, has such an unpleasant command line interface, and treats its users with such utter contempt.