Ich suche Daten auf git

Hallo, Ich heisse Jensen. Ich bin auf git interessiert. Haette gern von Euch gehoert. Gruss aus den Staaten, -- Cal Dershowitz aka Merrill Jensen in real life -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More

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

On 07/13/2016 12:20 AM, Joey Hess wrote: 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: Https password present in git output

On Thu, Jul 14, 2016 at 01:36:52AM +0300, ervion wrote: > It is in fact the case, that git fetch output is scrubbed, sorry I did not > notice previously. > But (on my device: git version 2.9.0 arch linux) git push is not. > $ git push origin --all Maybe this? -- >8 -- Subject: [PATCH] push:

Re: Https password present in git output

I completely agree that it is not a head-on-fire kind of problem, there are ways to avoid it. Simply nice to have. It is in fact the case, that git fetch output is scrubbed, sorry I did not notice previously. But (on my device: git version 2.9.0 arch linux) git push is not. $ git push

Re: What's cooking in git.git (Jul 2016, #05; Wed, 13)

On Wed, Jul 13, 2016 at 03:41:01PM -0700, Junio C Hamano wrote: > Stefan Beller writes: > > >>> I think Shawns proposal to have a receive.maxCommandBytes is a > >>> good way for an overall upper bound, but how does it stop us from > >>> going forward with this series? > >> >

Re: What's cooking in git.git (Jul 2016, #05; Wed, 13)

Stefan Beller writes: >>> I think Shawns proposal to have a receive.maxCommandBytes is a >>> good way for an overall upper bound, but how does it stop us from >>> going forward with this series? >> >> If we were to do maxcommandbytes, then max_options would become >>

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

On 07/12/2016 02:24 PM, Duy Nguyen wrote: 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

Re: [feature request] Warn about or prevent --amend commits that don't change anything

Junio C Hamano schrieb: Bergi writes: when nothing is staged in the index then `git commit` warns about this fact with either "nothing to commit, working directory clean" or "no changes added to commit". However, `git commit --amend --no-edit` will happily record a new

Re: [ANNOUNCE] Git v2.9.1

Junio C Hamano writes: > It is somewhat disturbing that nobody seems to be regularly building > on 32-bit platforms these days, which is the only reason I can think > of why this was never reported until it hit a maintenance track. > This should have been caught last week at

Re: Bug report: --invert-grep and --author seems to be incompatible.

Jehan Pagès writes: > ... A better naming should > have been called --invert-matches, or even just --invert. > And the man description should definitely be completed, IMO. Renaming the options would not work well without harming existing users, but a patch to update

Re: Bug report: --invert-grep and --author seems to be incompatible.

Hi, On Wed, Jul 13, 2016 at 7:37 PM, Junio C Hamano wrote: > Jehan Pagès writes: > >>> I think --author=someone greps the "author " field in the commit >>> object looking for the hit with "someone", and your request asks to >>> show commits that

Hi git

Hi git http://beabuyer.org/smell.php?cat=qcugur1unp6m3q98 Rgds Harsh -- 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

Re: [ANNOUNCE] Git v2.9.1

Johannes Schindelin writes: >> I was hoping to hear from you sooner and do v2.9.2 with your t0006 >> workaround with lazy-prereq changes from Peff (i.e. "Makes sense!" >> above), so that you do not have to do two releases in a row >> (i.e. skipping v2.9.1 saying "Git

Re: Multiple Keys in ssh-agent, fail to clone

Benjamin Fritsch writes: > I read the Changelog for 2.9 and couldn’t find any reference to changed key > handling. Is there anything that I can add to the `git clone` command to get > the old behavior? I do not think this has much to do with the version of Git, unless you are

Re: [feature request] Warn about or prevent --amend commits that don't change anything

Bergi writes: > when nothing is staged in the index then `git commit` warns about this > fact with either "nothing to commit, working directory clean" or "no > changes added to commit". > However, `git commit --amend --no-edit` will happily record a new > commit that differs in

Re: [ANNOUNCE] Git v2.9.1

Hi Junio, On Wed, 13 Jul 2016, Junio C Hamano wrote: > Johannes Schindelin writes: > > > This was just a quick fix, intended to allow me to release Git for Windows > > v2.9.1 in a timely manner (which is now delayed for other reasons). > > ... > >> You'll need to

Multiple Keys in ssh-agent, fail to clone

Hey all, We recently upgraded from Git 2.8 to 2.9 and saw an issue when there are multiple keys added to my ssh-agent. I have two keys. - KeyA (my company that has access to the repository I want to clone) - KeyB (just my personal key with access to my personal stuff) Having both keys in

Re: [ANNOUNCE] Git v2.9.1

Johannes Schindelin writes: > How about this one instead (which is part of the time_t-may-be-int64 > branch on https://github.com/dscho/git which I still have to complete, as > some unsigned longs still slipped out of my previous net)? It strikes me > as much more

Issue with git p4 clone when using multiple depots and multiple branches

Hi, We have a perforce structure at work that looks like this: //depot/basic/{main,branch1,branch2}/component{1,2} //depot/extra/{main,branch1,branch2}/extra{1,2} I'm trying to create 3 branches, i.e. main/branch1/branch2, with all sub-components together, i.e.

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

Hi Duy, On Wed, 13 Jul 2016, Duy Nguyen wrote: > On Wed, Jul 13, 2016 at 10:20 AM, Johannes Schindelin > wrote: > > > > On Tue, 12 Jul 2016, Duy Nguyen wrote: > > > >> On Tue, Jul 12, 2016 at 5:51 PM, Jeff King wrote: > >> > On Tue, Jul 12, 2016 at

[feature request] Warn about or prevent --amend commits that don't change anything

Hello, when nothing is staged in the index then `git commit` warns about this fact with either "nothing to commit, working directory clean" or "no changes added to commit". However, `git commit --amend --no-edit` will happily record a new commit that differs in nothing than its commit date

Re: [ANNOUNCE] Git v2.9.1

Hi Junio, On Wed, 13 Jul 2016, Junio C Hamano wrote: > Johannes Schindelin writes: > > > On Tue, 12 Jul 2016, Junio C Hamano wrote: > > > >> Jeff King writes: > >> > >> > In case it wasn't clear, I was mostly guessing there. So I dug a bit > >> >

Re: [ANNOUNCE] Git v2.9.1

Hi Junio, On Wed, 13 Jul 2016, Junio C Hamano wrote: > Jeff King writes: > > > Definitely keep that paragraph. I am quite familiar with the test > > helper and it was not the outcome I initially expected. > > > >> +test_lazy_prereq 64BIT_TIME ' > >> + case "$(test-date show:iso

Re: Https password present in git output

On wo, 2016-07-13 at 20:26 +0300, ervion wrote: > One possibility for this in git is to save remote in the  > https://username:passw...@domain.com/repo.git format. This is not recommended. Git has credential helpers to help you store passwords outside the git configuration. Which then makes your

Re: Https password present in git output

On Wed, Jul 13, 2016 at 11:09 AM, Junio C Hamano wrote: > ervion writes: > >> Sometimes using ssh is not possible and saving https password in plain >> text to disk may be desireable >> (in case of encrypted disk it would be equivalent security with >>

Re: Https password present in git output

ervion writes: > Sometimes using ssh is not possible and saving https password in plain > text to disk may be desireable > (in case of encrypted disk it would be equivalent security with > caching password in memory). > > One possibility for this in git is to save remote in

Re: What's cooking in git.git (Jul 2016, #05; Wed, 13)

On Wed, Jul 13, 2016 at 10:52 AM, Stefan Beller wrote: > On Wed, Jul 13, 2016 at 10:32 AM, Junio C Hamano wrote: >> Stefan Beller writes: >> * sb/push-options (2016-07-12) 5 commits - add a test for push options - push:

Re: What's cooking in git.git (Jul 2016, #05; Wed, 13)

On Wed, Jul 13, 2016 at 10:32 AM, Junio C Hamano wrote: > Stefan Beller writes: > >>> * sb/push-options (2016-07-12) 5 commits >>> - add a test for push options >>> - push: accept push options >>> - SQUASH??? >> >> Squash? I do not find a squashable

Https password present in git output

Sometimes using ssh is not possible and saving https password in plain text to disk may be desireable (in case of encrypted disk it would be equivalent security with caching password in memory). One possibility for this in git is to save remote in the

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

On Wed, Jul 13, 2016 at 5:16 PM, Duy Nguyen wrote: > On Tue, Jul 12, 2016 at 9:45 PM, Christian Couder > wrote: >> On Tue, Jul 12, 2016 at 5:12 PM, Duy Nguyen wrote: >>> >>> No. People could create an index file anywhere in

Re: What's cooking in git.git (Jul 2016, #05; Wed, 13)

Duy Nguyen writes: > On the subject of truncation, there is something else I should note. > The field sd_size in struct stat_data is 32 bits, so large files will > overflow it too, regardless of platforms. I did not do anything > because I checked and double checked and was

Re: What's cooking in git.git (Jul 2016, #05; Wed, 13)

On Wed, Jul 13, 2016 at 6:56 PM, Junio C Hamano wrote: > * nd/pack-ofs-4gb-limit (2016-07-13) 7 commits > - fsck: use streaming interface for large blobs in pack > - pack-objects: do not truncate result in-pack object size on 32-bit systems > - index-pack: correct "offset"

Re: What's cooking in git.git (Jul 2016, #05; Wed, 13)

> * sb/push-options (2016-07-12) 5 commits > - add a test for push options > - push: accept push options > - SQUASH??? Squash? I do not find a squashable commit in what you pushed, do you intend to squash the first 2 patches instead? > - receive-pack: implement advertising and receiving push

Re: Bug report: --invert-grep and --author seems to be incompatible.

Jehan Pagès writes: >> I think --author=someone greps the "author " field in the commit >> object looking for the hit with "someone", and your request asks to >> show commits that either do not have "something" or was not written >> by "someone", I would guess. > >

Re: What's cooking in git.git (Jul 2016, #05; Wed, 13)

Stefan Beller writes: >> * sb/push-options (2016-07-12) 5 commits >> - add a test for push options >> - push: accept push options >> - SQUASH??? > > Squash? I do not find a squashable commit in what you pushed, > do you intend to squash the first 2 patches instead? $ git

Re: Bug report: --invert-grep and --author seems to be incompatible.

Hi, On Wed, Jul 13, 2016 at 7:04 PM, Junio C Hamano wrote: > Jehan Pagès writes: > >>> git log --author=someone --invert-grep --grep=something >> >> But it does not work. Actually it looks like it just returns >> everything (as though I had done a

Bug report: --invert-grep and --author seems to be incompatible.

Hello, > $ git version > git version 2.5.5 Tested on a Fedora 23. You can combine `git log --author=someone --grep=something` to have all commits by "someone" where "something" can be grepped. If I want all commits by someone where "something" is not grepped, I would expect this command to

Re: Bug report: --invert-grep and --author seems to be incompatible.

Jehan Pagès writes: >> git log --author=someone --invert-grep --grep=something > > But it does not work. Actually it looks like it just returns > everything (as though I had done a simple `git log`). Do you see a commit that is by "someone" and has "something" in it

What's cooking in git.git (Jul 2016, #05; Wed, 13)

Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. The ones marked with '.' do not appear in any of the integration branches, but I am still holding onto them. It turns out that v2.9.1 had

Re: [ANNOUNCE] Git v2.9.1

Johannes Schindelin writes: > On Tue, 12 Jul 2016, Junio C Hamano wrote: > >> 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 >>

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

Nguyễn Thái Ngọc Duy writes: > A diff from nd/pack-ofs-4gb-limit can explain the changes better than > me. > > I did not add PRIdMAX or similar because that carries a risk to exotic > platforms that people rarely test. Just casting to unsigned should be > fine. Looks very

Re: [ANNOUNCE] Git v2.9.1

Jeff King writes: > Definitely keep that paragraph. I am quite familiar with the test > helper and it was not the outcome I initially expected. > >> +test_lazy_prereq 64BIT_TIME ' >> +case "$(test-date show:iso 99)" in >> +*" -> 2038-"*) >> +# on this

[RFC] Speed up git status via a file system daemon

Idea taken and code refactored from [1]: The intent of this patch series is to separate the index-helper logic from the Watchman logic. With very large repos, the percentage of time required to read the index from disk becomes a much smaller percentage of the overall time. The Watchman logic

Re: [PATCH v3] config: add conditional include

On Wed, Jul 13, 2016 at 9:21 AM, Matthieu Moy wrote: > Nguyễn Thái Ngọc Duy writes: > >> +`gitdir`:: >> + The environment variable `GIT_DIR` must match the following >> + pattern for files to be included. The pattern can contain >> +

Re: [ANNOUNCE] Git v2.9.1

Johannes Schindelin writes: > This was just a quick fix, intended to allow me to release Git for Windows > v2.9.1 in a timely manner (which is now delayed for other reasons). > ... >> You'll need to adjust check_show as I did in my earlier patch. > > Makes sense!

Re: [PATCH v5 2/8] add smudgeToFile and cleanFromFile filter configs

> On 12 Jul 2016, at 00:45, Joey Hess wrote: > > This adds new smudgeToFile and cleanFromFile filter commands, > which are similar to smudge and clean but allow direct access to files on > disk. > > This interface can be much more efficient when operating on large files, >

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

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 Signed-off-by: Junio C Hamano --- builtin/index-pack.c | 7

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

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 Signed-off-by: Junio C Hamano

Re: [PATCH 00/38] Virtualization of the refs API

On 07/10/2016 05:09 PM, Duy Nguyen wrote: > On Fri, Jun 3, 2016 at 11:03 PM, Michael Haggerty > wrote: >> Since the that ref-iterator [1] changes seem to have gotten a positive >> reception, let's try to keep up the momentum. I hope I'm not >> overloading the review

[PATCH v2 5/7] index-pack: correct "offset" type in unpack_entry_data()

unpack_entry_data() receives an off_t value from unpack_raw_entry(), which could be larger than unsigned long on 32-bit systems with large file support. Correct the type so truncation does not happen. This only affects bad object reporting though. Signed-off-by: Nguyễn Thái Ngọc Duy

[PATCH v2 6/7] pack-objects: do not truncate result in-pack object size on 32-bit systems

A typical diff will not show what's going on and you need to see full functions. The core code is like this, at the end of of write_one() e->idx.offset = *offset; size = write_object(f, e, *offset); if (!size) { e->idx.offset = recursing;

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

On 32 bit systems with large file support, unsigned long is 32-bit while the two offsets in the subtraction expression (pack-objects has the exact same expression as in sha1_file.c but not shown in diff) are in 64-bit. If an in-pack object is larger than 2^32 len/datalen is truncated and we get a

[PATCH v2 0/7] Number truncation with 4+ GB files on 32-bit systems

A diff from nd/pack-ofs-4gb-limit can explain the changes better than me. I did not add PRIdMAX or similar because that carries a risk to exotic platforms that people rarely test. Just casting to unsigned should be fine. diff --git a/builtin/fsck.c b/builtin/fsck.c index 55eac75..b08bc8b 100644

[PATCH v2 3/7] index-pack: correct "len" type in unpack_data()

On 32-bit systems with large file support, one entry could be larger than 4GB and overflow "len". Correct it so we can unpack a full entry. Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano --- builtin/index-pack.c | 14 +++--- 1

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

For blobs, we want to make sure the on-disk data is not corrupted (i.e. can be inflated and produce the expected SHA-1). Blob content is opaque, there's nothing else inside to check for. For really large blobs, we may want to avoid unpacking the entire blob in memory, just to check whether it

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

On Tue, Jul 12, 2016 at 9:45 PM, Christian Couder wrote: > 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

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

On Tue, Jul 12, 2016 at 10:40 PM, Junio C Hamano wrote: > 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

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

On Tue, Jul 12, 2016 at 10:49 PM, Junio C Hamano wrote: > 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

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

On Wed, Jul 13, 2016 at 10:20 AM, Johannes Schindelin wrote: > Hi Duy, > > On Tue, 12 Jul 2016, Duy Nguyen wrote: > >> 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

Re: [ANNOUNCE] Git v2.9.1

Hi, On Tue, 12 Jul 2016, Junio C Hamano wrote: > 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

Loan Offer

Instant cash Loan with same day payout on all kinds of Loan are available at Quick Financial Home were loan is offered at 2% per annul. Email: quickloa...@foxmail.com -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More

Loan Offer

Instant cash Loan with same day payout on all kinds of Loan are available at Quick Financial Home were loan is offered at 2% per annul. Email: quickloa...@foxmail.com -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More

Re: [PATCH v3] config: add conditional include

Jeff King writes: > On Wed, Jul 13, 2016 at 09:21:37AM +0200, Matthieu Moy wrote: > >> > +static int prepare_include_condition_pattern(struct strbuf *pat) >> > +{ >> > + int prefix = 0; >> > + >> > + /* TODO: maybe support ~user/ too */ >> > + if (pat->buf[0] == '~' &&

Re: [ANNOUNCE] Git v2.9.1

Hi Peff, On Tue, 12 Jul 2016, Jeff King wrote: > 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

Re: [ANNOUNCE] Git v2.9.1

Hi Duy, On Tue, 12 Jul 2016, Duy Nguyen wrote: > 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: > >> > >> > On Tue, 12 Jul 2016, Andreas Schwab

Re: [ANNOUNCE] Git v2.9.1

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

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

On Wed, Jul 13, 2016 at 04:26:53AM -0400, Jeff King wrote: > On Fri, Jul 08, 2016 at 01:38:55PM +0300, Kirill Smelkov wrote: > > > > - we will not compute the same write order (which is based on > > > traversal order), leading to packs that have less efficient cache > > >

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

On Tue, Jul 12, 2016 at 10:08:08PM +0300, Kirill Smelkov wrote: > > Or are we fine with my arguments about recency order staying the same > > when using bitmap reachability index for object graph traversal, and this > > way the patch is fine to go in as it is? > > Since there is no reply I

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: > > - we will not compute the same write order (which is based on > > traversal order), leading to packs that have less efficient cache > > characteristics > > I agree the order can be not exactly the same. Still if

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

Hi Duy, On Tue, 12 Jul 2016, Duy Nguyen wrote: > 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

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

Hi Jeff, [please note that top-posting is discouraged on this mailing list] On Tue, 12 Jul 2016, Jeff Hostetler wrote: > 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

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

Hi Junio, On Tue, 12 Jul 2016, Junio C Hamano wrote: > 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

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

Hi Pranit, On Wed, Jul 13, 2016 at 12:35 AM, Pranit Bauva wrote: > 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. It's a good thing to resend when you find

Re: [PATCH v3] config: add conditional include

Nguyễn Thái Ngọc Duy writes: > +`gitdir`:: > + The environment variable `GIT_DIR` must match the following > + pattern for files to be included. The pattern can contain > + standard globbing wildcards and two additional ones, `**/` and > + `/**`, that can match

Re: [PATCH v3] config: add conditional include

On Wed, Jul 13, 2016 at 09:21:37AM +0200, Matthieu Moy wrote: > > +static int prepare_include_condition_pattern(struct strbuf *pat) > > +{ > > + int prefix = 0; > > + > > + /* TODO: maybe support ~user/ too */ > > + if (pat->buf[0] == '~' && is_dir_sep(pat->buf[1])) { > > + struct

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

On Tue, Jul 12, 2016 at 10:38 PM, Junio C Hamano wrote: > 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