* Re: git-fetch per-repository speed issues
From: Andreas Ericsson @ 2006-07-04 11:10 UTC (permalink / raw)
To: Keith Packard; +Cc: Linus Torvalds, Junio C Hamano, git
In-Reply-To: <1151987441.4723.110.camel@neko.keithp.com>
Keith Packard wrote:
> On Mon, 2006-07-03 at 20:40 -0700, Linus Torvalds wrote:
>
>
>> "And, it's painfully slow, even when the repository is up to date"
>>
>>and gave a 17-second time.
>
>
> It's faster this evening, down to 8 seconds using ssh and 4 seconds
> using git. I clearly need to force use of the git protocol. Anyone else
> like the attached patch?
Since it changes the current meaning of ssh+git, I'm not exactly
thrilled. However, "git/ssh" or "ssh/git" would work fine for me. The
slash-separator could be used to say "fetch over this, push over that",
so we can end up with any valid protocol to use for fetches and another
one to push over.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] Additional merge-base tests
From: Jakub Narebski @ 2006-07-04 11:16 UTC (permalink / raw)
To: git
In-Reply-To: <7vsllhhcxr.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> The problem ALASCM's example demonstrates does rely on clock
> skews. The timestamps used in the example looked like this:
>
>
> 1 1
> / \/ \
> 4 -1 4
> | | |
> 3 -2 3
> | | |
> 2 -3 2
> \ | /
> 0
>
> The crucial clock skew the case relies on is that the tip of the
> middle branch (-1) is older than the common commit (0). But the
> topmost commits with timestamp 1 could be with timestamp 5 to
> correct the clock skew and still make the example "fail".
>
> 5 5
> / \/ \
> 4 -1 4
> | | |
> 3 -2 3
> | | |
> 2 -3 2
> \ | /
> 0
So would putting timestamp for merge be MAX(now, parents timestamps)
solve the problem?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Teach rev-parse the ... syntax.
From: Santi @ 2006-07-04 11:17 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List, Junio C. Hamano
In-Reply-To: <Pine.LNX.4.63.0607041247200.29667@wbgn013.biozentrum.uni-wuerzburg.de>
2006/7/4, Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> Hi,
>
> On Tue, 4 Jul 2006, Santi Béjar wrote:
>
> > + struct commit_list *exclude = get_merge_bases(a, b,1);
>
> You never free_commit_list() exclude.
>
Ups! But thanks to Junio it is already there :)
Santi
--
Looking for signature...
Looking for signature...done
^ permalink raw reply
* Re: git-fetch per-repository speed issues
From: Matthias Kestenholz @ 2006-07-04 11:18 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <44AA4CB0.7020604@op5.se>
* Andreas Ericsson (ae@op5.se) wrote:
> Keith Packard wrote:
> >On Mon, 2006-07-03 at 20:40 -0700, Linus Torvalds wrote:
> >
> >
> >> "And, it's painfully slow, even when the repository is up to date"
> >>
> >>and gave a 17-second time.
> >
> >
> >It's faster this evening, down to 8 seconds using ssh and 4 seconds
> >using git. I clearly need to force use of the git protocol. Anyone else
> >like the attached patch?
>
> Since it changes the current meaning of ssh+git, I'm not exactly
> thrilled. However, "git/ssh" or "ssh/git" would work fine for me. The
> slash-separator could be used to say "fetch over this, push over that",
> so we can end up with any valid protocol to use for fetches and another
> one to push over.
>
If we would do such a thing, we would be probably better off
allowing different URLs for pushing and pulling, because the git and
ssh URLs will only be the same, if the git repositories are located
in the root folder and I suspect that's almost never the case.
Matthias
^ permalink raw reply
* Re: qgit idea: interface for cherry-picking
From: Marco Costalba @ 2006-07-04 11:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jakub Narebski
In-Reply-To: <7vk66tna71.fsf@assigned-by-dhcp.cox.net>
On 7/4/06, Junio C Hamano <junkio@cox.net> wrote:
> "Marco Costalba" <mcostalba@gmail.com> writes:
>
>
> Yes, either you (1) need to make sure the user is aware what
> underlying git commands QGit runs for them, so that the user
> knows what workflow to follow when the procedure needs to go
> manual, or (2) hide the underlying git commands QGit runs for
> users, but then you need to make QGit aware of what workflow to
> follow when the procedure needs to go manual, and guide the user
> through that workflow. I think either is fine approach;
> personally I prefer transparent tools that does (1), which is
> the impression I am getting from your description of QGit.
>
Yes, I prefer way (1) too. QGit as an error reporting infrastructure
to always report by a message box arguments (starting from 0) of
offending command, be it native git or not.
> If you take route (1), using "am --fail" number of times
> involves QGit runs "am --fail" once, guide user to fix things up
> _and_ give control back to QGit, then you run the next "am
> --fail", etc, which would be quite cumbersome to implement. But
> running multiple am and do reset soft to roll back needed number
> of parents might be easier option to implement in QGit, but you
> still have the same "you give the control to the user but then
> you have to take the control away to proceed" problem when the
> patch does not apply cleanly somewhere (you let the user to hand
> resolve and say "am --resolved", but then when the series is
> depleted, somebody has to run "reset --soft" to roll N commits
> back to realize what you wanted to do, so at that point QGit
> somehow needs to take control back).
>
>
I have started to implement the feature suggested by Jakub (patch in
working dir only, not committed). The core is a loop of git-am, one
for each patch to import, followed by a:
git-reset --mixed HEAD~<Num of succesfully applied patches>
To note that the above git-reset command is _always_ run be the patch
series apply successfully be it fails at some point, so that in any
case the tree is not dirty up, and you have the working tree with the
information you need in case of manual fixup.
I will plan to push as soon I'm able to reach a "pushable site" ;-)
Comments? could work? not consistent?
Marco
^ permalink raw reply
* Re: contrib/ status
From: Jakub Narebski @ 2006-07-04 11:26 UTC (permalink / raw)
To: git
In-Reply-To: <7vmzbrwi3c.fsf_-_@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> OTOH I haven't seen much interest in contrib/colordiff, now
> Johannes's built-in "diff --color" is in. So if people do not
> mind, I'd like to drop it.
Since when, and is it documented?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git-cvsimport gets parents wrong for branches
From: Johannes Schindelin @ 2006-07-04 11:33 UTC (permalink / raw)
To: Elrond; +Cc: Martin Langhoff, git
In-Reply-To: <20060704110313.GC24572@memak.tu-darmstadt.de>
Hi,
On Tue, 4 Jul 2006, Elrond wrote:
> On Tue, Jul 04, 2006 at 10:09:18AM +0200, Johannes Schindelin wrote:
> > Hi,
> >
> > On Tue, 4 Jul 2006, Martin Langhoff wrote:
> >
> > > It is pretty hard to get that one right in any case, as there are
> > > cases where the new branch starts from something that is not a commit
> > > in the parent (from GIT's perspective).
> >
> > But it should be easy to introduce a faked commit, which just contains
> > those versions (and takes the newest commit touching any of these file
> > versions as branch point).
>
> [...]
>
> just which parent should our new fake commit have?
That is what I tried to address with the "branch point" thing. Just take
the newest commit (in the ancestor line) touching the file versions of
that particular tree, or in other words, the oldest commit having at least
these file versions.
IMHO it is dumb enough not to branch off of a commit that it does not
matter that much what parent this faked commit has.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Additional merge-base tests
From: Johannes Schindelin @ 2006-07-04 11:35 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e8dim7$8cm$1@sea.gmane.org>
Hi,
On Tue, 4 Jul 2006, Jakub Narebski wrote:
> Junio C Hamano wrote:
>
>
> > The problem ALASCM's example demonstrates does rely on clock
> > skews. The timestamps used in the example looked like this:
> >
> >
> > 1 1
> > / \/ \
> > 4 -1 4
> > | | |
> > 3 -2 3
> > | | |
> > 2 -3 2
> > \ | /
> > 0
> >
> > The crucial clock skew the case relies on is that the tip of the
> > middle branch (-1) is older than the common commit (0). But the
> > topmost commits with timestamp 1 could be with timestamp 5 to
> > correct the clock skew and still make the example "fail".
> >
> > 5 5
> > / \/ \
> > 4 -1 4
> > | | |
> > 3 -2 3
> > | | |
> > 2 -3 2
> > \ | /
> > 0
>
> So would putting timestamp for merge be MAX(now, parents timestamps)
> solve the problem?
If there is an evil committer, the parents could have bogus timestamps,
too. But then, I would not pull from such an evil person...
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Additional merge-base tests
From: Johannes Schindelin @ 2006-07-04 11:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: gitzilla, git
In-Reply-To: <7vsllhhcxr.fsf@assigned-by-dhcp.cox.net>
Hi,
On Tue, 4 Jul 2006, Junio C Hamano wrote:
> However, I am not sure how you are going to use that maximumSkew
> variable.
My idea was to continue traversing the merge base's ancestors, marking
them UNINTERESTING, until hitting a commit which is maximumSkew older than
the merge base (and not just stop at the merge base, as is the case right
now, and neither continue traversing in eternity like suggested).
This would not help _evil_ cases (i.e. intentional), but most certainly
your regular clock skew in a Microsoft network.
Ciao,
Dscho
^ permalink raw reply
* Re: contrib/ status
From: Johannes Schindelin @ 2006-07-04 11:43 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e8dj9u$asn$1@sea.gmane.org>
Hi,
On Tue, 4 Jul 2006, Jakub Narebski wrote:
> Junio C Hamano wrote:
>
> > OTOH I haven't seen much interest in contrib/colordiff, now
> > Johannes's built-in "diff --color" is in. So if people do not
> > mind, I'd like to drop it.
>
> Since when, and is it documented?
To your first question:
commit cd112cef999c59a7ca2a96c37b197d303a355924
Author: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Date: Tue Jun 13 18:45:44 2006 +0200
diff options: add --color
To the second:
No.
;-) It should be in diff-options.txt, but then you would have to document
the config variables to change the color, too, so I'll leave that task to
somebody else and go back to work...
Ciao,
Dscho
^ permalink raw reply
* Re: qgit idea: interface for cherry-picking
From: Marco Costalba @ 2006-07-04 11:58 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Junio C Hamano
In-Reply-To: <e8d2eo$k44$1@sea.gmane.org>
On 7/4/06, Jakub Narebski <jnareb@gmail.com> wrote:
> Marco Costalba wrote:
>
> > QGit is not supposed to be a GUI replacement of git UI. QGit only let
> > users quickly call some commonly used commands. [...]
>
> It's a pity. Doing some of commands from visual history viewer, with view of
> branches etc. would be so much easier: like bisect, rebasing, cherry
> picking, reverting a commit...
>
In the past weeks I (with Pavel support) have implemented and pushed
the concept of "custom actions".
Is it possible to associate commands sequences, scripts and anything
else executable to a custom action. Actions can be called and run from
menu entry and corresponding output is grabbed by a terminal window.
Instead of hard code each git-native command, this way you have a
flexible framework to add shortcuts and menu entry for anything you
would like to be a click away. BTW I use this for stuff like git pull,
but also for 'make' and 'make install' because you have a window
terminal for feedback.
There is also the possibility to input command line parameters before
to run, useful, as example for a git pull action that asks for source
repository to pull from.
Is this something that can fulfill you request? do you need something
different? perhaps something as a "default to current selected SHA as
input argument" flag.
Marco
^ permalink raw reply
* Re: qgit idea: marking refs (heads and tags)
From: Marco Costalba @ 2006-07-04 12:03 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e8d3i6$ne9$1@sea.gmane.org>
On 7/4/06, Jakub Narebski <jnareb@gmail.com> wrote:
> One thing I sorely lack in qgit as compared to gitk (and even gitweb[*1*])
> is marking commits with refs (heads and tags, marked with different colors
> or different shape marker). gitk currently uses markers in short log line
> before text of commit summary, gitweb uses markers after (at the end) of
> commit log summary. In qgit head commits are marked as such, but not to
> which branche they belong[*2*].
Currently you have to select the head and the status bar will show
related information: branch, tag message, etc.
>
> And also somewhat (but to much lesser extent) showing explicitely sha1-ids
> for commit, parents, tree, referenced object (in tag), to copy'n'paste to
> shell.
>
Something as a typical browser "copy selected link" context menu entry?
Marco
^ permalink raw reply
* Re: git-fetch per-repository speed issues
From: Andreas Ericsson @ 2006-07-04 12:05 UTC (permalink / raw)
To: Matthias Kestenholz; +Cc: git
In-Reply-To: <20060704111838.GA4285@spinlock.ch>
Matthias Kestenholz wrote:
> * Andreas Ericsson (ae@op5.se) wrote:
>
>>Keith Packard wrote:
>>
>>>On Mon, 2006-07-03 at 20:40 -0700, Linus Torvalds wrote:
>>>
>>>
>>>
>>>> "And, it's painfully slow, even when the repository is up to date"
>>>>
>>>>and gave a 17-second time.
>>>
>>>
>>>It's faster this evening, down to 8 seconds using ssh and 4 seconds
>>>using git. I clearly need to force use of the git protocol. Anyone else
>>>like the attached patch?
>>
>>Since it changes the current meaning of ssh+git, I'm not exactly
>>thrilled. However, "git/ssh" or "ssh/git" would work fine for me. The
>>slash-separator could be used to say "fetch over this, push over that",
>>so we can end up with any valid protocol to use for fetches and another
>>one to push over.
>>
>
>
> If we would do such a thing, we would be probably better off
> allowing different URLs for pushing and pulling, because the git and
> ssh URLs will only be the same, if the git repositories are located
> in the root folder and I suspect that's almost never the case.
>
True. We use relative paths where I work, so for us either way would
work. Your way is better though.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: qgit idea: marking refs (heads and tags)
From: Jakub Narebski @ 2006-07-04 12:45 UTC (permalink / raw)
To: git
In-Reply-To: <e5bfff550607040503x75b1abdavbbeb80b41a454e7d@mail.gmail.com>
Marco Costalba wrote:
> On 7/4/06, Jakub Narebski <jnareb@gmail.com> wrote:
>> One thing I sorely lack in qgit as compared to gitk (and even gitweb[*1*])
>> is marking commits with refs (heads and tags, marked with different colors
>> or different shape marker). gitk currently uses markers in short log line
>> before text of commit summary, gitweb uses markers after (at the end) of
>> commit log summary. In qgit head commits are marked as such, but not to
>> which branche they belong[*2*].
>
> Currently you have to select the head and the status bar will show
> related information: branch, tag message, etc.
That is step in right direction, but still when viewing history as a whole
I'd like to know which branch is which. Head refs are marked, so it shouldn't
be much work (well, perhaps some on the GUI side) to add, as an option,
head name somewhere (before or after, or even somwehere else) along commit
"subject".
>> And also somewhat (but to much lesser extent) showing explicitely sha1-ids
>> for commit, parents, tree, referenced object (in tag), to copy'n'paste to
>> shell.
>
> Something as a typical browser "copy selected link" context menu entry?
Yes, "copy sha1 of selected link" would be nice.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: qgit idea: interface for cherry-picking
From: Jakub Narebski @ 2006-07-04 13:29 UTC (permalink / raw)
To: git
In-Reply-To: <e5bfff550607040458m1e6ea6bes44b3e3eba26856f0@mail.gmail.com>
Marco Costalba wrote:
> In the past weeks I (with Pavel support) have implemented and pushed
> the concept of "custom actions".
>
> Is it possible to associate commands sequences, scripts and anything
> else executable to a custom action. Actions can be called and run from
> menu entry and corresponding output is grabbed by a terminal window.
>
> Instead of hard code each git-native command, this way you have a
> flexible framework to add shortcuts and menu entry for anything you
> would like to be a click away. BTW I use this for stuff like git pull,
> but also for 'make' and 'make install' because you have a window
> terminal for feedback.
>
> There is also the possibility to input command line parameters before
> to run, useful, as example for a git pull action that asks for source
> repository to pull from.
>
> Is this something that can fulfill you request? do you need something
> different? perhaps something as a "default to current selected SHA as
> input argument" flag.
It would be nice (I don't know if feasible) that either to provide some kind
of parameters substitution in the likes of "%head" in the invocation line
for a script to be expanded to the sha1 or name of head of currently
selected commit.
Other solution would be to provide GUI for input of command line parameters,
e.g. combo-box (i.e. editable text field, with provided list of default
values) for repository (populated from .git/branches and .git/remotes),
option to select commit or use selected commit for head ref or just commit
ref, etc...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Add a custom ./configure script
From: Jakub Narebski @ 2006-07-04 13:50 UTC (permalink / raw)
To: git
In-Reply-To: <20060704004012.22639.44317.stgit@machine.or.cz>
Petr Baudis wrote:
> The patch is on top of pu, that is Jakub Narebski's autoconf patch, because
> it reuses most of its infrastructure and just replaces the configure script.
If you named it for example configure.sh, then autoconf generated version,
and your by hand created version could coexist.
For now I think it would be best to move autoconf related files (configure.ac,
config.mak.in) to the contrib/autoconf/ area. Then one would be able to
compare config.mak.autogen generated by ./configure from autoconf, and
your ./configure script.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH 2, proof of concept] autoconf: Use %configure in git.spec, autoconf dependency only in rpm target
From: Jakub Narebski @ 2006-07-04 14:09 UTC (permalink / raw)
To: git
In-Reply-To: <200607030156.50455.jnareb@gmail.com>
This is __Proof of Concept__ patch, which makes use of predefined
%configure rpm macro to define install dirs, using autoconf
generated ./configure script.
This patch introduces dependency on autoconf _only_ for rpm target during
build process.
---
Probably there is more portable way of ignoring diff exit status than
using '|| true', and probably better way to generate
"file creation"/"new file" patch from a working directory (only) file
(perhaps using git-diff too).
Sidenote 1: current git.spec.in doesn't allow building RPMS from a dirty
version:
error: line 3: Illegal char '-' in version: Version: 1.4.1.g1c7c-dirty
Is it intentional?
Sidenote 2: building rpm currently does compilation _twice_, once to generate
git-tar-tree, and once in the rpm build (in BuildRoot).
Makefile | 3 +++
git.spec.in | 6 ++++--
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index 3c2c257..8ad1a4a 100644
--- a/Makefile
+++ b/Makefile
@@ -721,6 +722,9 @@ dist: git.spec git-tar-tree
gzip -f -9 $(GIT_TARNAME).tar
rpm: dist
+ autoconf
+ diff -Nu /dev/null configure > git-add-autoconf-configure.patch || true
+ gzip -f -9 git-add-autoconf-configure.patch
$(RPMBUILD) -ta $(GIT_TARNAME).tar.gz
htmldocs = git-htmldocs-$(GIT_VERSION)
diff --git a/git.spec.in b/git.spec.in
index 8ccd256..9c02803 100644
--- a/git.spec.in
+++ b/git.spec.in
@@ -7,6 +7,7 @@ License: GPL
Group: Development/Tools
URL: http://kernel.org/pub/software/scm/git/
Source: http://kernel.org/pub/software/scm/git/%{name}-%{version}.tar.gz
+Patch0: git-add-autoconf-configure.patch.gz
BuildRequires: zlib-devel >= 1.2, openssl-devel, curl-devel, expat-devel %{!?_without_docs:, xmlto, asciidoc > 6.0.3}
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
Requires: git-core, git-svn, git-cvs, git-arch, git-email, gitk
@@ -72,15 +73,16 @@ Git revision tree visualiser ('gitk')
%prep
%setup -q
+%patch0 -p0
%build
+%configure
make %{_smp_mflags} CFLAGS="$RPM_OPT_FLAGS" WITH_OWN_SUBPROCESS_PY=YesPlease \
- prefix=%{_prefix} all %{!?_without_docs: doc}
+ all %{!?_without_docs: doc}
%install
rm -rf $RPM_BUILD_ROOT
make %{_smp_mflags} DESTDIR=$RPM_BUILD_ROOT WITH_OWN_SUBPROCESS_PY=YesPlease \
- prefix=%{_prefix} mandir=%{_mandir} \
install %{!?_without_docs: install-doc}
(find $RPM_BUILD_ROOT%{_bindir} -type f | grep -vE "arch|svn|cvs|email|gitk" | sed -e s@^$RPM_BUILD_ROOT@@) > bin-man-doc-files
--
1.4.0
^ permalink raw reply related
* Re: [PATCH 1/3] Add read_cache_from() and discard_cache()
From: Johannes Schindelin @ 2006-07-04 14:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7virmepfhx.fsf@assigned-by-dhcp.cox.net>
Hi,
On Mon, 3 Jul 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Okay. After reading the comment, I am quite certain we can just set the
> > index_file_timestamp to 0.
>
> Thanks.
>
> > So, I still think that these two lines should be in the cleanup part of
> > get_merge_bases().
>
> I think that is sane -- please make it so.
Ummm. After reading my original mail again: bad tobacco that was. Of
course, I meant discard_cache(), not get_merge_bases(). Setting
index_file_timestamp in get_merge_bases() would be wrong.
Sorry for the noise,
Dscho
^ permalink raw reply
* Re: [RFC] GIT user survey
From: Jakub Narebski @ 2006-07-04 15:28 UTC (permalink / raw)
To: git
In-Reply-To: <4d8e3fd30606240918m6b452314m6514b5e5fc86f147@mail.gmail.com>
Paolo Ciarrocchi wrote:
> I was wondering whether it could be a good idea to have a kind of "GIT
> users survey" when google pointed my eyes to this page:
> http://www.selenic.com/pipermail/mercurial/2006-April/007513.html
>
> So I modified the content of the survey and published a DRAFT here:
> http://paolo.ciarrocchi.googlepages.com/GITSurvey
Could you please add the final version (and of course results) on
Git Wiki (http://git.or.cz/gitwiki), like original one is on Mercurial
wiki: http://www.selenic.com/mercurial/wiki/index.cgi/UserSurvey ?
Thanks in advance
P.S. I wonder why my Mozilla 1.7.12 sees GITSurvey as binary/octet-stream
instead of text/plain file...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git-fetch per-repository speed issues
From: Jakub Narebski @ 2006-07-04 15:42 UTC (permalink / raw)
To: git
In-Reply-To: <1151949764.4723.51.camel@neko.keithp.com>
I wonder if the problem detected here is also responsible with results
of Jeremy Blosser benchmark comparing git with Mercurial
http://lists.ibiblio.org/pipermail/sm-discuss/2006-May/014586.html
where git wins for clone, status and log, but is slower for pull.
See summary at
http://git.or.cz/gitwiki/GitBenchmarks#head-85df1bb7f019c4c504e34cde43450ef69349882f
--
Jakub Narebski
^ permalink raw reply
* Re: git-fetch per-repository speed issues
From: Thomas Glanzmann @ 2006-07-04 16:30 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e8e28j$v8v$1@sea.gmane.org>
Hello,
> See summary at
> http://git.or.cz/gitwiki/GitBenchmarks#head-85df1bb7f019c4c504e34cde43450ef69349882f
thank you for clarifing! I finally understand why Solaris folks prefer
hg over git: It is dog slow. - So it fits the general philosophy behind
Solaris.
Thomas
^ permalink raw reply
* Re: [PATCH 1/3] Add read_cache_from() and discard_cache()
From: Junio C Hamano @ 2006-07-04 17:41 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0607041617290.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Ummm. After reading my original mail again: bad tobacco that was. Of
> course, I meant discard_cache(), not get_merge_bases(). Setting
> index_file_timestamp in get_merge_bases() would be wrong.
I was well aware you were talking about discard_cache(). I
think these two clean-ups are good to have there.
^ permalink raw reply
* Re: git-fetch per-repository speed issues
From: Junio C Hamano @ 2006-07-04 17:45 UTC (permalink / raw)
To: git; +Cc: jnareb
In-Reply-To: <e8e28j$v8v$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> I wonder if the problem detected here is also responsible with results
> of Jeremy Blosser benchmark comparing git with Mercurial
> http://lists.ibiblio.org/pipermail/sm-discuss/2006-May/014586.html
> where git wins for clone, status and log, but is slower for pull.
I had an impression, though the report does not talk about this
specific detail, that the extra time we are paying is because
the "git pull" test is done without suppressing the final
diffstat phase.
^ permalink raw reply
* Re: qgit idea: interface for cherry-picking
From: Marco Costalba @ 2006-07-04 18:23 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e5bfff550607040421id4e71efw38ee2bd773c949de@mail.gmail.com>
On 7/4/06, Marco Costalba <mcostalba@gmail.com> wrote:
> On 7/4/06, Junio C Hamano <junkio@cox.net> wrote:
> > "Marco Costalba" <mcostalba@gmail.com> writes:
> >
>
> I have started to implement the feature suggested by Jakub (patch in
> working dir only, not committed).
Ok. I have pushed two patches, the first with support for applying a
patch series in working dir only, i.e. without to create new commits,
the second to add "branch that a rev belongs to" info as in gitk, near
tags information was already there.
The difference with gitk is that only loaded branch/tags are
considered, this is to better scale.
Anyhow, due to little tricks ;-) , indexing is very fast, about 250ms
to index the whole Linux tree on my box.
Marco
^ permalink raw reply
* Re: qgit idea: interface for cherry-picking
From: Marco Costalba @ 2006-07-04 18:38 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Junio C Hamano
In-Reply-To: <e8dqfo$3ff$1@sea.gmane.org>
On 7/4/06, Jakub Narebski <jnareb@gmail.com> wrote:
> Marco Costalba wrote:
>
> >
> > Is this something that can fulfill you request? do you need something
> > different? perhaps something as a "default to current selected SHA as
> > input argument" flag.
>
> It would be nice (I don't know if feasible) that either to provide some kind
> of parameters substitution in the likes of "%head" in the invocation line
> for a script to be expanded to the sha1 or name of head of currently
> selected commit.
>
Well, I think that the indiscussed champion in this field is git-rev-parse
Please note that an action have not to be _one_ git command, but you
can assign a command sequence to an action, if the first command is
git-rev-parse probably you have what you need.
I have to better explain some implemantation details. In case a multi
line text is set as an action content, qgit wraps up the content in a
temporary script and run the script as a whole.
So you can use anything inside your action definition.
NOTE: this is possible because the input parameters are _always_
appended to the first line command only.
As example if the action 'test' is defined as:
echo
echo 2
echo 3
When you run 'test' and insert '1' when prompted for input
parameters the output will be:
1
2
3
Hope this helps.
Marco
^ 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