Hello,
I'd like to know if that's possible to parse all notes to detect a
special string and if it's the case, remove the note like "git-notes
remove" would do.
Thanks
--
Francis
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.o
"brian m. carlson" writes:
> On Mon, Sep 09, 2013 at 09:45:10AM -0700, Junio C Hamano wrote:
>> "brian m. carlson" writes:
>> > --- a/git-send-email.perl
>> > +++ b/git-send-email.perl
>> > @@ -1234,7 +1234,7 @@ X-Mailer: git-send-email $gitversion
>> >if ($smtp->code
Johannes Sixt writes:
> Am 9/12/2013 17:24, schrieb Junio C Hamano:
>> Johannes Sixt writes:
>>
>>> Am 9/12/2013 1:32, schrieb Junio C Hamano:
* jc/ref-excludes (2013-09-03) 2 commits
>>
>> Thanks for a dose of sanity. I didn't look at rev-parse. I vaguely
>> recall somebody offered follo
Jiang Xin writes:
> 2013/9/13 Junio C Hamano :
>>
>> For systems that need POSIX escape hatch for Apollo Domain ;-), we
>> would need a bit more work. When both path1 and path2 begin with a
>> double-dash, we would need to check if they match up to the next
>> slash, so that
>>
>> - //host1/usr
Am 9/12/2013 17:24, schrieb Junio C Hamano:
> Johannes Sixt writes:
>
>> Am 9/12/2013 1:32, schrieb Junio C Hamano:
>>> * jc/ref-excludes (2013-09-03) 2 commits
>
> Thanks for a dose of sanity. I didn't look at rev-parse. I vaguely
> recall somebody offered follow-ups (was it you?) and at that p
Using a relative_path as git_dir first appears in v1.5.6-1-g044bbbc.
It will make git_dir shorter only if git_dir is inside work_tree,
and this will increase performance. But my last refactor effort on
relative_path function (commit v1.8.3-rc2-12-ge02ca72) changed that.
Always use relative_path as
In test cases for relative_path, path with one leading character
(such as /a, /x) may be recogonized as "a:/" or "x:/" if there is
such doc drive on MINGW platform. Use an umambigous leading path
"/foo" instead.
Signed-off-by: Jiang Xin
---
t/t0060-path-utils.sh | 56 +---
Tvangeste found that the "relative_path" function could not work
properly on Windows if "in" and "prefix" have dos driver prefix.
($gmane/234434)
e.g., When execute: test-path-utils relative_path "C:/a/b" "D:/x/y",
should return "C:/a/b", but returns "../../C:/a/b", which is wrong.
So make relati
Updates since v1:
* New patch 1/3 on t0060, which use umambigous leading path (/foo).
* Call tolower instead of strncasecmp in patch 2/3.
* Rename simple_relative_path to remove_leading_path in patch 3/3.
Jiang Xin (3):
test: use unambigous leading path (/foo) for mingw
relative_path should h
2013/9/13 Junio C Hamano :
>
> For systems that need POSIX escape hatch for Apollo Domain ;-), we
> would need a bit more work. When both path1 and path2 begin with a
> double-dash, we would need to check if they match up to the next
> slash, so that
>
> - //host1/usr/src and //host1/usr/lib shar
> When looking into this, I found a test in t5510 that appears to want to
> verify this very behavior:
>
>> test_expect_success 'fetch --prune --tags does not delete the
>> remote-tracking branches' '
The title tells me that it wants to make sure when pruning tags it does
not touch remote-trackin
A colleague of mine discovered, the hard way, that
git fetch --tags --prune $REMOTE
deletes all local tags that are not present on that particular remote.
To me this seems a dangerous and poorly-documented interaction of
features and arguably a bug.
Granted, it might not be such a good idea
On Thu, Sep 12, 2013 at 11:20 PM, Nicolas Pitre wrote:
> On Thu, 12 Sep 2013, Duy Nguyen wrote:
>
>> On Wed, Sep 11, 2013 at 11:25 PM, Nicolas Pitre wrote:
>> > On Wed, 11 Sep 2013, Duy Nguyen wrote:
>> >
>> >> Nico, if you have time you may want to look into this. The result v4
>> >> pack from p
On Thu, Sep 12, 2013 at 04:25:03PM -0700, Linus Torvalds wrote:
> On Thu, Sep 12, 2013 at 4:15 PM, Richard Hansen wrote:
> >
> > Is it worthwhile to poke a lawyer about this as a precaution? (If so,
> > who?) Or do we wait for a motivating event?
>
> I can poke the lawyer that was originally in
On Fri, Sep 13, 2013 at 3:21 AM, John Keeping wrote:
> On Thu, Sep 12, 2013 at 12:48:10PM -0700, Junio C Hamano wrote:
>> John Keeping writes:
>>
>> > This allows us to replace the submodule path trailing slash removal in
>> > builtin/rm.c with the PATHSPEC_STRIP_SUBMODULE_SLASH_CHEAP flag to
>>
No functional changes.
Signed-off-by: Felipe Contreras
---
GIT-VERSION-GEN | 36
1 file changed, 20 insertions(+), 16 deletions(-)
diff --git a/GIT-VERSION-GEN b/GIT-VERSION-GEN
index 06026ea..e96538d 100755
--- a/GIT-VERSION-GEN
+++ b/GIT-VERSION-GEN
@@ -6,
If the version is 'v1.8.4-rc1' that is the version, and there's no need
to change it to anything else, like 'v1.8.4.rc1'.
If RedHat, or somebody else, needs a specific version, they can use the
'version' file, like everybody else.
Signed-off-by: Felipe Contreras
---
GIT-VERSION-GEN | 4 +---
1
Felipe Contreras (2):
version-gen: cleanup
version-gen: avoid messing the version
GIT-VERSION-GEN | 36 +++-
1 file changed, 19 insertions(+), 17 deletions(-)
--
1.8.4-338-gefd7fa6
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body
On Wed, Sep 11, 2013 at 6:38 AM, Matthieu Moy
wrote:
> Felipe Contreras writes:
>
>> On Tue, Sep 10, 2013 at 3:26 AM, Matthieu Moy
>> wrote:
>>
>>> So, you insist in asking the user to chose between rebase and merge, but
>>> you also insist that they will not chose rebase? So, why ask?
>>
>> Bec
On Thu, Sep 12, 2013 at 5:01 PM, John Gietzen wrote:
> Background:
> Windows, git version 1.8.3.msysgit.0
> bare repo, 54k commits after migration from HG
> git filter-branch --prune-empty -- --all
>
> I'm trying to clean up our repository after migrating it from HG. I'm
> running the filter-bra
Eugene Sajine writes:
>> So even if we feed the exit status of the service process to the
>> hook script specified by the --post-service-hook, it does not tell
>> the script if the service "succeeded" in that sense.
>
> I see what you're saying.
> In my particular use case I can work around that
On Thu, Sep 12, 2013 at 4:15 PM, Richard Hansen wrote:
>
> Is it worthwhile to poke a lawyer about this as a precaution? (If so,
> who?) Or do we wait for a motivating event?
I can poke the lawyer that was originally involved. If people know
other lawyers, feel free to poke them too. Just ask t
On 2013-09-12 18:44, Linus Torvalds wrote:
> On Thu, Sep 12, 2013 at 3:30 PM, Junio C Hamano wrote:
>> Linus, this is not limited to us, so I am bothering you; sorry about
>> that.
>>
>> My instinct tells me that some competent lawyers at linux-foundation
>> helped you with the wording of DCO, and
On Thu, Sep 12, 2013 at 6:20 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Eugene Sajine writes:
>>
>>> So are you really sure that it is a non-starter to have
>>> --before-service/--after-service options for access-hook?
>>
>> Given the definition of "--access-hook" in "git help daemo
I certainly wouldn't recommend messing with the text of the DCO
without first consulting some lawyers. There should also be some
centralized coordination about any changes in the text and the version
number.
- Ted
--
To unsubscribe from this list: s
On Thu, Sep 12, 2013 at 3:30 PM, Junio C Hamano wrote:
> Linus, this is not limited to us, so I am bothering you; sorry about
> that.
>
> My instinct tells me that some competent lawyers at linux-foundation
> helped you with the wording of DCO, and we amateurs shouldn't be
> mucking with the text
Linus, this is not limited to us, so I am bothering you; sorry about
that.
My instinct tells me that some competent lawyers at linux-foundation
helped you with the wording of DCO, and we amateurs shouldn't be
mucking with the text like this patch does at all, but just in case
you might find it int
Junio C Hamano writes:
> Eugene Sajine writes:
>
>> So are you really sure that it is a non-starter to have
>> --before-service/--after-service options for access-hook?
>
> Given the definition of "--access-hook" in "git help daemon":
>
> --access-hook=::
> Every time a client co
Jonathan Nieder writes:
> Kyle J. McKay wrote:
>
>> The longer comment looks good to me. If you think the code will be safe from
>> simplification patches without a comment, that works for me too.
>
> I think if we can't trust reviewers to catch this kind of thing, we're
> in trouble (i.e., movi
The "Developer's Certificate of Origin" refers to "the open source
license indicated in the file", but there is no such indication in
most files in the Git repository.
Update the text to indicate that the license in COPYING should be
assumed if a file doesn't excplicitly indicate which license app
On Thu, Sep 12, 2013 at 5:16 PM, Eugene Sajine wrote:
> Junio,
>
> Thanks for the clarification! Your solution does look better.
>
> For now though i think i will have to delay the notification somehow
> and let the service finish first then notify the server.
>
> Thanks again!
>
> Eugene
>
>
> On
Background:
Windows, git version 1.8.3.msysgit.0
bare repo, 54k commits after migration from HG
git filter-branch --prune-empty -- --all
I'm trying to clean up our repository after migrating it from HG. I'm running
the filter-branch command listed above in an effort to clean up all of garbage
c
Kyle J. McKay wrote:
> The longer comment looks good to me. If you think the code will be safe from
> simplification patches without a comment, that works for me too.
I think if we can't trust reviewers to catch this kind of thing, we're
in trouble (i.e., moving too fast). :)
So FWIW my instinc
Sebastian Schuberth wrote:
> I'm not too happy with the wording either. As I see it, even on MinGW
> runtime version 4.0 it's not true that "string.h has _only_ inline
> definition of strcasecmp"; there's also "#define strncasecmp
> _strnicmp"
I assume you mean "#define strcasecmp _stricmp", whic
Sebastian Schuberth wrote:
> And that's exactly what defining __NO_INLINE__ does. Granted, defining
> __NO_INLINE__ in the scope of string.h will also add a "#define
> strcasecmp _stricmp"; but despite it's name, defining __NO_INLINE__
> does not imply a performance hit due to functions not being
On 2013-09-10 18:01, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Richard Hansen writes:
>>
>>> def do_export(parser):
>>> -global parsed_refs, dirname
>>> +global parsed_refs, dirname, transports
>>
>> As this has been acked by Felipe who knows the script the best, I'll
>> apply
Junio,
Thanks for the clarification! Your solution does look better.
For now though i think i will have to delay the notification somehow
and let the service finish first then notify the server.
Thanks again!
Eugene
On Thu, Sep 12, 2013 at 5:08 PM, Junio C Hamano wrote:
> Eugene Sajine writ
Eugene Sajine writes:
> So are you really sure that it is a non-starter to have
> --before-service/--after-service options for access-hook?
Given the definition of "--access-hook" in "git help daemon":
--access-hook=::
Every time a client connects, first run an external command
Richard Hansen writes:
>> Ping? I'd like to merge fc/contrib-bzr.hg-fixes topic to 'next'
>> (and fast track it to 'master' after that), and it would be helpful
>> to get an Ack on the conflict resolution I have.
>
> Sorry for the delay.
>
> Looks good to me, and the tests still pass.
Thanks.
On Wed, 11 Sep 2013, Jeff King wrote:
> On Tue, Sep 10, 2013 at 06:17:12PM -0400, Nicolas Pitre wrote:
>
> > Also remove the modulus as this is an expansive operation.
> > The size argument is always a power of 2 anyway, so a simple
> > mask operation provides the same result.
> >
> > On a 'git
On Thu, Sep 12, 2013 at 3:15 PM, Junio C Hamano wrote:
> Eugene Sajine writes:
>
>> Is it possible to have access-hook to be executed after receive?
>
> The whole point of access-hook is to allow it to decide whether the
> access is allowed or not, so that is a non-starter.
>
> A notification _af
On Sep 12, 2013, at 11:30, Junio C Hamano wrote:
+ /* append_normalized_escapes can cause norm.buf to change */
+ seg_start = norm.buf + seg_start_off;
The change looks good, but I find that this comment is not placed in
the right place. It is good if the reader kn
Nicolas Pitre writes:
>> Maybe it's worth squashing in one or both of the comments below as a
>> warning to anybody who tries to tweak it.
>
> Agreed.
>
> @Junio: are you willing to squash those in, or do you prefer a resent?
I think I've queued it ready to be squashed. No need for resend.
Tha
Jeff King writes:
> I think there are basically three classes of solution:
>
> 1. Declare __NO_INLINE__ everywhere. I'd worry this might affect other
> environments, who would then not inline and lose performance (but
> since it's a non-standard macro, we don't really know what it wil
> -Original Message-
> From: Jeff King
> Sent: Thursday, September 12, 2013 3:57 PM
>
> On Thu, Sep 12, 2013 at 12:45:44PM +, Pyeron, Jason J CTR (US)
> wrote:
>
> > If the rules of engagement are change a bit, the server side can be
> release from most of its work (CPU/IO).
> >
> > C
John Keeping writes:
> This allows us to replace the submodule path trailing slash removal in
> builtin/rm.c with the PATHSPEC_STRIP_SUBMODULE_SLASH_CHEAP flag to
> parse_pathspec() without changing the behaviour with respect to multiple
> trailing slashes.
Where does prefix_pathspec()'s input,
Am 12.09.2013 21:24, schrieb John Keeping:
> This allows us to correctly removing trailing backslashes on Windows
> when checking for submodules.
>
> Signed-off-by: John Keeping
> ---
> pathspec.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/pathspec.c b/pathspe
Sebastian Schuberth writes:
> I'm not too happy with the wording either. As I see it, even on MinGW
> runtime version 4.0 it's not true that "string.h has _only_ inline
> definition of strcasecmp"; there's also "#define strncasecmp
> _strnicmp" which effectively provides a non-inline definition o
On Thu, Sep 12, 2013 at 12:45:44PM +, Pyeron, Jason J CTR (US) wrote:
> If the rules of engagement are change a bit, the server side can be release
> from most of its work (CPU/IO).
>
> Client does the following, looping as needed:
>
> Heads=server->heads();
> KnownCommits=Local->AllCommits
On Thu, Sep 12, 2013 at 8:38 PM, Jonathan Nieder wrote:
> Looks good to me, but
>
>> -- >8 --
>> Subject: [PATCH] mailmap: work around implementations with pure inline
>> strcasecmp
>>
>> On some systems, string.h has _only_ inline definition of strcasecmp
>
> Please specify which system we are
On Thu, Sep 12, 2013 at 09:46:51PM +0200, Sebastian Schuberth wrote:
> > Right, option 3 seems perfectly reasonable to me, as we must be prepared
> > to cope with a decision not to inline the function, and there has to be
> > _some_ linked implementation. But shouldn't libc be providing an
> > ext
On Thu, Sep 12, 2013 at 12:48:10PM -0700, Junio C Hamano wrote:
> John Keeping writes:
>
> > This allows us to replace the submodule path trailing slash removal in
> > builtin/rm.c with the PATHSPEC_STRIP_SUBMODULE_SLASH_CHEAP flag to
> > parse_pathspec() without changing the behaviour with respe
Instead of re-implementing the "remove trailing slashes" loop in
builtin/rm.c just pass PATHSPEC_STRIP_SUBMODULE_SLASH_CHEAP to
parse_pathspec.
Signed-off-by: John Keeping
---
builtin/rm.c | 20
1 file changed, 4 insertions(+), 16 deletions(-)
diff --git a/builtin/rm.c b/bu
On Thu, Sep 12, 2013 at 8:20 PM, Jeff King wrote:
>> > I wonder if GCC has changed it's behaviour to more closely match C99.
>> > Clang as a compatibility article about this sort of issue:
>> >
>> > http://clang.llvm.org/compatibility.html#inline
>>
>> Interesting. The ways the page suggests
On Thu, Sep 12, 2013 at 12:35:32PM +0200, Josef Wolf wrote:
> I'm not sure I understand correctly. I see that bitmaps can be used to
> implement set operations. But how comes that walking the graph requires a lot
> of CPU? Isn't it O(n)?
Yes and no. Your "n" there is the entirety of history. Wher
"Kyle J. McKay" writes:
> So how about this patch instead...
>
> -- 8< --
> From: Thomas Rast
> Subject: urlmatch.c: recompute pointer after append_normalized_escapes
>
> When append_normalized_escapes is called, its internal strbuf_add* calls can
> cause the strbuf's buf to be reallocated chang
This allows us to correctly removing trailing backslashes on Windows
when checking for submodules.
Signed-off-by: John Keeping
---
pathspec.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/pathspec.c b/pathspec.c
index ad1a9f5..7c6963b 100644
--- a/pathspec.c
+++ b/path
Changes since v1:
* Improvements to existing pathspec code to use is_dir_sep instead of
comparing against '/' and handle multiple trailing slashes
* Remove calls to read_cache() made redundant by a new call in
builtin/reset.c::parse_args()
John Keeping (4):
pathspec: use is_dir_sep() to che
When using tab-completion, a directory path will often end with a
trailing slash which currently confuses "git reset" when dealing with
submodules. Now that we have parse_pathspec we can easily handle this
by simply adding the PATHSPEC_STRIP_SUBMODULE_SLASH_CHEAP flag.
To do this, we need to move
This allows us to replace the submodule path trailing slash removal in
builtin/rm.c with the PATHSPEC_STRIP_SUBMODULE_SLASH_CHEAP flag to
parse_pathspec() without changing the behaviour with respect to multiple
trailing slashes.
Signed-off-by: John Keeping
---
pathspec.c | 27 +--
Eugene Sajine writes:
> Is it possible to have access-hook to be executed after receive?
The whole point of access-hook is to allow it to decide whether the
access is allowed or not, so that is a non-starter.
A notification _after_ successful push update is usually done via
the post-receive hoo
Johannes Sixt writes:
> Am 12.09.2013 16:13, schrieb Torsten Bögershausen:
>> On 2013-09-12 11.12, Jiang Xin wrote:
>>> +static int have_same_root(const char *path1, const char *path2)
>>> +{
>>> + int is_abs1, is_abs2;
>>> +
>>> + is_abs1 = is_absolute_path(path1);
>>> + is_abs2 = is_absol
Repro:
1. git clone --recursive a repository with submodules.
2. cd checkout/submoduleA
3. git svn init svn://host/repo
Expected:
Works as usual
Actual:
/path/to/checkout/submoduleA/.git/refs: Not a directory
init: command returned error: 1
Why:
submoduleA/.git is a file, not a directory.
$ cat
On Thu, Sep 12, 2013 at 11:35:21AM -0700, Junio C Hamano wrote:
> >> - change it to a "statis inline";
> >> - remove "inline" from the definition;
> >> - provide an external (non-inline) def somewhere else;
> >> - compile with gnu899 dialect.
> >
> > Right, option 3 seems perfectly reasonable
Hi,
We are serving repos in closed netwrok via git protocol. We are using
git-daemon access hook (thank you very much for such a great feature)
in order to create push notifications for Jenkins.
I.e. upon the push the access-hook is called and then the curl command
is created and executed. As we
Am 12.09.2013 11:12, schrieb Jiang Xin:
> Using a relative_path as git_dir first appears in v1.5.6-1-g044bbbc.
> It will make git_dir shorter only if git_dir is inside work_tree,
> and this will increase performance. But my last refactor effort on
> relative_path function (commit v1.8.3-rc2-12-ge02
Jeff King writes:
> On Thu, Sep 12, 2013 at 08:37:08AM -0700, Junio C Hamano wrote:
>
>> > I wonder if GCC has changed it's behaviour to more closely match C99.
>> > Clang as a compatibility article about this sort of issue:
>> >
>> > http://clang.llvm.org/compatibility.html#inline
>>
>> Int
Junio C Hamano wrote:
> I think we would want something like below.
Looks good to me, but
> -- >8 --
> Subject: [PATCH] mailmap: work around implementations with pure inline
> strcasecmp
>
> On some systems, string.h has _only_ inline definition of strcasecmp
Please specify which system we are
Jeff King writes:
> This description is slightly inaccurate since the re-roll. I think it is
> now:
>
> "git config" did not provide a way to set or access numbers larger
> than a native "int" on the platform; it now provides 64-bit signed
> integers on all platforms.
>
> Not a big deal, bu
Thanks very much for the feedback and implementation suggestions.
> If the only thing you are interested in supporting is a one-shot
> invocation, i.e. giving which identity file to use from the command
> line when you run either "git push" or "git fetch",
Yes, this is the new option that could b
As noted in several forums, a recommended way to move trees between
repositories
is to use git-filter-branch to revise the history for a single tree:
http://gbayer.com/development/moving-files-from-one-git-repository-to-anoth
er-preserving-history/
http://stackoverflow.com/questions/1365541/how-to
On Thu, Sep 12, 2013 at 08:37:08AM -0700, Junio C Hamano wrote:
> > I wonder if GCC has changed it's behaviour to more closely match C99.
> > Clang as a compatibility article about this sort of issue:
> >
> > http://clang.llvm.org/compatibility.html#inline
>
> Interesting. The ways the page
Thanks, both.
--
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
Am 12.09.2013 16:13, schrieb Torsten Bögershausen:
> On 2013-09-12 11.12, Jiang Xin wrote:
>> +static int have_same_root(const char *path1, const char *path2)
>> +{
>> +int is_abs1, is_abs2;
>> +
>> +is_abs1 = is_absolute_path(path1);
>> +is_abs2 = is_absolute_path(path2);
>> +retur
On Thu, 12 Sep 2013, Duy Nguyen wrote:
> On Wed, Sep 11, 2013 at 11:25 PM, Nicolas Pitre wrote:
> > On Wed, 11 Sep 2013, Duy Nguyen wrote:
> >
> >> Nico, if you have time you may want to look into this. The result v4
> >> pack from pack-objects on git.git for me is 35MB (one branch) while
> >> pa
Jeff King writes:
> We already have GIT_SSH, so I would expect:
>
> GIT_SSH='ssh -i $HOME/.ssh/id_for_example_com' git push
>
> to work. But sadly, GIT_SSH does not use the shell, unlike most other
> configure git commands. :(
You read me correctly ;-)
> We could consider it a consistency bug
Torsten Bögershausen writes:
>> +static int have_same_root(const char *path1, const char *path2)
>> +{
>> +int is_abs1, is_abs2;
>> +
>> +is_abs1 = is_absolute_path(path1);
>> +is_abs2 = is_absolute_path(path2);
>> +return (is_abs1 && is_abs2 && !strncasecmp(path1, path2, 1)) ||
>
Am 12.09.2013 11:12, schrieb Jiang Xin:
> Tvangeste found that the "relative_path" function could not work
> properly on Windows if "in" and "prefix" have dos driver prefix.
> ($gmane/234434)
>
> e.g., When execute: test-path-utils relative_path "C:/a/b" "D:/x/y",
> should return "C:/a/b", but ret
John Keeping writes:
> On Thu, Sep 12, 2013 at 11:36:56AM +0200, Sebastian Schuberth wrote:
>> > Just wondering if that is the root of the problem, or if maybe there is
>> > something else subtle going on. Also, does __CRT_INLINE just turn into
>> > "inline", or is there perhaps some other pre-pr
On Tue, 10 Sep 2013, Duy Nguyen wrote:
> On Mon, Sep 9, 2013 at 10:01 PM, Nicolas Pitre wrote:
> > However this means that the progress meter will now be wrong and that's
> > terrible ! Users *will* complain that the meter doesn't reach 100% and
> > they'll protest for being denied the remaining
"Kyle J. McKay" writes:
> Also some nits. The patch description should be imperative mood
> (cf. Documentation/SubmittingPatches).
Heh. Serves me right to go away for a while and get SubmittingPatches
cited at me on return ;-)
Thanks for the updated patch. I agree with the changes. I partic
Johannes Sixt writes:
> Am 9/12/2013 1:32, schrieb Junio C Hamano:
>> * jc/ref-excludes (2013-09-03) 2 commits
>> - document --exclude option
>> - revision: introduce --exclude= to tame wildcards
>>
>> People often wished a way to tell "git log --branches" (and "git
>> log --remotes --not --
On 2013-09-12 11.12, Jiang Xin wrote:
> Tvangeste found that the "relative_path" function could not work
> properly on Windows if "in" and "prefix" have dos driver prefix.
> ($gmane/234434)
>
> e.g., When execute: test-path-utils relative_path "C:/a/b" "D:/x/y",
> should return "C:/a/b", but retur
On Sep 12, 2013, at 02:57, Thomas Rast wrote:
> The calls to strbuf_add* within append_normalized_escapes() can
> reallocate the buffer passed to it. Therefore, the seg_start pointer
> into the string cannot be kept across such calls.
Thanks for finding this.
> It went undetected for a while be
"git log --stat -1 v1.4.8 >/dev/null" takes 13s with v4 (8s with
v2). Of course we could do better when v4-aware tree-diff interface is
in place..
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Oops.. forgot this and broke git.
Another option is change cache_or_unpack_entry() to force
OBJ_PV4_TR
> -Original Message-
> From: Jeff King
> Sent: Thursday, September 12, 2013 5:24 AM
>
> On Thu, Sep 12, 2013 at 09:42:41AM +0200, Josef Wolf wrote:
>
> > > >> There are some work being done to optimize this further using
> > > >> various techniques, but they are not ready yet.
> > >
> > >
This turns the template COMMIT_EDITMSG from e.g
# [...]
# Changes to be committed:
# (use "git reset HEAD ..." to unstage)
#
# modified: builtin/commit.c
#
# Untracked files:
# (use "git add ..." to include in what will be committed)
#
# t/foo
#
to
# [...]
cmd_commit and cmd_status use very similar code to initialize the
wt_status structure. Factor this code into a function to ensure future
changes will keep both versions consistent.
Signed-off-by: Matthieu Moy
---
New patch, as discussed with Peff.
builtin/commit.c | 18 ++
1 fil
No behavior change in this patch, but this makes the display of status
hints more flexible as they can be enabled or disabled for individual
calls to commit.c:run_status().
Signed-off-by: Matthieu Moy
---
No real change since v1, just a slight adaptation after the PATCH 1.
builtin/commit.c | 1
On Do, Sep 12, 2013 at 05:23:40 -0400, Jeff King wrote:
> On Thu, Sep 12, 2013 at 09:42:41AM +0200, Josef Wolf wrote:
>
> I think Junio is referring to the reachability bitmap work. We may know
> that the other side has commit "E" (and therefore every object reachable
> from it), but we do not walk
Signed-off-by: Nguyễn Thái Ngọc Duy
---
The memmove in pv4_get_tree() may look inefficient. I added a
heuristics to avoid moving if nb_entries takes 2 bytes (most common,
I think), but it does not improve much. So memmove() is probably ok.
packv4-parse.c | 60
The intention is to store flat v4 trees in delta base cache to avoid
repeatedly expanding copy sequences in v4 trees. When the user needs
to unpack a v4 tree and the tree is found in the cache, the tree will
be converted back to canonical format. Future tree_desc interface may
skip canonical format
"git rev-list --objects v1.8.4" time is reduced from 29s to 10s with
this patch. But it is still a long way to catch up with v2: 4s.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
The problem I see with decode_entries() is that given n copy
sequences, it re-reads the same base n times. 30+ copy sequen
We do know the length of the path name of an tree entry from the tree
dictionary. On an unoptimized build, this cuts down "git rev-list
--objects v1.8.4"'s time from 6.2s to 5.8s. This difference is less on
optimized builds.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
packv4-parse.c | 23 +++
On Thu, Sep 12, 2013 at 11:36:56AM +0200, Sebastian Schuberth wrote:
> > Just wondering if that is the root of the problem, or if maybe there is
> > something else subtle going on. Also, does __CRT_INLINE just turn into
> > "inline", or is there perhaps some other pre-processor magic going on?
>
>
The calls to strbuf_add* within append_normalized_escapes() can
reallocate the buffer passed to it. Therefore, the seg_start pointer
into the string cannot be kept across such calls.
The actual bug is from 3402a8d (config: add helper to normalize and
match URLs, 2013-07-31). It can first be dete
On Thu, Sep 12, 2013 at 11:44:30AM +0200, Matthieu Moy wrote:
> That is clean, but a bit long and it is essentially duplicated between
> status and commit. I went another way: put all the similar code in a
> common function status_init_config:
>
> static void status_init_config(struct wt_status *
Jeff King writes:
> On Wed, Sep 11, 2013 at 11:08:58AM +0200, Matthieu Moy wrote:
>
>> No behavior change in this patch, but this makes the display of status
>> hints more flexible as they can be enabled or disabled for individual
>> calls to commit.c:run_status().
>> [...]
>> +static void status
Thank you, this fixes the problem with `git svn rebase` on Windows for me.
--Tvangeste
On Thu, Sep 12, 2013 at 11:12 AM, Jiang Xin wrote:
> Tvangeste found that the "relative_path" function could not work
> properly on Windows if "in" and "prefix" have dos driver prefix.
> ($gmane/234434)
>
> e.
On Wed, Sep 11, 2013 at 11:41 PM, Jeff King wrote:
>> I'm on Windows using MSYS / MinGW. Since MinGW runtime version 4.0,
>> string.h contains the following code (see [1]):
>>
>> #ifndef __NO_INLINE__
>> __CRT_INLINE int __cdecl __MINGW_NOTHROW
>> strncasecmp (const char * __sz1, const char * __s
1 - 100 of 107 matches
Mail list logo
