* Re: [PATCH v3 09/11] t4014: more tests about appending s-o-b lines
From: Junio C Hamano @ 2013-01-28 5:51 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Brandon Casey, git, pclouds, Brandon Casey
In-Reply-To: <7vboc9zwv1.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
>> Is "grep -n" portable? I didn't find any uses of it elsewhere in the
>> testsuite.
>
> Yes, "-n" is in POSIX. Even though we use it ourselves, "git grep"
> supports it, too.
Ehh even though we *DONT* use it ourselves, ... that is.
I do not think we mind, if its use helps our test.
^ permalink raw reply
* Re: [PATCH 6/7] read-cache: refuse to create index referring to external objects
From: Junio C Hamano @ 2013-01-28 5:54 UTC (permalink / raw)
To: Duy Nguyen; +Cc: git, Jens Lehmann
In-Reply-To: <CACsJy8BJZgyEn1n2GWgAVSGhSkVUO-P=GXwR02OcDf0ziTTRaA@mail.gmail.com>
Duy Nguyen <pclouds@gmail.com> writes:
> On Sat, Jan 26, 2013 at 2:00 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> This is not a tangent, but if you want to go this "forbid making our
>> repository depend on objects we do not have but we know about after
>> we peek submodule odb" route [*1*], write_sha1_file() needs to be
>> told about has_sha1_file_proper(). We may "git add" a new blob in
>> the superproject, the blob may not yet exist in *our* repository,
>> but may happen to already exist in the submodue odb. In such a
>> case, write_sha1_file() has to write that blob in our repository,
>> without the existing has_sha1_file() check bypassing it. Otherwise
>> our attempt to create a tree that contains that blob will fail,
>> saying that the blob only seems to exist to us via submodule odb but
>> not in our repository.
>
> Another thing needs to be done for this to work. The current reading
For *what* to work??? I think the performance consideration is the
only thing that should drive the read-order; correctness should not
be affected.
> order is packs first, loose objects next. If we create a local loose
> duplicate of an alternate packed object, our local version will never
> be read. Regardless the submodule odb issue, I think we should prefer
> reading local loose objects over alternate packed ones.
^ permalink raw reply
* Re: [PATCH 6/7] read-cache: refuse to create index referring to external objects
From: Duy Nguyen @ 2013-01-28 5:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jens Lehmann
In-Reply-To: <7vy5fdyhs0.fsf@alter.siamese.dyndns.org>
On Mon, Jan 28, 2013 at 12:54 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Duy Nguyen <pclouds@gmail.com> writes:
>
>> On Sat, Jan 26, 2013 at 2:00 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>> This is not a tangent, but if you want to go this "forbid making our
>>> repository depend on objects we do not have but we know about after
>>> we peek submodule odb" route [*1*], write_sha1_file() needs to be
>>> told about has_sha1_file_proper(). We may "git add" a new blob in
>>> the superproject, the blob may not yet exist in *our* repository,
>>> but may happen to already exist in the submodue odb. In such a
>>> case, write_sha1_file() has to write that blob in our repository,
>>> without the existing has_sha1_file() check bypassing it. Otherwise
>>> our attempt to create a tree that contains that blob will fail,
>>> saying that the blob only seems to exist to us via submodule odb but
>>> not in our repository.
>>
>> Another thing needs to be done for this to work. The current reading
>
> For *what* to work???
The "forbid making our repository depend on objects we do not have but
we know about afterwe peek submodule odb"
> I think the performance consideration is the
> only thing that should drive the read-order; correctness should not
> be affected.
>
>> order is packs first, loose objects next. If we create a local loose
>> duplicate of an alternate packed object, our local version will never
>> be read. Regardless the submodule odb issue, I think we should prefer
>> reading local loose objects over alternate packed ones.
--
Duy
^ permalink raw reply
* Re: [PATCH 6/7] read-cache: refuse to create index referring to external objects
From: Junio C Hamano @ 2013-01-28 6:06 UTC (permalink / raw)
To: Duy Nguyen; +Cc: git, Jens Lehmann
In-Reply-To: <CACsJy8CXC=poDBenBwo6t8=Qv-_zvGbvHYo-cDdGA8_fpw4Cyg@mail.gmail.com>
Duy Nguyen <pclouds@gmail.com> writes:
>>> Another thing needs to be done for this to work. The current reading
>>
>> For *what* to work???
>
> The "forbid making our repository depend on objects we do not have but
> we know about afterwe peek submodule odb"
With your "when our object database is contaminated, check objects
we base our new object on are available in local or our alternates"
together with the "when we try write_object(), do not bypass it with
has_sha1_file() check because that may find the object in submodule odb
we should *not* have access to; instead check with the same 'local
or our alternates' test" I brought up in the message you were
responding to, I do not think object read order does not make a
difference to our effort to prevent the object database breakage due
to temporary contamination by submodule objects.
>>> Regardless the submodule odb issue, I think we should prefer
>>> reading local loose objects over alternate packed ones.
I suspect you are alluding to make write_object() check with
has_sha1_file_locally() so that we can wean our repository from
existing alternates, but I do not think it is a right approach
(instead, you just fully repack locally if you want to dissociate
yourself from your alternates). What I was suggesting was to change
it to check with has_sha1_file_proper(), to make sure we do not omit
writing an object we need to access to, when we know it will vanish
once we stop temporarily borrowing from the submodule object store.
^ permalink raw reply
* [PATCH] l10n: de.po: translate 11 new messages
From: Ralf Thielow @ 2013-01-28 6:14 UTC (permalink / raw)
To: trast, jk, stimming; +Cc: git, Ralf Thielow
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"
"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 6/7] read-cache: refuse to create index referring to external objects
From: Duy Nguyen @ 2013-01-28 6:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jens Lehmann
In-Reply-To: <CACsJy8BJZgyEn1n2GWgAVSGhSkVUO-P=GXwR02OcDf0ziTTRaA@mail.gmail.com>
On Mon, Jan 28, 2013 at 12:48 PM, Duy Nguyen <pclouds@gmail.com> wrote:
> Regardless the submodule odb issue, I think we should prefer
> reading local loose objects over alternate packed ones.
I think I went from one problem to another and did not make it clear.
The reason behind this preference is security. With "all packs first"
reading order, someone can create a pack in the alternate source and
that pack will override the same local loose objects (local packed
ones are safe). If someone can create a malicious version with the
same SHA-1, we (well, the user) are in trouble. If the user uses this
repository directly then the malicious object can be used without
detected, even if it does not match the original SHA-1, as we do not
always verify content against its SHA-1 for common commands.
--
Duy
^ permalink raw reply
* Re: [PATCH 6/7] read-cache: refuse to create index referring to external objects
From: Junio C Hamano @ 2013-01-28 6:36 UTC (permalink / raw)
To: Duy Nguyen; +Cc: git, Jens Lehmann
In-Reply-To: <CACsJy8BwCCAZyMZ2w9fyMaNJsHRNp2V3Aen8g3drAkZ4y9mfBg@mail.gmail.com>
Duy Nguyen <pclouds@gmail.com> writes:
> On Mon, Jan 28, 2013 at 12:48 PM, Duy Nguyen <pclouds@gmail.com> wrote:
>> Regardless the submodule odb issue, I think we should prefer
>> reading local loose objects over alternate packed ones.
>
> I think I went from one problem to another and did not make it clear.
> The reason behind this preference is security.
Reading from ours first would not help you at all if you are lacking
some that you do need from your local repository and the only
solution is not to borrow from untrustworthy sources, I think.
You borrow only from a trusted source in the first place, no?
^ permalink raw reply
* What's cooking in git.git (Jan 2013, #10; Sun, 27)
From: Junio C Hamano @ 2013-01-28 6:45 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
As usual, this cycle is expected to last for 8 to 10 weeks, with a
preview -rc0 sometime in the middle of next month.
You can find the changes described here in the integration branches of the
repositories listed at
http://git-blame.blogspot.com/p/git-public-repositories.html
--------------------------------------------------
[New Topics]
* bc/git-p4-for-python-2.4 (2013-01-26) 2 commits
- git-p4.py: support Python 2.4
- git-p4.py: support Python 2.5
With small updates to remove dependency on newer features of
Python, keep git-p4 usable with older Python.
Will merge to 'next'.
* jk/gc-auto-after-fetch (2013-01-26) 1 commit
- Merge branch 'jk/maint-gc-auto-after-fetch' into jk/gc-auto-after-fetch
(this branch uses jk/maint-gc-auto-after-fetch.)
This is to resolve merge conflicts early for the same topic to
recent codebase.
Will merge to 'next'.
* jk/maint-gc-auto-after-fetch (2013-01-26) 2 commits
- fetch-pack: avoid repeatedly re-scanning pack directory
- fetch: run gc --auto after fetching
(this branch is used by jk/gc-auto-after-fetch.)
Help "fetch only" repositories that does not trigger "gc --auto"
often enough.
Will merge to 'next' via jk/gc-auto-after-fetch.
* jk/read-commit-buffer-data-after-free (2013-01-26) 3 commits
- logmsg_reencode: lazily load missing commit buffers
- logmsg_reencode: never return NULL
- commit: drop useless xstrdup of commit message
Clarify the ownership rule for commit->buffer field, which some
callers incorrectly accessed without making sure the data is
available there.
Will merge to 'next'.
* pw/git-p4-on-cygwin (2013-01-26) 21 commits
- git p4: introduce gitConfigBool
- git p4: avoid shell when calling git config
- git p4: avoid shell when invoking git config --get-all
- git p4: avoid shell when invoking git rev-list
- git p4: avoid shell when mapping users
- git p4: disable read-only attribute before deleting
- git p4 test: use test_chmod for cygwin
- git p4: cygwin p4 client does not mark read-only
- git p4 test: avoid wildcard * in windows
- git p4 test: use LineEnd unix in windows tests too
- git p4 test: newline handling
- git p4: scrub crlf for utf16 files on windows
- git p4: remove unreachable windows \r\n conversion code
- git p4 test: translate windows paths for cygwin
- git p4 test: start p4d inside its db dir
- git p4 test: use client_view in t9806
- git p4 test: avoid loop in client_view
- git p4 test: use client_view to build the initial client
- git p4: generate better error message for bad depot path
- git p4: remove unused imports
- git p4: temp branch name should use / even on windows
Improve "git p4" on Cygwin. The cover letter said it is not yet
ready for full Windows support so I won't move this to 'next' until
told by the author (the area maintainer) otherwise.
* ss/mergetools-tortoise (2013-01-26) 2 commits
- mergetools: allow passing pathnames with SP in them to TortoiseGitMerge
- mergetools: support TortoiseGitMerge
Update mergetools to work better with newer merge helper tortoise ships.
Will merge to 'next'.
* da/mergetool-docs (2013-01-27) 4 commits
- doc: generate a list of valid merge tools
- mergetool--lib: add functions for finding available tools
- mergetool--lib: improve the help text in guess_merge_tool()
- mergetool--lib: simplify command expressions
(this branch uses jk/mergetool.)
Build on top of the clean-up done by jk/mergetool and automatically
generate the list of mergetool and difftool backends the build
supports to be included in the documentation.
This may still need to be fixed up at minor details; I'd like to
see a review from John Keeping on these.
* nd/branch-error-cases (2013-01-27) 4 commits
- branch: mark more strings for translation
- branch: give a more helpful message on redundant arguments
- branch: reject -D/-d without branch name
- branch: no detached HEAD check when editing another branch's description
Fix various error messages and conditions in "git branch", e.g. we
advertised "branch -d/-D" to remove one or more branches but actually
implemented removal of zero or more branches---request to remove no
branches was not rejected.
Will merge to 'next', perhaps after rebasing on an older base
so that this can later be merged to the maintenance track.
--------------------------------------------------
[Stalled]
* mp/complete-paths (2013-01-11) 1 commit
- git-completion.bash: add support for path completion
The completion script used to let the default completer to suggest
pathnames, which gave too many irrelevant choices (e.g. "git add"
would not want to add an unmodified path). Teach it to use a more
git-aware logic to enumerate only relevant ones.
Waiting for area-experts' help and review.
* jl/submodule-deinit (2012-12-04) 1 commit
- submodule: add 'deinit' command
There was no Porcelain way to say "I no longer am interested in
this submodule", once you express your interest in a submodule with
"submodule init". "submodule deinit" is the way to do so.
Expecting a reroll.
$gmane/212884
* jk/lua-hackery (2012-10-07) 6 commits
- pretty: fix up one-off format_commit_message calls
- Minimum compilation fixup
- Makefile: make "lua" a bit more configurable
- add a "lua" pretty format
- add basic lua infrastructure
- pretty: make some commit-parsing helpers more public
Interesting exercise. When we do this for real, we probably would want
to wrap a commit to make it more like an "object" with methods like
"parents", etc.
* rc/maint-complete-git-p4 (2012-09-24) 1 commit
- Teach git-completion about git p4
Comment from Pete will need to be addressed ($gmane/206172).
* jc/maint-name-rev (2012-09-17) 7 commits
- describe --contains: use "name-rev --algorithm=weight"
- name-rev --algorithm=weight: tests and documentation
- name-rev --algorithm=weight: cache the computed weight in notes
- name-rev --algorithm=weight: trivial optimization
- name-rev: --algorithm option
- name_rev: clarify the logic to assign a new tip-name to a commit
- name-rev: lose unnecessary typedef
"git name-rev" names the given revision based on a ref that can be
reached in the smallest number of steps from the rev, but that is
not useful when the caller wants to know which tag is the oldest one
that contains the rev. This teaches a new mode to the command that
uses the oldest ref among those which contain the rev.
I am not sure if this is worth it; for one thing, even with the help
from notes-cache, it seems to make the "describe --contains" even
slower. Also the command will be unusably slow for a user who does
not have a write access (hence unable to create or update the
notes-cache).
Stalled mostly due to lack of responses.
* jc/xprm-generation (2012-09-14) 1 commit
- test-generation: compute generation numbers and clock skews
A toy to analyze how bad the clock skews are in histories of real
world projects.
Stalled mostly due to lack of responses.
* jc/add-delete-default (2012-08-13) 1 commit
- git add: notice removal of tracked paths by default
"git add dir/" updated modified files and added new files, but does
not notice removed files, which may be "Huh?" to some users. They
can of course use "git add -A dir/", but why should they?
Resurrected from graveyard, as I thought it was a worthwhile thing
to do in the longer term.
Stalled mostly due to lack of responses.
* mb/remote-default-nn-origin (2012-07-11) 6 commits
- Teach get_default_remote to respect remote.default.
- Test that plain "git fetch" uses remote.default when on a detached HEAD.
- Teach clone to set remote.default.
- Teach "git remote" about remote.default.
- Teach remote.c about the remote.default configuration setting.
- Rename remote.c's default_remote_name static variables.
When the user does not specify what remote to interact with, we
often attempt to use 'origin'. This can now be customized via a
configuration variable.
Expecting a reroll.
$gmane/210151
"The first remote becomes the default" bit is better done as a
separate step.
* nd/parse-pathspec (2013-01-11) 20 commits
. Convert more init_pathspec() to parse_pathspec()
. Convert add_files_to_cache to take struct pathspec
. Convert {read,fill}_directory to take struct pathspec
. Convert refresh_index to take struct pathspec
. Convert report_path_error to take struct pathspec
. checkout: convert read_tree_some to take struct pathspec
. Convert unmerge_cache to take struct pathspec
. Convert read_cache_preload() to take struct pathspec
. add: convert to use parse_pathspec
. archive: convert to use parse_pathspec
. ls-files: convert to use parse_pathspec
. rm: convert to use parse_pathspec
. checkout: convert to use parse_pathspec
. rerere: convert to use parse_pathspec
. status: convert to use parse_pathspec
. commit: convert to use parse_pathspec
. clean: convert to use parse_pathspec
. Export parse_pathspec() and convert some get_pathspec() calls
. Add parse_pathspec() that converts cmdline args to struct pathspec
. pathspec: save the non-wildcard length part
Uses the parsed pathspec structure in more places where we used to
use the raw "array of strings" pathspec.
Ejected from 'pu' for now; will take a look at the rerolled one
later ($gmane/213340).
--------------------------------------------------
[Cooking]
* jc/push-reject-reasons (2013-01-24) 4 commits
- push: finishing touches to explain REJECT_ALREADY_EXISTS better
- push: introduce REJECT_FETCH_FIRST and REJECT_NEEDS_FORCE
- push: further simplify the logic to assign rejection reason
- push: further clean up fields of "struct ref"
Improve error and advice messages given locally when "git push"
refuses when it cannot compute fast-forwardness by separating these
cases from the normal "not a fast-forward; merge first and push
again" case.
Will merge to 'next'.
* as/test-cleanup (2013-01-24) 1 commit
- t7102 (reset): don't hardcode SHA-1 in expected outputs
Will merge to 'next'.
* jc/do-not-let-random-file-interfere-with-completion-tests (2013-01-24) 1 commit
- t9902: protect test from stray build artifacts
Scripts to test bash completion was inherently flaky as it was
affected by whatever random things the user may have on $PATH.
Will merge to 'next'.
* jk/cvsimport-does-not-work-with-cvsps3 (2013-01-24) 1 commit
- git-cvsimport.txt: cvsps-2 is deprecated
Warn people that other tools are more recommendable over
cvsimport+cvsps2 combo when doing a one-shot import, and cvsimport
will not work with cvsps3.
Will merge to 'next'.
* jk/mergetool (2013-01-27) 8 commits
- mergetools: simplify how we handle "vim" and "defaults"
- mergetool--lib: don't call "exit" in setup_tool
- mergetool--lib: improve show_tool_help() output
- mergetools/vim: remove redundant diff command
- git-difftool: use git-mergetool--lib for "--tool-help"
- git-mergetool: don't hardcode 'mergetool' in show_tool_help
- git-mergetool: remove redundant assignment
- git-mergetool: move show_tool_help to mergetool--lib
(this branch is used by da/mergetool-docs.)
Cleans up mergetool/difftool combo.
Will merge to 'next'.
* jn/do-not-drop-username-when-reading-from-etc-mailname (2013-01-25) 1 commit
- ident: do not drop username when reading from /etc/mailname
We used to stuff "user@" and then append what we read from
/etc/mailname to come up with a default e-mail ident, but a bug
lost the "user@" part. This is to fix it.
Will merge to 'next'.
* mm/add-u-A-sans-pathspec (2013-01-25) 1 commit
- add: warn when -u or -A is used without pathspec
Forbid "git add -u" and "git add -A" without pathspec run from a
subdirectory, to train people to type "." (or ":/") to make the
choice of default does not matter.
Will merge to 'next'.
* bc/fix-array-syntax-for-3.0-in-completion-bash (2013-01-18) 1 commit
(merged to 'next' on 2013-01-25 at d113c1a)
+ git-completion.bash: replace zsh notation that breaks bash 3.X
Fix use of an array notation that older versions of bash do not
understand.
Will merge to 'master'.
* jc/help (2013-01-18) 1 commit
(merged to 'next' on 2013-01-25 at b2b087e)
+ help: include <common-cmds.h> only in one file
A header file that has the definition of a static array was
included in two places, wasting the space.
Will merge to 'master'.
* jc/hidden-refs (2013-01-18) 2 commits
- upload-pack: allow hiding ref hiearchies
- upload-pack: share more code
Allow the server side to unclutter the refs/ namespace it shows by
default, while still allowing requests for histories leading to the
tips of hidden refs by updated clients (which are not written yet).
* jk/update-install-for-p4 (2013-01-20) 1 commit
- INSTALL: git-p4 doesn't support Python 3
Will merge to 'next'.
* tb/t0050-maint (2013-01-21) 3 commits
(merged to 'next' on 2013-01-25 at 682b1e2)
+ t0050: Use TAB for indentation
+ t0050: honor CASE_INSENSITIVE_FS in add (with different case)
+ t0050: known breakage vanished in merge (case change)
Update tests that were expecting to fail due to a bug that was
fixed earlier.
Will merge to 'master'.
* nd/magic-pathspec-from-root (2013-01-21) 2 commits
(merged to 'next' on 2013-01-25 at b056b57)
+ grep: avoid accepting ambiguous revision
+ Update :/abc ambiguity check
When giving arguments without "--" disambiguation, object names
that come earlier on the command line must not be interpretable as
pathspecs and pathspecs that come later on the command line must
not be interpretable as object names. Tweak the disambiguation
rule so that ":/" (no other string before or after) is always
interpreted as a pathspec, to avoid having to say "git cmd -- :/".
Will merge to 'master'.
* ta/doc-no-small-caps (2013-01-22) 10 commits
- fixup! Change 'git' to 'Git' whenever the whole system is referred to #4
- Change 'git' to 'Git' whenever the whole system is referred to #4
- fixup! Change 'git' to 'Git' whenever the whole system is referred to #3
- Change 'git' to 'Git' whenever the whole system is referred to #3
- fixup! Change 'git' to 'Git' whenever the whole system is referred to #2
- Change 'git' to 'Git' whenever the whole system is referred to #2
- fixup! fixup! Change 'git' to 'Git' whenever the whole system is referred to #1
- fixup! Change 'git' to 'Git' whenever the whole system is referred to #1
- Change 'git' to 'Git' whenever the whole system is referred to #1
- Documentation: avoid poor-man's small caps
Update documentation to change "GIT" which was a poor-man's small
caps to "Git" which was the intended spelling. Also change "git"
spelled in all-lowercase to "Git" when it refers to the system as
the whole or the concept it embodies, as opposed to the command the
end users would type.
Will wait for a week or so (say, til end of January) for Thomas to
collect fix-ups, squash the result into two patches and then merge
to 'next'.
* rr/minimal-stat (2013-01-22) 1 commit
(merged to 'next' on 2013-01-25 at 11c4453)
+ Enable minimal stat checking
Some reimplementations of Git does not write all the stat info back
to the index due to their implementation limitations (e.g. jgit
running on Java). A configuration option can tell Git to ignore
changes to most of the stat fields and only pay attention to mtime
and size, which these implementations can reliably update. This
avoids excessive revalidation of contents.
Will merge to 'master'.
* jc/remove-treesame-parent-in-simplify-merges (2013-01-17) 1 commit
- simplify-merges: drop merge from irrelevant side branch
The --simplify-merges logic did not cull irrelevant parents from a
merge that is otherwise not interesting with respect to the paths
we are following.
As this touches a fairly core part of the revision traversal
infrastructure, it is appreciated to have an extra set of eyes for
sanity check.
Will merge to 'next'.
* jk/remote-helpers-in-python-3 (2013-01-27) 9 commits
- git-remote-testpy: fix path hashing on Python 3
(merged to 'next' on 2013-01-25 at acf9419)
+ git-remote-testpy: call print as a function
+ git-remote-testpy: don't do unbuffered text I/O
+ git-remote-testpy: hash bytes explicitly
+ svn-fe: allow svnrdump_sim.py to run with Python 3
+ git_remote_helpers: use 2to3 if building with Python 3
+ git_remote_helpers: force rebuild if python version changes
+ git_remote_helpers: fix input when running under Python 3
+ git_remote_helpers: allow building with Python 3
Prepare remote-helper test written in Python to be run with Python3.
Waiting for the final review and Ack, perhaps from Michael.
* dl/am-hg-locale (2013-01-18) 1 commit
(merged to 'next' on 2013-01-25 at 3419019)
+ am: invoke perl's strftime in C locale
Datestamp recorded in "Hg" format patch was reformatted incorrectly
to an e-mail looking date using locale dependant strftime, causing
patch application to fail.
Will merge to 'master'.
* jk/config-parsing-cleanup (2013-01-23) 8 commits
- reflog: use parse_config_key in config callback
- help: use parse_config_key for man config
- submodule: simplify memory handling in config parsing
- submodule: use parse_config_key when parsing config
- userdiff: drop parse_driver function
- convert some config callbacks to parse_config_key
- archive-tar: use parse_config_key when parsing config
- config: add helper function for parsing key names
Configuration parsing for tar.* configuration variables were
broken. Introduce a new config-keyname parser API to make the
callers much less error prone.
Will merge to 'next'.
* mp/diff-algo-config (2013-01-16) 3 commits
- diff: Introduce --diff-algorithm command line option
- config: Introduce diff.algorithm variable
- git-completion.bash: Autocomplete --minimal and --histogram for git-diff
Add diff.algorithm configuration so that the user does not type
"diff --histogram".
Looking better; may want tests to protect it from future breakages,
but otherwise it looks ready for 'next'.
Expecting a follow-up to add tests.
* jc/custom-comment-char (2013-01-16) 1 commit
(merged to 'next' on 2013-01-25 at 91d8a5d)
+ Allow custom "comment char"
An illustration to show codepaths that need to be touched to change
the hint lines in the edited text to begin with something other
than '#'.
This is half my work and half by Ralf Thielow. There may still be
leftover '#' lurking around, though. My "git grep" says C code
should be already fine, but git-rebase--interactive.sh could be
converted (it should not matter, as the file is not really a
free-form text).
I don't know how useful this will be in real life, though.
* nd/fetch-depth-is-broken (2013-01-11) 3 commits
(merged to 'next' on 2013-01-15 at 70a5ca7)
+ fetch: elaborate --depth action
+ upload-pack: fix off-by-one depth calculation in shallow clone
+ fetch: add --unshallow for turning shallow repo into complete one
"git fetch --depth" was broken in at least three ways. The
resulting history was deeper than specified by one commit, it was
unclear how to wipe the shallowness of the repository with the
command, and documentation was misleading.
Will cook in 'next'.
* jc/no-git-config-in-clone (2013-01-11) 1 commit
(merged to 'next' on 2013-01-15 at feeffe1)
+ clone: do not export and unexport GIT_CONFIG
We stopped paying attention to $GIT_CONFIG environment that points
at a single configuration file from any command other than "git config"
quite a while ago, but "git clone" internally set, exported, and
then unexported the variable during its operation unnecessarily.
Will cook in 'next'.
* dg/subtree-fixes (2013-01-08) 7 commits
- contrib/subtree: mkdir the manual directory if needed
- contrib/subtree: honor $(DESTDIR)
- contrib/subtree: fix synopsis and command help
- contrib/subtree: better error handling for "add"
- contrib/subtree: add --unannotate option
- contrib/subtree: use %B for split Subject/Body
- t7900: remove test number comments
contrib/subtree updates; there are a few more from T. Zheng that
were posted separately, with an overlap.
Expecting a reroll.
* jc/push-2.0-default-to-simple (2013-01-16) 14 commits
(merged to 'next' on 2013-01-16 at 23f5df2)
+ t5570: do not assume the "matching" push is the default
+ t5551: do not assume the "matching" push is the default
+ t5550: do not assume the "matching" push is the default
(merged to 'next' on 2013-01-09 at 74c3498)
+ doc: push.default is no longer "matching"
+ push: switch default from "matching" to "simple"
+ t9401: do not assume the "matching" push is the default
+ t9400: do not assume the "matching" push is the default
+ t7406: do not assume the "matching" push is the default
+ t5531: do not assume the "matching" push is the default
+ t5519: do not assume the "matching" push is the default
+ t5517: do not assume the "matching" push is the default
+ t5516: do not assume the "matching" push is the default
+ t5505: do not assume the "matching" push is the default
+ t5404: do not assume the "matching" push is the default
Will cook in 'next' until Git 2.0 ;-).
* mb/gitweb-highlight-link-target (2012-12-20) 1 commit
- Highlight the link target line in Gitweb using CSS
Expecting a reroll.
$gmane/211935
* bc/append-signed-off-by (2013-01-27) 11 commits
- Unify appending signoff in format-patch, commit and sequencer
- format-patch: update append_signoff prototype
- t4014: more tests about appending s-o-b lines
- sequencer.c: teach append_signoff to avoid adding a duplicate newline
- sequencer.c: teach append_signoff how to detect duplicate s-o-b
- sequencer.c: always separate "(cherry picked from" from commit body
- sequencer.c: recognize "(cherry picked from ..." as part of s-o-b footer
- t/t3511: add some tests of 'cherry-pick -s' functionality
- t/test-lib-functions.sh: allow to specify the tag name to test_commit
- commit, cherry-pick -s: remove broken support for multiline rfc2822 fields
- sequencer.c: rework search for start of footer to improve clarity
Rerolled. With help from Jonathan, I think this is getting closer.
^ permalink raw reply
* Re: [PATCH 6/7] read-cache: refuse to create index referring to external objects
From: Duy Nguyen @ 2013-01-28 6:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jens Lehmann
In-Reply-To: <7vpq0pyfsq.fsf@alter.siamese.dyndns.org>
On Mon, Jan 28, 2013 at 1:36 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Duy Nguyen <pclouds@gmail.com> writes:
>
>> On Mon, Jan 28, 2013 at 12:48 PM, Duy Nguyen <pclouds@gmail.com> wrote:
>>> Regardless the submodule odb issue, I think we should prefer
>>> reading local loose objects over alternate packed ones.
>>
>> I think I went from one problem to another and did not make it clear.
>> The reason behind this preference is security.
>
> Reading from ours first would not help you at all if you are lacking
> some that you do need from your local repository and the only
> solution is not to borrow from untrustworthy sources, I think.
>
> You borrow only from a trusted source in the first place, no?
Hmm.. yeah.
--
Duy
^ permalink raw reply
* Re: [PATCH v4 1/2] for-each-repo: new command used for multi-repo operations
From: Lars Hjemli @ 2013-01-28 7:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk3qywiqf.fsf@alter.siamese.dyndns.org>
On Sun, Jan 27, 2013 at 8:04 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Lars Hjemli <hjemli@gmail.com> writes:
>
>> The command also honours the option '--clean' which restricts the set of
>> repos to those which '--dirty' would skip, and '-x' which is used to
>> execute non-git commands.
>
> It might make sense to internally use RUN_GIT_CMD flag when the
> first word of the command line is 'git' as an optimization, but
> I am not sure it is a good idea to force the end users to think
> when to use -x and when not to is a good idea.
>
> In other words, I think
>
> git for-each-repo -d diff --name-only
> git for-each-repo -d -x ls '*.c'
>
> is less nice than letting the user say
>
> git for-each-repo -d git diff --name-only
> git for-each-repo -d ls '*.c'
>
The 'git-for-each-repo' command was made to allow any git command to
be executed in all discovered repositories, and I've used it that way
for two years (in the form of a shell-script called 'git-all'). During
this time, I've occasionally thought about forking non-git commands
but the itch hasn't been strong enough for me to scratch. The point
I'm trying to make is that to me, this command acts as a modifier for
other git commands[1]. Having the possibility to execute non-git
commands would be nice, but it is not the main objective of this
command.
[1] The 'git -a' rewrite patch shows how I think about this command -
it's just an option to the 'git' command, modifying the way any
subcommand is invoked (btw: I don't expect that patch to be applied
since 'git-all' was deemed to generic, so I'll just carry the patch in
my own tree).
>> Finally, the command to execute within each repo is optional. If none is
>> given, git-for-each-repo will just print the path to each repo found. And
>> since the command supports -z, this can be used for more advanced scripting
>> needs.
>
> It amounts to the same thing, but I would rather describe it as:
>
> To allow scripts to handle paths with shell-unsafe characters,
> support "-z" to show paths with NUL termination. Otherwise,
> such paths are shown with the usual c-quoting.
>
Much better, thanks.
> One more thing that nobody brought up during the previous reviews is
> if we want to support subset of repositories by allowing the
> standard pathspec match mechanism. For example,
>
> git for-each-repo -d git diff --name-only -- foo/ bar/b\*z
>
> might be a way to ask "please find repositories match the given
> pathspecs (i.e. foo/ bar/b\*z) and run the command in the ones that
> are dirty". We would need to think about how to mark the end of the
> command though---we could borrow \; from find(1), even though find
> is not the best example of the UI design. I.e.
>
> git for-each-repo -d git diff --name-only \; [--] foo/ bar/b\*z
>
> with or without "--".
I don't think this would be very nice to end users, and would prefer
--include and --exclude options (the latter is actually already a part
of git-all, added by one of my coworkers).
>> +NOTES
>> +-----
>> +
>> +For the purpose of `git-for-each-repo`, a dirty worktree is defined as a
>> +worktree with uncommitted changes.
>
> Is it a definition that is different from usual? If so why does it
> need to be inconsistent with the rest of the system?
I just wanted to clarify what condition --dirty and --clean will
check. In particular, the lack of checking for untracked files (which
could be added as yet another option).
>> +static void print_repo_path(const char *path, unsigned pretty)
>> +{
>> + if (path[0] == '.' && path[1] == '/')
>> + path += 2;
>> + if (pretty)
>> + color_fprintf_ln(stdout, color, "[%s]", path);
>
> This is shown before running a command in that repository. I am of
> two minds. It certainly is nice to be able to tell which repository
> each block of output lines comes from, and not requiring the command
> to do this themselves is a good default. However, I wonder if people
> would want to do something like this:
>
> git for-each-repo sh -c '
> git diff --name-only |
> sed -e "s|^|$path/|"
> '
>
> to get a consolidated view, in a way similar to how "submodule
> foreach" can be used. This unconditional output will get in the way
> for such a use case.
I guess -q/--quiet could be useful.
>> +static int walk(struct strbuf *path, int argc, const char **argv)
>> +{
>> + DIR *dir;
>> + struct dirent *ent;
>> + struct stat st;
>> + size_t len;
>> + int has_dotgit = 0;
>> + struct string_list list = STRING_LIST_INIT_DUP;
>> + struct string_list_item *item;
>> +
>> + dir = opendir(path->buf);
>> + if (!dir)
>> + return errno;
>> + strbuf_addstr(path, "/");
>> + len = path->len;
>> + while ((ent = readdir(dir))) {
>> + if (!strcmp(ent->d_name, ".") || !strcmp(ent->d_name, ".."))
>> + continue;
>> + if (!strcmp(ent->d_name, ".git")) {
>> + has_dotgit = 1;
>> + continue;
>> + }
>> + switch (DTYPE(ent)) {
>> + case DT_UNKNOWN:
>> + case DT_LNK:
>> + /* Use stat() to figure out if this path leads
>> + * to a directory - it's not important if it's
>> + * a symlink which gets us there.
>> + */
>> + strbuf_setlen(path, len);
>> + strbuf_addstr(path, ent->d_name);
>> + if (stat(path->buf, &st) || !S_ISDIR(st.st_mode))
>> + break;
>> + /* fallthrough */
>> + case DT_DIR:
>> + string_list_append(&list, ent->d_name);
>> + break;
>> + }
>> + }
>> + closedir(dir);
>> + strbuf_setlen(path, len);
>> + if (has_dotgit)
>> + handle_repo(path, argv);
>> + sort_string_list(&list);
>> + for_each_string_list_item(item, &list) {
>> + strbuf_setlen(path, len);
>> + strbuf_addstr(path, item->string);
>> + walk(path, argc, argv);
>> + }
>> + string_list_clear(&list, 0);
>> + return 0;
>> +}
>
> Is the "collect-first-and-then-sort" done so that the repositories
> are shown in a stable order regardless of the order in which
> readdir() returns he entries?
Yes (writing the testcases demonstrated a need for predictable output).
>> diff --git a/t/t6400-for-each-repo.sh b/t/t6400-for-each-repo.sh
>
> This command does not look like "6 - the revision tree commands" to
> me. "7 - the porcelainish commands concerning the working tree" or
> "9 - the git tools" may be a better match?
Ok, how about t9003?
>> new file mode 100755
>> index 0000000..af02c0c
>> --- /dev/null
>> +++ b/t/t6400-for-each-repo.sh
>> @@ -0,0 +1,150 @@
>> +#!/bin/sh
>> +#
>> +# Copyright (c) 2013 Lars Hjemli
>> +#
>> +
>> +test_description='Test the git-for-each-repo command'
>> +
>> +. ./test-lib.sh
>> +
>> +qname="with\"quote"
>> +qqname="\"with\\\"quote\""
>
> If Windows does not have problems with paths with dq in it, then
> this is fine, but I dunno. Otherwise, you may want to exclude the
> c-quote testing from the main part of the test, and have a single
> test that has prerequisite for filesystems that can do this at the
> end of the script.
I'll check my patch on msysgit before resending.
>> +test_expect_success "setup" '
>> + test_create_repo clean &&
>> + (cd clean && test_commit foo1) &&
>> + git init --separate-git-dir=.cleansub clean/gitfile &&
>> + (cd clean/gitfile && test_commit foo2 && echo bar >>foo2.t) &&
>> + test_create_repo dirty-idx &&
>> + (cd dirty-idx && test_commit foo3 && git rm foo3.t) &&
>> + test_create_repo dirty-wt &&
>> + (cd dirty-wt && mv .git .linkedgit && ln -s .linkedgit .git &&
>
> Some platforms are symlink-challenged. Can we do this test without
> "ln -s"? SYMLINKS prereq wouldn't be very useful for the setup
> step, as all the remaining tests won't work without setting up the
> test scenario.
I added this test to check the DT_UNKNOWN/DT_LINK case in walk() so
I'd rather not drop it, but it can be moved into a standalone,
SYMLINKS-enabled testcase.
Thanks for the review.
--
larsh
^ permalink raw reply
* Re: Port 22
From: Kevin @ 2013-01-28 8:06 UTC (permalink / raw)
To: Craig Christensen; +Cc: git
In-Reply-To: <55B0A474-AD5B-44B5-91E7-FA5253FA5682@gmail.com>
This is not really a git problem, but more of an ssh problem.
Are you in the position to change the port where the SSH daemon
listens on? Then you could use a different port which isn't blocked
(443 perhaps?).
On Sat, Jan 26, 2013 at 7:56 PM, Craig Christensen <cwcraigo@gmail.com> wrote:
> I am currently a student at Brigham Young University - Idaho and we are use Pagoda Box and Git for our Mobile Apps class. However, the school's network has blocked incoming trafic on port 22. I have been searching through all the tutorials and documents provided by Pagoda Box and Git but have not been able to find a solution to solve this problem. We can use sftp but we then have to manually deploy the latest using the admin panel. Can you help provide a simple solution?
>
> Thanks,
>
> Craig W Christensen
> cwcraigo@gmail.com
> chr07035@byui.edu--
> 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 v4 1/2] for-each-repo: new command used for multi-repo operations
From: Jonathan Nieder @ 2013-01-28 8:10 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Junio C Hamano, git
In-Reply-To: <CAFXTnz6GTVgY4DK-FLELGF-Cb1=iNYyWcUsUiaUytGRx9Tr4Ow@mail.gmail.com>
Hi,
Lars Hjemli wrote:
> [1] The 'git -a' rewrite patch shows how I think about this command -
> it's just an option to the 'git' command, modifying the way any
> subcommand is invoked (btw: I don't expect that patch to be applied
> since 'git-all' was deemed to generic, so I'll just carry the patch in
> my own tree).
As one data point, 'git all' also seems too generic to me but 'git -a'
doesn't. Intuition can be weird.
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. ;-)
[...]
>> One more thing that nobody brought up during the previous reviews is
>> if we want to support subset of repositories by allowing the
>> standard pathspec match mechanism. For example,
>>
>> git for-each-repo -d git diff --name-only -- foo/ bar/b\*z
>>
>> might be a way to ask "please find repositories match the given
>> pathspecs (i.e. foo/ bar/b\*z) and run the command in the ones that
>> are dirty". We would need to think about how to mark the end of the
>> command though---we could borrow \; from find(1), even though find
>> is not the best example of the UI design.
In most non-git commands, "--" represents an end-of-options marker,
allowing arbitrary options afterward without having to worry about
escaping minus signs. So in that spirit, if this weren't a git
command, I'd expect to be able to do
for-each-repo -- git diff -- '*.c'
and have the second '--' passed verbatim to "git diff".
Unfortunately in git (imitating commands like "grep", I suppose), "--"
means "paths start here". That means that with the git convention,
there is only one place to pass paths to a given command.
Tracing backwards: it would be really nice to be able to do
git for-each-repo git grep -e foo -- '*.c'
or
git -a grep -e foo -- '*.c'
For this practical reason, it seems that paths listed after the '--'
should go to the command being run. On the other hand, if I wanted to
limit my for-each-repo run to repositories in two subdirectories of
the cwd, I'd be tempted to try
git for-each-repo git grep -e foo -- src/ doc/
And if I wanted to limit to different file types in the repositories
under each directory, it would be tempting to use
git for-each-repo git grep -e foo -- 'src/*.c' 'doc/*.txt'
Is there a convention that would be usable today that is roughly
forward-compatible with that? (To throw an example out, requiring
that each pathspec passed to for-each-repo either starts with '*' or
contains no wildcards.)
Thanks,
Jonathan
^ permalink raw reply
* Re: [PATCH v2 0/4] Auto-generate mergetool lists
From: Philip Oakley @ 2013-01-28 8:20 UTC (permalink / raw)
To: David Aguilar, Junio C Hamano; +Cc: git, John Keeping
In-Reply-To: <1359334346-5879-1-git-send-email-davvid@gmail.com>
From: "David Aguilar" <davvid@gmail.com>
Sent: Monday, January 28, 2013 12:52 AM
> This is round two of this series.
> I think this touched on everything brought up in the code review.
> 4/4 could use a review as I'm not completely familiar with the
> makefile dependencies, though it seems to work correctly.
Does this 4/4 have any effect on the Msysgit / Git for Windows
documentation which simply refers [IIRC] to HTML documenation made by
Junio?
That is, how easy is it to create a 'default' set of docs, rather than
personalised documenation. Or have I misunderstood how it is working?
>
> David Aguilar (4):
> mergetool--lib: Simplify command expressions
> mergetool--lib: Improve the help text in guess_merge_tool()
> mergetool--lib: Add functions for finding available tools
> doc: Generate a list of valid merge tools
>
> Documentation/.gitignore | 1 +
> Documentation/Makefile | 22 +++++++-
> Documentation/diff-config.txt | 13 ++---
> Documentation/merge-config.txt | 12 ++---
> git-mergetool--lib.sh | 116
> ++++++++++++++++++++++-------------------
> 5 files changed, 96 insertions(+), 68 deletions(-)
>
> --
> 1.8.0.13.g3ff16bb
>
> --
> 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
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2013.0.2890 / Virus Database: 2639/6061 - Release Date:
> 01/27/13
>
^ permalink raw reply
* Re: [PATCH v2] add: warn when -u or -A is used without filepattern
From: Matthieu Moy @ 2013-01-28 8:48 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Jonathan Nieder, Robin Rosenberg, Piotr Krukowiecki,
Eric James Michael Ritz, Tomas Carnecky
In-Reply-To: <7vehh6v01v.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>
>> Plus, option_with_implicit_dot is used in cut-and-paste ready commands
>> below.
>
> I do not think we should aim for easy cut-and-paste, especially when
> the real purpose of the change is to train people's fingers; the
> message should discouraging cut-and-paste in a case like this, if
> anything.
cut-and-paste readyness is also a way to avoid being ambiguous. If you
tell users to run "git add -u (--update)", you'll always find someone to
type the command as-is and complain about it not working (sadly, the
teacher living inside me is speaking of experience ;-) ).
> But we could obviously do this, if you really want to cut-and-paste.
I was going to do something like this, you've been too quick ;-).
Resend comming soon.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH v2 0/4] Auto-generate mergetool lists
From: David Aguilar @ 2013-01-28 9:16 UTC (permalink / raw)
To: Philip Oakley; +Cc: Junio C Hamano, git, John Keeping
In-Reply-To: <5F78436DB1994B6DA686EC1BFA96B54E@PhilipOakley>
On Mon, Jan 28, 2013 at 12:20 AM, Philip Oakley <philipoakley@iee.org> wrote:
> From: "David Aguilar" <davvid@gmail.com>
> Sent: Monday, January 28, 2013 12:52 AM
>
>> This is round two of this series.
>> I think this touched on everything brought up in the code review.
>> 4/4 could use a review as I'm not completely familiar with the
>> makefile dependencies, though it seems to work correctly.
>
>
> Does this 4/4 have any effect on the Msysgit / Git for Windows documentation
> which simply refers [IIRC] to HTML documenation made by Junio?
>
> That is, how easy is it to create a 'default' set of docs, rather than
> personalised documenation. Or have I misunderstood how it is working?
It doesn't have any effect on Msysgit. The resulting documentation
lists all available tools, on all platforms.
--
David
^ permalink raw reply
* [PATCH v3] add: warn when -u or -A is used without filepattern
From: Matthieu Moy @ 2013-01-28 9:16 UTC (permalink / raw)
To: git, gitster
Cc: Jonathan Nieder, Robin Rosenberg, Piotr Krukowiecki,
Eric James Michael Ritz, Tomas Carnecky, Matthieu Moy
In-Reply-To: <vpqobg966cv.fsf@grenoble-inp.fr>
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'.
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.
Flipping the default now is unacceptable, so this patch starts training
users to type explicitely 'git add -u|-A :/' or 'git add -u|-A .', to prepare
for the next steps:
* forbid 'git add -u|-A' without filepattern (like 'git add' without
option)
* much later, maybe, re-allow 'git add -u|-A' without filepattern, with a
tree-wide scope.
A nice side effect of this patch is that it makes the :/ special
filepattern 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>
---
Changes since v2:
* Typo consistant -> consistent
* Mention both short and long option names (Thanks Junio). I went for
a two-lines display which I find a bit nicer to read than Junio's
version, but I'm fine with both.
Documentation/git-add.txt | 7 ++++---
builtin/add.c | 44 +++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 47 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index fd9e36b..5333559 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -107,9 +107,10 @@ apply to the index. See EDITING PATCHES below.
from the index if the corresponding files in the working tree
have been removed.
+
-If no <filepattern> is given, default to "."; in other words,
-update all tracked files in the current directory and its
-subdirectories.
+If no <filepattern> is given, the current version of Git defaults to
+"."; in other words, update all tracked files in the current directory
+and its subdirectories. This default will change in a future version
+of Git, hence the form without <filepattern> should not be used.
-A::
--all::
diff --git a/builtin/add.c b/builtin/add.c
index 7cb6cca..7738025 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -321,6 +321,35 @@ static int add_files(struct dir_struct *dir, int flags)
return exit_status;
}
+static void warn_pathless_add(const char *option_name, const char *short_name) {
+ /*
+ * To be consistent with "git add -p" and most Git
+ * commands, we should default to being tree-wide, but
+ * this is not the original behavior and can't be
+ * changed until users trained themselves not to type
+ * "git add -u" or "git add -A". For now, we warn and
+ * keep the old behavior. Later, this warning can be
+ * turned into a die(...), and eventually we may
+ * reallow the command with a new behavior.
+ */
+ warning(_("The behavior of 'git add %s (or %s)' with no path argument from a\n"
+ "subdirectory of the tree will change in Git 2.0 and should not be used anymore.\n"
+ "To add content for the whole tree, run:\n"
+ "\n"
+ " git add %s :/\n"
+ " (or git add %s :/)\n"
+ "\n"
+ "To restrict the command to the current directory, run:\n"
+ "\n"
+ " git add %s .\n"
+ " (or git add %s .)\n"
+ "\n"
+ "With the current Git version, the command is restricted to the current directory."),
+ option_name, short_name,
+ option_name, short_name,
+ option_name, short_name);
+}
+
int cmd_add(int argc, const char **argv, const char *prefix)
{
int exit_status = 0;
@@ -331,6 +360,8 @@ int cmd_add(int argc, const char **argv, const char *prefix)
int add_new_files;
int require_pathspec;
char *seen = NULL;
+ const char *option_with_implicit_dot = NULL;
+ const char *short_option_with_implicit_dot = NULL;
git_config(add_config, NULL);
@@ -350,8 +381,19 @@ int cmd_add(int argc, const char **argv, const char *prefix)
die(_("-A and -u are mutually incompatible"));
if (!show_only && ignore_missing)
die(_("Option --ignore-missing can only be used together with --dry-run"));
- if ((addremove || take_worktree_changes) && !argc) {
+ if (addremove) {
+ option_with_implicit_dot = "--all";
+ short_option_with_implicit_dot = "-A";
+ }
+ if (take_worktree_changes) {
+ option_with_implicit_dot = "--update";
+ short_option_with_implicit_dot = "-u";
+ }
+ if (option_with_implicit_dot && !argc) {
static const char *here[2] = { ".", NULL };
+ if (prefix)
+ warn_pathless_add(option_with_implicit_dot,
+ short_option_with_implicit_dot);
argc = 1;
argv = here;
}
--
1.8.1.1.440.g1d329bd.dirty
^ permalink raw reply related
* Re: Port 22
From: Michael J Gruber @ 2013-01-28 9:20 UTC (permalink / raw)
To: Kevin; +Cc: Craig Christensen, git
In-Reply-To: <CAO54GHBFo94Pes1cJ9MVvVJGD5ZMK4yMv9+_shtT8iPP-DVtsg@mail.gmail.com>
Kevin venit, vidit, dixit 28.01.2013 09:06:
> This is not really a git problem, but more of an ssh problem.
>
> Are you in the position to change the port where the SSH daemon
> listens on? Then you could use a different port which isn't blocked
> (443 perhaps?).
>
> On Sat, Jan 26, 2013 at 7:56 PM, Craig Christensen <cwcraigo@gmail.com> wrote:
>> I am currently a student at Brigham Young University - Idaho and we are use Pagoda Box and Git for our Mobile Apps class. However, the school's network has blocked incoming trafic on port 22. I have been searching through all the tutorials and documents provided by Pagoda Box and Git but have not been able to find a solution to solve this problem. We can use sftp but we then have to manually deploy the latest using the admin panel. Can you help provide a simple solution?
So how is your setup:
- Pagoda Box instance at BYU
- sftp uploads allowed, but not ssh
- drive Git on the box using the admin interface
Or do you use a Pagoda server? Do you have read access to the git repo
on the box?
ssh allows to restrict commands to only a subset, such as ssh only. If
the port were blocked for incoming traffic you wouldn't be able to use
(ssh at all thus) sftp either.
Michael
^ permalink raw reply
* Re: [PATCH v3] add: warn when -u or -A is used without filepattern
From: Jonathan Nieder @ 2013-01-28 9:20 UTC (permalink / raw)
To: Matthieu Moy
Cc: git, gitster, Robin Rosenberg, Piotr Krukowiecki,
Eric James Michael Ritz, Tomas Carnecky
In-Reply-To: <1359364593-10933-1-git-send-email-Matthieu.Moy@imag.fr>
Matthieu Moy wrote:
> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Looks good to me.
At some point we'll want to have tests for this case, but that's not
particularly urgent until it's time for the warning() to turn into a
die().
Thanks.
Jonathan
^ permalink raw reply
* Re: [feature request] git add completion should exclude staged content
From: Manlio Perillo @ 2013-01-28 9:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: wookietreiber, git
In-Reply-To: <7vip6iteod.fsf@alter.siamese.dyndns.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Il 28/01/2013 00:00, Junio C Hamano ha scritto:
> wookietreiber <kizkizzbangbang@googlemail.com> writes:
>
>> I have a feature request for `git add` auto completion:
>>
>> `git add` auto completion suggests all files / directories,
>> filtered by nothing. I guess it would be much nicer (as in
>> increasing productivity) if it would only suggest unstaged
>> content, as reported by `git status`, because that would be the
>> only content one would be able to add.
>
> I think that is what Manlio Perillo tried to do with the stalled
> mp/complete-paths topic that is queued in 'pu'.
>
> Manlio, any progress?
Well, I assumed that the patch was stalled due to missing review from
git completion experts...
For this reason I have not updated it with your latest suggestions,
waiting for the review (also, because now I'm busy with other projects).
For the OP: the last patch can be found in the mailing list archive,
with the subject:
[PATCH v5] git-completion.bash: add support for path completion
and date:
Fri, 11 Jan 2013 19:48:43 +0100
Can you please test it?
Regards Manlio
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlEGRE8ACgkQscQJ24LbaUSX9ACfUMBH/X6lVH4V7FUaB2wlqj8C
eYQAnAzuYwhYhDvkW3d29IeqHsDFyWBT
=BpRi
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH] l10n: de.po: translate 11 new messages
From: Thomas Rast @ 2013-01-28 10:33 UTC (permalink / raw)
To: Ralf Thielow; +Cc: jk, stimming, git
In-Reply-To: <1359353699-3987-1-git-send-email-ralf.thielow@gmail.com>
Ralf Thielow <ralf.thielow@gmail.com> writes:
> Translate 11 new messages came from git.pot update
> in 46bc403 (l10n: Update git.pot (11 new, 7 removed
> messages)).
> #: builtin/log.c:104
> msgid "Use mail map file"
> -msgstr ""
> +msgstr "verwendet \"mailmap\"-Datei"
Note that case differs here, but it's the English one that doesn't fit
the pattern -- option descriptions usually start with lowercase.
> #: 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?
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
* Re: [PATCH] git-remote-testpy: fix patch hashing on Python 3
From: Michael Haggerty @ 2013-01-28 10:44 UTC (permalink / raw)
To: John Keeping; +Cc: Junio C Hamano, git, Sverre Rabbelier
In-Reply-To: <20130127145056.GP7498@serenity.lan>
[-- Attachment #1: Type: text/plain, Size: 4681 bytes --]
On 01/27/2013 03:50 PM, John Keeping wrote:
> When this change was originally made (0846b0c - git-remote-testpy: hash
> bytes explicitly , I didn't realised that the "hex" encoding we chose is
> a "bytes to bytes" encoding so it just fails with an error on Python 3
> in the same way as the original code.
>
> It is not possible to provide a single code path that works on Python 2
> and Python 3 since Python 2.x will attempt to decode the string before
> encoding it, which fails for strings that are not valid in the default
> encoding. Python 3.1 introduced the "surrogateescape" error handler
> which handles this correctly and permits a bytes -> unicode -> bytes
> round-trip to be lossless.
>
> At this point Python 3.0 is unsupported so we don't go out of our way to
> try to support it.
>
> Helped-by: Michael Haggerty <mhagger@alum.mit.edu>
> Signed-off-by: John Keeping <john@keeping.me.uk>
> ---
> On Sun, Jan 27, 2013 at 02:13:29PM +0000, John Keeping wrote:
>> On Sun, Jan 27, 2013 at 05:44:37AM +0100, Michael Haggerty wrote:
>>> So to handle all of the cases across Python versions as closely as
>>> possible to the old 2.x code, it might be necessary to make the code
>>> explicitly depend on the Python version number, like:
>>>
>>> hasher = _digest()
>>> if sys.hexversion < 0x03000000:
>>> pathbytes = repo.path
>>> elif sys.hexversion < 0x03010000:
>>> # If support for Python 3.0.x is desired (note: result can
>>> # be different in this case than under 2.x or 3.1+):
>>> pathbytes = repo.path.encode(sys.getfilesystemencoding(),
>>> 'backslashreplace')
>>> else
>>> pathbytes = repo.path.encode(sys.getfilesystemencoding(),
>>> 'surrogateescape')
>>> hasher.update(pathbytes)
>>> repo.hash = hasher.hexdigest()
>
> How about this?
>
> git-remote-testpy.py | 18 +++++++++++++++++-
> 1 file changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/git-remote-testpy.py b/git-remote-testpy.py
> index c7a04ec..16b0c52 100644
> --- a/git-remote-testpy.py
> +++ b/git-remote-testpy.py
> @@ -36,6 +36,22 @@ if sys.hexversion < 0x02000000:
> sys.stderr.write("git-remote-testgit: requires Python 2.0 or later.\n")
> sys.exit(1)
>
> +
> +def _encode_filepath(path):
> + """Encodes a Unicode file path to a byte string.
> +
> + On Python 2 this is a no-op; on Python 3 we encode the string as
> + suggested by [1] which allows an exact round-trip from the command line
> + to the filesystem.
> +
> + [1] http://docs.python.org/3/c-api/unicode.html#file-system-encoding
> +
> + """
> + if sys.hexversion < 0x03000000:
> + return path
> + return path.encode('utf-8', 'surrogateescape')
> +
> +
> def get_repo(alias, url):
> """Returns a git repository object initialized for usage.
> """
> @@ -45,7 +61,7 @@ def get_repo(alias, url):
> repo.get_head()
>
> hasher = _digest()
> - hasher.update(repo.path.encode('hex'))
> + hasher.update(_encode_filepath(repo.path))
> repo.hash = hasher.hexdigest()
>
> repo.get_base_path = lambda base: os.path.join(
>
NAK. It is still not right. If the locale is not utf-8 based, then it
is incorrect to re-encode the string using utf-8. I think you really
have to use sys.getfilesystemencoding() as I suggested.
The attached program demonstrates the problem: the output of re-encoding
using UTF-8 depends on the locale, whereas that of re-encoding using the
filesystemencoding is independent of locale (as we want). The output,
using Python 3.2.3:
# This is 0xb6 0xc3:
$ ARG="ö"
$ LANG='C' /usr/bin/python3 chaos3.py "$ARG"
LANG = 'C'
fse = 'ascii'
sys.argv[1] = u"U+DCC3 U+DCB6"
re-encoded using UTF-8: b"C3 B6"
re-encoded using fse: b"C3 B6"
$ LANG='C.UTF-8' /usr/bin/python3 chaos3.py "$ARG"
LANG = 'C.UTF-8'
fse = 'utf-8'
sys.argv[1] = u"U+00F6"
re-encoded using UTF-8: b"C3 B6"
re-encoded using fse: b"C3 B6"
$ LANG='en_US.iso88591' /usr/bin/python3 chaos3.py "$ARG"
LANG = 'en_US.iso88591'
fse = 'iso8859-1'
sys.argv[1] = u"U+00C3 U+00B6"
re-encoded using UTF-8: b"C3 83 C2 B6"
re-encoded using fse: b"C3 B6"
Even though the Unicode intermediate representation is different for
UTF-8 and ASCII, re-encoding using the correct encoding gives back the
original bytes (which is what we want). But when using the ios8859-1
locale, the original bytes look like a valid latin1 string so they are
not surrogated going in, giving the incorrect Unicode string u"U+00C3
U+00B6". When this is re-encoded using UTF-8, the code points U+00C3
and U+00B6 are each encoded as two bytes.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
[-- Attachment #2: chaos3.py --]
[-- Type: text/x-python, Size: 664 bytes --]
#! /usr/bin/python3
import sys
import os
def explicit(s):
"""Convert a string or bytestring into an unambiguous human-readable string."""
if isinstance(s, str):
return 'u"%s"' % (' '.join('U+%04X' % (ord(c),) for c in s))
else:
return 'b"%s"' % (' '.join('%02X' % (c,) for c in s))
fse = sys.getfilesystemencoding()
print('LANG = %r' % (os.getenv('LANG'),))
print('fse = %r' % (fse,))
print('sys.argv[1] = %s' % explicit(sys.argv[1]))
print('re-encoded using UTF-8: %s' % explicit(sys.argv[1].encode('utf-8', 'surrogateescape')))
print('re-encoded using fse: %s' % explicit(sys.argv[1].encode(fse, 'surrogateescape')))
print()
^ permalink raw reply
* Bug: file named - on git commit
From: Rene Moser @ 2013-01-28 10:38 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 449 bytes --]
Hi
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.)
Everything looks ok to me after the commit. Other users reported to be
fixed in 1.8.1.1 but haven't it tested myself.
This does not work:
mkdir tmp && cd tmp;
echo foo >./-;
git init; git add .;
git commit -m "is this a bug?"
Kind regards
René
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]
^ permalink raw reply
* Re: Bug: file named - on git commit
From: Matthieu Moy @ 2013-01-28 10:56 UTC (permalink / raw)
To: Rene Moser; +Cc: git
In-Reply-To: <51065540.1090007@renemoser.net>
Rene Moser <mail@renemoser.net> writes:
> Hi
>
> Found a little issue in git version 1.7.9.5 if a file named "-", causing
> "git commit" to read from stdin.
Can't reproduce with Git version 1.8.1.1.440.g1d329bd, this probably has
been fixed already.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: Bug: file named - on git commit
From: Duy Nguyen @ 2013-01-28 10:58 UTC (permalink / raw)
To: Rene Moser; +Cc: git
In-Reply-To: <51065540.1090007@renemoser.net>
On Mon, Jan 28, 2013 at 5:38 PM, Rene Moser <mail@renemoser.net> wrote:
> Hi
>
> 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.)
>
> Everything looks ok to me after the commit. Other users reported to be
> fixed in 1.8.1.1 but haven't it tested myself.
Yes, it's fixed in 4682d85 (diff-index.c: "git diff" has no need to
read blob from the standard input - 2012-06-27) since v1.7.11.3.
> This does not work:
>
> mkdir tmp && cd tmp;
> echo foo >./-;
> git init; git add .;
> git commit -m "is this a bug?"
>
> Kind regards
>
> René
>
>
>
>
>
>
--
Duy
^ permalink raw reply
* Re: Bug: file named - on git commit
From: Thomas Rast @ 2013-01-28 11:05 UTC (permalink / raw)
To: Rene Moser; +Cc: git
In-Reply-To: <51065540.1090007@renemoser.net>
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.)
>
> Everything looks ok to me after the commit. Other users reported to be
> fixed in 1.8.1.1 but haven't it tested myself.
>
> This does not work:
>
> mkdir tmp && cd tmp;
> echo foo >./-;
> git init; git add .;
> git commit -m "is this a bug?"
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.
--
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