On Wed, Jun 06 2018, Timothy Rice wrote:
>> It does seem like something which could be noted in the git
>> rm docs. Perhaps you'd care to take a stab at a patch to
>> add a note to Documentation/git-rm.txt Thomas? Maybe a note
>> at the end of the DISCUSSION section?
>
> That same
On Wed, Jun 06 2018, Thomas Fischer wrote:
> I agree that the entire chain of empty directories should not be
> tracked, as git tracks content, not files.
>
> However, when I run 'rm path/to/some/file', I expect path/to/some/ to
> still exist.
>
> Similarly, when I run 'git rm
On Thu, 7 Jun 2018, Timothy Rice wrote:
> > It does seem like something which could be noted in the git
> > rm docs. Perhaps you'd care to take a stab at a patch to
> > add a note to Documentation/git-rm.txt Thomas? Maybe a note
> > at the end of the DISCUSSION section?
>
> That same
> It does seem like something which could be noted in the git
> rm docs. Perhaps you'd care to take a stab at a patch to
> add a note to Documentation/git-rm.txt Thomas? Maybe a note
> at the end of the DISCUSSION section?
That same documentation could mention a common workaround for when
On Wed, Jun 06, 2018 at 04:01:38PM -0400, Todd Zullinger wrote:
> Thomas Fischer wrote:
> > I agree that the entire chain of empty directories should not be tracked,
> > as git tracks content, not files.
> >
> > However, when I run 'rm path/to/some/file', I expect path/to/some/ to still
> >
Thomas Fischer wrote:
> I agree that the entire chain of empty directories should not be tracked, as
> git tracks content, not files.
>
> However, when I run 'rm path/to/some/file', I expect path/to/some/ to still
> exist.
>
> Similarly, when I run 'git rm path/to/some/file', I expect
On Wed, Jun 6, 2018 at 9:32 PM, Thomas Fischer
wrote:
> OVERVIEW
>
> "git rm" will remove more files than specified. This is either a bug or
> undocumented behavior (not in the man pages).
The behavior is intended, with a question mark. This change is
introduced in d9b814cc97 (Add builtin "git
On Wed, 6 Jun 2018, Thomas Fischer wrote:
> I agree that the entire chain of empty directories should not be
> tracked, as git tracks content, not files.
>
> However, when I run 'rm path/to/some/file', I expect path/to/some/
> to still exist.
why?
> Similarly, when I run 'git rm
I agree that the entire chain of empty directories should not be tracked, as
git tracks content, not files.
However, when I run 'rm path/to/some/file', I expect path/to/some/ to still
exist.
Similarly, when I run 'git rm path/to/some/file', I expect path/to/some/ to
exist, *albeit untracked*.
On Wed, 6 Jun 2018, Thomas Fischer wrote:
> OVERVIEW
>
> "git rm" will remove more files than specified. This is either a bug or
> undocumented behavior (not in the man pages).
>
> SETUP
>
> 1. In a git repository, create an empty directory OR a chain of empty
> directories
>
> $ mkdir -p
OVERVIEW
"git rm" will remove more files than specified. This is either a bug or
undocumented behavior (not in the man pages).
SETUP
1. In a git repository, create an empty directory OR a chain of empty
directories
$ mkdir -p path/to/some/
2. Create a file in the deepest directory and add
Eunsuk Kang esk...@csail.mit.edu writes:
My understanding was that running git rm on a file will delete
all ancestors of the file that are empty directories from the file
system.
Not really.
We do recurse up to see if a/b/ and then a/ has become a useless
empty directory when we did remove
Hello,
My understanding was that running git rm on a file will delete all ancestors
of the file that are empty directories from the file system. I've ran into a
case that seems a little strange.
To reproduce (using version 1.8.4.1 on Mac OS X 10.7.5):
git init
mkdir a
mkdir b
touch a/b/c.txt
13 matches
Mail list logo
