* [PATCH] Move the paragraph specifying where the .idx and .pack files should be
From: Matt Kraai @ 2007-09-21 13:43 UTC (permalink / raw)
To: git; +Cc: Matt Kraai
Signed-off-by: Matt Kraai <kraai@ftbfs.org>
---
Documentation/git-pack-objects.txt | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-pack-objects.txt b/Documentation/git-pack-objects.txt
index 628f296..5237ab0 100644
--- a/Documentation/git-pack-objects.txt
+++ b/Documentation/git-pack-objects.txt
@@ -25,16 +25,16 @@ is efficient to access. The packed archive format (.pack) is
designed to be unpackable without having anything else, but for
random access, accompanied with the pack index file (.idx).
+Placing both in the pack/ subdirectory of $GIT_OBJECT_DIRECTORY (or
+any of the directories on $GIT_ALTERNATE_OBJECT_DIRECTORIES)
+enables git to read from such an archive.
+
'git-unpack-objects' command can read the packed archive and
expand the objects contained in the pack into "one-file
one-object" format; this is typically done by the smart-pull
commands when a pack is created on-the-fly for efficient network
transport by their peers.
-Placing both in the pack/ subdirectory of $GIT_OBJECT_DIRECTORY (or
-any of the directories on $GIT_ALTERNATE_OBJECT_DIRECTORIES)
-enables git to read from such an archive.
-
In a packed archive, an object is either stored as a compressed
whole, or as a difference from some other object. The latter is
often called a delta.
--
1.5.3.1
^ permalink raw reply related
* [PATCH] Use "" instead of "<unknown>" for placeholders [was Re: [PATCH] Added a new placeholder '%cm' for full commit message]
From: Michal Vitecek @ 2007-09-21 14:05 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0709211207070.28395@racer.site>
Johannes Schindelin wrote:
>On Fri, 21 Sep 2007, Michal Vitecek wrote:
>> Johannes Schindelin wrote:
>> >On Fri, 21 Sep 2007, Michal Vitecek wrote:
>> >
>> >> I have added a new placeholder '%cm' for a full commit message.
>> >
>> >You mean the raw message, including the headers? Why not use "%r" for
>> >that?
>>
>> No, sorry for the incorrect term. I meant the whole commit message
>> (subject + 2*\n + body).
>
>Ah, makes sense. In that case, "%M" maybe?
I think it's no longer needed if instead of "<undefined>" only "" will
be substituted.
>> >> I made it because I want to use my own pretty format which currently
>> >> only allows '%s' for subject and '%b' for body. But '%b' is
>> >> substituted with <undefined> if the body is "missing" which I
>> >> obviously don't like :)
>> >
>> >Then you should fix %b not to show "<undefined>".
>>
>> I'll do it if it is okay. Shall I do the same for the other
>> placeholders as well?
>
>Yeah. Don't know why I did it that way.
Here comes the big patch :)
>From 2e4ba4e73bbcd19558039dd85fe45c7bbe7fd1c4 Mon Sep 17 00:00:00 2001
From: Michal Vitecek <fuf@mageo.cz>
Date: Fri, 21 Sep 2007 14:40:37 +0200
Subject: [PATCH] Use "" instead of "<unknown>" for placeholders
---
commit.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/commit.c b/commit.c
index 99f65ce..7e90bc1 100644
--- a/commit.c
+++ b/commit.c
@@ -919,7 +919,7 @@ long format_commit_message(const struct commit *commit, const void *format,
table[IBODY].value = xstrdup(msg + i);
for (i = 0; i < ARRAY_SIZE(table); i++)
if (!table[i].value)
- interp_set_entry(table, i, "<unknown>");
+ interp_set_entry(table, i, "");
do {
char *buf = *buf_p;
--
1.5.3.1
--
fuf (fuf@mageo.cz)
^ permalink raw reply related
* Re: Git as a filesystem
From: Nicolas Pitre @ 2007-09-21 13:45 UTC (permalink / raw)
To: Peter Stahlir; +Cc: Johannes Schindelin, git
In-Reply-To: <fbe8b1780709210635l5803456aof3757418dc9653e7@mail.gmail.com>
On Fri, 21 Sep 2007, Peter Stahlir wrote:
> > > I wonder how big a deltified Debian mirror in one pack file would be. :)
> >
> > It would be just as big as the non gitified storage on disk.
> >
> > The space saving with git comes from efficient delta storage of
> > _versioned_ files, i.e. multiple nearly identical versions of the same
> > file where the stored delta is only the small difference between the
> > first full version and subsequent versions. Unless you plan on storing
> > many different Debian versions together, you won't benefit from any
> > delta at all. And since Debian packages are already compressed, git
> > won't be able to compress them further.
> >
> > So don't waste your time.
>
> The 252GB stem from the fact that there are more than 10 architectures.
> I guess the /usr/share/doc of all architectures could be deltified (as could
> be all files that are architecture-independent)
>
> Right?
Indeed.
But how much does this represents, once compressed, compared to the
rest? I doubt it is significant enough for the trouble.
Nicolas
^ permalink raw reply
* Re: Git as a filesystem
From: Michael Poole @ 2007-09-21 13:41 UTC (permalink / raw)
To: Peter Stahlir; +Cc: Karl Hasselström, Johannes Schindelin, git
In-Reply-To: <fbe8b1780709210628u24c14117p5174bedb3d1912cb@mail.gmail.com>
Peter Stahlir writes:
> Telling git to handle -for example- deb archives and storing
> everything in a pack file would take advantage of redundancy across
> _all_ files.
> So the /usr/share/doc of all architectures could be compressed.
>
> Right?
You're proposing to trade off lots of CPU time in fetching many files
from a pack and making the package file -- paid every time someone
requests a package -- for at most 250 GB of space (cf Amdahl's law).
How long are your users willing to wait in exchange for 250 GB of
saved space? How much CPU are you willing to spend for it? Compare
those to the cost of a 300 GB hard drive (roughly $65).
There's also the cost to make git support the package format, and to
maintain that code going forward. Those costs are also large.
Michael Poole
^ permalink raw reply
* [PATCH] new test from the submodule chapter of the user manual
From: Miklos Vajna @ 2007-09-21 13:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin, J. Bruce Fields
In-Reply-To: <7vd4wdkokn.fsf@gitster.siamese.dyndns.org>
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
second version, now checking for all output, the commit hashes shows what is
committed is what we wanted to commit.
t/t3060-subprojects-tutorial.sh | 151 +++++++++++++++++++++++++++++++++++++++
1 files changed, 151 insertions(+), 0 deletions(-)
create mode 100755 t/t3060-subprojects-tutorial.sh
diff --git a/t/t3060-subprojects-tutorial.sh b/t/t3060-subprojects-tutorial.sh
new file mode 100755
index 0000000..fc09451
--- /dev/null
+++ b/t/t3060-subprojects-tutorial.sh
@@ -0,0 +1,151 @@
+#!/bin/sh
+#
+# Copyright (c) 2007 Miklos Vajna
+#
+
+test_description='A simple subprojects tutorial in the form of a test case'
+
+. ./test-lib.sh
+
+test_tick
+
+cat > create.expect << EOF
+Initialized empty Git repository in .git/
+Created initial commit 85349d2: Initial commit, submodule a
+ 1 files changed, 1 insertions(+), 0 deletions(-)
+ create mode 100644 a.txt
+Initialized empty Git repository in .git/
+Created initial commit 47398d6: Initial commit, submodule b
+ 1 files changed, 1 insertions(+), 0 deletions(-)
+ create mode 100644 b.txt
+Initialized empty Git repository in .git/
+Created initial commit 3d88526: Initial commit, submodule c
+ 1 files changed, 1 insertions(+), 0 deletions(-)
+ create mode 100644 c.txt
+Initialized empty Git repository in .git/
+Created initial commit 73af3de: Initial commit, submodule d
+ 1 files changed, 1 insertions(+), 0 deletions(-)
+ create mode 100644 d.txt
+EOF
+
+for i in a b c d
+do
+ mkdir $i &&
+ cd $i &&
+ git init &&
+ echo "module $i" > $i.txt &&
+ git add $i.txt &&
+ git commit -m "Initial commit, submodule $i" &&
+ cd ..
+done > create.output
+test_expect_success "create the submodules" 'cmp create.expect create.output'
+
+mkdir super
+cd super
+cat > create-super.expect << EOF
+Initialized empty Git repository in .git/
+Initialized empty Git repository in `pwd`/a/.git/
+0 blocks
+Initialized empty Git repository in `pwd`/b/.git/
+0 blocks
+Initialized empty Git repository in `pwd`/c/.git/
+0 blocks
+Initialized empty Git repository in `pwd`/d/.git/
+0 blocks
+EOF
+
+(git init &&
+for i in a b c d
+do
+ git submodule add `pwd`/../$i
+done ) &> create-super.output
+test_expect_success "create the superproject" 'cmp create-super.expect create-super.output'
+
+cat > commit-superproject.expect << EOF
+Created initial commit c496be9: Add submodules a, b, c and d.
+ 5 files changed, 16 insertions(+), 0 deletions(-)
+ create mode 100644 .gitmodules
+ create mode 160000 a
+ create mode 160000 b
+ create mode 160000 c
+ create mode 160000 d
+EOF
+git commit -m "Add submodules a, b, c and d." > commit-superproject.output
+
+test_expect_success "commit in the superproject" 'cmp commit-superproject.expect commit-superproject.output'
+
+cd ..
+
+cat > clone.expect << EOF
+Initialized empty Git repository in `pwd`/cloned/.git/
+0 blocks
+EOF
+
+git clone super cloned &> clone.output
+
+test_expect_success "clone the superproject" 'cmp clone.expect clone.output'
+
+cd cloned
+
+cat > submodule-init.expect << EOF
+Submodule 'a' (${PWD%%/cloned}/a/.git) registered for path 'a'
+Submodule 'b' (${PWD%%/cloned}/b/.git) registered for path 'b'
+Submodule 'c' (${PWD%%/cloned}/c/.git) registered for path 'c'
+Submodule 'd' (${PWD%%/cloned}/d/.git) registered for path 'd'
+EOF
+
+git submodule init > submodule-init.output
+
+test_expect_success "submodule init" 'cmp submodule-init.expect submodule-init.output'
+
+cat > submodule-update.expect << EOF
+Initialized empty Git repository in `pwd`/a/.git/
+0 blocks
+Submodule path 'a': checked out '85349d24595f581f5548b321a55c8a5fbe87259f'
+Initialized empty Git repository in `pwd`/b/.git/
+0 blocks
+Submodule path 'b': checked out '47398d6286153d23bfd5780ae3bf1996eb18cf90'
+Initialized empty Git repository in `pwd`/c/.git/
+0 blocks
+Submodule path 'c': checked out '3d88526ff6973dd27a07f57a3bb2bf5fa0bada42'
+Initialized empty Git repository in `pwd`/d/.git/
+0 blocks
+Submodule path 'd': checked out '73af3de6718291404ef541f4bb152f87d35a1481'
+EOF
+
+git submodule update &> submodule-update.output
+
+test_expect_success "submodule update" 'cmp submodule-update.expect submodule-update.output'
+
+cat > submodule-push.expect << EOF
+Created commit ab78b5a: Updated the submodule from within the superproject.
+ 1 files changed, 1 insertions(+), 0 deletions(-)
+Everything up-to-date
+Created commit 8bbfffe: Updated submodule a.
+ 1 files changed, 1 insertions(+), 1 deletions(-)
+updating 'refs/heads/master'
+ from c496be9e726d5c6ee0f96668b1b5822cf6cad027
+ to 8bbfffe1651b896e371bf7a3506452d545cf81b3
+ Also local refs/remotes/origin/master
+Generating pack...
+Done counting 2 objects.
+Deltifying 2 objects...
+ 50% (1/2) done
100% (2/2) done
+Writing 2 objects...
+ 50% (1/2) done
100% (2/2) done
+Total 2 (delta 0), reused 0 (delta 0)
+refs/heads/master: c496be9e726d5c6ee0f96668b1b5822cf6cad027 -> 8bbfffe1651b896e371bf7a3506452d545cf81b3
+EOF
+
+( cd a &&
+echo "adding a line again" >> a.txt &&
+git commit -a -m "Updated the submodule from within the superproject." &&
+git push &&
+cd .. &&
+git add a &&
+git commit -m "Updated submodule a." &&
+git push) &> submodule-push.output
+
+test_expect_success "update the submodule from within the superproject" 'cmp submodule-push.expect submodule-push.output'
+
+test_done
--
1.5.3.2.80.g077d6f-dirty
^ permalink raw reply related
* Re: Git as a filesystem
From: Peter Stahlir @ 2007-09-21 13:35 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Johannes Schindelin, git
In-Reply-To: <alpine.LFD.0.9999.0709210912120.32185@xanadu.home>
> > I wonder how big a deltified Debian mirror in one pack file would be. :)
>
> It would be just as big as the non gitified storage on disk.
>
> The space saving with git comes from efficient delta storage of
> _versioned_ files, i.e. multiple nearly identical versions of the same
> file where the stored delta is only the small difference between the
> first full version and subsequent versions. Unless you plan on storing
> many different Debian versions together, you won't benefit from any
> delta at all. And since Debian packages are already compressed, git
> won't be able to compress them further.
>
> So don't waste your time.
The 252GB stem from the fact that there are more than 10 architectures.
I guess the /usr/share/doc of all architectures could be deltified (as could
be all files that are architecture-independent)
Right?
^ permalink raw reply
* Re: [PATCH 4/4] t6000lib: workaround a possible dash bug
From: Herbert Xu @ 2007-09-21 13:28 UTC (permalink / raw)
To: Eric Wong; +Cc: Junio C Hamano, git
In-Reply-To: <11486091792604-git-send-email-normalperson@yhbt.net>
Hi Eric:
On Thu, May 25, 2006 at 07:06:18PM -0700, Eric Wong wrote:
> pdksh doesn't need this patch, of course bash works fine since
> that what most users use.
>
> Normally, 'var=val command' seems to work fine with dash, but
> perhaps there's something weird going on with "$@". dash is
> pretty widespread, so it'll be good to support this even though
> it does seem like a bug in dash.
Just going through dash issues right now. Do you recall
what the bug is in this case? Doing a quick test doesn't
seem to show much:
dash -c 'set -- env; a=b "$@"'
> diff --git a/t/t6000lib.sh b/t/t6000lib.sh
> index c6752af..d402621 100755
> --- a/t/t6000lib.sh
> +++ b/t/t6000lib.sh
> @@ -69,7 +69,9 @@ on_committer_date()
> {
> _date=$1
> shift 1
> - GIT_COMMITTER_DATE=$_date "$@"
> + export GIT_COMMITTER_DATE="$_date"
> + "$@"
> + unset GIT_COMMITTER_DATE
> }
>
> # Execute a command and suppress any error output.
> --
> 1.3.2.g7d11
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: Git as a filesystem
From: Peter Stahlir @ 2007-09-21 13:28 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Johannes Schindelin, git
In-Reply-To: <20070921125337.GA28456@diana.vm.bytemark.co.uk>
> > I wonder how big a deltified Debian mirror in one pack file would
> > be. :)
>
> Very, very close to 252 GB, since .deb files are already compressed.
Yes, but if there were deb and tar support in git (to automatically unpack
archives and store the contents), together with the best available
binary diffs I think the repository could be significantly smaller because
files common to all architectures could be deltified,
I did a quick check with 100MB of deb archives; the result was nearly 100MB
as you said.
I also did a quick check with all .so files in my /usr/lib directory; it shrunk
from 50MB to 20MB, the same is achieved with tar + bz2.
But the thing is, I think there is a lot of redundancy in
a) a Debian mirror or
b) your disk at home.
Telling git to handle -for example- deb archives and storing
everything in a pack file would take advantage of redundancy across
_all_ files.
So the /usr/share/doc of all architectures could be compressed.
Right?
^ permalink raw reply
* Re: Git as a filesystem
From: Nicolas Pitre @ 2007-09-21 13:22 UTC (permalink / raw)
To: Peter Stahlir; +Cc: Johannes Schindelin, git
In-Reply-To: <fbe8b1780709210441n281248dbh5ba9934d09d6bbfc@mail.gmail.com>
On Fri, 21 Sep 2007, Peter Stahlir wrote:
> This is was I was looking for. My motivation is whether it is possible
> to run a system, for example Debian on a computer on top of gitfs,
> and then have a huge mirror on it, for example a complete 252GB
> Debian mirror as space efficient as possible.
>
> I wonder how big a deltified Debian mirror in one pack file would be. :)
It would be just as big as the non gitified storage on disk.
The space saving with git comes from efficient delta storage of
_versioned_ files, i.e. multiple nearly identical versions of the same
file where the stored delta is only the small difference between the
first full version and subsequent versions. Unless you plan on storing
many different Debian versions together, you won't benefit from any
delta at all. And since Debian packages are already compressed, git
won't be able to compress them further.
So don't waste your time.
Nicolas
^ permalink raw reply
* Re: Git as a filesystem
From: Karl Hasselström @ 2007-09-21 12:53 UTC (permalink / raw)
To: Peter Stahlir; +Cc: Johannes Schindelin, git
In-Reply-To: <fbe8b1780709210441n281248dbh5ba9934d09d6bbfc@mail.gmail.com>
On 2007-09-21 13:41:07 +0200, Peter Stahlir wrote:
> My motivation is whether it is possible to run a system, for example
> Debian on a computer on top of gitfs, and then have a huge mirror on
> it, for example a complete 252GB Debian mirror as space efficient as
> possible.
>
> I wonder how big a deltified Debian mirror in one pack file would
> be. :)
Very, very close to 252 GB, since .deb files are already compressed.
If it's just the gzip compression you want, surely there must be real
filesystems that can do that.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: Git as a filesystem
From: Peter Stahlir @ 2007-09-21 11:41 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0709211208440.28395@racer.site>
2007/9/21, Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> On Fri, 21 Sep 2007, Peter Stahlir wrote:
>
> > Is it possible/feasible to use git as a filesystem?
> > Like having git on top of ext3.
>
> I haven't looked at it closely, but there is a GitFS:
>
> http://git.or.cz/gitwiki/InterfacesFrontendsAndTools#head-f354b40618742b976c13700fe1fea28387ad5c89
>
> (I am pointing you to the Git Wiki, so that you can find more pointers
> should you not be happy with this one.)
Thank you.
This is was I was looking for. My motivation is whether it is possible
to run a system, for example Debian on a computer on top of gitfs,
and then have a huge mirror on it, for example a complete 252GB
Debian mirror as space efficient as possible.
I wonder how big a deltified Debian mirror in one pack file would be. :)
Peter
^ permalink raw reply
* Re: Git as a filesystem
From: Johannes Schindelin @ 2007-09-21 11:11 UTC (permalink / raw)
To: Peter Stahlir; +Cc: git
In-Reply-To: <fbe8b1780709210351x30775090ldab559f25c27645d@mail.gmail.com>
Hi,
On Fri, 21 Sep 2007, Peter Stahlir wrote:
> Is it possible/feasible to use git as a filesystem?
> Like having git on top of ext3.
I haven't looked at it closely, but there is a GitFS:
http://git.or.cz/gitwiki/InterfacesFrontendsAndTools#head-f354b40618742b976c13700fe1fea28387ad5c89
(I am pointing you to the Git Wiki, so that you can find more pointers
should you not be happy with this one.)
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Added a new placeholder '%cm' for full commit message
From: Johannes Schindelin @ 2007-09-21 11:08 UTC (permalink / raw)
To: Michal Vitecek; +Cc: git
In-Reply-To: <20070921110646.GA9072@mageo.cz>
Hi,
On Fri, 21 Sep 2007, Michal Vitecek wrote:
> Johannes Schindelin wrote:
> >On Fri, 21 Sep 2007, Michal Vitecek wrote:
> >
> >> I have added a new placeholder '%cm' for a full commit message.
> >
> >You mean the raw message, including the headers? Why not use "%r" for
> >that?
>
> No, sorry for the incorrect term. I meant the whole commit message
> (subject + 2*\n + body).
Ah, makes sense. In that case, "%M" maybe?
> >> I made it because I want to use my own pretty format which currently
> >> only allows '%s' for subject and '%b' for body. But '%b' is
> >> substituted with <undefined> if the body is "missing" which I
> >> obviously don't like :)
> >
> >Then you should fix %b not to show "<undefined>".
>
> I'll do it if it is okay. Shall I do the same for the other
> placeholders as well?
Yeah. Don't know why I did it that way.
> >And please adher to the tips in Documentation/SubmittingPatches.
>
> Will do, sorry about the attachment - still learning :)
No problem. Thanks for contributing!
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Added a new placeholder '%cm' for full commit message
From: Michal Vitecek @ 2007-09-21 11:06 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0709211146090.28395@racer.site>
Johannes Schindelin wrote:
>On Fri, 21 Sep 2007, Michal Vitecek wrote:
>
>> I have added a new placeholder '%cm' for a full commit message.
>
>You mean the raw message, including the headers? Why not use "%r" for
>that?
No, sorry for the incorrect term. I meant the whole commit message
(subject + 2*\n + body).
>> I made it because I want to use my own pretty format which currently
>> only allows '%s' for subject and '%b' for body. But '%b' is substituted
>> with <undefined> if the body is "missing" which I obviously don't like
>> :)
>
>Then you should fix %b not to show "<undefined>".
I'll do it if it is okay. Shall I do the same for the other
placeholders as well?
>And please adher to the tips in Documentation/SubmittingPatches.
Will do, sorry about the attachment - still learning :)
Thank you,
Michal
--
fuf (fuf@mageo.cz)
^ permalink raw reply
* Git as a filesystem
From: Peter Stahlir @ 2007-09-21 10:51 UTC (permalink / raw)
To: git
Hi!
Is it possible/feasible to use git as a filesystem?
Like having git on top of ext3.
This way I could do a gitfs-gc and there is only one
pack file sitting on the disk which is a compressed
version of the whole system.
I am not interested in a version controlled filesystem,
only in the space saving aspects.
Thanks,
Peter
^ permalink raw reply
* Re: [PATCH] Added a new placeholder '%cm' for full commit message
From: Johannes Schindelin @ 2007-09-21 10:47 UTC (permalink / raw)
To: Michal Vitecek; +Cc: git
In-Reply-To: <20070921101420.GD22869@mageo.cz>
Hi,
On Fri, 21 Sep 2007, Michal Vitecek wrote:
> I have added a new placeholder '%cm' for a full commit message.
You mean the raw message, including the headers? Why not use "%r" for
that?
> I made it because I want to use my own pretty format which currently
> only allows '%s' for subject and '%b' for body. But '%b' is substituted
> with <undefined> if the body is "missing" which I obviously don't like
> :)
Then you should fix %b not to show "<undefined>".
And please adher to the tips in Documentation/SubmittingPatches.
Thank you,
Dscho
^ permalink raw reply
* [PATCH] Added a new placeholder '%cm' for full commit message
From: Michal Vitecek @ 2007-09-21 10:14 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 377 bytes --]
Hello,
I have added a new placeholder '%cm' for a full commit message. I made
it because I want to use my own pretty format which currently only
allows '%s' for subject and '%b' for body. But '%b' is substituted with
<undefined> if the body is "missing" which I obviously don't like :)
Thanks for consideration,
Michal
--
fuf (fuf@mageo.cz)
[-- Attachment #2: 0001-Added-a-new-placeholder-cm-for-full-commit-messag.patch --]
[-- Type: text/plain, Size: 2764 bytes --]
>From 5e22a989e6805d860b8477393fa8a6cc54f35193 Mon Sep 17 00:00:00 2001
From: Michal Vitecek <fuf@mageo.cz>
Date: Fri, 21 Sep 2007 12:02:57 +0200
Subject: [PATCH] Added a new placeholder '%cm' for full commit message
---
Documentation/pretty-formats.txt | 1 +
commit.c | 18 +++++++++++++++++-
2 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
index 0193c3c..26c42d3 100644
--- a/Documentation/pretty-formats.txt
+++ b/Documentation/pretty-formats.txt
@@ -117,6 +117,7 @@ The placeholders are:
- '%e': encoding
- '%s': subject
- '%b': body
+- '%cm': commit message
- '%Cred': switch color to red
- '%Cgreen': switch color to green
- '%Cblue': switch color to blue
diff --git a/commit.c b/commit.c
index 99f65ce..1e24e21 100644
--- a/commit.c
+++ b/commit.c
@@ -814,6 +814,7 @@ long format_commit_message(const struct commit *commit, const void *format,
{ "%e" }, /* encoding */
{ "%s" }, /* subject */
{ "%b" }, /* body */
+ { "%cm" }, /* commit message (subject and body) */
{ "%Cred" }, /* red */
{ "%Cgreen" }, /* green */
{ "%Cblue" }, /* blue */
@@ -835,12 +836,14 @@ long format_commit_message(const struct commit *commit, const void *format,
IENCODING,
ISUBJECT,
IBODY,
+ ICOMMIT_MESSAGE,
IRED, IGREEN, IBLUE, IRESET_COLOR,
INEWLINE,
ILEFT_RIGHT,
};
struct commit_list *p;
char parents[1024];
+ int cm_len = 0;
int i;
enum { HEADER, SUBJECT, BODY } state;
const char *msg = commit->buffer;
@@ -897,6 +900,7 @@ long format_commit_message(const struct commit *commit, const void *format,
if (state == SUBJECT) {
table[ISUBJECT].value = xstrndup(msg + i, eol - i);
+ cm_len = eol - i + 2; /* + 2 for 2 newlines */
i = eol;
}
if (i == eol) {
@@ -915,8 +919,20 @@ long format_commit_message(const struct commit *commit, const void *format,
xstrndup(msg + i + 9, eol - i - 9);
i = eol;
}
- if (msg[i])
+ if (msg[i]) {
table[IBODY].value = xstrdup(msg + i);
+ cm_len += strlen(msg + i);
+ }
+ if (cm_len) {
+ table[ICOMMIT_MESSAGE].value = xmalloc(cm_len + 1);
+ table[ICOMMIT_MESSAGE].value[0] = '\0';
+ if (table[ISUBJECT].value) {
+ strcpy(table[ICOMMIT_MESSAGE].value, table[ISUBJECT].value);
+ strcat(table[ICOMMIT_MESSAGE].value, "\n\n");
+ }
+ if (table[IBODY].value)
+ strcat(table[ICOMMIT_MESSAGE].value, table[IBODY].value);
+ }
for (i = 0; i < ARRAY_SIZE(table); i++)
if (!table[i].value)
interp_set_entry(table, i, "<unknown>");
--
1.5.3.1
^ permalink raw reply related
* Re: [PATCH] git-svnimport: Use separate arguments in the pipe for git-rev-parse
From: Matthias Urlichs @ 2007-09-21 10:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Dan Libby, git
In-Reply-To: <7vabrgjyg3.fsf@gitster.siamese.dyndns.org>
Hi,
Junio C Hamano:
> Matthias Urlichs <smurf@smurf.noris.de> writes:
>
> >> we do not like 'Cristian new code' as a tag name.
> >
> > Duh? That's a perfectly valid tag name.
>
> Is it?
>
> $ man git-check-ref-format
Bah, stupid me. You're right, obviously.
I'll replace them with underscores. :-/
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Murphy's Law:
If anything can go wrong, it will.
^ permalink raw reply
* Re: [PATCH] [git-p4] Detect exec bit in more cases.
From: Simon Hausmann @ 2007-09-21 10:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: David Brown, git
In-Reply-To: <7vodfxj6db.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 889 bytes --]
On Friday 21 September 2007 00:53:52 Junio C Hamano wrote:
> David Brown <git@davidb.org> writes:
> > On Wed, Sep 19, 2007 at 09:03:50PM +0200, Simon Hausmann wrote:
> >>On Wednesday 19 September 2007 20:15:03 David Brown wrote:
> >>> git-p4 was missing the execute bit setting if the file had other
> >>> attribute bits set.
> >>> ---
> >>
> >>I'm fine with this, so unless you find a better way:
> >>
> >>Acked-By: Simon Hausmann <simon@lst.de>
> >
> > I sent out an improved version of this patch yesterday
> > <1190232768445-git-send-email-git@davidb.org> that I'd like to get
> > approved. I guess I'm not quite sure what happens at this point with a
> > patch.
>
> I still have that *768445* message as "the last one proposed as
> better than previous ones" in my mbox.
>
> Simon?
Indeed, the new improved version is much better :)
Acked-By: Simon Hausmann <simon@lst.de>
Simon
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: stg branch --delete doesn't work
From: Karl Hasselström @ 2007-09-21 9:48 UTC (permalink / raw)
To: Aneesh Kumar; +Cc: Git Mailing List, catalin.marinas
In-Reply-To: <cc723f590709202140y677a17d0y504b8cfa8b66606b@mail.gmail.com>
On 2007-09-21 10:10:45 +0530, Aneesh Kumar wrote:
> [review@linux-review-ext4]$ git checkout master
> Switched to branch "master"
> [master@linux-review-ext4]$ stg branch --delete --force review
> Deleting branch "review" ...
> fatal: Needed a single revision
> stg branch: refs/heads/review does not exist
>
> And it leaves in .git/config
> [branch "test2.stgit"]
> stackformatversion = 2
>
> So a later stg init also fails.
Ow! You'd think we'd have a test for that ...
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH] Add git-rev-list --invert-match
From: Jeff King @ 2007-09-21 9:19 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Bart Trojanowski, git
In-Reply-To: <Pine.LNX.4.64.0709210904210.28395@racer.site>
On Fri, Sep 21, 2007 at 10:10:12AM +0100, Johannes Schindelin wrote:
> Indeed, it has a certain elegance to it. However, I cannot specify any
> rev-list options with your method, not even "--stat" or
> "--pretty=format:%H(%s)".
Actually, you can pass --stat, but it erroneously is counted as part of
the message due to a parsing bug in the script. However you are pointing
out a larger issue, which is that the format must be parseable by the
script. As a final step, the script could turn the output into a list of
commits, and pipe them into a git command which pretty-printed in the
desired format.
But that is doubly hack-ish, and slow to boot.
> So while your script is a good interim solution, I'd like to see a
> generic grep support for this feature.
Yes, I don't seriously propose it for mainline git. However, I quite
like the interface; unfortunately, to get it to work smoothly (and
efficiently!) the perl interpreter would need to be embedded inside
git-log. And I think I know what you will say about that... :)
-Peff
^ permalink raw reply
* Re: [PATCH] Add git-rev-list --invert-match
From: Johannes Schindelin @ 2007-09-21 9:10 UTC (permalink / raw)
To: Jeff King; +Cc: Bart Trojanowski, git
In-Reply-To: <20070921041821.GA28245@coredump.intra.peff.net>
Hi,
On Fri, 21 Sep 2007, Jeff King wrote:
> On Thu, Sep 20, 2007 at 02:12:54PM +0100, Johannes Schindelin wrote:
>
> > Further, it probably makes sense to have the option to say _both_: "Find
> > me a commit that contains Bart in one line, but not Simpson, and that
> > does not contain the word "Sverdoolaege" at all."
>
> This is perhaps a little hack-ish compared to better grep support in the
> core, but I find complex logic through command line options to be
> somewhat unreadable. I prefer something more Perl-ish like this:
>
> git-revgrep 'message =~ /bart/i
> && message !~ /Simpson/
> && author_name !~ /Sverdoolaege/'
Indeed, it has a certain elegance to it. However, I cannot specify any
rev-list options with your method, not even "--stat" or
"--pretty=format:%H(%s)".
So while your script is a good interim solution, I'd like to see a
generic grep support for this feature.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 0/3] git-svn: pass tests on svn trunk
From: Eric Wong @ 2007-09-21 8:27 UTC (permalink / raw)
To: Sam Vilain; +Cc: git
In-Reply-To: <1190340155146-git-send-email-sam.vilain@catalyst.net.nz>
Sam Vilain <sam.vilain@catalyst.net.nz> wrote:
> While svn trunk is a dubious target to integrate with, perhaps these
> patches will prove useful to include anyway.
>
> Tested against svn 1.4.2 and svn trunk r26724
Fine by me, as what's in trunk will likely be in a released version some
day and I'm glad that people are already testing git-svn against it.
This series Acked-by: Eric Wong <normalperson@yhbt.net>
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] git-svn: handle changed svn command-line syntax
From: Eric Wong @ 2007-09-21 8:23 UTC (permalink / raw)
To: Sam Vilain; +Cc: git
In-Reply-To: <46F33A05.2000906@vilain.net>
Sam Vilain <sam@vilain.net> wrote:
> Sam Vilain wrote:
> > Sam Vilain wrote:
> >> Previously, if you passed a revision and a path to svn, it meant to look
> >> back at that revision and select that path. New behaviour is to get the
> >> path then go back to the revision. The old syntax is selected with new
> >> syntax PATH@REV. This new syntax is not supported by the old tools, so we
> >> have to try both in turn.
> >
> > Blast, this analysis is wrong. Hold off, I'll see what's really going
> > on and re-submit.
>
> ok, figured it out :)
>
> I was close! I was just thrown off by 'svn ls PATH@REV'
>
> The patch is the same, just the description has changed.
>
> Subject: [PATCH] git-svn: handle changed svn cp command-line syntax
>
> Previously, if you passed a revision and a path to svn cp, it meant to look
> back at that revision and select that path. New behaviour is to get the
> path then go back to the revision (like other commands that accept @REV
> or -rREV do). The more consistent syntax is not supported by the old
> tools, so we have to try both in turn.
The @REV and -rREV distinction/ambiguity has always confused me in svn,
too. It always seems that it needed to be one way sometimes, the other
way at other times, and even _both_ at other times...
--
Eric Wong
^ permalink raw reply
* [DON'T MERGE PATCH 7/7]
From: Pierre Habouzit @ 2007-09-21 7:39 UTC (permalink / raw)
To: gitster, git
In-Reply-To: <20070921070329.GB5689@artemis.corp>
[-- Attachment #1: Type: text/plain, Size: 1123 bytes --]
On Fri, Sep 21, 2007 at 07:03:29AM +0000, Pierre Habouzit wrote:
> On jeu, sep 20, 2007 at 10:05:06 +0000, Pierre Habouzit wrote:
> > On mer, sep 19, 2007 at 10:42:16 +0000, Pierre Habouzit wrote:
> >
> > As someone pointed to me off-list the above should be:
> > + if (rf_one) {
> > + (*write_ref)[targets] = xmemdupz(rf_one + 1, buf.len - (rf_one + 1 - buf.buf));
> > + } else {
> >
> > Or better:
> > + if (rf_one) {
> > + rf_one++; /* skip \t */
> > + (*write_ref)[targets] = xmemdupz(rf_one, buf.buf + buf.len - rf_one);
> > + } else {
> >
> > Which is definitely more readable.
>
> damn it was not the error that was reported to me, there is another
> one, I'll roll a new patch, sorry :/
Okay this patch is worthless, the previous version worked the same, I
totally missed what it did. I should not code when I'm too tired, I'm
sorry.
Don't merge patch 7/7 it's broken.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ 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