* Re: [PATCH v2 0/5] Makefile: fix generation of assembler listings
From: Linus Torvalds @ 2010-01-06 9:07 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Junio C Hamano, git, Shawn O. Pearce
In-Reply-To: <20100106080216.GA7298@progeny.tock>
On Wed, 6 Jan 2010, Jonathan Nieder wrote:
>
> Patch 1 fixes a problem I noticed when tweaking the Makefile to
> automatically generate dependencies for the %.o targets. The problem
> is that the dependencies for the corresponding %.s (code listing)
> targets are not included in the Makefile at all, automatically or not.
Patches 1-3 (which were the ones I was cc'd on) look sane to me. Having
real dependencies might be prettier, but I agree that since a *.s file is
only generated on demand (and useful mainly to see code generation), just
forcing the build makes sense.
Linus
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2010, #01; Mon, 04)
From: Johannes Sixt @ 2010-01-06 9:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzl4r7jyu.fsf@alter.siamese.dyndns.org>
Junio C Hamano schrieb:
> Regarding your "[PATCH 8/6] t4030, t4031", I have two questions:
>
> Recall that MSYS bash converts POSIX style absolute paths to Windows style
> absolute paths. Unfortunately, it converts a program argument that begins
> with a double-quote and otherwise looks like an absolute POSIX path, but
> in doing so, it strips everything past the second double-quote[*]. This
> case is triggered in the two test scripts. The work-around is to place the
> Windows style path between the quotes to avoid the path conversion.
>
> (1) Does "Windows style path" here mean what $(pwd) returns as opposed to
> what is in $PWD?
Yes. $PWD is of the form /c/foo/bar; pwd is a function in test-lib.sh that
ensures it returns the form c:/foo/bar.
> (2) The patch reads like this:
>
> - git config diff.foo.textconv "\"$PWD\""/hexdump &&
> + git config diff.foo.textconv "\"$(pwd)\""/hexdump &&
>
> Does "strips everything past the second dq" mean "drops '/hexdump'"?
Yes.
> If so, would this also work (I am not suggesting to change it, just
> asking for information)?
>
> - git config diff.foo.textconv "\"$PWD\""/hexdump &&
> + git config diff.foo.textconv "\"$PWD/hexdump\"" &&
It would work, too, but it would depend on very bogus behavior of the MSYS
bash.
-- Hannes
^ permalink raw reply
* Re: [PATCH 9/9] rerere forget path: forget recorded resolution
From: Johannes Sixt @ 2010-01-06 8:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4on0oxcs.fsf@alter.siamese.dyndns.org>
Junio C Hamano schrieb:
> Johannes Sixt <j6t@kdbg.org> writes:
>> When you simply call ll_merge(), will it obey any merge drivers that
>> are defined in .gitattributes? Do we care about them?
>>
>> I already had an implementation of "rerere forget" before you
>> presented this solution, but it relies on that the user calls
>> "checkout --conflict=merge" first. One reason (besides its simplicity)
>> was that it does not have to care how the merge is computed.
>
> Doesn't "checkout --conflict=merge" use the same ll_merge() machinery?
It does, without setting up .gitattributes, either (IIUC), which is a bug IMO.
That said, I consider your solution superior because it works without
depending on conflict markers in the file in the worktree. Nevertheless,
we should think about whether merge drivers of .gitattributes should be
obeyed. I think they should: For example, a specialized XML merge driver
could leave conflicts that are different from those that merge-recursive
generates.
-- Hannes
^ permalink raw reply
* Re: checkout -m dumping core
From: Daniel @ 2010-01-06 8:11 UTC (permalink / raw)
To: Git List, Tomas Carnecky
In-Reply-To: <4B4381CA.1080504@dbservice.com>
Tomas Carnecky <tom@dbservice.com> wrote:
> git version 1.6.6.78.gbd757c
>
> HEAD points to a non-existent branch refs/heads/master. Normal checkout
> origin fails with:
> error: Entry '.cvsignore' would be overwritten by merge. Cannot merge.
> (the working tree does indeed contain this file). So I tried checkout -m
> and git crashed. Workaround for me was reset --hard origin; checkout
> origin. I have the repository backed up in case someone wants to try
> themselves.
>
> $ gdb `which git`
> GNU gdb 6.8
> Copyright (C) 2008 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law. Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "i386-pc-solaris2.11"...
> (gdb) run checkout -m origin
> Starting program: /export/home/tomc/local/git/bin/git checkout -m origin
> warning: Lowest section in /lib/libpthread.so.1 is .dynamic at 00000074
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x080788fa in cmd_checkout (argc=0, argv=0x8047538, prefix=0x0) at
> builtin-checkout.c:450
> 450 merge_trees(&o, new->commit->tree, work,
> (gdb) list
> 445 ret = reset_tree(new->commit->tree,
> opts, 1);
> 446 if (ret)
> 447 return ret;
> 448 o.branch1 = new->name;
> 449 o.branch2 = "local";
> 450 merge_trees(&o, new->commit->tree, work,
> 451 old->commit->tree, &result);
> 452 ret = reset_tree(new->commit->tree,
> opts, 0);
> 453 if (ret)
> 454 return ret;
> (gdb) p o
> $1 = {branch1 = 0x8047650 "origin", branch2 = 0x0, subtree_merge = 0,
> buffer_output = 1, verbosity = 0, diff_rename_limit = -1,
> merge_rename_limit = -1, call_depth = 0, obuf = {alloc = 0, len = 0, buf
> = 0x81643ac ""}, current_file_set = {
> items = 0x0, nr = 0, alloc = 0, strdup_strings = 1},
> current_directory_set = {items = 0x0, nr = 0, alloc = 0, strdup_strings
> = 1}}
> (gdb) p new
> $2 = {name = 0x8047650 "origin", path = 0x8166438 "refs/heads/origin",
> commit = 0x8168f48}
> (gdb) p work
> $3 = (struct tree *) 0x8174f90
> (gdb) p old
> No symbol "old" in current context.
> (gdb) p result
> $4 = (struct tree *) 0xfefc81be
> (gdb)
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Does this patch help?
---
From b2203bded22db1a496ee3c9f6f5f4a384a8ccefa Mon Sep 17 00:00:00 2001
From: Daniel Baranski <mjucde@o2.pl>
Date: Wed, 6 Jan 2010 08:58:21 +0100
Subject: [PATCH] checkout -m: Fix SEGFAULT if HEAD is not valid.
Signed-off-by: Daniel Barański <mjucde@o2.pl>
---
builtin-checkout.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/builtin-checkout.c b/builtin-checkout.c
index 64f3a11..0ab59b2 100644
--- a/builtin-checkout.c
+++ b/builtin-checkout.c
@@ -422,7 +422,8 @@ static int merge_working_tree(struct checkout_opts *opts,
struct merge_options o;
if (!opts->merge)
return 1;
- parse_commit(old->commit);
+ if (!parse_commit(old->commit))
+ die("Couldn't parse commit '%s'", old->path);
/* Do more real merge */
--
1.6.5.6
^ permalink raw reply related
* Re: checkout -m dumping core
From: Daniel @ 2010-01-06 8:20 UTC (permalink / raw)
To: git; +Cc: Tomas Carnecky
Argh, this one is better... (does not contain !). Stupid typo :/
---
From b2203bded22db1a496ee3c9f6f5f4a384a8ccefa Mon Sep 17 00:00:00 2001
From: Daniel Baranski <mjucde@o2.pl>
Date: Wed, 6 Jan 2010 08:58:21 +0100
Subject: [PATCH] checkout -m: Fix SEGFAULT if HEAD is not valid.
Signed-off-by: Daniel Barański <mjucde@o2.pl>
---
builtin-checkout.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/builtin-checkout.c b/builtin-checkout.c
index 64f3a11..0ab59b2 100644
--- a/builtin-checkout.c
+++ b/builtin-checkout.c
@@ -422,7 +422,8 @@ static int merge_working_tree(struct checkout_opts
*opts,
struct merge_options o;
if (!opts->merge)
return 1;
- parse_commit(old->commit);
+ if (parse_commit(old->commit))
+ die("Couldn't parse commit '%s'",
old->path);
/* Do more real merge */
--
1.6.5.6
^ permalink raw reply related
* [PATCH git-gui 5/5] git-gui/Makefile: consolidate .FORCE-* targets
From: Jonathan Nieder @ 2010-01-06 8:16 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Junio C Hamano
In-Reply-To: <20100106080216.GA7298@progeny.tock>
Providing multiple targets to force a rebuild is unnecessary
complication.
Avoid using a name that could conflict with future special
targets in GNU make (a leading period followed by uppercase
letters).
Cc: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
This is my first git-gui patch, so it is likely I have missed some
conventions. If that is the case, please let me know.
Thanks,
Jonathn
Makefile | 7 +++----
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/Makefile b/Makefile
index b3580e9..197b55e 100644
--- a/Makefile
+++ b/Makefile
@@ -7,7 +7,7 @@ all::
# TCL_PATH must be vaild for this to work.
#
-GIT-VERSION-FILE: .FORCE-GIT-VERSION-FILE
+GIT-VERSION-FILE: FORCE
@$(SHELL_PATH) ./GIT-VERSION-GEN
-include GIT-VERSION-FILE
@@ -270,7 +270,7 @@ TRACK_VARS = \
GITGUI_MACOSXAPP=$(GITGUI_MACOSXAPP) \
#end TRACK_VARS
-GIT-GUI-VARS: .FORCE-GIT-GUI-VARS
+GIT-GUI-VARS: FORCE
@VARS='$(TRACK_VARS)'; \
if test x"$$VARS" != x"`cat $@ 2>/dev/null`" ; then \
echo 1>&2 " * new locations or Tcl/Tk interpreter"; \
@@ -340,5 +340,4 @@ ifdef GITGUI_WINDOWS_WRAPPER
endif
.PHONY: all install uninstall dist-version clean
-.PHONY: .FORCE-GIT-VERSION-FILE
-.PHONY: .FORCE-GIT-GUI-VARS
+.PHONY: FORCE
--
1.6.6.rc2
^ permalink raw reply related
* [PATCH 4/5] Makefile: consolidate .FORCE-* targets
From: Jonathan Nieder @ 2010-01-06 8:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20100106080216.GA7298@progeny.tock>
Providing multiple targets to force a rebuild is unnecessary
complication.
Avoid using a name that could conflict with future special
targets in GNU make (a leading period followed by uppercase
letters).
The corresponding change to the git-gui Makefile is left for
another patch.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Documentation/Makefile | 4 ++--
Makefile | 15 ++++++---------
2 files changed, 8 insertions(+), 11 deletions(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 4797b2d..8a8a395 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -204,7 +204,7 @@ install-pdf: pdf
install-html: html
'$(SHELL_PATH_SQ)' ./install-webdoc.sh $(DESTDIR)$(htmldir)
-../GIT-VERSION-FILE: .FORCE-GIT-VERSION-FILE
+../GIT-VERSION-FILE: FORCE
$(QUIET_SUBDIR0)../ $(QUIET_SUBDIR1) GIT-VERSION-FILE
-include ../GIT-VERSION-FILE
@@ -337,4 +337,4 @@ quick-install-man:
quick-install-html:
'$(SHELL_PATH_SQ)' ./install-doc-quick.sh $(HTML_REF) $(DESTDIR)$(htmldir)
-.PHONY: .FORCE-GIT-VERSION-FILE
+.PHONY: FORCE
diff --git a/Makefile b/Makefile
index 3d774c6..fd79cd6 100644
--- a/Makefile
+++ b/Makefile
@@ -222,7 +222,7 @@ all::
# DEFAULT_EDITOR='$GIT_FALLBACK_EDITOR',
# DEFAULT_EDITOR='"C:\Program Files\Vim\gvim.exe" --nofork'
-GIT-VERSION-FILE: .FORCE-GIT-VERSION-FILE
+GIT-VERSION-FILE: FORCE
@$(SHELL_PATH) ./GIT-VERSION-GEN
-include GIT-VERSION-FILE
@@ -1632,7 +1632,7 @@ git.o git.spec \
%.o: %.c GIT-CFLAGS
$(QUIET_CC)$(CC) -o $*.o -c $(ALL_CFLAGS) $<
-%.s: %.c GIT-CFLAGS .FORCE-LISTING
+%.s: %.c GIT-CFLAGS FORCE
$(QUIET_CC)$(CC) -S $(ALL_CFLAGS) $<
%.o: %.S
$(QUIET_CC)$(CC) -o $*.o -c $(ALL_CFLAGS) $<
@@ -1723,7 +1723,7 @@ cscope:
TRACK_CFLAGS = $(subst ','\'',$(ALL_CFLAGS)):\
$(bindir_SQ):$(gitexecdir_SQ):$(template_dir_SQ):$(prefix_SQ)
-GIT-CFLAGS: .FORCE-GIT-CFLAGS
+GIT-CFLAGS: FORCE
@FLAGS='$(TRACK_CFLAGS)'; \
if test x"$$FLAGS" != x"`cat GIT-CFLAGS 2>/dev/null`" ; then \
echo 1>&2 " * new build flags or prefix"; \
@@ -1733,7 +1733,7 @@ GIT-CFLAGS: .FORCE-GIT-CFLAGS
# We need to apply sq twice, once to protect from the shell
# that runs GIT-BUILD-OPTIONS, and then again to protect it
# and the first level quoting from the shell that runs "echo".
-GIT-BUILD-OPTIONS: .FORCE-GIT-BUILD-OPTIONS
+GIT-BUILD-OPTIONS: FORCE
@echo SHELL_PATH=\''$(subst ','\'',$(SHELL_PATH_SQ))'\' >$@
@echo PERL_PATH=\''$(subst ','\'',$(PERL_PATH_SQ))'\' >>$@
@echo TAR=\''$(subst ','\'',$(subst ','\'',$(TAR)))'\' >>$@
@@ -1745,14 +1745,12 @@ GIT-BUILD-OPTIONS: .FORCE-GIT-BUILD-OPTIONS
ifndef NO_TCLTK
TRACK_VARS = $(subst ','\'',-DTCLTK_PATH='$(TCLTK_PATH_SQ)')
-GIT-GUI-VARS: .FORCE-GIT-GUI-VARS
+GIT-GUI-VARS: FORCE
@VARS='$(TRACK_VARS)'; \
if test x"$$VARS" != x"`cat $@ 2>/dev/null`" ; then \
echo 1>&2 " * new Tcl/Tk interpreter location"; \
echo "$$VARS" >$@; \
fi
-
-.PHONY: .FORCE-GIT-GUI-VARS
endif
### Testing rules
@@ -1972,8 +1970,7 @@ endif
.PHONY: all install clean strip
.PHONY: shell_compatibility_test please_set_SHELL_PATH_to_a_more_modern_shell
-.PHONY: .FORCE-GIT-VERSION-FILE TAGS tags cscope .FORCE-GIT-CFLAGS
-.PHONY: .FORCE-GIT-BUILD-OPTIONS .FORCE-LISTING
+.PHONY: FORCE TAGS tags cscope
### Check documentation
#
--
1.6.6.rc2
^ permalink raw reply related
* [PATCH 3/5] Makefile: learn to generate listings for targets requiring special flags
From: Jonathan Nieder @ 2010-01-06 8:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Linus Torvalds
In-Reply-To: <20100106080216.GA7298@progeny.tock>
'make git.s' to debug code generation of main() fails because
git.c makes use of preprocessor symbols such as GIT_VERSION that
are not set. make does not generate code listings for
builtin_help.c, exec_cmd.c, builtin-init-db.c, config.c, http.c,
or http-walker.c either, for the same reason.
So pass the flags used to generate each .o file when generating
the corresponding assembler listing.
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Makefile | 14 +++++++-------
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/Makefile b/Makefile
index 81190a6..3d774c6 100644
--- a/Makefile
+++ b/Makefile
@@ -1468,7 +1468,7 @@ strip: $(PROGRAMS) git$X
$(STRIP) $(STRIP_OPTS) $(PROGRAMS) git$X
git.o: common-cmds.h
-git.o: ALL_CFLAGS += -DGIT_VERSION='"$(GIT_VERSION)"' \
+git.s git.o: ALL_CFLAGS += -DGIT_VERSION='"$(GIT_VERSION)"' \
'-DGIT_HTML_PATH="$(htmldir_SQ)"'
git$X: git.o $(BUILTIN_OBJS) $(GITLIBS)
@@ -1476,7 +1476,7 @@ git$X: git.o $(BUILTIN_OBJS) $(GITLIBS)
$(BUILTIN_OBJS) $(ALL_LDFLAGS) $(LIBS)
builtin-help.o: common-cmds.h
-builtin-help.o: ALL_CFLAGS += \
+builtin-help.s builtin-help.o: ALL_CFLAGS += \
'-DGIT_HTML_PATH="$(htmldir_SQ)"' \
'-DGIT_MAN_PATH="$(mandir_SQ)"' \
'-DGIT_INFO_PATH="$(infodir_SQ)"'
@@ -1637,21 +1637,21 @@ git.o git.spec \
%.o: %.S
$(QUIET_CC)$(CC) -o $*.o -c $(ALL_CFLAGS) $<
-exec_cmd.o: ALL_CFLAGS += \
+exec_cmd.s exec_cmd.o: ALL_CFLAGS += \
'-DGIT_EXEC_PATH="$(gitexecdir_SQ)"' \
'-DBINDIR="$(bindir_relative_SQ)"' \
'-DPREFIX="$(prefix_SQ)"'
-builtin-init-db.o: ALL_CFLAGS += \
+builtin-init-db.s builtin-init-db.o: ALL_CFLAGS += \
-DDEFAULT_GIT_TEMPLATE_DIR='"$(template_dir_SQ)"'
-config.o: ALL_CFLAGS += -DETC_GITCONFIG='"$(ETC_GITCONFIG_SQ)"'
+config.s config.o: ALL_CFLAGS += -DETC_GITCONFIG='"$(ETC_GITCONFIG_SQ)"'
-http.o: ALL_CFLAGS += -DGIT_USER_AGENT='"git/$(GIT_VERSION)"'
+http.s http.o: ALL_CFLAGS += -DGIT_USER_AGENT='"git/$(GIT_VERSION)"'
ifdef NO_EXPAT
http-walker.o: http.h
-http-walker.o: ALL_CFLAGS += -DNO_EXPAT
+http-walker.s http-walker.o: ALL_CFLAGS += -DNO_EXPAT
endif
git-%$X: %.o $(GITLIBS)
--
1.6.6.rc2
^ permalink raw reply related
* [PATCH 2/5] Makefile: use target-specific variable to pass flags to cc
From: Jonathan Nieder @ 2010-01-06 8:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Linus Torvalds
In-Reply-To: <20100106080216.GA7298@progeny.tock>
This allows reusing the standard %.o: %.c pattern rule even for
targets that require special flags to be set. Thus after this
change, any changes in the command for compilation only have to
be performed in one place.
Target-specific variables have been supported in GNU make since
version 3.77, which has been available since 1998.
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Makefile | 41 ++++++++++++++++++-----------------------
1 files changed, 18 insertions(+), 23 deletions(-)
diff --git a/Makefile b/Makefile
index ba4d071..81190a6 100644
--- a/Makefile
+++ b/Makefile
@@ -1467,20 +1467,19 @@ shell_compatibility_test: please_set_SHELL_PATH_to_a_more_modern_shell
strip: $(PROGRAMS) git$X
$(STRIP) $(STRIP_OPTS) $(PROGRAMS) git$X
-git.o: git.c common-cmds.h GIT-CFLAGS
- $(QUIET_CC)$(CC) -DGIT_VERSION='"$(GIT_VERSION)"' \
- '-DGIT_HTML_PATH="$(htmldir_SQ)"' \
- $(ALL_CFLAGS) -o $@ -c $(filter %.c,$^)
+git.o: common-cmds.h
+git.o: ALL_CFLAGS += -DGIT_VERSION='"$(GIT_VERSION)"' \
+ '-DGIT_HTML_PATH="$(htmldir_SQ)"'
git$X: git.o $(BUILTIN_OBJS) $(GITLIBS)
$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ git.o \
$(BUILTIN_OBJS) $(ALL_LDFLAGS) $(LIBS)
-builtin-help.o: builtin-help.c common-cmds.h GIT-CFLAGS
- $(QUIET_CC)$(CC) -o $*.o -c $(ALL_CFLAGS) \
- '-DGIT_HTML_PATH="$(htmldir_SQ)"' \
- '-DGIT_MAN_PATH="$(mandir_SQ)"' \
- '-DGIT_INFO_PATH="$(infodir_SQ)"' $<
+builtin-help.o: common-cmds.h
+builtin-help.o: ALL_CFLAGS += \
+ '-DGIT_HTML_PATH="$(htmldir_SQ)"' \
+ '-DGIT_MAN_PATH="$(mandir_SQ)"' \
+ '-DGIT_INFO_PATH="$(infodir_SQ)"'
$(BUILT_INS): git$X
$(QUIET_BUILT_IN)$(RM) $@ && \
@@ -1638,25 +1637,21 @@ git.o git.spec \
%.o: %.S
$(QUIET_CC)$(CC) -o $*.o -c $(ALL_CFLAGS) $<
-exec_cmd.o: exec_cmd.c GIT-CFLAGS
- $(QUIET_CC)$(CC) -o $*.o -c $(ALL_CFLAGS) \
- '-DGIT_EXEC_PATH="$(gitexecdir_SQ)"' \
- '-DBINDIR="$(bindir_relative_SQ)"' \
- '-DPREFIX="$(prefix_SQ)"' \
- $<
+exec_cmd.o: ALL_CFLAGS += \
+ '-DGIT_EXEC_PATH="$(gitexecdir_SQ)"' \
+ '-DBINDIR="$(bindir_relative_SQ)"' \
+ '-DPREFIX="$(prefix_SQ)"'
-builtin-init-db.o: builtin-init-db.c GIT-CFLAGS
- $(QUIET_CC)$(CC) -o $*.o -c $(ALL_CFLAGS) -DDEFAULT_GIT_TEMPLATE_DIR='"$(template_dir_SQ)"' $<
+builtin-init-db.o: ALL_CFLAGS += \
+ -DDEFAULT_GIT_TEMPLATE_DIR='"$(template_dir_SQ)"'
-config.o: config.c GIT-CFLAGS
- $(QUIET_CC)$(CC) -o $*.o -c $(ALL_CFLAGS) -DETC_GITCONFIG='"$(ETC_GITCONFIG_SQ)"' $<
+config.o: ALL_CFLAGS += -DETC_GITCONFIG='"$(ETC_GITCONFIG_SQ)"'
-http.o: http.c GIT-CFLAGS
- $(QUIET_CC)$(CC) -o $*.o -c $(ALL_CFLAGS) -DGIT_USER_AGENT='"git/$(GIT_VERSION)"' $<
+http.o: ALL_CFLAGS += -DGIT_USER_AGENT='"git/$(GIT_VERSION)"'
ifdef NO_EXPAT
-http-walker.o: http-walker.c http.h GIT-CFLAGS
- $(QUIET_CC)$(CC) -o $*.o -c $(ALL_CFLAGS) -DNO_EXPAT $<
+http-walker.o: http.h
+http-walker.o: ALL_CFLAGS += -DNO_EXPAT
endif
git-%$X: %.o $(GITLIBS)
--
1.6.6.rc2
^ permalink raw reply related
* [PATCH 1/5] Makefile: regenerate assembler listings when asked
From: Jonathan Nieder @ 2010-01-06 8:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Linus Torvalds
In-Reply-To: <20100106080216.GA7298@progeny.tock>
'make var.s' fails to regenerate an assembler listing if var.c
has not changed but a header it includes has:
$ make var.s
CC var.s
$ touch cache.h
$ make var.s
$
The corresponding problem for 'make var.o' does not occur because
the Makefile lists dependencies for each .o target explicitly;
analogous dependency rules for the .s targets are not present.
Rather than add some, it seems better to force 'make' to always
regenerate assembler listings, since the assembler listing
targets are only invoked when specifically requested on the make
command line.
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Makefile | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index c11719c..ba4d071 100644
--- a/Makefile
+++ b/Makefile
@@ -1633,7 +1633,7 @@ git.o git.spec \
%.o: %.c GIT-CFLAGS
$(QUIET_CC)$(CC) -o $*.o -c $(ALL_CFLAGS) $<
-%.s: %.c GIT-CFLAGS
+%.s: %.c GIT-CFLAGS .FORCE-LISTING
$(QUIET_CC)$(CC) -S $(ALL_CFLAGS) $<
%.o: %.S
$(QUIET_CC)$(CC) -o $*.o -c $(ALL_CFLAGS) $<
@@ -1978,7 +1978,7 @@ endif
.PHONY: all install clean strip
.PHONY: shell_compatibility_test please_set_SHELL_PATH_to_a_more_modern_shell
.PHONY: .FORCE-GIT-VERSION-FILE TAGS tags cscope .FORCE-GIT-CFLAGS
-.PHONY: .FORCE-GIT-BUILD-OPTIONS
+.PHONY: .FORCE-GIT-BUILD-OPTIONS .FORCE-LISTING
### Check documentation
#
--
1.6.6.rc2
^ permalink raw reply related
* [PATCH v2 0/5] Makefile: fix generation of assembler listings
From: Jonathan Nieder @ 2010-01-06 8:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Linus Torvalds, Shawn O. Pearce
In-Reply-To: <20091128113709.GD10059@progeny.tock>
Jonathan Nieder wrote:
> This adds yet another phony .FORCE-foo target. Wouldn’t it be simpler
> to use a single target called .FORCE, or is there something I am
> missing that that would break?
I didn’t hear any screams when I suggested this about a month ago, so
let’s try it out.
Patch 1 fixes a problem I noticed when tweaking the Makefile to
automatically generate dependencies for the %.o targets. The problem
is that the dependencies for the corresponding %.s (code listing)
targets are not included in the Makefile at all, automatically or not.
Thus the command "make var.s var.o && touch cache.h && make var.s var.o"
produces the output
CC var.s
CC var.o
CC var.o
not regenerating var.s to reflect potential changes in cache.h.
"make git.s" previously did not work at all; patches 2-3 fix that.
Jonathan Nieder (5):
Makefile: regenerate assembler listings when asked
Makefile: use target-specific variable to pass flags to cc
Makefile: learn to generate listings for targets requiring special
flags
Makefile: consolidate .FORCE-* targets
git-gui/Makefile: consolidate .FORCE-* targets
Documentation/Makefile | 4 +-
Makefile | 56 ++++++++++++++++++++---------------------------
git-gui/Makefile | 7 ++---
3 files changed, 29 insertions(+), 38 deletions(-)
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2010, #01; Mon, 04)
From: Junio C Hamano @ 2010-01-06 7:47 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <4B43A5CA.7090104@kdbg.org>
Johannes Sixt <j6t@kdbg.org> writes:
> Junio C Hamano schrieb:
>> While you are technically correct that the change you made in t4030 is not
>> justified by the commit log message in the sense that the "hexdump" script
>> will go through run_command() interface and is not subject to the special
>> rules filter writers need to keep in mind, the patch text itself is a good
>> change, isn't it?
>
> The patch text is good, but since it will not make a difference (and
> there are a ton of other places that use /bin/sh successfully), the
> change is not warrented at this time, IMO.
You are right (and Peff also corrected me).
>> As "run-command: convert simple callsites to use_shell" is the one that
>> changes the filter_buffer(), do you want to have t0021 patch before that
>> one, to prepare the test for the coming change?
>
> Well, the test will break on Windows only after "run-command: optimize
> out useless shell calls", and I wrote the commit message
> accordingly. If you move it before that one (and if you are picky) the
> commit message should be changed as well.
Yeah, I've reworded that one with a phrase "futureproof".
Regarding your "[PATCH 8/6] t4030, t4031", I have two questions:
Recall that MSYS bash converts POSIX style absolute paths to Windows style
absolute paths. Unfortunately, it converts a program argument that begins
with a double-quote and otherwise looks like an absolute POSIX path, but
in doing so, it strips everything past the second double-quote[*]. This
case is triggered in the two test scripts. The work-around is to place the
Windows style path between the quotes to avoid the path conversion.
(1) Does "Windows style path" here mean what $(pwd) returns as opposed to
what is in $PWD?
(2) The patch reads like this:
- git config diff.foo.textconv "\"$PWD\""/hexdump &&
+ git config diff.foo.textconv "\"$(pwd)\""/hexdump &&
Does "strips everything past the second dq" mean "drops '/hexdump'"?
If so, would this also work (I am not suggesting to change it, just
asking for information)?
- git config diff.foo.textconv "\"$PWD\""/hexdump &&
+ git config diff.foo.textconv "\"$PWD/hexdump\"" &&
Thanks.
^ permalink raw reply
* Re: [PATCH] Documentation: reset: add some missing tables
From: Christian Couder @ 2010-01-06 7:31 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Linus Torvalds, Johannes Schindelin, Stephan Beyer,
Daniel Barkalow, Jakub Narebski, Paolo Bonzini, Johannes Sixt,
Stephen Boyd
In-Reply-To: <7vwrzx3v4z.fsf@alter.siamese.dyndns.org>
On mardi 05 janvier 2010, Junio C Hamano wrote:
> Christian Couder <chriscool@tuxfamily.org> writes:
> > and while at it also explain why --merge option is disallowed in some
> > cases.
> >
> > Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
> > ---
> > Documentation/git-reset.txt | 35 +++++++++++++++++++++++++++++------
> > 1 files changed, 29 insertions(+), 6 deletions(-)
> >
> > I must say that I find it a bit strange (and difficult to explain) that
> > we have:
> >
> > working index HEAD target working index HEAD
> > ----------------------------------------------------
> > B C C C --merge B C C
> >
> > while in the other cases, when it is allowed, --merge is like --hard.
>
> That is probably because you don't explain what --merge option is _for_
> well enough to your readers. If the reader understands it is to reset
> away a half-merged conflicted result, starting from a potentially dirty
> work tree, then it would be very obvious that the above is the right
> thing to do.
>
> As a prerequisite, the reader should be aware (otherwise they should read
> some introductory git books, or
> http://gitster.livejournal.com/29060.html) that a mergy operation can
> stop without completing a merge in two ways:
>
> - If a path that is involved in a mergy operation has local changes in
> the work tree, or if the index is dirty, the operation stops _without_
> doing anything.
>
> - If all paths that are involved in a mergy operation are clean in the
> work tree, the operation is attempted. If a conflict happens at the
> content level, the operation leaves the paths in conflicted state in
> the index and leaves the conflict markers in the files in the work
> tree. Be _very_ aware that even in this case, cleanly automerged
> paths are updated in the index and the work tree.
>
> In the first case, you do not have to run "reset --merge", as nothing was
> done by the mergy operation (it happens to be safe to "reset --merge", as
> the only thing you lose is a partial add, which you can easily redo from
> the files in the working tree).
>
> In the latter case, there are four classes of paths:
>
> (1) Ones that are not involved in the merge at all, and were clean from
> the beginning. The work tree file, the index and the HEAD would
> match.
>
> w=C i=C H=C
>
> (2) Ones that are not involved in the merge at all, but were dirty when
> you started the mergy operation. They have your local changes in
> the work tree that you wanted to keep across the mergy operation.
>
> w=B i=C H=C
>
> (3) Ones that are involved in the merge, and were cleanly merged. By
> definition, these paths did _not_ have local changes in the work
> tree (otherwise the mergy operation would have stopped without doing
> anything). These are updated in the index and the files in the work tree
> matches the index after the mergy operation stops.
>
> w=B i=B H=C
>
> (4) Ones that are involved in the merge, and were conflicted. Again, by
> definition, these paths did _not_ have local changes in the work
> tree These are left in the index as conflicted, and the files in the work
> tree have conflict markers after the mergy operation stops.
>
> w=X i=U H=C
>
> "reset --merge HEAD" is about going back to the state before you started
> this mergy operation. You don't need to do anything to paths in (1), and
> you want to reset paths in (3) and (4) back to the HEAD.
>
> Think what you want to do to (2). By definition, they weren't involved
> in the mergy operation (otherwise you couldn't have come this far), so
> the difference between the index and the work tree is purely your local
> changes, untouched by the mergy operation, and have not even been updated
> in "cvs update" style. The right thing to do is simply leave them as
> they are.
>
> Side note. Explained in the opposite way, if the work tree file is
> different from the index and the index is not unmerged, the
> difference _only_ could have come from the local change before you
> started your mergy operation. Any other change to the work tree files
> done by any mergy operation will be matched to the index. So w=B i=C in
> (2) will immediately tell you that the change is a local one that is
> unrelated to the merge.
>
> By the way, people often say that the index is good because it allows you
> to make partial commits (i.e. "add -p"), but at the same time have this
> mistaken notion that it is the _primary_ benefit of the index. Actually,
> a lot more important benefit of the index is (3) above. When you are
> dealing with a large merge with many paths, often a lot of them automerge
> cleanly while some gives you conflicts. The automerged results are added
> to the index and you do not have to see them in "git diff" (as their
> files and the index match), to allow you concentrate on the conflicted
> ones very easily.
Thanks for your explanations.
Christian.
^ permalink raw reply
* [PATCH v2] Makefile: make ppc/sha1ppc.o depend on GIT-CFLAGS
From: Jonathan Nieder @ 2010-01-06 6:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Nanako Shiraishi
In-Reply-To: <20091128113323.GC10059@progeny.tock>
The %.o: %.S pattern rule should depend on GIT-CFLAGS to avoid
trouble when ALL_CFLAGS changes.
The pattern only applies to one file (ppc/sha1ppc.S) and that
file does not use any #ifdefs, so leaving the dependency out is
probably harmless. Nevertheless, it is safer to include the
dependency in case future code's behavior does depend on the
build flags.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Hopefully the justification is a little clearer this time.
This is not a high-priority change. The problem it addresses is only
an aesthetic one as far as I can tell. Still, I would be happy to see
it fixed; thanks for the reminder.
Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index c11719c..015bfab 100644
--- a/Makefile
+++ b/Makefile
@@ -1635,7 +1635,7 @@ git.o git.spec \
$(QUIET_CC)$(CC) -o $*.o -c $(ALL_CFLAGS) $<
%.s: %.c GIT-CFLAGS
$(QUIET_CC)$(CC) -S $(ALL_CFLAGS) $<
-%.o: %.S
+%.o: %.S GIT-CFLAGS
$(QUIET_CC)$(CC) -o $*.o -c $(ALL_CFLAGS) $<
exec_cmd.o: exec_cmd.c GIT-CFLAGS
--
1.6.6.rc2
^ permalink raw reply related
* Re: cmake, was Re: submodules' shortcomings
From: Miles Bader @ 2010-01-06 4:25 UTC (permalink / raw)
To: Pau Garcia i Quiles; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <3af572ac1001051717u7757f0dep9392fbb7b02cbbca@mail.gmail.com>
Pau Garcia i Quiles <pgquiles@elpauer.org> writes:
> At this moment, what stops me from beginning this project is a simple
> question: is it worth my time? From the discussion a few months ago,
> it looked like it would the a second-class citizen and never replace
> the existing buildsystems, so I really wonder if I should spend me
> time porting git to CMake, or I should focus on other projects which
> would gladly receive my contributions. If you honestly think it's
> worth it, just tell me and I'll start the port to CMake immediately.
It sounds like it's you who want it, so aren't you the best person to
make that judgement...? It seems very unlikely for cmake to replace
anything.
-Miles
--
Politeness, n. The most acceptable hypocrisy.
^ permalink raw reply
* Re: [PATCH 0/4] Makefile fixes
From: Jonathan Nieder @ 2010-01-06 4:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, git
In-Reply-To: <7vpr5onir5.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Nanako Shiraishi <nanako3@lavabit.com> writes:
>
>> Junio, could you tell us what happened to this thread?
>>
>> Makefile improvements. No discussion.
These had some issues and instead of following up, I simply forgot
about them.
> I took 4/4, and after looking at them again, I think 2/4 looks sensible,
> too.
I also think the patch for 2/4 looks sensible, but the commit message
does not make much sense. Optimization flags do not affect
compilation of assembler code as far as I can tell. It would have
made more sense to say something like "Since the only .S file in git
does not have any #ifdefs, leaving the dependency out was mostly
harmless." (Will resend.)
> I was puzzled by 3/4 and I still am; the dependency rules are the same for
> %.o and %.s yet the patch changes only %.s. Either it leaves the same
> breakage for %.o (which is much more important in practice), or the
> problem Jonathan has with %.s may have other causes, but it was unclear to
> me.
The Makefile lists dependencies for each .o target elsewhere. While
cleaning up those other dependency rules, I noticed there was nothing
analogous for the .s targets. You can reproduce this by running
"make var.o var.s && touch cache.h && make var.o var.s".
Of course, I should have mentioned this in the commit message. Will
resend as well. Sorry to leave these standing for so long.
Sincerely,
Jonathan
^ permalink raw reply
* Re: A question about changing remote repo name
From: Dongas @ 2010-01-06 3:55 UTC (permalink / raw)
To: David Aguilar; +Cc: Russell Steicke, git
In-Reply-To: <20100105211521.GC2657@gmail.com>
2010/1/6 David Aguilar <davvid@gmail.com>:
>
> Hi,
>
> On Tue, Jan 05, 2010 at 12:30:03PM +0800, Dongas wrote:
>> 2010/1/5 Russell Steicke <russellsteicke@gmail.com>:
>> > On Mon, Jan 4, 2010 at 2:45 PM, Dongas <dongas86@gmail.com> wrote:
>>
>> Thanks a lot, Russell.
>> I followed you instruction but it seemed it needs more changes.
>>
>> Execute your steps....
>> Becomes:
>> root@ubuntu:/work/git-repo/free_monkey# tree -a
>
> Just a note: I would recommend against being root.
> You cloned the repo so you should own it.
Thanks for your advices.
> More below...
>
>
>> root@ubuntu:/work/git-repo/free_monkey# cat .git/config
>> [core]
>> repositoryformatversion = 0
>> filemode = true
>> bare = false
>> logallrefupdates = true
>> [remote "karmic"]
>> url = git@192.168.1.116:free_monkey.git
>> fetch = +refs/heads/*:refs/remotes/karmic/*
>> [branch "master"]
>> remote = karmic
>> merge = refs/heads/master
>>
>> But the result was:
>> root@ubuntu:/work/git-repo/free_monkey# git branch -a
>> * master
>> karmic/HEAD
>> origin/master
>> The 'origin/master' was still not changed.
>
>
> A safter alternative would be to leave the "origin" lines in
> place as a duplicate of karmic:
>
> [remote "karmic"]
> url = git@192.168.1.116:free_monkey.git
> fetch = +refs/heads/*:refs/karmic/origin/*
>
> [remote "origin"]
> url = git@192.168.1.116:free_monkey.git
> fetch = +refs/heads/*:refs/remotes/origin/*
>
>
> At that point you will have two remotes, "karmic" and "origin".
> "git fetch karmic" to get the latest branches.
>
> Finally, "git remote rm origin" to remove all references to it.
It's a good idea.
I have tried and it seemed to work.
(I also did a few more works to make it better)
Below is the result:
root@ubuntu:/work/git-repo/tmp/free_monkey# git branch -a
* master
origin/HEAD
origin/master
root@ubuntu:/work/git-repo/tmp/free_monkey# cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
url = git@192.168.1.106:free_monkey.git
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
root@ubuntu:/work/git-repo/tmp/free_monkey# git remote add karmic
git@192.168.1.106:free_monkey.git
root@ubuntu:/work/git-repo/tmp/free_monkey# git fetch karmic
From git@192.168.1.106:free_monkey
* [new branch] master -> karmic/master
root@ubuntu:/work/git-repo/tmp/free_monkey# git branch -a
* master
karmic/master
origin/HEAD
origin/master
root@ubuntu:/work/git-repo/tmp/free_monkey# git remote rm origin
root@ubuntu:/work/git-repo/tmp/free_monkey# git branch -a
* master
karmic/master
However there's a little issue:
root@ubuntu:/work/git-repo/tmp/free_monkey# git pull
fatal: 'origin': unable to chdir or not a git archive
fatal: The remote end hung up unexpectedly
root@ubuntu:/work/git-repo/tmp/free_monkey# grep -wrin 'origin' .git/
root@ubuntu:/work/git-repo/tmp/free_monkey# cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[branch "master"]
[remote "karmic"]
url = git@192.168.1.106:free_monkey.git
fetch = +refs/heads/*:refs/remotes/karmic/*
But 'git pull karmic master' worked well.
root@ubuntu:/work/git-repo/tmp/free_monkey# git pull karmic master
From git@192.168.1.106:free_monkey
* branch master -> FETCH_HEAD
Already up-to-date.
For conveniently, i did a few more steps.
Add two lines below '[branch "master"]':
root@ubuntu:/work/git-repo/tmp/free_monkey# cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[branch "master"]
remote = karmic
merge = refs/heads/master
[remote "karmic"]
url = git@192.168.1.106:free_monkey.git
fetch = +refs/heads/*:refs/remotes/karmic/*
Then, 'git pull' worked well.
root@ubuntu:/work/git-repo/tmp/free_monkey# git pull
Already up-to-date.
> That was a while ago (probably over a year ago) and this wasn't
> anybody's itch to scratch in the meantime so nothing every
> materialized. It think this is only the 2nd time this has come
> up in that whole time. Sorry, I wasn't able to find the thread.
Thanks for the info.
> Here's a nice middle ground --
>
> instead of naming your branch "master" you can call your default
> branch "karmic".
>
> To make it the default for "git clone" then you'll need to push
> your local master branch and call it "karmic" over there:
>
> git push origin master:karmic
>
> Then, go to that server and change the repo's HEAD entry so that
> it points to karmic instead of master.
>
> ssh admin@gitbox
> cd /path/to/repo.git
> vi HEAD
>
> From then on, everyone who clones the repo will have a "karmic"
> branch by default instead of the master branch.
>
> To get that branch on repos that were cloned before the change:
>
> git fetch origin
> git checkout -b karmic origin/karmic
>
>
>
> With this setup you might even want to remove the "master"
> branch altogether since it might be confusing to have both:
>
> Once:
> git push origin :master
>
> In everyone's repo:
> git remote prune origin
>
>
> You will need to make sure everyone has either:
> a) cloned from the new master-less repo
> b) run the "checkout -b" and "remote prune" commands
>
> Otherwise someone'll likely "git push" the master branch back
> into existence.
Thanks a lot for the alternative way , it looks good.
Regards
Dongas
^ permalink raw reply
* Re: A question about changing remote repo name
From: Dongas @ 2010-01-06 3:58 UTC (permalink / raw)
To: Russell Steicke; +Cc: git
In-Reply-To: <c1b8b6671001051607j6b6398d8gf08f7615a38de64e@mail.gmail.com>
2010/1/6 Russell Steicke <russellsteicke@gmail.com>:
> On Tue, Jan 5, 2010 at 12:30 PM, Dongas <dongas86@gmail.com> wrote:
>> I did a few more steps:
>> root@ubuntu:/work/git-repo/free_monkey# grep -wrin 'origin' .
>> ./.git/packed-refs:2:abfae429bb4081043e84681e5ee94102085f87e0
>> refs/remotes/origin/master
>> ./.git/refs/remotes/karmic/HEAD:1:ref: refs/remotes/origin/master
>>
>> Change 'origin' to 'karmic' in above files.
>
> Ah yes, I forgot about those files. I _think_ (but I'm not certain
> without digging into the code) that it's always safe to rm
> packed-refs, as that file is a cache for quicker access to the refs.
> At least it's never caused me any problems.
>
> In any case, your approach of grepping the whole of .git for
> interesting strings is a good way to learn about the implementation.
Thanks a lot for your help. :)
Regards
Dongas
^ permalink raw reply
* Re: [PATCH v3 2/6] t5541-http-push.sh: add test for unmatched, non-fast-forwarded refs
From: Tay Ray Chuan @ 2010-01-06 2:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Shawn O. Pearce, Daniel Barkalow, Jeff King
In-Reply-To: <7viqbgoxgg.fsf@alter.siamese.dyndns.org>
Hi,
On Wed, Jan 6, 2010 at 9:04 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Tay Ray Chuan <rctay89@gmail.com> writes:
>
>> Test that when non-fast-forwarded refs cannot be matched without an
>> explicit refspect, the push fails with a non-fast-forward ref status and
>> help message.
>>
>> Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
>> ---
>> t/t5541-http-push.sh | 20 ++++++++++++++++++++
>> 1 files changed, 20 insertions(+), 0 deletions(-)
>>
>> diff --git a/t/t5541-http-push.sh b/t/t5541-http-push.sh
>> index f49c7c4..5ebe04a 100755
>> --- a/t/t5541-http-push.sh
>> +++ b/t/t5541-http-push.sh
>> @@ -111,5 +111,25 @@ Merge the remote changes before pushing again. See the '"'non-fast-forward'"'
>> section of '"'git push --help'"' for details." output
>> '
>>
>> +test_expect_failure 'push fails for non-fast-forward refs unmatched by remote helper' '
>> + # create a dissimilarly-named ref so that git is unable to match the refs
>> + git push origin master:retsam
>> +
>> + echo "change changed" > path2 &&
>> + git commit -a -m path2 --amend &&
>> +
>> + # push master too. This ensures there is at least one '"'push'"' command to
>> + # the remote helper and triggers interaction with the helper.
>> + !(git push -v origin +master master:retsam >output 2>&1) &&
>
> A dumb question. Why is this done in a sub-shell?
>
>> +
>> + grep "^ + [a-z0-9]\+\.\.\.[a-z0-9]\+[ ]*master -> master (forced update)$" output &&
>> + grep "^ ! \[rejected\][ ]*master -> retsam (non-fast-forward)$" output &&
>
> [a-z0-9] seems too broad to catch hexadecimal.
Oops, my bad.
> "\+" to introduce ERE
> elements to grep that expects BRE is a GNU extension, IIRC. You could use
> egrep if you really want to say one-or-more, but I think in this case it
> is better to simply replace it with a zero-or-more '*'.
Ok.
> Why is a single
> SP made into character class with "[ ]" pair?
To make it clearer that I'm trying to match a SP.
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: [PATCH] git-update-index: report(...) now flushes stdout after printing the report line
From: Tay Ray Chuan @ 2010-01-06 1:51 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Miklos Vajna, Sebastian Thiel,
Nanako Shiraishi, git
In-Reply-To: <7vwrzwoxh4.fsf@alter.siamese.dyndns.org>
Hi,
On Wed, Jan 6, 2010 at 9:04 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Tay Ray Chuan <rctay89@gmail.com> writes:
>
>> from your above message solely and setting aside your original patch,
>> I presume that you want to introduce the ability to force progress
>> reporting even if stderr isn't a terminal.
>>
>> I am working a feature (display progress for http operations) that
>> happens to add this ability to git-push and git-fetch, by specifying
>> the --progress option.
>>
>> Regarding git-pull - I guess it's only git-fetch (being
>> transport-related) that reports progress?
>
> Are you talking about this topic?
>
> * tc/clone-v-progress (2009-12-26) 4 commits
> - clone: use --progress to force progress reporting
> - clone: set transport->verbose when -v/--verbose is used
> - git-clone.txt: reword description of progress behaviour
> - check stderr with isatty() instead of stdout when deciding to show progress
no, I'm not referring to that - the topic I mentioned is still off-list.
> What do people think about it? I vaguely recall that somebody asked to
> add a warning to release notes on the behaviour change to this series, and
> I think it may be a worthwhile thing to do (e.g. "Earlier we did X but now
> we do Y; change things in this way if you want us to keep doing X"), but
> otherwise I think it is a sensible change.
Yes, that request was from Dscho, and Miklos said something to that
effect as well. Could you advise how one could go about adding such a
warning, as I'm not sure about the release schedule details.
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: Filename quoting / parsing problem
From: Junio C Hamano @ 2010-01-06 1:32 UTC (permalink / raw)
To: Andreas Gruenbacher; +Cc: git
In-Reply-To: <201001060104.25737.agruen@suse.de>
Andreas Gruenbacher <agruen@suse.de> writes:
> * sha1 checksums are not verified right now. I'm not sure when that
> should happen: always by default, or only optionally?
preimage and postimage sums are not something you would "verify" with
anyway, and they are not useful unless you are dealing with binary patch,
so I wouldn't worry too much about them.
> * Similarity and dissimilarity headers are ignored.
I think it is fine to ignore them; even git doesn't use this information
other than parroting them in "apply --summary --stat" output.
> * Binary diffs are no supported. I think GNU patch should recognize
> them and give a reasonable message for now.
Nice.
^ permalink raw reply
* Re: cmake, was Re: submodules' shortcomings
From: Pau Garcia i Quiles @ 2010-01-06 1:17 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <alpine.DEB.1.00.1001060005010.4985@pacific.mpi-cbg.de>
On Wed, Jan 6, 2010 at 12:06 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Tue, 5 Jan 2010, Pau Garcia i Quiles wrote:
>
>> For instance, I'd like to have a 'cmake' repository where I store all
>> the FindBlah.cmake modules, so that I can share them from every
>> repository, and not worry about users changing and committing in the
>> main project instead of the submodule.
>
> ... which reminds me... it was you who wanted to provide a working recipe
> to compile and install CMake on msysGit, right?
Right
> What happened in the meantime?
What happened is I was very busy until November. Now I've got some free time.
At this moment, what stops me from beginning this project is a simple
question: is it worth my time? From the discussion a few months ago,
it looked like it would the a second-class citizen and never replace
the existing buildsystems, so I really wonder if I should spend me
time porting git to CMake, or I should focus on other projects which
would gladly receive my contributions. If you honestly think it's
worth it, just tell me and I'll start the port to CMake immediately.
--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
^ permalink raw reply
* Re: Filename quoting / parsing problem
From: Junio C Hamano @ 2010-01-06 1:08 UTC (permalink / raw)
To: Andreas Gruenbacher; +Cc: git
In-Reply-To: <201001022148.47841.agruen@suse.de>
Andreas Gruenbacher <agruen@suse.de> writes:
> Right now, git generates lines like "diff --git a/f a/f b/f b/f" in some
> corner cases, and from such lines alone, it is not possible to tell what the
> two file names are (either "a/f a/f" and "b/f b/f", or "a/f a/f b/f" and
> "b/f"). I can only find that out by looking at the other header lines.
I would understand "a/f a/f b/f a/f", which would be a diff of "f a/f"
between two versions.
"a/f a/f b/f b/f" could be rename from "f /a/f" to "f b/f" (or "f a/f b/f"
to "f"). But you will always get "rename from" and "rename to" in that
case.
So you can (and I think git-apply does) follow this simple rule:
If you see +++/---/rename from/rename to/new file/deleted file, use
the names you find there. Otherwise, because there is no rename,
"diff --git" lines has two identical names that follow a/ and b/, so
use that name.
The parsing code in builtin-apply.c is not so dense; you should be able to
lift it from there, I think.
Although an output of "a/f a/f b/f b/f" without "rename from/to" is
possible with --no-index of two unrelated files, --no-index output is not
even something that is meant to be appliable, so I wouldn't worry too much
about it.
^ permalink raw reply
* Re: [PATCH 0/4] Makefile fixes
From: Junio C Hamano @ 2010-01-06 1:07 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Jonathan Nieder, git
In-Reply-To: <20100101090556.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Junio, could you tell us what happened to this thread?
>
> Makefile improvements. No discussion.
I took 4/4, and after looking at them again, I think 2/4 looks sensible,
too.
I was puzzled by 3/4 and I still am; the dependency rules are the same for
%.o and %.s yet the patch changes only %.s. Either it leaves the same
breakage for %.o (which is much more important in practice), or the
problem Jonathan has with %.s may have other causes, but it was unclear to
me.
^ permalink raw reply
* Re: [PATCH/RFC 0/2] Lazily generate header dependencies
From: Junio C Hamano @ 2010-01-06 1:06 UTC (permalink / raw)
To: Nanako Shiraishi
Cc: Jonathan Nieder, Johannes Sixt, Git Mailing List,
Johannes Schindelin
In-Reply-To: <20100101090550.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Junio, could you tell us what happened to this thread?
>
> Makefile improvements. No discussion.
I was mildly interested in the series, but after this:
http://thread.gmane.org/gmane.comp.version-control.git/133872/focus=133911
the progress seems to have stopped.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox