* Problems during upgrade git from 1.5.3.2 to latest
From: horry @ 2008-10-27 2:29 UTC (permalink / raw)
To: git
Hello ,
My previous git version is 1.5.3.2 and i perform the suggested commands :
git clone http://www.kernel.org/pub/scm/git/git.git and it goes well , end
up with :
....................................................................
got d00da833cbeec16da9415e0ac11269594279545a
Checking 1480 files out...
100% (1480/1480) done
Then i checked git version , it still shows previous version without any
change .
XXXXXXX:/apps/mds_lrt/git/git> git version
git version 1.5.3.2
Is there additional command which i should perform after clone ?
thanks,
Horry
--
View this message in context: http://www.nabble.com/Problems-during-upgrade-git-from-1.5.3.2-to-latest-tp20180862p20180862.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* [RFC] gitweb: add 'historyfollow' view that follows renames
From: Blucher, Guy @ 2008-10-27 3:17 UTC (permalink / raw)
To: ming.m.lin, jnareb, robert.moore; +Cc: git
Hi Folks,
>>
>> What should we add to automatically get all file history?
> While the 'commitdiff' view would, in default gitweb configuration,
> contain information about file renames, currently 'history' view does
> not support '--follow' option to git-log. It wouldn't be too hard to
> add it, but it just wasn't done (well, add to this the fact that
> --follow works only for simple cases).
We also ran up against this issue because renaming of files in our
project is a useful bit of information while browsing file history.
I hacked gitweb to add a 'historyfollow' viewing option in addition to
the 'history' option. Yes, '--follow' is expensive so I didn't just
make it the default 'history' behaviour.
The only problem with doing it was that parse_commits in gitweb.perl
uses git rev-list which doesn't support the '--follow' option like
git-log does. A bit of hacking to use 'git log --pretty=raw -z' to make
the output look close to that from rev-list means only minor
shoe-horning is required (perhaps it would be better to make rev-list
understand --follow though?).
I wasn't originally prepared to publish the work here because I don't
really think it's the best solution. But considering it's come up... I
include a patch inline against gitweb.perl from v1.6.0.3 that implements
a 'historyfollow' view.
Feel free to do with it what you will. It would need some substantial
tidying up by someone who knows much more about perl than me :)
We use it such that anywhere a 'history' link is provided a
'historyfollow' link is also provided next to it - This patch doesn't
implement that bit though.
Hope it helps.
Cheers,
Guy.
---
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -478,6 +478,7 @@ my %actions = (
"forks" => \&git_forks,
"heads" => \&git_heads,
"history" => \&git_history,
+ "historyfollow" => \&git_history_follow,
"log" => \&git_log,
"rss" => \&git_rss,
"atom" => \&git_atom,
@@ -2311,25 +2312,39 @@ sub parse_commit {
}
sub parse_commits {
- my ($commit_id, $maxcount, $skip, $filename, @args) = @_;
+ my ($commit_id, $maxcount, $skip, $mode, $filename, @args) = @_;
my @cos;
$maxcount ||= 1;
$skip ||= 0;
local $/ = "\0";
+ # The '--max-count' argument is not available when doing a
+ # '--follow' to 'git log'
+ my $count_arg = ("--max-count=" . $maxcount) ;
+ if (defined $mode && $mode eq "--follow") {
+ $count_arg = "--follow" ;
+ }
- open my $fd, "-|", git_cmd(), "rev-list",
- "--header",
+
+ open my $fd, "-|", git_cmd(), "log",
+ "-z",
+ "--pretty=raw",
@args,
- ("--max-count=" . $maxcount),
+ ($count_arg ? ($count_arg ) : ()),
("--skip=" . $skip),
@extra_options,
$commit_id,
"--",
($filename ? ($filename) : ())
- or die_error(500, "Open git-rev-list failed");
+ or die_error(500, "Open git-log failed");
while (my $line = <$fd>) {
+ # Need to put a delimiter on the end of output
+ # 'git-log -z' doesn't put one before EOF like rev-list
does
+ $line = ($line . '\0');
+ # Need to strip the word commit from the start so it
+ # looks like rev-list output
+ $line =~ s/^commit // ;
my %co = parse_commit_text($line);
push @cos, \%co;
}
@@ -5363,6 +5378,13 @@ sub git_commitdiff_plain {
}
sub git_history {
+ my $mode = shift || '';
+ my $history_call = "history";
+
+ if ($mode eq "--follow") {
+ $history_call .= "historyfollow" ;
+ }
+
if (!defined $hash_base) {
$hash_base = git_get_head_hash($project);
}
@@ -5377,7 +5399,7 @@ sub git_history {
my $limit = sprintf("--max-count=%i", (100 * ($page+1)));
my @commitlist = parse_commits($hash_base, 101, (100 * $page),
- $file_name, "--full-history")
+ $mode, $file_name,
"--full-history")
or die_error(404, "No such file or directory on given
branch");
if (!defined $hash && defined $file_name) {
@@ -5398,7 +5420,7 @@ sub git_history {
my $paging_nav = '';
if ($page > 0) {
$paging_nav .=
- $cgi->a({-href => href(action=>"history",
hash=>$hash, hash_base=>$hash_base,
+ $cgi->a({-href => href(action=>"$history_call",
hash=>$hash, hash_base=>$hash_base,
file_name=>$file_name)},
"first");
$paging_nav .= " ⋅ " .
@@ -5429,6 +5451,11 @@ sub git_history {
git_footer_html();
}
+sub git_history_follow {
+ git_history('--follow');
+}
+
+
sub git_search {
gitweb_check_feature('search') or die_error(403, "Search is
disabled");
if (!defined $searchtext) {
@@ -5469,7 +5496,7 @@ sub git_search {
$greptype = "--committer=";
}
$greptype .= $searchtext;
- my @commitlist = parse_commits($hash, 101, (100 *
$page), undef,
+ my @commitlist = parse_commits($hash, 101, (100 *
$page), undef, undef,
$greptype,
'--regexp-ignore-case',
$search_use_regexp ?
'--extended-regexp' : '--fixed-strings');
@@ -5737,7 +5764,7 @@ sub git_feed {
# log/feed of current (HEAD) branch, log of given branch,
history of file/directory
my $head = $hash || 'HEAD';
- my @commitlist = parse_commits($head, 150, 0, $file_name);
+ my @commitlist = parse_commits($head, 150, 0, undef,
$file_name);
my %latest_commit;
my %latest_date;
---
Guy.
____________________________________________________
Guy Blucher
Defence Science and Technology Organisation
AUSTRALIA
IMPORTANT : This email remains the property of the Australian Defence
Organisation and is subject to the jurisdiction of section 70 of the
Crimes Act 1914. If you have received this email in error, you are
requested to contact the sender and delete the email.
^ permalink raw reply
* Re: Problems during upgrade git from 1.5.3.2 to latest
From: Pete Harlan @ 2008-10-27 3:58 UTC (permalink / raw)
To: horry; +Cc: git
In-Reply-To: <20180862.post@talk.nabble.com>
horry wrote:
> Hello ,
> My previous git version is 1.5.3.2 and i perform the suggested commands :
> git clone http://www.kernel.org/pub/scm/git/git.git and it goes well , end
> up with :
>
> ....................................................................
> got d00da833cbeec16da9415e0ac11269594279545a
> Checking 1480 files out...
> 100% (1480/1480) done
>
> Then i perform make in the same directory i performed clone and it shows
> errors .
>
> bfnt47-gx1:/apps/mds_lrt/git/git> make
> GIT_VERSION = 1.6.0.3.517.g759a
> * new build flags or prefix
> CC fast-import.o
> In file included from /usr/include/openssl/ssl.h:179,
> from git-compat-util.h:104,
> from builtin.h:4,
> from fast-import.c:142:
> /usr/include/openssl/kssl.h:72:18: krb5.h: No such file or directory
This is saying that you are missing this header file. On my machine
(Debian Linux "testing") the package that provides that file is libkrb5-dev.
Even if you're not using Debian, or Linux, this page may help you locate
which packages on your system may contain a given missing file:
http://www.debian.org/distrib/packages#search_contents
Entering krb5.h in the "Search the contents of packages" box brings up a
list of packages containing files ending in "krb5.h", one (likely
example of which) is libkrb5-dev.
--Pete
> XXXXXXX:/apps/mds_lrt/git/git> git version
> git version 1.5.3.2
>
> Can someone tell me how to resolve it ?
>
> thanks,
> Horry
^ permalink raw reply
* Re: [VOTE] git versus mercurial (for DragonflyBSD)
From: Leo Razoumov @ 2008-10-27 4:15 UTC (permalink / raw)
To: Arne Babenhauserheide; +Cc: mercurial, Jakub Narebski, git
In-Reply-To: <200810270120.55276.arne_bab@web.de>
On 10/26/08, Arne Babenhauserheide <arne_bab@web.de> wrote:
> 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.
>
I am not familiar with code swarms, sorry. My impressions are
subjective are thoroughly un-scientific:-)
(1) Judging by the activity of mailing lists git community is several
times larger and more active in terms of actual submitted patches.
(2) Hg forest extension is still not in the tree with outdated and
incorrect documentation in the wiki. For me it was biggest reason to
migrate from Hg to git.
--Leo--
^ permalink raw reply
* Re: [PATCH] Add mksnpath and git_snpath which allow to specify the output buffer
From: Junio C Hamano @ 2008-10-27 5:07 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20081026215913.GA18594@blimp.localdomain>
Where is git_snpath() used?
^ permalink raw reply
* Re: [PATCH] Add support for uintmax_t type on FreeBSD 4.9
From: Junio C Hamano @ 2008-10-27 5:30 UTC (permalink / raw)
To: David M. Syzdek; +Cc: git
In-Reply-To: <1225021957-11880-1-git-send-email-david.syzdek@acsalaska.net>
"David M. Syzdek" <david.syzdek@acsalaska.net> writes:
> This adds NO_UINTMAX_T for ancient systems. If NO_UINTMAX_T is defined, then
> uintmax_t is defined as uint32_t. This adds a test to configure.ac for
> uintmax_t and adds a check to the Makefile for FreeBSD 4.9-SECURITY.
> ...
> diff --git a/Makefile b/Makefile
> index 0d40f0e..bf6a6dc 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -931,6 +931,9 @@ endif
> ifdef NO_IPV6
> BASIC_CFLAGS += -DNO_IPV6
> endif
> +ifdef NO_UINTMAX_T
> + BASIC_CFLAGS += -Duintmax_t=uint32_t
> +endif
I have a stupid question.
Would it be a more appropriate improvement to do it like this:
ifdef USE_THIS_AS_UINTMAX_T
BASIC_CFLAGS += -Duintmax_t="$(USE_THIS_AS_UINTMAX_T)"
endif
and then add a section for FreeBSD 4.9-SECURITY like this:
ifeq ($(uname_R),4.9-SECURITY)
USE_THIS_AS_UINTMAX_T = uint32_t
endif
That way, an oddball 64-bit machine can use uint64_t here if it wants to,
possibly including FreeBSD 4.9-SECURITY backported to 64-bit ;-).
^ permalink raw reply
* Re: Weird problem with long $PATH and alternates (bisected)
From: Junio C Hamano @ 2008-10-27 5:30 UTC (permalink / raw)
To: Mikael Magnusson; +Cc: Junio C Hamano, René Scharfe, Git Mailing List
In-Reply-To: <237967ef0810261129y58898019m503a1f1593a95591@mail.gmail.com>
"Mikael Magnusson" <mikachu@gmail.com> writes:
> 2008/10/26 Junio C Hamano <gitster@pobox.com>:
> ...
>> 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.
Thanks.
^ permalink raw reply
* Re: [PATCH v3 7/8] wt-status: load diff ui config
From: Junio C Hamano @ 2008-10-27 5:30 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Sixt, Matthieu Moy, git
In-Reply-To: <20081026044935.GG21047@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> But it makes me a little nervous. On one hand, I think it is definitely
> the right thing for "status -v" to respect user options. But we do
> several _other_ diffs in addition, and those are more "plumbing" diffs.
> I think they should probably at least have diff_basic_config (e.g., for
> rename limits). But we are applying the diff_ui_config options to all
> diffs. Looking over the available options, I _think_ there are no nasty
> surprises. But you never know.
Up to 6/8 are indisputably good changes. The next one means well, and
this one is a requisite step for it, but I agree that this feels somewhat
risky.
^ permalink raw reply
* Re: [PATCH 0/3] symref rename/delete fixes
From: Junio C Hamano @ 2008-10-27 5:31 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Jeff King, Brandon Casey, git
In-Reply-To: <cover.1224987944.git.vmiklos@frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> A symref-aware rename_ref() is needed by git remove rename, since it
> typically does origin/HEAD -> upstream/HEAD symref renames there.
>
> Of course you can say that this should be handled by git-remote itself,
> without using rename_ref() but that not seem to be a good solution to
> me. (Workaround in the wrong layer, instead of a solution in a good
> one.)
I do not think it is a workaround at all.
I would even say that the renaming of symref that "git remote rename"
needs to do is fundamentally different from what rename_ref() is about,
and trying to cram it into rename_ref() is a grave mistake.
If you "git remote rename origin upstream" when origin/HEAD points at
refs/remotes/origin/master, you need to make the renamed one point at
refs/remotes/upstream/master, as you will be renaming origin/master to
upstream/master.
Normal "rename_ref()" would just rename the ref without touching its
contents, and if you used it to implement "git remote rename", your
upstream/HEAD would point at the old name "origin/master" that will
disappear when rename is finished, wouldn't it? I do not think it is
useful.
There may be cases where you would really want to rename the symbolic ref
without changing its value (e.g. which other ref it points at), but as you
mentioned, even "git branch -m" is not such a usecase.
I think it is better to simply forbid renaming of a symref _until_ we know
what we want it to mean. It is a lot easier to start strict and then add
features, than start loosely and implement an unclean semantics, and then
having to fix that semantics after people start to rely on the initial
(potentially crazy) semantics.
^ permalink raw reply
* Re: [PATCH] Add support for uintmax_t type on FreeBSD 4.9
From: David Syzdek @ 2008-10-27 5:46 UTC (permalink / raw)
To: git
In-Reply-To: <9a0027270810262239r311074m51d382bdd95fd0dc@mail.gmail.com>
On Sun, Oct 26, 2008 at 9:30 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> "David M. Syzdek" <david.syzdek@acsalaska.net> writes:
>
> > This adds NO_UINTMAX_T for ancient systems. If NO_UINTMAX_T is defined, then
> > uintmax_t is defined as uint32_t. This adds a test to configure.ac for
> > uintmax_t and adds a check to the Makefile for FreeBSD 4.9-SECURITY.
> > ...
> > diff --git a/Makefile b/Makefile
> > index 0d40f0e..bf6a6dc 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -931,6 +931,9 @@ endif
> > ifdef NO_IPV6
> > BASIC_CFLAGS += -DNO_IPV6
> > endif
> > +ifdef NO_UINTMAX_T
> > + BASIC_CFLAGS += -Duintmax_t=uint32_t
> > +endif
>
> I have a stupid question.
>
> Would it be a more appropriate improvement to do it like this:
>
> ifdef USE_THIS_AS_UINTMAX_T
> BASIC_CFLAGS += -Duintmax_t="$(USE_THIS_AS_UINTMAX_T)"
> endif
>
> and then add a section for FreeBSD 4.9-SECURITY like this:
>
> ifeq ($(uname_R),4.9-SECURITY)
> USE_THIS_AS_UINTMAX_T = uint32_t
> endif
>
> That way, an oddball 64-bit machine can use uint64_t here if it wants to,
> possibly including FreeBSD 4.9-SECURITY backported to 64-bit ;-).
>
Your suggestion provides more flexibility for other environments. I
was making the assumption that 64-bit systems would define uintmax_t,
however in retrospect that would be unwise.
Would you like me to resubmit the patches with your modifications?
--
An earthquake wiped out Etchisketchistan today.
-- Onion TV
^ permalink raw reply
* Re: [PATCH] Add support for uintmax_t type on FreeBSD 4.9
From: Junio C Hamano @ 2008-10-27 6:17 UTC (permalink / raw)
To: David Syzdek; +Cc: git
In-Reply-To: <9a0027270810262246i56cf5515l5fa0875f91d90a7a@mail.gmail.com>
"David Syzdek" <syzdek@gmail.com> writes:
> On Sun, Oct 26, 2008 at 9:30 PM, Junio C Hamano <gitster@pobox.com> wrote:
> ...
>> I have a stupid question.
>>
>> Would it be a more appropriate improvement to do it like this:
>>
>> ifdef USE_THIS_AS_UINTMAX_T
>> BASIC_CFLAGS += -Duintmax_t="$(USE_THIS_AS_UINTMAX_T)"
>> endif
>>
>> and then add a section for FreeBSD 4.9-SECURITY like this:
>>
>> ifeq ($(uname_R),4.9-SECURITY)
>> USE_THIS_AS_UINTMAX_T = uint32_t
>> endif
>>
>> That way, an oddball 64-bit machine can use uint64_t here if it wants to,
>> possibly including FreeBSD 4.9-SECURITY backported to 64-bit ;-).
>>
>
> Your suggestion provides more flexibility for other environments. I
> was making the assumption that 64-bit systems would define uintmax_t,
> however in retrospect that would be unwise.
> Would you like me to resubmit the patches with your modifications?
Actually there was a reason why I said this was a "stupid" question. I
think your assumption on 64-bit platforms would hold in practice, and my
suggestion could be an unnecessary overengineering. If nobody knows of a
system that would benefit from such a generalization, your original patch
would be better, partly because I think:
(1) USE_THIS_AS_UINTMAX_T is just for demonstration of concept and is a
terrible name we cannot possibly use in our Makefile. We have to
spend brain cycles to come up with a better name; and
(2) It may be tricky to come up with autoconf macros to determine what to
set USE_THIS_AS_UINTMAX_T to.
As a slightly unrelated aside, I find it somewhat unfortunate that the
conditional says "4.9-SECURITY", which is a bit too explicit and specific.
to my taste. I do not know how FreeBSD versioning scheme works, but
wouldn't your change work equally well for 4.9-RELEASE or 4.11-RELEASE?
I suspect that you would want to say "$(uname_R) that begins with '4.' or
smaller needs this workaround", as strtoul(3) manual page seems to appear
first in FreeBSD 5.0-RELEASE (but not found in FreeBSD 4.11-RELEASE).
^ permalink raw reply
* Re: [PATCH] Add mksnpath and git_snpath which allow to specify the output buffer
From: Alex Riesen @ 2008-10-27 6:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Linus Torvalds
In-Reply-To: <7v8wsak4mr.fsf@gitster.siamese.dyndns.org>
Junio C Hamano, Mon, Oct 27, 2008 06:07:24 +0100:
> Where is git_snpath() used?
Nowhere yet, but it should replace git_path in every call where the
result is not used immediately. Which, as the story with cygwin
porting shows, can be sometimes not quite trivial (who could suspect
lstat(2) will have application local side effects?).
Maybe I should resend the patches without it, following by patches
introducing git_snpath and replacing calls to git_path.
Maybe Linus should be sued for introducing the function in the first
place.
^ permalink raw reply
* Re: [PATCH] Fix potentially dangerous uses of mkpath and git_path
From: Johannes Sixt @ 2008-10-27 7:08 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Junio C Hamano
In-Reply-To: <20081026220852.GC18594@blimp.localdomain>
Alex Riesen schrieb:
> Replace them with mksnpath/git_snpath and a local buffer
> for the resulting string.
You should describe your definition of "potentially dangerous" to save the
reader some time.
-- Hannes
^ permalink raw reply
* Re: [VOTE] git versus mercurial (for DragonflyBSD)
From: Arne Babenhauserheide @ 2008-10-27 7:16 UTC (permalink / raw)
To: SLONIK.AZ; +Cc: mercurial, Jakub Narebski, git
In-Reply-To: <ee2a733e0810262115h705356dfmbc2237f8e88f3985@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2642 bytes --]
Am Montag 27 Oktober 2008 05:15:11 schrieb Leo Razoumov:
> > I created a head-to-head code_swarm of Mercurial and Git and it clearly
> > shows that Mercurial development didn't slow down.
>
> I am not familiar with code swarms, sorry. My impressions are
> subjective are thoroughly un-scientific:-)
That's always the case with code_swarms.
They only show the commit activity: How often how many files where changed.
They aren't a fair comparision but a damn unfair battle relying strongly on
development style, programming language (influences the style) and such.
What you can see very clearly in them is how activity patterns _change_.
And the Mercurial activity doesn't slow down.
Instead in the beginning you can see them pacing each other, git always the
bigger activity.
There was a moment in may this year when git activity had receded to the point
where it was equal to Mercurials activity, but it recovered from that.
An artifact in Mercurial is that it took an almost two week break in July this
year, but apart from that development always rolled on, and in august the
commits where coming fast again.
The smaller activity can for example be a result of a development style where
changes are thouroughly discussed before they get implemented.
> (1) Judging by the activity of mailing lists git community is several
> times larger and more active in terms of actual submitted patches.
This is something which didn't change. Git had higher activity from the start,
yet Mercurials actual code paced it well and was faster at some things.
Git still has higher activity, but that can simply stem from Mercurial being
almost completely done in Python which need less code to do the same work.
> (2) Hg forest extension is still not in the tree with outdated and
> incorrect documentation in the wiki. For me it was biggest reason to
> migrate from Hg to git.
Why didn't you instead update the documentation in the wiki?
I don't use the forest extension, so I can't judge whether it is fit for
inclusion in the tree.
But I wrote the group extension and learned that way that writing Mercurial
extensions is far easier than I thought. And different from the shell, Python
code is platform independent.
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
* Re: [VOTE] git versus mercurial (for DragonflyBSD)
From: dhruva @ 2008-10-27 7:16 UTC (permalink / raw)
To: SLONIK.AZ; +Cc: Arne Babenhauserheide, mercurial, git, Jakub Narebski
In-Reply-To: <ee2a733e0810262115h705356dfmbc2237f8e88f3985@mail.gmail.com>
Hello,
On Mon, Oct 27, 2008 at 9:45 AM, Leo Razoumov <slonik.az@gmail.com> wrote:
> (2) Hg forest extension is still not in the tree with outdated and
> incorrect documentation in the wiki. For me it was biggest reason to
> migrate from Hg to git.
There are a few extensions that ought to be part of main hg, I have
proposed rdiff and am still waiting to hear. Since hg depends a lot on
extensions to extend it (good design), commnly used or useful
extensions must be made part of mainstream at a steady pace.
Otherwise, new users who are not aware of existence of various
extensions will start comparing main hg with git. Since git has most
of the features in the core part, hence the comparisons will be not
apple to apple.
-dhruva
--
Contents reflect my personal views only!
^ permalink raw reply
* Re: [VOTE] git versus mercurial (for DragonflyBSD)
From: Arne Babenhauserheide @ 2008-10-27 7:50 UTC (permalink / raw)
To: Jakub Narebski; +Cc: mercurial, SLONIK.AZ, git
In-Reply-To: <200810270252.23392.jnareb@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 7896 bytes --]
Am Montag 27 Oktober 2008 02:52:22 schrieb Jakub Narebski:
> On Mon, 27 Oct 2008, Arne Babenhauserheide wrote:
> > Am Sonntag 26 Oktober 2008 19:55:09 schrieb Jakub Narebski:
> > > 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.
> >
> > What do you mean by "cleaner design"?
>
> Clean _underlying_ design. Git has very nice underlying model of graph
> (DAG) of commits (revisions), and branches and tags as pointers to this
> graph.
>
> > From what I see (and in my definition of "design"), Mercurial is designed
> > as VCS with very clear and clean design, which even keeps things like
> > streaming disk access in mind.
>
> I have read description of Mercurial's repository format, and it is not
> very clear in my opinion. File changesets, bound using manifest, bound
> using changerev / changelog.
This grows very simple if you keep common filesystem layout in mind.
inodes and datanodes (the files in the store), organized in directories which
keep many files (manifests) bound in changesets which keep additional data.
> Mercurial relies on transactions and O_TRUNC support, while Git relies
> on atomic write and on updating data then updating reference to data.
For most operations Mercurial just relies on appending support.
> I don't quite understand comment about streaming disk access...
If you tell a disk "give me files a, b, c, d, e, f (of the whole abc)", it is
faster then if you tell it "give me files a k p q s t", because the filesystem
can easier optimize that call.
That's why for example Mercurial avoids hashing filenames.
> Well, they have to a lot less than they used to, and there is
> "git gc --auto" that can be put in crontab safely.
relying on crontab which might not be available in all systems (I only use
GNU/Linux, but what about friends of mine who have to use Windows?)
> Explicit garbage collection was a design _decision_, not a sign of not
> clear design. We can argue if it was good or bad decision, but one
> should consider the following issues:
>
> * Rolling back last commit to correct it, or equivalently amending
> last commit (for example because we forgot some last minute change,
> or forgot to signoff a commit), or backing out of changes to the
> last commit in Mercurial relies on transactions (and locking) and
> correct O_TRUNC, while in Git it leaves dangling objects to be
> garbage collected later.
As far as I know the only problem woth O_TRUNC was that it sadly had bugs in
Linux.
> * Mercurial relies on transaction support. Git relies on atomic write
> support and on the fact that objects are immutable; those that are
> not needed are garbage collected later. Beside IIRC some of ways of
> implementing transaction in databases leads to garbage collecting.
But Mercurial normally works on standard filesystems, so this isn't the case
for normal operations.
You culd say, though, that git implements a very simple transaction model:
Keep all old data until it gets purged explicitely.
> * Explicit packing and having two repository "formats": loose and
> packed is a bit of historical reason: at the beginning there was
> only loose format. Pack format was IIRC invented for network
> transport, and was used for on disk storage (the same format!) for
> better I/O patterns[1]. Having packs as 'rewrite to pack' instead
> of 'append to pack' allows to prefer recency order, which result in
> faster access as objects from newer commits are earlier in delta
> chain and reduction in size in usual case of size growing with time
> as recency order allows to use delete deltas. Also _choosing_ base
> object allows further reduce size, especially in presence of
> nonlinear history.
So having multiple packs is equivalent to the automatic snapshot system in
Mercurial which doesn't need user interaction.
> * From what I understand Mercurial by default uses packed format for
> branches and tags; Git uses "loose" format for recent branches
> (meaning one file per branch), while packing older references.
> Using loose affects performance (and size) only for insane number of
> references, and only for some operations like listing all references,
> while using packed format is IMHO a bit error prone when updating.
As far as I know, Mercurial got that "using packed format" right from the
beginning.
> * Git has reflogs which are pruned (expired) during garbage collecting
> to not grow them without bounds; AFAIK Mercurial doesn't have
> equivalent of this feature.
>
> (Reflogs store _local_ history of branch tip, noting commits,
> fetches, merges, rewinding branch, switching branches, etc._
As far as I know Mercurial only tracks the state of the working directory, so
it doesn't track your whole local history.
But others can better tell you more about that in greater detail.
> [1] You wrote about "streaming disk access". Git relies (for reading)
> on good mmap implementation.
>
> > In git is has to check all changesets which affect the file.
>
> I don't understand you here... if I understand correctly above,
> then you are wrong about Git.
Might be that I remember incorrectly about what git does.
Are its commits "the whole changed file" or "the diff of the changes"?
If the latter, it needs to walk back all commits to the snapshot revision to
get the file data.
One story I experienced with that:
My amd64 GNU/Linux box suffers from performance problems when it gets high
levels of disk activity (something about the filesystem layer doesn't play
well with amd64 - reported by others, too).
When I pulled a the Linux kernel repository with git half a year ago, my disk
started klicking and the whole computer slowed down to a crawl.
When I pulled the same repository data from a Mercurial repository, the
computer kept running smooth, the disk stayed silent and happily wrote the
data.
Mercurial felt smooth, while git felt damn clumsy (though not slow).
> > 1) Hg is easy to understand
>
> Because it is simple... and less feature rich, c.f. multiple local
> branches in single repository.
That works quite well. People just don't use it very often, because the
workflow of having multiple repositories is easier with hg.
> > 2) You don't have to understand it to use it
>
> You don't have to understand details of Git design (pack format, index,
> stages, refs,...) to use it either.
I remember that to have been incorrect about half a year ago, when I stumbled
over many problems in git whenever I tried to do something a bit nonstandard.
It took me hours (and in the end asking a friend) to find out about
"git checkout ."
just to get back my deleted files.
The answer I got when I asked why it's done that way was "this is because of
the inner workings of git. You should know them if you use it".
> > And both are indications of a good design, the first of the core, the
> > second of the UI.
>
> Well, Git is built around concept of DAG of commits and branches as
> references to it. Without it you can use Git, but it is hard. But
> if you understand it, you can understand easily most advanced Git
> features.
>
> I agree that Mercurial UI is better; as usually in "Worse is Better"
> case... :-)
What do you mean with that?
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
* Re: [msysGit] Re: Weird filename encoding issue
From: Peter Krefting @ 2008-10-27 8:08 UTC (permalink / raw)
To: Robin Rosenberg
Cc: msysgit, Johannes Sixt, Alexander Gladysh, Git Mailing List
In-Reply-To: <200810180458.53853.robin.rosenberg@gmail.com>
Robin Rosenberg:
> Git (or msys) under windows is somewhat stupid here as it involves
> the eight-bit locale despite running in a unicode OS. To get UTF-8 on
> XP you can set the codepage to UTF-8 (called 65001 in windows).
That presents itself with a lot of other issues, however, as the
char-based file APIs were only designed to handle up to double-byte
characters. To implement proper Unicode file name support on Windows,
one need to use the "wide" APIs (using wchar_t).
Using those APIs, it does not matter what locale the system is set to.
Everything is then UTF-16, which is trivially converted to and from
UTF-8 (and there are even native APIs to do it if one can't be bothered
to write code for it).
I have been meaning to check out a copy of the Msysgit source tree and
see how difficult it would be to replace the file API layer with proper
Unicode support, but time keeps fleeing from me, so I never seem to get
around to :-/
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: [PATCH v3 7/8] wt-status: load diff ui config
From: Jeff King @ 2008-10-27 8:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, Matthieu Moy, git
In-Reply-To: <7vmygqiozb.fsf@gitster.siamese.dyndns.org>
On Sun, Oct 26, 2008 at 10:30:48PM -0700, Junio C Hamano wrote:
> > But it makes me a little nervous. On one hand, I think it is definitely
> > the right thing for "status -v" to respect user options. But we do
> > several _other_ diffs in addition, and those are more "plumbing" diffs.
> > I think they should probably at least have diff_basic_config (e.g., for
> > rename limits). But we are applying the diff_ui_config options to all
> > diffs. Looking over the available options, I _think_ there are no nasty
> > surprises. But you never know.
>
> Up to 6/8 are indisputably good changes. The next one means well, and
> this one is a requisite step for it, but I agree that this feels somewhat
> risky.
I have to wonder that nobody ever complained about the lack of diff
config here before. If I ever used "git status -v", I would certainly
have been turned off by the lack of color. But maybe everybody is using
"git commit -v" and their editor is colorizing it. Or maybe they just
aren't using color (the only other noticeable thing would be rename
options).
-Peff
^ permalink raw reply
* Re: [PATCH] Fix potentially dangerous uses of mkpath and git_path
From: Alex Riesen @ 2008-10-27 8:30 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Junio C Hamano
In-Reply-To: <490568F5.9060206@viscovery.net>
2008/10/27 Johannes Sixt <j.sixt@viscovery.net>:
> Alex Riesen schrieb:
>> Replace them with mksnpath/git_snpath and a local buffer
>> for the resulting string.
>
> You should describe your definition of "potentially dangerous" to save the
> reader some time.
>
Yeah. Thought it was obvious. Will do.
^ permalink raw reply
* Re: [PATCH 0/3] symref rename/delete fixes
From: Miklos Vajna @ 2008-10-27 8:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Brandon Casey, git
In-Reply-To: <7vhc6yioyq.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1215 bytes --]
On Sun, Oct 26, 2008 at 10:31:09PM -0700, Junio C Hamano <gitster@pobox.com> wrote:
> > Of course you can say that this should be handled by git-remote itself,
> > without using rename_ref() but that not seem to be a good solution to
> > me. (Workaround in the wrong layer, instead of a solution in a good
> > one.)
>
> I do not think it is a workaround at all.
>
> I would even say that the renaming of symref that "git remote rename"
> needs to do is fundamentally different from what rename_ref() is about,
> and trying to cram it into rename_ref() is a grave mistake.
>
> If you "git remote rename origin upstream" when origin/HEAD points at
> refs/remotes/origin/master, you need to make the renamed one point at
> refs/remotes/upstream/master, as you will be renaming origin/master to
> upstream/master.
>
> Normal "rename_ref()" would just rename the ref without touching its
> contents, and if you used it to implement "git remote rename", your
> upstream/HEAD would point at the old name "origin/master" that will
> disappear when rename is finished, wouldn't it? I do not think it is
> useful.
Ah, I missed that. You convienced me, I'll post updated patches later
today. :)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [VOTE] git versus mercurial (for DragonflyBSD)
From: Benoit Boissinot @ 2008-10-27 9:29 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Arne Babenhauserheide, SLONIK.AZ, mercurial, git
In-Reply-To: <200810270252.23392.jnareb@gmail.com>
On Mon, Oct 27, 2008 at 2:52 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Mon, 27 Oct 2008, Arne Babenhauserheide wrote:
>> Am Sonntag 26 Oktober 2008 19:55:09 schrieb Jakub Narebski:
>> >
>> > 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.
>>
>> What do you mean by "cleaner design"?
>
> Clean _underlying_ design. Git has very nice underlying model of graph
> (DAG) of commits (revisions), and branches and tags as pointers to this
> graph.
Git and Mercurial are very close from that point of view.
Mercurial explicitely disallow octopus merges (and we don't think there's
a good reason to allow them, although I agree with Linus, they look very nice
in gitk ;) ).
And we don't have "branches as pointer" in core, but the bookmark extension does
that.
Appart from that I think the underlying format are interchangeable, someone
could use the git format with the hg ui, or use revlogs (the basic
format of mercurial)
like packs.
The only special thing about revlogs is the linkrev stuff, it's a
pointer to the first revision
that introduced an object, so we can easily find what to send in our
network protocol
(we don't have to read the manifest, ie the "tree" of objects").
linkrev can be useful
to speedup "hg log" too.
> I have read description of Mercurial's repository format, and it is not
> very clear in my opinion. File changesets, bound using manifest, bound
> using changerev / changelog.
>
just do a s/// with the git terminology:
filelog -> blob
manifest -> tree
changelog -> commit object
regards,
Benoit
^ permalink raw reply
* Re: [VOTE] git versus mercurial (for DragonflyBSD)
From: Jakub Narebski @ 2008-10-27 9:41 UTC (permalink / raw)
To: Arne Babenhauserheide; +Cc: mercurial, SLONIK.AZ, git
In-Reply-To: <200810270850.09696.arne_bab@web.de>
On Mon, 27 Oct 2008, Arne Babenhauserheide wrote:
> Am Montag 27 Oktober 2008 02:52:22 schrieb Jakub Narebski:
>> On Mon, 27 Oct 2008, Arne Babenhauserheide wrote:
>>> Am Sonntag 26 Oktober 2008 19:55:09 schrieb Jakub Narebski:
>>>>
>>>> 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.
>>>
>>> What do you mean by "cleaner design"?
>>> From what I see (and in my definition of "design"), Mercurial is designed
>>> as VCS with very clear and clean design, which even keeps things like
>>> streaming disk access in mind.
>>
>> I have read description of Mercurial's repository format, and it is not
>> very clear in my opinion. File changesets, bound using manifest, bound
>> using changerev / changelog.
>
> This grows very simple if you keep common filesystem layout in mind.
>
> inodes and datanodes (the files in the store), organized in directories which
> keep many files (manifests) bound in changesets which keep additional data.
Well, for you it might be simple, for others it is binding things
together with duct tape and spit. (I am exaggerating here).
What Mercurial repository design did not get correctly, in my opinion
is its handling of tags and [named] branches.
>> I don't quite understand comment about streaming disk access...
>
> If you tell a disk "give me files a, b, c, d, e, f (of the whole abc)", it is
> faster then if you tell it "give me files a k p q s t", because the filesystem
> can easier optimize that call.
I would expect _good_ filesystem to be able to optimize this call as
well. As I said it looks like Mercurial and Git are optimized for
different cases: Git relies on filesystem for caching, and optimizes
for warm cache performance.
>
> That's why for example Mercurial avoids hashing filenames.
First, git does not hash filenames. The hash is contents, not of name.
You can say it stores objects (in loose format) in hash-based filenames.
Second, in packed repository you don't have to ask filesystem to "give
me files a, k, p, q, s, t (of the whole abc)"; you ask filesystem to
mmap a _single_ pack file (well, almost, there is also pack index to
mmap).
Yes, that means that you should periodically repack for better
performance... but currently git tries to use packed format as much
as possible, keeping packs from network if they are not too small,
repacking if creating large number of objects, etc.
>> Well, they have to a lot less than they used to, and there is
>> "git gc --auto" that can be put in crontab safely.
>
> relying on crontab which might not be available in all systems (I only use
> GNU/Linux, but what about friends of mine who have to use Windows?)
So they would have to either periodically repack by hand, or use some
crontab equivalent on MS Windows.
But that doesn't matter in the context of this discussion, which is
DragonflyBSD; worse or better support for MS Windows doesn't matter
here, does it?
>
>> Explicit garbage collection was a design _decision_, not a sign of not
>> clear design. We can argue if it was good or bad decision, but one
>> should consider the following issues:
>>
>> * Rolling back last commit to correct it, or equivalently amending
>> last commit (for example because we forgot some last minute change,
>> or forgot to signoff a commit), or backing out of changes to the
>> last commit in Mercurial relies on transactions (and locking) and
>> correct O_TRUNC, while in Git it leaves dangling objects to be
>> garbage collected later.
>
> As far as I know the only problem with O_TRUNC was that it sadly had bugs in
> Linux.
>
>> * Mercurial relies on transaction support. Git relies on atomic write
>> support and on the fact that objects are immutable; those that are
>> not needed are garbage collected later. Beside IIRC some of ways of
>> implementing transaction in databases leads to garbage collecting.
>
> But Mercurial normally works on standard filesystems, so this isn't the case
> for normal operations.
Mercurial implements transactions as a way to keeping operations atomic.
So I don't know what you mean by "normally works on standard filesystem"
here.
>
> You could say, though, that git implements a very simple transaction model:
> Keep all old data until it gets purged explicitely.
Git just uses different way to keep operations atomic, different way
of implementing transactions.
I'm not sure if I should have mentioned transactions in databases here.
Oh, well... Note however that there are advanced way of doing
transactions in relational databases which lead to dangling things
to be purged when transaction is interrupted. But this is not to the
point...
>
>> * Explicit packing and having two repository "formats": loose and
>> packed is a bit of historical reason: at the beginning there was
>> only loose format. Pack format was IIRC invented for network
>> transport, and was used for on disk storage (the same format!) for
>> better I/O patterns[1]. Having packs as 'rewrite to pack' instead
>> of 'append to pack' allows to prefer recency order, which result in
>> faster access as objects from newer commits are earlier in delta
>> chain and reduction in size in usual case of size growing with time
>> as recency order allows to use delete deltas. Also _choosing_ base
>> object allows further reduce size, especially in presence of
>> nonlinear history.
>
> So having multiple packs is equivalent to the automatic snapshot system in
> Mercurial which doesn't need user interaction.
Snapshot system doesn't change the fact that Mercurial (from what I
understand) implements forward deltas, from older version to never
version, and not from newer version to older.
Also from what I remember Mercurial didn't implement deltification
right from the start; it had problems with nonlinear history (it used
delta from last version appended, not from the parent version).
>> * From what I understand Mercurial by default uses packed format for
>> branches and tags; Git uses "loose" format for recent branches
>> (meaning one file per branch), while packing older references.
>> Using loose affects performance (and size) only for insane number of
>> references, and only for some operations like listing all references,
>> while using packed format is IMHO a bit error prone when updating.
>
> As far as I know, Mercurial got that "using packed format" right from the
> beginning.
And probably requires transactions and locks for that. Git simply uses
atomic write solution for atomic update of references.
>
>> * Git has reflogs which are pruned (expired) during garbage collecting
>> to not grow them without bounds; AFAIK Mercurial doesn't have
>> equivalent of this feature.
>>
>> (Reflogs store _local_ history of branch tip, noting commits,
>> fetches, merges, rewinding branch, switching branches, etc._
>
> As far as I know Mercurial only tracks the state of the working directory, so
> it doesn't track your whole local history.
>
> But others can better tell you more about that in greater detail.
Reflogs are very useful, and are natural extension of simple rollback
last transaction Mercurial has (which Git had equivalent from the very
beginning in the form of ORIG_HEAD). They allow for example for you
go back to the state before incorrect rewinding a branch, or before
applying series of patches from email, etc.
>> [1] You wrote about "streaming disk access". Git relies (for reading)
>> on good mmap implementation.
>>
>>> In git is has to check all changesets which affect the file.
>>
>> I don't understand you here... if I understand correctly above,
>> then you are wrong about Git.
>
> Might be that I remember incorrectly about what git does.
>
> Are its commits "the whole changed file" or "the diff of the changes"?
>
> If the latter, it needs to walk back all commits to the snapshot revision to
> get the file data.
Git is snapshot based SCM, although 'behind the scenes' it uses deltas
in the pack format. So to get file data at given revision (i.e. to do
something like "git show <revision>:<filename>") it needs to access
<revision>, access its tree, and access contents of a file (blob).
Behind the scenes, at a lower level, Git does necessary delta resolving.
Delta chains in packs have limited length (as they have in Mercurial).
> One story I experienced with that:
>
> My amd64 GNU/Linux box suffers from performance problems when it gets high
> levels of disk activity (something about the filesystem layer doesn't play
> well with amd64 - reported by others, too).
>
> When I pulled a the Linux kernel repository with git half a year ago, my disk
> started klicking and the whole computer slowed down to a crawl.
>
> When I pulled the same repository data from a Mercurial repository, the
> computer kept running smooth, the disk stayed silent and happily wrote the
> data.
>
> Mercurial felt smooth, while git felt damn clumsy (though not slow).
The answer usually is: did you have this repository packed? I admit
that it might be considered one of disadvantages of git, this having
to do garbage collection from time to time... just like in C ;-)
>>> 1) Hg is easy to understand
>>
>> Because it is simple... and less feature rich, c.f. multiple local
>> branches in single repository.
>
> That works quite well. People just don't use it very often, because the
> workflow of having multiple repositories is easier with hg.
Workflow of having multiple repositories, or one branch per repository,
is IMHO as simple in Git as in Mercurial, and as in Bazaar-NG.
>>> 2) You don't have to understand it to use it
>>
>> You don't have to understand details of Git design (pack format, index,
>> stages, refs,...) to use it either.
>
> I remember that to have been incorrect about half a year ago, when I stumbled
> over many problems in git whenever I tried to do something a bit nonstandard.
>
> It took me hours (and in the end asking a friend) to find out about
>
> "git checkout ."
>
> just to get back my deleted files.
>
> The answer I got when I asked why it's done that way was "this is because of
> the inner workings of git. You should know them if you use it".
Well, understanding "git checkout ." doesn't require understanding
inner workings of git. Your friend was incorrect here. I'll agree
though that it is a bit of quirk in UI[1] (but I use usually
"git reset --hard" to reset to last committed state).
[1] Having git-checkout behave very differently with and without
pathname parameter, and overloading of git-checkout.
>>> And both are indications of a good design, the first of the core, the
>>> second of the UI.
>>
>> Well, Git is built around concept of DAG of commits and branches as
>> references to it. Without it you can use Git, but it is hard. But
>> if you understand it, you can understand easily most advanced Git
>> features.
>>
>> I agree that Mercurial UI is better; as usually in "Worse is Better"
>> case... :-)
>
> What do you mean with that?
Just Google for "Worse is Better". But what I actually mean that Git
feature set and UI has evolved from very bare-bones plumbing, adding
features and UI _as needed_, instead of being designed according to
what designer thought it was needed.
For example in http://gitster.livejournal.com/9970.html Junio C Hamano
(git maintainer) writes:
By the time the basic structure as we currently know has stabilized,
we had help from literally dozens of contributors to add many things
on top of the very original version:
[...]
* We did not envision that multiple branches in a single repository
would turn out to be such a useful way to work, and did not have
support for switching branches.
[...]
It still is amazing that all of these were done without having to go
back to the drawing board. It shows how sound the initial conceptual
design was.
P.S. See "Innovations in git", http://gitster.livejournal.com/16077.html
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] Teach/Fix pull/fetch -q/-v options
From: Nanako Shiraishi @ 2008-10-27 10:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Tuncer Ayaz, git
In-Reply-To: <1224606624-5082-1-git-send-email-tuncer.ayaz@gmail.com>
Quoting Tuncer Ayaz <tuncer.ayaz@gmail.com>:
> After fixing clone -q I noticed that pull -q does not do what
> it's supposed to do and implemented --quiet/--verbose by
> adding it to builtin-merge and fixing two places in builtin-fetch.
Junio, may I ask what the status of this patch is? Maybe the patch was lost in the noise? The commit log message is written very differently from existing commits in the history of git, and I am thinking that maybe that is why you did not like the whole patch? Or is it lack of any test script?
I like what the quiet option to git-pull does, even though I do not care too much about the verbose option myself.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [VOTE] git versus mercurial (for DragonflyBSD)
From: Arne Babenhauserheide @ 2008-10-27 10:14 UTC (permalink / raw)
To: Jakub Narebski; +Cc: mercurial, SLONIK.AZ, git
In-Reply-To: <200810271041.54511.jnareb@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4660 bytes --]
Am Montag 27 Oktober 2008 10:41:53 schrieb Jakub Narebski:
> > If you tell a disk "give me files a, b, c, d, e, f (of the whole abc)",
> > it is faster then if you tell it "give me files a k p q s t", because the
> > filesystem can easier optimize that call.
>
> I would expect _good_ filesystem to be able to optimize this call as
> well. As I said it looks like Mercurial and Git are optimized for
> different cases: Git relies on filesystem for caching, and optimizes
> for warm cache performance.
The problem is by which knowledge the filesystem should optimize this call
when it is storing the files in the first place.
> > relying on crontab which might not be available in all systems (I only
> > use GNU/Linux, but what about friends of mine who have to use Windows?)
>
> But that doesn't matter in the context of this discussion, which is
> DragonflyBSD; worse or better support for MS Windows doesn't matter
> here, does it?
It only matters, if some developers are forced to work on WIndows machines at
times.
> > But Mercurial normally works on standard filesystems, so this isn't the
> > case for normal operations.
>
> Mercurial implements transactions as a way to keeping operations atomic.
> So I don't know what you mean by "normally works on standard filesystem"
> here.
I just meant "databases are a bit off topic" :)
> > You could say, though, that git implements a very simple transaction
> > model: Keep all old data until it gets purged explicitely.
>
> Git just uses different way to keep operations atomic, different way
> of implementing transactions.
That's what I wanted to express.
> And probably requires transactions and locks for that. Git simply uses
> atomic write solution for atomic update of references.
Doesn't atomic write also need locks, though on a lower level (to ensure
atomicity)?
> Behind the scenes, at a lower level, Git does necessary delta resolving.
> Delta chains in packs have limited length (as they have in Mercurial).
So both do snapshots - they seem more and more similar to me :)
> The answer usually is: did you have this repository packed? I admit
> that it might be considered one of disadvantages of git, this having
> to do garbage collection from time to time... just like in C ;-)
I cloned from the official repositories.
I hope Linus had his repository packed :)
> Well, understanding "git checkout ." doesn't require understanding
> inner workings of git. Your friend was incorrect here. I'll agree
> though that it is a bit of quirk in UI[1] (but I use usually
> "git reset --hard" to reset to last committed state).
Damn - one more way how I could have archieved what I wanted... one more way I
didn't find.
> Just Google for "Worse is Better". But what I actually mean that Git
> feature set and UI has evolved from very bare-bones plumbing, adding
> features and UI _as needed_, instead of being designed according to
> what designer thought it was needed.
And that's how it feels to me.
A great testing ground, but it developed too many stumbling blocks which keep
me from trying things.
When I now use git, I only do the most basic operations: clone, pull, push,
add, commit, checkout. When anything else arises, I check if it is worth the
risk of having to read up for hours - and since that wasn't the case for the
last few months, I then just ignore the problem or ask someone else if he can
fix it.
As a contrast, when I encounter a problem with Mercurial, I simply check the
commands for a moment and then try to solve it, and normally I have what I
wanted within seconds to minutes.
Git instead bit me once too often.
I know that this isn't something which hits everyone and that it is
subjective, but since it hit me, I'm wary of git, because in my view it isn't
something for the majority of people - and you almost always have someone from
that "majority" in your project.
I don't want people getting afraid of solving their own problems, so I avoid
systems which bite so often, that they create fear (for example of losing much
time on something which should be a side issue).
All in all it's a UI issue - while the git UI bit me quite often, the
Mercurial UI just works.
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
* Re: [PATCH] Only update the cygwin-related configuration during state auto-setup
From: Nanako Shiraishi @ 2008-10-27 10:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Riesen, Mark Levedahl, spearce, dpotapov, git
In-Reply-To: <7viqri35dq.fsf@gitster.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com>:
> This is the answer to the question I asked in:
>
> http://thread.gmane.org/gmane.comp.version-control.git/97986/focus=98066
>
> Perhaps we should use a separate variable as the original patch did, in:
>
> http://article.gmane.org/gmane.comp.version-control.git/97987
>
> How about doing it like this instead?
Junio, may I ask what the status of this patch is? I see you did not write tests nor commit message --- are you waiting for others to write them?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ 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