git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Shourya Shukla <shouryashukla.oo@gmail.com>
To: Elijah Newren <newren@gmail.com>
Cc: git@vger.kernel.org, gitster@pobox.com, sandals@crustytoothpaste.net
Subject: Re: [PATCH v4 4/4] gitfaq: fetching and pulling a repository
Date: Sat, 2 May 2020 12:27:45 +0530	[thread overview]
Message-ID: <20200502065745.GD5582@konoha> (raw)
In-Reply-To: <CABPp-BFt_5-OyOw9YbYJhhu1P4CJLOi65wdyRckOY5_acRejGg@mail.gmail.com>

On 29/04 08:56, Elijah Newren wrote:
> > +[[fetching-and-pulling]]
> > +How do I know if I want to do a fetch or a pull?::
> > +       A fetch brings in the latest changes made upstream (i.e., the
> > +       remote repository we are working on). This allows us to inspect
> > +       the changes made upstream and integrate all those changes (if
> > +       and only if we want to) or only cherry pick certain changes.
> > +       Fetching does not have any immediate effects on the local
> > +       repository.
> 
> Maybe change that last sentence to "Fetching does not modify the
> current branch"?  The local repository certainly gets bigger, and the
> remote tracking branches are updated as well as their reflogs, and it
> might trigger a gc, all of which sound like immediate effects to me.

I meant changes in terms of the user's code. Yep you are right, I need
to be precise here.

> > +
> > +       A pull is a wrapper for a fetch and merge. This means that doing
> 
> ...for a fetch and merge or a fetch and rebase.  This means...
> 
> > +       a `git pull` will not only fetch the changes made upstream but
> > +       integrate them as well with our local repository. The merge may
> 
> ...with our current branch.  The merge or rebase...
> 
> > +       go smoothly or have merge conflicts depending on the case. A pull
> > +       does not allow you to review any changes made upstream but rather
> > +       merge those changes on their own.
> 
> I don't understand this last sentence.  You can definitely review
> changes made upstream after a pull; e.g. git log @{u}@{1}..@{u}

I meant that the pull will apply the changes right away and one does not
get the chance to review what is being applied before it has been
applied (something a fetch does). I need to be more clear here,
understood.

> > ++
> > +This is the reason why it is sometimes advised to fetch the changes
> > +first and then merge them accordingly because not every change might
> > +be of utility to the user.
> 
> I don't understand the purpose of this paragraph.

I intended to emphasise the difference between a fetch and a pull; the
fact that fetch just brings in the changes from the remote and doesnot
apply them to our code/files right away, while a pull does so.

Also, a nit but, we are supposed to use 1 SP or 2 SP after a full
stop(.)? In India we use 1 SP, is it different in other countries?

  parent reply	other threads:[~2020-05-02  7:00 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-29  9:38 [PATCH v4 1/4] gitfaq: files in .gitignore are tracked Shourya Shukla
2020-04-29  9:38 ` [PATCH v4 2/4] gitfaq: changing the remote of a repository Shourya Shukla
2020-04-29 16:17   ` Elijah Newren
2020-04-29 17:01   ` Junio C Hamano
2020-04-29  9:38 ` [PATCH v4 3/4] gitfaq: shallow cloning " Shourya Shukla
2020-04-29 16:00   ` Elijah Newren
2020-05-02  5:00     ` Shourya Shukla
2020-04-29 17:09   ` Junio C Hamano
2020-05-02  6:13     ` Shourya Shukla
2020-05-04 16:06       ` Junio C Hamano
2020-05-05 12:26         ` Derrick Stolee
2021-05-06  2:49           ` dyrone teng
2020-04-29  9:38 ` [PATCH v4 4/4] gitfaq: fetching and pulling " Shourya Shukla
2020-04-29 15:56   ` Elijah Newren
2020-04-29 17:19     ` Junio C Hamano
2020-05-02  6:57     ` Shourya Shukla [this message]
2020-05-02 19:00       ` Elijah Newren
2020-05-03  1:03         ` Junio C Hamano
2020-04-29 16:16 ` [PATCH v4 1/4] gitfaq: files in .gitignore are tracked Elijah Newren
2020-05-02  6:36   ` Shourya Shukla
2020-04-29 16:55 ` Junio C Hamano

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200502065745.GD5582@konoha \
    --to=shouryashukla.oo@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=newren@gmail.com \
    --cc=sandals@crustytoothpaste.net \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).