mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Elijah Newren <>
To: Shourya Shukla <>
Cc: Git Mailing List <>,
	Junio C Hamano <>,
	"brian m. carlson" <>
Subject: Re: [PATCH v4 4/4] gitfaq: fetching and pulling a repository
Date: Sat, 2 May 2020 12:00:36 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <20200502065745.GD5582@konoha>

Hi Shourya,

On Fri, May 1, 2020 at 11:57 PM Shourya Shukla
<> wrote:
> 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.

So, perhaps we can shorten all three paragraphs to something like the following?

A fetch stores a copy of the latest changes from the remote
repository, without modifying the working tree or current branch.  You
can then at your leisure inspect, merge, rebase on top of, or ignore
the upstream changes.  A pull consists of a fetch followed immediately
by either a merge or rebase.

> 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?

Ah, the never ending spacing debate...

There may be variation country-to-country, but I doubt it's country
specific.  It's more a raging debate based on the fact that "official"
rules have changed multiple times, old habits die hard, different
contexts exist for different audiences, and various other wrinkles.
("official" needs quotes because it's not clear who the authority on
publishing, writing, or style is.  There are multiple out there.  But
even if you pick a fairly commonly quoted authority, such as the
Chicago manual of style, they've had at least three different rules
for how much space to use after the full stop over time.)

If you use a typesetting program like LaTeX, the amount of space you
use in the source is irrelevant as the target will automatically be
generated with the right amount according to whatever ruleset is in
play (you just need to be careful to specify when periods are used in
abbreviations versus at ends of sentences).  But if you are using a
WYSIWYG document or a plain text document for both generation and
consumption of the information, then some kind of rule is needed.

Fixed width versus proportional fonts also matter.  The two space rule
arose in the age of typewriters, which came about during the era when
larger spaces between sentences was the typesetting rule, and was
translated into a two-space rule.  Many of the one-space rules and
rule changes arose among those assuming everything would be using
variable width fonts[1].  Unless you're crazy[2], source code remains
fixed width and emails on mailing lists like git@vger often are too
(whenever someone sends a table as part of a commit message or just in
discussion, attempting to read it in a proportional font is
impossible; gmail is atrocious and a crime against humanity here but
luckily I can just go over to to read the emails
in a fixed width font).

There does seem to be emerging consensus among many style guides
(which come from those that just outright assume that variable width
fonts are the only kind that exist anymore) that just one space should
be used, though it appears to be at least partially because one space
is easy for editors to enforce[3]. (Switching from two spaces to one
is a simple search and replace, whereas switching from one space to
two is really hard because you have to know whether a period ends an
abbreviation like "Dr." or ends a sentence.)  The emerging style rules
also exist despite a (recent-ish) study showing that two spaces
slightly aids reading speed[4].

Personally, I still remember using a single space after sentences, and
my dad standing over my shoulder and letting me know that it was WRONG
to do that and that sentences should be followed by two spaces.  25
years later, it's an ingrained habit.  But the fact that I spend most
of my time in an environment that most the style guides presume no
longer exists or is used (namely fixed width fonts, as found with
source code), means that I've got a good argument that the conventions
used back in the days of typewriters are the ones that are actually
correct within my context.  Plus there's actually a scientific study
that just conveniently happens to match my habit, so now I can claim
that I've been right all along these past 25 years; in the end, that's
all that really matters anyway.  ;-)


  reply	other threads:[~2020-05-02 19: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
2020-05-02 19:00       ` Elijah Newren [this message]
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:

  List information:

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

  git send-email \ \ \ \ \ \ \

* 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

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).