* Re: [RFC/PATCH] add update to branch support for "floating submodules"
From: Junio C Hamano @ 2011-11-09 18:01 UTC (permalink / raw)
To: Heiko Voigt; +Cc: git
In-Reply-To: <20111109174027.GA28825@book.fritz.box>
Heiko Voigt <hvoigt@hvoigt.net> writes:
> This is almost ready but I would like to know what users of the
> "floating submodule" think about this.
Thanks for working on this.
I do like to hear from potential users as well, because the general
impression we got was that floating submodules is not a real need of
anybody, but it is merely an inertia of people who (perhaps mistakenly)
thought svn externals that are not anchored to a particular revision is a
feature when it is just a limitation in reality. During the GitTogether'11
we learned that Android that uses floating model does not really have to.
^ permalink raw reply
* [RFC/PATCH] add update to branch support for "floating submodules"
From: Heiko Voigt @ 2011-11-09 17:40 UTC (permalink / raw)
To: git
This adds the capability to configure a branch which submodule update
will use to checkout the tips sha1 instead of the registered one.
It will first attempt to read the configuration directly from the
currently checked out .gitmodules file from the key
submodule.$name.branch. This configuration can be overridden by local
user configuration values. The parameter --branch can be used to
specify/override the branch using the commandline. The parameter
--checkout can be used to switch to the exact model for all submodules.
Such a thing is helpful if a user wants to follow a defined branches tip
in the submodule. Image such a branch is the stable branch for some
central library or similar.
When the newly checked out tip will not match the registered sha1 in the
superproject it will show up as a change as usual. You can imagine this
as a configuration which lets the upstream project tell a user the
branch it usually updates to. The usual revision control is still in
place.
---
This is almost ready but I would like to know what users of the
"floating submodule" think about this.
Documentation/git-submodule.txt | 26 +++++++++--
git-submodule.sh | 47 ++++++++++++++++++++
t/t7406-submodule-update.sh | 93 +++++++++++++++++++++++++++++++++++++++
3 files changed, 162 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index 6ec3fef..b8affa3 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -133,9 +133,11 @@ init::
update::
Update the registered submodules, i.e. clone missing submodules and
checkout the commit specified in the index of the containing repository.
- This will make the submodules HEAD be detached unless `--rebase` or
- `--merge` is specified or the key `submodule.$name.update` is set to
- `rebase`, `merge` or `none`.
+ This will make the submodules HEAD be detached. This will not
+ happen if `--rebase`, `--merge` or `--branch` are specified.
+ Also if the key `submodule.$name.update` is set to `rebase`,
+ `merge` or `none`. If `submodule.$name.branch` is set to some
+ local branch this will also not happen.
+
If the submodule is not yet initialized, and you just want to use the
setting as stored in .gitmodules, you can automatically initialize the
@@ -146,7 +148,16 @@ registered submodules, and update any nested submodules within.
+
If the configuration key `submodule.$name.update` is set to `none` the
submodule with name `$name` will not be updated by default. This can be
-overriden by adding `--checkout` to the command.
+overriden by adding `--checkout` to the command. `--checkout` can also
+be used to enforce exact checkout of submodule sha1's.
++
+If the configuration key `submodule.$name.branch` is set to some valid
+branch in the submodule named by `$name` the submodule will be updated
+to the tip of that branch instead of the registered sha1. This option
+can either be set in .gitmodules or via git's configuration. Gits local
+configuration takes precedence over .gitmodules. If you want to override
+the branch checkout you can use the value `HEAD` to tell git to checkout
+exactly the registered sha1.
summary::
Show commit summary between the given commit (defaults to HEAD) and
@@ -252,6 +263,13 @@ OPTIONS
If the key `submodule.$name.update` is set to `rebase`, this option is
implicit.
+--branch::
+ This option is only valid for the update command. You can use
+ this parameter to specify which branch you want to update all
+ submodules to. This is helpful if you want to update all
+ submodules to the tip of a certain branch or need to work on a
+ branch for all submodules for some time.
+
--init::
This option is only valid for the update command.
Initialize all submodules for which "git submodule init" has not been
diff --git a/git-submodule.sh b/git-submodule.sh
index 3adab93..a4b117b 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -465,6 +465,14 @@ cmd_update()
--checkout)
update="checkout"
;;
+ --branch=*)
+ case "$1" in
+ *=*)
+ update="checkout"
+ branch=`expr "z$1" : 'z--[^=]*=\(.*\)'` ;;
+ *)
+ usage ;;
+ esac ;;
--)
shift
break
@@ -504,6 +512,45 @@ cmd_update()
update_module=$(git config submodule."$name".update)
fi
+ if ! test -z "$branch"
+ then
+ branch_module=$branch
+ else
+ if test "$update" != "checkout"
+ then
+ branch_module=$(git config submodule."$name".branch)
+ if test -z "$branch_module"
+ then
+ branch_module=$(git config -f .gitmodules --get submodule."$name".branch)
+ fi
+ fi
+ fi
+
+ if test "$branch_module" = "HEAD"
+ then
+ branch_module=
+ fi
+
+ if ! test -z "$branch_module"
+ then
+ (clear_local_git_env; cd "$path" &&
+ if test ! $nofetch
+ then
+ git-fetch --all >/dev/null 2>/dev/null || exit 1
+ fi) ||
+ die "$(eval_gettext "Unable to fetch submodule in path '\$path'")"
+
+ sha1=$(clear_local_git_env; cd "$path" &&
+ git rev-parse $branch_module) ||
+ say "$(eval_gettext "Unable to find branch '\$branch_module' in submodule path '\$path'")"
+ fi
+
+ if test "$branch" -a "$update" != "checkout"
+ then
+ die "$(eval_gettext "You can not set update='\$update' and
+use a branch for submodule '\$path'")"
+ fi
+
if test "$update_module" = "none"
then
echo "Skipping submodule '$path'"
diff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh
index 33b292b..517ed83 100755
--- a/t/t7406-submodule-update.sh
+++ b/t/t7406-submodule-update.sh
@@ -611,4 +611,97 @@ test_expect_success 'submodule update places git-dir in superprojects git-dir re
)
'
+test_expect_success '--branch updates follow the given branch' '
+ git clone . branch &&
+ (cd branch &&
+ git submodule add ./submodule submodule1 &&
+ git submodule add ./submodule submodule2 &&
+ (cd submodule1 &&
+ git rev-parse HEAD >../expected1 &&
+ git checkout HEAD^) &&
+ (cd submodule2 &&
+ git rev-parse HEAD >../expected2 &&
+ git checkout HEAD^) &&
+ git add submodule1 &&
+ git add submodule2 &&
+ git commit -m "add submodule1 and submodule2" &&
+ git submodule update --branch=origin/master &&
+ (cd submodule1 && git rev-parse HEAD >../actual1) &&
+ (cd submodule2 && git rev-parse HEAD >../actual2) &&
+ test_cmp expected1 actual1 &&
+ test_cmp expected2 actual2
+ )
+'
+
+cat >branch/expect_status <<EOF
+ M submodule1
+EOF
+
+check_submodule_one_follows()
+{
+ (cd submodule1 &&
+ git rev-parse origin/master >../expected1 &&
+ git rev-parse HEAD >../actual1) &&
+ (cd submodule2 &&
+ git rev-parse origin/master^ >../expected2 &&
+ git rev-parse HEAD >../actual2) &&
+ test_cmp expected1 actual1 &&
+ test_cmp expected2 actual2 &&
+ git status --porcelain --untracked-files=no >actual_status &&
+ test_cmp expect_status actual_status
+}
+
+check_both_submodules_exact()
+{
+ (cd submodule1 &&
+ git rev-parse origin/master^ >../expected1 &&
+ git rev-parse HEAD >../actual1) &&
+ (cd submodule2 &&
+ git rev-parse origin/master^ >../expected2 &&
+ git rev-parse HEAD >../actual2) &&
+ test_cmp expected1 actual1 &&
+ test_cmp expected2 actual2 &&
+ test -z "$(git status --porcelain --untracked-files=no)"
+}
+
+test_expect_success 'local branch configuration follows branch' '
+ (cd branch &&
+ git submodule update &&
+ check_both_submodules_exact &&
+ git config submodule.submodule1.branch origin/master &&
+ git submodule update &&
+ check_submodule_one_follows
+ )
+'
+
+test_expect_success '.gitmodules branch configuration follows branch' '
+ (cd branch &&
+ git config --unset submodule.submodule1.branch &&
+ git submodule update &&
+ check_both_submodules_exact &&
+ git config -f .gitmodules submodule.submodule1.branch origin/master &&
+ git add .gitmodules &&
+ git commit -m ".gitmodules follows branch" &&
+ git submodule update &&
+ check_submodule_one_follows
+ )
+'
+
+test_expect_success '--checkout commandline overrides branch config' '
+ (cd branch &&
+ git submodule update --checkout &&
+ check_both_submodules_exact
+ )
+'
+
+test_expect_success 'local config overrides .gitmodules branch config' '
+ (cd branch &&
+ git submodule update &&
+ check_submodule_one_follows &&
+ git config submodule.submodule1.branch HEAD &&
+ git submodule update &&
+ check_both_submodules_exact
+ )
+'
+
test_done
--
1.7.7.433.gcf1e7
^ permalink raw reply related
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: Junio C Hamano @ 2011-11-09 17:26 UTC (permalink / raw)
To: Linus Torvalds
Cc: Ted Ts'o, Shawn Pearce, git, James Bottomley, Jeff Garzik,
Andrew Morton, linux-ide, LKML
In-Reply-To: <CA+55aFyRawm9CoJMiEXDFCX4YTidPOiV4oqSS2d7nNv7Ecw8BQ@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> No, no, don't consider my "put in the merge message" a winner at all.
>
> I personally dislike it, and don't really think it's a wonderful thing
> at all. I really does have real downsides:
>
> - internal signatures really *are* a disaster for maintenance. You
> can never fix them if they need fixing (and "need fixing" may well be
> "you want to re-sign things after a repository format change")
>
> - they are ugly as heck, and you really don't want to see them in
> 99.999% of all cases.
>
> So putting those things iin the merge commit message may have some
> upsides, but it has tons of downsides too.
>
> I think your refs/audit/ idea should be given real thought, because
> maybe that's the right idea.
With the latest round of touch-ups, modulo a few bugs I will be fixing
before the 1.7.8 final, I think what we have is more or less OK in the
shorter term and should be ready for general consumption. The ugliness is
gone, but the issue around internal signatures may remain to be solved in
the longer term. At least, by storing the full contents of the tag today
in an extended header, when we figure out how a detached signature should
really work, we could convert by extracting them from the history.
In a separate message earlier in the thread, you raised another issue.
> I hate how anonymous our branches are. Sure, we can use good names for
> them, but it was a mistake to think we should describe the repository
> (for gitweb), rather than the branch.
>
> Ok, "hate" is a strong word. I don't "hate" it. I don't even think
> it's a major design issue. But I do think that it would have been
> nicer if we had had some branch description model.
At the first glance, our branch model is indeed peculiar in that a branch
does not have a global identity. The scope of its name is local to the
repository, and it is just a pointer into the history. A "note" [*1*] that
can annotate a commit long after the commit is made is not a good way to
describe what a branch is about, because the tip of the branch can advance
beyond the commit that is annotated by such a note. A commit on a branch
does not serve as a good anchoring point to describe the branch.
However, a commit that merges the history of a branch, whether the merged
branch is from a local repository or from a remote one, does serve as a
good anchoring point. The work on a branch is finished as complete as
possible at the time of the merge, and the committer who merges the branch
agrees with both the objective and the implementation of the work done on
the branch, and that is why the merge is made [*2*]. Describing what the
history of the side branch was about in the resulting merge is a perfectly
sensible way to explain the branch. So in that sense, I am very happy with
the way the merge message template uses the pull request tag to let the
lieutenant explain and defend the history behind the tag used for the pull
request. Such an explanation does not have to be keyed with anybody's
local branch name (e.g. "for-linus" would mean different things for
different pull requests even from the same person), but keying it with the
resulting merge commit is a sensible way to leave the record in the
history.
After justifying with the above two paragraphs that it is perfectly
sensible to record the annotations on commits and not on "branch names", I
do agree that we would eventually want to be able to have such annotations
on commits after the fact. Neither "tags" nor "notes" is necessarily a
very good mechanism, however, for the purpose of "signed pull requests"
and "signed commits" [*3*]. Here are some pros and cons:
- tags must be named, but the only thing we need is to be able to look
the contents (with signature if signed) up given a commit object.
Unlike the usual "I want to check out v3.0 release" look-up that goes
from tag names to the commits, annotation look-ups go the other way, do
not have to have a tagname, and having tagname does not help our
look-up in any way. If we want to use tag to annotate various commits
by various people and keep them around, we would need global namespace
that would not cause them to crash (we can work this around by using
the object name of the tag, e.g. renaming 'for-linus' tag to $(git
rev-parse tags/for-linus), but that is merely a workaround of having to
name things that do not have to be named in the first place). As a
local storage machinery for annotations, tags hanging below refs/tags/
(or refs/audit for that matter) hierarchy with their own names is an
inappropriate model.
+ tags can auto-follow the commits when object transfer happens (at least
in the fetch direction), and for the purpose of "signed pull requests"
and "signed commits", this is a desirable property. When a repository
gains a commit, the annotations attached to the commit that are missing
from the receiving repository are automatically transferred from the
place the commit comes from. Annotations given to other commits that
are not transferred into the repository do not come to the repository.
- "git notes" is represented as a commit that records a tree that holds
the entire mapping from commit to its annotations, and the only way to
transferr it is to send it together with its history as a whole. It
does not have the nice auto-following property that transfers only the
relevant annotations.
+ "git notes" maps the commits to its annotations in the right direction;
the object name of an annotated object to its annotation.
In the longer term, I think we would need to extend the system in the
following way:
- Introduce a mapping machanism that can be locally used to map names of
the objects being annotated to names of other objects (most likely
blobs but there is nothing that fundamentally prevents you from
annotating a commit with a tree). The current "git notes" might be a
perfectly suitable representation of this, or it may turn out to be
lacking (I haven't thought things through), but the important point is
that this "mapping store" is _local_. fsck, repack and prune need to be
told that objects that store the annotation are reachable from the
annotated objects.
- Introduce a protocol extension to transfer this mapping information for
objects being transferred in an efficient way. When "rev-list --objects
have..want" tells us that the receiving end (in either fetch/push
direction) would have an object at the end of the primary transfer
(note that I did not say "an object will be sent in this transfer
transaction"; "have" does not come into the picture), we make sure that
missing annotations attached to the object is also transferred, and new
mapping is registered at the receiving end.
The detailed design for the latter needs more thought. The auto-following
of tags works even if nothing is being fetched in the primary transfer
(i.e. "git fetch" && "git fetch" back to back to update our origin/master
with the master at the origin) when a new tag is added to ancient part of
the history that leads to the master at the origin, but this is exactly
because the sending end advertises all the available tags and the objects
they point at so that we can tell what new tags added to an old object is
missing from the receiving end. This obviously would not scale well when
we have tens of thousands of objects to annotate. Perhaps an entry in the
"mapping store" would record:
- The object name of the object being annotated;
- The object name of the annotation;
- The "timestamp", i.e. when the association between the above two was
made--this can be local to the repository and a simple counter would
do.
and also maintain the last "timestamp" this repository sent annotations to
the remote (one timestamp per remote repository). When we push, we would
send annotations pertaining to the object reachable from what we are
pushing (not limited by what they already have, as the whole point of this
exercise is to allow us to transfer annotations added to an object long
after the object was created and sent to the remote) that is newer than
that "timestamp". Similarly, when fetching, we would send the "timestamp"
this repository last fetched annotations from the other end (which means
we would need one such "timestamp" per remote repository) and let the
remote side decide the set of new annotations they added since we last
synched that are on objects reachable from what we "want".
Or something like that.
[Footnote]
*1* By this word, I do not necessarily mean what the "git notes" command
manipulates. A tag that points at a commit is also equally a good vehicle
to annotate a commit after the fact.
*2* For this reason, it may make sense to "commit -S" such a merge
commit. The "mergetag" asserts the authenticity of the pull request from
the lieutenant whose history is being integrated, and the "gpgsig" asserts
the authenticity of the merge itself--the fact that it was made by the
integrator.
*3* I do not mean what "git commit -S" parked in 'pu' produces, which is
to store the signature in the commit. Adding "Signed-off-by:" after the
fact to an existing commit by many people is a more appropriate example.
^ permalink raw reply
* [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
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