* [PATCH] gitk: use "gitk: repo-top-level-dir" as window title
From: Zbigniew Jędrzejewski-Szmek @ 2011-11-09 16:28 UTC (permalink / raw)
To: git, Doug Maxey, Paul Mackerras; +Cc: gitster, Zbigniew Jędrzejewski-Szmek
Previously, when run in a subdirectory, gitk would show the name
of this subdirectory as title, which was misleading. When run with
GIT_DIR set, it would show the cwd, which is even more misleading.
In case of non-bare repos, the .git suffix in the path is skipped.
Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
---
gitk-git/gitk | 12 +++++++++++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index 4cde0c4..2eaf901 100755
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -18,6 +18,14 @@ proc gitdir {} {
}
}
+proc reponame {} {
+ set n [file normalize [gitdir]]
+ if {[string match "*/.git" $n]} {
+ set n [string range $n 0 end-5]
+ }
+ return [file tail $n]
+}
+
# A simple scheduler for compute-intensive stuff.
# The aim is to make sure that event handlers for GUI actions can
# run at least every 50-100 ms. Unfortunately fileevent handlers are
@@ -11592,6 +11600,8 @@ if {[package vcompare $git_version "1.6.6.2"] >= 0} {
set show_notes "--show-notes"
}
+set appname "gitk"
+
set runq {}
set history {}
set historyindex 0
@@ -11656,7 +11666,7 @@ catch {
}
# wait for the window to become visible
tkwait visibility .
-wm title . "[file tail $argv0]: [file tail [pwd]]"
+wm title . "$appname: [reponame]"
update
readrefs
--
1.7.8.rc0.251.gccd63
^ permalink raw reply related
* Re: [PATCH v3] post-receive-email: explicitly set Content-Type header
From: Alexey Shumkin @ 2011-11-09 15:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Sixt, Jonathan Nieder
In-Reply-To: <7vy5vpv11n.fsf@alter.siamese.dyndns.org>
> Alexey Shumkin <alex.crezoff@gmail.com> writes:
>
> > Some email clients (e.g. claws-mail) incorrectly display
> > message body when there is no Content-Type header and charset
> > explicitly defined.
> > So, set explicitly Content-Type header. Its charset
> > can be defined with hooks.emailcharset config variable.
> >
> > NB: This above-mentioned charset may differ from
> > i18n.logOutputEncoding, because e.g. gitweb expects (for now)
> > i18n.logOutputEncoding set to UTF-8 to display logs correctly.
> >
> > Also, introduce hooks.gitopts config variable
> > with the default '-c core.quotepath=false'.
> > This takes into account that we want to see pretty email-message
> > with well-looking messages and list of changed filenames.
> > And usually non-ASCII filenames are in the same
> > encoding that commit messages are.
>
> (style) Why such an extremely ragged looking line-wrap of paragraphs?
I'm not good enough in English spelling ;(
>
> > Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com>
> > ---
>
> In this space, please describe what happened during v1 and v2, and
> how is this round different to help reviewers. Pointers to list
> archive, e.g.
> http://thread.gmane.org/gmane.comp.version-control.git/181737, would
> be helpful.
>
> People involved in v1/v2 discussion are missing from the Cc: line.
> Please do not give a false impression that you are hiding from them.
Oh, I've missed that moment, sorry all
>
> > diff --git a/contrib/hooks/post-receive-email
> > b/contrib/hooks/post-receive-email index ba077c1..913be89 100755
> > --- a/contrib/hooks/post-receive-email
> > +++ b/contrib/hooks/post-receive-email
> > @@ -65,6 +65,14 @@
> > # Default is "--stat --summary --find-copies-harder". Add -p to
> > those # options to include a unified diff of changes in addition
> > to the usual # summary output.
> > +# hooks.gitopts
> > +# git options for the git diff-tree invocation that shows
> > changes. +# Default is '-c core.quotepath=false' to be able to
> > see non-ASCII filenames +# used in a project.
>
> We do not particularly appreciate a patch that does two unrelated
> things ("they are both related to post-receive-email" is not an
> argument). Wouldn't this be useful even if the change to add
> hooks.emailcharset turned out to be unwanted, or vice versa?
The main reason was that using core.quotepath=false leads to showing
file names "correctly" according to commit messages encoding to make
email-message look pretty.
>
> > +# hooks.emailcharset
> > +# The charset used in Content-Type header. UTF-8, if not
> > specified. +# It can differ from i18n.logOutputEncoding (not to
> > mess-up with gitweb +# which expects i18n.logOutputEncoding to be
> > set to UTF-8)
>
> Why "UTF-8" instead of "i18n.logoutputencoding" if not specified?
Well, you're right.
For the explanation:
AFAIU, such hooks are used on central servers to notify involved people
about changes. And AFAIU the same server repos are used with gitweb
(which AFAIK requires i18n.logOutputEncoding=UTF-8)
But in common case "i18n.logoutputencoding" is more suitable.
>
> > @@ -234,6 +242,9 @@ generate_email_header()
> > cat <<-EOF
> > To: $recipients
> > Subject: ${emailprefix}$projectdesc $refname_type
> > $short_refname ${change_type}d. $describe
> > + MIME-Version: 1.0
> > + Content-Type: text/plain; charset=$emailcharset
> > + Content-Transfer-Encoding: 8bit
> > X-Git-Refname: $refname
> > X-Git-Reftype: $refname_type
> > X-Git-Oldrev: $oldrev
> > ...
> > @@ -730,6 +734,19 @@ custom_showrev=$(git config hooks.showrev)
> > maxlines=$(git config hooks.emailmaxlines)
> > diffopts=$(git config hooks.diffopts)
> > : ${diffopts:="--stat --summary --find-copies-harder"}
> > +gitopts=$(git config hooks.gitopts || echo '-c
> > core.quotepath=false') +emailcharset=$(git config
> > hooks.emailcharset || echo 'UTF-8') +
> > +projectdesc=$(sed -ne '1p' "$GIT_DIR/description" 2>/dev/null)
> > +# Check if the description is unchanged from it's default, and
> > shorten it to +# a more manageable length if it is
> > +if expr "$projectdesc" : "Unnamed repository.*$" >/dev/null
> > +then
> > + projectdesc="UNNAMED PROJECT"
> > +fi
> > +# Leave description in UTF-8 to be used in the Subject header
> > +# But convert it to an hooks.emailcharset encoding to be used in a
> > message body +projectdesc_e=$(echo $projectdesc | iconv -f UTF-8 -t
> > $emailcharset 2>/dev/null)
>
> Hmm, this generates a piece of e-mail whose subject line is in UTF-8
> (without B/Q quoting) and message body is in totally different
> encoding. Is it what mailers really want to see?
Here you're right, too. Windows email clients may interpret Subject
header without B/Q quoting in its default Windows charset, and as far as
it may contain non-English project description, so Subject would look
ugly. But I'll try to test with some clients.
>
> It almost seems backwards; converting the payload to UTF-8 and always
> sending UTF-8 would be a simpler approach, methinks.
Sounds reasonable
^ permalink raw reply
* Re: [PATCH v3] post-receive-email: explicitly set Content-Type header
From: Junio C Hamano @ 2011-11-09 14:11 UTC (permalink / raw)
To: Alexey Shumkin; +Cc: git, Johannes Sixt, Jonathan Nieder
In-Reply-To: <1320836458-24088-1-git-send-email-Alex.Crezoff@gmail.com>
Alexey Shumkin <alex.crezoff@gmail.com> writes:
> Some email clients (e.g. claws-mail) incorrectly display
> message body when there is no Content-Type header and charset
> explicitly defined.
> So, set explicitly Content-Type header. Its charset
> can be defined with hooks.emailcharset config variable.
>
> NB: This above-mentioned charset may differ from i18n.logOutputEncoding,
> because e.g. gitweb expects (for now) i18n.logOutputEncoding set to UTF-8
> to display logs correctly.
>
> Also, introduce hooks.gitopts config variable
> with the default '-c core.quotepath=false'.
> This takes into account that we want to see pretty email-message
> with well-looking messages and list of changed filenames.
> And usually non-ASCII filenames are in the same
> encoding that commit messages are.
(style) Why such an extremely ragged looking line-wrap of paragraphs?
> Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com>
> ---
In this space, please describe what happened during v1 and v2, and how is
this round different to help reviewers. Pointers to list archive, e.g.
http://thread.gmane.org/gmane.comp.version-control.git/181737, would be
helpful.
People involved in v1/v2 discussion are missing from the Cc: line. Please
do not give a false impression that you are hiding from them.
> diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email
> index ba077c1..913be89 100755
> --- a/contrib/hooks/post-receive-email
> +++ b/contrib/hooks/post-receive-email
> @@ -65,6 +65,14 @@
> # Default is "--stat --summary --find-copies-harder". Add -p to those
> # options to include a unified diff of changes in addition to the usual
> # summary output.
> +# hooks.gitopts
> +# git options for the git diff-tree invocation that shows changes.
> +# Default is '-c core.quotepath=false' to be able to see non-ASCII filenames
> +# used in a project.
We do not particularly appreciate a patch that does two unrelated things
("they are both related to post-receive-email" is not an argument).
Wouldn't this be useful even if the change to add hooks.emailcharset
turned out to be unwanted, or vice versa?
> +# hooks.emailcharset
> +# The charset used in Content-Type header. UTF-8, if not specified.
> +# It can differ from i18n.logOutputEncoding (not to mess-up with gitweb
> +# which expects i18n.logOutputEncoding to be set to UTF-8)
Why "UTF-8" instead of "i18n.logoutputencoding" if not specified?
> @@ -234,6 +242,9 @@ generate_email_header()
> cat <<-EOF
> To: $recipients
> Subject: ${emailprefix}$projectdesc $refname_type $short_refname ${change_type}d. $describe
> + MIME-Version: 1.0
> + Content-Type: text/plain; charset=$emailcharset
> + Content-Transfer-Encoding: 8bit
> X-Git-Refname: $refname
> X-Git-Reftype: $refname_type
> X-Git-Oldrev: $oldrev
> ...
> @@ -730,6 +734,19 @@ custom_showrev=$(git config hooks.showrev)
> maxlines=$(git config hooks.emailmaxlines)
> diffopts=$(git config hooks.diffopts)
> : ${diffopts:="--stat --summary --find-copies-harder"}
> +gitopts=$(git config hooks.gitopts || echo '-c core.quotepath=false')
> +emailcharset=$(git config hooks.emailcharset || echo 'UTF-8')
> +
> +projectdesc=$(sed -ne '1p' "$GIT_DIR/description" 2>/dev/null)
> +# Check if the description is unchanged from it's default, and shorten it to
> +# a more manageable length if it is
> +if expr "$projectdesc" : "Unnamed repository.*$" >/dev/null
> +then
> + projectdesc="UNNAMED PROJECT"
> +fi
> +# Leave description in UTF-8 to be used in the Subject header
> +# But convert it to an hooks.emailcharset encoding to be used in a message body
> +projectdesc_e=$(echo $projectdesc | iconv -f UTF-8 -t $emailcharset 2>/dev/null)
Hmm, this generates a piece of e-mail whose subject line is in UTF-8
(without B/Q quoting) and message body is in totally different encoding.
Is it what mailers really want to see?
It almost seems backwards; converting the payload to UTF-8 and always
sending UTF-8 would be a simpler approach, methinks.
^ permalink raw reply
* Re: [PATCH 19/17] merge: do not fast-forward when merging a tag
From: Junio C Hamano @ 2011-11-09 13:39 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds
In-Reply-To: <7v8vnpwhxl.fsf@alter.siamese.dyndns.org>
Merging a signed or an annotated tag is meant to trigger the editor for
the integrator to leave a meaningful merge commit log in the history.
Disallow fast-forwarding the merge in such a case to ensure that a merge
commit is always recorded.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin/merge.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/builtin/merge.c b/builtin/merge.c
index 3b3e374..99f1429 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -1255,8 +1255,10 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
strbuf_reset(&buf);
if (merge_remote_util(commit) &&
merge_remote_util(commit)->obj &&
- merge_remote_util(commit)->obj->type == OBJ_TAG)
+ merge_remote_util(commit)->obj->type == OBJ_TAG) {
option_edit = 1;
+ allow_fast_forward = 0;
+ }
}
if (!use_strategies) {
^ permalink raw reply related
* Re: [PATCH] completion: don't leak variable from the prompt into environment
From: SZEDER Gábor @ 2011-11-09 13:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Shawn O. Pearce
In-Reply-To: <7vd3d1widd.fsf@alter.siamese.dyndns.org>
Hi,
On Wed, Nov 09, 2011 at 05:11:26AM -0800, Junio C Hamano wrote:
> SZEDER Gábor <szeder@ira.uka.de> writes:
>
> > Commit e5b8eebc (completion: fix issue with process substitution not
> > working on Git for Windows, 2011-10-26) introduced a new variable in
> > __git_ps1_show_upstream(), but didn't declare it as local to prevent
> > it from leaking into the environment.
> > ---
>
> Thanks; I'd consider this signed-off?
Oops, yeah, sorry.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Just for the record: I pointed this out when the patch was discussed
on the list, and proposed a better solution:
http://thread.gmane.org/gmane.comp.version-control.git/184229/focus=184290
but apparently only after that patch was already merged. Since we are
in -rc phase, this patch below chooses the less intrusive solution
(i.e. it declares the variable as local instead of eliminating it by
using the command substitution as here string).
Gábor
>
> > contrib/completion/git-completion.bash | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> > index b3571ab4..d18895b1 100755
> > --- a/contrib/completion/git-completion.bash
> > +++ b/contrib/completion/git-completion.bash
> > @@ -110,7 +110,7 @@ __git_ps1_show_upstream ()
> > local upstream=git legacy="" verbose=""
> >
> > # get some config options from git-config
> > - output="$(git config -z --get-regexp '^(svn-remote\..*\.url|bash\.showupstream)$' 2>/dev/null | tr '\0\n' '\n ')"
> > + local output="$(git config -z --get-regexp '^(svn-remote\..*\.url|bash\.showupstream)$' 2>/dev/null | tr '\0\n' '\n ')"
> > while read key value; do
> > case "$key" in
> > bash.showupstream)
^ permalink raw reply
* [PATCH 18/17] request-pull: use the annotated tag contents
From: Junio C Hamano @ 2011-11-09 13:20 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds
In-Reply-To: <1320800523-5407-1-git-send-email-gitster@pobox.com>
The integrator tool will start allowing to pull signed or an annotated
tag, i.e.
$ git pull $there tags/for-linus
and the description in the tag is used to convey a meaningful message from
the lieutenant to the integrator to justify the history being pulled.
Include the message in the pull request e-mail, as the same information is
useful in this context, too. It would encourage the lieutenants to write
meaningful messages in their signed tags.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* Goes on top of jc/request-pull-show-head-4 that has been cooking in
the 'next' branch.
git-request-pull.sh | 14 ++++++++++++++
t/t5150-request-pull.sh | 4 ++++
2 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/git-request-pull.sh b/git-request-pull.sh
index 626cf25..c6a5b7a 100755
--- a/git-request-pull.sh
+++ b/git-request-pull.sh
@@ -48,6 +48,8 @@ then
fi
fi
+tag_name=$(git describe --exact "$head^0" 2>/dev/null)
+
test -n "$base" && test -n "$url" || usage
baserev=$(git rev-parse --verify "$base"^0) &&
headrev=$(git rev-parse --verify "$head"^0) || exit
@@ -82,8 +84,20 @@ then
echo "(from the branch description for $branch local branch)"
echo
git config "branch.$branch_name.description"
+fi &&
+
+if test -n "$tag_name"
+then
+ git cat-file tag "$tag_name" |
+ sed -n -e '1,/^$/d' -e '/^-----BEGIN PGP /q' -e p
+ echo
+fi &&
+
+if test -n "$branch_name" || test -n "$tag_name"
+then
echo "----------------------------------------------------------------"
fi &&
+
git shortlog ^$baserev $headrev &&
git diff -M --stat --summary $patch $merge_base..$headrev || status=1
diff --git a/t/t5150-request-pull.sh b/t/t5150-request-pull.sh
index 5bd1682..ea6f692 100755
--- a/t/t5150-request-pull.sh
+++ b/t/t5150-request-pull.sh
@@ -86,6 +86,7 @@ test_expect_success 'setup: two scripts for reading pull requests' '
s/$downstream_url_for_sed/URL/g
s/for-upstream/BRANCH/g
s/mnemonic.txt/FILENAME/g
+ s/^version [0-9]/VERSION/
/^ FILENAME | *[0-9]* [-+]*\$/ b diffstat
/^AUTHOR ([0-9]*):\$/ b shortlog
p
@@ -201,6 +202,9 @@ test_expect_success 'pull request format' '
SUBJECT (DATE)
----------------------------------------------------------------
+ VERSION
+
+ ----------------------------------------------------------------
SHORTLOG
DIFFSTAT
--
1.7.8.rc1.82.gde0f9
^ permalink raw reply related
* Re: [PATCH] completion: don't leak variable from the prompt into environment
From: Junio C Hamano @ 2011-11-09 13:11 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: git, Junio C Hamano, Shawn O. Pearce
In-Reply-To: <1320832970-26239-1-git-send-email-szeder@ira.uka.de>
SZEDER Gábor <szeder@ira.uka.de> writes:
> Commit e5b8eebc (completion: fix issue with process substitution not
> working on Git for Windows, 2011-10-26) introduced a new variable in
> __git_ps1_show_upstream(), but didn't declare it as local to prevent
> it from leaking into the environment.
> ---
Thanks; I'd consider this signed-off?
> contrib/completion/git-completion.bash | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index b3571ab4..d18895b1 100755
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -110,7 +110,7 @@ __git_ps1_show_upstream ()
> local upstream=git legacy="" verbose=""
>
> # get some config options from git-config
> - output="$(git config -z --get-regexp '^(svn-remote\..*\.url|bash\.showupstream)$' 2>/dev/null | tr '\0\n' '\n ')"
> + local output="$(git config -z --get-regexp '^(svn-remote\..*\.url|bash\.showupstream)$' 2>/dev/null | tr '\0\n' '\n ')"
> while read key value; do
> case "$key" in
> bash.showupstream)
^ permalink raw reply
* Re: Benchmarks regarding git's gc
From: David Michael Barr @ 2011-11-09 12:34 UTC (permalink / raw)
To: Jeff King; +Cc: Brandon Casey, Felipe Contreras, git
In-Reply-To: <20111108215812.GB18529@sigill.intra.peff.net>
On Wed, Nov 9, 2011 at 8:58 AM, Jeff King <peff@peff.net> wrote:
> On Tue, Nov 08, 2011 at 10:40:15AM -0600, Brandon Casey wrote:
>
>> On Tue, Nov 8, 2011 at 5:34 AM, Felipe Contreras
>> <felipe.contreras@gmail.com> wrote:
>> > Has anybody seen these?
>> > http://draketo.de/proj/hg-vs-git-server/test-results.html#results
>> >
>> > Seems like a potential area of improvement.
>>
>> I think this is a case of designing the problem space so that your
>> intended winner wins and your intended loser loses.
>
> Sort of. It is a real problem space, and mercurial does have some
> advantage in that area.
[...]
> So he may have a point that mercurial might perform better for some
> metrics than git in the current state. But I think a lot of that is
> because nobody has bothered putting git into this situation and done the
> tweaks needed to make it fast. You can argue that git sucks because it
> needs tweaking, of course, but if I were picking between the two systems
> to implement something like this, I'd consider picking git and doing the
> tweaks (of course, I'm far from unbiased).
It is the case that the default behaviour of git gc --auto is far from optimal.
I've been playing with ways to achieve both better asymptotic
performance and less jitter.
One part of that is choosing "good" packing parameters for a given repo.
I did this in a partially automated fashion for WebKit but I think the
process can be generalised.
The other issue is how often you repack ancient history, the potential
waste is obvious.
To this end I propose a repacking strategy in the spirit of merge-sort:
If you can maintain the constraint that the sizes of packs in a repo
form a geometric sequence, my napkin says the amortised cost of gc is
log(n).
--
David Barr.
^ permalink raw reply
* Problem with git-svn with limited SVN access
From: Antoine Bonavita @ 2011-11-09 11:28 UTC (permalink / raw)
To: git
Hello,
I have a problem with a git-svn setup and although I spent most of
yesterday googling for a solution but did not find any (see below for my
failed attempts). I hope you guys here will be able to help me.
I have limited access to a SVN repository with a "standard" layout. By
limited, I mean that I am allowed only to access the folders "trunk",
"branches/XXX" and "branches/YYY".
*Attempt 1:*
> git svn init svn://server/aaa/AAA -T trunk -b branches --username=UUU
Initialized empty Git repository in /home/.../.git/
Using higher level of URL: svn://server/aaa/AAA => svn://server/aaa
> git svn fetch
Error from SVN, (220001): Item is not readable: Item is not readable
*Attempt 2:*
> git svn init svn://server/aaa/AAA -T trunk -b branches --username=UUU
--no-minimize-url
Initialized empty Git repository in /home/.../.git/
> git svn fetch
W: Item is not readable: Item is not readable at
/usr/libexec/git-core/git-svn line 1782
Error from SVN, (220001): Item is not readable: Item is not readable
*Attempt 3:*
> git svn init svn://server/aaa/AAA -T trunk --username=UUU
--no-minimize-url
Initialized empty Git repository in /home/.../.git/
> git svn fetch
W: Item is not readable: Item is not readable at
/usr/libexec/git-core/git-svn line 1782
W: Ignoring error from SVN, path probably does not exist: (160013):
Filesystem has no item: File not found: revision 100, path '/AAA/trunk'
W: Do not be alarmed at the above message git-svn is just searching
aggressively for old history.
This may take a while on large repositories
Read access denied for root of edit: Not authorized to open root of edit
operation at /usr/libexec/git-core/git-svn line 5131
*Attempt 4:*
> git svn init -T svn://server/aaa/AAA/trunk -b
svn://server/aaa/AAA/branches --username=UUU --no-minimize-url
Initialized empty Git repository in /home/.../.git/
svn-remote.svn.url already set: svn://server/aaa/AAA/trunk
wanted to set to: svn://server/aaa/AAA/branches
> git svn fetch
W: Ignoring error from SVN, path probably does not exist: (160013):
Filesystem has no item: File not found: revision 100, path '/AAA/trunk'
W: Do not be alarmed at the above message git-svn is just searching
aggressively for old history.
This may take a while on large repositories
### stuff actually retrieved from SVN
.....
r6035 = 6163cb28acff14d68f1b96869274b668405897a2 (refs/remotes/trunk)
.....
Compressing objects: 100% (10751/10751), done.
Writing objects: 100% (10886/10886), done.
Total 10886 (delta 9331), reused 0 (delta 0)
Checking out files: 100% (6002/6002), done.
Checked out HEAD:
svn://server/aaa/AAA/trunk r27316
creating empty directory: lib/AAA/mp3gain/otherlang/help
...
### No line with any branch. So it looks like I managed to get the trunk
but not the branches.
*Attempt 5:*
> git svn init -T svn://server/aaa/AAA/trunk -b
svn://server/aaa/AAA/branches --username=UUU --no-minimize-url
Initialized empty Git repository in /home/.../.git/
svn-remote.svn.url already set: svn://server/aaa/AAA/trunk
wanted to set to: svn://server/aaa/AAA/branches
### My .git/config looks like:
[svn-remote "svn"]
url = svn://server/aaa/AAA/trunk
fetch = :refs/remotes/trunk
### If I try to add one of the branches manually:
branches = branches/XXX:refs/remotes/branches/XXX
> git svn fetch
One '*' is needed in glob: 'branches/XXX'
*Attempt 6:*
> git svn init -T svn://server/aaa/AAA/trunk -b
svn://server/aaa/AAA/branches --username=UUU --no-minimize-url
Initialized empty Git repository in /home/.../.git/
svn-remote.svn.url already set: svn://server/aaa/AAA/trunk
wanted to set to: svn://server/aaa/AAA/branches
### I put a glob instead of the branch name in git/.config:
branches = branches/{XXX,YYY}:refs/remotes/branches/*
> git svn fetch
...
Counting objects: 10886, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (10751/10751), done.
Writing objects: 100% (10886/10886), done.
Total 10886 (delta 9330), reused 0 (delta 0)
error: Untracked working tree file 'COPYRIGHT.txt' would be overwritten
by merge.
read-tree -m -u -v HEAD HEAD: command returned error: 128
### Only refs/remotes/trunk checked out. No branch.
At this point, I'm really lost and running out of ideas. If someone
could help me with this, I would be very grateful.
Please forgive me if I posted to the wrong mailing-list but I could not
find a specific git-svn list. If there is such thing, please point me in
the right direction.
Thanks,
Antoine.
--
Antoine Bonavita (antoine@stickyadstv.com)
Envoyé de mon PC. Moi je suis Fedora.
^ permalink raw reply
* Re: [PATCH v0] fast-import: Add drop command
From: Vitor Antunes @ 2011-11-09 11:29 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Dmitry Ivankov, Jonathan Nieder, git, David Barr
In-Reply-To: <CAGdFq_jPfSFidb59m-5Tsyusw3yQFRnxU9nqBVosVPuzbt86GA@mail.gmail.com>
On Wed, Nov 9, 2011 at 12:27 AM, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> Heya,
>
> On Wed, Nov 9, 2011 at 01:24, Vitor Antunes <vitor.hda@gmail.com> wrote:
>>
>> That was exactly my intention when I used release_tree_entry(). But I
>> guess I'm doing it wrong, because without the delete_ref() part this
>> does not work (just noticed there's a missing semicolon there...
>> sorry). Any advices/guidance, please? :)
>
> ENODATA. What do you mean with "does not work"? Can you run it through
> gdb and see what's going on?
Calm down! It's not that bad to require gdb :)
It just means that even using the drop() command from the patch I
posted before, I still get the "new tip ... does not contain
..." error from fast-import.
--
Vitor Antunes
^ permalink raw reply
* [PATCH v3] post-receive-email: explicitly set Content-Type header
From: Alexey Shumkin @ 2011-11-09 11:00 UTC (permalink / raw)
To: git; +Cc: Alexey Shumkin, Junio C Hamano
In-Reply-To: <20111007201932.GC29712@elie.hsd1.il.comcast.net>
Some email clients (e.g. claws-mail) incorrectly display
message body when there is no Content-Type header and charset
explicitly defined.
So, set explicitly Content-Type header. Its charset
can be defined with hooks.emailcharset config variable.
NB: This above-mentioned charset may differ from i18n.logOutputEncoding,
because e.g. gitweb expects (for now) i18n.logOutputEncoding set to UTF-8
to display logs correctly.
Also, introduce hooks.gitopts config variable
with the default '-c core.quotepath=false'.
This takes into account that we want to see pretty email-message
with well-looking messages and list of changed filenames.
And usually non-ASCII filenames are in the same
encoding that commit messages are.
Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com>
---
contrib/hooks/post-receive-email | 43 ++++++++++++++++++++++++++-----------
1 files changed, 30 insertions(+), 13 deletions(-)
diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email
index ba077c1..913be89 100755
--- a/contrib/hooks/post-receive-email
+++ b/contrib/hooks/post-receive-email
@@ -65,6 +65,14 @@
# Default is "--stat --summary --find-copies-harder". Add -p to those
# options to include a unified diff of changes in addition to the usual
# summary output.
+# hooks.gitopts
+# git options for the git diff-tree invocation that shows changes.
+# Default is '-c core.quotepath=false' to be able to see non-ASCII filenames
+# used in a project.
+# hooks.emailcharset
+# The charset used in Content-Type header. UTF-8, if not specified.
+# It can differ from i18n.logOutputEncoding (not to mess-up with gitweb
+# which expects i18n.logOutputEncoding to be set to UTF-8)
#
# Notes
# -----
@@ -234,6 +242,9 @@ generate_email_header()
cat <<-EOF
To: $recipients
Subject: ${emailprefix}$projectdesc $refname_type $short_refname ${change_type}d. $describe
+ MIME-Version: 1.0
+ Content-Type: text/plain; charset=$emailcharset
+ Content-Transfer-Encoding: 8bit
X-Git-Refname: $refname
X-Git-Reftype: $refname_type
X-Git-Oldrev: $oldrev
@@ -241,7 +252,7 @@ generate_email_header()
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
- the project "$projectdesc".
+ the project "$projectdesc_e".
The $refname_type, $short_refname has been ${change_type}d
EOF
@@ -255,7 +266,7 @@ generate_email_footer()
hooks/post-receive
--${SPACE}
- $projectdesc
+ $projectdesc_e
EOF
}
@@ -451,7 +462,7 @@ generate_update_branch_email()
# non-fast-forward updates.
echo ""
echo "Summary of changes:"
- git diff-tree $diffopts $oldrev..$newrev
+ git $gitopts diff-tree $diffopts $oldrev..$newrev
}
#
@@ -656,14 +667,15 @@ show_new_revisions()
revspec=$oldrev..$newrev
fi
+ revlistopts="-c i18n.logOutputEncoding=$emailcharset"
other_branches=$(git for-each-ref --format='%(refname)' refs/heads/ |
grep -F -v $refname)
git rev-parse --not $other_branches |
if [ -z "$custom_showrev" ]
then
- git rev-list --pretty --stdin $revspec
+ git $revlistopts rev-list --pretty --stdin $revspec
else
- git rev-list --stdin $revspec |
+ git $revlistopts $rev-list --stdin $revspec |
while read onerev
do
eval $(printf "$custom_showrev" $onerev)
@@ -714,14 +726,6 @@ if [ -z "$GIT_DIR" ]; then
exit 1
fi
-projectdesc=$(sed -ne '1p' "$GIT_DIR/description" 2>/dev/null)
-# Check if the description is unchanged from it's default, and shorten it to
-# a more manageable length if it is
-if expr "$projectdesc" : "Unnamed repository.*$" >/dev/null
-then
- projectdesc="UNNAMED PROJECT"
-fi
-
recipients=$(git config hooks.mailinglist)
announcerecipients=$(git config hooks.announcelist)
envelopesender=$(git config hooks.envelopesender)
@@ -730,6 +734,19 @@ custom_showrev=$(git config hooks.showrev)
maxlines=$(git config hooks.emailmaxlines)
diffopts=$(git config hooks.diffopts)
: ${diffopts:="--stat --summary --find-copies-harder"}
+gitopts=$(git config hooks.gitopts || echo '-c core.quotepath=false')
+emailcharset=$(git config hooks.emailcharset || echo 'UTF-8')
+
+projectdesc=$(sed -ne '1p' "$GIT_DIR/description" 2>/dev/null)
+# Check if the description is unchanged from it's default, and shorten it to
+# a more manageable length if it is
+if expr "$projectdesc" : "Unnamed repository.*$" >/dev/null
+then
+ projectdesc="UNNAMED PROJECT"
+fi
+# Leave description in UTF-8 to be used in the Subject header
+# But convert it to an hooks.emailcharset encoding to be used in a message body
+projectdesc_e=$(echo $projectdesc | iconv -f UTF-8 -t $emailcharset 2>/dev/null)
# --- Main loop
# Allow dual mode: run from the command line just like the update hook, or
--
1.7.7.3.5.g55178
^ permalink raw reply related
* Re: git svn rebase bug
From: Carlos Martín Nieto @ 2011-11-09 10:40 UTC (permalink / raw)
To: Matt Arsenault; +Cc: git
In-Reply-To: <39110A70-A25E-4A6B-A401-FCCE895B2CE5@rpi.edu>
On Tue, Nov 08, 2011 at 03:50:25PM -0500, Matt Arsenault wrote:
> There seems to be a bug using git svn rebase with strategies
>
> git version 1.7.7.2
>
>
> $ git svn rebase --strategy=theirs
ENOENT. The "theirs" strategy doesn't exist (there is an "ours"
strategy). "Theirs" in a option to the recursive merge strategy.
>
> First, rewinding head to replay your work on top of it...
> /usr/lib/git-core/git-rebase--merge: line 69: git-merge-theirs: command not found
> Unknown exit code (127) from command: git-merge-theirs deabad54a6d5ce3ab3f655e06b9c24eadbba6f6c^ -- HEAD deabad54a6d5ce3ab3f655e06b9c24eadbba6f6c
> rebase --strategy=theirs refs/remotes/git-svn: command returned error: 1
The bug is the failure to detect that the merge strategy doesn't
exist, but your command wouldn't have worked anyway.
cmn
^ permalink raw reply
* Re: [PATCH v3 00/17] Pulling signed tags
From: Robin H. Johnson @ 2011-11-09 10:32 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <1320800523-5407-1-git-send-email-gitster@pobox.com>
On Tue, Nov 08, 2011 at 05:01:46PM -0800, Junio C Hamano wrote:
> The third iteration of the fourth approach to give more confidence on the
> authenticity of history, but the third approach of giving GPG signature to
> individual commits is independently useful and has been rebased on top.
Looks good at initial visual review, I'll give a deep inspection in a
day or two (at ApacheCon this week).
Thanks for the perseverance!
--
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robbat2@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
^ permalink raw reply
* [PATCH] completion: don't leak variable from the prompt into environment
From: SZEDER Gábor @ 2011-11-09 10:02 UTC (permalink / raw)
To: git, Junio C Hamano, Shawn O. Pearce; +Cc: SZEDER Gábor
Commit e5b8eebc (completion: fix issue with process substitution not
working on Git for Windows, 2011-10-26) introduced a new variable in
__git_ps1_show_upstream(), but didn't declare it as local to prevent
it from leaking into the environment.
---
contrib/completion/git-completion.bash | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index b3571ab4..d18895b1 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -110,7 +110,7 @@ __git_ps1_show_upstream ()
local upstream=git legacy="" verbose=""
# get some config options from git-config
- output="$(git config -z --get-regexp '^(svn-remote\..*\.url|bash\.showupstream)$' 2>/dev/null | tr '\0\n' '\n ')"
+ local output="$(git config -z --get-regexp '^(svn-remote\..*\.url|bash\.showupstream)$' 2>/dev/null | tr '\0\n' '\n ')"
while read key value; do
case "$key" in
bash.showupstream)
--
1.7.8.rc0.107.g695cb
^ permalink raw reply related
* Re: Benchmarks regarding git's gc
From: Michael Haggerty @ 2011-11-09 5:12 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <CAMP44s3E-YCMQQzJAU2wjjD-adpNy6bGb-=iUQ=p=bFTWxm+Ng@mail.gmail.com>
On 11/08/2011 12:34 PM, Felipe Contreras wrote:
> Has anybody seen these?
> http://draketo.de/proj/hg-vs-git-server/test-results.html#results
>
> Seems like a potential area of improvement.
The fact that git requires periodic garbage collection is indeed
annoying (even in interactive use) and even more annoying in the
scenario discussed by the author of this article.
With respect to the article's claims about the overall efficiency of
Mercurial vs. git, I would like to point out that the author's use of a
test repository with a linear history avoids one of Mercurial's big
design weaknesses. If the repository had had a branching history,
Mercurial's numbers would probably be significantly less flattering.
Mercurial's revlog repository format [1] (at least the last time I
checked) uses a single data file to hold the contents of all versions of
a single file in the working copy. It appends a delta to the end of the
revlog file for each revision, with periodic fulltexts. It is designed
to make it possible to reconstruct any file revision via a single seek
and a single read of at most twice the length of the file's fulltext
(assuming that the index is already known). The avoidance of disk seeks
goes a long way to explaining Mercurial's competitive performance
despite the fact that it is written in Python.
However, the deltas stored in revlog are not relative to a revision's
parent(s), but rather relative to the previous revision in the revlog
file, which is typically the most recent revision committed *to any
branch*. Therefore, revlog is very good at storing a linear series of
commits, but is considerably less efficient at storing a history with
lots of branches that were under development concurrently. The net
result is that the history of a branchy repository can take up much more
space than that of a linear repository.
There was a GSOC "parentdelta" project to allow deltas to be computed
against parents [2], later replaced by a second "generaldelta" scheme
[3], but AFAICT this is still experimental and they are struggling with
its performance.
There is also a script in contrib that reorders the revisions in a
revlog file to put topological neighbors closer together [4]. This can
shrink the size of the file dramatically. But of course this script is
something like "git gc" in the sense that it would presumably need to be
run periodically, and each run would have to lock the repo for some time.
All this is not to detract from the fact that Mercurial, by not
requiring garbage collection, has a big advantage against git in certain
scenarios.
Michael
[1]
http://mercurial.selenic.com/wiki/FAQ#FAQ.2BAC8-TechnicalDetails.How_does_Mercurial_store_its_data.3F
[2] http://mercurial.selenic.com/wiki/ParentDeltaPlan
[3]
http://mercurial.selenic.com/wiki/WhatsNew#Mercurial_1.9_.282011-07-01.29
[4] http://selenic.com/hg/file/54c0517c0fe8/contrib/shrink-revlog.py
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: [PATCH 3/4] pack-objects: don't traverse objects unnecessarily
From: Dan McGee @ 2011-11-09 4:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk47qxe9x.fsf@alter.siamese.dyndns.org>
On Thu, Oct 27, 2011 at 5:26 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Dan McGee <dpmcgee@gmail.com> writes:
>
>> Two optimizations take place here- we can start our objects array
>> iteration from a known point where we left off before we started trying
>> to find our tags,
>
> This I would understand (but I am somewhat curious how much last_untagged
> would advance relative to nr_objects for this half of the optimization to
> be worth it), but...
First off, sorry I wasn't able to respond to you until now, I've been
a bit swamped with other projects. I saw this made it into the 1.7.7.3
maint release today, but wanted to at least try to respond to the
points you raised (if you didn't investigate them by yourself
already).
If I remember right, the last_untagged optimization was pretty minor-
around 10% advancement of the pointer, never that much more. However,
it was a very easy change to make so I figured it was worth the slight
additional code (~5 lines changed for that part on its own).
>
>> and we don't need to do the deep dives required by
>> add_family_to_write_order() if the object has already been marked as
>> filled.
>
> I am not sure if this produces the identical result that was benchmarked
> in the original series.
I was not either when I wrote the patch, and I had hoped to confirm
the results you showed in the message of 1b4bb16b9ec. However, I was
unable to figure out how you generated those numbers so I wasn't able
to do so (and had planned to get back to you to find out how you made
those tables). Were you able to verify the ordering did not regress?
> For example, if you have a tagged object that is not a commit (say a
> blob), you would have written that blob in the second phase (write tagged
> objects together), so the family of blobs that share same delta parent as
> that blob will not be written in this "Finally all the rest" in the right
> place in the original list, no?
True, I think. They would not be written in the same place, but is
that necessarily the right place? The delta parent of an
already-filled tag object would eventually come up in the array as not
filled, and then we would do a full deep dive at that point, so the
majority of the objects would still be in close proximity.
Note that either way, we still have a gap between the original tagged
object and its "family"- potentially all the other tagged tips, tags,
commits, and trees before the blobs are finally hit and laid out in
family groups. So there is at least one potentially big seek that
can't be avoided.
> I do not think this change would forget to fill an object that needs to be
> filled, but it would affect the resulting ordering of the list, so...
This was the purpose of the added "if (wo_end != nr_objects) die()"
line; it confirms we have traversed and hit every object we originally
found.
-Dan
^ permalink raw reply
* Re: [PATCH] prune: show progress while marking reachable objects
From: Nguyen Thai Ngoc Duy @ 2011-11-09 4:26 UTC (permalink / raw)
To: Jeff King; +Cc: git, Junio C Hamano
In-Reply-To: <20111108053149.GA29643@sigill.intra.peff.net>
On Tue, Nov 08, 2011 at 12:31:49AM -0500, Jeff King wrote:
> On Sat, Nov 05, 2011 at 07:00:08PM +0700, Nguyen Thai Ngoc Duy wrote:
>
> > prune already shows progress meter while pruning. The marking part may
> > take a few seconds or more, depending on repository size. Show
> > progress meter during this time too.
>
> Thanks, this is a nice start. It's missing a few things IMHO:
>
> 1. It actually counts commits, not all objects. I'm tempted to say
> this doesn't matter, as any eye candy is helpful. Except that the
> most common use of prune is as part of "git gc", in which case
> pack-objects will have just done the "counting objects" phase and
> come up with some number. If we count all objects, then our end
> number is the same (modulo any .keep packs, but at least it's
> probably in the same order of magnitude). That gives the user a
> better sense of completion time.
>
> 2. Prune should learn --progress/--no-progress, isatty(2), etc. And
> git-gc should pass --no-progress when it's told to be quiet.
3. Show progress meter while pruning packed objects. It does not
seem to take long enough time to show the meter. Anyway the code
is there we should enable it.
-- 8< --
Subject: [PATCH] prune: show progress meter while pruning packed objects
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
builtin.h | 4 ++++
builtin/prune-packed.c | 13 +++++--------
builtin/prune.c | 13 +++++++++----
3 files changed, 18 insertions(+), 12 deletions(-)
diff --git a/builtin.h b/builtin.h
index 0e9da90..0a5b511 100644
--- a/builtin.h
+++ b/builtin.h
@@ -13,6 +13,10 @@ extern const char git_version_string[];
extern const char git_usage_string[];
extern const char git_more_info_string[];
+#define PRUNE_DRY_RUN 01
+#define PRUNE_PROGRESS 02
+#define PRUNE_VERBOSE 04
+
extern void prune_packed_objects(int);
extern int fmt_merge_msg(struct strbuf *in, struct strbuf *out,
int merge_title, int shortlog_len);
diff --git a/builtin/prune-packed.c b/builtin/prune-packed.c
index f9463de..d9f6d1d 100644
--- a/builtin/prune-packed.c
+++ b/builtin/prune-packed.c
@@ -8,9 +8,6 @@ static const char * const prune_packed_usage[] = {
NULL
};
-#define DRY_RUN 01
-#define VERBOSE 02
-
static struct progress *progress;
static void prune_dir(int i, DIR *dir, char *pathname, int len, int opts)
@@ -29,7 +26,7 @@ static void prune_dir(int i, DIR *dir, char *pathname, int len, int opts)
if (!has_sha1_pack(sha1))
continue;
memcpy(pathname + len, de->d_name, 38);
- if (opts & DRY_RUN)
+ if (opts & PRUNE_DRY_RUN)
printf("rm -f %s\n", pathname);
else
unlink_or_warn(pathname);
@@ -46,7 +43,7 @@ void prune_packed_objects(int opts)
const char *dir = get_object_directory();
int len = strlen(dir);
- if (opts == VERBOSE)
+ if (opts & PRUNE_PROGRESS)
progress = start_progress_delay("Removing duplicate objects",
256, 95, 2);
@@ -71,10 +68,10 @@ void prune_packed_objects(int opts)
int cmd_prune_packed(int argc, const char **argv, const char *prefix)
{
- int opts = isatty(2) ? VERBOSE : 0;
+ int opts = isatty(2) ? PRUNE_PROGRESS : 0;
const struct option prune_packed_options[] = {
- OPT_BIT('n', "dry-run", &opts, "dry run", DRY_RUN),
- OPT_NEGBIT('q', "quiet", &opts, "be quiet", VERBOSE),
+ OPT_BIT('n', "dry-run", &opts, "dry run", PRUNE_DRY_RUN),
+ OPT_NEGBIT('q', "quiet", &opts, "be quiet", PRUNE_PROGRESS),
OPT_END()
};
diff --git a/builtin/prune.c b/builtin/prune.c
index 58d7cb8..4cdbac0 100644
--- a/builtin/prune.c
+++ b/builtin/prune.c
@@ -127,9 +127,10 @@ int cmd_prune(int argc, const char **argv, const char *prefix)
{
struct rev_info revs;
struct progress *progress = NULL;
+ int prune_opts = 0;
const struct option options[] = {
- OPT__DRY_RUN(&show_only, "do not remove, show only"),
- OPT__VERBOSE(&verbose, "report pruned objects"),
+ OPT_BIT('n', "dry-run", &prune_opts, "do not remove, show only", PRUNE_DRY_RUN),
+ OPT_BIT('v', "verbose", &prune_opts, "report pruned objects", PRUNE_VERBOSE),
OPT_BOOL(0, "progress", &show_progress, "show progress"),
OPT_DATE(0, "expire", &expire,
"expire objects older than <time>"),
@@ -143,6 +144,8 @@ int cmd_prune(int argc, const char **argv, const char *prefix)
init_revisions(&revs, prefix);
argc = parse_options(argc, argv, prefix, options, prune_usage, 0);
+ show_only = prune_opts & PRUNE_DRY_RUN;
+ verbose = prune_opts & PRUNE_VERBOSE;
while (argc--) {
unsigned char sha1[20];
const char *name = *argv++;
@@ -159,14 +162,16 @@ int cmd_prune(int argc, const char **argv, const char *prefix)
if (show_progress == -1)
show_progress = isatty(2);
- if (show_progress)
+ if (show_progress) {
+ prune_opts |= PRUNE_PROGRESS;
progress = start_progress_delay("Checking connectivity", 0, 0, 2);
+ }
mark_reachable_objects(&revs, 1, progress);
stop_progress(&progress);
prune_object_dir(get_object_directory());
- prune_packed_objects(show_only);
+ prune_packed_objects(prune_opts);
remove_temporary_files(get_object_directory());
s = xstrdup(mkpath("%s/pack", get_object_directory()));
remove_temporary_files(s);
--
1.7.3.1.256.g2539c.dirty
-- 8< --
^ permalink raw reply related
* [PATCH] prune: handle --progress/no-progress
From: Nguyễn Thái Ngọc Duy @ 2011-11-09 4:23 UTC (permalink / raw)
To: Jeff King
Cc: git, Junio C Hamano, Jeff King,
Nguyễn Thái Ngọc Duy
In-Reply-To: <20111108053407.GA16852@sigill.intra.peff.net>
From: Jeff King <peff@peff.net>
And have "git gc" pass no-progress when quiet.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
Added documentation.
Documentation/git-prune.txt | 9 ++++++++-
builtin/gc.c | 4 +++-
builtin/prune.c | 11 +++++++++--
3 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-prune.txt b/Documentation/git-prune.txt
index 80d01b0..6da99e2 100644
--- a/Documentation/git-prune.txt
+++ b/Documentation/git-prune.txt
@@ -9,7 +9,7 @@ git-prune - Prune all unreachable objects from the object database
SYNOPSIS
--------
[verse]
-'git prune' [-n] [-v] [--expire <expire>] [--] [<head>...]
+'git prune' [-n] [-v] [--expire <expire>] [--[no-]progress] [--] [<head>...]
DESCRIPTION
-----------
@@ -46,6 +46,13 @@ OPTIONS
--expire <time>::
Only expire loose objects older than <time>.
+--progress::
+--no-progress::
+ Progress status is reported on the standard error stream
+ by default when it is attached to a terminal, unless --no-progress
+ is specified. This flag forces progress status even if the
+ standard error stream is not directed to a terminal.
+
<head>...::
In addition to objects
reachable from any of our references, keep objects
diff --git a/builtin/gc.c b/builtin/gc.c
index 0498094..271376d 100644
--- a/builtin/gc.c
+++ b/builtin/gc.c
@@ -32,7 +32,7 @@ static const char *prune_expire = "2.weeks.ago";
static const char *argv_pack_refs[] = {"pack-refs", "--all", "--prune", NULL};
static const char *argv_reflog[] = {"reflog", "expire", "--all", NULL};
static const char *argv_repack[MAX_ADD] = {"repack", "-d", "-l", NULL};
-static const char *argv_prune[] = {"prune", "--expire", NULL, NULL};
+static const char *argv_prune[] = {"prune", "--expire", NULL, NULL, NULL};
static const char *argv_rerere[] = {"rerere", "gc", NULL};
static int gc_config(const char *var, const char *value, void *cb)
@@ -243,6 +243,8 @@ int cmd_gc(int argc, const char **argv, const char *prefix)
if (prune_expire) {
argv_prune[2] = prune_expire;
+ if (quiet)
+ argv_prune[3] = "--no-progress";
if (run_command_v_opt(argv_prune, RUN_GIT_CMD))
return error(FAILED_RUN, argv_prune[0]);
}
diff --git a/builtin/prune.c b/builtin/prune.c
index 6b39d3f..58d7cb8 100644
--- a/builtin/prune.c
+++ b/builtin/prune.c
@@ -15,6 +15,7 @@ static const char * const prune_usage[] = {
static int show_only;
static int verbose;
static unsigned long expire;
+static int show_progress = -1;
static int prune_tmp_object(const char *path, const char *filename)
{
@@ -125,10 +126,11 @@ static void remove_temporary_files(const char *path)
int cmd_prune(int argc, const char **argv, const char *prefix)
{
struct rev_info revs;
- struct progress *progress;
+ struct progress *progress = NULL;
const struct option options[] = {
OPT__DRY_RUN(&show_only, "do not remove, show only"),
OPT__VERBOSE(&verbose, "report pruned objects"),
+ OPT_BOOL(0, "progress", &show_progress, "show progress"),
OPT_DATE(0, "expire", &expire,
"expire objects older than <time>"),
OPT_END()
@@ -154,7 +156,12 @@ int cmd_prune(int argc, const char **argv, const char *prefix)
else
die("unrecognized argument: %s", name);
}
- progress = start_progress_delay("Checking connectivity", 0, 0, 2);
+
+ if (show_progress == -1)
+ show_progress = isatty(2);
+ if (show_progress)
+ progress = start_progress_delay("Checking connectivity", 0, 0, 2);
+
mark_reachable_objects(&revs, 1, progress);
stop_progress(&progress);
prune_object_dir(get_object_directory());
--
1.7.3.1.256.g2539c.dirty
^ permalink raw reply related
* Re: [RFC/PATCH] remote: add new sync command
From: Junio C Hamano @ 2011-11-09 3:36 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Jeff King, git
In-Reply-To: <CAMP44s0bm+bydNnMWPHpz8B8wMf6XN9LTiiCD-nrYSHGAV5c5Q@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> Perhaps these 'git remote' commands should be removed in 1.8 then.
It is true that it was a long-term goal to deprecate many parts of the
"git remote" script that started as a hack to scratch itches "git fetch"
in the older days did not directly scratch for people, e.g. fetching from
multiple remotes in one go.
I do not think 1.7.X series to 1.8 is a big enough jump to remove
duplicated features, though.
^ permalink raw reply
* [ANNOUNCE] Git 1.7.7.3
From: Junio C Hamano @ 2011-11-09 1:15 UTC (permalink / raw)
To: git; +Cc: Linux Kernel
The latest maintenance release Git 1.7.7.3 is available.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
382ee40da74a1b4a1875820c0f0a35c9ccd750f8 git-1.7.7.3.tar.gz
bc0f89cb04e562e4a6d3b936382dbc8f593d861f git-htmldocs-1.7.7.3.tar.gz
cf1b0d35e2d242bc4cffce3b2bf5b3e32857b395 git-manpages-1.7.7.3.tar.gz
Also the following public repositories all have a copy of the v1.7.7.3
tag and the maint 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
----------------------------------------------------------------
Changes since v1.7.7.2 are as follows:
Dan McGee (4):
pack-objects: mark add_to_write_order() as inline
pack-objects: use unsigned int for counter and offset values
pack-objects: rewrite add_descendants_to_write_order() iteratively
pack-objects: don't traverse objects unnecessarily
Jeff King (1):
docs: don't mention --quiet or --exit-code in git-log(1)
Julien Muchembled (1):
gitweb: fix regression when filtering out forks
Junio C Hamano (3):
branch -m/-M: remove undocumented RENAMED-REF
docs: Update install-doc-quick
Git 1.7.7.3
^ permalink raw reply
* [PATCH v3 05/17] refs DWIMmery: use the same rule for both "git fetch" and others
From: Junio C Hamano @ 2011-11-09 1:01 UTC (permalink / raw)
To: git
In-Reply-To: <1320800523-5407-1-git-send-email-gitster@pobox.com>
"git log frotz" can DWIM to "refs/remotes/frotz/HEAD", but in the remote
access context, "git fetch frotz" to fetch what the other side happened to
have fetched from what it calls 'frotz' (which may not have any relation
to what we consider is 'frotz') the last time would not make much sense,
so the fetch rules table did not include "refs/remotes/%.*s/HEAD".
When the user really wants to, "git fetch $there remotes/frotz/HEAD" would
let her do so anyway, so this is not about safety or security; it merely
is about confusion avoidance and discouraging meaningless usage.
Specifically, it is _not_ about ambiguity avoidance. A name that would
become ambiguous if we use the same rules table for both fetch and local
rev-parse would be ambiguous locally at the remote side.
So for the same reason as we added rule to allow "git fetch $there v1.0"
instead of "git fetch $there tags/v1.0" in the previous commit, here is a
bit longer rope for the users, which incidentally simplifies our code.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
cache.h | 2 +-
refs.c | 8 --------
t/t5510-fetch.sh | 5 ++---
3 files changed, 3 insertions(+), 12 deletions(-)
diff --git a/cache.h b/cache.h
index be07ec7..26322dd 100644
--- a/cache.h
+++ b/cache.h
@@ -873,7 +873,7 @@ extern int get_sha1_mb(const char *str, unsigned char *sha1);
extern int refname_match(const char *abbrev_name, const char *full_name, const char **rules);
extern const char *ref_rev_parse_rules[];
-extern const char *ref_fetch_rules[];
+#define ref_fetch_rules ref_rev_parse_rules
extern int create_symref(const char *ref, const char *refs_heads_master, const char *logmsg);
extern int validate_headref(const char *ref);
diff --git a/refs.c b/refs.c
index ff20eeb..026c7ea 100644
--- a/refs.c
+++ b/refs.c
@@ -995,14 +995,6 @@ const char *ref_rev_parse_rules[] = {
NULL
};
-const char *ref_fetch_rules[] = {
- "%.*s",
- "refs/%.*s",
- "refs/tags/%.*s",
- "refs/heads/%.*s",
- NULL
-};
-
int refname_match(const char *abbrev_name, const char *full_name, const char **rules)
{
const char **p;
diff --git a/t/t5510-fetch.sh b/t/t5510-fetch.sh
index 7e433b1..251d138 100755
--- a/t/t5510-fetch.sh
+++ b/t/t5510-fetch.sh
@@ -116,7 +116,7 @@ test_expect_success 'fetch must not resolve short tag name' '
'
-test_expect_success 'fetch must not resolve short remote name' '
+test_expect_success 'fetch can now resolve short remote name' '
cd "$D" &&
git update-ref refs/remotes/six/HEAD HEAD &&
@@ -125,8 +125,7 @@ test_expect_success 'fetch must not resolve short remote name' '
cd six &&
git init &&
- test_must_fail git fetch .. six:six
-
+ git fetch .. six:six
'
test_expect_success 'create bundle 1' '
--
1.7.8.rc1.82.g90e080
^ permalink raw reply related
* [PATCH v3 04/17] fetch: allow "git fetch $there v1.0" to fetch a tag
From: Junio C Hamano @ 2011-11-09 1:01 UTC (permalink / raw)
To: git
In-Reply-To: <1320800523-5407-1-git-send-email-gitster@pobox.com>
You can already do so with "git fetch $there tags/v1.0" but if it is not
ambiguous there is no reason to force users to type more.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
refs.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/refs.c b/refs.c
index cab4394..ff20eeb 100644
--- a/refs.c
+++ b/refs.c
@@ -998,6 +998,7 @@ const char *ref_rev_parse_rules[] = {
const char *ref_fetch_rules[] = {
"%.*s",
"refs/%.*s",
+ "refs/tags/%.*s",
"refs/heads/%.*s",
NULL
};
--
1.7.8.rc1.82.g90e080
^ permalink raw reply related
* [PATCH v3 12/17] merge: force edit mode when merging a tag object
From: Junio C Hamano @ 2011-11-09 1:01 UTC (permalink / raw)
To: git
In-Reply-To: <1320800523-5407-1-git-send-email-gitster@pobox.com>
Now that we allow pulling a tag from the remote site to validate the
authenticity, we should give the user the final chance to verify and
edit the merge message.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin/merge.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/builtin/merge.c b/builtin/merge.c
index 7158e8e..3b3e374 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -1253,6 +1253,10 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
sha1_to_hex(commit->object.sha1));
setenv(buf.buf, argv[i], 1);
strbuf_reset(&buf);
+ if (merge_remote_util(commit) &&
+ merge_remote_util(commit)->obj &&
+ merge_remote_util(commit)->obj->type == OBJ_TAG)
+ option_edit = 1;
}
if (!use_strategies) {
--
1.7.8.rc1.82.g90e080
^ permalink raw reply related
* [PATCH v3 17/17] pretty: %G[?GS] placeholders
From: Junio C Hamano @ 2011-11-09 1:02 UTC (permalink / raw)
To: git
In-Reply-To: <1320800523-5407-1-git-send-email-gitster@pobox.com>
Add new placeholders related to the GPG signature on signed commits.
- %GG to show the raw verification message from GPG;
- %G? to show either "G" for Good, "B" for Bad;
- %GS to show the name of the signer.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
pretty.c | 86 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 86 insertions(+), 0 deletions(-)
diff --git a/pretty.c b/pretty.c
index f45eb54..392d656 100644
--- a/pretty.c
+++ b/pretty.c
@@ -9,6 +9,7 @@
#include "notes.h"
#include "color.h"
#include "reflog-walk.h"
+#include "gpg-interface.h"
static char *user_format;
static struct cmt_fmt_map {
@@ -640,6 +641,12 @@ struct format_commit_context {
const struct pretty_print_context *pretty_ctx;
unsigned commit_header_parsed:1;
unsigned commit_message_parsed:1;
+ unsigned commit_signature_parsed:1;
+ struct {
+ char *gpg_output;
+ char good_bad;
+ char *signer;
+ } signature;
char *message;
size_t width, indent1, indent2;
@@ -822,6 +829,59 @@ static void rewrap_message_tail(struct strbuf *sb,
c->indent2 = new_indent2;
}
+static struct {
+ char result;
+ const char *check;
+} signature_check[] = {
+ { 'G', ": Good signature from " },
+ { 'B', ": BAD signature from " },
+};
+
+static void parse_signature_lines(struct format_commit_context *ctx)
+{
+ const char *buf = ctx->signature.gpg_output;
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(signature_check); i++) {
+ const char *found = strstr(buf, signature_check[i].check);
+ const char *next;
+ if (!found)
+ continue;
+ ctx->signature.good_bad = signature_check[i].result;
+ found += strlen(signature_check[i].check);
+ next = strchrnul(found, '\n');
+ ctx->signature.signer = xmemdupz(found, next - found);
+ break;
+ }
+}
+
+static void parse_commit_signature(struct format_commit_context *ctx)
+{
+ struct strbuf payload = STRBUF_INIT;
+ struct strbuf signature = STRBUF_INIT;
+ struct strbuf gpg_output = STRBUF_INIT;
+ int status;
+
+ ctx->commit_signature_parsed = 1;
+
+ if (parse_signed_commit(ctx->commit->object.sha1,
+ &payload, &signature) <= 0)
+ goto out;
+ status = verify_signed_buffer(payload.buf, payload.len,
+ signature.buf, signature.len,
+ &gpg_output);
+ if (status && !gpg_output.len)
+ goto out;
+ ctx->signature.gpg_output = strbuf_detach(&gpg_output, NULL);
+ parse_signature_lines(ctx);
+
+ out:
+ strbuf_release(&gpg_output);
+ strbuf_release(&payload);
+ strbuf_release(&signature);
+}
+
+
static size_t format_commit_one(struct strbuf *sb, const char *placeholder,
void *context)
{
@@ -974,6 +1034,30 @@ static size_t format_commit_one(struct strbuf *sb, const char *placeholder,
return 0;
}
+ if (placeholder[0] == 'G') {
+ if (!c->commit_signature_parsed)
+ parse_commit_signature(c);
+ switch (placeholder[1]) {
+ case 'G':
+ if (c->signature.gpg_output)
+ strbuf_addstr(sb, c->signature.gpg_output);
+ break;
+ case '?':
+ switch (c->signature.good_bad) {
+ case 'G':
+ case 'B':
+ strbuf_addch(sb, c->signature.good_bad);
+ }
+ break;
+ case 'S':
+ if (c->signature.signer)
+ strbuf_addstr(sb, c->signature.signer);
+ break;
+ }
+ return 2;
+ }
+
+
/* For the rest we have to parse the commit header. */
if (!c->commit_header_parsed)
parse_commit_header(c);
@@ -1114,6 +1198,8 @@ void format_commit_message(const struct commit *commit,
if (context.message != commit->buffer)
free(context.message);
+ free(context.signature.gpg_output);
+ free(context.signature.signer);
}
static void pp_header(const struct pretty_print_context *pp,
--
1.7.8.rc1.82.g90e080
^ permalink raw reply related
* [PATCH v3 16/17] test "commit -S" and "log --show-signature"
From: Junio C Hamano @ 2011-11-09 1:02 UTC (permalink / raw)
To: git
In-Reply-To: <1320800523-5407-1-git-send-email-gitster@pobox.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
t/t7510-signed-commit.sh | 71 ++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 71 insertions(+), 0 deletions(-)
create mode 100755 t/t7510-signed-commit.sh
diff --git a/t/t7510-signed-commit.sh b/t/t7510-signed-commit.sh
new file mode 100755
index 0000000..30401ce
--- /dev/null
+++ b/t/t7510-signed-commit.sh
@@ -0,0 +1,71 @@
+#!/bin/sh
+
+test_description='signed commit tests'
+. ./test-lib.sh
+. "$TEST_DIRECTORY/lib-gpg.sh"
+
+test_expect_success GPG 'create signed commits' '
+ echo 1 >file && git add file &&
+ test_tick && git commit -S -m initial &&
+ git tag initial &&
+ git branch side &&
+
+ echo 2 >file && test_tick && git commit -a -S -m second &&
+ git tag second &&
+
+ git checkout side &&
+ echo 3 >elif && git add elif &&
+ test_tick && git commit -m "third on side" &&
+
+ git checkout master &&
+ test_tick && git merge -S side &&
+ git tag merge &&
+
+ echo 4 >file && test_tick && git commit -a -m "fourth unsigned" &&
+ git tag fourth-unsigned &&
+
+ test_tick && git commit --amend -S -m "fourth signed"
+'
+
+test_expect_success GPG 'show signatures' '
+ (
+ for commit in initial second merge master
+ do
+ git show --pretty=short --show-signature $commit >actual &&
+ grep "Good signature from" actual || exit 1
+ ! grep "BAD signature from" actual || exit 1
+ echo $commit OK
+ done
+ ) &&
+ (
+ for commit in merge^2 fourth-unsigned
+ do
+ git show --pretty=short --show-signature $commit >actual &&
+ grep "Good signature from" actual && exit 1
+ ! grep "BAD signature from" actual || exit 1
+ echo $commit OK
+ done
+ )
+'
+
+test_expect_success GPG 'detect fudged signature' '
+ git cat-file commit master >raw &&
+
+ sed -e "s/fourth signed/4th forged/" raw >forged1 &&
+ git hash-object -w -t commit forged1 >forged1.commit &&
+ git show --pretty=short --show-signature $(cat forged1.commit) >actual1 &&
+ grep "BAD signature from" actual1 &&
+ ! grep "Good signature from" actual1
+'
+
+test_expect_success GPG 'detect fudged signature with NUL' '
+ git cat-file commit master >raw &&
+ cat raw >forged2 &&
+ echo Qwik | tr "Q" "\000" >>forged2 &&
+ git hash-object -w -t commit forged2 >forged2.commit &&
+ git show --pretty=short --show-signature $(cat forged2.commit) >actual2 &&
+ grep "BAD signature from" actual2 &&
+ ! grep "Good signature from" actual2
+'
+
+test_done
--
1.7.8.rc1.82.g90e080
^ permalink raw reply related
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