* Re: [RFC] diff-cache buglet
From: Junio C Hamano @ 2005-04-26 20:34 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0504261207380.18901@ppc970.osdl.org>
>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
LT> On Tue, 26 Apr 2005, Junio C Hamano wrote:
>>
>> We should just fix "remove-merge-entries" and call that
>> unconditionally before the read-tree is called. Once it is
>> fixed, we need to think about how to show this stage
>> information but that should be a separate discussion.
LT> I just thought that _if_ you wanted the unmerged parts to show up, then
LT> the "1//filename.c" thing might be acceptable. Personally, I just think
LT> diff-cache is pretty nonsensical with unmerged files,
I agree to what you said here. We are not interested in the
unmerged files in the original GIT_INDEX_FILE at all.
However, remember that "unmerged" entries diff_cache() function
sees are from the tree you are comparing against, either your
GIT_INDEX_FILE (with --cached) or your working tree (without).
Currently I suspect the behaviour of diff-cache without --cached
flag may be broken. Don't we need to check cached_only before
or inside of the first two if() statements in diff_cache()? For
a path that appears in the tree you are comparing against (i.e.
stage 1 entries):
- if GIT_INDEX_FILE does not have it but the working tree does,
it would still say "deleted".
- if GIT_INDEX_FILE does have it, the comparison goes against
that entry, not against the working tree.
Similarly for entries that are not in the stage 1, the code ends
up comparing only the dircache entries and never goes to the
filesystem.
Here is a proposed fix. When running without --cached,
diff_cache function really goes to the filesystem if the stage 0
entry in GIT_INDEX_FILE does not match what is in the working
tree for these cases.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff-cache.c | 40 ++++++++++++++++++++++++++++++++++++----
1 files changed, 36 insertions(+), 4 deletions(-)
./jit-snap -v 3:6
# - 04/26 12:25 Fix agreed with Linus.
# + 04/26 13:26 Proposed fix.
--- k/diff-cache.c
+++ l/diff-cache.c
@@ -10,6 +10,19 @@ static void show_file(const char *prefix
sha1_to_hex(ce->sha1), ce->name, line_termination);
}
+/* A file *may* have been added to the working tree */
+static void show_possible_local_add(struct cache_entry *new)
+{
+ static unsigned char no_sha1[20];
+ struct stat st;
+ if (stat(new->name, &st) < 0)
+ return; /* no, working tree does not have one. */
+ if (cache_match_stat(new, &st))
+ return show_file("+", new);
+
+ printf("+%o\t%s\t%s\t%s%c", st.st_mode, "blob",
+ sha1_to_hex(no_sha1), new->name, line_termination);
+}
static int show_modified(struct cache_entry *old, struct cache_entry *new)
{
unsigned int mode = ntohl(new->ce_mode), oldmode;
@@ -29,6 +42,8 @@ static int show_modified(struct cache_en
mode = st.st_mode;
sha1 = no_sha1;
}
+ else if (old == new)
+ return 0;
}
oldmode = ntohl(old->ce_mode);
@@ -48,16 +63,33 @@ static int diff_cache(struct cache_entry
while (entries) {
struct cache_entry *ce = *ac;
- /* No matching 0-stage (current) entry? Show it as deleted */
+ /* No matching 0-stage (current) entry?
+ * Show it as deleted.
+ */
if (ce_stage(ce)) {
- show_file("-", ce);
+ /* ... well, not so fast. We may have it in the
+ * working tree and operating without --cache.
+ */
+ if (cached_only)
+ show_file("-", ce);
+ else
+ /* this is sneaky but it works. trust me. */
+ show_modified(ce, ce);
ac++;
entries--;
continue;
}
- /* No matching 1-stage (tree) entry? Show the current one as added */
+ /* No matching 1-stage (tree) entry?
+ * Show the current one as added.
+ */
if (entries == 1 || !same_name(ce, ac[1])) {
- show_file("+", ce);
+ /* ... again, we may not have that in the
+ * working tree and operating without --cache.
+ */
+ if (cached_only)
+ show_file("+", ce);
+ else
+ show_possible_local_add(ce);
ac++;
entries--;
continue;
^ permalink raw reply
* Re: Merge with git-pasky II.
From: Daniel Barkalow @ 2005-04-26 20:31 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Bram Cohen, git
In-Reply-To: <Pine.LNX.4.58.0504261256150.18901@ppc970.osdl.org>
On Tue, 26 Apr 2005, Linus Torvalds wrote:
>
>
> On Tue, 26 Apr 2005, Bram Cohen wrote:
> >
> > If one person renames a file and another person modifies it then the
> > changes should be applied to the moved file.
>
> Bzzt. Wrong answer.
>
> The _right_ answer is "if one person moves a function, and another person
> modifies the function, the changes should be applied to the moved
> function".
I'd even go so far as to say that we need to have the user sign off on
this. The modification is reasonably likely to not work in the new
location, due to use of statics that aren't available or something of the
sort.
I suspect that we want to report a conflict in the new location between
the old version and the new version, and let the person merging check
whether the change is okay. That is, both sides modified the same section
at the same time: one side modified its content, while the other modified
its location. We can give a good suggestion, but we need a final ruling.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Merge with git-pasky II.
From: Bram Cohen @ 2005-04-26 20:31 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0504261256150.18901@ppc970.osdl.org>
Linus Torvalds wrote:
> On Tue, 26 Apr 2005, Bram Cohen wrote:
> >
> > If one person renames a file and another person modifies it then the
> > changes should be applied to the moved file.
>
> Bzzt. Wrong answer.
I'm trying to be polite. You're not making that easy.
> The _right_ answer is "if one person moves a function, and another person
> modifies the function, the changes should be applied to the moved
> function".
Now that you're done being dismissive, could you either (a) rebut my quite
detailed explanation of exactly why that functionality is both a dubious
idea and difficult to implement, or (b) admit that you have no plans
whatsoever for supporting any of this stuff? You can't have it both ways.
What I'd really like to hear is some explanation of why git is
reimplementing all of this stuff from scratch. Your implicit claims that
git will do more things than the other systems without having to reinvent
all of their functionality first are, honestly, naive, ill-informed
arrogance.
I'd like to reiterate that *nothing* out there supports moving lines
between files, and further predict, with total confidence, that if git
tries to support such functionality it will simply fail, either by giving
up or creating a system which can behave horribly. Before you get all
dismissive about this claim, please remember that I've spent years
thinking about merge algorithms, and have actually designed and
implemented them, and have spoken at length with other people who have
done the same, while you've merely thought about them for a few weeks.
> Which is clearly a _much_ more common case than file renames.
Even if we pretend that these are comparable features, that's far from
clearly true. Function moves within a file occur more frequently, but a
file rename moves *all* the functions within that file.
> In other words, if your algorithm doesn't handle the latter, then there is
> no point in handling the former either.
If someone offers you a dollar, no strings attached, do you turn them down
because they didn't offer you ten?
> And _if_ your algorithm handles the latter, then there's no point in
> handling file renames specially, since the algorithm will have done that
> too, as a small part of it.
In case these concepts got conflated, I'd like to point out that Codeville
merge both supports renames *and* does better than three-way merge can do
at merging a single, non-renamed file. In most cases three-way and
codeville merge give the same answer, but there are some cases where there
isn't a single appropriate LCA available, and in those cases codeville
will do the right thing while three-way can't.
-Bram
^ permalink raw reply
* Re: Mercurial 0.3 vs git benchmarks
From: Bill Davidsen @ 2005-04-26 20:30 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Linus Torvalds, Mike Taht, Matt Mackall, linux-kernel, git
In-Reply-To: <426E852A.40904@zytor.com>
H. Peter Anvin wrote:
> Linus Torvalds wrote:
>
>>
>> And don't try to make me explain why the patchbomb has any IO time at
>> all,
>> it should all have fit in the cache, but I think the writeback logic
>> kicked in.
>
>
> The default log size on ext3 is quite small. Making the log larger
> probably would have helped.
Experience tells me that making the log larger does very good things for
performance in many load types. However, that fsync issue forcing the
write of the whole log may get worse if there's a lot pending.
I suspect this would be helped by noatime.
--
-bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
^ permalink raw reply
* Re: Merge with git-pasky II.
From: Tom Lord @ 2005-04-26 20:30 UTC (permalink / raw)
To: torvalds; +Cc: bram, git
In-Reply-To: <Pine.LNX.4.58.0504261256150.18901@ppc970.osdl.org>
From: Linus Torvalds <torvalds@osdl.org>
On Tue, 26 Apr 2005, Bram Cohen wrote:
>
> If one person renames a file and another person modifies it then the
> changes should be applied to the moved file.
Bzzt. Wrong answer.
You're a little bit nuts, guy.
-t
^ permalink raw reply
* Re: unseeking?
From: Petr Baudis @ 2005-04-26 20:28 UTC (permalink / raw)
To: Zack Brown; +Cc: Daniel Barkalow, git
In-Reply-To: <20050425222833.GA21107@tumblerings.org>
Dear diary, on Tue, Apr 26, 2005 at 12:28:33AM CEST, I got a letter
where Zack Brown <zbrown@tumblerings.org> told me that...
> So, I did 'git patch pasky:this', and got the following. Is this an appropriate
> way to submit a patch? BTW, the 'truckload' fix I tried to change back by
> editing the README again, and committing the change; but the git patch command
> still shows the change.
Because it just exports individual patches. Use git diff (cg-diff) if
you want to get the cummulative diff.
Could you please sign off your patch?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: [PATCH] cogito - split out cg-X* to prefix/lib/cogito
From: Petr Baudis @ 2005-04-26 20:25 UTC (permalink / raw)
To: Joshua T. Corbin; +Cc: git
In-Reply-To: <200504260053.33506.jcorbin@wunjo.org>
Dear diary, on Tue, Apr 26, 2005 at 06:53:33AM CEST, I got a letter
where "Joshua T. Corbin" <jcorbin@wunjo.org> told me that...
> The following patch does the following:
> * Change the Makefile to install all cg-X* to $(prefix)/lib/cogito
> * Modify all cg-* to use this lib prefix.
>
> Basically the cg-* script looks at $0, if it appears to be in a prefix/bin
> directory that also has a prefix/lib/cogito directory, look for the cg-X*
> there; otherwise things will work as in old.
>
> Signed-off-by: Joshua T. Corbin <jcorbin@wunjo.org>
>
> Index: cg-Xdiffdo
> ===================================================================
> --- ddd5e0ab084034b713bb2f7d9de6f365d5a2e5bf/cg-Xdiffdo (mode:100755
> sha1:e3907b39ea105acb2f2ac3659f16898604b72d09)
> +++ bb131a04832677b22959ffe47f68900b94accc0c/cg-Xdiffdo (mode:100755
> sha1:832fd2c2a09274b5279327e1c31b99afc04fa7f1)
> @@ -12,7 +12,16 @@
> #
> # Outputs a diff converting the first tree to the second one.
>
> -. cg-Xlib
> +if [ -z "$COGITO_LIB" ]; then
> + COGITO_LIB=$(dirname $(dirname $0))/lib/cogito
> + if [ -d $COGITO_LIB ]; then
> + COGITO_LIB=$COGITO_LIB/
> + else
> + COGITO_LIB=
> + fi
> +fi
> +
> +. ${COGITO_LIB}cg-Xlib
>
>
> id1=$1; shift
I think this is wrong, stuffing too much redundant logic to all those
files. I'm fine with the last added line, but nothing more. What about
rewriting the scripts during make install, doing something like
s/\${COGITO_LIB}/\${COGITO_LIB:-$(libdir)}/
?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: [PATCH] cg-export to tarball
From: Petr Baudis @ 2005-04-26 20:20 UTC (permalink / raw)
To: Joshua T. Corbin; +Cc: Rene Scharfe, git
In-Reply-To: <200504260312.46320.jcorbin@wunjo.org>
Dear diary, on Tue, Apr 26, 2005 at 09:12:46AM CEST, I got a letter
where "Joshua T. Corbin" <jcorbin@wunjo.org> told me that...
> The following patch to cg-export will simlpy create a tarball if the argument
> ends in .tar.gz, .tar.bz2, or .tar.
>
> Signed-off-by; Joshua T. Corbin <jcorbin@wunjo.org>
What about cooperating with Rene Scharfe and using his tar-tree?
I didn't actually try it yet (not even look at the code so far),
it'd be cool if someone would give it some review and testing.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: : Networking
From: Linus Torvalds @ 2005-04-26 20:11 UTC (permalink / raw)
To: Andrew Morton; +Cc: pasky, davem, git
In-Reply-To: <20050426125141.6ec38d31.akpm@osdl.org>
On Tue, 26 Apr 2005, Andrew Morton wrote:
>
> With bk I was resolving that by just smashing the patches on top of each
> other, ignoring the rejects and refreshing the topmost patch. That
> approach actually resolved this linus-vs-davem dupe as well.
Oh, wow. I didn't realize that your scripts were quite _that_ stupid, and
didn't actually take advantage of any automatic merges at all.
If so, git should trivially do everything that BK ever did for you. Which
is not saying a lot ;)
Linus
^ permalink raw reply
* Re: git-pasky "tutorial"
From: Petr Baudis @ 2005-04-26 19:57 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: git
In-Reply-To: <1114306508.5444.7.camel@gaston>
Dear diary, on Sun, Apr 24, 2005 at 03:35:08AM CEST, I got a letter
where Benjamin Herrenschmidt <benh@kernel.crashing.org> told me that...
> Hi !
Hi,
> Is it really only my own stupidity, or is the "tutorial" in the README
> file in there only understandable if you in fact already know what it
> tries to explain ?
>
> The more I read it, the more confused I am about the whole thing...
>
> Is there some document somewhere that starts by explaining what are the
> concepts of "branch", "tracking", etc... in the context of git ?
you might want to try again with cogito-0.8; I hope I simplified the
concepts a lot.
There is no tracking, and branches are trivial - branches correspond to
repositories. When you do cg-init <remoterepo>, you get a branch origin
which represents the remoterepo (and gets updated when you do cg-pull or
cg-update), you can make Cogito know of more remote repositories by
doing cg-branch-add.
Yes, the README sucks; but apparently it helps at least some people. ;-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: Merge with git-pasky II.
From: Linus Torvalds @ 2005-04-26 19:58 UTC (permalink / raw)
To: Bram Cohen; +Cc: git
In-Reply-To: <Pine.LNX.4.44.0504261129500.4678-100000@wax.eds.org>
On Tue, 26 Apr 2005, Bram Cohen wrote:
>
> If one person renames a file and another person modifies it then the
> changes should be applied to the moved file.
Bzzt. Wrong answer.
The _right_ answer is "if one person moves a function, and another person
modifies the function, the changes should be applied to the moved
function".
Which is clearly a _much_ more common case than file renames.
In other words, if your algorithm doesn't handle the latter, then there is
no point in handling the former either.
And _if_ your algorithm handles the latter, then there's no point in
handling file renames specially, since the algorithm will have done that
too, as a small part of it.
Linus
^ permalink raw reply
* Re: Mercurial 0.3 vs git benchmarks
From: Chris Mason @ 2005-04-26 19:52 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Mike Taht, Matt Mackall, linux-kernel, git
In-Reply-To: <200504261339.34680.mason@suse.com>
On Tuesday 26 April 2005 13:39, Chris Mason wrote:
> As an example, here's the time to apply 300 patches on ext3. This was with
> my packed patches applied, but vanilla git should show similar percentage
> differences.
>
> data=writeback 32s
> data=ordered 44s
>
> With a long enough test, data=ordered should fall into the noise, but 10-40
> second runs really show it.
I get much closer numbers if the patches directory is already in
cache...data=ordered means more contention for the disk when trying to read
the patches.
If the patches are hot in the cache data=writeback and data=ordered both take
about 30s. You still see some writes in data=writeback, but these are mostly
async log commits.
The same holds true for vanilla git as well, although it needs 1m7s to apply
from a hot cache (sorry, couldn't resist the plug ;)
-chris
^ permalink raw reply
* Re: : Networking
From: Andrew Morton @ 2005-04-26 19:51 UTC (permalink / raw)
To: Linus Torvalds; +Cc: pasky, davem, git
In-Reply-To: <Pine.LNX.4.58.0504261209470.18901@ppc970.osdl.org>
Linus Torvalds <torvalds@osdl.org> wrote:
>
>
>
> On Tue, 26 Apr 2005, Andrew Morton wrote:
> >
> > I don't know if it'll be successful continually merging all those trees
> > together. The way I did this with bk was to have a separate repo for each
> > tree, but I don't think I'll want 30-40 separate git trees.
>
> You really don't. With git, the only thing you need is one object store,
> and some way to _track_ those 30-40 separate git trees (and "track" really
> means "remember a single SHA1 name for their top-of-tree").
Petr's wrappers do all that head tracking OK (which is why I'm using a
combo of those and of lower-level gittiness). They do handy remote repo
tracking too.
> Then you can merge any combination of the 40 in the same tree.
>
> You'll get confused easily, but if you do this all with tools, it
> shouldn't be too bad.
>
> > So hm. I guess git did what it was supposed to do here, and that a `git
> > merge' would have removed the common patch. But if I take the approach of
> > merging all those subsystem trees I do wonder if things will come
> > unstuck...
>
> Well, git isn't as good at merging as BK is, and your usage sure as hell
> would be a horrible worst-case example, but it might actually work fine.
> Git merges are _cheap_ (with a capital C, and probably H as well) when
> they work out, and quite frankly, so far they have always worked out for
> me.
>
> But yeah, you'd be doing some pretty aggressive merging, using a tool that
> is two weeks old. It might work. I'd be interested to know ;)
Hm. For now I might try what I have plus Jan's fancy interdiff command to
remove duped patches. We'll see. I obtained a copy of Tony's ia64 diff
quite happily - it didn't have any duplicates.
(It's fairly common for two subsystem maintainers to apply the same patch.
With bk I was resolving that by just smashing the patches on top of each
other, ignoring the rejects and refreshing the topmost patch. That
approach actually resolved this linus-vs-davem dupe as well. But the duped
patch was so damn BIG that it threw me. And I wasn't feeling gitty enough
to go hunting about looking for the particular patch(es) which caused the
problem)
^ permalink raw reply
* (unknown)
From: Bram Cohen @ 2005-04-26 19:14 UTC (permalink / raw)
To: git
Linus Torvalds wrote:
> What you can do at an SCM level, is that if you want to track renames,
> you track them as a separate commit altogether. Ie if you notice a
> rename, you first commit the rename (and you can _see_ it's a rename,
> since the object didn't change, and the sha1 stayed the same, which in
> git-speak means that it is the same object, ie that _is_ a rename as far
> as git is concerned), and then you create the "this is the data that
> changed" as a _second_ commit.
If a rename and a modification happen at the same time, you'll now have a
point in the history which has the modification but not the rename, which
will probably be completely broken. If a file is deleted and two identical
copies of the file are made at the same time, no inference of renaming can
be made. And sometimes people really do delete one file and make a new
different file with initially identical contents, and this will break that
case.
> But don't make it a new kind of commit. It's just a regular commit,
> dammit. No new abstractions.
You did just introduce a new abstraction, it just happens to be of the 'if
I say X I really mean Y' type, which is far more semantically weighty,
tricky to implement, and on top of that is just plain a gross hack.
> Some "higher level" thing can add its own rules _on_top_ of git rules.
> The same way we have normal applications having their _own_ rules on top
> of the kernel. You do abstraction in layers, but for this to work, the
> base you build on top of had better be damn solid, and not have any ugly
> special cases.
What you're advocating is unclear here, but if you're advocating that the
higher-level system store extra meta-data, not included in git, then that
means the higher-level tools won't be able to interoperate by pointing at
the same git store. And it won't get rid of the problems of storing
information which git doesn't currently, it just makes them be handled by
different code. You can't make these problems go away by getting angry at
them.
I for one am all in favor of blessing Cogito as the 'real' git interface,
with plans to write upgrade scripts which canonically change the current
git format into a new format when upgrades become necessary. There are
already several version control systems with appropriate back end systems
which aren't literally weekend hacks. But you currently seem to be
insisting that such an upgrade will never be necessary, even while
insisting that git will support functionality which it can't.
-Bram
^ permalink raw reply
* Re: : Networking
From: Linus Torvalds @ 2005-04-26 19:13 UTC (permalink / raw)
To: Andrew Morton; +Cc: Petr Baudis, davem, git
In-Reply-To: <20050426115609.0481401b.akpm@osdl.org>
On Tue, 26 Apr 2005, Andrew Morton wrote:
>
> I don't know if it'll be successful continually merging all those trees
> together. The way I did this with bk was to have a separate repo for each
> tree, but I don't think I'll want 30-40 separate git trees.
You really don't. With git, the only thing you need is one object store,
and some way to _track_ those 30-40 separate git trees (and "track" really
means "remember a single SHA1 name for their top-of-tree").
Then you can merge any combination of the 40 in the same tree.
You'll get confused easily, but if you do this all with tools, it
shouldn't be too bad.
> So hm. I guess git did what it was supposed to do here, and that a `git
> merge' would have removed the common patch. But if I take the approach of
> merging all those subsystem trees I do wonder if things will come
> unstuck...
Well, git isn't as good at merging as BK is, and your usage sure as hell
would be a horrible worst-case example, but it might actually work fine.
Git merges are _cheap_ (with a capital C, and probably H as well) when
they work out, and quite frankly, so far they have always worked out for
me.
But yeah, you'd be doing some pretty aggressive merging, using a tool that
is two weeks old. It might work. I'd be interested to know ;)
Linus
^ permalink raw reply
* Re: [RFC] diff-cache buglet
From: Linus Torvalds @ 2005-04-26 19:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk6mpnz96.fsf@assigned-by-dhcp.cox.net>
On Tue, 26 Apr 2005, Junio C Hamano wrote:
>
> We should just fix "remove-merge-entries" and call that
> unconditionally before the read-tree is called. Once it is
> fixed, we need to think about how to show this stage
> information but that should be a separate discussion.
I already applied that part of your fix and pushed it out, there as no
question about that one.
I just thought that _if_ you wanted the unmerged parts to show up, then
the "1//filename.c" thing might be acceptable. Personally, I just think
diff-cache is pretty nonsensical with unmerged files,
Linus
^ permalink raw reply
* Re: cg-add and update-cache add fails
From: Petr Baudis @ 2005-04-26 19:02 UTC (permalink / raw)
To: Rhys Hardwick; +Cc: git
In-Reply-To: <200504261735.47008.rhys@rhyshardwick.co.uk>
Dear diary, on Tue, Apr 26, 2005 at 06:35:46PM CEST, I got a letter
where Rhys Hardwick <rhys@rhyshardwick.co.uk> told me that...
> Here is the error I get:
>
> rhys@metatron:~/repo/learning.repo$ cg-add w1p4d1.c
> fatal: Unable to add w1p4d1.c to database
> rhys@metatron:~/repo/learning.repo$ update-cache --add w1p4d1.c
> fatal: Unable to add w1p4d1.c to database
>
> All the files under the .git folder appear to be owned by me, and are
> read-writable. The disk is not full.
Could you please show output of ls -l w1p4d1.c, done in the same
directory?
Thanks,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: : Networking
From: Andrew Morton @ 2005-04-26 18:56 UTC (permalink / raw)
To: Petr Baudis; +Cc: davem, torvalds, git
In-Reply-To: <20050426183350.GB13224@pasky.ji.cz>
Petr Baudis <pasky@ucw.cz> wrote:
>
> > d) To generate davem's tree (patch against linus's current tree (ie: patch
> > against 2.6.12-rc3+linus.patch)):
> >
> > git pull git-net
> > MERGE_BASE=$(merge-base $(cat .git/heads/origin ) $(cat .git/heads/git-net))
> > git diff -r $MERGE_BASE:$(cat .git/heads/git-net) > ../25/patches/git-net.patch
>
> This is the bad way; I think this suffers of basically the same problems
> as my ancient merging by "forward-patching". You should probably do a
> regular merge:
>
> git pull git-net
> git merge git-net
> git diff -p
>
> The last command will show diff between current tree and the first
> parent; that amounts the merged patch in this case.
Bear in mind that there will be 20 or 30 different trees which I'll need
the diffs for, not just the one git-net.
I don't know if it'll be successful continually merging all those trees
together. The way I did this with bk was to have a separate repo for each
tree, but I don't think I'll want 30-40 separate git trees.
My little methodology worked nicely for git-ia64.
Jan Harkes has pointed out that the problem here is that Linus and Dave
both applied the same patch from Al and that interdiff was able to fix it
up:
$ git diff -r 25ee7e3832951cf5896b194f6cd929a44863f419:b453257f057b834fdf9f4a6ad6133598b79bd982 > git-linus.patch
$ git diff -r 25ee7e3832951cf5896b194f6cd929a44863f419:5523662c4cd585b892811d7bb3e25d9a787e19b3 > git-net.patch
$ interdiff --no-revert-omitted -p1 git-linus.patch git-net.patch | diffstat
drivers/net/tg3.c | 73 ++++++++++++++-------------
net/ipv4/ip_output.c | 2
net/ipv4/netfilter/ip_conntrack_ftp.c | 4 -
net/ipv4/netfilter/ip_conntrack_standalone.c | 7 --
net/ipv4/tcp_input.c | 1
net/sched/simple.c | 18 ------
6 files changed, 46 insertions(+), 59 deletions(-)
So hm. I guess git did what it was supposed to do here, and that a `git
merge' would have removed the common patch. But if I take the approach of
merging all those subsystem trees I do wonder if things will come
unstuck...
^ permalink raw reply
* Re: [RFC] diff-cache buglet
From: Junio C Hamano @ 2005-04-26 18:56 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0504261137350.18901@ppc970.osdl.org>
>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
LT> On Tue, 26 Apr 2005, Junio C Hamano wrote:
>>
>> Well, I somehow thought these things are in fixed column format;
>> mode, ->, sha, stage, and filename are all seperated with either
>> ' ' or '\t'. So if I copy MN to "1 MN", presumably you would
>> see this:
>>
>> 100644 a716d58de4a570e0038f5c307bd8db34daea021f 0 MN
>> 100644 a716d58de4a570e0038f5c307bd8db34daea021f 0 1 MN
>>
>> So while I agree that // would also work, I fail to see why you
>> would even need that.
LT> Because I'd rather _not_ have the 0 in there at all for the normal case.
LT> Yes, it's there for "show-files --stages", but it's certainly _not_ there
LT> in "diff-tree" output right now.
I know. But first let's step back a bit.
Running diff-cache when you have unmerged entries in your
GIT_INDEX_FILE is fundamentally broken. You first read_cache(),
and then you read-tree into stage 1 of the named tree, and at
that point, you do not know what stage 1 means.
We should just fix "remove-merge-entries" and call that
unconditionally before the read-tree is called. Once it is
fixed, we need to think about how to show this stage
information but that should be a separate discussion.
I have attached two versions of patch. The first one is against
the original before my stupid question; the second one is
against the one if you applied my previous patch, to revert most
of its stupidity.
################################################################
--- Patch against the original before I asked that stupid question:
cd /opt/packrat/playpen/public/in-place/git/git.junio/
jit-snap -v 0
--- k/diff-cache.c
+++ l/diff-cache.c
@@ -76,7 +76,7 @@ static void remove_merge_entries(void)
for (i = 0; i < active_nr; i++) {
struct cache_entry *ce = active_cache[i];
if (!ce_stage(ce))
- break;
+ continue;
printf("%s: unmerged\n", ce->name);
while (remove_entry_at(i)) {
if (!ce_stage(active_cache[i]))
################################################################
--- Patch to revert the stupidity:
cd /opt/packrat/playpen/public/in-place/git/git.junio/
jit-snap -v 2
--- k/diff-cache.c
+++ l/diff-cache.c
@@ -1,6 +1,5 @@
#include "cache.h"
-static int leave_unmerged = 0;
static int cached_only = 0;
static int line_termination = '\n';
@@ -86,8 +85,7 @@ static void remove_merge_entries(void)
}
}
-static char *diff_cache_usage =
-"diff-cache [-r] [-z] [--cached] [--unmerged] <tree sha1>";
+static char *diff_cache_usage = "diff-cache [-r] [-z] [--cached] <tree sha1>";
int main(int argc, char **argv)
{
@@ -112,18 +110,13 @@ int main(int argc, char **argv)
cached_only = 1;
continue;
}
- if (!strcmp(arg, "--unmerged")) {
- leave_unmerged = 1;
- continue;
- }
usage(diff_cache_usage);
}
if (argc != 2 || get_sha1_hex(argv[1], tree_sha1))
usage(diff_cache_usage);
- if (!leave_unmerged)
- remove_merge_entries();
+ remove_merge_entries();
tree = read_tree_with_tree_or_commit_sha1(tree_sha1, &size, 0);
if (!tree)
^ permalink raw reply
* Re: Merge with git-pasky II.
From: Bram Cohen @ 2005-04-26 18:55 UTC (permalink / raw)
To: git
(my apologies for responding to old messages, I only just subscribed to
this list)
Linus Torvalds wrote:
> On Thu, 14 Apr 2005, Junio C Hamano wrote:
> >
> > You say "merge these two trees" above (I take it that you mean
> > "merge these two trees, taking account of this tree as their
> > common ancestor", so actually you are dealing with three trees),
>
> Yes. We're definitely talking three trees.
The LCA for different files might be at different points in the history.
Forcing them to all come from the same point produces very bad merges.
> The fact is, we know how to make tree merges unambiguous, by just
> totally ignoring the history between them. Ie we know how to merge
> data. I am pretty damn sure that _nobody_ knows how to merge "data over
> time".
You're incorrect. Codeville does exactly that (history-aware merges which
do the right thing even in cases where 3-way merge can't)
> > This however opens up another set of can of worms---it would
> > involve not just three trees but all the trees in the commit
> > chain in between.
>
> Exactly. I seriously believe that the model is _broken_, simply because
> it gets too complicated. At some point it boils down to "keep it simple,
> stupid".
The Codeville merge algorithm is also quite simple, and is already
implemented and mature.
> I've not even been convinved that renames are worth it. Nobody has
> really given a good reason why.
If one person renames a file and another person modifies it then the
changes should be applied to the moved file.
Also, there's the directory rename case where one person moves a directory
and another person adds a file to it, in which case the file should be
moved to the new directory location on merge. I gather than BK doesn't
support this functionality, but Codeville and Monotone both do.
> I think you might as well interpret the whole object thing. Git
> _does_ tell you how the objects changed, and I actually believe that a
> diff that works in between objects (ie can show "these lines moved from
> this file X to tjhat file Y") is a _hell_ of a lot more powerful than
> "rename" is.
>
> So I'd seriously suggest that instead of worryign about renames,
> people think about global diffs that aren't per-file. Git is good at
> limiting the changes to a set of objects, and it should be entirely
> possible to think of diffs as ways of moving lines _between_ objects and
> not just within objects. It's quite common to move a function from one
> file to another - certainly more so than renaming the whole file.
>
> In other words, I really believe renames are just a meaningless special
> case of a much more interesting problem. Which is just one reason why
> I'm not at all interested in bothering with them other than as a "data
> moved" thing, which git already handles very well indeed.
Nothing, not eveny our beloved BitKeeper, has 'move lines between files'
functionality, and for good reason.
To begin with, it's behaviorally extremely dubious. It would be not
uncommon for the system to erroneously think that some files deleted from
one file were added to another, and then further changes down the line
would cause random unrelated files to get modified in unpredictable ways
when merges happened.
Also, it presents a completely unsolved UI problem. If one person moves
lines 5-15 of file A to file B, and another person concurrently rewrites
lines 10-20 of file A, how on earth is that supposed to be presented to
the user? Codeville can support line moves *within* files just fine, but
doesn't do it because of the UI problem of presenting all the corner
cases. Maybe someday somebody will do a PhD thesis on that topic and we'll
add it, but until then we're sticking with the basic functionality.
Honestly, that you would think of doing whole-tree three-way merges and
even consider moving lines between files shows that you haven't explored
the merge problem very deeply. This is a much harder problem than you
think it is, and one which has already been solved by other systems.
-Bram
^ permalink raw reply
* Re: [PATCH] Set AUTHOR_DATE in git-tools
From: Greg KH @ 2005-04-26 18:44 UTC (permalink / raw)
To: David Woodhouse; +Cc: torvalds, git
In-Reply-To: <1114068737.29135.17.camel@localhost.localdomain>
On Thu, Apr 21, 2005 at 05:32:16PM +1000, David Woodhouse wrote:
> Entirely untested.
Doesn't work :(
And I couldn't see a simple reason why, oh well.
greg k-h
^ permalink raw reply
* Re: [PATCH] introduce xmalloc and xrealloc
From: Christopher Li @ 2005-04-26 15:42 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git mailing list
In-Reply-To: <Pine.LNX.4.58.0504261125220.18901@ppc970.osdl.org>
On Tue, Apr 26, 2005 at 11:25:58AM -0700, Linus Torvalds wrote:
>
> I'd prefer xmalloc()/xrealloc() instead, and just do it in one place.
Done.
Chris
Introduce xmalloc and xrealloc
Signed-off-by: Christopher Li<chrislgit@chrisli.org>
Index: git-hack/blob.c
===================================================================
--- git-hack.orig/blob.c 2005-04-26 11:38:21.000000000 -0400
+++ git-hack/blob.c 2005-04-26 11:38:26.000000000 -0400
@@ -8,7 +8,7 @@
{
struct object *obj = lookup_object(sha1);
if (!obj) {
- struct blob *ret = malloc(sizeof(struct blob));
+ struct blob *ret = xmalloc(sizeof(struct blob));
memset(ret, 0, sizeof(struct blob));
created_object(sha1, &ret->object);
ret->object.type = blob_type;
Index: git-hack/checkout-cache.c
===================================================================
--- git-hack.orig/checkout-cache.c 2005-04-26 11:38:21.000000000 -0400
+++ git-hack/checkout-cache.c 2005-04-26 11:38:26.000000000 -0400
@@ -39,7 +39,7 @@
static void create_directories(const char *path)
{
int len = strlen(path);
- char *buf = malloc(len + 1);
+ char *buf = xmalloc(len + 1);
const char *slash = path;
while ((slash = strchr(slash+1, '/')) != NULL) {
Index: git-hack/commit-tree.c
===================================================================
--- git-hack.orig/commit-tree.c 2005-04-26 11:38:21.000000000 -0400
+++ git-hack/commit-tree.c 2005-04-26 11:38:26.000000000 -0400
@@ -18,7 +18,7 @@
*/
static void init_buffer(char **bufp, unsigned int *sizep)
{
- char *buf = malloc(BLOCKING);
+ char *buf = xmalloc(BLOCKING);
*sizep = 0;
*bufp = buf;
}
@@ -40,7 +40,7 @@
buf = *bufp;
if (newsize > alloc) {
alloc = (newsize + 32767) & ~32767;
- buf = realloc(buf, alloc);
+ buf = xrealloc(buf, alloc);
*bufp = buf;
}
*sizep = newsize;
Index: git-hack/commit.c
===================================================================
--- git-hack.orig/commit.c 2005-04-26 11:38:21.000000000 -0400
+++ git-hack/commit.c 2005-04-26 11:38:26.000000000 -0400
@@ -9,7 +9,7 @@
{
struct object *obj = lookup_object(sha1);
if (!obj) {
- struct commit *ret = malloc(sizeof(struct commit));
+ struct commit *ret = xmalloc(sizeof(struct commit));
memset(ret, 0, sizeof(struct commit));
created_object(sha1, &ret->object);
ret->object.type = commit_type;
@@ -78,7 +78,7 @@
void commit_list_insert(struct commit *item, struct commit_list **list_p)
{
- struct commit_list *new_list = malloc(sizeof(struct commit_list));
+ struct commit_list *new_list = xmalloc(sizeof(struct commit_list));
new_list->item = item;
new_list->next = *list_p;
*list_p = new_list;
Index: git-hack/convert-cache.c
===================================================================
--- git-hack.orig/convert-cache.c 2005-04-26 11:38:21.000000000 -0400
+++ git-hack/convert-cache.c 2005-04-26 11:38:26.000000000 -0400
@@ -18,8 +18,7 @@
static struct entry *insert_new(unsigned char *sha1, int pos)
{
- struct entry *new = malloc(sizeof(struct entry));
-
+ struct entry *new = xmalloc(sizeof(struct entry));
memset(new, 0, sizeof(*new));
memcpy(new->old_sha1, sha1, 20);
memmove(convert + pos + 1, convert + pos, (nr_convert - pos) * sizeof(struct entry *));
@@ -68,7 +67,7 @@
static int write_subdirectory(void *buffer, unsigned long size, const char *base, int baselen, unsigned char *result_sha1)
{
- char *new = malloc(size);
+ char *new = xmalloc(size);
unsigned long newlen = 0;
unsigned long used;
@@ -226,9 +225,9 @@
static void convert_date(void *buffer, unsigned long size, unsigned char *result_sha1)
{
- char *new = malloc(size + 100);
+ char *new = xmalloc(size + 100);
unsigned long newlen = 0;
-
+
// "tree <sha1>\n"
memcpy(new + newlen, buffer, 46);
newlen += 46;
@@ -283,7 +282,7 @@
if (!data)
die("unable to read object %s", sha1_to_hex(sha1));
- buffer = malloc(size);
+ buffer = xmalloc(size);
memcpy(buffer, data, size);
if (!strcmp(type, "blob")) {
Index: git-hack/diff-tree.c
===================================================================
--- git-hack.orig/diff-tree.c 2005-04-26 11:38:21.000000000 -0400
+++ git-hack/diff-tree.c 2005-04-26 11:38:26.000000000 -0400
@@ -37,7 +37,7 @@
static char *malloc_base(const char *base, const char *path, int pathlen)
{
int baselen = strlen(base);
- char *newbase = malloc(baselen + pathlen + 2);
+ char *newbase = xmalloc(baselen + pathlen + 2);
memcpy(newbase, base, baselen);
memcpy(newbase + baselen, path, pathlen);
memcpy(newbase + baselen + pathlen, "/", 2);
@@ -270,7 +270,7 @@
paths = &argv[3];
nr_paths = argc - 3;
- pathlens = malloc(nr_paths * sizeof(int));
+ pathlens = xmalloc(nr_paths * sizeof(int));
for (i=0; i<nr_paths; i++)
pathlens[i] = strlen(paths[i]);
}
Index: git-hack/http-pull.c
===================================================================
--- git-hack.orig/http-pull.c 2005-04-26 11:38:21.000000000 -0400
+++ git-hack/http-pull.c 2005-04-26 11:38:26.000000000 -0400
@@ -73,7 +73,7 @@
curl_easy_setopt(curl, CURLOPT_FILE, NULL);
curl_easy_setopt(curl, CURLOPT_WRITEFUNCTION, fwrite_sha1_file);
- url = malloc(strlen(base) + 50);
+ url = xmalloc(strlen(base) + 50);
strcpy(url, base);
posn = url + strlen(base);
strcpy(posn, "objects/");
Index: git-hack/init-db.c
===================================================================
--- git-hack.orig/init-db.c 2005-04-26 11:38:21.000000000 -0400
+++ git-hack/init-db.c 2005-04-26 11:38:26.000000000 -0400
@@ -34,7 +34,7 @@
fprintf(stderr, "defaulting to local storage area\n");
}
len = strlen(sha1_dir);
- path = malloc(len + 40);
+ path = xmalloc(len + 40);
memcpy(path, sha1_dir, len);
safe_create_dir(sha1_dir);
Index: git-hack/object.c
===================================================================
--- git-hack.orig/object.c 2005-04-26 11:38:21.000000000 -0400
+++ git-hack/object.c 2005-04-26 11:38:26.000000000 -0400
@@ -52,7 +52,7 @@
if (obj_allocs == nr_objs) {
obj_allocs = alloc_nr(obj_allocs);
- objs = realloc(objs, obj_allocs * sizeof(struct object *));
+ objs = xrealloc(objs, obj_allocs * sizeof(struct object *));
}
/* Insert it into the right place */
@@ -75,7 +75,7 @@
}
target->used = 1;
- p = malloc(sizeof(*p));
+ p = xmalloc(sizeof(*p));
p->item = target;
p->next = NULL;
*pp = p;
Index: git-hack/read-cache.c
===================================================================
--- git-hack.orig/read-cache.c 2005-04-26 11:38:21.000000000 -0400
+++ git-hack/read-cache.c 2005-04-26 11:38:26.000000000 -0400
@@ -143,7 +143,7 @@
/* Make sure the array is big enough .. */
if (active_nr == active_alloc) {
active_alloc = alloc_nr(active_alloc);
- active_cache = realloc(active_cache, active_alloc * sizeof(struct cache_entry *));
+ active_cache = xrealloc(active_cache, active_alloc * sizeof(struct cache_entry *));
}
/* Add it in.. */
Index: git-hack/sha1_file.c
===================================================================
--- git-hack.orig/sha1_file.c 2005-04-26 11:38:21.000000000 -0400
+++ git-hack/sha1_file.c 2005-04-26 11:38:26.000000000 -0400
@@ -73,7 +73,7 @@
if (!base) {
char *sha1_file_directory = getenv(DB_ENVIRONMENT) ? : DEFAULT_DB_ENVIRONMENT;
int len = strlen(sha1_file_directory);
- base = malloc(len + 60);
+ base = xmalloc(len + 60);
memcpy(base, sha1_file_directory, len);
memset(base+len, 0, 60);
base[len] = '/';
@@ -161,9 +161,7 @@
return NULL;
bytes = strlen(buffer) + 1;
- buf = malloc(*size);
- if (!buf)
- return NULL;
+ buf = xmalloc(*size);
memcpy(buf, buffer + bytes, stream.total_out - bytes);
bytes = stream.total_out - bytes;
@@ -271,7 +269,7 @@
memset(&stream, 0, sizeof(stream));
deflateInit(&stream, Z_BEST_COMPRESSION);
size = deflateBound(&stream, len+hdrlen);
- compressed = malloc(size);
+ compressed = xmalloc(size);
/* Compress it */
stream.next_out = compressed;
Index: git-hack/show-files.c
===================================================================
--- git-hack.orig/show-files.c 2005-04-26 11:38:21.000000000 -0400
+++ git-hack/show-files.c 2005-04-26 11:38:26.000000000 -0400
@@ -30,9 +30,9 @@
if (nr_dir == dir_alloc) {
dir_alloc = alloc_nr(dir_alloc);
- dir = realloc(dir, dir_alloc*sizeof(char *));
+ dir = xrealloc(dir, dir_alloc*sizeof(char *));
}
- name = malloc(len + 1);
+ name = xmalloc(len + 1);
memcpy(name, pathname, len + 1);
dir[nr_dir++] = name;
}
Index: git-hack/tree.c
===================================================================
--- git-hack.orig/tree.c 2005-04-26 11:38:21.000000000 -0400
+++ git-hack/tree.c 2005-04-26 11:38:26.000000000 -0400
@@ -9,7 +9,7 @@
{
int len = strlen(pathname);
unsigned int size = cache_entry_size(baselen + len);
- struct cache_entry *ce = malloc(size);
+ struct cache_entry *ce = xmalloc(size);
memset(ce, 0, size);
@@ -39,7 +39,7 @@
if (S_ISDIR(mode)) {
int retval;
int pathlen = strlen(path);
- char *newbase = malloc(baselen + 1 + pathlen);
+ char *newbase = xmalloc(baselen + 1 + pathlen);
void *eltbuf;
char elttype[20];
unsigned long eltsize;
@@ -74,7 +74,7 @@
{
struct object *obj = lookup_object(sha1);
if (!obj) {
- struct tree *ret = malloc(sizeof(struct tree));
+ struct tree *ret = xmalloc(sizeof(struct tree));
memset(ret, 0, sizeof(struct tree));
created_object(sha1, &ret->object);
ret->object.type = tree_type;
@@ -116,7 +116,7 @@
sscanf(bufptr, "%o", &mode) != 1)
return -1;
- entry = malloc(sizeof(struct tree_entry_list));
+ entry = xmalloc(sizeof(struct tree_entry_list));
entry->name = strdup(path + 1);
entry->directory = S_ISDIR(mode);
entry->executable = mode & S_IXUSR;
Index: git-hack/update-cache.c
===================================================================
--- git-hack.orig/update-cache.c 2005-04-26 11:38:21.000000000 -0400
+++ git-hack/update-cache.c 2005-04-26 11:38:26.000000000 -0400
@@ -35,8 +35,8 @@
z_stream stream;
unsigned long size = st->st_size;
int max_out_bytes = size + 200;
- void *out = malloc(max_out_bytes);
- void *metadata = malloc(200);
+ void *out = xmalloc(max_out_bytes);
+ void *metadata = xmalloc(200);
int metadata_size;
void *in;
SHA_CTX c;
@@ -122,7 +122,7 @@
}
namelen = strlen(path);
size = cache_entry_size(namelen);
- ce = malloc(size);
+ ce = xmalloc(size);
memset(ce, 0, size);
memcpy(ce->name, path, namelen);
fill_stat_cache_info(ce, &st);
@@ -205,7 +205,7 @@
return ERR_PTR(-EINVAL);
size = ce_size(ce);
- updated = malloc(size);
+ updated = xmalloc(size);
memcpy(updated, ce, size);
fill_stat_cache_info(updated, &st);
return updated;
@@ -281,7 +281,7 @@
len = strlen(arg3);
size = cache_entry_size(len);
- ce = malloc(size);
+ ce = xmalloc(size);
memset(ce, 0, size);
memcpy(ce->sha1, sha1, 20);
Index: git-hack/write-tree.c
===================================================================
--- git-hack.orig/write-tree.c 2005-04-26 11:38:21.000000000 -0400
+++ git-hack/write-tree.c 2005-04-26 11:38:26.000000000 -0400
@@ -26,7 +26,7 @@
/* Guess at some random initial size */
size = 8192;
- buffer = malloc(size);
+ buffer = xmalloc(size);
offset = 0;
nr = 0;
@@ -68,7 +68,7 @@
entrylen = pathlen - baselen;
if (offset + entrylen + 100 > size) {
size = alloc_nr(offset + entrylen + 100);
- buffer = realloc(buffer, size);
+ buffer = xrealloc(buffer, size);
}
offset += sprintf(buffer + offset, "%o %.*s", mode, entrylen, filename);
buffer[offset++] = 0;
Index: git-hack/revision.h
===================================================================
--- git-hack.orig/revision.h 2005-04-26 11:38:21.000000000 -0400
+++ git-hack/revision.h 2005-04-26 11:38:26.000000000 -0400
@@ -68,10 +68,9 @@
if (rev_allocs == nr_revs) {
rev_allocs = alloc_nr(rev_allocs);
- revs = realloc(revs, rev_allocs * sizeof(struct revision *));
+ revs = xrealloc(revs, rev_allocs * sizeof(struct revision *));
}
- n = malloc(sizeof(struct revision) + strlen(tag));
-
+ n = xmalloc(sizeof(struct revision) + strlen(tag));
n->flags = 0;
memcpy(n->sha1, sha1, 20);
n->parent = NULL;
@@ -96,7 +95,7 @@
pp = &p->next;
}
- p = malloc(sizeof(*p));
+ p = xmalloc(sizeof(*p));
p->parent = parent_rev;
p->next = NULL;
*pp = p;
Index: git-hack/diff.c
===================================================================
--- git-hack.orig/diff.c 2005-04-26 11:38:21.000000000 -0400
+++ git-hack/diff.c 2005-04-26 11:38:26.000000000 -0400
@@ -59,8 +59,7 @@
if (*cp == '\'')
cnt += 3;
- if (! (buf = malloc(cnt)))
- return buf;
+ buf = xmalloc(cnt);
bp = buf;
while ((c = *src++)) {
if (c != '\'')
@@ -100,7 +99,7 @@
strlen(diff_arg) +
strlen(name_1_sq) + strlen(name_2_sq)
- 5);
- char *cmd = malloc(cmd_size);
+ char *cmd = xmalloc(cmd_size);
int next_at = 0;
next_at += snprintf(cmd+next_at, cmd_size-next_at,
Index: git-hack/strbuf.c
===================================================================
--- git-hack.orig/strbuf.c 2005-04-26 11:38:21.000000000 -0400
+++ git-hack/strbuf.c 2005-04-26 11:38:26.000000000 -0400
@@ -1,6 +1,7 @@
#include <stdio.h>
#include <stdlib.h>
#include "strbuf.h"
+#include "cache.h"
void strbuf_init(struct strbuf *sb) {
sb->buf = 0;
@@ -15,7 +16,7 @@
static void inline strbuf_add(struct strbuf *sb, int ch) {
if (sb->alloc <= sb->len) {
sb->alloc = sb->alloc * 3 / 2 + 16;
- sb->buf = realloc(sb->buf, sb->alloc);
+ sb->buf = xrealloc(sb->buf, sb->alloc);
}
sb->buf[sb->len++] = ch;
}
Index: git-hack/cache.h
===================================================================
--- git-hack.orig/cache.h 2005-04-26 11:40:43.000000000 -0400
+++ git-hack/cache.h 2005-04-26 11:40:59.000000000 -0400
@@ -147,4 +147,20 @@
unsigned long *size,
unsigned char *tree_sha1_ret);
+static inline void *xmalloc(int size)
+{
+ void *ret = malloc(size);
+ if (!ret)
+ die("Out of memory, malloc failed");
+ return ret;
+}
+
+static inline void *xrealloc(void *ptr, int size)
+{
+ void *ret = realloc(ptr, size);
+ if (!ret)
+ die("Out of memory, realloc failed");
+ return ret;
+}
+
#endif /* CACHE_H */
^ permalink raw reply
* Re: [RFC] diff-cache buglet
From: Linus Torvalds @ 2005-04-26 18:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vsm1do0t4.fsf@assigned-by-dhcp.cox.net>
On Tue, 26 Apr 2005, Junio C Hamano wrote:
>
> Well, I somehow thought these things are in fixed column format;
> mode, ->, sha, stage, and filename are all seperated with either
> ' ' or '\t'. So if I copy MN to "1 MN", presumably you would
> see this:
>
> 100644 a716d58de4a570e0038f5c307bd8db34daea021f 0 MN
> 100644 a716d58de4a570e0038f5c307bd8db34daea021f 0 1 MN
>
> So while I agree that // would also work, I fail to see why you
> would even need that.
Because I'd rather _not_ have the 0 in there at all for the normal case.
Yes, it's there for "show-files --stages", but it's certainly _not_ there
in "diff-tree" output right now.
Linus
^ permalink raw reply
* Re: : Networking
From: Petr Baudis @ 2005-04-26 18:33 UTC (permalink / raw)
To: Andrew Morton; +Cc: David S. Miller, torvalds, git
In-Reply-To: <20050426005725.6bfe6135.akpm@osdl.org>
Dear diary, on Tue, Apr 26, 2005 at 09:57:25AM CEST, I got a letter
where Andrew Morton <akpm@osdl.org> told me that...
> c) To generate -mm's linus.patch (patch against 2.6.12-rc3):
>
> git pull origin
> git diff -r v2.6.12-rc3 > ../25/patches/linus.patch
(Mainly for people not familiar with git-pasky - this merged origin to
the working tree since it was tracked branch - that's what origin is by
default after git init.)
> d) To generate davem's tree (patch against linus's current tree (ie: patch
> against 2.6.12-rc3+linus.patch)):
>
> git pull git-net
> MERGE_BASE=$(merge-base $(cat .git/heads/origin ) $(cat .git/heads/git-net))
> git diff -r $MERGE_BASE:$(cat .git/heads/git-net) > ../25/patches/git-net.patch
This is the bad way; I think this suffers of basically the same problems
as my ancient merging by "forward-patching". You should probably do a
regular merge:
git pull git-net
git merge git-net
git diff -p
The last command will show diff between current tree and the first
parent; that amounts the merged patch in this case.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: [PATCH] check for malloc
From: Linus Torvalds @ 2005-04-26 18:25 UTC (permalink / raw)
To: Christopher Li; +Cc: git mailing list
In-Reply-To: <20050426151217.GA5344@64m.dyndns.org>
On Tue, 26 Apr 2005, Christopher Li wrote:
>
> Add check for NULL return from malloc and realloc
I'd prefer xmalloc()/xrealloc() instead, and just do it in one place.
Linus
^ 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