Equivalent to Mercurial's 'fetch'

[Daniel Pittman]

Ben Finney <bignose+hates-spam at benfinney.id.au> writes:
> "Martin Pool" <mbp at canonical.com> writes:
>
>> We don't generally auto-commit merges for a few reasons. One is that
>> users may want to check the merge was semantically correct as well
>> as having no technical conflicts, eg by looking at the diff or
>> running some tests. Another is that there is some potential for user
>> confusion if you sometimes have to explicitly commit and sometimes
>> not.
>
> Yes, I must admit I find the auto-commit behaviour of 'hg fetch' a bit
> too magical for comfort.

I think that the common use case for this is a conflict-free merge:
remote changes have happened, as have local changes, and you are now
looking to merge upstream before pushing your changes.

I can see a much better justification for automatically committing that
conflict free merge -- which, essentially, contains zero information --
than for automatically committing a merge that had conflicting merges.

>> But I think there would be no harm in at least having an option for
>> this for people who like it. I would probably put it on merge rather
>> than having a new command.
>
> That behaviour already exists for those who use 'merge --pull', since
> sometimes the pull happens (in which case there's nothing to commit)
> and sometimes it doesn't.
>
> In that case, I vote for a single 'merge --automatic' option that
> would be like 'merge --pull' but with the added behaviour of
> automatically committing a merge if the merge was successful.

I think that requiring a manual commit after conflicts, but an automatic
commit after a conflict-free merge, is going to be more what most people
expect.

Regards,
        Daniel