Git development
 help / color / mirror / Atom feed
* Re: What's cooking in gitweb (20 Sep 2008)
From: Giuseppe Bilotta @ 2008-09-22 16:51 UTC (permalink / raw)
  To: Jakub Narebski; +Cc: git, Lea Wiemann
In-Reply-To: <200809221443.38689.jnareb@gmail.com>

On Mon, Sep 22, 2008 at 2:43 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> Giuseppe Bilotta wrote:
>>
>> I'll resend the whole series (plus an additional patch to fix an
>> aesthetical issue I found recently) as soon as I fix the url
>> generation for the dotted filename corner case (which by re-reading
>> the past emails seemed to be the only significant issue, correct?).
>
> I think it was the only significant issue (besides the fact that
> two mentioned patches could be in separate series).  To be more
> exact the issue was with generating gitweb URLs for sets of
> parameters which cannot be represented as path_info URL.  One
> example was filename with '..' in it, which cannot be used in
> the following path_info form:
>  $hash_parent_base:$file_parent..$hash_base:$filename
> but it can be used in 'no name change' form
>  $hash_parent_base..$hash_base:$filename
> This requires fallback to 'query' form URL.

This is fixed in the resend.

> Other example was branch name with the same name as one of gitweb
> actions, which require action to be stated explicitly even if it
> is default action and otherwise could be omitted.

Generated urls now _always_ contain the action

>> > 2. "[PATCH] gitweb: shortlog now also obeys $hash_parent"
>> > by Giuseppe Bilotta
> [...]
>> > More important fact is that I'd very much like for _all_ log-like
>> > views (perhaps with exception of feeds: Atom and RSS) to implement
>> > this feature.  This could be done by either doing it all in the same
>> > commit, doing commit series changing 'shortlog', 'log' and 'history'
>> > separately, or what I would prefer actually, to refactor generation
>> > of log-like views to use single worker/engine subroutine.
>>
>> I agree that refactoring is probably the best idea. It will also take
>> me some more time ;)
>
> But it has the advantage of making it easier to add more log-like
> views, like 'log' like view for the 'history' view, i.e. --pretty=full
> like view with path limiting.
>
> I have thought about doing the refactoring (it is/was on my long-term
> TODO list for gitweb), but I haven't even found good way to code it,
> to be flexible but not too generalized.  Callbacks, perhaps?

Actually, the only reason I mentioned it would take time was to
explain why _that_ patch wouldn't be resent 'shortly' by me. I need to
study the log/shortlog/history code better to get an idea of what
might be a good refactoring strategy :)


-- 
Giuseppe "Oblomov" Bilotta

^ permalink raw reply

* Re: [PATCH v2 4/4] diff.c: convert builtin funcname patterns to non-GNU extended regex syntax
From: Brandon Casey @ 2008-09-22 16:59 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmyi21mf8.fsf@gitster.siamese.dyndns.org>

Junio C Hamano wrote:
> Brandon Casey <drafnel@gmail.com> writes:
> 
>> Junio C Hamano <gitster <at> pobox.com> writes:
>>
>>> Here is [1/2] to be applied on top of 45d9414 (diff.*.xfuncname which uses
>>> "extended" regex's for hunk header selection, 2008-09-18).
>>>
>>> Testing appreciated.
>>> +	{ "bibtex", "(@[a-zA-Z]{1,}[ \t]*\{{0,1}[ \t]*[^ \t\"@',\\#}{~%]*).*$",
>>> +	  REG_EXTENDED },
>>> +	{ "tex",
>>> +	  "^(\\\\((sub)*section|chapter|part)\\*{0,1}\{.*)$",
>> I think you need double backslash '\\' before '{' in the two places in these
>> patterns where you only have a single backslash.
> 
> Thanks.  Any other nits?

Just a single minor one on the "fix multiple regexp semantics" patch.

This:

 	for (i = 0; i < regs->nr; i++) {
		...
	}
+	if (regs->nr <= i)

makes me use my brain (I try to avoid that).

I only mention it since I've seen discussions in the past about this sort
of ordering, and you seem to have accepted that it can be confusing to
native english speakers who would "read" the 'if' statement. The ordering
above puts emphasis on the value of regs->nr, when it is actually the value
of 'i' that is being tested (since regs->nr is unchanging).

I'll do some testing on non-GNU platforms today.

-brandon

^ permalink raw reply

* [PATCH] Do not perform cross-directory renames when creating packs
From: Petr Baudis @ 2008-09-22 17:20 UTC (permalink / raw)
  To: git, git; +Cc: gitster

A comment on top of create_tmpfile() describes caveats ('can have
problems on various systems (FAT, NFS, Coda)') that should apply
in this situation as well.  This in the end did not end up solving
any of my personal problems, but it might be a useful cleanup patch
nevertheless.

Signed-off-by: Petr Baudis <pasky@suse.cz>

---

If this one gets dropped now, I don't intend pursuing it further.

 builtin-pack-objects.c |    2 +-
 fast-import.c          |    4 ++--
 index-pack.c           |    2 +-
 pack-write.c           |    2 +-
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 5fc1b8c..1158e42 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -465,7 +465,7 @@ static void write_pack_file(void)
 			char tmpname[PATH_MAX];
 			int fd;
 			snprintf(tmpname, sizeof(tmpname),
-				 "%s/tmp_pack_XXXXXX", get_object_directory());
+				 "%s/pack/tmp_pack_XXXXXX", get_object_directory());
 			fd = xmkstemp(tmpname);
 			pack_tmp_name = xstrdup(tmpname);
 			f = sha1fd(fd, pack_tmp_name);
diff --git a/fast-import.c b/fast-import.c
index ccdf2e5..ab6689a 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -816,7 +816,7 @@ static void start_packfile(void)
 	int pack_fd;
 
 	snprintf(tmpfile, sizeof(tmpfile),
-		"%s/tmp_pack_XXXXXX", get_object_directory());
+		"%s/pack/tmp_pack_XXXXXX", get_object_directory());
 	pack_fd = xmkstemp(tmpfile);
 	p = xcalloc(1, sizeof(*p) + strlen(tmpfile) + 2);
 	strcpy(p->pack_name, tmpfile);
@@ -878,7 +878,7 @@ static char *create_index(void)
 	}
 
 	snprintf(tmpfile, sizeof(tmpfile),
-		"%s/tmp_idx_XXXXXX", get_object_directory());
+		"%s/pack/tmp_idx_XXXXXX", get_object_directory());
 	idx_fd = xmkstemp(tmpfile);
 	f = sha1fd(idx_fd, tmpfile);
 	sha1write(f, array, 256 * sizeof(int));
diff --git a/index-pack.c b/index-pack.c
index a6e91fe..530d820 100644
--- a/index-pack.c
+++ b/index-pack.c
@@ -172,7 +172,7 @@ static char *open_pack_file(char *pack_name)
 		if (!pack_name) {
 			static char tmpfile[PATH_MAX];
 			snprintf(tmpfile, sizeof(tmpfile),
-				 "%s/tmp_pack_XXXXXX", get_object_directory());
+				 "%s/pack/tmp_pack_XXXXXX", get_object_directory());
 			output_fd = xmkstemp(tmpfile);
 			pack_name = xstrdup(tmpfile);
 		} else
diff --git a/pack-write.c b/pack-write.c
index 939ed56..3621f1d 100644
--- a/pack-write.c
+++ b/pack-write.c
@@ -45,7 +45,7 @@ char *write_idx_file(char *index_name, struct pack_idx_entry **objects,
 	if (!index_name) {
 		static char tmpfile[PATH_MAX];
 		snprintf(tmpfile, sizeof(tmpfile),
-			 "%s/tmp_idx_XXXXXX", get_object_directory());
+			 "%s/pack/tmp_idx_XXXXXX", get_object_directory());
 		fd = xmkstemp(tmpfile);
 		index_name = xstrdup(tmpfile);
 	} else {
-- 
tg: (fe33b33..) t/pack/crossdir (depends on: vanilla/master)

^ permalink raw reply related

* [PATCH] Do not rename read-only files during a push
From: Petr Baudis @ 2008-09-22 17:20 UTC (permalink / raw)
  To: git, git; +Cc: gitster

Win32 does not allow renaming read-only files (at least on a Samba
share), making push into a local directory to fail. Thus, defer
the chmod() call in index-pack.c:final() only after
move_temp_to_file() was called.

Signed-off-by: Petr Baudis <pasky@suse.cz>

---
 index-pack.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/index-pack.c b/index-pack.c
index a6e91fe..2af72d6 100644
--- a/index-pack.c
+++ b/index-pack.c
@@ -786,7 +786,6 @@ static void final(const char *final_pack_name, const char *curr_pack_name,
 		err = close(output_fd);
 		if (err)
 			die("error while closing pack file: %s", strerror(errno));
-		chmod(curr_pack_name, 0444);
 	}
 
 	if (keep_msg) {
@@ -820,8 +819,8 @@ static void final(const char *final_pack_name, const char *curr_pack_name,
 		if (move_temp_to_file(curr_pack_name, final_pack_name))
 			die("cannot store pack file");
 	}
+	chmod(final_pack_name, 0444);
 
-	chmod(curr_index_name, 0444);
 	if (final_index_name != curr_index_name) {
 		if (!final_index_name) {
 			snprintf(name, sizeof(name), "%s/pack/pack-%s.idx",
@@ -831,6 +830,7 @@ static void final(const char *final_pack_name, const char *curr_pack_name,
 		if (move_temp_to_file(curr_index_name, final_index_name))
 			die("cannot store index file");
 	}
+	chmod(final_index_name, 0444);
 
 	if (!from_stdin) {
 		printf("%s\n", sha1_to_hex(sha1));
-- 
tg: (fe33b33..) t/pack/rdonly (depends on: vanilla/master)

^ permalink raw reply related

* Re: [PATCH] Do not perform cross-directory renames when creating packs
From: Linus Torvalds @ 2008-09-22 17:31 UTC (permalink / raw)
  To: Petr Baudis; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <1222104021-28277-1-git-send-email-pasky@suse.cz>



On Mon, 22 Sep 2008, Petr Baudis wrote:
>
> A comment on top of create_tmpfile() describes caveats ('can have
> problems on various systems (FAT, NFS, Coda)') that should apply
> in this situation as well.  This in the end did not end up solving
> any of my personal problems, but it might be a useful cleanup patch
> nevertheless.

Side note: the cross-directory avoidance for loose object creation _did_ 
seem to clear up the original problems reported on NFS, so yes, this is 
worth doing. Even if pack-file creation is such a heavy event that I 
suspect that none of the timing/caching/whatever issues that were present 
for loose objects really ever trigger in practice.

> Signed-off-by: Petr Baudis <pasky@suse.cz>

Looks obvious enough. So:

Acked-by: Linus Torvalds <torvalds@linux-foundation.org>

		Linus

^ permalink raw reply

* Re: [TopGit PATCH] prev/next/tsort: commands to explore dependencies
From: Bert Wesarg @ 2008-09-22 17:32 UTC (permalink / raw)
  To: Petr Baudis; +Cc: git
In-Reply-To: <20080922153614.GO10360@machine.or.cz>

On Mon, Sep 22, 2008 at 17:36, Petr Baudis <pasky@suse.cz> wrote:
>  Hi,
>
> On Fri, Sep 19, 2008 at 11:55:00AM +0200, Bert Wesarg wrote:
>> I hacked 3 commands to explore the dependencies of TopGit patches:
>
>  thanks, the idea of all three commands is good,
>
>>   I) tg prev [NAME]
>>      outputs the dependencies of NAME
>>
>>  II) tg next [NAME]
>>      outputs patches that depends on NAME
>
>  but I think it would be cleaner to add this functionality to
> tg info...
Right, but 'tg next' is shorter than any 'tg info --next'.

>
>> III) tg tsort [PATTERN]
>>      outputs a topological order of all patches starting with PATTERN
>
> ...and tg summary (overally, to have a tree view of branches).
Maybe something like the graph output from git rev-log --graph?

>> +                                     printf "%s\t%q\n" "${dep_rev}" "${dep}" >&3
>> +                                     printf "%s\t%s\n" "${topic_rev}" "${dep_rev}"
>
> %q?

"and %q causes printf to output the corresponding argument in  a
format that can be reused as shell input."

I thought that this would be needed.

Bert
>
> --
>                                Petr "Pasky" Baudis

^ permalink raw reply

* Re: ignoring files/directories in git
From: Alex Riesen @ 2008-09-21 17:20 UTC (permalink / raw)
  To: mwolfe38; +Cc: git
In-Reply-To: <19596152.post@talk.nabble.com>

mwolfe38, Sun, Sep 21, 2008 18:54:01 +0200:
> In my project I have several directories I do not want to have git ignore.
> One of them being
> cache/ and the other log/
> I've added them to the .gitignore file which I have in the initial directory
> of the repository
> The contents of my gitignore are:
> 
> .settings
> .cache
> cache/
> log/
> .project
> 
> However, if I do 
> git add .
> It will add the files from cache and log anyways.
> I know git add . will add anything that hasn't been added but shouldn't it
> ignore files in .gitignore?

It should and indeed it does ignore them:

    $ mkdir ggg && cd ggg
    $ git init
    Initialized empty Git repository in /tmp/ggg/.git/
    $ >a
    $ mkdir cache log
    $ touch cache/b
    $ touch log/c
    $ echo cache/ >.gitignore
    $ echo log/ >>.gitignore
    $ cat .gitignore
    cache
    log
    $ git add .
    $ git ls-files
    .gitignore
    a

What is your git version and where have you got it from?
Is your .gitignore written exactly like this (case, some hidden
extension, like they do on Windows)? Any invisible characters in
.gitignore?

^ permalink raw reply

* Re: [funny] "git checkout -t origin/xyzzy" seems to misbehave
From: Alex Riesen @ 2008-09-21 17:44 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git, Johannes Schindelin, Daniel Barkalow
In-Reply-To: <7v1vzd29i3.fsf@gitster.siamese.dyndns.org>

Junio C Hamano, Sun, Sep 21, 2008 10:23:00 +0200:
> When you
> 
>  * are on a branch "foo" that is not "bar",
>  * have "origin/bar",
>  * and already have a local branch "bar",
> 
> "git checkout -t origin/bar" seems to misbehave.
> 
>     $ git clone -s git.junio victim-002
>     $ cd victim-002
>     $ git branch
>     * master
>     $ git checkout -t origin/next
>     Branch next set up to track remote branch refs/remotes/origin/next.
>     Switched to a new branch "next"
>     $ git checkout -t origin/master
>     fatal: A branch named 'master' already exists.
>     $ git branch
>       master
>     * next
>     $ git diff --cached --shortstat
>      60 files changed, 2378 insertions(+), 3412 deletions(-)
>     $ git diff --cached master
>     $ exit
> 
> The first "checkout -t" is fine.  The failed one seems to have already
> updated the index and the work tree when it notices that it cannot create
> a new branch.

Precisely this (branch already exists) case is easy to handle with a
resolve_ref in builtin-checkout.c:switch_branches.

The other errors will still leave index and working tree in this
state: branch.c:create_branch does not cleanup in case of errors,
it just dies.

^ permalink raw reply

* Re: [PATCH 1/3] for-each-ref: utilize core.warnambiguousrefs for strict refname:short format
From: Bert Wesarg @ 2008-09-22 18:00 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git, szeder, Shawn O. Pearce
In-Reply-To: <7vk5d4xi1m.fsf@gitster.siamese.dyndns.org>

On Mon, Sep 22, 2008 at 18:27, Junio C Hamano <gitster@pobox.com> wrote:
> Bert Wesarg <bert.wesarg@googlemail.com> writes:
>
>> diff --git a/builtin-for-each-ref.c b/builtin-for-each-ref.c
>> index 9b44092..e7b7712 100644
>> --- a/builtin-for-each-ref.c
>> +++ b/builtin-for-each-ref.c
>> @@ -571,7 +571,7 @@ static void gen_scanf_fmt(char *scanf_fmt, const char *rule)
>>  /*
>>   * Shorten the refname to an non-ambiguous form
>>   */
>> -static char *get_short_ref(struct refinfo *ref)
>> +static void get_short_ref(struct refinfo *ref, int strict, char **short_ref)
>>  {
>>       int i;
>>       static char **scanf_fmts;
>
> As far as I can tell this changing of function signature does not help its
> existing caller nor the function's implementation.
>
> Why?  And especially why do this in a patch that does something else?
Good point.  I think it had something to do that I first want a
reverse of dwim_ref().  And this has this 'char **' argument.  Than I
changed it back to the old signature which makes this line:

-                                       refname = get_short_ref(ref);
+                                       refname = get_short_ref(ref,
warn_ambiguous_refs);

unbreakable or screams for an out factoring of all inside the 'if
(!prefixcmp(name, "refname")) {'

I would prefer the out factory.

Bert

^ permalink raw reply

* Re: [TopGit PATCH] tg-patch: add From/Date: line to header and print to file
From: Bert Wesarg @ 2008-09-22 18:10 UTC (permalink / raw)
  To: Petr Baudis; +Cc: git
In-Reply-To: <20080922153938.GP10360@machine.or.cz>

On Mon, Sep 22, 2008 at 17:39, Petr Baudis <pasky@suse.cz> wrote:
> On Fri, Sep 19, 2008 at 11:55:01AM +0200, Bert Wesarg wrote:
>> To make this more similar to git format-patch, I added a 'From' and
>> a 'Date:' header and let 'tg patch' print to a file (which is shown as output).
>>
>> Regards
>> Bert
>>
>> Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
>
> I dislike the anyway completely bogus From line. If you want mbox
> format, you should call (hypothetical) tg mail. Also, IMHO Date: should
> be simply always printed at the end of the header, it's distracting if
> it is higher.
>
> Also, the writing to file is confusing to me. What are you trying to
> achieve? If you want to export patches, why not use 'tg export' which
> already has this functionality? To me, 'tg patch' is basically
> equivalent of 'git show' for the whole branch.

You're right. I'm not familiar what is needed as a header to be used
with git send-email.

But the additional indirection with tg export/git format-patch is
overkill for one patch.

Therefore I would leave the writing to file, but drop the additional
headers for me.

Bert
>
> --
>                                Petr "Pasky" Baudis

^ permalink raw reply

* Re: clone fails: Could not get the current working directory
From: John Freeman @ 2008-09-22 18:32 UTC (permalink / raw)
  To: Paul Johnston, git
In-Reply-To: <48D6C822.7050602@cs.tamu.edu>

I have also tried copying the repo to my home directory on the remote 
Sun machine, and then cloning to my local machine.  This works as expected.

Does anyone know why a call to getcwd() would fail?

I found this in some documentation on getcwd:
http://www.opengroup.org/onlinepubs/009695399/functions/getcwd.html
"If a program is operating in a directory where some (grand)parent 
directory does not permit reading, getcwd() may fail, as in most 
implementations it must read the directory to determine the name of the 
file. This can occur if search, but not read, permission is granted in 
an intermediate directory, or if the program is placed in that directory 
by some more privileged process (for example, login). Including the 
[EACCES] error condition makes the reporting of the error consistent and 
warns the application writer that getcwd() can fail for reasons beyond 
the control of the application writer or user. Some implementations can 
avoid this occurrence (for example, by implementing getcwd() using pwd, 
where pwd is a set-user-root process), thus the error was made optional."

Does anyone know for certain if this is true for Sun machines?  Would it 
be possible to patch / introduce a macro that changes the use of 
getcwd() to a use of pwd, like the above documentation suggests?

- John

^ permalink raw reply

* Re: ignoring files/directories in git
From: Tim Harper @ 2008-09-22 18:47 UTC (permalink / raw)
  To: git
In-Reply-To: <19596620.post@talk.nabble.com>

On Sep 21, 2008, at 11:42 AM, mwolfe38 wrote:

>
> Fixed, by removing the trailing / in the names it will then ignore  
> all files
> in that directory,
> so now i just have
> cache
> log
> instead of
> cache/ and log/

FYI, you might try this instead:
/cache
/log

It's more specific, and if you had a file like "/lib/adapters/log/ 
rotater.rb", it wouldn't be ignored, whereas it would without the  
leading slashes.

Tim

^ permalink raw reply

* What's in git.git (Sep 2008, #03; Mon, 22)
From: Junio C Hamano @ 2008-09-22 19:40 UTC (permalink / raw)
  To: git

I think 'maint' has all the known fixes and is ready to become 1.6.0.3
(but I may not have enough time or energy to do the release engineering
before I leave for two weeks).

* The 'maint' branch has these fixes since the last announcement.

Alec Berryman (2):
  git-svn: factor out svnserve test code for later use
  git-svn: Always create a new RA when calling do_switch for svn://

Brandon Casey (2):
  t9700/test.pl: avoid bareword 'STDERR' in 3-argument open()
  t9700/test.pl: remove File::Temp requirement

Charles Bailey (2):
  Add new test to demonstrate git archive core.autocrlf inconsistency
  Make git archive respect core.autocrlf when creating zip format archives

Dmitry Potapov (2):
  git-rebase-interactive: do not squash commits on abort
  git-rebase--interactive: auto amend only edited commit

Eric Raible (1):
  completion: git commit should list --interactive

Eric Wong (1):
  git-svn: fix handling of even funkier branch names

Fabrizio Chiarello (1):
  builtin-clone: fix typo

Garry Dolley (1):
  Clarified gitattributes documentation regarding custom hunk header.

Heikki Orsila (3):
  Start conforming code to "git subcmd" style part 2
  Start conforming code to "git subcmd" style part 3
  Cosmetical command name fix

Jeff King (1):
  Use compatibility regex library also on FreeBSD

Joey Hess (1):
  gitweb: avoid warnings for commits without body

Johannes Sixt (2):
  Use compatibility regex library also on AIX
  git-remote: do not use user input in a printf format string

Junio C Hamano (9):
  discard_cache: reset lazy name_hash bit
  diff Porcelain: do not disable auto index refreshing on -C -C
  diff --quiet: make it synonym to --exit-code >/dev/null
  Don't verify host name in SSL certs when GIT_SSL_NO_VERIFY is set
  Fix permission bits on sources checked out with an overtight umask
  checkout: do not lose staged removal
  GIT 1.6.0.2
  diff/diff-files: do not use --cc too aggressively
  Start draft release notes for 1.6.0.3

Mikael Magnusson (2):
  Typo "bogos" in format-patch error message.
  git-repack uses --no-repack-object, not --no-repack-delta.

Petr Baudis (1):
  Do not perform cross-directory renames when creating packs

Ralf Wildenhues (1):
  Fix some manual typos.

Thomas Rast (1):
  sha1_file: link() returns -1 on failure, not errno

Todd Zullinger (1):
  Use dashless git commands in setgitperms.perl

Yann Dirson (1):
  Bust the ghost of long-defunct diffcore-pathspec.


* The 'master' branch has these since the last announcement
  in addition to the above.

Bert Wesarg (1):
  for-each-ref: `:short` format for `refname`

Christian Couder (3):
  bisect: test merge base if good rev is not an ancestor of bad rev
  bisect: only check merge bases when needed
  bisect: remove "checkout_done" variable used when checking merge bases

Daniel Barkalow (1):
  Check early that a new branch is new and valid

Deskin Miler (1):
  git-svn: testcase for partial rebuild

Deskin Miller (1):
  git-svn: do a partial rebuild if rev_map is out-of-date

Junio C Hamano (4):
  diff: vary default prefix depending on what are compared
  daemon.c: avoid setlinebuf()
  Update draft release notes to 1.6.1
  t5510: test "git fetch" following tags minimally

Nicolas Pitre (3):
  sha1write: don't copy full sized buffers
  pack-objects: don't include missing preferred base objects
  t5300: improve SHA1 collision test

Quy Tonthat (1):
  Update RPM spec for the new location of git-cvsserver.

René Scharfe (3):
  log: add load_ref_decorations()
  move load_ref_decorations() to log-tree.c and export it
  add '%d' pretty format specifier to show decoration

SZEDER Gábor (1):
  bash: use for-each-ref format 'refname:short'

Thomas Rast (2):
  rev-list: fix --reverse interaction with --parents
  t6013: replace use of 'tac' with equivalent Perl

^ permalink raw reply

* What's cooking in git.git (Sep 2008, #04; Mon, 22)
From: Junio C Hamano @ 2008-09-22 19:40 UTC (permalink / raw)
  To: git

Here are the topics that have been cooking.  Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'.

The topics list the commits in reverse chronological order.  The topics
meant to be merged to the maintenance series have "maint-" in their names.

I'll be on vacation til Oct 08; proposal/review/discussion/improvement
cycle based on e-mails and the distributed nature of git mean that it
shouldn't keep the participants from further improving the system.  I've
asked Shawn to look after in-flight patches during the time, so hopefully
when I come back I'll see a much better git ;-).

----------------------------------------------------------------
[New Topics]

* nd/narrow (Sun Sep 14 20:07:59 2008 +0700) 9 commits
 - grep: skip files that have not been checked out
 - checkout_entry(): CE_NO_CHECKOUT on checked out entries.
 - Prevent diff machinery from examining worktree outside narrow
   checkout
 - Add tests for updating no-checkout entries in index
 - ls-files: add --narrow-checkout option to "will checkout" entries
 - update-index: add --checkout/--no-checkout to update
   CE_NO_CHECKOUT bit
 - update-index: refactor mark_valid() in preparation for new options
 - Introduce CE_NO_CHECKOUT bit
 - Extend index to save more flags

This is an early half of the earlier series (I haven't had chance to look
at the updated series yet), and should be replaced with the updated one
posted recently.

----------------------------------------------------------------
[Stalled -- Needs Action to Proceed (or to be dropped)]

* pb/submodule (Fri Sep 12 23:09:19 2008 +0200) 1 commit
 - t7400: Add short "git submodule add" testsuite

Waiting for a reroll.

* bd/blame (Thu Aug 21 18:22:01 2008 -0500) 5 commits
 - Use xdiff caching to improve git blame performance
 - Allow xdiff machinery to cache hash results for a file
 - Always initialize xpparam_t to 0
 - Bypass textual patch generation and parsing in git blame
 - Allow alternate "low-level" emit function from xdl_diff

Réne had good comments on how the callback should be structured.

* kb/am-directory (Fri Aug 29 15:27:50 2008 -0700) 1 commit
 - git-am: Pass the --directory option through to git-apply

I think this is still buggy and drops the option when am stops with
conflicts.

----------------------------------------------------------------
[Will be merged to 'master/maint' soon]

* mv/merge-recursive (Sat Sep 6 18:29:49 2008 +0200) 11 commits
 + builtin-merge: release the lockfile in try_merge_strategy()
 + merge-recursive: get rid of virtual_id
 + merge-recursive: move current_{file,directory}_set to struct
   merge_options
 + merge-recursive: move the global obuf to struct merge_options
 + merge-recursive: get rid of the index_only global variable
 + merge-recursive: move call_depth to struct merge_options
 + cherry-pick/revert: make direct internal call to merge_tree()
 + builtin-merge: avoid run_command_v_opt() for recursive and subtree
 + merge-recursive: introduce merge_options
 + merge-recursive.c: Add more generic merge_recursive_generic()
 + Split out merge_recursive() to merge-recursive.c

(Tip at 4271666)

* ho/dirstat-by-file (Fri Sep 5 22:27:35 2008 +0300) 1 commit
 + diff --dirstat-by-file: count changed files, not lines

(Tip at fd33777)

* jc/safe-c-l-d (Tue Sep 2 14:10:15 2008 -0700) 1 commit
 + safe_create_leading_directories(): make it about "leading"
   directories

(Tip at 5f0bdf5)

* jc/apply-include-exclude (Mon Aug 25 01:05:31 2008 -0700) 1 commit
 + git-apply:--include=pathspec

(Tip at 6ecb1ee)

* mv/commit-tree (Wed Sep 10 22:10:33 2008 +0200) 3 commits
 + t7603: add new testcases to ensure builtin-commit uses
   reduce_heads()
 + builtin-commit: use commit_tree()
 + commit_tree(): add a new author parameter

(Tip at 7a172b0)

* pb/autocorrect-wrapper (Wed Sep 10 17:54:28 2008 +0200) 1 commit
 + git wrapper: also use aliases to correct mistyped commands

(Tip at 746c221)

* jc/better-conflict-resolution (Thu Sep 4 23:48:48 2008 +0200) 15 commits
 + Fix AsciiDoc errors in merge documentation
 + git-merge documentation: describe how conflict is presented
 + checkout --conflict=<style>: recreate merge in a non-default style
 + checkout -m: recreate merge when checking out of unmerged index
 + Merge branch 'jc/maint-checkout-fix' into 'jc/better-conflict-
   resolution'
 + git-merge-recursive: learn to honor merge.conflictstyle
 + merge.conflictstyle: choose between "merge" and "diff3 -m" styles
 + rerere: understand "diff3 -m" style conflicts with the original
 + rerere.c: use symbolic constants to keep track of parsing states
 + xmerge.c: "diff3 -m" style clips merge reduction level to EAGER or
   less
 + xmerge.c: minimum readability fixups
 + xdiff-merge: optionally show conflicts in "diff3 -m" style
 + xdl_fill_merge_buffer(): separate out a too deeply nested function
 + checkout --ours/--theirs: allow checking out one side of a
   conflicting merge
 + checkout -f: allow ignoring unmerged paths when checking out of
   the index

(Tip at 3407a7a)

* jc/alternate-push (Tue Sep 9 01:27:10 2008 -0700) 4 commits
 + push: receiver end advertises refs from alternate repositories
 + push: prepare sender to receive extended ref information from the
   receiver
 + receive-pack: make it a builtin
 + is_directory(): a generic helper function

(Tip at d79796b)

* bc/master-diff-hunk-header-fix (Sat Sep 20 18:36:22 2008 -0700) 10 commits
 + Merge branch 'bc/maint-diff-hunk-header-fix' into bc/master-diff-
   hunk-header-fix
 + diff hunk pattern: fix misconverted "\{" tex macro introducers
 + diff: fix "multiple regexp" semantics to find hunk header comment
 + diff: use extended regexp to find hunk headers
 + Merge branch 'bc/maint-diff-hunk-header-fix' into bc/master-diff-
   hunk-header-fix
 + diff: use extended regexp to find hunk headers
 + Merge branch 'bc/maint-diff-hunk-header-fix' into bc/master-diff-
   hunk-header-fix
 + diff.*.xfuncname which uses "extended" regex's for hunk header
   selection
 + diff.c: associate a flag with each pattern and use it for
   compiling regex
 + diff.c: return pattern entry pointer rather than just the hunk
   header pattern

(Tip at 92bb978)

* am/status (Mon Sep 8 00:05:03 2008 +0200) 2 commits
 + wt-status: Teach how to discard changes in the working directory
 + wt-status: Split header generation into three functions

(Tip at 4d6e4c4)

I think the above are all ready for 'master'.

* mg/maint-remote-fix (Mon Sep 22 10:57:51 2008 +0200) 1 commit
 + make "git remote" report multiple URLs

(Tip at 7d20e21)

* bc/maint-diff-hunk-header-fix (Sat Sep 20 15:30:12 2008 -0700) 5 commits
 + diff hunk pattern: fix misconverted "\{" tex macro introducers
 + diff: use extended regexp to find hunk headers
 + diff.*.xfuncname which uses "extended" regex's for hunk header
   selection
 + diff.c: associate a flag with each pattern and use it for
   compiling regex
 + diff.c: return pattern entry pointer rather than just the hunk
   header pattern

(Tip at 96d1a8e)

The above two are ready for 'maint'.

----------------------------------------------------------------
[Actively Cooking]

* tr/workflow-doc (Sat Sep 13 18:11:01 2008 +0200) 2 commits
 + Documentation: Refer to git-rebase(1) to warn against rewriting
 + Documentation: new upstream rebase recovery section in git-rebase

My impression from the last round of discusson on the third patch in this
series (not queued here) was that as long as we do not present it as "One
True Workflow", the description was a good starting point, possibly others
to add other recommended flows later.

* pb/commit-where (Mon Sep 8 01:05:41 2008 +0200) 1 commit
 + builtin-commit.c: show on which branch a commit was added

Tentatively kicked back to "still cooking" status after Jeff voiced his
annoyance.  I personally do not like making this multi-line as Jeff
suggested as an alternative (the message already is too verbose to my
taste).

* lt/time-reject-fractional-seconds (Sat Aug 16 21:25:40 2008 -0700) 1 commit
 + date/time: do not get confused by fractional seconds

* jc/add-ita (Thu Aug 21 01:44:53 2008 -0700) 1 commit
 + git-add --intent-to-add (-N)

Teaches "git add" to record only the intent to add a path later.
I rerolled this without the fake empty blob object.

* jc/post-simplify (Fri Aug 15 01:34:51 2008 -0700) 2 commits
 - revision --simplify-merges: incremental simplification
 - revision --simplify-merges: prepare for incremental simplification

I started making this incremental but the progress is not so great.

----------------------------------------------------------------
[On Hold]

* jc/stripspace (Sun Mar 9 00:30:35 2008 -0800) 6 commits
 - git-am --forge: add Signed-off-by: line for the author
 - git-am: clean-up Signed-off-by: lines
 - stripspace: add --log-clean option to clean up signed-off-by:
   lines
 - stripspace: use parse_options()
 - Add "git am -s" test
 - git-am: refactor code to add signed-off-by line for the committer

The one at second from the tip needs reworking.

* jc/send-pack-tell-me-more (Thu Mar 20 00:44:11 2008 -0700) 1 commit
 - "git push": tellme-more protocol extension

* jc/merge-whitespace (Sun Feb 24 23:29:36 2008 -0800) 1 commit
 - WIP: start teaching the --whitespace=fix to merge machinery

* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 2 commits
 - blame: show "previous" information in --porcelain/--incremental
   format
 - git-blame: refactor code to emit "porcelain format" output

* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 1 commit
 + merge: remove deprecated summary and diffstat options and config
   variables

This was previously in "will be in master soon" category, but it turns out
that the synonyms to the ones this one deletes are fairly new invention
that happend in 1.5.6 timeframe, and we cannot do this just yet.  Perhaps
in 1.7.0, but with the loud whining about moving git-foo out of $PATH we
have been hearing, it might not be a bad idea to drop this.

* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 1 commit
 - diff: enable "too large a rename" warning when -M/-C is explicitly
   asked for

This would be the right thing to do for command line use, but gitk will be
hit due to tcl/tk's limitation, so I am holding this back for now.

^ permalink raw reply

* Re: [TopGit PATCH] prev/next/tsort: commands to explore dependencies
From: Uwe Kleine-König @ 2008-09-22 20:10 UTC (permalink / raw)
  To: Bert Wesarg, g; +Cc: Petr Baudis, git
In-Reply-To: <36ca99e90809221032x3003c1f7q8ef09cb92a0473ad@mail.gmail.com>

On Mon, Sep 22, 2008 at 07:32:50PM +0200, Bert Wesarg wrote:
> On Mon, Sep 22, 2008 at 17:36, Petr Baudis <pasky@suse.cz> wrote:
> >  Hi,
> >
> > On Fri, Sep 19, 2008 at 11:55:00AM +0200, Bert Wesarg wrote:
> >> I hacked 3 commands to explore the dependencies of TopGit patches:
> >
> >  thanks, the idea of all three commands is good,
> >
> >>   I) tg prev [NAME]
> >>      outputs the dependencies of NAME
> >>
> >>  II) tg next [NAME]
> >>      outputs patches that depends on NAME
> >
> >  but I think it would be cleaner to add this functionality to
> > tg info...
> Right, but 'tg next' is shorter than any 'tg info --next'.
> 
> >
> >> III) tg tsort [PATTERN]
> >>      outputs a topological order of all patches starting with PATTERN
> >
> > ...and tg summary (overally, to have a tree view of branches).
> Maybe something like the graph output from git rev-log --graph?
> 
> >> +                                     printf "%s\t%q\n" "${dep_rev}" "${dep}" >&3
> >> +                                     printf "%s\t%s\n" "${topic_rev}" "${dep_rev}"
> >
> > %q?
> 
> "and %q causes printf to output the corresponding argument in  a
> format that can be reused as shell input."
With /bin/sh == dash this doesn't work.  I havn't looked where and how
this is used, but rev-parse has an --sq option that results in the
output being shell quoted.  Maybe this can help?

Best regards
Uwe

^ permalink raw reply

* Re: [TopGit PATCH] prev/next/tsort: commands to explore dependencies
From: Bert Wesarg @ 2008-09-22 20:18 UTC (permalink / raw)
  To: Uwe Kleine-König; +Cc: g, Petr Baudis, git
In-Reply-To: <20080922201025.GB792@strlen.de>

On Mon, Sep 22, 2008 at 22:10, Uwe Kleine-König <ukleinek@strlen.de> wrote:
> On Mon, Sep 22, 2008 at 07:32:50PM +0200, Bert Wesarg wrote:
>> On Mon, Sep 22, 2008 at 17:36, Petr Baudis <pasky@suse.cz> wrote:
>> >  Hi,
>> >
>> > On Fri, Sep 19, 2008 at 11:55:00AM +0200, Bert Wesarg wrote:
>> >> I hacked 3 commands to explore the dependencies of TopGit patches:
>> >
>> >  thanks, the idea of all three commands is good,
>> >
>> >>   I) tg prev [NAME]
>> >>      outputs the dependencies of NAME
>> >>
>> >>  II) tg next [NAME]
>> >>      outputs patches that depends on NAME
>> >
>> >  but I think it would be cleaner to add this functionality to
>> > tg info...
>> Right, but 'tg next' is shorter than any 'tg info --next'.
>>
>> >
>> >> III) tg tsort [PATTERN]
>> >>      outputs a topological order of all patches starting with PATTERN
>> >
>> > ...and tg summary (overally, to have a tree view of branches).
>> Maybe something like the graph output from git rev-log --graph?
>>
>> >> +                                     printf "%s\t%q\n" "${dep_rev}" "${dep}" >&3
>> >> +                                     printf "%s\t%s\n" "${topic_rev}" "${dep_rev}"
>> >
>> > %q?
>>
>> "and %q causes printf to output the corresponding argument in  a
>> format that can be reused as shell input."
> With /bin/sh == dash this doesn't work.  I havn't looked where and how
> this is used, but rev-parse has an --sq option that results in the
> output being shell quoted.  Maybe this can help?
I'm unsure if this quoting is actually needed.

I build a map from revision (sha1) to topic name:

  abc..\tt/topic

and use this file (after |sort|uniq) to build a sed script which
replaces sha1 with the topic name in the output  from tsort:

 s#abc...#t/topic#

Maybe the quoting is not needed.

Bert

>
> Best regards
> Uwe
>

^ permalink raw reply

* Re: [JGIT PATCH]  Test and fix handling of quotes in ~/.ssh/config
From: Robin Rosenberg @ 2008-09-22 20:42 UTC (permalink / raw)
  To: Jonas Fonseca; +Cc: sverre, Shawn O. Pearce, git
In-Reply-To: <20080921112519.GA24200@diku.dk>

söndagen den 21 september 2008 13.25.19 skrev Jonas Fonseca:
> +		assertEquals("bad.tld\"", osc.lookup("bad").getHostName());
This one is really (as you noted) bad so we shouldn't allow it at all. A new 
subclass of TransportExcpeption should be thrown to indicate a serious
configuration problem when attempting to use the option.

-- robin

^ permalink raw reply

* Re: [JGIT PATCH]  Test and fix handling of quotes in ~/.ssh/config
From: Shawn O. Pearce @ 2008-09-22 21:07 UTC (permalink / raw)
  To: Robin Rosenberg; +Cc: Jonas Fonseca, sverre, git
In-Reply-To: <200809222242.29165.robin.rosenberg.lists@dewire.com>

Robin Rosenberg <robin.rosenberg.lists@dewire.com> wrote:
> söndagen den 21 september 2008 13.25.19 skrev Jonas Fonseca:
> > +		assertEquals("bad.tld\"", osc.lookup("bad").getHostName());
> This one is really (as you noted) bad so we shouldn't allow it at all. A new 
> subclass of TransportExcpeption should be thrown to indicate a serious
> configuration problem when attempting to use the option.

Probably so.

But then we need to mark that the Host is invalid, because we
are serving requests from a cache, not from the file itself.
And TransportException isn't something that the SshSessionFactory
knows about.  Probably better to use a a subclass of IOException.

-- 
Shawn.

^ permalink raw reply

* rebasing merges
From: Stephen Haberman @ 2008-09-22 20:57 UTC (permalink / raw)
  To: git

Hello,

I was wondering if there are any plans to enhance the rebase
functionality to match something like [1], specifically to handle
rebasing merge commits.

My understanding of the current rebase implementation is that it dumps
all the changes as a patch, moves HEAD, and applies the patch.

This works great for regular commits, but if one of the new commits was
a merge, rebase seems to "flatten" the merge. Because the patch dump
doesn't include any information about the merged commit's existing
hashes/parents, when the patch is applied, each merged commit gets
reapplied as a new commit, with a new hash, and no DAG link back to
where the original pre-rebase merge came from.

We've had this happen on topic branches when devs merged in a new
stable release that contains ~100 commits, but had their branch's
remote head move on them, so they pull --rebase as usual, but end up
with all ~100 commits from the release essentially cherry-picked into
their topic branch. So now we have the disclaimer of "usually pull
--rebase...unless you've done a merge, then do a pull --merge".

[1] seems to solve this with some fairly complex cherry-picking and
ancestry manipulation that, admittedly, I don't quite understand, but
it seems like it might be able to bring along a merge's multiple
parents information throughout the rebase and maintain the merge as a
single, non-flattened merge commit.

Thanks,
Stephen

1: http://www.selenic.com/mercurial/wiki/index.cgi/RebasePlan

^ permalink raw reply

* [PATCH bc/maint-diff-hunk-header] t4018-diff-funcname: test syntax of builtin xfuncname patterns
From: Brandon Casey @ 2008-09-22 23:19 UTC (permalink / raw)
  To: Junio C Hamano
  Cc: Arjen Laarhoven, Mike Ralphson, Johannes Sixt, Jeff King,
	Boyd Lynn Gerber, Git Mailing List, Avery Pennarun, Johan Herland,
	Andreas Ericsson, Kirill Smelkov, Giuseppe Bilotta,
	Gustaf Hendeby, Jonathan del Strother
In-Reply-To: <7vy71n482x.fsf@gitster.siamese.dyndns.org>

Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---


How about something like this on top of your ERE conversion patch.
It will test that regcomp() completes successfully.

-brandon


 t/t4018-diff-funcname.sh |   11 +++++++++++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/t/t4018-diff-funcname.sh b/t/t4018-diff-funcname.sh
index 602d68f..76919a4 100755
--- a/t/t4018-diff-funcname.sh
+++ b/t/t4018-diff-funcname.sh
@@ -32,7 +32,18 @@ EOF
 
 sed 's/beer\\/beer,\\/' < Beer.java > Beer-correct.java
 
+builtin_patterns="bibtex java pascal ruby tex"
+for p in $builtin_patterns
+do
+	test_expect_success "builtin $p pattern compiles" '
+		echo "*.java diff=$p" > .gitattributes &&
+		git diff --no-index Beer.java Beer-correct.java 2>&1 |
+			test_must_fail grep "fatal" > /dev/null
+	'
+done
+
 test_expect_success 'default behaviour' '
+	rm -f .gitattributes &&
 	git diff --no-index Beer.java Beer-correct.java |
 	grep "^@@.*@@ public class Beer"
 '
-- 
1.6.0.1.244.gdc19

^ permalink raw reply related

* [PATCH bc/master-diff-hunk-header] t4018-diff-funcname: test syntax of builtin xfuncname patterns
From: Brandon Casey @ 2008-09-22 23:26 UTC (permalink / raw)
  To: Junio C Hamano
  Cc: Arjen Laarhoven, Mike Ralphson, Johannes Sixt, Jeff King,
	Boyd Lynn Gerber, Git Mailing List, Avery Pennarun, Johan Herland,
	Andreas Ericsson, Kirill Smelkov, Giuseppe Bilotta,
	Gustaf Hendeby, Jonathan del Strother
In-Reply-To: <b-t750rmbNQ3RJMPXbQJmYFebFR6SfB9QBkJdDzbG7GGT_3aZBkCfw@cipher.nrlssc.navy.mil>

Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---


And then this goes on top of bc/master-diff-hunk-header once
bc/maint-diff-hunk-header with the previous patch is merged in.

-brandon


 t/t4018-diff-funcname.sh |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/t/t4018-diff-funcname.sh b/t/t4018-diff-funcname.sh
index 76919a4..5b58f50 100755
--- a/t/t4018-diff-funcname.sh
+++ b/t/t4018-diff-funcname.sh
@@ -32,7 +32,7 @@ EOF
 
 sed 's/beer\\/beer,\\/' < Beer.java > Beer-correct.java
 
-builtin_patterns="bibtex java pascal ruby tex"
+builtin_patterns="bibtex html java pascal php python ruby tex"
 for p in $builtin_patterns
 do
 	test_expect_success "builtin $p pattern compiles" '
-- 
1.6.0.1.244.gdc19

^ permalink raw reply related

* [PATCH] builtin-prune.c: prune temporary packs in <object_dir>/pack directory
From: Brandon Casey @ 2008-09-22 23:34 UTC (permalink / raw)
  To: Petr Baudis; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <1222104021-28277-1-git-send-email-pasky@suse.cz>

Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---

Re: [PATCH] Do not perform cross-directory renames when creating packs

I think something like this should be applied on top.

-brandon


 builtin-prune.c |   18 ++++++++++--------
 1 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/builtin-prune.c b/builtin-prune.c
index c767a0a..fc8be45 100644
--- a/builtin-prune.c
+++ b/builtin-prune.c
@@ -13,7 +13,7 @@ static const char * const prune_usage[] = {
 static int show_only;
 static unsigned long expire;
 
-static int prune_tmp_object(char *path, const char *filename)
+static int prune_tmp_object(const char *path, const char *filename)
 {
 	const char *fullpath = mkpath("%s/%s", path, filename);
 	if (expire) {
@@ -113,21 +113,19 @@ static void prune_object_dir(const char *path)
  * files begining with "tmp_") accumulating in the
  * object directory.
  */
-static void remove_temporary_files(void)
+static void remove_temporary_files(const char *path)
 {
 	DIR *dir;
 	struct dirent *de;
-	char* dirname=get_object_directory();
 
-	dir = opendir(dirname);
+	dir = opendir(path);
 	if (!dir) {
-		fprintf(stderr, "Unable to open object directory %s\n",
-			dirname);
+		fprintf(stderr, "Unable to open directory %s\n", path);
 		return;
 	}
 	while ((de = readdir(dir)) != NULL)
 		if (!prefixcmp(de->d_name, "tmp_"))
-			prune_tmp_object(dirname, de->d_name);
+			prune_tmp_object(path, de->d_name);
 	closedir(dir);
 }
 
@@ -141,6 +139,7 @@ int cmd_prune(int argc, const char **argv, const char *prefix)
 			 "expire objects older than <time>"),
 		OPT_END()
 	};
+	char *s;
 
 	save_commit_buffer = 0;
 	init_revisions(&revs, prefix);
@@ -163,6 +162,9 @@ int cmd_prune(int argc, const char **argv, const char *prefix)
 	prune_object_dir(get_object_directory());
 
 	prune_packed_objects(show_only);
-	remove_temporary_files();
+	remove_temporary_files(get_object_directory());
+	s = xstrdup(mkpath("%s/pack", get_object_directory()));
+	remove_temporary_files(s);
+	free(s);
 	return 0;
 }
-- 
1.6.0.1.244.gdc19

^ permalink raw reply related

* git http-push and MKCOL error (22/409)
From: Sean Davis @ 2008-09-22 23:51 UTC (permalink / raw)
  To: git

I built git from source for mac os and after updating curl to the
latest version and installing the latest expat (both from source), I
have git-http-push installed.  I have a bare repository in the webDAV
directory (which was placed there over a webDAV mount, so it appears
that webDAV is working).  When I try to push to it, I get the
following:

sdavis$ git push http://sdavis@example.com/git/stuff.git master
Fetching remote heads...
  refs/
  refs/heads/
updating 'refs/heads/master'
  from 0000000000000000000000000000000000000000
  to   f1ea50f8f60497ea3eca2355c10c141734db6451
    sending 3070 objects
MKCOL d7a940ff6c7bbc924f6e2d2c319aea22b8b0fdac failed, aborting (22/409)
MKCOL c9ac4c17871308e520a9944e12d846be9f24f91d failed, aborting (22/409)
MKCOL 1ac1bf55510deade68b14debd71357e3d929fe1c failed, aborting (22/409)
MKCOL da5e8ff9649c2b6ee0fde2280163ab4b399a1f1a failed, aborting (22/409)
MKCOL 87fc8ecfa98c36e0f9e44ed772d49d02378fc191 failed, aborting (22/409)
UNLOCK HTTP error 500
error: failed to push some refs to 'http://sdavis@example.com/git/stuff.git'

The apache error log shows:

[Mon Sep 22 19:48:53 2008] [error] [client 156.40.148.25] File does
not exist: /home/www/git/stuff.git/info
[Mon Sep 22 19:48:53 2008] [error] [client 156.40.148.25] File does
not exist: /home/www/git/stuff.git/objects
[Mon Sep 22 19:49:47 2008] [error] [client 156.40.148.25] (2)No such
file or directory: Cannot create collection; intermediate collection
does not exist.  [409, #0]
[Mon Sep 22 19:49:47 2008] [error] [client 156.40.148.25] (2)No such
file or directory: Cannot create collection; intermediate collection
does not exist.  [409, #0]
[Mon Sep 22 19:49:47 2008] [error] [client 156.40.148.25] (2)No such
file or directory: Cannot create collection; intermediate collection
does not exist.  [409, #0]
[Mon Sep 22 19:49:47 2008] [error] [client 156.40.148.25] (2)No such
file or directory: Cannot create collection; intermediate collection
does not exist.  [409, #0]
[Mon Sep 22 19:49:47 2008] [error] [client 156.40.148.25] (2)No such
file or directory: Cannot create collection; intermediate collection
does not exist.  [409, #0]

Any ideas?

Thanks,
Sean

^ permalink raw reply

* [PATCH] diff funcname_pattern: Allow HTML header tags without attributes
From: Johan Herland @ 2008-09-23  0:49 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git, Brandon Casey
In-Reply-To: <CTXDOuN2-1v4gLJ9IqQwhgSzVh_BwEQIV70MoNH_beVI1QE7-TLy7g@cipher.nrlssc.navy.mil>

Signed-off-by: Johan Herland <johan@herland.net>
---

On Tuesday 23 September 2008, Brandon Casey wrote:
> And then this goes on top of bc/master-diff-hunk-header once
> bc/maint-diff-hunk-header with the previous patch is merged in.

After looking over this once more, I think the HTML regexp should be
changed as follows. This fixes a buglet that was part of my original
HTML pattern, and although this patch textually depends on Brandon's
work, it is conceptually independent of his refactorization.


Have fun!

...Johan

 diff.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/diff.c b/diff.c
index d0e7319..c8b72f4 100644
--- a/diff.c
+++ b/diff.c
@@ -1424,7 +1424,7 @@ static const struct funcname_pattern_entry *funcname_pattern(const char *ident)
 static const struct funcname_pattern_entry builtin_funcname_pattern[] = {
 	{ "bibtex", "(@[a-zA-Z]{1,}[ \t]*\{{0,1}[ \t]*[^ \t\"@',\\#}{~%]*).*$",
 	  REG_EXTENDED },
-	{ "html", "^[ \t]*(<[Hh][1-6][ \t].*>.*)$", REG_EXTENDED },
+	{ "html", "^[ \t]*(<[Hh][1-6]([ \t].*)?>.*)$", REG_EXTENDED },
 	{ "java",
 	  "!^[ \t]*(catch|do|for|if|instanceof|new|return|switch|throw|while)\n"
 	  "^[ \t]*(([ \t]*[A-Za-z_][A-Za-z_0-9]*){2,}[ \t]*\\([^;]*)$",
-- 
1.6.0.2.405.g3cc38

^ permalink raw reply related

* Re: [PATCH] diff funcname_pattern: Allow HTML header tags without attributes
From: Junio C Hamano @ 2008-09-23  1:46 UTC (permalink / raw)
  To: Johan Herland; +Cc: git, Brandon Casey
In-Reply-To: <200809230249.23298.johan@herland.net>

Johan Herland <johan@herland.net> writes:

> After looking over this once more, I think the HTML regexp should be
> changed as follows. This fixes a buglet that was part of my original
> HTML pattern, and although this patch textually depends on Brandon's
> work, it is conceptually independent of his refactorization.
> ...
> -	{ "html", "^[ \t]*(<[Hh][1-6][ \t].*>.*)$", REG_EXTENDED },
> +	{ "html", "^[ \t]*(<[Hh][1-6]([ \t].*)?>.*)$", REG_EXTENDED },

I do not think these two particularly would make much difference.  Why
isn't it simply...

	"<[Hh][1-6].*"

without even any capture or anchor?

It would falsely hit oddball cases like <h1foo> which is not <h1>, but
anybody who uses such a nonstandard thing deserves it, imnvho ;-).

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox