* Re: git and mtime
From: Andreas Ericsson @ 2008-11-20 13:12 UTC (permalink / raw)
To: Roger Leigh; +Cc: Matthias Kestenholz, git
In-Reply-To: <49255CBA.4030709@op5.se>
Andreas Ericsson wrote:
> Roger Leigh wrote:
>> For this, and some other uses I have in mind for git, it would be
>> great if git could store some more components of the inode
>> metadata in the tree, such as:
>> - mtime
>> - user
>> - group
>> - full permissions
>> - and also allow storage of the full range of file types (i.e.
>> block, character, pipe, etc.)
>>
>> This would allow git to be used as the basis for a complete
>> functional versioned filesystem (which I'd like to use for my
>> lightweight virtualisation tool, schroot, which currently
>> uses LVM snapshots for this purpose).
>>
>
> I believe someone else has done some work along the way of
> turning git into complete-with-metadata backupsystem before.
> Google might prove beneficial.
>
Although now that I come to think of it, storing "user" and
"group" made it near-enough totally useless for anything a
user had created as the repos hardly ever could be shared.
I'll say it again; Hooks can be written to handle this.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git and mtime
From: Randal L. Schwartz @ 2008-11-20 13:11 UTC (permalink / raw)
To: Roger Leigh; +Cc: Christian MICHON, git
In-Reply-To: <20081120112708.GC22787@ravenclaw.codelibre.net>
>>>>> "Roger" == Roger Leigh <rleigh@codelibre.net> writes:
Roger> Except in this case I'm storing the content of *tarballs* (along with
Roger> pristine-tar). I'm committing exactly what's in the tarball with
Roger> no changes (this is a requirement). I can't change the source prior
Roger> to commit.
If you're not doing distributed source code development, why are you using
git? It's hard to be angry at a screwdriver for not pounding in nails
properly.
Sounds like you want rsync or something.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
^ permalink raw reply
* Re: git commit -v does not removes the patch
From: SZEDER Gábor @ 2008-11-20 13:09 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Santi Béjar, Git Mailing List
In-Reply-To: <20081112081609.GA3720@coredump.intra.peff.net>
Hi,
On Wed, Nov 12, 2008 at 03:16:09AM -0500, Jeff King wrote:
> Here's a patch series that at least improves the situation by turning
> off the diff-stripping if we never put in a diff in the first place.
> That way only people who actually _use_ "-v" will have to pay for it.
I always want to see the diff while editing a commit message, even if
it's the commit message of a merge, a revert, a squash in rebase.
Since these commands do not have an option equivalent to 'git commit
-v', I wrote a little prepare-commit-msg hook to always append the
appropriate diff to the end of the appropriate commit message file.
This worked pretty well for the last couple of months, until 5/5 got
into maint.
So, what is the/is there a preferred way to always include the diff in
the commit message template and get it removed automatically? Are
there any workarounds other than revert that commit locally?
Thanks,
Gábor
^ permalink raw reply
* Re: Git.pm
From: Petr Baudis @ 2008-11-20 13:07 UTC (permalink / raw)
To: nadim khemir; +Cc: git
In-Reply-To: <20081120083446.GF10544@machine.or.cz>
On Thu, Nov 20, 2008 at 09:34:46AM +0100, Petr Baudis wrote:
> I know it's quite some time since you wrote this mail originally -
> have you read the Lea's thread I have recommended? What is your current
> plan?
Since people are asking for pointers, I'm talking about the
http://thread.gmane.org/gmane.comp.version-control.git/88068/focus=88365
and the associated superthread and subthread.
--
Petr "Pasky" Baudis
People who take cold baths never have rheumatism, but they have
cold baths.
^ permalink raw reply
* Re: git and mtime
From: Andreas Ericsson @ 2008-11-20 13:06 UTC (permalink / raw)
To: Roger Leigh; +Cc: Christian MICHON, git
In-Reply-To: <20081120112708.GC22787@ravenclaw.codelibre.net>
Roger Leigh wrote:
> On Wed, Nov 19, 2008 at 05:18:16PM +0100, Christian MICHON wrote:
>> On Wed, Nov 19, 2008 at 12:37 PM, Roger Leigh <rleigh@codelibre.net> wrote:
>>> Would it be possible for git to store the mtime of files in the tree?
>>>
>>> This would make it possible to do this type of work in git, since it's
>>> currently a bit random as to whether it works or not. This only
>>> started when I upgraded to an amd64 architecture from powerpc32,
>>> I guess it's maybe using high-resolution timestamps.
>>>
>> beside the obvious answer it comes back often as a request, it is
>> possible in theory to create a shell script which, for each file
>> present in the sandbox in the current branch, would find the mtime of
>> the last commit on that file (quite an expensive operation) and apply
>> it.
>
> Surely this is only expensive because you're not already storing the
> information in the tree; if it was there, it would be (relatively)
> cheap?
No, it's because git is *snapshot* based and doesn't care about anything
but contents. Storing filestate information in the tree would be a
backwards incompatible change that would require a major version change.
Caring about meta-data the way you mean it would mean that
git add foo.c; git commit -m "kapooie"; touch foo.c; git status
would show "foo.c" as modified. How sane is that? Or should we introduce
a new concept for altered metadata only? "metafied"? So what do we do
when the next user whizzes along and wants support for full acl's? And
what do we do when Windows (or some other bizarre system) add some sort
of extension so we have to have different types of ACL support on both
systems? Kablooie and welcome to interoperability hell.
> You could even compare the old and new trees to see if you
> needed to touch a file at all.
>
We already do that by matching the SHA1 hash for the index entries.
Only content that is actually different between to branches are altered
upon checkout (which is why it's so damn fast when you're using topic-
branches properly).
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Whats happening with git-notes?
From: Johannes Schindelin @ 2008-11-20 13:12 UTC (permalink / raw)
To: Tim Ansell; +Cc: git
In-Reply-To: <1227183162.23155.32.camel@vaio>
Hi,
On Thu, 20 Nov 2008, Tim Ansell wrote:
> I was just wondering what is happening with git notes stuff? I really
> like the idea of being able to annotate commits with various
> information.
>
> After the gittogether it sounded like we had a solid proposal and
> possible implementation, has anything happened since then? I had a quick
> look over the archives but didn't seem much mention of them in the last
> couple of weeks.
>
> Thanks for your help.
>
> Tim 'mithro' Ansell
> PS I'm going to try harder to find the time to continue to work on the
> git-media cloning stuff, been a bit snowed under at work.
The same goes on here. I wanted to take Peff's idea -- that hadn't
occurred to me back when I tried to help Johan with his notes idea --
which is to read in the whole notes tree into a singleton when needed, and
incorporate it into my existing test framework.
Maybe I'll find time later today.
Ciao,
Dscho
^ permalink raw reply
* [PATCH/gitweb-caching] perl/: fix optional argument handling in _load methods
From: Christian Jaeger @ 2008-11-20 12:41 UTC (permalink / raw)
To: git; +Cc: Lea Wiemann
Perl's 'shift' only ever delivers the first of all subroutine/method
arguments, meaning that $self would be assigned a value but $raw_text
would always remain undef even if an argument would have been passed
to the method.
Signed-off-by: Christian Jaeger <christian@jaeger.mine.nu>
---
This is a fix for the code in git://repo.or.cz/git/gitweb-caching.git
perl/Git/Commit.pm | 3 ++-
perl/Git/Tag.pm | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/perl/Git/Commit.pm b/perl/Git/Commit.pm
index ee87e11..6ed076b 100644
--- a/perl/Git/Commit.pm
+++ b/perl/Git/Commit.pm
@@ -141,7 +141,8 @@ sub encoding {
# The raw contents of the commit object; the commit object will be
# retrieved from the repository if that parameter is not given.
sub _load {
- my ($self, $raw_text) = shift;
+ my $self = shift;
+ my ($raw_text)=@_;
return if exists $self->{message}; # already loaded
my $sha1 = $self->sha1;
diff --git a/perl/Git/Tag.pm b/perl/Git/Tag.pm
index 5622431..e1f1201 100644
--- a/perl/Git/Tag.pm
+++ b/perl/Git/Tag.pm
@@ -132,7 +132,8 @@ sub encoding {
# The raw contents of the tag object; the tag object will be retrieved
# from the repository if that parameter is not given.
sub _load {
- my ($self, $raw_text) = shift;
+ my $self = shift;
+ my ($raw_text)=@_;
return if exists $self->{message}; # already loaded
my $sha1 = $self->sha1;
--
1.6.0.4
^ permalink raw reply related
* Re: git and mtime
From: Andreas Ericsson @ 2008-11-20 12:48 UTC (permalink / raw)
To: Roger Leigh; +Cc: Matthias Kestenholz, git
In-Reply-To: <20081120112051.GB22787@ravenclaw.codelibre.net>
Roger Leigh wrote:
> On Thu, Nov 20, 2008 at 09:38:28AM +0100, Andreas Ericsson wrote:
>> Matthias Kestenholz wrote:
>>> Hi,
>>>
>>> On 19.11.2008, at 12:37, Roger Leigh wrote:
>>>
>>>> I'm using git to store some generated files, as well as their sources.
>>>> (This is in the context of Debian package development, where entire
>>>> upstream release tarballs are injected into an upstream branch, with
>>>> Debian releases merging the upstream branch, and adding the Debian
>>>> packaging files.)
>>>>
>>>> The upstream release tarballs contains files such as
>>>> - yacc/lex code, and the corresponding generated sources
>>>> - Docbook/XML code, and corresponding HTML/PDF documentation
>>>>
>>>> Would it be possible for git to store the mtime of files in the tree?
>>> This subject comes up from time to time, but the answer always
>>> stays the same: No. The trees are purely defined by their content, and
>>> that's by design.
>>>
>>> If you do not want to regenerate files that are already up-to-date,
>>> you need multiple checkouts of the same repository.
>> Or a make-rule that touches the files you know are up to date. Since you
>> control the build environment, that's probably the simplest solution.
>
> This is the approach I'm currently taking, since it's simple and
> doesn't require any tool changes. Ideally, I'd like to avoid
> such hackiness, though.
>
> I understand all the arguments I've seen in favour of not using the
> mtime of the files when checking out. They make sense. However,
> in some situations (such as this), they do not--git is breaking
> something that was previously working. In my case, I'm
> injecting *release tarballs* into git, and the timestamps on the
> files really do matter. Regarding issues with branching and branch
> switching, I always do builds from clean in this case.
>
> If an option was added to git-checkout to restore mtimes, it need
> not be the default, but git could record them on commit and then
> restore them if asked /explicitly/.
>
You can. The way to ask explicitly right now is to write hooks
that implement the functionality you want. It's not as easy as
setting a config value, but since you'd have to write the patch
to do that anyways (and it's likely it will get dropped), you'd
be better off writing some hooks and submitting them as contrib
stuff.
> For this, and some other uses I have in mind for git, it would be
> great if git could store some more components of the inode
> metadata in the tree, such as:
> - mtime
> - user
> - group
> - full permissions
> - and also allow storage of the full range of file types (i.e.
> block, character, pipe, etc.)
>
> This would allow git to be used as the basis for a complete
> functional versioned filesystem (which I'd like to use for my
> lightweight virtualisation tool, schroot, which currently
> uses LVM snapshots for this purpose).
>
I believe someone else has done some work along the way of
turning git into complete-with-metadata backupsystem before.
Google might prove beneficial.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git and mtime
From: Roger Leigh @ 2008-11-20 11:20 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Matthias Kestenholz, git
In-Reply-To: <49252204.2070906@op5.se>
[-- Attachment #1: Type: text/plain, Size: 2772 bytes --]
On Thu, Nov 20, 2008 at 09:38:28AM +0100, Andreas Ericsson wrote:
> Matthias Kestenholz wrote:
>> Hi,
>>
>> On 19.11.2008, at 12:37, Roger Leigh wrote:
>>
>>> I'm using git to store some generated files, as well as their sources.
>>> (This is in the context of Debian package development, where entire
>>> upstream release tarballs are injected into an upstream branch, with
>>> Debian releases merging the upstream branch, and adding the Debian
>>> packaging files.)
>>>
>>> The upstream release tarballs contains files such as
>>> - yacc/lex code, and the corresponding generated sources
>>> - Docbook/XML code, and corresponding HTML/PDF documentation
>>>
>>> Would it be possible for git to store the mtime of files in the tree?
>>
>> This subject comes up from time to time, but the answer always
>> stays the same: No. The trees are purely defined by their content, and
>> that's by design.
>>
>> If you do not want to regenerate files that are already up-to-date,
>> you need multiple checkouts of the same repository.
>
> Or a make-rule that touches the files you know are up to date. Since you
> control the build environment, that's probably the simplest solution.
This is the approach I'm currently taking, since it's simple and
doesn't require any tool changes. Ideally, I'd like to avoid
such hackiness, though.
I understand all the arguments I've seen in favour of not using the
mtime of the files when checking out. They make sense. However,
in some situations (such as this), they do not--git is breaking
something that was previously working. In my case, I'm
injecting *release tarballs* into git, and the timestamps on the
files really do matter. Regarding issues with branching and branch
switching, I always do builds from clean in this case.
If an option was added to git-checkout to restore mtimes, it need
not be the default, but git could record them on commit and then
restore them if asked /explicitly/.
For this, and some other uses I have in mind for git, it would be
great if git could store some more components of the inode
metadata in the tree, such as:
- mtime
- user
- group
- full permissions
- and also allow storage of the full range of file types (i.e.
block, character, pipe, etc.)
This would allow git to be used as the basis for a complete
functional versioned filesystem (which I'd like to use for my
lightweight virtualisation tool, schroot, which currently
uses LVM snapshots for this purpose).
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: git and mtime
From: Roger Leigh @ 2008-11-20 11:27 UTC (permalink / raw)
To: Christian MICHON; +Cc: git
In-Reply-To: <46d6db660811190818r3aa2a392pda9106ac4a579cf0@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1723 bytes --]
On Wed, Nov 19, 2008 at 05:18:16PM +0100, Christian MICHON wrote:
> On Wed, Nov 19, 2008 at 12:37 PM, Roger Leigh <rleigh@codelibre.net> wrote:
> > Would it be possible for git to store the mtime of files in the tree?
> >
> > This would make it possible to do this type of work in git, since it's
> > currently a bit random as to whether it works or not. This only
> > started when I upgraded to an amd64 architecture from powerpc32,
> > I guess it's maybe using high-resolution timestamps.
> >
>
> beside the obvious answer it comes back often as a request, it is
> possible in theory to create a shell script which, for each file
> present in the sandbox in the current branch, would find the mtime of
> the last commit on that file (quite an expensive operation) and apply
> it.
Surely this is only expensive because you're not already storing the
information in the tree; if it was there, it would be (relatively)
cheap? You could even compare the old and new trees to see if you
needed to touch a file at all.
> You should store mostly content of source files. You should do a make
> in your first cloned repo at least once before committing anything to
> the repo. That's what I did and I saved days...
Except in this case I'm storing the content of *tarballs* (along with
pristine-tar). I'm committing exactly what's in the tarball with
no changes (this is a requirement). I can't change the source prior
to commit.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Whats happening with git-notes?
From: Tim Ansell @ 2008-11-20 12:12 UTC (permalink / raw)
To: git
Hey guys,
I was just wondering what is happening with git notes stuff? I really
like the idea of being able to annotate commits with various
information.
After the gittogether it sounded like we had a solid proposal and
possible implementation, has anything happened since then? I had a quick
look over the archives but didn't seem much mention of them in the last
couple of weeks.
Thanks for your help.
Tim 'mithro' Ansell
PS I'm going to try harder to find the time to continue to work on the
git-media cloning stuff, been a bit snowed under at work.
^ permalink raw reply
* [TopGit PATCH] Require an argument to tg -r
From: martin f. krafft @ 2008-11-20 12:08 UTC (permalink / raw)
To: git, pasky; +Cc: martin f. krafft
Right now, if -r is passed to tg, an ugly shift error occurs. This patch
checks for that case and outputs the help message if it occurs.
Signed-off-by: martin f. krafft <madduck@debian.org>
---
tg.sh | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/tg.sh b/tg.sh
index 4dcc15e..a5dc0a7 100644
--- a/tg.sh
+++ b/tg.sh
@@ -261,7 +261,13 @@ setup_hook "pre-commit"
[ -z "$tg__include" ] || return 0
if [ "$1" = "-r" ]; then
- shift; base_remote="$1"; shift
+ shift
+ if [ -z "$1" ]; then
+ echo "Option -r requires an argument." >&2
+ do_help
+ exit 1
+ fi
+ base_remote="$1"; shift
tg="$tg -r $base_remote"
fi
--
tg: (f17218e..) fixes/tg--r-require-arg (depends on: upstream)
^ permalink raw reply related
* [TopGit PATCH] Print help message when command is not proper
From: martin f. krafft @ 2008-11-20 12:08 UTC (permalink / raw)
To: git, pasky; +Cc: martin f. krafft
When invoked with an unknown subcommand, or when --help is sought for
a command that does not exist, TopGit prints the help message.
Signed-off-by: martin f. krafft <madduck@debian.org>
---
tg.sh | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/tg.sh b/tg.sh
index 4dcc15e..2464612 100644
--- a/tg.sh
+++ b/tg.sh
@@ -232,6 +232,8 @@ do_help()
fi
else
echo "`basename $0`: no help for $1" 1>&2
+ do_help
+ exit 1
fi
}
@@ -279,6 +281,7 @@ help|--help|-h)
*)
[ -r "@cmddir@"/tg-$cmd ] || {
echo "Unknown subcommand: $cmd" >&2
+ do_help
exit 1
}
. "@cmddir@"/tg-$cmd;;
--
tg: (f17218e..) fixes/more-help (depends on: upstream)
^ permalink raw reply related
* Re: [PATCH] Document levenshtein.c
From: Samuel Tardieu @ 2008-11-20 12:00 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0811201255120.30769@pacific.mpi-cbg.de>
* Johannes Schindelin <Johannes.Schindelin@gmx.de> [2008-11-20 13:00:35 +0100]
| How about this?
I think it still lacks a note about what "deletion" and "insertion" means
(is that a character deleted from string1 to obtain string2 or the reverse?).
In most implementation, you use the same cost for insertion and deletion
so the function is symetrical, but this implementation is more powerful.
^ permalink raw reply
* [PATCH] Document levenshtein.c
From: Johannes Schindelin @ 2008-11-20 12:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Samuel Tardieu, git
In-Reply-To: <7vhc63svsl.fsf@gitster.siamese.dyndns.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Wed, 19 Nov 2008, Junio C Hamano wrote:
> It is a sure sign that the original implementation was too
> scantily described, and that the fix was not explained well in the
> proposed commit log message (i.e. in what corner cases the original
> was bad in what way, and how the patch fixes it).
How about this?
levenshtein.c | 31 +++++++++++++++++++++++++++++++
1 files changed, 31 insertions(+), 0 deletions(-)
diff --git a/levenshtein.c b/levenshtein.c
index db52f2c..298907a 100644
--- a/levenshtein.c
+++ b/levenshtein.c
@@ -1,6 +1,39 @@
#include "cache.h"
#include "levenshtein.h"
+/*
+ * This function implements the Damerau-Levenshtein algorithm to
+ * calculate a distance between strings.
+ *
+ * The idea is to build a distance matrix for the substrings of both
+ * strings. To avoid a large space complexity, only the last three rows
+ * are kept in memory (if swaps had the same or higher cost as one deletion
+ * plus one insertion, only two rows would be needed).
+ *
+ * At any stage, "i + 1" denotes the length of the current substring of
+ * string1 that the distance is calculated for (likewise "j + 1" for
+ * string2).
+ *
+ * row2 holds the current row, row1 the previous row (i.e. for the substring
+ * of string1 of length "i"), and row0 the row before that.
+ *
+ * In other words, at the start of the big loop, row1[j + 1] contains the
+ * Damerau-Levenshtein distance between the substring of string1 of length
+ * "i" and the substring of string2 of length "j + 1".
+ *
+ * All the big loop does is determine the partial minimum-cost paths.
+ *
+ * It does so by calculating the costs of the path ending in characters
+ * i (in string1) and j (in string2), respectively, given that the last
+ * operation is a substition, a swap, a deletion, or an insertion.
+ *
+ * This implementation allows the costs to be weighted:
+ *
+ * - w (as in "sWap")
+ * - s (as in "Substition")
+ * - a (for insertion, AKA "Add")
+ * - d (as in "Deletion")
+ */
int levenshtein(const char *string1, const char *string2,
int w, int s, int a, int d)
{
--
1.6.0.2.763.g72663
^ permalink raw reply related
* Re: [TopGit PATCH] Check for help invocation before setup
From: martin f krafft @ 2008-11-20 11:48 UTC (permalink / raw)
To: Petr Baudis; +Cc: git discussion list
In-Reply-To: <20081119183902.GX10491@machine.or.cz>
[-- Attachment #1: Type: text/plain, Size: 777 bytes --]
also sprach Petr Baudis <pasky@suse.cz> [2008.11.19.1939 +0100]:
> Oh, oops - I missed the loop, I should get some lunch. ;-)
> Thus, something like this?
>
> check_help() { while [ -n "$1" ]; do ...; shift; done }
> check_help "$@"
Why didn't I think of that???
I just sent an updated patch without threading, sorry. tg-mail just
fires without confirmation... :/
--
.''`. martin f. krafft <madduck@debian.org>
: :' : proud Debian developer, author, administrator, and user
`. `'` http://people.debian.org/~madduck - http://debiansystem.info
`- Debian - when you have better things to do than fixing systems
"the pure and simple truth is rarely pure and never simple."
-- oscar wilde
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] Allow help/--help/-h to be run outside of a TopGit repo
From: martin f. krafft @ 2008-11-20 11:46 UTC (permalink / raw)
To: git, pasky; +Cc: martin f. krafft
The user ought to be able to call `tg help` from anywhere in the filesystem,
not just Git repositories, so the help parsing has to happen before the calls
to git git binary.
Debian bug: #501982
Signed-off-by: martin f. krafft <madduck@debian.org>
---
tg.sh | 28 +++++++++++++++++++++++++---
1 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/tg.sh b/tg.sh
index 4dcc15e..258f8ce 100644
--- a/tg.sh
+++ b/tg.sh
@@ -235,12 +235,37 @@ do_help()
fi
}
+# Check whether we are supposed to output the help message
+should_do_help()
+{
+ # we are being sourced for utility functions, never run help
+ [ -z "$tg__include" ] || return 1
+
+ local prev
+ while [ -n "$1" ]; do
+ case "$1" in
+ help|--help|-h)
+ shift
+ echo "${1:-$prev}"
+ return 0
+ esac
+ prev="$1"
+ shift
+ done
+
+ # run help when there was no previous topic, meaning that there where
+ # no arguments at all
+ test -z "$prev"
+}
## Startup
[ -d "@cmddir@" ] ||
die "No command directory: '@cmddir@'"
+# check if we should run help and get the topic while we're at it
+help_topic="$(should_do_help "$@")" && { do_help "$help_topic"; exit 0; }
+
## Initial setup
set -e
@@ -270,9 +295,6 @@ cmd="$1"
shift
case "$cmd" in
-help|--help|-h)
- do_help "$1"
- exit 0;;
--hooks-path)
# Internal command
echo "@hooksdir@";;
--
tg: (f17218e..) fixes/independent-help (depends on: upstream)
^ permalink raw reply related
* Re: [PATCH] Updated Swedish translation (514t0f0u).
From: Andreas Ericsson @ 2008-11-20 11:10 UTC (permalink / raw)
To: Peter Krefting; +Cc: Shawn O. Pearce, Git Mailing List, Mikael Magnusson
In-Reply-To: <Pine.LNX.4.64.0811201047180.1606@ds9.cixit.se>
Some english notes in there too.
Peter Krefting wrote:
> +"* Untracked file is %d bytes.\n"
> +"* Showing only first %d bytes.\n"
> +msgstr "* Den ospårad filen är %d byte.\n"
> +"* Visar endast inledande %d byte.\n"
>
s/ospårad/ospårade/
> +#: lib/mergetool.tcl:45
> +#, tcl-format
> +msgid "File %s seems to have unresolved conflicts, still stage?"
> +msgstr "Filen %s verkar innehålla olösta konflikter, vill du ändå köa?"
> +
's/, vill/. Vill/'
Should probably be two sentences in english too.
> +
> +#: lib/mergetool.tcl:303
> +msgid "Merge tool is already running, terminate it?"
> +msgstr "Verktyget för sammanslagning körs redan, vill du avsluta det?"
> +
Same as above.
>
> -#: lib/option.tcl:128
> +#: lib/option.tcl:151
> +msgid "Blame History Context Radius (days)"
> +msgstr "Historikkontextradie för klandring (dagar)"
> +
At least a 100 points in scrabble for "historikkontextradie". How about
"Historikradie för klandring (dagar)"?
Imo, "context" is noise in both english and swedish, and should probably
be removed.
>
> +#: lib/remote.tcl:163
> +msgid "Remove Remote"
> +msgstr "Ta bort fjärr"
> +
> +#: lib/remote_add.tcl:19
> +msgid "Add Remote"
> +msgstr "Lägg till fjärr"
> +
> +#: lib/remote_add.tcl:24
> +msgid "Add New Remote"
> +msgstr "Lägg till ny fjärr"
> +
> +
> +#: lib/remote_add.tcl:37
> +msgid "Remote Details"
> +msgstr "Detaljer för fjärr"
> +
> +
> +#: lib/remote_add.tcl:71
> +msgid "Initialize Remote Repository and Push"
> +msgstr "Initiera fjärrarkiv och sänd till"
> +
> +
> +#: lib/remote_add.tcl:101
> +msgid "Please supply a remote name."
> +msgstr "Ange ett namn för fjärren."
> +
> +#: lib/remote_add.tcl:114
> +#, tcl-format
> +msgid "'%s' is not an acceptable remote name."
> +msgstr "\"%s\" kan inte användas som namn på fjärren."
> +
> +#: lib/remote_add.tcl:125
> +#, tcl-format
> +msgid "Failed to add remote '%s' of location '%s'."
> +msgstr "Kunde inte lägga till fjärren \"%s\" på platsen \"%s\"."
> +
Använd "fjärrarkiv" konsekvent istället. "fjärr" används, såvitt jag
vet, inte ensamt någonstans i svenska språket, annat än som slang.
> +
> #: lib/remote_branch_delete.tcl:29 lib/remote_branch_delete.tcl:34
> -msgid "Delete Remote Branch"
> +msgid "Delete Branch Remotely"
> msgstr "Ta bort fjärrgren"
>
"Ta bort gren i fjärrarkivet" (fjärrgren är något annat)
> +
> +#: lib/tools.tcl:111
> +#, tcl-format
> +msgid "Running: %s"
> +msgstr "Kör: %s"
> +
s/Kör/Exekverar/ (upplysning, inte uppmaning)
Other than that:
Acked-by: Andreas Ericsson <ae@op5.se>
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git and mtime
From: Matthieu Moy @ 2008-11-20 10:53 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Arafangion, Roger Leigh, git
In-Reply-To: <alpine.DEB.1.00.0811201132220.30769@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Wed, 19 Nov 2008, Matthieu Moy wrote:
>
>> Arafangion <thestar@fussycoder.id.au> writes:
>>
>> > You should probably fix your build script,
>>
>> ccache should help:
>
> Only if you _allow_ the problem that makes ccache necessary. Which we
> don't.
You do, for some definition of "problem".
make
git checkout whatever
make
git checkout where-you-were-before
make # <--- this one
The last make is correct with plain git and plain make, but it can be
slow. With a cache in your build system, it can just reuse the objects
created during the first "make". It doesn't change correctness, only
performance.
--
Matthieu
^ permalink raw reply
* Re: fatal: did you run git update-server-info on the server? mv post-update.sample post-update
From: Johannes Schindelin @ 2008-11-20 11:05 UTC (permalink / raw)
To: Gary Yang; +Cc: git
In-Reply-To: <155056.88492.qm@web37905.mail.mud.yahoo.com>
Hi,
On Wed, 19 Nov 2008, Gary Yang wrote:
> I did not run post-update at public repository manually. Do I need to
> run it for the very first time?
You need to run it when you installed the hook _after_ seeing the message
"did you run...".
Ciao,
Dscho
^ permalink raw reply
* Re: [TopGit PATCH] Use the topological order when exporting explicitly listed branches.
From: martin f krafft @ 2008-11-20 10:54 UTC (permalink / raw)
To: Petr Baudis; +Cc: git, Niko Tyni
In-Reply-To: <20081120102005.GB10491@machine.or.cz>
[-- Attachment #1: Type: text/plain, Size: 1810 bytes --]
also sprach Petr Baudis <pasky@suse.cz> [2008.11.20.1120 +0100]:
> The point of -b is to export only the specified branches, assuming you
> already exported the dependencies before. If you just want to export a
> branch with all its dependencies, why not just switch to it and call
> plain tg export?
Ah, I see. I think then I probably failed to communicate what I had
in mind with -b, which was mainly to avoid use of a temporary
branch where to collapse all commits before creating a series.
I don't see the point of being able to export patches into a quilt
series without their dependencies. If needed, one could use tg-patch
for that. The only difference between tg-export -b and tg-patch is
that the former can do multiple patches in one go, and it writes
a series file. Since that series is not guaranteed to be applicable,
I think one could just not bother.
Thinking about it a bit more, I think tg-export should be modified
such that it can always take -b/--branches, which defaults to the
current branch. No matter what the driver, it always prepends the
dependencies to the list. Then, the list is passed to the export
driver. 'collapse' creates a branch as it does right now, and
'quilt' creates a series as it does right now.
I have most of this implemented in a branch which I'll gladly
publish as soon as I figured out some remaining corner cases.
--
.''`. martin f. krafft <madduck@debian.org>
: :' : proud Debian developer, author, administrator, and user
`. `'` http://people.debian.org/~madduck - http://debiansystem.info
`- Debian - when you have better things to do than fixing systems
"zum christentum wird man nicht geboren,
man muß dazu nur krank genug sein."
- friedrich nietzsche
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: git and mtime
From: Johannes Schindelin @ 2008-11-20 10:35 UTC (permalink / raw)
To: Christian MICHON; +Cc: Roger Leigh, git
In-Reply-To: <46d6db660811190818r3aa2a392pda9106ac4a579cf0@mail.gmail.com>
Hi,
On Wed, 19 Nov 2008, Christian MICHON wrote:
> On Wed, Nov 19, 2008 at 12:37 PM, Roger Leigh <rleigh@codelibre.net> wrote:
> > Would it be possible for git to store the mtime of files in the tree?
> >
> > This would make it possible to do this type of work in git, since it's
> > currently a bit random as to whether it works or not. This only
> > started when I upgraded to an amd64 architecture from powerpc32, I
> > guess it's maybe using high-resolution timestamps.
> >
>
> beside the obvious answer it comes back often as a request, it is
> possible in theory to create a shell script which, for each file present
> in the sandbox in the current branch, would find the mtime of the last
> commit on that file (quite an expensive operation) and apply it.
>
> I had a need for this once, then lost interest since using git as it is
> is so much better than trying to mimic behaviour of old scm tools and
> makefiles.
I had a need like this, too, and solved it by teaching the build process
to fall back to generated files if the tool to generate them was not
available.
Ciao,
Dscho
^ permalink raw reply
* Re: git and mtime
From: Johannes Schindelin @ 2008-11-20 10:34 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Arafangion, Roger Leigh, git
In-Reply-To: <vpqhc63zrz2.fsf@bauges.imag.fr>
Hi,
On Wed, 19 Nov 2008, Matthieu Moy wrote:
> Arafangion <thestar@fussycoder.id.au> writes:
>
> > You should probably fix your build script,
>
> ccache should help:
Only if you _allow_ the problem that makes ccache necessary. Which we
don't.
Ciao,
Dscho
P.S.: reminds me -- once again -- of the complicator's glove.
^ permalink raw reply
* Re: Git commit won't add an untracked file given on the command line
From: David Aguilar @ 2008-11-20 10:18 UTC (permalink / raw)
To: Mark Burton; +Cc: git
In-Reply-To: <20081119095452.3018d2de@crow>
On 0, Mark Burton <markb@ordern.com> wrote:
>
> Hi,
>
> Feature request for the git gui people:
>
> It would be nice if git gui was able to stage a highlighted region
> rather than either the whole hunk or just the line under the cursor
> as I believe it behaves now. I might be wrong but I don't think it
> can do that at the moment. I think that would be useful because
> although it's a step forward to be able to stage individual lines in
> a hunk, it can be laborious if you want to pick out more than just a
> couple of lines.
>
> Cheers,
>
> Mark
git-cola can do that.
http://cola.tuxfamily.org/
--
David
^ permalink raw reply
* Re: [TopGit PATCH] Use the topological order when exporting explicitly listed branches.
From: Petr Baudis @ 2008-11-20 10:20 UTC (permalink / raw)
To: martin f. krafft; +Cc: git, Niko Tyni
In-Reply-To: <1227173902-21180-1-git-send-email-madduck@debian.org>
On Thu, Nov 20, 2008 at 10:38:22AM +0100, martin f. krafft wrote:
> From: Niko Tyni <ntyni@debian.org>
>
> When exporting explicitly listed branches (tg export -b), the branch
> dependencies were not taken into account.
>
> Signed-off-by: martin f. krafft <madduck@debian.org>
> Tested-by: martin f. krafft <madduck@debian.org>
> ---
> Arguably, lines 178:189 need to be refactored due to the code duplication, but
> the patch does what it should for now.
The point of -b is to export only the specified branches, assuming you
already exported the dependencies before. If you just want to export a
branch with all its dependencies, why not just switch to it and call
plain tg export?
--
Petr "Pasky" Baudis
People who take cold baths never have rheumatism, but they have
cold baths.
^ 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