The diff-delta code can exhibit O(m*n) behavior with some patological data set where most hash entries end up in the same hash bucket. The latest code rework reduced the block size making it particularly vulnerable to this issue, but the issue was always there and can be triggered regardless of the block size. This patch does two things: 1) the hashing has been reworked to offer a better distribution to atenuate the problem a bit, and 2) a limit is imposed to the number of entries tha...

Andrew insists --whitespace=warn should be the default, and I tend to agree. This introduces --whitespace=warn, so if your project policy is more lenient, you can squelch them by having apply.whitespace=nowarn in your configuration file. Signed-off-by: Junio C Hamano <junkio@cox.net> --- * Not in "next" but will be shortly. apply.c | 6 +++++- 1 files changed, 5 insertions(+), 1 deletions(-) 114b085dd7b82c3ca74760c896e86c425127cf76 diff --git a/apply.c b/apply.c index a5cdd8e....

The new configuration option apply.whitespace can take one of "warn", "error", "error-all", or "strip". When git-apply is run to apply the patch to the index, they are used as the default value if there is no command line --whitespace option. Andrew can now tell people who feed him git trees to update to this version and say: git repo-config apply.whitespace error Signed-off-by: Junio C Hamano <junkio@cox.net> --- * Already in "next". apply.c | 72 ++++++++++++++++++++++...

Sorry. ls-remote shows "SHA1\tPATH". The original says "hexadecimal followed by [either a single space or a single tab] followed by a refpath", while yours says "hexadecimal followed by a single tab followed by a refpath". I do not see how that would make any difference. Puzzled... I've seen two servers DNS round-robin and one of them fail to respond. The first "fetch" goes to the good one and the second ls-remote goes to the bad one, then you would see "Oops, we cannot peek tags". But...

The only language I know of where the presence of whitespace on blank lines matters is make(1). Even there, it's subtle. It's okay to have (using "cat -e" syntax) foo : bar$ command$ $ command$ But there's a difference between foo : bar$ $ which specifies an empty command and will therefore not use a default rule, and foo : bar$ $ which does not specify any command and so will use a default rule if one exists. (Of course, you can also get [ \t]\n inside an arbitrary binary...

That might be reasonable, some might object to tiny amounts of extra work.. In my setup, trailing whitespace purely causes warnings. But with a quilt-style thing, it's trivial to unapply the patch, strip it, reapply. git is different - I'd imagine that if warnings were generated while an mbox was being applied, it's too much hassle to go and unapply the mbox, fix the diffs up and then apply the mbox again. I'd suggest that git have options to a) generate trailing-whitespace warnings, b) gene...

For example: http://compsoc.dur.ac.uk/whitespace/ Jokes aside, I can imagine people want to keep format=flowed text messages (i.e. not programming language source code) under git control. Maybe pulling and pushing would be the default mode of operation for those people, so what git-apply does would not be in the picture for those people, but who knows. One way to find it out is to push out a strict one and see who screams ;-), but the point is I am reluctant to make a stricter policy the ...

If I make a patch series where more than one patch touches the same line, I get a lot of merge errors when upstream has accepted them and I try to merge them back. Suppose a line contained the string "0". Patch p1 changes that to "1", patch p2 further changes that to "2". Upstream accept the patches, and I later "stg pull" them. When reapplying p1 after the pull, stg generates a merge conflict since upstream changed the "0" to "2" and p1 changes the "0" to "1". This situation arises for every li...

Karl Hasselstr

Hi, I find this patch very useful, especially when a directory (tree) describes a project. This patch allows history display of whole trees/directories, a la "git-rev-list HEAD <dir or file>", but somewhat slower, since exported git repository doesn't have the files checked out so we have to use "$gitbin/git-rev-list $hash | $gitbin/git-diff-tree -r --stdin \'$file_name\'" method. Maybe someone can find a speed up for this. And better yet, maybe links can be static as opposed to dynamic...

hi everyone, as i mentioned, i do experimental work with git and svn... and i experienced some problems with git when pulling much data from svn. Actually that happens after i commit a revision with many and big files. After that i cannot do a git-svn fetch anymore because git-svn complains... fatal: Ref refs/heads/svn-git-HEAD is at 504721bf4b2702d3e56cef69950f42a43568e846 but expected 504721bf4b2702d3e56cef69950f42a43568e846 now i am a little confused about that... oh, i actually modified...

ok, i experienced that on little modifications on the git-svn-HEAD branch either... so its really about modifying and not about the huge data I will keep that in mind for the future. Fortunatelly i am still testing and i saved the git repository before experimenting with git-svn. Have you any suggestions howto migrate a git-repository to svn and then work with git-svn on both of it? I tried cg-merge -j to merge my git branch with the private git svn branch, i am allowed to modify safely. that...

btw, i think you have a typo in your man-page: --- # Commit only the git commits you want to SVN:: git-svn commit <tree-ish> [<tree-ish_2> ...] # Commit all the git commits from my-branch that don't exist in SVN:: git commit git-svn-HEAD..my-branch --- i think the second one is intended to be "git-svn commit git-svn-HEAD..my-branch", because you want to sync the SVN tree again, not another git-tree i think... Nicolas -

As a rule, interface branches to different SCMs should never be modified directly by the user. They are used exclusively for talking to the foreign SCM. Signed-off-by: Eric Wong <normalperson@yhbt.net> --- contrib/git-svn/git-svn.txt | 9 ++++++++- 1 files changed, 8 insertions(+), 1 deletions(-) 4676a850ad5a9e4a88fa5dfba1ac231a58bffda1 diff --git a/contrib/git-svn/git-svn.txt b/contrib/git-svn/git-svn.txt index b4b7789..b588a2a 100644 --- a/contrib/git-svn/git-svn.txt +++ b/co...

Either of those could work for me. Changing git-svn-HEAD to become a tag would probably be easier (not having to update other tools, such as git-fetch), but refs/remote may make more sense. -- Eric Wong -

Well, I wouldn't say that tags are expected to stand still. Some kinds of tags are expected to move: a "this is the last tested version" tag would be expected to move with testing. That said, the movement is _different_ from a branch. A branch is expected to move _with_ development, while a tag is expected to either stay the same, or move _after_ development. However, in many ways git really doesn't care much. The "refs/heads" directory is the only one that is really special, in that ...

[Empty message]

Hi all, I'm a newbie of git. I have a question about how to generate a patch by git. I want to make a patch againt git repository HEAD. So in my local tree, I do the command: git diff -p > my.patch The file my.patch is generated. But the unchanged files information is also included in the patch file. It should be quiet. Was I wrong to use git by this way? Thanks for your hints. Regards, -Aubrey -

No, what I did was just "git clone" one repository to my local directory. And entered the local directory to modify one file I wanted. Then I run "git diff > my.patch". The "my.patch" was supposed to contain one file diff information. But it contained the all the files, including which were not changed. Thanks to reply. I''ll try to Andreas's suggestion. Regards, -Aubrey -

================================================================= aubrey@linux:/checkout/uboot/patch/work/drivers> git diff ----snip---- diff --git a/drivers/sk98lin/skxmac2.c b/drivers/sk98lin/skxmac2.c diff --git a/drivers/sk98lin/u-boot_compat.h b/drivers/sk98lin/u-boot_compat.h diff --git a/drivers/sk98lin/uboot_drv.c b/drivers/sk98lin/uboot_drv.c diff --git a/drivers/sk98lin/uboot_skb.c b/drivers/sk98lin/uboot_skb.c diff --git a/drivers/sl811.h b/drivers/sl811.h diff --git a/drivers/sl811_...

Did you by any chance do chmod -R, chown -R or start an ntp daemon somewhere in between there (don't know if clock skews will be detected Decidedly odd. What happens when you do "git update-index --refresh" and then re-run the "git diff > my.patch" thing? -- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 -

I'm using suse9.3. The filesystem is EXT3. I think I forgot one thing last night. When I changed the file, I compiled the package to verify my modification. It should be the reason. But should it really affect the result of "git diff"? Thanks, -Aubrey -

Oops, It's my fault. My mistake is that copy the clone git directory to another directory for backup. And work on another directory. Sorry for my incaution. -Aubrey -

The current best practice involves these steps: 1. Create a topic branch (git checkout -b feature-name) 2. Apply your changes and commit them, preferrably in small and isolated steps, making sure it compiles after each change. 3. Run "git format-patch origin". This will result in one or more commit-patches, which contains your author info, the commit-messages you wrote, the commit-time and all other such info and ofcourse the diff in unified git format. You can send those patches on using "g...

I'm afraid not. You should also note that git doesn't track permissions exactly. It just notices an execution bit and uses it to determine if it should write the working tree using (0666 ^ umask) or (0777 ^ umask). This makes it fairly unsuitable for /etc tracking unless you add some sort of permission restoring thing to it. -- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 - ...