Hi!
I am trying to make an automated processing of "git status" results.
I execute the command
git status -z -uno
I expect that it has stable output format. However, it still can print
warnings like
warning: CRLF will be replaced by LF in somefile.xml
I understand that we can turn off core.saf
+cc Pat who maintains git-gui
On Thu, Jun 29, 2017 at 6:13 PM, Samuel Leslie wrote:
> Hi there,
>
> When selecting “Restore Defaults” in the Options dialogue via the Edit ->
> Options menu the following application error is received:
>
> window name "!paving" already exists in parent
> while
On Thu, 2017-06-29 at 11:17 -0700, Junio C Hamano wrote:
> The rationale of this has changed in this final version, hasn't it,
> especially with the removal of the "include/only warning" bit?
>
> We used to add a blank line to separate the "we are committing for
> somebody else", which is an optio
On Thu, 2017-06-29 at 10:56 -0700, Junio C Hamano wrote:
> When I said "I would have ... if I were doing this", I merely meant
> exactly that---as I weren't doing it, I left it up to you. But you
> did it the way anyways, which is very nice of you ;-).
>
It made a *lot* of sense, that's why. :)
Hi there,
When selecting “Restore Defaults” in the Options dialogue via the Edit ->
Options menu the following application error is received:
window name "!paving" already exists in parent
while executing
"ttk::frame $w.!paving"
(procedure "pave_toplevel" line 4)
invoked from within
When a submodule is on a branch and in its superproject you run a recursive
checkout, the branch of the submodule is updated to what the superproject
checks out. This is very unexpected. Instead detach the HEAD when updating
it.
Signed-off-by: Stefan Beller
---
submodule.c | 3 ++-
Add a new flags field to emit_diff_symbol, that will be used by
context lines for:
* white space rules that are applicable (The first 12 bits)
Take a note in cahe.c as well, when this ws rules are extended we have
to fix the bits in the flags field.
* how the rules are evaluated (actually this
Signed-off-by: Stefan Beller
Signed-off-by: Junio C Hamano
---
diff.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/diff.c b/diff.c
index 6e48a129ed..488096b757 100644
--- a/diff.c
+++ b/diff.c
@@ -561,6 +561,7 @@ static void emit_line(struct diff_optio
Introduce a new option 'emitted_symbols' in the struct diff_options which
controls whether all output is buffered up until all output is available.
It is set internally in diff.c when necessary.
We'll have a new struct 'emitted_string' in diff.c which will be used to
buffer each line. The emitted
Reroll of sb/diff-color-moved, applies on top of the hashmap patches[1].
* Supports different whitespace modes correctly now (and has a test for trivial
white space changes)
* The fixups[2] have been squashed.
Thanks,
Stefan
[1] https://public-inbox.org/git/20170629235336.28460-1-sbel...@googl
Signed-off-by: Stefan Beller
Signed-off-by: Junio C Hamano
---
diff.c | 42 ++
1 file changed, 26 insertions(+), 16 deletions(-)
diff --git a/diff.c b/diff.c
index e5430d56da..85bfd9310d 100644
--- a/diff.c
+++ b/diff.c
@@ -561,6 +561,8 @@ static void emi
Signed-off-by: Stefan Beller
---
Documentation/config.txt | 15 +--
Documentation/diff-options.txt | 34 ++
2 files changed, 47 insertions(+), 2 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 06898a7498..74382
Signed-off-by: Stefan Beller
Signed-off-by: Junio C Hamano
---
diff.c | 71 ++
1 file changed, 41 insertions(+), 30 deletions(-)
diff --git a/diff.c b/diff.c
index 5a9c55736d..2db0d7c0f5 100644
--- a/diff.c
+++ b/diff.c
@@ -572,6 +
When a patch consists mostly of moving blocks of code around, it can
be quite tedious to ensure that the blocks are moved verbatim, and not
undesirably modified in the move. To that end, color blocks that are
moved within the same patch differently. For example (OM, del, add,
and NM are different c
we could save a little bit of memory when buffering in a later mode
by just passing the inner part ("%s and %s", file1, file 2), but
those a just a few bytes, so instead let's reuse the implementation from
DIFF_SYMBOL_HEADER and keep the whole line around.
Signed-off-by: Stefan Beller
Signed-off-
We have to use fprintf instead of emit_line, because we want to emit the
tab after the color. This is important for ancient versions of gnu patch
AFAICT, although we probably do not want to feed colored output to the
patch utility, such that it would not matter if the trailing tab is
colored. Keep
We call print_stat_summary from builtin/apply, so we still
need the version with a file pointer, so introduce
print_stat_summary_0 that uses emit_string machinery and
keep print_stat_summary with the same arguments around.
Signed-off-by: Stefan Beller
Signed-off-by: Junio C Hamano
---
diff.c |
Signed-off-by: Stefan Beller
Signed-off-by: Junio C Hamano
---
diff.c | 63 ++-
1 file changed, 46 insertions(+), 17 deletions(-)
diff --git a/diff.c b/diff.c
index 48f719fb07..f5a14359ae 100644
--- a/diff.c
+++ b/diff.c
@@ -561,6 +561
The word diffing is not line oriented and would need some serious
effort to be transformed into a line oriented approach, so
just go with a symbol DIFF_SYMBOL_WORD_DIFF that is a partial line.
Signed-off-by: Stefan Beller
Signed-off-by: Junio C Hamano
---
diff.c | 79 +++
The context marker use the exact same output pattern, so reuse it.
Signed-off-by: Stefan Beller
Signed-off-by: Junio C Hamano
---
diff.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/diff.c b/diff.c
index 85bfd9310d..b2b2a19fcf 100644
--- a/diff.c
+++ b/diff.c
@@ -56
Add the 'plain' mode for move detection of code. This omits the checking
for adjacent blocks, so it is not as useful. If you have a lot of the
same blocks moved in the same patch, the 'Zebra' would end up slow as it
is O(n^2) (n is number of same blocks). So this may be useful there and
is generall
Signed-off-by: Stefan Beller
Signed-off-by: Junio C Hamano
---
diff.c | 35 +--
1 file changed, 21 insertions(+), 14 deletions(-)
diff --git a/diff.c b/diff.c
index 1d0f8b509f..5c428e02b6 100644
--- a/diff.c
+++ b/diff.c
@@ -561,6 +561,7 @@ static void emit_line(
As the submodule process is no longer attached to the same file pointer
'o->file' as the superprojects process, there is a different result in
color.c::check_auto_color. That is why we need to pass coloring explicitly,
such that the submodule coloring decision will be made by the child process
proc
Any lines inside a moved block of code are not interesting. Boundaries
of blocks are only interesting if they are next to another block of moved
code.
Signed-off-by: Stefan Beller
Signed-off-by: Junio C Hamano
---
color.h| 2 +
diff.c | 132
Signed-off-by: Stefan Beller
Signed-off-by: Junio C Hamano
---
diff.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/diff.c b/diff.c
index e0d39d04da..5a9c55736d 100644
--- a/diff.c
+++ b/diff.c
@@ -571,6 +571,7 @@ enum diff_symbol {
DIFF_SYMBOL_STATS_SUMM
In a later patch we want to buffer all output before emitting it as a
new feature ("markup moved lines") conceptually cannot be implemented
in a single pass over the output.
There are different approaches to buffer all output such as:
* Buffering on the char level, i.e. we'd have a char[] which wo
We already have dereferenced 'p->two' into a local variable 'two'.
Use that.
Signed-off-by: Stefan Beller
Signed-off-by: Junio C Hamano
---
diff.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/diff.c b/diff.c
index 00b4c86698..2874dfc6fc 100644
--- a/diff.c
+++ b/diff.
In a later patch we want to do more things before and after all filepairs
are flushed. So factor flushing out all file pairs into its own function
that the new code can be plugged in easily.
Signed-off-by: Stefan Beller
Signed-off-by: Junio C Hamano
---
diff.c | 17 -
1 file cha
The emit_hunk_header() function is responsible for assembling a
hunk header and calling emit_line() to send the hunk header
to the output file. Its only caller fn_out_consume() needs
to prepare for a case where the function emits an incomplete
line and add the terminating LF.
Instead make sure em
Signed-off-by: Stefan Beller
Signed-off-by: Junio C Hamano
---
diff.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/diff.c b/diff.c
index 75b996c4cf..6e48a129ed 100644
--- a/diff.c
+++ b/diff.c
@@ -561,6 +561,7 @@ static void emit_line(struct diff_options *o, const
The header is constructed lazily including line breaks, so just emit
the raw string as is.
Signed-off-by: Stefan Beller
Signed-off-by: Junio C Hamano
---
diff.c | 28
1 file changed, 20 insertions(+), 8 deletions(-)
diff --git a/diff.c b/diff.c
index 49b45fef29..78
Signed-off-by: Stefan Beller
Signed-off-by: Junio C Hamano
---
diff.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/diff.c b/diff.c
index 4637368d59..75b996c4cf 100644
--- a/diff.c
+++ b/diff.c
@@ -561,13 +561,20 @@ static void emit_line(struct diff_options *o, co
When using the hashmap a common need is to have access to arbitrary data
in the compare function. A couple of times we abuse the keydata field
to pass in the data needed. This happens for example in patch-ids.c.
This patch changes the function signature of the compare function
to have one more voi
v2:
addressed all but the last point of Jonathan Nieder.
Thanks,
Stefan
v1:
https://public-inbox.org/git/xmqqpodnvmmw@gitster.mtv.corp.google.com/
for context why we need a new data field. Implement that.
Once upon a time we had a long discussion where to put documentation best.
The answe
While at it, clarify the use of `key`, `keydata`, `entry_or_key` as well
as documenting the new data pointer for the compare function.
Signed-off-by: Stefan Beller
---
Documentation/technical/api-hashmap.txt | 309
hashmap.h | 351 ++
On Thu, Jun 29, 2017 at 2:01 PM, Stefan Beller wrote:
> On Tue, Jun 27, 2017 at 10:06 PM, Junio C Hamano wrote:
>> Junio C Hamano writes:
>> This probably deserves a bit more illustration of how I envision the
>> code should evolve.
>> ...
> It turns out that the code here is rather a very loose
Took all suggestions so far, but the last one:
>
> Probably worth mentioning this is a convenience wrapper for iter_init
> + iter_next, like the Documentation/technical/ text did.
No. The code to observe that this is a convenience wrapper
IS RIGHT THERE (it's a header file), and I find this heade
İyi Günler
Tamamlanmış işler için rapor ve faturanız ekte gönderilmiştir. Lütfen ödemenizi
geciktirmeyiniz.
En iyi dileklerimizle
Murat Başaran, HAVELSAN A.Ş.
TEL : 0312 219 57 97 (35 hat Pbx)
FAKS : 0312 219 57 87
pdf_fatura.rar
Description: Binary data
The option -G of p4 (python marshal output) gives more context about the
data being output. That's useful when using the command "change -o" as
we can distinguish between warning/error line and real change description.
Some p4 triggers in the server side generate some warnings when
executed. Unfor
On Thu, Jun 29, 2017 at 8:59 AM, Luke Diamand wrote:
> On 28 June 2017 at 14:14, miguel torroja wrote:
>> Thanks Luke,
>>
>> regarding the error in t9800 (not ok 18 - unresolvable host in P4PORT
>> should display error), for me it's very weird too as it doesn't seem
>> to be related to this parti
Refactor calls to the grep machinery to always pass opt.ignore_case &
opt.extended_regexp_option instead of setting the equivalent regflags
bits.
The bug fixed when making -i work with -P in commit 9e3cbc59d5 ("log:
make --regexp-ignore-case work with --perl-regexp", 2017-05-20) was
really just pl
Remove the redundant REG_NEWLINE regcomp() flag from the code that
compiles a fixed-string regular-expression.
The REG_NEWLINE causes metacharacters such as "." to match a newline,
since the basic_regex_quote_buf() function being called here escapes
all metacharacters using REG_NEWLINE is confusin
Remove the redundant re-assignments of the fixed/pcre1/pcre2 fields to
zero right after the entire struct has been set to zero via
memset(...).
See an earlier related cleanup commit e0b9f8ae09 ("grep: remove
redundant regflags assignments", 2017-05-25) for an explanation of why
the code was struct
Adjust a now-redundant assignment to extended_regexp_option to make it
zero if grep.extendedRegexp is not set. This is always called right
after init_grep_defaults() which memsets the entire structure to 0, so
there's no need to set it again to zero.
However the reason for the if/else pattern is a
Stop assigning 0 to the extended_regexp_option field right after we've
zeroed out the entire struct with memset() just a few lines earlier.
Unlike some of the code being refactored in subsequent commits, this
was always completely redundant. See the original code introduced in
84befcd0a4 ("grep: a
Addresses comments from Stefan Beller (thanks!). I looked into it and
the REG_NEWLINE flag was redundant in 1/2 cases, see 6/6 for the
removal of that.
I looked into refactoring 5/6 as noted in 87zicqirrg@gmail.com,
but for the reasons now explained in the last paragraph of 5/6 decided
not to
Remove the redundant re-assignment of the fixed field to zero right
after the entire struct has been set to zero via memset(...).
Unlike some nearby commits this pattern doesn't date back to the
pattern described in e0b9f8ae09 ("grep: remove redundant regflags
assignments", 2017-05-25), instead it
Instead of implementing this on our own, just use a convenience macro.
Signed-off-by: Stefan Beller
---
merge-recursive.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index 59e5ee41a8..1494ffdb82 100644
--- a/merge-recursive.c
++
Stefan Beller wrote:
> Subject: hashmap: migrate documentation from Documentation/technical into
> header
>
> While at it, clarify the use of `key`, `keydata`, `entry_or_key` as well
> as documenting the new data pointer for the compare function.
>
> Signed-off-by: Stefan Beller
> ---
> Documen
On Tue, Jun 27, 2017 at 10:06 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Looking at the implementation of get_ws_cleaned_string() that is the
>> workhorse of emitted_symbol_cmp_no_ws(), it seems to be doing wrong
>> things for various "ignore whitespace" options (i.e. there is only
>
Hi,
On Wed, 28 Jun 2017, Johannes Schindelin wrote:
> On Mon, 26 Jun 2017, Gyandeep Singh wrote:
>
> [... a bug report ...]
This bug report was reposted as
https://github.com/git-for-windows/git/issues/1219
In my opinion, it is too Windows-specific for the discussion to continue
anywh
> We could discern between more than just empty vs. non-empty state of
> the environment variable, e.g.:
>
> - if empty/unset, then include "DWIM" suggestions.
> - if set to 'config', then query the 'completion.checkoutNoGuess'
>configuration variable, and omit "DWIM" suggestions if its true.
Hi,
Jonathan Tan wrote:
> Suppose you have missing blob AB12 and CD34 that you now need, so
> fetch-blob is invoked. It sends the literals AB12 and CD34 to a new
> server endpoint and obtains a packfile, which it then pipes through "git
> index-pack". The issue is that "git index-pack" wants to t
On Thu, Jun 29, 2017 at 11:44 AM, Junio C Hamano wrote:
> Laurent Humblet writes:
>
>> Would it be possible to add an optional Yes/No when doing a 'git stash
>> drop'? Something similar as what happens when pushing on a remotely
>> checked out branch (with a config setting to turn the warning on
As some of you may know, I'm currently working on support for partial
clones/fetches in Git (where blobs above a user-specified size threshold
are not downloaded - only their names and sizes are downloaded). To do
this, the client repository needs to be able to download blobs at will
whenever it ne
> On 29 Jun 2017, at 20:34, Junio C Hamano wrote:
>
> You seem to have squashed an unrelated "table-driven" clean-up into
> this step. While I think the end result looks good, I would have
> liked to see it as a separate step, either as a preparatory "now we
> are going to add the third one, le
Laurent Humblet writes:
> Would it be possible to add an optional Yes/No when doing a 'git stash
> drop'? Something similar as what happens when pushing on a remotely
> checked out branch (with a config setting to turn the warning on/off).
>
> I know that you can always get your dropped stash ba
You seem to have squashed an unrelated "table-driven" clean-up into
this step. While I think the end result looks good, I would have
liked to see it as a separate step, either as a preparatory "now we
are going to add the third one, let's make it table-driven before
doing so" step, or a follow-up
On Thu, Jun 29, 2017 at 11:11 AM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> I haven't looked at the use of keydata in patch-ids.c and friends to
>> decide if that "abuse" claim is correct; if it were the case, should
>> we expect that a follow-up patch to clean up the existing mess by
>
Kaartic Sivaraam writes:
> The commit template adds the optional parts without
> a new line to distinguish them. This results in
> difficulty in interpreting it's content, specifically
> for inexperienced users.
>
> Add new lines to separate the distinct parts of the
> template.
The rationale of
On Thu, Jun 29 2017, Stefan Beller jotted:
> On Wed, Jun 28, 2017 at 2:58 PM, Ævar Arnfjörð Bjarmason
> wrote:
>> Refactor calls to the grep machinery to always pass opt.ignore_case &
>> opt.extended_regexp_option instead of setting the equivalent regflags
>> bits.
>>
>> The bug fixed when makin
Junio C Hamano writes:
> I haven't looked at the use of keydata in patch-ids.c and friends to
> decide if that "abuse" claim is correct; if it were the case, should
> we expect that a follow-up patch to clean up the existing mess by
> using the new mechanism? Or does fixing the "abuse" take anot
Stefan Beller writes:
> When using the hashmap a common need is to have access to arbitrary data
> in the compare function. A couple of times we abuse the keydata field
> to pass in the data needed. This happens for example in patch-ids.c.
It is not "arbitrary data"; it is very important to stre
Kaartic Sivaraam writes:
> The notice that "git commit " default to "git commit
> --only " was there since 756e3ee0 ("Merge branch
> 'jc/commit'", 2006-02-14). Back then, existing users of Git
> expected the command doing "git commit --include ", and
> after we changed the behaviour of the comma
Kaartic Sivaraam writes:
> The commit template adds the optional parts without
> a new line to distinguish them. This results in
> difficulty in interpreting it's content, specifically
> for inexperienced users.
>
> Add new lines to separate the distinct parts of the
> template.
> ---
> I tried
On Thu, Jun 29 2017, Stefan Beller jotted:
> On Wed, Jun 28, 2017 at 2:58 PM, Ævar Arnfjörð Bjarmason
> wrote:
>> Remove a redundant assignment to extended_regexp_option to make it
>> zero if grep.extendedRegexp is not set. This is always called right
>> after init_grep_defaults() which memsets
On Wed, Jun 28, 2017 at 2:58 PM, Ævar Arnfjörð Bjarmason
wrote:
> Refactor calls to the grep machinery to always pass opt.ignore_case &
> opt.extended_regexp_option instead of setting the equivalent regflags
> bits.
>
> The bug fixed when making -i work with -P in commit 9e3cbc59d5 ("log:
> make -
On Wed, Jun 28, 2017 at 2:58 PM, Ævar Arnfjörð Bjarmason
wrote:
> Remove the redundant re-assignment of the fixed field to zero right
> after the entire struct has been set to zero via memset(...).
>
> Unlike some nearby commits this pattern doesn't date back to the
> pattern described in e0b9f8ae
On Wed, Jun 28, 2017 at 2:58 PM, Ævar Arnfjörð Bjarmason
wrote:
> Remove a redundant assignment to extended_regexp_option to make it
> zero if grep.extendedRegexp is not set. This is always called right
> after init_grep_defaults() which memsets the entire structure to 0.
>
> This is a logical fol
The commit template adds the optional parts without
a new line to distinguish them. This results in
difficulty in interpreting it's content, specifically
for inexperienced users.
Add new lines to separate the distinct parts of the
template.
---
I tried writing tests to ensure that the new line is
The notice that "git commit " default to "git commit
--only " was there since 756e3ee0 ("Merge branch
'jc/commit'", 2006-02-14). Back then, existing users of Git
expected the command doing "git commit --include ", and
after we changed the behaviour of the command to align with
other people's "$scm
On 6/28/2017 9:13 PM, Stefan Beller wrote:
While at it, clarify the use of `key`, `keydata`, `entry_or_key` as well
as documenting the new data pointer for the compare function.
Signed-off-by: Stefan Beller
---
Documentation/technical/api-hashmap.txt | 309
>> This series of patches is based on the 'next' branch.
>
> The reason not to base on 'master' is...?
>
The reason it wasn't based on 'master' was that it depended on the commit:
dir: create function count_slashes(),
which was merged to 'next' a few days back.
> The thing is that a topic built o
Hi all,
Would it be possible to add an optional Yes/No when doing a 'git stash
drop'? Something similar as what happens when pushing on a remotely
checked out branch (with a config setting to turn the warning on/off).
I know that you can always get your dropped stash back using git
reflog but a
Apply for a loan at 3% reply to this Email for more Info
HELP ME PLEASE
My name is Miss Victoria Jenny looking for a trustworthy, sincere and
honest someone like you who can help me in this time of needs.
My father is Rufus Okana, during the civil and political crisis in our
country, my parents together with my three sisters was poisoned by
heartless e
76 matches
Mail list logo