Re: Reference to a commit inside a commit message
You should use the latest version of the patch series (v11), because the blank line is now automatically added. Yes interpret-trailers add the blank line, but when call `git commit -m $MSG -e` it isn't displayed. I think this happens due to the default value of 'cleanup' option of git-commit that is 'strip' (in my case) when the message is edited. I can't use neither 'verbatim' nor 'whitespace' otherwise all the comments will be displayed. And using ':' instead of '=' after see-also would be more standard. Thanks I've updated my script and now I'm using the latest interpret-trailers. NaN -- 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: Reference to a commit inside a commit message
Thanks to all. With interpret-trailers has been easy to make a simple script, also it checks if the Hash passed is a valid Object. I haven't found a simple way to mantain the blank line above the output of interpet-trailers (not even through cleanup). Follows the script, maybe could be usefull for somebody: #!/bin/sh for i in $* do git show $i /dev/null if [ $? = 0 ] then trailers+= see-also=$i fi done msg=$(cat /dev/null | ../git-interpret-trailers $trailers) git commit -m $msg -e -- 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][GSoC] branch.c:install_branch_config Simplified long chain of if statements
From: NaN enzodici...@gmail.com
Hi there, I've made this patch in according to the rules to participate at GSoC.
I've seen other patches about this issue very well constructed, so this is only
another way to solve this microproject and to test how I can send a patch and
discuss about it.
Thanks,
NaN
Signed-off-by: Vincenzo di Cicco enzodici...@gmail.com
---
Table-driven approach to avoid the long chain of if statements.
branch.c | 37 ++---
1 file changed, 14 insertions(+), 23 deletions(-)
diff --git a/branch.c b/branch.c
index 723a36b..cb8a544 100644
--- a/branch.c
+++ b/branch.c
@@ -53,6 +53,10 @@ void install_branch_config(int flag, const char *local,
const char *origin, cons
int remote_is_branch = starts_with(remote, refs/heads/);
struct strbuf key = STRBUF_INIT;
int rebasing = should_setup_rebase(origin);
+ struct strbuf msg = STRBUF_INIT;
+ char *locations[2][2] = {{locate ref \%s, local branch \%s},
+{remote ref \%s, remote branch \%s from
\%s}};
+ char *location;
if (remote_is_branch
!strcmp(local, shortname)
@@ -77,30 +81,17 @@ void install_branch_config(int flag, const char *local,
const char *origin, cons
strbuf_release(key);
if (flag BRANCH_CONFIG_VERBOSE) {
- if (remote_is_branch origin)
- printf_ln(rebasing ?
- _(Branch %s set up to track remote branch %s
from %s by rebasing.) :
- _(Branch %s set up to track remote branch %s
from %s.),
- local, shortname, origin);
- else if (remote_is_branch !origin)
- printf_ln(rebasing ?
- _(Branch %s set up to track local branch %s
by rebasing.) :
- _(Branch %s set up to track local branch
%s.),
- local, shortname);
- else if (!remote_is_branch origin)
- printf_ln(rebasing ?
- _(Branch %s set up to track remote ref %s by
rebasing.) :
- _(Branch %s set up to track remote ref %s.),
- local, remote);
- else if (!remote_is_branch !origin)
- printf_ln(rebasing ?
- _(Branch %s set up to track local ref %s by
rebasing.) :
- _(Branch %s set up to track local ref %s.),
- local, remote);
- else
- die(BUG: impossible combination of %d and %p,
- remote_is_branch, origin);
+ location = locations[origin != NULL][remote_is_branch];
+
+ strbuf_addstr(msg, Branch \%s set up to track );
+ strbuf_addstr(msg, location);
+ if(rebasing)
+ strbuf_addstr(msg, by rebasing);
+ strbuf_addch(msg, '.');
+
+ printf_ln(_(msg.buf), local, remote_is_branch ? remote:
shortname, origin);
}
+ strbuf_release(msg);
}
/*
--
1.9.0
--
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][GSoC] branch.c:install_branch_config Simplified long chain of if statements
Thank you very much for the answer! I've learned a lot in this few rows. If we take the time to trace through the code, we can see that remote_is_branch is indeed either 0 or 1, thus this expression is safe today, however, if the implementation of starts_with() ever changes so that it returns a value other than 1 for true, then this code will break. To avoid such breakage, and to avoid placing burden of tracing code, you might instead write the expression as: location = locations[!!origin][!!remote_is_branch]; Thanks for the good tip. I've erroneously assumed that starts_with() never will change. This approach of composing strings is problematic for translation, which is why the GSoC microproject states: Thanks to show me this issue. I've read the other thread and understood the problem. I will do better in future :) -- 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
fnmatch vs regex
Hi there, I'm NaN. Recently I enrolled to this mailing list thanks to the GSoC. I've looked the Ideas Page but -unfortunately- some projects are very difficult for me. I've looked the source code and I've seen that to perform a search with a pattern to the branches list (and other commands) git uses fnmatch() and so supports the glob pattern. I haven't never massively used the branches or the tags to have the necessity to filter in a particolar way the results, and the asterisk has always worked very well. But: why the decision to support the Blob Pattern instead of the Regular Expressions? With your experiences can a patch like this improve this side? Thanks for the awesome work, NaN -- 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
