Re: [PATCH v3 4/4] cache-tree: do not generate empty trees as a result of all i-t-a subentries

Nguyễn Thái Ngọc Duy writes: > diff --git a/cache-tree.c b/cache-tree.c > index c2676e8..2d50640 100644 > --- a/cache-tree.c > +++ b/cache-tree.c > @@ -380,6 +380,13 @@ static int update_one(struct cache_tree *it, > continue; > } > > +

[PATCH 4/9] bisect--helper: `bisect_clean_state` shell function in C

Reimplement `bisect_clean_state` shell function in C and add a `bisect-clean-state` subcommand to `git bisect--helper` to call it from git-bisect.sh . Using `--bisect-clean-state` subcommand is a measure to port shell function to C so as to use the existing test suite. As more functions are

[GSOC Update] Week 10

= SUMMARY == My public git.git is available here[1]. I regularly keep pushing my work so anyone interested can track me there. Feel free to participate in the discussions going on PRs with my mentors. Your comments are valuable.

windows 10 git 2.9.0 with vim 7.4.1023 display editing bug

I am using git 2.9.0.windows.1 in windows 10. With core.editor set to vim. Vim was downloaded from vim.org latest version binary: VIM - Vi IMproved 7.4.1023 (2013 Aug 10, compiled Jan 2 2016 14:24:35) MS-Windows 32-bit console version When I do a git commit in a cmd window, it goes into a vim

Re: [PATCH 0/5] Number truncation with 4+ GB files on 32-bit systems

Nguyễn Thái Ngọc Duy writes: > Since I now could reproduce the problem that Christoph showed, I > decided to send the good patches out. To sum up, we use "unsigned > long" in some places related to file size. On 32-bit systems, it's > limited to 32 bits even though the system

Re: [PATCH v3 00/16] Use merge_recursive() directly in the builtin am

Johannes Schindelin writes: > This is the second iteration of the long-awaited re-roll of the attempt to > avoid spawning merge-recursive from the builtin am and use merge_recursive() > directly instead. This is actually the third iteration. I am trying to tease

Re: [PATCH v3 1/4] test-lib.sh: introduce and use $_EMPTY_TREE

Nguyễn Thái Ngọc Duy writes: > This is a special SHA1. Let's keep it at one place, easier to replace > later when the hash change comes, easier to recognize. Start with an > underscore to reduce the chances somebody may override it without > realizing it's predefined. > >

Re: [PATCH v3 2/8] doc: revisions - name the Left and Right sides

From: "Junio C Hamano" Philip Oakley writes: The terms Left and Right side originate from the symmetric difference. Name them there. --- Sign-off? Oops - will fix. Documentation/revisions.txt | 2 +- 1 file changed, 1 insertion(+), 1

Re: [PATCH v3 7/8] doc: revisions - define `reachable`

From: "Marc Branchaud" On 2016-07-11 04:25 PM, Philip Oakley wrote: Do not self-define `reachable`, which can lead to misunderstanding. Instead define `reachability` explictly. Signed-off-by: Philip Oakley --- Documentation/revisions.txt | 14

Re: [PATCH v3 4/8] doc: give headings for the two and three dot notations

From: "Junio C Hamano" Marc Branchaud writes: +The '{caret}' (caret) notation +~~~ To exclude commits reachable from a commit, a prefix '{caret}' notation is used. E.g. '{caret}r1 r2' means commits reachable from

Re: What's cooking in git.git (Jun 2016, #05; Thu, 16)

Torsten Bögershausen wrote re jh/clean-smudge-annex: > The thing is that we need to check the file system to find .gitatttibutes, > even if we just did it 1 nanosecond ago. > > So the .gitattributes is done 3 times: > -1 would_convert_to_git_filter_fd( > -2

Re: [PATCH v3 4/8] doc: give headings for the two and three dot notations

On Tue, Jul 12, 2016 at 10:41:35PM +0100, Philip Oakley wrote: > > > +The '{caret}' (caret) notation > > > +~~~ > > > To exclude commits reachable from a commit, a prefix '{caret}' > > > notation is used. E.g. '{caret}r1 r2' means commits reachable > > > from

[PATCH 3/9] bisect--helper: `write_terms` shell function in C

Reimplement the `write_terms` shell function in C and add a `write-terms` subcommand to `git bisect--helper` to call it from git-bisect.sh . Also remove the subcommand `--check-term-format` as it can now be called from inside the function write_terms() C implementation. Also `|| exit` is added

[PATCH 0/9] Resend of gitster/pb/bisect

Hey Junio, A small mistake got unnoticed by me which Lars recently pointed out. The naming convention is "git_path_" and underscore instead of spaces. Thanks! The interdiff is: diff --git a/builtin/bisect--helper.c b/builtin/bisect--helper.c index c2f3cee..88a1df8 100644 ---

[PATCH 9/9] bisect--helper: `bisect_write` shell function in C

Reimplement the `bisect_write` shell function in C and add a `bisect-write` subcommand to `git bisect--helper` to call it from git-bisect.sh Using `--bisect-write` subcommand is a temporary measure to port shell function in C so as to use the existing test suite. As more functions are ported,

[PATCH 5/9] t6030: explicitly test for bisection cleanup

Add test to explicitly check that 'git bisect reset' is working as expected. This is already covered implicitly by the test suite. Mentored-by: Lars Schneider Mentored-by: Christian Couder Signed-off-by: Pranit Bauva

[PATCH 7/9] bisect--helper: `bisect_reset` shell function in C

Reimplement `bisect_reset` shell function in C and add a `--bisect-reset` subcommand to `git bisect--helper` to call it from git-bisect.sh . Using `bisect_reset` subcommand is a temporary measure to port shell functions to C so as to use the existing test suite. As more functions are ported, this

[PATCH 2/9] bisect: rewrite `check_term_format` shell function in C

Reimplement the `check_term_format` shell function in C and add a `--check-term-format` subcommand to `git bisect--helper` to call it from git-bisect.sh Using `--check-term-format` subcommand is a temporary measure to port shell function to C so as to use the existing test suite. As more

[PATCH 1/9] bisect--helper: use OPT_CMDMODE instead of OPT_BOOL

`--next-all` is meant to be used as a subcommand to support multiple "operation mode" though the current implementation does not contain any other subcommand along side with `--next-all` but further commits will include some more subcommands. Helped-by: Johannes Schindelin

[PATCH 8/9] bisect--helper: `is_expected_rev` & `check_expected_revs` shell function in C

Reimplement `is_expected_rev` & `check_expected_revs` shell function in C and add a `--check-expected-revs` subcommand to `git bisect--helper` to call it from git-bisect.sh . Using `--check-expected-revs` subcommand is a temporary measure to port shell functions to C so as to use the existing

Re: [PATCH v3 4/8] doc: give headings for the two and three dot notations

From: "Marc Branchaud" On 2016-07-11 04:25 PM, Philip Oakley wrote: While there, also break out the other shorthand notations and add a title for the revision range summary (which also appears in git-rev-parse, so keep it mixed case). Signed-off-by: Philip Oakley

Re: [PATCH v3 0/8] Name for A..B ranges?

From: "Junio C Hamano" Philip Oakley writes: This is the re-roll of the po/range-doc (2016-07-01) 3 commits and its follow on patch. The series has gained additional patches following the discussions ($gmane/298790). .. The patches can be squashed

[PATCH 6/9] wrapper: move is_empty_file() and rename it as is_empty_or_missing_file()

is_empty_file() can help to refactor a lot of code. This will be very helpful in porting "git bisect" to C. Suggested-by: Torsten Bögershausen Mentored-by: Lars Schneider Mentored-by: Christian Couder Signed-off-by: Pranit Bauva

Re: [ANNOUNCE] Git v2.9.1

Hi Junio & Peff, On Mon, 11 Jul 2016, Junio C Hamano wrote: > Those who care about 32-bit builds need to start building and > testing 'next' and 'master' regularly, or similar breakages are > bound to continue happening X-<. Please note that "unsigned long" is 32-bit even on 64-bit Windows.

Re: [RFC] Long running Git clean/smudge filter

> On 10 Jul 2016, at 17:10, Joey Hess wrote: > > larsxschnei...@gmail.com wrote: >> (2) Joey's topic, which is the base for my patch, looks stalled for more than >> 2 weeks: >> http://thread.gmane.org/gmane.comp.version-control.git/297994/focus=298006 >> I would be happy to

[PATCH] gitk: ru.po: Update Russian translation

Signed-off-by: Dimitriy Ryazantcev --- po/ru.po | 640 --- 1 file changed, 328 insertions(+), 312 deletions(-) diff --git a/po/ru.po b/po/ru.po index 17ed026..6a00dc2 100644 --- a/po/ru.po +++ b/po/ru.po

Re: [ANNOUNCE] Git v2.9.1

Johannes Schindelin writes: > @@ -88,11 +88,11 @@ static int local_tzoffset(unsigned long time) > return offset * eastwest; > } > > -void show_date_relative(unsigned long time, int tz, > +void show_date_relative(time_t time, int tz, >

Re: [RFC/PATCH 8/8] read-cache: unlink old sharedindex files

On Mon, Jul 11, 2016 at 8:27 PM, Duy Nguyen wrote: > On Mon, Jul 11, 2016 at 7:22 PM, Christian Couder > wrote: >> Everytime split index is turned on, it creates a "sharedindex." >> file in the git directory. This makes sure that old sharedindex

Re: [ANNOUNCE] Git v2.9.1

On Tue, Jul 12, 2016 at 09:30:28AM +0200, Johannes Schindelin wrote: > On Mon, 11 Jul 2016, Junio C Hamano wrote: > > > Those who care about 32-bit builds need to start building and > > testing 'next' and 'master' regularly, or similar breakages are > > bound to continue happening X-<. > >

Re: git push doesn't update the status with multiple remotes

Thanks for the quick reply. On 12/07/16 06:26, Johannes Sixt wrote: Am 11.07.2016 um 18:54 schrieb Garoe: I have a repository on github, a clone on my desktop and bare repo on a private server, in my desktop the remotes looks like this allg...@github.com:user/repo.git (fetch) all

Re: [ANNOUNCE] Git v2.9.1

On Tue, Jul 12, 2016 at 11:12:25AM -0700, Junio C Hamano wrote: > Johannes Schindelin writes: > > >> Cool! Thanks for working on this. > > > > Well, I had to. Git for Windows v2.9.1 needs to get released, and I won't > > do that with a failing test suite. > > Let's

Re: Submodule's .git file contains absolute path when created using 'git clone --recursive'

Stefan Beller google.com> writes: > > On Thu, May 5, 2016 at 12:20 PM, Loet Avramson forter.com> wrote: > > It happened on 2.8.1, also reproducible on 2.8.2. > > Haven't had the time to dive deeper into the code but my guess is that > > relative_path() returns different results in those 2

Re: [ANNOUNCE] Git v2.9.1

Hi Peff, On Tue, 12 Jul 2016, Jeff King wrote: > On Tue, Jul 12, 2016 at 09:30:28AM +0200, Johannes Schindelin wrote: > > > FWIW I have this monster patch as a starting point (I plan to work more on > > this today): > > Cool! Thanks for working on this. Well, I had to. Git for Windows v2.9.1

Re: [ANNOUNCE] Git v2.9.1

Johannes Schindelin writes: >> PRIuMAX isn't compatible with time_t. > > That statement is wrong. No, it isn't. PRIuMAX is for uintmax_t, and time_t is not uintmax_t (even if they happen to have the same representation). Andreas. -- Andreas Schwab, sch...@linux-m68k.org

Re: gc and repack ignore .git/*HEAD when checking reachability

Hi Junio, On Mon, 11 Jul 2016, Junio C Hamano wrote: > Johannes Schindelin writes: > > >> No, the point is, refs subsystem needs to know which refs is per-repo, > >> which is per-worktree. So far the rules are "everything under refs, > >> except a few known

Re: Fast-forward able commit, otherwise fail

Junio C Hamano wrote: > Another thing to consider is that the proposed workflow would not > scale if your team becomes larger. Requiring each and every commit > on the trunk to be a merge commit, whose second parent (i.e. the tip > of the feature branch) fast-forwards to the

Re: [ANNOUNCE] Git v2.9.1

Johannes Schindelin writes: > Hi Andreas, > > On Tue, 12 Jul 2016, Andreas Schwab wrote: > >> Johannes Schindelin writes: >> >> >> PRIuMAX isn't compatible with time_t. >> > >> > That statement is wrong. >> >> No, it isn't. PRIuMAX is for

Re: What's cooking in git.git (Jul 2016, #04; Mon, 11)

Hi Junio, On Mon, 11 Jul 2016, Junio C Hamano wrote: > [New Topics] > > [...] What about http://thread.gmane.org/gmane.comp.version-control.git/299050? Ciao, Dscho -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More

Re: [ANNOUNCE] Git v2.9.1

On Tue, Jul 12, 2016 at 11:12 AM, Junio C Hamano wrote: > > Let's do 2.9.2 together, as this is not limited to GfW. > > Taking Peff's suggestions into account, perhaps like the attached? If I can get positive comments soon enough, I can do 2.9.2 early tomorrow my time. Or a

Re: [PATCH v3 7/8] doc: revisions - define `reachable`

On 2016-07-11 04:25 PM, Philip Oakley wrote: Do not self-define `reachable`, which can lead to misunderstanding. Instead define `reachability` explictly. Signed-off-by: Philip Oakley --- Documentation/revisions.txt | 14 ++ 1 file changed, 10 insertions(+),

Re: [ANNOUNCE] Git v2.9.1

On Tue, Jul 12, 2016 at 01:25:20PM +0200, Johannes Schindelin wrote: > [PATCH] Work around test failures due to timestamps being unsigned long > > Git's source code refers to timestamps as unsigned longs. On 32-bit > platforms, as well as on Windows, unsigned long is not large enough to >

Re: [PATCH v3 4/8] doc: give headings for the two and three dot notations

On 2016-07-11 04:25 PM, Philip Oakley wrote: While there, also break out the other shorthand notations and add a title for the revision range summary (which also appears in git-rev-parse, so keep it mixed case). Signed-off-by: Philip Oakley ---

Re: [ANNOUNCE] Git v2.9.1

On Mon, Jul 11, 2016 at 08:40:56PM -0400, Anders Kaseorg wrote: > On 07/11/2016 07:54 PM, Jeff King wrote: > > Yes, that's somewhat the point of the test. > > > > How does it fail for you (what does it look like with "-v")? We may be > > able to check for an outcome that matches both cases. > >

Re: [ANNOUNCE] Git v2.9.1

Johannes Schindelin writes: > Git's source code assumes that unsigned long is at least as precise as > time_t. Well, Git's source code is wrong. > ... That is correct. As people mentioned downthread already, "unsigned long" has two problems, it may not be wide

Re: [ANNOUNCE] Git v2.9.1

On Tue, Jul 12, 2016 at 03:31:00PM +0200, Andreas Schwab wrote: > Johannes Schindelin writes: > > > Hi Andreas, > > > > On Tue, 12 Jul 2016, Andreas Schwab wrote: > > > >> Johannes Schindelin writes: > >> > >> >> PRIuMAX isn't compatible with

Re: [ANNOUNCE] Git v2.9.1

Hi Andreas, On Tue, 12 Jul 2016, Andreas Schwab wrote: > Johannes Schindelin writes: > > > @@ -88,11 +88,11 @@ static int local_tzoffset(unsigned long time) > > return offset * eastwest; > > } > > > > -void show_date_relative(unsigned long time, int tz, > >

Re: [ANNOUNCE] Git v2.9.1

Johannes Schindelin writes: >> Cool! Thanks for working on this. > > Well, I had to. Git for Windows v2.9.1 needs to get released, and I won't > do that with a failing test suite. Let's do 2.9.2 together, as this is not limited to GfW. Taking Peff's suggestions into

Re: [ANNOUNCE] Git v2.9.1

Jeff King writes: > In case it wasn't clear, I was mostly guessing there. So I dug a bit > further, and indeed, I am wrong. Linux never bumped to a 64-bit time_t > on i386 because of the ABI headaches. This is being worked on. Andreas. -- Andreas Schwab, sch...@linux-m68k.org

Re: [ANNOUNCE] Git v2.9.1

Hi Andreas, On Tue, 12 Jul 2016, Andreas Schwab wrote: > Johannes Schindelin writes: > > >> PRIuMAX isn't compatible with time_t. > > > > That statement is wrong. > > No, it isn't. PRIuMAX is for uintmax_t, and time_t is not uintmax_t > (even if they happen to have the

Re: [PATCH v14 00/21] index-helper/watchman

Just thinking out loud. I've been thinking about this more about this. After the move from signal-based to unix socket for communication, we probably are better off with a simpler design than the shm-alike one we have now. What if we send everything over a socket or a pipe? Sending 500MB over a

Re: What's cooking in git.git (Jul 2016, #04; Mon, 11)

On Tue, Jul 12, 2016 at 6:16 AM, Johannes Schindelin wrote: > > On Mon, 11 Jul 2016, Junio C Hamano wrote: > >> [New Topics] >> >> [...] > > What about http://thread.gmane.org/gmane.comp.version-control.git/299050? Not forgotten. It just is not one of the "New

Re: [ANNOUNCE] Git v2.9.1

Jeff King writes: > I am not certain that there is a modern system with 32-bit time_t. We > know there are systems with 32-bit unsigned long, and I think that is > what produced the results people saw. I'd expect even 32-bit systems to > use "int64_t" or similar for their time_t

Re: gc and repack ignore .git/*HEAD when checking reachability

On Tue, Jul 12, 2016 at 5:26 PM, Jeff King wrote: > Likewise for other per-worktree items. If we used refs/MERGE_HEAD and > refs/worktree/foo/MERGE_HEAD, then you could access them independently > by using the fully qualified names. I'm not opposed to letting one worktree see

Re: gc and repack ignore .git/*HEAD when checking reachability

On Tue, Jul 12, 2016 at 05:46:12PM +0200, Duy Nguyen wrote: > I'm not opposed to letting one worktree see everything, but this move > makes it harder to write new scripts (or new builtin commands, even) > that works with both single and multiple worktrees because you refer > to one ref (in

Re: [RFC/PATCH 0/8] Add configuration options for split-index

On Mon, Jul 11, 2016 at 7:22 PM, Christian Couder wrote: > Future work > ~~~ > > One thing that is probably missing is a mechanism to avoid having too > many changes accumulating in the (split) index while in split index > mode. The git-update-index

Re: [ANNOUNCE] Git v2.9.1

On Tue, Jul 12, 2016 at 8:16 AM, Jeff King wrote: >> >> But moving the internal time representation used in various fields >> like commit->date to time_t is likely to be a wrong thing to do, >> because the first problem with "unsigned long", i.e. "may not be >> wide enough", is not

Re: [RFC/PATCH 8/8] read-cache: unlink old sharedindex files

On Tue, Jul 12, 2016 at 9:04 AM, Christian Couder wrote: > On Mon, Jul 11, 2016 at 8:27 PM, Duy Nguyen wrote: >> On Mon, Jul 11, 2016 at 7:22 PM, Christian Couder >> wrote: >>> Everytime split index is turned on, it

Re: [ANNOUNCE] Git v2.9.1

On Tue, Jul 12, 2016 at 07:34:14AM -0700, Junio C Hamano wrote: > > Git's source code assumes that unsigned long is at least as precise as > > time_t. Well, Git's source code is wrong. > > ... > > That is correct. As people mentioned downthread already, "unsigned > long" has two problems, it

Re: [PATCH] Add very verbose porcelain output to status

On Thu, Jul 07, 2016 at 03:26:28PM -0400, Jeff Hostetler wrote: > Tools interacting with Git repositories may need to know the complete > state of the working directory. For efficiency, it would be good to have > a single command to obtain this information. > > We already have a `--porcelain`

I will be waiting for your reply

Hello, My name is Chan Chak a bank manager with an investment bank, I have a business deal of mutual benefit that involve transfer of large sum of money. Get back to me through my private email:- chanch...@gmail.com for more details if you are interested. CHAN CHAK -- To unsubscribe from this

Re: gc and repack ignore .git/*HEAD when checking reachability

On Tue, Jul 12, 2016 at 12:47:06PM +0200, Johannes Schindelin wrote: > > Not so fast; it cuts both ways. > > > > People who want multiple worktrees with branches checked out to work > > in would want to do per-worktree things like bisection, which needs > > tons more state than we'd be

Re: [ANNOUNCE] Git v2.9.1

On Tue, Jul 12, 2016 at 08:25:51AM -0700, Junio C Hamano wrote: > On Tue, Jul 12, 2016 at 8:16 AM, Jeff King wrote: > >> > >> But moving the internal time representation used in various fields > >> like commit->date to time_t is likely to be a wrong thing to do, > >> because the

Re: Fast-forward able commit, otherwise fail

li...@haller-berlin.de (Stefan Haller) writes: > I have read and re-read this thread a hundred times now, but I still > don't understand why it makes much of a difference whether or not Bob > rebases his branch onto master before pushing his merge. In both cases, > Alice and Bob have this race as

Re: [ANNOUNCE] Git v2.9.1

Jeff King writes: > However, I was thinking that it might be handy to have this and some > other information available for helping with debugging. E.g., that we > could ask bug reporters for "git version --build-options" when we > suspect something related to their config. Sure.

Re: [PATCH] Add very verbose porcelain output to status

Thanks for the feedback. I like the overall direction of your suggestions. Going for a porcelain V2 feels better than piling onto verbose. I think that would also give us a little more license to address some of the line format issues that you point out. Let me retool what I have along these

Re: Submodule's .git file contains absolute path when created using 'git clone --recursive'

On Tue, Jul 12, 2016 at 4:22 AM, Ricardo Sánchez-Sáez wrote: > Stefan Beller google.com> writes: > > Hi, > > sorry to awake an old thread. Has this been fixed? In which git version? > It's hitting me on git version 2.7.4 (Apple Git-66) (default git client on > OS X

Re: [PATCH v3 2/8] doc: revisions - name the Left and Right sides

Philip Oakley writes: > The terms Left and Right side originate from the symmetric > difference. Name them there. > --- Sign-off? > Documentation/revisions.txt | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Documentation/revisions.txt

Re: [PATCH v3 4/8] doc: give headings for the two and three dot notations

Marc Branchaud writes: >> +The '{caret}' (caret) notation >> +~~~ >> To exclude commits reachable from a commit, a prefix '{caret}' >> notation is used. E.g. '{caret}r1 r2' means commits reachable >> from 'r2' but exclude the ones

[PATCH v3] config: add conditional include

Helped-by: Jeff King Signed-off-by: Nguyễn Thái Ngọc Duy --- v3 fixes some memory leak and typos. Most importantly it no longer depends on core.ignorecase for case-insensitive matching. The choice must be explicitly made by the user when they choose "gitdir"

Re: [PATCH 2/5] sha1_file.c: use type off_t* for object_info->disk_sizep

Nguyễn Thái Ngọc Duy writes: > This field, filled by sha1_object_info() contains the on-disk size of > an object, which could go over 4GB limit of unsigned long on 32-bit > systems. Use off_t for it instead and update all callers. > > Signed-off-by: Nguyễn Thái Ngọc Duy

Re: [ANNOUNCE] Git v2.9.1

On Tue, Jul 12, 2016 at 08:41:42AM -0700, Junio C Hamano wrote: > Jeff King writes: > > > I am not certain that there is a modern system with 32-bit time_t. We > > know there are systems with 32-bit unsigned long, and I think that is > > what produced the results people saw. I'd

Re: gc and repack ignore .git/*HEAD when checking reachability

On Tue, Jul 12, 2016 at 5:51 PM, Jeff King wrote: > On Tue, Jul 12, 2016 at 05:46:12PM +0200, Duy Nguyen wrote: > >> I'm not opposed to letting one worktree see everything, but this move >> makes it harder to write new scripts (or new builtin commands, even) >> that works with both

Re: [ANNOUNCE] Git v2.9.1

Jeff King writes: > In case it wasn't clear, I was mostly guessing there. So I dug a bit > further, and indeed, I am wrong. Linux never bumped to a 64-bit time_t > on i386 because of the ABI headaches. X-< (yes, I knew). > That being said, I still think the "clamp to time_t"

Re: [PATCH 0/5] Number truncation with 4+ GB files on 32-bit systems

Nguyễn Thái Ngọc Duy writes: > Since I now could reproduce the problem that Christoph showed, I > decided to send the good patches out. To sum up, we use "unsigned > long" in some places related to file size. On 32-bit systems, it's > limited to 32 bits even though the system

Re: [PATCH 1/5] pack-objects: pass length to check_pack_crc() without truncation

Nguyễn Thái Ngọc Duy writes: > diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c > index 8f5e358..df6ecd5 100644 > --- a/builtin/pack-objects.c > +++ b/builtin/pack-objects.c > @@ -349,7 +349,7 @@ static unsigned long write_reuse_object(struct sha1file > *f,

Re: [PATCH 4/5] index-pack: report correct bad object offsets even if they are large

Nguyễn Thái Ngọc Duy writes: > Use the right type for offsets in this case, off_t, which makes a > difference on 32-bit systems with large file support, and change > formatting code accordingly. > > Signed-off-by: Nguyễn Thái Ngọc Duy > --- >

Re: [PATCH 0/5] Number truncation with 4+ GB files on 32-bit systems

Junio C Hamano writes: > Nguyễn Thái Ngọc Duy writes: > >> Since I now could reproduce the problem that Christoph showed, I >> decided to send the good patches out. To sum up, we use "unsigned >> long" in some places related to file size. On 32-bit

Re: [PATCH 7/5] fsck: use streaming interface for large blobs in pack

Junio C Hamano writes: >> +if (type != OBJ_BLOB || size < big_file_threshold) { >> +data = unpack_entry(p, entries[i].offset, , ); >> +data_valid = 1; > > This codepath slurps the data in-core to hash and data is later >

Re: [PATCH] pack-objects: Use reachability bitmap index when generating non-stdout pack too

On Fri, Jul 08, 2016 at 01:38:55PM +0300, Kirill Smelkov wrote: > Peff first of all thanks for feedback, > > On Thu, Jul 07, 2016 at 04:52:23PM -0400, Jeff King wrote: > > On Thu, Jul 07, 2016 at 10:09:17PM +0300, Kirill Smelkov wrote: > > > > > Starting from 6b8fda2d (pack-objects: use bitmaps

Re: [ANNOUNCE] Git v2.9.1

On Tue, Jul 12, 2016 at 3:46 PM, Jeff King wrote: > On Tue, Jul 12, 2016 at 03:31:00PM +0200, Andreas Schwab wrote: > >> Johannes Schindelin writes: >> >> > Hi Andreas, >> > >> > On Tue, 12 Jul 2016, Andreas Schwab wrote: >> > >> >> Johannes Schindelin

Re: [PATCH 7/5] fsck: use streaming interface for large blobs in pack

Nguyễn Thái Ngọc Duy writes: > For this particular operation, not unpacking the blob and letting > check_sha1_signature, which supports streaming interface, do the job > is sufficient. That reasoning is sound, I would think, but... > We will call the callback function "fn"

Re: [PATCH 2/5] sha1_file.c: use type off_t* for object_info->disk_sizep

Nguyễn Thái Ngọc Duy writes: > - strbuf_addf(sb, "%lu", data->disk_size); > + strbuf_addf(sb, "%"PRIuMAX, data->disk_size); Subject: [PATCH] SQUASH??? --- builtin/cat-file.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

Re: [PATCH v5 0/8] extend smudge/clean filters with direct file access (for pu)

Joey Hess writes: > Since tb/convert-peek-in-index is not currently in pu, this reroll isn't > based on it, and will conflict if that topic gets added back into pu. > Not sure what the status of tb/convert-peek-in-index is at this point? It appears that we are converging on

Re: [PATCH 4/5] index-pack: report correct bad object offsets even if they are large

Nguyễn Thái Ngọc Duy writes: > va_end(params); > - die(_("pack has bad object at offset %lu: %s"), offset, buf); > + die(_("pack has bad object at offset %"PRIiMAX": %s"), > + (intmax_t)offset, buf); Subject: [PATCH] SQUASH??? diff --git

Re: [PATCH v3 0/8] Name for A..B ranges?

Philip Oakley writes: > This is the re-roll of the po/range-doc (2016-07-01) 3 commits and its > follow on patch. > > The series has gained additional patches following the discussions > ($gmane/298790). > > The original first 3 patches are unchanged, though 2/8 has been

Re: [RFC/PATCH 8/8] read-cache: unlink old sharedindex files

On Tue, Jul 12, 2016 at 5:12 PM, Duy Nguyen wrote: > > No. People could create an index file anywhere in theory. So you don't > know how many index files there are. Maybe when an index file is created, its path and its sharedindex file could be appended into a log file. We

Re: [PATCH v3 3/3] correct ce_compare_data() in a middle of a merge

Torsten Bögershausen writes: >> How do things look at this point? This version is what I ended up >> queuing in 'pu', but I took your "Thanks" in $gmane/299120 to only >> mean "Thanks for feeding some ideas to help me move forward", not >> necessarily "Tnanks that looks like the