* [JGIT PATCH 1/3] Fix retrieval of test resources for paths containing spaces
From: Jonas Fonseca @ 2008-10-22 8:32 UTC (permalink / raw)
To: Robin Rosenberg, Shawn O. Pearce; +Cc: git
The use of URL.getPath() can be problematic when the repository path
contains spaces since they get encoded as %20, which will lead to a "No
such file" error when resolving to a local file. The fix first tries to
convert the resource URL to a URI (added in Java 1.5), which is then
used to construct the File instance. As a fallback use the old behavior
if a URISyntaxException is thrown.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
.../tst/org/spearce/jgit/util/JGitTestUtil.java | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/util/JGitTestUtil.java b/org.spearce.jgit.test/tst/org/spearce/jgit/util/JGitTestUtil.java
index bf2471d..eee0c14 100644
--- a/org.spearce.jgit.test/tst/org/spearce/jgit/util/JGitTestUtil.java
+++ b/org.spearce.jgit.test/tst/org/spearce/jgit/util/JGitTestUtil.java
@@ -38,6 +38,7 @@
package org.spearce.jgit.util;
import java.io.File;
+import java.net.URISyntaxException;
import java.net.URL;
public abstract class JGitTestUtil {
@@ -57,7 +58,11 @@ public static File getTestResourceFile(final String fileName) {
// loaded previously
return new File("tst", fileName);
}
- return new File(url.getPath());
+ try {
+ return new File(url.toURI());
+ } catch(URISyntaxException e) {
+ return new File(url.getPath());
+ }
}
private static ClassLoader cl() {
--
1.6.0.2.1166.g8d97a.dirty
--
Jonas Fonseca
^ permalink raw reply related
* [JGIT PATCH 2/3] Fix FileTreeIteratorTest on Windows/NTFS
From: Jonas Fonseca @ 2008-10-22 8:33 UTC (permalink / raw)
To: Robin Rosenberg, Shawn O. Pearce; +Cc: git
Replace '.' with ',' in the test paths to keep the original intent, but
make the test runnable on systems where files named "a." cannot be
reliably created. The problem seems to be that a file created as "a."
will end up as "a" on disk.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
.../jgit/treewalk/FileTreeIteratorTest.java | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
With this all the tests pass on my Windows installation.
diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/treewalk/FileTreeIteratorTest.java b/org.spearce.jgit.test/tst/org/spearce/jgit/treewalk/FileTreeIteratorTest.java
index ca31991..967557e 100644
--- a/org.spearce.jgit.test/tst/org/spearce/jgit/treewalk/FileTreeIteratorTest.java
+++ b/org.spearce.jgit.test/tst/org/spearce/jgit/treewalk/FileTreeIteratorTest.java
@@ -47,7 +47,7 @@
import org.spearce.jgit.util.RawParseUtils;
public class FileTreeIteratorTest extends RepositoryTestCase {
- private final String[] paths = { "a.", "a.b", "a/b", "a0b" };
+ private final String[] paths = { "a,", "a,b", "a/b", "a0b" };
private long[] mtime;
--
1.6.0.2.1166.g8d97a.dirty
--
Jonas Fonseca
^ permalink raw reply related
* [JGIT RFC PATCH 3/3] Rate limit warnings spewed by RepositoryTestCase.recursiveDelete
From: Jonas Fonseca @ 2008-10-22 8:34 UTC (permalink / raw)
To: Robin Rosenberg, Shawn O. Pearce; +Cc: git
On Windows XP / NTFS / NetBeans 6.1 / Java 5 a lot of warnings are
printed. In most cases the path is in fact deleted and it seems to just
be a timing bug or something Windows or NTFS specific. Also, many of the
warnings are for the same paths and therefore a bit redundant.
Furthermore, when a lot of warnings are printed it gives the feeling of
slowing down the tests. By rate limiting the warnings the problem is
still made visible for developers to notice.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
.../org/spearce/jgit/lib/RepositoryTestCase.java | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
This is mostly an annoyance fix, but might be acceptable.
diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/RepositoryTestCase.java b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/RepositoryTestCase.java
index 9d7d133..44e24d7 100644
--- a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/RepositoryTestCase.java
+++ b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/RepositoryTestCase.java
@@ -51,6 +51,8 @@
public abstract class RepositoryTestCase extends TestCase {
+ private static long deleteFailures;
+
protected final File trashParent = new File("trash");
protected File trash;
@@ -79,7 +81,7 @@ protected static void recursiveDelete(final File dir) {
}
}
dir.delete();
- if (dir.exists()) {
+ if (dir.exists() && deleteFailures++ < 42) {
System.out.println("Warning: Failed to delete " + dir);
}
}
--
1.6.0.2.1166.g8d97a.dirty
--
Jonas Fonseca
^ permalink raw reply related
* Re: [irq/urgent]: created 3786fc7: "irq: make variable static"
From: Andreas Ericsson @ 2008-10-22 8:34 UTC (permalink / raw)
To: Ingo Molnar; +Cc: git
In-Reply-To: <20081022061730.GA5749@elte.hu>
Ingo Molnar wrote:
> Git recently started printing the branch name when creating commits:
>
> [irq/urgent]: created 3786fc7: "irq: make variable static"
>
> very nice idea IMO!
Thanks! Be sure to read the paintshop discussion that lead to the
change ;-)
> Having it all on one line allows me to double-check
> that i indeed queued up a patch in the intended topic branch. Had it
> read:
>
> [irq/urgent]: created 3786fc7: "printk: make variable static"
>
> i'd have noticed the mistake immediately.
>
> this welcome enhancement made me remember of three usage problems i had
> with Git recently:
>
> 1)
>
> Btw., it would be nice if there was an easier way to get a similar git
> log display in the ASCII space. For example i frequently ask the
> question "which topic branch did commit XYZ originate from?". All i have
> now is a pretty crude script that displays this for a given file:
>
> earth4:~/tip> tip-log --no-merges linus.. kernel/sched.c | grep ^#
> # core/kill-the-BKL: ffda12a: sched: optimize group load balancer
> # core/locking: ffda12a: sched: optimize group load balancer
> ...
>
> (see the script attached below)
>
> but it's very slow with 233 branches, obviously, so i only use it as a
> last resort mechanism.
>
> What i'd _love_ to see is just an ASCII representation of where a commit
> "came from" into the current branch. The first-hop branch it was
> committed to.
>
> it doesnt even have to be correct in the sha1 sense - i.e. it's enough
> for me if the merge commit log is parsed. (and hence it wont be correct
> if a branch ceases to exist or is renamed - but that is OK, i keep the
> branch space static)
>
> any ideas how to achieve that? I'd love to have output like this, if i
> do this from tip/master (the master integration branch):
>
If you have the branch-heads around, do "git branch --contains <sha1>".
If I understand the i386 tree correctly (integration branches are named
without slashes), you could pipe it to "grep /" to see only the
topic-branches that has it.
I imagine you'd want to use it to find out which branches you can (or
can't) merge, and in that case you need to know about all the topics
which have the commit. Assuming you don't go crazy cherry-picking and
criss-cross merging, it should only list a few. The output is not as
fancy as below, but it should be faster than the appended script (by
several orders of magnitude).
> # mockup
>
> earth4:~/tip> gll --no-merges kernel/sched.c
> ffda12a: [sched/core] sched: optimize group load balancer
> 8cd162c: [sched/clock] sched: only update rq->clock while holding
> 0a16b60: [tracing/sched] tracing, sched: LTTng instrumentation
> a5d8c34: [sched/debug] sched debug: add name to sched_domain sysctl entries
> 34b3ede: [sched/core] sched: remove redundant code in cpu_cgroup_create()
>
> ... and i dont want to embedd the branch name in every single commit.
>
> The semantics seem well-specified to me: walk down the merge tree a
> particular commit came from, and use the branch name that is mentioned
> in a merge commit's comment section 'closest' to this commit.
>
> That information is not 'trustable' in the sha1 sense because merge
> commits can be modified manually and because the momentary name of a
> branch might not be correct anymore - but with a sane topical setup this
> would be a very powerful visualization tool.
>
> It would be a nice tool that makes it easy to check the proper structure
> of topical branches, after the fact. Weird, incorrectly queued up
> commits would stick out _immediately_:
>
> 34b3ede: [x86/xen] sched: remove redundant code in cpu_cgroup_create()
>
> 2)
>
> and while at ASCII representation - this made me remember a problem i
> frequently have with octopus merges: it's _very_ difficult currently to
> 'backtrack' along a higher-order octopus in the git log ASCII space.
>
> I dont use the newfangled flashy GUIs all that frequently and i recently
> tried to go back to double-check the history of this order-21 octopus
> merge in the upstream Linux kernel:
>
> commit e496e3d645c93206faf61ff6005995ebd08cc39c
> Merge: b159d7a... 5bbd4c3... 175e438... 516cbf3... af2d237... 9b15684... 5b7e41f... 1befdef... a03352d... 7b22ff5... 2c7e9fd... 91030ca... dd55235... b3e15bd... 20211e4... efd327a... c7ffa6c... e51a1ac... 5df4551... d99e901... e621bd1...
> Author: Ingo Molnar <mingo@elte.hu>
> Date: Mon Oct 6 18:17:07 2008 +0200
>
> Merge branches 'x86/alternatives', 'x86/cleanups', 'x86/commandline', 'x86/crashdump', 'x86/debug', 'x86/defconfig', 'x86/doc', 'x86/exports', 'x86/fpu', 'x86/gart', 'x86/idle', 'x86/mm', 'x86/mtrr', 'x86/nmi-watchdog', 'x86/oprofile', 'x86/paravirt', 'x86/reboot', 'x86/sparse-fixes', 'x86/tsc', 'x86/urgent' and 'x86/vmalloc' into x86-v28-for-linus-phase1
>
> i wanted to know the history of the 'x86/idle' topical commits. But it
> was not easy to line up the sha1's to the branch names. So i had to
> manually edit the commit log, i manually lined up all 21 sha1's to each
> other, just to be able to figure out branch #11 in that lineup.
>
> Is there some more efficient way to do that? Perhaps some git log output
> that matches up the topic names with the sha1's? [for the cases where
> the octopus merge commit log message still has a reasonable format]
>
A mock-up of desired output would be good here. Perhaps something like this?
--%<--%<--
<X>-way octopus merge
x86/alternatives <abbrev sha1>: "<abbreviated x86/alternatives subject>"
x86/cleanups <abbrev sha1>: "<abbreviated x86/cleanups subject>"
Signed-off-by: ...
--%<--%<--
The subject for this says absolutely nothing, but it's not so long that it
can't be viewed comfortably either, and hopefully the author will amend
the subject with something suitable.
> 3)
>
> Similarly, when doing Octopus merges, and if the merge _fails_, it's
> hard to see exactly which branch failed. For example, when preparing for
> the v2.6.28 merge window i did something like this at a certain stage:
>
> git merge x86/alternatives x86/cleanups x86/commandline \
> x86/crashdump x86/debug x86/defconfig x86/doc \
> x86/exports x86/fpu x86/gart x86/xen x86/idle x86/mm \
> x86/mtrr x86/nmi-watchdog x86/oprofile x86/paravirt \
> x86/reboot x86/sparse-fixes x86/tsc x86/urgent \
> x86/vmalloc
>
> I got a conflicted octopus merge somewhere in the middle of it. But it
> only displayed sha1's when doing the merge. When i did a git log of that
> sha1 it was not obvious at first sight which current branch maps to that
> sha1. So i had to binary-search for the branch that caused the conflict
> (!), to figure out that in the above sequence the 'x86/xen' bit is what
> was causing trouble.
>
> It would be very nice if the Octopus merge tool displayed not only the
> sha1's that it is merging, but also the refspec that it is processing.
> And when it fails it would be nice if it displayed a for-dummies
> "Octopus merge failed when trying to merge x86/xen" kind of thing.
>
> So mapping back sha1's to topic branch names does not seem to be very
> easy at the moment. I realize that it is a fundamentally hard thing to
> do, and the information is not reliable because branch names are
> temporary - but in a sane branch setup it would be very nice to have
> tools for that, to keep topics nice and tidy, and to annotate git logs
> with the topical information.
>
Branch-names may be temporary, but we already record them for merge
messages so I don't see why we couldn't also use them when reporting
error messages but in a different format. I had a quick look at the
git-merge-octopus.sh but didn't find the obvious place to hack this
thing in, so I'll have to defer that to someone for whom this is a
more pressing need (hint ;-)), or who knows their way around gits
plumbing better than I do.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH v2] builtin-blame: Reencode commit messages according to git-log rules.
From: Alexander Gavrilov @ 2008-10-22 8:35 UTC (permalink / raw)
To: Jeff King; +Cc: git, Junio C Hamano
In-Reply-To: <20081022082016.GA18473@sigill.intra.peff.net>
On Wed, Oct 22, 2008 at 12:20 PM, Jeff King <peff@peff.net> wrote:
> On Wed, Oct 22, 2008 at 12:55:57AM +0400, Alexander Gavrilov wrote:
>
>> +test_expect_success \
>> + 'blame respects i18n.commitencoding' '
>> + git blame --incremental file | \
>> + grep "^\(author\|summary\) " > actual &&
>> + test_cmp actual expected
>
> Even though it is POSIX, using backslashed grouping in 'grep' isn't
> portable. It fails at least on Solaris 8, and you have to do:
>
> egrep "^(author|summary) "
>
> instead. Of course, I can't get your test to pass even with that change,
> but I think that is just a broken iconv on Solaris.
Hm, which of the conversions fail? You can try manually converting the
txt files with the iconv command to figure it out.
Alexander
^ permalink raw reply
* git archive
From: kenneth johansson @ 2008-10-22 8:42 UTC (permalink / raw)
To: git
I was going to make a tar of the latest stable linux kernel.
Done it before but now I got a strange problem.
>git archive --format=tar v2.6.27.2
fatal: Not a valid object name
this is the output from some other command on the same bare repository.
>git tag | grep 2.6.27.2
v2.6.27.2
>git cat-file -p v2.6.27.2
object 6bcd6d778419101dd96cbbdf03eeab8d779b1d66
type commit
tag v2.6.27.2
tagger Greg Kroah-Hartman <gregkh@suse.de> Sat Oct 18 10:58:00 2008 -0700
This is the v2.6.27.2 stable release
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
iEYEABECAAYFAkj6I6sACgkQMUfUDdst+ylcigCg0/e3kQZwAqLp6wPuPqdWl7nL
X0wAnjuNPJG1OqZfhMiAGccLx0QGvMQz
=INvo
-----END PGP SIGNATURE-----
>git cat-file -p 6bcd6d778419101dd96cbbdf03eeab8d779b1d66
tree a717af81e5a2e8a7ee36f3b80aa077965f570197
parent 6505670551fa3deeb6e5d7cab6983514384c7220
author Greg Kroah-Hartman <gregkh@suse.de> 1224352642 -0700
committer Greg Kroah-Hartman <gregkh@suse.de> 1224352642 -0700
Linux 2.6.27.2
>git archive --format=tar a717af81e5a2e8a7ee36f3b80aa077965f570197
fatal: not a tree object
>git cat-file -t a717af81e5a2e8a7ee36f3b80aa077965f570197
tree
^ permalink raw reply
* Re: [PATCH v2] builtin-blame: Reencode commit messages according to git-log rules.
From: Jeff King @ 2008-10-22 8:50 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: git, Junio C Hamano
In-Reply-To: <bb6f213e0810220135hd520f78odb83414c248a15e4@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 703 bytes --]
On Wed, Oct 22, 2008 at 12:35:17PM +0400, Alexander Gavrilov wrote:
> > instead. Of course, I can't get your test to pass even with that change,
> > but I think that is just a broken iconv on Solaris.
>
> Hm, which of the conversions fail? You can try manually converting the
> txt files with the iconv command to figure it out.
Test 2 fails for CP1251 and SJIS. Manually converting with iconv seems
to work ok (at least, doing "iconv -f CP1251 -t UTF-8 cp1251.txt"
produces the same output as "cat utf8.txt".
The output from "t8005-blame-i18n.sh -v -i" is attached (as
application/octet-stream to protect it from email munging) if that is
helpful to you. I can't make heads or tails of it.
-Peff
[-- Attachment #2: t8005-output.txt --]
[-- Type: application/octet-stream, Size: 1787 bytes --]
^ permalink raw reply
* Does a `git pull' write to the origin repository in any way?
From: Brett Ryan @ 2008-10-22 9:00 UTC (permalink / raw)
To: git
Greetings, the reason I ask this question is because my pattern of
development is to create local source git repositories on my home
directory, then pull them to the central location. I found myself
getting the error `unable to create temporary sha1 filename
.git/objects/11: File exists' which after investigation found that
there were paths in `.git/objects/' owned by root which is who I use
to do the pull from my home directory using sudo. `git log' shows all
commits as me.
Typical dev cycle.
cd ~/src/appl_bin
# make mods
git commit -a
cd $DEST
sudo git pull ~/src/appl_bin linux_test
Thankyou
-Brett
^ permalink raw reply
* Re: [irq/urgent]: created 3786fc7: "irq: make variable static"
From: Ingo Molnar @ 2008-10-22 9:00 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <48FEE5B3.9060202@op5.se>
* Andreas Ericsson <ae@op5.se> wrote:
> I imagine you'd want to use it to find out which branches you can (or
> can't) merge, and in that case you need to know about all the topics
> which have the commit. Assuming you don't go crazy cherry-picking and
> criss-cross merging, it should only list a few. The output is not as
> fancy as below, but it should be faster than the appended script (by
> several orders of magnitude).
i solved that particular problem quite well, based on suggestions in a
thread earlier on the git-list. I'm using git branch --no-merged:
earth4:~/tip> time todo-merge-all
merging the following updated branches:
merging linus ... ... merge done.
real 0m2.865s
user 0m2.580s
sys 0m0.228s
that work step used to be over a minute! There are 233 topic branches at
the moment and 18 integration branches. Kudos for making this go really
fast in 1.6.0.
the thing i'm after is to see the originator branch of changes. "git
name-rev" was suggested by Santi Béjar in this thread and that is
exactly what i need - i'll try to integrate it into some git-log-ish
output tool.
One thing i noticed is that 'git name-rev' can be quite slow for certain
commits:
earth4:~/tip> time git name-rev 948f984
948f984 tags/tip-safe-poison-pointers-2008-05-26_08_52_Mon~1
real 0m2.181s
user 0m2.068s
sys 0m0.092s
Which seems natural since it might have to dive back into history and
cross-reference it to all names. (there's 400 branches and 450 tags in
this tree, so i'm certainly pushing things!)
But if i use that in my git-log-line summary tool it might become
quadratic overhead (or worse) very quickly, with minutes of runtime.
Ingo
^ permalink raw reply
* Re: [PATCH v2] builtin-blame: Reencode commit messages according to git-log rules.
From: Alexander Gavrilov @ 2008-10-22 9:32 UTC (permalink / raw)
To: Jeff King; +Cc: git, Junio C Hamano
In-Reply-To: <20081022085036.GA1454@sigill.intra.peff.net>
On Wed, Oct 22, 2008 at 12:50 PM, Jeff King <peff@peff.net> wrote:
> On Wed, Oct 22, 2008 at 12:35:17PM +0400, Alexander Gavrilov wrote:
>
>> > instead. Of course, I can't get your test to pass even with that change,
>> > but I think that is just a broken iconv on Solaris.
>>
>> Hm, which of the conversions fail? You can try manually converting the
>> txt files with the iconv command to figure it out.
>
> Test 2 fails for CP1251 and SJIS. Manually converting with iconv seems
> to work ok (at least, doing "iconv -f CP1251 -t UTF-8 cp1251.txt"
> produces the same output as "cat utf8.txt".
>
> The output from "t8005-blame-i18n.sh -v -i" is attached (as
> application/octet-stream to protect it from email munging) if that is
> helpful to you. I can't make heads or tails of it.
>From the output it seems that what fails is "-f cp1251 -t sjis" and
"-f utf-8 -t sjis" (remember that blame --incremental produces its
output in reverse order compared to the order of commits). Unless
blame for some reason actually tries to convert to an entirely
different encoding. If tests 4 and 5 pass, you can try adding
--encoding=shift-jis to test 2 to check it.
Alexander
^ permalink raw reply
* Re: [irq/urgent]: created 3786fc7: "irq: make variable static"
From: Andreas Ericsson @ 2008-10-22 9:54 UTC (permalink / raw)
To: Ingo Molnar; +Cc: git
In-Reply-To: <20081022090010.GC4369@elte.hu>
Ingo Molnar wrote:
> * Andreas Ericsson <ae@op5.se> wrote:
>
>> I imagine you'd want to use it to find out which branches you can (or
>> can't) merge, and in that case you need to know about all the topics
>> which have the commit. Assuming you don't go crazy cherry-picking and
>> criss-cross merging, it should only list a few. The output is not as
>> fancy as below, but it should be faster than the appended script (by
>> several orders of magnitude).
>
> i solved that particular problem quite well, based on suggestions in a
> thread earlier on the git-list. I'm using git branch --no-merged:
>
> earth4:~/tip> time todo-merge-all
> merging the following updated branches:
> merging linus ... ... merge done.
>
> real 0m2.865s
> user 0m2.580s
> sys 0m0.228s
>
> that work step used to be over a minute! There are 233 topic branches at
> the moment and 18 integration branches. Kudos for making this go really
> fast in 1.6.0.
>
> the thing i'm after is to see the originator branch of changes. "git
> name-rev" was suggested by Santi Béjar in this thread and that is
> exactly what i need - i'll try to integrate it into some git-log-ish
> output tool.
>
> One thing i noticed is that 'git name-rev' can be quite slow for certain
> commits:
>
> earth4:~/tip> time git name-rev 948f984
> 948f984 tags/tip-safe-poison-pointers-2008-05-26_08_52_Mon~1
>
> real 0m2.181s
> user 0m2.068s
> sys 0m0.092s
>
> Which seems natural since it might have to dive back into history and
> cross-reference it to all names. (there's 400 branches and 450 tags in
> this tree, so i'm certainly pushing things!)
>
> But if i use that in my git-log-line summary tool it might become
> quadratic overhead (or worse) very quickly, with minutes of runtime.
>
What's the timing for "git branch --contains 948f984" ?
"git name-rev" parses a lot more just to be able to print a pretty
short-name (the reversed "git describe") for you to use.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [irq/urgent]: created 3786fc7: "irq: make variable static"
From: Ingo Molnar @ 2008-10-22 9:58 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <48FEF868.2010802@op5.se>
* Andreas Ericsson <ae@op5.se> wrote:
> Ingo Molnar wrote:
>> * Andreas Ericsson <ae@op5.se> wrote:
>>
>>> I imagine you'd want to use it to find out which branches you can (or
>>> can't) merge, and in that case you need to know about all the topics
>>> which have the commit. Assuming you don't go crazy cherry-picking and
>>> criss-cross merging, it should only list a few. The output is not as
>>> fancy as below, but it should be faster than the appended script (by
>>> several orders of magnitude).
>>
>> i solved that particular problem quite well, based on suggestions in a
>> thread earlier on the git-list. I'm using git branch --no-merged:
>>
>> earth4:~/tip> time todo-merge-all
>> merging the following updated branches:
>> merging linus ... ... merge done.
>>
>> real 0m2.865s
>> user 0m2.580s
>> sys 0m0.228s
>>
>> that work step used to be over a minute! There are 233 topic branches
>> at the moment and 18 integration branches. Kudos for making this go
>> really fast in 1.6.0.
>>
>> the thing i'm after is to see the originator branch of changes. "git
>> name-rev" was suggested by Santi Béjar in this thread and that is
>> exactly what i need - i'll try to integrate it into some git-log-ish
>> output tool.
>>
>> One thing i noticed is that 'git name-rev' can be quite slow for
>> certain commits:
>>
>> earth4:~/tip> time git name-rev 948f984
>> 948f984 tags/tip-safe-poison-pointers-2008-05-26_08_52_Mon~1
>>
>> real 0m2.181s
>> user 0m2.068s
>> sys 0m0.092s
>>
>> Which seems natural since it might have to dive back into history and
>> cross-reference it to all names. (there's 400 branches and 450 tags in
>> this tree, so i'm certainly pushing things!)
>>
>> But if i use that in my git-log-line summary tool it might become
>> quadratic overhead (or worse) very quickly, with minutes of runtime.
>>
>
> What's the timing for "git branch --contains 948f984" ?
>
> "git name-rev" parses a lot more just to be able to print a pretty
> short-name (the reversed "git describe") for you to use.
it takes much longer:
earth4:~/tip> time git branch --contains 948f984
[... 44 branches ...]
real 0m9.596s
user 0m9.151s
sys 0m0.218s
Ingo
^ permalink raw reply
* Re: [irq/urgent]: created 3786fc7: "irq: make variable static"
From: Jakub Narebski @ 2008-10-22 10:50 UTC (permalink / raw)
To: Ingo Molnar; +Cc: git
In-Reply-To: <20081022061730.GA5749@elte.hu>
Ingo Molnar <mingo@elte.hu> writes:
> Git recently started printing the branch name when creating commits:
>
> [irq/urgent]: created 3786fc7: "irq: make variable static"
>
> very nice idea IMO! Having it all on one line allows me to double-check
> that i indeed queued up a patch in the intended topic branch. Had it
> read:
>
> [irq/urgent]: created 3786fc7: "printk: make variable static"
>
> i'd have noticed the mistake immediately.
>
> this welcome enhancement made me remember of three usage problems i had
> with Git recently:
[...]
About printing either forward (git-describe, e.g. v1.6.0.2-590-g67f6062)
or backward (git-name-rev, e.g. tags/v1.6.0-rc2~8): you can use
git-name-rev in filter mode (git log ... | git name-rev --stdin), or
"git log --decorate", or '%d' in --pretty format specifier (this is very
new thing).
You might be also interested in --abbrev-commit (when used with
--pretty=oneline format), and --graph option to git-log (or
git-show-branch). The "(--merged | --no-merged | --contains) [<commit>]"
options to git-branch might be also of interest...
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git history and file moves
From: Alex Riesen @ 2008-10-22 11:19 UTC (permalink / raw)
To: Lin Ming; +Cc: git, Moore, Robert
In-Reply-To: <1224640967.14280.0.camel@minggr.sh.intel.com>
2008/10/22 Lin Ming <ming.m.lin@intel.com>:
> I'm looking for a way to move files to a new directory and have the
> full history follow the file automatically. Is this possible?
>
> I know about --follow, but I want the history to just follow the file
> transparently. ...
Of all Git tools, what does not do this "transparently" or "automatically"?
How more transparent do you imagine this?
What do you think should follow what?
I ask, because it is hard to understand what exactly is it you're missing:
merge support (which we have), git log listing the files as copied/renamed
(which is what --follow is for, and the suggestion for you is to make an
alias or something), git blame (ever looked at git gui blame?) or gitk
(which follows renames in default configuration)
> Also, we have a git web interface and we want the full
> history for the moved files to be available.
It is available. Whether it is shown is another question. git-web can
be improved (or just configured?)
^ permalink raw reply
* Re: [PATCH] git-fetch should not strip off ".git" extension
From: Leo Razoumov @ 2008-10-22 11:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Riesen, Andreas Ericsson, git
In-Reply-To: <7vd4htwp6v.fsf@gitster.siamese.dyndns.org>
On 10/21/08, Junio C Hamano <gitster@pobox.com> wrote:
> "Alex Riesen" <raa.lkml@gmail.com> writes:
>
> > 2008/10/21 Junio C Hamano <gitster@pobox.com>:
> >> "Leo Razoumov" <slonik.az@gmail.com> writes:
> >>
> >>> Even though the old behavior is "long established", it introduces
> >>> unnecessary ambiguity. If I have two repos
> >>> ...
> >>
> >> Of course. Now you know why people don't name such a pair of repositories
> >> like that ;-).
> >
> > FWIW, I support Leo on that. The "established" behavior is stupid.
>
>
> I am not inclined to respond to such an emotional argument. On the other
> hand, it is fair to say that the existing behaviour is established,
> because it is backed by a long history, which you can objectively verify.
>
> If you think about it deeper, you will realize that it is not even clear
> if it is "stupid".
>
> More importantly, the behaviour is consistent with the way how "git fetch"
> and "git clone" DWIMs the repository name by suffixing .git when the input
> lacks it. And this DWIMmery comes from the expectations that:
>
> (1) people name their repository project.git; and
>
> (2) people like using and seeing short names (iow, "clone
> git://$somewhere/project" is preferred over "clone
> git://$somewhere/project.git");
>
> If a repository whose real location is git://$somewhere/project.git is
> cloned/fetched as git://$somewhere/project by people, recording the merge
> source using the shorter name used by people to fetch from it is more
> consistent. The patch breaks this consistency [*1*].
>
> What is clear is that you would confuse yourself if you have two
> repositories A and A.git next to each other, and that is primarily because
> it breaks the above expectation.
>
> git core-level rarely imposes such policies, but what Porcelains do is a
> different matter.
>
> Hence the suggestion: don't do it.
>
> [Footnote]
>
> *1* It would be a different matter if the patch at the same time removed
> the fetch/clone DWIMmery. At least such a patch would be internally self
> consistent.
>
I think this discussion went in the direction of "correct" versus
"convent". I, personally, will choose correct over convenient any
time. Different people use git for different projects and their
expectations differ in this regard. In my case
after I do "git clone Foo.git" I get "Foo" repo side-by-side with
"Foo.git" and the ambiguity becomes apparent.
Regarding your footnote *1*. I agree with your suggestions and I can
improve the patch in the following way:
(1) Fetch/clone messages/comments will refer to the source/destination
repos by their complete names without stripping off any parts
(2) Searching for a source repo, clone/fetch will first try an exact
match and if it fails it will remove/add ".git" suffix and
^ permalink raw reply
* Re: [PATCH] git-fetch should not strip off ".git" extension
From: Leo Razoumov @ 2008-10-22 11:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Riesen, Andreas Ericsson, git
In-Reply-To: <7vd4htwp6v.fsf@gitster.siamese.dyndns.org>
My apologies!! I hit send button by mistake before message was
complete. Please, see below a completed version.
--Leo--
On 10/21/08, Junio C Hamano <gitster@pobox.com> wrote:
> "Alex Riesen" <raa.lkml@gmail.com> writes:
>
> > 2008/10/21 Junio C Hamano <gitster@pobox.com>:
> >> "Leo Razoumov" <slonik.az@gmail.com> writes:
> >>
> >>> Even though the old behavior is "long established", it introduces
> >>> unnecessary ambiguity. If I have two repos
> >>> ...
> >>
> >> Of course. Now you know why people don't name such a pair of repositories
> >> like that ;-).
> >
> > FWIW, I support Leo on that. The "established" behavior is stupid.
>
>
> I am not inclined to respond to such an emotional argument. On the other
> hand, it is fair to say that the existing behaviour is established,
> because it is backed by a long history, which you can objectively verify.
>
> If you think about it deeper, you will realize that it is not even clear
> if it is "stupid".
>
> More importantly, the behaviour is consistent with the way how "git fetch"
> and "git clone" DWIMs the repository name by suffixing .git when the input
> lacks it. And this DWIMmery comes from the expectations that:
>
> (1) people name their repository project.git; and
>
> (2) people like using and seeing short names (iow, "clone
> git://$somewhere/project" is preferred over "clone
> git://$somewhere/project.git");
>
> If a repository whose real location is git://$somewhere/project.git is
> cloned/fetched as git://$somewhere/project by people, recording the merge
> source using the shorter name used by people to fetch from it is more
> consistent. The patch breaks this consistency [*1*].
>
> What is clear is that you would confuse yourself if you have two
> repositories A and A.git next to each other, and that is primarily because
> it breaks the above expectation.
>
> git core-level rarely imposes such policies, but what Porcelains do is a
> different matter.
>
> Hence the suggestion: don't do it.
>
> [Footnote]
>
> *1* It would be a different matter if the patch at the same time removed
> the fetch/clone DWIMmery. At least such a patch would be internally self
> consistent.
>
I think this discussion went in the direction of "correct" versus
"convent". I, personally, will choose correct over convenient any
time. Different people use git for different projects and their
expectations differ in this regard. In my case
after I do "git clone Foo.git" I get "Foo" repo side-by-side with
"Foo.git" and the ambiguity becomes apparent.
Regarding your footnote *1*. I agree with your suggestions and I can
improve the patch in the following way:
(P1) Fetch/clone messages/records will refer to the source/destination
repos by their complete names without stripping off any parts of the name.
(P2) Searching for a source repo, clone/fetch will first try an exact
match and if it fails it will remove/add ".git" suffix as needed and retry.
Item (P2) will provide the convenience, while item (P1) still
guarantees correctness.
Please, let me know if such approach is more satisfactory.
--Leo--
^ permalink raw reply
* Re: git history and file moves
From: Michael J Gruber @ 2008-10-22 12:38 UTC (permalink / raw)
To: Lin Ming; +Cc: Alex Riesen, git, Moore, Robert
In-Reply-To: <81b0412b0810220419q43f6985fs1c608e3d3cbcf8f3@mail.gmail.com>
Alex Riesen venit, vidit, dixit 10/22/08 13:19:
> 2008/10/22 Lin Ming <ming.m.lin@intel.com>:
>> I'm looking for a way to move files to a new directory and have the
>> full history follow the file automatically. Is this possible?
>>
>> I know about --follow, but I want the history to just follow the file
>> transparently. ...
>
> Of all Git tools, what does not do this "transparently" or "automatically"?
> How more transparent do you imagine this?
> What do you think should follow what?
>
> I ask, because it is hard to understand what exactly is it you're missing:
> merge support (which we have), git log listing the files as copied/renamed
> (which is what --follow is for, and the suggestion for you is to make an
> alias or something), git blame (ever looked at git gui blame?) or gitk
> (which follows renames in default configuration)
>
>> Also, we have a git web interface and we want the full
>> history for the moved files to be available.
>
> It is available. Whether it is shown is another question. git-web can
> be improved (or just configured?)
By default, gitweb uses "-M" for diff. You can specify all options (-C,
-CC, -B) using "@diff_opts" in the config file for gitweb.cgi - if that
is what you are using. Is it?
Anyways, using default configs for git log and gitweb.cgi both of them
show the full history (renames, history before and after) for me here,
using current git (1.6.0.3.514.g2f91b). What is your setup?
Michael
^ permalink raw reply
* Re: [PATCH v2] builtin-blame: Reencode commit messages according to git-log rules.
From: Jeff King @ 2008-10-22 12:39 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: git, Junio C Hamano
In-Reply-To: <bb6f213e0810220232p2e7fe3daoa32f46fbe5bef2ac@mail.gmail.com>
On Wed, Oct 22, 2008 at 01:32:56PM +0400, Alexander Gavrilov wrote:
> From the output it seems that what fails is "-f cp1251 -t sjis" and
> "-f utf-8 -t sjis" (remember that blame --incremental produces its
Oh, indeed. Converting to and from utf-8 seems to work, but not between
cp1251 and sjis:
$ iconv -f SJIS -t UTF-8 sjis.txt | sed s/SJIS/UTF8/ >test &&
> cmp test utf8.txt && echo ok
ok
$ iconv -f UTF-8 -t SJIS utf8.txt | sed s/UTF8/SJIS/ >test &&
> cmp test sjis.txt && echo ok
ok
$ iconv -f SJIS -t CP1251 sjis.txt
Not supported SJIS to CP1251
$ iconv -f CP1251 -t SJIS cp1251.txt
Not supported CP1251 to SJIS
So I think it is simply a limitation of the platform with respect to the
particular encodings used. There is a similar problem in t3900, I think,
with EUCJP and ISO-2022-JP. I assume one _can_ install these encodings
for Solaris, but the admins of my box haven't done so (and this is a
production box that I can't ask for such things on).
> blame for some reason actually tries to convert to an entirely
> different encoding. If tests 4 and 5 pass, you can try adding
> --encoding=shift-jis to test 2 to check it.
Tests 2, 3, and 4 fail. Test 5 does pass.
-Peff
^ permalink raw reply
* Re: [PATCH] rebase-i-p: delay saving current-commit to REWRITTEN if squashing
From: Jeff King @ 2008-10-22 12:51 UTC (permalink / raw)
To: Stephen Haberman; +Cc: gitster, git
In-Reply-To: <759654ef1f1781cd2b102e21c6f972b065560398.1224055978.git.stephen@exigencecorp.com>
On Wed, Oct 15, 2008 at 02:44:36AM -0500, Stephen Haberman wrote:
> + if [ "$fast_forward" == "t" ]
This one even fails on my Linux box. :) "==" is a bash-ism.
-Peff
^ permalink raw reply
* Re: git archive
From: Deskin Miller @ 2008-10-22 13:08 UTC (permalink / raw)
To: kenneth johansson; +Cc: git
In-Reply-To: <gdmp0p$92r$1@ger.gmane.org>
On Wed, Oct 22, 2008 at 08:42:01AM +0000, kenneth johansson wrote:
> I was going to make a tar of the latest stable linux kernel.
> Done it before but now I got a strange problem.
>
> >git archive --format=tar v2.6.27.2
> fatal: Not a valid object name
I had the same thing happen to me, while trying to make an archive of Git.
Were you perchance working in a bare repository, as I was? I spent some time
looking at it and I think git archive sets up the environment in the wrong
order, though of course I never finished a patch so I'm going from memory:
After looking at the code again, I think the issue is that git_config is called
in builtin-archive.c:cmd_archive before setup_git_directory is called in
archive.c:write_archive. The former ends up setting GIT_DIR to be '.git' even
if you're in a bare repository. My coding skills weren't up to fixing it
easily; moving setup_git_directory before git_config in builtin-archive caused
last test of t5000 to fail: GIT_DIR=some/nonexistent/path git archive --list
should still display the archive formats.
Another vote for from me for the discussion carried on here:
http://article.gmane.org/gmane.comp.version-control.git/98800
Deskin Miller
^ permalink raw reply
* Re: git add --patch newfile doesn't add newfile to cache ?
From: Marc Weber @ 2008-10-22 13:12 UTC (permalink / raw)
To: git
In-Reply-To: <20081020235049.GA23120@coredump.intra.peff.net>
On Mon, Oct 20, 2008 at 07:50:50PM -0400, Jeff King wrote:
> On Mon, Oct 20, 2008 at 04:36:36PM +0200, Marc Weber wrote:
>
> > Is this desired behaviour?
> > [...]
> > git init
> > echo test > test
> > git add --patch test
> > echo "running status, nothing has been added"
> > git status
>
> I think your example makes sense, but nobody ever really tried it
> before. [..]
I came across this use case because I'm lazy. eg
git add --patch file-to-be-committed-partly newfile
is shorter than
git add --patch file-to-be-committed-partly
git add newfile
> I use "git add -p" all the time, but almost always when I am
> adding a new file, I add the whole contents.
>
> I think there are two ways to go about fixing it:
>
> - in git-add--interactive.perl, the function patch_update_cmd
> explicitly looks at the list of modified files. It would have to
> also check for untracked files, which is easy. But we also need to
> keep track of which files are modified and which are untracked
> through the whole patching procedure, which is a bit more invasive.
>
> - the recently-added "git add -N" adds an empty file into the index,
> at which point we could add content in the normal way. So:
>
> git add -N test
> git add -p test
>
> should just work (but obviously requires two steps from the user).
> You could do something more automatic like the patch below, but I
> think the semantics aren't quite right. If you stage nothing for a
> newly added file, then you still end up with an empty version of the
> staged file in the index. I would expect the semantics to be:
>
> 1. if you stage any content, then the file is added to the index
> with that content
>
> 2. if you stage no content, then the file remains untracked
> ---
> diff --git a/git-add--interactive.perl b/git-add--interactive.perl
> [...]
> sub patch_update_cmd {
> + my @new = list_untracked();
> + if (@new) {
> + system(qw(git add -N), @new)
> + and die "git add reported failure";
> + }
> +
I've tried the patch. However I'm not fully satisified.
I often use --patch to have another second look at each change to be
committed. Your patch adds new files to the cache silently without
giving the user the change to omit or edit the patch. But exatly that's
the reason I'm using --patch. So maybe I can work on this in some days..
Maybe I've also injected those lines into the wrong git version
(1.6.0.2.GIT)
May I try rewriting your semantics proposal to this ?
1) when using git add --patch untracked-file the user should be
given the default patch view (only containing + lines)
so that he can use edit to only commit parts of the file in the
usual way. (I guess this is similar to having used git add -N
before, I haven't tried yet)
2) if he wants to skip the entire patch / file nothing should be
added to the index.
Thanks for your reply.
Sincerly
Marc Weber
^ permalink raw reply
* Re: [irq/urgent]: created 3786fc7: "irq: make variable static"
From: Jeff King @ 2008-10-22 13:21 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Ingo Molnar, git
In-Reply-To: <m3ljwgj3xy.fsf@localhost.localdomain>
On Wed, Oct 22, 2008 at 03:50:52AM -0700, Jakub Narebski wrote:
> About printing either forward (git-describe, e.g. v1.6.0.2-590-g67f6062)
> or backward (git-name-rev, e.g. tags/v1.6.0-rc2~8): you can use
> git-name-rev in filter mode (git log ... | git name-rev --stdin), or
> "git log --decorate", or '%d' in --pretty format specifier (this is very
> new thing).
The "--decorate" and "%d" code just decorates branch _tips_. My
impression is that he wanted to see the branch mentioned even if the
commit was not at the tip. It would be possible to extend this to print
name-rev output, but it would be computationally and memory-intensive, I
suspect.
-Peff
^ permalink raw reply
* Re: Does a `git pull' write to the origin repository in any way?
From: Marc Weber @ 2008-10-22 13:25 UTC (permalink / raw)
To: git
In-Reply-To: <a65d095e0810220200q42936427o917cdac067d04135@mail.gmail.com>
On Wed, Oct 22, 2008 at 08:00:11PM +1100, Brett Ryan wrote:
> Greetings, the reason I ask this question is because my pattern of
> development is to create local source git repositories on my home
> directory, then pull them to the central location. I found myself
> getting the error `unable to create temporary sha1 filename
> .git/objects/11: File exists' which after investigation found that
> there were paths in `.git/objects/' owned by root which is who I use
> to do the pull from my home directory using sudo.
Aeh.. about which repo are you talking here? I guess it's not the one
owned by root because otherwise this would be normal..
Hi Brett, I'm not sure where the problem comes form. But I feel your dev
cycle is kind of wired.
If you can login as root using ssh you can also do it the "normal" (?)
way:
# user dir
git remote add root_repo ssh://root@localhost/path-to-root-repo
git pull root_repo # then resolve conflicts if any
git push root_repo # update the root repo
This way you always have conflicts in your local repo and never on the
root one which is preferable (IMHO)..
git-fetch doesn't list a way to access another repo by "su(do)" which
might be the best way here ? This could be convinient because you
would'nt have to setup an extra group to access the same repo as root
and user (?)
You're right that git pull *should not* modify any files from the repo
its pulling from.. But I don't know enough about git internals to say
more about this. All I know is that git clone might have created some
hardlinks.. But I'm not sure how this interfers with file permissions.
I hope someone else can give a more accurate reply.
Marc Weber
^ permalink raw reply
* Re: git add --patch newfile doesn't add newfile to cache ?
From: Jeff King @ 2008-10-22 13:29 UTC (permalink / raw)
To: Marc Weber; +Cc: git
In-Reply-To: <20081022131232.GL3988@gmx.de>
On Wed, Oct 22, 2008 at 03:12:32PM +0200, Marc Weber wrote:
> > sub patch_update_cmd {
> > + my @new = list_untracked();
> > + if (@new) {
> > + system(qw(git add -N), @new)
> > + and die "git add reported failure";
> > + }
> > +
>
>
> I've tried the patch. However I'm not fully satisified.
> I often use --patch to have another second look at each change to be
> committed. Your patch adds new files to the cache silently without
> giving the user the change to omit or edit the patch. But exatly that's
> the reason I'm using --patch. So maybe I can work on this in some days..
> Maybe I've also injected those lines into the wrong git version
> (1.6.0.2.GIT)
Yes, you need to use the current 'master' branch for the "-N" feature.
The point of "-N" is to say "this is a file I want to track, but don't
add any contents yet." So it does your part 1:
> 1) when using git add --patch untracked-file the user should be
> given the default patch view (only containing + lines)
> so that he can use edit to only commit parts of the file in the
> usual way. (I guess this is similar to having used git add -N
> before, I haven't tried yet)
But not your part 2:
> 2) if he wants to skip the entire patch / file nothing should be
> added to the index.
If you add _no_ contents, you still end up with the "this is a file I
want to track" part, but with no contents. And I agree it should stage
nothing, which is why this is an unsatisfactory solution (and why I
didn't clean up the patch and send it to Junio for inclusion).
-Peff
^ permalink raw reply
* Re: [PATCH] rehabilitate 'git index-pack' inside the object store
From: Nguyen Thai Ngoc Duy @ 2008-10-22 14:04 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Nicolas Pitre, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0810211856090.22125@pacific.mpi-cbg.de.mpi-cbg.de>
On 10/22/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> So I propose this change in semantics:
>
> - setup_git_directory_gently(): rename to discover_git_directory(),
> and avoid any chdir() at all.
> - setup_git_directory(): keep the semantics that it chdir()s to the
> worktree, or to the git directory for bare repositories.
>
> Using _gently() even for RUN_SETUP builtins should solve the long standing
> pager problem, too.
One more thing: "git foo -h" with RUN_SETUP won't run if repository is
not found. Maybe just drop RUN_SETUP and let subcommands call
setup_git_directory()
--
Duy
^ 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