On Sat, Jun 20, 2015 at 5:47 AM, Heiko Voigt wrote:
> I am currently experiencing sporadic test failures on Mac OS X 10.10.3:
>
> Test Summary Report
> ---
> t7503-pre-commit-hook.sh (Wstat: 256 Tests: 11
> Failed: 1)
> Failed test: 9
> Non-zero exit s
On 06/21/2015 04:16 PM, Robert Dailey wrote:
On Sun, Jun 21, 2015 at 9:04 AM, Robert Dailey wrote:
Upon inspection of the gitattributes documentation page here:
https://git-scm.com/docs/gitattributes
When comparing the documentation for 'text' with 'eol', I see the
following missing explanatio
On Wed, Jun 17, 2015 at 06:39:27PM -0400, Ismail Badawi wrote:
> 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
On Fri, Jun 19, 2015 at 6:35 AM, Johannes Schindelin
wrote:
>
> @@ -227,6 +277,10 @@ static int report(struct fsck_options *options, struct
> object *object,
> if (msg_type == FSCK_IGNORE)
> return 0;
>
> + if (options->skiplist && object &&
> +
On Sun, Jun 21, 2015 at 1:48 PM, Karthik Nayak wrote:
> Rename parse_opt_with_commit() to parse_opt_commit_object_name()
> to show that it can be used to obtain a list of commits and is
> not constricted to usage of '--contains' option.
I think that is a brilliant idea, but unlike the other funct
On Sun, Jun 21, 2015 at 1:48 PM, Karthik Nayak wrote:
> +static void do_merge_filter(struct ref_filter_cbdata *ref_cbdata)
> +{
> + struct rev_info revs;
> + int i, old_nr;
> + struct ref_filter *filter = ref_cbdata->filter;
> + struct ref_array *array = ref_cbdata->array;
On Sun, Jun 21, 2015 at 1:48 PM, Karthik Nayak wrote:
> Add 'parse_opt_merge_filter()' to parse '--merged' and '--no-merged'
> options and write MACROS for the same.
Why SHOUT here?
>
> This is copied from 'builtin/branch.c' which will eventually be removed
> when we port 'branch.c' to use ref-f
3 & 4 as a single patch may make more sense, if we were to tolerate the
"let's copy & paste first and then later remove the duplicate" as a way to
postpone touching "tag.c" side in order to first concentrate on for-each-ref.
I have not formed a firm opinion on what the right split of the series i
On Sun, Jun 21, 2015 at 1:51 PM, Karthik Nayak wrote:
> On Mon, Jun 22, 2015 at 2:15 AM, Karthik Nayak wrote:
>> The previous version of the patch series can be found here :
>> thread.gmane.org/gmane.comp.version-control.git/271754
>>
>> Changes in this version :
>> * 01/11: Remove unnecessary
On Sun, Jun 21, 2015 at 4:14 PM, brian m. carlson
wrote:
>
> This series introduces a --raw option for verify-commit and verify-tag.
> If it's used, they provide the gpg --status-fd output on standard error
> instead of the human-readable output. The series also adds tests for
> verify-tag, since
On Sun, Jun 21, 2015 at 03:07:41PM +0200, Richard Weinberger wrote:
> > I was then shocked to learn that ext4 apparently has a default
> > setting that allows it to truncate files upon power failure
> > (something about a full journal vs a fast journal or some such)
s/ext4/all modern file systems
The code to handle printing of signature data from a struct
signature_check is very similar between verify-commit and verify-tag.
Place this in a single function. verify-tag retains its special case
behavior of printing the tag even when no valid signature is found.
Signed-off-by: brian m. carlso
verify-commit by default displays human-readable output on standard
error. However, it can also be useful to get access to the raw gpg
status information, which is machine-readable, allowing automated
implementation of signing policy. Add a --raw option to make
verify-commit produce the gpg statu
verify-tag was executing an entirely different codepath than
verify-commit, except for the underlying verify_signed_buffer. Move
much of the code from check_commit_signature to a generic
check_signature function and adjust both codepaths to call it.
Update verify-tag to explicitly output the sign
verify-tag exits successfully if the signature is good but the key is
untrusted. verify-commit exits unsuccessfully. This divergence in
behavior is unexpected and unwanted. Since verify-tag existed earlier,
add a failing test to have verify-commit share verify-tag's behavior.
Signed-off-by: bri
Currently, verify-commit and verify-tag produce human-readable output.
This is great for humans, and awful for machines. It also lacks a lot
of the information that GnuPG's --status-fd output provides.
For example, if you wanted to know
* the hash algorithm;
* whether the signature was made with
verify-tag was lacking tests. Add some, mirroring those used for
verify-commit.
Signed-off-by: brian m. carlson
---
t/t7030-verify-tag.sh | 84 +++
1 file changed, 84 insertions(+)
create mode 100755 t/t7030-verify-tag.sh
diff --git a/t/t7030-ve
verify-tag by default displays human-readable output on standard error.
However, it can also be useful to get access to the raw gpg status
information, which is machine-readable, allowing automated
implementation of signing policy. Add a --raw option to make verify-tag
produce the gpg status infor
verify-commit and verify-tag both share a central codepath for verifying
commits: check_signature. However, verify-tag exited successfully for
untrusted signature, while verify-commit exited unsuccessfully.
Centralize this signature check and make verify-commit adopt the older
verify-tag behavior.
On Mon, Jun 22, 2015 at 2:15 AM, Karthik Nayak wrote:
> The previous version of the patch series can be found here :
> thread.gmane.org/gmane.comp.version-control.git/271754
>
> Changes in this version :
> * 01/11: Remove unnecessary tests and add signed tag.
> * 04/11: Grammatical change.
> *
Add the '--merged' and '--no-merged' options provided by 'ref-filter'.
The '--merged' option lets the user to only list refs merged into the
named commit. The '--no-merged' option lets the user to only list refs
not merged into the named commit.
Add documentation and tests for the same.
Based-on-
Add the '--contains' option provided by 'ref-filter'. The '--contains'
option lists only refs which contain the mentioned commit (HEAD if no
commit is explicitly given).
Add documentation and tests for the same.
Mentored-by: Christian Couder
Mentored-by: Matthieu Moy
Signed-off-by: Karthik Naya
In 'branch -l' we have '--merged' option which only lists refs (branches)
merged into the named commit and '--no-merged' option which only lists
refs (branches) not merged into the named commit. Implement these two
options in ref-filter.{c,h} so that other commands can benefit from this.
Based-on-
'tag -l' and 'branch -l' have two different ways of finding
out if a certain ref contains a commit. Implement both these
methods in ref-filter and give the caller of ref-filter API
the option to pick which implementation to be used.
'branch -l' uses 'is_descendant_of()' from commit.c which is
left
Rename parse_opt_with_commit() to parse_opt_commit_object_name()
to show that it can be used to obtain a list of commits and is
not constricted to usage of '--contains' option.
Mentored-by: Christian Couder
Mentored-by: Matthieu Moy
Signed-off-by: Karthik Nayak
---
builtin/branch.c | 4 ++--
Add a macro for using the '--contains' option in parse-options.h
also include an optional '--with' option macro which performs the
same action as '--contains'.
Make tag.c use this new macro.
Mentored-by: Christian Couder
Mentored-by: Matthieu Moy
Signed-off-by: Karthik Nayak
---
builtin/tag.c
Add the '--points-at' option provided by 'ref-filter'. The
option lets the user to pick only refs which point to a particular
commit.
Add documentation and tests for the same.
Based-on-patch-by: Jeff King
Mentored-by: Christian Couder
Mentored-by: Matthieu Moy
Signed-off-by: Karthik Nayak
---
Rename 'parse_opt_points_at()' to 'parse_opt_object_name()' and
move it from 'tag.c' to 'parse-options'. This now acts as a common
parse_opt function which accepts an objectname and stores it into
a sha1_array.
Based-on-patch-by: Jeff King
Mentored-by: Christian Couder
Mentored-by: Matthieu Moy
Add a test suite for testing the ref-filter APIs used
by for-each-ref. We just intialize the test suite for now.
More tests will be added in the following patches as more
options are added to for-each-ref.
Based-on-patch-by: Jeff King
Mentored-by: Christian Couder
Mentored-by: Matthieu Moy
Sign
In 'tag -l' we have '--points-at' option which lets users
list only tags which point to a particular commit. Implement
this option in 'ref-filter.{c,h}' so that other commands can
benefit from this.
This is duplicated from tag.c, we will eventually remove that
when we port tag.c to use ref-filter
Add 'parse_opt_merge_filter()' to parse '--merged' and '--no-merged'
options and write MACROS for the same.
This is copied from 'builtin/branch.c' which will eventually be removed
when we port 'branch.c' to use ref-filter APIs.
Based-on-patch-by: Jeff King
Mentored-by: Christian Couder
Mentored
The previous version of the patch series can be found here :
thread.gmane.org/gmane.comp.version-control.git/271754
Changes in this version :
* 01/11: Remove unnecessary tests and add signed tag.
* 04/11: Grammatical change.
* 06/11: Introduce a comment to explain code.
* 11/11: Grammatica
Junio C Hamano writes:
> Of course, that assumes that you can tell an object is a blob
> without unpacking. If a tree entry mentions an object to be a blob
> by having 100644 as its mode, unless you unpack the object pointed
> at by that tree entry to make sure it is a blob, you wouldn't be
> ab
Johannes Schindelin writes:
> On 2015-06-21 19:15, Junio C Hamano wrote:
> Michael Haggerty writes:
>> That's brilliant.
>>
>> Just to make sure I am reading you correctly, you mean the current
>> overall structure:
>>
>> [...]
>
> The way I read Michael's mail, he actually meant something dif
Junio C Hamano venit, vidit, dixit 19.06.2015 19:03:
> Michael J Gruber writes:
>
>> Now, since external diff runs on smudged blobs, it appears as if we
>> mixed cleaned and smudged blobs when feeding external diffs; whereas
>> really, we mix "worktree blobs" and "smudged repo blobs", which is ok
This is a re-casting of my previous filter-objects command but without
any of the filtering so it is now just "list-all-objects".
I have retained the "--verbose" option which outputs the same format as
the default "cat-file --batch-check" as it provides a useful performance
gain to filtering thoug
From: Charles Bailey
list-all-objects is a command to print the ids of all objects in the
object database of a repository. It is designed as a low overhead
interface for scripts that want to analyse all objects but don't require
the ordering implied by a revision walk.
It will list all objects,
Johannes Schindelin writes:
> How about I implement your suggestion tomorrow, then show the diff
> between the two versions and we can assess what looks to be simpler
> (i.e. more maintainable)?
I'm indifferent at this point, partly because as we agree that what
you have as long as it works is o
Johannes Löthberg writes:
>>But if we made some change to the transfer to push-to-receive-pack
>>so that this can also create HEAD that points at something, what
>>would the user say, instead of that earlier
>>
>> $ git clone git://site.xz/r
>>
>>to access this new namespace? Don't you have to b
On Sun, Jun 21, 2015 at 07:25:44PM +0100, Charles Bailey wrote:
> From: Charles Bailey
>
> diff --git a/parse-options.c b/parse-options.c
> index 80106c0..101b649 100644
> --- a/parse-options.c
> +++ b/parse-options.c
> @@ -180,6 +180,23 @@ static int get_value(struct parse_opt_ctx_t *p,
>
Hi Junio,
On 2015-06-21 19:15, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> But now that I'm writing this, a silly question occurs to me: Do we need
>> an overall option like this at all? If I demote all blob-integrity
>> checks to "ignore" via the mechanism that you have added, then sh
From: Charles Bailey
Fix the printf specification to treat 'integer' as the signed type that
it is and add a test that checks that we parse negative option
arguments.
Signed-off-by: Charles Bailey
---
t/t0040-parse-options.sh | 2 ++
test-parse-options.c | 2 +-
2 files changed, 3 insertio
From: Charles Bailey
The unsigned long option parsing (including 'k'/'m'/'g' suffix parsing)
is more widely applicable. Add support for OPT_MAGNITUDE to
parse-options.h and change pack-objects.c use this support.
The error behavior on parse errors follows that of OPT_INTEGER.
The name of the opt
This is a re-roll of the first two patches in my previous series which used to
include "filter-objects" which is now a separate topic.
[PATCH 1/2] Correct test-parse-options to handle negative ints
The first one has changed only in that I've moved the additional test to a more
logical place in th
Hi Junio,
On 2015-06-21 19:36, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
>> Hmm. I really do not like that kind of thinking, i.e. having to
>> duplicate, then modify data to be able to call the API, only to have
>> to modify the data back afterwards, and eventually having to
>> unall
Johannes Schindelin writes:
> Hmm. I really do not like that kind of thinking, i.e. having to
> duplicate, then modify data to be able to call the API, only to have
> to modify the data back afterwards, and eventually having to
> unallocate the data in all code paths. That feels just very inelega
Michael Haggerty writes:
> But now that I'm writing this, a silly question occurs to me: Do we need
> an overall option like this at all? If I demote all blob-integrity
> checks to "ignore" via the mechanism that you have added, then shouldn't
> fsck automatically detect that it doesn't have to o
Dear Git contributors & users,
in this time and age, it appears to be a good idea for Open Source Software
projects to have a document describing their code of conduct. Git for Windows
is no exception, so I opened a ticket:
https://github.com/git-for-windows/git/issues/200
In my opinion it
Hi Randall,
On 2015-06-21 07:09, Randall S. Becker wrote:
> On June 21, 2015 12:56 AM, Michael Haggerty wrote:
>
>> As for thinking of a shorter name for the option: assuming the blob integrity
>> checks can be turned on and off independently as described above, then I
>> think
>> it is reasonabl
On Sun, Jun 21, 2015 at 9:04 AM, Robert Dailey wrote:
> Upon inspection of the gitattributes documentation page here:
> https://git-scm.com/docs/gitattributes
>
> When comparing the documentation for 'text' with 'eol', I see the
> following missing explanations for 'eol':
>
> * eol
> * -eol
>
> Ma
Am 21.06.2015 um 15:59 schrieb Christoph Hellwig:
> On Sun, Jun 21, 2015 at 03:07:41PM +0200, Richard Weinberger wrote:
To me it seems like git was creating a new object and got interrupted
before fsync/fdatasync'ing it.
As the object was referenced before syncing the data to disk th
Upon inspection of the gitattributes documentation page here:
https://git-scm.com/docs/gitattributes
When comparing the documentation for 'text' with 'eol', I see the
following missing explanations for 'eol':
* eol
* -eol
Maybe the fact that these are missing means they are not valid to use.
The
Hi Junio,
On 2015-06-19 21:26, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
>> +static inline int substrcmp(const char *string, int len, const char *match)
>> +{
>> +int match_len = strlen(match);
>> +if (match_len != len)
>> +return -1;
>> +return memcmp(string,
On Sun, Jun 21, 2015 at 03:07:41PM +0200, Richard Weinberger wrote:
> >> To me it seems like git was creating a new object and got interrupted
> >> before fsync/fdatasync'ing it.
> >> As the object was referenced before syncing the data to disk the repo
> >> broke.
Git doesn't fsync by default, a
Hi Junio,
On 2015-06-19 21:13, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
>> +#define MSG_ID(id, msg_type) { STR(id), FSCK_##msg_type },
>> static struct {
>> +const char *id_string;
>> int msg_type;
>> } msg_id_info[FSCK_MSG_MAX + 1] = {
>> FOREACH_MSG_ID(MSG_ID)
>> -
> Subject: Re: [PATCH v5 07/10] send-email: reduce dependancies impact on
> parse_address_line
s/dependancies/dependencies/
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
Remi Lespinet writes:
> Helped-by: Remi Lespinet
???
At this point, it's realonable to consider that you're the main author
of the patch, but you could add a
Original-patch-by:
to credit the initial author.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list:
Hi Johannes,
[CC'ing linux-fsdevel and tytso]
Am 21.06.2015 um 14:28 schrieb Johannes Schindelin:
> Hi Richard,
>
> On 2015-06-20 21:40, Richard Weinberger wrote:
>
>> Yesterday our git server faced a power cut and a git repository broke.
>> The server is running a ext4 filesystem on top of Lin
Matthieu Moy writes:
> This is the last message I received in the series, and it's labeled
> 07/10. Is that normal?
No, it wasn't, I have seen no error message though... I'll take a look
at that later. I just sent 0008, 0009 and 0010 but I seems that I've pasted
the wrong line in the in-reply-t
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
---
git-send-email.perl | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git
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
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
Hi Richard,
On 2015-06-20 21:40, Richard Weinberger wrote:
> Yesterday our git server faced a power cut and a git repository broke.
> The server is running a ext4 filesystem on top of Linux 3.16 (stable
> from openSUSE) and git 2.1.4.
> We had a backup, so no data was lost but I really would like
Hi Michael,
On 2015-06-21 06:55, Michael Haggerty wrote:
> On 06/19/2015 10:53 PM, Junio C Hamano wrote:
>> Johannes Schindelin writes:
>>
>>> Can you think of a name for the option that is as short as `--quick`
>>> but means the same as `--connectivity-only`?
>>
>> No I can't. I think `--connec
This is the last message I received in the series, and it's labeled 07/10. Is
that normal?
> parse_address_line had not the same behavior whether the user had
had not -> did not have
> I've added the function in Git.pm as suggested. I've also added a test
> named t9000-addresses.sh (I've read t
65 matches
Mail list logo
