* Re: [PATCH 3/3] git checkout --nodwim
From: Jeff King @ 2009-10-26 22:14 UTC (permalink / raw)
To: Avery Pennarun
Cc: Johannes Schindelin, David Roundy, Junio C Hamano,
Nanako Shiraishi, Alex Riesen, git, Jay Soffian
In-Reply-To: <32541b130910261501n32046cc5s12283a8e3981d04e@mail.gmail.com>
On Mon, Oct 26, 2009 at 06:01:29PM -0400, Avery Pennarun wrote:
> > It's git-update-ref.
>
> That would be similar to git commit, not git checkout, right? Oh
> wait, I see the confusion: git checkout does two things. It switches
> branches, and it checks out files from the index into the work tree.
> I meant the latter meaning.
Er, sorry, yes. It should be "git symbolic-ref", of course, to change
HEAD, and then probably read-tree and checkout-index. I was just not
thinking when I wrote the other message (hopefully I am doing so now).
> > Consider "git commit", for example. Does anyone
> > actually script around "write-tree" and "commit-tree" these days, or do
> > they just script around "git commit"?
>
> Oh, I use those all the time. They're awesome! It allows you to
> create commits without having a working tree, which lets me do very
> interesting tricks. git-subtree uses this heavily.
>
> I'm probably a weirdo, though.
OK, I should have phrased my statement differently (see, I told you I
wasn't thinking). Yes, there are reasons to script around low-level
building blocks, when you don't want the assumptions associated with the
higher level. But I'm sure there are tons of scripts that munge some
files in a worktree, followed by "git add -A; git commit -m 'automagic
update'". And in that case, nobody would script around "commit-tree"
because it's a lot more work.
-Peff
^ permalink raw reply
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Johannes Schindelin @ 2009-10-26 22:22 UTC (permalink / raw)
To: Sean Estabrooks
Cc: Nicolas Pitre, Jeff King, Junio C Hamano, Daniel Barkalow,
Jay Soffian, git
In-Reply-To: <BLU0-SMTP840FB343954FC20ACA699CAEC30@phx.gbl>
Hi,
On Sat, 17 Oct 2009, Sean Estabrooks wrote:
> On Fri, 16 Oct 2009 04:07:23 +0200 (CEST)
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > Just recently, I had a user request (a very valid one, mind you) where
> > the user does not want to provide a commit message, and wants to just
> > commit all the current changes. In that particular case, it is very
> > sensible to ask for these things. It is something utterly simple to
> > ask for. Yet, it is utterly hard with Git, especially if I have to
> > explain it.
>
> Hey Johannes,
>
> It's actually easy, but maybe hard to find:
>
> $ git commit --cleanup=verbatim -m ""
Of course that leaves out the main part. But it is simple once you
know it (I did not): git add -A (we even went out of our way _not_ to name
the long option --addremove, but --all -- it does not seem to be an
expressive-enough option name to me, but what does my impression
matter...)
So I retract my claim that it is utterly hard to do with Git (but not the
rest).
Ciao,
Dscho
^ permalink raw reply
* gti push interface inconsistency
From: Eugene Sajine @ 2009-10-26 22:23 UTC (permalink / raw)
To: git
Hi,
I have a question:
Why I can't do
$ git push my_tag
It will fail because the remote is not specified, even if there is
only one origin remote
but can do
$ git push --tags
and it will push tags to origin...
Thanks,
Eugene
^ permalink raw reply
* Re: [PATCH ef/msys-imap] mingw: use BLK_SHA1 again
From: Johannes Schindelin @ 2009-10-26 22:26 UTC (permalink / raw)
To: Johannes Sixt
Cc: msysgit, git, Erik Faye-Lund, Junio C Hamano, Marius Storm-Olsen
In-Reply-To: <200910222026.29885.j6t@kdbg.org>
Hi,
On Thu, 22 Oct 2009, Johannes Sixt wrote:
> Since NO_OPENSSL is no longer defined on Windows, BLK_SHA1 is not defined
> anymore implicitly. Define it explicitly.
>
> As a nice side-effect, we no longer link against libcrypto.dll, which has
> non-trivial startup costs because it depends on 6 otherwise unneeded
> DLLs.
>
> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
> ---
> On Donnerstag, 22. Oktober 2009, Johannes Sixt wrote:
> > ... and I have one more patch to be applied on top of the series.
>
> Here it is. I haven't tested the MSVC aspect of the patch. I would
> appreciate feedback in this regard.
For better visibility, I pushed it to the work/msys-imap branch in
4msysgit.git (but I could not even compile-test it today, due to lack of
access to a Windows machine).
If nobody complains by the end of the week, I will merge it into
4msysgit.git's 'devel' branch (I can only compile-test by then).
Ciao,
Dscho
^ permalink raw reply
* git push interface inconsistency
From: Eugene Sajine @ 2009-10-26 22:25 UTC (permalink / raw)
To: git; +Cc: Eugene Sajine
Hi,
I have a question:
Why I can't do
$ git push my_tag
It will fail because the remote is not specified, even if there is
only one origin remote
but can do
$ git push --tags
and it will push tags to origin...
Thanks,
Eugene
^ permalink raw reply
* Re: [PATCH 3/3] git checkout --nodwim
From: Avery Pennarun @ 2009-10-26 22:28 UTC (permalink / raw)
To: Jeff King
Cc: Johannes Schindelin, David Roundy, Junio C Hamano,
Nanako Shiraishi, Alex Riesen, git, Jay Soffian
In-Reply-To: <20091026221424.GA28184@sigio.peff.net>
On Mon, Oct 26, 2009 at 6:14 PM, Jeff King <peff@peff.net> wrote:
> On Mon, Oct 26, 2009 at 06:01:29PM -0400, Avery Pennarun wrote:
>> > It's git-update-ref.
>>
>> That would be similar to git commit, not git checkout, right? Oh
>> wait, I see the confusion: git checkout does two things. It switches
>> branches, and it checks out files from the index into the work tree.
>> I meant the latter meaning.
>
> Er, sorry, yes. It should be "git symbolic-ref", of course, to change
> HEAD, and then probably read-tree and checkout-index. I was just not
> thinking when I wrote the other message (hopefully I am doing so now).
Wow, I've browsed through the git manpages repeatedly and never found
checkout-index. It was exactly the missing building block I was
looking for. Thanks!
>> > Consider "git commit", for example. Does anyone
>> > actually script around "write-tree" and "commit-tree" these days, or do
>> > they just script around "git commit"?
>>
>> Oh, I use those all the time. They're awesome! It allows you to
>> create commits without having a working tree, which lets me do very
>> interesting tricks. git-subtree uses this heavily.
>>
>> I'm probably a weirdo, though.
>
> OK, I should have phrased my statement differently (see, I told you I
> wasn't thinking). Yes, there are reasons to script around low-level
> building blocks, when you don't want the assumptions associated with the
> higher level. But I'm sure there are tons of scripts that munge some
> files in a worktree, followed by "git add -A; git commit -m 'automagic
> update'". And in that case, nobody would script around "commit-tree"
> because it's a lot more work.
Unfortunately this is pretty tricky to get perfect; perhaps there's no
way to do it.
In git-subtree, for example, I *mostly* use write-tree and
commit-tree, but when I do the final merge operation (to take the
synthetic history and merge it into your "real" history) I use commit.
This is because I wanted the default merge handling, commit message,
etc for that part. Unfortunately, it's possible that this dragged in
a bunch of stuff I *didn't* want. It also makes git-subtree, which
otherwise could be used as plumbing, effectively into a porcelain.
I don't really know what to do about that. You could introduce an
abstraction level somewhere between commit-tree and commit, but surely
someone would eventually find a case where that abstraction level is
still not right. To bring this around to the original topic of this
thread, such an extra level of abstraction is equivalent to the
suggested --plumbing (or whatever) option, whether it's presented as
an option or a separate command.
Have fun,
Avery
^ permalink raw reply
* Re: git push interface inconsistency
From: Avery Pennarun @ 2009-10-26 22:31 UTC (permalink / raw)
To: Eugene Sajine; +Cc: git
In-Reply-To: <76c5b8580910261525y5397b54eyf9c3d58c0fe19fce@mail.gmail.com>
On Mon, Oct 26, 2009 at 6:25 PM, Eugene Sajine <euguess@gmail.com> wrote:
> I have a question:
>
> Why I can't do
>
> $ git push my_tag
>
> It will fail because the remote is not specified, even if there is
> only one origin remote
>
> but can do
>
> $ git push --tags
>
> and it will push tags to origin...
Because 'my_tag' is interpreted as the name or URL of the remote, not
as a branch name. You can do "git push origin" and it will guess the
branch name(s) to push, but because of that, the one-parameter push
can't *also* be used to guess the remote name.
In contrast, --tags is a flag, so it's actually the zero-parameter
version of push, which assumes 'origin' and then guesses the branch
name (and --tags changes the guessed result).
Hope that helps.
Have fun,
Avery
^ permalink raw reply
* [PATCH v2 3/2] remote: fix poential ref_map list corruption in ref_remove_duplicates
From: Julian Phillips @ 2009-10-26 23:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, git
In-Reply-To: <20091025212813.48498.51868.julian@quantumfyre.co.uk>
The prev pointer was not being updated when the peer_ref member
pointer was NULL, which means that that any items in the list with a
NULL peer_ref immediately preceeding a duplicate would be dropped
without being freed.
Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk>
---
Having fixed the access after free bug, I realised that there was
still a problem. This one didn't show up in the tests - due to the
rather specific circumstances required, but may occur in real use.
remote.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/remote.c b/remote.c
index 1380b20..4f9f0cc 100644
--- a/remote.c
+++ b/remote.c
@@ -738,7 +738,7 @@ void ref_remove_duplicates(struct ref *ref_map)
struct string_list refs = { NULL, 0, 0, 0 };
struct string_list_item *item = NULL;
struct ref *prev = NULL, *next = NULL;
- for (; ref_map; ref_map = next) {
+ for (; ref_map; prev = ref_map, ref_map = next) {
next = ref_map->next;
if (!ref_map->peer_ref)
continue;
@@ -758,7 +758,6 @@ void ref_remove_duplicates(struct ref *ref_map)
item = string_list_insert(ref_map->peer_ref->name, &refs);
item->util = ref_map;
- prev = ref_map;
}
string_list_clear(&refs, 0);
}
--
1.6.5.rc2
^ permalink raw reply related
* Re: [PATCH] push: support remote branches in guess_ref DWIM
From: Junio C Hamano @ 2009-10-26 23:31 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20091026213353.GA27871@sigio.peff.net>
Jeff King <peff@peff.net> writes:
> When we get an unqualified dest refspec like "foo", we try
> to guess its full ref path (like "refs/heads/foo") based on
> the source ref. Commit f8aae12 mapped local heads to remote
> heads, and local tags to remote tags.
>
> This commit maps local tracking branches under
> "refs/remotes" to remote branch heads, so
>
> git push origin origin/branch:renamed-branch
>
> pushes to refs/heads/renamed-branch.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> This came from a discussion on IRC. I don't see any reason not to do
> this; would people really expect it to push into refs/remotes/ on the
> other side (right now, it complains and dies)?
As _our_ origin can never be _their_ origin if we are clone of them, I do
not think anybody sane would expect it to push into refs/remotes/origin/
to begin with.
But "not in refs/remotes/" does not automatically mean "the only sensible
place is refs/heads", does it? "We do not know what kind of mistake the
user is trying to make" could be more plausible answer, and in that case,
"complain and die" may be a more valid course of action.
For example,
git push origin origin/master:refs/heads/master
is most likely to be a mistake. The only situation something similar to
this makes sense is where you pushed out a bogus commit earlier and are
trying to correct it perhaps with
git push origin +origin/master@{1}:refs/heads/master
but you need to force it and go back in the reflog.
I know you are doing this DWIM only when $dst does not exist over there,
and the "pushing old master back to master" above is a different scenario,
but if "git push origin origin/master:master" shouldn't update their local
master, "git push origin origin/master:naster" shouldn't update their
local naster, in order to avoid confusion arising from inconsistency, no?
Another possibility is to see the type (not refname) of $src and push all
commits to refs/heads/$dst and everything else (most likely tags) to
refs/tags/$dst, to simplify the rule to make it easier to explain and
remember, but there are lightweight tags that make this idea unworkable.
> A related issue (which exists even without this patch) is that doing
> this:
>
> master:remotes/incoming/master
>
> will create "refs/heads/remotes/incoming/master". Perhaps we should DWYM
> a little more and recognize "heads", "remotes", and "tags" as special.
Yes, it is an independent issue; I think correcting this DWIM (or at least
"warning" if not refusing to create remotes/ under refs/heads/) might be a
good idea.
^ permalink raw reply
* Re: git push interface inconsistency
From: Eugene Sajine @ 2009-10-26 23:39 UTC (permalink / raw)
To: Avery Pennarun; +Cc: git
In-Reply-To: <32541b130910261531o36b8ce7eh6bddf26a2ae15663@mail.gmail.com>
Got it.
Thanks!
On Mon, Oct 26, 2009 at 6:31 PM, Avery Pennarun <apenwarr@gmail.com> wrote:
> On Mon, Oct 26, 2009 at 6:25 PM, Eugene Sajine <euguess@gmail.com> wrote:
>> I have a question:
>>
>> Why I can't do
>>
>> $ git push my_tag
>>
>> It will fail because the remote is not specified, even if there is
>> only one origin remote
>>
>> but can do
>>
>> $ git push --tags
>>
>> and it will push tags to origin...
>
> Because 'my_tag' is interpreted as the name or URL of the remote, not
> as a branch name. You can do "git push origin" and it will guess the
> branch name(s) to push, but because of that, the one-parameter push
> can't *also* be used to guess the remote name.
>
> In contrast, --tags is a flag, so it's actually the zero-parameter
> version of push, which assumes 'origin' and then guesses the branch
> name (and --tags changes the guessed result).
>
> Hope that helps.
>
> Have fun,
>
> Avery
>
^ permalink raw reply
* Re: [PATCH] gitk: Add Japanese translation
From: Junio C Hamano @ 2009-10-26 23:59 UTC (permalink / raw)
To: Mizar; +Cc: git
In-Reply-To: <d092a4360910260649l9a13e5ep9387b4f8feb9a22c@mail.gmail.com>
Mizar <mizar.jp@gmail.com> writes:
> I tried to Japanese translation of gitk. Attached to its translation.
> Some messages are not translated yet.
> And, you may find some strange translations.
> People have a better idea of Japanese translation, please let us know.
Wow, thanks.
Having an empty msgstr "" for yet-to-be-translated entries is slightly
misleading. People who work on PO files can spot them, but those who try
your wip translation files cannot spot them in the UI.
I am not sure if I am happy with the word used as the translation of
"reference".
Comments on just a few items I noticed (I didn't read everything that
deeply, though).
> +#: gitk:2099 gitk:2101
> +msgid "Exact"
> +msgstr "A-Z/a-zを区別"
git-gui seems to say "大文字小文字を区別" for this.
> +
> +#: gitk:2101 gitk:4447 gitk:6248
> +msgid "IgnCase"
> +msgstr "A-Z/a-zを区別しない"
Similar...
> +#: gitk:2397
> +msgid "Blame parent commit"
> +msgstr ""
Perhaps 「親コミットから blame をかける」
> +#: gitk:2404
> +msgid "Show origin of this line"
> +msgstr ""
Perhaps「この行の出自を表示する」
> +#: gitk:2405
> +msgid "Run git gui blame on this line"
> +msgstr ""
Perhaps「この行に git gui で blame をかける」
> +#: gitk:11137
> +msgid "Cannot find a git repository here."
> +msgstr "ここでgitリポジトリを見つけられません。"
「ここにはリポジトリがありません」。
> +#: gitk:11285
> +msgid "Command line"
> +msgstr "コマンドライン"
「コマンド行」would be equally common and shorter.
^ permalink raw reply
* Re: [PATCH/RFC 2/2] completion: allow use without compiling
From: Junio C Hamano @ 2009-10-26 23:59 UTC (permalink / raw)
To: Stephen Boyd
Cc: Shawn O. Pearce, Junio C Hamano, git, Clemens Buchacher,
Sverre Rabbelier
In-Reply-To: <1256589116-6998-3-git-send-email-bebarino@gmail.com>
Stephen Boyd <bebarino@gmail.com> writes:
> Some users don't want to compile their completion, even when the build
> generated completion is 10x faster to load. For example, in my bashrc I
> source the completion script directly so I can stay up to date with the
> latest completion by merely pulling changes.
>
> Do this by generating the lists dynamically when the merge strategy and
> command lists still have their initial values (__GIT_MERGE_STRATEGYLIST,
> __GIT_ALL_COMMANDLIST).
>
> Signed-off-by: Stephen Boyd <bebarino@gmail.com>
> ---
>
> This duplicates code, but I don't know of a way to re-use the dynamic
> code without sourcing a bash script and possibly breaking someone's build.
If we are going to do this, wouldn't it make more sense to revert the
rename of the script, so that people can keep relying on the name of the
script being "git-completion.bash", _but_ make it produce a pre-compiled
form to a separate file when invoked in some particular way?
Then at the runtime:
(0) If the script notices that it has already learned the command list
it uses it; otherwise,
(1) If the script notices that there is a file that contains the command
list, it sources it; otherwise,
(2) The script lazily builds the command list for its own use.
And at the buildtime, Makefile can run the script in "generation mode",
and install the output to where (1) above expects to see.
^ permalink raw reply
* Re: gti push interface inconsistency
From: Junio C Hamano @ 2009-10-27 0:08 UTC (permalink / raw)
To: Eugene Sajine; +Cc: git
In-Reply-To: <76c5b8580910261523s51ac22b5y624ec3502e8fed67@mail.gmail.com>
Eugene Sajine <euguess@gmail.com> writes:
> I have a question:
>
> Why I can't do
>
> $ git push my_tag
>
> It will fail because the remote is not specified, even if there is
> only one origin remote
Probably because git is not smart enough to understand the human language
to notice 't' 'a' 'g' is a tag and cannot be a remote name spelled
incorrectly, or git cannot read your mind and find out that you spelled
a name of the remote correctly but forgot to add the remote first.
^ permalink raw reply
* git vs hg commit counts?
From: Joe Perches @ 2009-10-27 0:08 UTC (permalink / raw)
To: LKML; +Cc: git, mercurial, Marti Raudsepp
I'm comparing linux-kernel git vs hg repositories.
While testing some changes to scripts/get_maintainer.pl,
I noticed that git and hg have different commit counts
for the same files.
For instance:
$ git log --since=1-year-ago -- MAINTAINERS | \
grep -P "^commit [0-9a-f]{40,40}$" | wc -l
514
$ hg log --template="commit {node}\n" --date -365 -- MAINTAINERS | \
grep -P "^commit [0-9a-f]{40,40}$" | wc -l
601
Anyone have any understanding why?
^ permalink raw reply
* Re: git vs hg commit counts?
From: Junio C Hamano @ 2009-10-27 0:18 UTC (permalink / raw)
To: Joe Perches; +Cc: LKML, git, mercurial, Marti Raudsepp
In-Reply-To: <1256602127.29938.8.camel@Joe-Laptop.home>
Joe Perches <joe@perches.com> writes:
> I'm comparing linux-kernel git vs hg repositories.
>
> While testing some changes to scripts/get_maintainer.pl,
> I noticed that git and hg have different commit counts
> for the same files.
>
> For instance:
>
> $ git log --since=1-year-ago -- MAINTAINERS | \
> grep -P "^commit [0-9a-f]{40,40}$" | wc -l
> 514
>
> $ hg log --template="commit {node}\n" --date -365 -- MAINTAINERS | \
> grep -P "^commit [0-9a-f]{40,40}$" | wc -l
> 601
>
> Anyone have any understanding why?
We simplify a merge history by discarding one branch when the merge result
matches one of the parents. Does "hg" know how to do that as well?
^ permalink raw reply
* Problems with git am
From: Alan @ 2009-10-27 0:12 UTC (permalink / raw)
To: git
I am encountering an interesting issue. I am not certain if I am doing
something wrong or I am encountering a bug or what.
I am using Git version 1.6.0.6 from Fedora 9. I am not using the current
version because it has changed how it errors out. (If git does not
understand the patch, instead of exiting with an error code that xargs
will fail on it exits with something non-fatal.)
I have a number of patches that I have been handed to apply to a git tree.
The patches have been generated by git, but have not been e-mailed. (They
may have been extracted from gitweb or some other source.)
The header of the patch looks like:
commit 62b266585bb5555d44a764c90d80f9c4bb8188c1
Author: Joe Example <joe@example.com>
Date: Wed Sep 19 10:03:47 2009 -0600
There is no e-mail line, but it has the information for e-mail address.
If I apply this patch it will error out with:
"Patch does not have a valid e-mail address."
If I use a current version of Git it errors out with a message "Cannot
determine patch format", but does not issue a fatal error code.
If I use git-apply on this patch, it applies it to the tree, but does not
commit it. (I need the comments and signoffs to remain intact.) I have to
cut-and-paste the commit information to keep it. (I am working on an
automated process to handle these patches and don' want to have to
reinvent git-am.)
Am i doing something wrong here?
My goal is to be able to take whatever patch I am handed and apply it to
the current tree. If it is a raw diff, I can handle that. What concerns
me are these patches that look like they are generated by git, but which
do not apply cleanly with git-am.
Is there some sort of instructions for applying patches that are dumped
out using "git-show" or some other mechanism?
I am not finding this process documented anywhere. (If it is, it is
pretty well hidden.)
Thanks!
^ permalink raw reply
* Re: git vs hg commit counts?
From: Joe Perches @ 2009-10-27 0:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: LKML, git, mercurial, Marti Raudsepp
In-Reply-To: <7v8wexd6zq.fsf@alter.siamese.dyndns.org>
On Mon, 2009-10-26 at 17:18 -0700, Junio C Hamano wrote:
> > $ git log --since=1-year-ago -- MAINTAINERS | \
> > grep -P "^commit [0-9a-f]{40,40}$" | wc -l
> > 514
> > $ hg log --template="commit {node}\n" --date -365 -- MAINTAINERS | \
> > grep -P "^commit [0-9a-f]{40,40}$" | wc -l
> > 601
> > Anyone have any understanding why?
> We simplify a merge history by discarding one branch when the merge result
> matches one of the parents.
Thanks Junio.
> Does "hg" know how to do that as well?
I don't know.
I was hoping to get equivalent results though.
Anyone know how?
^ permalink raw reply
* Re: git rebase -i <first_commit_in_repository>
From: eschvoca @ 2009-10-27 0:27 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: kusmabite, git
In-Reply-To: <alpine.DEB.1.00.0910262210480.4985@pacific.mpi-cbg.de>
Hi,
On Mon, Oct 26, 2009 at 5:11 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Mon, 26 Oct 2009, eschvoca wrote:
>
>> On Mon, Oct 26, 2009 at 1:25 PM, Erik Faye-Lund
>> <kusmabite@googlemail.com> wrote:
>> > On Mon, Oct 26, 2009 at 6:14 PM, eschvoca <eschvoca@gmail.com> wrote:
>> >> Hi,
>> >>
>> >> Is there a way to rewrite history, including the first commit. It
>> >> seems that the first commit can not be modified with a rebase.
>> >
>> > This question is answered in the FAQ:
>> > http://git.or.cz/gitwiki/GitFaq#HowdoIedittherootcommit.3F
>>
>> Thanks Eric. Hopefully someone will enhance rebase to handle the root
>> commit.
>
> If you cannot do it yourself, you can always offer to bribe^Wpay somebody
> to do it for you.
>
> Ciao,
> Dscho
>
I can do the workaround myself but not the production ready patch.
Right now the only bribe I can offer is that it might be less work
writing the patch than supporting this corner case with answering
questions and writing a FAQ entry about it. It also would make the
awesome rebase -i even awesomer :) I know, a disappointing bribe but
from a thankful user.
Thanks
^ permalink raw reply
* Re: [PATCH/RFC 2/2] completion: allow use without compiling
From: Clemens Buchacher @ 2009-10-27 0:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Stephen Boyd, Shawn O. Pearce, git, Sverre Rabbelier
In-Reply-To: <7vocntd7vt.fsf@alter.siamese.dyndns.org>
On Mon, Oct 26, 2009 at 04:59:18PM -0700, Junio C Hamano wrote:
> Stephen Boyd <bebarino@gmail.com> writes:
>
> > This duplicates code, but I don't know of a way to re-use the dynamic
> > code without sourcing a bash script and possibly breaking someone's build.
>
> (1) If the script notices that there is a file that contains the command
> list, it sources it; otherwise,
Or we substitute the command list in-place, so that we still have the entire
completion script in one file.
Clemens
^ permalink raw reply
* Re: [PATCH/RFC 2/2] completion: allow use without compiling
From: Junio C Hamano @ 2009-10-27 0:38 UTC (permalink / raw)
To: Clemens Buchacher
Cc: Junio C Hamano, Stephen Boyd, Shawn O. Pearce, git,
Sverre Rabbelier
In-Reply-To: <20091027003353.GA29205@localhost>
Clemens Buchacher <drizzd@aon.at> writes:
> On Mon, Oct 26, 2009 at 04:59:18PM -0700, Junio C Hamano wrote:
>
>> Stephen Boyd <bebarino@gmail.com> writes:
>>
>> > This duplicates code, but I don't know of a way to re-use the dynamic
>> > code without sourcing a bash script and possibly breaking someone's build.
>>
>> (1) If the script notices that there is a file that contains the command
>> list, it sources it; otherwise,
>
> Or we substitute the command list in-place, so that we still have the entire
> completion script in one file.
That defeats the whole point of my suggestion, as you would be overwriting
the tracked file.
^ permalink raw reply
* Re: Problems with git am
From: Junio C Hamano @ 2009-10-27 0:52 UTC (permalink / raw)
To: Alan; +Cc: git
In-Reply-To: <59976.134.134.139.70.1256602329.squirrel@clueserver.org>
"Alan" <alan@clueserver.org> writes:
> The header of the patch looks like:
>
> commit 62b266585bb5555d44a764c90d80f9c4bb8188c1
> Author: Joe Example <joe@example.com>
> Date: Wed Sep 19 10:03:47 2009 -0600
It shouldn't.
The format "git am" understands is a mbox file and format-patch is the
command to write commits out in that form. It should begin with lines
that look like:
From 610f99ec7d22b5750f12350f67c1341d6be8030f Mon Sep 17 00:00:00 2001
From: Junio C Hamano <gitster@pobox.com>
Date: Sun, 25 Oct 2009 18:41:09 -0700
Subject: [PATCH] Update draft release notes to 1.6.6
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
.... patch follows here ...
I do not think it is particularly hard to add a new case arm in "am" to
support "git log" output. It is different from a mbox format in that it
* begins each commit with "commit " marker;
* has Author: and Date: header that is different from a mailbox;
* lacks Subject: but makes it part of the message body; and
* indents the message by 4 places.
Nobody has bothered to do so, probably because nobody needed it.
The easiest, safest and quickest for you right now (meaning, before
waiting for anybody to help you by adding a new feature to "am") would be
to see if it is possible for you to get the commits re-exported in an
appropriate format.
I say the "safest" in the above because you _could_ massage what you have
into a format that looks like a mbox with some Perl script, but it risks
mismassaging.
^ permalink raw reply
* Re: [PATCH] gitk: Add Japanese translation
From: Mizar @ 2009-10-27 1:03 UTC (permalink / raw)
To: Junio C Hamano, git
In-Reply-To: <7vtyxld7vy.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1712 bytes --]
Junio C Hamano writes:
> Wow, thanks.
>
> Having an empty msgstr "" for yet-to-be-translated entries is slightly
> misleading. People who work on PO files can spot them, but those who try
> your wip translation files cannot spot them in the UI.
>
> I am not sure if I am happy with the word used as the translation of
> "reference".
>
> Comments on just a few items I noticed (I didn't read everything that
> deeply, though).
Thanks for response.
Fixed translation as follows.
> git-gui seems to say "大文字小文字を区別" for this.
| #: gitk:2099 gitk:2101
| msgid "Exact"
|-msgstr "A-Z/a-zを区別"
|+msgstr "英字の大小を区別する"
|
| #: gitk:2101 gitk:4447 gitk:6248
| msgid "IgnCase"
|-msgstr "A-Z/a-zを区別しない"
|+msgstr "英字の大小を区別しない"
> Perhaps 「親コミットから blame をかける」
> Perhaps「この行の出自を表示する」
> Perhaps「この行に git gui で blame をかける」
| #: gitk:2397
| msgid "Blame parent commit"
|-msgstr ""
|+msgstr "親コミットから blame をかける"
|
| #: gitk:2404
| msgid "Show origin of this line"
|-msgstr ""
|+msgstr "この行の出自を表示する"
|
| #: gitk:2405
| msgid "Run git gui blame on this line"
|-msgstr ""
|+msgstr "この行に git gui で blame をかける"
> 「ここにはリポジトリがありません」。
| #: gitk:11137
| msgid "Cannot find a git repository here."
|-msgstr "ここでgitリポジトリを見つけられません。"
|+msgstr "ここにはgitリポジトリがありません。"
> 「コマンド行」would be equally common and shorter.
| #: gitk:11285
| msgid "Command line"
|-msgstr "コマンドライン"
|+msgstr "コマンド行"
[-- Attachment #2: ja.po --]
[-- Type: application/octet-stream, Size: 25784 bytes --]
# Japanese translations for gitk package.
# Copyright (C) 2005-2009 Paul Mackerras
# This file is distributed under the same license as the gitk package.
#
# Mizar <mizar.jp@gmail.com>, 2009.
# Junio C Hamano <gitster@pobox.com>, 2009.
msgid ""
msgstr ""
"Project-Id-Version: gitk\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2009-10-19 02:45+0900\n"
"PO-Revision-Date: 2009-10-19 17:03+0900\n"
"Last-Translator: Mizar <mizar.jp@gmail.com>\n"
"Language-Team: Japanese\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=1; plural=0;\n"
#: gitk:113
msgid "Couldn't get list of unmerged files:"
msgstr "マージされていないファイルの一覧を取得できません:"
#: gitk:269
msgid "Error parsing revisions:"
msgstr "リビジョン解析エラー:"
#: gitk:324
msgid "Error executing --argscmd command:"
msgstr "--argscmd コマンド実行エラー:"
#: gitk:337
msgid "No files selected: --merge specified but no files are unmerged."
msgstr "ファイル未選択: --merge が指定されましたが、マージされていないファイルはありません。"
#: gitk:340
msgid ""
"No files selected: --merge specified but no unmerged files are within file "
"limit."
msgstr "ファイル未選択: --merge が指定されましたが、"
"ファイル制限内にマージされていないファイルはありません。"
#: gitk:362 gitk:509
msgid "Error executing git log:"
msgstr "git log 実行エラー:"
#: gitk:380 gitk:525
msgid "Reading"
msgstr "読み込み中"
#: gitk:440 gitk:4131
msgid "Reading commits..."
msgstr "コミット読み込み中..."
#: gitk:443 gitk:1561 gitk:4134
msgid "No commits selected"
msgstr "コミットが選択されていません"
#: gitk:1437
msgid "Can't parse git log output:"
msgstr "git log の出力を解析できません:"
#: gitk:1657
msgid "No commit information available"
msgstr "有効なコミットの情報がありません"
#: gitk:1793 gitk:1817 gitk:3924 gitk:8822 gitk:10358 gitk:10534
msgid "OK"
msgstr "OK"
#: gitk:1819 gitk:3926 gitk:8419 gitk:8493 gitk:8603 gitk:8652 gitk:8824
#: gitk:10359 gitk:10535
msgid "Cancel"
msgstr "キャンセル"
#: gitk:1919
msgid "Update"
msgstr "更新"
#: gitk:1920
msgid "Reload"
msgstr "リロード"
#: gitk:1921
msgid "Reread references"
msgstr "参照を再読み込み"
#: gitk:1922
msgid "List references"
msgstr "参照リストを表示"
#: gitk:1924
msgid "Start git gui"
msgstr "git gui の開始"
#: gitk:1926
msgid "Quit"
msgstr "終了"
#: gitk:1918
msgid "File"
msgstr "ファイル"
#: gitk:1930
msgid "Preferences"
msgstr "設定"
#: gitk:1929
msgid "Edit"
msgstr "編集"
#: gitk:1934
msgid "New view..."
msgstr "新規ビュー..."
#: gitk:1935
msgid "Edit view..."
msgstr "ビュー編集..."
#: gitk:1936
msgid "Delete view"
msgstr "ビュー削除"
#: gitk:1938
msgid "All files"
msgstr "全てのファイル"
#: gitk:1933 gitk:3678
msgid "View"
msgstr "ビュー"
#: gitk:1943 gitk:1953 gitk:2655
msgid "About gitk"
msgstr "gitk について"
#: gitk:1944 gitk:1958
msgid "Key bindings"
msgstr "キーバインディング"
#: gitk:1942 gitk:1957
msgid "Help"
msgstr "ヘルプ"
#: gitk:2018
msgid "SHA1 ID: "
msgstr "SHA1 ID: "
#: gitk:2049
msgid "Row"
msgstr "行"
#: gitk:2080
msgid "Find"
msgstr "検索"
#: gitk:2081
msgid "next"
msgstr "次"
#: gitk:2082
msgid "prev"
msgstr "前"
#: gitk:2083
msgid "commit"
msgstr "コミット"
#: gitk:2086 gitk:2088 gitk:4292 gitk:4315 gitk:4339 gitk:6280 gitk:6352
#: gitk:6436
msgid "containing:"
msgstr "含む:"
#: gitk:2089 gitk:3163 gitk:3168 gitk:4367
msgid "touching paths:"
msgstr "パスの一部:"
#: gitk:2090 gitk:4372
msgid "adding/removing string:"
msgstr "追加/除去する文字列:"
#: gitk:2099 gitk:2101
msgid "Exact"
msgstr "英字の大小を区別する"
#: gitk:2101 gitk:4447 gitk:6248
msgid "IgnCase"
msgstr "英字の大小を区別しない"
#: gitk:2101 gitk:4341 gitk:4445 gitk:6244
msgid "Regexp"
msgstr "正規表現"
#: gitk:2103 gitk:2104 gitk:4466 gitk:4496 gitk:4503 gitk:6372 gitk:6440
msgid "All fields"
msgstr "全ての項目"
#: gitk:2104 gitk:4464 gitk:4496 gitk:6311
msgid "Headline"
msgstr "ヘッドライン"
#: gitk:2105 gitk:4464 gitk:6311 gitk:6440 gitk:6874
msgid "Comments"
msgstr "コメント"
#: gitk:2105 gitk:4464 gitk:4468 gitk:4503 gitk:6311 gitk:6809 gitk:8071
#: gitk:8086
msgid "Author"
msgstr "作成者"
#: gitk:2105 gitk:4464 gitk:6311 gitk:6811
msgid "Committer"
msgstr "コミットした人"
#: gitk:2134
msgid "Search"
msgstr "検索"
#: gitk:2141
msgid "Diff"
msgstr "Diff"
#: gitk:2143
msgid "Old version"
msgstr "旧バージョン"
#: gitk:2145
msgid "New version"
msgstr "新バージョン"
#: gitk:2147
msgid "Lines of context"
msgstr "文脈行数"
#: gitk:2157
msgid "Ignore space change"
msgstr "空白の違いを無視"
#: gitk:2215
msgid "Patch"
msgstr "パッチ"
#: gitk:2217
msgid "Tree"
msgstr "ツリー"
#: gitk:2361 gitk:2378
msgid "Diff this -> selected"
msgstr "diff これ -> 選択"
#: gitk:2362 gitk:2379
msgid "Diff selected -> this"
msgstr "diff 選択 -> これ"
#: gitk:2363 gitk:2380
msgid "Make patch"
msgstr "パッチ作成"
#: gitk:2364 gitk:8477
msgid "Create tag"
msgstr "タグ生成"
#: gitk:2365 gitk:8583
msgid "Write commit to file"
msgstr "コミットをファイルに書き込む"
#: gitk:2366 gitk:8640
msgid "Create new branch"
msgstr "新規ブランチ生成"
#: gitk:2367
msgid "Cherry-pick this commit"
msgstr "このコミットをチェリーピックする"
#: gitk:2368
msgid "Reset HEAD branch to here"
msgstr "ブランチのHEADをここにリセットする"
#: gitk:2369
msgid "Mark this commit"
msgstr "このコミットにマークをつける"
#: gitk:2370
msgid "Return to mark"
msgstr "マークを付けた所に戻る"
#: gitk:2371
msgid "Find descendant of this and mark"
msgstr "この子孫を見つけてマークする"
#: gitk:2372
msgid "Compare with marked commit"
msgstr "マークを付けたコミットと比較する"
#: gitk:2386
msgid "Check out this branch"
msgstr "このブランチをチェックアウトする"
#: gitk:2387
msgid "Remove this branch"
msgstr "このブランチを除去する"
#: gitk:2394
msgid "Highlight this too"
msgstr "これもハイライトさせる"
#: gitk:2395
msgid "Highlight this only"
msgstr "これだけをハイライトさせる"
#: gitk:2396
msgid "External diff"
msgstr "外部diffツール"
#: gitk:2397
msgid "Blame parent commit"
msgstr "親コミットから blame をかける"
#: gitk:2404
msgid "Show origin of this line"
msgstr "この行の出自を表示する"
#: gitk:2405
msgid "Run git gui blame on this line"
msgstr "この行に git gui で blame をかける"
#: gitk:2657
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 - gitコミットビューア\n"
"\n"
"Copyright (c) 2005-2008 Paul Mackerras\n"
"\n"
"使用および再配布はGNU General Public License に従ってください"
#: gitk:2665 gitk:2727 gitk:9005
msgid "Close"
msgstr "閉じる"
#: gitk:2684
msgid "Gitk key bindings"
msgstr "Gitk キーバインディング"
#: gitk:2687
msgid "Gitk key bindings:"
msgstr "Gitk キーバインディング:"
#: gitk:2689
#, tcl-format
msgid "<%s-Q>\t\tQuit"
msgstr "<%s-Q>\t\t終了"
#: gitk:2690
msgid "<Home>\t\tMove to first commit"
msgstr "<Home>\t\t最初のコミットに移動"
#: gitk:2691
msgid "<End>\t\tMove to last commit"
msgstr "<End>\t\t最後のコミットに移動"
#: gitk:2692
msgid "<Up>, p, i\tMove up one commit"
msgstr "<Up>, p, i\t一つ上のコミットに移動"
#: gitk:2693
msgid "<Down>, n, k\tMove down one commit"
msgstr "<Down>, n, k\t一つ下のコミットに移動"
#: gitk:2694
msgid "<Left>, z, j\tGo back in history list"
msgstr "<Left>, z, j\t履歴の前に戻る"
#: gitk:2695
msgid "<Right>, x, l\tGo forward in history list"
msgstr "<Right>, x, l\t履歴の次へ進む"
#: gitk:2696
msgid "<PageUp>\tMove up one page in commit list"
msgstr "<PageUp>\tコミットリストの一つ上のページに移動"
#: gitk:2697
msgid "<PageDown>\tMove down one page in commit list"
msgstr "<PageDown>\tコミットリストの一つ下のページに移動"
#: gitk:2698
#, tcl-format
msgid "<%s-Home>\tScroll to top of commit list"
msgstr "<%s-Home>\tコミットリストの一番上にスクロールする"
#: gitk:2699
#, tcl-format
msgid "<%s-End>\tScroll to bottom of commit list"
msgstr "<%s-End>\tコミットリストの一番下にスクロールする"
#: gitk:2700
#, tcl-format
msgid "<%s-Up>\tScroll commit list up one line"
msgstr "<%s-Up>\tコミットリストの一つ下の行にスクロールする"
#: gitk:2701
#, tcl-format
msgid "<%s-Down>\tScroll commit list down one line"
msgstr "<%s-Down>\tコミットリストの一つ下の行にスクロールする"
#: gitk:2702
#, tcl-format
msgid "<%s-PageUp>\tScroll commit list up one page"
msgstr "<%s-PageUp>\tコミットリストの上のページにスクロールする"
#: gitk:2703
#, tcl-format
msgid "<%s-PageDown>\tScroll commit list down one page"
msgstr "<%s-PageDown>\tコミットリストの下のページにスクロールする"
#: gitk:2704
msgid "<Shift-Up>\tFind backwards (upwards, later commits)"
msgstr "<Shift-Up>\t後ろを検索 (上方・後のコミット)"
#: gitk:2705
msgid "<Shift-Down>\tFind forwards (downwards, earlier commits)"
msgstr "<Shift-Down>\t前を検索（下方・前のコミット）"
#: gitk:2706
msgid "<Delete>, b\tScroll diff view up one page"
msgstr "<Delete>, b\tdiff画面を上のページにスクロールする"
#: gitk:2707
msgid "<Backspace>\tScroll diff view up one page"
msgstr "<Backspace>\tdiff画面を上のページにスクロールする"
#: gitk:2708
msgid "<Space>\t\tScroll diff view down one page"
msgstr "<Space>\t\tdiff画面を下のページにスクロールする"
#: gitk:2709
msgid "u\t\tScroll diff view up 18 lines"
msgstr "u\t\tdiff画面を上に18行スクロールする"
#: gitk:2710
msgid "d\t\tScroll diff view down 18 lines"
msgstr "d\t\tdiff画面を下に18行スクロールする"
#: gitk:2711
#, tcl-format
msgid "<%s-F>\t\tFind"
msgstr "<%s-F>\t\t検索"
#: gitk:2712
#, tcl-format
msgid "<%s-G>\t\tMove to next find hit"
msgstr "<%s-G>\t\t次を検索して移動"
#: gitk:2713
msgid "<Return>\tMove to next find hit"
msgstr "<Return>\t次を検索して移動"
#: gitk:2714
msgid "/\t\tFocus the search box"
msgstr "/\t\t検索ボックスにフォーカス"
#: gitk:2715
msgid "?\t\tMove to previous find hit"
msgstr "?\t\t前を検索して移動"
#: gitk:2716
msgid "f\t\tScroll diff view to next file"
msgstr "f\t\t次のファイルにdiff画面をスクロールする"
#: gitk:2717
#, tcl-format
msgid "<%s-S>\t\tSearch for next hit in diff view"
msgstr "<%s-S>\t\tdiff画面の次を検索"
#: gitk:2718
#, tcl-format
msgid "<%s-R>\t\tSearch for previous hit in diff view"
msgstr "<%s-R>\t\tdiff画面の前を検索"
#: gitk:2719
#, tcl-format
msgid "<%s-KP+>\tIncrease font size"
msgstr "<%s-KP+>\t文字サイズを拡大"
#: gitk:2720
#, tcl-format
msgid "<%s-plus>\tIncrease font size"
msgstr "<%s-plus>\t文字サイズを拡大"
#: gitk:2721
#, tcl-format
msgid "<%s-KP->\tDecrease font size"
msgstr "<%s-KP->\t文字サイズを縮小"
#: gitk:2722
#, tcl-format
msgid "<%s-minus>\tDecrease font size"
msgstr "<%s-minus>\t文字サイズを縮小"
#: gitk:2723
msgid "<F5>\t\tUpdate"
msgstr "<F5>\t\t更新"
#: gitk:3178 gitk:3187
#, tcl-format
msgid "Error creating temporary directory %s:"
msgstr "一時ディレクトリ %s 生成時エラー:"
#: gitk:3200
#, tcl-format
msgid "Error getting \"%s\" from %s:"
msgstr ""
#: gitk:3263
msgid "command failed:"
msgstr "コマンド失敗:"
#: gitk:3409
msgid "No such commit"
msgstr "そのようなコミットはありません"
#: gitk:3423
msgid "git gui blame: command failed:"
msgstr "git gui blame: コマンド失敗:"
#: gitk:3454
#, tcl-format
msgid "Couldn't read merge head: %s"
msgstr ""
#: gitk:3462
#, tcl-format
msgid "Error reading index: %s"
msgstr "インデックス読み込みエラー: %s"
#: gitk:3487
#, tcl-format
msgid "Couldn't start git blame: %s"
msgstr "git blame を始められません: %s"
#: gitk:3490 gitk:6279
msgid "Searching"
msgstr "検索中"
#: gitk:3522
#, tcl-format
msgid "Error running git blame: %s"
msgstr "git blame 実行エラー: %s"
#: gitk:3550
#, tcl-format
msgid "That line comes from commit %s, which is not in this view"
msgstr ""
#: gitk:3564
msgid "External diff viewer failed:"
msgstr "外部diffビューアが失敗:"
#: gitk:3682
msgid "Gitk view definition"
msgstr "Gitk ビュー定義"
#: gitk:3686
msgid "Remember this view"
msgstr "このビューを記憶する"
#: gitk:3687
msgid "References (space separated list):"
msgstr "参照（スペース区切りのリスト）:"
#: gitk:3688
msgid "Branches & tags:"
msgstr "ブランチ＆タグ:"
#: gitk:3689
msgid "All refs"
msgstr "全ての参照"
#: gitk:3690
msgid "All (local) branches"
msgstr "全ての（ローカルな）ブランチ"
#: gitk:3691
msgid "All tags"
msgstr "全てのタグ"
#: gitk:3692
msgid "All remote-tracking branches"
msgstr "全てのリモート追跡ブランチ"
#: gitk:3693
msgid "Commit Info (regular expressions):"
msgstr "コミット情報（正規表現）:"
#: gitk:3694
msgid "Author:"
msgstr "作成者:"
#: gitk:3695
msgid "Committer:"
msgstr "コミットした人:"
#: gitk:3696
msgid "Commit Message:"
msgstr "コミットメッセージ:"
#: gitk:3697
msgid "Matches all Commit Info criteria"
msgstr "コミット情報の全ての条件に一致"
#: gitk:3698
msgid "Changes to Files:"
msgstr "変更したファイル:"
#: gitk:3699
msgid "Fixed String"
msgstr "固定文字列"
#: gitk:3700
msgid "Regular Expression"
msgstr "正規表現"
#: gitk:3701
msgid "Search string:"
msgstr "検索文字列:"
#: gitk:3702
msgid ""
"Commit Dates (\"2 weeks ago\", \"2009-03-17 15:27:38\", \"March 17, 2009 "
"15:27:38\"):"
msgstr "コミット日時 (\"2 weeks ago\", \"2009-03-17 15:27:38\", \"March 17, 2009 "
"15:27:38\"):"
#: gitk:3703
msgid "Since:"
msgstr "期間の始め:"
#: gitk:3704
msgid "Until:"
msgstr "期間の終わり:"
#: gitk:3705
msgid "Limit and/or skip a number of revisions (positive integer):"
msgstr ""
#: gitk:3706
msgid "Number to show:"
msgstr ""
#: gitk:3707
msgid "Number to skip:"
msgstr ""
#: gitk:3708
msgid "Miscellaneous options:"
msgstr "その他のオプション:"
#: gitk:3709
msgid "Strictly sort by date"
msgstr "厳密に日付順で並び替え"
#: gitk:3710
msgid "Mark branch sides"
msgstr ""
#: gitk:3711
msgid "Limit to first parent"
msgstr ""
#: gitk:3712
msgid "Simple history"
msgstr "簡易な履歴"
#: gitk:3713
msgid "Additional arguments to git log:"
msgstr "git log への追加の引数:"
#: gitk:3714
msgid "Enter files and directories to include, one per line:"
msgstr "含まれるファイル・ディレクトリを一行ごとに入力:"
#: gitk:3715
msgid "Command to generate more commits to include:"
msgstr ""
#: gitk:3837
msgid "Gitk: edit view"
msgstr "Gitk: ビュー編集"
#: gitk:3845
msgid "-- criteria for selecting revisions"
msgstr "― リビジョンの選択条件"
#: gitk:3850
msgid "View Name:"
msgstr "ビュー名:"
#: gitk:3925
msgid "Apply (F5)"
msgstr "適用 (F5)"
#: gitk:3963
msgid "Error in commit selection arguments:"
msgstr "コミット選択引数のエラー:"
#: gitk:4016 gitk:4068 gitk:4516 gitk:4530 gitk:5791 gitk:11232 gitk:11233
msgid "None"
msgstr "無し"
#: gitk:4464 gitk:6311 gitk:8073 gitk:8088
msgid "Date"
msgstr ""
#: gitk:4464 gitk:6311
msgid "CDate"
msgstr ""
#: gitk:4613 gitk:4618
msgid "Descendant"
msgstr "子孫"
#: gitk:4614
msgid "Not descendant"
msgstr "非子孫"
#: gitk:4621 gitk:4626
msgid "Ancestor"
msgstr "祖先"
#: gitk:4622
msgid "Not ancestor"
msgstr "非祖先"
#: gitk:4912
msgid "Local changes checked in to index but not committed"
msgstr ""
#: gitk:4948
msgid "Local uncommitted changes, not checked in to index"
msgstr ""
#: gitk:6629
msgid "many"
msgstr "多数"
#: gitk:6813
msgid "Tags:"
msgstr "タグ:"
#: gitk:6830 gitk:6836 gitk:8066
msgid "Parent"
msgstr "親"
#: gitk:6841
msgid "Child"
msgstr "子"
#: gitk:6850
msgid "Branch"
msgstr "ブランチ"
#: gitk:6853
msgid "Follows"
msgstr "下位"
#: gitk:6856
msgid "Precedes"
msgstr "上位"
#: gitk:7354
#, tcl-format
msgid "Error getting diffs: %s"
msgstr ""
#: gitk:7894
msgid "Goto:"
msgstr ""
#: gitk:7896
msgid "SHA1 ID:"
msgstr "SHA1 ID:"
#: gitk:7915
#, tcl-format
msgid "Short SHA1 id %s is ambiguous"
msgstr "短縮 SHA1 ID %s は曖昧です"
#: gitk:7922
#, tcl-format
msgid "Revision %s is not known"
msgstr "リビジョン %s は不明です"
#: gitk:7932
#, tcl-format
msgid "SHA1 id %s is not known"
msgstr "SHA1 id %s は不明です"
#: gitk:7934
#, tcl-format
msgid "Revision %s is not in the current view"
msgstr "リビジョン %s は現在のビューにはありません"
#: gitk:8076
msgid "Children"
msgstr "子供達"
#: gitk:8133
#, tcl-format
msgid "Reset %s branch to here"
msgstr "%s ブランチをここにリセットする"
#: gitk:8135
msgid "Detached head: can't reset"
msgstr ""
#: gitk:8244 gitk:8250
msgid "Skipping merge commit "
msgstr ""
#: gitk:8259 gitk:8264
msgid "Error getting patch ID for "
msgstr ""
#: gitk:8260 gitk:8265
msgid " - stopping\n"
msgstr " - 停止\n"
#: gitk:8270 gitk:8273 gitk:8281 gitk:8294 gitk:8303
msgid "Commit "
msgstr "コミット "
#: gitk:8274
msgid ""
" is the same patch as\n"
" "
msgstr ""
#: gitk:8282
msgid ""
" differs from\n"
" "
msgstr ""
#: gitk:8284
msgid ""
"Diff of commits:\n"
"\n"
msgstr ""
#: gitk:8295 gitk:8304
#, tcl-format
msgid " has %s children - stopping\n"
msgstr ""
#: gitk:8324
#, tcl-format
msgid "Error writing commit to file: %s"
msgstr ""
#: gitk:8330
#, tcl-format
msgid "Error diffing commits: %s"
msgstr ""
#: gitk:8360
msgid "Top"
msgstr ""
#: gitk:8361
msgid "From"
msgstr "From"
#: gitk:8366
msgid "To"
msgstr "To"
#: gitk:8390
msgid "Generate patch"
msgstr "パッチ生成"
#: gitk:8392
msgid "From:"
msgstr "From:"
#: gitk:8401
msgid "To:"
msgstr "To:"
#: gitk:8410
msgid "Reverse"
msgstr "逆"
#: gitk:8412 gitk:8597
msgid "Output file:"
msgstr "出力ファイル:"
#: gitk:8418
msgid "Generate"
msgstr "生成"
#: gitk:8456
msgid "Error creating patch:"
msgstr "パッチ生成エラー:"
#: gitk:8479 gitk:8585 gitk:8642
msgid "ID:"
msgstr "ID:"
#: gitk:8488
msgid "Tag name:"
msgstr "タグ名:"
#: gitk:8492 gitk:8651
msgid "Create"
msgstr "生成"
#: gitk:8509
msgid "No tag name specified"
msgstr "タグの名称が指定されていません"
#: gitk:8513
#, tcl-format
msgid "Tag \"%s\" already exists"
msgstr "タグ \"%s\" は既に存在します"
#: gitk:8519
msgid "Error creating tag:"
msgstr "タグ生成エラー:"
#: gitk:8594
msgid "Command:"
msgstr "コマンド:"
#: gitk:8602
msgid "Write"
msgstr "書き込み"
#: gitk:8620
msgid "Error writing commit:"
msgstr ""
#: gitk:8647
msgid "Name:"
msgstr "名前:"
#: gitk:8670
msgid "Please specify a name for the new branch"
msgstr "新しいブランチの名前を指定してください"
#: gitk:8675
#, tcl-format
msgid "Branch '%s' already exists. Overwrite?"
msgstr "ブランチ '%s' は既に存在します。上書きしますか？"
#: gitk:8741
#, tcl-format
msgid "Commit %s is already included in branch %s -- really re-apply it?"
msgstr "コミット %s は既にブランチ %s に含まれています ― 本当にこれを再適用しますか？"
#: gitk:8746
msgid "Cherry-picking"
msgstr "チェリーピック中"
#: gitk:8755
#, 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 ""
"ファイル '%s' のローカルな変更のためにチェリーピックは失敗しました。\n"
"あなたの変更に commit, reset, stash のいずれかを行ってからやり直してください。"
#: gitk:8761
msgid ""
"Cherry-pick failed because of merge conflict.\n"
"Do you wish to run git citool to resolve it?"
msgstr ""
"マージの衝突によってチェリーピックは失敗しました。\n"
"この解決のために git citool を実行したいですか？"
#: gitk:8777
msgid "No changes committed"
msgstr ""
#: gitk:8803
msgid "Confirm reset"
msgstr ""
#: gitk:8805
#, tcl-format
msgid "Reset branch %s to %s?"
msgstr "ブランチ %s を %s にリセットしますか？"
#: gitk:8809
msgid "Reset type:"
msgstr "Reset タイプ:"
#: gitk:8813
msgid "Soft: Leave working tree and index untouched"
msgstr "Soft: 作業ツリーもインデックスもそのままにする"
#: gitk:8816
msgid "Mixed: Leave working tree untouched, reset index"
msgstr "Mixed: 作業ツリーをそのままにして、インデックスをリセット"
#: gitk:8819
msgid ""
"Hard: Reset working tree and index\n"
"(discard ALL local changes)"
msgstr ""
"Hard: 作業ツリーやインデックスをリセット\n"
"（「全ての」ローカルな変更を破棄）"
#: gitk:8836
msgid "Resetting"
msgstr "リセット中"
#: gitk:8893
msgid "Checking out"
msgstr "チェックアウト"
#: gitk:8946
msgid "Cannot delete the currently checked-out branch"
msgstr ""
#: gitk:8952
#, tcl-format
msgid ""
"The commits on branch %s aren't on any other branch.\n"
"Really delete branch %s?"
msgstr ""
"ブランチ %s 上のコミットは他のブランチに存在しません。\n"
"本当にブランチ %s を削除しますか？"
#: gitk:8983
#, tcl-format
msgid "Tags and heads: %s"
msgstr "タグとHEAD: %s"
#: gitk:8998
msgid "Filter"
msgstr "フィルター"
#: gitk:9293
msgid ""
"Error reading commit topology information; branch and preceding/following "
"tag information will be incomplete."
msgstr ""
#: gitk:10279
msgid "Tag"
msgstr "タグ"
#: gitk:10279
msgid "Id"
msgstr "ID"
#: gitk:10327
msgid "Gitk font chooser"
msgstr "Gitk フォント選択"
#: gitk:10344
msgid "B"
msgstr "B"
#: gitk:10347
msgid "I"
msgstr "I"
#: gitk:10443
msgid "Gitk preferences"
msgstr "Gitk 設定"
#: gitk:10445
msgid "Commit list display options"
msgstr "コミットリスト表示オプション"
#: gitk:10448
msgid "Maximum graph width (lines)"
msgstr "最大グラフ幅（線の本数）"
#: gitk:10452
#, tcl-format
msgid "Maximum graph width (% of pane)"
msgstr "最大グラフ幅（ペインに対する％）"
#: gitk:10456
msgid "Show local changes"
msgstr "ローカルな変更を表示"
#: gitk:10459
msgid "Auto-select SHA1"
msgstr "SHA1 の自動選択"
#: gitk:10463
msgid "Diff display options"
msgstr "diff表示オプション"
#: gitk:10465
msgid "Tab spacing"
msgstr "タブ空白幅"
#: gitk:10468
msgid "Display nearby tags"
msgstr "近くのタグを表示する"
#: gitk:10471
msgid "Hide remote refs"
msgstr "リモート参照を隠す"
#: gitk:10474
msgid "Limit diffs to listed paths"
msgstr ""
#: gitk:10477
msgid "Support per-file encodings"
msgstr "ファイルごとのエンコーディングのサポート"
#: gitk:10483 gitk:10548
msgid "External diff tool"
msgstr "外部diffツール"
#: gitk:10485
msgid "Choose..."
msgstr "選択..."
#: gitk:10490
msgid "Colors: press to choose"
msgstr "色: ボタンを押して選択"
#: gitk:10493
msgid "Background"
msgstr "背景"
#: gitk:10494 gitk:10524
msgid "background"
msgstr "背景"
#: gitk:10497
msgid "Foreground"
msgstr "前景"
#: gitk:10498
msgid "foreground"
msgstr "前景"
#: gitk:10501
msgid "Diff: old lines"
msgstr "Diff: 旧バージョン"
#: gitk:10502
msgid "diff old lines"
msgstr "diff 旧バージョン"
#: gitk:10506
msgid "Diff: new lines"
msgstr "Diff: 新バージョン"
#: gitk:10507
msgid "diff new lines"
msgstr "diff 新バージョン"
#: gitk:10511
msgid "Diff: hunk header"
msgstr "Diff: hunkヘッダ"
#: gitk:10513
msgid "diff hunk header"
msgstr "diff hunkヘッダ"
#: gitk:10517
msgid "Marked line bg"
msgstr "マーク行の背景"
#: gitk:10519
msgid "marked line background"
msgstr "マーク行の背景"
#: gitk:10523
msgid "Select bg"
msgstr "選択の背景"
#: gitk:10527
msgid "Fonts: press to choose"
msgstr "フォント: ボタンを押して選択"
#: gitk:10529
msgid "Main font"
msgstr "主フォント"
#: gitk:10530
msgid "Diff display font"
msgstr "Diff表示用フォント"
#: gitk:10531
msgid "User interface font"
msgstr "UI用フォント"
#: gitk:10558
#, tcl-format
msgid "Gitk: choose color for %s"
msgstr "Gitk: 「%s」 の色を選択"
#: gitk:11009
msgid ""
"Sorry, gitk cannot run with this version of Tcl/Tk.\n"
" Gitk requires at least Tcl/Tk 8.4."
msgstr ""
"申し訳ありませんが、このバージョンの Tcl/Tk では gitk を実行できません。\n"
" Gitk は少なくとも Tcl/Tk 8.4 を必要とします。"
#: gitk:11137
msgid "Cannot find a git repository here."
msgstr "ここにはgitリポジトリがありません。"
#: gitk:11141
#, tcl-format
msgid "Cannot find the git directory \"%s\"."
msgstr "gitディレクトリ \"%s\" を見つけられません。"
#: gitk:11188
#, tcl-format
msgid "Ambiguous argument '%s': both revision and filename"
msgstr "あいまいな引数 '%s': リビジョンとファイル名の両方に解釈できます"
#: gitk:11200
msgid "Bad arguments to gitk:"
msgstr "gitkへの不正な引数:"
#: gitk:11285
msgid "Command line"
msgstr "コマンド行"
^ permalink raw reply
* [PATCH] gitignore: root most patterns at the top-level directory
From: Jeff King @ 2009-10-27 1:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Our gitignore doesn't use a preceding "/" to root its
patterns in the top of the repository. This means that if
you add a file or directory called "git" (for example)
inside a subdirectory, it will be erroneously ignored.
This patch was done mechanically with "s/^[^*]/\/&/" with
one exception: instead of ignoring gitk-wish, we should
gitk-git/gitk-wish (arguably, this should be done in
gitk-git/.gitignore, but because that is a subtree merge
from elsewhere, this is easier).
Acked-by: Sverre Rabbelier <srabbelier@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
---
This bit Sverre while I was looking over his shoulder. I doubt it comes
up very often, but we should probably be modeling good gitignore
behavior. I have to admit it looks a lot uglier, though.
.gitignore | 354 ++++++++++++++++++++++++++++++------------------------------
1 files changed, 177 insertions(+), 177 deletions(-)
diff --git a/.gitignore b/.gitignore
index 51a37b1..289c3d0 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,184 +1,184 @@
-GIT-BUILD-OPTIONS
-GIT-CFLAGS
-GIT-GUI-VARS
-GIT-VERSION-FILE
-git
-git-add
-git-add--interactive
-git-am
-git-annotate
-git-apply
-git-archimport
-git-archive
-git-bisect
-git-bisect--helper
-git-blame
-git-branch
-git-bundle
-git-cat-file
-git-check-attr
-git-check-ref-format
-git-checkout
-git-checkout-index
-git-cherry
-git-cherry-pick
-git-clean
-git-clone
-git-commit
-git-commit-tree
-git-config
-git-count-objects
-git-cvsexportcommit
-git-cvsimport
-git-cvsserver
-git-daemon
-git-diff
-git-diff-files
-git-diff-index
-git-diff-tree
-git-difftool
-git-difftool--helper
-git-describe
-git-fast-export
-git-fast-import
-git-fetch
-git-fetch--tool
-git-fetch-pack
-git-filter-branch
-git-fmt-merge-msg
-git-for-each-ref
-git-format-patch
-git-fsck
-git-fsck-objects
-git-gc
-git-get-tar-commit-id
-git-grep
-git-hash-object
-git-help
-git-http-fetch
-git-http-push
-git-imap-send
-git-index-pack
-git-init
-git-init-db
-git-instaweb
-git-log
-git-lost-found
-git-ls-files
-git-ls-remote
-git-ls-tree
-git-mailinfo
-git-mailsplit
-git-merge
-git-merge-base
-git-merge-index
-git-merge-file
-git-merge-tree
-git-merge-octopus
-git-merge-one-file
-git-merge-ours
-git-merge-recursive
-git-merge-resolve
-git-merge-subtree
-git-mergetool
-git-mergetool--lib
-git-mktag
-git-mktree
-git-name-rev
-git-mv
-git-pack-redundant
-git-pack-objects
-git-pack-refs
-git-parse-remote
-git-patch-id
-git-peek-remote
-git-prune
-git-prune-packed
-git-pull
-git-push
-git-quiltimport
-git-read-tree
-git-rebase
-git-rebase--interactive
-git-receive-pack
-git-reflog
-git-relink
-git-remote
-git-remote-curl
-git-repack
-git-replace
-git-repo-config
-git-request-pull
-git-rerere
-git-reset
-git-rev-list
-git-rev-parse
-git-revert
-git-rm
-git-send-email
-git-send-pack
-git-sh-setup
-git-shell
-git-shortlog
-git-show
-git-show-branch
-git-show-index
-git-show-ref
-git-stage
-git-stash
-git-status
-git-stripspace
-git-submodule
-git-svn
-git-symbolic-ref
-git-tag
-git-tar-tree
-git-unpack-file
-git-unpack-objects
-git-update-index
-git-update-ref
-git-update-server-info
-git-upload-archive
-git-upload-pack
-git-var
-git-verify-pack
-git-verify-tag
-git-web--browse
-git-whatchanged
-git-write-tree
-git-core-*/?*
-gitk-wish
-gitweb/gitweb.cgi
-test-chmtime
-test-ctype
-test-date
-test-delta
-test-dump-cache-tree
-test-genrandom
-test-match-trees
-test-parse-options
-test-path-utils
-test-sha1
-test-sigchain
-common-cmds.h
+/GIT-BUILD-OPTIONS
+/GIT-CFLAGS
+/GIT-GUI-VARS
+/GIT-VERSION-FILE
+/git
+/git-add
+/git-add--interactive
+/git-am
+/git-annotate
+/git-apply
+/git-archimport
+/git-archive
+/git-bisect
+/git-bisect--helper
+/git-blame
+/git-branch
+/git-bundle
+/git-cat-file
+/git-check-attr
+/git-check-ref-format
+/git-checkout
+/git-checkout-index
+/git-cherry
+/git-cherry-pick
+/git-clean
+/git-clone
+/git-commit
+/git-commit-tree
+/git-config
+/git-count-objects
+/git-cvsexportcommit
+/git-cvsimport
+/git-cvsserver
+/git-daemon
+/git-diff
+/git-diff-files
+/git-diff-index
+/git-diff-tree
+/git-difftool
+/git-difftool--helper
+/git-describe
+/git-fast-export
+/git-fast-import
+/git-fetch
+/git-fetch--tool
+/git-fetch-pack
+/git-filter-branch
+/git-fmt-merge-msg
+/git-for-each-ref
+/git-format-patch
+/git-fsck
+/git-fsck-objects
+/git-gc
+/git-get-tar-commit-id
+/git-grep
+/git-hash-object
+/git-help
+/git-http-fetch
+/git-http-push
+/git-imap-send
+/git-index-pack
+/git-init
+/git-init-db
+/git-instaweb
+/git-log
+/git-lost-found
+/git-ls-files
+/git-ls-remote
+/git-ls-tree
+/git-mailinfo
+/git-mailsplit
+/git-merge
+/git-merge-base
+/git-merge-index
+/git-merge-file
+/git-merge-tree
+/git-merge-octopus
+/git-merge-one-file
+/git-merge-ours
+/git-merge-recursive
+/git-merge-resolve
+/git-merge-subtree
+/git-mergetool
+/git-mergetool--lib
+/git-mktag
+/git-mktree
+/git-name-rev
+/git-mv
+/git-pack-redundant
+/git-pack-objects
+/git-pack-refs
+/git-parse-remote
+/git-patch-id
+/git-peek-remote
+/git-prune
+/git-prune-packed
+/git-pull
+/git-push
+/git-quiltimport
+/git-read-tree
+/git-rebase
+/git-rebase--interactive
+/git-receive-pack
+/git-reflog
+/git-relink
+/git-remote
+/git-remote-curl
+/git-repack
+/git-replace
+/git-repo-config
+/git-request-pull
+/git-rerere
+/git-reset
+/git-rev-list
+/git-rev-parse
+/git-revert
+/git-rm
+/git-send-email
+/git-send-pack
+/git-sh-setup
+/git-shell
+/git-shortlog
+/git-show
+/git-show-branch
+/git-show-index
+/git-show-ref
+/git-stage
+/git-stash
+/git-status
+/git-stripspace
+/git-submodule
+/git-svn
+/git-symbolic-ref
+/git-tag
+/git-tar-tree
+/git-unpack-file
+/git-unpack-objects
+/git-update-index
+/git-update-ref
+/git-update-server-info
+/git-upload-archive
+/git-upload-pack
+/git-var
+/git-verify-pack
+/git-verify-tag
+/git-web--browse
+/git-whatchanged
+/git-write-tree
+/git-core-*/?*
+/gitk-git/gitk-wish
+/gitweb/gitweb.cgi
+/test-chmtime
+/test-ctype
+/test-date
+/test-delta
+/test-dump-cache-tree
+/test-genrandom
+/test-match-trees
+/test-parse-options
+/test-path-utils
+/test-sha1
+/test-sigchain
+/common-cmds.h
*.tar.gz
*.dsc
*.deb
-git.spec
+/git.spec
*.exe
*.[aos]
*.py[co]
-config.mak
-autom4te.cache
-config.cache
-config.log
-config.status
-config.mak.autogen
-config.mak.append
-configure
-tags
-TAGS
-cscope*
+/config.mak
+/autom4te.cache
+/config.cache
+/config.log
+/config.status
+/config.mak.autogen
+/config.mak.append
+/configure
+/tags
+/TAGS
+/cscope*
*.obj
*.lib
*.sln
@@ -188,5 +188,5 @@ cscope*
*.user
*.idb
*.pdb
-Debug/
-Release/
+/Debug/
+/Release/
--
1.6.5.1.203.g342e8
^ permalink raw reply related
* Re: git vs hg commit counts?
From: Jakub Narebski @ 2009-10-27 1:14 UTC (permalink / raw)
To: Joe Perches; +Cc: LKML, git, mercurial, Marti Raudsepp
In-Reply-To: <1256602127.29938.8.camel@Joe-Laptop.home>
Joe Perches <joe@perches.com> writes:
> I'm comparing linux-kernel git vs hg repositories.
>
> While testing some changes to scripts/get_maintainer.pl,
> I noticed that git and hg have different commit counts
> for the same files.
>
> For instance:
>
> $ git log --since=1-year-ago -- MAINTAINERS | \
> grep -P "^commit [0-9a-f]{40,40}$" | wc -l
> 514
>
> $ hg log --template="commit {node}\n" --date -365 -- MAINTAINERS | \
> grep -P "^commit [0-9a-f]{40,40}$" | wc -l
> 601
>
> Anyone have any understanding why?
It *might* be caused by the fact that in Mercurial commit can have
only up to two parents. This means that octopus merges (merge commits
with more than two parents: there are a few of them in linux-kernel
history) have to be represented as a set of two-parent merges.
--
Jakub Narebski
http://stackoverflow.com/questions/1598759/git-and-mercurial-compare-and-contrast/1599930#1599930
^ permalink raw reply
* Re: git vs hg commit counts?
From: Marti Raudsepp @ 2009-10-27 1:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Joe Perches, LKML, git, mercurial
In-Reply-To: <7v8wexd6zq.fsf@alter.siamese.dyndns.org>
On Tue, Oct 27, 2009 at 2:18 AM, Junio C Hamano <gitster@pobox.com> wrote:
> We simplify a merge history by discarding one branch when the merge result
> matches one of the parents. Does "hg" know how to do that as well?
57 of the differing changesets are normal merges (probably what Junio explained)
3 are duplicate changesets in hg, probably also related to that
27 changesets are octopus merge fixups
wrt octopus merges: in git, one merge commit can have an arbitrary
number of parents, but in hg a merge changeset always has 2 parents --
so a octopus merge is represented as multiple distinct changesets.
Marti
^ 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