From: Igor Djordjevic <igor.d.djordjevic@gmail.com>
To: Harry Putnam <reader@newsguy.com>, git@vger.kernel.org
Subject: Re: [noob] is this normal behavior
Date: Tue, 9 May 2017 22:25:27 +0200 [thread overview]
Message-ID: <03ef09e8-62a1-b6bb-041a-bad83dc353f4@gmail.com> (raw)
In-Reply-To: <868tm6w5bz.fsf@local.lan>
Hi Harry,
Both behaviours you report are normal, specifically:
On 09/05/2017 15:02, Harry Putnam wrote:
> Shouldn't files that changed but are already being tracked just show
> up as modified and not need adding?
> ...
> Since that file is already being tracked; shouldn't `git status' show
> that file as modified but ready to be committed instead of a file that
> is modified but needs to be added before a commit can happen?
No, it shouldn`t - even though the file you`ve modified is already
being tracked, it doesn`t have to mean you want the modification
inside your very next commit, and Git doesn`t force that upon you.
That is where index (or "staging area") comes in handy, allowing you
to `git add` only the changes you actually want to commit now,
leaving the others for later decision.
You don`t even have to add all the modifications inside the single
file at once, for example by using `git add --patch`[1] you can
select just some of the them, fine tuning what gets committed and when.
With some precaution/steps needed not to commit broken project states
by accident, and some discipline not to overdo it, this allows you to
fully focus on the actual work you do, making logically unrelated
changes in place as you see fit, on the go, and only later organizing
them into logically grouped commits, through diligent use of `git add`.
> Another side of this is that a `git diff FILE' only works before an
> `git add .' operation is done.
>
> That is, if I run `git diff FILE' AFTER `git add' .. no diff is
> reported, even though it is not committed yet.
>
> So, for example: if I'm committing and in the vi buffer of the commit
> and want to see a diff of FILE to aid my log notes.
>
> git diff FILE will report nothing whatever.
>
> Is that expected behavior?
Yes, that is as expected - in the form you`ve given, `git diff` shows
the differences between your working tree and index (staging area),
so only changes you haven`t added yet. Once you `git add` the changes
from the working to the index, there are no more differences to show,
so no diff is produced.
If you want to see the added changes, what will be included in the
commit if you make it, you can use `git diff --cached`, as per
git-diff[2] documentation (--staged can also be used instead, being a synonym
for --cached, but maybe easier to remember, relating it to "staging
area").
That option shows differences between the staging area (index) and
the specific commit - with none provided, it implies your currently
checked-out position (referred to as HEAD), usually being your
latest/previous commit, which is exactly what you`re interested in.
As a side note, if you think you don`t need it, you can skip staging
area and commit all the modifications/deletions without a need of
adding them first by using `git commit --all`, as per git-commit[3]
documentation.
Just pay attention that untracked files are not affected, you still
need to add them first to tell Git to start tracking them, including
them in the next commit, but that seems to align nicely with your
expectations already.
I personally find the staging area to be one of the greatest Git
possibilities, but I do understand beginners getting confused by it,
as admittedly I once was myself.
In the end, you may want to ask questions like this on Git users
mailing list[4] on Google Groups, being a a nice place for beginners
to get answers to their concerns.
[1] https://git-scm.com/docs/git-add
[2] https://git-scm.com/docs/git-diff
[3] https://git-scm.com/docs/git-commit
[4] https://groups.google.com/forum/?fromgroups#!forum/git-users
Regards,
Buga
next prev parent reply other threads:[~2017-05-09 20:25 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-09 13:02 [noob] is this normal behavior Harry Putnam
2017-05-09 20:25 ` Igor Djordjevic [this message]
2017-05-10 17:27 ` Harry Putnam
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=03ef09e8-62a1-b6bb-041a-bad83dc353f4@gmail.com \
--to=igor.d.djordjevic@gmail.com \
--cc=git@vger.kernel.org \
--cc=reader@newsguy.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.
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).