[PATCH v9 10/17] rebase: introduce the --rebase-merges option

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

[PATCH v9 11/17] rebase --rebase-merges: add test for --keep-empty

From: Phillip Wood 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 ---

[PATCH v9 09/17] rebase-helper --make-script: introduce a flag to rebase merges

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

[PATCH v9 05/17] git-rebase--interactive: clarify arguments

From: Stefan Beller 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

[PATCH v9 04/17] sequencer: offer helpful advice when a command was rescheduled

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 --- sequencer.c | 16

[PATCH v9 00/17] rebase -i: offer to recreate commit topology by rebasing merges

Junio, I think this is now ready for `next`. Thank you for your patience and help with this. Once upon a time, I dreamed of an interactive rebase that would not linearize all patches and drop all merge commits, but instead recreate the commit topology faithfully. My original attempt was

[PATCH v9 07/17] sequencer: introduce the `merge` command

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

[PATCH v9 06/17] sequencer: introduce new commands to reset the revision

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

[PATCH v9 08/17] sequencer: fast-forward `merge` commands, if possible

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.

[PATCH v9 03/17] sequencer: refactor how original todo list lines are accessed

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

[PATCH v9 02/17] sequencer: make rearrange_squash() a bit more obvious

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

[PATCH v9 01/17] sequencer: avoid using errno clobbered by rollback_lock_file()

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 --- sequencer.c | 10 ++ 1

Re: [PATCH v5 09/11] technical/shallow: stop referring to grafts

On 25 April 2018 at 11:54, Johannes Schindelin wrote: > Now that grafts are deprecated, we should start to assume that readers > have no idea what grafts are. So it makes more sense to make the > description of the "shallow" feature stand on its own. > > Suggested-by:

Re: What's cooking in git.git (Apr 2018, #03; Wed, 25)

On Wed, Apr 25 2018, Junio C. Hamano wrote: > THe command line completion (in contrib/) has been taught that "git > * js/colored-push-errors (2018-04-24) 4 commits > - config: document the settings to colorize push errors/hints > - push: test to verify that push errors are colored > - push:

[PATCH v5 10/11] technical/shallow: describe why shallow cannot use replace refs

It is tempting to do away with commit_graft altogether (in the long haul), now that grafts are deprecated. However, the shallow feature needs a couple of things that the replace refs cannot fulfill. Let's point that out in the documentation. Signed-off-by: Johannes Schindelin

[PATCH v5 02/11] commit: Let the callback of for_each_mergetag return on error

This is yet another patch to be filed under the keyword "libification". There is one subtle change in behavior here, where a `git log` that has been asked to show the mergetags would now stop reporting the mergetags upon the first failure, whereas previously, it would have continued to the next

[PATCH v5 04/11] replace: "libify" create_graft() and callees

File this away as yet another patch in the "libification" category. As with all useful functions, in the next commit we want to use create_graft() from a higher-level function where it would be inconvenient if the called function simply die()s: if there is a problem, we want to let the user know

[PATCH v5 05/11] replace: introduce --convert-graft-file

This option is intended to help with the transition away from the now-deprecated graft file. Signed-off-by: Johannes Schindelin --- Documentation/git-replace.txt | 11 ++--- builtin/replace.c | 45 ++- 2 files changed,

[PATCH v5 09/11] technical/shallow: stop referring to grafts

Now that grafts are deprecated, we should start to assume that readers have no idea what grafts are. So it makes more sense to make the description of the "shallow" feature stand on its own. Suggested-by: Eric Sunshine Helped-by: Junio Hamano

[PATCH v5 11/11] Remove obsolete script to convert grafts to replace refs

The functionality is now implemented as `git replace --convert-graft-file`. Signed-off-by: Johannes Schindelin --- contrib/convert-grafts-to-replace-refs.sh | 28 --- 1 file changed, 28 deletions(-) delete mode 100755

[PATCH v5 07/11] Deprecate support for .git/info/grafts

The grafts feature was a convenient way to "stitch together" ancient history to the fresh start of linux.git. Its implementation is, however, not up to Git's standards, as there are too many ways where it can lead to surprising and unwelcome behavior. For example, when pushing from a repository

[PATCH v5 06/11] Add a test for `git replace --convert-graft-file`

The proof, as the saying goes, lies in the pudding. So here is a regression test that not only demonstrates what the option is supposed to accomplish, but also demonstrates that it does accomplish it. Signed-off-by: Johannes Schindelin --- builtin/replace.c | 1 -

[PATCH v5 08/11] filter-branch: stop suggesting to use grafts

The graft file is deprecated now, so let's use replace refs in the example in filter-branch's man page instead. Suggested-by: Eric Sunshine Signed-off-by: Johannes Schindelin --- Documentation/git-filter-branch.txt | 2 +- 1 file changed, 1

[PATCH v5 01/11] argv_array: offer to split a string by whitespace

This is a simple function that will interpret a string as a whitespace delimited list of values, and add those values into the array. Note: this function does not (yet) offer to split by arbitrary delimiters, or keep empty values in case of runs of whitespace, or de-quote Unix shell style. All fo

[PATCH v5 00/11] Deprecate .git/info/grafts

It is fragile, as there is no way for the revision machinery to say "but now I want to traverse the graph ignoring the graft file" e.g. when pushing commits to a remote repository (which, as a consequence, can miss commits). And we already have a better solution with `git replace --graft [...]`.

[PATCH v5 03/11] replace: avoid using die() to indicate a bug

We have the BUG() macro for that purpose. Signed-off-by: Johannes Schindelin --- builtin/replace.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/builtin/replace.c b/builtin/replace.c index 245d3f4164e..e345a5a0f1c 100644 --- a/builtin/replace.c

Re: [PATCH] git: add -N as a short option for --no-pager

On 24/04/18 17:59, Johannes Sixt wrote: In modern setups, less, the pager, uses alternate screen to show the content. When it is closed, it switches back to the original screen, and all content is gone. Are you setting LESS explicitly in the environment? From the git config man page: When

Re: [RFC PATCH] checkout: Force matching mtime between files

"Robin H. Johnson" writes: > In the thread from 6 years ago, you asked about tar's behavior for > mtimes. 'tar xf' restores mtimes from the tar archive, so relative > ordering after restore would be the same, and would only rebuild if the > original source happened to be

Re: [RFC PATCH] checkout: Force matching mtime between files

On Mon, Apr 23 2018, Junio C. Hamano wrote: > "Robin H. Johnson" writes: > >> On Fri, Apr 13, 2018 at 07:01:29PM +0200, Michał Górny wrote: >>> Currently git does not control mtimes of files being checked out. This >>> means that the only assumption you could make is that

What's cooking in git.git (Apr 2018, #03; Wed, 25)

Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. The ones marked with '.' do not appear in any of the integration branches, but I am still holding onto them. You can find the changes

Re: [PATCH v1 1/2] merge: Add merge.renames config setting

Hi Elijah, On Tue, 24 Apr 2018, Elijah Newren wrote: > On Tue, Apr 24, 2018 at 4:58 AM, Johannes Schindelin > wrote: > > > > On Tue, 24 Apr 2018, Junio C Hamano wrote: > > > >> Yeah, but as opposed to passing "oh, let's see if we can get a > >> reasonable result

Re: [PATCH v2 0/3] Some add-on patches on top of dj/runtime-prefix

Hi Junio, On Wed, 25 Apr 2018, Junio C Hamano wrote: > I really want to see that the runtime prefix stuff mature enough during > this cycle, so these follow-up patches are all very much appreciated. FWIW I merged these patches (including my touch-ups) into Git for Windows' `master` branch

Re: [PATCH] git: add -N as a short option for --no-pager

Hi Hannes, On Wed, 25 Apr 2018, Johannes Sixt wrote: > Am 25.04.2018 um 02:05 schrieb Junio C Hamano: > > Johannes Sixt writes: > > > It is not uncommon to request that the output remains visible in > > > the terminal. I ran `git log` and then hit `q`, and the latest screen

Re: [PATCH v3] Make running git under other debugger-like programs easy

Hi Elijah, On Tue, 24 Apr 2018, Elijah Newren wrote: > This allows us to run git, when using the script from bin-wrappers, under > other programs. A few examples for usage within testsuite scripts: > >debug git checkout master >debug --debugger=nemiver git $ARGS >debug -d "valgrind

Re: [PATCH v3 09/11] technical/shallow: describe the relationship with replace refs

Hi Philip & Junio, On Wed, 25 Apr 2018, Junio C Hamano wrote: > "Philip Oakley" writes: > > > Perhaps something like: > > +$GIT_DIR/shallow, and handle its contents similar to replace > > +refs (with the difference that shallow does not actually > > +create those replace

Re: [RFC PATCH] checkout: Force matching mtime between files

On Tue, Apr 24, 2018 at 08:41:07AM +0900, Junio C Hamano wrote: > "Robin H. Johnson" writes: > > > On Fri, Apr 13, 2018 at 07:01:29PM +0200, Michał Górny wrote: > >> Currently git does not control mtimes of files being checked out. This > >> means that the only assumption

Re: [RFC PATCH] checkout: Force matching mtime between files

W dniu śro, 25.04.2018 o godzinie 06∶58 +, użytkownik Robin H. Johnson napisał: > On Fri, Apr 13, 2018 at 07:01:29PM +0200, Michał Górny wrote: > > --- a/entry.c > > +++ b/entry.c > > @@ -411,6 +411,7 @@ int checkout_entry(struct cache_entry *ce, > > { > > static struct strbuf path =

Re: [PATCH v4 04/11] replace: "libify" create_graft() and callees

Hi Stefan, On Tue, 24 Apr 2018, Stefan Beller wrote: > On Tue, Apr 24, 2018 at 11:51 AM, Johannes Schindelin > wrote: > > > > > Oy vey. How many more mistakes can I introduce in one commit... > > > > I ask this myself all the time, but Software is hard when not

Re: [RFC PATCH] checkout: Force matching mtime between files

On Fri, Apr 13, 2018 at 07:01:29PM +0200, Michał Górny wrote: > --- a/entry.c > +++ b/entry.c > @@ -411,6 +411,7 @@ int checkout_entry(struct cache_entry *ce, > { > static struct strbuf path = STRBUF_INIT; > struct stat st; > + int ret; > > if (topath) >

Re: GSoC students and mentors in 2018

Hi Paul, On Wed, 25 Apr 2018, Paul-Sebastian Ungureanu wrote: > It is a pleasure and an honor for me to take part in Google Summer of > Code. I am sure it will be a exciting summer and I will definitely give > 100% to successfully fulfill 'git stash' project! I am excited, too, and really glad

Re: [PATCH] git: add -N as a short option for --no-pager

Am 25.04.2018 um 02:05 schrieb Junio C Hamano: Johannes Sixt writes: It is not uncommon to request that the output remains visible in the terminal. For this, the option --no-pager can be used. But it is a bit cumbersome to type, even when command completion is available. Provide

<    1   2