* Re: feature request: git-log should accept sth like v2.6.26-rc8-227
From: Junio C Hamano @ 2008-07-10 20:03 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Toralf Förster, git
In-Reply-To: <m3d4lledbn.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
> Besides, it would be nice to have some command (git-rev-parse perhaps?)
> which could take ambiguous commit-ish, and list all commit which matches
> it.
Have fun writing it and send in a patch.
^ permalink raw reply
* Re: [PATCH] bisect: test merge base if good rev is not an ancestor of bad rev
From: Junio C Hamano @ 2008-07-10 20:02 UTC (permalink / raw)
To: Christian Couder; +Cc: Johannes Schindelin, Michael Haggerty, Jeff King, git
In-Reply-To: <200807102126.37567.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> Yeah, in that case...
>
>> The whole idea of "bisect" relies on that idea, that any ancestor of a
>> good commit is good. Otherwise you'd have to check the commits one by
>> one, not in a bisecting manner.
Didn't we already discuss this at length?
> No, you just need to check that the merge bases between the bad rev on one
> side and each good rev on the other side are good too. And if that is the
> case, then you can be sure that bisection will point to a first bad commit.
>
> So the choice is between a simple and fast but not fully reliable bisect, or
> a more complex and slower but fully reliable bisect.
I have not looked at your implementation, but I do not think:
- The current one is not "fully reliable"; the user needs to know what
he is doing. You might call it "prone to user errors".
- "Test this merge-base before going forward, please" will add typically
only one round of check (if you have more merge bases between good and
bad, you need to test all of them are good to be sure), so it is not
"slower nor more complex".
^ permalink raw reply
* Re: feature request: git-log should accept sth like v2.6.26-rc8-227
From: Toralf Förster @ 2008-07-10 19:52 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git
In-Reply-To: <m3d4lledbn.fsf@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 340 bytes --]
At Thursday 10 July 2008 21:42:53 Jakub Narebski wrote :
> Besides, it would be nice to have some command (git-rev-parse perhaps?)
> which could take ambiguous commit-ish, and list all commit which matches
> it.
Oh yes :-)
--
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: feature request: git-log should accept sth like v2.6.26-rc8-227
From: Jakub Narebski @ 2008-07-10 19:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Toralf Förster, git
In-Reply-To: <7vk5ftpnek.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Toralf Förster <toralf.foerster@gmx.de> writes:
>
> > git-describe gives an informative string about the current status:
> > tfoerste@n22 ~/devel/linux-2.6 $ git describe
> > v2.6.26-rc9-56-g6329d30
> >
> > I appended those strings to the names of my UML kernel executables.
> > Unfortunately I didn't used the commit id and now I'm wondering whether git
> > could accept v2.6.26-rc9-56 as well in future.
>
> It does take v2.6.26-rc9-56-g6329d30.
>
> It will never take v2.6.26-rc9-56. The world is not linear.
Nevertheless it _could_ be unique.
Besides, it would be nice to have some command (git-rev-parse perhaps?)
which could take ambiguous commit-ish, and list all commit which matches
it.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: feature request: git-log should accept sth like v2.6.26-rc8-227
From: Johannes Schindelin @ 2008-07-10 19:29 UTC (permalink / raw)
To: Toralf Förster; +Cc: git
In-Reply-To: <200807102057.15063.toralf.foerster@gmx.de>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 309 bytes --]
Hi,
On Thu, 10 Jul 2008, Toralf Förster wrote:
> I appended those strings to the names of my UML kernel executables.
> Unfortunately I didn't used the commit id and now I'm wondering whether
> git could accept v2.6.26-rc9-56 as well in future.
If that were unambiguous, yes. But it is not.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] bisect: test merge base if good rev is not an ancestor of bad rev
From: Christian Couder @ 2008-07-10 19:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Michael Haggerty, Jeff King, git
In-Reply-To: <alpine.DEB.1.00.0807101201210.3135@eeepc-johanness>
Hi,
Le jeudi 10 juillet 2008, Johannes Schindelin a écrit :
> Hi,
>
> On Thu, 10 Jul 2008, Christian Couder wrote:
> > Before this patch, "git bisect", when it was given some good revs that
> > are not ancestor of the bad rev, didn't check if the merge bases were
> > good. "git bisect" just supposed that the user knew what he was doing,
> > and that, when he said the revs were good, he knew that it meant that
> > all the revs in the history leading to the good revs were also
> > considered good.
>
> Well, it is not completely relying on the user.
Yeah it's relying on statistics too.
> The common scenario before a bisect is this: something used to work _all
> the time_, and all of a sudden, it does not anymore.
I agree that it is the most common scenario, perhaps 95% or perhaps even 99%
or more. But mistakes and special cases happens too.
For example people can forget to apply in the trunk a fix that is in a side
branch. Or they can revert in a side branch a big buggy feature just before
making a minor release; but in the trunk the big buggy feature is still
there and may very well have introduced regressions.
> So it is expected that there is no fix in the history. Not in the
> current branch, not in the "good" branch, not wherever.
>
> In that case, you are literally guaranteed that all ancestors of a good
> commit are good, too, because if there was a bad one, there would be a
> fix, too.
Yeah, in that case...
> The whole idea of "bisect" relies on that idea, that any ancestor of a
> good commit is good. Otherwise you'd have to check the commits one by
> one, not in a bisecting manner.
No, you just need to check that the merge bases between the bad rev on one
side and each good rev on the other side are good too. And if that is the
case, then you can be sure that bisection will point to a first bad commit.
So the choice is between a simple and fast but not fully reliable bisect, or
a more complex and slower but fully reliable bisect.
Regards,
Christian.
^ permalink raw reply
* Re: feature request: git-log should accept sth like v2.6.26-rc8-227
From: Junio C Hamano @ 2008-07-10 19:08 UTC (permalink / raw)
To: Toralf Förster; +Cc: git
In-Reply-To: <200807102057.15063.toralf.foerster@gmx.de>
Toralf Förster <toralf.foerster@gmx.de> writes:
> git-describe gives an informative string about the current status:
> tfoerste@n22 ~/devel/linux-2.6 $ git describe
> v2.6.26-rc9-56-g6329d30
>
> I appended those strings to the names of my UML kernel executables.
> Unfortunately I didn't used the commit id and now I'm wondering whether git
> could accept v2.6.26-rc9-56 as well in future.
It does take v2.6.26-rc9-56-g6329d30.
It will never take v2.6.26-rc9-56. The world is not linear.
^ permalink raw reply
* Re: [JGIT PATCH 2/5] Don't display passwords on the console in fetch/push output
From: Robin Rosenberg @ 2008-07-10 18:56 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Marek Zawirski, git
In-Reply-To: <1215670403-19191-3-git-send-email-spearce@spearce.org>
torsdagen den 10 juli 2008 08.13.20 skrev Shawn O. Pearce:
> When we show the URI we just fetched or pushed against there may
> be a user password embedded in that URI, as saved in the user's
> .git/config file. We shouldn't display that in public to prying
> eyes so nulling it out will give us a copy of the URI without that
> field in it.
>
> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
> ---
> .../src/org/spearce/jgit/pgm/Fetch.java | 2 +-
> .../src/org/spearce/jgit/pgm/Push.java | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/org.spearce.jgit/src/org/spearce/jgit/pgm/Fetch.java b/org.spearce.jgit/src/org/spearce/jgit/pgm/Fetch.java
> index c9c997e..36a0592 100644
> --- a/org.spearce.jgit/src/org/spearce/jgit/pgm/Fetch.java
> +++ b/org.spearce.jgit/src/org/spearce/jgit/pgm/Fetch.java
> @@ -71,7 +71,7 @@ class Fetch extends TextBuiltin {
> return;
>
> out.print("From ");
> - out.print(tn.getURI());
> + out.print(tn.getURI().setPass(null));
We did this a while ago. Sort of patching broken stuff instead of fixing what's broken, thus we should make URIIsh.toiString
not display the password.
-- robin
^ permalink raw reply
* feature request: git-log should accept sth like v2.6.26-rc8-227
From: Toralf Förster @ 2008-07-10 18:57 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 455 bytes --]
Hello,
git-describe gives an informative string about the current status:
tfoerste@n22 ~/devel/linux-2.6 $ git describe
v2.6.26-rc9-56-g6329d30
I appended those strings to the names of my UML kernel executables.
Unfortunately I didn't used the commit id and now I'm wondering whether git
could accept v2.6.26-rc9-56 as well in future.
--
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] tutorial: prefix the prompts with names alice or bob, to make it clear who is doing what
From: Ian Katz @ 2008-07-10 18:27 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <20080710164520.GZ10347@genesis.frugalware.org>
Signed-off-by: Ian Katz <ifreecarve@gmail.com>
---
Documentation/gittutorial.txt | 26 +++++++++++++-------------
1 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/Documentation/gittutorial.txt b/Documentation/gittutorial.txt
index e71b561..e4248b6 100644
--- a/Documentation/gittutorial.txt
+++ b/Documentation/gittutorial.txt
@@ -274,7 +274,7 @@ same machine, wants to contribute.
Bob begins with:
------------------------------------------------
-$ git clone /home/alice/project myrepo
+bob$ git clone /home/alice/project myrepo
------------------------------------------------
This creates a new directory "myrepo" containing a clone of Alice's
@@ -285,7 +285,7 @@ Bob then makes some changes and commits them:
------------------------------------------------
(edit files)
-$ git commit -a
+bob$ git commit -a
(repeat as necessary)
------------------------------------------------
@@ -293,8 +293,8 @@ When he's ready, he tells Alice to pull changes from the rep
ository
at /home/bob/myrepo. She does this with:
------------------------------------------------
-$ cd /home/alice/project
-$ git pull /home/bob/myrepo master
+alice$ cd /home/alice/project
+alice$ git pull /home/bob/myrepo master
------------------------------------------------
This merges the changes from Bob's "master" branch into Alice's
@@ -312,7 +312,7 @@ again. By defining 'remote' repository shorthand, you can m
ake
it easier:
------------------------------------------------
-$ git remote add bob /home/bob/myrepo
+alice$ git remote add bob /home/bob/myrepo
------------------------------------------------
With this, Alice can perform the first operation alone using the
@@ -320,7 +320,7 @@ With this, Alice can perform the first operation alone using
the
using:
-------------------------------------
-$ git fetch bob
+alice$ git fetch bob
-------------------------------------
Unlike the longhand form, when Alice fetches from Bob using a
@@ -329,7 +329,7 @@ fetched is stored in a remote tracking branch, in this case
`bob/master`. So after this:
-------------------------------------
-$ git log -p master..bob/master
+alice$ git log -p master..bob/master
-------------------------------------
shows a list of all the changes that Bob made since he branched from
@@ -339,14 +339,14 @@ After examining those changes, Alice
could merge the changes into her master branch:
-------------------------------------
-$ git merge bob/master
+alice$ git merge bob/master
-------------------------------------
This `merge` can also be done by 'pulling from her own remote
tracking branch', like this:
-------------------------------------
-$ git pull . remotes/bob/master
+alice$ git pull . remotes/bob/master
-------------------------------------
Note that git pull always merges into the current branch,
@@ -355,7 +355,7 @@ regardless of what else is given on the command line.
Later, Bob can update his repo with Alice's latest changes using
-------------------------------------
-$ git pull
+bob$ git pull
-------------------------------------
Note that he doesn't need to give the path to Alice's repository;
@@ -364,7 +364,7 @@ repository in the repository configuration, and that locatio
n is
used for pulls:
-------------------------------------
-$ git config --get remote.origin.url
+bob$ git config --get remote.origin.url
/home/alice/project
-------------------------------------
@@ -376,7 +376,7 @@ Git also keeps a pristine copy of Alice's master branch unde
r the
name "origin/master":
-------------------------------------
-$ git branch -r
+bob$ git branch -r
origin/master
-------------------------------------
@@ -384,7 +384,7 @@ If Bob later decides to work from a different host, he can s
till
perform clones and pulls using the ssh protocol:
-------------------------------------
-$ git clone alice.org:/home/alice/project myrepo
+bob$ git clone alice.org:/home/alice/project myrepo
-------------------------------------
Alternatively, git has a native protocol, or can use rsync or http;
--
1.5.3.7
^ permalink raw reply related
* Re: [JGIT PATCH 1/1] jgit: create a tag command
From: Robin Rosenberg @ 2008-07-10 18:02 UTC (permalink / raw)
To: Mike Ralphson; +Cc: Shawn O. Pearce, Marek Zawirski, git
In-Reply-To: <e2b179460807100831g5d62a0a8nc7e7bf2715f0b9f1@mail.gmail.com>
torsdagen den 10 juli 2008 17.31.06 skrev Mike Ralphson:
> 2008/7/7 Robin Rosenberg <robin.rosenberg.lists@dewire.com>:
> >
> > This command allows us to create simple or annotated tags.
> > PGP signed tags are not yet supported.
> >
> > Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
>
> Apologies this will be whitespace damaged, but it's trivial.
Don't do like that again : Had to use patch -l to apply this. Why doesn't git am have that?
Anyway thanks for the fix.
-- robin
^ permalink raw reply
* Re: git pull is slow
From: Stephan Hennig @ 2008-07-10 17:44 UTC (permalink / raw)
To: git; +Cc: Petr Baudis, Johannes Sixt
In-Reply-To: <20080710155016.GC32184@machine.or.cz>
Petr Baudis schrieb:
> On Thu, Jul 10, 2008 at 05:45:14PM +0200, Stephan Hennig wrote:
>>
>> No, I'm already using git+ssh.
>
> Oh, ok. By the way, how long are you hitting this issue? Just today,
> I have upgraded the chroot Git from some anonymous 2007-12-08 version
> to the almost-latest #next.
I don't know for sure. But I think I've had the issue since I started
accessing that repository in October 2007 (then with WinGit-0.2-alpha).
Best regards,
Stephan Hennig
PS: Attached is my .git/config. Could the repositoryformatversion line
trigger some sort of dumb transfer protocol?
> [core]
> repositoryformatversion = 0
> filemode = false
> bare = false
> logallrefupdates = true
> symlinks = false
> autocrlf = false
> [remote "origin"]
> url = git+ssh://xxx@repo.or.cz/srv/git/wortliste.git
> fetch = +refs/heads/*:refs/remotes/origin/*
> [branch "master"]
> remote = origin
> merge = refs/heads/master
^ permalink raw reply
* Re: THREADED_DELTA_SEARCH
From: Andreas Ericsson @ 2008-07-10 16:50 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Pierre Habouzit, Git ML
In-Reply-To: <4875C1CF.1010604@viscovery.net>
Johannes Sixt wrote:
> Pierre Habouzit schrieb:
>> I'm using it in production for quite a long time now, and I wonder if
>> there is any specific reason why it's not default. Debian activated it
>> by default too a couple of weeks ago, which means that it's in
>> production on quite a large scale, and there are no issues reported
>> either. Would a patch making it default be accepted ? It's quite handy
>> given that SMP machines are really pervasive nowadays…
>
> Don't forget to turn it off in the MINGW section in the Makefile since we
> don't have pthreads on Windows.
>
I started trying that, but ran into problems almost immediately. Enabling
pthreads by default and disabling it for certain systems means we screw
over those poor sods that have their own config.mak files on systems
where there's no <pthread.h> to include, or where that header file
requires a bunch of other stuff to be in first.
On the one hand, that's not nice.
On the other hand, those who have a config.mak are probably savvy enough
figure out how to amend it disable threads as well.
Opinions? I'm all for enabling THREADED_DELTA_SEARCH by default. I've
been using it ever since v1.5.4.3-193-g833e3df when using the same
.gitconfig on all my systems became a sane thing to do and I haven't
seen any ill effects what so ever from it, but how much can we screw
the build-system in place today, and what other systems would, by
default, require the NO_PTHREADS option in the Makefile?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] tutorial: prefix the prompts with names alice or bob, to make it clear who is doing what
From: Miklos Vajna @ 2008-07-10 16:45 UTC (permalink / raw)
To: Ian Katz; +Cc: git
In-Reply-To: <dc5b80bf0807100912rac7b730ga1ac035057d71d64@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 293 bytes --]
On Thu, Jul 10, 2008 at 12:12:09PM -0400, Ian Katz <ifreecarve@gmail.com> wrote:
> ---
> Documentation/gittutorial.txt | 26 +++++++++++++-------------
> 1 files changed, 13 insertions(+), 13 deletions(-)
Please add your Sign-off when sending patches, see
Documentation/SubmittingPatches.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: THREADED_DELTA_SEARCH
From: Nicolas Pitre @ 2008-07-10 16:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pierre Habouzit, Git ML
In-Reply-To: <7vy749pxbe.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1337 bytes --]
On Thu, 10 Jul 2008, Junio C Hamano wrote:
> Pierre Habouzit <madcoder@debian.org> writes:
>
> > I'm using it in production for quite a long time now, and I wonder if
> > there is any specific reason why it's not default. Debian activated it
> > by default too a couple of weeks ago, which means that it's in
> > production on quite a large scale, and there are no issues reported
> > either. Would a patch making it default be accepted ? It's quite handy
> > given that SMP machines are really pervasive nowadays…
>
> There were two issues, IIRC.
>
> (1) resulting pack could be suboptimal, due to delta-chain getting cut
> betweeen the worker thread boundary.
>
> (2) exploding memory use, suspected to be due to malloc pool
> fragmentation under multithreading.
>
> The former was only an issue with early iterations of the code and the
> current code has much improved behaviour on this point,
I would say it is even negligible.
> but I do not
> recall the latter issue has been addressed.
Well, for "standard" repositories such as the Linux kernel, things
always worked just fine. And commit eac12e2d is apparently helping a
lot with the remaining odd cases. And if someone has problems due to
this then a simple 'git config --global pack.threads 1' would restore
the non threaded behavior.
Nicolas
^ permalink raw reply
* [PATCH] tutorial: prefix the prompts with names alice or bob, to make it clear who is doing what
From: Ian Katz @ 2008-07-10 16:12 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.DEB.1.00.0807101654080.18205@racer>
---
Documentation/gittutorial.txt | 26 +++++++++++++-------------
1 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/Documentation/gittutorial.txt b/Documentation/gittutorial.txt
index e71b561..e4248b6 100644
--- a/Documentation/gittutorial.txt
+++ b/Documentation/gittutorial.txt
@@ -274,7 +274,7 @@ same machine, wants to contribute.
Bob begins with:
------------------------------------------------
-$ git clone /home/alice/project myrepo
+bob$ git clone /home/alice/project myrepo
------------------------------------------------
This creates a new directory "myrepo" containing a clone of Alice's
@@ -285,7 +285,7 @@ Bob then makes some changes and commits them:
------------------------------------------------
(edit files)
-$ git commit -a
+bob$ git commit -a
(repeat as necessary)
------------------------------------------------
@@ -293,8 +293,8 @@ When he's ready, he tells Alice to pull changes from the rep
ository
at /home/bob/myrepo. She does this with:
------------------------------------------------
-$ cd /home/alice/project
-$ git pull /home/bob/myrepo master
+alice$ cd /home/alice/project
+alice$ git pull /home/bob/myrepo master
------------------------------------------------
This merges the changes from Bob's "master" branch into Alice's
@@ -312,7 +312,7 @@ again. By defining 'remote' repository shorthand, you can m
ake
it easier:
------------------------------------------------
-$ git remote add bob /home/bob/myrepo
+alice$ git remote add bob /home/bob/myrepo
------------------------------------------------
With this, Alice can perform the first operation alone using the
@@ -320,7 +320,7 @@ With this, Alice can perform the first operation alone using
the
using:
-------------------------------------
-$ git fetch bob
+alice$ git fetch bob
-------------------------------------
Unlike the longhand form, when Alice fetches from Bob using a
@@ -329,7 +329,7 @@ fetched is stored in a remote tracking branch, in this case
`bob/master`. So after this:
-------------------------------------
-$ git log -p master..bob/master
+alice$ git log -p master..bob/master
-------------------------------------
shows a list of all the changes that Bob made since he branched from
@@ -339,14 +339,14 @@ After examining those changes, Alice
could merge the changes into her master branch:
-------------------------------------
-$ git merge bob/master
+alice$ git merge bob/master
-------------------------------------
This `merge` can also be done by 'pulling from her own remote
tracking branch', like this:
-------------------------------------
-$ git pull . remotes/bob/master
+alice$ git pull . remotes/bob/master
-------------------------------------
Note that git pull always merges into the current branch,
@@ -355,7 +355,7 @@ regardless of what else is given on the command line.
Later, Bob can update his repo with Alice's latest changes using
-------------------------------------
-$ git pull
+bob$ git pull
-------------------------------------
Note that he doesn't need to give the path to Alice's repository;
@@ -364,7 +364,7 @@ repository in the repository configuration, and that locatio
n is
used for pulls:
-------------------------------------
-$ git config --get remote.origin.url
+bob$ git config --get remote.origin.url
/home/alice/project
-------------------------------------
@@ -376,7 +376,7 @@ Git also keeps a pristine copy of Alice's master branch unde
r the
name "origin/master":
-------------------------------------
-$ git branch -r
+bob$ git branch -r
origin/master
-------------------------------------
@@ -384,7 +384,7 @@ If Bob later decides to work from a different host, he can s
till
perform clones and pulls using the ssh protocol:
-------------------------------------
-$ git clone alice.org:/home/alice/project myrepo
+bob$ git clone alice.org:/home/alice/project myrepo
-------------------------------------
Alternatively, git has a native protocol, or can use rsync or http;
--
1.5.3.7
^ permalink raw reply related
* Re: [PATCH] apply: fix copy/rename breakage
From: Don Zickus @ 2008-07-10 15:43 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, git, Linus Torvalds
In-Reply-To: <48762919.6070902@viscovery.net>
On Thu, Jul 10, 2008 at 05:22:01PM +0200, Johannes Sixt wrote:
> >> With this patch, we disable the postimage record 'fn_table' when applying
> >> a patch to produce new files out of existing file by copying to fix this
> >> issue.
> >
> > Odd. I guess the way I read this workflow is
> >
> > apply change X to A, copy A' to B, apply change Y to B => B' now has changes X+Y
> >
> > But instead you are saying B' only has change Y because A is copied to B
> > not A'.
> >
> > Regardless, it doesn't affect my workflow.
>
> Oh, it does. It's a normal git diff where a copy was detected!
>
> Don't let you distract by the word "incremental" and by the names A and B.
> In the example above, the change X comes first because 'A' is sorted
> before 'B'. If the roles of A and B were swapped, then you have this patch:
>
> diff --git a/A b/A
> copy from B
> copy to A
> --- a/A
> +++ b/A
> ... change text Y here ...
> diff --git a/A b/B
> --- a/A
> +++ b/B
> ... change text X here ...
>
> See?
Yes, thank you!
Cheers,
Don
^ permalink raw reply
* Re: [PATCH] cherry: cache patch-ids to avoid repeating work
From: Johannes Schindelin @ 2008-07-10 15:56 UTC (permalink / raw)
To: Geoffrey Irving; +Cc: Junio C Hamano, git@vger.kernel.org
In-Reply-To: <7f9d599f0807100733s4435a9bga89749f2f6e10cf@mail.gmail.com>
Hi,
On Thu, 10 Jul 2008, Geoffrey Irving wrote:
> On Thu, Jul 10, 2008 at 7:28 AM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>
> > On Thu, 10 Jul 2008, Geoffrey Irving wrote:
> >
> >> On Wed, Jul 9, 2008 at 8:34 PM, Geoffrey Irving <irving@naml.us> wrote:
> >>
> >> > Note: there are at least two "holes" in this code. First, it is
> >> > impossible to verify the validity of the entries (this is
> >> > impossible to fix). Second, it is possible to write a malicious
> >> > patch-id-cache file that causes git-cherry to go into an infinite
> >> > loop. Fixing the loop requires either traversing every entry on
> >> > load (bad) or adding a second loop termination condition to
> >> > find_helper. Since looping forever is better than returning
> >> > incorrect results, I figured fixing the weaker hole would just
> >> > result in a false sense of security.
> >>
> >> Oops: avoiding the infinite loop only requires reading expected O(1)
> >> entries on load, so I can fix that if you like. It would only be all
> >> of them if it actually did detect the infinite loop.
> >
> > I have to admit that you lost me there. AFAIR the patch-id cache is a
> > simple commit->patch_id store, right? Then there should be no way to
> > get an infinite loop.
>
> If every entry is nonnull, find_helper loops forever.
Ah, that is because you did not use that part of my implementation. My
hash did not wrap.
> > Besides, this is a purely local cache, no? Never to be transmitted...
> > So not much chance of a malicious attack, except if you allow write
> > access to your local repository, in which case you are endangered no
> > matter what.
>
> Yep, that's why it's only a hole in quotes, and why I didn't fix it.
Then it is not a hole.
Ciao,
Dscho
^ permalink raw reply
* Re: git pull is slow
From: Petr Baudis @ 2008-07-10 15:50 UTC (permalink / raw)
To: Stephan Hennig; +Cc: git, Johannes Sixt
In-Reply-To: <48762E8A.7070203@arcor.de>
On Thu, Jul 10, 2008 at 05:45:14PM +0200, Stephan Hennig wrote:
> Johannes Sixt schrieb:
> > Stephan Hennig schrieb:
> >> I am observing very large data transfers when pulling from the
> >> repository at <URL:http://repo.or.cz/w/wortliste.git>. This
> >> repository contains one 13 MB text file that compressed is roughly
> >> 3 MB large.
> >
> > Do you by any chance use a http URL to pull? Don't do that. Use git
> > protocol.
>
> No, I'm already using git+ssh.
Oh, ok. By the way, how long are you hitting this issue? Just today,
I have upgraded the chroot Git from some anonymous 2007-12-08 version
to the almost-latest #next.
--
Petr "Pasky" Baudis
The last good thing written in C++ was the Pachelbel Canon. -- J. Olson
^ permalink raw reply
* Re: git pull is slow
From: Stephan Hennig @ 2008-07-10 15:45 UTC (permalink / raw)
To: git; +Cc: Johannes Sixt
In-Reply-To: <48762B27.90004@viscovery.net>
Johannes Sixt schrieb:
> Stephan Hennig schrieb:
>> I am observing very large data transfers when pulling from the
>> repository at <URL:http://repo.or.cz/w/wortliste.git>. This
>> repository contains one 13 MB text file that compressed is roughly
>> 3 MB large.
>
> Do you by any chance use a http URL to pull? Don't do that. Use git
> protocol.
No, I'm already using git+ssh.
Best regards,
Stephan Hennig
^ permalink raw reply
* Re: THREADED_DELTA_SEARCH
From: Junio C Hamano @ 2008-07-10 15:34 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Git ML
In-Reply-To: <20080710075327.GD24819@artemis.madism.org>
Pierre Habouzit <madcoder@debian.org> writes:
> I'm using it in production for quite a long time now, and I wonder if
> there is any specific reason why it's not default. Debian activated it
> by default too a couple of weeks ago, which means that it's in
> production on quite a large scale, and there are no issues reported
> either. Would a patch making it default be accepted ? It's quite handy
> given that SMP machines are really pervasive nowadays…
There were two issues, IIRC.
(1) resulting pack could be suboptimal, due to delta-chain getting cut
betweeen the worker thread boundary.
(2) exploding memory use, suspected to be due to malloc pool
fragmentation under multithreading.
The former was only an issue with early iterations of the code and the
current code has much improved behaviour on this point, but I do not
recall the latter issue has been addressed.
^ permalink raw reply
* Re: [JGIT PATCH 1/1] jgit: create a tag command
From: Mike Ralphson @ 2008-07-10 15:31 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Shawn O. Pearce, Marek Zawirski, git
In-Reply-To: <200807070116.39892.robin.rosenberg.lists@dewire.com>
2008/7/7 Robin Rosenberg <robin.rosenberg.lists@dewire.com>:
>
> This command allows us to create simple or annotated tags.
> PGP signed tags are not yet supported.
>
> Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
Apologies this will be whitespace damaged, but it's trivial.
diff --git a/org.spearce.jgit/src/org/spearce/jgit/pgm/Tag.java
b/org.spearce.jgit/src/org/spearce/jgit/pgm/Tag.java
index 110db6b..a215fbd 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/pgm/Tag.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/pgm/Tag.java
@@ -47,6 +47,8 @@ class Tag extends TextBuiltin {
String message = null;
String ref = "HEAD";
boolean force = false;
+ if (args.length == 0)
+ usage();
for (int i = 0; i < args.length; ++i) {
if (args[i].equals("-f")) {
force = true;
@@ -97,6 +99,6 @@ class Tag extends TextBuiltin {
}
private void usage() {
- throw die("Usage: -m message tag [head]");
+ throw die("Usage: [-m message] [-f] tag [head]");
}
}
Signed-off-by: Mike Ralphson <mike@abacus.co.uk>
Loving the make_jgit stuff.
Mike
^ permalink raw reply related
* Re: git pull is slow
From: Johannes Sixt @ 2008-07-10 15:30 UTC (permalink / raw)
To: Stephan Hennig; +Cc: git
In-Reply-To: <g5570s$d5m$1@ger.gmane.org>
Stephan Hennig schrieb:
> I am observing very large data transfers when pulling from the
> repository at <URL:http://repo.or.cz/w/wortliste.git>. This repository
> contains one 13 MB text file that compressed is roughly 3 MB large.
>
> While I'd expect pulling commits that change only a few lines of the
> large text file to result in a download of less than, say 10kB, git pull
> seems to transfer the complete, compressed file. I have observed this
> several times for different commits. On the other hand, pushing my own
> commits to the repository is fast (with git+ssh access method). Any
> ideas what's going on and how to make pulling faster?
Do you by any chance use a http URL to pull? Don't do that. Use git protocol.
-- Hannes
^ permalink raw reply
* Re: git pull is slow
From: Petr Baudis @ 2008-07-10 15:28 UTC (permalink / raw)
To: Stephan Hennig; +Cc: git
In-Reply-To: <g5570s$d5m$1@ger.gmane.org>
Hi,
On Thu, Jul 10, 2008 at 04:40:17PM +0200, Stephan Hennig wrote:
> I am observing very large data transfers when pulling from the
> repository at <URL:http://repo.or.cz/w/wortliste.git>. This repository
> contains one 13 MB text file that compressed is roughly 3 MB large.
>
> While I'd expect pulling commits that change only a few lines of the
> large text file to result in a download of less than, say 10kB, git pull
> seems to transfer the complete, compressed file. I have observed this
> several times for different commits. On the other hand, pushing my own
> commits to the repository is fast (with git+ssh access method). Any
> ideas what's going on and how to make pulling faster?
do you use HTTP or native Git protocol for pulling? If HTTP, you have
to live with this, sorry - the automatic repacks will create a new pack
every time and you will have to redownload the whole history; I tried to
avoid this problem but in the end I had to bow down to the agressive
repacking strategy because the number of packs was getting out of hand.
It is technically possible to implement some alternative more
HTTP-friendly packing strategy, but this has always stayed only in idea
stage. If you want to implement something, repo.or.cz will become a glad
user. :-)
--
Petr "Pasky" Baudis
The last good thing written in C++ was the Pachelbel Canon. -- J. Olson
^ permalink raw reply
* Re: [PATCH] apply: fix copy/rename breakage
From: Johannes Sixt @ 2008-07-10 15:22 UTC (permalink / raw)
To: Don Zickus; +Cc: Junio C Hamano, git, Linus Torvalds
In-Reply-To: <20080710140154.GN26957@redhat.com>
Don Zickus schrieb:
> On Wed, Jul 09, 2008 at 08:10:58PM -0700, Junio C Hamano wrote:
>> However, this "incremental" mode of patch application contradicts with the
>> way git rename/copy patches are fundamentally designed. When a git patch
>> talks about a file A getting modified, and a new file B created out of B,
>> like this:
>>
>> diff --git a/A b/A
>> --- a/A
>> +++ b/A
>> ... change text X here ...
>> diff --git a/A b/B
>> copy from A
>> copy to B
>> --- a/A
>> +++ b/B
>> ... change text Y here ...
>>
>> the second change to produce B does not depend on what is done to A with
>> the first change (this is explicitly done so for reviewability of
>> individual patches).
>>
>> With this patch, we disable the postimage record 'fn_table' when applying
>> a patch to produce new files out of existing file by copying to fix this
>> issue.
>
> Odd. I guess the way I read this workflow is
>
> apply change X to A, copy A' to B, apply change Y to B => B' now has changes X+Y
>
> But instead you are saying B' only has change Y because A is copied to B
> not A'.
>
> Regardless, it doesn't affect my workflow.
Oh, it does. It's a normal git diff where a copy was detected!
Don't let you distract by the word "incremental" and by the names A and B.
In the example above, the change X comes first because 'A' is sorted
before 'B'. If the roles of A and B were swapped, then you have this patch:
diff --git a/A b/A
copy from B
copy to A
--- a/A
+++ b/A
... change text Y here ...
diff --git a/A b/B
--- a/A
+++ b/B
... change text X here ...
See?
-- Hannes
^ 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