exec argument is a command, not a commit.
Signed-off-by: Orgad Shaneh
---
git-rebase--interactive.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index cbf44f8648..85a72b933e 100644
--- a/git-rebase--interactive.sh
On Sun, May 27, 2018 at 1:57 AM, Junio C Hamano wrote:
> Duy Nguyen writes:
>
>> On Sat, May 26, 2018 at 12:56 AM, Jeremy Linton
>> wrote:
>>> @@ -1416,7 +1416,7 @@ static void *unpack_compressed_entry(struct
>>> packed_git *p,
>>> return NULL;
>>> memset(&stream, 0, si
On Sat, May 26, 2018 at 8:47 AM, Christian Couder
wrote:
> Tests t9902-completion.sh and t9903-bash-prompt.sh each have tests
> that check what happens when we are "in the '.git' directory" and
> when we are "deep inside the '.git' directory".
>
> To test the case when we are "deep inside the '.gi
Todd, it looks like that may very well be the same issue. And it looks like
it's planning on being fixed in the next release? Would that be 2.17.1 since
it's a regression?
> On 2018 May 26, at 16:07, Todd Zullinger wrote:
>
> Hi Jeff,
>
> Jeff Felchner wrote:
>> Ever since 2.17.0, when savi
On Sat, May 26, 2018 at 4:31 PM Junio C Hamano wrote:
> *That* is something I don't do. After all, I am fully aware that I
> have started end-of-day ritual by that time, so I won't even look at
> a new patch (or a pull request for that matter).
Sounds like you're more organized about the end-of
Elijah Newren writes:
>> I'd expect that a reader of the commit who cares enough to bother to
>> wonder by looking at the patch and seeing that 2 became 3 would know
>> why already. And a reader of the resulting file would not know that
>> the 3 used to be 2, and won't be helped by "we used to c
Duy Nguyen writes:
> On Sat, May 26, 2018 at 12:56 AM, Jeremy Linton
> wrote:
>> @@ -1416,7 +1416,7 @@ static void *unpack_compressed_entry(struct packed_git
>> *p,
>> return NULL;
>> memset(&stream, 0, sizeof(stream));
>> stream.next_out = buffer;
>> - st
Linus Torvalds writes:
> Soes my use pattern of "git gc --prune=now" make sense? Maybe not. But
> it's what I've gotten used to, and it's at least not entirely insane.
FWIW, my end-of-day ritual is to do repack -a -d -f with a large
window and a small depth, followed by prune, which boils down
So this is a RFC patch, I'm not sure how much people really care, but I
find the current behavior of "git gc --prune=now" to be unnecessarily
dangerous.
There's two issues with it:
(a) parse_expiry_date() considers "now" to be special, and it actually
doesn't mean "now" at all, it means
--
--
(From: Mr.James Tan (Urgent & Confidential)
Good Day, Please Read.
My name is Mr.James Tan , I am the Bill and Exchange manager here in Bank
of Africa (BOA) Lome-Togo.West-Africa. I have a business proposal in the
tune of $9.7m, (Nine Million Seven Hundred Thousand Dollars Only) after th
Hi Jeff,
Jeff Felchner wrote:
> Ever since 2.17.0, when saving a patch (using add --patch
> but probably other ways as well), if the whitespace is
> removed from the initial column, the patch doesn't apply.
This sounds a bit like the issue discussed in this thread a
few weeks ago:
https://public
Ever since 2.17.0, when saving a patch (using add --patch but probably other
ways as well), if the whitespace is removed from the initial column, the patch
doesn't apply.
Full walkthrough (including comparison with 2.16.3) in the video attached to
this link:
https://www.dropbox.com/s/s1ophi4mw
On Sat, May 26, 2018 at 08:46:09PM +0200, Jakub Narebski wrote:
> One issue: in the future when Git moves to NewHash, it could encounter
> then both commit-graph files using SHA-1 and using NewHash. What about
> GRPH_OID_LEN then: for one of those it would be incorrect. Unless it is
> about minim
On Friday 25 May 2018 08:10 AM, Jeff King wrote:
> Subject: [PATCH] branch: customize "-l" warning in list mode
>
> People mistakenly use "git branch -l", thinking that it
> triggers list mode. It doesn't, but the lack of non-option
> arguments in that command does (and the "-l" becomes a
> silent
Derrick Stolee writes:
> The GRAPH_MIN_SIZE macro should be the smallest size of a parsable
> commit-graph file. However, the minimum number of chunks was wrong.
> It is possible to write a commit-graph file with zero commits, and
> that violates this macro's value.
>
> Rewrite the macro, and use
On Friday 25 May 2018 01:01 AM, Jeff King wrote:
> On Thu, May 24, 2018 at 03:22:14PM -0400, Jeff King wrote:
>
> Hmm, actually, I suppose the true value of the warning is to help people
> doing "git branch -l foo", and it would still work there. The "more
> extreme" from your suggested patch woul
Jeff King writes:
> On Thu, Mar 31, 2016 at 11:01:44AM -0700, Junio C Hamano wrote:
>> Michael Haggerty writes:
>>
>>> the backend now has to implement
>>>
struct ref_iterator *ref_iterator_begin_fn(const char *submodule,
const char *prefix,
>
Hi,
I published my blog post about this week. You can read it here:
https://blog.pa1ch.fr/posts/2018/05/26/en/gsoc2018-week-4.html
All comments are welcome!
Cheers,
Alban
Hello
Greetings to you please i have a business proposal for you contact me
for more detailes asap thanks.
Best Regards,
Miss.Zeliha ömer faruk
Esentepe Mahallesi Büyükdere
Caddesi Kristal Kule Binasi
No:215
Sisli - Istanbul, Turkey
Signed-off-by: Nguyễn Thái Ngọc Duy
---
fsck.c | 22 ++
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/fsck.c b/fsck.c
index b65ff2d856..ff1547d3c7 100644
--- a/fsck.c
+++ b/fsck.c
@@ -74,14 +74,15 @@ enum fsck_msg_id {
#undef MSG_ID
#define STR(x) #x
-#def
Commit 76f5df305b (log: decorate grafted commits with "grafted" -
2011-08-18) lets us decorate grafted commits but I forgot about the
color.decorate.* config.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/config.txt | 3 ++-
log-tree.c | 1 +
2 files changed, 3 insertions(+
Config variables are case-insensitive but this case/esac construct is
case-sensitive by default. For bash v4, it'll be easy. For platforms
that are stuck with older versions, we need an external command, but
that is not that critical. And where this additional overhead matters
the most is Windows,
This array will be used by some other function than parse_msg_id() in
the following commit. Factor out this prep code so it could be called
from that one.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
fsck.c | 40
1 file changed, 24 insertions(+), 16 deletions(
This is more inline with how we handle color slots in other code. It
also allows us to get the list of configurable color slots later.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
grep.c | 106 ++---
grep.h | 21 +++-
2 files changed, 62 in
For parsing, we don't really need this because the main config parser
will lowercase everything so we can do exact matching. But this array
now is also used for printing in `git help --config`. Keep camelCase
so we have a nice printout.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
advice.c | 42 +
The new help option --config-for-completion is a machine friendlier
version of --config where all the placeholders and wildcards are
dropped, leaving only the good, completable prefixes for
git-completion.bash to consume.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/help.c
Sometimes it helps to list all available config vars so the user can
search for something they want. The config man page can also be used
but it's harder to search if you want to focus on the variable name,
for example.
This is not the best way to collect the available config since it's
not precis
The only benefit from this move (apart from cleaner code) is that
advice.amWorkDir should now show up in `git help --config`. There
should be no regression since advice config is always read by the
git_default_config().
While at there, use advise() like other code. We now get "hint: "
prefix and t
The last patch makes "git config " shows camelCase names because
that's what's in the source: config.txt. There are still a couple
manual var completion in this code. Let's make them follow the naming
convention as well.
In theory we could automate this part too because we have the
information. Bu
v2 changes:
- based on 'next'
- C99 is now mentioned in the commit message
- fixed Eric's comments
- the old 8/9 partial case-insensitive support patch is replaced
with Szeder's version.
Szeder I claimed authorship because I wrote the commit message which
may not be what you like. If you
Instead of hard coding the name-to-id mapping in C code, keep it in an
array and use a common function to do the parsing. This reduces code
and also allows us to list all possible color slots later.
This starts using C99 designated initializers more for convenience
(the first designated initialize
On Fri, May 25, 2018 at 8:38 PM, Ævar Arnfjörð Bjarmason
wrote:
>
> On Fri, May 25 2018, Duy Nguyen wrote:
>
>> On Fri, May 25, 2018 at 10:12 AM, Junio C Hamano wrote:
+Currently this is used by linkgit:git-checkout[1] when 'git checkout
+' will checkout the '' branch on another remote,
Previous attempts to fix ita-related diffs breaks this case. To make
sure that does not happen again, add a test to verify the behavior
wrt. ita entries when we diff a worktree and a tree.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
t/t2203-add-intent.sh | 17 +
1 file changed, 17 in
Similar to 'git reset -N', this option makes 'git apply' automatically
mark new files as intent-to-add so they are visible in the following
'git diff' command and could also be committed with 'git commit -a'.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/git-apply.txt | 10 +-
ap
This option is supposed to fix the diff of "diff-files" (not reporting
ita entries as new files) and "diff-index --cached " ( showing
ita entries as present in the index with empty content) but not
"diff-index ".
When --ita-invisible-in-index is set on "git diff-index ",
unpack_trees() will eventu
v2 first fixes a bug in --ita-invisible-in-index that accidentally
affects diffing a worktree and a tree. This caused a regression when
v1's 1/2 turned this option on by default.
Other than that, 4/4 should address Junio's comments on v1's 2/2.
Nguyễn Thái Ngọc Duy (4):
diff: ignore --ita-[in]v
Due to the implementation detail of intent-to-add entries, the current
"git diff" (i.e. no treeish or --cached argument) would show the
changes in the i-t-a file, but it does not mark the file as new, while
"diff --cached" would mark the file as new while showing its content
as empty.
$ git d
Shallow clones with --shallow-since or --shalow-exclude work by
running rev-list to get all reachable commits, then draw a boundary
between reachable and unreachable and send "shallow" requests based on
that.
The code does miss one corner case: if rev-list returns nothing, we'll
have no border and
Hi Jonathan,
I'd like to confirm, that your patch fixes my problem: I can sync with
google repository now using git and curl version without gzip support.
Do you know how this patch is going to be released? Just HEAD now and GA in
the next planned release?
Communication looks like follow now:
r
39 matches
Mail list logo
