* Re: [PATCH v3 0/9] User manual updates
From: W. Trevor King @ 2013-02-18 12:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git, Jonathan Nieder
In-Reply-To: <7vr4keatlk.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 506 bytes --]
On Mon, Feb 18, 2013 at 12:56:07AM -0800, Junio C Hamano wrote:
> I've taken the following to 'maint'…
Should I rebase v4 onto maint so I don't accidentally collide with any
of the previous patches which have already been merged there? It
doesn't look like you've pushed the last round of maint additions to
your public repository yet…
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v2 02/15] user-manual: Update for receive.denyCurrentBranch=refuse
From: Drew Northup @ 2013-02-18 13:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: W. Trevor King, Git
In-Reply-To: <7v4nhezpta.fsf@alter.siamese.dyndns.org>
On Thu, Feb 14, 2013 at 1:57 PM, Junio C Hamano <gitster@pobox.com> wrote:
> I did not think the detailed discussion belongs there in the first
> place, so I re-read the context. I think the only thing the reader
> of the user manual needs to learn at that point of the flow is that
> they can push to a non-bare but cannot push to update the currently
> checked out branch by default. So let's tone everything down and do
> this instead:
> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> index 85651b5..7c534dc 100644
> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -1986,9 +1986,10 @@ handling this case.
>
> Note that the target of a "push" is normally a
> <<def_bare_repository,bare>> repository. You can also push to a
> -repository that has a checked-out working tree, but the working tree
> -will not be updated by the push. This may lead to unexpected results if
> -the branch you push to is the currently checked-out branch!
> +repository that has a checked-out working tree, but a push to update the
> +currently checked-out branch is denied by default to prevent confusion.
> +See the description ofthe receive.denyCurrentBranch option
> +in linkgit:git-config[1] for details.
This looks safe to me, with the minor nit that "ofthe" ("of the")
isn't one word.
--
-Drew Northup
--------------------------------------------------------------
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
^ permalink raw reply
* Re: Recursive submodule confusing output (bug?)
From: Will Entriken @ 2013-02-18 15:58 UTC (permalink / raw)
To: git
In-Reply-To: <CAFwrLX6EWPureNoyjuMVy13kgwyAgDBcd1Eoet7hQ1CB9OhLxQ@mail.gmail.com>
Hello,
I am running:
git submodule update --recursive
And get the output:
Submodule path 'Submodules/evernote-ios-sdk': checked out
'391ca643c5b1cd02e9fa869a6b0760436ea452ed'
Submodule path 'Submodules/facebook-ios-sdk': checked out
'ada467f754febd4f2871d15943e9be16b323f114'
Submodule path 'Submodules/objectiveflickr': checked out
'f474a78c807b5fa0c887bf8efaead5be1da637ec'
Submodule path 'Submodules/sskeychain': checked out
'8252a69cdfea562223d4dc2e2ccaf01b752d2cc6'
This is a little confusing to me, would this be more appropriate?
Submodule path 'Submodules/ShareKit/Submodules/evernote-ios-sdk':
checked out '391ca643c5b1cd02e9fa869a6b0760436ea452ed'
Submodule path 'Submodules/ShareKit/Submodules/facebook-ios-sdk':
checked out 'ada467f754febd4f2871d15943e9be16b323f114'
Submodule path 'Submodules/ShareKit/Submodules/objectiveflickr':
checked out 'f474a78c807b5fa0c887bf8efaead5be1da637ec'
Submodule path 'Submodules/ShareKit/Submodules/sskeychain':
checked out '8252a69cdfea562223d4dc2e2ccaf01b752d2cc6'
Please let me know if this is something I may fix.
Thank you,
William Entriken
^ permalink raw reply
* [PATCH] shell-prompt: clean up nested if-then
From: Martin Erik Werner @ 2013-02-18 16:23 UTC (permalink / raw)
To: gitster; +Cc: git, trsten, Martin Erik Werner
In-Reply-To: <1361204512.4758.10.camel@mas>
Minor clean up of if-then nesting in checks for environment variables
and config options. No functional changes.
---
contrib/completion/git-prompt.sh | 27 +++++++++++++--------------
1 file changed, 13 insertions(+), 14 deletions(-)
diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index 9b2eec2..e29694d 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -320,26 +320,25 @@ __git_ps1 ()
b="GIT_DIR!"
fi
elif [ "true" = "$(git rev-parse --is-inside-work-tree 2>/dev/null)" ]; then
- if [ -n "${GIT_PS1_SHOWDIRTYSTATE-}" ]; then
- if [ "$(git config --bool bash.showDirtyState)" != "false" ]; then
- git diff --no-ext-diff --quiet --exit-code || w="*"
- if git rev-parse --quiet --verify HEAD >/dev/null; then
- git diff-index --cached --quiet HEAD -- || i="+"
- else
- i="#"
- fi
+ if test -n "${GIT_PS1_SHOWDIRTYSTATE-}" &&
+ test "$(git config --bool bash.showDirtyState)" != "false"
+ then
+ git diff --no-ext-diff --quiet --exit-code || w="*"
+ if git rev-parse --quiet --verify HEAD >/dev/null; then
+ git diff-index --cached --quiet HEAD -- || i="+"
+ else
+ i="#"
fi
fi
if [ -n "${GIT_PS1_SHOWSTASHSTATE-}" ]; then
git rev-parse --verify refs/stash >/dev/null 2>&1 && s="$"
fi
- if [ -n "${GIT_PS1_SHOWUNTRACKEDFILES-}" ]; then
- if [ "$(git config --bool bash.showUntrackedFiles)" != "false" ]; then
- if [ -n "$(git ls-files --others --exclude-standard)" ]; then
- u="%"
- fi
- fi
+ if test -n "${GIT_PS1_SHOWUNTRACKEDFILES-}" &&
+ test "$(git config --bool bash.showUntrackedFiles)" != "false" &&
+ test -n "$(git ls-files --others --exclude-standard)"
+ then
+ u="%"
fi
if [ -n "${GIT_PS1_SHOWUPSTREAM-}" ]; then
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH] read_directory: avoid invoking exclude machinery on tracked files
From: Karsten Blees @ 2013-02-18 16:42 UTC (permalink / raw)
To: Junio C Hamano
Cc: Duy Nguyen, git, kusmabite, Ramkumar Ramachandra, Robert Zeh,
finnag
In-Reply-To: <7vd2w1gyok.fsf@alter.siamese.dyndns.org>
Am 15.02.2013 20:32, schrieb Junio C Hamano:
> Duy Nguyen <pclouds@gmail.com> writes:
>
>> On Fri, Feb 15, 2013 at 11:52 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>> In the current code, we always check if a path is excluded, and when
>>> dealing with DT_REG/DT_LNK, we call treat_file():
>>>
>>> * When such a path is excluded, treat_file() returns true when we
>>> are not showing ignored directories. This causes treat_one_path()
>>> to return path_ignored, so for excluded DT_REG/DT_LNK paths when
>>> no DIR_*_IGNORED is in effect, this change is a correct
>>> optimization.
>>>
>>> * When such a path is not excluded, on the ther hand, and when we
>>> are not showing ignored directories, treat_file() just returns
>>> the value of exclude_file, which is initialized to false and is
>>> not changed in the function. This causes treat_one_path() to
>>> return path_handled. However, the new code returns path_ignored
>>> in this case.
>>>
>>> What guarantees that this change is regression free?
>>
>> If you consider read_directory_recursive alone, there is a regression.
>> The return value of r_d_r depends on path_handled/path_ignored. With
>> this patch, the return value will be different.
>
> That is exactly what was missing from the proposed log message, and
> made me ask "Do all the callers that reach this function in their
> callgraph, when they get path_ignored for a path in the index,
> behave as if the difference between path_ignored and path_handled
> does not matter?" Your answer seems to be
>
> - r-d-r returns 'how many paths in this directory match the
> criteria we are looking for', unless check_only is true. Now in
> some cases we return path_ignored not path_handled, so we may
> return a number that is greater than we used to return.
>
> - treat_directory, the only user of that return value, cares if
> r-d-r returned 0 or non-zero; and
>
> - As long as we keep returning 0 from r-d-r in cases we used to
> return 0 and non-zero in cases we used to return non-zero, exact
> number does not matter. Overall we get the same result.
>
> I think all of the above is true, but I have not convinced myself
> that r-d-r with the new code never returns 0 when we used to return
> non-zero.
>
treat_directory calls read_directory_recursive in tow cases:
1.) The directory is not in the index.
---8<---
switch (directory_exists_in_index(dirname, len-1)) {
case index_nonexistent:
if (dir->flags & DIR_SHOW_OTHER_DIRECTORIES)
break;
}
...
---8<---
The directory is not in the index if there are no tracked files in the directory. I.e. cache_name_exists will always be false in this case, so the change won't affect the result of r_d_r.
2.) The directory is in the index but is ignored.
---8<---
switch (directory_exists_in_index(dirname, len-1)) {
case index_directory:
if ((dir->flags & DIR_SHOW_OTHER_DIRECTORIES) && exclude)
break;
}
if ((dir->flags & DIR_SHOW_IGNORED) && !exclude) {
...
}
if (!(dir->flags & DIR_SHOW_IGNORED) &&
!(dir->flags & DIR_HIDE_EMPTY_DIRECTORIES))
return show_directory;
if (!read_directory_recursive(dir, dirname, len, 1, simplify))
return ignore_directory;
return show_directory;
---8<---
With exclude==true, only one r_d_r call is reachable, and only if either DIR_SHOW_IGNORED or DIR_HIDE_EMPTY_DIRECTORIES is set.
2a) DIR_SHOW_IGNORED is set: the patch already checks !(dir->flags & DIR_SHOW_IGNORED), so the result of r_d_r is not affected.
2b) DIR_HIDE_EMPTY_DIRECTORIES is set and DIR_SHOW_IGNORED is not set: the directory is already ignored, so all files in the directory should be ignored, too. It doesn't matter whether treat_one_path returns path_ignored because of the excluded() check or cache_name_exists().
Therefore, I think the patch (v0) is regression-free.
As a side note, I'm quite confused why we would ever want to evaluate .gitignore patterns on tracked files at all, as gitignore(5) clearly states "Files already tracked by git are not affected". There is 'git-ls-files --cached --ignored', although this doesn't seem to process .gitignore files but expects exclude patterns on the command line...
^ permalink raw reply
* Google Summer of Code 2013 (GSoC13)
From: Thomas Rast @ 2013-02-18 17:23 UTC (permalink / raw)
To: git
Cc: Jeff King, Shawn Pearce, Jakub Narebski, Christian Couder,
Pat Thoyts, Paul Mackerras, Carlos Martín Nieto,
Thomas Gummerer, David Michael Barr, Ramkumar Ramachandra,
Jens Lehmann, Nguyen Thai Ngoc Duy
Hi,
Google announced the 2013 incarnation of the Google Summer of Code
program on Feb 11:
http://www.google-melange.com/gsoc/homepage/google/gsoc2013
Git has taken part in previous years, so I figure somebody should get
the ball rolling again! The following items need to be sorted out:
* We need an org admin. AFAIK this was done by Peff and Shawn in
tandem last year. Would you do it again?
* We should prepare an "ideas page". Last year, Peff made one on
https://github.com/peff/git/wiki/SoC-2012-Ideas
I couldn't edit it there over git access[1], so I made a clone in "my"
github wiki:
https://github.com/trast/git/wiki/SoC-2013-Ideas
I'll volunteer to manage that wiki[2]. Please either edit it
directly, or send me patches or pull requests. I won't really have
time to properly review them, but I'll do my best to merge everything.
* Naturally that ideas page is a bit stale now, and three projects
shorter. Please propose new ideas and refresh or delete the old ones!
In particular some projects spawned long discussions on the list, and
the results of those discussions should be integrated to avoid deja
vus.
* We should have a pool of mentors and rough mentor-project matchings.
I gathered a -- certainly incomplete -- list of previous mentors and
students in the Cc field; maybe some of you are interested again? If
so, propose your own ideas and/or list yourself in the "proposed
mentors" for some existing projects. (I cleared all those fields for
now.)
* Even if you don't want to mentor, you can still contribute by helping
with discussing and ranking proposals, especially immediately before
and after the project submission deadline (May 3).
If we want to participate again, we need to get together an org
application until *March 29* 19:00 UTC, and it won't exactly hurt to
have the ideas page settled until then too.
It would be really nice if we could do this again, I think GSoC is a
great opportunity both for Git and the involved students.
Cheers
Thomas
Footnotes:
[1] That's a bit silly really, since I *can* edit it via the web
interface. Peff, perhaps you can get that fixed?
[2] Unless Peff wants to take it over again? You could just pull it
from the git version, it's based on your history.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: Google Summer of Code 2013 (GSoC13)
From: Jeff King @ 2013-02-18 17:42 UTC (permalink / raw)
To: Thomas Rast
Cc: git, Shawn Pearce, Jakub Narebski, Christian Couder, Pat Thoyts,
Paul Mackerras, Carlos Martín Nieto, Thomas Gummerer,
David Michael Barr, Ramkumar Ramachandra, Jens Lehmann,
Nguyen Thai Ngoc Duy
In-Reply-To: <87ehgd1qq2.fsf@pctrast.inf.ethz.ch>
On Mon, Feb 18, 2013 at 06:23:01PM +0100, Thomas Rast wrote:
> * We need an org admin. AFAIK this was done by Peff and Shawn in
> tandem last year. Would you do it again?
I will do it again, if people feel strongly about Git being a part of
it. However, I have gotten a little soured on the GSoC experience. Not
because of anything Google has done; it's a good idea, and I think they
do a fine of administering the program. But I have noticed that the work
that comes out of GSoC the last few years has quite often not been
merged, or not made a big impact in the codebase, and nor have the
participants necessarily stuck around.
And I do not want to blame the students here (some of whom are on the cc
list :) ). They are certainly under no obligation to stick around after
GSoC ends, and I know they have many demands on their time. But I am
also thinking about what Git wants to get out of GSoC (and to my mind,
the most important thing is contributors).
As far as merged code, I think part of the problem is that git is fairly
mature at this point. The most interesting projects are of a bigger
scope than a student with no experience in the code base can do in a
summer project. Maybe that means we need to do a better job of breaking
projects down into reasonably sized sub-components. Or maybe it means
the project is hitting a point of diminishing returns for GSoC. I don't
know.
There are a few counterpoints I can think of:
- Even though not all projects are winners, _some_ are. I see Carlos
and Ram on the cc list, two people who started as GSoC students and
stuck around.
- There is also the angle that even if _Git_ doesn't benefit directly
from people sticking around, those people may float into other open
source projects and work on them. Which makes the world a better
place on the whole.
So I don't know. Those are just some things that have been floating
around in my head. Feel free to ignore or discuss.
But thanks for getting the ball rolling, Thomas. If we are going to do
it, sooner is better, and if we aren't, then we should probably do so
consciously, and not just miss the deadline accidentally. :)
> * We should prepare an "ideas page". Last year, Peff made one on
>
> https://github.com/peff/git/wiki/SoC-2012-Ideas
>
> I couldn't edit it there over git access[1], so I made a clone in "my"
> github wiki:
> [...]
> [1] That's a bit silly really, since I *can* edit it via the web
> interface. Peff, perhaps you can get that fixed?
Ugh, I would have to write ruby code to fix that. I'll try to trick
somebody else here into fixing it. :)
> [2] Unless Peff wants to take it over again? You could just pull it
> from the git version, it's based on your history.
I think it is as good on your repo as on mine. The kernel.org wiki is
also up, and the github/peff/git one was supposed to be temporary. But I
really hate any wiki that I cannot edit with vim. I guess we need to
have a discussion as a group about where the "official" wiki should
live, and it should go there (I can also put it at github/git/git, which
is a more sane place; but I do not want to compete with kernel.org's
wiki unless there is community consensus that we are moving).
-Peff
^ permalink raw reply
* Re: Google Summer of Code 2013 (GSoC13)
From: Thomas Rast @ 2013-02-18 17:46 UTC (permalink / raw)
To: git
Cc: Jeff King, Shawn Pearce, Jakub Narebski, Christian Couder,
Pat Thoyts, Paul Mackerras, Carlos Martín Nieto,
Thomas Gummerer, David Michael Barr, Ramkumar Ramachandra,
Jens Lehmann, Nguyen Thai Ngoc Duy
In-Reply-To: <87ehgd1qq2.fsf@pctrast.inf.ethz.ch>
Thomas Rast <trast@inf.ethz.ch> writes:
> * We should prepare an "ideas page"[...]
> https://github.com/trast/git/wiki/SoC-2013-Ideas
>From where I'm currently sitting, I won't have the time to mentor this
year. So my two earlier proposals are essentially up for grabs:
1. Improving parallelism in various commands
-----------------------------------------
Git is mostly written single-threaded, with a few commands having
bolted-on extensions to support parallel operation (notably git-grep,
git-pack-objects and the core.preloadIndex feature).
We have recently looked into some of these areas and made a few
optimizations, but a big roadblock is that pack access is entirely
single-threaded. The project would consist of the following steps:
* In preparation (the half-step): identify commands that could
benefit from parallelism. `git grep --cached` and `git grep
COMMIT` come to mind, but most likely also `git diff` and `git log
-p`. You can probably find more.
* Rework the pack access mechanisms to allow the maximum possible
parallel access.
* Rework the commands found in the first step to use parallel pack
access if possible. Along the way, document the improvements with
performance tests.
The actual programming must be done in C using pthreads for obvious
reasons. At the very least you should not be scared of low-level
programming. Prior experience and access to one or more multi-core
computers is a plus.
This one is probably still a contender. However, it might be worth
first looking into whether using libgit2 for pack reading would be
easier and faster, since it is written to be reentrant from the ground
up.
2. Improving the `git add -p` interface
------------------------------------
The interface behind `git {add|commit|stash|reset} {-p|-i}` is shared
and called `git-add--interactive.perl`. This project would mostly
focus on the `--patch` side, as that seems to be much more widely
used; however, improvements to `--interactive` would probably also be
welcome.
The `--patch` interface suffers from some design flaws caused largely
by how the script grew:
* Application is not atomic: hitting Ctrl-C midway through patching
may still touch files.
* The terminal/line-based interface becomes a problem if diff hunks
are too long to fit in your terminal.
* Cannot go back and forth between files.
* Cannot reverse the direction of the patch.
* Cannot look at the diff in word-diff mode (and apply it normally).
Due to the current design it is also pretty hard to add these features
without adding to the mess. Thus the project consists of:
* Come up with more ideas for features/improvements and discuss them
with users.
* Cleanly redesigning the main interface loop to allow for the above
features.
* Implement the new features.
As the existing code is written in Perl, that is what you will use for
this project.
This has already featured twice, and resulted in proposals that were
insufficiently advanced and too little work for a GSoC. If nobody feels
like extending it to a bigger project, I'll just scrap it.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: Google Summer of Code 2013 (GSoC13)
From: Ramkumar Ramachandra @ 2013-02-18 18:13 UTC (permalink / raw)
To: Thomas Rast
Cc: git, Jeff King, Shawn Pearce, Jakub Narebski, Christian Couder,
Pat Thoyts, Paul Mackerras, Carlos Martín Nieto,
Thomas Gummerer, David Michael Barr, Jens Lehmann,
Nguyen Thai Ngoc Duy
In-Reply-To: <87k3q5zfaa.fsf@pctrast.inf.ethz.ch>
Thomas Rast wrote:
> 2. Improving the `git add -p` interface
> ------------------------------------
> * The terminal/line-based interface becomes a problem if diff hunks
> are too long to fit in your terminal.
I don't know if it's worth coming up with another interface. The best
solution for this is editor integration, in my opinion. I use Magit
mostly for just the graphical staging/ unstaging. There's also a
Fugitive.vim for vim.
> * Cannot look at the diff in word-diff mode (and apply it normally).
Yes, this is a major limitation that would be nice to fix.
Also: Having to figure out, heuristically, when to actually turn it on
might be a worthwhile feature, especially for services like GitHub.
> As the existing code is written in Perl, that is what you will use for
> this project.
I don't know- is Perl a possible deterrent?
Won't getting a word-diff to apply involve C work though? (patching
builtin/apply.c?)
^ permalink raw reply
* Re: Google Summer of Code 2013 (GSoC13)
From: Ronan Keryell @ 2013-02-18 18:02 UTC (permalink / raw)
To: Thomas Rast
Cc: git, Jeff King, Shawn Pearce, Jakub Narebski, Christian Couder,
Pat Thoyts, Paul Mackerras, Carlos Martín Nieto,
Thomas Gummerer, David Michael Barr, Ramkumar Ramachandra,
Jens Lehmann, Nguyen Thai Ngoc Duy
In-Reply-To: <87k3q5zfaa.fsf@pctrast.inf.ethz.ch>
>>>>> On Mon, 18 Feb 2013 18:46:05 +0100, Thomas Rast <trast@student.ethz.ch> said:
Thomas> The actual programming must be done in C using pthreads
Thomas> for obvious reasons.
Are there obvious reasons OpenMP would not be enough to do the job?
It looks like a trade-off between the code readability & portability
versus the real expressiveness of what parallelism control details are
needed.
--
Ronan KERYELL |\/ Phone: +1 650 386 6482
SILKAN Wild Systems |/)
4962 El Camino Real #201 K Ronan.Keryell@silkan.com
Los Altos, CA 94022 |\ skype:keryell
USA | \ http://silkan.com
^ permalink raw reply
* [PATCH] l10n: de.po: translate 35 new messages
From: Ralf Thielow @ 2013-02-18 18:22 UTC (permalink / raw)
To: trast, jk, stimming; +Cc: git, Ralf Thielow
Translate 35 new messages came from git.pot update
in 9caaf23 (l10n: Update git.pot (35 new, 14 removed
messages)).
Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
---
po/de.po | 140 +++++++++++++++++++++++++++++++--------------------------------
1 file changed, 68 insertions(+), 72 deletions(-)
diff --git a/po/de.po b/po/de.po
index df98a0f..9690cd7 100644
--- a/po/de.po
+++ b/po/de.po
@@ -358,14 +358,14 @@ msgid "gpg failed to sign the data"
msgstr "gpg beim Signieren der Daten fehlgeschlagen"
#: gpg-interface.c:112
-#, fuzzy, c-format
+#, c-format
msgid "could not create temporary file '%s': %s"
-msgstr "konnte Datei '%s' nicht erstellen"
+msgstr "konnte temporäre Datei '%s' nicht erstellen: %s"
#: gpg-interface.c:115
-#, fuzzy, c-format
+#, c-format
msgid "failed writing detached signature to '%s': %s"
-msgstr "Fehler beim Erstellen des Pfades '%s'%s"
+msgstr "Fehler beim Schreiben der Signatur nach '%s': %s"
#: grep.c:1622
#, c-format
@@ -1443,9 +1443,8 @@ msgid "failed to unlink '%s'"
msgstr "Konnte '%s' nicht entfernen"
#: builtin/add.c:20
-#, fuzzy
msgid "git add [options] [--] <pathspec>..."
-msgstr "git add [Optionen] [--] [<Dateimuster>...]"
+msgstr "git add [Optionen] [--] [<Pfadspezifikation>...]"
#: builtin/add.c:63
#, c-format
@@ -1601,6 +1600,21 @@ msgid ""
"With the current Git version, the command is restricted to the current "
"directory."
msgstr ""
+"Das Verhalten von 'git add %s (oder %s)' ohne ein Pfad-Argument von\n"
+"einem Unterverzeichnis aus, wird in Git 2.0 geändert und sollte nicht\n"
+"mehr verwendet werden.\n"
+"Um Dateien des gesamten Projektverzeichnisses hinzuzufügen, führen Sie aus:\n"
+"\n"
+" git add %s :/\n"
+" (oder git add %s :/)\n"
+"\n"
+"Zur Einschränkung auf das aktuelle Verzeichnis, führen Sie aus:\n"
+"\n"
+" git add %s .\n"
+" (oder git add %s .)\n"
+"\n"
+"Mit der aktuellen Version von Git ist das Kommando auf das aktuelle\n"
+"Verzeichnis beschränkt."
#: builtin/add.c:381
msgid "-A and -u are mutually incompatible"
@@ -2412,16 +2426,16 @@ msgstr "[%d voraus, %d hinterher]"
#: builtin/branch.c:469
msgid " **** invalid ref ****"
-msgstr ""
+msgstr " **** ungültige Referenz ****"
#: builtin/branch.c:560
msgid "(no branch)"
msgstr "(kein Zweig)"
#: builtin/branch.c:593
-#, fuzzy, c-format
+#, c-format
msgid "object '%s' does not point to a commit"
-msgstr "'%s' zeigt auf keine Version"
+msgstr "Objekt '%s' zeigt auf keine Version"
#: builtin/branch.c:625
msgid "some refs could not be read"
@@ -2571,33 +2585,30 @@ msgid "--column and --verbose are incompatible"
msgstr "Die Optionen --column und --verbose sind inkompatibel."
#: builtin/branch.c:845
-#, fuzzy
msgid "branch name required"
-msgstr "Kein Zweigname spezifiziert"
+msgstr "Zweigname erforderlich"
#: builtin/branch.c:860
-#, fuzzy
msgid "Cannot give description to detached HEAD"
-msgstr "Kann Hauptzweig des externen Projektarchivs nicht bestimmen"
+msgstr "zu losgelöster Zweigspitze (HEAD) kann keine Beschreibung hinterlegt werden"
#: builtin/branch.c:865
-#, fuzzy
msgid "cannot edit description of more than one branch"
-msgstr "bearbeitet die Beschreibung für den Zweig"
+msgstr "Beschreibung von mehr als einem Zweig kann nicht bearbeitet werden"
#: builtin/branch.c:872
-#, fuzzy, c-format
+#, c-format
msgid "No commit on branch '%s' yet."
-msgstr "Kein solcher Zweig '%s'"
+msgstr "Noch keine Version in Zweig '%s'."
#: builtin/branch.c:875
-#, fuzzy, c-format
+#, c-format
msgid "No branch named '%s'."
-msgstr "Ungültiger Zweig-Name: '%s'"
+msgstr "Zweig '%s' nicht vorhanden."
#: builtin/branch.c:888
msgid "too many branches for a rename operation"
-msgstr ""
+msgstr "zu viele Zweige angegeben"
#: builtin/branch.c:893
#, c-format
@@ -2731,28 +2742,24 @@ msgid "suppress progress reporting"
msgstr "unterdrückt Fortschrittsanzeige"
#: builtin/check-ignore.c:151
-#, fuzzy
msgid "cannot specify pathnames with --stdin"
-msgstr "kann -a nicht mit -d benutzen"
+msgstr "Angabe von Pfadnamen kann nicht gemeinsam mit --stdin verwendet werden"
#: builtin/check-ignore.c:154
msgid "-z only makes sense with --stdin"
-msgstr ""
+msgstr "Die Option -z kann nur mit --stdin verwendet werden."
#: builtin/check-ignore.c:156
-#, fuzzy
msgid "no path specified"
-msgstr "kein externes Projektarchiv angegeben"
+msgstr "kein Pfad angegeben"
#: builtin/check-ignore.c:160
-#, fuzzy
msgid "--quiet is only valid with a single pathname"
-msgstr "verwendet [PATCH n/m] auch mit einzelnem Patch"
+msgstr "Die Option --quiet ist nur mit einem einzelnen Pfadnamen gültig."
#: builtin/check-ignore.c:162
-#, fuzzy
msgid "cannot have both --quiet and --verbose"
-msgstr "Kann den aktuellen Zustand der Bereitstellung nicht speichern"
+msgstr "Die Optionen --quiet und --verbose können nicht gemeinsam verwendet werden."
#: builtin/checkout-index.c:126
msgid "git checkout-index [options] [--] [<file>...]"
@@ -3421,14 +3428,12 @@ msgid "--command must be the first argument"
msgstr "Die Option --command muss an erster Stelle stehen."
#: builtin/commit.c:34
-#, fuzzy
msgid "git commit [options] [--] <pathspec>..."
-msgstr "git commit [Optionen] [--] <Dateimuster>..."
+msgstr "git commit [Optionen] [--] <Pfadspezifikation>..."
#: builtin/commit.c:39
-#, fuzzy
msgid "git status [options] [--] <pathspec>..."
-msgstr "git status [Optionen] [--] <Dateimuster>..."
+msgstr "git status [Optionen] [--] <Pfadspezifikation>..."
#: builtin/commit.c:44
msgid ""
@@ -3604,17 +3609,17 @@ msgstr ""
"und versuchen Sie es erneut.\n"
#: builtin/commit.c:735
-#, fuzzy, c-format
+#, c-format
msgid ""
"Please enter the commit message for your changes. Lines starting\n"
"with '%c' will be ignored, and an empty message aborts the commit.\n"
msgstr ""
"Bitte geben Sie eine Versionsbeschreibung für Ihre Änderungen ein. Zeilen,\n"
-"die mit '#' beginnen, werden ignoriert, und eine leere Versionsbeschreibung\n"
+"die mit '%c' beginnen, werden ignoriert, und eine leere Versionsbeschreibung\n"
"bricht die Eintragung ab.\n"
#: builtin/commit.c:740
-#, fuzzy, c-format
+#, c-format
msgid ""
"Please enter the commit message for your changes. Lines starting\n"
"with '%c' will be kept; you may remove them yourself if you want to.\n"
@@ -3622,7 +3627,7 @@ msgid ""
msgstr ""
"Bitte geben Sie eine Versionsbeschreibung für Ihre Änderungen ein. Zeilen, "
"die\n"
-"mit '#' beginnen, werden beibehalten; wenn Sie möchten, können Sie diese "
+"mit '%c' beginnen, werden beibehalten; wenn Sie möchten, können Sie diese "
"entfernen.\n"
"Eine leere Versionsbeschreibung bricht die Eintragung ab.\n"
@@ -4403,9 +4408,8 @@ msgid "deepen history of shallow clone"
msgstr "vertieft die Historie eines flachen Klon"
#: builtin/fetch.c:86
-#, fuzzy
msgid "convert to a complete repository"
-msgstr "um von einem lokalen Projektarchiv zu klonen"
+msgstr "konvertiert zu einem vollständigen Projektarchiv"
#: builtin/fetch.c:88 builtin/log.c:1119
msgid "dir"
@@ -4561,14 +4565,13 @@ msgid "You need to specify a tag name."
msgstr "Sie müssen den Namen der Markierung angeben."
#: builtin/fetch.c:981
-#, fuzzy
msgid "--depth and --unshallow cannot be used together"
-msgstr "Die Optionen -x und -X können nicht gemeinsam verwendet werden."
+msgstr "Die Optionen --depth und --unshallow können nicht gemeinsam verwendet werden."
#: builtin/fetch.c:983
-#, fuzzy
msgid "--unshallow on a complete repository does not make sense"
-msgstr "Die Option --name-only kann nicht verwendet werden."
+msgstr "Die Option --unshallow kann nicht in einem vollständigen Projektarchiv "
+"verwendet werden."
#: builtin/fetch.c:1002
msgid "fetch --all does not take a repository argument"
@@ -6122,7 +6125,7 @@ msgstr ""
"Zusammenführung abzuschließen.\n"
#: builtin/merge.c:788
-#, fuzzy, c-format
+#, c-format
msgid ""
"Please enter a commit message to explain why this merge is necessary,\n"
"especially if it merges an updated upstream into a topic branch.\n"
@@ -6135,7 +6138,7 @@ msgstr ""
"insbesondere wenn es einen aktualisierten, externen Zweig mit einem Thema-"
"Zweig zusammenführt.\n"
"\n"
-"Zeilen beginnend mit '#' werden ignoriert, und eine leere Beschreibung "
+"Zeilen beginnend mit '%c' werden ignoriert, und eine leere Beschreibung "
"bricht die Eintragung ab.\n"
#: builtin/merge.c:812
@@ -6606,9 +6609,8 @@ msgid "unable to start 'show' for object '%s'"
msgstr "konnte 'show' für Objekt '%s' nicht starten"
#: builtin/notes.c:143
-#, fuzzy
msgid "could not read 'show' output"
-msgstr "Konnte '%s' nicht lesen"
+msgstr "Konnte Ausgabe von 'show' nicht lesen."
#: builtin/notes.c:151
#, c-format
@@ -7213,7 +7215,6 @@ msgstr ""
"für weitere Details."
#: builtin/push.c:224
-#, fuzzy
msgid ""
"Updates were rejected because the remote contains work that you do\n"
"not have locally. This is usually caused by another repository pushing\n"
@@ -7221,18 +7222,18 @@ msgid ""
"'git pull') before pushing again.\n"
"See the 'Note about fast-forwards' in 'git push --help' for details."
msgstr ""
-"Aktualisierungen wurden zurückgewiesen, weil die Spitze Ihres aktuellen\n"
-"Zweiges hinter seinem externen Gegenstück zurückgefallen ist. Führen Sie\n"
-"die externen Änderungen zusammen (z.B. 'git pull') bevor Sie erneut\n"
-"versenden.\n"
+"Aktualisierungen wurden zurückgewiesen, weil das Fernarchiv Versionen enthält,\n"
+"die lokal nicht vorhanden sind. Das wird üblicherweise durch das Versenden von\n"
+"Versionen auf dieselbe Referenz von einem anderen Projektarchiv aus verursacht.\n"
+"Vielleicht müssen Sie die externen Änderungen zusammenzuführen (z.B. 'git pull')\n"
+"bevor Sie erneut versenden.\n"
"Siehe auch die Sektion 'Note about fast-forwards' in 'git push --help'\n"
"für weitere Details."
#: builtin/push.c:231
-#, fuzzy
msgid "Updates were rejected because the tag already exists in the remote."
msgstr ""
-"Aktualisierungen wurden zurückgewiesen, weil die Zielreferenz bereits\n"
+"Aktualisierungen wurden zurückgewiesen, weil die Markierung bereits\n"
"im Fernarchiv existiert."
#: builtin/push.c:234
@@ -7241,6 +7242,9 @@ msgid ""
"or update a remote ref to make it point at a non-commit object,\n"
"without using the '--force' option.\n"
msgstr ""
+"Sie können keine externe Referenz aktualisieren, die auf ein Objekt zeigt,\n"
+"das keine Version ist, oder es auf ein solches Objekt zeigen lassen, ohne\n"
+"die Option '--force' zu verwenden.\n"
#: builtin/push.c:294
#, c-format
@@ -7351,9 +7355,8 @@ msgid "prune locally removed refs"
msgstr "entfernt lokal gelöschte Referenzen"
#: builtin/push.c:439
-#, fuzzy
msgid "bypass pre-push hook"
-msgstr "umgeht \"pre-commit hook\""
+msgstr "umgeht \"pre-push hook\""
#: builtin/push.c:448
msgid "--delete is incompatible with --all, --mirror and --tags"
@@ -8536,20 +8539,18 @@ msgid "could not verify the tag '%s'"
msgstr "Konnte Markierung '%s' nicht verifizieren"
#: builtin/tag.c:249
-#, fuzzy, c-format
+#, c-format
msgid ""
"\n"
"Write a tag message\n"
"Lines starting with '%c' will be ignored.\n"
msgstr ""
"\n"
-"#\n"
-"# Geben Sie eine Markierungsbeschreibung ein.\n"
-"# Zeilen, die mit '#' beginnen, werden ignoriert.\n"
-"#\n"
+"Geben Sie eine Markierungsbeschreibung ein.\n"
+"Zeilen, die mit '%c' beginnen, werden ignoriert.\n"
#: builtin/tag.c:253
-#, fuzzy, c-format
+#, c-format
msgid ""
"\n"
"Write a tag message\n"
@@ -8557,11 +8558,9 @@ msgid ""
"want to.\n"
msgstr ""
"\n"
-"#\n"
-"# Geben Sie eine Markierungsbeschreibung ein.\n"
-"# Zeilen, die mit '#' beginnen, werden behalten; Sie dürfen diese\n"
-"# selbst entfernen wenn Sie möchten.\n"
-"#\n"
+"Geben Sie eine Markierungsbeschreibung ein.\n"
+"Zeilen, die mit '%c' beginnen, werden behalten; Sie dürfen diese\n"
+"selbst entfernen wenn Sie möchten.\n"
#: builtin/tag.c:292
msgid "unable to sign the tag"
@@ -8942,7 +8941,6 @@ msgid "Print lines matching a pattern"
msgstr "Stellt Zeilen dar, die einem Muster entsprechen"
#: common-cmds.h:17
-#, fuzzy
msgid "Create an empty Git repository or reinitialize an existing one"
msgstr ""
"Erstellt ein leeres Git-Projektarchiv oder initialisiert ein bestehendes neu"
@@ -9869,14 +9867,12 @@ msgid "blob"
msgstr "Blob"
#: git-submodule.sh:979
-#, fuzzy
msgid "Submodules changed but not updated:"
-msgstr "# Unterprojekte geändert, aber nicht aktualisiert:"
+msgstr "Unterprojekte geändert, aber nicht aktualisiert:"
#: git-submodule.sh:981
-#, fuzzy
msgid "Submodule changes to be committed:"
-msgstr "# Änderungen in Unterprojekt zum Eintragen:"
+msgstr "Änderungen in Unterprojekt zum Eintragen:"
#: git-submodule.sh:1129
#, sh-format
--
1.8.2.rc0
^ permalink raw reply related
* Re: [PATCH 11/13] contrib/subtree: Make each test self-contained
From: greened @ 2013-02-18 18:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: James Nylen, git, Techlive Zheng
In-Reply-To: <7v4nhqwzzi.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> I also think it would be a good idea for you to learn to push back
> to the original authors; fixing problems in patches by others, while
> is a good way to learn how their thinking process went, is not
> necessarily fun.
Sure, but in this case I said I'd handle it so I will.
-David
^ permalink raw reply
* Re: [ANNOUNCE] Git v1.8.2-rc0
From: Matthieu Moy @ 2013-02-18 18:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Linux Kernel
In-Reply-To: <7vk3q6e94s.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Git v1.8.2 Release Notes (draft)
> ========================
>
> Backward compatibility notes
> ----------------------------
>
> In the upcoming major release (tentatively called 1.8.2), we will
> change the behavior of the "git push" command.
>
> When "git push [$there]" does not say what to push, we have used the
> traditional "matching" semantics so far (all your branches were sent
> to the remote as long as there already are branches of the same name
> over there). We will use the "simple" semantics
I don't understand: wasn't this supposed to happen in Git 2.0? Did you
mean "In the upcoming major release (tentatively called *2.0*)"?
Also, you may want to mention the argumentless "git add -u" change too.
It currently has an item below, but this is a future
backward-incompatible change so it may deserve to appear in this section
too.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH 13/13] contrib/subtree: Remove --annotate
From: greened @ 2013-02-18 18:39 UTC (permalink / raw)
To: James Nylen; +Cc: Junio C Hamano, git
In-Reply-To: <CABVa4NiyVksEn4+NqBPXpaWGYnP6FeUqeacLOnAOHtw9FgMJdA@mail.gmail.com>
James Nylen <jnylen@gmail.com> writes:
> I don't agree that removing `--annotate` obviates the need for `--unannotate`.
>
> I responded on 1/17 with what I think is a typical and normal use case
> for that option:
Sorry, I must have missed that reply.
> - add "fancylib" as a subtree of "myprog"
> - commit to "myprog" repo: "fancylib: don't crash as much"
> - split these commits back out to "fancylib" main repo, and remove
> the "fancylib: " prefix
I can see how that would be useful.
> `--unannotate` is a clunky name, but I think this functionality is
> worth taking another look at. Maybe it could be called
> `--remove-prefix` ?
Should this really be a function of git-subtree? It seems like it would
fit better in a history-rewriting command. Wouldn't rebase -i or even
filter-branch be a better way to do this?
If there's no --annotate I don't see why git-subtree should have the
--unannotate functionality.
Again, I agree that your example is relevant, maybe even common, but I
don't necessarily think git-subtree should be in the business of
rewriting commit messages at all.
I'd appreciate more thoughts from you on this. I want to make sure we
can support your use case.
-David
^ permalink raw reply
* Re: Google Summer of Code 2013 (GSoC13)
From: Ramkumar Ramachandra @ 2013-02-18 18:44 UTC (permalink / raw)
To: Jeff King
Cc: Thomas Rast, git, Shawn Pearce, Jakub Narebski, Christian Couder,
Pat Thoyts, Paul Mackerras, Carlos Martín Nieto,
Thomas Gummerer, David Barr, Jens Lehmann, Nguyen Thai Ngoc Duy
In-Reply-To: <20130218174239.GB22832@sigill.intra.peff.net>
[corrected David Barr's email address]
Jeff King wrote:
> And I do not want to blame the students here (some of whom are on the cc
> list :) ). They are certainly under no obligation to stick around after
> GSoC ends, and I know they have many demands on their time. But I am
> also thinking about what Git wants to get out of GSoC (and to my mind,
> the most important thing is contributors).
>
> As far as merged code, I think part of the problem is that git is fairly
> mature at this point. The most interesting projects are of a bigger
> scope than a student with no experience in the code base can do in a
> summer project. Maybe that means we need to do a better job of breaking
> projects down into reasonably sized sub-components. Or maybe it means
> the project is hitting a point of diminishing returns for GSoC. I don't
> know.
I'll be frank here. I think the main reason for a student to stick
around is to see more of his code hit `master`. I think it is
absolutely essential to get students constantly post iteration after
iteration on the list. It would be nice to get them connected with 2~3
people in the community who will follow their progress and pitch in
everytime they post an iteration. It might also make sense to stage
their work in the main tree (a gsoc/ namespace?), so we can just
checkout to their branch to demo what they've done.
Also, we need more projects that will scratch everyday itches. A
collection of related tiny features might not be a bad idea. Often,
we risk erring on the side of too-big-for-one-summer when it comes to
specifying projects. What's the harm of including something estimated
to take 80% of a summer?
On a related note, I don't like our Wiki. It's down half the time,
and it's very badly maintained. I want to write content for our Wiki
from the comfort of my editor, with version control aiding me. And I
can't stand archaic WikiText.
^ permalink raw reply
* Re: Google Summer of Code 2013 (GSoC13)
From: Jeff King @ 2013-02-18 18:58 UTC (permalink / raw)
To: Ramkumar Ramachandra
Cc: Thomas Rast, git, Shawn Pearce, Jakub Narebski, Christian Couder,
Pat Thoyts, Paul Mackerras, Carlos Martín Nieto,
Thomas Gummerer, David Barr, Jens Lehmann, Nguyen Thai Ngoc Duy
In-Reply-To: <CALkWK0nDEwgDwnVktmM8abv3ZgQmJCOm8LBe25UKR485PZMPfA@mail.gmail.com>
On Tue, Feb 19, 2013 at 12:14:19AM +0530, Ramkumar Ramachandra wrote:
> I'll be frank here. I think the main reason for a student to stick
> around is to see more of his code hit `master`. I think it is
> absolutely essential to get students constantly post iteration after
> iteration on the list. It would be nice to get them connected with 2~3
> people in the community who will follow their progress and pitch in
> everytime they post an iteration. It might also make sense to stage
> their work in the main tree (a gsoc/ namespace?), so we can just
> checkout to their branch to demo what they've done.
I agree. One of the main problems with GSoC projects is that the student
goes away and works for a while, and then at the end does not
necessarily have something mergeable. That is not how regular
contributors work. They post works in progress, get feedback, and
iterate on ideas. They break work into easily digestable and reviewable
chunks. So maybe the mentors should be focusing more on that than on
actual code problems.
> Also, we need more projects that will scratch everyday itches. A
> collection of related tiny features might not be a bad idea. Often,
> we risk erring on the side of too-big-for-one-summer when it comes to
> specifying projects. What's the harm of including something estimated
> to take 80% of a summer?
I very much agree with you here. One problem is that those smaller
projects often do not sound as grand or as interesting, and so students
do not propose them. We have to work with the applicants we get.
> On a related note, I don't like our Wiki. It's down half the time,
> and it's very badly maintained. I want to write content for our Wiki
> from the comfort of my editor, with version control aiding me. And I
> can't stand archaic WikiText.
Agreed on all of those points. Putting the Wiki on GitHub fixes that.
But it means contributors need to have a GitHub account. On the other
hand, I think kernel.org wiki contributors need an account these days?
And GitHub is putting some active effort into finding and killing spammy
accounts, which might keep wiki spam down (I do not pay too much
attention to those efforts, but on kernel.org, it is mostly up to the
Git community to do it ourselves).
-Peff
^ permalink raw reply
* feature request
From: Jay Townsend @ 2013-02-18 18:52 UTC (permalink / raw)
To: git
Hi everyone,
Just would like to request a security feature to help secure peoples
github accounts more by supporting 2 factor authentication like the
yubikey more information can be found from this link
www.yubico.com/develop/ and googles 2 factor authentication. Hope it
gets implemented as I think it would make a great feature
^ permalink raw reply
* Re: [PATCH] shell-prompt: clean up nested if-then
From: Jonathan Nieder @ 2013-02-18 19:10 UTC (permalink / raw)
To: Martin Erik Werner; +Cc: gitster, git, trsten, Simon Oosthoek, Felipe Contreras
In-Reply-To: <1361204601-4573-1-git-send-email-martinerikwerner@gmail.com>
Hi Martin,
Martin Erik Werner wrote:
> Minor clean up of if-then nesting in checks for environment variables
> and config options. No functional changes.
Yeah, the nesting was getting a little deep. Thanks for the cleanup.
May we have your sign-off?
Once this is signed off,
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Patch left unsnipped for reference.
> ---
> contrib/completion/git-prompt.sh | 27 +++++++++++++--------------
> 1 file changed, 13 insertions(+), 14 deletions(-)
>
> diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
> index 9b2eec2..e29694d 100644
> --- a/contrib/completion/git-prompt.sh
> +++ b/contrib/completion/git-prompt.sh
> @@ -320,26 +320,25 @@ __git_ps1 ()
> b="GIT_DIR!"
> fi
> elif [ "true" = "$(git rev-parse --is-inside-work-tree 2>/dev/null)" ]; then
> - if [ -n "${GIT_PS1_SHOWDIRTYSTATE-}" ]; then
> - if [ "$(git config --bool bash.showDirtyState)" != "false" ]; then
> - git diff --no-ext-diff --quiet --exit-code || w="*"
> - if git rev-parse --quiet --verify HEAD >/dev/null; then
> - git diff-index --cached --quiet HEAD -- || i="+"
> - else
> - i="#"
> - fi
> + if test -n "${GIT_PS1_SHOWDIRTYSTATE-}" &&
> + test "$(git config --bool bash.showDirtyState)" != "false"
> + then
> + git diff --no-ext-diff --quiet --exit-code || w="*"
> + if git rev-parse --quiet --verify HEAD >/dev/null; then
> + git diff-index --cached --quiet HEAD -- || i="+"
> + else
> + i="#"
> fi
> fi
> if [ -n "${GIT_PS1_SHOWSTASHSTATE-}" ]; then
> git rev-parse --verify refs/stash >/dev/null 2>&1 && s="$"
> fi
>
> - if [ -n "${GIT_PS1_SHOWUNTRACKEDFILES-}" ]; then
> - if [ "$(git config --bool bash.showUntrackedFiles)" != "false" ]; then
> - if [ -n "$(git ls-files --others --exclude-standard)" ]; then
> - u="%"
> - fi
> - fi
> + if test -n "${GIT_PS1_SHOWUNTRACKEDFILES-}" &&
> + test "$(git config --bool bash.showUntrackedFiles)" != "false" &&
> + test -n "$(git ls-files --others --exclude-standard)"
> + then
> + u="%"
> fi
>
> if [ -n "${GIT_PS1_SHOWUPSTREAM-}" ]; then
> --
^ permalink raw reply
* Re: [PATCH v5] submodule: add 'deinit' command
From: Jens Lehmann @ 2013-02-18 19:20 UTC (permalink / raw)
To: Junio C Hamano
Cc: Phil Hord, Git Mailing List, Heiko Voigt, Michael J Gruber,
Marc Branchaud, W. Trevor King
In-Reply-To: <7v38wufu5t.fsf@alter.siamese.dyndns.org>
Am 17.02.2013 23:32, schrieb Junio C Hamano:
> Jens Lehmann <Jens.Lehmann@web.de> writes:
>> diff --git a/git-submodule.sh b/git-submodule.sh
>> index 004c034..0fb6ee0 100755
>> --- a/git-submodule.sh
>> +++ b/git-submodule.sh
>> @@ -547,6 +548,82 @@ cmd_init()
>> }
>>
>> #
>> +# Unregister submodules from .git/config and remove their work tree
>> +#
>> +# $@ = requested paths (use '.' to deinit all submodules)
>> +#
>> +cmd_deinit()
>> +{
>> + # parse $args after "submodule ... init".
>> + while test $# -ne 0
>> + do
>> ..
>> + done
>> +
>> + if test $# = 0
>> + then
>> + die "$(eval_gettext "Use '.' if you really want to deinitialize all submodules")"
>
> I do not think I saw anybody mentioned this so far, but how is
> "deinit" supposed to work inside a subdirectory of a superproject?
> If the answer is to work on submodules appear in that subdirectory,
> '.' should probably not mean "all in the superproject" I think?
"git submodule" fails when not run in the top level directory.
>> + module_list "$@" |
>> + while read mode sha1 stage sm_path
>> + do
>> + die_if_unmatched "$mode"
>> + name=$(module_name "$sm_path") || exit
>> + url=$(git config submodule."$name".url)
>> + if test -z "$url"
>> + then
>> + test $# -ne 1 || test "$@" = "." ||
>> + say "$(eval_gettext "Submodule '\$name' is not initialized for path '\$sm_path'")"
>> + continue
>> + fi
>
> This 'test "$@" = "."' makes readers feel uneasy. This particular
> invocation happens to be safe only because it is protected with
> "test $# -ne 1 ||", but for all other values of $# this will result
> in a syntax error. 'test "$1" = "."' would make the intention of
> the check more clear.
I used $@ here because it makes the code more robust against
someone accidentally removing the "test $# -ne 1 ||" (as it then
will fail when $# > 1 in one of the tests). But looking at it
again I agree that "$1" might better show the intention here and
the "$@" can easily make people suspicious.
> But stepping back a bit, is the condition this test is trying to
> warn against really worth warning?
>
> It seems that this "warn if user told us to deinitialize a submodule
> that hasn't been initialized" is from the very initial round of this
> series, and not something other people asked for during the review.
> If somebody did
>
> git submodule deinit foo bar
>
> and then later said:
>
> git submodule deinit foo
>
> would it a mistake that the user wants to be warned about?
>
> Perhaps the user did not mean to deinitialize foo (e.g. wanted to
> *initialize* foo instead, or wanted to deinitialize *foz* instead)
> and that is worth warning about? I am not sure, but I have a
> feeling that we can do without this check.
Hmm, if you would replace "submodule deinit" with "rm" in the above
example, the "rm" would not only warn but error out the second time.
But on the other hand doing a "git submodule init" again on already
initialized submodules will silently do nothing, which seems to be
the better analogy here. So yes, it looks like we can do without.
Ok, unless someone speaks up and argues in favor of this message
I'll remove it in v6.
> Also the value of submodule.$name.url is not used in the later
> codepath to ensure that the named submodule is in the pristine state
> in the superproject's working tree (i.e. no submodule.$name section
> in the local configuration, no working tree for that submodule), so
> it may be even a good change to remove the "does submodule.$name.url
> exist" check and always do the "deinitialize" process. That would
> give the users a way to recover from a state where a submodule is
> only half initialized for some reason safely, no?
That is a very good point. It makes sense that if we don't nuke the
whole test to at least remove the "continue" there (in case someone
fiddled with .git/config but wants to get rid of the work tree in a
safe manner later).
^ permalink raw reply
* Re: [ANNOUNCE] Git v1.8.2-rc0
From: Tim Chase @ 2013-02-18 19:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk3q6e94s.fsf@alter.siamese.dyndns.org>
On 2013-02-17 16:52, Junio C Hamano wrote:
> * Color specifiers, e.g. "%C(blue)Hello%C(reset)", used in the
> "--format=" option of "git log" and friends can be disabled when
> the output is not sent to a terminal by prefixing them with
> "auto,", e.g. "%C(auto,blue)Hello%C(auto,reset)".
Thanks so much! It has long annoyed me that I had to maintain pairs
of nigh-identical aliases, one with colors for output on my terminal,
the other alias uncolored for piping to further commands.
-tkc
^ permalink raw reply
* Re: Google Summer of Code 2013 (GSoC13)
From: Jonathan Nieder @ 2013-02-18 19:34 UTC (permalink / raw)
To: Jeff King
Cc: Thomas Rast, git, Shawn Pearce, Jakub Narebski, Christian Couder,
Pat Thoyts, Paul Mackerras, Carlos Martín Nieto,
Thomas Gummerer, David Michael Barr, Ramkumar Ramachandra,
Jens Lehmann, Nguyen Thai Ngoc Duy
In-Reply-To: <20130218174239.GB22832@sigill.intra.peff.net>
Hi,
Jeff King wrote:
> I will do it again, if people feel strongly about Git being a part of
> it. However, I have gotten a little soured on the GSoC experience. Not
> because of anything Google has done; it's a good idea, and I think they
> do a fine of administering the program. But I have noticed that the work
> that comes out of GSoC the last few years has quite often not been
> merged, or not made a big impact in the codebase, and nor have the
> participants necessarily stuck around.
I think that if we can commit enough time to mentor well it's
worthwhile. Even such a negative result is useful, since it can teach
us how good or poor we are at bringing new contributors in and what
parts of that process need more work.
That said, I won't have time to mentor a project on my own. It takes
a lot of time (or luck, to get the student that doesn't need
mentoring). I'd be happy to help on a project with 1 or 2 co-mentors.
Some potential projects (unfiltered --- please take them with a grain
of salt):
- cross-compilable git
- incorporation of the cgit web interface, or formalizing a subset of
libgit.a to export as a stable library to it
- merging the gitweb-caching fork
- moving forward on a project that was the subject of a previous
gsoc project: line-level logging, "rebase --interactive" on top of
sequencer, usable svn remote helper
- collapsable --first-parent history in gitk
http://bugs.debian.org/600001
- drag-and-drop cherry-pick in gitk
- a sub-library of code shared with libgit2 (might be hard because
our notions of strings are different :().
- assimilating the distro builds: "make deb-pkg", "make rpm-pkg",
etc along the same lines as the linux kernel's script/package/,
to help people get recent git installed when they want it
- "please cherry-pick this before testing that" notes for less
scary bisecting
- collaborative notes editing: fix the default notes refspec,
make sure the "notes pull" workflow works well and is documented
well, offer an easy way to hide private notes after the fact
without disrupting public history
Hope that helps,
Jonathan
^ permalink raw reply
* Re: Recursive submodule confusing output (bug?)
From: Jens Lehmann @ 2013-02-18 19:35 UTC (permalink / raw)
To: Will Entriken; +Cc: git
In-Reply-To: <CAFwrLX5nPvySfA05CLgdfoNt-pzQbCq0o+LtGJxZyVwP0EyHcg@mail.gmail.com>
Am 18.02.2013 16:58, schrieb Will Entriken:
> I am running:
>
> git submodule update --recursive
>
> And get the output:
>
> Submodule path 'Submodules/evernote-ios-sdk': checked out
> '391ca643c5b1cd02e9fa869a6b0760436ea452ed'
> Submodule path 'Submodules/facebook-ios-sdk': checked out
> 'ada467f754febd4f2871d15943e9be16b323f114'
> Submodule path 'Submodules/objectiveflickr': checked out
> 'f474a78c807b5fa0c887bf8efaead5be1da637ec'
> Submodule path 'Submodules/sskeychain': checked out
> '8252a69cdfea562223d4dc2e2ccaf01b752d2cc6'
>
> This is a little confusing to me, would this be more appropriate?
>
> Submodule path 'Submodules/ShareKit/Submodules/evernote-ios-sdk':
> checked out '391ca643c5b1cd02e9fa869a6b0760436ea452ed'
> Submodule path 'Submodules/ShareKit/Submodules/facebook-ios-sdk':
> checked out 'ada467f754febd4f2871d15943e9be16b323f114'
> Submodule path 'Submodules/ShareKit/Submodules/objectiveflickr':
> checked out 'f474a78c807b5fa0c887bf8efaead5be1da637ec'
> Submodule path 'Submodules/ShareKit/Submodules/sskeychain':
> checked out '8252a69cdfea562223d4dc2e2ccaf01b752d2cc6'
Yes. (I assume from the output that you have a submodule named
"Submodules/ShareKit/" in the superproject which itself contains
those four submodules inside another "Submodules" directory)
> Please let me know if this is something I may fix.
Sure, go ahead! (I just checked, cmd_update() is the only function
in git-submodule.sh without prefix handling; see cmd_foreach() for
an example of how to do that). And - if you're not already familiar
with it - you'll find a detailed description on how to prepare your
fix in "Documentation/SubmittingPatches".
^ permalink raw reply
* Re: Google Summer of Code 2013 (GSoC13)
From: Thomas Rast @ 2013-02-18 19:45 UTC (permalink / raw)
To: Ramkumar Ramachandra
Cc: Jeff King, git, Shawn Pearce, Jakub Narebski, Christian Couder,
Pat Thoyts, Paul Mackerras, Carlos Martín Nieto,
Thomas Gummerer, David Barr, Jens Lehmann, Nguyen Thai Ngoc Duy
In-Reply-To: <CALkWK0nDEwgDwnVktmM8abv3ZgQmJCOm8LBe25UKR485PZMPfA@mail.gmail.com>
Ramkumar Ramachandra <artagnon@gmail.com> writes:
> [corrected David Barr's email address]
>
> Jeff King wrote:
>> And I do not want to blame the students here (some of whom are on the cc
>> list :) ). They are certainly under no obligation to stick around after
>> GSoC ends, and I know they have many demands on their time. But I am
>> also thinking about what Git wants to get out of GSoC (and to my mind,
>> the most important thing is contributors).
>>
>> As far as merged code, I think part of the problem is that git is fairly
>> mature at this point. The most interesting projects are of a bigger
>> scope than a student with no experience in the code base can do in a
>> summer project. Maybe that means we need to do a better job of breaking
>> projects down into reasonably sized sub-components. Or maybe it means
>> the project is hitting a point of diminishing returns for GSoC. I don't
>> know.
>
> I'll be frank here. I think the main reason for a student to stick
> around is to see more of his code hit `master`. I think it is
> absolutely essential to get students constantly post iteration after
> iteration on the list. It would be nice to get them connected with 2~3
> people in the community who will follow their progress and pitch in
> everytime they post an iteration. It might also make sense to stage
> their work in the main tree (a gsoc/ namespace?), so we can just
> checkout to their branch to demo what they've done.
I agree, but I think there's an additional component. Consider the 'log
-L' feature. It's fairly workable, and I merge it in my own builds and
use it, but there were and are two main issues:
* The initial work by Bo was not in shape to be included, mostly because
the code was too convoluted in the parts that process line ranges.
* The last version I posted was held up because there's _in principle_ a
better way to do things, but it requires major refactorings of
existing code.
I'm not going to try to discuss away the first one; it's also a failure
of myself as mentor. However, as far as incomplete work goes, I think
the latter item is fairly symptomatic. We underestimate the amount of
work required to polish and reroll a submission that a student would
deem "sufficiently working for inclusion", fixes to be done later.
So I agree with your suggestion:
> What's the harm of including something estimated to take 80% of a
> summer?
Maybe even less than 80%.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: Google Summer of Code 2013 (GSoC13)
From: Ramkumar Ramachandra @ 2013-02-18 19:45 UTC (permalink / raw)
To: Jeff King
Cc: Thomas Rast, git, Shawn Pearce, Jakub Narebski, Christian Couder,
Pat Thoyts, Paul Mackerras, Carlos Martín Nieto,
Thomas Gummerer, David Barr, Jens Lehmann, Nguyen Thai Ngoc Duy
In-Reply-To: <20130218185801.GA25673@sigill.intra.peff.net>
Jeff King wrote:
> On Tue, Feb 19, 2013 at 12:14:19AM +0530, Ramkumar Ramachandra wrote:
>
>> I'll be frank here. I think the main reason for a student to stick
>> around is to see more of his code hit `master`. I think it is
>> absolutely essential to get students constantly post iteration after
>> iteration on the list. It would be nice to get them connected with 2~3
>> people in the community who will follow their progress and pitch in
>> everytime they post an iteration. It might also make sense to stage
>> their work in the main tree (a gsoc/ namespace?), so we can just
>> checkout to their branch to demo what they've done.
>
> I agree. One of the main problems with GSoC projects is that the student
> goes away and works for a while, and then at the end does not
> necessarily have something mergeable. That is not how regular
> contributors work. They post works in progress, get feedback, and
> iterate on ideas. They break work into easily digestable and reviewable
> chunks.
> So maybe the mentors should be focusing more on that than on
> actual code problems.
Take what I'm about to say with a pinch of salt, because I've never mentored.
Mentors often don't provide much technical assistance: students should
just post to the list with queries, or ask on #git-devel. Mentors
serve a different purpose; their primary responsibility, in my
opinion, is to teach the student a sustainable productive workflow.
This means: profiling them to figure out where they're losing out. Do
they have the habit of:
- posting to the list regularly?
- CC'ing the right people?
- iterating quickly after reviews?
- using gdb efficiently to quickly understand parts?
- using git efficiently for the rebase/ patch workflow?
>> Also, we need more projects that will scratch everyday itches. A
>> collection of related tiny features might not be a bad idea. Often,
>> we risk erring on the side of too-big-for-one-summer when it comes to
>> specifying projects. What's the harm of including something estimated
>> to take 80% of a summer?
>
> I very much agree with you here. One problem is that those smaller
> projects often do not sound as grand or as interesting, and so students
> do not propose them. We have to work with the applicants we get.
We have to post well-crafted proposals like this to pique their interest.
>> On a related note, I don't like our Wiki. It's down half the time,
>> and it's very badly maintained. I want to write content for our Wiki
>> from the comfort of my editor, with version control aiding me. And I
>> can't stand archaic WikiText.
>
> Agreed on all of those points. Putting the Wiki on GitHub fixes that.
> But it means contributors need to have a GitHub account. On the other
> hand, I think kernel.org wiki contributors need an account these days?
> And GitHub is putting some active effort into finding and killing spammy
> accounts, which might keep wiki spam down (I do not pay too much
> attention to those efforts, but on kernel.org, it is mostly up to the
> Git community to do it ourselves).
No, I'm against using the GitHub Wiki for neutrality reasons. There
is one easy way to fight spam: don't expose a web-based editing
interface at all. It's mainly going to be maintained by the
community, and we're all much more comfortable in our editors and git.
We can give the regulars direct commit access and ask the rest to
submit pull requests. Make it cost pennies, so any of us can easily
afford it: just a cheap domain, DNS, and static HTML hosting.
^ permalink raw reply
* Re: [PATCH 13/13] contrib/subtree: Remove --annotate
From: James Nylen @ 2013-02-18 19:46 UTC (permalink / raw)
To: greened; +Cc: Junio C Hamano, git
In-Reply-To: <87sj4t4gar.fsf@waller.obbligato.org>
On Mon, Feb 18, 2013 at 1:39 PM, <greened@obbligato.org> wrote:
> James Nylen <jnylen@gmail.com> writes:
>> - add "fancylib" as a subtree of "myprog"
>> - commit to "myprog" repo: "fancylib: don't crash as much"
>> - split these commits back out to "fancylib" main repo, and remove
>> the "fancylib: " prefix
> Should this really be a function of git-subtree? It seems like it would
> fit better in a history-rewriting command. Wouldn't rebase -i or even
> filter-branch be a better way to do this?
I'm not a git guru by any stretch, so I'm sure there are other ways to
accommodate the example use case above. I really just want to be able
to split and merge repositories while keeping meaningful commit
messages with an appropriate level of detail. Can you suggest an
alternative workflow?
> If there's no --annotate I don't see why git-subtree should have the
> --unannotate functionality.
Because they are not inverse operations - they both apply to `git
subtree split`. I think that `--annotate` would only be useful as an
option to `git subtree merge`. In that case it would be the inverse
operation of `git subtree split --unannotate`, and then I would agree
that if you remove one, you can/should remove the other.
> Again, I agree that your example is relevant, maybe even common, but I
> don't necessarily think git-subtree should be in the business of
> rewriting commit messages at all.
I'm willing to accept that. Junio seemed to be leaning that way too
in earlier emails.
> I'd appreciate more thoughts from you on this. I want to make sure we
> can support your use case.
I currently need to enable `git subtree` manually anyway, since it's
not part of the main distribution. So it's not a burden for me to
support this feature with a customized script, or learn a new way to
do it.
Thanks for your consideration of this small and nit-picky issue.
^ 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