Hi,
[PATCH v4]: Introduced `config_set` construct which points to a ordered set of
config-files cached as hashmaps. Added relevant API functions. For more
details see the documentation. Rewrote the git_config_get* family to use
`config_set` internally. Added tests for both
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: Tanay Abhra tanay...@gmail.com
---
.gitignore | 1 +
Makefile
Some workflows prefer to track exactly which email message was used to
generate a commit. This can be used, for example, to generate an
automated acknowledgement when a patch is committed as a response to
the patch email, or as a reference to the thread which introduced the
patch.
Support this
Some workflows prefer to track exactly which email message was used to
generate a commit. This can be used, for example, to generate an
automated acknowledgement when a patch is committed as a response to
the patch email, or as a reference to the thread which introduced the
patch.
Support this
Tanay Abhra tanay...@gmail.com writes:
Add a `config_set` construct that points to an ordered set of config files
specified by the user, each of which represents what was read and cached
in core as hashmaps. Add two external functions `git_configset_get_value`
and
Tanay Abhra tanay...@gmail.com writes:
+test_expect_success 'clear default config' '
+ rm -f .git/config
+'
+
+cat .git/config EOF
t/README says:
- Put all code inside test_expect_success and other assertions.
Even code that isn't a test per se, but merely some setup code
--- a/git-am.sh
+++ b/git-am.sh
@@ -39,6 +39,7 @@ committer-date-is-author-datelie about committer date
ignore-date use current timestamp for author date
rerere-autoupdate update the index with reused conflict resolution if
possible
S,gpg-sign? GPG-sign commits
On 7/2/2014 2:44 PM, Matthieu Moy wrote:
Tanay Abhra tanay...@gmail.com writes:
Add a `config_set` construct that points to an ordered set of config files
specified by the user, each of which represents what was read and cached
in core as hashmaps. Add two external functions
On 7/2/2014 2:59 PM, Matthieu Moy wrote:
Tanay Abhra tanay...@gmail.com writes:
+test_expect_success 'clear default config' '
+rm -f .git/config
+'
+
+cat .git/config EOF
t/README says:
- Put all code inside test_expect_success and other assertions.
Even code that
Some workflows prefer to track exactly which email message was used to
generate a commit. This can be used, for example, to generate an
automated acknowledgement when a patch is committed as a response to
the patch email, or as a reference to the thread which introduced the
patch.
Support this
On 07/02/2014 12:58 PM, Torsten Bögershausen wrote:
@@ -757,6 +761,10 @@ To restore the original branch and stop patching run \\$cmdline
--abort\.
then
cat $dotest/msg-clean
fi
+ if test 't' == $message_id
The == is bash
Hi Max,
On Wed, 2 Jul 2014, Max Kirillov wrote:
On Mon, Jun 30, 2014 at 04:55:10PM +0200, Johannes Schindelin wrote:
I just wish the tests were a little easier to understand...
What could be improved with them?
Oh, I would name the files more appropriately, for example. That is,
instead
Hi Avi,
On 07/02/2014 10:51 AM, Avi Kivity wrote:
Some workflows prefer to track exactly which email message was used to
generate a commit. This can be used, for example, to generate an
automated acknowledgement when a patch is committed as a response to
the patch email, or as a reference to
Tanay Abhra tanay...@gmail.com writes:
On 7/2/2014 2:44 PM, Matthieu Moy wrote:
Tanay Abhra tanay...@gmail.com writes:
Maybe a reworded sentence may work,
`git_configset_get_value_multi` returns a list of values sorted in order of
increasing priority (i.e. last match will be at the end of
On 07/02/2014 05:18 PM, Fabian Ruch wrote:
Hi Avi,
On 07/02/2014 10:51 AM, Avi Kivity wrote:
Some workflows prefer to track exactly which email message was used to
generate a commit. This can be used, for example, to generate an
automated acknowledgement when a patch is committed as a
Some workflows prefer to track exactly which email message was used to
generate a commit. This can be used, for example, to generate an
automated acknowledgement when a patch is committed as a response to
the patch email, or as a reference to the thread which introduced the
patch.
Support this
(Not sure if this is the right thread)
(I haven't checked if this is fixed in your latest version)
On what I have on pu 7a0da7902cbbc9a876b90c9, Tue Jul 1 14:51:53 2014 -0700
Many submodule tests are broken.
One problem is here:
lib-submodule-update.sh:264: possible problem: echo -n is not
I know that with the `git branch` command I can determine which
branches contain a commit. Is there a way to represent this
graphically with `git log`? Sometimes I just have a commit, and I need
to find out what branch contains that commit. The reason why `git
branch --contains` doesn't solve this
diff --git a/git-am.sh b/git-am.sh
index ee61a77..fd0181f 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -39,6 +39,7 @@ committer-date-is-author-datelie about committer date
ignore-date use current timestamp for author date
rerere-autoupdate update the index with reused conflict
Jeff King p...@peff.net writes:
For that reason, the mem form puts its length parameter
next to the buffer (since they are a pair), and the string
form puts it at the end (since it is an out-parameter). The
compiler can notice when you get the order wrong, which
should help prevent writing
When compiling Git 2.0.1 on RedHat 5.9 as a non-root user I get the
following error:
BUILD ERROR
```
make prefix=/home/eldon/local all doc info
...
CC zlib.o
CC unix-socket.o
CC thread-utils.o
CC compat/strlcpy.o
AR libgit.a
/bin/sh: gar: command not found
make: ***
On 07/02/2014 06:03 PM, Torsten Bögershausen wrote:
@@ -565,6 +568,7 @@ Use \git am --abort\ to remove it.)
echo $git_apply_opt $dotest/apply-opt
echo $threeway $dotest/threeway
echo $sign $dotest/sign
+ echo $message_id $dotest/message-id
echo $utf8
Eldon Nelson eldon_nel...@ieee.org writes:
make prefix=/home/eldon/local all doc info
...
CC zlib.o
CC unix-socket.o
CC thread-utils.o
CC compat/strlcpy.o
AR libgit.a
/bin/sh: gar: command not found
[...]
I think the fix is to allow the use of ar if gar does not
On Wed, Jul 02, 2014 at 10:56:25AM -0500, Eldon Nelson wrote:
When compiling Git 2.0.1 on RedHat 5.9 as a non-root user I get the
following error:
BUILD ERROR
```
make prefix=/home/eldon/local all doc info
...
CC zlib.o
CC unix-socket.o
CC thread-utils.o
CC
On Wed, Jul 02, 2014 at 09:50:57AM -0500, Robert Dailey wrote:
I know that with the `git branch` command I can determine which
branches contain a commit. Is there a way to represent this
graphically with `git log`? Sometimes I just have a commit, and I need
to find out what branch contains
On Wed, Jul 02, 2014 at 08:54:44AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
For that reason, the mem form puts its length parameter
next to the buffer (since they are a pair), and the string
form puts it at the end (since it is an out-parameter). The
compiler can
On Wed, Jul 2, 2014 at 11:34 AM, Jeff King p...@peff.net wrote:
Have you tried git describe --contains --all commit?
To some degree, I fear your question isn't something git can answer. If
the branch containing the commit has been merged into other branches,
then they all contain the commit.
-Original Message-
From: Jeff King
Sent: Wednesday, July 02, 2014 12:35
On Wed, Jul 02, 2014 at 09:50:57AM -0500, Robert Dailey wrote:
I know that with the `git branch` command I can determine which
branches contain a commit. Is there a way to represent this
graphically with
On Wed, Jul 2, 2014 at 11:52 AM, Jason Pyeron jpye...@pdinc.us wrote:
-Original Message-
From: Jeff King
Sent: Wednesday, July 02, 2014 12:35
On Wed, Jul 02, 2014 at 09:50:57AM -0500, Robert Dailey wrote:
I know that with the `git branch` command I can determine which
branches
Tanay Abhra tanay...@gmail.com writes:
diff --git a/Documentation/technical/api-config.txt
b/Documentation/technical/api-config.txt
index 230b3a0..2c02fee 100644
--- a/Documentation/technical/api-config.txt
+++ b/Documentation/technical/api-config.txt
@@ -77,6 +77,75 @@ To read a specific
Matthieu Moy matthieu@grenoble-inp.fr writes:
I don't like the name the_config_set. It's not the only one. Perhaps
repo_config_set? (not totally satisfactory as it does not contain only
the repo, but the repo+user+system)
What do others think?
I actually do like the_configset, which
On Fri, Jun 27, 2014 at 5:37 PM, Shawn Pearce spea...@spearce.org wrote:
On Fri, Jun 27, 2014 at 2:30 PM, Ronnie Sahlberg sahlb...@google.com wrote:
List,
One of my ref transaction aims is to make define a stable public API
for accessing refs.
Once this is done I want to make it possible to
Junio C Hamano gits...@pobox.com writes:
Tanay Abhra tanay...@gmail.com writes:
diff --git a/Documentation/technical/api-config.txt
b/Documentation/technical/api-config.txt
index 230b3a0..2c02fee 100644
--- a/Documentation/technical/api-config.txt
+++
Avi Kivity a...@cloudius-systems.com writes:
+ if test 't' == $message_id
+ then
+ grep ^Message-Id: $dotest/info || true
+ fi
if test '' != $ADD_SIGNOFF
then
echo $ADD_SIGNOFF
Seeing
Jeff King p...@peff.net writes:
Having had a day to mull it over, and having read your email, I think I
still prefer strip_suffix.
That's OK. I was only trying to help you explore different avenues,
without having strong preference myself either way.
--
To unsubscribe from this list: send the
Hi,
this reroll applies the comments from Eric, Junio and Michael. In
particular,
* It turned out that `pick_one` does not need option handling at all
and the option-like argument `-n` determines whether `pick_one` or
`do_pick` creates the replay commit. The latter happens if the
task
The to-do list command `reword` replays a commit like `pick` but lets
the user also edit the commit's log message. This happens in two
steps. Firstly, the named commit is cherry-picked. Secondly, the
commit created in the first step is amended using an unchanged index
to edit the log message. The
The to-do list command `reword` replays a commit like `pick` but lets
the user also edit the commit's log message. If the edited log
message is empty or is found ill-formatted by one of the commit
hooks, git-rebase--interactive prints three error messages to the
console.
1. The git-commit
The to-do list command `reword` replays a commit like `pick` but lets
the user also edit the commit's log message. If `--keep-empty` is
passed as option to git-rebase--interactive, empty commits ought to
be replayed without complaints. However, if the users chooses to
reword an empty commit by
The to-do list command `reword` replays a commit like `pick` but lets
the user also edit the commit's log message. If one thinks of `pick`
entries as scheduled `cherry-pick` command lines, then `reword`
becomes an alias for the command line `cherry-pick --edit`. The
porcelain `rebase--interactive`
Since `do_pick` might be executed in a sub-shell (a modified author
environment for instance), calling `die` in `do_pick` has no effect
but exiting the sub-shell with a failure exit status. The
git-rebase--interactive script is not terminated. Moreover, if
`do_pick` is called while a squash or
`do_pick` is the git-cherry-pick wrapper in git-rebase--interactive
that is used to implement the to-do list command `pick`. To cater for
the different pick behaviours (like `reword`), `do_pick` accepts
several options not only from the git-cherry-pick but also the
git-commit interface. Add the
There are two kinds of to-do list commands available. One kind
replays a commit (`pick`, `reword`, `edit`, `squash` and `fixup` that
is) and the other executes a shell command (`exec`). We will call the
first kind replay commands.
The two kinds of tasks are scheduled using different line formats.
The options passed to `do_pick` determine whether the picked commit
will be rewritten or not. If the commit gets rewritten, because the
user requested to edit the commit message for instance, let
`pick_one` merely apply the changes introduced by the commit and do
not commit the resulting tree yet.
pick and reword are atomic to-do list commands in the sense that they
open a new task which is closed after the respective command is
completed. squash and fixup are not atomic. They create a new task
which is not completed until the last squash or fixup is processed.
Lift the general unknown
The command line used to recreate root commits specifies the
erroneous option `-q` which suppresses the commit summary message.
However, git-rebase--interactive tends to tell the user about the
commits it creates, if she wishes (cf. command line option
`--verbose`). The code parts handling
`do_pick` is the git-cherry-pick wrapper in git-rebase--interactive
that is used to implement many of the to-do list commands.
Eventually, the complete `do_pick` interface will be exposed to the
user in some form or another and those commands will become simple
aliases for the `do_pick` options
The to-do list command `squash` and its close relative `fixup` replay
the changes of a commit like `pick` but do not recreate the commit.
Instead they replace the previous commit with a new commit that also
introduces the changes of the squashed commit. This is roughly like
cherry-picking without
`do_pick` is the git-cherry-pick wrapper in git-rebase--interactive
that is currently used to implement most of the to-do list commands
and offers additional options that will eventually find their way
onto to-do lists.
To extend the repertoire of available options, add the git-commit and
`do_pick` is the git-cherry-pick wrapper in git-rebase--interactive
that is used to implement the to-do list command `pick`, `reword` and
`edit`. To cater for the different pick behaviours (like `squash`),
`do_pick` accepts several options not only from the git-cherry-pick
but also the git-commit
`do_pick` is the git-cherry-pick wrapper in git-rebase--interactive
that is used to implement the to-do list commands `pick`, `reword`
and `edit`. To cater for the different pick behaviours (like
`squash`), `do_pick` accepts several options not only from the
git-cherry-pick but also the git-commit
Read in to-do list lines as
command args
instead of
command sha1 rest
so that to-do list command lines can specify additional arguments
apart from the commit hash and the log message title, which become
the non-options in `args`. Loop over `args`, put all options (an
argument beginning
Rewrite `squash` and `fixup` handling in `do_next` using the sequence
pick_one
commit
in order to test the correctness of a single `do_squash` or
parameterised `do_pick` and make the subsequent patch reimplementing
`squash` in terms of such a single function more readable.
Do not call
Karsten Blees karsten.bl...@gmail.com writes:
Replace the 'const char *key' parameter in the API with a pointer to a
'struct trace_key' that bundles the environment variable name with
additional, trace-internal state. Change the call sites of these APIs to
use a static 'struct trace_key'
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
builtin/clean.c | 2 +-
builtin/tag.c | 2 +-
pretty.c| 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/builtin/clean.c b/builtin/clean.c
index 9a91515..27701d2 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
On Wed, Jun 18, 2014 at 2:10 PM, Junio C Hamano gits...@pobox.com wrote:
Junio C Hamano gits...@pobox.com writes:
Ronnie Sahlberg sahlb...@google.com writes:
Add a field that describes what type of update this refers to. For now
the only type is UPDATE_SHA1 but we will soon add more types.
We create a directory that cannot be removed, confirm that
it cannot be removed, and then fix it like:
chmod 0 foo
test_must_fail git clean -d -f
chmod 755 foo
If the middle step fails but leaves the directory (e.g., the
bug is that clean does not notice the failure), this
pollutes the
Karsten Blees karsten.bl...@gmail.com writes:
+#else
+
+/*
+ * Macros to add file:line - see above for C-style declarations of how these
+ * should be used.
+ *
+ * TRACE_CONTEXT may be set to __FUNCTION__ if the compiler supports it. The
+ * default is __FILE__, as it is consistent with
Jeff King wrote:
Signed-off-by: Jeff King p...@peff.net
---
t/t7300-clean.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Does the later git clean -d with an unreadable empty directory test
need the same treatment?
Thanks,
Jonathan
--
To unsubscribe from this list: send the
On Wed, Jul 02, 2014 at 12:01:59PM -0700, Jonathan Nieder wrote:
Jeff King wrote:
Signed-off-by: Jeff King p...@peff.net
---
t/t7300-clean.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Does the later git clean -d with an unreadable empty directory test
need the same
If you have an untracked directory that contains excluded files, like
this:
mkdir foo
echo content foo/one
echo content foo/two
echo foo/one .gitignore
then git clean -d will notice that foo is untracked and recursively
delete it and its contents, including the ignored foo/one.
Our
Karsten Blees karsten.bl...@gmail.com writes:
Also, can it be set to something like __FILE__ : __FUNCTION__
which may alleviate the alleged problem of not necessarily unique
perhaps?
Should work with MSVC. With GCC, however, __FUNCTION__ is a string constant
supplied by the compiler, so
Am 02.07.2014 20:57, schrieb Junio C Hamano:
Karsten Blees karsten.bl...@gmail.com writes:
+#else
+
+/*
+ * Macros to add file:line - see above for C-style declarations of how these
+ * should be used.
+ *
+ * TRACE_CONTEXT may be set to __FUNCTION__ if the compiler supports it. The
+ *
Am 02.07.2014 16:54, schrieb Torsten Bögershausen:
(Not sure if this is the right thread)
(I haven't checked if this is fixed in your latest version)
Yes, this is the right thread and no, it isn't fixed yet.
On what I have on pu 7a0da7902cbbc9a876b90c9, Tue Jul 1 14:51:53 2014 -0700
Many
Ronnie Sahlberg wrote:
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
builtin/clean.c | 2 +-
builtin/tag.c | 2 +-
pretty.c| 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
Is there some gcc option or other tool that can automatically detect
this kind of problem
Jeff King p...@peff.net writes:
On Wed, Jul 02, 2014 at 12:01:59PM -0700, Jonathan Nieder wrote:
Jeff King wrote:
Signed-off-by: Jeff King p...@peff.net
---
t/t7300-clean.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Does the later git clean -d with an unreadable
GCC can check/error for this with
--pedantic -Werror
On Wed, Jul 2, 2014 at 12:58 PM, Jonathan Nieder jrnie...@gmail.com wrote:
Ronnie Sahlberg wrote:
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
builtin/clean.c | 2 +-
builtin/tag.c | 2 +-
pretty.c| 2 +-
3
Christian Couder chrisc...@tuxfamily.org writes:
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
Signed-off-by: Junio C Hamano gits...@pobox.com
---
t/t6050-replace.sh | 12
1 file changed, 12 insertions(+)
diff --git a/t/t6050-replace.sh b/t/t6050-replace.sh
index
Christian Couder chrisc...@tuxfamily.org writes:
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
builtin/replace.c | 42 +-
1 file changed, 25 insertions(+), 17 deletions(-)
diff --git a/builtin/replace.c b/builtin/replace.c
index
Christian Couder chrisc...@tuxfamily.org writes:
It could be misleading to keep a signature in a
replacement commit, so let's remove it.
Note that there should probably be a way to sign
the replacement commit created when using --graft,
but this can be dealt with in another commit or
patch
Heya,
We recently ran into a particularly troubling race condition, discovered
in git 2.0.0. The setup for it is as follows:
The repository is a bare repository, which developers push to via ssh;
it mirrors its changes out onto github. In its config:
[remote github]
url =
Here are a few small hashmap improvements, partly resulting from recent
discussion of the config-cache topic.
Karsten Blees (4):
hashmap: factor out getting an int hash code from a SHA1
hashmap: improve struct hashmap member documentation
hashmap: add simplified hashmap_get_from_hash() API
Alex Vandiver a...@chmrr.net writes:
[remote github]
url = g...@github.com:bestpractical/rt.git
fetch = +refs/*:refs/*
mirror = yes
git push github master^:master must stay a usable way to update
the published repository to an arbitrary commit, so if set to
Copying the first bytes of a SHA1 is duplicated in six places, however,
the implications (wrong byte order on little-endian systems) is documented
only once.
Add a properly documented API for this.
Signed-off-by: Karsten Blees bl...@dcon.de
---
Documentation/technical/api-hashmap.txt | 9
Signed-off-by: Karsten Blees bl...@dcon.de
---
Documentation/technical/api-hashmap.txt | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/Documentation/technical/api-hashmap.txt
b/Documentation/technical/api-hashmap.txt
index 4689968..dc21a7c 100644
---
Interning short strings with high probability of duplicates can reduce the
memory footprint and speed up comparisons.
Add strintern() and memintern() APIs that use a hashmap to manage the pool
of unique, interned strings.
Note: strintern(getenv()) could be used to sanitize git's use of getenv(),
Hashmap entries are typically looked up by just a key. The hashmap_get()
API expects an initialized entry structure instead, to support compound
keys. This flexibility is currently only needed by find_dir_entry() in
name-hash.c (and compat/win32/fscache.c in the msysgit fork). All other
(currently
On Wed, Jul 2, 2014 at 10:11 AM, Ronnie Sahlberg sahlb...@google.com wrote:
On Fri, Jun 27, 2014 at 5:37 PM, Shawn Pearce spea...@spearce.org wrote:
On Fri, Jun 27, 2014 at 2:30 PM, Ronnie Sahlberg sahlb...@google.com wrote:
List,
One of my ref transaction aims is to make define a stable
On 07/02/2014 06:20 PM, Junio C Hamano wrote:
Alex Vandiver a...@chmrr.net writes:
[remote github]
url = g...@github.com:bestpractical/rt.git
fetch = +refs/*:refs/*
mirror = yes
git push github master^:master must stay a usable way to update
the published
Is Git supposed to be usable in an environment where the execution character
set is EBCDIC?
I ask because, in browsing the source code (version 2.0.0), I stumbled across
three functions
that won't work as presumably intended in an EBCDIC environment (strihash(),
memihash(), and
On Wed, Jul 02, 2014 at 04:08:28PM +0200, Johannes Schindelin wrote:
What could be improved with them?
Oh, I would name the files more appropriately, for example. That is,
instead of test1.txt I would call it mixed-endings.txt or lf-only.txt or
some such.
And instead of the Latin version
On 07/02/2014 09:57 PM, Jens Lehmann wrote:
Am 02.07.2014 16:54, schrieb Torsten Bögershausen:
(Not sure if this is the right thread)
(I haven't checked if this is fixed in your latest version)
Yes, this is the right thread and no, it isn't fixed yet.
On what I have on pu
83 matches
Mail list logo
