2005-04-08 02:16:10 +04:00
|
|
|
/*
|
|
|
|
* GIT - The information manager from hell
|
|
|
|
*
|
|
|
|
* Copyright (C) Linus Torvalds, 2005
|
|
|
|
*/
|
2005-04-08 02:13:13 +04:00
|
|
|
#include "cache.h"
|
2006-04-02 16:44:09 +04:00
|
|
|
#include "commit.h"
|
|
|
|
#include "tree.h"
|
2006-05-23 16:15:33 +04:00
|
|
|
#include "builtin.h"
|
2006-12-23 00:06:08 +03:00
|
|
|
#include "utf8.h"
|
commit: teach --gpg-sign option
This uses the gpg-interface.[ch] to allow signing the commit, i.e.
$ git commit --gpg-sign -m foo
You need a passphrase to unlock the secret key for
user: "Junio C Hamano <gitster@pobox.com>"
4096-bit RSA key, ID 96AFE6CB, created 2011-10-03 (main key ID 713660A7)
[master 8457d13] foo
1 files changed, 1 insertions(+), 0 deletions(-)
The lines of GPG detached signature are placed in a new multi-line header
field, instead of tucking the signature block at the end of the commit log
message text (similar to how signed tag is done), for multiple reasons:
- The signature won't clutter output from "git log" and friends if it is
in the extra header. If we place it at the end of the log message, we
would need to teach "git log" and friends to strip the signature block
with an option.
- Teaching new versions of "git log" and "gitk" to optionally verify and
show signatures is cleaner if we structurally know where the signature
block is (instead of scanning in the commit log message).
- The signature needs to be stripped upon various commit rewriting
operations, e.g. rebase, filter-branch, etc. They all already ignore
unknown headers, but if we place signature in the log message, all of
these tools (and third-party tools) also need to learn how a signature
block would look like.
- When we added the optional encoding header, all the tools (both in tree
and third-party) that acts on the raw commit object should have been
fixed to ignore headers they do not understand, so it is not like that
new header would be more likely to break than extra text in the commit.
A commit made with the above sample sequence would look like this:
$ git cat-file commit HEAD
tree 3cd71d90e3db4136e5260ab54599791c4f883b9d
parent b87755351a47b09cb27d6913e6e0e17e6254a4d4
author Junio C Hamano <gitster@pobox.com> 1317862251 -0700
committer Junio C Hamano <gitster@pobox.com> 1317862251 -0700
gpgsig -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQIcBAABAgAGBQJOjPtrAAoJELC16IaWr+bL4TMP/RSe2Y/jYnCkds9unO5JEnfG
...
=dt98
-----END PGP SIGNATURE-----
foo
but "git log" (unless you ask for it with --pretty=raw) output is not
cluttered with the signature information.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-06 04:23:20 +04:00
|
|
|
#include "gpg-interface.h"
|
2005-04-08 02:13:13 +04:00
|
|
|
|
usage: do not insist that standard input must come from a file
The synopsys text and the usage string of subcommands that read list
of things from the standard input are often shown like this:
git gostak [--distim] < <list-of-doshes>
This is problematic in a number of ways:
* The way to use these commands is more often to feed them the
output from another command, not feed them from a file.
* Manual pages outside Git, commands that operate on the data read
from the standard input, e.g "sort", "grep", "sed", etc., are not
described with such a "< redirection-from-file" in their synopsys
text. Our doing so introduces inconsistency.
* We do not insist on where the output should go, by saying
git gostak [--distim] < <list-of-doshes> > <output>
* As it is our convention to enclose placeholders inside <braket>,
the redirection operator followed by a placeholder filename
becomes very hard to read, both in the documentation and in the
help text.
Let's clean them all up, after making sure that the documentation
clearly describes the modes that take information from the standard
input and what kind of things are expected on the input.
[jc: stole example for fmt-merge-msg from Jonathan]
Helped-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-16 21:27:42 +03:00
|
|
|
static const char commit_tree_usage[] = "git commit-tree [(-p <sha1>)...] [-S[<keyid>]] [-m <message>] [-F <file>] <sha1>";
|
2005-04-21 06:49:16 +04:00
|
|
|
|
2013-11-05 03:14:41 +04:00
|
|
|
static const char *sign_commit;
|
|
|
|
|
2008-06-27 16:24:47 +04:00
|
|
|
static void new_parent(struct commit *parent, struct commit_list **parents_p)
|
2005-06-19 21:40:10 +04:00
|
|
|
{
|
2008-06-27 16:24:47 +04:00
|
|
|
unsigned char *sha1 = parent->object.sha1;
|
|
|
|
struct commit_list *parents;
|
|
|
|
for (parents = *parents_p; parents; parents = parents->next) {
|
|
|
|
if (parents->item == parent) {
|
2005-06-19 21:40:10 +04:00
|
|
|
error("duplicate parent %s ignored", sha1_to_hex(sha1));
|
2008-06-27 16:24:47 +04:00
|
|
|
return;
|
2005-06-19 21:40:10 +04:00
|
|
|
}
|
2008-06-27 16:24:47 +04:00
|
|
|
parents_p = &parents->next;
|
2005-06-19 21:40:10 +04:00
|
|
|
}
|
2008-06-27 16:24:47 +04:00
|
|
|
commit_list_insert(parent, parents_p);
|
2005-06-19 21:40:10 +04:00
|
|
|
}
|
|
|
|
|
commit: teach --gpg-sign option
This uses the gpg-interface.[ch] to allow signing the commit, i.e.
$ git commit --gpg-sign -m foo
You need a passphrase to unlock the secret key for
user: "Junio C Hamano <gitster@pobox.com>"
4096-bit RSA key, ID 96AFE6CB, created 2011-10-03 (main key ID 713660A7)
[master 8457d13] foo
1 files changed, 1 insertions(+), 0 deletions(-)
The lines of GPG detached signature are placed in a new multi-line header
field, instead of tucking the signature block at the end of the commit log
message text (similar to how signed tag is done), for multiple reasons:
- The signature won't clutter output from "git log" and friends if it is
in the extra header. If we place it at the end of the log message, we
would need to teach "git log" and friends to strip the signature block
with an option.
- Teaching new versions of "git log" and "gitk" to optionally verify and
show signatures is cleaner if we structurally know where the signature
block is (instead of scanning in the commit log message).
- The signature needs to be stripped upon various commit rewriting
operations, e.g. rebase, filter-branch, etc. They all already ignore
unknown headers, but if we place signature in the log message, all of
these tools (and third-party tools) also need to learn how a signature
block would look like.
- When we added the optional encoding header, all the tools (both in tree
and third-party) that acts on the raw commit object should have been
fixed to ignore headers they do not understand, so it is not like that
new header would be more likely to break than extra text in the commit.
A commit made with the above sample sequence would look like this:
$ git cat-file commit HEAD
tree 3cd71d90e3db4136e5260ab54599791c4f883b9d
parent b87755351a47b09cb27d6913e6e0e17e6254a4d4
author Junio C Hamano <gitster@pobox.com> 1317862251 -0700
committer Junio C Hamano <gitster@pobox.com> 1317862251 -0700
gpgsig -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQIcBAABAgAGBQJOjPtrAAoJELC16IaWr+bL4TMP/RSe2Y/jYnCkds9unO5JEnfG
...
=dt98
-----END PGP SIGNATURE-----
foo
but "git log" (unless you ask for it with --pretty=raw) output is not
cluttered with the signature information.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-06 04:23:20 +04:00
|
|
|
static int commit_tree_config(const char *var, const char *value, void *cb)
|
|
|
|
{
|
|
|
|
int status = git_gpg_config(var, value, NULL);
|
|
|
|
if (status)
|
|
|
|
return status;
|
2013-11-05 03:14:41 +04:00
|
|
|
if (!strcmp(var, "commit.gpgsign")) {
|
|
|
|
sign_commit = git_config_bool(var, value) ? "" : NULL;
|
|
|
|
return 0;
|
|
|
|
}
|
commit: teach --gpg-sign option
This uses the gpg-interface.[ch] to allow signing the commit, i.e.
$ git commit --gpg-sign -m foo
You need a passphrase to unlock the secret key for
user: "Junio C Hamano <gitster@pobox.com>"
4096-bit RSA key, ID 96AFE6CB, created 2011-10-03 (main key ID 713660A7)
[master 8457d13] foo
1 files changed, 1 insertions(+), 0 deletions(-)
The lines of GPG detached signature are placed in a new multi-line header
field, instead of tucking the signature block at the end of the commit log
message text (similar to how signed tag is done), for multiple reasons:
- The signature won't clutter output from "git log" and friends if it is
in the extra header. If we place it at the end of the log message, we
would need to teach "git log" and friends to strip the signature block
with an option.
- Teaching new versions of "git log" and "gitk" to optionally verify and
show signatures is cleaner if we structurally know where the signature
block is (instead of scanning in the commit log message).
- The signature needs to be stripped upon various commit rewriting
operations, e.g. rebase, filter-branch, etc. They all already ignore
unknown headers, but if we place signature in the log message, all of
these tools (and third-party tools) also need to learn how a signature
block would look like.
- When we added the optional encoding header, all the tools (both in tree
and third-party) that acts on the raw commit object should have been
fixed to ignore headers they do not understand, so it is not like that
new header would be more likely to break than extra text in the commit.
A commit made with the above sample sequence would look like this:
$ git cat-file commit HEAD
tree 3cd71d90e3db4136e5260ab54599791c4f883b9d
parent b87755351a47b09cb27d6913e6e0e17e6254a4d4
author Junio C Hamano <gitster@pobox.com> 1317862251 -0700
committer Junio C Hamano <gitster@pobox.com> 1317862251 -0700
gpgsig -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQIcBAABAgAGBQJOjPtrAAoJELC16IaWr+bL4TMP/RSe2Y/jYnCkds9unO5JEnfG
...
=dt98
-----END PGP SIGNATURE-----
foo
but "git log" (unless you ask for it with --pretty=raw) output is not
cluttered with the signature information.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-06 04:23:20 +04:00
|
|
|
return git_default_config(var, value, cb);
|
|
|
|
}
|
|
|
|
|
2008-07-01 06:37:49 +04:00
|
|
|
int cmd_commit_tree(int argc, const char **argv, const char *prefix)
|
|
|
|
{
|
2011-11-09 23:33:55 +04:00
|
|
|
int i, got_tree = 0;
|
2008-07-01 06:37:49 +04:00
|
|
|
struct commit_list *parents = NULL;
|
|
|
|
unsigned char tree_sha1[20];
|
|
|
|
unsigned char commit_sha1[20];
|
|
|
|
struct strbuf buffer = STRBUF_INIT;
|
|
|
|
|
commit: teach --gpg-sign option
This uses the gpg-interface.[ch] to allow signing the commit, i.e.
$ git commit --gpg-sign -m foo
You need a passphrase to unlock the secret key for
user: "Junio C Hamano <gitster@pobox.com>"
4096-bit RSA key, ID 96AFE6CB, created 2011-10-03 (main key ID 713660A7)
[master 8457d13] foo
1 files changed, 1 insertions(+), 0 deletions(-)
The lines of GPG detached signature are placed in a new multi-line header
field, instead of tucking the signature block at the end of the commit log
message text (similar to how signed tag is done), for multiple reasons:
- The signature won't clutter output from "git log" and friends if it is
in the extra header. If we place it at the end of the log message, we
would need to teach "git log" and friends to strip the signature block
with an option.
- Teaching new versions of "git log" and "gitk" to optionally verify and
show signatures is cleaner if we structurally know where the signature
block is (instead of scanning in the commit log message).
- The signature needs to be stripped upon various commit rewriting
operations, e.g. rebase, filter-branch, etc. They all already ignore
unknown headers, but if we place signature in the log message, all of
these tools (and third-party tools) also need to learn how a signature
block would look like.
- When we added the optional encoding header, all the tools (both in tree
and third-party) that acts on the raw commit object should have been
fixed to ignore headers they do not understand, so it is not like that
new header would be more likely to break than extra text in the commit.
A commit made with the above sample sequence would look like this:
$ git cat-file commit HEAD
tree 3cd71d90e3db4136e5260ab54599791c4f883b9d
parent b87755351a47b09cb27d6913e6e0e17e6254a4d4
author Junio C Hamano <gitster@pobox.com> 1317862251 -0700
committer Junio C Hamano <gitster@pobox.com> 1317862251 -0700
gpgsig -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQIcBAABAgAGBQJOjPtrAAoJELC16IaWr+bL4TMP/RSe2Y/jYnCkds9unO5JEnfG
...
=dt98
-----END PGP SIGNATURE-----
foo
but "git log" (unless you ask for it with --pretty=raw) output is not
cluttered with the signature information.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-06 04:23:20 +04:00
|
|
|
git_config(commit_tree_config, NULL);
|
2008-07-01 06:37:49 +04:00
|
|
|
|
2009-11-09 18:04:44 +03:00
|
|
|
if (argc < 2 || !strcmp(argv[1], "-h"))
|
2008-07-01 06:37:49 +04:00
|
|
|
usage(commit_tree_usage);
|
|
|
|
|
2011-11-09 23:33:55 +04:00
|
|
|
for (i = 1; i < argc; i++) {
|
|
|
|
const char *arg = argv[i];
|
|
|
|
if (!strcmp(arg, "-p")) {
|
|
|
|
unsigned char sha1[20];
|
|
|
|
if (argc <= ++i)
|
|
|
|
usage(commit_tree_usage);
|
2012-07-03 21:03:38 +04:00
|
|
|
if (get_sha1_commit(argv[i], sha1))
|
2011-11-09 23:33:55 +04:00
|
|
|
die("Not a valid object name %s", argv[i]);
|
|
|
|
assert_sha1_type(sha1, OBJ_COMMIT);
|
|
|
|
new_parent(lookup_commit(sha1), &parents);
|
|
|
|
continue;
|
|
|
|
}
|
2008-07-01 06:37:49 +04:00
|
|
|
|
2014-12-24 03:18:11 +03:00
|
|
|
if (skip_prefix(arg, "-S", &sign_commit))
|
commit: teach --gpg-sign option
This uses the gpg-interface.[ch] to allow signing the commit, i.e.
$ git commit --gpg-sign -m foo
You need a passphrase to unlock the secret key for
user: "Junio C Hamano <gitster@pobox.com>"
4096-bit RSA key, ID 96AFE6CB, created 2011-10-03 (main key ID 713660A7)
[master 8457d13] foo
1 files changed, 1 insertions(+), 0 deletions(-)
The lines of GPG detached signature are placed in a new multi-line header
field, instead of tucking the signature block at the end of the commit log
message text (similar to how signed tag is done), for multiple reasons:
- The signature won't clutter output from "git log" and friends if it is
in the extra header. If we place it at the end of the log message, we
would need to teach "git log" and friends to strip the signature block
with an option.
- Teaching new versions of "git log" and "gitk" to optionally verify and
show signatures is cleaner if we structurally know where the signature
block is (instead of scanning in the commit log message).
- The signature needs to be stripped upon various commit rewriting
operations, e.g. rebase, filter-branch, etc. They all already ignore
unknown headers, but if we place signature in the log message, all of
these tools (and third-party tools) also need to learn how a signature
block would look like.
- When we added the optional encoding header, all the tools (both in tree
and third-party) that acts on the raw commit object should have been
fixed to ignore headers they do not understand, so it is not like that
new header would be more likely to break than extra text in the commit.
A commit made with the above sample sequence would look like this:
$ git cat-file commit HEAD
tree 3cd71d90e3db4136e5260ab54599791c4f883b9d
parent b87755351a47b09cb27d6913e6e0e17e6254a4d4
author Junio C Hamano <gitster@pobox.com> 1317862251 -0700
committer Junio C Hamano <gitster@pobox.com> 1317862251 -0700
gpgsig -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQIcBAABAgAGBQJOjPtrAAoJELC16IaWr+bL4TMP/RSe2Y/jYnCkds9unO5JEnfG
...
=dt98
-----END PGP SIGNATURE-----
foo
but "git log" (unless you ask for it with --pretty=raw) output is not
cluttered with the signature information.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-06 04:23:20 +04:00
|
|
|
continue;
|
|
|
|
|
2013-12-14 03:40:35 +04:00
|
|
|
if (!strcmp(arg, "--no-gpg-sign")) {
|
|
|
|
sign_commit = NULL;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2011-11-09 23:54:04 +04:00
|
|
|
if (!strcmp(arg, "-m")) {
|
|
|
|
if (argc <= ++i)
|
|
|
|
usage(commit_tree_usage);
|
|
|
|
if (buffer.len)
|
|
|
|
strbuf_addch(&buffer, '\n');
|
|
|
|
strbuf_addstr(&buffer, argv[i]);
|
|
|
|
strbuf_complete_line(&buffer);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!strcmp(arg, "-F")) {
|
|
|
|
int fd;
|
|
|
|
|
|
|
|
if (argc <= ++i)
|
|
|
|
usage(commit_tree_usage);
|
|
|
|
if (buffer.len)
|
|
|
|
strbuf_addch(&buffer, '\n');
|
|
|
|
if (!strcmp(argv[i], "-"))
|
|
|
|
fd = 0;
|
|
|
|
else {
|
|
|
|
fd = open(argv[i], O_RDONLY);
|
|
|
|
if (fd < 0)
|
|
|
|
die_errno("git commit-tree: failed to open '%s'",
|
|
|
|
argv[i]);
|
|
|
|
}
|
|
|
|
if (strbuf_read(&buffer, fd, 0) < 0)
|
|
|
|
die_errno("git commit-tree: failed to read '%s'",
|
|
|
|
argv[i]);
|
|
|
|
if (fd && close(fd))
|
|
|
|
die_errno("git commit-tree: failed to close '%s'",
|
|
|
|
argv[i]);
|
|
|
|
strbuf_complete_line(&buffer);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2012-07-03 21:03:38 +04:00
|
|
|
if (get_sha1_tree(arg, tree_sha1))
|
2011-11-09 23:33:55 +04:00
|
|
|
die("Not a valid object name %s", arg);
|
|
|
|
if (got_tree)
|
|
|
|
die("Cannot give more than one trees");
|
|
|
|
got_tree = 1;
|
2008-07-01 06:37:49 +04:00
|
|
|
}
|
|
|
|
|
2011-11-09 23:54:04 +04:00
|
|
|
if (!buffer.len) {
|
|
|
|
if (strbuf_read(&buffer, 0, 0) < 0)
|
|
|
|
die_errno("git commit-tree: failed to read");
|
|
|
|
}
|
2008-07-01 06:37:49 +04:00
|
|
|
|
2014-06-11 01:36:52 +04:00
|
|
|
if (commit_tree(buffer.buf, buffer.len, tree_sha1, parents,
|
|
|
|
commit_sha1, NULL, sign_commit)) {
|
2010-10-02 12:41:00 +04:00
|
|
|
strbuf_release(&buffer);
|
2006-03-25 09:23:25 +03:00
|
|
|
return 1;
|
2010-10-02 12:41:00 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
printf("%s\n", sha1_to_hex(commit_sha1));
|
|
|
|
strbuf_release(&buffer);
|
|
|
|
return 0;
|
2005-04-08 02:13:13 +04:00
|
|
|
}
|