* [PATCH 1/2] Rename REFRESH_SAY_CHANGED to REFRESH_IN_PORCELAIN.
From: Matthieu Moy @ 2009-08-07 20:24 UTC (permalink / raw)
To: git, gitster; +Cc: Matthieu Moy
In-Reply-To: <7vvdl0kau4.fsf@alter.siamese.dyndns.org>
The change in the output is going to become more general than just saying
"changed", so let's make the variable name more general too.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
builtin-add.c | 2 +-
builtin-reset.c | 4 ++--
cache.h | 2 +-
read-cache.c | 2 +-
4 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/builtin-add.c b/builtin-add.c
index 581a2a1..a325bc9 100644
--- a/builtin-add.c
+++ b/builtin-add.c
@@ -105,7 +105,7 @@ static void refresh(int verbose, const char **pathspec)
for (specs = 0; pathspec[specs]; specs++)
/* nothing */;
seen = xcalloc(specs, 1);
- refresh_index(&the_index, verbose ? REFRESH_SAY_CHANGED : REFRESH_QUIET,
+ refresh_index(&the_index, verbose ? REFRESH_IN_PORCELAIN : REFRESH_QUIET,
pathspec, seen);
for (i = 0; i < specs; i++) {
if (!seen[i])
diff --git a/builtin-reset.c b/builtin-reset.c
index 5fa1789..ddf68d5 100644
--- a/builtin-reset.c
+++ b/builtin-reset.c
@@ -261,7 +261,7 @@ int cmd_reset(int argc, const char **argv, const char *prefix)
die("Cannot do %s reset with paths.",
reset_type_names[reset_type]);
return read_from_tree(prefix, argv + i, sha1,
- quiet ? REFRESH_QUIET : REFRESH_SAY_CHANGED);
+ quiet ? REFRESH_QUIET : REFRESH_IN_PORCELAIN);
}
if (reset_type == NONE)
reset_type = MIXED; /* by default */
@@ -302,7 +302,7 @@ int cmd_reset(int argc, const char **argv, const char *prefix)
break;
case MIXED: /* Report what has not been updated. */
update_index_refresh(0, NULL,
- quiet ? REFRESH_QUIET : REFRESH_SAY_CHANGED);
+ quiet ? REFRESH_QUIET : REFRESH_IN_PORCELAIN);
break;
}
diff --git a/cache.h b/cache.h
index e6c7f33..a2f2923 100644
--- a/cache.h
+++ b/cache.h
@@ -473,7 +473,7 @@ extern void fill_stat_cache_info(struct cache_entry *ce, struct stat *st);
#define REFRESH_QUIET 0x0004 /* be quiet about it */
#define REFRESH_IGNORE_MISSING 0x0008 /* ignore non-existent */
#define REFRESH_IGNORE_SUBMODULES 0x0010 /* ignore submodules */
-#define REFRESH_SAY_CHANGED 0x0020 /* say "changed" not "needs update" */
+#define REFRESH_IN_PORCELAIN 0x0020 /* user friendly output, not "needs update" */
extern int refresh_index(struct index_state *, unsigned int flags, const char **pathspec, char *seen);
struct lock_file {
diff --git a/read-cache.c b/read-cache.c
index 4e3e272..f1aff81 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1077,7 +1077,7 @@ int refresh_index(struct index_state *istate, unsigned int flags, const char **p
unsigned int options = really ? CE_MATCH_IGNORE_VALID : 0;
const char *needs_update_message;
- needs_update_message = ((flags & REFRESH_SAY_CHANGED)
+ needs_update_message = ((flags & REFRESH_IN_PORCELAIN)
? "locally modified" : "needs update");
for (i = 0; i < istate->cache_nr; i++) {
struct cache_entry *ce, *new;
--
1.6.4.62.g39c83.dirty
^ permalink raw reply related
* [PATCH 2/2 (v2)] reset: make the output more user-friendly.
From: Matthieu Moy @ 2009-08-07 20:24 UTC (permalink / raw)
To: git, gitster; +Cc: Matthieu Moy
In-Reply-To: <1249676676-5051-1-git-send-email-Matthieu.Moy@imag.fr>
git reset without argument displays a summary of the remaining
unstaged changes. The problem with these is that they look like an
error message, and the format is inconsistant with the format used in
other places like "git diff --name-status".
This patch mimics the output of "git diff --name-status", and adds a
header to make it clear the output is informative, and not an error.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
As noted by Junio, my previous version did actually display the header
unconditionnaly. This version displays it as the first change is found.
read-cache.c | 22 +++++++++++++++++-----
t/t7102-reset.sh | 3 ++-
2 files changed, 19 insertions(+), 6 deletions(-)
diff --git a/read-cache.c b/read-cache.c
index f1aff81..4a4f4a5 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1065,6 +1065,15 @@ static struct cache_entry *refresh_cache_ent(struct index_state *istate,
return updated;
}
+static void show_file(const char * fmt, const char * name, int in_porcelain, int * first)
+{
+ if (in_porcelain && *first) {
+ printf("Unstaged changes after reset:\n");
+ *first=0;
+ }
+ printf(fmt, name);
+}
+
int refresh_index(struct index_state *istate, unsigned int flags, const char **pathspec, char *seen)
{
int i;
@@ -1074,11 +1083,14 @@ int refresh_index(struct index_state *istate, unsigned int flags, const char **p
int quiet = (flags & REFRESH_QUIET) != 0;
int not_new = (flags & REFRESH_IGNORE_MISSING) != 0;
int ignore_submodules = (flags & REFRESH_IGNORE_SUBMODULES) != 0;
+ int first = 1;
+ int in_porcelain = (flags & REFRESH_IN_PORCELAIN);
unsigned int options = really ? CE_MATCH_IGNORE_VALID : 0;
- const char *needs_update_message;
+ const char *needs_update_fmt;
+ const char *needs_merge_fmt;
- needs_update_message = ((flags & REFRESH_IN_PORCELAIN)
- ? "locally modified" : "needs update");
+ needs_update_fmt = (in_porcelain ? "M\t%s\n" : "%s: needs update\n");
+ needs_merge_fmt = (in_porcelain ? "U\t%s\n" : "%s: needs merge\n");
for (i = 0; i < istate->cache_nr; i++) {
struct cache_entry *ce, *new;
int cache_errno = 0;
@@ -1094,7 +1106,7 @@ int refresh_index(struct index_state *istate, unsigned int flags, const char **p
i--;
if (allow_unmerged)
continue;
- printf("%s: needs merge\n", ce->name);
+ show_file(needs_merge_fmt, ce->name, in_porcelain, &first);
has_errors = 1;
continue;
}
@@ -1117,7 +1129,7 @@ int refresh_index(struct index_state *istate, unsigned int flags, const char **p
}
if (quiet)
continue;
- printf("%s: %s\n", ce->name, needs_update_message);
+ show_file(needs_update_fmt, ce->name, in_porcelain, &first);
has_errors = 1;
continue;
}
diff --git a/t/t7102-reset.sh b/t/t7102-reset.sh
index e637c7d..e85ff02 100755
--- a/t/t7102-reset.sh
+++ b/t/t7102-reset.sh
@@ -419,7 +419,8 @@ test_expect_success 'resetting an unmodified path is a no-op' '
'
cat > expect << EOF
-file2: locally modified
+Unstaged changes after reset:
+M file2
EOF
test_expect_success '--mixed refreshes the index' '
--
1.6.4.62.g39c83.dirty
^ permalink raw reply related
* Re: Problem compiling git-1.6.4 on OpenServer 6.0
From: Junio C Hamano @ 2009-08-07 20:07 UTC (permalink / raw)
To: Boyd Lynn Gerber; +Cc: Git List
In-Reply-To: <alpine.LNX.2.00.0908071326250.13290@suse104.zenez.com>
Boyd Lynn Gerber <gerberb@zenez.com> writes:
> I just tried to compile the latest git and I get this error.
>
> CC builtin-pack-objects.o
> UX:acomp: ERROR: "builtin-pack-objects.c", line 1602: integral
> constant expression expected
I think we recently acquired another instance of variable sized array on
the stack in addition to this one.
^ permalink raw reply
* Re: [PATCH] push: point to 'git pull' and 'git push --force' in case of non-fast forward
From: Junio C Hamano @ 2009-08-07 20:05 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqvdkzwh3j.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> +Alternatively, you can rebase your change between X and B on top of A,
>> +with "git pull --rebase", and push the result back. The rebase will
>> +create a new commit D that builds the change between X and B on top of
>> +A.
>> +
>> +----------------
>> +
>> + B D
>> + / /
>> + ---X---A
>> +
>> +----------------
>> +
>> +Again, updating A with this commit will fast-forward and your push will be
>> +accepted.
>
> Maybe add something about --force ? I don't like my wording very much,
> but a first try is this:
>
> Lastly, you can decide that the B shouldn't have existed, and delete
> it. This is to do with a lot of care, not only because it will discard
> the changes introduced in B, but also because if B has been pulled by
> someone else, he will have a view of history inconsistant with the
> original repository. This is done with the --force option.
To be consistent with the flow, I think you are discarding A in the
example, not B. A is what somebody else pushed out before your failed
attempt of pushing B, and --force will discard A, replacing its history
with yours.
Of course, you also could decide that somebody else's change A is vastly
superior than your crappy B, and you may decide to do "git reset --hard A"
to get rid of your history locally; but you wouldn't be using "git push"
after that. It is an equally valid outcome in the example situation and
until you fetch to see what A is, you cannot decide.
So, probably the order to teach would be:
- You can pull to merge, or pull --rebase to rebase; either way, you are
trying to preserve both histories. [I've written on this in the
previous message]
- But you may realize that the commit by the other (i.e. A) was an
incorrect solution to the same problem you solved with your B. You
_could_ force the push to replace it with B in such a case. You need
to tell the person who pushed A (and everybody else who might have
fetched A and built on top) to discard their history (and rebuild their
work that was done on top of A on top of B). [This is yours with A <=> B]
- Alternatively you may realize that the commit by the other (i.e. A) was
much better solution to the same problem you tried to solve with your
B. In such a case, you can simply discard B in your history with "git
reset --hard A" after fetching. You wouldn't be pushing anything back
in this case.
I actually do not think it is appropriate to teach --force in an example
that involves more than one person (iow, in the context of the example in
my patch). A lot better alternative in such a case is to "git merge -s
ours A" and push the result out, which keeps the fast-forwardness for the
person who did A, and others who pulled and built on top of A already.
So scratch your "lastly", replace it (and the second point in my list
above) with:
- You may realize that the commit by the other (i.e. A) was an incorrect
solution to the same problem you solved with your B. In such a case,
do _not_ use --force to remove A from the public history. Instead,
resolve the merge (in the previous instruction) favoring your solution,
e.g. "git pull -s ours", and push the result out.
^ permalink raw reply
* Re: [PATCH] push: point to 'git pull' and 'git push --force' in case of non-fast forward
From: Michael J Gruber @ 2009-08-07 19:46 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Michael J Gruber, git, gitster
In-Reply-To: <vpqzlabwhue.fsf@bauges.imag.fr>
Matthieu Moy venit, vidit, dixit 07.08.2009 21:21:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
>
>> May I suggest "Some push was rejected because it would not result in a
>> fast forward:\n Merge in the remote changes (using git pull) before
>> pushing yours\n or use..."?
>
> Are you sure this is "Some push _was_ ..."? In the general case,
> several branches are rejected, so that would be "were", no?
>
Well, I'm certainly sure about the "yours" vs "your's" and about the
rewording of "due to".
If you want plural then please use "Some pushes were". I suggested the
singular, "A push was" or "Some push was". "Some" can denote an amount
but it is also used as a determiner in sentences like: "Some guy here
pretends to know English although he's not a native speaker." That would
be me :)
We don't know how many pushes failed, only that at least one did. Being
a mathematician I have to use the singular here, but feel free to use
the plural (also for the noun).
Cheers,
Michael
^ permalink raw reply
* [PATCH 1/1] git-svn: ignore leading blank lines in svn:ignore
From: Michael Haggerty @ 2009-08-07 19:21 UTC (permalink / raw)
To: git; +Cc: gitster, Michael Haggerty
Subversion ignores all blank lines in svn:ignore properties. The old
git-svn code ignored blank lines everywhere except for the first line
of the svn:ignore property. This patch makes the "git svn
show-ignore" and "git svn create-ignore" commands ignore leading blank
lines, too.
Also include leading blank lines in the test suite.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
git-svn.perl | 2 ++
t/t9101-git-svn-props.sh | 5 ++++-
2 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index d075810..f1cc849 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -764,6 +764,7 @@ sub cmd_show_ignore {
print STDOUT "\n# $path\n";
my $s = $props->{'svn:ignore'} or return;
$s =~ s/[\r\n]+/\n/g;
+ $s =~ s/^\n+//;
chomp $s;
$s =~ s#^#$path#gm;
print STDOUT "$s\n";
@@ -801,6 +802,7 @@ sub cmd_create_ignore {
open(GITIGNORE, '>', $ignore)
or fatal("Failed to open `$ignore' for writing: $!");
$s =~ s/[\r\n]+/\n/g;
+ $s =~ s/^\n+//;
chomp $s;
# Prefix all patterns so that the ignore doesn't apply
# to sub-directories.
diff --git a/t/t9101-git-svn-props.sh b/t/t9101-git-svn-props.sh
index 9da4178..929499e 100755
--- a/t/t9101-git-svn-props.sh
+++ b/t/t9101-git-svn-props.sh
@@ -142,7 +142,9 @@ test_expect_success 'test show-ignore' "
touch deeply/nested/directory/.keep &&
svn_cmd add deeply &&
svn_cmd up &&
- svn_cmd propset -R svn:ignore 'no-such-file*' .
+ svn_cmd propset -R svn:ignore '
+no-such-file*
+' .
svn_cmd commit -m 'propset svn:ignore'
cd .. &&
git svn show-ignore > show-ignore.got &&
@@ -171,6 +173,7 @@ test_expect_success 'test create-ignore' "
"
cat >prop.expect <<\EOF
+
no-such-file*
EOF
--
1.6.4
^ permalink raw reply related
* Re: [PATCH] push: point to 'git pull' and 'git push --force' in case of non-fast forward
From: Matthieu Moy @ 2009-08-07 19:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7hxgk8c9.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Matthieu Moy <Matthieu.Moy@imag.fr> writes:
>
>> 'git push' failing because of non-fast forward is a very common situation,
>> and a beginner does not necessarily understand "fast forward" immediately.
>>
>> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
>> ---
>> That may be a bit verbose, but I think it's worth it.
>> ...
>> + if (nonfastforward) {
>> + printf("Some branch push were rejected due to non-fast forward:\n");
>> + printf("Merge the remote changes (git pull) before pushing your's\n");
>> + printf("or use git push --force to discard the remote changes.\n");
>> + }
>
> Although I think the patch identified the right place to make changes, I
> am not sure about what the help message should say.
>
> If the user lacks understanding of what a fast-forward is, I do not think
> giving two choices that would produce vastly different results
Well, there are different levels of mis-understanding of
"fast-forward", and one of them is just a mis-understanding of the
wording.
My experience is that many people understand "there are changes over
there that you don't have so an explicit merge is needed", but would
not necessarily use the wording "fast-forward" for this.
The second line of my message was not only here to point to "git
pull", but had also a subliminal message stating that there are
remote changes ;-).
> Jokes aside, perhaps we could add "see git-push documentation for details"
> to the above message of yours, and add something like this to the
> documentation.
100% convinced that this section in the doc is a good idea. I'm not
totally sure the error message should point to it, because that will
make the message 4 lines long instead of 3, so it may start disturbing
gurus for whom the whole message is useless.
Right now, I have this in my tree:
if (nonfastforward) {
printf("Some push were rejected because it would not result in a fast forward:\n"
"Merge in the remote changes (using git pull) before pushing yours, or\n"
"use git push --force to discard the remote changes.\n"
"See 'non-fast forward' section of 'git push --help' for details.\n");
}
> +Alternatively, you can rebase your change between X and B on top of A,
> +with "git pull --rebase", and push the result back. The rebase will
> +create a new commit D that builds the change between X and B on top of
> +A.
> +
> +----------------
> +
> + B D
> + / /
> + ---X---A
> +
> +----------------
> +
> +Again, updating A with this commit will fast-forward and your push will be
> +accepted.
Maybe add something about --force ? I don't like my wording very much,
but a first try is this:
Lastly, you can decide that the B shouldn't have existed, and delete
it. This is to do with a lot of care, not only because it will discard
the changes introduced in B, but also because if B has been pulled by
someone else, he will have a view of history inconsistant with the
original repository. This is done with the --force option.
--
Matthieu
^ permalink raw reply
* Problem compiling git-1.6.4 on OpenServer 6.0
From: Boyd Lynn Gerber @ 2009-08-07 19:27 UTC (permalink / raw)
To: Git List
Hello,
I just tried to compile the latest git and I get this error.
CC builtin-pack-objects.o
UX:acomp: ERROR: "builtin-pack-objects.c", line 1602: integral constant
expression expected
gmake: *** [builtin-pack-objects.o] Error 1
I will look into it when I have a bit more time, but this is a heads up.
Thanks,
--
Boyd Gerber <gerberb@zenez.com> 801 849-0213
ZENEZ 1042 East Fort Union #135, Midvale Utah 84047
^ permalink raw reply
* Re: [PATCH] push: point to 'git pull' and 'git push --force' in case of non-fast forward
From: Matthieu Moy @ 2009-08-07 19:21 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git, gitster
In-Reply-To: <4A7B3760.2000303@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
> May I suggest "Some push was rejected because it would not result in a
> fast forward:\n Merge in the remote changes (using git pull) before
> pushing yours\n or use..."?
Are you sure this is "Some push _was_ ..."? In the general case,
several branches are rejected, so that would be "were", no?
--
Matthieu
^ permalink raw reply
* [PATCH/RFC] Makefile: build/install git-remote-<scheme> as hardlinks when able
From: Junio C Hamano @ 2009-08-07 19:19 UTC (permalink / raw)
To: Daniel Barkalow, Johannes Schindelin; +Cc: git
In-Reply-To: <7v63d06wjq.fsf@alter.siamese.dyndns.org>
Three git-remote-<scheme> helper programs are the same executable that
uses libcurl to implement the named protocol transfer. Instead of
running the linker three times to build different programs, build one and
hardlink (or copy if the underlying filesystem does not support it) the
other two.
Install one to $(gitexecdir) and make the other two hardnlinks, in a way
similar to how we install programs that implement built-in commands.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
I do not particularly like this one. ALL_PROGRAMS does not include any of
the built-in programs, but because CURL_SYNONYMS are part of PROGRAMS, the
install step needs to filter them out, so that we can arrange to make
hardlinks to the synonyms in a separate step.
Putting git-remote-http$X on OTHER_PROGRAMS like we do for git$X does not
work well either, as that won't install it in gitexecdir.
Makefile | 23 +++++++++++++++++++----
1 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/Makefile b/Makefile
index e29b15f..438cffb 100644
--- a/Makefile
+++ b/Makefile
@@ -383,7 +383,8 @@ BUILT_INS += git-stage$X
BUILT_INS += git-status$X
BUILT_INS += git-whatchanged$X
-# what 'all' will build and 'install' will install, in gitexecdir
+# what 'all' will build and 'install' will install in gitexecdir,
+# excluding programs for built-in commands
ALL_PROGRAMS = $(PROGRAMS) $(SCRIPTS)
# what 'all' will build but not install in gitexecdir
@@ -980,7 +981,8 @@ else
else
CURL_LIBCURL = -lcurl
endif
- PROGRAMS += git-remote-http$X git-remote-https$X git-remote-ftp$X git-http-fetch$X
+ CURL_SYNONYMS = git-remote-https$X git-remote-ftp$X
+ PROGRAMS += git-remote-http$X $(CURL_SYNONYMS) git-http-fetch$X
curl_check := $(shell (echo 070908; curl-config --vernum) | sort -r | sed -ne 2p)
ifeq "$(curl_check)" "070908"
ifndef NO_EXPAT
@@ -1256,6 +1258,7 @@ ifndef V
QUIET_LINK = @echo ' ' LINK $@;
QUIET_BUILT_IN = @echo ' ' BUILTIN $@;
QUIET_GEN = @echo ' ' GEN $@;
+ QUIET_LNCP = @echo ' ' LN/CP $@;
QUIET_SUBDIR0 = +@subdir=
QUIET_SUBDIR1 = ;$(NO_SUBDIR) echo ' ' SUBDIR $$subdir; \
$(MAKE) $(PRINT_DIR) -C $$subdir
@@ -1494,10 +1497,16 @@ git-http-push$X: revision.o http.o http-push.o $(GITLIBS)
$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
$(LIBS) $(CURL_LIBCURL) $(EXPAT_LIBEXPAT)
-git-remote-http$X git-remote-https$X git-remote-ftp$X: remote-curl.o http.o http-walker.o $(GITLIBS)
+git-remote-http$X: remote-curl.o http.o http-walker.o $(GITLIBS)
$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
$(LIBS) $(CURL_LIBCURL) $(EXPAT_LIBEXPAT)
+$(CURL_SYNONYMS): git-remote-http$X
+ $(QUIET_LNCP)$(RM) $@ && \
+ ln $< $@ 2>/dev/null || \
+ ln -s $< $@ 2>/dev/null || \
+ cp $< $@
+
$(LIB_OBJS) $(BUILTIN_OBJS): $(LIB_H)
$(patsubst git-%$X,%.o,$(PROGRAMS)) git.o: $(LIB_H) $(wildcard */*.h)
builtin-revert.o wt-status.o: wt-status.h
@@ -1653,7 +1662,7 @@ export gitexec_instdir
install: all
$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(bindir_SQ)'
$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(gitexec_instdir_SQ)'
- $(INSTALL) $(ALL_PROGRAMS) '$(DESTDIR_SQ)$(gitexec_instdir_SQ)'
+ $(INSTALL) $(filter-out $(CURL_SYNONYMS), $(ALL_PROGRAMS)) '$(DESTDIR_SQ)$(gitexec_instdir_SQ)'
$(INSTALL) git$X git-upload-pack$X git-receive-pack$X git-upload-archive$X git-shell$X git-cvsserver '$(DESTDIR_SQ)$(bindir_SQ)'
$(MAKE) -C templates DESTDIR='$(DESTDIR_SQ)' install
ifndef NO_PERL
@@ -1679,6 +1688,12 @@ endif
ln -s "git$X" "$$execdir/$$p" 2>/dev/null || \
cp "$$execdir/git$X" "$$execdir/$$p" || exit; \
done; } && \
+ { for p in $(CURL_SYNONYMS); do \
+ $(RM) "$$execdir/$$p" && \
+ ln "$$execdir/git-remote-http$X" "$$execdir/$$p" 2>/dev/null || \
+ ln -s "git-remote-http$X" "$$execdir/$$p" 2>/dev/null || \
+ cp "$$execdir/git-remote-http$X" "$$execdir/$$p" || exit; \
+ done; } && \
./check_bindir "z$$bindir" "z$$execdir" "$$bindir/git-add$X"
install-doc:
^ permalink raw reply related
* Re: [PATCH] Change mentions of "git programs" to "git commands"
From: Junio C Hamano @ 2009-08-07 18:15 UTC (permalink / raw)
To: Ori Avtalion; +Cc: git
In-Reply-To: <4a7c3971.170d660a.3caa.20b3@mx.google.com>
Ori Avtalion <ori@avtalion.name> writes:
> Most of the docs and printouts refer to "commands".
> This patch changes the other terminology to be consistent.
Thanks, but not really.
> @@ -605,7 +605,7 @@ color.interactive.<slot>::
> Use customized color for 'git-add --interactive'
> output. `<slot>` may be `prompt`, `header`, `help` or `error`, for
> four distinct types of normal output from interactive
> - programs. The values of these variables may be specified as
> + commands. The values of these variables may be specified as
This is good.
> color.pager::
> @@ -1113,7 +1113,7 @@ instaweb.port::
> linkgit:git-instaweb[1].
>
> interactive.singlekey::
> - In interactive programs, allow the user to provide one-letter
> + In interactive commands, allow the user to provide one-letter
This is good.
> diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
> index d313795..20bf512 100644
> --- a/Documentation/fetch-options.txt
> +++ b/Documentation/fetch-options.txt
> @@ -1,7 +1,7 @@
> -q::
> --quiet::
> Pass --quiet to git-fetch-pack and silence any other internally
> - used programs.
> + used utilities.
This does not have much to do with what you claim to have done in the
commit log message nor the title. Probably "utilities" is a slightly
better word than "programs" in this context but not by a wide margin.
> -'git-rev-list' is a very essential git program, since it
> +'git-rev-list' is a very essential git command, since it
> provides the ability to build and traverse commit ancestry graphs. For
> this reason, it has a lot of different options that enables it to be
> used by commands as different as 'git-bisect' and
Ok, but probably we would want to say "git rev-list" here.
> --exec-path::
> - Path to wherever your core git programs are installed.
> + Path to wherever your core git commands are installed.
I do not think this is a good change.
When you talk about git "command", e.g. "'git rev-list' is an essential
command", you are talking about an abstract concept. In the reader's
world view, there is one single toplevel program called "git" and it has
various commands, one of which is 'rev-list'. But this description is not
about an abstract concept of command, but is about a particular
implementation detail. For every git command, there is a corresponding
git _program_ that implements that command, and --exec-path tells you (or
you use --exec-path to tell the git toplevel program) where they are.
You kept this intact in gitcore-tutorial:
... Also
you need to make sure that you have the 'git-receive-pack'
program on the `$PATH`.
and I think you did the right thing. This is about a concrete instance of
a program. If you really really want to say _command_, you would probably
want to do something like this instead:
--exec-path::
- Path to wherever your core git programs are installed.
+ Path to the directory that holds programs that implements git commands.
> @@ -327,7 +327,7 @@ Synching repositories
>
> include::cmds-synchingrepositories.txt[]
>
> -The following are helper programs used by the above; end users
> +The following are helper commands used by the above; end users
> typically do not use them directly.
Ok.
> The attribute `merge` affects how three versions of a file is
> merged when a file-level merge is necessary during `git merge`,
> -and other programs such as `git revert` and `git cherry-pick`.
> +and other commands such as `git revert` and `git cherry-pick`.
Ok.
> diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt
> index 7ba5e58..b3640c4 100644
> --- a/Documentation/gitcore-tutorial.txt
> +++ b/Documentation/gitcore-tutorial.txt
> @@ -12,7 +12,7 @@ git *
> DESCRIPTION
> -----------
>
> -This tutorial explains how to use the "core" git programs to set up and
> +This tutorial explains how to use the "core" git commands to set up and
> work with a git repository.
>
> If you just need to use git as a revision control system you may prefer
Ok.
> @@ -1328,7 +1328,7 @@ into it later. Obviously, this repository creation needs to be
> done only once.
>
> [NOTE]
> -'git-push' uses a pair of programs,
> +'git-push' uses a pair of commands,
> 'git-send-pack' on your local machine, and 'git-receive-pack'
> on the remote machine. The communication between the two over
> the network internally uses an SSH connection.
Ok.
> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> index 0b88a51..67ebffa 100644
> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -4131,7 +4131,7 @@ What does this mean?
>
> `git rev-list` is the original version of the revision walker, which
> _always_ printed a list of revisions to stdout. It is still functional,
> -and needs to, since most new Git programs start out as scripts using
> +and needs to, since most new Git commands start out as scripts using
> `git rev-list`.
Ok.
> `git rev-parse` is not as important any more; it was only used to filter out
> diff --git a/help.c b/help.c
> index 6c46d8b..57a0e0e 100644
> --- a/help.c
> +++ b/help.c
> @@ -334,7 +334,7 @@ const char *help_unknown_cmd(const char *cmd)
> const char *assumed = main_cmds.names[0]->name;
> main_cmds.names[0] = NULL;
> clean_cmdnames(&main_cmds);
> - fprintf(stderr, "WARNING: You called a Git program named '%s', "
> + fprintf(stderr, "WARNING: You called a Git command named '%s', "
> "which does not exist.\n"
> "Continuing under the assumption that you meant '%s'\n",
> cmd, assumed);
Ok.
^ permalink raw reply
* Re: Gitweb giving me some warnings in Apache's error_log
From: Mark Rada @ 2009-08-07 17:56 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3my6bpv6v.fsf@localhost.localdomain>
Let me double check my understanding.
The warnings will not occur if Gitweb is run as a regular CGI script
because then it won't be nested inside a call from
ModPerl::Registry?
Will it also not complain if I provided my own $project_list in the first place?
Also, I looked at some examples from the second and third page of an article
on the subject, http://www.perl.com/pub/a/2002/05/07/mod_perl.html?
and it looks "fixable". Is there a particular reason why any of them are not
desirable?
Note: I haven't tried anything yet, just wondering if you know off hand
--
Mark A Rada (ferrous26)
marada@uwaterloo.ca
On Fri, Aug 7, 2009 at 10:14 AM, Jakub Narebski<jnareb@gmail.com> wrote:
> Mark A Rada <markrada26@gmail.com> writes:
>
>> It doesn't seem to cause any other problems, but I don't know if it is
>> significant or not.
>>
>> [Fri Aug 7 08:51:13 2009] gitweb.cgi: Variable "$project_maxdepth"
>> may be unavailable at /var/www/private/gitweb/cgi-bin/gitweb.cgi line
>> 2296.
>> [Fri Aug 7 08:51:13 2009] gitweb.cgi: Variable "$projectroot" may be
>> unavailable at /var/www/private/gitweb/cgi-bin/gitweb.cgi line 2304.
>>
>>
>> Apache 2.2.12/ mod_perl 2.04/ perl 5.8.8
>
> From perldiag(1) manpage:
>
> Variable "%s" may be unavailable
>
> (W closure) An inner (nested) anonymous subroutine is inside a
> named subroutine, and outside that is another subroutine; and the
> anonymous (innermost) subroutine is referencing a lexical variable
> defined in the outermost subroutine. For example:
>
> sub outermost { my $a; sub middle { sub { $a } } }
>
> If the anonymous subroutine is called or referenced (directly or
> indirectly) from the outermost subroutine, it will share the
> variable as you would expect. But if the anonymous subroutine is
> called or referenced when the outermost subroutine is not active,
> it will see the value of the shared variable as it was before and
> during the *first* call to the outermost subroutine, which is
> probably not what you want.
>
> In these circumstances, it is usually best to make the middle
> subroutine anonymous, using the "sub {}" syntax. Perl has
> specific support for shared variables in nested anonymous
> subroutines; a named subroutine in between interferes with this
> feature.
>
> The warning is about 'wanted' anonymous subroutine passed to
> File::Find::find. The "middle" subroutine is git_get_projects_list,
> and the "outermost" is mod_perl / ModPerl::Registry request loop.
>
> We can't make git_get_projects_list anonymous, but anonymous
> subroutine is not called or referenced outside git_get_projects_list,
> nor it is called or referenced outside mod_perl request/event loop.
>
> This warning is harmless... but I do not know how to silence it.
>
> --
> Jakub Narebski
> Poland
> ShadeHawk on #git
>
^ permalink raw reply
* Re: Problem running 'make install' as root when on mounted fs
From: Junio C Hamano @ 2009-08-07 17:51 UTC (permalink / raw)
To: Alex Blewitt; +Cc: git
In-Reply-To: <8F9F4A8A-9515-4A7D-90EE-4BD3DA3F7A2B@gmail.com>
Alex Blewitt <alex.blewitt@gmail.com> writes:
> I think it would be possible to restrict the GIT-BUILD-OPTIONS to be
> generated during a build phase, so restructuring the Makefile like:
>
> install: build
> all:: build GIT-BUILD-OPTIONS
> build: ...
If you did:
make prefix=$HOME all
make prefix=/usr install
then the second step needs to notice that the gitexecdir computed and
stored in exec_cmd.o in the first step is now invalid, and needs to
recompile the file. The whole purpose of GIT-BUILD-OPTIONS is to detect
such a case---doesn't your change defeat it?
^ permalink raw reply
* Re: [ANNOUNCE] tortoisegit 0.9.1.0
From: Sverre Rabbelier @ 2009-08-07 16:24 UTC (permalink / raw)
To: John Tapsell, Johannes Schindelin
Cc: Tim Harper, Frank Li, git, tortoisegit-dev, tortoisegit-users,
tortoisegit-announce, tortoisegit
In-Reply-To: <43d8ce650908062348x3bbfac30w6be13ffce43b33d9@mail.gmail.com>
Heya,
On Thu, Aug 6, 2009 at 23:48, John Tapsell<johnflux@gmail.com> wrote:
> How hard would it be to port this to KDE?
Impossible.
> What would be involved?
Port all Windows specific code; instead, you should have a look at
git-cheetah, which aims to do the same thing, only platform agnostic.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* problems setting gitattribute ident for a whole directory
From: Edke @ 2009-08-07 15:21 UTC (permalink / raw)
To: git
Hello.
I'm moving from SVN to Git, started just two days ago. I'm amazed with Git
so far, also using it with SVN solid.
I'm having few difficulties setting ident attribute:
1) Setting it for a whole directory. I tried .git/info/attributes,
.gitattributes in root of my project, I tried some patterns ( app/*, app/,
app* ), nothing work so far. Using app/* works for files placed in app
folder but I need to apply this attribute for a whole directory
(recursively).
2) If applied correctly, will it work with files that already exists in
project ?
3) What I need to do so that changes (replacing $Id$ with hash) will show in
all affected files ? I found some tutorial, where author applies this as rm
file; git checkout -- file. But how should I proceed for a whole project ?
--
View this message in context: http://www.nabble.com/problems-setting-gitattribute-ident-for-a-whole-directory-tp24866724p24866724.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH 0/5] Suggested for PU: revision caching system to significantly speed up packing/walking
From: Nicolas Pitre @ 2009-08-07 15:00 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Sam Vilain, Nick Edelen, Michael J Gruber, Junio C Hamano,
Jeff King, Shawn O. Pearce, Andreas Ericsson, Christian Couder,
git@vger.kernel.org
In-Reply-To: <alpine.DEB.1.00.0908070808340.8306@pacific.mpi-cbg.de>
On Fri, 7 Aug 2009, Johannes Schindelin wrote:
> On Fri, 7 Aug 2009, Sam Vilain wrote:
>
> > Especially as in this case as Nick mentions, the domain is subtly
> > different (ie pack vs dag). Unfortunately you just can't try to pretend
> > that they will always be the same; you can't force a full repack on
> > every ref change!
>
> No, but you do not need that, either. In the setting that is most likely
> the most thankful one, i.e. a git:// server, you _want_ to keep the
> repository "as packed as possible", otherwise the rev cache improvements
> will be lost in the bad packing performance anyway.
Yes and no.
Currently, the number #1 latency in any initial git clone is the famous
"counting objects" phase, even if the repo is perfectly packed. And
that's all this rev cache can and will improve. The packing does play
its performance role of course, but for a totally different reason.
Hence the repository needs no be perfectly packed for a rev cache to
speed up its own part of the game.
> > > Still, there is some redundancy between the pack index and your cache,
> > > as you have to write out the whole list of SHA-1s all over again. I
> > > guess it is time to look at the code instead of asking stupid
> > > questions.
> > >
> >
> > "Disk is cheap" :-)
>
> Disk I/O ain't.
>
> (Size of the I/O caches, yaddayadda, I'm sure you get my point).
I don't know about the size of the rev cache on disk yet (I asked Nick
about that) nor do I really know how this cache is implemented. But I
know damn well about git packs and associated index and I for sure don't
want to see a revision cache coupled with it.
And for a clone the disk IO will certainly be a magnitude larger than
for the cache (or so I hope). Maybe the IO for the rev cache might be a
significant overhead for operations performed on a client (aka
developer) repository, in which case it would be a good idea to have a
config variable to control the cache size, or even to turn it off
entirely. We do it for delta depth and many other things already.
Nicolas
^ permalink raw reply
* [PATCH] Change mentions of "git programs" to "git commands"
From: Ori Avtalion @ 2009-08-07 14:24 UTC (permalink / raw)
To: git
Most of the docs and printouts refer to "commands".
This patch changes the other terminology to be consistent.
Signed-off-by: Ori Avtalion <ori@avtalion.name>
---
Documentation/config.txt | 4 ++--
Documentation/fetch-options.txt | 2 +-
Documentation/git-rev-list.txt | 2 +-
Documentation/git.txt | 4 ++--
Documentation/gitattributes.txt | 2 +-
Documentation/gitcore-tutorial.txt | 4 ++--
Documentation/user-manual.txt | 2 +-
help.c | 2 +-
8 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index c6f09f8..e94a8ab 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -605,7 +605,7 @@ color.interactive.<slot>::
Use customized color for 'git-add --interactive'
output. `<slot>` may be `prompt`, `header`, `help` or `error`, for
four distinct types of normal output from interactive
- programs. The values of these variables may be specified as
+ commands. The values of these variables may be specified as
in color.branch.<slot>.
color.pager::
@@ -1113,7 +1113,7 @@ instaweb.port::
linkgit:git-instaweb[1].
interactive.singlekey::
- In interactive programs, allow the user to provide one-letter
+ In interactive commands, allow the user to provide one-letter
input with a single key (i.e., without hitting enter).
Currently this is used only by the `\--patch` mode of
linkgit:git-add[1]. Note that this setting is silently
diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
index d313795..20bf512 100644
--- a/Documentation/fetch-options.txt
+++ b/Documentation/fetch-options.txt
@@ -1,7 +1,7 @@
-q::
--quiet::
Pass --quiet to git-fetch-pack and silence any other internally
- used programs.
+ used utilities.
-v::
--verbose::
diff --git a/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt
index bf98c84..21ccccd 100644
--- a/Documentation/git-rev-list.txt
+++ b/Documentation/git-rev-list.txt
@@ -90,7 +90,7 @@ between the two operands. The following two commands are equivalent:
$ git rev-list A...B
-----------------------------------------------------------------------
-'git-rev-list' is a very essential git program, since it
+'git-rev-list' is a very essential git command, since it
provides the ability to build and traverse commit ancestry graphs. For
this reason, it has a lot of different options that enables it to be
used by commands as different as 'git-bisect' and
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 5fd5953..fe13e09 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -189,7 +189,7 @@ because `git --help ...` is converted internally into `git
help ...`.
--exec-path::
- Path to wherever your core git programs are installed.
+ Path to wherever your core git commands are installed.
This can also be controlled by setting the GIT_EXEC_PATH
environment variable. If no path is given, 'git' will print
the current setting and then exit.
@@ -327,7 +327,7 @@ Synching repositories
include::cmds-synchingrepositories.txt[]
-The following are helper programs used by the above; end users
+The following are helper commands used by the above; end users
typically do not use them directly.
include::cmds-synchelpers.txt[]
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index aaa073e..1195e83 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -404,7 +404,7 @@ Performing a three-way merge
The attribute `merge` affects how three versions of a file is
merged when a file-level merge is necessary during `git merge`,
-and other programs such as `git revert` and `git cherry-pick`.
+and other commands such as `git revert` and `git cherry-pick`.
Set::
diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt
index 7ba5e58..b3640c4 100644
--- a/Documentation/gitcore-tutorial.txt
+++ b/Documentation/gitcore-tutorial.txt
@@ -12,7 +12,7 @@ git *
DESCRIPTION
-----------
-This tutorial explains how to use the "core" git programs to set up and
+This tutorial explains how to use the "core" git commands to set up and
work with a git repository.
If you just need to use git as a revision control system you may prefer
@@ -1328,7 +1328,7 @@ into it later. Obviously, this repository creation needs to be
done only once.
[NOTE]
-'git-push' uses a pair of programs,
+'git-push' uses a pair of commands,
'git-send-pack' on your local machine, and 'git-receive-pack'
on the remote machine. The communication between the two over
the network internally uses an SSH connection.
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 0b88a51..67ebffa 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -4131,7 +4131,7 @@ What does this mean?
`git rev-list` is the original version of the revision walker, which
_always_ printed a list of revisions to stdout. It is still functional,
-and needs to, since most new Git programs start out as scripts using
+and needs to, since most new Git commands start out as scripts using
`git rev-list`.
`git rev-parse` is not as important any more; it was only used to filter out
diff --git a/help.c b/help.c
index 6c46d8b..57a0e0e 100644
--- a/help.c
+++ b/help.c
@@ -334,7 +334,7 @@ const char *help_unknown_cmd(const char *cmd)
const char *assumed = main_cmds.names[0]->name;
main_cmds.names[0] = NULL;
clean_cmdnames(&main_cmds);
- fprintf(stderr, "WARNING: You called a Git program named '%s', "
+ fprintf(stderr, "WARNING: You called a Git command named '%s', "
"which does not exist.\n"
"Continuing under the assumption that you meant '%s'\n",
cmd, assumed);
--
1.6.0.4
^ permalink raw reply related
* Re: [PATCH 0/5] Suggested for PU: revision caching system to significantly speed up packing/walking
From: Nicolas Pitre @ 2009-08-07 14:18 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Sam Vilain, Nick Edelen, Michael J Gruber, Junio C Hamano,
Jeff King, Shawn O. Pearce, Andreas Ericsson, Christian Couder,
git@vger.kernel.org
In-Reply-To: <alpine.DEB.1.00.0908070806350.8306@pacific.mpi-cbg.de>
On Fri, 7 Aug 2009, Johannes Schindelin wrote:
> Hi,
>
> On Fri, 7 Aug 2009, Nicolas Pitre wrote:
>
> > On Fri, 7 Aug 2009, Sam Vilain wrote:
> >
> > > Johannes Schindelin wrote:
> > > >> the short answer is that cache slices are totally independant of
> > > >> pack files.
> > > >>
> > > >
> > > > My idea with that was that you already have a SHA-1 map in the pack
> > > > index, and if all you want to be able to accelerate the revision
> > > > walker, you'd probably need something that adds yet another mapping,
> > > > from commit to parents and tree, and from tree to sub-tree and blob
> > > > (so you can avoid unpacking commit and tree objects).
> > > >
> > >
> > > Tying indexes together like that is not a good idea in the database
> > > world. Especially as in this case as Nick mentions, the domain is
> > > subtly different (ie pack vs dag). Unfortunately you just can't try to
> > > pretend that they will always be the same; you can't force a full
> > > repack on every ref change!
> >
> > Right. And the rev cache must work even if the repository is not
> > packed.
>
> Umm, why? AFAICT the principal purpose of the rev cache is to help work
> loads on, say, www.kernel.org.
So what?
Speeding up rev-list with a rev cache is completely orthogonal to
whether the repository is packed or not. It is like having a "git diff"
result cache: no one would think of stuffing that in the pack index.
If we want to improve on the repository packing format, that must be
doable without bothering with an independent concept such as a rev
cache.
> I am unlikely to notice the improvements in my regular "git log" calls
> that only show a couple of pages before I quit the pager.
Indeed. But what is your point again?
Nicolas
^ permalink raw reply
* Re: Gitweb giving me some warnings in Apache's error_log
From: Jakub Narebski @ 2009-08-07 14:14 UTC (permalink / raw)
To: Mark A Rada; +Cc: git
In-Reply-To: <533D6DDF-4DAC-4A86-A6F7-95B54B77E48B@gmail.com>
Mark A Rada <markrada26@gmail.com> writes:
> It doesn't seem to cause any other problems, but I don't know if it is
> significant or not.
>
> [Fri Aug 7 08:51:13 2009] gitweb.cgi: Variable "$project_maxdepth"
> may be unavailable at /var/www/private/gitweb/cgi-bin/gitweb.cgi line
> 2296.
> [Fri Aug 7 08:51:13 2009] gitweb.cgi: Variable "$projectroot" may be
> unavailable at /var/www/private/gitweb/cgi-bin/gitweb.cgi line 2304.
>
>
> Apache 2.2.12/ mod_perl 2.04/ perl 5.8.8
>From perldiag(1) manpage:
Variable "%s" may be unavailable
(W closure) An inner (nested) anonymous subroutine is inside a
named subroutine, and outside that is another subroutine; and the
anonymous (innermost) subroutine is referencing a lexical variable
defined in the outermost subroutine. For example:
sub outermost { my $a; sub middle { sub { $a } } }
If the anonymous subroutine is called or referenced (directly or
indirectly) from the outermost subroutine, it will share the
variable as you would expect. But if the anonymous subroutine is
called or referenced when the outermost subroutine is not active,
it will see the value of the shared variable as it was before and
during the *first* call to the outermost subroutine, which is
probably not what you want.
In these circumstances, it is usually best to make the middle
subroutine anonymous, using the "sub {}" syntax. Perl has
specific support for shared variables in nested anonymous
subroutines; a named subroutine in between interferes with this
feature.
The warning is about 'wanted' anonymous subroutine passed to
File::Find::find. The "middle" subroutine is git_get_projects_list,
and the "outermost" is mod_perl / ModPerl::Registry request loop.
We can't make git_get_projects_list anonymous, but anonymous
subroutine is not called or referenced outside git_get_projects_list,
nor it is called or referenced outside mod_perl request/event loop.
This warning is harmless... but I do not know how to silence it.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: What's in git.git (Aug 2009, #01; Wed, 05)
From: Brandon Casey @ 2009-08-07 14:01 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Junio C Hamano, git
In-Reply-To: <20090807123346.6117@nanako3.lavabit.com>
Nanako Shiraishi wrote:
> Quoting Brandon Casey <brandon.casey.ctr@nrlssc.navy.mil>
>
>> Junio C Hamano wrote:
>>> The 1.6.4 release seems to have been quite solid, and there is no
>>> brown-paper-bag bugfixes on 'maint' yet ;-).
>> Found one.
>>
>> I didn't realize the whole git-am discussion did _not_ result in a
>> fix being applied. But git-am will currently refuse to apply any
>> patch from email that does not have "From " or "From: " in the first
>> three lines of the email. For those of us whose mail servers prepend
>> many lines of the form:
>>
>> Received: from XXX ([XXX]) by XXX with Microsoft SMTPSVC(6.0.3790.2825);
>> Tue, 14 Jul 2009 07:24:06 -0500
>
> According to an already hashed out discussion, that isn't a mbox format that has been supported, so it isn't even a bug. For details, see e.g.
>
> http://thread.gmane.org/gmane.comp.version-control.git/123338/focus=123355
>
> And Nicolas Sebrecht has been working with Junio to implement an enhancement to add support for the "individual piece of email" format.
Commit b3f041fb0f7de167dbb6711b0a231d36c4b5de08 titled 'git-am support for
naked email messages (take 2)' by H. Peter Anvin from December 2005 seems
to indicate otherwise.
IMHO, I think something was indeed broken here, but it is a moot point
since it will all be fixed (or "enhanced" depending on your POV) soon. :)
-brandon
^ permalink raw reply
* Re: [PATCH 5/5] full integration of rev-cache into git's revision walker, completed test suite
From: Nick Edelen @ 2009-08-07 13:47 UTC (permalink / raw)
To: Nick Edelen, Junio C Hamano, Johannes Schindelin, Jeff King,
Sam Vilain
In-Reply-To: <op.ux8i7ceotdk399@sirnot.private>
A small patch to eliminate the python dependency in rev-cache's test-suite.
This is a holdover for the 'integration' patch until a revised patchset is sent.
Signed-off-by: Nick Edelen <sirnot@gmail.com>
---
I've also implemented name caching, but I'd like to cleanup that (and the docs
;-) up a bit before posting it. I'll have everything ready for public display
by tonight (I've got an appointment for the next several hours).
t/t6015-rev-cache-list.sh | 39 +++++++++++++++++++++------------------
t/t6015-sha1-dump-diff.py | 36 ------------------------------------
2 files changed, 21 insertions(+), 54 deletions(-)
diff --git a/t/t6015-rev-cache-list.sh b/t/t6015-rev-cache-list.sh
index bfd9525..7c3719d 100755
--- a/t/t6015-rev-cache-list.sh
+++ b/t/t6015-rev-cache-list.sh
@@ -3,7 +3,11 @@
test_description='git rev-cache tests'
. ./test-lib.sh
-sha1diff="python $TEST_DIRECTORY/t6015-sha1-dump-diff.py"
+test_cmp_sorted() {
+ grep -io "[a-f0-9]*" $1 | sort >.tmpfile1 &&
+ grep -io "[a-f0-9]*" $2 | sort >.tmpfile2 &&
+ test_cmp .tmpfile1 .tmpfile2
+}
# we want a totally wacked out branch structure...
# we need branching and merging of sizes up through 3, tree
@@ -99,49 +103,49 @@ test_expect_success 'remake cache slice' '
#check core mechanics and rev-list hook for commits
test_expect_success 'test rev-caches walker directly (limited)' '
git-rev-cache walk HEAD --not HEAD~3 >list &&
- test -z `$sha1diff list proper_commit_list_limited`
+ test_cmp_sorted list proper_commit_list_limited
'
test_expect_success 'test rev-caches walker directly (unlimited)' '
git-rev-cache walk HEAD >list &&
- test -z `$sha1diff list proper_commit_list`
+ test_cmp_sorted list proper_commit_list
'
test_expect_success 'test rev-list traversal (limited)' '
git-rev-list HEAD --not HEAD~3 >list &&
- test -z `$sha1diff list proper_commit_list_limited`
+ test_cmp list proper_commit_list_limited
'
test_expect_success 'test rev-list traversal (unlimited)' '
git-rev-list HEAD >list &&
- test -z `$sha1diff list proper_commit_list`
+ test_cmp list proper_commit_list
'
#do the same for objects
test_expect_success 'test rev-caches walker with objects' '
git-rev-cache walk --objects HEAD >list &&
- test -z `$sha1diff list proper_object_list`
+ test_cmp_sorted list proper_object_list
'
test_expect_success 'test rev-list with objects (topo order)' '
git-rev-list --topo-order --objects HEAD >list &&
- test -z `$sha1diff list proper_object_list`
+ test_cmp_sorted list proper_object_list
'
test_expect_success 'test rev-list with objects (no order)' '
git-rev-list --objects HEAD >list &&
- test -z `$sha1diff list proper_object_list`
+ test_cmp_sorted list proper_object_list
'
#verify age limiting
test_expect_success 'test rev-list date limiting (topo order)' '
git-rev-list --topo-order --max-age=$min_date --min-age=$max_date HEAD >list &&
- test -z `$sha1diff list proper_list_date_limited`
+ test_cmp_sorted list proper_list_date_limited
'
test_expect_success 'test rev-list date limiting (no order)' '
git-rev-list --max-age=$min_date --min-age=$max_date HEAD >list &&
- test -z `sha1diff list proper_list_date_limited`
+ test_cmp_sorted list proper_list_date_limited
'
#check partial cache slice
@@ -154,7 +158,7 @@ test_expect_success 'saving old cache and generating partial slice' '
'
test_expect_success 'rev-list with wholly interesting partial slice' '
- git-rev-list --topo-order HEAD >list &&
+ git-rev-list --topo-order HEAD >list &&
test_cmp list proper_commit_list
'
@@ -199,13 +203,13 @@ test_expect_success 'corrupt slice' '
'
test_expect_success 'test rev-list traversal (limited) (corrupt slice)' '
- git-rev-list HEAD --not HEAD~3 >list &&
- test -z `$sha1diff list proper_commit_list_limited`
+ git-rev-list --topo-order HEAD --not HEAD~3 >list &&
+ test_cmp list proper_commit_list_limited
'
test_expect_success 'test rev-list traversal (unlimited) (corrupt slice)' '
git-rev-list HEAD >list &&
- test -z `$sha1diff list proper_commit_list`
+ test_cmp_sorted list proper_commit_list
'
test_expect_success 'corrupt index' '
@@ -213,16 +217,15 @@ test_expect_success 'corrupt index' '
'
test_expect_success 'test rev-list traversal (limited) (corrupt index)' '
- git-rev-list HEAD --not HEAD~3 >list &&
- test -z `$sha1diff list proper_commit_list_limited`
+ git-rev-list --topo-order HEAD --not HEAD~3 >list &&
+ test_cmp list proper_commit_list_limited
'
test_expect_success 'test rev-list traversal (unlimited) (corrupt index)' '
git-rev-list HEAD >list &&
- test -z `$sha1diff list proper_commit_list`
+ test_cmp_sorted list proper_commit_list
'
#test --ignore-size in fuse?
test_done
-
diff --git a/t/t6015-sha1-dump-diff.py b/t/t6015-sha1-dump-diff.py
deleted file mode 100755
index 7fc30e7..0000000
--- a/t/t6015-sha1-dump-diff.py
+++ /dev/null
@@ -1,36 +0,0 @@
-
-import sys, re
-
-if len(sys.argv) < 3 :
- sys.exit(0)
-
-f = open(sys.argv[1], 'r')
-dict = {}
-for line in f :
- if len(line) >= 40 and re.match(r'^[0-9a-fA-F]{40}', line[:40]) != None :
- dict[line[:40]] = 1
-
-f.close()
-
-f = open(sys.argv[2], 'r')
-for line in f :
- if len(line) < 40 :
- continue
-
- hash = line[:40]
- if re.match(r'^[0-9a-fA-F]{40}', hash) == None :
- continue
-
- if hash in dict :
- dict[hash] -= 1
- else :
- dict[hash] = -1
-
-f.close()
-
-for k in dict.keys() :
- if dict[k] == 0 :
- del dict[k]
-
-if len(dict) :
- print dict
---
^ permalink raw reply related
* Gitweb giving me some warnings in Apache's error_log
From: Mark A Rada @ 2009-08-07 13:00 UTC (permalink / raw)
To: git
It doesn't seem to cause any other problems, but I don't know if it is
significant or not.
[Fri Aug 7 08:51:13 2009] gitweb.cgi: Variable "$project_maxdepth"
may be unavailable at /var/www/private/gitweb/cgi-bin/gitweb.cgi line
2296.
[Fri Aug 7 08:51:13 2009] gitweb.cgi: Variable "$projectroot" may be
unavailable at /var/www/private/gitweb/cgi-bin/gitweb.cgi line 2304.
Apache 2.2.12/ mod_perl 2.04/ perl 5.8.8
--
Mark A Rada (ferrous26)
marada@uwaterloo.ca
^ permalink raw reply
* Re: [PATCH 1/5] revision caching documentation: man page and technical discussion
From: Johannes Schindelin @ 2009-08-07 12:20 UTC (permalink / raw)
To: Rogan Dawes
Cc: Sam Vilain, Nick Edelen, Junio C Hamano, Jeff King,
Shawn O. Pearce, Andreas Ericsson, Christian Couder,
git@vger.kernel.org
In-Reply-To: <4A7C18F2.2000905@dawes.za.net>
Hi,
On Fri, 7 Aug 2009, Rogan Dawes wrote:
> Sam Vilain wrote:
>
> >> +`fuse`::
> >> + Coagulate several cache slices into a single large slice.
> >>
> >
> > Coagulate? You mean, the revision caches will stop being liquid and go
> > gluggy, like a pool of blood clotting?
> >
> > How about "combine" :-) - and the option might be better called
> > something simple like that, too.
>
> I think the word he had in mind was "coalesce".
As Git users typically have a quite good idea what a "merge" is, I'd
prefer that word anyway.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 1/5] revision caching documentation: man page and technical discussion
From: Rogan Dawes @ 2009-08-07 12:07 UTC (permalink / raw)
To: Sam Vilain
Cc: Nick Edelen, Junio C Hamano, Johannes Schindelin, Jeff King,
Shawn O. Pearce, Andreas Ericsson, Christian Couder,
git@vger.kernel.org
In-Reply-To: <4A7B9ACA.1060601@vilain.net>
Sam Vilain wrote:
>> +`fuse`::
>> + Coagulate several cache slices into a single large slice.
>>
>
> Coagulate? You mean, the revision caches will stop being liquid and go
> gluggy, like a pool of blood clotting?
>
> How about "combine" :-) - and the option might be better called
> something simple like that, too.
I think the word he had in mind was "coalesce".
Rogan
^ permalink raw reply
* [PATCH] Add 'stg prev' and 'stg next'
From: Hannes Eder @ 2009-08-07 10:45 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
These commands are related to 'stg top'. They print the patch below
resp. above the topmost patch, given that they exist.
Signed-off-by: Hannes Eder <heder@google.com>
---
Ok, I confess it's not kill feature, but Mercurial has these commands
and I use them from time to time. Maybe somebody else finds it useful
as well, so I decided to share it. ;)
Cheers,
Hannes
stgit/commands/next.py | 48 ++++++++++++++++++++++++++++++++++++++++++++++++
stgit/commands/prev.py | 48 ++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 96 insertions(+), 0 deletions(-)
create mode 100644 stgit/commands/next.py
create mode 100644 stgit/commands/prev.py
diff --git a/stgit/commands/next.py b/stgit/commands/next.py
new file mode 100644
index 0000000..c8e2599
--- /dev/null
+++ b/stgit/commands/next.py
@@ -0,0 +1,48 @@
+__copyright__ = """
+Copyright (C) 2005, Catalin Marinas <catalin.marinas@gmail.com>
+
+This program is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License version 2 as
+published by the Free Software Foundation.
+
+This program is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with this program; if not, write to the Free Software
+Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+"""
+
+from stgit.argparse import opt
+from stgit.commands import common
+from stgit.out import out
+from stgit import argparse
+
+help = 'Print the name of the next patch'
+kind = 'stack'
+usage = ['']
+description = """
+Print the name of the next patch."""
+
+args = []
+options = [
+ opt('-b', '--branch', args = [argparse.stg_branches],
+ short = 'Use BRANCH instead of the default branch')]
+
+directory = common.DirectoryHasRepositoryLib()
+
+def func(parser, options, args):
+ """Show the name of the next patch
+ """
+ if len(args) != 0:
+ parser.error('incorrect number of arguments')
+
+ stack = directory.repository.get_stack(options.branch)
+ unapplied = stack.patchorder.unapplied
+
+ if unapplied:
+ out.stdout(unapplied[0])
+ else:
+ raise common.CmdException, 'No unapplied patches'
diff --git a/stgit/commands/prev.py b/stgit/commands/prev.py
new file mode 100644
index 0000000..79f97a8
--- /dev/null
+++ b/stgit/commands/prev.py
@@ -0,0 +1,48 @@
+__copyright__ = """
+Copyright (C) 2005, Catalin Marinas <catalin.marinas@gmail.com>
+
+This program is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License version 2 as
+published by the Free Software Foundation.
+
+This program is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with this program; if not, write to the Free Software
+Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+"""
+
+from stgit.argparse import opt
+from stgit.commands import common
+from stgit.out import out
+from stgit import argparse
+
+help = 'Print the name of the previous patch'
+kind = 'stack'
+usage = ['']
+description = """
+Print the name of the previous patch."""
+
+args = []
+options = [
+ opt('-b', '--branch', args = [argparse.stg_branches],
+ short = 'Use BRANCH instead of the default branch')]
+
+directory = common.DirectoryHasRepositoryLib()
+
+def func(parser, options, args):
+ """Show the name of the previous patch
+ """
+ if len(args) != 0:
+ parser.error('incorrect number of arguments')
+
+ stack = directory.repository.get_stack(options.branch)
+ applied = stack.patchorder.applied
+
+ if applied and len(applied) >= 2:
+ out.stdout(applied[-2])
+ else:
+ raise common.CmdException, 'Not enough applied patches'
^ permalink raw reply related
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