Junio C Hamano gits...@pobox.com 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 Wine$
The point is:
Junio C Hamano gits...@pobox.com writes:
+int git_config(config_fn_t fn, void *data)
+{
+git_config_check_init();
+return configset_iter(the_config_set, fn, data);
+}
Perhaps if you define this function at the right place in the file
you do not have to add an forward decl of
On Wed, Jul 23, 2014 at 8:48 PM, Michael J Gruber
g...@drmicha.warpmail.net 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
On Thu, Jul 24, 2014 at 4:16 AM, Junio C Hamano gits...@pobox.com 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
On Thu, Jul 24, 2014 at 2:59 AM, Junio C Hamano gits...@pobox.com 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
On 7/24/2014 3:19 AM, Junio C Hamano wrote:
Tanay Abhra tanay...@gmail.com 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
On 7/24/2014 3:41 AM, Junio C Hamano wrote:
Matthieu Moy matthieu@grenoble-inp.fr writes:
Tanay Abhra tanay...@gmail.com 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
Tanay Abhra tanay...@gmail.com 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 used
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
nothing).
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
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 v11 and
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
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 matthieu@imag.fr
Signed-off-by: Tanay Abhra tanay...@gmail.com
---
Tanay Abhra tanay...@gmail.com 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
On 7/24/2014 9:09 PM, Matthieu Moy wrote:
Tanay Abhra tanay...@gmail.com 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
Tanay Abhra tanay...@gmail.com writes:
On 7/24/2014 9:09 PM, Matthieu Moy wrote:
Tanay Abhra tanay...@gmail.com 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
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
Duy Nguyen pclo...@gmail.com writes:
On Thu, Jul 24, 2014 at 4:16 AM, Junio C Hamano gits...@pobox.com wrote:
+ if (strbuf_read_file(sb, path.buf, 0) = 0 ||
+ !skip_prefix(sb.buf, ref:, start))
+ goto done;
while (isspace(*start))
start++;
Matthieu Moy matthieu@grenoble-inp.fr writes:
Tanay Abhra tanay...@gmail.com 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
Matthieu Moy matthieu@grenoble-inp.fr writes:
Junio C Hamano gits...@pobox.com 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
Michael J Gruber g...@drmicha.warpmail.net 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
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'
Junio C Hamano gits...@pobox.com writes:
Duy Nguyen pclo...@gmail.com writes:
On Thu, Jul 24, 2014 at 4:16 AM, Junio C Hamano gits...@pobox.com wrote:
+ if (strbuf_read_file(sb, path.buf, 0) = 0 ||
+ !skip_prefix(sb.buf, ref:, start))
+ goto done;
while
Tanay Abhra tanay...@gmail.com writes:
On 7/24/2014 3:19 AM, Junio C Hamano wrote:
Tanay Abhra tanay...@gmail.com 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
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
On 7/25/2014 12:01 AM, Junio C Hamano wrote:
Tanay Abhra tanay...@gmail.com writes:
On 7/24/2014 3:19 AM, Junio C Hamano wrote:
Tanay Abhra tanay...@gmail.com writes:
If a callback returns a negative value to `git_config*()` family,
they call `die()` while printing the line number and
Tanay Abhra tanay...@gmail.com 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
+
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
Tanay Abhra tanay...@gmail.com 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
Tanay Abhra tanay...@gmail.com writes:
On 7/25/2014 12:01 AM, Junio C Hamano wrote:
Tanay Abhra tanay...@gmail.com writes:
On 7/24/2014 3:19 AM, Junio C Hamano wrote:
Tanay Abhra tanay...@gmail.com writes:
If a callback returns a negative value to `git_config*()` family,
they call
On Thu, Jul 24, 2014 at 08:47:45PM +0200, Matthieu Moy wrote:
Tanay Abhra tanay...@gmail.com 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
Matthieu Moy matthieu@grenoble-inp.fr writes:
Tanay Abhra tanay...@gmail.com 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
On 7/25/2014 12:50 AM, Junio C Hamano wrote:
Matthieu Moy matthieu@grenoble-inp.fr writes:
Tanay Abhra tanay...@gmail.com 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
Tanay Abhra tanay...@gmail.com 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
Matthieu Moy matthieu@grenoble-inp.fr 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
Jeff King p...@peff.net 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.
On 24/07/14 20:54, Junio C Hamano wrote:
Tanay Abhra tanay...@gmail.com 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
Duy Nguyen pclo...@gmail.com writes:
On Wed, Jul 23, 2014 at 8:48 PM, Michael J Gruber
g...@drmicha.warpmail.net 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
Johannes Sixt j...@kdbg.org 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 -r -C
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
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
From: Junio C Hamano gits...@pobox.com
Sent: Wednesday, July 23, 2014 7:10 PM
Philip Oakley philipoak...@iee.org 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
Philip Oakley philipoak...@iee.org 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.
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,
On 7/25/2014 2:52 AM, Ramsay Jones wrote:
On 24/07/14 20:54, Junio C Hamano wrote:
Tanay Abhra tanay...@gmail.com 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
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
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
47 matches
Mail list logo