* A note from the maintainer
From: Junio C Hamano @ 2013-01-28 20:48 UTC (permalink / raw)
To: git
Welcome to the Git development community.
This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.
* Mailing list and the community
The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>. You don't have to be
subscribed to send messages. The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".
Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.
If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise. Please
do not hesitate to send a reminder message in such a case. Messages
getting lost in the noise is a sign that people involved don't have
enough mental/time bandwidth to process them right at the moment, and
it often helps to wait until the list traffic becomes calmer before
sending such a reminder.
The list archive is available at a few public sites:
http://news.gmane.org/gmane.comp.version-control.git/
http://marc.theaimsgroup.com/?l=git
http://www.spinics.net/lists/git/
For those who prefer to read it over NNTP (including the maintainer):
nntp://news.gmane.org/gmane.comp.version-control.git
When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:
http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217
as it also allows people who subscribe to the mailing list as gmane
newsgroup to "jump to" the article.
Some members of the development community can sometimes also be found
on the #git IRC channel on Freenode. Its log is available at:
http://colabti.org/irclogger/irclogger_log/git
* Reporting bugs
When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work". "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken". It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.
Please remember to always state
- what you wanted to achieve;
- what you did (the version of git and the command sequence to reproduce
the behavior);
- what you saw happen (X above);
- what you expected to see (Y above); and
- how the last two are different.
See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.
* Repositories, branches and documentation.
My public git.git repositories are at:
git://git.kernel.org/pub/scm/git/git.git/
git://repo.or.cz/alt-git.git/
https://github.com/git/git/
https://code.google.com/p/git-core/
git://git.sourceforge.jp/gitroot/git-core/git.git/
git://git-core.git.sourceforge.net/gitroot/git-core/git-core/
A few gitweb interfaces are found at:
http://git.kernel.org/?p=git/git.git
http://repo.or.cz/w/alt-git.git
Preformatted documentation from the tip of the "master" branch can be
found in:
git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
git://repo.or.cz/git-{htmldocs,manpages}.git/
https://code.google.com/p/git-{htmldocs,manpages}.git/
https://github.com/gitster/git-{htmldocs,manpages}.git/
You can browse the HTML manual pages at:
http://git-htmldocs.googlecode.com/git/git.html
There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "pu".
The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting. Every now and then, a
"feature release" is cut from the tip of this branch and they
typically are named with three dotted decimal digits. The last such
release was 1.8.1 done on Dec 31, 2012 (or Jan 1, 2013, depending on
where you were when it happened). You can expect that the tip of the
"master" branch is always more stable than any of the released
versions.
Whenever a feature release is made, "maint" branch is forked off from
"master" at that point. Obvious, safe and urgent fixes after a feature
release are applied to this branch and maintenance releases are cut from
it. The maintenance releases are named with four dotted decimal, named
after the feature release they are updates to; the last such release was
1.8.1.2. New features never go to this branch. This branch is also
merged into "master" to propagate the fixes forward as needed.
A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" and your patches are queued
there, and kept out of "master" while people test it out. The quality of
topic branches are judged primarily by the mailing list discussions.
Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master". It might
not be quite rock-solid, but is expected to work more or less without major
breakage. The "next" branch is where new and exciting things take place. A
topic that is in "next" is expected to be polished to perfection before it
is merged to "master".
The "pu" (proposed updates) branch bundles all the remaining topic branches.
The topics on the branch are not complete, well tested, nor well documented
and need further work. When a topic that was in "pu" proves to be in a
testable shape, it is merged to "next".
You can run "git log --first-parent master..pu" to see what topics are
currently in flight. Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "pu" in such a case.
The two branches "master" and "maint" are never rewound, and "next"
usually will not be either. After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.
Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release. There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged.
* Other people's trees, trusted lieutenants and credits.
Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent. As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.
Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:
- git-gui/ comes from git-gui project, maintained by Pat Thoyts:
git://repo.or.cz/git-gui.git
- gitk-git/ comes from Paul Mackerras's gitk project:
git://ozlabs.org/~paulus/gitk
- po/ comes from the localization coordinator, Jiang Xin:
https://github.com/git-l10n/git-po/
I would like to thank everybody who helped to raise git into the current
shape. Especially I would like to thank the git list regulars whose help
I have relied on and expect to continue relying on heavily:
- Linus Torvalds, Shawn Pearce, Johannes Schindelin, Nicolas Pitre,
René Scharfe, Jeff King, Jonathan Nieder, Johan Herland, Johannes
Sixt, Sverre Rabbelier, Michael J Gruber, Nguyễn Thái Ngọc Duy,
Ævar Arnfjörð Bjarmason and Thomas Rast for helping with general
design and implementation issues and reviews on the mailing list.
- Shawn and Nicolas Pitre for helping with packfile design and
implementation issues.
- Martin Langhoff, Frank Lichtenheld and Ævar Arnfjörð Bjarmason for
cvsserver and cvsimport.
- Paul Mackerras for gitk.
- Eric Wong, David D. Kilzer and Sam Vilain for git-svn.
- Simon Hausmann, Pete Wyckoff and Luke Diamond for git-p4.
- Jakub Narebski, John Hawley, Petr Baudis, Luben Tuikov, Giuseppe
Bilotta for maintaining and enhancing gitweb.
- Ævar Arnfjörð Bjarmason for kicking off the i18n effort, and Jiang
Xin for volunteering to be the l10n coordinator.
- Jens Lehmann, Heiko Voigt and Lars Hjemli for submodule related
Porcelains.
- J. Bruce Fields, Jonathan Nieder, Michael J Gruber and Thomas Rast for
documentation (and countless others for proofreading and fixing).
- Alexandre Julliard for Emacs integration.
- David Aguilar and Charles Bailey for taking good care of git-mergetool
(and Theodore Ts'o for creating it in the first place) and git-difftool.
- Johannes Schindelin, Johannes Sixt, Erik Faye-Lund, Pat Thoyts and others
for their effort to move things forward on the Windows front.
- People on non-Linux platforms for keeping their eyes on portability;
especially, Randal Schwartz, Theodore Ts'o, Jason Riedy, Thomas Glanzmann,
Brandon Casey, Jeff King, Alex Riesen and countless others.
^ permalink raw reply
* Re: Bug: file named - on git commit
From: Jonathan Nieder @ 2013-01-28 20:41 UTC (permalink / raw)
To: Thomas Rast; +Cc: Rene Moser, git
In-Reply-To: <87txq11sbk.fsf@pctrast.inf.ethz.ch>
Hi,
Thomas Rast wrote:
> Rene Moser <mail@renemoser.net> writes:
>> Found a little issue in git version 1.7.9.5 if a file named "-", causing
>> "git commit" to read from stdin.
>>
>> (So you must hit ctrl-d or ctrl-c to finish the commit.)
[...]
> This was fixed by Junio around 4682d85 (diff-index.c: "git diff" has no
> need to read blob from the standard input, 2012-06-27), which is
> included starting with v1.7.12 and the v1.7.11.3 maint release. Please
> upgrade.
Should upgrade-averse folks stuck on 1.7.10.y (like Debian 7.0, which
is currently in the release candidate stage) take this fix? Do you
happen to know of any other fixes such people would want?
Thanks,
Jonathan
^ permalink raw reply
* [ANNOUNCE] Git v1.8.1.2
From: Junio C Hamano @ 2013-01-28 20:41 UTC (permalink / raw)
To: git; +Cc: Linux Kernel
The latest maintenance release Git v1.8.1.2 is now available at the
usual places. This contains a handful of fixes that will also
appear in the next feature release.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
29a2dee568b1f86e9d3d8f9dcc376f24439b6a0c git-1.8.1.2.tar.gz
3df491003d026b8f4b2de378e57b930a98f0a595 git-htmldocs-1.8.1.2.tar.gz
142222a27dfec52256831f2d0e2ee655f75c1077 git-manpages-1.8.1.2.tar.gz
Also the following public repositories all have a copy of the v1.8.1.2
tag and the maint branch that the tag points at:
url = git://repo.or.cz/alt-git.git
url = https://code.google.com/p/git-core/
url = git://git.sourceforge.jp/gitroot/git-core/git.git
url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
url = https://github.com/gitster/git
Git 1.8.1.2 Release Notes
=========================
Fixes since v1.8.1.1
--------------------
* An element on GIT_CEILING_DIRECTORIES list that does not name the
real path to a directory (i.e. a symbolic link) could have caused
the GIT_DIR discovery logic to escape the ceiling.
* Command line completion for "tcsh" emitted an unwanted space
after completing a single directory name.
* Command line completion leaked an unnecessary error message while
looking for possible matches with paths in <tree-ish>.
* "git archive" did not record uncompressed size in the header when
streaming a zip archive, which confused some implementations of unzip.
* When users spelled "cc:" in lowercase in the fake "header" in the
trailer part, "git send-email" failed to pick up the addresses from
there. As e-mail headers field names are case insensitive, this
script should follow suit and treat "cc:" and "Cc:" the same way.
Also contains various documentation fixes.
----------------------------------------------------------------
Changes since v1.8.1.1 are as follows:
Antoine Pelisse (3):
dir.c: Make git-status --ignored more consistent
git-status: Test --ignored behavior
status: always report ignored tracked directories
Dylan Smith (1):
git-completion.bash: silence "not a valid object" errors
Eric S. Raymond (1):
Remove the suggestion to use parsecvs, which is currently broken.
John Keeping (1):
git-for-each-ref.txt: 'raw' is a supported date format
Jonathan Nieder (1):
contrib/vim: simplify instructions for old vim support
Junio C Hamano (2):
Start preparing for 1.8.1.2
Git 1.8.1.2
Marc Khouzam (1):
Prevent space after directories in tcsh completion
Michael Haggerty (8):
Introduce new static function real_path_internal()
real_path_internal(): add comment explaining use of cwd
Introduce new function real_path_if_valid()
longest_ancestor_length(): use string_list_split()
longest_ancestor_length(): take a string_list argument for prefixes
longest_ancestor_length(): require prefix list entries to be normalized
setup_git_directory_gently_1(): resolve symlinks in ceiling paths
string_list_longest_prefix(): remove function
Nguyễn Thái Ngọc Duy (1):
attr: make it build with DEBUG_ATTR again
Nickolai Zeldovich (1):
git-send-email: treat field names as case-insensitively
Peter Eisentraut (1):
git-commit-tree(1): correct description of defaults
René Scharfe (5):
archive-zip: write uncompressed size into header even with streaming
t0024, t5000: clear variable UNZIP, use GIT_UNZIP instead
t0024, t5000: use test_lazy_prereq for UNZIP
t5000, t5003: move ZIP tests into their own script
t5003: check if unzip supports symlinks
Sebastian Staudt (1):
config.txt: Document help.htmlpath config parameter
^ permalink raw reply
* Re: [PATCH v2 3/4] mergetool--lib: Add functions for finding available tools
From: Junio C Hamano @ 2013-01-28 20:36 UTC (permalink / raw)
To: John Keeping; +Cc: David Aguilar, git
In-Reply-To: <20130128193700.GB7498@serenity.lan>
John Keeping <john@keeping.me.uk> writes:
>> + printf "%s%s\n" "$per_line_prefix" "$tool"
>
> This needs to be:
>
> printf "$per_line_prefix%s\n" "$tool"
>
> since $per_line_prefix is usually '\t\t' which isn't expanded if we
> format it with %s - an alternative would be to change the value passed
> in to '$TAB$TAB' with literal tabs.
I would prefer the latter, actually. I do understand the
convenience of being able to write backslash-t, but I do not think
it outweighs the potential risk of mistakingly passing a string with
per-cent in it.
^ permalink raw reply
* Re: [PATCH v4 1/2] for-each-repo: new command used for multi-repo operations
From: Junio C Hamano @ 2013-01-28 20:34 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Lars Hjemli, Jonathan Nieder, git, Heiko Voigt
In-Reply-To: <5106DBB7.70007@web.de>
Jens Lehmann <Jens.Lehmann@web.de> writes:
> Am 28.01.2013 19:51, schrieb Junio C Hamano:
>> Lars Hjemli <hjemli@gmail.com> writes:
>>
>>>> Come to think of it, is there a reason why "for-each-repo" should
>>>> not be an extention to "submodule foreach"? We can view this as
>>>> visiting repositories that _could_ be registered as a submodule, in
>>>> addition to iterating over the registered submodules, no?
>>>
>>> Yes, but I see some possible problems with that approach:
>>> -'git for-each-repo' does not need to be started from within a git worktree
>>
>> True, but "git submodule foreach --untracked" can be told that it is
>> OK not (yet) to be in any superproject, no?
>
> Hmm, I'm not sure how that would work as it looks for gitlinks
> in the index which point to work tree paths.
I was imagining that "foreach --untracked" could go something like this:
* If you are inside an existing git repository, read its index to
learn the gitlinks in the directory and its subdirectories.
* Start from the current directory and recursively apply the
procedure in this step:
* Scan the directory and iterate over the ones that has ".git" in
it:
* If it is a gitlinked one, show it, but do not descend into it
unless --recursive is given (e.g. you start from /home/jens,
find /home/jens/proj/ directory that has /home/jens/proj/.git
in it. /home/jens/.git/index knows that it is a submodule of
the top-level superproject. "proj" is handled, and it is up
to the --recursive option if its submodules are handled).
* If it is _not_ a gitlinked one, show it and descend into it
(e.g. /home/jens/ is not a repository or /home/jens/proj is
not a tracked submodule) to apply this procedure recursively.
Of course, without --untracked, we have no need to iterate over the
readdir() return values; instead we just scan the index of the
top-level superproject.
>>> -'git for-each-repo' and 'git submodule foreach' have different
>>> semantics for --dirty and --clean
>
> I'm confused, what semantics of --dirty and --clean does current
> 'git submodule foreach' have? I can't find any sign of it in the
> current code ... did I miss something while skimming through this
> thread? Or are you talking about status and diff here?
I think Lars is hinting that "submodule foreach" could restrict its
operation to a similar --dirty/--clean/--both option he has. Of
course, the command given to foreach can decide to become no-op by
inspecting the submodule itself, so in that sense, --dirty/--clean
can be done without, but I think it would make sense to have it in
"submodule foreach" even without the "--untracked" option.
> But I think the current for-each-repo
> proposal doesn't allow to traverse repos which contain untracked
> content (and it would be nice if the user could somehow combine
> that with the current --dirty flag to have both in one go).
Perhaps. I personally felt it was really strange that submodule
diff and status consider that it is a sin to have untracked and
unignored cruft in the submodule working tree, though.
^ permalink raw reply
* Re: [PATCH] l10n: de.po: translate 11 new messages
From: Philip Oakley @ 2013-01-28 20:33 UTC (permalink / raw)
To: Ralf Thielow, Thomas Rast; +Cc: jk, stimming, Git List
In-Reply-To: <20130128175514.GA2926@rath-ubuntu>
From: "Ralf Thielow" <ralf.thielow@gmail.com>
Sent: Monday, January 28, 2013 5:55 PM
> On Mon, Jan 28, 2013 at 11:33:09AM +0100, Thomas Rast wrote:
>> Ralf Thielow <ralf.thielow@gmail.com> writes:
>>
>> > #: builtin/reset.c:275
>> > -#, fuzzy, c-format
>> > +#, c-format
>> > msgid "Failed to resolve '%s' as a valid revision."
>> > -msgstr "Konnte '%s' nicht als gültige Referenz auflösen."
>> > +msgstr "Konnte '%s' nicht als gültige Revision auflösen."
>>
>> You don't have "revision" in the glossary[1] yet. Wouldn't it be
>> appropriate to treat it as "commit", and translate as "Version" to
>> avoid
>> introducing yet another term?
>>
>> Or am I missing some subtle distinction between commit and revision?
>>
>
> I don't think there's a distinction.
It was a problem I had http://stackoverflow.com/a/11792712/717355
answered as:
See "SPECIFYING REVISIONS" of git rev-parse:
A revision parameter <rev> typically, but not necessarily, names a
commit object.
It uses what is called an extended SHA1 syntax, [and includes] various
ways to spell object names.
It had me confused for a while.
> Since we've already translated
> "revision" as "Revision" in a couple of other messages, I'll make a
> new "s/Revision/Version" commit on top.
>
>> Since it's only a single nit, feel free to add my ack when you
>> reroll:
>>
>> Acked-by: Thomas Rast <trast@inf.ethz.ch>
>>
>>
>> [1] https://github.com/ralfth/git-po-de/wiki/Glossary
>>
>> --
>> Thomas Rast
>> trast@{inf,student}.ethz.ch
> --
Philip Oakley
^ permalink raw reply
* Re: [feature request] git add completion should exclude staged content
From: Manlio Perillo @ 2013-01-28 20:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael J Gruber, wookietreiber, git
In-Reply-To: <7vd2wpxki1.fsf@alter.siamese.dyndns.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Il 28/01/2013 18:52, Junio C Hamano ha scritto:
> [...]
>
> Thanks both for commenting. I'll find time to read it over again
> and perhaps we can merge it to 'next' and advertise it in the next
> issue of "What's cooking" report to ask for wider testing to move it
> forward.
Thanks.
I will try to update the patch, with your latest suggestions (avoid
tricky POSIX shell syntax, and CDPATH issue - if I remember correctly),
and with an update for the t/t9902-completion.sh test (that I completely
missed).
Regards Manlio
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlEG3IcACgkQscQJ24LbaUTR/wCfSC/kHxseKAQ9rnK2ba/WwND1
cmsAn2CuHpRs2VjippTwkT5O3ul9cQKb
=5Way
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH v4 1/2] for-each-repo: new command used for multi-repo operations
From: Jens Lehmann @ 2013-01-28 20:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Lars Hjemli, Jonathan Nieder, git, Heiko Voigt
In-Reply-To: <7vr4l5w385.fsf@alter.siamese.dyndns.org>
Am 28.01.2013 19:51, schrieb Junio C Hamano:
> Lars Hjemli <hjemli@gmail.com> writes:
>
>>> Come to think of it, is there a reason why "for-each-repo" should
>>> not be an extention to "submodule foreach"? We can view this as
>>> visiting repositories that _could_ be registered as a submodule, in
>>> addition to iterating over the registered submodules, no?
>>
>> Yes, but I see some possible problems with that approach:
>> -'git for-each-repo' does not need to be started from within a git worktree
>
> True, but "git submodule foreach --untracked" can be told that it is
> OK not (yet) to be in any superproject, no?
Hmm, I'm not sure how that would work as it looks for gitlinks
in the index which point to work tree paths.
>> -'git for-each-repo' and 'git submodule foreach' have different
>> semantics for --dirty and --clean
I'm confused, what semantics of --dirty and --clean does current
'git submodule foreach' have? I can't find any sign of it in the
current code ... did I miss something while skimming through this
thread? Or are you talking about status and diff here?
> That could be a problem. Is there a good reason why they should use
> different definitions of dirtyness?
I don't see any (except of course for comparing a gitlink with the
HEAD of the submodule, which is an additional condition that only
applies to submodules). But I think the current for-each-repo
proposal doesn't allow to traverse repos which contain untracked
content (and it would be nice if the user could somehow combine
that with the current --dirty flag to have both in one go).
>> -'git for-each-repo' is in C because my 'git-all' shell script was
>> horribly slow on large directory trees (especially on windows)
>
> Your for-each-repo could be a good basis to build a new builtin
> "submodule--foreach" that is a pure helper hidden from the end users
> that does both; cmd_foreach() in git-submodule.sh can simply delegate
> to it.
I like that approach, because the operations are very similar from
the user's point of view. But please remember that internally they
would work differently, as submodule foreach walks the index and
only descends into those submodules that are populated (and contain
a .git directory or file) while for-each-repo scans the whole work
tree, which makes it a more expensive operation.
>> All of these problems are probably solvable, but it would require
>> quite some reworking of git-submodule.sh
>
> Of course some work is needed, but we do not have to convert all the
> cmd_foo in git-submodule.sh in one step. For the purpose of
> unifying for-each-repo and submodule foreach to deliver the
> functionality sooner to the end users, we can go the route to add
> only the submodule--foreach builtin, out of which we will get
> reusable implementation of module_list and other helper functions we
> can leverage later to do other cmd_foo functions.
I really like that idea!
^ permalink raw reply
* Re: [feature request] git add completion should exclude staged content
From: Manlio Perillo @ 2013-01-28 20:13 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Junio C Hamano, wookietreiber, git
In-Reply-To: <5106A5CE.3000800@drmicha.warpmail.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Il 28/01/2013 17:22, Michael J Gruber ha scritto:
> [...]
>> The patch will suggest (for git add command), all the files that are
>> candidate to be added to the index file.
>>
>> Please, test it and report any behaviour you think is incorrect.
>
> OK, that seems to work and to be quite helpful.
>
> Minor nit: "git add -u" could use the same fileset as "git commit". But
> I don't know whether completion can act upon the presence of options.
It is possible, but I have not implemented since I was not sure about it
and I wanted to avoid to make the patch more hard to review.
I will work on it after the patch is approved.
> Currently, it also includes untracked files (just like without -u) but
> omits unmodified and ignored ones, which is already quite an improvement.
>
> I won't be able to review the completion code but may contribute a few
> lines to t/t9902-completion.sh, possibly.
>
Ah, I missed this test; thanks.
The proposed patch must update it.
Regards Manlio
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlEG2+UACgkQscQJ24LbaURstACfdNxuFvaokBSTls20bSQ7jPHA
8I0An3fX6oRKuc2lzAgPVBLjsbjbw91V
=igwr
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH v4 1/2] for-each-repo: new command used for multi-repo operations
From: Lars Hjemli @ 2013-01-28 19:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Nieder, git
In-Reply-To: <7vr4l5w385.fsf@alter.siamese.dyndns.org>
On Mon, Jan 28, 2013 at 7:51 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Lars Hjemli <hjemli@gmail.com> writes:
>
>>> Come to think of it, is there a reason why "for-each-repo" should
>>> not be an extention to "submodule foreach"? We can view this as
>>> visiting repositories that _could_ be registered as a submodule, in
>>> addition to iterating over the registered submodules, no?
>>
>> Yes, but I see some possible problems with that approach:
>> -'git for-each-repo' does not need to be started from within a git worktree
>
> True, but "git submodule foreach --untracked" can be told that it is
> OK not (yet) to be in any superproject, no?
Yes.
>
>> -'git for-each-repo' and 'git submodule foreach' have different
>> semantics for --dirty and --clean
>
> That could be a problem. Is there a good reason why they should use
> different definitions of dirtyness?
I suspected that 'submodule foreach --dirty' might want to compare the
HEAD sha1 in the submodule against the one recorded in the
superproject (similar to what 'git submodule status' does), but such a
check could be triggered by a different flag (e.g. --behind/--ahead or
something similar).
>> -'git for-each-repo' is in C because my 'git-all' shell script was
>> horribly slow on large directory trees (especially on windows)
>
> Your for-each-repo could be a good basis to build a new builtin
> "submodule--foreach" that is a pure helper hidden from the end users
> that does both; cmd_foreach() in git-submodule.sh can simply delegate
> to it.
Ok, I'll rework my patches in this direction. Thanks.
--
larsh
^ permalink raw reply
* Re: [PATCH v2 3/4] mergetool--lib: Add functions for finding available tools
From: John Keeping @ 2013-01-28 19:37 UTC (permalink / raw)
To: David Aguilar; +Cc: Junio C Hamano, git
In-Reply-To: <1359334346-5879-4-git-send-email-davvid@gmail.com>
On Sun, Jan 27, 2013 at 04:52:25PM -0800, David Aguilar wrote:
> Refactor show_tool_help() so that the tool-finding logic is broken out
> into a separate show_tool_names() function.
>
> Signed-off-by: David Aguilar <davvid@gmail.com>
> ---
> filter_tools renamed to show_tool_names() and simplfied
> to use ls -1. show_tool_names() now has a preamble as discussed.
>
> git-mergetool--lib.sh | 68 +++++++++++++++++++++++++++++----------------------
> 1 file changed, 39 insertions(+), 29 deletions(-)
>
> diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
> index db3eb58..fe068f6 100644
> --- a/git-mergetool--lib.sh
> +++ b/git-mergetool--lib.sh
> @@ -2,6 +2,35 @@
> # git-mergetool--lib is a library for common merge tool functions
> MERGE_TOOLS_DIR=$(git --exec-path)/mergetools
>
> +mode_ok () {
> + diff_mode && can_diff ||
> + merge_mode && can_merge
> +}
> +
> +is_available () {
> + merge_tool_path=$(translate_merge_tool_path "$1") &&
> + type "$merge_tool_path" >/dev/null 2>&1
> +}
> +
Can we move show_tool_names() to be above show_tool_help()? It's a
very minor nit but I prefer having related functionality grouped
together.
> +show_tool_names () {
> + condition=${1:-true} per_line_prefix=${2:-} preamble=${3:-}
Would this be better with one value on each line? Also perhaps
per_line_prefix -> line_prefix.
> +
> + ( cd "$MERGE_TOOLS_DIR" && ls -1 * ) |
> + while read toolname
> + do
> + if setup_tool "$toolname" 2>/dev/null &&
> + (eval "$condition" "$toolname")
> + then
> + if test -n "$preamble"
> + then
> + echo "$preamble"
> + preamble=
> + fi
> + printf "%s%s\n" "$per_line_prefix" "$tool"
This needs to be:
printf "$per_line_prefix%s\n" "$tool"
since $per_line_prefix is usually '\t\t' which isn't expanded if we
format it with %s - an alternative would be to change the value passed
in to '$TAB$TAB' with literal tabs.
> + fi
> + done
> +}
> +
> diff_mode() {
> test "$TOOL_MODE" = diff
> }
^ permalink raw reply
* [PATCH] fixup! mergetools: simplify how we handle "vim" and "defaults"
From: John Keeping @ 2013-01-28 19:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, David Aguilar
---
Junio, please can you squash this into f9924e5 on jk/mergetool,
providing that David is OK with that?
The original change breaks custom mergetool by making changing the logic
around default functions so that they are now only defined when the tool
file exists in $MERGE_TOOLS_DIR but we need the default implementations
when a custom tool is in use, which by definition means that the file
doesn't exist in $MERGE_TOOLS_DIR.
git-mergetool--lib.sh | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
index 1d0fb12..211ffe5 100644
--- a/git-mergetool--lib.sh
+++ b/git-mergetool--lib.sh
@@ -48,15 +48,6 @@ valid_tool () {
setup_tool () {
tool="$1"
- if ! test -f "$MERGE_TOOLS_DIR/$tool"
- then
- # Use a special return code for this case since we want to
- # source "defaults" even when an explicit tool path is
- # configured since the user can use that to override the
- # default path in the scriptlet.
- return 2
- fi
-
# Fallback definitions, to be overriden by tools.
can_merge () {
return 0
@@ -80,6 +71,15 @@ setup_tool () {
echo "$1"
}
+ if ! test -f "$MERGE_TOOLS_DIR/$tool"
+ then
+ # Use a special return code for this case since we want to
+ # source "defaults" even when an explicit tool path is
+ # configured since the user can use that to override the
+ # default path in the scriptlet.
+ return 2
+ fi
+
# Load the redefined functions
. "$MERGE_TOOLS_DIR/$tool"
--
1.8.1.1
^ permalink raw reply related
* [PATCH] remove protocol from gravatar and picon links for clear if Gitweb is being called through a secure server
From: Andrej Andb @ 2013-01-28 19:14 UTC (permalink / raw)
To: git; +Cc: Andrej Andb
---
gitweb/gitweb.perl | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index c6bafe6..1309196 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2068,7 +2068,7 @@ sub picon_url {
if (!$avatar_cache{$email}) {
my ($user, $domain) = split('@', $email);
$avatar_cache{$email} =
- "http://www.cs.indiana.edu/cgi-pub/kinzler/piconsearch.cgi/" .
+ "//www.cs.indiana.edu/cgi-pub/kinzler/piconsearch.cgi/" .
"$domain/$user/" .
"users+domains+unknown/up/single";
}
@@ -2083,7 +2083,7 @@ sub gravatar_url {
my $email = lc shift;
my $size = shift;
$avatar_cache{$email} ||=
- "http://www.gravatar.com/avatar/" .
+ "//www.gravatar.com/avatar/" .
Digest::MD5::md5_hex($email) . "?s=";
return $avatar_cache{$email} . $size;
}
--
1.8.1.1
^ permalink raw reply related
* Re: [PATCH v4 1/2] for-each-repo: new command used for multi-repo operations
From: Junio C Hamano @ 2013-01-28 18:51 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Jonathan Nieder, git
In-Reply-To: <CAFXTnz6xBMo42jWdqahYX-bnTBucVmQpFPN29X8tGRd7L=g2wQ@mail.gmail.com>
Lars Hjemli <hjemli@gmail.com> writes:
>> Come to think of it, is there a reason why "for-each-repo" should
>> not be an extention to "submodule foreach"? We can view this as
>> visiting repositories that _could_ be registered as a submodule, in
>> addition to iterating over the registered submodules, no?
>
> Yes, but I see some possible problems with that approach:
> -'git for-each-repo' does not need to be started from within a git worktree
True, but "git submodule foreach --untracked" can be told that it is
OK not (yet) to be in any superproject, no?
> -'git for-each-repo' and 'git submodule foreach' have different
> semantics for --dirty and --clean
That could be a problem. Is there a good reason why they should use
different definitions of dirtyness?
> -'git for-each-repo' is in C because my 'git-all' shell script was
> horribly slow on large directory trees (especially on windows)
Your for-each-repo could be a good basis to build a new builtin
"submodule--foreach" that is a pure helper hidden from the end users
that does both; cmd_foreach() in git-submodule.sh can simply delegate
to it.
> All of these problems are probably solvable, but it would require
> quite some reworking of git-submodule.sh
Of course some work is needed, but we do not have to convert all the
cmd_foo in git-submodule.sh in one step. For the purpose of
unifying for-each-repo and submodule foreach to deliver the
functionality sooner to the end users, we can go the route to add
only the submodule--foreach builtin, out of which we will get
reusable implementation of module_list and other helper functions we
can leverage later to do other cmd_foo functions.
^ permalink raw reply
* Re: [PATCH v4 1/2] for-each-repo: new command used for multi-repo operations
From: Lars Hjemli @ 2013-01-28 18:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Nieder, git
In-Reply-To: <7vham1xktx.fsf@alter.siamese.dyndns.org>
On Mon, Jan 28, 2013 at 6:45 PM, Junio C Hamano <gitster@pobox.com> wrote:
> As to the pathspec limiting to affect the loop itself, not the
> argument given to the command that is run, I don't think it is
> absolutely needed; I am perfectly fine with declaring that
> for-each-repo goes to repositories in all subdirectories without
> limit, especially if doing so will make the UI issues we have to
> deal with simpler.
Good (since the relative path of each repo will be exported to the
child process, that process can perform path limiting when needed).
> As to the "option to the command, not to the subcommand, -a option",
> I have been assuming that it was a joke patch, but if "git -a grep"
> turns out to be really useful, "submodule foreach" that iterates
> over the submodules may also want to have such a short and sweet
> mechanism. Between "for-each-repo" and "submodule foreach", I do
> not yet have a strong opinion on which one deserves it more.
>
> Come to think of it, is there a reason why "for-each-repo" should
> not be an extention to "submodule foreach"? We can view this as
> visiting repositories that _could_ be registered as a submodule, in
> addition to iterating over the registered submodules, no?
Yes, but I see some possible problems with that approach:
-'git for-each-repo' does not need to be started from within a git worktree
-'git for-each-repo' and 'git submodule foreach' have different
semantics for --dirty and --clean
-'git for-each-repo' is in C because my 'git-all' shell script was
horribly slow on large directory trees (especially on windows)
All of these problems are probably solvable, but it would require
quite some reworking of git-submodule.sh
--
larsh
^ permalink raw reply
* Re: [PATCH v4 1/2] for-each-repo: new command used for multi-repo operations
From: Junio C Hamano @ 2013-01-28 18:35 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Jonathan Nieder, git
In-Reply-To: <CAFXTnz6zN0izx8S23JFww5niVD6x-r2e7TSthqZnempUrvAEWw@mail.gmail.com>
Lars Hjemli <hjemli@gmail.com> writes:
> On Mon, Jan 28, 2013 at 9:10 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
>> ...
>> So if I ran the world, then having commands
>>
>> git -a diff
>>
>> and
>>
>> git for-each-repo git diff
>>
>> do the same thing would be fine. Of course I don't run the world. ;-)
>
> This would make me very happy. Junio?
Ahh, our mails crossed (rather, I responded to the other message I
saw before I saw this one). I am not completely sold on "git -a"
yet, but another worry I have is which one between "submodule
foreach" and "for-each-repo" should use "git -a", if we decide that
it is useful to the users to add it.
^ permalink raw reply
* [PATCH] l10n: de.po: translate "reset" as "neu setzen"
From: Ralf Thielow @ 2013-01-28 18:33 UTC (permalink / raw)
To: trast, jojo; +Cc: git, jk, stimming, Ralf Thielow
In-Reply-To: <1359398014-3325-1-git-send-email-ralf.thielow@gmail.com>
According to the glossary, "reset" should be
translated as "neu setzen" but in a couple of
messages we've translated it as "zurücksetzen".
This fixes that.
Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
---
Note that the part "neu" is not used in any places because
I think sometimes it sounds better without them.
po/de.po | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/po/de.po b/po/de.po
index 6c7384b..9b1f589 100644
--- a/po/de.po
+++ b/po/de.po
@@ -2764,7 +2764,7 @@ msgstr "Zweigspitze (HEAD) ist jetzt bei"
#: builtin/checkout.c:609
#, c-format
msgid "Reset branch '%s'\n"
-msgstr "Setze Zweig '%s' zurück\n"
+msgstr "Setze Zweig '%s' neu\n"
#: builtin/checkout.c:612
#, c-format
@@ -2774,7 +2774,7 @@ msgstr "Bereits auf '%s'\n"
#: builtin/checkout.c:616
#, c-format
msgid "Switched to and reset branch '%s'\n"
-msgstr "Gewechselt zu zurückgesetztem Zweig '%s'\n"
+msgstr "Gewechselt zu neu gesetztem Zweig '%s'\n"
#: builtin/checkout.c:618 builtin/checkout.c:955
#, c-format
@@ -7900,19 +7900,19 @@ msgstr "weniger Ausgaben, meldet nur Fehler"
#: builtin/reset.c:250
msgid "reset HEAD and index"
-msgstr "setzt Zweigspitze (HEAD) und Bereitstellung zurück"
+msgstr "setzt Zweigspitze (HEAD) und Bereitstellung neu"
#: builtin/reset.c:251
msgid "reset only HEAD"
-msgstr "setzt nur Zweigspitze (HEAD) zurück"
+msgstr "setzt nur Zweigspitze (HEAD) neu"
#: builtin/reset.c:253 builtin/reset.c:255
msgid "reset HEAD, index and working tree"
-msgstr "setzt Zweigspitze (HEAD), Bereitstellung und Arbeitsbaum zurück"
+msgstr "setzt Zweigspitze (HEAD), Bereitstellung und Arbeitsbaum neu"
#: builtin/reset.c:257
msgid "reset HEAD but keep local changes"
-msgstr "setzt Zweigspitze (HEAD) zurück, behält aber lokale Änderungen"
+msgstr "setzt Zweigspitze (HEAD) neu, behält aber lokale Änderungen"
#: builtin/reset.c:275
#, c-format
@@ -7952,7 +7952,7 @@ msgstr "'%s' Zurücksetzung ist in einem bloßen Projektarchiv nicht erlaubt"
#: builtin/reset.c:333
#, c-format
msgid "Could not reset index file to revision '%s'."
-msgstr "Konnte Bereitstellungsdatei nicht zu Version '%s' zurücksetzen."
+msgstr "Konnte Bereitstellungsdatei nicht zu Version '%s' setzen."
#: builtin/reset.c:339
msgid "Unstaged changes after reset:"
@@ -8833,7 +8833,7 @@ msgstr "Baut lokale Versionen auf einem aktuellerem externen Zweig neu auf"
#: common-cmds.h:24
msgid "Reset current HEAD to the specified state"
msgstr ""
-"Setzt die aktuelle Zweigspitze (HEAD) zu einem spezifizierten Zustand zurück"
+"Setzt die aktuelle Zweigspitze (HEAD) zu einem spezifizierten Zustand"
#: common-cmds.h:25
msgid "Remove files from the working tree and from the index"
--
1.8.1.1.439.g50a6b54
^ permalink raw reply related
* [PATCH] l10n: de.po: translate "revision" consistently as "Version"
From: Ralf Thielow @ 2013-01-28 18:33 UTC (permalink / raw)
To: trast, jojo; +Cc: git, jk, stimming, Ralf Thielow
In-Reply-To: <1359398014-3325-1-git-send-email-ralf.thielow@gmail.com>
In the German translation, we have translated "revision"
as both "Revision" and "Version". In the context of version
control, revision has the same meaning as commit, so we don't
need to use both terms. "revision" is now consistently translated
as "Version".
Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
---
po/de.po | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/po/de.po b/po/de.po
index ed8330a..6c7384b 100644
--- a/po/de.po
+++ b/po/de.po
@@ -156,7 +156,7 @@ msgstr "Dem Projektarchiv fehlen folgende vorausgesetzte Versionen:"
#: builtin/log.c:751 builtin/log.c:1358 builtin/log.c:1574 builtin/merge.c:347
#: builtin/shortlog.c:157
msgid "revision walk setup failed"
-msgstr "Einrichtung des Revisionsgangs fehlgeschlagen"
+msgstr "Einrichtung des Versionsgangs fehlgeschlagen"
#: bundle.c:186
#, c-format
@@ -2201,7 +2201,7 @@ msgstr "arbeite länger, um bessere Übereinstimmungen zu finden"
#: builtin/blame.c:2380
msgid "Use revisions from <file> instead of calling git-rev-list"
-msgstr "Benutzt Revisionen von <Datei> anstatt \"git-rev-list\" aufzurufen"
+msgstr "Benutzt Versionen von <Datei> anstatt \"git-rev-list\" aufzurufen"
#: builtin/blame.c:2381
msgid "Use <file>'s contents as the final image"
@@ -2832,7 +2832,7 @@ msgstr ""
#: builtin/checkout.c:730
msgid "internal error in revision walk"
-msgstr "interner Fehler im Revisionsgang"
+msgstr "interner Fehler im Versionsgang"
#: builtin/checkout.c:734
msgid "Previous HEAD position was"
@@ -6193,7 +6193,7 @@ msgstr "findet Vorfahren für eine einzelne n-Wege-Zusammenführung"
#: builtin/merge-base.c:100
msgid "list revs not reachable from others"
-msgstr "listet Revisionen auf, die nicht durch Andere erreichbar sind"
+msgstr "listet Versionen auf, die nicht durch Andere erreichbar sind"
#: builtin/merge-base.c:102
msgid "is the first one ancestor of the other?"
@@ -6831,7 +6831,7 @@ msgstr "erzeugt keine leeren Pakete"
#: builtin/pack-objects.c:2481
msgid "read revision arguments from standard input"
-msgstr "liest Argumente bezüglich Revisionen von der Standard-Eingabe"
+msgstr "liest Argumente bezüglich Versionen von der Standard-Eingabe"
#: builtin/pack-objects.c:2483
msgid "limit the objects to those that are not yet packed"
@@ -7917,7 +7917,7 @@ msgstr "setzt Zweigspitze (HEAD) zurück, behält aber lokale Änderungen"
#: builtin/reset.c:275
#, c-format
msgid "Failed to resolve '%s' as a valid revision."
-msgstr "Konnte '%s' nicht als gültige Revision auflösen."
+msgstr "Konnte '%s' nicht als gültige Version auflösen."
#: builtin/reset.c:278 builtin/reset.c:286
#, c-format
@@ -8193,7 +8193,7 @@ msgstr ""
"git show-branch [-a|--all] [-r|--remotes] [--topo-order | --date-order] [--"
"current] [--color[=<Wann>] | --no-color] [--sparse] [--more=<n> | --list | --"
"independent | --merge-base] [--no-name | --sha1-name] [--topics] "
-"[(<Revision> | <glob>)...]"
+"[(<Version> | <glob>)...]"
#: builtin/show-branch.c:10
msgid "git show-branch (-g|--reflog)[=<n>[,<base>]] [--list] [<ref>]"
@@ -9440,7 +9440,7 @@ msgstr "Kein \"stash\" gefunden."
#: git-stash.sh:359
#, sh-format
msgid "Too many revisions specified: $REV"
-msgstr "Zu viele Revisionen angegeben: $REV"
+msgstr "Zu viele Versionen angegeben: $REV"
#: git-stash.sh:365
#, sh-format
--
1.8.1.1.439.g50a6b54
^ permalink raw reply related
* [PATCHv2] l10n: de.po: translate 11 new messages
From: Ralf Thielow @ 2013-01-28 18:33 UTC (permalink / raw)
To: trast, jojo; +Cc: git, jk, stimming, Ralf Thielow
In-Reply-To: <1359353699-3987-1-git-send-email-ralf.thielow@gmail.com>
Translate 11 new messages came from git.pot update
in 46bc403 (l10n: Update git.pot (11 new, 7 removed
messages)).
Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
Acked-by: Thomas Rast <trast@inf.ethz.ch>
---
po/de.po | 37 ++++++++++++++++++-------------------
1 file changed, 18 insertions(+), 19 deletions(-)
diff --git a/po/de.po b/po/de.po
index 3779f4c..ed8330a 100644
--- a/po/de.po
+++ b/po/de.po
@@ -5,7 +5,7 @@
#
msgid ""
msgstr ""
-"Project-Id-Version: git 1.8.1\n"
+"Project-Id-Version: git 1.8.2\n"
"Report-Msgid-Bugs-To: Git Mailing List <git@vger.kernel.org>\n"
"POT-Creation-Date: 2013-01-25 12:33+0800\n"
"PO-Revision-Date: 2012-10-02 19:35+0200\n"
@@ -1033,9 +1033,9 @@ msgid "unable to access '%s': %s"
msgstr "konnte nicht auf '%s' zugreifen: %s"
#: wrapper.c:423
-#, fuzzy, c-format
+#, c-format
msgid "unable to access '%s'"
-msgstr "konnte nicht auf '%s' zugreifen: %s"
+msgstr "konnte nicht auf '%s' zugreifen"
#: wrapper.c:434
#, c-format
@@ -2997,14 +2997,14 @@ msgid "Would remove %s\n"
msgstr "Würde %s löschen\n"
#: builtin/clean.c:26
-#, fuzzy, c-format
+#, c-format
msgid "Skipping repository %s\n"
-msgstr "ungültiges Projektarchiv '%s'"
+msgstr "Überspringe Projektarchiv %s\n"
#: builtin/clean.c:27
-#, fuzzy, c-format
+#, c-format
msgid "Would skip repository %s\n"
-msgstr "ungültiges Projektarchiv '%s'"
+msgstr "Würde Projektarchiv %s überspringen\n"
#: builtin/clean.c:28
#, c-format
@@ -3223,9 +3223,8 @@ msgid "--bare and --origin %s options are incompatible."
msgstr "Die Optionen --bare und --origin %s sind inkompatibel."
#: builtin/clone.c:708
-#, fuzzy
msgid "--bare and --separate-git-dir are incompatible."
-msgstr "Die Optionen --bare und --origin %s sind inkompatibel."
+msgstr "Die Optionen --bare und --separate-git-dir sind inkompatibel."
#: builtin/clone.c:721
#, c-format
@@ -5449,7 +5448,7 @@ msgstr "zeigt Quelle"
#: builtin/log.c:104
msgid "Use mail map file"
-msgstr ""
+msgstr "verwendet \"mailmap\"-Datei"
#: builtin/log.c:105
msgid "decorate options"
@@ -5542,7 +5541,7 @@ msgstr "beginnt die Nummerierung der Patches bei <n> anstatt bei 1"
#: builtin/log.c:1114
msgid "mark the series as Nth re-roll"
-msgstr ""
+msgstr "kennzeichnet die Serie als n-te Fassung"
#: builtin/log.c:1116
msgid "Use [<prefix>] instead of [PATCH]"
@@ -7099,6 +7098,8 @@ msgid ""
"Updates were rejected because the destination reference already exists\n"
"in the remote."
msgstr ""
+"Aktualisierungen wurden zurückgewiesen, weil die Zielreferenz bereits\n"
+"im Fernarchiv existiert."
#: builtin/push.c:269
#, c-format
@@ -7841,14 +7842,12 @@ msgstr ""
"git reset [--mixed | --soft | --hard | --merge | --keep] [-q] [<Version>]"
#: builtin/reset.c:26
-#, fuzzy
msgid "git reset [-q] <tree-ish> [--] <paths>..."
-msgstr "git reset [-q] <Version> [--] <Pfade>..."
+msgstr "git reset [-q] <Versionsreferenz> [--] <Pfade>..."
#: builtin/reset.c:27
-#, fuzzy
msgid "git reset --patch [<tree-ish>] [--] [<paths>...]"
-msgstr "git reset --patch [<Version>] [--] [<Pfade>...]"
+msgstr "git reset --patch [<Versionsreferenz>] [--] [<Pfade>...]"
#: builtin/reset.c:33
msgid "mixed"
@@ -7916,9 +7915,9 @@ msgid "reset HEAD but keep local changes"
msgstr "setzt Zweigspitze (HEAD) zurück, behält aber lokale Änderungen"
#: builtin/reset.c:275
-#, fuzzy, c-format
+#, c-format
msgid "Failed to resolve '%s' as a valid revision."
-msgstr "Konnte '%s' nicht als gültige Referenz auflösen."
+msgstr "Konnte '%s' nicht als gültige Revision auflösen."
#: builtin/reset.c:278 builtin/reset.c:286
#, c-format
@@ -7926,9 +7925,9 @@ msgid "Could not parse object '%s'."
msgstr "Konnte Objekt '%s' nicht parsen."
#: builtin/reset.c:283
-#, fuzzy, c-format
+#, c-format
msgid "Failed to resolve '%s' as a valid tree."
-msgstr "Konnte '%s' nicht als gültige Referenz auflösen."
+msgstr "Konnte '%s' nicht als gültigen Baum auflösen."
#: builtin/reset.c:292
msgid "--patch is incompatible with --{hard,mixed,soft}"
--
1.8.1.1.439.g50a6b54
^ permalink raw reply related
* Re: [PATCH v3] add: warn when -u or -A is used without filepattern
From: Junio C Hamano @ 2013-01-28 18:31 UTC (permalink / raw)
To: Matthieu Moy
Cc: Michael J Gruber, git, Jonathan Nieder, Robin Rosenberg,
Piotr Krukowiecki, Eric James Michael Ritz, Tomas Carnecky
In-Reply-To: <vpq8v7dw4f5.fsf@grenoble-inp.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> I think "add -u && commit" vs "commit -a" you brought up is a good
>> thing to mention, so let's do this.
>
> I'm OK with your proposal. Let me know if you want me to resend.
Thanks for a quick response. As you may have guessed, I am sending
these after running "commit --amend", so ...
>> The inconsistency of 'git add -u' and 'git add -A' are particularly
>
> Nitpick: this should be "inconsistencies" (or "is particularly").
... it is much easier for me to fix these locally instead of getting
a reroll.
Will amend with s/are particularly/is particularly/; thanks.
^ permalink raw reply
* Re: [PATCH/RFC] mingw: rename WIN32 cpp macro to NATIVE_WINDOWS
From: Ramsay Jones @ 2013-01-28 18:29 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Eric Blake, Junio C Hamano, Mark Levedahl, Alex Riesen,
Jason Pyeron, git, Torsten Bögershausen,
Stephen & Linda Smith
In-Reply-To: <20130126010359.GH3341@elie.Belkin>
Jonathan Nieder wrote:
> Throughout git, it is assumed that the WIN32 preprocessor symbol is
> defined on native Windows setups (mingw and msvc) and not on Cygwin.
> On Cygwin, most of the time git can pretend this is just another Unix
> machine, and Windows-specific magic is generally counterproductive.
>
> Unfortunately Cygwin *does* define the WIN32 symbol in some headers.
> Best to rely on a new git-specific symbol NATIVE_WINDOWS instead,
> defined as follows:
>
> #if defined(WIN32) && !defined(__CYGWIN__)
> # define NATIVE_WINDOWS
> #endif
>
> After this change, it should be possible to drop the
> CYGWIN_V15_WIN32API setting without any negative effect.
>
> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
If we go with this approach, could we prefix the symbol name with GIT_
in order to reduce the global namespace pollution?
eg GIT_NATIVE_WINDOWS, or GIT_NATIVE_WIN32 or just GIT_WIN32.
(Yeah, I'm not good at choosing names!)
ATB,
Ramsay Jones
^ permalink raw reply
* Re: [PATCH v3] add: warn when -u or -A is used without filepattern
From: Matthieu Moy @ 2013-01-28 18:25 UTC (permalink / raw)
To: Junio C Hamano
Cc: Michael J Gruber, git, Jonathan Nieder, Robin Rosenberg,
Piotr Krukowiecki, Eric James Michael Ritz, Tomas Carnecky
In-Reply-To: <7v4ni1xjuc.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> I think "add -u && commit" vs "commit -a" you brought up is a good
> thing to mention, so let's do this.
I'm OK with your proposal. Let me know if you want me to resend.
> The inconsistency of 'git add -u' and 'git add -A' are particularly
Nitpick: this should be "inconsistencies" (or "is particularly").
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH] l10n: de.po: translate 11 new messages
From: Ralf Thielow @ 2013-01-28 18:13 UTC (permalink / raw)
To: Joachim Schmitz; +Cc: git, jk, stimming, trast
In-Reply-To: <ke69ta$1e4$1@ger.gmane.org>
On Mon, Jan 28, 2013 at 05:39:27PM +0100, Joachim Schmitz wrote:
> Ralf Thielow wrote:
> >Translate 11 new messages came from git.pot update
> >in 46bc403 (l10n: Update git.pot (11 new, 7 removed
> >messages)).
> >
> >Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
> >---
> > po/de.po | 37 ++++++++++++++++++-------------------
> > 1 file changed, 18 insertions(+), 19 deletions(-)
> >
> >diff --git a/po/de.po b/po/de.po
> >index 3779f4c..ed8330a 100644
> >--- a/po/de.po
> >+++ b/po/de.po
> >@@ -5,7 +5,7 @@
> > #
> > msgid ""
> > msgstr ""
> >-"Project-Id-Version: git 1.8.1\n"
> >+"Project-Id-Version: git 1.8.2\n"
>
> Not "Projekt-Id-Version ..."?
>
I don't think that we need to translate this.
> > #: builtin/reset.c:33
> > msgid "mixed"
> >@@ -7916,9 +7915,9 @@ msgid "reset HEAD but keep local changes"
> > msgstr "setzt Zweigspitze (HEAD) zurück, behält aber lokale
> >Änderungen"
>
> Not "reset -> setze" and "keep" -> halte (imperativ)?
> Or is the enlish text wrong and should be "resets" and "keeps"
>
All translations which describe an option shown by "git <command> -h"
are (or should be) like this. The reading is like "This option..."
followed by such a messages. That's at least how it's done. I don't think
it sounds bad.
According to the glossary, the translation here is wrong because "reset" is
not "*zurück* setzen" but "neu setzen". I'll fix this (and perhaps other
messages) on a commit on top.
> Bye, Jojo
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3] add: warn when -u or -A is used without filepattern
From: Junio C Hamano @ 2013-01-28 18:07 UTC (permalink / raw)
To: Michael J Gruber
Cc: Matthieu Moy, git, Jonathan Nieder, Robin Rosenberg,
Piotr Krukowiecki, Eric James Michael Ritz, Tomas Carnecky
In-Reply-To: <51067353.2090006@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
> Matthieu Moy venit, vidit, dixit 28.01.2013 10:16:
>> Most git commands that can be used with our without a filepattern are
>> tree-wide by default, the filepattern being used to restrict their scope.
>> A few exceptions are: 'git grep', 'git clean', 'git add -u' and 'git add -A'.
>
> Since I didn't follow this thread, my first reaction was: "Huh? Aren't
> they treewide?" (for the relative tree)
>
> So, for someone reading just the commit message, it would be helpful to
> say what the others do, i.e. default to the relative tree at pwd (rather
> than defaulting to an empty tree, or all files whether tracked or not,
> or...).
I think "add -u && commit" vs "commit -a" you brought up is a good
thing to mention, so let's do this. Another tweak is that I did
s/filepattern/pathspec/ here. I know that both the documentation
and the help text for "git add" say filepattern, but we say pathspec
starting from glossary fairly consistently everywhere in the rest of
the system.
We should probably update the documentation/help for "git add", but
that is entirely a separate topic.
add: warn when -u or -A is used without pathspec
Most Git commands that can be used with or without pathspec operate
tree-wide by default, the pathspec being used to restrict their
scope. A few exceptions are: 'git grep', 'git clean', 'git add -u'
and 'git add -A'. When run in a subdirectory without pathspec, they
operate only on paths in the current directory.
The inconsistency of 'git add -u' and 'git add -A' are particularly
problematic since other 'git add' subcommands (namely 'git add -p'
and 'git add -e') are tree-wide by default. It also means that "git
add -u && git commit" will record a state that is different from
what is recorded with "git commit -a".
Flipping the default now is unacceptable, so let's start training
users to type 'git add -u|-A :/' or 'git add -u|-A .' explicitly, to
prepare for the next steps:
* forbid 'git add -u|-A' without pathspec (like 'git add' without
option)
* much later, maybe, re-allow 'git add -u|-A' without pathspec, that
will add all tracked and modified files, or all files, tree-wide.
A nice side effect of this patch is that it makes the :/ magic
pathspec easier to discover for users.
When the command is called from the root of the tree, there is no
ambiguity and no need to change the behavior, hence no need to warn.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
^ permalink raw reply
* Re: [PATCH] l10n: de.po: translate 11 new messages
From: Ralf Thielow @ 2013-01-28 17:55 UTC (permalink / raw)
To: Thomas Rast; +Cc: jk, stimming, git
In-Reply-To: <87sj5l38d6.fsf@pctrast.inf.ethz.ch>
On Mon, Jan 28, 2013 at 11:33:09AM +0100, Thomas Rast wrote:
> Ralf Thielow <ralf.thielow@gmail.com> writes:
>
> > #: builtin/reset.c:275
> > -#, fuzzy, c-format
> > +#, c-format
> > msgid "Failed to resolve '%s' as a valid revision."
> > -msgstr "Konnte '%s' nicht als gültige Referenz auflösen."
> > +msgstr "Konnte '%s' nicht als gültige Revision auflösen."
>
> You don't have "revision" in the glossary[1] yet. Wouldn't it be
> appropriate to treat it as "commit", and translate as "Version" to avoid
> introducing yet another term?
>
> Or am I missing some subtle distinction between commit and revision?
>
I don't think there's a distinction. Since we've already translated
"revision" as "Revision" in a couple of other messages, I'll make a
new "s/Revision/Version" commit on top.
> Since it's only a single nit, feel free to add my ack when you reroll:
>
> Acked-by: Thomas Rast <trast@inf.ethz.ch>
>
>
> [1] https://github.com/ralfth/git-po-de/wiki/Glossary
>
> --
> Thomas Rast
> trast@{inf,student}.ethz.ch
^ 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