* Re: [irq/urgent]: created 3786fc7: "irq: make variable static"
From: René Scharfe @ 2008-10-26 16:04 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Santi Béjar, git
In-Reply-To: <20081022075639.GA1284@elte.hu>
Ingo Molnar schrieb:
> The most useful angle would be if git log --format had a way to print
> the reverse name. Then i could do a git-log-line script like:
>
> git log --pretty=format:"%h: %20N %s" $@
>
> where %N prints the reverse name.
>
> While at it: it would be nice if git log had a way to crop string
> output. For example i'd love to use:
>
> git log --pretty=format:"%h: %60s" $@
>
> which would print out at most 60 characters from the first commit line.
>
> That way i can see it properly on an 80 width terminal and can paste it
> into email without linewraps, etc. But --pretty=format does not seem to
> know width restrictions.
You don't need support for format string cropping in git for the latter
example, you can use cut instead:
git log --pretty=format:%h:\ %s $@ | cut -b-70
But I only realized that after I had written the following patch. :)
Would this feature still be useful?
Thanks,
René
---
Documentation/pretty-formats.txt | 5 +++++
pretty.c | 30 ++++++++++++++++++++++++++++--
2 files changed, 33 insertions(+), 2 deletions(-)
diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
index f18d33e..cc76c45 100644
--- a/Documentation/pretty-formats.txt
+++ b/Documentation/pretty-formats.txt
@@ -128,6 +128,11 @@ The placeholders are:
- '%n': newline
- '%x00': print a byte from a hex code
++
+You can also specify a maximum width for each field after the '%', e.g.
+'%60s' will show the first sixty characters of the subject (or less if
+it's shorter).
+
* 'tformat:'
+
The 'tformat:' format works exactly like 'format:', except that it
diff --git a/pretty.c b/pretty.c
index 1e79943..74e8932 100644
--- a/pretty.c
+++ b/pretty.c
@@ -498,8 +498,8 @@ static void format_decoration(struct strbuf *sb, const struct commit *commit)
strbuf_addch(sb, ')');
}
-static size_t format_commit_item(struct strbuf *sb, const char *placeholder,
- void *context)
+static size_t do_format_commit_item(struct strbuf *sb, const char *placeholder,
+ void *context)
{
struct format_commit_context *c = context;
const struct commit *commit = c->commit;
@@ -621,6 +621,32 @@ static size_t format_commit_item(struct strbuf *sb, const char *placeholder,
return 0; /* unknown placeholder */
}
+static size_t format_commit_item(struct strbuf *sb, const char *placeholder,
+ void *context)
+{
+ size_t digits = 0;
+ size_t maxlen = 0;
+ size_t consumed;
+
+ if (isdigit(placeholder[0])) {
+ do {
+ digits++;
+ maxlen *= 10;
+ maxlen += placeholder[0] - '0';
+ placeholder++;
+ } while (isdigit(placeholder[0]));
+ maxlen += sb->len;
+ }
+
+ consumed = do_format_commit_item(sb, placeholder, context);
+ if (!consumed)
+ return 0;
+
+ if (digits && sb->len > maxlen)
+ strbuf_setlen(sb, maxlen);
+ return digits + consumed;
+}
+
void format_commit_message(const struct commit *commit,
const void *format, struct strbuf *sb,
enum date_mode dmode)
--
1.6.0.3.514.g2f91b
^ permalink raw reply related
* Re: From Perforce to Git
From: Brandon @ 2008-10-26 16:08 UTC (permalink / raw)
To: David Symonds; +Cc: git
In-Reply-To: <ee77f5c20810251641l4892ff12n7b30667c6fcc903c@mail.gmail.com>
On Sat, Oct 25, 2008 at 6:41 PM, David Symonds <dsymonds@gmail.com> wrote:
> On Sat, Oct 25, 2008 at 2:18 PM, Brandon <siamesedream01@gmail.com> wrote:
>
>> I'm trying to make a comprehensive comparison of Perforce and Git
>> features. There are two things I currently can't find:
>>
>> 1) "Who's editing what"
>> It's been documented that git can help developers communicate who
>> is editing what at any given time like perforce. (assuming there is a
>> central repositry) Has anyone seen an example of scripts to do this?
>
> That's the primary feature of Perforce that kills its scalability once
> you get past a few hundred developers; it bloats the metadata too
> much. When you're using Git, there's really little point in using it,
> since you don't declare what files you are going to be editing, and
> you can find out other people's changes at merge time at your leisure
> (not just when *you* want to commit).
I think there is an even more fundamental problem with this
feature. Since perforce 'forces' developers the checkout files for
edit, eventually you just ignore these warnings because you don't know
if someone is really checking something out to make a change they are
going to commit, or just need to make a file writable to experiment
with some other feature they're working on etc... This feature would
work much better if it were optional. I don't really care about the
feature per se I would just like to be able to state that Git can
offer everything that perforce can.
I would imagine this would require users pushing their changes to a
branch in the central git repo. Then other users could use git log or
cherry to see what files others are interested in (aka declared they
are going to edit)? Not that this is necessarily a good way to work.
>> 2) Symlinks to checkout partial repository
>> I believe I read symlinks could be used to checkout part of a
>> repository. Is this true? any references? I imagine submodules is the
>> preferred way of doing this, and "narrow" or "partial" or "sparse"
>> checkouts are under development
>
> I don't think so. You could use symlinks to *simulate* a bigger
> repository that is actually made up of smaller repositories.
>
>
> Dave.
>
thanks, I'm pretty sure I'm just imagining reading this somewhere, I
just needed some confirmation.
^ permalink raw reply
* Re: Weird problem with long $PATH and alternates (bisected)
From: Junio C Hamano @ 2008-10-26 16:15 UTC (permalink / raw)
To: Mikael Magnusson; +Cc: Git Mailing List
In-Reply-To: <237967ef0810260746w10e930c1sf36a2674f49afbe1@mail.gmail.com>
"Mikael Magnusson" <mikachu@gmail.com> writes:
> % mkdir 1; cd 1
> % echo > a; git add a; git commit -m a
> % cd ..
> % git clone -s 1 2
> % git push . master:master
> fatal: Could not switch to
> '/tmp/a/1/.git/objects/n:/usr/games/bin:/usr/local/ipod-chain'
> fatal: The remote end hung up unexpectedly
I think I see a bug in foreach_alt_odb() to add_refs_from_alternate()
callchain, but I cannot explain why the contents of $PATH leaks to the
error message.
Can you try this patch?
sha1_file.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git i/sha1_file.c w/sha1_file.c
index ab2b520..98e7d7a 100644
--- i/sha1_file.c
+++ w/sha1_file.c
@@ -402,9 +402,11 @@ void foreach_alt_odb(alt_odb_fn fn, void *cb)
struct alternate_object_database *ent;
prepare_alt_odb();
- for (ent = alt_odb_list; ent; ent = ent->next)
+ for (ent = alt_odb_list; ent; ent = ent->next) {
+ *ent->name = '\0';
if (fn(ent, cb))
return;
+ }
}
void prepare_alt_odb(void)
^ permalink raw reply related
* Re: git export to svn
From: Warren Harris @ 2008-10-26 16:24 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: J.H., git
In-Reply-To: <20081026091554.GC3612@atjola.homenet>
On Oct 26, 2008, at 2:15 AM, Björn Steinbrink wrote:
> On 2008.10.25 13:29:50 -0700, Warren Harris wrote:
>> I tried a fetch, but still no luck:
>>
>> $ git svn fetch
>> W: Ignoring error from SVN, path probably does not exist: (175002):
>> RA
>> layer request failed: REPORT of '/svn/!svn/bc/100': Could not read
>> chunk
>> size: Secure connection truncated (https://svn)
>> W: Do not be alarmed at the above message git-svn is just searching
>> aggressively for old history.
>> This may take a while on large repositories
>> r58084 = c01dadf89b552077da132273485e7569d8694518 (trunk)
>> A ...
>> r58088 = 7916f3a02ad6c759985bd9fb886423c373a72125 (trunk)
>>
>> $ git svn rebase
>> Unable to determine upstream SVN information from working tree
>> history
>
> Means that your current branch is not based on what git-svn has
> fetched,
> which is expected when you use "svn init" + "svn fetch" after you
> already started working.
>
> What's the actual relationship between your local history and the
> history you fetched from svn?
Since I'm trying to export my git repo to svn, the svn repo is
completely empty.
>
>
> If your local stuff started from revision X, which you manually
> imported
> from svn, you can just rebase it:
>
> git rebase --onto <svn-revision-X> <your-revision-X>
When I try this, I keep getting:
fatal: Needed a single revision
invalid upstream
>
>
>
> If you have a bunch of merges in your local history, you might want to
> merge your stuff into the svn-based branch instead. When you dcommit,
> the svn repo will only see one big "do it all" commit though.
>
> For that, you would create a graft, so that your first "real" local
> commit gets the svn revision X commit as its parent. That is, from:
>
> S---S---SX---S---S---S (svn)
>
> LX--------L---L---L---L (local)
>
> You want to go to:
>
> S---S---SX---S---S---S (svn)
> \
> LX L---L---L---L (local)
>
>
> Where 'S' means that the commit came from SVN, and L means that it
> is a
> "local" commit. SX and LX are the commits that have the same tree
> attached (same directories/files), but have a different hash due to
> how
> they were created. The graft overrides the parent-child relation for
> the
> first "L" commit, so that it actually appears as being branched off
> of SX.
>
> And then, you'd merge local into svn, so you get:
>
> S---S---SX---S---S---S--M (svn)
> \ /
> LX L---L---L---L (local)
>
>
>
> If possible, go with the rebase though. That at least gives a somewhat
> reasonable history in the svn repo as well. Also note that when you go
> with the merge way, make sure that the svn branch is totally uptodate
> before you merge and that the merge commit is the only one to be
> dcommitted. Otherwise, funny stuff might happen, and rebase might kick
> in anyway, I don't exactly remember what git-svn does, but it wasn't
> pleasant :-)
I may not have been clear about what I'm trying to do: I have a git
repository, and I'd like to put it (either the head of the master, or
the entire revision history if possible) into svn. From then on, I
would like to be able to use 'git svn' commands to manage the two
repos. (Initially I don't expect anyone else to be committing to svn
-- it's just an archive and something for others to pull from.)
Here's a complete transcript of how I tried to do this, which seems to
be missing some crucial step:
$ mkdir test2-git-clone
$ git clone ../test2/ # clone my working repo which is unrelated to
svn at this point
$ cd test2-git-clone/test2
$ svn mkdir https://svn/svn/SANDBOX/warren/test2 -m "test2"
$ svn mkdir https://svn/svn/SANDBOX/warren/test2/trunk -m "test2"
$ svn mkdir https://svn/svn/SANDBOX/warren/test2/branches -m "test2"
$ svn mkdir https://svn/svn/SANDBOX/warren/test2/tags -m "test2"
$ git svn init https://svn/svn/SANDBOX/warren/test2 -T trunk -t tags -
b branches
Initialized empty Git repository in /Users/warren/projects/tmp/test2-
git-clone/test2/.git/
Using higher level of URL: https://svn/svn/SANDBOX/warren/test2 => https://svn/svn
$ git svn dcommit
Can't call method "full_url" on an undefined value at /opt/local/
libexec/git-core/git-svn line 425.
$ git merge --no-ff master
Already up-to-date.
$ git svn dcommit
Can't call method "full_url" on an undefined value at /opt/local/
libexec/git-core/git-svn line 425.
$ git svn fetch
$ git svn dcommit
Can't call method "full_url" on an undefined value at /opt/local/
libexec/git-core/git-svn line 425.
Thanks for your help,
Warren
^ permalink raw reply
* Re: Weird problem with long $PATH and alternates (bisected)
From: Mikael Magnusson @ 2008-10-26 16:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vljwb5o4p.fsf@gitster.siamese.dyndns.org>
2008/10/26 Junio C Hamano <gitster@pobox.com>:
> "Mikael Magnusson" <mikachu@gmail.com> writes:
>
>> % mkdir 1; cd 1
>> % echo > a; git add a; git commit -m a
>> % cd ..
>> % git clone -s 1 2
>> % git push . master:master
>> fatal: Could not switch to
>> '/tmp/a/1/.git/objects/n:/usr/games/bin:/usr/local/ipod-chain'
>> fatal: The remote end hung up unexpectedly
>
> I think I see a bug in foreach_alt_odb() to add_refs_from_alternate()
> callchain, but I cannot explain why the contents of $PATH leaks to the
> error message.
>
> Can you try this patch?
Yeah this fixes the issue for me. If I add this
static int add_refs_from_alternate(struct alternate_object_database
*e, void *unused)
{
+ fprintf(stderr, "add: %s\n", e->base);
char *other = xstrdup(make_absolute_path(e->base));
size_t len = strlen(other);
and
prepare_alt_odb();
for (ent = alt_odb_list; ent; ent = ent->next) {
fprintf(stderr, "for: %s\n", ent->name);
if (fn(ent, cb))
return;
then i get
for: in//usr/qt/3/bin:/usr/games/bin:/usr/loca
add: /tmp/a/1/.git/objects/in//usr/qt/3/bin:/usr/games/bin:/usr/loca
fatal: Could not switch to
'/tmp/a/1/.git/objects/in//usr/qt/3/bin:/usr/games/bin:/usr'
fatal: The remote end hung up unexpectedly
--
Mikael Magnusson
^ permalink raw reply
* Re: git export to svn
From: Björn Steinbrink @ 2008-10-26 17:15 UTC (permalink / raw)
To: Warren Harris; +Cc: J.H., git
In-Reply-To: <8ED0030A-E55E-4082-87C9-53B11F763E1B@gmail.com>
On 2008.10.26 09:24:07 -0700, Warren Harris wrote:
>
> On Oct 26, 2008, at 2:15 AM, Björn Steinbrink wrote:
>
>> On 2008.10.25 13:29:50 -0700, Warren Harris wrote:
>>> I tried a fetch, but still no luck:
>>>
>>> $ git svn fetch
>>> W: Ignoring error from SVN, path probably does not exist: (175002):
>>> RA
>>> layer request failed: REPORT of '/svn/!svn/bc/100': Could not read
>>> chunk
>>> size: Secure connection truncated (https://svn)
>>> W: Do not be alarmed at the above message git-svn is just searching
>>> aggressively for old history.
>>> This may take a while on large repositories
>>> r58084 = c01dadf89b552077da132273485e7569d8694518 (trunk)
>>> A ...
>>> r58088 = 7916f3a02ad6c759985bd9fb886423c373a72125 (trunk)
>>>
>>> $ git svn rebase
>>> Unable to determine upstream SVN information from working tree
>>> history
>>
>> Means that your current branch is not based on what git-svn has
>> fetched,
>> which is expected when you use "svn init" + "svn fetch" after you
>> already started working.
>>
>> What's the actual relationship between your local history and the
>> history you fetched from svn?
>
> Since I'm trying to export my git repo to svn, the svn repo is
> completely empty.
OK, the "r58084" made me think that your code is based on something that
is already in the SVN repo. But apperently, that's just a shared svn
repo, right?
> I may not have been clear about what I'm trying to do: I have a git
> repository, and I'd like to put it (either the head of the master, or
> the entire revision history if possible) into svn. From then on, I would
> like to be able to use 'git svn' commands to manage the two repos.
> (Initially I don't expect anyone else to be committing to svn -- it's
> just an archive and something for others to pull from.)
>
> Here's a complete transcript of how I tried to do this, which seems to
> be missing some crucial step:
>
> $ mkdir test2-git-clone
> $ git clone ../test2/ # clone my working repo which is unrelated to
> svn at this point
> $ cd test2-git-clone/test2
> $ svn mkdir https://svn/svn/SANDBOX/warren/test2 -m "test2"
> $ svn mkdir https://svn/svn/SANDBOX/warren/test2/trunk -m "test2"
> $ svn mkdir https://svn/svn/SANDBOX/warren/test2/branches -m "test2"
> $ svn mkdir https://svn/svn/SANDBOX/warren/test2/tags -m "test2"
> $ git svn init https://svn/svn/SANDBOX/warren/test2 -T trunk -t tags -b
> branches
> Initialized empty Git repository in /Users/warren/projects/tmp/test2-
> git-clone/test2/.git/
> Using higher level of URL: https://svn/svn/SANDBOX/warren/test2 => https://svn/svn
> $ git svn dcommit
> Can't call method "full_url" on an undefined value at /opt/local/
> libexec/git-core/git-svn line 425.
Can't work yet, your local stuff is not yet connected to the svn commit
(which you didn't even fetch yet). Same for the other dcommit calls you
did.
> $ git merge --no-ff master
> Already up-to-date.
That tries to merge master into itself ;-) The blog entry assumed that
you have a svn-based branch checked out, and applies to quite a
different situation.
This should do and uses a graft to simplify the process a bit:
Initialize git-svn:
git svn init -s --prefix=svn/ https://svn/svn/SANDBOX/warren/test2
The --prefix gives you remote tracking branches like "svn/trunk" which
is nice because you don't get ambiguous names if you call your local
branch just "trunk" then. And -s is a shortcut for the standard
trunk/tags/branches layout.
Fetch the initial stuff from svn:
git svn fetch
Now look up the hash of your root commit (should show a single commit):
git rev-list --parents master | grep '^.\{40\}$'
Then get the hash of the empty trunk commit:
git rev-parse svn/trunk
Create the graft:
echo <root-commit-hash> <svn-trunk-commit-hash> >> .git/info/grafts
Now, "gitk" should show svn/trunk as the first commit on which your
master branch is based.
Make the graft permanent:
git filter-branch -- ^svn/trunk --all
Drop the graft:
rm .git/info/grafts
gitk should still show svn/trunk in the ancestry of master
Linearize your history on top of trunk:
git svn rebase
And now "git svn dcommit -n" should tell you that it is going to commit
to trunk.
Alternatively, if rebase gives just too many conflicts, you can do:
git svn init -s --prefix=svn/ https://svn/svn/SANDBOX/warren/test2
git svn fetch
git checkout -b trunk svn/trunk
git merge master
git svn dcommit
That will just create a single huge commit in svn. But the history will
be retained in git. You can then work on the new "trunk" branch or move
your master branch, so it points to the same commit as trunk and then
drop the "trunk" branch or whatever. It just matters that your new work
is based upon the dcommited merge commit, so "svn/trunk" is in your
branch's history.
HTH
Björn
^ permalink raw reply
* Re: Weird problem with long $PATH and alternates (bisected)
From: René Scharfe @ 2008-10-26 17:53 UTC (permalink / raw)
To: Mikael Magnusson; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <7vljwb5o4p.fsf@gitster.siamese.dyndns.org>
Junio C Hamano schrieb:
> "Mikael Magnusson" <mikachu@gmail.com> writes:
>
>> % mkdir 1; cd 1
>> % echo > a; git add a; git commit -m a
>> % cd ..
>> % git clone -s 1 2
>> % git push . master:master
>> fatal: Could not switch to
>> '/tmp/a/1/.git/objects/n:/usr/games/bin:/usr/local/ipod-chain'
>> fatal: The remote end hung up unexpectedly
>
> I think I see a bug in foreach_alt_odb() to add_refs_from_alternate()
> callchain, but I cannot explain why the contents of $PATH leaks to the
> error message.
With the following patch, I can no longer reproduce the problem. Does it
work fo you, too?
Thanks,
René
diff --git a/sha1_file.c b/sha1_file.c
index ab2b520..8044e9c 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -269,7 +269,7 @@ static int link_alt_odb_entry(const char * entry, int len, const char * relative
entlen += base_len;
pfxlen += base_len;
}
- ent = xmalloc(sizeof(*ent) + entlen);
+ ent = xcalloc(1, sizeof(*ent) + entlen);
if (!is_absolute_path(entry) && relative_base) {
memcpy(ent->base, relative_base, base_len - 1);
^ permalink raw reply related
* Re: Weird problem with long $PATH and alternates (bisected)
From: Junio C Hamano @ 2008-10-26 18:07 UTC (permalink / raw)
To: René Scharfe; +Cc: Mikael Magnusson, Git Mailing List
In-Reply-To: <4904AE8D.9090706@lsrfire.ath.cx>
René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> Junio C Hamano schrieb:
>> "Mikael Magnusson" <mikachu@gmail.com> writes:
>>
>>> % mkdir 1; cd 1
>>> % echo > a; git add a; git commit -m a
>>> % cd ..
>>> % git clone -s 1 2
>>> % git push . master:master
>>> fatal: Could not switch to
>>> '/tmp/a/1/.git/objects/n:/usr/games/bin:/usr/local/ipod-chain'
>>> fatal: The remote end hung up unexpectedly
>>
>> I think I see a bug in foreach_alt_odb() to add_refs_from_alternate()
>> callchain, but I cannot explain why the contents of $PATH leaks to the
>> error message.
>
> With the following patch, I can no longer reproduce the problem. Does it
> work fo you, too?
>
> Thanks,
> René
>
> diff --git a/sha1_file.c b/sha1_file.c
> index ab2b520..8044e9c 100644
> --- a/sha1_file.c
> +++ b/sha1_file.c
> @@ -269,7 +269,7 @@ static int link_alt_odb_entry(const char * entry, int len, const char * relative
> entlen += base_len;
> pfxlen += base_len;
> }
> - ent = xmalloc(sizeof(*ent) + entlen);
> + ent = xcalloc(1, sizeof(*ent) + entlen);
Ah, that would explain the "filled with garbage from $PATH" issue, but I
don't think it fixes the fundamental issue.
In the alternate_object_database structure, ent->base[] is a buffer the
users can use to form pathnames to loose objects, and ent->name is a
pointer into that buffer (it points at one beyond ".git/objects/"). If
you get a call to add_refs_from_alternate() after somebody used the entry
(has_loose_object() has been called, for example), *ent->name would not be
NUL, and ent->base[] won't be the path to the object store.
This caller is expecting to read the path to the object store in ent->base[];
it needs to NUL terminate the buffer if it wants to.
I think the previous patch to sha1_file.c, while it may fix the issue, is
not quite nice. Here is a replacement that should work.
builtin-receive-pack.c | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git c/builtin-receive-pack.c w/builtin-receive-pack.c
index 45e3cd9..9f60f31 100644
--- c/builtin-receive-pack.c
+++ w/builtin-receive-pack.c
@@ -466,12 +466,17 @@ static int delete_only(struct command *cmd)
static int add_refs_from_alternate(struct alternate_object_database *e, void *unused)
{
- char *other = xstrdup(make_absolute_path(e->base));
- size_t len = strlen(other);
+ char *other;
+ size_t len;
struct remote *remote;
struct transport *transport;
const struct ref *extra;
+ e->name[-1] = '\0';
+ other = xstrdup(make_absolute_path(e->base));
+ e->name[-1] = '/';
+ len = strlen(other);
+
while (other[len-1] == '/')
other[--len] = '\0';
if (len < 8 || memcmp(other + len - 8, "/objects", 8))
^ permalink raw reply related
* Re: Weird problem with long $PATH and alternates (bisected)
From: Mikael Magnusson @ 2008-10-26 18:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: René Scharfe, Git Mailing List
In-Reply-To: <7v63nf5iy1.fsf@gitster.siamese.dyndns.org>
2008/10/26 Junio C Hamano <gitster@pobox.com>:
> René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
>
>> Junio C Hamano schrieb:
>>> "Mikael Magnusson" <mikachu@gmail.com> writes:
>>>
>>>> % mkdir 1; cd 1
>>>> % echo > a; git add a; git commit -m a
>>>> % cd ..
>>>> % git clone -s 1 2
>>>> % git push . master:master
>>>> fatal: Could not switch to
>>>> '/tmp/a/1/.git/objects/n:/usr/games/bin:/usr/local/ipod-chain'
>>>> fatal: The remote end hung up unexpectedly
>>>
>>> I think I see a bug in foreach_alt_odb() to add_refs_from_alternate()
>>> callchain, but I cannot explain why the contents of $PATH leaks to the
>>> error message.
>
> I think the previous patch to sha1_file.c, while it may fix the issue, is
> not quite nice. Here is a replacement that should work.
It does.
--
Mikael Magnusson
^ permalink raw reply
* Re: [VOTE] git versus mercurial (for DragonflyBSD)
From: Jakub Narebski @ 2008-10-26 18:55 UTC (permalink / raw)
To: SLONIK.AZ; +Cc: Maxim Vuets, mercurial, git
In-Reply-To: <ee2a733e0810260805n35c3a637v4739dda938a22518@mail.gmail.com>
I'm not sure if Mercurial mailing list is not subscribe only. Git isn't.
On Sun, 26 Oct 2008, Leo Razoumov wrote:
> On 10/26/08, Maxim Vuets <maxim.vuets@gmail.com> wrote:
>> On 26 Oct 2008 15:15:57 +0100, Jakub Narebski <jnareb@gmail.com> wrote:
>>>
>>> 1. Documentation and ease of use.
>>>
>>> Mercurial is supposedly better documented and easier to use; I
>>> think this descends from the early days of Git, where it was not
>>> very user friendly. IMHO Git has much improved since. Mercurial
>>> had 'hgbook' from the beginning; Git User's Manual is more recent.
>>
>> Also, there is http://book.git-scm.com/ that is similar to hgbook, I think.
>>
>> Thanks for the comprarision!
>
> I have been using Mercurial for about two years and am very
> comfortable with it. Here are some cons and pros
>
> Mercurial PROS:
> * Easier and more consistent UI. Newbie friendly.
I think that _might_ be example of "Worse is better" scenario, with Git
having UI which evolved rather than was designed, and therefore less
consistent.
Also if you are limiting to what is described in main chapters of
'hgbook', namely one branch (one "fork") per repository paradigm
everything is simpler.
> * Better documentation. IMHO, hgbook is by far better than
> http://book.git-scm.com/
And probably better than "Git User's Manual". There are lot of various
git-related documentation: "Git Magic", "Git for Computer Scientists",
"Git from bottoms up"...
> * Windows support (personally, I do not care)
And I think it is not important for DragonflyBSD.
Besides git _has_ MS Windows support, in the form of Cygwin and in the
form of msysGit project. It is still not as full as Linux support (for
example git-svn comes to mind), but it is not bad. Well, Mercurial
has TortiouseHg, while Git-Cheetah is in very early stages...
>
> Mercurial CONS:
> * Less potential than git. Once Ted Tso even said that "git has more
> legs than mercurial", see
> http://thunk.org/tytso/blog/2007/03/24/git-and-hg/
I agree, and I think it is at least partially because of Git having
cleaner design, even if you have to understand more terms at first.
> * Hg is strictly an SCM system while GIT is a content addressable file
> system that can be used in other ways, hence the name Global
> Information Tracker (GIT)
Errr... I think you are mislead by tongue-in-cheek backronym, which was
created in the beginning, when git had very weak porcelain (i.e. SCM UI).
> * Recently, Hg development seems to have somewhat slowed down. To
> simply put it, there is not enough room in the world for several
> similar SCM systems. With git's pace and momentum the other SCMs
> including Hg are fighting an uphill battle.
The competing _distributed_ version control systems left seems to be
Bazaar-NG (Ubuntu), Mercurial (OpenSolaris, Mozilla), Git (Linux kernel,
Freedesktop.org, Ruby on Rails people). There are many IDEs, many
editors, many web browsers; there is Linux and there are *BSD; I hope
that Mercurial would continue to be developed, and not vanish in
obscurity like Arch and clones...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [VOTE] git versus mercurial (for DragonflyBSD)
From: Jakub Narebski @ 2008-10-26 19:07 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, mercurial
In-Reply-To: <94a0d4530810260857u7c0cb122g8147b9484108f539@mail.gmail.com>
I'm not sure if Mercurial mailing list is not subscribe only. Git isn't.
On Sun, 26 Sep 2008, Felipe Contreras wrote:
> On Sun, Oct 26, 2008 at 4:15 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> > [Cc: gmane.comp.version-control.git,
> > gmane.comp.version-control.mercurial.general]
> > 3. Repository design and performance.
> > Git and Mercurial have similar performance, although it is thought
> > that due to design Mercurial has faster patch applying and is
> > optimized for cold cache case, while Git has faster merging and is
> > optimized for warm cache case.
> >
> > Mercurial may have (or had) problems with larger binary files, from
> > what I have heard.
>
> The fact that hg is changeset based means that certain operations are
> slower, like checkout a specific commit. In hg my bet is you would
> need to gather a bunch of changesets while in git the operation is
> done in a single step.
Actually from what I have read Mercurial stores current version
(snapshot) from time to time, so time to resolve specific commit is
limited. Also if you have packed your Git repository (good idea not
only to limit size, but also for performance (I/O performance)), then
resolving specific commit also might require some delta resolution
(by default delta chain length is limited to 50, see pack.depth).
> It also means that bare clones are not possible in hg, or at least
> very complicated.
I think it is things like .hgtags which make bare clones (without
working directory) to be hard or even impossible in Mercurial.
> Note: I'm not sure if what I'm claiming is correct.
Hmmm...
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH v2] add -p: warn if only binary changes present
From: Thomas Rast @ 2008-10-26 19:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeff King, szeder
In-Reply-To: <20081026104006.GA18969@neumann>
Current 'git add -p' will say "No changes." if there are no changes to
text files, which can be confusing if there _are_ changes to binary
files. Add some code to distinguish the two cases, and give a
different message in the latter one.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
SZEDER Gábor wrote:
> What about
>
> Only binary files changed.
>
> or something of the sort?
Yes, why not.
git-add--interactive.perl | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index da768ee..b0223c3 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -811,11 +811,16 @@ EOF
}
sub patch_update_cmd {
- my @mods = grep { !($_->{BINARY}) } list_modified('file-only');
+ my @all_mods = list_modified('file-only');
+ my @mods = grep { !($_->{BINARY}) } @all_mods;
my @them;
if (!@mods) {
- print STDERR "No changes.\n";
+ if (@all_mods) {
+ print STDERR "Only binary files changed.\n";
+ } else {
+ print STDERR "No changes.\n";
+ }
return 0;
}
if ($patch_mode) {
--
tg: (759ad19..) t/add-p-binary-warn (depends on: origin/master)
^ permalink raw reply related
* Re: [PATCH v2] add -p: warn if only binary changes present
From: Jeff King @ 2008-10-26 19:38 UTC (permalink / raw)
To: Thomas Rast; +Cc: Junio C Hamano, git, szeder
In-Reply-To: <1225049826-14941-1-git-send-email-trast@student.ethz.ch>
On Sun, Oct 26, 2008 at 08:37:06PM +0100, Thomas Rast wrote:
> > What about
> >
> > Only binary files changed.
> >
> > or something of the sort?
>
> Yes, why not.
That is better, IMHO.
-Peff
^ permalink raw reply
* Re: [VOTE] git versus mercurial (for DragonflyBSD)
From: Felipe Contreras @ 2008-10-26 19:54 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, mercurial
In-Reply-To: <200810262007.30148.jnareb@gmail.com>
On Sun, Oct 26, 2008 at 9:07 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> I'm not sure if Mercurial mailing list is not subscribe only. Git isn't.
>
> On Sun, 26 Sep 2008, Felipe Contreras wrote:
>> On Sun, Oct 26, 2008 at 4:15 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>> > [Cc: gmane.comp.version-control.git,
>> > gmane.comp.version-control.mercurial.general]
>
>> > 3. Repository design and performance.
>
>> > Git and Mercurial have similar performance, although it is thought
>> > that due to design Mercurial has faster patch applying and is
>> > optimized for cold cache case, while Git has faster merging and is
>> > optimized for warm cache case.
>> >
>> > Mercurial may have (or had) problems with larger binary files, from
>> > what I have heard.
>>
>> The fact that hg is changeset based means that certain operations are
>> slower, like checkout a specific commit. In hg my bet is you would
>> need to gather a bunch of changesets while in git the operation is
>> done in a single step.
>
> Actually from what I have read Mercurial stores current version
> (snapshot) from time to time, so time to resolve specific commit is
> limited. Also if you have packed your Git repository (good idea not
> only to limit size, but also for performance (I/O performance)), then
> resolving specific commit also might require some delta resolution
> (by default delta chain length is limited to 50, see pack.depth).
Ah, ok, good to know.
>> It also means that bare clones are not possible in hg, or at least
>> very complicated.
>
> I think it is things like .hgtags which make bare clones (without
> working directory) to be hard or even impossible in Mercurial.
Oops, I meant shallow clones (git clone --depth=1).
--
Felipe Contreras
^ permalink raw reply
* Re: [RFC] Zit (v2): the git-based single file content tracker
From: Giuseppe Bilotta @ 2008-10-26 21:18 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3k5bvgz83.fsf@localhost.localdomain>
On Sun, Oct 26, 2008 at 4:20 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> "Giuseppe Bilotta" <giuseppe.bilotta@gmail.com> writes:
>> Ah, good idea. Done, in Version Control Interface layers section
>
> Thanks.
>
> I have added link to repositoy, as you didn't configure your gitweb to
> display those URL links (see gitweb/README and gitweb/INSTALL).
Oops, right, thanks. BTW, isn't there a way to have the git:// URL be
computed automatically? Judging by the docs, it seems that I have to
set it manually for each project, like the description.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* git working tree status
From: Mike Clarke @ 2008-10-26 21:54 UTC (permalink / raw)
To: git
Hi all,
I'd like a way of getting a simple summary of the status of a working
tree, for consumption by other programs rather than humans.
Specifically, I'd like to know whether the working tree is:
a) fully 'clean' -- i.e., all changes checked in, no stashes;
b) all changes checked in, but there are some stashes; or
c) 'dirty' in some way -- new files, uncommitted changes, etc.
The logical way to do this seems to be via an exit code, but the exit
code of git status is not currently rich enough. As a result, I'm
considering the addition of an option to git status -- perhaps
'--is-clean' -- that would provide the required information.
My questions are:
1) Is there already some way of doing this that I've overlooked?
2) Would the preferred approach be an option (git status --is-clean)
or a sub-command (git is-clean)? A sub-command would probably result
in cleaner internal code, but would also clutter the interface.
3) Is a patch for such a feature likely to be accepted?
Thanks,
--
Mike Clarke
^ permalink raw reply
* [PATCH] Add mksnpath and git_snpath which allow to specify the output buffer
From: Alex Riesen @ 2008-10-26 21:59 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Both are actually just vsnprintf's but additionally call cleanup_path
on the result. To be used as alternatives to mkpath and git_path where
the buffer for the created path may not be reused by subsequent calls
of the same formatting function.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
cache.h | 4 ++++
path.c | 38 ++++++++++++++++++++++++++++++++++++++
2 files changed, 42 insertions(+), 0 deletions(-)
diff --git a/cache.h b/cache.h
index b0edbf9..a9024db 100644
--- a/cache.h
+++ b/cache.h
@@ -495,6 +495,10 @@ extern int check_repository_format(void);
#define DATA_CHANGED 0x0020
#define TYPE_CHANGED 0x0040
+extern char *mksnpath(char *buf, size_t n, const char *fmt, ...)
+ __attribute__((format (printf, 3, 4)));
+extern char *git_snpath(char *buf, size_t n, const char *fmt, ...)
+ __attribute__((format (printf, 3, 4)));
/* Return a statically allocated filename matching the sha1 signature */
extern char *mkpath(const char *fmt, ...) __attribute__((format (printf, 1, 2)));
extern char *git_path(const char *fmt, ...) __attribute__((format (printf, 1, 2)));
diff --git a/path.c b/path.c
index 76e8872..85ab28a 100644
--- a/path.c
+++ b/path.c
@@ -32,6 +32,44 @@ static char *cleanup_path(char *path)
return path;
}
+char *mksnpath(char *buf, size_t n, const char *fmt, ...)
+{
+ va_list args;
+ unsigned len;
+
+ va_start(args, fmt);
+ len = vsnprintf(buf, n, fmt, args);
+ va_end(args);
+ if (len >= n) {
+ snprintf(buf, n, bad_path);
+ return buf;
+ }
+ return cleanup_path(buf);
+}
+
+char *git_snpath(char *buf, size_t n, const char *fmt, ...)
+{
+ const char *git_dir = get_git_dir();
+ va_list args;
+ size_t len;
+
+ len = strlen(git_dir);
+ if (n < len + 1)
+ goto bad;
+ memcpy(buf, git_dir, len);
+ if (len && !is_dir_sep(git_dir[len-1]))
+ buf[len++] = '/';
+ va_start(args, fmt);
+ len += vsnprintf(buf + len, n - len, fmt, args);
+ va_end(args);
+ if (len >= n)
+ goto bad;
+ return cleanup_path(buf);
+bad:
+ snprintf(buf, n, bad_path);
+ return buf;
+}
+
char *mkpath(const char *fmt, ...)
{
va_list args;
--
1.6.0.3.540.g3f8b
^ permalink raw reply related
* Re: [RFC] Zit (v2): the git-based single file content tracker
From: Jakub Narebski @ 2008-10-26 22:04 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git
In-Reply-To: <cb7bb73a0810261418y3b114e2ag81cbb75c4a80603c@mail.gmail.com>
Giuseppe Bilotta wrote:
> On Sun, Oct 26, 2008 at 4:20 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>> "Giuseppe Bilotta" <giuseppe.bilotta@gmail.com> writes:
>>>
>>> Ah, good idea. Done, in Version Control Interface layers section
>>
>> Thanks.
>>
>> I have added link to repositoy, as you didn't configure your gitweb to
>> display those URL links (see gitweb/README and gitweb/INSTALL).
>
> Oops, right, thanks. BTW, isn't there a way to have the git:// URL be
> computed automatically? Judging by the docs, it seems that I have to
> set it manually for each project, like the description.
gitweb/README:
How to configure gitweb for your local system
---------------------------------------------
[...]
* GITWEB_BASE_URL
Git base URLs used for URL to where fetch project from, i.e. full
URL is "$git_base_url/$project". Shown on projects summary page.
Repository URL for project can be also configured per repository; this
takes precedence over URLs composed from base URL and a project name.
Note that you can setup multiple base URLs (for example one for
git:// protocol access, another for http:// access) from the gitweb
config file. [No default]
[...]
Runtime gitweb configuration
----------------------------
[...]
Gitweb config file variables
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[...]
* @git_base_url_list
List of git base URLs used for URL to where fetch project from, shown
in project summary page. Full URL is "$git_base_url/$project".
You can setup multiple base URLs (for example one for git:// protocol
access, and one for http:// "dumb" protocol access). Note that per
repository configuration in 'cloneurl' file, or as values of gitweb.url
project config.
Ooops, there seems to be a type in above...
Per-repository gitweb configuration
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[...]
* cloneurl (or multiple-valued gitweb.url)
File with repository URL (used for clone and fetch), one per line.
Displayed in the project summary page. You can use multiple-valued
gitweb.url repository configuration variable for that, but the file
takes precedence.
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH] Fix mkpath abuse in dwim_ref and dwim_log of sha1_name.c
From: Alex Riesen @ 2008-10-26 22:07 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <20081026215913.GA18594@blimp.localdomain>
Otherwise the function sometimes fail to resolve obviously correct
refnames, because the string data pointed to by "str" argument were
reused.
The change in dwim_log does not fix anything, just optimizes away
strcpy code as the path can be created directly in the available
buffer.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
Was noticed in cygwin port, which somehow (supposedly by excessive
calling of git_config from lstat stub setup) managed to reuse the
just returned buffer.
sha1_name.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index 41b6809..159c2ab 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -245,11 +245,13 @@ int dwim_ref(const char *str, int len, unsigned char *sha1, char **ref)
*ref = NULL;
for (p = ref_rev_parse_rules; *p; p++) {
+ char fullref[PATH_MAX];
unsigned char sha1_from_ref[20];
unsigned char *this_result;
this_result = refs_found ? sha1_from_ref : sha1;
- r = resolve_ref(mkpath(*p, len, str), this_result, 1, NULL);
+ mksnpath(fullref, sizeof(fullref), *p, len, str);
+ r = resolve_ref(fullref, this_result, 1, NULL);
if (r) {
if (!refs_found++)
*ref = xstrdup(r);
@@ -272,7 +274,7 @@ int dwim_log(const char *str, int len, unsigned char *sha1, char **log)
char path[PATH_MAX];
const char *ref, *it;
- strcpy(path, mkpath(*p, len, str));
+ mksnpath(path, sizeof(path), *p, len, str);
ref = resolve_ref(path, hash, 1, NULL);
if (!ref)
continue;
--
1.6.0.3.540.g3f8b
^ permalink raw reply related
* [PATCH] Fix potentially dangerous uses of mkpath and git_path
From: Alex Riesen @ 2008-10-26 22:08 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <20081026215913.GA18594@blimp.localdomain>
Replace them with mksnpath/git_snpath and a local buffer
for the resulting string.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
builtin-apply.c | 4 ++--
builtin-for-each-ref.c | 6 ++++--
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/builtin-apply.c b/builtin-apply.c
index cfd8fce..4c4d1e1 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -2841,8 +2841,8 @@ static void create_one_file(char *path, unsigned mode, const char *buf, unsigned
unsigned int nr = getpid();
for (;;) {
- const char *newpath;
- newpath = mkpath("%s~%u", path, nr);
+ char newpath[PATH_MAX];
+ mksnpath(newpath, sizeof(newpath), "%s~%u", path, nr);
if (!try_create_file(newpath, mode, buf, size)) {
if (!rename(newpath, path))
return;
diff --git a/builtin-for-each-ref.c b/builtin-for-each-ref.c
index fa6c1ed..e46b7ad 100644
--- a/builtin-for-each-ref.c
+++ b/builtin-for-each-ref.c
@@ -620,14 +620,16 @@ static char *get_short_ref(struct refinfo *ref)
for (j = 0; j < i; j++) {
const char *rule = ref_rev_parse_rules[j];
unsigned char short_objectname[20];
+ char refname[PATH_MAX];
/*
* the short name is ambiguous, if it resolves
* (with this previous rule) to a valid ref
* read_ref() returns 0 on success
*/
- if (!read_ref(mkpath(rule, short_name_len, short_name),
- short_objectname))
+ mksnpath(refname, sizeof(refname),
+ rule, short_name_len, short_name);
+ if (!read_ref(refname, short_objectname))
break;
}
--
1.6.0.3.540.g3f8b
^ permalink raw reply related
* Re: [RFC] Zit (v2): the git-based single file content tracker
From: Giuseppe Bilotta @ 2008-10-26 22:16 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200810262304.13582.jnareb@gmail.com>
On Sun, Oct 26, 2008 at 11:04 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> Gitweb config file variables
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> [...]
> * @git_base_url_list
> List of git base URLs used for URL to where fetch project from, shown
> in project summary page. Full URL is "$git_base_url/$project".
> You can setup multiple base URLs (for example one for git:// protocol
> access, and one for http:// "dumb" protocol access). Note that per
> repository configuration in 'cloneurl' file, or as values of gitweb.url
> project config.
Doh, thanks, I had totally overlooked it. Done 8-)
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: [PATCH 5/5] blame: use xdi_diff_hunks(), get rid of struct patch
From: René Scharfe @ 2008-10-26 22:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Brian Downing, git
In-Reply-To: <7vhc708o1v.fsf@gitster.siamese.dyndns.org>
Junio C Hamano schrieb:
> Perhaps revision.c in our history would be more interesting than cache.h
> or Makefile, as there are more line migrations from different places to
> that file.
Indeed:
# master
$ /usr/bin/time $blame revision.c >/dev/null
2.15user 0.27system 0:02.58elapsed 94%CPU (0avgtext+0avgdata 0maxresident)k
3544inputs+0outputs (29major+13835minor)pagefaults 0swaps
# this patch series
$ /usr/bin/time $blame revision.c >/dev/null
1.88user 0.14system 0:02.03elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+14068minor)pagefaults 0swaps
René
^ permalink raw reply
* Re: git working tree status
From: Miklos Vajna @ 2008-10-26 22:23 UTC (permalink / raw)
To: Mike Clarke; +Cc: git
In-Reply-To: <73f525b90810261454wb902edfk3a696c06ef2148d1@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1411 bytes --]
On Sun, Oct 26, 2008 at 09:54:03PM +0000, Mike Clarke <clarkema@gmail.com> wrote:
> a) fully 'clean' -- i.e., all changes checked in, no stashes;
In case you want to ignore ignores:
$ git ls-files -o
otherwise:
git ls-files -o --exclude-standard
by 'stashes', I guess you mean those extra files, but using that term is
confusing, given that stashes can be listed with git stash list and they
are actually merge commits (so something totally different).
> b) all changes checked in, but there are some stashes; or
git update-index -q --refresh
test -z "$(git diff-index --name-only HEAD --)" && echo "everything committed"
> c) 'dirty' in some way -- new files, uncommitted changes, etc.
git update-index -q --refresh
test -z "$(git diff-index --name-only HEAD --)" && echo "dirty"
see GIT-VERSION-GEN in git.git
> 1) Is there already some way of doing this that I've overlooked?
> 2) Would the preferred approach be an option (git status --is-clean)
> or a sub-command (git is-clean)? A sub-command would probably result
> in cleaner internal code, but would also clutter the interface.
I guess you overlooked the fact that plumbing is supposed to be used
from scripts and porcelain by the users. git status is porcelain, so
in general just don't use it from scripts.
> 3) Is a patch for such a feature likely to be accepted?
I don't think so, see above.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: git working tree status
From: Miklos Vajna @ 2008-10-26 22:26 UTC (permalink / raw)
To: Mike Clarke; +Cc: git
In-Reply-To: <20081026222335.GJ2273@genesis.frugalware.org>
[-- Attachment #1: Type: text/plain, Size: 307 bytes --]
On Sun, Oct 26, 2008 at 11:23:35PM +0100, Miklos Vajna <vmiklos@frugalware.org> wrote:
> > c) 'dirty' in some way -- new files, uncommitted changes, etc.
>
> git update-index -q --refresh
> test -z "$(git diff-index --name-only HEAD --)" && echo "dirty"
I wanted to write '|| echo "dirty"', sorry.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [VOTE] git versus mercurial (for DragonflyBSD)
From: Arne Babenhauserheide @ 2008-10-27 0:20 UTC (permalink / raw)
To: mercurial; +Cc: Jakub Narebski, SLONIK.AZ, git
In-Reply-To: <200810261955.10536.jnareb@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1796 bytes --]
Am Sonntag 26 Oktober 2008 19:55:09 schrieb Jakub Narebski:
> > * Recently, Hg development seems to have somewhat slowed down. To
> > simply put it, there is not enough room in the world for several
> > similar SCM systems. With git's pace and momentum the other SCMs
> > including Hg are fighting an uphill battle.
>
> The competing _distributed_ version control systems left seems to be
> Bazaar-NG (Ubuntu), Mercurial (OpenSolaris, Mozilla), Git (Linux kernel,
> Freedesktop.org, Ruby on Rails people). There are many IDEs, many
> editors, many web browsers; there is Linux and there are *BSD; I hope
> that Mercurial would continue to be developed, and not vanish in
> obscurity like Arch and clones...
Before we get tangled in this train of thought:
I created a head-to-head code_swarm of Mercurial and Git and it clearly shows
that Mercurial development didn't slow down.
The code_swarm isn't a fancy one with music and annotations, but I think
you'll directly see for yourself what I mean:
- http://www.rakjar.de/shared_codeswarm/hg-vs-git-short.avi
red is git,
blue is Mercurial.
It is a result of my shared_codeswarm project with which you can create
code_swarms from more than one repository automatically - and update them
incrementally, creating new code_swarms of only the new commits in the
repositories:
- http://www.rakjar.de/shared_codeswarm/project_activity_battle_swarm.html
Best wishes,
Arne
-- My stuff: http://draketo.de - stories, songs, poems, programs and stuff :)
-- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the
history of free software.
-- Ein Würfel System: http://1w6.org - einfach saubere (Rollenspiel-) Regeln.
-- PGP/GnuPG: http://draketo.de/inhalt/ich/pubkey.txt
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 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