RE: git diff --name-status for deleted files

[Gene Thomas]

Junio,
   Thanks for your reply. So git is essentially doing a "git commit" 
when I "git rm". 

Gene.

-Original Message-
From: Junio C Hamano [mailto:gits...@pobox.com] 
Sent: Friday, 15 September 2017 2:58 PM
To: Gene Thomas <g...@nlc.co.nz>
Cc: git@vger.kernel.org
Subject: Re: git diff --name-status for deleted files

Gene Thomas <g...@nlc.co.nz> writes:

> Hello,
>   "git diff -name-status" is useful to list the files one
>   has changed but it does not list file that one has
>   deleted with "git rm". It would be really handy if it
>   did. I am using git 2.9.3 on Ubuntu Linux 16.10.

With or without --name-status option, "git diff" compares between the contents 
you have in the index and in your working tree.  After you modify contents of a 
file, i.e.

edit file
git add file

you would not see that file edited exactly because the file on the filesystem 
is identical to what you added to the index with "git add".

Your example works exactly the same way.  Instead of modifying the contents of 
a file, removing the presense of the file and recording that fact to the index 
(i.e. removing the path from the index, too) is done with "git rm", so after 
running

git rm file

your working tree would lack "file" and so would your index.  Hence you 
wouldn't see "git diff" report any difference on "file".

Perhaps you wanted "git diff HEAD", which is a way to compare between the 
contents you have in the tip commit and the paths in your working tree thru the 
index?

git diff --name-status for deleted files

[Gene Thomas]

Hello,
  "git diff -name-status" is useful to list the files one has changed 
but it does not list file that one has deleted with "git rm". It would be 
really handy if it did. I am using git 2.9.3 on Ubuntu Linux 16.10.

Yours Sincerely,

Gene Thomas.

RE: rebase destroys branches

[Gene Thomas [DATACOM]]

Philip,
Thanks for your reply.

The original branch is not 'destroyed', rather the pointer to the previous tip 
is within the logs. 

Is that the 'git log' log or internal logs? Are you sure? There doesn't appear 
to be a way to checkout that tip of see the log back from that tip.

All the content is still available until the logs expire.

So we will be unable to checkout content after a time?

Gene Thomas.

-Original Message-
From: Philip Oakley [mailto:philipoak...@iee.org] 
Sent: Tuesday, 5 March 2013 12:44
To: Gene Thomas [DATACOM]; Git List
Subject: Re: rebase destroys branches

From: Gene Thomas [DATACOM] gene.tho...@datacom.co.nz
Sent: Monday, March 04, 2013 11:06 PM
Hello,
I am evaluating git for use in a company. Please correct if I am wrong.
I am concerned that an inexperienced developer could mistakenly rebase 
branches, destroying the original branch.

The original branch is not 'destroyed', rather the pointer to the previous tip 
is within the logs. All the content is still available until the logs expire.

   Attached is a script (Windoze)
that shows the 'topic' branch being moved!, after the rebase we are 
unable to see the original branch, read it's history or find it's 
commit points.

Surely no operation should remove anything from the repository.
Operations like this irreversibly break the repository . When rebasing 
the original branch must be retained.

It's easy to misread some of Git's strengths if you have come from other 
historic corporate 'version control systems' which are often based on drawing 
office practice of old (e.g. the belief there is a single master to be 
protected is one misconception for software).

Rebase, at the personal level, is an important mechanism for staff to prepare 
better code and commit messages. Trying to hide the reality will just make your 
management 'control' less effective as staff work around it and delay 
check-ins, etc.

The broader access control and repo management issues are deliberately not part 
of Git, and there are good tools for that. e.g. Gitolite.

Yours faithfully,


Gene Thomas.

Philip

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html