list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <>
To: Shourya Shukla <>
Subject: Re: [PATCH 2/2] gitfaq: append the 'Common Issues' section
Date: Mon, 06 Apr 2020 12:28:39 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <> (Shourya Shukla's message of "Mon, 6 Apr 2020 23:42:16 +0530")

Shourya Shukla <> writes:

> +[[rebasing-and-merging]]
> +How do I know when to merge or rebase?::
> +	Rebasing and merging two entirely different concepts with different utiilites.

Can you wrap these lines at a more reasonable column, like 65-72?

> +	In Git terms, rebasing means to place changes made in one branch over another branch
> +	(called base, hence the term rebase). The commit history of the branch wanting to rebase
> +	get placed over the branch on the receiving end and it appears as if those changes took
> +	place in the receiving branch itself. Merging, as the name suggests, merges the latest
> +	commit of one branch onto the recent branch, making this combination appear as one separate
> +	commit.

There is nothing technically wrong per-se in the above, but is this
worth saying here, instead of polishing the tutorial or rebase/merge
manual pages?  Also, in the above, I do not see much that would help
readers to decide which one between merge and rebase to choose.

> +[[files-in-.gitignore-are-tracked]]
> +I asked Git to ignore various files, yet they show up as changes in my staging area::
> +	One uses `.gitignore` to ignore files from getting tracked in the working tree. This ignores
> +	the aforementioned files for the whole lifetime of the project unless they area removed from
> +	the `.gitignore`.

This should mention "git add" (and possibly "git status") somewhere.
You list patterns to match cruft you want to "IGNORE", (i.e. would
not want to track), so that "git add ." would ignore it, and "git
status" won't make noises about them not being tracked.

> But, `.gitignore` will only ignore the files which were not a part of the
> +	repository when they were mentioned in the `.gitignore`. Hence, addition of a file to `.gitignore`
> +	after it was added to the working tree will have no effect and Git will keep tracking them.
> +	To prevent this from happening, one has to use `git rm --cached <file>` to remove the file
> +	from the staging area(i.e. the cache) and not from the repository. 

That's not "prevent this from happening".  It is more like
recovering from an earlier mistake of adding what you did not want
to add.

But people ask ".gitignore does not ignore, my vendor.o file is
tracked, and I want changes to vendor.o to be ignored" in the
context of "once tracked, .gitignore would ont kick in", so the
above advice to "remove from the tracked set" would not even help
them.  Their expectation needs to be adjusted, and an entry in FAQ
you are trying to add is a good place to do so.

> +[[checking-out]]
> +What is checking out a commit/branch? How do I perform one?::
> +	In Git terminology, checking out means updating the current working tree with a another commit or
> +	even a separate tree(which would translate to a branch).

Unless you are going to mention "switch" and "restore", you should
stress the fact that "checkout" checks out two separate things for
two different purposes upfront, in the first sentence.

 - Checking out a branch (or a commit) is to set up the working tree
   files in preparation for working on the history of the branch
   (most often, to grow the history by adding more commits, but
   sometimes to edit the history by rebasing).

 - Checking out individual paths out of a tree-ish (most often, a
   commit) is to grab a verbatim copy of the path recorded in the
   tree-ish to update the files in the working tree, and is done to
   work on the history of the current branch.

People found the "checkout" command confusing, as the distinction
between the two weren't clearly taught to them.  More recent
versions of Git introduced "switch" and "restore" subcommands that
can be used only for the former and for the latter purpose,


      reply	other threads:[~2020-04-06 19:28 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-06 18:12 [PATCH 0/2] Add more issues in gitfaq Shourya Shukla
2020-04-06 18:12 ` [PATCH 1/2] gitfaq: cleanup gitfaq.txt Shourya Shukla
2020-04-06 19:06   ` Junio C Hamano
2020-04-06 23:46   ` Junio C Hamano
2020-04-07  1:07     ` brian m. carlson
2020-04-07  3:15       ` Junio C Hamano
2020-04-08 18:22     ` Pratyush Yadav
2020-04-10 18:29       ` Junio C Hamano
2020-04-06 18:12 ` [PATCH 2/2] gitfaq: append the 'Common Issues' section Shourya Shukla
2020-04-06 19:28   ` Junio C Hamano [this message]

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