* Re: [PATCH 2/2] config: add include directive
From: Junio C Hamano @ 2012-02-06 22:39 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20120206095404.GB4300@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> +Includes
> +~~~~~~~~
> +
> +You can include one config file from another by setting the special
> +`include.path` variable to the name of the file to be included. The
> +included file is expanded immediately, as if its contents had been
> +found at the location of the include directive. If the value of the
> +`include.path` variable is a relative path, the path is considered to be
> +relative to the configuration file in which the include directive was
> +found. See below for examples.
If the file referenced by this directive does not exist, what should
happen? Should it be signalled as an error? Should it stop the whole
calling process with die()?
I think "die() when we are honoring the include, ignore when we are not"
would be a good way to handle this, as it allows us to catch mistakes
while allowing the user to fix broken configuration files using "git
config --unset include.path", but I may be overlooking something.
^ permalink raw reply
* Re: [PATCH 1/2] docs: add a basic description of the config API
From: Junio C Hamano @ 2012-02-06 22:31 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20120206095346.GA4300@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> This wasn't documented at all; this is pretty bare-bones,
> but it should at least give new git hackers a basic idea of
> how the reading side works.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> Documentation/technical/api-config.txt | 101 ++++++++++++++++++++++++++++++++
> 1 files changed, 101 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/technical/api-config.txt
>
> diff --git a/Documentation/technical/api-config.txt b/Documentation/technical/api-config.txt
> new file mode 100644
> index 0000000..f428c5c
> --- /dev/null
> +++ b/Documentation/technical/api-config.txt
> @@ -0,0 +1,101 @@
> +config API
> +==========
> +
> +The config API gives callers a way to access git configuration files
> +(and files which have the same syntax). See linkgit:git-config[1] for a
> +discussion of the config file syntax.
> +
> +General Usage
> +-------------
> +
> +Config files are parsed linearly, and each variable found is passed to a
> +caller-provided callback function. The callback function is responsible
> +for any actions to be taken on the config option, and is free to ignore
> +some options (it is not uncommon for the configuration to be parsed
> +several times during the run of a git program, with different callbacks
> +picking out different variables useful to themselves).
It woud be easeier to read if you stopped the sentence after "some
options" and made the "It is not uncommon..." a first-class sentence
outside the parentheses.
> +A config callback function takes three parameters:
> +
> +- the name of the parsed variable. This is in canonical "flat" form: the
> + section, subsection, and variable segments will be separated by dots,
> + and the section and variable segments will be all lowercase. E.g.,
> + `core.ignorecase`, `diff.SomeType.textconv`.
> +
> +- the value of the found variable, as a string. If the variable had no
> + value specified, the value will be NULL (typically this means it
> + should be interpreted as boolean true).
> +
> +- a void pointer passed in by the caller of the config API; this can
> + contain callback-specific data
> +
> +A config callback should return 0 for success, or -1 if the variable
> +could not be parsed properly.
This matches what I have always thought, but I think I recently saw a
series that adds callbacks that return 1 to mean "I have understood this
variable, so callers should not look at it any more". It felt wrong, but
I did not find anything in the config.c API framework to prvent such a
local calling convention.
> +Basic Config Querying
> +---------------------
> +
> +Most programs will simply want to look up variables in all config files
> +that git knows about, using the normal precedence rules. To do this,
> +call `git_config` with a callback function and void data pointer.
> +
> +`git_config` will read all config sources in order of increasing
> +priority. Thus a callback should typically overwrite previously-seen
> +entries with new ones (e.g., if both the user-wide `~/.gitconfig` and
> +repo-specific `.git/config` contain `color.ui`, the config machinery
> +will first feed the user-wide one to the callback, and then the
> +repo-specific one; by overwriting, the higher-priority repo-specific
> +value is left at the end).
> +
> +There is a special version of `git_config` called `git_config_early`
> +that takes an additional parameter to specify the repository config.
> +This should be used early in a git program when the repository location
> +has not yet been determined (and calling the usual lazy-evaluation
> +lookup rules would yield an incorrect location).
Do you want to say somethink like "Ordinary programs should not have to
worry about git_config_early()"? Differently put, if you are learning the
config API by reading this document and cannot tell which one you should
be calling, you are way too inexperienced to call git_config_early() and
you would always want to call git_config()?
^ permalink raw reply
* Re: git describe relative to a given tag pattern
From: Adam Mercer @ 2012-02-06 22:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhaz362b8.fsf@alter.siamese.dyndns.org>
On Mon, Feb 6, 2012 at 16:10, Junio C Hamano <gitster@pobox.com> wrote:
> Perhaps Git is correct and your HEAD is not a descendant of any tag whose
> name matches the pattern "lal-v*".
Thanks you're right, the tags I was trying to match are on a different
branch. Back to the drawing board for this script.
Cheers
Adam
^ permalink raw reply
* Re: git describe relative to a given tag pattern
From: Junio C Hamano @ 2012-02-06 22:10 UTC (permalink / raw)
To: Adam Mercer; +Cc: git
In-Reply-To: <CA+mfgz0VB9qMHHtoT76zCOiUaH=8egdMDrneQVRBug2waQsGAg@mail.gmail.com>
Adam Mercer <ramercer@gmail.com> writes:
> $ git describe --match=lal-v* HEAD
> fatal: No tags can describe 'cee13cbb25d0fa38f6e3bc6622bc751ebf35d2f0'.
Perhaps Git is correct and your HEAD is not a descendant of any tag whose
name matches the pattern "lal-v*".
Here is how people can mimic the situation:
$ git checkout v1.7.6~20
$ git describe --match='v1.7.*' HEAD
v1.7.6-rc0-3-g6c92972
$ git describe --match='v1.7.[7-9]*' HEAD
fatal: No tags can describe '6c92972d7f5ab247a8cab5e4b88cb281bf201970'.
Try --always, or create some tags.
^ permalink raw reply
* Re: [bug] blame duplicates trailing ">" in mailmapped emails
From: Junio C Hamano @ 2012-02-06 22:04 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Jeff King, Jonathan Nieder, git, SZEDER Gábor
In-Reply-To: <CAMP44s1RN+_UK9rAk_m9Z=YaJJtwHLyiCu2stMMDEWqZN9260g@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> This subject doesn't explain the *purpose* of the patch: always return
> a plain mail address from map_user()
That would be a much better subject.
> I think the immediate problem should be here:
>
> Currently 'git blame -e' would add an extra '>' if map_user() returns
> true, which would end up as '<foo@bar.com>>'. This is because
> map_user() sometimes modifies, the mail string, but sometimes not. So
> let's always modify it.
That is just a symptom. People who reached this commit by digging the
history of mailmap.c would need to see the *cause* of the symptom
described in the light of how the API is designed to be used. In other
words, "the code after the update has to be this way because these are the
i/o constraints this API has". "Otherwise you would see this breakage for
example" is merely a supporting material.
^ permalink raw reply
* git describe relative to a given tag pattern
From: Adam Mercer @ 2012-02-06 22:03 UTC (permalink / raw)
To: git
Hi
I'm trying to use git describe to describe the current status of my
tree with respect a given tag, or more specifically the latest tag
matching a specific pattern.
My repository has the following tags:
$ git tag -l lal-v*
lal-v6.6.0
lal-v6.6.0rc1
lal-v6.6.0rc2
lal-v6.6.1
lal-v6.6.2
$
And I want git describe to use the latest of these tags, so looking at
the git describe man page it seems that the --match option can allow
me to specify a pattern. This, however, doesn't seem to work:
$ git describe --match=lal-v* HEAD
fatal: No tags can describe 'cee13cbb25d0fa38f6e3bc6622bc751ebf35d2f0'.
Try --always, or create some tags.
$
quoting the pattern has no effect, what am I doing wrong here?
Cheers
Adam
PS: I'm using git-1.7.9
^ permalink raw reply
* Re: [PATCH 2/4] commit: introduce a config key to allow as-is commit with i-t-a entries
From: Junio C Hamano @ 2012-02-06 21:48 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Nguyễn Thái Ngọc Duy, git
In-Reply-To: <20120206211321.GA2949@burratino>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Junio C Hamano wrote:
>
>> IIRC, the original motivation of intent-to-add "add -N" was in response to
>> users who curse Git because they often forget to add new files before
>> committing, and they wanted to say "Here I have a new file, it is not
>> complete yet, but I do not want it left out of the commit. While my memory
>> is fresh, let me tell Git to keep an eye on it, so that it can remind me
>> if I forget to add the final contents."
>
> I agree with everything up to here. But I believe these people were
> _already_ paying attention to "git status" output from the commandline
> and in the editor window when they run "git commit", to notice other
> changes they forgot to add, too. I don't think this series would
> inconvenience them.
That means that you are willing to declare that nobody will ever need
"please remind me lest I forget". Not just the original requestor of the
"add -N" feature, but absolutely nobody else.
Then the deprecation sequence presented in this series is fine. The
wording to sell that "removal of misfeature" to the end user community
needs to be well thought out, though.
^ permalink raw reply
* Re: [PATCH 3/3] t: mailmap: add simple name translation test
From: Felipe Contreras @ 2012-02-06 21:32 UTC (permalink / raw)
To: Jeff King
Cc: Jonathan Nieder, git, Junio C Hamano, Marius Storm-Olsen,
Jim Meyering
In-Reply-To: <20120204234237.GB1366@sigill.intra.peff.net>
On Sun, Feb 5, 2012 at 1:42 AM, Jeff King <peff@peff.net> wrote:
> On Sun, Feb 05, 2012 at 12:19:53AM +0200, Felipe Contreras wrote:
>
>> > Thanks. I guess you think I'm stupid. I have no idea how I can
>> > correct that assumption and help you to actually work with me to make
>> > the code better. :/
>>
>> You mean the commit message, you haven't made any comment about the code.
>>
>> If you want to know why I had to modify those test assertions, you
>> really need to look at the code. In essence; all of them use the same
>> repo, and obviously adding a new commit message changes the output of
>> the commands.
>
> Then say that in the commit message.
I believe that's overkill. If somebody needs an explanation, it's
because they are not familiar with the code being modified, and
introducing people to some code in each and every patch that modifies
it definitely seems like overkill to me. There is not even such
introduction in the code itself for this test, and in most of git's
code, presumably because we are following the principle of having
self-documented code.
If you look at the code, it would become obvious why so many hunks are
introduced, in fact, if you look closely at the patch you can see it
as well: look for strings related to CTO <cto@company.xx>.
> Looking at this series, I wonder if the tests should simply be squashed
> into the bugfix patch, which might make what is going on more obvious.
Because it's a logically independent change?
There's _nothing_ that prevents this patch from being applied to
master *right now*. Of course, it would conflict, because it depends
on the 'git blame -e' tests, but if you solve that conflict by just
removing that hunk, it would apply and run just fine, and it would
detect regressions orthogonal from my other proposed patches.
> Keep in mind that as reviewers now, we read the whole series. But in a
> year, as "git log" users, we may see the commits in isolation.
Sure, and this patch by itself is good; it's adding a missing test
(even if you ignore the 'git blame -e' part).
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: [RFC/PATCH] add update to branch support for "floating submodules"
From: Jens Lehmann @ 2012-02-06 21:32 UTC (permalink / raw)
To: Phil Hord; +Cc: Junio C Hamano, Leif Gruenwoldt, git
In-Reply-To: <CABURp0rt=LcjMfDU61m0de-gLpX1a3x3vhb0zVxCbceSvD9jFw@mail.gmail.com>
Am 06.02.2012 18:31, schrieb Phil Hord:
> On Wed, Feb 1, 2012 at 5:37 PM, Jens Lehmann <Jens.Lehmann@web.de> wrote:
>> Hmm, I really think the fact that submodules are unaware that they
>> are part of a superproject is a feature. I'd prefer seeing that kind
>> of problem being tackled by the CI server and/or user education. Or
>> maybe a pre-commit hook which issues a warning in that case?
>
> I agree that submodule isolation is a feature essential to the
> architecture of git and the submodules implementation. But it is also
> a limitation, not just of this example. A pre-commit hook is a nice
> idea, but it doesn't help 'git status' (which is the standard go-to
> answer point for "where am I").
Yes, this feature also is a limitation. To put it in other words: I want
each submodule to be a full fledged repo of its own. IMO it must always
be possible to just clone a submodule without any superproject and run
any git command in it. And the other way around: each superproject must
be usable as a submodule in another superproject. That makes adding some
kind of "superproject awareness" in a sane way rather difficult, as a
repo can't say "I live in a superproject" or "I am the topmost project".
> This has me thinking more about recursing siblings now, though. I find
> myself typing something like this quite a lot:
> git submodule foreach 'git grep "someFunction" || :'
There was an attempt to teach git grep the --recurse-submodules option,
but unfortunately it looks like this didn't lead anywhere so far.
> Or worse (in that the UI is more unwieldy):
> git submodule foreach 'git log --oneline "-SsomeFunction" || :'
This could also be done by teaching git log the --recurse-submodules
option. Me thinks in the long run a lot of git commands should learn
that option to make it easy to optionally include submodules in
whatever they are doing. But my focus is on recursive checkout for the
next time, so I have no idea when I find some time to do that.
> But what I want is this:
> git --git-dir=${TOP}/../.git grep --recurse-submodules "someFunction"
>
> But not really, because I am lazy and that is too much typing.
> git grep --include-siblings "someFunction"
>
> Maybe I can add a "sib" macro to get this:
> git sib grep "someFunction"
And from what you where saying earlier a "git sib status" would be nice
too? What about using alias commands for that functionality? They could
point to a script which searches the topmost repo and calls "git submodule
foreach 'git <command> "$@" || :'" from there ...
^ permalink raw reply
* Re: [PATCH 3/3] t: mailmap: add simple name translation test
From: Felipe Contreras @ 2012-02-06 21:18 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, Junio C Hamano, Marius Storm-Olsen, Jim Meyering
In-Reply-To: <20120205061738.GB1870@burratino>
On Sun, Feb 5, 2012 at 8:17 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Felipe Contreras wrote:
>
>> You mean the commit message, you haven't made any comment about the code.
>
> No, for this patch, more important than the absence of any explanation
> in the commit message (which is also important) is the code change
> that seems unnecessarily invasive.
It only seems that way if you are not familiar with the code, and you
assume the worst.
Feel free propose an alternative change. You would find there's no
better way to simplify those changes.
Here's a tip: look at the previous change "CTO <cto@company.xx>", and
see how it's right next to each an every of the hunks introduced in
this patch.
> You've already demonstrated that I do not have the right communication
> style to explain such things to you and work towards a fix that
> addresses both our concerns. So I give up.
You are assuming your concerns are valid without actually looking at the code.
> I'll just give my
> feedback on patches that concern code I care about and an explanation
> for the sake of others on the list that are better able to interact
> with you. I am willing to work with or answer questions from anyone
> including you, though.
Your feedback is most certainly welcome, but you shouldn't assume you
are always right. There's nothing wrong with disagreeing, and in this
case I most definitely disagree, and there's nothing wrong with that.
--
Felipe Contreras
^ permalink raw reply
* Re: Git performance results on a large repository
From: Sam Vilain @ 2012-02-06 21:17 UTC (permalink / raw)
To: Joshua Redstone; +Cc: Nguyen Thai Ngoc Duy, git@vger.kernel.org
In-Reply-To: <243C23AF01622E49BEA3F28617DBF0AD5912CA85@SC-MBX02-5.TheFacebook.com>
> Sam Vilain: Thanks for the pointer, i didn't realize that
> fast-import was bi-directional. I used it for generating the
> synthetic repo. Will look into using it the other way around.
> Though that still won't speed up things like git-blame,
> presumably?
It could, because blame is an operation which primarily works on
the source history with little reference to the working copy. Of
course this will depend on the quality of the implementation
server-side. Blame should suit distribution over a cluster, as
it is mostly involved with scanning candidate revisions for
string matches which is the compute intensive part. Coming up
with candidate revisions has its own cost and can probably also
be distributed, but just working on the lowest loop level might
be a good place to start.
What it doesn't help with is local filesystem operations. For
this I think a different approach is required, if you can tie
into fam or a similar inode change notification system, then you
should be able to avoid the entire recursive stat on 'git
status'. I'm not sure --assume-unchanged on its own is a good
idea, you could easily miss things. Those stat's are useful.
Making the index able to hold just changes to the checked-out
tree, as others have mentioned, would also save the massive reads
and writes you've identified. Perhaps a more high performance
back-end could be developed.
> The sparse-checkout issue you mention is a good one.
It's actually been on the table since at least GitTogether 2008;
there's been some design discussion on it and I think it's just
one of those features which doesn't have enough demand yet for it
to be built. It keeps coming up but not from anyone with the
inclination or resources to make it happen. There is a protocol
issue, but this should be able to fit into the current extension
system.
> There is a good question of how to support quick checkout,
> branch switching, clone, push and so forth.
Sure. It will be much more network intensive as you are
replacing the part which normally has a very fast link through
the buffercache to pack files etc. A hybrid approach is also
possible, where objects are fetched individually via fast-import
and cached in a local .git repo. And I have a hunch that LZOP
compression of the stream may also be a win, but as with all of
these ideas, it would be after profiling identifies it as a choke point
than just because it sounds good.
> I'll look into the approaches you suggest. One consideration
> is coming up with a high-leverage approach - i.e. not doing
> heavy dev work if we can avoid it.
Right. You don't actually need to port the whole of git to Hadoop
initially, to begin with it can just pass through all commands to a
server-side git fast-import process. When you find specific operations
which are slow then these specific operations can be implemented using a
Hadoop back-end, and the rest backed to the standard git. If done using
a useful plug-in system, these systems could be accepted by the core
project as an enterprise scaling option.
This could let you get going with the knowledge that the scaling option
is there should it come out.
> On the other hand, it would be nice if we (including the entire
> community:) ) improve git in areas that others that share
> similar issues benefit from as well.
Like I say, a lot of people have run into this already...
HTH,
Sam
^ permalink raw reply
* Re: [PATCH 2/4] commit: introduce a config key to allow as-is commit with i-t-a entries
From: Jonathan Nieder @ 2012-02-06 21:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nguyễn Thái Ngọc Duy, git
In-Reply-To: <7vwr7z653f.fsf@alter.siamese.dyndns.org>
Hi,
Junio C Hamano wrote:
> IIRC, the original motivation of intent-to-add "add -N" was in response to
> users who curse Git because they often forget to add new files before
> committing, and they wanted to say "Here I have a new file, it is not
> complete yet, but I do not want it left out of the commit. While my memory
> is fresh, let me tell Git to keep an eye on it, so that it can remind me
> if I forget to add the final contents."
I agree with everything up to here. But I believe these people were
_already_ paying attention to "git status" output from the commandline
and in the editor window when they run "git commit", to notice other
changes they forgot to add, too. I don't think this series would
inconvenience them.
Hoping I can find time to look over the other changes soon.
Thanks,
Jonathan
^ permalink raw reply
* Re: [PATCH 2/4] commit: introduce a config key to allow as-is commit with i-t-a entries
From: Junio C Hamano @ 2012-02-06 21:10 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Jonathan Nieder
In-Reply-To: <1328525855-2547-3-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
> index 9c1d395..ec548ea 100644
> --- a/Documentation/git-add.txt
> +++ b/Documentation/git-add.txt
> @@ -123,8 +123,16 @@ subdirectories.
> Record only the fact that the path will be added later. An entry
> for the path is placed in the index with no content. This is
> useful for, among other things, showing the unstaged content of
> - such files with `git diff` and committing them with `git commit
> - -a`.
> + such files with `git diff`.
> ++
> +Paths added with this option have intent-to-add flag in index. The
> +flag is removed once real content is added or updated. By default you
> +cannot commit the index as-is from until this flag is removed from all
> +entries (i.e. all entries have real content). See commit.ignoreIntentToAdd
> +regardless the flag.
> ++
> +Committing with `git commit -a` or with selected paths works
> +regardless the config key and the flag.
It still is not clear to me how best to sell this change to the end-user
community.
IIRC, the original motivation of intent-to-add "add -N" was in response to
users who curse Git because they often forget to add new files before
committing, and they wanted to say "Here I have a new file, it is not
complete yet, but I do not want it left out of the commit. While my memory
is fresh, let me tell Git to keep an eye on it, so that it can remind me
if I forget to add the final contents." For them, the current "did you
forget to add them? If so tell me the final contents for at least the
paths you will be changing with this commit" error was a perfect safety
solution.
It turned out that the benefits described we see above in the context,
"This is useful, among other things, ...", were of more value, and for
these use cases, i-t-a entries ceased to mean "I may forget, so I am
telling you now, please remind me when I say commit." And "did you
forget?" error is hinderance for them.
But does that mean nobody will ever need "please remind me lest I forget"?
Just the original requestor of the "add -N" feature may still be using
git, but more importantly, isn't it the case that those who have been
using it merely for the other side effect (e.g. 'git diff') sometimes want
the "please remind me" safety?
I suspect that some among 1 million Git users would want the "please
remind me", so a solution with configuration variable without command line
override is not ideal (command line without any configurability is fine as
long as we have a good default).
I am beginning to think "safety by default, which can be turned off by
learned users, but still can be turned on on demand" may be a lot easier
to sell this. That is:
- commit.ignoreIntentToAdd defaults to `false`; the default will never
change. The users can set it to `true`.
- "commit --ignore-intent-to-add" can be used without setting the
configuration or to defeat an explicit `false`, for a one-shot request.
- "commit --honor-intent-to-add" can be used to defeat an explicit
`true`, for a one-shot request.
The third one is a bit funny, as it is a way to bring back safety when the
user earlier decided that he does not need that kind of safety (i.e. "I
only say 'add -N' for `diff` and stuff, I will never forget to add real
contents before committing"), so it will almost never be used, because
these users who set 'ignoreIntentToAdd = true' do _not_ expect Git to help
them in remembering to add the real contents. And having to add a funny
option just for the sake of completeness is often an indication that there
is something fundamentally wrong in the system that the option tries to
express an interface into it.
Without conclusion... Sigh...
^ permalink raw reply
* Re: Git performance results on a large repository
From: Greg Troxel @ 2012-02-06 21:07 UTC (permalink / raw)
To: Joshua Redstone; +Cc: git@vger.kernel.org
In-Reply-To: <CB55A6A4.40AFD%joshua.redstone@fb.com>
[-- Attachment #1: Type: text/plain, Size: 1742 bytes --]
Joshua Redstone <joshua.redstone@fb.com> writes:
> Greg, 'git commit' does some stat'ing of every file, even with all those
> flags - for example, I think one instance it does it is, just in case any
> pre-commit hooks touched any files, it re-stats everything.
That seems ripe for skipping. If I understand correctly, what's being
committed is the index, not the working dir contents, so it would follow
that a pre-commit hook changing a file is a bug.
> Regarding the perf numbers, I ran it on a beefy linux box. Have you
> tried doing your measurements with the drop_caches trick to make sure
> the file cache is totally cold?
On NetBSD, there should be a clear cache command for just this reason,
but I'm not sure there is. So I did
sysctl -w kern.maxvnodes=1000 # seemed to take a while
ls -lR # wait for those to be faulted in
sysctl -w kern.maxvnodes=500000
Then, git status on my repo churned the disk for a long time.
real 2m7.121s
user 0m3.086s
sys 0m7.577s
and then again right away
real 0m6.497s
user 0m2.533s
sys 0m3.010s
That repo has 217852 files (a real source tree with a few binaries, not
synthetic).
> Sorry for the dumb question, but how do I check the vnode cache size?
On BSD, sysctl kern.maxvnodes. I would aasume that on Linux there is
some max size for the the vnode cache, and that stat of a file in that
cache is faster than going to the filesystem (even if reading from
cached disk blocks). But I really don't know how that works in Linux.
I was going to say that if your vnode cache isn't big enough, then the
hot run won't be so much faster than the warm run, but that's not true,
because the fs blocks will be in the block cache and it will still help.
[-- Attachment #2: Type: application/pgp-signature, Size: 194 bytes --]
^ permalink raw reply
* Re: [PATCH v4 2/4] completion: simplify __git_remotes
From: Felipe Contreras @ 2012-02-06 21:04 UTC (permalink / raw)
To: SZEDER Gábor
Cc: git, Junio C Hamano, Jonathan Nieder, Thomas Rast, Todd Zullinger,
Shawn O. Pearce, Junio C Hamano
In-Reply-To: <20120206205315.GI16099@goldbirke>
2012/2/6 SZEDER Gábor <szeder@ira.uka.de>:
> On Thu, Feb 02, 2012 at 10:30:23PM +0200, Felipe Contreras wrote:
>> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
>> index b435b6d..f86b734 100755
>> --- a/contrib/completion/git-completion.bash
>> +++ b/contrib/completion/git-completion.bash
>> @@ -644,12 +644,7 @@ __git_refs_remotes ()
>> __git_remotes ()
>> {
>> local i ngoff IFS=$'\n' d="$(__gitdir)"
>
> You could also remove the ngoff variable, because with this patch it's
> not used anymore.
Right, I thought I did that... The change must have been lost in one
of the many revisions =/
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH v4 2/4] completion: simplify __git_remotes
From: SZEDER Gábor @ 2012-02-06 20:53 UTC (permalink / raw)
To: Felipe Contreras
Cc: git, Junio C Hamano, Jonathan Nieder, Thomas Rast, Todd Zullinger,
Shawn O. Pearce, Junio C Hamano
In-Reply-To: <1328214625-3576-3-git-send-email-felipe.contreras@gmail.com>
Hi,
On Thu, Feb 02, 2012 at 10:30:23PM +0200, Felipe Contreras wrote:
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index b435b6d..f86b734 100755
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -644,12 +644,7 @@ __git_refs_remotes ()
> __git_remotes ()
> {
> local i ngoff IFS=$'\n' d="$(__gitdir)"
You could also remove the ngoff variable, because with this patch it's
not used anymore.
> - __git_shopt -q nullglob || ngoff=1
> - __git_shopt -s nullglob
> - for i in "$d/remotes"/*; do
> - echo ${i#$d/remotes/}
> - done
> - [ "$ngoff" ] && __git_shopt -u nullglob
> + test -d "$d/remotes" && ls -1 "$d/remotes"
> for i in $(git --git-dir="$d" config --get-regexp 'remote\..*\.url' 2>/dev/null); do
> i="${i#remote.}"
> echo "${i/.url*/}"
> --
> 1.7.9
>
^ permalink raw reply
* Re: Git performance results on a large repository
From: Joshua Redstone @ 2012-02-06 20:50 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy, Joey Hess, dgma@mohsinc.com, Matt Graham,
Tomas Carnecky, Greg Troxel, david@lang.hm, David Barr
Cc: git@vger.kernel.org
In-Reply-To: <CALts4TRGj1_uPX2b86GyfHHcDAUp6JSSMGmKjfS0p79DSAZ_uA@mail.gmail.com>
Hi all,
Nguyen, thanks for pointing out the assume-unchanged part. That, and
especially the suggestion of making assume-unchanged files read-only is
interesting. It does require explicit specification of what's changed.
Hmm, I wonder if that could be a candidate API through which something
like CoW file system could let git know what's changed. Btw, I think you
asked earlier, but the index compresses from 158MB to 58MB - keep in mind
that the majority of file names in the repo are synthetic, so take with
big grain of salt.
Joey, it sounds like it might be good if git-mv and other commands where
consistent in how they treat the assume-unchanged bit.
David Mohs: Yeah, it's an open question whether we'd be better off
somehow forcing the repos the split apart more. As a practical matter,
what may happen is that we incrementally solve our problem by addressing
pain points as they come up (e.g., git status being slow). One risk with
that approach is that it leads to overly short-term thinking and we get
stuck in a local minimum. I totally agree that good modularization and
code health is valuable. I think sometimes that getting to good
modularization does involve some technical work - like maybe moving
functionality between systems so they split apart better, having some
notion of versioning and dependency and managing that, and so forth. I
suppose the other aspect to the problem is that we want to make sure we
have a good source-control story even if the modularization effort takes a
long time - we'd rather not end up in a race between long-term
modularization efforts and source-control performance going south too
fast. I suppose this comes back to the desire that modularization not be
a prerequisite for good source-control performance. Oh, and in case I
didn't mention it - we are working on modularization and splitting off
large chunks of code, both into separable libraries as well as into
separate services, but it's a long-term process.
Matt, some of our repos are still on SVN, many are on pure-git. One of
the main ones that is on SVN is, at least at the moment, not amenable to
sparse checkouts because of it's structure.
Tomas, yeah, I think one of the big questions is how little technical work
can we get away with, and where's the point of maximum leverage in terms
of how much engineering time we invest.
Greg, 'git commit' does some stat'ing of every file, even with all those
flags - for example, I think one instance it does it is, just in case any
pre-commit hooks touched any files, it re-stats everything. Regarding the
perf numbers, I ran it on a beefy linux box. Have you tried doing your
measurements with the drop_caches trick to make sure the file cache is
totally cold? Sorry for the dumb question, but how do I check the vnode
cache size?
David Lang and David Barr, I generated the pack files by doing a repack:
"git repack -a -d -f --max-pack-size=10g --depth=100 --window=250" after
generating the repo.
One other update, the command I was running to get a histogram of all
files in the repo finally completed. The histogram (counting file size in
bytes) is:
[ 0.0 - 6.4): 3
[ 6.4 - 41.3): 27
[ 41.3 - 265.7): 6
[ 265.7 - 1708.1): 652594
[ 1708.1 - 10980.6): 673482
[ 10980.6 - 70591.6): 19519
[ 70591.6 - 453814.3): 1583
[ 453814.3 - 2917451.4): 276
[ 2917451.4 - 18755519.0): 61
[18755519.0 - 120574242.0]: 4
n=1347555 mean=3697.917708, median=1770.000000, stddev=122940.890559
The smaller files are all text (code), and the large ones are probably
binary.
Cheers,
Josh
On 2/6/12 11:23 AM, "Matt Graham" <mdg149@gmail.com> wrote:
>On Sat, Feb 4, 2012 at 18:05, Joshua Redstone <joshua.redstone@fb.com>
>wrote:
>> [ wanted to reply to my initial msg, but wasn't subscribed to the list
>>at time of mailing, so replying to most recent post instead ]
>>
>> Matt Graham: I don't have file stats at the moment. It's mostly code
>>files, with a few larger data files here and there. We also don't do
>>sparse checkouts, primarily because most people use git (whether on top
>>of SVN or not), which doesn't support it.
>
>
>This doesn't help your original goal, but while you're still working
>with git-svn, you can do sparse checkouts. Use --ignore-paths when you
>do the original clone and it will filter out directories that are not
>of interest.
>
>We used this at Etsy to keep git svn checkouts manageable when we
>still had a gigantic svn repo. You've repeatedly said you don't want
>to reorganize your repos but you may find this writeup informative
>about how Etsy migrated to git (which included a health amount of repo
>manipuation).
>http://codeascraft.etsy.com/2011/12/02/moving-from-svn-to-git-in-1000-easy
>-steps/
^ permalink raw reply
* Re: [PATCH] perl/Makefile: use 'installsitelib' even with NO_PERL_MAKEMAKER
From: Jeff King @ 2012-02-06 20:34 UTC (permalink / raw)
To: Nicholas Harteau; +Cc: git
In-Reply-To: <9D199309-85A6-42EE-9417-8C4E61534670@spotify.com>
On Mon, Feb 06, 2012 at 03:30:54PM -0500, Nicholas Harteau wrote:
> >>> ifdef NO_PERL_MAKEMAKER
> >>> -instdir_SQ = $(subst ','\'',$(prefix)/lib)
> >>> +instdir_SQ = $(subst ','\'',$(subst installsitelib=,'',$(shell $(PERL_PATH_SQ) -V:installsitelib)))
> >
> > Isn't this a regression if I am a non-root user installing into
> > $HOME/local or similar? With MakeMaker, I end up with this in my
> > perl.mak:
> [...]
>
> Totally correct - let me re-think the non-root case. Thanks.
I just read the github PR you linked to. It sounds like it might work to
just add a knob that the homebrew recipe could tweak to enable this
behavior (with the knob off by default).
-Peff
^ permalink raw reply
* Re: [PATCH] perl/Makefile: use 'installsitelib' even with NO_PERL_MAKEMAKER
From: Nicholas Harteau @ 2012-02-06 20:30 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20120206202610.GC30776@sigill.intra.peff.net>
On Feb 6, 2012, at 3:26 PM, Jeff King wrote:
> On Mon, Feb 06, 2012 at 02:38:20PM -0500, Nicholas Harteau wrote:
>
>>> perl/Makefile installs Git.pm into $prefix/lib when ExtUtils::MakeMaker
>>> is not present. perl can't "use Git;" in that scenario, as $prefix/lib
>>> isn't in perl's include path.
>>>
>>> This patch installs Git.pm into perl's 'installsitelib', generally
>>> $prefix/lib/perl5/site_perl, so that even when ExtUtils::MakeMaker isn't
>>> present, Git.pm gets installed in a location where 'use Git;' just
>>> works.
>> [...]
>>> ifdef NO_PERL_MAKEMAKER
>>> -instdir_SQ = $(subst ','\'',$(prefix)/lib)
>>> +instdir_SQ = $(subst ','\'',$(subst installsitelib=,'',$(shell $(PERL_PATH_SQ) -V:installsitelib)))
>
> Isn't this a regression if I am a non-root user installing into
> $HOME/local or similar? With MakeMaker, I end up with this in my
> perl.mak:
>
> PREFIX = /home/peff/local
> ...
> SITEPREFIX = $(PREFIX)
> ...
> INSTALLSITELIB = $(SITEPREFIX)/share/perl/5.14.2
>
> which works great. Before your patch, without MakeMaker, git would
> install into /home/peff/local/lib, which is also OK. But with your
> patch, it will try:
>
> $ perl -V:installsitelib
> installsitelib='/usr/local/share/perl/5.14.2';
>
> which is not writable by me, and the install will fail.
>
> I know it's more convenient for some uses, because we know that
> installsitelib will be in perl's @INC. But git has always installed out
> of the box for non-root users, and I don't think we want to change that.
Totally correct - let me re-think the non-root case. Thanks.
--
Nicholas Harteau
nrh@spotify.com
^ permalink raw reply
* Re: [PATCH] perl/Makefile: use 'installsitelib' even with NO_PERL_MAKEMAKER
From: Jeff King @ 2012-02-06 20:26 UTC (permalink / raw)
To: Nicholas Harteau; +Cc: git
In-Reply-To: <7328033C-8A11-452D-A927-E81E2DC4ABD6@spotify.com>
On Mon, Feb 06, 2012 at 02:38:20PM -0500, Nicholas Harteau wrote:
> > perl/Makefile installs Git.pm into $prefix/lib when ExtUtils::MakeMaker
> > is not present. perl can't "use Git;" in that scenario, as $prefix/lib
> > isn't in perl's include path.
> >
> > This patch installs Git.pm into perl's 'installsitelib', generally
> > $prefix/lib/perl5/site_perl, so that even when ExtUtils::MakeMaker isn't
> > present, Git.pm gets installed in a location where 'use Git;' just
> > works.
> [...]
> > ifdef NO_PERL_MAKEMAKER
> > -instdir_SQ = $(subst ','\'',$(prefix)/lib)
> > +instdir_SQ = $(subst ','\'',$(subst installsitelib=,'',$(shell $(PERL_PATH_SQ) -V:installsitelib)))
Isn't this a regression if I am a non-root user installing into
$HOME/local or similar? With MakeMaker, I end up with this in my
perl.mak:
PREFIX = /home/peff/local
...
SITEPREFIX = $(PREFIX)
...
INSTALLSITELIB = $(SITEPREFIX)/share/perl/5.14.2
which works great. Before your patch, without MakeMaker, git would
install into /home/peff/local/lib, which is also OK. But with your
patch, it will try:
$ perl -V:installsitelib
installsitelib='/usr/local/share/perl/5.14.2';
which is not writable by me, and the install will fail.
I know it's more convenient for some uses, because we know that
installsitelib will be in perl's @INC. But git has always installed out
of the box for non-root users, and I don't think we want to change that.
-Peff
^ permalink raw reply
* Re: [RFD] Rewriting safety - warn before/when rewriting published history
From: Johan Herland @ 2012-02-06 20:16 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Philip Oakley, git
In-Reply-To: <201202061814.58346.jnareb@gmail.com>
On Mon, Feb 6, 2012 at 18:14, Jakub Narebski <jnareb@gmail.com> wrote:
> On Mon, 6 Feb 2012, Johan Herland wrote:
>> On Mon, Feb 6, 2012 at 15:44, Jakub Narebski <jnareb@gmail.com> wrote:
>> > Relying on (default) hooks to implement this feature has the disadvantage
>> > that it wouldn't be turned on by default... while this feature would be
>> > most helpful for users new to git (scared by refuse to push).
>>
>> True. I too believe that this will be most helpful if it is enabled by
>> default. That said, the easiest way to get there might be through
>> first demonstrating that it works in practice when implemented as
>> hooks.
>
> Yes, starting with prototype implementation using existing infrastructure
> (hooks) would be a very good idea. (That's how first versions of what
> became submodules were implemented.)
>
> OTOH we should be aware of limitations of said prototype due to the fact
> that it is a prototype...
Agreed, but AFAICS (and modulo the addition of pre-rewrite and
pre/post-push hooks mentioned earlier) all of the things discussed so
far in this thread can be implemented as hooks.
>> > I am not sure either if everything (wrt. safety net) can be implemented
>> > via hooks. One thing that I forgot about is preventing rewinding of
>> > branch past the published commit using e.g. "git reset --hard <commit>".
>> > Unless `pre-rewrite` hook could be used for that safety too...
>>
>> Hmm. I don't think we'll be able to "plug" all the holes that might
>> leave the user in a rewritten state (e.g. what if the user (possibly
>> with the help of some tool) does an "echo $SHA1 >
>> .git/refs/head/master"?).
>
> First, I was thinking about having safety net against rewriting published
> commits being present only in porcelain. Plumbing would be not affected
> (perhaps there would be need to extend or add new plumbing to query "phase"
> state, though).
I also think this is very much a porcelain-only feature. I'd be more
worried if plumbing changes were needed.
>> And trying to plug too many holes might end
>> up annoying more experienced users who "know what they're doing".
>
> Second, forcing via command line parameter should always be an option.
Obviously, but if a large portion of the Git community felt the need
to always disable this feature, I'd say that we'd failed. The best
features are those that Just Work(tm).
>> Instead we might want to add a client-side check at push time. I
>> realize that this check is already done by the remote end, but the
>> client-side might be able to give a more helpful response along the
>> lines of:
>
> [...]
>
> Explanation is good, but the whole idea of rewriting safety is that you
> are informed (warned or denied) _before_ attempting rewrite and doing much
> work.
True, but there may be cases where the rewrite is not apparent until
after it has happened. E.g. a novice user may use 'git reset --hard'
in order to get to an earlier state for testing purposes, and then -
after completing the test - 'git reset --hard' back to the starting
point. I know this is not best practice, but is it bad enough that we
want to refuse it?
>> First, we don't need to annotate _all_ commits. For the 'public'
>> state, we only annotate the last/tip commit that was pushed/published.
>> From there, we can defer that all ancestor commits are also 'public'.
>
> Right.
>
>> For the 'secret' state, we do indeed annotate _all_ secret commits,
>> but I believe this will be a somewhat limited number of commits. If
>> your workflow forces you to annotate millions of commits as 'secret',
>> I claim there is something wrong with your workflow.
>
> Well, for the 'secret' we can rely on the fact that child of 'secret'
> commit must also be 'secret' (non-publishable) if secret is to stay
> secret. Still marking all 'secret' commits might be better idea from
> UI and from performance point of view.
I don't think we should automatically assume that all children of a
'secret' commit are also 'secret'. First of all, the git DAG was not
made for iterating forwards in history, so given a 'secret' commit, it
is computationally expensive to enumerate all its implied-'secret'
descendants. More importantly though, I don't agree with the premise.
I would typically use the 'secret' state as follows: While debugging a
piece of code, I might commit a few debug print statements, and I
would typically mark this debug commit as 'secret', in order to
prevent myself from accidentally pushing this. Although it probably
doesn't matter in practice, I think it is wrong for the commits made
(temporarily) on top of this debug commit to be also considered
'secret'. They are only unpublishable as a consequence of being based
on the debug commit, and only until I get around to rebasing away the
'secret' debug commit.
>> > Second, I have doubts if "phase" is really state of an individual commit,
>> > and not the feature of revision walking.
>
> It matters to presentation: can commit be simultaneously 'public' because
> of one branch, and 'draft' because of other.
>
>> I believe the 'public' state is a "feature of revision walking" (i.e.
>> one annotated 'public' commit implies that all its ancestors are also
>> 'public'). However, the 'secret' state should be bound to the
>> individual commit, IMHO.
>
> Good call, otherwise 'secret' commit could have been "side-leaked"
> by other refs being pushed.
>
> This means though that 'public' / 'draft' while looking similar to 'secret'
> are in fact a bit different things. In other words 'immutable' and
> 'impushable' traits are quite a bit different in behavior...
>
> Especially that one acts at pre-rewrite time, and second pre-push time.
Exactly. I find Mercurial 'phase' language confusing, precisely for
the reason that 'public' and 'secret' are DIFFERENT concepts. One
hinders rewrite and naturally applies to a commit AND its ancestors,
while the other hinders push and only applies to the commit itself.
The fact that they could be implemented by the same mechanisms (hooks
and notes) does not make them the same thing.
>> > Take for example the situation where given commit is reference by
>> > remote-tracking branch 'public/foo', and also by two local branches:
>> > 'foo' with upstream 'public/foo', and local branch 'bar' with no upstream.
>> >
>> > Now it is quite obvious that this feature should prevent rewriting 'foo'
>> > branch, for which commits are published upstream. But what about branch
>> > 'bar'? Should we prevent rewriting (e.g. rebase) here too? What about
>> > rewinding 'bar' to point somewhere else. What if 'bar' is really detached
>> > HEAD?
>> >
>> > These questions need to be answered...
>>
>> Good point. There are two questions we may need to answer: "Has commit
>> X ever been published?", and "Has commit X ever been published in the
>> context of branch Y?". In the latter case, we do indeed need to take
>> the upstream branch into account.
>
> I think the second one is more interested for rewrite safeties.
>
>> Basically, there are three different "levels" for this rewrite/publish
>> protection to run at:
>>
>> 1. Do not meddle at all. This is the current behavior, and assumes
>> that if the user rewrites and pushes something, the user knows what
>> he/she is doing, and Git should not meddle (obviously unless the
>> server refuses the push).
>
> I think that there should be some easy way to force such behavior,
> i.e. to discard rewrite safeties.
Indeed. We should probably have a simple config flag to enable the
rewrite protection. In fact I would argue that the flag should default
to false (disable protection) when unset, and then we should let
init/clone set the config flag to true (enable protection) in newly
created repos (unless explicitly disabled in the user/system configs).
This way, behavior does not change for existing repos, but new repos
are protected by default (with only a single command needed to disable
the protection).
>> 2. Warn/refuse rewriting commits in your upstream. This would only
>> check branch X against its registered upstream. Only if there is a
>> registered upstream, and you're about to rewrite commits that are
>> reachable from the upstream remote-tracking branch, should Git
>> intervene and warn/refuse the rewrite. This level would IMHO provide
>> most of the benefit, and little or no trouble (i.e. false positives).
>
> Right. I wonder if we can get usage statistics from Mercurial users
> about usage of their "phases" feature... though mapping terminology
> for example 'upstream' from Git to Mercurial and vice versa can be
> a pain, I guess.
I'm unsure how useful it would be. IMHO Git and Mercurial are
different enough (and promote sightly different workflows) that I
don't trust the the average Mercurial user's preference for
Mercurial's 'phase' behavior to be transferable to the average Git
user's preference for a similar behavior in Git.
>> 3. Warn/refuse rewriting _any_ 'public' commit. Refuse to rewrite any
>> commit that is reachable from any remote-tracking branch. Some would
>> say that this is a Good Thing(tm), since it prevents a commit from
>> being _copied_ (i.e. rebased or cherry-picked) between branches (you'd
>> be in this camp if you run a tightly-controlled workflow, where you
>> e.g. mandate upmerging patches from the oldest applicable branch
>> instead of cherry-picking patches from a newer branch). However, other
>> people would say that this is too limiting, and imposes unnecessary
>> rules on the workflow of the project (where e.g. copying (by way of
>> git-rebase) a topic branch from one place to another would cause an
>> annoying false positive).
>
> Well, we could always 'deny' on 2nd, and just 'warn' on 3rd...
Good idea.
Have fun! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: Bug: "git checkout -b" should be allowed in empty repo
From: Jeff King @ 2012-02-06 20:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael Haggerty, Andrew Ardill, git
In-Reply-To: <7vpqdr7rn0.fsf@alter.siamese.dyndns.org>
On Mon, Feb 06, 2012 at 10:17:55AM -0800, Junio C Hamano wrote:
> > PS I probably would have done it as:
> >
> > git init vendor
> > cd vendor
> > import import import
> > cd ..
> >
> > git init project
> > cd project
> > git fetch ../vendor master:vendor
> >
> > but I don't think there's anything wrong with your approach (in fact,
> > it's slightly more efficient).
>
> Probably I am slower than my usual slow self this morning. Does Michael's
> approach go like this:
>
> git init project
> cd project
> import import import
> git branch -m vendor
> git checkout -b master
>
> to fork from third-party codebase?
I thought it would have been:
git init project
cd project
git checkout -b vendor
import import import
git checkout -b master
modify modify modify
but he can probably say more.
-Peff
^ permalink raw reply
* Re: [PATCH 2/3] tag: die when listing missing or corrupt objects
From: Jeff King @ 2012-02-06 20:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Tom Grennan, git, jasampler
In-Reply-To: <7vty337rug.fsf@alter.siamese.dyndns.org>
On Mon, Feb 06, 2012 at 10:13:27AM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > OK, that's easy enough to do. Should we show lightweight tags to commits
> > for backwards compatibility (and just drop the parse_signature junk in
> > that case)? The showing of blobs or trees is the really bad thing, I
> > think.
>
> For now, dropping 3/3 and queuing this instead...
>
> ---
> Subject: tag: do not show non-tag contents with "-n"
Looks perfect. Thanks.
-Peff
^ permalink raw reply
* Re: [PATCH 4/4] commit: remove commit.ignoreIntentToAdd, assume it's always true
From: Junio C Hamano @ 2012-02-06 20:05 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Jonathan Nieder
In-Reply-To: <1328525855-2547-5-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> diff --git a/t/t2203-add-intent.sh b/t/t2203-add-intent.sh
> index 09b8bbf..7c7ab54 100755
> --- a/t/t2203-add-intent.sh
> +++ b/t/t2203-add-intent.sh
> @@ -50,7 +50,7 @@ test_expect_success 'can commit tree with i-t-a entry' '
> echo frotz >nitfol &&
> git add rezrov &&
> git add -N nitfol &&
> - git config commit.ignoreIntentToAdd true &&
> + git config commit.ignoreIntentToAdd false &&
This deserves a comment to the effect that the variable is now *ignored*.
> git commit -m initial &&
> git ls-tree -r HEAD >actual &&
> cat >expected <<EOF &&
^ permalink raw reply
* Re: [PATCH 3/4] commit: turn commit.ignoreIntentToAdd to true by default
From: Junio C Hamano @ 2012-02-06 20:03 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Jonathan Nieder
In-Reply-To: <1328525855-2547-4-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> - if (!set_commit_ignoreintenttoadd) {
Now no warning() is associated with testing of this flag, which means that
people who didn't get around to read the doc and react to the warnings in
the earlier releases will get _nothing_ when the real change hits them?
That sounds strangely bad. What am I missing?
> + if (!(cache_tree_flags & WRITE_TREE_IGNORE_INTENT_TO_ADD)) {
> int i;
> for (i = 0; i < active_nr; i++)
> if (active_cache[i]->ce_flags & CE_INTENT_TO_ADD)
> break;
> if (i < active_nr)
> warning(_("You are committing as-is with intent-to-add entries as the result of\n"
> - "\"git add -N\". Git currently forbids this case. This will change in\n"
> - "1.8.0 where intent-to-add entries are simply ignored when committing\n"
> - "as-is. Please look up document and set commit.ignoreIntentToAdd\n"
> - "properly to stop this warning."));
> + "\"git add -N\". Git currently forbids this case. But this is deprecated\n"
> + "support for this behavior will be dropped in FIXME.\n"
> + "Please look up document and set commit.ignoreIntentToAdd to true\n"
> + "or remove it."));
As this is marked with FIXME ;-)
At this point in the deprecation cycle, "currently forbids this case." is
not true at all. "You asked me to punt when you forgot to tell me the
final contents for i-t-a entries, so I am honoring your wish" is what is
happening here. Perhaps...
Git currently allows you to set commit.ignoreIntentToAdd to false
to remind you about the paths you may have forgotten to add the
real contents to before committing, but this support will be
removed in future versions of Git. Set commit.ignoreIntentToAdd
to `false` or remove the variable, and get used to the new
behaviour, to squelch this message.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox