* Re: index manipulation -- how?
From: Luben Tuikov @ 2005-11-22 6:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3blpi6r7.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
> Junio C Hamano <junkio@cox.net> writes:
>
> > Luben Tuikov <ltuikov@yahoo.com> writes:
> >
> >> How do I reverse a _single_ "git-update-index" operation?
> >> Be it --add or just an update.
> >
> > Reverting working tree files are "git checkout HEAD the-file"
> > (both index and working tree file from the head commit) or "git
> > checkout -- the-file" (working tree file from the index), but I
> > do not think there is a prepackaged way to revert only a single
> > index path offhand.
> >
> > git-ls-tree HEAD the-file |
> > sed -e 's/^\([0-7]*\) [^ ]* \(.*\)/\1 \2/' |
> > git-update-index --index-info
Ok.
(There is a very similar construct in git-checkout.sh.
So if you apply the patch below, please make sure
git-checkout.sh doesn't break.)
Question: so in effect, more generally:
git checkout <tree-ish> <file>
would do the right thing: update index and the working
tree as the file <file> looked as it was at <tree-ish>?
Is that correct? Can someone confirm/deny?
Luben
P.S. So both methods as mentioned by Linus and Junio
do what I asked about.
> >
> > should work.
> >
> > I think changing update-index --index-info so that you can lose
> > the sed in between without breaking its other usage (it reads
> > from git-apply --index-info, which does not say " blob " which
> > is what the sed is stripping out) is a worthwhile thing to do.
>
> And here is the patch to let you say:
>
> git-ls-tree HEAD the-file | git-update-index --index-info
>
>
> ---
>
> diff --git a/update-index.c b/update-index.c
> index 5bbc3de..11b7f6a 100644
> --- a/update-index.c
> +++ b/update-index.c
> @@ -338,7 +338,7 @@ static void read_index_info(int line_ter
> struct strbuf buf;
> strbuf_init(&buf);
> while (1) {
> - char *ptr;
> + char *ptr, *tab;
> char *path_name;
> unsigned char sha1[20];
> unsigned int mode;
> @@ -348,12 +348,15 @@ static void read_index_info(int line_ter
> break;
>
> mode = strtoul(buf.buf, &ptr, 8);
> - if (ptr == buf.buf || *ptr != ' ' ||
> - get_sha1_hex(ptr + 1, sha1) ||
> - ptr[41] != '\t')
> + if (ptr == buf.buf || *ptr != ' ')
> goto bad_line;
>
> - ptr += 42;
> + tab = strchr(ptr, '\t');
> + if (!tab || tab - ptr < 41)
> + goto bad_line;
> + if (get_sha1_hex(tab - 40, sha1) || tab[-41] != ' ')
> + goto bad_line;
> + ptr = tab + 1;
>
> if (line_termination && ptr[0] == '"')
> path_name = unquote_c_style(ptr, NULL);
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: auto-packing on kernel.org? please?
From: Linus Torvalds @ 2005-11-22 5:41 UTC (permalink / raw)
To: Chuck Lever
Cc: Carl Baldwin, H. Peter Anvin, Git Mailing List, Catalin Marinas
In-Reply-To: <4382AC11.5090209@citi.umich.edu>
On Tue, 22 Nov 2005, Chuck Lever wrote:
>
> there are some things repacking does that breaks StGIT, though.
>
> git repack -d
>
> seems to remove old commits that StGIT was still depending on.
If that is true, then "git-fsck-cache" probably also reports errors on a
StGIT repository. No? Basically, it implies that the tool doesn't know how
to find all the "heads".
Could somebody (Catalin?) perhaps tell how tools like git-fsck-cache and
git-repack could figure out which objects are still in use by stgit?
Preferably with some generic mechanism that _other_ projects (not just
stgit) might want to use?
The preferred way would be to just list the references somewhere under
.git/refs/stgit, in which case fsck and repack should pick them up
automatically (so clearly stgit doesn't do that right now ;).
It also implies that doing a "git prune" will do horribly bad things to a
stgit repo, since it would remove all the objects that it thinks aren't
reachable..
> git repack -a -n
>
> seems to work fine with StGIT,
Well, it "works", but not "fine". Since it doesn't know about the stgit
objects, it won't ever pack them.
But maybe that's what stgit wants (since they are "temporary"), but it
does mean that if you see a big advantage from packing, you might be
losing some of it.
Linus
^ permalink raw reply
* Re: index manipulation -- how?
From: Junio C Hamano @ 2005-11-22 5:36 UTC (permalink / raw)
To: Luben Tuikov; +Cc: git
In-Reply-To: <7v8xvhi7bi.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Luben Tuikov <ltuikov@yahoo.com> writes:
>
>> How do I reverse a _single_ "git-update-index" operation?
>> Be it --add or just an update.
>
> Reverting working tree files are "git checkout HEAD the-file"
> (both index and working tree file from the head commit) or "git
> checkout -- the-file" (working tree file from the index), but I
> do not think there is a prepackaged way to revert only a single
> index path offhand.
>
> git-ls-tree HEAD the-file |
> sed -e 's/^\([0-7]*\) [^ ]* \(.*\)/\1 \2/' |
> git-update-index --index-info
>
> should work.
>
> I think changing update-index --index-info so that you can lose
> the sed in between without breaking its other usage (it reads
> from git-apply --index-info, which does not say " blob " which
> is what the sed is stripping out) is a worthwhile thing to do.
And here is the patch to let you say:
git-ls-tree HEAD the-file | git-update-index --index-info
---
diff --git a/update-index.c b/update-index.c
index 5bbc3de..11b7f6a 100644
--- a/update-index.c
+++ b/update-index.c
@@ -338,7 +338,7 @@ static void read_index_info(int line_ter
struct strbuf buf;
strbuf_init(&buf);
while (1) {
- char *ptr;
+ char *ptr, *tab;
char *path_name;
unsigned char sha1[20];
unsigned int mode;
@@ -348,12 +348,15 @@ static void read_index_info(int line_ter
break;
mode = strtoul(buf.buf, &ptr, 8);
- if (ptr == buf.buf || *ptr != ' ' ||
- get_sha1_hex(ptr + 1, sha1) ||
- ptr[41] != '\t')
+ if (ptr == buf.buf || *ptr != ' ')
goto bad_line;
- ptr += 42;
+ tab = strchr(ptr, '\t');
+ if (!tab || tab - ptr < 41)
+ goto bad_line;
+ if (get_sha1_hex(tab - 40, sha1) || tab[-41] != ' ')
+ goto bad_line;
+ ptr = tab + 1;
if (line_termination && ptr[0] == '"')
path_name = unquote_c_style(ptr, NULL);
^ permalink raw reply related
* Re: Diffs "from" working directory
From: Linus Torvalds @ 2005-11-22 5:33 UTC (permalink / raw)
To: Chuck Lever; +Cc: Catalin Marinas, git
In-Reply-To: <4382A972.1010801@citi.umich.edu>
On Tue, 22 Nov 2005, Chuck Lever wrote:
>
> for some reason i was under the impression that it would parse the
> Signed-off-by: fields in the patch description, and take the first one as the
> patch author.
The first sign-off really isn't necessarily the author.
It might be a company sign-off (many companies don't want any random
engineer to send out patches), but much more commonly it's a trivial patch
that somebody else signs off on, even if the original patcher didn't (see
case (b) in the sign-off-rules: you can sign of on somebody elses work if
you know it's under the GPL).
So the fact that there was a sign-off procedure doesn't automatically mean
that the author will be the first sign-off person, although in _practice_
that obviously would likely always be the most common case by far.
(Another reason is that some people actually add the sign-offs above
previous ones. It happens, although if I notice, I try to point it out).
So authorship really is totally separate from sign-off, and all _my_ tools
take the authorship from the first "From:" line at the top of the message
body or from the email itself.
Linus
^ permalink raw reply
* Re: auto-packing on kernel.org? please?
From: Chuck Lever @ 2005-11-22 5:26 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Carl Baldwin, H. Peter Anvin, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0511211110480.13959@g5.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 1504 bytes --]
Linus Torvalds wrote:
>
> On Mon, 21 Nov 2005, Carl Baldwin wrote:
>
>>I have a question about automatic repacking.
>>
>>I am thinking of turning something like Linus' repacking heuristic loose
>>on my repositories. I just want to make sure it is as safe as possible.
>>
>>At the core of the incremental and full repack strategies are these
>>statements.
>>
>>Incremental...
>>
>>> git repack &&
>>> git prune-packed
>>
>>Full...
>>
>>> git repack -a -d &&
>>> git prune-packed
>
>
> NOTE! Since that email, "git repack" has gotten a "local" option (-l),
> which is very useful if the repositories have pointers to alternates.
>
> So do
>
> git repack -l
>
> instead, to get much better packs (and "-a -d" for the full case, of
> course).
>
> Other that than, the old email suggestion should still be fine.
i've been playing with "git repack" on StGIT-managed repositories.
on NFS, using packs instead of individual objects is quite a bit faster,
because a single NFS GETATTR will tell you if your NFS client's cached
pack file is still valid, whereas a whole bunch of GETATTRs are required
for validating individual object files.
there are some things repacking does that breaks StGIT, though.
git repack -d
seems to remove old commits that StGIT was still depending on.
git repack -a -n
seems to work fine with StGIT, as does
git prune-packed
i'm really interested in trying out the new command to remove redundant
objects and packs, but haven't gotten around to it yet.
[-- Attachment #2: cel.vcf --]
[-- Type: text/x-vcard, Size: 439 bytes --]
begin:vcard
fn:Chuck Lever
n:Lever;Charles
org:Network Appliance, Incorporated;Linux NFS Client Development
adr:535 West William Street, Suite 3100;;Center for Information Technology Integration;Ann Arbor;MI;48103-4943;USA
email;internet:cel@citi.umich.edu
title:Member of Technical Staff
tel;work:+1 734 763-4415
tel;fax:+1 734 763 4434
tel;home:+1 734 668-1089
x-mozilla-html:FALSE
url:http://www.monkey.org/~cel/
version:2.1
end:vcard
^ permalink raw reply
* Re: index manipulation -- how?
From: Junio C Hamano @ 2005-11-22 5:24 UTC (permalink / raw)
To: ltuikov; +Cc: git
In-Reply-To: <20051122050337.46450.qmail@web31808.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> writes:
> How do I reverse a _single_ "git-update-index" operation?
> Be it --add or just an update.
Reverting working tree files are "git checkout HEAD the-file"
(both index and working tree file from the head commit) or "git
checkout -- the-file" (working tree file from the index), but I
do not think there is a prepackaged way to revert only a single
index path offhand.
git-ls-tree HEAD the-file |
sed -e 's/^\([0-7]*\) [^ ]* \(.*\)/\1 \2/' |
git-update-index --index-info
should work.
I think changing update-index --index-info so that you can lose
the sed in between without breaking its other usage (it reads
from git-apply --index-info, which does not say " blob " which
is what the sed is stripping out) is a worthwhile thing to do.
^ permalink raw reply
* Re: index manipulation -- how?
From: Linus Torvalds @ 2005-11-22 5:23 UTC (permalink / raw)
To: Luben Tuikov; +Cc: git
In-Reply-To: <20051122050337.46450.qmail@web31808.mail.mud.yahoo.com>
On Mon, 21 Nov 2005, Luben Tuikov wrote:
>
> How do I reverse a _single_ "git-update-index" operation?
> Be it --add or just an update.
An "add" is easy enough to undo: just do a
git-update-index --force-remove filename
which will remove the entry from the index even if the file on your
filesystem still remains (so you can "git add" it later when you do want
to commit it).
For a file that you had in your old index, but you've updated (either mode
or SHA1), you need to figure out what the old mode/sha1 was. USUALLY this
would be just the state that you still have in your HEAD tree, but if
you want to go back to something else, you'd need to figure out what that
was.
If it's the "last commit" state (ie just your HEAD state), then do
git-ls-tree HEAD filename
which will show you the info, and then you do
git-update-index --cacheinfo <mode> <sha1> filename
from that state.
You could obviously script something like "git-downdate-index":
#!/bin/sh
filename="$1"
tree_info=$(git-ls-tree HEAD -- "$filename")
if [ -z "$tree_info" ]; then
git-update-index --force-remove -- "$filename"
else
echo "$tree_info" | while read mode type sha1 name; do
git-update-index --cacheinfo "$mode" "$sha1" "$filename"
done
fi
but the above is totally untested, and "git-downdate-index" is a really
sucky name too, so you'd need to rename it and test whether it does what
you want.
Hmm?
Linus
^ permalink raw reply
* Re: Diffs "from" working directory
From: Chuck Lever @ 2005-11-22 5:15 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0511211328j7c062c07s@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 675 bytes --]
Catalin Marinas wrote:
>>btw, catalin, this was bruce's patch. i'm not sure why i was listed as
>>the author (probably a mistake of mine when i imported his patch into my
>>repository). ah well.
>
>
> My import command sets the author to the e-mail sender, which was you.
> Maybe this should be changed but I don't know which option is better.
> In the meantime, you can change the default e-mail template to set the
> From: line with to the author of the patch and maybe add a Reply-to:
> with your address.
for some reason i was under the impression that it would parse the
Signed-off-by: fields in the patch description, and take the first one
as the patch author.
[-- Attachment #2: cel.vcf --]
[-- Type: text/x-vcard, Size: 439 bytes --]
begin:vcard
fn:Chuck Lever
n:Lever;Charles
org:Network Appliance, Incorporated;Linux NFS Client Development
adr:535 West William Street, Suite 3100;;Center for Information Technology Integration;Ann Arbor;MI;48103-4943;USA
email;internet:cel@citi.umich.edu
title:Member of Technical Staff
tel;work:+1 734 763-4415
tel;fax:+1 734 763 4434
tel;home:+1 734 668-1089
x-mozilla-html:FALSE
url:http://www.monkey.org/~cel/
version:2.1
end:vcard
^ permalink raw reply
* index manipulation -- how?
From: Luben Tuikov @ 2005-11-22 5:03 UTC (permalink / raw)
To: git
I've a question:
Suppose I've updated the index and there is
several updates pending in it: several new
files, and several updates, etc.
That is a sequence of:
git-update-index [options] <file>
...
My question is:
How do I reverse a _single_ "git-update-index" operation?
Be it --add or just an update.
Thanks,
Luben
^ permalink raw reply
* Re: Question Building Deb Packages
From: Junio C Hamano @ 2005-11-22 5:01 UTC (permalink / raw)
To: Jon Loeliger; +Cc: git
In-Reply-To: <E1EeOHi-0007Bx-HH@jdl.com>
Jon Loeliger <jdl@freescale.com> writes:
> It _appears_ that the "deb" make target requires it to be
> done in an actual git repository.
I think we could cheat:
$ tar zxf original-tarball-of-0.99.9j.tar.gz
$ cd there
$ fakeroot debian/rules binary
But you are right; "make deb" at the toplevel would not work
well on a virgin machine, because it uses git-tar-tree to do the
tarball construction; we inherited this braindamage from RPM
building procedure. So if you do not want to cheat:
$ tar zxf original-tarball-of-0.99.9j.tar.gz
$ cd there
$ make install ;# to install in $HOME/bin
$ cd ..
$ git clone git://kernel.org/pub/scm/git/git.git/
$ git checkout -b build v0.99.9j
$ make deb
Then install the resulting deb and get rid of $HOME/bin/git*.
^ permalink raw reply
* Re: Get rid of .git/branches/ and .git/remotes/?
From: linux @ 2005-11-22 4:18 UTC (permalink / raw)
To: linux, torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0511211931350.13959@g5.osdl.org>
> This is like Makefiles: if you have spaces in the wrong place, it may all
> _look_ fine, but the Makefile just doesn't work. Really irritating.
Makefiles are more annoying because spaces instead of tabs can cause
them to work *differently*. It's hard to write syntax that will
actually do that, but the parser ahs to go past the problem a bit to
really figure it out, so it can't print a nice error message.
With the strict prefix convention, the parser can produce excellent
error messages.
> And obviously using the file will show the problem (the parser will
> complain with a nice line number and readable error, hopefully), but I
> personally find that to just be too damn late. By then, you're already
> irritated.
>
> So I like the notion of depending on indentation, but I just feel it falls
> down in practice.
So you're a crotchety old fart already, unable to learn new things?
It irritates you the first few times until you learn to do it right in
first place, just like it irritates most beginning C programmers that the
compiler keeps complaining about missing semicolons.
Computers will be annoying about syntax until they learn to do what
I want them to do rather than what I tell them to do, at which point
they'll be smart enough to start being annoying by doing what they want
to to instead of what I want them to do.
> Of course, since I believe that tabs are always exactly 8 characters, I'd
> also be perfectly happy to just declare that anybody who disagrees with me
> is a moron and deserves to die (*).
I agree on the One True Tab Spacing, but I fear I heretically
disagree with you about the whole NO_IRQ thing, so I guess I'll just
have to take your advice and start stalking you with eugenic intent.
[Briefly: what hardware conventions are, and particularly how many
of those hardware devices exist in the world, is irrelevant. We have
existence proofs of hardware that uses 0 for "no IRQ" and hardware that
accepts 0 as a valid IRQ. dev->irq is a freaking *software convention*.
What matters is the development and maintenance burden of translating
that convention into all the different hardware out there. And frankly
converting between "0 is valid" and "0 is invalid" affects a lot more
code paths than converting between "0 is invalid" and "-1 is invalid"
for a couple of specific hardware devices. Particularly if you
want various kernel messages and /proc/interrupts to look right.
Hell, I could argue that having the most common hardware exercise the
longest code paths is a good thing, because that puts the code that
needs the most testing where it'll get it.]
Seriously, you could always have it print warning messages but try to
keep going by assuming 8 space tabs so that at least you can postpone
fixing the problem until your current train of thought has pulled into
the station.
^ permalink raw reply
* [PATCH] GIT: Fix compilation error in connect.c
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2005-11-22 3:18 UTC (permalink / raw)
To: junkio; +Cc: git, yoshfuji
Fix compilation error for gcc-2.95.
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
diff --git a/connect.c b/connect.c
index a4d6d35..7a417e5 100644
--- a/connect.c
+++ b/connect.c
@@ -455,6 +455,10 @@ static int rhost_len;
static int git_proxy_command_options(const char *var, const char *value)
{
if (!strcmp(var, "core.gitproxy")) {
+ const char *for_pos;
+ int matchlen = -1;
+ int hostlen;
+
if (git_proxy_command)
return 0;
/* [core]
@@ -463,10 +467,7 @@ static int git_proxy_command_options(con
* gitproxy = netcatter-2 for sample.xz
* gitproxy = netcatter-default
*/
- const char *for_pos = strstr(value, " for ");
- int matchlen = -1;
- int hostlen;
-
+ for_pos = strstr(value, " for ");
if (!for_pos)
/* matches everybody */
matchlen = strlen(value);
--
YOSHIFUJI Hideaki @ USAGI Project <yoshfuji@linux-ipv6.org>
GPG-FP : 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA
^ permalink raw reply related
* Re: Get rid of .git/branches/ and .git/remotes/?
From: Linus Torvalds @ 2005-11-22 3:38 UTC (permalink / raw)
To: linux; +Cc: git
In-Reply-To: <20051122032014.32539.qmail@science.horizon.com>
On Mon, 21 Nov 2005, linux@horizon.com wrote:
>
> Actually, most indentation-sensitive languages have a simpler solution:
> they don't try to convert whitespace strings to a number like "horizontal
> position"; they just compare strings.
Yes, but that doesn't really change the problem: you can't _visually_ see
what is wrong in most editors (some editors end up showing tabs as
something that isn't quite whitespace, but that's also really irritating).
This is like Makefiles: if you have spaces in the wrong place, it may all
_look_ fine, but the Makefile just doesn't work. Really irritating.
And obviously using the file will show the problem (the parser will
complain with a nice line number and readable error, hopefully), but I
personally find that to just be too damn late. By then, you're already
irritated.
So I like the notion of depending on indentation, but I just feel it falls
down in practice.
Of course, since I believe that tabs are always exactly 8 characters, I'd
also be perfectly happy to just declare that anybody who disagrees with me
is a moron and deserves to die (*).
Linus
(*) That's obviously true of _anything_ that people disagree with me on,
but at the same time, I have this nagging suspicion that it's just better
to not depend on indentation.
^ permalink raw reply
* Re: Get rid of .git/branches/ and .git/remotes/?
From: linux @ 2005-11-22 3:20 UTC (permalink / raw)
To: torvalds; +Cc: git
> The main reason I don't like indentation is that it tends to have strange
> rules for "tab". Some people (incorrectly, of course) think that tabs are
> not at fixed 8-byte things, so deciding the indentation of a tab often
> ends up either disallowing tabs altogether (bad) or having other strange
> rules (disallowing spaces).
>
> So I'm not religiously opposed to it, but I find it to be less than
> optimal.
Actually, most indentation-sensitive languages have a simpler solution:
they don't try to convert whitespace strings to a number like "horizontal
position"; they just compare strings.
Each line must either have the same indentation string as some active
scope, or its indentation must have the current innermost scope as a
prefix, in which case it introduces a new scope.
This allows anything except for
foo # No prefix
bar # 4 spaces prefix
baz # tab prefix: illegal!
The "baz" line would have to begin with 4 spaces to be legal.
They could be followed by 4 more spaces, or a tab, or any other
whitespace pattern.
It's also possible to combine the two, as Haskell does. Haskell inserts
open braces automatically if there is no such punctuation between two
lines with differing indentation, but if you supply a brace explicitly,
you can do whatever indentation you like. (And the close brace must be
explicit if the open brace is, of course.)
^ permalink raw reply
* [PATCH] Teach diff-tree to honor grafts
From: Junio C Hamano @ 2005-11-22 3:02 UTC (permalink / raw)
To: Santi Béjar; +Cc: git
In-Reply-To: <7v4q65odkg.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Santi Béjar <sbejar@gmail.com> writes:
>
>> diff-tree decode directly the commit, so it does not take into
>> account the graft file. Is this the expected behaviour?
>
> Expected? Yes, only because I happen to know diff-tree was
> written way before grafts are invented and nobody bothered to
> change that behaviour. Desireable? Probably not.
Something like this (only lightly tested) should make it work in
one-tree case. The --stdin form does not necessarily need this
if you tell rev-list to show the parents, but that case should
be covered as well with this patch.
-- >8 --
"git-rev-list --parent" piped to "git-diff-tree --stdin" honors
grafts because rev-list will explicitly tell diff-tree what base
commit to compare each commit against, but a single parameter
"git-diff-tree oneEnt" form did its own thing to extract parent
information from the commit object by hand, without honoring the
grafts the user has. Rewrite that part to use parse_commit()
API.
---
diff --git a/diff-tree.c b/diff-tree.c
index 09d16ad..e79a134 100644
--- a/diff-tree.c
+++ b/diff-tree.c
@@ -69,52 +69,50 @@ static int diff_root_tree(const unsigned
return retval;
}
-static const char *generate_header(const char *commit, const char *parent, const char *msg, unsigned long len)
+static const char *generate_header(const char *commit, const char *parent, const char *msg)
{
static char this_header[16384];
int offset;
+ unsigned long len;
if (!verbose_header)
return commit;
+ len = strlen(msg);
offset = sprintf(this_header, "%s%s (from %s)\n", header_prefix, commit, parent);
offset += pretty_print_commit(commit_format, msg, len, this_header + offset, sizeof(this_header) - offset);
return this_header;
}
-static int diff_tree_commit(const unsigned char *commit, const char *name)
+static int diff_tree_commit(const unsigned char *commit_sha1)
{
- unsigned long size, offset;
- char *buf = read_object_with_reference(commit, "commit", &size, NULL);
+ struct commit *commit;
+ struct commit_list *parents;
+ char name[50];
+ unsigned char sha1[20];
- if (!buf)
+ sprintf(name, "%s^0", sha1_to_hex(commit_sha1));
+ if (get_sha1(name, sha1))
return -1;
-
- if (!name) {
- static char commit_name[60];
- strcpy(commit_name, sha1_to_hex(commit));
- name = commit_name;
- }
-
+ name[40] = 0;
+ commit = lookup_commit(sha1);
+
/* Root commit? */
- if (show_root_diff && memcmp(buf + 46, "parent ", 7)) {
- header = generate_header(name, "root", buf, size);
- diff_root_tree(commit, "");
+ if (show_root_diff && !commit->parents) {
+ header = generate_header(name, "root", commit->buffer);
+ diff_root_tree(commit_sha1, "");
}
/* More than one parent? */
- if (ignore_merges) {
- if (!memcmp(buf + 46 + 48, "parent ", 7))
+ if (ignore_merges && commit->parents && commit->parents->next)
return 0;
- }
- offset = 46;
- while (offset + 48 < size && !memcmp(buf + offset, "parent ", 7)) {
- unsigned char parent[20];
- if (get_sha1_hex(buf + offset + 7, parent))
- return -1;
- header = generate_header(name, sha1_to_hex(parent), buf, size);
- diff_tree_sha1_top(parent, commit, "");
+ for (parents = commit->parents; parents; parents = parents->next) {
+ struct commit *parent = parents->item;
+ header = generate_header(name,
+ sha1_to_hex(parent->object.sha1),
+ commit->buffer);
+ diff_tree_sha1_top(parent->object.sha1, commit_sha1, "");
if (!header && verbose_header) {
header_prefix = "\ndiff-tree ";
/*
@@ -122,9 +120,7 @@ static int diff_tree_commit(const unsign
* don't print the diffs.
*/
}
- offset += 48;
}
- free(buf);
return 0;
}
@@ -147,7 +143,7 @@ static int diff_tree_stdin(char *line)
return diff_tree_sha1_top(parent, commit, "");
}
line[40] = 0;
- return diff_tree_commit(commit, line);
+ return diff_tree_commit(commit);
}
static const char diff_tree_usage[] =
@@ -250,7 +246,7 @@ int main(int argc, const char **argv)
usage(diff_tree_usage);
break;
case 1:
- diff_tree_commit(sha1[0], NULL);
+ diff_tree_commit(sha1[0]);
break;
case 2:
diff_tree_sha1_top(sha1[0], sha1[1], "");
^ permalink raw reply related
* Question Building Deb Packages
From: Jon Loeliger @ 2005-11-22 2:53 UTC (permalink / raw)
To: git
Guys,
So, a long and twisty path (all alike) later, I have
a new desktop box with Ubuntu on it. So what.
It didn't have git on it at all, the proper git package wasn't
available directly, and I didn't know the location of an apt
source for one off the top of my head. So, first principles.
First, for the record, after you install ubuntu 5.10, you
have to install a whole bunch of normal stuff, like, a compiler.
When you get done with that, I also had to apt-get install some
form of these:
linux-kernel-headers
libc6-dev
libssl-dev
libcurl3-dev
libexpat-dev
openssl
zlib1g-dev
asciidoc
xmlto
fakeroot
The control file lists these:
Build-Depends-Indep: libz-dev, libssl-dev,
libcurl3-dev|libcurl3-gnutls-dev|libcurl3-openssl-dev,
asciidoc (>= 7), xmlto, debhelper (>= 4.0.0),
bc, libexpat-dev
So, that is in pretty-good agreement. The last 3 in my list were
for "doc" and "deb" make targets, of course.
Second, I then decided to actually make the debian package
and attempt to install it from the 99.9j tarball directly
and then add that package to my system. No dice.
It _appears_ that the "deb" make target requires it to be
done in an actual git repository. This struck me as odd,
as I _think_ I have done an obvious progression:
- I don't have git, but want it
- I want to build it from a source drop, 0.99.9j
- Grab tarball, unpack, build it
- Build debian target
- Install just-built deb package
Later, of course, I can use that 'official' installation to
actually grab new (git) repositories and all. But I have to
bootstrap the mess, and I want to do that in a "controlled"
way. Namely, through the debian package target...
Did I get confused?
Thanks,
jdl
jdl@ubuntu:/usr/src/git-0.99.9j$ make prefix=/usr
make -C templates
make[1]: Entering directory `/usr/src/git-0.99.9j/templates'
: no custom templates yet
make[1]: Leaving directory `/usr/src/git-0.99.9j/templates'
jdl@ubuntu:/usr/src/git-0.99.9j$ make prefix=/usr deb
./git-tar-tree HEAD git-0.99.9j > git-0.99.9j.tar
usage: git-tar-tree <key> [basedir]
make: *** [dist] Error 129
jdl@ubuntu:/usr/src/git-0.99.9j$ ls .git*
.gitignore
^ permalink raw reply
* Re: [RFC] git-format-patch options
From: Luben Tuikov @ 2005-11-22 1:53 UTC (permalink / raw)
To: Ryan Anderson; +Cc: Andreas Ericsson, git
In-Reply-To: <43821BE7.5000306@michonline.com>
--- Ryan Anderson <ryan@michonline.com> wrote:
> Doesn't git-format-patch $commit^1..$commit do what you want?
>
Yes, this is the one. Thanks!
Luben
^ permalink raw reply
* Re: Git Future Proofing
From: Junio C Hamano @ 2005-11-22 1:13 UTC (permalink / raw)
To: Martin Atukunda; +Cc: git
In-Reply-To: <11326192921291-git-send-email-matlads@dsmagic.com>
Martin Atukunda <matlads@dsmagic.com> writes:
> Patch 2 fixes init-db's template copy so that it handles
> copying a config file.
The readdir() loop in init_db_config_check() confuses me. Why
check the prefix config (and "config" has 6 bytes not 5 ;-) not
just open("$template_path/config")???
> Patch 6 fixes up init-db config copying so as to never copy anything newer.
>> It however, warns if the copy will result in a downgrade of the repo format
>> version, as git tools are supposed (or will be able) to handle this case :)
I suspect that it is not enough to copy an older version of
config file along with older version of templates.
Suppose version 0 had .git/remotes/{origin,linus,...} and
version 1 moved that information to a flat file ".git/remotes",
that has a bunch of sections like [remotes.origin] in the config
file format, because we have a mechanism in your patch 5 that
lets us read from more than one configuration file.
Now suppose you are running a version 1 repository, so all your
remotes trees you subscribe to are described in .git/remotes
file. You somehow used git-init-db to reiniailize it, using
version 0 template, which has "remotes/origin" and
"remotes/linus". What happens?
Template-copying is designed not to overwrite what is in the
repository, so your .git/remotes file will hopefully be kept,
and the configuration file now claims the repository is in
version 0 format. But is it really in version 0 format? You
cannot create .git/remote/frotz file in such a repository.
I think copying older one into a fresh repository might be safe,
but I'd feel safer if we do not play downgrade games like this.
^ permalink raw reply
* Re: [RFC 1/2] Use remote information in .git/config
From: Johannes Schindelin @ 2005-11-22 0:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhda5lf4t.fsf@assigned-by-dhcp.cox.net>
Hi,
On Mon, 21 Nov 2005, Junio C Hamano wrote:
> Once we start thinking about allowing the template mechansim to
> give default "config" information to newly created repositories,
> having everything in one file may make things a bit awkward to
> handle. When you managed to make your colleage interested in
> git development, you can let her copy your remotes/junio. Once
> you moved remotes/ to .git/config file, while you would not want
> her to use copy of your .git/config verbatim without updating at
> least user.name, you would want to have her use other pieces in
> the .git/config, including [remote.jnio] bits.
Well, obviously I would patch git-fetch/-pull/-push to have an option
("--store") to store the current parameters under a certain nick name in
the config ;-)
Or add a little option (which is easy) to generate commands which can be
piped into a little script (think "xmodmap -pke").
> The following comments are not about your patch but I am having
> a feeling that we ended up having too much flexibility. It may
> not necessarily be a bad thing when we view git as pure
> plumbing, but it makes things confusing to have too many "you
> could do it this way if you want to gain XXX, as long as you are
> careful about YYY".
I wouldn't be so sad about the flexibility. It is an open source project,
and the strength therein lies in many people having many (yes, even
stupid) ideas, and trying to get them in. In the long run, the dumb ideas
are thrown out, but what remains is a collection of gems.
So, it might be confusing for a noobee, but that's what we have
Documentation/tutorial for.
> Most of the time, what we recommend are the BCP, but
> knowledgeable users can deviate from that, to gain some
> advantage (e.g. reduced disk space using an incomplete
> repository, convenience of having more than one checked-out
> trees at the same time, not having to migrate to all UTF-8
> system) over the BCP if they are willing to sacrifice something
> else or their use pattern is not affected negatively by what
> they are losing (e.g. can live without an access to ancient
> history, be very careful when pruning and fetching, do not have
> people whose names cannot be spelled in KOI-8).
'xactly. For example, I can do
ln -s .gitgrafts .git/info/grafts
and have the effect that Linus just called "nasty". Point is, if I choose
to do so, I can. Easily.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] Make grafts versionable
From: Johannes Schindelin @ 2005-11-22 0:37 UTC (permalink / raw)
To: Linus Torvalds; +Cc: H. Peter Anvin, git
In-Reply-To: <Pine.LNX.4.64.0511211326110.13959@g5.osdl.org>
Hi,
On Mon, 21 Nov 2005, Linus Torvalds wrote:
> In general, making any internal git data versionable is very confusing. So
> you make the grafts file versionable - that suddenly means that different
> branches may have different parents for the same commit. And that
> depending on which branch you have checked out, git-fsck-cache may result
> in an error, or it may not. That's _nasty_, in my opinion.
Yes, that is nasty. It does not reflect my normal usage pattern, but that
does not make it better. So let's forget about that idea of mine.
Ciao,
Dscho
^ permalink raw reply
* [PATCH 6/6] Add check for downgrading of repo format version via init-db
From: Martin Atukunda @ 2005-11-22 0:28 UTC (permalink / raw)
To: git; +Cc: Martin Atukunda
In-Reply-To: <11326192921291-git-send-email-matlads@dsmagic.com>
This corrects an earlier assumption that init-db made. It assumed that the
config file was specifying a correct repo format version.
This patch clarifies the assumption by checking the repo format version
specified in the config to be copied, and dies if the copy will result in
an upgrade.
It however, warns if the copy will result in a downgrade of the repo format
version, as git tools are supposed (or will be able) to handle this case :)
Signed-Off-By: Martin Atukunda <matlads@dsmagic.com>
---
init-db.c | 41 +++++++++++++++++++++++++++++++++++++++--
1 files changed, 39 insertions(+), 2 deletions(-)
applies-to: 0095aa60b05c91308a25a00dc939bcd95e63b03f
7858de7a1a57e73d2585271b57acfcd044e27e68
diff --git a/init-db.c b/init-db.c
index 90be428..d1fc142 100644
--- a/init-db.c
+++ b/init-db.c
@@ -110,6 +110,15 @@ static void copy_templates_1(char *path,
}
}
+static int check_repo_config(const char *var, const char *value)
+{
+ if (strcmp(var, "core.repositoryformatversion") == 0) {
+ repository_format_version = git_config_int(var, value);
+ return 0;
+ }
+ return 1;
+}
+
static int init_db_config_check(const char *template_path)
{
DIR *dir;
@@ -117,8 +126,36 @@ static int init_db_config_check(const ch
dir = opendir(template_path);
while((de = readdir(dir)) != NULL) {
- if ((strncmp(de->d_name, "config", 5) == 0))
- return check_repo_format();
+ if ((strncmp(de->d_name, "config", 5) == 0)) {
+ int rfv1, rfv2;
+ char cpath[PATH_MAX];
+ check_repo_format();
+
+ /* is the file we are copying friendly? */
+ rfv1 = repository_format_version;
+ snprintf(cpath, sizeof(cpath), "%s%s", template_path,
+ de->d_name);
+ git_config_from_file(cpath, check_repo_config);
+ rfv2 = repository_format_version;
+ if (rfv1 == rfv2) {
+ break;
+ }
+ if (rfv2 < rfv1) {
+ /* the repo format specified in the conf file
+ * we are copying is older than the repo we
+ * are re-initialising! Downgrading?
+ */
+ fprintf(stderr, "Possibly downgrading repo"
+ " format version from %d to %d. Check"
+ " config template file!\n", rfv1, rfv2);
+ break;
+ } else
+ /* OK we die */
+ die ("Won't copy config file"
+ " for repo format version %d over"
+ " one for version %d",
+ rfv2, rfv1);
+ }
}
return 0;
}
---
0.99.9.GIT
^ permalink raw reply related
* [PATCH 5/6] Allow Specification of the conf file to read for git_config operations
From: Martin Atukunda @ 2005-11-22 0:28 UTC (permalink / raw)
To: git; +Cc: Martin Atukunda
In-Reply-To: <11326192921291-git-send-email-matlads@dsmagic.com>
This patch adds a git_config_from_file which allows us to specify the
config file to use for git_config operations.
Signed-Off-By: Martin Atukunda <matlads@dsmagic.com>
---
cache.h | 1 +
config.c | 10 +++++++---
2 files changed, 8 insertions(+), 3 deletions(-)
applies-to: d6c3faa0566795b1c74e693ecc004439c116e6c6
39e4ab307abb445115f3c9ee0e09ed1812568247
diff --git a/cache.h b/cache.h
index a455373..48018ab 100644
--- a/cache.h
+++ b/cache.h
@@ -388,6 +388,7 @@ extern int gitfakemunmap(void *start, si
typedef int (*config_fn_t)(const char *, const char *);
extern int git_default_config(const char *, const char *);
+extern int git_config_from_file(const char *, config_fn_t fn);
extern int git_config(config_fn_t fn);
extern int git_config_int(const char *, const char *);
extern int git_config_bool(const char *, const char *);
diff --git a/config.c b/config.c
index 5d237c8..c5a5312 100644
--- a/config.c
+++ b/config.c
@@ -245,11 +245,10 @@ int git_default_config(const char *var,
return 0;
}
-int git_config(config_fn_t fn)
+int git_config_from_file(const char *confpath, config_fn_t fn)
{
int ret;
- FILE *f = fopen(git_path("config"), "r");
-
+ FILE *f = fopen(confpath, "r");
ret = -1;
if (f) {
config_file = f;
@@ -260,6 +259,11 @@ int git_config(config_fn_t fn)
return ret;
}
+int git_config(config_fn_t fn)
+{
+ return git_config_from_file(git_path("config"), fn);
+}
+
/*
* Find all the stuff for git_config_set() below.
*/
---
0.99.9.GIT
^ permalink raw reply related
* [PATCH 3/6] Make get_git_dir take a flag that makes it re-read the env. variables
From: Martin Atukunda @ 2005-11-22 0:28 UTC (permalink / raw)
To: git; +Cc: Martin Atukunda
In-Reply-To: <11326192921291-git-send-email-matlads@dsmagic.com>
Signed-Off-By: Martin Atukunda <matlads@dsmagic.com>
---
cache.h | 2 +-
environment.c | 4 ++--
path.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
applies-to: 0748fd804fbe155503235e2c36d812fc3ef641a0
e3973791e841440ad92d91340fd954b5a58101c7
diff --git a/cache.h b/cache.h
index 54c283d..a455373 100644
--- a/cache.h
+++ b/cache.h
@@ -138,7 +138,7 @@ extern unsigned int active_nr, active_al
#define INDEX_ENVIRONMENT "GIT_INDEX_FILE"
#define GRAFT_ENVIRONMENT "GIT_GRAFT_FILE"
-extern char *get_git_dir(void);
+extern char *get_git_dir(int recheck_env);
extern char *get_object_directory(void);
extern char *get_refs_directory(void);
extern char *get_index_file(void);
diff --git a/environment.c b/environment.c
index 3f19473..6a961ca 100644
--- a/environment.c
+++ b/environment.c
@@ -39,9 +39,9 @@ static void setup_git_env(void)
git_graft_file = strdup(git_path("info/grafts"));
}
-char *get_git_dir(void)
+char *get_git_dir(int recheck_env)
{
- if (!git_dir)
+ if (!git_dir || recheck_env)
setup_git_env();
return git_dir;
}
diff --git a/path.c b/path.c
index 4d88947..e322dc0 100644
--- a/path.c
+++ b/path.c
@@ -42,7 +42,7 @@ char *mkpath(const char *fmt, ...)
char *git_path(const char *fmt, ...)
{
- const char *git_dir = get_git_dir();
+ const char *git_dir = get_git_dir(0);
va_list args;
unsigned len;
---
0.99.9.GIT
^ permalink raw reply related
* Git Future Proofing
From: Martin Atukunda @ 2005-11-22 0:28 UTC (permalink / raw)
To: git
This patch series adds git repository future proofing to git.
It adds checks for core.repositoryformatversion at various points in the git
architecture, and this is an overview of the patch series
Patch 1 adds GIT_REPO_VERSION and repository_format_version
Patch 2 fixes init-db's template copy so that it handles copying a config file.
Patch 3 adds support for re-reading gits env variables in certain cases
Patch 4 adds the repo format version check for various major operation
Patch 5 adds support for explictly specifying which config file to use
Patch 6 fixes up init-db config copying so as to never copy anything newer.
comments and suggestions welcome.
- Martin -
^ permalink raw reply
* [PATCH 1/6] Add GIT_REPO_VERSION, and repository_format_version
From: Martin Atukunda @ 2005-11-22 0:28 UTC (permalink / raw)
To: git; +Cc: Martin Atukunda
In-Reply-To: <11326192921291-git-send-email-matlads@dsmagic.com>
This variable will enable git to track the repository version. It's
currently set to 0. (in true C style :)
Signed-Off-By: Martin Atukunda <matlads@dsmagic.com>
---
cache.h | 4 ++++
environment.c | 1 +
2 files changed, 5 insertions(+), 0 deletions(-)
applies-to: 339319e60db7b3f96f8c711407b135a54da7aa2e
976b8d57a80d79853df9c142ba30d39b414e1b8e
diff --git a/cache.h b/cache.h
index c7c6637..54c283d 100644
--- a/cache.h
+++ b/cache.h
@@ -182,6 +182,10 @@ extern int trust_executable_bit;
extern int only_use_symrefs;
extern int diff_rename_limit_default;
+#define GIT_REPO_VERSION 0
+extern int repository_format_version;
+extern int check_repo_format(void);
+
#define MTIME_CHANGED 0x0001
#define CTIME_CHANGED 0x0002
#define OWNER_CHANGED 0x0004
diff --git a/environment.c b/environment.c
index b5026f1..3f19473 100644
--- a/environment.c
+++ b/environment.c
@@ -13,6 +13,7 @@ char git_default_email[MAX_GITNAME];
char git_default_name[MAX_GITNAME];
int trust_executable_bit = 1;
int only_use_symrefs = 0;
+int repository_format_version = 0;
static char *git_dir, *git_object_dir, *git_index_file, *git_refs_dir,
*git_graft_file;
---
0.99.9.GIT
^ permalink raw reply related
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