Remi Lespinet remi.lespi...@ensimag.grenoble-inp.fr writes:
Helped-by: Remi Lespinet remi.lespi...@ensimag.grenoble-inp.fr
???
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.
--
Hi Junio,
On 2015-06-19 21:13, Junio C Hamano wrote:
Johannes Schindelin johannes.schinde...@gmx.de 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] = {
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.
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 reasonable to
Hi Michael,
On 2015-06-21 06:55, Michael Haggerty wrote:
On 06/19/2015 10:53 PM, Junio C Hamano wrote:
Johannes Schindelin johannes.schinde...@gmx.de 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
Matthieu Moy matthieu@grenoble-inp.fr 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
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 Linux 3.16
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 the repo
Michael Haggerty mhag...@alum.mit.edu 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
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
On Sun, Jun 21, 2015 at 9:04 AM, Robert Dailey rcdailey.li...@gmail.com 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':
*
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
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
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
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, and because
Hi Junio,
On 2015-06-19 21:26, Junio C Hamano wrote:
Johannes Schindelin johannes.schinde...@gmx.de 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
Johannes Schindelin johannes.schinde...@gmx.de 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
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 to
Do not consider quote inside a recipient name as character when
they are not escaped. This interprets:
Jane Doe j...@example.com
as:
Jane Doe j...@example.com
instead of:
Jane\ \Doe j...@example.com
Signed-off-by: Remi Lespinet remi.lespi...@ensimag.grenoble-inp.fr
---
On Sun, Jun 21, 2015 at 1:51 PM, Karthik Nayak karthik@gmail.com wrote:
On Mon, Jun 22, 2015 at 2:15 AM, Karthik Nayak karthik@gmail.com 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 :
On Sun, Jun 21, 2015 at 1:48 PM, Karthik Nayak karthik@gmail.com 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
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/
On Sun, Jun 21, 2015 at 4:14 PM, brian m. carlson
sand...@crustytoothpaste.net 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
On Sun, Jun 21, 2015 at 1:48 PM, Karthik Nayak karthik@gmail.com 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
On Fri, Jun 19, 2015 at 6:35 AM, Johannes Schindelin
johannes.schinde...@gmx.de 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 karthik@gmail.com 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 =
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 command
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 is,
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:
Junio C Hamano gits...@pobox.com 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
Johannes Schindelin johannes.schinde...@gmx.de 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
Junio C Hamano venit, vidit, dixit 19.06.2015 19:03:
Michael J Gruber g...@drmicha.warpmail.net 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
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.
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
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
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
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:
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 sand...@crustytoothpaste.net
---
t/t7030-verify-tag.sh | 84 +++
1 file changed, 84 insertions(+)
create mode 100755
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
On Mon, Jun 22, 2015 at 2:15 AM, Karthik Nayak karthik@gmail.com 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:
On Sun, Jun 21, 2015 at 07:25:44PM +0100, Charles Bailey wrote:
From: Charles Bailey cbaile...@bloomberg.net
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
Hi Junio,
On 2015-06-21 19:15, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu 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
Johannes Schindelin johannes.schinde...@gmx.de writes:
On 2015-06-21 19:15, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu 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,
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 p...@peff.net
Mentored-by: Christian Couder christian.cou...@gmail.com
Mentored-by:
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 p...@peff.net
Mentored-by: Christian Couder
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 p...@peff.net
Mentored-by: Christian Couder
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 p...@peff.net
Mentored-by: Christian
From: Charles Bailey cbaile...@bloomberg.net
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 cbaile...@bloomberg.net
---
t/t0040-parse-options.sh | 2 ++
From: Charles Bailey cbaile...@bloomberg.net
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
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 the
Johannes Löthberg johan...@kyriasis.com 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
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 though
From: Charles Bailey cbaile...@bloomberg.net
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
'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
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 christian.cou...@gmail.com
Mentored-by: Matthieu Moy matthieu@grenoble-inp.fr
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 christian.cou...@gmail.com
Mentored-by: Matthieu Moy
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.
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 christian.cou...@gmail.com
Mentored-by: Matthieu Moy
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.
19th International Conference on Circuits, Systems, Communications and
Computers, (CSCC 2015), Zakynthos Island, Greece, July 16-20, 2015
jointly with INASE.org conferences
www.cscc.co and www.inase.org
*** 44 ISI/SCI/SCOPUS (with Impact Factor
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 the
63 matches
Mail list logo
