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 7a0da7902cbbc9a876b9
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 v
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
git_user_age
On 07/02/2014 06:20 PM, Junio C Hamano wrote:
> Alex Vandiver 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 r
On Wed, Jul 2, 2014 at 10:11 AM, Ronnie Sahlberg wrote:
> On Fri, Jun 27, 2014 at 5:37 PM, Shawn Pearce wrote:
>> On Fri, Jun 27, 2014 at 2:30 PM, Ronnie Sahlberg wrote:
>>> List,
>>>
>>> One of my ref transaction aims is to make define a stable public API
>>> for accessing refs.
>>> Once this i
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
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(),
Signed-off-by: Karsten Blees
---
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
--- a/Documentation/techn
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
---
Documentation/technical/api-hashmap.txt | 9 +
builtin/
Alex Vandiver 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
mirror, do n
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
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 = g...@gi
Christian Couder writes:
> Signed-off-by: Christian Couder
> ---
> t/t6050-replace.sh | 22 ++
> 1 file changed, 22 insertions(+)
>
> diff --git a/t/t6050-replace.sh b/t/t6050-replace.sh
> index ca45a84..80b85e3 100755
> --- a/t/t6050-replace.sh
> +++ b/t/t6050-replace.sh
>
Christian Couder 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 series.
Both pa
Christian Couder writes:
> Signed-off-by: Christian Couder
> ---
> builtin/replace.c | 42 +-
> 1 file changed, 25 insertions(+), 17 deletions(-)
>
> diff --git a/builtin/replace.c b/builtin/replace.c
> index 3515979..ad47237 100644
> --- a/builtin/replac
Christian Couder writes:
> Signed-off-by: Christian Couder
> Signed-off-by: Junio C Hamano
> ---
> t/t6050-replace.sh | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/t/t6050-replace.sh b/t/t6050-replace.sh
> index 68b3cb2..ca45a84 100755
> --- a/t/t6050-replace.sh
> +++
GCC can check/error for this with
--pedantic -Werror
On Wed, Jul 2, 2014 at 12:58 PM, Jonathan Nieder wrote:
> Ronnie Sahlberg wrote:
>
>> Signed-off-by: Ronnie Sahlberg
>> ---
>> builtin/clean.c | 2 +-
>> builtin/tag.c | 2 +-
>> pretty.c| 2 +-
>> 3 files changed, 3 insertions(
Junio C Hamano writes:
> It tests that "clean -d" is happy if a blind rmdir(2) removes the
> directory. If it fails for whatever reason (e.g. add "exit(0)" at
> the beginning of cmd_clean(), for example) to remove the directory,
> we do leave an empty unreadable directory behind.
>
> But as long
Jeff King writes:
> On Wed, Jul 02, 2014 at 12:01:59PM -0700, Jonathan Nieder wrote:
>
>> Jeff King wrote:
>>
>> > Signed-off-by: Jeff King
>> > ---
>> > t/t7300-clean.sh | 4 ++--
>> > 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> Does the later "git clean -d with an unreadable empty
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
>
> Ma
Ronnie Sahlberg wrote:
> Signed-off-by: Ronnie Sahlberg
> ---
> 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 so the regress
Am 02.07.2014 20:57, schrieb Junio C Hamano:
> Karsten Blees 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
>> + * defau
Karsten Blees 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 string literal
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".
On Wed, Jul 02, 2014 at 12:01:59PM -0700, Jonathan Nieder wrote:
> Jeff King wrote:
>
> > Signed-off-by: Jeff King
> > ---
> > 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 sam
Jeff King wrote:
> Signed-off-by: Jeff King
> ---
> 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 line "unsu
Karsten Blees 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 assert(), and st
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 th
On Wed, Jun 18, 2014 at 2:10 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Ronnie Sahlberg 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.
>>>
>>> Signed-off-by: Ronnie Sahlberg
>>>
Signed-off-by: Ronnie Sahlberg
---
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
@@ -48,7 +48,7 @@ e
Karsten Blees 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' instead of a string cons
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 `r
`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 i
`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
`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
git-cher
`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 now
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 c
`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 com
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 command line used to recreate root commits specifies the
effectless option `-C`. It is used to reuse commit message and
authorship from the named commit but the commit being amended here,
which is the sentinel commit, already carries the authorship and log
message of the processed commit. Note
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.
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 non-root
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 opti
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 fixu
The command line used to recreate root commits specifies the
erroneous option `--allow-empty-message`. If the root commit has an
empty log message, the replay of this commit should fail and the
rebase should be interrupted like for any other commit that is on the
to-do list and has an empty commit
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`
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 chan
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 outp
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 p
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 w
Jeff King 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 line "unsub
Avi Kivity writes:
> + if test 't' == "$message_id"
> + then
> + grep ^Message-Id: "$dotest/info" || true
> + fi
> if test '' != "$ADD_SIGNOFF"
> then
> echo "$ADD_SIGNOFF"
Seeing how existi
Junio C Hamano writes:
> Tanay Abhra 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 @
On Fri, Jun 27, 2014 at 5:37 PM, Shawn Pearce wrote:
> On Fri, Jun 27, 2014 at 2:30 PM, Ronnie Sahlberg 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 replace the current
>> .git/
Matthieu Moy 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 goes nicely parallel to
Tanay Abhra 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 file in git-c
On Wed, Jul 2, 2014 at 11:52 AM, Jason Pyeron 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 c
> -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
> > graphi
On Wed, Jul 2, 2014 at 11:34 AM, Jeff King wrote:
> Have you tried "git describe --contains --all "?
>
> 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. There is no
On Wed, Jul 02, 2014 at 08:54:44AM -0700, Junio C Hamano wrote:
> Jeff King 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 noti
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 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
> C
Eldon Nelson 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 exist.
It is
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"
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: *** [libgit.a]
Jeff King 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 one when
> 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
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
(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 porta
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 by
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 respons
Tanay Abhra writes:
> On 7/2/2014 2:44 PM, Matthieu Moy wrote:
>> Tanay Abhra 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 the list.)
OK.
>>> read from us
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
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,
inste
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 b
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 by
On 7/2/2014 2:59 PM, Matthieu Moy wrote:
> Tanay Abhra 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 is
On 7/2/2014 2:44 PM, Matthieu Moy wrote:
> Tanay Abhra 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`
> --- 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
> +m,me
Tanay Abhra 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
should be insi
Tanay Abhra 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 `git_configset_get_value_multi` for queryin
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 by
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 by
84 matches
Mail list logo
