All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Duy Nguyen <pclouds@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>,
	Damien Robert <damien.olivier.robert@gmail.com>,
	Git Mailing List <git@vger.kernel.org>,
	Christian Couder <christian.couder@gmail.com>,
	Stefan Beller <stefanbeller@gmail.com>
Subject: Re: Pull without fetch
Date: Mon, 08 Apr 2019 14:51:31 +0200	[thread overview]
Message-ID: <877ec4acdo.fsf@evledraar.gmail.com> (raw)
In-Reply-To: <CACsJy8B_-r-=LxzvdnY44H7Bnydijqu4+GvWOy3r+hP723uezA@mail.gmail.com>


On Mon, Apr 08 2019, Duy Nguyen wrote:

> On Mon, Apr 8, 2019 at 8:34 AM Junio C Hamano <gitster@pobox.com> wrote:
>>
>> Damien Robert <damien.olivier.robert@gmail.com> writes:
>>
>> > is there a way to do a git pull without it running git fetch?
>> > Looking at the source in builtin/pull.c does not seem to indicate so.
>>
>> The reason behind that is because it does not make any sense for
>> "pull", which is meant as a quick short-cut to say "fetch && merge",
>> not to run fetch, especially back then when 'git pull' was designed,
>> the world was much simpler.  There was no "fetch && rebase", our
>> branches did not know what their @{upstream}s were.  In that simpler
>> world, what you are trying to do would have been:
>>
>>         git fetch
>>         # did I get anything worth integrating?
>>         git merge FETCH_HEAD
>>
>> That obviously would not work for those with "pull.rebase", and I do
>> not think it makes much sense to teach "git rebase" the same trick
>> to read FETCH_HEAD as "git merge" does in the above sequence.
>>
>> Others may have a better idea, but I do not immediately see any
>> solution better than inventing a new option to "git pull".
>>
>> Another and better option that may be harder to arrange is to make
>> sure that a no-op "git fetch" incurs very low cost.  If you did so,
>
> Not exactly related. But I often wish to see the list of branch
> updates since the last fetch. There's no easy way (that I know) to do
> this unless you copy the last fetch's output somewhere. If this "fetch
> at low cost" could simply read FETCH_HEAD and summarizes it like a
> normal fetch, that would be great. And it should also be very low cost
> because we only replay the last part (making summary) of normal fetch.

The ability to have this is something reftables will provide (from my
memory of a comment by Stefan Beller), which Christian Couder is working
on implementing these days.

>> "git fetch && git pull" would perform just like your "git fetch &&
>> git pull --no-fetch", and we won't need a new option at all.

  reply	other threads:[~2019-04-08 12:51 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-06 13:12 Pull without fetch Damien Robert
2019-04-08  1:34 ` Junio C Hamano
2019-04-08  2:17   ` Duy Nguyen
2019-04-08 12:51     ` Ævar Arnfjörð Bjarmason [this message]
2019-04-08 13:18       ` Duy Nguyen
2019-04-08 14:53   ` Damien Robert
2019-04-08 16:11     ` Damien Robert
2019-04-09  8:03       ` Junio C Hamano
2019-04-11 11:07         ` Damien Robert

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=877ec4acdo.fsf@evledraar.gmail.com \
    --to=avarab@gmail.com \
    --cc=christian.couder@gmail.com \
    --cc=damien.olivier.robert@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=pclouds@gmail.com \
    --cc=stefanbeller@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.