I don't know if it's such a good idea to start by showing how easy changing commit messages is or even have this option that easily available, because after all you're changing the history and the beginner might not be aware what this really means, and beginners seem to be the target audience for this tool.
Actually, GitUp was designed to be for professional software engineers first, even though it may also appeal to beginners. It's faster than the CLI for a number of operations, and offers features that don’t even exist natively in Git like a visual commit splitter or a unified reflog browser.
The Map view documentation does have a large warning on rewriting history (which obviously is required for a number of operations), but I agree that an in-app warning might be good too: http://forums.gitup.co/t/using-gitup-map-view/34.
I agree. If you've already pushed to other repos with the old commit message, this can cause issues. The only time I actually change the commit message is when I'm sure that nobody else has seen it. I'm not even sure what happens when you change the local commit message, and push it again. Does it just get updated in the remote repo?
You get the usual Git error "unable to fast-forward" which means in plain English that what's on the remote repo doesn't match what you have locally anymore, so you can't push, unless you force.
In such cases, GitUp just prompts you if you want to force push.
If you decide to force push, then your updated commit message is on the remote repo as well. This is completely safe if this is your private repo, or you are pushing to a private branch. In any other situation e.g. a shared repo with a team or a public repo on GitHub, you should pretty much never force-push as this will mess up other people clones (as there are now 2 histories of the repo in a way).
I agree. Instead of promoting this as something very simple to do with GitUp, we should stop people from having people the urge to change commit messages.
Plus, as even programming data structures are increasingly immutable, I don't see why I would go change the commit message from a week ago.
Changing git history is simply and utterly wrong unless you are the sole developer, for the reasons you already understand.
I would even go so far as to say that even with a sole developer, this shouldn't be part of a workflow, as 1 developer can become 2 fairly easily.
I think you need to mention this in your homepage/video/marketing somewhere.
You're basically making it easier to mutate Git history, with all the concurrency issues that that creates. The reason why changing history in Git is hard, is because it should be hard.
You can't push your changed commits without forcing them, and if you force them, then you're overwriting the remote repo
and all guys having a clone will have "fun" on their next pull.
