Re: [PATCH] Add documentation on how to integrate commands.
Michael Haggerty mhag...@alum.mit.edu: I think that here a reference to the file t/README would help (and perhaps make part of your text redundant). Thank you, done. -- a href=http://www.catb.org/~esr/;Eric S. Raymond/a -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Python extension commands in git - request for policy change
On Sun, Nov 25, 2012 at 3:44 AM, Eric S. Raymond e...@thyrsus.com wrote: git presently contains one Python extension command, Pete Wycoff's p4 importer. If my git-weave code is merged it will acquire another. I think we can expect more submissions of Python extensions in the future, for two good reasons: According to the Git User Survey 2012, 1% of the responders used the 'git p4' tool. I don't know how much widely used 'git weave' would be, but I wouldn't want to star changing policies for issues that are practically non-existent or irrelevant for the vast majority of git users. We're behind the best-practices curve here. The major Linux distributions, which have to deal with almost the same set of tradeoffs we do, went to Python for pretty much all glue and administration scripts outside /etc a decade ago, and the decision has served them well. If your friends jump off a bridge, would you? Yes, using python has served them well, but as opposed to what? Other scripting languages? I don't think so. I should also point out that none of Mercurial's problems seem to have anything to do with the fact that it's written in Python... I agree that the _current_ major problems with mercurial are not related to python, but once those are solved, who says python won't be an issue?. That's an exercise in guesswork, because we can't know. I think we can choose a better policy based on some simple premises. 1) In 2012, we can specify a floor Python version of 2.6 (shipped in 2008) and be pretty much guaranteed it will be anywhere we want to deploy except Windows. Windows will remain a problem because Python isn't part of the stock install, but that's an equal or worse problem for shell and Perl - and at least the Python project ships a binary installer for Windows. What if my extension only supports python 2.7? Or what if my extension wants to support 2.0? 2) Python extension commands should test the Python version on startup and die loudly but gracefully in the rare case that they don't find what they need. Yes, they should _if_ they know what version they need. In my extensions I really have no idea. 3) We should be unconditionally be encouraging extensions to move from shell and Perl to Python. This would be a clear net gain is portability and maintainability. NO! It's up to the developer to choose what language to use, and I find it very chauvinist of you to say python is better, so let's all use python. So far you have listed a few advantages of python, but you haven't explained so far what is wrong with shell and perl. In fact, while advancing python you have made clear a problem with python; the version requirements. So far I have *never* encountered a problem with git because of my bash version, or my perl version. And we haven't touched to the python3 mess yet. To me, those are advantages of shell and perl. Actually, I don't care if 'git foo' is written in perl, or shell, or c; as long as it *works*. And I would hate it if 'git rebase' ever told me that I need a newer version of python, or worst; that I don't have python in my system (Arch Linux ships 'python2', not 'python'). And what if X developer that wrote Y tool loves perl, and hates python? Or loves ruby? Are we going to kick him out of the project because (s)he refuses to switch to python? Are we going to threat him like an outsider, a rogue developer? 4) We should be encouraging C code to move to Python, too. There's little gain in portability on this path because modern C has cleaned up its act a lot, but the drop in expected bug loads would be well worth the porting effort. Segfaults are not your friend, and the x2 to x5 drop in line count would do very good things for long-term maintainability. Definitely NO! I really really doubt git in python would be able to achieve the same performance as git in c, but to show me wrong, it wouldn't be very difficult to run a few measurements with python dulwich *if* we are even to begin considering this point. And are segmentation faults really that different from python's exceptions? Not to the user. And why not ruby instead? If you are serious about this, I think there's a lot more to work to show that there's anything wrong with the current situation, and that other alternatives (e.g. ruby) are not good solutions. I for one would like to see more tools move away from perl/shell, and into C. And other tools move to ruby, but that it's up to the developers of those tools, unless I myself do it. 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: Python extension commands in git - request for policy change
On Sun, Nov 25, 2012 at 6:18 AM, Eric S. Raymond e...@thyrsus.com wrote: Nguyen Thai Ngoc Duy pclo...@gmail.com: These may apply to other languages as well. Where do we draw a line? I'm in favor of the general policy of avoiding scripting languages other than the top three most widely deployed. At the moment that means shell, Python, Perl; on present trends, in a few years Perl (dropping in popularity) might be passed by Ruby on the way up. Top three according to whom? According to TIOBE it's python, perl, and ruby (if you don't count VB or PHP), and perl is beating ruby only by a small margin that will probably disappear soon. However, shell has advantages none of the above have. http://1.1.1.4/bmi/www.tiobe.com/content/paperinfo/tpci/images/tpci_trends.png 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: Python extension commands in git - request for policy change
Am 25.11.2012 03:44, schrieb Eric S. Raymond: That, among other things, means up-to-date versions of Python are ubiquitous unless we're looking at Windows - in which case Perl and shell actually become much bigger portability problems. You seem to ignore that more than a quater of users are on Windows[1]. This is not negligible. Therefore, we *are* looking at Windows. But where is there a portability problem? There is a POSIX shell available in all git installations on Windows. So is Perl. Python is not. [1] https://git.wiki.kernel.org/index.php/GitSurvey2011#10._On_which_operating_system.28s.29_do_you_use_Git.3F 4) We should be encouraging C code to move to Python, too. Absolutely not. To achieve best portability, all code should move to C instead. -- 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: [PATCH] emacs: make 'git-status' work with separate git dirs
Junio C Hamano gits...@pobox.com writes: Enrico Scholz enrico.sch...@sigma-chemnitz.de writes: when trying 'M-x git-status' in a submodule created with recent (1.7.5+) git, the command fails with | ... is not a git working tree This is caused by creating submodules with '--separate-git-dir' but still checking for a working tree by testing for a '.git' directory. The patch fixes this by relaxing the existing detection a little bit. Signed-off-by: Enrico Scholz enrico.sch...@sigma-chemnitz.de --- This script already relies on the assumption that nobody sane would create a directory named .git that is not a git repository, and this loosens the assumption that nobody would create a file named .git, either. So I would think it is a sane thing to do, but just in case if the area expert has better ideas, I am forwarding it. Ack? Sure, that's fine. -- Alexandre Julliard julli...@winehq.org -- 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 bash does not access drive f:
On 2012-11-22, Angelo Borsotti angelo.borso...@gmail.com wrote: Hi I have attached an external disc, which appears on Windows as drive f: in Windows Explorer. Right-clicking on it displays a context menu showing (among other items) Git Init Here, Git Gui and Git Bash. The first two work properly on that drive. However, the git bash does not. Not even the one that is run from the icon: $ cd f: sh.exe: cd: f:: No such file or directory This is probably a known limitation of MSYS (the shell environment that Git Bash uses, which is part of MingW): Drive letters added after MSYS has started only become visible if all MSYS processes are stopped and restarted. See e.g. How to register newly mounted drive in git bash? http://stackoverflow.com/questions/5197540/ for some more details. It seems there is no easy workaround, so you'll need to close all Git Bash windows and reopen them. -- 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: [msysGit] Re: Python extension commands in git - request for policy change
Pat Thoyts pattho...@gmail.com: Git for Windows simply ships everything we need to run git - so if a desirable module requires a version of python, we will add that version plus any required modules into the installer. We already have a patch to provide python in the msysgit tree - it would just require polishing up a little. I'm certain this is no problem for the other windows port (cygwin) either. Thank you - I think this completely disposes of the Windows is a blocker for scripting language X argument, with the case X = Python in point. -- a href=http://www.catb.org/~esr/;Eric S. Raymond/a -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] git-svn: Document branches with at-sign(@).
git svn will sometimes create branches with an at-sign in the name (branchname@revision). These branches confuse many users and it is a FAQ why they are created. Document when git svn will create them. Signed-off-by: Sebastian Leske sebastian.le...@sleske.name --- I found various important features of git-svn that are not documented. Thus I created a series of patches to add and update documentation for git-svn. I am sending this as four patches (of which this mail is the first). I have tried my best to make the patches ready for inclusion into git, but if there's any feedback, I'll gladly incorporate it. Documentation/git-svn.txt | 26 ++ 1 file changed, 26 insertions(+) diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt index 8b0d3ad..482d60d 100644 --- a/Documentation/git-svn.txt +++ b/Documentation/git-svn.txt @@ -881,6 +881,32 @@ different name spaces. For example: branches = stable/*:refs/remotes/svn/stable/* branches = debug/*:refs/remotes/svn/debug/* +If 'git svn' is configured to fetch branches (and --follow-branches +is in effect), it will sometimes create multiple branches for one SVN +branch, where the addtional branches have names of the form +'branchname@nnn' (with nnn an SVN revision number). These additional +branches are created if 'git svn' cannot find a parent commit for the +first commit in the branch, to connect the branch to the history of the +other branches. Normally, 'git svn' will find the git commit that +corresponds to the SVN revision a branch was created (copied) from and +use that as the parent. However, it is possible that there is no +suitable git commit to serve as parent. This will happen, among other +reasons, if the SVN branch is a copy of a revision that was not fetched +by 'git svn' (e.g. because it is an old revision that was skipped with +'--revision'), or if in SVN a directory was copied that is not tracked +by 'git svn' (a branch that is not tracked at all, or a subdirectory of +a tracked branch). In these cases, 'git svn' will still create a git +branch, but the branch will not be connected to the history of the other +branches. 'git svn' will also create a commit from the SVN revision the +branch was copied from, and use that as the parent commit of the branch +(this is indicated by the message Initializing parent: branchname). +Additionally, it will create a special branch named +'branchname@SVN-Revision', where SVN-Revision is the SVN revision +number the branch was copied from. This branch will point to the +specially created parent commit. +If in SVN the branch was deleted and later recreated from a different +version, there will be multiple such branches with an '@'. + BUGS -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Python extension commands in git - request for policy change
On 11/25/2012 09:53 AM, Felipe Contreras wrote: On Sun, Nov 25, 2012 at 3:44 AM, Eric S. Raymond e...@thyrsus.com wrote: 1) In 2012, we can specify a floor Python version of 2.6 (shipped in 2008) and be pretty much guaranteed it will be anywhere we want to deploy except Windows. Windows will remain a problem because Python isn't part of the stock install, but that's an equal or worse problem for shell and Perl - and at least the Python project ships a binary installer for Windows. What if my extension only supports python 2.7? Or what if my extension wants to support 2.0? There would obviously have to be a policy like all Python code in core git must run on any Python interpreter with 2.6 = version 3.0, just as there are policies about what C and shell features are allowed. If you happen to want to support earlier versions of Python, I don't see why anybody would stop you as long as your code also runs in the mandated versions. (In practice, backwards compatibility within Python versions 2.x is very good and almost any code that runs in Python 2.6 would automatically run in all later 2.x versions. Moreover, the Python documentation covering what is available in each version and the deltas between versions is high-quality and easily available online.) There is, of course, the awkward issue of how/when to transition to Python 3.x, which is *not* backwards compatible with Python 2.x. I expect that when the time comes there will be volunteers (myself included) willing to help adapt Python scripts to the new version, but the problem shouldn't be minimized. Of course Perl will have the same problem if Perl6 ever materializes. 2) Python extension commands should test the Python version on startup and die loudly but gracefully in the rare case that they don't find what they need. Yes, they should _if_ they know what version they need. In my extensions I really have no idea. Then simply (with the help of the mailing list) ensure that your extensions run under 2.6 (or whatever the chosen minimum version is) and everything will be OK. It is not an error to specify 2.6 as the minimum version even though your script happens also to run on older versions :-) 3) We should be unconditionally be encouraging extensions to move from shell and Perl to Python. This would be a clear net gain is portability and maintainability. NO! It's up to the developer to choose what language to use, and I find it very chauvinist of you to say python is better, so let's all use python. So far you have listed a few advantages of python, but you haven't explained so far what is wrong with shell and perl. Given that some languages are accepted in git-core and others are not, it's already not up to the developer to choose what language to use. At best there is a short list of blessed languages, and the developer can choose among only those. In fact, while advancing python you have made clear a problem with python; the version requirements. So far I have *never* encountered a problem with git because of my bash version, or my perl version. And we haven't touched to the python3 mess yet. To me, those are advantages of shell and perl. On the contrary, there is *constant* traffic on the mailing list about incompatibilities between different shell implementations (sh, dash, bash, etc), not to mention those in other utilities (sed, grep, etc) that one is forced to work with in shell scripts. Compatibility is a *huge* pain when developing shell code for git. The fact that users typically don't encounter such problems is due to the hard work of POSIX lawyers on the mailing list correcting the compatibility errors of mortal programmers. Actually, I don't care if 'git foo' is written in perl, or shell, or c; as long as it *works*. And I would hate it if 'git rebase' ever told me that I need a newer version of python, or worst; that I don't have python in my system (Arch Linux ships 'python2', not 'python'). The configure script would locate the correct interpreter and the build would adjust the scripts' shebang lines, just as things are tweaked within Perl scripts at build time. 4) We should be encouraging C code to move to Python, too. There's little gain in portability on this path because modern C has cleaned up its act a lot, but the drop in expected bug loads would be well worth the porting effort. Segfaults are not your friend, and the x2 to x5 drop in line count would do very good things for long-term maintainability. Definitely NO! I really really doubt git in python would be able to achieve the same performance as git in c, but to show me wrong, it wouldn't be very difficult to run a few measurements with python dulwich *if* we are even to begin considering this point. And are segmentation faults really that different from python's exceptions? Not to the user. There is one huge difference: it C it is all too easy to write code that leads to a security hole due to buffer
Re: Python extension commands in git - request for policy change
Michael Haggerty mhag...@alum.mit.edu: There is, of course, the awkward issue of how/when to transition to Python 3.x, which is *not* backwards compatible with Python 2.x. I expect that when the time comes there will be volunteers (myself included) willing to help adapt Python scripts to the new version, but the problem shouldn't be minimized. 2to3 actually does a pretty good job. It doesn't reduce the transition cost to zero, but I find it does reduce that cost to an easily manageable level even on quite large codebases. It would be insane to rewrite performance-critical C code in any scripting language, but there is a huge penumbra of code that is not performance critical and that mutates rapidly. Indeed. In the git architecture there is a pretty clear dividing line - to a first approximation, plumbing should remain C but porcelain should probably not. (Not that I am advocating forcing such a move - but it would be good to allow it to happen.) The 80-20 rule (80% of the execution time is spent in 20% of the code) helps us here. The *other* 80% of the code can move to a scripting language with no significant performance loss. To find out what needs to stay in C, run a profiler! -- a href=http://www.catb.org/~esr/;Eric S. Raymond/a -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/8] Add function strbuf_addstr_xml_quoted() and more
There were two functions doing almost the same XML quoting of character entities, so implement a library function strbuf_addstr_xml_quoted() and use that in both places. Along the way, do a lot of simplification within imap-send.c, which was doing a lot of its own string management instead of using strbuf. Please note that git imap-send is utterly absent from the test suite, probably due to the difficulty of testing without a real IMAP server. I ran some manual tests after my changes and didn't find any problems. The bug that I reported on 2012-11-12, namely that git format-patch --signoff --stdout --attach origin | git imap-send is broken, is not addressed by these patches. Michael Haggerty (8): Add new function strbuf_add_xml_quoted() xml_entities(): use function strbuf_addstr_xml_quoted() lf_to_crlf(): NUL-terminate msg_data::data imap-send: store all_msgs as a strbuf imap-send: correctly report errors reading from stdin imap-send: change msg_data from storing (char *, len) to storing strbuf wrap_in_html(): use strbuf_addstr_xml_quoted() wrap_in_html(): process message in bulk rather than line-by-line http-push.c | 23 + imap-send.c | 157 +++- strbuf.c| 26 ++ strbuf.h| 6 +++ 4 files changed, 104 insertions(+), 108 deletions(-) -- 1.8.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
[PATCH 2/8] xml_entities(): use function strbuf_addstr_xml_quoted()
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
http-push.c | 23 +--
1 file changed, 1 insertion(+), 22 deletions(-)
diff --git a/http-push.c b/http-push.c
index 8701c12..9923441 100644
--- a/http-push.c
+++ b/http-push.c
@@ -172,28 +172,7 @@ enum dav_header_flag {
static char *xml_entities(const char *s)
{
struct strbuf buf = STRBUF_INIT;
- while (*s) {
- size_t len = strcspn(s, \);
- strbuf_add(buf, s, len);
- s += len;
- switch (*s) {
- case '':
- strbuf_addstr(buf, quot;);
- break;
- case '':
- strbuf_addstr(buf, lt;);
- break;
- case '':
- strbuf_addstr(buf, gt;);
- break;
- case '':
- strbuf_addstr(buf, amp;);
- break;
- case 0:
- return strbuf_detach(buf, NULL);
- }
- s++;
- }
+ strbuf_addstr_xml_quoted(buf, s);
return strbuf_detach(buf, NULL);
}
--
1.8.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
[PATCH 4/8] imap-send: store all_msgs as a strbuf
all_msgs is only used as a glorified string, therefore there is no
reason to declare it as a struct msg_data.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
imap-send.c | 23 +--
1 file changed, 9 insertions(+), 14 deletions(-)
diff --git a/imap-send.c b/imap-send.c
index c818b0c..50e223a 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -1391,26 +1391,20 @@ static void wrap_in_html(struct msg_data *msg)
#define CHUNKSIZE 0x1000
-static int read_message(FILE *f, struct msg_data *msg)
+static int read_message(FILE *f, struct strbuf *all_msgs)
{
- struct strbuf buf = STRBUF_INIT;
-
- memset(msg, 0, sizeof(*msg));
-
do {
- if (strbuf_fread(buf, CHUNKSIZE, f) = 0)
+ if (strbuf_fread(all_msgs, CHUNKSIZE, f) = 0)
break;
} while (!feof(f));
- msg-len = buf.len;
- msg-data = strbuf_detach(buf, NULL);
- return msg-len;
+ return all_msgs-len;
}
-static int count_messages(struct msg_data *msg)
+static int count_messages(struct strbuf *all_msgs)
{
int count = 0;
- char *p = msg-data;
+ char *p = all_msgs-buf;
while (1) {
if (!prefixcmp(p, From )) {
@@ -1431,7 +1425,7 @@ static int count_messages(struct msg_data *msg)
return count;
}
-static int split_msg(struct msg_data *all_msgs, struct msg_data *msg, int *ofs)
+static int split_msg(struct strbuf *all_msgs, struct msg_data *msg, int *ofs)
{
char *p, *data;
@@ -1439,7 +1433,7 @@ static int split_msg(struct msg_data *all_msgs, struct
msg_data *msg, int *ofs)
if (*ofs = all_msgs-len)
return 0;
- data = all_msgs-data[*ofs];
+ data = all_msgs-buf[*ofs];
msg-len = all_msgs-len - *ofs;
if (msg-len 5 || prefixcmp(data, From ))
@@ -1509,7 +1503,8 @@ static int git_imap_config(const char *key, const char
*val, void *cb)
int main(int argc, char **argv)
{
- struct msg_data all_msgs, msg;
+ struct strbuf all_msgs = STRBUF_INIT;
+ struct msg_data msg;
struct store *ctx = NULL;
int ofs = 0;
int r;
--
1.8.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
[PATCH 5/8] imap-send: correctly report errors reading from stdin
Previously, read_message() didn't distinguish between an error and eof
when reading its input. This could have resulted in incorrect
behavior if there was an error: (1) reporting nothing to send if no
bytes were read or (2) sending an incomplete message if some bytes
were read before the error.
Change read_message() to return -1 on ferror()s and 0 on success, so
that the caller can recognize that an error occurred. (The return
value used to be the length of the input read, which was redundant
because that is already available as the strbuf length.
Change the caller to report errors correctly.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
imap-send.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/imap-send.c b/imap-send.c
index 50e223a..86cf603 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -1398,7 +1398,7 @@ static int read_message(FILE *f, struct strbuf *all_msgs)
break;
} while (!feof(f));
- return all_msgs-len;
+ return ferror(f) ? -1 : 0;
}
static int count_messages(struct strbuf *all_msgs)
@@ -1537,7 +1537,12 @@ int main(int argc, char **argv)
}
/* read the messages */
- if (!read_message(stdin, all_msgs)) {
+ if (read_message(stdin, all_msgs)) {
+ fprintf(stderr, error reading input\n);
+ return 1;
+ }
+
+ if (all_msgs.len == 0) {
fprintf(stderr, nothing to send\n);
return 1;
}
--
1.8.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
[PATCH 6/8] imap-send: change msg_data from storing (char *, len) to storing strbuf
struct msg_data stored (char *, len) of the data to be included in a
message, kept the character data NUL-terminated, etc., much like a
strbuf would do. So change it to use a struct strbuf. This makes the
code clearer and reduces copying a little bit.
A side effect of this change is that the memory for each message is
freed after it is used rather than leaked, though that detail is
unimportant given that imap-send is a top-level command.
--
For some reason, there is a bunch of infrastructure in this file for
dealing with IMAP flags, although there is nothing in the code that
actually allows any flags to be set. If there is no plan to add
support for flags in the future, a bunch of code could be ripped out
and struct msg_data could be completely replaced with strbuf.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
imap-send.c | 92 +++--
1 file changed, 47 insertions(+), 45 deletions(-)
diff --git a/imap-send.c b/imap-send.c
index 86cf603..a5e0e33 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -69,12 +69,7 @@ struct store {
};
struct msg_data {
- /* NUL-terminated data: */
- char *data;
-
- /* length of data (not including NUL): */
- int len;
-
+ struct strbuf data;
unsigned char flags;
};
@@ -1268,46 +1263,49 @@ static int imap_make_flags(int flags, char *buf)
return d;
}
-static void lf_to_crlf(struct msg_data *msg)
+static void lf_to_crlf(struct strbuf *msg)
{
+ size_t new_len;
char *new;
int i, j, lfnum = 0;
- if (msg-data[0] == '\n')
+ if (msg-buf[0] == '\n')
lfnum++;
for (i = 1; i msg-len; i++) {
- if (msg-data[i - 1] != '\r' msg-data[i] == '\n')
+ if (msg-buf[i - 1] != '\r' msg-buf[i] == '\n')
lfnum++;
}
- new = xmalloc(msg-len + lfnum + 1);
- if (msg-data[0] == '\n') {
+ new_len = msg-len + lfnum;
+ new = xmalloc(new_len + 1);
+ if (msg-buf[0] == '\n') {
new[0] = '\r';
new[1] = '\n';
i = 1;
j = 2;
} else {
- new[0] = msg-data[0];
+ new[0] = msg-buf[0];
i = 1;
j = 1;
}
for ( ; i msg-len; i++) {
- if (msg-data[i] != '\n') {
- new[j++] = msg-data[i];
+ if (msg-buf[i] != '\n') {
+ new[j++] = msg-buf[i];
continue;
}
- if (msg-data[i - 1] != '\r')
+ if (msg-buf[i - 1] != '\r')
new[j++] = '\r';
/* otherwise it already had CR before */
new[j++] = '\n';
}
- new[j] = '\0';
- msg-len += lfnum;
- free(msg-data);
- msg-data = new;
+ strbuf_attach(msg, new, new_len, new_len + 1);
}
-static int imap_store_msg(struct store *gctx, struct msg_data *data)
+/*
+ * Store msg to IMAP. Also detach and free the data from msg-data,
+ * leaving msg-data empty.
+ */
+static int imap_store_msg(struct store *gctx, struct msg_data *msg)
{
struct imap_store *ctx = (struct imap_store *)gctx;
struct imap *imap = ctx-imap;
@@ -1316,16 +1314,15 @@ static int imap_store_msg(struct store *gctx, struct
msg_data *data)
int ret, d;
char flagstr[128];
- lf_to_crlf(data);
+ lf_to_crlf(msg-data);
memset(cb, 0, sizeof(cb));
- cb.dlen = data-len;
- cb.data = xmalloc(cb.dlen);
- memcpy(cb.data, data-data, data-len);
+ cb.dlen = msg-data.len;
+ cb.data = strbuf_detach(msg-data, NULL);
d = 0;
- if (data-flags) {
- d = imap_make_flags(data-flags, flagstr);
+ if (msg-flags) {
+ d = imap_make_flags(msg-flags, flagstr);
flagstr[d++] = ' ';
}
flagstr[d] = 0;
@@ -1356,7 +1353,8 @@ static void encode_html_chars(struct strbuf *p)
strbuf_splice(p, i, 1, quot;, 6);
}
}
-static void wrap_in_html(struct msg_data *msg)
+
+static void wrap_in_html(struct strbuf *msg)
{
struct strbuf buf = STRBUF_INIT;
struct strbuf **lines;
@@ -1366,9 +1364,7 @@ static void wrap_in_html(struct msg_data *msg)
static char *pre_close = /pre\n;
int added_header = 0;
- strbuf_attach(buf, msg-data, msg-len, msg-len);
- lines = strbuf_split(buf, '\n');
- strbuf_release(buf);
+ lines = strbuf_split(msg, '\n');
for (p = lines; *p; p++) {
if (! added_header) {
if ((*p)-len == 1 *((*p)-buf) == '\n') {
@@ -1385,8 +1381,8 @@ static void wrap_in_html(struct msg_data *msg)
}
strbuf_addstr(buf, pre_close);
strbuf_list_free(lines);
- msg-len = buf.len;
- msg-data = strbuf_detach(buf, NULL);
+
[PATCH 7/8] wrap_in_html(): use strbuf_addstr_xml_quoted()
Use the new function to quote characters as they are being added to
buf, rather than quoting them in *p and then copying them into buf.
This increases code sharing, and changes the algorithm from O(N^2) to
O(N) in the number of characters in a line.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
imap-send.c | 23 ---
1 file changed, 4 insertions(+), 19 deletions(-)
diff --git a/imap-send.c b/imap-send.c
index a5e0e33..b73c913 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -1339,21 +1339,6 @@ static int imap_store_msg(struct store *gctx, struct
msg_data *msg)
return DRV_OK;
}
-static void encode_html_chars(struct strbuf *p)
-{
- int i;
- for (i = 0; i p-len; i++) {
- if (p-buf[i] == '')
- strbuf_splice(p, i, 1, amp;, 5);
- if (p-buf[i] == '')
- strbuf_splice(p, i, 1, lt;, 4);
- if (p-buf[i] == '')
- strbuf_splice(p, i, 1, gt;, 4);
- if (p-buf[i] == '')
- strbuf_splice(p, i, 1, quot;, 6);
- }
-}
-
static void wrap_in_html(struct strbuf *msg)
{
struct strbuf buf = STRBUF_INIT;
@@ -1372,12 +1357,12 @@ static void wrap_in_html(struct strbuf *msg)
strbuf_addbuf(buf, *p);
strbuf_addstr(buf, pre_open);
added_header = 1;
- continue;
+ } else {
+ strbuf_addbuf(buf, *p);
}
+ } else {
+ strbuf_addstr_xml_quoted(buf, (*p)-buf);
}
- else
- encode_html_chars(*p);
- strbuf_addbuf(buf, *p);
}
strbuf_addstr(buf, pre_close);
strbuf_list_free(lines);
--
1.8.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: Python extension commands in git - request for policy change
On Sun, Nov 25, 2012 at 5:44 PM, Michael Haggerty mhag...@alum.mit.edu wrote: On the contrary, there is *constant* traffic on the mailing list about incompatibilities between different shell implementations (sh, dash, bash, etc), not to mention those in other utilities (sed, grep, etc) that one is forced to work with in shell scripts. Compatibility is a *huge* pain when developing shell code for git. The fact that users typically don't encounter such problems is due to the hard work of POSIX lawyers on the mailing list correcting the compatibility errors of mortal programmers. I think we still are in the process of moving away from shell-based commands (not the shell interface), just not enough man power to do it fast. The only shell-based command with active development is git-submodule. So most shell PITA is in the test suite. The most important issues to consider when imagining a future with a hybrid of code in C and some scripting language X are: * Portability: is X available on all platforms targeted by git, in usable and mutually-compatible versions? * Startup time: Is the time to start the X interpreter prohibitive? (On my computer, python -c pass, which starts the Python interpreter and does nothing, takes about 24ms.) This overhead would be incurred by every command that is not pure C. * Should the scripting language access the C functionality only by calling pure-C executables or by dynamically or statically linking to a binary module interface? If the former, then the granularity of interactions between X and C is necessarily coarse, and X cannot be used to implement anything but the outermost layer of functionality. If the latter, then the way would be clear to implement much more of git in X (and lua would also be worth considering). * Learning curve for developers: how difficult is it for a typical git developer to become conversant with X, considering both (1) how likely is it that the typical git developer already knows X and (2) how straightforward and predictable is the language X? In this category I think that Python has a huge advantage over Perl, though certainly opinions will differ and Ruby would also be a contender. * We might also need an embedded language variant, like Jeff's lua experiment. I'd be nice if X can also take this role. -- 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: Python extension commands in git - request for policy change
On Sun, Nov 25, 2012 at 10:54 AM, Eric S. Raymond e...@thyrsus.com wrote: Felipe Contreras felipe.contre...@gmail.com: On Sun, Nov 25, 2012 at 6:18 AM, Eric S. Raymond e...@thyrsus.com wrote: Nguyen Thai Ngoc Duy pclo...@gmail.com: These may apply to other languages as well. Where do we draw a line? I'm in favor of the general policy of avoiding scripting languages other than the top three most widely deployed. At the moment that means shell, Python, Perl; on present trends, in a few years Perl (dropping in popularity) might be passed by Ruby on the way up. Top three according to whom? According to the LOC counts in git's codebase. Not according to ohloh: 1) shell 33% 2) tcl 9% 3) perl 9.7% 4) python 1.8% And this is a non-sequitur; you are proposing to change git policies based on numbers that are a direct result of git's policies? https://www.ohloh.net/p/git/analyses/latest/languages_summary -- 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: Python extension commands in git - request for policy change
On Sun, 25 Nov 2012, Eric S. Raymond wrote: Michael Haggerty mhag...@alum.mit.edu: There is, of course, the awkward issue of how/when to transition to Python 3.x, which is *not* backwards compatible with Python 2.x. I expect that when the time comes there will be volunteers (myself included) willing to help adapt Python scripts to the new version, but the problem shouldn't be minimized. 2to3 actually does a pretty good job. It doesn't reduce the transition cost to zero, but I find it does reduce that cost to an easily manageable level even on quite large codebases. It would be insane to rewrite performance-critical C code in any scripting language, but there is a huge penumbra of code that is not performance critical and that mutates rapidly. Indeed. In the git architecture there is a pretty clear dividing line - to a first approximation, plumbing should remain C but porcelain should probably not. (Not that I am advocating forcing such a move - but it would be good to allow it to happen.) The 80-20 rule (80% of the execution time is spent in 20% of the code) helps us here. The *other* 80% of the code can move to a scripting language with no significant performance loss. To find out what needs to stay in C, run a profiler! Remember that old code is tested code. The mere act of re-writing it from scratch is likely to introduce new bugs due to 'simplifications' by the person re-writing the code. If a particular piece of code has a track record of being buggy, this may be overwelmed by the fresh start and new attention (plus whatever theoretical advantage any particular language provides), but unless it's suspect, re-writing it for the sole reason of changing the language is unlikely to be a win. In addition, a good programmer working in a 'bad' language that they are very familiar with is going to write better code than that same programmer would write in a 'good' language that they are not familiar with. I git, the programmers are very familiar with C and Bash, but far less familiar with either Perl or Python (although from what I see, far more familiar with Perl than Python) If it's something going into contrib, where the core developers are not needing to maintain it, the language it's written in matters far less than if it's something that's going to be in the core. If it's in the core, it needs to be in a language that the core developers are comforatable with. You may think that C and Bash are poor choices, but that is what the community is familar with. You are far from the first person to say that git should be re-written (or at least large portions of it) in the language-of-the-day, and you won't be the last (even, or especially if it does get re-written in Python ;-) David Lang -- 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: Python extension commands in git - request for policy change
Hi David. One minor but important correction ... On 11/25/2012 12:51 PM, David Lang wrote: You may think that C and Bash are poor choices, but that is what the community is familar with. Actually, it is C and POSIX shell -- not merely bash. Indeed, the shell code in Git is expected to work with the Solaris Korn shell, the BSD /bin/sh, the dash shell (which is now the default /bin/sh on Debian and Ubuntu), etc. (Oh, and on the python vs. C vs. shell diatribe I'm mostly neutral, mostly because I'm no Git developer, and I have no cents to throw). Regards, Stefano -- 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] Fix typo in remote set-head usage
parenthesis are not matching in `builtin_remote_sethead_usage`
as a square bracket is closing something never opened.
---
This will also break all translation files, should I also send a patch
to update them ?
Cheers,
Antoine Pelisse
builtin/remote.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/remote.c b/builtin/remote.c
index a5a4b23..937484d 100644
--- a/builtin/remote.c
+++ b/builtin/remote.c
@@ -39,7 +39,7 @@ static const char * const builtin_remote_rm_usage[] = {
};
static const char * const builtin_remote_sethead_usage[] = {
- N_(git remote set-head name (-a | -d | branch])),
+ N_(git remote set-head name (-a | -d | branch)),
NULL
};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gitk tag delete/rename support
Hi, On Sun, Nov 25, 2012 at 7:26 AM, Junio C Hamano gits...@pobox.com wrote: Thanks, but I prefer not to take patches to gitk-git/ directly; could you prepare a patch against Paul's tree at git://ozlabs.org/~paulus/gitk and send it in that direction (paulus@) instead? No problem. Will do that. -- Best Regards, Leon -- 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
Multiple threads of compression
Hi,
I’m asking here informally first, because my information relates
to a quite old version (the one from lenny-backports). A tl;dr
is at the end.
On a multi-core machine, the garbage collection of git, as well
as pack compression on the server side when someone clones a
repository remotely, the compression is normally done automatically
using multiple threads of execution.
That may be fine for your typical setups, but in my cases, I have
two scenarios where it isn’t:
ⓐ The machine where I want it to use only, say, 2 of my 4 or 8 cores
as I’m also running some VMs on the box which eat up a lot of CPU
and which I don’t want to slow down.
ⓑ The server VM which has been given 2 or 3 VCPUs to cope with all
the load done by clients, but which is RAM-constrained to only
512 or, when lucky, 768 MiB. It previously served only http/https
and *yuk* Subversion, but now, git comes into the play, and I’ve
seen the one server box I think about go down *HARD* because git
ate up all RAM *and* swap when someone wanted to update their clone
of a repository after someone else committed… well, an ~100 MiB large
binary file they shouldn’t. (It required manual intervention on the
server to kill that revision and then the objects coupled with it,
but even *that* didn’t work, read on for more.)
In both cases, I had to apply a quick hack. One I can reproduce
by now is, that, on the first box, I added a --threads=2 to the
line calling git pack-objects in /usr/lib/git-core/git-repack,
like this:
83 args=$args $local ${GIT_QUIET:+-q} $no_reuse$extra
84 names=$(git pack-objects --threads=2 --keep-true-parents --honor-pack-
keep --non-empty --all --reflog $arg
85 exit 1
(By the way, wrapping source code at 80c is still way to go IMHO.)
On the second box, IIRC I added --threads=1, but that box got
subsequently upgraded from lenny to wheezy so any local modification
is lost (luckily, the problem didn’t occur again recently, or at
least I didn’t notice it, save for the VM load going up to 6-8
several times a day).
tl;dr: I would like to have a *global* option for git to restrict
the number of threads of execution it uses. Several subcommands,
like pack-objects, are already equipped with an optioin for this,
but unfortunately, these are seldom invoked by hand¹, so this can’t
work in my situations.
① automatic garbage collection, “git gc --aggressive --prune=now”,
and cloning are the use cases I have at hand right now.
À propos, while here: is gc --aggressive safe to run on a live,
online-shared repository, or does it break other users accessing
the repository concurrently? (If it’s safe I’d very much like to do
that in a, say weekly, cronjob on FusionForge, our hosting system.)
Thanks in advance!
//mirabilos
--
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: Python extension commands in git - request for policy change
Felipe Contreras felipe.contre...@gmail.com: Of course, but there are experts in C and shell around, not so many python experts. So if somebody sneaks in a python program that makes use of features specific to python 2.7, I doubt anybody would notice. I would. And if they did, I doubt that would be reason enough for rejection, supposing that porting to 2.6 would be difficult enough. In cases like that, backporting is usually pretty easy. Been there, done that. -- a href=http://www.catb.org/~esr/;Eric S. Raymond/a -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Python extension commands in git - request for policy change
David Lang da...@lang.hm: You may think that C and Bash are poor choices, but that is what the community is familar with. I don't think C is a poor choice. bash, on the other hand...so many dependencies on tool quirks! You are far from the first person to say that git should be re-written (or at least large portions of it) in the language-of-the-day, and you won't be the last (even, or especially if it does get re-written in Python ;-) I think you're overinterpreting. Trying for One Big Rewrite in language X is almost never a good idea and I don't advocate it. Encouraging people to migrate pieces as they feel motivated and resdy is a different matter. -- a href=http://www.catb.org/~esr/;Eric S. Raymond/a -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Python extension commands in git - request for policy change
Felipe Contreras felipe.contre...@gmail.com: Not according to ohloh: 1) shell 33% 2) tcl 9% 3) perl 9.7% 4) python 1.8% Look in the Makefile - all that tcl code is buried in gitk. We're very, very lucky the author did such a good job, because it's a potentially serious headache; who can maintain it? -- a href=http://www.catb.org/~esr/;Eric S. Raymond/a -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] gitk tag delete/rename support
Right clicking on a tag pops up a menu, which allows
tag to be renamed or deleted.
Signed-off-by: Leon KUKOVEC leon.kuko...@gmail.com
---
gitk-git/gitk | 154 +
1 file changed, 154 insertions(+)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index d93bd99..38cc233 100755
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -2032,6 +2032,7 @@ proc makewindow {} {
global have_tk85 use_ttk NS
global git_version
global worddiff
+global tagctxmenu
# The mc arguments here are purely so that xgettext
# sees the following string as needing to be translated
@@ -2581,6 +2582,13 @@ proc makewindow {} {
{mc Run git gui blame on this line command {external_blame_diff}}
}
$diff_menu configure -tearoff 0
+
+set tagctxmenu .tagctxmenu
+makemenu $tagctxmenu {
+ {mc Rename this tag command mvtag}
+ {mc Delete this tag command rmtag}
+}
+$tagctxmenu configure -tearoff 0
}
# Windows sends all mouse wheel events to the current focused window, not
@@ -6400,6 +6408,7 @@ proc drawtags {id x xt y1} {
-font $font -tags [list tag.$id text]]
if {$ntags = 0} {
$canv bind $t 1 [list showtag $tag_quoted 1]
+ $canv bind $t $ctxbut [list showtagmenu %X %Y $id $tag_quoted]
} elseif {$nheads = 0} {
$canv bind $t $ctxbut [list headmenu %X %Y $id $tag_quoted]
}
@@ -8931,6 +8940,113 @@ proc domktag {} {
return 1
}
+proc mvtag {} {
+global mvtagtop
+global tagmenuid tagmenutag tagctxmenu maintag NS
+global mvtagtag
+
+set mvtagtag $tagmenutag
+set top .movetag
+set mvtagtop $top
+catch {destroy $top}
+ttk_toplevel $top
+make_transient $top .
+
+${NS}::label $top.msg -text [mc Enter a new tag name:]
+${NS}::entry $top.tag -width 60 -textvariable mvtagtag
+
+grid $top.msg -sticky w -row 0 -column 0
+grid $top.tag -sticky w -row 0 -column 1
+
+${NS}::frame $top.buts
+${NS}::button $top.buts.gen -text [mc Rename] -command mvtaggo
+${NS}::button $top.buts.can -text [mc Cancel] -command mvtagcan
+bind $top Key-Return mvtaggo
+bind $top Key-Escape mvtagcan
+grid $top.buts.gen $top.buts.can
+grid columnconfigure $top.buts 0 -weight 1 -uniform a
+grid columnconfigure $top.buts 1 -weight 1 -uniform a
+grid $top.buts - -pady 10 -sticky ew
+}
+
+proc domvtag {} {
+global mvtagtop env tagids idtags tagmenutag tagmenuid mvtagtag
+
+set tag $mvtagtag
+set id $tagmenuid
+
+# add tag
+# XXX: reuse domktag including keeping comment from the original tag.
+if {[catch {
+exec git tag $tag $id
+} err]} {
+error_popup [mc Error renaming tag:] $err $mvtagtop
+return 0
+}
+
+# delete old tag, content stored in $tagmenutag and $tagmenuid
+dormtag
+
+set tagids($tag) $id
+lappend idtags($id) $tag
+redrawtags $id
+addedtag $id
+dispneartags 0
+run refill_reflist
+return 1
+}
+
+proc rmtag {} {
+global rmtagtop
+global tagmenuid tagmenutag tagctxmenu maintag NS
+
+set top .maketag
+set rmtagtop $top
+catch {destroy $top}
+ttk_toplevel $top
+make_transient $top .
+${NS}::label $top.title -text [mc Delete tag]
+grid $top.title - -pady 10
+
+${NS}::label $top.msg -text [mc You are about to delete a tag]
+${NS}::label $top.tagname -foreground Red -text [mc $tagmenutag]
+grid $top.msg -sticky w -row 0 -column 0
+grid $top.tagname -sticky w -row 0 -column 1
+
+${NS}::frame $top.buts
+${NS}::button $top.buts.gen -text [mc Delete] -command rmtaggo
+${NS}::button $top.buts.can -text [mc Cancel] -command rmtagcan
+bind $top Key-Return rmtaggo
+bind $top Key-Escape rmtagcan
+grid $top.buts.gen $top.buts.can
+grid columnconfigure $top.buts 0 -weight 1 -uniform a
+grid columnconfigure $top.buts 1 -weight 1 -uniform a
+grid $top.buts - -pady 10 -sticky ew
+}
+
+proc dormtag {} {
+global rmtagtop env tagids idtags tagmenutag tagmenuid
+
+set tag $tagmenutag
+set id $tagmenuid
+
+if {[catch {
+exec git tag -d $tag
+} err]} {
+error_popup [mc Error deleting tag:] $err $rmtagtop
+return 0
+}
+
+unset tagids($tag)
+set idx [lsearch $idtags($id) $tag]
+set idtags($id) [lreplace $idtags($id) $idx $idx]
+
+redrawtags $id
+dispneartags 0
+run refill_reflist
+return 1
+}
+
proc redrawtags {id} {
global canv linehtag idpos currentid curview cmitlisted markedid
global canvxmax iddrawn circleitem mainheadid circlecolors
@@ -8974,6 +9090,30 @@ proc mktaggo {} {
mktagcan
}
+proc rmtagcan {} {
+global rmtagtop
+
+catch {destroy $rmtagtop}
+unset rmtagtop
+}
+
+proc rmtaggo {} {
+if {![dormtag]} return
+rmtagcan
+}
+
+proc mvtagcan {} {
+global mvtagtop
+
+catch {destroy $mvtagtop}
+unset mvtagtop
+}
+
Re: Python extension commands in git - request for policy change
On Sun, Nov 25, 2012 at 6:50 PM, Eric S. Raymond e...@thyrsus.com wrote: Felipe Contreras felipe.contre...@gmail.com: Not according to ohloh: 1) shell 33% 2) tcl 9% 3) perl 9.7% 4) python 1.8% Look in the Makefile - all that tcl code is buried in gitk. We're very, very lucky the author did such a good job, because it's a potentially serious headache; who can maintain it? And gitk is an integral part of git. But if you have different numbers, what are they? -- 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: Python extension commands in git - request for policy change
On Sun, Nov 25, 2012 at 6:36 PM, Eric S. Raymond e...@thyrsus.com wrote: Felipe Contreras felipe.contre...@gmail.com: Of course, but there are experts in C and shell around, not so many python experts. So if somebody sneaks in a python program that makes use of features specific to python 2.7, I doubt anybody would notice. I would. And are you going to be around to spot them? It seems my patches for git-remote-hg slipped by your watch, because it seems they use stuff specific to python 2.7. And if they did, I doubt that would be reason enough for rejection, supposing that porting to 2.6 would be difficult enough. In cases like that, backporting is usually pretty easy. Been there, done that. Exactly. Why would you reject something you can fix easily? -- 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] Document the integration requirements for extension commands.
This contains no policy changes or proposals, it simply attempts to document the interfaces and conventions already in place. --- Documentation/technical/api-command.txt | 81 +++ 1 file changed, 81 insertions(+) create mode 100644 Documentation/technical/api-command.txt diff --git a/Documentation/technical/api-command.txt b/Documentation/technical/api-command.txt new file mode 100644 index 000..de76614 --- /dev/null +++ b/Documentation/technical/api-command.txt @@ -0,0 +1,81 @@ += Integrating new subcommands = + +This is how-to documentation for people who want to add extension +commands to git. It should be read alongside api-builtin.txt. + +== Runtime environment == + +git subcommands are standalone executables that live in the git +execution directory, normally /usr/lib/git-core. The git executable itself +is a thin wrapper that sets GIT_DIR and passes command-line arguments +to the subcommand. + +(If git foo is not found in the git execution directory, the wrapper +will look in the rest of your $PATH for it. Thus, it's possible +to write local git extensions that don't live in system space.) + +== Implementation languages == + +Most subcommands are written in C or shell. A few are written in +Perl. A tiny minority are written in Python. + +While we strongly encourage coding in portable C for portability, these +specific scripting languages are also acceptable. We won't accept more +without a very strong technical case, as we don't want to broaden the +git suite's required dependencies. + +C commands are normally written as single modules, named after the +command, that link a core library called libgit. Thus, your command +'git-foo' would normally be implemented as a single git-foo.c; this +organization makes it easy for people reading the code to find things. + +See the CodingGuidelines document for other guidance on what we consider +good practice in C and shell, and api-builtin.txt for the support +functions available to built-in commands written in C. + +== What every extension command needs == + +You must have a man page, written in asciidoc (this is what git help +followed by your subcommand name will display). Be aware that there is +a local asciidoc configuration and macros which you should use. It's +often helpful to start by cloning an existing page and replacing the +text content. + +You must have a test, written to report in TAP (Test Anything Protocol). +Tests are executables (usually shell scripts) that live in the 't' +subdirectory of the tree. Each test name begins with 't' and a sequence +number that controls where in the test sequence it will be executed; +conventionally the rest of the name stem is that of the command +being tested. + +Read the file t/README to learn more about the conventions to be used +in writing tests, and the test support library. + +== Integrating a command == + +Here are the things you need to do when you want to merge a new +subcommand into the git tree. + +1. Append your command name to one of the variables BUILTIN_OBJS, +EXTRA_PROGRAMS, SCRIPT_SH, SCRIPT_PERL or SCRIPT_PYTHON. + +2. Drop its test in the t directory. + +3. If your command is implemented in an interpreted language with a +p-code intermediate form, make sure .gitignore in the main directory +includes a pattern entry that ignores such files. Python .pyc and +.pyo files will already be covered. + +4. If your command has any dependency on a a particular version of +your language, document it in the INSTALL file. + +5. There is a file command-list.txt in the distribution main directory +that categorizes commands by type, so they can be listed in appropriate +subsections in the documentation's summary command list. Add an entry +for yours. To understand the categories, look at git-cmmands.txt +in the main directory. + +6. When your patch is merged, remind the maintainer to add something +about it in the RelNotes file. + +That's all there is to it. -- 1.7.9.5 -- a href=http://www.catb.org/~esr/;Eric S. Raymond/a Rightful liberty is unobstructed action, according to our will, within limits drawn around us by the equal rights of others. -- Thomas Jefferson -- 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: Python extension commands in git - request for policy change
On Sat, Nov 24, 2012 at 09:44:51PM -0500, Eric S. Raymond wrote: We're behind the best-practices curve here. The major Linux distributions, which have to deal with almost the same set of tradeoffs we do, went to Python for pretty much all glue and administration scripts outside /etc a decade ago, and the decision has served them well. That, among other things, means up-to-date versions of Python are ubiquitous unless we're looking at Windows - in which case Perl and shell actually become much bigger portability problems. Mac OS X has kept up to date, too; Lion shipped 2.7.1 and that was a major release back at this point. What about embedded systems? git is also useful there. C and shell is everywhere, python is not. Adding additional dependency if it's not really needed it's not a good idea. Also not everyone uses up-to-date systems and sometimes you just care about some critical parts and do not touch everything else and there is probably quote large number of systems with python 2.6. And even when you keep your system up-to-date, there are some GNU/Linux distros that are still supported, but does not provide recent python - for instance PLD Ac, which I still use on some systems and will use until the hardware dies, provides only python 2.4.6 (by the way, important packages like git are of course quite recent there - 1.7.11.1). Krzysiek -- 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: Python extension commands in git - request for policy change
On Sun, Nov 25, 2012 at 6:32 PM, Eric S. Raymond e...@thyrsus.com wrote: Felipe Contreras felipe.contre...@gmail.com: Seems sensible, but I don't know what rejection would actually mean. Why is this mysterious? We reject a patch when we don't choose to merge it. Why would you reject it? If, according to you, it's very simple to fix the portability, then presumably it would take you less time to fix it, than to reject it (and everything that implies). Too late. I'd be happy to help you out by auditing them for version dependencies. Be my guest: http://git.kernel.org/?p=git/git.git;a=tree;f=contrib/remote-helpers;h=adfdcc164e634c74024c8f69bb0cdb9f3b4a9f18;hb=7b4a70c62f3a83fbd8b44bf712141754a5f64205 Some patches might be missing, so: https://github.com/felipec/git/tree/fc/remote/hg I don't see what this means in practical terms. People are going to write code in whatever language they want to write code in. How exactly are we going to encourage them not to do that is not entirely clear to me. One way is by having clear guidelines for good practice that *include* Python, and tell people exactly what the requirements are. The key word being guideline, which is different from a strict rule. Subcommands are also probably more efficient in c. And lets remember that most people use git through the *official* subcommands. See my remarks on the 80-20 rule elsewhere in the thread. Execessive worship of efficiency is a great way to waste effort and pile up hidden costs in maintainance problems. According to the results of the last survey, our users do care about performance, so I don't think there's anything excessive about it. Are there any hidden costs in maintenance problems? I don't think so. The people that like to improve the performance of git, would keep doing so, and the people that want to use fancy scripts to do fancy stuff, will keep doing so. It just happens that the former have actually managed to do it, and go all the way into the mainline. It would be great if we had a finished libgit2 with all the essential stuff, and good bindings for python (and other languages), and it would be great if python really was this touted language, that is easy to read, and would make things more maintainable. Unfortunately, that's not the case. I could write an endless list of what things in the python language don't make any sense, and how in ruby, for example, they do. Fortunately, I don't have to. Git does have problems, but they have nothing to do with maintenance, or C; they have to do with the user interface, and the documentation (again, according to our users (and me)). So, I don't see why worry about moving code from C to python when barely any code in git is python, specially if it doesn't fix any real issue. 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: Python extension commands in git - request for policy change
Felipe Contreras felipe.contre...@gmail.com: And are you going to be around to spot them? It seems my patches for git-remote-hg slipped by your watch, because it seems they use stuff specific to python 2.7. The dev group hasn't decided (in whatever way it decides these things) to require 2.6 yet. When and if it does, I will volunteer my services as a Python expert to audit the in-tree Python code for 2.6 conformance and assist the developers in backporting if required. I will also make myself available to audit future submissions. I think you know who I am. Junio and the other senior devs certainly know where to find me. I've been making promises like this, and *keeping* them, for decades. Please stop wasting our time with petulant display. Exactly. Why would you reject something you can fix easily? I wouldn't. The point of a policy like this is not to kick incoming submissions over the horizon as though that were some sort of accomplishment, it's to let submitters know what is required of them so they can code up to a standard that supports maintainability. It would be no different than any of our other portability requirements. -- a href=http://www.catb.org/~esr/;Eric S. Raymond/a -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Python extension commands in git - request for policy change
Krzysztof Mazur krzys...@podlesie.net: What about embedded systems? git is also useful there. C and shell is everywhere, python is not. Supposing this is true (and I question it with regard to shell) if you tell me how you live without gitk and the Perl pieces I'll play that right back at you as your answer. -- a href=http://www.catb.org/~esr/;Eric S. Raymond/a -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/11] sequencer.c: remove broken support for rfc2822 continuation in footer
Commit c1e01b0c generalized the detection of the last paragraph
signed-off-by footer and used rfc2822 as a guideline. Support for rfc2822
style continuation lines was also implemented, but not correctly, so it has
never detected a line beginning with space or tab as a continuation of the
previous line.
Since a commit message is not governed by the line length limits imposed
by rfc2822 for email messages, and it does not seem like this functionality
would produce better commit messages anyway, let's remove this broken
functionality.
Signed-off-by: Brandon Casey bca...@nvidia.com
---
sequencer.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/sequencer.c b/sequencer.c
index 2260490..656df6b 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -1023,7 +1023,6 @@ static int ends_rfc2822_footer(struct strbuf *sb, int
ignore_footer)
int hit = 0;
int i, j, k;
int len = sb-len - ignore_footer;
- int first = 1;
const char *buf = sb-buf;
for (i = len - 1; i 0; i--) {
@@ -1040,11 +1039,6 @@ static int ends_rfc2822_footer(struct strbuf *sb, int
ignore_footer)
; /* do nothing */
k++;
- if ((buf[k] == ' ' || buf[k] == '\t') !first)
- continue;
-
- first = 0;
-
for (j = 0; i + j len; j++) {
ch = buf[i + j];
if (ch == ':')
--
1.8.0.284.g959048a
--
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 02/11] t/test-lib-functions.sh: allow to specify the tag name to test_commit
The message part of test_commit() may not be appropriate for a tag name.
So let's allow test_commit to accept a fourth argument to specify the tag
name.
Signed-off-by: Brandon Casey bca...@nvidia.com
---
t/test-lib-functions.sh | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh
index 8889ba5..9e2b8b8 100644
--- a/t/test-lib-functions.sh
+++ b/t/test-lib-functions.sh
@@ -135,12 +135,13 @@ test_pause () {
fi
}
-# Call test_commit with the arguments message [file [contents]]
+# Call test_commit with the arguments message [file [contents [tag]]]
#
# This will commit a file with the given contents and the given commit
-# message. It will also add a tag with message as name.
+# message. It will also add a tag with message as name unless tag is
+# given.
#
-# Both file and contents default to message.
+# file, contents, and tag all default to message.
test_commit () {
notick=
@@ -168,7 +169,7 @@ test_commit () {
test_tick
fi
git commit $signoff -m $1
- git tag $1
+ git tag ${4:-$1}
}
# Call test_merge with the arguments message commit, where commit
--
1.8.0.284.g959048a
--
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 03/11] t/t3511: add some tests of 'cherry-pick -s' functionality
Add some tests to ensure that 'cherry-pick -s' operates in the following
manner:
* Inserts a blank line before appending a s-o-b to a commit message that
does not contain a s-o-b footer
* Does not mistake first line subject: description as a s-o-b footer
* Does not mistake single word message body as conforming to rfc2822
* Appends a s-o-b when last s-o-b in footer does not match committer
s-o-b, even when committer's s-o-b exists elsewhere in footer.
* Does not append a s-o-b when last s-o-b matches committer s-o-b
* Correctly detects a non-conforming footer containing a mix of s-o-b
like elements and s-o-b elements. (marked expect failure)
Signed-off-by: Brandon Casey bca...@nvidia.com
---
t/t3511-cherry-pick-x.sh | 111 +++
1 file changed, 111 insertions(+)
create mode 100755 t/t3511-cherry-pick-x.sh
diff --git a/t/t3511-cherry-pick-x.sh b/t/t3511-cherry-pick-x.sh
new file mode 100755
index 000..a6c4168
--- /dev/null
+++ b/t/t3511-cherry-pick-x.sh
@@ -0,0 +1,111 @@
+#!/bin/sh
+
+test_description='Test cherry-pick -x and -s'
+
+. ./test-lib.sh
+
+pristine_detach () {
+ git cherry-pick --quit
+ git checkout -f $1^0
+ git read-tree -u --reset HEAD
+ git clean -d -f -f -q -x
+}
+
+mesg_one_line='base: commit message'
+
+mesg_no_footer=$mesg_one_line
+
+OneWordBodyThatsNotA-S-o-B
+
+mesg_with_footer=$mesg_no_footer
+
+Signed-off-by: $GIT_COMMITTER_NAME $GIT_COMMITTER_EMAIL
+Signed-off-by: A.U. Thor aut...@example.com
+Signed-off-by: B.U. Thor but...@example.com
+
+mesg_broken_footer=$mesg_no_footer
+
+Signed-off-by: B.U. Thor but...@example.com
+Not a valid footer element
+Signed-off-by: $GIT_COMMITTER_NAME $GIT_COMMITTER_EMAIL
+
+mesg_with_footer_sob=$mesg_with_footer
+Signed-off-by: $GIT_COMMITTER_NAME $GIT_COMMITTER_EMAIL
+
+
+test_expect_success setup '
+ git config advice.detachedhead false
+ echo unrelated unrelated
+ git add unrelated
+ test_commit initial foo a
+ test_commit $mesg_one_line foo b mesg-one-line
+ git reset --hard initial
+ test_commit $mesg_no_footer foo b mesg-no-footer
+ git reset --hard initial
+ test_commit $mesg_broken_footer foo b mesg-broken-footer
+ git reset --hard initial
+ test_commit $mesg_with_footer foo b mesg-with-footer
+ git reset --hard initial
+ test_commit $mesg_with_footer_sob foo b mesg-with-footer-sob
+ pristine_detach initial
+ test_commit conflicting unrelated
+'
+
+test_expect_success 'cherry-pick -s inserts blank line after one line subject'
'
+ pristine_detach initial
+ git cherry-pick -s mesg-one-line
+ cat -EOF expect
+ $mesg_one_line
+
+ Signed-off-by: $GIT_COMMITTER_NAME $GIT_COMMITTER_EMAIL
+ EOF
+ git log -1 --pretty=format:%B actual
+ test_cmp expect actual
+'
+
+test_expect_failure 'cherry-pick -s inserts blank line after non-conforming
footer' '
+ pristine_detach initial
+ git cherry-pick -s mesg-broken-footer
+ cat -EOF expect
+ $mesg_broken_footer
+
+ Signed-off-by: $GIT_COMMITTER_NAME $GIT_COMMITTER_EMAIL
+ EOF
+ git log -1 --pretty=format:%B actual
+ test_cmp expect actual
+'
+
+test_expect_success 'cherry-pick -s inserts blank line when conforming footer
not found' '
+ pristine_detach initial
+ git cherry-pick -s mesg-no-footer
+ cat -EOF expect
+ $mesg_no_footer
+
+ Signed-off-by: $GIT_COMMITTER_NAME $GIT_COMMITTER_EMAIL
+ EOF
+ git log -1 --pretty=format:%B actual
+ test_cmp expect actual
+'
+
+test_expect_success 'cherry-pick -s adds sob when last sob doesnt match
committer' '
+ pristine_detach initial
+ git cherry-pick -s mesg-with-footer
+ cat -EOF expect
+ $mesg_with_footer
+ Signed-off-by: $GIT_COMMITTER_NAME $GIT_COMMITTER_EMAIL
+ EOF
+ git log -1 --pretty=format:%B actual
+ test_cmp expect actual
+'
+
+test_expect_success 'cherry-pick -s refrains from adding duplicate trailing
sob' '
+ pristine_detach initial
+ git cherry-pick -s mesg-with-footer-sob
+ cat -EOF expect
+ $mesg_with_footer_sob
+ EOF
+ git log -1 --pretty=format:%B actual
+ test_cmp expect actual
+'
+
+test_done
--
1.8.0.284.g959048a
--
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 04/11] sequencer.c: recognize (cherry picked from ... as part of s-o-b footer
When 'cherry-pick -s' is used to append a signed-off-by line to a cherry
picked commit, it does not currently detect the (cherry picked from...
that may have been appended by a previous 'cherry-pick -x' as part of the
s-o-b footer and it will insert a blank line before appending a new s-o-b.
Let's detect (cherry picked from...) as part of the footer so that we
will produce this:
Signed-off-by: A U Thor aut...@example.com
(cherry picked from da39a3ee5e6b4b0d3255bfef95601890afd80709)
Signed-off-by: C O Mitter commit...@example.com
instead of this:
Signed-off-by: A U Thor aut...@example.com
(cherry picked from da39a3ee5e6b4b0d3255bfef95601890afd80709)
Signed-off-by: C O Mitter commit...@example.com
Signed-off-by: Brandon Casey bca...@nvidia.com
---
sequencer.c | 42
t/t3511-cherry-pick-x.sh | 55
2 files changed, 84 insertions(+), 13 deletions(-)
diff --git a/sequencer.c b/sequencer.c
index 656df6b..19eaf11 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -18,6 +18,7 @@
#define GIT_REFLOG_ACTION GIT_REFLOG_ACTION
const char sign_off_header[] = Signed-off-by: ;
+static const char cherry_picked_prefix[] = (cherry picked from commit ;
static void remove_sequencer_state(void)
{
@@ -492,7 +493,7 @@ static int do_pick_commit(struct commit *commit, struct
replay_opts *opts)
}
if (opts-record_origin) {
- strbuf_addstr(msgbuf, (cherry picked from commit );
+ strbuf_addstr(msgbuf, cherry_picked_prefix);
strbuf_addstr(msgbuf,
sha1_to_hex(commit-object.sha1));
strbuf_addstr(msgbuf, )\n);
}
@@ -1017,11 +1018,32 @@ int sequencer_pick_revisions(struct replay_opts *opts)
return pick_commits(todo_list, opts);
}
-static int ends_rfc2822_footer(struct strbuf *sb, int ignore_footer)
+static int is_rfc2822_line(const char *buf, int len)
+{
+ int i;
+
+ for (i = 0; i len; i++) {
+ int ch = buf[i];
+ if (ch == ':')
+ break;
+ if (isalnum(ch) || (ch == '-'))
+ continue;
+ return 0;
+ }
+
+ return 1;
+}
+
+static int is_cherry_pick_from_line(const char *buf, int len)
+{
+ return (strlen(cherry_picked_prefix) + 41) = len
+ !prefixcmp(buf, cherry_picked_prefix);
+}
+
+static int has_conforming_footer(struct strbuf *sb, int ignore_footer)
{
- int ch;
int hit = 0;
- int i, j, k;
+ int i, k;
int len = sb-len - ignore_footer;
const char *buf = sb-buf;
@@ -1039,15 +1061,9 @@ static int ends_rfc2822_footer(struct strbuf *sb, int
ignore_footer)
; /* do nothing */
k++;
- for (j = 0; i + j len; j++) {
- ch = buf[i + j];
- if (ch == ':')
- break;
- if (isalnum(ch) ||
- (ch == '-'))
- continue;
+ if (!(is_rfc2822_line(buf+i, k-i) ||
+ is_cherry_pick_from_line(buf+i, k-i)))
return 0;
- }
}
return 1;
}
@@ -1064,7 +1080,7 @@ void append_signoff(struct strbuf *msgbuf, int
ignore_footer)
for (i = msgbuf-len - 1 - ignore_footer; i 0 msgbuf-buf[i - 1]
!= '\n'; i--)
; /* do nothing */
if (prefixcmp(msgbuf-buf + i, sob.buf)) {
- if (!i || !ends_rfc2822_footer(msgbuf, ignore_footer))
+ if (!i || !has_conforming_footer(msgbuf, ignore_footer))
strbuf_splice(msgbuf, msgbuf-len - ignore_footer, 0,
\n, 1);
strbuf_splice(msgbuf, msgbuf-len - ignore_footer, 0, sob.buf,
sob.len);
}
diff --git a/t/t3511-cherry-pick-x.sh b/t/t3511-cherry-pick-x.sh
index a6c4168..32c0bb1 100755
--- a/t/t3511-cherry-pick-x.sh
+++ b/t/t3511-cherry-pick-x.sh
@@ -32,6 +32,10 @@ Signed-off-by: $GIT_COMMITTER_NAME $GIT_COMMITTER_EMAIL
mesg_with_footer_sob=$mesg_with_footer
Signed-off-by: $GIT_COMMITTER_NAME $GIT_COMMITTER_EMAIL
+mesg_with_cherry_footer=$mesg_with_footer_sob
+(cherry picked from commit da39a3ee5e6b4b0d3255bfef95601890afd80709)
+Tested-by: C.U. Thor cut...@example.com
+
test_expect_success setup '
git config advice.detachedhead false
@@ -47,6 +51,8 @@ test_expect_success setup '
test_commit $mesg_with_footer foo b mesg-with-footer
git reset --hard initial
test_commit $mesg_with_footer_sob foo b mesg-with-footer-sob
+ git reset --hard initial
+ test_commit $mesg_with_cherry_footer foo b mesg-with-cherry-footer
pristine_detach initial
test_commit conflicting unrelated
'
@@ -98,6 +104,19 @@ test_expect_success 'cherry-pick -s
[PATCH 05/11] sequencer.c: always separate (cherry picked from from commit body
Start treating the (cherry picked from line added by cherry-pick -x
the same way that the s-o-b lines are treated. Namely, separate them
from the main commit message body with an empty line.
Introduce tests to test this functionality.
Signed-off-by: Brandon Casey bca...@nvidia.com
---
sequencer.c | 106 +--
t/t3511-cherry-pick-x.sh | 53
2 files changed, 109 insertions(+), 50 deletions(-)
diff --git a/sequencer.c b/sequencer.c
index 19eaf11..7c0852a 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -20,6 +20,60 @@
const char sign_off_header[] = Signed-off-by: ;
static const char cherry_picked_prefix[] = (cherry picked from commit ;
+static int is_rfc2822_line(const char *buf, int len)
+{
+ int i;
+
+ for (i = 0; i len; i++) {
+ int ch = buf[i];
+ if (ch == ':')
+ break;
+ if (isalnum(ch) || (ch == '-'))
+ continue;
+ return 0;
+ }
+
+ return 1;
+}
+
+static int is_cherry_pick_from_line(const char *buf, int len)
+{
+ return (strlen(cherry_picked_prefix) + 41) = len
+ !prefixcmp(buf, cherry_picked_prefix);
+}
+
+static int has_conforming_footer(struct strbuf *sb, int ignore_footer)
+{
+ int hit = 0;
+ int i, k;
+ int len = sb-len - ignore_footer;
+ const char *buf = sb-buf;
+
+ for (i = len - 1; i 0; i--) {
+ if (hit buf[i] == '\n')
+ break;
+ hit = (buf[i] == '\n');
+ }
+
+ /* require at least one blank line */
+ if (!hit || buf[i] != '\n')
+ return 0;
+
+ while (i len - 1 buf[i] == '\n')
+ i++;
+
+ for (; i len; i = k) {
+ for (k = i; k len buf[k] != '\n'; k++)
+ ; /* do nothing */
+ k++;
+
+ if (!(is_rfc2822_line(buf+i, k-i) ||
+ is_cherry_pick_from_line(buf+i, k-i)))
+ return 0;
+ }
+ return 1;
+}
+
static void remove_sequencer_state(void)
{
struct strbuf seq_dir = STRBUF_INIT;
@@ -493,6 +547,8 @@ static int do_pick_commit(struct commit *commit, struct
replay_opts *opts)
}
if (opts-record_origin) {
+ if (!has_conforming_footer(msgbuf, 0))
+ strbuf_addch(msgbuf, '\n');
strbuf_addstr(msgbuf, cherry_picked_prefix);
strbuf_addstr(msgbuf,
sha1_to_hex(commit-object.sha1));
strbuf_addstr(msgbuf, )\n);
@@ -1018,56 +1074,6 @@ int sequencer_pick_revisions(struct replay_opts *opts)
return pick_commits(todo_list, opts);
}
-static int is_rfc2822_line(const char *buf, int len)
-{
- int i;
-
- for (i = 0; i len; i++) {
- int ch = buf[i];
- if (ch == ':')
- break;
- if (isalnum(ch) || (ch == '-'))
- continue;
- return 0;
- }
-
- return 1;
-}
-
-static int is_cherry_pick_from_line(const char *buf, int len)
-{
- return (strlen(cherry_picked_prefix) + 41) = len
- !prefixcmp(buf, cherry_picked_prefix);
-}
-
-static int has_conforming_footer(struct strbuf *sb, int ignore_footer)
-{
- int hit = 0;
- int i, k;
- int len = sb-len - ignore_footer;
- const char *buf = sb-buf;
-
- for (i = len - 1; i 0; i--) {
- if (hit buf[i] == '\n')
- break;
- hit = (buf[i] == '\n');
- }
-
- while (i len - 1 buf[i] == '\n')
- i++;
-
- for (; i len; i = k) {
- for (k = i; k len buf[k] != '\n'; k++)
- ; /* do nothing */
- k++;
-
- if (!(is_rfc2822_line(buf+i, k-i) ||
- is_cherry_pick_from_line(buf+i, k-i)))
- return 0;
- }
- return 1;
-}
-
void append_signoff(struct strbuf *msgbuf, int ignore_footer)
{
struct strbuf sob = STRBUF_INIT;
diff --git a/t/t3511-cherry-pick-x.sh b/t/t3511-cherry-pick-x.sh
index 32c0bb1..9dd6d5d 100755
--- a/t/t3511-cherry-pick-x.sh
+++ b/t/t3511-cherry-pick-x.sh
@@ -57,6 +57,19 @@ test_expect_success setup '
test_commit conflicting unrelated
'
+test_expect_success 'cherry-pick -x inserts blank line after one line subject'
'
+ pristine_detach initial
+ sha1=`git rev-parse mesg-one-line^0`
+ git cherry-pick -x mesg-one-line
+ cat -EOF expect
+ $mesg_one_line
+
+ (cherry picked from commit $sha1)
+ EOF
+ git log -1 --pretty=format:%B actual
+ test_cmp expect actual
+'
+
test_expect_success 'cherry-pick -s inserts blank line after one line subject'
'
pristine_detach initial
[PATCH 06/11] sequencer.c: teach append_signoff how to detect duplicate s-o-b
Teach append_signoff how to detect a duplicate s-o-b in the commit footer.
This is in preparation to unify the append_signoff implementations in
log-tree.c and sequencer.c.
Fixes test in t3511.
Signed-off-by: Brandon Casey bca...@nvidia.com
---
builtin/commit.c | 2 +-
sequencer.c | 43 +++
sequencer.h | 2 +-
t/t3511-cherry-pick-x.sh | 2 +-
4 files changed, 34 insertions(+), 15 deletions(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index 1dd2ec5..7b9e2ac 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -700,7 +700,7 @@ static int prepare_to_commit(const char *index_file, const
char *prefix,
previous = eol;
}
- append_signoff(sb, ignore_footer);
+ append_signoff(sb, ignore_footer, 0);
}
if (fwrite(sb.buf, 1, sb.len, s-fp) sb.len)
diff --git a/sequencer.c b/sequencer.c
index 7c0852a..3062ad4 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -42,12 +42,19 @@ static int is_cherry_pick_from_line(const char *buf, int
len)
!prefixcmp(buf, cherry_picked_prefix);
}
-static int has_conforming_footer(struct strbuf *sb, int ignore_footer)
+/* Returns 0 for non-conforming footer
+ * Returns 1 for conforming footer
+ * Returns 2 when sob exists within conforming footer
+ * Returns 3 when sob exists within conforming footer as last entry
+ */
+static int has_conforming_footer(struct strbuf *sb, struct strbuf *sob,
+ int ignore_footer)
{
int hit = 0;
- int i, k;
+ int i, k = 0;
int len = sb-len - ignore_footer;
const char *buf = sb-buf;
+ int found_sob = 0;
for (i = len - 1; i 0; i--) {
if (hit buf[i] == '\n')
@@ -63,14 +70,24 @@ static int has_conforming_footer(struct strbuf *sb, int
ignore_footer)
i++;
for (; i len; i = k) {
+ int found_rfc2822;
+
for (k = i; k len buf[k] != '\n'; k++)
; /* do nothing */
k++;
- if (!(is_rfc2822_line(buf+i, k-i) ||
- is_cherry_pick_from_line(buf+i, k-i)))
+ found_rfc2822 = is_rfc2822_line(buf+i, k-i);
+ if (found_rfc2822 sob
+ !strncasecmp(buf+i, sob-buf, sob-len))
+ found_sob = k;
+
+ if (!(found_rfc2822 || is_cherry_pick_from_line(buf+i, k-i)))
return 0;
}
+ if (found_sob == i)
+ return 3;
+ if (found_sob)
+ return 2;
return 1;
}
@@ -291,7 +308,7 @@ static int do_recursive_merge(struct commit *base, struct
commit *next,
rollback_lock_file(index_lock);
if (opts-signoff)
- append_signoff(msgbuf, 0);
+ append_signoff(msgbuf, 0, 0);
if (!clean) {
int i;
@@ -547,7 +564,7 @@ static int do_pick_commit(struct commit *commit, struct
replay_opts *opts)
}
if (opts-record_origin) {
- if (!has_conforming_footer(msgbuf, 0))
+ if (!has_conforming_footer(msgbuf, NULL, 0))
strbuf_addch(msgbuf, '\n');
strbuf_addstr(msgbuf, cherry_picked_prefix);
strbuf_addstr(msgbuf,
sha1_to_hex(commit-object.sha1));
@@ -1074,9 +1091,10 @@ int sequencer_pick_revisions(struct replay_opts *opts)
return pick_commits(todo_list, opts);
}
-void append_signoff(struct strbuf *msgbuf, int ignore_footer)
+void append_signoff(struct strbuf *msgbuf, int ignore_footer, int no_dup_sob)
{
struct strbuf sob = STRBUF_INIT;
+ int has_footer = 0;
int i;
strbuf_addstr(sob, sign_off_header);
@@ -1085,10 +1103,11 @@ void append_signoff(struct strbuf *msgbuf, int
ignore_footer)
strbuf_addch(sob, '\n');
for (i = msgbuf-len - 1 - ignore_footer; i 0 msgbuf-buf[i - 1]
!= '\n'; i--)
; /* do nothing */
- if (prefixcmp(msgbuf-buf + i, sob.buf)) {
- if (!i || !has_conforming_footer(msgbuf, ignore_footer))
- strbuf_splice(msgbuf, msgbuf-len - ignore_footer, 0,
\n, 1);
- strbuf_splice(msgbuf, msgbuf-len - ignore_footer, 0, sob.buf,
sob.len);
- }
+ if (!i || !(has_footer =
+ has_conforming_footer(msgbuf, sob, ignore_footer)))
+ strbuf_splice(msgbuf, msgbuf-len - ignore_footer, 0, \n, 1);
+ if (has_footer != 3 (!no_dup_sob || has_footer != 2))
+ strbuf_splice(msgbuf, msgbuf-len - ignore_footer, 0,
+ sob.buf, sob.len);
strbuf_release(sob);
}
diff --git a/sequencer.h b/sequencer.h
index 9d57d57..c4c7132 100644
--- a/sequencer.h
+++ b/sequencer.h
@@ -48,6 +48,6 @@ int sequencer_pick_revisions(struct replay_opts
[PATCH 07/11] sequencer.c: teach append_signoff to avoid adding a duplicate newline
Teach append_signoff to detect whether a blank line exists at the position that the signed-off-by line will be added, and avoid adding an additional one if one already exists. This is necessary to allow format-patch to add a s-o-b to a patch with no commit message without adding an extra newline. A following patch will make format-patch use this function rather than the append_signoff implementation inside log-tree.c. Signed-off-by: Brandon Casey bca...@nvidia.com --- sequencer.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sequencer.c b/sequencer.c index 3062ad4..eb93dd6 100644 --- a/sequencer.c +++ b/sequencer.c @@ -1103,8 +1103,8 @@ void append_signoff(struct strbuf *msgbuf, int ignore_footer, int no_dup_sob) strbuf_addch(sob, '\n'); for (i = msgbuf-len - 1 - ignore_footer; i 0 msgbuf-buf[i - 1] != '\n'; i--) ; /* do nothing */ - if (!i || !(has_footer = - has_conforming_footer(msgbuf, sob, ignore_footer))) + if (msgbuf-buf[i] != '\n' (!i || !(has_footer = + has_conforming_footer(msgbuf, sob, ignore_footer strbuf_splice(msgbuf, msgbuf-len - ignore_footer, 0, \n, 1); if (has_footer != 3 (!no_dup_sob || has_footer != 2)) strbuf_splice(msgbuf, msgbuf-len - ignore_footer, 0, -- 1.8.0.284.g959048a -- 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 08/11] t4014: more tests about appending s-o-b lines
From: Nguyễn Thái Ngọc Duy pclo...@gmail.com
[bc: fix test 90 signoff: some random signoff-alike and mark as failing.
Correct behavior should insert a blank line after message body and
signed-off-by ]
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
Signed-off-by: Brandon Casey bca...@nvidia.com
---
t/t4014-format-patch.sh | 146
1 file changed, 146 insertions(+)
diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh
index 16a4ca1..dfe9209 100755
--- a/t/t4014-format-patch.sh
+++ b/t/t4014-format-patch.sh
@@ -963,4 +963,150 @@ test_expect_success 'format patch ignores color.ui' '
test_cmp expect actual
'
+append_signoff()
+{
+ C=`git commit-tree HEAD^^{tree} -p HEAD`
+ git format-patch --stdout --signoff ${C}^..${C} |
+ tee append_signoff.patch |
+ sed -n 1,/^---$/p |
+ grep -n -E ^Subject|Sign|^$
+}
+
+test_expect_success 'signoff: commit with no body' '
+ append_signoff /dev/null actual
+ cat \EOF | sed s/EOL$// expected
+4:Subject: [PATCH] EOL
+8:
+9:Signed-off-by: C O Mitter commit...@example.com
+EOF
+ test_cmp expected actual
+'
+
+test_expect_success 'signoff: commit with only subject' '
+ echo subject | append_signoff actual
+ cat expected \EOF
+4:Subject: [PATCH] subject
+8:
+9:Signed-off-by: C O Mitter commit...@example.com
+EOF
+ test_cmp expected actual
+'
+
+test_expect_success 'signoff: commit with only subject that does not end with
NL' '
+ echo -n subject | append_signoff actual
+ cat expected \EOF
+4:Subject: [PATCH] subject
+8:
+9:Signed-off-by: C O Mitter commit...@example.com
+EOF
+ test_cmp expected actual
+'
+
+test_expect_success 'signoff: no existing signoffs' '
+ append_signoff \EOF actual
+subject
+
+body
+EOF
+ cat expected \EOF
+4:Subject: [PATCH] subject
+8:
+10:
+11:Signed-off-by: C O Mitter commit...@example.com
+EOF
+ test_cmp expected actual
+'
+
+test_expect_success 'signoff: no existing signoffs and no trailing NL' '
+ printf subject\n\nbody | append_signoff actual
+ cat expected \EOF
+4:Subject: [PATCH] subject
+8:
+10:
+11:Signed-off-by: C O Mitter commit...@example.com
+EOF
+ test_cmp expected actual
+'
+
+test_expect_success 'signoff: some random signoff' '
+ append_signoff \EOF actual
+subject
+
+body
+
+Signed-off-by: my@house
+EOF
+ cat expected \EOF
+4:Subject: [PATCH] subject
+8:
+10:
+11:Signed-off-by: my@house
+12:Signed-off-by: C O Mitter commit...@example.com
+EOF
+ test_cmp expected actual
+'
+
+test_expect_failure 'signoff: some random signoff-alike' '
+ append_signoff \EOF actual
+subject
+
+body
+Fooled-by-me: my@house
+EOF
+ cat expected \EOF
+4:Subject: [PATCH] subject
+8:
+11:
+12:Signed-off-by: C O Mitter commit...@example.com
+EOF
+ test_cmp expected actual
+'
+
+test_expect_success 'signoff: the same signoff at the end' '
+ append_signoff \EOF actual
+subject
+
+body
+
+Signed-off-by: C O Mitter commit...@example.com
+EOF
+ cat expected \EOF
+4:Subject: [PATCH] subject
+8:
+10:
+11:Signed-off-by: C O Mitter commit...@example.com
+EOF
+ test_cmp expected actual
+'
+
+test_expect_success 'signoff: the same signoff at the end, no trailing NL' '
+ printf subject\n\nSigned-off-by: C O Mitter commit...@example.com |
+ append_signoff actual
+ cat expected \EOF
+4:Subject: [PATCH] subject
+8:
+9:Signed-off-by: C O Mitter commit...@example.com
+EOF
+ test_cmp expected actual
+'
+
+test_expect_success 'signoff: the same signoff NOT at the end' '
+ append_signoff \EOF actual
+subject
+
+body
+
+Signed-off-by: C O Mitter commit...@example.com
+Signed-off-by: my@house
+EOF
+ cat expected \EOF
+4:Subject: [PATCH] subject
+8:
+10:
+11:Signed-off-by: C O Mitter commit...@example.com
+12:Signed-off-by: my@house
+EOF
+ test_cmp expected actual
+'
+
test_done
--
1.8.0.284.g959048a
--
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 09/11] format-patch: stricter S-o-b detection
From: Nguyễn Thái Ngọc Duy pclo...@gmail.com
S-o-b in the middle of a sentence, at the beginning of the sentence
but it is just because of text wrapping, or a full paragraph of valid
S-o-b in the middle of the message. All these are not S-o-b, but
detected as is. Fix them.
[bc: add two additional tests to demonstrate shortcomings of the current
code:
1. failure to detect non-conforming elements in the footer when last
line matches committer's s-o-b.
2. failure to handle various s-o-b -like elements in the footer as
conforming. e.g. Change-id: I or Bug: 1234
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
Signed-off-by: Brandon Casey bca...@nvidia.com
---
log-tree.c | 37 +--
t/t4014-format-patch.sh | 95 +
2 files changed, 130 insertions(+), 2 deletions(-)
diff --git a/log-tree.c b/log-tree.c
index 4f86def..14ebf69 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -260,14 +260,47 @@ static void append_signoff(struct strbuf *sb, const char
*signoff)
int has_signoff = 0;
char *cp;
- cp = sb-buf;
+ /*
+* Only search in the last paragrah, don't be fooled by a
+* paragraph full of valid S-o-b in the middle.
+*/
+ cp = sb-buf + sb-len - 1;
+ while (cp sb-buf) {
+ if (cp[0] == '\n' cp[1] == '\n') {
+ cp += 2;
+ break;
+ }
+ cp--;
+ }
/* First see if we already have the sign-off by the signer */
while ((cp = strstr(cp, signed_off_by))) {
+ const char *s = cp;
+ cp += strlen(signed_off_by);
+
+ if (!has_signoff s sb-buf) {
+ /*
+* S-o-b in the middle of a sentence is not
+* really S-o-b
+*/
+ if (s[-1] != '\n')
+ continue;
+
+ if (s - 1 sb-buf s[-2] == '\n')
+ ; /* the first S-o-b */
+ else if (!detect_any_signoff(sb-buf, s - sb-buf))
+ /*
+* The previous line looks like an
+* S-o-b. There's still no guarantee
+* that it's an actual S-o-b. For that
+* we need to look back until we find
+* a blank line, which is too costly.
+*/
+ continue;
+ }
has_signoff = 1;
- cp += strlen(signed_off_by);
if (cp + signoff_len = sb-buf + sb-len)
break;
if (strncmp(cp, signoff, signoff_len))
diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh
index dfe9209..30e37a7 100755
--- a/t/t4014-format-patch.sh
+++ b/t/t4014-format-patch.sh
@@ -1062,6 +1062,60 @@ EOF
test_cmp expected actual
'
+test_expect_success 'signoff: not really a signoff' '
+ append_signoff \EOF actual
+subject
+
+I want to mention about Signed-off-by: here.
+EOF
+ cat expected \EOF
+4:Subject: [PATCH] subject
+8:
+9:I want to mention about Signed-off-by: here.
+10:
+11:Signed-off-by: C O Mitter commit...@example.com
+EOF
+ test_cmp expected actual
+'
+
+test_expect_success 'signoff: not really a signoff (2)' '
+ append_signoff \EOF actual
+subject
+
+My unfortunate
+Signed-off-by: example happens to be wrapped here.
+EOF
+ cat expected \EOF
+4:Subject: [PATCH] subject
+8:
+10:Signed-off-by: example happens to be wrapped here.
+11:
+12:Signed-off-by: C O Mitter commit...@example.com
+EOF
+ test_cmp expected actual
+'
+
+test_expect_success 'signoff: valid S-o-b paragraph in the middle' '
+ append_signoff \EOF actual
+subject
+
+Signed-off-by: my@house
+Signed-off-by: your@house
+
+A lot of houses.
+EOF
+ cat expected \EOF
+4:Subject: [PATCH] subject
+8:
+9:Signed-off-by: my@house
+10:Signed-off-by: your@house
+11:
+13:
+14:Signed-off-by: C O Mitter commit...@example.com
+EOF
+ test_cmp expected actual
+'
+
test_expect_success 'signoff: the same signoff at the end' '
append_signoff \EOF actual
subject
@@ -1109,4 +1163,45 @@ EOF
test_cmp expected actual
'
+test_expect_failure 'signoff: detect garbage in non-conforming footer' '
+ append_signoff \EOF actual
+subject
+
+body
+
+Tested-by: my@house
+Some Trash
+Signed-off-by: C O Mitter commit...@example.com
+EOF
+ cat expected \EOF
+4:Subject: [PATCH] subject
+8:
+10:
+13:Signed-off-by: C O Mitter commit...@example.com
+14:
+15:Signed-off-by: C O Mitter commit...@example.com
+EOF
+ test_cmp expected actual
+'
+
+test_expect_failure 'signoff: footer begins with non-signoff without @ sign' '
+
[PATCH 10/11] format-patch: update append_signoff prototype
From: Nguyễn Thái Ngọc Duy pclo...@gmail.com
This is a preparation step for merging with append_signoff from
sequencer.c
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
Signed-off-by: Brandon Casey bca...@nvidia.com
---
builtin/log.c | 13 +
log-tree.c| 21 +
revision.h| 2 +-
3 files changed, 15 insertions(+), 21 deletions(-)
diff --git a/builtin/log.c b/builtin/log.c
index e7b7db1..bb48344 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -1058,7 +1058,6 @@ int cmd_format_patch(int argc, const char **argv, const
char *prefix)
struct commit *origin = NULL, *head = NULL;
const char *in_reply_to = NULL;
struct patch_ids ids;
- char *add_signoff = NULL;
struct strbuf buf = STRBUF_INIT;
int use_patch_format = 0;
int quiet = 0;
@@ -1154,16 +1153,6 @@ int cmd_format_patch(int argc, const char **argv, const
char *prefix)
PARSE_OPT_KEEP_ARGV0 | PARSE_OPT_KEEP_UNKNOWN |
PARSE_OPT_KEEP_DASHDASH);
- if (do_signoff) {
- const char *committer;
- const char *endpos;
- committer = git_committer_info(IDENT_STRICT);
- endpos = strchr(committer, '');
- if (!endpos)
- die(_(bogus committer info %s), committer);
- add_signoff = xmemdupz(committer, endpos - committer + 1);
- }
-
for (i = 0; i extra_hdr.nr; i++) {
strbuf_addstr(buf, extra_hdr.items[i].string);
strbuf_addch(buf, '\n');
@@ -1354,7 +1343,7 @@ int cmd_format_patch(int argc, const char **argv, const
char *prefix)
total++;
start_number--;
}
- rev.add_signoff = add_signoff;
+ rev.add_signoff = do_signoff;
while (0 = --nr) {
int shown;
commit = list[nr];
diff --git a/log-tree.c b/log-tree.c
index 14ebf69..be8e7ab 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -253,9 +253,11 @@ static int detect_any_signoff(char *letter, int size)
return seen_head seen_name;
}
-static void append_signoff(struct strbuf *sb, const char *signoff)
+static void append_signoff(struct strbuf *sb, int flags)
{
- static const char signed_off_by[] = Signed-off-by: ;
+ char* signoff = xstrdup(fmt_name(getenv(GIT_COMMITTER_NAME),
+getenv(GIT_COMMITTER_EMAIL)));
+ static const char sign_off_header[] = Signed-off-by: ;
size_t signoff_len = strlen(signoff);
int has_signoff = 0;
char *cp;
@@ -274,9 +276,9 @@ static void append_signoff(struct strbuf *sb, const char
*signoff)
}
/* First see if we already have the sign-off by the signer */
- while ((cp = strstr(cp, signed_off_by))) {
+ while ((cp = strstr(cp, sign_off_header))) {
const char *s = cp;
- cp += strlen(signed_off_by);
+ cp += strlen(sign_off_header);
if (!has_signoff s sb-buf) {
/*
@@ -317,9 +319,10 @@ static void append_signoff(struct strbuf *sb, const char
*signoff)
if (!has_signoff)
strbuf_addch(sb, '\n');
- strbuf_addstr(sb, signed_off_by);
+ strbuf_addstr(sb, sign_off_header);
strbuf_add(sb, signoff, signoff_len);
strbuf_addch(sb, '\n');
+ free(signoff);
}
static unsigned int digits_in_number(unsigned int number)
@@ -695,8 +698,10 @@ void show_log(struct rev_info *opt)
/*
* And then the pretty-printed message itself
*/
- if (ctx.need_8bit_cte = 0)
- ctx.need_8bit_cte = has_non_ascii(opt-add_signoff);
+ if (ctx.need_8bit_cte = 0 opt-add_signoff)
+ ctx.need_8bit_cte =
+ has_non_ascii(fmt_name(getenv(GIT_COMMITTER_NAME),
+ getenv(GIT_COMMITTER_EMAIL)));
ctx.date_mode = opt-date_mode;
ctx.date_mode_explicit = opt-date_mode_explicit;
ctx.abbrev = opt-diffopt.abbrev;
@@ -707,7 +712,7 @@ void show_log(struct rev_info *opt)
pretty_print_commit(ctx, commit, msgbuf);
if (opt-add_signoff)
- append_signoff(msgbuf, opt-add_signoff);
+ append_signoff(msgbuf, 0);
if ((ctx.fmt != CMIT_FMT_USERFORMAT)
ctx.notes_message *ctx.notes_message) {
diff --git a/revision.h b/revision.h
index 059bfff..435a60b 100644
--- a/revision.h
+++ b/revision.h
@@ -137,7 +137,7 @@ struct rev_info {
int numbered_files;
char*message_id;
struct string_list *ref_message_ids;
- const char *add_signoff;
+ int add_signoff;
const char *extra_headers;
const char *log_reencode;
const char *subject_prefix;
--
1.8.0.284.g959048a
--
To unsubscribe from this list:
[PATCH 11/11] Unify appending signoff in format-patch, commit and sequencer
There are two implementations of append_signoff in log-tree.c and
sequencer.c, which do more or less the same thing. Unify on top of the
sequencer.c implementation.
Add a test in t4014 to demonstrate support for non-s-o-b elements in the
commit footer provided by sequence.c:append_sob. Mark tests fixed as
appropriate.
[Commit message mostly stolen from Nguyễn Thái Ngọc Duy's original
unification patch]
Signed-off-by: Brandon Casey bca...@nvidia.com
---
log-tree.c | 122 +---
t/t4014-format-patch.sh | 27 +--
2 files changed, 26 insertions(+), 123 deletions(-)
diff --git a/log-tree.c b/log-tree.c
index be8e7ab..1fb0a16 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -9,6 +9,7 @@
#include string-list.h
#include color.h
#include gpg-interface.h
+#include sequencer.h
struct decoration name_decoration = { object names };
@@ -206,125 +207,6 @@ void show_decorations(struct rev_info *opt, struct commit
*commit)
putchar(')');
}
-/*
- * Search for ^[-A-Za-z]+: [^@]+@ pattern. It usually matches
- * Signed-off-by: and Acked-by: lines.
- */
-static int detect_any_signoff(char *letter, int size)
-{
- char *cp;
- int seen_colon = 0;
- int seen_at = 0;
- int seen_name = 0;
- int seen_head = 0;
-
- cp = letter + size;
- while (letter = --cp *cp == '\n')
- continue;
-
- while (letter = cp) {
- char ch = *cp--;
- if (ch == '\n')
- break;
-
- if (!seen_at) {
- if (ch == '@')
- seen_at = 1;
- continue;
- }
- if (!seen_colon) {
- if (ch == '@')
- return 0;
- else if (ch == ':')
- seen_colon = 1;
- else
- seen_name = 1;
- continue;
- }
- if (('A' = ch ch = 'Z') ||
- ('a' = ch ch = 'z') ||
- ch == '-') {
- seen_head = 1;
- continue;
- }
- /* no empty last line doesn't match */
- return 0;
- }
- return seen_head seen_name;
-}
-
-static void append_signoff(struct strbuf *sb, int flags)
-{
- char* signoff = xstrdup(fmt_name(getenv(GIT_COMMITTER_NAME),
-getenv(GIT_COMMITTER_EMAIL)));
- static const char sign_off_header[] = Signed-off-by: ;
- size_t signoff_len = strlen(signoff);
- int has_signoff = 0;
- char *cp;
-
- /*
-* Only search in the last paragrah, don't be fooled by a
-* paragraph full of valid S-o-b in the middle.
-*/
- cp = sb-buf + sb-len - 1;
- while (cp sb-buf) {
- if (cp[0] == '\n' cp[1] == '\n') {
- cp += 2;
- break;
- }
- cp--;
- }
-
- /* First see if we already have the sign-off by the signer */
- while ((cp = strstr(cp, sign_off_header))) {
- const char *s = cp;
- cp += strlen(sign_off_header);
-
- if (!has_signoff s sb-buf) {
- /*
-* S-o-b in the middle of a sentence is not
-* really S-o-b
-*/
- if (s[-1] != '\n')
- continue;
-
- if (s - 1 sb-buf s[-2] == '\n')
- ; /* the first S-o-b */
- else if (!detect_any_signoff(sb-buf, s - sb-buf))
- /*
-* The previous line looks like an
-* S-o-b. There's still no guarantee
-* that it's an actual S-o-b. For that
-* we need to look back until we find
-* a blank line, which is too costly.
-*/
- continue;
- }
-
- has_signoff = 1;
-
- if (cp + signoff_len = sb-buf + sb-len)
- break;
- if (strncmp(cp, signoff, signoff_len))
- continue;
- if (!isspace(cp[signoff_len]))
- continue;
- /* we already have him */
- return;
- }
-
- if (!has_signoff)
- has_signoff = detect_any_signoff(sb-buf, sb-len);
-
- if (!has_signoff)
- strbuf_addch(sb, '\n');
-
- strbuf_addstr(sb, sign_off_header);
- strbuf_add(sb, signoff, signoff_len);
- strbuf_addch(sb, '\n');
- free(signoff);
-}
-
static
Re: [PATCH] fast-export: Allow pruned-references in mark file
Antoine Pelisse apeli...@gmail.com writes:
fast-export can fail because of some pruned-reference when importing a
mark file.
The problem happens in the following scenario:
$ git fast-export --export-marks=MARKS master
(rewrite master)
$ git prune
$ git fast-export --import-marks=MARKS master
This might fail if some references have been removed by prune
because some marks will refer to non-existing commits.
Let's warn when we have a mark for a commit we don't know.
Also, increment the last_idnum before, so we don't override
the mark.
Is this a safe and sane thing to do, and if so why? Could you
describe that in the log message here?
Signed-off-by: Antoine Pelisse apeli...@gmail.com
---
builtin/fast-export.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/builtin/fast-export.c b/builtin/fast-export.c
index 12220ad..141b245 100644
--- a/builtin/fast-export.c
+++ b/builtin/fast-export.c
@@ -607,16 +607,19 @@ static void import_marks(char *input_file)
|| *mark_end != ' ' || get_sha1(mark_end + 1, sha1))
die(corrupt mark line: %s, line);
+ if (last_idnum mark)
+ last_idnum = mark;
+
object = parse_object(sha1);
- if (!object)
- die (Could not read blob %s, sha1_to_hex(sha1));
+ if (!object) {
+ warning(Could not read blob %s, sha1_to_hex(sha1));
+ continue;
+ }
if (object-flags SHOWN)
error(Object %s already has a mark,
sha1_to_hex(sha1));
mark_object(object, mark);
- if (last_idnum mark)
- last_idnum = mark;
object-flags |= SHOWN;
}
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/7] New remote-bzr remote helper
Felipe Contreras felipe.contre...@gmail.com writes: On Sun, Nov 11, 2012 at 3:19 PM, Felipe Contreras felipe.contre...@gmail.com wrote: This is a re-roll of the previous series to add support to fetch and push special modes, and refactor some related code. It seems this one got forgotten, I only see v2 in pu. Oops; I think that was fell through the cracks during the maintainer hand-off. As the previous one has already been cooking in 'next' for a week or so, I would appreciate if you send incremental updates to fix or enhance what is in there. Thanks. -- 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 documentation on how to integrate commands.
e...@thyrsus.com (Eric S. Raymond) writes: --- Sign off? Documentation/CommandIntegration | 69 ++ 1 file changed, 69 insertions(+) create mode 100644 Documentation/CommandIntegration diff --git a/Documentation/CommandIntegration b/Documentation/CommandIntegration new file mode 100644 index 000..be248f7 --- /dev/null +++ b/Documentation/CommandIntegration @@ -0,0 +1,69 @@ += Integrating new subcommands = + +This is how-to documentation for people who want to add extension +commands to git. + +== Runtime environment == + +git subcommands are standalone executables that live in the git +execution directory, normally /usr/lib/git-core. The git executable itself +is a thin wrapper that sets GIT_DIR and passes command-line arguments +to the subcommand. + +(If git foo is not found in the git execution directory, the wrapper +will look in the rest of your $PATH for it. Thus, it's possible As the first sentence in this paragraph does not make it clear enough that you are defining a new term git execution directory, execution directory here may be misleading and can easily be mistaken as if we look something in the directory where the user runs git in. We usually call it exec path. +== Implementation languages == + +Most subcommands are written in C or shell. A few are written in +Perl. A tiny minority are written in Python. + +While we strongly encourage coding in portable C for portability, these +specific scripting languages are also acceptable. We won't accept more +without a very strong technical case, as we don't want to broaden the +git suite's required dependencies. Actually, we tend to avoid Python dependency for anything important and allow it only on fringes; people who lack Python environment are not missing much, and we would want to keep it that way until the situation on the Windows front changes. +C commands are normally written as single modules, named after the +command, that link a core library called libgit. Thus, your command I would prefer to see this sentence not call libgit.a a library. We primarily use libgit.a to let linker pick necessary object files without us having to list object files for non-builtin command implementations and it is not designed to be used by other people. +== Integrating a command == + +Here are the things you need to do when you want to merge a new +subcommand into the git tree. + +1. Append your command name to one of the variables BUILTIN_OBJS, +EXTRA_PROGRAMS, SCRIPT_SH, SCRIPT_PERL or SCRIPT_PYTHON. + +2. Drop its test in the t directory. + +That's all there is to it. And when sending a patch in, do not forget to sign off your patches ;-) -- 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: Requirements for integrating a new git subcommand
Junio C Hamano gits...@pobox.com: Eric S. Raymond e...@thyrsus.com writes: While the weave operation can build a commit graph with any structure desired, an important restriction of the inverse (unraveling) operation is that it operates on *master branches only*. The unravel operation discards non-master-branch content, emitting a warning to standard error when it has to do so. Imagine that I have a simple four-commit diamond: I---A \ \ B---M where Amy and Bob forked the initial commit made by Ian and created one commit each, and their branches were merged into one 'master' branch by a merge commit made by Mac. How many state snapshots will I see when I ask you to unravel this? Three, or four? You will see four tree states. I have managed to remove the master-branch-only restriction. As to the procedural stuff, I think others have sufficiently answered already. If I may add something, a new stuff typically start its life in contrib/ before it proves to be useful. Thank you, I have submitted a documentation patch which folds in the on-list discussion. As a separate point...are you requesting that I submit my integration patch to drop git-weave in contrib? If so, I will of course comply. But I will point out that git-weave is not a half-thought out experiment; it is fully documented and has a functional test. The case for its usefulness is bolstered by one previous contrib script, which the author has agreed to retire in favor of git-weave. -- a href=http://www.catb.org/~esr/;Eric S. Raymond/a -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] second try
Sven Strickroth sven.strickr...@tu-clausthal.de writes: Am 11.11.2012 17:40 schrieb Sven Strickroth: Am 06.10.2012 20:28 schrieb Junio C Hamano: It is either that it was simply forgotten, or after I wrote the part you quoted early in January there were discussions later that showed the patch was not desirable for some reason. I do not recall which. I noticed no threads about possible problems, so I try again. On November 11th I submitted the updated patches again, however, without any reaction or comments. I think between Peff and me it fell in the cracks during the hand-off; I do not know about the others, probably people did not find it interesting perhaps? I'll add Eric Wong (git-svn submaintainer) to Cc. -- 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
Can I zip a git repo without losing anything?
Hi all This is my first post to this list, so thank you for all your work. After suggesting using zip files to move our projects around, I was told that you can not zip a git repo without loosing all the history. This didn't make sense to me, but two people told me the same thing, so I wasn't sure. I think they may have been confusing the zipped file you can download from GitHub with a zipped git repo. If someone could put me straight on this, I'd really appreciate it. Thanks Carl -- 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: Python extension commands in git - request for policy change
On Mon, Nov 26, 2012 at 4:17 AM, Eric S. Raymond e...@thyrsus.com wrote: Krzysztof Mazur krzys...@podlesie.net: What about embedded systems? git is also useful there. C and shell is everywhere, python is not. Supposing this is true (and I question it with regard to shell) if you tell me how you live without gitk and the Perl pieces I'll play that right back at you as your answer. gitk is unlikely to be used on an embedded system, the perl pieces more so. I have never understood why people complain about readability in perl. Just because it uses the ascii charset a bit more? You expect a mathematician or indeed any scientist to use special symbols to mean special things, why not programmers? Perhaps people should be forced to use COBOL for a few years (like I did, a long while ago) to appreciate brevity. -- 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
links of london friendship bracelet try and proper some United kingdom eccentricity
Necklaces has become utilized by means of human beings intended for many years, in addition to recommended different things to help families in addition to countries. In the course of heritage humankind include desired objects having which often to help accentuate independently, from time to time intended for ornament, from time to time for just a greater significance. Currently persons tend to have a number of objectives in their necklaces, of which it ought to be premium quality, hip in addition to beautiful. [url=http://www.linksoflondonsweetiebracelets.co.uk/]links of london sale[/url] aim to meet every time with their beautiful modern collections. Whether you are looking for an amazing gift for someone special, or looking to treat yourself, there may well be an item which is just right for you. The history of the company is interesting, and goes to show that even internationally recognised brands start out small to begin with! If you are considering purchasing their products, some company history and additional information may help to finalise a decision one way or the other. Links of London was created in 1990 in the city of London,UK,in response to a request from a local restaurant owner for a pair of Sterling silver cufflinks, which were to be given to loyal customers.These were seen by the exclusive fashion retailer Harvey Nichols who then proceeded to order an entire collection.From then onwards the brand has continued to attract interest and win admirers. The company now has stores in the USA, Canada,Hong Kong as well as the UK. The company tries to allow personalisation of their products by providing space for engravings and embossing,as well as producing a range of charms for individuals to choose from to make sweetie bracelets their own. The presentation of items is exceptional; the company prides itself in making each piece special, through the use of special boxes, ribbons and bows.This adds an extra feeling of luxury to the items of jewellery, making your gift or purchase all the more exciting.[url=http://www.linksoflondonsweetiebracelets.co.uk/]links of london friendship bracelet[/url] try to inject an element of British eccentricity and a sense of humour into their ranges,which further adds to their appeal in the UK and abroad. http://www.linksoflondonsweetiebracelets.co.uk/ -- View this message in context: http://git.661346.n2.nabble.com/links-of-london-friendship-bracelet-try-and-proper-some-United-kingdom-eccentricity-tp7571934.html Sent from the git mailing list archive at Nabble.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
[RFC] pack-objects: compression level for non-blobs
Add config pack.graphcompression similar to pack.compression.
Applies to non-blob objects and if unspecified falls back to pack.compression.
We may identify objects compressed with level 0 by their leading bytes.
Use this to force recompression when the source and target levels mismatch.
Limit its application to when the config pack.graphcompression is set.
Signed-off-by: David Michael Barr b...@rr-dav.id.au
---
builtin/pack-objects.c | 49 +
1 file changed, 45 insertions(+), 4 deletions(-)
I started working on this just before taking a vacation,
so it's been a little while coming.
The intent is to allow selective recompression of pack data.
For small objects/deltas the overhead of deflate is significant.
This may improve read performance for the object graph.
I ran some unscientific experiments with the chromium repository.
With pack.graphcompression = 0, there was a 2.7% increase in pack size.
I saw a 35% improvement with cold caches and 43% otherwise on git log --raw.
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index f069462..9518daf 100644
--- a/builtin/pack-objects.c
+++ b/builtin/pack-objects.c
@@ -40,6 +40,7 @@ struct object_entry {
unsigned long z_delta_size; /* delta data size (compressed) */
unsigned int hash; /* name hint hash */
enum object_type type;
+ enum object_type actual_type;
enum object_type in_pack_type; /* could be delta */
unsigned char in_pack_header_size;
unsigned char preferred_base; /* we do not pack this, but is available
@@ -81,6 +82,8 @@ static int num_preferred_base;
static struct progress *progress_state;
static int pack_compression_level = Z_DEFAULT_COMPRESSION;
static int pack_compression_seen;
+static int pack_graph_compression_level = Z_DEFAULT_COMPRESSION;
+static int pack_graph_compression_seen;
static unsigned long delta_cache_size = 0;
static unsigned long max_delta_cache_size = 256 * 1024 * 1024;
@@ -125,14 +128,14 @@ static void *get_delta(struct object_entry *entry)
return delta_buf;
}
-static unsigned long do_compress(void **pptr, unsigned long size)
+static unsigned long do_compress(void **pptr, unsigned long size, int level)
{
git_zstream stream;
void *in, *out;
unsigned long maxsize;
memset(stream, 0, sizeof(stream));
- git_deflate_init(stream, pack_compression_level);
+ git_deflate_init(stream, level);
maxsize = git_deflate_bound(stream, size);
in = *pptr;
@@ -191,6 +194,18 @@ static unsigned long write_large_blob_data(struct
git_istream *st, struct sha1fi
return olen;
}
+static int check_pack_compressed(struct packed_git *p,
+ struct pack_window **w_curs,
+ off_t offset)
+{
+ unsigned long avail;
+ int compressed = 0;
+ unsigned char *in = use_pack(p, w_curs, offset, avail);
+ if (avail = 3)
+ compressed = !!(in[2] 0x6);
+ return compressed;
+}
+
/*
* we are going to reuse the existing object data as is. make
* sure it is not corrupt.
@@ -240,6 +255,8 @@ static void copy_pack_data(struct sha1file *f,
}
}
+#define compression_level(type) ((type) (type) != OBJ_BLOB ?
pack_graph_compression_level : pack_compression_level)
+
/* Return 0 if we will bust the pack-size limit */
static unsigned long write_no_reuse_object(struct sha1file *f, struct
object_entry *entry,
unsigned long limit, int
usable_delta)
@@ -286,7 +303,7 @@ static unsigned long write_no_reuse_object(struct sha1file
*f, struct object_ent
else if (entry-z_delta_size)
datalen = entry-z_delta_size;
else
- datalen = do_compress(buf, size);
+ datalen = do_compress(buf, size,
compression_level(entry-actual_type));
/*
* The object header is a byte of 'type' followed by zero or
@@ -379,6 +396,13 @@ static unsigned long write_reuse_object(struct sha1file
*f, struct object_entry
offset += entry-in_pack_header_size;
datalen -= entry-in_pack_header_size;
+ if (!pack_to_stdout
+ pack_graph_compression_seen
+ check_pack_compressed(p, w_curs, offset) !=
!!compression_level(entry-actual_type)) {
+ unuse_pack(w_curs);
+ return write_no_reuse_object(f, entry, limit, usable_delta);
+ }
+
if (!pack_to_stdout p-index_version == 1
check_pack_inflate(p, w_curs, offset, datalen, entry-size)) {
error(corrupt packed object for %s,
sha1_to_hex(entry-idx.sha1));
@@ -955,6 +979,8 @@ static int add_object_entry(const unsigned char *sha1, enum
object_type type,
memset(entry, 0, sizeof(*entry));
hashcpy(entry-idx.sha1, sha1);
entry-hash = hash;
+ if (pack_graph_compression_seen)
+ entry-actual_type =
bijoux swarovski could be the selection of every person
There are various types of crystalfigurines as well as each individual gathers all of them with regard to their own factors. They may be big collectible figurines which are the discussion item on their own, as well as little sensitive types which are available in models. If you're considering accumulating collectible figurines for your own personel curio cupboard, there are several points you need to know. Not every are made equivalent and never all are made from qualitySwarovski very. There are several particular factors the very porcelain figurine has the actual Swarovski title. To begin all,[url=http://www.bijouxswarovskiboutique.com/]swarovski[/url] spells luxury. Daniel Swarovski was born in what is now the Czech Republic and his father owned a small glass factory where Daniel did an apprenticeship as a young man. It was here that he learned the art of glass cutting, but didn't make crystal figurines just yet. http://www.bijouxswarovskiboutique.com/ -- View this message in context: http://git.661346.n2.nabble.com/bijoux-swarovski-could-be-the-selection-of-every-person-tp7571940.html Sent from the git mailing list archive at Nabble.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: [PATCH 00/11] alternative unify appending of sob
On Mon, Nov 26, 2012 at 8:45 AM, Brandon Casey draf...@gmail.com wrote: From: Brandon Casey bca...@nvidia.com I hate to have the battle of the patches, but I kinda prefer the append_signoff code in sequencer.c over the code in log-tree.c as a foundation to build on. So, this series is similar to Duy's unification series, but it goes in the opposite direction and builds on top of sequencer.c and additionally adds the elements from my original series to treat the (cherry picked from... line added by 'cherry-pick -x' in the same way that other footer elements are treated (after addressing Junio's comments about rfc2822 continuation lines and duplicate s-o-b's). I've integrated Duy's series with a few minor tweaks. I added a couple of additional tests to t4014 and corrected one of the tests which had incorrect behavior. I think his sign-off's should still be valid, so I kept them in. Sorry that I've been slow, and now the two of us are stepping on each other's toes, but Duy please take a look and let me know if there's anything you dislike. I'm still not sure whether format-patch should follow cherry-pick's rule in appending sob. If it does, it probably makes more sense to fix the sequencer.c code then delete log-tree.c (not fixes on log-tree.c then delete it). I see that your changes pass all the new tests I added in format-patch so sequencer.c is probably good enough, log-tree.c changes are probably not needed. Feel free take over the series :-) -- 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
