* Re: git send-email should not allow 'y' for in-reply-to
From: Junio C Hamano @ 2013-01-12 2:56 UTC (permalink / raw)
To: Ben Aveling
Cc: Antoine Pelisse, Jeff King, Matt Seitz (matseitz),
git@vger.kernel.org, Hilco Wijbenga
In-Reply-To: <50F0B643.20201@optusnet.com.au>
Ben Aveling <bena.001@optusnet.com.au> writes:
> On 12/01/2013 10:54 AM, Junio C Hamano wrote:
>> Antoine Pelisse <apelisse@gmail.com> writes:
>>
>>> I would simply go for:
>>>
>>> What Message-ID are you replying to (if any)?
>>>
>>> If I don't know what to answer, I would definitely not say y/yes/n/no,
>>> but press enter directly.
>> Sounds sensible (even though technically you reply to a message
>> that has that message ID, and not to a message ID ;-)).
>>
>> Any better phrasing from others? If not, I'd say we adopt this
>> text.
>
> I guess it depends on how much we mind if people accidentally miss the
> message ID.
>
> If we don't mind much, we could say something like:
>
> What Message-ID are you replying to [Default=None]?
>
>
> If we are concerned that when a Message-ID exists, it should be
> provided, we could split to 2 questions:
>
> Are you replying to an existing Message [Y/n]?
>
> And then, if the answer is Y,
>
> What Message-ID are you replying to?
Eewww. Now we come back to full circles.
It sometimes helps to follow the in-reply-to chain to see what has
already been said in the thread, I guess ;-)
^ permalink raw reply
* Re: git send-email should not allow 'y' for in-reply-to
From: Ben Aveling @ 2013-01-12 1:02 UTC (permalink / raw)
To: Junio C Hamano
Cc: Antoine Pelisse, Jeff King, Matt Seitz (matseitz),
git@vger.kernel.org, Hilco Wijbenga
In-Reply-To: <7vmwwf9sx9.fsf@alter.siamese.dyndns.org>
On 12/01/2013 10:54 AM, Junio C Hamano wrote:
> Antoine Pelisse <apelisse@gmail.com> writes:
>
>> I would simply go for:
>>
>> What Message-ID are you replying to (if any)?
>>
>> If I don't know what to answer, I would definitely not say y/yes/n/no,
>> but press enter directly.
> Sounds sensible (even though technically you reply to a message
> that has that message ID, and not to a message ID ;-)).
>
> Any better phrasing from others? If not, I'd say we adopt this
> text.
I guess it depends on how much we mind if people accidentally miss the
message ID.
If we don't mind much, we could say something like:
What Message-ID are you replying to [Default=None]?
If we are concerned that when a Message-ID exists, it should be
provided, we could split to 2 questions:
Are you replying to an existing Message [Y/n]?
And then, if the answer is Y,
What Message-ID are you replying to?
Regards, Ben
^ permalink raw reply
* Re: missing objects -- prevention
From: Sitaram Chamarty @ 2013-01-12 1:09 UTC (permalink / raw)
To: Jeff King; +Cc: Git Mailing List
In-Reply-To: <20130111164202.GB5219@sigill.intra.peff.net>
Thanks for the very detailed answer.
On Fri, Jan 11, 2013 at 10:12 PM, Jeff King <peff@peff.net> wrote:
> On Fri, Jan 11, 2013 at 04:40:38PM +0530, Sitaram Chamarty wrote:
>
>> I find a lot of info on how to recover from and/or repair a repo that
>> has missing (or corrupted) objects.
>>
>> What I need is info on common reasons (other than disk errors -- we've
>> checked for those) for such errors to occur, any preventive measures
>> we can take, and so on.
>
> I don't think any race can cause corruption of the object or packfiles
> because of the way they are written. At GitHub, every case of file-level
> corruption we've seen has been a filesystem issue.
>
> So I think the main thing systemic/race issue to worry about is missing
> objects. And since git only deletes objects during a prune (assuming you
> are using git-gc or "repack -A" so that repack cannot drop objects), I
> think prune is the only thing to watch out for.
No one runs anything manually under normal conditions. If there's any
gc happening, it's gc --auto.
> The --expire time saves us from the obvious races where you write object
> X but have not yet referenced it, and a simultaneous prune wants to
> delete it. However, it's possible that you have an old object that is
> unreferenced, but would become referenced as a result of an in-progress
> operation. For example, commit X is unreferenced and ready to be pruned,
> you build commit Y on top of it, but before you write the ref, git-prune
> removes X.
>
> The server-side version of that would happen via receive-pack, and is
> even more unlikely, because X would have to be referenced initially for
> us to advertise it. So it's something like:
>
> 1. The repo has a ref R pointing at commit X.
>
> 2. A user starts a push to another ref, Q, of commit Y that builds on
> X. Git advertises ref R, so the sender knows they do not need to
> send X, but only Y. The user then proceeds to send the packfile
> (which might take a very long time).
>
> 3. Meanwhile, another user deletes ref R. X becomes unreferenced.
The gitolite logs show that no deletion of refs has happened.
> 4. After step 3 but before step 2 has finished, somebody runs prune
> (this might sound unlikely, but if you kick off a "gc" job after
> each push, or after N pushes, it's not so unlikely). It sees that
> X is unreferenced, and it may very well be older than the --expire
> setting. Prune deletes X.
>
> 5. The packfile in (2) arrives, and receive-pack attempts to update
> the refs.
>
> So it's even a bit more unlikely than the local case, because
> receive-pack would not otherwise build on dangling objects. You have
> to race steps (2) and (3) just to create the situation.
>
> Then we have an extra protection in the form of
> check_everything_connected, which receive-pack runs before writing the
> refs into place. So if step 4 happens while the packfile is being sent
> (which is the most likely case, since it is the longest stretch of
> receive-pack's time), we would still catch it there and reject the push
> (annoying to the user, but the repo remains consistent).
>
> However, that's not foolproof. We might hit step 4 after we've checked
> that everything is connected but right before we write the ref. In which
> case we drop X, which has just become referenced, and we have a missing
> object.
>
> So I think it's possible. But I have never actually seen it in practice,
> and come up with this scenario only by brainstorming "what could go
> wrong" scenarios.
>
> This could be mitigated if there was a "proposed refs" storage.
> Receive-pack would write a note saying "consider Y for pruning purposes,
> but it's not really referenced yet", check connectivity for Y against
> the current refs, and then eventually write Y to its real ref (or reject
> it if there are problems). Prune would either run before the "proposed"
> note is written, which would mean it deletes X, but the connectivity
> check fails. Or it would run after, in which case it would leave X
> alone.
>
>> For example, can *any* type of network error or race condition cause
>> this? (Say, can one push writes an object, then fails an update
>> check, and a later push succeeds and races against a gc that removes
>> the unreachable object?) Or... the repo is pretty large -- about 6-7
>> GB, so could size cause a race that would not show up on a smaller
>> repo?
>
> The above is the only open issue I know about. I don't think it is
> dependent on repo size, but the window is widened for a really large
> push, because rev-list takes longer to run. It does not widen if you
> have receive.fsckobjects set, because that happens before we do the
> connectivity check (and the connectivity check is run in a sub-process,
> so the race timer starts when we exec rev-list, which may open and mmap
> packfiles or otherwise cache the presence of X in memory).
>
>> Anything else I can watch out for or caution the team about?
>
> That's the only open issue I know about for missing objects.
>
> There is a race with simultaneously deleting and packing refs. It
> doesn't cause object db corruption, but it will cause refs to "rewind"
> back to their packed versions. I have seen that one in practice (though
> relatively rare). I fixed it in b3f1280, which is not yet in any
> released version.
This is for the packed-refs file right? And it could result in a ref
getting deleted right?
I said above that the gitolite logs say no ref was deleted. What if
the ref "deletion" happened because of this race, making the rest of
your 4-step scenario above possible?
>> The symptom is usually a disk space crunch caused by tmp_pack_* files
>> left around by auto-gc. Presumably the missing objects failed the gc
>> and so it left the files around, and they eventually accumulate enough
>> to cause disk full errors. (If a gc ever succeeded, I suspect these
>> files would go away, but that requires manual intervention).
>
> Gc shouldn't be leaving around tmp_pack_* unless it is actually dying
> during the pack-objects phase. In my experience, stale tmp_pack_*
> objects are more likely a sign of a failed push (e.g., the client hangs
Oh. I did not know that! That explains why I sometimes saw that even
when there were less than 6700 loose objects (i.e., auto-gc should not
have kicked in at all).
> up in the middle, or fsck rejects the pack). We have historically left
fsck... you mean if I had 'receive.fsckObjects' true, right? I don't.
Should I? Would it help this overall situation? As I understand it,
thats only about the internals of each object to check corruption, and
cannot detect a *missing* object on the local object store.
> them in place to facilitate analysis of the failure.
>
> At GitHub, we've taken to just cleaning them up aggressively (I think
> after an hour), though I am tempted to put in an optional signal/atexit
OK; I'll do the same then. I suppose a cron job is the best way; I
didn't find any config for expiring these files.
Thanks again for your help. I'm going to treat it (for now) as a
disk/fs error after hearing from you about the other possibility I
mentioned above, although I find it hard to believe one repo can be
hit buy *two* races occurring together!
> handler to clean them up when index-pack fails. The forensics are
> occasionally interesting (e.g., finding weird fsck problems), but large
> pushes can waste a lot of disk space in the interim.
>
> -Peff
--
Sitaram
^ permalink raw reply
* What's cooking in git.git (Jan 2013, #05; Fri, 11)
From: Junio C Hamano @ 2013-01-11 23:56 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
--------------------------------------------------
[Graduated to "master"]
* as/api-allocation-doc (2013-01-06) 1 commit
(merged to 'next' on 2013-01-08 at c80b544)
+ api-allocation-growing.txt: encourage better variable naming
* as/dir-c-cleanup (2012-12-28) 10 commits
(merged to 'next' on 2013-01-08 at 5aee090)
+ dir.c: rename free_excludes() to clear_exclude_list()
+ dir.c: refactor is_path_excluded()
+ dir.c: refactor is_excluded()
+ dir.c: refactor is_excluded_from_list()
+ dir.c: rename excluded() to is_excluded()
+ dir.c: rename excluded_from_list() to is_excluded_from_list()
+ dir.c: rename path_excluded() to is_path_excluded()
+ dir.c: rename cryptic 'which' variable to more consistent name
+ Improve documentation and comments regarding directory traversal API
+ api-directory-listing.txt: update to match code
(this branch is used by as/check-ignore.)
Refactor and generally clean up the directory traversal API
implementation.
* aw/rebase-am-failure-detection (2012-10-11) 1 commit
(merged to 'next' on 2013-01-07 at 9e2ee43)
+ rebase: Handle cases where format-patch fails
Originally merged to 'next' on 2013-01-02
Save output from format-patch command in a temporary file, just in
case it aborts, to give a better failure-case behaviour.
* jc/comment-cygwin-win32api-in-makefile (2013-01-06) 1 commit
(merged to 'next' on 2013-01-08 at dea04e8)
+ Makefile: add comment on CYGWIN_V15_WIN32API
* jc/maint-fmt-merge-msg-no-edit-lose-credit (2012-12-28) 1 commit
(merged to 'next' on 2013-01-07 at 497bf10)
+ merge --no-edit: do not credit people involved in the side branch
Originally merged to 'next' on 2013-01-02
Stop spending cycles to compute information to be placed on
commented lines in "merge --no-edit".
* jk/config-uname (2013-01-03) 1 commit
(merged to 'next' on 2013-01-08 at f986500)
+ Makefile: hoist uname autodetection to config.mak.uname
Move the bits to set fallback default based on the platform from
the main Makefile to a separate file, so that it can be included in
Makefiles in subdirectories.
* jl/interrupt-clone-remove-separate-git-dir (2013-01-05) 1 commit
(merged to 'next' on 2013-01-08 at 568f874)
+ clone: support atomic operation with --separate-git-dir
When "git clone --separate-git-dir" is interrupted, we failed to
remove the real location we created the repository.
* mz/pick-unborn (2012-12-23) 2 commits
(merged to 'next' on 2013-01-07 at c6c062b)
+ learn to pick/revert into unborn branch
+ tests: move test_cmp_rev to test-lib-functions
Originally merged to 'next' on 2013-01-02
Allows "git cherry-pick $commit" when you do not have any history
behind HEAD yet.
* nd/wildmatch (2013-01-01) 18 commits
(merged to 'next' on 2013-01-07 at 2a39f7d)
+ wildmatch: replace variable 'special' with better named ones
+ compat/fnmatch: respect NO_FNMATCH* even on glibc
+ wildmatch: fix "**" special case
+ t3070: Disable some failing fnmatch tests
+ test-wildmatch: avoid Windows path mangling
+ Support "**" wildcard in .gitignore and .gitattributes
+ wildmatch: make /**/ match zero or more directories
+ wildmatch: adjust "**" behavior
+ wildmatch: fix case-insensitive matching
+ wildmatch: remove static variable force_lower_case
+ wildmatch: make wildmatch's return value compatible with fnmatch
+ t3070: disable unreliable fnmatch tests
+ Integrate wildmatch to git
+ wildmatch: follow Git's coding convention
+ wildmatch: remove unnecessary functions
+ Import wildmatch from rsync
+ ctype: support iscntrl, ispunct, isxdigit and isprint
+ ctype: make sane_ctype[] const array
(this branch is used by nd/retire-fnmatch.)
Originally merged to 'next' on 2013-01-01
Allows pathname patterns in .gitignore and .gitattributes files
with double-asterisks "foo/**/bar" to match any number of directory
hierarchies.
* rs/leave-base-name-in-name-field-of-tar (2013-01-05) 1 commit
(merged to 'next' on 2013-01-08 at 98f325e)
+ archive-tar: split long paths more carefully
Improve compatibility with implementations of "tar" that do not
like empty name field in header (with the additional prefix field
holding everything).
* tb/test-shell-lint (2013-01-02) 1 commit
(merged to 'next' on 2013-01-07 at 0bca54a)
+ test: Add check-non-portable-shell.pl
Originally merged to 'next' on 2013-01-04
Check for common mistakes in the test scripts, based on simple
pattern-matching.
--------------------------------------------------
[New Topics]
* jk/maint-fast-import-doc-reorder (2013-01-09) 2 commits
(merged to 'next' on 2013-01-10 at 9f3950d)
+ git-fast-import(1): reorganise options
+ git-fast-import(1): combine documentation of --[no-]relative-marks
Will merge to 'master'.
* jk/shortlog-no-wrap-doc (2013-01-09) 1 commit
(merged to 'next' on 2013-01-10 at c79898a)
+ git-shortlog(1): document behaviour of zero-width wrap
Will merge to 'master'.
* rt/commit-cleanup-config (2013-01-10) 1 commit
- commit: make default of "cleanup" option configurable
Add a configuration variable to set default clean-up mode other
than "strip".
Will merge to 'next'.
* jc/custom-comment-char (2013-01-10) 1 commit
- 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 '#'.
* jn/maint-trim-vim-contrib (2013-01-10) 1 commit
- contrib/vim: simplify instructions for old vim support
Will merge to 'next'.
* mz/reset-misc (2013-01-10) 22 commits
- reset [--mixed]: use diff-based reset whether or not pathspec was given
- [SQUASH???] script portability fixes
- reset: allow reset on unborn branch
- reset $sha1 $pathspec: require $sha1 only to be treeish
- reset [--mixed] --quiet: don't refresh index
- reset.c: finish entire cmd_reset() whether or not pathspec is given
- reset [--mixed]: don't write index file twice
- reset.c: move lock, write and commit out of update_index_refresh()
- reset.c: move update_index_refresh() call out of read_from_tree()
- reset: avoid redundant error message
- reset --keep: only write index file once
- reset.c: replace switch by if-else
- reset.c: share call to die_if_unmerged_cache()
- [SQUASH???] style fixes
- reset.c: extract function for updating {ORIG,}HEAD
- reset.c: remove unnecessary variable 'i'
- [SQUASH???] style fix
- reset.c: extract function for parsing arguments
- reset: don't allow "git reset -- $pathspec" in bare repo
- reset.c: pass pathspec around instead of (prefix, argv) pair
- reset $pathspec: exit with code 0 if successful
- reset $pathspec: no need to discard index
Various 'reset' optimizations and clean-ups, followed by a change
to allow "git reset" to work even on an unborn branch.
* pe/doc-email-env-is-trumped-by-config (2013-01-10) 1 commit
- git-commit-tree(1): correct description of defaults
In the precedence order, the environment variable $EMAIL comes
between the built-in default (i.e. taking value by asking the
system's gethostname() etc.) and the user.email configuration
variable; the documentation implied that it is stronger than the
configuration like $GIT_COMMITTER_EMAIL is, which is wrong.
Will merge to 'next'.
* ds/completion-silence-in-tree-path-probe (2013-01-11) 1 commit
- git-completion.bash: silence "not a valid object" errors
An internal ls-tree call made by completion code only to probe if
a path exists in the tree recorded in a commit object leaked error
messages when the path is not there. It is not an error at all and
should not be shown to the end user.
Will merge to 'next'.
* er/replace-cvsimport (2013-01-11) 4 commits
- t9604: fixup for new cvsimport
- t9600: fixup for new cvsimport
- t/lib-cvs.sh: allow cvsps version 3.x.
- cvsimport: rewrite to use cvsps 3.x to fix major bugs
Rewrite of cvsimport to talk with cvsps 3.x; this negatively
affects existing users of cvsimport that only have cvsps 2.x and
use -o, -M and -m options (they cannot use the old cvsimport with
old cvsps 2.x in the fall-back mode, even though these options are
supported by the old one), but it is not known how common they are.
For people who work with CVS histories complex enough to need cvsps
3.x to import correctly, this version should be a definite
improvement, and I would love to see small wrinkles in the new
implementation straightened out sooner so that we can merge it to
'next' (and from there on, apply incremental updates).
Help from people with Python experience would be appreciated in
reviewing and patching.
* nd/fetch-depth-is-broken (2013-01-11) 3 commits
- 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 merge to 'next'.
* jc/no-git-config-in-clone (2013-01-11) 1 commit
- 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.
--------------------------------------------------
[Stalled]
* 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.
--------------------------------------------------
[Cooking]
* nz/send-email-headers-are-case-insensitive (2013-01-06) 1 commit
(merged to 'next' on 2013-01-10 at cf4c9c9)
+ git-send-email: treat field names as case-insensitively
When user spells "cc:" in lowercase in the fake "header" in the
trailer part, send-email failed to pick up the addresses from
there. As e-mail headers field names are case insensitive, this
script should follow suit and treat "cc:" and "Cc:" the same way.
* mk/complete-tcsh (2013-01-07) 1 commit
(merged to 'next' on 2013-01-11 at b8b30b1)
+ Prevent space after directories in tcsh completion
Update tcsh command line completion so that an unwanted space is
not added to a single directory name.
* 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.
Will merge to 'next'.
* ap/log-mailmap (2013-01-10) 11 commits
(merged to 'next' on 2013-01-10 at 8544084)
+ log --use-mailmap: optimize for cases without --author/--committer search
+ log: add log.mailmap configuration option
+ log: grep author/committer using mailmap
+ test: add test for --use-mailmap option
+ log: add --use-mailmap option
+ pretty: use mailmap to display username and email
+ mailmap: add mailmap structure to rev_info and pp
+ mailmap: simplify map_user() interface
+ mailmap: remove email copy and length limitation
+ Use split_ident_line to parse author and committer
+ string-list: allow case-insensitive string list
Teach commands in the "log" family to optionally pay attention to
the mailmap.
* nd/upload-pack-shallow-must-be-commit (2013-01-08) 1 commit
(merged to 'next' on 2013-01-10 at a8b3ba5)
+ upload-pack: only accept commits from "shallow" line
A minor consistency check patch that does not have much relevance
to the real world.
* jc/blame-no-follow (2012-09-21) 2 commits
(merged to 'next' on 2013-01-10 at 201c7f4)
+ blame: pay attention to --no-follow
+ diff: accept --no-follow option
Teaches "--no-follow" option to "git blame" to disable its
whole-file rename detection.
* jc/push-2.0-default-to-simple (2013-01-08) 11 commits
(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 ;-).
* jk/unify-exit-code-by-receiving-signal (2013-01-06) 1 commit
(merged to 'next' on 2013-01-08 at 5ebf940)
+ run-command: encode signal death as a positive integer
The internal logic had to deal with two representations of a death
of a child process by a signal.
Will merge to 'master'.
* jn/xml-depends-on-asciidoc-conf (2013-01-06) 1 commit
(merged to 'next' on 2013-01-08 at 4faf8d4)
+ docs: manpage XML depends on asciidoc.conf
Will merge to 'master'.
* nd/clone-no-separate-git-dir-with-bare (2013-01-10) 1 commit
- clone: forbid --bare --separate-git-dir <dir>
Will merge to 'next'.
* 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.
Unfortunately, this conflicts a couple of topics in flight. I tried
to be careful while resolving conflicts, though.
* rs/zip-tests (2013-01-07) 4 commits
(merged to 'next' on 2013-01-08 at 8e37423)
+ t5003: check if unzip supports symlinks
+ t5000, t5003: move ZIP tests into their own script
+ t0024, t5000: use test_lazy_prereq for UNZIP
+ t0024, t5000: clear variable UNZIP, use GIT_UNZIP instead
Updates zip tests to skip some that cannot be handled on platform
unzip.
I've renamed the t5002 in the original to t5003 to avoid name
clashes with another topic in flight.
Will merge to 'master'.
* rs/zip-with-uncompressed-size-in-the-header (2013-01-06) 1 commit
(merged to 'next' on 2013-01-08 at d9ec30e)
+ archive-zip: write uncompressed size into header even with streaming
Improve compatibility of our zip output to fill uncompressed size
in the header, which we can do without seeking back (even though it
should not be necessary).
Will merge to 'master'.
* jc/doc-maintainer (2013-01-03) 2 commits
(merged to 'next' on 2013-01-11 at f35d582)
+ howto/maintain: mark titles for asciidoc
+ Documentation: update "howto maintain git"
Describe tools for automation that were invented since this
document was originally written.
* fc/remote-testgit-feature-done (2012-10-29) 1 commit
(merged to 'next' on 2013-01-10 at 3132a60)
+ remote-testgit: properly check for errors
In the longer term, tightening rules is a good thing to do, and
because nobody who has worked in the remote helper area seems to be
interested in reviewing this, I would assume they do not think
such a retroactive tightening will affect their remote helpers. So
let's advance this topic to see what happens.
* mo/cvs-server-updates (2012-12-09) 18 commits
(merged to 'next' on 2013-01-08 at 75e2d11)
+ t9402: Use TABs for indentation
+ t9402: Rename check.cvsCount and check.list
+ t9402: Simplify git ls-tree
+ t9402: Add missing &&; Code style
+ t9402: No space after IO-redirection
+ t9402: Dont use test_must_fail cvs
+ t9402: improve check_end_tree() and check_end_full_tree()
+ t9402: sed -i is not portable
+ cvsserver Documentation: new cvs ... -r support
+ cvsserver: add t9402 to test branch and tag refs
+ cvsserver: support -r and sticky tags for most operations
+ cvsserver: Add version awareness to argsfromdir
+ cvsserver: generalize getmeta() to recognize commit refs
+ cvsserver: implement req_Sticky and related utilities
+ cvsserver: add misc commit lookup, file meta data, and file listing functions
+ cvsserver: define a tag name character escape mechanism
+ cvsserver: cleanup extra slashes in filename arguments
+ cvsserver: factor out git-log parsing logic
Various git-cvsserver updates.
Will cook in 'next' for a while to see if anybody screams.
* ap/status-ignored-in-ignored-directory (2013-01-07) 3 commits
(merged to 'next' on 2013-01-10 at 20f7476)
+ status: always report ignored tracked directories
(merged to 'next' on 2013-01-07 at 2a20b19)
+ git-status: Test --ignored behavior
+ dir.c: Make git-status --ignored more consistent
Output from "git status --ignored" showed an unexpected interaction
with "--untracked".
* as/check-ignore (2013-01-10) 12 commits
- t0008: avoid brace expansion
- add git-check-ignore sub-command
- setup.c: document get_pathspec()
- add.c: extract new die_if_path_beyond_symlink() for reuse
- add.c: extract check_path_for_gitlink() from treat_gitlinks() for reuse
- pathspec.c: rename newly public functions for clarity
- add.c: move pathspec matchers into new pathspec.c for reuse
- add.c: remove unused argument from validate_pathspec()
- dir.c: improve docs for match_pathspec() and match_pathspec_depth()
- dir.c: provide clear_directory() for reclaiming dir_struct memory
- dir.c: keep track of where patterns came from
- dir.c: use a single struct exclude_list per source of excludes
Add a new command "git check-ignore" for debugging .gitignore
files.
Will merge to 'next'.
* jc/format-patch-reroll (2013-01-03) 9 commits
(merged to 'next' on 2013-01-07 at 0e007e6)
+ format-patch: give --reroll-count a short synonym -v
+ format-patch: document and test --reroll-count
+ format-patch: add --reroll-count=$N option
+ get_patch_filename(): split into two functions
+ get_patch_filename(): drop "just-numbers" hack
+ get_patch_filename(): simplify function signature
+ builtin/log.c: stop using global patch_suffix
+ builtin/log.c: drop redundant "numbered_files" parameter from make_cover_letter()
+ builtin/log.c: drop unused "numbered" parameter from make_cover_letter()
Originally merged to 'next' on 2013-01-04
Teach "format-patch" to prefix v4- to its output files for the
fourth iteration of a patch series, to make it easier for the
submitter to keep separate copies for iterations.
Will merge to 'master'.
* nd/retire-fnmatch (2013-01-01) 7 commits
(merged to 'next' on 2013-01-07 at ab31f9b)
+ Makefile: add USE_WILDMATCH to use wildmatch as fnmatch
+ wildmatch: advance faster in <asterisk> + <literal> patterns
+ wildmatch: make a special case for "*/" with FNM_PATHNAME
+ test-wildmatch: add "perf" command to compare wildmatch and fnmatch
+ wildmatch: support "no FNM_PATHNAME" mode
+ wildmatch: make dowild() take arbitrary flags
+ wildmatch: rename constants and update prototype
Originally merged to 'next' on 2013-01-04
Replace our use of fnmatch(3) with a more feature-rich wildmatch.
A handful patches at the bottom have been moved to nd/wildmatch to
graduate as part of that branch, before this series solidifies.
Will cook in 'next' a bit longer than other topics.
* jc/merge-blobs (2012-12-26) 5 commits
(merged to 'next' on 2013-01-08 at 582ca38)
+ merge-tree: fix d/f conflicts
+ merge-tree: add comments to clarify what these functions are doing
+ merge-tree: lose unused "resolve_directories"
+ merge-tree: lose unused "flags" from merge_list
+ Which merge_file() function do you mean?
Update the disused merge-tree proof-of-concept code.
Will merge to 'master'.
* mb/gitweb-highlight-link-target (2012-12-20) 1 commit
- Highlight the link target line in Gitweb using CSS
Expecting a reroll.
$gmane/211935
* zk/clean-report-failure (2013-01-10) 2 commits
- [SQUASH???] style fixes
- git-clean: Display more accurate delete messages
"git clean" states what it is going to remove and then goes on to
remove it, but sometimes it only discovers things that cannot be
removed after recursing into a directory, which makes the output
confusing and even wrong.
Will merge to 'next' after squashing the style fix in.
* 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.
* bc/append-signed-off-by (2013-01-01) 12 commits
- t4014: do not use echo -n
- Unify appending signoff in format-patch, commit and sequencer
- format-patch: update append_signoff prototype
- format-patch: stricter S-o-b detection
- 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
- sequencer.c: remove broken support for rfc2822 continuation in footer
Expecting a reroll.
$gmane/212507
^ permalink raw reply
* Re: git send-email should not allow 'y' for in-reply-to
From: Junio C Hamano @ 2013-01-11 23:54 UTC (permalink / raw)
To: Antoine Pelisse
Cc: Jeff King, Matt Seitz (matseitz), git@vger.kernel.org,
Hilco Wijbenga
In-Reply-To: <CALWbr2wtAzz7yWb_Z_V0LFt5ddZcRSs7_rea2w=ghdC847mEyQ@mail.gmail.com>
Antoine Pelisse <apelisse@gmail.com> writes:
> I would simply go for:
>
> What Message-ID are you replying to (if any)?
>
> If I don't know what to answer, I would definitely not say y/yes/n/no,
> but press enter directly.
Sounds sensible (even though technically you reply to a message
that has that message ID, and not to a message ID ;-)).
Any better phrasing from others? If not, I'd say we adopt this
text.
Thanks.
^ permalink raw reply
* Re: git send-email should not allow 'y' for in-reply-to
From: Antoine Pelisse @ 2013-01-11 22:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Matt Seitz (matseitz), git@vger.kernel.org
In-Reply-To: <7vy5fz9xdl.fsf@alter.siamese.dyndns.org>
On Fri, Jan 11, 2013 at 11:18 PM, Junio C Hamano <gitster@pobox.com> wrote:
> The exchange, when you do not have a configuration, goes like this:
>
> $ git send-email 0001-filename-of-the-patch.patch
> 0001-filename-of-the-patch.patch
> Who should the emails be sent to (if any)? junio
> Are you sure you want to use <junio> [y/N]? y
> Message-ID to be used as In-Reply-To for the first email (if any)?
>
> Why not do this instead?
>
> $ git send-email 0001-filename-of-the-patch.patch
> 0001-filename-of-the-patch.patch
> Who should the emails be sent to (if any)? junio
> Are you sure you want to use <junio> [y/N]? y
> Is this a response to an existing message [y/N]? y
I'm not sure about the extra question. If the user doesn't care, he
will probably use the empty default, which will result in the same
number of steps. If the user cares, he probably knows what he's doing
and will give a sensible value.
> What is the Message-ID of the message you are replying to?
I would simply go for:
What Message-ID are you replying to (if any)?
If I don't know what to answer, I would definitely not say y/yes/n/no,
but press enter directly.
^ permalink raw reply
* Re: git send-email should not allow 'y' for in-reply-to
From: Junio C Hamano @ 2013-01-11 22:18 UTC (permalink / raw)
To: Antoine Pelisse; +Cc: Jeff King, Matt Seitz (matseitz), git@vger.kernel.org
In-Reply-To: <CALWbr2xasF1y9j3G=-fQ9Wwg41Ymv=MMsWoqyuhweDov9KpRvg@mail.gmail.com>
Antoine Pelisse <apelisse@gmail.com> writes:
> On Fri, Jan 11, 2013 at 10:23 PM, Jeff King <peff@peff.net> wrote:
>> On Fri, Jan 11, 2013 at 08:13:57PM +0000, Matt Seitz (matseitz) wrote:
>>
>>> > > How about "What Message-ID to use as In-Reply-To for the first email?"
>>> > > or "Provide the Message-ID to use as In-Reply-To for the first
>>> > > email:".
>>> >
>>> > seem fine to me. Maybe somebody who has been confused by it can offer
>>> > more. At any rate, patches welcome.
>>>
>>> Suggestion: "Message-ID to use as In-Reply-To for the first email:".
>>>
>>> Simple and unlikely to generate a "y" or "n" response. Putting
>>> "Message-ID" first makes it more obvious what data is being asked for
>>> by this prompt.
>>
>> You'd think. But the existing message that has been causing problems is:
>>
>> Message-ID to be used as In-Reply-To for the first email?
>>
>> which is more or less what you are proposing. I do think a colon rather
>> than a question mark helps indicate that the response is not yes/no.
>
> That is true.
>
> I'm definitely not a wording person, but assuming people who make the
> mistake probably don't read the whole sentence out of laziness (that
> might be somehow extreme though ;), starting it with "what" makes it
> obvious at first sight that you can't answer yes/no.
> That is not true if the message starts with Message-ID .. which
> doesn't look like a question. Now it feels like you have agree or not.
The exchange, when you do not have a configuration, goes like this:
$ git send-email 0001-filename-of-the-patch.patch
0001-filename-of-the-patch.patch
Who should the emails be sent to (if any)? junio
Are you sure you want to use <junio> [y/N]? y
Message-ID to be used as In-Reply-To for the first email (if any)?
Why not do this instead?
$ git send-email 0001-filename-of-the-patch.patch
0001-filename-of-the-patch.patch
Who should the emails be sent to (if any)? junio
Are you sure you want to use <junio> [y/N]? y
Is this a response to an existing message [y/N]? y
What is the Message-ID of the message you are replying to?
^ permalink raw reply
* Re: [PATCH] format_commit_message(): simplify calls to logmsg_reencode()
From: Junio C Hamano @ 2013-01-11 22:15 UTC (permalink / raw)
To: git
In-Reply-To: <1357942509-21431-1-git-send-email-gitster@pobox.com>
Please disregard this...
^ permalink raw reply
* [PATCH] format_commit_message(): simplify calls to logmsg_reencode()
From: Junio C Hamano @ 2013-01-11 22:15 UTC (permalink / raw)
To: git
All the other callers of logmsg_reencode() pass return value of
get_commit_output_encoding() or get_log_output_encoding(). Teach
the function to optionally take NULL as a synonym to "" aka "no
conversion requested" so that we can simplify the only remaining
calling site.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
pretty.c | 16 ++++------------
1 file changed, 4 insertions(+), 12 deletions(-)
diff --git a/pretty.c b/pretty.c
index e87fe9f..732e2a2 100644
--- a/pretty.c
+++ b/pretty.c
@@ -500,7 +500,7 @@ char *logmsg_reencode(const struct commit *commit,
char *encoding;
char *out;
- if (!*output_encoding)
+ if (!output_encoding || !*output_encoding)
return NULL;
encoding = get_header(commit, "encoding");
use_encoding = encoding ? encoding : utf8;
@@ -1184,23 +1184,15 @@ void format_commit_message(const struct commit *commit,
const struct pretty_print_context *pretty_ctx)
{
struct format_commit_context context;
- static const char utf8[] = "UTF-8";
const char *output_enc = pretty_ctx->output_encoding;
memset(&context, 0, sizeof(context));
context.commit = commit;
context.pretty_ctx = pretty_ctx;
context.wrap_start = sb->len;
- context.message = commit->buffer;
- if (output_enc) {
- char *enc = get_header(commit, "encoding");
- if (strcmp(enc ? enc : utf8, output_enc)) {
- context.message = logmsg_reencode(commit, output_enc);
- if (!context.message)
- context.message = commit->buffer;
- }
- free(enc);
- }
+ context.message = logmsg_reencode(commit, output_enc);
+ if (!context.message)
+ context.message = commit->buffer;
strbuf_expand(sb, format, format_commit_item, &context);
rewrap_message_tail(sb, &context, 0, 0, 0);
--
1.8.1.407.g91cb4ac
^ permalink raw reply related
* Re: [PATCH v5] git-completion.bash: add support for path completion
From: Junio C Hamano @ 2013-01-11 22:02 UTC (permalink / raw)
To: Manlio Perillo; +Cc: git, szeder, felipe.contreras, peff
In-Reply-To: <1357930123-26310-1-git-send-email-manlio.perillo@gmail.com>
Manlio Perillo <manlio.perillo@gmail.com> writes:
> +# Process path list returned by "ls-files" and "diff-index --name-only"
> +# commands, in order to list only file names relative to a specified
> +# directory, and append a slash to directory names.
> +__git_index_file_list_filter ()
> +{
> + # Default to Bash >= 4.x
> + __git_index_file_list_filter_bash
> +}
> +
> +# Execute git ls-files, returning paths relative to the directory
> +# specified in the first argument, and using the options specified in
> +# the second argument.
> +__git_ls_files_helper ()
> +{
> + # NOTE: $2 is not quoted in order to support multiple options
> + cd "$1" && git ls-files --exclude-standard $2
> +} 2>/dev/null
I think this redirection is correct but a bit tricky; it is in
effect during the execution of the { block } (in other words, it is
not about squelching errors during the function definition).
-- >8 --
#!/bin/sh
cat >t.sh <<\EOF &&
echo I am "$1"
t () { echo "Goes to stdout"; echo >&2 "Goes to stderr"; } 2>/dev/null
t
for sh in bash dash ksh zsh
do
$sh t.sh $sh
done
-- 8< --
Bash does (so do dash and real AT&T ksh) grok this correctly, but
zsh does not seem to (I tried zsh 4.3.10 and 4.3.17; also zsh
pretending to be ksh gets this wrong as well). Not that what ksh
does matters, as it won't be dot-sourcing bash completion script.
It however may affect zsh, which does seem to dot-source this file.
Perhaps zsh completion may have to be rewritten in a similar way as
tcsh completion is done (i.e. does not dot-source this file but ask
bash to do the heavy-lifting).
This function seems to be always called in an subshell (e.g. as an
upstream of a pipeline), so the "cd" may be harmless, but don't you
need to disable CDPATH while doing this?
> +# Execute git diff-index, returning paths relative to the directory
> +# specified in the first argument, and using the tree object id
> +# specified in the second argument.
> +__git_diff_index_helper ()
> +{
> + cd "$1" && git diff-index --name-only --relative "$2"
> +} 2>/dev/null
Ditto.
> @@ -722,6 +875,43 @@ __git_has_doubledash ()
> return 1
> }
>
> +# Try to count non option arguments passed on the command line for the
> +# specified git command.
> +# When options are used, it is necessary to use the special -- option to
> +# tell the implementation were non option arguments begin.
> +# XXX this can not be improved, since options can appear everywhere, as
> +# an example:
> +# git mv x -n y
If that is the case, it is a bug in the command line parser, I
think. We should reject it, and the command line completer
certainly should not encourage it.
^ permalink raw reply
* Re: git send-email should not allow 'y' for in-reply-to
From: Antoine Pelisse @ 2013-01-11 21:53 UTC (permalink / raw)
To: Jeff King; +Cc: Matt Seitz (matseitz), git@vger.kernel.org
In-Reply-To: <20130111212325.GA18193@sigill.intra.peff.net>
On Fri, Jan 11, 2013 at 10:23 PM, Jeff King <peff@peff.net> wrote:
> On Fri, Jan 11, 2013 at 08:13:57PM +0000, Matt Seitz (matseitz) wrote:
>
>> > > How about "What Message-ID to use as In-Reply-To for the first email?"
>> > > or "Provide the Message-ID to use as In-Reply-To for the first
>> > > email:".
>> >
>> > seem fine to me. Maybe somebody who has been confused by it can offer
>> > more. At any rate, patches welcome.
>>
>> Suggestion: "Message-ID to use as In-Reply-To for the first email:".
>>
>> Simple and unlikely to generate a "y" or "n" response. Putting
>> "Message-ID" first makes it more obvious what data is being asked for
>> by this prompt.
>
> You'd think. But the existing message that has been causing problems is:
>
> Message-ID to be used as In-Reply-To for the first email?
>
> which is more or less what you are proposing. I do think a colon rather
> than a question mark helps indicate that the response is not yes/no.
That is true.
I'm definitely not a wording person, but assuming people who make the
mistake probably don't read the whole sentence out of laziness (that
might be somehow extreme though ;), starting it with "what" makes it
obvious at first sight that you can't answer yes/no.
That is not true if the message starts with Message-ID .. which
doesn't look like a question. Now it feels like you have agree or not.
Antoine,
^ permalink raw reply
* Re: git send-email should not allow 'y' for in-reply-to
From: Jeff King @ 2013-01-11 21:23 UTC (permalink / raw)
To: Matt Seitz (matseitz); +Cc: git@vger.kernel.org
In-Reply-To: <A0DB01D693D8EF439496BC8B037A0AEF322039A7@xmb-rcd-x15.cisco.com>
On Fri, Jan 11, 2013 at 08:13:57PM +0000, Matt Seitz (matseitz) wrote:
> > > How about "What Message-ID to use as In-Reply-To for the first email?"
> > > or "Provide the Message-ID to use as In-Reply-To for the first
> > > email:".
> >
> > seem fine to me. Maybe somebody who has been confused by it can offer
> > more. At any rate, patches welcome.
>
> Suggestion: "Message-ID to use as In-Reply-To for the first email:".
>
> Simple and unlikely to generate a "y" or "n" response. Putting
> "Message-ID" first makes it more obvious what data is being asked for
> by this prompt.
You'd think. But the existing message that has been causing problems is:
Message-ID to be used as In-Reply-To for the first email?
which is more or less what you are proposing. I do think a colon rather
than a question mark helps indicate that the response is not yes/no.
-Peff
^ permalink raw reply
* Re: [PATCH] git-completion.bash: Silence not a valid object errors
From: Manlio Perillo @ 2013-01-11 21:12 UTC (permalink / raw)
To: Dylan Smith; +Cc: git
In-Reply-To: <alpine.DEB.2.02.1301110304220.26739@antec>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Il 11/01/2013 09:06, Dylan Smith ha scritto:
> Trying to complete the command
>
> git show master:./file
>
> would cause a "Not a valid object name" error to be output on standard
> error. Silence the error so it won't appear on the command line.
>
I reported the problem a few weeks ago; thanks.
> [...]
Regards Manlio
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlDwgCAACgkQscQJ24LbaUTAxgCfZbB8X8IaTZAcT8iTs1XIILBJ
72MAn2zlh3xbRa/wjq1WyA2yOiAlaCr7
=dMN7
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: git-archive fails against smart-http repos
From: Jeff King @ 2013-01-11 20:58 UTC (permalink / raw)
To: Bruce Lysik; +Cc: git
In-Reply-To: <6014ED12-17F9-4D57-927F-6AFCD8A51C9D@apple.com>
On Wed, Jan 09, 2013 at 10:52:48AM -0800, Bruce Lysik wrote:
> Trying to run git-archive fails against smart-http based repos. Example:
>
> $ git archive --verbose --format=zip --remote=http://code.toofishes.net/git/dan/initscripts.git
> fatal: Operation not supported by protocol.
> Unexpected end of command stream
>
> This problem was brought up against my internal repos as well.
Right. Neither the client nor server for the http transport knows how to
handle the "git-upload-archive" service (as opposed to the regular
"git-upload-pack" or "git-receive-pack" services). I don't think there's
anything technical standing in the way; it is has simply never been
implemented.
Currently, you can do remote git-archive only locally, via ssh, or over
git:// (but then only if the server side has explicitly enabled it).
Patches welcome.
-Peff
^ permalink raw reply
* Re: git send-email should not allow 'y' for in-reply-to
From: Matt Seitz (matseitz) @ 2013-01-11 20:13 UTC (permalink / raw)
To: git@vger.kernel.org
"Jeff King" <peff@peff.net> wrote in message news:<20130111185417.GA12852@sigill.intra.peff.net>...
> On Fri, Jan 11, 2013 at 10:43:39AM -0800, Hilco Wijbenga wrote:
>
>
> > How about "What Message-ID to use as In-Reply-To for the first email?"
> > or "Provide the Message-ID to use as In-Reply-To for the first
> > email:".
>
> seem fine to me. Maybe somebody who has been confused by it can offer
> more. At any rate, patches welcome.
Suggestion: "Message-ID to use as In-Reply-To for the first email:".
Simple and unlikely to generate a "y" or "n" response. Putting "Message-ID" first makes it more obvious what data is being asked for by this prompt.
^ permalink raw reply
* [BUG]:Git doesn't work with Sock5 proxy on MAC
From: Herry Wang @ 2013-01-11 20:22 UTC (permalink / raw)
To: git
On Thu, Jan 10, 2013 at 9:51 PM, Herry Wang <tech.herry@gmail.com> wrote:
>
> OS:
>
> Darwin ... 11.4.2 Darwin Kernel Version 11.4.2: Thu Aug 23 16:25:48 PDT
> 2012; root:xnu-1699.32.7~1/RELEASE_X86_64 x86_64
>
> Git: version: (via homebrew)
>
> git --version
> git version 1.8.0
>
> curl version:
>
> curl --version
> curl 7.28.1 (x86_64-apple-darwin11.4.2)
>
>
> git clone http://herry@stash.somesite/a.git
> Cloning into 'a'...
> error: Empty reply from server while accessing
> ....git/info/refs?service=git-upload-pack
> fatal: HTTP request failed
>
> i tried export http_proxy=socks5://ip:port, all_proxy=socks5://, neither
> of them works.
> I also configure socks proxy in ~/.curlrc, git is not working well.
> However, curl is doing well with curlrc config.
> From the trace, looks like git is just put the http request via proxy
> host. But according with socks protocol, it should have some headers.
>
>
> Interesting thing is, http_proxy way is working perfectly on my Ubuntu
> enviroment.
>
>
> Thanks
> Herry
>
^ permalink raw reply
* Re: Version 1.8.1 does not compile on Cygwin 1.7.14
From: Alex Riesen @ 2013-01-11 20:17 UTC (permalink / raw)
To: Mark Levedahl
Cc: Junio C Hamano, Jason Pyeron, git, Jonathan Nieder,
Torsten Bögershausen, Stephen & Linda Smith, Eric Blake
In-Reply-To: <CALxABCYHRp17rcoOca1xWG9S19fq2rotz8FEKo09jNdrgMLiyQ@mail.gmail.com>
On Fri, Jan 11, 2013 at 9:08 PM, Alex Riesen <raa.lkml@gmail.com> wrote:
> This short discussion on GitHub (file git-compat-util.h) might be relevant:
>
> https://github.com/msysgit/git/commit/435bdf8c7ffa493f8f6f2e8f329f8cc22db16ce6#commitcomment-2407194
>
> The change suggested there (to remove an inclusion of windows.h in
> git-compat-util.h) might simplify the solution a little. Might even
> remove the need for auto-configuration in Makefile (worked for me).
Just to be clear, the change is this:
diff --git a/git-compat-util.h b/git-compat-util.h
index 4a1979f..780a919 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -85,12 +85,6 @@
#define _NETBSD_SOURCE 1
#define _SGI_SOURCE 1
-#ifdef WIN32 /* Both MinGW and MSVC */
-#define WIN32_LEAN_AND_MEAN /* stops windows.h including winsock.h */
-#include <winsock2.h>
-#include <windows.h>
-#endif
-
#include <unistd.h>
#include <stdio.h>
#include <sys/stat.h>
^ permalink raw reply related
* Re: Version 1.8.1 does not compile on Cygwin 1.7.14
From: Alex Riesen @ 2013-01-11 20:08 UTC (permalink / raw)
To: Mark Levedahl
Cc: Junio C Hamano, Jason Pyeron, git, Jonathan Nieder,
Torsten Bögershausen, Stephen & Linda Smith, Eric Blake
In-Reply-To: <50EB8EB5.6080204@gmail.com>
This short discussion on GitHub (file git-compat-util.h) might be relevant:
https://github.com/msysgit/git/commit/435bdf8c7ffa493f8f6f2e8f329f8cc22db16ce6#commitcomment-2407194
The change suggested there (to remove an inclusion of windows.h in
git-compat-util.h) might simplify the solution a little. Might even
remove the need for auto-configuration in Makefile (worked for me).
^ permalink raw reply
* Re: [PATCH] cvsimport: rewrite to use cvsps 3.x to fix major bugs
From: Junio C Hamano @ 2013-01-11 19:27 UTC (permalink / raw)
To: esr; +Cc: git
In-Reply-To: <20130111185818.GA30398@thyrsus.com>
"Eric S. Raymond" <esr@thyrsus.com> writes:
> Junio C Hamano <gitster@pobox.com>:
> ...
> The other is a design-level problem - these options were a bad idea to
> begin with. In earlier list mail I said
>
> An example of the batchiness mistake close to home is the -m and -M
> options in the old version of cvsimport. It takes human judgment
> looking at the whole commit DAG in gitspace to decide what merge
> points would best express the (as you say, sometimes ambiguous) CVS
> history - what's needed is a scalpel and sutures in a surgeon's hand,
> not a regexp hammer.
>
> One specific problem with the regexp hammer is false-positive matches
> leading to unintended merges.
Yeah, it is OK to _discourage_ its use, but to me it looks like that
the above is a fairly subjective policy decision, not something I
should let you impose on the users of the old cvsimport, which you
do not seem to even treat as your users.
>> Having the code to die when it sees options the rewritten version
>> does not yet support before it calls the fallback makes the fallback
>> much less effective, no?
>
> Only to the extent that -o/-m/-M are really important, which I doubt.
> But that might be fixable, and I'll put it on the to-do list.
>
>> Not very impressed (yet). The advertised "fix major bugs" sounds
>> more like "trade major bugs with different ones with a couple of
>> feature removals" at this point.
>
> If you think that, you have failed to understand just how broken and
> dangerous the old combination is. None of the details you've called
> out are "major" by any stretch of the imagination compared to it
> silently botching the translation of repositories.
The "major" in my sentence was from your description (the bugs you
fixed), and not about the new ones you still have in this draft. I
did not mean to say that you are trading fixes to "major" bugs with
different "major" bugs.
Insecure quoting of parameters is much easier to fix; it does need
to be addressed, though.
It is just that looking at the state of the patch as submitted left
me with a feeling that this topic needs a lot more time to mature
than I previously was led to believe by your earlier messages, which
made me someaht sad.
^ permalink raw reply
* Re: [PATCH] cvsimport: rewrite to use cvsps 3.x to fix major bugs
From: Junio C Hamano @ 2013-01-11 19:17 UTC (permalink / raw)
To: esr; +Cc: git
In-Reply-To: <20130111185818.GA30398@thyrsus.com>
"Eric S. Raymond" <esr@thyrsus.com> writes:
> Junio C Hamano <gitster@pobox.com>:
>> I think the prevalent style in this script is to write "print"
>> without parentheses:
>>
>> print STDERR "msg\n";
>
> That can be easily fixed.
>
>> This looks lazy and unsafe quoting. Is there anything that makes
>> sure repository path does not contain a single quote?
>
> No. But...wait, checking...the Perl code didn't have the analogous
> check, so there's no increased vulnerability here. I'll put it on the
> to-do list for after I ship parsecvs.
I checked before I sent that review, and as far as I could tell, it
was fairly consistently avoiding the lazy and insecure forms, e.g.
system("com mand " . $param);
open($fh, "com mand " . $param . " |"); while (<$fh>) { ... }
but used the more sequre list form, e.g.
system(qw(com mand), $param);
open($fh, "-|", qw(com mand), $param); while (<$fh>) { ... }
But of course there may be some places that were careless that I
didn't spot (and previous reviewers of the current cvsimport
didn't).
^ permalink raw reply
* Re: parsecvs has been salvaged
From: Eric S. Raymond @ 2013-01-11 19:02 UTC (permalink / raw)
To: Bart Massey; +Cc: git, Keith Packard
In-Reply-To: <CAA6gtpnDrVOfiX-bQFS2X91wsS705b60YST8DwuDaibjkYU9vg@mail.gmail.com>
Bart Massey <bart@cs.pdx.edu>:
> Very cool! I'm glad you got it doing what you wanted; I'll be
> interested to see how parsecvs compares in quality and performance to
> cvs2git and cvsps. --Bart
And now it has that -R option and correctly interprets the timezone field.
(I've been busy this morning.) I'm working on the no-commitids warning now.
Oh, and it now has...actual documentation, too. :-)
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* Re: [PATCH] cvsimport: rewrite to use cvsps 3.x to fix major bugs
From: Eric S. Raymond @ 2013-01-11 18:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7va9sfd6lk.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com>:
> I think the prevalent style in this script is to write "print"
> without parentheses:
>
> print STDERR "msg\n";
That can be easily fixed.
> This looks lazy and unsafe quoting. Is there anything that makes
> sure repository path does not contain a single quote?
No. But...wait, checking...the Perl code didn't have the analogous
check, so there's no increased vulnerability here. I'll put it on the
to-do list for after I ship parsecvs.
> > + def command(self):
> > + "Emit the command implied by all previous options."
> > + return "(cvs2git --username=git-cvsimport --quiet --quiet --blobfile={0} --dumpfile={1} {2} {3} && cat {0} {1} && rm {0} {1})".format(tempfile.mkstemp()[1], tempfile.mkstemp()[1], self.opts, self.modulepath)
>
> Could we do something better with this overlong source line?
Yes. The correct fix is to simplify cvs2git's rather baroque command-line
interface. Michael Haggerty has accepted that patch. Soon that line will
look like this:
return "cvs2git --quiet --quiet {0} {1}".format(self.opts, self.modulepath)
Older versions of cvs2git will terminate cleanly with an error message
when called this way.
> > + elif opt == '-o':
> > + sys.stderr.write("git cvsimport: -o is no longer supported.\n")
> > + sys.exit(1)
>
> Isn't this a regression?
It would be if the -o behavior were consistent and decently
documented. When I tested this option with the Perl version I got no
result. Possibly my usage was incorrect; if anyone can be found who
actually understands how it's supposed to work in detail and will tell
me, I can probably support it.
> > + elif opt in ('-m', '-M'):
> > + sys.stderr.write("git cvsimport: -m and -M are no longer supported: use reposurgeon instead.\n")
> > + sys.exit(1)
>
> I wonder if it is better to ignore these options with a warning but
> still let the command continue; cvsps-3.x was supposed to get merges
> right without the help of these ad-hoc options, no?
Sorry, I don't know where you got that idea. I don't think the general merge
detection that would need is possible even in principle.
> Otherwise it looks like a regression to me.
There are two reasons -m and -M aren't supported.
One is implementation-level. The wrapper script no longer deals with
individual files or changesets or branches; it relies on the
conversion engine to do all that. (As it should - the old design was
a mess with lots of stuff being done at the wrong level.) But the
conversion engines don't implement -m or -M, and aren't ever going to
(see next paragraph).
The other is a design-level problem - these options were a bad idea to
begin with. In earlier list mail I said
An example of the batchiness mistake close to home is the -m and -M
options in the old version of cvsimport. It takes human judgment
looking at the whole commit DAG in gitspace to decide what merge
points would best express the (as you say, sometimes ambiguous) CVS
history - what's needed is a scalpel and sutures in a surgeon's hand,
not a regexp hammer.
One specific problem with the regexp hammer is false-positive matches
leading to unintended merges.
That's why I won't implement these in cvsps or parsecvs. Instead I've
just added DAG visualization via graphviz in reposurgeon, so a human
can quickly see candidate merges in the visualization and do them by
hand. This is better and safer.
> Having the code to die when it sees options the rewritten version
> does not yet support before it calls the fallback makes the fallback
> much less effective, no?
Only to the extent that -o/-m/-M are really important, which I doubt.
But that might be fixable, and I'll put it on the to-do list.
> Not very impressed (yet). The advertised "fix major bugs" sounds
> more like "trade major bugs with different ones with a couple of
> feature removals" at this point.
If you think that, you have failed to understand just how broken and
dangerous the old combination is. None of the details you've called
out are "major" by any stretch of the imagination compared to it
silently botching the translation of repositories.
Also bear in mind that leaving the old Perl code in place is not going
to be a viable option for more than a few months out. As cvsps-3.x
propagates to the distros what you have is going to stop even its
current pretense of working.
Finally...my own purposes are fulfilled by having CVS exporters that can
do a decent job of front-ending for reposurgeon. Rewriting git's
wrapper script was extra work that I took on only because I wanted to
be friendly to the git project, *but*...
...there is a limit to the amount of what I consider pointless
hoop-jumping that friendliness will buy you, and the 2.x fallback eas
already pushing that limit. Tread a little more gently, Junio; I've
put in a lot of hard, boring work on git-cvsimport over the last two
weeks when I would rather have been doing other things, and my
patience for being nit-picked without appreciation or reward has a
correspondingly low limit. We'll both be happier if you don't reach
it.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* Re: git send-email should not allow 'y' for in-reply-to
From: Jeff King @ 2013-01-11 18:54 UTC (permalink / raw)
To: Hilco Wijbenga; +Cc: Eric Blake, git, libvir-list
In-Reply-To: <CAE1pOi0zc+d6d9Y4KViX24qHgc1WL9atmRuyygorX_DQMj69Hg@mail.gmail.com>
On Fri, Jan 11, 2013 at 10:43:39AM -0800, Hilco Wijbenga wrote:
> > People answer 'y' to "Who should the emails appear to be from?" and
> > 'n' to "Message-ID to be used as In-Reply-To for the first email?"
> > for some unknown reason. While it is possible that your local
> > username really is "y" and you are sending the mail to your local
> > colleagues, it is possible, and some might even say it is likely,
> > that it is a user error.
>
> I have never used Git's email support so this doesn't affect me one
> way or another but it seems that checking the results is fixing the
> symptoms, not the problem? I apologize if this was already discussed
> but I couldn't find such a discussion.
It depends on who you are. If you are the person running send-email,
then the symptom is your confusion. If you are somebody else, the
symptom is somebody else sending out a bogus email. That patch fixes
only the latter. :)
More seriously, I agree that re-wording the question is a reasonable
thing to do. I do not use send-email, either, so I don't have a strong
opinion on it. The suggestions you made:
> How about "What Message-ID to use as In-Reply-To for the first email?"
> or "Provide the Message-ID to use as In-Reply-To for the first
> email:".
seem fine to me. Maybe somebody who has been confused by it can offer
more. At any rate, patches welcome.
-Peff
^ permalink raw reply
* [PATCH v5] git-completion.bash: add support for path completion
From: Manlio Perillo @ 2013-01-11 18:48 UTC (permalink / raw)
To: git; +Cc: gitster, szeder, felipe.contreras, peff, Manlio Perillo
The git-completion.bash script did not implemented full, git aware,
support to complete paths, for git commands that operate on files within
the current working directory or the index.
As an example:
git add <TAB>
will suggest all files in the current working directory, including
ignored files and files that have not been modified.
Support path completion, for git commands where the non-option arguments
always refer to paths within the current working directory or the index,
as follows:
* the path completion for the "git rm" and "git ls-files"
commands will suggest all cached files.
* the path completion for the "git add" command will suggest all
untracked and modified files. Ignored files are excluded.
* the path completion for the "git clean" command will suggest all
untracked files. Ignored files are excluded.
* the path completion for the "git mv" command will suggest all cached
files when expanding the first argument, and all untracked and cached
files for subsequent arguments. In the latter case, empty directories
are included and ignored files are excluded.
* the path completion for the "git commit" command will suggest all
files that have been modified from the HEAD, if HEAD exists, otherwise
it will suggest all cached files.
For all affected commands, completion will always stop at directory
boundary. Only standard ignored files are excluded, using the
--exclude-standard option of the ls-files command.
When using a recent Bash version, Git path completion will be the same
as builtin file completion, e.g.
git add contrib/
will suggest relative file names.
Signed-off-by: Manlio Perillo <manlio.perillo@gmail.com>
---
Changes:
* Applied Junio patch to fix completion inside a subdirectory.
* Quoted the hopefully last incorrectly unquoted variable.
* Fixed coding style (removed stdout file descriptor in shell
redirection, since it is redundant).
* Fixed regression in path completion, when using non canonicalized
or absolute path names.
The problem has been solved making sure to chdir to the specified
directory before executing ls-files and diff-index commands.
The only issue is that there is no tilde expansion, but this is
harmless, since default bash completion will be used (the old
behaviour).
* Improved path completion when the new compopt builtin is available
(Bash >= 4.x).
Now git paths completion is done in exactly the same way as Bash
builtin filenames completion.
* Updated the zsh compatibility code to use the improved path
completion support
* Fixed incorrect git mv arguments count used to check the first
path to be renamed.
When options are used (unless they are git main options), -- is
required to separate options from non options arguments.
It is harmless to not use --; in this case bash will suggest
untracked files and directories for the first argument.
XXX: should I add this implementation note in the commit message?
* Make sure to sort ls-files and diff-index filtered output before
removing duplicate directories.
* Merged master.
Please note that before merging this patch in next, we need to update the
zsh and tcsh completion scripts.
I have the changes ready, but I will post them later since both scripts
needs more patches (I have posted an informal patch for zsh, and changes
to tcsh should be in pu, but I need to test them).
contrib/completion/git-completion.bash | 250 ++++++++++++++++++++++++++++++---
1 file changed, 234 insertions(+), 16 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index a4c48e1..51b8b3b 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -13,6 +13,7 @@
# *) .git/remotes file names
# *) git 'subcommands'
# *) tree paths within 'ref:path/to/file' expressions
+# *) file paths within current working directory and index
# *) common --long-options
#
# To use these routines:
@@ -233,6 +234,118 @@ __gitcomp_nl ()
COMPREPLY=($(compgen -P "${2-}" -S "${4- }" -W "$1" -- "${3-$cur}"))
}
+# Generates completion reply with compgen from newline-separated possible
+# completion filenames.
+# It accepts 1 to 3 arguments:
+# 1: List of possible completion filenames, separated by a single newline.
+# 2: A directory prefix to be added to each possible completion filename
+# (optional).
+# 3: Generate possible completion matches for this word (optional).
+__gitcomp_file ()
+{
+ local IFS=$'\n'
+
+ # XXX does not work when the directory prefix contains a tilde,
+ # since tilde expansion is not applied.
+ # This means that COMPREPLY will be empty and Bash default
+ # completion will be used.
+ COMPREPLY=($(compgen -P "${2-}" -W "$1" -- "${3-$cur}"))
+
+ # Tell Bash that compspec generates filenames.
+ compopt -o filenames 2>/dev/null
+}
+
+__git_index_file_list_filter_compat ()
+{
+ local path
+
+ while read -r path; do
+ case "$path" in
+ ?*/*) echo "${path%%/*}/" ;;
+ *) echo "$path" ;;
+ esac
+ done
+}
+
+__git_index_file_list_filter_bash ()
+{
+ local path
+
+ while read -r path; do
+ case "$path" in
+ ?*/*)
+ # XXX if we append a slash to directory names when using
+ # `compopt -o filenames`, Bash will append another slash.
+ # This is pretty stupid, and this the reason why we have to
+ # define a compatible version for this function.
+ echo "${path%%/*}" ;;
+ *)
+ echo "$path" ;;
+ esac
+ done
+}
+
+# Process path list returned by "ls-files" and "diff-index --name-only"
+# commands, in order to list only file names relative to a specified
+# directory, and append a slash to directory names.
+__git_index_file_list_filter ()
+{
+ # Default to Bash >= 4.x
+ __git_index_file_list_filter_bash
+}
+
+# Execute git ls-files, returning paths relative to the directory
+# specified in the first argument, and using the options specified in
+# the second argument.
+__git_ls_files_helper ()
+{
+ # NOTE: $2 is not quoted in order to support multiple options
+ cd "$1" && git ls-files --exclude-standard $2
+} 2>/dev/null
+
+
+# Execute git diff-index, returning paths relative to the directory
+# specified in the first argument, and using the tree object id
+# specified in the second argument.
+__git_diff_index_helper ()
+{
+ cd "$1" && git diff-index --name-only --relative "$2"
+} 2>/dev/null
+
+# __git_index_files accepts 1 or 2 arguments:
+# 1: Options to pass to ls-files (required).
+# Supported options are --cached, --modified, --deleted, --others,
+# and --directory.
+# 2: A directory path (optional).
+# If provided, only files within the specified directory are listed.
+# Sub directories are never recursed. Path must have a trailing
+# slash.
+__git_index_files ()
+{
+ local dir="$(__gitdir)" root="${2-.}"
+
+ if [ -d "$dir" ]; then
+ __git_ls_files_helper "$root" "$1" | __git_index_file_list_filter |
+ sort | uniq
+ fi
+}
+
+# __git_diff_index_files accepts 1 or 2 arguments:
+# 1) The id of a tree object.
+# 2) A directory path (optional).
+# If provided, only files within the specified directory are listed.
+# Sub directories are never recursed. Path must have a trailing
+# slash.
+__git_diff_index_files ()
+{
+ local dir="$(__gitdir)" root="${2-.}"
+
+ if [ -d "$dir" ]; then
+ __git_diff_index_helper "$root" "$1" | __git_index_file_list_filter |
+ sort | uniq
+ fi
+}
+
__git_heads ()
{
local dir="$(__gitdir)"
@@ -430,6 +543,46 @@ __git_complete_revlist_file ()
}
+# __git_complete_index_file requires 1 argument: the options to pass to
+# ls-file
+__git_complete_index_file ()
+{
+ local pfx cur_="$cur"
+
+ case "$cur_" in
+ ?*/*)
+ pfx="${cur_%/*}"
+ cur_="${cur_##*/}"
+ pfx="${pfx}/"
+
+ __gitcomp_file "$(__git_index_files "$1" "$pfx")" "$pfx" "$cur_"
+ ;;
+ *)
+ __gitcomp_file "$(__git_index_files "$1")" "" "$cur_"
+ ;;
+ esac
+}
+
+# __git_complete_diff_index_file requires 1 argument: the id of a tree
+# object
+__git_complete_diff_index_file ()
+{
+ local pfx cur_="$cur"
+
+ case "$cur_" in
+ ?*/*)
+ pfx="${cur_%/*}"
+ cur_="${cur_##*/}"
+ pfx="${pfx}/"
+
+ __gitcomp_file "$(__git_diff_index_files "$1" "$pfx")" "$pfx" "$cur_"
+ ;;
+ *)
+ __gitcomp_file "$(__git_diff_index_files "$1")" "" "$cur_"
+ ;;
+ esac
+}
+
__git_complete_file ()
{
__git_complete_revlist_file
@@ -722,6 +875,43 @@ __git_has_doubledash ()
return 1
}
+# Try to count non option arguments passed on the command line for the
+# specified git command.
+# When options are used, it is necessary to use the special -- option to
+# tell the implementation were non option arguments begin.
+# XXX this can not be improved, since options can appear everywhere, as
+# an example:
+# git mv x -n y
+#
+# __git_count_arguments requires 1 argument: the git command executed.
+__git_count_arguments ()
+{
+ local word i c=0
+
+ # Skip "git" (first argument)
+ for ((i=1; i < ${#words[@]}; i++)); do
+ word="${words[i]}"
+
+ case "$word" in
+ --)
+ # Good; we can assume that the following are only non
+ # option arguments.
+ ((c = 0))
+ ;;
+ "$1")
+ # Skip the specified git command and discard git
+ # main options
+ ((c = 0))
+ ;;
+ ?*)
+ ((c++))
+ ;;
+ esac
+ done
+
+ printf "%d" $c
+}
+
__git_whitespacelist="nowarn warn error error-all fix"
_git_am ()
@@ -770,8 +960,6 @@ _git_apply ()
_git_add ()
{
- __git_has_doubledash && return
-
case "$cur" in
--*)
__gitcomp "
@@ -780,7 +968,9 @@ _git_add ()
"
return
esac
- COMPREPLY=()
+
+ # XXX should we check for --update and --all options ?
+ __git_complete_index_file "--others --modified"
}
_git_archive ()
@@ -930,15 +1120,15 @@ _git_cherry_pick ()
_git_clean ()
{
- __git_has_doubledash && return
-
case "$cur" in
--*)
__gitcomp "--dry-run --quiet"
return
;;
esac
- COMPREPLY=()
+
+ # XXX should we check for -x option ?
+ __git_complete_index_file "--others"
}
_git_clone ()
@@ -969,8 +1159,6 @@ _git_clone ()
_git_commit ()
{
- __git_has_doubledash && return
-
case "$prev" in
-c|-C)
__gitcomp_nl "$(__git_refs)" "" "${cur}"
@@ -1005,7 +1193,13 @@ _git_commit ()
"
return
esac
- COMPREPLY=()
+
+ if git rev-parse --verify --quiet HEAD >/dev/null; then
+ __git_complete_diff_index_file "HEAD"
+ else
+ # This is the first commit
+ __git_complete_index_file "--cached"
+ fi
}
_git_describe ()
@@ -1223,8 +1417,6 @@ _git_init ()
_git_ls_files ()
{
- __git_has_doubledash && return
-
case "$cur" in
--*)
__gitcomp "--cached --deleted --modified --others --ignored
@@ -1237,7 +1429,10 @@ _git_ls_files ()
return
;;
esac
- COMPREPLY=()
+
+ # XXX ignore options like --modified and always suggest all cached
+ # files.
+ __git_complete_index_file "--cached"
}
_git_ls_remote ()
@@ -1369,7 +1564,14 @@ _git_mv ()
return
;;
esac
- COMPREPLY=()
+
+ if [ $(__git_count_arguments "mv") -gt 0 ]; then
+ # We need to show both cached and untracked files (including
+ # empty directories) since this may not be the last argument.
+ __git_complete_index_file "--cached --others --directory"
+ else
+ __git_complete_index_file "--cached"
+ fi
}
_git_name_rev ()
@@ -2075,15 +2277,14 @@ _git_revert ()
_git_rm ()
{
- __git_has_doubledash && return
-
case "$cur" in
--*)
__gitcomp "--cached --dry-run --ignore-unmatch --quiet"
return
;;
esac
- COMPREPLY=()
+
+ __git_complete_index_file "--cached"
}
_git_shortlog ()
@@ -2448,6 +2649,15 @@ if [[ -n ${ZSH_VERSION-} ]]; then
compadd -Q -S "${4- }" -p "${2-}" -- ${=1} && _ret=0
}
+ __gitcomp_file ()
+ {
+ emulate -L zsh
+
+ local IFS=$'\n'
+ compset -P '*[=:]'
+ compadd -Q -p "${2-}" -f -- ${=1} && _ret=0
+ }
+
__git_zsh_helper ()
{
emulate -L ksh
@@ -2469,6 +2679,14 @@ if [[ -n ${ZSH_VERSION-} ]]; then
compdef _git git gitk
return
+elif [[ -n ${BASH_VERSION-} ]]; then
+ if ((${BASH_VERSINFO[0]} < 4)); then
+ # compopt is not supported
+ __git_index_file_list_filter ()
+ {
+ __git_index_file_list_filter_compat
+ }
+ fi
fi
__git_func_wrap ()
--
1.8.1.rc1.31.ga3c84da
^ permalink raw reply related
* Re: git send-email should not allow 'y' for in-reply-to
From: Hilco Wijbenga @ 2013-01-11 18:43 UTC (permalink / raw)
To: Jeff King; +Cc: Eric Blake, git, libvir-list
In-Reply-To: <20130111164730.GA7921@sigill.intra.peff.net>
On 11 January 2013 08:47, Jeff King <peff@peff.net> wrote:
> On Fri, Jan 11, 2013 at 09:39:06AM -0700, Eric Blake wrote:
>
>> > Please don't answer "y" when git send email shows the following prompt:
>> >
>> > "Message-ID to be used as In-Reply-To for the first email?"
>> >
>> > you should respond with a message ID there. Unfortunately we have a
>> > growing thread that contains submissions with this mistake.
<snip/>
> People answer 'y' to "Who should the emails appear to be from?" and
> 'n' to "Message-ID to be used as In-Reply-To for the first email?"
> for some unknown reason. While it is possible that your local
> username really is "y" and you are sending the mail to your local
> colleagues, it is possible, and some might even say it is likely,
> that it is a user error.
I have never used Git's email support so this doesn't affect me one
way or another but it seems that checking the results is fixing the
symptoms, not the problem? I apologize if this was already discussed
but I couldn't find such a discussion.
I was wondering if it might be a better idea to change the wording of
the questions if they have proven so confusing? The first time (just
now) that I read "Message-ID to be used as In-Reply-To for the first
email?", it clearly seemed like a yes/no question to me. :-)
How about "What Message-ID to use as In-Reply-To for the first email?"
or "Provide the Message-ID to use as In-Reply-To for the first
email:". I'm a little surprised that "Who should the emails appear to
be from?" would be interpreted as a yes/no question but we could
rephrase that similarly as "Provide the name of the email sender:" (I
don't really like this particular version but you get the idea).
^ 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