Hi
It looks like the perl regular expression multiline mode does not work with
'git grep'
for example, something like
git grep -P '(?s)foo.*?bar
will not match a file in the repo where it has something like
foo
bar
ie. split across two lines
Regards, Noel Grandin
--
To
The struct has been growing members whose malloced memory needs to be
freed. Do this with one helper function so that no malloced memory shall
be left unfreed.
Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net
---
builtin/merge.c | 5 +
gpg-interface.c | 12
This incorporates all remarks about the test coding guidelines and
rearranging the series.
Open questions:
- There was some debate about (optionally) verifying more than what
git-verify-{commit,tag} currently do, or going for a generic git-verify command.
The former would require both to be
In contrast to tag signatures, commit signatures are put into the
header, that is between the other header parts and commit messages.
Provide access to the commit content sans the signature, which is the
payload that is actually signed. Commit signature verification does the
parsing anyways, and
This mixes the git verify-commit tests in with the git show
--show-signature tests, to keep the tests more readable.
The tests already mix in the call show tests with the verify tests.
So in case of a test beakage, a '-v' run would be needed to reveal the
exact point of breakage anyway.
t7510 uses for loops in a subshell, which need to make sure that the test
returns with the appropriate error code from within the loop.
Restructure the loops as the usual chains with a single point of
exit 1 at the end of the loop to make this clearer.
Signed-off-by: Michael J Gruber
Commit signatures can be verified using git show -s --show-signature
or the %G? pretty format and parsing the output, which is well suited
for user inspection, but not for scripting.
Provide a command verify-commit which is analogous to verify-tag: It
returns 0 for good signatures and non-zero
Not sure what are the prerequisites for creating this bug, but it just
suddenly happened to me that I cannot create branches.
bad window path name .__branch_createo1d.desc.name_t
bad window path name .__branch_createo1d.desc.name_t
while executing
focus $old_focus
On Wed, Jun 18, 2014 at 4:36 PM, Jeff King p...@peff.net wrote:
When we get the author name and email either from an
existing commit or from the --author option, we create a
copy of the strings. We cannot just free() these copies,
since the same pointers may also be pointing to getenv()
On Mon, Jun 23, 2014 at 11:28 AM, Eric Sunshine sunsh...@sunshineco.com wrote:
On Wed, Jun 18, 2014 at 4:36 PM, Jeff King p...@peff.net wrote:
When we get the author name and email either from an
existing commit or from the --author option, we create a
copy of the strings. We cannot just
On Mon, Jun 23, 2014 at 5:33 AM, Erik Faye-Lund kusmab...@gmail.com wrote:
On Mon, Jun 23, 2014 at 11:28 AM, Eric Sunshine sunsh...@sunshineco.com
wrote:
On Wed, Jun 18, 2014 at 4:36 PM, Jeff King p...@peff.net wrote:
When we get the author name and email either from an
existing commit or
Hi,
[PATCH v3]: Added flag for NULL values that were causing segfaults in some
cases.
Added test-config for usage examples.
Minor changes and corrections. Refer to discussion thread[5] for more
details.
Thanks to Matthieu, Jeff and Junio for their valuable suggestions.
Currently `git_config()` uses a callback mechanism and file rereads for
config values. Due to this approach, it is not uncommon for the config
files to be parsed several times during the run of a git program, with
different callbacks picking out different variables useful to themselves.
Add a
Add different usage examples for 'git_config_get_string' and
`git_config_get_string_multi`. They will serve as documentation
on how to query for config values in a non-callback manner.
Signed-off-by: Tanay Abhra tanay...@gmail.com
---
.gitignore| 1 +
Makefile | 1 +
test-config.c |
The string-list API has STRING_LIST_INIT_* macros to be used
to define variables with initialisers, but lacks functions
to initialise an uninitialised piece of memory to be used as
a string-list at the run-time.
Introduce string_list_init_{dup,nodup}() functions for that.
Signed-off-by: Tanay
On Thu, Jun 19, 2014 at 5:28 PM, Jeff King p...@peff.net wrote:
This is shorter, harder to get wrong, and more clearly
captures the intent.
Signed-off-by: Jeff King p...@peff.net
---
I wondered if there was a reason to avoid this (because we are in
setup_git_env, which can potentially be
Use git_config_get_string instead of git_config to take advantage of
the config hash-table api which provides a cleaner control flow.
Signed-off-by: Tanay Abhra tanay...@gmail.com
---
pager.c | 44 +++-
1 file changed, 15 insertions(+), 29 deletions(-)
Use git_config_get_string instead of git_config to take advantage of
the config hash-table api which provides a cleaner control flow.
Signed-off-by: Tanay Abhra tanay...@gmail.com
---
notes.c | 20 ++--
1 file changed, 6 insertions(+), 14 deletions(-)
diff --git a/notes.c
Use git_config_get_string instead of git_config to take advantage of
the config hash-table api which provides a cleaner control flow.
Signed-off-by: Tanay Abhra tanay...@gmail.com
---
notes-utils.c | 31 +++
1 file changed, 15 insertions(+), 16 deletions(-)
diff
Use git_config_get_string instead of git_config to take advantage of
the config hash-table api which provides a cleaner control flow.
Signed-off-by: Tanay Abhra tanay...@gmail.com
---
imap-send.c | 68 ++---
1 file changed, 29
Use git_config_get_string instead of git_config to take advantage of
the config hash-table api which provides a cleaner control flow.
Signed-off-by: Tanay Abhra tanay...@gmail.com
---
branch.c | 24
1 file changed, 8 insertions(+), 16 deletions(-)
diff --git a/branch.c
Use git_config_get_string instead of git_config to take advantage of
the config hash-table api which provides a cleaner control flow.
Signed-off-by: Tanay Abhra tanay...@gmail.com
---
alias.c | 28 ++--
1 file changed, 10 insertions(+), 18 deletions(-)
diff --git
On Sun, Jun 22, 2014 at 12:51 PM, Michael S. Tsirkin m...@redhat.com wrote:
Why did it auto-pack twice in a single pull?
None of the changes applied are very large.
Guess: auto-packing was started in background, did not
complete in time, and was restarted for the second time?
If true, some
W dniu 2014-06-20 23:17, Nico Williams pisze:
On Fri, Jun 20, 2014 at 1:53 AM, Junio C Hamano gits...@pobox.com wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
[...]
Hmph, but that obviously will become very expensive to compute as
project grows.
That's the main reason to like
Tanay Abhra tanay...@gmail.com writes:
+/* for NULL values, 'util' for each `string_list_item` is flagged as 1 */
It's a void *, so just saying that it is flagged as 1 does not say how
it's encoded. How about ... is an 'int *' pointing to the value 1.
And actually, you can save one malloc by
On Thu, Jun 19, 2014 at 7:27 PM, Thomas Braun
thomas.br...@virtuell-zuhause.de wrote:
@@ -2721,6 +2721,11 @@ int diff_populate_filespec(struct diff_filespec *s,
unsigned int flags)
}
if (size_only)
return 0;
+ if ((flags
On 2014-06-23 12.11, Tanay Abhra wrote:
The string-list API has STRING_LIST_INIT_* macros to be used
to define variables with initialisers, but lacks functions
to initialise an uninitialised piece of memory to be used as
a string-list at the run-time.
Introduce string_list_init_{dup,nodup}()
On 06/23/2014 05:36 AM, Torsten Bögershausen wrote:
If we look at the definition below:
struct string_list {
struct string_list_item *items;
unsigned int nr, alloc;
unsigned int strdup_strings:1;
compare_strings_fn cmp; /* NULL uses strcmp() */
I think a simple
Stephen Kelly wrote:
But I agree that this is suboptimal for your workflow. What about adding
a Visualize These Changes In The Submodule menu entry for the context
menu of a change in gitk just like the one git gui already has?
Can you tell me how to find and try that out in git gui?
In
On 23/06/14 11:11, Tanay Abhra wrote:
[snip]
diff --git a/config.c b/config.c
index a1aef1c..6200f36 100644
--- a/config.c
+++ b/config.c
@@ -9,6 +9,8 @@
#include exec_cmd.h
#include strbuf.h
#include quote.h
+#include hashmap.h
+#include string-list.h
struct config_source {
Hi,
On Sun, 22 Jun 2014, Fabian Ruch wrote:
On 06/20/2014 03:40 PM, Michael Haggerty wrote:
On 06/19/2014 05:28 AM, Fabian Ruch wrote:
`pick_one` and `pick_one_preserving_merges` are wrappers around
`cherry-pick` in `rebase --interactive`. They take the hash of a commit
and build a
On 06/23/2014 07:57 AM, Ramsay Jones wrote:
On 23/06/14 11:11, Tanay Abhra wrote:
diff --git a/config.c b/config.c
index a1aef1c..6200f36 100644
--- a/config.c
+++ b/config.c
@@ -9,6 +9,8 @@
#include exec_cmd.h
#include strbuf.h
#include quote.h
+#include hashmap.h
+#include
Am 22.06.2014 17:45, schrieb Stephen Kelly:
Jens Lehmann wrote:
Am 22.06.2014 16:09, schrieb Stephen Kelly:
But I agree that this is suboptimal for your workflow. What about adding
a Visualize These Changes In The Submodule menu entry for the context
menu of a change in gitk just like the
On Sun, Jun 22, 2014 at 09:26:44PM -0400, Eric Sunshine wrote:
+ if (line == eol)
+ return NULL;
+ next = *eol ? eol + 1 : NULL;
+
+ if (eol - line key_len
+ !strncmp(line, key, key_len)
+
Jens Lehmann wrote:
Am 22.06.2014 17:45, schrieb Stephen Kelly:
Jens Lehmann wrote:
Am 22.06.2014 16:09, schrieb Stephen Kelly:
But I agree that this is suboptimal for your workflow. What about adding
a Visualize These Changes In The Submodule menu entry for the context
menu of a change
Jens Lehmann wrote:
But I agree that this is suboptimal for your workflow. What about adding
a Visualize These Changes In The Submodule menu entry for the context
menu of a change in gitk just like the one git gui already has? Then the
user could examine the merges in more detail if he wants.
On Mon, Jun 23, 2014 at 05:28:14AM -0400, Eric Sunshine wrote:
static void determine_author_info(struct strbuf *author_ident)
{
char *name, *email, *date;
struct ident_split author;
- struct strbuf date_buf = STRBUF_INIT;
+ struct strbuf name_buf =
On Mon, Jun 23, 2014 at 11:33:56AM +0200, Erik Faye-Lund wrote:
This approach has the added benefit of fixing the case where getenv
uses a static buffer, like POSIX allows.
Good point. I knew we could invalidate the pointer if setenv() was called, but
I didn't know that another getenv() could
On Mon, Jun 23, 2014 at 09:05:46AM +0200, Michael J Gruber wrote:
This incorporates all remarks about the test coding guidelines and
rearranging the series.
Open questions:
- There was some debate about (optionally) verifying more than what
git-verify-{commit,tag} currently do, or going
On Sun, Jun 22, 2014 at 01:00:53PM -0600, Cox, Michael wrote:
I like the idea of recognizing environment variable syntax in config files,
at least a feature that would allow *some* config variables to be specified
as accepting environment variable syntax. It adds a lot of flexibility,
but
Torsten Bögershausen tbo...@web.de writes:
No, it hadn't, under my Linux box.
(And I had a .gittatributes file on the Mac OS box, which I forgot about.
OK, that explains the difference; thanks for double-checking.
Files with mixed LF CRLF in the repo are not changed by Git, when the
Stephen Kelly wrote:
Failing all of that, can you show me where the code would need to be
changed to list all of the newly-reachable commits? I can keep a commit
for myself then.
I see that gitk is showing the output of git diff --submodule, similar to
git submodule summary.
Assuming that
Jeff King p...@peff.net writes:
... Recently we discussed supporting environment
variables in expansions of path-oriented config variables. So something
like:
[include]
path = $GIT_DIR/../.gitremotes
would do what you want. We'd have to give some thought on what that
should do when
Noel Grandin noelgran...@gmail.com writes:
It looks like the perl regular expression multiline mode does not work with
'git grep'
Yes, and deliberately so, to avoid having to think about things like
how would a multi-line match interact with 'grep -n'?
We behave as if we feed each line of
Jeff King p...@peff.net writes:
On Mon, Jun 23, 2014 at 09:05:46AM +0200, Michael J Gruber wrote:
This incorporates all remarks about the test coding guidelines and
rearranging the series.
Open questions:
- There was some debate about (optionally) verifying more than what
Stephen Kelly wrote:
I see that gitk is showing the output of git diff --submodule, similar to
git submodule summary.
Assuming that is not going to be changed, maybe I can hack
parseblobdiffline locally. I have not really tried to read of write tcl
code before though, so I'd still prefer a
Jeff King p...@peff.net writes:
diff --git a/builtin/clone.c b/builtin/clone.c
index b12989d..a5b2d9d 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -703,9 +703,12 @@ static void write_refspec_config(const char*
src_ref_prefix,
Since its inception at 7e29b825 (Add column layout skeleton and
git-column, 2012-04-21), it seems that git_column_config() asked for
a specific $command did not give column.$command.* any precedence
over the fallback value defined for column.ui.*. If you happen to
have column.ui.* earlier than
Am 23.06.2014 14:18, schrieb Duy Nguyen:
On Thu, Jun 19, 2014 at 7:27 PM, Thomas Braun
thomas.br...@virtuell-zuhause.de wrote:
@@ -2721,6 +2721,11 @@ int diff_populate_filespec(struct diff_filespec *s,
unsigned int flags)
}
if (size_only)
Am 23.06.2014 20:24, schrieb Stephen Kelly:
Stephen Kelly wrote:
I see that gitk is showing the output of git diff --submodule, similar to
git submodule summary.
Right, and for your use case --submodule would have to learn a
different value in addition to 'log' and 'short'. And the default
On Mon, Jun 23, 2014 at 11:50:06AM -0700, Junio C Hamano wrote:
I was re-reading this and noticed another possible bug.
builtin/clone.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/clone.c b/builtin/clone.c
index b12989d..df659dd 100644
---
On Mon, Jun 23, 2014 at 10:52:38AM -0700, Junio C Hamano wrote:
The one thing that does give me pause is that we do not seem to have any
way of accessing mergetag signatures. We should perhaps stop and think
for a second about how we might expose those (and whether it would fit
into the
Jeff King p...@peff.net writes:
On Mon, Jun 23, 2014 at 10:52:38AM -0700, Junio C Hamano wrote:
The one thing that does give me pause is that we do not seem to have any
way of accessing mergetag signatures. We should perhaps stop and think
for a second about how we might expose those (and
31b808a0 (clone --single: limit the fetch refspec to fetched branch,
2012-09-20) tried to see if the given branch to follow is actually
a tag at the remote repository by checking with refs/tags/ but it
incorrectly used strstr(3); it is actively wrong to treat a branch
refs/heads/refs/tags/foo and
Jeff King p...@peff.net writes:
diff --git a/connect.c b/connect.c
index 94a6650..37ff018 100644
--- a/connect.c
+++ b/connect.c
@@ -140,12 +141,12 @@ struct ref **get_remote_heads(int in, char *src_buf,
size_t src_len,
if (!len)
break;
-
Tanay Abhra wrote:
alias.c | 28 ++--
1 file changed, 10 insertions(+), 18 deletions(-)
What commit are these patches against? Are they a continuation
of the git config cache special querying api series?
Thanks,
Jonathan
--
To unsubscribe from this list: send the
Eric Sunshine sunsh...@sunshineco.com writes:
On Thu, Jun 19, 2014 at 5:28 PM, Jeff King p...@peff.net wrote:
This is shorter, harder to get wrong, and more clearly
captures the intent.
Signed-off-by: Jeff King p...@peff.net
---
I wondered if there was a reason to avoid this (because we
Michael J Gruber g...@drmicha.warpmail.net writes:
test_expect_success GPG 'detect fudged signature' '
git cat-file commit master raw
sed -e s/seventh/7th forged/ raw forged1
git hash-object -w -t commit forged1 forged1.commit
+ ! git verify-commit $(cat
Junio C Hamano wrote:
* pb/trim-trailing-spaces (2014-06-13) 1 commit
(merged to 'next' on 2014-06-20 at 6985153)
+ t0008: do not depend on 'echo' handling backslashes specially
Will merge to 'master'.
Without this patch, 'master' doesn't pass t0008 for me with bash as
/bin/sh. The
Tanay Abhra tanay...@gmail.com writes:
+static int hashmap_initialized;
+ ...
+static struct hashmap *get_config_cache(void)
+{
+ static struct hashmap config_cache;
+ if (!hashmap_initialized) {
+ config_cache_init(config_cache);
+ hashmap_initialized = 1;
On Mon, Jun 23, 2014 at 4:13 PM, Jonathan Nieder jrnie...@gmail.com wrote:
Junio C Hamano wrote:
* pb/trim-trailing-spaces (2014-06-13) 1 commit
(merged to 'next' on 2014-06-20 at 6985153)
+ t0008: do not depend on 'echo' handling backslashes specially
Will merge to 'master'.
Without
Ramsay Jones ram...@ramsay1.demon.co.uk writes:
+static struct hashmap *get_config_cache(void)
+{
+static struct hashmap config_cache;
+if (!hashmap_initialized) {
+config_cache_init(config_cache);
+hashmap_initialized = 1;
+
I was trying to setup a git client to deal with our version of a
triangular workflow and found that there where no configuration
directives which supported our use case.
Developers create and commit to branches named dev/user/TOPIC
(Branch permissions are handled by Gitolite). If the topic is
--
Vážený pane / paní,
Potřebujete naléhavou nabídku úvěr splatit své účty, nebo nastavení
obchodní? Už jste hledali hotovost investovat nebo rozšířit své
podnikání? Nebo potřebujete hotovostní úvěry pro různé účely a jste
unaveni hledám úvěrů a hypoték? Byl jste odmítli neustále vaše bank a
I just encountered a situation where a merge was made, with no
apparent changes in files (ie no log), but the result was that some
files were deleted.
person A adds some files
person B adds some files from the same point
person B commits and pushes.
person A commits -- now merge is required
a
On 6/24/2014 4:08 AM, Jonathan Nieder wrote:
Tanay Abhra wrote:
alias.c | 28 ++--
1 file changed, 10 insertions(+), 18 deletions(-)
What commit are these patches against? Are they a continuation
of the git config cache special querying api series?
My fault, I
(thinking more about this, digesting Jonathan's response...)
The Illumos repo, like OpenSolaris before it, and Solaris itself at
Sun (and now at Oracle) requires that fixes be broken down into small
commits, with related fixes, tests, and docs changes all typically in
separate commits, but all
Since the setup requires the GPG prerequisite, it doesn't make much
sense to try and run any tests without it. So rather than using a
prereq on each individual test and possibly forgetting it on new ones
(as just happened), skip the entire file if GPG isn't found.
Signed-off-by: Brian Gernhardt
When many branches contain the commit, they used to be shown in
the form A, B and many more, where A, B can be master of current
HEAD. But there are more which might be interesting to always know about.
For example, origin/master.
The new option, visiblerefs, is stored in ~/.gitk. It contains a
69 matches
Mail list logo
