* Re: Is anyone working on a next-gen Git protocol?
From: Junio C Hamano @ 2012-10-22 4:59 UTC (permalink / raw)
To: Git Mailing List; +Cc: Jeff King, spearce, Ævar Arnfjörð
In-Reply-To: <7va9vxq5gp.fsf@alter.siamese.dyndns.org>
On Sun, Oct 7, 2012 at 3:31 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> I and Shawn helped privately somebody from Gerrit circle, where the
> initial ref advertisement is a huge problem (primarily because they
> add tons of refs to one commit that eventually goes to their
> integration branch), to coming up with a problem description and
> proposal document to kick-start a discussion some time ago, but not
> much has happened since. Unless I hear from them soonish, I'll send
> a cleaned-up version of the draft before I leave for my vacation.
Which I forgot and never happened. Here is a link (not cleaned-up)
http://tinyurl.com/WhoSpeaksFirstInGit
^ permalink raw reply
* Re: Links broken in ref docs.
From: Andrew Ardill @ 2012-10-22 4:45 UTC (permalink / raw)
To: Mike Norman; +Cc: git, Scott Chacon
In-Reply-To: <CAJr+XPGm4djBh+vacG5Ff=Y6aYmWbcUXOV9x2jekgnsGsk4b-g@mail.gmail.com>
On 21 October 2012 18:31, Mike Norman <mknorman@gmail.com> wrote:
> Many links on scm-git.org/docs simply reload the page.
>
> For example, all of Sharing and Updating section simply reload the
> docs page. And tons others. Must be a broken link or routing problem.
> Repros on FF 14.0.1 and Chrome. Good luck!
>
Including Scott Chacon as he manages this site (to my knowledge).
Looking at the request, I am getting a 302:
Request URL:http://git-scm.com/docs/git-fetch
Request Method:GET
Status Code:302 Moved Temporarily
Maybe those pages are not done yet? That doesn't seem right as this is
simply the reference manual, but perhaps there is something else going
on here.
On another (related) note, the wayback machine has some very
interesting entries for the scm-git.org domain [1] and it seems the
/doc directory is not indexed at all. Is this on purpose?
Regards,
Andrew Ardill
[1] http://wayback.archive.org/web/*/http://git-scm.com/*
^ permalink raw reply
* [PATCH v6 3/3] completion: add new zsh completion
From: Felipe Contreras @ 2012-10-22 1:45 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Jeff King, SZEDER Gábor, Matthieu Moy,
Felipe Contreras
In-Reply-To: <1350870342-22653-1-git-send-email-felipe.contreras@gmail.com>
It seems there's always issues with zsh's bash completion emulation.
I've tried to fix as many as I could and most of the fixes are already
in the latest version of zsh, but still, there are issues.
There is no point in going through all that pain; the emulation is easy
to achieve, and this patch works better than zsh's emulation.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
v5:
* Even more simplification by using __gitcompadd
v4:
* Simplification updates for the latest bash completion
v3:
* Simplification
* Avoid COMPREPLY; call compadd directly
* Fix _get_comp_words_by_ref
contrib/completion/git-completion.zsh | 48 +++++++++++++++++++++++++++++++++++
1 file changed, 48 insertions(+)
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..ae9c532
--- /dev/null
+++ b/contrib/completion/git-completion.zsh
@@ -0,0 +1,48 @@
+#compdef git gitk
+
+# zsh completion wrapper for git
+#
+# You need git's bash completion script installed somewhere, by default on the
+# same directory as this script.
+#
+# If your script is on ~/.git-completion.sh instead, you can configure it on
+# your ~/.zshrc:
+#
+# zstyle ':completion:*:*:git:*' script ~/.git-completion.sh
+#
+# The recommended way to install this script is to copy to
+# '~/.zsh/completion/_git', and then add the following to your ~/.zshrc file:
+#
+# fpath=(~/.zsh/completion $fpath)
+
+complete ()
+{
+ # do nothing
+ return 0
+}
+
+zstyle -s ":completion:*:*:git:*" script script
+test -z "$script" && script="$(dirname ${funcsourcetrace[1]%:*})"/git-completion.bash
+ZSH_VERSION='' . "$script"
+
+__gitcompadd ()
+{
+ compadd -Q -S "$4" -P "${(M)cur#*[=:]}" -p "$2" -- ${=1} && _ret=0
+}
+
+_git ()
+{
+ local _ret=1
+ () {
+ emulate -L ksh
+ local cur cword prev
+ cur=${words[CURRENT-1]}
+ prev=${words[CURRENT-2]}
+ let cword=CURRENT-1
+ __${service}_main
+ }
+ let _ret && _default -S '' && _ret=0
+ return _ret
+}
+
+_git
--
1.8.0
^ permalink raw reply related
* [PATCH v6 2/3] completion: add new __gitcompadd helper
From: Felipe Contreras @ 2012-10-22 1:45 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Jeff King, SZEDER Gábor, Matthieu Moy,
Felipe Contreras
In-Reply-To: <1350870342-22653-1-git-send-email-felipe.contreras@gmail.com>
The idea is to never touch the COMPREPLY variable directly.
This allows other completion systems override __gitcompadd, and do
something different instead.
Also, this allows the simplification of the completion tests (separate
patch).
There should be no functional changes.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
contrib/completion/git-completion.bash | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 7bdd6a8..975ae13 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -225,6 +225,11 @@ _get_comp_words_by_ref ()
fi
fi
+__gitcompadd ()
+{
+ COMPREPLY=($(compgen -W "$1" -P "$2" -S "$4" -- "$3"))
+}
+
# Generates completion reply with compgen, appending a space to possible
# completion words, if necessary.
# It accepts 1 to 4 arguments:
@@ -241,9 +246,7 @@ __gitcomp ()
;;
*)
local IFS=$'\n'
- COMPREPLY=($(compgen -P "${2-}" \
- -W "$(__gitcomp_1 "${1-}" "${4-}")" \
- -- "$cur_"))
+ __gitcompadd "$(__gitcomp_1 "${1-}" "${4-}")" "${2-}" "$cur_" ""
;;
esac
}
@@ -260,7 +263,7 @@ __gitcomp ()
__gitcomp_nl ()
{
local IFS=$'\n'
- COMPREPLY=($(compgen -P "${2-}" -S "${4- }" -W "$1" -- "${3-$cur}"))
+ __gitcompadd "$1" "${2-}" "${3-$cur}" "${4- }"
}
__git_heads ()
@@ -1603,7 +1606,7 @@ _git_config ()
local remote="${prev#remote.}"
remote="${remote%.fetch}"
if [ -z "$cur" ]; then
- COMPREPLY=("refs/heads/")
+ __gitcompadd "refs/heads/"
return
fi
__gitcomp_nl "$(__git_refs_remotes "$remote")"
--
1.8.0
^ permalink raw reply related
* [PATCH v6 1/3] completion: get rid of empty COMPREPLY assignments
From: Felipe Contreras @ 2012-10-22 1:45 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Jeff King, SZEDER Gábor, Matthieu Moy,
Felipe Contreras
In-Reply-To: <1350870342-22653-1-git-send-email-felipe.contreras@gmail.com>
There's no functional reason for those, the only purpose they are
supposed to serve is to say "we don't provide any words here", but even
for that it's not used consitently.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
contrib/completion/git-completion.bash | 28 ----------------------------
1 file changed, 28 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index be800e0..7bdd6a8 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -238,7 +238,6 @@ __gitcomp ()
case "$cur_" in
--*=)
- COMPREPLY=()
;;
*)
local IFS=$'\n'
@@ -486,7 +485,6 @@ __git_complete_remote_or_refspec ()
case "$cmd" in
push) no_complete_refspec=1 ;;
fetch)
- COMPREPLY=()
return
;;
*) ;;
@@ -502,7 +500,6 @@ __git_complete_remote_or_refspec ()
return
fi
if [ $no_complete_refspec = 1 ]; then
- COMPREPLY=()
return
fi
[ "$remote" = "." ] && remote=
@@ -776,7 +773,6 @@ _git_am ()
"
return
esac
- COMPREPLY=()
}
_git_apply ()
@@ -796,7 +792,6 @@ _git_apply ()
"
return
esac
- COMPREPLY=()
}
_git_add ()
@@ -811,7 +806,6 @@ _git_add ()
"
return
esac
- COMPREPLY=()
}
_git_archive ()
@@ -856,7 +850,6 @@ _git_bisect ()
__gitcomp_nl "$(__git_refs)"
;;
*)
- COMPREPLY=()
;;
esac
}
@@ -969,7 +962,6 @@ _git_clean ()
return
;;
esac
- COMPREPLY=()
}
_git_clone ()
@@ -993,7 +985,6 @@ _git_clone ()
return
;;
esac
- COMPREPLY=()
}
_git_commit ()
@@ -1027,7 +1018,6 @@ _git_commit ()
"
return
esac
- COMPREPLY=()
}
_git_describe ()
@@ -1158,7 +1148,6 @@ _git_fsck ()
return
;;
esac
- COMPREPLY=()
}
_git_gc ()
@@ -1169,7 +1158,6 @@ _git_gc ()
return
;;
esac
- COMPREPLY=()
}
_git_gitk ()
@@ -1246,7 +1234,6 @@ _git_init ()
return
;;
esac
- COMPREPLY=()
}
_git_ls_files ()
@@ -1265,7 +1252,6 @@ _git_ls_files ()
return
;;
esac
- COMPREPLY=()
}
_git_ls_remote ()
@@ -1381,7 +1367,6 @@ _git_mergetool ()
return
;;
esac
- COMPREPLY=()
}
_git_merge_base ()
@@ -1397,7 +1382,6 @@ _git_mv ()
return
;;
esac
- COMPREPLY=()
}
_git_name_rev ()
@@ -1567,7 +1551,6 @@ _git_send_email ()
return
;;
esac
- COMPREPLY=()
}
_git_stage ()
@@ -1680,7 +1663,6 @@ _git_config ()
return
;;
*.*)
- COMPREPLY=()
return
;;
esac
@@ -2060,7 +2042,6 @@ _git_remote ()
__gitcomp "$c"
;;
*)
- COMPREPLY=()
;;
esac
}
@@ -2104,7 +2085,6 @@ _git_rm ()
return
;;
esac
- COMPREPLY=()
}
_git_shortlog ()
@@ -2173,8 +2153,6 @@ _git_stash ()
*)
if [ -z "$(__git_find_on_cmdline "$save_opts")" ]; then
__gitcomp "$subcommands"
- else
- COMPREPLY=()
fi
;;
esac
@@ -2187,14 +2165,12 @@ _git_stash ()
__gitcomp "--index --quiet"
;;
show,--*|drop,--*|branch,--*)
- COMPREPLY=()
;;
show,*|apply,*|drop,*|pop,*|branch,*)
__gitcomp_nl "$(git --git-dir="$(__gitdir)" stash list \
| sed -n -e 's/:.*//p')"
;;
*)
- COMPREPLY=()
;;
esac
fi
@@ -2311,7 +2287,6 @@ _git_svn ()
__gitcomp "--revision= --parent"
;;
*)
- COMPREPLY=()
;;
esac
fi
@@ -2336,13 +2311,10 @@ _git_tag ()
case "$prev" in
-m|-F)
- COMPREPLY=()
;;
-*|tag)
if [ $f = 1 ]; then
__gitcomp_nl "$(__git_tags)"
- else
- COMPREPLY=()
fi
;;
*)
--
1.8.0
^ permalink raw reply related
* [PATCH v6 0/3] completion: refactor and zsh wrapper
From: Felipe Contreras @ 2012-10-22 1:45 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Jeff King, SZEDER Gábor, Matthieu Moy,
Felipe Contreras
Hi,
Here's a bit of reorganition. I'm introducing a new __gitcompadd helper that is
useful to wrapp all changes to COMPREPLY, but first, lets get rid of
unnecessary assignments as SZEDER suggested.
The zsh wrapper is now very very simple.
Since v5:
* Get rid of unnecessary COMPREPLY assignments
Felipe Contreras (3):
completion: get rid of empty COMPREPLY assignments
completion: add new __gitcompadd helper
completion: add new zsh completion
contrib/completion/git-completion.bash | 41 ++++++-----------------------
contrib/completion/git-completion.zsh | 48 ++++++++++++++++++++++++++++++++++
2 files changed, 56 insertions(+), 33 deletions(-)
create mode 100644 contrib/completion/git-completion.zsh
--
1.8.0
^ permalink raw reply
* [PATCH 1/2] completion: refactor __gitcomp related tests
From: Felipe Contreras @ 2012-10-22 1:39 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jeff King, SZEDER Gábor, Felipe Contreras
In-Reply-To: <1350869941-22485-1-git-send-email-felipe.contreras@gmail.com>
Lots of duplicated code!
No functional changes.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
t/t9902-completion.sh | 72 ++++++++++++++++-----------------------------------
1 file changed, 23 insertions(+), 49 deletions(-)
diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
index cbd0fb6..1c6952a 100755
--- a/t/t9902-completion.sh
+++ b/t/t9902-completion.sh
@@ -72,87 +72,61 @@ test_completion_long ()
newline=$'\n'
-test_expect_success '__gitcomp - trailing space - options' '
- sed -e "s/Z$//" >expected <<-\EOF &&
- --reuse-message=Z
- --reedit-message=Z
- --reset-author Z
- EOF
+test_gitcomp ()
+{
+ sed -e 's/Z$//' > expected &&
(
local -a COMPREPLY &&
- cur="--re" &&
- __gitcomp "--dry-run --reuse-message= --reedit-message=
- --reset-author" &&
+ cur="$1" &&
+ shift &&
+ __gitcomp "$@" &&
IFS="$newline" &&
echo "${COMPREPLY[*]}" > out
) &&
test_cmp expected out
+}
+
+test_expect_success '__gitcomp - trailing space - options' '
+ test_gitcomp "--re" "--dry-run --reuse-message= --reedit-message=
+ --reset-author" <<-EOF
+ --reuse-message=Z
+ --reedit-message=Z
+ --reset-author Z
+ EOF
'
test_expect_success '__gitcomp - trailing space - config keys' '
- sed -e "s/Z$//" >expected <<-\EOF &&
+ test_gitcomp "br" "branch. branch.autosetupmerge
+ branch.autosetuprebase browser." <<-\EOF
branch.Z
branch.autosetupmerge Z
branch.autosetuprebase Z
browser.Z
EOF
- (
- local -a COMPREPLY &&
- cur="br" &&
- __gitcomp "branch. branch.autosetupmerge
- branch.autosetuprebase browser." &&
- IFS="$newline" &&
- echo "${COMPREPLY[*]}" > out
- ) &&
- test_cmp expected out
'
test_expect_success '__gitcomp - option parameter' '
- sed -e "s/Z$//" >expected <<-\EOF &&
+ test_gitcomp "--strategy=re" "octopus ours recursive resolve subtree" \
+ "" "re" <<-\EOF
recursive Z
resolve Z
EOF
- (
- local -a COMPREPLY &&
- cur="--strategy=re" &&
- __gitcomp "octopus ours recursive resolve subtree
- " "" "re" &&
- IFS="$newline" &&
- echo "${COMPREPLY[*]}" > out
- ) &&
- test_cmp expected out
'
test_expect_success '__gitcomp - prefix' '
- sed -e "s/Z$//" >expected <<-\EOF &&
+ test_gitcomp "branch.me" "remote merge mergeoptions rebase" \
+ "branch.maint." "me" <<-\EOF
branch.maint.merge Z
branch.maint.mergeoptions Z
EOF
- (
- local -a COMPREPLY &&
- cur="branch.me" &&
- __gitcomp "remote merge mergeoptions rebase
- " "branch.maint." "me" &&
- IFS="$newline" &&
- echo "${COMPREPLY[*]}" > out
- ) &&
- test_cmp expected out
'
test_expect_success '__gitcomp - suffix' '
- sed -e "s/Z$//" >expected <<-\EOF &&
+ test_gitcomp "branch.me" "master maint next pu" "branch." \
+ "ma" "." <<-\EOF
branch.master.Z
branch.maint.Z
EOF
- (
- local -a COMPREPLY &&
- cur="branch.me" &&
- __gitcomp "master maint next pu
- " "branch." "ma" "." &&
- IFS="$newline" &&
- echo "${COMPREPLY[*]}" > out
- ) &&
- test_cmp expected out
'
test_expect_success 'basic' '
--
1.8.0
^ permalink raw reply related
* [PATCH 2/2] completion: simplify __gitcomp test helper
From: Felipe Contreras @ 2012-10-22 1:39 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jeff King, SZEDER Gábor, Felipe Contreras
In-Reply-To: <1350869941-22485-1-git-send-email-felipe.contreras@gmail.com>
By using print_comp as suggested by SZEDER Gábor.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
t/t9902-completion.sh | 13 +++++--------
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
index 1c6952a..2e7fc06 100755
--- a/t/t9902-completion.sh
+++ b/t/t9902-completion.sh
@@ -74,15 +74,12 @@ newline=$'\n'
test_gitcomp ()
{
+ local -a COMPREPLY &&
sed -e 's/Z$//' > expected &&
- (
- local -a COMPREPLY &&
- cur="$1" &&
- shift &&
- __gitcomp "$@" &&
- IFS="$newline" &&
- echo "${COMPREPLY[*]}" > out
- ) &&
+ cur="$1" &&
+ shift &&
+ __gitcomp "$@" &&
+ print_comp &&
test_cmp expected out
}
--
1.8.0
^ permalink raw reply related
* [PATCH 0/2] completion: test simplifications
From: Felipe Contreras @ 2012-10-22 1:38 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jeff King, SZEDER Gábor, Felipe Contreras
As the subject says. These came up in a discussion with SZEDER.
Felipe Contreras (2):
completion: refactor __gitcomp related tests
completion: simplify __gitcomp test helper
t/t9902-completion.sh | 71 +++++++++++++++------------------------------------
1 file changed, 21 insertions(+), 50 deletions(-)
--
1.8.0
^ permalink raw reply
* Re: [PATCH v5 1/3] completion: add new __gitcompadd helper
From: Felipe Contreras @ 2012-10-22 0:41 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: git, Junio C Hamano, Matthieu Moy
In-Reply-To: <20121017172808.GD2156@goldbirke>
On Wed, Oct 17, 2012 at 7:28 PM, SZEDER Gábor <szeder@ira.uka.de> wrote:
> On Sun, Oct 14, 2012 at 05:52:49PM +0200, Felipe Contreras wrote:
>> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
>> index d743e56..01325de 100644
>> --- a/contrib/completion/git-completion.bash
>> +++ b/contrib/completion/git-completion.bash
>> @@ -225,6 +225,11 @@ _get_comp_words_by_ref ()
>> fi
>> fi
>>
>> +__gitcompadd ()
>> +{
>> + COMPREPLY=($(compgen -W "$1" -P "$2" -S "$4" -- "$3"))
>> +}
>> +
>> # Generates completion reply with compgen, appending a space to possible
>> # completion words, if necessary.
>> # It accepts 1 to 4 arguments:
>> @@ -238,13 +243,11 @@ __gitcomp ()
>>
>> case "$cur_" in
>> --*=)
>> - COMPREPLY=()
>> + __gitcompadd
>> ;;
>> *)
>> local IFS=$'\n'
>> - COMPREPLY=($(compgen -P "${2-}" \
>> - -W "$(__gitcomp_1 "${1-}" "${4-}")" \
>> - -- "$cur_"))
>> + __gitcompadd "$(__gitcomp_1 "${1-}" "${4-}")" "${2-}" "$cur_" ""
>> ;;
>> esac
>> }
>> @@ -261,7 +264,7 @@ __gitcomp ()
>> __gitcomp_nl ()
>> {
>> local IFS=$'\n'
>> - COMPREPLY=($(compgen -P "${2-}" -S "${4- }" -W "$1" -- "${3-$cur}"))
>> + __gitcompadd "$1" "${2-}" "${3-$cur}" "${4- }"
>> }
>
> I feel hesitant about this change. One of the ways I'm exploring to
> fix the issues with shell metacharacters and expansion in compgen is
> to actually replace compgen. We already iterate over all possible
> completion words in __gitcomp_1(), so it doesn't make much of a
> difference to do the filtering for the current word while we are at
> it. However, the way __gitcompadd() encapsulates COMPREPLY=($(compgen
> ...)), and tha basic idea of never touching COMPREPLY directly make
> this basically impossible.
How is it impossible? You can still replace compgen, all you have to
do is modify __gitcompadd and replace that code with whatever custom
code you want. You can change the arguments and everything. The only
limitation is that it should be the only place where COMPREPLY is
modified, and all is good. Well, it doesn't have to be only _one_
place, but the less functions that do this, the better.
>> __git_heads ()
>> @@ -486,7 +489,7 @@ __git_complete_remote_or_refspec ()
>> case "$cmd" in
>> push) no_complete_refspec=1 ;;
>> fetch)
>> - COMPREPLY=()
>> + __gitcompadd
>> return
>> ;;
>> *) ;;
>> @@ -502,7 +505,7 @@ __git_complete_remote_or_refspec ()
>> return
>> fi
>> if [ $no_complete_refspec = 1 ]; then
>> - COMPREPLY=()
>> + __gitcompadd
>> return
>> fi
>> [ "$remote" = "." ] && remote=
>> @@ -776,7 +779,7 @@ _git_am ()
>> "
>> return
>> esac
>> - COMPREPLY=()
>> + __gitcompadd
>
> These changes effectively run compgen in a subshell to generate an
> empty completion reply. While it doesn't really matter on Linux,
> it'll add another half a tenth of a second delay in those cases on my
> Windows machine. At least it should be conditional, i.e. $(compgen
> ...) shouldn't be executed when there are no possible completion
> words.
>
> However, I think those COMPREPLY=() assignments are pointless anyway.
> COMPREPLY is always empty when completion functions are invoked, so
> there is no need to explicitly set it to an empty array when we don't
> provide any words for completion. Their only use is basically to
> explicitly tell us humans that in those cases we don't offer any words
> for completion. But we don't do that consistently: there are several
> places without offering words for completion and without COMPREPLY=(),
> e.g. the '__git_has_doubledash && return' pattern.
>
> Perhaps it would be time to get rid of these COMPREPLY=() assignments?
I'm all for it, I never understood what was the purpose of that. I
believe zsh could benefit from this information to decide whether to
run the default completion (e.g. files) or not, but as you said, if
it's not used consistently for bash, there's no point in trying.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: looking for suggestions for managing a tree of server configs
From: david @ 2012-10-21 23:33 UTC (permalink / raw)
To: Drew Northup; +Cc: Junio C Hamano, git
In-Reply-To: <CAM9Z-n=VGM4cjrZxMz=n5LwDsvuG6uwXymh4J3Gjq4mYJoGPcg@mail.gmail.com>
On Sun, 21 Oct 2012, Drew Northup wrote:
> On Sat, Oct 20, 2012 at 10:34 PM, <david@lang.hm> wrote:
>> On Sat, 20 Oct 2012, Drew Northup wrote:
>>> On Sun, Oct 14, 2012 at 12:57 AM, <david@lang.hm> wrote:
>>>> On Sat, 13 Oct 2012, Junio C Hamano wrote:
>>>>> david@lang.hm writes:
>>>>>>
>>>>>> today I have just a single git tree covering everything, and I make a
>>>>>> commit each time one of the per-server directories is updated, and
>>>>>> again when the top-level stuff is created.
>>>>>
>>>>> if a large portion of the configuration for these servers are
>>>>> shared, it might not be a bad idea to have a canonical "gold-master"
>>>>> configuration branch, to which the shared updates are applied, with
>>>>> a branch per server that forks from that canonical branch to keep
>>>>> the machine specific tweaks
>>>>
>>>> In an ideal world yes, but right now these machines are updated by many
>>>> different tools (unforuntantly including 'vi'), so
>>>> these directories aren't the config to be pushed out to the boxes, it's
>>>> instead an archived 'what is', the result of changes from all the tools.
>
> So you need to save what is there before pulling changes from the
> master. That's no different from doing development work on an active
> code base.
I think I've done a poor job of explaining my problem.
I'm not looking for tips on how to manage the systems themselves, I'm
looking for suggestions on how to manage this data that I'm already
gathering on this reporting server.
I have the problem that different departments have their own (different)
preferred tools for implementing changes. There are 6 different
departments that need to be involved with a single system to build and
maintain it. Each department has their 'standard' way of doing things. At
least two of these departments are using different, central configuration
(i.e. puppet like) tools.
As a result, I am not looking to pull changes from the central location.
I'm just trying to gather information and be able to produce reports about
the systems (Including "This is what all the different configs files on
this server were like at time X"). I'm not using the distributed features
of git at this time.
I've got existing tools that do a very similar job to what it sounds like
sysconfcollect does that gather the non-sensitive info from all my remote
machines and sends the data to my central server. These tools send an
update whenever 'significant' changes are made, and in addition do a
scheduled update to catch less significant changes.
On my central server I have the directory configs-current that then has a
subdirectory details/systemname for each system that contains all the
information about htat system (populated by scripts that parse apart the
data mentioned above)
In other files and directories in configs-current I have lots of more
global data and reports. This includes things like a report of every
interface on every machine, the IP address, does it have link, what speed
is it at, etc.
Right now I have one git tree for configs-current and each time I update a
details/systemname tree I do
git add -a configs-current/details/$systemname
git commit -m'system update from $servername'
then when I run the summary scripts I do
git add -a configs-current
git commit -m'summary update'
This has been working for a few years
However, trying to go back in history to find a change on one system is a
pain.
Right now the updates accumulate until I manually trigger a processing
cycle to update the files. I would like to make it so that the updates to
each system's details/systemname directory is done automatically as the
e-mail from that system arrives, and this could result in parallel
updates. I don't think that git will handle this well in one tree with the
existing process (different processes doing git add and git commits in
parallel will end up mixing their data)
As one big tree, this has lots of commits (a couple hundred each update),
and this is making it slow to try and track changes to a particular file
in a particular system.
I'm thinking that splitting the history tracking per-server should make
everything faster.
I'm wondering if I should do a subproject for each details/systemname
directory, or if there is something else I can do to make this tracking of
the data better.
Doing a single repository with lots of branches doesn't seem like it would
work as I need to get at the data from all the branches at the same time.
I guess I could do something with branches on one repository, with a
different worktree for each system, but that seems a bit fragile (one
command with the wrong environment variables and it coudl really tangle
things up)
David Lang
^ permalink raw reply
* Re: [PATCH] gitk: Update Swedish translation (296t)
From: Paul Mackerras @ 2012-10-21 22:28 UTC (permalink / raw)
To: Peter Krefting; +Cc: Git Mailing List
In-Reply-To: <alpine.DEB.2.00.1210030820270.20444@ds9.cixit.se>
On Wed, Oct 03, 2012 at 08:22:17AM +0100, Peter Krefting wrote:
> This patch updates the Swedish translation for gitk. To avoid the
> UTF-8 encoding of the file to be mangled by my email software, the
> patch is attached gzip'ed.
>
> --
> \\// Peter - http://www.softwolves.pp.se/
Thanks, applied.
Paul.
^ permalink raw reply
* Re: [BUG] gitk: clicking on a connecting line produces can't read "cflist_top"
From: Paul Mackerras @ 2012-10-21 22:25 UTC (permalink / raw)
To: Stefan Haller; +Cc: Johannes Sixt, git
In-Reply-To: <1349383817-14457-1-git-send-email-stefan@haller-berlin.de>
On Thu, Oct 04, 2012 at 10:50:15PM +0200, Stefan Haller wrote:
> Sorry, I didn't realize that there is a display mode where the
> list of files is empty, not even showing a "Comments" entry.
>
> Here's a patch that fixes it, plus another patch that is only related
> in so far as the bug that it fixes was introduced by the same commit.
>
> [PATCH 1/2] gitk: Fix error message when clicking on a connecting line
> [PATCH 2/2] gitk: When searching, only highlight files when in Patch mode
Thanks, applied both.
Paul.
^ permalink raw reply
* Re: [PATCH] gitk: Fix crash when not using themed widgets
From: Paul Mackerras @ 2012-10-21 22:22 UTC (permalink / raw)
To: Marcus Karlsson; +Cc: git
In-Reply-To: <1349644874-22988-1-git-send-email-mk@acc.umu.se>
On Sun, Oct 07, 2012 at 11:21:14PM +0200, Marcus Karlsson wrote:
> When configured not to use themed widgets gitk may crash on launch with
> a message that says that the image "bm-left disabled bm-left-gray"
> doesn't exist. This happens when the left and right arrow buttons are
> created.
>
> The crash can be avoided by configuring the buttons differently
> depending on whether or not themed widgets are used. If themed widgets
> are not used then only set the images to bm-left and bm-right
> respectively, and keep the old behavior when themed widgets are used.
>
> The previous behaviour was added in f062e50f to work around a bug in Tk
> on OS X where the disabled state did not display properly. The buttons
> may still not display correctly, however the workaround added in
> f062e50f will still apply if gitk is used with themed widgets.
>
> Make gitk not crash on launch when not using themed widgets.
>
> Signed-off-by: Marcus Karlsson <mk@acc.umu.se>
Thanks, applied.
Paul.
^ permalink raw reply
* Re: [PATCH] transport-helper: check when helpers fail
From: Felipe Contreras @ 2012-10-21 22:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeff King, Sverre Rabbelier, Shawn O. Pearce
In-Reply-To: <7v7gqjftuj.fsf@alter.siamese.dyndns.org>
On Sun, Oct 21, 2012 at 10:33 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>> +int check_command(struct child_process *cmd)
>> +{
>> + int status;
>> + pid_t pid;
>> +
>> + pid = waitpid(cmd->pid, &status, WNOHANG);
>> +
>> + if (pid < 0)
>> + return -1;
>> + if (WIFSIGNALED(status))
>> + return WTERMSIG(status);
>> + if (WIFEXITED(status))
>> + return WEXITSTATUS(status);
>> +
>> + return 0;
>> +}
>
> It is nice to have a separate helper that would theoretically be
> useful by anybody who runs a child process, but I have to wonder:
>
> - How other codepaths that run child process check their results?
> Do they ignore the result altogether? Do they check the results
> in an ad-hoc way without a good reason? Do they check the
> results differently because their error handling need to be
> different?
They probably check at the end, truly waiting for the process to
finish, that's not what we want, thus the WNOHANG that apparently
nobody else in git is using.
The reason is that the transport-helpers are special; they are
re-used, so we can't wait for the process to finish after running a
certain command.
> With this, I am not requesting to port these other codepaths to
> use this helper in this patch series. But designing the helper
> with potential others' use in mind is within the scope of this
> patch.
That's what I did. If somebody else needs to check the status of the
command mid-stream, they can do that.
> - How does the caller use the return value from this helper? I can
> see that "zero is success, non-zero is failure", unless there is
> a platform what defines a signum 0 for some signal that can kill
> the child process. But I am not sure if the caller can tell more
> than that from the return value ("did it die with a signal, or
> did it exit with non-zero status"?)
I don't really care, I'm fine returning -1 on all errors.
>> diff --git a/t/t5800-remote-helpers.sh b/t/t5800-remote-helpers.sh
>> index e7dc668..d4b17ae 100755
>> --- a/t/t5800-remote-helpers.sh
>> +++ b/t/t5800-remote-helpers.sh
>> @@ -145,4 +145,10 @@ test_expect_failure 'push new branch with old:new refspec' '
>> compare_refs clone HEAD server refs/heads/new-refspec
>> '
>>
>> +test_expect_success 'proper failure checks' '
>> + export GIT_REMOTE_TESTGIT_FAILURE=1 &&
>> + ! git clone "testgit::$PWD/server" failure 2> errors &&
>> + grep -q "Error while running helper" errors
>> +'
>> +
>> test_done
>
> Please be nicer to people who come *after* you are done with this
> change. Forcing failure will propagate to any new test added after
> this piece with this patch.
>
> Perhaps like this:
>
> test_expect_success 'proper failure checks' '
> (
> GIT_REMOTE_TESTGIT_FAILURE=1 &&
> export GIT_REMOTE_TESTGIT_FAILURE &&
> test_must_fail git clone "testgit::$PWD/server" failure
> ) 2>errors &&
> grep "Error while running helper" errors
> '
LGTM.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH v2 0/2] Re: gitk: can't reload commits with new key binding
From: Paul Mackerras @ 2012-10-21 22:19 UTC (permalink / raw)
To: Andrew Wong; +Cc: git, gitster, szeder
In-Reply-To: <1349190285-7788-1-git-send-email-andrew.kw.w@gmail.com>
On Tue, Oct 02, 2012 at 11:04:43AM -0400, Andrew Wong wrote:
> Refactored the code for binding modified function keys as Junio suggested.
>
> Andrew Wong (2):
> gitk: Refactor code for binding modified function keys
> gitk: Use bindshiftfunctionkey to bind Shift-F5
>
> gitk | 10 +++++++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
Thanks, applied both patches.
Paul.
^ permalink raw reply
* What's cooking in git.git (Oct 2012, #07; Sun, 21)
From: Junio C Hamano @ 2012-10-21 22:11 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'.
The 1.8.0 release has been tagged. I'd disappear for a few weeks
without carrying a computer, and Git will be in steady hands of Jeff
King (thanks) in the meantime.
You can find the changes described here in the integration branches of the
repositories listed at
http://git-blame.blogspot.com/p/git-public-repositories.html
--------------------------------------------------
[New Topics]
* jc/maint-fetch-tighten-refname-check (2012-10-19) 1 commit
- get_fetch_map(): tighten checks on dest refs
This was split out from discarded jc/maint-push-refs-all topic.
* jh/symbolic-ref-d (2012-10-21) 1 commit
- git symbolic-ref --delete $symref
Add "symbolic-ref -d SYM" to delete a symbolic ref SYM.
It is already possible to remove a symbolic ref with "update-ref -d
--no-deref", but it may be a good addition for completeness.
* jh/update-ref-d-through-symref (2012-10-21) 2 commits
- Fix failure to delete a packed ref through a symref
- t1400-update-ref: Add test verifying bug with symrefs in delete_ref()
(this branch uses rs/branch-del-symref.)
"update-ref -d --deref SYM" to delete a ref through a symbolic ref
that points to it did not remove it correctly.
--------------------------------------------------
[Stalled]
* rc/maint-complete-git-p4 (2012-09-24) 1 commit
(merged to 'next' on 2012-09-25 at 116e58f)
+ Teach git-completion about git p4
Comment from Pete will need to be addressed in a follow-up patch.
* as/test-tweaks (2012-09-20) 7 commits
- tests: paint unexpectedly fixed known breakages in bold red
- tests: test the test framework more thoroughly
- [SQUASH] t/t0000-basic.sh: quoting of TEST_DIRECTORY is screwed up
- tests: refactor mechanics of testing in a sub test-lib
- tests: paint skipped tests in bold blue
- tests: test number comes first in 'not ok $count - $message'
- tests: paint known breakages in bold yellow
Various minor tweaks to the test framework to paint its output
lines in colors that match what they mean better.
Has the "is this really blue?" issue Peff raised resolved???
* 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/blame-no-follow (2012-09-21) 2 commits
- 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.
Stalled mostly due to lack of responses.
* jc/doc-default-format (2012-10-07) 2 commits
- [SQAUSH] allow "cd Doc* && make DEFAULT_DOC_TARGET=..."
- Allow generating a non-default set of documentation
Need to address the installation half if this is to be any useful.
* mk/maint-graph-infinity-loop (2012-09-25) 1 commit
- graph.c: infinite loop in git whatchanged --graph -m
The --graph code fell into infinite loop when asked to do what the
code did not expect ;-)
Anybody who worked on "--graph" wants to comment?
Stalled mostly due to lack of responses.
* jc/add-delete-default (2012-08-13) 1 commit
(merged to 'next' on 2012-10-11 at bd9e5cb)
+ 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.
Waiting for comments.
* 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.
"The first remote becomes the default" bit is better done as a
separate step.
--------------------------------------------------
[Cooking]
* mh/ceiling (2012-10-21) 8 commits
- string_list_longest_prefix(): remove function
- normalize_ceiling_entry(): resolve symlinks
- longest_ancestor_length(): require prefix list entries to be normalized
- longest_ancestor_length(): take a string_list argument for prefixes
- longest_ancestor_length(): use string_list_split()
- Introduce new function real_path_if_valid()
- real_path_internal(): add comment explaining use of cwd
- Introduce new static function real_path_internal()
Elements of GIT_CEILING_DIRECTORIES list may not match the real
pathname we obtain from getcwd(), leading the GIT_DIR discovery
logic to escape the ceilings the user thought to have specified.
* js/mingw-fflush-errno (2012-10-17) 1 commit
(merged to 'next' on 2012-10-18 at 43d6ebb)
+ maybe_flush_or_die: move a too-loose Windows specific error
Will merge to 'master' in the first batch after 1.8.0 ships.
* mo/cvs-server-cleanup (2012-10-16) 10 commits
(merged to 'next' on 2012-10-18 at 5a60da1)
+ cvsserver status: provide real sticky info
+ cvsserver: cvs add: do not expand directory arguments
+ cvsserver: use whole CVS rev number in-process; don't strip "1." prefix
+ cvsserver: split up long lines in req_{status,diff,log}
+ cvsserver: clean up client request handler map comments
+ cvsserver: remove unused functions _headrev and gethistory
+ cvsserver update: comment about how we shouldn't remove a user-modified file
+ cvsserver: add comments about database schema/usage
+ cvsserver: removed unused sha1Or-k mode from kopts_from_path
+ cvsserver t9400: add basic 'cvs log' test
(this branch is used by mo/cvs-server-updates.)
* mo/cvs-server-updates (2012-10-16) 10 commits
- 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
(this branch uses mo/cvs-server-cleanup.)
* ta/doc-cleanup (2012-10-18) 5 commits
- Documentation/howto: convert plain text files to asciidoc
- Documentation/technical: convert plain text files to asciidoc
- Change headline of technical/send-pack-pipeline.txt to not confuse its content with content from git-send-pack.txt
- Shorten two over-long lines in git-bisect-lk2009.txt by abbreviating some sha1
- Split over-long synopsis in git-fetch-pack.txt into several lines
Misapplication of a patch fixed; the ones near the tip needs to
update the links to point at the html files, though.
* lt/diff-stat-show-0-lines (2012-10-17) 1 commit
- Fix "git diff --stat" for interesting - but empty - file changes
We failed to mention a file without any content change but whose
permission bit was modified, or (worse yet) a new file without any
content in the "git diff --stat" output.
* jc/prettier-pretty-note (2012-10-19) 7 commits
- Documentation: decribe format-patch --notes
- format-patch --notes: show notes after three-dashes
- format-patch: append --signature after notes
- pretty_print_commit(): do not append notes message
- pretty: prepare notes message at a centralized place
- format_note(): simplify API
- pretty: remove reencode_commit_message()
Needs updates to the placeholder documentation.
* jk/sh-setup-in-filter-branch (2012-10-18) 2 commits
(merged to 'next' on 2012-10-18 at 3864adc)
+ filter-branch: use git-sh-setup's ident parsing functions
+ git-sh-setup: refactor ident-parsing functions
Will merge to 'master' in the second batch after 1.8.0 ships.
* jk/strbuf-detach-always-non-null (2012-10-18) 1 commit
(merged to 'next' on 2012-10-18 at 54561c7)
+ strbuf: always return a non-NULL value from strbuf_detach
Will merge to 'master' in the first batch after 1.8.0 ships.
* nd/status-long (2012-10-18) 1 commit
(merged to 'next' on 2012-10-18 at 53940a1)
+ status: add --long output format option
Allow an earlier "--short" option on the command line to be
countermanded with the "--long" option for "git status" and "git
commit".
Will merge to 'master' in the second batch after 1.8.0 ships.
* rs/branch-del-symref (2012-10-18) 5 commits
(merged to 'next' on 2012-10-18 at 68ee254)
+ branch: show targets of deleted symrefs, not sha1s
+ branch: skip commit checks when deleting symref branches
+ branch: delete symref branch, not its target
+ branch: factor out delete_branch_config()
+ branch: factor out check_branch_commit()
(this branch is used by jh/update-ref-d-through-symref.)
A symbolic ref refs/heads/SYM was not correctly removed with
"git branch -d SYM"; the command removed the ref pointed by
SYM instead.
Will merge to 'master' in the second batch after 1.8.0 ships.
* sz/maint-curl-multi-timeout (2012-10-19) 1 commit
- Fix potential hang in https handshake
Sometimes curl_multi_timeout() function suggested a wrong timeout
value when there is no file descriptors to wait on and the http
transport ended up sleeping for minutes in select(2) system call.
Detect this and reduce the wait timeout in such a case.
* jc/same-encoding (2012-10-18) 1 commit
- reencode_string(): introduce and use same_encoding()
Various codepaths checked if two encoding names are the same using
ad-hoc code and some of them ended up asking iconv() to convert
between "utf8" and "UTF-8". The former is not a valid way to spell
the encoding name, but often people use it by mistake, and we
equated them in some but not all codepaths. Introduce a new helper
function to make these codepaths consistent.
* nd/tree-walk-enum-cleanup (2012-10-19) 1 commit
- tree-walk: use enum interesting instead of integer
* jk/maint-http-init-not-in-result-handler (2012-10-12) 2 commits
(merged to 'next' on 2012-10-16 at cc88829)
+ http: do not set up curl auth after a 401
+ remote-curl: do not call run_slot repeatedly
Further clean-up to the http codepath that picks up results after
cURL library is done with one request slot.
Will merge to 'master' in the second batch after 1.8.0 ships.
* nd/grep-true-path (2012-10-12) 1 commit
(merged to 'next' on 2012-10-16 at 8a75ac8)
+ grep: stop looking at random places for .gitattributes
"git grep -e pattern <tree>" asked the attribute system to read
"<tree>:.gitattributes" file in the working tree, which was
nonsense.
Will merge to 'master' in the second batch after 1.8.0 ships.
* cr/cvsimport-local-zone (2012-10-16) 1 commit
- git-cvsimport: allow author-specific timezones
Allows "cvsimport" to read per-author timezone from the author info
file.
* fc/completion-send-email-with-format-patch (2012-10-16) 1 commit
- completion: add format-patch options to send-email
* fc/zsh-completion (2012-10-15) 3 commits
- completion: add new zsh completion
- tests: use __gitcompadd to simplify completion tests
- completion: add new __gitcompadd helper
* jc/apply-trailing-blank-removal (2012-10-12) 1 commit
- apply.c:update_pre_post_images(): the preimage can be truncated
Fix to update_pre_post_images() that did not take into account the
possibility that whitespace fix could shrink the preimage and
change the number of lines in it.
Extra set of eyeballs appreciated.
* jn/warn-on-inaccessible-loosen (2012-10-14) 4 commits
- config: exit on error accessing any config file
- doc: advertise GIT_CONFIG_NOSYSTEM
- config: treat user and xdg config permission problems as errors
- config, gitignore: failure to access with ENOTDIR is ok
An RFC to deal with a situation where .config/git is a file and we
notice .config/git/config is not readable due to ENOTDIR, not
ENOENT; I think a bit more refactored approach to consistently
address permission errors across config, exclude and attrs is
desirable. Don't we also need a check for an opposite situation
where we open .config/git/config or .gitattributes for reading but
they turn out to be directories?
* rs/lock-correct-ref-during-delete (2012-10-16) 1 commit
(merged to 'next' on 2012-10-16 at 850b5b2)
+ refs: lock symref that is to be deleted, not its target
When "update-ref -d --no-deref SYM" tried to delete a symbolic ref
SYM, it incorrectly locked the underlying reference pointed by SYM,
not the symbolic ref itself.
* as/check-ignore (2012-10-19) 13 commits
- Documentation/check-ignore: we show the deciding match, not the first
- Add git-check-ignore sub-command
- dir.c: provide free_directory() for reclaiming dir_struct memory
- pathspec.c: move reusable code from builtin/add.c
- dir.c: refactor treat_gitlinks()
- dir.c: keep track of where patterns came from
- 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
(this branch uses nd/attr-match-optim and nd/attr-match-optim-more; is tangled with nd/wildmatch.)
Duy helped to reroll this.
* js/format-2047 (2012-10-18) 7 commits
(merged to 'next' on 2012-10-18 at 5b9a629)
+ format-patch tests: check quoting/encoding in To: and Cc: headers
+ format-patch: fix rfc2047 address encoding with respect to rfc822 specials
+ format-patch: make rfc2047 encoding more strict
+ format-patch: introduce helper function last_line_length()
+ format-patch: do not wrap rfc2047 encoded headers too late
+ format-patch: do not wrap non-rfc2047 headers too early
+ utf8: fix off-by-one wrapping of text
Fixes many rfc2047 quoting issues in the output from format-patch.
* km/send-email-compose-encoding (2012-10-10) 1 commit
(merged to 'next' on 2012-10-11 at d94bd05)
+ git-send-email: introduce compose-encoding
"git send-email --compose" can let the user create a non-ascii
cover letter message, but there was not a way to mark it with
appropriate content type before sending it out.
Will merge to 'master' in the second batch after 1.8.0 ships.
* so/prompt-command (2012-10-17) 4 commits
(merged to 'next' on 2012-10-17 at 0843a8b)
+ coloured git-prompt: paint detached HEAD marker in red
(merged to 'next' on 2012-10-16 at adf81be)
+ Fix up colored git-prompt
(merged to 'next' on 2012-10-11 at 1a14825)
+ show color hints based on state of the git tree
+ Allow __git_ps1 to be used in PROMPT_COMMAND
Updates __git_ps1 so that it can be used as $PROMPT_COMMAND,
instead of being used for command substitution in $PS1, to embed
color escape sequences in its output.
* jc/test-say-color-avoid-echo-escape (2012-10-11) 1 commit
(merged to 'next' on 2012-10-11 at 639036d)
+ test-lib: Fix say_color () not to interpret \a\b\c in the message
Recent nd/wildmatch series was the first to reveal this ancient bug
in the test scaffolding.
Will merge to 'master' in the first batch after 1.8.0 ships.
* aw/rebase-am-failure-detection (2012-10-11) 1 commit
- rebase: Handle cases where format-patch fails
I am unhappy a bit about the possible performance implications of
having to store the output in a temporary file only for a rare case
of format-patch aborting.
* da/mergetools-p4 (2012-10-11) 1 commit
(merged to 'next' on 2012-10-12 at 16f5c06)
+ mergetools/p4merge: Handle "/dev/null"
Will merge to 'master' in the first batch after 1.8.0 ships.
* nd/wildmatch (2012-10-15) 13 commits
(merged to 'next' on 2012-10-16 at 5eaf3a4)
+ 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 uses nd/attr-match-optim and nd/attr-match-optim-more; is tangled with as/check-ignore.)
Allows pathname patterns in .gitignore and .gitattributes files
with double-asterisks "foo/**/bar" to match any number of directory
hierarchies.
I suspect that this needs to be plugged to pathspec matching code;
otherwise "git log -- 'Docum*/**/*.txt'" would not show the log for
commits that touch Documentation/git.txt, which would be confusing
to the users.
* 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.
* nd/attr-match-optim (2012-10-05) 2 commits
(merged to 'next' on 2012-10-08 at bfbdd8a)
+ attr: avoid searching for basename on every match
+ attr: avoid strlen() on every match
(this branch is used by as/check-ignore, nd/attr-match-optim-more and nd/wildmatch.)
Trivial and obvious optimization for finding attributes that match
a given path.
Will merge to 'master' in the first batch after 1.8.0 ships.
* nd/attr-match-optim-more (2012-10-15) 7 commits
(merged to 'next' on 2012-10-16 at 9baac99)
+ attr: more matching optimizations from .gitignore
+ gitignore: make pattern parsing code a separate function
+ exclude: split pathname matching code into a separate function
+ exclude: fix a bug in prefix compare optimization
+ exclude: split basename matching code into a separate function
+ exclude: stricten a length check in EXC_FLAG_ENDSWITH case
+ Merge commit 'f9f6e2c' into nd/attr-match-optim-more
(this branch is used by as/check-ignore and nd/wildmatch; uses nd/attr-match-optim.)
Start laying the foundation to build the "wildmatch" after we can
agree on its desired semantics.
* jc/grep-pcre-loose-ends (2012-10-09) 7 commits
(merged to 'next' on 2012-10-11 at fec8530)
+ log: honor grep.* configuration
+ log --grep: accept --basic-regexp and --perl-regexp
+ log --grep: use the same helper to set -E/-F options as "git grep"
+ revisions: initialize revs->grep_filter using grep_init()
+ grep: move pattern-type bits support to top-level grep.[ch]
+ grep: move the configuration parsing logic to grep.[ch]
+ builtin/grep.c: make configuration callback more reusable
"git log -F -E --grep='<ere>'" failed to use the given <ere>
pattern as extended regular expression, and instead looked for the
string literally. The early part of this series is a fix for it.
Will merge to 'master' in the second batch after 1.8.0 ships.
* jk/peel-ref (2012-10-04) 4 commits
(merged to 'next' on 2012-10-08 at 4adfa2f)
+ upload-pack: use peel_ref for ref advertisements
+ peel_ref: check object type before loading
+ peel_ref: do not return a null sha1
+ peel_ref: use faster deref_tag_noverify
Speeds up "git upload-pack" (what is invoked by "git fetch" on the
other side of the connection) by reducing the cost to advertise the
branches and tags that are available in the repository.
Will merge to 'master' in the first batch after 1.8.0 ships.
* fa/remote-svn (2012-10-07) 16 commits
(merged to 'next' on 2012-10-07 at 7b90cf4)
+ Add a test script for remote-svn
+ remote-svn: add marks-file regeneration
+ Add a svnrdump-simulator replaying a dump file for testing
+ remote-svn: add incremental import
+ remote-svn: Activate import/export-marks for fast-import
+ Create a note for every imported commit containing svn metadata
+ vcs-svn: add fast_export_note to create notes
+ Allow reading svn dumps from files via file:// urls
+ remote-svn, vcs-svn: Enable fetching to private refs
+ When debug==1, start fast-import with "--stats" instead of "--quiet"
+ Add documentation for the 'bidi-import' capability of remote-helpers
+ Connect fast-import to the remote-helper via pipe, adding 'bidi-import' capability
+ Add argv_array_detach and argv_array_free_detached
+ Add svndump_init_fd to allow reading dumps from arbitrary FDs
+ Add git-remote-testsvn to Makefile
+ Implement a remote helper for svn in C
A GSoC project.
Will merge to 'master' in the first batch after 1.8.0 ships.
* bw/config-lift-variable-name-length-limit (2012-10-01) 1 commit
(merged to 'next' on 2012-10-08 at 69f54f4)
+ Remove the hard coded length limit on variable names in config files
The configuration parser had an unnecessary hardcoded limit on
variable names that was not checked consistently. Lift the limit.
Will merge to 'master' in the first batch after 1.8.0 ships.
* jm/diff-context-config (2012-10-02) 2 commits
(merged to 'next' on 2012-10-02 at e57700a)
+ t4055: avoid use of sed 'a' command
(merged to 'next' on 2012-10-01 at 509a558)
+ diff: diff.context configuration gives default to -U
Teaches a new configuration variable to "git diff" Porcelain and
its friends.
Will merge to 'master' in the first batch after 1.8.0 ships.
* jl/submodule-add-by-name (2012-09-30) 2 commits
(merged to 'next' on 2012-10-08 at 9408d8d)
+ submodule add: Fail when .git/modules/<name> already exists unless forced
+ Teach "git submodule add" the --name option
If you remove a submodule, in order to keep the repository so that
"git checkout" to an older commit in the superproject history can
resurrect the submodule, the real repository will stay in $GIT_DIR
of the superproject. A later "git submodule add $path" to add a
different submodule at the same path will fail. Diagnose this case
a bit better, and if the user really wants to add an unrelated
submodule at the same path, give the "--name" option to give it a
place in $GIT_DIR of the superproject that does not conflict with
the original submodule.
Will merge to 'master' in the second batch after 1.8.0 ships.
* jl/submodule-rm (2012-09-29) 1 commit
(merged to 'next' on 2012-10-01 at 4e5c4fc)
+ submodule: teach rm to remove submodules unless they contain a git directory
"git rm submodule" cannot blindly remove a submodule directory as
its working tree may have local changes, and worse yet, it may even
have its repository embedded in it. Teach it some special cases
where it is safe to remove a submodule, specifically, when there is
no local changes in the submodule working tree, and its repository
is not embedded in its working tree but is elsewhere and uses the
gitfile mechanism to point at it.
Will merge to 'master' in the second batch after 1.8.0 ships.
* nd/pretty-placeholder-with-color-option (2012-09-30) 9 commits
- pretty: support %>> that steal trailing spaces
- pretty: support truncating in %>, %< and %><
- pretty: support padding placeholders, %< %> and %><
- pretty: two phase conversion for non utf-8 commits
- utf8.c: add utf8_strnwidth() with the ability to skip ansi sequences
- utf8.c: move display_mode_esc_sequence_len() for use by other functions
- pretty: support %C(auto[,N]) to turn on coloring on next placeholder(s)
- pretty: split parsing %C into a separate function
- pretty: share code between format_decoration and show_decorations
* jk/no-more-pre-exec-callback (2012-06-05) 1 commit
(merged to 'next' on 2012-10-12 at 69fed45)
+ pager: drop "wait for output to run less" hack
(Originally merged to 'next' on 2012-07-23)
Removes a workaround for buggy version of less older than version
406.
Will merge to 'master' in the first batch after 1.8.0 ships.
--------------------------------------------------
[Discarded]
* fa/vcs-svn (2012-10-07) 4 commits
- vcs-svn: remove repo_tree
- vcs-svn/svndump: rewrite handle_node(), begin|end_revision()
- vcs-svn/svndump: restructure node_ctx, rev_ctx handling
- svndump: move struct definitions to .h
(this branch uses fa/remote-svn.)
A follow-up to a GSoC project, but seems not quite ready.
* ph/credential-refactor (2012-09-02) 5 commits
- wincred: port to generic credential helper
- Merge branch 'ef/win32-cred-helper' into ph/credential-refactor
- osxkeychain: port to generic credential helper implementation
- gnome-keyring: port to generic helper implementation
- contrib: add generic credential helper
Attempts to refactor to share code among OSX keychain, Gnome keyring
and Win32 credential helpers. Turns out that the sharing wasn't
big enough to worth the churn.
* ms/contrib-thunderbird-updates (2012-08-31) 2 commits
- [SQUASH] minimum fixup
- Thunderbird: fix appp.sh format problems
Update helper to send out format-patch output using Thunderbird.
Seems to have design regression for silent users.
* jx/test-real-path (2012-08-27) 1 commit
- test: set the realpath of CWD as TRASH_DIRECTORY
Running tests with the "trash" directory elsewhere with the "--root"
option did not work well if the directory was specified by a symbolic
link pointing at it.
Seems broken as it makes $(pwd) and TRASH_DIRECTORY inconsistent.
* jc/maint-push-refs-all (2012-08-27) 2 commits
- get_fetch_map(): tighten checks on dest refs
- [BROKEN] fetch/push: allow refs/*:refs/*
This is broken (see the log message there). "git fetch/push
$there 'refs/*:refs/*'" already propagates heads, tags, notes,
etc. hierarchies; an attempt to propagate refs/stash will fail
against an older version of the other side and is not worth
supporting.
* tx/relative-in-the-future (2012-08-16) 2 commits
- date: show relative dates in the future
- date: refactor the relative date logic from presentation
Not my itch; rewritten an earlier submission by Tom Xue into
somewhat more maintainable form, though it breaks existing i18n.
Was waiting for a voluteer to fix it up, which never happend.
* jc/split-blob (2012-04-03) 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
- packfile: use varint functions
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 disappointed that the original patch series
that was sent long time 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" fanbois, 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 :-<.
^ permalink raw reply
* A note from the maintainer
From: Junio C Hamano @ 2012-10-21 22:10 UTC (permalink / raw)
To: git
Welcome to the Git development community.
This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.
* Mailing list and the community
The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>. You don't have to be
subscribed to send messages. The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".
Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.
If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise. Please
do not hesitate to send a reminder message in such a case. Messages
getting lost in the noise is a sign that people involved don't have
enough mental/time bandwidth to process them right at the moment, and
it often helps to wait until the list traffic becomes calmer before
sending such a reminder.
The list archive is available at a few public sites:
http://news.gmane.org/gmane.comp.version-control.git/
http://marc.theaimsgroup.com/?l=git
http://www.spinics.net/lists/git/
For those who prefer to read it over NNTP (including the maintainer):
nntp://news.gmane.org/gmane.comp.version-control.git
When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:
http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217
as it also allows people who subscribe to the mailing list as gmane
newsgroup to "jump to" the article.
Some members of the development community can sometimes also be found
on the #git IRC channel on Freenode. Its log is available at:
http://colabti.org/irclogger/irclogger_log/git
* Reporting bugs
When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work". "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken". It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.
Please remember to always state
- what you wanted to achieve;
- what you did (the version of git and the command sequence to reproduce
the behavior);
- what you saw happen (X above);
- what you expected to see (Y above); and
- how the last two are different.
See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.
* Repositories, branches and documentation.
My public git.git repositories are at:
git://git.kernel.org/pub/scm/git/git.git/
git://repo.or.cz/alt-git.git/
https://github.com/git/git/
https://code.google.com/p/git-core/
git://git.sourceforge.jp/gitroot/git-core/git.git/
git://git-core.git.sourceforge.net/gitroot/git-core/git-core/
A few gitweb interfaces are found at:
http://git.kernel.org/?p=git/git.git
http://repo.or.cz/w/alt-git.git
Preformatted documentation from the tip of the "master" branch can be
found in:
git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
git://repo.or.cz/git-{htmldocs,manpages}.git/
https://code.google.com/p/git-{htmldocs,manpages}.git/
https://github.com/gitster/git-{htmldocs,manpages}.git/
You can browse the HTML manual pages at:
http://git-htmldocs.googlecode.com/git/git.html
There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "pu".
The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting. Every now and then, a "feature
release" is cut from the tip of this branch and they typically are named
with three dotted decimal digits. The last such release was 1.8.0 done on
Oct 21, 2012. You can expect that the tip of the "master" branch is always
more stable than any of the released versions.
Whenever a feature release is made, "maint" branch is forked off from
"master" at that point. Obvious, safe and urgent fixes after a feature
release are applied to this branch and maintenance releases are cut from
it. The maintenance releases are named with four dotted decimal, named
after the feature release they are updates to; the last such release was
1.7.12.4. New features never go to this branch. This branch is also
merged into "master" to propagate the fixes forward as needed.
A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" and your patches are queued
there, and kept out of "master" while people test it out. The quality of
topic branches are judged primarily by the mailing list discussions.
Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master". It might
not be quite rock-solid, but is expected to work more or less without major
breakage. The "next" branch is where new and exciting things take place. A
topic that is in "next" is expected to be polished to perfection before it
is merged to "master".
The "pu" (proposed updates) branch bundles all the remaining topic branches.
The topics on the branch are not complete, well tested, nor well documented
and need further work. When a topic that was in "pu" proves to be in a
testable shape, it is merged to "next".
You can run "git log --first-parent master..pu" to see what topics are
currently in flight. Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "pu" in such a case.
The two branches "master" and "maint" are never rewound, and "next"
usually will not be either. After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.
Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release. There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged.
* Other people's trees, trusted lieutenants and credits.
Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent. As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.
Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:
- git-gui/ comes from git-gui project, maintained by Pat Thoyts:
git://repo.or.cz/git-gui.git
- gitk-git/ comes from Paul Mackerras's gitk project:
git://git.kernel.org/pub/scm/gitk/gitk.git
- po/ comes from the localization coordinator, Jiang Xin:
https://github.com/git-l10n/git-po/
I would like to thank everybody who helped to raise git into the current
shape. Especially I would like to thank the git list regulars whose help
I have relied on and expect to continue relying on heavily:
- Linus Torvalds, Shawn Pearce, Johannes Schindelin, Nicolas Pitre,
René Scharfe, Jeff King, Jonathan Nieder, Johan Herland, Johannes
Sixt, Sverre Rabbelier, Michael J Gruber, Nguyễn Thái Ngọc Duy,
Ævar Arnfjörð Bjarmason and Thomas Rast for helping with general
design and implementation issues and reviews on the mailing list.
- Shawn and Nicolas Pitre for helping with packfile design and
implementation issues.
- Martin Langhoff, Frank Lichtenheld and Ævar Arnfjörð Bjarmason for
cvsserver and cvsimport.
- Paul Mackerras for gitk.
- Eric Wong, David D. Kilzer and Sam Vilain for git-svn.
- Simon Hausmann, Pete Wyckoff and Luke Diamond for git-p4.
- Jakub Narebski, John Hawley, Petr Baudis, Luben Tuikov, Giuseppe
Bilotta for maintaining and enhancing gitweb.
- Ævar Arnfjörð Bjarmason for kicking off the i18n effort, and Jiang
Xin for volunteering to be the l10n coordinator.
- Jens Lehmann, Heiko Voigt and Lars Hjemli for submodule related
Porcelains.
- J. Bruce Fields, Jonathan Nieder, Michael J Gruber and Thomas Rast for
documentation (and countless others for proofreading and fixing).
- Alexandre Julliard for Emacs integration.
- David Aguilar and Charles Bailey for taking good care of git-mergetool
(and Theodore Ts'o for creating it in the first place) and git-difftool.
- Johannes Schindelin, Johannes Sixt, Erik Faye-Lund, Pat Thoyts and others
for their effort to move things forward on the Windows front.
- People on non-Linux platforms for keeping their eyes on portability;
especially, Randal Schwartz, Theodore Ts'o, Jason Riedy, Thomas Glanzmann,
Brandon Casey, Jeff King, Alex Riesen and countless others.
^ permalink raw reply
* [ANNOUNCE] Git v1.8.0
From: Junio C Hamano @ 2012-10-21 22:10 UTC (permalink / raw)
To: git; +Cc: Linux Kernel
The latest feature release Git v1.8.0 is now available at the
usual places.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
a03afc33f8f0723ad12649d79f1e8968526b4bf7 git-1.8.0.tar.gz
93c860cf4cd26d4b3e269b0903b833db1c1f0f8e git-htmldocs-1.8.0.tar.gz
a6fa49be36f265e85b7252d36364d4c7f38530ea git-manpages-1.8.0.tar.gz
Also the following public repositories all have a copy of the v1.8.0
tag and the master branch that the tag points at:
url = git://repo.or.cz/alt-git.git
url = https://code.google.com/p/git-core/
url = git://git.sourceforge.jp/gitroot/git-core/git.git
url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
url = https://github.com/gitster/git
Enjoy.
Git v1.8.0 Release Notes
========================
Backward compatibility notes
----------------------------
In the next major release (not *this* one), we will change the
behavior of the "git push" command.
When "git push [$there]" does not say what to push, we have used the
traditional "matching" semantics so far (all your branches were sent
to the remote as long as there already are branches of the same name
over there). We will use the "simple" semantics that pushes the
current branch to the branch with the same name, only when the current
branch is set to integrate with that remote branch. There is a user
preference configuration variable "push.default" to change this, and
"git push" will warn about the upcoming change until you set this
variable in this release.
"git branch --set-upstream" is deprecated and may be removed in a
relatively distant future. "git branch [-u|--set-upstream-to]" has
been introduced with a saner order of arguments.
Updates since v1.7.12
---------------------
UI, Workflows & Features
* A credential helper for Win32 to allow access to the keychain of
the logged-in user has been added.
* An initial port to HP NonStop.
* A credential helper to allow access to the Gnome keyring has been
added.
* When "git am" sanitizes the "Subject:" line, we strip the prefix from
"Re: subject" and also from a less common "re: subject", but left
the even less common "RE: subject" intact. Now we strip that too.
* It was tempting to say "git branch --set-upstream origin/master",
but that tells Git to arrange the local branch "origin/master" to
integrate with the currently checked out branch, which is highly
unlikely what the user meant. The option is deprecated; use the
new "--set-upstream-to" (with a short-and-sweet "-u") option
instead.
* "git cherry-pick" learned the "--allow-empty-message" option to
allow it to replay a commit without any log message.
* After "git cherry-pick -s" gave control back to the user asking
help to resolve conflicts, concluding "git commit" used to need to
be run with "-s" if the user wants to sign it off; now the command
leaves the sign-off line in the log template.
* "git daemon" learned the "--access-hook" option to allow an
external command to decline service based on the client address,
repository path, etc.
* "git difftool --dir-diff" learned to use symbolic links to prepare
a temporary copy of the working tree when available.
* "git grep" learned to use a non-standard pattern type by default if
a configuration variable tells it to.
* Accumulated updates to "git gui" has been merged.
* "git log -g" learned the "--grep-reflog=<pattern>" option to limit
its output to commits with a reflog message that matches the given
pattern.
* "git merge-base" learned the "--is-ancestor A B" option to tell if A is
an ancestor of B. The result is indicated by its exit status code.
* "git mergetool" now allows users to override the actual command used
with the mergetool.$name.cmd configuration variable even for built-in
mergetool backends.
* "git rebase -i" learned the "--edit-todo" option to open an editor
to edit the instruction sheet.
Foreign Interface
* "git svn" has been updated to work with SVN 1.7.
* "git p4" learned the "--conflicts" option to specify what to do when
encountering a conflict during "p4 submit".
Performance, Internal Implementation, etc.
* Git ships with a fall-back regexp implementation for platforms with
buggy regexp library, but it was easy for people to keep using their
platform regexp by mistake. A new test has been added to check this.
* The "check-docs" build target has been updated and greatly
simplified.
* The test suite is run under MALLOC_CHECK_ when running with a glibc
that supports the feature.
* The documentation in the TeXinfo format was using indented output
for materials meant to be examples that are better typeset in
monospace.
* Compatibility wrapper around some mkdir(2) implementations that
reject parameters with trailing slash has been introduced.
* Compatibility wrapper for systems that lack usable setitimer() has
been added.
* The option parsing of "git checkout" had error checking, dwim and
defaulting missing options, all mixed in the code, and issuing an
appropriate error message with useful context was getting harder.
The code has been reorganized to allow giving a proper diagnosis
when the user says "git checkout -b -t foo bar" (e.g. "-t" is not a
good name for a branch).
* Many internal uses of a "git merge-base" equivalent were only to see
if one commit fast-forwards to the other, which did not need the
full set of merge bases to be computed. They have been updated to
use less expensive checks.
* The heuristics to detect and silently convert latin1 to utf8 when
we were told to use utf-8 in the log message has been transplanted
from "mailinfo" to "commit" and "commit-tree".
* Messages given by "git <subcommand> -h" from many subcommands have
been marked for translation.
Also contains minor documentation updates and code clean-ups.
Fixes since v1.7.12
-------------------
Unless otherwise noted, all the fixes since v1.7.12 in the
maintenance track are contained in this release (see release notes
to them for details).
* The attribute system may be asked for a path that itself or its
leading directories no longer exists in the working tree, and it is
fine if we cannot open .gitattribute file in such a case. Failure
to open per-directory .gitattributes with error status other than
ENOENT and ENOTDIR should be diagnosed, but it wasn't.
* When looking for $HOME/.gitconfig etc., it is OK if we cannot read
them because they do not exist, but we did not diagnose existing
files that we cannot read.
* When "git am" is fed an input that has multiple "Content-type: ..."
header, it did not grok charset= attribute correctly.
* "git am" mishandled a patch attached as application/octet-stream
(e.g. not text/*); Content-Transfer-Encoding (e.g. base64) was not
honored correctly.
* "git blame MAKEFILE" run in a history that has "Makefile" but not
"MAKEFILE" should say "No such file MAKEFILE in HEAD", but got
confused on a case insensitive filesystem and failed to do so.
* Even during a conflicted merge, "git blame $path" always meant to
blame uncommitted changes to the "working tree" version; make it
more useful by showing cleanly merged parts as coming from the other
branch that is being merged.
* It was unclear in the documentation for "git blame" that it is
unnecessary for users to use the "--follow" option.
* Output from "git branch -v" contains "(no branch)" that could be
localized, but the code to align it along with the names of
branches was counting in bytes, not in display columns.
* "git cherry-pick A C B" used to replay changes in A and then B and
then C if these three commits had committer timestamps in that
order, which is not what the user who said "A C B" naturally
expects.
* A repository created with "git clone --single" had its fetch
refspecs set up just like a clone without "--single", leading the
subsequent "git fetch" to slurp all the other branches, defeating
the whole point of specifying "only this branch".
* Documentation talked about "first line of commit log" when it meant
the title of the commit. The description was clarified by defining
how the title is decided and rewording the casual mention of "first
line" to "title".
* "git cvsimport" did not thoroughly cleanse tag names that it
inferred from the names of the tags it obtained from CVS, which
caused "git tag" to barf and stop the import in the middle.
* Earlier we made the diffstat summary line that shows the number of
lines added/deleted localizable, but it was found irritating having
to see them in various languages on a list whose discussion language
is English, and this change has been reverted.
* "git fetch --all", when passed "--no-tags", did not honor the
"--no-tags" option while fetching from individual remotes (the same
issue existed with "--tags", but the combination "--all --tags" makes
much less sense than "--all --no-tags").
* "git fetch" over http had an old workaround for an unlikely server
misconfiguration; it turns out that this hurts debuggability of the
configuration in general, and has been reverted.
* "git fetch" over http advertised that it supports "deflate", which
is much less common, and did not advertise the more common "gzip" on
its Accept-Encoding header.
* "git fetch" over the dumb-http revision walker could segfault when
curl's multi interface was used.
* "git gc --auto" notified the user that auto-packing has triggered
even under the "--quiet" option.
* After "gitk" showed the contents of a tag, neither "Reread
references" nor "Reload" updated what is shown as the
contents of it when the user overwrote the tag with "git tag -f".
* "git log --all-match --grep=A --grep=B" ought to show commits that
mention both A and B, but when these three options are used with
--author or --committer, it showed commits that mention either A or
B (or both) instead.
* The "-Xours" backend option to "git merge -s recursive" was ignored
for binary files.
* "git p4", when "--use-client-spec" and "--detect-branches" are used
together, misdetected branches.
* "git receive-pack" (the counterpart to "git push") did not give
progress output while processing objects it received to the puser
when run over the smart-http protocol.
* When you misspell the command name you give to the "exec" action in
the "git rebase -i" instruction sheet you were told that 'rebase' is not a
git subcommand from "git rebase --continue".
* The subcommand in "git remote" to remove a defined remote was
"rm" and the command did not take a fully-spelled "remove".
* The interactive prompt that "git send-email" gives was error prone. It
asked "What e-mail address do you want to use?" with the address it
guessed (correctly) the user would want to use in its prompt,
tempting the user to say "y". But the response was taken as "No,
please use 'y' as the e-mail address instead", which is most
certainly not what the user meant.
* "git show --format='%ci'" did not give the timestamp correctly for
commits created without human readable name on the "committer" line.
* "git show --quiet" ought to be a synonym for "git show -s", but
wasn't.
* "git submodule frotz" was not diagnosed as "frotz" being an unknown
subcommand to "git submodule"; the user instead got a complaint
that "git submodule status" was run with an unknown path "frotz".
* "git status" honored the ignore=dirty settings in .gitmodules but
"git commit" didn't.
* "gitweb" did not give the correct committer timezone in its feed
output due to a typo.
----------------------------------------------------------------
Changes since v1.8.0-rc3 are as follows:
Andrew Wong (2):
git-gui: Detect full path when parsing arguments
git-gui: Don't prepend the prefix if value looks like a full path
Beat Bolli (2):
git-gui: Fix a loose/lose mistake
git-gui: remove .git/CHERRY_PICK_HEAD after committing
Benjamin Kerensa (1):
git-gui: fix a typo in po/ files
Clemens Buchacher (1):
git-gui: fix git-gui crash due to uninitialized variable
Heiko Voigt (1):
git-gui: open console when using --trace on windows
Junio C Hamano (1):
Git 1.8.0
Marcus Karlsson (1):
git-gui: Use PWD if it exists on Mac OS X
Pat Thoyts (2):
git-gui: preserve commit messages in utf-8
git-gui 0.17
Ralf Thielow (3):
git-gui: de.po: consistently add untranslated hook names within braces
git-gui: de.po: translate "bare" as "bloß"
git-gui: de.po: translate "remote" as "extern"
Vitaly _Vi Shukela (1):
git-gui: Fix semi-working shortcuts for unstage and revert
^ permalink raw reply
* [PATCH] Doc SubmittingPatches: Mention --notes option after "cover letter"
From: Philip Oakley @ 2012-10-21 21:34 UTC (permalink / raw)
To: GitList; +Cc: Junio C Hamano, Eric Blake
The git format-patch --notes option can now insert the commit notes
after the three dashes. Mention this after the regular cover letter
guidance for submitting patches.
Signed-off-by: Philip Oakley <philipoakley@iee.org>
---
Documentation/SubmittingPatches | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 0dbf2c9..3d8b2fe 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -179,7 +179,8 @@ message starts, you can put a "From: " line to name that person.
You often want to add additional explanation about the patch,
other than the commit message itself. Place such "cover letter"
-material between the three dash lines and the diffstat.
+material between the three dash lines and the diffstat. Git-notes
+can also be inserted using the `--notes` option.
Do not attach the patch as a MIME attachment, compressed or not.
Do not let your e-mail client send quoted-printable. Do not let
--
1.7.11.msysgit.1
^ permalink raw reply related
* [PATCH] Doc format-patch: clarify --notes use case
From: Philip Oakley @ 2012-10-21 21:34 UTC (permalink / raw)
To: GitList; +Cc: Junio C Hamano, Eric Blake
In-Reply-To: <1350855250-2844-1-git-send-email-philipoakley@iee.org>
Remove double negative, and include the repeat usage across
versions of a patch series.
Signed-off-by: Philip Oakley <philipoakley@iee.org>
---
Documentation/git-format-patch.txt | 11 ++++-------
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index 066dc8b..751009c 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -196,13 +196,10 @@ will want to ensure that threading is disabled for `git send-email`.
after the three-dash line.
+
The expected use case of this is to write supporting explanation for
-the commit that does not belong to the commit log message proper
-when (or after) you create the commit, and include it in your patch
-submission. But if you can plan ahead and write it down, there may
-not be a good reason not to write it in your commit message, and if
-you can't, you can always edit the output of format-patch before
-sending it out, so the practical value of this option is somewhat
-dubious, unless your workflow is broken.
+the commit, that does not belong to the commit log message proper,
+and include it with the patch submission. The notes can be maintained
+between versions of the patch series. You can also edit the output of
+format-patch before sending.
--[no]-signature=<signature>::
Add a signature to each message produced. Per RFC 3676 the signature
--
1.7.11.msysgit.1
^ permalink raw reply related
* [PATCH] Doc User-Manual: Patch cover letter, three dashes, and --notes
From: Philip Oakley @ 2012-10-21 21:34 UTC (permalink / raw)
To: GitList; +Cc: Junio C Hamano, Eric Blake
In-Reply-To: <1350855250-2844-1-git-send-email-philipoakley@iee.org>
Show that git format-patch can have a cover letter, include patch
commentary below the three dashes, and notes can also be
included.
Signed-off-by: Philip Oakley <philipoakley@iee.org>
---
Documentation/user-manual.txt | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 85651b5..d918c53 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1787,6 +1787,11 @@ $ git format-patch origin
will produce a numbered series of files in the current directory, one
for each patch in the current branch but not in origin/HEAD.
+`git format-patch` can include an initial "cover letter". You can insert
+a commentary on individual patches using a three dash line after the
+commit message, and before the patch itself. `git format-patch --notes`
+(v1.8.1) will include the commit's notes in the similar manner.
+
You can then import these into your mail client and send them by
hand. However, if you have a lot to send at once, you may prefer to
use the linkgit:git-send-email[1] script to automate the process.
--
1.7.11.msysgit.1
^ permalink raw reply related
* [PATCH] Doc notes: Include the format-patch --notes option
From: Philip Oakley @ 2012-10-21 21:34 UTC (permalink / raw)
To: GitList; +Cc: Junio C Hamano, Eric Blake
In-Reply-To: <1350855250-2844-1-git-send-email-philipoakley@iee.org>
git format-patch gained a --notes option. Tell the notes user.
Signed-off-by: Philip Oakley <philipoakley@iee.org>
---
Documentation/git-notes.txt | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/git-notes.txt b/Documentation/git-notes.txt
index b95aafa..46ef046 100644
--- a/Documentation/git-notes.txt
+++ b/Documentation/git-notes.txt
@@ -39,6 +39,10 @@ message stored in the commit object, the notes are indented like the
message, after an unindented line saying "Notes (<refname>):" (or
"Notes:" for `refs/notes/commits`).
+Notes can also be added to patches prepared with `git format-patch` by
+using the `--notes` option. Such notes are added as a patch commentary
+after a three dash separator line.
+
To change which notes are shown by 'git log', see the
"notes.displayRef" configuration in linkgit:git-log[1].
--
1.7.11.msysgit.1
^ permalink raw reply related
* Re: [PATCH 6/6] format-patch --notes: show notes after three-dashes
From: Philip Oakley @ 2012-10-21 21:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Eric Blake
In-Reply-To: <7vlif3l9fw.fsf@alter.siamese.dyndns.org>
From: "Junio C Hamano" <gitster@pobox.com>
> "Philip Oakley" <philipoakley@iee.org> writes:
>
>> From: "Junio C Hamano" <gitster@pobox.com>
>>> When inserting the note after the commit log message to format-patch
>>> output, add three dashes before the note. Record the fact that we
>>> did so in the rev_info and omit showing duplicated three dashes in
>>> the usual codepath that is used when notes are not being shown.
>>>
>>> Signed-off-by: Junio C Hamano <gitster@pobox.com>
>>
>> Should this also include a documentation update to make this
>> substantive benefit visible, whether that be in the format-patch man
>> pages, the SubmittingPatches guide, in the git-notes description of
>> 'A
>> typical use...', or even in the user-manual?
>
> Eric Blake (http://mid.gmane.org/507EB310.8020904@redhat.com) was
Added to distribution.
> already working on a documentation updates already, I thought.
>
> As long as what it does is explained in format-patch, that is fine.
>
> I do not think this deserves to be in the SubmittingPatches. We do
> tell people to hide "here is the context of the change" additional
> explanation after three dashes, but how the submitters prepare that
> text is entirely up to them (and I personally do not think notes is
> not necessarily the right tool to do so).
>
I've prepared a short set of patches for the documenation I mentioned.
I, like Eric, feel some of the methods available are a bit of a Catch
22.
We do need to at least hint about capabilities as a way of helping new
users who aren't already experts (the inverse Kruger Dunning problem).
I have tried hard to make the patches concise so hopefully they will be
acceptable.
Philip
^ permalink raw reply
* clone over slow/ unreliable network / partial clone with full history
From: Gelonida N @ 2012-10-21 21:22 UTC (permalink / raw)
To: git
Hi,
Sometimes I have to clone a repository over a slow / rather unreliable
network and wonder whether there are any tools tricks to reduce the pain
for such cases.
I'm having two problems:
Problem 1: Resuming a clone:
-----------------------------
When the connection gets cut during the clone, then I don't know how to
continue / resume the clone. This is very annoying. After 20 minutes of
cloning my connection is los. I reclone after 15 minutes the connection
is lost. I reclone and after 25 minutes I succeed.
The only wrokaround, that I know would require full ssh access to the
server. In fact it would be using rsync, (which can be resumed)
clone from the rsynced copy and thenmanually change the url of origin.
Problem 2: Full history but only required data
-----------------------------------------------
Very often I would only need a few versions (some branch heads / last
week's commits) However git clone --depth seems to have far too many
restrictions. (e.g. can't push from it)
So I wondered whether it would be possible to clone the entire history
of a repositry, but fetch only the data of a few specific commits.
This would reduce the transfer time massively as the repository may
contine some huge binary files, which may change every few versions.
What would be great would be.
- download only the history (of course with a resume option if the
connection got interrupted)
- then fetch the 'contents' for the version's I want to checkout
(ideally specify some commit ranges, but specifying some specific
commit id's would be good enough for me)
Are there any helper tools/ plans which would allow such work flow?
^ 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