* Re: Remote hung up during `git fetch`
From: Shawn Pearce @ 2012-11-22 19:52 UTC (permalink / raw)
To: Yichao Yu; +Cc: git
In-Reply-To: <CAMvDr+Rv6Krmjto6nQL18GnEj-+qCFPYgp7jDQnLs-ybamM0FA@mail.gmail.com>
On Thu, Nov 22, 2012 at 11:44 AM, Yichao Yu <yyc1992@gmail.com> wrote:
>> US holiday today? The list traffic tends to be down during holidays.
> This silent?.... 0 email from the kernel mailing list for 10+ hours?..
> anyway.... nvm...
Check your spam filters? I am having no trouble getting email for the
Git list. Traffic is down, but there have been several messages within
the past 4 hours. E.g. this thread among them.
> packet: fetch> want 2d242fb3fc19fc9ba046accdd9210be8b9913f64
> multi_ack_detailed side-band-64k thin-pack ofs-delta
> packet: fetch> shallow 65546ab097b023886a60df4cbc931d4cc362b98e
> packet: fetch> shallow b80d60e1c3854460a1f01d4110da5ae98f30f9b2
> packet: fetch> 0000
I think this is the problem. Your client told the sever it has the
Linux kernel shallow cloned, but its talking to a repository that
hosts git.git. The remote server doesn't know these two SHA-1s
mentioned on the shallow line, as they are from the Linux kernel
repository, so the server just hung up on you.
Basically this is an unsupported use case. A shallow repository can
only fetch from the place it cloned from. Anything else working is
pure luck. It _may_ be able to fetch from a clone of that same
repository at another server, if the clone has at least all of the
commits the client already has. If the remote clone is missing commits
(as in this case where it has none!) then it doesn't work.
^ permalink raw reply
* Re: [PATCH v5 15/15] fast-export: don't handle uninteresting refs
From: Felipe Contreras @ 2012-11-22 0:28 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Jonathan Nieder, git, Johannes Schindelin,
Max Horn, Sverre Rabbelier, Brandon Casey, Brandon Casey,
Ilari Liusvaara, Pete Wyckoff, Ben Walton, Matthieu Moy,
Julian Phillips
In-Reply-To: <20121121194810.GE16280@sigill.intra.peff.net>
On Wed, Nov 21, 2012 at 8:48 PM, Jeff King <peff@peff.net> wrote:
> On Tue, Nov 20, 2012 at 09:08:36PM -0800, Junio C Hamano wrote:
>
>> With such a one-sided discussion, I've been having a hard time
>> convincing myself if Felipe's effort is making the interface better,
>> or just breaking it even more for existing remote helpers, only to
>> fit his world model better.
>
> Felipe responded in more detail, but I will just add the consensus we
> came to earlier in the discussion: the series does make things better
> for users of fast-export that use marks, but does not make things any
> better for users of negative refs on the command line. However, I do not
> think that it makes things worse for them, either (neither by changing
> the behavior negatively, nor by making the code harder for a more
> complete fix later).
Patch 14 changes the behavior depending on the marks, patch 15 doesn't.
This patch is mostly orthogonal to marks.
Before without marks:
% git branch unintresting master
% git fast-export master ^uninteresting
reset refs/heads/uninteresting
from :0
Before with marks:
% git fast-export --import-marks=marks master ^uninteresting
reset refs/heads/uninteresting
from :100
See? In both cases git is doing something the user doesn't want, nor
specified. After my patch nothing gets updated, because nothing was
specified to be updated.
I'm not going to bother explaining why other people objected to this
patch (again), which is indeed related to marks, they should do it for
themselves. Let me reaffirm that no valid reason has put forward to
object to this patch.
> So while fixing everybody might be nice
I would like to understand that that even means. What behavior is
currently broken? And for who? And how is this patch related to that?
> [1] There are other possible use cases for fast-export which might
> benefit from negative refs working more sanely, but since they are
> in the minority and are not being made worse, I think the partial
> fix is OK.
Which ones? I don't think this is a partial fix.
Nobody has put forward such a use-case.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* [PATCH] Completion must sort before using uniq
From: Marc Khouzam @ 2012-11-22 4:16 UTC (permalink / raw)
To: git; +Cc: SZEDER Gábor, Felipe Contreras
In-Reply-To: <1353557598-4820-1-git-send-email-marc.khouzam@gmail.com>
The uniq program only works with sorted input. The man page states
"uniq prints the unique lines in a sorted file".
When __git_refs use the guess heuristic employed by checkout for
tracking branches it wants to consider remote branches but only if
the branch name is unique. To do that, it calls 'uniq -u'. However
the input given to 'uniq -u' is not sorted.
For example if all available branches are:
master
remotes/GitHub/maint
remotes/GitHub/master
remotes/origin/maint
remotes/origin/master
When performing completion on 'git checkout ma' the choices given are
maint
master
but when performing completion on 'git checkout mai', no choices
appear, which is obviously contradictory.
The reason is that, when dealing with 'git checkout ma',
"__git_refs '' 1" will find the following list:
master
maint
master
maint
master
which, when passed to 'uniq -u' will remain the same.
But when dealing with 'git checkout mai', the list will be:
maint
maint
which happens to be sorted and will be emptied by 'uniq -u'.
The solution is to first call 'sort' and then 'uniq -u'.
Signed-off-by: Marc Khouzam <marc.khouzam@gmail.com>
---
I ran into this by fluke when testing the tcsh completion.
Thanks for considering the fix.
Marc
contrib/completion/git-completion.bash | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index bc0657a..85ae419 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -321,7 +321,7 @@ __git_refs ()
if [[ "$ref" == "$cur"* ]]; then
echo "$ref"
fi
- done | uniq -u
+ done | sort | uniq -u
fi
return
fi
--
1.8.0.1.g9fe2839
^ permalink raw reply related
* Re: Remote hung up during `git fetch`
From: Yichao Yu @ 2012-11-22 19:44 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <CAJo=hJveYb09uhZWsKWKYor5Jcuz+wZ40F3wnsR3Hy8bcxeb6g@mail.gmail.com>
On Thu, Nov 22, 2012 at 2:01 PM, Shawn Pearce <spearce@spearce.org> wrote:
> On Thu, Nov 22, 2012 at 10:39 AM, Yichao Yu <yyc1992@gmail.com> wrote:
>> I sent this email yesterday to the git mailing list but I cannot find
>> it in any archive so I decide to send it again.
>
> If it was HTML formatted it would have been silently dropped by the list.
Well, I simply forward the original email and both of them are plain
text I believe....
>
>> Does anyone know what has happened to the mailing list? I haven't
>> receive any email from several kernel related busy mailing lists for
>> several hours....
>
> US holiday today? The list traffic tends to be down during holidays.
This silent?.... 0 email from the kernel mailing list for 10+ hours?..
anyway.... nvm...
>
>> I want to build packages for snap shoot of different branches from
>> different remote git repositories in the same local directory (so that
>> I don't need to recompile everything everytime.) and I am using a
>> combination of `git clone/checkout/reset/fetch` to do that. However,
>> during git-fetch, the remote sometimes stop responding or simply reset
>> the connection. This happens occasionally at least for both ssh and
>> git protocol (not sure about http/https) on github, bitbucket and also
>> kernel.org so I think it is probably not due to a weird behavior of a
>> certain host. Does anyone know the reason or is there anything I have
>> done wrong? And is there a better way to set the local tree to a
>> certain branch at a certain url? THX
>
> If the remote server is really busy it might be OOM'ing the server
Well, clone succeeded but fetch didn't?...
> process which would disconnect the client. Or maybe its your ISP
> sending a rogue RST packet to kill the connection because they don't
> like traffic that leaves their network and costs them money on a
> peering agreement. Or... ?
Well, yes I have only tested here but I don't really think MIT is
doing that... No?
>
>> #!/bin/bash
>>
>> repo_name=git
>> # remote1='git://github.com/torvalds/linux.git'
>> remote1='git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git'
>> branch1='master'
>> # remote2='git://github.com/git/git.git'
>> remote2='git://git.kernel.org/pub/scm/git/git.git'
>> branch2='next'
>>
>> git clone --depth 1 --single-branch --branch "$branch1" "$remote1" "$repo_name"
>> cd "$repo_name"
>> git fetch -vvv "$remote2" # "$branch2:$branch2"
>>
>> -----------------------------------------------
>>
>> Cloning into 'git'...
>> remote: Counting objects: 43215, done.
>> remote: Compressing objects: 100% (41422/41422), done.
>> remote: Total 43215 (delta 3079), reused 22032 (delta 1247)
>> Receiving objects: 100% (43215/43215), 119.06 MiB | 1.60 MiB/s, done.
>> Resolving deltas: 100% (3079/3079), done.
>> Checking out files: 100% (40905/40905), done.
>> fatal: destination path 'git' already exists and is not an empty directory.
>
> Why does this error come up? It looks like git already exists locally.
> Git should have aborted much earlier in clone when the directory
> exists.
Ahh, sorry. I killed the previous script to use LANG=C but forgot to
remove the directory which is normally deleted automatically by the
last few lines of my script that I didn't paste here (cd and rm...).
So here is the right output.
---------------------------------------
Cloning into 'git'...
remote: Counting objects: 43215, done.
remote: Compressing objects: 100% (41071/41071), done.
remote: Total 43215 (delta 3699), reused 13345 (delta 1598)
Receiving objects: 100% (43215/43215), 116.91 MiB | 4.51 MiB/s, done.
Resolving deltas: 100% (3699/3699), done.
Checking out files: 100% (40905/40905), done.
Server supports multi_ack_detailed
Server supports side-band-64k
Server supports ofs-delta
want 2d242fb3fc19fc9ba046accdd9210be8b9913f64 (HEAD)
have ef6c5be658f6a70c1256fbd18e18ee0dc24c3386
have db9d8c60266a5010e905829e10cd722519e14777
done
fatal: read error: Connection reset by peer
----------------------------------------------------
>
>> Server supports multi_ack_detailed
>> Server supports side-band-64k
>> Server supports ofs-delta
>> want 2d242fb3fc19fc9ba046accdd9210be8b9913f64 (HEAD)
>> have ef6c5be658f6a70c1256fbd18e18ee0dc24c3386
>> have db9d8c60266a5010e905829e10cd722519e14777
>> done
>> fatal: The remote end hung up unexpectedly
>
> This looks like its from the fetch command. Since the server doesn't
yes, plz simply ignore the previous one....
> report any errors to the client, its hard to say why the server just
> gave up right there. I wonder if this is related to the fact that you
> did a shallow clone initially. The shallow clone may have confused the
> server when fetch ran because it only sent 2 have lines and gave up.
Probably (related to shallow clone...) but hopefully this is not sth I
shouldn't do?
And a shallow clone is really what I want in my case. I really don't
need the full history to compile...
>
> Try exporting GIT_TRACE_PACKET=1 and seeing if you can get more
> detailed information from the protocol on the client side.
So here it is, I have removed lots of tags fetching (hopefully they
are irrelevant). Is there anything that looks strange (Looks like it's
actually .... done???)? Any more information needed?
----------------------------------------------
Cloning into 'git'...
remote: Counting objects: 43385, done.
remote: Compressing objects: 100% (41117/41117), done.
Receiving objects: 100% (43385/43385), 117.05 MiB | 4.73 MiB/s, done.
remote: Total 43385 (delta 3862), reused 13596 (delta 1722)
Resolving deltas: 100% (3862/3862), done.
Checking out files: 100% (40905/40905), done.
packet: fetch> git-upload-pack
/pub/scm/git/git.git\0host=git.kernel.org\0
packet: fetch< 2d242fb3fc19fc9ba046accdd9210be8b9913f64
HEAD\0multi_ack thin-pack side-band side-band-64k ofs-delta shallow
no-progress include-tag multi_ack_detailed
packet: fetch< 1c03999bef32edabd3db6479279b3ef90cc635ca refs/heads/maint
packet: fetch< 2d242fb3fc19fc9ba046accdd9210be8b9913f64 refs/heads/master
packet: fetch< ce6fbe5b9dc5e1e8ce1499bd8f7fb982e0c68289 refs/heads/next
packet: fetch< 7b4a70c62f3a83fbd8b44bf712141754a5f64205 refs/heads/pu
packet: fetch< 2c806864e99fc1252cea652ab0fc837067e726ba refs/heads/todo
packet: fetch< d5aef6e4d58cfe1549adef5b436f3ace984e8c86
refs/tags/gitgui-0.10.0
packet: fetch< 3d654be48f65545c4d3e35f5d3bbed5489820930
refs/tags/gitgui-0.10.0^{}
packet: fetch< 33682a5e98adfd8ba4ce0e21363c443bd273eb77
refs/tags/gitgui-0.10.1
packet: fetch< 729ffa50f75a025935623bfc58d0932c65f7de2f
refs/tags/gitgui-0.10.1^{}
... tags... and tags... and tags.....
packet: fetch< c15295d7477ccec489953299bd03a8e62f86e611
refs/tags/v1.8.0-rc2
packet: fetch< cd46259ebf2e624bcee2aaae05c36663d414e1a2
refs/tags/v1.8.0-rc2^{}
packet: fetch< 22ed067acc84eac8a0a72d20478a18aee4e25571
refs/tags/v1.8.0-rc3
packet: fetch< 87a5461fa7b30f7b7baf27204f10219d61500fbf
refs/tags/v1.8.0-rc3^{}
packet: fetch< 0000
Server supports multi_ack_detailed
Server supports side-band-64k
Server supports ofs-delta
want 2d242fb3fc19fc9ba046accdd9210be8b9913f64 (HEAD)
packet: fetch> want 2d242fb3fc19fc9ba046accdd9210be8b9913f64
multi_ack_detailed side-band-64k thin-pack ofs-delta
packet: fetch> shallow 65546ab097b023886a60df4cbc931d4cc362b98e
packet: fetch> shallow b80d60e1c3854460a1f01d4110da5ae98f30f9b2
packet: fetch> 0000
packet: fetch> have 5a903166dd31a42e39283b075cc6b9a9c079d1af
have 5a903166dd31a42e39283b075cc6b9a9c079d1af
packet: fetch> have b80d60e1c3854460a1f01d4110da5ae98f30f9b2
have b80d60e1c3854460a1f01d4110da5ae98f30f9b2
packet: fetch> have 65546ab097b023886a60df4cbc931d4cc362b98e
have 65546ab097b023886a60df4cbc931d4cc362b98e
packet: fetch> done
done
fatal: read error: Connection reset by peer
----------------------------------------------------------
>
> FYI, https://kernel.googlesource.com/ mirrors git://git.kernel.org/ so
> you can also try pulling from that server (e.g.
> https://kernel.googlesource.com/pub/scm/git/git.git).
THX. I have no problem cloning/pulling either the git or the kernel
tree from anywhere. It only happens when I want to do this kind of
fetching. I think git.kernel.org should be the best place to
demonstrate this kind of error since you may know exactly what is
running on the server. (And you probably don't want to try reproducing
sth on my private ssh git server?.) =P
^ permalink raw reply
* Re: git-fetch does not work from .git subdirectory
From: Patrik Gornicz @ 2012-11-22 0:55 UTC (permalink / raw)
To: Timur Tabi; +Cc: git
In-Reply-To: <50AC0316.7090002@freescale.com>
Just a hunch but your remote's location uses a relative path
'../linux-2.6.git', perhaps git is messing up what the path is relative
to.
I assume this repo is beside the linux.cq-test repo? ie. perhaps
they're located at /home/user/git/linux.cq-test and
/home/user/git/linux-2.6.git.
Then, for example, from linux.cq-test it looks for
/home/user/git/linux-2.6.git but from linux.cq-test/.git it looks for
/home/user/git/linux.cq-test/linux-2.6.git, which is wrong.
Note sure what the fix will be though as it'll likely break existing
repositories that use relative paths either way. Can you try an
absolute path to see if that fixes thing?
Patrik
On Tue Nov 20 17:24:22 2012, Timur Tabi wrote:
> I was under the impression that git commands which affect repository (as
> opposed to the local file system) work from any subdirectory inside the
> repository. For example:
>
> [b04825@efes linux.cq-test]$ git log -1
> commit f35d179fde24be5e1675b1df9f7a49b8d95561b2
> Author: Timur Tabi <timur@freescale.com>
> Date: Wed Oct 31 15:56:20 2012 +0200
> ...
> [b04825@efes linux.cq-test]$ cd .git
> [b04825@efes .git]$ git log -1
> commit f35d179fde24be5e1675b1df9f7a49b8d95561b2
> Author: Timur Tabi <timur@freescale.com>
> Date: Wed Oct 31 15:56:20 2012 +0200
> ...
>
> It appears, however, that git-fetch does not work this way:
>
> [b04825@efes linux.cq-test]$ git fetch upstream master
> From ../linux-2.6
> * branch master -> FETCH_HEAD
> [b04825@efes linux.cq-test]$ cd .git
> [b04825@efes .git]$ git fetch upstream master
> fatal: '../linux-2.6.git' does not appear to be a git repository
> fatal: The remote end hung up unexpectedly
>
> This makes it complicated because git hooks run from the .git directory on
> normal repositories, but they run from the top-level directory on bare
> repositories. Apparently, you need to be in the top-level directory for
> git-fetch to run in any kind of repository.
>
^ permalink raw reply
* Re: [PATCH v5 15/15] fast-export: don't handle uninteresting refs
From: Felipe Contreras @ 2012-11-22 0:38 UTC (permalink / raw)
To: Max Horn
Cc: Junio C Hamano, Jonathan Nieder, git, Johannes Schindelin,
Jeff King, Sverre Rabbelier, Brandon Casey, Brandon Casey,
Ilari Liusvaara, Pete Wyckoff, Ben Walton, Matthieu Moy,
Julian Phillips
In-Reply-To: <0F47AA24-F5B6-4197-8D74-6DD32E253856@quendi.de>
On Wed, Nov 21, 2012 at 11:30 PM, Max Horn <max@quendi.de> wrote:
> 2) Some are interfaces to foreign systems (bzr, hg, mediawiki, ...). They cannot use sha1s and must use marks (at least that is how I understand felipe's explanation). These tools use import combined with either export, or push. Examples:
>
> - git-remote-mediawiki: import, push, refspec
> (its capabilities command also prints "list", but that seems to be a bug?)
I don't think remote mediawiki uses marks. They are strictly not
needed by 'import' because the remote helper has full control over
this operation. For example, in my remote helpers, I store the
previous tip of the branches, so when git ask for 'import
refs/heads/master', I only import the new commits. I named this file
'marks' anyway, but they are not marks for fast-import.
> - git-remote-hg: import, export, refspec, import-marks, export-marks
> (both the msysgit one and felipe's
> - git-remote-bzr: import, push
> (the one from https://github.com/lelutin/git-remote-bzr)
> - git-remote-bzr (felipe's): import, export, refspec, *import-marks, *export-marks
> (but why the * ?)
AFAIK both of my remote helpers have * in them, they are to denote
they are required.
> Does that sound about right? If so, can somebody give me a hint when a type 2 helper would use "export" and when "push"?
I don't know when would be appropriate to use push, there's another
git-remote-bzr that uses the bzr-git infrastructure, and uses push.
I picked export/import because I think they are the easiest to
implement to get all the features, and should be efficient.
> And while I am at it: git-remote-helpers.txt does not mention the "export", "import-marks" and "export-marks" capabilities. Could somebody who knows what they do look into fixing that? Overall, that doc helped me a bit, but it is more a reference to somebody who already understands in detail how remote helpers work, and who just wants to look up some specific detail :-(. Some hints on when to implement which capabilities might be useful (similar to the "Tips and Tricks" section in git-fast-import.txt).
I've had problems finding out the right information, but I hope the
git-remote-testgit I wrote in bash in less than 90 lines of code
should give a pretty good idea of how the whole thing works.
> As it is, felipe's recent explanation on why he thinks marks are essential for remote-helpers (I assume he was only referring to type 2 helpers, though) was one of the most enlightening texts I read on the whole subject so far (then again, I am fairly new to this list, so I may have missed lots of past goodness). Anyway, it would be nice if this could be augmented by "somebody from the other camp" ;).
Wouldn't that be nice?
Cheers.
--
Felipe Contreras
^ permalink raw reply
* [PATCH v2 2/4] format-patch: stricter S-o-b detection
From: Nguyễn Thái Ngọc Duy @ 2012-11-22 16:38 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Nguyễn Thái Ngọc Duy
In-Reply-To: <1353602289-9418-1-git-send-email-pclouds@gmail.com>
S-o-b in the middle of a sentence, at the beginning of the sentence
but it is just because of text wrapping, or a full paragraph of valid
S-o-b in the middle of the message. All these are not S-o-b, but
detected as is. Fix them.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
log-tree.c | 37 +++++++++++++++++++++++++++++++--
t/t4014-format-patch.sh | 54 +++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 89 insertions(+), 2 deletions(-)
diff --git a/log-tree.c b/log-tree.c
index c894930..aff7c0a 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -260,14 +260,47 @@ static void append_signoff(struct strbuf *sb, const char *signoff)
int has_signoff = 0;
char *cp;
- cp = sb->buf;
+ /*
+ * Only search in the last paragrah, don't be fooled by a
+ * paragraph full of valid S-o-b in the middle.
+ */
+ cp = sb->buf + sb->len - 1;
+ while (cp > sb->buf) {
+ if (cp[0] == '\n' && cp[1] == '\n') {
+ cp += 2;
+ break;
+ }
+ cp--;
+ }
/* First see if we already have the sign-off by the signer */
while ((cp = strstr(cp, signed_off_by))) {
+ const char *s = cp;
+ cp += strlen(signed_off_by);
+
+ if (!has_signoff && s > sb->buf) {
+ /*
+ * S-o-b in the middle of a sentence is not
+ * really S-o-b
+ */
+ if (s[-1] != '\n')
+ continue;
+
+ if (s - 1 > sb->buf && s[-2] == '\n')
+ ; /* the first S-o-b */
+ else if (!detect_any_signoff(sb->buf, s - sb->buf))
+ /*
+ * The previous line looks like an
+ * S-o-b. There's still no guarantee
+ * that it's an actual S-o-b. For that
+ * we need to look back until we find
+ * a blank line, which is too costly.
+ */
+ continue;
+ }
has_signoff = 1;
- cp += strlen(signed_off_by);
if (cp + signoff_len >= sb->buf + sb->len)
break;
if (strncmp(cp, signoff, signoff_len))
diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh
index c8d5d29..d0b3c85 100755
--- a/t/t4014-format-patch.sh
+++ b/t/t4014-format-patch.sh
@@ -989,6 +989,60 @@ EOF
test_cmp expected actual
'
+test_expect_success 'signoff: not really a signoff' '
+ append_signoff <<\EOF >actual &&
+subject
+
+I want to mention about Signed-off-by: here.
+EOF
+ cat >expected <<\EOF &&
+4:Subject: [PATCH] subject
+8:
+9:I want to mention about Signed-off-by: here.
+10:
+11:Signed-off-by: C O Mitter <committer@example.com>
+EOF
+ test_cmp expected actual
+'
+
+test_expect_success 'signoff: not really a signoff (2)' '
+ append_signoff <<\EOF >actual &&
+subject
+
+My unfortunate
+Signed-off-by: example happens to be wrapped here.
+EOF
+ cat >expected <<\EOF &&
+4:Subject: [PATCH] subject
+8:
+10:Signed-off-by: example happens to be wrapped here.
+11:
+12:Signed-off-by: C O Mitter <committer@example.com>
+EOF
+ test_cmp expected actual
+'
+
+test_expect_success 'signoff: valid S-o-b paragraph in the middle' '
+ append_signoff <<\EOF >actual &&
+subject
+
+Signed-off-by: my@house
+Signed-off-by: your@house
+
+A lot of houses.
+EOF
+ cat >expected <<\EOF &&
+4:Subject: [PATCH] subject
+8:
+9:Signed-off-by: my@house
+10:Signed-off-by: your@house
+11:
+13:
+14:Signed-off-by: C O Mitter <committer@example.com>
+EOF
+ test_cmp expected actual
+'
+
test_expect_success 'signoff: the same signoff at the end' '
append_signoff <<\EOF >actual &&
subject
--
1.8.0.4.g5d0415a
^ permalink raw reply related
* Re: Duplicate test numbers in pu.
From: Adam Spiers @ 2012-11-22 10:35 UTC (permalink / raw)
To: Ramsay Jones
Cc: Junio C Hamano, Jeff King, GIT Mailing-list, felipe.contreras
In-Reply-To: <50AD27FA.3010006@ramsay1.demon.co.uk>
On Wed, Nov 21, 2012 at 7:14 PM, Ramsay Jones
<ramsay@ramsay1.demon.co.uk> wrote:
> I noticed that the pu branch has two tests with number t0007, viz:
>
> $ cd t
> $ make test-lint-duplicates
> duplicate test numbers: t0007
> make: *** [test-lint-duplicates] Error 1
> $
>
> In particular, t/t0007-git-var.sh is added by branch 'jk/send-email-\
> sender-prompt', while t/t0007-ignores.sh is added by branch 'as/check-ignore'.
Thanks; I can renumber t0007-ignores.sh in the next re-roll.
^ permalink raw reply
* [PATCH v2 0/4] nd/unify-appending-of-s-o-b
From: Nguyễn Thái Ngọc Duy @ 2012-11-22 16:38 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Nguyễn Thái Ngọc Duy
In-Reply-To: <CACsJy8BiJRK7N3_HZ2WXpMd1YkDSW00AxuYqiCWJgij+Kq6AiQ@mail.gmail.com>
This round cherry-pick and commit only skip S-o-b if the last one is
the same while format-patch skips it if the same one appears
anywhere in S-o-b list. I don't have strong opinion about which way is
more correct. Though if we decide to change format-patch behavior, the
series may become a bit different.
Nguyễn Thái Ngọc Duy (4):
t4014: more tests about appending s-o-b lines
format-patch: stricter S-o-b detection
format-patch: update append_signoff prototype
Unify appending signoff in format-patch, commit and sequencer
builtin/commit.c | 10 ++-
builtin/log.c | 13 +---
log-tree.c | 66 +++++++++++++---
log-tree.h | 4 +
revision.h | 2 +-
sequencer.c | 65 +---------------
sequencer.h | 4 -
t/t4014-format-patch.sh | 199 ++++++++++++++++++++++++++++++++++++++++++++++++
t/t7501-commit.sh | 2 +-
9 files changed, 272 insertions(+), 93 deletions(-)
--
1.8.0.4.g5d0415a
^ permalink raw reply
* [PATCH v2 1/4] t4014: more tests about appending s-o-b lines
From: Nguyễn Thái Ngọc Duy @ 2012-11-22 16:38 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Nguyễn Thái Ngọc Duy
In-Reply-To: <1353602289-9418-1-git-send-email-pclouds@gmail.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
t/t4014-format-patch.sh | 145 ++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 145 insertions(+)
diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh
index 959aa26..c8d5d29 100755
--- a/t/t4014-format-patch.sh
+++ b/t/t4014-format-patch.sh
@@ -891,4 +891,149 @@ test_expect_success 'format patch ignores color.ui' '
test_cmp expect actual
'
+append_signoff()
+{
+ C=`git commit-tree HEAD^^{tree} -p HEAD` &&
+ git format-patch --stdout --signoff ${C}^..${C} |
+ tee append_signoff.patch |
+ sed -n "1,/^---$/p" |
+ grep -n -E "^Subject|Sign|^$"
+}
+
+test_expect_success 'signoff: commit with no body' '
+ append_signoff </dev/null >actual &&
+ cat <<\EOF | sed "s/EOL$//" >expected &&
+4:Subject: [PATCH] EOL
+8:
+9:Signed-off-by: C O Mitter <committer@example.com>
+EOF
+ test_cmp expected actual
+'
+
+test_expect_success 'signoff: commit with only subject' '
+ echo subject | append_signoff >actual &&
+ cat >expected <<\EOF &&
+4:Subject: [PATCH] subject
+8:
+9:Signed-off-by: C O Mitter <committer@example.com>
+EOF
+ test_cmp expected actual
+'
+
+test_expect_success 'signoff: commit with only subject that does not end with NL' '
+ echo -n subject | append_signoff >actual &&
+ cat >expected <<\EOF &&
+4:Subject: [PATCH] subject
+8:
+9:Signed-off-by: C O Mitter <committer@example.com>
+EOF
+ test_cmp expected actual
+'
+
+test_expect_success 'signoff: no existing signoffs' '
+ append_signoff <<\EOF >actual &&
+subject
+
+body
+EOF
+ cat >expected <<\EOF &&
+4:Subject: [PATCH] subject
+8:
+10:
+11:Signed-off-by: C O Mitter <committer@example.com>
+EOF
+ test_cmp expected actual
+'
+
+test_expect_success 'signoff: no existing signoffs and no trailing NL' '
+ printf "subject\n\nbody" | append_signoff >actual &&
+ cat >expected <<\EOF &&
+4:Subject: [PATCH] subject
+8:
+10:
+11:Signed-off-by: C O Mitter <committer@example.com>
+EOF
+ test_cmp expected actual
+'
+
+test_expect_success 'signoff: some random signoff' '
+ append_signoff <<\EOF >actual &&
+subject
+
+body
+
+Signed-off-by: my@house
+EOF
+ cat >expected <<\EOF &&
+4:Subject: [PATCH] subject
+8:
+10:
+11:Signed-off-by: my@house
+12:Signed-off-by: C O Mitter <committer@example.com>
+EOF
+ test_cmp expected actual
+'
+
+test_expect_success 'signoff: some random signoff-alike' '
+ append_signoff <<\EOF >actual &&
+subject
+
+body
+Fooled-by-me: my@house
+EOF
+ cat >expected <<\EOF &&
+4:Subject: [PATCH] subject
+8:
+11:Signed-off-by: C O Mitter <committer@example.com>
+EOF
+ test_cmp expected actual
+'
+
+test_expect_success 'signoff: the same signoff at the end' '
+ append_signoff <<\EOF >actual &&
+subject
+
+body
+
+Signed-off-by: C O Mitter <committer@example.com>
+EOF
+ cat >expected <<\EOF &&
+4:Subject: [PATCH] subject
+8:
+10:
+11:Signed-off-by: C O Mitter <committer@example.com>
+EOF
+ test_cmp expected actual
+'
+
+test_expect_success 'signoff: the same signoff at the end, no trailing NL' '
+ printf "subject\n\nSigned-off-by: C O Mitter <committer@example.com>" |
+ append_signoff >actual &&
+ cat >expected <<\EOF &&
+4:Subject: [PATCH] subject
+8:
+9:Signed-off-by: C O Mitter <committer@example.com>
+EOF
+ test_cmp expected actual
+'
+
+test_expect_success 'signoff: the same signoff NOT at the end' '
+ append_signoff <<\EOF >actual &&
+subject
+
+body
+
+Signed-off-by: C O Mitter <committer@example.com>
+Signed-off-by: my@house
+EOF
+ cat >expected <<\EOF &&
+4:Subject: [PATCH] subject
+8:
+10:
+11:Signed-off-by: C O Mitter <committer@example.com>
+12:Signed-off-by: my@house
+EOF
+ test_cmp expected actual
+'
+
test_done
--
1.8.0.4.g5d0415a
^ permalink raw reply related
* Re: Requirements for integrating a new git subcommand
From: Shawn Pearce @ 2012-11-22 19:17 UTC (permalink / raw)
To: Eric Raymond; +Cc: git
In-Reply-To: <20121122053012.GA17265@thyrsus.com>
On Wed, Nov 21, 2012 at 9:30 PM, Eric S. Raymond <esr@thyrsus.com> wrote:
> I have completed work on git-weave (the tool I had called 'gitpacker' in some
> previous postings). I want to submit a patch that integrates it into git;
> in hopes of smoothing the process I have some technical and procedural
> questions.
...
> Now *my* questions:
>
> 1. I have a round-trip test for the tool that I can very easily adapt
> to speak TAP. To function, the test will require a small linear
> history to operate on in the form of an import-stream file (so the
> result of round-tripping through a weave-unravel can be diffed against
> the original). Does the distribution include any test repos? If
> so, where can I find them?
No. We create the repositories from scratch using a series of
commands. If you look at the test library the environment is set in a
predictable way so the author, committer and timestamps are all set to
a single well known value, allowing Git to create a commit that is
reproducible on all platforms. A test_tick function is used in the
scripts to move the clock, allowing different times to be used. For an
example see t7502-commit.sh, or really any script in that directory.
> 2. I understand that a "git foo" command is typically implemented
> as "git-foo" binary or script in /usr/lib/git-core. What I don't
> know is what the other interfacing requirements are. Are they
> documented anywhere? In particular...
Nope. "git foo" will invoke "git-foo" with GIT_DIR set in the
environment, so you know what repository to act against, and so does
any git command you recursively invoke. Other than that there really
aren't any interface requirements. Your program is executed with
whatever arguments the caller gave you. Its pretty simple UNIX stuff.
:-)
> 3. Is there any registration protocol other than simply installing
> the extension in the subcommand library?
Nope. Running "git whatever-this-is-i-have-no-idea" will try to
execute "git-whatever-this-is-i-have-no-idea" via $PATH, after adding
/usr/lib/git-core to the front of $PATH. Its pretty simple actually.
If your standard C library can find the program in $PATH its run, if
it can't find it, it dies.
> 4. How does "git help" work? That is, how is a subcommand expected
> to know when it is being called to export its help text?
IIRC "git help foo" runs "man git-foo".
> 5. I don't see any extensions written in Python. Are there any special
> requirements or exclusions for Python scripts?
Nope, it just has to be executable. We don't have any current Python
code. IIRC the last Python code was the implementation of
git-merge-recursive, which was ported to C many years ago. We avoid
Python because it is not on every platform where Git is installed. Yes
Python is very portable and can be installed in many places, but we
prefer not to make it a requirement.
^ permalink raw reply
* [PATCH v2 4/4] Unify appending signoff in format-patch, commit and sequencer
From: Nguyễn Thái Ngọc Duy @ 2012-11-22 16:38 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Nguyễn Thái Ngọc Duy
In-Reply-To: <1353602289-9418-1-git-send-email-pclouds@gmail.com>
There are two implementations of append_signoff in log-tree.c and
sequencer.c, which do more or less the same thing. This patch removes
the sequencer.c's in favor of the format-patch's.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
builtin/commit.c | 10 ++++++++-
log-tree.c | 14 ++++++++----
log-tree.h | 4 ++++
sequencer.c | 65 ++-----------------------------------------------------
sequencer.h | 4 ----
t/t7501-commit.sh | 2 +-
6 files changed, 26 insertions(+), 73 deletions(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index a17a5df..6d323d9 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -698,7 +698,15 @@ static int prepare_to_commit(const char *index_file, const char *prefix,
previous = eol;
}
- append_signoff(&sb, ignore_footer);
+ if (ignore_footer) {
+ struct strbuf footer = STRBUF_INIT;
+ strbuf_addstr(&footer, sb.buf + sb.len - ignore_footer);
+ strbuf_setlen(&sb, sb.len - ignore_footer);
+ append_signoff(&sb, SOB_IGNORE_SAME);
+ strbuf_addstr(&sb, footer.buf);
+ strbuf_release(&footer);
+ } else
+ append_signoff(&sb, SOB_IGNORE_SAME);
}
if (fwrite(sb.buf, 1, sb.len, s->fp) < sb.len)
diff --git a/log-tree.c b/log-tree.c
index 7e50545..e8d31d9 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -12,6 +12,8 @@
struct decoration name_decoration = { "object names" };
+const char sign_off_header[] = "Signed-off-by: ";
+
enum decoration_type {
DECORATION_NONE = 0,
DECORATION_REF_LOCAL,
@@ -207,7 +209,7 @@ void show_decorations(struct rev_info *opt, struct commit *commit)
}
/*
- * Search for "^[-A-Za-z]+: [^@]+@" pattern. It usually matches
+ * Search for "^[-A-Za-z0-9]+: [^@]+@" pattern. It usually matches
* Signed-off-by: and Acked-by: lines.
*/
static int detect_any_signoff(char *letter, int size)
@@ -243,6 +245,7 @@ static int detect_any_signoff(char *letter, int size)
}
if (('A' <= ch && ch <= 'Z') ||
('a' <= ch && ch <= 'z') ||
+ ('0' <= ch && ch <= '9') ||
ch == '-') {
seen_head = 1;
continue;
@@ -253,11 +256,10 @@ static int detect_any_signoff(char *letter, int size)
return seen_head && seen_name;
}
-static void append_signoff(struct strbuf *sb, int flags)
+void append_signoff(struct strbuf *sb, int flags)
{
char* signoff = xstrdup(fmt_name(getenv("GIT_COMMITTER_NAME"),
getenv("GIT_COMMITTER_EMAIL")));
- static const char sign_off_header[] = "Signed-off-by: ";
size_t signoff_len = strlen(signoff);
int has_signoff = 0;
char *cp;
@@ -310,7 +312,11 @@ static void append_signoff(struct strbuf *sb, int flags)
if (!isspace(cp[signoff_len]))
continue;
/* we already have him */
- return;
+ if (flags & SOB_IGNORE_SAME) {
+ if (cp[signoff_len + 1] == '\0')
+ return;
+ } else
+ return;
}
if (!has_signoff)
diff --git a/log-tree.h b/log-tree.h
index f5ac238..739f729 100644
--- a/log-tree.h
+++ b/log-tree.h
@@ -24,4 +24,8 @@ void load_ref_decorations(int flags);
void get_patch_filename(struct commit *commit, const char *subject, int nr,
const char *suffix, struct strbuf *buf);
+#define SOB_IGNORE_SAME 1
+extern const char sign_off_header[];
+void append_signoff(struct strbuf *msgbuf, int flags);
+
#endif
diff --git a/sequencer.c b/sequencer.c
index e3723d2..bc02a66 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -14,11 +14,10 @@
#include "merge-recursive.h"
#include "refs.h"
#include "argv-array.h"
+#include "log-tree.h"
#define GIT_REFLOG_ACTION "GIT_REFLOG_ACTION"
-const char sign_off_header[] = "Signed-off-by: ";
-
static void remove_sequencer_state(void)
{
struct strbuf seq_dir = STRBUF_INIT;
@@ -236,7 +235,7 @@ static int do_recursive_merge(struct commit *base, struct commit *next,
rollback_lock_file(&index_lock);
if (opts->signoff)
- append_signoff(msgbuf, 0);
+ append_signoff(msgbuf, SOB_IGNORE_SAME);
if (!clean) {
int i;
@@ -1016,63 +1015,3 @@ int sequencer_pick_revisions(struct replay_opts *opts)
save_opts(opts);
return pick_commits(todo_list, opts);
}
-
-static int ends_rfc2822_footer(struct strbuf *sb, int ignore_footer)
-{
- int ch;
- int hit = 0;
- int i, j, k;
- int len = sb->len - ignore_footer;
- int first = 1;
- const char *buf = sb->buf;
-
- for (i = len - 1; i > 0; i--) {
- if (hit && buf[i] == '\n')
- break;
- hit = (buf[i] == '\n');
- }
-
- while (i < len - 1 && buf[i] == '\n')
- i++;
-
- for (; i < len; i = k) {
- for (k = i; k < len && buf[k] != '\n'; k++)
- ; /* do nothing */
- k++;
-
- if ((buf[k] == ' ' || buf[k] == '\t') && !first)
- continue;
-
- first = 0;
-
- for (j = 0; i + j < len; j++) {
- ch = buf[i + j];
- if (ch == ':')
- break;
- if (isalnum(ch) ||
- (ch == '-'))
- continue;
- return 0;
- }
- }
- return 1;
-}
-
-void append_signoff(struct strbuf *msgbuf, int ignore_footer)
-{
- struct strbuf sob = STRBUF_INIT;
- int i;
-
- strbuf_addstr(&sob, sign_off_header);
- strbuf_addstr(&sob, fmt_name(getenv("GIT_COMMITTER_NAME"),
- getenv("GIT_COMMITTER_EMAIL")));
- strbuf_addch(&sob, '\n');
- for (i = msgbuf->len - 1 - ignore_footer; i > 0 && msgbuf->buf[i - 1] != '\n'; i--)
- ; /* do nothing */
- if (prefixcmp(msgbuf->buf + i, sob.buf)) {
- if (!i || !ends_rfc2822_footer(msgbuf, ignore_footer))
- strbuf_splice(msgbuf, msgbuf->len - ignore_footer, 0, "\n", 1);
- strbuf_splice(msgbuf, msgbuf->len - ignore_footer, 0, sob.buf, sob.len);
- }
- strbuf_release(&sob);
-}
diff --git a/sequencer.h b/sequencer.h
index 9d57d57..99eb7fa 100644
--- a/sequencer.h
+++ b/sequencer.h
@@ -46,8 +46,4 @@ struct replay_opts {
int sequencer_pick_revisions(struct replay_opts *opts);
-extern const char sign_off_header[];
-
-void append_signoff(struct strbuf *msgbuf, int ignore_footer);
-
#endif
diff --git a/t/t7501-commit.sh b/t/t7501-commit.sh
index 195e747..6dd4580 100755
--- a/t/t7501-commit.sh
+++ b/t/t7501-commit.sh
@@ -353,7 +353,7 @@ test_expect_success 'signoff gap' '
echo 3 >positive &&
git add positive &&
- alt="Alt-RFC-822-Header: Value" &&
+ alt="Alt-RFC-822-Header: Va@lue" &&
git commit -s -m "welcome
$alt" &&
--
1.8.0.4.g5d0415a
^ permalink raw reply related
* [PATCH] emacs: make 'git-status' work with separate git dirs
From: Enrico Scholz @ 2012-11-22 15:58 UTC (permalink / raw)
To: git, gitster; +Cc: Enrico Scholz
when trying 'M-x git-status' in a submodule created with recent (1.7.5+)
git, the command fails with
| ... is not a git working tree
This is caused by creating submodules with '--separate-git-dir' but
still checking for a working tree by testing for a '.git' directory.
The patch fixes this by relaxing the existing detection a little bit.
Signed-off-by: Enrico Scholz <enrico.scholz@sigma-chemnitz.de>
---
contrib/emacs/git.el | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
index 65c95d9..5ffc506 100644
--- a/contrib/emacs/git.el
+++ b/contrib/emacs/git.el
@@ -1671,7 +1671,7 @@ Commands:
"Entry point into git-status mode."
(interactive "DSelect directory: ")
(setq dir (git-get-top-dir dir))
- (if (file-directory-p (concat (file-name-as-directory dir) ".git"))
+ (if (file-exists-p (concat (file-name-as-directory dir) ".git"))
(let ((buffer (or (and git-reuse-status-buffer (git-find-status-buffer dir))
(create-file-buffer (expand-file-name "*git-status*" dir)))))
(switch-to-buffer buffer)
--
1.7.11.7
^ permalink raw reply related
* Re: [PATCH v4 2/4] diff: introduce diff.submodule configuration variable
From: Ramkumar Ramachandra @ 2012-11-22 9:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git List
In-Reply-To: <CALkWK0kZ0p4ptmAySXKspU2qJm9gm6Wg4uyBhRnXQ4qdSC34FA@mail.gmail.com>
Ramkumar Ramachandra wrote:
> Junio C Hamano wrote:
>> Ramkumar Ramachandra <artagnon@gmail.com> writes:
>>> +test_expect_success 'added submodule, set diff.submodule' "
>>
>> s/added/add/;
>
> I see that the topic is already in `next`. Do you want to fix it up there?
I was simply following the example set by the previous test in the
file: "added submodule". I can fix up these two after the topic
graduates to `master`, if you prefer that, instead of rewriting `next`
for a small change like this.
Ram
^ permalink raw reply
* Requirements for integrating a new git subcommand
From: Eric S. Raymond @ 2012-11-22 5:30 UTC (permalink / raw)
To: git
I have completed work on git-weave (the tool I had called 'gitpacker' in some
previous postings). I want to submit a patch that integrates it into git;
in hopes of smoothing the process I have some technical and procedural
questions.
First, however, let me present the git-weave documentation for design
review:
----------------------------------------------------------------------
git-weave(1)
============
NAME
----
git-weave - Weave a sequence of trees and log data into a repository
SYNOPSIS
--------
[verse]
'git-weave' [-v] [-m limit] [-q] indir outdir
DESCRIPTION
-----------
git-weave accepts an input directory containing a sequence of
subdirectories and a metadata file, and composes them into a
git repository created under the specified output directory
(which must not exist).
If the input directory is identifiably a git repository, the weave
operation is reversed; tree states from each commit are unraveled into
the output directory with a log holding commit metadata
(committer/author/comment information and parent headers representing
links of the repository DAG) and tags.
This tool is primarily intended for importing and working with project
histories that have been preserved only as linear sequences of release
snapshots. It may also be useful for surgery on linear repositories
While the weave operation can build a commit graph with any structure
desired, an important restriction of the inverse (unraveling)
operation is that it operates on *master branches only*. The unravel
operation discards non-master-branch content, emitting a warning
to standard error when it has to do so.
Commits from the repository's master branch are unraveled into
directories named for integers from 1 increasing, but their order of
composition when re-woven is actually set by the sequence of entries
in the metadata file. File trees may be inserted or removed without
hindering re-weaving provided the pointers in the log's parent fields
are fixed up properly.
METADATA FILE FORMAT
--------------------
The metadata file format will contain three kinds of stanzas: entries
for commits, entries for lightweight tags, and entries for annotated
tags.
A commit stanza has headers similar to those in a commit raw log:
commit, committer, author, and optionally parent headers. The header
contents are not hash IDs, but arbitrary text cookies either declared
by a previous commit stanza or referencing one. The following example
declares "8" to be a commit ID, and references a previous commit
identified as '7'. Note that commit IDs are not required to be
numeric strings, though the unravel operation generates them that way.
------------
commit 8
parent 7
author Eric S. Raymond <esr@thyrsus.com> 1325026869 +0000
committer Eric S. Raymond <esr@thyrsus.com> 1325026869 +0000
Initial revision
.
------------
The text body of a commit comment or tag comment entry is delimited
from the headers by an empty line; the text body must always end with
"." on a line by itself; and text lines beginning with "." will have
an additional "." prepended to them.
A commit stanza may also have a "directory" header. If present, this
sets the name of the subdirectory in which git-weave expects to
find the content tree for this commit. For example
------------
commit 24
directory intercal-0.17
parent 23
author Eric S. Raymond <esr@thyrsus.com> 1325026489 +0000
committer Eric S. Raymond <esr@thyrsus.com> 1325026489 +0000
The state of the INTERCAL project at release 0.17.
.
------------
A label stanza declares a lightweight tag. This example declares a
tag 'sample' pointing at the commit identified as 102.
------------
label sample
refers-to 102
------------
A tag stanza declares an annotated tag. This one declares a tag named
'annotated1' pointing at the commit declared as 99.
------------
tag annotated1
refers-to 99
tagger Eric S. Raymond <esr@thyrsus.com> Sat Nov 17 03:16:26 2012 -0500
This is an example annotated tag.
.
------------
When you are composing commit and tag stanzas by hand, you can count
on any of the date formats normally acceptable to git to be
recognized.
If, when weaving, any committer or author or tagger line, the date is omitted,
git-weave will supply as a default the latest modification time of
any file in the corresponding tree.
If a committer or author or tagger line is omitted entirely, the
user's name and email address as retrieved by ''git-config'' will
be supplied as defaults, and the date will default as above.
Thus, the following variation on one of the previous examples
is a valid stanza:
------------
commit 24
directory intercal-0.17
parent 23
The state of the INTERCAL project at release 0.17.
.
------------
OPTIONS
-------
-q::
Be quiet. Suppress the normal spinning-baton progress meter
with timing information.
-m::
Limit the number of commits or trees processed to a specified
integer maximum. '0' means process all of them.
-v::
Be verbose, enabling progress and command-execution messages
This option will probably be of interest only to developers;
consult the source code for details.
EXAMPLES
--------
* Weave a sequence of trees in the directory 'unraveled'
into a git repository in the directory 'repo'.
+
------------
$ rm -fr repo; git-weave unraveled repo
------------
+
The metadata is expected to be in 'unraveled/log'. This mode of
operation is triggered when there is no file 'unraveled/.git',
* Unravel a repository in the directory 'repo' into a sequence
of file trees and a metadata log in the directory 'unraveled'.
+
------------
$ rm -fr unraveled; git-weave repo unraveled
------------
+
This mode of operation is triggered when there is a 'repo/.git' file.
SEE ALSO
--------
linkgit:git-log[1]
linkgit:git-checkout[1]
linkgit:git-add[1]
linkgit:git-mktree[1]
linkgit:git-ls-tree[1]
linkgit:git-update-references[1]
GIT
---
Not yet part of the linkgit:git[1] suite
----------------------------------------------------------------------
Yes, there are scripts in contrib that do similar things. git-weave
is an improvement is several ways: (a) it is documented, (b) I am
shipping it with a functional test, (c) I am prepared to maintain it
and am quite unlikely to drop out of sight :-), (d) it does both
the import operation *and its inverse*, and (e) it is rather more
powerful, including the ability to decorate the import with
annotated tags.
Now *my* questions:
1. I have a round-trip test for the tool that I can very easily adapt
to speak TAP. To function, the test will require a small linear
history to operate on in the form of an import-stream file (so the
result of round-tripping through a weave-unravel can be diffed against
the original). Does the distribution include any test repos? If
so, where can I find them?
2. I understand that a "git foo" command is typically implemented
as "git-foo" binary or script in /usr/lib/git-core. What I don't
know is what the other interfacing requirements are. Are they
documented anywhere? In particular...
3. Is there any registration protocol other than simply installing
the extension in the subcommand library?
4. How does "git help" work? That is, how is a subcommand expected
to know when it is being called to export its help text?
5. I don't see any extensions written in Python. Are there any special
requirements or exclusions for Python scripts?
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* Re: [PATCH v5 08/15] remote-testgit: cleanup tests
From: Felipe Contreras @ 2012-11-22 0:55 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Johannes Schindelin, Max Horn, Jeff King, Sverre Rabbelier,
Brandon Casey, Brandon Casey, Jonathan Nieder, Ilari Liusvaara,
Pete Wyckoff, Ben Walton, Matthieu Moy, Julian Phillips
In-Reply-To: <7vzk2a22g8.fsf@alter.siamese.dyndns.org>
On Wed, Nov 21, 2012 at 7:28 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> We don't need a bare 'server' and an intermediary 'public'. The repos
>> can talk to each other directly; that's what we want to exercise.
>
> The previous patch to remove the test (the one that covered a case
> where a bug was fixed in an older git-remote-testpy and tried to
> catch the bug when it resurfaced) made sense even with its
> ultra-short justification "irrelevant".
>
> But I am not sure if this one is so cut-and-dried. The repos can
> talk to each other directly, but at the same time the tests were
> exercising interactions between bare and non-bare repositories,
> weren't they? Talking to each other may be one of the things we
> want to exercise, but that does not necessarily be the only thing.
>
> If it were explained like this (note that I am *guessing* what you
> meant to achieve by this patch, which may be wrong, in which case
> the log message needs further clarification):
>
> Going through an intermediary 'public' may have exercised
> interactions among combinations of bare and non-bare
> repositories a bit more, but that is not an issue specific
> to the remote-helper transfer that we want to be testing in
> this script. Simplify the tests to let two repositories
> talk directly with each other.
Right. I don't think bare vs. non-bare has anything to do with it; the
intermediary repository was there to have 3 types of repos interacting
with each other local testpy, remote testpy, local git. But this
doesn't exercise anything from transport helper.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* [PATCH] diff: Fixes shortstat number of files
From: Antoine Pelisse @ 2012-11-21 21:26 UTC (permalink / raw)
To: git; +Cc: Antoine Pelisse
There is a discrepancy between the last line of `git diff --stat`
and `git diff --shortstat` in case of a merge.
The unmerged files are actually counted twice, thus doubling the
value of "file changed".
In fact, while stat decrements number of files when seeing an unmerged
file, shortstat doesn't.
Signed-off-by: Antoine Pelisse <apelisse@gmail.com>
---
diff.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/diff.c b/diff.c
index e89a201..5c6bcbd 100644
--- a/diff.c
+++ b/diff.c
@@ -1704,9 +1704,8 @@ static void show_shortstats(struct diffstat_t *data, struct diff_options *option
int added = data->files[i]->added;
int deleted= data->files[i]->deleted;
- if (data->files[i]->is_unmerged)
- continue;
- if (!data->files[i]->is_renamed && (added + deleted == 0)) {
+ if (data->files[i]->is_unmerged ||
+ (!data->files[i]->is_renamed && (added + deleted == 0))) {
total_files--;
} else if (!data->files[i]->is_binary) { /* don't count bytes */
adds += added;
--
1.7.9.5
^ permalink raw reply related
* Re: Remote hung up during `git fetch`
From: Shawn Pearce @ 2012-11-22 19:01 UTC (permalink / raw)
To: Yichao Yu; +Cc: git
In-Reply-To: <CAMvDr+QuMpfdTdkOMOiYyEnHvQjia2cDCt3sx2rQwwLcJiCVmw@mail.gmail.com>
On Thu, Nov 22, 2012 at 10:39 AM, Yichao Yu <yyc1992@gmail.com> wrote:
> I sent this email yesterday to the git mailing list but I cannot find
> it in any archive so I decide to send it again.
If it was HTML formatted it would have been silently dropped by the list.
> Does anyone know what has happened to the mailing list? I haven't
> receive any email from several kernel related busy mailing lists for
> several hours....
US holiday today? The list traffic tends to be down during holidays.
> I want to build packages for snap shoot of different branches from
> different remote git repositories in the same local directory (so that
> I don't need to recompile everything everytime.) and I am using a
> combination of `git clone/checkout/reset/fetch` to do that. However,
> during git-fetch, the remote sometimes stop responding or simply reset
> the connection. This happens occasionally at least for both ssh and
> git protocol (not sure about http/https) on github, bitbucket and also
> kernel.org so I think it is probably not due to a weird behavior of a
> certain host. Does anyone know the reason or is there anything I have
> done wrong? And is there a better way to set the local tree to a
> certain branch at a certain url? THX
If the remote server is really busy it might be OOM'ing the server
process which would disconnect the client. Or maybe its your ISP
sending a rogue RST packet to kill the connection because they don't
like traffic that leaves their network and costs them money on a
peering agreement. Or... ?
> #!/bin/bash
>
> repo_name=git
> # remote1='git://github.com/torvalds/linux.git'
> remote1='git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git'
> branch1='master'
> # remote2='git://github.com/git/git.git'
> remote2='git://git.kernel.org/pub/scm/git/git.git'
> branch2='next'
>
> git clone --depth 1 --single-branch --branch "$branch1" "$remote1" "$repo_name"
> cd "$repo_name"
> git fetch -vvv "$remote2" # "$branch2:$branch2"
>
> -----------------------------------------------
>
> Cloning into 'git'...
> remote: Counting objects: 43215, done.
> remote: Compressing objects: 100% (41422/41422), done.
> remote: Total 43215 (delta 3079), reused 22032 (delta 1247)
> Receiving objects: 100% (43215/43215), 119.06 MiB | 1.60 MiB/s, done.
> Resolving deltas: 100% (3079/3079), done.
> Checking out files: 100% (40905/40905), done.
> fatal: destination path 'git' already exists and is not an empty directory.
Why does this error come up? It looks like git already exists locally.
Git should have aborted much earlier in clone when the directory
exists.
> Server supports multi_ack_detailed
> Server supports side-band-64k
> Server supports ofs-delta
> want 2d242fb3fc19fc9ba046accdd9210be8b9913f64 (HEAD)
> have ef6c5be658f6a70c1256fbd18e18ee0dc24c3386
> have db9d8c60266a5010e905829e10cd722519e14777
> done
> fatal: The remote end hung up unexpectedly
This looks like its from the fetch command. Since the server doesn't
report any errors to the client, its hard to say why the server just
gave up right there. I wonder if this is related to the fact that you
did a shallow clone initially. The shallow clone may have confused the
server when fetch ran because it only sent 2 have lines and gave up.
Try exporting GIT_TRACE_PACKET=1 and seeing if you can get more
detailed information from the protocol on the client side.
FYI, https://kernel.googlesource.com/ mirrors git://git.kernel.org/ so
you can also try pulling from that server (e.g.
https://kernel.googlesource.com/pub/scm/git/git.git).
^ permalink raw reply
* Re: [PATCH v5 06/15] remote-testgit: get rid of non-local functionality
From: Felipe Contreras @ 2012-11-21 23:44 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Johannes Schindelin, Max Horn, Jeff King, Sverre Rabbelier,
Brandon Casey, Brandon Casey, Jonathan Nieder, Ilari Liusvaara,
Pete Wyckoff, Ben Walton, Matthieu Moy, Julian Phillips
In-Reply-To: <7v624y3h0q.fsf@alter.siamese.dyndns.org>
On Wed, Nov 21, 2012 at 7:26 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> This only makes sense for the python remote helpers framework.
>
> A better explanation is sorely needed for this. If the test were
> feeding python snippet to be sourced by python remote helper to be
> tested, the new remote-testgit.bash would not have any hope (nor
> need) to grok it, and "this only makes sense for python" makes
> perfect sense and clear enough, but that is not the case.
>
> If the justification were like this:
>
> remote-testgit: remove non-local tests
>
> The simplified remote-testgit does not talk with any remote
> repository and incapable of running non-local tests. Remove
> them.
>
> I would understand it, and I wouldn't say it is a regression in the
> test not to test "non-local", as that is not essential aspect of
> these tests (we are only interested in testing the object/ref
> transfer over remote-helper interface and do not care what the
> "other side" really is).
>
> But I am not quite sure what you really mean by "non-local"
> functionality in the first place. The original test weren't opening
> network port to emulate multi-host remote transfer, were it?
No, that's not it at all.
By local, I mean 'file:///home/user/foo', by remote, I mean
'http://user.org/foo'. How each of these URLs is handled is entirely
up to the remote helper.
bzr for example doesn't need any change at all, the same API works on
both cases. hg OTOH has different APIs, so the code needs a local
clone to do most operations. The python remote helper framework has
APIs to make it easier to implement the local clone functionality (for
the remote helpers that need it).
This has absolutely nothing to do with with remote helpers, this is
100% a python remote helper feature. So we don't need those tests
here, they belong in git-remote-testpy.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: Topics currently in the Stalled category
From: Nguyen Thai Ngoc Duy @ 2012-11-22 11:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vobirq0q2.fsf_-_@alter.siamese.dyndns.org>
On Wed, Nov 21, 2012 at 7:05 AM, Junio C Hamano <gitster@pobox.com> wrote:
> * nd/unify-appending-of-s-o-b (2012-11-15) 1 commit
> - Unify appending signoff in format-patch, commit and sequencer
>
> I am not sure if the logic to refrain from adding a sign-off based
> on the existing run of sign-offs is done correctly in this change.
I'm not sure what's the right logic here. The original code in
format-patch has exactly one test just to verify that --signoff does
_something_. There's another signoff code in git-am.sh and we should
make sure at least the behavior is consistent. I guess I should start
over by writing new tests to record the current behavior, then fixes
and finally the unification. I think you can drop this for now.
--
Duy
^ permalink raw reply
* Fwd: Remote hung up during `git fetch`
From: Yichao Yu @ 2012-11-22 18:39 UTC (permalink / raw)
To: git
In-Reply-To: <CAMvDr+R__wWRwm2xNC3-v0T1RVu_rKdjKUJhb8cHwEXvuX9OMQ@mail.gmail.com>
Hi everyone,
I sent this email yesterday to the git mailing list but I cannot find
it in any archive so I decide to send it again.
Does anyone know what has happened to the mailing list? I haven't
receive any email from several kernel related busy mailing lists for
several hours....
Yichao Yu
---------- Forwarded message ----------
From: Yichao Yu <yyc1992@gmail.com>
Date: Wed, Nov 21, 2012 at 11:18 PM
Subject: Remote hung up during `git fetch`
To: git@vger.kernel.org
Hi everyone,
I want to build packages for snap shoot of different branches from
different remote git repositories in the same local directory (so that
I don't need to recompile everything everytime.) and I am using a
combination of `git clone/checkout/reset/fetch` to do that. However,
during git-fetch, the remote sometimes stop responding or simply reset
the connection. This happens occasionally at least for both ssh and
git protocol (not sure about http/https) on github, bitbucket and also
kernel.org so I think it is probably not due to a weird behavior of a
certain host. Does anyone know the reason or is there anything I have
done wrong? And is there a better way to set the local tree to a
certain branch at a certain url? THX
My git version is ArchLinux package 1.8.0-1. (timezone
America/New_York in case the time stamp somehow matters)
Here is a script that always triggers the issue (at least now) and
it's output. (No I am not trying to merge git and the kernel... These
are just random public repos on kernel.org that can trigger the issue.
Although I am pulling from two repos from different project here, the
same thing can also happen on other hosts when the two repos are
actually the same project)
Yichao Yu
------------------------------------------------------------------
#!/bin/bash
repo_name=git
# remote1='git://github.com/torvalds/linux.git'
remote1='git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git'
branch1='master'
# remote2='git://github.com/git/git.git'
remote2='git://git.kernel.org/pub/scm/git/git.git'
branch2='next'
git clone --depth 1 --single-branch --branch "$branch1" "$remote1" "$repo_name"
cd "$repo_name"
git fetch -vvv "$remote2" # "$branch2:$branch2"
-----------------------------------------------
Cloning into 'git'...
remote: Counting objects: 43215, done.
remote: Compressing objects: 100% (41422/41422), done.
remote: Total 43215 (delta 3079), reused 22032 (delta 1247)
Receiving objects: 100% (43215/43215), 119.06 MiB | 1.60 MiB/s, done.
Resolving deltas: 100% (3079/3079), done.
Checking out files: 100% (40905/40905), done.
fatal: destination path 'git' already exists and is not an empty directory.
Server supports multi_ack_detailed
Server supports side-band-64k
Server supports ofs-delta
want 2d242fb3fc19fc9ba046accdd9210be8b9913f64 (HEAD)
have ef6c5be658f6a70c1256fbd18e18ee0dc24c3386
have db9d8c60266a5010e905829e10cd722519e14777
done
fatal: The remote end hung up unexpectedly
^ permalink raw reply
* [PATCH] Fix bash completion when `egrep` is aliased to `egrep --color=always`
From: Adam Tkac @ 2012-11-22 15:41 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 169 bytes --]
Hello all,
attached patch fixes bash completion when `egrep` is aliased to `egrep --color=always`.
Comments are welcomed.
Regards, Adam
--
Adam Tkac, Red Hat, Inc.
[-- Attachment #2: 0001-Fix-bash-completion-when-egrep-is-aliased-to-egrep-c.patch --]
[-- Type: text/plain, Size: 998 bytes --]
>From 2b62bd71af1158129492f74f0b77c9840a49507f Mon Sep 17 00:00:00 2001
From: Adam Tkac <atkac@redhat.com>
Date: Thu, 22 Nov 2012 16:34:58 +0100
Subject: [PATCH] Fix bash completion when `egrep` is aliased to `egrep
--color=always`
Originally reported as https://bugzilla.redhat.com/show_bug.cgi?id=863780
Signed-off-by: Adam Tkac <atkac@redhat.com>
Signed-off-by: Holger Arnold <holgerar@gmail.com>
---
contrib/completion/git-completion.bash | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index bc0657a..47613f9 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -565,7 +565,7 @@ __git_complete_strategy ()
__git_list_all_commands ()
{
local i IFS=" "$'\n'
- for i in $(git help -a|egrep '^ [a-zA-Z0-9]')
+ for i in $(git help -a|egrep --color=never '^ [a-zA-Z0-9]')
do
case $i in
*--*) : helper pattern;;
--
1.8.0
^ permalink raw reply related
* [PATCH 5/5] git-send-email: allow edit invalid email address
From: Krzysztof Mazur @ 2012-11-22 18:12 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Felipe Contreras, Andreas Schwab, Felipe Balbi,
Tomi Valkeinen, Krzysztof Mazur
In-Reply-To: <1353607932-10436-1-git-send-email-krzysiek@podlesie.net>
In some cases the user may want to send email with "Cc:" line with
email address we cannot extract. Now we allow user to extract
such email address for us.
Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net>
---
git-send-email.perl | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index d42dca2..9996735 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -851,10 +851,10 @@ sub extract_valid_address_or_die {
sub validate_address {
my $address = shift;
- if (!extract_valid_address($address)) {
+ while (!extract_valid_address($address)) {
print STDERR "error: unable to extract a valid address from: $address\n";
- $_ = ask("What to do with this address? ([q]uit|[d]rop): ",
- valid_re => qr/^(?:quit|q|drop|d)/i,
+ $_ = ask("What to do with this address? ([q]uit|[d]rop|[e]dit): ",
+ valid_re => qr/^(?:quit|q|drop|d|edit|e)/i,
default => 'q');
if (/^d/i) {
return undef;
@@ -862,6 +862,9 @@ sub validate_address {
cleanup_compose_files();
exit(0);
}
+ $address = ask("Who should the email be sent to (if any)? ",
+ default => "",
+ valid_re => qr/\@.*\./, confirm_only => 1);
}
return $address;
}
--
1.8.0.393.gcc9701d
^ permalink raw reply related
* What's cooking in git.git (Nov 2012, #07; Wed, 21)
From: Junio C Hamano @ 2012-11-21 22:18 UTC (permalink / raw)
To: git
What's cooking in git.git (Nov 2012, #07; Wed, 21)
--------------------------------------------------
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
Many topics have been merged to 'maint' in preparation for 1.8.0.1;
and some more dormant topics have been moved to the stalled category
(to be discarded without prejudice unless they see some activities).
The upcoming 1.8.1 release is slowly taking shape.
You can find the changes described here in the integration branches
of the repositories listed at
http://git-blame.blogspot.com/p/git-public-repositories.html
--------------------------------------------------
[New Topics]
* nd/maint-compat-fnmatch-fix (2012-11-20) 1 commit
(merged to 'next' on 2012-11-21 at ce6fbe5)
+ compat/fnmatch: fix off-by-one character class's length check
Will merge to 'master' and then 'maint'.
--------------------------------------------------
[Graduated to "master"]
* cn/config-missing-path (2012-11-15) 1 commit
(merged to 'next' on 2012-11-18 at c08b73c)
+ config: don't segfault when given --path with a missing value
* jk/checkout-out-of-unborn (2012-11-15) 1 commit
(merged to 'next' on 2012-11-18 at 7d2aa24)
+ checkout: print a message when switching unborn branches
* jk/config-ignore-duplicates (2012-10-29) 9 commits
(merged to 'next' on 2012-10-29 at 67fa0a2)
+ builtin/config.c: Fix a sparse warning
(merged to 'next' on 2012-10-25 at 233df08)
+ git-config: use git_config_with_options
+ git-config: do not complain about duplicate entries
+ git-config: collect values instead of immediately printing
+ git-config: fix regexp memory leaks on error conditions
+ git-config: remove memory leak of key regexp
+ t1300: test "git config --get-all" more thoroughly
+ t1300: remove redundant test
+ t1300: style updates
Drop duplicate detection from git-config; this lets it better match
the internal config callbacks, which clears up some corner cases
with includes. This is an API breakage, though.
* jk/maint-gitweb-xss (2012-11-12) 1 commit
(merged to 'next' on 2012-11-14 at 7a667bc)
+ gitweb: escape html in rss title
Fixes an XSS vulnerability in gitweb.
* jk/maint-http-half-auth-fetch (2012-10-31) 2 commits
(merged to 'next' on 2012-11-09 at af69926)
+ remote-curl: retry failed requests for auth even with gzip
+ remote-curl: hoist gzip buffer size to top of post_rpc
Fixes fetch from servers that ask for auth only during the actual
packing phase. This is not really a recommended configuration, but it
cleans up the code at the same time.
* jl/submodule-rm (2012-11-14) 1 commit
(merged to 'next' on 2012-11-18 at bf4525d)
+ docs: move submodule section
Documentation correction for d21240f (Merge branch
'jl/submodule-rm', 2012-10-29) that needs to be fast-tracked.
* kb/preload-index-more (2012-11-02) 1 commit
(merged to 'next' on 2012-11-09 at a750ebd)
+ update-index/diff-index: use core.preloadindex to improve performance
Use preloadindex in more places, which has a nice speedup on systems
with slow stat calls (and even on Linux).
* mg/replace-resolve-delete (2012-11-13) 1 commit
(merged to 'next' on 2012-11-14 at fa785ae)
+ replace: parse revision argument for -d
Be more user friendly to people using "git replace -d".
* mh/alt-odb-string-list-cleanup (2012-11-08) 2 commits
(merged to 'next' on 2012-11-13 at 2bf41d9)
+ link_alt_odb_entries(): take (char *, len) rather than two pointers
+ link_alt_odb_entries(): use string_list_split_in_place()
Cleanups in the alternates code. Fixes a potential bug and makes the
code much cleaner.
* ml/cygwin-mingw-headers (2012-11-18) 2 commits
(merged to 'next' on 2012-11-19 at f9964da)
+ USE CGYWIN_V15_WIN32API as macro to select api for cygwin
(merged to 'next' on 2012-11-15 at 22e11b3)
+ Update cygwin.c for new mingw-64 win32 api headers
Make git work on newer cygwin.
* pw/maint-p4-rcs-expansion-newline (2012-11-08) 1 commit
(merged to 'next' on 2012-11-13 at e90cc7c)
+ git p4: RCS expansion should not span newlines
I do not have p4 to play with, but looks obviously correct to me.
* rh/maint-gitweb-highlight-ext (2012-11-08) 1 commit
(merged to 'next' on 2012-11-13 at c57d856)
+ gitweb.perl: fix %highlight_ext mappings
Fixes a clever misuse of perl's list interpretation.
* so/prompt-command (2012-10-17) 4 commits
(merged to 'next' on 2012-10-25 at 79565a1)
+ coloured git-prompt: paint detached HEAD marker in red
+ Fix up colored git-prompt
+ show color hints based on state of the git tree
+ Allow __git_ps1 to be used in PROMPT_COMMAND
Updates __git_ps1 so that it can be used as $PROMPT_COMMAND,
instead of being used for command substitution in $PS1, to embed
color escape sequences in its output.
Will merge to 'master' in the seventh batch.
* ta/doc-cleanup (2012-10-25) 6 commits
(merged to 'next' on 2012-11-13 at e11fafd)
+ Documentation: build html for all files in technical and howto
+ Documentation/howto: convert plain text files to asciidoc
+ Documentation/technical: convert plain text files to asciidoc
+ Change headline of technical/send-pack-pipeline.txt to not confuse its content with content from git-send-pack.txt
+ Shorten two over-long lines in git-bisect-lk2009.txt by abbreviating some sha1
+ Split over-long synopsis in git-fetch-pack.txt into several lines
--------------------------------------------------
[Stalled]
* pf/editor-ignore-sigint (2012-11-11) 5 commits
- launch_editor: propagate SIGINT from editor to git
- run-command: do not warn about child death by SIGINT
- run-command: drop silent_exec_failure arg from wait_or_whine
- launch_editor: ignore SIGINT while the editor has control
- launch_editor: refactor to use start/finish_command
Avoid confusing cases where the user hits Ctrl-C while in the editor
session, not realizing git will receive the signal. Since most editors
will take over the terminal and will block SIGINT, this is not likely
to confuse anyone.
Some people raised issues with emacsclient, which are addressed by this
re-roll. It should probably also handle SIGQUIT, and there were a
handful of other review comments.
Expecting a re-roll.
* mo/cvs-server-updates (2012-10-16) 10 commits
- cvsserver Documentation: new cvs ... -r support
- cvsserver: add t9402 to test branch and tag refs
- cvsserver: support -r and sticky tags for most operations
- cvsserver: Add version awareness to argsfromdir
- cvsserver: generalize getmeta() to recognize commit refs
- cvsserver: implement req_Sticky and related utilities
- cvsserver: add misc commit lookup, file meta data, and file listing functions
- cvsserver: define a tag name character escape mechanism
- cvsserver: cleanup extra slashes in filename arguments
- cvsserver: factor out git-log parsing logic
Needs review by folks interested in cvsserver.
* jn/warn-on-inaccessible-loosen (2012-10-14) 4 commits
- config: exit on error accessing any config file
- doc: advertise GIT_CONFIG_NOSYSTEM
- config: treat user and xdg config permission problems as errors
- config, gitignore: failure to access with ENOTDIR is ok
An RFC to deal with a situation where .config/git is a file and we
notice .config/git/config is not readable due to ENOTDIR, not
ENOENT; I think a bit more refactored approach to consistently
address permission errors across config, exclude and attrs is
desirable. Don't we also need a check for an opposite situation
where we open .config/git/config or .gitattributes for reading but
they turn out to be directories?
* as/check-ignore (2012-11-08) 14 commits
- t0007: fix tests on Windows
- Documentation/check-ignore: we show the deciding match, not the first
- Add git-check-ignore sub-command
- dir.c: provide free_directory() for reclaiming dir_struct memory
- pathspec.c: move reusable code from builtin/add.c
- dir.c: refactor treat_gitlinks()
- dir.c: keep track of where patterns came from
- dir.c: refactor is_path_excluded()
- dir.c: refactor is_excluded()
- dir.c: refactor is_excluded_from_list()
- dir.c: rename excluded() to is_excluded()
- dir.c: rename excluded_from_list() to is_excluded_from_list()
- dir.c: rename path_excluded() to is_path_excluded()
- dir.c: rename cryptic 'which' variable to more consistent name
Duy helped to reroll this.
Expecting a re-roll.
* aw/rebase-am-failure-detection (2012-10-11) 1 commit
- rebase: Handle cases where format-patch fails
I am unhappy a bit about the possible performance implications of
having to store the output in a temporary file only for a rare case
of format-patch aborting.
* jk/lua-hackery (2012-10-07) 6 commits
- pretty: fix up one-off format_commit_message calls
- Minimum compilation fixup
- Makefile: make "lua" a bit more configurable
- add a "lua" pretty format
- add basic lua infrastructure
- pretty: make some commit-parsing helpers more public
Interesting exercise. When we do this for real, we probably would want
to wrap a commit to make it more like an "object" with methods like
"parents", etc.
* fc/remote-testgit-feature-done (2012-10-29) 1 commit
- remote-testgit: properly check for errors
Is this still in "Needs review" state? Are people involved in the
remote interface happy with this change?
* jk/send-email-sender-prompt (2012-11-15) 8 commits
- send-email: do not prompt for explicit repo ident
- Git.pm: teach "ident" to query explicitness
- var: provide explicit/implicit ident information
- var: accept multiple variables on the command line
- ident: keep separate "explicit" flags for author and committer
- ident: make user_ident_explicitly_given static
- t7502: factor out autoident prerequisite
- test-lib: allow negation of prerequisites
Avoid annoying sender prompt in git-send-email, but only when it is
safe to do so.
Perhaps keep only the first three patches, and replace the rest
with the one from Felipe that takes a much simpler approach (the
rationale of that patch needs to be cleaned up first, along the
lines Jeff outlined, though). Frozen until that happens.
* nd/unify-appending-of-s-o-b (2012-11-15) 1 commit
- Unify appending signoff in format-patch, commit and sequencer
I am not sure if the logic to refrain from adding a sign-off based
on the existing run of sign-offs is done correctly in this change.
* nd/pretty-placeholder-with-color-option (2012-09-30) 9 commits
. pretty: support %>> that steal trailing spaces
. pretty: support truncating in %>, %< and %><
. pretty: support padding placeholders, %< %> and %><
. pretty: two phase conversion for non utf-8 commits
. utf8.c: add utf8_strnwidth() with the ability to skip ansi sequences
. utf8.c: move display_mode_esc_sequence_len() for use by other functions
. pretty: support %C(auto[,N]) to turn on coloring on next placeholder(s)
. pretty: split parsing %C into a separate function
. pretty: share code between format_decoration and show_decorations
This causes warnings with -Wuninitialized, so I've ejected it from pu
for the time being.
* rc/maint-complete-git-p4 (2012-09-24) 1 commit
(merged to 'next' on 2012-10-29 at af52cef)
+ Teach git-completion about git p4
Comment from Pete will need to be addressed in a follow-up patch.
* as/test-tweaks (2012-09-20) 7 commits
- tests: paint unexpectedly fixed known breakages in bold red
- tests: test the test framework more thoroughly
- [SQUASH] t/t0000-basic.sh: quoting of TEST_DIRECTORY is screwed up
- tests: refactor mechanics of testing in a sub test-lib
- tests: paint skipped tests in bold blue
- tests: test number comes first in 'not ok $count - $message'
- tests: paint known breakages in bold yellow
Various minor tweaks to the test framework to paint its output
lines in colors that match what they mean better.
Has the "is this really blue?" issue Peff raised resolved???
* jc/maint-name-rev (2012-09-17) 7 commits
- describe --contains: use "name-rev --algorithm=weight"
- name-rev --algorithm=weight: tests and documentation
- name-rev --algorithm=weight: cache the computed weight in notes
- name-rev --algorithm=weight: trivial optimization
- name-rev: --algorithm option
- name_rev: clarify the logic to assign a new tip-name to a commit
- name-rev: lose unnecessary typedef
"git name-rev" names the given revision based on a ref that can be
reached in the smallest number of steps from the rev, but that is
not useful when the caller wants to know which tag is the oldest one
that contains the rev. This teaches a new mode to the command that
uses the oldest ref among those which contain the rev.
I am not sure if this is worth it; for one thing, even with the help
from notes-cache, it seems to make the "describe --contains" even
slower. Also the command will be unusably slow for a user who does
not have a write access (hence unable to create or update the
notes-cache).
Stalled mostly due to lack of responses.
* jc/xprm-generation (2012-09-14) 1 commit
- test-generation: compute generation numbers and clock skews
A toy to analyze how bad the clock skews are in histories of real
world projects.
Stalled mostly due to lack of responses.
* jc/blame-no-follow (2012-09-21) 2 commits
- blame: pay attention to --no-follow
- diff: accept --no-follow option
Teaches "--no-follow" option to "git blame" to disable its
whole-file rename detection.
Stalled mostly due to lack of responses.
* jc/doc-default-format (2012-10-07) 2 commits
- [SQAUSH] allow "cd Doc* && make DEFAULT_DOC_TARGET=..."
- Allow generating a non-default set of documentation
Need to address the installation half if this is to be any useful.
* mk/maint-graph-infinity-loop (2012-09-25) 1 commit
- graph.c: infinite loop in git whatchanged --graph -m
The --graph code fell into infinite loop when asked to do what the
code did not expect ;-)
Anybody who worked on "--graph" wants to comment?
Stalled mostly due to lack of responses.
* jc/add-delete-default (2012-08-13) 1 commit
- git add: notice removal of tracked paths by default
"git add dir/" updated modified files and added new files, but does
not notice removed files, which may be "Huh?" to some users. They
can of course use "git add -A dir/", but why should they?
Resurrected from graveyard, as I thought it was a worthwhile thing
to do in the longer term.
Waiting for comments.
* mb/remote-default-nn-origin (2012-07-11) 6 commits
- Teach get_default_remote to respect remote.default.
- Test that plain "git fetch" uses remote.default when on a detached HEAD.
- Teach clone to set remote.default.
- Teach "git remote" about remote.default.
- Teach remote.c about the remote.default configuration setting.
- Rename remote.c's default_remote_name static variables.
When the user does not specify what remote to interact with, we
often attempt to use 'origin'. This can now be customized via a
configuration variable.
Expecting a re-roll.
"The first remote becomes the default" bit is better done as a
separate step.
* mh/ceiling (2012-10-29) 8 commits
- string_list_longest_prefix(): remove function
- setup_git_directory_gently_1(): resolve symlinks in ceiling paths
- longest_ancestor_length(): require prefix list entries to be normalized
- longest_ancestor_length(): take a string_list argument for prefixes
- longest_ancestor_length(): use string_list_split()
- Introduce new function real_path_if_valid()
- real_path_internal(): add comment explaining use of cwd
- Introduce new static function real_path_internal()
Elements of GIT_CEILING_DIRECTORIES list may not match the real
pathname we obtain from getcwd(), leading the GIT_DIR discovery
logic to escape the ceilings the user thought to have specified.
--------------------------------------------------
[Cooking]
* fc/fast-export-fixes (2012-11-21) 19 commits
- fast-export: don't handle uninteresting refs
- fast-export: make sure updated refs get updated
- fast-export: fix comparison in tests
- fast-export: trivial cleanup
- remote-testgit: advertise "done" feature and write "done" ourselves
- fixup! remote-testgit: report success after an import
- remote-testgit: report success after an import
- fixup! remote-testgit: exercise non-default refspec feature
- remote-testgit: exercise non-default refspec feature
- remote-testgit: cleanup tests
- remote-testgit: remove irrelevant test
- remote-testgit: remove non-local tests
- fixup! Add git-remote-testgit
- Add git-remote-testgit
- Rename git-remote-testgit to git-remote-testpy
- remote-helpers: fix failure message
- remote-testgit: fix direction of marks
- fixup! fast-export: avoid importing blob marks
- fast-export: avoid importing blob marks
Replaced with the last re-roll posted to the list, queued with
various fixup! commits to record suggested changes (most are
trivial style fixes).
* pp/gitweb-config-underscore (2012-11-21) 1 commit
- gitweb: make remote_heads config setting work
The key "gitweb.remote_heads" is not legal git config; this maps it to
"gitweb.remoteheads".
* jc/apply-trailing-blank-removal (2012-10-12) 1 commit
- apply.c:update_pre_post_images(): the preimage can be truncated
Fix to update_pre_post_images() that did not take into account the
possibility that whitespace fix could shrink the preimage and
change the number of lines in it.
Will merge to 'next'.
* nd/pathspec-wildcard (2012-11-19) 4 commits
- tree_entry_interesting: do basedir compare on wildcard patterns when possible
- pathspec: apply "*.c" optimization from exclude
- pathspec: do exact comparison on the leading non-wildcard part
- pathspec: save the non-wildcard length part
* sg/complete-help-undup (2012-11-14) 1 commit
(merged to 'next' on 2012-11-18 at eadd0f3)
+ completion: remove 'help' duplicate from porcelain commands
Will merge to 'master' in the seventh batch.
* bc/do-not-recurse-in-die (2012-11-15) 1 commit
(merged to 'next' on 2012-11-18 at 79d62a8)
+ usage.c: detect recursion in die routines and bail out immediately
Will merge to 'master' in the seventh batch.
* mk/complete-tcsh (2012-11-16) 1 commit
(merged to 'next' on 2012-11-19 at 8309029)
+ tcsh-completion re-using git-completion.bash
Will merge to 'master' in the seventh batch.
* mm/status-push-pull-advise (2012-11-16) 1 commit
- status: add advice on how to push/pull to tracking branch
Will merge to 'next'.
* lt/diff-stat-show-0-lines (2012-10-17) 1 commit
(merged to 'next' on 2012-11-19 at 0037290)
+ Fix "git diff --stat" for interesting - but empty - file changes
We failed to mention a file without any content change but whose
permission bit was modified, or (worse yet) a new file without any
content in the "git diff --stat" output.
Will merge to 'master' in the seventh batch.
* fc/zsh-completion (2012-11-19) 2 commits
- completion: start moving to the new zsh completion
- completion: add new zsh completion
Replaced by shedding large changes to other independent topics.
Any comments from zsh users?
* nd/wildmatch (2012-11-20) 14 commits
(merged to 'next' on 2012-11-21 at 151288f)
+ test-wildmatch: avoid Windows path mangling
(merged to 'next' on 2012-10-25 at 510e8df)
+ Support "**" wildcard in .gitignore and .gitattributes
+ wildmatch: make /**/ match zero or more directories
+ wildmatch: adjust "**" behavior
+ wildmatch: fix case-insensitive matching
+ wildmatch: remove static variable force_lower_case
+ wildmatch: make wildmatch's return value compatible with fnmatch
+ t3070: disable unreliable fnmatch tests
+ Integrate wildmatch to git
+ wildmatch: follow Git's coding convention
+ wildmatch: remove unnecessary functions
+ Import wildmatch from rsync
+ ctype: support iscntrl, ispunct, isxdigit and isprint
+ ctype: make sane_ctype[] const array
Allows pathname patterns in .gitignore and .gitattributes files
with double-asterisks "foo/**/bar" to match any number of directory
hierarchies.
I suspect that this needs to be plugged to pathspec matching code;
otherwise "git log -- 'Docum*/**/*.txt'" would not show the log for
commits that touch Documentation/git.txt, which would be confusing
to the users.
Will cook in 'next'.
* jh/update-ref-d-through-symref (2012-10-21) 2 commits
(merged to 'next' on 2012-11-19 at 6bcca4c)
+ Fix failure to delete a packed ref through a symref
+ t1400-update-ref: Add test verifying bug with symrefs in delete_ref()
"update-ref -d --deref SYM" to delete a ref through a symbolic ref
that points to it did not remove it correctly.
Will merge to 'master' in the seventh batch.
* fc/completion-test-simplification (2012-11-16) 6 commits
- completion: simplify __gitcomp() test helper
- completion: refactor __gitcomp related tests
- completion: consolidate test_completion*() tests
- completion: simplify tests using test_completion_long()
- completion: standardize final space marker in tests
- completion: add comment for test_completion()
Clean up completion tests. Use of conslidated helper may make
instrumenting one particular test during debugging of the test
itself, but I think that issue should be addressed in some other
way (e.g. making sure individual tests in 9902 can be skipped).
* jk/pickaxe-textconv (2012-10-28) 2 commits
- pickaxe: use textconv for -S counting
- pickaxe: hoist empty needle check
Use textconv filters when searching with "log -S".
Will merge to 'next'.
* fc/remote-bzr (2012-11-08) 5 commits
(merged to 'next' on 2012-11-18 at 86add07)
+ remote-bzr: update working tree
+ remote-bzr: add support for remote repositories
+ remote-bzr: add support for pushing
+ remote-bzr: add simple tests
+ Add new remote-bzr transport helper
New remote helper for bzr.
Will merge to 'master' in the seventh batch.
* fc/remote-hg (2012-11-12) 20 commits
(merged to 'next' on 2012-11-18 at 4a4f2e4)
+ remote-hg: avoid bad refs
+ remote-hg: try the 'tip' if no checkout present
+ remote-hg: fix compatibility with older versions of hg
+ remote-hg: add missing config for basic tests
+ remote-hg: the author email can be null
+ remote-hg: add option to not track branches
+ remote-hg: add extra author test
+ remote-hg: add tests to compare with hg-git
+ remote-hg: add bidirectional tests
+ test-lib: avoid full path to store test results
+ remote-hg: add basic tests
+ remote-hg: fake bookmark when there's none
+ remote-hg: add compat for hg-git author fixes
+ remote-hg: add support for hg-git compat mode
+ remote-hg: match hg merge behavior
+ remote-hg: make sure the encoding is correct
+ remote-hg: add support to push URLs
+ remote-hg: add support for remote pushing
+ remote-hg: add support for pushing
+ Add new remote-hg transport helper
New remote helper for hg.
Will merge to 'master' in the seventh batch.
* cr/push-force-tag-update (2012-11-19) 5 commits
- push: update remote tags only with force
- push: flag updates that require force
- push: keep track of "update" state separately
- push: add advice for rejected tag reference
- push: return reject reasons via a mask
Require "-f" for push to update a tag, even if it is a fast-forward.
* rr/submodule-diff-config (2012-11-18) 4 commits
(merged to 'next' on 2012-11-19 at 355319e)
+ submodule: display summary header in bold
+ diff: rename "set" variable
+ diff: introduce diff.submodule configuration variable
+ Documentation: move diff.wordRegex from config.txt to diff-config.txt
Lets "git diff --submodule=log" become the default via configuration.
Will merge to 'master' in the seventh batch.
^ permalink raw reply
* [PATCH 1/5] git-send-email: remove garbage after email address
From: Krzysztof Mazur @ 2012-11-22 18:12 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Felipe Contreras, Andreas Schwab, Felipe Balbi,
Tomi Valkeinen, Krzysztof Mazur
In-Reply-To: <7v8v9vrgc9.fsf@alter.siamese.dyndns.org>
In some cases it's very useful to add some additional information
after email in Cc-list, for instance:
"Cc: Stable kernel <stable@vger.kernel.org> #v3.4 v3.5 v3.6"
Currently the git refuses to add such invalid email to Cc-list,
when the Email::Valid perl module is available or just uses whole line
as the email address.
Now in sanitize_address() everything after the email address is
removed, so the resulting line is correct email address and Email::Valid
validates it correctly.
Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net>
Tested-by: Felipe Balbi <balbi@ti.com>
---
git-send-email.perl | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/git-send-email.perl b/git-send-email.perl
index 5a7c29d..9840d0a 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -924,6 +924,10 @@ sub quote_subject {
# use the simplest quoting being able to handle the recipient
sub sanitize_address {
my ($recipient) = @_;
+
+ # remove garbage after email address
+ $recipient =~ s/(.*>).*$/$1/;
+
my ($recipient_name, $recipient_addr) = ($recipient =~ /^(.*?)\s*(<.*)/);
if (not $recipient_name) {
--
1.8.0.393.gcc9701d
^ 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