Re: "git rm" seems to do recursive removal even without "-r"

[Junio C Hamano]

"Robert P. J. Day"  writes:

> ... so if, in the kernel source
> tree, i ran:
>
>   $ git rm \*.c
>
> i would end up removing *all* 25,569 "*.c" files in the kernel source
> repository.

Yes, as that is exactly what the command line asks Git to do.

If you said

$ git rm *.c

then the shell expands the glob and all Git sees is that you want to
remove a.c b.c d.c ...; if you said "git rm -r *.c", unless b.c is
not a directory, these and only these files are removed.

>   however, let's say i wanted to remove, recursively, all files with a
> *precise* (non-globbed) name, such as "Makefile". so i, naively, run:
>
>   $ git rm Makefile
>
> guess what ... the lack of globbing means i remove only the single
> Makefile at the top of the working directory.

Again, that is exactly what you asked Git to do.

$ git rm $(find . -name Makefile -print)

would of course one way to remove all Makefiles.  If you let POSIX
shell glob, i.e.

$ git rm */Makefile

the asterisk would not expand nothing but a single level, so it may
remove fs/Makefile, but not fs/ext4/Makefile (some shells allow
"wildmatch" expansion so "git rm **/Makefile" may catch the latter
with such a shell).

By letting Git see the glob, i.e.

$ git rm Makefile \*/Makefile

you would let Git to go over the paths it knows/cares about to find
ones that match the pathspec pattern and remove them (but not
recursively, even if you had a directory whose name is Makefile; for
that, you would use "-r").

Earlier some people mentioned "Unix newbie" in the thread, but I do
not think this is about Unix.  In general, Unix tools do not perform
grobbing themselves but expect the user to tell the shell to do so
before the tools see the arguments.  In that sense, I do think the
combination of "-r" and globbing pathspec may produce a result that
looks confusing at first glance.  

"git rm [-r] ..."

 (1) walks the paths it knows/cares about, rejecting ones that do
 not match the ;

 (2) decides to remove the ones that match; and

 (3) when it is asked to recursively remove, the ones that are
 directories are removed together with its contents.  If it was
 not asked to go recursive, it refuses to act on directories.

where (1) and (2) are not something the tool needs to worry
about---what is given from the command line is the only set of paths
that the tool is asked to operate on.  These two steps are quite
unlike regular Unix tools.

Once you decide to give the tool the flexibility that come from
taking pathspec, however, steps (1) and (2) do have to happen inside
the tool.  And great power takes some understanding of the tool on
the part of the user to exercise.  I suspect that the occasion you
would need to use "-r" with "git rm" is a lot less frequent than a
plain "rm".

Of course, there is no confusion if you do not quote wildcards.  By
quoting wildcards and not letting the shell to expand them, the user
tells Git that the fact _it_ sees the asterisk is because the user
is doing so on purpose---so that Git would find paths that match the
pattern.

Hope this clarifies and helps.

Re: [PATCH v2 1/5] test-list-objects: List a subset of object ids

[Junio C Hamano]

Jeff King  writes:

> On Sat, Oct 07, 2017 at 03:12:08PM -0400, Derrick Stolee wrote:
>
>> In my local copy, I added a test to p4211-line-log.sh that runs "git log
>> --raw -r" and tested it on three copies of the Linux repo. In order, they
>> have 1 packfile (0 loose), 24 packfiles (0 loose), and 23 packfiles
>> (~324,000 loose).
>> 
>> 4211.6: git log --raw -r  43.34(42.62+0.65)   40.47(40.16+0.27)  -6.6%
>> 4211.6: git log --raw -r  88.77(86.54+2.12)   82.44(81.87+0.52)  -7.1%
>> 4211.6: git log --raw -r 108.86(103.97+4.81) 103.92(100.63+3.19) -4.5%
>> 
>> We have moderate performance gains for this command, despite the command
>> doing many more things than just checking abbreviations.
>
> Yeah, while it's less exciting than seeing the 90% numbers for a
> micro-benchmark, I think this represents real-world gains (and 5-7% is
> nothing to sneeze at).

Yes!  I would even say 5-7% is much better than "nothing to sneeze
at".  We do prefer workload closer to the real-world usage over
micro benchmarks, and consider changes that gain by a few percent as
real improvements.

> You might also try adding "--format=%h" or --oneline to your invocation,
> which would compute abbreviations for each commit (making your workload
> more abbrev-heavy and possibly showing off the difference more).

Again, agreed, and I would not consider it would be inflating the
benchmark artificially in favor of the change.  "log --oneline" is
not something people use rarely---I'd think it would be quite a
normal thing to do.

> I also think "-r" isn't doing anything. Recursive diffs are the default
> for the "log" porcelain (even for --raw).

That's my fault writing "-r" ;-) Together with your "log --oneline"
suggestion,

git log --oneline --raw

would be a reasonable thing to measure.

Thanks, both.

Re: "git rm" seems to do recursive removal even without "-r"

[Paul Smith]

On Sat, 2017-10-07 at 15:43 -0400, Robert P. J. Day wrote:
>   it's been a long week, so take this in the spirit in which it is
> intended ... i think the "git rm" command and its man page should be
> printed out, run through a paper shredder, then set on fire. i can't
> remember the last time i saw such a thoroughly badly-designed,
> badly-documented and non-intuitive utility.

"git rm" works the same way that the UNIX rm command has worked, for 40+
years now.  Very simple, very well designed, and very intuitive (IMO).

The major difference is the ability to handle globbing patterns, which
UNIX rm doesn't do.  Maybe the way this is implemented is a little
confusing, although I just read the man page and it seemed pretty clear
to me.

If you don't use glob patterns (or more specifically if you let the
shell handle glob patterns, which is how I always do it) then there is
really nothing bizarre about "git rm".  Maybe you could be more precise
in your criticism.

Re: "git rm" seems to do recursive removal even without "-r"

[Robert P. J. Day]

On Sat, 7 Oct 2017, Paul Smith wrote:

> On Sat, 2017-10-07 at 15:43 -0400, Robert P. J. Day wrote:
> >   it's been a long week, so take this in the spirit in which it is
> > intended ... i think the "git rm" command and its man page should be
> > printed out, run through a paper shredder, then set on fire. i can't
> > remember the last time i saw such a thoroughly badly-designed,
> > badly-documented and non-intuitive utility.
>
> "git rm" works the same way that the UNIX rm command has worked, for
> 40+ years now.  Very simple, very well designed, and very intuitive
> (IMO).
>
> The major difference is the ability to handle globbing patterns,
> which UNIX rm doesn't do.  Maybe the way this is implemented is a
> little confusing, although I just read the man page and it seemed
> pretty clear to me.

  um, wrong.

> If you don't use glob patterns (or more specifically if you let the
> shell handle glob patterns, which is how I always do it) then there
> is really nothing bizarre about "git rm".  Maybe you could be more
> precise in your criticism.

  ok, fine, let me explain why this command is a nightmarish
monstrosity. as i now understand, if i use an escaped wildcard
pattern, "git rm" will *automatically* (with no further guidance from
me, and no warning), operate recursively. so if, in the kernel source
tree, i ran:

  $ git rm \*.c

i would end up removing *all* 25,569 "*.c" files in the kernel source
repository.

  however, let's say i wanted to remove, recursively, all files with a
*precise* (non-globbed) name, such as "Makefile". so i, naively, run:

  $ git rm Makefile

guess what ... the lack of globbing means i remove only the single
Makefile at the top of the working directory.

  if that isn't an example of ridiculous, non-intuitive behaviour, i
don't know what is.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

Re: "git rm" seems to do recursive removal even without "-r"

[Robert P. J. Day]

On Sat, 7 Oct 2017, Theodore Ts'o wrote:

> On Sat, Oct 07, 2017 at 03:43:43PM -0400, Robert P. J. Day wrote:
> > >   -r
> > >   Recursively remove the contents of any directories that match
> > >   ``.
> > >
> > > or something.
> >
> >   it's been a long week, so take this in the spirit in which it is
> > intended ... i think the "git rm" command and its man page should be
> > printed out, run through a paper shredder, then set on fire. i can't
> > remember the last time i saw such a thoroughly badly-designed,
> > badly-documented and non-intuitive utility.
> >
> >   i'm going to go watch football now and try to forget this horror.
>
> It sounds like the real issue here is that you are interpreting
> "recursively" to mean "globbing".  Your original complaint seemed to
> be a surprise that "git rm book/\*.asc" would delete all of the files
> in the directory "book" that ended in .asc, even without the -r flag.
>
> That's because the operation of matching *.asc is considered
> "globbing".  Now if there were directories whose name ended in .asc,
> then they would only be deleted if the -r flag is given.  Deleting
> directories and their contents is what is considered "recursive
> removal".
>
> That's not particularly surprising to me as a long-time Unix/Linux
> user/developer, since that's how things work in Unix/Linux:
>
> % touch 1.d 2.d ; mkdir 3.d 4.d
> % /bin/ls
> 1.d  2.d  3.d  4.d
> % rm -r *.d
> % touch 1.d 2.d ; mkdir 3.d 4.d
> % rm *.d
> rm: cannot remove '3.d': Is a directory
> rm: cannot remove '4.d': Is a directory
>
> I'm going to guess that you don't come from a Unix background?

  yeah, that must be it, i'm a newbie at linux. let's go with that.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

Re: is there a truly compelling rationale for .git/info/exclude?

[brian m. carlson]

On Fri, Oct 06, 2017 at 01:39:16PM -0400, Robert P. J. Day wrote:
> On Fri, 6 Oct 2017, Junio C Hamano wrote:
> > This is primarily why .git/info/exclude exists.  A user who does not
> > use the same set of tools to work on different projects may not be
> > able to use ~/.gitconfig with core.excludesFile pointing at a single
> > place that applies to _all_ repositories the user touches.
> >
> > Also, core.excludesFile came a lot later than in-project and
> > in-repository exclude list, IIRC.
> >
> > Don't waste time by seeking a "compelling" reason.  A mere "this is
> > the most expedite way to gain convenience" back when something was
> > introduced could be an answer, and it is way too late to complain
> > about such a choice anyway.
> 
>   perfectly respectable answer ... it tells me that, between
> .gitignore files and core.excludesFile, there's not much left for
> .git/info/exclude to do, except in weird circumstances.

A place where I use it is in some Vim package repositories that I have
as submodules of my home directory.  The author of those repositories,
Tim Pope, explicitly does not exclude the helptags output.  I simply
ignore those files using .git/info/exclude.

Another case is when I install a plugin that lives below a our main
product repository at work.  I can simply exclude that plugin locally on
my system without the need to submit a change for merge.  I can later
remove those patterns if I like and run git clean -df to clean up.
-- 
brian m. carlson / brian with sandals: Houston, Texas, US
https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204


signature.asc
Description: PGP signature

Re: "git rm" seems to do recursive removal even without "-r"

[Theodore Ts'o]

On Sat, Oct 07, 2017 at 03:43:43PM -0400, Robert P. J. Day wrote:
> >   -r
> > Recursively remove the contents of any directories that match
> > ``.
> >
> > or something.
> 
>   it's been a long week, so take this in the spirit in which it is
> intended ... i think the "git rm" command and its man page should be
> printed out, run through a paper shredder, then set on fire. i can't
> remember the last time i saw such a thoroughly badly-designed,
> badly-documented and non-intuitive utility.
> 
>   i'm going to go watch football now and try to forget this horror.

It sounds like the real issue here is that you are interpreting
"recursively" to mean "globbing".  Your original complaint seemed to
be a surprise that "git rm book/\*.asc" would delete all of the files
in the directory "book" that ended in .asc, even without the -r flag.

That's because the operation of matching *.asc is considered
"globbing".  Now if there were directories whose name ended in .asc,
then they would only be deleted if the -r flag is given.  Deleting
directories and their contents is what is considered "recursive
removal".

That's not particularly surprising to me as a long-time Unix/Linux
user/developer, since that's how things work in Unix/Linux:

% touch 1.d 2.d ; mkdir 3.d 4.d
% /bin/ls
1.d  2.d  3.d  4.d
% rm -r *.d
% touch 1.d 2.d ; mkdir 3.d 4.d
% rm *.d
rm: cannot remove '3.d': Is a directory
rm: cannot remove '4.d': Is a directory

I'm going to guess that you don't come from a Unix background?

- Ted

Re: "git rm" seems to do recursive removal even without "-r"

[Robert P. J. Day]

On Sat, 7 Oct 2017, Jeff King wrote:

> On Sat, Oct 07, 2017 at 03:32:24PM -0400, Robert P. J. Day wrote:
>
> > > Nothing, because there is nothing to recurse in the pathspecs you've
> > > given.
> > >
> > > Try:
> > >
> > >   $ git rm drivers
> > >   fatal: not removing 'drivers' recursively without -r
> > >
> > > versus
> > >
> > >   $ git rm -r drivers
> > >   [...removes everything under drivers/...]
> >
> >   that is not what the man page is saying ... it refers to a "leading"
> > directory name, not simply a directory name. if it should say simply
> > "when a directory name is given", then it should be changed to say
> > that.
>
> It's the leading directory of the files that will be removed.
>
> An earlier part of the manpage (under ) also says:
>
>   A leading directory name (e.g. dir to remove dir/file1 and dir/file2)
>   can be given to remove all files in the directory, and recursively all
>   sub-directories, but this requires the -r option to be explicitly
>   given.
>
> which perhaps makes it more clear. Later in "-r", we say:
>
>-r
>Allow recursive removal when a leading directory name is given.
>
> which I guess is the part you're reading.  I think it would be equally
> correct to say "leading directory" or just "directory" there.
>
> Though really, you could give many such directory names, or even match
> them with a glob. So a more accurate description might be something
> like:
>
>   -r
>   Recursively remove the contents of any directories that match
>   ``.
>
> or something.

  it's been a long week, so take this in the spirit in which it is
intended ... i think the "git rm" command and its man page should be
printed out, run through a paper shredder, then set on fire. i can't
remember the last time i saw such a thoroughly badly-designed,
badly-documented and non-intuitive utility.

  i'm going to go watch football now and try to forget this horror.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

Re: "git rm" seems to do recursive removal even without "-r"

[Jeff King]

On Sat, Oct 07, 2017 at 03:32:24PM -0400, Robert P. J. Day wrote:

> > Nothing, because there is nothing to recurse in the pathspecs you've
> > given.
> >
> > Try:
> >
> >   $ git rm drivers
> >   fatal: not removing 'drivers' recursively without -r
> >
> > versus
> >
> >   $ git rm -r drivers
> >   [...removes everything under drivers/...]
> 
>   that is not what the man page is saying ... it refers to a "leading"
> directory name, not simply a directory name. if it should say simply
> "when a directory name is given", then it should be changed to say
> that.

It's the leading directory of the files that will be removed.

An earlier part of the manpage (under ) also says:

  A leading directory name (e.g. dir to remove dir/file1 and dir/file2)
  can be given to remove all files in the directory, and recursively all
  sub-directories, but this requires the -r option to be explicitly
  given.

which perhaps makes it more clear. Later in "-r", we say:

   -r
   Allow recursive removal when a leading directory name is given.

which I guess is the part you're reading.  I think it would be equally
correct to say "leading directory" or just "directory" there.

Though really, you could give many such directory names, or even match
them with a glob. So a more accurate description might be something
like:

  -r
Recursively remove the contents of any directories that match
``.

or something.

-Peff

Re: [PATCH v2 1/5] test-list-objects: List a subset of object ids

[Jeff King]

On Sat, Oct 07, 2017 at 03:12:08PM -0400, Derrick Stolee wrote:

> In my local copy, I added a test to p4211-line-log.sh that runs "git log
> --raw -r" and tested it on three copies of the Linux repo. In order, they
> have 1 packfile (0 loose), 24 packfiles (0 loose), and 23 packfiles
> (~324,000 loose).
> 
> 4211.6: git log --raw -r  43.34(42.62+0.65)   40.47(40.16+0.27)  -6.6%
> 4211.6: git log --raw -r  88.77(86.54+2.12)   82.44(81.87+0.52)  -7.1%
> 4211.6: git log --raw -r 108.86(103.97+4.81) 103.92(100.63+3.19) -4.5%
> 
> We have moderate performance gains for this command, despite the command
> doing many more things than just checking abbreviations.

Yeah, while it's less exciting than seeing the 90% numbers for a
micro-benchmark, I think this represents real-world gains (and 5-7% is
nothing to sneeze at).

You might also try adding "--format=%h" or --oneline to your invocation,
which would compute abbreviations for each commit (making your workload
more abbrev-heavy and possibly showing off the difference more).

I also think "-r" isn't doing anything. Recursive diffs are the default
for the "log" porcelain (even for --raw).

> I plan to re-roll my patch on Monday including the following feedback items:
> 
> * Remove test-list-objects and test-abbrev in favor of a new "git log"
>   performance test.
> 
> * Fix binary search overflow error.
> 
> * Check response from open_pack_index(p) in find_abbrev_len_for_pack().
>   I plan to return without failure on non-zero result, which results in
>   no failure on a bad pack and the abbreviation length will be the
>   minimum required among all valid packs. (Thanks Stefan!)

That all sounds reasonable to me.

> - Teach 'cat-file' to --batch-check='%(objectsize:short)'. (Peff already
>   included a patch, perhaps that could be reviewed separately.)

I think I'll let it lie in the list archive for now unless somebody has
a real use case for it (though I'm tempted to add it purely for
completionism, since it's so easy).

-Peff

Re: "git rm" seems to do recursive removal even without "-r"

[Robert P. J. Day]

On Sat, 7 Oct 2017, Jeff King wrote:

> On Sat, Oct 07, 2017 at 03:12:01PM -0400, Robert P. J. Day wrote:
>
> >   ok, in that case, can you give me an example where "-r" makes a
> > difference, given that the man page refers to "a leading directory
> > name being given"? let's use as an example the linux kernel source,
> > where there are a *ton* of files named "Makefile" under the drivers/
> > directory.
> >
> >   should there be a difference between:
> >
> >   $ git rm drivers/Makefile
> >   $ git rm -r drivers/Makefile
> >
> > clearly, i have a "leading directory name" in both examples above ...
> > what should happen differently?
>
> Nothing, because there is nothing to recurse in the pathspecs you've
> given.
>
> Try:
>
>   $ git rm drivers
>   fatal: not removing 'drivers' recursively without -r
>
> versus
>
>   $ git rm -r drivers
>   [...removes everything under drivers/...]

  that is not what the man page is saying ... it refers to a "leading"
directory name, not simply a directory name. if it should say simply
"when a directory name is given", then it should be changed to say
that.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

Re: "git rm" seems to do recursive removal even without "-r"

[Jeff King]

On Sat, Oct 07, 2017 at 03:12:01PM -0400, Robert P. J. Day wrote:

>   ok, in that case, can you give me an example where "-r" makes a
> difference, given that the man page refers to "a leading directory
> name being given"? let's use as an example the linux kernel source,
> where there are a *ton* of files named "Makefile" under the drivers/
> directory.
> 
>   should there be a difference between:
> 
>   $ git rm drivers/Makefile
>   $ git rm -r drivers/Makefile
> 
> clearly, i have a "leading directory name" in both examples above ...
> what should happen differently?

Nothing, because there is nothing to recurse in the pathspecs you've
given.

Try:

  $ git rm drivers
  fatal: not removing 'drivers' recursively without -r

versus

  $ git rm -r drivers
  [...removes everything under drivers/...]

-Peff

Re: [PATCH v2 1/5] test-list-objects: List a subset of object ids

[Derrick Stolee]

On 10/6/2017 10:11 AM, Jeff King wrote:

On Thu, Oct 05, 2017 at 08:39:42AM -0400, Derrick Stolee wrote:

I'll run some perf numbers for these commands you recommend, and also see if
I can replicate some of the pain points that triggered this change using the
Linux repo.


Thanks!

-Peff



In my local copy, I added a test to p4211-line-log.sh that runs "git log 
--raw -r" and tested it on three copies of the Linux repo. In order, 
they have 1 packfile (0 loose), 24 packfiles (0 loose), and 23 packfiles 
(~324,000 loose).


4211.6: git log --raw -r  43.34(42.62+0.65)   40.47(40.16+0.27)  -6.6%
4211.6: git log --raw -r  88.77(86.54+2.12)   82.44(81.87+0.52)  -7.1%
4211.6: git log --raw -r 108.86(103.97+4.81) 103.92(100.63+3.19) -4.5%

We have moderate performance gains for this command, despite the command 
doing many more things than just checking abbreviations.


I plan to re-roll my patch on Monday including the following feedback items:

* Remove test-list-objects and test-abbrev in favor of a new "git log"
  performance test.

* Fix binary search overflow error.

* Check response from open_pack_index(p) in find_abbrev_len_for_pack().
  I plan to return without failure on non-zero result, which results in
  no failure on a bad pack and the abbreviation length will be the
  minimum required among all valid packs. (Thanks Stefan!)

I made note of a few things, but will not include them in my re-roll. 
I'll revisit them later if they are valuable:


- nth_packed_object_sha1() could be simplified in
  find_abbrev_len_for_pack().

- Teach 'cat-file' to --batch-check='%(objectsize:short)'. (Peff already
  included a patch, perhaps that could be reviewed separately.)

- Ramsay caught my lack of "static" in test-list-objects.c, but that
  file will be removed in the next patch. I'll make sure to use "static"
  in the future.

I'm not re-rolling immediately to allow for some extra review over the 
weekend, if anyone is so inclined.


Thanks,
-Stolee

Re: "git rm" seems to do recursive removal even without "-r"

[Robert P. J. Day]

On Sat, 7 Oct 2017, Todd Zullinger wrote:

> Robert P. J. Day wrote:
> >
> >  was just testing variations of "git rm", and man page claims:
> >
> >  -r Allow recursive removal when a leading directory name is given.
> >
> > i tested this on the "pro git" book repo, which contains a top-level "book/"
> > directory, and quite a number of "*.asc" files in various subdirectories one
> > or more levels down. i ran:
> >
> >  $ git rm book/\*.asc
> >
> > and it certainly seemed to delete *all* "*.asc" files no matter where they
> > were under book/, even without the "-r" option.
> >
> >  am i misunderstanding something?
>
> By shell-escaping the *, you're letting git perform the file glob.  The
> DISCUSSION section of git-rm(1) says "File globbing matches across directory
> boundaries."
>
> # With bash performing file globbing
> $ git rm -n Documentation/*.txt | wc -l
> 199
>
> # With git performing file globbing
> $ git rm -n Documentation/\*.txt | wc -l
> 578

  ok, in that case, can you give me an example where "-r" makes a
difference, given that the man page refers to "a leading directory
name being given"? let's use as an example the linux kernel source,
where there are a *ton* of files named "Makefile" under the drivers/
directory.

  should there be a difference between:

  $ git rm drivers/Makefile
  $ git rm -r drivers/Makefile

clearly, i have a "leading directory name" in both examples above ...
what should happen differently?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

Re: "git rm" seems to do recursive removal even without "-r"

[Todd Zullinger]

Robert P. J. Day wrote:


 was just testing variations of "git rm", and man page claims:

 -r 
Allow recursive removal when a leading directory name is given.


i tested this on the "pro git" book repo, which contains a top-level 
"book/" directory, and quite a number of "*.asc" files in various 
subdirectories one or more levels down. i ran:


 $ git rm book/\*.asc

and it certainly seemed to delete *all* "*.asc" files no matter where 
they were under book/, even without the "-r" option.


 am i misunderstanding something?


By shell-escaping the *, you're letting git perform the file glob.  
The DISCUSSION section of git-rm(1) says "File globbing matches across 
directory boundaries."


# With bash performing file globbing
$ git rm -n Documentation/*.txt | wc -l
199

# With git performing file globbing
$ git rm -n Documentation/\*.txt | wc -l
578

--
Todd
~~
Whenever you find yourself on the side of the majority, it is time to
pause and reflect.
   -- Mark Twain

"git rm" seems to do recursive removal even without "-r"

[Robert P. J. Day]

  was just testing variations of "git rm", and man page claims:

  -r
 Allow recursive removal when a leading directory name is given.

i tested this on the "pro git" book repo, which contains a top-level
"book/" directory, and quite a number of "*.asc" files in various
subdirectories one or more levels down. i ran:

  $ git rm book/\*.asc

and it certainly seemed to delete *all* "*.asc" files no matter where
they were under book/, even without the "-r" option.

  am i misunderstanding something?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

hello

[Myriama]

-- 
Greetings
my name is miss myriam
No Matter the Good and bad that we face
Everyday in our life there is still a Space of love in our Heart.
and i count it a Great Privileged in Communicating with someone who
will Truly be honest with me

i need you as a business partner or a
friend who will help me to invest my fund in his company or country.
please reply me back

Yours faithful,
Myriam Dady Omar Yaman
thanksa

I expect your urgent communication.

[Mr. Abel Kaba]

-- 
Dear Friend,

Good day. I am Mr. Abel Kaba. I am working with one of the prime banks
in Burkina Faso. I have decided to contact you for a financial
transaction which values $14,500,000.00 (Fourteen Million Five Hundred
Thousand USA Dollars). This is an abandoned fund that belongs to a
late foreign customer of our bank. I want a foreign account where the
bank will transfer this fund.

I was very fortunate to come across the deceased customer's security
file; during documentation of old and abandoned customers files for an
official re-documentation and audit of the year 2017.

If you are really sure of your trustworthiness, accountability and
confidentiality over this transaction, contact me urgently. I will let
you know the next step and procedure to follow in order to finalize
this transaction successfully.

I expect your urgent communication.

Yours sincerely,
Mr. Abel Kaba.

Re: [RFC PATCH 2/8] commit: move code to update HEAD to libgit

[Junio C Hamano]

Phillip Wood  writes:

> From: Phillip Wood 
>
> Signed-off-by: Phillip Wood 
> ---

This seems to do a lot more than just moving code, most notably, it
uses setenv() to affect what happens in any subprocesses we may
spawn, and it is unclear if it was verified that this patch is free
of unwanted consequences due to that change (and any others I may
have missed while reading this patch, if any).

I suspect that it would be sufficient to make update_head() helper
function take the reflog action message as another parameter
instead to fix the above, but there may be other reasons why you
chose to do it this way---I cannot read it in your empty log
message, though.

I will not give line-by-line style nitpick but in general we do not
leave a SP between function name and the open parenthesis that
starts its argument list.  New code in this patch seems to use
mixture of styles.

> diff --git a/builtin/commit.c b/builtin/commit.c
> index 
> 0b8c1ef6f57cfed328d12255e6834adb4bda4137..497778ba2c02afdd4a337969a27ca781e8389040
>  100644
> --- a/builtin/commit.c
> +++ b/builtin/commit.c
> @@ -1578,13 +1578,11 @@ int cmd_commit(int argc, const char **argv, const 
> char *prefix)
>   struct strbuf sb = STRBUF_INIT;
>   struct strbuf author_ident = STRBUF_INIT;
>   const char *index_file, *reflog_msg;
> - char *nl;
>   struct object_id oid;
>   struct commit_list *parents = NULL;
>   struct stat statbuf;
>   struct commit *current_head = NULL;
>   struct commit_extra_header *extra = NULL;
> - struct ref_transaction *transaction;
>   struct strbuf err = STRBUF_INIT;
>  
>   if (argc == 2 && !strcmp(argv[1], "-h"))
> @@ -1625,10 +1623,10 @@ int cmd_commit(int argc, const char **argv, const 
> char *prefix)
>   reflog_msg = getenv("GIT_REFLOG_ACTION");
>   if (!current_head) {
>   if (!reflog_msg)
> - reflog_msg = "commit (initial)";
> + setenv ("GIT_REFLOG_ACTION", "commit (initial)", 1);
>   } else if (amend) {
>   if (!reflog_msg)
> - reflog_msg = "commit (amend)";
> + setenv("GIT_REFLOG_ACTION", "commit (amend)", 1);
>   parents = copy_commit_list(current_head->parents);
>   } else if (whence == FROM_MERGE) {
>   struct strbuf m = STRBUF_INIT;
> @@ -1637,7 +1635,7 @@ int cmd_commit(int argc, const char **argv, const char 
> *prefix)
>   struct commit_list **pptr = 
>  
>   if (!reflog_msg)
> - reflog_msg = "commit (merge)";
> + setenv("GIT_REFLOG_ACTION", "commit (merge)", 1);
>   pptr = commit_list_append(current_head, pptr);
>   fp = xfopen(git_path_merge_head(), "r");
>   while (strbuf_getline_lf(, fp) != EOF) {
> @@ -1660,9 +1658,9 @@ int cmd_commit(int argc, const char **argv, const char 
> *prefix)
>   parents = reduce_heads(parents);
>   } else {
>   if (!reflog_msg)
> - reflog_msg = (whence == FROM_CHERRY_PICK)
> - ? "commit (cherry-pick)"
> - : "commit";
> + setenv("GIT_REFLOG_ACTION", (whence == FROM_CHERRY_PICK)
> + ? "commit (cherry-pick)"
> + : "commit", 1);
>   commit_list_insert(current_head, );
>   }
>  
> @@ -1707,25 +1705,10 @@ int cmd_commit(int argc, const char **argv, const 
> char *prefix)
>   strbuf_release(_ident);
>   free_commit_extra_headers(extra);
>  
> - nl = strchr(sb.buf, '\n');
> - if (nl)
> - strbuf_setlen(, nl + 1 - sb.buf);
> - else
> - strbuf_addch(, '\n');
> - strbuf_insert(, 0, reflog_msg, strlen(reflog_msg));
> - strbuf_insert(, strlen(reflog_msg), ": ", 2);
> -
> - transaction = ref_transaction_begin();
> - if (!transaction ||
> - ref_transaction_update(transaction, "HEAD", oid.hash,
> -current_head
> -? current_head->object.oid.hash : null_sha1,
> -0, sb.buf, ) ||
> - ref_transaction_commit(transaction, )) {
> + if (update_head (current_head, , , )) {
>   rollback_index_files();
>   die("%s", err.buf);
>   }
> - ref_transaction_free(transaction);
>  
>   unlink(git_path_cherry_pick_head());
>   unlink(git_path_revert_head());
> diff --git a/sequencer.c b/sequencer.c
> index 
> 319208afb3de36c97b6c62d4ecf6e641245e7a54..917ad4a16216b30adb2c2c9650217926d8db8ba7
>  100644
> --- a/sequencer.c
> +++ b/sequencer.c
> @@ -1,10 +1,10 @@
>  #include "cache.h"
>  #include "config.h"
>  #include "lockfile.h"
> -#include "sequencer.h"
>  #include "dir.h"
>  #include 

Re: [PATCH v7 0/3] Incremental rewrite of git-submodules

[Eric Sunshine]

On Sat, Oct 7, 2017 at 4:51 AM, Junio C Hamano  wrote:
> FWIW, the previous one is at
> https://public-inbox.org/git/20170929094453.4499-1-pc44...@gmail.com
> Hope that helps ;-)

Thanks, it does help.

Having scanned discussions of previous versions, I see that some of my
comments do indeed overlap (and sometimes are at odds) with comments
from other reviewers.

Re: [PATCH v7 0/3] Incremental rewrite of git-submodules

[Junio C Hamano]

Prathamesh Chavan  writes:

> Changes in v7:

FWIW, the previous one is at

https://public-inbox.org/git/20170929094453.4499-1-pc44...@gmail.com

Alternatively, the References link can be followed back from the
cover letter to go back to quite an early iteration of the series.

Hope that helps ;-)