Usually, a trivial change(like coding style fix) may bury a
original change of the code, and thus git blame is of less
help. And to address this situation, I have to do like this:
git blame -s REF^ > temp
to dig into the history recursively by hand, to find out
the original change.
Here, REF
Am 5/7/2014 19:46, schrieb Junio C Hamano:
> David Turner writes:
>
>> On Wed, 2014-05-07 at 08:17 +0200, Johannes Sixt wrote:
} else if (cache_name_pos(src, length) < 0)
bad = _("not under version control");
- else if (lstat(dst, &st) == 0) {
Hi,
this is the error in httpd error.log
[Wed May 07 20:44:10 2014] [alert] getpwuid: couldn't determine user
name from uid 4294967295, you probably need to modify the User directive
[Wed May 07 20:44:10 2014] [notice] Apache/2.2.17 (Ubuntu) configured
--resuming normal operations
[
During the mail thread about "Pull is mostly evil" a user asked how
the first parent could become reversed.
This howto explains how the first parent can get reversed when viewed
by the project and then explains a method to keep the history correct.
Signed-off-by: Stephen P. Smith
---
Documentat
On Wed, May 7, 2014 at 9:38 PM, Nathan Collins wrote:
> On Wed, May 7, 2014 at 4:39 PM, Nathan Collins
> wrote:
>> On Wed, May 7, 2014 at 11:42 AM, Junio C Hamano wrote:
>>> Nathan Collins writes:
>>
For (2), the solution may be to add a separate
'diff.add-clickable-paths' option (pr
On Wed, May 7, 2014 at 4:39 PM, Nathan Collins wrote:
> On Wed, May 7, 2014 at 11:42 AM, Junio C Hamano wrote:
>> Nathan Collins writes:
>
>>> For (2), the solution may be to add a separate
>>> 'diff.add-clickable-paths' option (probably there is a better name?
>>> 'diff.add-copyable-paths'? ...
On Wed, May 07, 2014 at 02:45:01PM -0700, Junio C Hamano wrote:
> Fabio D'Alfonso writes:
>
> > root@HDUBVM01:~/builds/git/t# ./t5539-fetch-http-shallow.sh
> > ok 1 - setup shallow clone
> > not ok 2 - clone http repository
> [...]
> Does not reproduce for me but I am on Ubuntu 12.04.2 LTS, so.
On Wed, May 07, 2014 at 04:44:01PM -0700, Jonathan Nieder wrote:
> The git-shell(1) manpage says
>
> EXAMPLE
> To disable interactive logins, displaying a greeting
> instead:
>
> +
>
> $ chsh -s /usr/bin/git-shell
>
Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > Felipe Contreras writes:
> >
> >> Here's a bunch of tests more, and a fixes for Mercurial v3.0.
> >
> > I think the discussion with John Keeping hints that we shouldn't be
> > rushing fc/remote-helpers-hg-bzr-graduation and this does not appea
Felipe, I would ask, suggest, beg, implore you to calm down. It's
generally not a good plan to alienate the maintainer of a project,
regardless of the correctness or incorrectness of one's arguments, but I
fear that's only what you will achieve at the moment.
--
Regards,
James Denholm.
--
To unsub
I'll create a patch.
On Wednesday, May 07, 2014 01:51:04 PM Junio C Hamano wrote:
> Jim Garrison writes:
>
> >> -Original Message-
> >> From: Junio C Hamano
> >> Sent: Wednesday, May 07, 2014 1:16 PM
> >> Subject: Re: Beginner question on "Pull is mostly evil"
> >>
> >> No. This is mos
On Tue, May 06, 2014 at 03:59:04PM -0700, dtur...@twopensource.com wrote:
> @@ -74,7 +74,7 @@ int cmd_mv(int argc, const char **argv, const char *prefix)
> };
> const char **source, **destination, **dest_path, **submodule_gitfile;
> enum update_mode { BOTH = 0, WORKING_DIRECTORY,
Junio C Hamano wrote:
> Felipe Contreras writes:
>
> > And you are still conveniently avoiding the question:
> >
> > Based on what reasoning?
>
> Go re-read what was already said in the thread.
I already read it, and I already responded.
> I still think remote-hg and remote-bzr can and will fl
After a closer look, it seems the initial patch wasn't correctly sent
to the list. Please disregard, I'm re-sending the patch entirely.
Regards,
James Denholm.
On 8 May 2014 07:53, James Denholm wrote:
> On 4 May 2014 16:33:32 GMT+10:00, James Denholm wrote:
>>cmd_add_commit() is passed FETCH_H
cmd_add_commit() is passed FETCH_HEAD by cmd_add_repository, which is
then rev-parsed into an object ID. However, if the user is fetching a
tag rather than a branch HEAD, such as by executing:
$ git subtree add -P oldGit https://github.com/git/git.git tags/v1.8.0
The object ID is a tag and is nev
Greg Troxel wrote:
>
> Felipe Contreras writes:
>
> > Greg Troxel wrote:
> >> In a packaging system, dependencies are much more troublesome.
> >> Dependencies have to be declared, and the build limited to use only
> >> those declared dependencies, in order to get repeatable builds and
> >> binar
Junio C Hamano writes:
> Felipe Contreras writes:
>
>> Here's a bunch of tests more, and a fixes for Mercurial v3.0.
>
> I think the discussion with John Keeping hints that we shouldn't be
> rushing fc/remote-helpers-hg-bzr-graduation and this does not appear
> to assume the presense of that ser
Felipe Contreras writes:
> And you are still conveniently avoiding the question:
>
> Based on what reasoning?
Go re-read what was already said in the thread. I still think
remote-hg and remote-bzr can and will flourish on their own merit,
and unbundling will be better for the end users for the
The git-shell(1) manpage says
EXAMPLE
To disable interactive logins, displaying a greeting
instead:
+
$ chsh -s /usr/bin/git-shell
$ mkdir $HOME/git-shell-commands
[...]
The stray "+" has been there eve
On Wed, May 7, 2014 at 11:42 AM, Junio C Hamano wrote:
> Nathan Collins writes:
>> For (2), the solution may be to add a separate
>> 'diff.add-clickable-paths' option (probably there is a better name?
>> 'diff.add-copyable-paths'? ...),...
>> ...
>> Concretely, if 'diff.add-clickable-paths' is s
Felipe Contreras writes:
> Greg Troxel wrote:
>> In a packaging system, dependencies are much more troublesome.
>> Dependencies have to be declared, and the build limited to use only
>> those declared dependencies, in order to get repeatable builds and
>> binary packages that can be used on othe
Hi Junio,
The following changes since commit b4f86a4ce85e4e370a67455de6586a02f158a789:
Git 2.0-rc2 (2014-05-02 13:15:52 -0700)
are available in the git repository at:
git://github.com/git-l10n/git-po master
for you to fetch changes up to 80dad719fb4bd8090b70da0e6f61ac22a6ff8754:
l10n: F
Hi.
I might be late to this discussion, but here either
something I don't understand or something is missed.
On Sat, May 03, 2014 at 03:56:51AM -0400, Richard Hansen wrote:
> In my experience 'git pull' is mostly (only?) used for the following
> three tasks:
>
> 1. update a local branch to inco
On 8 May 2014 06:57:13 GMT+10:00, Matthieu Moy
wrote:
>Felipe Contreras writes:
>
>> Matthieu Moy wrote:
>>> Felipe Contreras writes:
>>> > If you want to use python2, then use '/usr/bin/env python2'.
>>>
>>> Err, yes, this is what the code does before your patch.
>>
>> Not for all the instanc
On Fri, Mar 21, 2014 at 08:32:03AM +0100, Per Cederqvist wrote:
> This makes it easier to script operations on the entire queue, for
> example run the test suite on each patch in the queue:
>
> guilt pop -a;while guilt push; do make test||break; done
>
> This brings "guilt push" in line with
On 4 May 2014 16:33:32 GMT+10:00, James Denholm wrote:
>cmd_add_commit() is passed FETCH_HEAD by cmd_add_repository, which is
>then rev-parsed into an object ID. However, if the user is fetching a
>tag rather than a branch HEAD, such as by executing:
>
>$ git subtree add -P oldGit https://github.c
John Keeping wrote:
> On Wed, May 07, 2014 at 03:26:15PM -0500, Felipe Contreras wrote:
> > Junio C Hamano wrote:
> > > Your git-integrate might turn into something I could augment my
> > > workflow with with some additions.
> > >
> > > - specifying a merge strategy per branch being merged;
> >
Fabio D'Alfonso writes:
> Hi,
> I am getting this in Ubuntu, something wrong with my env?
> Thanks
>
> root@HDUBVM01:~/builds/git/t# ./t5539-fetch-http-shallow.sh
> ok 1 - setup shallow clone
> not ok 2 - clone http repository
> #
> #git clone --bare --no-local shallow
> "$HTTPD_DOCUMENT_
Thorsten Glaser writes:
> Display the tag name about to be added to the user during interactive
> editing.
>
> Signed-off-by: Thorsten Glaser
> Signed-off-by: Richard Hartmann
> ---
Sounds sensible from a first glance. Will queue; thanks.
> builtin/tag.c | 8
> 1 file changed, 4 in
On Fri, Mar 21, 2014 at 08:32:02AM +0100, Per Cederqvist wrote:
> Only one invocation of "disp" or "_disp" actually needed backslash
> processing. In quite a few instances, it was wrong to do backslash
> processing, as the message contained data derived from the user.
>
> Created the new function
Signed-off-by: Josef 'Jeff' Sipek
On Fri, Mar 21, 2014 at 08:32:05AM +0100, Per Cederqvist wrote:
> Fix remove_topic() in t-061.sh so that it doesn't print a git hash.
>
> Signed-off-by: Per Cederqvist
> ---
> regression/t-061.out | 1 -
> regression/t-061.sh | 2 +-
> 2 files changed, 1 inse
On Wed, May 07, 2014 at 10:59:56PM +0200, Per Cederqvist wrote:
> On Tue, May 6, 2014 at 9:40 PM, Jeff Sipek wrote:
> > On Fri, Mar 21, 2014 at 08:31:45AM +0100, Per Cederqvist wrote:
> >> Test that we can combine any combination of patches with empty and
> >> non-empty messages, both with and wit
Felipe Contreras writes:
> Matthieu Moy wrote:
>> Felipe Contreras writes:
>> > If you want to use python2, then use '/usr/bin/env python2'.
>>
>> Err, yes, this is what the code does before your patch.
>
> Not for all the instances.
Well, I guess not all scripts require python2, hence not all
On Tue, May 6, 2014 at 9:40 PM, Jeff Sipek wrote:
> On Fri, Mar 21, 2014 at 08:31:45AM +0100, Per Cederqvist wrote:
>> Test that we can combine any combination of patches with empty and
>> non-empty messages, both with and without guilt.diffstat. (All
>> patches are empty.)
>
> I feel like we sho
On Wed, 2014-05-07 at 10:42 -0700, Junio C Hamano wrote:
> David Turner writes:
>
> > This causes my test to pass and generally seems correct to me.
>
> Yes, this approach is very sensible, and I'll queue.
>
> But watchman support _should_ be prepared for a program that does
> not do this. Dev
Jonathan Nieder writes:
>> Please make it a habit to use "test -f" when you expect "the path
>> exists as a file", not merely "something exists there I do not care
>> if it is a file or a directory", for which "test -e" is perfectly
>> appropriate.
>
> Or, better in tests,
>
> test_path_is_
Hi,
I am getting this in Ubuntu, something wrong with my env?
Thanks
root@HDUBVM01:~/builds/git/t# ./t5539-fetch-http-shallow.sh
ok 1 - setup shallow clone
not ok 2 - clone http repository
#
#git clone --bare --no-local shallow
"$HTTPD_DOCUMENT_ROOT_PATH/repo.git" &&
#git clone
Hi,
I've looked more attentively, here are my observations and the
resulting suggestions:
- Suggest only to check *string-wise* the given "path" against
$GIT_DIR. Both or one of them may be relative paths (but comparison
best be performed when converted to absolute paths). That's the only
sol
Jim Garrison writes:
>> -Original Message-
>> From: Junio C Hamano
>> Sent: Wednesday, May 07, 2014 1:16 PM
>> Subject: Re: Beginner question on "Pull is mostly evil"
>>
>> No. This is most often true for people who use a single repository as a
>> place for everybody to meet, in the sam
Matthieu Moy wrote:
> Felipe Contreras writes:
> > If you want to use python2, then use '/usr/bin/env python2'.
>
> Err, yes, this is what the code does before your patch.
Not for all the instances.
> > If you are going to follow practices different than git.git, then
> > multimail shouldn't li
Junio C Hamano wrote:
> Felipe Contreras writes:
> > Really? Based on what reasoning? I have proven his reasoning to be
> > basically wrong.
>
> Perhaps s/proven/convinced myself only/; you didn't prove it to me
> and I doubt you proved it to John.
And you are still conveniently avoiding the que
On Tue, May 6, 2014 at 8:23 AM, Michael Haggerty wrote:
> On 05/06/2014 12:57 AM, Ronnie Sahlberg wrote:
>> This is a single patch that adds two new functions to try to hide the reflog
>> implementation details from the callers in checkout.c and reflog.c.
>> It adds new functions to test if a refl
n Tue, May 6, 2014 at 9:08 PM, Jeff Sipek wrote:
> On Sun, Mar 23, 2014 at 10:03:48PM +0100, Per Cederqvist wrote:
>> On Sun, Mar 23, 2014 at 6:09 PM, Jeff Sipek wrote:
>>
>> > On Fri, Mar 21, 2014 at 08:31:44AM +0100, Per Cederqvist wrote:
>> >> When extracting the patch, we only want the actual
On Wed, May 07, 2014 at 03:26:15PM -0500, Felipe Contreras wrote:
> Junio C Hamano wrote:
> > Your git-integrate might turn into something I could augment my
> > workflow with with some additions.
> >
> > - specifying a merge strategy per branch being merged;
>
> git-reintegrate[1] supports this
Matthieu Moy writes:
> Perhaps it deserves a mention in the doc, e.g. squashing this on top of
> my patch:
Thanks, will do.
>
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index b7f92ac..ebd1676 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@
Heiko Voigt writes:
> On Mon, Apr 28, 2014 at 04:29:31PM +0200, Stepan Kasal wrote:
>> this is another patch that lives in msysGit for a long time.
>> Originally, it had two parts:
>> (Cf https://github.com/msysgit/git/commit/64a8a03 )
>>
>> 1) adding alias pwd='pwd -W' to git-sh-setup.sh
>>
Junio C Hamano wrote:
> That "when I manually" part is what I meant by "we give a good way for
> these third-party tools" above, and "make it really easy to install
> these third-party tools" in the remaining part of the message you are
> responding to.
We need two things:
1) Provied a pkg-conf
Heiko Voigt writes:
> On Wed, May 07, 2014 at 11:19:09AM -0700, Junio C Hamano wrote:
>> Jeff King writes:
>> ...
>> > Yeah, this started last summer when we added __attribute__((format)) to
>> > the status_printf_ln calls, and I posted essentially the same patch. We
>> > kind of waffled betwee
> -Original Message-
> From: Junio C Hamano
> Sent: Wednesday, May 07, 2014 1:16 PM
> Subject: Re: Beginner question on "Pull is mostly evil"
>
> No. This is most often true for people who use a single repository as a
> place for everybody to meet, in the same way as SVN.
[snip lots of ex
Felipe Contreras writes:
> Junio C Hamano wrote:
>> Felipe Contreras writes:
>>
>> > Here's a bunch of tests more, and a fixes for Mercurial v3.0.
>>
>> I think the discussion with John Keeping hints that we shouldn't be
>> rushing fc/remote-helpers-hg-bzr-graduation
>
> Really? Based on what
Felipe Contreras writes:
> Matthieu Moy wrote:
>> Felipe Contreras writes:
>>
>> > It's better if all our scripts use the same '/usr/bin/env python'.
>>
>> Why?
>>
>> Using python2 for git_multimail.py is a deliberate decision:
>
> If you want to use python2, then use '/usr/bin/env python2'.
Michael Haggerty writes:
> +1 Looks good to me. Thanks!
Will queue with your Ack; thanks.
--
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
Jim Garrison writes:
> During my initial self-education I came across the maxim "don't
> pull, fetch+merge instead" and have been doing that. I think I
> followed most of the "pull is (mostly) evil" discussion but one
> facet still puzzles me: the idea that pull will do a merge "in the
> wrong d
On Wed, May 07, 2014 at 11:19:09AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > On Sun, May 04, 2014 at 07:01:22PM +, brian m. carlson wrote:
> >
> >> On Sun, May 04, 2014 at 01:12:55AM -0500, Felipe Contreras wrote:
> >> > This is in gcc 4.9.0:
> >> >
> >> > wt-status.c: In func
Greg Troxel wrote:
> In a packaging system, dependencies are much more troublesome.
> Dependencies have to be declared, and the build limited to use only
> those declared dependencies, in order to get repeatable builds and
> binary packages that can be used on other systems. Dependencies that
> re
John Keeping wrote:
> Having thought about it a bit more after reading Felipe's reply, it
> would be nice if there were some way for third-party tools to install
> HTML documentation without relying on `git --html-path` but I cannot
> see an obvious way to do that as there isn't a standard $HTML_PA
Junio C Hamano wrote:
> Felipe Contreras writes:
>
> > As an example of all the hacks needed by a real distribution package,
> > here's the stuff ArchLinux packagers have to do:
> >
> > # bash completion
> > mkdir -p "$pkgdir"/usr/share/bash-completion/completions/
> > install -m644 ./contr
On Wed, May 07, 2014 at 11:56:18AM -0700, Junio C Hamano wrote:
> John Keeping writes:
>
> > On Tue, May 06, 2014 at 05:01:59PM -0700, Junio C Hamano wrote:
> > ...
> >> Another thing to keep in mind is that we need to ensure that we give
> >> a good way for these third-party tools to integrate w
On 2014-05-05 23.46, Jeff King wrote:
[]
>> 2. Do all index filename comparisons under Mac OS X using a UTF-8 aware
>> comparison function regardless if core.precomposeunicode is set.
>> This would probably have bad performance, and somewhat
>> defeats the point of converting the f
Matthieu Moy wrote:
> Felipe Contreras writes:
>
> > It's better if all our scripts use the same '/usr/bin/env python'.
>
> Why?
>
> Using python2 for git_multimail.py is a deliberate decision:
If you want to use python2, then use '/usr/bin/env python2'.
> "The git-multimail project itself is
Junio C Hamano wrote:
> Felipe Contreras writes:
>
> > Here's a bunch of tests more, and a fixes for Mercurial v3.0.
>
> I think the discussion with John Keeping hints that we shouldn't be
> rushing fc/remote-helpers-hg-bzr-graduation
Really? Based on what reasoning? I have proven his reasoning
Felipe Contreras writes:
> Junio C Hamano wrote:
>> Felipe Contreras writes:
>> > Plus this one which has been completely ignored:
>> >
>> >completion: move out of contrib
>>
>> It is not about "ignored". It is about running out of time before
>> concluding the day's integration.
>
> A com
John Keeping writes:
> On Tue, May 06, 2014 at 05:01:59PM -0700, Junio C Hamano wrote:
> ...
>> Another thing to keep in mind is that we need to ensure that we give
>> a good way for these third-party tools to integrate well with the
>> core Git tools to form a single toolchest for the users. I
Hi,
On Mon, Apr 28, 2014 at 04:29:31PM +0200, Stepan Kasal wrote:
> this is another patch that lives in msysGit for a long time.
> Originally, it had two parts:
> (Cf https://github.com/msysgit/git/commit/64a8a03 )
>
> 1) adding alias pwd='pwd -W' to git-sh-setup.sh
>This one went upstream, t
Nathan Collins writes:
> More concretely, what I had in mind was that if 'diff.noprefix=true'
> is set in the user's config, and the patch is in '-p0' format, then
> Git could suggest to the user that the 'diff.noprefix' setting *might*
> be causing them to generate '-p0' patches. If the user had
Junio C Hamano wrote:
> dtur...@twopensource.com writes:
>> +test -e testcase
>
> Please make it a habit to use "test -f" when you expect "the path
> exists as a file", not merely "something exists there I do not care
> if it is a file or a directory", for which "test -e" is perfectly
> approp
Jeff King writes:
> On Sun, May 04, 2014 at 07:01:22PM +, brian m. carlson wrote:
>
>> On Sun, May 04, 2014 at 01:12:55AM -0500, Felipe Contreras wrote:
>> > This is in gcc 4.9.0:
>> >
>> > wt-status.c: In function ‘wt_status_print_unmerged_header’:
>> > wt-status.c:191:2: warning: zero-
Felipe Contreras writes:
> Here's a bunch of tests more, and a fixes for Mercurial v3.0.
I think the discussion with John Keeping hints that we shouldn't be
rushing fc/remote-helpers-hg-bzr-graduation and this does not appear
to assume the presense of that series, which is good in order to
make
Felipe Contreras writes:
> It's better if all our scripts use the same '/usr/bin/env python'.
Why?
Using python2 for git_multimail.py is a deliberate decision:
https://github.com/mhagger/git-multimail/pull/2
(also, contrib/hooks/multimail/README says:
"The git-multimail project itself is cur
dtur...@twopensource.com writes:
> +if ! test_have_prereq CASE_INSENSITIVE_FS
> +then
> + skip_all='skipping case insensitive tests - case sensitive file system'
> + test_done
> +fi
> +
> +test_expect_success 'merge with case-changing rename' '
> + test $(git config core.ignorecase) =
On Wed, 2014-05-07 at 10:46 -0700, Junio C Hamano wrote:
> David Turner writes:
>
> > On Wed, 2014-05-07 at 08:17 +0200, Johannes Sixt wrote:
> >> > } else if (cache_name_pos(src, length) < 0)
> >> > bad = _("not under version control");
> >> > -
Junio C Hamano writes:
> While I fully agree with the above conclusion, I just noticed that I
> will be irritated enough to eventually set pager.blame myself, after
> running a short "git blame -L1311,+7 git-p4.py", which is one of the
> standard first steps for me to start reading patches submit
David Turner writes:
> On Wed, 2014-05-07 at 08:17 +0200, Johannes Sixt wrote:
>> >} else if (cache_name_pos(src, length) < 0)
>> >bad = _("not under version control");
>> > - else if (lstat(dst, &st) == 0) {
>> > + else if (lstat(dst, &dst_st) ==
David Turner writes:
> This causes my test to pass and generally seems correct to me.
Yes, this approach is very sensible, and I'll queue.
But watchman support _should_ be prepared for a program that does
not do this. Developing your support in on a codebase with this
patch may be sweeping a b
Felipe Contreras writes:
> As an example of all the hacks needed by a real distribution package,
> here's the stuff ArchLinux packagers have to do:
>
> # bash completion
> mkdir -p "$pkgdir"/usr/share/bash-completion/completions/
> install -m644 ./contrib/completion/git-completion.bash
> "
Tolga Ceylan writes:
> When applying binary patches a full index is required. format-patch
> already handles this, but diff-tree needs '--full-index' argument
> to always output full index. When git-p4 runs git-apply to test
> the patch, git-apply rejects the patch due to abbreviated blob
> objec
Jeff King writes:
> On Tue, May 06, 2014 at 08:49:22PM +0200, Matthieu Moy wrote:
> ...
>> The idea of having a separate default value for pager.blame (or set
>> $LESS differently for blame) crossed my mind, but I actually don't like
>> it, as it would make it harder for a user to fine-tune his c
On Wed, May 07, 2014 at 03:40:28PM +, Jim Garrison wrote:
> During my initial self-education I came across the maxim "don't pull,
> fetch+merge instead" and have been doing that. I think I followed
> most of the "pull is (mostly) evil" discussion but one facet still
> puzzles me: the idea tha
On Wed, 2014-05-07 at 08:17 +0200, Johannes Sixt wrote:
> > } else if (cache_name_pos(src, length) < 0)
> > bad = _("not under version control");
> > - else if (lstat(dst, &st) == 0) {
> > + else if (lstat(dst, &dst_st) == 0 &&
> > +
Jim Garrison writes:
> During my initial self-education I came across the maxim "don't pull,
> fetch+merge instead" and have been doing that. I think I followed
> most of the "pull is (mostly) evil" discussion but one facet still
> puzzles me: the idea that pull will do a merge "in the wrong
> d
During my initial self-education I came across the maxim "don't pull,
fetch+merge instead" and have been doing that. I think I followed most of the
"pull is (mostly) evil" discussion but one facet still puzzles me: the idea
that pull will do a merge "in the wrong direction" sometimes.
Do I und
On 05/05/2014 09:48 AM, Chris Packham wrote:
Hi,
I know there are a few people on this list that do git training in
various forms. At $dayjob I've been asked to run a few training
sessions in house. The initial audience is SW developers so they are
fairly clued up on VCS concepts and most have s
---
.gitignore | 1 +
Makefile | 1 +
t/t7063-status-untracked-cache.sh (new +x) | 352 +
test-dump-untracked-cache.c (new) | 61 +
4 files changed, 415 insertions(+)
create mode 100755
Some numbers below. In short, the saving on wt_status_collect_untracked()
is about 80%. There are some overhead on read/write_cache, but it seems
lower than 50ms, while the .._untracked() saving is in the 500ms range
(except linux-2.6, about 150ms). "git status" time saving ranges from
33% to 42%.
---
builtin/update-index.c | 144 +
1 file changed, 144 insertions(+)
diff --git a/builtin/update-index.c b/builtin/update-index.c
index 003e28e..f18076b 100644
--- a/builtin/update-index.c
+++ b/builtin/update-index.c
@@ -46,6 +46,145 @@ static voi
---
read-cache.c | 24 +++-
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/read-cache.c b/read-cache.c
index 66c2279..72adcd6 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -258,20 +258,26 @@ static int ce_match_stat_basic(const struct cache_entry
*ce, struct
---
builtin/commit.c | 8
wt-status.c | 6 ++
2 files changed, 14 insertions(+)
diff --git a/builtin/commit.c b/builtin/commit.c
index 9cfef6c..1e45ff0 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -1327,6 +1327,14 @@ int cmd_status(int argc, const char **argv, const c
This could be used to verify correct behavior in tests
---
dir.c | 12
1 file changed, 12 insertions(+)
diff --git a/dir.c b/dir.c
index 18fe44c..58303ca 100644
--- a/dir.c
+++ b/dir.c
@@ -14,6 +14,8 @@
#include "pathspec.h"
#include "varint.h"
+#define TRACE_KEY "GIT_TRACE_UNTRA
Ideally we should replace untracked_cache_invalidate_path() with
untracked_cache_remove_from_index() and untracked_cache_add_to_index(),
and the two last functions will update untracked cache right away
instead of invalidating it and wait for read_directory() next time to
deal with it. But that may
When a directory is updated within the same second that its timestamp
is last saved, we cannot realize the directory has been updated by
checking timestamps. Assume the worst (something is update). See
29e4d36 (Racy GIT - 2005-12-20) for more information.
---
cache.h | 2 ++
dir.c| 6
FIXME: load check_only
---
dir.c| 107 +++
dir.h| 1 +
read-cache.c | 3 ++
3 files changed, 111 insertions(+)
diff --git a/dir.c b/dir.c
index b7d394a..3c61b42 100644
--- a/dir.c
+++ b/dir.c
@@ -2256,3 +2256,110 @@ void
Suppose untracked cache stores that in directory A we need to recurse
in A/B and A/C. Then A/B is removed. When read_directory() is executed
again, of course we detect that we only need to recurse in A/C when in
A, not A/B any more.
We need a way though to let the write phase know not to write A/B
This cuts down a signficant number of open(.gitignore) because most
directories usually don't have .gitignore files.
---
dir.c | 26 +-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/dir.c b/dir.c
index 63fa960..b5bfda8 100644
--- a/dir.c
+++ b/dir.c
@@ -1021
The idea is if we can capture all input and output of
read_directory_recursive() and verify at a later time that all the
input is the same, then read_directory_recursive() should produce the
same output, so we can bypass read_directory_recursive() and reuse the
cached output for the directory in qu
---
dir.c | 115 --
dir.h | 3 ++
2 files changed, 115 insertions(+), 3 deletions(-)
diff --git a/dir.c b/dir.c
index 34a10b2..a198aa8 100644
--- a/dir.c
+++ b/dir.c
@@ -568,6 +568,22 @@ static struct untracked_cache_dir *lookup_un
It's easy to see that if an existing .gitignore changes, its SHA-1
would be different and invalidate_gitignore() is called.
If .gitignore is removed, add_excludes() will treat it like an empty
.gitignore, which again should invalidate the cached directory data.
if .gitignore is added, lookup_untr
The main readdir loop in read_directory_recursive() is replaced with a
new one that checks if cached results of a directory is still valid.
If a file is added or removed from the index, the containing directory
is invalidated (but not its subdirs). If directory's mtime is changed,
the same happens
FIXME: save check_only
---
cache.h | 3 ++
dir.c| 91
dir.h| 1 +
read-cache.c | 12
4 files changed, 107 insertions(+)
diff --git a/cache.h b/cache.h
index 107ac61..06fcb6b 100644
--- a/cache.h
+++ b/cac
This also fixes the problem of silently ignoring .gitignore if the
full path exceeds PATH_MAX. Now add_excludes_from_file() will report
if it gets ENAMETOOLONG.
---
dir.c | 47 ---
dir.h | 2 +-
2 files changed, 29 insertions(+), 20 deletions(-)
diff -
First of all, thanks for pointing to many more big repos. I'll look at
them tomorrow. End-of-day report (or ranting :D) time.
The series now looks good enough for public eyes. I haven't run the
test suite with untracked cache on by default so confidence level is
not so high. Although I suspect rac
1 - 100 of 123 matches
Mail list logo
