* Re: [PATCH] Builtin-commit: show on which branch a commit was added
From: Andreas Ericsson @ 2008-09-30 6:13 UTC (permalink / raw)
To: Jeff King; +Cc: Pieter de Bie, Junio C Hamano, Git Mailinglist
In-Reply-To: <20080929224430.GA11545@sigill.intra.peff.net>
Jeff King wrote:
> On Mon, Sep 29, 2008 at 10:09:17PM +0200, Pieter de Bie wrote:
>
>> How about something like
>>
>> Created commit abcd1234 on widget -- "subwidget: one line summary"
>
> I think that is probably just trading one visual problem for another.
> That is, there are other people will have the same problem with "--"
> that I had with ": ".
>
Created 6207abc (subwidget: one quite long line of sum...) on <branch>
"commit" is just noise. Parentheses are often used to extemporize when
using normal written language so it should work well here too.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] explicitly set LANG to 'C' in for guilt run-tests
From: Josef 'Jeff' Sipek @ 2008-09-30 4:42 UTC (permalink / raw)
To: Mikael Magnusson; +Cc: Scott Moser, git
In-Reply-To: <237967ef0809291325p7a0e3581vac348a1e99dbd4ed@mail.gmail.com>
On Mon, Sep 29, 2008 at 10:25:48PM +0200, Mikael Magnusson wrote:
...
> If I'm not mistaken, $LANG is used as the ultimate fallback, while LC_ALL is
> the one that overrides all others, so you probably want to set LC_ALL. I'm
> unsure which off the specific ones would apply here, but very likely it's
> LC_COLLATE. In other words, if LC_ALL is set, it is used, otherwise if
> LC_COLLATE is set it is used, otherwise if LANG is set, it is used,
> otherwise, "POSIX" is used.
I fixed up the patch to set LC_ALL instead, and committed it.
Thanks,
Josef 'Jeff' Sipek.
--
Humans were created by water to transport it upward.
^ permalink raw reply
* [JGIT PATCH] index-pack: Detect SHA-1 hash collisions to avoid replacing objects
From: Shawn O. Pearce @ 2008-09-30 3:54 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
When indexing a pack file coming in from the network there may
be an object contained in the pack that we already have. Its
only safe to retain that object in our newly stored pack if it
exactly matches the content we already have on disk. Storing
a different content for the same object name runs the risk of
allowing a malicious attacker to replace an object in our store.
Data validation is performed the first time we have the object
in memory, which occurs when we first compute its SHA-1. This
is the earliest opportunity we have to validate that there is
no collision, and it reduces the number of times we need to do
a read for an object. However our memory usage when we process
a whole object is now increased as the collision test is done
by loading the entire object into memory. Future improvements
may permit a streaming compare of the objects.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
This is only the first in what will be a series to add basic fsck
support to jgit. My day-job application is accepting untrusted
input through IndexPack so I need to fully validate the objects
are sane before I can allow them to enter the local repository.
In the end we'll honor receive.fsckObjects. But right now this
is enough to detect evil SHA-1 collisions, and is the same level
of protection that git.git's index-pack has.
I'm offering this up for comment because its done and ready for
inclusion. The rest of the object fsck rules are going to take
a bit more time, but I hope to have most of them done tomorrow or
the day after.
.../src/org/spearce/jgit/transport/IndexPack.java | 63 +++++++++++++++++---
1 files changed, 54 insertions(+), 9 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/transport/IndexPack.java b/org.spearce.jgit/src/org/spearce/jgit/transport/IndexPack.java
index bc52896..8a66ec9 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/transport/IndexPack.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/transport/IndexPack.java
@@ -375,6 +375,7 @@ private void resolveDeltas(final long pos, final int oldCRC, int type,
objectDigest.update(data);
tempObjectId.fromRaw(objectDigest.digest(), 0);
+ verifyNoCollision(type, data);
oe = new PackedObjectInfo(pos, crc32, tempObjectId);
entries[entryCount++] = oe;
}
@@ -622,7 +623,7 @@ private void indexOneObject() throws IOException {
r = new ArrayList<UnresolvedDelta>(8);
baseByPos.put(base, r);
}
- inflateFromInput(false);
+ skipInflateFromInput(sz);
r.add(new UnresolvedDelta(pos, (int) crc.getValue()));
deltaCount++;
break;
@@ -637,7 +638,7 @@ private void indexOneObject() throws IOException {
r = new ArrayList<UnresolvedDelta>(8);
baseById.put(base, r);
}
- inflateFromInput(false);
+ skipInflateFromInput(sz);
r.add(new UnresolvedDelta(pos, (int) crc.getValue()));
deltaCount++;
break;
@@ -649,17 +650,30 @@ private void indexOneObject() throws IOException {
private void whole(final int type, final long pos, final long sz)
throws IOException {
+ final byte[] data = inflateFromInput(sz);
objectDigest.update(Constants.encodedTypeString(type));
objectDigest.update((byte) ' ');
objectDigest.update(Constants.encodeASCII(sz));
objectDigest.update((byte) 0);
- inflateFromInput(true);
+ objectDigest.update(data);
tempObjectId.fromRaw(objectDigest.digest(), 0);
+ verifyNoCollision(type, data);
final int crc32 = (int) crc.getValue();
entries[entryCount++] = new PackedObjectInfo(pos, crc32, tempObjectId);
}
+ private void verifyNoCollision(final int type, final byte[] data)
+ throws IOException {
+ final ObjectLoader ldr = repo.openObject(tempObjectId);
+ if (ldr != null) {
+ final byte[] existingData = ldr.getCachedBytes();
+ if (ldr.getType() != type || !Arrays.equals(data, existingData)) {
+ throw new IOException("collision in " + tempObjectId.name());
+ }
+ }
+ }
+
// Current position of {@link #bOffset} within the entire file.
private long position() {
return bBase + bOffset;
@@ -747,7 +761,7 @@ private void sync() throws IOException {
bOffset = 0;
}
- private void inflateFromInput(final boolean digest) throws IOException {
+ private void skipInflateFromInput(long sz) throws IOException {
final Inflater inf = inflater;
try {
final byte[] dst = objectData;
@@ -765,21 +779,52 @@ private void inflateFromInput(final boolean digest) throws IOException {
int free = dst.length - n;
if (free < 8) {
- if (digest)
- objectDigest.update(dst, 0, n);
+ sz -= n;
n = 0;
free = dst.length;
}
-
n += inf.inflate(dst, n, free);
}
- if (digest)
- objectDigest.update(dst, 0, n);
+ if (n != sz)
+ throw new DataFormatException("wrong decompressed length");
+ n = bAvail - inf.getRemaining();
+ if (n > 0) {
+ crc.update(buf, p, n);
+ use(n);
+ }
+ } catch (DataFormatException dfe) {
+ throw corrupt(dfe);
+ } finally {
+ inf.reset();
+ }
+ }
+
+ private byte[] inflateFromInput(final long sz) throws IOException {
+ final byte[] dst = new byte[(int) sz];
+ final Inflater inf = inflater;
+ try {
+ int n = 0;
+ int p = -1;
+ while (!inf.finished()) {
+ if (inf.needsInput()) {
+ if (p >= 0) {
+ crc.update(buf, p, bAvail);
+ use(bAvail);
+ }
+ p = fillFromInput(1);
+ inf.setInput(buf, p, bAvail);
+ }
+
+ n += inf.inflate(dst, n, dst.length - n);
+ }
+ if (n != sz)
+ throw new DataFormatException("wrong decompressed length");
n = bAvail - inf.getRemaining();
if (n > 0) {
crc.update(buf, p, n);
use(n);
}
+ return dst;
} catch (DataFormatException dfe) {
throw corrupt(dfe);
} finally {
--
1.6.0.2.513.g6dbd
^ permalink raw reply related
* Re: Bug? git svn fetch: "unable to create temporary sha1 filename /home/andres/git/public/crystal.git/objects/96: File exists"
From: Andres Freund @ 2008-09-30 0:23 UTC (permalink / raw)
To: git
In-Reply-To: <200809300210.00285.andres@anarazel.de>
[-- Attachment #1: Type: text/plain, Size: 825 bytes --]
On Tuesday 30 September 2008, Andres Freund wrote in "Bug? git svn fetch:
"unable to create temporary sha1 filename
/home/andres/git/public/crystal.git/objects/96: File exists"":
> First failing svn fetch:
> M plugins/cscript/pycore/coremod.cpp
> M plugins/cscript/cspython/pytocs.cpp
> error: unable to create temporary sha1 filename
> /home/andres/git/public/crystal.git/objects/96: File exists
>
> fatal: Unable to add /tmp/Git_zIIUG4 to database
> hash-object -w --stdin-paths: command returned error: 128
>
> error closing pipe: Bad file descriptor at
> /usr/local/libexec/git-core/git-svn line 0
> error closing pipe: Bad file descriptor at
> /usr/local/libexec/git-core/git-svn line 0
After repacking the repository the problem is gone. Really rather strange.
Andres
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 1/6] gitweb: action in path with use_pathinfo
From: Jakub Narebski @ 2008-09-30 0:21 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Petr Baudis, Lea Wiemann
In-Reply-To: <cb7bb73a0809290722w5ed92171v98d6b83a7dae8f8b@mail.gmail.com>
On Mon, 29 Sep 2008, Giuseppe Bilotta wrote:
> On Mon, Sep 29, 2008 at 3:03 AM, Jakub Narebski <jnareb@gmail.com> wrote:
>> On Sun, 21 Sep 2008, Giuseppe Bilotta wrote:
>> Also, from what I understand, generated pathinfo links now always
>> use action, so they are a tiny little bit longer.
>
> Is that a problem, by the way? I've had half-thoughts about making the
> action implicit when possible, but I'm afraid that's prone to make the
> code way more complex and the path info handling much less robust.
No, I don't think there is a problem; if I remember correctly action
is omitted for default actions with and without project, i.e. for
projects list, and for 'summary' view for a project, which is default
view in absence of other parameters.
I would explain difference between then and now in the patch adding
support for _creating_ wider range of path_info links (I don't know,
perhaps you did that in new version):
* path_info URL were always without action, and were possible only
for the case of default action (projects list, summary), and in the
case of implicit action ('tree' for trees i.e. filename ending in
'/'; 'blob_plain' for ordinary files i.e. filename but no '/' at end;
'shortlog' for bare ref, assuming branch).
* now that pathinfo can contain action, wider range of URL can be done
as purely path_info links; in other way more of parameters can be put
in path_info part.
Perhaps not in so large and detailed form... I guess explanation of
using ':/' as separator should be put there as well, if you plan to
squash those patches.
>>> ---
>>> gitweb/gitweb.perl | 109 ++++++++++++++++++++++++++++++++++------------------
>>> 1 files changed, 72 insertions(+), 37 deletions(-)
>>>
>>> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
>>> index da474d0..e783d12 100755
>>> --- a/gitweb/gitweb.perl
>>> +++ b/gitweb/gitweb.perl
>> Well, you could instead split hash declaration from defining it,
>> in the form of
>>
>> my %actions = ();
>> ...
>> %actions = (
>> ...
>> );
>>
>> but I guess moving declaration earlier is good solution.
>
> Is there some coding style recommendation wrt this situations, or is
> it just a matter of making the patch smaller?
I think that moving %actions earlier is a better solution.
>>> # now read PATH_INFO and use it as alternative to parameters
>>> sub evaluate_path_info {
>>> return if defined $project;
>>> @@ -512,6 +543,16 @@ sub evaluate_path_info {
>>> # do not change any parameters if an action is given using the query string
>>> return if $action;
>>> $path_info =~ s,^\Q$project\E/*,,;
>>> +
>>> + # next comes the action
>>> + $action = $path_info;
>>> + $action =~ s,/.*$,,;
>>
>> I would use perhaps "($action) = ($path_info =~ m!^([^/]+)!);"
>> But that is Perl, so TIMTOWDI.
>
> Well, Perl is not my native language so I tend to stay away from
> complex expressions if possible ;-)
What I meant is instead of "copy and strip" use "find match".
I tried to use one-liner, but it could be written instead as:
+ # next comes the action
+ if ($path_info =~ m!^([^/]+)!) {;
+ $action = $1;
+ }
But I guess your approach is equally valid. I don't think of myself
being a Perl expert, either.
>>> @@ -525,10 +566,12 @@ sub evaluate_path_info {
>>> }
>>> $hash_base ||= validate_refname($refname);
>>> $file_name ||= validate_pathname($pathname);
>>> + $hash ||= git_get_hash_by_path($hash_base, $file_name);
>>
>> I don't understand why you feel that you need to do this (this is
>> additional git command fork, as git_get_hash_by_path calls Git, to
>> be more exact it calls git-ls-tree (it could call git-rev-parse
>> instead). Moreover, I don't understand why you need to do this _here_,
>> instead of just before where you would have to have $hash variable set.
>
> Hm. I must confess that I honestly don't remember. The same holds for
> the other chunks you have perplexities on. When I started writing
> these patches I came across a few situations where $hash wouldn't
> carry over properly, but now I can't seem to recreate those issues
> anymore, which leads me to suspect it was a problem with hand-crafted
> links (i.e. before I coded the link generation part too). I'll resend
> without these chunks.
That is the problem, but not as large a problem as having similar code
calling git_get_hash_by_path() during link generation, in href(...)
subroutine (at least without Lea's gitweb caching, the part that reuses
"git cat-file --batch"). This is called once per view (page); that
was called once per generated gitweb link...
>>> @@ -624,8 +636,13 @@ sub href (%) {
>>> if ($params{-replay}) {
>>> while (my ($name, $symbol) = each %mapping) {
>>> if (!exists $params{$name}) {
>>> - # to allow for multivalued params we use arrayref form
>>> - $params{$name} = [ $cgi->param($symbol) ];
>>> + if ($cgi->param($symbol)) {
>>> + # to allow for multivalued params we use arrayref form
>>> + $params{$name} = [ $cgi->param($symbol) ];
>>> + } else {
>>> + no strict 'refs';
>>> + $params{$name} = $$name if $$name;
>>> + }
>>> }
>>> }
>>> }
>>
>> What this change is about? And why this change is _here_, in this
>> commit? It is I think unrelated, and wrong change.
>
> This is about being able to recycle CGI parameters that came through
> as part of path_info instead of the CGI parameter list. It might not
> be the best way to recover it, though. I *did* have a few thoughts
> about an alternative way that consisted of build a parameter list
> merging CGI and path-info parameter, but since this approach seemed to
> work, I went with it.
Fact, I have totally forgot about this.
>> href(..., -replay=>1) is all about reusing current URL, perhaps with
>> a few parameters changed, like for example pagination links differ only
>> in page number param change. For example if we had only hb= and f=
>> parameters, -replay=>1 links should use only those, and not add h=
>> parameter because somewhere we felt that we need $hash to be calculated.
>
> Assume for example that you are to an url such as
>
> http://git.oblomov.eu/git/tree/refs/remotes/origin/master:gitweb
>
> Without this patch, the 'history' link on the second header line links
> to ARRAY(0xblah)ARRAY(0xblah). With this patch, it shows the proper
> link. So either replay is being abused somewhere in the link
> generation code, or this CGI+path_info parameter retrieval is
> necessary, one way or the other.
Ah. Now I understand.
When creating code for href(..., -replay=>1), which by the way I thought
would be more useful than actually is, I have forgot that parameters to
gitweb could be passed in other way that through CGI parameters
(CGI query)[1].
Using
$params{$name} = [ $cgi->param($symbol) ];
is a cute hack, but it doesn't work for arguments passed via path_info
(was: project, hash_base and file_name; while now it is project, action,
hash_base (in full) and file_name).
The solution I thought about and abandoned in favor of this cute hack
was to have additional hash (in addition to %mapping), which would map
action names to references to variables holding the value for parameter.
This has the same problem as your proposed solution of putting some
parameters which didn't come from URL but were filled from other info.
$hash parameter is most likely to be culprit here.
On the other hand it is more generic and doesn't rely on knowledge that
there is no multi-valued parameter which can be expressed in path_info
(currently only 'opt' parameter can be multi-valued, and requires
arrayref, but also 'opt' parameter is and cannot be put in path_info).
I am talking there about the following solution:
my %action_vars = (
project => \$project,
action => \$action,
# ...
extra_options => \@extra_options,
);
# ...
while (my ($name, $symbol) = each %mapping) {
if (!exists $params{$name}) {
$params{$name} = ${$action_vars{$name}};
}
}
This avoids cure hack of (from your code)
} else {
no strict 'refs';
$params{$name} = $$name if $$name;
}
I think that gitweb should use single source, not CGI query parameters
or variable saving [sanitized] value.
[*1*] Currently parameters can be passed either as CGI query parameters
(which I remember about), but also (with some restrictions) in the
path_info part of gitweb URLs. If we implement command line
switches (for example to generate directory listing in format
expected by gitweb for file $projects_list, or for off-line
generation of RSS feed), there could be yet another source.
>>> @@ -636,10 +653,28 @@ sub href (%) {
>>> + # next, we put either hash_base:file_name or hash
>>> + if (defined $params{'hash_base'}) {
>>> + $href .= "/".esc_url($params{'hash_base'});
>>> + if (defined $params{'file_name'}) {
>>> + $href .= ":".esc_url($params{'file_name'});
>>> + delete $params{'hash'} if $params{'hash'} eq git_get_hash_by_path($params{'hash_base'},$params{'file_name'});
>>
>> First, this page has around 140 characters. That is too long, much too long.
>> Please try to wrap code around 80-characters.
>>
>> Second, following Petr 'Pasky' Baudis suggestion of reducing complexity
>> and shortening gitweb URLs, we could unconditionally remove redundant
>> 'hash' parameter if we have both 'hash_base' and 'file_name'
>> parameters. This would also simplify and speed up (lack of extra fork)
>> gitweb code.
>
> If it's indeed guaranteed that hash is not needed in these cases, it's
> surely the best course of action. I changed the code to that effect.
Hash is not needed for hash_base:file_name, unless you messed up
something (by hand-crafting URL). If they do not much, you have more
problems than that...
>> Hmmm... now I am not so sure if it wouldn't be better to split this
>> patch in pathinfo parsing and pathinfo generation. The first part
>> would be obvious, the second part would be smaller and easier to review.
>
> Ok, I'll split parsing from generation. Since it's what I did for
> subsequent extensions (such as the parent..current thing) it also fits
> nicely with the patchflow.
Thanks.
--
Jakub Narebski
Poland
^ permalink raw reply
* Bug? git svn fetch: "unable to create temporary sha1 filename /home/andres/git/public/crystal.git/objects/96: File exists"
From: Andres Freund @ 2008-09-30 0:09 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 2164 bytes --]
Hi,
I regularly run git-svn fetch on some mirrors of svn repositories - which
works quite well.
But now I started to get this error:
Last successfull git svn fetch:
M src/z3c/form/browser/file-testing.txt
r91613 = 27c991067847b4a54a4d8bc71d440c74893475af (trunk)
From .
c7c32b3..27c9910 trunk -> trunk
First failing svn fetch:
M plugins/cscript/pycore/coremod.cpp
M plugins/cscript/cspython/pytocs.cpp
error: unable to create temporary sha1 filename
/home/andres/git/public/crystal.git/objects/96: File exists
fatal: Unable to add /tmp/Git_zIIUG4 to database
hash-object -w --stdin-paths: command returned error: 128
error closing pipe: Bad file descriptor at /usr/local/libexec/git-core/git-svn
line 0
error closing pipe: Bad file descriptor at /usr/local/libexec/git-core/git-svn
line 0
M src/z3c/form/tests/test_doc.py
r91624 = 6a9a5c03c44618ca1cc34cf428c94b25009c6fc4 (trunk)
A src/z3c/form/testing.txt
r91625 = a10508daf71d4e8aaad5531f5bcf8cb4ef0695e8 (trunk)
From .
27c9910..a10508d trunk -> trunk
All further git svn fetch invocation result in something alike:
Index mismatch: c8858cc0b587ab638af9ed52e7c03c8966b7db63 !=
c32a46c51a046500a3765fe573b95e2eb2f44b2a
rereading 87e2a16d8c259eba290bde0512af4d6bc1f64d1f
M plugins/cscript/pycore/coremod.cpp
M plugins/cscript/cspython/pytocs.cpp
error: unable to create temporary sha1 filename
/home/andres/git/public/crystal.git/objects/96: File exists
fatal: Unable to add /tmp/Git_YSlrAs to database
hash-object -w --stdin-paths: command returned error: 128
error closing pipe: Bad file descriptor at /usr/local/libexec/git-core/git-svn
line 0
error closing pipe: Bad file descriptor at /usr/local/libexec/git-core/git-svn
line 0
svn fetch is always invocated as "git --bare svn fetch".
Git repository is located at:
git://git.anarazel.de/crystal.git
http://git.anarazel.de/git/crystal.git
Original svn repository is located at:
https://crystal.svn.sourceforge.net/svnroot/crystal
Any idea?
Thanks,
Andres
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH v2] Add OS X support to the pre-auto-gc example hook
From: Jonathan del Strother @ 2008-09-29 23:36 UTC (permalink / raw)
To: git; +Cc: Miklos Vajna, Jonathan del Strother
In-Reply-To: <57518fd10809270253s4c07318bjd54c7d86460ce7d7@mail.gmail.com>
Signed-off-by: Jonathan del Strother <jon.delStrother@bestbefore.tv>
---
Second attempt - this simplifies the test while making it more specific (it will only pack when on AC power, rather than, say, UPS).
contrib/hooks/pre-auto-gc-battery | 10 +++++++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/contrib/hooks/pre-auto-gc-battery b/contrib/hooks/pre-auto-gc-battery
index 0096f57..b0a8caa 100644
--- a/contrib/hooks/pre-auto-gc-battery
+++ b/contrib/hooks/pre-auto-gc-battery
@@ -1,9 +1,9 @@
#!/bin/sh
#
# An example hook script to verify if you are on battery, in case you
-# are running Linux. Called by git-gc --auto with no arguments. The hook
-# should exit with non-zero status after issuing an appropriate message
-# if it wants to stop the auto repacking.
+# are running Linux or OS X. Called by git-gc --auto with no arguments.
+# The hook should exit with non-zero status after issuing an appropriate
+# message if it wants to stop the auto repacking.
#
# This hook is stored in the contrib/hooks directory. Your distribution
# may have put this somewhere else. If you want to use this hook, you
@@ -30,6 +30,10 @@ then
elif grep -q '0x01$' /proc/apm 2>/dev/null
then
exit 0
+elif test -x /usr/bin/pmset && /usr/bin/pmset -g batt |
+ grep -q "Currently drawing from 'AC Power'"
+then
+ exit 0
fi
echo "Auto packing deferred; not on AC"
--
1.6.0.2.308.gd442a.dirty
^ permalink raw reply related
* [PATCH 1/1] Replace svn.foo.org with svn.example.com in git-svn docs (RFC 2606)
From: Michael Prokop @ 2008-09-29 23:01 UTC (permalink / raw)
To: git; +Cc: Michael Prokop
foo.org is an existing domain, use RFC 2606 complying example.com instead
as used in other docs as well.
Signed-off-by: Michael Prokop <mika@grml.org>
---
Documentation/git-svn.txt | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 1e644ca..82d03b4 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -473,7 +473,7 @@ Tracking and contributing to the trunk of a Subversion-managed project:
------------------------------------------------------------------------
# Clone a repo (like git clone):
- git svn clone http://svn.foo.org/project/trunk
+ git svn clone http://svn.example.com/project/trunk
# Enter the newly cloned directory:
cd trunk
# You should be on master branch, double-check with git-branch
@@ -495,7 +495,7 @@ Tracking and contributing to an entire Subversion-managed project
------------------------------------------------------------------------
# Clone a repo (like git clone):
- git svn clone http://svn.foo.org/project -T trunk -b branches -t tags
+ git svn clone http://svn.example.com/project -T trunk -b branches -t tags
# View all branches and tags you have cloned:
git branch -r
# Reset your master to trunk (or any other branch, replacing 'trunk'
@@ -514,7 +514,7 @@ have each person clone that repository with 'git-clone':
------------------------------------------------------------------------
# Do the initial import on a server
- ssh server "cd /pub && git svn clone http://svn.foo.org/project
+ ssh server "cd /pub && git svn clone http://svn.example.com/project
# Clone locally - make sure the refs/remotes/ space matches the server
mkdir project
cd project
@@ -523,7 +523,7 @@ have each person clone that repository with 'git-clone':
git config --add remote.origin.fetch '+refs/remotes/*:refs/remotes/*'
git fetch
# Initialize git-svn locally (be sure to use the same URL and -T/-b/-t options as were used on server)
- git svn init http://svn.foo.org/project
+ git svn init http://svn.example.com/project
# Pull the latest changes from Subversion
git svn rebase
------------------------------------------------------------------------
--
1.5.6.5
^ permalink raw reply related
* Re: [PATCH 2/6] gitweb: use_pathinfo filenames start with /
From: Jakub Narebski @ 2008-09-29 23:20 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Petr Baudis, Lea Wiemann
In-Reply-To: <cb7bb73a0809290712g324ec015r70fd868b91673645@mail.gmail.com>
On Mon, 29 Sep 2008, Giuseppe Bilotta wrote:
> On Mon, Sep 29, 2008 at 3:08 AM, Jakub Narebski <jnareb@gmail.com> wrote:
>> On Sun, 21 Sep 2008, Giuseppe Bilotta wrote:
>>> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
>>> index e783d12..18da484 100755
>>> --- a/gitweb/gitweb.perl
>>> +++ b/gitweb/gitweb.perl
>>> @@ -664,7 +664,7 @@ sub href (%) {
>>> if (defined $params{'hash_base'}) {
>>> $href .= "/".esc_url($params{'hash_base'});
>>> if (defined $params{'file_name'}) {
>>> - $href .= ":".esc_url($params{'file_name'});
>>> + $href .= ":/".esc_url($params{'file_name'});
>>> delete $params{'hash'} if $params{'hash'} eq git_get_hash_by_path($params{'hash_base'},$params{'file_name'});
>>> delete $params{'file_name'};
>>> } else {
>>> --
>>> 1.5.6.5
>>
>> Is there reason why this change is separate (not squashed) from
>> previous commit?
>
> Historical reason (i.e. I came up with the idea later on). I'll squash it.
Hn. Now I am not sure if it should be squashed, or should be separate.
Good change.
Please don't forget to describe this decision, i.e. why gitweb is
using "branch:/filename" when creating path_info links instead of
simple "branch:name" for relative URLs in HTML in 'raw' ('blob_plain')
view, in the commit message. Thanks in advance.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] Builtin-commit: show on which branch a commit was added
From: Jeff King @ 2008-09-29 22:44 UTC (permalink / raw)
To: Pieter de Bie; +Cc: Junio C Hamano, Git Mailinglist
In-Reply-To: <A36A4B61-D223-4821-9969-FA76EAECD1EC@ai.rug.nl>
On Mon, Sep 29, 2008 at 10:09:17PM +0200, Pieter de Bie wrote:
> How about something like
>
> Created commit abcd1234 on widget -- "subwidget: one line summary"
I think that is probably just trading one visual problem for another.
That is, there are other people will have the same problem with "--"
that I had with ": ".
And of course it doesn't deal with the line length issues.
Anyway, I seem to be the only one complaining, so perhaps it should just
be left as-is.
-Peff
^ permalink raw reply
* [PATCH] diff.c: remove duplicate bibtex pattern introduced by merge 92bb9785
From: Brandon Casey @ 2008-09-29 21:52 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Git Mailing List
In-Reply-To: <ZOivOHIiBa1yoDqFPq18uB0VuTttUsV4lS5k7YcyEsM@cipher.nrlssc.navy.mil>
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
diff.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/diff.c b/diff.c
index b001d7b..7c982b4 100644
--- a/diff.c
+++ b/diff.c
@@ -1439,8 +1439,6 @@ static const struct funcname_pattern_entry builtin_funcname_pattern[] = {
{ "python", "^[ \t]*((class|def)[ \t].*)$", REG_EXTENDED },
{ "ruby", "^[ \t]*((class|module|def)[ \t].*)$",
REG_EXTENDED },
- { "bibtex", "(@[a-zA-Z]{1,}[ \t]*\\{{0,1}[ \t]*[^ \t\"@',\\#}{~%]*).*$",
- REG_EXTENDED },
{ "tex",
"^(\\\\((sub)*section|chapter|part)\\*{0,1}\\{.*)$",
REG_EXTENDED },
--
1.6.0.2.323.g7c850
^ permalink raw reply related
* Re: [PATCH] explicitly set LANG to 'C' in for guilt run-tests
From: Scott Moser @ 2008-09-29 21:01 UTC (permalink / raw)
To: Josef Jeff Sipek; +Cc: Mikael Magnusson, git
In-Reply-To: <20080929204958.GD31590@josefsipek.net>
On Mon, 29 Sep 2008, Josef Jeff Sipek wrote:
> > If I'm not mistaken, $LANG is used as the ultimate fallback, while LC_ALL is
> > the one that overrides all others, so you probably want to set LC_ALL. I'm
> > unsure which off the specific ones would apply here, but very likely it's
> > LC_COLLATE. In other words, if LC_ALL is set, it is used, otherwise if
> > LC_COLLATE is set it is used, otherwise if LANG is set, it is used,
> > otherwise, "POSIX" is used.
>
> IIRC, my devel system has all of them set to UTF8, _except_ LC_COLLATE (I
> like the case sensitive sort of filenames in ls(1)) which I have set to "C".
> So chances are that the minimum required is LC_COLLATE=C, but overriding
> everything might be safer overall.
>
Yeah, LC_ALL I sprobably correct. I'm not very "LANG" aware at all. I
just noticed that test 052 didn't run on my system, and figured out that
was why.
You want a re-send of this patch with LC_ALL ? Or do you want to make
the modification yourself and apply?
Scott
^ permalink raw reply
* Re: [PATCH] explicitly set LANG to 'C' in for guilt run-tests
From: Josef Jeff Sipek @ 2008-09-29 20:49 UTC (permalink / raw)
To: Mikael Magnusson; +Cc: Scott Moser, git
In-Reply-To: <237967ef0809291325p7a0e3581vac348a1e99dbd4ed@mail.gmail.com>
On Mon, Sep 29, 2008 at 10:25:48PM +0200, Mikael Magnusson wrote:
> 2008/9/29 Scott Moser <smoser@brickies.net>:
> > The output of guilt's run-tests is dependent on LANG due to reliance on a
> > given sorting algorithm. Currently, the test '052' will fail if LANG is
> > set to 'en_US.UTF-8' (and likely others values).
> >
> > Remove the assumption by explicitly setting this in run-tests.
> >
> > Signed-off-by: Scott Moser <smoser@brickies.net>
> > ---
> > regression/run-tests | 1 +
> > 1 files changed, 1 insertions(+), 0 deletions(-)
> >
> > diff --git a/regression/run-tests b/regression/run-tests
> > index 8f572eb..945150b 100755
> > --- a/regression/run-tests
> > +++ b/regression/run-tests
> > @@ -2,6 +2,7 @@
> >
> > export REG_DIR="$PWD"
> > export PATH="$PWD/bin:$PATH"
> > +export LANG=C
> >
> > source scaffold
> >
> > --
> > 1.5.6.3
>
> If I'm not mistaken, $LANG is used as the ultimate fallback, while LC_ALL is
> the one that overrides all others, so you probably want to set LC_ALL. I'm
> unsure which off the specific ones would apply here, but very likely it's
> LC_COLLATE. In other words, if LC_ALL is set, it is used, otherwise if
> LC_COLLATE is set it is used, otherwise if LANG is set, it is used,
> otherwise, "POSIX" is used.
IIRC, my devel system has all of them set to UTF8, _except_ LC_COLLATE (I
like the case sensitive sort of filenames in ls(1)) which I have set to "C".
So chances are that the minimum required is LC_COLLATE=C, but overriding
everything might be safer overall.
Josef 'Jeff' Sipek.
--
Penguin : Linux version 2.6.25.4 on an i386 machine (6135.73 BogoMips).
^ permalink raw reply
* Re: [PATCH] explicitly set LANG to 'C' in for guilt run-tests
From: Mikael Magnusson @ 2008-09-29 20:25 UTC (permalink / raw)
To: Scott Moser; +Cc: Josef Jeff Sipek, git
In-Reply-To: <1222714272-9557-1-git-send-email-smoser@brickies.net>
2008/9/29 Scott Moser <smoser@brickies.net>:
> The output of guilt's run-tests is dependent on LANG due to reliance on a
> given sorting algorithm. Currently, the test '052' will fail if LANG is
> set to 'en_US.UTF-8' (and likely others values).
>
> Remove the assumption by explicitly setting this in run-tests.
>
> Signed-off-by: Scott Moser <smoser@brickies.net>
> ---
> regression/run-tests | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/regression/run-tests b/regression/run-tests
> index 8f572eb..945150b 100755
> --- a/regression/run-tests
> +++ b/regression/run-tests
> @@ -2,6 +2,7 @@
>
> export REG_DIR="$PWD"
> export PATH="$PWD/bin:$PATH"
> +export LANG=C
>
> source scaffold
>
> --
> 1.5.6.3
If I'm not mistaken, $LANG is used as the ultimate fallback, while LC_ALL is
the one that overrides all others, so you probably want to set LC_ALL. I'm
unsure which off the specific ones would apply here, but very likely it's
LC_COLLATE. In other words, if LC_ALL is set, it is used, otherwise if
LC_COLLATE is set it is used, otherwise if LANG is set, it is used,
otherwise, "POSIX" is used.
--
Mikael Magnusson
^ permalink raw reply
* [PATCH] Typos.
From: Ralf Wildenhues @ 2008-09-29 20:30 UTC (permalink / raw)
To: git
---
Documentation/RelNotes-1.6.1.txt | 4 ++--
Documentation/git-read-tree.txt | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/RelNotes-1.6.1.txt b/Documentation/RelNotes-1.6.1.txt
index 421e569..906932c 100644
--- a/Documentation/RelNotes-1.6.1.txt
+++ b/Documentation/RelNotes-1.6.1.txt
@@ -59,7 +59,7 @@ on.
* "git daemon" learned --max-connections=<count> option.
-* "git diff" learned to mimick --suppress-blank-empty from GNU diff via a
+* "git diff" learned to mimic --suppress-blank-empty from GNU diff via a
configuration option.
* "git diff" learned to put more sensible hunk headers for Python and
@@ -121,7 +121,7 @@ release, unless otherwise noted.
is a path in it).
* "git diff --stdin" used to take two trees on a line and compared them,
- but we droppped support for such a use case long time ago. This has
+ but we dropped support for such a use case long time ago. This has
been resurrected.
* "git filter-branch" failed to rewrite a tag name with slashes in it.
diff --git a/Documentation/git-read-tree.txt b/Documentation/git-read-tree.txt
index 309deac..7160fa1 100644
--- a/Documentation/git-read-tree.txt
+++ b/Documentation/git-read-tree.txt
@@ -212,7 +212,7 @@ output after two-tree merge.
Case #3 is slightly tricky and needs explanation. The result from this
rule logically should be to remove the path if the user staged the removal
-of the path and then swiching to a new branch. That however will prevent
+of the path and then switching to a new branch. That however will prevent
the initial checkout from happening, so the rule is modified to use M (new
tree) only when the contents of the index is empty. Otherwise the removal
of the path is kept as long as $H and $M are the same.
--
1.6.0.1.309.g48068
^ permalink raw reply related
* Re: [PATCH] remove vim syntax highlighting in favor of upstream
From: Jeff King @ 2008-09-29 20:12 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: Shawn O. Pearce, git
In-Reply-To: <20080929200814.GA19840@neumann>
On Mon, Sep 29, 2008 at 10:08:14PM +0200, SZEDER Gábor wrote:
> Here it is. Since significant parts of the patch and the commit
> message are from Jeff, maybe he should sign off, too?
I think all of my changes were deletions, so I'm not sure there is any
copyright to claim. ;) But:
Signed-off-by: Jeff King <peff@peff.net>
> Note, that this patch is slightly different from the previous one, as
> it proposes writing the auto-detect commands into ~/.vim/filetype.vim
> instead of ~/.vimrc. It's not quite clear to me why, but it seems to
> resolve the filetype confusion I mentioned in my previous email.
I haven't really tested this at all, as I have been running vim 7.2 for
a while now. But presumably it works for you, and hey, it's only
contrib/. :)
-Peff
^ permalink raw reply
* Re: [PATCH] Builtin-commit: show on which branch a commit was added
From: Pieter de Bie @ 2008-09-29 20:09 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Git Mailinglist
In-Reply-To: <20080921104238.GA9217@sigill.intra.peff.net>
(Sorry for a late response)
On 21 sep 2008, at 12:42, Jeff King wrote:
> OK, I have lived with it for a little while, and I am still
> annoyed. ;)
>
> My complaints are:
>
> 1. It wastes more horizontal screen real estate, making it more
> likely
> that the line will wrap.
>
> 2. In almost all of my projects (including git), I use the subject
> line convention of "subsystem: one line summary". So you end up
> with the visually confusing:
>
> Created commit abcd1234 on master: subsystem: one line summary
>
> which is even worse on a topic branch which is meaningful to the
> project:
>
> Created commit abcd1234 on widget: subwidget: one line summary
>
> which has literally left me scratching my head wondering why I put
> "widget" into the commit message.
How about something like
Created commit abcd1234 on widget -- "subwidget: one line summary"
?
> Maybe it is better to simply break the line, which solves both
> problems.
> Something like:
I don't like a multi-line approach.. I tried it myself, and the second
line
makes the first line easier to overlook
- Pieter
^ permalink raw reply
* [PATCH] remove vim syntax highlighting in favor of upstream
From: SZEDER Gábor @ 2008-09-29 20:08 UTC (permalink / raw)
To: Shawn O. Pearce, Jeff King; +Cc: vim, git
In-Reply-To: <20080929145542.GA18340@spearce.org>
As of version 7.2, vim ships with its own syntax
highlighting for git commit messages, which is:
1. more comprehensive in splitting up the various
components of the file
2. in accordance with the usual vim behavior for syntax
highlighting (e.g., respecting b:current_syntax)
3. presumably better maintained (I have not been using
what's in git's contrib/ directory for some time in
favor of the upstream version)
Furthermore, vim upsream also provides syntax highlighting
for other git filetypes (gitconfig, rebase, send-email).
This patch gets rid of our local version and just points
interested parties to the upstream version.
The code for auto-detecting filetypes is taken from vim's
runtime/filetype.vim.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
---
On Mon, Sep 29, 2008 at 07:55:42AM -0700, Shawn O. Pearce wrote:
> Missing SBO line?
Here it is. Since significant parts of the patch and the commit
message are from Jeff, maybe he should sign off, too?
Note, that this patch is slightly different from the previous one, as
it proposes writing the auto-detect commands into ~/.vim/filetype.vim
instead of ~/.vimrc. It's not quite clear to me why, but it seems to
resolve the filetype confusion I mentioned in my previous email.
contrib/vim/README | 38 ++++++++++++++++++++++++++++++--------
contrib/vim/syntax/gitcommit.vim | 18 ------------------
2 files changed, 30 insertions(+), 26 deletions(-)
delete mode 100644 contrib/vim/syntax/gitcommit.vim
diff --git a/contrib/vim/README b/contrib/vim/README
index 9e7881f..c487346 100644
--- a/contrib/vim/README
+++ b/contrib/vim/README
@@ -1,8 +1,30 @@
-To syntax highlight git's commit messages, you need to:
- 1. Copy syntax/gitcommit.vim to vim's syntax directory:
- $ mkdir -p $HOME/.vim/syntax
- $ cp syntax/gitcommit.vim $HOME/.vim/syntax
- 2. Auto-detect the editing of git commit files:
- $ cat >>$HOME/.vimrc <<'EOF'
- autocmd BufNewFile,BufRead COMMIT_EDITMSG set filetype=gitcommit
- EOF
+Syntax highlighting for git commit messages, config files, etc. is
+included with the vim distribution as of vim 7.2, and should work
+automatically.
+
+If you have an older version of vim, you can get the latest syntax
+files from the vim project:
+
+ http://vim.svn.sourceforge.net/viewvc/vim/trunk/runtime/syntax/git.vim
+ http://vim.svn.sourceforge.net/viewvc/vim/trunk/runtime/syntax/gitcommit.vim
+ http://vim.svn.sourceforge.net/viewvc/vim/trunk/runtime/syntax/gitconfig.vim
+ http://vim.svn.sourceforge.net/viewvc/vim/trunk/runtime/syntax/gitrebase.vim
+ http://vim.svn.sourceforge.net/viewvc/vim/trunk/runtime/syntax/gitsendemail.vim
+
+To install:
+
+ 1. Copy these files to vim's syntax directory $HOME/.vim/syntax
+ 2. To auto-detect the editing of various git-related filetypes:
+ $ cat >>$HOME/.vim/filetype.vim <<'EOF'
+ autocmd BufNewFile,BufRead *.git/COMMIT_EDITMSG setf gitcommit
+ autocmd BufNewFile,BufRead *.git/config,.gitconfig setf gitconfig
+ autocmd BufNewFile,BufRead git-rebase-todo setf gitrebase
+ autocmd BufNewFile,BufRead .msg.[0-9]*
+ \ if getline(1) =~ '^From.*# This line is ignored.$' |
+ \ setf gitsendemail |
+ \ endif
+ autocmd BufNewFile,BufRead *.git/**
+ \ if getline(1) =~ '^\x\{40\}\>\|^ref: ' |
+ \ setf git |
+ \ endif
+ EOF
diff --git a/contrib/vim/syntax/gitcommit.vim b/contrib/vim/syntax/gitcommit.vim
deleted file mode 100644
index 332121b..0000000
--- a/contrib/vim/syntax/gitcommit.vim
+++ /dev/null
@@ -1,18 +0,0 @@
-syn region gitLine start=/^#/ end=/$/
-syn region gitCommit start=/^# Changes to be committed:$/ end=/^#$/ contains=gitHead,gitCommitFile
-syn region gitHead contained start=/^# (.*)/ end=/^#$/
-syn region gitChanged start=/^# Changed but not updated:/ end=/^#$/ contains=gitHead,gitChangedFile
-syn region gitUntracked start=/^# Untracked files:/ end=/^#$/ contains=gitHead,gitUntrackedFile
-
-syn match gitCommitFile contained /^#\t.*/hs=s+2
-syn match gitChangedFile contained /^#\t.*/hs=s+2
-syn match gitUntrackedFile contained /^#\t.*/hs=s+2
-
-hi def link gitLine Comment
-hi def link gitCommit Comment
-hi def link gitChanged Comment
-hi def link gitHead Comment
-hi def link gitUntracked Comment
-hi def link gitCommitFile Type
-hi def link gitChangedFile Constant
-hi def link gitUntrackedFile Constant
--
1.6.0.2.330.gcef5c
^ permalink raw reply related
* [PATCH] fix guilt-pop and push to fail if no relevant patches
From: Scott Moser @ 2008-09-29 18:51 UTC (permalink / raw)
To: Josef "Jeff" Sipek; +Cc: git, Scott Moser
currently guilt-pop and guilt-push will exit with '0' if there are no more
relevant patches in the series (ie, if you've pushed or popped all of them)
This means that you cannot do something like:
while guilt-push; do
guilt refresh || break
done
for reference, quilt does exit with non-zero in those cases:
$ quilt push -a && quilt push
File series fully applied, ends at patch my.patch
$ echo $?
1
$ quilt pop -a; quilt pop
No patch removed
$ echo $?
2
Signed-off-by: Scott Moser <smoser@brickies.net>
---
guilt-pop | 3 +--
guilt-push | 43 ++++++++++++++++++++++++-------------------
regression/t-021.out | 3 +++
3 files changed, 28 insertions(+), 21 deletions(-)
diff --git a/guilt-pop b/guilt-pop
index db8473e..8a83fdb 100755
--- a/guilt-pop
+++ b/guilt-pop
@@ -45,8 +45,7 @@ patch="$1"
[ ! -z "$all" ] && patch="-a"
if [ ! -s "$applied" ]; then
- disp "No patches applied."
- exit 0
+ die "No patches applied."
elif [ "$patch" = "-a" ]; then
# we are supposed to pop all patches
diff --git a/guilt-push b/guilt-push
index 018f9ac..48f886b 100755
--- a/guilt-push
+++ b/guilt-push
@@ -97,22 +97,27 @@ fi
sidx=`wc -l < $applied`
sidx=`expr $sidx + 1`
-get_series | sed -n -e "${sidx},${eidx}p" | while read p
-do
- disp "Applying patch..$p"
- if [ ! -f "$GUILT_DIR/$branch/$p" ]; then
- die "Patch $p does not exist. Aborting."
- fi
-
- push_patch "$p" $abort_flag
-
- # bail if necessary
- if [ $? -eq 0 ]; then
- disp "Patch applied."
- elif [ -z "$abort_flag" ]; then
- die "Patch applied with rejects. Fix it up, and refresh."
- else
- die "To force apply this patch, use 'guilt push -f'"
- fi
-done
-
+get_series | sed -n -e "${sidx},${eidx}p" |
+ {
+ did_patch=0
+ while read p
+ do
+ disp "Applying patch..$p"
+ if [ ! -f "$GUILT_DIR/$branch/$p" ]; then
+ die "Patch $p does not exist. Aborting."
+ fi
+
+ push_patch "$p" $abort_flag
+
+ # bail if necessary
+ if [ $? -eq 0 ]; then
+ disp "Patch applied."
+ elif [ -z "$abort_flag" ]; then
+ die "Patch applied with rejects. Fix it up, and refresh."
+ else
+ die "To force apply this patch, use 'guilt push -f'"
+ fi
+ did_patch=1
+ done
+ [ $did_patch -ge 1 ] || die "no patches to apply"
+ }
diff --git a/regression/t-021.out b/regression/t-021.out
index cd8ae96..44771cb 100644
--- a/regression/t-021.out
+++ b/regression/t-021.out
@@ -822,6 +822,7 @@ index 0000000..8baef1b
@@ -0,0 +1 @@
+abc
% guilt-push --all
+no patches to apply
% guilt-pop -n -1
Invalid number of patches to pop.
% list_files
@@ -908,6 +909,7 @@ index 0000000..8baef1b
@@ -0,0 +1 @@
+abc
% guilt-push --all
+no patches to apply
% guilt-pop -n 0
No patches requested to be removed.
% list_files
@@ -994,6 +996,7 @@ index 0000000..8baef1b
@@ -0,0 +1 @@
+abc
% guilt-push --all
+no patches to apply
% guilt-pop -n 1
Now at remove.
% list_files
--
1.5.6.3
^ permalink raw reply related
* [PATCH] explicitly set LANG to 'C' in for guilt run-tests
From: Scott Moser @ 2008-09-29 18:51 UTC (permalink / raw)
To: Josef "Jeff" Sipek; +Cc: git, Scott Moser
The output of guilt's run-tests is dependent on LANG due to reliance on a
given sorting algorithm. Currently, the test '052' will fail if LANG is
set to 'en_US.UTF-8' (and likely others values).
Remove the assumption by explicitly setting this in run-tests.
Signed-off-by: Scott Moser <smoser@brickies.net>
---
regression/run-tests | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/regression/run-tests b/regression/run-tests
index 8f572eb..945150b 100755
--- a/regression/run-tests
+++ b/regression/run-tests
@@ -2,6 +2,7 @@
export REG_DIR="$PWD"
export PATH="$PWD/bin:$PATH"
+export LANG=C
source scaffold
--
1.5.6.3
^ permalink raw reply related
* What's cooking in git/spearce.git (Sep 2008, #04; Mon, 22)
From: Shawn O. Pearce @ 2008-09-29 18:47 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'.
The topics list the commits in reverse chronological order. The topics
meant to be merged to the maintenance series have "maint-" in their names.
I'll be on vacation til Oct 08; proposal/review/discussion/improvement
cycle based on e-mails and the distributed nature of git mean that it
shouldn't keep the participants from further improving the system. I've
asked Shawn to look after in-flight patches during the time, so hopefully
when I come back I'll see a much better git ;-).
----------------------------------------------------------------
[New Topics]
* nd/narrow (Sun Sep 14 20:07:59 2008 +0700) 9 commits
- grep: skip files that have not been checked out
- checkout_entry(): CE_NO_CHECKOUT on checked out entries.
- Prevent diff machinery from examining worktree outside narrow
checkout
- Add tests for updating no-checkout entries in index
- ls-files: add --narrow-checkout option to "will checkout" entries
- update-index: add --checkout/--no-checkout to update
CE_NO_CHECKOUT bit
- update-index: refactor mark_valid() in preparation for new options
- Introduce CE_NO_CHECKOUT bit
- Extend index to save more flags
This is an early half of the earlier series (I haven't had chance to look
at the updated series yet), and should be replaced with the updated one
posted recently.
----------------------------------------------------------------
[Stalled -- Needs Action to Proceed (or to be dropped)]
* pb/submodule (Fri Sep 12 23:09:19 2008 +0200) 1 commit
- t7400: Add short "git submodule add" testsuite
Waiting for a reroll.
* bd/blame (Thu Aug 21 18:22:01 2008 -0500) 5 commits
- Use xdiff caching to improve git blame performance
- Allow xdiff machinery to cache hash results for a file
- Always initialize xpparam_t to 0
- Bypass textual patch generation and parsing in git blame
- Allow alternate "low-level" emit function from xdl_diff
Réne had good comments on how the callback should be structured.
* kb/am-directory (Fri Aug 29 15:27:50 2008 -0700) 1 commit
- git-am: Pass the --directory option through to git-apply
I think this is still buggy and drops the option when am stops with
conflicts.
----------------------------------------------------------------
[Will be merged to 'master/maint' soon]
* mv/merge-recursive (Sat Sep 6 18:29:49 2008 +0200) 11 commits
+ builtin-merge: release the lockfile in try_merge_strategy()
+ merge-recursive: get rid of virtual_id
+ merge-recursive: move current_{file,directory}_set to struct
merge_options
+ merge-recursive: move the global obuf to struct merge_options
+ merge-recursive: get rid of the index_only global variable
+ merge-recursive: move call_depth to struct merge_options
+ cherry-pick/revert: make direct internal call to merge_tree()
+ builtin-merge: avoid run_command_v_opt() for recursive and subtree
+ merge-recursive: introduce merge_options
+ merge-recursive.c: Add more generic merge_recursive_generic()
+ Split out merge_recursive() to merge-recursive.c
(Tip at 4271666)
* ho/dirstat-by-file (Fri Sep 5 22:27:35 2008 +0300) 1 commit
+ diff --dirstat-by-file: count changed files, not lines
(Tip at fd33777)
* jc/safe-c-l-d (Tue Sep 2 14:10:15 2008 -0700) 1 commit
+ safe_create_leading_directories(): make it about "leading"
directories
(Tip at 5f0bdf5)
* jc/apply-include-exclude (Mon Aug 25 01:05:31 2008 -0700) 1 commit
+ git-apply:--include=pathspec
(Tip at 6ecb1ee)
* mv/commit-tree (Wed Sep 10 22:10:33 2008 +0200) 3 commits
+ t7603: add new testcases to ensure builtin-commit uses
reduce_heads()
+ builtin-commit: use commit_tree()
+ commit_tree(): add a new author parameter
(Tip at 7a172b0)
* pb/autocorrect-wrapper (Wed Sep 10 17:54:28 2008 +0200) 1 commit
+ git wrapper: also use aliases to correct mistyped commands
(Tip at 746c221)
* jc/better-conflict-resolution (Thu Sep 4 23:48:48 2008 +0200) 15 commits
+ Fix AsciiDoc errors in merge documentation
+ git-merge documentation: describe how conflict is presented
+ checkout --conflict=<style>: recreate merge in a non-default style
+ checkout -m: recreate merge when checking out of unmerged index
+ Merge branch 'jc/maint-checkout-fix' into 'jc/better-conflict-
resolution'
+ git-merge-recursive: learn to honor merge.conflictstyle
+ merge.conflictstyle: choose between "merge" and "diff3 -m" styles
+ rerere: understand "diff3 -m" style conflicts with the original
+ rerere.c: use symbolic constants to keep track of parsing states
+ xmerge.c: "diff3 -m" style clips merge reduction level to EAGER or
less
+ xmerge.c: minimum readability fixups
+ xdiff-merge: optionally show conflicts in "diff3 -m" style
+ xdl_fill_merge_buffer(): separate out a too deeply nested function
+ checkout --ours/--theirs: allow checking out one side of a
conflicting merge
+ checkout -f: allow ignoring unmerged paths when checking out of
the index
(Tip at 3407a7a)
* jc/alternate-push (Tue Sep 9 01:27:10 2008 -0700) 4 commits
+ push: receiver end advertises refs from alternate repositories
+ push: prepare sender to receive extended ref information from the
receiver
+ receive-pack: make it a builtin
+ is_directory(): a generic helper function
(Tip at d79796b)
* bc/master-diff-hunk-header-fix (Sat Sep 20 18:36:22 2008 -0700) 10 commits
+ Merge branch 'bc/maint-diff-hunk-header-fix' into bc/master-diff-
hunk-header-fix
+ diff hunk pattern: fix misconverted "\{" tex macro introducers
+ diff: fix "multiple regexp" semantics to find hunk header comment
+ diff: use extended regexp to find hunk headers
+ Merge branch 'bc/maint-diff-hunk-header-fix' into bc/master-diff-
hunk-header-fix
+ diff: use extended regexp to find hunk headers
+ Merge branch 'bc/maint-diff-hunk-header-fix' into bc/master-diff-
hunk-header-fix
+ diff.*.xfuncname which uses "extended" regex's for hunk header
selection
+ diff.c: associate a flag with each pattern and use it for
compiling regex
+ diff.c: return pattern entry pointer rather than just the hunk
header pattern
(Tip at 92bb978)
* am/status (Mon Sep 8 00:05:03 2008 +0200) 2 commits
+ wt-status: Teach how to discard changes in the working directory
+ wt-status: Split header generation into three functions
(Tip at 4d6e4c4)
I think the above are all ready for 'master'.
* mg/maint-remote-fix (Mon Sep 22 10:57:51 2008 +0200) 1 commit
+ make "git remote" report multiple URLs
(Tip at 7d20e21)
* bc/maint-diff-hunk-header-fix (Sat Sep 20 15:30:12 2008 -0700) 5 commits
+ diff hunk pattern: fix misconverted "\{" tex macro introducers
+ diff: use extended regexp to find hunk headers
+ diff.*.xfuncname which uses "extended" regex's for hunk header
selection
+ diff.c: associate a flag with each pattern and use it for
compiling regex
+ diff.c: return pattern entry pointer rather than just the hunk
header pattern
(Tip at 96d1a8e)
The above two are ready for 'maint'.
----------------------------------------------------------------
[Actively Cooking]
* tr/workflow-doc (Sat Sep 13 18:11:01 2008 +0200) 2 commits
+ Documentation: Refer to git-rebase(1) to warn against rewriting
+ Documentation: new upstream rebase recovery section in git-rebase
My impression from the last round of discusson on the third patch in this
series (not queued here) was that as long as we do not present it as "One
True Workflow", the description was a good starting point, possibly others
to add other recommended flows later.
* pb/commit-where (Mon Sep 8 01:05:41 2008 +0200) 1 commit
+ builtin-commit.c: show on which branch a commit was added
Tentatively kicked back to "still cooking" status after Jeff voiced his
annoyance. I personally do not like making this multi-line as Jeff
suggested as an alternative (the message already is too verbose to my
taste).
* lt/time-reject-fractional-seconds (Sat Aug 16 21:25:40 2008 -0700) 1 commit
+ date/time: do not get confused by fractional seconds
* jc/add-ita (Thu Aug 21 01:44:53 2008 -0700) 1 commit
+ git-add --intent-to-add (-N)
Teaches "git add" to record only the intent to add a path later.
I rerolled this without the fake empty blob object.
* jc/post-simplify (Fri Aug 15 01:34:51 2008 -0700) 2 commits
- revision --simplify-merges: incremental simplification
- revision --simplify-merges: prepare for incremental simplification
I started making this incremental but the progress is not so great.
----------------------------------------------------------------
[On Hold]
* jc/stripspace (Sun Mar 9 00:30:35 2008 -0800) 6 commits
- git-am --forge: add Signed-off-by: line for the author
- git-am: clean-up Signed-off-by: lines
- stripspace: add --log-clean option to clean up signed-off-by:
lines
- stripspace: use parse_options()
- Add "git am -s" test
- git-am: refactor code to add signed-off-by line for the committer
The one at second from the tip needs reworking.
* jc/send-pack-tell-me-more (Thu Mar 20 00:44:11 2008 -0700) 1 commit
- "git push": tellme-more protocol extension
* jc/merge-whitespace (Sun Feb 24 23:29:36 2008 -0800) 1 commit
- WIP: start teaching the --whitespace=fix to merge machinery
* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 2 commits
- blame: show "previous" information in --porcelain/--incremental
format
- git-blame: refactor code to emit "porcelain format" output
* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 1 commit
+ merge: remove deprecated summary and diffstat options and config
variables
This was previously in "will be in master soon" category, but it turns out
that the synonyms to the ones this one deletes are fairly new invention
that happend in 1.5.6 timeframe, and we cannot do this just yet. Perhaps
in 1.7.0, but with the loud whining about moving git-foo out of $PATH we
have been hearing, it might not be a bad idea to drop this.
* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 1 commit
- diff: enable "too large a rename" warning when -M/-C is explicitly
asked for
This would be the right thing to do for command line use, but gitk will be
hit due to tcl/tk's limitation, so I am holding this back for now.
--
Shawn.
^ permalink raw reply
* What's in git/spearce.git (Sep 2008, #04; Mon, 29)
From: Shawn O. Pearce @ 2008-09-29 18:46 UTC (permalink / raw)
To: git
What's in git/spearce.git (Sep 2008, #04; Mon, 29)
maint edb7e82 (Merge branch 'bc/maint-diff-hunk-header-fix' into maint)
master 9800c0d (Merge branch 'bc/master-diff-hunk-header-fix')
------------------------------------------------------------------------
With Junio offline for another week we won't see a 1.6.0.3 until
probably mid-October. With that in mind I've merged a number of
topics and trivial patches to maint so we can shake these out
before the 1.6.0.3 release.
* The 'maint' branch has these fixes since the last announcement.
Alex Riesen (3):
Remove empty directories in recursive merge
Add remove_path: a function to remove as much as possible of a path
Use remove_path from dir.c instead of own implementation
Brandon Casey (5):
diff.c: return pattern entry pointer rather than just the hunk header
pattern
diff.c: associate a flag with each pattern and use it for compiling regex
diff.*.xfuncname which uses "extended" regex's for hunk header selection
t4018-diff-funcname: test syntax of builtin xfuncname patterns
git-stash.sh: don't default to refs/stash if invalid ref supplied
Chris Frey (1):
Documentation: clarify the details of overriding LESS via core.pager
Deskin Miller (1):
maint: check return of split_cmdline to avoid bad config strings
Johan Herland (2):
for-each-ref: Fix --format=%(subject) for log message without newlines
Use strchrnul() instead of strchr() plus manual workaround
Jonas Fonseca (1):
checkout: Do not show local changes when in quiet mode
Junio C Hamano (2):
diff: use extended regexp to find hunk headers
diff hunk pattern: fix misconverted "\{" tex macro introducers
Michael J Gruber (1):
make "git remote" report multiple URLs
Ping Yin (1):
git-submodule: Fix "Unable to checkout" for the initial 'update'
Rafael Garcia-Suarez (1):
Clarify commit error message for unmerged files
Shawn O. Pearce (1):
Update release notes for 1.6.0.3
Stephen Haberman (1):
Clarify how the user can satisfy stash's 'dirty state' check.
* The 'master' branch has these since the last announcement
in addition to the above.
Alex Riesen (1):
Cleanup remove_path
Alexander Gavrilov (9):
git-gui: Fix Blame Parent & Context for working copy lines.
git-gui: Restore ability to Stage Working Copy for conflicts.
git-gui: Add more integration options to citool.
git-gui: Cleanup handling of the default encoding.
git-gui: Add a menu of available encodings.
git-gui: Allow forcing display encoding for diffs using a submenu.
git-gui: Optimize encoding name resolution using a lookup table.
git-gui: Support the encoding menu in gui blame.
git-gui: Reenable staging unmerged files by clicking the icon.
Anders Melchiorsen (2):
wt-status: Split header generation into three functions
wt-status: Teach how to discard changes in the working directory
Brandon Casey (1):
t4018-diff-funcname: test syntax of builtin xfuncname patterns
Christian Stimming (2):
git-gui: I18n fix sentence parts into full sentences for translation
again.
git-gui: Updated German translation.
Dmitry Potapov (1):
mingw: remove use of _getdrive() from lstat/fstat
Garry Dolley (1):
Fixed some grammatical errors in git-rebase.txt documentation.
Giuseppe Bilotta (1):
gitweb: shortlog now also obeys $hash_parent
Heikki Orsila (1):
diff --dirstat-by-file: count changed files, not lines
Johan Herland (2):
Fix AsciiDoc errors in merge documentation
Fix submodule sync with relative submodule URLs
Johannes Sixt (1):
compat/mingw: Support a timeout in the poll emulation if no fds are given
Joshua Williams (1):
git-gui: Add support for calling out to the prepare-commit-msg hook
Junio C Hamano (21):
checkout -f: allow ignoring unmerged paths when checking out of the index
checkout --ours/--theirs: allow checking out one side of a conflicting
merge
xdl_fill_merge_buffer(): separate out a too deeply nested function
xdiff-merge: optionally show conflicts in "diff3 -m" style
xmerge.c: minimum readability fixups
xmerge.c: "diff3 -m" style clips merge reduction level to EAGER or less
rerere.c: use symbolic constants to keep track of parsing states
rerere: understand "diff3 -m" style conflicts with the original
merge.conflictstyle: choose between "merge" and "diff3 -m" styles
git-merge-recursive: learn to honor merge.conflictstyle
checkout -m: recreate merge when checking out of unmerged index
checkout --conflict=<style>: recreate merge in a non-default style
git-merge documentation: describe how conflict is presented
safe_create_leading_directories(): make it about "leading" directories
git-apply:--include=pathspec
is_directory(): a generic helper function
receive-pack: make it a builtin
push: prepare sender to receive extended ref information from the
receiver
push: receiver end advertises refs from alternate repositories
diff: use extended regexp to find hunk headers
diff: fix "multiple regexp" semantics to find hunk header comment
Miklos Vajna (13):
Split out merge_recursive() to merge-recursive.c
merge-recursive: introduce merge_options
builtin-merge: avoid run_command_v_opt() for recursive and subtree
cherry-pick/revert: make direct internal call to merge_tree()
merge-recursive: move call_depth to struct merge_options
merge-recursive: get rid of the index_only global variable
merge-recursive: move the global obuf to struct merge_options
merge-recursive: move current_{file,directory}_set to struct
merge_options
merge-recursive: get rid of virtual_id
builtin-merge: release the lockfile in try_merge_strategy()
commit_tree(): add a new author parameter
builtin-commit: use commit_tree()
t7603: add new testcases to ensure builtin-commit uses reduce_heads()
Nanako Shiraishi (4):
remote.c: make free_ref(), parse_push_refspec() and free_refspecs()
static.
graph.c: make many functions static
usage.c: remove unused functions
Add contrib/rerere-train script
Petr Baudis (1):
git-web--browse: Support for using /bin/start on MinGW
Pieter de Bie (1):
git wrapper: also use aliases to correct mistyped commands
Shawn O. Pearce (3):
git-gui: Hide commit related UI during citool --nocommit
git-gui: Use gitattribute "encoding" for file content display
git-gui: Assume `blame --incremental` output is in UTF-8
Stephan Beyer (1):
merge-recursive.c: Add more generic merge_recursive_generic()
--
Shawn.
^ permalink raw reply
* Re: [PATCH] builtin-commit: avoid using reduce_heads()
From: Jakub Narebski @ 2008-09-29 18:44 UTC (permalink / raw)
To: Miklos Vajna; +Cc: SZEDER Gábor, git, Shawn O. Pearce, Johannes.Schindelin
In-Reply-To: <20080929181856.GX23137@genesis.frugalware.org>
Dnia poniedziałek 29. września 2008 20:18, Miklos Vajna napisał:
> On Mon, Sep 29, 2008 at 05:07:22PM +0200, Miklos Vajna <vmiklos@frugalware.org> wrote:
> > > Currently parents of merge commits are 'reduce(HEAD + MERGE_HEAD)'
> > > in symbolic equation; I propose they would be simply 'MERGE_HEAD'.
> > > then we set this branch to new commit
> >
> > Yes. Currently - after a merge conflict - you are able to check what
> > heads caused were merged, which caused the conflict, but with this
> > approach you would not be able to. I think this would be a step back...
>
> Uh, I should read my mail before sending it next time.
>
> I just wanted to say that in case, for example, I merge A^ and A, but I
> get a conflict after octopus tried to merge A^ then it can be a useful
> info to see that A^ was a head. Putting reduce(HEAD + MERGE_HEAD) to
> MERGE_HEAD would hide this info, which would make the situation worse,
> IMHO.
I don't understand: I thought that merge strategy gets _reduced_ heads.
Moreover, if head reduction reduces number of heads to two, you would
use twohead merge (recursive) instead of octopus, and fast-forward if
there is only one head after reduction.
All that I proposed is to put those reduced heads into MERGE_HEAD.
I did not proposed to put yet unresolved heads in MERGE_HEAD in case
of octopus merge conflict. I think either you misunderstood me, or
I misunderstood you.
Take for example the following case of
[H@repo]$ git merge a b c
.---.---.---.---H <-- H <-- HEAD
\
\.---.---.---a <-- a
\
\-b <-- b
\
\--c <-- c
Currently after failed merge we have:
HEAD:
refs: refs/heads/H
MERGE_HEAD
sha1(a)
sha1(b)
sha1(c)
I propose it to be
HEAD:
refs: refs/heads/H
MERGE_HEAD
sha1(a)
sha1(c)
And merge strategy chosen would be twohead one (recursive).
If the situation was slightly different
.---.---.---.---.--.---.---.---H <-- H <-- HEAD
\
\.---.---.---a <-- a
\
\-b <-- b
\
\--c <-- c
I propose it to be
HEAD:
refs: refs/heads/H
MERGE_HEAD
sha1(H)
sha1(a)
sha1(c)
And merge strategy chosen would be octopus.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH 3/4] mingw: move common functionality to win32.h
From: Dmitry Potapov @ 2008-09-29 18:37 UTC (permalink / raw)
To: Johannes Sixt
Cc: git, Junio C Hamano, Shawn O. Pearce, Alex Riesen, Marcus Griep
In-Reply-To: <200809281110.48256.johannes.sixt@telecom.at>
On Sun, Sep 28, 2008 at 11:10:48AM +0200, Johannes Sixt wrote:
> On Samstag, 27. September 2008, Dmitry Potapov wrote:
> > win32_to_errno was the first thing that implemented but then released
> > that translation of Win32 errors to errno cannot be in general case.
> > For instance, ERROR_BUFFER_OVERFLOW means ENAMETOOLONG here, but it
> > can be translated to ETOOSMALL in other cases. How do you propose to
> > deal with that?
>
> We deal with that when the need arises, in an evolutionary manner. The first
> step is to *have* an error code translation routine.
Step to what? IMHO, the idea of win32_to_errno is deeply flawed, and, in
any case, refactoring handling of Win32 error in MinGW is not the
purpose of my series. If you want to introduce win32_to_errno in mingw,
you can send your own patch to that effect, and we can discuss that
separately. So far, I am not convinced that it will improve anything in
the existing code. As to avoiding duplication of Win32 specific code,
get_file_attr() fits better. So, let's proceed step-wise, and first
finish one thing, namely, speed-up of Cygwin version of Git and then
discuss adding win32_to_errno to MinGW.
Dmitry
^ permalink raw reply
* Re: [PATCH 4/4] cygwin: Use native Win32 API for stat
From: Dmitry Potapov @ 2008-09-29 18:26 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Johannes Sixt, git, Junio C Hamano, Alex Riesen, Marcus Griep
In-Reply-To: <20080929153400.GJ17584@spearce.org>
On Mon, Sep 29, 2008 at 08:34:00AM -0700, Shawn O. Pearce wrote:
> Johannes Sixt <johannes.sixt@telecom.at> wrote:
>
> > My point is that emphasis on "stat" in the name is wrong: That's about
> > implementation, but not about the effect. Why wouldn't 'ignoreCygwinFSTricks'
> > be specific enough?
>
> I like this a lot better. I could see us also bypassing other Cygwin
> functions like open() in order to get faster system calls for Git.
If you think that it may be useful to bypass some other functions, and
you want to use the same option to control that then a general name like
that makes sense. Personally, I don't believe that we may want to bypass
something like open() as it is not performance critical, but I said
above I don't care about the name much, so I am going to change my patch
to use ignoreCygwinFSTricks.
Dmitry
^ 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