Re: [PATCH] create_delta_index: simplify condition always evaluating to true

From: "Stefan Beller" The code sequence ' (1u << i) < hsize && i < 31 ' is a multi step process, whose first step requires that 'i' is already less that 31, otherwise the result (1u << i) is undefined (and 'undef_val < hsize' can therefore be assumed to be 'false'), and so the later test i <

Re: [PATCH v2] CEST is +0200 during April

Sorry I forgot to add him when I used `git send-email`. On Sat, 17 Aug 2013 02:36:44 -0400 Aaron Schrab wrote: > Mattias, the convention on this list is to send directly > to participants in the thread as well as the list. So > I've added Andreas as a recipient. > > At 05:52 +0200 17 Aug 2013,

Re: [PATCH v2] CEST is +0200 during April

Mattias, the convention on this list is to send directly to participants in the thread as well as the list. So I've added Andreas as a recipient. At 05:52 +0200 17 Aug 2013, Mattias Andrée wrote: - For example CET (which is 2 hours ahead UTC) is `+0200`. + For example CEST (which

[PATCH v2] CEST is +0200 during April

Signed-off-by: Mattias Andrée --- Documentation/date-formats.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/date-formats.txt b/Documentation/date-formats.txt index c000f08..61a836e 100644 --- a/Documentation/date-formats.txt +++ b/Documentation/date-formats.

[RFC] git-send-email: Cache generated message-ids, use them when prompting

This is mostly a proof of concept/RFC patch. The idea is for git-send-email to store the message-ids it generates, along with the Subject and Date headers of the message. When prompting for which Message-ID should be used in In-Reply-To, display a list of recent emails (identifed using the Date/Sub

Re: [PATCH] bash prompt: test the prompt with newline in repository path

On Fri, Aug 16, 2013 at 6:36 AM, SZEDER Gábor wrote: > This subtlety really warrants its own test, especially since I didn't > explait it in the log message or in an in-code comment back then, so s/explait/explain/ > add a test to excercise the prompt with newline characters in the path > to the

Re: [PATCH] Git segmentation faults if submodule path is empty.

On Fri, Aug 16, 2013 at 10:59:35AM -0700, Jharrod LaFon wrote: > Here is an updated patch with a test. Bits like this that should not be part of the commit message should either go after the "---" lines near the diffstat, or should come before a scissors line, like: Here is my new patch. --

Re: [PATCH 3/6] shallow: add setup_temporary_shallow()

On Fri, Aug 16, 2013 at 5:52 AM, Nguyễn Thái Ngọc Duy wrote: > This function is like setup_alternate_shallow() except that it does > not lock $GIT_DIR/shallow. It's supposed to be used when a program > generates temporary shallow for for use by another program, then throw s/for for/for/ > the sh

Re: [PATCH 2/6] shallow: only add shallow graft points to new shallow file

On Fri, Aug 16, 2013 at 5:52 AM, Nguyễn Thái Ngọc Duy wrote: > for_each_commit_graft() goes through all graft points and shallow > boudaries are just one special kind of grafting. If $GIT_DIR/shallow s/boudaries/boundaries/ > and $GIT_DIR/info/grafts are both present, write_shallow_commits may >

Re: [PATCH] bash prompt: test the prompt with newline in repository path

Am 16.08.2013 12:36, schrieb SZEDER Gábor: +repo_with_newline='repo +with +newline' + +test_expect_success 'prompt - with newline in path' ' This test must be skipped when the filesystem does not support LF in file names. Cf. the FUNNYNAMES prerequisite in t3600-rm.sh. + printf " (mas

Re: [PATCH] CET is only one hour ahead of UTC, it even says so in date.c

Mattias Andrée writes: > diff --git a/Documentation/date-formats.txt b/Documentation/date-formats.txt > index c000f08..4dbaafa 100644 > --- a/Documentation/date-formats.txt > +++ b/Documentation/date-formats.txt > @@ -11,11 +11,11 @@ Git internal format:: > It is ` `, where ` timestam

[PATCH] create_delta_index: simplify condition always evaluating to true

The code sequence ' (1u << i) < hsize && i < 31 ' is a multi step process, whose first step requires that 'i' is already less that 31, otherwise the result (1u << i) is undefined (and 'undef_val < hsize' can therefore be assumed to be 'false'), and so the later test i < 31 can always be optimiz

Re: [PATCH] rebase -i: fix cases ignoring core.commentchar

On Fri, Aug 16, 2013 at 5:44 PM, Eric Sunshine wrote: > eff80a9fd990de36 (Allow custom "comment char", 2013-01-16) added general > core.commentchar support but forgot to update git-rebase--interactive to > respect it. 180bad3d10fe3a7f (rebase -i: respect core.commentchar, > 2013-02-11) addressed

Re: git undo # last command

On Fri, Aug 16, 2013 at 04:21:59PM +0200, Saša Tomić wrote: > git commit ==> git reset --soft HEAD^ The commit does still exists, you can find it in the reflog. This is important if you for example commits a huge file and wants to remove it. That commit needs to be gc:ed too, and this is dangerous.

Re: [PATCH] rebase -i: fix cases ignoring core.commentchar

On Fri, Aug 16, 2013 at 5:55 PM, Eric Sunshine wrote: > On Fri, Aug 16, 2013 at 5:44 PM, Eric Sunshine > wrote: >> eff80a9fd990de36 (Allow custom "comment char", 2013-01-16) added general >> core.commentchar support but forgot to update git-rebase--interactive to >> respect it. 180bad3d10fe3a7f

[PATCH] rebase -i: fix cases ignoring core.commentchar

eff80a9fd990de36 (Allow custom "comment char", 2013-01-16) added general core.commentchar support but forgot to update git-rebase--interactive to respect it. 180bad3d10fe3a7f (rebase -i: respect core.commentchar, 2013-02-11) addressed this oversight but missed one instance of hard-coded '#' commen

Re: [PATCH] Git segmentation faults if submodule path is empty.

Here is an updated patch with a test. Git fails due to a segmentation fault if a submodule path is empty. Here is an example .gitmodules that will cause a segmentation fault: [submodule "foo-module"] path url = http://host/repo.git $ git status Segmentation fault (core dumped) This occurs be

[PATCH] git-send-email: kill $prompting variable

The variable $prompting is weird. It is only read in one place (when deciding whether to prompt for a Message-ID to use in In-Reply-To), and it will be false unless we've taken the completely unrelated branch filling in @initial_to. Prompting should be done if the info is needed, not if some unrel

Re: [PATCH] create_delta_index: simplify condition always evaluating to true

From: "Eric Sunshine" On Thu, Aug 15, 2013 at 5:34 PM, Stefan Beller wrote: When checking the previous lines in that function, we can deduce that hsize must always be smaller than (1u<<31), since 506049c7df2c6 (fix >4GiB source delta assertion failure), because entries is capped at an upper bo

Re: [PATCH] cherry-pick: allow "-" as abbreviation of '@{-1}'

Junio C Hamano wrote: > Thomas Rast writes: > >> Hiroshige Umino writes: >> >>> As "git cherry-pick -" or "git merge -" is convenient to >>> switch back to or merge the previous branch, >>> "git cherry-pick -" is abbreviation of "git cherry-pick @{-1}" >>> to pick up a commit from the previous

Re: [PATCH] Git segmentation faults if submodule path is empty.

OK, I'll incorporate Jeff's changes, add a test and resubmit the patch. Thanks, -- Jharrod LaFon OpenEye Scientific Software On Aug 16, 2013, at 7:14 AM, Jeff King wrote: > On Fri, Aug 16, 2013 at 09:09:58AM -0400, Jeff King wrote: > - if (parse_config_key(var, "submodule", &name, &nam

Re: duplicate objects in packfile

On Wed, Aug 14, 2013 at 11:39:34AM -0700, Junio C Hamano wrote: > > Older versions of JGit used to put duplicate objects in a pack, and > > IIRC Shawn declared that a bug in the packer and fixed it, so from > > that point of view, I think rejecting is probably the right thing, > > even though I th

Re: git undo # last command

On Fri, Aug 16, 2013 at 3:26 PM, Jeff King wrote: > On Fri, Aug 16, 2013 at 10:55:06AM +0200, Saša Tomić wrote: > >> it just occurred to me -- the command that I would REALLY like to have >> is simple: >> >> git undo >> >> which 'undo'es the last action that has not been pushed yet -- >> whichev

"git fmt-merge-msg" usage (was [PATCH v2 00/46] "struct pathspec" conversion and :(glob) and :(icase))

On 07/15/2013 11:43 PM, Junio C Hamano wrote: > [...] > This was a good exercise for git-imerge.[...] > > A few things I noticed: > [...] > > - The final step "imerge finish" gave me this ugliness: > > Merge commit 93d9353... into commit cb5d2fc7 > >Perhaps you can at least use the i

Re: [PATCH] lookup_object: split up displacement penalty for hash collisions

On Fri, Aug 16, 2013 at 05:57:22AM -0400, Jeff King wrote: > In that case, it seems like we would want to move B to the second > position. This lets the 2-hot case just keep swapping the hot items back > and forth as quickly as possible. To the detriment of C, D, etc, which > never get promoted. B

Re: git undo # last command

On Fri, Aug 16, 2013 at 10:55:06AM +0200, Saša Tomić wrote: > it just occurred to me -- the command that I would REALLY like to have > is simple: > > git undo > > which 'undo'es the last action that has not been pushed yet -- > whichever the action is. Similarly to the 'back' button in the > b

Re: [cygwin] Re: Lack of case-sensitive filename handling with git 1.7.9-1 for Cygwin 64-bit

On Fri, Aug 16, 2013 at 07:54:57AM -0400, Jason Pyeron wrote: > > The interesting thing here is, if you try this the other way > > around, you'll see the exact same effect. If you created the > > above git repo with 64 bit git, everything works exactly as > > in the 32 bit version and the two

RE: [cygwin] Re: Lack of case-sensitive filename handling with git 1.7.9-1 for Cygwin 64-bit

I just saw this on the cygwin list. > -Original Message- > From: Corinna Vinschen > Sent: Friday, August 16, 2013 4:18 > To: cyg...@cygwin.com > Subject: [cygwin] Re: Lack of case-sensitive filename > handling with git 1.7.9-1 for Cygwin 64-bit > > On Aug 16 10:32, Kal Sze wrote: > > I h

Re: Understanding Git Under The Hood: Trees

Hi Andreas, you gave me a lot of new insight and keywords I can google (Junio as well!). Thanks a lot! On Fri, Aug 16, 2013 at 11:12 AM, Andreas Ericsson wrote: > More or less, yes, but please don't confuse "directory tree" with "git > tree". They're not the same. A directory tree can contain mu

Re: [PATCH] Git segmentation faults if submodule path is empty.

On Fri, Aug 16, 2013 at 09:09:58AM -0400, Jeff King wrote: > > > - if (parse_config_key(var, "submodule", &name, &namelen, &key) < 0 || > > > !name) > > > + if (parse_config_key(var, "submodule", &name, &namelen, &key) < 0 || > > > !name || !value) > > > return 0; > > I think this is

Re: [PATCH] Git segmentation faults if submodule path is empty.

On Fri, Aug 16, 2013 at 08:48:43AM +0200, Jens Lehmann wrote: > > This patch addresses the issue by returning from the function if > > 'value' is null before the call to xstrdup is made. > > Hmm, I'm not sure silently ignoring the misconfiguration is the best > way to go. A submodule config havin

Re: [PATCH] CET is only one hour ahead of UTC

On Fri, Aug 16, 2013 at 12:58:20PM +0200, Mattias Andrée wrote: > > The standard email format as described by RFC 2822, for > > example -Thu, 07 Apr 2005 22:13:13 +0200\&. > > +Thu, 07 Apr 2005 22:13:13 +0100\&. > > .RE > > .PP > > ISO 8601 > > I when on a limb and assumed that these patches

Re: [PATCH] create_delta_index: simplify condition always evaluating to true

On Fri, Aug 16, 2013 at 7:43 AM, brian m. carlson wrote: > On Thu, Aug 15, 2013 at 09:37:40PM +0200, Stefan Beller wrote: >> When checking the previous lines in that function, we can deduct that >> hsize must always be smaller than (1u<<31), since 506049c7df2c6 >> (fix >4GiB source delta assertion

Re: [PATCH] create_delta_index: simplify condition always evaluating to true

On Thu, Aug 15, 2013 at 09:37:40PM +0200, Stefan Beller wrote: > When checking the previous lines in that function, we can deduct that > hsize must always be smaller than (1u<<31), since 506049c7df2c6 > (fix >4GiB source delta assertion failure), because the entries is the entries are > capped at

Re: [PATCH] CET is only one hour ahead of UTC

On Fri, 16 Aug 2013 12:54:11 +0200 Mattias Andrée wrote: > Signed-off-by: Mattias Andrée > --- > man1/git-commit-tree.1 | 6 +++--- > man1/git-commit.1 | 6 +++--- > man1/git-tag.1 | 6 +++--- > 3 files changed, 9 insertions(+), 9 deletions(-) > > diff --git a/man1/git-commit-tree

[PATCH] CET is only one hour ahead of UTC

Signed-off-by: Mattias Andrée --- man1/git-commit-tree.1 | 6 +++--- man1/git-commit.1 | 6 +++--- man1/git-tag.1 | 6 +++--- 3 files changed, 9 insertions(+), 9 deletions(-) diff --git a/man1/git-commit-tree.1 b/man1/git-commit-tree.1 index 2014cc3..1bef965 100644 --- a/man1/git-co

[PATCH] CET is only one hour ahead of UTC

Signed-off-by: Mattias Andrée --- date-formats.txt | 4 ++-- git-commit-tree.html | 4 ++-- git-commit.html | 4 ++-- git-tag.html | 4 ++-- 4 files changed, 8 insertions(+), 8 deletions(-) diff --git a/date-formats.txt b/date-formats.txt index c000f08..4dbaafa 100644 --- a/date

[PATCH] CET is only one hour ahead of UTC, it even says so in date.c

Signed-off-by: Mattias Andrée --- Documentation/date-formats.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/date-formats.txt b/Documentation/date-formats.txt index c000f08..4dbaafa 100644 --- a/Documentation/date-formats.txt +++ b/Documentation/date-form

[PATCH] bash prompt: test the prompt with newline in repository path

Newlines in the path to a git repository were not an issue for the git-specific bash prompt before commit efaa0c1532 (bash prompt: combine 'git rev-parse' executions in the main code path, 2013-06-17), because the path returned by 'git rev-parse --git-dir' was directly stored in a variable, and thi

Re: [PATCH] lookup_object: split up displacement penalty for hash collisions

On Fri, Aug 16, 2013 at 11:26:28AM +0200, Thomas Rast wrote: > > I trust the laptop numbers less because it has far more thermal (and > > thus throttling) issues, but the runs do show a significant difference, > > though less than you claimed. > > Well, as I feared... another run on the same lapt

[PATCH 4/6] upload-pack: delegate rev walking in shallow fetch to pack-objects

upload-pack has a special rev walking code for shallow recipients. It works almost like the similar code in pack-objects except: 1. in upload-pack, graft points could be added for deepening 2. also when the repository is deepened, the shallow point will be moved further away from the tip, but

[PATCH 5/6] list-objects: reduce one argument in mark_edges_uninteresting

mark_edges_uninteresting() is always called with this form mark_edges_uninteresting(revs->commits, revs, ...); Remove the first argument and let mark_edges_uninteresting figure that out by itself. It helps answer the question "are this commit list and revs related in any way?" when looking at m

[PATCH 6/6] list-objects: mark more commits as edges in mark_edges_uninteresting

The purpose of edge commits is to let pack-objects know what objects it can use as base, but does not need to include in the thin pack because the other side is supposed to already have them. So far we mark uninteresting parents of interesting commits as edges. But even an unrelated uninteresting c

[PATCH 1/6] Move setup_alternate_shallow and write_shallow_commits to shallow.c

Signed-off-by: Nguyễn Thái Ngọc Duy --- commit.h | 3 +++ fetch-pack.c | 53 + shallow.c| 54 ++ 3 files changed, 58 insertions(+), 52 deletions(-) diff --git a/commit.h b/commit.h in

[PATCH 2/6] shallow: only add shallow graft points to new shallow file

for_each_commit_graft() goes through all graft points and shallow boudaries are just one special kind of grafting. If $GIT_DIR/shallow and $GIT_DIR/info/grafts are both present, write_shallow_commits may catch both sets, accidentally turning some graft points to shallow boundaries. Don't do that.

[PATCH 3/6] shallow: add setup_temporary_shallow()

This function is like setup_alternate_shallow() except that it does not lock $GIT_DIR/shallow. It's supposed to be used when a program generates temporary shallow for for use by another program, then throw the shallow file away. Signed-off-by: Nguyễn Thái Ngọc Duy --- commit.h | 1 + shallow.c

Re: [RFC PATCH] During a shallow fetch, prevent sending over unneeded objects

On Mon, Aug 12, 2013 at 3:02 PM, Matthijs Kooijman wrote: > Hi Duy, > >> OK. Mathijs, do you want make a patch for it? > I'm willing, but: > - I don't understand the code and all of your comments well enough yet >to start coding right away (though I haven't actually invested enough >time

Re: [PATCH] lookup_object: split up displacement penalty for hash collisions

On 08/16/2013 11:26 AM, Thomas Rast wrote: > Thomas Rast writes: > >> Stefan Beller writes: >> >>> However please do check if this patch brings the promised performance >>> on your own, as you're likely using different hardware and another >>> software setup. Feel free to share your performance

Re: [PATCH] lookup_object: split up displacement penalty for hash collisions

Thomas Rast writes: > Stefan Beller writes: > >> However please do check if this patch brings the promised performance >> on your own, as you're likely using different hardware and another >> software setup. Feel free to share your performance differences. > > I get this on an i7-M620 laptop fro

Re: Understanding Git Under The Hood: Trees

On 2013-08-15 21:32, Erik Bernoth wrote: On Thu, Aug 15, 2013 at 7:31 PM, Junio C Hamano wrote: While the last statement applies to other parts of the system, it is not true for the in-core index design. We always had a flat index, and it is not cheating at all. The original "tree" was also a

git undo # last command

Hi to all, I've been using git for some time now, but I'm in no way a git expert. I typically hack my way through the variety of commands that git provides. I believe that most git users work similarly. it just occurred to me -- the command that I would REALLY like to have is simple: git undo

Re: [PATCH] lookup_object: split up displacement penalty for hash collisions

Stefan Beller writes: > A little background on hash tables first: > Consider you want to have the object X, which you'd expect at position > i, but because that place was already taken by B, it is not found at > position i, you start looking right of position i to find X until you > find it. > >

Re: [PATCH] Git segmentation faults if submodule path is empty.

Jharrod LaFon writes: > Git fails due to a segmentation fault if a submodule path is empty. > Here is an example .gitmodules that will cause a segmentation fault: > [submodule "foo-module"] > path > url = http://host/repo.git > $ git status > Segmentation fault (core dumped) Can you turn