"brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> writes: > It may be helpful to point out that this is essentially the workflow I > had ... > I'm not sure if this email is an argument for or against this option, > but maybe it provides some helpful perspective. I think you and Phillip misread me. I did not question if the workflow is common the message you are responding to. I've done my fair share of "I know what I have on my laptop is stale as I pushed it out to elsewhere to continue working on it, so let's get rid of it from the updated upstream and start afresh" myself. What I questioned was if it is sensible to ensure that it stays common. We'd be encouraging the dangerous workflow, instead of analysing the situation where people employ it and trying to give them a better alternative to deal with the situation. That is what we'd be doing with "pull --reset", i.e. an easier to type short-hand that robs the chance to double check in the middle of "fetch && inspect && reset" sequence. As to where the feature should go, if we decide that it is a good idea to promote this workflow element as a supported feature, I agree with Alex's design in the patch that it makes sense to have it as "pull --reset". Existing "pull --merge" and "pull -rebase" are "fetch and then integrate by merging theirs into ours" and "fetch and then integrate by rebasing our stuff on top of theirs"; the new "pull --reset" would fit well sitting next to them with its "fetch and then treat our stuff as valueless and replace it with theirs" semantics.
