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
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
(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 pus
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 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 fe
--
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
jiný
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//TOPIC
(Branch permissions are handled by Gitolite). If the topic is
prefixe
Ramsay Jones writes:
>> +static struct hashmap *get_config_cache(void)
>> +{
>> +static struct hashmap config_cache;
>> +if (!hashmap_initialized) {
>> +config_cache_init(&config_cache);
>> +hashmap_initialized = 1;
>> +git_config(config_cache_callback,
On Mon, Jun 23, 2014 at 4:13 PM, Jonathan Nieder 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 this
Tanay Abhra 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;
I find t
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
Michael J Gruber 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 forged1.commit) &
Eric Sunshine writes:
> On Thu, Jun 19, 2014 at 5:28 PM, Jeff King wrote:
>> This is shorter, harder to get wrong, and more clearly
>> captures the intent.
>>
>> Signed-off-by: Jeff King
>> ---
>> I wondered if there was a reason to avoid this (because we are in
>> setup_git_env, which can pote
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 th
Jeff King 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;
>
> - i
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/fo
Jeff King 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 wh
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
> > int
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
> --- a/builti
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 defa
Am 23.06.2014 14:18, schrieb Duy Nguyen:
> On Thu, Jun 19, 2014 at 7:27 PM, Thomas Braun
> wrote:
>>> @@ -2721,6 +2721,11 @@ int diff_populate_filespec(struct diff_filespec *s,
>>> unsigned int flags)
>>> }
>>> if (size_only)
>>> return 0;
>>> +
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
Jeff King 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,
> strbuf_addf(&value, "+%
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 pre
Jeff King 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
>> git-verify-{com
Noel Grandin 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 the contents one lin
Jeff King 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 $GIT_D
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
Torsten Bögershausen 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
> checkout out
> o
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
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 goi
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 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_b
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 w
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
>>>
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)
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
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 "hash
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 b
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"
>
> stru
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 gu
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
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 Thu, Jun 19, 2014 at 7:27 PM, Thomas Braun
wrote:
>> @@ -2721,6 +2721,11 @@ int diff_populate_filespec(struct diff_filespec *s,
>> unsigned int flags)
>> }
>> if (size_only)
>> return 0;
>> + if ((flags & DIFF_POPULATE_IS_BINARY) &&
Tanay Abhra 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 encoding the valu
W dniu 2014-06-20 23:17, Nico Williams pisze:
On Fri, Jun 20, 2014 at 1:53 AM, Junio C Hamano wrote:
Michael Haggerty writes:
[...]
Hmph, but that obviously will become very expensive to compute as
project grows.
That's the main reason to like Fossil's approach (namely, the use of
SQL, sp
On Sun, Jun 22, 2014 at 12:51 PM, Michael S. Tsirkin 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 kind of loc
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
---
branch.c | 24
1 file changed, 8 insertions(+), 16 deletions(-)
diff --git a/branch.c b/branch.c
index 66
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
---
alias.c | 28 ++--
1 file changed, 10 insertions(+), 18 deletions(-)
diff --git a/alias.c b/alias.c
index
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
---
imap-send.c | 68 ++---
1 file changed, 29 insertions(+), 39 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
---
pager.c | 44 +++-
1 file changed, 15 insertions(+), 29 deletions(-)
diff --git a/pager.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
---
notes.c | 20 ++--
1 file changed, 6 insertions(+), 14 deletions(-)
diff --git a/notes.c b/notes.c
index 5fe691d..
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
---
notes-utils.c | 31 +++
1 file changed, 15 insertions(+), 16 deletions(-)
diff --git a/notes-utils.c b
On Thu, Jun 19, 2014 at 5:28 PM, Jeff King wrote:
> This is shorter, harder to get wrong, and more clearly
> captures the intent.
>
> Signed-off-by: Jeff King
> ---
> I wondered if there was a reason to avoid this (because we are in
> setup_git_env, which can potentially be called by git_pathdup)
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
---
.gitignore| 1 +
Makefile | 1 +
test-config.c | 93 +
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 Abhr
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 hash
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.
[
On Mon, Jun 23, 2014 at 5:33 AM, Erik Faye-Lund wrote:
> On Mon, Jun 23, 2014 at 11:28 AM, Eric Sunshine
> wrote:
>> On Wed, Jun 18, 2014 at 4:36 PM, Jeff King wrote:
>>> When we get the author name and email either from an
>>> existing commit or from the "--author" option, we create a
>>> copy
On Mon, Jun 23, 2014 at 11:28 AM, Eric Sunshine wrote:
> On Wed, Jun 18, 2014 at 4:36 PM, Jeff King 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
On Wed, Jun 18, 2014 at 4:36 PM, Jeff King 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()
> storage whic
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"
(
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.
A
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
---
t
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-
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 c
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
---
builtin/merge.c | 5 +
gpg-interface.c | 12
gpg-interface.h | 1 +
pretty.c
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 change
68 matches
Mail list logo
