Complete audit trail for embedded (Linux) system lifecycle with Git
Hello, We are to solve a complete audit trail solution for full subcontractor value-chain fullfilling European Union machinery directive: http://ec.europa.eu/enterprise/sectors/mechanical/machinery/ To summarize, the directive is created to ensure safe operating environment for all kind of machinery devices (from industrial machinery to consumer shopping-centre lifts/elevators). This also includes the embedded software that controls the machinery (which is as we know, the make-or-break the true safety of the device). The solution is based on the very core Git functionality, in very brief overview explained here: http://abstractiondev.wordpress.com/git-based-distribution/ As Git is completely file-system based, in our solution it is used as the core technology to audit ANY digital document or information. It is serving as a distributed set of master data repositories, including the digital signature repositories and 3rd party validation stacks. In the validation chains it is critical to be able to support responsible decision makers to approve design choises beyond the software, thus the digital signature infrastructure for any legal-binding document is as important as the actual embedded software stack, that is by its nature version controlled within Git as well. While I would hope this post to serve a purpose for demonstrating that Git works as a perfect solution in the core, I'd also like to hear if there is already established community/ongoing process of achieving anything described above? We have no intention of reinventing the wheel here, although being very core solution for ANY audit trail and being so close based on Git - bare functionality, I'm expecting any existing solution to share much of similar design. Any existing tooling to support the solution (especially dynamic cross-connected metadata repository searches - the bottom image of the overview, that indexes the repositories together) would be very welcome. The current technical solution is using GnuPG for the digital signatures and open-source cross platform XML-database for metadata indexing - grid databases being considered for the larger implementations. Any comments and/or feedback would be greatly appreciated. Cheers, Kalle Launiala -- 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: (Ab)using filter-branch from a post-receive hook
On Jul 14, 2012, at 11:44 PM, Junio C Hamano wrote: Wincent Colaiuta w...@wincent.com writes: On Jul 14, 2012, at 10:25 PM, Junio C Hamano wrote: I did not see anything wrong doing what you described in the post-receive, even though having the hook in the scratch felt strange, as the copying from authoritative would also want to be automated and the natural triggering mechanism to do so would be a post-receive there. What issues were you worried about? The part that I left out, to keep things simple, is that ... I said strange, not wrong. If it is undesirable to hook the authoritative repository, it is perfectly fine to hook on the receiving end. So what issues were you worried about? I guess I was just a little worried about using filter-branch in a completely automated context (I have used it previously, but always in a manual fashion to do explicit surgery on the history), so I really just wanted a sanity check. Thanks for your input; it's much appreciated. We have a strict fast-forward-only policy on our master branch, so I think the hook will be quite simple to write and won't require us to handle any crazy edge cases. Cheers, Wincent -- 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: t1450-fsck (sometimes/often) failes on Mac OS X
On Sat, Jul 14, 2012 at 02:21:35PM +0200, Torsten Bögershausen wrote: I saw the problem first on pu, some time ago, but it dissappeared after cloning git.git into another directory. Now it appeared on next as well, so it's time to look a little bit deeper. This test case of t1450 fails: test_expect_success 'tag pointing to something else than its type' ' I can't reproduce this failure; I tried both pu or next, on Linux and OS X (10.7). Linux: error: Object 63499e4ea8e096b831515ceb1d5a7593e4d87ae5 is a blob, not a commit error in tag 66f6581d549f70e05ca586bc2df5c15a95662c36: broken links error in tag 66f6581d549f70e05ca586bc2df5c15a95662c36: could not load tagged object Mac OS X: error: Object 63499e4ea8e096b831515ceb1d5a7593e4d87ae5 is a commit, not a blob error: 63499e4ea8e096b831515ceb1d5a7593e4d87ae5: object corrupt or missing That seems very broken. That sha1 can have only one type, so OS X is actually mis-parsing the object type? Weird. I would suggest a memory error or race condition, but the test is valgrind-clean, and fsck should not be threaded at all. What does git show 63499e4 show when the test has failed? If you re-run git fsck --tags, does it reproduce reliably (i.e., is it bogus data that something wrote to the object db, or is it good data being ruined during the reading process)? I reverted the last change in fsck.c (Use the streaming interface), but that doesn't help Looking into the trash directory and looking at the files, we can see that the .git/index is different between Linux and Mac OS X. Is there a good way to debug the index file? git ls-files -s will dump the entries. But I'd expect them not to be byte-equivalent, because the index will contain things like mtimes for each entry, which will vary from run to run. Plus the error message above indicates something much more broken. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: t1450-fsck (sometimes/often) failes on Mac OS X
Peff, thanks for looking into this. My answers are inline and at the end. On 15.07.12 11:08, Jeff King wrote: On Sat, Jul 14, 2012 at 02:21:35PM +0200, Torsten Bögershausen wrote: I saw the problem first on pu, some time ago, but it dissappeared after cloning git.git into another directory. Now it appeared on next as well, so it's time to look a little bit deeper. This test case of t1450 fails: test_expect_success 'tag pointing to something else than its type' ' I can't reproduce this failure; I tried both pu or next, on Linux and OS X (10.7). Linux: error: Object 63499e4ea8e096b831515ceb1d5a7593e4d87ae5 is a blob, not a commit error in tag 66f6581d549f70e05ca586bc2df5c15a95662c36: broken links error in tag 66f6581d549f70e05ca586bc2df5c15a95662c36: could not load tagged object Mac OS X: error: Object 63499e4ea8e096b831515ceb1d5a7593e4d87ae5 is a commit, not a blob error: 63499e4ea8e096b831515ceb1d5a7593e4d87ae5: object corrupt or missing That seems very broken. That sha1 can have only one type, so OS X is actually mis-parsing the object type? Weird. I would suggest a memory error or race condition, but the test is valgrind-clean, and fsck should not be threaded at all. What does git show 63499e4 show when the test has failed? ../../git show 63499e4 blob If you re-run git fsck --tags, does it reproduce reliably (i.e., is it bogus data that something wrote to the object db, or is it good data being ruined during the reading process)? ../../git fsck --tags Checking object directories: 100% (256/256), done. error: Object 63499e4ea8e096b831515ceb1d5a7593e4d87ae5 is a blob, not a commit error in tag 66f6581d549f70e05ca586bc2df5c15a95662c36: broken links error in tag 66f6581d549f70e05ca586bc2df5c15a95662c36: could not load tagged object broken link from tag 66f6581d549f70e05ca586bc2df5c15a95662c36 broken link from unknown unknown dangling blob 63499e4ea8e096b831515ceb1d5a7593e4d87ae5 I reverted the last change in fsck.c (Use the streaming interface), but that doesn't help Looking into the trash directory and looking at the files, we can see that the .git/index is different between Linux and Mac OS X. Is there a good way to debug the index file? git ls-files -s will dump the entries. But I'd expect them not to be byte-equivalent, because the index will contain things like mtimes for each entry, which will vary from run to run. Plus the error message above indicates something much more broken. ../../git ls-files -s 100644 5626abf0f72e58d7a153368ba57db4c673c0e171 0 fileA 100644 f719efd430d52bcfc8566a43b2eb655688d38871 0 fileB I did some bisecting, and it didn't lead to a bad commit. The problem goes away after another clone into a fresh directory. Once it comes up, it seems to stay within that working tree. Or it has something to do with the uptime of the machine (?) Checking out v1.7.10 seems to make the problem go away, and stepping up to e.g. commit d30ef5144cee3e9ed01a2a3f3b96d47c5322b20d Merge branch 'jc/sha1-name-more' into next brings the failure back. This is probably not related to this very 2 commits, so may be a reverse bisect would help, (When does the problem go away?) Thanks for helping /Torsten -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Implementing authenticated Smart HTTP - which URLs to secure
Howdy! I'd like to implement HTTP authentication for Git Smart HTTP using Dulwich (a Python binding): 1) read-only if unauthenticated and write only if authenticated 2) read/write only if authenticated I couldn't find any documentation on which URLs need be secured and what response codes are expected in case the cloner/pusher is unauthenticated. Is there any documentation on Smart HTTP workflow? The C sources (vanilla Git and libgit2) didn't help me too much since I found it very difficult to follow the code-flow... it's probably just abstracted too well :-) Thanks! Jonas -- 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 overwritten remote ref on with fast-import.
After importing new commits on top of refs/remotes/* the
ref was overwritten with the local refs/heads/master, because the name
of the remote reference to fetch, i.e. refs/heads/master, was used to
retrieve old_sha1 for it's local counterpart. Therefore, old_sha1 pointed
to the local head which was not contained in the remote branch and couldn't
be updated (printing a warning ..).
There are some points that are still not completely clear to me:
- I found, that the remote ref I need is stored in ref-peer_ref. There
is one little comment on peer_ref saying /* when renaming */. That doesn't
say much
to me. Is peer_ref the correct solution?
- fast-import's commit command does already add a commit to a branch. The
remote ref was already correct, but got overwritten by store_updated_refs
after fast import terminated. (I figured that out using strace).
So the update is somewhat redundant. But probably only in this special
case.(?)
Signed-off-by: Florian Achleitner florian.achleitner.2.6...@gmail.com
---
transport-helper.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/transport-helper.c b/transport-helper.c
index d6daad5..a0f05ce 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -485,8 +485,10 @@ static int fetch_with_import(struct transport *transport,
continue;
if (data-refspecs)
private = apply_refspecs(data-refspecs,
data-refspec_nr, posn-name);
+ else if (posn-peer_ref)
+ private = xstrdup(posn-peer_ref-name);
else
- private = xstrdup(posn-name);
+ private = NULL;
if (private) {
read_ref(private, posn-old_sha1);
free(private);
--
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: Support of '^' as alias for 'HEAD^'
Am 15.07.2012 00:24, schrieb Zeeshan Ali (Khattak): On Sun, Jul 15, 2012 at 12:26 AM, Junio C Hamanogits...@pobox.com wrote: Zeeshan Ali (Khattak)zeesha...@gnome.org writes: What about '^' and '^^' that I suggested? If you want a shortcut, you might try this: echo ref: HEAD .git/h Then you can use 'h' instead of 'HEAD'. Tested it and it seemed to work. If not someone on this list surely will correct me. -- 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] fast-import: catch deletion of non-existent file in input
Hi, Jeff King wrote: Subject: fast-import: catch deletion of non-existent file in input [...] We silently ignored the bogus D foo directive, and the resulting tree incorrectly contained bar. With this patch, we notice the bogus input and die. This breaks svn-fe, which relies on the existing semantics when asked to copy an empty directory. That's my fault because we never check that in the testsuite, but I also wouldn't be surprised if other importers were relying on the same thing. Any API break this big without a justification along the lines We can be confident that no existing importer uses this construct because ... _needs_ to be guarded by a new feature to be safe for existing importers. Let's repeat that for emphasis: API breaks in fast-import not guarded with a new feature type are not ok. Sorry, Jonathan -- 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: Implementing authenticated Smart HTTP - which URLs to secure
On Sun, Jul 15, 2012 at 6:43 AM, Jonas H. jo...@lophus.org wrote: I'd like to implement HTTP authentication for Git Smart HTTP using Dulwich (a Python binding): 1) read-only if unauthenticated and write only if authenticated 2) read/write only if authenticated I couldn't find any documentation on which URLs need be secured and what response codes are expected in case the cloner/pusher is unauthenticated. Smart HTTP uses HTTP authentication, so return 401 with a proper WWW-Authenticate header to prompt the client for authentication, and use the Authorization header to verify the client. Return 403 to tell the client they cannot access the service because the Authorization header is invalid[1]. You can tell check for a write request by looking at the service parameter on the /info/refs request, if its git-receive-pack, you are about to receive a write, so you want to prompt for authentication. You should also check for authentication on the /git-receive-pack request. [1] This is actually a lie. The servers I have written over the years return 200 OK with a special Git payload in this case. The payload uses the ERR in the /info/refs response to print a message to the client telling the user access is forbidden. This allows a custom message to be sent, and stops the client from discarding the message and falling back to the dumb protocol. Is there any documentation on Smart HTTP workflow? The C sources (vanilla Git and libgit2) didn't help me too much since I found it very difficult to follow the code-flow... it's probably just abstracted too well :-) There is no authentication/authorization in the server components in git-core. This is delegated to the web server that runs in front of Git, just like with the system SSH server handling authentication for Git over SSH. -- 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 maint-1.6.5 v2] block-sha1: avoid pointer conversion that violates alignment constraints
Jonathan, Thanks for acting so promptly on this. Just a minor point on the commit message below. On 15/07/2012, at 8:50 AM, Jonathan Nieder wrote: Unfortunately, Michael noticed on an Alpha machine that git was using plain 32-bit reads anyway. As soon as we convert a pointer to int *, the compiler can assume that the object pointed to is correctly aligned as an int (C99 section 6.3.2.3 pointer conversions paragraph 7), and gcc takes full advantage by converting the get_be32 calls back to a load and bswap and producing a whole bunch of unaligned access traps. Alpha does not have a bswap (or similar) instruction. I do recall reading somewhere that one can get halfway to swapping endianness by treating a number as a VAX float and converting to IEEE float, with only a couple or so more instructions to achieve the full swap. But I don't think that is available to us anyway because on Debian we compile for generic Alpha. I suspect that the crux of the matter is that compiling for generic Alpha also means that byte access instructions are not permitted. In other words, all memory accesses must be long words (32bits) or quad words (64bits). In the get_be32 routine the compiler _has_ to issue 32bit memory accesses whether the base pointer is char * or int *. If the pointer is unaligned then two neighbouring aligned 32bit loads are required to ensure that all four bytes are loaded. If the pointer is aligned then a single 32bit load gets all the four bytes. Having never looked at the generated assembler code, I nevertheless suspect that is the guts of the optimisation --- the compiler can eliminate an access to memory if it knows the pointer is aligned. Cheers Michael. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Add a new email notification script to contrib
On 07/15/2012 09:11 AM, Junio C Hamano wrote: mhag...@alum.mit.edu writes: Add a new Python script, contrib/hooks/post-receive-multimail.py, that can be used to send notification emails describing pushes into a git repository. This script is derived from contrib/hooks/post-receive-mail, but has many differences, including: The new script (I didn't read it at all) may be useful to some people, but I'm fairly negative on adding 47 different I know there is something in contrib/, I looked at it, but I didn't bother updating it to fill my needs and wrote a new one instead at this point to my tree. I understand your concern. It is a different matter if the patch was to replace the existing one, saying the users of the old script can use this one, which is backward compatible with respect to the external interface such as command line, or configuration variables used. Instead of a total backward compatibility, here is a script to migrate the existing set of configuration variables so that users of the old script can run it once, and start using this new one is also perfectly fine. Such an enhancement, especially if the rewritten result is cleaner and easier to enhance going forward than the original, would be very much appreciated. I didn't originally put the new script forward as a replacement for the old one mainly because it seems that Python is relatively unwelcome in the git project. But if the use of Python doesn't disqualify it, then yes, I think the new script (with a little more work) will be a worthy replacement for the old shell script. The new script is already mostly compatible with the old one: * It accepts the same command-line arguments and uses most of the same configuration variables. * It is possible to configure the new script to send only the refchange summary emails and skip sending the emails for individual commits, though I would want to put some work into supporting this mode better. * I tested the earliest versions of the new script by verifying that its output was identical to that of the shell script. (Of course the output is no longer identical; I claim that it is now better :-) .) So I think it would be quite possible to touch up the new script to make it a drop-in replacement for the old one, and I am willing to do so. If I understand correctly that there is a non-negligible chance of this happening, then I will continue working towards that goal. Michael -- 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] fast-import: catch deletion of non-existent file in input
On Sun, Jul 15, 2012 at 01:11:51PM -0500, Jonathan Nieder wrote: Subject: fast-import: catch deletion of non-existent file in input [...] We silently ignored the bogus D foo directive, and the resulting tree incorrectly contained bar. With this patch, we notice the bogus input and die. This breaks svn-fe, which relies on the existing semantics when asked to copy an empty directory. Thanks for the report. I had a worry while writing this that somebody was relying on the behavior. Let's just drop it, then. It's nice to catch errors in exporters, but not at the expense of compatibility issues. We could introduce a new feature bit, but I'm not sure it is really worthwhile. The older versions of bzr-fast-export would not set the bit anyway, and newer versions are already fixed, so it is kind of closing the barn door after the horse has left (we might catch other bugs, but this one is kind of oddly specific; if somebody wanted to audit fast-import for other similar cases and introduce a strict feature bit, that might be worthwhile. But for this single change, I don't think so). Let's repeat that for emphasis: API breaks in fast-import not guarded with a new feature type are not ok. Totally agree. The question in my mind was whether this was a bug fix or an API change, and it sounds like it is too far towards the latter. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix overwritten remote ref on with fast-import.
Hi Florian, Florian Achleitner wrote: After importing new commits on top of refs/remotes/* the ref was overwritten with the local refs/heads/master, because the name of the remote reference to fetch, i.e. refs/heads/master, was used to retrieve old_sha1 for it's local counterpart. Therefore, old_sha1 pointed to the local head which was not contained in the remote branch and couldn't be updated (printing a warning ..). I assume you are talking about the status quo here. It's easy to forget that others have not already applied your patch, but using the present tense would make reading easier. Think of the patch description as a special kind of bug report. Unfortunately, as a bug report, the above is lacking some detail. Do I understand correctly that some remote helper is failing when git invokes its 'import' command? What are the symptoms? If it prints a warning, what is the exact warning? Does that remote helper advertise the 'refspec' capability? If so, what refspec does it use? If not, why not? It might seem silly to ask for these things when you're providing a fix along with the report! However, if someone else runs into the same symptoms, they need to be able to find your patch quickly; if your patch has a bad side-effect then we need to know why not to revert it; and if someone new starts working on the same area of code, they need to know what bugs to avoid reintroducing. Curious, Jonathan -- 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] Fix overwritten remote ref on with fast-import.
Jonathan Nieder jrnie...@gmail.com writes: Hi Florian, Florian Achleitner wrote: After importing new commits on top of refs/remotes/* the ref was overwritten with the local refs/heads/master, because the name of the remote reference to fetch, i.e. refs/heads/master, was used to retrieve old_sha1 for it's local counterpart. Therefore, old_sha1 pointed to the local head which was not contained in the remote branch and couldn't be updated (printing a warning ..). I assume you are talking about the status quo here. It's easy to forget that others have not already applied your patch, but using the present tense would make reading easier. Think of the patch description as a special kind of bug report. Unfortunately, as a bug report, the above is lacking some detail. Do I understand correctly that some remote helper is failing when git invokes its 'import' command? What are the symptoms? If it prints a warning, what is the exact warning? Does that remote helper advertise the 'refspec' capability? If so, what refspec does it use? If not, why not? It might seem silly to ask for these things when you're providing a fix along with the report! I share the puzzlement you expressed above, and it is unclear if this is a fix or covering a user error with butchering a code that is working as intended, making two wrongs happen to collide into producing a right. At least it needs a better description of the problem it tries to fix, preferrably in the form of a new test for the transport helper. However, if someone else runs into the same symptoms, they need to be able to find your patch quickly; if your patch has a bad side-effect then we need to know why not to revert it; and if someone new starts working on the same area of code, they need to know what bugs to avoid reintroducing. That, too. 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: Bug Report - Binary Files as plain files, line endings conversions
Hi, $ git add . warning: LF will be replaced by CRLF in web/images/logo_twitter.png. The file will have its original line endings in your working directory. JOSE@COMPAQ /d/wamp/www/internationalstudies.co (master) $ git --version git version 1.7.11.msysgit.0 JOSE@COMPAQ /d/wamp/www/internationalstudies.co (master) $ cat .gitattributes # Auto detect text files and perform LF normalization * eol=crlf JOSE@COMPAQ /d/wamp/www/internationalstudies.co (master) Binary files as an image not may perform any line ending operations, many binary files will be corrupt when are restoring from repository, Saludos, José Nobile -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
What's cooking in git.git (Jul 2012, #05; Sun, 15)
Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. The sixth batch of topics are now in 'master'. You can find the changes described here in the integration branches of the repositories listed at http://git-blame.blogspot.com/p/git-public-repositories.html -- [New Topics] * sn/doc-typofix (2012-07-14) 1 commit - doc: A few minor copy edits. -- [Graduated to master] * ar/clone-honor-umask-at-top (2012-07-09) 3 commits (merged to 'next' on 2012-07-10 at 680bc22) + add: create ADD_EDIT.patch with mode 0666 + rerere: make rr-cache fanout directory honor umask + Restore umasks influence on the permissions of work tree created by clone A handful of files and directories we create had tighter than necessary permission bits when the user wanted to have group writability (e.g. by setting umask 002). * cw/amend-commit-without-message (2012-07-09) 1 commit (merged to 'next' on 2012-07-10 at e7c75d5) + Allow edit of empty message with commit --amend commit --amend used to refuse amending a commit with an empty log message, with or without --allow-empty-message. * cw/rebase-i-root (2012-07-05) 3 commits (merged to 'next' on 2012-07-05 at aeb4c56) + t3404: make test 57 work with dash and others (merged to 'next' on 2012-07-03 at 231c0a4) + Add tests for rebase -i --root without --onto + rebase -i: support --root without --onto git rebase [-i] --root $tip can now be used to rewrite all the history down to the root. * jc/apply-3way (2012-07-09) 19 commits (merged to 'next' on 2012-07-10 at fb5c872) + apply: tests for the --3way option + apply: document --3way option + apply: allow rerere() to work on --3way results + apply: register conflicted stages to the index + apply: --3way with add/add conflict + apply: move verify_index_match() higher + apply: plug the three-way merge logic in + apply: fall back on three-way merge + apply: accept -3/--3way command line option + apply: move already exists logic to check_to_create() + apply: move check_to_create_blob() closer to its sole caller + apply: further split load_preimage() + apply: refactor previous patch logic + apply: split load_preimage() helper function out + apply: factor out checkout_target() helper function + apply: refactor read_file_or_gitlink() + apply: clear_image() clears things a bit more + apply: a bit more comments on PATH_TO_BE_DELETED + apply: fix an incomplete comment in check_patch() git apply learns to wiggle the base version and perform three-way merge when a patch does not exactly apply to the version you have. * jk/index-pack-streaming-fix (2012-07-10) 1 commit (merged to 'next' on 2012-07-13 at c575338) + index-pack: loop while inflating objects in unpack_data The streaming index-pack introduced in 1.7.11 had a data corruption bug, and this should fix it. * jk/maint-commit-amend-only-no-paths (2012-07-10) 1 commit (merged to 'next' on 2012-07-10 at 1c650c2) + commit: fix --amend --only with no pathspec git commit --amend --only -- was meant to allow Clever people to rewrite the commit message without making any change even when they have already changes for the next commit added to their index, but it never worked as advertised since it was introduced in 1.3.0 era. * jk/push-delete-ref-error-message (2012-07-03) 1 commit (merged to 'next' on 2012-07-09 at 82c6bd2) + push: don't guess at qualifying remote refs on deletion The error message from git push $there :bogo mentioned we tried and failed to guess what ref is being deleted based on the LHS of the refspec, which we don't. * jn/makefile-cleanup (2012-07-09) 14 commits (merged to 'next' on 2012-07-10 at f55e6a1) + Makefile: document ground rules for target-specific dependencies + Makefile: move GIT-VERSION-FILE dependencies closer to use + Makefile: build instaweb similar to other scripts + Makefile: update scripts when build-time parameters change + Makefile: do not replace @@GIT_VERSION@@ in shell scripts + Makefile: split prefix flags from GIT-CFLAGS + Makefile: be silent when only GIT_USER_AGENT changes + Makefile: split GIT_USER_AGENT from GIT-CFLAGS + Makefile: do not replace @@GIT_USER_AGENT@@ in scripts + Makefile: apply dependencies consistently to sparse/asm targets + Makefile: do not have git.o depend on common-cmds.h + Makefile: fold XDIFF_H and VCSSVN_H into LIB_H + Makefile: fold MISC_H into LIB_H + Makefile: sort LIB_H list Tightens dependency rules to avoid unnecessary recompilation. * pw/git-p4-jobs (2012-07-05) 3 commits (merged to 'next' on 2012-07-10 at c6ef8f9) + git p4: notice Jobs lines in git commit messages + git p4 test: refactor marshal_dump + git p4: remove unused P4Submit interactive setting Teach git p4 to notice Jobs: in the log message and relay it to Perforce to trigger its
