From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Elijah Newren <newren@gmail.com>
Cc: "Git Mailing List" <git@vger.kernel.org>,
"Christoph Böhmwalder" <christoph@boehmwalder.at>
Subject: Re: Why is there no force pull?
Date: Sat, 09 Jun 2018 22:30:56 +0200 [thread overview]
Message-ID: <87h8mbwvlr.fsf@evledraar.gmail.com> (raw)
In-Reply-To: <CABPp-BG9HQ4O8h7-b4oL7KLu+boe6-QV1fvcfW_4O3Rax3W_Hw@mail.gmail.com>
On Sat, Jun 09 2018, Elijah Newren wrote:
> On Sat, Jun 9, 2018 at 12:01 PM, Christoph Böhmwalder
> <christoph@boehmwalder.at> wrote:
>> Hi,
>>
>> Since this is a use case that actually comes up quite often in
>> day-to-day use, especially among git beginners, I was wondering: is
>> there a specific reason why a command like "fetch changes from remote,
>> overwriting everything in my current working directory including all
>> commits I've made" doesn't exist? Now, I'm quite aware that something
>> like
>>
>> $ git fetch origin/branch
>> $ git reset --hard origin/branch
>>
>> will do the trick just fine, but (like I mentioned, especially for
>> beginners) this kind of seems like a crook. Why not have a single
>> command for accomplishing this? Afterall we do have a `--force` flag on
>> `git push`, which practically does the same thing in reverse.
>>
>> Just reaching out to get some input on this, as it seems like a quite
>> curious inconsistency to me.
>
> Upon reading the subject and before reading the body, I assumed you
> were going to ask for a 'git pull --force' that would throw away
> *uncommitted* changes (i.e. do a 'git reset --hard HEAD' before the
> rest of the pull). But then you asked for both uncommitted and
> committed changes to be thrown away. That difference isn't something
> you have to consider with a push.
>
> That might be a reason such an option would be confusing, or it might
> just be a warning to document the option carefully. Anyway, thought
> I'd mention it.
More generally, "git pull"'s params are passed to "git fetch", and then
we either "git merge" or "git rebase".
This proposed behavior doesn't fit into that at all.
But it would if we added a third mode, similar to how we added "rebase",
where we'd dispatch to "reset" instead, so:
git pull --reset --hard
Meaning (in the general case):
git fetch &&
git reset --hard @{u}
next prev parent reply other threads:[~2018-06-09 20:31 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-09 19:01 Why is there no force pull? Christoph Böhmwalder
2018-06-09 20:04 ` Elijah Newren
2018-06-09 20:25 ` Christoph Böhmwalder
2018-06-09 20:30 ` Ævar Arnfjörð Bjarmason [this message]
2018-06-10 16:11 ` Torsten Bögershausen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87h8mbwvlr.fsf@evledraar.gmail.com \
--to=avarab@gmail.com \
--cc=christoph@boehmwalder.at \
--cc=git@vger.kernel.org \
--cc=newren@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).