- 14 6月, 2014 2 次提交
-
-
由 Jeff King 提交于
Each of these sites assumes that commit->buffer is valid. Since they would segfault if this was not the case, they are likely to be correct in practice. However, we can future-proof them by using get_commit_buffer. And as a side effect, we abstract away the final bare uses of commit->buffer. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jeff King 提交于
Like the callsites in the previous commit, logmsg_reencode already falls back to read_sha1_file when necessary. However, I split its conversion out into its own commit because it's a bit more complex. We return either: 1. The original commit->buffer 2. A newly allocated buffer from read_sha1_file 3. A reencoded buffer (based on either 1 or 2 above). while trying to do as few extra reads/allocations as possible. Callers currently free the result with logmsg_free, but we can simplify this by pointing them straight to unuse_commit_buffer. This is a slight layering violation, in that we may be passing a buffer from (3). However, since the end result is to free() anything except (1), which is unlikely to change, and because this makes the interface much simpler, it's a reasonable bending of the rules. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 13 6月, 2014 1 次提交
-
-
由 Jeff King 提交于
This simplifies the code, as logmsg_reencode handles the reencoding for us in a single call. It also means we learn logmsg_reencode's trick of pulling the buffer from disk when commit->buffer is NULL (we currently just silently return!). It is doubtful this matters in practice, though, as sequencer operations would not generally turn off save_commit_buffer. Note that we may be fixing a bug here. The existing code does: if (same_encoding(to, from)) reencode_string(buf, to, from); That probably should have been "!same_encoding". Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 28 1月, 2014 1 次提交
-
-
由 Nicolas Vigier 提交于
Signed-off-by: NNicolas Vigier <boklm@mars-attacks.org> Signed-off-by: Nbrian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 06 12月, 2013 1 次提交
-
-
由 Christian Couder 提交于
Leaving only the function definitions and declarations so that any new topic in flight can still make use of the old functions, replace existing uses of the prefixcmp() and suffixcmp() with new API functions. The change can be recreated by mechanically applying this: $ git grep -l -e prefixcmp -e suffixcmp -- \*.c | grep -v strbuf\\.c | xargs perl -pi -e ' s|!prefixcmp\(|starts_with\(|g; s|prefixcmp\(|!starts_with\(|g; s|!suffixcmp\(|ends_with\(|g; s|suffixcmp\(|!ends_with\(|g; ' on the result of preparatory changes in this series. Signed-off-by: NChristian Couder <chriscool@tuxfamily.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 31 8月, 2013 1 次提交
-
-
由 Brad King 提交于
Expose lock_ref_sha1_basic's type_p argument to callers of lock_any_ref_for_update. Update all call sites to ignore it by passing NULL for now. Signed-off-by: NBrad King <brad.king@kitware.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 10 7月, 2013 1 次提交
-
-
由 Nguyễn Thái Ngọc Duy 提交于
I attempted to make index_state->cache[] a "const struct cache_entry **" to find out how existing entries in index are modified and where. The question I have is what do we do if we really need to keep track of on-disk changes in the index. The result is - diff-lib.c: setting CE_UPTODATE - name-hash.c: setting CE_HASHED - preload-index.c, read-cache.c, unpack-trees.c and builtin/update-index: obvious - entry.c: write_entry() may refresh the checked out entry via fill_stat_cache_info(). This causes "non-const struct cache_entry *" in builtin/apply.c, builtin/checkout-index.c and builtin/checkout.c - builtin/ls-files.c: --with-tree changes stagemask and may set CE_UPDATE Of these, write_entry() and its call sites are probably most interesting because it modifies on-disk info. But this is stat info and can be retrieved via refresh, at least for porcelain commands. Other just uses ce_flags for local purposes. So, keeping track of "dirty" entries is just a matter of setting a flag in index modification functions exposed by read-cache.c. Except unpack-trees, the rest of the code base does not do anything funny behind read-cache's back. The actual patch is less valueable than the summary above. But if anyone wants to re-identify the above sites. Applying this patch, then this: diff --git a/cache.h b/cache.h index 430d021..1692891 100644 --- a/cache.h +++ b/cache.h @@ -267,7 +267,7 @@ static inline unsigned int canon_mode(unsigned int mode) #define cache_entry_size(len) (offsetof(struct cache_entry,name) + (len) + 1) struct index_state { - struct cache_entry **cache; + const struct cache_entry **cache; unsigned int version; unsigned int cache_nr, cache_alloc, cache_changed; struct string_list *resolve_undo; will help quickly identify them without bogus warnings. Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 20 6月, 2013 1 次提交
-
-
由 Ramkumar Ramachandra 提交于
The following command $ git cherry-pick --ff b8bb3f writes the following uninformative message to the reflog cherry-pick Improve it to cherry-pick: fast-forward Avoid hard-coding "cherry-pick" in fast_forward_to(), so the sequencer is generic enough to support future actions. Signed-off-by: NRamkumar Ramachandra <artagnon@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 07 6月, 2013 1 次提交
-
-
由 Felipe Contreras 提交于
We should free objects before leaving. Signed-off-by: NFelipe Contreras <felipe.contreras@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 04 6月, 2013 1 次提交
-
-
由 Felipe Contreras 提交于
By using good ol' goto. Signed-off-by: NFelipe Contreras <felipe.contreras@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 10 5月, 2013 1 次提交
-
-
由 Junio C Hamano 提交于
Earlier, 21246dbb (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: NJunio C Hamano <gitster@pobox.com>
-
- 13 4月, 2013 1 次提交
-
-
由 Stefano Lattarini 提交于
Most of these were found using Lucas De Marchi's codespell tool. Signed-off-by: NStefano Lattarini <stefano.lattarini@gmail.com> Signed-off-by: NJonathan Nieder <jrnieder@gmail.com> Acked-by: NMatthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 12 4月, 2013 1 次提交
-
-
由 Miklos Vajna 提交于
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: NMiklos Vajna <vmiklos@suse.cz> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 23 2月, 2013 1 次提交
-
-
由 Brandon Casey 提交于
'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: NJohn Keeping <john@keeping.me.uk> Signed-off-by: NBrandon Casey <drafnel@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 13 2月, 2013 7 次提交
-
-
由 Brandon Casey 提交于
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: NBrandon Casey <bcasey@nvidia.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Brandon Casey 提交于
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: NBrandon Casey <bcasey@nvidia.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Brandon Casey 提交于
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: NBrandon Casey <bcasey@nvidia.com> Reviewed-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Brandon Casey 提交于
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: NBrandon Casey <drafnel@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Brandon Casey 提交于
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: NA U Thor <author@example.com> (cherry picked from da39a3ee5e6b4b0d3255bfef95601890afd80709) Signed-off-by: NC O Mmitter <committer@example.com> instead of this: Signed-off-by: NA U Thor <author@example.com> (cherry picked from da39a3ee5e6b4b0d3255bfef95601890afd80709) Signed-off-by: NC O Mmitter <committer@example.com> [with improvements from Jonathan Nieder] Signed-off-by: NBrandon Casey <bcasey@nvidia.com> Acked-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Brandon Casey 提交于
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: NReporter <reporter@example.com> Signed-off-by: NAuthor <author@example.com> Acked-by: NLieutenant <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: NBrandon Casey <bcasey@nvidia.com> Reviewed-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jonathan Nieder 提交于
This code sequence is somewhat difficult to read. Let's rewrite it and add some comments to improve clarity. Signed-off-by: NBrandon Casey <drafnel@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 24 12月, 2012 1 次提交
-
-
由 Martin von Zweigbergk 提交于
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: NMartin von Zweigbergk <martinvonz@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 04 11月, 2012 1 次提交
-
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <gitster@pobox.com>
-
- 29 10月, 2012 1 次提交
-
-
由 Nguyễn Thái Ngọc Duy 提交于
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: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJeff King <peff@peff.net>
-
- 16 9月, 2012 1 次提交
-
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 15 9月, 2012 1 次提交
-
-
由 Miklos Vajna 提交于
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: NMiklos Vajna <vmiklos@suse.cz> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 31 8月, 2012 1 次提交
-
-
由 Martin von Zweigbergk 提交于
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/164794Signed-off-by: NMartin von Zweigbergk <martinvonz@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 07 8月, 2012 1 次提交
-
-
由 Chris Webb 提交于
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: NChris Webb <chris@arachsys.com> Reviewed-by: NNeil Horman <nhorman@tuxdriver.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 30 5月, 2012 1 次提交
-
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <gitster@pobox.com>
-
- 04 5月, 2012 1 次提交
-
-
由 Neil Horman 提交于
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: NNeil Horman <nhorman@tuxdriver.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 26 4月, 2012 1 次提交
-
-
由 René Scharfe 提交于
This function can be used in other parts of git. Give it a new home in commit.c. Signed-off-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 25 4月, 2012 1 次提交
-
-
由 Neil Horman 提交于
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: NNeil Horman <nhorman@tuxdriver.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 20 4月, 2012 1 次提交
-
-
由 Ralf Thielow 提交于
Remove an additional blank line between the headline and the list of conflicted files after doing a recursive merge. Signed-off-by: NRalf Thielow <ralf.thielow@googlemail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 12 4月, 2012 1 次提交
-
-
由 Neil Horman 提交于
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: NNeil Horman <nhorman@tuxdriver.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 24 3月, 2012 1 次提交
-
-
由 Jeff King 提交于
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: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 23 2月, 2012 1 次提交
-
-
由 Phil Hord 提交于
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: NPhil Hord <hordp@cisco.com> Acked-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 12 1月, 2012 1 次提交
-
-
由 Ramkumar Ramachandra 提交于
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: NRamkumar Ramachandra <artagnon@gmail.com> Reviewed-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 13 12月, 2011 1 次提交
-
-
由 Jonathan Nieder 提交于
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: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 05 8月, 2011 1 次提交
-
-
由 Ramkumar Ramachandra 提交于
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: NRamkumar Ramachandra <artagnon@gmail.com> Signed-off-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-