This moves the code to add the per-directory ignore files for the base directory into the library routine. That not only allows us to turn the function push_exclude_per_directory() static again, it also simplifies the library interface a lot (the caller no longer needs to worry about any of the per-directory exclude files at all). Signed-off-by: Linus Torvalds <torvalds@osdl.org> --- dir.c | 28 +++++++++++++++++++++++++++- dir.h | 2 -- ls-files.c | 22 +----------...

Hi, I've been trying to get git to work on the latest Solaris Express release (with the help of NetBSD's pkgsrc). It mostly miserabely fails because of common "shell commands" being used with GNU options. (like xargs, diff, tr and prob. some more) On my box (and thats AFAIK the default when you install gnu coreutils on Solaris) the commands do have a g prefix. So there are 2 possible solutions to get git working on Solaris. 1. fix every single shellscript automatically during the build phas...

And Linus Torvalds writes: - - The complete libification will take some time, and in the meantime, a few - silly C files that hard-code the shell logic is probably much preferable - to using the shell and all the problems that involves (like the whole - problem with quoting arguments - just _gone_ when you do it as a execve() - in a simple C program). But for recommending and using git on these systems _now_... Simply translating the shell script into C with execs doesn't help if you'r...

And "Stefan Pfetzing" writes: - I've been trying to get git to work on the latest Solaris Express - release (with the help of NetBSD's pkgsrc). I've been using it on Solaris 8 and 9 with the GNU tools in pkgsrc for quite a while, as well as on AIX with the GNU tools available as modules (but I haven't compiled a new AIX version for a month or two). - It mostly miserabely fails because of common "shell commands" being - used with GNU options. (like xargs, diff, tr and prob. some more) On - ...

Good job, and it does not seem to spend too many more cycles either (it does slow it down a bit because it needs to do more deltas, but that is to be expected). Here is the average chain length and resulting pack size from full repacking of git.git repository, with three versions. Avg 6.20 6516kB (master) Avg 5.97 5784kB (next, has 1/x version) Avg 6.89 5536kB (this patch on top of next) What's interesting is that the 1/x version shortens the chain (i.e. decrea...

Well, if shell expansion cannot find a file matching pattern, it uses pattern as file name literaly. It would be nice to have easy (git core porcelain level) way to add files which match ignore pattern. -- Jakub Narebski Warsaw, Poland -

Yes I am aware of this one; I just haven't bothered to deal with it. It looks at two strings, "v1.3.3:Makefile" and "Makefile", and says "they have different names -- they are renamed". Patches welcome as long as you do not break more usual cases ;-). -

Well, the thing is, git-add doesn't really take a "file name", it takes a filename _pattern_. Clearly we can't add everything that matches the pattern, because one common case is to add a whole subdirectory, and thus clearly the .gitignore file must override the pattern. So it's consistent that it overrides it also for a single filename case, no? Linus -

Hi *, In the case of: - You merge from a branch with new files - You have these files in the working directory - You do not have these files in the HEAD. The end result is that you lose the content of these files. So an additional check for the merge is to check for these dirty but not in HEAD files. Here is a test that reproduce it. I expect the merge to fail and with the content of foo being bar. test_description='Test merge with local conflicts in new files' . ./tes...

For me it is the other way, all my files matter but git can do Thanks, it works here. Santi -

Sorry, the test is wrong. Use this: test_description='Test merge with local conflicts in new files' . ./test-lib.sh test_expect_success 'prepare repository' \ 'echo "Hello" > init && git add init && git commit -m "Initial commit" && git checkout -b B && echo "foo" > foo && git add foo && git commit -m "File: foo" && git checkout master && echo "bar" > foo && ' test_expect_code 1 'Merge with local conflicts i...

>>>>> "Luke" == Luke <oxwacpp@arsenal.co.uk> writes: Luke> Hire, Luke> i am here sittiang in the internet caffe. Found your email a!nd Luke> decided to write. I might be coming to your p!lace in 14 days, Luke> so I decided to email you. May be we ca!n meet? I am 25 y.o. Luke> girl. I have a picture if you want. No need to reply here as Luke> this is not my email. Write me at ex@datetodayy.com I hope she has a big table. :) -- Randal L. Schwartz - Sto...

Hi. I just ran into trouble with git-svn, related to a file containing $Id$. Yes, I know $Id$ sucks and should be avoided, and I'll be removing them shortly, but that doesn't change the fact that the history contains files with them. Just wanted to let you know of a workaround: manually edit the relevant file in .git/git-svn/tree/ to undo the $Id$ change, and git-svn fetch works again. $ git-svn fetch Tree mismatch, Got: c242bb60d78c1dfce133e0bbaca7f13895de00b2, Expected: 07d35ac911cc56aabea86f...

Well, yes, I agree. But, at least git-svn.txt says this: BUGS ---- ... svn:keywords can't be ignored in Subversion (at least I don't know of a way to ignore them). I guess one might be able to reach that information through the svn API. Or just propget svn:keywords and sed s/\$Id\(:[^$]*\)\$/$Id$/ all files with keywords, for all relevant keywords. Eww. -- Inoi Oy, Tykist

Please don't do this. Just error out. It would be horrible to have a quilt import "succeed", and then later notice that some of the patches had incorrect authorship attribution just because the import script didn't check it, but just made it "unknown". An un-attributed patch is simply not acceptable in any serious project. It's much better to consider it an error than to say "ok". Linus -

I agree it is probably a good way to error by default, optinally allowing to say "don't care". I do not think Linus would pull from such a tree or trees branched from it into his official tree, so I do not think we would need to worry about commits with incomplete information propagating for this particular "gitified mm" usage. But as a general purpose tool to produce "gitified quilt series" tree, we would. It depends on the expected use of the resulting gitified mm tree. If it is for an in...

Hello, With above usage on GIT_PROXY_COMMAND, I still have problem on connection with remote git repository. I also tried setting http_proxy directly but the same result. It's first usage of git in our network. Well, need I enable the git port 9418 at proxy server? Or did I miss sth or what? I use git-2006-05-14.tar.gz package on FC3. Method I : Use GIT_PROXY_COMMAND [root@sam u-boot]# git clone \ git://www.denx.de/git/u-boot.git u-boot-denx.git fatal: exec failed fetch-pack fro...

I cannot run "socket" and "CONNECT" on Fedora Core 3. It simply told me that no such command. How could I Seems you tried proxy-cmd.sh on Debian. Which distribution did you use? Thanks a lot, Sam __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -

On Tue, 16 May 2006 14:46:35 +0300 There are a few commands that would benefit from being easier to run in a bare repository. If this option was added to the "git" wrapper rather than git-repack, it would work for all of them. But maybe git could just automatically recognize when it's in a bare repository. Sean -

The objective of this guide is to save you time and money. http://jrtz.s0g0fjffg7f0aaa3fsslxaaa.sluggingmc.com/?efvck -

Hi, * Junio C Hamano [06-05-16 03:18:24 -0700] wrote: To write an encoder really fully conforming to RfC2047 is a mess. Not so much because the algorithms are difficult but because there're many things to take care of if you want to do it right. For example, encoded words are required to be at most something below 80 characters long. For names this maybe is not an issue, but for subjects. I didn't really check whether your patch produces only the minimum encoding (i.e. only those words that ...

Hello, Do it like that: $ ls project.git $ GIT_DIR=project.git git-repack -a -d -

Unfortunately, no, if you mean by "least common" closest to the tips. See the big illustration at the top of the source for how you can construct pathological case to defeat an attempt to guarantee such. --all guarantees that the output contains all interesting ones, but does not guarantee the output has no suboptimal merge bases. -

Yes, git-merge-base should always return a least common ancestor, never anything less. The only question is what happens when there are multiple LCA commits. In fact, even in that case git-merge-base will have a pretty strong specification: "git-merge-base with the '--all' flag will return the complete set of least common ancestors, sorted by most recent (as defined purely by the commit date order, not any graph ordering) first. Without the '--all' flag, it will return just...

Ah, yes, I remember now. The drawing was done while we were working on the solution to that pathological case; mark_reachable_commits() solves that horizon effect. http://article.gmane.org/gmane.comp.version-control.git/11410 http://article.gmane.org/gmane.comp.version-control.git/11429 http://article.gmane.org/gmane.comp.version-control.git/11552 http://article.gmane.org/gmane.comp.version-control.git/11613 However, our inability to come up with one is not a nonexistence pr...