* Re: [PATCH] Get commits from remote repositories by HTTP
From: tony.luck @ 2005-04-17 3:16 UTC (permalink / raw)
To: Adam Kropelin; +Cc: Daniel Barkalow, git
In-Reply-To: <011201c542d5$940bb670$03c8a8c0@kroptech.com>
>How about building a file list and doing a batch download via 'wget -i
>/tmp/foo'? A quick test (on my ancient wget-1.7) indicates that it reuses
>connectionss when successive URLs point to the same server.
Here's a script that does just that. So there is a burst of individual
wget commands to get HEAD, the top commit object, and all the tree
objects. The just one to get all the missing blobs.
Subsequent runs will do far less work as many of the tree objects will
not have changed, so we don't descend into any tree that we already have.
-Tony
Not a patch ... it is a whole file. I called it "git-wget", but it might
also want to be called "git-pulltop".
Signed-off-by: Tony Luck <tony.luck@intel.com>
------ script starts here -----
#!/bin/sh
# Copyright (C) 2005 Tony Luck
REMOTE=http://www.kernel.org/pub/linux/kernel/people/torvalds/linux-2.6.git/
rm -rf .gittmp
# set up a temp git repository so that we can use cat-file and ls-tree on the
# objects we pull without installing them into our tree. This allows us to
# restart if the download is interrupted
mkdir .gittmp
cd .gittmp
init-db
wget -q $REMOTE/HEAD
if cmp -s ../.git/HEAD HEAD
then
echo Already have HEAD = `cat ../.git/HEAD`
cd ..
rm -rf .gittmp
exit 0
fi
sha1=`cat HEAD`
sha1file=${sha1:0:2}/${sha1:2}
if [ -f ../.git/objects/$sha1file ]
then
echo Already have most recent commit. Update HEAD to $sha1
cd ..
rm -rf .gittmp
exit 0
fi
wget -q $REMOTE/objects/$sha1file -O .git/objects/$sha1file
treesha1=`cat-file commit $sha1 | (read tag tree ; echo $tree)`
get_tree()
{
treesha1file=${1:0:2}/${1:2}
if [ -f ../.git/objects/$treesha1file ]
then
return
fi
wget -q $REMOTE/objects/$treesha1file -O .git/objects/$treesha1file
ls-tree $1 | while read mode tag sha1 name
do
subsha1file=${sha1:0:2}/${sha1:2}
if [ -f ../.git/objects/$subsha1file ]
then
continue
fi
if [ $mode = 40000 ]
then
get_tree $sha1 `expr $2 + 1`
else
echo objects/$subsha1file >> needbloblist
fi
done
}
# get all the tree objects to our .gittmp area, and create list of needed blobs
get_tree $treesha1
# now get the blobs
cd ../.git
if [ -s ../.gittmp/needbloblist ]
then
wget -q -r -nH --cut-dirs=6 --base=$REMOTE -i ../.gittmp/needbloblist
fi
# Now we have the blobs, move the trees and commit from .gitttmp
cd ../.gittmp/.git/objects
find ?? -type f -print | while read f
do
mv $f ../../../.git/objects/$f
done
# update HEAD
cd ../..
mv HEAD ../.git
cd ..
rm -rf .gittmp
------ script ends here -----
^ permalink raw reply
* Re: SHA1 hash safety
From: Tkil @ 2005-04-17 3:23 UTC (permalink / raw)
To: omb; +Cc: David Lang, Ingo Molnar, git
In-Reply-To: <4261132A.3090907@khandalf.com>
>>>>> "Brian" == Brian O'Mahoney <omb@khandalf.com> writes:
Brian> (1) I _have_ seen real-life collisions with MD5, in the context
Brian> of Document management systems containing ~10^6 ms-WORD
Brian> documents.
Was this whole-document based, or was it blocked or otherwise chunked?
I'm wondering, because (SFAIK) the MS word on-disk format is some
serialized version of one or more containers, possibly nested. If
you're blocks are sized so that the first block is the same across
multiple files, this could cause collisions -- but they're the good
kind, that allow us to save disk space, so they're not a problem.
Are you saying that, within 1e7 documents, that you found two
documents with the same MD5 hash yet different contents?
That's not an accusation, btw; I'm just trying to get clarity on the
terminology. I'm fascinated by the idea of using this sort of
content-addressable filesystem, but the chance of any collision at all
wigs me out. I look at the probabilities, but still.
Thanks,
t.
^ permalink raw reply
* Re: [PATCH] update-cache --refresh cache entry leak
From: Linus Torvalds @ 2005-04-17 3:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8y3i5o8t.fsf@assigned-by-dhcp.cox.net>
On Sat, 16 Apr 2005, Junio C Hamano wrote:
>
> When update-cache --refresh replaces an existing cache entry
> with a new one, it forgets to free the original.
I've seen this patch now three times, and it's been wrong every single
time. Maybe we should add a comment?
That active-cache entry you free()'d was not necessarily allocated with
malloc(). Most cache-entries are just mmap'ed directly from the index
file.
Leaking is ok. We cannot leak too much.
Linus
^ permalink raw reply
* Re: [PATCH] libgit
From: Randy.Dunlap @ 2005-04-17 3:46 UTC (permalink / raw)
To: Mike Taht; +Cc: git
In-Reply-To: <4261D438.9080705@timesys.com>
On Sat, 16 Apr 2005 20:12:56 -0700 Mike Taht wrote:
| commit b0550573055abcf8ad19dcb8a036c32dd00a3be4
| tree b77882b170769c07732381b9f19ff2dd5c9f1520
| parent 866b4aea9313513612f2b0d66814a2f526d17f21
| author Mike Taht <m@picketwyre.com> 1113704772 -0700
| committer Mike Taht <m@ipbx.taht.net> 1113704772 -0700
|
| looks my 1878 line patch to convert git to libgit got eaten by vger..
| I put it up at http://pbx.picketwyre.com/~mtaht/libgit.patch if anyone
| wants to comment. from my log:
Connection refused.
---
~Randy
^ permalink raw reply
* Re: Yet another base64 patch
From: David A. Wheeler @ 2005-04-17 3:53 UTC (permalink / raw)
To: git
In-Reply-To: <20050414205831.01039ee8.pj@engr.sgi.com>
Paul Jackson wrote:
> Earlier, hpa wrote:
>
>>The base64 version has 2^12 subdirectories instead of 2^8 (I just used 2
>>characters as the hash key just like the hex version.)
>
> Later, hpa wrote:
>
>>Ultimately the question is: do we care about old (broken) filesystems?
>
>
> I'd imagine we care a little - just not alot.
Some people (e.g., me) would really like for "git"
to be more forgiving of nasty filesystems,
so that git can be used very widely.
I.E., be forgiving about case insensitivity,
poor performance or problems with a large # of files
in a directory, etc. You're already working to make
sure git handles filenames with spaces & i18n filenames,
a common failing of many other SCM systems.
If "git" is used for Linux kernel development & nothing else,
it's still a success. But it'd be even better from
my point of view if "git" was a useful tool for MANY
other projects. I think there are advantages, even if you
only plan to use git for the kernel, to making "git" easier
to use for other projects. By making git less
sensitive to the filesystem, you'll attract more (non-kernel-dev)
users, some of whom will become new git developers who
add cool new functionality.
As noted in my SCM survey (http://www.dwheeler.com/essays/scm.html),
I think SCM Windows support is really important to a lot of
OSS projects. Many OSS projects, even if they start
Unix/Linux only, spin off a Windows port, and it's
painful if their SCM can't run on Windows then.
Problems running on NFS filesystems have caused problems
with GNU Arch users (there are workarounds, but now you
need to learn about workarounds instead of things
"just working"). If nothing else, look at the history
of other SCM projects: all too many have undergone radical and
painful surgeries so that they can be more portable to
various filesystems.
It's a trade-off, I know.
--- David A. Wheeler
^ permalink raw reply
* Re: Yet another base64 patch
From: Paul Jackson @ 2005-04-17 4:05 UTC (permalink / raw)
To: dwheeler; +Cc: git
In-Reply-To: <4261DDBC.3050706@dwheeler.com>
David wrote:
> It's a trade-off, I know.
So where do you recommend we make that trade-off?
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@engr.sgi.com> 1.650.933.1373, 1.925.600.0401
^ permalink raw reply
* Re: [PATCH] libgit
From: Mike Taht @ 2005-04-17 4:08 UTC (permalink / raw)
To: Randy.Dunlap; +Cc: git
In-Reply-To: <20050416204602.18a124dc.rddunlap@osdl.org>
Fixed.
Randy.Dunlap wrote:
> On Sat, 16 Apr 2005 20:12:56 -0700 Mike Taht wrote:
>
> | commit b0550573055abcf8ad19dcb8a036c32dd00a3be4
> | tree b77882b170769c07732381b9f19ff2dd5c9f1520
> | parent 866b4aea9313513612f2b0d66814a2f526d17f21
> | author Mike Taht <m@picketwyre.com> 1113704772 -0700
> | committer Mike Taht <m@ipbx.taht.net> 1113704772 -0700
> |
> | looks my 1878 line patch to convert git to libgit got eaten by vger..
> | I put it up at http://pbx.picketwyre.com/~mtaht/libgit.patch if anyone
> | wants to comment. from my log:
>
> Connection refused.
>
> ---
> ~Randy
--
Mike Taht
"FLASH! Intelligence of mankind decreasing. Details at ... uh, when
the little hand is on the ...."
^ permalink raw reply
* Re: SHA1 hash safety
From: Paul Jackson @ 2005-04-17 4:09 UTC (permalink / raw)
To: Tkil; +Cc: omb, david.lang, mingo, git
In-Reply-To: <ghdi684sm.fsf@brand.scrye.com>
> but the chance of any collision at all wigs me out.
Guess you're just going to get wigged out then.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@engr.sgi.com> 1.650.933.1373, 1.925.600.0401
^ permalink raw reply
* Re: Yet another base64 patch
From: David Lang @ 2005-04-17 4:10 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Linus Torvalds, bert hubert, Christopher Li, git
In-Reply-To: <425F1394.5020709@zytor.com>
On Thu, 14 Apr 2005, H. Peter Anvin wrote:
> Linus Torvalds wrote:
>>
>> Even something as simple as "ls -l" has been known to have O(n**2)
>> behaviour for big directories.
>>
>
> For filesystems with linear directories, sure. For sane filesystems, it
> should have O(n log n).
note that default configs of ext2 and ext3 don't qualify as sane
filesystems by this definition.
ext3 does have an extention that you can enable to have it hash the
directory access, but even if you enable that on a filesystem you aren't
guaranteed that it will be active (if the directory existed before it was
turned on, or has been accessed by a kernel that didn't understand the
extention then the htree functionality won't be used until you manually
tell the system to generate the tree)
David Lang
--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
-- C.A.R. Hoare
^ permalink raw reply
* Re: [PATCH] Use libcurl to use HTTP to get repositories
From: Linus Torvalds @ 2005-04-17 4:36 UTC (permalink / raw)
To: Paul Jackson; +Cc: Daniel Barkalow, git, pasky
In-Reply-To: <20050416174544.5ca28322.pj@sgi.com>
On Sat, 16 Apr 2005, Paul Jackson wrote:
> Daniel wrote:
> > I'm working off of Linus's tree when not working on scripts, and it
> > doesn't have that section at all.
>
> Ah so - nevermind my README comments then.
Well, actually, I suspect that something like this should go to Pasky. I
really see my repo as purely a "internal git datastructures", and when it
gets to "how do we interact with other peoples web-sites", I suspect
Pasky's tree is better.
Linus
^ permalink raw reply
* Re: SHA1 hash safety
From: David A. Wheeler @ 2005-04-17 4:38 UTC (permalink / raw)
To: Paul Jackson; +Cc: David Lang, cscott, pasky, omb, mingo, git
In-Reply-To: <20050416161153.534b47d5.pj@sgi.com>
Paul Jackson wrote:
>>what I'm talking about is the chance that somewhere, sometime there will
>>be two different documents that end up with the same hash
>
> I have vastly greater chance of a file colliding due to hardware or
> software glitch than a random message digest collision of two legitimate
> documents.
The probability of an accidental overlap for SHA-1 for two
different files is absurdly remote; it's just not worth worrying about.
However, the possibility of an INTENTIONAL overlap is a completely
different matter. I think the hash algorithm should change in the
future; I have a proposal below.
Someone has ALREADY broken into a server to modify the Linux kernel
code already, so the idea of an attack on kernel code
is not an idle fantasy. MD5 is dead, and SHA-1's work factor has
already been sufficiently broken that people have already been told
"walk to the exits" (i.e., DO NOT USE SHA-1 for new programs like git).
The fact that blobs are compressed first, with a length header
in front, _may_ make it harder to attack. But maybe not.
I haven't checked for this case, but most decompression algorithms
I know of have a "don't change" mode that essentially just copies the
data behind it. If the one used in git has such a mode
(I bet it does!), an attacker could use that mode to
make it MUCH easier to create an attack vector than it would
appear at first. Now the attacker just needs to create a collision
(hmmm, where was that paper?). Remember, you don't need to
run a hash algorithm over an entire file; you can precompute
to near the end, and then try your iterations from there.
A little hardware (inc. FPGAs) would speed the attack.
Of course, that assumes you actually
check everything to make sure that an attacker can't slip
in something different. After each rsync, are all new files'
hash values checked? Do they uncompress to right length?
Do they have excess data after the decompression?
I'm hoping that sort of input-checking (since the data
might be from an attacker, if indirectly!) is already going on,
though I haven't reviewed the git source code.
While the jury's still out, the current belief by most folks
I talk to is that SHA-1 variants with more bits, such as SHA-256,
are the way to go now. The SHA-1 attack simply reduces
the work factor (it's not a COMPLETE break), so adding
more bits is believed to increase the work factor
enough to counter it.
Adding more information to the hash can make attacking even harder.
Here's one idea: whenever that hash algorithm
switch occurs, create a new "hash" value as this:
SHA-256 "+" uncompressed-length
Where SHA-256 is computed just like SHA-1 is now, e.g.,
SHA-256(file) where file = typecode + length + compressed data.
Leave the internal format as-is (with the length embedded as well).
This means that an attacker has to come up with an attack
that creates the same length uncompressed, yet has the same hash
of the compressed result. That's harder to do.
Length is also really, really cheap to compute :-).
That also might help the convince the "what happens if there's
an accidental collision" crowd: now, if the file lengths
are different, you're GUARANTEED that the hash values are different,
though that's not the best reason to do that.
One reason to think about switching sooner rather than later
is that it'd be really nice if the object store also included
signatures, so that in one fell swoop you could check who signed what
(and thus you could later on CONFIRM with much more certainty who
REALLY submitted a given change... say if it was clearly malicious).
If you switch hash algorithms, the signatures might not work,
depending on how you do it.
--- David A. Wheeler
^ permalink raw reply
* Re: SHA1 hash safety
From: Tkil @ 2005-04-17 4:43 UTC (permalink / raw)
To: Paul Jackson; +Cc: omb, david.lang, mingo, git
In-Reply-To: <20050416210934.11a27387.pj@sgi.com>
>>>>> "Tkil" == Tkil <tkil@scrye.com> writes:
Tkil> but the chance of any collision at all wigs me out.
>>>>> "Paul" == Paul Jackson <pj@sgi.com> writes:
Paul> Guess you're just going to get wigged out then.
Wig wig. :)
I didn't mean "wigs me out to the point I won't use it" but more of
"wigs me out so that I'm curious whether there are backup schemes
worth considering".
In particular, the comparisons between hash collisions and hardware
failure seem contrived -- if I have bad RAM, or a bad block on my HD,
I can recover it from known good sources. But if the actual known
good source is structured in such a way that a particular set of data
cannot be represented, that bothers me.
In this case, the fact that it has to be the same length, same SHA-1,
correct C, and functionally similar C at that, makes for a comforting
cushion. Further, git wouldn't be the only representation; there
would be periodic tarballs, different trees, etc.
On the other paw, if "effectively random" MS Word docs gave true MD5
collisions (when we have a proper MD5 hash computed over the entire
document) in a "mere" 1e7 space, that is interesting/scary.
(I was also trying to add a few factoids to the MSW comment, as their
structure could lead to collisions if (say) only the first 512 bytes
were considered -- it's possible that nothing but size and date might
change in that, and /those/ I can see colliding in 1e7 documents.)
Finally, I apologize for taking your time. I'm just watching this
from the sidelines, and the questions above are just intellectual
curiosity. :-/
(The only other thread I'm really following is people trying to chunk
files in a way that would increase storage efficiency; reading the
Venti paper, I was wondering how efficient it would be if a one-byte
addition at the top of the file would generate all-new blocks, while
the rsync-ish protocol seems to offer substantial relief. But if the
"interesting history" fits in 10USD worth of HD, that might be enough.
Babble.)
Thanks,
t.
^ permalink raw reply
* Re: [PATCH] update-cache --refresh cache entry leak
From: Junio C Hamano @ 2005-04-17 4:44 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0504162033250.7211@ppc970.osdl.org>
>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
LT> I've seen this patch now three times, and it's been wrong every single
LT> time. Maybe we should add a comment?
I found out the previous two just after I sent it out. Sorry
about that.
^ permalink raw reply
* Re: Storing permissions
From: Linus Torvalds @ 2005-04-17 4:48 UTC (permalink / raw)
To: Paul Jackson; +Cc: Morten Welinder, mj, git
In-Reply-To: <20050416183023.0b27b3a4.pj@sgi.com>
On Sat, 16 Apr 2005, Paul Jackson wrote:
>
> Morten wrote:
> > It makes some sense in principle, but without storing what they mean
> > (i.e., group==?) it certainly makes no sense.
>
> There's no "they" there.
>
> I think Martin's proposal, to which I agreed, was to store a _single_
> bit. If any of the execute permissions of the incoming file are set,
> then the bit is stored ON, else it is stored OFF. On 'checkout', if the
> bit is ON, then the file permission is set mode 0777 (modulo umask),
> else it is set mode 0666 (modulo umask).
I think I agree.
Anybody willing to send me a patch? One issue is that if done the obvious
way it's an incompatible change, and old tree objects won't be valid any
more. It might be ok to just change the "compare cache" check to only care
about a few bits, though: S_IXUSR and S_IFDIR. And then always write new
"tree" objects out with mode set to one of
- 040000: we already do this for directories
- 100644: normal files without S_IXUSR set
- 100755: normal files _with_ S_IXUSR set
Then, at compare time, we only look at S_IXUSR matching for files (we
never compare directory modes anyway). And at file create time, we create
them with 0666 and 0777 respectively, and let the users umask sort it out
(and if the user has 0100 set in his umask, he can damn well blame
himself).
This would pretty much match the existing kernel tree, for example. We'd
end up with some new trees there (and in git), but not a lot of
incompatibility. And old trees would still work fine, they'd just get
written out differently.
Anybody want to send a patch to do this?
Linus
^ permalink raw reply
* Re: [PATCH] Use libcurl to use HTTP to get repositories
From: Ingo Molnar @ 2005-04-17 4:55 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Daniel Barkalow
In-Reply-To: <Pine.LNX.4.21.0504162008190.30848-100000@iabervon.org>
* Daniel Barkalow <barkalow@iabervon.org> wrote:
> Still leaks a bit of memory due to bug copied from read-tree.
Linus, should i resend the 18 fixes i sent the other day? (as a GIT
repository perhaps?) I found roughly 6 common memory leaks, 8
theoretical memory leaks, 2 overflows and did a couple of cleanups. One
of the patches [the cache collision related thing] we agreed was not
needed, the rest is still very much valid i think. I did some basic
testing with the fixes applied, nothing seemed to break in any visible
way in these tests.
Ingo
^ permalink raw reply
* Re: Storing permissions
From: David A. Wheeler @ 2005-04-17 5:00 UTC (permalink / raw)
To: Paul Jackson; +Cc: Junio C Hamano, mj, git
In-Reply-To: <20050416170324.2cf934df.pj@sgi.com>
Paul Jackson wrote:
> Junio wrote:
>
>>Sounds like svn
>
>
> I have no idea what svn is.
svn = common abbreviation for "Subversion", a
widely-used centralized SCM tool intentionally
similar to CVS.
--- David A. Wheeler
^ permalink raw reply
* Re: SHA1 hash safety
From: Paul Jackson @ 2005-04-17 5:09 UTC (permalink / raw)
To: Tkil, David A. Wheeler; +Cc: omb, david.lang, mingo, git
In-Reply-To: <gacny8135.fsf@brand.scrye.com>
I have nothing further to contribute to this subtopic.
Good luck with it.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@engr.sgi.com> 1.650.933.1373, 1.925.600.0401
^ permalink raw reply
* Re: Issues with higher-order stages in dircache
From: Junio C Hamano @ 2005-04-17 5:11 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <7vll7i95u1.fsf_-_@assigned-by-dhcp.cox.net>
Linus,
earlier I wrote [*R1*]:
- An explicit "update-cache [--add] [--remove] path" should
be taken as a signal from the user (or Cogito) to tell the
dircache layer "the merge is done and here is the result".
So just delete higher-order stages for the path and record
the specified path at stage 0 (or remove it altogether).
and I think this commit of yours implements the adding half.
commit be7b1f05cea8e5213ffef8f74ebdefed2aacb6fc:1
author Linus Torvalds <torvalds@ppc970.osdl.org> 1113678345 -0700
committer Linus Torvalds <torvalds@ppc970.osdl.org> 1113678345 -0700
When inserting a index entry of stage 0, remove all old unmerged entries.
I am wondering if you have a particular reason not to do the
same for the removing half. Without it, currently I do not see
a way for the user or Cogito to tell dircache layer that the
merge should result in removal. That is, other than first
adding a phony entry there (which brings the entry down to stage
0) and then immediately doing a regular update-cache --remove.
That is two instead of one reading of 1.6MB index file for the
kernel case.
Also do you have any comments on this one from the same message?
* read-tree
- When merging two trees, i.e. "read-tree -m A B", shouldn't
we collapse identical stage-1/2 into stage-0?
[References]
*R1* http://marc.theaimsgroup.com/?l=git&m=111366023126466&w=2
^ permalink raw reply
* Re: Issues with higher-order stages in dircache
From: Linus Torvalds @ 2005-04-17 5:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v64ym2dju.fsf@assigned-by-dhcp.cox.net>
On Sat, 16 Apr 2005, Junio C Hamano wrote:
>
> I am wondering if you have a particular reason not to do the
> same for the removing half.
No. Except for me being silly.
Please just make it so.
> Also do you have any comments on this one from the same message?
>
> * read-tree
>
> - When merging two trees, i.e. "read-tree -m A B", shouldn't
> we collapse identical stage-1/2 into stage-0?
How do you actually intend to merge two trees?
That sounds like a total special case, and better done with "diff-tree".
But regardless, since I assume the result is the later tree, why do a
"read-tree -m A B", since what you really want is "read-tree B"?
The real merge always needs the base tree, and I'd hate to complicate the
real merge with some special-case that isn't relevant for that real case.
Linus
^ permalink raw reply
* [PATCH] checkout-cache -a should not extract unmerged stages
From: Junio C Hamano @ 2005-04-17 5:30 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
When checkout-cache -a is run, currently it attempts to extract
each existing unmerged stage to the same destination and
complains to what it itself has done. This is nonsensical.
Presumably, the user is running checkout-cache -a in order to
verify the result of the part that has cleanly been merged. So
check out only stage 0 entries and give warnings for paths that
are unmerged.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
checkout-cache.c | 11 +++++++++++
1 files changed, 11 insertions(+)
checkout-cache.c: 431b7032576f40d93a08be801e26f76c168ed57b
--- checkout-cache.c
+++ checkout-cache.c 2005-04-16 22:23:15.000000000 -0700
@@ -121,10 +121,21 @@
static int checkout_all(void)
{
+ struct cache_entry *unmerge_skipping = NULL;
int i;
for (i = 0; i < active_nr ; i++) {
struct cache_entry *ce = active_cache[i];
+ if (ce_stage(ce)) {
+ if (!unmerge_skipping ||
+ strcmp(unmerge_skipping->name, ce->name))
+ fprintf(stderr,
+ "checkout-cache: needs merge %s\n",
+ ce->name);
+ unmerge_skipping = ce;
+ continue;
+ }
+ unmerge_skipping = NULL;
if (checkout_entry(ce) < 0)
return -1;
}
^ permalink raw reply
* Re: Storing permissions
From: Paul Jackson @ 2005-04-17 5:32 UTC (permalink / raw)
To: Linus Torvalds; +Cc: mwelinder, mj, git
In-Reply-To: <Pine.LNX.4.58.0504162138020.7211@ppc970.osdl.org>
Linus wrote:
> It might be ok to just change the "compare cache" check to only care
> about a few bits, though: S_IXUSR and S_IFDIR. And then ...
I think I agree. But since I am reluctant to take enough time to
understand the code well enough to write this patch, I'll shut up now ;).
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@engr.sgi.com> 1.650.933.1373, 1.925.600.0401
^ permalink raw reply
* Re: Storing permissions
From: Linus Torvalds @ 2005-04-17 5:37 UTC (permalink / raw)
To: Paul Jackson; +Cc: Morten Welinder, mj, git
In-Reply-To: <Pine.LNX.4.58.0504162138020.7211@ppc970.osdl.org>
On Sat, 16 Apr 2005, Linus Torvalds wrote:
>
> Anybody want to send a patch to do this?
Actually, I just did it. Seems to work for the only test-case I tried,
namely I just committed it, and checked that the permissions all ended up
being recorded as 0644 in the tree (if it has the -x bit set, they get
recorded as 0755).
When checking out, we always check out with 0666 or 0777, and just let
umask do its thing. We only test bit 0100 when checking for differences.
Maybe I missed some case, but this does indeed seem saner than the "try to
restore all bits" case. If somebody sees any problems, please holler.
(Btw, you may or may not need to blow away your "index" file by just
re-creating it with a "read-tree" after you've updated to this. I _tried_
to make sure that the compare just ignored the ce_mode bits, but the fact
is, your index file may be "corrupt" in the sense that it has permission
sets that sparse expects to never generate in an index file any more..)
Linus
^ permalink raw reply
* [PATCH] show-diff.c: do not include unused header file
From: Junio C Hamano @ 2005-04-17 5:39 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
This is my bad. I added #include <ctype.h> to the file,
which I ended up not using and failed to remove it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
show-diff.c: d85d79b97a59342390bd34da09049dd58d56900f
--- show-diff.c
+++ show-diff.c 2005-04-16 22:37:29.000000000 -0700
@@ -4,7 +4,6 @@
* Copyright (C) Linus Torvalds, 2005
*/
#include "cache.h"
-#include <ctype.h>
static char *diff_cmd = "diff -L '%s' -u -N - '%s'";
^ permalink raw reply
* [PATCH] Add lsremote command.
From: Steven Cole @ 2005-04-17 5:36 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
[-- Attachment #1: Type: text/plain, Size: 238 bytes --]
This is a fairly trivial addition, but if users are adding remote repositories
with git addremote, then those users should be able to list out the remote
list without having to know the details of where the remotes file is kept.
Steven
[-- Attachment #2: add-lsremote-command.diff --]
[-- Type: text/x-diff, Size: 1013 bytes --]
Adds lsremote command to list remotes.
Signed-Off-By: Steven Cole <elenstev@mesatop.com>
-------------
diff -urN git-pasky-orig/git git-pasky/git
--- git-pasky-orig/git 2005-04-16 22:47:22.000000000 -0600
+++ git-pasky/git 2005-04-16 22:49:14.000000000 -0600
@@ -41,6 +41,7 @@
log
ls [TREE_ID]
lsobj [OBJTYPE]
+ lsremote
merge -b BASE_ID FROM_ID
pull [RNAME]
rm FILE...
@@ -105,6 +106,7 @@
"log") gitlog.sh "$@";;
"ls") gitls.sh "$@";;
"lsobj") gitlsobj.sh "$@";;
+"lsremote") gitlsremote.sh "$@";;
"merge") gitmerge.sh "$@";;
"pull") gitpull.sh "$@";;
"rm") gitrm.sh "$@";;
diff -urN git-pasky-orig/gitlsremote.sh git-pasky/gitlsremote.sh
--- git-pasky-orig/gitlsremote.sh 1969-12-31 17:00:00.000000000 -0700
+++ git-pasky/gitlsremote.sh 2005-04-16 22:58:15.000000000 -0600
@@ -0,0 +1,7 @@
+#!/bin/sh
+#
+# ls remotes in GIT repository
+#
+[ -e .git/remotes ] && cat .git/remotes && exit 1
+
+echo 'List of remotes is empty. See git addremote.'
^ permalink raw reply
* [PATCH] Fix off-by-one error in show-diff
From: Junio C Hamano @ 2005-04-17 5:56 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
The patch to introduce shell safety to show-diff has an
off-by-one error. Here is an fix.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
show-diff.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
show-diff.c: 8a24ff62b85a6e23469e3f0e7a20170dfe543ebf
--- show-diff.c
+++ show-diff.c 2005-04-16 22:53:11.000000000 -0700
@@ -27,8 +27,8 @@
int cnt, c;
char *cp;
- /* count single quote characters */
- for (cnt = 0, cp = src; *cp; cnt++, cp++)
+ /* count bytes needed to store the quoted string. */
+ for (cnt = 1, cp = src; *cp; cnt++, cp++)
if (*cp == '\'')
cnt += 3;
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox