[+cc git@vger, since this may be of interest to others]
On Tue, Nov 11, 2014 at 02:40:59PM -0800, Scott Baker wrote:
> I'd like to recreate the github style diffs on the command line. It
> appears that your diff-highlight is very close. The current version only
> allows you to "invert the colors"
--
A postaláda korlátozza, kérjük, kattintson ide prekrocila
http://updattw2qq.jigsy.com
Ellen?rizze a elektronikus levél köszönet
Rendszergazda E-mail System.
Köszönjük az együttm?ködést!
Levél a Web Team @ 2014
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body
On Tue, Nov 11, 2014 at 7:40 PM, Johan Herland wrote:
> Make this test script appear somewhat less old-fashioned:
> Signed-off-by: Johan Herland
> ---
> diff --git a/t/t3301-notes.sh b/t/t3301-notes.sh
> index 416ed9e..861c159 100755
> --- a/t/t3301-notes.sh
> +++ b/t/t3301-notes.sh
> @@ -50,206
Make this test script appear somewhat less old-fashioned:
- Use test helper functions:
- write_script
- test_commit
- test_write_lines
- test_line_count
- test_config
- test_unconfig
- test_path_is_missing
- Remove whitespace between redirection operators and their tar
Add test cases documenting the current behavior when trying to
add/append/edit empty notes. This is in preparation for adding
--allow-empty; to allow empty notes to be stored.
Improved-by: Eric Sunshine
Improved-by: Junio C Hamano
Signed-off-by: Johan Herland
---
t/t3301-notes.sh | 27
Although the "git notes" man page advertises that we support binary-safe
notes addition (using the -C option), we currently do not support adding
the empty note (i.e. using the empty blob to annotate an object). Instead,
an empty note is always treated as an intent to remove the note
altogether.
I
This fixes a small buglet when trying to explicitly add the empty blob
as a note object using the -c or -C option to git notes add/append.
Instead of failing with a nonsensical error message indicating that the
empty blob does not exist, we should rather behave as if an empty notes
message was give
If the user has gone through the trouble of explicitly adding an empty
note, then "git log" should not silently skip it (as if it didn't exist).
Signed-off-by: Johan Herland
---
notes.c | 3 +--
t/t3301-notes.sh | 12
2 files changed, 13 insertions(+), 2 deletions(-)
diff
Remove the need for 'retval' and the unnecessary goto. Also reorganize
to only call free_note_data() is actually needed.
Improved-by: Junio C Hamano
Signed-off-by: Johan Herland
---
builtin/notes.c | 35 +--
1 file changed, 17 insertions(+), 18 deletions(-)
diff
create_note() has a non-trivial interface, and comprises three loosely
related parts:
1. launching the editor with the note contents, if needed
2. appending to an existing note, if append_only was given
3. adding or removing the resulting note, based on whether it's non-empty
Split it along th
Move the 'path' variable from create_note() and into the
note_data struct. Unify cleanup of note_data objects with
a free_note_data() function.
This might not make too much sense on its own, but it makes the
future refactoring of create_note() considerably cleaner.
Signed-off-by: Johan Herland
-
In preparation for some needed refactoring, rename struct msg_arg to
struct note_data, and rename its instances from "msg" to "d" (also
removing some unnecessary parentheses). The 'msg_arg' name was
inherited from tag.c, but is not really a good name for the contents
of a note.
Also rename write_n
Changes v4 -> v5:
- Patch #5: Reorder code to ease readability and fix issue with
checking d.given after free_note_data(&d), noticed by Junio.
- Patch #9: Fix typo in commit message, noticed by Junio.
- Patch #9: Rename "output" files to "actual", suggested by Eric.
- Patch #9: Use test_
On Tue, Nov 11, 2014 at 3:41 AM, Jeff King wrote:
> On Tue, Nov 11, 2014 at 02:40:19AM +0100, Johan Herland wrote:
>> > This and all other failures are due to the output of 'wc -l', which on
>> > Mac is "{whitespace}1" rather than just "1" as it is on other
>> > platforms. fbe4f748 added quotes ar
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
You can find the changes described here in the integration branches
of the repositories listed at
http://git-blame.blogspot.com/p/git-publi
Christian Halstrick writes:
> ok, thanks. Then I'll teach JGit to fetch at least "HEAD" if nothing
> is configured and nothing explicitly specified as refspec.
Sounds like a sensible thing to do to match what JGit does to what
we did from the time immemorial ;-)
Thanks.
--
To unsubscribe from t
ok, thanks. Then I'll teach JGit to fetch at least "HEAD" if nothing
is configured and nothing explicitly specified as refspec.
Ciao
Chris
On Sun, Nov 9, 2014 at 6:23 PM, Junio C Hamano wrote:
> Jakub Narębski writes:
>
>> W dniu 2014-11-08 11:52, Jeff King pisze:
>>> On Fri, Nov 07, 2014 at
Thomas Ackermann writes:
> Signed-off-by: Thomas Ackermann
> ---
> Documentation/gittutorial.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/gittutorial.txt b/Documentation/gittutorial.txt
> index af9f709..710e636 100644
> --- a/Documentation/gittutori
Max Horn writes:
> I did this because I was browsing the remote helper docs online quite a bit,
> and was wishing for some more direct links between the pages. While I can
> manyally edit the URL, it seems logical to offer these links directly.
> diff --git a/Documentation/git-fast-export.txt
>
In particular, git-fast-import and -export link to each
other, and gitremote-helpers links to existing remote
helpers, and vice versa. Also link to fast-import from the
remote helper spec, as this is relevant for remote helpers
using the fast-import format.
Signed-off-by: Max Horn
---
I did this
Signed-off-by: Thomas Ackermann
---
Documentation/gittutorial.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/gittutorial.txt b/Documentation/gittutorial.txt
index af9f709..710e636 100644
--- a/Documentation/gittutorial.txt
+++ b/Documentation/gittutorial.tx
Junio C Hamano writes:
> Either way, I do not see how such an arrangement is the most
> convenient way to organize the tickets and ask questions such as
> "what are the known, untriaged, or unresolved issues in v1.8.5?",
> "what are the issues that didn't exist in v1.7.0 but appear in
> v1.8.5?",
Am 11.11.2014 um 18:17 schrieb Junio C Hamano:
Holger Hellmuth writes:
Am 06.11.2014 um 19:45 schrieb Junio C Hamano:
This is a tangent, but I personally do not think "ticket" meshes
very well with "commit". If you already know which commit was
problematic, why are you annotating it with a t
Jiang Xin writes:
> Please pull the following git l10n updates.
>
> The following changes since commit 4ace7ff4557350b7e0b57d024a2ea311b332e01d:
>
> Git 2.2.0-rc0 (2014-10-31 11:57:23 -0700)
>
> are available in the git repository at:
>
> git://github.com/git-l10n/git-po master
>
> for you to
Jeff King writes:
> I had always just assumed that -Wstrict-prototypes was part of -Wall,
> but it is not (nor even part of -Wextra!). Maybe it is time to add it to
> your integration-build flags. :)
Yup, I had -Wold-style-definition but not -Wstrict-prototypes in the
mix. Thanks for spotting.
Holger Hellmuth writes:
> Am 06.11.2014 um 19:45 schrieb Junio C Hamano:
>> This is a tangent, but I personally do not think "ticket" meshes
>> very well with "commit". If you already know which commit was
>> problematic, why are you annotating it with a ticket before
>> reverting it first?
>
>
Johan Herland writes:
> Ah, thanks!
>
> I thought that quoting command output was a good idea in general. Am I
> wrong, or is this just one exception to an otherwise good guideline?
It is not a good practice to blindly follow any guideline ;-).
When you anticipate that different platforms throw
Jeff King writes:
> I don't think this is "unfortunately"; freeing the memory was the entire
> purpose in adding env_array. If you want to easily reuse the same
> environment in multiple commands, it is still perfectly fine to use
> "env" directly, like:
>
> struct argv_array env = ARGV_ARRAY_I
Johan Herland writes:
> On Mon, Nov 10, 2014 at 9:36 PM, Junio C Hamano wrote:
>> Johan Herland writes:
>>
>>> Signed-off-by: Johan Herland
>>> ---
>>> builtin/notes.c | 12 +---
>>> 1 file changed, 5 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/builtin/notes.c b/builtin/notes.c
On Tue, Nov 11, 2014 at 2:34 AM, Jeff King wrote:
> On Tue, Oct 21, 2014 at 01:36:47PM -0700, Ronnie Sahlberg wrote:
>
>> commit e193c10fc4f9274d1e751cfcdcc4507818e8d498 upstream.
>>
>> Change lock_ref_sha1_basic to return an error instead of dying when
>> we fail to lock a file during a transacti
Am 06.11.2014 um 19:45 schrieb Junio C Hamano:
This is a tangent, but I personally do not think "ticket" meshes
very well with "commit". If you already know which commit was
problematic, why are you annotating it with a ticket before
reverting it first?
I would expect a ticket to be annotating
I've come to the last piece to speed up "git status", watchman
support. And I realized it's not as good as I thought.
Watchman could be used for two things: to avoid refreshing the index,
and to avoid searching for ignored files. The first one can be done
(with the patch below as demonstration). A
On Tue, Oct 21, 2014 at 01:36:47PM -0700, Ronnie Sahlberg wrote:
> commit e193c10fc4f9274d1e751cfcdcc4507818e8d498 upstream.
>
> Change lock_ref_sha1_basic to return an error instead of dying when
> we fail to lock a file during a transaction.
> This function is only called from transaction_commi
33 matches
Mail list logo