[bug] Git submodule command interprets switch as argument and switch

The issue is as follows: R0b0t1@host:~/devel/project$ git submodule add https://github.com/user/project -f Cloning into '/home/R0b0t1/devel/project/-f'... My .gitignore's first line is *, and then I explicitly allow things. Despite the presence of "project/" in the .gitignore the submodule

Re: Submodule regression in 2.14?

On Thu, Aug 17, 2017 at 7:13 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> Are you saying this might be a design mistake and >> the .update ought to be respected by all the other >> commands? For example >> git reset --recurse-submodules >>

Re: [PATCH v4 2/3] builtin/branch: stop supporting the use of --set-upstream option

On Friday 18 August 2017 01:25 AM, Junio C Hamano wrote: Martin Ågren writes: On 17 August 2017 at 04:54, Kaartic Sivaraam wrote: Helped-by: Martin Ågren , Junio C Hamano Signed-off-by:

Re: [PATCH v4 2/3] builtin/branch: stop supporting the use of --set-upstream option

On Friday 18 August 2017 01:28 AM, Junio C Hamano wrote: Kaartic Sivaraam writes: diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt index 81bd0a7b7..948d9c9ef 100644 --- a/Documentation/git-branch.txt +++ b/Documentation/git-branch.txt @@

Re: [PATCH/RFC] git-grep: correct exit code with --quiet and -L

Anthony Sottile writes: > The handling of `status_only` no longer interferes with the handling of > `unmatch_name_only`. `--quiet` no longer affects the exit code when using > `-L`/`--files-without-match`. > > Signed-off-by: Anthony Sottile > ---

Re: [PATCH v3 0/4] Modernize read_graft_line implementation

Thanks, will queue.

Re: Submodule regression in 2.14?

Stefan Beller writes: > Are you saying this might be a design mistake and > the .update ought to be respected by all the other > commands? For example > git reset --recurse-submodules > should ignore the .update= none? I have been under the impression that that has been

[PATCH v3 3/4] commit: allocate array using object_id size

struct commit_graft aggregates an array of object_id's, which have size >= GIT_MAX_RAWSZ bytes. This change prevents memory allocation error when size of object_id is larger than GIT_SHA1_RAWSZ. Signed-off-by: Patryk Obara --- commit.c | 3 ++- 1 file changed, 2

[PATCH v3 4/4] commit: rewrite read_graft_line

Determine the number of object_id's to parse in a single graft line by counting separators (whitespace characters) instead of dividing by length of hash representation. This way graft parsing code can support different sizes of hashes without any further code adaptations. Signed-off-by: Patryk

[PATCH v3 1/4] sha1_file: fix definition of null_sha1

The array is declared in cache.h as: extern const unsigned char null_sha1[GIT_MAX_RAWSZ]; Definition in sha1_file.c must match. Signed-off-by: Patryk Obara --- sha1_file.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sha1_file.c b/sha1_file.c

[PATCH v3 2/4] commit: replace the raw buffer with strbuf in read_graft_line

This simplifies function declaration and allows for use of strbuf_rtrim instead of modifying buffer directly. Signed-off-by: Patryk Obara --- builtin/blame.c | 2 +- commit.c| 15 --- commit.h| 2 +- 3 files changed, 10 insertions(+), 9

[PATCH v3 0/4] Modernize read_graft_line implementation

Changes since v2: - commit implementing free_graft dropped (no longer needed) - several more lines moved from last commit to commit replacing raw buffer with strbuf - fix for memory allocation separated from change in hash parsing - commit_graft struct uses FLEX_ARRAY again, meaning

[PATCH/RFC] git-grep: correct exit code with --quiet and -L

The handling of `status_only` no longer interferes with the handling of `unmatch_name_only`. `--quiet` no longer affects the exit code when using `-L`/`--files-without-match`. Signed-off-by: Anthony Sottile --- grep.c | 2 +- t/t7810-grep.sh | 5 + 2 files

Re: reftable [v7]: new ref storage format

On Tue, Aug 15, 2017 at 7:48 PM, Shawn Pearce wrote: > 7th iteration of the reftable storage format. > > You can read a rendered version of this here: > https://googlers.googlesource.com/sop/jgit/+/reftable/Documentation/technical/reftable.md FYI, JGit has adopted this v7

Re: [PATCH v3 2/2] File commited with CRLF should roundtrip diff and apply

tbo...@web.de writes: > @@ -1712,11 +1726,15 @@ static int parse_fragment(struct apply_state *state, > if (!deleted && !added) > leading++; > trailing++; > + if (!state->apply_in_reverse) > +

Re: [PATCH v3 2/2] File commited with CRLF should roundtrip diff and apply

tbo...@web.de writes: > Changes since v2: > - Manually integrated all code changes from Junio > (Thanks, I hope that I didn't miss something) I suspect that "apply -R makes '+' preimage" change is not here. > - Having examples of "git diff" in the commit message confuses "git apply", > so

Beloved

I am Mrs Susan Patrick i have a proposal donation if you are interested get back to me via email: susanpatrick...@gmail.com Thanks Hope to hear from you soon Mrs Susan Patrick --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com

Re: Submodule regression in 2.14?

On Thu, Aug 17, 2017 at 2:21 PM, Lars Schneider wrote: > >> Oh, wait. >> $ git log --oneline v2.13.0..v2.14.1 -- builtin/pull.c >> c9c63ee558 Merge branch 'sb/pull-rebase-submodule' >> a6d7eb2c7a pull: optionally rebase submodules (remote submodule changes only) >> could

Re: [PATCH] sub-process: print the cmd when a capability is unsupported

On Thu, 17 Aug 2017 23:34:33 +0200 Lars Schneider wrote: > > > On 17 Aug 2017, at 23:01, Junio C Hamano wrote: > > > > Christian Couder writes: > > > >> ... but I think we should then emphasize more in our test > >>

[PATCH v3 2/2] File commited with CRLF should roundtrip diff and apply

From: Torsten Bögershausen When a file had been commited with CRLF but now .gitattributes say "* text=auto" (or core.autocrlf is true), the following does not roundtrip, `git apply` fails: printf "Added line\r\n" >>file && git diff >patch && git checkout -- . && git apply patch

[PATCH v3 1/2] convert: Add SAFE_CRLF_KEEP_CRLF

From: Torsten Bögershausen When convert_to_git() is called, the caller may want to keep CRLF to be kept as CRLF (and not converted into LF). This will be used in the next commit, when apply works with files that have CRLF and patches are applied onto these files. Add the new

Re: upgarding GIT

On Mon, Aug 7, 2017 at 4:20 PM, James Wells wrote: > > As you can see my version of git is not supported with the current version of > bitbucket. I will have to perform a two stage upgrade anyway as the version > of STASH I am running cannot be upgraded directly to

Re: [PATCH v2 4/4] commit: rewrite read_graft_line

Understood :) - yes, oid_array is not completely necessary here - and it gives the wrong impression about usage of this struct. FLEX_ARRAY will be brought back in v3. On Thu, Aug 17, 2017 at 11:20 PM, Junio C Hamano wrote: > Patryk Obara writes: > >>

Re: [PATCH 3/5] commit: replace the raw buffer with strbuf in read_graft_line

> In fact, the former is already how we represent the list of fake > parents in the commit_graft structure, so I think patch 5/5 in this > series does two unrelated things, one of which is bad (i.e. use of > parse_oid_hex() is good; turning the FLEX_ARRAY at the end into a > oid_array that

Re: [RFC PATCH] Updated "imported object" design

Thanks for your comments. I'll reply to both your e-mails in this one e-mail. > This illustrates another place we need to resolve the > naming/vocabulary. We should at least be consistent to make it easier > to discuss/explain. We obviously went with "virtual" when building > GVFS but I'm OK

Re: [PATCH] files-backend: cheapen refname_available check when locking refs

Jeff King writes: >> diff --git a/refs/files-backend.c b/refs/files-backend.c >> index e9b95592b6..f2a420c611 100644 >> --- a/refs/files-backend.c >> +++ b/refs/files-backend.c >> @@ -631,11 +631,11 @@ static int lock_raw_ref(struct files_ref_store *refs, >> >> /*

Re: Inconsistent exit code for `git grep --files-without-match` with `--quiet`

Anthony reported this issue to bug-g...@gnu.org. From what I can see, git-grep's behavior is better, so I changed GNU grep to behave like git-grep. Please see: https://debbugs.gnu.org/28105 I hope this saves you folks a little bit of work.

Re: [PATCH] sub-process: print the cmd when a capability is unsupported

> On 17 Aug 2017, at 23:01, Junio C Hamano wrote: > > Christian Couder writes: > >> ... but I think we should then emphasize more in our test >> scripts (maybe by giving a good example) and perhaps also in the doc >> that the

Re: [PATCH] check-ref-format: require a repository for --branch

Jeff King writes: > On Mon, Jul 17, 2017 at 10:27:09AM -0700, Jonathan Nieder wrote: > >> > --- a/t/t1402-check-ref-format.sh >> > +++ b/t/t1402-check-ref-format.sh >> > @@ -161,6 +161,10 @@ test_expect_success 'check-ref-format --branch from >> > subdir' ' >> >test

Re: Submodule regression in 2.14?

> On 16 Aug 2017, at 20:51, Stefan Beller wrote: > > On Wed, Aug 16, 2017 at 11:35 AM, Lars Schneider > wrote: >> Hi, >> >> I think we discovered a regression in Git 2.14.1 today. >> It looks like as if "git submodule update --init --recursive"

Re: [PATCH v2 4/4] commit: rewrite read_graft_line

Patryk Obara writes: > The previous implementation of read_graft_line used calculations based > on GIT_SHA1_RAWSZ and GIT_SHA1_HEXSZ to determine the number of commit > ids in a single graft line. New implementation does not depend on these > constants, so it adapts to

Re: [PATCH 3/5] commit: replace the raw buffer with strbuf in read_graft_line

Jeff King writes: > I'd expect most of the GIT_MAX constants to eventually go away in favor > of "struct object_id", but that will still be using the same "big enough > to hold any hash" size under the hood. Indeed. It is good to see major contributors are in agreement ;-) I'd

Re: [PATCH] sub-process: print the cmd when a capability is unsupported

Christian Couder writes: > ... but I think we should then emphasize more in our test > scripts (maybe by giving a good example) and perhaps also in the doc > that the filters/sub-processes should really pay attention and not > output any capability that are not

Re: [PATCH v2] update revisions doc for quoting in ':/' notation

ryenus writes: > To make sure the `` in `:/` is seen as one search string, > one should quote/escape `` properly. > > Especially, the example given in the manual `:/fix nasty bug` does not > work because of missing quotes when used in shell. A note about > quoting/escaping is

Re: [RFC PATCH] Updated "imported object" design

On 8/16/2017 5:35 PM, Jonathan Tan wrote: On Wed, 16 Aug 2017 13:32:23 -0700 Junio C Hamano wrote: Jonathan Tan writes: Also, let me know if there's a better way to send out these patches for review. Some of the code here has been reviewed

Re: git fetch with refspec does not include tags?

On Thu, Aug 17, 2017 at 01:38:36PM -0700, Junio C Hamano wrote: > Kevin Daudt writes: > > > On Thu, Aug 17, 2017 at 12:38:58PM -0700, Junio C Hamano wrote: > >> Jeff King writes: > >> > >> > # no tags, we just populate FETCH_HEAD because of the bare URL > >> >

Re: git fetch with refspec does not include tags?

Kevin Daudt writes: > On Thu, Aug 17, 2017 at 12:38:58PM -0700, Junio C Hamano wrote: >> Jeff King writes: >> >> > # no tags, we just populate FETCH_HEAD because of the bare URL >> > git fetch ../parent >> > >> > # this does fetch tags, because we're

Re: [Patch size_t V3 00/19] use size_t

On Wed, Aug 16, 2017 at 10:16:12PM +0200, Martin Koegler wrote: > From: Martin Koegler > > This patchset is for next [24db08a6e8fed761d3bace7f2d5997806e20b9f7]. I applied it succesfully, and run the test suite on a 32 bit system. The Laptop reported one brekage in

Re: [Patch size_t V3 01/19] delta: fix enconding size larger than an "uint" can hold

On Wed, Aug 16, 2017 at 10:16:13PM +0200, Martin Koegler wrote: > From: Martin Koegler > > The current delta code produces incorrect pack objects for files > 4GB. This may need a little bit more info (E.g. it does not fix anything on a 32 bit Linux) How about this:

Re: git fetch with refspec does not include tags?

On Thu, Aug 17, 2017 at 12:38:58PM -0700, Junio C Hamano wrote: > Jeff King writes: > > > # no tags, we just populate FETCH_HEAD because of the bare URL > > git fetch ../parent > > > > # this does fetch tags, because we're storing the result according to > > # the

Re: [RFC PATCH] Updated "imported object" design

On 8/15/2017 8:32 PM, Jonathan Tan wrote: This patch is based on an updated version of my refactoring of pack-related functions [1]. This corresponds to patch 1 of my previous series [2]. I'm sending this patch out (before I update the rest) for 2 reasons: * to provide a demonstration of

Re: [PATCH v4 2/3] builtin/branch: stop supporting the use of --set-upstream option

Kaartic Sivaraam writes: > diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt > index 81bd0a7b7..948d9c9ef 100644 > --- a/Documentation/git-branch.txt > +++ b/Documentation/git-branch.txt > @@ -195,10 +195,10 @@ start-point is either a local

Re: [PATCH v4 2/3] builtin/branch: stop supporting the use of --set-upstream option

Martin Ågren writes: > On 17 August 2017 at 04:54, Kaartic Sivaraam > wrote: >> Helped-by: Martin Ågren , Junio C Hamano >> >> Signed-off-by: Kaartic Sivaraam >

ignoring extra bitmap file?

Hi everyone, I'm seeing the message remote: warning: ignoring extra bitmap file: ./objects/pack/pack-2943dc24pack and indeed, there is such a thing (two, actually): 171736188 Aug 17 08:20 pack-2943dc2477026f87b280ebcefa93fe28412688df.idx 12662268 Aug 17 08:24

Re: git fetch with refspec does not include tags?

Jeff King writes: > I think it's a bit more complex because "git pull" uses "git fetch" > under the hood. In fact, your "git fetch origin master" is exactly what > gets run when you do: > > git pull origin master > > That's maybe OK. But I think one-off pulls like: > > git

Re: git fetch with refspec does not include tags?

Jeff King writes: > # no tags, we just populate FETCH_HEAD because of the bare URL > git fetch ../parent > > # this does fetch tags, because we're storing the result according to > # the configured refspec ("refs/heads/*:refs/remotes/origin/*"). > git fetch origin The

Re: git add -p breaks after split on change at the top of the file

Jeff King writes: > Of course this is a pretty ridiculous input in the first place. In > theory it _could_ be figured out, but overlapping hunks like this are > always going to cause problems (in this case, context from the second > hunk became a removal, and the second hunk no

Re: git add -p breaks after split on change at the top of the file

Jeff King writes: > [+cc Junio, as this gets deep into git-apply innards] I've written off --recount and --allow-overlap as ugly workaround that happens to work some of the time but cannot be trusted long time ago. IIRC, before the "(e)dit" thing was added to "add -p", we

Re: [PATCH] add test for bug in git-mv with nested submodules

On Thu, Aug 17, 2017 at 3:34 AM, Heiko Voigt wrote: > When using git-mv with a submodule it will detect that and update the > paths for its configurations (.gitmodules, worktree and gitfile). This > does not work for nested submodules where a user renames the root > submodule.

Re: reftable [v7]: new ref storage format

Michael Haggerty writes: > On Wed, Aug 16, 2017 at 11:05 PM, Junio C Hamano wrote: >> I found it a slightly odd that we do not insist that update_indices >> that appear in a single reftable file are consecutive, yet we >> require that min_update_index of

Re: [PATCH v4 2/3] builtin/branch: stop supporting the use of --set-upstream option

On 17 August 2017 at 04:54, Kaartic Sivaraam wrote: > Helped-by: Martin Ågren , Junio C Hamano > > Signed-off-by: Kaartic Sivaraam I didn't expect a "Helped-by", all I did was to give

Re: [PATCH v4 5/8] interpret-trailers: add --parse convenience option

On 16 August 2017 at 10:20, Jeff King wrote: > On Tue, Aug 15, 2017 at 01:26:53PM +0200, Martin Ågren wrote: > >> > This command reads some patches or commit messages from either the >> > - arguments or the standard input if no is specified. Then >> > -this command applies the

Re: [Patch size_t V3 17/19] Convert ref-filter to size_t

Junio C Hamano writes: > I did not see anything fishy in the remaining parts I did not > comment on. > > Thanks. What I meant was "remainder of this patch 17/19". I am not claiming that I read all other patches; I haven't, not yet anyway.

Re: [Patch size_t V3 17/19] Convert ref-filter to size_t

Martin Koegler writes: > -static char *copy_subject(const char *buf, unsigned long len) > +static char *copy_subject(const char *buf, size_t len) > { > char *r = xmemdupz(buf, len); > int i; This has the same "we are still iterating with 'int i' over an

Re: [PATCH] files-backend: cheapen refname_available check when locking refs

On 08/17, Jeff King wrote: > On Thu, Aug 17, 2017 at 05:12:50PM +0200, Michael Haggerty wrote: > > > I was testing this using the reporter's recipe (but fetching from a > > local clone), and found the following surprising timing numbers: > > > > b05855b5bc (before the slowdown): 22.7 s > >

Re: [Patch size_t V3 18/19] Convert tree-walk to size_t

Martin Koegler writes: > From: Martin Koegler > > Signed-off-by: Martin Koegler > --- > tree-walk.c | 17 + > tree-walk.h | 4 ++-- > tree.h | 2 +- > 3 files changed, 12 insertions(+), 11

Re: [Patch size_t V3 19/19] Convert xdiff-interface to size_t

Martin Koegler writes: > diff --git a/combine-diff.c b/combine-diff.c > index acf39ec..ad5d177 100644 > --- a/combine-diff.c > +++ b/combine-diff.c > @@ -343,7 +343,7 @@ struct combine_diff_state { > struct sline *lost_bucket; > }; > > -static void

Re: [RFC PATCH 2/2] submodule: simplify decision tree whether to or not to fetch

On 08/17, Stefan Beller wrote: > On Thu, Aug 17, 2017 at 4:00 AM, Heiko Voigt wrote: > > To make extending this logic later easier. > > > > Signed-off-by: Heiko Voigt > > --- > > I am quite sure I replicated the same logic but a few more eyes would be > >

Re: [PATCH] t5526: fix some broken && chains

On Thu, Aug 17, 2017 at 3:36 AM, Heiko Voigt wrote: > Signed-off-by: Heiko Voigt Reviewed-by: Stefan Beller Thanks, Stefan > --- > t/t5526-fetch-submodules.sh | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff

Re: [PATCH] diff: retire sane_truncate_fn

On Thu, Aug 17, 2017 at 10:27 AM, Junio C Hamano wrote: > Long time ago, 23707811 ("diff: do not chomp hunk-header in the > middle of a character", 2008-01-02) introduced sane_truncate_line() > helper function to trim the "function header" line that is shown at > the end of the

Re: Question about git gc on large text files

> On Aug 17, 2017, at 10:33 AM, Jeff King wrote: > > On Thu, Aug 17, 2017 at 10:28:00AM -0700, Kai Zhang wrote: > >> I have a git repository maintaining one large json file (along with >> several other small files). With commits for large json file, the >> repository become

Re: Question about git gc on large text files

On Thu, Aug 17, 2017 at 10:28:00AM -0700, Kai Zhang wrote: > I have a git repository maintaining one large json file (along with > several other small files). With commits for large json file, the > repository become bigger and bigger, so I tried to run command "git gc > --prune=now --aggressive"

Question about git gc on large text files

Hi I have a git repository maintaining one large json file (along with several other small files). With commits for large json file, the repository become bigger and bigger, so I tried to run command "git gc --prune=now --aggressive" to reduce disk usage, then I found .git folder size did not

[PATCH] diff: retire sane_truncate_fn

Long time ago, 23707811 ("diff: do not chomp hunk-header in the middle of a character", 2008-01-02) introduced sane_truncate_line() helper function to trim the "function header" line that is shown at the end of the hunk header line, in order to avoid chomping it in the middle of a single UTF-8

Re: [RFC PATCH 2/2] submodule: simplify decision tree whether to or not to fetch

On Thu, Aug 17, 2017 at 4:00 AM, Heiko Voigt wrote: > To make extending this logic later easier. > > Signed-off-by: Heiko Voigt > --- > I am quite sure I replicated the same logic but a few more eyes would be > appreciated. A code cleanup is appreciated! I

Re: [RFC PATCH 1/2] implement fetching of moved submodules

On Thu, Aug 17, 2017 at 3:53 AM, Heiko Voigt wrote: > We store the changed submodules paths to calculate which submodule needs > fetching. This does not work for moved submodules since their paths do > not stay the same in case of a moved submodules. In case of new > submodules

Re: [PATCH/FIXUP 6/2] apply: clarify read_old_data() is about no-index case

Junio C Hamano writes: > Torsten Bögershausen writes: > >> Unless we re-define the meaning of "NULL" into "don't do CRLF conversions, >> like SAFE_CRLF_KEEP_CRLF does. > > My preference is not to use NULL as any hint. Instead, the "flag" > parameter we already

Re: [PATCH] files-backend: cheapen refname_available check when locking refs

On Thu, Aug 17, 2017 at 05:12:50PM +0200, Michael Haggerty wrote: > I was testing this using the reporter's recipe (but fetching from a > local clone), and found the following surprising timing numbers: > > b05855b5bc (before the slowdown): 22.7 s > 524a9fdb51 (immediately after the slowdown):

[PATCH] files-backend: cheapen refname_available check when locking refs

When locking references in preparation for updating them, we need to check that none of the newly added references D/F conflict with existing references (e.g., we don't allow `refs/foo` to be added if `refs/foo/bar` already exists, or vice versa). Prior to 524a9fdb51

Re: git fetch with refspec does not include tags?

On Thu, Aug 17, 2017 at 11:29:48AM +, Carlsson, Magnus wrote: > > 2. If we continue to follow the "are we storing any refs" rule for the > > default, possibly it should expand to "did we store anything, > > including opportunistic tracking-ref updates". > > Personally I think that I

(no subject)

-- I'd like you to be in custody of my late client's fortune. My client died along with his family including his next-of-kin The funds shall be used for investment under your management Do reply for details. Regards Richard Williams Email:rich19willi...@gmail.com

Liebste,

Liebste, Wie gehts Ihnen heute, ich hoffe, dass meine Post Sie in gutem Zustand der Gesundheit erfüllt? Sehr geehrte Damen und Herren, ich habe mich entschlossen, mit Ihnen in Kontakt zu treten, wenn ich bedenkt habe, dass wir uns noch nicht getroffen haben, aber wegen eines Umstandes, der

Re: What's cooking in git.git (Aug 2017, #03; Mon, 14)

On Thursday 17 August 2017 12:58 AM, Junio C Hamano wrote: Nothing has. Neither thread seems to have any comment from anybody but you, and I took it as an indication that people do not think it is a good change. I do not find the s/branch/parameter/ too bad (although I would have said

Re: git fetch with refspec does not include tags?

Thanks for your quick answer! > 1. Definitely these defaults are under-documented. I couldn't find >them anywhere in git-fetch(1). Yes, some sort of explanation would be good, especially since one of the first sentences state that you always get relevant tags. > 2. If we continue to

[RFC PATCH 2/2] submodule: simplify decision tree whether to or not to fetch

To make extending this logic later easier. Signed-off-by: Heiko Voigt --- I am quite sure I replicated the same logic but a few more eyes would be appreciated. Cheers Heiko submodule.c | 55 +++ 1 file changed, 27

Re: tsan: t5400: set_try_to_free_routine

On Tue, Aug 15, 2017 at 02:53:07PM +0200, Martin Ågren wrote: > Using SANITIZE=thread made t5400-send-pack.sh hit the potential race > below. > > This is set_try_to_free_routine in wrapper.c. The race relates to the > reading of the "old" value. The caller doesn't care about the "old" > value,

[RFC PATCH 1/2] implement fetching of moved submodules

We store the changed submodules paths to calculate which submodule needs fetching. This does not work for moved submodules since their paths do not stay the same in case of a moved submodules. In case of new submodules we do not have a path in the current checkout, since they just appeared in this

Re: [PATCH 1/9] Convert pack-objects to size_t

On Wed, Aug 16, 2017 at 10:22:39PM +0200, Martin Koegler wrote: > On Mon, Aug 14, 2017 at 10:08:05AM -0700, Junio C Hamano wrote: > >It may help reducing the maintenance if we introduced obj_size_t > >that is defined to be size_t for now, so that we can later swap > >it to ofs_t or

[PATCH] t5526: fix some broken && chains

Signed-off-by: Heiko Voigt --- t/t5526-fetch-submodules.sh | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/t/t5526-fetch-submodules.sh b/t/t5526-fetch-submodules.sh index ce788e9..22a7358 100755 --- a/t/t5526-fetch-submodules.sh +++

[PATCH] add test for bug in git-mv with nested submodules

When using git-mv with a submodule it will detect that and update the paths for its configurations (.gitmodules, worktree and gitfile). This does not work for nested submodules where a user renames the root submodule. We discovered this fact when working on on-demand fetch for renamed submodules.

Re: [PATCH] check-ref-format: require a repository for --branch

On Mon, Jul 17, 2017 at 11:18:43PM +0200, Marko Kungla wrote: > I guess that should only be about that it should not hit a (BUG). > In my case in the example I gave I scan trough the directories to > check repository status one of the tasks make use of check-ref-format. > Since it may hit

Re: [PATCH] check-ref-format: require a repository for --branch

On Mon, Jul 17, 2017 at 10:27:09AM -0700, Jonathan Nieder wrote: > > --- a/t/t1402-check-ref-format.sh > > +++ b/t/t1402-check-ref-format.sh > > @@ -161,6 +161,10 @@ test_expect_success 'check-ref-format --branch from > > subdir' ' > > test "$refname" = "$sha1" > > ' > > > >

Dear Talented

Dear Talented, I am Talent Scout For BLUE SKY FILM STUDIO, Present Blue Sky Studio a Film Corporation Located in the United State, is Soliciting for the Right to use Your Photo/Face and Personality as One of the Semi -Major Role/ Character in our Upcoming ANIMATED Stereoscope 3D Movie-The

Quick Loans

Loan Offer at 3%, Feel Free to REPLY back to us for more info

Re: git fetch with refspec does not include tags?

On Thu, Aug 17, 2017 at 09:02:52AM +, Carlsson, Magnus wrote: > In the git fetch documentation it states that by default you will > fetch all tags that point into the history to the branches fetched. > > "By default, any tag that points into the histories being fetched is > also fetched; the

Re: git add -p breaks after split on change at the top of the file

On Thu, Aug 17, 2017 at 05:03:08AM -0400, Jeff King wrote: > But that does the opposite of what we want: it makes this case work when > --allow-overlap isn't specified. I think my first attempt is probably > closer to the right direction (but we'd want to have it kick in only > when

Re: git add -p breaks after split on change at the top of the file

On Thu, Aug 17, 2017 at 04:41:09AM -0400, Jeff King wrote: > diff --git a/apply.c b/apply.c > index 41ee63e1db..606db58218 100644 > --- a/apply.c > +++ b/apply.c > @@ -2966,8 +2966,9 @@ static int apply_one_fragment(struct apply_state *state, >* In other words, a hunk that is

git fetch with refspec does not include tags?

Hi​ In the git fetch documentation it states that by default you will fetch all tags that point into the history to the branches fetched. "By default, any tag that points into the histories being fetched is also fetched; the effect is to fetch tags that point at branches that you are

Re: git add -p breaks after split on change at the top of the file

[+cc Junio, as this gets deep into git-apply innards] On Wed, Aug 16, 2017 at 10:25:04PM +0200, Simon Ruderich wrote: > $ git add -p > diff --git a/file b/file > index 587be6b..74a69a0 100644 > --- a/file > +++ b/file > @@ -1 +1,4 @@ > +a > +b > x > +c >

Re: [PATCH/FIXUP 6/2] apply: clarify read_old_data() is about no-index case

On Thu, Aug 17, 2017 at 12:12:36AM -0700, Junio C Hamano wrote: > Torsten Bögershausen writes: > > > Unless we re-define the meaning of "NULL" into "don't do CRLF conversions, > > like SAFE_CRLF_KEEP_CRLF does. > > My preference is not to use NULL as any hint. Instead, the

Re: reftable [v7]: new ref storage format

On Wed, Aug 16, 2017 at 11:05 PM, Junio C Hamano wrote: > I found it a slightly odd that we do not insist that update_indices > that appear in a single reftable file are consecutive, yet we > require that min_update_index of a reftable file must be one greater > than the

Re: [PATCH/FIXUP 6/2] apply: clarify read_old_data() is about no-index case

Torsten Bögershausen writes: > Unless we re-define the meaning of "NULL" into "don't do CRLF conversions, > like SAFE_CRLF_KEEP_CRLF does. My preference is not to use NULL as any hint. Instead, the "flag" parameter we already pass to convert_to_git(), just like the updated

Re: [PATCH/FIXUP 6/2] apply: clarify read_old_data() is about no-index case

Torsten Bögershausen writes: > I don't have time to look at this today or tomorrow, > please give a hint if you are working further. It is past my bedtime, and generally I prefer not to touch topics that I know other people are willing to look into, especially when I know those

Re: [PATCH] fix revisions doc about quoting for ':/' notation

On 17 August 2017 at 05:57, Junio C Hamano wrote: > Andreas Heiduk writes: > >> Am 16.08.2017 um 05:21 schrieb ryenus: >>> To make sure the `` in `:/` is seen as one search string, >>> one should quote/escape `` properly. >>> >>> Especially, the example

[PATCH v2] update revisions doc for quoting in ':/' notation

To make sure the `` in `:/` is seen as one search string, one should quote/escape `` properly. Especially, the example given in the manual `:/fix nasty bug` does not work because of missing quotes when used in shell. A note about quoting/escaping is added along with a working example, however,

Re: [PATCH v2 2/2] File commited with CRLF should roundtrip diff and apply

tbo...@web.de writes: > Analyze the patch if there is a) any context line with CRLF, > or b) if any line with CRLF is to be removed. > Thanks to Junio C Hamano, his input became the base for the changes in t4124. > One test case is split up into 3: > - Detect the " a\r" line in the patch > -

Re: [PATCH/FIXUP 6/2] apply: clarify read_old_data() is about no-index case

On Wed, Aug 16, 2017 at 11:34:45AM -0700, Junio C Hamano wrote: > With the previous fixes to CRLF handling in place, read_old_data() > knows what it wants convert_to_git() to do with respect to CRLF. In > fact, this codepath is about applying a patch to a file in the > filesystem, which may not

[PATCH v2 1/2] convert: Add SAFE_CRLF_KEEP_CRLF

From: Torsten Bögershausen When convert_to_git() is called, the caller may want to keep CRLF to be kept as CRLF (and not converted into LF). This will be used in the next commit, when apply works with files that have CRLF and patches are applied onto these files. Add the new

[PATCH v2 2/2] File commited with CRLF should roundtrip diff and apply

From: Torsten Bögershausen When a file had been commited with CRLF but now .gitattributes say "* text=auto" (or core.autocrlf is true), the following does not roundtrip, `git apply` fails: printf "Added line\r\n" >>file && git diff >patch && git checkout -- . && git apply patch