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?
next prev 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).