pandora smycken rea
Med olika pärlor och smycken åtkomliga från Pandora smycken , pandora berlocker rea http://www.jewelleryshoponlineswindon.com/pandora i am säker på göra en armband som endast vi kanske har och inget en annars motivet bara för detta är att Pandora gör och sätta upp dessa pärlor och berlocker till salu att se vi kan köpa på din egen det innebär att konturerna och sammanslagning av pärlor beror helt till vår smak och val Vi kan placera dem tillsammans med oss själva om vi gillar tillsammans med pärlor att folk välja och gå med skulle kunna utgöra perfekt stil och design som endast vi kanske ha Detta är faktiskt bestäms av vår . smak och preferenser Det är inte mycket vanlig i någon smycken affärer för att generera en skapelse som tillåter kunder och köpare frihet i crafting och skapar en design som kunderna gör sig här möjligen skulle vara . orsaken till varför Pandora Armband har vuxit till att bli småningom känd ett av flera kvinnor . Pärlorna att folk kunde köpa är erhållas i en rad former, pandora smycken http://www.jewelleryshoponlineswindon.com/pandora färger och storlekar Du kan easliy få pärlor och ädelstenar skapas från värdefulla metaller som guld och silver , stilrena men dyra glasögon , och i många fall semi dyrbara stenar dessa pärlor har ett varierat utbud av mönster som skulle utbudet till flera marknadsplatser Kvinnor har . olika typer av intressen kommer säkert upptäcka något baserad på sin egen val temana som råkar vara erhållas har en stor sort från blommor mot stjärnteckenplus i siffror och göra charm mer personlig, hittar bokstäver erbjuds också, så du kan easliy tänka på en utformning med olika ord eller namn som endast Vi kan ha . med en av dessa fantastiska pärlor och charmsFree innehåll , den som kommer att bära smycken garanteras på en exklusiva och unika objekt . Vilket betyder detta gör Pandora Armband en utmärkt present individualitet i smycken är sannolikt att göra någon dam känner sig extra när att hon kommer få här sortens gåva. Pandora en pandora ringar http://www.jewelleryshoponlineswindon.com/pandora/pandora-ringar varumärke och det är berömd allt grund av den underbara smycken och kvalitet material som används i tillverkning av denna fascinerande smycken det är anledningen . varför Pandora är ett av många tre bästa smycken varumärken i världen den bästa idén del av världen just nu Pandora är känd för sin anpassning och unika använda mönster de levererar på sin kund i hela världen därför är folk som någonsin ställe vart går alltid fråga om Pandora smycken i butik som korrektur deras höga anseende innanför offentliga Pandora Armband och Charms är attraktiva . och trendig vilket får dem att vara mer önskvärt . Pandora Armband och Charms ändra över till vara den idealiska gåva distribueras av du Pandora armband muddar kan vara köpts in guld , silver och vanlig tunn tråd det är inte att berömd även silver innanför bästa matchen eftersom det samlokalisera med . varje charm och öka deras betydelse Readymade Armband erbjuds också på marknaden pandoras ask http://www.jewelleryshoponlineswindon.com/pandora/pandoras-paket-ask för komfort kunderna kan använda och om du är lite kreativ och dessutom ha stor fantasi och önskar göra din egen personliga designen då Pandora ger göra det möjligt för dig att göra det som du som om din fantasi blir det enda begränsningen med det här Pandora armband och berlocker ger sina potentiella kunder mycket val. -- View this message in context: http://git.661346.n2.nabble.com/pandora-smycken-rea-tp7600297.html Sent from the git mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mv: let 'git mv file no-such-dir/' error out
Duy Nguyen pclo...@gmail.com writes: On Tue, Dec 3, 2013 at 3:32 PM, Matthieu Moy matthieu@imag.fr wrote: Git used to trim the trailing slash, and make the command equivalent to 'git mv file no-such-dir', which created the file no-such-dir (while the trailing slash explicitly stated that it could only be a directory). This patch skips the trailing slash removal for the destination path. The path with its trailing slash is passed to rename(2), which errors out with the appropriate message: $ git mv file no-such-dir/ fatal: renaming 'file' failed: Not a directory There's something we probably should check. In d78b0f3 ([PATCH] git-mv: add more path normalization - 2006-08-16), it mentions about git mv something/ somewhere/ there's no test in that commit so I don't know the actual input and expected outcome. To me, the expected outcome is behave like Unix's mv (which works with or without the trailing slash if somewhere exists). If somewhere is a directory, it errors out with this patch and works without it. I can't reproduce. I've added this to my patch (indeed, the area wasn't well tested), and the tests pass. diff --git a/t/t7001-mv.sh b/t/t7001-mv.sh index e5c8084..3bfdfed 100755 --- a/t/t7001-mv.sh +++ b/t/t7001-mv.sh @@ -70,12 +70,31 @@ test_expect_success \ rm -f idontexist untracked1 untracked2 \ path0/idontexist path0/untracked1 path0/untracked2 \ .git/index.lock +rmdir path1 test_expect_success \ -'moving to target with trailing slash' \ +'moving to absent target with trailing slash' \ 'test_must_fail git mv path0/COPYING no-such-dir/ test_must_fail git mv path0/COPYING no-such-dir// - git mv path0/ no-such-dir/' + git mv path0/ no-such-dir/ + test_path_is_dir no-such-dir' + +test_expect_success \ +'clean up' \ +'git reset --hard' + +test_expect_success \ +'moving to existing untracked target with trailing slash' \ +'mkdir path1 + git mv path0/ path1/ + test_path_is_dir path1/path0/' + +test_expect_success \ +'moving to existing tracked target with trailing slash' \ +'mkdir path2 + path2/file git add path2/file + git mv path1/path0/ path2/ + test_path_is_dir path2/path0/' test_expect_success \ 'clean up' \ -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Business
Dear friend, Good day! This is an investment proposal for you on behalf of Capt. Addanki Gopinath (RTD). He wants you to be his foreign partner, investments and funds manager to invest his funds USD68million into Real Estate or any other lucrative business in your country. If you are interested reply me an email as soon as possible for more details. Yours Truly, Mr. Anthoni Choi -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: gitk refresh keeps showing dangling commits
On Fri, Nov 29, 2013 at 4:27 PM, Thibault Kruse tibokr...@googlemail.com wrote: and in gitk, I select Reload(Ctrl-F5), and I still see both commits, not just commit foo. Do you use the menu entry Reload, or the keyboard shortcut Ctrl+F5? The shortcut was changed a while ago to Shift+F5. http://git.661346.n2.nabble.com/PATCH-gitk-avoid-Meta1-F5-td7444531.html -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Command-line git Vs IDE+plugin?
On Tue, Nov 19, 2013 at 6:20 PM, Matthieu Moy matthieu@grenoble-inp.fr wrote: One thing the command-line does well is to give names to concepts (basically, command names, option names, ...). It's easy to write in a tutorial or an email run the command 'git foo'. It's less easy to write click on that red button, on the right of the green one. And it is also easier for many to press a button than writing a command. This is a bad thing, in my experience. In a GUI, people tend to take chances: Oh, reset, that sounds like what I want. What, it did not work? Oh there is this option 'hard', let's tick it and see what happens. Another thing GUIs do not (often) offer is history. I would be lost if I couldn't see what I was trying to do 5 commands ago (before someone interrupted me), or refer to a previous error message. But if you cannot touch-type, buttons are going to be more attractive. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH jk/remove-deprecated] stop installing git-tar-tree link
Jonathan Nieder venit, vidit, dixit 03.12.2013 00:37:
When the built-in git tar-tree command (a thin wrapper around git
archive) was removed in 925ceccf (tar-tree: remove deprecated
command, 2013-11-10), the build continued to install a non-functioning
git-tar-tree command in gitexecdir by mistake:
$ PATH=$(git --exec-path):$PATH
$ git-tar-tree -h
fatal: cannot handle tar-tree internally
The list of links in gitexecdir is populated from BUILTIN_OBJS, which
includes builtin/tar-tree.o to implement git get-tar-commit-id.
... which still resides in builtin/tar-tree.c
Had me scratch my head quite a bit as is ;)
Rename the get-tar-commit-id source file to builtin/get-tar-commit-id.c
to reflect its purpose and fix 'make install'.
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
Hi,
John Keeping wrote:
builtin/tar-tree.c | 62 -
Here's a quick fixup on top. Thoughts?
Thanks,
Jonathan
Makefile| 3 +--
builtin/{tar-tree.c = get-tar-commit-id.c} | 0
2 files changed, 1 insertion(+), 2 deletions(-)
rename builtin/{tar-tree.c = get-tar-commit-id.c} (100%)
diff --git a/Makefile b/Makefile
index 504931f..37beb73 100644
--- a/Makefile
+++ b/Makefile
@@ -586,7 +586,6 @@ BUILT_INS += git-cherry$X
BUILT_INS += git-cherry-pick$X
BUILT_INS += git-format-patch$X
BUILT_INS += git-fsck-objects$X
-BUILT_INS += git-get-tar-commit-id$X
BUILT_INS += git-init$X
BUILT_INS += git-merge-subtree$X
BUILT_INS += git-show$X
@@ -929,6 +928,7 @@ BUILTIN_OBJS += builtin/fmt-merge-msg.o
BUILTIN_OBJS += builtin/for-each-ref.o
BUILTIN_OBJS += builtin/fsck.o
BUILTIN_OBJS += builtin/gc.o
+BUILTIN_OBJS += builtin/get-tar-commit-id.o
BUILTIN_OBJS += builtin/grep.o
BUILTIN_OBJS += builtin/hash-object.o
BUILTIN_OBJS += builtin/help.o
@@ -980,7 +980,6 @@ BUILTIN_OBJS += builtin/show-ref.o
BUILTIN_OBJS += builtin/stripspace.o
BUILTIN_OBJS += builtin/symbolic-ref.o
BUILTIN_OBJS += builtin/tag.o
-BUILTIN_OBJS += builtin/tar-tree.o
BUILTIN_OBJS += builtin/unpack-file.o
BUILTIN_OBJS += builtin/unpack-objects.o
BUILTIN_OBJS += builtin/update-index.o
diff --git a/builtin/tar-tree.c b/builtin/get-tar-commit-id.c
similarity index 100%
rename from builtin/tar-tree.c
rename to builtin/get-tar-commit-id.c
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Use mongoose to test smart-http unconditionally?
I was thinking of an alternative to apache for testing smart-http so that most of http tests could always run. Mongoose [1] looks like a good candidate to bundle with git. Just one pair of source files, mongoose.[ch], a mainloop wrapper and we have an http server. Just wondering, do we rely on any apache-specific features? I'm not so familiar with lib-httpd.sh.. [1] https://github.com/cesanta/mongoose -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Command-line git Vs IDE+plugin?
On 19/11/13 06:11, Matthieu Moy wrote: I was wondering whether others had similar (or not) experience. In particular, as a teacher, I'm wondering whether I should push my students towards the GUI in the IDE, or advise them to keep using the command-line (we teach them git with the command-line first anyway, but after a year of practice, we may want to show them the GUI equivalent). My $0.02 as someone who performs some part-time SCM admin tasks for a moderately sized group of engineers (~40) with varying degrees of experience. Some people are scared by a command line and think poking buttons in an IDE is preferable (and somehow safer). As others have pointed out the first sign of trouble they shuffle over to my desk. I see the people that are comfortable with the command line far less frequently. I think learning the command line first does help with peoples overall understanding. Once they have some working knowledge of the basics introducing some of the tools that integrate with those building blocks is much easier. In some respects the gui/IDE is better for some tasks. For example I don't even bother telling people about 'git add -p' because 'git gui' provides the same functionality with an interface that is better suited to picking chunks/lines of code to stage. Another example is Eclipse's annotations which provides the same information as 'git blame' but it is right there with the code I'm editing. Specifically about Eclipse; I've personally found that in the days of Ganymede/Helios the VCS integration built around SVN and the mapping of SVN concepts to Git was imperfect (impossible?). With Juno/Indigo the support for DVCSes in general and for Git specifically is greatly improved but I still rarely use Eclipse to actually make commits. - C -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: slow git-cherry-pick.
On Wednesday 04 of December 2013 08:07:23 Duy Nguyen wrote:
On Wed, Dec 4, 2013 at 3:13 AM, Thomas Rast t...@thomasrast.ch wrote:
Paweł Sikora pawel.sik...@agmk.net writes:
Umm, there's a gem here that the thread missed so far:
my git repo isn't very big[1] but it's checked out on the linear lvm
where random i/o generally hurts and strace shows that current git
version
performs 2x{lstat}+1x{open,read,close} [2] on whole checkout before
^
There's no reason why it should do the lstat() *twice* for every file.
But Paweł is right; the code path roughly goes like this:
int cmd_cherry_pick(int argc, const char **argv, const char *prefix)
{
[...]
res = sequencer_pick_revisions(opts);
int sequencer_pick_revisions(struct replay_opts *opts)
{
[...]
read_and_refresh_cache(opts);
[...]
return pick_commits(todo_list, opts);
}
static int pick_commits(struct commit_list *todo_list, struct replay_opts
*opts) {
[...]
read_and_refresh_cache(opts);
I'm too tired to dig further, but AFAICT it's just a rather obvious case
of duplication of effort.
That's something to optimize, but it's single commit picking,
sequencer_pick_revisions() should call single_pick() instead of
pick_commits().
The read+close on the whole checkout looks like there's problem with
refresh operation and git decides to read up and verify sha-1 by
content. Pawel, if you run strace git update-index --refresh twice,
does it still show 1 stat + 1 read for every entry on the second try?
the 'git update-index --refresh' runs quickly and strace shows only lstat()
on every file. i see no massive open/read actions in this case.
$ strace -o strace-try1.log git update-index --refresh
hmdb: needs update
$ strace -o strace-try2.log git update-index --refresh
hmdb: needs update
$ grep -c lstat strace-try1.log
33793
$ grep -c lstat strace-try2.log
33793
--
gpg key fingerprint = 60B4 9886 AD53 EB3E 88BB 1EB5 C52E D01B 683B 9411
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mv: let 'git mv file no-such-dir/' error out
On Wed, Dec 4, 2013 at 3:44 PM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Duy Nguyen pclo...@gmail.com writes: On Tue, Dec 3, 2013 at 3:32 PM, Matthieu Moy matthieu@imag.fr wrote: There's something we probably should check. In d78b0f3 ([PATCH] git-mv: add more path normalization - 2006-08-16), it mentions about git mv something/ somewhere/ there's no test in that commit so I don't know the actual input and expected outcome. To me, the expected outcome is behave like Unix's mv (which works with or without the trailing slash if somewhere exists). If somewhere is a directory, it errors out with this patch and works without it. I can't reproduce. I've added this to my patch (indeed, the area wasn't well tested), and the tests pass. Now I can't either. Probably some mis-setups or some local bugs in my tree. Good that we have more tests. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] gitweb: Add a comment explaining the meaning of $/
So future reader will know what does it mean without running perldoc
perlvar.
Signed-off-by: Krzesimir Nowak krzesi...@endocode.com
---
gitweb/gitweb.perl | 2 ++
1 file changed, 2 insertions(+)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 68c77f6..ee61f9e 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2629,6 +2629,8 @@ sub git_parse_project_config {
my $section_regexp = shift;
my %config;
+ # input record separator, so getline does end on null, not
+ # newline
local $/ = \0;
open my $fh, -|, git_cmd(), config, '-z', '-l',
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/5] gitweb: Add a feature for adding more branch refs
Allow extra-branch-refs feature to tell gitweb to show refs from
additional hierarchies in addition to branches in the list-of-branches
view.
Signed-off-by: Krzesimir Nowak krzesi...@endocode.com
Reviewed-by: Junio C Hamano gits...@pobox.com
Reviewed-by: Jakub Narębski jna...@gmail.com
---
Documentation/gitweb.conf.txt | 37 +++
gitweb/gitweb.perl| 85 +--
2 files changed, 110 insertions(+), 12 deletions(-)
diff --git a/Documentation/gitweb.conf.txt b/Documentation/gitweb.conf.txt
index e2113d9..5a77452 100644
--- a/Documentation/gitweb.conf.txt
+++ b/Documentation/gitweb.conf.txt
@@ -849,6 +849,43 @@ time zones in the form of +/-HHMM, such as +0200.
+
Project specific override is not supported.
+extra-branch-refs::
+ List of additional directories under refs which are going to
+ be used as branch refs. For example if you have a gerrit setup
+ where all branches under refs/heads/ are official,
+ push-after-review ones and branches under refs/sandbox/,
+ refs/wip and refs/other are user ones where permissions are
+ much wider, then you might want to set this variable as
+ follows:
++
+
+$feature{'extra-branch-refs'}{'default'} =
+ ['sandbox', 'wip', 'other'];
+
++
+If overriding was enabled then this feature can be configured on a
+per-repository basis via repository's `gitweb.extrabranchrefs`
+configuration variable, which contains a space separated list of
+refs. An example:
++
+
+[gitweb]
+ extrabranchrefs = sandbox wip other
+
++
+The gitweb.extrabranchrefs is actually a multi-valued configuration
+variable, so following example is also correct and the result is the
+same as of the snippet above:
++
+
+[gitweb]
+ extrabranchrefs = sandbox
+ extrabranchrefs = wip other
+
++
+It is an error to specify a ref that does not pass git check-ref-format
+scrutiny. Duplicated values are filtered.
+
EXAMPLES
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 3434602..6d3d52d 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -548,6 +548,20 @@ our %feature = (
'sub' = sub { feature_bool('remote_heads', @_) },
'override' = 0,
'default' = [0]},
+
+ # Enable showing branches under other refs in addition to heads
+
+ # To set system wide extra branch refs have in $GITWEB_CONFIG
+ # $feature{'extra-branch-refs'}{'default'} = ['dirs', 'of', 'choice'];
+ # To have project specific config enable override in $GITWEB_CONFIG
+ # $feature{'extra-branch-refs'}{'override'} = 1;
+ # and in project config gitweb.extrabranchrefs = dirs of choice
+ # Every directory is separated with whitespace.
+
+ 'extra-branch-refs' = {
+ 'sub' = \feature_extra_branch_refs,
+ 'override' = 0,
+ 'default' = []},
);
sub gitweb_get_feature {
@@ -626,6 +640,26 @@ sub feature_avatar {
return @val ? @val : @_;
}
+sub feature_extra_branch_refs {
+ my (@branch_refs) = @_;
+ my $values = git_get_project_config('extrabranchrefs');
+
+ if ($values) {
+ unless (ref $values) {
+ $values = [$values];
+ }
+ unless (ref $values eq 'ARRAY') {
+ return @branch_refs;
+ }
+ @branch_refs = ();
+ foreach my $value (@{$values}) {
+ push @branch_refs, split /\s+/, $value;
+ }
+ }
+
+ return @branch_refs;
+}
+
# checking HEAD file with -e is fragile if the repository was
# initialized long time ago (i.e. symlink HEAD) and was pack-ref'ed
# and then pruned.
@@ -656,6 +690,18 @@ sub filter_snapshot_fmts {
!$known_snapshot_formats{$_}{'disabled'}} @fmts;
}
+sub filter_and_validate_refs {
+ my @refs = @_;
+ my %unique_refs = ();
+
+ foreach my $ref (@refs) {
+ die_error(500, Invalid ref '$ref' in 'extra-branch-refs'
feature) unless (check_ref_format($ref));
+ # 'heads' are added implicitly in get_branch_refs().
+ $unique_refs{$ref} = 1 if ($ref ne 'heads');
+ }
+ return sort keys %unique_refs;
+}
+
# If it is set to code reference, it is code that it is to be run once per
# request, allowing updating configurations that change with each request,
# while running other code in config file only once.
@@
[PATCH 3/5] gitweb: Return plain booleans in validation methods
Users of validate_* passing 0 might get failures on correct name
because of coercion of 0 to false in code like:
die_error(500, invalid ref) unless (check_ref_format (0));
Signed-off-by: Krzesimir Nowak krzesi...@endocode.com
---
gitweb/gitweb.perl | 45 +
1 file changed, 25 insertions(+), 20 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 67415b9..3434602 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1419,63 +1419,68 @@ sub href {
## validation, quoting/unquoting and escaping
sub validate_action {
- my $input = shift || return undef;
- return undef unless exists $actions{$input};
- return $input;
+ my $input = shift;
+
+ return 0 unless defined $input;
+ return 0 unless exists $actions{$input};
+ return 1;
}
sub validate_project {
- my $input = shift || return undef;
+ my $input = shift;
+
+ return 0 unless defined $input;
if (!validate_pathname($input) ||
!(-d $projectroot/$input) ||
!check_export_ok($projectroot/$input) ||
($strict_export !project_in_list($input))) {
- return undef;
+ return 0;
} else {
- return $input;
+ return 1;
}
}
sub validate_pathname {
- my $input = shift || return undef;
+ my $input = shift;
+ return 0 unless defined $input;
# no '.' or '..' as elements of path, i.e. no '.' nor '..'
# at the beginning, at the end, and between slashes.
# also this catches doubled slashes
if ($input =~ m!(^|/)(|\.|\.\.)(/|$)!) {
- return undef;
+ return 0;
}
# no null characters
if ($input =~ m!\0!) {
- return undef;
+ return 0;
}
- return $input;
+ return 1;
}
sub check_ref_format {
- my $input = shift || return undef;
+ my $input = shift;
+ return 0 unless defined $input;
# restrictions on ref name according to git-check-ref-format
if ($input =~ m!(/\.|\.\.|[\000-\040\177 ~^:?*\[]|/$)!) {
- return undef;
+ return 0;
}
- return $input;
+ return 1;
}
sub validate_refname {
- my $input = shift || return undef;
+ my $input = shift;
+ return undef unless defined $input;
# textual hashes are O.K.
if ($input =~ m/^[0-9a-fA-F]{40}$/) {
- return $input;
+ return 1;
}
# it must be correct pathname
- $input = validate_pathname($input)
- or return undef;
+ validate_pathname($input) or return 0;
# check git-check-ref-format restrictions
- check_ref_format($input)
- or return undef;
- return $input;
+ check_ref_format($input) or return 0;
+ return 1;
}
# decode sequences of octets in utf8 into Perl's internal form,
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] Show extra branch refs in gitweb
On Tue, 2013-12-03 at 15:56 +0100, Krzesimir Nowak wrote: First patch just splits some code to a function, second patch adds the extra-branch-refs feature and third one adds some visual differentation of branches from non-standard ref directories. Krzesimir Nowak (3): gitweb: Move check-ref-format code into separate function gitweb: Add a feature for adding more branch refs gitweb: Denote non-heads, non-remotes branches. Documentation/gitweb.conf.txt | 27 ++ gitweb/gitweb.perl| 120 +++--- 2 files changed, 129 insertions(+), 18 deletions(-) New version of patches are in Show extra branch refs in gitweb v6 thread. Cheers, -- Krzesimir Nowak Software Developer Endocode AG krzesi...@endocode.com -- Endocode AG, Johannisstraße 20, 10117 Berlin i...@endocode.com | www.endocode.com Vorstandsvorsitzender: Mirko Boehm Vorstände: Dr. Karl Beecher, Chris Kühl, Sebastian Sucker Aufsichtsratsvorsitzende: Jennifer Beecher Registergericht: Amtsgericht Charlottenburg - HRB 150748 B -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] gitweb: Add a comment explaining the meaning of $/
On Wed, 2013-12-04 at 16:11 +0100, Jakub Narębski wrote:
On Wed, Dec 4, 2013 at 2:42 PM, Krzesimir Nowak krzesi...@endocode.com
wrote:
So future reader will know what does it mean without running perldoc
perlvar.
Hmmm... shouldn't future reader know it anyway? It is not that cryptic.
I'd say it is idiomatic Perl.
It's plainly obscure. And I think it is not that often used - I keep
forgetting what that pair of punctuation is actually meaning. In this
case I guess it would be more readable to use the following code
instead:
$fh-input_record_separator (\0);
Besides, it is not the only place where we set input record separator to NUL,
to match corresponding option to git command to separate records with NUL
(the '-z' option in this case). Others are git_get_path_by_hash(),
parse_commit(),
and parse_commits(), git_tree(), not including places where we set $/ to undef
to slurp whole file: git_get_link_target(), git_blobdiff() for $format
== 'plain', etc.
Yes, but I stumbled upon that one when trying to understand how config
parsing works. So I added a comment.
Signed-off-by: Krzesimir Nowak krzesi...@endocode.com
---
gitweb/gitweb.perl | 2 ++
1 file changed, 2 insertions(+)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 68c77f6..ee61f9e 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2629,6 +2629,8 @@ sub git_parse_project_config {
my $section_regexp = shift;
my %config;
+ # input record separator, so getline does end on null, not
+ # newline
local $/ = \0;
It is here because of '-z' option below (to account for values with
embedded newlines).
open my $fh, -|, git_cmd(), config, '-z', '-l',
--
1.8.3.1
--
Krzesimir Nowak
Software Developer
Endocode AG
krzesi...@endocode.com
--
Endocode AG, Johannisstraße 20, 10117 Berlin
i...@endocode.com | www.endocode.com
Vorstandsvorsitzender: Mirko Boehm
Vorstände: Dr. Karl Beecher, Chris Kühl, Sebastian Sucker
Aufsichtsratsvorsitzende: Jennifer Beecher
Registergericht: Amtsgericht Charlottenburg - HRB 150748 B
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] gitweb: Move check-ref-format code into separate function
On Wed, Dec 4, 2013 at 2:43 PM, Krzesimir Nowak krzesi...@endocode.com wrote:
This check will be used in more than one place later.
Signed-off-by: Krzesimir Nowak krzesi...@endocode.com
Reviewed-by: Junio C Hamano gits...@pobox.com
Reviewed-by: Jakub Narębski jna...@gmail.com
All right, that is nice refactoring.
---
gitweb/gitweb.perl | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index ee61f9e..67415b9 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1452,6 +1452,16 @@ sub validate_pathname {
return $input;
}
+sub check_ref_format {
+ my $input = shift || return undef;
+
+ # restrictions on ref name according to git-check-ref-format
+ if ($input =~ m!(/\.|\.\.|[\000-\040\177 ~^:?*\[]|/$)!) {
+ return undef;
+ }
+ return $input;
+}
+
sub validate_refname {
my $input = shift || return undef;
@@ -1462,10 +1472,9 @@ sub validate_refname {
# it must be correct pathname
$input = validate_pathname($input)
or return undef;
- # restrictions on ref name according to git-check-ref-format
- if ($input =~ m!(/\.|\.\.|[\000-\040\177 ~^:?*\[]|/$)!) {
- return undef;
- }
+ # check git-check-ref-format restrictions
+ check_ref_format($input)
+ or return undef;
return $input;
}
Right, check_ref_format() has name after git-check-ref-format...
though... check_ref_format() or die doesn't read completely
naturally...
--
Jakub Narebski
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
problems with git --git-dir on windows 7
Hello, We are using git on windows7(git-version 1.8.1; see below) and we get the following problem in using the command 'git --git-dir=' C:\UserTemp\git\appli3git --git-dir=C:\UserTemp\git\appli3 tag fatal: Not a git repository: 'C:\UserTemp\git\appli3' but the repository is well defined,as we can run the following command: C:\UserTemp\git\appli3git log -1 --oneline 37cdbe0 Merge branch 'master' of L:/_ApplicationData/FBLU_IT-FLIT/se-DevelopSupp When running the equivalent command on Linux, we don't have any problems: On Linux: git --git-dir=/tmp/GITPOC/appli3 tag V1.0 V1.1 V2.0 V3.0 Could you help me please ? Best regards Manfred Schilz --- C:\UserTemp\git\appli3git --version git version 1.8.1.msysgit.1 Internet communications are not secure and therefore BGL BNP Paribas does not accept legal responsibility for the contents of this message. The information contained in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Nothing in the message is capable or intended to create any legally binding obligations on either party and it is not intended to provide legal advice. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 02/11] remote.c: add infrastructure for parsing --prune options
On 12/04/2013 01:57 PM, Duy Nguyen wrote:
On Wed, Dec 4, 2013 at 12:44 PM, Michael Haggerty mhag...@alum.mit.edu
wrote:
+void argv_push_prune_option(struct argv_array *argv,
+ struct prune_option *prune_option)
+{
+ if (prune_option-prune != -1)
+ argv_array_pushf(argv,
+prune_option-prune
+? --prune
+: --no-prune);
+}
Nit. I think argv_array_push() is enough for this case?
Yes, you're right. Thanks for noticing.
If people want this patch series I will fix the problem in the next round.
Michael
--
Michael Haggerty
mhag...@alum.mit.edu
http://softwareswirl.blogspot.com/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] gitweb: Add a comment explaining the meaning of $/
On Wed, Dec 4, 2013 at 4:46 PM, Krzesimir Nowak krzesi...@endocode.com wrote: On Wed, 2013-12-04 at 16:11 +0100, Jakub Narębski wrote: On Wed, Dec 4, 2013 at 2:42 PM, Krzesimir Nowak krzesi...@endocode.com wrote: So future reader will know what does it mean without running perldoc perlvar. Hmmm... shouldn't future reader know it anyway? It is not that cryptic. I'd say it is idiomatic Perl. It's plainly obscure. And I think it is not that often used - I keep forgetting what that pair of punctuation is actually meaning. I think it depends on what kind of Perl code one is used to. It is not as obscure as $; and similar to $|, I think. In this case I guess it would be more readable to use the following code instead: $fh-input_record_separator (\0); That would be a good change to replace local $/ = \0; open my $fh, -|, git_cmd(), ..., '-z', ... with open my $fh, -|, git_cmd(), ..., '-z', ... $fh-input_record_separator (\0); (not forgetting about use IO::Handle, which module is core Perl module); Anyway, this change (or proposed change) does not, IMHO, belong in this series. -- Jakub Narebski -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] mv: let 'git mv file no-such-dir/' error out
Git used to trim the trailing slash, and make the command equivalent to
'git mv file no-such-dir', which created the file no-such-dir (while the
trailing slash explicitly stated that it could only be a directory).
This patch skips the trailing slash removal for the destination path. The
path with its trailing slash is passed to rename(2), which errors out
with the appropriate message:
$ git mv file no-such-dir/
fatal: renaming 'file' failed: Not a directory
Original-patch-by: Duy Nguyen pclo...@gmail.com
Tests, tweaks and commit message by: Matthieu Moy matthieu@imag.fr
Signed-off-by: Matthieu Moy matthieu@imag.fr
---
So, this patch adds more tests, as suggested by Duy. They all pass
without modifying the code.
builtin/mv.c | 23 ---
t/t7001-mv.sh | 29 +
2 files changed, 45 insertions(+), 7 deletions(-)
diff --git a/builtin/mv.c b/builtin/mv.c
index 2e0e61b..08fbc03 100644
--- a/builtin/mv.c
+++ b/builtin/mv.c
@@ -16,9 +16,12 @@ static const char * const builtin_mv_usage[] = {
NULL
};
+#define DUP_BASENAME 1
+#define KEEP_TRAILING_SLASH 2
+
static const char **internal_copy_pathspec(const char *prefix,
const char **pathspec,
- int count, int base_name)
+ int count, unsigned flags)
{
int i;
const char **result = xmalloc((count + 1) * sizeof(const char *));
@@ -27,11 +30,12 @@ static const char **internal_copy_pathspec(const char
*prefix,
for (i = 0; i count; i++) {
int length = strlen(result[i]);
int to_copy = length;
- while (to_copy 0 is_dir_sep(result[i][to_copy - 1]))
+ while (!(flags KEEP_TRAILING_SLASH)
+ to_copy 0 is_dir_sep(result[i][to_copy - 1]))
to_copy--;
- if (to_copy != length || base_name) {
+ if (to_copy != length || flags DUP_BASENAME) {
char *it = xmemdupz(result[i], to_copy);
- if (base_name) {
+ if (flags DUP_BASENAME) {
result[i] = xstrdup(basename(it));
free(it);
} else
@@ -87,16 +91,21 @@ int cmd_mv(int argc, const char **argv, const char *prefix)
source = internal_copy_pathspec(prefix, argv, argc, 0);
modes = xcalloc(argc, sizeof(enum update_mode));
- dest_path = internal_copy_pathspec(prefix, argv + argc, 1, 0);
+ /*
+* Keep trailing slash, needed to let
+* git mv file no-such-dir/ error out.
+*/
+ dest_path = internal_copy_pathspec(prefix, argv + argc, 1,
+ KEEP_TRAILING_SLASH);
submodule_gitfile = xcalloc(argc, sizeof(char *));
if (dest_path[0][0] == '\0')
/* special case: . was normalized to */
- destination = internal_copy_pathspec(dest_path[0], argv, argc,
1);
+ destination = internal_copy_pathspec(dest_path[0], argv, argc,
DUP_BASENAME);
else if (!lstat(dest_path[0], st)
S_ISDIR(st.st_mode)) {
dest_path[0] = add_slash(dest_path[0]);
- destination = internal_copy_pathspec(dest_path[0], argv, argc,
1);
+ destination = internal_copy_pathspec(dest_path[0], argv, argc,
DUP_BASENAME);
} else {
if (argc != 1)
die(destination '%s' is not a directory,
dest_path[0]);
diff --git a/t/t7001-mv.sh b/t/t7001-mv.sh
index b90e985..2f82478 100755
--- a/t/t7001-mv.sh
+++ b/t/t7001-mv.sh
@@ -70,6 +70,35 @@ test_expect_success \
rm -f idontexist untracked1 untracked2 \
path0/idontexist path0/untracked1 path0/untracked2 \
.git/index.lock
+rmdir path1
+
+test_expect_success \
+'moving to absent target with trailing slash' \
+'test_must_fail git mv path0/COPYING no-such-dir/
+ test_must_fail git mv path0/COPYING no-such-dir//
+ git mv path0/ no-such-dir/
+ test_path_is_dir no-such-dir/'
+
+test_expect_success \
+'clean up' \
+'git reset --hard'
+
+test_expect_success \
+'moving to existing untracked target with trailing slash' \
+'mkdir path1
+ git mv path0/ path1/
+ test_path_is_dir path1/path0/'
+
+test_expect_success \
+'moving to existing tracked target with trailing slash' \
+'mkdir path2
+ path2/file git add path2/file
+ git mv path1/path0/ path2/
+ test_path_is_dir path2/path0/'
+
+test_expect_success \
+'clean up' \
+'git reset --hard'
test_expect_success \
'adding another file' \
--
1.8.5.rc3.4.g8bd3721
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Re: [PATCH 1/5] gitweb: Add a comment explaining the meaning of $/
On Wed, Dec 4, 2013 at 6:34 PM, Jakub Narębski jna...@gmail.com wrote: On Wed, Dec 4, 2013 at 4:46 PM, Krzesimir Nowak krzesi...@endocode.com wrote: On Wed, 2013-12-04 at 16:11 +0100, Jakub Narębski wrote: On Wed, Dec 4, 2013 at 2:42 PM, Krzesimir Nowak krzesi...@endocode.com wrote: So future reader will know what does it mean without running perldoc perlvar. Hmmm... shouldn't future reader know it anyway? It is not that cryptic. I'd say it is idiomatic Perl. It's plainly obscure. And I think it is not that often used - I keep forgetting what that pair of punctuation is actually meaning. I think it depends on what kind of Perl code one is used to. It is not as obscure as $; and similar to $|, I think. In this case I guess it would be more readable to use the following code instead: $fh-input_record_separator (\0); That would be a good change to replace local $/ = \0; open my $fh, -|, git_cmd(), ..., '-z', ... with open my $fh, -|, git_cmd(), ..., '-z', ... $fh-input_record_separator (\0); (not forgetting about use IO::Handle, which module is core Perl module); Actually it is replacing local $/ = \0; with IO::Handle-input_record_separator(\0); see http://p3rl.org/IO::Handle -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mv: let 'git mv file no-such-dir/' error out
Duy Nguyen pclo...@gmail.com writes: On Wed, Dec 4, 2013 at 3:44 PM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Duy Nguyen pclo...@gmail.com writes: On Tue, Dec 3, 2013 at 3:32 PM, Matthieu Moy matthieu@imag.fr wrote: There's something we probably should check. In d78b0f3 ([PATCH] git-mv: add more path normalization - 2006-08-16), it mentions about git mv something/ somewhere/ there's no test in that commit so I don't know the actual input and expected outcome. To me, the expected outcome is behave like Unix's mv (which works with or without the trailing slash if somewhere exists). If somewhere is a directory, it errors out with this patch and works without it. I can't reproduce. I've added this to my patch (indeed, the area wasn't well tested), and the tests pass. Now I can't either. Probably some mis-setups or some local bugs in my tree. Good that we have more tests. OK, I was also scratching my head after seeing your response. It seems that t7001 needs some face-lifting, by the way. Perhaps after this patch solidifies. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mv: let 'git mv file no-such-dir/' error out
Junio C Hamano gits...@pobox.com writes: It seems that t7001 needs some face-lifting, by the way. Perhaps after this patch solidifies. Yes. I followed the style of surrounding code, but it could be reformatted to follow the current standard. I have no time for it now. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] gitweb: Add a feature for adding more branch refs
Krzesimir Nowak krzesi...@endocode.com writes:
On Tue, 2013-12-03 at 21:38 +0100, Jakub Narębski wrote:
On Tue, Dec 3, 2013 at 9:15 PM, Junio C Hamano gits...@pobox.com wrote:
Krzesimir Nowak krzesi...@endocode.com writes:
@@ -626,6 +640,17 @@ sub feature_avatar {
return @val ? @val : @_;
}
+sub feature_extra_branch_refs {
+ my (@branch_refs) = @_;
+ my $values = git_get_project_config('extra_branch_refs');
Hmph. Three points.
* Almost all callers of this function use
my ($val) = git_get_project_config(...);
my @val = git_get_project_config(...);
to expect that the function returns a list of things (and grab the
first one among them, not the length of the list). Shouldn't this
part do the same?
Right. feature_snapshot() has here
my (@fmts) = @_;
my ($val) = git_get_project_config('snapshot');
...though git_get_project_config returns scalar.
So what's the point of it? 'my @val = git_get_project_config ()' just
creates an array with one element.
The point is that my ($val) = git_get_project_config('name') calls
the sub in the list context like everybody else, which would be more
robust, if you want to be prepared for somebody else's change to the
implementation in the future, I think.
* Wouldn't this be a good candidate for a multi-valued configuration
variable, e.g. shouldn't this
[gitweb]
extraBranchRefs = wip
extraBranchRefs = sandbox other
be parsed as a three-item list, qw(wip sandbox other)?
This would require changes in git_get_project_config(), which would
need to be able to deal with multi-valued result (it caches these
results, so we pay only one cost of `git config` call).
Hm, actually not at all. Now, if I have a setup like Junio wrote the
git_get_project_config just returns an array ref. So modifying the
feature_extra_branch_refs to handle the returned value as either simple
scalar or array reference should be enough.
Yes, changing the calling site to use of config_to_multi() around
(see the handling of 'ctag' for an example) and then concatenate the
result of splitting each returned element would be one way to do
this.
Jakub may have had in mind to teach git_get_project_config() to
return a list; because existing callers call the sub in the list
context, they will not get surprising result---even though they may
only use the first one and discard the rest.
Which might not be a bad thing in the longer term, but I think it is
outside the scope of this particular topic, but in order to prepare
for that kind of internal API enhancement, it would still help to
make sure that this new caller calls the sub in the list context
like others.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] gitweb: Add a feature for adding more branch refs
On Wed, Dec 4, 2013 at 2:43 PM, Krzesimir Nowak krzesi...@endocode.com wrote:
Allow extra-branch-refs feature to tell gitweb to show refs from
additional hierarchies in addition to branches in the list-of-branches
view.
Signed-off-by: Krzesimir Nowak krzesi...@endocode.com
Reviewed-by: Junio C Hamano gits...@pobox.com
Reviewed-by: Jakub Narębski jna...@gmail.com
This version is Helped-by (maybe), but not (yet!) Reviewed-by.
---
Documentation/gitweb.conf.txt | 37 +++
gitweb/gitweb.perl| 85
+--
2 files changed, 110 insertions(+), 12 deletions(-)
diff --git a/Documentation/gitweb.conf.txt b/Documentation/gitweb.conf.txt
index e2113d9..5a77452 100644
--- a/Documentation/gitweb.conf.txt
+++ b/Documentation/gitweb.conf.txt
@@ -849,6 +849,43 @@ time zones in the form of +/-HHMM, such as +0200.
+
Project specific override is not supported.
+extra-branch-refs::
+ List of additional directories under refs which are going to
+ be used as branch refs. For example if you have a gerrit setup
+ where all branches under refs/heads/ are official,
+ push-after-review ones and branches under refs/sandbox/,
+ refs/wip and refs/other are user ones where permissions are
+ much wider, then you might want to set this variable as
+ follows:
++
+
+$feature{'extra-branch-refs'}{'default'} =
+ ['sandbox', 'wip', 'other'];
+
++
+If overriding was enabled then this feature can be configured on a
s/was/is/;
Perhaps it would better read as
This feature can be configured on per-repository basis after setting
$feature{'extra-branch-refs'}{'override'} to true, via repository's
`gitweb.extraBranchRefs` ...
+per-repository basis via repository's `gitweb.extrabranchrefs`
+configuration variable, which contains a space separated list of
+refs. An example:
++
+
+[gitweb]
+ extrabranchrefs = sandbox wip other
+
O.K.
++
+The gitweb.extrabranchrefs is actually a multi-valued configuration
+variable, so following example is also correct and the result is the
+same as of the snippet above:
++
+
+[gitweb]
+ extrabranchrefs = sandbox
+ extrabranchrefs = wip other
+
I think this part should be better left for a separate patch. There is
important difference between single-valued and multi-valued configuration
variable: with single-valued later occurrences override earlier ones,
which includes settings in more specific config file (e.g. per-repository)
overriding setting in more general one (e.g. per-user or system-wide).
With multi-valued we won't be able to override earlier / more generic
settings... well, unless we add support for no-value, or empty-value
as clearer, i.e.
[gitweb]
extrabranchrefs = sandbox
extrabranchrefs
# orextrabranchrefs =
extrabranchrefs = wip other
resulting in ('wip', 'other').
++
+It is an error to specify a ref that does not pass git check-ref-format
+scrutiny. Duplicated values are filtered.
+
Hmmm... 'snapshot' feature ignores invalid values, but in this case
formerly valid compression schemes might get invalid via tightening
%known_snapshot_formats, and we don't want existing config getting
suddenly invalid.
[cut]
Nice!
--
Jakub Narebski
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] gitweb: Return plain booleans in validation methods
Jakub Narębski jna...@gmail.com writes:
On Wed, Dec 4, 2013 at 2:43 PM, Krzesimir Nowak krzesi...@endocode.com
wrote:
Users of validate_* passing 0 might get failures on correct name
because of coercion of 0 to false in code like:
die_error(500, invalid ref) unless (check_ref_format (0));
I would say that the problem was that validate_sth() subroutines returned
value of parameter if it was valid, which could be a problem if said value is
false-ish (e.g. validate_refname(0), or validate_pathname(0)).
Returning undef on invalid data newer was a problem, using 'return $input;'
on valid input was, especially that validate_sth() functions were ever used
in a conditional:
if (!validate_sth($param)) {
die_error(...)
}
Correct, and I think that is exactly what the above three lines in
the proposed log message says.
While at it validate_sth() is not a best name for boolean predicate:
is_valid_sth() would be better, I think.
Yeah, I tend to agree. As we are doing a whole-sale API clean-up in
this patch, we might as well do that at the same time.
Signed-off-by: Krzesimir Nowak krzesi...@endocode.com
---
gitweb/gitweb.perl | 45 +
1 file changed, 25 insertions(+), 20 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 67415b9..3434602 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1419,63 +1419,68 @@ sub href {
## validation, quoting/unquoting and escaping
sub validate_action {
- my $input = shift || return undef;
- return undef unless exists $actions{$input};
- return $input;
+ my $input = shift;
+
+ return 0 unless defined $input;
+ return 0 unless exists $actions{$input};
+ return 1;
}
The only change that needs to be doe is replacing
return $input;
with
return 1;
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Use mongoose to test smart-http unconditionally?
On Wed, Dec 4, 2013 at 2:53 AM, Duy Nguyen pclo...@gmail.com wrote: I was thinking of an alternative to apache for testing smart-http so that most of http tests could always run. Mongoose [1] looks like a good candidate to bundle with git. Just one pair of source files, mongoose.[ch], a mainloop wrapper and we have an http server. Just wondering, do we rely on any apache-specific features? I'm not so familiar with lib-httpd.sh.. I don't think we do anything Apache specific in the test suite. It basically relies on CGI execution, being able to configure a URL to serve a directory, and making some URLs 404 or 500 so we can emulate a broken or failing server to test the client behavior in those conditions. At worst that 404/500 forced failure mode could be handled by a CGI. [1] https://github.com/cesanta/mongoose -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Use mongoose to test smart-http unconditionally?
On Wed, Dec 04, 2013 at 10:13:11AM -0800, Shawn Pearce wrote: On Wed, Dec 4, 2013 at 2:53 AM, Duy Nguyen pclo...@gmail.com wrote: I was thinking of an alternative to apache for testing smart-http so that most of http tests could always run. Mongoose [1] looks like a good candidate to bundle with git. Just one pair of source files, mongoose.[ch], a mainloop wrapper and we have an http server. Just wondering, do we rely on any apache-specific features? I'm not so familiar with lib-httpd.sh.. I don't think we do anything Apache specific in the test suite. It basically relies on CGI execution, being able to configure a URL to serve a directory, and making some URLs 404 or 500 so we can emulate a broken or failing server to test the client behavior in those conditions. At worst that 404/500 forced failure mode could be handled by a CGI. I don't think there's anything apache specific, but there's a fair bit of config for handling various auth scenarios. It's stuff I'd expect any decent server implementation to handle, but somebody actually needs to go through and translate all of the config to mongoose. I've been tempted to add lighttpd support, as I generally find its config much more readable (and less prone to breaking during upgrades). But I think it would be a mistake to support multiple servers, as it would mean updates to the tests need to hit all of the servers. If mongoose gives a sane lowest common denominator, that's fine with me. I don't know if it is worth all that much effort, though. I suppose it could get us more exposure to the httpd tests, but I do not know if it would be a good idea to turn them on by default anyway. They touch global machine resources (like ports) that can cause conflicts or test failures. I assume that is the reason we do not turn on git-daemon tests by default (though perhaps it would be better in both cases to have it on by default and let people with special needs, like running multiple test instances at once, turn it off). -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] gitweb: Denote non-heads, non-remotes branches
On Wed, Dec 4, 2013 at 2:43 PM, Krzesimir Nowak krzesi...@endocode.com wrote:
Given two branches residing in refs/heads/master and refs/wip/feature
the list-of-branches view will present them in following way:
master
feature (wip)
When getting a snapshot of a 'feature' branch, the tarball is going to
have name like 'project-wip-feature-short hash.tgz'.
Signed-off-by: Krzesimir Nowak krzesi...@endocode.com
Very nice feature, which allows to distinguish between refs/heads/feature
and refs/wip/feature.
---
gitweb/gitweb.perl | 27 +--
1 file changed, 25 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 6d3d52d..9a63ea9 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3739,8 +3739,14 @@ sub git_get_heads_list {
$ref_item{'fullname'} = $name;
my $strip_refs = join '|', map { quotemeta }
get_branch_refs();
$name =~ s!^refs/($strip_refs|remotes)/!!;
+ $ref_item{'name'} = $name;
+ # for refs neither in 'heads' nor 'remotes' we want to
+ # show their different ref dir
Perhaps simply:
+ # for refs neither in 'heads' nor 'remotes' we want
to show their ref dir
+ my $ref_dir = (defined $1) ? $1 : '';
+ if ($ref_dir ne '' and $ref_dir ne 'heads' and $ref_dir ne
'remotes') {
+ $ref_item{'name'} .= ' (' . $ref_dir . ')';
+ }
- $ref_item{'name'} = $name;
$ref_item{'id'}= $hash;
$ref_item{'title'} = $title || '(no commit message)';
$ref_item{'epoch'} = $epoch;
@@ -7257,7 +7263,24 @@ sub snapshot_name {
# branches and other need shortened SHA-1 hash
my $strip_refs = join '|', map { quotemeta }
get_branch_refs();
if ($hash =~ m!^refs/($strip_refs|remotes)/(.*)$!) {
- $ver = $1;
+ my $ref_dir = $1;
+ $ver = $2;
+
+ if (defined $ref_dir) {
+ # this is going to be a part of
+ # filename, so lets stick to
+ # alphanumerics, dashes and underlines
+ # only - some filesystems do not like
+ # some punctuation symbols for
+ # example.
+ $ref_dir =~ s/[^[:alnum:]_-]//g;
+ }
I think this safety replacement should apply also to other parts of filename,
if it is to be used.
$ref_dir should be compatibile with path-part - in loose form it is stored
on filesystem... though different filesystems might have different restrictions.
One thing we should worry about is '/' in hierarchical refdir names, e.g.
'wip/jk', which needs to be replaced / sanitized somehow, though probably
as 'wip-jk' or 'wip_jk' rather than 'wipjk', isn't it?
+
+ # for refs not in heads nor remotes we want to
+ # add a ref dir to archive name
+ if ($ref_dir ne '' and $ref_dir ne 'heads' and
$ref_dir ne 'remotes') {
+ $ver = $ref_dir . '-' . $ver;
+ }
}
$ver .= '-' . git_get_short_hash($project, $hash);
}
--
1.8.3.1
--
Jakub Narebski
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Build issue for git 1.8.5.1 under Mac OS X 10.8 (Mountain Lion)
Hi all, Over the years I have built many versions of git and released them on hmug.org. git 1.8.5.1 builds just fine under OS 10.7 (Lion) and 10.9 (Mavericks), but the build fails (also for 1.8.5) on 10.8 (Mountain Lion): snip GIT_VERSION = 1.8.5.1 * new build flags CC credential-store.o In file included from git-compat-util.h:330:0, from cache.h:4, from credential-store.c:1: compat/apple-common-crypto.h: In function 'git_CC_EVP_EncodeBlock': compat/apple-common-crypto.h:32:2: error: 'SecTransformRef' undeclared (first use in this function) compat/apple-common-crypto.h:32:2: note: each undeclared identifier is reported only once for each function it appears in compat/apple-common-crypto.h:32:18: error: expected ';' before 'encoder' compat/apple-common-crypto.h:36:2: error: 'encoder' undeclared (first use in this function) compat/apple-common-crypto.h:36:2: warning: implicit declaration of function 'SecEncodeTransformCreate' compat/apple-common-crypto.h:36:37: error: 'kSecBase64Encoding' undeclared (first use in this function) compat/apple-common-crypto.h:40:2: warning: implicit declaration of function 'SecTransformSetAttribute' compat/apple-common-crypto.h:40:36: error: 'kSecTransformInputAttributeName' undeclared (first use in this function) compat/apple-common-crypto.h:44:2: warning: implicit declaration of function 'SecTransformExecute' compat/apple-common-crypto.h: In function 'git_CC_EVP_DecodeBlock': compat/apple-common-crypto.h:62:2: error: 'SecTransformRef' undeclared (first use in this function) compat/apple-common-crypto.h:62:18: error: expected ';' before 'decoder' compat/apple-common-crypto.h:66:2: error: 'decoder' undeclared (first use in this function) compat/apple-common-crypto.h:66:2: warning: implicit declaration of function 'SecDecodeTransformCreate' compat/apple-common-crypto.h:66:37: error: 'kSecBase64Encoding' undeclared (first use in this function) compat/apple-common-crypto.h:70:36: error: 'kSecTransformInputAttributeName' undeclared (first use in this function) Makefile:1975: recipe for target 'credential-store.o' failed make: *** [credential-store.o] Error 1 /snip Apparently a header issue: I tried force feeding the Security/SecEncryptTransform.h file, and just got an other error… Any help would be welcome! Thanks in advance. Marius -- Marius Schamschula -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] tests: fix gzip with exported GZIP variable in environment
On Tue, Dec 03, 2013 at 10:21:35AM -0800, Junio C Hamano wrote: Jeff King p...@peff.net writes: There are a few options I see: 1. Drop $GZIP variable, and hard-code the prerequisite check to gzip, which is what is being tested. 2. Keep $GZIP (but rename it to $GIT_GZIP), and explicitly set up tar.tgz.command as $GIT_GZIP -cn. 3. Teach the Makefile a knob to set the value for gzip at compile time, and use that for the baked-in config (and propagate it to the test to check the prerequisite). I think I'd be in favor of (1). It's the simplest, and we have not seen any reports of people who do not actually have gzip called gzip. Users can still override it via config if they really want to. I am OK with (1). A related tangent is that we may have to worry about is how/if a random setting coming from GZIP in the environment (e.g. GZIP=-1v) would interfere with the test. It may be the simplest to unset $GZIP at the beginning of these tests, regardless of which of the above three is taken. I don't think we should worry about it. There are two levels to consider here. One, people may put junk in their GZIP variable, which will impact normal running of git itself (e.g., when you run git archive). And two, they may put options in which affect the test output (e.g., -v). In the former case, I do not think it is worth worrying about. If you put something in your GZIP variable that causes gzip -cn to stop working (like GZIP=-d), then it is your fault for breaking gzip (and it is not just broken for git, but everywhere). If you put in tame things like --rsyncable or -9, I think it is a _good_ thing that git's invocation of gzip is respecting your choice. Fixing that would involve git-archive clearing the GZIP variable, but I do not think it is a good idea. For tests, we could potentially clear GZIP to give us a more consistent state for running the tests. But I do not think there is anything you would put in GZIP that should negatively affect the tests. Obvious just like -d is in the same boat as above; if you break gzip completely, you deserve it. If you use -v or -q to change stderr, we handle that just fine. That leaves options which change the compressed output, like -9. I'm inclined to say that letting them affect the tests is a good thing. It is true that we do not have a consistent state, but that also means we are testing the real world a little bit better. Part of the point of git's test suite is to make sure that from commit to commit, we do not break things. But it is also to show that for a given commit, from machine to machine we do not break things. Though we try to give a consistent baseline, we must tolerate some amount of variance, and that uncovers portability bugs (e.g., tests reveal that the shell on platform X does not like our script). If somebody shows up complaining that a test fails when they have GZIP set, then that may be catching a bug, or it may be catching a fragility in the test. But since we do not have a real-world complaint yet, I'd rather leave it and judge when we have an actual case. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: [PATCH 4/5] Replace {pre,suf}fixcmp() with {starts,ends}_with()
On Tue, Dec 03, 2013 at 09:24:40PM +0100, Christian Couder wrote: I skimmed the patch and didn't notice any problems. It's whitespace-damaged by gmail, of course. The simplest thing is probably to just point us at a public repo with the commit, if you have one. Ok, the commit is in the use_starts_ends_with branch on this github repo: https://github.com/chriscool/git.git Thanks. I looked more carefully this time, using a few greps to classify the surrounding context (since the script you used for the update could conceivably miss some really odd misuse). The whole thing looks good to me. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to resume broke clone ?
On Thu, Nov 28, 2013 at 11:15:27AM -0800, Shawn Pearce wrote: - better integration with git bundles, provide a way to seamlessly create/fetch/resume the bundles with git clone and git fetch We have been thinking about formalizing the /clone.bundle hack used by repo on Android. If the server has the bundle, add a capability in the refs advertisement saying its available, and the clone client can first fetch $URL/clone.bundle. Yes, that was going to be my next step after getting the bundle fetch support in. If we are going to do this, though, I'd really love for it to not be hey, fetch .../clone.bundle from me, but a full-fledged here are full URLs of my mirrors. Then you can redirect a non-http cloner to http to grab the bundle. Or redirect them to a CDN. Or even somebody else's server entirely (e.g., go fetch from Linus first, my piddly server cannot feed you the whole kernel). Some of the redirects you can do by issuing an http redirect to /clone.bundle, but the cross-protocol ones are tricky. If we advertise it as a blob in a specialized ref (e.g., refs/mirrors) it does not add much overhead over a simple capability. There are a few extra round trips to actually fetch the blob (client sends a want and no haves, then server sends the pack), but I think that's negligible when we are talking about redirecting a full clone. In either case, we have to hang up the original connection, fetch the mirror, and then come back. For most Git repositories the bundle can be constructed by saving the bundle reference header into a file, e.g. $GIT_DIR/objects/pack/pack-$NAME.bh at the same time the pack is created. The bundle can be served by combining the .bh and .pack streams onto the network. It is very little additional disk overhead for the origin server, That's clever. It does not work out of the box if you are using alternates, but I think it could be adapted in certain situations. E.g., if you layer the pack so that one base repo always has its full pack at the start, which is something we're already doing at GitHub. but allows resumable clone, provided the server has not done a GC. As an aside, the current transfer-resuming code in http.c is questionable. It does not use etags or any sort of invalidation mechanism, but just assumes hitting the same URL will give the same bytes. That _usually_ works for dumb fetching of objects and packfiles, though it is possible for a pack to change representation without changing name. My bundle patches inherited the same flaw, but it is much worse there, because your URL may very well just be clone.bundle that gets updated periodically. I posted patches for this last year. One of the things that I got hung up on was that I spooled the bundle to disk, and then cloned from it. Which meant that you needed twice the disk space for a moment. I don't think this is a huge concern. In many cases the checked out copy of the repository approaches a sizable fraction of the .pack itself. If you don't have 2x .pack disk available at clone time you may be in trouble anyway as you try to work with the repository post clone. Yeah, in retrospect I was being stupid to let that hold it up. I'll revisit the patches (I've rebased them forward over the past year, so it shouldn't be too bad). I wanted to teach index-pack to --fix-thin a pack that was already on disk, so that we could spool to disk, and then finalize it without making another copy. Don't you need to separate the bundle header from the pack data before you do this? Yes, though it isn't hard. We have to fetch part of the bundle header into memory during discover_refs(), since that is when we realize we are getting a bundle and not just the refs. From there you can spool the bundle header to disk, and then the packfile separately. My original implementation did that, though I don't remember if that one got posted to the list (after realizing that I couldn't just --fix-thin directly, I simplified it to just spool the whole thing to a single file). If the bundle is only used at clone time there is no --fix-thin step. Yes, for the particular use case of a clone-mirror, you wouldn't need to --fix-thin. But I think git fetch https://example.com/foo.bundle; should work in the general case (and it does with my patches). See above, I think you can reasonably do the /clone.bundle automatically on any HTTP server. Yeah, the .bh trick you mentioned is low enough impact to the server that we could just unconditionally make it part of the repack. What would need to go into such a hash? It would need to represent the exact bytes that will go into the pack, but without actually generating those bytes. Perhaps a sha1 over the sequence of object sha1, type, base (if applicable), length for each object would be enough. We should know that after calling compute_write_order. If the client has a match, we should be able to skip ahead to the correct byte. I don't think Length
Re: Use mongoose to test smart-http unconditionally?
Duy Nguyen pclo...@gmail.com writes: I was thinking of an alternative to apache for testing smart-http so that most of http tests could always run. Mongoose [1] looks like a good candidate to bundle with git. Just one pair of source files, mongoose.[ch], a mainloop wrapper and we have an http server. H. How would the high-level integration look like? - we add contrib/mongoose/*; - in t/Makefile, we: . set GIT_TEST_HTTPD to yes, unless it is already set to another value; . set LIB_HTTPD_PATH to $GIT_BUILD_DIR/contrib/mongoose/mongoose, unless it is already set to another value; . if LIB_HTTPD_PATH is set to our mongoose and if it hasn't been built, go ../contrib/mongoose and build it. - we teach lib-httpd.sh to trigger the DEFAULT_HTTPD_PATH computation when LIB_HTTPD_PATH is set to 'system-apache', so that people can test with their installed apache if they choose to; and - we teach lib-httpd.sh to write out an appropriate configuration for the mongoose server. That would force people to run http tests by turning it from an opt-in option to an opt-out option. Or were you thinking about embedding mongoose in the git executable? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] difftool: Change prompt to display the number of files in the diff queue
Eric Sunshine sunsh...@sunshineco.com writes: + setenv (GIT_DIFF_PATH_COUNTER, counterstr.buf, 1); + setenv (GIT_DIFF_PATH_TOTAL, totalstr.buf, 1); + retval = run_command_v_opt(spawn_arg, RUN_USING_SHELL); Would run_command_v_opt_cd_env() be more appropriate than setenv() + run_command_v_opt() done here? Probably (besides, SPs after 'setenv' need to go). Also, we know total/conter is a decimal integer. On-stack 32-byte arrays are sufficient and two strbufs are overkill ;-) diff --git a/t/t4020-diff-external.sh b/t/t4020-diff-external.sh index 8a30979..4935fc4 100755 --- a/t/t4020-diff-external.sh +++ b/t/t4020-diff-external.sh @@ -193,6 +193,22 @@ test_expect_success 'GIT_EXTERNAL_DIFF with more than one changed files' ' GIT_EXTERNAL_DIFF=echo git diff ' +echo #!$SHELL_PATH external-diff.sh +cat external-diff.sh \EOF +echo $GIT_DIFF_PATH_COUNTER of $GIT_DIFF_PATH_TOTAL counter.txt +EOF +chmod a+x external-diff.sh Perhaps write_script()? Definitely. Thanks, both. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 00/11] Make reference pruning more configurable
Michael Haggerty mhag...@alum.mit.edu writes: But even though --prune=pattern is no longer needed to prevent tag nuking, it might be useful to somebody for other purposes, and therefore I am submitting it to the list as an RFC. Maybe there is a use case associated with non-branch, non-tag references, like perhaps Gerrit pull request-related references? Personally, I am -0 on this series. I think it adds more complication (code, documentation, etc) than its usefulness justifies. I tend to agree. Even though selective only prune these if the other side no longer have corresponding refs sounds like a great flexibility as a concept, the user needs to know that the local refs that match given patterns cannot come from remotes other than the one that fetch is talking with, which is already too complicated for the human user to grok ;-) Don't mix refs from different sources in a random hierarchy is probably a good advice and when adhered to there is no need for such a selective pruning. So, if anybody can think of a compelling use case for this feature, please make your case! Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] gitweb: Add a comment explaining the meaning of $/
Martin Langhoff martin.langh...@gmail.com writes: On Wed, Dec 4, 2013 at 10:46 AM, Krzesimir Nowak krzesi...@endocode.com wrote: On Wed, 2013-12-04 at 16:11 +0100, Jakub Narębski wrote: On Wed, Dec 4, 2013 at 2:42 PM, Krzesimir Nowak krzesi...@endocode.com wrote: So future reader will know what does it mean without running perldoc perlvar. Hmmm... shouldn't future reader know it anyway? It is not that cryptic. I'd say it is idiomatic Perl. It's plainly obscure. And I think it is not that often used - It's classic Perl. Perhaps you'd want to use English; and call it $INPUT_RECORD_SEPARATOR in a patch titled Make things readable to non-Perl natives. Hmm, but do we want to see use English there in the first place? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] gitweb: Move check-ref-format code into separate function
Krzesimir Nowak krzesi...@endocode.com writes:
This check will be used in more than one place later.
Signed-off-by: Krzesimir Nowak krzesi...@endocode.com
Reviewed-by: Junio C Hamano gits...@pobox.com
Again, I do not think I reviewed this exact version. Nor did I say
that use of the ... or return undef is a good idea.
Reviewed-by: Jakub Narębski jna...@gmail.com
---
gitweb/gitweb.perl | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index ee61f9e..67415b9 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1452,6 +1452,16 @@ sub validate_pathname {
return $input;
}
+sub check_ref_format {
+ my $input = shift || return undef;
+
+ # restrictions on ref name according to git-check-ref-format
+ if ($input =~ m!(/\.|\.\.|[\000-\040\177 ~^:?*\[]|/$)!) {
+ return undef;
+ }
+ return $input;
+}
+
sub validate_refname {
my $input = shift || return undef;
@@ -1462,10 +1472,9 @@ sub validate_refname {
# it must be correct pathname
$input = validate_pathname($input)
or return undef;
- # restrictions on ref name according to git-check-ref-format
- if ($input =~ m!(/\.|\.\.|[\000-\040\177 ~^:?*\[]|/$)!) {
- return undef;
- }
+ # check git-check-ref-format restrictions
+ check_ref_format($input)
+ or return undef;
return $input;
}
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] Show extra branch refs in gitweb v6
Krzesimir Nowak krzesi...@endocode.com writes: First patch just adds a comment I though would be useful when trying to understand how config parsing is done. Second patch splits some code to a function. Third patch fixes validation functions to return either 0 or 1, instead of undef or passed $input. Fourth patch adds the extra-branch-feature and some documentation. Fifth patch adds some visual differentation of branches from non-standard ref directories. Krzesimir Nowak (5): gitweb: Add a comment explaining the meaning of $/ gitweb: Move check-ref-format code into separate function gitweb: Return plain booleans in validation methods gitweb: Add a feature for adding more branch refs gitweb: Denote non-heads, non-remotes branches Documentation/gitweb.conf.txt | 27 +++ gitweb/gitweb.perl| 166 +- 2 files changed, 160 insertions(+), 33 deletions(-) Thanks; I'll tentatively queue 2 thru 5 on 'pu', but people are feeding good suggestions on it, so I'd expect further rerolls. A tip: git format-patch -v7 --cover-letter may be handy. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: [PATCH 4/5] Replace {pre,suf}fixcmp() with {starts,ends}_with()
Christian Couder christian.cou...@gmail.com writes: Ok, the commit is in the use_starts_ends_with branch on this github repo: https://github.com/chriscool/git.git I looked at the patches, and they looked alright. The endgame needs to be on a separate topic to be held until a distant future, though. Will queue. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: [PATCH 4/5] Replace {pre,suf}fixcmp() with {starts,ends}_with()
Junio C Hamano gits...@pobox.com writes: Christian Couder christian.cou...@gmail.com writes: Ok, the commit is in the use_starts_ends_with branch on this github repo: https://github.com/chriscool/git.git I looked at the patches, and they looked alright. The endgame needs to be on a separate topic to be held until a distant future, though. Will queue. Thanks. It turns out that, naturally, there are many new uses of prefixcmp in the topics in flight. I can manage, but adjusting all of them would not look too pretty X-. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] tests: fix gzip with exported GZIP variable in environment
Jeff King p...@peff.net writes: On Tue, Dec 03, 2013 at 10:21:35AM -0800, Junio C Hamano wrote: Jeff King p...@peff.net writes: There are a few options I see: 1. Drop $GZIP variable, and hard-code the prerequisite check to gzip, which is what is being tested. ... I think I'd be in favor of (1). It's the simplest, and we have not seen any reports of people who do not actually have gzip called gzip. Users can still override it via config if they really want to. I am OK with (1). A related tangent is that we may have to worry about is how/if a random setting coming from GZIP in the environment (e.g. GZIP=-1v) would interfere with the test. It may be the simplest to unset $GZIP at the beginning of these tests, regardless of which of the above three is taken. I don't think we should worry about it. There are two levels to consider here. One, people may put junk in their GZIP variable, which will impact normal running of git itself... This wasn't something I was worried about. We should support reasonable setting of GZIP without breaking ourselves. That leaves options which change the compressed output, like -9. Yes, I was solely focusing on the stability of the tests. If somebody shows up complaining that a test fails when they have GZIP set, then that may be catching a bug, or it may be catching a fragility in the test. But since we do not have a real-world complaint yet, I'd rather leave it and judge when we have an actual case. OK. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/WIP PATCH 0/4] less ignorance of submodules for ignore=all
This is my current work in progress. Sergey it would be awesome if you could test these and tell me whether the behaviour is what you would expect. Once that is settled I will add some tests and possibly clean up some code. Since nobody spoke against this change of behavior I assume that we agree on the general approach I am taking here. If not please speak up now so we can work something out and save me implementation time ;-) Whats still missing is: * it seems reset does not care at all about the ignore settings. It still shows a Msubmodule line even when the submodule in question was not in the index and is marked as ignored. Have not looked at the code yet. * The git diff $commit question Junio mentioned here[1] it does not yet show diffs of ignore=all submodules. For testing convenience you can also find all patches applied to Junio's current master here: https://github.com/hvoigt/git/commits/hv/fix_ignore_all_submodules Cheers Heiko Heiko Voigt (4): disable complete ignorance of submodules for index - HEAD diff fix 'git add' to skip submodules configured as ignored teach add -f option for ignored submodules always show committed submodules in summary after commit builtin/add.c | 55 --- builtin/commit.c | 1 + builtin/diff.c| 2 ++ diff-lib.c| 3 +++ diff.h| 2 +- submodule.c | 26 -- submodule.h | 2 ++ t/t4027-diff-submodule.sh | 12 --- t/t7508-status.sh | 6 +- 9 files changed, 90 insertions(+), 19 deletions(-) -- 1.8.5.1.43.gf00fb86 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/WIP PATCH 1/4] disable complete ignorance of submodules for index - HEAD diff
If the value of ignore for submodules is set to all we would not show
whats actually committed during status or diff. This can result in the
user committing unexpected submodule references. Lets be nicer and always
show whats in the index.
Signed-off-by: Heiko Voigt hvo...@hvoigt.net
---
builtin/diff.c| 2 ++
diff-lib.c| 3 +++
diff.h| 2 +-
submodule.c | 16 ++--
submodule.h | 1 +
t/t4027-diff-submodule.sh | 12 +---
t/t7508-status.sh | 6 +-
7 files changed, 35 insertions(+), 7 deletions(-)
diff --git a/builtin/diff.c b/builtin/diff.c
index adb93a9..c47614d 100644
--- a/builtin/diff.c
+++ b/builtin/diff.c
@@ -162,6 +162,8 @@ static int builtin_diff_tree(struct rev_info *revs,
if (argc 1)
usage(builtin_diff_usage);
+ enforce_no_complete_ignore_submodule(revs-diffopt);
+
/*
* We saw two trees, ent0 and ent1. If ent1 is uninteresting,
* swap them.
diff --git a/diff-lib.c b/diff-lib.c
index 346cac6..c5219cb 100644
--- a/diff-lib.c
+++ b/diff-lib.c
@@ -483,6 +483,9 @@ int run_diff_index(struct rev_info *revs, int cached)
{
struct object_array_entry *ent;
+ if (cached)
+ enforce_no_complete_ignore_submodule(revs-diffopt);
+
ent = revs-pending.objects;
if (diff_cache(revs, ent-item-sha1, ent-name, cached))
exit(128);
diff --git a/diff.h b/diff.h
index e342325..81561b3 100644
--- a/diff.h
+++ b/diff.h
@@ -64,7 +64,7 @@ typedef struct strbuf *(*diff_prefix_fn_t)(struct
diff_options *opt, void *data)
#define DIFF_OPT_FIND_COPIES_HARDER (1 6)
#define DIFF_OPT_FOLLOW_RENAMES (1 7)
#define DIFF_OPT_RENAME_EMPTY(1 8)
-/* (1 9) unused */
+#define DIFF_OPT_NO_IGNORE_SUBMODULE (1 9)
#define DIFF_OPT_HAS_CHANGES (1 10)
#define DIFF_OPT_QUICK (1 11)
#define DIFF_OPT_NO_INDEX(1 12)
diff --git a/submodule.c b/submodule.c
index 1905d75..e0719b6 100644
--- a/submodule.c
+++ b/submodule.c
@@ -294,6 +294,16 @@ int parse_submodule_config_option(const char *var, const
char *value)
return 0;
}
+void enforce_no_complete_ignore_submodule(struct diff_options *diffopt)
+{
+ DIFF_OPT_SET(diffopt, NO_IGNORE_SUBMODULE);
+ if (DIFF_OPT_TST(diffopt, OVERRIDE_SUBMODULE_CONFIG)
+ DIFF_OPT_TST(diffopt, IGNORE_SUBMODULES)) {
+ DIFF_OPT_CLR(diffopt, IGNORE_SUBMODULES);
+ DIFF_OPT_SET(diffopt, IGNORE_DIRTY_SUBMODULES);
+ }
+}
+
void handle_ignore_submodules_arg(struct diff_options *diffopt,
const char *arg)
{
@@ -301,9 +311,11 @@ void handle_ignore_submodules_arg(struct diff_options
*diffopt,
DIFF_OPT_CLR(diffopt, IGNORE_UNTRACKED_IN_SUBMODULES);
DIFF_OPT_CLR(diffopt, IGNORE_DIRTY_SUBMODULES);
- if (!strcmp(arg, all))
+ if (!strcmp(arg, all)) {
+ if (DIFF_OPT_TST(diffopt, NO_IGNORE_SUBMODULE))
+ return;
DIFF_OPT_SET(diffopt, IGNORE_SUBMODULES);
- else if (!strcmp(arg, untracked))
+ } else if (!strcmp(arg, untracked))
DIFF_OPT_SET(diffopt, IGNORE_UNTRACKED_IN_SUBMODULES);
else if (!strcmp(arg, dirty))
DIFF_OPT_SET(diffopt, IGNORE_DIRTY_SUBMODULES);
diff --git a/submodule.h b/submodule.h
index 7beec48..2c8087e 100644
--- a/submodule.h
+++ b/submodule.h
@@ -20,6 +20,7 @@ void set_diffopt_flags_from_submodule_config(struct
diff_options *diffopt,
int submodule_config(const char *var, const char *value, void *cb);
void gitmodules_config(void);
int parse_submodule_config_option(const char *var, const char *value);
+void enforce_no_complete_ignore_submodule(struct diff_options *diffopt);
void handle_ignore_submodules_arg(struct diff_options *diffopt, const char *);
int parse_fetch_recurse_submodules_arg(const char *opt, const char *arg);
void show_submodule_summary(FILE *f, const char *path,
diff --git a/t/t4027-diff-submodule.sh b/t/t4027-diff-submodule.sh
index 518bf95..bd84ea7 100755
--- a/t/t4027-diff-submodule.sh
+++ b/t/t4027-diff-submodule.sh
@@ -258,7 +258,9 @@ test_expect_success 'git diff between submodule commits' '
expect_from_to expect.body $subtip $subprev
test_cmp expect.body actual.body
git diff --ignore-submodules HEAD^..HEAD actual
- ! test -s actual
+ sed -e 1,/^@@/d actual actual.body
+ expect_from_to expect.body $subtip $subprev
+ test_cmp expect.body actual.body
'
test_expect_success 'git diff between submodule commits [.git/config]' '
@@ -274,7 +276,9 @@ test_expect_success 'git diff between submodule commits
[.git/config]' '
test_cmp expect.body actual.body
git config submodule.subname.ignore all
git diff HEAD^..HEAD actual
- ! test -s actual
+ sed -e 1,/^@@/d actual actual.body
+
[RFC/WIP PATCH 2/4] fix 'git add' to skip submodules configured as ignored
If submodules are configured as ignore=all they are not shown by status.
Lets also ignore them when adding files to the index. This avoids that
users accidentially add ignored submodules with: git add .
We achieve this by reading the submodule config and thus correctly
initializing the infrastructure to take the ignore decision.
Signed-off-by: Heiko Voigt hvo...@hvoigt.net
---
builtin/add.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/builtin/add.c b/builtin/add.c
index 226f758..2d0d2ef 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -15,6 +15,7 @@
#include diffcore.h
#include revision.h
#include bulk-checkin.h
+#include submodule.h
static const char * const builtin_add_usage[] = {
N_(git add [options] [--] pathspec...),
@@ -378,6 +379,10 @@ static int add_config(const char *var, const char *value,
void *cb)
ignore_add_errors = git_config_bool(var, value);
return 0;
}
+
+ if (!prefixcmp(var, submodule.))
+ return parse_submodule_config_option(var, value);
+
return git_default_config(var, value, cb);
}
@@ -415,6 +420,7 @@ int cmd_add(int argc, const char **argv, const char *prefix)
int implicit_dot = 0;
struct update_callback_data update_data;
+ gitmodules_config();
git_config(add_config, NULL);
argc = parse_options(argc, argv, prefix, builtin_add_options,
--
1.8.5.1.43.gf00fb86
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/WIP PATCH 3/4] teach add -f option for ignored submodules
When the user wants to bypass the ignored status configured by
submodule.name.ignore=all it is now allowed by using the -f option.
Signed-off-by: Heiko Voigt hvo...@hvoigt.net
---
builtin/add.c | 49 +
submodule.c | 10 ++
submodule.h | 1 +
3 files changed, 48 insertions(+), 12 deletions(-)
diff --git a/builtin/add.c b/builtin/add.c
index 2d0d2ef..d6cab7f 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -16,6 +16,7 @@
#include revision.h
#include bulk-checkin.h
#include submodule.h
+#include string-list.h
static const char * const builtin_add_usage[] = {
N_(git add [options] [--] pathspec...),
@@ -37,6 +38,20 @@ struct update_callback_data {
static const char *option_with_implicit_dot;
static const char *short_option_with_implicit_dot;
+static struct lock_file lock_file;
+
+static const char ignore_error[] =
+N_(The following paths are ignored by one of your .gitignore files:\n);
+static const char submodule_ignore_error[] =
+N_(The following paths are ignored submodules:\n);
+
+static int verbose, show_only, ignored_too, refresh_only;
+static int ignore_add_errors, intent_to_add, ignore_missing;
+
+#define ADDREMOVE_DEFAULT 0 /* Change to 1 in Git 2.0 */
+static int addremove = ADDREMOVE_DEFAULT;
+static int addremove_explicit = -1; /* unspecified */
+
static void warn_pathless_add(void)
{
static int shown;
@@ -140,6 +155,9 @@ static void update_callback(struct diff_queue_struct *q,
warn_pathless_add();
continue;
}
+ if (is_ignored_submodule(path) !ignored_too)
+ continue;
+
switch (fix_unmerged_status(p, data)) {
default:
die(_(unexpected diff status %c), p-status);
@@ -174,6 +192,7 @@ static void update_files_in_cache(const char *prefix,
struct rev_info rev;
init_revisions(rev, prefix);
+ enforce_no_complete_ignore_submodule(rev.diffopt);
setup_revisions(0, NULL, rev, NULL);
if (pathspec)
copy_pathspec(rev.prune_data, pathspec);
@@ -332,18 +351,6 @@ static int edit_patch(int argc, const char **argv, const
char *prefix)
return 0;
}
-static struct lock_file lock_file;
-
-static const char ignore_error[] =
-N_(The following paths are ignored by one of your .gitignore files:\n);
-
-static int verbose, show_only, ignored_too, refresh_only;
-static int ignore_add_errors, intent_to_add, ignore_missing;
-
-#define ADDREMOVE_DEFAULT 0 /* Change to 1 in Git 2.0 */
-static int addremove = ADDREMOVE_DEFAULT;
-static int addremove_explicit = -1; /* unspecified */
-
static int ignore_removal_cb(const struct option *opt, const char *arg, int
unset)
{
/* if we are told to ignore, we are not adding removals */
@@ -407,6 +414,17 @@ static int add_files(struct dir_struct *dir, int flags)
return exit_status;
}
+static void die_ignored_submodules(struct string_list *ignored_submodules)
+{
+ struct string_list_item *path;
+
+ fprintf(stderr, _(submodule_ignore_error));
+ for_each_string_list_item(path, ignored_submodules)
+ fprintf(stderr, %s\n, path-string);
+ fprintf(stderr, _(Use -f if you really want to add them.\n));
+ die(_(no files added));
+}
+
int cmd_add(int argc, const char **argv, const char *prefix)
{
int exit_status = 0;
@@ -419,6 +437,7 @@ int cmd_add(int argc, const char **argv, const char *prefix)
char *seen = NULL;
int implicit_dot = 0;
struct update_callback_data update_data;
+ struct string_list ignored_submodules = STRING_LIST_INIT_NODUP;
gitmodules_config();
git_config(add_config, NULL);
@@ -550,6 +569,7 @@ int cmd_add(int argc, const char **argv, const char *prefix)
for (i = 0; i pathspec.nr; i++) {
const char *path = pathspec.items[i].match;
+ char path_copy[PATH_MAX];
if (!seen[i]
((pathspec.items[i].magic
(PATHSPEC_GLOB | PATHSPEC_ICASE)) ||
@@ -562,6 +582,9 @@ int cmd_add(int argc, const char **argv, const char *prefix)
die(_(pathspec '%s' did not match any
files),
pathspec.items[i].original);
}
+ normalize_path_copy(path_copy, path);
+ if (is_ignored_submodule(path_copy))
+ string_list_insert(ignored_submodules, path);
}
free(seen);
}
@@ -583,6 +606,8 @@ int cmd_add(int argc, const char **argv, const char *prefix)
update_files_in_cache(prefix, pathspec, update_data);
exit_status |= !!update_data.add_errors;
+ if (!ignored_too ignored_submodules.nr)
+
[RFC/WIP PATCH 4/4] always show committed submodules in summary after commit
If an ignored submodule is committed because is was registered in the index we should always show that to the user in the printed summary after commit. Signed-off-by: Heiko Voigt hvo...@hvoigt.net --- builtin/commit.c | 1 + 1 file changed, 1 insertion(+) diff --git a/builtin/commit.c b/builtin/commit.c index 6ab4605..e551566 100644 --- a/builtin/commit.c +++ b/builtin/commit.c @@ -1361,6 +1361,7 @@ static void print_summary(const char *prefix, const unsigned char *sha1, strbuf_release(committer_ident); init_revisions(rev, prefix); + enforce_no_complete_ignore_submodule(rev.diffopt); setup_revisions(0, NULL, rev, NULL); rev.diff = 1; -- 1.8.5.1.43.gf00fb86 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Use mongoose to test smart-http unconditionally?
On Wed, Dec 04, 2013 at 12:09:09PM -0800, Junio C Hamano wrote: Duy Nguyen pclo...@gmail.com writes: I was thinking of an alternative to apache for testing smart-http so that most of http tests could always run. Mongoose [1] looks like a good candidate to bundle with git. Just one pair of source files, mongoose.[ch], a mainloop wrapper and we have an http server. H. How would the high-level integration look like? - we add contrib/mongoose/*; - in t/Makefile, we: . set GIT_TEST_HTTPD to yes, unless it is already set to another value; . set LIB_HTTPD_PATH to $GIT_BUILD_DIR/contrib/mongoose/mongoose, unless it is already set to another value; . if LIB_HTTPD_PATH is set to our mongoose and if it hasn't been built, go ../contrib/mongoose and build it. I think building it on-demand is probably too much effort. If it is portable, then it should not be a problem to just build it along with the rest of git. If it is not, then we should rethink whether it is worth including. - we teach lib-httpd.sh to trigger the DEFAULT_HTTPD_PATH computation when LIB_HTTPD_PATH is set to 'system-apache', so that people can test with their installed apache if they choose to; and I do not think we want to allow run-time switching between an embedded solution and apache. That would mean that we have to keep two sets of http-server config in sync. Or were you thinking about embedding mongoose in the git executable? I don't think it makes sense to embed it in git, but it could easily be test-httpd. The rollout would be: 1. add contrib/mongoose/* 2. add test-httpd which links against mongoose, built by default in the Makefile 3. convert lib-httpd/apache.conf into mongoose config as necessary 4. convert lib-httpd.sh to run test-httpd instead of LIB_HTTPD_PATH 5. delete apache.conf, LIB_HTTPD_PATH and any other apache remnants 6. default GIT_TEST_HTTPD to yes Step 3 is the part where I would anticipate trouble (i.e., finding out that the new server does not do everything the tests expect). -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/WIP PATCH 0/4] less ignorance of submodules for ignore=all
On Wed, Dec 04, 2013 at 11:16:59PM +0100, Heiko Voigt wrote: * The git diff $commit question Junio mentioned here[1] it does not yet show diffs of ignore=all submodules. Forgot to add this here: [1] http://article.gmane.org/gmane.comp.version-control.git/238348 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/WIP PATCH 0/4] less ignorance of submodules for ignore=all
Heiko Voigt hvo...@hvoigt.net writes: This is my current work in progress. Sergey it would be awesome if you could test these and tell me whether the behaviour is what you would expect. Once that is settled I will add some tests and possibly clean up some code. Since nobody spoke against this change of behavior I assume that we agree on the general approach I am taking here. If not please speak up now so we can work something out and save me implementation time ;-) Whats still missing is: Before listing what's missing, can you describe what the general approach is? After all, that is what you are assuming that has got a silent concensus, but without getting it spelled out, others would easily miss what they agreed to. I do think that it is a good thing to make what git add . does and what git status . reports consistent, and git add . that does not add everything may be a good step in that direction (another possible solution may be to admit that ignore=all was a mistake and remove that special case altogether, so that git status will always report a submodule that does not match what is in the HEAD and/or index). -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git filter-branch --directory-filter oddity
On Tue, Dec 3, 2013 at 5:44 PM, Martin Langhoff martin.langh...@gmail.com wrote: Am I doing it wrong? Looks like I was doing something wrong. Apologies about the noise. cheers, m -- martin.langh...@gmail.com - ask interesting questions - don't get distracted with shiny stuff - working code first ~ http://docs.moodle.org/en/User:Martin_Langhoff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Use mongoose to test smart-http unconditionally?
Jeff King p...@peff.net writes: The rollout would be: 1. add contrib/mongoose/* 2. add test-httpd which links against mongoose, built by default in the Makefile 3. convert lib-httpd/apache.conf into mongoose config as necessary 4. convert lib-httpd.sh to run test-httpd instead of LIB_HTTPD_PATH 5. delete apache.conf, LIB_HTTPD_PATH and any other apache remnants 6. default GIT_TEST_HTTPD to yes Step 3 is the part where I would anticipate trouble (i.e., finding out that the new server does not do everything the tests expect). If it involves making things not tested with apache, I'd actually be less supportive for the whole plan. I thought the primary objective was to encourage people who currently are _not_ running httpd tests by making a lightweight server available out of the box, robbing an excuse my box does not have apache installed from them. As long as a server supports bog standard CGI interface, smart-http should work the same way with any such server. For that reason, it should be theoretically sufficient to test with one non-apache server (i.e. mongoose) for the purpose of making sure _our_ end of the set-up works, but still... -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Publishing filtered branch repositories - workflow / recommendations?
Hi folks.
currently working on a project based on Moodle (the LMS that got me
into git in the first place). This is a highly modular software, and I
would like to maintain a bunch of out of tree modules in a single
repository, and be able to publish them in per-module repositories.
So I would like to maintain a tree with looking like
auth/foomatic/{code}
mod/foomatic/{code}
where I can develop, branch and tag all the foomatic code together.
Yet, at release time I want to _also_ publish two repos
auth-foomatic.git
mod-foomatic.git
each of them with matching tags and code at the root of the git
tree, and ideally with a truthful history (i.e.: similar to having run
git filter-branch --subdirectory-filter, but able to update that
filtered history incrementally).
Is there a reasonable approach to scripting this?
Alternatively, has git submodule been improved so that it's usable by
mere mortals (i.e.: my team), or are there strong alternatives to git
submodule?
cheers,
m
--
martin.langh...@gmail.com
- ask interesting questions
- don't get distracted with shiny stuff - working code first
~ http://docs.moodle.org/en/User:Martin_Langhoff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Re: [RFC/WIP PATCH 0/4] less ignorance of submodules for ignore=all
On Wed, Dec 04, 2013 at 02:32:46PM -0800, Junio C Hamano wrote: Heiko Voigt hvo...@hvoigt.net writes: This is my current work in progress. Sergey it would be awesome if you could test these and tell me whether the behaviour is what you would expect. Once that is settled I will add some tests and possibly clean up some code. Since nobody spoke against this change of behavior I assume that we agree on the general approach I am taking here. If not please speak up now so we can work something out and save me implementation time ;-) Whats still missing is: Before listing what's missing, can you describe what the general approach is? After all, that is what you are assuming that has got a silent concensus, but without getting it spelled out, others would easily miss what they agreed to. Definitely, sorry I missed that (isn't it obvious ;-)): This series tries to achieve the following goals for the submodule.name.ignore=all configuration or the --ignore-submodules=all command line switch. * Make git status never ignore submodule changes that got somehow in the index. Currently when ignore=all is specified they are and thus secretly committed. Basically always show exactly what will be committed. * Make add ignore submodules that have the ignore=all configuration when not explicitly naming a certain submodule (i.e. using git add .). That way ignore=all submodules are not added to the index by default. That can be overridden by using the -f switch so it behaves the same as with untracked files specified in one of the ignore files except that submodules are actually tracked. * Let diff always show submodule changes between revisions or between a revision and the index. Only worktree changes should be ignored with ignore=all. * Generally speaking: Make everything that displays diffs in history, diffs between revisions or between a revision and the index always show submodules changes (only the commit ids) even if a submodule is specified as ignore=all. * If ignore=all for a submodule and a diff would usually involve the worktree we will show the diff of the commit ids between the current index and the requested revision. I do think that it is a good thing to make what git add . does and what git status . reports consistent, and git add . that does not add everything may be a good step in that direction (another possible solution may be to admit that ignore=all was a mistake and remove that special case altogether, so that git status will always report a submodule that does not match what is in the HEAD and/or index). I think it was too early to add ignore=all back then when the ignoring was implemented. We did not think through all implications. Since people have always been requesting the floating model and as it seems started using it I am not so sure whether there is not a valid use case. Maybe Sergey can shed some light on their actual use case and why they do not care about the precise revision most of the time. For example the case that all developers always want to work with some HEAD revision of all submodules and the build system then integrates their changes on a regular basis. When all went well it creates commits with the precise revisions. This way they have some stable points as fallback or for releases. Thats at least the use case I can think of but maybe there are others. Cheers Heiko -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Use mongoose to test smart-http unconditionally?
Jeff King wrote: I don't know if it is worth all that much effort, though. I suppose it could get us more exposure to the httpd tests, but I do not know if it would be a good idea to turn them on by default anyway. They touch global machine resources (like ports) that can cause conflicts or test failures. I assume that is the reason we do not turn on git-daemon tests by default Yup, that's why I don't run them. For what it's worth, when I build git and run tests I tend to be in an environment with apache available, but I'm too lazy to configure git's tests to pick the right port and make sure it is reserved and so on. Perhaps there's some way to help lazy people in the same boat? (E.g., picking a port randomly and skipping instead of failing a test when it's taken or something) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] contrib/git-credential-gnome-keyring.c: small stylistic cleanups
Thanks, will queue. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Use mongoose to test smart-http unconditionally?
On Thu, Dec 5, 2013 at 6:28 AM, Jonathan Nieder jrnie...@gmail.com wrote: Jeff King wrote: I don't know if it is worth all that much effort, though. I suppose it could get us more exposure to the httpd tests, but I do not know if it would be a good idea to turn them on by default anyway. They touch global machine resources (like ports) that can cause conflicts or test failures. I assume that is the reason we do not turn on git-daemon tests by default Yup, that's why I don't run them. For what it's worth, when I build git and run tests I tend to be in an environment with apache available, but I'm too lazy to configure git's tests to pick the right port and make sure it is reserved and so on. Perhaps there's some way to help lazy people in the same boat? (E.g., picking a port randomly and skipping instead of failing a test when it's taken or something) Sounds like good first steps. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
What's cooking in git.git (Dec 2013, #01; Wed, 4)
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
There are quite a many topics that have been left over from the
previous round. I haven't rewound the tip of 'next' yet, but I am
planning to do so real soon now, kicking some topics out of it.
The next release has not been named yet. I do not think it will be
2.0 yet, but I am tempted to call it 1.9 (not 1.9.0) in preparation
for 2.0 sometime late spring or early summer.
You can find the changes described here in the integration branches
of the repositories listed at
http://git-blame.blogspot.com/p/git-public-repositories.html
--
[Graduated to master]
* jj/doc-markup-gitcli (2013-11-20) 1 commit
(merged to 'next' on 2013-11-21 at 5e49fa8)
+ Documentation/gitcli.txt: fix double quotes
* jj/doc-markup-hints-in-coding-guidelines (2013-11-18) 1 commit
(merged to 'next' on 2013-11-21 at 9c638a6)
+ State correct usage of literal examples in man pages in the coding standards
* jj/log-doc (2013-11-13) 2 commits
(merged to 'next' on 2013-11-21 at cb0ddd2)
+ Documentation/git-log.txt: mark-up fix and minor rephasing
+ Documentation/git-log: update --log-size description
* jj/rev-list-options-doc (2013-11-18) 2 commits
(merged to 'next' on 2013-11-20 at db975de)
+ Documentation/rev-list-options.txt: fix some grammatical issues and typos
+ Documentation/rev-list-options.txt: fix mark-up
* mi/typofixes (2013-11-12) 3 commits
(merged to 'next' on 2013-11-13 at bb7c2eb)
+ contrib: typofixes
+ Documentation/technical/http-protocol.txt: typofixes
+ typofixes: fix misspelt comments
* nd/glossary-content-pathspec-markup (2013-11-21) 1 commit
(merged to 'next' on 2013-11-21 at 6072636)
+ glossary-content.txt: fix documentation of ** patterns
* tb/doc-fetch-pack-url (2013-11-11) 1 commit
(merged to 'next' on 2013-11-13 at 90d6832)
+ git-fetch-pack uses URLs like git-fetch
--
[New Topics]
* cl/p4-use-diff-tree (2013-11-22) 1 commit
(merged to 'next' on 2013-11-27 at 11926ce)
+ git p4: Use git diff-tree instead of format-patch
Will merge to 'master'.
* jn/scripts-updates (2013-11-26) 11 commits
(merged to 'next' on 2013-11-27 at 5056d4d)
+ Merge commit '0f2068c4cfb8bc84d338265f03c773e5559e761d' into
jn/scripts-updates
+ gitk: chmod +x po2msg
+ Merge commit '688eb87c9444686180d8f379ab854bcbc34db4db' into
jn/scripts-updates
+ git-gui: chmod +x po2msg, windows/git-gui.sh
+ remove #!interpreter line from shell libraries
+ test: replace shebangs with descriptions in shell libraries
+ test: make FILEMODE a lazy prereq
+ contrib: remove git-p4import
+ mark contributed hooks executable
+ mark perl test scripts executable
+ mark Windows build scripts executable
Will drop the two merges at the tip to gitk and git-gui parts of
the tree, as I've forwarded the relevant patches to the upstream
and expect them to come back later from their respective trees.
* tr/commit-slab-cleanup (2013-12-02) 3 commits
(merged to 'next' on 2013-12-02 at f545f4d)
+ commit-slab: sizeof() the right type in xrealloc
(merged to 'next' on 2013-11-27 at 84d5a73)
+ commit-slab: declare functions static inline
+ commit-slab: document clear_$slabname()
* tr/doc-git-cherry (2013-11-27) 1 commit
(merged to 'next' on 2013-11-27 at d37f520)
+ Documentation: revamp git-cherry(1)
Will merge to 'master'.
* aa/transport-non-positive-depth-only (2013-11-26) 1 commit
(merged to 'next' on 2013-11-27 at b01f05b)
+ transport: catch non positive --depth option value
Will merge to 'master'.
* rs/doc-submitting-patches (2013-11-27) 1 commit
(merged to 'next' on 2013-11-27 at f8886f4)
+ SubmittingPatches: document how to handle multiple patches
Will merge to 'master'.
* cc/starts-n-ends-with (2013-12-04) 4 commits
- replace {pre,suf}fixcmp() with {starts,ends}_with()
- strbuf: introduce starts_with() and ends_with()
- builtin/remote: remove postfixcmp() and use suffixcmp() instead
- environment: normalize use of prefixcmp() by removing != 0
(this branch is used by cc/starts-n-ends-with-endgame.)
Remove a few duplicate implementations of prefix/suffix comparison
functions, and rename them to starts_with and ends_with.
This conflicts with a part of cc/remote-remove-redundant-postfixcmp
topic (I think it actually subsumes it).
* cc/starts-n-ends-with-endgame (2013-12-04) 1 commit
- strbuf: remove prefixcmp() and suffixcmp()
(this branch uses cc/starts-n-ends-with.)
Endgame for the above topic, that needs to be evil-merged with
other topics that introduce new uses of prefix/suffix-cmp
functions.
* jc/push-refmap (2013-12-04) 3 commits
- push: also use upstream mapping when pushing a single ref
- push: use remote.$name.push as a refmap
- builtin/push.c: use strbuf instead of manual allocation
Make git push
[PATCH v2 0/3] Teaching git push to map pushed refs
The 'master' refspec in git fetch origin master used to mean We grab their 'master' branch, but we do not store it in any of our remote-tracking branches. but in modern Git, the remote-tracking branch that would receive updates from 'master' with a corresponding git fetch origin (without any specific refs on the command line) is updated. Updating the same refs/remotes/origin/master with git fetch origin git fetch origin master avoids surprises. However, we did not have a similar refspec mapping on the push side. This three-patch series does just that. It would help triangular workflow by making these two: git checkout master git push origin git push origin master update the same ref at the 'origin'. It also would help those who need to emulate a fetch run on mothership from satellite with a push run on satellite into mothership (due to e.g. network connectivity issues). The second round avoids instantiating the remote and the list of local heads until the very last minute when they are actually needed (the change is in the second patch). Junio C Hamano (3): builtin/push.c: use strbuf instead of manual allocation push: use remote.$name.push as a refmap push: also use upstream mapping when pushing a single ref Documentation/git-push.txt | 9 +++-- builtin/push.c | 84 ++ remote.c | 8 ++--- remote.h | 2 ++ t/t5516-fetch-push.sh | 75 + 5 files changed, 150 insertions(+), 28 deletions(-) -- 1.8.5.1-402-gdd8f092 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/3] push: also use upstream mapping when pushing a single ref
When the user is using the 'upstream' mode, these commands:
$ git push
$ git push origin
would find the 'upstream' branch for the current branch, and then
push the current branch to update it. However, pushing a single
branch explicitly, i.e.
$ git push origin $(git symbolic-ref --short HEAD)
would not go through the same ref mapping process, and ends up
updating the branch at 'origin' of the same name, which may not
necessarily be the upstream of the branch being pushed.
In the spirit similar to the previous one, map a colon-less refspec
using the upstream mapping logic.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
builtin/push.c| 11 +++
t/t5516-fetch-push.sh | 30 ++
2 files changed, 41 insertions(+)
diff --git a/builtin/push.c b/builtin/push.c
index 857f76d..9e47c29 100644
--- a/builtin/push.c
+++ b/builtin/push.c
@@ -58,6 +58,17 @@ static const char *map_refspec(const char *ref,
}
}
+ if (push_default == PUSH_DEFAULT_UPSTREAM
+ !prefixcmp(matched-name, refs/heads/)) {
+ struct branch *branch = branch_get(matched-name + 11);
+ if (branch-merge_nr == 1 branch-merge[0]-src) {
+ struct strbuf buf = STRBUF_INIT;
+ strbuf_addf(buf, %s:%s,
+ ref, branch-merge[0]-src);
+ return strbuf_detach(buf, NULL);
+ }
+ }
+
return ref;
}
diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
index 6d7f102..926e7f6 100755
--- a/t/t5516-fetch-push.sh
+++ b/t/t5516-fetch-push.sh
@@ -1160,6 +1160,7 @@ test_expect_success 'with no remote.$name.push, it is not
used as refmap' '
git pull ../testrepo master
git branch next
git config remote.dst.url ../dst
+ git config push.default matching
git push dst master
git show-ref refs/heads/master ../dst/expect
)
@@ -1171,6 +1172,35 @@ test_expect_success 'with no remote.$name.push, it is
not used as refmap' '
test_cmp dst/expect dst/actual
'
+test_expect_success 'with no remote.$name.push, upstream mapping is used' '
+ mk_test testrepo heads/master
+ rm -fr src dst
+ git init src
+ git init --bare dst
+ (
+ cd src
+ git pull ../testrepo master
+ git branch next
+ git config remote.dst.url ../dst
+ git config remote.dst.fetch +refs/heads/*:refs/remotes/dst/*
+ git config push.default upstream
+
+ git config branch.master.merge refs/heads/trunk
+ git config branch.master.remote dst
+
+ git push dst master
+ git show-ref refs/heads/master |
+ sed -e s|refs/heads/master|refs/heads/trunk| ../dst/expect
+ )
+ (
+ cd dst
+ test_must_fail git show-ref refs/heads/master
+ test_must_fail git show-ref refs/heads/next
+ git show-ref refs/heads/trunk actual
+ )
+ test_cmp dst/expect dst/actual
+'
+
test_expect_success 'push does not follow tags by default' '
mk_test testrepo heads/master
rm -fr src dst
--
1.8.5.1-402-gdd8f092
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/3] builtin/push.c: use strbuf instead of manual allocation
The command line arguments given to git push are massaged into
a list of refspecs in set_refspecs() function. This was implemented
using xmalloc, strcpy and friends, but it is much easier to read if
done using strbuf.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
builtin/push.c | 35 ++-
1 file changed, 14 insertions(+), 21 deletions(-)
diff --git a/builtin/push.c b/builtin/push.c
index 7b1b66c..76e4400 100644
--- a/builtin/push.c
+++ b/builtin/push.c
@@ -41,29 +41,22 @@ static void set_refspecs(const char **refs, int nr)
for (i = 0; i nr; i++) {
const char *ref = refs[i];
if (!strcmp(tag, ref)) {
- char *tag;
- int len;
+ struct strbuf tagref = STRBUF_INIT;
if (nr = ++i)
die(_(tag shorthand without tag));
- len = strlen(refs[i]) + 11;
- if (deleterefs) {
- tag = xmalloc(len+1);
- strcpy(tag, :refs/tags/);
- } else {
- tag = xmalloc(len);
- strcpy(tag, refs/tags/);
- }
- strcat(tag, refs[i]);
- ref = tag;
- } else if (deleterefs !strchr(ref, ':')) {
- char *delref;
- int len = strlen(ref)+1;
- delref = xmalloc(len+1);
- strcpy(delref, :);
- strcat(delref, ref);
- ref = delref;
- } else if (deleterefs)
- die(_(--delete only accepts plain target ref names));
+ ref = refs[i];
+ if (deleterefs)
+ strbuf_addf(tagref, :refs/tags/%s, ref);
+ else
+ strbuf_addf(tagref, refs/tags/%s, ref);
+ ref = strbuf_detach(tagref, NULL);
+ } else if (deleterefs) {
+ struct strbuf delref = STRBUF_INIT;
+ if (strchr(ref, ':'))
+ die(_(--delete only accepts plain target ref
names));
+ strbuf_addf(delref, :%s, ref);
+ ref = strbuf_detach(delref, NULL);
+ }
add_refspec(ref);
}
}
--
1.8.5.1-402-gdd8f092
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/3] push: use remote.$name.push as a refmap
Since f2690487 (fetch: opportunistically update tracking refs,
2013-05-11), we stopped taking a non-storing refspec given on the
command line of git fetch literally, and instead started mapping
it via remote.$name.fetch refspecs. This allows
$ git fetch origin master
from the 'origin' repository, which is configured with
[remote origin]
fetch = +refs/heads/*:refs/remotes/origin/*
to update refs/remotes/origin/master with the result, as if the
command line were
$ git fetch origin +master:refs/remotes/origin/master
to reduce surprises and improve usability. Before that change, a
refspec on the command line without a colon was only to fetch the
history and leave the result in FETCH_HEAD, without updating the
remote-tracking branches.
When you are simulating a fetch from you by your mothership with a
push by you into your mothership, instead of having:
[remote satellite]
fetch = +refs/heads/*:refs/remotes/satellite/*
on the mothership repository and running:
mothership$ git fetch satellite
you would have:
[remote mothership]
push = +refs/heads/*:refs/remotes/satellite/*
on your satellite machine, and run:
satellite$ git push mothership
Because we so far did not make the corresponding change to the push
side, this command:
satellite$ git push mothership master
does _not_ allow you on the satellite to only push 'master' out but
still to the usual destination (i.e. refs/remotes/satellite/master).
Implement the logic to map an unqualified refspec given on the
command line via the remote.$name.push refspec. This will bring a
bit more symmetry between fetch and push.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
Documentation/git-push.txt | 9 +++--
builtin/push.c | 40 ++--
remote.c | 8
remote.h | 2 ++
t/t5516-fetch-push.sh | 45 +
5 files changed, 96 insertions(+), 8 deletions(-)
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 9eec740..2b7f4f9 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -56,8 +56,13 @@ it can be any arbitrary SHA-1 expression, such as
`master~4` or
+
The dst tells which ref on the remote side is updated with this
push. Arbitrary expressions cannot be used here, an actual ref must
-be named. If `:`dst is omitted, the same ref as src will be
-updated.
+be named.
+If `git push [repository]` without any `refspec` argument is set to
+update some ref at the destination with `src` with
+`remote.repository.push` configuration variable, `:dst` part can
+be omitted---such a push will update a ref that `src` normally updates
+without any `refspec` on the command line. Otherwise, missing
+`:dst` means to update the same ref as the `src`.
+
The object referenced by src is used to update the dst reference
on the remote side. By default this is only allowed if dst is not
diff --git a/builtin/push.c b/builtin/push.c
index 76e4400..857f76d 100644
--- a/builtin/push.c
+++ b/builtin/push.c
@@ -35,9 +35,38 @@ static void add_refspec(const char *ref)
refspec[refspec_nr-1] = ref;
}
-static void set_refspecs(const char **refs, int nr)
+static const char *map_refspec(const char *ref,
+ struct remote *remote, struct ref *local_refs)
{
+ struct ref *matched = NULL;
+
+ /* Does ref uniquely name our ref? */
+ if (count_refspec_match(ref, local_refs, matched) != 1)
+ return ref;
+
+ if (remote-push) {
+ struct refspec query;
+ memset(query, 0, sizeof(struct refspec));
+ query.src = matched-name;
+ if (!query_refspecs(remote-push, remote-push_refspec_nr,
query)
+ query.dst) {
+ struct strbuf buf = STRBUF_INIT;
+ strbuf_addf(buf, %s%s:%s,
+ query.force ? + : ,
+ query.src, query.dst);
+ return strbuf_detach(buf, NULL);
+ }
+ }
+
+ return ref;
+}
+
+static void set_refspecs(const char **refs, int nr, const char *repo)
+{
+ struct remote *remote = NULL;
+ struct ref *local_refs = NULL;
int i;
+
for (i = 0; i nr; i++) {
const char *ref = refs[i];
if (!strcmp(tag, ref)) {
@@ -56,6 +85,13 @@ static void set_refspecs(const char **refs, int nr)
die(_(--delete only accepts plain target ref
names));
strbuf_addf(delref, :%s, ref);
ref = strbuf_detach(delref, NULL);
+ } else if (!strchr(ref, ':')) {
+ if (!remote) {
+ /* lazily grab remote and local_refs */
+ remote = remote_get(repo);
+
Thin pack
Hi, What are the difference between pre 1.8.5 and 1.8.5 about thin pack support? Could you describe thin pack? From the doc, it says --thin is default option. Is that true? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Dec 2013, #01; Wed, 4)
On Thu, Dec 5, 2013 at 8:23 AM, Junio C Hamano gits...@pobox.com wrote: * aa/transport-non-positive-depth-only (2013-11-26) 1 commit (merged to 'next' on 2013-11-27 at b01f05b) + transport: catch non positive --depth option value Will merge to 'master'. Don't. It breaks smart-http [1]. I'm starting to think catching this at fetch/clone level is probably better. But I need to add a test case to exercise this backfill_tags code in smart-http first. [1] http://thread.gmane.org/gmane.comp.version-control.git/238714/focus=238720 -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Use mongoose to test smart-http unconditionally?
On Wed, Dec 04, 2013 at 02:53:13PM -0800, Junio C Hamano wrote: If it involves making things not tested with apache, I'd actually be less supportive for the whole plan. I hadn't really considered that angle. Apache is a much more realistic real-world deployment. We give advice for it in git-http-backend(1), and the tests do check that that advice works (OTOH, we also give advice for lighttpd, but that is not checked in the test scripts). I thought the primary objective was to encourage people who currently are _not_ running httpd tests by making a lightweight server available out of the box, robbing an excuse my box does not have apache installed from them. Whether we get rid of apache or not, I think a new lightweight server would fulfill that goal. I just did not want the maintenance burden of managing multiple configs (and our test harness apache config has grown non-trivial). As long as a server supports bog standard CGI interface, smart-http should work the same way with any such server. For that reason, it should be theoretically sufficient to test with one non-apache server (i.e. mongoose) for the purpose of making sure _our_ end of the set-up works, but still... There are definitely subtleties between servers. For example, when I worked on fetching bundles over http a while back, there was a big difference between lighttpd and apache. A request for http://example.com/foo.bundle/info/refs; would return the bundle under lighttpd, but not under apache (for an apache server, we would have to make a fallback request). The client needs to be able to handle both scenarios gracefully. That's a case where it would be nice to be able to test _both_ cases, and that may be an argument for having multiple (or trying to configure apache to do both behaviors). But it shows that there may be subtle differences between a fake test server and a real deployment. So thinking on it more, I'm somewhat less enthusiastic about mongoose. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Additional git-archive tests
Interplay between paths specified in three ways now tested: * After a : in the tree-ish, * As a pathspec in the command, * By virtue of the current working directory Note that these tests are based on the behaviours as found in 1.8.5. They may not be intentional. They were developed to regression test enhancements made to parse_treeish_arg() in archive.c Helped-by: Eric Sunshine sunsh...@sunshineco.com Signed-off-by: Nick Townsend nick.towns...@mac.com --- t/t5004-archive-corner-cases.sh | 71 + 1 file changed, 71 insertions(+) diff --git a/t/t5004-archive-corner-cases.sh b/t/t5004-archive-corner-cases.sh index 67f3b54..a81a836 100755 --- a/t/t5004-archive-corner-cases.sh +++ b/t/t5004-archive-corner-cases.sh @@ -113,4 +113,75 @@ test_expect_success 'archive empty subtree by direct pathspec' ' check_dir extract sub ' +test_expect_success 'setup - repository with subdirs' ' + mkdir -p a/b/c a/b/d + echo af a/af + echo bf a/b/bf + echo cf a/b/c/cf + git add a + git commit -m commit 1 + git tag -a -m rev-1 rev-1 +' + +test_expect_success 'archive subtree from root by treeish' ' + git archive --format=tar HEAD:a atreeroot.tar + make_dir extract + $TAR xf atreeroot.tar -C extract + check_dir extract af b b/bf b/c b/c/cf +' + +test_expect_success 'archive subtree from root with pathspec' ' + git archive --format=tar HEAD a atreepath.tar + make_dir extract + $TAR xf atreepath.tar -C extract + check_dir extract a a/af a/b a/b/bf a/b/c a/b/c/cf +' + +test_expect_success 'archive subtree from root by 2-level treeish' ' + git archive --format=tar HEAD:a/b abtreeroot.tar + make_dir extract + $TAR xf abtreeroot.tar -C extract + check_dir extract bf c c/cf +' + +test_expect_success 'archive subtree from subdir' ' + ( + cd a + git archive --format=tar HEAD ../asubtree.tar + ) + make_dir extract + $TAR xf asubtree.tar -C extract + check_dir extract af b b/bf b/c b/c/cf +' + +test_expect_success 'archive subtree from subdir with treeish' ' + ( + cd a + git archive --format=tar HEAD:./b ../absubtree.tar + ) + make_dir extract + $TAR xf absubtree.tar -C extract + check_dir extract bf c c/cf +' + +test_expect_success 'archive subtree from subdir with treeish and pathspec' ' + ( + cd a + git archive --format=tar HEAD:./b c ../absubtree.tar + ) + make_dir extract + $TAR xf absubtree.tar -C extract + check_dir extract c c/cf +' + +test_expect_success 'archive subtree from subdir with alt treeish' ' + ( + cd a + git archive --format=tar HEAD:b ../abxsubtree.tar + ) + make_dir extract + $TAR xf abxsubtree.tar -C extract + check_dir extract bf c c/cf +' + test_done -- 1.8.5 On 3 Dec 2013, at 09:54, Junio C Hamano gits...@pobox.com wrote: Eric Sunshine sunsh...@sunshineco.com writes: +test_expect_success 'archive subtree from subdir' ' + cd a + git archive --format=tar HEAD ../asubtree.tar + cd .. + make_dir extract + $TAR xf asubtree.tar -C extract + check_dir extract af b b/bf b/c b/c/cf +' If git-archive fails, the subsequent 'cd ..' will not be invoked, hence all tests following this one will fail since the current directory has not been restored. If you place the 'cd a' in a subshell, then the current directory remains unchanged for commands outside the subshell (and you can drop the 'cd ..'): ( cd a git archive ... ) make_dir ... ... Thanks, and please indent the commands run in the subshell for better readability. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Use mongoose to test smart-http unconditionally?
On Wed, Dec 04, 2013 at 03:28:00PM -0800, Jonathan Nieder wrote: For what it's worth, when I build git and run tests I tend to be in an environment with apache available, but I'm too lazy to configure git's tests to pick the right port and make sure it is reserved and so on. Perhaps there's some way to help lazy people in the same boat? (E.g., picking a port randomly and skipping instead of failing a test when it's taken or something) What level of magic do you need? For most people, apt-get install apache make GIT_TEST_HTTPD=yes test is enough to run the tests. It uses ports in the 5000-range; this _can_ conflict with other services the user is running, but it should not usually (we don't match anything in a typical /etc/services file). And each script uses its own port, so running the tests in parallel is fine. If you are planning on running make test from multiple git checkouts at the same time, though, they will conflict. The failure mode is reasonable. You should get something like: $ GIT_TEST_HTTPD=1 LIB_HTTPD_PORT=80 ./t5540-http-push.sh 1..0 # SKIP skipping test, web server setup failed We could do better by retrying with a range of ports, but unless somebody really needs that, I'd prefer to avoid complicating it more. The one thing I have occasionally run into is a stale apache hanging around. But I think that only happens when I am abusing the test script (e.g., sticking a test_pause in, poking around, and then not letting the script complete and do its cleanup). So is the current behavior good enough to meet your needs and you didn't know it, or do we need more? -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] clone,fetch: catch non positive --depth option value
Instead of simply ignoring the value passed to --depth option when
it is zero or negative, catch and report it as an error to let
people know that they were using the option incorrectly.
Original-patch-by: Andrés G. Aragoneses kno...@gmail.com
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
This replaces aa/transport-non-positive-depth-only
builtin/clone.c | 4
builtin/fetch.c | 4
2 files changed, 8 insertions(+)
diff --git a/builtin/clone.c b/builtin/clone.c
index 552f340..535b52f 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -797,6 +797,10 @@ int cmd_clone(int argc, const char **argv, const char
*prefix)
if (option_local 0 !is_local)
warning(_(--local is ignored));
+ /* no need to be strict, transport_set_option() will validate it again
*/
+ if (option_depth atoi(option_depth) 1)
+ die(_(depth %s is not a positive number), option_depth);
+
if (argc == 2)
dir = xstrdup(argv[1]);
else
diff --git a/builtin/fetch.c b/builtin/fetch.c
index 2496ad2..ed399eb 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -1047,6 +1047,10 @@ int cmd_fetch(int argc, const char **argv, const char
*prefix)
}
}
+ /* no need to be strict, transport_set_option() will validate it again
*/
+ if (depth atoi(depth) 1)
+ die(_(depth %s is not a positive number), depth);
+
if (recurse_submodules != RECURSE_SUBMODULES_OFF) {
if (recurse_submodules_default) {
int arg =
parse_fetch_recurse_submodules_arg(--recurse-submodules-default,
recurse_submodules_default);
--
1.8.5.1.25.g8667982
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] t5551: test fetch.c:backfill_tags() code
This makes sure the second fetch with transport helper code path is
exercised in the test suite.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
This should catch the problem by aa/transport-non-positive-depth-only.
The GIT_TEST_BACKFILL_TAGS is bad but I don't know any sure way to
verify it, assuming the shallow code may change in future and stop
triggering backfill_tags().
builtin/fetch.c | 2 ++
t/t5551-http-fetch.sh | 16
2 files changed, 18 insertions(+)
diff --git a/builtin/fetch.c b/builtin/fetch.c
index 5647055..2496ad2 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -750,6 +750,8 @@ static struct transport *prepare_transport(struct remote
*remote)
static void backfill_tags(struct transport *transport, struct ref *ref_map)
{
+ if (getenv(GIT_TEST_BACKFILL_TAGS))
+ fprintf(stderr, backfill_tags executed\n);
if (transport-cannot_reuse) {
gsecondary = prepare_transport(transport-remote);
transport = gsecondary;
diff --git a/t/t5551-http-fetch.sh b/t/t5551-http-fetch.sh
index 1b71bb5..7eeb043 100755
--- a/t/t5551-http-fetch.sh
+++ b/t/t5551-http-fetch.sh
@@ -181,6 +181,22 @@ test_expect_success 'create namespaced refs' '
symbolic-ref refs/namespaces/ns/HEAD
refs/namespaces/ns/refs/heads/master
'
+test_expect_success 'trigger backfill_tags() over smart-http' '
+ git tag -m two tag-two
+ echo content file
+ git commit -a -m three
+ git push public master tag-two
+ git rev-parse master tag-two expected
+ (
+ git init shallow
+ cd shallow
+ GIT_TEST_BACKFILL_TAGS=1 git fetch --depth=2 $HTTPD_URL/smart/repo.git
master:foo 2err
+ grep backfill_tags executed err
+ git rev-parse foo tag-two ../actual
+ )
+ test_cmp expected actual
+'
+
test_expect_success 'smart clone respects namespace' '
git clone $HTTPD_URL/smart_namespace/repo.git ns-smart
echo namespaced expect
--
1.8.5.1.25.g8667982
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Thin pack
On Thu, Dec 5, 2013 at 8:44 AM, 乙酸鋰 ch3co...@gmail.com wrote: What are the difference between pre 1.8.5 and 1.8.5 about thin pack support? No idea. Could you describe thin pack? It gets a bit technical. Under the hood objects are deltified, only the differences between an object and its base are stored. If both the diff and the base are in a pack, it's a normal pack. If the pack lacks the base, it's thin. This makes thin packs more suited for network transfer because you transfer much less. Imagine you have a 5k file, you fetch another version of the same file that changes 1 line. With thin pack, you receive just that line (not entirely true, but good enough). Without thin pack, you also receive the 5k file you already have because it's the base of the new version. From the doc, it says --thin is default option. Is that true? Yes. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to resume broke clone ?
On Wed, Dec 4, 2013 at 12:08 PM, Jeff King p...@peff.net wrote: On Thu, Nov 28, 2013 at 11:15:27AM -0800, Shawn Pearce wrote: - better integration with git bundles, provide a way to seamlessly create/fetch/resume the bundles with git clone and git fetch We have been thinking about formalizing the /clone.bundle hack used by repo on Android. If the server has the bundle, add a capability in the refs advertisement saying its available, and the clone client can first fetch $URL/clone.bundle. Yes, that was going to be my next step after getting the bundle fetch support in. Yay! If we are going to do this, though, I'd really love for it to not be hey, fetch .../clone.bundle from me, but a full-fledged here are full URLs of my mirrors. Ack. I agree completely. Then you can redirect a non-http cloner to http to grab the bundle. Or redirect them to a CDN. Or even somebody else's server entirely (e.g., go fetch from Linus first, my piddly server cannot feed you the whole kernel). Some of the redirects you can do by issuing an http redirect to /clone.bundle, but the cross-protocol ones are tricky. Ack. My thoughts exactly. Especially the part of my piddly server shouldn't have to serve you a clone of Linus' tree when there are many public hosts mirroring his code available to anyone. It is simply not fair to clone Linus' tree off some guy's home ADSL connection, his uplink probably sucks. But it is reasonable to fetch his incremental delta after cloning from some other well known and well connected source. If we advertise it as a blob in a specialized ref (e.g., refs/mirrors) it does not add much overhead over a simple capability. There are a few extra round trips to actually fetch the blob (client sends a want and no haves, then server sends the pack), but I think that's negligible when we are talking about redirecting a full clone. In either case, we have to hang up the original connection, fetch the mirror, and then come back. I wasn't thinking about using a well known blob for this. Jonathan, Dave, Colby and I were kicking this idea around on Monday during lunch. If the initial ref advertisement included a mirrors capability the client could respond with want mirrors instead of the usual want/have negotiation. The server could then return the mirror URLs as pkt-lines, one per pkt. Its one extra RTT, but this is trivial compared to the cost to really clone the repository. These pkt-lines need to be a bit more than just URL. Or we need a new URL like bundle:http://; to denote a resumable bundle over HTTP vs. a normal HTTP URL that might not be a bundle file, and is just a better connected server. The mirror URLs could be stored in $GIT_DIR/config as a simple multi-value variable. Unfortunately that isn't easily remotely editable. But I am not sure I care? GitHub doesn't let you edit $GIT_DIR/config, but it doesn't need to. For most repositories hosted at GitHub, GitHub is probably the best connected server for that repository. For repositories that are incredibly high traffic GitHub might out of its own interest want to configure mirror URLs on some sort of CDN to distribute the network traffic closer to the edges. Repository owners just shouldn't have to worry about these sorts of details. It should be managed by the hosting service. In my case for android.googlesource.com we want bundles on the CDN near the network edges, and our repository owners don't care to know the details of that. They just want our server software to make it all happen, and our servers already manage $GIT_DIR/config for them. It also mostly manages /clone.bundle on the CDN. And /clone.bundle is an ugly, limited hack. For the average home user sharing their working repository over git:// from their home ADSL or cable connection, editing .git/config is easier than a blob in refs/mirrors. They already know how to edit .git/config to manage remotes. Heck, remote.origin.url might already be a good mirror address to advertise, especially if the client isn't on the same /24 as the server and the remote.origin.url is something like git.kernel.org. :-) For most Git repositories the bundle can be constructed by saving the bundle reference header into a file, e.g. $GIT_DIR/objects/pack/pack-$NAME.bh at the same time the pack is created. The bundle can be served by combining the .bh and .pack streams onto the network. It is very little additional disk overhead for the origin server, That's clever. It does not work out of the box if you are using alternates, but I think it could be adapted in certain situations. E.g., if you layer the pack so that one base repo always has its full pack at the start, which is something we're already doing at GitHub. Yes, well, I was assuming the pack was a fully connected repack. Alternates always creates a partial pack. But if you have an alternate, that alternate maybe should be given as a mirror URL? And allow the client to recurse the alternate mirror URL
Re: Build issue for git 1.8.5.1 under Mac OS X 10.8 (Mountain Lion)
On 12/04/2013 07:48 PM, Marius Schamschula wrote: Hi all, Over the years I have built many versions of git and released them on hmug.org. git 1.8.5.1 builds just fine under OS 10.7 (Lion) and 10.9 (Mavericks), but the build fails (also for 1.8.5) on 10.8 (Mountain Lion): snip GIT_VERSION = 1.8.5.1 * new build flags CC credential-store.o In file included from git-compat-util.h:330:0, from cache.h:4, from credential-store.c:1: compat/apple-common-crypto.h: In function 'git_CC_EVP_EncodeBlock': compat/apple-common-crypto.h:32:2: error: 'SecTransformRef' undeclared (first use in this function) compat/apple-common-crypto.h:32:2: note: each undeclared identifier is reported only once for each function it appears in compat/apple-common-crypto.h:32:18: error: expected ';' before 'encoder' compat/apple-common-crypto.h:36:2: error: 'encoder' undeclared (first use in this function) compat/apple-common-crypto.h:36:2: warning: implicit declaration of function 'SecEncodeTransformCreate' compat/apple-common-crypto.h:36:37: error: 'kSecBase64Encoding' undeclared (first use in this function) compat/apple-common-crypto.h:40:2: warning: implicit declaration of function 'SecTransformSetAttribute' compat/apple-common-crypto.h:40:36: error: 'kSecTransformInputAttributeName' undeclared (first use in this function) compat/apple-common-crypto.h:44:2: warning: implicit declaration of function 'SecTransformExecute' compat/apple-common-crypto.h: In function 'git_CC_EVP_DecodeBlock': compat/apple-common-crypto.h:62:2: error: 'SecTransformRef' undeclared (first use in this function) compat/apple-common-crypto.h:62:18: error: expected ';' before 'decoder' compat/apple-common-crypto.h:66:2: error: 'decoder' undeclared (first use in this function) compat/apple-common-crypto.h:66:2: warning: implicit declaration of function 'SecDecodeTransformCreate' compat/apple-common-crypto.h:66:37: error: 'kSecBase64Encoding' undeclared (first use in this function) compat/apple-common-crypto.h:70:36: error: 'kSecTransformInputAttributeName' undeclared (first use in this function) Makefile:1975: recipe for target 'credential-store.o' failed make: *** [credential-store.o] Error 1 /snip Apparently a header issue: I tried force feeding the Security/SecEncryptTransform.h file, and just got an other error… Any help would be welcome! Thanks in advance. Marius -- Marius Schamschula I can't reproduce it here (in other words, it compiles) What could help is to run the preprocessor, and see what the compiler see. a) Patch the Makefile of git like this: -- a/Makefile +++ b/Makefile @@ -349,7 +349,8 @@ GIT-VERSION-FILE: FORCE # CFLAGS and LDFLAGS are for the users to override from the command line. -CFLAGS = -g -O2 -Wall +#CFLAGS = -g -O2 -Wall +CFLAGS= -E b) Compile credential-store.o (Which is now an ASCII file) credential-store.o ; make credential-store.o c) Take an editor and have a look. On my system SecTransform.h is here: - /System/Library/Frameworks/Security.framework/Headers/SecTransform.h d) And the file contains something like this: --- typedef CFTypeRef SecTransformRef; typedef CFTypeRef SecGroupTransformRef; /Torsten -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: [PATCH 4/5] Replace {pre,suf}fixcmp() with {starts,ends}_with()
On Wed, Dec 4, 2013 at 11:02 PM, Junio C Hamano gits...@pobox.com wrote: Junio C Hamano gits...@pobox.com writes: Christian Couder christian.cou...@gmail.com writes: Ok, the commit is in the use_starts_ends_with branch on this github repo: https://github.com/chriscool/git.git I looked at the patches, and they looked alright. The endgame needs to be on a separate topic to be held until a distant future, though. Will queue. Thanks. Great! It turns out that, naturally, there are many new uses of prefixcmp in the topics in flight. I can manage, but adjusting all of them would not look too pretty X-. Tell me if I can do something. I can prepare patches for the topics in flight in 'next' for example. Thanks, Christian. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Dec 2013, #01; Wed, 4)
On Thu, Dec 5, 2013 at 2:23 AM, Junio C Hamano gits...@pobox.com wrote:
* cc/starts-n-ends-with (2013-12-04) 4 commits
- replace {pre,suf}fixcmp() with {starts,ends}_with()
- strbuf: introduce starts_with() and ends_with()
- builtin/remote: remove postfixcmp() and use suffixcmp() instead
- environment: normalize use of prefixcmp() by removing != 0
(this branch is used by cc/starts-n-ends-with-endgame.)
Remove a few duplicate implementations of prefix/suffix comparison
functions, and rename them to starts_with and ends_with.
This conflicts with a part of cc/remote-remove-redundant-postfixcmp
topic (I think it actually subsumes it).
Yeah, it subsumes it.
Thanks,
Christian.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
