Re: A few contributor's questions
On 2014-01-31 14:04, David Kastrup wrote: I'm still in the process of finishing the rewrite of the builtin/blame.c internals. Now there are various questions regarding the final patch proposals and commit messages. Point 1) signing off implies that I'm fine with the licensing of the file. builtin/blame.c merely states /* * Blame * * Copyright (c) 2006, Junio C Hamano */ which obviously will not match the authorship of my contributions. Since Junio has given blanket permission to reuse his Git contributions under other licenses (see URL:https://github.com/libgit2/libgit2/blob/development/git.git-authors#L58) that I am not going to license my work under, the first commit in the respective series would replace this header with It's a long time since I wrote that document. Does this mean you're not willing to relicense your contributions with the license used by libgit2? That's what the document is supposed to mean and it's what I asked on the mailing list when requesting permission. The libgit2 license used as of today is still the license that people agreed to relicense their contributions under. It can be found here: https://github.com/libgit2/libgit2/blob/development/.HEADER I'm mostly adding it here for the sake of clarity in case people find this in the future and wonder what all the fuzz was about. -- Andreas Ericsson andreas.erics...@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. -- 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: htonll, ntohll
On 2013-11-05 01:00, Ramsay Jones wrote: [Note: I have never particularly liked htons, htonl et.al., so adding these htonll/ntohll functions doesn't thrill me! :-D For example see this post[1], which echo's my sentiments exactly.] That post actually contradicts your statement, as it clearly states that someone at Adobe figured out about byte order and there would have been no problems transferring files between (big-endian and little-endian) machines... if the people at Adobe wrote proper code to encode and decode their files. htonl(), ntohl(), htons(), ntohs() are those encode and decode functions. If you or the author of the post you linked think otherwise, you're misinformed and need to learn what encoding and decoding means. -- Andreas Ericsson andreas.erics...@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. -- 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/86] replace prefixcmp() with has_prefix()
On 2013-11-09 08:05, Christian Couder wrote: Here is a big patch series to replace prefixcmp() with a new has_prefix() function. Seems like totally useless codechurn to me. Besides, prefixcmp() ties in nicely with strcmp() and memcmp() (and returns 0 on a match just like its namesakes), whereas your function must return non-zero on match and thus can't be used as a qsort() callback. Granted, prefixcmp() lends itself poorly to that as well, but at least it's consistent with the other *cmp() functions. So -1 on this whole series. -- Andreas Ericsson andreas.erics...@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. -- 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: Understanding Git Under The Hood: Trees
On 2013-08-15 21:32, Erik Bernoth wrote: On Thu, Aug 15, 2013 at 7:31 PM, Junio C Hamano gits...@pobox.com wrote: While the last statement applies to other parts of the system, it is not true for the in-core index design. We always had a flat index, and it is not cheating at all. The original tree was also a flat representation of everything under the sun, and hierarchical tree objects came much later. To some degree that revalidates my interpretation of Andreas' statements. If I understand it correctly eacht time a shell command is executed, which requires tree interaction, the corresponding tree is read from filesystem to memory completely before anything is done? More or less, yes, but please don't confuse directory tree with git tree. They're not the same. A directory tree can contain multiple levels of directories, whereas a git tree can only contain a list of objects. The index (aka staging area) represents a directory tree, but when it gets stored on-disk a directory tree gets broken down into as many git trees as is necessary. The index is just a cache though. Until changes have been staged to it in preparation for the next commit, it can be recreated exactly from the currently checked out commit. As Junio pointed out, the index has been flat from the very beginning. Don't confuse the index with the git tree objects found in the object storage though, or the working tree with git trees. They're really not the same. To illustrate the differences, here's a few commands and what they do and operate on, with regards to the three different kinds of trees that have come up in this discussion. Ignore everything git-related and only print the worktree: find . Ignores everything index- and worktree-related and only print the root git tree of the currently checked out commit. You won't see any relative paths or directories in there; Just a list of trees and blobs: git cat-file -p $(git cat-file -p HEAD | sed -n 's/^tree //p;q') List staged files only, regardless of what you have in the worktree or what the latest commit looks like. This will look pretty much like the last command, but with files located in subdirectories as well, and an additional field where the index-state is stored: git ls-files -s So if I git-add a file, the whole index is read first, then the memory object is changed and then the resulting change is written to disk bottom-up from the point of view of the tree? When you git-add a file, we read in the index, update it with the new contents of the file you pointed to, or add the new file to it if the file isn't known to us since before. We also add the blob to the object store and write out the new tree(s) to the object store as well. Then we write out the new index, and then we're done. We do all that bottom up, as you say, or the object store will be inconsistent after we started writing root objects but before we're done writing leaf objects. For a simple git-add, that's it, and you'll now see git status list files as added to the index without being committed. They're what we call staged at this point. If you also do git commit after having done git-add, we write out a commit object, pointing to its parent commit and the root tree we created in the git-add stage. git cat-file -p HEAD will give you an idea of how that looks. -- Andreas Ericsson andreas.erics...@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. -- 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: Understanding Git Under The Hood: Trees
wait, although disk I/O is certainly (often) the largest part of that. -- Andreas Ericsson andreas.erics...@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. -- 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: Workflow Help
On 2013-05-21 02:59, Quilkey, Tony wrote: Hi, I am looking at formulating and then documenting our vcs workflow using Git at work. I have an idea of how I want things to work, but am a little hazy on some of the details. Our basic workflow will be based around: http://nvie.com/posts/a-successful-git-branching-model, with a few exceptions. We would like to create our release-* branches from the last release tag. From there, we would like the ability to cherry pick (or take the complete diff) commits from the develop branch. So, we are after is: 1) Create topic (feature) branches from develop, and merge back into develop when complete. 2) Once it is decided we are packaging a release, make a release-* branch from the previous release tag. 3) Cherry pick/merge/whatever any commits we want from develop into the new release-* until it is complete. This will drive you crazy. If you have any sort of tempo on development and separate your commits into small series, it will be close to impossible to track all related changes. I know, as some colleagues tried it not long ago. A better workflow is to use topic-branches for pretty much everything. If the branch is mainly a bugfix, although the bug has to be fixed by refactoring or remodeling something, it gets merged to whatever maint branch you have (in your case I'd imagine that would be release-X something). Then you merge the release-branch into develop and take the other topics directly into develop. We do something like this: * work, work, work (mostly on master) * cut a release by setting a tag and creating a maint-branch for it (actually, it's a beta-release that goes off to QA, but whatever) * maint branches are 100% test-driven development * bugfixes (with their test-cases, as well as test-cases for other affected areas) go directly to maint (although possibly via a topic-branch if the change is bigger than trivial). * maint is merged to master * repeat as necessary It works reasonably well and ensures a high code quality with very little overhead. Sometimes people commit bugfixes to master by mistake. In that case, we simply cherry-pick the fix to 'maint' and then merge maint back to master as usual. It does require some sort of stability between projects and the libs shipped by and used by the project though, but assuming you haven't done things horribly wrong at the design stage, this model should work reasonably well while avoiding the whole where are the bugfixes and in which order do I need to apply them? issue. -- Andreas Ericsson andreas.erics...@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. -- 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: [rfh] do I need to use something more complex to do this?
On 04/10/2013 04:40 PM, Junio C Hamano wrote: I have set of items with two attributes, X,Y, and would like to keep them in some data structure in such a way that it is efficient to (1) add a new item to the data structure, and (2) pick an item in a specific order. There can be multiple items that share the same value for X, or Y, or both X and Y, and it does not matter in what order items comes out among those that share the same X,Y. The type of X is totally ordered. The type of Y also usually is, but Y can take a special value U(nspecified). Now on to the specific order I want to pick an item. I'd like to take the item with the largest value of Y in general, and tiebreaking on the value of X which also I prefer to take from larger to smaller. But with a twist. When I am picking an item X=n,Y=m, there should be no item remaining in the data store with a value of Y that is smaller than m (duplicates are allowed, so there can still be items with Y=m), and also when I am picking X=n,Y=m, there should be no item with Y=Unspecified that has a value of X that is equal or smaller than n. So X is primary sort and Y is secondary, except Y=Undefined trumps all other values for Y, but never trumps X as primary sort. Can't you just have U be the largest unsigned integer value of the type you choose? For this particular application, I doubt there's any risk of the defined numbers catching up with it. I might have missed something though. This seems a bit too trivial for you to ask for help. -- Andreas Ericsson andreas.erics...@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. -- 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/Mac refuses to install on OS X 10.8 (Mountain Lion)
On 04/07/2013 03:55 AM, David Foster wrote: The default security settings on OS X 10.8 (Mountain Lion) disallow the installation of unsigned packages, with no override. Git/Mac 1.8.2 is not signed and therefore will not install without changing the OS default security settings. Sounds like an OSX lockin bugture to me. If anyone can sign the package with any random key, then it wouldn't provide much in the way of security, so I guess that means one has to get a signing key form Apple, which I doubt they just hand out to anyone (usually it means paying $100 to get an apple developer certificate). That's nonsense, ofcourse, but it's how they've chosen to do business. That aside; Does the package work if you reduce the security settings, install it and then reset the security settings to their default settings later? If so, I'd call that a reasonable workaround, and we probably won't even have to document it since google should provide it for git and a plethora of other useful packages. Otoh, if enough osx folks want git on the latest pussycat, I'm sure they'll provide a package themselves sooner or later, in which case you just have to wait for that to happen. -- Andreas Ericsson andreas.erics...@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. -- 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: cd
On 04/03/2013 04:49 PM, jpinheiro wrote: Hi all, We are students from Universidade do Minho in Portugal, and we are using git in project as a case study. While experimenting with git we found an unexpected behavior with git rm. Here is a trace of the unexpected behavior: $ git init $ mkdir D $ echo Hi D/F $ git add D/F $ rm -r D $ echo Hey D $ git rm D/F warning: 'D/F': Not a directory rm 'D/F' fatal: git rm: 'D/F': Not a directory If the file D created with last echo did not exist or was named differently then no error would occur as expected. For example: $ git init $ mkdir D $ echo Hi D/F $ git add D/F $ rm -r D $ echo Hey F $ git rm D/F This works as expected, and the only difference is the name of the file of the last echo. Is this the expected behavior of git rm? Yes. The only difference between 'git rm' and 'rm' is that git rm also removes the file from its index and prepares to commit a version without it. From git's point of view, it's not an error if the file doesn't exist. It *is* an error if the directory where the file should reside suddenly no longer a directory though. -- Andreas Ericsson andreas.erics...@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. -- 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 status takes 30 seconds on Windows 7. Why?
On 03/27/2013 05:39 PM, Jim Kinsman wrote: git status takes 30 seconds on Windows 7. Here are some stats: git ls-files | wc -l 27330 git ls-files -o | wc -l 4 $ git diff --name-only | xargs du -chs 68K update_import_contacts.php 68K total What can I do??? This is so slow it is unbearable. By the way i've done git gc several times and nothing changed. I'm guessing it's the disk that's so slow. I accidentally put a git repo on a network-mounted drive once. With 20ms round-trip time to the server, git operations took forever. Could you try it on a disk you know is local? Preferrably a solid state drive. If it's still slow there, we know for sure something's broken inside git. If switching media causes git to become fast, you'll know it's a hardware problem. -- Andreas Ericsson andreas.erics...@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. -- 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: auto merge bug
On 03/05/2013 07:47 PM, Junio C Hamano wrote: Jeff King p...@peff.net writes: I'm also not sure how useful those really are in practice. I have not used union myself ever. And in the example that started this thread, I find the use of union slightly dubious. Yeah, I do not think anybody sane used union outside toy examples. I do, for lists used in tests or to generate perfect hashes from. It's really quite handy for things like that but totally useless for any type of multiline format, or even .ini style files unless you're very, very careful with how you write them. -- Andreas Ericsson andreas.erics...@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. -- 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: Certificate validation vulnerability in Git
On 02/24/2013 06:31 PM, Zubin Mithra wrote:
Hello,
There seems to be a security issue in the way git uses openssl for
certificate validation. Similar occurrences have been found and
documented in other open source projects, the research can be found at
[1].
-=]
- imap-send.c
Line 307
307 ret = SSL_connect(sock-ssl);
308 if (ret = 0) {
309 socket_perror(SSL_connect, sock, ret);
310 return -1;
311 }
312
Certificate validation errors are signaled either through return
values of SSL_connect or by setting internal flags. The internal flags
need to be checked using the SSL_get_verify_result function. This is
not performed.
Kindly fix these issues, file a CVE and credit it to Dhanesh K. and
Zubin Mithra. Thanks.
The lack of certificate authority verification presents no attack vector
for git imap-send. As such, it doesn't warrant a CVE. I'm sure you'll
be credited with a reported-by line in the commit message if someone
decides to fix it though. Personally, I'm not fussed.
We are not subscribed to this list, so we'd appreciate it if you could
CC us in the replies.
That's standard on this list. Please follow the same convention if/when
you reply. Thanks.
--
Andreas Ericsson andreas.erics...@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
--
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: Is this a bug?
On 02/19/2013 10:32 AM, David Wade wrote: Hi, I wrote a commit message beginning with a hash (#) character, like this: 'git commit -m #ifdef ' Everything went okay when committing, but then I tried 'git commit -amend' and without editing the commit message I was told I had an empty commit message. Is this a problem with my text editor (vim 7.2) or git itself? (git version 1.7.2.2 under RedHat 5.8) Or something I'm not supposed to do ;-) ? Lines starting with a hash sign are considered comments by git commit. If you fire it up without '-m' you'll see that git puts all its own notes about the commit in commented-out lines. While empty commit messages aren't really unacceptable by git's model, they're considered almost certainly user errors. I expect the -m flag being present when running 'git commit' causes the check for empty message to be skipped, which isn't the case when amending the commit. Btw, when I write messages probably similar to the one you just did, I tend to write: Use compat-layer __builtin_clz() #ifndef __GNUC__ precisely to avoid this issue. It also puts the imperative first, which I find makes for smoother reading. Putting the condition first screams for a comma and a slight stagger in reading flow, like so: Unless built with gcc, use compat-layer __builtin_clz() -- Andreas Ericsson andreas.erics...@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. -- 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 branch case insensitivity (Possible bug)
On 01/09/2013 04:46 PM, Alexander Gallego wrote: Hello, Here is a pastebin where I've reproduced the steps on a clean git repo. http://pastebin.com/0vQZEat0 Brief description of the problem: 1.Basically one creates a local branch call it 'imp_fix' (branch off master -- this doesn't matter) 2.One does work, commit, etc 3.One rebases imp_fix with master via: (inside imp_fix) git rebase master 4.One checks out master via: git checkout master 5.One merges an incorrect name imp_Fix (notice the capital F) 6.The expected output is that git would say, silly you -- that branch does not exist. 7. Instead it merges (what I think is incorrectly) imp_fix. Kindly let me know if I can provide more details. Are you using Mac OSX? Are you using the HFS+ filesystem shipped with it? Did you use the filesystem's default settings rather than reinstall your system with sensible settings? If you said yes to all of the above, this is a filesystem feature, courtesy of (cr)Apple, and you're screwed. You can work around it by running git pack-refs every time you create a branch or a tag though. -- Andreas Ericsson andreas.erics...@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. -- 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] fsck: warn about .git in trees
On 11/30/2012 08:50 PM, Torsten Bögershausen wrote: Having a .git entry inside a tree can cause confusing results on checkout. At the top-level, you could not checkout such a tree, as it would complain about overwriting the real .git directory. In a subdirectory, you might check it out, but performing operations in the subdirectory would confusingly consider the in-tree .git directory as the repository. [snip] +int has_dotgit = 0; Name like . or .. are handled as directories by the OS. The patch is for the index, where they're handled as whatever the mode claims it is. The patch doesn't touch those parts though. .git could be a file or a directory, at least in theory, and from the OS point of view, but we want to have this as a reserved name. Looking at bad directory names, which gives trouble when checking out: Should we check for / or ../blabla as well? Apart from the checks already in place, checking for git's internal directory separator marker (which is '/') is enough to catch both, and that check is done. -- Andreas Ericsson andreas.erics...@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. -- 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: Possible vulnerability to SHA-1 collisions
On 11/28/2012 01:27 AM, Jeff King wrote: On Tue, Nov 27, 2012 at 06:30:17PM -0500, Aaron Schrab wrote: At 18:07 -0500 27 Nov 2012, Jeff King p...@peff.net wrote: PS I also think the OP's sockpuppet creates innocuous bugfix above is easier said than done. We do not have SHA-1 collisions yet, but if the md5 attacks are any indication, the innocuous file will not be completely clean; it will need to have some embedded binary goo that is mutated randomly during the collision process (which is why the md5 attacks were demonstrated with postscript files which _rendered_ to look good, but contained a chunk of random bytes in a spot ignored by the postscript interpreter). I don't think that really saves us though. Many formats have parts of the file which will be ignored, such as comments in source code. Agreed, it does not save us unconditionally. It just makes it harder to execute the attack. Would you take a patch from a stranger that had a kilobyte of binary garbage in a comment? A more likely avenue would be a true binary file where nobody is expected to read the diff. With the suggested type of attack, there isn't a requirement about which version of the file is modified. So the attacker should be able to generate a version of a file with an innocuous change, get the SHA-1 for that, then add garbage comments to their malicious version of the file to try to get the same SHA-1. That's not how birthday collision attacks usually work, though. You do not get to just mutate the malicious side and leave the innocuous side untouched. You are mutating both sides over and over and hoping to find a matching sha1 from the good and evil sides. Of course, I have not been keeping up too closely with the efforts to break sha-1. Maybe there is something more nefarious about the current attacks. I am just going off my recollection of the md5 collision attacks. AFAIR, collision attacks can be executed with a 2^51 probability (with a 2^80 claim, that's pretty bad), but preimage attacks are still stuck very close to the claimed 2^160. That means every attack involving SHA1 means Mr. Malicious creates both the involved files or does exceptional research without sharing it. I think git's job is to make sure that write access to only one of the repositories is insufficient to launch an attack. If the attacker manages to change all repositories involved then the hash function used is really quite irrelevant. -- Andreas Ericsson andreas.erics...@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. -- 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: Millisecond precision in timestamps?
On 11/28/2012 08:29 AM, Junio C Hamano wrote: Jeff King p...@peff.net writes: There is room for new headers, and older versions of git will ignore them. You could add a new committer-timestamp field that elaborates on the timestamp included on the committer line. Newer versions of git would respect it, and older versions would fall back to using the committer timestamp. But I really wonder if anybody actually cares about adding sub-second timestamp support, or if it is merely because SVN has it. Roundtrip conversions may benefit from sub-second timestamps, but personally I think negative timestamps are more interesting and of practical use. Prehistoric projects need them even if they intend to switch to Git, never to go back to their original tarballs and collection of RCS ,v files. And if we were to add committer-timestamp and friends to support negative timestamps anyway (because older tools will not support them), supporting sub-second part might be something we want to think about at the same time. We would however need to be extra careful. How should we express half-second past Tue Nov 27 23:24:16 2012 (US/Pacific)? Would we spell it 1354087456.5? 1354087456.500? Would we require decimal representation of floating point numbers to be normalized in some way (e.g. minimum number of digits without losing precision)? The same timestamp needs to be expressed the same way, or we will end up with different commit objects, which defeats the whole purpose of introducing subsecond timestamps to support round-trip conversions. If we were to use a separate subsecond fields, another thing we need to be careful about is the order of these extra fields, exactly for the same reason. If we're going to support pre-epoch timestamps, we'll have to do that for 2.0 anyway, since we'll otherwise have two conflicting dates in the commit object. Adding support for parsing them now and start writing them in 2.0 would make sense. In that case, we'd have to print timestamps as printf(%lu.%06lu, tv.tv_sec, tv.tv_usec); I'm unsure how useful it is to support pre-epoch dates though. It's hard to find software where anyone really cares about the code from 43 years ago with anything but historical interest, and for those who take the museum road, I'm betting it's more interesting to see how people worked back then than it is to see what they wrote. Aside from that, it would be trivial to support museum style history viewing with a special flag that treats the timestamps as minutes since 1900-01-01 or some such, giving us plenty of time before even the first punch-card was invented. It wouldn't be much harder to let the user specify the timeunit and the start-point either, and then we could store the history of carbon-based lifeforms on earth in git. -- Andreas Ericsson andreas.erics...@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. -- 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: Millisecond precision in timestamps?
On 11/28/2012 09:04 AM, David Aguilar wrote: On Tue, Nov 27, 2012 at 11:58 PM, Eric S. Raymond e...@thyrsus.com wrote: Junio C Hamano gits...@pobox.com: Roundtrip conversions may benefit from sub-second timestamps, but personally I think negative timestamps are more interesting and of practical use. You mean, as in times before the Unix epoch 1970-01-01T00:00:00Z? Interesting. I hadn't thought of that. I've never seen a software project under version control with bits that old, which is significant because I've probably done more digging into ancient software than anybody other than a specialist historian or two. One example I've heard is someone wanting to throw the history of a country's laws into git so they can diff them. That'll get tricky if you try it in Sweden. Our oldest written law dates back to 1281. Quite fun reading. Apparently it was against the law to shoot your slaves with stone arrows back then. See my other proposal for how this could be done, which would only affect the output layer (and some care would have to be taken with the input, naturally). -- Andreas Ericsson andreas.erics...@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. -- 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 11:44 PM, Eric S. Raymond wrote: Felipe Contreras felipe.contre...@gmail.com: 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. Then you're either pretending or very naive. Three decades of experience as a C programmer tells me that C code at any volume is a *serious* maintainance problem relative to almost any language with GC. Prudent architects confine it is much as possible. Prudent architects also avoid rewrites as much as possible, since it's inevitable that bugs will be introduced that have been fixed in the official version. Personally, I think if you'd left your suggestion on It would be great to have guidelines for python scripts. I propose 2.6 as the minimum required python verison and left it at that, there would have been very little disagreement. The suggestion that things should be rewritten in python for some spurious long-term savings seems mostly designed to refuel everyone's favourite flamethrower, and you know as well as I do that it just won't happen unless there's at least a chance of some substantial technical benefits from doing so. -- Andreas Ericsson andreas.erics...@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. -- 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: Failure to extra sta...@vger.kernel.org addresses
On 11/20/2012 11:28 AM, Felipe Contreras wrote:
On Tue, Nov 20, 2012 at 8:56 AM, Krzysztof Mazur krzys...@podlesie.net
wrote:
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -925,8 +925,11 @@ sub quote_subject {
sub sanitize_address {
my ($recipient) = @_;
+ my $local_part_regexp = qr/[^\s@]+/;
+ my $domain_regexp = qr/[^.\s@]+(?:\.[^.\s@]+)+/;
+
# remove garbage after email address
- $recipient =~ s/(.*).*$/$1/;
+ $recipient =~ s/^(.*?$local_part_regexp\@$domain_regexp).*/$1/;
I don't think all that extra complexity is warranted, to me
s/(.*?)(.*)$/$1/ is just fine.
It's intentionally left without the at-sign so one can send mail to a
local account as well as remote ones. Very nifty when debugging, and
when one wants to preview outgoing emails.
--
Andreas Ericsson andreas.erics...@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
--
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: Lack of netiquette, was Re: [PATCH v4 00/13] New remote-hg helper
On 11/01/2012 02:46 PM, René Scharfe wrote: Also, and I'm sure you didn't know that, Jedem das Seine (to each his own) was the slogan of the Buchenwald concentration camp. For that reason some (including me) hear the unspoken cynical half-sentence and some people just have to be sent to the gas chamber when someone uses this proverb. It goes further back than that. Suum cuique pulchrum est (To each his own is a beautiful thing) is a latin phrase said to be used frequently in the roman senate when senators politely agreed to disagree and let a vote decide the outcome rather than debating further. Please don't let the twisted views of whatever nazi idiot thought it meant you may have the wrong faith and therefore deserve to die, so you shall pollute it. The original meaning is both poetic and democratic, and I firmly believe most people have the original meaning to the fore of their mind when using it. After all, very few people knowingly quote nazi concentration camp slogans. -- Andreas Ericsson andreas.erics...@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. -- 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: Who is the 'git' vendor?
On 10/25/2012 08:43 AM, PROHASKA, Thor wrote: Hi, The organisation I am currently working for uses 'git'. In order to manage all the software used in the organisation we have been compiling a list of software that includes the software Vendor's name. My colleague has listed the vendor of git as being the 'Software Freedom Conservancy'. Can you please advise me if this is correct? If not, who should the vendor be identified as? Most likely, you'll want to put git@vger.kernel.org as vendor for git, as the whole vendor concept doesn't really fly with FOSS. There's noone to go to if it breaks your systems, and unless you purchase a support contract from somewhere there's noone to turn to except the (excellent) git community in case you have issues with it. -- Andreas Ericsson andreas.erics...@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. -- 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: libgit2 status
On 10/19/2012 10:13 PM, Junio C Hamano wrote: Ramkumar Ramachandra artag...@gmail.com writes: Thiago Farina wrote: [...] With some structure like: include/git.h src/git.c ... whatever. [...] Junio- is it reasonable to expect the directory-restructuring by 2.0? I actually hate include/git.h vs src/git.c; you have distinction between .c and .h already. Agreed. The way libgit2 does it is to have src/tag.[ch], which are for internal use, and then src/include/tag.h which is the published version that others can use to write code against the tag library. src/tag.h always includes src/include/tag.h, so no code needs to be duplicated, but internal parts of the library can still use lower- level stuff if it wants to. It's a good compromise when creating a library from application code and there were no opaque types from the start. -- Andreas Ericsson andreas.erics...@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. -- 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: Is anyone working on a next-gen Git protocol?
On 10/07/2012 09:57 PM, Ævar Arnfjörð Bjarmason wrote: On Wed, Oct 3, 2012 at 9:13 PM, Junio C Hamano gits...@pobox.com wrote: Ævar Arnfjörð Bjarmason ava...@gmail.com writes: I'm creating a system where a lot of remotes constantly fetch from a central repository for deployment purposes, but I've noticed that even with a remote.$name.fetch configuration to only get certain refs a git fetch will still call git-upload pack which will provide a list of all references. It has been observed that the sender has to advertise megabytes of refs because it has to speak first before knowing what the receiver wants, even when the receiver is interested in getting updates from only one of them, or worse yet, when the receiver is only trying to peek the ref it is interested has been updated. Has anyone started working on a next-gen Git protocol as a result of this discussion? If not I thought I'd give it a shot if/when I have time. The current protocol is basically (S = Server, C = Client) S: Spew out first ref S: Advertisement of capabilities S: Dump of all our refs C/S: Declare wanted refs, negotiate with server S: Send pack to client, if needed And I thought I'd basically turn it into: C: Connect to server, declare what protocol we understand C: Advertisement of capabilities S: Advertisement of capabilities C/S: Negotiate what we want C/S: Same as v1, without the advertisement of capabilities, and maybe don't dump refs at all Basically future-proofing it by having the client say what it supports to begin with along with what it can handle (like in HTTP). Then in the negotiation phase the client server would go back forth about what they want how they want it. I'd planned to implement something like: C: want_refs refs/heads/* S: OK to that C: want_refs refs/tags/* S: OK to that Or: C: want_refs refs/heads/master S: OK to that C: want_refs refs/tags/v* S: OK to that You'll want that to be a single wants message to avoid incurring insane amounts of roundtrip latency with lots of refs. github and other hosted services are quite popular, but with my 120ms ping rtt I'd be spending half a minute just telling the other side what I want when I fetch from a repo with 250 refs. It's a flagday and a half to change the protocol though, so I expect it'll have to wait for 2.0, unless the current client-side part of it is dumb and ignores existing refs when requesting its wants, in which case the server can just stop advertising existing refs and most of the speedup is already done. -- Andreas Ericsson andreas.erics...@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. -- 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: inconsistent behavior on mac with case changes
On 09/14/2012 02:37 PM, Larry Martell wrote: On Thu, Sep 13, 2012 at 5:24 PM, Larry Martell larry.mart...@gmail.com wrote: I created a dir on my Mac called Rollup, and pushed it out. Then went to a CentOS box, pulled it, and realized I wanted to call it RollUp (capital U). I renamed it, and pushed out the change. Went back to the Mac and did a pull - it said it created the RollUp dir, but it did not - it was still called Rollup. I reamed it, but status did not pick up the change. Then I checked out a branch that had Rollup, but it was gone there - no Rollup or RollUp. I did a merge and then RollUp was created. I know the Mac is somewhat inconsistent with how it deals with case, e.g.: $ ls RollUp $ ls -d Rollup Rollup $ ls -d RollUp RollUp $ find . -name Rollup -print $ find . -name RollUp -print ./RollUp So I guess I can understand git also being inconsistent there. But what really got me was the dir being gone on the branch. Is all this expected behavior? More or less. Git sees Rollup and RollUp as two different directories, so assuming everything inside it is committed git is free to remove the directory that exists on one branch but not the other when switching branches in order to keep the work tree in sync with the index. Consider this (most output cut away): git init touch base; git add base git commit -m first commit mkdir foo touch foo/lala git add foo/lala git commit -m meh git checkout -b newbranch HEAD^ ls -ld foo ls: cannot access foo.: No such file or directory mkdir bar touch bar/bear git add bar/bear git commit -m rawr git checkout master ls -ld bar ls: cannot access bar.: no such file or directory If git would leave your committed directory in the worktree when you move to a branch that doesn't have it, it would put you in a very weird position where you may have to clear away rubble from someone else, or start depending on code that's not in your branch. So yes, you're seeing the expected behaviour, and OSX is retarded wrt case sensitive filenames. I'd suggest you either reformat your drive to stop using HFS+ or do your development work inside a loopback fs mounted with proper case sensitivity, as there's really no sane way around the problem OSX causes. Is this not the correct list for a question like this? If not, is there another list that's more appropriate? It is, but people don't always spend their days looking for questions to answer. -- Andreas Ericsson andreas.erics...@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. -- 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] git-am: Handle git show output correctly
On 09/13/2012 12:19 AM, Junio C Hamano wrote: Dan Johnson computerdr...@gmail.com writes: Not really. If we start encouraging people to use git show output as a kosher input to am, we would have to support such use forever, and we end up painting ourselves in a corner we cannot get out of easily. If git am emitted a warning when accepting git show output, it seems like it would support Peter's use-case without encouraging bad behavior? Are you seriously suggesting me to sell to our users a new feature saying this does not work reliably, we would not recommend using it, no, really, don't trust it. from the day the feature is introduced, especially when we know it will not be the feature does not work well yet, but it will, we promise but is and it may become worse in the future? I do not see much point in doing that. Besides, what bad behaviour do we avoid from encouraging with such an approach? As Peter said, the problem is not on the part of the user who ended up with an output from git show, when he really wants output from git format-patch. Giving the warning to the user of git am is too late. It might be enough to either enable format-patch output or print a warning to stderr when stdout is not a tty. I believe that would at least mitigate the problem, and it might educate the user as well. We already modify output format when stdout is not a tty (removing colors), so we're not giving guarantees about its format when it's piped somewhere. I believe that would provide almost every scenario with the expected outcome (including 'git show | grep'), but there will be a handful of very surprised people as well. -- Andreas Ericsson andreas.erics...@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] Add a function string_list_longest_prefix()
On 09/10/2012 06:33 PM, Jeff King wrote: On Mon, Sep 10, 2012 at 09:24:17AM -0700, Junio C Hamano wrote: While we're on the subject, it seems to me that documenting APIs like these in separate files under Documentation/technical rather than in the header files themselves - makes the documentation for a particular function harder to find, - makes it easier for the documentation to get out of sync with the actual collection of functions (e.g., the 5 undocumented functions listed above). - makes it awkward for the documentation to refer to particular function parameters by name. While it is nice to have a high-level prose description of an API, I am often frustrated by the lack of docstrings in the header file where a function is declared. The high-level description of an API could be put at the top of the header file. Also, better documentation in header files could enable the automatic generation of API docs (e.g., via doxygen). Yeah, perhaps you may want to look into doing an automated generation of Documentation/technical/api-*.txt files out of the headers. I was just documenting something in technical/api-* the other day, and had the same feeling. I'd be very happy if we moved to some kind of literate-programming system. I have no idea which ones are good or bad, though. I have used doxygen, but all I remember is it being painfully baroque. I'd much rather have something simple and lightweight, with an easy markup format. For example, this: http://tomdoc.org/ Looks much nicer to me than most doxygen I've seen. But again, it's been a while, so maybe doxygen is nicer than I remember. Doxygen has a the very nifty feature of being able to generate callgraphs though. We use it extensively at $dayjob, so if you need a hand building something sensible out of git's headers, I'd be happy to help. libgit2 uses doxygen btw, and has done since the start. If we ever merge the two, it would be neat to use the same. -- Andreas Ericsson andreas.erics...@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. -- 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: Using doxygen (or something similar) to generate API docs [was [PATCH 4/4] Add a function string_list_longest_prefix()]
On 09/10/2012 11:56 PM, Jeff King wrote: On Mon, Sep 10, 2012 at 09:21:12PM +0200, Michael Haggerty wrote: I'm renaming this thread so that the bikeshedding can get over ASAP. Thanks. :) http://tomdoc.org/ Looks much nicer to me than most doxygen I've seen. But again, it's been a while, so maybe doxygen is nicer than I remember. I don't have a personal preference for what system is used. I mentioned doxygen only because it seems to be a well-known example. From a glance at the URL you mentioned, it looks like TomDoc is only applicable to Ruby code. Yeah, sorry, I should have been more clear; tomdoc is not an option because it doesn't do C. But what I like about it is the more natural markup syntax. I was wondering if there were other similar solutions. Looks like NaturalDocs is one: http://www.naturaldocs.org/documenting.html On the other hand, doxygen is well-known among open source folks, which counts for something. And from what I've read, recent versions support Markdown, but I'm not sure of the details. So maybe it is a lot better than I remember. Markdown is supported, yes. There aren't really any details to it. I don't particularly like markdown, but my colleagues tend to use it for howto's and whatnot and it can be mixed with other doxygen styles without problem. Doxygen has a the very nifty feature of being able to generate callgraphs though. We use it extensively at $dayjob, so if you need a hand building something sensible out of git's headers, I'd be happy to help. It has been over a decade since I seriously used doxygen for anything, and then it was a medium-sized project. So take my opinion with a grain of salt. But I remember the callgraph feature being one of those things that _sounded_ really cool, but in practice was not all that useful. It's like all tools; Once you're used to it, it's immensely useful. I tend to prefer using it to find either code in dire need of refactoring (where the graph is too large), or engines and exit points. For those purposes, it's pretty hard to beat a good callgraph. My plate is full. If you are able to work on this, it would be awesome. As far as I'm concerned, you are the new literate documentation czar :-) Lucky me? :) I think he was talking to me, but since you seem to have volunteered... ;) I think I'll leave it for the moment, and next time I start to add some api-level documentation I'll take a look at doxygen-ating them and see how I like it. And I'd invite anyone else to do the same (in doxygen, or whatever system you like -- the best way to evaluate a tool like this is to see how your real work would look). That's one of the problems. People follow what's already there, and there are no comments there now so there won't be any added in the future :-/ -- Andreas Ericsson andreas.erics...@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. -- 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: libgit2 status
On 08/24/2012 04:02 PM, gree...@obbligato.org wrote: What is the status of libgit2 WRT the overall git project? I recall that there was some discussion of basing bits of git on libgit2 once it matures. I ask because I'm starting a project to improve the abysmal speed of git-subtree split. It's unbearably slow at the moment and as far as I can puzzle out it's due almost entirely to repeated subshell invocations to run git commands. I was planning on doing some experiments rewriting bits of git-subtree using libgit2 but I want to make sure that that isn't wasted work. It appears to be exactly what I need to code bits of git-subtree natively. Thoughts? libgit2 is now maintained by Vicent Marti, who was once a gsoc student. He's employed by github and seems to spend most of his time working on libgit2. Politically, I'm not sure how keen the git community is on handing over control to the core stuff of git to a commercial entity, but it doesn't seem to be a dying project, so I'd say go ahead and do it. -- Andreas Ericsson andreas.erics...@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. -- 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 on HP NonStop
On 08/22/2012 06:38 PM, Joachim Schmitz wrote: -Original Message- From: Junio C Hamano [mailto:gits...@pobox.com] Sent: Tuesday, August 21, 2012 4:06 AM To: Joachim Schmitz Cc: 'Johannes Sixt'; 'Jan Engelhardt'; git@vger.kernel.org Subject: Re: git on HP NonStop Joachim Schmitz j...@schmitz-digital.de writes: OK, so let's have a look at code, current git, builtin/cat-file.c, line 196: void *contents = contents; This variable is set later in an if branch (if (print_contents == BATCH), but not in the else branch. It is later used always under the same condition as the one under which it is set. Apparently is is malloc_d storage (there a free(content);), so there's no harm al all in initializing it with NULL, even if it only appeases a stupid compiler. It actually is harmful. See below. Harmful to initialize with NULL or to use that undefined behavoir? I checked what our compiler does here: after having warned about vlues us used before it is set: it actually dies seem to have initializes the value to 0 resp. NULL. So here there's no harm done in avoiding undefined behavior and set it to 0 resp NULL in the first place. There is harm in tricking future programmers into thinking that the initialization actually means something, which some of them do. It's unlikely that you're the one to maintain that code forever, and the var = var idiom is used widely within git with a clear meaning as a hint to programmers who read a bit of git code. If they aren't used to that idiom, they usually investigate it in the code and pretty quickly realize that what it means. -- Andreas Ericsson andreas.erics...@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. -- 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 am and the wrong chunk of ---
On 08/10/2012 12:36 PM, Jeff King wrote: On Thu, Aug 09, 2012 at 05:13:51PM -0700, H. Peter Anvin wrote: I have some contributors who consistently put their commentary *before* the --- line rather than *after* it, presumably with the notion that it is some kind of cover text. This messes with git am, and so I end up having to edit those posts manually. I have tried git am --scissors and it doesn't seem to solve the problem. Is there any other option which can be used to automatically process such a patch? If I understand your issue, somebody is writing: From: them To: you Date: ... Subject: [PATCH] subject line commit message body some cover letter material that should go below the --- --- [diffstat + diff] How do you know when the commit message body ends, and the cover letter begins? We already have two machine-readable formats for separating the two (--- after the commit message, and -- 8 -- scissors before). Is there some machine-readable hint? Is it always the paragraph before the ---? Chopping that off unconditionally seems like a dangerous heuristic. End of SOB lines might be a good cutoff, if they're present. I've never seen anyone put commit message text below them anyway. -- Andreas Ericsson andreas.erics...@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. -- 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
