Re: [PATCH] notes: mention --notes in more places
Jeff King p...@peff.net wrote: It may also make sense to show notes differently when outputting the email format as format-patch does. E.g., using a triple-dash would keep them separate from the commit message when using git am. Like: your commit message Signed-off-by: You --- your notes go here We've talked about it several times, but it's never happened (probably because most people don't actually use notes). It is sometimes scary how we end up saying identical things independently :-) -- 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 can cause empty GIT_AUTHOR_NAME for 'git filter-branch --tree-filter' on Solaris?
The filter-branch command, the contents of ~/.gitconfig and the tree are the same. The command succeeds on cygwin, but fails on Solaris due to unset GIT_AUTHOR_NAME and GIT_COMMITTER_NAME : $ git filter-branch --tree-filter env | grep GIT_ ; $CMD b416b9bfc5e71531f2f05af4c396bb0ba7560741..HEAD Rewrite 214efc6eec82b015aefe23b2280979f05b351396 (1/16)GIT_DIR=/home/tester/.ilya/builds/makepkg.rap_0.1-1_sparc.XX/src/rap/.git GIT_INDEX_FILE=/home/tester/.ilya/builds/makepkg.rap_0.1-1_sparc.XX/src/rap/.git-rewrite/t/../index GIT_WORK_TREE=. GIT_AUTHOR_NAME= GIT_COMMITTER_NAME= GIT_COMMIT=214efc6eec82b015aefe23b2280979f05b351396 fatal: empty ident m...@email.com not allowed could not write rewritten commit If I explicitly set these 2 variables, filter-branch succeeds, but other commit attributes like commit date aren't preserved. I use git 1.7.6, from sunfreeware. I hope there is some simple thing that needs to be configured. -- 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/3] Change colors to be based on git status -sb in color mode
On 16/10/12 23:30, Junio C Hamano wrote:
Simon Oosthoek s.oosth...@xs4all.nl writes:
Hi
Fixed the mistakes of the last one, and I'm now using the symbolic names
ok_color and bad_color.
The test for headless state is now more direct, and I hope it is still
correct.
/Simon
Will apply with a bit more readable log message.
Ok
I think it would be a good idea to squash something like the
attached into this patch, though.
I tried the patch and it works when you switch the color assignments in
the if statement you added...
@@ -264,7 +264,7 @@ __git_ps1 ()
fi
b=$(git symbolic-ref HEAD 2/dev/null) || {
-
+ detached=yes
b=$(
case ${GIT_PS1_DESCRIBE_STYLE-} in
(contains)
@@ -335,8 +335,7 @@ __git_ps1 ()
local flags_color=$c_lblue
local branchstring=$c${b##refs/heads/}
- if git symbolic-ref HEAD 2/dev/null 12
- then
+ if [ $detached = yes ]; then
- branch_color=$ok_color
+ branch_color=$bad_color
else
- branch_color=$bad_color
+ branch_color=$ok_color
if detached = yes, then bad_color should be applied, else use ok_color.
Cheers
Simon
--
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 can cause empty GIT_AUTHOR_NAME for 'git filter-branch --tree-filter' on Solaris?
On Wed, Oct 17, 2012 at 10:47:29AM +0400, Ilya Basin wrote:
The filter-branch command, the contents of ~/.gitconfig and the tree
are the same.
The command succeeds on cygwin, but fails on Solaris due to
unset GIT_AUTHOR_NAME and GIT_COMMITTER_NAME :
That shouldn't happen. The likely culprit is that the sed magic in the
set_ident function of git-filter-branch is not portable to your version
of sed.
What happens if you run this:
echo 'author Your Name y...@example.com 1350408529 -0400' commit
set -- author
lid=$(echo $1 | tr [A-Z] [a-z])
uid=$(echo $1 | tr [a-z] [A-Z])
pick_id_script='
/^'$lid' /{
s/'\''/'\''\\'\'\''/g
h
s/^'$lid' \([^]*\) [^]* .*$/\1/
s/'\''/'\''\'\'\''/g
s/.*/GIT_'$uid'_NAME='\'''\''; export GIT_'$uid'_NAME/p
g
s/^'$lid' [^]* \([^]*\) .*$/\1/
s/'\''/'\''\'\'\''/g
s/.*/GIT_'$uid'_EMAIL='\'''\''; export
GIT_'$uid'_EMAIL/p
g
s/^'$lid' [^]* [^]* \(.*\)$/@\1/
s/'\''/'\''\'\'\''/g
s/.*/GIT_'$uid'_DATE='\'''\''; export GIT_'$uid'_DATE/p
q
}
'
LANG=C LC_ALL=C sed -ne $pick_id_script commit
in your shell? You should get:
GIT_AUTHOR_NAME='Your Name'; export GIT_AUTHOR_NAME
GIT_AUTHOR_EMAIL='y...@example.com'; export GIT_AUTHOR_EMAIL
GIT_AUTHOR_DATE='@1350408529 -0400'; export GIT_AUTHOR_DATE
I use git 1.7.6, from sunfreeware.
It might also be worth testing v1.7.12, but reading the logs, I don't
think there has been any meaningful update to filter-branch since then.
-Peff
--
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 can cause empty GIT_AUTHOR_NAME for 'git filter-branch --tree-filter' on Solaris?
Am 10/17/2012 8:47, schrieb Ilya Basin: The filter-branch command, the contents of ~/.gitconfig and the tree are the same. The command succeeds on cygwin, but fails on Solaris due to unset GIT_AUTHOR_NAME and GIT_COMMITTER_NAME : $ git filter-branch --tree-filter env | grep GIT_ ; $CMD b416b9bfc5e71531f2f05af4c396bb0ba7560741..HEAD Rewrite 214efc6eec82b015aefe23b2280979f05b351396 (1/16)GIT_DIR=/home/tester/.ilya/builds/makepkg.rap_0.1-1_sparc.XX/src/rap/.git GIT_INDEX_FILE=/home/tester/.ilya/builds/makepkg.rap_0.1-1_sparc.XX/src/rap/.git-rewrite/t/../index GIT_WORK_TREE=. GIT_AUTHOR_NAME= GIT_COMMITTER_NAME= GIT_COMMIT=214efc6eec82b015aefe23b2280979f05b351396 fatal: empty ident m...@email.com not allowed could not write rewritten commit Most likely, your sed has problems with a sed script in function get_author_ident_from_commit. I tested it like this: $ sh -c '. $(git --exec-path)/git-sh-setup; get_author_ident_from_commit HEAD' GIT_AUTHOR_NAME='Johannes Sixt' GIT_AUTHOR_EMAIL='j...@kdbg.org' GIT_AUTHOR_DATE='@1350025129 +0200' -- 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: sharedRepository derived from file permissions
On Mon, 8 Oct 2012, Junio C Hamano wrote: Mark Hills m...@pogo.org.uk writes: We make extensive use of unix permissions and core.sharedRepository -- multiple developers push to the same repo. I have often wondered why core.sharedRepository is needed at all as a separate configuration? It looks like it might be easier (and less confusing to users) to derive this attribute from the top-level .git directory? Hrm, clever ;-) Is there a reason why Git doesn't just follow (and echo) the top-level permissions? Other than we did not trust that all the end users are capable of doing the right 'chmod 2775 .git chgrp project .git, with a little bit of we didn't think of that when we wrote the system, I do not recall any. Thanks. If I understand, you mean it might be worth a try to implement this. For us it would certainly simplify, and reduce mistakes/confusion. I've yet to look into the code, but I will try and do this. If you have any hints or recommendations where to begin then that'd be good. I think I did peek some years ago to find out that it was non-trivial, and then came up with the script! I wonder if there are any users who are granting permission to specific branchs or tags or tag directories. I'm not sure if this is really a valid use case, but there might need to be a way to ignore the top-level attributes too for some special cases? Thanks -- Mark -- 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: sharedRepository derived from file permissions
Mark Hills m...@pogo.org.uk writes: It looks like it might be easier (and less confusing to users) to derive this attribute from the top-level .git directory? Hrm, clever ;-) Is there a reason why Git doesn't just follow (and echo) the top-level permissions? Other than we did not trust that all the end users are capable of doing the right 'chmod 2775 .git chgrp project .git, with a little bit of we didn't think of that when we wrote the system, I do not recall any. Thanks. If I understand, you mean it might be worth a try to implement this. Not really. I still do not think that all the end users are capable of doing the right 'chmod 2775 .git chgrp project .git' themselves. -- 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: When Will We See Collisions for SHA-1? (An interesting analysis by Bruce Schneier)
On Tue, Oct 16, 2012 at 02:27:51PM -0400, Jeff King wrote: The one reason why we *might* want to use SHA-3, BTW, is that it is a radically different design from SHA-1 and SHA-2. And if there is a crypto hash failure which is bad enough that the security of git would be affected, there's a chance that the same attack could significantly affect SHA-2 as well. The fact that SHA-3 is fundamentally different from a cryptographic design perspective means that an attack that impacts SHA-1/SHA-2 will not likely impact SHA-3, and vice versa. Right. The point of having the SHA-3 contest was that we thought SHA-1's breakage meant that SHA-2 was going to fall next. But Schneier's comments before the winners were announced were basically it turns out that SHA-2 is not broken like we thought, so there's no reason to ditch it, and the fact that it is well-studied and well-deployed may mean it's a good choice. So I could go either way. This is not a decision we should make today, though, so we can wait and see which direction the world goes before picking an algorithm. Do you really need to pick an algorithm and go through a full-on flag day ten years down the road all over again? People don't really care that a git revision is actually the hex-encoded SHA1 hash of a tree. They just know it's this long string of stuff that uniquely identifies a revison globally somehow. They know if they copy and paste the first few characters of the string there is a small chance two revisions will have the same first few characters, and if they copy and paste the whole string the chance drops to you're whole dev team will be eaten by wolves in tragic unrelated incidences unlikely. So why bake in a single algorithm? We'll have to extend the length of a whole revision string anyway - the alternatives start at 256bits - and people are going to want to be able to specify the whole revision string at least sometimes. Once you've gone through that pain, why have to repeat it again in ten years? Let's make revisions be a long but variable length string. A revision by itself is meaningless of course. However if if you know of a repo that contains that revision, you can convert it into something useful, like a commit and associated tree. If you don't know, well, you'd be stuck anyway right now. Now when you push and pull from a remote repo what'll happen is the repo will figure out what type(s) of hash algorithm your client supports. A Git 3000 user with a repo using SHA3072 can talk to a v0.1 client just fine: they send the v0.1 client revisions calculated with an algorithm they support, and when they pull revisions from that repo they calculate new revisions with their preferred algorithm. If they want to do this a lot, they maintain the two sets of digest tables next to each other, with the SHA3072 table marked as preferred, and the rest kept only so pushes and pulls can be fast. In most cases a project will convert to one hash algorithm, but by having multi-hash support that conversion doesn't have to be a flag day, and at the same time it's still easy to lookup old revisions by their old digests. Meanwhile the crypto-wonks get to have their fun PGP signing and timestamping long, secure digests. Note that we don't even have to shut out non-upgraded users from participating. Machine-to-machine communication is not a problem as outlined above, but even with stuff like mailing lists we can start passing around concatenated revisions like the following: da39a3ee5e6b4b0d3255bfef95601890afd80709.e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 Old users just use the first bit. (the period isn't even required really) If you think that's too long, there's a simple solution that keeps your requirements-bit security, albeit one whose implications lead you right to Linus's lines of thinking: da39a3ee5e6b4b0d3255bfef95601890afd80709 That's just a SHA1 again. Of course, if you actually care about this stuff you already have cryptographic infrastructure, and that infrastructure can simply store *trusted* metadata in you're repos saying that the string 'foo' happens to be a valid alias for the actual digest that *the user* can specify instead of that digest. It may even be that for your security needs just timestamping those aliases is enough. Either way while something needs to be calculating secure hashes, and preferably Git mainline so push and pull works without having to examine every last line of code, you can get away without changing the UI very much. Anyway, in the short term the people who care can write parallel digest calculators; I personally have a use-case for one right now. Better code to handle the cases where individual blobs have colliding hashes is required as well in the medium term. Finally those who require it could very well write parallel git's to effectively do the pulling and pushing of their parallel calculated revision hashes if they really wanted too. But if this
Re[2]: What can cause empty GIT_AUTHOR_NAME for 'git filter-branch --tree-filter' on Solaris?
JS Most likely, your sed has problems with a sed script in function
JS get_author_ident_from_commit. I tested it like this:
JS $ sh -c '. $(git --exec-path)/git-sh-setup;
JS get_author_ident_from_commit HEAD'
JS GIT_AUTHOR_NAME='Johannes Sixt'
JS GIT_AUTHOR_EMAIL='j...@kdbg.org'
JS GIT_AUTHOR_DATE='@1350025129 +0200'
JS -- Hannes
Both systems have GNU sed 4.2.1 installed. I wrote a wrapper script wor sed.
It's output attached.
The difference is letter case in sed input data:
Solaris:
/^AUTHOR /
Windows:
/^author /
-- $ git filter-branch -f --tree-filter env | grep GIT_; true HEAD~1..HEAD
SED BEGIN
SED ARGUMENTS: -e s/-/ /
SED STDIN BEGIN
git-filter-branch
SED STDIN END
SED OUTPUT BEGIN
git filter-branch
SED OUTPUT END
SED EXIT CODE: 0
SED END
SED BEGIN
SED ARGUMENTS: -e /^^/d
/cygdrive/c/sicap/rap/gitcvs/RAP27/.git-rewrite/raw-heads
SED INPUT FILE BEGIN: /cygdrive/c/sicap/rap/gitcvs/RAP27/.git-rewrite/raw-heads
refs/heads/master
SED INPUT FILE END: /cygdrive/c/sicap/rap/gitcvs/RAP27/.git-rewrite/raw-heads
SED OUTPUT BEGIN
refs/heads/master
SED OUTPUT END
SED EXIT CODE: 0
SED END
Rewrite acd1d2bb1984c96630d5070497590307151c4682 (1/1)
SED BEGIN
SED ARGUMENTS: -ne
/^author /{
s/'/'\\''/g
h
s/^author \([^]*\) [^]* .*$/\1/
s/'/'\''/g
s/.*/GIT_AUTHOR_NAME=''; export GIT_AUTHOR_NAME/p
g
s/^author [^]* \([^]*\) .*$/\1/
s/'/'\''/g
s/.*/GIT_AUTHOR_EMAIL=''; export GIT_AUTHOR_EMAIL/p
g
s/^author [^]* [^]* \(.*\)$/\1/
s/'/'\''/g
s/.*/GIT_AUTHOR_DATE=''; export GIT_AUTHOR_DATE/p
q
}
SED STDIN BEGIN
tree 969f563d319049bb6dabc12054d67671499a6f55
parent c4734950e37c09ca7d3e3088f6f31d866dbb5077
author Ilya Basin basini...@gmail.com 1350401059 +0400
committer Ilya Basin basini...@gmail.com 1350405585 +0400
temp
SED STDIN END
SED OUTPUT BEGIN
GIT_AUTHOR_NAME='Ilya Basin'; export GIT_AUTHOR_NAME
GIT_AUTHOR_EMAIL='basini...@gmail.com'; export GIT_AUTHOR_EMAIL
GIT_AUTHOR_DATE='1350401059 +0400'; export GIT_AUTHOR_DATE
SED OUTPUT END
SED EXIT CODE: 0
SED END
SED BEGIN
SED ARGUMENTS: -ne
/^committer /{
s/'/'\\''/g
h
s/^committer \([^]*\) [^]* .*$/\1/
s/'/'\''/g
s/.*/GIT_COMMITTER_NAME=''; export GIT_COMMITTER_NAME/p
g
s/^committer [^]* \([^]*\) .*$/\1/
s/'/'\''/g
s/.*/GIT_COMMITTER_EMAIL=''; export
GIT_COMMITTER_EMAIL/p
g
s/^committer [^]* [^]* \(.*\)$/\1/
s/'/'\''/g
s/.*/GIT_COMMITTER_DATE=''; export GIT_COMMITTER_DATE/p
q
}
SED STDIN BEGIN
tree 969f563d319049bb6dabc12054d67671499a6f55
parent c4734950e37c09ca7d3e3088f6f31d866dbb5077
author Ilya Basin basini...@gmail.com 1350401059 +0400
committer Ilya Basin basini...@gmail.com 1350405585 +0400
temp
SED STDIN END
SED OUTPUT BEGIN
GIT_COMMITTER_NAME='Ilya Basin'; export GIT_COMMITTER_NAME
GIT_COMMITTER_EMAIL='basini...@gmail.com'; export GIT_COMMITTER_EMAIL
GIT_COMMITTER_DATE='1350405585 +0400'; export GIT_COMMITTER_DATE
SED OUTPUT END
SED EXIT CODE: 0
SED END
GIT_DIR=/cygdrive/c/sicap/rap/gitcvs/RAP27/.git
GIT_AUTHOR_DATE=1350401059 +0400
GIT_INDEX_FILE=/cygdrive/c/sicap/rap/gitcvs/RAP27/.git-rewrite/t/../index
GIT_WORK_TREE=.
GIT_AUTHOR_NAME=Ilya Basin
GIT_COMMITTER_NAME=Ilya Basin
GIT_COMMIT=acd1d2bb1984c96630d5070497590307151c4682
GIT_COMMITTER_EMAIL=basini...@gmail.com
GIT_COMMITTER_DATE=1350405585 +0400
GIT_AUTHOR_EMAIL=basini...@gmail.com
SED BEGIN
SED ARGUMENTS: -e 1,/^$/d
SED STDIN BEGIN
tree 969f563d319049bb6dabc12054d67671499a6f55
parent c4734950e37c09ca7d3e3088f6f31d866dbb5077
author Ilya Basin basini...@gmail.com 1350401059 +0400
committer Ilya Basin basini...@gmail.com 1350405585 +0400
temp
SED STDIN END
SED OUTPUT BEGIN
temp
SED OUTPUT END
SED EXIT CODE: 0
SED END
WARNING: Ref 'refs/heads/master' is unchanged
-bash-3.00$ git filter-branch -f --tree-filter env | grep GIT_; true
HEAD~1..HEAD
SED BEGIN
SED ARGUMENTS: -e s/-/ /
SED STDIN BEGIN
git-filter-branch
SED STDIN END
SED OUTPUT BEGIN
git filter-branch
SED OUTPUT END
SED EXIT CODE: 0
SED END
SED BEGIN
SED ARGUMENTS: -e /^^/d
/home/tester/.ilya/builds/makepkg.rap_0.1-1_sparc.XX/src/rap/.git-rewrite/raw-heads
SED INPUT FILE BEGIN:
/home/tester/.ilya/builds/makepkg.rap_0.1-1_sparc.XX/src/rap/.git-rewrite/raw-heads
refs/heads/master
SED INPUT FILE END:
Re[3]: What can cause empty GIT_AUTHOR_NAME for 'git filter-branch --tree-filter' on Solaris?
JS Most likely, your sed has problems with a sed script in function JS get_author_ident_from_commit. I tested it like this: JS $ sh -c '. $(git --exec-path)/git-sh-setup; JS get_author_ident_from_commit HEAD' JS GIT_AUTHOR_NAME='Johannes Sixt' JS GIT_AUTHOR_EMAIL='j...@kdbg.org' JS GIT_AUTHOR_DATE='@1350025129 +0200' JS -- Hannes IB Both systems have GNU sed 4.2.1 installed. I wrote a wrapper script wor sed. IB It's output attached. IB The difference is letter case in sed input data: IB Solaris: IB /^AUTHOR / IB Windows: IB /^author / The culprit is bad $PATH : When git-filter-branch runs, for some reason two new entries precede /usr/bin in it: /tmp/777/.ilya-sparc/bin /home/tester/.ilya/opt/SNiFF-3.2.1/bin /export/home/testora/app/testora/product/11.2.0/client_32/bin +/usr/xpg6/bin +/usr/xpg4/bin /usr/bin /home/tester/apache-ant-1.7.1/bin /usr/jdk/instances/jdk1.5.0//bin And /usr/xpg6/bin/tr fails to make AUTHOR lowercase. -- 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
L10n regression in 1.8.0.rc2: diffstat summary (git diff --stat, git format-patch)
Hi! The output of git format-patch and git diff --stat no longer becomes localized when using 1.8.0.rc2, compared to 1.7.12 Running both versions of git format-patch -1 from the same repository, with the same settings otherwise, has 1.7.12 output the diffstat summary in Swedish, while 1.8.0.rc2 doesn't: diff 1.7.12.txt 1.8.0.rc2.txt 8c8 1 fil ändrad, 1 tillägg(+) --- 1 file changed, 1 insertion(+) 18c18 1.7.12 --- 1.8.0.rc2 The same applies to git diff --stat and git show --stat. I can understand for git format-patch to default to English (but as its output is ignored on read, it doesn't hurt to have it localized), but for diff and show, it is annoying (even if the rest of the git diff output also needs to be translated eventually). -- \\// Peter - http://www.softwolves.pp.se/ -- 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: L10n regression in 1.8.0.rc2: diffstat summary (git diff --stat, git format-patch)
On Wed, Oct 17, 2012 at 5:53 PM, Peter Krefting pe...@softwolves.pp.se wrote: Hi! The output of git format-patch and git diff --stat no longer becomes localized when using 1.8.0.rc2, compared to 1.7.12 It's the result of this discussion [1]. I don't remember exactly the open issues. But I think it involves drawing a line between team language vs local language, whether team language can be anything other than English, the maintenance cost for supporting it. You're welcome to revive the discussion. Maybe we can find a solution that is agreed by all parties. [1] http://thread.gmane.org/gmane.comp.version-control.git/204285/focus=204283 -- 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: [PATCH v5 02/12] ctype: support iscntrl, ispunct, isxdigit and isprint
Hi Nguyen.
I just had a need for isprint() myself, and then I found
your code here.
I had a look at the POSIX locale as describe here:
http://sourceware.org/git/?p=glibc.git;a=blob;f=localedata/locales/POSIX
Some remarks below.
Am 14.10.2012 16:26, schrieb Nguyen Thai Ngoc Duy:
-- 8 --
diff --git a/ctype.c b/ctype.c
index faeaf34..0bfebb4 100644
--- a/ctype.c
+++ b/ctype.c
@@ -11,18 +11,21 @@ enum {
D = GIT_DIGIT,
G = GIT_GLOB_SPECIAL, /* *, ?, [, \\ */
R = GIT_REGEX_SPECIAL, /* $, (, ), +, ., ^, {, | */
- P = GIT_PATHSPEC_MAGIC /* other non-alnum, except for ] and } */
+ P = GIT_PATHSPEC_MAGIC, /* other non-alnum, except for ] and } */
+ X = GIT_CNTRL,
+ U = GIT_PUNCT,
+ Z = GIT_CNTRL | GIT_SPACE
};
const unsigned char sane_ctype[256] = {
- 0, 0, 0, 0, 0, 0, 0, 0, 0, S, S, 0, 0, S, 0, 0, /* 0.. 15 */
- 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, /* 16.. 31 */
+ X, X, X, X, X, X, X, X, X, Z, Z, X, X, Z, X, X, /* 0.. 15 */
+ X, X, X, X, X, X, X, X, X, X, X, X, X, X, X, X, /* 16.. 31 */
Normal isspace() also includes vertical tab (11) and form-feed (12) as
white-space characters. Is there a reason, why they are not included here?
S, P, P, P, R, P, P, P, R, R, G, R, P, P, R, P, /* 32.. 47 */
D, D, D, D, D, D, D, D, D, D, P, P, P, P, P, G, /* 48.. 63 */
P, A, A, A, A, A, A, A, A, A, A, A, A, A, A, A, /* 64.. 79 */
- A, A, A, A, A, A, A, A, A, A, A, G, G, 0, R, P, /* 80.. 95 */
+ A, A, A, A, A, A, A, A, A, A, A, G, G, U, R, P, /* 80.. 95 */
P, A, A, A, A, A, A, A, A, A, A, A, A, A, A, A, /* 96..111 */
- A, A, A, A, A, A, A, A, A, A, A, R, R, 0, P, 0, /* 112..127 */
+ A, A, A, A, A, A, A, A, A, A, A, R, R, U, P, X, /* 112..127 */
/* Nothing in the 128.. range */
};
diff --git a/git-compat-util.h b/git-compat-util.h
index f8b859c..db77f3e 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
[...]
@@ -527,6 +533,13 @@ extern const unsigned char sane_ctype[256];
#define isupper(x) sane_iscase(x, 0)
#define is_glob_special(x) sane_istest(x,GIT_GLOB_SPECIAL)
#define is_regex_special(x) sane_istest(x,GIT_GLOB_SPECIAL |
GIT_REGEX_SPECIAL)
+#define iscntrl(x) (sane_istest(x,GIT_CNTRL))
+#define ispunct(x) sane_istest(x, GIT_PUNCT | GIT_REGEX_SPECIAL | \
+ GIT_GLOB_SPECIAL | GIT_PATHSPEC_MAGIC)
+#define isxdigit(x) (hexval_table[x] != -1)
+#define isprint(x) (sane_istest(x, GIT_ALPHA | GIT_DIGIT | GIT_SPACE | \
+ GIT_PUNCT | GIT_REGEX_SPECIAL | GIT_GLOB_SPECIAL | \
+ GIT_PATHSPEC_MAGIC))
Normal isprint() only includes space (32) from the white-space characters.
The other white-space characters are not considered printable.
Do we want to stay close to the original, or not?
Regards
Jan
--
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
[no subject]
subscribe -- 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: sharedRepository derived from file permissions
On Wed, 17 Oct 2012, Junio C Hamano wrote: Mark Hills m...@pogo.org.uk writes: It looks like it might be easier (and less confusing to users) to derive this attribute from the top-level .git directory? Hrm, clever ;-) Is there a reason why Git doesn't just follow (and echo) the top-level permissions? Other than we did not trust that all the end users are capable of doing the right 'chmod 2775 .git chgrp project .git, with a little bit of we didn't think of that when we wrote the system, I do not recall any. Thanks. If I understand, you mean it might be worth a try to implement this. Not really. I still do not think that all the end users are capable of doing the right 'chmod 2775 .git chgrp project .git' themselves. But with the current method, users still have to do this _and_ set sharedRepository=. It would make things hard or impossible if we assume that a user wanting to share a repository does not understand file modes or groups. -- Mark -- 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 v5 02/12] ctype: support iscntrl, ispunct, isxdigit and isprint
On Wed, Oct 17, 2012 at 7:09 PM, Jan H. Schönherr
schn...@cs.tu-berlin.de wrote:
const unsigned char sane_ctype[256] = {
- 0, 0, 0, 0, 0, 0, 0, 0, 0, S, S, 0, 0, S, 0, 0, /* 0.. 15 */
- 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, /* 16.. 31 */
+ X, X, X, X, X, X, X, X, X, Z, Z, X, X, Z, X, X, /* 0.. 15 */
+ X, X, X, X, X, X, X, X, X, X, X, X, X, X, X, X, /* 16.. 31 */
Normal isspace() also includes vertical tab (11) and form-feed (12) as
white-space characters. Is there a reason, why they are not included here?
I'm not sure. They were not classified as spaces in the very first
version in 4546738 (Unlocalized isspace and friends - 2005-10-13).
Maybe Linus had a reason to do so.
+#define isprint(x) (sane_istest(x, GIT_ALPHA | GIT_DIGIT | GIT_SPACE | \
+ GIT_PUNCT | GIT_REGEX_SPECIAL | GIT_GLOB_SPECIAL | \
+ GIT_PATHSPEC_MAGIC))
Normal isprint() only includes space (32) from the white-space characters.
The other white-space characters are not considered printable.
Do we want to stay close to the original, or not?
We do. I followed [1] but obvious missed the last sentence in print
description: No characters specified for the keyword cntrl shall be
specified. Thanks for catching. I'll fix it soon.
[1] http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap07.html
--
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: Can git pull from a mercurial repository?
Hi, On Tue, Sep 25, 2012 at 4:15 PM, Max Horn post...@quendi.de wrote: On 18.09.2012, at 14:40, Joachim Schmitz wrote: From: Andreas Ericsson [mailto:a...@op5.se] Sent: Tuesday, September 18, 2012 1:46 PM To: Joachim Schmitz Cc: git@vger.kernel.org Subject: Re: Can git pull from a mercurial repository? On 09/18/2012 01:22 PM, Joachim Schmitz wrote: Is there an easy way to get git to clone/pull from a Mercurial repository? Yes. Google git remote helpers and you'll most likely find it. Well, I found a few. No idea how to get them to work though (so far for the 'easy' part of my question) I think there is a lot of demand for a git-hg bridge, a way to seemlessly access a Mercurial repository as if it was a git repository. A converse to hg-git http://hg-git.github.com/ As you discovered, there are several attempts to this. A recent overview over some of them can be found here: https://github.com/dubiousjim/yagh/blob/master/README.md And here's a new one: https://github.com/felipec/git/blob/fc-remote-hd/contrib/remote-hd/git-remote-hg I took a look at several of them, and none satisfied me; too complicated, depends on another tool, hard to install, etc. This one is simple, and works fine. Only for local repositories, and only for fetching at the moment, but it's easy to use, and doesn't require much to install. I think it has good chances of getting into git mainline, and hopefully other people will help adding the rest of the features. The code is not hard at all :) Cheers. -- Felipe Contreras -- 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] Add new git-remote-hd helper
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
I've looked at many hg-git tools and none satisfy me. Too complicated, or too
slow, or to difficult to setup, etc.
The only one I've liked so far is hg-fast-export[1], which is indeed fast,
relatively simple, and relatively easy to use. But it's not properly maintained
any more.
So, I decided to write my own from scratch, using hg-fast-export as
inspiration, and voila.
This one doesn't have any dependencies, just put it into your $PATH, and you
can clone and fetch hg repositories. More importantly to me; the code is
simple, and easy to maintain.
[1] http://repo.or.cz/w/fast-export.git
contrib/remote-hd/git-remote-hg | 231
1 file changed, 231 insertions(+)
create mode 100755 contrib/remote-hd/git-remote-hg
diff --git a/contrib/remote-hd/git-remote-hg b/contrib/remote-hd/git-remote-hg
new file mode 100755
index 000..9157b30
--- /dev/null
+++ b/contrib/remote-hd/git-remote-hg
@@ -0,0 +1,231 @@
+#!/usr/bin/python2
+
+# Inspired by Rocco Rutte's hg-fast-export
+
+# Just copy to your ~/bin, or anywhere in your $PATH.
+# Then you can clone with:
+# hg::file:///path/to/mercurial/repo/
+
+from mercurial import hg, ui
+
+import re
+import sys
+import os
+import json
+
+def die(msg, *args):
+print sys.stderr, 'ERROR:', msg % args
+sys.exit(1)
+
+def gitmode(flags):
+return 'l' in flags and '12' or 'x' in flags and '100755' or '100644'
+
+def export_file(fc):
+if fc.path() == '.hgtags':
+return
+d = fc.data()
+print M %s inline %s % (gitmode(fc.flags()), fc.path())
+print data %d % len(d)
+print d
+
+def get_filechanges(repo, ctx, parents):
+l = [repo.status(p, ctx)[:3] for p in parents]
+changed, added, removed = [sum(e, []) for e in zip(*l)]
+return added + changed, removed
+
+author_re = re.compile('^((.+?) )?(.+?)$')
+
+def fixup_user(user):
+user = user.replace('', '')
+m = author_re.match(user)
+if m:
+name = m.group(1)
+mail = m.group(3)
+else:
+name = user
+mail = None
+
+if not name:
+name = 'Unknown'
+if not mail:
+mail = 'unknown'
+
+return '%s %s' % (name, mail)
+
+def get_repo(path, alias):
+myui = ui.ui()
+myui.setconfig('ui', 'interactive', 'off')
+repo = hg.repository(myui, path)
+return repo
+
+def hg_branch(b):
+if b == 'master':
+return 'default'
+return b
+
+def git_branch(b):
+if b == 'default':
+return 'master'
+return b
+
+def export_tag(repo, tag):
+global prefix
+print reset %s/tags/%s % (prefix, tag)
+print from :%s % (repo[tag].rev() + 1)
+print
+
+def export_branch(repo, branch):
+global prefix, marks, cache, branches
+
+heads = branches[hg_branch(branch)]
+
+# verify there's only one head
+if (len(heads) 1):
+die(Branch '%s' has more than one head % hg_branch(branch))
+
+head = repo[heads[0]]
+tip = marks.get(branch, 0)
+# mercurial takes too much time checking this
+if tip == head.rev():
+# nothing to do
+return
+revs = repo.revs('%u:%u' % (tip, head))
+count = 0
+
+revs = [rev for rev in revs if not cache.get(rev, False)]
+
+for rev in revs:
+
+c = repo[rev]
+(manifest, user, (time, tz), files, desc, extra) =
repo.changelog.read(c.node())
+rev_branch = git_branch(extra['branch'])
+
+tz = '%+03d%02d' % (-tz / 3600, -tz % 3600 / 60)
+
+print commit %s/branches/%s % (prefix, rev_branch)
+print mark :%d % (rev + 1)
+print committer %s %d %s % (fixup_user(user), time, tz)
+print data %d % (len(desc) + 1)
+print desc
+print
+
+parents = [p for p in repo.changelog.parentrevs(rev) if p = 0]
+
+if len(parents) == 0:
+modified = c.manifest().keys()
+removed = []
+else:
+added = []
+changed = []
+print from :%s % (parents[0] + 1)
+if len(parents) 1:
+print merge :%s % (parents[1] + 1)
+modified, removed = get_filechanges(repo, c, parents)
+
+for f in removed:
+print D %s % (f)
+for f in modified:
+export_file(c.filectx(f))
+print
+
+count += 1
+if (count % 100 == 0):
+print progress revision %d '%s' (%d/%d) % (rev, branch, count,
len(revs))
+print
#
+
+cache[rev] = True
+
+# store the latest revision
+marks[branch] = rev
+
+def do_capabilities(repo, args):
+global prefix, dirname
+
+print import
+print refspec refs/heads/*:%s/branches/* % prefix
+print refspec refs/tags/*:%s/tags/* % prefix
+
+path = os.path.join(dirname, 'marks-git')
+
+print *export-marks %s % path
+if os.path.exists(path):
+print *import-marks %s
Re: [PATCH] notes: mention --notes in more places
On 10/16/2012 11:51 PM, Jeff King wrote: It may also make sense to show notes differently when outputting the email format as format-patch does. E.g., using a triple-dash would keep them separate from the commit message when using git am. Like: your commit message Signed-off-by: You --- your notes go here That's _precisely_ what I want! I want to use notes as a way of tracking my edits for what I did in v2 of a patch, at the time I commit my v2, so that I can send a revised series including the notes in a manner most efficient for someone else using 'git am' on the series to see why I sent a v2 but without polluting the upstream repository with useless versioning information from the email. We've talked about it several times, but it's never happened (probably because most people don't actually use notes). And people (like me) don't use notes because they aren't documented. Catch-22, so we have to start somewhere. I'll submit a v2 with the non-controversial edits, and spend some time trying to figure out how to isolate the portion of pretty-options.txt that is relevant to format-patch. If it's easy enough, I can also consider using --- instead of Notes: as the separator when using format-patch. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [PATCH] Add new git-remote-hd helper
Hi, On Wed, 17 Oct 2012, Felipe Contreras wrote: I've looked at many hg-git tools and none satisfy me. Too complicated, or too slow, or to difficult to setup, etc. The one I merged into Git for Windows (since that is what I install on all my machines even if they run Linux) is rock-solid. It also comes with tests. And it requires a fix I tried to get into git.git (but failed, since I was asked to do much more in addition to what I needed for myself, and I lack the time to address such requests these days). So I have to admit that I do not quite see the point of avoiding to enhance the existing work of Sverre (and a little bit of me, too, in a hackathon for which I traveled half the continent back in July 2011). Ciao, Johannes -- 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] Add new git-remote-hd helper
On Wed, Oct 17, 2012 at 6:03 PM, Johannes Schindelin johannes.schinde...@gmx.de wrote: On Wed, 17 Oct 2012, Felipe Contreras wrote: I've looked at many hg-git tools and none satisfy me. Too complicated, or too slow, or to difficult to setup, etc. The one I merged into Git for Windows (since that is what I install on all my machines even if they run Linux) is rock-solid. It also comes with tests. And it requires a fix I tried to get into git.git (but failed, since I was asked to do much more in addition to what I needed for myself, and I lack the time to address such requests these days). Maybe, but who uses it? It's quite a lot of code, and it's quite difficult to setup--you would need a non-vanilla version of git. Compare this: 32 files changed, 3351 insertions(+), 289 deletions(-) To this: 1 file changed, 231 insertions(+) I would like to first get something that works in, and then step by step work on top of that. Anyway, I'm not even sure which version you are talking about, because there's plenty out there: https://github.com/SRabbelier/git/network So I have to admit that I do not quite see the point of avoiding to enhance the existing work of Sverre (and a little bit of me, too, in a hackathon for which I traveled half the continent back in July 2011). It's way too much code, to be specific; 15x the code I just submitted. It would be better to work together, but to me the code-styles are way too different, the difference between night and day. If you are interested in simplifying that code, get rid of the classes of classes of classes and have something more consolidated, I could try to contribute, but I doubt that's the case. Anyway, this is 231 lines of code, and works just fine, which is better than what we have in git.git for mercurial: basically nothing. Cheers. -- Felipe Contreras -- 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
Fix git diff --stat for interesting - but empty - file changes
The behavior of git diff --stat is rather odd for files that have zero lines of changes: it will discount them entirely unless they were renames. Which means that the stat output will simply not show files that only had other changes: they were created or deleted, or their mode was changed. Now, those changes do show up in the summary, but so do renames, so the diffstat logic is inconsistent. Why does it show renames with zero lines changed, but not mode changes or added files with zero lines changed? So change the logic to not check for is_renamed, but for is_interesting instead, where interesting is judged to be any action but a pure data change (because a pure data change with zero data changed really isn't worth showing, if we ever get one in our diffpairs). So if you did chmod +x Makefile git diff --stat before, it would show empty ( 0 files changed), with this it shows Makefile | 0 1 file changed, 0 insertions(+), 0 deletions(-) which I think is a more correct diffstat (and then with --summary it shows *what* the metadata change to Makefile was - this is completely consistent with our handling of renamed files). Side note: the old behavior was *really* odd. With no changes at all, git diff --stat output was empty. With just a chmod, it said 0 files changed. No way is our legacy behavior sane. Signed-off-by: Linus Torvalds torva...@linux-foundation.org --- This was triggered by kernel developers not noticing that they had added zero-sized files, because those additions never showed up in the diffstat. NOTE! This does break two of our tests, so we clearly did this on purpose, or at least tested for it. I just uncommented the subtests that this makes irrelevant, and changed the output of another one. Another test was simply buggy. It used git diff --root cmit, and thought that would be the diff against root. It isn't, and never has been. It just happened to give the same (no file) output before. Fixing --stat to show new files showed how buggy the test was. The --root thing matters for git show or git log (when showing a root commit) and for git diff-tree with a single tree. Maybe we would *want* to make git diff --root cmit be the diff between root and cmit, but that's not what it actually is. Comments? patch.diff Description: Binary data
Aw: Re: [Patch v3 0/8] Create single PDF for all HTML files
- Original Nachricht Von: Junio C Hamano gits...@pobox.com An: Thomas Ackermann th.acke...@arcor.de Datum: 17.10.2012 00:11 Betreff: Re: [Patch v3 0/8] Create single PDF for all HTML files I (and other people who wrote documentation, I suspect, as well) feel somewhat offended by the word fix here and there in the message in commits that turn files that so far have been plain text into asciidoc, though ;-). When I started working on this topic, I was wondering why not all files in ./technical and ./howto where converted to html. So I tried it myself and found out, that only minor changes where needed to get them processed by asciidoc. So from my perspective I was simply fixing some asciidoc problems. But of course this wording was never meant to offend anybody. Sorry for that. BTW1: As only the changes in the doc files where cherry-picked, currently on pu howto-index.sh will create invalid links in howto-index.html because it scans all .txt-files in ./howto for 'Content-type: text/asciidoc' and if found, creates a reference to a html file. But these are not created for the new asciidoc files. So the changes in Documentation/Makefile which create html for the new files should be merged also. BTW2: The 'pretty-print shell script in update-hook-example.txt' part of my changes was left out from the merge to pu but should also be considered as belonging to the category 'convert plain text files to asciidoc' as the original file contained a mixture of tabs and spaces which caused suboptimal indendation formatting with asciidoc. --- Thomas -- 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 v5 1/3] completion: add new __gitcompadd helper
On Sun, Oct 14, 2012 at 05:52:49PM +0200, Felipe Contreras wrote:
The idea is to never touch the COMPREPLY variable directly.
This allows other completion systems override __gitcompadd, and do
something different instead.
Also, this allows the simplifcation of the completino tests (separate
patch).
There should be no functional changes.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/completion/git-completion.bash | 65
++
1 file changed, 34 insertions(+), 31 deletions(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index d743e56..01325de 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -225,6 +225,11 @@ _get_comp_words_by_ref ()
fi
fi
+__gitcompadd ()
+{
+ COMPREPLY=($(compgen -W $1 -P $2 -S $4 -- $3))
+}
+
# Generates completion reply with compgen, appending a space to possible
# completion words, if necessary.
# It accepts 1 to 4 arguments:
@@ -238,13 +243,11 @@ __gitcomp ()
case $cur_ in
--*=)
- COMPREPLY=()
+ __gitcompadd
;;
*)
local IFS=$'\n'
- COMPREPLY=($(compgen -P ${2-} \
- -W $(__gitcomp_1 ${1-} ${4-}) \
- -- $cur_))
+ __gitcompadd $(__gitcomp_1 ${1-} ${4-}) ${2-} $cur_
;;
esac
}
@@ -261,7 +264,7 @@ __gitcomp ()
__gitcomp_nl ()
{
local IFS=$'\n'
- COMPREPLY=($(compgen -P ${2-} -S ${4- } -W $1 -- ${3-$cur}))
+ __gitcompadd $1 ${2-} ${3-$cur} ${4- }
}
I feel hesitant about this change. One of the ways I'm exploring to
fix the issues with shell metacharacters and expansion in compgen is
to actually replace compgen. We already iterate over all possible
completion words in __gitcomp_1(), so it doesn't make much of a
difference to do the filtering for the current word while we are at
it. However, the way __gitcompadd() encapsulates COMPREPLY=($(compgen
...)), and tha basic idea of never touching COMPREPLY directly make
this basically impossible.
__git_heads ()
@@ -486,7 +489,7 @@ __git_complete_remote_or_refspec ()
case $cmd in
push) no_complete_refspec=1 ;;
fetch)
- COMPREPLY=()
+ __gitcompadd
return
;;
*) ;;
@@ -502,7 +505,7 @@ __git_complete_remote_or_refspec ()
return
fi
if [ $no_complete_refspec = 1 ]; then
- COMPREPLY=()
+ __gitcompadd
return
fi
[ $remote = . ] remote=
@@ -776,7 +779,7 @@ _git_am ()
return
esac
- COMPREPLY=()
+ __gitcompadd
These changes effectively run compgen in a subshell to generate an
empty completion reply. While it doesn't really matter on Linux,
it'll add another half a tenth of a second delay in those cases on my
Windows machine. At least it should be conditional, i.e. $(compgen
...) shouldn't be executed when there are no possible completion
words.
However, I think those COMPREPLY=() assignments are pointless anyway.
COMPREPLY is always empty when completion functions are invoked, so
there is no need to explicitly set it to an empty array when we don't
provide any words for completion. Their only use is basically to
explicitly tell us humans that in those cases we don't offer any words
for completion. But we don't do that consistently: there are several
places without offering words for completion and without COMPREPLY=(),
e.g. the '__git_has_doubledash return' pattern.
Perhaps it would be time to get rid of these COMPREPLY=() assignments?
}
_git_apply ()
@@ -796,7 +799,7 @@ _git_apply ()
return
esac
- COMPREPLY=()
+ __gitcompadd
}
_git_add ()
@@ -811,7 +814,7 @@ _git_add ()
return
esac
- COMPREPLY=()
+ __gitcompadd
}
_git_archive ()
@@ -856,7 +859,7 @@ _git_bisect ()
__gitcomp_nl $(__git_refs)
;;
*)
- COMPREPLY=()
+ __gitcompadd
;;
esac
}
@@ -965,7 +968,7 @@ _git_clean ()
return
;;
esac
- COMPREPLY=()
+ __gitcompadd
}
_git_clone ()
@@ -989,7 +992,7 @@ _git_clone ()
return
;;
esac
- COMPREPLY=()
+ __gitcompadd
}
_git_commit ()
@@ -1023,7 +1026,7 @@ _git_commit ()
return
esac
- COMPREPLY=()
+ __gitcompadd
}
_git_describe ()
@@ -1154,7 +1157,7 @@ _git_fsck ()
return
;;
esac
-
Re: [PATCH] Add new git-remote-hd helper
Hi, On Wed, 17 Oct 2012, Felipe Contreras wrote: On Wed, Oct 17, 2012 at 6:03 PM, Johannes Schindelin johannes.schinde...@gmx.de wrote: On Wed, 17 Oct 2012, Felipe Contreras wrote: I've looked at many hg-git tools and none satisfy me. Too complicated, or too slow, or to difficult to setup, etc. The one I merged into Git for Windows (since that is what I install on all my machines even if they run Linux) is rock-solid. It also comes with tests. And it requires a fix I tried to get into git.git (but failed, since I was asked to do much more in addition to what I needed for myself, and I lack the time to address such requests these days). Maybe, but who uses it? It's quite a lot of code, and it's quite difficult to setup--you would need a non-vanilla version of git. Okay, so the difficulty of setting it up is because it is not in mainline git.git? Compare this: 32 files changed, 3351 insertions(+), 289 deletions(-) To this: 1 file changed, 231 insertions(+) Yeah, and that's also because of the severe lack of tests. And the lack of possible code-sharing with other remote helpers. As for who uses it: https://github.com/dscho/hg It would be better to work together, but to me the code-styles are way too different, the difference between night and day. Aha. Well, okay, it was an offer to collaborate. Ciao, Johannes -- 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 v5 2/3] tests: use __gitcompadd to simplify completion tests
On Sun, Oct 14, 2012 at 05:52:50PM +0200, Felipe Contreras wrote:
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
t/t9902-completion.sh | 29 +
1 file changed, 9 insertions(+), 20 deletions(-)
diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
index 92d7eb4..49c6eb4 100755
--- a/t/t9902-completion.sh
+++ b/t/t9902-completion.sh
@@ -39,19 +39,18 @@ _get_comp_words_by_ref ()
done
}
-print_comp ()
+__gitcompadd ()
{
- local IFS=$'\n'
- echo ${COMPREPLY[*]} out
+ compgen -P ${2-} -S ${4- } -W $1 -- ${3-$cur} out
}
Please don't. Running compgen is a fundamental part of the completion
script, therefore tests must run it as it is in the completion script
and not some copy of it.
run_completion ()
{
- local -a COMPREPLY _words
+ local -a _words
local _cword
_words=( $1 )
(( _cword = ${#_words[@]} - 1 ))
- __git_wrap__git_main print_comp
+ __git_wrap__git_main
}
test_completion ()
@@ -70,12 +69,10 @@ test_expect_success '__gitcomp - trailing space -
options' '
--reset-author Z
EOF
(
- local -a COMPREPLY
I'm not sure what I was thinking when I wrote this, but using the
local keyword while not within a function but in a subshell doesn't
seem to be that clever ;) Maybe just a copy-paste from the local
variable declarations of run-completion().
cur=--re
__gitcomp --dry-run --reuse-message= --reedit-message=
--reset-author
- IFS=$newline
- echo ${COMPREPLY[*]} out
And here I should have used print_comp().
All these can be cleaned up without overriding __gitcompadd() and
potentialy compromising correctness. Will send a patch in a minute.
+ IFS=$newline
This was only necessary for echoing the array.
)
test_cmp expected out
'
@@ -88,12 +85,10 @@ test_expect_success '__gitcomp - trailing space - config
keys' '
browser.Z
EOF
(
- local -a COMPREPLY
cur=br
__gitcomp branch. branch.autosetupmerge
branch.autosetuprebase browser.
- IFS=$newline
- echo ${COMPREPLY[*]} out
+ IFS=$newline
)
test_cmp expected out
'
@@ -104,12 +99,10 @@ test_expect_success '__gitcomp - option parameter' '
resolve Z
EOF
(
- local -a COMPREPLY
cur=--strategy=re
__gitcomp octopus ours recursive resolve subtree
re
- IFS=$newline
- echo ${COMPREPLY[*]} out
+ IFS=$newline
)
test_cmp expected out
'
@@ -120,12 +113,10 @@ test_expect_success '__gitcomp - prefix' '
branch.maint.mergeoptions Z
EOF
(
- local -a COMPREPLY
cur=branch.me
__gitcomp remote merge mergeoptions rebase
branch.maint. me
- IFS=$newline
- echo ${COMPREPLY[*]} out
+ IFS=$newline
)
test_cmp expected out
'
@@ -136,12 +127,10 @@ test_expect_success '__gitcomp - suffix' '
branch.maint.Z
EOF
(
- local -a COMPREPLY
cur=branch.me
__gitcomp master maint next pu
branch. ma .
- IFS=$newline
- echo ${COMPREPLY[*]} out
+ IFS=$newline
)
test_cmp expected out
'
--
1.7.12.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
[PATCH] completion: clean up __gitcomp() tests
Clean up two issues in the tests I added in 74a8c849 (tests: add tests
for the __gitcomp() completion helper function, 2012-04-17):
- The COMPREPLY array is created using 'local -a' while in a
subshell. However, the local keyword should only be used in a
shell function, and a variable created in a subshell is by
definition local to that subshell. Use 'declare -a' instead.
- The contents of the COMPREPLY array is written through an IFS
fiddling + echo + redirection combo, although there is the
print_comp() helper function for exactly this purpose.
Signed-off-by: SZEDER Gábor sze...@ira.uka.de
---
t/t9902-completion.sh | 27 ++-
1 file changed, 10 insertions(+), 17 deletions(-)
diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
index cbd0fb66..cc375ed0 100755
--- a/t/t9902-completion.sh
+++ b/t/t9902-completion.sh
@@ -70,8 +70,6 @@ test_completion_long ()
test_completion $1
}
-newline=$'\n'
-
test_expect_success '__gitcomp - trailing space - options' '
sed -e s/Z$// expected -\EOF
--reuse-message=Z
@@ -79,12 +77,11 @@ test_expect_success '__gitcomp - trailing space - options' '
--reset-author Z
EOF
(
- local -a COMPREPLY
+ declare -a COMPREPLY
cur=--re
__gitcomp --dry-run --reuse-message= --reedit-message=
--reset-author
- IFS=$newline
- echo ${COMPREPLY[*]} out
+ print_comp
)
test_cmp expected out
'
@@ -97,12 +94,11 @@ test_expect_success '__gitcomp - trailing space - config
keys' '
browser.Z
EOF
(
- local -a COMPREPLY
+ declare -a COMPREPLY
cur=br
__gitcomp branch. branch.autosetupmerge
branch.autosetuprebase browser.
- IFS=$newline
- echo ${COMPREPLY[*]} out
+ print_comp
)
test_cmp expected out
'
@@ -113,12 +109,11 @@ test_expect_success '__gitcomp - option parameter' '
resolve Z
EOF
(
- local -a COMPREPLY
+ declare -a COMPREPLY
cur=--strategy=re
__gitcomp octopus ours recursive resolve subtree
re
- IFS=$newline
- echo ${COMPREPLY[*]} out
+ print_comp
)
test_cmp expected out
'
@@ -129,12 +124,11 @@ test_expect_success '__gitcomp - prefix' '
branch.maint.mergeoptions Z
EOF
(
- local -a COMPREPLY
+ declare -a COMPREPLY
cur=branch.me
__gitcomp remote merge mergeoptions rebase
branch.maint. me
- IFS=$newline
- echo ${COMPREPLY[*]} out
+ print_comp
)
test_cmp expected out
'
@@ -145,12 +139,11 @@ test_expect_success '__gitcomp - suffix' '
branch.maint.Z
EOF
(
- local -a COMPREPLY
+ declare -a COMPREPLY
cur=branch.me
__gitcomp master maint next pu
branch. ma .
- IFS=$newline
- echo ${COMPREPLY[*]} out
+ print_comp
)
test_cmp expected out
'
--
1.8.0.rc0.83.gc8e1777
--
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] Add new git-remote-hd helper
On Wed, Oct 17, 2012 at 7:39 PM, Johannes Schindelin johannes.schinde...@gmx.de wrote: On Wed, 17 Oct 2012, Felipe Contreras wrote: On Wed, Oct 17, 2012 at 6:03 PM, Johannes Schindelin johannes.schinde...@gmx.de wrote: On Wed, 17 Oct 2012, Felipe Contreras wrote: I've looked at many hg-git tools and none satisfy me. Too complicated, or too slow, or to difficult to setup, etc. The one I merged into Git for Windows (since that is what I install on all my machines even if they run Linux) is rock-solid. It also comes with tests. And it requires a fix I tried to get into git.git (but failed, since I was asked to do much more in addition to what I needed for myself, and I lack the time to address such requests these days). Maybe, but who uses it? It's quite a lot of code, and it's quite difficult to setup--you would need a non-vanilla version of git. Okay, so the difficulty of setting it up is because it is not in mainline git.git? My version: 1) cp contrib/remote-hg/git-remote-hg ~/bin Your version? I don't know, but it certainly will be more than one step... may more. Compare this: 32 files changed, 3351 insertions(+), 289 deletions(-) To this: 1 file changed, 231 insertions(+) Yeah, and that's also because of the severe lack of tests. And the lack of possible code-sharing with other remote helpers. What is there to share? It's 230 lines of code. And share it with which remote helpers? And trying to do so will certainly make it harder to setup. As for the tests, I don't see any tests checking that the import of tags succeeds. Oh, that's right, that is not implemented, so not surprisingly; there are no tests for that. What does a dozen passing tests tell you about the code? Not much. If my code had tests, the test for importing tags would succeed, but I chose to spend my time implementing features, and trying to make them accessible to as many people as possible... rather than writing tests. But fine, lets remove the tests out of the equation (150 lines), the number of lines of code still exceeds 3000. Cheers. -- Felipe Contreras -- 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] Add new git-remote-hd helper
On Wed, Oct 17, 2012 at 11:12 AM, Felipe Contreras felipe.contre...@gmail.com wrote: But fine, lets remove the tests out of the equation (150 lines), the number of lines of code still exceeds 3000. I don't think it's fair to just look at LOC, git-remote-hg when it was just parsing was fairly simple. Most of the current code is our copy of the python fast-import library which is only used to support pushing to mercurial. -- Cheers, Sverre Rabbelier -- 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] completion: clean up __gitcomp() tests
On Wed, Oct 17, 2012 at 7:54 PM, SZEDER Gábor sze...@ira.uka.de wrote: Clean up two issues in the tests I added in 74a8c849 (tests: add tests for the __gitcomp() completion helper function, 2012-04-17): - The COMPREPLY array is created using 'local -a' while in a subshell. However, the local keyword should only be used in a shell function, and a variable created in a subshell is by definition local to that subshell. Use 'declare -a' instead. - The contents of the COMPREPLY array is written through an IFS fiddling + echo + redirection combo, although there is the print_comp() helper function for exactly this purpose. Makes sense. But this code seems awfully similar, a helper function might help. -- Felipe Contreras -- 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 v5 2/3] tests: use __gitcompadd to simplify completion tests
On Wed, Oct 17, 2012 at 7:50 PM, SZEDER Gábor sze...@ira.uka.de wrote:
On Sun, Oct 14, 2012 at 05:52:50PM +0200, Felipe Contreras wrote:
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
t/t9902-completion.sh | 29 +
1 file changed, 9 insertions(+), 20 deletions(-)
diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
index 92d7eb4..49c6eb4 100755
--- a/t/t9902-completion.sh
+++ b/t/t9902-completion.sh
@@ -39,19 +39,18 @@ _get_comp_words_by_ref ()
done
}
-print_comp ()
+__gitcompadd ()
{
- local IFS=$'\n'
- echo ${COMPREPLY[*]} out
+ compgen -P ${2-} -S ${4- } -W $1 -- ${3-$cur} out
}
Please don't. Running compgen is a fundamental part of the completion
script, therefore tests must run it as it is in the completion script
and not some copy of it.
All right. I added this patch as an after though to help sell the idea
of __gitcompadd. Either way I'm not to worried about overriding it,
we are not really exercising any code that could catch issues with
calling compgen; we probably need specialized tests for that. In fact
I amended the quote you are quoting above as it's totally different
from the proposed __gitcompadd, but it still works nonetheless.
--
Felipe Contreras
--
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 submodule sync --recursive
Am 17.10.2012 01:20, schrieb Phil Hord: I noticed that this is not supported: git submodule sync --recursive I do not see any discussion in the relevant commits about why it cannot or should not be supported. Is it just an itch no one has scratched? I can't remember any discussions about that either, but can't think of a reason why we shouldn't support that. -- 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: Fix git diff --stat for interesting - but empty - file changes
Linus Torvalds torva...@linux-foundation.org writes: So if you did chmod +x Makefile git diff --stat before, it would show empty ( 0 files changed), with this it shows Makefile | 0 1 file changed, 0 insertions(+), 0 deletions(-) which I think is a more correct diffstat (and then with --summary it shows *what* the metadata change to Makefile was - this is completely consistent with our handling of renamed files). Side note: the old behavior was *really* odd. With no changes at all, git diff --stat output was empty. With just a chmod, it said 0 files changed. No way is our legacy behavior sane. Signed-off-by: Linus Torvalds torva...@linux-foundation.org --- This was triggered by kernel developers not noticing that they had added zero-sized files, because those additions never showed up in the diffstat. ... Comments? I think listing a file whose content remain unchanged with 0 as the number of lines affected makes sense, and it will mesh well with Duy's http://thread.gmane.org/gmane.comp.version-control.git/207749 I first wondered if we would get a division-by-zero while scaling the graph, but we do not scale smaller numbers up to fill the columns, so we should be safe. These days, we omit 0 insertions and 0 deletions, so I am not sure what you should get for this case, though: Makefile | 0 1 file changed, 0 insertions(+), 0 deletions(-) Should we just say 1 file changed? -- 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] Add new git-remote-hd helper
On Wed, Oct 17, 2012 at 8:18 PM, Sverre Rabbelier srabbel...@gmail.com wrote: On Wed, Oct 17, 2012 at 11:12 AM, Felipe Contreras felipe.contre...@gmail.com wrote: But fine, lets remove the tests out of the equation (150 lines), the number of lines of code still exceeds 3000. I don't think it's fair to just look at LOC, git-remote-hg when it was just parsing was fairly simple. Most of the current code is our copy of the python fast-import library which is only used to support pushing to mercurial. Well, as a rule of thumb more code means more places for bugs to hide. It is also quite frankly rather difficult to navigate; very spaghetti-like. I have the feeling I can implement the same fast-import functionality in a much simpler way, but for now I want to concentrate on fetching, and hopefully making it easy for people to actually use it. I would like to cooperate as much as possible, but as I said, I would rewrite a lot of that code. And also, I'm not even sure which repository contains the latest version of this code. I've seen a couple of them that are quite different, and none which are based on a recent version of git. Cheers. -- Felipe Contreras -- 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] notes: mention --notes in more places
On Wed, Oct 17, 2012 at 07:30:56AM -0600, Eric Blake wrote: We've talked about it several times, but it's never happened (probably because most people don't actually use notes). And people (like me) don't use notes because they aren't documented. Catch-22, so we have to start somewhere. Oh, I definitely agree your patch is the right direction. I was just explaining why it hasn't happened, even though people think it's a good idea. I'll submit a v2 with the non-controversial edits, and spend some time trying to figure out how to isolate the portion of pretty-options.txt that is relevant to format-patch. If it's easy enough, I can also consider using --- instead of Notes: as the separator when using format-patch. Hmm. After digging in the archive, it seems we (including both you and me!) have discussed this several times, and there are even some patches floating around. Maybe one of them would be a good starting point for your submission (I did not read carefully over all of the arguments for each): Patch from Thomas, Feb 2010: http://thread.gmane.org/gmane.comp.version-control.git/139919/focus=140818 Discussion between us, Dec 2010: http://thread.gmane.org/gmane.comp.version-control.git/163141 Patch from Michael, Apr 2011: http://thread.gmane.org/gmane.comp.version-control.git/172079 -Peff -- 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: Fix git diff --stat for interesting - but empty - file changes
On Wed, Oct 17, 2012 at 11:28 AM, Junio C Hamano gits...@pobox.com wrote: I think listing a file whose content remain unchanged with 0 as the number of lines affected makes sense, and it will mesh well with Duy's http://thread.gmane.org/gmane.comp.version-control.git/207749 I first wondered if we would get a division-by-zero while scaling the graph, but we do not scale smaller numbers up to fill the columns, so we should be safe. Note that we should be safe for a totally different - and more fundamental - reason: the zero line case is by no means new. We've always done it for the rename case. These days, we omit 0 insertions and 0 deletions, so I am not sure what you should get for this case, though: Makefile | 0 1 file changed, 0 insertions(+), 0 deletions(-) Should we just say 1 file changed? If that is what it does for the rename case, then yes. I think it should fall out naturally. Linus -- 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: error: git-fast-import died of signal 11
Hi Michael, Looks like the changes to limit solved the problem. I didn't verify if it was the stacksize or descriptors but one of those. Final repository size was 14GB from a 328GB dump file. Thanks, Uri On Tue, Oct 16, 2012 at 2:18 AM, Michael Haggerty mhag...@alum.mit.edu wrote: On 10/15/2012 05:53 PM, Uri Moszkowicz wrote: I'm trying to convert a CVS repository to Git using cvs2git. I was able to generate the dump file without problem but am unable to get Git to fast-import it. The dump file is 328GB and I ran git fast-import on a machine with 512GB of RAM. fatal: Out of memory? mmap failed: Cannot allocate memory fast-import: dumping crash report to fast_import_crash_18192 error: git-fast-import died of signal 11 How can I import the repository? What versions of git and of cvs2git are you using? If not the current versions, please try with the current versions. What is the nature of your repository (i.e., why is it so big)? Does it consist of extremely large files? A very deep history? Extremely many branches/tags? Extremely many files? Did you check whether the RAM usage of git-fast-import process was growing gradually to fill RAM while it was running vs. whether the usage seemed reasonable until it suddenly crashed? There are a few obvious possibilities: 0. There is some reason that too little of your computer's RAM is available to git-fast-import (e.g., ulimit, other processes running at the same time, much RAM being used as a ramdisk, etc). 1. Your import is simply too big for git-fast-import to hold in memory the accumulated things that it has to remember. I'm not familiar with the internals of git-fast-import, but I believe that the main thing that it has to keep in RAM is the list of marks (references to git objects that can be referred to later in the import). From your crash file, it looks like there were about 350k marks loaded at the time of the crash. Supposing each mark is about 100 bytes, this would only amount to 35 Mb, which should not be a problem (*if* my assumptions are correct). 2. Your import contains a gigantic object which individually is so big that it overflows some component of the import. (I don't know whether large objects are handled streamily; they might be read into memory at some point.) But since your computer had so much RAM this is hardly imaginable. 3. git-fast-import has a memory leak and the accumulated memory leakage is exhausting your RAM. 4. git-fast-import has some other kind of a bug. 5. The contents of the dumpfile are corrupt in a way that is triggering the problem. This could either be invalid input (e.g., an object that is reported to be quaggabytes large), or some invalid input that triggers a bug in git-fast-import. If (1), then you either need a bigger machine or git-fast-import needs architectural changes. If (2), then you either need a bigger machine or git-fast-import and/or git needs architectural changes. If (3), then it would be good to get more information about the problem so that the leak can be fixed. If this is the case, it might be possible to work around the problem by splitting the dumpfile into several parts and loading them one after the other (outputting the marks from one run and loading them into the next). If (4) or (5), then it would be helpful to narrow down the problem. It might be possible to do so by following the instructions in the cvs2svn FAQ [1] for systematically shrinking a test case to smaller size using destroy_repository.py and shrink_test_case.py. If you can create a small repository that triggers the same problem, then there is a good chance that it is easy to fix. Michael (the cvs2git maintainer) [1] http://cvs2svn.tigris.org/faq.html#testcase -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- 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: Aw: Re: [Patch v3 0/8] Create single PDF for all HTML files
Thomas Ackermann th.acke...@arcor.de writes: BTW1: As only the changes in the doc files where cherry-picked, currently on pu howto-index.sh will create invalid links in howto-index.html because it scans all .txt-files in ./howto for 'Content-type: text/asciidoc' and if found, creates a reference to a html file. But these are not created for the new asciidoc files. So the changes in Documentation/Makefile which create html for the new files should be merged also. Ah, I didn't notice that. That means that for the patch [6/8], which adds content-type to the text files, to be complete, it needs to update Makefile to produce html files from them. Thanks. BTW2: The 'pretty-print shell script in update-hook-example.txt' part of my changes was left out from the merge to pu ... Do you mean e2399e9 (Documentation/howto: convert plain text files to asciidoc, 2012-10-16), or something else? -- 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
[ANNOUNCE] Git v1.7.12.4
The latest maintenance release Git v1.7.12.4 is now available at the usual places. The release tarballs are found at: http://code.google.com/p/git-core/downloads/list and their SHA-1 checksums are: e7eb697fc12887138e44ae100165c620a1210e81 git-1.7.12.4.tar.gz 1d4ce5c8fabbf576d611effcce2f87089da1bb89 git-htmldocs-1.7.12.4.tar.gz 1f853aa40c4518a4fad829f255c96d6e21659e93 git-manpages-1.7.12.4.tar.gz Also the following public repositories all have a copy of the v1.7.12.4 tag and the maint branch that the tag points at: url = git://repo.or.cz/alt-git.git url = https://code.google.com/p/git-core/ url = git://git.sourceforge.jp/gitroot/git-core/git.git url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core url = https://github.com/gitster/git Git 1.7.12.4 Release Notes == Fixes since v1.7.12.3 - * git fetch over the dumb-http revision walker could segfault when curl's multi interface was used. * It was possible to give specific paths for asciidoc and other tools in the documentation toolchain, but not for xmlto. * gitweb did not give the correct committer timezone in its feed output due to a typo. * The -Xours (and similarly -Xtheirs) backend option to git merge -s recursive was ignored for binary files. Now it is honored. * The binary synthetic attribute made diff to treat the path as binary, but not merge. Also contains many documentation updates. Changes since v1.7.12.3 are as follows: Ben Walton (1): tests: cp -a is a GNUism Dave Borowitz (1): Documentation/Makefile: Allow custom XMLTO binary Dylan Alex Simon (1): gitweb.cgi: fix comitter_tz typo in feed Jeff King (1): http: fix segfault in handle_curl_result Junio C Hamano (6): merge: teach -Xours/-Xtheirs to binary ll-merge driver attr: binary attribute should choose built-in binary merge driver ll-merge: warn about inability to merge binary files only when we can't t1450: the order the objects are checked is undefined gitcli: parse-options lets you omit tail of long options Git 1.7.12.4 Nguyễn Thái Ngọc Duy (2): gitignore.txt: suggestions how to get literal # or ! at the beginning attr: a note about the order of .gitattributes lookup Philip Oakley (5): Doc: shallow clone deepens _to_ new depth Doc: separate gitignore pattern sources Doc add: link gitignore Doc clean: add See Also link Doc branch: show -vv option and alternative Ramkumar Ramachandra (3): t/test-lib: make sure Git has already been built test-lib: use $SHELL_PATH, not $SHELL Git url doc: mark ftp/ftps as read-only and deprecate them Richard Fearn (1): Fix spelling error in post-receive-email hook Simon Ruderich (1): l10n: de.po: fix a few minor typos -- 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
[ANNOUNCE] Git v1.8.0-rc3
A release candidate Git v1.8.0-rc3 is now available for testing at the usual places. This hopefully will be the last rc before the final that is expected to happen this weekend. The release tarballs are found at: http://code.google.com/p/git-core/downloads/list and their SHA-1 checksums are: 499d09c326857afc78d1582b1e7153e4a53712c6 git-1.8.0.rc3.tar.gz cb5236b10f0014fd66a05fe61767d6d6d5fec35e git-htmldocs-1.8.0.rc3.tar.gz cccb8dcc4c088518aa5d2c03fe3d16ad9d1c1d3d git-manpages-1.8.0.rc3.tar.gz Also the following public repositories all have a copy of the v1.8.0-rc3 tag and the master branch that the tag points at: url = git://repo.or.cz/alt-git.git url = https://code.google.com/p/git-core/ url = git://git.sourceforge.jp/gitroot/git-core/git.git url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core url = https://github.com/gitster/git Git v1.8.0 Release Notes (draft) Backward compatibility notes In the next major release (not *this* one), we will change the behavior of the git push command. When git push [$there] does not say what to push, we have used the traditional matching semantics so far (all your branches were sent to the remote as long as there already are branches of the same name over there). We will now use the simple semantics, that pushes the current branch to the branch with the same name only when the current branch is set to integrate with that remote branch. There is a user preference configuration variable push.default to change this, and git push will warn about the upcoming change until you set this variable. git branch --set-upstream is deprecated and may be removed in a relatively distant future. git branch [-u|--set-upstream-to] has been introduced with a saner order of arguments. Updates since v1.7.12 - UI, Workflows Features * A credential helper for Win32 to allow access to the keychain of the logged-in user has been added. * An initial port to HP NonStop. * A credential helper to allow access to the Gnome keyring has been added. * When git am sanitizes the Subject: line, we strip the prefix from Re: subject and also from a less common re: subject, but left the even less common RE: subject intact. We strip that now, too. * It was tempting to say git branch --set-upstream origin/master, but that tells Git to arrange the local branch origin/master to integrate with the currently checked out branch, which is highly unlikely what the user meant. The option is deprecated; use the new --set-upstream-to (with a short-and-sweet -u) option instead. * git cherry-pick learned the --allow-empty-message option to allow it to replay a commit without any log message. * After git cherry-pick -s gave control back to the user asking help to resolve conflicts, concluding git commit used to need to be run with -s if the user wants to sign it off; now the command leaves the sign-off line in the log template. * git daemon learned the --access-hook option to allow an external command to decline service based on the client address, repository path, etc. * git difftool --dir-diff learned to use symbolic links to prepare a temporary copy of the working tree when available. * git grep learned to use a non-standard pattern type by default if a configuration variable tells it to. * git log -g learned the --grep-reflog=pattern option to limit its output to commits with a reflog message that matches the given pattern. * git merge-base learned the --is-ancestor A B option to tell if A is an ancestor of B. The result is indicated by its exit status code. * git mergetool now allows users to override the actual command used with the mergetool.$name.cmd configuration variable even for built-in mergetool backends. * git rebase -i learned the --edit-todo option to open an editor to edit the instruction sheet. Foreign Interface * git svn has been updated to work with SVN 1.7. * git p4 learned the --conflicts option to specify what to do when encountering a conflict during p4 submit. Performance, Internal Implementation, etc. (please report possible regressions) * Git ships with a fall-back regexp implementation for platforms with buggy regexp library, but it was easy for people to keep using their platform regexp by mistake. A new test has been added to check this. * The check-docs build target has been updated and greatly simplified. * The test suite is run under MALLOC_CHECK_ when running with a glibc that supports the feature. * The documentation in the TeXinfo format was using indented output for materials meant to be examples that are better typeset in monospace. * Compatibility wrapper around some mkdir(2) implementations that reject parameters with trailing slash has been introduced. * Compatibility wrapper for systems that lack usable setitimer() has
Re: [PATCH] notes: mention --notes in more places
Jeff King p...@peff.net writes: On Wed, Oct 17, 2012 at 07:30:56AM -0600, Eric Blake wrote: We've talked about it several times, but it's never happened (probably because most people don't actually use notes). And people (like me) don't use notes because they aren't documented. Catch-22, so we have to start somewhere. Oh, I definitely agree your patch is the right direction. I was just explaining why it hasn't happened, even though people think it's a good idea. I'll submit a v2 with the non-controversial edits, and spend some time trying to figure out how to isolate the portion of pretty-options.txt that is relevant to format-patch. If it's easy enough, I can also consider using --- instead of Notes: as the separator when using format-patch. Hmm. After digging in the archive, it seems we (including both you and me!) have discussed this several times, and there are even some patches floating around. Maybe one of them would be a good starting point for your submission (I did not read carefully over all of the arguments for each): Thomas's oldest one looked like a good starting point but we've gained a codepath to spit out the contents of notes since then, which probably needs to be killed at least for this codepath. A few problems I noticed while looking at log-tree.c and pretty.c * pretty_print_commit() shows notes at the end of existing message. There is no provision for the callers to affect what comes between the existing log message and the notes text. * show_log() has the add-signoff that appends a sign-off after whatever pretty_print_commit() gives. Taken together, they make it unnecessarily cumbersome to inject a new sign-off and --- between the log message and notes. The easiest is to add another parameter to pretty_print_commit that is inserted immediately after the log message before notes are appended. That way, we can update show_log() to first format additional sign off (if needed) and then ---\n (again, if needed) to a new strbuf and pass it as the new argument when calling the pretty_print_commit() function. -- 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 can cause empty GIT_AUTHOR_NAME for 'git filter-branch --tree-filter' on Solaris?
On Wed, Oct 17, 2012 at 12:58:47PM +0400, Ilya Basin wrote:
JS Most likely, your sed has problems with a sed script in function
JS get_author_ident_from_commit. I tested it like this:
JS $ sh -c '. $(git --exec-path)/git-sh-setup;
JS get_author_ident_from_commit HEAD'
JS GIT_AUTHOR_NAME='Johannes Sixt'
JS GIT_AUTHOR_EMAIL='j...@kdbg.org'
JS GIT_AUTHOR_DATE='@1350025129 +0200'
JS -- Hannes
Both systems have GNU sed 4.2.1 installed. I wrote a wrapper script wor sed.
It's output attached.
The difference is letter case in sed input data:
Solaris:
/^AUTHOR /
Windows:
/^author /
Ah, so it's tr that is the culprit. We've had problems with Solaris tr
before, but usually around NULs or the use of brackets. But according to
40a7ce6 (tr portability fixes, 2008-03-12), filter-branch is already
doing it the portable way.
If you apply this patch, does your filter-branch work?
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index 178e453..58b1d69 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -68,8 +68,8 @@ set_ident () {
# author or committer
set_ident () {
- lid=$(echo $1 | tr [A-Z] [a-z])
- uid=$(echo $1 | tr [a-z] [A-Z])
+ lid=$(echo $1 | tr ABCDEFGHIJKLMNOPQRSTUVWXYZ
abcdefghijklmnopqrstuvwxyz)
+ uid=$(echo $1 | tr abcdefghijklmnopqrstuvwxyz
ABCDEFGHIJKLMNOPQRSTUVWXYZ)
pick_id_script='
/^'$lid' /{
s/'\''/'\''\\'\'\''/g
That seems like crazy overkill, but it at least will let us double-check
that the tr sequences are the problem.
-Peff
--
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 can cause empty GIT_AUTHOR_NAME for 'git filter-branch --tree-filter' on Solaris?
On Wed, Oct 17, 2012 at 02:36:23PM +0400, Ilya Basin wrote: The culprit is bad $PATH : When git-filter-branch runs, for some reason two new entries precede /usr/bin in it: /tmp/777/.ilya-sparc/bin /home/tester/.ilya/opt/SNiFF-3.2.1/bin /export/home/testora/app/testora/product/11.2.0/client_32/bin +/usr/xpg6/bin +/usr/xpg4/bin /usr/bin /home/tester/apache-ant-1.7.1/bin /usr/jdk/instances/jdk1.5.0//bin And /usr/xpg6/bin/tr fails to make AUTHOR lowercase. Hmph. Those are controlled by SANE_TOOL_PATH at git's build time, with the intent that the xpg tools are less terrible than the ones in /usr/bin on Solaris. But it sounds like that may not be the case. Yuck. I don't have a Solaris box handy. Is there a way to make sequences like A-Z work sanely with /usr/xpg6/bin/tr? Do you have any LANG or locale settings? Sometimes those can affect sequences. What does: echo AUTHOR | LANG=C LC_ALL=C /usr/xpg6/bin/tr '[A-Z]' '[a-z]' do? -Peff -- 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
[PULL REQUEST]: Please pull git-gui
The following changes since commit 942e6baa92846e5628752c65a22bc4957d8de4d0: git-gui 0.16 (2011-12-13 23:44:30 +) are available in the git repository at: git://repo.or.cz/git-gui.git tags/gitgui-0.17.0 for you to fetch changes up to f6dd784ed4c1705d465b1238f9a5971f2733e582: git-gui 0.17 (2012-10-17 21:57:29 +0100) git-gui 0.17.0 Andrew Wong (2): git-gui: Detect full path when parsing arguments git-gui: Don't prepend the prefix if value looks like a full path Beat Bolli (2): git-gui: Fix a loose/lose mistake git-gui: remove .git/CHERRY_PICK_HEAD after committing Benjamin Kerensa (1): git-gui: fix a typo in po/ files Clemens Buchacher (1): git-gui: fix git-gui crash due to uninitialized variable Heiko Voigt (1): git-gui: open console when using --trace on windows Marcus Karlsson (1): git-gui: Use PWD if it exists on Mac OS X Pat Thoyts (3): git-gui: preserve commit messages in utf-8 Merge branch 'rt/trans' git-gui 0.17 Ralf Thielow (3): git-gui: de.po: consistently add untranslated hook names within braces git-gui: de.po: translate bare as bloß git-gui: de.po: translate remote as extern Vitaly _Vi Shukela (1): git-gui: Fix semi-working shortcuts for unstage and revert GIT-VERSION-GEN| 2 +- git-gui.sh | 36 ++-- lib/commit.tcl | 3 ++- lib/status_bar.tcl | 1 + macosx/AppMain.tcl | 4 +++- po/de.po | 38 +++--- po/fr.po | 2 +- po/git-gui.pot | 2 +- po/hu.po | 2 +- po/it.po | 2 +- po/ja.po | 2 +- po/nb.po | 2 +- po/pt_br.po| 2 +- po/ru.po | 2 +- po/sv.po | 2 +- 15 files changed, 65 insertions(+), 37 deletions(-) -- 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] Add new git-remote-hd helper
On Wed, Oct 17, 2012 at 02:58:41PM +0200, Felipe Contreras wrote:
I've looked at many hg-git tools and none satisfy me. Too complicated, or
too
slow, or to difficult to setup, etc.
I run into this every few months, evaluate all of the options, and come
to the same conclusion. So I am excited at the prospect of something
simple that just works out of the box.
Unfortunately, when I tried it, it did not work for me. :(
Details below.
contrib/remote-hd/git-remote-hg | 231
1 file changed, 231 insertions(+)
create mode 100755 contrib/remote-hd/git-remote-hg
Is this hd a typo, or is there something clever I am missing?
--- /dev/null
+++ b/contrib/remote-hd/git-remote-hg
@@ -0,0 +1,231 @@
+#!/usr/bin/python2
I do not have /usr/bin/python2. I do have (on my Debian box):
$ ls -l /usr/bin/python* | perl -lne 'print $ if m{/.*}'
/usr/bin/python - python2.7
/usr/bin/python2.6
/usr/bin/python2.7
/usr/bin/python3 - python3.2
/usr/bin/python3.2 - python3.2mu
/usr/bin/python3.2mu
/usr/bin/python3mu - python3.2mu
Obviously a minor, easily fixable issue, but I wonder if it should ship
with a more portable default (like just /usr/bin/python, or even
/usr/bin/env python).
+# Inspired by Rocco Rutte's hg-fast-export
+
+# Just copy to your ~/bin, or anywhere in your $PATH.
+# Then you can clone with:
+# hg::file:///path/to/mercurial/repo/
The first thing I tried was:
$ git clone hg::https://code.google.com/p/dactyl/
Cloning into 'dactyl'...
fatal: Unable to find remote helper for 'hg'
sigill:~/compile/dactyl$ git clone hg::https://code.google.com/p/dactyl/
Cloning into 'dactyl'...
Traceback (most recent call last):
File /home/peff/local/bin/git-remote-hg, line 231, in module
sys.exit(main(sys.argv))
File /home/peff/local/bin/git-remote-hg, line 222, in main
do_list(repo, args)
File /home/peff/local/bin/git-remote-hg, line 159, in do_list
head = repo.dirstate.branch()
AttributeError: 'httpsrepository' object has no attribute 'dirstate'
So we are failing here:
+def do_list(repo, args):
+global branches
+
+head = repo.dirstate.branch()
+for branch in repo.branchmap():
+heads = repo.branchheads(branch)
+if len(heads):
+branches[branch] = heads
Is there a way to get this information for remote repos?
I worked around it by doing an hg-clone and trying to git-clone from
that local clone. But that didn't work either:
$ hg clone https://code.google.com/p/dactyl/ hg
[... clone eventually completes ...]
$ git clone hg::$PWD/hg git
Cloning into 'git'...
progress revision 99 'pentadactyl-1.0b5-branch' (100/5367)
[... many more progress updates ...]
progress revision 6766 'cpg-hack' (1400/1467)
ERROR: Branch 'default' has more than one head
error: refs/tags/VIMPERATOR_2_2_b1 does not point to a valid object!
error: refs/tags/muttator-0.5 does not point to a valid object!
error: refs/tags/pentadactyl-1.0 does not point to a valid object!
error: refs/tags/pentadactyl-1.0b1 does not point to a valid object!
error: refs/tags/pentadactyl-1.0b2 does not point to a valid object!
error: refs/tags/pentadactyl-1.0b3 does not point to a valid object!
error: refs/tags/pentadactyl-1.0b4 does not point to a valid object!
error: refs/tags/pentadactyl-1.0b4.1 does not point to a valid object!
error: refs/tags/pentadactyl-1.0b4.2 does not point to a valid object!
error: refs/tags/pentadactyl-1.0b4.3 does not point to a valid object!
error: refs/tags/pentadactyl-1.0b5 does not point to a valid object!
error: refs/tags/pentadactyl-1.0b5.1 does not point to a valid object!
error: refs/tags/pentadactyl-1.0b6 does not point to a valid object!
error: refs/tags/pentadactyl-1.0b7 does not point to a valid object!
error: refs/tags/pentadactyl-1.0b7.1 does not point to a valid object!
error: refs/tags/pentadactyl-1.0rc1 does not point to a valid object!
error: refs/tags/vimperator-0.4.1 does not point to a valid object!
error: refs/tags/vimperator-0.5 does not point to a valid object!
error: refs/tags/vimperator-0.5-branch-HEAD-merge-1 does not point to a valid
object!
error: refs/tags/vimperator-0.5.1 does not point to a valid object!
error: refs/tags/vimperator-0.5.2 does not point to a valid object!
error: refs/tags/vimperator-0.5.3 does not point to a valid object!
error: refs/tags/vimperator-1.0 does not point to a valid object!
error: refs/tags/vimperator-1.1 does not point to a valid object!
error: refs/tags/vimperator-1.2 does not point to a valid object!
error: refs/tags/vimperator-2.0 does not point to a valid object!
error: refs/tags/vimperator-2.0a1 does not point to a valid object!
error: refs/tags/vimperator-2.1 does not point to a valid object!
error: refs/tags/vimperator-2.2 does not point to a valid object!
error: refs/tags/vimperator-2.2b1 does not point to a valid object!
error:
Re: [PULL REQUEST]: Please pull git-gui
Thanks; will pull. -- 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 1/2] status: refactor output format to represent default
From: Jeff King p...@peff.net
When deciding which output format to use, we default an
internal enum to STATUS_FORMAT_LONG and modify it if
--porcelain or --short is given. If this enum is set to
LONG, then we know the user has not specified any format,
and we can kick in default behaviors. This works because
there is no --long which they could use to explicitly
specify LONG.
Let's expand the enum to have an explicit STATUS_FORMAT_NONE,
in preparation for adding --long. Then we can distinguish
between LONG and NONE when setting other defaults. There are
two such cases:
1. The user has asked for NUL termination. With NONE, we
currently default to turning on the porcelain mode.
With an explicit --long, we would in theory use NUL
termination with the long mode, but it does not support
it. So we can just complain and die.
2. When an output format is given to git commit, we
default to --dry-run. This behavior would now kick in
when --long is given, too.
Signed-off-by: Jeff King p...@peff.net
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Two die()s with --long are moved to the next patch where --long is
introduced.
builtin/commit.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index a17a5df..984e29c 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -112,10 +112,11 @@ static const char *only_include_assumed;
static struct strbuf message = STRBUF_INIT;
static enum {
+ STATUS_FORMAT_NONE = 0,
STATUS_FORMAT_LONG,
STATUS_FORMAT_SHORT,
STATUS_FORMAT_PORCELAIN
-} status_format = STATUS_FORMAT_LONG;
+} status_format;
static int opt_parse_m(const struct option *opt, const char *arg, int unset)
{
@@ -454,6 +455,7 @@ static int run_status(FILE *fp, const char *index_file,
const char *prefix, int
case STATUS_FORMAT_PORCELAIN:
wt_porcelain_print(s);
break;
+ case STATUS_FORMAT_NONE:
case STATUS_FORMAT_LONG:
wt_status_print(s);
break;
@@ -1058,9 +1060,11 @@ static int parse_and_validate_options(int argc, const
char *argv[],
if (all argc 0)
die(_(Paths with -a does not make sense.));
- if (s-null_termination status_format == STATUS_FORMAT_LONG)
- status_format = STATUS_FORMAT_PORCELAIN;
- if (status_format != STATUS_FORMAT_LONG)
+ if (s-null_termination) {
+ if (status_format == STATUS_FORMAT_NONE)
+ status_format = STATUS_FORMAT_PORCELAIN;
+ }
+ if (status_format != STATUS_FORMAT_NONE)
dry_run = 1;
return argc;
@@ -1186,8 +1190,10 @@ int cmd_status(int argc, const char **argv, const char
*prefix)
builtin_status_usage, 0);
finalize_colopts(s.colopts, -1);
- if (s.null_termination status_format == STATUS_FORMAT_LONG)
- status_format = STATUS_FORMAT_PORCELAIN;
+ if (s.null_termination) {
+ if (status_format == STATUS_FORMAT_NONE)
+ status_format = STATUS_FORMAT_PORCELAIN;
+ }
handle_untracked_files_arg(s);
if (show_ignored_in_status)
@@ -1216,6 +1222,7 @@ int cmd_status(int argc, const char **argv, const char
*prefix)
case STATUS_FORMAT_PORCELAIN:
wt_porcelain_print(s);
break;
+ case STATUS_FORMAT_NONE:
case STATUS_FORMAT_LONG:
s.verbose = verbose;
s.ignore_submodule_arg = ignore_submodule_arg;
--
1.8.0.rc2.32.g1729c8c
--
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 2/2] status: add --long for default format
This could be useful when the user sets an alias to status --short
and wants to get the default format back temporarily.
git-commit also learns --long mostly for consistency as there's little
chance that someone adds an alias for git commit --short then wants
a one shot --long output.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Documentation/git-commit.txt | 4
Documentation/git-status.txt | 3 +++
builtin/commit.c | 10 ++
3 files changed, 17 insertions(+)
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 9594ac8..3acf2e7 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -109,6 +109,10 @@ OPTIONS
format. See linkgit:git-status[1] for details. Implies
`--dry-run`.
+--long::
+ When doing a dry-run, give the output in a the long-format.
+ Implies `--dry-run`.
+
-z::
--null::
When showing `short` or `porcelain` status output, terminate
diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt
index 67e5f53..9f1ef9a 100644
--- a/Documentation/git-status.txt
+++ b/Documentation/git-status.txt
@@ -38,6 +38,9 @@ OPTIONS
across git versions and regardless of user configuration. See
below for details.
+--long::
+ Give the output in the long-format. This is the default.
+
-u[mode]::
--untracked-files[=mode]::
Show untracked files.
diff --git a/builtin/commit.c b/builtin/commit.c
index 984e29c..1dd2ec5 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -1063,6 +1063,8 @@ static int parse_and_validate_options(int argc, const
char *argv[],
if (s-null_termination) {
if (status_format == STATUS_FORMAT_NONE)
status_format = STATUS_FORMAT_PORCELAIN;
+ else if (status_format == STATUS_FORMAT_LONG)
+ die(_(--long and -z are incompatible));
}
if (status_format != STATUS_FORMAT_NONE)
dry_run = 1;
@@ -1163,6 +1165,9 @@ int cmd_status(int argc, const char **argv, const char
*prefix)
OPT_SET_INT(0, porcelain, status_format,
N_(machine-readable output),
STATUS_FORMAT_PORCELAIN),
+ OPT_SET_INT(0, long, status_format,
+ N_(show status in long format (default)),
+ STATUS_FORMAT_LONG),
OPT_BOOLEAN('z', null, s.null_termination,
N_(terminate entries with NUL)),
{ OPTION_STRING, 'u', untracked-files, untracked_files_arg,
@@ -1193,6 +1198,8 @@ int cmd_status(int argc, const char **argv, const char
*prefix)
if (s.null_termination) {
if (status_format == STATUS_FORMAT_NONE)
status_format = STATUS_FORMAT_PORCELAIN;
+ else if (status_format == STATUS_FORMAT_LONG)
+ die(_(--long and -z are incompatible));
}
handle_untracked_files_arg(s);
@@ -1393,6 +1400,9 @@ int cmd_commit(int argc, const char **argv, const char
*prefix)
OPT_BOOLEAN(0, branch, s.show_branch, N_(show branch
information)),
OPT_SET_INT(0, porcelain, status_format,
N_(machine-readable output),
STATUS_FORMAT_PORCELAIN),
+ OPT_SET_INT(0, long, status_format,
+ N_(show status in long format (default)),
+ STATUS_FORMAT_LONG),
OPT_BOOLEAN('z', null, s.null_termination,
N_(terminate entries with NUL)),
OPT_BOOLEAN(0, amend, amend, N_(amend previous commit)),
--
1.8.0.rc2.32.g1729c8c
--
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 v2 1/2] status: refactor output format to represent default
On Thu, Oct 18, 2012 at 08:57:59AM +0700, Nguyen Thai Ngoc Duy wrote: From: Jeff King p...@peff.net When deciding which output format to use, we default an internal enum to STATUS_FORMAT_LONG and modify it if --porcelain or --short is given. If this enum is set to LONG, then we know the user has not specified any format, and we can kick in default behaviors. This works because there is no --long which they could use to explicitly specify LONG. Let's expand the enum to have an explicit STATUS_FORMAT_NONE, in preparation for adding --long. Then we can distinguish between LONG and NONE when setting other defaults. There are two such cases: 1. The user has asked for NUL termination. With NONE, we currently default to turning on the porcelain mode. With an explicit --long, we would in theory use NUL termination with the long mode, but it does not support it. So we can just complain and die. 2. When an output format is given to git commit, we default to --dry-run. This behavior would now kick in when --long is given, too. Signed-off-by: Jeff King p...@peff.net Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- Two die()s with --long are moved to the next patch where --long is introduced. I think that is fine to split it like this, but you would want to update the commit message above. Probably just remove those two cases and say something like: Note that you cannot actually trigger STATUS_FORMAT_LONG, as we do not yet have --long; that will come in a follow-on patch. And then move the reasoning for how --long works with each case into the commit message of the next patch. Other than that, the patches look OK to me. -Peff -- 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
[WIP-PATCH 0/3] Cleaning up notes in log output
This is only the preparatory step. The obvious next one that follows will swap the add-sign-off logic and appending of notes, so that sign-off will come before the notes. And then, we will insert --- before we add notes, leave a bit in the rev_info for the later step in the codepath to tell it that it does not have to add another ---, and tweak the existing codepath that adds --- to refrain from doing so. Junio C Hamano (3): pretty: remove reencode_commit_message() pretty: prepare notes message at a centralized place pretty_print_commit(): do not append notes message builtin/blame.c | 5 +++-- commit.h| 4 +--- log-tree.c | 17 - pretty.c| 22 -- 4 files changed, 24 insertions(+), 24 deletions(-) -- 1.8.0.rc3.112.gdb88a5e -- 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
[WIP-PATCH 1/3] pretty: remove reencode_commit_message()
This function has only two callsites, and is a thin wrapper whose
usefulness is dubious. When the caller needs to learn the log
output encoding, it should be able to do so by directly calling
get_log_output_encoding() and calling the underlying
logmsg_reencode() with it.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
builtin/blame.c | 5 +++--
commit.h| 2 --
pretty.c| 13 ++---
3 files changed, 5 insertions(+), 15 deletions(-)
diff --git a/builtin/blame.c b/builtin/blame.c
index c27ef21..cfae569 100644
--- a/builtin/blame.c
+++ b/builtin/blame.c
@@ -1425,7 +1425,7 @@ static void get_commit_info(struct commit *commit,
int detailed)
{
int len;
- const char *subject;
+ const char *subject, *encoding;
char *reencoded, *message;
static char author_name[1024];
static char author_mail[1024];
@@ -1446,7 +1446,8 @@ static void get_commit_info(struct commit *commit,
die(Cannot read commit %s,
sha1_to_hex(commit-object.sha1));
}
- reencoded = reencode_commit_message(commit, NULL);
+ encoding = get_log_output_encoding();
+ reencoded = logmsg_reencode(commit, encoding);
message = reencoded ? reencoded : commit-buffer;
ret-author = author_name;
ret-author_mail = author_mail;
diff --git a/commit.h b/commit.h
index 9f21313..a822af8 100644
--- a/commit.h
+++ b/commit.h
@@ -99,8 +99,6 @@ extern int has_non_ascii(const char *text);
struct rev_info; /* in revision.h, it circularly uses enum cmit_fmt */
extern char *logmsg_reencode(const struct commit *commit,
const char *output_encoding);
-extern char *reencode_commit_message(const struct commit *commit,
-const char **encoding_p);
extern void get_commit_format(const char *arg, struct rev_info *);
extern const char *format_subject(struct strbuf *sb, const char *msg,
const char *line_separator);
diff --git a/pretty.c b/pretty.c
index 8b1ea9f..c311a68 100644
--- a/pretty.c
+++ b/pretty.c
@@ -1341,16 +1341,6 @@ void pp_remainder(const struct pretty_print_context *pp,
}
}
-char *reencode_commit_message(const struct commit *commit, const char
**encoding_p)
-{
- const char *encoding;
-
- encoding = get_log_output_encoding();
- if (encoding_p)
- *encoding_p = encoding;
- return logmsg_reencode(commit, encoding);
-}
-
void pretty_print_commit(const struct pretty_print_context *pp,
const struct commit *commit,
struct strbuf *sb)
@@ -1367,7 +1357,8 @@ void pretty_print_commit(const struct
pretty_print_context *pp,
return;
}
- reencoded = reencode_commit_message(commit, encoding);
+ encoding = get_log_output_encoding();
+ reencoded = logmsg_reencode(commit, encoding);
if (reencoded) {
msg = reencoded;
}
--
1.8.0.rc3.112.gdb88a5e
--
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
[WIP-PATCH 2/3] pretty: prepare notes message at a centralized place
Instead of passing a boolean show_notes around, pass an optional
string buffer that is to be inserted after the log message proper is
shown.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
commit.h | 2 +-
log-tree.c | 15 ++-
pretty.c | 10 --
3 files changed, 19 insertions(+), 8 deletions(-)
diff --git a/commit.h b/commit.h
index a822af8..e119788 100644
--- a/commit.h
+++ b/commit.h
@@ -86,7 +86,7 @@ struct pretty_print_context {
enum date_mode date_mode;
unsigned date_mode_explicit:1;
int need_8bit_cte;
- int show_notes;
+ struct strbuf *after_message_body;
struct reflog_walk_info *reflog_info;
const char *output_encoding;
};
diff --git a/log-tree.c b/log-tree.c
index c894930..95ff405 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -533,6 +533,7 @@ static void show_mergetag(struct rev_info *opt, struct
commit *commit)
void show_log(struct rev_info *opt)
{
struct strbuf msgbuf = STRBUF_INIT;
+ struct strbuf appendbuf = STRBUF_INIT;
struct log_info *log = opt-loginfo;
struct commit *commit = log-commit, *parent = log-parent;
int abbrev_commit = opt-abbrev_commit ? opt-abbrev : 40;
@@ -540,7 +541,6 @@ void show_log(struct rev_info *opt)
struct pretty_print_context ctx = {0};
opt-loginfo = NULL;
- ctx.show_notes = opt-show_notes;
if (!opt-verbose_header) {
graph_show_commit(opt-graph);
@@ -648,6 +648,18 @@ void show_log(struct rev_info *opt)
if (!commit-buffer)
return;
+ if (opt-show_notes) {
+ int flags;
+
+ if (opt-commit_format == CMIT_FMT_USERFORMAT)
+ flags = 0;
+ else
+ flags = NOTES_SHOW_HEADER | NOTES_INDENT;
+ format_display_notes(commit-object.sha1, appendbuf,
+get_log_output_encoding(), flags);
+ ctx.after_message_body = appendbuf;
+ }
+
/*
* And then the pretty-printed message itself
*/
@@ -689,6 +701,7 @@ void show_log(struct rev_info *opt)
}
strbuf_release(msgbuf);
+ strbuf_release(appendbuf);
}
int log_tree_diff_flush(struct rev_info *opt)
diff --git a/pretty.c b/pretty.c
index c311a68..bdd991c 100644
--- a/pretty.c
+++ b/pretty.c
@@ -1033,9 +1033,8 @@ static size_t format_commit_one(struct strbuf *sb, const
char *placeholder,
}
return 0; /* unknown %g placeholder */
case 'N':
- if (c-pretty_ctx-show_notes) {
- format_display_notes(commit-object.sha1, sb,
- get_log_output_encoding(), 0);
+ if (c-pretty_ctx-after_message_body) {
+ strbuf_addbuf(sb, c-pretty_ctx-after_message_body);
return 1;
}
return 0;
@@ -1418,9 +1417,8 @@ void pretty_print_commit(const struct
pretty_print_context *pp,
if (pp-fmt == CMIT_FMT_EMAIL sb-len = beginning_of_body)
strbuf_addch(sb, '\n');
- if (pp-show_notes)
- format_display_notes(commit-object.sha1, sb, encoding,
-NOTES_SHOW_HEADER | NOTES_INDENT);
+ if (pp-after_message_body)
+ strbuf_addbuf(sb, pp-after_message_body);
free(reencoded);
}
--
1.8.0.rc3.112.gdb88a5e
--
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
[WIP-PATCH 3/3] pretty_print_commit(): do not append notes message
The only case pretty_print_commit() appends notes message to the log message taken from the commit is when show_log() calls it with the after_message_body field set and the output format is not the userformat. No other users of this function sets this field in the pretty_print_context, as can be seen in the previous step. Hoist the code to append the notes message to the caller. Up to this point, no functionality change is intended. Signed-off-by: Junio C Hamano gits...@pobox.com --- log-tree.c | 2 ++ pretty.c | 3 --- 2 files changed, 2 insertions(+), 3 deletions(-) diff --git a/log-tree.c b/log-tree.c index 95ff405..6e141f0 100644 --- a/log-tree.c +++ b/log-tree.c @@ -673,6 +673,8 @@ void show_log(struct rev_info *opt) ctx.reflog_info = opt-reflog_info; ctx.fmt = opt-commit_format; pretty_print_commit(ctx, commit, msgbuf); + if ((ctx.fmt != CMIT_FMT_USERFORMAT) ctx.after_message_body) + strbuf_addbuf(msgbuf, ctx.after_message_body); if (opt-add_signoff) append_signoff(msgbuf, opt-add_signoff); diff --git a/pretty.c b/pretty.c index bdd991c..ad27325 100644 --- a/pretty.c +++ b/pretty.c @@ -1417,9 +1417,6 @@ void pretty_print_commit(const struct pretty_print_context *pp, if (pp-fmt == CMIT_FMT_EMAIL sb-len = beginning_of_body) strbuf_addch(sb, '\n'); - if (pp-after_message_body) - strbuf_addbuf(sb, pp-after_message_body); - free(reencoded); } -- 1.8.0.rc3.112.gdb88a5e -- 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] Add new git-remote-hd helper
On Thu, Oct 18, 2012 at 12:59 AM, Jeff King p...@peff.net wrote:
On Wed, Oct 17, 2012 at 02:58:41PM +0200, Felipe Contreras wrote:
I've looked at many hg-git tools and none satisfy me. Too complicated, or
too
slow, or to difficult to setup, etc.
I run into this every few months, evaluate all of the options, and come
to the same conclusion. So I am excited at the prospect of something
simple that just works out of the box.
Unfortunately, when I tried it, it did not work for me. :(
Details below.
contrib/remote-hd/git-remote-hg | 231
1 file changed, 231 insertions(+)
create mode 100755 contrib/remote-hd/git-remote-hg
Is this hd a typo, or is there something clever I am missing?
Yeah, I've fixed that now.
--- /dev/null
+++ b/contrib/remote-hd/git-remote-hg
@@ -0,0 +1,231 @@
+#!/usr/bin/python2
I do not have /usr/bin/python2. I do have (on my Debian box):
$ ls -l /usr/bin/python* | perl -lne 'print $ if m{/.*}'
/usr/bin/python - python2.7
/usr/bin/python2.6
/usr/bin/python2.7
/usr/bin/python3 - python3.2
/usr/bin/python3.2 - python3.2mu
/usr/bin/python3.2mu
/usr/bin/python3mu - python3.2mu
Obviously a minor, easily fixable issue, but I wonder if it should ship
with a more portable default (like just /usr/bin/python, or even
/usr/bin/env python).
Yeah, this has always been an issue in Arch Linux; I have to compile
git by exporting PYTHON_PATH.
I'm OK with using any of the two above suggestions above, as they are
more standard.
+# Inspired by Rocco Rutte's hg-fast-export
+
+# Just copy to your ~/bin, or anywhere in your $PATH.
+# Then you can clone with:
+# hg::file:///path/to/mercurial/repo/
The first thing I tried was:
$ git clone hg::https://code.google.com/p/dactyl/
Right, doesn't look like it works for remote repositories. I think
that's the next feature I want to implement, but to be honest, I don't
think it's a big issue. To replace this:
git clone hg::https://code.google.com/p/dactyl/
With this
hg clone https://code.google.com/p/dactyl/
git clone hg::dactyl dactyl-git
We could do what other tools do, manually clone the repository and
store it internally, but I'll rather not trick the users this way.
I worked around it by doing an hg-clone and trying to git-clone from
that local clone. But that didn't work either:
$ hg clone https://code.google.com/p/dactyl/ hg
[... clone eventually completes ...]
$ git clone hg::$PWD/hg git
Cloning into 'git'...
progress revision 99 'pentadactyl-1.0b5-branch' (100/5367)
[... many more progress updates ...]
progress revision 6766 'cpg-hack' (1400/1467)
ERROR: Branch 'default' has more than one head
Yes, this is deliberate, we can't have more than one head per branch in git.
What you should do is go to the mercurial repo, and 'hg merge' (I think).
We could just pick the first head, and warn the user instead.
But at the moment it should fail at this point, I wonder why you get
the errors below.
error: refs/tags/VIMPERATOR_2_2_b1 does not point to a valid object!
error: refs/tags/muttator-0.5 does not point to a valid object!
error: refs/tags/pentadactyl-1.0 does not point to a valid object!
error: refs/tags/pentadactyl-1.0b1 does not point to a valid object!
error: refs/tags/pentadactyl-1.0b2 does not point to a valid object!
error: refs/tags/pentadactyl-1.0b3 does not point to a valid object!
error: refs/tags/pentadactyl-1.0b4 does not point to a valid object!
error: refs/tags/pentadactyl-1.0b4.1 does not point to a valid object!
error: refs/tags/pentadactyl-1.0b4.2 does not point to a valid object!
error: refs/tags/pentadactyl-1.0b4.3 does not point to a valid object!
error: refs/tags/pentadactyl-1.0b5 does not point to a valid object!
error: refs/tags/pentadactyl-1.0b5.1 does not point to a valid object!
error: refs/tags/pentadactyl-1.0b6 does not point to a valid object!
error: refs/tags/pentadactyl-1.0b7 does not point to a valid object!
error: refs/tags/pentadactyl-1.0b7.1 does not point to a valid object!
error: refs/tags/pentadactyl-1.0rc1 does not point to a valid object!
error: refs/tags/vimperator-0.4.1 does not point to a valid object!
error: refs/tags/vimperator-0.5 does not point to a valid object!
error: refs/tags/vimperator-0.5-branch-HEAD-merge-1 does not point to a
valid object!
error: refs/tags/vimperator-0.5.1 does not point to a valid object!
error: refs/tags/vimperator-0.5.2 does not point to a valid object!
error: refs/tags/vimperator-0.5.3 does not point to a valid object!
error: refs/tags/vimperator-1.0 does not point to a valid object!
error: refs/tags/vimperator-1.1 does not point to a valid object!
error: refs/tags/vimperator-1.2 does not point to a valid object!
error: refs/tags/vimperator-2.0 does not point to a valid object!
error: refs/tags/vimperator-2.0a1 does not point to a valid object!
error:
Re: [PATCH] transport-helper: call git fast-import properly
On Wed, Oct 17, 2012 at 1:27 AM, Felipe Contreras felipe.contre...@gmail.com wrote: The marks options are being ignored right now. It seems unlikely to me that this never worked, surely no reviewer would accept a patch that doesn't actually implement the feature? What's the history here? -- Cheers, Sverre Rabbelier -- 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] Add new git-remote-hd helper
On Thu, Oct 18, 2012 at 5:44 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Thu, Oct 18, 2012 at 12:59 AM, Jeff King p...@peff.net wrote:
On Wed, Oct 17, 2012 at 02:58:41PM +0200, Felipe Contreras wrote:
I've looked at many hg-git tools and none satisfy me. Too complicated, or
too
slow, or to difficult to setup, etc.
I run into this every few months, evaluate all of the options, and come
to the same conclusion. So I am excited at the prospect of something
simple that just works out of the box.
Unfortunately, when I tried it, it did not work for me. :(
Ok, I've fixed all those issues:
http://github.com/felipec/git/blob/fc-remote-hg/contrib/remote-hg/git-remote-hg
Right now I've just added an error when using remote repositories. But
it seems there's no way around it; if we want to have support for
remote repos, we need to make a local clone.
But at the moment it should fail at this point, I wonder why you get
the errors below.
error: refs/tags/VIMPERATOR_2_2_b1 does not point to a valid object!
error: refs/tags/muttator-0.5 does not point to a valid object!
error: refs/tags/pentadactyl-1.0 does not point to a valid object!
error: refs/tags/pentadactyl-1.0b1 does not point to a valid object!
error: refs/tags/pentadactyl-1.0b2 does not point to a valid object!
error: refs/tags/pentadactyl-1.0b3 does not point to a valid object!
error: refs/tags/pentadactyl-1.0b4 does not point to a valid object!
error: refs/tags/pentadactyl-1.0b4.1 does not point to a valid object!
error: refs/tags/pentadactyl-1.0b4.2 does not point to a valid object!
error: refs/tags/pentadactyl-1.0b4.3 does not point to a valid object!
error: refs/tags/pentadactyl-1.0b5 does not point to a valid object!
error: refs/tags/pentadactyl-1.0b5.1 does not point to a valid object!
error: refs/tags/pentadactyl-1.0b6 does not point to a valid object!
error: refs/tags/pentadactyl-1.0b7 does not point to a valid object!
error: refs/tags/pentadactyl-1.0b7.1 does not point to a valid object!
error: refs/tags/pentadactyl-1.0rc1 does not point to a valid object!
error: refs/tags/vimperator-0.4.1 does not point to a valid object!
error: refs/tags/vimperator-0.5 does not point to a valid object!
error: refs/tags/vimperator-0.5-branch-HEAD-merge-1 does not point to a
valid object!
error: refs/tags/vimperator-0.5.1 does not point to a valid object!
error: refs/tags/vimperator-0.5.2 does not point to a valid object!
error: refs/tags/vimperator-0.5.3 does not point to a valid object!
error: refs/tags/vimperator-1.0 does not point to a valid object!
error: refs/tags/vimperator-1.1 does not point to a valid object!
error: refs/tags/vimperator-1.2 does not point to a valid object!
error: refs/tags/vimperator-2.0 does not point to a valid object!
error: refs/tags/vimperator-2.0a1 does not point to a valid object!
error: refs/tags/vimperator-2.1 does not point to a valid object!
error: refs/tags/vimperator-2.2 does not point to a valid object!
error: refs/tags/vimperator-2.2b1 does not point to a valid object!
error: refs/tags/xulmus-0.1 does not point to a valid object!
This is weird.
I think I know why the errors above show up; even though the helper
dies, transport-helper doesn't check the status until the very end.
Something like this should do the trick:
diff --git a/run-command.c b/run-command.c
index 1101ef7..0a859ca 100644
--- a/run-command.c
+++ b/run-command.c
@@ -559,6 +559,21 @@ int run_command(struct child_process *cmd)
return finish_command(cmd);
}
+int check_command(struct child_process *cmd)
+{
+ int status;
+ pid_t pid;
+
+ pid = waitpid(cmd-pid, status, WNOHANG);
+
+ if (pid != cmd-pid)
+ return -1;
+ if (WIFSIGNALED(status))
+ return WTERMSIG(status);
+ if (WIFEXITED(status))
+ return WEXITSTATUS(status);
+}
+
static void prepare_run_command_v_opt(struct child_process *cmd,
const char **argv,
int opt)
diff --git a/run-command.h b/run-command.h
index 44f7d2b..9019e38 100644
--- a/run-command.h
+++ b/run-command.h
@@ -45,6 +45,7 @@ struct child_process {
int start_command(struct child_process *);
int finish_command(struct child_process *);
int run_command(struct child_process *);
+int check_command(struct child_process *cmd);
extern int run_hook(const char *index_file, const char *name, ...);
diff --git a/transport-helper.c b/transport-helper.c
index cfe0988..bc1349d 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -441,6 +441,10 @@ static int fetch_with_import(struct transport *transport,
if (finish_command(fastimport))
die(Error while running fast-import);
+
+ if (check_command(data-helper))
+ die(Error while running helper);
+
free(fastimport.argv);
fastimport.argv = NULL;
@@
Re: What can cause empty GIT_AUTHOR_NAME for 'git filter-branch --tree-filter' on Solaris?
Am 10/18/2012 0:09, schrieb Jeff King:
- lid=$(echo $1 | tr [A-Z] [a-z])
- uid=$(echo $1 | tr [a-z] [A-Z])
+ lid=$(echo $1 | tr ABCDEFGHIJKLMNOPQRSTUVWXYZ
abcdefghijklmnopqrstuvwxyz)
+ uid=$(echo $1 | tr abcdefghijklmnopqrstuvwxyz
ABCDEFGHIJKLMNOPQRSTUVWXYZ)
That seems like crazy overkill, but it at least will let us double-check
that the tr sequences are the problem.
Right. But we should really be doing something like this instead to save a
few subprocesses.
-- Hannes
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index 178e453..018e56e 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -68,8 +68,8 @@ eval $functions
# author or committer
set_ident () {
- lid=$(echo $1 | tr [A-Z] [a-z])
- uid=$(echo $1 | tr [a-z] [A-Z])
+ uid=$1
+ lid=$2
pick_id_script='
/^'$lid' /{
s/'\''/'\''\\'\'\''/g
@@ -320,9 +320,9 @@ while read commit parents; do
git cat-file commit $commit ../commit ||
die Cannot read commit $commit
- eval $(set_ident AUTHOR ../commit) ||
+ eval $(set_ident AUTHOR author ../commit) ||
die setting author failed for commit $commit
- eval $(set_ident COMMITTER ../commit) ||
+ eval $(set_ident COMMITTER committer ../commit) ||
die setting committer failed for commit $commit
eval $filter_env /dev/null ||
die env filter failed: $filter_env
--
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 can cause empty GIT_AUTHOR_NAME for 'git filter-branch --tree-filter' on Solaris?
On Thu, Oct 18, 2012 at 07:31:35AM +0200, Johannes Sixt wrote: Right. But we should really be doing something like this instead to save a few subprocesses. [...] - eval $(set_ident AUTHOR ../commit) || + eval $(set_ident AUTHOR author ../commit) || I cringe a little at losing DRY-ness to avoid processes. But the repetition is pretty straightforward and obvious, and I know that some platforms are really hurt by extra processes (and this is being called for every commit). Speaking of repetition, this seems like almost the exact same parsing that happens in git-sh-setup's get_author_ident_from_commit. Maybe it's worth merging them. I suspect you could also avoid another process by parsing out both author and committer information in the same sed invocation. -Peff -- 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/6] Bring format-patch --notes closer to a real feature
This replaces the earlier wip with a real thing. We never advertised the --notes option to format-patch (or anything related to the pretty format options for that matter) because the behaviour of these options was whatever they happened to do, not what they were designed to do. It had a few obvious glitches: * The notes section was appended immediately after the log message, and then the three-dash line was added. Such a supplimental material should come after the three-dash line. * The logic to append a new sign-off with format-patch --signoff worked on the message after the note was added, which made the detection of existing sign-off lines incorrect. This updates the handling of --notes option to correct these, in an attempt to bring it closer to a real feature. Junio C Hamano (6): pretty: remove reencode_commit_message() format_note(): simplify API pretty: prepare notes message at a centralized place pretty_print_commit(): do not append notes message format-patch: append --signature after notes format-patch --notes: show notes after three-dashes builtin/blame.c | 5 +++-- commit.h| 4 +--- log-tree.c | 32 notes.c | 13 +++-- notes.h | 6 +- pretty.c| 22 -- revision.c | 2 +- revision.h | 1 + t/t4014-format-patch.sh | 15 +-- 9 files changed, 59 insertions(+), 41 deletions(-) -- 1.8.0.rc3.112.gdb88a5e -- 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/6] pretty: remove reencode_commit_message()
This function has only two callsites, and is a thin wrapper whose
usefulness is dubious. When the caller needs to learn the log
output encoding, it should be able to do so by directly calling
get_log_output_encoding() and calling the underlying
logmsg_reencode() with it.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
builtin/blame.c | 5 +++--
commit.h| 2 --
pretty.c| 13 ++---
3 files changed, 5 insertions(+), 15 deletions(-)
diff --git a/builtin/blame.c b/builtin/blame.c
index c27ef21..cfae569 100644
--- a/builtin/blame.c
+++ b/builtin/blame.c
@@ -1425,7 +1425,7 @@ static void get_commit_info(struct commit *commit,
int detailed)
{
int len;
- const char *subject;
+ const char *subject, *encoding;
char *reencoded, *message;
static char author_name[1024];
static char author_mail[1024];
@@ -1446,7 +1446,8 @@ static void get_commit_info(struct commit *commit,
die(Cannot read commit %s,
sha1_to_hex(commit-object.sha1));
}
- reencoded = reencode_commit_message(commit, NULL);
+ encoding = get_log_output_encoding();
+ reencoded = logmsg_reencode(commit, encoding);
message = reencoded ? reencoded : commit-buffer;
ret-author = author_name;
ret-author_mail = author_mail;
diff --git a/commit.h b/commit.h
index 9f21313..a822af8 100644
--- a/commit.h
+++ b/commit.h
@@ -99,8 +99,6 @@ extern int has_non_ascii(const char *text);
struct rev_info; /* in revision.h, it circularly uses enum cmit_fmt */
extern char *logmsg_reencode(const struct commit *commit,
const char *output_encoding);
-extern char *reencode_commit_message(const struct commit *commit,
-const char **encoding_p);
extern void get_commit_format(const char *arg, struct rev_info *);
extern const char *format_subject(struct strbuf *sb, const char *msg,
const char *line_separator);
diff --git a/pretty.c b/pretty.c
index 8b1ea9f..c311a68 100644
--- a/pretty.c
+++ b/pretty.c
@@ -1341,16 +1341,6 @@ void pp_remainder(const struct pretty_print_context *pp,
}
}
-char *reencode_commit_message(const struct commit *commit, const char
**encoding_p)
-{
- const char *encoding;
-
- encoding = get_log_output_encoding();
- if (encoding_p)
- *encoding_p = encoding;
- return logmsg_reencode(commit, encoding);
-}
-
void pretty_print_commit(const struct pretty_print_context *pp,
const struct commit *commit,
struct strbuf *sb)
@@ -1367,7 +1357,8 @@ void pretty_print_commit(const struct
pretty_print_context *pp,
return;
}
- reencoded = reencode_commit_message(commit, encoding);
+ encoding = get_log_output_encoding();
+ reencoded = logmsg_reencode(commit, encoding);
if (reencoded) {
msg = reencoded;
}
--
1.8.0.rc3.112.gdb88a5e
--
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/6] format_note(): simplify API
We either stuff the notes message without modification for %N
userformat, or format it for human consumption. Using two bits
is an overkill that does not benefit anybody.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
notes.c| 13 +++--
notes.h| 6 +-
pretty.c | 5 ++---
revision.c | 2 +-
4 files changed, 11 insertions(+), 15 deletions(-)
diff --git a/notes.c b/notes.c
index bc454e1..97097db 100644
--- a/notes.c
+++ b/notes.c
@@ -1204,10 +1204,11 @@ void free_notes(struct notes_tree *t)
* If the given notes_tree is NULL, the internal/default notes_tree will be
* used instead.
*
- * 'flags' is a bitwise combination of the flags for format_display_notes.
+ * (raw != 0) gives the %N userformat; otherwise, the note message is given
+ * for human consumption.
*/
static void format_note(struct notes_tree *t, const unsigned char *object_sha1,
- struct strbuf *sb, const char *output_encoding, int
flags)
+ struct strbuf *sb, const char *output_encoding, int raw)
{
static const char utf8[] = utf-8;
const unsigned char *sha1;
@@ -1244,7 +1245,7 @@ static void format_note(struct notes_tree *t, const
unsigned char *object_sha1,
if (msglen msg[msglen - 1] == '\n')
msglen--;
- if (flags NOTES_SHOW_HEADER) {
+ if (!raw) {
const char *ref = t-ref;
if (!ref || !strcmp(ref, GIT_NOTES_DEFAULT_REF)) {
strbuf_addstr(sb, \nNotes:\n);
@@ -1260,7 +1261,7 @@ static void format_note(struct notes_tree *t, const
unsigned char *object_sha1,
for (msg_p = msg; msg_p msg + msglen; msg_p += linelen + 1) {
linelen = strchrnul(msg_p, '\n') - msg_p;
- if (flags NOTES_INDENT)
+ if (!raw)
strbuf_addstr(sb, );
strbuf_add(sb, msg_p, linelen);
strbuf_addch(sb, '\n');
@@ -1270,13 +1271,13 @@ static void format_note(struct notes_tree *t, const
unsigned char *object_sha1,
}
void format_display_notes(const unsigned char *object_sha1,
- struct strbuf *sb, const char *output_encoding, int
flags)
+ struct strbuf *sb, const char *output_encoding, int
raw)
{
int i;
assert(display_notes_trees);
for (i = 0; display_notes_trees[i]; i++)
format_note(display_notes_trees[i], object_sha1, sb,
- output_encoding, flags);
+ output_encoding, raw);
}
int copy_note(struct notes_tree *t,
diff --git a/notes.h b/notes.h
index 3592b19..3324c48 100644
--- a/notes.h
+++ b/notes.h
@@ -237,10 +237,6 @@ void prune_notes(struct notes_tree *t, int flags);
*/
void free_notes(struct notes_tree *t);
-/* Flags controlling how notes are formatted */
-#define NOTES_SHOW_HEADER 1
-#define NOTES_INDENT 2
-
struct string_list;
struct display_notes_opt {
@@ -274,7 +270,7 @@ void init_display_notes(struct display_notes_opt *opt);
* You *must* call init_display_notes() before using this function.
*/
void format_display_notes(const unsigned char *object_sha1,
- struct strbuf *sb, const char *output_encoding, int
flags);
+ struct strbuf *sb, const char *output_encoding, int
raw);
/*
* Load the notes tree from each ref listed in 'refs'. The output is
diff --git a/pretty.c b/pretty.c
index c311a68..735cf0f 100644
--- a/pretty.c
+++ b/pretty.c
@@ -1035,7 +1035,7 @@ static size_t format_commit_one(struct strbuf *sb, const
char *placeholder,
case 'N':
if (c-pretty_ctx-show_notes) {
format_display_notes(commit-object.sha1, sb,
- get_log_output_encoding(), 0);
+get_log_output_encoding(), 1);
return 1;
}
return 0;
@@ -1419,8 +1419,7 @@ void pretty_print_commit(const struct
pretty_print_context *pp,
strbuf_addch(sb, '\n');
if (pp-show_notes)
- format_display_notes(commit-object.sha1, sb, encoding,
-NOTES_SHOW_HEADER | NOTES_INDENT);
+ format_display_notes(commit-object.sha1, sb, encoding, 0);
free(reencoded);
}
diff --git a/revision.c b/revision.c
index a09e60b..ddfba11 100644
--- a/revision.c
+++ b/revision.c
@@ -2236,7 +2236,7 @@ static int commit_match(struct commit *commit, struct
rev_info *opt)
if (!buf.len)
strbuf_addstr(buf, commit-buffer);
format_display_notes(commit-object.sha1, buf,
-get_log_output_encoding(), 0);
+get_log_output_encoding(), 1);
}
/* Find either in the commit object, or in the temporary */
--
1.8.0.rc3.112.gdb88a5e
--
[PATCH 3/6] pretty: prepare notes message at a centralized place
Instead of passing a boolean show_notes around, pass an optional
string that is to be inserted after the log message proper is shown.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
commit.h | 2 +-
log-tree.c | 14 +-
pretty.c | 9 -
3 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/commit.h b/commit.h
index a822af8..7b43e45 100644
--- a/commit.h
+++ b/commit.h
@@ -86,7 +86,7 @@ struct pretty_print_context {
enum date_mode date_mode;
unsigned date_mode_explicit:1;
int need_8bit_cte;
- int show_notes;
+ char *notes_message;
struct reflog_walk_info *reflog_info;
const char *output_encoding;
};
diff --git a/log-tree.c b/log-tree.c
index c894930..84e9f5b 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -540,7 +540,6 @@ void show_log(struct rev_info *opt)
struct pretty_print_context ctx = {0};
opt-loginfo = NULL;
- ctx.show_notes = opt-show_notes;
if (!opt-verbose_header) {
graph_show_commit(opt-graph);
@@ -648,6 +647,18 @@ void show_log(struct rev_info *opt)
if (!commit-buffer)
return;
+ if (opt-show_notes) {
+ int raw;
+ struct strbuf notebuf = STRBUF_INIT;
+
+ raw = (opt-commit_format == CMIT_FMT_USERFORMAT);
+ format_display_notes(commit-object.sha1, notebuf,
+get_log_output_encoding(), raw);
+ ctx.notes_message = notebuf.len
+ ? strbuf_detach(notebuf, NULL)
+ : xcalloc(1, 1);
+ }
+
/*
* And then the pretty-printed message itself
*/
@@ -689,6 +700,7 @@ void show_log(struct rev_info *opt)
}
strbuf_release(msgbuf);
+ free(ctx.notes_message);
}
int log_tree_diff_flush(struct rev_info *opt)
diff --git a/pretty.c b/pretty.c
index 735cf0f..a53eb53 100644
--- a/pretty.c
+++ b/pretty.c
@@ -1033,9 +1033,8 @@ static size_t format_commit_one(struct strbuf *sb, const
char *placeholder,
}
return 0; /* unknown %g placeholder */
case 'N':
- if (c-pretty_ctx-show_notes) {
- format_display_notes(commit-object.sha1, sb,
-get_log_output_encoding(), 1);
+ if (c-pretty_ctx-notes_message) {
+ strbuf_addstr(sb, c-pretty_ctx-notes_message);
return 1;
}
return 0;
@@ -1418,8 +1417,8 @@ void pretty_print_commit(const struct
pretty_print_context *pp,
if (pp-fmt == CMIT_FMT_EMAIL sb-len = beginning_of_body)
strbuf_addch(sb, '\n');
- if (pp-show_notes)
- format_display_notes(commit-object.sha1, sb, encoding, 0);
+ if (pp-notes_message *pp-notes_message)
+ strbuf_addstr(sb, pp-notes_message);
free(reencoded);
}
--
1.8.0.rc3.112.gdb88a5e
--
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/6] pretty_print_commit(): do not append notes message
The only case pretty_print_commit() appends notes message to the log message taken from the commit is when show_log() calls it with the notes_message field set, and the output format is not the userformat (i.e. when substituting %N). No other users of this function sets this field in the pretty_print_context, as can be easily verified in the previous step. Hoist the code to append the notes message to the caller. Up to this point, no functionality change is intended. Signed-off-by: Junio C Hamano gits...@pobox.com --- log-tree.c | 3 +++ pretty.c | 3 --- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/log-tree.c b/log-tree.c index 84e9f5b..e7e08f4 100644 --- a/log-tree.c +++ b/log-tree.c @@ -672,6 +672,9 @@ void show_log(struct rev_info *opt) ctx.reflog_info = opt-reflog_info; ctx.fmt = opt-commit_format; pretty_print_commit(ctx, commit, msgbuf); + if ((ctx.fmt != CMIT_FMT_USERFORMAT) + ctx.notes_message *ctx.notes_message) + strbuf_addstr(msgbuf, ctx.notes_message); if (opt-add_signoff) append_signoff(msgbuf, opt-add_signoff); diff --git a/pretty.c b/pretty.c index a53eb53..1925e9c 100644 --- a/pretty.c +++ b/pretty.c @@ -1417,9 +1417,6 @@ void pretty_print_commit(const struct pretty_print_context *pp, if (pp-fmt == CMIT_FMT_EMAIL sb-len = beginning_of_body) strbuf_addch(sb, '\n'); - if (pp-notes_message *pp-notes_message) - strbuf_addstr(sb, pp-notes_message); - free(reencoded); } -- 1.8.0.rc3.112.gdb88a5e -- 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 5/6] format-patch: append --signature after notes
When appending a new signature with format-patch --signature, if
the --notes option is also in effect, the location of the new
signature (and if the signature should be added in the first place)
should be decided using the contents of the original commit log
message, before the message from the notes is added.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
log-tree.c | 6 --
t/t4014-format-patch.sh | 12 ++--
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/log-tree.c b/log-tree.c
index e7e08f4..4390b11 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -672,12 +672,14 @@ void show_log(struct rev_info *opt)
ctx.reflog_info = opt-reflog_info;
ctx.fmt = opt-commit_format;
pretty_print_commit(ctx, commit, msgbuf);
+
+ if (opt-add_signoff)
+ append_signoff(msgbuf, opt-add_signoff);
+
if ((ctx.fmt != CMIT_FMT_USERFORMAT)
ctx.notes_message *ctx.notes_message)
strbuf_addstr(msgbuf, ctx.notes_message);
- if (opt-add_signoff)
- append_signoff(msgbuf, opt-add_signoff);
if (opt-show_log_size) {
printf(log size %i\n, (int)msgbuf.len);
graph_show_oneline(opt-graph);
diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh
index 959aa26..bea6381 100755
--- a/t/t4014-format-patch.sh
+++ b/t/t4014-format-patch.sh
@@ -616,8 +616,16 @@ test_expect_success 'format-patch --in-reply-to' '
'
test_expect_success 'format-patch --signoff' '
- git format-patch -1 --signoff --stdout |
- grep ^Signed-off-by: $GIT_COMMITTER_NAME $GIT_COMMITTER_EMAIL
+ git format-patch -1 --signoff --stdout out
+ grep ^Signed-off-by: $GIT_COMMITTER_NAME $GIT_COMMITTER_EMAIL out
+'
+
+test_expect_success 'format-patch --notes --signoff' '
+ git notes --ref test add -m test message HEAD
+ git format-patch -1 --signoff --stdout --notes=test out
+ # Notes message must come after S-o-b
+ ! sed /^Signed-off-by: /q out | grep test message
+ sed 1,/^Signed-off-by: /d out | grep test message
'
echo fatal: --name-only does not make sense expect.name-only
--
1.8.0.rc3.112.gdb88a5e
--
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 6/6] format-patch --notes: show notes after three-dashes
When inserting the note after the commit log message to format-patch
output, add three dashes before the note. Record the fact that we
did so in the rev_info and omit showing duplicated three dashes in
the usual codepath that is used when notes are not being shown.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
log-tree.c | 15 +++
revision.h | 1 +
t/t4014-format-patch.sh | 7 +--
3 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/log-tree.c b/log-tree.c
index 4390b11..712a22b 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -677,8 +677,13 @@ void show_log(struct rev_info *opt)
append_signoff(msgbuf, opt-add_signoff);
if ((ctx.fmt != CMIT_FMT_USERFORMAT)
- ctx.notes_message *ctx.notes_message)
+ ctx.notes_message *ctx.notes_message) {
+ if (ctx.fmt == CMIT_FMT_EMAIL) {
+ strbuf_addstr(msgbuf, ---\n);
+ opt-shown_dashes = 1;
+ }
strbuf_addstr(msgbuf, ctx.notes_message);
+ }
if (opt-show_log_size) {
printf(log size %i\n, (int)msgbuf.len);
@@ -710,6 +715,7 @@ void show_log(struct rev_info *opt)
int log_tree_diff_flush(struct rev_info *opt)
{
+ opt-shown_dashes = 0;
diffcore_std(opt-diffopt);
if (diff_queue_is_empty()) {
@@ -737,10 +743,11 @@ int log_tree_diff_flush(struct rev_info *opt)
opt-diffopt.output_prefix_data);
fwrite(msg-buf, msg-len, 1, stdout);
}
- if ((pch opt-diffopt.output_format) == pch) {
- printf(---);
+ if (!opt-shown_dashes) {
+ if ((pch opt-diffopt.output_format) == pch)
+ printf(---);
+ putchar('\n');
}
- putchar('\n');
}
}
diff_flush(opt-diffopt);
diff --git a/revision.h b/revision.h
index a95bd0b..059bfff 100644
--- a/revision.h
+++ b/revision.h
@@ -111,6 +111,7 @@ struct rev_info {
/* Format info */
unsigned intshown_one:1,
+ shown_dashes:1,
show_merge:1,
show_notes:1,
show_notes_given:1,
diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh
index bea6381..9750ba6 100755
--- a/t/t4014-format-patch.sh
+++ b/t/t4014-format-patch.sh
@@ -623,9 +623,12 @@ test_expect_success 'format-patch --signoff' '
test_expect_success 'format-patch --notes --signoff' '
git notes --ref test add -m test message HEAD
git format-patch -1 --signoff --stdout --notes=test out
- # Notes message must come after S-o-b
+ # Three dashes must come after S-o-b
! sed /^Signed-off-by: /q out | grep test message
- sed 1,/^Signed-off-by: /d out | grep test message
+ sed 1,/^Signed-off-by: /d out | grep test message
+ # Notes message must come after three dashes
+ ! sed /^---$/q out | grep test message
+ sed 1,/^---$/d out | grep test message
'
echo fatal: --name-only does not make sense expect.name-only
--
1.8.0.rc3.112.gdb88a5e
--
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
