[PATCH 1/3] config.txt: a few lines about branch.name.description
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- Documentation/config.txt | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/config.txt b/Documentation/config.txt index bf8f911..ee64846 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -735,6 +735,12 @@ branch.name.rebase:: it unless you understand the implications (see linkgit:git-rebase[1] for details). +branch.name.description:: + Branch description, can be edited with + `git branch --edit-description`. Branch description is + automatically added in the format-patch cover letter or + request-pull summary. + browser.tool.cmd:: Specify the command to invoke the specified browser. The specified command is evaluated in shell with the URLs passed -- 1.8.0.rc2.23.g1fb49df -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] format-patch: pick up branch description when no ref is specified
find_branch_name() fails to detect format-patch --cover-letter -3
where no command line arguments are given and HEAD is automatically
added. Detect branch name in this case so we can pick up the branch's
description in cover letter.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
builtin/log.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/builtin/log.c b/builtin/log.c
index e7b7db1..115f118 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -1027,8 +1027,22 @@ static char *find_branch_name(struct rev_info *rev)
else
return NULL;
}
- if (positive 0)
+ if (positive 0) {
+ /*
+* No actual ref from command line, but HEAD from
+* rev-def was added in setup_revisions()
+* e.g. format-patch --cover-letter -12
+*/
+ if (!rev-cmdline.nr
+ rev-pending.nr == 1
+ !strcmp(rev-pending.objects[0].name, HEAD)) {
+ const char *ref;
+ ref = resolve_ref_unsafe(HEAD, branch_sha1, 1, NULL);
+ if (ref !prefixcmp(ref, refs/heads/))
+ return xstrdup(ref + strlen(refs/heads/));
+ }
return NULL;
+ }
strbuf_addf(buf, refs/heads/%s, rev-cmdline.rev[positive].name);
branch = resolve_ref_unsafe(buf.buf, branch_sha1, 1, NULL);
if (!branch ||
--
1.8.0.rc2.23.g1fb49df
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] branch: delete branch description if it's empty
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- I don't see the value of having an empty branch description. But I may be missing something. builtin/branch.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/builtin/branch.c b/builtin/branch.c index 1ec9c02..873f624 100644 --- a/builtin/branch.c +++ b/builtin/branch.c @@ -725,7 +725,7 @@ static int edit_branch_description(const char *branch_name) stripspace(buf, 1); strbuf_addf(name, branch.%s.description, branch_name); - status = git_config_set(name.buf, buf.buf); + status = git_config_set(name.buf, buf.len ? buf.buf : NULL); strbuf_release(name); strbuf_release(buf); -- 1.8.0.rc2.23.g1fb49df -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Remove the suggestion to use parsecvs, which is currently broken.
Minor typo On 12/29/2012 05:20 AM, Eric S. Raymond wrote: The parsecvs code has been neglected for a long time, and the only public version does not even build correctly. I have been handed control of the project and intend to fix this, but until I do it cannot be recommended. Also, the project URL given for Subversion needed to be updated to follow their site move. --- Documentation/git-cvsimport.txt | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/Documentation/git-cvsimport.txt b/Documentation/git-cvsimport.txt index 98d9881..9d5353e 100644 --- a/Documentation/git-cvsimport.txt +++ b/Documentation/git-cvsimport.txt @@ -213,11 +213,9 @@ Problems related to tags: * Multiple tags on the same revision are not imported. If you suspect that any of these issues may apply to the repository you -want to import consider using these alternative tools which proved to be -more stable in practice: +want to imort, consider using cvs2git: s/imort/import/ -* cvs2git (part of cvs2svn), `http://cvs2svn.tigris.org` -* parsecvs, `http://cgit.freedesktop.org/~keithp/parsecvs` +* cvs2git (part of cvs2svn), `http://subversion.apache.org/` GIT --- -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] pack-objects: compression level for non-blobs
On Tue, Jan 1, 2013 at 11:15 AM, Duy Nguyen pclo...@gmail.com wrote: Fix pack-objects to behave the way JGit does, cluster commits first in the pack stream. Now you have a dense space of commits. If I remember right this has a tiny positive improvement for most rev-list operations with very little downside. I was going to suggest a similar thing. The current state of C Git's pack writing is not bad. We mix commits and tags together, but tags And I was wrong. At least since 1b4bb16 (pack-objects: optimize recency order - 2011-06-30) commits are spread out and can be mixed with trees too. Grouping them back defeats what Junio did in that commit, I think. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git filter-branch doesn't dereference annotated tags
Am 31.12.2012 17:24, schrieb Grégory Pakosz:
Please disregard the previous email that contains an incorrect fix
suggestion. I wish my first contribution was flawless.
Here is what's happening.
git-filter-branch let git-update-ref -d verify that the value for $ref
matches $sha1.
However, when $ref points to an annotated tag that is being deleted,
that verification fails because $sha1 is the commit underneath.
I think there are two possible fixes:
1) either make git-filter-branch dereference annotated tags and do
the verification itself then use the two arguments version of git
update-ref
2) in the case of an annotated tag, pass another old value to git
update-ref
Please find below a patch that implements solution 1). Please note the
patch doesn't contain a unit test for this situation as I wasn't sure
how to provide one. Yet I tested it on the repository I'm working on.
Gregory
We write material like this below the three-dash line of the patch.
From 9d21960088a61bfbac1ffdb4b13e3038f88ab4d6 Mon Sep 17 00:00:00 2001
From: Gregory Pakosz gpak...@visionobjects.com
Date: Mon, 31 Dec 2012 15:30:36 +0100
Then you can remove these three lines because they are inferred from the
email message. And you should not attach the patch, only place it
inline, but make sure that it is not line-wrapped and space-mangled on
the mail route.
Subject: [PATCH] git-filter-branch: support annotated tags deletion
git-filter-branch let git-update-ref -d verify that the value for $ref matches
$sha1. However, when $ref is an annotated tag being deleted that verfication
fails because $sha1 corresponds to a commit object.
Instead of asking git-update-ref to verify values actually match, dereference
$ref ourselves and test against $sha1 first. Then invoke git-update-ref with
two
arguments.
It would have been very helpful if you could summarize the conditions
under which the unexpected behavior happens in the commit message. A
test case would also be great; it should be a matter of inserting
another case in t/t7003.
Without that information, I can't decide whether it is a good thing that
a tag (annotated or not) is deleted, because we have --tag-name-filter
to treat tags (even though you can't delete tags with this feature).
Signed-off-by: Gregory Pakosz gpak...@visionobjects.com
---
git-filter-branch.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index 5314249..bbee6d0 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -383,7 +383,7 @@ do
case $rewritten in
'')
echo Ref '$ref' was deleted
- git update-ref -m filter-branch: delete -d $ref $sha1 ||
+ test $(git rev-parse --verify $ref^{commit}) = $sha1 git
update-ref -m filter-branch: delete -d $ref ||
die Could not delete $ref
As written, it counts as error Could not delete $ref if the test...
command fails. Is this intended?
-- Hannes
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git filter-branch doesn't dereference annotated tags
Thanks. A few comments.
At the design level. Where does this $sha1 come from in the first
place?
actually, sha1=$(git rev-parse $ref^0)
(please remember that I'm discovering git internals while figuring out
how to make git filter-branch work in my use case)
in my use case, $ref is refs/tags/4.0 which is an annotated tag
$ git rev-parse refs/tags/4.0
e941b106c17b59320f776d58b71fc2fcdb72
$ git cat-file -t e941b106c17b59320f776d58b71fc2fcdb72
tag
$ git rev-parse e941b106c17b59320f776d58b71fc2fcdb72^0
dcd7cdc18240dd9a54b30d757dd2347f52040490
$ git cat-file -t dcd7cdc18240dd9a54b30d757dd2347f52040490
commit
so $sha1 is dcd7cdc18240dd9a54b30d757dd2347f52040490
and then git-filter-branch calls git update-ref -m filter-branch:
delete -d refs/tags/4.0 dcd7cdc18240dd9a54b30d757dd2347f52040490
which makes git update-index complains
e941b106c17b59320f776d58b71fc2fcdb72 !=
dcd7cdc18240dd9a54b30d757dd2347f52040490
so hmm, adding test $(git rev-parse --verify $ref^{commit}) = $sha1
as I did in my patch is always true since sha1=$(git rev-parse
$ref^0)
If a ref that named the annotated tag was deleted, shouldn't
we arrange things so this part of the code receives the $sha1 of the
tag that corresponds to the $ref
I'm not sure what you mean by a ref that named the annotated tag was deleted
What's happening in my situation is that the commit the tag points to
gets rewritten to nothing as the result of my filtering:
refs/tags/4.0 points to e941b106c17b59320f776d58b71fc2fcdb72
(tag) which points to dcd7cdc18240dd9a54b30d757dd2347f52040490
(commit) which gets rewritten to nothing so the tag must be deleted.
so that update-ref -d can check
that nobody tampered with the repository while the script was
working?
I'm not quite sure what could possibly go well if somebody tampers
with the repository while it's being filtered with git filter-branch
anyways???
If we want to address did somebody tamper with the repository while
the script was working?, then test $(git rev-parse --verify
$ref^{commit}) = $sha1 verifies somebody didn't tamper with $ref
since we got $sha1 from it.
But that doesn't ensure tampering didn't take place in between
test $(git rev-parse --verify $ref^{commit}) = $sha1
and
git update-ref -m filter-branch: delete -d $ref.
How defensive should git filter-branch really be?
At the implementation level. When the ref being deleted pointed at
a tree or a blob, the original would have correctly removed it, but
will the updated one?
Yes.
Now that you made me think about it even more, the title of that
thread isn't git filter-branch doesn't dereference annotated tags.
It in fact does as per sha1=$(git rev-parse $ref^0).
Maybe the suggested fix should be: in case the tag points to a commit
that has been rewritten to nothing, get $sha1 again without
dereferencing recursively with sha1=$(git rev-parse $ref) then use
the 3 arguments versions of git update-ref as before.
Thanks for reading
Gregory
From 59f86c9c07715734d59009c15816220f996b75be Mon Sep 17 00:00:00 2001
From: Gregory Pakosz gpak...@visionobjects.com
Date: Mon, 31 Dec 2012 15:30:36 +0100
Subject: [PATCH] git-filter-branch: support annotated tags deletion
git-filter-branch let git-update-ref -d verify that the value for $ref matches
$sha1. $sha1 is obtained form dereferencing $ref recursively. In case $sha1 gets
rewritten to nothing as per result of the filtering, the tag should be deleted.
However, in case of an annotated tag, git-update-ref -d fails because $ref
doesn't directly point to $sha1.
To make git-filter-branch properly delete an annotated tag, obtain $sha1 again
withouth dereferencing the tag before asking git-update-ref to verify $ref and
$sha1 match.
Signed-off-by: Gregory Pakosz gpak...@visionobjects.com
---
git-filter-branch.sh | 1 +
1 file changed, 1 insertion(+)
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index 5314249..7ae9912 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -383,6 +383,7 @@ do
case $rewritten in
'')
echo Ref '$ref' was deleted
+ test $(git cat-file -t $ref) = 'tag' sha1=$(git rev-parse
$ref)
git update-ref -m filter-branch: delete -d $ref $sha1 ||
die Could not delete $ref
;;
--
1.8.0.1
0001-git-filter-branch-support-annotated-tags-deletion.patch
Description: Binary data
[PATCH] Correct example restore from bundle
Without use branche option repository restory without files: $ git clone pr.bundle q/ Cloning into 'q'... Receiving objects: 100% (619/619), 13.52 MiB | 18.74 MiB/s, done. Resolving deltas: 100% (413/413), done. warning: remote HEAD refers to nonexistent ref, unable to checkout. $ ls -aF q/ ./ ../ .git/ Signed-off-by: Brilliantov Kirill Vladimirovich brillian...@inbox.ru --- Documentation/git-bundle.txt |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/git-bundle.txt b/Documentation/git-bundle.txt index 16a6b0a..6c31715 100644 --- a/Documentation/git-bundle.txt +++ b/Documentation/git-bundle.txt @@ -118,7 +118,7 @@ were a remote repository instead of creating an empty repository and then pulling or fetching objects from the bundle: -machineB$ git clone /home/me/tmp/file.bundle R2 +machineB$ git clone /home/me/tmp/file.bundle R2 -b master This will define a remote called origin in the resulting repository that -- 1.7.10.4
[PATCH] Correct example restore from bundle
Without use branche option repository restory without files:
$ git clone pr.bundle q/
Cloning into 'q'...
Receiving objects: 100% (619/619), 13.52 MiB | 18.74 MiB/s, done.
Resolving deltas: 100% (413/413), done.
warning: remote HEAD refers to nonexistent ref, unable to checkout.
$ ls -aF q/
./ ../ .git/
Signed-off-by: Brilliantov Kirill Vladimirovich brillian...@inbox.ru
---
Documentation/git-bundle.txt |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/git-bundle.txt b/Documentation/git-bundle.txt
index 16a6b0a..6c31715 100644
--- a/Documentation/git-bundle.txt
+++ b/Documentation/git-bundle.txt
@@ -118,7 +118,7 @@ were a remote repository instead of creating an empty
repository and then
pulling or fetching objects from the bundle:
-machineB$ git clone /home/me/tmp/file.bundle R2
+machineB$ git clone /home/me/tmp/file.bundle R2 -b master
This will define a remote called origin in the resulting repository that
--
1.7.10.4N�r��yb�X��ǧv�^�){.n�+ا���ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z� �w���?��)ߢf
Re: What's cooking in git.git (Dec 2012, #08; Mon, 31)
* ap/status-ignored-in-ignored-directory (2012-12-26) 1 commit - wt-status: Show ignored files in untracked dirs A topic still in flux; will be redone. I've already redone this part sending two patches (one with the fix, and one with some tests for each individual use-case) that you probably missed. Here are the message ids: - 1356878341-12942-1-git-send-email-apeli...@gmail.com - 1356878341-12942-2-git-send-email-apeli...@gmail.com * ap/log-mailmap (2012-12-27) 10 commits - log --use-mailmap: optimize for cases without --author/--committer search - log: add log.mailmap configuration option - log: grep author/committer using mailmap - test: Add test for --use-mailmap option - log: Add --use-mailmap option - pretty: Use mailmap to display username and email - mailmap: Add mailmap structure to rev_info and pp - mailmap: Simplify map_user() interface - mailmap: Remove buffer length limit in map_user - Use split_ident_line to parse author and committer (this branch is used by jc/mailmap.) Clean up various codepaths around mailmap and teach the log machinery to use it. Will merge to 'next'. I'm not sure that should be merged to next yet. I've thought of another optimization that will require another preparatory step. Here is the idea: - Create some string_list_lookup_extended with a n parameter (size of the string to match) and a case parameter (to allow strncasecmp() the strings). - Re-re-factor map_user() to take/return pointers instead of strbufs to avoid a bunch of copies. (that is pointless without the former point). The whole idea would be to avoid a bunch of copies: one for lowering the email, the other for adding '\0' at the end of name before running string_list_lookup(). Cheers, -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] pack-objects: compression level for non-blobs
On Tue, Jan 1, 2013 at 4:10 AM, Duy Nguyen pclo...@gmail.com wrote: On Tue, Jan 1, 2013 at 11:15 AM, Duy Nguyen pclo...@gmail.com wrote: Fix pack-objects to behave the way JGit does, cluster commits first in the pack stream. Now you have a dense space of commits. If I remember right this has a tiny positive improvement for most rev-list operations with very little downside. I was going to suggest a similar thing. The current state of C Git's pack writing is not bad. We mix commits and tags together, but tags And I was wrong. At least since 1b4bb16 (pack-objects: optimize recency order - 2011-06-30) commits are spread out and can be mixed with trees too. Grouping them back defeats what Junio did in that commit, I think. I think you misunderstand what 1b4bb16 does. Junio uses a layout similar to what JGit has done for years. Commits are packed, then trees, then blobs. Only annotated tags are interspersed with commits. The decision on where to place tags is different, but has a similar purpose. How blobs are written is very different, Junio's implementation is strictly better than JGit's[1]. So we can use pack ordering. There will be a gap because of tags, but if we assume there are less tags than commits, it will still be a reasonable cache file size. [1] I have known this since he was developing this commit. We talked about clustering by delta chain and the improvements it showed in CGit. I tried to implement a similar delta chain clustering in JGit but broke something in the packer and caused data corruption, so its stalled. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Bug in latest gitk - can't click lines connecting commits
I was testing some patches against the latest gitk, and noticed that when I click the mouse on the lines that connect the commits in the history graph, I get an error popup with: Error: can't read cflist_top: no such variable Looks like this was introduced in gitk commit b967135d89e8d8461d059 gitk: Synchronize highlighting in file view when scrolling diff This commit hasn't been merged yet from upstream into git. Here's the full error trace: can't read cflist_top: no such variable can't read cflist_top: no such variable while executing $cflist tag remove highlight $cflist_top.0 $cflist_top.0 lineend (procedure highlightfile line 4) invoked from within highlightfile 0 (procedure highlightfile_for_scrollpos line 8) invoked from within highlightfile_for_scrollpos $topidx (procedure scrolltext line 9) invoked from within scrolltext 0.0 1.0 (vertical scrolling command executed by text) -Jason -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug in latest gitk - can't click lines connecting commits
Jason Holden jason.k.holden.sw...@gmail.com wrote: I was testing some patches against the latest gitk, and noticed that when I click the mouse on the lines that connect the commits in the history graph, I get an error popup with: Error: can't read cflist_top: no such variable Looks like this was introduced in gitk commit b967135d89e8d8461d059 gitk: Synchronize highlighting in file view when scrolling diff A patch that fixes this was proposed over two months ago, and Paul said he had applied it: http://permalink.gmane.org/gmane.comp.version-control.git/208162 However, looking at git://ozlabs.org/~paulus/gitk.git it's not there. Paul? -- Stefan Haller Berlin, Germany http://www.haller-berlin.de/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git filter-branch doesn't dereference annotated tags
Grégory Pakosz gpak...@visionobjects.com writes: in my use case, $ref is refs/tags/4.0 which is an annotated tag $ git rev-parse refs/tags/4.0 e941b106c17b59320f776d58b71fc2fcdb72 Yeah, but in that case it appears to me that you told the command to rewrite the tag itself and the history behind the commit the tag refers to, but the end result did not rewrite the tag itself and left the tag pointing at the original history. The $rewritten variable being empty in this codepath tells me that the command decided that it *does* want to delete the tag, but as J6t mentioned in his review, it is unclear to me what is expected by the user. If the command and the filters you gave the command decided the tag should be removed, then not being able to delete it is a problem and the code you patched that compares the object name of the tag and the object name of the commit the tag refers to is certainly doing a wrong comparison. But I have this suspicion that you did not want to remove the tag in the first place. The application of map shell function to obtain $rewritten is done on the unwrapped object name by passing $ref^0 to rev-parse, but perhaps that ^0 is the real source of the problem instead, so that it checks what new object the original annotated tag was rewritten to? If the tag object was rewritten, either to empty to signal its removal or to a new object name, then we do want to update-ref it, but the decision should be made on its object name, not the object name of the commit it points at? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Dec 2012, #08; Mon, 31)
Antoine Pelisse apeli...@gmail.com writes: * ap/status-ignored-in-ignored-directory (2012-12-26) 1 commit - wt-status: Show ignored files in untracked dirs A topic still in flux; will be redone. I've already redone this part sending two patches (one with the fix, and one with some tests for each individual use-case) that you probably missed. It was more like waiting for the discussion to come to conclusion and dust to settle. Here are the message ids: - 1356878341-12942-1-git-send-email-apeli...@gmail.com - 1356878341-12942-2-git-send-email-apeli...@gmail.com Thanks. * ap/log-mailmap (2012-12-27) 10 commits - ... Clean up various codepaths around mailmap and teach the log machinery to use it. Will merge to 'next'. I'm not sure that should be merged to next yet. I am sure it is not ready ;-) after discussing the strbuf_grow() with you. Thanks for reminding. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] pack-objects: compression level for non-blobs
Duy Nguyen pclo...@gmail.com writes: On Tue, Jan 1, 2013 at 11:15 AM, Duy Nguyen pclo...@gmail.com wrote: Fix pack-objects to behave the way JGit does, cluster commits first in the pack stream. Now you have a dense space of commits. If I remember right this has a tiny positive improvement for most rev-list operations with very little downside. I was going to suggest a similar thing. The current state of C Git's pack writing is not bad. We mix commits and tags together, but tags And I was wrong. At least since 1b4bb16 (pack-objects: optimize recency order - 2011-06-30) commits are spread out and can be mixed with trees too. Really? That certainly wasn't the intention of that change. The compute_write_order() function first fills the commits in the original recency order (the order in which rev-list discovered them by traversing the history from the tips) until we find a commit that is tagged by a ref in the refs/tags/ hierarchy. When we reach that point, we stop showing the commits and show all the tags in the refs/tags/ hierarchy and commits that are tagged by them, breaking the original ordering of commits so that ancient but tagged commits clump at this point. After that, we resume showing the rest of the commits and tags in the original order they came to us. Trees are done next, and then the remainder. So I am not sure how trees can appear between commits. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git filter-branch doesn't dereference annotated tags
Yeah, but in that case it appears to me that you told the command to rewrite the tag itself and the history behind the commit the tag refers to, but the end result did not rewrite the tag itself and left the tag pointing at the original history. The problem exhibits at the point git filter-branch updates the references. I indeed asked to rewrite tagged commits by passing --tag-name-filter cat The $rewritten variable being empty in this codepath tells me that the command decided that it *does* want to delete the tag, but as J6t mentioned in his review, it is unclear to me what is expected by the user. The history behind the commit the tag refers to is empty after filtering has been applied. As a user, I expected the tag to be removed: it's not illogical, all tags that pointed to history that has been entirely filtered out should go away imho. --tag-name-filter doesn't allow to deleted tags as J6t mentioned and I'm not surre what the new contract would be: empty tag name to delete a tag so if $(map $sha1) yields '' I can decided to delete the tag? If the tag wasn't an annotated one, I guess it would have been successfully deleted which exhibits a different behavior between annotated and lightweight tags. If the command and the filters you gave the command decided the tag should be removed, then not being able to delete it is a problem and the code you patched that compares the object name of the tag and the object name of the commit the tag refers to is certainly doing a wrong comparison. That's what I believe. The index and commit filters are made to keep only a couple of directories and get rid of the rest. Those directories didn't exist early in the history. Commits in that early part of the history were tagged with annotated tags. But I have this suspicion that you did not want to remove the tag in the first place. The tag pointed to something the filters decided to throw out. Since I want tags to be updated, it doesn't make much sense to keep it and I'm expecting its deletion. It appears to me that the suggested fix doing test $(git cat-file -t $ref) = 'tag' sha1=$(git rev-parse $ref) so that $sha1 is obtained again from the tag ref but without dereferencing recursively should only apply if --tag-name-filter has been provided. What do you think? The application of map shell function to obtain $rewritten is done on the unwrapped object name by passing $ref^0 to rev-parse, but perhaps that ^0 is the real source of the problem instead, so that it checks what new object the original annotated tag was rewritten to? If the tag object was rewritten, either to empty to signal its removal or to a new object name, then we do want to update-ref it, but the decision should be made on its object name, not the object name of the commit it points at? Are you suggesting $sha1 should be obtained differently before entering case $rewritten ? That would mean changing sha1=$(git rev-parse $ref^0) at line 376 to something like $(git cat-file -t $ref) = 'tag' sha1=$(git rev-parse $ref) || sha1=$(git rev-parse $ref^0) ? Gregory -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] format-patch: pick up branch description when no ref is specified
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
find_branch_name() fails to detect format-patch --cover-letter -3
where no command line arguments are given and HEAD is automatically
added.
Nicely spotted.
That is not the only case that takes this codepath, though.
$ git format-patch --cover-letter master..
will also give you the same (if you say it without .., which is
the more normal invocation of the command, then the caller already
know you meant the current branch and this function is not called).
And in that case you will have two tokens on cmdline.nr, one for
master.. to show where he bottom is, and the other for the
implied HEAD; I do not think this patch is a sufficient solution
for the more general cases, but on the other hand I do not know how
much it matters.
- if (positive 0)
+ if (positive 0) {
+ /*
+ * No actual ref from command line, but HEAD from
+ * rev-def was added in setup_revisions()
+ * e.g. format-patch --cover-letter -12
+ */
That comment does not describe positive 0 case, but belongs to
the conditional added in this patch, no?
+ if (!rev-cmdline.nr
+ rev-pending.nr == 1
+ !strcmp(rev-pending.objects[0].name, HEAD)) {
+ const char *ref;
+ ref = resolve_ref_unsafe(HEAD, branch_sha1, 1, NULL);
+ if (ref !prefixcmp(ref, refs/heads/))
+ return xstrdup(ref + strlen(refs/heads/));
+ }
return NULL;
+ }
strbuf_addf(buf, refs/heads/%s, rev-cmdline.rev[positive].name);
branch = resolve_ref_unsafe(buf.buf, branch_sha1, 1, NULL);
if (!branch ||
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Correct example restore from bundle
Kirill Brilliantov brillian...@inbox.ru writes: -machineB$ git clone /home/me/tmp/file.bundle R2 +machineB$ git clone /home/me/tmp/file.bundle R2 -b master I think the command line should follow the convention that is suggested in git clone -h output, i.e. git clone -b master /home/me/tmp/file.bundle R2 I also think 'git bundle create should record HEAD that points at the only branch it is packing so the person who clones from it should not say which branch, and when that is done this patch will become unnecessary, but that is a separate topic. Thanks; I'll queue this after rewording some. -- 8 -- From: Kirill Brilliantov brillian...@inbox.ru Date: Tue, 1 Jan 2013 17:54:44 +0400 Subject: [PATCH] Documentation: correct example restore from bundle Because the bundle created in the example does not record HEAD, git clone will not check out the files to the working tree: $ git clone pr.bundle q/ Cloning into 'q'... Receiving objects: 100% (619/619), 13.52 MiB | 18.74 MiB/s, done. Resolving deltas: 100% (413/413), done. warning: remote HEAD refers to nonexistent ref, unable to checkout. Avoid alarming the readers by adding -b master to the example. A better fix may be to arrange the bundle created in the earlier step to record HEAD, so that it can be cloned without this workaround. Signed-off-by: Brilliantov Kirill Vladimirovich brillian...@inbox.ru Signed-off-by: Junio C Hamano gits...@pobox.com --- Documentation/git-bundle.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/git-bundle.txt b/Documentation/git-bundle.txt index 16a6b0a..5c8ba44 100644 --- a/Documentation/git-bundle.txt +++ b/Documentation/git-bundle.txt @@ -118,7 +118,7 @@ were a remote repository instead of creating an empty repository and then pulling or fetching objects from the bundle: -machineB$ git clone /home/me/tmp/file.bundle R2 +machineB$ git clone -b master /home/me/tmp/file.bundle R2 This will define a remote called origin in the resulting repository that -- 1.8.1.209.gc32ab23 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 02/19] Improve documentation and comments regarding directory traversal API
Adam Spiers g...@adamspiers.org writes:
diff --git a/Documentation/technical/api-directory-listing.txt
b/Documentation/technical/api-directory-listing.txt
index 0356d25..944fc39 100644
--- a/Documentation/technical/api-directory-listing.txt
+++ b/Documentation/technical/api-directory-listing.txt
@@ -9,8 +9,11 @@ Data structure
--
`struct dir_struct` structure is used to pass directory traversal
-options to the library and to record the paths discovered. The notable
-options are:
+options to the library and to record the paths discovered. A single
+`struct dir_struct` is used regardless of whether or not the traversal
+recursively descends into subdirectories.
I am somewhat lukewarm on this part of the change.
The added regardless of... does not seem to add as much value as
the two extra lines the patch spends. If we say something like:
A `struct dir_struct` structure is used to pass options to
traverse directories recursively, and to record all the
paths discovered by the traversal.
it might be much more direct and informative, I suspect, though.
After all, the word traversal pretty much implies that the library
goes in and out of the directories recursively.
@@ -39,7 +42,7 @@ options are:
If set, recurse into a directory that looks like a git
directory. Otherwise it is shown as a directory.
-The result of the enumeration is left in these fields::
+The result of the enumeration is left in these fields:
Good eyes.
diff --git a/dir.c b/dir.c
index ee8e711..89e27a6 100644
--- a/dir.c
+++ b/dir.c
@@ -2,6 +2,8 @@
* This handles recursive filename detection with exclude
* files, index knowledge etc..
*
+ * See Documentation/technical/api-directory-listing.txt
+ *
* Copyright (C) Linus Torvalds, 2005-2006
*Junio Hamano, 2005-2006
*/
@@ -476,6 +478,10 @@ void add_excludes_from_file(struct dir_struct *dir,
const char *fname)
die(cannot use %s as an exclude file, fname);
}
+/*
+ * Loads the per-directory exclude list for the substring of base
+ * which has a char length of baselen.
+ */
static void prep_exclude(struct dir_struct *dir, const char *base, int
baselen)
{
struct exclude_list *el;
@@ -486,7 +492,7 @@ static void prep_exclude(struct dir_struct *dir, const
char *base, int baselen)
(baselen + strlen(dir-exclude_per_dir) = PATH_MAX))
return; /* too long a path -- ignore */
- /* Pop the ones that are not the prefix of the path being checked. */
+ /* Pop the directories that are not the prefix of the path being
checked. */
The one does not refer to a directory, but to an exclude-list.
Pop the ones that are not for parent directories of the path
being checked
perhaps?
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git filter-branch doesn't dereference annotated tags
Grégory Pakosz gpak...@visionobjects.com writes: Are you suggesting $sha1 should be obtained differently before entering case $rewritten ? That would mean changing sha1=$(git rev-parse $ref^0) at line 376 to something like $(git cat-file -t $ref) = 'tag' sha1=$(git rev-parse $ref) || sha1=$(git rev-parse $ref^0) ? I was wondering if it should be sha1=$(git rev-parse --verify $ref) or something that does not dereference a tag at all. The way I read what that loop seems to want to do is: Read each refname that was given originally from the file $tempdir/heads, find out the object it used to refer to and have it in $sha1, find out what new object the object was rewritten to and have it in $rewritten, and: (1) if the rewrite left the object unchanged, do nothing but warn users just in case this was a mistake; (2) if the rewrite told us to remove it, then delete the ref; or (3) if the rewrite gave us a new object, replace the ref to point to that new one. And in the latter two cases, save the original one in $orig_namespace so that the user can choose to recover if this filter-branch was done by mistake. So I do not think unwraping the ref at that point makes any sense, unless it is not prepared to handle annotated tags at all by unwrapping tags too early. What am I missing? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Documentation: full-ness of a bundle is significant for cloning
Not necessarily every bundle file can be cloned from. Only the ones that do not need prerequisites can. When 1d52b02 (Documentation: minor grammatical fixes and rewording in git-bundle.txt, 2009-03-22) reworded this paragraph, it lost a critical hint to tell readers why thhis particular bundle can be cloned from. Resurrect it. Signed-off-by: Junio C Hamano gits...@pobox.com --- * As I noticed this while I was looking at Kirill's patch... Documentation/git-bundle.txt | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/Documentation/git-bundle.txt b/Documentation/git-bundle.txt index 5c8ba44..bc023cc 100644 --- a/Documentation/git-bundle.txt +++ b/Documentation/git-bundle.txt @@ -112,10 +112,9 @@ machineA$ git bundle create file.bundle master machineA$ git tag -f lastR2bundle master -Then you transfer file.bundle to the target machine B. If you are creating -the repository on machine B, then you can clone from the bundle as if it -were a remote repository instead of creating an empty repository and then -pulling or fetching objects from the bundle: +Then you transfer file.bundle to the target machine B. Because this +bundle does not require any existing object to be extracted, you can +create a new repository on machine B by cloning from it: machineB$ git clone -b master /home/me/tmp/file.bundle R2 -- 1.8.1.209.gc32ab23 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Avoid using non-POSIX cp options
t/3600-rm was using the -a option to cp. This option is a GNU extention and is not portable. Instead, use just -R (no -p necessary). Signed-off-by: Ben Walton bdwal...@gmail.com --- t/t3600-rm.sh |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/t/t3600-rm.sh b/t/t3600-rm.sh index 06f6384..37bf5f1 100755 --- a/t/t3600-rm.sh +++ b/t/t3600-rm.sh @@ -474,7 +474,7 @@ test_expect_success 'rm of a conflicted populated submodule with a .git director git submodule update (cd submod rm .git - cp -a ../.git/modules/sub .git + cp -R ../.git/modules/sub .git GIT_WORK_TREE=. git config --unset core.worktree ) test_must_fail git merge conflict2 @@ -508,7 +508,7 @@ test_expect_success 'rm of a populated submodule with a .git directory fails eve git submodule update (cd submod rm .git - cp -a ../.git/modules/sub .git + cp -R ../.git/modules/sub .git GIT_WORK_TREE=. git config --unset core.worktree ) test_must_fail git rm submod @@ -606,7 +606,7 @@ test_expect_success 'rm of a populated nested submodule with a nested .git direc git submodule update --recursive (cd submod/subsubmod rm .git - cp -a ../../.git/modules/sub/modules/sub .git + cp -R ../../.git/modules/sub/modules/sub .git GIT_WORK_TREE=. git config --unset core.worktree ) test_must_fail git rm submod -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/8] Add --unannotate
David A. Greene gree...@obbligato.org writes: From: James Nylen jny...@gmail.com Teach git-subtree about --unannotate. This option strips a prefix from a commit message when doing a subtree split. Hrm. This looks like a workaround for a short-sighted misdesign of the annotate option that only allowed prefixing a fixed string. I have to wonder if it is better to deprecate --annotate and replace it with a more general commit log rewriting facility that can cover both use cases? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/8] Better Error Handling for add
David A. Greene gree...@obbligato.org writes:
From: David A. Greene gree...@obbligato.org
Check refspecs for validity before passing them on to other commands.
This lets us generate more helpful error messages.
Signed-off-by: David A. Greene gree...@obbligato.org
---
contrib/subtree/git-subtree.sh | 12
1 file changed, 12 insertions(+)
diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
index 7ceb413..b8a807a 100755
--- a/contrib/subtree/git-subtree.sh
+++ b/contrib/subtree/git-subtree.sh
@@ -509,8 +509,20 @@ cmd_add()
ensure_clean
if [ $# -eq 1 ]; then
+ ref=$(git check-ref-format --normalize refs/heads/$1) ||
+die '$1' is not a valid refspec. Are you missing a branch?
Is a user forbidden from passing a commit that is not at the tip of
an existing branch? In other words, is
$ subtree add origin/next~4^2
forbidden?
+ rev=$(git rev-parse --verify $1) ||
+die '$1' is not a valid refspec. Are you missing a branch?
+
cmd_add_commit $@
If you want to make sure you give a comit to add_commit, you can
probably say something like this:
git rev-parse -q --verify $1^{commit} /dev/null ||
die '$1' does not refer to a commit
elif [ $# -eq 2 ]; then
+ ref=$(git check-ref-format --normalize refs/heads/$2) ||
+die '$2' is not a valid refspec.
+
+ rev=$(git rev-parse --verify $2) ||
+die '$2' is not a valid refspec.
+
Likewise.
cmd_add_repository $@
else
say error: parameters were '$@'
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] test: Add target test-lint-shell-syntax
Add the perl script check-non-portable-shell.pl to detect non-portable
shell syntax
Many systems use gnu tools which accept an extended syntax in shell scripts,
which is not portable on all systems and causes the test suite to fail.
To prevent contributors using e.g. Linux to add non-portable test code,
check-non-portable-shell.pl is run as part of
make test or make in the t/ directory.
echo -n is an example of a statement working on Linux,
but not on e.g. Mac OS X.
Beside echo -n we check for
sed -i,
arrays in shell scripts (declare statement),
which (use type instead),
or == (bash style of =)
Signed-off-by: Torsten Bögershausen tbo...@web.de
---
t/Makefile| 7 +++--
t/check-non-portable-shell.pl | 67 +++
2 files changed, 72 insertions(+), 2 deletions(-)
create mode 100755 t/check-non-portable-shell.pl
diff --git a/t/Makefile b/t/Makefile
index 88e289f..7b0c4dc 100644
--- a/t/Makefile
+++ b/t/Makefile
@@ -23,7 +23,7 @@ TGITWEB = $(sort $(wildcard t95[0-9][0-9]-*.sh))
all: $(DEFAULT_TEST_TARGET)
-test: pre-clean $(TEST_LINT)
+test: pre-clean test-lint-shell-syntax $(TEST_LINT)
$(MAKE) aggregate-results-and-cleanup
prove: pre-clean $(TEST_LINT)
@@ -43,7 +43,7 @@ clean-except-prove-cache:
clean: clean-except-prove-cache
$(RM) .prove
-test-lint: test-lint-duplicates test-lint-executable
+test-lint: test-lint-duplicates test-lint-executable test-lint-shell-syntax
test-lint-duplicates:
@dups=`echo $(T) | tr ' ' '\n' | sed 's/-.*//' | sort | uniq -d` \
@@ -55,6 +55,9 @@ test-lint-executable:
test -z $$bad || { \
echo 2 non-executable tests: $$bad; exit 1; }
+test-lint-shell-syntax:
+ $(PERL_PATH) check-non-portable-shell.pl $(T)
+
aggregate-results-and-cleanup: $(T)
$(MAKE) aggregate-results
$(MAKE) clean
diff --git a/t/check-non-portable-shell.pl b/t/check-non-portable-shell.pl
new file mode 100755
index 000..de62ef0
--- /dev/null
+++ b/t/check-non-portable-shell.pl
@@ -0,0 +1,67 @@
+#!/usr/bin/perl -w
+##
+# Test t..t.sh for non portable shell scripts#
+# Examples are echo -n or sed -i #
+# This script can be called with one or more filenames as parameters #
+#
+##
+use strict;
+my $exitcode=0;
+
+sub check_one_file($) {
+ my $lineno=1;
+ my $filename=shift;
+
+ open(FINPUT, $filename) || die Couldn't open filename $filename;
+ my @fdata = FINPUT;
+ close(FINPUT);
+
+ while (my $line = shift @fdata) {
+do {
+ chomp $line;
+ # sed -i
+ if ($line =~ /^\s*sed\s+-i/) {
+printf(%s:%d:error: \sed -i not portable\ %s\n, $filename,
$lineno, $line);
+ $exitcode=1;
+ }
+ # echo -n
+ if ($line =~ /^\s*echo\s+-n/) {
+printf(%s:%d:error: \echo -n not portable\ %s\n, $filename,
$lineno, $line);
+ $exitcode=1;
+ }
+ # arrays (declare statement)
+ if ($line =~ /^\s*declare\s+/) {
+printf(%s:%d:error: \arrays/declare not portable\ %s\n, $filename,
$lineno, $line);
+ $exitcode=1;
+ }
+ # which
+ if ($line =~ /^\s*[^#]\s*which\s/) {
+printf(%s:%d:error: \which is not portable (use type)\ %s\n,
$filename, $lineno, $line);
+ $exitcode=1;
+ }
+
+ # == (bash style comparison)
+ if ($line =~ /test\s+[^=]*==/) {
+printf(%s:%d:error: \== is not portable (use =)\ %s\n, $filename,
$lineno, $line);
+ $exitcode=1;
+ }
+
+ $lineno=$lineno+1;
+ }
+ }
+}
+
+
+if ($#ARGV = 0) {
+ print STDERR $0: Check shell scripts for non portable syntax\n;
+ print STDERR Example: $0 t[0-9]*.sh\n;
+
+ exit(2);
+}
+
+while (@ARGV) {
+ my $arg = shift @ARGV;
+ check_one_file($arg);
+}
+
+exit($exitcode);
--
1.8.0.197.g5a90748
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/8] Fix Synopsis
David A. Greene gree...@obbligato.org writes: From: David A. Greene gree...@obbligato.org Fix the documentation of add to show that a repository can be specified along with a commit. Change commit to refspec in the synopsis for add. Suggested by Yann Dirson dir...@bertin.fr. Signed-off-by: David A. Greene gree...@obbligato.org --- contrib/subtree/git-subtree.sh |3 ++- contrib/subtree/git-subtree.txt |3 ++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh index b8a807a..ad62dfb 100755 --- a/contrib/subtree/git-subtree.sh +++ b/contrib/subtree/git-subtree.sh @@ -8,7 +8,8 @@ if [ $# -eq 0 ]; then set -- -h fi OPTS_SPEC=\ -git subtree add --prefix=prefix commit +git subtree add --prefix=prefix refspec Again, this is not refspec but commit. +git subtree add --prefix=prefix repository refspec This is given to fetch and it seems to acccept any refspec, so it is probably a good change (I didn't fully follow the codepath, though). git subtree merge --prefix=prefix commit git subtree pull --prefix=prefix repository refspec... git subtree push --prefix=prefix repository refspec... diff --git a/contrib/subtree/git-subtree.txt b/contrib/subtree/git-subtree.txt index ae420aa..89c2d6e 100644 --- a/contrib/subtree/git-subtree.txt +++ b/contrib/subtree/git-subtree.txt @@ -9,7 +9,8 @@ git-subtree - Merge subtrees together and split repository into subtrees SYNOPSIS [verse] -'git subtree' add -P prefix commit +'git subtree' add -P prefix refspec +'git subtree' add -P prefix repository refspec 'git subtree' pull -P prefix repository refspec... 'git subtree' push -P prefix repository refspec... 'git subtree' merge -P prefix commit -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] t9810: Do not use sed -i
sed -i is not portable on all systems. Use sed with different input and output files. Utilize a tmp file whenever needed Signed-off-by: Torsten Bögershausen tbo...@web.de --- t/t9810-git-p4-rcs.sh | 24 ++-- 1 file changed, 14 insertions(+), 10 deletions(-) diff --git a/t/t9810-git-p4-rcs.sh b/t/t9810-git-p4-rcs.sh index 0c2fc3e..5bf9291 100755 --- a/t/t9810-git-p4-rcs.sh +++ b/t/t9810-git-p4-rcs.sh @@ -26,10 +26,8 @@ test_expect_success 'init depot' ' line7 line8 EOF - cp filek fileko - sed -i s/Revision/Revision: do not scrub me/ fileko - cp fileko file_text - sed -i s/Id/Id: do not scrub me/ file_text + sed filek s/Revision/Revision: do not scrub me/ fileko + sed fileko s/Id/Id: do not scrub me/ file_text p4 add -t text+k filek p4 submit -d filek p4 add -t text+ko fileko @@ -88,7 +86,8 @@ test_expect_success 'edit far away from RCS lines' ' ( cd $git git config git-p4.skipSubmitEdit true - sed -i s/^line7/line7 edit/ filek + sed filek s/^line7/line7 edit/ filek.tmp + mv -f filek.tmp filek git commit -m filek line7 edit filek git p4 submit scrub_k_check filek @@ -105,7 +104,8 @@ test_expect_success 'edit near RCS lines' ' cd $git git config git-p4.skipSubmitEdit true git config git-p4.attemptRCSCleanup true - sed -i s/^line4/line4 edit/ filek + sed filek s/^line4/line4 edit/ filek.tmp + mv -f filek.tmp filek git commit -m filek line4 edit filek git p4 submit scrub_k_check filek @@ -122,7 +122,8 @@ test_expect_success 'edit keyword lines' ' cd $git git config git-p4.skipSubmitEdit true git config git-p4.attemptRCSCleanup true - sed -i /Revision/d filek + sed filek /Revision/d filek.tmp + mv -f filek.tmp filek git commit -m filek remove Revision line filek git p4 submit scrub_k_check filek @@ -139,7 +140,8 @@ test_expect_success 'scrub ko files differently' ' cd $git git config git-p4.skipSubmitEdit true git config git-p4.attemptRCSCleanup true - sed -i s/^line4/line4 edit/ fileko + sed fileko s/^line4/line4 edit/ fileko.tmp + mv -f fileko.tmp fileko git commit -m fileko line4 edit fileko git p4 submit scrub_ko_check fileko @@ -189,12 +191,14 @@ test_expect_success 'do not scrub plain text' ' cd $git git config git-p4.skipSubmitEdit true git config git-p4.attemptRCSCleanup true - sed -i s/^line4/line4 edit/ file_text + sed file_text s/^line4/line4 edit/ file_text.tmp + mv -f file_text.tmp file_text git commit -m file_text line4 edit file_text ( cd $cli p4 open file_text - sed -i s/^line5/line5 p4 edit/ file_text + sed file_text s/^line5/line5 p4 edit/ file_text.tmp + mv -f file_text.tmp file_text p4 submit -d file5 p4 edit ) echo s | test_expect_code 1 git p4 submit -- 1.8.0.197.g5a90748 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] t4014: do not uese echo -n
echo -n is not portable on all systems. Use printf instead Signed-off-by: Torsten Bögershausen tbo...@web.de --- t/t4014-format-patch.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh index 6cfad13..f460930 100755 --- a/t/t4014-format-patch.sh +++ b/t/t4014-format-patch.sh @@ -993,7 +993,7 @@ EOF ' test_expect_success 'signoff: commit with only subject that does not end with NL' ' - echo -n subject | append_signoff actual + printf subject | append_signoff actual cat expected \EOF 4:Subject: [PATCH] subject 8: -- 1.8.0.197.g5a90748 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] t9020: which is not portable
Use type instead Signed-off-by: Torsten Bögershausen tbo...@web.de --- t/t9020-remote-svn.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/t/t9020-remote-svn.sh b/t/t9020-remote-svn.sh index 4f2dfe0..dbaecbc 100755 --- a/t/t9020-remote-svn.sh +++ b/t/t9020-remote-svn.sh @@ -32,8 +32,8 @@ fi test_debug ' git --version - which git - which svnrdump + type git + type svnrdump ' test_expect_success REMOTE_SVN 'simple fetch' ' -- 1.8.0.197.g5a90748 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] t9020: which is not portable
Use type instead Signed-off-by: Torsten Bögershausen tbo...@web.de --- t/t9020-remote-svn.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/t/t9020-remote-svn.sh b/t/t9020-remote-svn.sh index 4f2dfe0..dbaecbc 100755 --- a/t/t9020-remote-svn.sh +++ b/t/t9020-remote-svn.sh @@ -32,8 +32,8 @@ fi test_debug ' git --version - which git - which svnrdump + type git + type svnrdump ' test_expect_success REMOTE_SVN 'simple fetch' ' -- 1.8.0.197.g5a90748 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/8] Make the Manual Directory if Needed
David A. Greene gree...@obbligato.org writes: From: Jesper L. Nielsen lya...@gmail.com Before install git-subtree documentation, make sure the manpage directory exists. Author:Jesper L. Nielsen lya...@gmail.com Signed-off-by:Jesper L. Nielsen lya...@gmail.com Signed-off-by: David A. Greene gree...@obbligato.org --- contrib/subtree/Makefile |1 + 1 file changed, 1 insertion(+) diff --git a/contrib/subtree/Makefile b/contrib/subtree/Makefile index 36ae3e4..52d6fb9 100644 --- a/contrib/subtree/Makefile +++ b/contrib/subtree/Makefile @@ -35,6 +35,7 @@ install: $(GIT_SUBTREE) install-doc: install-man install-man: $(GIT_SUBTREE_DOC) + mkdir -p $(man1dir) We seem to use $(INSTALL) -d -m 755 for this kind of thing (see the Documentation/Makefile). $(INSTALL) -m 644 $^ $(DESTDIR)$(man1dir) $(GIT_SUBTREE_DOC): $(GIT_SUBTREE_XML) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/8] Ignore git-subtree
David A. Greene gree...@obbligato.org writes: From: Michael Schubert msc...@elegosoft.com Add the git-subtree command executable to .gitignore. Author:Michael Schubert msc...@elegosoft.com Signed-off-by:Michael Schubert msc...@elegosoft.com Signed-off-by: David A. Greene gree...@obbligato.org --- Seems sensible; I think I have this already in my tree. contrib/subtree/.gitignore |1 + 1 file changed, 1 insertion(+) diff --git a/contrib/subtree/.gitignore b/contrib/subtree/.gitignore index 7e77c9d..91360a3 100644 --- a/contrib/subtree/.gitignore +++ b/contrib/subtree/.gitignore @@ -1,4 +1,5 @@ *~ +git-subtree git-subtree.xml git-subtree.1 mainline -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Replace git-cvsimport with a rewrite that fixes major bugs.
Eric S. Raymond e...@thyrsus.com writes: The combination of git-cvsimport and cvsps had serious problems. Among these were: (1) Analysis of branchy repos was buggy in multiple ways in both programs, leading to incorrect repo translations. (2) Even after a correct branch analysis, extra (redundant) fileops would often be generated on the new-branch side. (3) Inability to report more than one tag pointing to the same revision. (4) Failure in certain cases of clock-skew reported by the t9603 test. (5) Failure to use commitids for changeset ordering in cases were this would have prevented clock skew from causing incorrect grouping. Problems 2-5 and portions of problem 1 have been solved by a major rewrite of cvsps (the 3.x release series); it now emits a git fast-import stream. So..., is this a flag-day patch? After this is merged, users who have been interoperating with CVS repositories with the older cvsps have to install the updated cvsps before using a new version of Git that ships with it? As long as they update both cvsps and cvsimport, they can continue using the existing repository to get updates from the same upstream CVS repository without losing hisory continuity? I would have preferred an addition of git cvsimport-new (or rename of the existing one to git cvsimport-old), with additional tests that compare the results of these two implemenations on simple CVS history that cvsimport-old did *not* screw up, to ensure that (1) people with existing set-up can choose to keep using the old one, perhaps by tweaking their process to use cvsimport-old, and (2) the updated one will give these people the identical conversion results, as long as the history they have been interacting with do not have the corner cases that trigger bugs in older cvsps. Or am I being too conservative? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Avoid using non-POSIX cp options
Thanks; I think I already have 2d3ac9a (t3600: Avoid cp -a, which is a GNUism, 2012-12-18) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] test: Add target test-lint-shell-syntax
Torsten Bögershausen tbo...@web.de writes: Add the perl script check-non-portable-shell.pl to detect non-portable shell syntax Many systems use gnu tools which accept an extended syntax in shell scripts, which is not portable on all systems and causes the test suite to fail. To prevent contributors using e.g. Linux to add non-portable test code, check-non-portable-shell.pl is run as part of make test or make in the t/ directory. echo -n is an example of a statement working on Linux, but not on e.g. Mac OS X. Beside echo -n we check for sed -i, arrays in shell scripts (declare statement), which (use type instead), or == (bash style of =) Signed-off-by: Torsten Bögershausen tbo...@web.de What it checks looks like a good start, but the indentation of it (and the log message) seems very screwed up. I also have to wonder what's the false positive rate of this. When you are preparing a new test, you would ideally want a mode that checks only parts that you just added, without seeing noises from existing violations and false positives from the part you did not touch. Otherwise, it will be too cumbersome to run for developers, and the check mechanism will end up used by nobody. +## +# Test t..t.sh for non portable shell scripts# +# Examples are echo -n or sed -i # +# This script can be called with one or more filenames as parameters # +# +## Just a style thing (style requests are not optional, though ;-), but these box comments are moderately annoying to read and extremely annoying to modify. Writing it like this: +# +# Test t..t.sh for non portable shell scripts +# Examples are echo -n or sed -i +# This script can be called with one or more filenames as parameters +# should be sufficiently loud. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation: full-ness of a bundle is significant for cloning
On Tue, Jan 01, 2013 at 01:07:05PM -0800, Junio C Hamano wrote: critical hint to tell readers why thhis particular bundle can be s/thhis/this/ signature.asc Description: OpenPGP digital signature
Re: [PATCH 2/4] t9810: Do not use sed -i
Torsten Bögershausen tbo...@web.de writes: sed -i is not portable on all systems. Use sed with different input and output files. Utilize a tmp file whenever needed Signed-off-by: Torsten Bögershausen tbo...@web.de --- t/t9810-git-p4-rcs.sh | 24 ++-- 1 file changed, 14 insertions(+), 10 deletions(-) diff --git a/t/t9810-git-p4-rcs.sh b/t/t9810-git-p4-rcs.sh index 0c2fc3e..5bf9291 100755 --- a/t/t9810-git-p4-rcs.sh +++ b/t/t9810-git-p4-rcs.sh @@ -26,10 +26,8 @@ test_expect_success 'init depot' ' line7 line8 EOF - cp filek fileko - sed -i s/Revision/Revision: do not scrub me/ fileko - cp fileko file_text - sed -i s/Id/Id: do not scrub me/ file_text + sed filek s/Revision/Revision: do not scrub me/ fileko + sed fileko s/Id/Id: do not scrub me/ file_text Making it shorter and more correct ;-), which is good, but you are losing the chaining. Also it is more customary to have redirection at the end, unless it is to redirect a numbered file descriptor (e.g. echo 2 error message). I.e. sed s/Revision/Revision: do not scrub me/ filek fileko sed s/Id/Id: do not scrub me/ fileko file_text -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] two-way read-tree can write null sha1s into index
Jeff King p...@peff.net writes: So I think we need to update twoway_merge to recognize unmerged entries, which gives us two options: 1. Reject the merge. 2. Throw away the current unmerged entry in favor of the new entry (when old and new are the same, of course; otherwise we would reject). I think (2) is the right thing. As --reset in read-tree --reset -u A B is a way to say we know we are based on A and we want to go to B no matter what, I agree we should not reject the merge. With -m instead of --reset, I am not sure what the right semantics should be, though. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/8] Use %B for Split Subject/Body
Junio C Hamano gits...@pobox.com writes: David A. Greene gree...@obbligato.org writes: From: Techlive Zheng techlivezh...@gmail.com Use %B to format the commit message and body to avoid an extra newline if a commit only has a subject line. Is this an unconditional improvement, or is it generally an improvement but for some users it may be a regression? I am guessing it is the former but am just making sure. The former. Author:Techlive Zheng techlivezh...@gmail.com Signed-off-by: David A. Greene gree...@obbligato.org Please don't do Author: which does not add anything new. That is what From: is for. Instead it needs to be a sign-off. Ok. Unfortunately I sent a number of patches like that. Do you want me to re-send them? Also, is that a real name, I have to wonder? No idea. Not likely, I'd say. -David -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/8] Use %B for Split Subject/Body
Junio C Hamano gits...@pobox.com writes: Also, please be careful about the subject line. I doubt that these 8 patches will stand out as relating to contrib/subtree, when mixed in 200 line output of git shortlog --no-merges. Ah, ok. I'll be more careful next time. -David -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/8] Use %B for Split Subject/Body
Junio C Hamano gits...@pobox.com writes: David A. Greene gree...@obbligato.org writes: Subject: Re: [PATCH 1/8] Use %B for Split Subject/Body This needs to say contrib/subtree somewhere (applies to all patches in this series). Ok. Shall I re-send everything? From: Techlive Zheng techlivezh...@gmail.com Use %B to format the commit message and body to avoid an extra newline if a commit only has a subject line. Author:Techlive Zheng techlivezh...@gmail.com This needs to be a S-o-b instead; is it a real name, by the way? Ok. No idea about the name but his online presence seems consistent at least. +# Save this hash for testing later. + +subdir_hash=`git rev-parse HEAD` + We prefer $() over ``; much more readable. Ack, of course. I don't know how I missed that. # 15 test_expect_success 'add main6' ' create main6 Why? It was in the original testsuite from Avery. I didn't add or remove any tests when I first integrated git-subtree. @@ -235,7 +238,19 @@ test_expect_success 'check split with --branch' ' check_equal ''$(git rev-parse splitbr1)'' $spl1 Is quoting screwed up around here (and in many other places in this patch)? What are these no-op '' doing? I assumed they are there to get the double-quotes around the command. I'll see about removing them. -# 25 +#25 Why the lossage of a SP? I think this got fixed later in the series. It may make sense to lose these # num that will have to be touched every time somebody inserts new test pieces in the middle, as a preparatory step before any of these patches, by the way. That will reduce noise in the patches for real changes. Yeah, I know, but it makes it really easy to find a test when something goes wrong. -David -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/8] Add --unannotate
Junio C Hamano gits...@pobox.com writes: David A. Greene gree...@obbligato.org writes: From: James Nylen jny...@gmail.com Teach git-subtree about --unannotate. This option strips a prefix from a commit message when doing a subtree split. Hrm. This looks like a workaround for a short-sighted misdesign of the annotate option that only allowed prefixing a fixed string. I have to wonder if it is better to deprecate --annotate and replace it with a more general commit log rewriting facility that can cover both use cases? That's not a bad idea. I'd have to think a bit about a sensible design. Do you have any ideas, James? In the meantime, will you apply the patch or do you prefer a new design? -David -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/8] Better Error Handling for add
Junio C Hamano gits...@pobox.com writes:
diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
index 7ceb413..b8a807a 100755
--- a/contrib/subtree/git-subtree.sh
+++ b/contrib/subtree/git-subtree.sh
@@ -509,8 +509,20 @@ cmd_add()
ensure_clean
if [ $# -eq 1 ]; then
+ref=$(git check-ref-format --normalize refs/heads/$1) ||
+die '$1' is not a valid refspec. Are you missing a
branch?
Is a user forbidden from passing a commit that is not at the tip of
an existing branch? In other words, is
$ subtree add origin/next~4^2
forbidden?
Good point. It probably shouldn't be. I think rev-parse should be
enough of a check.
+rev=$(git rev-parse --verify $1) ||
+die '$1' is not a valid refspec. Are you missing a
branch?
+
cmd_add_commit $@
If you want to make sure you give a comit to add_commit, you can
probably say something like this:
git rev-parse -q --verify $1^{commit} /dev/null ||
die '$1' does not refer to a commit
What does $1^{commit} mean? I think your suggestion is what I want but
I don't know what it means yet. :)
-David
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/8] Fix Synopsis
Junio C Hamano gits...@pobox.com writes: -git subtree add --prefix=prefix commit +git subtree add --prefix=prefix refspec Again, this is not refspec but commit. Ok, I need to study the terminology. :) +git subtree add --prefix=prefix repository refspec This is given to fetch and it seems to acccept any refspec, so it is probably a good change (I didn't fully follow the codepath, though). I think you are correct. -David -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/8] Honor DESTDIR
Junio C Hamano gits...@pobox.com writes: David A. Greene gree...@obbligato.org writes: From: Adam Tkac at...@redhat.com Teach git-subtree's Makefile to honor DESTDIR. Author:Adam Tkac at...@redhat.com Signed-off-by:Adam Tkac at...@redhat.com Signed-off-by: David A. Greene gree...@obbligato.org --- The contents of the patch looks sensible; the above is questionable as all the other messages in this series, though. Did any of our tools cause this failure? If so I would like to know more about it. What failure are you referring to? When I used git send-email --author, the Author: line was commented out. I assumed I was supposed to uncomment it. Guess I was wrong. I'll re-send the series since you pointed out a number of improvements. -David -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/8] Make the Manual Directory if Needed
Junio C Hamano gits...@pobox.com writes: diff --git a/contrib/subtree/Makefile b/contrib/subtree/Makefile index 36ae3e4..52d6fb9 100644 --- a/contrib/subtree/Makefile +++ b/contrib/subtree/Makefile @@ -35,6 +35,7 @@ install: $(GIT_SUBTREE) install-doc: install-man install-man: $(GIT_SUBTREE_DOC) +mkdir -p $(man1dir) We seem to use $(INSTALL) -d -m 755 for this kind of thing (see the Documentation/Makefile). Ok, will fix. -Dave -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2] t9810: Do not use sed -i
sed -i is not portable on all systems. Use sed with different input and output files. Utilize a tmp file whenever needed Added missing at 2 places Signed-off-by: Torsten Bögershausen tbo...@web.de --- Changes since v1: Use sed infile outfile Added missing at 2 places (thanks for catching) t/t9810-git-p4-rcs.sh | 24 ++-- 1 file changed, 14 insertions(+), 10 deletions(-) diff --git a/t/t9810-git-p4-rcs.sh b/t/t9810-git-p4-rcs.sh index 0c2fc3e..01a9921 100755 --- a/t/t9810-git-p4-rcs.sh +++ b/t/t9810-git-p4-rcs.sh @@ -26,10 +26,8 @@ test_expect_success 'init depot' ' line7 line8 EOF - cp filek fileko - sed -i s/Revision/Revision: do not scrub me/ fileko - cp fileko file_text - sed -i s/Id/Id: do not scrub me/ file_text + sed s/Revision/Revision: do not scrub me/ filek fileko + sed s/Id/Id: do not scrub me/ fileko file_text p4 add -t text+k filek p4 submit -d filek p4 add -t text+ko fileko @@ -88,7 +86,8 @@ test_expect_success 'edit far away from RCS lines' ' ( cd $git git config git-p4.skipSubmitEdit true - sed -i s/^line7/line7 edit/ filek + sed s/^line7/line7 edit/ filek filek.tmp + mv -f filek.tmp filek git commit -m filek line7 edit filek git p4 submit scrub_k_check filek @@ -105,7 +104,8 @@ test_expect_success 'edit near RCS lines' ' cd $git git config git-p4.skipSubmitEdit true git config git-p4.attemptRCSCleanup true - sed -i s/^line4/line4 edit/ filek + sed s/^line4/line4 edit/ filek filek.tmp + mv -f filek.tmp filek git commit -m filek line4 edit filek git p4 submit scrub_k_check filek @@ -122,7 +122,8 @@ test_expect_success 'edit keyword lines' ' cd $git git config git-p4.skipSubmitEdit true git config git-p4.attemptRCSCleanup true - sed -i /Revision/d filek + sed /Revision/d filek filek.tmp + mv -f filek.tmp filek git commit -m filek remove Revision line filek git p4 submit scrub_k_check filek @@ -139,7 +140,8 @@ test_expect_success 'scrub ko files differently' ' cd $git git config git-p4.skipSubmitEdit true git config git-p4.attemptRCSCleanup true - sed -i s/^line4/line4 edit/ fileko + sed fileko s/^line4/line4 edit/ fileko.tmp + mv -f fileko.tmp fileko git commit -m fileko line4 edit fileko git p4 submit scrub_ko_check fileko @@ -189,12 +191,14 @@ test_expect_success 'do not scrub plain text' ' cd $git git config git-p4.skipSubmitEdit true git config git-p4.attemptRCSCleanup true - sed -i s/^line4/line4 edit/ file_text + sed s/^line4/line4 edit/ file_text file_text.tmp + mv -f file_text.tmp file_text git commit -m file_text line4 edit file_text ( cd $cli p4 open file_text - sed -i s/^line5/line5 p4 edit/ file_text + sed s/^line5/line5 p4 edit/ file_text file_text.tmp + mv -f file_text.tmp file_text p4 submit -d file5 p4 edit ) echo s | test_expect_code 1 git p4 submit -- 1.8.0.197.g5a90748 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] Update SubmittingPatches
The main thing this series wants to do is the second one, but I wanted to reduce the clutter in this document while at it. Junio C Hamano (3): SubmittingPatches: who am I and who cares? SubmittingPatches: mention subsystems with dedicated repositories SubmittingPatches: remove overlong checklist Documentation/SubmittingPatches | 160 1 file changed, 79 insertions(+), 81 deletions(-) -- 1.8.1.209.gc32ab23 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] SubmittingPatches: who am I and who cares?
The introductory text in the long version talks about the origin of this document with I started ..., but it is unclear who that I is, and more importantly, it is not interesting how it was started. Just state the purpose of the document to help readers decide if it is releavant to them. Signed-off-by: Junio C Hamano gits...@pobox.com --- Documentation/SubmittingPatches | 10 ++ 1 file changed, 2 insertions(+), 8 deletions(-) diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index c34c9d1..b9fd182 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -60,14 +60,8 @@ Checklist (and a short version for the impatient): Long version: -I started reading over the SubmittingPatches document for Linux -kernel, primarily because I wanted to have a document similar to -it for the core GIT to make sure people understand what they are -doing when they write Signed-off-by line. - -But the patch submission requirements are a lot more relaxed -here on the technical/contents front, because the core GIT is -thousand times smaller ;-). So here is only the relevant bits. +Here are some guidelines for people who want to contribute their code +to this software. (0) Decide what to base your work on. -- 1.8.1.209.gc32ab23 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] SubmittingPatches: mention subsystems with dedicated repositories
These were only mentioned in periodical A note from the maintainer posting and not in the documentation suite. SubmittingPatches has a section to help contributors decide on what commit to base their changes, which is the most suitable place for this information. Signed-off-by: Junio C Hamano gits...@pobox.com --- Documentation/SubmittingPatches | 24 1 file changed, 24 insertions(+) diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index b9fd182..e810263 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -88,6 +88,10 @@ change is relevant to. wait until some of the dependent topics graduate to 'master', and rebase your work. + - Some parts of the system have dedicated maintainers with their own + repositories (see the section Subsystems below). Changes to + these parts should be based on their trees. + To find the tip of a topic branch, run git log --first-parent master..pu and look for the merge commit. The second parent of this commit is the tip of the topic branch. @@ -279,6 +283,26 @@ You can also create your own tag or use one that's in common usage such as Thanks-to:, Based-on-patch-by:, or Mentored-by:. +Subsystems with dedicated maintainers + +Some parts of the system have dedicated maintainers with their own +repositories. + + - git-gui/ comes from git-gui project, maintained by Pat Thoyts: + +git://repo.or.cz/git-gui.git + + - gitk-git/ comes from Paul Mackerras's gitk project: + +git://ozlabs.org/~paulus/gitk + + - po/ comes from the localization coordinator, Jiang Xin: + + https://github.com/git-l10n/git-po/ + +Patches to these parts should be based on their trees. + + An ideal patch flow Here is an ideal patch flow for this project the current maintainer -- 1.8.1.209.gc32ab23 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] SubmittingPatches: remove overlong checklist
The section is no longer a concise checklist. It also talks about things that are not covered in the Long version text, which means people need to read both, covering more or less the same thing in different phrasing. Fold the details into the main text and remove the section. Signed-off-by: Junio C Hamano gits...@pobox.com --- Documentation/SubmittingPatches | 126 +--- 1 file changed, 53 insertions(+), 73 deletions(-) diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index e810263..a7daad3 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -1,65 +1,3 @@ -Checklist (and a short version for the impatient): - - Commits: - - - make commits of logical units - - check for unnecessary whitespace with git diff --check - before committing - - do not check in commented out code or unneeded files - - the first line of the commit message should be a short - description (50 characters is the soft limit, see DISCUSSION - in git-commit(1)), and should skip the full stop - - it is also conventional in most cases to prefix the - first line with area: where the area is a filename - or identifier for the general area of the code being - modified, e.g. - . archive: ustar header checksum is computed unsigned - . git-cherry-pick.txt: clarify the use of revision range notation - (if in doubt which identifier to use, run git log --no-merges - on the files you are modifying to see the current conventions) - - the body should provide a meaningful commit message, which: - . explains the problem the change tries to solve, iow, what - is wrong with the current code without the change. - . justifies the way the change solves the problem, iow, why - the result with the change is better. - . alternate solutions considered but discarded, if any. - - describe changes in imperative mood, e.g. make xyzzy do frotz - instead of [This patch] makes xyzzy do frotz or [I] changed - xyzzy to do frotz, as if you are giving orders to the codebase - to change its behaviour. - - try to make sure your explanation can be understood without - external resources. Instead of giving a URL to a mailing list - archive, summarize the relevant points of the discussion. - - add a Signed-off-by: Your Name y...@example.com line to the - commit message (or just use the option -s when committing) - to confirm that you agree to the Developer's Certificate of Origin - - make sure that you have tests for the bug you are fixing - - make sure that the test suite passes after your commit - - Patch: - - - use git format-patch -M to create the patch - - do not PGP sign your patch - - do not attach your patch, but read in the mail - body, unless you cannot teach your mailer to - leave the formatting of the patch alone. - - be careful doing cut paste into your mailer, not to - corrupt whitespaces. - - provide additional information (which is unsuitable for - the commit message) between the --- and the diffstat - - if you change, add, or remove a command line option or - make some other user interface change, the associated - documentation should be updated as well. - - if your name is not writable in ASCII, make sure that - you send off a message in the correct encoding. - - send the patch to the list (git@vger.kernel.org) and the - maintainer (gits...@pobox.com) if (and only if) the patch - is ready for inclusion. If you use git-send-email(1), - please test it first by sending email to yourself. - - see below for instructions specific to your mailer - -Long version: - Here are some guidelines for people who want to contribute their code to this software. @@ -119,13 +57,52 @@ change, the approach taken by the change, and if relevant how this differs substantially from the prior version, are all good things to have. +Make sure that you have tests for the bug you are fixing. + +When adding a new feature, make sure that you have new tests to show +the feature triggers the new behaviour when it should, and to show the +feature does not trigger when it shouldn't. Also make sure that the +test suite passes after your commit. Do not forget to update the +documentation to describe the updated behaviour. + Oh, another thing. I am picky about whitespaces. Make sure your changes do not trigger errors with the sample pre-commit hook shipped in templates/hooks--pre-commit. To help ensure this does not happen, run git diff --check on your changes before you commit. +(2) Describe your changes well. + +The first line of the commit message should be a short description (50
Re: [RFC] pack-objects: compression level for non-blobs
Shawn Pearce spea...@spearce.org writes: How blobs are written is very different, Junio's implementation is strictly better than JGit's[1]. I do not think there can be a single ordering that is strictly better than any other one. The clump all objects in a delta family and write them width-first, starting from the base object may give you a reasonable trade-off for a result of normal repack, but if you repack (like I do) with very shallow --depth with wide --window to really get a tight pack, a delta may end up having too may uncles between it and its father, requiring a large seek to skip over all the uncles in order to grab the delta data, after you reconstitute the delta base object. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] test: Add target test-lint-shell-syntax
On 01.01.13 23:07, Junio C Hamano wrote: [snip] What it checks looks like a good start, but the indentation of it (and the log message) seems very screwed up. OK I also have to wonder what's the false positive rate of this. When you are preparing a new test, you would ideally want a mode that checks only parts that you just added, without seeing noises from existing violations and false positives from the part you did not touch. Otherwise, it will be too cumbersome to run for developers, and the check mechanism will end up used by nobody. The script found all problems which make the testsuite (unecessary) fail on Mac OS X. The false positive rate is currently 0% (otherwise I should not have send it to the list) The suggestion is to run it every time the test suite is run, at the begining. And it seems to be fast enough: $ time ./check-non-portable-shell.pl ../../git.master/t/t[0-9]*.sh real0m0.263s user0m0.239s sys 0m0.021s /Torsten -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/8] Use %B for Split Subject/Body
gree...@obbligato.org writes: Ack, of course. I don't know how I missed that. # 15 test_expect_success 'add main6' ' create main6 Why? It was in the original testsuite from Avery. I didn't add or remove any tests when I first integrated git-subtree. The question was about the lossage of the blank line, which does not seem to be related to what this patch wants to do. -# 25 +#25 Why the lossage of a SP? I think this got fixed later in the series. That is not a good excuse to introduce breakages in the first place, no? It may make sense to lose these # num that will have to be touched every time somebody inserts new test pieces in the middle, as a preparatory step before any of these patches, by the way. That will reduce noise in the patches for real changes. Yeah, I know, but it makes it really easy to find a test when something goes wrong. That is what t-*.sh -i is for, isn't it? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/8] Add --unannotate
gree...@obbligato.org writes: In the meantime, will you apply the patch or do you prefer a new design? The --unannotate option will become a baggage you will have to keep working until the end of time, if we applied it. I think it is not too uch a baggage, so it probably is OK. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Replace git-cvsimport with a rewrite that fixes major bugs.
Junio C Hamano gits...@pobox.com: So..., is this a flag-day patch? After this is merged, users who have been interoperating with CVS repositories with the older cvsps have to install the updated cvsps before using a new version of Git that ships with it? Yes, they must install an updated cvsps. But this is hardly a loss, as the old version was perilously broken. There was an error or typo in the branch-analysis code, dating from 2006 and possibly earlier, that meant that branch root points would almost always be attributed to parent patchsets one patchset earlier than they should have been. Shocked me when I found it - how was this missed for six years? Because of the way the analysis is done, this fundamental bug would also cause secondary damage like file changes near the root point getting attributed to the wrong branch. In fact, this is how I first spotted the problem; my test suite exhibited this symptom. And mind you this is on top of ancestry-branch tracking not working - two separate bugs that could interact in ways I'd really rather not think about. The bottom line is that every import of a branchy CVS repo with a pre-3.x version of cvsps is probably wrong. The old git-cvsimport code was doing its part to screw things up, too. At least three of the bugs on its manual page are problems I couldn't reproduce using a bare cvsps instance, even the old broken version. As long as they update both cvsps and cvsimport, they can continue using the existing repository to get updates from the same upstream CVS repository without losing hisory continuity? Yes, but in that case I would strongly advise re-importing the entire CVS history, as the portion analyzed with 2.2b1 and earlier versions of cvsps will almost certainly have been somewhat garbled if it contains any branches. I would have preferred an addition of git cvsimport-new (or rename of the existing one to git cvsimport-old), with additional tests that compare the results of these two implemenations on simple CVS history that cvsimport-old did *not* screw up, to ensure that (1) people with existing set-up can choose to keep using the old one, perhaps by tweaking their process to use cvsimport-old, and (2) the updated one will give these people the identical conversion results, as long as the history they have been interacting with do not have the corner cases that trigger bugs in older cvsps. Or am I being too conservative? I think you are being too conservative. This patch is *not* a mere feature upgrade. The branch-analysis bug I found three days ago is not a minor problem, it is a big ugly showstopper for any case beside the simplest linear histories. Only linear histories will not break. 'People with existing set-ups' should absolutely *not* 'keep using the old one'; we should yank that choice away from them and get the old cvsimport/cvsps pair out of use *as fast as possible*, because it silently mangles branchy imports. Accordingly, giving people the idea that it's OK to use old and new versions in parallel would be an extremely bad idea. I would go so far as to call it irresponsible. Here is what I have done to ease the transition: If you try to use old git-cvsimport with new cvsps, new cvsps will detect this and ship a message to stderr telling you to upgrade If you try to use new git-cvsimport with old cvsps, old cvsps will complain of an invalid argument and git-cvsimport will quit. As for testing...cvsps now has several dozen self-tests on five different CVS repositories, including improved versions of the t960[123] tests. I will keep developing these as I work on bringing parsecvs up to snuff. I don't think there is a lot of point in git-cvsimport having its own tests any more. If you read it I think you'll see why; it's a much thinner wrapper around the conversion engine(s) than it used to be. In particular, it no longer does its own protocol transactions to the CVS server. -- a href=http://www.catb.org/~esr/;Eric S. Raymond/a -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Replace git-cvsimport with a rewrite that fixes major bugs.
Eric S. Raymond e...@thyrsus.com writes: Junio C Hamano gits...@pobox.com: So..., is this a flag-day patch? After this is merged, users who have been interoperating with CVS repositories with the older cvsps have to install the updated cvsps before using a new version of Git that ships with it? Yes, they must install an updated cvsps. But this is hardly a loss, as the old version was perilously broken. There was an error or typo in the branch-analysis code, dating from 2006 and possibly earlier, that meant that branch root points would almost always be attributed to parent patchsets one patchset earlier than they should have been. Shocked me when I found it - how was this missed for six years? Would it be that not many people use branchy history in CVS, as merging there was s painful? Or am I being too conservative? I think you are being too conservative. This patch is *not* a mere feature upgrade. The branch-analysis bug I found three days ago is not a minor problem, it is a big ugly showstopper for any case beside the simplest linear histories. Only linear histories will not break. That is exactly my point. It never worked in a branchy history, and that is an indication that people who didn't complain and used the old cvsimport with branch-incapable cvsps happily would have been working with a linear history. Either nobody uses cvsimport in the daily work, in which case a flag-day is perfectly fine, or we will have many people who are forced to update to unproven version for no immediate upside because the upstream repositories they work with, or options they use cvsimport, do not trigger the multi-branch bug. I however do understand that updating is the only sensible thing to do for them *in the longer term*, as older cvsimport and cvsps are no longer maintained, and sooner they update the better the chance the new cvsimport becomes perfect earlier. 'People with existing set-ups' should absolutely *not* 'keep using the old one'; we should yank that choice away from them and get the old cvsimport/cvsps pair out of use *as fast as possible*, because it silently mangles branchy imports. I still am not convinced, especially without a we make sure we do not regress in linear histories side-by-side test in place. That sounds irresponsible. But others may disagree, and I'd have to sleep on it. I'd prefer to hear from somebody who is *not* defending on his newer implementation, but from somebody who is actively using cvsimport as an end user. On the end-users' side, there always is this anxiety that a radical rewrite will always introduce new bugs, even when they know the rewrite is done very competently. Here is what I have done to ease the transition: If you try to use old git-cvsimport with new cvsps, new cvsps will detect this and ship a message to stderr telling you to upgrade Sounds sensible. If you try to use new git-cvsimport with old cvsps, old cvsps will complain of an invalid argument and git-cvsimport will quit. With an error message that tells the user to update cvsps, this also sounds sensible. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Makefile dependency from 'configure' to 'GIT-VERSION-FILE'
Hi,
I use autoconf with git.git. I have noticed lately, especially when
doing things like git rebase -i --exec make, that ./configure is run
every time. If I understand correctly, this is because of 8242ff4
(build: reconfigure automatically if configure.ac changes,
2012-07-19). Just a few days before that commit, on 2012-07-15, the
branch jn/makefile-cleanup including 520a6cd (Makefile: move
GIT-VERSION-FILE dependencies closer to use, 2012-06-20) was merged
(to next?). I wonder if these two subjects were aware of each other.
The reason 'configure' depends on GIT-VERSION-FILE is because it
inserts the version into the call to AC_INIT. I have close to no
experience with autoconf or even make and it's not at all clear to me
why we need to pass the verison to AC_INIT. It seems like it's just
for messages printed by ./configure. If that's the case, we shouldn't
need to generate a new 'configure' file ever time. At the very least,
we shouldn't need to run it.
Do you think we should simply remove the dependency from 'configure'
to 'GIT-VERSION-FILE' and leave a comment there instead? Or should we
instead somehow make 'reconfigure' depend only on 'configure.ac'? Both
of these feel a little wrong to me, because they would remove real
dependencies. Maybe the (probably mangled) patch at the end of this
message is better?
Martin
diff --git a/Makefile b/Makefile
index 736ecd4..ec5d7ca 100644
--- a/Makefile
+++ b/Makefile
@@ -2267,12 +2267,9 @@ $(patsubst %.py,%,$(SCRIPT_PYTHON)): % : unimplemented.sh
mv $@+ $@
endif # NO_PYTHON
-configure: configure.ac GIT-VERSION-FILE
- $(QUIET_GEN)$(RM) $@ $+ \
- sed -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
- $ $+ \
- autoconf -o $@ $+ \
- $(RM) $+
+configure: configure.ac
+ $(QUIET_GEN)$(RM) $@ \
+ autoconf -o $@ $
ifdef AUTOCONFIGURED
config.status: configure
diff --git a/configure.ac b/configure.ac
index ad215cc..00c3e38 100644
--- a/configure.ac
+++ b/configure.ac
@@ -142,7 +142,10 @@ fi
## Configure body starts here.
AC_PREREQ(2.59)
-AC_INIT([git], [@@GIT_VERSION@@], [git@vger.kernel.org])
+AC_INIT([git],
+ m4_esyscmd([ ./GIT-VERSION-GEN
+{ sed -ne 's/GIT_VERSION = //p' GIT-VERSION-FILE
| xargs echo -n; } ]),
+ [git@vger.kernel.org])
AC_CONFIG_SRCDIR([git.c])
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] t4014: do not uese echo -n
Torsten Bögershausen tbo...@web.de writes: echo -n is not portable on all systems. Use printf instead Signed-off-by: Torsten Bögershausen tbo...@web.de --- Brandon, this comes from 932581b (Unify appending signoff in format-patch, commit and sequencer, 2012-11-25). Please make sure to squash it in when you reroll the series. Thanks (and a happy new year ;-). t/t4014-format-patch.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh index 6cfad13..f460930 100755 --- a/t/t4014-format-patch.sh +++ b/t/t4014-format-patch.sh @@ -993,7 +993,7 @@ EOF ' test_expect_success 'signoff: commit with only subject that does not end with NL' ' - echo -n subject | append_signoff actual + printf subject | append_signoff actual cat expected \EOF 4:Subject: [PATCH] subject 8: -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] format-patch: pick up branch description when no ref is specified
On Wed, Jan 2, 2013 at 3:38 AM, Junio C Hamano gits...@pobox.com wrote:
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
find_branch_name() fails to detect format-patch --cover-letter -3
where no command line arguments are given and HEAD is automatically
added.
Nicely spotted.
That is not the only case that takes this codepath, though.
$ git format-patch --cover-letter master..
will also give you the same (if you say it without .., which is
the more normal invocation of the command, then the caller already
know you meant the current branch and this function is not called).
And in that case you will have two tokens on cmdline.nr, one for
master.. to show where he bottom is, and the other for the
implied HEAD;
Interesting. find_brach_name() handles this case wrong because
rev-cmdline[positive].name is HEAD and it goes ahead prepending
refs/heads/ anyway. I'll fix it in the reroll. I was avoiding tests
with an excuse that you did not write tests when you added this
function either. But with this change, I think tests are required.
I do not think this patch is a sufficient solution
for the more general cases, but on the other hand I do not know how
much it matters.
I think the best place to handle this is setup_revisions() for general
cases. But we do not need branch detection anywhere else yet, I guess
it's ok to fix it case by case here. We can move the code back to
revisions.c when there are more use cases for it.
- if (positive 0)
+ if (positive 0) {
+ /*
+ * No actual ref from command line, but HEAD from
+ * rev-def was added in setup_revisions()
+ * e.g. format-patch --cover-letter -12
+ */
That comment does not describe positive 0 case, but belongs to
the conditional added in this patch, no?
It's meant as the comment for the following block, yes. I'll move it
into the block for clarity.
+ if (!rev-cmdline.nr
+ rev-pending.nr == 1
+ !strcmp(rev-pending.objects[0].name, HEAD)) {
+ const char *ref;
+ ref = resolve_ref_unsafe(HEAD, branch_sha1, 1, NULL);
+ if (ref !prefixcmp(ref, refs/heads/))
+ return xstrdup(ref + strlen(refs/heads/));
+ }
return NULL;
+ }
strbuf_addf(buf, refs/heads/%s, rev-cmdline.rev[positive].name);
branch = resolve_ref_unsafe(buf.buf, branch_sha1, 1, NULL);
if (!branch ||
--
Duy
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug in latest gitk - can't click lines connecting commits
On Tue, Jan 01, 2013 at 06:54:23PM +0100, Stefan Haller wrote: Jason Holden jason.k.holden.sw...@gmail.com wrote: I was testing some patches against the latest gitk, and noticed that when I click the mouse on the lines that connect the commits in the history graph, I get an error popup with: Error: can't read cflist_top: no such variable Looks like this was introduced in gitk commit b967135d89e8d8461d059 gitk: Synchronize highlighting in file view when scrolling diff A patch that fixes this was proposed over two months ago, and Paul said he had applied it: http://permalink.gmane.org/gmane.comp.version-control.git/208162 However, looking at git://ozlabs.org/~paulus/gitk.git it's not there. Paul? I just forgot to push it out. It's there now. Paul. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] git-clean: Display more accurate delete messages
(1) Only print out the names of the files and directories that got
actually deleted.
(2) Show warning message for ignored untracked git repositories
Consider the following repo layout:
test.git/
|-- tracked_dir/
| |-- some_tracked_file
| |-- some_untracked_file
|-- tracked_file
|-- untracked_file
|-- untracked_foo/
| |-- bar/
| | |-- bar.txt
| |-- emptydir/
| |-- frotz.git/
| |-- frotz.tx
|-- untracked_some.git/
|-- some.txt
Suppose the user issues 'git clean -fd' from the test.git directory.
When -d option is used and untracked directory 'foo' contains a
subdirectory 'frotz.git' that is managed by a different git repository
therefore it will not be removed.
$ git clean -fd
Removing tracked_dir/some_untracked_file
Removing untracked_file
Removing untracked_foo/
Removing untracked_some.git/
The message displayed to the user is slightly misleading. The foo/
directory has not been removed because of foo/frotz.git still exists.
On the other hand the subdirectories 'bar' and 'emptydir' have been
deleted but they're not mentioned anywhere. Also, untracked_some.git
has not been removed either.
This behaviour is the result of the way the deletion of untracked
directories are reported. In the current implementation they are
deleted recursively but only the name of the top most directory is
printed out. The calling function does not know about any
subdirectories that could not be removed during the recursion.
Improve the way the deleted directories are reported back to
the user:
(1) Create a recursive delete function 'remove_dirs' in builtin/clean.c
to run in both dry_run and delete modes with the delete logic as
follows:
(a) Check if the current directory to be deleted is an untracked
git repository. If it is and --force --force option is not set
do not touch this directory, print ignore message, set dir_gone
flag to false for the caller and return.
(b) Otherwise for each item in current directory:
(i) If current directory cannot be accessed, print warning,
set dir_gone flag to false and return.
(ii) If the item is a subdirectory recurse into it,
check for the returned value of the dir_gone flag.
If the subdirectory is gone, add the name of the deleted
directory to a list of successfully removed items 'dels'.
Else set the dir_gone flag as the current directory
cannot be removed because we have at least one subdirectory
hanging around.
(iii) If it is a file try to remove it. If success add the
file name to the 'dels' list, else print error and set
dir_gone flag to false.
(c) After we finished deleting all items in the current directory and
the dir_gone flag is still true, remove the directory itself.
If failed set the dir_gone flag to false.
(d) If the current directory cannot be deleted because the dir_gone flag
has been set to false, print out all the successfully deleted items
for this directory from the 'dels' list.
(e) We're done with the current directory, return.
(2) Modify the cmd_clean() function to:
(a) call the recursive delete function 'remove_dirs()' for each
topmost directory it wants to remove
(b) check for the returned value of dir_gone flag. If it's true
print the name of the directory as being removed.
Consider the output of the improved version:
$ git clean -fd
Removing tracked_dir/some_untracked_file
Removing untracked_file
warning: ignoring untracked git repository untracked_foo/frotz.git
Removing untracked_foo/bar
Removing untracked_foo/emptydir
warning: ignoring untracked git repository untracked_some.git/
Now it displays only the file and directory names that got actually
deleted and shows warnings about ignored untracked git repositories.
Reported-by: Soren Brinkmann soren.brinkm...@xilinx.com
Signed-off-by: Zoltan Klinger zoltan.klin...@gmail.com
---
builtin/clean.c | 149 ---
1 file changed, 120 insertions(+), 29 deletions(-)
diff --git a/builtin/clean.c b/builtin/clean.c
index 69c1cda..37e403a 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
@@ -10,6 +10,7 @@
#include cache.h
#include dir.h
#include parse-options.h
+#include refs.h
#include string-list.h
#include quote.h
@@ -20,6 +21,13 @@ static const char *const builtin_clean_usage[] = {
NULL
};
+static const char* MSG_REMOVE = Removing %s\n;
+static const char* MSG_WOULD_REMOVE = Would remove %s\n;
+static const char* MSG_WOULD_NOT_REMOVE = Would not remove %s\n;
+static const char* MSG_WOULD_IGNORE_GIT_DIR = Would ignore
Re: [PATCH 2/3] SubmittingPatches: mention subsystems with dedicated repositories
On Tue, Jan 01, 2013 at 03:24:54PM -0800, Junio C Hamano wrote: +Subsystems with dedicated maintainers + +Some parts of the system have dedicated maintainers with their own +repositories. + + - git-gui/ comes from git-gui project, maintained by Pat Thoyts: + +git://repo.or.cz/git-gui.git + + - gitk-git/ comes from Paul Mackerras's gitk project: + +git://ozlabs.org/~paulus/gitk + + - po/ comes from the localization coordinator, Jiang Xin: + + https://github.com/git-l10n/git-po/ + +Patches to these parts should be based on their trees. + + An ideal patch flow Any reason to leave out the maintainers email addresses? If we add that, all the content of the MAINTAINERS file we had been discussing would then be in this file. My only other suggestion for this series might be to augment the file with a patch submittal example(s). I found the best example to be in git-send-email's man page, but maybe enumerate the example out for the most common workflows. Maybe something like: --- Example of sending patches for a new feature: Create the patches: $ git format-patch --cover-letter -M origin/master -o outgoing/ $ edit outgoing/-* To send your completed patches for initial consideration: $ git send-email outgoing/* -to git@vger.kernel.org -cc gits...@pobox.com To send your reviewed patches for inclusion: $ git send-email outgoing/* -to gits...@pobox.com -cc git@vger.kernel.org -Jason -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] SubmittingPatches: mention subsystems with dedicated repositories
Jason Holden jason.k.holden.sw...@gmail.com writes: Any reason to leave out the maintainers email addresses? Nothing particular, other than that I did not find anywhere in the file that does not break the flow. My only other suggestion for this series might be to augment the file with a patch submittal example(s). I found the best example to be in git-send-email's man page,... I'd feel better to avoid copying and pasting. If send-email has good examples, shouldn't it be sufficient to refer to them? --- Example of sending patches for a new feature: Create the patches: $ git format-patch --cover-letter -M origin/master -o outgoing/ $ edit outgoing/-* To send your completed patches for initial consideration: $ git send-email outgoing/* -to git@vger.kernel.org -cc gits...@pobox.com This is ambiguous; it makes it look as if you are CC'ing the maintainer, but for the initial round, it is likely that you are sending it to me only because I have been involved in the area the patch touches. To send your reviewed patches for inclusion: $ git send-email outgoing/* -to gits...@pobox.com -cc git@vger.kernel.org This is fine, but we would probably want to see it CC'ed to people who reviewed the initial submission, too. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/8] Better Error Handling for add
gree...@obbligato.org writes:
If you want to make sure you give a comit to add_commit, you can
probably say something like this:
git rev-parse -q --verify $1^{commit} /dev/null ||
die '$1' does not refer to a commit
What does $1^{commit} mean?
$thing^{type} tells Git to interpret the $thing as that type (and
error out if it can't).
So v1.0.0^{commit} is a less cryptic way to say v1.0.0^0 (there is
no need to say zeroth parent of a commit is the commit itself?
Yeah, it makes sort of sense when you learn it).
git cat-file -t junio-gpg-pub^{blob} will say blob, but you will
get a failure from git rev-parse v1.0.0^{blob} as you can only
dereference a tag that refers to a commit down to the comit and then
to its top-level tree, but not to a single blob.
And you can ask for the tree object with v1.0.0^{tree}, for example.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] test: Add target test-lint-shell-syntax
Torsten Bögershausen tbo...@web.de writes: The suggestion is to run it every time the test suite is run, at the begining. And it seems to be fast enough: $ time ./check-non-portable-shell.pl ../../git.master/t/t[0-9]*.sh real0m0.263s user0m0.239s sys 0m0.021s Hmph. OK. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] pack-objects: compression level for non-blobs
On Wed, Jan 2, 2013 at 12:17 AM, Shawn Pearce spea...@spearce.org wrote:
And I was wrong. At least since 1b4bb16 (pack-objects: optimize
recency order - 2011-06-30) commits are spread out and can be mixed
with trees too. Grouping them back defeats what Junio did in that
commit, I think.
I think you misunderstand what 1b4bb16 does. Junio uses a layout
similar to what JGit has done for years. Commits are packed, then
trees, then blobs. Only annotated tags are interspersed with commits.
The decision on where to place tags is different, but has a similar
purpose.
This is embarrassing. I looked at verify-pack output and somehow saw
trees mixed with commits. I must have read it wrong. git verify-pack
-v pack|awk '{print $2;}'|uniq on recently created pack shows that
only tags and commits are mixed. Sorry for the noise.
--
Duy
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Test failures with python versions when building git 1.8.1
A test case snuck in this release that assumes /usr/bin/python is
python2 and causes test failures. Unlike all other tests and code
depending on python, this one does not respect PYTHON_PATH, which we
explicitly set when building git on Arch Linux due to python2 vs
python3 differences.
-Dan
make[1]: Entering directory `/build/src/git-1.8.1/t'
rm -f -r test-results
*** prove ***
Test Summary Report
---
t9020-remote-svn.sh (Wstat: 256 Tests: 6 Failed: 4)
Failed tests: 1-2, 5-6
Non-zero exit status: 1
Files=608, Tests=8772, 76 wallclock secs ( 4.07 usr 0.65 sys + 91.83
cusr 37.14 csys = 133.69 CPU)
Result: FAIL
make[1]: *** [prove] Error 1
make[1]: Leaving directory `/build/src/git-1.8.1/t'
make: *** [test] Error 2
$ contrib/svn-fe/svnrdump_sim.py
File contrib/svn-fe/svnrdump_sim.py, line 43
print usage: %s dump URL -rLOWER:UPPER
^
SyntaxError: invalid syntax
diff --git a/contrib/svn-fe/svnrdump_sim.py b/contrib/svn-fe/svnrdump_sim.py
index 1cfac4a..7e6148d 100755
--- a/contrib/svn-fe/svnrdump_sim.py
+++ b/contrib/svn-fe/svnrdump_sim.py
@@ -40,7 +40,7 @@ def writedump(url, lower, upper):
if __name__ == __main__:
if not (len(sys.argv) in (3, 4, 5)):
-print usage: %s dump URL -rLOWER:UPPER
+print(usage: %s dump URL -rLOWER:UPPER)
sys.exit(1)
if not sys.argv[1] == 'dump': raise NotImplementedError('only
dump is suppported.')
url = sys.argv[2]
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Test failures with python versions when building git 1.8.1
Dan McGee d...@archlinux.org writes: A test case snuck in this release that assumes /usr/bin/python is python2 and causes test failures. Unlike all other tests and code depending on python, this one does not respect PYTHON_PATH, which we explicitly set when building git on Arch Linux due to python2 vs python3 differences. I had an impression that you are not supposed to run our scripts with python3 yet (no python scripts have been checked for python3 compatibility), even though some people have expressed interests in doing so. Eric? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Test failures with python versions when building git 1.8.1
Junio C Hamano gits...@pobox.com: Dan McGee d...@archlinux.org writes: A test case snuck in this release that assumes /usr/bin/python is python2 and causes test failures. Unlike all other tests and code depending on python, this one does not respect PYTHON_PATH, which we explicitly set when building git on Arch Linux due to python2 vs python3 differences. I had an impression that you are not supposed to run our scripts with python3 yet (no python scripts have been checked for python3 compatibility), even though some people have expressed interests in doing so. Eric? Yeah, git's stuff is nowhere even *near* python3 ready. I have it on my to-do list to run 2to3 on the in-tree scripts as a diagnostic, but I haven't had time to do that yet...mainly because cvsps/cvsimport blew up in my face when I poked at them. Now I need to go beat parsecvs into shape and run both it and cvs2git against the CVS torture tests I'm developing, so the 2to3 check won't happen for a week or two at least. Sorry. As in a general thing, I wouldn't advise worrying too much about python3 compatibility. That version is not gaining adoption very fast, mainly due to the rat's nest around plain strings vs. UTF-8 which can make code conversion a serious pain in the ass. -- a href=http://www.catb.org/~esr/;Eric S. Raymond/a -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Test failures with python versions when building git 1.8.1
On Tue, Jan 01, 2013 at 09:19:13PM -0800, Junio C Hamano wrote: Dan McGee d...@archlinux.org writes: A test case snuck in this release that assumes /usr/bin/python is python2 and causes test failures. Unlike all other tests and code depending on python, this one does not respect PYTHON_PATH, which we explicitly set when building git on Arch Linux due to python2 vs python3 differences. I had an impression that you are not supposed to run our scripts with python3 yet (no python scripts have been checked for python3 compatibility), even though some people have expressed interests in doing so. Eric? Yeah, but the worrying thing to me is that we are not respecting PYTHON_PATH. So even if Arch does everything right, it is getting punished just for having python3 on the system at all. I think we need to either: 1. Build contrib/svn-fe/svnrdump_sim.py into svnrdump using our normal build procedure, which handles $PYTHON_PATH (right now we seem to just symlink[1] it into place as svnrdump during the test script run). 2. Create svnrdump as a shell script in the test suite to do something like[2]: $PYTHON_PATH $TEST_DIRECTORY/../contrib/svn-fe/svnrdump_sim.py -Peff [1] This symlink is doubly wrong, because any use of symbolic links in the test scripts needs to depend on the SYMLINKS prereq, and this does not. [2] In both the current code and what I showed above, the test scripts depend on things in contrib/. This is probably a bad idea in general, as the quality of what goes into contrib is not as closely watched (especially with respect to things like portability). Certainly I would not have known to look more carefully at a patch to contrib/svn-fe for breakage to the test suite. FWIW, we also have this situation with t9902 (bash completion), though the dependency is a little more obvious there. It might be worth promoting bash completion out of contrib (or alternatively, demoting t9902 into contrib/completion/, possibly with a feature to make it easier to run tests out of contrib). -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gitk tag delete/rename support
On Sun, Nov 25, 2012 at 08:05:45PM +0100, Leon KUKOVEC wrote: Right clicking on a tag pops up a menu, which allows tag to be renamed or deleted. Nice idea, but I am concerned that renaming a tag that refers to a tag object will turn it into a lightweight tag, which would be surprising for users. I think that needs to be fixed before I apply the patch. Also, when renaming a tag it would be good to check for the cases where the new name is the same as the old (in which case nothing needs to be done) and where the new name already exists. Thanks, Paul. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gitk: add a checkbox to control the visibility of tags
On Sat, Dec 01, 2012 at 06:16:25PM -0800, Junio C Hamano wrote:
Łukasz Stelmach stl...@poczta.fm writes:
Enable hiding of tags displayed in the tree as yellow labels.
If a repository is used together with a system like Gerrit
there may be quite a lot of tags used to control building
and there may be hardly any place left for commit subjects.
Signed-off-by: Łukasz Stelmach stl...@poczta.fm
---
Paul, this patch is not done against your tree (does not have gitk
at the top-level), but other than that, the change mimics the way
existing hideremoes is implemented and looks reasonable to me.
We _may_ want to unify these two hidestuff into a list of patterns
that hides any ref that match one of the patterns in the list, e.g.
set hidestuff {refs/heads/*/* refs/tags/* refs/remotes/*}
may hide all tags, all remote-tracking branches and local branches
that have a slash in their names.
If the concern is the amount of screen real-estate that the tags take
up when there are many of them (which is a reasonable concern), I'd
rather just put a single tag icon with tags... inside it and arrange
to list all the tags in the diff display pane when the user clicks on
it. I think that would be better than not showing the tags at all.
Paul.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Test failures with python versions when building git 1.8.1
Jeff King p...@peff.net writes: [1] This symlink is doubly wrong, because any use of symbolic links in the test scripts needs to depend on the SYMLINKS prereq, and this does not. Yeah, I think we have discussed this once already in http://thread.gmane.org/gmane.comp.version-control.git/210688/focus=210714 [2] In both the current code and what I showed above, the test scripts depend on things in contrib/. This is probably a bad idea in general, as the quality of what goes into contrib is not as closely watched (especially with respect to things like portability). Certainly I would not have known to look more carefully at a patch to contrib/svn-fe for breakage to the test suite. As long as such tests are made skippable with appropriate prerequisites, I do not think it is bad to have their tests in t/; I would say it is rather better than having them in contrib/ and leave it not run by anybody, which happened to some of the stuff in contrib/ already. ... possibly with a feature to make it easier to run tests out of contrib). Yes, that certainly is a workable alternative. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Makefile dependency from 'configure' to 'GIT-VERSION-FILE'
Hi Martin,
Martin von Zweigbergk wrote:
I use autoconf with git.git. I have noticed lately, especially when
doing things like git rebase -i --exec make, that ./configure is run
every time. If I understand correctly, this is because of 8242ff4
(build: reconfigure automatically if configure.ac changes,
2012-07-19).
How about this patch (untested)?
-- 8 --
Subject: build: do not automatically reconfigure unless configure.ac changed
Starting with v1.7.12-rc0~4^2 (build: reconfigure automatically if
configure.ac changes, 2012-07-19), config.status --recheck is
automatically run every time the configure script changes. In
particular, that means the configuration procedure repeats whenever
the version number changes (since the configure script changes to
support ./configure --version and ./configure --help), making
bisecting painfully slow.
The intent was to make the reconfiguration process only trigger for
changes to configure.ac's logic. Tweak the Makefile rule to match
that intent by depending on configure.ac instead of configure.
Reported-by: Martin von Zweigbergk martinv...@gmail.com
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
[...]
--- a/Makefile
+++ b/Makefile
@@ -2267,12 +2267,9 @@ $(patsubst %.py,%,$(SCRIPT_PYTHON)): % :
unimplemented.sh
mv $@+ $@
endif # NO_PYTHON
-configure: configure.ac GIT-VERSION-FILE
+configure: configure.ac
[...]
--- a/configure.ac
+++ b/configure.ac
@@ -142,7 +142,10 @@ fi
## Configure body starts here.
AC_PREREQ(2.59)
-AC_INIT([git], [@@GIT_VERSION@@], [git@vger.kernel.org])
+AC_INIT([git],
+ m4_esyscmd([ ./GIT-VERSION-GEN
+{ sed -ne 's/GIT_VERSION = //p' GIT-VERSION-FILE | xargs
echo -n; } ]),
+ [git@vger.kernel.org])
I don't think that would warrant dropping the GIT-VERSION-FILE
dependency, since the resulting configure script still hard-codes the
version number.
Sane?
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index 736ecd45..2a22041f 100644
--- a/Makefile
+++ b/Makefile
@@ -2275,7 +2275,7 @@ configure: configure.ac GIT-VERSION-FILE
$(RM) $+
ifdef AUTOCONFIGURED
-config.status: configure
+config.status: configure.ac
$(QUIET_GEN)if test -f config.status; then \
./config.status --recheck; \
else \
--
1.8.1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gitk: add a checkbox to control the visibility of tags
Paul Mackerras pau...@samba.org writes: On Sat, Dec 01, 2012 at 06:16:25PM -0800, Junio C Hamano wrote: Łukasz Stelmach stl...@poczta.fm writes: Enable hiding of tags displayed in the tree as yellow labels. If a repository is used together with a system like Gerrit there may be quite a lot of tags used to control building and there may be hardly any place left for commit subjects. Signed-off-by: Łukasz Stelmach stl...@poczta.fm --- ... If the concern is the amount of screen real-estate that the tags take up when there are many of them (which is a reasonable concern), I'd rather just put a single tag icon with tags... inside it and arrange to list all the tags in the diff display pane when the user clicks on it. I think that would be better than not showing the tags at all. Yeah, sounds very sensible. Thanks. Łukasz, what do you think? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Makefile dependency from 'configure' to 'GIT-VERSION-FILE'
On Tue, Jan 1, 2013 at 11:21 PM, Jonathan Nieder jrnie...@gmail.com wrote:
How about this patch (untested)?
Looks good. Thanks!
--- a/Makefile
+++ b/Makefile
@@ -2267,12 +2267,9 @@ $(patsubst %.py,%,$(SCRIPT_PYTHON)): % :
unimplemented.sh
mv $@+ $@
endif # NO_PYTHON
-configure: configure.ac GIT-VERSION-FILE
+configure: configure.ac
[...]
--- a/configure.ac
+++ b/configure.ac
@@ -142,7 +142,10 @@ fi
## Configure body starts here.
AC_PREREQ(2.59)
-AC_INIT([git], [@@GIT_VERSION@@], [git@vger.kernel.org])
+AC_INIT([git],
+ m4_esyscmd([ ./GIT-VERSION-GEN
+{ sed -ne 's/GIT_VERSION = //p' GIT-VERSION-FILE |
xargs echo -n; } ]),
+ [git@vger.kernel.org])
I don't think that would warrant dropping the GIT-VERSION-FILE
dependency, since the resulting configure script still hard-codes the
version number.
Yeah, you're right. I was merely sweeping the dependency under the rug :-(
diff --git a/Makefile b/Makefile
index 736ecd45..2a22041f 100644
--- a/Makefile
+++ b/Makefile
@@ -2275,7 +2275,7 @@ configure: configure.ac GIT-VERSION-FILE
$(RM) $+
ifdef AUTOCONFIGURED
-config.status: configure
+config.status: configure.ac
$(QUIET_GEN)if test -f config.status; then \
./config.status --recheck; \
else \
The next line just outside the context here does depend on
'configure', which is why I thought this would not be right. But it
seems impossible to get away from that, and AUTOCONFIGURED should only
be set when ./configure has been run (IIUC), so it's not even
realistic to have git reconfigure fail to find ./configure. So,
again, looks good.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
What's cooking in git.git (Jan 2013, #01; Tue, 1)
Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. The tip of the 'master' branch is at 1.8.1; the tip of 'next' will be rewound soonish to reorder topics that are already well cooked during the pre-release freeze earlier than the others so that they can orderly be merged to 'master' after the dust settles, probably towards the end of this week. Note that many topics that have been marked as Will cook in next have been recategorized to be merged to 'master' soonish, and a few topics have been marked to be kicked back to 'pu'. Please holler if a topic that still has unresolved issues is marked to be merged to 'master' by mistake. You can find the changes described here in the integration branches of the repositories listed at http://git-blame.blogspot.com/p/git-public-repositories.html -- [New Topics] * jc/submittingpatches (2013-01-01) 3 commits - SubmittingPatches: remove overlong checklist - SubmittingPatches: mention subsystems with dedicated repositories - SubmittingPatches: who am I and who cares? Will reroll. * kb/maint-bundle-doc (2013-01-01) 2 commits - Documentation: full-ness of a bundle is significant for cloning - Documentation: correct example restore from bundle Will merge to 'next'. * nd/maint-branch-desc-doc (2013-01-01) 3 commits - branch: delete branch description if it's empty - format-patch: pick up branch description when no ref is specified - config.txt: a few lines about branch.name.description Waiting for a reroll. * tb/test-t9020-no-which (2013-01-01) 1 commit - t9020: which is not portable Will merge to 'next'. * tb/test-t9810-no-sed-i (2013-01-01) 1 commit - t9810: Do not use sed -i Will merge to 'next'. -- [Stalled] * jl/submodule-deinit (2012-12-04) 1 commit (merged to 'next' on 2012-12-07 at ea772f0) + submodule: add 'deinit' command There was no Porcelain way to say I no longer am interested in this submodule, once you express your interest in a submodule with submodule init. submodule deinit is the way to do so. But this does not yet do so (does not remove the checkout of the submodule). The design discussion petered out. http://thread.gmane.org/gmane.comp.version-control.git/210867/focus=211456 Will kick back to 'pu'. * jc/doc-maintainer (2012-11-27) 1 commit - update howto maintain git An early draft that is still incomplete. * fc/remote-bzr (2012-12-13) 10 commits - (fixup) test-bzr.sh: fix multi-line string assignment - remote-bzr: detect local repositories - remote-bzr: add support for older versions of bzr - remote-bzr: add support to push special modes - remote-bzr: add support for fecthing special modes - remote-bzr: add simple tests - remote-bzr: update working tree upon pushing - remote-bzr: add support for remote repositories - remote-bzr: add support for pushing - Add new remote-bzr transport helper New remote helper for bzr (v3). With minor fixes, this may be ready for 'next'. * mo/cvs-server-updates (2012-12-09) 18 commits - t9402: Use TABs for indentation - t9402: Rename check.cvsCount and check.list - t9402: Simplify git ls-tree - t9402: Add missing ; Code style - t9402: No space after IO-redirection - t9402: Dont use test_must_fail cvs - t9402: improve check_end_tree() and check_end_full_tree() - t9402: sed -i is not portable - 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. * aw/rebase-am-failure-detection (2012-10-11) 1 commit - rebase: Handle cases where format-patch fails Save output from format-patch command in a temporary file, just in case it aborts, to give a better failure-case behaviour. Will merge to 'next'. * 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 Needs review and Ack (or Nack) from people
