Hi,
As you might remember, I'm maintaining a remote helper that allows to
talk directly to mercurial servers with git: git-cinnabar.
When dealing with "foreign (non-git) repositories", it is often
necessary to refer to revisions with their native name. With mercurial,
that's a sha1, with svn it's
Jeff King venit, vidit, dixit 11.07.2017 10:24:
> On Tue, Jul 11, 2017 at 10:20:43AM +0200, Torsten Bögershausen wrote:
>
>>> No problem. I actually think it would be interesting if Git could
>>> somehow detect and warn about this situation. But the obvious way to do
>>> that would be to re-run th
On Thu, Aug 17, 2017 at 09:24:36PM +0200, Andreas Krey wrote:
> I'm seeing the message
>
>remote: warning: ignoring extra bitmap file:
> ./objects/pack/pack-2943dc24pack
>
> and indeed, there is such a thing (two, actually):
Only one is the extra. :) The other is doing something useful
On Fri, Aug 18, 2017 at 03:59:38AM +0200, Patryk Obara wrote:
> 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
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 Story
of
On Fri, Aug 18, 2017 at 03:59:36AM +0200, Patryk Obara wrote:
> diff --git a/commit.c b/commit.c
> index 8b28415..019e733 100644
> --- a/commit.c
> +++ b/commit.c
> @@ -134,17 +134,18 @@ int register_commit_graft(struct commit_graft *graft,
> int ignore_dups)
> return 0;
> }
>
> -struct
On Thu, Aug 17, 2017 at 02:30:53PM -0700, Junio C Hamano wrote:
> > I'm not sure I buy that. What does "turning it into a branch name" even
> > mean when you are not in a repository? Clearly @{-1} must fail. And
> > everything else is just going to output the exact input you provided.
>
> This "j
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
comman
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
>> should ignore the .update= none?
>
> I have
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: Kaartic Sivaraam
I didn't expect a "Helped-by", all I did was to give some random
comments. :-) I'm n
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
@@ -195,10 +195,10 @@ start-point i
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
> ---
Thanks, Will queue.
> grep.c | 2 +-
Thanks, will queue.
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 the traditional
desir
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 insertions(+), 1 deletion(-)
dif
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 Ob
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
index b60ae15..f5b5bec 100
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 deletions(-)
diff --git a/bu
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 free_graft,
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 changed, 6 insertions(+),
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 draft as version 1 of th
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)
> +
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 th
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
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 also be a culprit. Do you
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
> >> scripts (maybe by giving a good example) and perhaps also in the doc
> >> th
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 value "SAFE_CRLF_KE
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
Before applying
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 bitbucket 5.2 as well.
>
> Is
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:
>
>> The previous implementation of read_graft_li
> 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 requires
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 wit
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,
>>
>> /*
>>
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.
> 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 filters/sub-processes should really pay attention and not
>> output
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 "$refname" = "$sha1"
>> >
> 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" removes
>> the "skip submodules" config.
>>
>> C
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 any object_id buffer size.
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 expect that an ar
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 supported by Git.
Oh, absolutely.
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 added along with a w
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 before, for example.
[1] https://public-inbox.or
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
> >> > git fetch ../parent
> >> >
> >
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 storing the result according to
>> >
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 t0040:
t0040-parse-options.sh
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:
The current delta code produc
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 configured refspec ("ref
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 how
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 or remote-tracking branch.
>
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
>
> I didn't expect a "Helped-by", all I did was to give some random
> comments. :-) I'm not so sure about the comma-separation, that
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 pack-2943dc2477026f8
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 pull https://exampl
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 above two look go
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 longer applies).
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 counted
the line numbe
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.
>
> We discovered th
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 a reftable file must be one greater
>> th
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 some random
comments. :-) I'm not so sure about the comma-separation, that seems to
be a first in the project
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 arguments passed u
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.
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 array
that can be 'size_t len
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
> > 524a9f
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 deletions(-)
In this one, I did not find anything suspicious.
> diff --git a/tre
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 consume_line(void *state_, char *line,
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
> > appreciated.
>
> A code cleanup is appre
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 --git a/t/t5526-fetch-submodules.sh b/t/t5526-fetch-submodul
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 hunk header line, i
> 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 bigger and bigger, s
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"
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 c
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 char
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 thought Brandon had a series in flight
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 we do not have a pa
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 pass to convert_to_git(), just lik
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): 13
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 (refs_verify_refname_available
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
--
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,
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 mi
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 "argument
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 follo
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 insertions(+), 28 deletions(
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, so
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
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 some
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
+++ b/t/t5526-fetch-submodules.sh
@@ -19
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.
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 director
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"
> > '
> >
> > +test_expect_s
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 Story
Loan Offer at 3%, Feel Free to REPLY back to us for more info
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
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 --allow-overla
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 (frag->oldpos
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
interest
[+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
>
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 "flag"
> parameter we
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 max_update_index of a prev
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
read_old_data() uses
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 "other people" ar
1 - 100 of 101 matches
Mail list logo
