summaryrefslogtreecommitdiff
path: root/sequencer.c
AgeCommit message (Collapse)AuthorFilesLines
2018-05-30Merge branch 'bc/object-id'Libravatar Junio C Hamano1-2/+2
Conversion from uchar[20] to struct object_id continues. * bc/object-id: (42 commits) merge-one-file: compute empty blob object ID add--interactive: compute the empty tree value Update shell scripts to compute empty tree object ID sha1_file: only expose empty object constants through git_hash_algo dir: use the_hash_algo for empty blob object ID sequencer: use the_hash_algo for empty tree object ID cache-tree: use is_empty_tree_oid sha1_file: convert cached object code to struct object_id builtin/reset: convert use of EMPTY_TREE_SHA1_BIN builtin/receive-pack: convert one use of EMPTY_TREE_SHA1_HEX wt-status: convert two uses of EMPTY_TREE_SHA1_HEX submodule: convert several uses of EMPTY_TREE_SHA1_HEX sequencer: convert one use of EMPTY_TREE_SHA1_HEX merge: convert empty tree constant to the_hash_algo builtin/merge: switch tree functions to use object_id builtin/am: convert uses of EMPTY_TREE_SHA1_BIN to the_hash_algo sha1-file: add functions for hex empty tree and blob OIDs builtin/receive-pack: avoid hard-coded constants for push certs diff: specify abbreviation size in terms of the_hash_algo upload-pack: replace use of several hard-coded constants ...
2018-05-30Merge branch 'js/sequencer-and-root-commits'Libravatar Junio C Hamano1-25/+181
The implementation of "git rebase -i --root" has been updated to use the sequencer machinery more. * js/sequencer-and-root-commits: rebase --rebase-merges: root commits can be cousins, too rebase --rebase-merges: a "merge" into a new root is a fast-forward sequencer: allow introducing new root commits rebase -i --root: let the sequencer handle even the initial part sequencer: learn about the special "fake root commit" handling sequencer: extract helper to update active_cache_tree
2018-05-23Merge branch 'js/rebase-recreate-merge'Libravatar Junio C Hamano1-37/+855
"git rebase" learned "--rebase-merges" to transplant the whole topology of commit graph elsewhere. * js/rebase-recreate-merge: rebase -i --rebase-merges: add a section to the man page rebase -i: introduce --rebase-merges=[no-]rebase-cousins pull: accept --rebase=merges to recreate the branch topology rebase --rebase-merges: avoid "empty merges" sequencer: handle post-rewrite for merge commands sequencer: make refs generated by the `label` command worktree-local rebase --rebase-merges: add test for --keep-empty rebase: introduce the --rebase-merges option rebase-helper --make-script: introduce a flag to rebase merges sequencer: fast-forward `merge` commands, if possible sequencer: introduce the `merge` command sequencer: introduce new commands to reset the revision git-rebase--interactive: clarify arguments sequencer: offer helpful advice when a command was rescheduled sequencer: refactor how original todo list lines are accessed sequencer: make rearrange_squash() a bit more obvious sequencer: avoid using errno clobbered by rollback_lock_file()
2018-05-23Merge branch 'js/rebase-i-clean-msg-after-fixup-continue'Libravatar Junio C Hamano1-47/+146
"git rebase -i" sometimes left intermediate "# This is a combination of N commits" message meant for the human consumption inside an editor in the final result in certain corner cases, which has been fixed. * js/rebase-i-clean-msg-after-fixup-continue: rebase --skip: clean up commit message after a failed fixup/squash sequencer: always commit without editing when asked for rebase -i: Handle "combination of <n> commits" with GETTEXT_POISON rebase -i: demonstrate bugs with fixup!/squash! commit messages
2018-05-23Merge branch 'sb/oid-object-info'Libravatar Junio C Hamano1-1/+2
The codepath around object-info API has been taught to take the repository object (which in turn tells the API which object store the objects are to be located). * sb/oid-object-info: cache.h: allow oid_object_info to handle arbitrary repositories packfile: add repository argument to cache_or_unpack_entry packfile: add repository argument to unpack_entry packfile: add repository argument to read_object packfile: add repository argument to packed_object_info packfile: add repository argument to packed_to_object_type packfile: add repository argument to retry_bad_packed_offset cache.h: add repository argument to oid_object_info cache.h: add repository argument to oid_object_info_extended
2018-05-23Merge branch 'ds/lazy-load-trees'Libravatar Junio C Hamano1-6/+6
The code has been taught to use the duplicated information stored in the commit-graph file to learn the tree object name for a commit to avoid opening and parsing the commit object when it makes sense to do so. * ds/lazy-load-trees: coccinelle: avoid wrong transformation suggestions from commit.cocci commit-graph: lazy-load trees for commits treewide: replace maybe_tree with accessor methods commit: create get_commit_tree() method treewide: rename tree to maybe_tree
2018-05-08Merge branch 'js/ident-date-fix'Libravatar Junio C Hamano1-0/+2
During a "rebase -i" session, the code could give older timestamp to commits created by later "pick" than an earlier "reword", which has been corrected. * js/ident-date-fix: sequencer: reset the committer date before commits
2018-05-06rebase --rebase-merges: root commits can be cousins, tooLibravatar Johannes Schindelin1-1/+2
Reported by Wink Saville: when rebasing with no-rebase-cousins, we will want to refrain from rebasing all of them, even when they are root commits. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-06rebase --rebase-merges: a "merge" into a new root is a fast-forwardLibravatar Johannes Schindelin1-0/+12
When a user provides a todo list containing something like reset [new root] merge my-branch let's do the same as if pulling into an orphan branch: simply fast-forward. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-06sequencer: allow introducing new root commitsLibravatar Johannes Schindelin1-12/+28
In the context of the new --rebase-merges mode, which was designed specifically to allow for changing the existing branch topology liberally, a user may want to extract commits into a completely fresh branch that starts with a newly-created root commit. This is now possible by inserting the command `reset [new root]` before `pick`ing the commit that wants to become a root commit. Example: reset [new root] pick 012345 a commit that is about to become a root commit pick 234567 this commit will have the previous one as parent This does not conflict with other uses of the `reset` command because `[new root]` is not (part of) a valid ref name: both the opening bracket as well as the space are illegal in ref names. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-06sequencer: learn about the special "fake root commit" handlingLibravatar Johannes Schindelin1-3/+121
When an interactive rebase wants to recreate a root commit, it - first creates a new, empty root commit, - checks it out, - converts the next `pick` command so that it amends the empty root commit Introduce support in the sequencer to handle such an empty root commit, by looking for the file <GIT_DIR>/rebase-merge/squash-onto; if it exists and contains a commit name, the sequencer will compare the HEAD to said root commit, and if identical, a new root commit will be created. While converting scripted code into proper, portable C, we also do away with the old "amend with an empty commit message, then cherry-pick without committing, then amend again" dance and replace it with code that uses the internal API properly to do exactly what we want: create a new root commit. To keep the implementation simple, we always spawn `git commit` to create new root commits. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-06sequencer: extract helper to update active_cache_treeLibravatar Johannes Schindelin1-9/+18
This patch extracts the code from is_index_unchanged() to initialize or update the index' cache tree (i.e. a tree object reflecting the current index' top-level tree). The new helper will be used in the upcoming code to support `git rebase -i --root` via the sequencer. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-02sequencer: use the_hash_algo for empty tree object IDLibravatar brian m. carlson1-1/+1
To ensure that we are hash algorithm agnostic, use the_hash_algo to look up the object ID for the empty tree instead of using the empty_tree_oid variable. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-02sequencer: convert one use of EMPTY_TREE_SHA1_HEXLibravatar brian m. carlson1-1/+1
Convert one use of EMPTY_TREE_SHA1_HEX to use empty_tree_oid_hex to avoid a dependency on a given hash algorithm. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-02rebase --skip: clean up commit message after a failed fixup/squashLibravatar Johannes Schindelin1-13/+100
During a series of fixup/squash commands, the interactive rebase builds up a commit message with comments. This will be presented to the user in the editor if at least one of those commands was a `squash`. In any case, the commit message will be cleaned up eventually, removing all those intermediate comments, in the final step of such a fixup/squash chain. However, if the last fixup/squash command in such a chain fails with merge conflicts, and if the user then decides to skip it (or resolve it to a clean worktree and then continue the rebase), the current code fails to clean up the commit message. This commit fixes that behavior. The fix is quite a bit more involved than meets the eye because it is not only about the question whether we are `git rebase --skip`ing a fixup or squash. It is also about removing the skipped fixup/squash's commit message from the accumulated commit message. And it is also about the question whether we should let the user edit the final commit message or not ("Was there a squash in the chain *that was not skipped*?"). For example, in this case we will want to fix the commit message, but not open it in an editor: pick <- succeeds fixup <- succeeds squash <- fails, will be skipped This is where the newly-introduced `current-fixups` file comes in real handy. A quick look and we can determine whether there was a non-skipped squash. We only need to make sure to keep it up to date with respect to skipped fixup/squash commands. As a bonus, we can even avoid committing unnecessarily, e.g. when there was only one fixup, and it failed, and was skipped. To fix only the bug where the final commit message was not cleaned up properly, but without fixing the rest, would have been more complicated than fixing it all in one go, hence this commit lumps together more than a single concern. For the same reason, this commit also adds a bit more to the existing test case for the regression we just fixed. The diff is best viewed with --color-moved. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-02sequencer: always commit without editing when asked forLibravatar Johannes Schindelin1-0/+2
Previously, we only called run_git_commit() without EDIT_MSG when we also passed in a default message. However, an upcoming caller will want to commit without EDIT_MSG and *without* a default message: to clean up fixup/squash comments in HEAD's commit message. Let's prepare for that. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-02rebase -i: Handle "combination of <n> commits" with GETTEXT_POISONLibravatar Johannes Schindelin1-34/+44
We previously relied on the localized versions of # This is a combination of <N> commits (which we write into the commit messages during fixup/squash chains) to contain <N> encoded in ASCII. This is not true in general, and certainly not true when compiled with GETTEXT_POISON=TryToKillMe, as demonstrated by the regression test we just introduced in t3418. So let's decouple keeping track of the count from the (localized) commit messages by introducing a new file called 'current-fixups' that keeps track of the current fixup/squash chain. This file contains a bit more than just the count (it contains a list of "fixup <commit>"/"squash <commit>" lines). This is done on purpose, as it will come in handy for a fix for the bug where `git rebase --skip` on a final fixup/squash will leave the commit message in limbo. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-26rebase -i: introduce --rebase-merges=[no-]rebase-cousinsLibravatar Johannes Schindelin1-0/+4
When running `git rebase --rebase-merges` non-interactively with an ancestor of HEAD as <upstream> (or leaving the todo list unmodified), we would ideally recreate the exact same commits as before the rebase. However, if there are commits in the commit range <upstream>.. that do not have <upstream> as direct ancestor (i.e. if `git log <upstream>..` would show commits that are omitted by `git log --ancestry-path <upstream>..`), this is currently not the case: we would turn them into commits that have <upstream> as direct ancestor. Let's illustrate that with a diagram: C / \ A - B - E - F \ / D Currently, after running `git rebase -i --rebase-merges B`, the new branch structure would be (pay particular attention to the commit `D`): --- C' -- / \ A - B ------ E' - F' \ / D' This is not really preserving the branch topology from before! The reason is that the commit `D` does not have `B` as ancestor, and therefore it gets rebased onto `B`. This is unintuitive behavior. Even worse, when recreating branch structure, most use cases would appear to want cousins *not* to be rebased onto the new base commit. For example, Git for Windows (the heaviest user of the Git garden shears, which served as the blueprint for --rebase-merges) frequently merges branches from `next` early, and these branches certainly do *not* want to be rebased. In the example above, the desired outcome would look like this: --- C' -- / \ A - B ------ E' - F' \ / -- D' -- Let's introduce the term "cousins" for such commits ("D" in the example), and let's not rebase them by default. For hypothetical use cases where cousins *do* need to be rebased, `git rebase --rebase=merges=rebase-cousins` needs to be used. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-26rebase --rebase-merges: avoid "empty merges"Libravatar Johannes Schindelin1-0/+7
The `git merge` command does not allow merging commits that are already reachable from HEAD: `git merge HEAD^`, for example, will report that we are already up to date and not change a thing. In an interactive rebase, such a merge could occur previously, e.g. when competing (or slightly modified) versions of a patch series were applied upstream, and the user had to `git rebase --skip` all of the local commits, and the topic branch becomes "empty" as a consequence. Let's teach the todo command `merge` to behave the same as `git merge`. Seeing as it requires some low-level trickery to create such merges with Git's commands in the first place, we do not even have to bother to introduce an option to force `merge` to create such merge commits. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-26sequencer: handle post-rewrite for merge commandsLibravatar Johannes Schindelin1-1/+4
In the previous patches, we implemented the basic functionality of the `git rebase -i --rebase-merges` command, in particular the `merge` command to create merge commits in the sequencer. The interactive rebase is a lot more these days, though, than a simple cherry-pick in a loop. For example, it calls the post-rewrite hook (if any) after rebasing with a mapping of the old->new commits. This patch implements the post-rewrite handling for the `merge` command we just introduced. The other commands that were added recently (`label` and `reset`) do not create new commits, therefore post-rewrite hooks do not need to handle them. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-26rebase-helper --make-script: introduce a flag to rebase mergesLibravatar Johannes Schindelin1-1/+345
The sequencer just learned new commands intended to recreate branch structure (similar in spirit to --preserve-merges, but with a substantially less-broken design). Let's allow the rebase--helper to generate todo lists making use of these commands, triggered by the new --rebase-merges option. For a commit topology like this (where the HEAD points to C): - A - B - C \ / D the generated todo list would look like this: # branch D pick 0123 A label branch-point pick 1234 D label D reset branch-point pick 2345 B merge -C 3456 D # C To keep things simple, we first only implement support for merge commits with exactly two parents, leaving support for octopus merges to a later patch series. All merge-rebasing todo lists start with a hard-coded `label onto` line. This makes it convenient to refer later on to the revision onto which everything is rebased, e.g. as starting point for branches other than the very first one. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-26sequencer: fast-forward `merge` commands, if possibleLibravatar Johannes Schindelin1-1/+32
Just like with regular `pick` commands, if we are trying to rebase a merge commit, we now test whether the parents of said commit match HEAD and the commits to be merged, and fast-forward if possible. This is not only faster, but also avoids unnecessary proliferation of new objects. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-26sequencer: introduce the `merge` commandLibravatar Johannes Schindelin1-0/+200
This patch is part of the effort to reimplement `--preserve-merges` with a substantially improved design, a design that has been developed in the Git for Windows project to maintain the dozens of Windows-specific patch series on top of upstream Git. The previous patch implemented the `label` and `reset` commands to label commits and to reset to labeled commits. This patch adds the `merge` command, with the following syntax: merge [-C <commit>] <rev> # <oneline> The <commit> parameter in this instance is the *original* merge commit, whose author and message will be used for the merge commit that is about to be created. The <rev> parameter refers to the (possibly rewritten) revision to merge. Let's see an example of a todo list (the initial `label onto` command is an auto-generated convenience so that the label `onto` can be used to refer to the revision onto which we rebase): label onto # Branch abc reset onto pick deadbeef Hello, world! label abc reset onto pick cafecafe And now for something completely different merge -C baaabaaa abc # Merge the branch 'abc' into master To edit the merge commit's message (a "reword" for merges, if you will), use `-c` (lower-case) instead of `-C`; this convention was borrowed from `git commit` that also supports `-c` and `-C` with similar meanings. To create *new* merges, i.e. without copying the commit message from an existing commit, simply omit the `-C <commit>` parameter (which will open an editor for the merge message): merge abc This comes in handy when splitting a branch into two or more branches. Note: this patch only adds support for recursive merges, to keep things simple. Support for octopus merges will be added later in a separate patch series, support for merges using strategies other than the recursive merge is left for the future. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-26sequencer: introduce new commands to reset the revisionLibravatar Johannes Schindelin1-7/+206
In the upcoming commits, we will teach the sequencer to rebase merges. This will be done in a very different way from the unfortunate design of `git rebase --preserve-merges` (which does not allow for reordering commits, or changing the branch topology). The main idea is to introduce new todo list commands, to support labeling the current revision with a given name, resetting the current revision to a previous state, and merging labeled revisions. This idea was developed in Git for Windows' Git garden shears (that are used to maintain Git for Windows' "thicket of branches" on top of upstream Git), and this patch is part of the effort to make it available to a wider audience, as well as to make the entire process more robust (by implementing it in a safe and portable language rather than a Unix shell script). This commit implements the commands to label, and to reset to, given revisions. The syntax is: label <name> reset <name> Internally, the `label <name>` command creates the ref `refs/rewritten/<name>`. This makes it possible to work with the labeled revisions interactively, or in a scripted fashion (e.g. via the todo list command `exec`). These temporary refs are removed upon sequencer_remove_state(), so that even a `git rebase --abort` cleans them up. We disallow '#' as label because that character will be used as separator in the upcoming `merge` command. Later in this patch series, we will mark the `refs/rewritten/` refs as worktree-local, to allow for interactive rebases to be run in parallel in worktrees linked to the same repository. As typos happen, a failed `label` or `reset` command will be rescheduled immediately. As the previous code to reschedule a command is embedded deeply in the pick/fixup/squash code path, we simply duplicate the few lines. This will allow us to extend the new code path easily for the upcoming `merge` command. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-26sequencer: offer helpful advice when a command was rescheduledLibravatar Johannes Schindelin1-0/+16
Previously, we did that just magically, and potentially left some users quite puzzled. Let's err on the safe side instead, telling the user what is happening, and how they are supposed to continue. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-26sequencer: refactor how original todo list lines are accessedLibravatar Johannes Schindelin1-24/+36
Previously, we did a lot of arithmetic gymnastics to get at the line in the todo list (as stored in todo_list.buf). This might have been fast, but only in terms of execution speed, not in terms of developer time. Let's refactor this to make it a lot easier to read, and hence to reason about the correctness of the code. It is not performance-critical code anyway. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-26sequencer: make rearrange_squash() a bit more obviousLibravatar Johannes Schindelin1-1/+1
There are some commands that have to be skipped from rearranging by virtue of not handling any commits. However, the logic was not quite obvious: it skipped commands based on their position in the enum todo_command. Instead, let's make it explicit that we skip all commands that do not handle any commit. With one exception: the `drop` command, because it, well, drops the commit and is therefore not eligible to rearranging. Note: this is a bit academic at the moment because the only time we call `rearrange_squash()` is directly after generating the todo list, when we have nothing but `pick` commands anyway. However, the upcoming `merge` command *will* want to be handled by that function, and it *can* handle commits. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-26sequencer: avoid using errno clobbered by rollback_lock_file()Libravatar Johannes Schindelin1-4/+6
As pointed out in a review of the `--rebase-merges` patch series, `rollback_lock_file()` clobbers errno. Therefore, we have to report the error message that uses errno before calling said function. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-26cache.h: add repository argument to oid_object_infoLibravatar Stefan Beller1-1/+2
Add a repository argument to allow the callers of oid_object_info to be more specific about which repository to handle. This is a small mechanical change; it doesn't change the implementation to handle repositories other than the_repository yet. As with the previous commits, use a macro to catch callers passing a repository other than the_repository at compile time. Signed-off-by: Stefan Beller <sbeller@google.com> Reviewed-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25Merge branch 'sb/filenames-with-dashes'Libravatar Junio C Hamano1-1/+1
Rename bunch of source files to more consistently use dashes instead of underscores to connect words. * sb/filenames-with-dashes: replace_object.c: rename to use dash in file name sha1_file.c: rename to use dash in file name sha1_name.c: rename to use dash in file name exec_cmd: rename to use dash in file name unicode_width.h: rename to use dash in file name write_or_die.c: rename to use dashes in file name
2018-04-25Merge branch 'pw/rebase-signoff'Libravatar Junio C Hamano1-1/+7
"git rebase" has learned to honor "--signoff" option when using backends other than "am" (but not "--preserve-merges"). * pw/rebase-signoff: rebase --keep-empty: always use interactive rebase rebase -p: error out if --signoff is given rebase: extend --signoff support
2018-04-25Merge branch 'pw/rebase-keep-empty-fixes'Libravatar Junio C Hamano1-2/+6
"git rebase --keep-empty" still removed an empty commit if the other side contained an empty commit (due to the "does an equivalent patch exist already?" check), which has been corrected. * pw/rebase-keep-empty-fixes: rebase: respect --no-keep-empty rebase -i --keep-empty: don't prune empty commits rebase --root: stop assuming squash_onto is unset
2018-04-19sequencer: reset the committer date before commitsLibravatar Johannes Sixt1-0/+2
Now that the sequencer commits without forking when the commit message isn't edited all the commits that are picked have the same committer date. If a commit is reworded it's committer date will be a later time as it is created by running an separate instance of 'git commit'. If the reworded commit is follow by further picks, those later commits will have an earlier committer date than the reworded one. This is caused by git caching the default date used when GIT_COMMITTER_DATE is not set. Reset the cached date before a commit is generated in-process. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-11exec_cmd: rename to use dash in file nameLibravatar Stefan Beller1-1/+1
This is more consistent with the project style. The majority of Git's source files use dashes in preference to underscores in their file names. Signed-off-by: Stefan Beller <sbeller@google.com>
2018-04-11treewide: replace maybe_tree with accessor methodsLibravatar Derrick Stolee1-6/+6
In anticipation of making trees load lazily, create a Coccinelle script (contrib/coccinelle/commit.cocci) to ensure that all references to the 'maybe_tree' member of struct commit are either mutations or accesses through get_commit_tree() or get_commit_tree_oid(). Apply the Coccinelle script to create the rest of the patch. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-11treewide: rename tree to maybe_treeLibravatar Derrick Stolee1-6/+6
Using the commit-graph file to walk commit history removes the large cost of parsing commits during the walk. This exposes a performance issue: lookup_tree() takes a large portion of the computation time, even when Git never uses those trees. In anticipation of lazy-loading these trees, rename the 'tree' member of struct commit to 'maybe_tree'. This serves two purposes: it hints at the future role of possibly being NULL even if the commit has a valid tree, and it allows for unambiguous transformation from simple member access (i.e. commit->maybe_tree) to method access. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-11Merge branch 'bw/c-plus-plus' into ds/lazy-load-treesLibravatar Junio C Hamano1-1/+1
* bw/c-plus-plus: (37 commits) replace: rename 'new' variables trailer: rename 'template' variables tempfile: rename 'template' variables wrapper: rename 'template' variables environment: rename 'namespace' variables diff: rename 'template' variables environment: rename 'template' variables init-db: rename 'template' variables unpack-trees: rename 'new' variables trailer: rename 'new' variables submodule: rename 'new' variables split-index: rename 'new' variables remote: rename 'new' variables ref-filter: rename 'new' variables read-cache: rename 'new' variables line-log: rename 'new' variables imap-send: rename 'new' variables http: rename 'new' variables entry: rename 'new' variables diffcore-delta: rename 'new' variables ...
2018-04-10Merge branch 'bc/object-id'Libravatar Junio C Hamano1-4/+5
Conversion from uchar[20] to struct object_id continues. * bc/object-id: (36 commits) convert: convert to struct object_id sha1_file: introduce a constant for max header length Convert lookup_replace_object to struct object_id sha1_file: convert read_sha1_file to struct object_id sha1_file: convert read_object_with_reference to object_id tree-walk: convert tree entry functions to object_id streaming: convert istream internals to struct object_id tree-walk: convert get_tree_entry_follow_symlinks internals to object_id builtin/notes: convert static functions to object_id builtin/fmt-merge-msg: convert remaining code to object_id sha1_file: convert sha1_object_info* to object_id Convert remaining callers of sha1_object_info_extended to object_id packfile: convert unpack_entry to struct object_id sha1_file: convert retry_bad_packed_offset to struct object_id sha1_file: convert assert_sha1_type to object_id builtin/mktree: convert to struct object_id streaming: convert open_istream to use struct object_id sha1_file: convert check_sha1_signature to struct object_id sha1_file: convert read_loose_object to use struct object_id builtin/index-pack: convert struct ref_delta_entry to object_id ...
2018-03-29rebase: extend --signoff supportLibravatar Phillip Wood1-1/+7
Allow --signoff to be used with --interactive and --merge. In interactive mode only commits marked to be picked, edited or reworded will be signed off. The main motivation for this patch was to allow one to run 'git rebase --exec "make check" --signoff' which is useful when preparing a patch series for publication and is more convenient than doing the signoff with another --exec command. This change also allows --root without --onto to work with --signoff as well (--root with --onto was already supported). Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-29Merge branch 'pw/rebase-keep-empty-fixes' into pw/rebase-signoffLibravatar Junio C Hamano1-2/+6
* pw/rebase-keep-empty-fixes: rebase: respect --no-keep-empty rebase -i --keep-empty: don't prune empty commits rebase --root: stop assuming squash_onto is unset Git 2.16.2
2018-03-29rebase -i --keep-empty: don't prune empty commitsLibravatar Phillip Wood1-2/+6
If there are empty commits on the left hand side of $upstream...HEAD then the empty commits on the right hand side that we want to keep are pruned by --cherry-pick. Fix this by using --cherry-mark instead of --cherry-pick and keeping the commits that are empty or are not marked as cherry-picks. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-21Merge branch 'ma/skip-writing-unchanged-index'Libravatar Junio C Hamano1-6/+5
Internal API clean-up to allow write_locked_index() optionally skip writing the in-core index when it is not modified. * ma/skip-writing-unchanged-index: write_locked_index(): add flag to avoid writing unchanged index
2018-03-14Merge branch 'ma/roll-back-lockfiles'Libravatar Junio C Hamano1-18/+14
Some codepaths used to take a lockfile and did not roll it back; they are automatically rolled back at program exit, so there is no real "breakage", but it still is a good practice to roll back when you are done with a lockfile. * ma/roll-back-lockfiles: sequencer: do not roll back lockfile unnecessarily merge: always roll back lock in `checkout_fast_forward()` merge-recursive: always roll back lock in `merge_recursive_generic()` sequencer: always roll back lock in `do_recursive_merge()` sequencer: make lockfiles non-static
2018-03-14sha1_file: convert sha1_object_info* to object_idLibravatar brian m. carlson1-1/+2
Convert sha1_object_info and sha1_object_info_extended to take pointers to struct object_id and rename them to use "oid" instead of "sha1" in their names. Update the declaration and definition and apply the following semantic patch, plus the standard object_id transforms: @@ expression E1, E2; @@ - sha1_object_info(E1.hash, E2) + oid_object_info(&E1, E2) @@ expression E1, E2; @@ - sha1_object_info(E1->hash, E2) + oid_object_info(E1, E2) @@ expression E1, E2, E3; @@ - sha1_object_info_extended(E1.hash, E2, E3) + oid_object_info_extended(&E1, E2, E3) @@ expression E1, E2, E3; @@ - sha1_object_info_extended(E1->hash, E2, E3) + oid_object_info_extended(E1, E2, E3) Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-14Convert find_unique_abbrev* to struct object_idLibravatar brian m. carlson1-1/+1
Convert find_unique_abbrev and find_unique_abbrev_r to each take a pointer to struct object_id. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-14cache-tree: convert write_*_as_tree to object_idLibravatar brian m. carlson1-2/+2
Convert write_index_as_tree and write_cache_as_tree to use struct object_id. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-06Merge branch 'bw/c-plus-plus'Libravatar Junio C Hamano1-1/+1
Avoid using identifiers that clash with C++ keywords. Even though it is not a goal to compile Git with C++ compilers, changes like this help use of code analysis tools that targets C++ on our codebase. * bw/c-plus-plus: (37 commits) replace: rename 'new' variables trailer: rename 'template' variables tempfile: rename 'template' variables wrapper: rename 'template' variables environment: rename 'namespace' variables diff: rename 'template' variables environment: rename 'template' variables init-db: rename 'template' variables unpack-trees: rename 'new' variables trailer: rename 'new' variables submodule: rename 'new' variables split-index: rename 'new' variables remote: rename 'new' variables ref-filter: rename 'new' variables read-cache: rename 'new' variables line-log: rename 'new' variables imap-send: rename 'new' variables http: rename 'new' variables entry: rename 'new' variables diffcore-delta: rename 'new' variables ...
2018-03-06Merge branch 'rs/strbuf-read-file-or-whine'Libravatar Junio C Hamano1-46/+28
Code clean-up. * rs/strbuf-read-file-or-whine: sequencer: factor out strbuf_read_file_or_whine()
2018-03-06Merge branch 'nd/rebase-show-current-patch'Libravatar Junio C Hamano1-0/+4
The new "--show-current-patch" option gives an end-user facing way to get the diff being applied when "git rebase" (and "git am") stops with a conflict. * nd/rebase-show-current-patch: rebase: introduce and use pseudo-ref REBASE_HEAD rebase: add --show-current-patch am: add --show-current-patch
2018-03-01write_locked_index(): add flag to avoid writing unchanged indexLibravatar Martin Ågren1-6/+5
We have several callers like if (active_cache_changed && write_locked_index(...)) handle_error(); rollback_lock_file(...); where the final rollback is needed because "!active_cache_changed" shortcuts the if-expression. There are also a few variants of this, including some if-else constructs that make it more clear when the explicit rollback is really needed. Teach `write_locked_index()` to take a new flag SKIP_IF_UNCHANGED and simplify the callers. Leave the most complicated of the callers (in builtin/update-index.c) unchanged. Rewriting it to use this new flag would end up duplicating logic. We could have made the new flag behave the other way round ("FORCE_WRITE"), but that could break existing users behind their backs. Let's take the more conservative approach. We can still migrate existing callers to use our new flag. Later we might even be able to flip the default, possibly without entirely ignoring the risk to in-flight or out-of-tree topics. Suggested-by: Jeff King <peff@peff.net> Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>