On Mon, Nov 13, 2017 at 10:35 PM, Louis Gruand
wrote:
> Dear team, when i download Git on Mac it says “no mountable file systems” and
> doesnt open after. how can i solve this?
When googling "Mac no mountable file systems", it looks like this
error is not specific to Git.
Could you check if you
h...@unimetic.com writes:
> From: Haaris
>
> Description:
> This patch adds a new option to the config command.
>
> Uses flag --expiry-date as a data-type to covert date-strings to
> timestamps when reading from config files (GET).
> This flag is ignored on write (SET) because the date-string is
On Tue, Nov 14, 2017 at 3:04 AM, wrote:
> From: Haaris
>
> Description:
> This patch adds a new option to the config command.
>
> Uses flag --expiry-date as a data-type to covert date-strings to
> timestamps when reading from config files (GET).
> This flag is ignored on write (SET) because the
Kaartic Sivaraam writes:
>> * jc/branch-name-sanity (2017-10-14) 3 commits
>> - branch: forbid refs/heads/HEAD
>> - branch: split validate_new_branchname() into two
>> - branch: streamline "attr_only" handling in validate_new_branchname()
>>
>> "git branch" and "git checkout -b" are now forbi
Nicolas Morey-Chaisemartin writes:
> - const char *body = "*** SUBJECT HERE ***\n\n*** BLURB HERE ***\n";
> - const char *msg;
> + const char *body = "*** SUBJECT HERE ***\n\n*** BLURB HERE ***\n\n";
H.
> @@ -1021,17 +1021,21 @@ static void make_cover_letter(struct rev_info *rev
Nicolas Morey-Chaisemartin writes:
> if (!git_config_get_bool("commit.gpgsign", &gpgsign))
> state->sign_commit = gpgsign ? "" : NULL;
> +
> }
Please give at least a cursory proof-reading before sending things
out.
> @@ -1106,14 +1131,6 @@ static void am_next(struct am_stat
On Mon, Nov 13, 2017 at 04:13:19PM -0500, Marc Branchaud wrote:
> Various incantations of "git show ... 9c355a7726e31" only fail with the same
> error, so I can't determine much about the problematic commit. Luckily I'm
> not particularly concerned with losing objects, as I push any important
> pr
Nicolas Morey-Chaisemartin writes:
> Extract the patch ID and series length from the [PATCH N/M]
> prefix in the mail header
>
> Signed-off-by: Nicolas Morey-Chaisemartin
> ---
> mailinfo.c | 35 +++
> mailinfo.h | 2 ++
> 2 files changed, 37 insertions(+)
As
* jc/branch-name-sanity (2017-10-14) 3 commits
- branch: forbid refs/heads/HEAD
- branch: split validate_new_branchname() into two
- branch: streamline "attr_only" handling in validate_new_branchname()
"git branch" and "git checkout -b" are now forbidden from creating
a branch whose name is
Elijah Newren writes:
> + entry = dir_rename_find_entry(dir_renames, old_dir);
> + if (!entry) {
> + entry = xcalloc(1, sizeof(struct dir_rename_entry));
> + hashmap_entry_init(entry, strhash(old_dir));
Please make these two lines i
On Monday 13 November 2017 05:00 PM, Kevin Daudt wrote:
On Mon, Nov 13, 2017 at 08:01:12AM +0530, Kaartic Sivaraam wrote:
That was a little attribution I wanted make to the strbuf API as this was
the first time I leveraged it to this extent and I was surprised by the way
it made string manipulat
Elijah Newren writes:
> Create a new function, get_diffpairs() to compute the diff_filepairs
> between two trees. While these are currently only used in
> get_renames(), I want them to be available to some new functions. No
> actual logic changes yet.
OK.
This refactors an easy-to-use (in t
Junio C Hamano wrote:
The message goes to the standard output stream since it was
introduced in 809f38c8 ("git notes merge: Manual conflict
resolution, part 1/2", 2010-11-09) and 6abb3655 ("git notes merge:
Manual conflict resolution, part 2/2", 2010-11-09). I do think it
makes more sense to s
Junio C Hamano writes:
> Elijah Newren writes:
>
>> +struct rename_info {
>> +struct string_list *head_renames;
>> +struct string_list *merge_renames;
>> +};
>
> This type is added in order to allow the caller and the helper to
> communicate the findings in a single logical structure, in
Elijah Newren writes:
> get_renames() has always zero'ed out diff_queued_diff.nr while only
> manually free'ing diff_filepairs that did not correspond to renames.
> Further, it allocated struct renames that were tucked away in the
> return string_list. Make sure all of these are deallocated when
Elijah Newren writes:
> +struct rename_info {
> + struct string_list *head_renames;
> + struct string_list *merge_renames;
> +};
This type is added in order to allow the caller and the helper to
communicate the findings in a single logical structure, instead of
having to pass them as sep
Elijah Newren writes:
> I want to re-use some other functions in the file without moving those other
> functions or dealing with a handful of annoying split function declarations
> and definitions.
>
> Signed-off-by: Elijah Newren
> ---
It took me a while to figure out that you are basing this
What's cooking in git.git (Nov 2017, #04; Tue, 14)
--
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 i
Todd Zullinger writes:
>> I wonder if this line in 3320 is doing what it meant to do:
>>
>>test_must_fail git notes merge z 2>&1 >out &&test_i18ngrep
>> "Automatic notes merge failed" out &&grep -v "A notes merge into
>> refs/notes/x is already in-progress in" out
>
> That's a fine qu
[+cc:Duy]
On Mon, Nov 13, 2017 at 4:06 PM, Robert P. J. Day wrote:
> On Mon, 13 Nov 2017, Eric Sunshine wrote:
>> On Mon, Nov 13, 2017 at 9:48 AM, Robert P. J. Day
>> wrote:
>> > finally, the prune "--expire" option is truly confusing:
>> >
>> > --expire
>> > With prune, only exp
Ann T Ropea writes:
> Where needed, we arrange for invocations of Git as if
>
>"-c core.printsha1ellipsis=true"
>
> had been specified on the command-line. This furnishes ellipses in the
> output which then matches what is expected.
>
> Signed-off-by: Ann T Ropea
> ---
I am not a huge fan
Santiago Torres wrote:
Quick followup.
The version that triggers this is at least 2.1.21[1]. I recall there
was some wiggle room on minor versions before it.
Thanks for digging that up! I had 2.1.13 at hand in a fedora-25
chroot which I used to build git recently, but I've not been able to
Ann T Ropea writes:
> Neither Git nor the user are in need of this (visual) aid anymore, but
> we must offer a transition period.
>
> Also, fix a typo: "abbbreviated" ---> "abbreviated".
>
> Signed-off-by: Ann T Ropea
> ---
> v2: rename patch series & focus on removal of ellipses
> diff.c | 69
Junio C Hamano wrote:
**Blush**. I should have caught this during the review. Thanks.
I've written that code myself in the past and I am sure I will do it
again. :)
I wonder if this line in 3320 is doing what it meant to do:
test_must_fail git notes merge z 2>&1 >out &&
test_i18ng
Todd Zullinger writes:
> In 29ff1f8f74 (t: lib-gpg: flush gpg agent on startup, 2017-07-20), a
> call to gpgconf was added to kill the gpg-agent. The intention was to
> ignore all output from the call, but the order of the redirection needs
> to be switched to ensure that both stdout and stderr
Charles Bailey writes:
>> > But that we should take it anyway regardless of that since it'll *also*
>> > work on Linux with your patch, and this logic makes some sense whereas
>> > the other one clearly didn't and just worked by pure accident of some
>> > toolchain semantics that I haven't figure
Joey Hess writes:
> Jeff King wrote:
>> This should make Joey's immediate pain go away, though only by papering
>> it over. I tend to agree that we shouldn't be looking at $PWD at all
>> here.
>
> I've confirmed that Jeff's patch fixes the case I was having trouble with.
Thanks, both.
From: Haaris
Description:
This patch adds a new option to the config command.
Uses flag --expiry-date as a data-type to covert date-strings to
timestamps when reading from config files (GET).
This flag is ignored on write (SET) because the date-string is stored in
config without performing any n
Stefan Beller writes:
> On Fri, Nov 10, 2017 at 11:05 AM, Elijah Newren wrote:
>> Signed-off-by: Elijah Newren
>> ...
>> +# B
>> +# o
>> +# / \
>> +# A o ?
>> +# \ /
>> +# o
>> +# C
>> + ...
>> +# Testcase 1a, Basic directory rename.
>> +# Commit A: z/{b,c}
>> +
On Mon, Nov 13, 2017 at 5:21 PM, Stefan Beller wrote:
> On Mon, Nov 13, 2017 at 4:57 PM, Elijah Newren wrote:
> (slightly dreaming:)
> I wonder if we could teach our test suite to accept multiple test_done
> or restart_tests or such to resurrect the clean slate.
I'm dreaming now too; I would li
On Mon, Nov 13, 2017 at 4:25 PM, Stefan Beller wrote:
> On Fri, Nov 10, 2017 at 11:05 AM, Elijah Newren wrote:
>> +# Testcase 6b, Same rename done on both sides
>> +# (Related to testcases 6c and 8e)
>> +# Commit A: z/{b,c}
>> +# Commit B: y/{b,c}
>> +# Commit C: y/{b,c}, z/d
>
> Missing
Elijah Newren writes:
> If I have to walk through the debugger and inspect the values found in
> here in order to figure out their meaning, despite having known these
> things inside and out some years back, then they probably need a comment
> for the casual reader to explain their purpose.
>
> S
On Mon, Nov 13, 2017 at 4:57 PM, Elijah Newren wrote:
> On Mon, Nov 13, 2017 at 2:04 PM, Stefan Beller wrote:
>> On Fri, Nov 10, 2017 at 11:05 AM, Elijah Newren wrote:
>> (minor thought:)
>> After rereading the docs above this is clear; I wonder if instead of A, B, C
>> a notation of Base, ours,
On Mon, Nov 13, 2017 at 4:15 PM, Stefan Beller wrote:
> On Fri, Nov 10, 2017 at 11:05 AM, Elijah Newren wrote:
>> +# Testcase 5c, Transitive rename would cause
>> rename/rename/rename/add/add/add
>> +# (Directory rename detection would result in transitive rename vs.
>> +#rename/rename(1to
Elijah Newren writes:
> 2) Instead of counting pairs of source/dest files compared, just
> count number of dest paths completed. (Thus, we wouldn't need a value
> big enough to hold rename_dst_nr * rename_src_nr, just big enough to
> hold rename_dst_nr).
This sounds like the most sensible thi
Phillip Wood writes:
> Are you happy with the '--signoff' is handled (I didn't modify my
> changes in the last iteration as you were still thinking about it)?
I am not, but I am not unhappy, either.
As I understand from your responses, it seems that the existing code
had an untriggerable mess a
Ben Peart writes:
> The proposed format for extensions (ie having both a header and a
> footer with name and size) in the current patch already enables having
> multiple extensions that can be parsed forward or backward. Any
> extensions that would want to be parse-able in reverse would just all
On Mon, Nov 13, 2017 at 3:25 PM, Stefan Beller wrote:
> On Fri, Nov 10, 2017 at 11:05 AM, Elijah Newren wrote:
>> +# Testcase 3a, Avoid implicit rename if involved as source on other side
>> +# (Related to testcases 1c and 1f)
>> +# Commit A: z/{b,c,d}
>> +# Commit B: z/{b,c,d} (no change)
On Mon, Nov 13, 2017 at 2:04 PM, Stefan Beller wrote:
> On Fri, Nov 10, 2017 at 11:05 AM, Elijah Newren wrote:
> (minor thought:)
> After rereading the docs above this is clear; I wonder if instead of A, B, C
> a notation of Base, ours, theirs would be easier to understand?
Sure, that'd be an ea
On Fri, Nov 10, 2017 at 11:05 AM, Elijah Newren wrote:
> +# In my opinion, testcases that are difficult to understand from this
> +# section is due to difficulty in the testcase rather than the directory
> +# renaming (similar to how t6042 and t6036 have difficult resolutions due
> +# to the prob
On Fri, Nov 10, 2017 at 11:05 AM, Elijah Newren wrote:
> Signed-off-by: Elijah Newren
> ---
> t/t6043-merge-rename-directories.sh | 283
>
> 1 file changed, 283 insertions(+)
>
> diff --git a/t/t6043-merge-rename-directories.sh
> b/t/t6043-merge-rename-dire
On Fri, Nov 10, 2017 at 11:05 AM, Elijah Newren wrote:
> Signed-off-by: Elijah Newren
> ---
> t/t6043-merge-rename-directories.sh | 303
>
> 1 file changed, 303 insertions(+)
>
> diff --git a/t/t6043-merge-rename-directories.sh
> b/t/t6043-merge-rename-dire
On Fri, Nov 10, 2017 at 11:05 AM, Elijah Newren wrote:
> Signed-off-by: Elijah Newren
> ---
> t/t6043-merge-rename-directories.sh | 100
>
> 1 file changed, 100 insertions(+)
>
> diff --git a/t/t6043-merge-rename-directories.sh
> b/t/t6043-merge-rename-dire
On Mon, Nov 13, 2017 at 3:39 PM, Elijah Newren wrote:
> On Mon, Nov 13, 2017 at 2:12 PM, Stefan Beller wrote:
>> I wanted to debug a very similar issue today just after reviewing this
>> series, see
>> https://public-inbox.org/git/743acc29-85bb-3773-b6a0-68d4a0b8f...@ispras.ru/
>
> Oh, bleh. Tha
On Mon, Nov 13, 2017 at 2:12 PM, Stefan Beller wrote:
> I wanted to debug a very similar issue today just after reviewing this
> series, see
> https://public-inbox.org/git/743acc29-85bb-3773-b6a0-68d4a0b8f...@ispras.ru/
Oh, bleh. That's not a D/F conflict at all, it's the code assuming
there's a
On Fri, Nov 10, 2017 at 11:05 AM, Elijah Newren wrote:
> Signed-off-by: Elijah Newren
> ---
> t/t6043-merge-rename-directories.sh | 137
>
> 1 file changed, 137 insertions(+)
>
> diff --git a/t/t6043-merge-rename-directories.sh
> b/t/t6043-merge-rename-dire
On Fri, Nov 10, 2017 at 11:05 AM, Elijah Newren wrote:
> Signed-off-by: Elijah Newren
> ---
> t/t6043-merge-rename-directories.sh | 125
>
> 1 file changed, 125 insertions(+)
>
> diff --git a/t/t6043-merge-rename-directories.sh
> b/t/t6043-merge-rename-dire
On Mon, Nov 13, 2017 at 2:57 PM, Elijah Newren wrote:
>
> Perhaps:
>
> If 'before' is renamed to 'after' then src_entry will contain
> the versions of 'before' from the merge_base, HEAD, and MERGE in
> stages 1, 2, and 3; and dst_entry will contain the respective versions of
> 'after' in c
Quick followup.
The version that triggers this is at least 2.1.21[1]. I recall there was some
wiggle room on minor versions before it.
Thanks!
-Santiago.
[1] https://dev.gnupg.org/T3218
On Mon, Nov 13, 2017 at 06:02:02PM -0500, Santiago Torres wrote:
>
> > Were the ENOENT errors you encounter
> Were the ENOENT errors you encountered in running the tests multiple times
> easy to reproduce?
If you had the right gpg2, it should be easy to repro with just re-running.
> If so, I can certainly try to reproduce them and then
> run the tests with --reload in place of --kill to gpgconf. If
On Mon, Nov 13, 2017 at 1:06 PM, Stefan Beller wrote:
> On Fri, Nov 10, 2017 at 11:05 AM, Elijah Newren wrote:
>> + /*
>> +* Because I keep forgetting every few years what src_entry and
>> +* dst_entry are and have to walk through a debugger and puzzle
>> +* through
Hi Santiago,
Santiago Torres wrote:
Thanks for catching the redirection issue! I agree that the other
fixes feel like overkill. Are you certain that switching to gpgconf
--reload will have the same effect as --kill? (I know that this is
the case for scdaemon only).
I am not at all certain wh
Where needed, we arrange for invocations of Git as if
"-c core.printsha1ellipsis=true"
had been specified on the command-line. This furnishes ellipses in the
output which then matches what is expected.
Signed-off-by: Ann T Ropea
---
v2: rename patch series & focus on removal of ellipses
t/
Confusing the ellipsis with the three-dot operator should be made as
difficult as possible.
Signed-off-by: Ann T Ropea
---
v2: rename patch series & focus on removal of ellipses
Documentation/user-manual.txt | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --g
Neither Git nor the user are in need of this (visual) aid anymore, but
we must offer a transition period.
Also, fix a typo: "abbbreviated" ---> "abbreviated".
Signed-off-by: Ann T Ropea
---
v2: rename patch series & focus on removal of ellipses
diff.c | 69 +-
We do not want an ellipsis displayed following an (abbreviated) SHA-1
value.
The days when this was necessary to indicate the truncation to
lower-level Git commands and/or the user are bygone.
However, to ease the transition, the ellipsis will still be printed if
the user (actively!) sets the con
Signed-off-by: Ann T Ropea
---
v2: rename patch series & focus on removal of ellipses
Documentation/revisions.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt
index 61277469c874..dfcc49c72c0f 100644
--- a/Documentati
We use it to ascertain whether or not the user wants an ellipsis
printed after an abbreviated SHA-1 value.
By de-asserting it in the default, we encourage not printing the
ellipsis in such circumstances.
Not adding a corresponding cli option is intentional; and we would like
to remove the config
Thanks for the reviews!
On Mon, Nov 13, 2017 at 1:33 PM, Jonathan Tan wrote:
> On Mon, 13 Nov 2017 12:15:58 -0800
> Elijah Newren wrote:
>
>> -static int display(struct progress *progress, unsigned n, const char *done)
>> +static int display(struct progress *progress, uint64_t n, const char *don
> Of course, beyond getting stderr to /dev/null, there is the fact that on
> versions of gnupg < 2.1, gpgconf --kill is not available. I noticed this with
> gnupg-2.0.14 on CentOS 6. It also occurs on CentOS 7, which provides
> gnupg-2.0.22.
>
> I don't know if there's much value in trying to
On Mon, Nov 13, 2017 at 2:03 PM, Luke Diamand wrote:
> On 13 November 2017 at 19:51, Luke Diamand wrote:
>> Hi!
>>
>> I think there may be a regression caused by this change which means
>> that "git fetch origin" doesn't work:
>>
>> commit d0c39a49ccb5dfe7feba4325c3374d99ab123c59 (refs/bisect/bad
On Mon, Nov 13, 2017 at 2:04 PM, Elijah Newren wrote:
> Do you feel it's important that I come up with a demonstration case
> here? If so, I'll see if I can generate one.
I was mostly "just curious" on how you'd construct it theoretically.
> it's actually something newly possible only due to d
I have important transaction for you as next of kin to claim US$8.37m email me
at changgordo...@yahoo.com.hk so I can send you more
details
Thanks for the reviews!
On Mon, Nov 13, 2017 at 11:48 AM, Stefan Beller wrote:
> On Fri, Nov 10, 2017 at 11:05 AM, Elijah Newren wrote:
>> merge_trees() did a variety of work, including:
>> * Calling get_unmerged() to get unmerged entries
>> * Calling record_df_conflict_files() with all unme
On Fri, Nov 10, 2017 at 11:05 AM, Elijah Newren wrote:
> Signed-off-by: Elijah Newren
> ---
> t/t6043-merge-rename-directories.sh | 391
>
> 1 file changed, 391 insertions(+)
> create mode 100755 t/t6043-merge-rename-directories.sh
>
> diff --git a/t/t6043-
On 13 November 2017 at 19:51, Luke Diamand wrote:
> Hi!
>
> I think there may be a regression caused by this change which means
> that "git fetch origin" doesn't work:
>
> commit d0c39a49ccb5dfe7feba4325c3374d99ab123c59 (refs/bisect/bad)
> Author: Nguyễn Thái Ngọc Duy
> Date: Wed Aug 23 19:36:5
Apologies in advance for the vagueness of this bug report.
I was juggling a few patches around in a git repo (happens to be linux
but that's probably not particularly relevant).
I'd been reverting, rebasing and cherry-picking on the CLI. Then I
found I needed one more commit which I located with
Dear team, when i download Git on Mac it says “no mountable file systems” and
doesnt open after. how can i solve this?
Thank you for your help,
On Mon, 13 Nov 2017 12:15:58 -0800
Elijah Newren wrote:
> -static int display(struct progress *progress, unsigned n, const char *done)
> +static int display(struct progress *progress, uint64_t n, const char *done)
> {
> const char *eol, *tp;
>
> @@ -106,7 +106,7 @@ static int display(str
(I'm using git 2.15.0.)
So today "git gc" started complaining:
error: Could not read 2bc277bcb7e9cc6ef2ea677dd1c3dcd1f9af0c2b
fatal: Failed to traverse parents of commit
9c355a7726e31b3033b8e714cf7edb4f0a41d8d4
error: failed to run repack
I suspect I'm a victim of the worktree+submodule bugs
The intention is to ignore all output from the 'git stash apply' call.
Adjust the order of the redirection to ensure that both stdout and
stderr are redirected to /dev/null.
Signed-off-by: Todd Zullinger
---
git-rebase.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-re
On 11 November 2017 at 00:13, Joel Teichroeb wrote:
> If the merge does not have anything to do, it does not unlock the index,
> causing any further index operations to fail. Thus, always unlock the index
> regardless of outcome.
> if (clean < 0)
> return clean;
Do we nee
In 29ff1f8f74 (t: lib-gpg: flush gpg agent on startup, 2017-07-20), a
call to gpgconf was added to kill the gpg-agent. The intention was to
ignore all output from the call, but the order of the redirection needs
to be switched to ensure that both stdout and stderr are redirected to
/dev/null. Wit
On Mon, 13 Nov 2017, Eric Sunshine wrote:
> On Mon, Nov 13, 2017 at 9:48 AM, Robert P. J. Day
> wrote:
... snip ...
> > finally, the prune "--expire" option is truly confusing:
> >
> > --expire
> > With prune, only expire unused working trees older than .
> >
> > suddenly, we en
On Fri, Nov 10, 2017 at 11:05 AM, Elijah Newren wrote:
> If I have to walk through the debugger and inspect the values found in
> here in order to figure out their meaning, despite having known these
> things inside and out some years back, then they probably need a comment
> for the casual reader
On Mon, 13 Nov 2017 12:15:58 -0800
Elijah Newren wrote:
> The possibility of setting merge.renameLimit beyond 2^16 raises the
> possibility that the values passed to progress can exceed 2^32.
> Use uint64_t, because it "ought to be enough for anybody". :-)
>
> Signed-off-by: Elijah Newren
> --
When trying to cherry-pick a change that has lots of renames, it is
somewhat unsettling to wait a really long time without any feedback.
Signed-off-by: Elijah Newren
---
sequencer.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sequencer.c b/sequencer.c
index 2b4cecb617..247d93f363 100644
In commit 0024a5492 (Fix the rename detection limit checking; 2007-09-14),
the renameLimit was clamped to 32767. This appears to have been to simply
avoid integer overflow in the following computation:
num_create * num_src <= rename_limit * rename_limit
although it also could be viewed as a h
This patchset fixes some issues around rename detection limits. Changes
since the original submission[1]:
* Patches 2 and 3 are swapped in order so as to not temporarily introduce
any bugs (even if only cosmetic)
* Commit message fixups
* Using uint64_t instead of double for holding mult
The possibility of setting merge.renameLimit beyond 2^16 raises the
possibility that the values passed to progress can exceed 2^32.
Use uint64_t, because it "ought to be enough for anybody". :-)
Signed-off-by: Elijah Newren
---
This does imply 64-bit math for all progress operations. Possible a
When many files were renamed, the recursive merge strategy stopped
detecting renames and left many paths with delete/modify conflicts,
without any warning about what was going on or providing any hints about
how to tell Git to spend more cycles to detect renames.
Signed-off-by: Elijah Newren
---
Thanks for the reviews and suggestions!
On Sun, Nov 12, 2017 at 9:24 PM, Junio C Hamano wrote:
> Elijah Newren writes:
>
>> Subject: Re: [PATCH 3/4] progress: Fix progress meters when dealing with
>> lots of work
>
> Style: s/Fix/fix/;
I also messed this up in a lot of my patches in my other p
Le 13/11/2017 à 20:40, Jonathan Tan a écrit :
> On Mon, 13 Nov 2017 18:13:27 +0100
> Nicolas Morey-Chaisemartin wrote:
>
>> v2:
>> - Enhance mailinfo to parse patch series id from subject
>> - Detect cover using mailinfo parsed ids in git am
> I noticed that this was done in the patch set by sea
Hi!
I think there may be a regression caused by this change which means
that "git fetch origin" doesn't work:
commit d0c39a49ccb5dfe7feba4325c3374d99ab123c59 (refs/bisect/bad)
Author: Nguyễn Thái Ngọc Duy
Date: Wed Aug 23 19:36:59 2017 +0700
revision.c: --all adds HEAD from all worktrees
Junio C Hamano wrote:
This change probably makes sense. From here on after applying the
patch, we won't have to worry about updating these every time they
move---not that they have moved often, though ;-)
Indeed. It's thankfully a rare move. I imagine that's why it's
somewhat common to fin
On Fri, Nov 10, 2017 at 11:05 AM, Elijah Newren wrote:
> merge_trees() did a variety of work, including:
> * Calling get_unmerged() to get unmerged entries
> * Calling record_df_conflict_files() with all unmerged entries to
> do some work to ensure we could handle D/F conflicts correctly
>
On Mon, 13 Nov 2017 18:13:27 +0100
Nicolas Morey-Chaisemartin wrote:
> v2:
> - Enhance mailinfo to parse patch series id from subject
> - Detect cover using mailinfo parsed ids in git am
I noticed that this was done in the patch set by searching for "PATCH" -
that is probably quite error-prone a
On Fri, Nov 10, 2017 at 11:05 AM, Elijah Newren wrote:
> t3501 had a testcase originally added
... goes and looks ...
"in 05f2dfb965 (cherry-pick: demonstrate a segmentation fault, 2016-11-26)"
would have helped me here in the commit message.
> to ensure cherry-pick wouldn't
> segfault when
To subscribe to the git mailing list, send the email to
majord...@vger.kernel.org, not the mailing list itself.
On Sat, Nov 11, 2017 at 6:21 PM, wrote:
> subscribe git
On Sun, Nov 12, 2017 at 1:28 PM, brian m. carlson
wrote:
> Switch the uses of empty_tree_oid and empty_blob_oid to use the
> current_hash abstraction that represents the current hash algorithm in
> use.
>
> Signed-off-by: brian m. carlson
> ---
Thanks for writing this series,
all four patches lo
On Mon, Nov 13, 2017 at 3:22 AM, Peter Krefting wrote:
> Elijah Newren:
>
>> I would be very interested to hear how my rename detection performance
>> patches work for you; this kind of usecase was the exact one it was designed
>> to help the most. See
>> https://public-inbox.org/git/201711102221
Description:
This patch adds a new option to the config command.
Enables flag --expiry-date as a data-type to covert date-strings to
timestamps when reading from config files (GET).
This flag is ignored on write (SET) because the date-string is stored in
config without performing any normalizatio
On Mon, Nov 13, 2017 at 9:48 AM, Robert P. J. Day wrote:
> once more, into the man pages ... "git worktree" seems like a fairly
> simple command, but there is some confusion about the function of
>
> $ git worktree prune
>
> the normal meaning of "prune" (certainly with git commands) is to
> a
TODO: figure out defaults, add a config option, move tip detection to specific
function
Signed-off-by: Nicolas Morey-Chaisemartin
---
Documentation/git-format-patch.txt | 4
builtin/log.c | 44 +-
2 files changed, 38 insertions(+),
Extract the patch ID and series length from the [PATCH N/M]
prefix in the mail header
Signed-off-by: Nicolas Morey-Chaisemartin
---
mailinfo.c | 35 +++
mailinfo.h | 2 ++
2 files changed, 37 insertions(+)
diff --git a/mailinfo.c b/mailinfo.c
index a89db22ab..2
Issue with empty patch detection
Signed-off-by: Nicolas Morey-Chaisemartin
---
builtin/am.c | 143 ---
1 file changed, 126 insertions(+), 17 deletions(-)
diff --git a/builtin/am.c b/builtin/am.c
index 92c485350..702cbf8e0 100644
--- a/buil
v2:
- Enhance mailinfo to parse patch series id from subject
- Detect cover using mailinfo parsed ids in git am
- Support multiple patch series in a single run
TODO:
- Add doc/comments
- Add tests
- Add a new "seperator" at the end of a cover letter.
Right now I added a triple dash to all cover
Jeff King wrote:
> This should make Joey's immediate pain go away, though only by papering
> it over. I tend to agree that we shouldn't be looking at $PWD at all
> here.
I've confirmed that Jeff's patch fixes the case I was having trouble with.
--
see shy jo
signature.asc
Description: PGP sign
sup Git
http://bit.ly/2zz7jZe
Yours Truly
Cwestin
On 11/9/2017 11:46 PM, Junio C Hamano wrote:
Ben Peart writes:
To make this work for V4 indexes, when writing the index, it periodically
"resets" the prefix-compression by encoding the current entry as if the
path name for the previous entry is completely different and saves the
offset of th
1 - 100 of 122 matches
Mail list logo
