summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2018-06-19t3404: check root commit in 'rebase -i --root reword root commit'Libravatar Todd Zullinger1-1/+2
When testing a reworded root commit, ensure that the squash-onto commit which is created and amended is still the root commit. Suggested-by: Phillip Wood <phillip.wood@talktalk.net> Helped-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Todd Zullinger <tmz@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-18rebase --root: fix amending root commit messagesLibravatar Johannes Schindelin2-2/+2
The code path that triggered that "BUG" really does not want to run without an explicit commit message. In the case where we want to amend a commit message, we have an *implicit* commit message, though: the one of the commit to amend. Therefore, this code path should not even be entered. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-18rebase --root: demonstrate a bug while amending root commit messagesLibravatar Todd Zullinger1-0/+9
When splitting a repository, running `git rebase -i --root` to reword the initial commit, Git dies with BUG: sequencer.c:795: root commit without message. Signed-off-by: Todd Zullinger <tmz@pobox.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-06rebase -i --root: let the sequencer handle even the initial partLibravatar Johannes Schindelin3-10/+19
In this developer's earlier attempt to accelerate interactive rebases by converting large parts from Unix shell script into portable, performant C, the --root handling was specifically excluded (to simplify the task a little bit; it still took over a year to get that reduced set of patches into Git proper). This patch ties up that loose end: now only --preserve-merges uses the slow Unix shell script implementation to perform the interactive rebase. As the rebase--helper reports progress to stderr (unlike the scripted interactive rebase, which reports it to stdout, of all places), we have to adjust a couple of tests that did not expect that for `git rebase -i --root`. This patch fixes -- at long last! -- the really old bug reported in 6a6bc5bdc4d (add tests for rebasing root, 2013-06-06) that rebasing with --root *always* rewrote the root commit, even if there were no changes. The bug still persists in --preserve-merges mode, of course, but that mode will be deprecated as soon as the new --rebase-merges mode stabilizes, anyway. 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 Schindelin2-3/+125
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-04-26rebase -i --rebase-merges: add a section to the man pageLibravatar Johannes Schindelin1-0/+135
The --rebase-merges mode is probably not half as intuitive to use as its inventor hopes, so let's document it some. 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 Schindelin7-6/+59
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-26pull: accept --rebase=merges to recreate the branch topologyLibravatar Johannes Schindelin5-10/+38
Similar to the `preserve` mode simply passing the `--preserve-merges` option to the `rebase` command, the `merges` mode simply passes the `--rebase-merges` option. This will allow users to conveniently rebase non-trivial commit topologies when pulling new commits, without flattening them. 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 Schindelin2-0/+15
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 Schindelin2-1/+29
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-26sequencer: make refs generated by the `label` command worktree-localLibravatar Johannes Schindelin2-1/+16
This allows for rebases to be run in parallel in separate worktrees (think: interrupted in the middle of one rebase, being asked to perform a different rebase, adding a separate worktree just for that job). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-26rebase --rebase-merges: add test for --keep-emptyLibravatar Phillip Wood1-0/+1
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 being pruned. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-26rebase: introduce the --rebase-merges optionLibravatar Johannes Schindelin5-2/+207
Once upon a time, this here developer thought: wouldn't it be nice if, say, Git for Windows' patches on top of core Git could be represented as a thicket of branches, and be rebased on top of core Git in order to maintain a cherry-pick'able set of patch series? The original attempt to answer this was: git rebase --preserve-merges. However, that experiment was never intended as an interactive option, and it only piggy-backed on git rebase --interactive because that command's implementation looked already very, very familiar: it was designed by the same person who designed --preserve-merges: yours truly. Some time later, some other developer (I am looking at you, Andreas! ;-)) decided that it would be a good idea to allow --preserve-merges to be combined with --interactive (with caveats!) and the Git maintainer (well, the interim Git maintainer during Junio's absence, that is) agreed, and that is when the glamor of the --preserve-merges design started to fall apart rather quickly and unglamorously. The reason? In --preserve-merges mode, the parents of a merge commit (or for that matter, of *any* commit) were not stated explicitly, but were *implied* by the commit name passed to the `pick` command. This made it impossible, for example, to reorder commits. Not to mention to move commits between branches or, deity forbid, to split topic branches into two. Alas, these shortcomings also prevented that mode (whose original purpose was to serve Git for Windows' needs, with the additional hope that it may be useful to others, too) from serving Git for Windows' needs. Five years later, when it became really untenable to have one unwieldy, big hodge-podge patch series of partly related, partly unrelated patches in Git for Windows that was rebased onto core Git's tags from time to time (earning the undeserved wrath of the developer of the ill-fated git-remote-hg series that first obsoleted Git for Windows' competing approach, only to be abandoned without maintainer later) was really untenable, the "Git garden shears" were born [*1*/*2*]: a script, piggy-backing on top of the interactive rebase, that would first determine the branch topology of the patches to be rebased, create a pseudo todo list for further editing, transform the result into a real todo list (making heavy use of the `exec` command to "implement" the missing todo list commands) and finally recreate the patch series on top of the new base commit. That was in 2013. And it took about three weeks to come up with the design and implement it as an out-of-tree script. Needless to say, the implementation needed quite a few years to stabilize, all the while the design itself proved itself sound. With this patch, the goodness of the Git garden shears comes to `git rebase -i` itself. Passing the `--rebase-merges` option will generate a todo list that can be understood readily, and where it is obvious how to reorder commits. New branches can be introduced by inserting `label` commands and calling `merge <label>`. And once this mode will have become stable and universally accepted, we can deprecate the design mistake that was `--preserve-merges`. Link *1*: https://github.com/msysgit/msysgit/blob/master/share/msysGit/shears.sh Link *2*: https://github.com/git-for-windows/build-extra/blob/master/shears.sh 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 Schindelin3-2/+349
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 Schindelin2-0/+204
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 Schindelin2-7/+208
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-26git-rebase--interactive: clarify argumentsLibravatar Stefan Beller1-7/+7
Up to now each command took a commit as its first argument and ignored the rest of the line (usually the subject of the commit) Now that we are about to introduce commands that take different arguments, clarify each command by giving the argument list. Signed-off-by: Stefan Beller <sbeller@google.com> 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-25The fourth batch for 2.18Libravatar Junio C Hamano1-0/+78
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25Merge branch 'jm/mem-pool'Libravatar Junio C Hamano4-61/+106
An reusable "memory pool" implementation has been extracted from fast-import.c, which in turn has become the first user of the mem-pool API. * jm/mem-pool: mem-pool: move reusable parts of memory pool into its own file fast-import: introduce mem_pool type fast-import: rename mem_pool type to mp_block
2018-04-25Merge branch 'tg/use-git-contacts'Libravatar Junio C Hamano1-2/+2
Doc update. * tg/use-git-contacts: SubmittingPatches: mention the git contacts command
2018-04-25Merge branch 'sb/filenames-with-dashes'Libravatar Junio C Hamano42-45/+45
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 'cc/perf-bisect'Libravatar Junio C Hamano3-10/+166
Performance measuring framework in t/perf learned to help bisecting performance regressions. * cc/perf-bisect: t/perf: add scripts to bisect performance regressions perf/run: add --subsection option
2018-04-25Merge branch 'bp/fsmonitor-prime-index'Libravatar Junio C Hamano1-0/+3
The index file is updated to record the fsmonitor section after a full scan was made, to avoid wasting the effort that has already spent. * bp/fsmonitor-prime-index: fsmonitor: force index write after full scan
2018-04-25Merge branch 'bp/fsmonitor-bufsize-fix'Libravatar Junio C Hamano1-1/+1
Fix an unexploitable (because the oversized contents are not under attacker's control) buffer overflow. * bp/fsmonitor-bufsize-fix: fsmonitor: fix incorrect buffer size when printing version number
2018-04-25Merge branch 'cb/bash-completion-ls-files-processing'Libravatar Junio C Hamano1-6/+1
Shell completion (in contrib) that gives list of paths have been optimized somewhat. * cb/bash-completion-ls-files-processing: completion: improve ls-files filter performance
2018-04-25Merge branch 'es/worktree-docs'Libravatar Junio C Hamano1-9/+9
Doc updates. * es/worktree-docs: git-worktree.txt: unify command-line prompt in example blocks git-worktree.txt: recommend 'git worktree remove' over manual deletion
2018-04-25Merge branch 'es/fread-reads-dir-autoconf-fix'Libravatar Junio C Hamano1-1/+1
Small fix to the autoconf build procedure. * es/fread-reads-dir-autoconf-fix: configure.ac: fix botched FREAD_READS_DIRECTORIES check
2018-04-25Merge branch 'ps/test-chmtime-get'Libravatar Junio C Hamano10-42/+63
Test cleanup. * ps/test-chmtime-get: t/helper: 'test-chmtime (--get|-g)' to print only the mtime
2018-04-25Merge branch 'js/t5404-path-fix'Libravatar Junio C Hamano1-1/+1
Test fix. * js/t5404-path-fix: t5404: relax overzealous test
2018-04-25Merge branch 'jk/ref-array-push'Libravatar Junio C Hamano4-14/+36
API clean-up aournd ref-filter code. * jk/ref-array-push: ref-filter: factor ref_array pushing into its own function ref-filter: make ref_array_item allocation more consistent ref-filter: use "struct object_id" consistently
2018-04-25Merge branch 'en/doc-typoes'Libravatar Junio C Hamano7-8/+8
Docfix. * en/doc-typoes: Documentation: normalize spelling of 'normalised' Documentation: fix several one-character-off spelling errors
2018-04-25Merge branch 'lw/daemon-log-destination'Libravatar Junio C Hamano1-1/+1
Recent introduction of "--log-destination" option to "git daemon" did not work well when the daemon was run under "--inetd" mode. * lw/daemon-log-destination: daemon.c: fix condition for redirecting stderr
2018-04-25Merge branch 'mn/send-email-credential-doc'Libravatar Junio C Hamano1-10/+6
Doc update. * mn/send-email-credential-doc: send-email: simplify Gmail example in the documentation
2018-04-25Merge branch 'ak/bisect-doc-typofix'Libravatar Junio C Hamano1-2/+2
Docfix. * ak/bisect-doc-typofix: Documentation/git-bisect.txt: git bisect term → git bisect terms
2018-04-25Merge branch 'br/mergetools-guiffy'Libravatar Junio C Hamano1-0/+18
"git mergetools" learned talking to guiffy. * br/mergetools-guiffy: mergetools: add support for guiffy
2018-04-25Merge branch 'nd/worktree-move'Libravatar Junio C Hamano1-4/+3
Test update. * nd/worktree-move: t2028: tighten grep expression to make "move worktree" test more robust
2018-04-25Merge branch 'ks/branch-list-detached-rebase-i'Libravatar Junio C Hamano2-4/+32
"git branch --list" during an interrupted "rebase -i" now lets users distinguish the case where a detached HEAD is being rebased and a normal branch is being rebased. * ks/branch-list-detached-rebase-i: t3200: verify "branch --list" sanity when rebasing from detached HEAD branch --list: print useful info whilst interactive rebasing a detached HEAD
2018-04-25Merge branch 'jk/t5561-missing-curl'Libravatar Junio C Hamano2-2/+12
Test fixes. * jk/t5561-missing-curl: t5561: skip tests if curl is not available t5561: drop curl stderr redirects
2018-04-25Merge branch 'bw/commit-partial-from-subdirectory-fix'Libravatar Junio C Hamano2-2/+13
"cd sub/dir && git commit ../path" ought to record the changes to the file "sub/path", but this regressed long time ago. * bw/commit-partial-from-subdirectory-fix: commit: allow partial commits with relative paths
2018-04-25Merge branch 'jk/relative-directory-fix'Libravatar Junio C Hamano11-17/+223
Some codepaths, including the refs API, get and keep relative paths, that go out of sync when the process does chdir(2). The chdir-notify API is introduced to let these codepaths adjust these cached paths to the new current directory. * jk/relative-directory-fix: refs: use chdir_notify to update cached relative paths set_work_tree: use chdir_notify add chdir-notify API trace.c: export trace_setup_key set_git_dir: die when setenv() fails
2018-04-25Merge branch 'jk/flockfile-stdio'Libravatar Junio C Hamano1-3/+5
Code clean-up. * jk/flockfile-stdio: config: move flockfile() closer to unlocked functions
2018-04-25Merge branch 'pw/rebase-signoff'Libravatar Junio C Hamano8-57/+114
"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 Hamano3-3/+11
"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-25Merge branch 'cb/git-gui-ttk-style'Libravatar Junio C Hamano1-5/+10
"git gui" has been taught to work with old versions of tk (like 8.5.7) that do not support "ttk::style theme use" as a way to query the current theme. * cb/git-gui-ttk-style: git-gui: workaround ttk:style theme use