3 ms·
Rewording “too easily” would inevitably lead to someone accidentally rewording a commit on a shared branch (such as main/master). What I want in a git gui is f
by alkonaut 4y ago
Rewording “too easily” would inevitably lead to someone accidentally rewording a commit on a shared branch (such as main/master).
What I want in a git gui is first and foremost the fundamentals of my workflow built into the tool.
What patterns for branch names means they are private? Or short lived? Or forked but never merged back? This should control e.g how a graph is drawn (you don’t bend the main branch etc) or how branch pruning is done.
If I push a feature branch, later it’s merged on a server using a as squash commit and deleted remotely, then there is no way to say it should be deleted locally because there is no merge commit. This means something is missing. Either the knowledge of deleted branches should be communicated. Or the record that the branch was pushed to the central repo but is since deleted there must be saved. And this requires also specifying clearly that a remote is the source of truth. Git just doesn’t care. The remote list is basically a map of names to urls. No name is more special than another, just like no branch names are really special. And while flexible, it’s also extremely limiting.