git/sequencer.c, branch v2.7.3

sequencer: simplify memory allocation of get_message

2016-02-22T22:51:09Z

For a commit with sha1 "1234abcd" and subject "foo", this function produces a struct with three strings: 1. "foo" 2. "1234abcd... foo" 3. "parent of 1234abcd... foo" It takes advantage of the fact that these strings are subsets of each other, and allocates only _one_ string, with pointers into the various parts. Unfortunately, this makes the string allocation complicated and hard to follow. Since we keep only one of these in memory at a time, we can afford to simply allocate three strings. This lets us build on tools like xstrfmt and avoid manual computation. While we're here, we can also drop the ad-hoc reimplementation of get_git_commit_encoding(), and simply call that function. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Remove get_object_hash.

2015-11-20T13:02:05Z

Convert all instances of get_object_hash to use an appropriate reference to the hash member of the oid member of struct object. This provides no functional change, as it is essentially a macro substitution. Signed-off-by: brian m. carlson Signed-off-by: Jeff King

Convert struct object to object_id

2015-11-20T13:02:05Z

struct object is one of the major data structures dealing with object IDs. Convert it to use struct object_id instead of an unsigned char array. Convert get_object_hash to refer to the new member as well. Signed-off-by: brian m. carlson Signed-off-by: Jeff King

Add several uses of get_object_hash.

2015-11-20T13:02:05Z

Convert most instances where the sha1 member of struct object is dereferenced to use get_object_hash. Most instances that are passed to functions that have versions taking struct object_id, such as get_sha1_hex/get_oid_hex, or instances that can be trivially converted to use struct object_id instead, are not converted. Signed-off-by: brian m. carlson Signed-off-by: Jeff King

Merge branch 'dt/refs-pseudo'

2015-08-25T21:57:08Z

To prepare for allowing a different "ref" backend to be plugged in to the system, update_ref()/delete_ref() have been taught about ref-like things like MERGE_HEAD that are per-worktree (they will always be written to the filesystem inside $GIT_DIR). * dt/refs-pseudo: pseudoref: check return values from read_ref() sequencer: replace write_cherry_pick_head with update_ref bisect: use update_ref pseudorefs: create and use pseudoref update and delete functions refs: add ref_type function refs: introduce pseudoref and per-worktree ref concepts

memoize common git-path "constant" files

2015-08-10T22:37:14Z

One of the most common uses of git_path() is to pass a constant, like git_path("MERGE_MSG"). This has two drawbacks: 1. The return value is a static buffer, and the lifetime is dependent on other calls to git_path, etc. 2. There's no compile-time checking of the pathname. This is OK for a one-off (after all, we have to spell it correctly at least once), but many of these constant strings appear throughout the code. This patch introduces a series of functions to "memoize" these strings, which are essentially globals for the lifetime of the program. We compute the value once, take ownership of the buffer, and return the cached value for subsequent calls. cache.h provides a helper macro for defining these functions as one-liners, and defines a few common ones for global use. Using a macro is a little bit gross, but it does nicely document the purpose of the functions. If we need to touch them all later (e.g., because we learned how to change the git_dir variable at runtime, and need to invalidate all of the stored values), it will be much easier to have the complete list. Note that the shared-global functions have separate, manual declarations. We could do something clever with the macros (e.g., expand it to a declaration in some places, and a declaration _and_ a definition in path.c). But there aren't that many, and it's probably better to stay away from too-magical macros. Likewise, if we abandon the C preprocessor in favor of generating these with a script, we could get much fancier. E.g., normalizing "FOO/BAR-BAZ" into "git_path_foo_bar_baz". But the small amount of saved typing is probably not worth the resulting confusion to readers who want to grep for the function's definition. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

sequencer: replace write_cherry_pick_head with update_ref

2015-07-31T17:40:18Z

Now update_ref (via write_pseudoref) does almost exactly what write_cherry_pick_head did, so we can remove write_cherry_pick_head and just use update_ref. Signed-off-by: David Turner Signed-off-by: Junio C Hamano

Merge branch 'mg/sequencer-commit-messages-always-verbatim'

2015-03-17T23:01:32Z

"git cherry-pick" used to clean-up the log message even when it is merely replaying an existing commit. It now replays the message verbatim unless you are editing the message of resulting commits. * mg/sequencer-commit-messages-always-verbatim: sequencer: preserve commit messages

sequencer: preserve commit messages

2015-03-06T19:11:39Z

sequencer calls "commit" with default options, which implies "--cleanup=default" unless the user specified something else in their config. This leads to cherry-picked commits getting a cleaned up commit message, which is usually not an intended side-effect. Make the sequencer use "--cleanup=verbatim" so that it preserves commit messages independent of the default, unless the user has set config for "commit" or the message is amended with -s or -x. Reported-by: Christoph Anton Mitterer Signed-off-by: Michael J Gruber Signed-off-by: Junio C Hamano

ref_transaction_update(): remove "have_old" parameter

2015-02-17T19:22:50Z

Instead, verify the reference's old value if and only if old_sha1 is non-NULL. ref_transaction_delete() will get the same treatment in a moment. Signed-off-by: Michael Haggerty Reviewed-by: Stefan Beller Signed-off-by: Junio C Hamano