Tanay Abhra writes:
> On 7/25/2014 2:52 AM, Ramsay Jones wrote:
>> However, I think it you could create a list of > entry, string-list index> pairs in the config_set and use that to do
>> the iteration. A bit ugly, but it should work.
>
> Thanks for the advice, that is exactly what I am doing.
I
Junio C Hamano venit, vidit, dixit 24.07.2014 23:30:
> Duy Nguyen writes:
>
>> On Wed, Jul 23, 2014 at 8:48 PM, Michael J Gruber
>> wrote:
>>> Nguyễn Thái Ngọc Duy venit, vidit, dixit 23.07.2014 13:43:
+ if (advice_checkout_to)
+ die(_("%s is already checked out at %s.\
Junio C Hamano venit, vidit, dixit 24.07.2014 19:19:
> Michael J Gruber writes:
>
>> Steffen Nurpmeso venit, vidit, dixit 24.07.2014 15:29:
>>> Hello (again, psst, after a long time),
>>>
>>> it happened yesterday that i needed to do
>>>
>>> $ git diff HEAD:FILE COMMIT:SAME-FILE |
>>> > (
On 07/25/2014 11:10 AM, Sheldon Els wrote:
> It is just a shell script yes, and a man page to make things a bit
> more discoverable for "git help feature-branch".
>
> The brew command comes from homebrew, a popular OSX package manager.
> My platform of choice.
You might want to at least add "thes
It is just a shell script yes, and a man page to make things a bit
more discoverable for "git help feature-branch".
The brew command comes from homebrew, a popular OSX package manager.
My platform of choice.
Perhaps I can get support for an easy install for your platform. Do
you think a Makefile
On 07/25/2014 03:45 AM, Sheldon Els wrote:
> Hi
>
> A small tool I wrote that is useful for some workflows. I thought it'd
> be worth sharing. https://github.com/sheldon/git-feature-branch/
As far as I can tell it's just a shell script; does it really need
installation instructions, and if so can
On 7/25/2014 2:52 AM, Ramsay Jones wrote:
> On 24/07/14 20:54, Junio C Hamano wrote:
>> Tanay Abhra writes:
>>
>>> If we take the easy way out, fixing UI mistakes would be easier,
>>> just replace git_config_cache() with git_config_raw() for such cases.
>>
>> I do not think that would fly well.
Hi all,
I'm a developer of Seafile (https://github.com/haiwen/seafile) project.
We borrowed some source code from the Git project and are going to
license our code in GPLv2. But one concern is that GPLv2 is not compatible
with the Openssl license. It requires an exception.
As far as I can see, Git
"Philip Oakley" writes:
>> which still makes me feel hesitant to promote this
>> document without updating its contents, though.
>>
>
> I hadn't viewed it as a 'promotion', rather it was simply ensuring
> access to the guide via the help system, instead of leaving it
> somewhat hidden.
Stale or
From: "Junio C Hamano"
Sent: Wednesday, July 23, 2014 7:10 PM
"Philip Oakley" writes:
* po/everyday-doc (2014-01-27) 1 commit
- Make 'git help everyday' work
This may make the said command to emit something, but the source is
not meant to be formatted into a manual pages to begin with, and
a
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
We would need to start slowing down to prepare for -rc0 preview at
the end of this week and then feature freeze. Some topics that
joined 'next'
Hi
A small tool I wrote that is useful for some workflows. I thought it'd
be worth sharing. https://github.com/sheldon/git-feature-branch/
Sheldon
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http:/
Johannes Sixt writes:
>> @@ -177,7 +175,7 @@ test_expect_success 'detect copies' '
>> level=$(git diff-tree -r -C --find-copies-harder HEAD | sed 1d | cut -f1 |
>> cut -d" " -f5 | sed "s/C0*//") &&
>> test -n "$level" && test "$level" -gt 0 && test "$level" -lt 98 &&
>> src=$(git diff-tree
Duy Nguyen writes:
> On Wed, Jul 23, 2014 at 8:48 PM, Michael J Gruber
> wrote:
>> Nguyễn Thái Ngọc Duy venit, vidit, dixit 23.07.2014 13:43:
>>> + if (advice_checkout_to)
>>> + die(_("%s is already checked out at %s.\n"
>>> + "Either use --detach or -b together
On 24/07/14 20:54, Junio C Hamano wrote:
> Tanay Abhra writes:
>
>> If we take the easy way out, fixing UI mistakes would be easier,
>> just replace git_config_cache() with git_config_raw() for such cases.
>
> I do not think that would fly well.
>
> The kind of "let's migrate funcname users to
Jeff King writes:
> Since Stefan has recently started feeding git builds to coverity, I
> spent a few minutes poking through the results. There are tons of false
> positives, so there is some work to be done there with tweaking our
> coverity models. But there are some real issues, too. Here are
Matthieu Moy writes:
> As a side effect, I guess Junio will apply this on top of master so the
> string interning API will be available immediately at the tip of the
> branch.
Thanks for a heads-up. The two-patch series does not use the
interning, but does use string_list_init(), which is recen
Tanay Abhra writes:
> If we take the easy way out, fixing UI mistakes would be easier,
> just replace git_config_cache() with git_config_raw() for such cases.
I do not think that would fly well.
The kind of "let's migrate funcname users to xfuncname while still
supporting the old uses" change w
On 7/25/2014 12:50 AM, Junio C Hamano wrote:
> Matthieu Moy writes:
>
>> Tanay Abhra writes:
>>
>>> For core the only test failing was xfuncname vs funcname,
>>
>> Being a little pessimistic: there may be other cases where the hashtable
>> magically gives the right order for existing tests, bu
Matthieu Moy writes:
> Tanay Abhra writes:
>
>> For core the only test failing was xfuncname vs funcname,
>
> Being a little pessimistic: there may be other cases where the hashtable
> magically gives the right order for existing tests, but that would fail
> for untested use-cases.
>
> But I can
On Thu, Jul 24, 2014 at 08:47:45PM +0200, Matthieu Moy wrote:
> Tanay Abhra writes:
> > Also can you name any third party apps that use the git_config()
> > system on which I can test the patches.
>
> There are probably tons of. I can think of git-multimail.
CGit [1] is probably the only one tha
Tanay Abhra writes:
> On 7/25/2014 12:01 AM, Junio C Hamano wrote:
>> Tanay Abhra writes:
>>
>>> On 7/24/2014 3:19 AM, Junio C Hamano wrote:
Tanay Abhra writes:
> If a callback returns a negative value to `git_config*()` family,
> they call `die()` while printing the line num
Tanay Abhra writes:
> For core the only test failing was xfuncname vs funcname,
Being a little pessimistic: there may be other cases where the hashtable
magically gives the right order for existing tests, but that would fail
for untested use-cases.
But I can't think of any such case.
> so the
Am 23.07.2014 23:28, schrieb Christoph Bonitz:
> The scenario in the rename test makes unnecessary assumptions about
> which file git file-tree will detect as a source for a copy-operations.
> Furthermore, copy detection is not tested by checking the resulting
> perforce revision history via p4 fil
Tanay Abhra writes:
> +int git_configset_get_string_const(struct config_set *cs, const char *key,
> const char **dest)
> +{
> + const char *value;
> + if (!git_configset_get_value(cs, key, &value))
> + return git_config_string(dest, key, value);
> + else
> + r
On 7/25/2014 12:01 AM, Junio C Hamano wrote:
> Tanay Abhra writes:
>
>> On 7/24/2014 3:19 AM, Junio C Hamano wrote:
>>> Tanay Abhra writes:
>>>
If a callback returns a negative value to `git_config*()` family,
they call `die()` while printing the line number and the file name.
C
>
> I haven't formed a firm opinion whether preserving the order is
> necessary at git_config() iteration level yet. If the only in-core
> user that will be broken by not doing so is xfuncname vs funcname,
> it may not be too bad, but it will constrain us in the future, which
> is a lot bigger p
Tanay Abhra writes:
> On 7/24/2014 3:19 AM, Junio C Hamano wrote:
>> Tanay Abhra writes:
>>
>>> If a callback returns a negative value to `git_config*()` family,
>>> they call `die()` while printing the line number and the file name.
>>> Currently the printed line number is off by one, thus pri
Junio C Hamano writes:
> Duy Nguyen writes:
>
>> On Thu, Jul 24, 2014 at 4:16 AM, Junio C Hamano wrote:
+ if (strbuf_read_file(&sb, path.buf, 0) <= 0 ||
+ !skip_prefix(sb.buf, "ref:", &start))
+ goto done;
while (isspace(*start))
The latest maintenance release Git v2.0.3 is now available at
the usual places. Hopefully it would be the final maintenance
release for the v2.0 series.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/
The following public repositories all have a copy of the 'v2.0.3'
Michael J Gruber writes:
> Steffen Nurpmeso venit, vidit, dixit 24.07.2014 15:29:
>> Hello (again, psst, after a long time),
>>
>> it happened yesterday that i needed to do
>>
>> $ git diff HEAD:FILE COMMIT:SAME-FILE |
>> > (cd src && git apply -)
>> ...
>
> Ah little more context woul
Matthieu Moy writes:
> Junio C Hamano writes:
>
>> in my ~/.gitconfig and then for a particular project I wanted to use
>> a custom pattern in its .git/config but it was sufficient to define
>> the pattern without using extended regexp, I would be tempted to say
>>
>> diff.foo.funcname "Win
Matthieu Moy writes:
> Tanay Abhra writes:
>
> + test_when_finished "mv .git/config.old .git/config" &&
> + echo "[alias]\n br" >.git/config &&
>>>
>>> Is the use of \n portable?
>>>
>>
>> Yes, you are right, will replace with printf in the next patch.
>
> ... or a cat >.git/config <<\
Duy Nguyen writes:
> On Thu, Jul 24, 2014 at 4:16 AM, Junio C Hamano wrote:
>>> + if (strbuf_read_file(&sb, path.buf, 0) <= 0 ||
>>> + !skip_prefix(sb.buf, "ref:", &start))
>>> + goto done;
>>> while (isspace(*start))
>>> start++;
>>> end = start
When a client certificate is required to connect to a Subversion repository,
the certificate location and password may be stored in Subversion config
directory.
Commands like "git svn init/fetch/dcommit" do not prompt for client
certificate/password
if the location is set in SVN config file, but
Tanay Abhra writes:
> On 7/24/2014 9:09 PM, Matthieu Moy wrote:
>> Tanay Abhra writes:
>>
>>> I am attaching the v12 with two new functions git_configset_get_string() &
>>> git_configset_get_string_const().
>>
>> Didn't you intend to change git_config_get_string to let it die in case
>> of err
On 7/24/2014 9:09 PM, Matthieu Moy wrote:
> Tanay Abhra writes:
>
>> I am attaching the v12 with two new functions git_configset_get_string() &
>> git_configset_get_string_const().
>
> Didn't you intend to change git_config_get_string to let it die in case
> of error instead of returning an er
Tanay Abhra writes:
> I am attaching the v12 with two new functions git_configset_get_string() &
> git_configset_get_string_const().
Didn't you intend to change git_config_get_string to let it die in case
of error instead of returning an error code?
--
Matthieu Moy
http://www-verimag.imag.fr/~
Expose the `config_set` C API as a set of simple commands in order to
facilitate testing. Add tests for the `config_set` API as well as for
`git_config_get_*()` family for the usual config files.
Signed-off-by: Matthieu Moy
Signed-off-by: Tanay Abhra
---
.gitignore| 1 +
Makefile
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 `con
>
> Are you done with the original series, or do you still want to fix
> the const-ness issue with the string pointer before working on
> follow-up topics like this one?
>
I am attaching the v12 with two new functions git_configset_get_string() &
git_configset_get_string_const().
Diff between v1
Hello (again, psst, after a long time),
it happened yesterday that i needed to do
$ git diff HEAD:FILE COMMIT:SAME-FILE |
> (cd src && git apply -)
but found that didn't work with v2.0.0 (silently succeeds?, doing
nothing). It works without the subshell and the cd(1); i had to
use `(cd
Steffen Nurpmeso venit, vidit, dixit 24.07.2014 15:29:
> Hello (again, psst, after a long time),
>
> it happened yesterday that i needed to do
>
> $ git diff HEAD:FILE COMMIT:SAME-FILE |
> > (cd src && git apply -)
>
> but found that didn't work with v2.0.0 (silently succeeds?, doing
>
Tanay Abhra writes:
+ test_when_finished "mv .git/config.old .git/config" &&
+ echo "[alias]\n br" >.git/config &&
>>
>> Is the use of \n portable?
>>
>
> Yes, you are right, will replace with printf in the next patch.
... or a cat >.git/config <<\EOF, since this is the construct u
On 7/24/2014 3:41 AM, Junio C Hamano wrote:
> Matthieu Moy writes:
>
>> Tanay Abhra writes:
>>
>>> +test_expect_success 'check line errors for malformed values' '
>>> + cp .git/config .git/config.old &&
>
> Should this be "mv" not "cp"? You will be overwriting the file from
> scratch in th
On 7/24/2014 3:19 AM, Junio C Hamano wrote:
> Tanay Abhra writes:
>
>> If a callback returns a negative value to `git_config*()` family,
>> they call `die()` while printing the line number and the file name.
>> Currently the printed line number is off by one, thus printing the
>> wrong line num
On Thu, Jul 24, 2014 at 2:59 AM, Junio C Hamano wrote:
> It does not explain what the change to the test is about, though.
The old test and code are wrong. We want to verify repos are not
pruned if they're new (like, just created). But "git prune" without
--expire sets expire time to 0x (
On Thu, Jul 24, 2014 at 4:16 AM, Junio C Hamano wrote:
>> + if (strbuf_read_file(&sb, path.buf, 0) <= 0 ||
>> + !skip_prefix(sb.buf, "ref:", &start))
>> + goto done;
>> while (isspace(*start))
>> start++;
>> end = start;
>> while (*end && !is
On Wed, Jul 23, 2014 at 8:48 PM, Michael J Gruber
wrote:
> Nguyễn Thái Ngọc Duy venit, vidit, dixit 23.07.2014 13:43:
>> + if (advice_checkout_to)
>> + die(_("%s is already checked out at %s.\n"
>> + "Either use --detach or -b together with --to "
>> +
49 matches
Mail list logo
