git/sequencer.c, branch v1.8.2.2

Correct common spelling mistakes in comments and tests

2013-04-12T20:38:40Z

Most of these were found using Lucas De Marchi's codespell tool. Signed-off-by: Stefano Lattarini Signed-off-by: Jonathan Nieder Acked-by: Matthieu Moy Signed-off-by: Junio C Hamano

learn to pick/revert into unborn branch

2012-12-23T18:40:37Z

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 Signed-off-by: Junio C Hamano

Merge branch 'jc/same-encoding'

2012-11-15T18:24:05Z

Various codepaths checked if two encoding names are the same using ad-hoc code and some of them ended up asking iconv() to convert between "utf8" and "UTF-8". The former is not a valid way to spell the encoding name, but often people use it by mistake, and we equated them in some but not all codepaths. Introduce a new helper function to make these codepaths consistent. * jc/same-encoding: reencode_string(): introduce and use same_encoding() Conflicts: builtin/mailinfo.c

reencode_string(): introduce and use same_encoding()

2012-11-04T13:10:33Z

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

Move try_merge_command and checkout_fast_forward to libgit.a

2012-10-29T07:08:30Z

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 Signed-off-by: Jeff King

Merge branch 'jc/make-static'

2012-09-18T21:37:46Z

Turn many file-scope private symbols to static to reduce the global namespace contamination. * jc/make-static: sequencer.c: mark a private file-scope symbol as static ident.c: mark private file-scope symbols as static trace.c: mark a private file-scope symbol as static wt-status.c: mark a private file-scope symbol as static read-cache.c: mark a private file-scope symbol as static strbuf.c: mark a private file-scope symbol as static sha1-array.c: mark a private file-scope symbol as static symlinks.c: mark private file-scope symbols as static notes.c: mark a private file-scope symbol as static rerere.c: mark private file-scope symbols as static graph.c: mark private file-scope symbols as static diff.c: mark a private file-scope symbol as static commit.c: mark a file-scope private symbol as static builtin/notes.c: mark file-scope private symbols as static

sequencer.c: mark a private file-scope symbol as static

2012-09-16T06:20:40Z

Signed-off-by: Junio C Hamano

cherry-pick: don't forget -s on failure

2012-09-14T17:04:29Z

In case 'git cherry-pick -s ' 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 Signed-off-by: Junio C Hamano

Merge branch 'mz/cherry-pick-cmdline-order'

2012-09-10T22:42:55Z

"git cherry-pick A C B" used to replay changes in A and then B and then C if these three commits had committer timestamps in that order, which is not what the user who said "A C B" naturally expects. * mz/cherry-pick-cmdline-order: cherry-pick/revert: respect order of revisions to pick demonstrate broken 'git cherry-pick three one two' teach log --no-walk=unsorted, which avoids sorting

cherry-pick/revert: respect order of revisions to pick

2012-08-30T21:00:23Z

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 Signed-off-by: Junio C Hamano