* [PATCH 0/3] completion: trivial cleanups
From: Felipe Contreras @ 2012-01-29 23:41 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras
And an improvement for zsh.
Felipe Contreras (3):
completion: be nicer with zsh
completion: remove old code
completion: remove unused code
contrib/completion/git-completion.bash | 47 +++++---------------------------
1 files changed, 7 insertions(+), 40 deletions(-)
--
1.7.8.3
^ permalink raw reply
* [PATCH 1/3] completion: be nicer with zsh
From: Felipe Contreras @ 2012-01-29 23:41 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras
In-Reply-To: <1327880479-25275-1-git-send-email-felipe.contreras@gmail.com>
And yet another bug in zsh[1] causes a mismatch; zsh seems to have
problem emulating wordspliting, but only when the ':' command is
involved.
Let's avoid it. This has the advantage that the code is now actually
understandable (at least to me), while before it looked like voodoo.
I found this issue because __git_compute_porcelain_commands listed all
commands (not only porcelain).
[1] http://article.gmane.org/gmane.comp.shells.zsh.devel/24296
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
contrib/completion/git-completion.bash | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 1496c6d..7051c7a 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -676,7 +676,8 @@ __git_merge_strategies=
# is needed.
__git_compute_merge_strategies ()
{
- : ${__git_merge_strategies:=$(__git_list_merge_strategies)}
+ test "$__git_merge_strategies" && return
+ __git_merge_strategies=$(__git_list_merge_strategies 2> /dev/null)
}
__git_complete_revlist_file ()
@@ -854,7 +855,8 @@ __git_list_all_commands ()
__git_all_commands=
__git_compute_all_commands ()
{
- : ${__git_all_commands:=$(__git_list_all_commands)}
+ test "$__git_all_commands" && return
+ __git_all_commands=$(__git_list_all_commands 2> /dev/null)
}
__git_list_porcelain_commands ()
@@ -947,7 +949,8 @@ __git_porcelain_commands=
__git_compute_porcelain_commands ()
{
__git_compute_all_commands
- : ${__git_porcelain_commands:=$(__git_list_porcelain_commands)}
+ test "$__git_porcelain_commands" && return
+ __git_porcelain_commands=$(__git_list_porcelain_commands 2> /dev/null)
}
__git_pretty_aliases ()
--
1.7.8.3
^ permalink raw reply related
* [PATCH 2/3] completion: remove old code
From: Felipe Contreras @ 2012-01-29 23:41 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras
In-Reply-To: <1327880479-25275-1-git-send-email-felipe.contreras@gmail.com>
We don't need to check for GIT_DIR/remotes, right? This was removed long
time ago.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
contrib/completion/git-completion.bash | 8 +-------
1 files changed, 1 insertions(+), 7 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 7051c7a..f7278b5 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -643,13 +643,7 @@ __git_refs_remotes ()
__git_remotes ()
{
- local i ngoff IFS=$'\n' d="$(__gitdir)"
- __git_shopt -q nullglob || ngoff=1
- __git_shopt -s nullglob
- for i in "$d/remotes"/*; do
- echo ${i#$d/remotes/}
- done
- [ "$ngoff" ] && __git_shopt -u nullglob
+ local i IFS=$'\n' d="$(__gitdir)"
for i in $(git --git-dir="$d" config --get-regexp 'remote\..*\.url' 2>/dev/null); do
i="${i#remote.}"
echo "${i/.url*/}"
--
1.7.8.3
^ permalink raw reply related
* [PATCH 3/3] completion: remove unused code
From: Felipe Contreras @ 2012-01-29 23:41 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras
In-Reply-To: <1327880479-25275-1-git-send-email-felipe.contreras@gmail.com>
No need for thus rather complicated piece of code :)
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
contrib/completion/git-completion.bash | 30 ------------------------------
1 files changed, 0 insertions(+), 30 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index f7278b5..59a4650 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -2730,33 +2730,3 @@ if [ Cygwin = "$(uname -o 2>/dev/null)" ]; then
complete -o bashdefault -o default -o nospace -F _git git.exe 2>/dev/null \
|| complete -o default -o nospace -F _git git.exe
fi
-
-if [[ -n ${ZSH_VERSION-} ]]; then
- __git_shopt () {
- local option
- if [ $# -ne 2 ]; then
- echo "USAGE: $0 (-q|-s|-u) <option>" >&2
- return 1
- fi
- case "$2" in
- nullglob)
- option="$2"
- ;;
- *)
- echo "$0: invalid option: $2" >&2
- return 1
- esac
- case "$1" in
- -q) setopt | grep -q "$option" ;;
- -u) unsetopt "$option" ;;
- -s) setopt "$option" ;;
- *)
- echo "$0: invalid flag: $1" >&2
- return 1
- esac
- }
-else
- __git_shopt () {
- shopt "$@"
- }
-fi
--
1.7.8.3
^ permalink raw reply related
* What's cooking in git.git (Jan 2012, #07; Sun, 29)
From: Junio C Hamano @ 2012-01-29 23:48 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 promised in the recent couple of issues of "What's cooking", the first
batch of topics that have been cooking in 'next' are now in 'master'. The
tip of 'next' hasn't been rewound yet, but it soon will after the second
batch of topics graduate.
Here are the repositories that have my integration branches:
With maint, master, next, pu, todo:
git://git.kernel.org/pub/scm/git/git.git
git://repo.or.cz/alt-git.git
https://code.google.com/p/git-core/
https://github.com/git/git
With only maint and master:
git://git.sourceforge.jp/gitroot/git-core/git.git
git://git-core.git.sourceforge.net/gitroot/git-core/git-core
With all the topics and integration branches:
https://github.com/gitster/git
The preformatted documentation in HTML and man format are found in:
git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
git://repo.or.cz/git-{htmldocs,manpages}.git/
https://code.google.com/p/git-{htmldocs,manpages}.git/
https://github.com/gitster/git-{htmldocs,manpages}.git/
--------------------------------------------------
[New Topics]
* bl/gitweb-project-filter (2012-01-29) 2 commits
- gitweb: place links to parent directories in page header
- gitweb: add project_filter to limit project list to a subdirectory
* rt/completion-branch-edit-desc (2012-01-29) 1 commit
- completion: --edit-description option for git-branch
--------------------------------------------------
[Graduated to "master"]
* cb/git-daemon-tests (2012-01-08) 5 commits
(merged to 'next' on 2012-01-08 at 1db8351)
+ git-daemon tests: wait until daemon is ready
+ git-daemon: produce output when ready
+ git-daemon: add tests
+ dashed externals: kill children on exit
+ run-command: optionally kill children on exit
* cb/push-quiet (2012-01-08) 3 commits
(merged to 'next' on 2012-01-20 at 4326dda)
+ t5541: avoid TAP test miscounting
+ fix push --quiet: add 'quiet' capability to receive-pack
+ server_supports(): parse feature list more carefully
* jc/maint-log-first-parent-pathspec (2012-01-19) 1 commit
(merged to 'next' on 2012-01-20 at fb2b35f)
+ Making pathspec limited log play nicer with --first-parent
* jk/parse-object-cached (2012-01-06) 3 commits
(merged to 'next' on 2012-01-08 at 8c6fa4a)
+ upload-pack: avoid parsing tag destinations
+ upload-pack: avoid parsing objects during ref advertisement
+ parse_object: try internal cache before reading object db
These are a bit scary changes, but I do think they are worth doing.
* jl/test-pause (2012-01-17) 1 commit
(merged to 'next' on 2012-01-20 at ee56335)
+ test-lib: add the test_pause convenience function
* jn/gitweb-unspecified-action (2012-01-09) 1 commit
(merged to 'next' on 2012-01-20 at 2b31714)
+ gitweb: Fix actionless dispatch for non-existent objects
* mh/ref-clone-without-extra-refs (2012-01-17) 4 commits
(merged to 'next' on 2012-01-20 at 2e9645e)
+ write_remote_refs(): create packed (rather than extra) refs
+ add_packed_ref(): new function in the refs API.
+ ref_array: keep track of whether references are sorted
+ pack_refs(): remove redundant check
Looked reasonable; will hopefully help making mh/ref-api-rest simpler and
cleaner.
* nd/clone-single-branch (2012-01-08) 1 commit
(merged to 'next' on 2012-01-09 at 6c3c759)
+ clone: add --single-branch to fetch only one branch
(this branch is used by nd/clone-detached.)
* nd/index-pack-no-recurse (2012-01-16) 3 commits
(merged to 'next' on 2012-01-20 at d1e964e)
+ index-pack: eliminate unlimited recursion in get_base_data()
+ index-pack: eliminate recursion in find_unresolved_deltas
+ Eliminate recursion in setting/clearing marks in commit list
* nd/maint-refname-in-hierarchy-check (2012-01-11) 1 commit
(merged to 'next' on 2012-01-20 at acb5611)
+ Fix incorrect ref namespace check
* pw/p4-view-updates (2012-01-11) 5 commits
(merged to 'next' on 2012-01-20 at 8ca2c7b)
+ git-p4: add tests demonstrating spec overlay ambiguities
+ git-p4: adjust test to adhere to stricter useClientSpec
+ git-p4: clarify comment
+ git-p4: fix verbose comment typo
+ git-p4: only a single ... wildcard is supported
* rs/diff-postimage-in-context (2012-01-06) 1 commit
(merged to 'next' on 2012-01-09 at 9635032)
+ xdiff: print post-image for common records instead of pre-image
* sp/smart-http-failure-to-push (2012-01-20) 1 commit
(merged to 'next' on 2012-01-20 at a892434)
+ remote-curl: Fix push status report when all branches fail
* tr/maint-mailinfo (2012-01-16) 2 commits
(merged to 'next' on 2012-01-20 at 278fae1)
+ mailinfo: with -b, keep space after [foo]
+ am: learn passing -b to mailinfo
--------------------------------------------------
[Stalled]
* jc/advise-push-default (2011-12-18) 1 commit
- push: hint to use push.default=upstream when appropriate
Peff had a good suggestion outlining an updated code structure so that
somebody new can try to dip his or her toes in the development. Any
takers?
Waiting for a reroll.
* ss/git-svn-prompt-sans-terminal (2012-01-04) 3 commits
- fixup! 15eaaf4
- git-svn, perl/Git.pm: extend Git::prompt helper for querying users
(merged to 'next' on 2012-01-05 at 954f125)
+ perl/Git.pm: "prompt" helper to honor GIT_ASKPASS and SSH_ASKPASS
The bottom one has been replaced with a rewrite based on comments from
Ævar. The second one needs more work, both in perl/Git.pm and prompt.c, to
give precedence to tty over SSH_ASKPASS when terminal is available.
Will defer till the next cycle.
* nd/commit-ignore-i-t-a (2012-01-16) 2 commits
- commit, write-tree: allow to ignore CE_INTENT_TO_ADD while writing trees
- cache-tree: update API to take abitrary flags
May want to consider this as fixing an earlier UI mistake, and not as a
feature that devides the userbase.
Will defer till the next cycle.
--------------------------------------------------
[Cooking]
* jl/submodule-re-add (2012-01-24) 1 commit
(merged to 'next' on 2012-01-26 at 482553e)
+ submodule add: fix breakage when re-adding a deep submodule
"git submodule add" forgot to recompute the name to be stored in .gitmodules
when the module was once added to the superproject and already initialized.
Will merge to 'master' in the second batch.
* jn/svn-fe (2012-01-27) 44 commits
(merged to 'next' on 2012-01-29 at 001a395)
+ vcs-svn/svndiff.c: squelch false "unused" warning from gcc
+ Merge branch 'svn-fe' of git://repo.or.cz/git/jrn into jn/svn-fe
+ vcs-svn: reset first_commit_done in fast_export_init
+ Merge branch 'db/text-delta' into svn-fe
+ vcs-svn: do not initialize report_buffer twice
+ Merge branch 'db/text-delta' into svn-fe
+ vcs-svn: avoid hangs from corrupt deltas
+ vcs-svn: guard against overflow when computing preimage length
+ Merge branch 'db/delta-applier' into db/text-delta
+ vcs-svn: implement text-delta handling
+ Merge branch 'db/delta-applier' into db/text-delta
+ Merge branch 'db/delta-applier' into svn-fe
+ vcs-svn: cap number of bytes read from sliding view
+ test-svn-fe: split off "test-svn-fe -d" into a separate function
+ vcs-svn: let deltas use data from preimage
+ vcs-svn: let deltas use data from postimage
+ vcs-svn: verify that deltas consume all inline data
+ vcs-svn: implement copyfrom_data delta instruction
+ vcs-svn: read instructions from deltas
+ vcs-svn: read inline data from deltas
+ vcs-svn: read the preimage when applying deltas
+ vcs-svn: parse svndiff0 window header
+ vcs-svn: skeleton of an svn delta parser
+ vcs-svn: make buffer_read_binary API more convenient
+ vcs-svn: learn to maintain a sliding view of a file
+ Makefile: list one vcs-svn/xdiff object or header per line
+ Merge branch 'db/svn-fe-code-purge' into svn-fe
+ vcs-svn: drop obj_pool
+ vcs-svn: drop treap
+ vcs-svn: drop string_pool
+ vcs-svn: pass paths through to fast-import
+ Merge branch 'db/strbufs-for-metadata' into db/svn-fe-code-purge
+ Merge branch 'db/length-as-hash' (early part) into db/svn-fe-code-purge
+ Merge branch 'db/vcs-svn-incremental' into svn-fe
+ vcs-svn: avoid using ls command twice
+ vcs-svn: use mark from previous import for parent commit
+ vcs-svn: handle filenames with dq correctly
+ vcs-svn: quote paths correctly for ls command
+ vcs-svn: eliminate repo_tree structure
+ vcs-svn: add a comment before each commit
+ vcs-svn: save marks for imported commits
+ vcs-svn: use higher mark numbers for blobs
+ vcs-svn: set up channel to read fast-import cat-blob response
+ Merge commit 'v1.7.5' into svn-fe
"vcs-svn"/"svn-fe" learned to read dumps with svn-deltas and support
incremental imports.
Will merge to 'master' in the second batch.
* jc/split-blob (2012-01-24) 6 commits
- chunked-object: streaming checkout
- chunked-object: fallback checkout codepaths
- bulk-checkin: support chunked-object encoding
- bulk-checkin: allow the same data to be multiply hashed
- new representation types in the packstream
- varint-in-pack: refactor varint encoding/decoding
Not ready.
I finished the streaming checkout codepath, but as explained in 127b177
(bulk-checkin: support chunked-object encoding, 2011-11-30), these are
still early steps of a long and painful journey. At least pack-objects and
fsck need to learn the new encoding for the series to be usable locally,
and then index-pack/unpack-objects needs to learn it to be used remotely.
Given that I heard a lot of noise that people want large files, and that I
was asked by somebody at GitTogether'11 privately for an advice on how to
pay developers (not me) to help adding necessary support, I am somewhat
dissapointed that the original patch series that was sent almost two
months ago still remains here without much comments and updates from the
developer community. I even made the interface to the logic that decides
where to split chunks easily replaceable, and I deliberately made the
logic in the original patch extremely stupid to entice others, especially
the "bup" fanboys, to come up with a better logic, thinking that giving
people an easy target to shoot for, they may be encouraged to help
out. The plan is not working :-(.
* ar/i18n-no-gettext (2012-01-27) 4 commits
(merged to 'next' on 2012-01-27 at 0ecf258)
+ i18n: Do not force USE_GETTEXT_SCHEME=fallthrough on NO_GETTEXT
(merged to 'next' on 2012-01-23 at 694a94e)
+ i18n: Make NO_GETTEXT imply fallthrough scheme in shell l10n
+ add a Makefile switch to avoid gettext translation in shell scripts
+ git-sh-i18n: restructure the logic to compute gettext.sh scheme
Will merge to 'master' in the second batch and deal with any fallout in 'master'.
* da/maint-mergetool-twoway (2012-01-23) 1 commit
(merged to 'next' on 2012-01-23 at f927323)
+ mergetool: Provide an empty file when needed
Caters to GUI merge backends that cannot merge two files without
a base by giving them an empty file as a "pretend" common ancestor.
Will merge to 'master' in the second batch and deal with any fallout in 'master'.
* ld/git-p4-branches-and-labels (2012-01-20) 5 commits
(merged to 'next' on 2012-01-23 at 9020ec4)
+ git-p4: label import fails with multiple labels at the same changelist
+ git-p4: add test for p4 labels
+ git-p4: importing labels should cope with missing owner
+ git-p4: cope with labels with empty descriptions
+ git-p4: handle p4 branches and labels containing shell chars
(this branch is used by va/git-p4-branch.)
Will merge to 'master' in the second batch.
* va/git-p4-branch (2012-01-26) 4 commits
(merged to 'next' on 2012-01-26 at e67c52a)
+ t9801: do not overuse test_must_fail
+ git-p4: Change p4 command invocation
+ git-p4: Add test case for complex branch import
+ git-p4: Search for parent commit on branch creation
(this branch uses ld/git-p4-branches-and-labels.)
Rerolled and Acked.
Will merge to 'master' in the second batch.
* ks/sort-wildcard-in-makefile (2012-01-22) 1 commit
(merged to 'next' on 2012-01-23 at e2e0c1d)
+ t/Makefile: Use $(sort ...) explicitly where needed
t/Makefile is adjusted to prevent newer versions of GNU make from running
tests in seemingly random order.
Will merge to 'master' in the second batch.
* tr/grep-l-with-decoration (2012-01-23) 1 commit
(merged to 'next' on 2012-01-23 at 42b8795)
+ grep: fix -l/-L interaction with decoration lines
Using "git grep -l/-L" together with options -W or --break may not make
much sense as the output is to only count the number of hits and there is
no place for file breaks, but the latter options made "-l/-L" to miscount
the hits.
Will merge to 'master' in the second batch.
* jc/pull-signed-tag (2012-01-23) 1 commit
(merged to 'next' on 2012-01-23 at 4257553)
+ merge: use editor by default in interactive sessions
Per Linus's strong suggestion, sugarcoated (aka "taking blame for the
original UI screw-ups") so that it is easier for me to swallow and accept
a potentially huge backward incompatibility issue, "git merge" is made to
launch an editor to explain the merge in the merge commit by default in
interactive sessions.
I've updated the special-case environment variable to MERGE_AUTOEDIT that
scripts can set to "no" when they start. There is no plan to encourage
humans to keep using the historical behaviour, hence there is no support
for configuration variable (e.g. merge.autoedit) that can be set to 'no'.
Oh, also I updated the documentation a bit.
"git merge" in an interactive session learned to spawn the editor by
default to let the user edit the auto-generated merge message, to
encourage people to explain their merges better.
Will merge to 'master' in the second batch and deal with any fallout in 'master'.
* jc/advise-i18n (2011-12-22) 1 commit
(merged to 'next' on 2012-01-23 at 6447013)
+ i18n of multi-line advice messages
Allow localization of advice messages that tend to be longer and
multi-line formatted. For now this is deliberately limited to advise()
interface and not vreportf() in general as touching the latter has
interactions with error() that has plumbing callers whose prefix "error: "
should never be translated.
Will merge to 'master' in the second batch.
* rr/sequencer (2012-01-11) 2 commits
(merged to 'next' on 2012-01-23 at f349b56)
+ sequencer: factor code out of revert builtin
+ revert: prepare to move replay_action to header
Moving large chunk of code out of cherry-pick/revert for later reuse,
primarily to prepare for the next cycle.
Will merge to 'master' in the second batch.
* nd/clone-detached (2012-01-24) 12 commits
(merged to 'next' on 2012-01-26 at 7b0cc8a)
+ clone: fix up delay cloning conditions
(merged to 'next' on 2012-01-23 at bee31c6)
+ push: do not let configured foreign-vcs permanently clobbered
(merged to 'next' on 2012-01-23 at 9cab64e)
+ clone: print advice on checking out detached HEAD
+ clone: allow --branch to take a tag
+ clone: refuse to clone if --branch points to bogus ref
+ clone: --branch=<branch> always means refs/heads/<branch>
+ clone: delay cloning until after remote HEAD checking
+ clone: factor out remote ref writing
+ clone: factor out HEAD update code
+ clone: factor out checkout code
+ clone: write detached HEAD in bare repositories
+ t5601: add missing && cascade
"git clone" learned to detach the HEAD in the resulting repository when
the source repository's HEAD does not point to a branch.
Will merge to 'master' in the second batch and deal with any fallout in 'master'.
--------------------------------------------------
[Discarded]
* mh/ref-api-rest (2011-12-12) 35 commits
. repack_without_ref(): call clear_packed_ref_cache()
. read_packed_refs(): keep track of the directory being worked in
. is_refname_available(): query only possibly-conflicting references
. refs: read loose references lazily
. read_loose_refs(): take a (ref_entry *) as argument
. struct ref_dir: store a reference to the enclosing ref_cache
. sort_ref_dir(): take (ref_entry *) instead of (ref_dir *)
. do_for_each_ref_in_dir*(): take (ref_entry *) instead of (ref_dir *)
. add_entry(): take (ref_entry *) instead of (ref_dir *)
. search_ref_dir(): take (ref_entry *) instead of (ref_dir *)
. find_containing_direntry(): use (ref_entry *) instead of (ref_dir *)
. add_ref(): take (ref_entry *) instead of (ref_dir *)
. read_packed_refs(): take (ref_entry *) instead of (ref_dir *)
. find_ref(): take (ref_entry *) instead of (ref_dir *)
. is_refname_available(): take (ref_entry *) instead of (ref_dir *)
. get_loose_refs(): return (ref_entry *) instead of (ref_dir *)
. get_packed_refs(): return (ref_entry *) instead of (ref_dir *)
. refs: wrap top-level ref_dirs in ref_entries
. get_ref_dir(): keep track of the current ref_dir
. do_for_each_ref(): only iterate over the subtree that was requested
. refs: sort ref_dirs lazily
. sort_ref_dir(): do not sort if already sorted
. refs: store references hierarchically
. refs.c: rename ref_array -> ref_dir
. struct ref_entry: nest the value part in a union
. check_refname_component(): return 0 for zero-length components
. free_ref_entry(): new function
. refs.c: reorder definitions more logically
. is_refname_available(): reimplement using do_for_each_ref_in_array()
. names_conflict(): simplify implementation
. names_conflict(): new function, extracted from is_refname_available()
. repack_without_ref(): reimplement using do_for_each_ref_in_array()
. do_for_each_ref_in_arrays(): new function
. do_for_each_ref_in_array(): new function
. do_for_each_ref(): correctly terminate while processesing extra_refs
Will be re-rolled. Discarded without prejudice.
* mm/zsh-completion-regression-fix (2012-01-17) 1 commit
(merged to 'next' on 2012-01-23 at 7bc2e0a)
+ bash-completion: don't add quoted space for ZSH (fix regression)
Superseded by a better fix already in 'master'.
^ permalink raw reply
* Re: [PATCH] grep: fix -l/-L interaction with decoration lines
From: Junio C Hamano @ 2012-01-29 23:49 UTC (permalink / raw)
To: Thomas Rast; +Cc: Albert Yale, René Scharfe, git
In-Reply-To: <74777e0e8633d980fee9a1a680a63535be042fdc.1327340917.git.trast@student.ethz.ch>
Thanks, makes sense.
^ permalink raw reply
* Re: [PATCH/RFC v2] grep: Add the option '--exclude'
From: Albert Yale @ 2012-01-30 0:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvcnudsda.fsf@alter.siamese.dyndns.org>
Thank you for your feedback Junio.
I'll revise my patch next weekend.
Albert Yale
On Sun, Jan 29, 2012 at 6:02 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> Albert Yale <surfingalbert@gmail.com> writes:
>
> > Feedback would again be appreciated,
>
> Hmm.
>
> > [-f <file>] [-e] <pattern>
> > + [-x<pattern>|--exclude<pattern>]
>
> Compare the above two lines and notice some funny in the added one?
>
> > @@ -124,6 +125,12 @@ OPTIONS
> > Use fixed strings for patterns (don't interpret pattern
> > as a regex).
> >
> > +-x<pattern>::
> > +--exclude<pattern>::
> > + In addition to those found in .gitignore (per directory) and
> > + $GIT_DIR/info/exclude, also consider these patterns to be in the
> > + set of the ignore rules in effect.
> > +
>
> Likewise.
>
> > diff --git a/builtin/grep.c b/builtin/grep.c
> > index 9ce064a..9772fa4 100644
> > --- a/builtin/grep.c
> > +++ b/builtin/grep.c
> > @@ -530,6 +530,10 @@ static int grep_cache(struct grep_opt *opt, const struct pathspec *pathspec, int
> > continue;
> > if (!match_pathspec_depth(pathspec, ce->name, ce_namelen(ce), 0, NULL))
> > continue;
> > + if (pathspec->exclude &&
> > + pathspec->exclude->nr &&
> > + match_pathspec_depth(pathspec->exclude, ce->name, ce_namelen(ce), 0, NULL))
> > + continue;
>
> Why isn't this just
>
> if (!match_pathspec_depth(pathspec, ce->name, ce_namelen(ce), 0, NULL))
>
> that is, *no change whatsoever* on the existing codepaths that call
> match_pathspec_depth()? Can't the "even if one of the positive pathspec
> matched, if one of the excluded one matches, declare that the path does
> *not* match" logic live in match_pathspec_depth() itself?
>
> Exactly the same comment applies to all the other additions that calls
> match_pathspec_depth() with pathspec->exclude as its first parameter in
> this patch.
>
> > @@ -1053,6 +1084,12 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
> > pathspec.max_depth = opt.max_depth;
> > pathspec.recursive = 1;
> >
> > + if( exclude_list.nr ) {
> > + create_pathspec_from_string_list(&pathspec.exclude, &exclude_list);
> > + pathspec.exclude->max_depth = opt.max_depth;
> > + pathspec.exclude->recursive = 1;
> > + }
> > +
>
> Style. Notice where SPs should be near parentheses on "if" statement in
> our codebase.
^ permalink raw reply
* [PATCH] completion: add new zsh completion
From: Felipe Contreras @ 2012-01-30 0:01 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras
It seems there's always issues with zsh's bash completion emulation,
after I took a deep look at the code, I found many issues[1].
So, here is a kind of wrapper that does the same, but properly :)
This would also allow us to make fixes if necessary, since the code is
simple enough, and extend functionality.
[1] http://article.gmane.org/gmane.comp.shells.zsh.devel/24290
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
contrib/completion/git-completion.zsh | 146 +++++++++++++++++++++++++++++++++
1 files changed, 146 insertions(+), 0 deletions(-)
create mode 100644 contrib/completion/git-completion.zsh
diff --git a/contrib/completion/git-completion.zsh b/contrib/completion/git-completion.zsh
new file mode 100644
index 0000000..15961df
--- /dev/null
+++ b/contrib/completion/git-completion.zsh
@@ -0,0 +1,146 @@
+#compdef git gitk
+
+compgen () {
+ local prefix suffix
+ local -a results
+ while getopts "W:P:S:" opt
+ do
+ case $opt in
+ W)
+ results=( ${(Q)~=OPTARG} )
+ ;;
+ P)
+ prefix="$OPTARG"
+ ;;
+ S)
+ suffix="$OPTARG"
+ ;;
+ esac
+ done
+ print -l -r -- "$prefix${^results[@]}$suffix"
+}
+
+complete () {
+ # do nothing
+ return 0
+}
+
+ZSH_VERSION='' . /usr/share/git/completion/git-completion.bash
+
+_get_comp_words_by_ref ()
+{
+ while [ $# -gt 0 ]; do
+ case "$1" in
+ cur)
+ cur=${_words[CURRENT]}
+ ;;
+ prev)
+ cur=${_words[CURRENT-1]}
+ ;;
+ words)
+ words=("${_words[@]}")
+ ;;
+ cword)
+ ((cword = CURRENT - 1))
+ ;;
+ esac
+ shift
+ done
+}
+
+_bash_wrap ()
+{
+ local -a COMPREPLY results _words
+ _words=( $words )
+ () {
+ emulate -L sh
+ setopt kshglob noshglob braceexpand nokshautoload
+ typeset -h words
+ local cur words cword prev
+ _get_comp_words_by_ref -n =: cur words cword prev
+ $1
+ } $1
+ results=( "${^COMPREPLY[@]}" )
+ local COMP_WORDBREAKS="\"'@><=;|&(:"
+ local i start
+ local cur="${words[CURRENT]}"
+ i=$(expr index "$cur" "$COMP_WORDBREAKS")
+ start="${cur:0:$i}"
+ compadd -Q -S '' -p "$start" -a results && return 0
+}
+
+_gitk ()
+{
+ __git_has_doubledash && return
+
+ local g="$(__gitdir)"
+ local merge=""
+ if [ -f "$g/MERGE_HEAD" ]; then
+ merge="--merge"
+ fi
+ case "$cur" in
+ --*)
+ __gitcomp "
+ $__git_log_common_options
+ $__git_log_gitk_options
+ $merge
+ "
+ return
+ ;;
+ esac
+ __git_complete_revlist
+}
+
+_git ()
+{
+ if [[ $service != git ]]
+ then
+ _bash_wrap _$service
+ return ret
+ fi
+
+ local ret=1
+ local curcontext="$curcontext" state state_descr line
+ typeset -A opt_args
+
+ _arguments -C \
+ '(-p --paginate --no-pager)'{-p,--paginate}'[Pipe all output into ''less'']' \
+ '(-p --paginate)--no-pager[Do not pipe git output into a pager]' \
+ '--git-dir=-[Set the path to the repository]: :_directories' \
+ '--bare[Treat the repository as a bare repository]' \
+ '(- :)--version[Prints the git suite version]' \
+ '--exec-path=-[Path to where your core git programs are installed]:: :_directories' \
+ '--html-path[Print the path where git''s HTML documentation is installed]' \
+ '--work-tree=-[Set the path to the working tree]: :_directories' \
+ '--namespace=-[Set the git namespace]: :_directories' \
+ '(- :)--help[Prints the synopsis and a list of the most commonly used commands]' \
+ '(-): :->command' \
+ '(-)*:: :->option-or-argument' && return 0
+
+ case $state in
+ (command)
+ emulate sh -c __git_compute_porcelain_commands
+ local -a porcelain aliases
+ porcelain=( ${=__git_porcelain_commands} )
+ aliases=( $(__git_aliases) )
+ _describe -t porcelain-commands 'porcelain commands' porcelain && ret=0
+ _describe -t aliases 'aliases' aliases && ret=0
+ ;;
+ (option-or-argument)
+ local command="${words[1]}"
+
+ completion_func="_git_${command//-/_}"
+ declare -f $completion_func >/dev/null && _bash_wrap $completion_func && return 0
+
+ local expansion=$(__git_aliased_command "$command")
+ if [ -n "$expansion" ]; then
+ completion_func="_git_${expansion//-/_}"
+ declare -f $completion_func >/dev/null && _bash_wrap $completion_func && return 0
+ fi
+ ;;
+ esac
+
+ return ret
+}
+
+_git
--
1.7.8.3
^ permalink raw reply related
* [PATCH] completion: cleanup __gitcomp*
From: Felipe Contreras @ 2012-01-30 0:29 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras
I don't know why there's so much code; these functions don't seem to be
doing much:
* ${1-} is the same as $1
* no need to check $#, ${3:-$cur} is much easier
* __gitcomp_nl doesn't seem to using the initial IFS
This makes the code much simpler.
Eventually it would be nice to wrap everything that touches compgen and
COMPREPLY in one function for the zsh wrapper.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
contrib/completion/git-completion.bash | 24 +++++-------------------
1 files changed, 5 insertions(+), 19 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 1496c6d..accfce5 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -495,19 +495,15 @@ fi
# 4: A suffix to be appended to each possible completion word (optional).
__gitcomp ()
{
- local cur_="$cur"
-
- if [ $# -gt 2 ]; then
- cur_="$3"
- fi
+ local cur_="${3:-$cur}"
case "$cur_" in
--*=)
COMPREPLY=()
;;
*)
local IFS=$'\n'
- COMPREPLY=($(compgen -P "${2-}" \
- -W "$(__gitcomp_1 "${1-}" "${4-}")" \
+ COMPREPLY=($(compgen -P "$2" \
+ -W "$(__gitcomp_1 "$1" "$4")" \
-- "$cur_"))
;;
esac
@@ -524,18 +520,8 @@ __gitcomp ()
# appended.
__gitcomp_nl ()
{
- local s=$'\n' IFS=' '$'\t'$'\n'
- local cur_="$cur" suffix=" "
-
- if [ $# -gt 2 ]; then
- cur_="$3"
- if [ $# -gt 3 ]; then
- suffix="$4"
- fi
- fi
-
- IFS=$s
- COMPREPLY=($(compgen -P "${2-}" -S "$suffix" -W "$1" -- "$cur_"))
+ local IFS=$'\n'
+ COMPREPLY=($(compgen -P "$2" -S "${4:- }" -W "$1" -- "${3:-$cur}"))
}
__git_heads ()
--
1.7.8.3
^ permalink raw reply related
* Re: [PATCH 2/3] completion: remove old code
From: Jonathan Nieder @ 2012-01-30 2:36 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <1327880479-25275-3-git-send-email-felipe.contreras@gmail.com>
Hi,
Felipe Contreras wrote:
> We don't need to check for GIT_DIR/remotes, right? This was removed long
> time ago.
I don't follow. fetch, push, and remote still look in .git/remotes
like they always did, last time I checked.
Perhaps you mean that /usr/share/git-core/templates/ no longer
contains a remotes/ directory? That's true but not particularly
relevant. A more relevant detail would be that very few people _use_
the .git/remotes feature, though it is not obvious to me whether that
justifies removing this code from the git-completion script that
already works.
^ permalink raw reply
* Re: [PATCH] completion: cleanup __gitcomp*
From: Jonathan Nieder @ 2012-01-30 2:42 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <1327883371-25573-1-git-send-email-felipe.contreras@gmail.com>
Felipe Contreras wrote:
> * ${1-} is the same as $1
| $ git log -S'${1-}' contrib/completion/git-completion.bash
| [...]
| commit 25a31f81
| Author: Ted Pavlic <ted@tedpavlic.com>
| Date: Thu Jan 15 11:02:21 2009 -0500
|
| bash-completion: Support running when set -u is enabled
|
| Under "set -u" semantics, it is an error to access undefined variables.
| Some user environments may enable this setting in the interactive shell.
|
| In any context where the completion functions access an undefined
| variable, accessing a default empty string (aka "${1-}" instead of "$1")
| is a reasonable way to code the function, as it silences the undefined
| variable error while still supplying an empty string.
|
| In this patch, functions that should always take an argument still use
| $1. Functions that have optional arguments use ${1-}.
|
| Signed-off-by: Ted Pavlic <ted@tedpavlic.com>
| Acked-by: Shawn O. Pearce <spearce@spearce.org>
| Signed-off-by: Junio C Hamano <gitster@pobox.com>
Hope that helps,
Jonathan
^ permalink raw reply
* Re: [PATCH 3/3] completion: remove unused code
From: Jonathan Nieder @ 2012-01-30 2:50 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <1327880479-25275-4-git-send-email-felipe.contreras@gmail.com>
Felipe Contreras wrote:
> No need for thus rather complicated piece of code :)
[...]
> contrib/completion/git-completion.bash | 30 ------------------------------
> 1 files changed, 0 insertions(+), 30 deletions(-)
[...]
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -2730,33 +2730,3 @@ if [ Cygwin = "$(uname -o 2>/dev/null)" ]; then
[...]
> -if [[ -n ${ZSH_VERSION-} ]]; then
> - __git_shopt () {
[...]
> -else
> - __git_shopt () {
> - shopt "$@"
> - }
> -fi
What codebase does this apply to? My copy of git-completion.bash
contains a number of calls to __git_shopt, which will fail after this
change.
By the way, is there any reason you did not cc this series to Gábor or
others who also know the completion code well? The patches are not
marked with RFC/ so I assume they are intended for direct application,
which seems somewhat odd to me.
Thanks and hope that helps,
Jonathan
^ permalink raw reply
* Re: [PATCH 2/3] completion: remove old code
From: Felipe Contreras @ 2012-01-30 3:24 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git
In-Reply-To: <20120130023642.GA14986@burratino>
On Mon, Jan 30, 2012 at 4:36 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Felipe Contreras wrote:
>
>> We don't need to check for GIT_DIR/remotes, right? This was removed long
>> time ago.
>
> I don't follow. fetch, push, and remote still look in .git/remotes
> like they always did, last time I checked.
>
> Perhaps you mean that /usr/share/git-core/templates/ no longer
> contains a remotes/ directory? That's true but not particularly
> relevant. A more relevant detail would be that very few people _use_
> the .git/remotes feature, though it is not obvious to me whether that
> justifies removing this code from the git-completion script that
> already works.
The problem is all the 'nullglob' stuff. It's *a lot* of code for this
feature that nobody uses.
OK, maybe some people use it, but most likely they are using an old
version of git, and thus an old version of the completion script.
Anyway, aren't there easier ways to get this? Perhaps first checking
if the directory exists, to avoid wasting cycles.
Something like:
test -d "$d/remotes" && ls -1 "$d/remotes"
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH 2/3] completion: remove old code
From: Jonathan Nieder @ 2012-01-30 3:27 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <CAMP44s1H6Db6Xq_iZseXppaTwpBCeu14ySgPfmoQnpELfywQ-Q@mail.gmail.com>
Felipe Contreras wrote:
> Anyway, aren't there easier ways to get this? Perhaps first checking
> if the directory exists, to avoid wasting cycles.
>
> Something like:
> test -d "$d/remotes" && ls -1 "$d/remotes"
Yeah, that sounds like a good idea. Could you send a patch that does
that?
Thanks,
Jonathan
^ permalink raw reply
* Re: [PATCH 3/3] completion: remove unused code
From: Jonathan Nieder @ 2012-01-30 3:29 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <20120130025014.GA15944@burratino>
Jonathan Nieder wrote:
> What codebase does this apply to? My copy of git-completion.bash
> contains a number of calls to __git_shopt
Ah, now I get it. This would have been easier to understand if
squashed in with patch 2/3.
And it certainly looks like a good change, yes. :)
Thanks for explaining,
Jonathan
^ permalink raw reply
* Re: [PATCH 3/3] completion: remove unused code
From: Felipe Contreras @ 2012-01-30 3:30 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git
In-Reply-To: <20120130025014.GA15944@burratino>
On Mon, Jan 30, 2012 at 4:50 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Felipe Contreras wrote:
>
>> No need for thus rather complicated piece of code :)
> [...]
>> contrib/completion/git-completion.bash | 30 ------------------------------
>> 1 files changed, 0 insertions(+), 30 deletions(-)
> [...]
>> --- a/contrib/completion/git-completion.bash
>> +++ b/contrib/completion/git-completion.bash
>> @@ -2730,33 +2730,3 @@ if [ Cygwin = "$(uname -o 2>/dev/null)" ]; then
> [...]
>> -if [[ -n ${ZSH_VERSION-} ]]; then
>> - __git_shopt () {
> [...]
>> -else
>> - __git_shopt () {
>> - shopt "$@"
>> - }
>> -fi
>
> What codebase does this apply to? My copy of git-completion.bash
> contains a number of calls to __git_shopt, which will fail after this
> change.
The latest and greatest of course:
http://git.kernel.org/?p=git/git.git;a=blob;f=contrib/completion/git-completion.bash
It's only used in __git_remotes.
> By the way, is there any reason you did not cc this series to Gábor or
> others who also know the completion code well? The patches are not
> marked with RFC/ so I assume they are intended for direct application,
> which seems somewhat odd to me.
No reason. I hope they read the mailing list, otherwise I'll resend
and CC them. A get_maintainers script, or something like that would
make things easier.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH] completion: cleanup __gitcomp*
From: Felipe Contreras @ 2012-01-30 3:39 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git
In-Reply-To: <20120130024242.GA15896@burratino>
On Mon, Jan 30, 2012 at 4:42 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Felipe Contreras wrote:
>
>> * ${1-} is the same as $1
>
> | $ git log -S'${1-}' contrib/completion/git-completion.bash
> | [...]
> | commit 25a31f81
> | Author: Ted Pavlic <ted@tedpavlic.com>
> | Date: Thu Jan 15 11:02:21 2009 -0500
> |
> | bash-completion: Support running when set -u is enabled
> |
> | Under "set -u" semantics, it is an error to access undefined variables.
> | Some user environments may enable this setting in the interactive shell.
> |
> | In any context where the completion functions access an undefined
> | variable, accessing a default empty string (aka "${1-}" instead of "$1")
> | is a reasonable way to code the function, as it silences the undefined
> | variable error while still supplying an empty string.
> |
> | In this patch, functions that should always take an argument still use
> | $1. Functions that have optional arguments use ${1-}.
> |
> | Signed-off-by: Ted Pavlic <ted@tedpavlic.com>
> | Acked-by: Shawn O. Pearce <spearce@spearce.org>
> | Signed-off-by: Junio C Hamano <gitster@pobox.com>
>
> Hope that helps,
I see. I'll revert that then.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH 2/3] completion: remove old code
From: Junio C Hamano @ 2012-01-30 4:27 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Jonathan Nieder, git
In-Reply-To: <CAMP44s1H6Db6Xq_iZseXppaTwpBCeu14ySgPfmoQnpELfywQ-Q@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> OK, maybe some people use it, but most likely they are using an old
> version of git, and thus an old version of the completion script.
Please adjust your attitude about backward compatibility to match the
standard used for other parts of Git.
Most likely they are using repositories that they started using with an
old version, but at the same time, most likely they are happily using more
modern version exactly because the rest of Git still support it, except
for the completion script after _this_ patch breaks the support.
^ permalink raw reply
* Re: [PATCH 1/3] completion: be nicer with zsh
From: Junio C Hamano @ 2012-01-30 4:34 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <1327880479-25275-2-git-send-email-felipe.contreras@gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> Let's avoid it. This has the advantage that the code is now actually
> understandable (at least to me), while before it looked like voodoo.
I am somewhat hesitant to accept a patch to shell scripts on the basis
that the patch author does not understand the existing constructs that
are standard parts of shell idioms.
Avoiding zsh's bug that cannot use conditional assignment on the no-op
colon command (if the bug is really that; it is somewhat hard to imagine
if the bug exists only for colon command, though) *is* by itself a good
justification for this change, even though the resulting code is harder to
read for people who are used to read shell scripts.
^ permalink raw reply
* Re: [PATCH 1/3] completion: be nicer with zsh
From: Junio C Hamano @ 2012-01-30 5:50 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <7v8vkperli.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Avoiding zsh's bug that cannot use conditional assignment on the no-op
> colon command (if the bug is really that; it is somewhat hard to imagine
> if the bug exists only for colon command, though) *is* by itself a good
> justification for this change, even though the resulting code is harder to
> read for people who are used to read shell scripts.
Just from my curiosity, I am wondering what zsh does when given these:
bar () { echo "frotz nitfol xyzzy" }
unset foo; : ${foo:=$(bar)}; echo "<$?,$foo>"
unset foo; true ${foo:=$(bar)}; echo "<$?,$foo>"
unset foo; echo >/dev/null ${foo:=$(bar)}; echo "<$?,$foo>"
The first one is exactly your "And yet another bug in zsh[1] causes a
mismatch; zsh seems to have problem emulating wordspliting, but only when
the ':' command is involved.", so we already know it "seems to have
problem emulating word-splitting" (by the way, can we replace that with
exact description of faulty symptom? e.g. "does not split words at $IFS"
might be what you meant but still when we are assigning the result to a
single variable, it is unclear how that matters).
Note that I am not suggesting to rewrite the existing ": ${var:=val}" with
"echo ${var:val} >/dev/null" at all. Even if "echo >/dev/null" makes it
work as expected, your rewrite to protect it with an explicit conditional
e.g. "test -n ${foo:-} || foo=$(bar)" would be a lot better than funny
construct like "echo >/dev/null ${foo:=$(bar)", because it is not an
established shell idiom to use default assignment with anything but ":".
Thanks.
^ permalink raw reply
* Re: Bug: "git checkout -b" should be allowed in empty repo
From: Michael Haggerty @ 2012-01-30 6:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwr8bvvxj.fsf@alter.siamese.dyndns.org>
On 01/29/2012 07:56 AM, Junio C Hamano wrote:
> Michael Haggerty <mhagger@alum.mit.edu> writes:
>
>> When starting a new repo, git seems to insist that the first commit be
>> made on a branch named "master":
>>
>> $ git --version
>> git version 1.7.9
>> $ git init git-test
>> Initialized empty Git repository in /home/mhagger/tmp/git-test/.git/
>> $ cd git-test
>> $ git checkout -b foo
>> fatal: You are on a branch yet to be born
>>
>> I would call this a bug; the last command should be allowed. The
>> plumbing allows it:
>>
>> $ git symbolic-ref HEAD refs/heads/foo
>
> Your last sentence is nonsense. The plumbing equivalent of that command
> is *not* what you wrote above, but is more like [*1*]:
>
> git update-ref refs/heads/foo $(git rev-parse --verify HEAD) &&
> git symbolic-ref HEAD refs/heads/foo
All that I meant is that the one command is the equivalent of *what the
user wants and expects* in the *particular* situation that I described
[1]. I should have been clearer.
> And the first step will fail the same way. While I share the sense of
> annoyance with you, I do not think that it is a bug in "checkout -b".
>
> When you are on an unborn branch, what the "symbolic-ref HEAD" command
> reports does *not* appear in the output from the "for-each-ref refs/heads"
> command (similarly, that branch name does not appear in the output from
> the "git branch" command).
>
> Such a behaviour indeed is *curious* and very *different* from the normal
> case of being on an existing branch, but is that a bug?
When git behaves differently than a typical user would expect for no
good reason, that is a bug (albeit a UI bug). The fact that somebody
who knows the internals of git can find an excuse for the inconsistency
might be an explanation for how the bug arose but it doesn't make it
less of a bug.
> You need to first admit that the state immediately after "git init" (or
> for that matter, "checkout --orphan") where you are on an unborn branch
> *is* special. Some things that would normally make sense would not.
ISTM that this state is more special than it needs to be due to an
design flaw of git [2]. But even given the fact that this case is
special *internal* to git, there is no reason to let that specialness
leak out to the user more than necessary.
> [...]
> I am not sure "git checkout -b foo" (without explict HEAD [*1*]) should
> special case and degenerate to "symbolic-ref HEAD refs/heads/foo" when
> HEAD points to a nonexistent branch. The mimicking does not go far enough
> to satisfy people who are pedantic enough to expect "git checkout -b foo"
> to work when you haven't even instantiated your current branch (when you
> are on an already instantiated branch, after "git checkout -b foo", "git
> branch" output will show both foo and the branch you were on, but if you
> start from an unborn branch, the behaviour will be different and a pedant
> will notice the difference).
For me, "git checkout -b foo" means "leave the old branch in its current
state and move to a new branch that is in the same state." If the old
branch was unborn, then it should remain unborn after the command, and I
should be moved to a new unborn branch. Since an unborn branch in git
is not a branch, I would have no expectation that the old branch exists
after the command [3].
> It may make sense to let
>
> $ git branch -m trunk
>
> or even
>
> $ git branch -m master trunk
>
> move away from an unborn "master'"after "git init", with a special case
> codepath. When you start from an instanticated branch, after a successful
> such renaming, the original branch will not exist, and the new branch will
> exist. This property would also hold true if you start from an unborn one,
> so it would be much better mimickery than "git checkout -b foo" case you
> brought up in this thread.
It makes sense that "git branch -m" can *also* be used to escape an
unborn master, but this command won't necessarily occur to people
accustomed to using "git checkout -b" for creating new branches.
Michael
[1] Of course, here "the user" means me :-) but I predict that other
users would feel the same.
[2] Namely that "orphan" commits have no parents, instead of having an
"empty repository" commit (something like "000000*") as parent. By
contrast, when a new Subversion repository is created, it automatically
gets a pseudo "r0" commit that represents the empty repository. The r0
commit can be used in the UI most places that a "real" commit can be
used. If the 0000000 commit could be used in the same way in git, it
would remove a lot of special casing. For example, an "unborn branch"
could be initialized pointing at 0000000. Even if there is some deeper
reason why such a design wouldn't have worked, perhaps such a concept
could be faked for the user interface.
[3] If commit 0000000 were treated specially, then there would be no
unborn branches but only branches pointing at the empty commit. In that
case, my expectation would change--the old branch should be left
pointing at 0000000. But currently git has no concept of an unborn
branch that is not HEAD.
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: git-subtree
From: David A. Greene @ 2012-01-29 22:07 UTC (permalink / raw)
To: Jeff King; +Cc: Ramkumar Ramachandra, David Greene, git
In-Reply-To: <87zke2yv27.fsf@smith.obbligato.org>
greened@obbligato.org (David A. Greene) writes:
>> I'd favor keeping the history and doing the munge-overlay thing.
>
> Ok, that sounds fine to me. I'll do that in a private branch. What
> should I send as patches to the mailing list? I'm assuming we don't
> want [PATCH 235/12342], etc. sent to the list chronicling the entire
> history. :)
>
>> Although part of me wants to join the histories in a subtree so that we
>> can use "git subtree" to do it (which would just be cool),
>
> Heh. I thought about that too. :)
I actually did end up doing a subtree merge via git subtree. It was
more convenient to put it in contrib/ like that as almost everthing
there is in its own subdirectory.
I'm cleaning things up there to remove redundancy, rewrite tests (using
earlier work), etc. What number should I use for git-subtree tests?
Here are some logical candidates:
5 - the pull and exporting commands
6 - the revision tree commands (even e.g. merge-base)
7 - the porcelainish commands concerning the working tree
9 - the git tools
git-subtree can pull and export. It also affects revision trees (it
merges, for example) and is a porcelainish command that affects the
working tree. It is also a "git tool" of a sort.
I originally put them under t97XX but now that is taken, as is
everything up to and including t99XX.
Anyone have a strong opinion?
Thanks!
-Dave
^ permalink raw reply
* Re: [PATCH 3/3] completion: remove unused code
From: Thomas Rast @ 2012-01-30 7:44 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Jonathan Nieder, git
In-Reply-To: <CAMP44s1bZeednbHfqXANZR5zVVvGwjRpuV5TFmnh212FD7E-Vg@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> No reason. I hope they read the mailing list, otherwise I'll resend
> and CC them. A get_maintainers script, or something like that would
> make things easier.
I simply use
git shortlog -sn --no-merges v1.7.0.. -- contrib/completion/
(In many parts the revision limiter can be omitted without losing much,
but e.g. here this drops Shawn who hasn't worked on it since 2009.)
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: gitweb showing slash r at the end of line
From: Ondra Medek @ 2012-01-30 7:55 UTC (permalink / raw)
To: git
In-Reply-To: <201201281802.44339.jnareb@gmail.com>
Hi Jakub,
I have read "SubmittingPatches". I have made a path by "git format-patch -M"
and I have though it's enough. The problem maybe was, that I had not
included "Subject: " from the result of "git format-patch -M". Next time I
will try to do it better.
I am a Git newbie, but my bare repos have "config" file and this file can
contain the "core.autocrlf" setting. So the gitweb can read it. Or what
about to have a special section [gitweb] in this config? For now, the gitweb
config files are somewhat "scattered" = "descrition", "cloneurl",
"project.list", ...
Yeah, the autodetection of mixed mode line endings could be the best
solution.
However, from my point of view a global gitweb setting would be enough for
now.
--
View this message in context: http://git.661346.n2.nabble.com/gitweb-showing-slash-r-at-the-end-of-line-tp7229895p7235866.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* L10n for Git in Chinese begins
From: Jiang Xin @ 2012-01-30 8:21 UTC (permalink / raw)
To: Git List
With the release of v1.7.9 or some earlier , Git is multilingual.
I select some typical git commands and translated into Chinese,
both works.
- git status (in c)
- git stash (in bash)
Now I create a repo in Github hosting the po file (zh_cn.po) for git.
- repo: https://github.com/gotgit/git-l10n-zh-cn/
- file: https://github.com/gotgit/git-l10n-zh-cn/blob/master/zh_cn.po
Any help is appreciated, and will contribute here after 100% completed.
--
Jiang Xin
^ 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