* [PATCH] Speedup bash completion loading
From: Kirill Smelkov @ 2009-10-05 10:03 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Kirill Smelkov
On my slow laptop (P3 700MHz), system-wide bash completions take too
much time to load (> 1s), and significant fraction of this time is spent
loading git-completion.bash:
$ time bash -c '. git-completion.bash' # before this patch
real 0m0.317s
user 0m0.250s
sys 0m0.060s
I've tracked down that the most time is spent warming up merge_strategy,
all_command & porcelain_command caches.
Since git is not used in each and every interactive xterm, I think it
would be perfectly ok to load completion support with cold caches, and
then load needed thing lazily.
As __git_merge_stratiegies(), __git_all_commands() &
__git_porcelain_command() already cache their results, we can safely
remove associated cache initialization code and be done with it:
$ time bash -c '. git-completion.bash' # after this patch
real 0m0.069s
user 0m0.050s
sys 0m0.020s
Signed-off-by: Kirill Smelkov <kirr@mns.spb.ru>
---
contrib/completion/git-completion.bash | 3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 2c2a0d4..4c09d41 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -340,7 +340,6 @@ __git_merge_strategies ()
}'
}
__git_merge_strategylist=
-__git_merge_strategylist=$(__git_merge_strategies 2>/dev/null)
__git_complete_file ()
{
@@ -505,7 +504,6 @@ __git_all_commands ()
done
}
__git_all_commandlist=
-__git_all_commandlist="$(__git_all_commands 2>/dev/null)"
__git_porcelain_commands ()
{
@@ -596,7 +594,6 @@ __git_porcelain_commands ()
done
}
__git_porcelain_commandlist=
-__git_porcelain_commandlist="$(__git_porcelain_commands 2>/dev/null)"
__git_aliases ()
{
--
1.6.5.rc2.17.gdbc1b
^ permalink raw reply related
* Re: [PATCH RESEND] git submodule add: make the <path> parameter optional
From: Jens Lehmann @ 2009-10-05 10:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Lars Hjemli, git
In-Reply-To: <7vtyyek4nz.fsf@alter.siamese.dyndns.org>
Junio C Hamano schrieb:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>> So far, I started submodules by cloning them, doing everything in the
>> other files needed to integrate, and then actually wondered why "git
>> submodule add" could not simply take the (relative) path to the
>> checked-out submodule and deduce the URL from the corresponding config?
>
> Let me try to rephrase the above to see if I understand what you are
> doing. When building a top-level superproject that uses two submodules
> from other places, you would do:
>
> $ git init toplevel
> $ cd toplevel
> $ git clone $overthere submodule1
> $ git clone $elsewhere submodule2
> $ edit Makefile common.h
> $ git add Makefile common.h submodule1 submodule2
>
> and by "the corresponding config", you mean "submodule1/.git/config
> already records that it came from $overthere, and there is no reason to
> say it again in 'git submodule add $overthere submodule1'".
Right, no reason to use git submodule add here. But in this example
submodule1 & submodule2 aren't real submodules, because the .gitmodules
file is not created. Or am i missing something?
> If that is the case, I think it is a very sane argument. It also makes me
> wonder why we need "git submodule add" as a separate step to begin with
> (i.e. "git add" Porcelain could do that behind the scene), but that is
> probably a separate topic.
I think we need git submodule add because it is doing much more than
a plain git add. It also does the clone and creates the .gitmodules
file needed later.
My everyday use case looks different. When i start a new project where
i want to use two of libraries living in their own git repo, i do:
$ git init toplevel
$ cd toplevel
$ git submodule add git://mygitserver/submodule1.git submodule1
$ git submodule add git://mygitserver/submodule2.git submodule2
$ git commit -m 'Initial setup with submodule1 & submodule2'
After the submodule add submodule1, submodule2 and .gitmodules are
added to the index and the two repositories are cloned, so i just
have to do a commit when ready.
And with my patch the two submodule add lines read:
$ git submodule add git://mygitserver/submodule1.git
$ git submodule add git://mygitserver/submodule2.git
Which then resembles the command i would use when i want to clone them
on their own:
$ git clone git://mygitserver/submodule1.git
>> So I would actually vote for making the <repository> parameter optional...
>
> In your "git submodule add submodule1", it would be quite clear that it is
> a local path and <repository> is being omitted. On the other hand, if you
> said "git submodule add $overthere" without submodule1, because $overthere
> is not likely to be an in-tree path, it also would be clear that it is
> omitting the path. IOW, these two typesavers are not mutually exclusive.
>
> In real life, it is very likely $overthere does _not_ end with submodule1,
> and your suggestion would probably be more useful than the patch under
> discussion, I think.
Actually, for me $overthere is _always_ a treeish path (e.g. ends with
submodule1 or submodule1.git). And almost always i have no reason to
name the local directory different than the repo.
Jens
^ permalink raw reply
* Re: [PATCH] Add the --submodule-summary option to the diff option family
From: Jens Lehmann @ 2009-10-05 11:22 UTC (permalink / raw)
To: Johannes Schindelin, Junio C Hamano, Lars Hjemli; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0910051027010.4985@pacific.mpi-cbg.de>
First: I already coded a test and am using this patch in git gui and
gitk (there was no way git submodule summary would have worked for
gitk, now it does). Looking really good, will post when this patch
solidifies ...
Johannes Schindelin schrieb:
> That's something I will gladly do after I adjusted the format to look a
> bit more like "git submodule summary" (Jens noticed 4 differences), and
> after Jens patched git-submodule.sh to use the diff mode instead.
Actually there are two more and Junio pointed out #7: submodule summary
uses --first-parent and we don't (My testcases don't contain merges, so
i didn't notice).
The difference that is most obvious and was unintended is that the
shortlog is indented by four spaces instead of two. I appended an
interdiff to fix that.
As with the other six, i am not really sure if we should just copy the
behaviour of git submodule summary.
> IOW in hindsight I would like to add the prefix "RFC/RFH" to the subject.
FullAck.
First some examples for the current behaviour (with the patch below
applied):
$ git diff --submodule-summary
Submodule sub 5431f52..3f35670:
> sub3
$ git submodule summary --files
* sub 5431f52...3f35670 (1):
> sub3
$ git diff-index --submodule-summary HEAD -p
Submodule sub 81d7059..3f35670:
> sub3
> sub2
$ git submodule summary
* sub 81d7059...3f35670 (2):
> sub3
> sub2
[$ git diff --cached --submodule-summary HEAD
Submodule sub 81d7059..5431f52:
> sub2
$ git submodule summary --cached
* sub 81d7059...5431f52 (1):
> sub2
$
So the differences are:
1) Dscho replaced the leading '*' with the more explicit "Submodule"
I like the explicit version.
2) submodule summary prints out how many shortlog entries are following
3) submodule summary adds a newline after the shortlog
4) submodule summary uses --first-parent
No idea about the intention here. Lars?
5) submodule summary always prints three '.' between the hashes
Seems like submodule summary didn't do the hassle for performance
reasons. But for consistency i would prefer the new version as we
use it all over the place, no?
6) submodule summary can limit the number of shortlog lines
Hm, i want to see them all. Any users of that -n option?
To take this a bit further: It might be a good idea to let git diff
generate output for submodules that is consistent with that for regular
files. So instead of:
git diff --cached --submodule-summary HEAD -p
Submodule sub 81d7059..5431f52:
> sub2
we could produce:
diff --git a/sub b/sub
index 81d7059..3f35670 160000
--- a/sub
+++ b/sub
@@ -1 +1 @@
-Subproject commit 81d70590e6aaf9f995ebf4d6d284a7ebb355398d
+Subproject commit 3f356705649b5d566d97ff843cf193359229a453
> sub2
(This is the output of a git diff without the --submodule-summary option
with an appended shortlog)
I like the second variant (mainly because of consistency). Opinions?
And here the promised indentation depth fix interdiff:
------------------8<-----------------
diff --git a/submodule.c b/submodule.c
index 3f2590d..11fce7d 100644
--- a/submodule.c
+++ b/submodule.c
@@ -42,7 +42,7 @@ void show_submodule_summary(FILE *f, const char *path,
struct commit_list *merge_bases, *list;
const char *message = NULL;
struct strbuf sb = STRBUF_INIT;
- static const char *format = " %m %s";
+ static const char *format = " %m %s";
int fast_forward = 0, fast_backward = 0;
if (add_submodule_odb(path))
^ permalink raw reply related
* Re: Confusing git pull error message
From: Johannes Sixt @ 2009-10-05 11:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, John Tapsell, Git List
In-Reply-To: <7v1vmar353.fsf@alter.siamese.dyndns.org>
Junio C Hamano schrieb:
> Jeff King <peff@peff.net> writes:
>> I think it is enough for git-pull to just check whether the config
>> exists, and if so, guess that the ref was simply not fetched. IOW,
>> this:
>
> Thanks.
>
> I saw some discussion on improving the wording. Here is what I plan to
> commit.
>
> diff --git a/git-pull.sh b/git-pull.sh
> index 0bbd5bf..2c2fa79 100755
> --- a/git-pull.sh
> +++ b/git-pull.sh
> @@ -89,6 +89,8 @@ error_on_no_merge_candidates () {
> done
>
> curr_branch=${curr_branch#refs/heads/}
> + upstream=$(git config "branch.$curr_branch.merge" ||
> + git config "branch.$curr_branch.rebase")
>
> if [ -z "$curr_branch" ]; then
> echo "You are not currently on a branch, so I cannot use any"
> @@ -96,7 +98,7 @@ error_on_no_merge_candidates () {
> echo "Please specify which branch you want to merge on the command"
> echo "line and try again (e.g. 'git pull <repository> <refspec>')."
> echo "See git-pull(1) for details."
> - else
> + elif [ -z "$upstream" ]; then
> echo "You asked me to pull without telling me which branch you"
> echo "want to merge with, and 'branch.${curr_branch}.merge' in"
> echo "your configuration file does not tell me either. Please"
> @@ -114,6 +116,10 @@ error_on_no_merge_candidates () {
> echo " remote.<nickname>.fetch = <refspec>"
> echo
> echo "See git-config(1) for details."
> + else
> + echo "Your configuration specifies to merge the ref"
> + echo "'${upstream#refs/heads/}' from the remote, but no such ref"
> + echo "was fetched."
> fi
> exit 1
> }
Unfortunately, this is not water-tight. See what I just observed:
$ git pull hk
From /exports/repos/hk/viscovery
9455552..6429037 master -> hk/master
Your configuration specifies to merge the ref
'master' from the remote, but no such ref
was fetched.
The message is confusing when it says "'master' was not fetched" when
clearly master _was_ fetched.
More importantly, the message is wrong to say that "Your configuration
specifies to merge the ref 'master' from the remote", because I have this
configuration:
$ git config -l | egrep '^(remote|branch)'
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
remote.origin.url=/exports/repos/js/viscovery
branch.master.remote=origin
branch.master.merge=refs/heads/master
remote.hk.url=/exports/repos/hk/viscovery
remote.hk.fetch=+refs/heads/*:refs/remotes/hk/*
i.e. while on master, I merge master from "origin", not from "hk".
-- Hannes
^ permalink raw reply
* Re: Confusing git pull error message
From: Jeff King @ 2009-10-05 11:53 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, John Tapsell, Git List
In-Reply-To: <4AC9D952.3050108@viscovery.net>
On Mon, Oct 05, 2009 at 01:32:34PM +0200, Johannes Sixt wrote:
> Unfortunately, this is not water-tight. See what I just observed:
>
> $ git pull hk
> From /exports/repos/hk/viscovery
> 9455552..6429037 master -> hk/master
> Your configuration specifies to merge the ref
> 'master' from the remote, but no such ref
> was fetched.
>
> The message is confusing when it says "'master' was not fetched" when
> clearly master _was_ fetched.
>
> More importantly, the message is wrong to say that "Your configuration
> specifies to merge the ref 'master' from the remote", because I have this
> configuration:
Ah, yeah. Looking at %(upstream) from for-each-ref (which is how we
determine to show that message) always uses the configured remote. But
if we have asked for another remote, then that doesn't make much sense.
So I think we need something like this. I wasn't able to figure out a
test case to trigger the first code path below, though. It may not be
possible; if we give a refspec on the command line, either it will be a
candidate for merging or, if it does not exist, fetch will barf. So it
may be that we can just collapse it down to a single case.
diff --git a/git-pull.sh b/git-pull.sh
index edf3ce3..a831db5 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -97,6 +97,18 @@ error_on_no_merge_candidates () {
echo "Please specify which branch you want to merge on the command"
echo "line and try again (e.g. 'git pull <repository> <refspec>')."
echo "See git-pull(1) for details."
+ elif [ -n "$1" ]; then
+ if [ $# -gt 1 ]; then
+ echo "You asked to pull from the remote '$1', but none"
+ echo "of the things you asked to fetch were candidates"
+ echo "for merging."
+ else
+ echo "You asked to pull from the remote '$1', but did"
+ echo "not specify a branch to merge. Because this is"
+ echo "not the default configured remote for your current"
+ echo "branch, you must specify a branch on the command"
+ echo "line."
+ fi
elif [ -z "$upstream" ]; then
echo "You asked me to pull without telling me which branch you"
echo "want to merge with, and 'branch.${curr_branch}.merge' in"
^ permalink raw reply related
* Can I retrieve changes from deleted stash?
From: Daniel @ 2009-10-05 12:05 UTC (permalink / raw)
To: git
I did:
$ git stash
$ git pop
$ git checkout -- <modified files>
Now I don't have changes I stashed. I guess the blobs with stashed
files should be somewhere? Is there any way I can get back my changes?
I tried to use git-reflog, but I'm not sure how can I find the files
I need.
^ permalink raw reply
* Re: Confusing git pull error message
From: Johannes Sixt @ 2009-10-05 12:13 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, John Tapsell, Git List
In-Reply-To: <20091005115308.GA2122@coredump.intra.peff.net>
Jeff King schrieb:
> On Mon, Oct 05, 2009 at 01:32:34PM +0200, Johannes Sixt wrote:
> Ah, yeah. Looking at %(upstream) from for-each-ref (which is how we
> determine to show that message) always uses the configured remote. But
> if we have asked for another remote, then that doesn't make much sense.
>
> So I think we need something like this. I wasn't able to figure out a
> test case to trigger the first code path below, though. It may not be
> possible; if we give a refspec on the command line, either it will be a
> candidate for merging or, if it does not exist, fetch will barf. So it
> may be that we can just collapse it down to a single case.
>
> diff --git a/git-pull.sh b/git-pull.sh
> index edf3ce3..a831db5 100755
> --- a/git-pull.sh
> +++ b/git-pull.sh
> @@ -97,6 +97,18 @@ error_on_no_merge_candidates () {
> echo "Please specify which branch you want to merge on the command"
> echo "line and try again (e.g. 'git pull <repository> <refspec>')."
> echo "See git-pull(1) for details."
> + elif [ -n "$1" ]; then
> + if [ $# -gt 1 ]; then
> + echo "You asked to pull from the remote '$1', but none"
> + echo "of the things you asked to fetch were candidates"
> + echo "for merging."
> + else
> + echo "You asked to pull from the remote '$1', but did"
> + echo "not specify a branch to merge. Because this is"
> + echo "not the default configured remote for your current"
> + echo "branch, you must specify a branch on the command"
> + echo "line."
> + fi
> elif [ -z "$upstream" ]; then
> echo "You asked me to pull without telling me which branch you"
> echo "want to merge with, and 'branch.${curr_branch}.merge' in"
Thanks, this gives a much better error message.
But, can we *please* have a more pleasantly wrapped message, even if this
grows lines in the source code beyond the 80 char limit? Like:
echo "You asked to pull from the remote '$1',"
echo "but did not specify a branch to merge. Because this is"
echo "not the default configured remote for your current branch,"
echo "you must specify a branch on the command line."
I.e.:
- Reserve more room for a long $1 in the first line.
- Don't wrap lines in "current branch" and "command line" when they are at
the end of a major logical unit of the sentence.
-- Hannes
^ permalink raw reply
* Re: Can I retrieve changes from deleted stash?
From: Thomas Rast @ 2009-10-05 12:30 UTC (permalink / raw)
To: Daniel; +Cc: git
In-Reply-To: <c18a43e.55008170.4ac9e127.2a972@o2.pl>
[-- Attachment #1: Type: Text/Plain, Size: 901 bytes --]
Daniel wrote:
> I did:
>
> $ git stash
> $ git pop
>
> $ git checkout -- <modified files>
>
> Now I don't have changes I stashed. I guess the blobs with stashed
> files should be somewhere? Is there any way I can get back my changes?
> I tried to use git-reflog, but I'm not sure how can I find the files
> I need.
The problem is that the stash itself is a reflog, so there is no extra
safety layer.
Recent versions of the git-stash(1) manpage[*] document a command that
helps find the stashes: if you do not explicitly name them, the they
will be called "WIP on <subject>" and can thus be found with
git fsck --unreachable |
grep commit | cut -d\ -f3 |
xargs git log --merges --no-walk --grep=WIP
[*] you can find a bleeding edge version at
http://www.kernel.org/pub/software/scm/git/docs/git-stash.html
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Can I retrieve changes from deleted stash?
From: mjucde @ 2009-10-05 12:50 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <200910051430.17559.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> wrote:
> Daniel wrote:
> > I did:
> >
> > $ git stash
> > $ git pop
> >
> > $ git checkout -- <modified files>
> >
> > Now I don't have changes I stashed. I guess the blobs with stashed
> > files should be somewhere? Is there any way I can get back my changes?
> > I tried to use git-reflog, but I'm not sure how can I find the files
> > I need.
>
> The problem is that the stash itself is a reflog, so there is no extra
> safety layer.
>
> Recent versions of the git-stash(1) manpage[*] document a command that
> helps find the stashes: if you do not explicitly name them, the they
> will be called "WIP on <subject>" and can thus be found with
>
> git fsck --unreachable |
> grep commit | cut -d\ -f3 |
> xargs git log --merges --no-walk --grep=WIP
>
>
> [*] you can find a bleeding edge version at
>
> http://www.kernel.org/pub/software/scm/git/docs/git-stash.html
>
> --
> Thomas Rast
> trast@{inf,student}.ethz.ch
>
Thanks, that did the trick :)
^ permalink raw reply
* Re: [PATCH 2/6 (v4)] basic revision cache system, no integration or features
From: Nick Edelen @ 2009-10-05 12:51 UTC (permalink / raw)
To: Junio C Hamano
Cc: Nicolas Pitre, Johannes Schindelin, Sam Vilain, Michael J Gruber,
Jeff King, Shawn O. Pearce, Andreas Ericsson, Christian Couder,
git@vger.kernel.org
In-Reply-To: <7vbpkmk2mm.fsf@alter.siamese.dyndns.org>
> The entire series is unusable due to whitespace breakage.
Shit sorry about that. I think my mail client reset some settings
when I upgraded. Will resend.
I feel like such a klutz...
^ permalink raw reply
* Re: [PATCH 2/6 (v4)] basic revision cache system, no integration or features
From: Sverre Rabbelier @ 2009-10-05 12:56 UTC (permalink / raw)
To: Nick Edelen
Cc: Junio C Hamano, Nicolas Pitre, Johannes Schindelin, Sam Vilain,
Michael J Gruber, Jeff King, Shawn O. Pearce, Andreas Ericsson,
Christian Couder, git@vger.kernel.org
In-Reply-To: <op.uys3qlsjtdk399@sirnot.private>
Heya,
On Mon, Aug 17, 2009 at 14:31, Nick Edelen <sirnot@gmail.com> wrote:
> 1618 insertions(+)
Really?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [RFCv4 3/5] 2/2: Add Python support library for CVS remote helper
From: Sverre Rabbelier @ 2009-10-05 13:31 UTC (permalink / raw)
To: Johan Herland
Cc: Git List, Johannes Schindelin, Daniel Barkalow, David Aguilar,
Junio C Hamano
In-Reply-To: <1250480161-21933-4-git-send-email-johan@herland.net>
Heya,
On Mon, Aug 17, 2009 at 05:35, Johan Herland <johan@herland.net> wrote:
> This patch introduces the rest of a Python package called "git_remote_cvs"
> containing the building blocks of the CVS remote helper. The CVS remote
> helper itself is NOT part of this patch.
Might I suggest that we pool our efforts and instead create a structure like:
git_remote_helpers/
git_remote_helpers/__init__.py
git_remote_helpers/Makefile
git_remote_helpers/setup.py
git_remote_helpers/util.py
git_remote_helpers/git
git_remote_helpers/git/__init__.py
git_remote_helpers/git/
git_remote_helpers/cvs
git_remote_helpers/cvs/__init__.py
git_remote_helpers/cvs/changeset.py
git_remote_helpers/cvs/commit_states.py
git_remote_helpers/cvs/cvs.py
git_remote_helpers/cvs/revision_map.py
git_remote_helpers/cvs/symbol_cache.py
git_remote_helpers/hg
git_remote_helpers/hg/__init__.py
git_remote_helpers/hg/hg.py
git_remote_helpers/hg/export.py
I'm willing to spend some time to do the needed refactoring, but IIUC
Daniel said that you need to reroll the cvs series anyway?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [RFCv4 3/5] 2/2: Add Python support library for CVS remote helper
From: Johan Herland @ 2009-10-05 14:41 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Git List, Johannes Schindelin, Daniel Barkalow, David Aguilar,
Junio C Hamano
In-Reply-To: <fabb9a1e0910050631j73bf7288w65da92806332d051@mail.gmail.com>
On Monday 05 October 2009, Sverre Rabbelier wrote:
> On Mon, Aug 17, 2009, Johan Herland <johan@herland.net> wrote:
> > This patch introduces the rest of a Python package called
> > "git_remote_cvs" containing the building blocks of the CVS remote
> > helper. The CVS remote helper itself is NOT part of this patch.
>
> Might I suggest that we pool our efforts and instead create a
> structure like:
>
> git_remote_helpers/
> git_remote_helpers/__init__.py
> git_remote_helpers/Makefile
> git_remote_helpers/setup.py
> git_remote_helpers/util.py
> git_remote_helpers/git
> git_remote_helpers/git/__init__.py
> git_remote_helpers/git/
> git_remote_helpers/cvs
> git_remote_helpers/cvs/__init__.py
> git_remote_helpers/cvs/changeset.py
> git_remote_helpers/cvs/commit_states.py
> git_remote_helpers/cvs/cvs.py
> git_remote_helpers/cvs/revision_map.py
> git_remote_helpers/cvs/symbol_cache.py
> git_remote_helpers/hg
> git_remote_helpers/hg/__init__.py
> git_remote_helpers/hg/hg.py
> git_remote_helpers/hg/export.py
I like this. One couple of questions (for now):
- Are you planning to share directory structure only, or some of the
Python code as well? From the above structure it seems like you want to
make use of e.g. util.py and git.py. I'd be delighted if the code is
reusable by other remote helpers.
- Do you plan to put the remote helpers into this structure as well, or
keep them separate? (currently the cvs remote helper lives separately
in git-remote-cvs.py in the project root directory)
> I'm willing to spend some time to do the needed refactoring, but IIUC
> Daniel said that you need to reroll the cvs series anyway?
Yeah, a re-roll was planned once the sr/gfi-options work was finalized.
(right now I'm mostly focused on the jh/notes work). Feel free to post
the hg-specific and/or common parts as a separate patch, and I can
rebase the CVS series on top of that before I submit the next
iteration.
Nice to see people starting to pick up the foreign-vcs work. :)
Have fun! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [RFCv4 3/5] 2/2: Add Python support library for CVS remote helper
From: Sverre Rabbelier @ 2009-10-05 14:50 UTC (permalink / raw)
To: Johan Herland
Cc: Git List, Johannes Schindelin, Daniel Barkalow, David Aguilar,
Junio C Hamano
In-Reply-To: <200910051641.43136.johan@herland.net>
Heya,
On Mon, Oct 5, 2009 at 16:41, Johan Herland <johan@herland.net> wrote:
> - Are you planning to share directory structure only, or some of the
> Python code as well? From the above structure it seems like you want to
> make use of e.g. util.py and git.py. I'd be delighted if the code is
> reusable by other remote helpers.
Yes, the main reason I suggested this was because I want to reuse
util.py and git.py :). Of course, it'd probably be cleaner to move the
little CVS-specific code that is in git.py atm out of it.
> - Do you plan to put the remote helpers into this structure as well, or
> keep them separate? (currently the cvs remote helper lives separately
> in git-remote-cvs.py in the project root directory)
I think it's good where it is right now, and I've also placed
git-remote-hg.py in the root directory.
>> I'm willing to spend some time to do the needed refactoring, but IIUC
>> Daniel said that you need to reroll the cvs series anyway?
>
> Yeah, a re-roll was planned once the sr/gfi-options work was finalized.
> (right now I'm mostly focused on the jh/notes work). Feel free to post
> the hg-specific and/or common parts as a separate patch, and I can
> rebase the CVS series on top of that before I submit the next
> iteration.
Yeah, I'm waiting on Shawn to decide what should be done with the
whole options thing before I resubmit sr/gfi-options.
> Nice to see people starting to pick up the foreign-vcs work. :)
Now if only we could bribe Eric to write a svn helper :).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Interim maintainer tree
From: Shawn O. Pearce @ 2009-10-05 14:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7viqevu1zt.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
> > Junio is on vaction for the next week. In his absence Peff and I
> > are trying to keep up with current patches in my fork:
> >
> > git://repo.or.cz/git/spearce.git
> > http://repo.or.cz/r/git/spearce.git
> >
> > Right now the tree matches Junio's last push, I'll try to pick up
> > the patches since then and push later today.
>
> Thanks, both.
>
> I've fetched, but haven't fully examined "log ..spearce/*" nor "log ..peff/*"
> yet.
Sorry, I proved to be a very poor interim maintainer this cycle.
I just didn't have the time to keep up with integration each day,
and then dropped the ball on Thursday and Friday and failed to pull
anything from Peff or the list. Peff, thanks for keeping up a bit
and at least having some tips for Junio to pick up from.
> I noticed that some topics in 'pu' have been rebased (not complaining, but
> just making sure I am not hallucinating).
Yes, some topics in 'pu' got rebased. Wednesday I ran RB
after preparing a new master, and then rebuilt pu around it.
Unfortunately I somehow lost a patch on Nick's rev-list series,
not sure how I managed to do that, but I guess I did, sorry.
Were you no longer in the habit of running RB when you rebuilt pu?
--
Shawn.
^ permalink raw reply
* Re: Interim maintainer tree
From: Jeff King @ 2009-10-05 15:05 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20091005145615.GA9261@spearce.org>
On Mon, Oct 05, 2009 at 07:56:15AM -0700, Shawn O. Pearce wrote:
> Sorry, I proved to be a very poor interim maintainer this cycle.
> I just didn't have the time to keep up with integration each day,
> and then dropped the ball on Thursday and Friday and failed to pull
> anything from Peff or the list. Peff, thanks for keeping up a bit
> and at least having some tips for Junio to pick up from.
It was an interesting experience this time, having two people doing it.
I think the communication overhead may have overwhelmed any help we were
giving each other. Perhaps if there had been more, larger series, it
might have made sense to assign somebody to track a topic and its
iterations, and then finally sign off on it being ready. But being -rc
period, things seem to have settled down, and most patches were one-off
bugfixes all over the place.
-Peff
^ permalink raw reply
* Re: [PATCH] Speedup bash completion loading
From: Shawn O. Pearce @ 2009-10-05 15:25 UTC (permalink / raw)
To: Kirill Smelkov; +Cc: git
In-Reply-To: <1254737039-10404-1-git-send-email-kirr@mns.spb.ru>
Kirill Smelkov <kirr@mns.spb.ru> wrote:
> I've tracked down that the most time is spent warming up merge_strategy,
> all_command & porcelain_command caches.
Nak.
The problem is, during completion when we modify the value the
change doesn't persist beyond the current completion invocation.
Thus there is no value in the cache, so every completion attempt
which needs the list has to rerun the command to compute it.
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index 2c2a0d4..4c09d41 100755
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -340,7 +340,6 @@ __git_merge_strategies ()
> }'
> }
> __git_merge_strategylist=
> -__git_merge_strategylist=$(__git_merge_strategies 2>/dev/null)
>
> __git_complete_file ()
> {
> @@ -505,7 +504,6 @@ __git_all_commands ()
> done
> }
> __git_all_commandlist=
> -__git_all_commandlist="$(__git_all_commands 2>/dev/null)"
>
> __git_porcelain_commands ()
> {
> @@ -596,7 +594,6 @@ __git_porcelain_commands ()
> done
> }
> __git_porcelain_commandlist=
> -__git_porcelain_commandlist="$(__git_porcelain_commands 2>/dev/null)"
>
> __git_aliases ()
> {
> --
> 1.6.5.rc2.17.gdbc1b
>
--
Shawn.
^ permalink raw reply
* Re: [PATCH 1/6] Open the pack file and keep a map on it.
From: Shawn O. Pearce @ 2009-10-05 15:27 UTC (permalink / raw)
To: Herv?? Cauwelier; +Cc: git
In-Reply-To: <1254593401-18801-2-git-send-email-herve@itaapy.com>
Herv?? Cauwelier <herve@itaapy.com> wrote:
> diff --git a/src/odb.h b/src/odb.h
> index 2f205b2..0311d78 100644
> --- a/src/odb.h
> +++ b/src/odb.h
> @@ -11,9 +11,10 @@
> * uint32_t *fanout = ... the file data at offset 0 ...
> * ntohl(fanout[0]) < ntohl(fanout[1])
> *
> - * The value chosen here for PACK_TOC is such that the above
> + * The value chosen here for IDX_TOC is such that the above
> * cannot be true for an idx v1 file.
> */
> -#define PACK_TOC 0xff744f63 /* -1tOc */
> +#define IDX_TOC 0xff744f63 /* -1tOc */
> +#define PACK_TOC 0x5041434b /* PACK */
FWIW, I wouldn't call the magic string 'PACK' PACK_TOC. TOC here
meant "table of contents". The magic string '-1tOc' for PACK_TOC
is no accident, its trying to show that this file is a table of
contents file.
I think at the time I meant for PACK_TOC to be the pack-*.idx
header magic string, and PACK_SIG or PACK_HDR to be the magic
string for pack-*.pack.
--
Shawn.
^ permalink raw reply
* Re: [RFCv4 3/5] 2/2: Add Python support library for CVS remote helper
From: Johan Herland @ 2009-10-05 15:35 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Git List, Johannes Schindelin, Daniel Barkalow, David Aguilar,
Junio C Hamano
In-Reply-To: <fabb9a1e0910050750q195bdafv5511915fe5d26c02@mail.gmail.com>
On Monday 05 October 2009, Sverre Rabbelier wrote:
> On Mon, Oct 5, 2009 at 16:41, Johan Herland <johan@herland.net> wrote:
> > - Are you planning to share directory structure only, or some of
> > the Python code as well? From the above structure it seems like you
> > want to make use of e.g. util.py and git.py. I'd be delighted if
> > the code is reusable by other remote helpers.
>
> Yes, the main reason I suggested this was because I want to reuse
> util.py and git.py :). Of course, it'd probably be cleaner to move
> the little CVS-specific code that is in git.py atm out of it.
Sure. Refactor away. :)
> > - Do you plan to put the remote helpers into this structure as
> > well, or keep them separate? (currently the cvs remote helper lives
> > separately in git-remote-cvs.py in the project root directory)
>
> I think it's good where it is right now, and I've also placed
> git-remote-hg.py in the root directory.
Ok.
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [PATCH] Teach 'rebase -i' the command "amend"
From: Björn Gustavsson @ 2009-10-05 16:10 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Johannes Schindelin, git, gitster
In-Reply-To: <fabb9a1e0910050239h614118cfw8a5055e4ed966dd1@mail.gmail.com>
On Mon, Oct 5, 2009 at 11:39 AM, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> 2009/10/5 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>> My objection was that the "upcoming" (yeah, Sverre, I am imitating Duke
>> Nukem Forever here) "merge" command would clash with "msgedit", which was
>> why I suggested "rephrase" (but would be okay with "reword" Junio
>> mentions).
>
> I also dislike 'msgedit' because it's abbrev-ed, I would prefer
> "reword" for that reason.
>
Thanks for the comments. "reword" it will be then. I'll send a new patch soon.
--
Björn Gustavsson, Erlang/OTP, Ericsson AB
^ permalink raw reply
* [PATCH] Teach 'rebase -i' the command "reword"
From: Björn Gustavsson @ 2009-10-05 16:16 UTC (permalink / raw)
To: git; +Cc: gitster
Make it easier to edit just the commit message for a commit
using 'git rebase -i' by introducing the "reword" command.
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
---
Here is the re-roll of my previous patch.
The only difference is that "amend" (which would be mis-leading)
has been replaced with "reword".
Documentation/git-rebase.txt | 3 +++
git-rebase--interactive.sh | 9 +++++++++
t/lib-rebase.sh | 6 +++---
t/t3404-rebase-interactive.sh | 14 ++++++++++++++
4 files changed, 29 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index 0aefc34..52af656 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -368,6 +368,9 @@ By replacing the command "pick" with the command "edit", you can tell
the files and/or the commit message, amend the commit, and continue
rebasing.
+If you just want to edit the commit message for a commit, you can replace
+the command "pick" with the command "reword".
+
If you want to fold two or more commits into one, replace the command
"pick" with "squash" for the second and subsequent commit. If the
commits had different authors, it will attribute the squashed commit to
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 23ded48..30c2f62 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -340,6 +340,14 @@ do_next () {
pick_one $sha1 ||
die_with_patch $sha1 "Could not apply $sha1... $rest"
;;
+ reword|r)
+ comment_for_reflog reword
+
+ mark_action_done
+ pick_one $sha1 ||
+ die_with_patch $sha1 "Could not apply $sha1... $rest"
+ output git commit --amend
+ ;;
edit|e)
comment_for_reflog edit
@@ -752,6 +760,7 @@ first and then run 'git rebase --continue' again."
#
# Commands:
# p, pick = use commit
+# r, reword = use commit, but allow editing of the commit message
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
#
diff --git a/t/lib-rebase.sh b/t/lib-rebase.sh
index 260a231..62f452c 100644
--- a/t/lib-rebase.sh
+++ b/t/lib-rebase.sh
@@ -9,8 +9,8 @@
#
# "[<lineno1>] [<lineno2>]..."
#
-# If a line number is prefixed with "squash" or "edit", the respective line's
-# command will be replaced with the specified one.
+# If a line number is prefixed with "squash", "edit", or "reword", the
+# respective line's command will be replaced with the specified one.
set_fake_editor () {
echo "#!$SHELL_PATH" >fake-editor.sh
@@ -32,7 +32,7 @@ cat "$1".tmp
action=pick
for line in $FAKE_LINES; do
case $line in
- squash|edit)
+ squash|edit|reword)
action="$line";;
*)
echo sed -n "${line}s/^pick/$action/p"
diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
index 4cae019..3a37793 100755
--- a/t/t3404-rebase-interactive.sh
+++ b/t/t3404-rebase-interactive.sh
@@ -470,4 +470,18 @@ test_expect_success 'avoid unnecessary reset' '
test 123456789 = $MTIME
'
+test_expect_success 'reword' '
+ git checkout -b reword-branch master &&
+ FAKE_LINES="1 2 3 reword 4" FAKE_COMMIT_MESSAGE="E changed" git rebase -i A &&
+ git show HEAD | grep "E changed" &&
+ test $(git rev-parse master) != $(git rev-parse HEAD) &&
+ test $(git rev-parse master^) = $(git rev-parse HEAD^) &&
+ FAKE_LINES="1 2 reword 3 4" FAKE_COMMIT_MESSAGE="D changed" git rebase -i A &&
+ git show HEAD^ | grep "D changed" &&
+ FAKE_LINES="reword 1 2 3 4" FAKE_COMMIT_MESSAGE="B changed" git rebase -i A &&
+ git show HEAD~3 | grep "B changed" &&
+ FAKE_LINES="1 reword 2 3 4" FAKE_COMMIT_MESSAGE="C changed" git rebase -i A &&
+ git show HEAD~2 | grep "C changed"
+'
+
test_done
--
1.6.5.rc2.18.g020de
^ permalink raw reply related
* [PATCH] git-send-email.perl: Fold long header lines to 78 chars
From: Joe Perches @ 2009-10-05 16:24 UTC (permalink / raw)
To: git; +Cc: Jay Soffian
Some MTAs reject or filter long header lines which can
be generated if the cc list is only a few entries.
Fold long header lines to 78 chars to be more rfc compliant.
Signed-off-by: Joe Perches <joe@perches.com>
diff --git a/git-send-email.perl b/git-send-email.perl
index dd821f7..cb8b48b 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -814,6 +814,41 @@ sub sanitize_address
}
+# Fold header lines to 78 chars if possible for better RFC 2822 compliance
+# Does not terminate last line with newline
+sub fold_header
+{
+ my ($folded_line, $separator, @entries) = @_;
+ my $folded_header = "";
+ my $count = 0;
+ my $trim_sep = $separator;
+
+ $trim_sep =~ s/\s+$//;
+
+ foreach my $entry (@entries) {
+ if ($count == 0) {
+ $folded_line = "$folded_line$entry";
+ } elsif ((length($folded_line) + length($entry)) > 78) {
+ if ($folded_header ne "") {
+ $folded_header = "$folded_header$trim_sep\n";
+ }
+ $folded_header = "$folded_header$folded_line";
+ $folded_line = " $entry";
+ } else {
+ $folded_line = "$folded_line$separator$entry";
+ }
+ $count++;
+ }
+
+ if ($count == 0) {
+ $folded_header = "$folded_line";
+ } else {
+ $folded_header = "$folded_header$trim_sep\n$folded_line";
+ }
+
+ return "$folded_header";
+}
+
# Returns 1 if the message was sent, and 0 otherwise.
# In actuality, the whole program dies when there
# is an error sending a message.
@@ -835,10 +870,10 @@ sub send_message
$gitversion = Git::version();
}
- my $cc = join(", ", unique_email_list(@cc));
+ @cc = unique_email_list(@cc);
my $ccline = "";
- if ($cc ne '') {
- $ccline = "\nCc: $cc";
+ if (@cc gt 0) {
+ $ccline = fold_header("\nCc: ", ", ", @cc);
}
my $sanitized_sender = sanitize_address($sender);
make_message_id() unless defined($message_id);
@@ -976,7 +1011,7 @@ X-Mailer: git-send-email $gitversion
if ($smtp_server !~ m#^/#) {
print "Server: $smtp_server\n";
print "MAIL FROM:<$raw_from>\n";
- print "RCPT TO:".join(',',(map { "<$_>" } @recipients))."\n";
+ print fold_header("RCPT TO:", ",", map { "<$_>" } @recipients)."\n";
} else {
print "Sendmail: $smtp_server ".join(' ',@sendmail_parameters)."\n";
}
^ permalink raw reply related
* Re: [PATCH] Speedup bash completion loading
From: Kirill Smelkov @ 2009-10-05 16:58 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20091005152504.GE9261@spearce.org>
On Mon, Oct 05, 2009 at 08:25:04AM -0700, Shawn O. Pearce wrote:
> Kirill Smelkov <kirr@mns.spb.ru> wrote:
> > I've tracked down that the most time is spent warming up merge_strategy,
> > all_command & porcelain_command caches.
>
> Nak.
>
> The problem is, during completion when we modify the value the
> change doesn't persist beyond the current completion invocation.
> Thus there is no value in the cache, so every completion attempt
> which needs the list has to rerun the command to compute it.
Yes, my mistake.
To avoid spawning subshell on $(__git_porcelain_commands) I could come up
with "caching" at the upper level, as e.g.
@@ -2107,7 +2111,10 @@ _git ()
--help
"
;;
- *) __gitcomp "$(__git_porcelain_commands) $(__git_aliases)" ;;
+ *) __gitcomp "
+ ${__git_porcelain_commandlist:=$(__git_porcelain_commands)}
+ $(__git_aliases)
+ " ;;
but that's ugly and not maintainable since e.g. __git_all_commands() is used in
several places.
The other possibility is to pregenerate all these lists at git build time, but
are we going to do it for things under contrib/ ?
This could have easy solution if bash provided analog of $() to call a function
and obtain either its stdout or return value without spawning subshell, but up
to now I could not find such a construct in bash's man.
I have to go, but I'll try to come up with something practical in several days.
Thanks for spotting it,
Kirill
^ permalink raw reply
* Re: [PATCH] Add the --submodule-summary option to the diff option family
From: Jens Lehmann @ 2009-10-05 17:32 UTC (permalink / raw)
To: Johannes Schindelin, Junio C Hamano, Lars Hjemli; +Cc: git
In-Reply-To: <4AC9D6EB.8090002@web.de>
A bug showed up in the tests, deleted submodules were labelled
"(not checked out)" instead of "(submodule deleted)". This patch
fixes that.
--------------------------8<--------------------
[PATCH] fix output for deleted submodules in git diff --submodule-summary
When a submodule has been deleted, add_submodule_odb() returns false
because the directory of the submodule is gone. So we have to test the
second sha for null before we call add_submodule_odb() to get the correct
output.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
---
submodule.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/submodule.c b/submodule.c
index 11fce7d..54c8de8 100644
--- a/submodule.c
+++ b/submodule.c
@@ -45,12 +45,12 @@ void show_submodule_summary(FILE *f, const char *path,
static const char *format = " %m %s";
int fast_forward = 0, fast_backward = 0;
- if (add_submodule_odb(path))
+ if (is_null_sha1(two))
+ message = "(submodule deleted)";
+ else if (add_submodule_odb(path))
message = "(not checked out)";
else if (is_null_sha1(one))
message = "(new submodule)";
- else if (is_null_sha1(two))
- message = "(submodule deleted)";
else if (!(left = lookup_commit_reference(one)) ||
!(right = lookup_commit_reference(two)))
message = "(commits not present)";
--
1.6.5.rc2.210.gac56a4.dirty
^ permalink raw reply related
* Re: [PATCH] Reserve a slot for argv[0] in default_arg.
From: Jeff King @ 2009-10-05 18:45 UTC (permalink / raw)
To: Petter Urkedal; +Cc: Junio C Hamano, git, Stephen Boyd
In-Reply-To: <20091005063649.GA25040@eideticdew.org>
On Mon, Oct 05, 2009 at 08:36:49AM +0200, Petter Urkedal wrote:
> On 2009-10-04, Junio C Hamano wrote:
> > It is a command specific aliasing mechanism; not even I use the feature
> > these days, since "alias.*" is much easier to use. But there is no strong
> > need to remove it either; it is not too much hassle to keep it for people
> > who do use it. Perhaps deprecate it and remove it in the long run?
>
> I didn't know about alias.*. Excellent. I'll be using that.
Yeah, showbranch.default really seems pointless now. Especially
confusing is the fact that it doesn't do whitespace-splitting, so you
can't do:
git config showbranch.default "--topo-order branch1 branch2"
but instead have to set multiple config variables.
I think deprecation makes sense, but I am in no hurry to get rid of it.
I mainly just wouldn't want people to think it was a useful thing to
learn. :)
> The code is slightly nicer to, I think, but you can probably drop "+ 20"
> in the grow-case now.
I think it could actually just be switched to use ALLOC_GROW.
-Peff
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox