On Tue, Apr 5, 2016 at 12:07 PM, wrote:
> builtin/verify-tag: replace name argument with sha1
builtin/verify-tag: prepare verify_tag() for libification
> This change is meant to prepare verify_tag for libification. Many
> existing modules/commands already do the refname to sha1 resolution,
> On 05 Apr 2016, at 21:15, Johannes Sixt wrote:
>
> Am 05.04.2016 um 19:09 schrieb Junio C Hamano:
>>> Thanks-to: Torsten Bögershausen
>
> I sense NFD disease: The combining diaresis should combine with the o, not
> the g. Here is a correct line to copy-and-paste if you like:
>
> Thanks-to
Junio C Hamano venit, vidit, dixit 06.04.2016 01:16:
> Michael J Gruber writes:
>
>>> The "test" command is used as it does not generate any output on stdout.
>>
>> "test" is a bit of a red herring here since it will receive commands.
>> But your example works even with "true" which ignores its c
On Tue, Apr 5, 2016 at 12:07 PM, wrote:
> t7030-verify-tag: Adds validation for multiple tags
s/t7030-verify-tag/t7030/
s/Adds/add
> The verify-tag command supports multiple tag names as an argument.
> However, existing tests only test for invocation with a single tag, so
> we add a test invoki
On Tue, Apr 05, 2016 at 12:58:38PM -0700, Seren Thompson wrote:
> I'm not having luck with overriding the fsck message types
> (zeroPaddedFilemode specifically). I've tried adding
> [fsck]
> zeroPaddedFilemode = ignore
> to both global and local configs, but it seems to have no effect:
>
>
On Wed, Apr 06, 2016 at 01:53:35AM -0400, Eric Sunshine wrote:
> On Tue, Apr 5, 2016 at 6:21 AM, Elia Pinto wrote:
> > 2016-04-01 22:25 GMT+02:00 Eric Sunshine :
> >> In addition to review comments by others, why are the new curl_dump()
> >> and curl_trace() functions duplicated in both patches r
Hi,
Recently while playing around with git log, I realized that it is possible to
pass incomplete (pre-defined) format names. For example, it is possible to use
`git log --pretty=one` instead of oneline and it would still output the logs in
oneline formatting. Same goes for other formats such as '
Chen Bin writes:
> This is a feature request.
>
> From time to time, I want to re-use MY code. So git grep with --Author
> options is really useful. My current git version is 2.6.3, looks it
> doesn't have this option.
Git doesn't "know" which line of code is yours. What it can do is walk
throug
On Tue, Apr 5, 2016 at 11:39 AM, Pranit Bauva wrote:
> On Mon, Apr 4, 2016 at 3:00 AM, Eric Sunshine wrote:
>> On Sat, Apr 2, 2016 at 7:33 PM, Pranit Bauva wrote:
>>> Current implementation of parse-options.c treats OPT__QUIET() as integer
>>> and not boolean and thus it is more appropriate to p
On Tue, Apr 5, 2016 at 6:21 AM, Elia Pinto wrote:
> 2016-04-01 22:25 GMT+02:00 Eric Sunshine :
>> In addition to review comments by others, why are the new curl_dump()
>> and curl_trace() functions duplicated in both patches rather than
>> factored out to a shared implementation?
>
> It's right. D
On 05.04.16 23:12, Junio C Hamano wrote:
> tbo...@web.de writes:
>
>> +git config core.autocrlf true &&
>> +mv crlfinrepo tmp &&
>> +git checkout crlfinrepo &&
>> +rm tmp &&
>
> Why not just "rm -f crlfinrepo" and "git checkout crlfinrepo"?
The intention was to get a new inode num
--
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
This is a feature request.
>From time to time, I want to re-use MY code. So git grep with --Author options
>is really useful. My current git version is 2.6.3, looks it doesn't have this
>option.
--
Best Regards,
Chen Bin
--
Help me, help you
--
To unsubscribe from this list: send the line "un
Michael J Gruber writes:
>> The "test" command is used as it does not generate any output on stdout.
>
> "test" is a bit of a red herring here since it will receive commands.
> But your example works even with "true" which ignores its commands and
> produces no output.
Either sounds strange, as
Chris Packham writes:
> We ran into something at $dayjob the other day. The actual problem was
> a developer ended up amending a commit that had already been pushed.
> It happens occasionally and is usually recoverable with a simple
> rebase and is generally a learning experience. In this particu
Good day, friend. I'm a Banker with HSBC here in Malaysia.I have an interesting
business deal for you that will be of immense benefit to both of us.Although
this
may be hard for you to believe,we stand to gain $7million in a matter of days.
Please grant me the benefit of doubt and hear me out.
Torsten Bögershausen writes:
> On 05.04.16 21:15, Johannes Sixt wrote:
>> Am 05.04.2016 um 19:09 schrieb Junio C Hamano:
Thanks-to: Torsten Bögershausen
>>
>> I sense NFD disease: The combining diaresis should combine with the o, not
>> the g. Here is a correct line to copy-and-paste if
Junio C Hamano wrote:
> Eric Wong writes:
>
> > Using a mmddHHMMSS date representation is more meaningful to
> > humans, especially when used for lookups on NNTP servers or linking
> > to archive sites via Message-ID (e.g. mid.gmane.org or
> > mid.mail-archive.com). This timestamp format mo
tbo...@web.de writes:
> + git config core.autocrlf true &&
> + mv crlfinrepo tmp &&
> + git checkout crlfinrepo &&
> + rm tmp &&
Why not just "rm -f crlfinrepo" and "git checkout crlfinrepo"?
> + git blame crlfinrepo >actual &&
> + grep "A U Thor" actual
> +'
> +
> test_
Eric Wong writes:
> Using a mmddHHMMSS date representation is more meaningful to
> humans, especially when used for lookups on NNTP servers or linking
> to archive sites via Message-ID (e.g. mid.gmane.org or
> mid.mail-archive.com). This timestamp format more easily gives a
> reader of the U
Thanks for the information that binary builds are availably on
SourceForge faster than on git-scm. I can see the v2.8.1 for OS X was
uploaded few hours ago to the SF, so my main problem (lack of security
fixes in git for OS X) is solved.
The automation process should be probably reviewed, though -
tbo...@web.de writes:
> This fix is completely independent of the rest of the series,
> so break out 6/7 from tb/safe-crlf-output.
Sounds sensible. It is somewhat sad and strange that we need to
rely on what is in the index to show the current working tree state,
but this makes the things more
Eric Sunshine writes:
> On Tue, Apr 5, 2016 at 6:05 AM, Elia Pinto wrote:
>> The correct api is trace_printf_key
>>
>> Signed-off-by: Elia Pinto
>> ---
>> diff --git a/Documentation/technical/api-trace.txt
>> b/Documentation/technical/api-trace.txt
>> @@ -28,7 +28,7 @@ static struct trace_key
Hi,
Would you be interested in reaching out to "Condominium Owners List"? with
opt-in verified email addresses from the USA.
We also have contacts of Real Estate Investors, Home Owners, Mortgage Holders,
Mortgage with Home, Investors List, New Movers List, Golfers Email List, High
Net-worth
I'm not having luck with overriding the fsck message types (zeroPaddedFilemode
specifically). I've tried adding
[fsck]
zeroPaddedFilemode = ignore
to both global and local configs, but it seems to have no effect:
$ git --version
git version 2.8.0
$ git config --get fetch.fsckobjects
Using a mmddHHMMSS date representation is more meaningful to
humans, especially when used for lookups on NNTP servers or linking
to archive sites via Message-ID (e.g. mid.gmane.org or
mid.mail-archive.com). This timestamp format more easily gives a
reader of the URL itself a rough date of a li
On 05.04.16 21:15, Johannes Sixt wrote:
> Am 05.04.2016 um 19:09 schrieb Junio C Hamano:
>>> Thanks-to: Torsten Bögershausen
>
> I sense NFD disease: The combining diaresis should combine with the o, not
> the g. Here is a correct line to copy-and-paste if you like:
>
> Thanks-to: Torsten Böge
From: Torsten Bögershausen
git blame reports lines as not "Not Committed Yet" when they have
CRLF in the index, CRLF in the worktree and core.autocrlf is true.
Since commit c48053 "new safer autocrlf handling", files that have CRLF
in the index are not normalized at commit when core.autocrl is s
Am 05.04.2016 um 19:09 schrieb Junio C Hamano:
Thanks-to: Torsten Bögershausen
I sense NFD disease: The combining diaresis should combine with the o,
not the g. Here is a correct line to copy-and-paste if you like:
Thanks-to: Torsten Bögershausen
-- Hannes
--
To unsubscribe from this li
Junio C Hamano writes:
> Checking the value against ULONG_MAX and errno==ERANGE would be an
> improvement. It may be debatable if we should silently ignore an
> entry with an invalid timestamp, but that is a separate issue.
>
> refs.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
On Tue, Apr 5, 2016 at 6:05 AM, Elia Pinto wrote:
> The correct api is trace_printf_key
>
> Signed-off-by: Elia Pinto
> ---
> diff --git a/Documentation/technical/api-trace.txt
> b/Documentation/technical/api-trace.txt
> @@ -28,7 +28,7 @@ static struct trace_key trace_foo = TRACE_KEY_INIT(FOO);
Alexander Rinass writes:
> File paths containing decomposed unicode chars passed to diff
> command are not converted to precomposed unicode form.
>
> As a result, no diff is displayed when feeding such a file path to the
> diff command.
>
> Opposite to most builtin commands, the diff builtin is m
Sorry, forgot to add, this is a follow on to [1].
Thanks,
-Santiago.
[1]:
http://git.661346.n2.nabble.com/PATCH-v4-0-6-tag-move-PGP-verification-code-to-tag-c-td7652451.html
On Tue, Apr 05, 2016 at 12:07:23PM -0400, santi...@nyu.edu wrote:
> From: Santiago Torres
>
> v5 (this):
> Added helpful
W dniu 05.04.2016 o 16:47, Pranit Bauva pisze:
> On Tue, Apr 5, 2016 at 8:08 PM, Jacek Wielemborek wrote:
>> Hello,
>>
>> I'm asking for this one because there's quite a lot of interest
>> (including me) in this feature and there is no convenient walkaround:
>>
>> https://stackoverflow.com/questio
From: Santiago Torres
v5 (this):
Added helpful feedback by Eric
* Reordering of the patches, to avoid temporal inclusion of a regression
* Fix typos here and there.
* Review commit messages, as some weren't representative of what the patches
were doing anymore.
* Updated t7030 to include
From: Santiago Torres
The verify_signed_buffer comand might cause a SIGPIPE signal when the
gpg child process terminates early (due to a bad keyid, for example) and
git tries to write to it afterwards. Previously, ignoring SIGPIPE was
done on the builtin/verify-tag.c command to avoid this issue.
From: Santiago Torres
The verify-tag command supports multiple tag names as an argument.
However, existing tests only test for invocation with a single tag, so
we add a test invoking with multiple tags.
Helped-by: Jeff King
Signed-off-by: Santiago Torres
---
t/t7030-verify-tag.sh | 12 +++
From: Santiago Torres
The PGP verification routine for tags could be accessed by other
commands that require it. We do this by moving it to the common tag.c
module. We rename the verify_tag() function to gpg_verify_tag() to avoid
conflicts with the mktag.c function.
Signed-off-by: Santiago Torre
From: Santiago Torres
This change is meant to prepare verify_tag for libification. Many
existing modules/commands already do the refname to sha1 resolution, so
should avoid resolving the refname twice. To avoid breaking
builtin/verify-tag, we move the refname resolution outside of the
verify_tag(
From: Santiago Torres
Instead of running the verify-tag plumbing command, we use the
gpg_verify_tag() function within the verify_tag function to avoid doing
an additional fork call.
Signed-off-by: Santiago Torres
---
builtin/tag.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
d
From: Santiago Torres
The run_gpg_verify function has two variables size, and len. This may
come off as confusing when reading the code. We clarify which one
pertains to the length of the tag headers by renaming len to
payload_length.
Signed-off-by: Santiago Torres
---
builtin/verify-tag.c | 1
On Tue, Apr 5, 2016 at 4:59 AM, Eric Sunshine wrote:
> On Sun, Apr 3, 2016 at 8:58 PM, Eric Sunshine wrote:
>> The fact that the 32 new tests are nearly identical suggests strongly
>> that the testing should instead either be table-driven or be done via
>> for-loops to systematically cover all ca
On Mon, Apr 4, 2016 at 5:32 AM, Eric Sunshine wrote:
> On Sat, Apr 2, 2016 at 7:33 PM, Pranit Bauva wrote:
>> Make the fake "editor" store output of grep in a file so that we can
>> see how many diffs were contained in the message and use them in
>> individual tests where ever it is required. Als
Erik Bray writes:
> I tracked the issue to refs/files-backend.c in show_one_reflog_ent :
>
> https://github.com/git/git/blob/11529ecec914d2f0d7575e6d443c2d5a6ff75424/refs/files-backend.c#L2923
>
> in which
>
> !(timestamp = strtoul(email_end + 2, &message, 10)) ||
>
> implies an invalid reflog en
On Mon, Apr 4, 2016 at 4:40 AM, Eric Sunshine wrote:
> On Sat, Apr 2, 2016 at 7:33 PM, Pranit Bauva wrote:
>> The reason to make it respect "unspecified" values is to give the
>> ability to differentiate whether `--option` or `--no-option` was
>> specified at all. "unspecified" values should be i
[+cc:Duy Nguyen, Jonathan Nieder]
On Mon, Apr 4, 2016 at 3:00 AM, Eric Sunshine wrote:
> On Sat, Apr 2, 2016 at 7:33 PM, Pranit Bauva wrote:
>> Current implementation of parse-options.c treats OPT__QUIET() as integer
>> and not boolean and thus it is more appropriate to print it as integer
>> to
On Tue, Apr 5, 2016 at 8:08 PM, Jacek Wielemborek wrote:
> Hello,
>
> I'm asking for this one because there's quite a lot of interest
> (including me) in this feature and there is no convenient walkaround:
>
> https://stackoverflow.com/questions/5875275/git-commit-v-by-default
>
> Cheers,
> d33tah
Hello,
I'm asking for this one because there's quite a lot of interest
(including me) in this feature and there is no convenient walkaround:
https://stackoverflow.com/questions/5875275/git-commit-v-by-default
Cheers,
d33tah
signature.asc
Description: OpenPGP digital signature
Georg Pichler venit, vidit, dixit 20.03.2016 13:43:
> Hi,
>
> I realized that "git diff --exit-code" does not honour textconv settings.
> Maybe this behaviour is desired. It can be partially circumvented by using
> the "-b" flag if one does not care about whitespace changes.
> To reproduce this,
Michael J Gruber wrote:
> Remi Galan Alfonso venit, vidit, dixit 05.04.2016 14:28:
> > Michael J Gruber wrote:
> >> A few changelog entries have inconsistent dates, which rpmlint reports
> >> as errors.
> >>
> >> Fix them based on these assumptions:
> >> - It's easier to mistype a number than a w
Remi Galan Alfonso venit, vidit, dixit 05.04.2016 14:28:
> Michael J Gruber wrote:
>> A few changelog entries have inconsistent dates, which rpmlint reports
>> as errors.
>>
>> Fix them based on these assumptions:
>> - It's easier to mistype a number than a weekday abbreviation.
>> - changelog dat
Am 05.04.2016 um 04:19 schrieb Timothee Cour:
> Could we have block comments in gitconfig?
> It's a nice-to-have supported in most languages.
> eg:
>
> #{
> commented out block
> #}
>
> or other intuitive syntax
Maybe not what you're looking for, but couldn't you use
the include functionality of
Michael J Gruber wrote:
> A few changelog entries have inconsistent dates, which rpmlint reports
> as errors.
>
> Fix them based on these assumptions:
> - It's easier to mistype a number than a weekday abbreviation.
> - changelog date must be before git commit date
> - The mistyped date is just a
A few changelog entries have inconsistent dates, which rpmlint reports
as errors.
Fix them based on these assumptions:
- It's easier to mistype a number than a weekday abbreviation.
- changelog date must be before git commit date
- The mistyped date is just a few days off.
Signed-off-by: Michael
Hi Timothee,
On Mon, 4 Apr 2016, Timothee Cour wrote:
> Could we have block comments in gitconfig?
> It's a nice-to-have supported in most languages.
> eg:
>
> #{
> commented out block
> #}
>
> or other intuitive syntax
You could have such block comments. If you implemented that feature.
Havi
Hi all,
I found this issue through a test suite for a Python git interface,
which during the tests at some point sets
GIT_COMMITTER_DATE=1970-01-01T00:00:00
To reproduce the issue:
$ git init
$ echo foo > testfile
$ git add testfile
$ git commit -m "test"
$ echo bar >> testfile
$ export GIT_COM
Hi,
We ran into something at $dayjob the other day. The actual problem was
a developer ended up amending a commit that had already been pushed.
It happens occasionally and is usually recoverable with a simple
rebase and is generally a learning experience. In this particular case
however things wer
Signed-off-by: Michael J Gruber
---
contrib/completion/git-completion.bash | 1 +
1 file changed, 1 insertion(+)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index e3918c8..d87cf4d 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/
2016-04-03 21:21 GMT+02:00 Junio C Hamano :
> If you do not build RPM binary packages from our pristine source,
> you can safely ignore this release and stop reading this message.
>
> Now that the audience of this message has been limited to a narrow
> target, before I make an announcement, here is
2016-04-01 22:25 GMT+02:00 Eric Sunshine :
> On Fri, Apr 1, 2016 at 6:44 AM, Elia Pinto wrote:
>> Implements the GIT_CURL_DEBUG environment variable to allow a greater
>> degree of detail of GIT_CURL_VERBOSE, in particular the complete
>> transport header and all the data payload exchanged.
>> It
The correct api is trace_printf_key
Signed-off-by: Elia Pinto
---
Documentation/technical/api-trace.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/technical/api-trace.txt
b/Documentation/technical/api-trace.txt
index 389ae16..45a0ecd 100644
--- a/Documenta
Junio C Hamano venit, vidit, dixit 03.04.2016 21:21:
> If you do not build RPM binary packages from our pristine source,
> you can safely ignore this release and stop reading this message.
>
> Now that the audience of this message has been limited to a narrow
> target, before I make an announcemen
Jeff King wrote:
> > +test_expand --pretty=fuller
> > +test_expand --pretty=fuller
>
> Duplicated fuller?
Just brush it off :)
[Those too young to get the joke can
look up "fuller brush" in Wikipedia.]
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a messag
Ye Xiaolong writes:
> ---1---o---A
> /\ /
> ---O X
> \/ \
> ---2---o---o---B
>
> For this criss-cross merges, as neither merge base(like 1) is better
> than the other(both 1 and 2 are 'best' merge bases), I think it should
> be fine to pick a random one as base
In general "echo 2>&1 $msg" to redirect a possible error message
that comes from 'echo' itself into the same standard output stream
$msg is getting written to does not make any sense; it is not like
we are expecting to see any errors out of 'echo' in these statements,
and even if it were the case,
65 matches
Mail list logo
