In addition to the valuable review comments by Torsten and Peff, find
more below...
On Mon, Jun 2, 2014 at 10:47 AM, Tanay Abhra wrote:
> Add a hash table to cache all key-value pairs read from config files
> (repo specific .git/config, user wide ~/.gitconfig and the global
> /etc/gitconfig). Add
Simplified cases where a strbuf_reset was immediately followed by a
strbuf_add using the new strbuf_set operations.
Signed-off-by: Jeremiah Mahler
---
fast-import.c | 19 ++-
1 file changed, 6 insertions(+), 13 deletions(-)
diff --git a/fast-import.c b/fast-import.c
index e8ec34
Currently, the data in a strbuf is modified using add operations. To
set the buffer to some data a reset must be performed before an add.
strbuf_reset(buf);
strbuf_add(buf, cb.buf.buf, cb.buf.len);
And this is a common sequence of operations with 70 occurrences found in
the current source co
Simplified cases where a strbuf_reset was immediately followed by a
strbuf_add using the new strbuf_set operations.
Signed-off-by: Jeremiah Mahler
---
sha1_name.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index 2b6322f..f88b66c
Simplified cases where a strbuf_reset was immediately followed by a
strbuf_add using the new strbuf_set operations.
Signed-off-by: Jeremiah Mahler
---
builtin/remote.c | 51 +--
1 file changed, 17 insertions(+), 34 deletions(-)
diff --git a/builti
Add documentation of the strbuf_set operations to
technical/api-strbuf.txt.
Signed-off-by: Jeremiah Mahler
---
Documentation/technical/api-strbuf.txt | 18 ++
1 file changed, 18 insertions(+)
diff --git a/Documentation/technical/api-strbuf.txt
b/Documentation/technical/api-strb
Currently, the data in a strbuf is modified using add operations. To
set the buffer to some data a reset must be performed before an add.
strbuf_reset(buf);
strbuf_add(buf, cb.buf.buf, cb.buf.len);
And this is a common sequence of operations with 70 occurrences found in
the current s
On Mon, Jun 9, 2014 at 4:36 AM, Jeremiah Mahler wrote:
> Add documentation of the strbuf_set operations to
> technical/api-strbuf.txt.
Since this patch is concise and so closely related to patch 1/5, it
probably should be squashed into that one.
More below.
> Signed-off-by: Jeremiah Mahler
> -
On Mon, Jun 9, 2014 at 4:36 AM, Jeremiah Mahler wrote:
> Subject: fast-import.c: cleanup using strbuf_set operations
This might read more clearly if written:
fast-import: simplify via strbuf_set()
> Simplified cases where a strbuf_reset was immediately followed by a
> strbuf_add using the n
answer call but after cannot end, bcoz no effect light and sensitive.my phone
is voyager dg300.but root is
cwm.N�r��yb�X��ǧv�^�){.n�+ا���ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf
On Mon, Jun 9, 2014 at 3:36 PM, Jeremiah Mahler wrote:
> Currently, the data in a strbuf is modified using add operations. To
> set the buffer to some data a reset must be performed before an add.
>
> strbuf_reset(buf);
> strbuf_add(buf, cb.buf.buf, cb.buf.len);
>
> And this is a common seque
Kedves felhasználók e-mailben;
Túllépte 23432 box set
Web Service / Admin, és akkor nem lesz probléma a küldő és
fogadhat e-maileket, amíg újra ellenőrizni. Kérjük, frissítse kattintva
linkre, és töltse ki az adatokat, hogy ellenőrizze a számla
Kérjük, kövesse az alábbi linkre, és majd másolja és
Kedves felhasználók e-mailben;
Túllépte 23432 box set
Web Service / Admin, és akkor nem lesz probléma a küldő és
fogadhat e-maileket, amíg újra ellenőrizni. Kérjük, frissítse kattintva
linkre, és töltse ki az adatokat, hogy ellenőrizze a számla
Kérjük, kövesse az alábbi linkre, és majd másolja és
Hi all,
Someone pointed out on the "Git for human beings" Google group
(https://groups.google.com/d/topic/git-users/27_FxIV_100/discussion)
that using git-reset's hard mode when having staged untracked files
simply deletes them from the working dir.
Since git-reset specifically doesn't touch untr
Hi,
I am taking this patch out of RFC.
[PATCH V1]:Most of the invaluable suggestions by Eric Sunshine, Torsten
Bogershausen and
Jeff King has been implemented[1]. Complete rewrite of config_cache*()
family
using git_config() as hook as suggested by Jeff. Thanks for the review.
Add a hash table to cache all key-value pairs read from config files
(repo specific .git/config, user wide ~/.gitconfig and the global
/etc/gitconfig). Add two external functions `git_config_get_string` and
`git_config_get_string_multi` for querying in a non-callback manner from the
hash table.
Si
'!f() { ... }; f' is a recommended pattern to declare more complex
aliases (see git wiki [1]). This commit teaches the completion to
handle them.
When determining which completion to use for an alias, the opening brace
is now ignored in order to continue the search for a git command inside
the fu
Am 06.06.2014 07:54, schrieb Heiko Voigt:
> On Thu, Jun 05, 2014 at 07:48:33PM +1200, Chris Packham wrote:
>> On 05/06/14 07:42, Heiko Voigt wrote:
>>> So either we do this "magically" and all valid boolean values are
>>> forbidden as tags or we would need a different config option. Further
>>> thi
Elia Pinto writes:
> These patch series convert test -a/-o to && and ||.
Reviewed-by: Matthieu Moy
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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
Pierre-François CLEMENT writes:
> Hi all,
>
> Someone pointed out on the "Git for human beings" Google group
> (https://groups.google.com/d/topic/git-users/27_FxIV_100/discussion)
> that using git-reset's hard mode when having staged untracked files
> simply deletes them from the working dir.
>
>
Tanay Abhra writes:
> +the highest priority(i.e. for the same variable value in the repo config
^
missing space.
> +struct config_cache_entry {
> + struct hashmap_entry ent;
> + char *key;
> + struct string_list *value_list;
> +};
I guess this crossed Eric's r
Hi Junio,
On 05/27/2014 08:42 PM, Junio C Hamano wrote:
> Fabian Ruch writes:
>> [..]
>>
>> In order to signal the three possible situations (not only success and
>> failure to complete) after a pick through porcelain commands such as
>> `cherry-pick`, exit with a return value that is neither 0 n
thanks
On Sun, Jun 8, 2014 at 2:03 AM, Eric Sunshine wrote:
> On Thu, Jun 5, 2014 at 7:26 PM, Ronnie Sahlberg wrote:
>> When we are updating more than one single ref, i.e. not a commit, then
>> write the updated refs directly to the packed refs file instead of writing
>> them as loose refs.
>>
>
Jeff King writes:
> I think it would make sense to actually take this one step further,
> though, and move commit->buffer into the slab, as well. That has two
> advantages:
>
> 1. It further decreases the size of "struct commit" for callers who do
> not use save_commit_buffer.
>
> 2. It
Kedves Email felhasználói;
Ön túllépte a tárolási határt 23.432 az e-postafiók beállítva a
WEB SERVICE / Administrator, és akkor problémái küldés
és a bejövő üzenetek, amíg meg újból érvényesíti az e-mail címét. A szükséges
eljárások
nyújtottak be az alábbi a véleménye, ellenőrizze kattintva
az a
--
Kedves Email felhasználói;
Ön túllépte a tárolási határt 23.432 az e-postafiók beállítva a
WEB SERVICE / Administrator, és akkor problémái küldés
és a bejövő üzenetek, amíg meg újból érvényesíti az e-mail címét. A
szükséges eljárások
nyújtottak be az alábbi a véleménye, ellenőrizze kattint
Here's my series to drop "buffer" from "struct commit" in favor of a
slab, and then add in a length field. It's a lot of commits, but I tried
to break it down into readable chunks.
[01/15]: alloc: include any-object allocations in alloc_report
[02/15]: commit: push commit_index update into all
When 2c1cbec (Use proper object allocators for unknown
object nodes too, 2007-04-16), added a special "any_object"
allocator, it never taught alloc_report to report on it. To
do so we need to add an extra type argument to the REPORT
macro, as that commit did for DEFINE_ALLOCATOR.
Signed-off-by: Je
Whenever we create a commit object via lookup_commit, we
give it a unique index to be used with the commit-slab API.
The theory is that any "struct commit" we create would
follow this code path, so any such struct would get an
index. However, callers could use alloc_commit_node()
directly (and get
In both blame and merge-recursive, we sometimes create a
"fake" commit struct for convenience (e.g., to represent the
HEAD state as if we would commit it). By allocating
ourselves rather than using alloc_commit_node, we do not
properly set the "index" field of the commit. This can
produce subtle bu
This simplifies the code, as logmsg_reencode handles the
reencoding for us in a single call. It also means we learn
logmsg_reencode's trick of pulling the buffer from disk when
commit->buffer is NULL (we currently just silently return!).
It is doubtful this matters in practice, though, as
sequencer
The return value from logmsg_reencode may be either a newly
allocated buffer or a pointer to the existing commit->buffer.
We would not want the caller to accidentally free() or
modify the latter, so let's mark it as const. We can cast
away the constness in logmsg_free, but only once we have
determ
This converts two lines into one at each caller. But more
importantly, it abstracts the concept of freeing the buffer,
which will make it easier to change later.
Note that we also need to provide a "detach" mechanism for
the weird case in fsck which passes the buffer back to be
freed.
Signed-off-
Right now this is just a one-liner, but abstracting it will
make it easier to change later.
Signed-off-by: Jeff King
---
builtin/blame.c | 2 +-
commit.c| 7 ++-
commit.h| 6 ++
object.c| 2 +-
4 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/builti
Many sites look at commit->buffer to get more detailed
information than what is in the parsed commit struct.
However, we sometimes drop commit->buffer to save memory,
in which case the caller would need to read the object
afresh. Some callers do this (leading to duplicated code),
and others do not
For both of these sites, we already do the "fallback to
read_sha1_file" trick. But we can shorten the code by just
using get_commit_buffer.
Note that the error cases are slightly different when
read_sha1_file fails. get_commit_buffer will die() if the
object cannot be loaded, or is a non-commit.
Some call sites check commit->buffer to see whether we have
a cached buffer, and if so, do some work with it. In the
long run we may want to switch these code paths to make
their decision on a different boolean flag (because checking
the cache may get a little more expensive in the future).
But for
Each of these sites assumes that commit->buffer is valid.
Since they would segfault if this was not the case, they are
likely to be correct in practice. However, we can
future-proof them by using get_commit_buffer.
And as a side effect, we abstract away the final bare uses
of commit->buffer.
Sign
Like the callsites in the previous commit, logmsg_reencode
already falls back to read_sha1_file when necessary.
However, I split its conversion out into its own commit
because it's a bit more complex.
We return either:
1. The original commit->buffer
2. A newly allocated buffer from read_sha1
Callers currently must use init_foo_slab() at runtime before
accessing a slab. For global slabs, it's much nicer if we
can initialize them in BSS, so that each user does not have
to add code to check-and-initialize.
Signed-off-by: Jeff King
---
The calling convention is kind of weird. It goes:
This will make it easier to manage the buffer cache
independently of the "struct commit" objects. It also
shrinks "struct commit" by one pointer, which may be
helpful.
Unfortunately it does not reduce the max memory size of
something like "rev-list", because rev-list uses
get_cached_commit_buffer(
Most callsites which use the commit buffer try to use the
cached version attached to the commit, rather than
re-reading from disk. Unfortunately, that interface provides
only a pointer to the NUL-terminated buffer, with no
indication of the original length.
For the most part, this doesn't matter.
David Kastrup writes:
> Junio C Hamano writes:
>
>> "git blame" has been optimized greatly by reorganising the data
>> structure that is used to keep track of the work to be done, thanks
>> to David Karstrup .
>
> I guess that "reorganising the data structure" for months is not worth
> the tr
Torsten Bögershausen writes:
> The first version of test 23 did simply check that no output was send
> to stderr.
>
> Commit 5e2c7cd2 verified that the expected tags were actually cloned.
>
> Since the day "git clone" printed "Cloning into 'too-many-refs'" to stderr,
Thanks. It is 68b939b2 (clo
Eric,
On Mon, Jun 09, 2014 at 05:53:49AM -0400, Eric Sunshine wrote:
> On Mon, Jun 9, 2014 at 4:36 AM, Jeremiah Mahler wrote:
> > Add documentation of the strbuf_set operations to
> > technical/api-strbuf.txt.
>
> Since this patch is concise and so closely related to patch 1/5, it
> probably sho
Eric,
On Mon, Jun 09, 2014 at 06:12:12AM -0400, Eric Sunshine wrote:
> On Mon, Jun 9, 2014 at 4:36 AM, Jeremiah Mahler wrote:
> > Subject: fast-import.c: cleanup using strbuf_set operations
>
...
>
> > Signed-off-by: Jeremiah Mahler
> > ---
> > fast-import.c | 19 ++-
> > 1 fi
Duy,
On Mon, Jun 09, 2014 at 05:39:12PM +0700, Duy Nguyen wrote:
> On Mon, Jun 9, 2014 at 3:36 PM, Jeremiah Mahler wrote:
> > Currently, the data in a strbuf is modified using add operations. To
> > set the buffer to some data a reset must be performed before an add.
> >
> > strbuf_reset(buf);
David Turner writes:
> Since Junio has picked up the first patch from previous versions of
> this series, I'm just going to send the second (SSE) one. I decided
> not to s/NO_SSE42/!HAVE_SSE42/ because it looks like git mostly uses
> the former convention (for instance, that's what GIT_PARSE_WIT
Version 2 of the patch set to add strbuf_set operations.
Includes suggestions from Eric Sunshine [1]:
- New operations and their documentation placed in one patch.
- Less ambiguous documentation: "Replace the buffer content with [...]"
- Use imperative mood in log messages.
- Don't use
Currently, the data in a strbuf is modified using add operations. To
set the buffer to some data a reset must be performed before an add.
strbuf_reset(buf);
strbuf_add(buf, cb.buf.buf, cb.buf.len);
And this is a common sequence of operations with 70 occurrences found in
the current source co
Simplify cases where a strbuf_reset is immediately followed by a
strbuf_add by using strbuf_set operations.
Signed-off-by: Jeremiah Mahler
---
builtin/checkout.c | 18 ++
1 file changed, 6 insertions(+), 12 deletions(-)
diff --git a/builtin/checkout.c b/builtin/checkout.c
index
Simplify cases where a strbuf_reset is immediately followed by a
strbuf_add by using strbuf_set operations.
Signed-off-by: Jeremiah Mahler
---
branch.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/branch.c b/branch.c
index 660097b..bc7cc7e 100644
--- a/branch.c
+++ b
Simplify cases where a strbuf_reset is immediately followed by a
strbuf_add by using strbuf_set operations.
Signed-off-by: Jeremiah Mahler
---
builtin/branch.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/builtin/branch.c b/builtin/branch.c
index 2d1c57c..ad641b6 100644
Simplify cases where a strbuf_reset is immediately followed by a
strbuf_add by using strbuf_set operations.
Signed-off-by: Jeremiah Mahler
---
sha1_name.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index 2b6322f..f88b66c 100644
Simplify cases where a strbuf_reset is immediately followed by a
strbuf_add by using strbuf_set operations.
Signed-off-by: Jeremiah Mahler
---
builtin/remote.c | 59
1 file changed, 21 insertions(+), 38 deletions(-)
diff --git a/builtin/r
Simplify cases where a strbuf_reset is immediately followed by a
strbuf_add by using strbuf_set operations.
Signed-off-by: Jeremiah Mahler
---
fast-import.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/fast-import.c b/fast-import.c
index e8ec34d..cfe9404 100644
--- a
Simplify cases where a strbuf_reset is immediately followed by a
strbuf_add by using strbuf_set operations.
Signed-off-by: Jeremiah Mahler
---
date.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/date.c b/date.c
index 782de95..0b723a4 100644
--- a/date.c
+++ b/date.c
@@ -
Simplify cases where a strbuf_reset is immediately followed by a
strbuf_add by using strbuf_set operations.
Signed-off-by: Jeremiah Mahler
---
http-backend.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/http-backend.c b/http-backend.c
index d2c0a62..25c7435 100644
--
Simplify cases where a strbuf_reset is immediately followed by a
strbuf_add by using strbuf_set operations.
Signed-off-by: Jeremiah Mahler
---
diffcore-order.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/diffcore-order.c b/diffcore-order.c
index 97dd3d0..5a93971 100644
Simplify cases where a strbuf_reset is immediately followed by a
strbuf_add by using strbuf_set operations.
Signed-off-by: Jeremiah Mahler
---
http.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/http.c b/http.c
index 2b4f6a3..626fed7 100644
--- a/http.c
+++ b/http.c
@@ -
Simplify cases where a strbuf_reset is immediately followed by a
strbuf_add by using strbuf_set operations.
Signed-off-by: Jeremiah Mahler
---
builtin/mailinfo.c | 18 ++
1 file changed, 6 insertions(+), 12 deletions(-)
diff --git a/builtin/mailinfo.c b/builtin/mailinfo.c
index
Simplify cases where a strbuf_reset is immediately followed by a
strbuf_add by using strbuf_set operations.
Signed-off-by: Jeremiah Mahler
---
builtin/tag.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/builtin/tag.c b/builtin/tag.c
index c6e8a71..b545c21 100644
--- a/bui
Simplify cases where a strbuf_reset is immediately followed by a
strbuf_add by using strbuf_set operations.
Signed-off-by: Jeremiah Mahler
---
wt-status.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/wt-status.c b/wt-status.c
index 318a191..a89cd73 100644
--- a/wt-status
Simplify cases where a strbuf_reset is immediately followed by a
strbuf_add by using strbuf_set operations.
Signed-off-by: Jeremiah Mahler
---
ident.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/ident.c b/ident.c
index 1d9b6e7..523e249 100644
--- a/ident.c
+++ b/ide
Simplify cases where a strbuf_reset is immediately followed by a
strbuf_add by using strbuf_set operations.
Signed-off-by: Jeremiah Mahler
---
submodule.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/submodule.c b/submodule.c
index 3402af6..878cc48 100644
--- a/submod
Simplify cases where a strbuf_reset is immediately followed by a
strbuf_add by using strbuf_set operations.
Signed-off-by: Jeremiah Mahler
---
vcs-svn/svndump.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/vcs-svn/svndump.c b/vcs-svn/svndump.c
index 31d1d83..7fbf5d8 1006
Simplify cases where a strbuf_reset is immediately followed by a
strbuf_add by using strbuf_set operations.
Signed-off-by: Jeremiah Mahler
---
remote-curl.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/remote-curl.c b/remote-curl.c
index 4493b38..49d27f5 100644
--- a/rem
Simplify cases where a strbuf_reset is immediately followed by a
strbuf_add by using strbuf_set operations.
Signed-off-by: Jeremiah Mahler
---
transport.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/transport.c b/transport.c
index 172b3d8..e8f5dfa 100644
--- a/transport
On Mon, 2014-06-09 at 15:16 -0700, Junio C Hamano wrote:
> David Turner writes:
>
> > Since Junio has picked up the first patch from previous versions of
> > this series, I'm just going to send the second (SSE) one. I decided
> > not to s/NO_SSE42/!HAVE_SSE42/ because it looks like git mostly us
Jeff King writes:
> diff --git a/notes-merge.c b/notes-merge.c
> index 94a1a8a..7885ab2 100644
> --- a/notes-merge.c
> +++ b/notes-merge.c
> @@ -671,7 +671,8 @@ int notes_merge_commit(struct notes_merge_options *o,
> DIR *dir;
> struct dirent *e;
> struct strbuf path = STRBUF_IN
Junio C Hamano writes:
> David Turner writes:
>
>> Since Junio has picked up the first patch from previous versions of
>> this series, I'm just going to send the second (SSE) one. I decided
>> not to s/NO_SSE42/!HAVE_SSE42/ because it looks like git mostly uses
>> the former convention (for ins
On 07/06/2014 17:52, Philip Oakley wrote:
Just to say there has been a similar confusion about 'git reset'
reported on the Git Users group for the case of reset with added
(staged), but uncommitted changes being wiped out, which simlarly
reports on the difficulty of explaining some of the co
2014-06-09 16:04 GMT+02:00 David Kastrup :
> Pierre-François CLEMENT writes:
>
>> Hi all,
>>
>> Someone pointed out on the "Git for human beings" Google group
>> (https://groups.google.com/d/topic/git-users/27_FxIV_100/discussion)
>> that using git-reset's hard mode when having staged untracked fi
Two test scripts (t3302 and t3419) had copy & paste code to set
USR_BIN_TIME prerequisite. Use the test_lazy_prereq helper to define
them in the common t/test-lib.sh.
Signed-off-by: Junio C Hamano
---
t/t3302-notes-index-expensive.sh | 1 -
t/t3419-rebase-patch-id.sh | 1 -
t/test-lib.sh
This was only necessary because do_tests helper the script defines
took its parameters in a wrong order. Just pass an empty string (or
not passing the optional EXPENSIVE prerequisite) when running the
test with a light-weight set of parameters and have the shell do the
right thing when parsing tes
Use "<<-END_OF_HERE_TEXT" to push the contents of here-text to the
right in order to show the loop structure better.
Use write_script when writing a script to be run.
Use "test" (not "[ ... ]") and avoid unnecessary ";" in the middle
of a line.
Signed-off-by: Junio C Hamano
---
t/t3302-notes-i
Two test scripts (t0021 and t5551) had copy & paste code to set
EXPENSIVE prerequisite. Use the test_lazy_prereq helper to define
them in the common t/test-lib.sh.
Signed-off-by: Junio C Hamano
---
t/t0021-conversion.sh | 2 --
t/t5551-http-fetch.sh | 2 --
t/test-lib.sh | 4
3 fil
These days^Wyears we strive to do stuff in subdirectories inside
subshells to avoid mistakes.
Signed-off-by: Junio C Hamano
---
t/t3302-notes-index-expensive.sh | 27 ++-
1 file changed, 18 insertions(+), 9 deletions(-)
diff --git a/t/t3302-notes-index-expensive.sh b/t/t
This was only necessary because do_tests helper the script defines
took its parameters in a wrong order. Just pass an empty string (or
not passing the optional EXPENSIVE prerequisite) when running the
test with a light-weight set of parameters and have the shell do the
right thing when parsing tes
Elia Pinto writes:
> @@ -1059,13 +1059,17 @@ cmd_summary() {
> while read mod_src mod_dst sha1_src sha1_dst status sm_path
> do
> # Always show modules deleted or type-changed
> (blob<->module)
> - test $status = D -o $status
While reviewing somebody's patch, I noticed that individual test
scripts set EXPENSIVE test prerequisite with copied-and-pasted
lines. Here is a bit to update them, while fixing styles in old
test scripts that had these copied-and-pasted lines.
The last step discards support for GIT_{NOTES,PATCHI
Elia Pinto writes:
> The construct is error-prone; "test" being built-in in most modern
> shells, the reason to avoid "test && test " spawning
> one extra process by using a single "test -a " no
> longer exists.
>
> Signed-off-by: Elia Pinto
> ---
> contrib/examples/git-clone.sh |2 +-
>
Two tests (t3302 and t3419) used to have their own environment
variable to trigger expensive tests without enabling expensive
tests in other scripts; a user could set GIT_NOTES_TIMING_TESTS
but not GIT_TEST_LONG and run the whole test suite and trigger
expensive tests only in t3302 but not other te
Stepan Kasal writes:
> It is sometimes desirable to insert several header lines at the top of
> the body, e.g., if From or Date differs from the mail header.
> (Linus even recommends to use this second header for all kernel
> submissions.)
>
> send-email has a minimal support for this; make sure
On Mon, Jun 09, 2014 at 03:17:07PM +0200, Jens Lehmann wrote:
> And by the way: wouldn't it make more sense to tell the user /what/
> we do automatically? So maybe 'submodule.autoupdate' is a better
> name for the new switch?
Or autocheckout? No need to preserve submodule-specific jargon when
we
Pierre-François CLEMENT writes:
> Hm, I didn't think of "git apply --index"... Makes sense for this
> special use, but I'm not sure about the other use cases.
Try merging another branch that tracks a file your current branch
does not know about and ending up with conflicts during that merge.
Res
On Mon, Jun 09, 2014 at 03:40:57PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > diff --git a/notes-merge.c b/notes-merge.c
> > index 94a1a8a..7885ab2 100644
> > --- a/notes-merge.c
> > +++ b/notes-merge.c
> > @@ -671,7 +671,8 @@ int notes_merge_commit(struct notes_merge_options *o,
> >
If the user explicitly specified a merge strategy or strategy options,
"rebase --interactive" started using the default merge strategy again
after "rebase --continue".
This problem gets fixed by this commit. Add test.
Since the "rebase" options "-s" and "-X" imply "--merge", we can simply
remove
On Mon, Jun 9, 2014 at 8:02 PM, Fabian Ruch wrote:
> If the user explicitly specified a merge strategy or strategy options,
> "rebase --interactive" started using the default merge strategy again
> after "rebase --continue".
For reference, this problem was reported as far back as 2013-08-09 [1].
Hi Eric,
thanks a lot for the reference.
I added the Reported-by: and Signed-off-by: lines to the commit message.
Fabian
-- >8 --
Subject: rebase -i: Remember merge options beyond continue actions
If the user explicitly specified a merge strategy or strategy options,
"rebase --interactive"
On Mon, Jun 09, 2014 at 08:02:24PM -0400, Jeff King wrote:
> I'm still confused and disturbed that my gcc is not noticing this
> obvious const violation. Hmm, shutting off ccache seems to make it work.
> Doubly disturbing.
Ah, mystery solved. It's a gcc bug:
https://gcc.gnu.org/bugzilla/show_b
From: Pierre-François CLEMENT gmail.com>
> You create a new (untracked) file.
> You use git-reset's hard mode to go one commit back, the new
> (untracked) file's still there.
> You add/stage that new file.
> You use git-reset's hard mode again to go one commit back, and the new
> untracked file yo
On Mon, Jun 9, 2014 at 2:10 PM, Jeff King wrote:
> The return value from logmsg_reencode may be either a newly
> allocated buffer or a pointer to the existing commit->buffer.
> We would not want the caller to accidentally free() or
> modify the latter, so let's mark it as const. We can cast
> awa
> On Thu, Jun 5, 2014 at 3:15 AM, Pasha Bolokhov
> wrote:
>> + /* only add it if GIT_DIR does not end with '.git' or '/.git' */
>> + if (len < 4 || strcmp(n_git + len - 4, ".git") ||
>> + (len > 4 && n_git[len - 5] != '/')) {
>
> Hmm.. should we exclude "foobar.git" as well?
On 2014-06-09 21.16, Junio C Hamano wrote:
>> Since the day "git clone" printed "Cloning into 'too-many-refs'" to stderr,
>
> Thanks. It is 68b939b2 (clone: send diagnostic messages to stderr,
> 2013-09-18); before it we showed the message to the standard output
> stream instead.
>
> Will queue
t9001 used a '\n' in a sed expression to split one line into two lines,
but the usage of '\n' in the "replacement string" is not portable.
The '\n' can be used to match a newline in the "pattern space",
but otherwise the meaning of '\n' is unspecified in POSIX.
- Gnu versions of sed will treat '\
On Tue, Jun 10, 2014 at 12:07 AM, Torsten Bögershausen wrote:
> t9001 used a '\n' in a sed expression to split one line into two lines,
> but the usage of '\n' in the "replacement string" is not portable.
>
> The '\n' can be used to match a newline in the "pattern space",
> but otherwise the meani
From: Jeff King
>
> --- a/builtin/blame.c
> +++ b/builtin/blame.c
> @@ -2313,7 +2313,7 @@ static struct commit *fake_working_tree_commit(struct
> diff_options *opt,
> ident, ident, path,
> (!contents_from ? path :
>(!strcmp(contents_from, "-
On Tue, Jun 10, 2014 at 07:12:37AM +0200, Christian Couder wrote:
> From: Jeff King
> >
> > --- a/builtin/blame.c
> > +++ b/builtin/blame.c
> > @@ -2313,7 +2313,7 @@ static struct commit *fake_working_tree_commit(struct
> > diff_options *opt,
> > ident, ident, path,
> >
Steffen Prohaska writes:
> '!f() { ... }; f' is a recommended pattern to declare more complex
> aliases (see git wiki [1]). This commit teaches the completion to
> handle them.
Hmm, I've never endorsed nor recommended such a notation myself ;-)
I tend to prefer writing it like so instead:
1 - 100 of 108 matches
Mail list logo