On Wed, Jun 17, 2015 at 3:41 PM, Junio C Hamano wrote:
> Michael Rappazzo writes:
>
>> For some mergetools, the current invocation of git mergetool will
>> include an auto-merge flag. By default the flag is included, however if
>> the git config option 'merge.automerge' is set to 'false', then t
Duy Nguyen writes:
>>> How about this:
>>>
>>> git-checkout - Switch branches or restore changes to the working tree
>>
>> Gahh. We are NOT restoring CHANGES. We are restoring the whole
>> contents to a path.
>
> "the whole contents" is only true when --patch is not used, I think.
I've seen th
On Thu, Jun 18, 2015 at 2:58 AM, Junio C Hamano wrote:
> Torsten Bögershausen writes:
>
>> On 2015-06-17 21.23, Junio C Hamano wrote:
>> []
Basically, I'm fine with anything starting with "Switch branches or",
but please do change the headline ;-).
>>>
>>> Likewise; I agree "switch bran
When a repository is first fetched as a shallow clone, either by
git-clone or by fetching into an empty repo, the server's capabilities
are not currently consulted. The client will send shallow requests even
if the server does not understand them, and the resulting error may be
unhelpful to the use
> Junio C Hamano writes
> Suffix "rgx" that means "regular expression" is a bit unusual, and
> also hard to read when squashed to another word. Elsewhere in the
> same script, we seem to use $re_whatever to store precompiled
> regular expressions, so perhaps $re_comment, $re_quote, etc.?
Yes it'
Matthieu Moy writes
> > + my $commentrgx=qr/\((?:[^)]*)\)/;
> > + my $quotergx=qr/"(?:[^\"\\]|\\.)*"/;
> > + my $wordrgx=qr/(?:[^]["\s()<>:;@\\,.]|\\.)+/;
>
> Spaces around = please.
> ...
> > + foreach my $token (@tokens) {
> > + if ($token =~ /^[,;]$/) {
>
> Here and below: you'
On Wed, Jun 17, 2015 at 06:52:24PM -0400, Theodore Ts'o wrote:
> On Wed, Jun 17, 2015 at 10:26:32PM +0200, Tuncer Ayaz wrote:
> >
> > By allowing multiple authors, you don't have to decide who's the
> > primary author, as in such situations usually there is no primary at
> > all. I sometimes delib
Reproduce like this (using git 2.4.3):
git init
mkdir foo
touch foo/bar
git add .
git commit -m "Initial commit."
ln -s foo link
git add .
git commit -m "Add link to foo."
git difftool -d HEAD^ HEAD
That last command outputs:
fatal: Unable to hash /Users/isbadawi/test/link
hash-object /Users/isb
On Wed, Jun 17, 2015 at 10:26:32PM +0200, Tuncer Ayaz wrote:
>
> By allowing multiple authors, you don't have to decide who's the
> primary author, as in such situations usually there is no primary at
> all. I sometimes deliberately override the author when committing and
> add myself just as anot
j...@joshtriplett.org writes:
> Author and committer are used by many git tools; if they weren't part of
> the object header, they'd need to be part of some pseudo-header with a
> standardized format that git can parse.
Yes, the same goes to the address on Signed-off-by: footers. There
recently
On Wed, Jun 17, 2015 at 02:51:18PM -0700, Junio C Hamano wrote:
> j...@joshtriplett.org writes:
>
> > Having more than one author field in a commit would likely break things,
> > but having a coauthor field seems plausible these days. Git added
> > support for signed commits, and the world didn't
On Wed, Jun 17, 2015 at 03:23:49PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > On Wed, Jun 17, 2015 at 05:11:21PM -0400, Richard Hansen wrote:
> >
> >> + test -z "$1" && test -n "$quiet" && return
> >> + eval "say_color_color=\$say_color_$1"
> >
> > Thanks, this look
Jeff King writes:
> On Wed, Jun 17, 2015 at 05:11:21PM -0400, Richard Hansen wrote:
>
>> +test -z "$1" && test -n "$quiet" && return
>> +eval "say_color_color=\$say_color_$1"
>
> Thanks, this looks much simpler.
>
> In the non-quiet case, you will eval $say_color_, even th
On Wed, Jun 17, 2015 at 05:11:21PM -0400, Richard Hansen wrote:
> + test -z "$1" && test -n "$quiet" && return
> + eval "say_color_color=\$say_color_$1"
Thanks, this looks much simpler.
In the non-quiet case, you will eval $say_color_, even though we know it
to be bogus.
On Wed, Jun 17, 2015 at 11:51 PM, Junio C Hamano wrote:
> j...@joshtriplett.org writes:
>
> > Having more than one author field in a commit would likely break
> > things, but having a coauthor field seems plausible these days.
> > Git added support for signed commits, and the world didn't end, so
>
j...@joshtriplett.org writes:
> Having more than one author field in a commit would likely break things,
> but having a coauthor field seems plausible these days. Git added
> support for signed commits, and the world didn't end, so it's possible
> to extend the commit format.
Something being pos
On Tue, Jun 16, 2015 at 11:32 PM, Jeff King wrote:
> On Tue, Jun 16, 2015 at 06:21:56PM -0500, Tad Hardesty wrote:
>> ~/test (master #)$ git status -z | hexdump -C
>> 41 20 20 61 41 20 20 62 |A aA b|
>> 0008
>
> That's really weird. I don't have a Yosemite
Remi Lespinet writes:
> parse_address_line had not the same behavior whether the user had
> Mail::Address or not. Teach parse_address_line to behave like
> Mail::Address.
Sounds like a fun project ;-)
> + my $commentrgx=qr/\((?:[^)]*)\)/;
> + my $quotergx=qr/"(?:[^\"\\]|\\.)*"/;
> +
Changes from v1:
* Eliminate the case statement and assume the user passed a sane
value for $1.
* Use the same test as the non-colorized version of say_color() when
determining whether to suppress the output: assume that a message
can only be suppresed if $1 is the empty string. T
If tput needs ~/.terminfo for the current $TERM, then tput will
succeed before HOME is changed to $TRASH_DIRECTORY (causing color to
be set to 't') but fail afterward.
One possible way to fix this is to treat HOME like TERM: back up the
original value and temporarily restore it before say_color()
This reverts commit 102fc80d32094ad6598b17ab9d607516ee8edc4a.
There are two issues with that commit:
* It is buggy. In pseudocode, it is doing:
color is set || TERM != dumb && color works && color=t
when it should be doing:
color is set || { TERM != dumb && color works &&
On Wed, Jun 17, 2015 at 01:57:12PM -0700, Junio C Hamano wrote:
> Tuncer Ayaz writes:
>
> > On Wed, Jun 17, 2015 at 9:58 PM, Junio C Hamano wrote:
> >> Tuncer Ayaz writes:
> >>
> >> > Is this something that breaks the design and would never be
> >> > implemented,
> >>
> >> Yes.
> >
> > Junio, th
On Wed, Jun 17, 2015 at 10:26:32PM +0200, Tuncer Ayaz wrote:
> On Wed, Jun 17, 2015 at 9:58 PM, Junio C Hamano wrote:
> > Tuncer Ayaz writes:
> >
> > > Is this something that breaks the design and would never be
> > > implemented,
> >
> > Yes.
>
> Junio, thanks for the quick response.
>
> I supp
Tuncer Ayaz writes:
> On Wed, Jun 17, 2015 at 9:58 PM, Junio C Hamano wrote:
>> Tuncer Ayaz writes:
>>
>> > Is this something that breaks the design and would never be
>> > implemented,
>>
>> Yes.
>
> Junio, thanks for the quick response.
>
> I suppose things have changed since Jonathan Nieder's
Karsten Blees writes:
>> I do not think the removal of the text makes much sense here unless
>> you add the equivalent to the new text below.
>>
>>> - The contents of the blob objects are uninterpreted sequences
>>> of bytes. There is no encoding translation at the core
>>> level.
>>>
On Wed, Jun 17, 2015 at 9:58 PM, Junio C Hamano wrote:
> Tuncer Ayaz writes:
>
> > Is this something that breaks the design and would never be
> > implemented,
>
> Yes.
Junio, thanks for the quick response.
I suppose things have changed since Jonathan Nieder's response in [1]
(2010), or I've rea
On Wed, Jun 17, 2015 at 03:55:05PM -0400, Richard Hansen wrote:
> > I do not mind it so much as you have
> > it, but it does mean adding a new field needs to update two spots.
>
> I also don't like the duplicate list of color types, and I considered
> doing something similar to what you suggested
Richard Hansen writes:
> We could test if the variable is set first (test -n "${foo+set}"), at
> the cost of a bit more complexity.
>
>> I do not mind it so much as you have
>> it, but it does mean adding a new field needs to update two spots.
>
> I also don't like the duplicate list of color typ
On Wed, Jun 17, 2015 at 12:25 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>>> Just make strbuf_slopbuf[] large enough to keep Coverity happy. If it's
>>> happy, we'll have cleaner defect list
>>
>> It's down 31 defects, roughly 10% of all things coverity detected as
>> problematic.
>> YAY
On Wed, Jun 17, 2015 at 12:12 PM, Jeff King wrote:
> On Wed, Jun 17, 2015 at 10:58:10AM -0700, Stefan Beller wrote:
>
>> > Just make strbuf_slopbuf[] large enough to keep Coverity happy. If it's
>> > happy, we'll have cleaner defect list
>>
>> It's down 31 defects, roughly 10% of all things coveri
Jeff King writes:
> I would vote for a documentation change, perhaps like:
>
> Subject: docs: clarify that --encoding can produce invalid sequences
>
> In the common case that the commit encoding matches the
> output encoding, we do not touch the buffer at all, which
> makes things much more effi
Tuncer Ayaz writes:
> Is this something that breaks the design and would never be implemented,
Yes.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Torsten Bögershausen writes:
> On 2015-06-17 21.23, Junio C Hamano wrote:
> []
>>> Basically, I'm fine with anything starting with "Switch branches or",
>>> but please do change the headline ;-).
>>
>> Likewise; I agree "switch branches or" part is good.
>
> How about this:
>
> git-checkout - Sw
> * just make this more clear in the docs and/or
> * should we adjust the behavior of --encoding or
> * should we do something entirely different, like adding a new command line
> option or
The general spirit is to keep things backwards compatible, so that users which
expect the "raw" (and possible
On 2015-06-17 15:43, Jeff King wrote:
> On Wed, Jun 17, 2015 at 03:06:26PM -0400, Richard Hansen wrote:
>> +say_color_error=$(tput bold; tput setaf 1) # bold red
>> +say_color_skip=$(tput setaf 4) # blue
>> +say_color_warn=$(tput setaf 3) # brown/yellow
>> +say_color_pass=$(tput set
Even though I don't have time to work on a feature like this, like
others before me, I've been in situations where I would have liked to
set more than one GIT_AUTHOR_NAME (etc.) for a single commit due to
the involvement of multiple developers in authoring a change.
Is this something that breaks t
On Wed, Jun 17, 2015 at 2:08 PM, Matthieu Moy
wrote:
> Karthik Nayak writes:
>> --- a/ref-filter.c
>> +++ b/ref-filter.c
>> @@ -901,12 +903,19 @@ static int ref_filter_handler(const char *refname,
>> const struct object_id *oid,
>> if (!match_points_at(&filter->points_at, oid->hash, refnam
On Wed, Jun 17, 2015 at 03:06:26PM -0400, Richard Hansen wrote:
> If tput needs ~/.terminfo for the current $TERM, then tput will
> succeed before HOME is changed to $TRASH_DIRECTORY (causing color to
> be set to 't') but fail afterward.
>
> One possible way to fix this is to treat HOME like TERM
Michael Rappazzo writes:
> For some mergetools, the current invocation of git mergetool will
> include an auto-merge flag. By default the flag is included, however if
> the git config option 'merge.automerge' is set to 'false', then that
> flag will now be omitted.
... and why is the "automerge
On 17/06/2015 20:24, Jeff King wrote:
On Wed, Jun 17, 2015 at 08:16:10PM +0100, KK wrote:
remote: error: invalid key: hooks.denypush.branch.versions/4.3.2
remote: error: invalid key: hooks.allowmerge.versions/4.3.2
[...]
Those are syntactically bogus config keys. Keys should be of the form
On 2015-06-17 21.23, Junio C Hamano wrote:
[]
>> Basically, I'm fine with anything starting with "Switch branches or",
>> but please do change the headline ;-).
>
> Likewise; I agree "switch branches or" part is good.
How about this:
git-checkout - Switch branches or restore changes to the worki
If tput needs ~/.terminfo for the current $TERM, then tput will
succeed before HOME is changed to $TRASH_DIRECTORY (causing color to
be set to 't') but fail afterward.
One possible way to fix this is to treat HOME like TERM: back up the
original value and temporarily restore it before say_color()
This reverts commit 102fc80d32094ad6598b17ab9d607516ee8edc4a.
There are two issues with that commit:
* It is buggy. In pseudocode, it is doing:
color is set || TERM != dumb && color works && color=t
when it should be doing:
color is set || { TERM != dumb && color works &&
Stefan Beller writes:
>> Just make strbuf_slopbuf[] large enough to keep Coverity happy. If it's
>> happy, we'll have cleaner defect list
>
> It's down 31 defects, roughly 10% of all things coverity detected as
> problematic.
> YAY!
I actually think this is too ugly to live. If coverity is bugg
Commit 102fc80d fixed a bug where tput was failing because it needed
to read ~/.terminfo after HOME was changed. However, that commit is
buggy, and it unnecessarily disables color support when tput needs to
read from ~/.terminfo.
This series does two things:
* revert the buggy fix
* fix it p
On Wed, Jun 17, 2015 at 08:16:10PM +0100, KK wrote:
> remote: error: invalid key: hooks.denypush.branch.versions/4.3.2
> remote: error: invalid key: hooks.allowmerge.versions/4.3.2
> [...]
Those are syntactically bogus config keys. Keys should be of the form
section.subsection.key
and only "s
"Andres G. Aragoneses" writes:
> Comments?
No.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Matthieu Moy writes:
> Torsten Bögershausen writes:
>
>> My v3 will probably use the original line:
>> git-checkout - Checkout a branch or paths to the working tree
>
> I think mentionning "Switch branch" was a real improvement. For someone
> not familiar with the version control vocabulary, "ch
On Wed, Jun 17, 2015 at 09:07:36AM -0500, Tad Hardesty wrote:
> Everything looks normal using the commands you described, and it does appear
> to only affect status:
>
> ~/test (master)$ type git
> git is hashed (/usr/local/bin/git)
> ~/test (master)$ git config --list
> core.repositoryformatver
Hi,
After upgrade GIT from 1.7.2.5-3.1 to 1.7.10.4-1+wheezy1 following error
appear:
git push central versions/4.3.2
Counting objects: 45, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (28/28), done.
Writing objects: 100% (28/28), 13.01 KiB, done.
Total 28 (delta 22)
On Wed, Jun 17, 2015 at 1:57 PM, Matthieu Moy
wrote:
> Err, for-each-ref already uses it before this series, no?
>
> So, you don't need any extra option to get for-each-ref, because it is
> already there. Having these extra options is a good side effect, though.
>
> To make sure I'm clear enough,
On Wed, Jun 17, 2015 at 10:58:10AM -0700, Stefan Beller wrote:
> > Just make strbuf_slopbuf[] large enough to keep Coverity happy. If it's
> > happy, we'll have cleaner defect list
>
> It's down 31 defects, roughly 10% of all things coverity detected as
> problematic.
> YAY!
That's a good thing.
On Wed, Jun 17, 2015 at 05:04:04PM +0700, Duy Nguyen wrote:
> I wonder if we could do it a bit differently. Instead of
> GIT_TRACE_STDIN, I would add GIT_TRACE_HOOK that points to a script.
> Whenever a command is run via run-command interface, the actual
> command line to be executed would be "
Coverity noticed that we strncpy() into a fixed-size buffer
without making sure that it actually ended up
NUL-terminated. This is unlikely to be a bug in practice,
since throughput strings rarely hit 32 characters, but it
would be nice to clean it up.
The most obvious way to do so is to add a NUL-
On Wed, Jun 17, 2015 at 07:07:48PM +0200, Jan-Philip Gehrcke wrote:
> The two-option scenario is totally clear. Although one must stress that the
> "error-out" option can, as discussed, be kept minimally invasive: it is
> sufficient (and common) to just skip those byte sequences (and replace them
> Just make strbuf_slopbuf[] large enough to keep Coverity happy. If it's
> happy, we'll have cleaner defect list
It's down 31 defects, roughly 10% of all things coverity detected as
problematic.
YAY!
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to maj
On 17/06/15 19:24, Matthieu Moy wrote:
Torsten Bögershausen writes:
My v3 will probably use the original line:
git-checkout - Checkout a branch or paths to the working tree
I think mentionning "Switch branch" was a real improvement. For someone
not familiar with the version control vocabular
Johannes Schindelin writes:
> +test_expect_failure 'rebase --continue removes CHERRY_PICK_HEAD' '
> + git checkout -b commit-to-skip &&
> + for double in X 3 1
> + do
> + seq 5 | sed "s/$double/&&/" >seq &&
> + git add seq &&
> + test_tick &&
> +
On Wed, Jun 17, 2015 at 3:16 AM, Nguyễn Thái Ngọc Duy wrote:
> It usually goes like this
>
> strbuf sb = STRBUF_INIT;
> if (!strncmp(sb.buf, "foo", 3))
>printf("%s", sb.buf + 3);
>
> Coverity thinks that printf() can be executed, and because initial
> sb.buf only has one character
Torsten Bögershausen writes:
> My v3 will probably use the original line:
> git-checkout - Checkout a branch or paths to the working tree
I think mentionning "Switch branch" was a real improvement. For someone
not familiar with the version control vocabulary, "checkout" does not
mean much (just
On Wed, Jun 17, 2015 at 5:18 PM, Junio C Hamano wrote:
> Mike Hommey writes:
> > I'm tempted to make init_notes itself do the check, based on the value
> > it is given for a "read_only" argument.
>
> Yeah, that would be one sensible way to go after making sure that
> everything goes thru this int
On 17.06.2015 18:42, Junio C Hamano wrote:
Jan-Philip Gehrcke writes:
I was surprised to see that the output of
git log --encoding=utf-8 "--format=format:%b"
can contain byte sequences that are invalid in UTF-8. Note: I am using
git 2.1.4 and the %b format specifier represents the commi
On Wed, Jun 17, 2015 at 07:48:14AM -0400, Mike Edgar wrote:
> When a repository is first fetched as a shallow clone, either by
> git-clone or by fetching into an empty repo, the server's capabilities
> are not currently consulted. The client will send shallow requests even
> if the server does not
On Wed, Jun 17, 2015 at 09:35:23AM -0700, Junio C Hamano wrote:
> > Of course it's hard to add to the test suite, since we do not have a way
> > of hitting a server that does not understand shallow (I simply fudged
> > server_supports() to return false on the client).
>
> We've had the "shallow"
Johannes Schindelin writes:
> The symptom is that .git/CHERRY_PICK_HEAD is left behind after
> skipping an already-merged patch with `git rebase --continue`
> instead of `git rebase --skip`. I always prefer the former
> invocation because the latter would also skip legitimate patches
> if there w
On 2015-06-17 18.19, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Matthieu Moy writes:
>>
>>> Yes, but "Switch branchs or discard local changes" still does not
>>> describe "git checkout HEAD^^^ -- file.txt" (restore to an old state,
>>> but does not switch branch) or "git checkout -- fil
Jan-Philip Gehrcke writes:
> I was surprised to see that the output of
>
> git log --encoding=utf-8 "--format=format:%b"
>
> can contain byte sequences that are invalid in UTF-8. Note: I am using
> git 2.1.4 and the %b format specifier represents the commit message
> body.
Yeah, if the origi
Jeff King writes:
> On Thu, Jun 11, 2015 at 08:02:33PM +0700, Duy Nguyen wrote:
>
>> > I see that do_fetch_pack checks server_supports("shallow"). Is that
>> > enough to cover all fetch cases? And if it is, why does it not cover the
>> > matching clone cases?
>>
>> I think this replacement check
On Wed, Jun 17, 2015 at 06:02:46PM +0900, Mike Hommey wrote:
> > In a sense that is weirdly broken already:
> >
> > $ git log --notes=:/foo >/dev/null
> > warning: notes ref refs/notes/:/foo is invalid
> >
> > but I wonder if we should be making expand_notes_ref a little more
> > careful as
Remi Galan Alfonso
writes:
> Junio C Hamano writes:
>> * gr/rebase-i-drop-warn (2015-06-01) 2 commits
>> - git rebase -i: warn about removed commits
>> - git-rebase -i: add command "drop" to remove a commit
>>
>> Add "drop commit-object-name subject" command as another way to
>> skip replaying o
Junio C Hamano writes:
> Matthieu Moy writes:
>
>> Yes, but "Switch branchs or discard local changes" still does not
>> describe "git checkout HEAD^^^ -- file.txt" (restore to an old state,
>> but does not switch branch) or "git checkout -- file.txt" (get from the
>> index).
>
> You are right, e
On 2015-06-17 17.29, Junio C Hamano wrote:
> Matthieu Moy writes:
>
>> Yes, but "Switch branchs or discard local changes" still does not
>> describe "git checkout HEAD^^^ -- file.txt" (restore to an old state,
>> but does not switch branch) or "git checkout -- file.txt" (get from the
>> index).
>
I do the following:
$ git push origin :topic
If I stop halfway through typing 'topic' and hit TAB, auto-completion
does not work if I do not have a local branch by that name (sometimes
I delete my local branch first, then I push to delete it remotely). I
thought that git completion code was suppo
Remi Lespinet writes:
> Aliases were expanded before checking the From field of the
"checking" is misleading here. I thought you meant "check that the From
field is well-formed", while you mean "set $sender based on the From:
field".
> --compose option. This is inconsistent with other fields
>
Remi Lespinet writes:
> ---
> git-send-email.perl | 54
> +++--
> 1 file changed, 52 insertions(+), 2 deletions(-)
>
> diff --git a/git-send-email.perl b/git-send-email.perl
> index a0cd7ff..a1f6c18 100755
> --- a/git-send-email.perl
> +++ b/git-s
Kevin Daudt writes:
> rebase learned to stash changes when it encounters a dirty work tree, but
> git pull --rebase does not.
>
> Only verify if the working tree is dirty when rebase.autostash is not
> enabled.
>
> Signed-off-by: Kevin Daudt
> Helped-by: Paul Tan
> ---
> Changes to v2:
> - Dro
Matthieu Moy writes:
> Yes, but "Switch branchs or discard local changes" still does not
> describe "git checkout HEAD^^^ -- file.txt" (restore to an old state,
> but does not switch branch) or "git checkout -- file.txt" (get from the
> index).
You are right, especially when file.txt does not ha
Hi,
On 2015-06-17 14:58, SZEDER Gábor wrote:
> Quoting Johannes Schindelin :
>> diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
>> index dc3133f..16e0a82 100644
>> --- a/git-rebase--interactive.sh
>> +++ b/git-rebase--interactive.sh
>> @@ -849,7 +849,11 @@ continue)
>> #
Mike Hommey writes:
> I'm tempted to make init_notes itself do the check, based on the value
> it is given for a "read_only" argument.
Yeah, that would be one sensible way to go after making sure that
everything goes thru this interface.
> On the other hand, some commands
> do their ref resolvi
Simon Eugster writes:
> A better picture would be nice.
> And regarding the textual description, are you going to commit your version?
Nah, I'd rather not take credit away from you ;-)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.ke
Matthieu Moy writes
> Remi Lespinet writes:
> > if (defined $sender) {
> > + $sender =~ s/^\s+|\s$//g;
> I would say \s+ also for the second \s. Not really different, but it
> feels wrong to iterate the substitution as many times as there are
> trailing spaces to remove.
Oops should hav
Remi Lespinet writes:
> if (defined $sender) {
> + $sender =~ s/^\s+|\s$//g;
I would say \s+ also for the second \s. Not really different, but it
feels wrong to iterate the substitution as many times as there are
trailing spaces to remove.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
On Wed, Jun 17, 2015 at 9:54 PM, Duy Nguyen wrote:
> I think Coverity caught this correctly.
>
> ** CID 1306846: Memory - illegal accesses (USE_AFTER_FREE)
> /builtin/pull.c: 287 in config_get_rebase()
>
>
>
Do not consider quote inside a recipient name as character when
they are not escaped. This interprets:
"Jane" "Doe"
as:
"Jane Doe"
instead of:
"Jane\" \"Doe"
Signed-off-by: Remi Lespinet
---
I don't know if it's an argument for this change, but rfc2822 says:
Semantically, neith
Everything looks normal using the commands you described, and it does appear to
only affect status:
~/test (master)$ type git
git is hashed (/usr/local/bin/git)
~/test (master)$ git config --list
core.repositoryformatversion=0
core.filemode=true
core.bare=false
core.logallrefupdates=true
core.ign
Remove leading and trailing whitespaces in from field before
interepreting it to improve consistency with other options. The
split_addrs function already take care of trailing and leading
whitespaces for to, cc and bcc fields.
The from option now:
- has the same behavior when passing arguments l
2015-06-16 17:41 GMT+02:00 Junio C Hamano :
> Simon Eugster writes:
>
>> 2015-06-15 22:10 GMT+02:00 Junio C Hamano :
>>>
>>> "Simon A. Eugster" writes:
>>>
>>> > ---
>>>
>>> - Lack of explanation as to why this is a good thing.
>>> - Lack of sign-off.
>>>
>>> Why is there still 1/2, if its effect
Accept a list of emails separated by commas in flags --cc, --to and
--bcc. Multiple addresses can already be given by using these options
multiple times, but it is more convenient to allow cutting-and-pasting
a list of addresses from the header of an existing e-mail message,
which already lists th
parse_address_line had not the same behavior whether the user had
Mail::Address or not. Teach parse_address_line to behave like
Mail::Address.
When the user input is correct, this implementation behaves
exactly like Mail::Address except when there are quotes
inside the name:
"Jane Do"e
In thi
Move the creation of the scripts used in to-cmd and cc-cmd tests
in a setup test to make them available for later tests.
Signed-off-by: Remi Lespinet
---
t/t9001-send-email.sh | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/t/t9001-send-email.sh b/t/t9001-send
Simplify code by creating a function which transform a list of strings
containing email addresses (separated by commas, comporting aliases)
into a clean list of valid email addresses.
Signed-off-by: Remi Lespinet
---
git-send-email.perl | 22 --
1 file changed, 12 insertions(
Aliases were expanded before checking the From field of the
--compose option. This is inconsistent with other fields
(To, Cc, ...) which already support aliases.
Signed-off-by: Remi Lespinet
---
git-send-email.perl | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-send-
Create a function which replaces Date, Message-Id and
X-Mailer lines generated by git-send-email by a specific string:
Date:.*$ -> Date: DATE-STRING
Message-Id:.*$ -> Message-Id: MESSAGE-ID-STRING
X-Mailer:.*$ -> X-Mailer: X-MAILER-STRING
Signed-off-by: Remi Lespinet
---
t/t9001-send-ema
Group expressions in a single if statement. This avoid checking
multiple time if the variable $sender is defined.
Signed-off-by: Remi Lespinet
---
git-send-email.perl | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index f61449d
Interpret aliases in:
- Header fields of patches generated by git format-patch
(using --to, --cc, --add-header for example) or
manually modified. Example of fields in header:
To: alias1
Cc: alias2
Cc: alias3
- Outputs of command scripts specified by --cc-cmd and
I think Coverity caught this correctly.
** CID 1306846: Memory - illegal accesses (USE_AFTER_FREE)
/builtin/pull.c: 287 in config_get_rebase()
*** CID 1306846: Memory - illegal accesses (
Hi,
Quoting Johannes Schindelin :
When skipping commits whose changes were already applied via `git rebase
--continue`, we need to clean up said file explicitly.
The same is not true for `git rebase --skip` because that will execute
`git reset --hard` as part of the "skip" handling in git-rebas
"Andres G. Aragoneses" writes:
> On 17/06/15 13:54, Matthieu Moy wrote:
>> "Andres G. Aragoneses" writes:
>>
>>> On 17/06/15 12:54, Matthieu Moy wrote:
Duy Nguyen writes:
> On Wed, Jun 17, 2015 at 2:54 PM, Torsten Bögershausen
> wrote:
>> -git-checkout - Checkout a branc
On 17/06/15 13:54, Matthieu Moy wrote:
"Andres G. Aragoneses" writes:
On 17/06/15 12:54, Matthieu Moy wrote:
Duy Nguyen writes:
On Wed, Jun 17, 2015 at 2:54 PM, Torsten Bögershausen wrote:
-git-checkout - Checkout a branch or paths to the working tree
+git-checkout - Switch branches or r
"Andres G. Aragoneses" writes:
> On 17/06/15 12:54, Matthieu Moy wrote:
>> Duy Nguyen writes:
>>
>>> On Wed, Jun 17, 2015 at 2:54 PM, Torsten Bögershausen wrote:
-git-checkout - Checkout a branch or paths to the working tree
+git-checkout - Switch branches or restore changes
>>>
>>> I
1 - 100 of 122 matches
Mail list logo
