3 ms·

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 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?

swisspol 11y ago
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).
- loumf 11y ago
  Which makes it really weird that your video shows you doing this to master, a branch very likely to be shared.
  - graffitici 11y ago
    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.
- lectrick 11y 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.
dan00 11y ago
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.

swisspol 11y ago

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).

loumf 11y ago
Which makes it really weird that your video shows you doing this to master, a branch very likely to be shared.
- graffitici 11y ago
  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.
lectrick 11y 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.

dan00 11y ago

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.