* Re: Recording merges after repo conversion
From: Johan Herland @ 2007-10-31 17:08 UTC (permalink / raw)
To: git
Cc: Linus Torvalds, Johannes Schindelin, Peter Karlsson, Lars Hjemli,
Benoit SIGOURE
In-Reply-To: <alpine.LFD.0.999.0710310928490.3340@woody.linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 2698 bytes --]
On Wednesday 31 October 2007, Linus Torvalds wrote:
> On Wed, 31 Oct 2007, Johannes Schindelin wrote:
> > Seriously, your proposal does not make any sense. If you have to set up a
> > hook to get the _sane_ behaviour, something is really wrong. So I do not
> > really understand why you brought up this idea here and now.
>
> Well, I think this does kind of have some commonality with another issue
> that has come up before: git clone only clones the really core repository
> data.
>
> That's generally a big feature, and I think it's absolutely the correct
> thing to do.
>
> But I can also see that sometimes, you might want to clone more than the
> actual repository, and get things like SVN metadata, branch reflogs,
> various hooks and all the config options too.
>
> Of course, in practice, at least right now, the right thing to do for that
> is to just do a recursive filesystem copy and then a "git status", but I
> think the background here is that some people simply do end up wanting to
> transfer more infrastructure than just the actual repository data.
>
> One thing to note: one reason for *not* allowing that is that incremental
> upgrades of non-repo data is obviously not possible. You might be able to
> *clone* a repo with config info and other metadata (if nothing else, then
> by just doing that raw filesystem copy), but you will never ever be able
> to _fetch_ the updates, because they aren't part of the core repository,
> and aren't versioned.
>
> So I think I can understand why some people would want to do things like
> this, but I do think it's broken. Yes, you can make the grafts file (or
> the config file) be part of the repo, and even just add a symlink to your
> .git/ directory, but it's simply not a very good model.
>
> So I think it always does end up breaking (other people might rebase, and
> break your grafts, or just not want them in the first place, or they don't
> care about the same things, and mess up "your" configuration etc etc). So
> the git repo layout is designed to have the minimally required shared
> state, and not anything else.
I agree that sharing the "metainfo" (i.e. config, grafts, hooks, reflogs,
rerere magic, etc.) of the repo is not something git should do in the general
case.
But in some specific workflows (e.g. in-house, centralized workflows), I think
it makes sense to coordinate/share some of this info between repos. But in
that case, I guess such coordination/sharing can be done by special-purpose
tools built on top of git (e.g. in-house admin scripts).
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: cogito and remote#branch, was Re: [PATCH] Git homepage: remove all the references to Cogito
From: Petr Baudis @ 2007-10-31 17:09 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: Johannes Schindelin, Paolo Ciarrocchi, git
In-Reply-To: <2c6b72b30710161516j5c029847r1acb3ce2d88344a1@mail.gmail.com>
On Wed, Oct 17, 2007 at 12:16:25AM +0200, Jonas Fonseca wrote:
> On 10/16/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On Tue, 16 Oct 2007, Petr Baudis wrote:
> > > I'm not sure this is good idea, Cogito is still quite frequently used
> > > and it should be documented that it exists.
> >
> > I agree. But maybe it could be marked as unmaintained? Maybe someone
> > steps up to maintain it. Or, even better, comes up with a list of "this
> > is what I like do regularly with cogito, but there's no easy way with core
> > git" issues.
>
> One thing that I occasionally miss is
>
> cg-export /path/to/directory/
>
> And yes, I know it can be accomplished via "obscurities" like
> git-archive+tar (or worse git-checkout-index) but I think having
> an easy way to checkout to a directory could be great (and possibly
> with the ability to apply substitutions with the recent discussion).
>
> Else, I am really looking forward for the option parser work to provide
> an easy way to list options. I found it very useful with Cogito.
> Also, most of the "status" commands in Cogito seemd to provide a richer
> default output geared towards human consumption. For example stuff like
> git-branch -v and git remote -v flags would have been the default for
> Cogito ... I think.
A "me too" mail for once...
I fully second this. cg-export is one of the Cogito commands I still use
frequently. I wonder if there is any obvious piece of Git command set we
could glue this on (so that we don't introduce Yet Another Command)... I
think cg-export is better-named here than git-archive. ;-)
And some command in Git to easily get the equivalent of cg-status -g
output is something I probably miss the most in Git now. (Originally I
was about to say that I just miss an equivalent of cg-status, but
thinking about it, most of the time I'm interested only in either -g
(long branch info) or -w (git status output)).
--
Petr "Pasky" Baudis
We don't know who it was that discovered water, but we're pretty sure
that it wasn't a fish. -- Marshall McLuhan
^ permalink raw reply
* Re: Recording merges after repo conversion
From: Linus Torvalds @ 2007-10-31 16:43 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Johan Herland, git, Peter Karlsson, Lars Hjemli, Benoit SIGOURE
In-Reply-To: <Pine.LNX.4.64.0710311553510.4362@racer.site>
On Wed, 31 Oct 2007, Johannes Schindelin wrote:
>
> Seriously, your proposal does not make any sense. If you have to set up a
> hook to get the _sane_ behaviour, something is really wrong. So I do not
> really understand why you brought up this idea here and now.
Well, I think this does kind of have some commonality with another issue
that has come up before: git clone only clones the really core repository
data.
That's generally a big feature, and I think it's absolutely the correct
thing to do.
But I can also see that sometimes, you might want to clone more than the
actual repository, and get things like SVN metadata, branch reflogs,
various hooks and all the config options too.
Of course, in practice, at least right now, the right thing to do for that
is to just do a recursive filesystem copy and then a "git status", but I
think the background here is that some people simply do end up wanting to
transfer more infrastructure than just the actual repository data.
One thing to note: one reason for *not* allowing that is that incremental
upgrades of non-repo data is obviously not possible. You might be able to
*clone* a repo with config info and other metadata (if nothing else, then
by just doing that raw filesystem copy), but you will never ever be able
to _fetch_ the updates, because they aren't part of the core repository,
and aren't versioned.
So I think I can understand why some people would want to do things like
this, but I do think it's broken. Yes, you can make the grafts file (or
the config file) be part of the repo, and even just add a symlink to your
.git/ directory, but it's simply not a very good model.
So I think it always does end up breaking (other people might rebase, and
break your grafts, or just not want them in the first place, or they don't
care about the same things, and mess up "your" configuration etc etc). So
the git repo layout is designed to have the minimally required shared
state, and not anything else.
Linus
^ permalink raw reply
* Re: Recording merges after repo conversion
From: Johannes Schindelin @ 2007-10-31 15:57 UTC (permalink / raw)
To: Johan Herland; +Cc: git, Peter Karlsson, Lars Hjemli, Benoit SIGOURE
In-Reply-To: <200710311621.09845.johan@herland.net>
Hi,
On Wed, 31 Oct 2007, Johan Herland wrote:
> Well, to a certain degree (and depending on your level of paranoia),
> you're always responsible for the code entering your own repo, and you
> could always set up a hook disallowing ".gitgrafts" (or whatever it
> would be called) from entering your repo.
Yeah, right. And you could also stay in an oxygen tent the whole time to
avoid being infected with some virus.
Seriously, your proposal does not make any sense. If you have to set up a
hook to get the _sane_ behaviour, something is really wrong. So I do not
really understand why you brought up this idea here and now.
I understand that you wanted to end this discussion, but I could _not_ let
your statement stand uncorrected.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Implement sending mails over TLS in git-send-email.
From: Simon Sasburg @ 2007-10-31 15:50 UTC (permalink / raw)
To: git; +Cc: Simon Sasburg
Signed-off-by: Simon Sasburg <Simon.Sasburg@gmail.com>
---
With this patch I was able to use git-send-email to send mail through gmail's
smpt server, which uses TLS.
Net::SMTP::TLS apparently doesn't do proper error handling, so the TLS
codepath is essentially not checked for errors. I'm not really happy with this.
The Net::SMTP::TLS docs say this about error handling:
>ERROR HANDLING:
>This module will croak in the event of an SMTP error. Should you wish to handle this gracefully in your application, you may wrap your mail transmission in an eval {} block and check $@ afterward.
But my perl knowledge is way too limited for me to know if/how that helps.
(This patch was just made by copying existing code and fiddling with it untill it did what i wanted)
Maybe someone who knows more about perl than I do can finish this?
Or give an estimate how difficult it would be for me to fix after pointing me in the right direction?
(I'm willing to learn a little perl for this, but not too much :-p)
---
git-send-email.perl | 64 +++++++++++++++++++++++++++++++++-----------------
1 files changed, 42 insertions(+), 22 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 96051bc..5cf220f 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -88,6 +88,9 @@ Options:
--smtp-ssl If set, connects to the SMTP server using SSL.
+ --smtp-tls If set, connects to the SMTP server using TLS.
+ Overrides --smtp-ssl.
+
--suppress-from Suppress sending emails to yourself if your address
appears in a From: line. Defaults to off.
@@ -175,7 +178,7 @@ my ($quiet, $dry_run) = (0, 0);
# Variables with corresponding config settings
my ($thread, $chain_reply_to, $suppress_from, $signed_off_cc, $cc_cmd);
-my ($smtp_server, $smtp_server_port, $smtp_authuser, $smtp_authpass, $smtp_ssl);
+my ($smtp_server, $smtp_server_port, $smtp_authuser, $smtp_authpass, $smtp_ssl, $smtp_tls);
my ($identity, $aliasfiletype, @alias_files, @smtp_host_parts);
my %config_bool_settings = (
@@ -184,6 +187,7 @@ my %config_bool_settings = (
"suppressfrom" => [\$suppress_from, 0],
"signedoffcc" => [\$signed_off_cc, 1],
"smtpssl" => [\$smtp_ssl, 0],
+ "smtptls" => [\$smtp_tls, 0],
);
my %config_settings = (
@@ -213,6 +217,7 @@ my $rc = GetOptions("sender|from=s" => \$sender,
"smtp-user=s" => \$smtp_authuser,
"smtp-pass=s" => \$smtp_authpass,
"smtp-ssl!" => \$smtp_ssl,
+ "smtp-tls!" => \$smtp_tls,
"identity=s" => \$identity,
"compose" => \$compose,
"quiet" => \$quiet,
@@ -613,31 +618,46 @@ X-Mailer: git-send-email $gitversion
die "The required SMTP server is not properly defined."
}
- if ($smtp_ssl) {
- $smtp_server_port ||= 465; # ssmtp
- require Net::SMTP::SSL;
- $smtp ||= Net::SMTP::SSL->new($smtp_server, Port => $smtp_server_port);
+ if ($smtp_tls) {
+ require Net::SMTP::TLS;
+ $smtp ||= Net::SMTP::TLS->new(
+ $smtp_server,
+ Port => $smtp_server_port,
+ User => $smtp_authuser,
+ Password=> $smtp_authpass);
+
+ $smtp->mail( $raw_from );
+ $smtp->to( @recipients );
+ $smtp->data;
+ $smtp->datasend("$header\n$message");
+ $smtp->dataend();
}
else {
- require Net::SMTP;
- $smtp ||= Net::SMTP->new((defined $smtp_server_port)
- ? "$smtp_server:$smtp_server_port"
- : $smtp_server);
- }
+ if ($smtp_ssl) {
+ require Net::SMTP::SSL;
+ $smtp ||= Net::SMTP::SSL->new($smtp_server, Port => $smtp_server_port);
+ }
+ else {
+ require Net::SMTP;
+ $smtp ||= Net::SMTP->new((defined $smtp_server_port)
+ ? "$smtp_server:$smtp_server_port"
+ : $smtp_server);
+ }
- if (!$smtp) {
- die "Unable to initialize SMTP properly. Is there something wrong with your config?";
- }
+ if (!$smtp) {
+ die "Unable to initialize SMTP properly. Is there something wrong with your config?";
+ }
- if ((defined $smtp_authuser) && (defined $smtp_authpass)) {
- $smtp->auth( $smtp_authuser, $smtp_authpass ) or die $smtp->message;
+ if ((defined $smtp_authuser) && (defined $smtp_authpass)) {
+ $smtp->auth( $smtp_authuser, $smtp_authpass ) or die $smtp->message;
+ }
+ $smtp->mail( $raw_from ) or die $smtp->message;
+ $smtp->to( @recipients ) or die $smtp->message;
+ $smtp->data or die $smtp->message;
+ $smtp->datasend("$header\n$message") or die $smtp->message;
+ $smtp->dataend() or die $smtp->message;
+ $smtp->ok or die "Failed to send $subject\n".$smtp->message;
}
- $smtp->mail( $raw_from ) or die $smtp->message;
- $smtp->to( @recipients ) or die $smtp->message;
- $smtp->data or die $smtp->message;
- $smtp->datasend("$header\n$message") or die $smtp->message;
- $smtp->dataend() or die $smtp->message;
- $smtp->ok or die "Failed to send $subject\n".$smtp->message;
}
if ($quiet) {
printf (($dry_run ? "Dry-" : "")."Sent %s\n", $subject);
@@ -651,7 +671,7 @@ X-Mailer: git-send-email $gitversion
print "Sendmail: $smtp_server ".join(' ',@sendmail_parameters)."\n";
}
print "From: $sanitized_sender\nSubject: $subject\nCc: $cc\nTo: $to\n\n";
- if ($smtp) {
+ if ($smtp && !$smtp_tls) {
print "Result: ", $smtp->code, ' ',
($smtp->message =~ /\n([^\n]+\n)$/s), "\n";
} else {
--
1.5.3.4.498.g9c514
^ permalink raw reply related
* Re: remote#branch
From: Linus Torvalds @ 2007-10-31 15:28 UTC (permalink / raw)
To: David Kastrup; +Cc: Jakub Narebski, git
In-Reply-To: <85lk9jzsxb.fsf@lola.goethe.zz>
On Wed, 31 Oct 2007, David Kastrup wrote:
>
> I can click on links in my mail reader, and the above is not recognized
> as one. <URL:http://host/git repo with spaces in the path> would likely
> work.
I don't think this whole discussion is relevant at all.
Why?
Because we don't care! This is *exactly* why I brought up the whole
discussion about "interoperability with a web browser", and pointed out
that there is no such thing *anyway*, since a GIT URL is generally not
suitable for browsing _regardless_ of any encoding issues!
So it doesn't matter one whit if a mail client recognizes GIT URL's or
not! Because the mail client cannot do the right thing with them anyway,
and would generally think that it's something that it should highlight so
that you can browse it!
Besides, you generally shouldn't use http for git URL's in the first
place, and they are very much a secondary citizen. Yes, some people use
them because they have firewall issues, and they *work*, but giving them
as examples of GIT URL's and discussing them as it they were a big deal is
just *stupid* when no other - more realistic - git url works that way
anyway.
This was the whole and only point of my "interoperability" thing. The GIT
URL's - even when they are perfectly well-formed URL's (which is basically
100% of the time, since no current git server tends to put things like
spaces in the path anyway) - are simply in a different "space" than most
other URL's.
You cannot feed them to a web browser or a file browser anyway, since the
URL is actually mal-formed (on purpose) in *another* and more fundamental
way: it doesn't say what the "application domain" is, since it basically
just assumes that the application domain is git, and the "scheme" part of
the URL really talks only about the _protocol_, not about the fact that
it's a git thing.
So if you wanted to be inter-operable, you'd have add the "git" part to
the scheme, and do the (insane, in my opinion) cogito thing with
"git+http://xyz.hjashja/" thing!
See? Otherwise no non-git program could understand *anyway* that it's a
git address, and not meant to be some html thing.
So to summarise:
- the only way to make git interoperate would be to be user-UNfriendly
with stupid markers that no git program really needs or wants, and by
making the escaping depend on the form of the GIT URL.
But hey, if people want to screw up git even more, and make the "git+"
crap also encode the address, I don't care. I would never *ever* use the
"git+xyz://" forms anyway. They're stupid and useless, but if you want to
have programs automatically do something magical about git url's, you'd
need that "git+" thing.
Personally, I think it's a much better idea to just be git-specific.
Because realistically, nobody is ever going to really be anything else
anyway. There is nothing you can sanely do with a git link, unless it's
something very git specific and conscious in the first place!
Linus
^ permalink raw reply
* git-commit broken with GIT_INDEX_FILE
From: Tim Janik @ 2007-10-31 15:02 UTC (permalink / raw)
To: git
hey All.
i'm maintaining my own git porcelainen, and as part of that had to
(re-)implement my own commit command:
http://blogs.gnome.org/timj/2007/10/13/13102007-yummy-yummy-porcelain-version-08/
i've read through git-commit and cg-commit, and would really like to avoid
reimplementing the hook and utf8 encoding handling. thus, my tool calls
git-commit once it has created an index file with all the files that
need comitting.
ideally, it'd construct a temporary index, e.g. $GIT_DIR/next-index$$ and
then invoke:
GIT_INDEX_FILE=$GIT_DIR/next-index$$ git-commit -F commitmsg.txt
this is not working as expected however.
when GIT_INDEX_FILE=tmpindex is specified for git-commit-1.5.3.4, it will
construct a commit message for tmpindex, but it'll still use the standard
index file $GIT_DIR/index for git-write-tree.
(so my current implementation saves and restores the standard index file
around committs.)
for consistent commit messages, the index file used for commit message
construction should be the same index used for git-write-tree.
ideally however, GIT_INDEX_FILE=tmpindex git-commit would work correctly
in using tmpindex for git-write-tree as well.
---
ciaoTJ
^ permalink raw reply
* Re: Recording merges after repo conversion
From: Johan Herland @ 2007-10-31 15:21 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin, Peter Karlsson, Lars Hjemli, Benoit SIGOURE
In-Reply-To: <Pine.LNX.4.64.0710311503120.4362@racer.site>
[-- Attachment #1: Type: text/plain, Size: 1162 bytes --]
On Wednesday 31 October 2007, Johannes Schindelin wrote:
> On Wed, 31 Oct 2007, Johan Herland wrote:
> > On Wednesday 31 October 2007, Johannes Schindelin wrote:
> > > All this does not change the fact that installing a graft and 'git gc
> > > --prune'ing gets rid of the old history. D'oh.
> >
> > So will rebasing and --prune'ing, or pulling a rebased branch and
> > --prune'ing. Git already gives you _plenty_ of different ropes to hang
> > yourself with. The question is whether adding yet another one is worth
> > it.
>
> But that is not the question here. The question here is: are users
> allowed to hang _others_? I say: no.
Well, to a certain degree (and depending on your level of paranoia), you're
always responsible for the code entering your own repo, and you could always
set up a hook disallowing ".gitgrafts" (or whatever it would be called) from
entering your repo.
But taking this (and everything else that's been said) into account, I totally
agree with you that adding this feature would open up a _massive_ can of
worms.
EOD
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH 5/8] push, send-pack: support pushing HEAD to real ref name
From: Steffen Prohaska @ 2007-10-31 15:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wbfufbo.fsf@gitster.siamese.dyndns.org>
On Oct 28, 2007, at 9:58 PM, Junio C Hamano wrote:
> Steffen Prohaska <prohaska@zib.de> writes:
>
>> On Oct 28, 2007, at 5:03 PM, Junio C Hamano wrote:
>> ...
>>> An alternative, just to let me keep my nicer public image by
>>> pretending to be constructive ;-)
>>>
>>> Introduce a configuration "remote.$name.push_default" whose
>>> value can be a list of refs. Teach the push command without
>>> refspecs:
>>>
>>> $ git push
>>> $ git push $remote
>>>
>>> to pretend as if the listed refspecs are given, instead of the
>>> traditional "matching branches" behaviour.
>>>
>>> Then, introduce another option
>>>
>>> $ git push --matching
>>> $ git push --matching $remote
>>>
>>> to override that configuration, if set, so that the user who
>>> usually pushes only the selected branches can use the "matching
>>> branches" behaviour when needed.
>>>
>>> Along with your earlier "git push $remote HEAD" patch, this will
>>> allow you to say:
>>>
>>> [remote "origin"]
>>> push_default = HEAD
>>>
>>> and your
>>>
>>> $ git push
>>>
>>> will push only the current branch.
>>
>> Sounds reasonable; but it is more work. I'm not starting to
>> implement this today.
>
> Take your time; nobody is in a hurry.
>
> If somebody usually uses "matching" behaviour, i.e. without
> remote.$name.push_default configuration, but wants to push only
> the current branch as a one-shot operation, we can obviously use
> "git push $remote HEAD". But to be complete, it may make sense
> to have another option
>
> $ git push --current
>
> that lets you omit $remote (and default to the value configured
> with branch.$name.remote).
Here is an alternative proposal.
The idea is that in a workflow based on a shared repository
git pull and git push should be 'more' symmetric than they are
in a pull-only based workflow. The integration of changes is
'more' direct. Working against a shared repository may require
to integrate new changes before pushing. Changes are also
pushed directly to the remote branch you originally branched
off. Both is different from a pull-only workflow, where I first
push my changes to a privately owned but publicly readable repo
and someone else does the integration by pulling from there.
The branch in the shared repository serves as the single
'integration' branch. One can use 'git branch --track' to set
up local branches that automatically merge changes from the
shared 'integration' branch. That is git pull without further
arguments is the right command to integrate changes from the
shared branch to the local branch. (git provides more advanced
ways, but git pull is simple and in principle does the right
thing.)
What is missing is a simple way to 'push' local changes back
to shared integration branch in the remote repository. This
can be seen as a 'symmetric' operation to pulling. So, git push
should do the right thing. And the right thing is pushing the
current branch to the shared 'integration' branch.
The automerge behaviour stores information in branch.$name.remote
and branch.$name.merge that provide sufficient information to
make "git pull" the equivalent of
git pull <remoteURL> <remoteref>
where <remoteURL> is the full URL of the remote stored in
branch.$name.remote, and <remoteref> is the value of
branch.$name.merge.
A 'symmetric' push command would push the current branch to the
remote head it originally was branched off, that is
git push <remoteURL> <currentbranch>:<remoteref>
Now, the proposal is
- add a configuration variable branch.$name.push
- change git push to check if the push configuration variable
is set for the current branch $name, and if so run the
equivalent of
git push branch.$name.remote $name:branch.$name.push
- teach git branch a flag --push/--no-push that sets up
branch.$name.push. Add branch.autosetuppush configuration
flag to configure if --push or --no-push is the default.
(maybe we need better names here).
This breaks the symmetry between git fetch/git push and
replaces it with a symmetry between git pull/git push for some
branches. I believe this might be the right thing to do for
a workflow based on shared repos.
Steffen
^ permalink raw reply
* Re: Recording merges after repo conversion
From: Johannes Schindelin @ 2007-10-31 15:03 UTC (permalink / raw)
To: Johan Herland; +Cc: git, Peter Karlsson, Lars Hjemli, Benoit SIGOURE
In-Reply-To: <200710311537.30384.johan@herland.net>
Hi,
On Wed, 31 Oct 2007, Johan Herland wrote:
> On Wednesday 31 October 2007, Johannes Schindelin wrote:
>
> > All this does not change the fact that installing a graft and 'git gc
> > --prune'ing gets rid of the old history. D'oh.
>
> So will rebasing and --prune'ing, or pulling a rebased branch and
> --prune'ing. Git already gives you _plenty_ of different ropes to hang
> yourself with. The question is whether adding yet another one is worth
> it.
But that is not the question here. The question here is: are users
allowed to hang _others_? I say: no.
Ciao,
Dscho
^ permalink raw reply
* Re: Recording merges after repo conversion
From: Johan Herland @ 2007-10-31 14:37 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin, Peter Karlsson, Lars Hjemli, Benoit SIGOURE
In-Reply-To: <Pine.LNX.4.64.0710311340500.4362@racer.site>
[-- Attachment #1: Type: text/plain, Size: 1718 bytes --]
On Wednesday 31 October 2007, Johannes Schindelin wrote:
> On Wed, 31 Oct 2007, Johan Herland wrote:
> > On Wednesday 31 October 2007, Johannes Schindelin wrote:
> > > On Wed, 31 Oct 2007, Peter Karlsson wrote:
> > > > Johannes Schindelin:
> > > > > Why should it? This would contradict the whole "a commit sha1
> > > > > hashes the commit, and by inference the _whole_ history"
> > > > > principle.
> > > >
> > > > Does it?
> > >
> > > Yes! Of course! If what you want becomes possible, I could make an
> > > evil change in history long gone, and slip it by you. You could not
> > > even see the history which changed.
> >
> > Well, technically, if the grafts file was part of the repo, you wouldn't
> > be able to change the (in-tree) grafts file without affecting the SHA1
> > of HEAD. In other words, given a commit SHA1 sum, you can be sure that
> > someone else who checks out the same commit (and has no local
> > modification to their grafts file) will see exactly the same history as
> > you do.
>
> All this does not change the fact that installing a graft and 'git gc
> --prune'ing gets rid of the old history. D'oh.
So will rebasing and --prune'ing, or pulling a rebased branch and --prune'ing.
Git already gives you _plenty_ of different ropes to hang yourself with. The
question is whether adding yet another one is worth it.
> Automatically installing grafts is wrong.
I tend to agree with you here, because the possibility for massive confusion
is huge, but that doesn't deny the fact that, if used properly (and that's a
_big_ 'if'), this is a very powerful feature.
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH 1/1] Add --first-parent support to interactive rebase.
From: Dmitry Potapov @ 2007-10-31 14:36 UTC (permalink / raw)
To: Karl Hasselström
Cc: Björn Steinbrink, Junio C Hamano, Johannes.Schindelin, git
In-Reply-To: <20071031140028.GA30207@diana.vm.bytemark.co.uk>
On Wed, Oct 31, 2007 at 03:00:28PM +0100, Karl Hasselström wrote:
> On 2007-10-31 16:43:58 +0300, Dmitry Potapov wrote:
>
> > I believe that the issue is with Junio's mail client. Indeed, the
> > context encoding for the mail *body* was specified as 8859-1, but
> > that should have none effect on fields in the mail header, because
> > any field is the header should be either printable ASCII or encoded
> > to contain only ASCII characters as specified in RFC 1522:
>
> Yes. But it's the body that's been mangled -- specifically, the
> Sign-off line.
Hmm... I looked at the mail again and I cannot see where 8859-1 is
specified. It seems that context encoding is not specified at all.
Of course, it is incorrect to use non ASCII characters in a mail
without specifying encoding. Apparently, because I use utf-8 in the
terminal, the Sign-off line displays correctly for me, so I did not
notice the problem. Sorry for the noise...
Dmitry
^ permalink raw reply
* [PATCH] git-gui: Update Japanese strings
From: しらいしななこ @ 2007-10-31 14:12 UTC (permalink / raw)
To: spearce; +Cc: git
This updates the Japanese translation file.
Signed-off-by: しらいしななこ <nanako3@bluebottle.com>
---
po/ja.po | 277 ++++++++++++++++++++++++++++++--------------------------------
1 files changed, 133 insertions(+), 144 deletions(-)
diff --git a/po/ja.po b/po/ja.po
index f65e460..e4491f7 100644
--- a/po/ja.po
+++ b/po/ja.po
@@ -9,7 +9,7 @@ msgstr ""
"Project-Id-Version: git-gui\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2007-10-10 04:04-0400\n"
-"PO-Revision-Date: 2007-08-14 18:49+0900\n"
+"PO-Revision-Date: 2007-10-31 16:23+0900\n"
"Last-Translator: しらいし ななこ <nanako3@bluebottle.com>\n"
"Language-Team: Japanese\n"
"MIME-Version: 1.0\n"
@@ -19,12 +19,12 @@ msgstr ""
#: git-gui.sh:41 git-gui.sh:634 git-gui.sh:648 git-gui.sh:661 git-gui.sh:744
#: git-gui.sh:763
msgid "git-gui: fatal error"
-msgstr ""
+msgstr "git-gui: 致命的なエラー"
#: git-gui.sh:595
-#, fuzzy, tcl-format
+#, tcl-format
msgid "Invalid font specified in %s:"
-msgstr "gui.%s に無効なフォントが指定されています:"
+msgstr "%s に無効なフォントが指定されています:"
#: git-gui.sh:620
msgid "Main Font"
@@ -66,9 +66,8 @@ msgid "Git directory not found:"
msgstr "Git ディレクトリが見つかりません:"
#: git-gui.sh:860
-#, fuzzy
msgid "Cannot move to top of working directory:"
-msgstr "変な .git ディレクトリは使えません"
+msgstr "作業ディレクトリの最上位に移動できません"
#: git-gui.sh:867
msgid "Cannot use funny .git directory:"
@@ -158,7 +157,6 @@ msgid "Branch"
msgstr "ブランチ"
#: git-gui.sh:1794 lib/choose_rev.tcl:547
-#, fuzzy
msgid "Commit@@noun"
msgstr "コミット"
@@ -167,9 +165,8 @@ msgid "Merge"
msgstr "マージ"
#: git-gui.sh:1798 lib/choose_rev.tcl:556
-#, fuzzy
msgid "Remote"
-msgstr "リモート:"
+msgstr "リモート"
#: git-gui.sh:1807
msgid "Browse Current Branch's Files"
@@ -301,7 +298,6 @@ msgid "Sign Off"
msgstr "署名"
#: git-gui.sh:1980 git-gui.sh:2296
-#, fuzzy
msgid "Commit@@verb"
msgstr "コミット"
@@ -329,7 +325,7 @@ msgstr "%s について"
#: git-gui.sh:2026
msgid "Preferences..."
-msgstr ""
+msgstr "設定…"
#: git-gui.sh:2034 git-gui.sh:2558
msgid "Options..."
@@ -346,21 +342,19 @@ msgstr "オンライン・ドキュメント"
#: git-gui.sh:2165
#, tcl-format
msgid "fatal: cannot stat path %s: No such file or directory"
-msgstr ""
+msgstr "致命的: パス %s が stat できません。そのようなファイルやディレクトリはありません"
#: git-gui.sh:2198
msgid "Current Branch:"
msgstr "現在のブランチ"
#: git-gui.sh:2219
-#, fuzzy
msgid "Staged Changes (Will Commit)"
msgstr "ステージングされた（コミット予定済の）変更"
#: git-gui.sh:2239
-#, fuzzy
msgid "Unstaged Changes"
-msgstr "変更をコミット予定に入れる"
+msgstr "コミット予定に入っていない変更"
#: git-gui.sh:2286
msgid "Stage Changed"
@@ -448,6 +442,10 @@ msgid ""
"by %s:\n"
"\n"
msgstr ""
+"環境に問題がある可能性があります\n"
+"\n"
+"以下の環境変数は %s が起動する Git サブプロセスによって無視されるでしょう:\n"
+"\n"
#: git-gui.sh:2707
msgid ""
@@ -455,6 +453,9 @@ msgid ""
"This is due to a known issue with the\n"
"Tcl binary distributed by Cygwin."
msgstr ""
+"\n"
+"これは Cygwin で配布されている Tcl バイナリに\n"
+"関しての既知の問題によります"
#: git-gui.sh:2712
#, tcl-format
@@ -466,6 +467,10 @@ msgid ""
"user.email settings into your personal\n"
"~/.gitconfig file.\n"
msgstr ""
+"\n"
+"\n"
+"個人的な ~/.gitconfig ファイル内で user.name と user.email の値を設定\n"
+"するのが、%s の良い代用となります\n"
#: lib/about.tcl:25
msgid "git-gui - a graphical user interface for Git."
@@ -490,50 +495,47 @@ msgstr "%s を読んでいます…"
#: lib/blame.tcl:473
msgid "Loading copy/move tracking annotations..."
-msgstr ""
+msgstr "コピー・移動追跡データを読んでいます…"
#: lib/blame.tcl:493
msgid "lines annotated"
-msgstr ""
+msgstr "行を注釈しました"
#: lib/blame.tcl:674
msgid "Loading original location annotations..."
-msgstr ""
+msgstr "元位置行の注釈データを読んでいます…"
#: lib/blame.tcl:677
msgid "Annotation complete."
-msgstr ""
+msgstr "注釈完了しました"
#: lib/blame.tcl:731
-#, fuzzy
msgid "Loading annotation..."
-msgstr "%s をロード中…"
+msgstr "注釈を読み込んでいます…"
#: lib/blame.tcl:787
msgid "Author:"
-msgstr ""
+msgstr "作者:"
#: lib/blame.tcl:791
-#, fuzzy
msgid "Committer:"
-msgstr "コミット:"
+msgstr "コミット者:"
#: lib/blame.tcl:796
msgid "Original File:"
-msgstr ""
+msgstr "元ファイル"
#: lib/blame.tcl:910
msgid "Originally By:"
-msgstr ""
+msgstr "原作者:"
#: lib/blame.tcl:916
-#, fuzzy
msgid "In File:"
msgstr "ファイル:"
#: lib/blame.tcl:921
msgid "Copied Or Moved Here By:"
-msgstr ""
+msgstr "複写・移動者:"
#: lib/branch_checkout.tcl:14 lib/branch_checkout.tcl:19
msgid "Checkout Branch"
@@ -741,7 +743,7 @@ msgstr "%s から %s をフェッチしています"
#: lib/checkout_op.tcl:127
#, tcl-format
msgid "fatal: Cannot resolve %s"
-msgstr ""
+msgstr "致命的エラー: %s を解決できません"
#: lib/checkout_op.tcl:140 lib/console.tcl:79 lib/database.tcl:31
msgid "Close"
@@ -796,9 +798,9 @@ msgstr ""
"自動的に再スキャンを開始します。\n"
#: lib/checkout_op.tcl:322
-#, fuzzy, tcl-format
+#, tcl-format
msgid "Updating working directory to '%s'..."
-msgstr "作業ディレクトリがありません"
+msgstr "作業ディレクトリを '%s' に更新しています…"
#: lib/checkout_op.tcl:353
#, tcl-format
@@ -827,9 +829,9 @@ msgstr ""
"チを開始してください。"
#: lib/checkout_op.tcl:446
-#, fuzzy, tcl-format
+#, tcl-format
msgid "Checked out '%s'."
-msgstr "チェックアウト"
+msgstr "'%s' をチェックアウトしました"
#: lib/checkout_op.tcl:478
#, tcl-format
@@ -866,244 +868,235 @@ msgstr ""
"起こるはずのないエラーです。あきらめて %s を終了します。"
#: lib/choose_font.tcl:39
-#, fuzzy
msgid "Select"
-msgstr "全て選択"
+msgstr "選択"
#: lib/choose_font.tcl:53
msgid "Font Family"
-msgstr ""
+msgstr "フォント・ファミリー"
#: lib/choose_font.tcl:73
-#, fuzzy
msgid "Font Size"
-msgstr "フォントを小さく"
+msgstr "フォントの大きさ"
#: lib/choose_font.tcl:90
msgid "Font Example"
-msgstr ""
+msgstr "フォント・サンプル"
#: lib/choose_font.tcl:101
msgid ""
"This is example text.\n"
"If you like this text, it can be your font."
msgstr ""
+"これはサンプル文です。\n"
+"このフォントが気に入ればお使いになれます。"
#: lib/choose_repository.tcl:25
msgid "Git Gui"
-msgstr ""
+msgstr "Git GUI"
#: lib/choose_repository.tcl:69 lib/choose_repository.tcl:204
-#, fuzzy
msgid "Create New Repository"
-msgstr "元のリポジトリ"
+msgstr "新しいリポジトリを作る"
#: lib/choose_repository.tcl:74 lib/choose_repository.tcl:291
-#, fuzzy
msgid "Clone Existing Repository"
-msgstr "送り先リポジトリ"
+msgstr "既存リポジトリを複製する"
#: lib/choose_repository.tcl:79 lib/choose_repository.tcl:800
-#, fuzzy
msgid "Open Existing Repository"
-msgstr "送り先リポジトリ"
+msgstr "既存リポジトリを開く"
#: lib/choose_repository.tcl:91
msgid "Next >"
-msgstr ""
+msgstr "次 >"
#: lib/choose_repository.tcl:152
-#, fuzzy, tcl-format
+#, tcl-format
msgid "Location %s already exists."
-msgstr "'%s'というブランチは既に存在します。"
+msgstr "'%s' は既に存在します。"
#: lib/choose_repository.tcl:158 lib/choose_repository.tcl:165
#: lib/choose_repository.tcl:172
-#, fuzzy, tcl-format
+#, tcl-format
msgid "Failed to create repository %s:"
-msgstr "完全にオプションを保存できません:"
+msgstr "リポジトリ %s を作製できません:"
#: lib/choose_repository.tcl:209 lib/choose_repository.tcl:309
msgid "Directory:"
-msgstr ""
+msgstr "ディレクトリ:"
#: lib/choose_repository.tcl:238 lib/choose_repository.tcl:363
#: lib/choose_repository.tcl:834
-#, fuzzy
msgid "Git Repository"
-msgstr "リポジトリ"
+msgstr "GIT リポジトリ"
#: lib/choose_repository.tcl:253 lib/choose_repository.tcl:260
-#, fuzzy, tcl-format
+#, tcl-format
msgid "Directory %s already exists."
-msgstr "'%s'というブランチは既に存在します。"
+msgstr "ディレクトリ '%s' は既に存在します。"
#: lib/choose_repository.tcl:265
-#, fuzzy, tcl-format
+#, tcl-format
msgid "File %s already exists."
-msgstr "'%s'というブランチは既に存在します。"
+msgstr "ファイル '%s' は既に存在します。"
#: lib/choose_repository.tcl:286
-#, fuzzy
msgid "Clone"
-msgstr "閉じる"
+msgstr "複製"
#: lib/choose_repository.tcl:299
msgid "URL:"
-msgstr ""
+msgstr "URL:"
#: lib/choose_repository.tcl:319
msgid "Clone Type:"
-msgstr ""
+msgstr "複製方式:"
#: lib/choose_repository.tcl:325
msgid "Standard (Fast, Semi-Redundant, Hardlinks)"
-msgstr ""
+msgstr "標準(高速・中冗長度・ハードリンク)"
#: lib/choose_repository.tcl:331
msgid "Full Copy (Slower, Redundant Backup)"
-msgstr ""
+msgstr "全複写(低速・冗長バックアップ)"
#: lib/choose_repository.tcl:337
msgid "Shared (Fastest, Not Recommended, No Backup)"
-msgstr ""
+msgstr "共有(最高速・非推奨・バックアップ無し)"
#: lib/choose_repository.tcl:369 lib/choose_repository.tcl:418
#: lib/choose_repository.tcl:560 lib/choose_repository.tcl:630
#: lib/choose_repository.tcl:840 lib/choose_repository.tcl:848
-#, fuzzy, tcl-format
+#, tcl-format
msgid "Not a Git repository: %s"
-msgstr "リポジトリが選択されていません。"
+msgstr "Git リポジトリではありません: %s"
#: lib/choose_repository.tcl:405
msgid "Standard only available for local repository."
-msgstr ""
+msgstr "標準方式は同一計算機上のリポジトリにのみ使えます。"
#: lib/choose_repository.tcl:409
msgid "Shared only available for local repository."
-msgstr ""
+msgstr "共有方式は同一計算機上のリポジトリにのみ使えます。"
#: lib/choose_repository.tcl:439
msgid "Failed to configure origin"
-msgstr ""
+msgstr "origin を設定できませんでした"
#: lib/choose_repository.tcl:451
msgid "Counting objects"
-msgstr ""
+msgstr "オブジェクトを数えています"
#: lib/choose_repository.tcl:452
msgid "buckets"
-msgstr ""
+msgstr "バケツ"
#: lib/choose_repository.tcl:476
#, tcl-format
msgid "Unable to copy objects/info/alternates: %s"
-msgstr ""
+msgstr "objects/info/alternates を複写できません: %s"
#: lib/choose_repository.tcl:512
-#, fuzzy, tcl-format
+#, tcl-format
msgid "Nothing to clone from %s."
-msgstr "%s から新しい変更をフェッチしています"
+msgstr "%s から複製する内容はありません"
#: lib/choose_repository.tcl:514 lib/choose_repository.tcl:728
#: lib/choose_repository.tcl:740
msgid "The 'master' branch has not been initialized."
-msgstr ""
+msgstr "'master' ブランチが初期化されていません"
#: lib/choose_repository.tcl:527
msgid "Hardlinks are unavailable. Falling back to copying."
-msgstr ""
+msgstr "ハードリンクが作れないので、コピーします"
#: lib/choose_repository.tcl:539
-#, fuzzy, tcl-format
+#, tcl-format
msgid "Cloning from %s"
-msgstr "%s から %s をフェッチしています"
+msgstr "%s から複製しています"
#: lib/choose_repository.tcl:570
-#, fuzzy
msgid "Copying objects"
-msgstr "データベース圧縮"
+msgstr "オブジェクトを複写しています"
#: lib/choose_repository.tcl:571
msgid "KiB"
-msgstr ""
+msgstr "KiB"
#: lib/choose_repository.tcl:595
#, tcl-format
msgid "Unable to copy object: %s"
-msgstr ""
+msgstr "オブジェクトを複写できません: %s"
#: lib/choose_repository.tcl:605
msgid "Linking objects"
-msgstr ""
+msgstr "オブジェクトを連結しています"
#: lib/choose_repository.tcl:606
msgid "objects"
-msgstr ""
+msgstr "オブジェクト"
#: lib/choose_repository.tcl:614
#, tcl-format
msgid "Unable to hardlink object: %s"
-msgstr ""
+msgstr "オブジェクトをハードリンクできません: %s"
#: lib/choose_repository.tcl:669
msgid "Cannot fetch branches and objects. See console output for details."
-msgstr ""
+msgstr "ブランチやオブジェクトを取得できません。コンソール出力を見て下さい"
#: lib/choose_repository.tcl:680
msgid "Cannot fetch tags. See console output for details."
-msgstr ""
+msgstr "タグを取得できません。コンソール出力を見て下さい"
#: lib/choose_repository.tcl:704
msgid "Cannot determine HEAD. See console output for details."
-msgstr ""
+msgstr "HEAD を確定できません。コンソール出力を見て下さい"
#: lib/choose_repository.tcl:713
#, tcl-format
msgid "Unable to cleanup %s"
-msgstr ""
+msgstr "%s を掃除できません"
#: lib/choose_repository.tcl:719
-#, fuzzy
msgid "Clone failed."
-msgstr "中断に失敗しました。"
+msgstr "複写に失敗しました。"
#: lib/choose_repository.tcl:726
msgid "No default branch obtained."
-msgstr ""
+msgstr "デフォールト・ブランチが取得されませんでした"
#: lib/choose_repository.tcl:737
#, tcl-format
msgid "Cannot resolve %s as a commit."
-msgstr ""
+msgstr "%s をコミットとして解釈できません"
#: lib/choose_repository.tcl:749
-#, fuzzy
msgid "Creating working directory"
-msgstr "作業ディレクトリがありません"
+msgstr "作業ディレクトリを作成しています"
#: lib/choose_repository.tcl:750 lib/index.tcl:15 lib/index.tcl:80
#: lib/index.tcl:149
msgid "files"
-msgstr ""
+msgstr "ファイル"
#: lib/choose_repository.tcl:779
msgid "Initial file checkout failed."
-msgstr ""
+msgstr "初期チェックアウトに失敗しました"
#: lib/choose_repository.tcl:795
msgid "Open"
-msgstr ""
+msgstr "開く"
#: lib/choose_repository.tcl:805
-#, fuzzy
msgid "Repository:"
-msgstr "リポジトリ"
+msgstr "リポジトリ:"
#: lib/choose_repository.tcl:854
-#, fuzzy, tcl-format
+#, tcl-format
msgid "Failed to open repository %s:"
-msgstr "完全にオプションを保存できません:"
+msgstr "リポジトリ %s を開けません:"
#: lib/choose_rev.tcl:53
msgid "This Detached Checkout"
@@ -1140,11 +1133,11 @@ msgstr "リビジョン式が空です。"
#: lib/choose_rev.tcl:530
msgid "Updated"
-msgstr ""
+msgstr "更新しました"
#: lib/choose_rev.tcl:558
msgid "URL"
-msgstr ""
+msgstr "URL"
#: lib/commit.tcl:9
msgid ""
@@ -1258,7 +1251,7 @@ msgstr "write-tree が失敗しました:"
#: lib/commit.tcl:275
#, tcl-format
msgid "Commit %s appears to be corrupt"
-msgstr ""
+msgstr "コミット %s は壊れています"
#: lib/commit.tcl:279
msgid ""
@@ -1281,7 +1274,7 @@ msgstr "コミットする変更がありません。"
#: lib/commit.tcl:303
#, tcl-format
msgid "warning: Tcl does not support encoding '%s'."
-msgstr ""
+msgstr "警告: Tcl はエンコーディング '%s' をサポートしていません"
#: lib/commit.tcl:317
msgid "commit-tree failed:"
@@ -1354,11 +1347,16 @@ msgid ""
"\n"
"Compress the database now?"
msgstr ""
+"このリポジトリにはおおよそ %i 個の個別オブジェクトがあります\n"
+"\n"
+"最適な性能を保つために、%i 個以上の個別オブジェクトを作る毎にデータベースを圧縮することを推奨します\n"
+"\n"
+"データベースを圧縮しますか？"
#: lib/date.tcl:25
-#, fuzzy, tcl-format
+#, tcl-format
msgid "Invalid date from Git: %s"
-msgstr "無効なリビジョン: %s"
+msgstr "Git から出た無効な日付: %s"
#: lib/diff.tcl:42
#, tcl-format
@@ -1383,14 +1381,14 @@ msgstr ""
"同様な状態のファイルを探すために、自動的に再スキャンを開始します。"
#: lib/diff.tcl:81
-#, fuzzy, tcl-format
+#, tcl-format
msgid "Loading diff of %s..."
-msgstr "%s をロード中…"
+msgstr "%s の変更点をロード中…"
#: lib/diff.tcl:114 lib/diff.tcl:184
#, tcl-format
msgid "Unable to display %s"
-msgstr ""
+msgstr "%s を表示できません"
#: lib/diff.tcl:115
msgid "Error loading file:"
@@ -1398,11 +1396,11 @@ msgstr "ファイルを読む際のエラーです:"
#: lib/diff.tcl:122
msgid "Git Repository (subproject)"
-msgstr ""
+msgstr "Git リポジトリ(サブプロジェクト)"
#: lib/diff.tcl:134
msgid "* Binary file (not showing content)."
-msgstr ""
+msgstr "* バイナリファイル(内容は表示しません)"
#: lib/diff.tcl:185
msgid "Error loading diff:"
@@ -1429,14 +1427,14 @@ msgid "You must correct the above errors before committing."
msgstr "コミットする前に、以上のエラーを修正して下さい"
#: lib/index.tcl:241
-#, fuzzy, tcl-format
+#, tcl-format
msgid "Unstaging %s from commit"
-msgstr "コミットから降ろす"
+msgstr "コミットから '%s' を降ろす"
#: lib/index.tcl:285
-#, fuzzy, tcl-format
+#, tcl-format
msgid "Adding %s"
-msgstr "%s を読んでいます…"
+msgstr "コミットに %s を加えています"
#: lib/index.tcl:340
#, tcl-format
@@ -1651,41 +1649,37 @@ msgid "New Branch Name Template"
msgstr "新しいブランチ名のテンプレート"
#: lib/option.tcl:176
-#, fuzzy
msgid "Change Font"
-msgstr "主フォント"
+msgstr "フォントを変更"
#: lib/option.tcl:180
#, tcl-format
msgid "Choose %s"
-msgstr ""
+msgstr "%s を選択"
#: lib/option.tcl:186
msgid "pt."
-msgstr ""
+msgstr "ポイント"
#: lib/option.tcl:200
msgid "Preferences"
-msgstr ""
+msgstr "設定"
#: lib/option.tcl:235
msgid "Failed to completely save options:"
msgstr "完全にオプションを保存できません:"
#: lib/remote.tcl:165
-#, fuzzy
msgid "Prune from"
-msgstr "%s から刈る…"
+msgstr "から刈込む…"
#: lib/remote.tcl:170
-#, fuzzy
msgid "Fetch from"
-msgstr "%s からフェッチ…"
+msgstr "取得元"
#: lib/remote.tcl:213
-#, fuzzy
msgid "Push to"
-msgstr "プッシュ"
+msgstr "プッシュ先"
#: lib/remote_branch_delete.tcl:29 lib/remote_branch_delete.tcl:34
msgid "Delete Remote Branch"
@@ -1724,12 +1718,15 @@ msgid "A branch is required for 'Merged Into'."
msgstr "'マージ先' にはブランチが必要です。"
#: lib/remote_branch_delete.tcl:184
-#, fuzzy, tcl-format
+#, tcl-format
msgid ""
"The following branches are not completely merged into %s:\n"
"\n"
" - %s"
-msgstr "以下のブランチは %s に完全にマージされていません:"
+msgstr ""
+"以下のブランチは %s に完全にマージされていません:\n"
+"\n"
+" - %s"
#: lib/remote_branch_delete.tcl:189
#, tcl-format
@@ -1782,9 +1779,9 @@ msgid "%s ... %*i of %*i %s (%3i%%)"
msgstr "%1$s ... %3$*i %4$s 中の %$2*i (%5$3i%%)"
#: lib/transport.tcl:6
-#, fuzzy, tcl-format
+#, tcl-format
msgid "fetch %s"
-msgstr "フェッチ"
+msgstr "%s を取得"
#: lib/transport.tcl:7
#, tcl-format
@@ -1794,7 +1791,7 @@ msgstr "%s から新しい変更をフェッチしています"
#: lib/transport.tcl:18
#, tcl-format
msgid "remote prune %s"
-msgstr ""
+msgstr "遠隔刈込 %s"
#: lib/transport.tcl:19
#, tcl-format
@@ -1804,7 +1801,7 @@ msgstr "%s から削除されたトラッキング・ブランチを刈ってい
#: lib/transport.tcl:25 lib/transport.tcl:71
#, tcl-format
msgid "push %s"
-msgstr ""
+msgstr "%s をプッシュ"
#: lib/transport.tcl:26
#, tcl-format
@@ -1834,7 +1831,7 @@ msgstr "通信オプション"
#: lib/transport.tcl:160
msgid "Force overwrite existing branch (may discard changes)"
-msgstr ""
+msgstr "既存ブランチを上書き(変更を破棄する可能性があります)"
#: lib/transport.tcl:164
msgid "Use thin pack (for slow network connections)"
@@ -1844,11 +1841,3 @@ msgstr "Thin Pack を使う（遅いネットワーク接続）"
msgid "Include tags"
msgstr "タグを含める"
-#~ msgid "Cannot find the git directory:"
-#~ msgstr "git ディレクトリが見つかりません:"
-
-#~ msgid "Unstaged Changes (Will Not Be Committed)"
-#~ msgstr "ステージングされていない（コミット未予定の）変更"
-
-#~ msgid "Push to %s..."
-#~ msgstr "%s へプッシュ…"
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
----------------------------------------------------------------------
Free pop3 email with a spam filter.
http://www.bluebottle.com/tag/5
^ permalink raw reply related
* Re: cpio command not found
From: Allan Wind @ 2007-10-31 13:58 UTC (permalink / raw)
To: git
In-Reply-To: <18216.35066.259686.376571@lisa.zopyra.com>
On 2007-10-31T07:54:02-0600, Bill Lear wrote:
> If the system does not have cpio, I think the build of git should
> complain and fail, or it should activate code that treats any
> repository accessed over the file system as it would file://.
git may be build and run on two different hosts, so while the build-time
check is good there should be a run-time check as well.
/Allan
^ permalink raw reply
* Re: cpio command not found
From: Johannes Schindelin @ 2007-10-31 14:20 UTC (permalink / raw)
To: Erik Mouw; +Cc: Karl Hasselstr?m, Bill Lear, git
In-Reply-To: <20071031140655.GA8802@gateway.home>
Hi,
On Wed, 31 Oct 2007, Erik Mouw wrote:
> On Wed, Oct 31, 2007 at 02:30:39PM +0100, Karl Hasselstr?m wrote:
> > On 2007-10-31 06:51:30 -0600, Bill Lear wrote:
> >
> > > I don't remember this dependence from earlier versions of git. I
> > > have been running git 1.4.xx on this machine for a while...
> >
> > When you clone with -l, git uses cpio to hardlink to the original
> > repository. What has changed is that -l is now used by default when
> > cloning a repository that's accessed via the file system (as opposed
> > to over some network protocol).
>
> Why cpio? What is wrong with ln(1) (every Unix should have one) or
> link(2) ?
Patch, please?
Ciao,
Dscho
^ permalink raw reply
* Re: cpio command not found
From: Erik Mouw @ 2007-10-31 14:06 UTC (permalink / raw)
To: Karl Hasselstr?m; +Cc: Bill Lear, git
In-Reply-To: <20071031133039.GA29065@diana.vm.bytemark.co.uk>
[-- Attachment #1: Type: text/plain, Size: 734 bytes --]
On Wed, Oct 31, 2007 at 02:30:39PM +0100, Karl Hasselstr?m wrote:
> On 2007-10-31 06:51:30 -0600, Bill Lear wrote:
>
> > I don't remember this dependence from earlier versions of git. I
> > have been running git 1.4.xx on this machine for a while...
>
> When you clone with -l, git uses cpio to hardlink to the original
> repository. What has changed is that -l is now used by default when
> cloning a repository that's accessed via the file system (as opposed
> to over some network protocol).
Why cpio? What is wrong with ln(1) (every Unix should have one) or
link(2) ?
Erik
--
They're all fools. Don't worry. Darwin may be slow, but he'll
eventually get them. -- Matthew Lammers in alt.sysadmin.recovery
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Possible bug: git-svn leaves broken tree in case of error
From: Anton Korobeynikov @ 2007-10-31 14:04 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20071031084257.GA2911.SS5073SS@mayonaise>
Hello, Eric
> With the following test case, I'm not able to reproduce what you're
> describing.
Looks like something nasty here. I also failed to reproduce with such
test, however I definitely was sure, that I modelled it properly.
The typical scenario here is that I'm syncing with external repository
by hands. I tried to replay this with "bad" authors file, but it doesn't
allow me to past through "bad" changeset. And yes, adding new entry to
authors files fixes the problem.
I saw corruption, when git-svn in the next run continues fetch
changesets. As I saw this problem several times with my current setup, I
added some extra backups, so I hope next time I'll catch tree before and
after breakage. Sorry for bothering.
Btw, there is way, how repository can be broken (however, by user only):
after such error 'git fsck' reports dangling trees, and running 'git gc
--prune' will break any future sync.
Anyway, thanks alot.
--
With best regards, Anton Korobeynikov.
Faculty of Mathematics & Mechanics, Saint Petersburg State University.
^ permalink raw reply
* Re: [PATCH 1/1] Add --first-parent support to interactive rebase.
From: Karl Hasselström @ 2007-10-31 14:00 UTC (permalink / raw)
To: Dmitry Potapov
Cc: Björn Steinbrink, Junio C Hamano, Johannes.Schindelin, git
In-Reply-To: <20071031134358.GD15182@dpotapov.dyndns.org>
On 2007-10-31 16:43:58 +0300, Dmitry Potapov wrote:
> I believe that the issue is with Junio's mail client. Indeed, the
> context encoding for the mail *body* was specified as 8859-1, but
> that should have none effect on fields in the mail header, because
> any field is the header should be either printable ASCII or encoded
> to contain only ASCII characters as specified in RFC 1522:
Yes. But it's the body that's been mangled -- specifically, the
Sign-off line.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: cpio command not found
From: David Symonds @ 2007-10-31 14:00 UTC (permalink / raw)
To: Bill Lear; +Cc: Karl Hasselström, git
In-Reply-To: <18216.35066.259686.376571@lisa.zopyra.com>
On 11/1/07, Bill Lear <rael@zopyra.com> wrote:
> On Wednesday, October 31, 2007 at 14:30:39 (+0100) Karl Hasselström writes:
> >On 2007-10-31 06:51:30 -0600, Bill Lear wrote:
> >
> >> I don't remember this dependence from earlier versions of git. I
> >> have been running git 1.4.xx on this machine for a while...
> >
> >When you clone with -l, git uses cpio to hardlink to the original
> >repository. What has changed is that -l is now used by default when
> >cloning a repository that's accessed via the file system (as opposed
> >to over some network protocol).
> >
> >To work around this, specify the repository location with file://, and
> >git won't try to hardlink (and hence won't try to use cpio).
>
> Hmm, thanks for the workaround, but I don't altogether like leaving
> things like this.
>
> If the system does not have cpio, I think the build of git should
> complain and fail, or it should activate code that treats any
> repository accessed over the file system as it would file://.
Something like this could be done at run-time instead. You might
install cpio, but shouldn't require a rebuild of git just to use it.
Dave.
^ permalink raw reply
* [PATCH] git-diff.txt: add section "output format" describing the diff formats
From: Gerrit Pape @ 2007-10-31 13:59 UTC (permalink / raw)
To: git, Junio C Hamano
git-diff.txt includes diff-options.txt which for the -p option refers
to a section "generating patches.." which is missing from the git-diff
documentation. This patch adapts diff-format.txt to additionally
mention the git-diff program, and includes diff-format.txt into
git-diff.txt.
Tino Keitel noticed this problem.
Signed-off-by: Gerrit Pape <pape@smarden.org>
---
Documentation/diff-format.txt | 22 +++++++++++-----------
Documentation/git-diff.txt | 3 +++
2 files changed, 14 insertions(+), 11 deletions(-)
diff --git a/Documentation/diff-format.txt b/Documentation/diff-format.txt
index 0015032..a580f18 100644
--- a/Documentation/diff-format.txt
+++ b/Documentation/diff-format.txt
@@ -1,5 +1,5 @@
-The output format from "git-diff-index", "git-diff-tree" and
-"git-diff-files" are very similar.
+The output format from "git-diff-index", "git-diff-tree",
+"git-diff-files" and "git diff --raw" are very similar.
These commands all compare two sets of things; what is
compared differs:
@@ -62,9 +62,9 @@ respectively.
diff format for merges
----------------------
-"git-diff-tree" and "git-diff-files" can take '-c' or '--cc' option
-to generate diff output also for merge commits. The output differs
-from the format described above in the following way:
+"git-diff-tree", "git-diff-files" and "git-diff" can take '-c' or
+'--cc' option to generate diff output also for merge commits. The
+output differs from the format described above in the following way:
. there is a colon for each parent
. there are more "src" modes and "src" sha1
@@ -86,10 +86,10 @@ Generating patches with -p
--------------------------
When "git-diff-index", "git-diff-tree", or "git-diff-files" are run
-with a '-p' option, they do not produce the output described above;
-instead they produce a patch file. You can customize the creation
-of such patches via the GIT_EXTERNAL_DIFF and the GIT_DIFF_OPTS
-environment variables.
+with a '-p' option, or "git diff" without the '--raw' option, they
+do not produce the output described above; instead they produce a
+patch file. You can customize the creation of such patches via the
+GIT_EXTERNAL_DIFF and the GIT_DIFF_OPTS environment variables.
What the -p option produces is slightly different from the traditional
diff format.
@@ -137,8 +137,8 @@ file made it into the new one.
combined diff format
--------------------
-git-diff-tree and git-diff-files can take '-c' or '--cc' option
-to produce 'combined diff', which looks like this:
+"git-diff-tree", "git-diff-files" and "git-diff" can take '-c' or
+'--cc' option to produce 'combined diff', which looks like this:
------------
diff --combined describe.c
diff --git a/Documentation/git-diff.txt b/Documentation/git-diff.txt
index ce0f502..11c4216 100644
--- a/Documentation/git-diff.txt
+++ b/Documentation/git-diff.txt
@@ -82,6 +82,9 @@ include::diff-options.txt[]
the diff to the named paths (you can give directory
names and get diff for all files under them).
+Output format
+-------------
+include::diff-format.txt[]
EXAMPLES
--------
--
1.5.3.4
^ permalink raw reply related
* Re: cpio command not found
From: Bill Lear @ 2007-10-31 13:54 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20071031133039.GA29065@diana.vm.bytemark.co.uk>
On Wednesday, October 31, 2007 at 14:30:39 (+0100) Karl Hasselström writes:
>On 2007-10-31 06:51:30 -0600, Bill Lear wrote:
>
>> I don't remember this dependence from earlier versions of git. I
>> have been running git 1.4.xx on this machine for a while...
>
>When you clone with -l, git uses cpio to hardlink to the original
>repository. What has changed is that -l is now used by default when
>cloning a repository that's accessed via the file system (as opposed
>to over some network protocol).
>
>To work around this, specify the repository location with file://, and
>git won't try to hardlink (and hence won't try to use cpio).
Hmm, thanks for the workaround, but I don't altogether like leaving
things like this.
If the system does not have cpio, I think the build of git should
complain and fail, or it should activate code that treats any
repository accessed over the file system as it would file://.
No sense in leaving this surprise to the user so late in the cycle.
Bill
^ permalink raw reply
* Re: [PATCH 1/1] Add --first-parent support to interactive rebase.
From: Dmitry Potapov @ 2007-10-31 13:43 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Junio C Hamano, Johannes.Schindelin, git
In-Reply-To: <20071031055303.GB3326@atjola.homenet>
On Wed, Oct 31, 2007 at 06:53:03AM +0100, Björn Steinbrink wrote:
> On 2007.10.30 22:05:27 -0700, Junio C Hamano wrote:
> > Your MUA seems to mark the UTF-8 message you are sending out as
> > 8859-1, which means your name in the message gets corrupt.
>
> Hm, that would be git-send-email then, anything I need to configure?
> (Actually I don't see it marking the message as anything)
I believe that the issue is with Junio's mail client. Indeed, the
context encoding for the mail *body* was specified as 8859-1, but
that should have none effect on fields in the mail header, because
any field is the header should be either printable ASCII or encoded
to contain only ASCII characters as specified in RFC 1522:
encoded-word = "=?" charset "?" encoding "?" encoded-text "?="
Here is the From field from the mail:
From: =?utf-8?q?Bj=C3=B6rn=20Steinbrink?= <B.Steinbrink@gmx.de>
So, as far as I can tell, it is encoded properly using utf-8.
Dmitry
^ permalink raw reply
* Re: Recording merges after repo conversion
From: Johannes Schindelin @ 2007-10-31 13:43 UTC (permalink / raw)
To: Johan Herland; +Cc: git, Peter Karlsson, Lars Hjemli, Benoit SIGOURE
In-Reply-To: <200710311343.58414.johan@herland.net>
Hi,
On Wed, 31 Oct 2007, Johan Herland wrote:
> On Wednesday 31 October 2007, Johannes Schindelin wrote:
>
> > On Wed, 31 Oct 2007, Peter Karlsson wrote:
> >
> > > Johannes Schindelin:
> > >
> > > > Why should it? This would contradict the whole "a commit sha1
> > > > hashes the commit, and by inference the _whole_ history"
> > > > principle.
> > >
> > > Does it?
> >
> > Yes! Of course! If what you want becomes possible, I could make an
> > evil change in history long gone, and slip it by you. You could not
> > even see the history which changed.
>
> Well, technically, if the grafts file was part of the repo, you wouldn't
> be able to change the (in-tree) grafts file without affecting the SHA1
> of HEAD. In other words, given a commit SHA1 sum, you can be sure that
> someone else who checks out the same commit (and has no local
> modification to their grafts file) will see exactly the same history as
> you do.
All this does not change the fact that installing a graft and 'git gc
--prune'ing gets rid of the old history. D'oh.
Automatically installing grafts is wrong.
Ciao,
Dscho
^ permalink raw reply
* Re: cpio command not found
From: Karl Hasselström @ 2007-10-31 13:30 UTC (permalink / raw)
To: Bill Lear; +Cc: git
In-Reply-To: <18216.31314.990545.518458@lisa.zopyra.com>
On 2007-10-31 06:51:30 -0600, Bill Lear wrote:
> I don't remember this dependence from earlier versions of git. I
> have been running git 1.4.xx on this machine for a while...
When you clone with -l, git uses cpio to hardlink to the original
repository. What has changed is that -l is now used by default when
cloning a repository that's accessed via the file system (as opposed
to over some network protocol).
To work around this, specify the repository location with file://, and
git won't try to hardlink (and hence won't try to use cpio).
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: Problem with git-cvsimport
From: Aidan Van Dyk @ 2007-10-31 12:40 UTC (permalink / raw)
To: dev; +Cc: git
In-Reply-To: <200710302244.50034.robin.rosenberg.lists@dewire.com>
Robin Rosenberg wrote:
> I use fromcvs which is *very* fast, and quite memory conservative compared
> to the others and seems reliable so far (six months). It probably breaks
> on exotic variants of branches though, but I don't have those / don't care
> about them.
I actually use fromcvs for a few repositories, and actually started using it
on repositories where cvsps (and git-cvsimport) fail.
> Drawbacks, more dependencies and access to the rcs files is required and
> tags are not converted.
Most projects have "rsyncs" or "tarballs" of their CVS repository available,
making fromcvs possible on most of them. And CVS tags, well they are about
as good as CVS $Keywords$.
^ 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