* Re: Performance problem, long run of identical hashes
From: Jon Smirl @ 2007-12-10 16:20 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Git Mailing List
In-Reply-To: <alpine.LFD.0.99999.0712101037270.555@xanadu.home>
On 12/10/07, Nicolas Pitre <nico@cam.org> wrote:
> On Mon, 10 Dec 2007, Jon Smirl wrote:
>
> > Running oprofile during my gcc repack shows this loop as the hottest
> > place in the code by far.
>
> Well, that is kind of expected.
>
> > I added some debug printfs which show that I
> > have a 100,000+ run of identical hash entries. Processing the 100,000
> > entries also causes RAM consumption to explode.
>
> That is impossible. If you look at the code where those hash entries
> are created in create_delta_index(), you'll notice a hard limit of
> HASH_LIMIT (currently 64) is imposed on the number of identical hash
> entries.
On 12/10/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> On 12/9/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> > > + if (victim) {
> > > + sub_size = victim->remaining / 2;
> > > + list = victim->list + victim->list_size - sub_size;
> > > + while (sub_size && list[0]->hash &&
> > > + list[0]->hash == list[-1]->hash) {
> > > + list++;
> >
> > I think you needed to copy sub_size to another variable for this loop
>
> Copying sub_size was wrong. I believe you are checking for deltas on
> the same file. It's probably that chain of 103,817 deltas that can't
> be broken up.
At the end of multi-threaded repack one thread ends up with 45 minutes
of work after all the other threads have exited. That's because it
hits this loop and can't spit the list any more.
If the lists can't be over 64 identical entries, why do I get caught
in this loop for 50,000+ iterations? If remove this loop the threads
are balanced right to the end.
--
Jon Smirl
jonsmirl@gmail.com
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH 2/2] pack-objects: fix threaded load balancing
From: Nicolas Pitre @ 2007-12-10 16:14 UTC (permalink / raw)
To: Jon Smirl; +Cc: Junio C Hamano, git
In-Reply-To: <9e4733910712092206o40e0c748s3796b95f637bf2b3@mail.gmail.com>
On Mon, 10 Dec 2007, Jon Smirl wrote:
> On 12/10/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> > I just deleted the section looking for identical hashes.
> >
> > + while (sub_size && list[0]->hash &&
> > + list[0]->hash == list[-1]->hash) {
> > + list++;
> > + sub_size--;
> > + }
> >
> > Doing that allows the long chains to be split over the cores.
> >
> > My last 5% of objects is taking over 50% of the total CPU time in the
> > repack. I think these objects are the ones from that 103,817 entry
> > chain. It is also causing the explosion in RAM consumption.
> >
> > At the end I can only do 20 objects per clock second on four cores. It
> > takes 30 clock minutes (120 CPU minutes) to do the last 3% of objects.
>
> It's all in create_delta...
Here you're mixing two different hashes with no relation what so ever
with each other.
The hash in create_delta corresponds to chunk of data in a reference
buffer that we try to match in a source buffer.
The hash in the code above has to do with the file names the
corresponding objects are coming from.
And again, both hash uses are deterministic i.e. they will be the same
when repacking with -f regardless if the source pack is the 2.1GB or the
300MB one, so they may not explain the huge performance and memory usage
discrepency you see between those two packs.
The code that do get influenced by the source pack, though, is all
concentrated in sha1_file.c.
Nicolas
^ permalink raw reply
* Re: [PATCH 2/2] pack-objects: fix threaded load balancing
From: Nicolas Pitre @ 2007-12-10 16:03 UTC (permalink / raw)
To: Jon Smirl; +Cc: Junio C Hamano, git
In-Reply-To: <9e4733910712092219kd86e576k33b11c93179f6475@mail.gmail.com>
On Mon, 10 Dec 2007, Jon Smirl wrote:
> It seems to be caused by looping over those runs of 100,000 identical
> hash entries.
As mentioned earlier, there simply can't be 100000 identical hash
entries.
> 5091699 24.6407 : for (entry = index->hash[i]; entry < index->hash[i+1]; entry++) {
> 5301791 25.6575 : const unsigned char *ref = entry->ptr;
This loop is the very heart of the delta search code. It is normal to
see it high on the graph. In some worst cases, this loop might even be
entered for every byte in the source buffer.
And yet I bring you back to your observation about the fact that the
source pack used for the repack (whether it is the 2.1GB pack or the
300MB pack) has a great influence on the performance outcome. The code
above, though, would be executed the very exact number of times, and the
exact amount of memory allocated, regardless of the source pack used (as
long as you use -f with 'git repack' of course).
So this cannot be the culprit.
Nicolas
^ permalink raw reply
* Re: Adding Git to Better SCM Initiative : Comparison
From: Jakub Narebski @ 2007-12-10 15:47 UTC (permalink / raw)
To: Florian Weimer; +Cc: git, Shlomi Fish
In-Reply-To: <87ve76mwos.fsf@mid.deneb.enyo.de>
Florian Weimer <fw@deneb.enyo.de> writes:
> * Jakub Narebski:
> > @@ -214,6 +225,13 @@ <title>File and Directories Copies</title>
[...]
> > + <s id="git">
> > + Yes (or no depending on interpretation). Git
>
> This should be "No." (same for copies below).
I would agree to "N/A" or "Partial", but with 'git log --follow'
implemented at least for single file I wouldn't say that that git
doesn't support file and directories renames (copies). It does, in
it's own fashion, using rename (copy) detection instead of rename
(copy) tracking.
By the way, the explanation for "File and Directories Copies" section
itself is a bit imprecise; well at least it doesn't lead to easy
answer for git. I took it as question if we can examine _history_
of a file (or directory) across renames (copies). Other
interpretation would be if version control system in question
correctly handles renames and copies during merges... but it is in
TODO (Add intelligent merging of renamed paths.)
> > + <s id="git">
> > + Partial (?). It is possible to lock down repository
> > + (access to branches and tags) using hooks.
> > + </s>
>
> I doubt this works reliably. You still can access data once you've got
> its SHA1 hash, for instance.
So what? The data is not visible, so it is as if it didn't
exist. Besides if you are truly paranoid you can I think remove
downloaded pack.
By the way the default 'contrib/hooks/update-paranoid' implements ACL
restricting access to branches and tags, but I think that you can
write a hook which would refuse update if there are changes outside
specified subdirectory for example.
Note however that "repository permissions" are much more important for
centralized SCMs than for distributed SCMs, where you can form
"network of trust" (like Linus with his kernel's lieutenants and
subsystem maintainers).
> > + <s id="git">
> > + Yes. Changesets are supported.<br />
> > + Actually Git is snapshot based which means Git records
> > + the full state in every commit. This means that any two
> > + commits can be compared directly very quickly, although the
> > + repository is typically browsed as a series of changesets.
> > + </s>
>
> I don't think this explanation is necessary. What does Subversion say?
Subversion has the following currently:
Partial support. There are implicit changeset that are generated on
each commit.
Well, we could follow Mercurial, Monotone and Darcs and simply write
+ <s id="git">
+ Yes. Changesets are supported.
+ </s>
> > + <s id="git">
> > + Yes. (git blame, git gui blame).
> > + It can also detect the origin of copied and moved source
> > + lines, and can ignore whitespace changes.
> > + </s>
>
> A simple "Yes." should suffice.
Each SCM names the command for displaying line-wise file history,
if it of course exists.
While "can ignore whitespace changes" is not that important, detection
of contents movement and copying is important differentiation,
possible (or at least implemented) because Git uses rename detection
rather than rename tracking.
> > @@ -636,6 +677,10 @@ <title>Tracking Uncommited Changes</title>
> > Yes, using "darcs whatsnew".
> > </s>
> > <s id="aegis">Yes. Using aediff</s>
> > + <s id="git">
> > + Yes, of course. Using git diff.
> > + Note that git uses staging area for commits (index).
> > + </s>
>
> Simply "Yes.". "git diff" is wrong, it's actually "git diff HEAD".
Actually it depends on the definition of "uncommitted changes".
Besides "git diff HEAD" _is_ "using git diff".
But it's true that 'of course' there is not needed.
> > @@ -681,6 +726,11 @@ <title>Per-File Commit Messages</title>
> > <s id="darcs">
> > No.
> > </s>
> > + <s id="git">
> > + No. The message applies to the commit as a whole.
> > + But you can tag (with description) given contents
> > + of a file (blob).
> > + </s>
>
> Have we got any real tool support for this? This should be "No.".
True. But I'd rather leave it as "No. The message applies to the
commit as a whole." because that is important property.
> > @@ -1006,6 +1075,13 @@ <title>Command Set</title>
> > but since the model is different most commands are
> > unique.
> > </s>
> > + <s id="git">
> > + Tries to follow CVS conventions, but deviates where there
> > + is a different design (following BitKeeper for DVCS).
>
> I don't think this is true. Is there any command that closely matches
> what CVS does?
Yes: init, add, annotate (alias to blame), checkout, commit, diff,
status, log, version. At least in principle, if not in output format.
I don't think that Mercurial and Monotone follow CVS much better than
Git. (But that was one of answers I was having problems with.)
> > @@ -1203,6 +1286,11 @@ <title>Portability</title>
> > Very good. Supports many UNIXes, Mac OS X, and Windows,
> > and is written in a portable language.
> > </s>
> > + <s id="git">
> > + Good to very good. Portable across all POSIX systems.
> > + There exists Win32 binary using MinGW (msysGit),
> > + or you can use binary provided by Cygwin.
> > + </s>
>
> Isn't Windows support still a bit lacking in terms of performance?
That is more a problem with Windows, than Git ;-)
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Performance problem, long run of identical hashes
From: Nicolas Pitre @ 2007-12-10 15:45 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910712100707i66e185bofe22805b8e0ba4d8@mail.gmail.com>
On Mon, 10 Dec 2007, Jon Smirl wrote:
> Running oprofile during my gcc repack shows this loop as the hottest
> place in the code by far.
Well, that is kind of expected.
> I added some debug printfs which show that I
> have a 100,000+ run of identical hash entries. Processing the 100,000
> entries also causes RAM consumption to explode.
That is impossible. If you look at the code where those hash entries
are created in create_delta_index(), you'll notice a hard limit of
HASH_LIMIT (currently 64) is imposed on the number of identical hash
entries.
Nicolas
^ permalink raw reply
* Re: Adding Git to Better SCM Initiative : Comparison
From: Florian Weimer @ 2007-12-10 15:36 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0712101522290.27959@racer.site>
* Johannes Schindelin:
>> > + <s id="git">
>> > + Yes (or no depending on interpretation). Git
>>
>> This should be "No." (same for copies below).
>
> Nice. I have no idea what you are talking about, as you only quoted the
> answer, but not the question.
Oops. It's about the rename/copy detection stuff.
> (Same for the other quoted text.)
I tried to provide more context in those cases; the @@ lines should be
sufficient, I guess.
^ permalink raw reply
* Re: Git and GCC
From: Nicolas Pitre @ 2007-12-10 15:35 UTC (permalink / raw)
To: Gabriel Paubert
Cc: Harvey Harrison, Linus Torvalds, Jeff King, Jon Smirl,
Daniel Berlin, David Miller, ismail, gcc, git
In-Reply-To: <20071210095426.GA32611@iram.es>
On Mon, 10 Dec 2007, Gabriel Paubert wrote:
> On Fri, Dec 07, 2007 at 04:47:19PM -0800, Harvey Harrison wrote:
> > Some interesting stats from the highly packed gcc repo. The long chain
> > lengths very quickly tail off. Over 60% of the objects have a chain
> > length of 20 or less. If anyone wants the full list let me know. I
> > also have included a few other interesting points, the git default
> > depth of 50, my initial guess of 100 and every 10% in the cumulative
> > distribution from 60-100%.
> >
> > This shows the git default of 50 really isn't that bad, and after
> > about 100 it really starts to get sparse.
>
> Do you have a way to know which files have the longest chains?
With 'git verify-pack -v' you get the delta depth for each object.
Then you can use 'git show' with the object SHA1 to see its content.
> I have a suspiscion that the ChangeLog* files are among them,
> not only because they are, almost without exception, only modified
> by prepending text to the previous version (and a fairly small amount
> compared to the size of the file), and therefore the diff is simple
> (a single hunk) so that the limit on chain depth is probably what
> causes a new copy to be created.
My gcc repo is currently repacked with a max delta depth of 50, and
a quick sample of those objects at the depth limit does indeed show the
content of the ChangeLog file. But I have occurrences of the root
directory tree object too, and the "GCC machine description for IA-32"
content as well.
But yes, the really deep delta chains are most certainly going to
contain those ChangeLog files.
> Besides that these files grow quite large and become some of the
> largest files in the tree, and at least one of them is changed
> for every commit. This leads again to many versions of fairly
> large files.
>
> If this guess is right, this implies that most of the size gains
> from longer chains comes from having less copies of the ChangeLog*
> files. From a performance point of view, it is rather favourable
> since the differences are simple. This would also explain why
> the window parameter has little effect.
Well, actually the window parameter does have big effects. For instance
the default of 10 is completely inadequate for the gcc repo, since
changing the window size from 10 to 100 made the corresponding pack
shrink from 2.1GB down to 400MB, with the same max delta depth.
Nicolas
^ permalink raw reply
* Re: Adding Git to Better SCM Initiative : Comparison
From: Johannes Schindelin @ 2007-12-10 15:23 UTC (permalink / raw)
To: Florian Weimer; +Cc: git
In-Reply-To: <87ve76mwos.fsf@mid.deneb.enyo.de>
Hi,
On Mon, 10 Dec 2007, Florian Weimer wrote:
> * Jakub Narebski:
>
> > + <s id="git">
> > + Yes (or no depending on interpretation). Git
>
> This should be "No." (same for copies below).
Nice. I have no idea what you are talking about, as you only quoted the
answer, but not the question. (Same for the other quoted text.)
Thanks,
Dscho
^ permalink raw reply
* Performance problem, long run of identical hashes
From: Jon Smirl @ 2007-12-10 15:07 UTC (permalink / raw)
To: Git Mailing List
Running oprofile during my gcc repack shows this loop as the hottest
place in the code by far. I added some debug printfs which show that I
have a 100,000+ run of identical hash entries. Processing the 100,000
entries also causes RAM consumption to explode.
create_delta()
for (entry = index->hash[i]; entry < index->hash[i+1]; entry++) {
const unsigned char *ref = entry->ptr;
const unsigned char *src = data;
unsigned int ref_size = ref_top - ref;
if (entry->val != val)
continue;
if (ref_size > top - src)
ref_size = top - src;
if (ref_size <= msize)
break;
while (ref_size-- && *src++ == *ref)
ref++;
if (msize < ref - entry->ptr) {
/* this is our best match so far */
msize = ref - entry->ptr;
moff = entry->ptr - ref_data;
if (msize >= 4096) /* good enough */
break;
}
}
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* git help -t <topic>: list the help of the commands in a given topic
From: Santi Béjar @ 2007-12-10 15:03 UTC (permalink / raw)
To: Git Mailing List; +Cc: Santi Béjar
With 'git help -t' lists the available topics.
Show a hint to get a longer list when listing the common commands.
Signed-off-by: Santi Béjar <sbejar@gmail.com>
---
To apply on top of cc/help
Documentation/git-help.txt | 41 +++++++++++++++++++++++++++++-
command-list.txt | 12 +++++++++
generate-cmdlist.sh | 37 ++++++++++++++++++++++-----
help.c | 59 +++++++++++++++++++++++++++++++++++++------
4 files changed, 132 insertions(+), 17 deletions(-)
diff --git a/Documentation/git-help.txt b/Documentation/git-help.txt
index ac9e15d..bb010f0 100644
--- a/Documentation/git-help.txt
+++ b/Documentation/git-help.txt
@@ -7,7 +7,7 @@ git-help - display help information about git
SYNOPSIS
--------
-'git help' [-a|--all|-i|--info|-w|--web] [COMMAND]
+'git help' [-a|--all|-i|--info|-w|--web|-t [topic]] [COMMAND]
DESCRIPTION
-----------
@@ -16,6 +16,9 @@ With no options and no COMMAND given, the synopsis of the 'git'
command and a list of the most commonly used git commands are printed
on the standard output.
+If the option '-t <topic>' is given, then all the commands on a given
+topic are printed, and without a <topic> to get a list of topics.
+
If the option '--all' or '-a' is given, then all available commands are
printed on the standard output.
@@ -54,6 +57,42 @@ is available in PATH.
Note that the script tries, as much as possible, to display the HTML
page in a new tab on an already opened browser.
+-t <topic>::
+ Prints all the commands on a given topic, or all the topics.
+
+TOPICS
+------
+
+common::
+ The most commonly used commands.
+
+main::
+ The main commands.
+
+interrogators::
+ The interrogators commands.
+
+manipulators::
+ The manipulators commands.
+
+synching::
+ The commands to synchronize repositories.
+
+foreignscm::
+ The commands dealing with foreign SCM.
+
+plumbinginterrogators::
+ The low-level interrogators commands.
+
+plumbingmanipulators::
+ The low-level manipulators commands.
+
+purehelpers::
+ The helpers commands.
+
+synchelpers::
+ The helpers commands to synchronize repositories.
+
Author
------
Written by Junio C Hamano <gitster@pobox.com> and the git-list
diff --git a/command-list.txt b/command-list.txt
index 28342da..cbfb3d2 100644
--- a/command-list.txt
+++ b/command-list.txt
@@ -128,3 +128,15 @@ git-verify-pack plumbinginterrogators
git-verify-tag ancillaryinterrogators
git-whatchanged ancillaryinterrogators
git-write-tree plumbingmanipulators
+# List of known git topics.
+# topic name category [common]
+topic-common mainporcelain common
+topic-main mainporcelain
+topic-interrogators ancillaryinterrogators
+topic-manipulators ancillarymanipulators
+topic-synching synchingrepositories
+topic-foreignscm foreignscminterface
+topic-plumbinginterrogators plumbinginterrogators
+topic-plumbingmanipulators plumbingmanipulators
+topic-purehelpers purehelpers
+topic-synchelpers synchelpers
diff --git a/generate-cmdlist.sh b/generate-cmdlist.sh
index a2913c2..9371e9d 100755
--- a/generate-cmdlist.sh
+++ b/generate-cmdlist.sh
@@ -1,24 +1,47 @@
#!/bin/sh
echo "/* Automatically generated by $0 */
+#define COMMON (1<<1)
+
struct cmdname_help
{
- char name[16];
+ char name[23];
char help[80];
+ char category[22];
+ int option;
};
-static struct cmdname_help common_cmds[] = {"
+static struct cmdname_help cmd_list[] = {"
-sed -n -e 's/^git-\([^ ]*\)[ ].* common.*/\1/p' command-list.txt |
-sort |
-while read cmd
+sed -n -e 's/^git-\([^ ]*\)\(.*\)$/\1\2/p' command-list.txt |
+grep -v deprecated | sort |
+while read cmd topic flag
do
+ flag=$(echo $flag | tr '[a-z]' '[A-Z]')
+ [ -z "$flag" ] && flag="0"
sed -n '
- /NAME/,/git-'"$cmd"'/H
+ /^NAME$/,/git-'"$cmd"'/H
${
x
- s/.*git-'"$cmd"' - \(.*\)/ {"'"$cmd"'", "\1"},/
+ s/.*git-'"$cmd"' - \(.*\)/ {"'"$cmd"'", "\1",/
p
}' "Documentation/git-$cmd.txt"
+ echo "\"$topic\", $flag },"
+done
+echo "};"
+
+echo "static struct cmdname_help topic_list[] = {"
+sed -n -e 's/^topic-\([^ ]*\)\(.*\)$/\1\2/p' command-list.txt |
+while read topic category flag
+do
+ flag=$(echo $flag | tr '[a-z]' '[A-Z]')
+ [ -z "$flag" ] && flag="0"
+ sed -n '
+ /^'$topic'::$/{
+ n
+ s/^[ ]*\(.*\)./ {"'"$topic"'", "\1",/
+ p
+ }' "Documentation/git-help.txt"
+ echo "\"$category\", $flag },"
done
echo "};"
diff --git a/help.c b/help.c
index c96b167..4249d2a 100644
--- a/help.c
+++ b/help.c
@@ -222,20 +222,54 @@ static void list_commands(void)
}
}
+void list_cmds_help(const char *topic)
+{
+ int i, longest = 0, option = 0;
+ const char *category = topic;
+
+ for (i = 0; i < ARRAY_SIZE(topic_list); i++) {
+ if (!strcmp(topic_list[i].name, topic)) {
+ category = topic_list[i].category;
+ option = topic_list[i].option;
+ printf("%s:\n",topic_list[i].help);
+ }
+ }
+
+ for (i = 0; i < ARRAY_SIZE(cmd_list); i++) {
+ if (strcmp(cmd_list[i].category, category)) continue;
+ if (longest < strlen(cmd_list[i].name))
+ longest = strlen(cmd_list[i].name);
+ }
+
+ for (i = 0; i < ARRAY_SIZE(cmd_list); i++) {
+ if (strcmp(cmd_list[i].category, category)) continue;
+ if ((option == 0) || (cmd_list[i].option & option)){
+ printf(" %s ", cmd_list[i].name);
+ mput_char(' ', longest - strlen(cmd_list[i].name));
+ puts(cmd_list[i].help);
+ }
+ }
+}
+
void list_common_cmds_help(void)
{
- int i, longest = 0;
+ list_cmds_help("common");
+ puts("(use 'git help -t main' to get a longer list)");
+}
- for (i = 0; i < ARRAY_SIZE(common_cmds); i++) {
- if (longest < strlen(common_cmds[i].name))
- longest = strlen(common_cmds[i].name);
+void list_topics_help()
+{
+ printf("The topics:\n");
+ int i, longest = 0;
+ for (i = 0; i < ARRAY_SIZE(topic_list); i++) {
+ if (longest < strlen(topic_list[i].name))
+ longest = strlen(topic_list[i].name);
}
- puts("The most commonly used git commands are:");
- for (i = 0; i < ARRAY_SIZE(common_cmds); i++) {
- printf(" %s ", common_cmds[i].name);
- mput_char(' ', longest - strlen(common_cmds[i].name));
- puts(common_cmds[i].help);
+ for (i = 0; i < ARRAY_SIZE(topic_list); i++) {
+ printf(" %s ", topic_list[i].name);
+ mput_char(' ', longest - strlen(topic_list[i].name));
+ puts(topic_list[i].help);
}
}
@@ -331,6 +365,13 @@ int cmd_help(int argc, const char **argv, const char *prefix)
show_info_page(argc > 2 ? argv[2] : NULL);
}
+ else if (!strcmp(help_cmd, "-t")) {
+ const char *topic = NULL;
+ topic = argc > 2 ? argv[2] : NULL;
+ if (!topic) list_topics_help();
+ else list_cmds_help(topic);
+ }
+
else
show_man_page(help_cmd);
--
1.5.3.7.2094.gff6c
^ permalink raw reply related
* Re: Building git-1.5.3.7 on HP-UX 11.00
From: H.Merijn Brand @ 2007-12-10 14:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Andreas Ericsson, git, Sam Vilain
In-Reply-To: <7vve7e49or.fsf@gitster.siamese.dyndns.org>
On Tue, 04 Dec 2007 10:05:40 -0800, Junio C Hamano <gitster@pobox.com> wrote:
> "H.Merijn Brand" <h.m.brand@xs4all.nl> writes:
>
> > On Tue, 4 Dec 2007 15:39:47 +0000 (GMT), Johannes Schindelin
> > ...
> > I found it! unset returns false
> > ...
> > I must leave now.
>
> Thanks, you two.
>
> I do not see "unset VAR... &&" outside t0001 test, but there are
> instances of "unset VAR... &&" in git-submodule implementations as well.
>
> In short, not too many places to fix.
I took the snapshot from 10-12-2007 and applied the patch below
Summary of the changes:
1 Added a section for HP-UX in the Makefile. Note that this will
cover most of HP-UX, but might need several changes for both
newer HP-UX versions and 64bit environments. Will come to that
once I've got it all running
2 HP-UX does not have <sys/select.h>. I mentioned this before
3 I am willing to believe that HP_UX' vsnprintf () is broken, or
at least does not conform to the expectations in the GNU world,
but chickening out like the way strbuf_addf () does is maybe a
bit too rude, so I forced a minimum of 64bytes available. That
fixes a lot!
but it still breaks t4013 :(
4 'tr' doesn't like '\0', but wants '\000' instead.
5 'tr' cannot deal with character classes
6 I don't know how to attack another HP specific problem: HP has
a system command called 'patch' and it is *very* incompatible
with GNU patch. Very. On all my systems I have GNU patch as
'npatch', but I also know of people that have it as 'gpatch'.
In whatever case, HP's patch will fail, so you'd have to ask
if the poor user does have a GNU patch lying around. In t4109
I changed the three calls to patch to calls to npatch, but did
not include this in the patch below. Same for the single call
in t4110.
7 What do you expect for LOCALE's? below is the first failure for
locale testing, but there are more, like
*** t4201-shortlog.sh ***
t4201-shortlog.sh[22]: Invalid multibyte character.
and somewhere inside t5100-mailinfo.sh:
fatal: cannot convert from iso-2022-jp to utf-8
After working my way down, I stopped after hitting this:
+ git-index-pack -o tmp.idx test-2-7f8ead892057e78576c0329a70cc83afb113f117.pack
fatal: serious inflate inconsistency
inside t5300-pack-object.sh
# make configure
:
# env CC=gcc configure --prefix=/pro/local --disable-nls --without-iconv \
--with-perl=/pro/bin/perl
:
# make
:
# make test
:
:
*** t3900-i18n-commit.sh ***
* ok 1: setup
* ok 2: no encoding header for base case
* ok 3: ISO-8859-1 setup
* ok 4: EUCJP setup
* ok 5: ISO-2022-JP setup
* ok 6: check encoding header for ISO-8859-1
* ok 7: check encoding header for EUCJP
* ok 8: check encoding header for ISO-2022-JP
* ok 9: config to remove customization
* FAIL 10: ISO-8859-1 should be shown in UTF-8 now
compare_with ISO-8859-1 ../t3900/1-UTF-8.txt
* FAIL 11: EUCJP should be shown in UTF-8 now
compare_with EUCJP ../t3900/2-UTF-8.txt
* FAIL 12: ISO-2022-JP should be shown in UTF-8 now
compare_with ISO-2022-JP ../t3900/2-UTF-8.txt
* ok 13: config to add customization
* ok 14: ISO-8859-1 should be shown in itself now
* ok 15: EUCJP should be shown in itself now
* ok 16: ISO-2022-JP should be shown in itself now
* ok 17: config to tweak customization
* FAIL 18: ISO-8859-1 should be shown in UTF-8 now
compare_with ISO-8859-1 ../t3900/1-UTF-8.txt
* FAIL 19: EUCJP should be shown in UTF-8 now
compare_with EUCJP ../t3900/2-UTF-8.txt
* FAIL 20: ISO-2022-JP should be shown in UTF-8 now
compare_with ISO-2022-JP ../t3900/2-UTF-8.txt
* ok 21: EUCJP should be shown in EUCJP now
* FAIL 22: ISO-2022-JP should be shown in EUCJP now
compare_with ISO-2022-JP ../t3900/EUCJP.txt
* FAIL 23: EUCJP should be shown in ISO-2022-JP now
compare_with EUCJP ../t3900/ISO-2022-JP.txt
* ok 24: ISO-2022-JP should be shown in ISO-2022-JP now
* ok 25: No conversion with ISO-8859-1
* ok 26: No conversion with EUCJP
* ok 27: No conversion with ISO-2022-JP
* failed 8 among 27 test(s)
make[1]: *** [t3900-i18n-commit.sh] Error 1
# locale -a
C
POSIX
C.iso88591
C.utf8
univ.utf8
nl_NL.iso88591
nl_NL.roman8
en_GB.iso88591
en_GB.roman8
en_US.iso88591
en_US.roman8
C.iso885915
nl_NL.iso885915@euro
en_GB.iso885915@euro
--8<--- git-hpux.diff
diff -pur git-2007-12-10_01/Makefile git-2007-12-10/Makefile
--- git-2007-12-10_01/Makefile 2007-12-09 10:23:48 +0100
+++ git-2007-12-10/Makefile 2007-12-10 13:41:39 +0100
@@ -398,6 +398,18 @@ EXTLIBS =
# because maintaining the nesting to match is a pain. If
# we had "elif" things would have been much nicer...
+ifeq ($(uname_S),HP-UX)
+ # HP-UX
+ BASIC_LDFLAGS += -L/usr/local/ssl/lib -L/usr/local/lib
+ #EXTLIBS += -lc_r -lgcc
+ NO_HSTRERROR = YesPlease
+ NO_ICONV = YesPlease
+ NO_INET_NTOP = YesPlease
+ NO_INET_PTON = YesPlease
+ NO_UNSETENV = YesPlease
+ NO_STRTOULL = YesPlease
+ NO_STRTOUMAX = YesPlease
+endif
ifeq ($(uname_S),Linux)
NO_STRLCPY = YesPlease
endif
diff -pur git-2007-12-10_01/git-compat-util.h git-2007-12-10/git-compat-util.h
--- git-2007-12-10_01/git-compat-util.h 2007-12-09 10:23:48 +0100
+++ git-2007-12-10/git-compat-util.h 2007-12-10 14:25:26 +0100
@@ -68,7 +68,9 @@
#include <sys/poll.h>
#include <sys/socket.h>
#include <sys/ioctl.h>
+#ifndef _HPUX_SOURCE
#include <sys/select.h>
+#endif
#include <assert.h>
#include <regex.h>
#include <netinet/in.h>
diff -pur git-2007-12-10_01/strbuf.c git-2007-12-10/strbuf.c
--- git-2007-12-10_01/strbuf.c 2007-12-09 10:23:48 +0100
+++ git-2007-12-10/strbuf.c 2007-12-10 15:19:46 +0100
@@ -12,7 +12,7 @@ void strbuf_init(struct strbuf *sb, size
sb->alloc = sb->len = 0;
sb->buf = strbuf_slopbuf;
if (hint)
- strbuf_grow(sb, hint);
+ strbuf_grow(sb, hint);
}
void strbuf_release(struct strbuf *sb)
@@ -118,7 +118,7 @@ void strbuf_addf(struct strbuf *sb, cons
int len;
va_list ap;
- if (!strbuf_avail(sb))
+ if (strbuf_avail(sb) < 64)
strbuf_grow(sb, 64);
va_start(ap, fmt);
len = vsnprintf(sb->buf + sb->len, sb->alloc - sb->len, fmt, ap);
diff -pur git-2007-12-10_01/t/t0020-crlf.sh git-2007-12-10/t/t0020-crlf.sh
--- git-2007-12-10_01/t/t0020-crlf.sh 2007-12-09 10:23:48 +0100
+++ git-2007-12-10/t/t0020-crlf.sh 2007-12-10 14:25:58 +0100
@@ -5,7 +5,7 @@ test_description='CRLF conversion'
. ./test-lib.sh
q_to_nul () {
- tr Q '\0'
+ tr Q '\000'
}
append_cr () {
diff -pur git-2007-12-10_01/t/t1300-repo-config.sh git-2007-12-10/t/t1300-repo-config.sh
--- git-2007-12-10_01/t/t1300-repo-config.sh 2007-12-09 10:23:48 +0100
+++ git-2007-12-10/t/t1300-repo-config.sh 2007-12-10 09:49:48 +0100
@@ -591,12 +591,12 @@ Qsection.sub=section.val4
Qsection.sub=section.val5Q
EOF
-git config --null --list | tr '[\000]' 'Q' > result
+git config --null --list | tr '\000' 'Q' > result
echo >>result
test_expect_success '--null --list' 'cmp result expect'
-git config --null --get-regexp 'val[0-9]' | tr '[\000]' 'Q' > result
+git config --null --get-regexp 'val[0-9]' | tr '\000' 'Q' > result
echo >>result
test_expect_success '--null --get-regexp' 'cmp result expect'
-->8--- git-hpux.diff
Can I put the ball back in your court now?
--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using & porting perl 5.6.2, 5.8.x, 5.10.x on HP-UX 10.20, 11.00, 11.11,
& 11.23, SuSE 10.1 & 10.2, AIX 5.2, and Cygwin. http://qa.perl.org
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org
http://www.goldmark.org/jeff/stupid-disclaimers/
^ permalink raw reply
* Re: Adding Git to Better SCM Initiative : Comparison
From: Florian Weimer @ 2007-12-10 14:49 UTC (permalink / raw)
To: git
In-Reply-To: <200712101357.49325.jnareb@gmail.com>
* Jakub Narebski:
> + <s id="git">
> + Yes (or no depending on interpretation). Git
This should be "No." (same for copies below).
> + <s id="git">
> + Partial (?). It is possible to lock down repository
> + (access to branches and tags) using hooks.
> + </s>
I doubt this works reliably. You still can access data once you've got
its SHA1 hash, for instance.
> + <s id="git">
> + Yes. Changesets are supported.<br />
> + Actually Git is snapshot based which means Git records
> + the full state in every commit. This means that any two
> + commits can be compared directly very quickly, although the
> + repository is typically browsed as a series of changesets.
> + </s>
I don't think this explanation is necessary. What does Subversion say?
> + <s id="git">
> + Yes. (git blame, git gui blame).
> + It can also detect the origin of copied and moved source
> + lines, and can ignore whitespace changes.
> + </s>
A simple "Yes." should suffice.
> @@ -636,6 +677,10 @@ <title>Tracking Uncommited Changes</title>
> Yes, using "darcs whatsnew".
> </s>
> <s id="aegis">Yes. Using aediff</s>
> + <s id="git">
> + Yes, of course. Using git diff.
> + Note that git uses staging area for commits (index).
> + </s>
Simply "Yes.". "git diff" is wrong, it's actually "git diff HEAD".
> @@ -681,6 +726,11 @@ <title>Per-File Commit Messages</title>
> <s id="darcs">
> No.
> </s>
> + <s id="git">
> + No. The message applies to the commit as a whole.
> + But you can tag (with description) given contents
> + of a file (blob).
> + </s>
Have we got any real tool support for this? This should be "No.".
> @@ -1006,6 +1075,13 @@ <title>Command Set</title>
> but since the model is different most commands are
> unique.
> </s>
> + <s id="git">
> + Tries to follow CVS conventions, but deviates where there
> + is a different design (following BitKeeper for DVCS).
I don't think this is true. Is there any command that closely matches
what CVS does?
> @@ -1203,6 +1286,11 @@ <title>Portability</title>
> Very good. Supports many UNIXes, Mac OS X, and Windows,
> and is written in a portable language.
> </s>
> + <s id="git">
> + Good to very good. Portable across all POSIX systems.
> + There exists Win32 binary using MinGW (msysGit),
> + or you can use binary provided by Cygwin.
> + </s>
Isn't Windows support still a bit lacking in terms of performance?
^ permalink raw reply
* Re: There is not summary of kernel 2.4.x repo.
From: J.C. Pizarro @ 2007-12-10 14:35 UTC (permalink / raw)
To: Andreas Ericsson, Linus Torvalds, git
In-Reply-To: <475D39A3.1040401@op5.se>
I'm sorry, thanks :)
^ permalink raw reply
* Re: Adding Git to Better SCM Initiative : Comparison
From: David Kastrup @ 2007-12-10 14:33 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Shlomi Fish, git
In-Reply-To: <200712101357.49325.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Git was created by Linus Torvalds in response to the change of BitKeeper
> licensing, as a tool to manage Linux kernel sources. It is based on
> three years of Linus experience with BitKeeper, and inspired by
of Linus' experience
> Monotone architecture. It was designed for Linux kernel, and is used
Monotone's architecture.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* [PATCH] Fix indentation of the -p, --patch option in git-add(1)
From: Eyvind Bernhardsen @ 2007-12-10 13:40 UTC (permalink / raw)
To: git, gitster; +Cc: Eyvind Bernhardsen
Signed-off-by: Eyvind Bernhardsen <eyvind-git@orakel.ntnu.no>
---
Documentation/git-add.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index bf94cd4..721ca99 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -65,7 +65,7 @@ OPTIONS
operation to a subset of the working tree. See ``Interactive
mode'' for details.
--p, \--patch:
+-p, \--patch::
Similar to Interactive mode but the initial command loop is
bypassed and the 'patch' subcommand is invoked using each of
the specified filepatterns before exiting.
--
1.5.3.7.995.gdf9262
^ permalink raw reply related
* Re: Better value for chunk_size when threaded
From: Nicolas Pitre @ 2007-12-10 13:46 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Jon Smirl, Git Mailing List, Junio C Hamano
In-Reply-To: <475D1473.5090809@op5.se>
On Mon, 10 Dec 2007, Andreas Ericsson wrote:
> Nicolas Pitre wrote:
> > If there is one besides futzing with /proc/cpuinfo I'd like to know about
> > it. Bonus points if it is portable.
> >
>
> Here is such a one. I've sent it before, using git-send-email, but that
> one doesn't seem to work too well for all list-members, probably because
> my own laptop appears to be the original SMTP-server and its name can't
> be looked up. Sorry for inlining it here instead of sending it as a mail
> on its own, but I have absolutely no idea how to get git-send-email to
> do ldap authentication and connect to our tls-enabled smtp-server
> without using /usr/bin/sendmail and adding my laptop as originating
> smtp-server.
>
> This patch replaces the one I sent earlier and *should* work on
> everything from Irix and AIX to Linux, Windows and every other
> posixish system. It passes all tests, both with and without
> THREADED_DELTA_SEARCH, and causes our weekly repack of our
> mother-ship repos to run roughly 4 times as fast (4 cores, no
> previous thread config).
>
> Extract with
> sed -n -e /^##SEDMEHERE##/,/##TOHERE##/p -e /^##/d
>
> ##SEDMEHERE##
> > From ddf08303bd7962be385abbd5e964455a90ed6055 Mon Sep 17 00:00:00 2001
> From: Andreas Ericsson <ae@op5.se>
> Date: Thu, 6 Dec 2007 22:09:27 +0100
> Subject: [PATCH] pack-objects: Add runtime detection of number of CPU's
>
> Packing objects can be done in parallell nowadays, but
> it's only done if the config option pack.threads is set
> to a value above 1. Because of that, the code-path used
> is sometimes not the most optimal one.
>
> This patch adds a routine to detect the number of active
> CPU's at runtime, which should provide a better default
> and activate the (hopefully) better codepath more often.
Your patch is whitespace dammaged.
Also please make it into a separate .c file. One day, maybe index-pack
will want to use it as well.
Nicolas
^ permalink raw reply
* Re: Adding Git to Better SCM Initiative : Comparison
From: Jakub Narebski @ 2007-12-10 13:20 UTC (permalink / raw)
To: Eyvind Bernhardsen; +Cc: git
In-Reply-To: <E876AFC0-498C-48B4-8B83-DB44585F76C5@orakel.ntnu.no>
Eyvind Bernhardsen wrote:
> On 10. des. 2007, at 13.57, Jakub Narebski wrote:
>
>> I have noticed that your SCM comparison at "Better SCM Initiative"
>> website
>> http://better-scm.berlios.de/comparison/comparison.html
>> misses one of the Git, version control system which is used to manage
>
> "misses one of the Git"?
Gaaah... I started to write "misses one of the main OSS DSCM", but end
up with "misses Git [...] one of the main open source (distributed)
version control systems"... and forgot to remove "one of the".
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: "remote end hung up unexpectedly"
From: Andreas Ericsson @ 2007-12-10 13:11 UTC (permalink / raw)
To: Clifford Heath; +Cc: git
In-Reply-To: <CE1FB037-26E3-475E-9F9D-AC3874987B9C@gmail.com>
Clifford Heath wrote:
> Be patient with me, it's my first day on git... I like it better than
> svn already,
Welcome to a better world.
> but I need a bit of help.
>
> After cloning a remote repository, I wanted to update (rebase) an existing
> remote branch to get the latest master commits, so I switched to it using
> git checkout, then did a "git merge origin/master" and it updated my local
> copy so it looked reasonable... I have changes to add to this branch, but
> I wanted a proper base, so I did a "git commit" and a "git push". The push
> gave me the above message.
>
> I've checked ssh access (don't have shell) to the other side, my PK is
> set up.
>
> What went wrong? How can I diagnose it further (-v doesn't help)
>
How did you clone it? If you cloned via git:// protocol, you most likely
can't push back there. The git-daemon supports pushing, but does no
authentication.
If you cloned via ssh it's a bit harder to diagnose, since all git knows
is that the ssh-server closed its connection. For security reasons, it
doesn't necessarily tell you why it did that, so it's hard to know what
the real problem is.
> I understand that to add my further changes, I should set up a local branch
> to track this updated remote branch. But I'm assuming that the rebase must
> be done while switched to the remote branch...?
>
Not really. You can do "git rebase --onto origin/master master". However,
since you merged origin/master earlier, a rebase will only tell you that
you're up-to-date.
"git help rebase" might be worth looking into though.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Adding Git to Better SCM Initiative : Comparison
From: Eyvind Bernhardsen @ 2007-12-10 13:09 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Shlomi Fish, git
In-Reply-To: <200712101357.49325.jnareb@gmail.com>
On 10. des. 2007, at 13.57, Jakub Narebski wrote:
> I have noticed that your SCM comparison at "Better SCM Initiative"
> website
> http://better-scm.berlios.de/comparison/comparison.html
> misses one of the Git, version control system which is used to manage
"misses one of the Git"?
--
Eyvind
^ permalink raw reply
* Re: There is not summary of kernel 2.4.x repo.
From: Andreas Ericsson @ 2007-12-10 13:05 UTC (permalink / raw)
To: J.C. Pizarro; +Cc: Linus Torvalds, git
In-Reply-To: <998d0e4a0712100442g40c61093q570aee1c063f1302@mail.gmail.com>
J.C. Pizarro wrote:
> It exists http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=summary
> but http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.4.git;a=summary
> is empty. :)
That's what you get for hand-hacking URL's when there's a list to choose
from.
http://git.kernel.org/?p=linux/kernel/git/wtarreau/linux-2.4.git;a=summary
works though.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Adding Git to Better SCM Initiative : Comparison
From: Jakub Narebski @ 2007-12-10 12:57 UTC (permalink / raw)
To: Shlomi Fish; +Cc: git
I have noticed that your SCM comparison at "Better SCM Initiative"
website
http://better-scm.berlios.de/comparison/comparison.html
misses one of the Git, version control system which is used to manage
Linux kernel, and one of the main open source (distributed) version
control systems (among Mercurial, Bazaar-NG, Monotone and Darcs).
Git used to be "stupid content tracker", something to build
user-friendly SCM interface on (e.g. Cogito) but it evolved into fully
fledged SCM since.
Git was created by Linus Torvalds in response to the change of BitKeeper
licensing, as a tool to manage Linux kernel sources. It is based on
three years of Linus experience with BitKeeper, and inspired by
Monotone architecture. It was designed for Linux kernel, and is used
by various projects, including X.Org, various Freedesktop projects,
WINE, OLPC (One Laptop Per Child), Samba.
<blurb src="http://git-scm.org">
Git is a popular version control system designed to handle very large
projects with speed and efficiency; it is used mainly for various open
source projects, most notably the Linux kernel.
Git falls in the category of distributed source code management tools,
similar to e.g. GNU Arch or Monotone (or BitKeeper in the proprietary
world). Every Git working directory is a full-fledged repository with
full revision tracking capabilities, not dependent on network access or
a central server.
Git is an Open Source project covered by the GNU General Public License v2.
It was originally written by Linus Torvalds and is currently maintained
by Junio C Hamano.
</blurb>
Below there is (slightly doctored) patch to the sources for the site.
BTW. when asking about updating GIT info for comparison, please CC
git mailing list, git@vger.kernel.org
Index: src/comparison/scm-comparison.xml
===================================================================
--- src/comparison/scm-comparison.xml (revision 290)
+++ src/comparison/scm-comparison.xml (working copy)
@@ -38,6 +38,9 @@ <implementations>
<impl id="darcs">
<name>Darcs</name>
</impl>
+ <impl id="git">
+ <name>Git</name>
+ </impl>
<impl id="mercurial">
<name>Mercurial</name>
</impl>
@@ -106,6 +109,7 @@ <title>Atomic Commits</title>
<s id="svk">Commits are atomic.</s>
<s id="aegis">Commits are atomic.</s>
<s id="bitkeeper">Yes (but need to verify)</s>
+ <s id="git">Yes.</s>
<s id="mercurial">Yes.</s>
<s id="monotone">Yes.</s>
<s id="opencm">Yes. Commits are atomic.</s>
@@ -142,6 +146,13 @@ <title>Files and Directories Moves or Renames</title>
<s id="darcs">Yes. Renames are supported.</s>
<s id="bitkeeper">Yes. Renames are supported.</s>
<s id="aegis">Yes. Renames are supported.</s>
+ <s id="git">
+ Yes (or no depending on interpretation). Git detects
+ renames based on content regardless of whether the
+ committer indicated the fact.
+ You can follow history of file across renames using
+ 'git log -M --follow'.
+ </s>
<s id="mercurial">Yes. Renames are supported.</s>
<s id="monotone">Yes. Renames are supported.</s>
<s id="opencm">Yes. Renames are supported</s>
@@ -214,6 +225,13 @@ <title>File and Directories Copies</title>
Yes. Copies are supported.
</s>
<s id="aegis">No. Copies are not supported.</s>
+ <s id="git">
+ Yes (or no depending on interpretation). Git detects
+ copies (when requested) based on content regardless
+ of whether the committer indicated the fact.
+ You can follow history of file across copies using
+ 'git log -C -C --follow'.
+ </s>
<s id="mercurial">Yes. Copies are supported</s>
<s id="monotone">Yes. Copies are supported</s>
<s id="opencm">No. Copies are not supported.</s>
@@ -267,6 +285,7 @@ <title>Remote Repository Replication</title>
<s id="darcs">Yes.</s>
<s id="bitkeeper">Yes.</s>
<s id="aegis">Yes.</s>
+ <s id="git">Yes.</s>
<s id="mercurial">Yes.</s>
<s id="monotone">Yes.</s>
<s id="opencm">No.</s>
@@ -313,6 +332,7 @@ <title>Propagating Changes to Parent Repositories</title>
<s id="darcs">Yes.</s>
<s id="bitkeeper">Yes.</s>
<s id="aegis">Yes.</s>
+ <s id="git">Yes.</s>
<s id="mercurial">Yes.</s>
<s id="monotone">Yes.</s>
<s id="opencm">No.</s>
@@ -373,6 +393,10 @@ <title>Repository Permissions</title>
<s id="svk">
Same as subversion.
</s>
+ <s id="git">
+ Partial (?). It is possible to lock down repository
+ (access to branches and tags) using hooks.
+ </s>
<s id="mercurial">
Yes. It is possible to lock down repositories,
subdirectories, or files using hooks.
@@ -455,6 +479,13 @@ <title>Changesets' Support</title>
<s id="darcs">
Yes. Changesets are supported.
</s>
+ <s id="git">
+ Yes. Changesets are supported.<br />
+ Actually Git is snapshot based which means Git records
+ the full state in every commit. This means that any two
+ commits can be compared directly very quickly, although the
+ repository is typically browsed as a series of changesets.
+ </s>
<s id="mercurial">
Yes. Changesets are supported.
</s>
@@ -509,6 +540,11 @@ <title>Tracking Line-wise File History</title>
<s id="arch">Not in the command line client, but ViewARCH,
a web-interface for Arch, has it.</s>
<s id="darcs">Yes. (darcs annotate)</s>
+ <s id="git">
+ Yes. (git blame, git gui blame).
+ It can also detect the origin of copied and moved source
+ lines, and can ignore whitespace changes.
+ </s>
<s id="mercurial">Yes. (hg annotate)</s>
<s id="monotone">Yes, as of version 0.19.</s>
<s id="aegis">Yes. aeannotate</s>
@@ -570,6 +606,11 @@ <title>Ability to Work only on One Directory...</title>
whole.
</s>
<s id="aegis">No. All changes are made repository-wide.</s>
+ <s id="git">
+ No. All changes are made repository-wide. However
+ it is possible to commit only selected changes in the
+ working tree rather than everything. You can also
+ use submodules (subproject) support.</s>
<s id="mercurial">
It is possible to commit changes only in a subset of the
tree. There are plans for partial checkouts.
@@ -636,6 +677,10 @@ <title>Tracking Uncommited Changes</title>
Yes, using "darcs whatsnew".
</s>
<s id="aegis">Yes. Using aediff</s>
+ <s id="git">
+ Yes, of course. Using git diff.
+ Note that git uses staging area for commits (index).
+ </s>
<s id="mercurial">Yes. Using hg diff.</s>
<s id="monotone">Yes. In a similar fashion to CVS.</s>
<s id="opencm">Yes. Using cm diff</s>
@@ -681,6 +726,11 @@ <title>Per-File Commit Messages</title>
<s id="darcs">
No.
</s>
+ <s id="git">
+ No. The message applies to the commit as a whole.
+ But you can tag (with description) given contents
+ of a file (blob).
+ </s>
<s id="mercurial">
No.
</s>
@@ -782,6 +832,15 @@ <title>Documentation</title>
and the client contains a help tool that offers
an integrated help system.
</s>
+ <s id="git">
+ Good. There's Git User's Manual, manpages, some
+ technical documentation and some howtos. All
+ documentation is also available
+ <a href="http://www.kernel.org/pub/software/scm/git/docs">online</a>
+ in HTML format; there is additional information (including
+ beginnings of FAQ) on a
+ <a href="http://git-scm.org/gitwiki">git wiki</a>.
+ </s>
<s id="mercurial">
Very good. There's an overview and tutorial on the
web site, and integrated help for every command.
@@ -894,6 +953,16 @@ <title>Ease of Deployment</title>
to install the subversion perl bindings and a few modules
from CPAN.
</s>
+ <s id="git">
+ Very good. Install from RPM or deb on Linux; use
+ msysGit or Cygwin install on Windows. Git requires
+ zlib; also POSIX shell and utilities and Perl for some
+ commands.
+ Installing from sources is easy: Makefile has ready
+ configuration for many OS, you can also use autoconf
+ to generate Makefile configuration. Compiling docs
+ requires asciidoc toolchain, but you can use prebuild.
+ </s>
<s id="mercurial">
Excellent. Binary packages are available for all
popular platforms. Building from source requires
@@ -1006,6 +1075,13 @@ <title>Command Set</title>
but since the model is different most commands are
unique.
</s>
+ <s id="git">
+ Tries to follow CVS conventions, but deviates where there
+ is a different design (following BitKeeper for DVCS).
+ Large command set (~140) is divided into plumbing commands
+ (low lewel, to be used in scripts) and porcelain (high level).
+ It is easy to add new commands as scripts, or as git aliases.
+ </s>
<s id="mercurial">
Tries to follow CVS conventions, but deviates where there
is a different design.
@@ -1106,6 +1182,13 @@ <title>Networking Support</title>
There exists some HTTP-functionality, but it is quite
limited.
</s>
+ <s id="git">
+ Excellent. Uses HTTPS (with WebDAV) or ssh for push
+ (to publish changes to server) and HTTP, FTP, ssh or custom
+ "git" protocol for fetch (read from server). There is also
+ git-bundle for offline transport, and tools to exchange
+ (create and apply) patches via email.
+ </s>
<s id="mercurial">
Excellent. Uses HTTP or ssh. Remote access also
works safely without locks over read-only network
@@ -1203,6 +1286,11 @@ <title>Portability</title>
Very good. Supports many UNIXes, Mac OS X, and Windows,
and is written in a portable language.
</s>
+ <s id="git">
+ Good to very good. Portable across all POSIX systems.
+ There exists Win32 binary using MinGW (msysGit),
+ or you can use binary provided by Cygwin.
+ </s>
<s id="mercurial">
Excellent. Runs on all platforms supported by
Python. Repositories are portable across CPU
@@ -1300,6 +1388,10 @@ <title>Web Interface</title>
is included in the distribution.
</s>
<s id="aegis">Yes.</s>
+ <s id="git">
+ Yes, gitweb is included in git since version 1.4.0.
+ Other web interfaces exists: cgit, wit, git-php
+ </s>
<s id="mercurial">Yes. The web interface is a bundled component.</s>
<s id="monotone">No.</s>
<s id="opencm">No.</s>
@@ -1373,6 +1464,12 @@ <title>Availability of Graphical User-Interfaces.</title>
<s id="aegis">
There is tkaegis.
</s>
+ <s id="git">
+ There is history viewer 'gitk' and commit tool 'git-gui';
+ both in Tcl/Tk. There also exists a number of third-party
+ GUIs, including: qgit (Qt), GitView (GTK+), Giggle (GTK+),
+ tig (ncurses).
+ </s>
<s id="mercurial">
History viewing available with hgit extension;
check-in extension (hgct) makes committing easier.
@@ -1453,6 +1550,7 @@ <title>License</title>
GNU GPL (open-source)
</s>
<s id="svk">Perl License. (open source)</s>
+ <s id="git">GNU GPL v2 (open source)</s>
<s id="mercurial">GNU GPL (open source)</s>
<s id="monotone">GNU GPL (open source)</s>
<s id="opencm">
^ permalink raw reply
* [PATCH] Better errors when trying to merge a submodule
From: Finn Arne Gangstad @ 2007-12-10 12:44 UTC (permalink / raw)
To: git, gitster
Instead of dying with weird errors when trying to merge submodules from a
supermodule, emit errors that show what the problem is.
Signed-off-by: Finn Arne Gangstad <finnag@pvv.org>
---
If you try to merge a submodule from a supermodule, you get some very
strange error messages. With this patch you get a nice clean error
message indicating that this isn't supported instead.
git-merge-one-file.sh | 7 +++++++
merge-recursive.c | 2 ++
2 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/git-merge-one-file.sh b/git-merge-one-file.sh
index 1e7727d..7aee342 100755
--- a/git-merge-one-file.sh
+++ b/git-merge-one-file.sh
@@ -82,6 +82,13 @@ case "${1:-.}${2:-.}${3:-.}" in
;;
esac
+ case ",$6,$7," in
+ *,160000,*)
+ echo "ERROR: $4: Not merging submodule."
+ exit 1
+ ;;
+ esac
+
src2=`git-unpack-file $3`
case "$1" in
'')
diff --git a/merge-recursive.c b/merge-recursive.c
index 9a1e2f2..ecae8ea 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -1046,6 +1046,8 @@ static struct merge_file_info merge_file(struct diff_filespec *o,
free(result_buf.ptr);
result.clean = (merge_status == 0);
+ } else if (S_ISGITLINK(a->mode) || S_ISGITLINK(b->mode)) {
+ die("cannot merge submodules!");
} else {
if (!(S_ISLNK(a->mode) || S_ISLNK(b->mode)))
die("cannot merge modes?");
--
1.5.3.7.1149.g591a-dirty
^ permalink raw reply related
* There is not summary of kernel 2.4.x repo.
From: J.C. Pizarro @ 2007-12-10 12:42 UTC (permalink / raw)
To: Linus Torvalds, git
It exists http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=summary
but http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.4.git;a=summary
is empty. :)
^ permalink raw reply
* "remote end hung up unexpectedly"
From: Clifford Heath @ 2007-12-10 11:49 UTC (permalink / raw)
To: git
Be patient with me, it's my first day on git... I like it better than
svn already,
but I need a bit of help.
After cloning a remote repository, I wanted to update (rebase) an
existing
remote branch to get the latest master commits, so I switched to it
using
git checkout, then did a "git merge origin/master" and it updated my
local
copy so it looked reasonable... I have changes to add to this branch,
but
I wanted a proper base, so I did a "git commit" and a "git push". The
push
gave me the above message.
I've checked ssh access (don't have shell) to the other side, my PK
is set up.
What went wrong? How can I diagnose it further (-v doesn't help)
I understand that to add my further changes, I should set up a local
branch
to track this updated remote branch. But I'm assuming that the rebase
must
be done while switched to the remote branch...?
Clifford Heath.
^ permalink raw reply
* Re: git-svn init from Avogadro SVN repo - deleted files showing
From: Peter Baumann @ 2007-12-10 11:40 UTC (permalink / raw)
To: Marcus D. Hanwell; +Cc: Eric Wong, git
In-Reply-To: <20071210104235.GA7521@xp.machine.xx>
On Mon, Dec 10, 2007 at 11:42:35AM +0100, Peter Baumann wrote:
> On Sun, Dec 09, 2007 at 07:24:40PM -0500, Marcus D. Hanwell wrote:
> > Hi,
> >
> > I am quite new to git and git-svn but have been using both for my
> > development work recently. I imported the Avogadro subversion repository
> > (hosted on Sourceforge) using the following commands,
> >
> > git svn init -t tags -b branches -T trunk
> > https://avogadro.svn.sourceforge.net/svnroot/avogadro
> >
> > git svn fetch
> >
> >
> > The files avogadro.pro and README in the trunk/ directory appear in my
> > imported git repository but not in Avogadro subversion trunk. We also had
> > trunk/src/ and all its files/subdirectories appearing in the git checkout
> > but not in subversion trunk. We deleted this using git and git svn which
> > removed it from the git checkouts too after r858.
> >
> > I have been talking to Peter who confirmed this and pointed out that the
> > repo was reorganised several times in the past. Please CC me on replies as
> > I am not on the list. There is a copy of my git repo at
> > http://platinum.cryos.net/avogadro.git/ if you would rather skip the
> > import. Other than that everything has been working great. It would be good
> > to get rid of this bug if possible. Let me know if there is anything else I
> > can do to help.
> >
>
> [ Eric Cc'ed, as the author of git-svn ]
>
> I can confirm that this looks like an import problem.
> (e.g see svn log -v -r33:78 https://avogadro.svn.sourceforge.net/svnroot/avogadro)
>
> I did my analysis on the file /trunk/avogadro.pro, because the error
> happens really early in the history so could just import up to revision 76
> to see what goes wrong. (The file gets never deleted in the import, as it
> should be!)
>
>
>
> trunk/avogadro.pro is added here:
>
> ------------------------------------------------------------------------
> r33 | dcurtis3 | 2006-08-21 07:34:10 +0200 (Mon, 21 Aug 2006) | 3 lines
> Changed paths:
> A /trunk/avogadro.pro
>
> Does a recursive build.
>
>
> Here the refactoring starts (a new directory not tracked by git is added):
> ------------------------------------------------------------------------
> r66 | dcurtis3 | 2007-01-03 06:42:45 +0100 (Wed, 03 Jan 2007) | 3 lines
> Changed paths:
> A /avogadro
>
> Making room for libavogadro.
>
>
> /branches is moved to /avogadro/branches
> ------------------------------------------------------------------------
> r67 | dcurtis3 | 2007-01-03 06:47:11 +0100 (Wed, 03 Jan 2007) | 3 lines
> Changed paths:
> A /avogadro/branches (from /branches:66)
> D /branches
>
> Making room for libavogadro
>
>
>
>
> ERROR HAPPENS HERE:
> ====================
>
> /trunk and /tags are moved, too.
> (/trunk/avogadro.pro becomes /avogadro/trunk/avogadro.pro):
> ------------------------------------------------------------------------
> r68 | dcurtis3 | 2007-01-03 06:47:34 +0100 (Wed, 03 Jan 2007) | 3 lines
> Changed paths:
> A /avogadro/tags (from /tags:66)
> A /avogadro/trunk (from /trunk:66)
> D /tags
> D /trunk
>
> Making room for libavogadro.
>
> The above delete/move of trunk isn't recorded anywhere in the git svn import.
> 'git-svn find-rev r66' doesn't produce any output!
Sorry. I meant r67 and r68 instead of r66.
> And later git-svn thinks that /trunk and all its files are still there, so
> e.g. /trunk/avogadro.pro stays in the repo forever.
>
>
> -Peter
>
> This is just for consistency here and for anyone interested in further
> analyses.
>
> Here is the rest of the import analyses I've done. Look how "interesting" the
> repo is and how many times the files are moved.
>
>
>
>
> /libavogadro is added
> ------------------------------------------------------------------------
> r69 | dcurtis3 | 2007-01-03 06:50:58 +0100 (Wed, 03 Jan 2007) | 3 lines
> Changed paths:
> A /libavogadro
> A /libavogadro/CMakeLists.txt
> A /libavogadro/FindOpenBabel.cmake
> A /libavogadro/src
> A /libavogadro/src/CMakeLists.txt
> A /libavogadro/src/color.cpp
> A /libavogadro/src/color.h
> A /libavogadro/src/engine.h
> A /libavogadro/src/engines
> A /libavogadro/src/engines/CMakeLists.txt
> A /libavogadro/src/engines/ResidueSphereEngine.cpp
> A /libavogadro/src/engines/ResidueSphereEngine.h
> A /libavogadro/src/engines/SphereEngine.cpp
> A /libavogadro/src/engines/SphereEngine.h
> A /libavogadro/src/engines/StickEngine.cpp
> A /libavogadro/src/engines/StickEngine.h
> A /libavogadro/src/engines/WireframeEngine.cpp
> A /libavogadro/src/engines/WireframeEngine.h
> A /libavogadro/src/engines/bsengine.cpp
> A /libavogadro/src/engines/bsengine.h
> A /libavogadro/src/engines/vertexarray.cpp
> A /libavogadro/src/engines/vertexarray.h
> A /libavogadro/src/glwidget.cpp
> A /libavogadro/src/glwidget.h
> A /libavogadro/src/primitives.cpp
> A /libavogadro/src/primitives.h
>
> Added libavogadro.
>
>
> Create /libavogadro/{trunk,branches,tags} and move anything below the
> former /libavogadro into /libavogadro/trunk
> ------------------------------------------------------------------------
> r70 | dcurtis3 | 2007-01-03 06:53:13 +0100 (Wed, 03 Jan 2007) | 3 lines
> Changed paths:
> D /libavogadro/CMakeLists.txt
> D /libavogadro/FindOpenBabel.cmake
> A /libavogadro/branches
> D /libavogadro/src
> A /libavogadro/tags
> A /libavogadro/trunk
> A /libavogadro/trunk/CMakeLists.txt (from /libavogadro/CMakeLists.txt:69)
> A /libavogadro/trunk/FindOpenBabel.cmake (from /libavogadro/FindOpenBabel.cmake:69)
> A /libavogadro/trunk/src (from /libavogadro/src:69)
>
> Putting in trunk / branches / tags.
>
>
> ------------------------------------------------------------------------
> r72 | dcurtis3 | 2007-01-03 08:55:32 +0100 (Wed, 03 Jan 2007) | 3 lines
> Changed paths:
> A /avogadro/trunk/CMakeLists.txt
> A /avogadro/trunk/FindAvogadro.cmake
> A /avogadro/trunk/FindOpenBabel.cmake
> D /avogadro/trunk/src/Engine.h
> D /avogadro/trunk/src/GLWidget.cpp
> D /avogadro/trunk/src/GLWidget.h
> D /avogadro/trunk/src/MainWindow.cpp
> D /avogadro/trunk/src/MainWindow.h
> D /avogadro/trunk/src/Primitives.cpp
> D /avogadro/trunk/src/Primitives.h
> D /avogadro/trunk/src/Renderer.h
> D /avogadro/trunk/src/Tool.cpp
> D /avogadro/trunk/src/Tool.h
> D /avogadro/trunk/src/Views.cpp
> D /avogadro/trunk/src/Views.h
> D /avogadro/trunk/src/color.cpp
> D /avogadro/trunk/src/color.h
> D /avogadro/trunk/src/engines
> M /avogadro/trunk/src/main.cpp
> A /avogadro/trunk/src/mainwindow.cpp (from /avogadro/trunk/src/MainWindow.cpp:70)
> A /avogadro/trunk/src/mainwindow.h (from /avogadro/trunk/src/MainWindow.h:70)
> A /avogadro/trunk/src/tool.cpp (from /avogadro/trunk/src/Tool.cpp:70)
> A /avogadro/trunk/src/tool.h (from /avogadro/trunk/src/Tool.h:70)
> A /avogadro/trunk/untitled01.gpr
>
> Now uses libavogadro. Starting to think we should package this a
> little different.
>
>
>
> Renamed /libavogadro to /avogadro-lib
> ------------------------------------------------------------------------
> r73 | dcurtis3 | 2007-01-03 16:48:02 +0100 (Wed, 03 Jan 2007) | 3 lines
> Changed paths:
> A /avogadro-lib (from /libavogadro:72)
> D /libavogadro
>
> Refactor
>
>
> mv /avogadro/trunk/avogadro.pro /trunk/avogadro/avogadro.pro
> ------------------------------------------------------------------------
> r75 | dcurtis3 | 2007-01-03 20:49:35 +0100 (Wed, 03 Jan 2007) | 2 lines
> Changed paths:
> D /avogadro
> D /avogadro-lib
> A /branches
> A /tags
> A /trunk
> A /trunk/avogadro (from /avogadro/trunk:74)
> A /trunk/libavogadro (from /avogadro-lib/trunk:74)
>
> Moving things around. Conforming to a more KDE-like layout in SVN.
> I'm going nuts. SOrry
^ 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