kernel/git - git - PowerEL Git System

Commit Graph

Author	SHA1	Message	Date
Junio C Hamano	7c0b0d8dea	cherry-pick: picking a tag that resolves to a commit is OK Earlier, `21246dbb9e` (cherry-pick: make sure all input objects are commits, 2013-04-11) tried to catch an unlikely "git cherry-pick $blob" as an error, but broke a more important use case to cherry-pick a tag that points at a commit. Signed-off-by: Junio C Hamano <gitster@pobox.com>	12 years ago
Stefano Lattarini	41ccfdd9c9	Correct common spelling mistakes in comments and tests Most of these were found using Lucas De Marchi's codespell tool. Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Acked-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>	12 years ago
Miklos Vajna	21246dbb9e	cherry-pick: make sure all input objects are commits When a single argument was a non-commit, the error message used to be: fatal: BUG: expected exactly one commit from walk For multiple arguments, when none of the arguments was a commit, the error was: fatal: empty commit set passed Finally, when some of the arguments were non-commits, we ignored those arguments. Fix this bug and make sure all arguments are commits, and for the first non-commit, error out with: fatal: <name>: Can't cherry-pick a <type> Signed-off-by: Miklos Vajna <vmiklos@suse.cz> Signed-off-by: Junio C Hamano <gitster@pobox.com>	12 years ago
Brandon Casey	8c613fd5ef	git-commit: populate the edit buffer with 2 blank lines before s-o-b 'commit -s' populates the edit buffer with a blank line before the Signed-off-by line, to allow the user to immediately start typing the log message. But commit `33f2f9ab` removed this space, forcing the user to first push the Signed-off-by line down to open a place to type the log message. Fix this regression and let's ensure that the Signed-off-by line is preceded by two blank lines, instead of just one, to hint that something should be filled in, and that a blank line should separate it from the body and the Signed-off-by line. Add a test for this behavior. Reported-by: John Keeping <john@keeping.me.uk> Signed-off-by: Brandon Casey <drafnel@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	12 years ago
Brandon Casey	33f2f9ab4e	sequencer.c: teach append_signoff to avoid adding a duplicate newline Teach append_signoff to detect whether a blank line exists at the position that the signed-off-by line will be added, and refrain from adding an additional one if one already exists. Or, add an additional line if one is needed to make sure the new footer is separated from the message body by a blank line. Signed-off-by: Brandon Casey <bcasey@nvidia.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	12 years ago
Brandon Casey	bab4d1097c	sequencer.c: teach append_signoff how to detect duplicate s-o-b Teach append_signoff how to detect a duplicate s-o-b in the commit footer. This is in preparation to unify the append_signoff implementations in log-tree.c and sequencer.c. Fixes test in t3511. Signed-off-by: Brandon Casey <bcasey@nvidia.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	12 years ago
Brandon Casey	b971e04f54	sequencer.c: always separate "(cherry picked from" from commit body Start treating the "(cherry picked from" line added by cherry-pick -x the same way that the s-o-b lines are treated. Namely, separate them from the main commit message body with an empty line. Introduce tests to test this functionality. Signed-off-by: Brandon Casey <bcasey@nvidia.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	12 years ago
Brandon Casey	2cdccad160	sequencer.c: require a conforming footer to be preceded by a blank line Currently, append_signoff() performs a search for the last line of the commit buffer by searching back from the end until it hits a newline. If it reaches the beginning of the buffer without finding a newline, that means either the commit message was empty, or there was only one line in it. In this case, append_signoff will skip the call to has_conforming_footer since it already knows that it is necessary to append a newline before appending the sob. Let's perform this function inside of has_conforming_footer where it appropriately belongs and generalize it so that we require that the footer paragraph be an actual distinct paragraph separated by a blank line. Signed-off-by: Brandon Casey <drafnel@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	12 years ago
Brandon Casey	cd650a4eee	sequencer.c: recognize "(cherry picked from ..." as part of s-o-b footer When 'cherry-pick -s' is used to append a signed-off-by line to a cherry picked commit, it does not currently detect the "(cherry picked from..." that may have been appended by a previous 'cherry-pick -x' as part of the s-o-b footer and it will insert a blank line before appending a new s-o-b. Let's detect "(cherry picked from...)" as part of the footer so that we will produce this: Signed-off-by: A U Thor <author@example.com> (cherry picked from da39a3ee5e6b4b0d3255bfef95601890afd80709) Signed-off-by: C O Mmitter <committer@example.com> instead of this: Signed-off-by: A U Thor <author@example.com> (cherry picked from da39a3ee5e6b4b0d3255bfef95601890afd80709) Signed-off-by: C O Mmitter <committer@example.com> [with improvements from Jonathan Nieder] Signed-off-by: Brandon Casey <bcasey@nvidia.com> Acked-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	12 years ago
Brandon Casey	9b15152209	commit, cherry-pick -s: remove broken support for multiline rfc2822 fields Starting with `c1e01b0c` (commit: More generous accepting of RFC-2822 footer lines, 2009-10-28), "git commit -s" carefully parses the last paragraph of each commit message to check if it consists only of RFC2822-style headers, in which case the signoff will be added as a new line in the same list: Reported-by: Reporter <reporter@example.com> Signed-off-by: Author <author@example.com> Acked-by: Lieutenant <lt@example.com> It even included support for accepting indented continuation lines for multiline fields. Unfortunately the multiline field support is broken because it checks whether buf[k] (the first character of the next line) instead of buf[i] is a whitespace character. The result is that any footer with a continuation line is not accepted, since the last continuation line neither starts with an RFC2822 field name nor is followed by a continuation line. That this has remained broken for so long is good evidence that nobody actually needed multiline fields. Rip out the broken continuation support. There should be no functional change. [Thanks to Jonathan Nieder for the excellent commit message] Signed-off-by: Brandon Casey <bcasey@nvidia.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	12 years ago
Jonathan Nieder	fa1727fb21	sequencer.c: rework search for start of footer to improve clarity This code sequence is somewhat difficult to read. Let's rewrite it and add some comments to improve clarity. Signed-off-by: Brandon Casey <drafnel@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	12 years ago
Martin von Zweigbergk	334ae39745	learn to pick/revert into unborn branch cherry-picking into an unborn branch should work, so make it work, with or without --ff. Cherry-picking anything other than a commit that only adds files, will naturally result in conflicts. Similarly, revert also works, but will result in conflicts unless the specified revision only deletes files. Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	12 years ago
Junio C Hamano	0e18bcd5e9	reencode_string(): introduce and use same_encoding() Callers of reencode_string() that re-encodes a string from one encoding to another all used ad-hoc way to bypass the case where the input and the output encodings are the same. Some did strcmp(), some did strcasecmp(), yet some others when converting to UTF-8 used is_encoding_utf8(). Introduce same_encoding() helper function to make these callers use the same logic. Notably, is_encoding_utf8() has a work-around for common misconfiguration to use "utf8" to name UTF-8 encoding, which does not match "UTF-8" hence strcasecmp() would not consider the same. Make use of it in this helper function. Signed-off-by: Junio C Hamano <gitster@pobox.com>	12 years ago
Nguyễn Thái Ngọc Duy	db699a8a1f	Move try_merge_command and checkout_fast_forward to libgit.a These functions are called in sequencer.c, which is part of libgit.a. This makes libgit.a potentially require builtin/merge.c for external git commands. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Jeff King <peff@peff.net>	12 years ago
Junio C Hamano	250f2492a4	sequencer.c: mark a private file-scope symbol as static Signed-off-by: Junio C Hamano <gitster@pobox.com>	12 years ago
Miklos Vajna	5ed75e2a3f	cherry-pick: don't forget -s on failure In case 'git cherry-pick -s <commit>' failed, the user had to use 'git commit -s' (i.e. state the -s option again), which is easy to forget about. Instead, write the signed-off-by line early, so plain 'git commit' will have the same result. Also update 'git commit -s', so that in case there is already a relevant Signed-off-by line before the Conflicts: line, it won't add one more at the end of the message. If there is no such line, then add it before the the Conflicts: line. Signed-off-by: Miklos Vajna <vmiklos@suse.cz> Signed-off-by: Junio C Hamano <gitster@pobox.com>	12 years ago
Martin von Zweigbergk	a73e22e963	cherry-pick/revert: respect order of revisions to pick When giving multiple individual revisions to cherry-pick or revert, as in 'git cherry-pick A B' or 'git revert B A', one would expect them to be picked/reverted in the order given on the command line. They are instead ordered by their commit timestamp -- in chronological order for "cherry-pick" and in reverse chronological order for "revert". This matches the order in which one would usually give them on the command line, making this bug somewhat hard to notice. Still, it has been reported at least once before [1]. It seems like the chronological sorting happened by accident because the revision walker has traditionally always sorted commits in reverse chronological order when rev_info.no_walk was enabled. In the case of 'git revert B A' where B is newer than A, this sorting is a no-op. For 'git cherry-pick A B', the sorting would reverse the arguments, but because the sequencer also flips the rev_info.reverse flag when picking (as opposed to reverting), the end result is a chronological order. The rev_info.reverse flag was probably flipped so that the revision walker emits B before C in 'git cherry-pick A..C'; that it happened to effectively undo the unexpected sorting done when not walking, was probably a coincidence that allowed this bug to happen at all. Fix the bug by telling the revision walker not to sort the commits when not walking. The only case we want to reverse the order is now when cherry-picking and walking revisions (rev_info.no_walk = 0). [1] http://thread.gmane.org/gmane.comp.version-control.git/164794 Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Chris Webb	4bee958479	cherry-pick: add --allow-empty-message option Scripts such as "git rebase -i" cannot currently cherry-pick commits which have an empty commit message, as git cherry-pick calls git commit without the --allow-empty-message option. Add an --allow-empty-message option to git cherry-pick which is passed through to git commit, so this behaviour can be overridden. Signed-off-by: Chris Webb <chris@arachsys.com> Reviewed-by: Neil Horman <nhorman@tuxdriver.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Junio C Hamano	ac2b0e8fb7	cherry-pick: regression fix for empty commits The earlier "--keep-redundant-commit" series broke "cherry-pick" that is given a commit whose change is already in the current history. Such a cherry-pick would result in an empty change, and should stop with an error, telling the user that conflict resolution may have made the result empty (which is exactly what is happening), but we silently dropped the change on the floor without any message nor non-zero exit code. Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Neil Horman	4b580061b3	git cherry-pick: do not dereference a potential NULL pointer In the case the pointer could be NULL, the function that gave the caller the NULL pointer would already have issued an error message, so simply returning early with an error status without issuing a new message is sufficient. The same for parse_commit() that will show necessary error message when the argument is not NULL, and will return error silently when the argument is NULL. Noticed-by: Michael Mueller Signed-off-by: Neil Horman <nhorman@tuxdriver.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
René Scharfe	89b5f1d9c5	sequencer: export commit_list_append() This function can be used in other parts of git. Give it a new home in commit.c. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Neil Horman	b27cfb0d8d	git-cherry-pick: Add keep-redundant-commits option The git-cherry-pick --allow-empty command by default only preserves empty commits that were originally empty, i.e only those commits for which <commit>^{tree} and <commit>^^{tree} are equal. By default commits which are non-empty, but were made empty by the inclusion of a prior commit on the current history are filtered out. This option allows us to override that behavior and include redundant commits as empty commits in the change history. Note that this patch changes the default behavior of git cherry-pick slightly. Prior to this patch all commits in a cherry-pick sequence were applied and git commit was run. The implication here was that, if a commit was redundant, and the commit did not trigger the fast forward logic, the git commit operation, and therefore the git cherry-pick operation would fail, displaying the cherry pick advice (i.e. run git commit --allow-empty). With this patch however, such redundant commits are automatically skipped without stopping, unless --keep-redundant-commits is specified, in which case, they are automatically applied as empty commits. Signed-off-by: Neil Horman <nhorman@tuxdriver.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Ralf Thielow	51120683ec	sequencer: remove additional blank line Remove an additional blank line between the headline and the list of conflicted files after doing a recursive merge. Signed-off-by: Ralf Thielow <ralf.thielow@googlemail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Neil Horman	df478b744c	git-cherry-pick: add allow-empty option git cherry-pick fails when picking a non-ff commit that is empty. The advice given with the failure is that a git-commit --allow-empty should be issued to explicitly add the empty commit during the cherry pick. This option allows a user to specify before hand that they want to keep the empty commit. This eliminates the need to issue both a cherry pick and a commit operation. Signed-off-by: Neil Horman <nhorman@tuxdriver.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Jeff King	cba595bd21	drop casts from users EMPTY_TREE_SHA1_BIN This macro already evaluates to the correct type, as it casts the string literal to "unsigned char *" itself (and callers who want the literal can use the _LITERAL form). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Phil Hord	ed727b192b	cherry-pick: No advice to commit if --no-commit When cherry-pick fails it offers a helpful hint about how to proceed. The hint tells the user how to do the cleanup needed by the conflicted cherry-pick and finish the job after conflict resolution. In case of cherry-pick --no-commit, the hint goes too far. It tells the user to finish up with 'git commit'. That is not what this git-cherry-pick was trying to do in the first place. Restrict the hint in case of --no-commit to avoid giving this extra advice. Also, add a test verifying the reduced hint for the --no-commit version of cherry-pick. Signed-off-by: Phil Hord <hordp@cisco.com> Acked-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Ramkumar Ramachandra	043a4492b3	sequencer: factor code out of revert builtin Expose the cherry-picking machinery through a public sequencer_pick_revisions() (renamed from pick_revisions() in builtin/revert.c), so that cherry-picking and reverting are special cases of a general sequencer operation. The cherry-pick builtin is now a thin wrapper that does command-line argument parsing before calling into sequencer_pick_revisions(). In the future, we can write a new "foo" builtin that calls into the sequencer like: memset(&opts, 0, sizeof(opts)); opts.action = REPLAY_FOO; opts.revisions = xmalloc(sizeof(*opts.revs)); parse_args_populate_opts(argc, argv, &opts); init_revisions(opts.revs); sequencer_pick_revisions(&opts); This patch does not intend to make any functional changes. Check with: $ git blame -s -C HEAD^..HEAD -- sequencer.c \| grep -C3 '^[^^]' Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Jonathan Nieder	d596118d7a	revert: stop creating and removing sequencer-old directory Now that "git reset" no longer implicitly removes .git/sequencer that the operator may or may not have wanted to keep, the logic to write a backup copy of .git/sequencer and remove it when stale is not needed any more. Simplify the sequencer API and repository layout by dropping it. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Ramkumar Ramachandra	26ae337be1	revert: Introduce --reset to remove sequencer state To explicitly remove the sequencer state for a fresh cherry-pick or revert invocation, introduce a new subcommand called "--reset" to remove the sequencer state. Take the opportunity to publicly expose the sequencer paths, and a generic function called "remove_sequencer_state" that various git programs can use to remove the sequencer state in a uniform manner; "git reset" uses it later in this series. Introducing this public API is also in line with our long-term goal of eventually factoring out functions from revert.c into a generic commit sequencer. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	14 years ago

42 Commits (5e49f30c85ecacec98631462fa73f1148a01637c)