* Re: git gc - out of memory
From: Alejandro Riveira @ 2009-11-15 14:44 UTC (permalink / raw)
To: git
In-Reply-To: <df1390cc0911141126w1a0c5691p83885053a73f829@mail.gmail.com>
El Sat, 14 Nov 2009 20:26:00 +0100, Simon Strandgaard escribió:
> My bare repository is on an OpenBSD machine. I was unaware of the
> importance of git gc until today after investigating a problem with "git
> pull". So there hasn't been run git gc on the repository ever.
>
> The biggest file in the repository is a 45 mb file. The repository size
> is near 2 gb.
>
> What can I do?
run « git repack -adf --window=memory » on the repo where memory is
escaled apropiately for your machine ?
See « git help repack »
Regards;
^ permalink raw reply
* Re: Question about "git pull --rebase"
From: Francis Moreau @ 2009-11-15 14:34 UTC (permalink / raw)
To: Johan 't Hart; +Cc: git
In-Reply-To: <4AFF3D4D.7000308@gmail.com>
Johan 't Hart <johanthart@gmail.com> writes:
> Francis Moreau schreef:
>> hello,
>>
>> Let's say I'm on a branch called 'foo'.
>>
>> I tried to rebase this branch by using 'git pull --rebase'.
>>
>> I first tried the following command:
>>
>> $ git pull --rebase origin master:foo
>> remote: Counting objects: 5, done.
>> remote: Total 3 (delta 0), reused 0 (delta 0)
>> Unpacking objects: 100% (3/3), done.
>> From /dev/shm/git/A
>> ! [rejected] master -> foo (non fast forward)
>
> When using a refspec, you usually mean to update a remote tracking
> branch, like refs/remotes/origin/master. Internally the refspec
> parameter is passed to git fetch, which fast-forwards your local
> tracking branch to match the remote branch.
>
> With this command, you make git clear you want to fast-forward your
> branch refs/foo to match the remotes master branch, and then rebase
> your current branch on that foo branch.
>
> Foo probably is also your current branch. So what you probably want is
> to fetch the remotes master branch and rebase your current branch foo
> on it. You could do it this way:
>
>> Then I tried:
>>
>> $ git pull --rebase origin master
>>
>> which worked.
>
> This does not update any remote tracking branches, but it will rebase
> your foo branch on the remote master branch (which is what you want)
> It could also be done with:
>
> git pull --rebase origin master:origin/master
>
> This will also update your remote tracking branch
> refs/remotes/origin/master to match the master branch on the remote
> repo. Your foo branch will then be rebased onto it.
>
>>
>> Reading the man git-pull I would assume the 2 commands are equivalent
>> but obviously they're not.
>>
>> So the question is: why ?
>
> So, thats why :) They're not the same. Many words... Hope you
> understand... I hope I understood it well too..?
>
Looks like you did :)
I've been somehow confused by the git-pull man page, which says:
A parameter <ref> without a colon is equivalent to <ref>: when
pulling/fetching, so it merges <ref> into the current branch without
storing the remote branch anywhere locally
So I thought that both of the commands were equivalent for 'git pull
--rebase'.
Thanks for the explanation.
--
Francis
^ permalink raw reply
* Re: Question about "git pull --rebase"
From: Francis Moreau @ 2009-11-15 14:31 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git
In-Reply-To: <20091115081649.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Quoting Francis Moreau <francis.moro@gmail.com>
>
>> Let's say I'm on a branch called 'foo'.
>> ...
>> $ git pull --rebase origin master:foo
>
> With this command line, you are asking:
>
> 1) Please first fetch master from origin and update the local
> 'foo' with it, but please fail if this doesn't fast forward;
>
> 2) If the first step was successful, please rebase the current
> branch on top of that commit.
>
> If your current branch 'foo' doesn't fast forward, the first step
> should fail, and that is the failure you saw.
>
> Your request doesn't make any sense. The first step would succeed
> only when your 'foo' doesn't have anything to replay on 'master'
> from origin, and the second step either isn't executed (when 'foo'
> has some commits), or it doesn't do anything (when 'foo' doesn't
> have any commit).
>
>> $ git pull --rebase origin master
>
> With this command line, you are asking:
>
> 1) Please first fetch master from origin, but don't store it anywhere;
>
> 2) Then on top of that fetched commit, please rebase the current branch.
>
> That is a much saner request.
I see thanks.
Actually I've been confused by the following part of the git-pull man
page:
A parameter <ref> without a colon is equivalent to <ref>: when
pulling/fetching, so it merges <ref> into the current branch without
storing the remote branch anywhere locally
So it sounds that both of the pull commands were equivalent whereas
they're not.
--
Francis
^ permalink raw reply
* Re: [PATCH] Check the format of more printf-type functions
From: Alex Riesen @ 2009-11-15 14:17 UTC (permalink / raw)
To: Tarmigan Casebolt; +Cc: Junio C Hamano, git, Miklos Vajna
In-Reply-To: <1258234393-5093-1-git-send-email-tarmigan+git@gmail.com>
On Sat, Nov 14, 2009 at 22:33, Tarmigan Casebolt <tarmigan+git@gmail.com> wrote:
> We already have these checks in many printf-type functions that have
> prototypes which are in header files. Add these same checks to some
> more prototypes in header functions and to static functions in .c
> files.
>
> cc: Miklos Vajna <vmiklos@frugalware.org>
> Signed-off-by: Tarmigan Casebolt <tarmigan+git@gmail.com>
> ---
>
> Junio, please consider this for next. It will hopefully catch some bugs like
> the Content-Length one in http-backend.c.
>
> One extra warning is
> CC merge-recursive.o
> merge-recursive.c: In function ‘write_tree_from_memory’:
> merge-recursive.c:218: warning: field precision should have type ‘int’, but argument 5 has type ‘size_t’
>
> A fix that might work in practice (because pathnames won't be longer than
> an int?) is:
> --- a/merge-recursive.c
> +++ b/merge-recursive.c
> @@ -215,7 +215,9 @@ struct tree *write_tree_from_memory(struct merge_options *o)
> for (i = 0; i < active_nr; i++) {
> struct cache_entry *ce = active_cache[i];
> if (ce_stage(ce))
> - output(o, 0, "%d %.*s", ce_stage(ce), ce_namelen(ce), ce->name);
> + output(o, 0, "%d %.*s", ce_stage(ce), (int)ce_namelen(ce), ce->name);
It'll do. The message is purely diagnostics.
> + if (ce_namelen(ce) > INT_MAX)
> + die("A filename was too long");
That's overdoing it a little.
^ permalink raw reply
* Re: GNU patch: new 2.6 release
From: Björn Gustavsson @ 2009-11-15 14:02 UTC (permalink / raw)
To: Thomas Rast; +Cc: Andreas Gruenbacher, git, bug-patch
In-Reply-To: <200911151437.56228.trast@student.ethz.ch>
2009/11/15 Thomas Rast <trast@student.ethz.ch>:
> Björn Gustavsson wrote:
>> That would be very useful in a workflow when you work in git (and have some
>> binary files in the repository), but need to commit your finished work
>> into another VCS (such as Clearcase).
>
> You can simply use git-apply in this case, it also works outside a git
> repository.
Thanks, I didn't know that. I just assumed that it used the index
or generally depended on being run in a git repository.
The patch program does one thing that git-apply does not --
it can check out the files to be patched (for systems that need
it, such as Clearcase or RCS). I will have to handle that myself
(but that is not hard, I can either use 'git diff --name-only' to find
out the file names or extract the names from the patch itself).
/Björn
--
Björn Gustavsson, Erlang/OTP, Ericsson AB
^ permalink raw reply
* Re: GNU patch: new 2.6 release
From: Thomas Rast @ 2009-11-15 13:37 UTC (permalink / raw)
To: Björn Gustavsson; +Cc: Andreas Gruenbacher, git
In-Reply-To: <6672d0160911140045h70243c12w3c56ad925dc70d39@mail.gmail.com>
Björn Gustavsson wrote:
> Do you have any plans to support git-style binary patches?
>
> That would be very useful in a workflow when you work in git (and have some
> binary files in the repository), but need to commit your finished work
> into another VCS (such as Clearcase).
You can simply use git-apply in this case, it also works outside a git
repository.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: git svn fetch loses data
From: Thomas Rast @ 2009-11-15 13:33 UTC (permalink / raw)
To: Victor Engmark; +Cc: Johan 't Hart, Sverre Rabbelier, git
In-Reply-To: <7d4f41f50911150156x4cc07dcch977c90e5bd134d17@mail.gmail.com>
Victor Engmark wrote:
> On Sun, Nov 15, 2009 at 12:35 AM, Johan 't Hart <johanthart@gmail.com> wrote:
> > Sverre Rabbelier schreef:
> >
> > > $ git rebase git-svn
> >
> > Why not just
> > $ git svn rebase
>
> What is the difference between the two?
'git svn rebase' magically[*] picks the right remote branch to rebase
against, and also first talks to the network to update said branch.
[*] actually it looks at the first git-svn-id line found in git log
--first-parent.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* [RFC] format-patch: Ensure that author and commit time are not lost
From: Björn Gustavsson @ 2009-11-15 13:25 UTC (permalink / raw)
To: git
'git format-patch' encodes the author of the commit in the From:
header and the time of the commit in the Date: header.
Depending on how the email is sent, however, those headers can be
lost before the email reaches its destination.
Therefore, if the sender of the email (i.e. the configuration
options user.name and user.email) are different from the author
of a commit, insert From: and Date: headers at the beginning of
the body of the commit message.
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
---
The code works, but is not appropriate for 'pu' because a fair
number of test cases will fail.
Some additional work is needed before this functionality can
be considered ready for 'pu'. Since I am rather busy at the
moment, I don't want to spend any more time on this unless I'll
get some indication that this functionality is useful for
someone else.
I would also want some input on whether it would be OK
to make this functionality unconditionally turned on so that
there will always From: and Date: headers in the commit
message.
I suspect that the answer is no, because there might be scripts
that parse the output of format-patch (perhaps to interface
with other source-code control systems).
Assuming that we need an option, should the default be to
produce the extra headers (to make sure that the original
author is not lost) or to not produce any extra headers
(for backwards compatibility)?
I suspect that the answer is that the default should be not
to generate any extra headers not to break any existing
scripts.
To implement an option is not difficult, but will need
changes in a fair number of source files in order to propagate
a boolean down to pretty_print_commit() (either as an
additional argument or possibly as an additional field
in the pretty_print_context struct).
pretty.c | 45 +++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/pretty.c b/pretty.c
index da15cf2..63268a1 100644
--- a/pretty.c
+++ b/pretty.c
@@ -916,6 +916,36 @@ char *reencode_commit_message(const struct commit *commit, const char **encoding
return logmsg_reencode(commit, encoding);
}
+static int sender_is_not_author(const char *message)
+{
+ const char **msg_p = &message;
+
+ for (;;) {
+ const char *line = *msg_p;
+ int linelen = get_one_line(*msg_p);
+ *msg_p += linelen;
+
+ /* Get out of here if the commit has no author. */
+ if (linelen <= 1)
+ return 0;
+
+ if (!memcmp(line, "author ", 7)) {
+ size_t name_len = strlen(git_default_name);
+ size_t email_len;
+ line += 7;
+ if (strncmp(line, git_default_name, name_len))
+ return 1;
+ line += name_len;
+ if (line[0] != ' ' || line[1] != '<')
+ return 1;
+ line += 2;
+ email_len = strlen(git_default_email);
+ return strncmp(line, git_default_email, email_len) ||
+ line[email_len] != '>';
+ }
+ }
+}
+
void pretty_print_commit(enum cmit_fmt fmt, const struct commit *commit,
struct strbuf *sb,
const struct pretty_print_context *context)
@@ -977,6 +1007,21 @@ void pretty_print_commit(enum cmit_fmt fmt, const struct commit *commit,
pp_title_line(fmt, &msg, sb, context->subject,
context->after_subject, encoding, need_8bit_cte);
+ /*
+ * If we are formatting an email and if the sender is different
+ * from the author of the commit, include the From: and Date:
+ * headers in the body of the commit message to make sure they
+ * are not lost.
+ */
+ if (fmt == CMIT_FMT_EMAIL) {
+ const char *p = reencoded ? reencoded : commit->buffer;
+ if (sender_is_not_author(commit->buffer)) {
+ pp_header(fmt, context->abbrev, context->date_mode, encoding,
+ commit, &p, sb);
+ strbuf_addch(sb, '\n');
+ }
+ }
+
beginning_of_body = sb->len;
if (fmt != CMIT_FMT_ONELINE)
pp_remainder(fmt, &msg, sb, indent);
--
1.6.5.2.186.geb718e
^ permalink raw reply related
* Re: P4 Sync problem
From: Pete Wyckoff @ 2009-11-15 13:00 UTC (permalink / raw)
To: Dmitry Smirnov; +Cc: git
In-Reply-To: <loom.20091111T131837-901@post.gmane.org>
divis1969@gmail.com wrote on Wed, 11 Nov 2009 12:39 +0000:
> i would propose to use both command-line arguments and a client spec
> to create a correct filter of what should be synced/cloned.
> BTW, it looks this script does not honor neither the order of paths
> in the spec (which can be important) nor mapping of the files to a local tree.
Here's a hack that I've been using to at least read the repo
locations out of the client spec. In the useclientspec case, it
takes all the info on paths from an existing p4 client spec. No
command line argument to git p4 sync. Hack out the test for P4ENV;
that is site specific for me.
We've moved away from using client specs with more than 1 line, so
I'm not interested in this patch anymore. Also, the long term
solution will probably be based on the foreign remote work that
Daniel and others are doing, so don't invest too much time in fixing
this up. That said, if there is a clean way to support both your
client specs and how Tor and others use them, it is worth putting
in now.
Good luck.
-- Pete
>From 55e8f6323894031119c755f2c3b3214c1c74b824 Mon Sep 17 00:00:00 2001
From: Pete Wyckoff <pw@padd.com>
Date: Wed, 26 Nov 2008 12:28:09 -0500
Subject: [PATCH] honor git client spec
Destination directories for parts of the depot are specified in the
client spec. Use them as given. Also read the entire client spec to
figure out what to do.
---
contrib/fast-import/git-p4 | 108 +++++++++++++++++++++++++++++++++++---------
1 files changed, 86 insertions(+), 22 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 1cecae2..28fa95f 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -456,6 +456,26 @@ def p4ChangesForPaths(depotPaths, changeRange):
changelist.sort()
return changelist
+#
+# Sort by number of slashes first: more specific at the top. Then
+# sort by alpha within a given number of path components.
+#
+def clientSortFunc(a, b):
+ asrc = a[0]
+ bsrc = b[0]
+ asrclen = asrc.count("/")
+ bsrclen = bsrc.count("/")
+ if asrclen > bsrclen:
+ return -1
+ elif asrclen < bsrclen:
+ return 1
+ elif asrc > bsrc:
+ return 1
+ elif asrc < bsrc:
+ return -1
+ else:
+ return 0
+
class Command:
def __init__(self):
self.usage = "usage: %prog [options]"
@@ -915,6 +935,11 @@ class P4Sync(Command):
return files
def stripRepoPath(self, path, prefixes):
+ if self.clientSpecDirs:
+ for val in self.clientSpecDirs:
+ if path.startswith(val[0]):
+ return val[1] + path[len(val[0]):]
+
if self.keepRepoPath:
prefixes = [re.sub("^(//[^/]+/).*", r'\1', prefixes[0])]
@@ -1038,7 +1063,7 @@ class P4Sync(Command):
includeFile = True
for val in self.clientSpecDirs:
if f['path'].startswith(val[0]):
- if val[1] <= 0:
+ if val[1] == '-':
includeFile = False
break
@@ -1115,6 +1140,7 @@ class P4Sync(Command):
self.gitStream.write("from %s\n" % parent)
self.streamP4Files(new_files)
+
self.gitStream.write("\n")
change = int(details["change"])
@@ -1476,24 +1502,54 @@ class P4Sync(Command):
def getClientSpec(self):
- specList = p4CmdList( "client -o" )
+ specList = p4CmdList("client -o")
temp = {}
+ client = ""
+ for entry in specList:
+ for k,v in entry.iteritems():
+ if k.startswith("Client"):
+ client = v
+ print "client is", client
+ if not client:
+ sys.stderr.write("no client found\n")
+ sys.exit(1)
+ client = "//" + client + "/"
for entry in specList:
for k,v in entry.iteritems():
if k.startswith("View"):
- if v.startswith('"'):
- start = 1
- else:
- start = 0
- index = v.find("...")
- v = v[start:index]
- if v.startswith("-"):
- v = v[1:]
- temp[v] = -len(v)
- else:
- temp[v] = len(v)
- self.clientSpecDirs = temp.items()
- self.clientSpecDirs.sort( lambda x, y: abs( y[1] ) - abs( x[1] ) )
+ if v.startswith('"'):
+ v = v[1:]
+ if v.endswith('"'):
+ v = v[:-1]
+ d = v.split(" ");
+ if len(d) != 2:
+ sys.stderr.write( \
+ "expecting two fields in view, got: %s\n" % v)
+ sys.exit(1)
+ if not d[0].endswith("..."):
+ sys.stderr.write(\
+ "expecting trailing ..., got: %s\n" % d[0])
+ sys.exit(1)
+ d[0] = d[0][:-3]
+ if not d[1].endswith("..."):
+ sys.stderr.write(\
+ "expecting trailing ..., got: %s\n" % d[1])
+ sys.exit(1)
+ d[1] = d[1][:-3]
+ if not d[1].startswith(client):
+ sys.stderr.write(\
+ "expecting dest to start with %s, got: %s\n" % \
+ (client, d[1]))
+ sys.exit(1)
+ d[1] = d[1][len(client):]
+ # negated items do not appear in tree
+ if d[0].startswith("-"):
+ d[0] = d[0][1:]
+ d[1] = ""
+ temp[d[0]] = d[1]
+
+ self.clientSpecDirs = temp.items()
+ self.clientSpecDirs.sort(clientSortFunc)
def run(self, args):
self.depotPaths = []
@@ -1755,7 +1811,7 @@ class P4Clone(P4Sync):
def __init__(self):
P4Sync.__init__(self)
self.description = "Creates a new git repository and imports from Perforce into it"
- self.usage = "usage: %prog [options] //depot/path[@revRange]"
+ self.usage = "usage: %prog [options] [//depot/path[@revRange]]"
self.options += [
optparse.make_option("--destination", dest="cloneDestination",
action='store', default=None,
@@ -1783,18 +1839,26 @@ class P4Clone(P4Sync):
return os.path.split(depotDir)[1]
def run(self, args):
- if len(args) < 1:
- return False
-
if self.keepRepoPath and not self.cloneDestination:
sys.stderr.write("Must specify destination for --keep-path\n")
sys.exit(1)
depotPaths = args
- if not self.cloneDestination and len(depotPaths) > 1:
- self.cloneDestination = depotPaths[-1]
- depotPaths = depotPaths[:-1]
+ if gitConfig("git-p4.useclientspec") == "true":
+ if not os.path.exists("P4ENV"):
+ sys.stderr.write("Must copy P4ENV file from a valid client\n")
+ sys.exit(1)
+ self.getClientSpec()
+ if not depotPaths:
+ depotPaths = [p[0] for p in self.clientSpecDirs]
+ else:
+ if not depotPaths:
+ sys.stderr.write("Must specify depot path if no client spec\n")
+ sys.exit(1)
+
+ if not self.cloneDestination:
+ self.cloneDestination = "."
self.cloneExclude = ["/"+p for p in self.cloneExclude]
for p in depotPaths:
--
1.6.2.5
^ permalink raw reply related
* Re: get git not to care about permissions
From: Thomas Rast @ 2009-11-15 12:31 UTC (permalink / raw)
To: Matt Schoen; +Cc: Jay Soffian, git, euguess
In-Reply-To: <3cf217d80911121344w7d1809ebs103eaa2ac19a03a6@mail.gmail.com>
Matt Schoen wrote:
> On Thu, Nov 12, 2009 at 11:10 AM, Thomas Rast <trast@student.ethz.ch> wrote:
> > It prints an absolute path, so the open() also accesses an absolute
> > path (though I don't know why it insists on that).
> >
> > But the above directory listing would indicate that you do not even
> > have permission to look inside your $(pwd) by absolute path...
>
> I'm pretty sure I can. How can I test this? I can ls all
> subdirectories within the path, and when I navigate to the path, I
> usually do it absolutely. After all, this is a network share, so I
> have to start with "/ad/eng/...". Although, this is curious. Some of
> the directories show "d---------" when I do ls -al. They were created
> by root in the same environment (forced 700), but I can still read
> their contents, and such.
What filesystem is this? Are there perhaps extended attributes
allowing access anyway? I'm not exactly an expert on unix permissions
but my local path_resolution(7) tells me it should not be possible to
cd beyond a directory where you have no 'x' permissions.
> Does open() strictly require the permissions you give it?
open(2) says the permissions are modified by the umask, so that
shouldn't be a problem.
Question for the people who know git better than me: Does that open()
require an absolute path?
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH] pull: refuse complete src:dst fetchspec arguments
From: Thomas Rast @ 2009-11-15 12:24 UTC (permalink / raw)
To: git
In-Reply-To: <d561e70f0aa802ceb96eba16d3bb2316134d69c8.1256062808.git.trast@student.ethz.ch>
Thomas Rast wrote:
> git-pull has historically accepted full fetchspecs, meaning that you
> could do
>
> git pull $repo A:B
>
> which would simultaneously fetch the remote branch A into the local
> branch B and merge B into HEAD. This got especially confusing if B
> was checked out. New users variously mistook pull for fetch or read
> that command as "merge the remote A into my B", neither of which is
> correct.
It gets worse. *Much* worse.
Yesterday on IRC I helped 'thrope' with the github pull requests
guide. This is a wiki page, but placed at a sufficiently prominent
URL to make it look like an authoritative guide to a new user.
http://github.com/guides/pull-requests
I have since replaced the part in question with one that is more in
line with what the tools actually do, but the bottom line of the old
version was basically
# You got a request to pull git://github.com/defunkt/grit.git master
# mojombo can add the defunkt repository as a remote source, create
# a new branch, and pull the defunkt repository contents into it
# like this:
$ git remote add -f defunkt git://github.com/defunkt/grit.git
$ git checkout -b defunkt/master # (1)
$ git pull defunkt master:4f0ea0c # (2)
# [...]
$ git commit # (3)
$ git checkout master
$ git merge defunkt/master # (4)
$ git push
Note that all but the first line and the numbers is literally
cut&pasted from the old version, which is still available at
http://github.com/guides/pull-requests/24
so you can see for yourself. Note that the lines (1) and (2) were
there even in version 3.
And as you can see, there are just so many things wrong with it:
(1) will actually create a new branch defunkt/master based on whatever
you happened to be on, making (4) merge something entirely different
than what the pull request was for.
(2) will pull defunkt's master into a local *branch* called 4f0ea0c
(in the guide this is actually the sha1 of defunkt's master, but who
knows), and then merge that into the local defunkt/master branch from
(1).
(3) shouldn't do anything at that point, but hell if I know how he got
the idea to commit there.
So this suggests several safety measures:
* Perhaps branch/checkout -b can refuse to create branches that
already exist with this exact name under remotes if that's the only
argument. I.e., in the above situation (1),
# refuse: remotes/defunkt/master exists
git checkout -b defunkt/master
git branch defunkt/master
# accept: obviously you're asking for trouble explicitly
git checkout -b defunkt/master defunkt/master
git branch defunkt/master defunkt/master
* Perhaps all branch-creating code could refuse to create branches
that have a name that is also a valid sha1 prefix of an existing
object? This would be fairly drastic if a user's language has many
words consisting only of [a-f], but on the other hand, the user can
hardly be helped by having something that looks like a sha1 resolve
to some *other* sha1.
* I ask you to reconsider this patch. For some reason, people read
things into pull with fetchspecs that are far from correct.
I haven't thought much about backwards compatibility yet, though, so
some of it may not be possible.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* [PATCH 2/2] Add gitk-git Hungarian translation
From: Laszlo Papp @ 2009-11-15 11:23 UTC (permalink / raw)
To: git; +Cc: paulus, Laszlo Papp
Signed-off-by: Laszlo Papp <djszapi@archlinux.us>
---
gitk-git/po/hu.po | 1151 +++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 1151 insertions(+), 0 deletions(-)
create mode 100755 gitk-git/po/hu.po
diff --git a/gitk-git/po/hu.po b/gitk-git/po/hu.po
new file mode 100755
index 0000000..d281e3c
--- /dev/null
+++ b/gitk-git/po/hu.po
@@ -0,0 +1,1151 @@
+# Translation of gitk to Hungarian.
+# Copyright (C) 2007 Paul Mackerras.
+# This file is distributed under the same license as the gitk package.
+#
+# Laszlo Papp <laszlo.papp@arhungary.hu>, 2009.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: git-gui\n"
+"Report-Msgid-Bugs-To: \n"
+"POT-Creation-Date: 2009-05-12 21:55+0200\n"
+"PO-Revision-Date: 2009-05-12 22:18+0200\n"
+"Last-Translator: Laszlo Papp <djszapi@archlinux.us>\n"
+"Language-Team: Hungarian\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#: gitk:113
+msgid "Couldn't get list of unmerged files:"
+msgstr "Nem sikerült letölteni az unmerged fájl listát:"
+
+#: gitk:268
+msgid "Error parsing revisions:"
+msgstr "Hiba történt értelmezés közben:"
+
+#: gitk:323
+msgid "Error executing --argscmd command:"
+msgstr "Hiba történt a végrehajtáskor --argscmd parancs:"
+
+#: gitk:336
+msgid "No files selected: --merge specified but no files are unmerged."
+msgstr "Nincsen fájl kiválasztva: --merge megadve, de egyetlen fájl sem unmerged."
+
+#: gitk:339
+msgid ""
+"No files selected: --merge specified but no unmerged files are within file "
+"limit."
+msgstr ""
+"Nincsen fájl kiválasztva: --merge megadva, de nincsenek unmerged fájlok a fájlon
+belül "
+"limit."
+
+#: gitk:361 gitk:508
+msgid "Error executing git log:"
+msgstr "Hiba történt a git log végrehajtása közben:"
+
+#: gitk:379 gitk:524
+msgid "Reading"
+msgstr "Olvasás"
+
+#: gitk:439 gitk:4061
+msgid "Reading commits..."
+msgstr "Commitok olvasása ..."
+
+#: gitk:442 gitk:1560 gitk:4064
+msgid "No commits selected"
+msgstr "Nincsen commit kiválasztva"
+
+#: gitk:1436
+msgid "Can't parse git log output:"
+msgstr "Nem lehet értelmezni a git log kimenetét:"
+
+#: gitk:1656
+msgid "No commit information available"
+msgstr "Nincsen elérhető commit információ"
+
+#: gitk:1791 gitk:1815 gitk:3854 gitk:8714 gitk:10250 gitk:10422
+msgid "OK"
+msgstr "OK"
+
+#: gitk:1817 gitk:3856 gitk:8311 gitk:8385 gitk:8495 gitk:8544 gitk:8716
+#: gitk:10251 gitk:10423
+msgid "Cancel"
+msgstr "Visszavonás"
+
+#: gitk:1917
+msgid "Update"
+msgstr "Frissités"
+
+#: gitk:1918
+msgid "Reload"
+msgstr "Újratöltés"
+
+#: gitk:1919
+msgid "Reread references"
+msgstr "Referenciák újraolvasása"
+
+#: gitk:1920
+msgid "List references"
+msgstr "Referenciák listázása"
+
+#: gitk:1922
+msgid "Start git gui"
+msgstr "Git gui indÃtása"
+
+#: gitk:1924
+msgid "Quit"
+msgstr "Kilépés"
+
+#: gitk:1916
+msgid "File"
+msgstr "Fájl"
+
+#: gitk:1928
+msgid "Preferences"
+msgstr "BeállÃtások"
+
+#: gitk:1927
+msgid "Edit"
+msgstr "Szerkesztés"
+
+#: gitk:1932
+msgid "New view..."
+msgstr "Új nézet ..."
+
+#: gitk:1933
+msgid "Edit view..."
+msgstr "Nézet szerkesztése ..."
+
+#: gitk:1934
+msgid "Delete view"
+msgstr "Nézet törlése"
+
+#: gitk:1936
+msgid "All files"
+msgstr "Minden fájl"
+
+#: gitk:1931 gitk:3666
+msgid "View"
+msgstr "Nézet"
+
+#: gitk:1941 gitk:1951 gitk:2650
+msgid "About gitk"
+msgstr "Gitk névjegy"
+
+#: gitk:1942 gitk:1956
+msgid "Key bindings"
+msgstr "Billentyűkombináció"
+
+#: gitk:1940 gitk:1955
+msgid "Help"
+msgstr "SegÃtség"
+
+#: gitk:2016
+msgid "SHA1 ID: "
+msgstr "SHA1 ID: "
+
+#: gitk:2047
+msgid "Row"
+msgstr "Sor"
+
+#: gitk:2078
+msgid "Find"
+msgstr "Keresés"
+
+#: gitk:2079
+msgid "next"
+msgstr "következő"
+
+#: gitk:2080
+msgid "prev"
+msgstr "előző"
+
+#: gitk:2081
+msgid "commit"
+msgstr "commit"
+
+#: gitk:2084 gitk:2086 gitk:4222 gitk:4245 gitk:4269 gitk:6210 gitk:6282
+#: gitk:6366
+msgid "containing:"
+msgstr "tartalmazás:"
+
+#: gitk:2087 gitk:3158 gitk:3163 gitk:4297
+msgid "touching paths:"
+msgstr "érintendő útvonalak:"
+
+#: gitk:2088 gitk:4302
+msgid "adding/removing string:"
+msgstr "string hozzáadása/törlése:"
+
+#: gitk:2097 gitk:2099
+msgid "Exact"
+msgstr "Pontos"
+
+#: gitk:2099 gitk:4377 gitk:6178
+msgid "IgnCase"
+msgstr "Kis/nagy betű nem számÃt"
+
+#: gitk:2099 gitk:4271 gitk:4375 gitk:6174
+msgid "Regexp"
+msgstr "Regexp"
+
+#: gitk:2101 gitk:2102 gitk:4396 gitk:4426 gitk:4433 gitk:6302 gitk:6370
+msgid "All fields"
+msgstr "Minden mező"
+
+#: gitk:2102 gitk:4394 gitk:4426 gitk:6241
+msgid "Headline"
+msgstr "FÅ‘cÃm"
+
+#: gitk:2103 gitk:4394 gitk:6241 gitk:6370 gitk:6804
+msgid "Comments"
+msgstr "Megjegyzések"
+
+#: gitk:2103 gitk:4394 gitk:4398 gitk:4433 gitk:6241 gitk:6739 gitk:7991
+#: gitk:8006
+msgid "Author"
+msgstr "Szerző"
+
+#: gitk:2103 gitk:4394 gitk:6241 gitk:6741
+msgid "Committer"
+msgstr "Commitoló"
+
+#: gitk:2132
+msgid "Search"
+msgstr "Keresés"
+
+#: gitk:2139
+msgid "Diff"
+msgstr "Diff"
+
+#: gitk:2141
+msgid "Old version"
+msgstr "Régi verzió"
+
+#: gitk:2143
+msgid "New version"
+msgstr "Új verzió"
+
+#: gitk:2145
+msgid "Lines of context"
+msgstr "Tartalmi sorok"
+
+#: gitk:2155
+msgid "Ignore space change"
+msgstr "Space váltás mellőzése"
+
+#: gitk:2213
+msgid "Patch"
+msgstr "Patch"
+
+#: gitk:2215
+msgid "Tree"
+msgstr "Tree"
+
+#: gitk:2359 gitk:2376
+msgid "Diff this -> selected"
+msgstr "Diff ezeket -> kiválasztott"
+
+#: gitk:2360 gitk:2377
+msgid "Diff selected -> this"
+msgstr "Diff kiválasztottakat -> ezt"
+
+#: gitk:2361 gitk:2378
+msgid "Make patch"
+msgstr "Patch készÃtése"
+
+#: gitk:2362 gitk:8369
+msgid "Create tag"
+msgstr "Tag készÃtése"
+
+#: gitk:2363 gitk:8475
+msgid "Write commit to file"
+msgstr "Commit fáljba Ãrása"
+
+#: gitk:2364 gitk:8532
+msgid "Create new branch"
+msgstr "Új branch készÃtése"
+
+#: gitk:2365
+msgid "Cherry-pick this commit"
+msgstr "Cherry-pick erre a commitra"
+
+#: gitk:2366
+msgid "Reset HEAD branch to here"
+msgstr "HEAD branch újraindÃtása ide"
+
+#: gitk:2367
+msgid "Mark this commit"
+msgstr "Ezen commit megjelölése"
+
+#: gitk:2368
+msgid "Return to mark"
+msgstr "Visszatérés a megjelöléshez"
+
+#: gitk:2369
+msgid "Find descendant of this and mark"
+msgstr "Találd meg ezen utódokat és jelöld meg"
+
+#: gitk:2370
+msgid "Compare with marked commit"
+msgstr "ÖsszehasonlÃtás a megjelölt commit-tal"
+
+#: gitk:2384
+msgid "Check out this branch"
+msgstr "Check out ezt a branchot"
+
+#: gitk:2385
+msgid "Remove this branch"
+msgstr "Töröld ezt a branch-ot"
+
+#: gitk:2392
+msgid "Highlight this too"
+msgstr "Emeld ki ezt is"
+
+#: gitk:2393
+msgid "Highlight this only"
+msgstr "Csak ezt emeld ki"
+
+#: gitk:2394
+msgid "External diff"
+msgstr "Külső diff"
+
+#: gitk:2395
+msgid "Blame parent commit"
+msgstr "Blame szülő kommitra"
+
+#: gitk:2402
+msgid "Show origin of this line"
+msgstr "Mutasd meg ennek a sornak az eredetét"
+
+#: gitk:2403
+msgid "Run git gui blame on this line"
+msgstr "Futtasd a git gui blame-t ezen a soron"
+
+#: gitk:2652
+msgid ""
+"\n"
+"Gitk - a commit viewer for git\n"
+"\n"
+"Copyright © 2005-2008 Paul Mackerras\n"
+"\n"
+"Use and redistribute under the terms of the GNU General Public License"
+msgstr ""
+"\n"
+"Gitk - commit nézegető a githez\n"
+"\n"
+"Szerzői jog © 2005-2008 Paul Mackerras\n"
+"\n"
+"Használd és terjeszd a GNU General Public License feltételei mellett "
+"Licensz"
+
+#: gitk:2660 gitk:2722 gitk:8897
+msgid "Close"
+msgstr "Bezárás"
+
+#: gitk:2679
+msgid "Gitk key bindings"
+msgstr "Gitk-billentyű hozzárendelés"
+
+#: gitk:2682
+msgid "Gitk key bindings:"
+msgstr "Gitk-billentyű hozzaárendelés:"
+
+#: gitk:2684
+#, tcl-format
+msgid "<%s-Q>\t\tQuit"
+msgstr "<%s-Q>\t\tKilépés"
+
+#: gitk:2685
+msgid "<Home>\t\tMove to first commit"
+msgstr "<Pos1>\t\tElső commithoz"
+
+#: gitk:2686
+msgid "<End>\t\tMove to last commit"
+msgstr "<Ende>\t\tUtolsó commithoz"
+
+#: gitk:2687
+msgid "<Up>, p, i\tMove up one commit"
+msgstr "<Hoch>, p, i\tEgy committal feljebb"
+
+#: gitk:2688
+msgid "<Down>, n, k\tMove down one commit"
+msgstr "<Runter>, n, k\tEgy committal lejjebb"
+
+#: gitk:2689
+msgid "<Left>, z, j\tGo back in history list"
+msgstr "<Links>, z, j\tVissza a history listába"
+
+#: gitk:2690
+msgid "<Right>, x, l\tGo forward in history list"
+msgstr "<Rechts>, x, l\tElőre a history listába"
+
+#: gitk:2691
+msgid "<PageUp>\tMove up one page in commit list"
+msgstr "<BildHoch>\tEgy lappal feljebb a commit listába"
+
+#: gitk:2692
+msgid "<PageDown>\tMove down one page in commit list"
+msgstr "<BildRunter>\tEgy lappal lejjebb a commit listába"
+
+#: gitk:2693
+#, tcl-format
+msgid "<%s-Home>\tScroll to top of commit list"
+msgstr "<%s-Pos1>\tGörgetés a commit lista tetejéhez"
+
+#: gitk:2694
+#, tcl-format
+msgid "<%s-End>\tScroll to bottom of commit list"
+msgstr "<%s-Ende>\tGörgetés a commit lista aljához"
+
+#: gitk:2695
+#, tcl-format
+msgid "<%s-Up>\tScroll commit list up one line"
+msgstr "<%s-Hoch>\tEgy sorral feljebb görgetés a commit listában"
+
+#: gitk:2696
+#, tcl-format
+msgid "<%s-Down>\tScroll commit list down one line"
+msgstr "<%s-Runter>\tEgy sorral lejjebb görgetés a commit listában"
+
+#: gitk:2697
+#, tcl-format
+msgid "<%s-PageUp>\tScroll commit list up one page"
+msgstr "<%s-BildHoch>\tEgy lappal feljebb görgetés a commit listában"
+
+#: gitk:2698
+#, tcl-format
+msgid "<%s-PageDown>\tScroll commit list down one page"
+msgstr "<%s-BildRunter>\tEgy sorral lejjebb görgetés a commit listában"
+
+#: gitk:2699
+msgid "<Shift-Up>\tFind backwards (upwards, later commits)"
+msgstr "<Umschalt-Hoch>\tKeresés visszafele (felfele, utolsó commitok)"
+
+#: gitk:2700
+msgid "<Shift-Down>\tFind forwards (downwards, earlier commits)"
+msgstr "<Umschalt-Runter>\tKeresés előre (lefelé; korábbi commitok)"
+
+#: gitk:2701
+msgid "<Delete>, b\tScroll diff view up one page"
+msgstr "<Entf>, b\t\tEgy lappal feljebb görgetés a diff nézetben"
+
+#: gitk:2702
+msgid "<Backspace>\tScroll diff view up one page"
+msgstr "<Löschtaste>\tEgy lappal feljebb görgetés a diff nézetben"
+
+#: gitk:2703
+msgid "<Space>\t\tScroll diff view down one page"
+msgstr "<Leertaste>\tEgy lappal lejjebb görgetés a diff nézetben"
+
+#: gitk:2704
+msgid "u\t\tScroll diff view up 18 lines"
+msgstr "u\t\t18 sorral felfelé görgetés diff nézetben"
+
+#: gitk:2705
+msgid "d\t\tScroll diff view down 18 lines"
+msgstr "d\t\t18 sorral lejjebb görgetés a diff nézetben"
+
+#: gitk:2706
+#, tcl-format
+msgid "<%s-F>\t\tFind"
+msgstr "<%s-F>\t\tKeresés"
+
+#: gitk:2707
+#, tcl-format
+msgid "<%s-G>\t\tMove to next find hit"
+msgstr "<%s-G>\t\tKövetkező találathoz"
+
+#: gitk:2708
+msgid "<Return>\tMove to next find hit"
+msgstr "<Eingabetaste>\tKövetkező találathoz"
+
+#: gitk:2709
+msgid "/\t\tFocus the search box"
+msgstr "/\t\tLépj a keresési mezőre"
+
+#: gitk:2710
+msgid "?\t\tMove to previous find hit"
+msgstr "?\t\tElőző találathoz"
+
+#: gitk:2711
+msgid "f\t\tScroll diff view to next file"
+msgstr "f\t\tKövetkező fájlra görgetés diff nézetben"
+
+#: gitk:2712
+#, tcl-format
+msgid "<%s-S>\t\tSearch for next hit in diff view"
+msgstr "<%s-S>\t\tKövetkező találatra keresés diff nézetben"
+
+#: gitk:2713
+#, tcl-format
+msgid "<%s-R>\t\tSearch for previous hit in diff view"
+msgstr "<%s-R>\t\tElőző találatra keresés diff nézetben"
+
+#: gitk:2714
+#, tcl-format
+msgid "<%s-KP+>\tIncrease font size"
+msgstr "<%s-Nummerblock-Plus>\tBetűméret növelése"
+
+#: gitk:2715
+#, tcl-format
+msgid "<%s-plus>\tIncrease font size"
+msgstr "<%s-Plus>\tBetűméret növelése"
+
+#: gitk:2716
+#, tcl-format
+msgid "<%s-KP->\tDecrease font size"
+msgstr "<%s-Nummernblock-Minus> Betűméret csökkentése"
+
+#: gitk:2717
+#, tcl-format
+msgid "<%s-minus>\tDecrease font size"
+msgstr "<%s-Minus>\tBetűméret csökkentése"
+
+#: gitk:2718
+msgid "<F5>\t\tUpdate"
+msgstr "<F5>\t\tFrissÃtés"
+
+#: gitk:3173
+#, tcl-format
+msgid "Error getting \"%s\" from %s:"
+msgstr "Hiba történt \"%s\" letöltése közben %s-ről:"
+
+#: gitk:3230 gitk:3239
+#, tcl-format
+msgid "Error creating temporary directory %s:"
+msgstr "Hiba történt az ideiglenes könyvtár létrehozása közben %s:"
+
+#: gitk:3251
+msgid "command failed:"
+msgstr "parancs hiba:"
+
+#: gitk:3397
+msgid "No such commit"
+msgstr "Nincs ilyen commit"
+
+#: gitk:3411
+msgid "git gui blame: command failed:"
+msgstr "git gui blame: parancs hiba:"
+
+#: gitk:3442
+#, tcl-format
+msgid "Couldn't read merge head: %s"
+msgstr "Nem sikerült a Merge head olvasása: %s"
+
+#: gitk:3450
+#, tcl-format
+msgid "Error reading index: %s"
+msgstr "Hiba történt az index olvasása közben: %s"
+
+#: gitk:3475
+#, tcl-format
+msgid "Couldn't start git blame: %s"
+msgstr "Nem sikerült a git blame indÃtása: %s"
+
+#: gitk:3478 gitk:6209
+msgid "Searching"
+msgstr "Keresés"
+
+#: gitk:3510
+#, tcl-format
+msgid "Error running git blame: %s"
+msgstr "Hiba történt a git blame futtatása közben: %s"
+
+#: gitk:3538
+#, tcl-format
+msgid "That line comes from commit %s, which is not in this view"
+msgstr ""
+"A %s commitból származik az a sor, amelyik nem található ebben a nézetben"
+
+#: gitk:3552
+msgid "External diff viewer failed:"
+msgstr "Külső diff nézegető hiba:"
+
+#: gitk:3670
+msgid "Gitk view definition"
+msgstr "Gitk nézet meghatározása"
+
+#: gitk:3674
+msgid "Remember this view"
+msgstr "Maradj ennél a nézetnél"
+
+#: gitk:3675
+msgid "Commits to include (arguments to git log):"
+msgstr "Beleértendő commitok (Argumentok a git log-hoz):"
+
+#: gitk:3676
+msgid "Use all refs"
+msgstr "Használd az összes referenciát"
+
+#: gitk:3677
+msgid "Strictly sort by date"
+msgstr "Szigorú rendezás dátum alapján"
+
+#: gitk:3678
+msgid "Mark branch sides"
+msgstr "Jelölje meg az ágakat"
+
+#: gitk:3679
+msgid "Since date:"
+msgstr "Ettől:"
+
+#: gitk:3680
+msgid "Until date:"
+msgstr "Eddig:"
+
+#: gitk:3681
+msgid "Max count:"
+msgstr "Max. szám:"
+
+#: gitk:3682
+msgid "Skip:"
+msgstr "Kihagy:"
+
+#: gitk:3683
+msgid "Limit to first parent"
+msgstr "Korlátozás az első szülőre"
+
+#: gitk:3684
+msgid "Command to generate more commits to include:"
+msgstr "Parancs több tartalmazó commit generálására:"
+
+#: gitk:3780
+msgid "Gitk: edit view"
+msgstr "Gitk: szerkesztés nézet"
+
+#: gitk:3793
+msgid "Name"
+msgstr "Név"
+
+#: gitk:3841
+msgid "Enter files and directories to include, one per line:"
+msgstr "Fájlok és könyvtárak bejegyzése amiket tartalmaz, soronként:"
+
+#: gitk:3855
+msgid "Apply (F5)"
+msgstr "Alkalmaz (F5)"
+
+#: gitk:3893
+msgid "Error in commit selection arguments:"
+msgstr "Hiba történt a commit argumentumok kiválasztása közben:"
+
+#: gitk:3946 gitk:3998 gitk:4446 gitk:4460 gitk:5721 gitk:11114 gitk:11115
+msgid "None"
+msgstr "Keine"
+
+#: gitk:4394 gitk:6241 gitk:7993 gitk:8008
+msgid "Date"
+msgstr "Dátum"
+
+#: gitk:4394 gitk:6241
+msgid "CDate"
+msgstr "Dátum"
+
+#: gitk:4543 gitk:4548
+msgid "Descendant"
+msgstr "Leszármazott"
+
+#: gitk:4544
+msgid "Not descendant"
+msgstr "Nem leszármazott"
+
+#: gitk:4551 gitk:4556
+msgid "Ancestor"
+msgstr "Előd"
+
+#: gitk:4552
+msgid "Not ancestor"
+msgstr "Nem előd"
+
+#: gitk:4842
+msgid "Local changes checked in to index but not committed"
+msgstr "Lokális változtatások, melyek be vannak téve az indexbe, de még
+nincsenek commitolva"
+
+#: gitk:4878
+msgid "Local uncommitted changes, not checked in to index"
+msgstr "Lokális nem commitolt változások, nincsenek betéve az indexbe"
+
+#: gitk:6559
+msgid "many"
+msgstr "sok"
+
+#: gitk:6743
+msgid "Tags:"
+msgstr "Tagek:"
+
+#: gitk:6760 gitk:6766 gitk:7986
+msgid "Parent"
+msgstr "Eltern"
+
+#: gitk:6771
+msgid "Child"
+msgstr "Gyerek"
+
+#: gitk:6780
+msgid "Branch"
+msgstr "Ãg"
+
+#: gitk:6783
+msgid "Follows"
+msgstr "Következők"
+
+#: gitk:6786
+msgid "Precedes"
+msgstr "Megelőzők"
+
+#: gitk:7279
+#, tcl-format
+msgid "Error getting diffs: %s"
+msgstr "Hiba történt a diff-ek letöltése közben: %s"
+
+#: gitk:7819
+msgid "Goto:"
+msgstr "Menj:"
+
+#: gitk:7821
+msgid "SHA1 ID:"
+msgstr "SHA1 ID:"
+
+#: gitk:7840
+#, tcl-format
+msgid "Short SHA1 id %s is ambiguous"
+msgstr "Rövid SHA1 id %s félreérthető"
+
+#: gitk:7852
+#, tcl-format
+msgid "SHA1 id %s is not known"
+msgstr "SHA1 id %s nem ismert"
+
+#: gitk:7854
+#, tcl-format
+msgid "Tag/Head %s is not known"
+msgstr "Tag/Head %s nem ismert"
+
+#: gitk:7996
+msgid "Children"
+msgstr "Gyerekek"
+
+#: gitk:8053
+#, tcl-format
+msgid "Reset %s branch to here"
+msgstr "ÃllÃtsd vissza a %s branch-ot ide"
+
+#: gitk:8055
+msgid "Detached head: can't reset"
+msgstr "ElkülönÃtett head: nem lehet visszaállÃtani"
+
+#: gitk:8164 gitk:8170
+msgid "Skipping merge commit "
+msgstr "Merge commit kihagyása "
+
+#: gitk:8179 gitk:8184
+msgid "Error getting patch ID for "
+msgstr "Hiba történt a patch ID megszerzése közben a következőnél "
+
+#: gitk:8180 gitk:8185
+msgid " - stopping\n"
+msgstr " - abbahagyás\n"
+
+#: gitk:8190 gitk:8193 gitk:8201 gitk:8211 gitk:8220
+msgid "Commit "
+msgstr "Commit "
+
+#: gitk:8194
+msgid ""
+" is the same patch as\n"
+" "
+msgstr ""
+" Ugyanaz a patch mint\n"
+" "
+
+#: gitk:8202
+msgid ""
+" differs from\n"
+" "
+msgstr ""
+" különbözik innentől\n"
+" "
+
+#: gitk:8204
+msgid "- stopping\n"
+msgstr "- abbahagyás.\n"
+
+#: gitk:8212 gitk:8221
+#, tcl-format
+msgid " has %s children - stopping\n"
+msgstr " %s gyereke van. abbahagyás\n"
+
+#: gitk:8252
+msgid "Top"
+msgstr "Teteje"
+
+#: gitk:8253
+msgid "From"
+msgstr "Innen"
+
+#: gitk:8258
+msgid "To"
+msgstr "Ide"
+
+#: gitk:8282
+msgid "Generate patch"
+msgstr "Patch generálása"
+
+#: gitk:8284
+msgid "From:"
+msgstr "Innen:"
+
+#: gitk:8293
+msgid "To:"
+msgstr "Ide:"
+
+#: gitk:8302
+msgid "Reverse"
+msgstr "Visszafele"
+
+#: gitk:8304 gitk:8489
+msgid "Output file:"
+msgstr "Kimeneti fájl:"
+
+#: gitk:8310
+msgid "Generate"
+msgstr "Generálás"
+
+#: gitk:8348
+msgid "Error creating patch:"
+msgstr "Hiba törtét a patch készÃtése közben:"
+
+#: gitk:8371 gitk:8477 gitk:8534
+msgid "ID:"
+msgstr "ID:"
+
+#: gitk:8380
+msgid "Tag name:"
+msgstr "Tag név:"
+
+#: gitk:8384 gitk:8543
+msgid "Create"
+msgstr "Létrehozás"
+
+#: gitk:8401
+msgid "No tag name specified"
+msgstr "A tag neve nincsen megadva"
+
+#: gitk:8405
+#, tcl-format
+msgid "Tag \"%s\" already exists"
+msgstr "%s Tag már létezik"
+
+#: gitk:8411
+msgid "Error creating tag:"
+msgstr "Hiba történt a tag létrehozása közben:"
+
+#: gitk:8486
+msgid "Command:"
+msgstr "Parancs:"
+
+#: gitk:8494
+msgid "Write"
+msgstr "Ãrás"
+
+#: gitk:8512
+msgid "Error writing commit:"
+msgstr "Hiba történt a commit Ãrása közben:"
+
+#: gitk:8539
+msgid "Name:"
+msgstr "Név:"
+
+#: gitk:8562
+msgid "Please specify a name for the new branch"
+msgstr "Kérem adja meg a nevét az új branchhoz"
+
+#: gitk:8567
+#, tcl-format
+msgid "Branch '%s' already exists. Overwrite?"
+msgstr "%s branch már létezik. FelülÃrja?"
+
+#: gitk:8633
+#, tcl-format
+msgid "Commit %s is already included in branch %s -- really re-apply it?"
+msgstr ""
+"%s commit már benne van a %s branchban -- biztos hogy újra csinálja ?"
+"eintragen?"
+
+#: gitk:8638
+msgid "Cherry-picking"
+msgstr "Cherry-picking"
+
+#: gitk:8647
+#, tcl-format
+msgid ""
+"Cherry-pick failed because of local changes to file '%s'.\n"
+"Please commit, reset or stash your changes and try again."
+msgstr ""
+"Cherry-pick hiba történt lokális váltotások miatt a '%s' fájlban.\n"
+"Kérem commitolja, indÃtsa újra vagy rejtse el a változtatásait és próbálja újra."
+
+#: gitk:8653
+msgid ""
+"Cherry-pick failed because of merge conflict.\n"
+"Do you wish to run git citool to resolve it?"
+msgstr ""
+"Cherry-pick hiba történt merge konfliktus miatt.\n"
+"KÃvánja futtatni a git citool-t a probléma megoldásához?"
+
+#: gitk:8669
+msgid "No changes committed"
+msgstr "Nincsen változás commitolva"
+
+#: gitk:8695
+msgid "Confirm reset"
+msgstr "ÚjraindÃtás megerÅ‘sÃtése"
+
+#: gitk:8697
+#, tcl-format
+msgid "Reset branch %s to %s?"
+msgstr "ÚjraindÃtja a %s branchot %s-ig?"
+
+#: gitk:8701
+msgid "Reset type:"
+msgstr "ÚjraindÃtás tÃpusa:"
+
+#: gitk:8705
+msgid "Soft: Leave working tree and index untouched"
+msgstr "Soft: Hagyd a working tree-t és az indexet érintetlenül"
+
+#: gitk:8708
+msgid "Mixed: Leave working tree untouched, reset index"
+msgstr ""
+"Kevert: Hagyd a working tree-t érintetlenül, töröld az indexet"
+
+#: gitk:8711
+msgid ""
+"Hard: Reset working tree and index\n"
+"(discard ALL local changes)"
+msgstr ""
+"Hard: IndÃtsd újra a working tree-t és az indexet\n"
+"(MINDEN lokális változás eldobása)"
+
+#: gitk:8728
+msgid "Resetting"
+msgstr "ÚjraindÃtás"
+
+#: gitk:8785
+msgid "Checking out"
+msgstr "Kivesz"
+
+#: gitk:8838
+msgid "Cannot delete the currently checked-out branch"
+msgstr ""
+"Nem lehet a jelenleg kivett branch-ot törölni"
+
+#: gitk:8844
+#, tcl-format
+msgid ""
+"The commits on branch %s aren't on any other branch.\n"
+"Really delete branch %s?"
+msgstr ""
+"A %s branchon található commit nem található meg semelyik másik branchon.\n"
+"Tényleg törli a %s branchot?"
+
+#: gitk:8875
+#, tcl-format
+msgid "Tags and heads: %s"
+msgstr "Tagek és headek: %s"
+
+#: gitk:8890
+msgid "Filter"
+msgstr "Szűrő"
+
+#: gitk:9185
+msgid ""
+"Error reading commit topology information; branch and preceding/following "
+"tag information will be incomplete."
+msgstr ""
+"Hiba történt a commit topológiai információ olvasása közben; branch és"
+"a megelőző/következő információ nem lesz teljes."
+
+#: gitk:10171
+msgid "Tag"
+msgstr "Tag"
+
+#: gitk:10171
+msgid "Id"
+msgstr "Id"
+
+#: gitk:10219
+msgid "Gitk font chooser"
+msgstr "Gitk-betű kiválasztó"
+
+#: gitk:10236
+msgid "B"
+msgstr "F"
+
+#: gitk:10239
+msgid "I"
+msgstr "K"
+
+#: gitk:10334
+msgid "Gitk preferences"
+msgstr "Gitk beállÃtások"
+
+#: gitk:10336
+msgid "Commit list display options"
+msgstr "Commit lista kijelzési opciók"
+
+#: gitk:10339
+msgid "Maximum graph width (lines)"
+msgstr "Maximális grafikon szélesség (sorok)"
+
+#: gitk:10343
+#, tcl-format
+msgid "Maximum graph width (% of pane)"
+msgstr "Maximális grafikon szélesség (táble %-je)"
+
+#: gitk:10347
+msgid "Show local changes"
+msgstr "Mutasd a lokális változtatásokat"
+
+#: gitk:10350
+msgid "Auto-select SHA1"
+msgstr "SHA1 Automatikus kiválasztása"
+
+#: gitk:10354
+msgid "Diff display options"
+msgstr "Diff kijelző opciók"
+
+#: gitk:10356
+msgid "Tab spacing"
+msgstr "Tab sorköz"
+
+#: gitk:10359
+msgid "Display nearby tags"
+msgstr "Szomszédos tagek kijelzése"
+
+#: gitk:10362
+msgid "Limit diffs to listed paths"
+msgstr "Korlátozott diffek a kilistázott útvonalakhoz"
+
+#: gitk:10365
+msgid "Support per-file encodings"
+msgstr "Fájlonkénti kódolás támgatása"
+
+#: gitk:10371 gitk:10436
+msgid "External diff tool"
+msgstr "Külső diff alkalmazás"
+
+#: gitk:10373
+msgid "Choose..."
+msgstr "Válaszd ..."
+
+#: gitk:10378
+msgid "Colors: press to choose"
+msgstr "SzÃnek: nyomja meg a kiválasztáshoz"
+
+#: gitk:10381
+msgid "Background"
+msgstr "Háttér"
+
+#: gitk:10382 gitk:10412
+msgid "background"
+msgstr "háttér"
+
+#: gitk:10385
+msgid "Foreground"
+msgstr "Előtér"
+
+#: gitk:10386
+msgid "foreground"
+msgstr "előtér"
+
+#: gitk:10389
+msgid "Diff: old lines"
+msgstr "Diff: régi sorok"
+
+#: gitk:10390
+msgid "diff old lines"
+msgstr "diff régi sorok"
+
+#: gitk:10394
+msgid "Diff: new lines"
+msgstr "Diff: új sorok"
+
+#: gitk:10395
+msgid "diff new lines"
+msgstr "diff - új sorok"
+
+#: gitk:10399
+msgid "Diff: hunk header"
+msgstr "Diff: nagy headerök"
+
+#: gitk:10401
+msgid "diff hunk header"
+msgstr "diff - nagy headerök"
+
+#: gitk:10405
+msgid "Marked line bg"
+msgstr "Megjelölt sor háttér"
+
+#: gitk:10407
+msgid "marked line background"
+msgstr "megjelölt sor háttér"
+
+#: gitk:10411
+msgid "Select bg"
+msgstr "Válasszon hátteret"
+
+#: gitk:10415
+msgid "Fonts: press to choose"
+msgstr "Betű: nyomja meg a kiválasztáshoz"
+
+#: gitk:10417
+msgid "Main font"
+msgstr "Fő betű"
+
+#: gitk:10418
+msgid "Diff display font"
+msgstr "Diff kijelző betű"
+
+#: gitk:10419
+msgid "User interface font"
+msgstr "Felhasználói interfész betű"
+
+#: gitk:10446
+#, tcl-format
+msgid "Gitk: choose color for %s"
+msgstr "Gitk: válasszon szÃnt a %s-ra"
+
+#: gitk:10893
+msgid ""
+"Sorry, gitk cannot run with this version of Tcl/Tk.\n"
+" Gitk requires at least Tcl/Tk 8.4."
+msgstr ""
+"Sajnáljuk, de a gitk nem futtatható ezzel a Tcl/Tk verzióval.\n"
+"Gitk futtatásához legalább Tcl/Tk 8.4 szükséges."
+
+#: gitk:11020
+msgid "Cannot find a git repository here."
+msgstr "Nem találhatü git repository itt."
+
+#: gitk:11024
+#, tcl-format
+msgid "Cannot find the git directory \"%s\"."
+msgstr "Nem található a \"%s\" könyvtár."
+
+#: gitk:11071
+#, tcl-format
+msgid "Ambiguous argument '%s': both revision and filename"
+msgstr "FélreérthetÅ‘ argumentum '%s': revÃzió és fájlnév is"
+
+#: gitk:11083
+msgid "Bad arguments to gitk:"
+msgstr "Rossz gitk argumentumok:"
+
+#: gitk:11167
+msgid "Command line"
+msgstr "Parancs sor"
--
1.6.5
^ permalink raw reply related
* Re: pushing remote branches
From: Sitaram Chamarty @ 2009-11-15 11:04 UTC (permalink / raw)
To: Lorenzo Bettini; +Cc: git
In-Reply-To: <hdoko1$s78$1@ger.gmane.org>
On Sun, Nov 15, 2009 at 3:51 PM, Lorenzo Bettini <bettini@dsi.unifi.it> wrote:
> Sitaram Chamarty wrote:
>>
>> Hi Lorenzo,
>>
>> On Sun, Nov 15, 2009 at 5:07 AM, Lorenzo Bettini <bettini@dsi.unifi.it>
>> wrote:
>>
>>> url = git://...
>>
>>> isn't this enough to be able to push the experiments branch?
>>
>> not normally.
>>
>> The "git://" protocol is a read-only protocol by default. Since it is
>> completely unauthenticated, enabling push via git:// is not a good idea in
>> general.
>
> so probably I managed to push origin master anyway because gitorious asked
> me for my ssh passphrase?
As far as I know you could not have pushed anything when the url is
git:// (at least by default. Push over git:// can be enabled but is
highly inadvisable and I have not seen anyone enable it nor any good
reason to)
> Thus, if I had
>
> [remote "origin"]
> fetch = +refs/heads/*:refs/remotes/origin/*
> url = git@...
> [branch "master"]
> remote = origin
> merge = refs/heads/master
> [branch "experiments"]
> remote = origin
> merge = refs/heads/experiments
>
> instead of
>
> [remote "origin"]
> fetch = +refs/heads/*:refs/remotes/origin/*
> url = git://...
> [branch "master"]
> remote = origin
> merge = refs/heads/master
> [branch "experiments"]
> remote = origin
> merge = refs/heads/experiments
>
> I would have been able to push also to branch experiments? Without having
> to add
>
> [remote "experiments"]
> url = git@...
> fetch = +refs/heads/experiments:refs/remotes/experiments/experiments
>
> ?
(by the way: do you mean refs/remotes/origin/experiments in that last
line above?)
Anyway to answer your question, I do not see the refspec line as the issue
here, but the URL for the repo, which determines how you access it.
regards,
sitaram
^ permalink raw reply
* What's cooking in git.git (Nov 2009, #03; Sun, 15)
From: Junio C Hamano @ 2009-11-15 10:23 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' while commits prefixed with '+' are in 'next'. The ones
marked with '.' do not appear in any of the integration branches, but I am
still holding onto them.
In 1.7.0, we plan to correct handful of warts in the interfaces everybody
agrees that they were mistakes. The resulting system may not be strictly
backward compatible. Currently planned changes are:
* refuse push to update the checked out branch in a non-bare repo by
default
Make "git push" into a repository to update the branch that is checked
out fail by default. You can countermand this default by setting a
configuration variable in the receiving repository.
http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007
* refuse push to delete the current branch by default
Make "git push $there :$killed" to delete the branch that is pointed at
by its HEAD fail by default. You can countermand this default by
setting a configuration variable in the receiving repository.
http://thread.gmane.org/gmane.comp.version-control.git/108862/focus=108936
* git-send-email won't make deep threads by default
Many people said that by default when sending more than 2 patches the
threading git-send-email makes by default is hard to read, and they
prefer the default be one cover letter and each patch as a direct
follow-up to the cover letter. You can countermand this by setting a
configuration variable.
http://article.gmane.org/gmane.comp.version-control.git/109790
* git-status won't be "git-commit --dry-run" anymore
http://thread.gmane.org/gmane.comp.version-control.git/125989/focus=125993
* "git-diff -w --exit-code" will exit success if only differences it
found are whitespace changes that are stripped away from the output.
http://thread.gmane.org/gmane.comp.version-control.git/119731/focus=119751
I wasn't fully functioning for the past few days, so this round we have
only added new topics and new patches to existing ones, without changing
the status of individual topics very much.
--------------------------------------------------
[Graduated to "master"]
* jk/maint-format-patch-p-suppress-stat (2009-11-04) 1 commit.
(merged to 'next' on 2009-11-08 at 0943296)
+ format-patch: make "-p" suppress diffstat
(this branch is used by bg/format-patch-doc-update.)
* vl/maint-openssl-signature-change (2009-10-31) 1 commit.
(merged to 'next' on 2009-10-31 at 0e1ce6b)
+ imap-send.c: fix compiler warnings for OpenSSL 1.0
Prepare ourselves before newer versions of OpenSSL hits more platforms.
* pb/maint-gitweb-blob-lineno (2009-11-06) 1 commit.
(merged to 'next' on 2009-11-06 at 27b86ec)
+ gitweb: Fix blob linenr links in pathinfo mode
* bg/merge-ff-only (2009-10-29) 1 commit
(merged to 'next' on 2009-10-31 at b6b49aa)
+ Teach 'git merge' and 'git pull' the option --ff-only
* jk/maint-1.6.3-ls-files-i (2009-10-30) 1 commit.
(merged to 'next' on 2009-10-31 at 3a31fcc)
+ ls-files: unbreak "ls-files -i"
* tr/describe-advice (2009-10-28) 1 commit
(merged to 'next' on 2009-10-31 at 8084850)
+ describe: when failing, tell the user about options that work
* jp/dirty-describe (2009-10-21) 1 commit.
(merged to 'next' on 2009-10-30 at 19c7fc7)
+ Teach "git describe" --dirty option
* jk/gitignore-anchored (2009-10-26) 1 commit
(merged to 'next' on 2009-10-30 at 9391a93)
+ gitignore: root most patterns at the top-level directory
* jk/maint-push-config (2009-10-25) 1 commit.
(merged to 'next' on 2009-10-30 at 934e3c5)
+ push: always load default config
* sr/blame-incomplete (2009-10-19) 1 commit.
(merged to 'next' on 2009-10-22 at 133e0ce)
+ blame: make sure that the last line ends in an LF
I think this is _good enough_ as-is; although it would be better if we
added some hint to the output for Porcelain implementations, that can be
done as a follow-up fix.
--------------------------------------------------
[New Topics]
* jn/help-everywhere (2009-11-09) 21 commits
- diff --no-index: make the usage string less scary
- merge-{recursive,subtree}: use usagef() to print usage
- Introduce usagef() that takes a printf-style format
- Let 'git <command> -h' show usage without a git dir
- Show usage string for 'git http-push -h'
- Let 'git http-fetch -h' show usage outside any git repository
- Show usage string for 'git stripspace -h'
- Show usage string for 'git unpack-file -h'
- Show usage string for 'git show-index -h'
- Show usage string for 'git rev-parse -h'
- Show usage string for 'git merge-one-file -h'
- Show usage string for 'git mailsplit -h'
- Show usage string for 'git imap-send -h'
- Show usage string for 'git get-tar-commit-id -h'
- Show usage string for 'git fast-import -h'
- Show usage string for 'git check-ref-format -h'
- Show usage string for 'git show-ref -h'
- Show usage string for 'git merge-ours -h'
- Show usage string for 'git commit-tree -h'
- Show usage string for 'git cherry -h'
- Show usage string for 'git grep -h'
(this branch uses jn/maint-http-fetch-mingw and jn/remove-fetch--tool.)
There were unrelated but still worthy fixes, so I reordered some of them;
also the "usage()" change is different from the one that was posted (see
my comment in $gmane/132592).
* jn/maint-http-fetch-mingw (2009-11-09) 1 commit.
- http-fetch: add missing initialization of argv0_path
(this branch is used by jn/help-everywhere.)
* jn/remove-fetch--tool (2009-11-09) 1 commit
- Retire fetch--tool helper to contrib/examples
(this branch is used by jn/help-everywhere.)
These two were originally part of the "help-everywhere" topic but
they can stand on their own.
* jc/log-stdin (2009-11-03) 1 commit
- Teach --stdin option to "log" family
This is not signed-off (see $gmane/131971 for list of things you can do to
help advancing this topic).
* jn/gitweb-log-history (2009-11-13) 3 commits
- gitweb: Make 'history' view (re)use git_log_generic()
- gitweb: Refactor common parts of 'log' and 'shortlog' views
- gitweb: Refactor 'log' action generation, adding git_log_body()
* jn/rfc-pull-rebase-error-message (2009-11-12) 1 commit
- git-pull.sh --rebase: overhaul error handling when no candidates are found
* np/maint-sideband-favor-status (2009-11-11) 1 commit.
- give priority to progress messages
This looked obviously correct but I wasn't fully up to speed after being
ill for a few days, so it is queued in 'pu' with everything else.
* rg/doc-workflow (2009-11-14) 2 commits.
- Corrections to release management section in gitworkflows.txt
- Add branch management for releases to gitworkflows
* sb/ls-tree-parseopt (2009-11-13) 2 commits.
- ls-tree: migrate to parse-options
- t3101: test more ls-tree options
* tz/maint-rpm (2009-11-11) 1 commit.
- Makefile: Ensure rpm packages can be read by older rpm versions
--------------------------------------------------
[Stalled]
* jl/submodule-add-noname (2009-09-22) 1 commit.
- git submodule add: make the <path> parameter optional
Dscho started an interesting discussion regarding the larger workflow in
which the "submodule add" is used. I think the patch itself makes sense
but at the same time it probably makes sense to also take the <path> and
infer the <repository> as Dscho suggested, probably in "git submodule
add", not in "git add" proper, at least initially.
Any objections against merging this to 'next'?
* jc/fix-tree-walk (2009-10-22) 11 commits.
(merged to 'next' on 2009-10-22 at 10c0c8f)
+ Revert failed attempt since 353c5ee
+ read-tree --debug-unpack
(merged to 'next' on 2009-10-11 at 0b058e2)
+ unpack-trees.c: look ahead in the index
+ unpack-trees.c: prepare for looking ahead in the index
+ Aggressive three-way merge: fix D/F case
+ traverse_trees(): handle D/F conflict case sanely
+ more D/F conflict tests
+ tests: move convenience regexp to match object names to test-lib.sh
+ unpack_callback(): use unpack_failed() consistently
+ unpack-trees: typofix
+ diff-lib.c: fix misleading comments on oneway_diff()
This has some stupid bugs and temporarily reverted from 'next' until I can
fix it, but the "temporarily" turned out to be very loooong. Sigh...
* jh/notes (2009-10-09) 22 commits.
- fast-import: Proper notes tree manipulation using the notes API
- Refactor notes concatenation into a flexible interface for combining notes
- Notes API: Allow multiple concurrent notes trees with new struct notes_tree
- Notes API: for_each_note(): Traverse the entire notes tree with a callback
- Notes API: get_note(): Return the note annotating the given object
- Notes API: add_note(): Add note objects to the internal notes tree structure
- Notes API: init_notes(): Initialize the notes tree from the given notes ref
- Notes API: get_commit_notes() -> format_note() + remove the commit restriction
(merged to 'next' on 2009-11-01 at 948327a)
+ Add selftests verifying concatenation of multiple notes for the same commit
+ Refactor notes code to concatenate multiple notes annotating the same object
+ Add selftests verifying that we can parse notes trees with various fanouts
+ Teach the notes lookup code to parse notes trees with various fanout schemes
+ Teach notes code to free its internal data structures on request
+ Add '%N'-format for pretty-printing commit notes
+ Add flags to get_commit_notes() to control the format of the note string
+ t3302-notes-index-expensive: Speed up create_repo()
+ fast-import: Add support for importing commit notes
+ Teach "-m <msg>" and "-F <file>" to "git notes edit"
+ Add an expensive test for git-notes
+ Speed up git notes lookup
+ Add a script to edit/inspect notes
+ Introduce commit notes
I somehow thought that the later API part was waiting for updates but
nothing seems to be happening.
* jn/gitweb-blame (2009-09-01) 5 commits.
- gitweb: Minify gitweb.js if JSMIN is defined
- gitweb: Create links leading to 'blame_incremental' using JavaScript
(merged to 'next' on 2009-10-11 at 73c4a83)
+ gitweb: Colorize 'blame_incremental' view during processing
+ gitweb: Incremental blame (using JavaScript)
+ gitweb: Add optional "time to generate page" info in footer
Ajax-y blame. Any progress or RFH?
* sr/gfi-options (2009-09-06) 6 commits.
- fast-import: test the new option command
- fast-import: add option command
- fast-import: test the new feature command
- fast-import: add feature command
- fast-import: put marks reading in it's own function
- fast-import: put option parsing code in separate functions
It seemed to be moving again soon, but nothing has happened yet...
* je/send-email-no-subject (2009-08-05) 1 commit.
(merged to 'next' on 2009-10-11 at 1b99c56)
+ send-email: confirm on empty mail subjects
The existing tests cover the positive case (i.e. as long as the user says
"yes" to the "do you really want to send this message that lacks subject",
the message is sent) of this feature, but the feature itself needs its own
test to verify the negative case (i.e. does it correctly stop if the user
says "no"?)
--------------------------------------------------
[Cooking]
* sc/protocol-doc (2009-11-03) 1 commit.
- Update packfile transfer protocol documentation
* tr/filter-branch (2009-11-10) 2 commits.
- filter-branch: nearest-ancestor rewriting outside subdir filter
- filter-branch: stop special-casing $filter_subdir argument
Updated again. Looked sane, except that the option might not be
necessary. But that can be fixed while in 'next', so unless anybody
sees further issues, I'll move this to 'next' soon.
* em/commit-claim (2009-11-04) 1 commit
- commit -c/-C/--amend: reset timestamp and authorship to committer with --reset-author
I just picked better bits from both versions, but this needs to be
rethought.
* bg/format-patch-doc-update (2009-11-07) 4 commits
- format-patch: Add "--no-stat" as a synonym for "-p"
- format-patch documentation: Fix formatting
- format-patch documentation: Remove diff options that are not useful
- format-patch: Always generate a patch
Looked sensible, even though this may want to wait for 1.7.0. We'll see
when we merge this to 'next'. I tweaked the --no-stat patch with noneg
bit; please check for sanity.
* rj/maint-simplify-cygwin-makefile (2009-10-27) 1 commit.
- Makefile: merge two Cygwin configuration sections into one
(this branch is used by rj/cygwin-msvc.)
This is one of the most obviously correct bit from "Compiling on Cygwin
using MSVC fails" topic.
* rj/cygwin-msvc (2009-11-09) 3 commits.
- Add explicit Cygwin check to guard WIN32 header inclusion
- MSVC: Add support for building with NO_MMAP
- Makefile: keep MSVC and Cygwin configuration separate
(this branch uses rj/maint-simplify-cygwin-makefile.)
I think J6t was not happy with the tip one.
* bg/fetch-multi (2009-11-10) 9 commits
- Re-implement 'git remote update' using 'git fetch'
- builtin-fetch: add --dry-run option
- builtin-fetch: add --prune option
- teach warn_dangling_symref to take a FILE argument
- remote: refactor some logic into get_stale_heads()
- Add missing test for 'git remote update --prune'
- Add the configuration option skipFetchAll
- Teach the --multiple option to 'git fetch'
- Teach the --all option to 'git fetch'
This series from Björn Gustavsson contains 4 patches from Jay Soffian as
well. I haven't looked at the code very closely yet.
* bs/maint-pre-commit-hook-sample (2009-11-05) 1 commit.
(merged to 'next' on 2009-11-06 at d70f646)
+ pre-commit.sample: Diff against the empty tree when HEAD is invalid
Looked Ok.
* cc/bisect-doc (2009-11-08) 1 commit
- Documentation: add "Fighting regressions with git bisect" article
Any comments? Should it go to Documentation/technical instead?
* sb/tutorial-test (2009-11-06) 4 commits
- t1200: prepare for merging with Fast-forward bikeshedding
- t1200: further modernize test script style
- t1200: Make documentation and test agree
- t1200: cleanup and modernize test style
Ready for 'next', I think.
* jn/editor-pager (2009-10-30) 9 commits
- Provide a build time default-pager setting
- Provide a build time default-editor setting
- am -i, git-svn: use "git var GIT_PAGER"
- add -i, send-email, svn, p4, etc: use "git var GIT_EDITOR"
- Teach git var about GIT_PAGER
- Teach git var about GIT_EDITOR
- Suppress warnings from "git var -l"
- Do not use VISUAL editor on dumb terminals
- Handle more shell metacharacters in editor names
* bw/autoconf-more (2009-11-04) 2 commits
- configure: add settings for gitconfig, editor and pager
- configure: add macro to set arbitrary make variables
This will follow jn/editor-pager series.
* js/maint-diff-color-words (2009-10-30) 3 commits.
(merged to 'next' on 2009-11-10 at 5619714)
+ diff --color-words: bit of clean-up
+ diff --color-words -U0: fix the location of hunk headers
+ t4034-diff-words: add a test for word diff without context
Fixes a corner case of running --color-words with -U0.
* sc/difftool-p4merge (2009-10-28) 1 commit
(merged to 'next' on 2009-10-31 at 194b5c5)
+ mergetool--lib: add p4merge as a pre-configured mergetool option
I do not do p4 nor use difftool, so it's much easier for me to merge this
to 'master' and wait for anybody to scream if there is breakage. I'll do
so, unless I hear objections in a few days.
* sr/vcs-helper (2009-11-06) 12 commits
- Add Python support library for remote helpers
- Basic build infrastructure for Python scripts
- Allow helpers to request the path to the .git directory
- Allow helpers to report in "list" command that the ref is unchanged
- Allow helper to map private ref names into normal names
- Add support for "import" helper command
- Allow specifying the remote helper in the url
- Add a config option for remotes to specify a foreign vcs
- Allow fetch to modify refs
- Use a function to determine whether a remote is valid
- Allow programs to not depend on remotes having urls
- Fix memory leak in helper method for disconnect
Re-rolled series that contains Daniel's and Johan's.
Any comments? Is everybody happy?
* mr/gitweb-snapshot (2009-11-07) 4 commits.
- gitweb: Smarter snapshot names
- gitweb: Document current snapshot rules via new tests
- t/gitweb-lib.sh: Split gitweb output into headers and body
(merged to 'next' on 2009-10-11 at 22ba047)
+ gitweb: check given hash before trying to create snapshot
Replaced commits near the tip with recent updates.
* jp/fetch-cull-many-refs (2009-11-13) 3 commits
(merged to 'next' on 2009-11-15 at db0f967)
+ remote: fix use-after-free error detected by glibc in ref_remove_duplicates
(merged to 'next' on 2009-11-01 at 1f09ce9)
+ fetch: Speed up fetch of large numbers of refs
+ remote: Make ref_remove_duplicates faster for large numbers of refs
Soon in 'master'.
* jk/maint-add-p-empty (2009-10-27) 1 commit.
(merged to 'next' on 2009-10-30 at 2bd302f)
+ add-interactive: handle deletion of empty files
Soon in 'master'.
* lt/revision-bisect (2009-10-27) 1 commit.
(merged to 'next' on 2009-10-30 at 81ee52b)
+ Add '--bisect' revision machinery argument
Soon in 'master'.
* jc/pretty-lf (2009-10-04) 1 commit.
- Pretty-format: %[+-]x to tweak inter-item newlines
* rs/pretty-wrap (2009-11-08) 2 commits
(merged to 'next' on 2009-11-08 at 8973fd8)
+ log --format: don't ignore %w() at the start of format string
(merged to 'next' on 2009-10-30 at 403bbfe)
+ Implement wrap format %w() as if it is a mode switch
(this branch uses js/log-rewrap.)
Soon in 'master'.
* js/log-rewrap (2009-10-18) 3 commits
(merged to 'next' on 2009-10-30 at 403bbfe)
+ Teach --wrap to only indent without wrapping
+ Add strbuf_add_wrapped_text() to utf8.[ch]
+ print_wrapped_text(): allow hard newlines
(this branch is used by rs/pretty-wrap.)
Soon in 'master'.
* fc/doc-fast-forward (2009-10-24) 1 commit.
(merged to 'next' on 2009-11-01 at faaad90)
+ Use 'fast-forward' all over the place
Soon in 'master'; carrying this in 'next' for too long is turning out to
be quite painful.
* ks/precompute-completion (2009-10-26) 3 commits.
(merged to 'next' on 2009-10-28 at cd5177f)
+ completion: ignore custom merge strategies when pre-generating
(merged to 'next' on 2009-10-22 at f46a28a)
+ bug: precomputed completion includes scripts sources
(merged to 'next' on 2009-10-14 at adf722a)
+ Speedup bash completion loading
I didn't follow the discussion from the past few days closely, but I am
getting an impression that the consensus is we shouldn't precompute, so I
may have to revert this and replace with what's cooking on the list when
it stabilizes.
* sp/smart-http (2009-11-11) 35 commits
(merged to 'next' on 2009-11-15 at 2a326b2)
+ http-backend: Fix bad treatment of uintmax_t in Content-Length
+ t5551-http-fetch: Work around broken Accept header in libcurl
+ t5551-http-fetch: Work around some libcurl versions
+ http-backend: Protect GIT_PROJECT_ROOT from /../ requests
+ Git-aware CGI to provide dumb HTTP transport
(merged to 'next' on 2009-11-06 at 666837c)
+ http-backend: Test configuration options
+ http-backend: Use http.getanyfile to disable dumb HTTP serving
+ test smart http fetch and push
+ http tests: use /dumb/ URL prefix
+ set httpd port before sourcing lib-httpd
+ t5540-http-push: remove redundant fetches
+ Smart HTTP fetch: gzip requests
+ Smart fetch over HTTP: client side
+ Smart push over HTTP: client side
+ Discover refs via smart HTTP server when available
+ http-backend: more explict LocationMatch
+ http-backend: add example for gitweb on same URL
+ http-backend: use mod_alias instead of mod_rewrite
+ http-backend: reword some documentation
+ http-backend: add GIT_PROJECT_ROOT environment var
+ Smart fetch and push over HTTP: server side
+ Add stateless RPC options to upload-pack, receive-pack
+ Git-aware CGI to provide dumb HTTP transport
+ remote-helpers: return successfully if everything up-to-date
+ Move WebDAV HTTP push under remote-curl
+ remote-helpers: Support custom transport options
+ remote-helpers: Fetch more than one ref in a batch
+ fetch: Allow transport -v -v -v to set verbosity to 3
+ remote-curl: Refactor walker initialization
+ Add multi_ack_detailed capability to fetch-pack/upload-pack
+ Move "get_ack()" back to fetch-pack
+ fetch-pack: Use a strbuf to compose the want list
+ pkt-line: Make packet_read_line easier to debug
+ pkt-line: Add strbuf based functions
+ http-push: fix check condition on http.c::finish_http_pack_request()
* ef/msys-imap (2009-10-22) 9 commits.
(merged to 'next' on 2009-10-31 at 8630603)
+ Windows: use BLK_SHA1 again
+ MSVC: Enable OpenSSL, and translate -lcrypto
+ mingw: enable OpenSSL
+ mingw: wrap SSL_set_(w|r)fd to call _get_osfhandle
+ imap-send: build imap-send on Windows
+ imap-send: fix compilation-error on Windows
+ imap-send: use run-command API for tunneling
+ imap-send: use separate read and write fds
+ imap-send: remove useless uid code
Soon in 'master', unless I hear objections from msys folks or imap-send
users.
* nd/sparse (2009-08-20) 19 commits.
- sparse checkout: inhibit empty worktree
- Add tests for sparse checkout
- read-tree: add --no-sparse-checkout to disable sparse checkout support
- unpack-trees(): ignore worktree check outside checkout area
- unpack_trees(): apply $GIT_DIR/info/sparse-checkout to the final index
- unpack-trees(): "enable" sparse checkout and load $GIT_DIR/info/sparse-checkout
- unpack-trees.c: generalize verify_* functions
- unpack-trees(): add CE_WT_REMOVE to remove on worktree alone
- Introduce "sparse checkout"
- dir.c: export excluded_1() and add_excludes_from_file_1()
- excluded_1(): support exclude files in index
- unpack-trees(): carry skip-worktree bit over in merged_entry()
- Read .gitignore from index if it is skip-worktree
- Avoid writing to buffer in add_excludes_from_file_1()
- Teach Git to respect skip-worktree bit (writing part)
- Teach Git to respect skip-worktree bit (reading part)
- Introduce "skip-worktree" bit in index, teach Git to get/set this bit
- Add test-index-version
- update-index: refactor mark_valid() in preparation for new options
The latest update I didn't look at very closely but I had an impression
that it was touching very generic codepath that would affect non sparse
cases, iow the patch looked very scary (the entire series already is).
--------------------------------------------------
[For 1.7.0]
* jc/1.7.0-no-commit-no-ff-2 (2009-10-22) 1 commit.
- git-merge: forbid fast-forward and up-to-date when --no-commit is given
This makes "git merge --no-commit" fail when it results in fast-forward or
up-to-date. I haven't described this at the beginning of this message
yet, as it is not clear if this change is even necessary. Opinions?
* jk/1.7.0-status (2009-09-05) 5 commits.
- docs: note that status configuration affects only long format
(merged to 'next' on 2009-10-11 at 65c8513)
+ commit: support alternate status formats
+ status: add --porcelain output format
+ status: refactor format option parsing
+ status: refactor short-mode printing to its own function
(this branch uses jc/1.7.0-status.)
Gives the --short output format to post 1.7.0 "git commit --dry-run" that
is similar to that of post 1.7.0 "git status".
The tip one is not in 'next' as I have been hoping that somebody may want
to change the code to make it unnecessary, but it does not seem to be
happening, so probably it should also go to 'next'.
* jc/1.7.0-status (2009-09-05) 4 commits.
(merged to 'next' on 2009-10-11 at 9558627)
+ status: typo fix in usage
+ git status: not "commit --dry-run" anymore
+ git stat -s: short status output
+ git stat: the beginning of "status that is not a dry-run of commit"
(this branch is used by jk/1.7.0-status.)
With this, "git status" is no longer "git commit --dry-run".
* jc/1.7.0-send-email-no-thread-default (2009-08-22) 1 commit.
(merged to 'next' on 2009-10-11 at 043acdf)
+ send-email: make --no-chain-reply-to the default
* jc/1.7.0-diff-whitespace-only-status (2009-08-30) 4 commits.
(merged to 'next' on 2009-10-11 at 546c74d)
+ diff.c: fix typoes in comments
+ Make test case number unique
+ diff: Rename QUIET internal option to QUICK
+ diff: change semantics of "ignore whitespace" options
This changes exit code from "git diff --ignore-whitespace" and friends
when there is no actual output. It is a backward incompatible change, but
we could argue that it is a bugfix.
* jc/1.7.0-push-safety (2009-02-09) 2 commits.
(merged to 'next' on 2009-10-11 at 81b8128)
+ Refuse deleting the current branch via push
+ Refuse updating the current branch in a non-bare repository via push
--------------------------------------------------
[I have been too busy to purge these]
* ne/rev-cache (2009-10-19) 7 commits.
. support for commit grafts, slight change to general mechanism
. support for path name caching in rev-cache
. full integration of rev-cache into git, completed test suite
. administrative functions for rev-cache, start of integration into git
. support for non-commit object caching in rev-cache
. basic revision cache system, no integration or features
. man page and technical discussion for rev-cache
The author indicated that there is another round coming. Does not seem to
pass the tests when merged to 'pu', so it has been ejected for now.
* jc/log-tz (2009-03-03) 1 commit.
- Allow --date=local --date=other-format to work as expected
Maybe some people care about this. I dunno.
* jc/mailinfo-remove-brackets (2009-07-15) 1 commit.
- mailinfo: -b option keeps [bracketed] strings that is not a [PATCH] marker
Maybe some people care about this. I dunno.
* pb/gitweb-no-project-list (2009-11-06) 3 commits.
. gitweb: Polish the content tags support
. gitweb: Support for no project list on gitweb front page
. gitweb: Refactor project list routines
I picked these up but didn't queue as Warthog9's comments made certain
amount of sense to me.
^ permalink raw reply
* Re: pushing remote branches
From: Lorenzo Bettini @ 2009-11-15 10:21 UTC (permalink / raw)
To: git
In-Reply-To: <2e24e5b90911141645n59680856ja21f2f3c7063f7c0@mail.gmail.com>
Sitaram Chamarty wrote:
> Hi Lorenzo,
>
> On Sun, Nov 15, 2009 at 5:07 AM, Lorenzo Bettini <bettini@dsi.unifi.it> wrote:
>
>> url = git://...
>
>> isn't this enough to be able to push the experiments branch?
>
> not normally.
>
> The "git://" protocol is a read-only protocol by default. Since it is
> completely unauthenticated, enabling push via git:// is not a good idea in
> general.
so probably I managed to push origin master anyway because gitorious
asked me for my ssh passphrase?
>
>> url = git@...
>
> This is a shortcut for something like ssh://git@..., which then allows write
> also.
Thus, if I had
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
url = git@...
[branch "master"]
remote = origin
merge = refs/heads/master
[branch "experiments"]
remote = origin
merge = refs/heads/experiments
instead of
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
url = git://...
[branch "master"]
remote = origin
merge = refs/heads/master
[branch "experiments"]
remote = origin
merge = refs/heads/experiments
I would have been able to push also to branch experiments? Without
having to add
[remote "experiments"]
url = git@...
fetch =
+refs/heads/experiments:refs/remotes/experiments/experiments
?
thanks in advance
Lorenzo
--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
ICQ# lbetto, 16080134 (GNU/Linux User # 158233)
HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com
http://www.myspace.com/supertrouperabba
BLOGS: http://tronprog.blogspot.com http://longlivemusic.blogspot.com
http://www.gnu.org/software/src-highlite
http://www.gnu.org/software/gengetopt
http://www.gnu.org/software/gengen http://doublecpp.sourceforge.net
^ permalink raw reply
* [PATCH v2] Speed up bash completion loading
From: Jonathan Nieder @ 2009-11-15 10:29 UTC (permalink / raw)
To: Junio C Hamano
Cc: Stephen Boyd, Kirill Smelkov, Sverre Rabbelier, Shawn O. Pearce,
git
In-Reply-To: <7vd43krwd0.fsf@alter.siamese.dyndns.org>
On my slow laptop (P3 600MHz), system-wide bash completions take
too much time to load (> 2s), and a significant fraction of this
time is spent loading git-completion.bash:
$ time bash -c ". ./git-completion.bash" # hot cache, before this patch
real 0m0.509s
user 0m0.310s
sys 0m0.180s
Kirill noticed that most of the time is spent warming up the
merge_strategy, all_command and porcelain_command caches.
Since git is not used in each and every interactive xterm, it
seems best to load completion support with cold caches and then
load each needed thing lazily. This has most of the speed
advantage of pre-generating everything at build time, without the
complication of figuring out at build time what commands will be
available at run time.
The result is that loading completion is significantly faster
now:
$ time bash -c ". ./git-completion.bash" # cold cache, after this patch
real 0m0.171s
user 0m0.060s
sys 0m0.040s
Suggested-by: Kirill Smelkov <kirr@mns.spb.ru>
Cc: Shawn O. Pearce <spearce@spearce.org>
Cc: Stephen Boyd <bebarino@gmail.com>
Cc: SZEDER Gábor <szeder@ira.uka.de>
Cc: Sverre Rabbelier <srabbelier@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
This version incorporates the small improvements previously sent, plus the
following nice one (which makes caching merge strategies safe again).
Thanks for the advice, everyone.
Junio C Hamano wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>
> > __git_compute_merge_strategies ()
> > {
> > - : ${__git_merge_strategies=$(__git_list_merge_strategies)}
> > + __git_merge_strategies=$(__git_list_merge_strategies)
>
> Wouldn't
>
> : ${__gms:=$(command)}
>
> run command only until it gives a non-empty string?
Yes. :)
contrib/completion/git-completion.bash | 76 +++++++++++++++++---------------
1 files changed, 41 insertions(+), 35 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index e3ddecc..43d76b7 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -21,13 +21,7 @@
# 2) Added the following line to your .bashrc:
# source ~/.git-completion.sh
#
-# 3) You may want to make sure the git executable is available
-# in your PATH before this script is sourced, as some caching
-# is performed while the script loads. If git isn't found
-# at source time then all lookups will be done on demand,
-# which may be slightly slower.
-#
-# 4) Consider changing your PS1 to also show the current branch:
+# 3) Consider changing your PS1 to also show the current branch:
# PS1='[\u@\h \W$(__git_ps1 " (%s)")]\$ '
#
# The argument to __git_ps1 will be displayed only if you
@@ -324,12 +318,8 @@ __git_remotes ()
done
}
-__git_merge_strategies ()
+__git_list_merge_strategies ()
{
- if [ -n "${__git_merge_strategylist-}" ]; then
- echo "$__git_merge_strategylist"
- return
- fi
git merge -s help 2>&1 |
sed -n -e '/[Aa]vailable strategies are: /,/^$/{
s/\.$//
@@ -339,8 +329,17 @@ __git_merge_strategies ()
p
}'
}
-__git_merge_strategylist=
-__git_merge_strategylist=$(__git_merge_strategies 2>/dev/null)
+
+unset __git_merge_strategies
+# 'git merge -s help' (and thus detection of the merge strategy
+# list) fails, unfortunately, if run outside of any git working
+# tree. __git_merge_strategies is set to the empty string in
+# that case, and the detection will be repeated the next time it
+# is needed.
+__git_compute_merge_strategies ()
+{
+ : ${__git_merge_strategies:=$(__git_list_merge_strategies)}
+}
__git_complete_file ()
{
@@ -474,27 +473,24 @@ __git_complete_remote_or_refspec ()
__git_complete_strategy ()
{
+ __git_compute_merge_strategies
case "${COMP_WORDS[COMP_CWORD-1]}" in
-s|--strategy)
- __gitcomp "$(__git_merge_strategies)"
+ __gitcomp "$__git_merge_strategies"
return 0
esac
local cur="${COMP_WORDS[COMP_CWORD]}"
case "$cur" in
--strategy=*)
- __gitcomp "$(__git_merge_strategies)" "" "${cur##--strategy=}"
+ __gitcomp "$__git_merge_strategies" "" "${cur##--strategy=}"
return 0
;;
esac
return 1
}
-__git_all_commands ()
+__git_list_all_commands ()
{
- if [ -n "${__git_all_commandlist-}" ]; then
- echo "$__git_all_commandlist"
- return
- fi
local i IFS=" "$'\n'
for i in $(git help -a|egrep '^ [a-zA-Z0-9]')
do
@@ -504,17 +500,18 @@ __git_all_commands ()
esac
done
}
-__git_all_commandlist=
-__git_all_commandlist="$(__git_all_commands 2>/dev/null)"
-__git_porcelain_commands ()
+unset __git_all_commands
+__git_compute_all_commands ()
+{
+ : ${__git_all_commands=$(__git_list_all_commands)}
+}
+
+__git_list_porcelain_commands ()
{
- if [ -n "${__git_porcelain_commandlist-}" ]; then
- echo "$__git_porcelain_commandlist"
- return
- fi
local i IFS=" "$'\n'
- for i in "help" $(__git_all_commands)
+ __git_compute_all_commands
+ for i in "help" $__git_all_commands
do
case $i in
*--*) : helper pattern;;
@@ -595,8 +592,13 @@ __git_porcelain_commands ()
esac
done
}
-__git_porcelain_commandlist=
-__git_porcelain_commandlist="$(__git_porcelain_commands 2>/dev/null)"
+
+unset __git_porcelain_commands
+__git_compute_porcelain_commands ()
+{
+ __git_compute_all_commands
+ : ${__git_porcelain_commands=$(__git_list_porcelain_commands)}
+}
__git_aliases ()
{
@@ -1088,7 +1090,8 @@ _git_help ()
return
;;
esac
- __gitcomp "$(__git_all_commands)
+ __git_compute_all_commands
+ __gitcomp "$__git_all_commands
attributes cli core-tutorial cvs-migration
diffcore gitk glossary hooks ignore modules
repository-layout tutorial tutorial-2
@@ -1444,7 +1447,8 @@ _git_config ()
return
;;
pull.twohead|pull.octopus)
- __gitcomp "$(__git_merge_strategies)"
+ __git_compute_merge_strategies
+ __gitcomp "$__git_merge_strategies"
return
;;
color.branch|color.diff|color.interactive|\
@@ -1545,7 +1549,8 @@ _git_config ()
pager.*)
local pfx="${cur%.*}."
cur="${cur#*.}"
- __gitcomp "$(__git_all_commands)" "$pfx" "$cur"
+ __git_compute_all_commands
+ __gitcomp "$__git_all_commands" "$pfx" "$cur"
return
;;
remote.*.*)
@@ -2142,7 +2147,8 @@ _git ()
--help
"
;;
- *) __gitcomp "$(__git_porcelain_commands) $(__git_aliases)" ;;
+ *) __git_compute_porcelain_commands
+ __gitcomp "$__git_porcelain_commands $(__git_aliases)" ;;
esac
return
fi
--
1.6.5.2
^ permalink raw reply related
* Re: [PATCH todo] dodoc: detect doctype-xsl version before making docs
From: Junio C Hamano @ 2009-11-15 10:09 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: gitster, git
In-Reply-To: <20091112023139.GA1627@progeny.tock>
Jonathan Nieder <jrnieder@gmail.com> writes:
> The manpages in the man branch of git.git appear to have acquired
> the dreaded escaped .ft disease when the docbook-xsl toolchain
> was upgraded to v1.74.3.
> ---
> It is hard work avoiding escaped nroff directives in output. I am a
> bit confused at what happened here, since docbook-xsl v1.73.2 should
> have required the same settings.
>
> These changes are untested, unfortunately. I hope they can be of some
> help nevertheless.
>
> dodoc.sh | 13 +++++++++++++
> 1 files changed, 13 insertions(+), 0 deletions(-)
>
> diff --git a/dodoc.sh b/dodoc.sh
> index 5cbc269..bf49710 100755
> --- a/dodoc.sh
> +++ b/dodoc.sh
> @@ -77,6 +77,19 @@ asciidoc' 8'.*)
> export ASCIIDOC8 ;;
> esac
>
> +db_version_file=/usr/share/xml/docbook/stylesheet/nwalsh/VERSION
> +case "$(grep "<fm:Version>" "$db_version_file" 2>/dev/null)" in
Thanks, but there seem to be no such file on FC11. In /etc/xml/catalog,
I see:
<rewriteURI
uriStartString="http://docbook.sourceforge.net/release/xsl/current"
rewritePrefix="file:///usr/share/sgml/docbook/xsl-stylesheets-1.74.3"/>
Unfortunately this seems highly distro dependent. On my near-by Debian
box, /etc/xml/docbook-xsl.xml has
<delegateURI
uriStartString="http://docbook.sourceforge.net/release/xsl/"
catalog="file:///usr/share/xml/docbook/stylesheet/nwalsh/catalog.xml"/>
and the _catalog_ file has comment v1.73.2 (or whatever) and also
<rewriteURI
uriStartString="http://docbook.sourceforge.net/release/xsl/1.73.2/"
rewritePrefix="./"/>
For now I simply will give up to be portable and adjust the script for the
reality on k.org machine that is used to auto-generate the documentation.
^ permalink raw reply
* Make Gitweb behave like Apache mod_userdir
From: Sylvain Rabot @ 2009-11-15 10:04 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1383 bytes --]
Hello,
I contact you because I spent quite some time to make something pretty
basic with gitweb.
I made gitweb behave a bit like UserDir module will in apache.
In fact it's only configuration but I think it could be useful to others.
Basicly it allows users of your server who use git to be able to use
gitweb to browse their own root project. E.G. :
Alice's private repos :
/home/alice/git/product_a.git (cloned from /var/git/product_a.git)
/home/alice/git/product_b.git (cloned from /var/git/product_b.git)
/home/alice/git/product_c.git (cloned from /var/git/product_c.git)
Alice's links to her repos which she wants to be able to browse with gitweb :
/home/alice/gitweb/product_a -> /home/alice/git/product_a.git/.git
/home/alice/gitweb/product_c -> /home/alice/git/product_c.git/.git
Bare repos :
/var/git/product_a.git
/var/git/product_b.git
/var/git/product_c.git
/var/git/product_d.git
/etc/gitweb.conf :
$projectroot = $ENV{'GITWEB_PROJECTROOT'} || "/var/git/";
Apache configuration :
RewriteRule ^/~([^\/]+)/?$ /cgi-bin/gitweb.cgi
[QSA,E=GITWEB_PROJECTROOT:/home/$1/gitweb/,L,PT]
So now all users with a gitweb folder in their home will be able to
browse all git repos in it through http://<host>/~<user>.
You will find a patch enclosed which try to describe best what I did
and why in the gitweb/README.
Regards.
[-- Attachment #2: userdirstyle.patch --]
[-- Type: application/octet-stream, Size: 1490 bytes --]
diff --git a/gitweb/README b/gitweb/README
index 66c6a93..6f733e6 100644
--- a/gitweb/README
+++ b/gitweb/README
@@ -306,8 +306,10 @@ repositories, you can configure apache like this:
DocumentRoot /pub/git
SetEnv GITWEB_CONFIG /etc/gitweb.conf
RewriteEngine on
+
# make the front page an internal rewrite to the gitweb script
RewriteRule ^/$ /cgi-bin/gitweb.cgi
+
# make access for "dumb clients" work
RewriteRule ^/(.*\.git/(?!/?(HEAD|info|objects|refs)).*)?$ /cgi-bin/gitweb.cgi%{REQUEST_URI} [L,PT]
</VirtualHost>
@@ -332,6 +334,20 @@ something like the following in your gitweb.conf (or gitweb_config.perl) file:
$my_uri = "/";
$home_link = "/";
+If you want gitweb to act a bit like UserDir mod in apache, knowing, http://<host>/~<user>
+will list all git repos of <user> located in a special directory in his home (/home/<user>/gitweb/),
+do the following steps :
+
+Add this to the VirtualHost section of your apache configuration file :
+
+ RewriteRule ^/~([^\/]+)/?$ /cgi-bin/gitweb.cgi [QSA,E=GITWEB_PROJECTROOT:/home/$1/gitweb/,L,PT]
+
+Modify your gitweb.conf file, located at /etc/gitweb.conf in this example, with :
+
+ $projectroot = $ENV{'GITWEB_PROJECTROOT'} || "/path/to/the/defaul/project/root";
+
+Thus, each user with a gitweb folder in his home will be able to browse it with gitweb.
+/!\ The gitweb folder and user's home folder must be readable by the webserver user.
PATH_INFO usage
-----------------------
^ permalink raw reply related
* Re: git svn fetch loses data
From: Victor Engmark @ 2009-11-15 9:56 UTC (permalink / raw)
To: Johan 't Hart; +Cc: Sverre Rabbelier, git
In-Reply-To: <4AFF3EB7.5080606@gmail.com>
On Sun, Nov 15, 2009 at 12:35 AM, Johan 't Hart <johanthart@gmail.com> wrote:
> Sverre Rabbelier schreef:
>> On Sat, Nov 14, 2009 at 20:29, Victor Engmark <victor.engmark@gmail.com>
>> wrote:
>>>
>>> Do I need to run something after fetch to see them?
>>
>> Your working copy is probably not up to date anymore, try:
>>
>> $ git rebase git-svn
>>
> Why not just
> $ git svn rebase
> ?
What is the difference between the two?
--
Victor Engmark
^ permalink raw reply
* Re: .gitignore polution
From: Jeff King @ 2009-11-15 9:43 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Git List
In-Reply-To: <fabb9a1e0911141557k5f6b0b8aud48b95784a9da4e3@mail.gmail.com>
On Sun, Nov 15, 2009 at 12:57:31AM +0100, Sverre Rabbelier wrote:
> I usually compile git from next (sometimes pu to test out a new
> feature), and when I then switch back to a development branch (usually
> based off master) I get something like this:
>
> $ git status
> # On branch remote-helpers
> # Untracked files:
> # (use "git add <file>..." to include in what will be committed)
> #
> # git-http-backend
> # git-notes
> # git-remote-hg
> # test-index-version
>
> Now I can easily do 'git clean -f', but it's somewhat annoying. How do
> other developers deal with this?
I use "git clean". :)
The other option is to mark them for ignore outside of the
branch-specific ignore:
git ls-files -o --exclude-standard >>.git/info/exclude
-Peff
^ permalink raw reply
* Re: [PATCHv3] Add branch management for releases to gitworkflows
From: Junio C Hamano @ 2009-11-15 9:14 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: rocketraman, git, trast, gitster
In-Reply-To: <20091114071946.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Other minor clarifications in the text are also included in this change:
>
> * Clarify "building documentation" a bit; the post-update hook
> creates preformatted documentation pages.
>
> * The latest documentation set uses "fast-forward", not "fast
> forward".
>
> * Call 'next' branch an integration branch, not a "testing" branch, to be
> consistent with the Graduation section.
> ...
> Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
> ---
Your changes look mostly fine.
I obviously agree with the removal of "use 'branch -f' to update maint"
which I said I do not want to see in the document number of times.
There is another thing; I didn't notice it in the earlier round but the
way I actually rotate 'master', 'maint' and the 'maint-one-rev-old' is
similar to how Thomas mentioned. That is:
================================
git checkout master
git log ..maint ;# should see nothing
git tag ... ;# release task
git checkout maint
git branch maint-X.Y.Z ;# without -f so that I can catch a typo to
clobber what already exists
git merge --ff-only master
================================
My fingers are trained to type "git merge" before --ff-only was invented,
so I actually do use "merge master" without --ff-only option in the last
step, but if I see a real merge created with that command, I notice it and
treat it as a grave error, so in the Recipe we should say --ff-only.
^ permalink raw reply
* Re: [PATCH] Define $PERL_PATH in test-lib.sh
From: Junio C Hamano @ 2009-11-15 9:12 UTC (permalink / raw)
To: Philippe Bruhat (BooK); +Cc: Jeff King, git
In-Reply-To: <20091110122315.GA15906@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Tue, Nov 10, 2009 at 11:46:51AM +0100, Philippe Bruhat (BooK) wrote:
> (snip)
> Will this work if I just have PERL_PATH in my config.mak in the root
> directory? Should we be adding PERL_PATH to the generated
> GIT-BUILD-OPTIONS file in the root, which gets sourced by test-lib?
>
> Something like the following (completely untested) patch?
Philippe, could you please help getting this topic unstuck with a "it
works" or "it doesn't and here is a better solution"?
> diff --git a/Makefile b/Makefile
> index a10a60c..b9a8145 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1643,6 +1643,7 @@ GIT-CFLAGS: .FORCE-GIT-CFLAGS
> # and the first level quoting from the shell that runs "echo".
> GIT-BUILD-OPTIONS: .FORCE-GIT-BUILD-OPTIONS
> @echo SHELL_PATH=\''$(subst ','\'',$(SHELL_PATH_SQ))'\' >$@
> + @echo PERL_PATH=\''$(subst ','\'',$(PERL_PATH_SQ))'\' >$@
> @echo TAR=\''$(subst ','\'',$(subst ','\'',$(TAR)))'\' >>$@
> @echo NO_CURL=\''$(subst ','\'',$(subst ','\'',$(NO_CURL)))'\' >>$@
> @echo NO_PERL=\''$(subst ','\'',$(subst ','\'',$(NO_PERL)))'\' >>$@
^ permalink raw reply
* Re: [PATCH 2/2] pack documentation review updates
From: Junio C Hamano @ 2009-11-15 9:11 UTC (permalink / raw)
To: Scott Chacon
Cc: Nanako Shiraishi, Junio C Hamano, Sverre Rabbelier,
Shawn O. Pearce, git list
In-Reply-To: <d411cc4a0911110205j6f3afedw57d2c56fb28dc20@mail.gmail.com>
Scott Chacon <schacon@gmail.com> writes:
> On Wed, Nov 11, 2009 at 9:19 AM, Nanako Shiraishi <nanako3@lavabit.com> wrote:
>> Update Scott's protocol document according to review comments given by Junio.
>>
>> * name of "%00" byte is NUL not null;
>> ...
>> * don't unnecessarily say "SHOULD NOT" when existing servers can satisify
>> "MUST NOT";
>> ...
>
> I was _just_ working on this yesterday and had gotten about halfway
> through - I'm traveling a lot right now, so I'm a bit behind. This
> looks good, thanks for taking the time Nanako.
>
> Signed-off-by: Scott Chacon <schacon@gmail.com>
Thanks, both.
I had some doubts about the "SHOULD NOT"/"MUST" on obj-id myself, but if
you are Ok with the change, I wouldn't complain ;-).
Will squash this in.
^ permalink raw reply
* Re: [PATCH] Re: Clarify documentation on the "ours" merge strategy.
From: Junio C Hamano @ 2009-11-15 9:10 UTC (permalink / raw)
To: Nanako Shiraishi
Cc: Peter Krefting, Junio C Hamano, Thomas Rast, Nicolas Sebrecht,
Baz, Git Mailing List, Johannes.Schindelin, B.Steinbrink
In-Reply-To: <20091114111259.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Quoting Peter Krefting <peter@softwolves.pp.se>
>
>> The web tree checkout script uses rebase to avoid introducing merge
>> commits every time the blog comment is updated, as it in 99 % of cases
>> is unrelated to any other changes found in the central repo.
>>
>> In the few cases where the blog comment update from the web tree
>> conflicts with a change in the central repo, I want the "git pull
>> --rebase" call to overwrite any changes in the central repo with my
>> changes in the web tree (meaning that I would later have to manually
>> re-delete the spam comments, but I can live with that).
>
> That sounds like "-Xours" merge option that was discussed some time
> ago. See
>
> http://thread.gmane.org/gmane.comp.version-control.git/76650/focus=89021
>
> I remember that Junio and Petr were against it because it would
> encourage a bad workflow. Dscho was against the syntax used to
> pass the options also.
Yeah, Björn seems to speculate the same.
Even though I still think -Xours/-Xtheirs are nonsense options in the
context of source code management, I suspect that they might be exactly
what Peter needs in this situation.
As long as the changes made on the "web tree" side only consist of
user-generated blog contents and never touch framework code that is
controlled by his "central repo" side (and that condition should
hold true; otherwise Peter's web site is seriously broken from the
security point of view and no SCM can fix that), running a merge with
the fabled -Xours option in the "web tree" to slurp in the changes made on
the "central repo" side does not sound like an unreasonable thing to do.
^ permalink raw reply
* Re: [PATCH] Update 'git remote' usage and man page to match.
From: Junio C Hamano @ 2009-11-15 9:08 UTC (permalink / raw)
To: Tim Henigan; +Cc: Nanako Shiraishi, gitster, git
In-Reply-To: <32c343770911142034j6cf10e36jbd031c49119973c8@mail.gmail.com>
Tim Henigan <tim.henigan@gmail.com> writes:
> On Fri, Nov 13, 2009 at 5:19 PM, Nanako Shiraishi <nanako3@lavabit.com> wrote:
>>
>> The second change is good but why do you remove -v from the
>> synopsis section? Why is it a good idea? Manual pages for
>> many other commands list --verbose in their synopsis section.
>>
>
> After checking other git operations (fetch, pull, clone, commit, merge, etc)
> I found that none of these other commands document '-v' in the synopsis.
>
> With that in mind, I wondered why it had been listed for 'git remote'. My best
> guess is that only some of the 'git remote' subcommands are affected by '-v'.
> However, to me it still seems better to only mention it as a general option.
> That way if subcommands add/remote support for '-v', the usage string
> and man page don't need to be updated.
>
> Please note that even with the change, '-v' is still printed as one of the
> general options in the usage string. I simply removed it from the synopsis
> section.
You noticed a good issue to address. That is, "git remote -h" output
looks Ok but "git remote add -h" and friends show way suboptimal help.
The current output looks like:
$ git remote add -h
usage: git remote [-v | --verbose]
or: git remote add [-t <branch>] [-m <master>] [-f] [--mirror] <name>
<url>
or: git remote rename <old> <new>
or: git remote rm <name>
or: git remote set-head <name> [-a | -d | <branch>]
or: git remote show [-n] <name>
or: git remote prune [-n | --dry-run] <name>
or: git remote [-v | --verbose] update [-p | --prune] [group]
add specific options
-f, --fetch fetch the remote branches
-t, --track <branch> branch(es) to track
-m, --master <branch>
master branch
--mirror no separate remotes
As the user already knows "add" is the subcommand she is interested in,
this is insane.
My preference is:
(1) to drop your change to the synopsis section ("git remote -v" is a
valid way to get more verbose information, isn't it?);
(2) to keep the current output of "git remote -h";
(3) to drop the general description section altogether from "git remote
add -h" output;
I think this is related to a bigger issue of how we generally would want
to show help in response to "-h", and also in the manual pages.
http://thread.gmane.org/gmane.comp.version-control.git/129399/focus=129424
http://thread.gmane.org/gmane.comp.version-control.git/129906/focus=130646
^ 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