* committing selected 'changed' or 'added' files works, but not 'removed'
From: Jim Meyering @ 2007-05-14 6:16 UTC (permalink / raw)
To: git
Hello,
If I've just run "git-rm -f c" in a directory with a few modified
or git-added files, is there some way to commit (non-interactively)
only the removal of that selected file? I.e., not any other changes
in the working directory? git-commit -m. -- c fails with this:
error: pathspec 'c' did not match any file(s) known to git
If I use "cg-commit" instead of "git-commit", it works fine.
When I asked on IRC, "cehteh" suggested to create a temporary branch,
do the removal there, and then to rebase that change back onto the
original branch -- and to remove the disposable branch. Yes, that works,
but I want do the job with a single commit command, the same way I can
for "added" and "modified" files. And I've been trying (until now,
successfully) to wean myself away from cogito.
Why should "removed" files be handled so differently? If I cannot commit
a selected "file removal" (regardless of the state of the index), then
isn't that an opportunity to add a feature?
In case you're wondering, I want this functionality in order to make
a version control agnostic commit/diff/ChangeLog tool work the same way
with raw git as it did using cogito.
-------------------------------------------
In case an actual scenario helps, I'd like to be able to commit the
removal of "c", below without also committing the change to "b":
mkdir .j && cd .j && git-init > /dev/null && touch b c && git-add b c \
&& git-commit -q -m. && echo > b && git-rm --quiet -f c \
&& git-commit -m. -- c
The final commit above fails like this:
error: pathspec 'c' did not match any file(s) known to git.
Did you forget to 'git add'?
^ permalink raw reply
* Re: RFH for [PATCH] Optimized cvsexportcommit: calling 'cvs status' only once instead of once per changed file.
From: Martin Langhoff @ 2007-05-14 6:40 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Junio C Hamano, git, Steffen Prohaska
In-Reply-To: <200705132351.24867.robin.rosenberg.lists@dewire.com>
On 5/14/07, Robin Rosenberg <robin.rosenberg.lists@dewire.com> wrote:
> söndag 13 maj 2007 skrev Junio C Hamano:
> > I'd like to have feedbacks on this patch, as I think what it
> > tries to do is sensible and worth to have it in v1.5.2 if it
> > works for people.
> >
> > Ack? Nack? YesButNeedsmorework?
>
> Looks good, but I haven't tried it for production work yet.
Same here - got it in my dev system, but haven't had a chance to use
it in real-life.
m
^ permalink raw reply
* Suggestions for cgit (was: Re: suggestions for gitweb)
From: Jakub Narebski @ 2007-05-14 7:31 UTC (permalink / raw)
To: Lars Hjemli; +Cc: git
In-Reply-To: <8c5c35580705130952r7c0e353dr9cf20aed61bdd463@mail.gmail.com>
On Sun, 13 May 2007, Lars Hjemli <hjemli@gmail.com> wrote:
> I've implemented number of files/lines changed in cgit's log view and
> pushed it to http://hjemli.net/git/
>
> It does consume some cpu (especially on the linux-2.6 repo), but it's
> not terribly bad (and the caching helps out). But I felt like changing
> the number of commits per page to 50, so I added a knob for this in
> the config file while at it.
>
> I'll try to get a proper diffstat on the commit page + file history
> via tree view next (filesize has always been part of cgits tree view
> btw).
What I lack in cgit is using git diff and showing extended diff headers
(and the ugly tight box around diff doesn't help either), and gitweb's
'commitdiff' view / git's git-show / git's git-format-patch.
I don't think displaying filesize slows cgit much (you need to find and
read object header for that, as this information is not present in a
tree object...
By the way, what do you think about http://git.or.cz/gitwiki/Gitweb
page?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] Require JDK1.5
From: Noel Grandin @ 2007-05-14 7:21 UTC (permalink / raw)
To: Grzegorz Kulewski; +Cc: Robin Rosenberg, spearce, git
In-Reply-To: <Pine.LNX.4.63.0705140303380.17507@alpha.polcom.net>
>> diff --git
>> a/org.spearce.jgit/src/org/spearce/jgit/lib/ObjectIdMap.java
>> b/org.spearce.jgit/src/org/spearce/jgit/lib/ObjectIdMap.java
>> index c397a0d..63796fd 100644
>> --- a/org.spearce.jgit/src/org/spearce/jgit/lib/ObjectIdMap.java
>> +++ b/org.spearce.jgit/src/org/spearce/jgit/lib/ObjectIdMap.java
>> @@ -50,9 +50,9 @@ public class ObjectIdMap implements Map {
>>
>> public ObjectIdMap(Map sample) {
>> try {
>> - Method m=sample.getClass().getMethod("clone", null);
>> + Method m=sample.getClass().getMethod("clone",
>> (Class[])null);
>> for (int i=0; i<256; ++i) {
>> - level0[i] = (Map)m.invoke(sample, null);
>> + level0[i] = (Map)m.invoke(sample, (Object[])null);
>> }
>> } catch (IllegalAccessException e) {
>> throw new IllegalArgumentException(e);
>
> I wonder why one would need changes like this?
>
> These casts are not needed for anything as far as I can see and your
> IDE should easily tell you what type that parameter is. No?
>
Those are varargs parameters, so when compiling under 1.5 you sometimes
have to tell the compiler the difference between passing a varargs array
and passing one parameter.
Disclaimer: http://www.peralex.com/disclaimer.html
^ permalink raw reply
* Re: [PATCH] Documentation: Split description of pretty formats of commit log
From: Jakub Narebski @ 2007-05-14 7:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vejlkp440.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> Split description of pretty formats into list of pretty options
>> (--pretty and --encoding) in new file Documentation/pretty-options.txt
>> and description of formats itself as a separate "PRETTY FORMATS"
>> section in pretty-formats.txt
>
> Very good -- thanks.
It should be: "section in Documentation/pretty-formats.txt". I updated
one part, but forgot to update another.
Not terribly important...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: committing selected 'changed' or 'added' files works, but not 'removed'
From: Junio C Hamano @ 2007-05-14 7:44 UTC (permalink / raw)
To: Jim Meyering; +Cc: git
In-Reply-To: <87y7jsgcag.fsf@rho.meyering.net>
Jim Meyering <jim@meyering.net> writes:
> Why should "removed" files be handled so differently? If I cannot commit
> a selected "file removal" (regardless of the state of the index), then
> isn't that an opportunity to add a feature?
The answer is because it is a bit cumbersome to arrange, and
people who felt the need were too lazy to add that. And
everybody knows that I am not from the "partial commit" camp.
You could do something like this...
NOTE NOTE NOTE.
I am not quite happy with this one, as it exposes one of my
favorite pet peeves -- wildcard pathspecs behave differently
between diff-tree family and ls-files family. After modifying a
random C source file, you can say:
git commit -m 'C files changed' -- '*.c'
but you cannot say:
git commit -m 'C files modified and/or removed' -- '*.c'
after removing a C source file, because diff-tree's pathspec
only works as top-down, subdirectory limiter.
-- >8 --
git-commit: Allow removal to be partially committed as well
We allow partial commit of modified and added files but never
handled removed files. This hacks it around.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
git-commit.sh | 36 ++++++++++++++++++++++++++++++-
t/t7400-commit.sh | 60 +++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 95 insertions(+), 1 deletions(-)
diff --git a/git-commit.sh b/git-commit.sh
index f28fc24..f4ba0ef 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -59,6 +59,40 @@ run_status () {
${untracked_files:+--untracked}
}
+compute_commit_only () {
+
+ # The first one cannot commit removal
+ if test -n "$initial_commit"
+ then
+ exec git-ls-files --error-unmatch -- "$@"
+ fi
+
+ # Usual case -- no unmatch
+ if files=$(git-ls-files --error-unmatch -- "$@" 2>/dev/null)
+ then
+ echo "$files"
+ exit 0
+ fi
+
+ has_unmatch_errs=
+ # Otherwise we need to do it the hard way
+ for p in "$@"
+ do
+ removed=$(git-diff-index --cached --name-only \
+ --diff-filter=D HEAD -- "$p")
+ if test -n "$removed"
+ then
+ echo "$removed"
+ elif git-ls-files --error-unmatch -- "$p"
+ then
+ : ok so far
+ else
+ has_unmatch_errs=t
+ fi
+ done
+ test -z "$has_unmatch_errs"
+}
+
trap '
test -z "$TMP_INDEX" || {
test -f "$TMP_INDEX" && rm -f "$TMP_INDEX"
@@ -364,7 +398,7 @@ t,)
refuse_partial "Cannot do a partial commit during a merge."
fi
TMP_INDEX="$GIT_DIR/tmp-index$$"
- commit_only=`git-ls-files --error-unmatch -- "$@"` || exit
+ commit_only=$( (compute_commit_only "$@") ) || exit
# Build a temporary index and update the real index
# the same way.
diff --git a/t/t7400-commit.sh b/t/t7400-commit.sh
new file mode 100755
index 0000000..81196b0
--- /dev/null
+++ b/t/t7400-commit.sh
@@ -0,0 +1,60 @@
+#!/bin/sh
+
+test_description='git commit porcelain-ish'
+
+. ./test-lib.sh
+
+test_expect_success 'the basics' '
+
+ echo doing partial >"commit is" &&
+ mkdir not &&
+ echo very much encouraged but we should >not/forbid &&
+ git add "commit is" not &&
+ echo update added "commit is" file >"commit is" &&
+ echo also update another >not/forbid &&
+ test_tick &&
+ git commit -a -m "initial with -a" &&
+
+ git cat-file blob HEAD:"commit is" >current.1 &&
+ git cat-file blob HEAD:not/forbid >current.2 &&
+
+ cmp current.1 "commit is" &&
+ cmp current.2 not/forbid
+
+'
+
+test_expect_success 'partial' '
+
+ echo another >"commit is" &&
+ echo another >not/forbid &&
+ test_tick &&
+ git commit -m "partial commit to handle a file" "commit is" &&
+
+ changed=$(git diff-tree --name-only HEAD^ HEAD) &&
+ test "$changed" = "commit is"
+
+'
+
+test_expect_success 'partial modification into subdirecotry' '
+
+ test_tick &&
+ git commit -m "partial commit to subdirectory" not &&
+
+ changed=$(git diff-tree -r --name-only HEAD^ HEAD) &&
+ test "$changed" = "not/forbid"
+
+'
+
+test_expect_success 'partial removal' '
+
+ git rm not/forbid &&
+ git commit -m "partial commit to remove not/forbid" not &&
+
+ changed=$(git diff-tree -r --name-only HEAD^ HEAD) &&
+ test "$changed" = "not/forbid" &&
+ remain=$(git ls-tree -r --name-only HEAD) &&
+ test "$remain" = "commit is"
+
+'
+
+test_done
^ permalink raw reply related
* Re: Suggestions for cgit (was: Re: suggestions for gitweb)
From: Lars Hjemli @ 2007-05-14 8:50 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200705140931.32513.jnareb@gmail.com>
On 5/14/07, Jakub Narebski <jnareb@gmail.com> wrote:
> On Sun, 13 May 2007, Lars Hjemli <hjemli@gmail.com> wrote:
>
> > I've implemented number of files/lines changed in cgit's log view and
> > pushed it to http://hjemli.net/git/
> >
> > It does consume some cpu (especially on the linux-2.6 repo), but it's
> > not terribly bad (and the caching helps out). But I felt like changing
> > the number of commits per page to 50, so I added a knob for this in
> > the config file while at it.
> >
> > I'll try to get a proper diffstat on the commit page + file history
> > via tree view next (filesize has always been part of cgits tree view
> > btw).
>
> What I lack in cgit is using git diff and showing extended diff headers
> (and the ugly tight box around diff doesn't help either), and gitweb's
> 'commitdiff' view / git's git-show / git's git-format-patch.
Yes, this has been lacking. Last night I pushed initial support for
'commitdiff', but it doesn't show git's extended diff headers, nor is
there any plain/patch view (but the ugly tiny box is still there, I'm
lousy at web design :)
That said, extended headers/patch view should be trivial to support so
I'll look into it.
> I don't think displaying filesize slows cgit much (you need to find and
> read object header for that, as this information is not present in a
> tree object...
True, I do
type = sha1_object_info(sha1, &size)
per entry in tree view to get the size. It's fast.
> By the way, what do you think about http://git.or.cz/gitwiki/Gitweb
> page?
Nice, I hadn't noticed this page, maybe cgit should get one too? Well,
it probably should get some users first (are there anyone besides
myself?)
--
larsh
^ permalink raw reply
* Re: suggestions for gitweb
From: Michael Niedermayer @ 2007-05-14 8:53 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git, Jakub Narebski
In-Reply-To: <20070514023609.GI18276@pasky.or.cz>
[-- Attachment #1: Type: text/plain, Size: 1678 bytes --]
Hi
On Mon, May 14, 2007 at 04:36:09AM +0200, Petr Baudis wrote:
> On Mon, May 14, 2007 at 04:00:02AM CEST, Michael Niedermayer wrote:
> > i agree with you that she will click on 'history' and figure out what it is
> > but if she wants to see the contents of one of the files then i think
> > she will be confused and not know where to click,
>
> I think she will just click on the filename - straightforward enough...?
yes and no :)
i see 2 possible problems with this
first if she starts from the summary page (which is from where she would
start from if she clicked on 'ffmpeg') then she would see the recent
history but no directory/file names, she would have to click on 'tree'
here
the second possible problem i see is that while directory names are
displayed in iceweasel in underlined blue like links, filenames are
not, so she might not realize that she can click on them
another thing i just realized is that the blob/tree links on the tree
page seems redundant as the directory/file names already link to these
pages, iam just mentioning that as some people in this thread seemed to
like minimizing the number of links and the length of varous displayed
items
also file size and last modified dates would be interresting on the tree
page
viewvc displays on its equivalent page, time since last change
svn revission of the last change, the author/commiter of the last change
and the corresponding abbreviated log entry
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Segmentation fault in git-svn
From: Peter Baumann @ 2007-05-14 9:02 UTC (permalink / raw)
To: Eric Wong; +Cc: Steven Grimm, git
In-Reply-To: <46478B74.8010005@midwinter.com>
On Sun, May 13, 2007 at 03:04:36PM -0700, Steven Grimm wrote:
> I can confirm that the patch fixes the segfault for me too. Thanks!
>
> -Steve
>
I can (hopefully) confirm this, too.
-Peter
Side Note:
I tried it yesterday and got a message which
looks something alike "connection closed ..." and after continuing the
import I got an segfault. But as I couldn't reproduce this today, it
seems that it was just a flacky connection and after the closed
connection the repo was just in an inconsistent state.
I'll propably try to import this repo a few more times, just to check
if it is really fixed.
^ permalink raw reply
* Re: suggestions for gitweb
From: Petr Baudis @ 2007-05-14 9:58 UTC (permalink / raw)
To: Michael Niedermayer; +Cc: Junio C Hamano, git, Jakub Narebski
In-Reply-To: <20070514085314.GY14859@MichaelsNB>
Hi,
On Mon, May 14, 2007 at 10:53:15AM CEST, Michael Niedermayer wrote:
> On Mon, May 14, 2007 at 04:36:09AM +0200, Petr Baudis wrote:
> > On Mon, May 14, 2007 at 04:00:02AM CEST, Michael Niedermayer wrote:
> > > i agree with you that she will click on 'history' and figure out what it is
> > > but if she wants to see the contents of one of the files then i think
> > > she will be confused and not know where to click,
> >
> > I think she will just click on the filename - straightforward enough...?
>
> yes and no :)
> i see 2 possible problems with this
> first if she starts from the summary page (which is from where she would
> start from if she clicked on 'ffmpeg') then she would see the recent
> history but no directory/file names, she would have to click on 'tree'
> here
well, I guess our opinions on how hard it is to guess it through just
differ... :-)
> also file size and last modified dates would be interresting on the tree
> page
> viewvc displays on its equivalent page, time since last change
> svn revission of the last change, the author/commiter of the last change
> and the corresponding abbreviated log entry
I guess this is much easier to retrieve in svn than in git - you
actually have to walk all the history to figure out this information as
there's no global per-file info; so this is very troublesome
performance-wise. I think there were some patches on the mailinglist
that dit this, though I'm not sure. Might be reasonable to cache this
(and git history properties make it possible to nicely make a very
easily reusable cache for this information).
About file sizes, that also has some extra performance hit, but in
this case I suspect that it would be totally negligible (if implemented
at the plumbing level) - and I admit that I would like to see file sizes
too, they can help orientation in a foreign source tree a lot.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Ever try. Ever fail. No matter. // Try again. Fail again. Fail better.
-- Samuel Beckett
^ permalink raw reply
* git as a backup tool?
From: Geert Uytterhoeven @ 2007-05-14 11:48 UTC (permalink / raw)
To: git; +Cc: Geert Uytterhoeven
Hi,
Has anyone considered using git as a backup tool? I.e.
- put your whole file system in git
- do `git add .; git commit -a' from cron
- copy .git to external media once in a while
- clean up old stuff (unused and older than xx days) from .git
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: git.or.cz IPv6
From: Jeffrey C. Ollie @ 2007-05-14 12:04 UTC (permalink / raw)
To: GIT
In-Reply-To: <20070514054232.GD17207@cip.informatik.uni-erlangen.de>
[-- Attachment #1: Type: text/plain, Size: 2054 bytes --]
On Mon, 2007-05-14 at 07:42 +0200, Thomas Glanzmann wrote:
>
> (faui01) [~] traceroute6 git.or.cz
> traceroute to rover.or.cz (2a01:b0:0:2::) from 2001:638:a00:1e:209:3dff:fe10:85e5, 30 hops max, 16 byte packets
> [...]
> 15 so-0-0-0.ham10.ip6.tiscali.net (2001:668:0:2::101) 37.727 ms 37.319 ms 37.488 ms
> 16 * * *
> 17 * * *
> 18 * * *
> (thinkpad) [~] traceroute6 git.or.cz
> traceroute to rover.or.cz (2a01:b0:0:2::) from 2001:a60:f027:dead:213:2ff:fe7b:d860, 30 hops max, 16 byte packets
> [...]
> 19 so-0-0-0.ham10.ip6.tiscali.net (2001:668:0:2::101) 58.853 ms 60.317 ms 59.325 ms
> 20 * *
> (stargate) [~] traceroute6 git.or.cz
> traceroute to rover.or.cz (2a01:b0:0:2::) from 2001:4b88:103a::1, 30 hops max, 16 byte packets
> [...]
> 12 so-0-0-0.ham10.ip6.tiscali.net (2001:668:0:2::101) 41.131 ms 42.767 ms 42.101 ms
I see a similar problem from my Hurricane Electric tunnel:
# traceroute6 git.or.cz
traceroute to git.or.cz (2a01:b0:0:2::), 30 hops max, 40 byte packets
1 ambience.tunnel.tserv2.fmt.ipv6.he.net (2001:470:1f01:ffff::130) 110.910 ms 110.729 ms 110.611 ms
2 2001:470:1fff:2::26 (2001:470:1fff:2::26) 110.505 ms 110.404 ms 110.273 ms
3 2001:470:0:9::2 (2001:470:0:9::2) 121.185 ms 121.044 ms 120.939 ms
4 2001:470:1fff:1::1 (2001:470:1fff:1::1) 195.496 ms 195.321 ms 195.213 ms
5 (2001:458:26:2::200) 206.184 ms 206.110 ms *
6 * ge-1-0-0.nyc10.ip6.tiscali.net (2001:504:1::a500:3257:1) 189.877 ms 189.688 ms
7 so-1-1-3.nyc33.ip6.tiscali.net (2001:668:0:2::330) 189.582 ms 189.497 ms 200.172 ms
8 so-2-1-0.lon11.ip6.tiscali.net (2001:668:0:2::1:61) 266.841 ms 257.321 ms 257.144 ms
9 so-7-0-0.lon11.ip6.tiscali.net (2001:668:0:2::1:332) 257.036 ms 253.481 ms so-0-1-0.lon11.ip6.tiscali.net (2001:668:0:2::1:322) 264.383 ms
10 so-1-0-0.dus11.ip6.tiscali.net (2001:668:0:2::1:32) 278.012 ms * 268.019 ms
11 so-0-0-0.ham10.ip6.tiscali.net (2001:668:0:2::101) 278.754 ms 278.614 ms 278.478 ms
12 * * *
13 * * *
14 * * *
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [BUG] git-svn dcommit fails (connection closed unexpectedly)
From: Matthieu Moy @ 2007-05-14 12:27 UTC (permalink / raw)
To: git
In-Reply-To: <20070513171707.GA14024@muzzle>
Eric Wong <normalperson@yhbt.net> writes:
> Does the patch in
> http://permalink.gmane.org/gmane.comp.version-control.git/47126
> help?
I don't have the failure right now, I'll tell you when I get it again.
> If your local username the same as the username
> you're using for svn it shouldn't fail for the reason that patch
> above is needed.
It is the same on both machines.
> Which version of SVN is running on the server?
$ svn --version
svn, version 1.1.4 (r13838)
compiled Apr 12 2005, 16:01:59
$ cat /etc/redhat-release
Red Hat Enterprise Linux ES release 4 (Nahant Update 5)
--
Matthieu
^ permalink raw reply
* Re: [ANNOUNCE] cgit v0.4
From: Matthieu Moy @ 2007-05-14 12:34 UTC (permalink / raw)
To: git
In-Reply-To: <8c5c35580705131524s15e78d4y807879c64edd5de1@mail.gmail.com>
"Lars Hjemli" <lh@elementstorage.no> writes:
> I've just tagged and pushed v0.4 of cgit.
You forgot:
"cgit is a fast webinterface for git"
(year, maybe everybody knew, but I didn't ;-) ).
--
Matthieu
^ permalink raw reply
* Re: committing selected 'changed' or 'added' files works, but not 'removed'
From: Jim Meyering @ 2007-05-14 12:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7viravonmj.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> You could do something like this...
...
> -- >8 --
> git-commit: Allow removal to be partially committed as well
>
> We allow partial commit of modified and added files but never
> handled removed files. This hacks it around.
Nice! Thanks for the quick patch.
I liked the test cases :-)
^ permalink raw reply
* Re: [PATCH (amend)] cvsserver: Add test cases for config file handling
From: Frank Lichtenheld @ 2007-05-14 12:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vtzugqym8.fsf@assigned-by-dhcp.cox.net>
On Sun, May 13, 2007 at 01:04:15PM -0700, Junio C Hamano wrote:
> Frank Lichtenheld <frank@lichtenheld.de> writes:
>
> > Add a few test cases for the config file parsing
> > done by git-cvsserver.
> >
> > Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
> > ---
> > t/t9420-git-cvsserver-config.sh | 109 +++++++++++++++++++++++++++++++++++++++
> > 1 files changed, 109 insertions(+), 0 deletions(-)
> > create mode 100755 t/t9420-git-cvsserver-config.sh
>
> Do we really need a separate test script that does quite similar setup?
Right now, probably not.
But I certainly don't intend to do all the tests in one big file which
will become rather large over time. If you're concerned with code
duplication, maybe I should move the code to a separate file and source
it from there?
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* [PATCH] Allow the ident attribute to include a length specifier
From: Andy Parkins @ 2007-05-14 13:05 UTC (permalink / raw)
To: git
When the ident attribute is found for a path, then git replaces $ident$
with:
$ident: df2a1fd3ebce86876721bd7e12ce02ac89c885db $
With this patch, you can put the following in your attribute file:
somepath ident=10
And get expansions like this:
$ident: df2a1fd3eb $
There is no change to existing behaviour. With no parameter, the
expansion is all 40 hex digits.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
convert.c | 12 +++++++++---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/convert.c b/convert.c
index 9ee31b0..79dfbcf 100644
--- a/convert.c
+++ b/convert.c
@@ -534,8 +534,8 @@ static char *ident_to_worktree(const char *path, const char *src, unsigned long
memcpy(dst, "ident: ", 7);
dst += 7;
- memcpy(dst, sha1_to_hex(sha1), 40);
- dst += 40;
+ memcpy(dst, sha1_to_hex(sha1), ident);
+ dst += ident;
*dst++ = ' ';
size -= (cp - src);
src = cp;
@@ -580,7 +580,13 @@ static int git_path_check_ident(const char *path, struct git_attr_check *check)
{
const char *value = check->value;
- return !!ATTR_TRUE(value);
+ if( ATTR_UNSET(value) || ATTR_FALSE(value) )
+ return 0;
+
+ if( ATTR_TRUE(value) )
+ return 40;
+
+ return atoi(value);
}
char *convert_to_git(const char *path, const char *src, unsigned long *sizep)
--
1.5.2.rc3.27.g43d151-dirty
^ permalink raw reply related
* Re: git.or.cz IPv6
From: Sebastian Harl @ 2007-05-14 12:45 UTC (permalink / raw)
To: git
In-Reply-To: <1179144251.9637.6.camel@lt21223.campus.dmacc.edu>
[-- Attachment #1: Type: text/plain, Size: 2722 bytes --]
Hi,
On Mon, May 14, 2007 at 07:04:11AM -0500, Jeffrey C. Ollie wrote:
> On Mon, 2007-05-14 at 07:42 +0200, Thomas Glanzmann wrote:
> > (faui01) [~] traceroute6 git.or.cz
> > traceroute to rover.or.cz (2a01:b0:0:2::) from 2001:638:a00:1e:209:3dff:fe10:85e5, 30 hops max, 16 byte packets
> > [...]
> > 15 so-0-0-0.ham10.ip6.tiscali.net (2001:668:0:2::101) 37.727 ms 37.319 ms 37.488 ms
> > 16 * * *
> > 17 * * *
> > 18 * * *
>
> > (thinkpad) [~] traceroute6 git.or.cz
> > traceroute to rover.or.cz (2a01:b0:0:2::) from 2001:a60:f027:dead:213:2ff:fe7b:d860, 30 hops max, 16 byte packets
> > [...]
> > 19 so-0-0-0.ham10.ip6.tiscali.net (2001:668:0:2::101) 58.853 ms 60.317 ms 59.325 ms
> > 20 * *
>
> > (stargate) [~] traceroute6 git.or.cz
> > traceroute to rover.or.cz (2a01:b0:0:2::) from 2001:4b88:103a::1, 30 hops max, 16 byte packets
> > [...]
> > 12 so-0-0-0.ham10.ip6.tiscali.net (2001:668:0:2::101) 41.131 ms 42.767 ms 42.101 ms
>
> I see a similar problem from my Hurricane Electric tunnel:
>
> # traceroute6 git.or.cz
> traceroute to git.or.cz (2a01:b0:0:2::), 30 hops max, 40 byte packets
> 1 ambience.tunnel.tserv2.fmt.ipv6.he.net (2001:470:1f01:ffff::130) 110.910 ms 110.729 ms 110.611 ms
> 2 2001:470:1fff:2::26 (2001:470:1fff:2::26) 110.505 ms 110.404 ms 110.273 ms
> 3 2001:470:0:9::2 (2001:470:0:9::2) 121.185 ms 121.044 ms 120.939 ms
> 4 2001:470:1fff:1::1 (2001:470:1fff:1::1) 195.496 ms 195.321 ms 195.213 ms
> 5 (2001:458:26:2::200) 206.184 ms 206.110 ms *
> 6 * ge-1-0-0.nyc10.ip6.tiscali.net (2001:504:1::a500:3257:1) 189.877 ms 189.688 ms
> 7 so-1-1-3.nyc33.ip6.tiscali.net (2001:668:0:2::330) 189.582 ms 189.497 ms 200.172 ms
> 8 so-2-1-0.lon11.ip6.tiscali.net (2001:668:0:2::1:61) 266.841 ms 257.321 ms 257.144 ms
> 9 so-7-0-0.lon11.ip6.tiscali.net (2001:668:0:2::1:332) 257.036 ms 253.481 ms so-0-1-0.lon11.ip6.tiscali.net (2001:668:0:2::1:322) 264.383 ms
> 10 so-1-0-0.dus11.ip6.tiscali.net (2001:668:0:2::1:32) 278.012 ms * 268.019 ms
> 11 so-0-0-0.ham10.ip6.tiscali.net (2001:668:0:2::101) 278.754 ms 278.614 ms 278.478 ms
> 12 * * *
It works fine for me - might be fixed by now:
traceroute to rover.or.cz (2a01:b0:0:2::) from 2001:780:106::f1, 30 hops max, 1s
[...]
5 so-1-0-0.fra40.ip6.tiscali.net (2001:668:0:2::4b0) 4.971 ms 4.962 ms 4.9s 6 so-0-0-0.dus11.ip6.tiscali.net (2001:668:0:2::1:1) 8.468 ms 8.45 ms 8.55s
7 so-0-0-0.ham10.ip6.tiscali.net (2001:668:0:2::101) 13.964 ms 13.683 ms 1s
8 rover.xs26.eu (2a01:b0:0:2::) 37.079 ms 37.146 ms 37.145 ms
Cheers,
Sebastian
--
Sebastian "tokkee" Harl
GnuPG-ID: 0x8501C7FC
http://tokkee.org/
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Allow the ident attribute to include a length specifier
From: Andy Parkins @ 2007-05-14 13:29 UTC (permalink / raw)
To: git
In-Reply-To: <200705141405.29550.andyparkins@gmail.com>
On Monday 2007 May 14, Andy Parkins wrote:
> When the ident attribute is found for a path, then git replaces $ident$
> with:
>
> $ident: df2a1fd3ebce86876721bd7e12ce02ac89c885db $
Is it too late to request a change to this? Make the field $Id$. $Id$ is
present already in SVN and CVS; it would mean that people converting their
existing repositories won't have to make any changes to the source files
should they want to make use of the ident attribute.
Given that it's a feature that's meant to calm those very people, it seems
obtuse to make them edit every file just to make use of it.
I think that bzr uses $Id$; Mercurial has examples for $Id$; monotone has $Id$
on its wishlist. I can't think of a good reason not to stick with the
de-facto standard and call ours $Id$ instead of $ident$.
(I accept that this doesn't help those using $Author$, $Rev$, etc, but it's
better than nothing)
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: [ANNOUNCE] cgit v0.4
From: Lars Hjemli @ 2007-05-14 13:32 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqwszbporj.fsf@bauges.imag.fr>
On 5/14/07, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
> "Lars Hjemli" <lh@elementstorage.no> writes:
>
> > I've just tagged and pushed v0.4 of cgit.
>
> You forgot:
>
> "cgit is a fast webinterface for git"
>
> (year, maybe everybody knew, but I didn't ;-) ).
>
Thanks for the comment, I'll try to make the next announcement more descriptive.
Btw: are anyone bothered by the cgit-announcements on the list? If so,
please speak up :)
--
larsh
^ permalink raw reply
* [PATCH] Use $Id$ as the ident attribute keyword rather than $ident$ to be consistent with other VCSs
From: Andy Parkins @ 2007-05-14 13:37 UTC (permalink / raw)
To: git
In-Reply-To: <200705141429.58412.andyparkins@gmail.com>
$Id$ is present already in SVN and CVS; it would mean that people
converting their existing repositories won't have to make any changes to
the source files should they want to make use of the ident attribute.
Given that it's a feature that's meant to calm those very people, it
seems obtuse to make them edit every file just to make use of it.
I think that bzr uses $Id$; Mercurial has examples hooks for $Id$;
monotone has $Id$ on its wishlist. I can't think of a good reason not
to stick with the de-facto standard and call ours $Id$ instead of
$ident$.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
Patch, should anyone agree with the idea.
convert.c | 30 +++++++++++++++---------------
1 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/convert.c b/convert.c
index 79dfbcf..23257aa 100644
--- a/convert.c
+++ b/convert.c
@@ -412,7 +412,7 @@ static void setup_convert_check(struct git_attr_check *check)
static int count_ident(const char *cp, unsigned long size)
{
/*
- * "$ident: 0000000000000000000000000000000000000000 $" <=> "$ident$"
+ * "$Id: 0000000000000000000000000000000000000000 $" <=> "$Id$"
*/
int cnt = 0;
char ch;
@@ -466,10 +466,10 @@ static char *ident_to_git(const char *path, const char *src, unsigned long *size
for (dst = buf; size; size--) {
char ch = *src++;
*dst++ = ch;
- if ((ch == '$') && (6 <= size) &&
- !memcmp("ident:", src, 6)) {
- unsigned long rem = size - 6;
- const char *cp = src + 6;
+ if ((ch == '$') && (3 <= size) &&
+ !memcmp("Id:", src, 3)) {
+ unsigned long rem = size - 3;
+ const char *cp = src + 3;
do {
ch = *cp++;
if (ch == '$')
@@ -478,8 +478,8 @@ static char *ident_to_git(const char *path, const char *src, unsigned long *size
} while (rem);
if (!rem)
continue;
- memcpy(dst, "ident$", 6);
- dst += 6;
+ memcpy(dst, "Id$", 3);
+ dst += 3;
size -= (cp - src);
src = cp;
}
@@ -511,13 +511,13 @@ static char *ident_to_worktree(const char *path, const char *src, unsigned long
const char *cp;
char ch = *src++;
*dst++ = ch;
- if ((ch != '$') || (size < 6) || memcmp("ident", src, 5))
+ if ((ch != '$') || (size < 3) || memcmp("Id", src, 2))
continue;
- if (src[5] == ':') {
+ if (src[2] == ':') {
/* discard up to but not including the closing $ */
- unsigned long rem = size - 6;
- cp = src + 6;
+ unsigned long rem = size - 3;
+ cp = src + 3;
do {
ch = *cp++;
if (ch == '$')
@@ -527,13 +527,13 @@ static char *ident_to_worktree(const char *path, const char *src, unsigned long
if (!rem)
continue;
size -= (cp - src);
- } else if (src[5] == '$')
- cp = src + 5;
+ } else if (src[2] == '$')
+ cp = src + 2;
else
continue;
- memcpy(dst, "ident: ", 7);
- dst += 7;
+ memcpy(dst, "Id: ", 4);
+ dst += 4;
memcpy(dst, sha1_to_hex(sha1), ident);
dst += ident;
*dst++ = ' ';
--
1.5.2.rc3.27.g43d151-dirty
^ permalink raw reply related
* Re: [PATCH] Use $Id$ as the ident attribute keyword rather than $ident$ to be consistent with other VCSs
From: Johannes Sixt @ 2007-05-14 14:19 UTC (permalink / raw)
To: git
In-Reply-To: <200705141437.25528.andyparkins@gmail.com>
Andy Parkins wrote:
> I think that bzr uses $Id$; Mercurial has examples hooks for $Id$;
> monotone has $Id$ on its wishlist. I can't think of a good reason not
> to stick with the de-facto standard and call ours $Id$ instead of
> $ident$.
I very much agree. I wondered why it was named $ident$ in the first
place. Now that I'm not alone, I thought I'd throw my 2 cents in...
-- Hannes
^ permalink raw reply
* Re: [PATCH] Use $Id$ as the ident attribute keyword rather than $ident$ to be consistent with other VCSs
From: Andy Parkins @ 2007-05-14 14:39 UTC (permalink / raw)
To: Johannes Sixt, Git Mailing List
In-Reply-To: <46486FE6.16A82D9A@eudaptics.com>
On Monday 2007 May 14, Johannes Sixt wrote:
Oops: response via private email, obviously intended for git mailing list.
> Andy Parkins wrote:
> > I think that bzr uses $Id$; Mercurial has examples hooks for $Id$;
> > monotone has $Id$ on its wishlist. I can't think of a good reason not
> > to stick with the de-facto standard and call ours $Id$ instead of
> > $ident$.
>
> I very much agree. I wondered why it was named $ident$ in the first
> place. Now that I'm not alone, I thought I'd throw my 2 cents in...
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* [PATCH] builtin-log.c: Fix typo in comment
From: Frank Lichtenheld @ 2007-05-14 14:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Frank Lichtenheld
In-Reply-To: <1179153893715-git-send-email-frank@lichtenheld.de>
s/fmt-patch/format-patch/
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
---
builtin-log.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-log.c b/builtin-log.c
index 38bf52f..3744712 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -454,7 +454,7 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
/*
* Parse the arguments before setup_revisions(), or something
- * like "git fmt-patch -o a123 HEAD^.." may fail; a123 is
+ * like "git format-patch -o a123 HEAD^.." may fail; a123 is
* possibly a valid SHA1.
*/
for (i = 1, j = 1; i < argc; i++) {
--
1.5.1.4
^ permalink raw reply related
* Some misc Documentation patches
From: Frank Lichtenheld @ 2007-05-14 14:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
The result of me playing around with git format-patch and git-am.
builtin-log.c: Fix typo in comment
Found while searching for the omnious --mbox option
Documentation: format-patch has no --mbox option
Replace --mbox with --stdout. Probably needs some more
thought to really improve the documentation
git-am: Clean up the asciidoc documentation
Fixing some things that annoyed me while reading the man page
and some things that I found while fixing the former.
If I should split that in more than one patch, please say so.
Documentation/git-am.txt | 38 ++++++++++++++++++++------------------
Documentation/git-applymbox.txt | 2 +-
Documentation/git-mailinfo.txt | 3 +--
builtin-log.c | 3 +--
4 files changed, 23 insertions(+), 23 deletions(-)
^ 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