Signed-off-by: Pavel Roskin <proski@gnu.org> --- sha1_file.c | 15 +++++++++++---- 1 files changed, 11 insertions(+), 4 deletions(-) diff --git a/sha1_file.c b/sha1_file.c index 095a7e1..53e25f2 100644 --- a/sha1_file.c +++ b/sha1_file.c @@ -22,6 +22,12 @@ #endif #endif +#ifdef NO_C99_FORMAT +#define SZ_FMT "lu" +#else +#define SZ_FMT "zu" +#endif + const unsigned char null_sha1[20]; static unsigned int sha1_file_open_flag = O_NOATIME; @@ -407,9 +413,9 @@ struct pac...

My sp/mmap changes to pack-check.c modified the function such that it expects packed_git.pack_size to be populated with the total bytecount of the packfile by the caller. But that isn't the case for packs obtained by git-http-fetch as pack_size was not initialized before being accessed. This caused verify_pack to think it had 2^32-21 bytes available when the downloaded pack perhaps was only 305 bytes in length. The use_pack function then later dies with "offset beyond end of packfile" when compu...

Me too. I have actually been fighting with it on and off since we got sp/mmap reasonably stable. I just always kept attributing it to kernel.org mirroring lag until I realized it was just happening way too often. -- Shawn. -

Ohhhhh. It should reflog if .git/logs/HEAD exists, so long as changes to HEAD are done via update-ref and not just by echo (as one of Junio's versions of the feature had done). Unfortunately .git/logs/HEAD wouldn't be created by default as its not under refs/heads or refs/remotes. Though it could be made to be on by default, in which case it would only log changes while HEAD is detached. If HEAD is attached to a branch then .git/logs/HEAD wouldn't be appended to (or even created), while the br...

I think reflogging detached HEAD is easier than adding safety checks either on commit (no commits on top of detached HEAD), or on checkouts and stuff (try not to loose unless forced chain of commits built on top of detached HEAD). -- Jakub Narebski Poland -

git checkout v1.4.0 # dang, need some local fix git commit -m tmpfix -a git reset --hard v1.2.0 git reset --hard v1.3.0 # dang, need that local again fix - where is it? It ain't in ORIG_HEAD. Its now only findable by fsck-objects/lost-found. But if you reflog a detached HEAD its there as HEAD@{2}. Maybe its not really worth it. But it almost seems like it would come free if we always use update-ref like we're supposed to... -- Shawn. -

Ah, yes, apparently my own head is detached and not clearly thinking. Thanks. That UI is not so good. -- Shawn. -

Yes. Then that removes my desire for a safety check in reset, (which Linus doesn't want) thereby making both of us happy. -- Shawn. -

Looks sane. Eric? -

Got this from one of the other people here who's using git. Luckily he was able to restore his repo from a filesystem snapshot, so no permanent harm done, but what's the pure-git way to recover from this? Are the revisions in question really gone? --- I have 3 branches: master fql fql-new master is basically just the same as remotes/git-svn, fql is a bunch of changes on top of that, and then fql-new is a new version of FQL so it makes changes on top of the changes in fql (with the intention ...

Try `git lost-found` before you use `git prune` (or also now `git gc`). Also, if you have relogs enabled on your work branches (and I hope you do, as its now the default) you can look at the branch from earlier, e.g.: git log HEAD@{5.minutes.ago} or git log HEAD@{1} to look at HEAD was just before `git rebase` did the reset. Which would be the commit you lost, but want back. Unfortunately we don't really have a reflog viewing utility yet so you just have to sort of guess around with...

Humh... I finished the conflicts solving game. I think the way I choosed is incorrect. Following gitk, it is now a big big bazaar in my commits history. Can you give me some tips about using both git-svn and stgit please? -- Guilhem BONNEFILLE -=- #UIN: 15146515 JID: guyou@im.apinc.org MSN: guilhem_bonnefille@hotmail.com -=- mailto:guilhem.bonnefille@gmail.com -=- http://nathguil.free.fr/ -

I have setup, (thanks Pasky) the repository git://repo.or.cz/qgit4.git With an experimental version of qgit, called qgit4. Features are the same of qgit-1.5.4 release but has been ported under Qt4.2 libraries from Qt3, this means that could be compiled and run as a Windows native application. Qt4.2 is available as GPL for non commercial purposes also for Windows platform. So what you need is: 1) Qt4.2 already packaged with MinGW for windows ([ message continues ]

Well, Qt4 it's completely different from Qt3, porting it's a nice way to say rewrite. So moving patches between the two branches it's very difficult already now and it will be impossible in a near future not because of development forking, but because of API. This means two different and *not mergeable* branches. Being not mergeable they lose the main motivation to be in the same repository IMHO. Also I would like to continue to support and improve the stable and proven Qt3 version on kernel.org ...

Thanks for the hints, here the next try. Stefan -

Seems to be style inconsistancy between current_offset = and rc= I How likely are we ever to be in the right place here? Seems vanishingly small putting us firmly in the four syscalls per call space. I wonder if git ever actually cares about the seek location. ie if we could stop reading and resetting it. Probabally not worth working it out I guess -apw -

In the index-pack case it simply will never happen. Nicolas -

No this is wrong. The original offset _has_ to be preserved. index-pack counts on it. Nicolas -

Hi, Not completely true. We fixed in v1.4.4.1~23 a bug which was triggered by NO_MMAP. Since this recently became the default for cygwin, "git-index-pack --fix-thin" would fail in most cases. Ciao, Dscho -

Otherwise we get an error like this on stderr: cat: [...]/.git/refs/remotes/origin/master: No such file or directory which makes it look like git-clone failed. Signed-off-by: Alexandre Julliard <julliard@winehq.org> --- git-clone.sh | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/git-clone.sh b/git-clone.sh index 3d388de..cf761b2 100755 --- a/git-clone.sh +++ b/git-clone.sh @@ -355,7 +355,7 @@ then # The name under $remote_top the remote HEAD seems to ...

That's fine. I applied your patch with minimum fixups so that it does not make the surviving records _invalid_ ones after "reflog expire" runs ;-). -

What does it do when you say, for example: git log --walk-reflogs master..next I couldn't make heads or tails out of the patch and did not understand what it was trying to do. It looked as if you were making the log traversal machinery to walk _both_ reflog (probably from the latest to older) and the usual ancestry. -

No, I had not had a chance to look at it. I don't see the patch in my inbox currently, so I must have deleted it earlier. As much as I want this feature in 1.5.0's final release I don't really have the time/inclination to dredge though my own local mailing list archives or through the online ones to locate it either. Right now I want to track down a nasty bug in git-http-fetch that I noticed recently that's keeping me from tracking git.git through an HTTP proxy, and then I need to do some hacki...

Style: please don't have declaration after statement. Yes, it is in the more recent ANSI, but the rest of git has avoided it so far and having the decls upfront makes it easier to read. I do not think you would want to return EINVAL. Andy's read_in_full() is now on 'master' so please use it instead to avoid short read. -

Ok, following the next try for replacing pread() with lseek()/xread()/lseek() sequence like Shawn suggested. It's tested on Linux but not yet on Cygwin. I'll do it tomorrow. Stefan -