Eric Sunshine writes:
> On Mon, Oct 19, 2015 at 3:28 AM, Junio C Hamano wrote:
>> With the previous steps, it becomes clear that the mailinfo()
>> function is the only one that wants the "line" to be directly
>> touchable. Move it to the function scope of this function.
>>
>> Signed-off-by: Jun
Alex Henrie writes:
> 2015-10-16 11:42 GMT-06:00 Junio C Hamano :
>>
>> Yes, but that fixes historical "mistake", no?
>>
>> With this, you are breaking historical practice by changing only one
>> instance to deviate from the then-current practice of saying
>> 'options' without brackets. It is ba
Hi there! A friend of mine gave me your email adress.
He was confident you would be very happy to read my CV.
After looking through your homepage and seeing what it is you guys do, I am
also quite sure
you will not be disappointed. I'm attaching my CV for you to read.
I'm truly looking forward
David Turner writes:
> The problem is not the name_hash, but with the dir_hash. The dir_hash
> is only even populated on case-insensitive filesystems (which is why you
> and Linus don't see this bug). The dir_hash is not designed to catch
> d/f conflicts, but rather case conflicts (one side of
On Mon, Oct 19, 2015 at 11:09:19PM +, brian m. carlson wrote:
> On Mon, Oct 19, 2015 at 08:59:15PM +0100, Andreas Amann wrote:
> > Thank you for your answer. However, this reasoning only applies to loose
> > objects and not packfiles.
> >
> > My understanding is that "git prune" will not pru
On Fri, 2015-10-16 at 08:34 +0200, Michael Haggerty wrote:
> On 10/15/2015 09:46 PM, David Turner wrote:
> > is_branch was already non-static, but this patch declares it in the
> > header.
>
> The commit message no longer reflects the patch.
>
> > Signed-off-by: Ronnie Sahlberg
> > Signed-off-by
On Mon, Oct 19, 2015 at 08:59:15PM +0100, Andreas Amann wrote:
> Thank you for your answer. However, this reasoning only applies to loose
> objects and not packfiles.
>
> My understanding is that "git prune" will not prune any pack files
> (except those starting with tmp_). Only "git repack" sho
On Mon, Oct 19, 2015 at 3:28 AM, Junio C Hamano wrote:
> All callers of this function refrains from calling it when
s/refrains/refrain/
> mi->metainfo_charset is NULL; move the check to the callee,
> as it already has a few conditions at its beginning to turn
> it into a no-op.
>
> Signed-off-by
On Mon, Oct 19, 2015 at 3:28 AM, Junio C Hamano wrote:
> With the previous steps, it becomes clear that the mailinfo()
> function is the only one that wants the "line" to be directly
> touchable. Move it to the function scope of this function.
>
> Signed-off-by: Junio C Hamano
> ---
> diff --git
On Fri, 2015-10-16 at 09:04 -0700, Junio C Hamano wrote:
> David Turner writes:
>
> > We also do dozens or hundreds of merges per day and only saw this quite
> > rarely. Interestingly, we could only trigger it with an alternate
> > hashing function for git's hashmap implementation, and only once
On Mon, Oct 19, 2015 at 12:28 PM, Lars Schneider
wrote:
> Hi,
>
> I have a closed source Git repo which references an Open Source Git repo as
> Submodule. The Open Source Git repo references yet another Open Source repo
> as submodule. In order to avoid failing builds due to external services I
Hi all,
it is my pleasure to announce that Git for Windows 2.6.2 is available.
Please find it at https://git-for-windows.github.io/
Changes since Git for Windows v2.6.1 (October 5th 2015)
New Features
• Comes with Git v2.6.2
• Users who are part of a Windows domain now have sensible default
"brian m. carlson" writes:
> On Sun, Oct 18, 2015 at 10:37:55PM +0100, Andreas Amann wrote:
>> git (2.6.1) sometimes updates the modification time of a packfile, even if it
>> has not changed at all.
>>
>> On my system this triggers quite expensive an d unnecessary backup
>> operations, which I w
Dirty the test worktree's root directory, as the test expects.
When testing the untracked-cache, we previously assumed that checking
out master would be sufficient to mark the mtime of the worktree's
root directory as racily-dirty. But sometimes, the checkout would
happen at 12345.999 seconds and
Eric Sunshine writes:
> With this in mind, my
> question was also indirectly asking whether there was sufficient
> justification of the long-term cost of a --count-lines option. The
> argument that --count-lines would help test a proposed
> strbuf_count_lines() likely does not outweigh that cost.
Hi,
I have a closed source Git repo which references an Open Source Git repo as
Submodule. The Open Source Git repo references yet another Open Source repo as
submodule. In order to avoid failing builds due to external services I mirrored
the Open Source repos in my company network. That works
On Mon, Oct 19, 2015 at 1:03 PM, Christian Couder
wrote:
> On Mon, Oct 19, 2015 at 3:46 PM, Tobias Klauser wrote:
>> On 2015-10-18 at 19:18:53 +0200, Junio C Hamano wrote:
>>> Eric Sunshine writes:
>>> > Is there any application beyond git-rebase--interactive where a
>>> > --count-lines options
From: Lars Schneider
A changelist that contains only excluded files (e.g. via client spec or
branch prefix) will be imported as empty commit. Add option
"git-p4.ignoreEmptyCommits" to ignore these commits.
Signed-off-by: Lars Schneider
---
Documentation/git-p4.txt | 5 ++
git-p
It did work out without initializing the flag so far, but to make it
future proof, we want to explicitly initialize the flag.
Signed-off-by: Stefan Beller
---
run-command.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/run-command.c b/run-command.c
index b8b5747..108b930 100644
--- a/run-c
If the `get_next_task` did not explicitly called child_process_init
and only filled in some fields, there may have been some stale data
in the child process. This is hard to debug and also adds a review
burden for each new user of that API. To improve the situation, we
pass only cleanly initialized
Signed-off-by: Stefan Beller
---
t/t0061-run-command.sh | 16 +---
test-run-command.c | 12
2 files changed, 21 insertions(+), 7 deletions(-)
diff --git a/t/t0061-run-command.sh b/t/t0061-run-command.sh
index 0af77cd..f27ada7 100755
--- a/t/t0061-run-command.sh
+++ b
We reuse the get_next_task callback which would stop after invoking the
test program 4 times. However as we have only 3 parallel processes started
(We pass in 3 as max parallel processes and 3 is smaller than the spawn
cap in run-command, so we will start the 3 processes in the first run
determinis
I noticed a problem with the gracefully abortion in the parallel processing,
that is fixed in patch 1.
Patch 2 makes the API more maintainable/usable (the caller may forget to
call child_process_init and only fill in fields which the callback is
interested in)
Patch 3 is another fixup. It actuall
The return value of `pp_collect_finished` indicates if we want to shutdown
the parallel processing early. Both returns from that function should
return any accumulated results.
Signed-off-by: Stefan Beller
---
run-command.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/run-
ATTN:
Do you need a convenient and direct loan? We offer personal loan, car loan,
small business loan and Investment financing with an affordable interest rate,
fast and convenient. To apply email: enquir...@saharafc.com
--
To unsubscribe from this list: send the line "unsubscribe git" in
the bod
2015-10-16 11:42 GMT-06:00 Junio C Hamano :
> Alex Henrie writes:
>
>> 2015-10-16 10:36 GMT-06:00 Junio C Hamano :
>>> Makes sense, as all the other in the usage string are
>>> bracketted.
>>>
>>> Does it make sense to do this for contrib/examples, which is the
>>> historical record, though?
>>
>
On Mon, Oct 19, 2015 at 3:46 PM, Tobias Klauser wrote:
> On 2015-10-18 at 19:18:53 +0200, Junio C Hamano wrote:
>> Eric Sunshine writes:
>>
>> > Is there any application beyond git-rebase--interactive where a
>> > --count-lines options is expected to be useful? It's not obvious from
>> > the com
Hi Khải,
On Sat, 17 Oct 2015, Khải wrote:
> I'm using Windows 10. Before I install git 2.6.1.windows.1, I have
> installed git 1.9.5.github.0 (by installing GitHub Desktop), it works
> just fine.
Good.
> But when I installed git 2.6.1.windows.1 (from git-scm.com), I'm not
> able to use git anym
Hello,
I wish to notify you that late Gianni Agnelli, had included you as beneficiary
of his Will. He left the sum of sixty Million, Five Hundred Thousand Dollars
(US$60, 500,000.00) to you in the Codicil and last testament to his Will. This
may sound strange and unbelievable to you; you are ad
On 2015-10-18 at 19:18:53 +0200, Junio C Hamano wrote:
> Eric Sunshine writes:
>
> > Is there any application beyond git-rebase--interactive where a
> > --count-lines options is expected to be useful? It's not obvious from
> > the commit message that this change is necessarily a win for later
>
On 2015-10-18 at 01:57:57 +0200, Eric Sunshine wrote:
> On Fri, Oct 16, 2015 at 11:16 AM, Tobias Klauser wrote:
> > Implement the --count-lines options for git stripspace [...]
> >
> > This will make it easier to port git-rebase--interactive.sh to C later
> > on.
>
> Is there any application bey
Because the "push" command is already avaiable, remove it from the
"todo" file.
Signed-off-by: Fabio Porcedda
---
contrib/subtree/todo | 2 --
1 file changed, 2 deletions(-)
diff --git a/contrib/subtree/todo b/contrib/subtree/todo
index 7e44b00..0d0e777 100644
--- a/contrib/subtree/todo
+++ b/c
Branch descriptions are great. Even more so if you set
merge.branchdesc=true (while we are at it could there be a CLI option
to git merge that allowed overriding merge.branchdesc for that merge)
But the bit that pains me is that my description is local only.
Could we add support for syncing the b
Junio C Hamano writes:
> I personally would suggest whichever order you feel more comfortable
> and less error-prone.
This is a good summary, and I fully agree with it.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the bod
With the previous two commits, we established that the local
variable "line" in handle_body() and handle_boundary() functions
always refer to the global "line" that is used as the common and
shared "current line from the input". They are the only callers of
the last function that refers to the glo
In olden days we might have wanted to behave differently in
decode_header() if the header line was encoded with RFC2047, but we
apparently do not do so, hence this helper function can go, together
with its return value.
Signed-off-by: Junio C Hamano
---
builtin/mailinfo.c | 23 +++---
In this first step, move only 'email' and 'name' fields in there and
remove the corresponding globals. In subsequent patches, more
globals will be moved to this and the structure will be passed
around as a new parameter to more functions.
Signed-off-by: Junio C Hamano
---
builtin/mailinfo.c | 7
With the previous steps, it becomes clear that the mailinfo()
function is the only one that wants the "line" to be directly
touchable. Move it to the function scope of this function.
Signed-off-by: Junio C Hamano
---
builtin/mailinfo.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
di
Signed-off-by: Junio C Hamano
---
builtin/mailinfo.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/builtin/mailinfo.c b/builtin/mailinfo.c
index 18781b7..810d132 100644
--- a/builtin/mailinfo.c
+++ b/builtin/mailinfo.c
@@ -22,6 +22,7 @@ struct mailinfo {
Move the bulk of the code from builtin/mailinfo.c to mailinfo.c
so that new callers can start calling mailinfo() directly.
Note that a few calls to exit() and die() need to be cleaned up
for the API to be truly useful, which will come in later steps.
Signed-off-by: Junio C Hamano
---
Makefile
This function has a single caller, and called with the global "line"
holding the first line of the e-mail body after the caller finished
processing the e-mail headers. The function then goes into a loop
to process each line of the input, starting from what was given by
its caller, and fills the sa
And finally the endgame. Instead of spawning "git mailinfo" via the
run_command() API the same number of times as there are incoming
patches, make direct internal call to the libified mailinfo() from
"git am" to reduce the spawning overhead, which would matter on some
platforms.
Signed-off-by: Ju
Signed-off-by: Junio C Hamano
---
builtin/mailinfo.c | 132 ++---
1 file changed, 66 insertions(+), 66 deletions(-)
diff --git a/builtin/mailinfo.c b/builtin/mailinfo.c
index 81bb3c7..5a21d93 100644
--- a/builtin/mailinfo.c
+++ b/builtin/mailinfo.c
Signed-off-by: Junio C Hamano
---
builtin/mailinfo.c | 45 ++---
1 file changed, 26 insertions(+), 19 deletions(-)
diff --git a/builtin/mailinfo.c b/builtin/mailinfo.c
index 2c194da..ec65805 100644
--- a/builtin/mailinfo.c
+++ b/builtin/mailinfo.c
@@ -7,6
Signed-off-by: Junio C Hamano
---
builtin/mailinfo.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/builtin/mailinfo.c b/builtin/mailinfo.c
index 104d3d9..4eabc11 100644
--- a/builtin/mailinfo.c
+++ b/builtin/mailinfo.c
@@ -39,8 +39,6 @@ struct mailinfo {
struct str
Signed-off-by: Junio C Hamano
---
builtin/mailinfo.c | 27 ++-
1 file changed, 14 insertions(+), 13 deletions(-)
diff --git a/builtin/mailinfo.c b/builtin/mailinfo.c
index 737d0fc..18781b7 100644
--- a/builtin/mailinfo.c
+++ b/builtin/mailinfo.c
@@ -23,14 +23,14 @@ struct
Signed-off-by: Junio C Hamano
---
builtin/mailinfo.c | 25 +++--
1 file changed, 11 insertions(+), 14 deletions(-)
diff --git a/builtin/mailinfo.c b/builtin/mailinfo.c
index 6fc6aa8..104d3d9 100644
--- a/builtin/mailinfo.c
+++ b/builtin/mailinfo.c
@@ -41,8 +41,17 @@ struct ma
This requires us to pass the struct down to decode_header() and
convert_to_utf8() callchain.
Signed-off-by: Junio C Hamano
---
builtin/mailinfo.c | 40
1 file changed, 20 insertions(+), 20 deletions(-)
diff --git a/builtin/mailinfo.c b/builtin/mailinfo.c
Instead of dying in convert_to_utf8(), just report an error and let
the callers handle it. Between the two callers:
- decode_header() silently punts when it cannot parse a broken
RFC2047 encoded text (e.g. when it sees anything other than B or
Q after it sees "=?") by jumping to release_re
Signed-off-by: Junio C Hamano
---
builtin/mailinfo.c | 37 +++--
1 file changed, 23 insertions(+), 14 deletions(-)
diff --git a/builtin/mailinfo.c b/builtin/mailinfo.c
index b8b94d6..2c194da 100644
--- a/builtin/mailinfo.c
+++ b/builtin/mailinfo.c
@@ -30,10 +30,10
Signed-off-by: Junio C Hamano
---
builtin/mailinfo.c | 23 +--
1 file changed, 13 insertions(+), 10 deletions(-)
diff --git a/builtin/mailinfo.c b/builtin/mailinfo.c
index c0522f2..2c8f249 100644
--- a/builtin/mailinfo.c
+++ b/builtin/mailinfo.c
@@ -20,6 +20,8 @@ struct maili
When mailinfo() is eventually libified, the calling "git am" still
will have to write out the log message in the "msg" file for hooks
and other users of the information, but it does not have to reopen
and reread what it wrote earlier if the function kept it in a strbuf.
This also removes the need
This one is trivial thanks to previous steps that started passing
the structure throughout the input codepaths.
Signed-off-by: Junio C Hamano
---
builtin/mailinfo.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/builtin/mailinfo.c b/builtin/mailinfo.c
index 5823ae
The top-level mailinfo() would instead punt when the code in the
deeper part of the callchain detects an unrecoverable error in the
input.
Signed-off-by: Junio C Hamano
---
mailinfo.c | 30 ++
mailinfo.h | 1 +
2 files changed, 23 insertions(+), 8 deletions(-)
diff
Signed-off-by: Junio C Hamano
---
builtin/mailinfo.c | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/builtin/mailinfo.c b/builtin/mailinfo.c
index 810d132..b8b94d6 100644
--- a/builtin/mailinfo.c
+++ b/builtin/mailinfo.c
@@ -7,11 +7,11 @@
#i
This function has a single caller, and called with the global "line"
holding the multi-part boundary line the caller saw while processing
the e-mail body. The function then goes into a loop to process each
line of the input, and fills the same global "line" variable from
the input as it needs to r
Earlier we got rid of two function-scope static variables that kept
track of the states of helper functions by making them extra arguments
that are passed throughout the callchain. Now we have a convenient
place to store and pass them around in the form of "struct mailinfo",
change them into two f
We pre-increment the pointer that we will use to store something at,
so the pointer is already beyond the end of the array if it points
at content[MAX_BOUNDARIES].
Signed-off-by: Junio C Hamano
---
builtin/mailinfo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/mai
All callers of this function refrains from calling it when
mi->metainfo_charset is NULL; move the check to the callee,
as it already has a few conditions at its beginning to turn
it into a no-op.
Signed-off-by: Junio C Hamano
---
builtin/mailinfo.c | 8 +++-
1 file changed, 3 insertions(+),
This requires us to pass "struct mailinfo" to more functions
throughout the codepath that read input lines. Incidentally,
later steps are helped by this patch passing the struct to
more callchains.
Signed-off-by: Junio C Hamano
---
builtin/mailinfo.c | 54 ---
This requires us to pass the structure into check_header() codepath.
Signed-off-by: Junio C Hamano
---
builtin/mailinfo.c | 31 +--
1 file changed, 17 insertions(+), 14 deletions(-)
diff --git a/builtin/mailinfo.c b/builtin/mailinfo.c
index 8bd76c6..c0522f2 100644
--
There is a strange "if (!mi->cmitmsg) return 0" at the very beginning
of handle_commit_msg(), but the condition should never trigger, because:
* The only place cmitmsg is set to NULL is after this function sees
a patch break, closes the FILE * to write the commit log message
and returns 1.
This function wants to call find_boundary() and is called only from
one place without any recursing, so it becomes easier to read if it
appears after the called function.
Signed-off-by: Junio C Hamano
---
builtin/mailinfo.c | 114 ++---
1 file chan
Two helper functions use "static int" in their scope to keep track
of the state while repeatedly getting called once for each input
line. Move these state variables to their ultimate caller and pass
down pointers to them along the callchain, as a small step in
preparation for making this entire ca
This does not make a difference within the context of "git mailinfo"
that runs once and exits, as flushing and closing would happen upon
process termination. It however will matter when we eventually make
it callable as an API function.
Besides, cleaning after yourself once you are done is a good
This way, we can lose a forward decl for decode_header().
Signed-off-by: Junio C Hamano
---
builtin/mailinfo.c | 139 ++---
1 file changed, 69 insertions(+), 70 deletions(-)
diff --git a/builtin/mailinfo.c b/builtin/mailinfo.c
index 5a21d93..6fc6a
These two are the only easy ones that do not require passing the
structure around to deep corners of the callchain.
Signed-off-by: Junio C Hamano
---
builtin/mailinfo.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/builtin/mailinfo.c b/builtin/mailinfo.c
in
The called function checks if the second parameter is either a NULL
or an empty string at the very beginning and returns without doing
anything. Remove the useless call.
Signed-off-by: Junio C Hamano
---
builtin/mailinfo.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/builtin/mailinfo
During the discussion on the recent "git am" regression, I noticed
that the command reimplemented in C spawns one "mailsplit" and then
spawns "mailinfo" followed by "apply --index" to commit the changes
described in each message. As there are platforms where spawning
subprocess via run_command() i
69 matches
Mail list logo
