* Re: [PATCH] Corrected copy-and-paste thinko in ignore executable bit test case.
From: Shawn Pearce @ 2006-09-27 19:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr6xx9jta.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
>
> > This test should be testing update-index --add, not git-add as these
> > are two completely different implementations of what is essentially
> > the same task.
>
> Thanks -- I'd rephrase the last sentence, though.
-- >8 --
Corrected copy-and-paste thinko in ignore executable bit test case.
This test should be testing update-index --add, not git-add to
ensure all possible interfaces behave the same way.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
t/t3700-add.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/t3700-add.sh b/t/t3700-add.sh
index d36f22d..c20e4c2 100755
--- a/t/t3700-add.sh
+++ b/t/t3700-add.sh
@@ -35,7 +35,7 @@ test_expect_success \
'git repo-config core.filemode 0 &&
echo foo >xfoo2 &&
chmod 755 xfoo2 &&
- git-add xfoo2 &&
+ git-update-index --add xfoo2 &&
case "`git-ls-files --stage xfoo2`" in
100644" "*xfoo2) echo ok;;
*) echo fail; git-ls-files --stage xfoo2; exit 1;;
--
1.4.2.1.g1e40
^ permalink raw reply related
* Re: [PATCH] Corrected copy-and-paste thinko in ignore executable bit test case.
From: Junio C Hamano @ 2006-09-27 19:43 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060927151849.GF20705@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> This test should be testing update-index --add, not git-add as these
> are two completely different implementations of what is essentially
> the same task.
Thanks -- I'd rephrase the last sentence, though.
^ permalink raw reply
* Re: [PATCH] Removed memory leaks from interpolation table uses.
From: Junio C Hamano @ 2006-09-27 19:42 UTC (permalink / raw)
To: Jon Loeliger; +Cc: git
In-Reply-To: <E1GSc4w-0005cu-I3@jdl.com>
Jon Loeliger <jdl@jdl.com> writes:
> Junio,
>
> This is on top of my previous cleanup [PATCH Rev 3].
Thanks.
> BTW, In that previous patch of mine, this line:
>
> - and %D for the absolute path of the named repository.
>
> has trailing blanks in my patch that must be removed in order
> to apply it correctly to the HEAD of git. The _previous_ patch
> clearly was (correctly) applied with --whitepace=strip!
Yes, I usually use --whitespace=strip. The only time I
deliberately had to turn it off was to apply patches to diff
output test vectors.
Hopefully the recent addition to "diff --color" output to highlight
these potential whitespace errors would help spot them before
making commits.
^ permalink raw reply
* PATCH/RFC] allow delta data reuse even if base object is a preferred base
From: Nicolas Pitre @ 2006-09-27 19:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
Any reason why this couldn't be done?
When I reworked that code I preserved the existing logic wrt preferred
base. However I could not find a reason why it was that way. Hence
this patch.
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 6db97b6..ee5f031 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -989,7 +988,7 @@ static void check_object(struct object_e
unuse_packed_git(p);
entry->in_pack_header_size = used;
- if (base_entry && !base_entry->preferred_base) {
+ if (base_entry) {
/* Depth value does not matter - find_deltas()
* will never consider reused delta as the
^ permalink raw reply related
* Re: [RFC] git-split: Split the history of a git repository by subdirectories and ranges
From: Junio C Hamano @ 2006-09-27 19:31 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: Josh Triplett, git
In-Reply-To: <7vr6xxb00m.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> However, you can do:
>
> $ git rev-list --parents --pretty=raw
>
> which would give you "commit $this_commit $its $parents" lines
> and "parent $true_parent" lines at the same time.
>
> And they will be inconsistent when you have grafts or path
> limiter. The former honor grafts and path limiter, and the
> latter show the true set of parents.
-- >8 --
An illustration of rev-list --parents --pretty=raw
This script creates two separate histories, A and B, each of
which does:
(A0, B0): create fileA and subdir/fileB
(A1, B1): modify fileA
(A2, B2): modify subdir/fileB
and then grafts them together to make B0 a child of A2. So
the final history looks like (time flows from top to bottom):
true parent touches subdir?
A0 none yes (creates it)
A1 A0 no
A2 A1 yes
B0 none yes (different from what's in A2)
B1 B0 no
B2 B1 yes
"git rev-list --parents --pretty=raw B2" would give "fake"
parents on the "commit " header lines while "parent " header
lines show the parent as recorded in the commit object (i.e. B0
appears to have A2 as its parent on "commit " header but there
is no "parent A2" header line in it).
When you have path limiters, we simplify history to omit
commits that do not affect the specified paths.
So "git rev-list --parents --pretty=raw B2 subdir" would return
"B2 B0 A2 A0" (because B1 and A1 do not touch the path). When
it does so, the "commit " header lines have "fake" parents
(i.e. B2 appears to have B0 as its parent on "commit " header),
but you can still get the true parents by looking at "parent "
header.
---
diff --git a/t/t6001-rev-list-graft.sh b/t/t6001-rev-list-graft.sh
new file mode 100755
index 0000000..08a6cff
--- /dev/null
+++ b/t/t6001-rev-list-graft.sh
@@ -0,0 +1,113 @@
+#!/bin/sh
+
+test_description='Revision traversal vs grafts and path limiter'
+
+. ./test-lib.sh
+
+test_expect_success setup '
+ mkdir subdir &&
+ echo >fileA fileA &&
+ echo >subdir/fileB fileB &&
+ git add fileA subdir/fileB &&
+ git commit -a -m "Initial in one history." &&
+ A0=`git rev-parse --verify HEAD` &&
+
+ echo >fileA fileA modified &&
+ git commit -a -m "Second in one history." &&
+ A1=`git rev-parse --verify HEAD` &&
+
+ echo >subdir/fileB fileB modified &&
+ git commit -a -m "Third in one history." &&
+ A2=`git rev-parse --verify HEAD` &&
+
+ rm -f .git/refs/heads/master .git/index &&
+
+ echo >fileA fileA again &&
+ echo >subdir/fileB fileB again &&
+ git add fileA subdir/fileB &&
+ git commit -a -m "Initial in alternate history." &&
+ B0=`git rev-parse --verify HEAD` &&
+
+ echo >fileA fileA modified in alternate history &&
+ git commit -a -m "Second in alternate history." &&
+ B1=`git rev-parse --verify HEAD` &&
+
+ echo >subdir/fileB fileB modified in alternate history &&
+ git commit -a -m "Third in alternate history." &&
+ B2=`git rev-parse --verify HEAD` &&
+ : done
+'
+
+check () {
+ type=$1
+ shift
+
+ arg=
+ which=arg
+ rm -f test.expect
+ for a
+ do
+ if test "z$a" = z--
+ then
+ which=expect
+ child=
+ continue
+ fi
+ if test "$which" = arg
+ then
+ arg="$arg$a "
+ continue
+ fi
+ if test "$type" = basic
+ then
+ echo "$a"
+ else
+ if test "z$child" != z
+ then
+ echo "$child $a"
+ fi
+ child="$a"
+ fi
+ done >test.expect
+ if test "$type" != basic && test "z$child" != z
+ then
+ echo >>test.expect $child
+ fi
+ if test $type = basic
+ then
+ git rev-list $arg >test.actual
+ elif test $type = parents
+ then
+ git rev-list --parents $arg >test.actual
+ elif test $type = parents-raw
+ then
+ git rev-list --parents --pretty=raw $arg |
+ sed -n -e 's/^commit //p' >test.actual
+ fi
+ diff test.expect test.actual
+}
+
+for type in basic parents parents-raw
+do
+ test_expect_success 'without grafts' "
+ rm -f .git/info/grafts
+ check $type $B2 -- $B2 $B1 $B0
+ "
+
+ test_expect_success 'with grafts' "
+ echo '$B0 $A2' >.git/info/grafts
+ check $type $B2 -- $B2 $B1 $B0 $A2 $A1 $A0
+ "
+
+ test_expect_success 'without grafts, with pathlimit' "
+ rm -f .git/info/grafts
+ check $type $B2 subdir -- $B2 $B0
+ "
+
+ test_expect_success 'with grafts, with pathlimit' "
+ echo '$B0 $A2' >.git/info/grafts
+ check $type $B2 subdir -- $B2 $B0 $A2 $A0
+ "
+
+done
+test_done
^ permalink raw reply related
* [PATCH] zap a debug remnant
From: Nicolas Pitre @ 2006-09-27 19:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Signed-off-by: Nicolas Pitre <nico@cam.org>
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 6db97b6..16e98f3 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -440,7 +440,6 @@ static unsigned long write_object(struct
+ entry->in_pack_header_size;
datalen = find_packed_object_size(p, entry->in_pack_offset)
- entry->in_pack_header_size;
-//fprintf(stderr, "reusing %d at %d header %d size %d\n", obj_type, entry->in_pack_offset, entry->in_pack_header_size, datalen);
if (!pack_to_stdout && check_inflate(buf, datalen, entry->size))
die("corrupt delta in pack %s", sha1_to_hex(entry->sha1));
sha1write(f, buf, datalen);
^ permalink raw reply related
* Re: [RFC] git-split: Split the history of a git repository by subdirectories and ranges
From: Junio C Hamano @ 2006-09-27 19:08 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: Josh Triplett, git
In-Reply-To: <451A6788.5030808@shadowen.org>
Andy Whitcroft <apw@shadowen.org> writes:
>> You are handling grafts by hand because --pretty=raw is special
>> in that it displays the real parents (although traversal does
>> use grafts). Maybe it would have helped if we had a --pretty
>> format that is similar to raw but rewrites the parents?
>
> I have wondered recently why grafts are hidden in this way. I feel they
> are something I want to know is occuring in my history as this history
> is being manipulated.
Just to make sure we are on the same page, only "raw" format
output is special and it is special only on output. Ancestry
traversal always honors what you have in grafts.
However, you can do:
$ git rev-list --parents --pretty=raw
which would give you "commit $this_commit $its $parents" lines
and "parent $true_parent" lines at the same time.
And they will be inconsistent when you have grafts or path
limiter. The former honor grafts and path limiter, and the
latter show the true set of parents.
^ permalink raw reply
* Re: git and time
From: Andy Whitcroft @ 2006-09-27 18:53 UTC (permalink / raw)
To: Matthew L Foster
Cc: Andreas Ericsson, Junio C Hamano, git, Jeff King, Jakub Narebski
In-Reply-To: <20060927180147.33024.qmail@web51009.mail.yahoo.com>
Matthew L Foster wrote:
>> Because git doesn't care about timestamps. It stores them as comments
>> (albeit auto-formatted comments) and relies on the dependency chain to
>> provide history.
>
> Ok, the word "history" in the context of git primarily means the order of changes not the when?
> Would it be a conceptual or technical issue for git to directly track the local time of
> merges/changesets?
It is tracking the local times of each change as it is added to the
dependancy chain. This chain then moves about between repositories
carrying its stamp with it. When we merge a set of changes into a trunk
such as Linus does that merge will be stamped by him saying when he
merged it. So there is plenty of time stuff in there.
Of course none of it tells you when the kernel you are running has it
in. The only way to know that is to know when the thing was released,
under what version#, and what version you are running.
Now when we make a signed tag, doen't that make a new object too and I
assume that has a tagged date in it. That time might really actually
mean something and a fix's relation ship to those tags might also mean
something.
-apw
^ permalink raw reply
* Re: git and time
From: Linus Torvalds @ 2006-09-27 18:10 UTC (permalink / raw)
To: Matthew L Foster
Cc: Andreas Ericsson, Junio C Hamano, git, Jeff King, Jakub Narebski
In-Reply-To: <20060927180147.33024.qmail@web51009.mail.yahoo.com>
On Wed, 27 Sep 2006, Matthew L Foster wrote:
>
> Ok, the word "history" in the context of git primarily means the order of changes not the when?
> Would it be a conceptual or technical issue for git to directly track the local time of
> merges/changesets?
True merges _get_ tracked - they are commits too (they just have multiple
parents).
But it's only the time the merge was done that gets tracked, not the time
the merge was then pushed out to somebody else.
Linus
^ permalink raw reply
* Re: git and time
From: Linus Torvalds @ 2006-09-27 18:09 UTC (permalink / raw)
To: Edgar Toernig
Cc: Matthew L Foster, Junio C Hamano, git, Jeff King, Jakub Narebski
In-Reply-To: <20060927200054.7a49b619.froese@gmx.de>
On Wed, 27 Sep 2006, Edgar Toernig wrote:
>
> Well, I would simply look at the filesystem's mtime of the commit object
> resp. the pack containing the commit. IMHO good enough most of the time.
Nope. The moment you repack, you're toast. And if you don't repack, please
don't use large repositories.
Here's a real-world example: in the week since 2.6.18 was released, the
kernel has gotten over twenty _thousand_ new objects. If you don't repack,
you'll have lost about 40MB of diskspace. It adds up.
So yes, mtime works for a bit. And then it stops working ;)
Linus
^ permalink raw reply
* Re: git and time
From: Matthew L Foster @ 2006-09-27 18:01 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Junio C Hamano, git, Jeff King, Jakub Narebski
In-Reply-To: <451A8AD9.2010107@op5.se>
> Because git doesn't care about timestamps. It stores them as comments
> (albeit auto-formatted comments) and relies on the dependency chain to
> provide history.
Ok, the word "history" in the context of git primarily means the order of changes not the when?
Would it be a conceptual or technical issue for git to directly track the local time of
merges/changesets?
-Matt
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: git and time
From: Edgar Toernig @ 2006-09-27 18:00 UTC (permalink / raw)
To: Matthew L Foster
Cc: Linus Torvalds, Junio C Hamano, git, Jeff King, Jakub Narebski
In-Reply-To: <Pine.LNX.4.64.0609270919220.3952@g5.osdl.org>
Linus Torvalds wrote:
>
> On Wed, 27 Sep 2006, Matthew L Foster wrote:
> >
> > Perhaps git should record three(+) timestamps, adding when the change was committed into this
> > repository?
>
> What you CAN do is to connect (in any particular private repository) a
> _branch_update_ with the time it was done. That is Shawn Pierces "reflog"
> work - you can track a particular branch _locally_. It's purely local to
> that _one_ repository, though. It by definition makes no sense anywhere
> else, and it's not tracking commits, it's literally tracking how branches
> changed in a local copy.
Well, I would simply look at the filesystem's mtime of the commit object
resp. the pack containing the commit. IMHO good enough most of the time.
Ciao, ET.
^ permalink raw reply
* Re: Notes on Using Git with Subprojects
From: Jeff King @ 2006-09-27 17:33 UTC (permalink / raw)
To: A Large Angry SCM; +Cc: Martin Waitz, Shawn Pearce, Daniel Barkalow, git
In-Reply-To: <451AADC3.40201@gmail.com>
On Wed, Sep 27, 2006 at 09:58:43AM -0700, A Large Angry SCM wrote:
> This means that modules are not separate, stand alone projects but,
> rather, just a sub part of your bigger project. Very useful and
> applicable in some situations but other situations want/need separate,
> stand alone subprojects.
One thing that I believe some people have requested for subprojects is
to avoid downloading files/history for subprojects you're not interested
in. I think this could be faciliated in this scheme by only cloning the
heads of the subprojects you're interested in (there would need to be
special machinery to handle this at the root level if we want to allow
making root commits without necessarily having all of the subprojects).
A first step to this would be an argument to git-clone to allow cloning
only a subset of refs.
> The problem I'm working on is how to deal with the sub parts of a larger
> project when those sub parts are controlled by different entity. Silly
> example: the kernel is controlled by Linus; glibc is controlled by the
> GNU folks, gcc is controlled by some other GNU folks, the web server is
> controlled by the Apache Foundation, the X server is controlled by Xorg,
> etc.
The nice thing about this approach is that I believe the two systems
need only differ at clone time. Instead of creating a remotes file with
all of the subproject branches, you would just create multiple remotes
files. The root fetching porcelain needs to be smart enough to fetch all
remotes.
-Peff
^ permalink raw reply
* Re: Notes on Using Git with Subprojects
From: A Large Angry SCM @ 2006-09-27 17:13 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Martin Waitz, Shawn Pearce, Daniel Barkalow, git
In-Reply-To: <Pine.LNX.4.63.0609271152270.14200@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> Hi,
>
> On Wed, 27 Sep 2006, Martin Waitz wrote:
>
>> On Tue, Sep 26, 2006 at 03:33:49PM -0700, A Large Angry SCM wrote:
>>> So, for each subproject of a parent project, you want to record branch,
>>> version (commit ID), and directory location. Not quite as easy to do in
>>> a makefile but do-able.
>> I've been playing with this kind of subprojects a little bit.
>>
>> My current approach is like this:
>>
>> * create a .gitmodules file which lists all the directories
>> which contain a submodule.
>> * the .git/refs/heads directory of the submodule gets stored in
>> .gitmodule/<modulename> inside the parent project
>
> Taking this a step further, you could make subproject/.git/refs/heads a
> symbolic link to .git/refs/heads/subproject, with the benefit that fsck
> Just Works.
Wouldn't an fsck in the parent complain about missing objects?
^ permalink raw reply
* Re: Notes on Using Git with Subprojects
From: A Large Angry SCM @ 2006-09-27 16:58 UTC (permalink / raw)
To: Martin Waitz; +Cc: Shawn Pearce, Daniel Barkalow, git
In-Reply-To: <20060927080652.GA8056@admingilde.org>
Martin Waitz wrote:
[...]
> My current approach is like this:
>
> * create a .gitmodules file which lists all the directories
> which contain a submodule.
> * the .git/refs/heads directory of the submodule gets stored in
> .gitmodule/<modulename> inside the parent project
> * both things above should be tracked in the parent project.
> This way you always store the current state of each submodule
> in each commit of the parent project. And you don't have to
> create a new parent commit for each change. You can commit
> to the parent project when you think that all your modules are
> in a good state.
This means that modules are not separate, stand alone projects but,
rather, just a sub part of your bigger project. Very useful and
applicable in some situations but other situations want/need separate,
stand alone subprojects.
> * When checking out a project, all submodules listen in .gitmodules
> get checked out, too.
> * If there is a merge conflict in the module list or its refs/heads,
> this is handled specially, e.g. by triggering a new merge inside
> the submodule.
> * The object directory is shared between the parent and all modules.
> To make fsck-objects happy, the parent gets a refs/module link
> pointing to .gitmodule/ and all submodules get a refs/parent
> link pointing to the refs directory of the parent.
>
[...]
> By storing the complete refs/heads directory for each submodule instead
> of only one head, it is possible to track multiple branches of a
> subproject. I'm don't know yet how this works out in praktice but I
> think that it can be nice to be able to atomically commit to several
> branches of one submodule (perhaps one branch per customer, per
> hardware platform, whatever).
It's not immediately clear to me if tracking several long term
(globally) visible branches in a checkout sub module is generally useful
or only useful in special situations. I need to think about this...
[...]
You solved a similar problem to the one I'm working on; and one that is
applicable to a number of projects. Namely, projects where all the parts
are under the control of the same entity. For projects looking to escape
CVS, that use CVS modules, this looks like a Git solution.
The problem I'm working on is how to deal with the sub parts of a larger
project when those sub parts are controlled by different entity. Silly
example: the kernel is controlled by Linus; glibc is controlled by the
GNU folks, gcc is controlled by some other GNU folks, the web server is
controlled by the Apache Foundation, the X server is controlled by Xorg,
etc.
^ permalink raw reply
* Re: git and time
From: Linus Torvalds @ 2006-09-27 16:29 UTC (permalink / raw)
To: Matthew L Foster; +Cc: Junio C Hamano, git, Jeff King, Jakub Narebski
In-Reply-To: <20060927140918.65775.qmail@web51004.mail.yahoo.com>
On Wed, 27 Sep 2006, Matthew L Foster wrote:
>
> Perhaps git should record three(+) timestamps, adding when the change was committed into this
> repository?
If you ask for logging, that's exactly what you get.
Well, almost.
You cannot connect the time to a _commit_, since a commit (very much by
design) is totally immutable. Once you have created any git object, it's
done. It can never be changed ever again, and this is not just a small
detail, it's what the whole system builds up on, and it's where the
security and trustworthiness fundamentally comes from (it's also where the
naming scheme comes from - things are named by their contents, so if you
were to ever change them again, they'd have to be renamed - they
effectively _become_ something different).
Also, you fundamentally couldn't do it anyway, since the third time isn't
actually even well-defined in a distributed manner. It only makes sense
very much in a local way, and as such can never be part of the distributed
data - and trying to add something like that to the commit would be
fundamentally incorrect.
BUT.
What you CAN do is to connect (in any particular private repository) a
_branch_update_ with the time it was done. That is Shawn Pierces "reflog"
work - you can track a particular branch _locally_. It's purely local to
that _one_ repository, though. It by definition makes no sense anywhere
else, and it's not tracking commits, it's literally tracking how branches
changed in a local copy.
To enable it, just add a
[core]
logAllRefUpdates=true
thing to your .git/config file (or, if you want to do it for _all_ the
projects you track, you can just do it in your ~/.gitconfig file, and it
should be the default for everything you do).
(Althernatively, you can choose to log just a _single_ branch by just
creating the ".git/logs/refs/heads/<branchname>" file - git should start
logging that branch automatically)
This is a reasonably new feature, so old git versions need not apply.
Linus
^ permalink raw reply
* [PATCH] Removed memory leaks from interpolation table uses.
From: Jon Loeliger @ 2006-09-27 16:16 UTC (permalink / raw)
To: git
Clarified that parse_extra_args()s results in
interpolation table entries.
Removed a few trailing whitespace occurrences.
Signed-off-by: Jon Loeliger <jdl@jdl.com>
---
Junio,
This is on top of my previous cleanup [PATCH Rev 3].
BTW, In that previous patch of mine, this line:
- and %D for the absolute path of the named repository.
has trailing blanks in my patch that must be removed in order
to apply it correctly to the HEAD of git. The _previous_ patch
clearly was (correctly) applied with --whitepace=strip!
*sigh*
Thanks,
jdl
daemon.c | 56 ++++++++++++++++++++++++++++++++++----------------------
interpolate.c | 26 ++++++++++++++++++++++++++
interpolate.h | 3 +++
3 files changed, 63 insertions(+), 22 deletions(-)
diff --git a/daemon.c b/daemon.c
index 260f0cf..46c7fa2 100644
--- a/daemon.c
+++ b/daemon.c
@@ -71,7 +71,7 @@ static struct interp interp_table[] = {
{ "%IP", 0},
{ "%P", 0},
{ "%D", 0},
- { "%%", "%"},
+ { "%%", 0},
};
@@ -398,7 +398,11 @@ static void make_service_overridable(con
die("No such service %s", name);
}
-static void parse_extra_args(char *extra_args, int buflen)
+/*
+ * Separate the "extra args" information as supplied by the client connection.
+ * Any resulting data is squirrelled away in the given interpolation table.
+ */
+static void parse_extra_args(struct interp *table, char *extra_args, int buflen)
{
char *val;
int vallen;
@@ -410,18 +414,17 @@ static void parse_extra_args(char *extra
val = extra_args + 5;
vallen = strlen(val) + 1;
if (*val) {
- char *port;
- char *save = xmalloc(vallen); /* FIXME: Leak */
-
- interp_table[INTERP_SLOT_HOST].value = save;
- strlcpy(save, val, vallen);
- port = strrchr(save, ':');
+ /* Split <host>:<port> at colon. */
+ char *host = val;
+ char *port = strrchr(host, ':');
if (port) {
*port = 0;
port++;
- interp_table[INTERP_SLOT_PORT].value = port;
+ interp_set_entry(table, INTERP_SLOT_PORT, port);
}
+ interp_set_entry(table, INTERP_SLOT_HOST, host);
}
+
/* On to the next one */
extra_args = val + vallen;
}
@@ -431,8 +434,6 @@ static void parse_extra_args(char *extra
void fill_in_extra_table_entries(struct interp *itable)
{
char *hp;
- char *canon_host = NULL;
- char *ipaddr = NULL;
/*
* Replace literal host with lowercase-ized hostname.
@@ -459,10 +460,12 @@ #ifndef NO_IPV6
for (ai = ai0; ai; ai = ai->ai_next) {
struct sockaddr_in *sin_addr = (void *)ai->ai_addr;
- canon_host = xstrdup(ai->ai_canonname);
inet_ntop(AF_INET, &sin_addr->sin_addr,
addrbuf, sizeof(addrbuf));
- ipaddr = addrbuf;
+ interp_set_entry(interp_table,
+ INTERP_SLOT_CANON_HOST, ai->ai_canonname);
+ interp_set_entry(interp_table,
+ INTERP_SLOT_IP, addrbuf);
break;
}
freeaddrinfo(ai0);
@@ -476,22 +479,20 @@ #else
static char addrbuf[HOST_NAME_MAX + 1];
hent = gethostbyname(interp_table[INTERP_SLOT_HOST].value);
- canon_host = xstrdup(hent->h_name);
ap = hent->h_addr_list;
memset(&sa, 0, sizeof sa);
sa.sin_family = hent->h_addrtype;
sa.sin_port = htons(0);
memcpy(&sa.sin_addr, *ap, hent->h_length);
-
+
inet_ntop(hent->h_addrtype, &sa.sin_addr,
addrbuf, sizeof(addrbuf));
- ipaddr = addrbuf;
+
+ interp_set_entry(interp_table, INTERP_SLOT_CANON_HOST, hent->h_name);
+ interp_set_entry(interp_table, INTERP_SLOT_IP, addrbuf);
}
#endif
-
- interp_table[INTERP_SLOT_CANON_HOST].value = canon_host; /* FIXME: Leak */
- interp_table[INTERP_SLOT_IP].value = xstrdup(ipaddr); /* FIXME: Leak */
}
@@ -535,8 +536,14 @@ #endif
if (len && line[len-1] == '\n')
line[--len] = 0;
+ /*
+ * Initialize the path interpolation table for this connection.
+ */
+ interp_clear_table(interp_table, ARRAY_SIZE(interp_table));
+ interp_set_entry(interp_table, INTERP_SLOT_PERCENT, "%");
+
if (len != pktlen) {
- parse_extra_args(line + len + 1, pktlen - len - 1);
+ parse_extra_args(interp_table, line + len + 1, pktlen - len - 1);
fill_in_extra_table_entries(interp_table);
}
@@ -546,7 +553,12 @@ #endif
if (!strncmp("git-", line, 4) &&
!strncmp(s->name, line + 4, namelen) &&
line[namelen + 4] == ' ') {
- interp_table[INTERP_SLOT_DIR].value = line+namelen+5;
+ /*
+ * Note: The directory here is probably context sensitive,
+ * and might depend on the actual service being performed.
+ */
+ interp_set_entry(interp_table,
+ INTERP_SLOT_DIR, line + namelen + 5);
return run_service(interp_table, s);
}
}
@@ -982,7 +994,7 @@ int main(int argc, char **argv)
char *ph = listen_addr = xmalloc(strlen(arg + 9) + 1);
while (*p)
*ph++ = tolower(*p++);
- *ph = 0;
+ *ph = 0;
continue;
}
if (!strncmp(arg, "--port=", 7)) {
diff --git a/interpolate.c b/interpolate.c
index d82f1b5..8357742 100644
--- a/interpolate.c
+++ b/interpolate.c
@@ -4,9 +4,35 @@
#include <string.h>
+#include "git-compat-util.h"
#include "interpolate.h"
+void interp_set_entry(struct interp *table, int slot, char *value)
+{
+ char *oldval = table[slot].value;
+ char *newval = value;
+
+ if (oldval)
+ free(oldval);
+
+ if (value)
+ newval = xstrdup(value);
+
+ table[slot].value = newval;
+}
+
+
+void interp_clear_table(struct interp *table, int ninterps)
+{
+ int i;
+
+ for (i = 0; i < ninterps; i++) {
+ interp_set_entry(table, i, NULL);
+ }
+}
+
+
/*
* Convert a NUL-terminated string in buffer orig
* into the supplied buffer, result, whose length is reslen,
diff --git a/interpolate.h b/interpolate.h
index 00c63a5..7f386bd 100644
--- a/interpolate.h
+++ b/interpolate.h
@@ -11,6 +11,9 @@ struct interp {
char *value;
};
+extern void interp_set_entry(struct interp *table, int slot, char *value);
+extern void interp_clear_table(struct interp *table, int ninterps);
+
extern int interpolate(char *result, int reslen,
char *orig,
struct interp *interps, int ninterps);
--
1.4.2.1.g85d8-dirty
^ permalink raw reply related
* Re: git and time
From: Jeff King @ 2006-09-27 15:28 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <451A398C.3060800@op5.se>
On Wed, Sep 27, 2006 at 10:42:52AM +0200, Andreas Ericsson wrote:
> >>It's true I don't know much about git, what is the difference
> >>between a changeset and a snapshot? Are you saying timestamps
> >
> >I do not know what Jeff meant by snapshot vs changeset, so I
> >would not comment on this part.
>
> Me neither, but I've seen this distinction before on the mailing-list.
>
> To my mind, a changeset is the patch that brings some form of data from
> one state (snapshot) to another. In this respect, git is certainly both
> snapshot- and changeset-based.
I was talking specifically about the core data structure of git. The
commit object doesn't say "I'm based on commit X, and the deltas are Y."
It says "Here are the complete contents of the tree at this point, and
the previous complete contents were X."
Of course, git often shows changesets (patches, git-whatchanged, etc)
because that's what's useful to users. But the context of the discussion
was fetching commits to a repository. In that case it's important to
note that you're just grabbing the new state (albeit optimizing the
process by skipping things you have) and not "re-committing" changesets
(which is what the OP seemed to think was happening).
-Peff
^ permalink raw reply
* [PATCH] Corrected copy-and-paste thinko in ignore executable bit test case.
From: Shawn Pearce @ 2006-09-27 15:18 UTC (permalink / raw)
To: git
This test should be testing update-index --add, not git-add as these
are two completely different implementations of what is essentially
the same task.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
t/t3700-add.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/t3700-add.sh b/t/t3700-add.sh
index d36f22d..c20e4c2 100755
--- a/t/t3700-add.sh
+++ b/t/t3700-add.sh
@@ -35,7 +35,7 @@ test_expect_success \
'git repo-config core.filemode 0 &&
echo foo >xfoo2 &&
chmod 755 xfoo2 &&
- git-add xfoo2 &&
+ git-update-index --add xfoo2 &&
case "`git-ls-files --stage xfoo2`" in
100644" "*xfoo2) echo ok;;
*) echo fail; git-ls-files --stage xfoo2; exit 1;;
--
1.4.2.1.g1e40
^ permalink raw reply related
* Re: [PATCH 3/3] diff --stat: sometimes use non-linear scaling.
From: Linus Torvalds @ 2006-09-27 15:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jan Engelhardt, Adrian Bunk
In-Reply-To: <7vfyeejakq.fsf@assigned-by-dhcp.cox.net>
On Tue, 26 Sep 2006, Junio C Hamano wrote:
>
> When some files have big changes and others are touched only
> slightly, diffstat graph did not show differences among smaller
> changes that well. This changes the graph scaling to non-linear
> algorithm in such a case.
Ok, this is just _strange_.
> while with this, it shows:
>
> .gitignore | 1
> Documentation/git-tar-tree.txt | 3 +++++++++
No _way_ is it correct to show more than three characters if there were
three lines of changes.
I think "nonlinear" is fine, but this is something that is "superlinear"
in small changes, and then sublinear in bigger ones (and then apparently
totally wrong for one-line changes).
It should at least never be superlinear, I believe.
Linus
^ permalink raw reply
* Re: git and time
From: Shawn Pearce @ 2006-09-27 15:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfyedd3bw.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> One thing that makes "the common library code" less useful is
> that lock_ref_sha1() and its cousin lock_any_ref_for_update() do
> not let the caller to tell why a ref could not be locked ("did
> it not exist? did the old_sha1 not match?" and in
> lock_ref_sha1()'s case "did the ref have funny characters?").
Yes. But I thought that in all such cases we use error or die so
the message is sent to STDERR before the process either terminates
or the function returns NULL. So although the caller doesn't know
why the lock failed the end user does.
Git hasn't exactly structured its error messages in the past.
If we are talking about going down the path of having functions
return why they failed to the caller so the caller can react to
the failure as they see fit then we've got some work to do. :)
> diff --git a/receive-pack.c b/receive-pack.c
> @@ -318,9 +258,11 @@ int main(int argc, char **argv)
> if (!dir)
> usage(receive_pack_usage);
>
> - if(!enter_repo(dir, 0))
> + if (!enter_repo(dir, 0))
> die("'%s': unable to chdir or not a git archive", dir);
>
You are missing:
+ setup_ident();
Without that reflog can't get the proper committer data from the
host's gecos information. This is probably what is desired for
most pushes over SSH.
> + git_config(git_default_config);
> +
> write_head_info();
--
Shawn.
^ permalink raw reply
* Re: git and time
From: Andreas Ericsson @ 2006-09-27 14:29 UTC (permalink / raw)
To: Matthew L Foster; +Cc: Junio C Hamano, git, Jeff King, Jakub Narebski
In-Reply-To: <20060927140918.65775.qmail@web51004.mail.yahoo.com>
Matthew L Foster wrote:
> How can git be
> said to keep an accurate record of history if time is uncertain?
>
Because git doesn't care about timestamps. It stores them as comments
(albeit auto-formatted comments) and relies on the dependency chain to
provide history.
In the same way that contributors are expected to write clear and
concise commit-messages, they are also expected to keep their system
clocks somewhat in sync. Sometimes one or the other fails, and this is
as inevitable as it can be annoying (although commit-messages along the
line of "fixed some bugs causing some random crashes" for a commit that
touches 2384 lines are indefinitely worse than a bad timestamp).
What's beautiful about git is that it's designed to present a correct
history even if random-contributor-X's system clock is out of sync with
the rest of the world, as it inevitably will be at one point or another.
It handles content, and the order in which each piece of content was
added/removed/mutilated/transformed into something else, and it does a
good job at that.
All that aside though, would you rather have that fix pronto with a bad
timestamp, or three days later when the contributor had time to set up
ntp properly?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git and time
From: Matthew L Foster @ 2006-09-27 14:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeff King, Jakub Narebski
In-Reply-To: <7vodt2nmft.fsf@assigned-by-dhcp.cox.net>
> Each commit object in git records two timestamps. When the
> author made that change, and when the change was made into a
> commit object in _some_ repository.
Perhaps git should record three(+) timestamps, adding when the change was committed into this
repository? Last weekend there was a committ in Linus' kernel tree with a timestamp ~2 days into
the future, which could be a problem in a scenario involving when an important bug fix was
merged/published in Linus' kernel tree, situations like that should be impossible. How can git be
said to keep an accurate record of history if time is uncertain?
-Matt
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: Notes on Using Git with Subprojects
From: Johannes Schindelin @ 2006-09-27 13:13 UTC (permalink / raw)
To: Martin Waitz; +Cc: A Large Angry SCM, Shawn Pearce, Daniel Barkalow, git
In-Reply-To: <20060927124604.GD8056@admingilde.org>
Hi,
On Wed, 27 Sep 2006, Martin Waitz wrote:
> On Wed, Sep 27, 2006 at 02:01:11PM +0200, Johannes Schindelin wrote:
>
> > AFAICT this is not the idea of subprojects-in-git. If you have to track
> > the subprojects in the root project manually anyway, you don't need _any_
> > additional tool (you _can_ track files in a subdirectory containing a .git
> > subdirectory).
>
> But then you loose the fine grained commits of your subprojects. You
> only store the tree of the subproject when committing to the parent, not
> the entire history.
The more I get told about subprojects (I don't have a use for them
myself), the more I think you are right: subprojects should not be
integrated deeply into git.
Ciao,
Dscho
^ permalink raw reply
* Re: Notes on Using Git with Subprojects
From: Martin Waitz @ 2006-09-27 12:46 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: A Large Angry SCM, Shawn Pearce, Daniel Barkalow, git
In-Reply-To: <Pine.LNX.4.63.0609271358100.14200@wbgn013.biozentrum.uni-wuerzburg.de>
[-- Attachment #1: Type: text/plain, Size: 1914 bytes --]
hoi :)
On Wed, Sep 27, 2006 at 02:01:11PM +0200, Johannes Schindelin wrote:
> On Wed, 27 Sep 2006, Martin Waitz wrote:
> > On Wed, Sep 27, 2006 at 11:55:22AM +0200, Johannes Schindelin wrote:
> > > > My current approach is like this:
> > > >
> > > > * create a .gitmodules file which lists all the directories
> > > > which contain a submodule.
> > > > * the .git/refs/heads directory of the submodule gets stored in
> > > > .gitmodule/<modulename> inside the parent project
> > >
> > > Taking this a step further, you could make subproject/.git/refs/heads a
> > > symbolic link to .git/refs/heads/subproject, with the benefit that fsck
> > > Just Works.
> >
> > in fact it is done this way (more or less).
>
> With the difference, that if you store the refs outside of
> <root>/.git/refs, you have to take extra care that prune does not delete
> the corresponding objects.
that's why there is .git/refs/module/modulname -> .gitmodule/modulename.
> > You can accumulate as many changes in different subprojects until you
> > get to a state that is worth committing in the parent project.
> > All these changes are then seen as one atomic change to the whole
> > project.
>
> AFAICT this is not the idea of subprojects-in-git. If you have to track
> the subprojects in the root project manually anyway, you don't need _any_
> additional tool (you _can_ track files in a subdirectory containing a .git
> subdirectory).
But then you loose the fine grained commits of your subprojects.
You only store the tree of the subproject when committing to the parent,
not the entire history.
I think having the "commit subproject changes to parent" step as a
manual action makes sense in the same way as you have to trigger a
commit to a repository by hand, too. You are not storing every little
change to your filesystem in the database.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ 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