Junio C Hamano gits...@pobox.com writes:
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
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 a77a48c259d9adbe7779ca69a3432e493116b3fd
Author: Junio C Hamano
On Mon, Feb 03, 2014 at 03:10:08PM -0800, Junio C Hamano wrote:
Kirill Smelkov k...@mns.spb.ru writes:
where correct paths stands for paths that are different to all
parents.
Up until now, we were testing combined diff only on one file, or on
several files which were all different
On 04/02/14 06:30, Junio C Hamano wrote:
Adrian Johnson ajohn...@redneon.com writes:
- Allow extra space in is new and is separate
- Fix bug in word regex for numbers
Signed-off-by: Adrian Johnson ajohn...@redneon.com
---
t/t4034/ada/expect | 2 +-
userdiff.c | 4 ++--
2 files
add --recurse-submodules
From 0390a24e2653e0cdb6bfb9a569c28e4d58002038 Mon Sep 17 00:00:00 2001
From: Sup Yut Sum ch3co...@gmail.com
Date: Wed, 5 Feb 2014 23:09:46 +0800
Subject: [PATCH 1/1] bash completion: Add --recurse-submodules
---
contrib/completion/git-completion.bash | 19
乙酸鋰 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 attachments to send
you patches (git send-email can help) and
On Tue, Feb 04, 2014 at 10:37:24AM -0800, Junio C Hamano wrote:
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
Some preparatory patches for my reworked nparent tree-walker. Please apply.
Thanks beforehand,
Kirill
Kirill Smelkov (4):
tree-diff: allow diff_tree_sha1 to accept NULL sha1
tree-diff: convert diff_root_tree_sha1() to just call diff_tree_sha1
with old=NULL
line-log: convert to using
which would mean that corresponding tree - old or new - is empty.
As followup patches will show, that functionality was already needed in
several places of Git codebase, but there, we were preparing empty
tree_desc objects by hand, with some code duplication.
For handling sha1 = NULL case, let's
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.
Besides, that
if (!tree)
return 0;
looked suspect - we were saying an invalid tree != empty tree, but maybe it is
Now since diff_tree_sha1 understands NULL for both old and new, we could
indicate an empty tree for root commit by providing just NULL for old
sha1.
Signed-off-by: Kirill Smelkov k...@mns.spb.ru
---
tree-diff.c | 15 +--
1 file changed, 1 insertion(+), 14 deletions(-)
diff --git
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 Smelkov k...@mns.spb.ru
---
line-log.c | 26 ++
1 file
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
On Wed, Feb 05, 2014 at 07:55:09AM +0100, Michael Haggerty wrote:
* René Scharfe submitted a patch to use a function parse_prefix()
(originally suggested by Peff) instead of Duy's suggested approach:
http://article.gmane.org/gmane.comp.version-control.git/239569
His patch
On Wed, Feb 05, 2014 at 09:17:47AM -0800, Junio C Hamano wrote:
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
On Wed, Feb 05, 2014 at 08:57:08PM +0400, Kirill Smelkov wrote:
Kirill Smelkov (4):
tree-diff: allow diff_tree_sha1 to accept NULL sha1
tree-diff: convert diff_root_tree_sha1() to just call diff_tree_sha1
with old=NULL
line-log: convert to using diff_tree_sha1()
revision:
On Wed, Feb 05, 2014 at 08:57:12PM +0400, Kirill Smelkov wrote:
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.
Besides, that
if (!tree)
return 0;
looked
This started with the desire to move the setting of the LESS and LV
environment variables into a Makefile knob. But there's a fair bit of
infrastructure involved in that, and this is an attempt to factor out
some of that infrastructure to be more easily reusable. And if we like
the approach, we
We build git-instaweb if NO_PERL is not defined, and it in
turns depends on gitweb, which causes us to descend into
the gitweb subdir and recursively invoke make. But because
gitweb is marked as .PHONY, this forces a rebuild of
git-instaweb every time we run make.
We can drop the dependency of
We create GIT-CFLAGS and related files by echoing into a
shell redirection. It's possible for an error to cause the
file to end up empty or truncated. In theory, this could
cause us to later make an incorrect comparison of the file
contents to a Makefile variable, and avoid rebuilding some
If we are trying to store an empty sentinel value for a
make-var, we would consider a missing file the same as an
empty variable. E.g., repeatedly running:
make GIT_USER_AGENT=
will not create MAKE/USER-AGENT at all if it does not exist,
and subsequent make invocations will force a rebuild.
The Makefile creates files like GIT-CFLAGS to keep track of
the make variables used in the last build. We have a number
of these files now, all starting with GIT-*. Let's move them
into their own subdirectory, which has two advantages:
1. It's less clutter in the main directory.
2. Each file
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 many spots that should have been
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 enough that we can do away with the _SQ
Now that all uses of the SQ variables have been dropped, we
can stop setting the variables.
Signed-off-by: Jeff King p...@peff.net
---
Makefile | 28
1 file changed, 28 deletions(-)
diff --git a/Makefile b/Makefile
index b1c3fb4..cd07a70 100644
--- a/Makefile
+++
It's a common pattern in our Makefile to echo some make
variables into a file, but only if they are different from a
previous run. This sentinel file can then be used as a
dependency to trigger rebuilds when the make variable
changes.
The code to do this is a bit ugly and repetetive; let's
factor
This variable is used only by shell scripts, not by C
programs. It was originally included in GIT-CFLAGS as part
of ad17ea7 (add a Makefile switch to avoid gettext
translation in shell scripts, 2012-01-23), in an attempt to
trigger rebuilding when the variable changed.
However, shell scripts do
We already insert the values of some make variables into
files in MAKE/*. We can therefore build a simple pattern
rule for converting such a value into a C string in a header
file, which can then be included and used as normal.
The new system is demonstrated on version.c, where it can
replace the
We set the LESS and LV variables to sensible defaults if
they are not already set. However, the code is brittle.
There is no easy way to change the defaults at compile time,
and we have to duplicate the code in git-sh-setup and in
pager.c.
Let's turn it into a normal Makefile knob instead.
The current scheme for getting build-time variables into a
shell script is to munge the script with sed, and stick the
munged variable into a special sentinel file so that make
knows about the dependency.
Instead, we can combine both functions by generating a shell
snippet with our value, and
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
On 2014-02-05 02.16, Jeff King wrote:
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),
When we write Makefile variables to a sentinel file, we use
echo to do so. Since we are writing arbitrary data which
may contain backslash escapes (particularly with file paths
on Windows), echo may or may not expand those escapes,
depending on which shell is in use.
During the next run of make,
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
On Wed, Feb 05, 2014 at 09:36:55AM -0800, Junio C Hamano wrote:
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
---
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?
On Wed, Feb 05, 2014 at 11:13:24AM -0800, Junio C Hamano wrote:
+# Quote the value as C string inside a shell string. Good for passing
strings
+# on the command line via -DFOO=$(call # scq,$(FOO)).
call # scq???
Whoops. Bad rewrapping of the comment. It should obviously just be
On Wed, Feb 05, 2014 at 11:17:13AM -0800, Junio C Hamano wrote:
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
+
On Wed, Feb 05, 2014 at 01:08:57PM -0500, Jeff King wrote:
+quote() {
+ echo $1 | sed 's/\\//g; s//\\/'
+}
This of course has the same /g bug as the earlier patch in the series.
I was tempted to pull the function out into script/lib-c.sh, so that
both can source it, but perhaps that
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
On Wed, Feb 05, 2014 at 11:26:58AM -0800, Junio C Hamano wrote:
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
On Wed, Feb 05, 2014 at 02:23:50PM -0500, Jeff King wrote:
On Wed, Feb 05, 2014 at 01:08:57PM -0500, Jeff King wrote:
+quote() {
+ echo $1 | sed 's/\\//g; s//\\/'
+}
This of course has the same /g bug as the earlier patch in the series.
I was tempted to pull the function out
... and this is the other half that is supposed to be only about
renaming variables.
-- 8 --
From: Torsten Bögershausen tbo...@web.de
Date: Sun, 2 Feb 2014 16:09:56 +0100
Subject: [PATCH] repack.c: rename a few variables
Rename the variables to match what they are used for: fname for the
final
On Wed, Feb 05, 2014 at 12:06:41PM -0800, Junio C Hamano wrote:
Actually, since 1190a1ac, if you have repacked and gotten the same pack
name, then you do not have to do any rename dance at all; you can throw
away what you just generated because you know that it is byte-for-byte
identical.
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 and is stored in
separate field:
Ah, I do not
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
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 to have a test to cover this case,
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
On Tue, Feb 04, 2014 at 02:49:16PM -0800, Junio C Hamano wrote:
Let's tell these branches that they are both supposed to be building
on top of 'master'.
: gitster track/master; git config branch.foo.remote .
: gitster track/master; git config branch.foo.merge refs/heads/master
On Wed, Feb 05, 2014 at 03:37:40PM -0500, Jeff King wrote:
Sounds sensible. Run repack -a -d once, and then another while
forcing it to be single threaded, or something?
Certainly that's the way to trigger the code, but doing this:
[...]
...does not seem to fail, and it does not seem to
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
On 2014-02-05 21.31, 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 to have a test to cover this case, though.
Sounds
On Wed, Feb 05, 2014 at 12:57:14PM -0800, Junio C Hamano wrote:
...does not seem to fail, and it does not seem to leave any cruft in
place. So maybe I am misunderstanding the thing the patch is meant to
fix. Is it that we simply do not replace the pack in this instance?
Yes. Not just
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
On Wed, Feb 05, 2014 at 01:05:04PM -0800, Junio C Hamano wrote:
I don't recall us ever doing anything after that. I don't have a problem
with making it work, of course, but I am not sure if it is really a bug.
Once people get used to us being extra nice in some places, other
less nice
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
On Wed, Feb 05, 2014 at 01:08:36PM -0800, Junio C Hamano wrote:
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.
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
On 2014-02-03 23.11, Reuben Hawkins wrote:
On Mon, Feb 3, 2014 at 2:21 PM, Torsten Bögershausen tbo...@web.de
mailto:tbo...@web.de wrote:
[]
So to summarize, when fast-import uses strncmp_icase (what fast-import
does now) import on a repository where ignorecase=true is wrong.
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 fixes).
Powering up my old laptop for the
Ø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
This Saturday I'm going to be attending a Git hackday held by Bloomberg
in New York. The participants will be eager C coders who have experience
using git, but not contributing to it. As somebody who has read The
Mythical Man Month, I don't expect huge productivity, but I'm hoping to
do some bug
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 and
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
Junio C Hamano gits...@pobox.com writes:
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
Hi,
It appears that the last test in t9151-svn-mergeinfo.sh:
test_expect_failure 'everything got merged in the end' '
unmerged=$(git rev-list --all --not master)
[ -z $unmerged ]
'
reports known breakage or breakage vanished seemingly at
On Thu, Feb 6, 2014 at 1:25 AM, Junio C Hamano gits...@pobox.com wrote:
Yes, indeed. I wonder why your new test did not notice it, though
;-)
... and the answer turns out to be that it was not testing the right
thing. On top of that faulty version, this will fix it.
Yes, write-tree should
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:
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
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
On Tue, Feb 4, 2014 at 11:05 PM, Jonathan Nieder jrnie...@gmail.com wrote:
t/t7101-reset-empty-subdirs.sh (new +x) | 63
+
t/t7101-reset.sh (gone) | 63
-
t/t7104-reset-hard.sh (new +x) | 46
81 matches
Mail list logo
