On Fri, Nov 8, 2013 at 2:48 AM, Vincent van Ravesteijn <v...@lyx.org> wrote: > On Thu, Nov 7, 2013 at 10:40 PM, Nico Williams <n...@cryptonector.com> > wrote: >> _Never_ push -f to any repo that *others* (or even you, in other >> workspaces) pull from. > > In general it is better to not rewrite history if you're collaborating. I > don't completely agree with the "_Never_". > > If you're sure you are the only one working on the feature, you can rewrite > history every time you update. For example, if you want to have your feature > merged with master, you want to have a nice series of commits. The > maintainer won't agree with the merge if the series is full of rubbish > commits just because you're not allowed to rewrite history because you once > shared your work so that others can try it.
Of course. I rebase (and re-write history of) my private branches all the time. I push those (with -f) to my public repos. But for official master branches of master repos? Never. > If you're collaborating on a feature, you'll need to sync with your > collaborator when to rewrite the history. Yes. The easiest way to do this is not to push -f but to push a new branch. E.g., % git checkout feature-foo <do work, commits> % git checkout -b feature-foo2 % git rebase -i master ... % git push myrepo feature-foo2 Now anyone who had code based on feature-foo can now % git rebase --onto feature-foo2 and we can all observe what changed in each rebase. > Others that might have pulled your features should be aware that they were > pulling from your personal repository. Yes. And you might not know if they did, so you might well push -f to these. This is a risk they take; they should tell you. Nico --
