Kirill Smelkov k...@mns.spb.ru writes:
As was recently shown (c839f1bd combine-diff: optimize
combine_diff_path sets intersection), combine-diff runs very slowly. In
that commit we optimized paths sets intersection, but that accounted
only for ~ 25% of the slowness, and as my tracing showed,
Junio C Hamano gits...@pobox.com writes:
Kirill Smelkov k...@mns.spb.ru writes:
As was recently shown (c839f1bd combine-diff: optimize
combine_diff_path sets intersection), combine-diff runs very slowly. In
that commit we optimized paths sets intersection, but that accounted
only for ~ 25
Philip Oakley philipoak...@iee.org writes:
If we are progressing from V1.9 to V2.0 quickly (one cycle?), which I
understand is the plan, then mixing the minor development items (patch
series which progress to master) with the maintenance fixes over the
next few months, thus only having 1.9.x
Kirill Smelkov k...@mns.spb.ru writes:
+ parents_sha1 = xmalloc(nparent * sizeof(parents_sha1[0]));
+ for (i = 0; i nparent; i++)
+ parents_sha1[i] = parents-sha1[i];
+
+ /* fake list head, so worker can assume it is non-NULL */
+ struct combine_diff_path
Martin Erik Werner martinerikwer...@gmail.com writes:
Then it seems like one could get rid of npath completely:
Yes. And you need to remove its definition as well to avoid unused
variable warning.
Will queue with an obvious fix-up.
Thanks.
diff --git a/setup.c b/setup.c
index
Torsten Bögershausen tbo...@web.de writes:
[]
So to summarize, when fast-import uses strncmp_icase (what fast-import does
now) import on a repository where ignorecase=true is wrong. My patch,
fast-import.c: always honor the filename case fixes this. Can you verify?
Thanks in advance,
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
The tip of 'master' is at 1.9-rc2.
You can find the changes described here in the integration branches
of the repositories listed at
Martin Erik Werner martinerikwer...@gmail.com writes:
Will you add that test or should I place it in the series with you as
author?
Either is fine. Thanks.
On Mon, Feb 03, 2014 at 01:00:48PM -0800, Junio C Hamano wrote:
Martin Erik Werner martinerikwer...@gmail.com writes:
The path
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
Housekeeping jobs like auto gc generally should not get in the way.
Users who are pushing may not want to wait until auto gc is done on
the server. Give a hint for those users that it's safe now to break
git push and stop waiting.
Junio C Hamano gits...@pobox.com writes:
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
Housekeeping jobs like auto gc generally should not get in the way.
Users who are pushing may not want to wait until auto gc is done on
the server. Give a hint for those users that it's safe now to break
Kirill Smelkov k...@mns.spb.ru writes:
if we did not want to reinvent the whole tree walking thing, which
would add risks for new bugs and burden to maintain this and the
usual two-tree diff tree walking in sync.
Junio, I understand it is not good to duplicate code and increase
maintenance
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
This goes far back to e84fb2f (branch --contains: default to HEAD -
2008-07-08) where the same parsing code is shared with
builtin/tag.c. git-branch.txt correctly states that commit for
--contains is optional while git-tag.txt does not. Correct
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
@@ -128,13 +129,20 @@ static void update_index_from_diff(struct
diff_queue_struct *q,
one-path);
add_cache_entry(ce, ADD_CACHE_OK_TO_ADD |
Martin Erik Werner martinerikwer...@gmail.com writes:
+ const char* work_tree = get_git_work_tree();
Style: asterisk sticks to the variable, not type.
No need to resend---all patches looked reasonable.
Thanks, will queue.
--
To unsubscribe from this list: send the line unsubscribe git in
Torsten Bögershausen tbo...@web.de writes:
On 2014-02-04 15.25, Martin Erik Werner wrote:
t/t0060-path-utils.sh | 10 ++
1 file changed, 10 insertions(+)
diff --git a/t/t0060-path-utils.sh b/t/t0060-path-utils.sh
index b8e92e1..c0a14f6 100755
--- a/t/t0060-path-utils.sh
+++
Miklos Vajna vmik...@collabora.co.uk writes:
Hi,
I was trying to understand the history of a piece of code in LibreOffice
and I'm facing a behaviour of git-log which is not something I can
explain. I'm not sure if this is a git bug or a user error. ;)
Here is the situation:
git clone
David Kastrup d...@gnu.org writes:
Making a single preparation run for counting the lines will avoid memory
fragmentation. Also, fix the allocated memory size which was wrong
when sizeof(int *) != sizeof(int), and would have been too small
for sizeof(int *) sizeof(int), admittedly unlikely.
David Kastrup d...@gnu.org writes:
Whitespace error in line 1778. Should I be reposting?
Heh, let me try to clean it up first and then repost for your
review.
Thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More
Junio C Hamano gits...@pobox.com writes:
David Kastrup d...@gnu.org writes:
Whitespace error in line 1778. Should I be reposting?
Heh, let me try to clean it up first and then repost for your
review.
Thanks.
-- 8 --
From: David Kastrup d...@gnu.org
Making a single preparation run
David Kastrup d...@gnu.org writes:
Anybody know offhand what I should be including here? It looks like Git
has some fallback definitions of its own, so it's probably not just
string.h I should include?
In general, no *.c files outside the compatibility layer should
include anything #include
David Kastrup d...@gnu.org writes:
Junio C Hamano gits...@pobox.com writes:
David Kastrup d...@gnu.org writes:
Anybody know offhand what I should be including here? It looks like Git
has some fallback definitions of its own, so it's probably not just
string.h I should include
David Kastrup d...@gnu.org writes:
Ok, I now wrote
for (p = buf;; num++, p++) {
p = memchr(p, '\n', end - p);
if (!p)
break;
}
Looks still wrong (perhaps this is a taste issue).
num++ is not loop control, but the real
David Kastrup d...@gnu.org writes:
so something like
for (p = buf; p end; p++) {
p = find the end of this line
if (!p)
break;
num++;
}
perhaps?
Would crash on incomplete last line.
Hmph, even with if !p? From
Jeff King p...@peff.net writes:
But there's another set of people that I was intending to help with the
patch, which is people that have set up LESS, and did not necessarily
care about the R flag in the past (e.g., for many years before git
came along, I set LESS=giM, and never even knew that
Junio C Hamano gits...@pobox.com writes:
While I do not have any problem with adding an optional keep lost
paths as intent-to-add entries feature, I am not sure why this has
to be so different from the usual add-cache-entry codepath. The
if/elseif chain you are touching inside this loop does
Start from an empty repository like so:
: gitster track; git init
Initialized empty Git repository in /var/tmp/x/track/.git/
: gitster track/master; git commit --allow-empty -m initial
[master (root-commit) abdcd1c] initial
: gitster track/master; git branch foo
: gitster
Jeff King p...@peff.net writes:
The safest thing would be to turn off auto-color when LESS (or any of
the pager environment variables) is set at all (and not worry about
whether R is set; only know that _we_ are not setting it, so we cannot
count on it). But that would potentially
Thomas Rast t...@thomasrast.ch writes:
log --remerge-diff: show what the conflict resolution changed
Yay ;-)
This series explores another angle, which I call remerge diff. It
works by re-doing the merge in core, using features from patches 1-3
and 7. Likely that will result in
for:
fname for the final name of the new packfile, fname_old for the name
of the existing one, and fname_tmp for the temporary name pack-objects
created the new packfile in.
Signed-off-by: Torsten Bögershausen tbo...@web.de
Signed-off-by: Junio C Hamano gits...@pobox.com
---
* Somehow this came to my
Junio C Hamano gits...@pobox.com writes:
This comment in builtin/repack.c:
...
Oops; there was supposed to be these lines before anythning else:
From: Torsten Bögershausen tbo...@web.de
Date: Sun Feb 2 16:09:56 2014 +0100
First see if there are packs of the same name
Duy Nguyen pclo...@gmail.com writes:
On Tue, Feb 04, 2014 at 02:25:25PM -0800, Junio C Hamano wrote:
Junio C Hamano gits...@pobox.com writes:
While I do not have any problem with adding an optional keep lost
paths as intent-to-add entries feature, I am not sure why this has
to be so
Adrian Johnson ajohn...@redneon.com writes:
-|[0-9][-+0-9#_.eE]
+|[-+]?[0-9][0-9#_.aAbBcCdDeEfF]*([eE][+-]?[0-9_]+)?
This would match a lot wider than what I read you said you wanted to
match in your previous message. Does -04##4_3_2Ee-9 count as a
number, for example, or can we
Kirill Smelkov k...@mns.spb.ru writes:
Only, before I clean things up, I'd like to ask - would the following
patch be accepted
8 ---
diff --git a/tree-walk.c b/tree-walk.c
index 79dba1d..4dc86c7 100644
--- a/tree-walk.c
+++ b/tree-walk.c
@@ -37,7 +37,7 @@ static void
Junio C Hamano gits...@pobox.com writes:
Duy Nguyen pclo...@gmail.com writes:
On Tue, Feb 04, 2014 at 02:25:25PM -0800, Junio C Hamano wrote:
Junio C Hamano gits...@pobox.com writes:
While I do not have any problem with adding an optional keep lost
paths as intent-to-add entries feature
Matthieu Moy matthieu@grenoble-inp.fr writes:
乙酸鋰 ch3co...@gmail.com writes:
add --recurse-submodules
Thanks for the patch, but it cannot be included as-is.
Please, read Documentation/SubmittingPatches in Git's source tree. In
particular, the signed-off-by part. Also, don't use
All four looked sensible; will queue. Thanks.
--
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://vger.kernel.org/majordomo-info.html
Jeff King p...@peff.net writes:
This patch moves all of the generated GIT-* files into
MAKE/*, with one exception: GIT-VERSION-FILE. This could be
moved along with the rest, but there is a reasonable chance
that there are some out-of-tree scripts that may peek at it
(whereas things like
Jeff King p...@peff.net writes:
We have to c-quote strings coming from Makefile variables
when we pass them to the compiler via -D. Now that we can
use $(call) in our Makefile, we can factor out the quoting
to make things easier to read. We can also apply it more
consistently, as there were
Jeff King p...@peff.net writes:
Since we have recently abolished the prohibition on $(call)
in our Makefile, we can use it to factor out the repeated
shell-quoting we do. There are two upsides:
1. It is much more readable than inline calls to
$(subst ','\'').
2. It is short
Again, Yay!
--
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://vger.kernel.org/majordomo-info.html
Jeff King p...@peff.net writes:
diff --git a/script/mkcstring b/script/mkcstring
new file mode 100644
index 000..c01f430
--- /dev/null
+++ b/script/mkcstring
@@ -0,0 +1,18 @@
+#!/bin/sh
+
+name=$1; shift
+
+c_quote() {
+ sed 's/\\//g; s//\\/'
No 'g' for the second one?
Jeff King p...@peff.net writes:
define cmd_munge_script
$(RM) $@ $@+ \
+{ \
+includes=$(filter MAKE/%.sh,$^); \
+if ! test -z $$includes; then \
+ cat $$includes; \
+fi \
sed -e '1s|#!.*/sh|#!$(call sqi,$(SHELL_PATH))|' \
-e 's|@SHELL_PATH@|$(call sqi,$(SHELL_PATH))|' \
-
Kirill Smelkov k...@navytux.spb.ru writes:
I agree object data should be immutable for good. The only thing I'm talking
about here is mode, which is parsed from a tree buffer and is stored in
separate field:
Ah, I do not see any problem in that case, then.
Thanks.
--
To unsubscribe from this
name of the new packfile, fname_old for the name of the
existing one, and fname_tmp for the temporary name pack-objects
created the new packfile in.
Signed-off-by: Torsten Bögershausen tbo...@web.de
Signed-off-by: Junio C Hamano gits...@pobox.com
---
builtin/repack.c | 22 +++---
1
Jeff King p...@peff.net writes:
The minimal fix you posted below does make sense to me as a stopgap, and
we can look into dropping the code entirely during the next cycle. It
would be nice to have a test to cover this case, though.
Sounds sensible. Run repack -a -d once, and then another
David Kastrup d...@gnu.org writes:
Junio C Hamano gits...@pobox.com writes:
which I think is the prevalent style in our codebase. The same for
the other loop we see in the new code below.
- avoid assignments in conditionals when you do not have to.
commit
Jeff King p...@peff.net writes:
On Tue, Feb 04, 2014 at 03:40:15PM -0800, Junio C Hamano wrote:
* Somehow this came to my private mailbox without Cc to list, so I
am forwarding it.
I think with 1190a1ac (pack-objects: name pack files after
trailer hash, 2013-12-05), repacking
David Kastrup d...@gnu.org writes:
It's snake oil making debugging harder.
OK, that is a sensible argument.
This was fun ;-)
At the expense of seriously impacting my motivation to do any further
code cleanup on Git.
Well, I said it was fun because I was learning from a new person
who
Jeff King p...@peff.net writes:
On Wed, Feb 05, 2014 at 12:31:34PM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
The minimal fix you posted below does make sense to me as a stopgap, and
we can look into dropping the code entirely during the next cycle. It
would be nice
Jeff King p...@peff.net writes:
Is it legal to put an unqualified ref there? A wise man once said[1]:
Actually, it is broken in a lot of places. for-each-ref relies on
the same code as git status, git checkout, etc, which will all
fail to display tracking info. I believe the same
Jeff King p...@peff.net writes:
... So the fact that this
bug exists doesn't really produce any user-visible behavior, and
hopefully post-release we would drop the code entirely, and the test
would have no reason to exist.
Heh, thanks, and I agree with the reasoning for the longer-term
Jeff King p...@peff.net writes:
Did your report come
out of a real case, or was it just something you noticed?
Some git-wrappers (like repo) are reported to muck with the
configuration files.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to
Øystein Walle oys...@gmail.com writes:
Signed-off-by: Øystein Walle oys...@gmail.com
---
In July I sent in some typo fixes but it halted in a discussion on UK
vs. US English and so forth ($gmane/231331). There were some actual typo
fixes in there though (in addition to the opinionated typo
Kirill Smelkov k...@navytux.spb.ru writes:
On Wed, Feb 05, 2014 at 11:42:41AM -0800, Junio C Hamano wrote:
Kirill Smelkov k...@navytux.spb.ru writes:
I agree object data should be immutable for good. The only thing I'm
talking
about here is mode, which is parsed from a tree buffer
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
v1.9.0-rc3 is expected to happen this weekend or early next week.
You can find the changes described here in the integration branches
of the
On Wed, Feb 5, 2014 at 3:48 PM, Duy Nguyen pclo...@gmail.com wrote:
No no. I found that duplicate, but I did not suggest removing it
because it is needed there..
Hmph, if that is the case, we probably should make it the
responsibility of the calling side to actually mark ce-flags with the
bit
Junio C Hamano gits...@pobox.com writes:
On Wed, Feb 5, 2014 at 3:48 PM, Duy Nguyen pclo...@gmail.com wrote:
No no. I found that duplicate, but I did not suggest removing it
because it is needed there..
Hmph, if that is the case, we probably should make it the
responsibility of the calling
Lasse Makholm lasse.makh...@gmail.com writes:
Here's a repro with -DDEBUG_ATTR=1 and a printf() in read_attr_from_file():
$ cd /tmp/
$ mkdir -p attr-test/repo
$ cd attr-test/repo
$ git init
Initialized empty Git repository in /tmp/attr-test/repo/.git/
$ echo 'dir/* filter=foo'
places.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
* This is purely a preparatory clean-up in the test script I'll be
adding a new test to in the next patch.
t/t0003-attributes.sh | 52 +--
1 file changed, 30 insertions(+), 22 deletions
in a bare repository just like
check-attr attempts to be.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
builtin/check-attr.c | 3 +++
t/t0003-attributes.sh | 10 ++
2 files changed, 13 insertions(+)
diff --git a/builtin/check-attr.c b/builtin/check-attr.c
index 075d01d..f29d6c3
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
It's introduced in 1bd8c8f (git-upload-pack: Support the multi_ack
protocol - 2005-10-28) but probably better documented in the commit
message of 78affc4 (Add multi_ack_detailed capability to
fetch-pack/upload-pack - 2009-10-30)
Signed-off-by:
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
See 3e63b21 (upload-pack: Implement no-done capability - 2011-03-14)
and 761ecf0 (fetch-pack: Implement no-done capability - 2011-03-14)
for more information.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
In smart http, upload-pack adds new shallow lines at the beginning of
each rpc response. Only shallow lines from the first rpc call are
useful. After that they are thrown away. It's designed this way
because upload-pack is stateless and has no
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
Reported by Jeff [1]. Junio spotted it right but nobody made any move
since then.
Hrm. Was I supposed to make any move at that point? The discussion
ended by me asking a question what happens if we did X? and there
was no discussion.
The main
Jonathan Nieder jrnie...@gmail.com writes:
Junio C Hamano wrote:
Moving to some other directory and letting the remainder of the test
pieces to expect that they start there is a bad practice.
I agree with the above, and I like the patch
Jonathan Nieder jrnie...@gmail.com writes:
Someone asked in a private reply how this interacts with t0003.
It was me mistakenly using reply not reply all.
t0003 tries check-attr in a bare repository. The question is, is that
a desirable feature, and are people relying on it?
Running
Jonathan Nieder jrnie...@gmail.com writes:
For a while I've been wanting to teach GIT_SKIP_TESTS not to skip
tests with 'setup' or 'set up' in their name, but I never got around
to it.
Yeah, that would be a good thing. As part of doing so, we might
want to come up with a way to test the
Thomas Rast t...@thomasrast.ch writes:
Kirill Smelkov k...@mns.spb.ru writes:
Since diff_tree_sha1() can now accept empty trees via NULL sha1, we
could just call it without manually reading trees into tree_desc and
duplicating code.
Cc: Thomas Rast t...@thomasrast.ch
Signed-off-by: Kirill
Christian Couder chrisc...@tuxfamily.org writes:
It is simpler and more natural if the git interpret-trailers
is made a filter as its output already goes to sdtout.
sdtout???
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
builtin/interpret-trailers.c | 2 +-
Christian Couder chrisc...@tuxfamily.org writes:
We will use a doubly linked list to store all information
about trailers and their configuration.
This way we can easily remove or add trailers to or from
trailer lists while traversing the lists in either direction.
Signed-off-by: Christian
Christian Couder chrisc...@tuxfamily.org writes:
+ enum action_if_exist if_exist;
+ enum action_if_missing if_missing;
Probably if_exists is more gramatically correct.
if (x-if_exists) {
... do this ...
}
would read well, but not x-if_exist.
Christian Couder chrisc...@tuxfamily.org writes:
This patch implements the logic that process trailers
from file and arguments.
At the beginning trailers from file are in their own
infile_tok doubly linked list, and trailers from
arguments are in their own arg_tok doubly linked list.
The
Christian Couder chrisc...@tuxfamily.org writes:
This patch parses the trailer command line arguments
and put the result into an arg_tok doubly linked
list.
No the patch doesn't parse anything ;-).
Parse the command line arguments and
+static void parse_trailer(struct strbuf *tok,
Christian Couder chrisc...@tuxfamily.org writes:
diff --git a/git.c b/git.c
index 3799514..1420b58 100644
--- a/git.c
+++ b/git.c
@@ -383,6 +383,7 @@ static void handle_internal_command(int argc, const char
**argv)
{ index-pack, cmd_index_pack, RUN_SETUP_GENTLY },
Christian Couder chrisc...@tuxfamily.org writes:
+
+cat basic_message 'EOF'
+subject
+
+body
+EOF
+
+cat complex_message_body 'EOF'
+my subject
+
+my body which is long
+and contains some special
+chars like : = ? !
+
+EOF
+
+# We want one trailing space at the end of each line.
Christian Couder chrisc...@tuxfamily.org writes:
It is simpler and more natural if the git interpret-trailers
is made a filter as its output already goes to sdtout.
sdtout?
Why isn't this a pure filter without any infile parameter in the
first place?
Signed-off-by: Christian Couder
Christian Couder chrisc...@tuxfamily.org writes:
+#define TRAILER_ARG_STRING $ARG
No need to support users who may want to use a string that happens
to match this substring literally as part of the command line?
struct trailer_item {
struct trailer_item *previous;
struct
Christian Couder chrisc...@tuxfamily.org writes:
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
trailer.c | 30 +-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/trailer.c b/trailer.c
index 98187fc..b5de616 100644
--- a/trailer.c
Christian Couder chrisc...@tuxfamily.org writes:
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
trailer.c | 30 +-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/trailer.c b/trailer.c
index 98187fc..b5de616 100644
--- a/trailer.c
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
diff --git a/t/t5537-fetch-shallow.sh b/t/t5537-fetch-shallow.sh
index b0fa738..fb11073 100755
--- a/t/t5537-fetch-shallow.sh
+++ b/t/t5537-fetch-shallow.sh
@@ -200,5 +200,29 @@ EOF
)
'
+# This test is tricky. We need large enough
Christian Couder christian.cou...@gmail.com writes:
On Fri, Feb 7, 2014 at 1:10 AM, Junio C Hamano gits...@pobox.com wrote:
Christian Couder chrisc...@tuxfamily.org writes:
diff --git a/git.c b/git.c
index 3799514..1420b58 100644
--- a/git.c
+++ b/git.c
@@ -383,6 +383,7 @@ static void
Christian Couder chrisc...@tuxfamily.org writes:
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
execute command from ... is fine, but I wish there were more
details before S-o-b line. Is is not worth explaining what happens
to the output, and what the facility is used for in general?
Jonathan Nieder jrnie...@gmail.com writes:
Duy Nguyen wrote:
Don't take it the wrong way. I was just summarizing the last round. It
surprised me though that this went under my radar. Perhaps a bug
tracker is not a bad idea after all (if Jeff went missing, this bug
could fall under the
Junio C Hamano gits...@pobox.com writes:
... RUN_SETUP at 7/14 and then change the same line to have RUN_SETUP
when you start to need it could be an option; I am *not* suggesting
that.
Sorry, typo. s/could be an option;/;/
--
To unsubscribe from this list: send the line unsubscribe git
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
The tip of 'master' has been tagged as v1.9.0-rc3. As a workaround
to make life easier for third-party tools, the upcoming major
release will
started
with the same byte value, due to a race condition.
(merge b2476a6 jh/loose-object-dirs-creation-race later to maint).
Changes since v1.9-rc2 are as follows:
Adrian Johnson (1):
userdiff: update Ada patterns
Junio C
Pavan Kumar Sunkara pavan.sss1...@gmail.com writes:
Golang is quickly becoming one of the major programming languages.
This change switches on golang syntax highlight support by default
in gitweb rather than asking the users to do it using config files.
Looks trivially harmless ;-)
I
Jens Lehmann jens.lehm...@web.de writes:
I think the user needs to sort things out, just like she has to do
when a file has a merge conflict. But unfortunately we cannot use
conflict markers here, so I'd propose the following:
* When merge proposes a merge resolution (which it does today by
Pavan Kumar Sunkara pavan.sss1...@gmail.com writes:
Sorry. I misunderstood your message. Yes, I guess lazy loading the
supported file extensions would be better. But not all highlighters
support `-p` option. So, I think its better to leave it to the user.
Yes, those highlighters that do not
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
Trailing spaces are invisible in most standard editors (*). git diff
does show trailing spaces by default. But that does not help newly
written .gitignore files. And trailing spaces are the source of
frustration when writing .gitignore.
So
Junio C Hamano gits...@pobox.com writes:
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
Trailing spaces are invisible in most standard editors (*). git diff
does show trailing spaces by default. But that does not help newly
written .gitignore files. And trailing spaces are the source
Christian Couder chrisc...@tuxfamily.org writes:
This is what if_exists and if_missing are all about.
Either:
the same key already exists regardless of the value
and, in this case, what happens depends on what has been specified using
the if_exists configuration variable.
Or:
Duy Nguyen pclo...@gmail.com writes:
On Fri, Feb 07, 2014 at 10:01:08AM -0800, Junio C Hamano wrote:
Here is the difference between the posted series and what I queued
after applying the changes suggested during the review.
Thanks.
I was going to send a reroll after the received comments
Jeff King p...@peff.net writes:
Here it is as a Real Patch™. I just based it on master, so it can
replace your 5537/5538 fix in your series.
Thanks, looks good. Will put this at the bottom and rebuild the
nd/http-fetch-shallow-fix series on top.
1. Is there anybody who has apache
Thomas Rast t...@thomasrast.ch writes:
Junio C Hamano gits...@pobox.com writes:
Matthieu Moy matthieu@grenoble-inp.fr writes:
[...]
don't forget to Cc Junio if
you think your patch is ready for inclusion.
Heh, thanks. Everybody seems to think anything they send out to the
list
Duy Nguyen pclo...@gmail.com writes:
On Mon, Feb 10, 2014 at 6:03 PM, Erik Faye-Lund kusmab...@gmail.com wrote:
`gc --auto` takes time and can block the user temporarily (but not any
- if (!quiet)
- fprintf(stderr,
-
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
diff --git a/setup.c b/setup.c
index 6c3f85f..b09a412 100644
--- a/setup.c
+++ b/setup.c
@@ -787,3 +787,27 @@ void sanitize_stdfds(void)
if (fd 2)
close(fd);
}
+
+int daemonize(void)
+{
+#ifdef NO_POSIX_GOODIES
+
Ingo Rohloff lund...@gmx.de writes:
To handle that I setup several remote tracking branches called:
repo1_master (tracks repo1/master)
repo2_master (tracks repo2/master)
reap3_master (tracks repo3/master)
Now without push.default=upstream I would have to either always explicitly
On Mon, Feb 10, 2014 at 10:43 AM, Junio C Hamano gits...@pobox.com wrote:
If --quiet is set, we should not be printing anyway. If not, I thinkg
we could only print auto packing in background.. when we actually
can do that, else just print the old message. It means an #ifdef
NO_POSIX_GOODIES
Karsten Blees karsten.bl...@gmail.com writes:
... At the very least we shouldn't
stall the rest of the patch series on a hunch that the last
(unfortunately non-standard) patch may break on some legacy
system.
Oh, no question about it. I was planning split out the last one and
merge the rest
301 - 400 of 27729 matches
Mail list logo
