Hi. I work with a lot of backporting of patches and there are times when people combine multiple patches together such that the resulting patch can have multiple chunks changing the same file. I have noticed git-apply does not handle this case correctly. It usually ignores all previous chunks and only applies the last one. The same scenario can also cause git-apply to fail if a later patch chunk depends on changes from an earlier patch chunk. The traditional 'patch' command seems to handle t...

I started a thread a while back about repository corruption. It manifested as a clone error and the thread is here: http://kerneltrap.org/mailarchive/git/2007/7/31/253475 I just ran, again, into corruption after my laptop kernel-panic'd. (Ironically, at the moment I ran into the corruption I was trying to push my repo to a backup location.) Since that thread took place it seems a section about recovering from repo corruption was added to the manual --- but it assumes you can (or care to pai...

Nope. I was *just* about to back it up. -- Denis --

Thanks for the help. My situation was: ...---a---*---b---c---d---*---e---... Following your example, I believe I got this to: ...---a---* b---c---d---* e---... \ / \ / \-X-/ \---/ That is, I replaced the first problematic commit and deleted the second, since I forgot how I changed 'd' to get that commit. I put the following in .git/info/grafts: 'b' X 'e' 'd' (which I gathered from here: [ message continues ]

You're onto something: [dorothy.local /tmp <Tue Jun 10> <16:02:08>] tmp[176] > git clone file:///Volumes/work/identity.fb/ Initialized empty Git repository in /tmp/identity.fb/.git/ remote: Counting objects: 401, done. remote: Compressing objects: 100% (364/364), done. remote: Total 401 (delta 170), reused 0 (delta 0) Receiving objects: 100% (401/401), 233.76 KiB, done. Resolving deltas: 100% (170/170), done. [dorothy.local /tmp <Tue Jun 10> <16:02:22>] tmp[177] &g...

On Tue, Jun 10, 2008 at 16:23, Linus Torvalds I intended to do that, yes, and I think I was successful. (I only say I "intended to" --- instead of "I did" --- because I read the documentation for the grafts file elsewhere on this list, and not in I do have bunches of personal information in the repo, unfortunately. The particular *file* involved in the corruption, however, is fine for all to view. Is that useful? -- Denis --

"Graft and then clone" will not make the copied repository Ok. You need to propagate the graft in some other way. However, "Graft and then filter-branch" is a way to hide and get rid of the the broken thing in history etched in the objects. After that the repository itself and a clone from it will not need the graft. So I'd rather argue we should document it _differently_ (or just _better_) than not document it. --

On Tue, Jun 10, 2008 at 17:09, Linus Torvalds I checked; no such luck. -- Denis

On Tue, Jun 10, 2008 at 17:48, Linus Torvalds Right --- that's my username and computer's hostname... for some reason. [You are not expected to understand this. My computer's name mysteriously changed. It should not be "dorothy.local" but it is. I It is the same computer on which the problem occurred last time. It's an OS X 10.4 macbook pro. I haven't noticed corruption in other places, but it's fair to assume it's occurring. I'll have to boot off I can't remember if the old one happened...

For me, on the whole kernel, on a pretty good system: - before: [torvalds@woody test-it-out]$ time git add . real 0m7.986s user 0m6.404s sys 0m1.456s - after: [torvalds@woody test-it-out]$ time ~/git/git-add . real 0m52.693s user 0m7.416s sys 0m2.516s so it's definitely quite noticeable in that simplistic form. A more interesting patch would use aio_fsync(), and then just wait for them at the end with aio_return(). Not that I love AIO, but t...

Yes, almost exclusively. ... That is an odd problem. Thanks for the suggestion. -- Denis --

So I re-did the filter-branch as: git-filter-branch HEAD 28aa69aafc8ae901e588f6d341b3e6d3558c6d26^..163a93df14d246dee91c3a503e6372b8313f337d Now cloning still works and only shows dangling commits --- no errors! -- Denis --

Extract filling project list info, i.e. adding age, description, owner and forks information, into fill_project_list_info() subroutine. This is preparation for smart pagination and smart searching (to make it possible to calculate/generate info only for those projects which will be shown). Small changes compared to original version to improve readability (comments, names of variables, named loops). Additionally, store both full ('descr_long') and shortened ('descr') project description in Perl'...

Following up last week's problem with the stable-2.6.25.y tree: From the HTTP perspective, the tree is stuck in time. The two new tags v2.6.25.5 and v2.6.25.6 do not appear when I do this: % git pull -v From http://www.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.25.y = [up to date] master -> origin/master Already up-to-date. On my home machine, I verified that these tags appear as expected when I pull with the git protocol. But at work I'm behind a firewall and am stuc...

Take a look at match_multi_number in date.c The timezone didn't change. One date is in daylight saving time, the other There will be flaws in any system that tries to automatically guess the format. If there is not already one, perhaps a statement should be added to the appropriate documentation describing how to ensure that european ordering is used to parse the date. -brandon --

Well, there are safer ways to give the date. If you do it in strict rfc822 format, you'll never have any confusion what-so-ever. The "approxidate()" thing tries to parse any random input, but it *is* meant to be excessively liberal. IOW, you can literally say "at tea-time two weeks ago" and get a date, and it will even work. But you can also say "my 3rd child was born in December", and it will also give you a date. The date will not make _sense_, but it will give you one (it will decid...

Since you did not give a timezone, your local timezone is taken, presumably MET, which has daylight saving time in July, but not in January. This is OK. -- Hannes --

For CVS repositories with unusual CVSROOT, git-cvsimport would fail: $ git-cvsimport -v -C foo -d :pserver:anon:@cvs.example.com:/ foo AuthReply: error 0 : no such repository This patch ensures that the path is never empty, but at least '/'. Signed-off-by: Philippe Bruhat (BooK) <book@cpan.org> --- git-cvsimport.perl | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/git-cvsimport.perl b/git-cvsimport.perl index 5a02550..cacbfc0 100755 --- a/git-cvsimpor...

See below for detailed response. It looks like all, or almost all I wonder why it was made immutable (static page)... errr, it is not immutable, you just are required to login to edit. Below detailed analysis of the contents of the page ------------------------------------------------------------------- I'm not sure if having bug tracker would help. Git development works Git has now "-m <parent-number>|--mainline <parent-number>" option to git-cherry-pick and git-revert,...

I think the right solution would be for send-email to move Date: to the beginning of the body part, just like it adds an extra From: there when the sender is different from the author, and not lie about the mail transmission date. Then we won't lose the authorship date information in the resulting commit and will still keep the mailpath happy. --

Heh. That's just because our "smudge_racily_clean_entry()" uses 0 as the magic smudging size. You can fix this multiple ways. One would be to pick another size that is simply less likely (eg ~0 instead), which leaves the theoretical race, and just makes it practically impossible to hit (not that I think it's very practical to hit already). The other approach is to know that an empty blob always has a very specific SHA1. Here's an trial patch. Linus --- read-cache.c | 16 ...

It's worth pointing out that even in the absense of races, you can obviously screw things up if you really work at it, and *want* to. We cannot guarantee that we see all file changes from the stat() information, and we don't even save the whole stat info (ie we only save the low 32 bits). The ctime check is there to help make it harder for people to play games by setting the mtime back in time after having changed things, but we may at some point be forced to remove it because it trigge...

Hmm, sorry, could you elaborate how you would plan to use the return value from time(2) per file? The "index file timestamp" trick assumes that once we start reading from and writing to the filesystem (in order to hash the current contents, check if there is any modification), nobody else touches the paths we are interested in (e.g., after "read-tree -m -u" checks out the new contents, grabs the stat information from the newly deposited file and stuffs that in the index, you do not go in and edit...

Sorry if this is a well-known problem, but I only just came across it. I tried searching for it briefly, but to no avail. Maybe nobody cares because there's usually no need to export from git! And it's only one of the satellite features, not the core. Nonetheless, if you export git repos, you might want to know about it. Try this: $ git clone git://git.kernel.org/pub/scm/git/git.git # clone git source $ git checkout -b test 60ea0fdd7de001405fcc7591beb18a66a1f0dd09 $ git fast-export test > /t...

This makes it possible to install html documents from the top level directory. Previously such target was only in Documentation/Makefile. Signed-off-by: Teemu Likonen <tlikonen@iki.fi> --- I'm wondering why this target doesn't exist. Is this sane and safe thing to do? Makefile | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/Makefile b/Makefile index 1937507..b2b8bef 100644 --- a/Makefile +++ b/Makefile @@ -1290,6 +1290,9 @@ endif install-doc: $(MAK...