Hello, the below patch fixes some compiler warnings returned by Solaris Workshop Compilers. CC builtin-apply.o "builtin-apply.c", line 686: warning: statement not reached CC utf8.o "utf8.c", line 287: warning: statement not reached CC xdiff/xdiffi.o "xdiff/xdiffi.c", line 261: warning: statement not reached CC xdiff/xutils.o "xdiff/xutils.c", line 236: warning: statement not reached Signed-off-by: Guido Ostkamp <git@ostkamp.fastmail.fm> --- builtin-apply.c | ...

This one is right. Accidentally, as it seems -

Sure enough. I'll chalk that one up to too many mind-numbing meetings today. Thanks for the wake-up... -

Does "dos2unix" override file access bits? Because the object store is always made read-only. Nicolas -

I was working on a new repo created from a tar snapshot of an old project, and after about a half-hour and about 5 commits for hacking, I had fixed the problem I set out to take care of. However, I tried to run git gc to clean it up and put it away and I was met with the following: [sewall@hobo SWIFT++_1.2 (master)]$ git gc Counting objects: 227, done. error: corrupt loose object '680aba836639d14a36b81f9e29da52bd9af69770' fatal: object 680aba836639d14a36b81f9e29da52bd9af69770 cannot be ...

Thanks for a fix-up and clarification. Hannes, otherwise this passed in your environment? -

Since you changed this test, I assume that the remaining tests that you put back failed only because this one did something wrong. If so, please mention that in the commit message. -- Hannes -

It did nothing wrong. It was simply relying on the product of a previous test that might still be disabled. Nicolas -

I imagine it is one of the above. Most sed's add trailing newlines. -- David Kastrup -

When git-fetch was builtin-ized the previous script was moved to contrib/examples. Now, it is the sole remaining user for most of git-parse-remote (except for get_remote_url) and for git-fetch--tool. Would it make sense to remove git-fetch--tool, the dead parts of git-parse-remote, and contrib/examples/git-fetch.sh? Anyway, the script is very involuted unlike the other scripts in contrib/examples. Paolo -

Yes, have just sent you the output of "--verbose" and also running the script using "sh -x" (off list). Cheers, Wincent -

Was just running the test suite against the master branch and saw that t9101 is currently failing on Leopard, and a review with git-bisect indicates that it has been ever since it was first introduced (in commit 15153451). Not sure if this problem is Leopard-specific or not as I only have one machine. This is the specific test that's failing: * FAIL 25: test propget git-svn propget svn:ignore . | cmp - prop.expect && cd deeply && git-svn propget svn:ignore . | cmp - ../prop.expect ...

Hi, I think this is our good old friend, MacOSX' sed. (Wasn't there a question today what's wrong with using sed? I think this issue qualifies.) I imagine that it is that MacOSX' sed is adding a trailing newline (not the regexp like you suggested). Which means that "wc -l" would print "1". (You can see for yourself if you run the script with "sh -x ...".) IMHO a good solution would be test -z "$(grep -e '^#' -e '^$' actual)" Could you test, please? Thanks, Dscho -

Commit 4d8b1dc850 added a couple of tests to t7004, and my testing reveals that this one has been broken on Leopard since then: * FAIL 83: message in editor has initial comment GIT_EDITOR=cat git tag -a initial-comment > actual || true && test $(sed -n "/^\(#\|\$\)/p" actual | wc -l) -gt 0 (Not sure whether this affects other platforms, or versions of Mac OS X prior to Leopard, as I only have one machine here.) The problem is the version of sed that ships with Leopard fails to match ...

The 'message in editor has initial comment' test fails on Leopard (and possibly on other versions of Mac OS X as well) due to the limited sed syntax available on that platform. Avoid the breakage by using grep instead (suggested by Johannes Schindelin). Signed-off-by: Wincent Colaiuta <win@wincent.com> --- t/t7004-tag.sh | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/t/t7004-tag.sh b/t/t7004-tag.sh index 096fe33..02ec9c3 100755 --- a/t/t7004-tag.sh +++ ...

"Conditioned by retarded systems" is pretty close, and it was pretty much the wording employed. And then, when someone gets upset, he gets "Sheesh"ed off, basically calling him stupid again. "People skills" is not something I would associate with the git developer list in general. -- David Kastrup -

Linus Torvalds <torvalds@linux-foundation.org> writes: OK, and if I say "git add subdir/a-ok" I get no error, as expected. So extend it just a tiny bit, moving a-ok down a directory and using the negative pattern "!subsubdir/a-ok" to match: brs% cat .gitignore a* brs% cat subdir/.gitignore !subsubdir/a-ok brs% find * all-files subdir subdir/.gitignore subdir/subsubdir subdir/subsubdir/a-ok subdir/a-ok brs% git ls-files -o ...

By the way, about the problem I described briefly last night. I never understood the intended use of -i option to ls-files, but in your test repository (the one that has subsubdir), you can do: $ git ls-files -i --exclude='a*' to see "What paths have I already _staged_ that would have been ignored if the exclude pattern were 'a*'". You can abuse this to list all the staged header files with: $ git ls-files -i --exclude='*.h' but $ git ls-files -- '*.h' is much simpler for ...

What about character classes containing the pattern delimiter, \+, \?, \|, nested grouping, anchors in groups, * after groups? That's all rather straightforward usage. -- David Kastrup -

I don't think that's really a fair characterization -- almost all of the autoconf sed portability caveats concern weird corner cases in the dusty corners of the language (and some are "common" issues with other tools, i.e., avoiding ^ and $ inside of regexp groups). For typical straightforward usage, there seems little problem. [The main portability problems I've actually _noticed_ with sed are the "-e" versus ";" issue and what happens with "\n" in various contexts...] -Miles -- Do ...

When using an existing git repository to cache the perforce import we don't= fetch the branch mapping from perforce as that is a slow operation. However the origi= n repository may not be fully up-to-date and therefore it may be necessary to import mor= e changes directly from Perforce. Such a direct import needs self.knownBranches to be= set up though, so initialize it from the existing p4/* git branches. Signed-off-by: Simon Hausmann <simon@lst.de> =2D-- contrib/fast-import/git-p4 | ...

Great, that's a lot more appropriate in my opinion. I'll just update to a later git. Thanks! -- Jens Axboe -

Earlier "git cherry-pick" learned the "-m <parent-number>" option to allow cherry-picking a merge commit. When you have this history: ---o---o---C---A---M \ / o---o-------B You can replay the change between A and M (in other words, the effect of merging B into A) on top of C to create a new commit, with: $ git cherry-pick -m 1 M In the current implementation, the resulting commit has a single parent C. This is quite similar to a squash merge of B ...

Actually, this turns to be a trick question ;-) If there was an accidental clean merge between A and B, and a part of the duplicated same changes in the accidental clean merge sits between C and A, replaying the difference from A to M on top of C would not yield the same result as merging B into C. -

When switching to a new rev, we first made "new-bisect" branch to point at the chosen commit, attempt to switch to it, and then finally renamed the new-bisect branch to bisect by hand when successful. This is so that we can catch checkout failure (your local modification may interfere with switching to the chosen version) without losing information on which commit the next attempt should be made. Rewrite it using a more modern form but without breaking the safety. Signed-off-by: Junio C ...

We do not need to pipe "echo" to "sed" only to strip refs/heads/ from the beginning. We are assuming not-so-ancient shells these days. Also there is no need to avoid assuming \012 is the LF; we do not run on EBCDIC, sorry. Other parts of the script already uses tr to convert separator to LF that way. Signed-off-by: Junio C Hamano <gitster@pobox.com> --- git-bisect.sh | 5 ++--- 1 files changed, 2 insertions(+), 3 deletions(-) diff --git a/git-bisect.sh b/git-bisect.sh index ...

Ooops. 'test -d "$GIT_DIR/refs/bisect"' is used as a signal that we are bisecting for the rest of the code, so we cannot lose that rm -fr there. I think a longer term clean-up would be not to treat "bisect" as a reserved branch name but use detached HEAD while bisecting. But that is a larger topic. -

Nothing, but using it means forking a new process unnecessarily, and the shorter form without sed is arguably more readable: - echo "$head" | sed 's#^refs/heads/##' >"$GIT_DIR/head-name" + echo "${head#refs/heads/}" >"$GIT_DIR/head-name" Cheers, Wincent -

I even had Junio convinced at one point! I am not actually creating such refs, but I think my brain was still fried from the URL encoding discussion, and I was overly paranoid about spaces. -Peff -

If you also swap %(refname) and %(objectname), then this is also not prone to whitespace in refnames. (Yes, I know, there shouldn't be such, but...) -- Hannes -

It says "remove refs/heads/ from the beginning of the string pointed to by $head". It's not a bashism. Some extensions to that syntax are though (I think). If you want to be sure of portability, use sed instead. git uses this syntax often enough that it's worth using everywhere, but usually only in porcelain commands which one can relatively safely assume are run on at least decently up-to-date developer workstations. You'll note that stuff that absolutely *has* to reside server-side ...

If refs were ever packed in the middle of bisection, the bisect refs were not removed from the "packed-refs" file. This patch fixes this problem by using "git update-ref -d $ref $hash" in "bisect_clean_state". Signed-off-by: Christian Couder <chriscool@tuxfamily.org> --- git-bisect.sh | 11 ++++++++++- t/t6030-bisect-porcelain.sh | 12 ++++++++++++ 2 files changed, 22 insertions(+), 1 deletions(-) diff --git a/git-bisect.sh b/git-bisect.sh index 3aac816..73a4da2 ...

Yes, but at that point we know we are looking for "git" subcommand not general command on PATH, so we can only look for "git-runstatus" in the git_exec_path (initialized by $GIT_EXEC_PATH or compiled-in) and correctly fail during the test. -

Hi, Funnily enough, it _is_ the non-dash form that I replaced. What happens is this: the git wrapper looks for a builtin named 'runstatus', does not find it, then calls out for something like 'git-runstatus', which is found in my $HOME/bin. Sorry, Dscho -

Signed-off-by: Shawn Bohrer <shawn.bohrer@gmail.com> --- builtin-clean.c | 9 ++------- 1 files changed, 2 insertions(+), 7 deletions(-) diff --git a/builtin-clean.c b/builtin-clean.c index 01fb887..dc6a21e 100644 --- a/builtin-clean.c +++ b/builtin-clean.c @@ -22,7 +22,7 @@ static int git_clean_config(const char *var, const char *value) { if (!strcmp(var, "clean.requireforce")) force = !git_config_bool(var, value); - return 0; + return git_default_config(var, value); } ...

Hi, IMHO a better idea would be a counterpart to fast-import, probably called "fast-export". You'd need only one process then, and it would not only be faster, but would be usable by even more people, I guess. Ciao, Dscho -

So, where has that patch gone? -- Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen -

Can't you just load a root kit^w^wsystem extension that hides such files from any and all application? Morten -

Oh what a day I've had. Today Insane Bank Corp (my day-job employer) upgraded their Windows desktop encryption software. *Every* directory on every computer is now blessed with a "Desktop.ini" file. Git of course loves this concept: $ git for-each-ref >/dev/null && echo yes error: refs/Desktop.ini points nowhere! error: refs/heads/Desktop.ini points nowhere! yes Fortunately for-each-ref allows corrupt refs to exist in the ref namespace. So until Git is properly patched we are at ...

Well, see, you can't actually use Git at Insane Bank Corp because it wasn't put on the approved list of software. Furthermore if it was put on that list it would probably only ever be approved for use on RedHat Linux, as on Windows there is Microsoft Visual Source Suck and on Solaris there is Rational ConfusingCase. All provide the same function and therefore are exactly suitable for those platforms. Any deviants get Desktop.ini files where they don't want them. Keep in mind that Insane ...

That doesn't seem to work. For example, if I add '*.c' to .gitignores in git.git, I can't seem to get that command to display any .c files. Run on its own, it displays lots of files, but no .c files. Run with That also doesn't seem to do quite what I want, and probably in the same way. I see git add returns non-zero error status if a file is ignored, so I can do it with excluded=() for f in $(git ls-files) do git add $f || excluded=($excluded $f) done But that feels kind of ...

Alex Riesen <raa.lkml@gmail.com> writes: They are in the index. What I want is a list of files which are known to git, which are matched by the default rules (in particular the .gitignore files). So that should be this? git ls-files --exclude-per-directory=.gitignore -i But that shows nothing at all, and it still shows nothing if I add a "builtin-add.c" as an argument to it (this file exists, and is in the index). "git add builtin-add.c" fails, complaining (correctly) that ...

Ahh. *All* the .gitignore rules are purely about files that git does not already know about. Once git tracks a pathname, the ignore rules simply do not matter. Files that are in the index are simply never ignored. There's no way to ignore them, and in fact, the whole "git add -f" thing is a way to add files to the index and override the exclude rules - at which point git then tracks them regardless of any such exclude rules. Linus -

Yes, so it seems. The per-directory ignore-files don't work. No, I honestly believed that Git-known files can be ignored. According to Linus I must be wrong, but I have an excuse: $ mkdir aaa $ cd aaa $ git init Initialized empty Git repository in .git/ $ uname >abc $ git add . $ ls > .gitignore $ git ls-files -X .gitignore $ git ls-files -X .gitignore -i abc -

Is that supposed to work? I would have thought that the only options would be empty and 0. I am pretty sure I have seen size calculations in the deltifying code that would break badly using FLEX_ARRAY=1. So _IFF_ -DFLEX_ARRAY=1 is supposed to be necessary for some compilers, I could try seeing whether I find those locations again. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum -

I do recall that I received a patch with an explicit member elem[1] that is in fact used as a flexible array, foolishly converted it to use FLEX_ARRAY and saw it mysteriously fail, and realized what it was doing and reverted my changes, and applied the patch as received. IIRC it all happened before I pushed the results out. I unfortunately do not recall which area the patch was about. -

On Thu, 15 Nov 2007, Bj

Yeah, that at least compiles (didn't do any further tests), forgot to say that in the last email. Björn -

Actually, I just created a test-case remotely on a Solaris box in my university (see below) and didn't compile the actual git code. With the FAM, cc complains about a redeclared identifier, with a zero-sized array, it complains that an array cannot be zero-sized... Seems to be a known bug in Sun Studio 10: http://forum.java.sun.com/thread.jspa?threadID=5071896&messageID=9263771 Björn #include <stdio.h> struct foo; void bar(const struct foo *, unsigned long); struct bla ...

Some versions of SUN's cc have a bug that causes them to complain about a redeclared identifier when you use a function declaration that takes a struct with a FAM and this struct has only been declared but not yet defined. IOW, this will fail: struct foo; void bar(struct foo *); struct foo { int v; long *a[]; }; void bar(struct foo *foo) {} // SUN cc bug strikes here So when we detect a SUN cc, we use an array size of 1 to workaround that bug. Signed-off-by: Björn ...

Hi, Provided you do not kill the repository of the submodule (you have some public repo for that, right?) you will not lose anything, since the history of the superproject has pointers to the submodule. But I guess that you want something different... You probably want to rewrite history as if the submodule had not been a submodule at all, right? Ciao, Dscho -

I want to keep the history of the submodule -- Ping Yin -

Yeah, this actually what i want. Now i find a way: 1. move submodule subB outside mv subB /newpath/to/subB git-commit subB 2. git-filter-branch to rename all files in subA repository to subB directory (say subB/subB). cd newpath/to/subB && git filter-branch --index-filter \ 'git ls-files -s | sed "s-\t-&subB/-" | GIT_INDEX_FILE=$GIT_INDEX_FILE.new \ git update-index --index-info && mv ...

Really? I would think "which" works better, in that it is not restrictive. I.e., "The filter attribute is set to a string. This string, btw, names a filter driver" (which) rather than "The filter attribute is set to a string, and from the set of strings, it is set to the particular string that names a filter driver" (that). But in the non-restrictive case, it should be in a parenthetical phrase: A `filter` attribute can be set to a string value, which names a filter driver specified in ...

Yes, but someone (guess who) started to modernize git-bisect by using "for-each-ref": http://git.kernel.org/?p=git/git.git;a=commitdiff;h=6fecf1915c5fd0b14e2ca2ec9e1a6b620a... http://git.kernel.org/?p=git/git.git;a=commitdiff;h=0a5280a9f444c33b0e4ebf2f073df5899c... Thanks for reminding me of this problem. I just posted a patch that should fix it. Best regards, Christian. -

Thanks, I took a look at the man page you suggested. The "ident" feature almost does what I want, but doesn't seem to take any sort of format string. So, I thought I'd explore "filter," but can't really find any examples of how to implement the smudge and clean commands, which seem to be what I'm really trying to do here. Is there an example somewhere that you can point me to? The man page doesn't really show any examples of how to implement the filter attribute, so I'm a little unsure how to ...

"git-add -i" _doesn't_ seems to notice it though... -Miles -- [|nurgle|] ddt- demonic? so quake will have an evil kinda setting? one that will make every christian in the world foamm at the mouth? [iddt] nurg, that's the goal -

To clarify: the "add untracked" sub-menu of "git-add -i" -Miles -- Do not taunt Happy Fun Ball. -

I think this is a good cookbook material to put somewhere in the docs. -

Is that really the case, or is this _just_ when we have asked to include ignored files in the output? Or maybe I am missing something fundamental here. git-add--interactive:list_untracked needs something like this, but I don't think your patch will work. We need something more like this (also on maint because your standard exclude patch is): -- >8 -- git-ls-files: add --exclude-standard This provides a way for scripts to get at the new standard exclude function. --- diff --git ...

So here it is. This teaches "git ls-files" to read the standard set of exclude files when no exclude patterns nor files is given from the command line. We used to error out in such a case. Signed-off-by: Junio C Hamano <gitster@pobox.com> --- builtin-ls-files.c | 7 ++----- 1 files changed, 2 insertions(+), 5 deletions(-) diff --git a/builtin-ls-files.c b/builtin-ls-files.c index e0b856f..50dcb89 100644 --- a/builtin-ls-files.c +++ b/builtin-ls-files.c @@ -542,11 +542,8 @@ int ...

How is %s/foo different from ../foo? There are only 2 paths that need to be relocatable. Your proposal is over-engineering, IMHO. -- Hannes -

fair enough. Let's take your patches. Steffen -

Path relocation would be more explicit: 1) Paths that need to be relocated are filtered through relocate_path(). That's easy to understand. 2) All the code prefixing the path is in relocate_path(). This avoids code duplication. 3) Path that should be relocated contain "%s" in the Makefile. This indicates that some string expansion may take place. (1) and (2) would be useful even if you do not agree with (3). The code in PATCH 9/11 and PATCH 11/11 looks very similar. If the ...

Oops, I'm clearly an idiot. I explicitly looked at bad_ref_char before writing the original message, and somehow read that as strictly less than. So the parsing problem goes away, and I think using the sort order as a hint takes away the potential performance problem (I don't even know if it was a problem -- there may be other O(n^2) behavior). I will take a look at the tests Alex has been working on, maybe add a few to it, and submit a cleaned-up series. -Peff -

BTW, since there seems to be some debate on how this _should_ work, I think the "signal failure if anything failed" approach is the better. Why? Because either way you do it, there is an ambiguity, and I would rather that ambiguity lie with the "failure" case. If I see exit code '0', I _know_ that all of my refs were updated. If I see exit code '1', then there was some failure detected, but my refs might or might not have been updated. But that ambiguity _already_ exists. Consider the ...

My goal with the recent patches is that _any_ failure will cause a non-0 exit code (but you have to read the stderr output to find out which, if any, refs were successful). -Peff -

After I became disconnected, I looked at my 'next', and the reason for the failure to delete the ref seems to be your is_null_sha1 error-checking patch, which Junio put in next. But maybe you have figured that out in the intervening time. :) -Peff -

It wouldn't match other --mirror options. You would want it to set up refs/remotes namespace for you, but the other --mirror options (those in push/fetch) are meant to explicitly ignore refs/remotes and make sure branches are named exactly the same on both sides (hence --mirror). I wouldn't mind if it was given some other option that did what you wanted, but having --mirror mean two such very different things would be bad. "git init --remote origin=git://host/repo", where the lhs of the ...

Hi, Nope. That is necessary only for the initial push. Remember: "git push" defaults to pushing to the remote "origin", and _all_ local branches which the remote knows about. And the latter is the reason why the initial push needs a special handling: the local and the remote repository have no branches in common, because the remote one does not have _any_ branch yet! So, once you pushed the initial push, you can drop the "origin master" It's highly unlikely that you have the ...

Junio just said "but that is fine", so afaiu he's not against allowing it per se. It's just that him and the other frequent contributors don't have this particular problem, so if *they* fix it it will a) Not be done with enthusiasm, and it would indeed drain enthusiasm and happiness from the project. b) Perhaps not be done the way those who want this feature would like it. c) Take another scarce resource (time) from other, more pressing issues which may or may not affect your workflow ...

I don't know the exact error but are you sure that changes to If the error is a conflict, 'stg push --undo' should revert the pushed patch to its previous state. Otherwise, fix the conflict and run 'stg I haven't seen this type of error before. There might be some inconsistency between the HEAD and the index. Can you try 'git-read-tree HEAD' and run 'stg refresh' afterwards? You might also want to try the latest StGIT snapshot. It should be pretty stable as we are preparing it for a 0.14 ...

I think at the time it was felt the speed hit was too great on large trees. Although my view still is we should always go for correctness I also worry about corner cases in parsing code, especially if you have to start poking around in CVS/Root files. Another (ugly) method could be a two pass attempt, falling back to an individual status call if the I've not had another go at fixing this mainly due to being too busy. The It's not just new files that can break (btw another fix has gone in ...

--- t/t7501-commit.sh | 10 ++++++++++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/t/t7501-commit.sh b/t/t7501-commit.sh index 5aed3de..3627d9f 100644 --- a/t/t7501-commit.sh +++ b/t/t7501-commit.sh @@ -259,4 +259,14 @@ test_expect_success 'amend commit to fix author' ' diff expected current ' + +test_expect_success 'git commit <file> with dirty index' ' + echo tacocat > elif && + echo tehlulz > chz && + git add chz && + git commit elif -m "tacocat is a ...

Hi, On Thu, 15 Nov 2007, Kristian H

Hi, Well, it _is_ in testable shape. My working setup is using builtin-commit since a week. One glitch is serious: "git add a1 && git commit b1" will commit a1, too. Another glitch is only mildly annoying to me (but I have not investigated in detail yet): when you commit new files in a subsubdirectory, no summary "created file" is printed for them. Other than that, I am pretty happy with it, and the other issues I listed I run with it, and like it. Sometimes when I rebase to ...

If you look just above where you added these lines, there is code to deal with this case, except it doesn't work. I was trying to fix this too by adding a discard_cache() call before building the temp index, but then I couldn't add the files in question because the index was now newer than those files. Anyway, I don't know if your code is better that just doing read_tree(), but we should only have one or the other in there. Kristian -