Re: [PATCH v7 07/17] # This is a combination of 2 commits. # This is the 1st commit message:

On Thu, Apr 19, 2018 at 8:20 AM, Johannes Schindelin wrote: > # This is a combination of 2 commits. # This is the 1st commit message: Botched squash/fixup? > sequencer: introduce the `merge` command > > This patch is part of the effort to reimplement

Re: [PATCH v2 1/2] completion: stop showing 'save' for stash by default

On Fri, Apr 20, 2018 at 1:25 AM, Thomas Gummerer wrote: > The 'save' subcommand in git stash has been deprecated in > fd2ebf14db ("stash: mark "git stash save" deprecated in the man page", > 2017-10-22). > > Stop showing it when the users enters 'git stash ' or 'git stash >

Re: [BUG] Git fast-export with import marks file omits merge commits

On 20 April 2018 at 00:48, Junio C Hamano wrote: > Isaac Chou writes: > >> I inspected the source code (builtin/fast-export.c) for the >> fast-export issue I encountered, and it looks like the merge >> commit is discarded too early by the call to

Re: [PATCH v10 00/36] Add directory rename detection to git

Elijah Newren writes: > On Thu, Apr 19, 2018 at 10:57 AM, Elijah Newren wrote: >> This series is a reboot of the directory rename detection series that was >> merged to master and then reverted due to the final patch having a buggy >> can-skip-update check,

Re: [PATCH v2 0/2] completion: improvements for git stash

Thomas Gummerer writes: > I didn't find a good way to implement "reluctant completion" (I'm also > by no means an expert in bash completion, so there may well be a way I > couldn't find by googl'ing around), so I left that out of this > series. > > I don't think it's

Re: [PATCH v2 3/7] Add a test for `git replace --convert-graft-file`

Johannes Schindelin writes: > 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. The above spreads the

Re: [PATCH v2 2/7] replace: introduce --convert-graft-file

Johannes Schindelin writes: > 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

Re: [PATCH v2 1/7] replace: "libify" create_graft()

Johannes Schindelin writes: > It is quite convenient to simply die() in builtins, in the absence of > proper exception handling, because it allows us to just go belly up > without having to implement error handling chains. > > Of course, for reusable library

Re: Silly "git gc" UI issue.

Simon Ruderich writes: > On Thu, Apr 19, 2018 at 10:52:47AM +0900, Junio C Hamano wrote: >> It turns out that prune silently goes away given a bad expiry >> >> $ git prune --expire=nyah ; echo $? >> 129 > > I noticed that git log --since/--after/--before/--until have

Re: [RFC WIP PATCH] merge: implement -s theirs -X N

Ævar Arnfjörð Bjarmason writes: > On Thu, Apr 19 2018, Junio C. Hamano wrote: > >> This question has nothing to do with your "-s theirs" but let me see >> if I got the above correctly. Suppose you have a deployed branch >> (say, "prod"), all developments happen on "master"

Re: [PATCH] git-send-email: Cc more people

Mathieu Desnoyers writes: >>> I'd further say that these new CC-sources should be disabled by >>> default and made opt-in to avoid surprising existing users. >> >> But I disagree with this. The current behaviour is surprising to >> existing users, to the point

[PATCH v2 2/2] completion: make stash -p and alias for stash push -p

We define 'git stash -p' as an alias for 'git stash push -p' in the manpage. Do the same in the completion script, so all options that can be given to 'git stash push' are being completed when the user is using 'git stash -p --'. Currently the only additional option the user will get is

[PATCH v2 1/2] completion: stop showing 'save' for stash by default

The 'save' subcommand in git stash has been deprecated in fd2ebf14db ("stash: mark "git stash save" deprecated in the man page", 2017-10-22). Stop showing it when the users enters 'git stash ' or 'git stash s'. Keep showing it however when the user enters 'git stash sa' or any more characters of

[PATCH v2 0/2] completion: improvements for git stash

Previous round was at <20180417212945.24002-1-t.gumme...@gmail.com>. Thanks Junio for your input on the previous round. This round drops what was 1/3 in the previous round. We keep completing the options for 'git stash save', so calling the variable 'save_opts' and defining what would be

Re: [PATCH 1/2] daemon: use timeout for uninterruptible poll

Kim Gybels writes: >> > In other words, you scolded Kim for something that this patch did not >> > introduce, but which was already there. > > I didn't feel scolded, just Junio raising a concern about maintainability of > the code. FWIW, I didn't mean to scold, either.

Re: [BUG] Git fast-export with import marks file omits merge commits

Isaac Chou writes: > I inspected the source code (builtin/fast-export.c) for the > fast-export issue I encountered, and it looks like the merge > commit is discarded too early by the call to object_array_pop() > after only one of the two UNSHOWN parents is processed in

Re: [BUG] Git fast-export with import marks file omits merge commits

Hi Isaac, On Thu, Apr 19, 2018 at 2:46 PM, Isaac Chou wrote: > I inspected the source code (builtin/fast-export.c) for the fast-export issue > I encountered, and it looks like the merge commit is discarded too early by > the call to object_array_pop() after only one

Re: Bug Report - Pull remote branch does not retrieve new tags

Andrew, On Thu, Apr 19, 2018 at 6:55 AM, Andrew Ducker wrote: > > What happens: > When I create a new tag on the remote (changing nothing else) > "git pull origin master" produces the following: > From git.internal.company.com:team/testrepo >* branch

RE: [BUG] Git fast-export with import marks file omits merge commits

I inspected the source code (builtin/fast-export.c) for the fast-export issue I encountered, and it looks like the merge commit is discarded too early by the call to object_array_pop() after only one of the two UNSHOWN parents is processed in the method handle_tail(). The poped merge commit

Re: [PATCH v3 1/1] perl: fix installing modules from contrib

Junio C Hamano on Thu, 2018/04/19 06:44: > Christian Hesse writes: > > > Commit 20d2a30f (Makefile: replace perl/Makefile.PL with simple make > > rules) removed a target that allowed Makefiles from contrib/ to get the > > correct install path. This introduces a

Re: [PATCH 1/2] daemon: use timeout for uninterruptible poll

On (19/04/18 06:51), Junio C Hamano wrote: > Johannes Schindelin writes: > > In other words, you scolded Kim for something that this patch did not > > introduce, but which was already there. I didn't feel scolded, just Junio raising a concern about maintainability of

Re: [PATCH v10 25/36] merge-recursive: fix overwriting dirty files involved in renames

On Thu, Apr 19, 2018 at 1:48 PM, Martin Ågren wrote: > On 19 April 2018 at 19:58, Elijah Newren wrote: >> This fixes an issue that existed before my directory rename detection >> patches that affects both normal renames and renames implied by >>

Re: [PATCH v10 25/36] merge-recursive: fix overwriting dirty files involved in renames

On 19 April 2018 at 22:48, Martin Ågren wrote: > On 19 April 2018 at 19:58, Elijah Newren wrote: >> -static int git_merge_trees(int index_only, >> +static int git_merge_trees(struct merge_options *o, >>struct tree *common, >>

Re: [PATCH v10 32/36] t6046: testcases checking whether updates can be skipped in a merge

On Thu, Apr 19, 2018 at 1:26 PM, SZEDER Gábor wrote: > Just a couple of minor things: Sweet, thanks for taking a look; will get these all fixed up.

Re: [PATCH v10 33/36] merge-recursive: fix was_tracked() to quit lying with some renamed paths

On Thu, Apr 19, 2018 at 1:39 PM, Martin Ågren wrote: > On 19 April 2018 at 19:58, Elijah Newren wrote: >> + /* Free the extra index left from git_merge_trees() */ >> + /* >> +* FIXME: Need to also data allocated by >>

Re: [PATCH v10 25/36] merge-recursive: fix overwriting dirty files involved in renames

On 19 April 2018 at 19:58, Elijah Newren wrote: > This fixes an issue that existed before my directory rename detection > patches that affects both normal renames and renames implied by > directory rename detection. Additional codepaths that only affect > overwriting of dirty

Re: [PATCH v10 33/36] merge-recursive: fix was_tracked() to quit lying with some renamed paths

On 19 April 2018 at 19:58, Elijah Newren wrote: > + /* Free the extra index left from git_merge_trees() */ > + /* > +* FIXME: Need to also data allocated by > setup_unpack_trees_porcelain() > +* tucked away in o->unpack_opts.msgs, but the problem is

Re: [PATCH v10 32/36] t6046: testcases checking whether updates can be skipped in a merge

Just a couple of minor things: > +### > +# SECTION 1: Cases involving no renames (one side has subset of changes of > +#the other side) >

Re: [PATCH v10 00/36] Add directory rename detection to git

On Thu, Apr 19, 2018 at 11:35 AM, Elijah Newren wrote: > On Thu, Apr 19, 2018 at 10:57 AM, Elijah Newren wrote: >> This series is a reboot of the directory rename detection series that was >> merged to master and then reverted due to the final patch having a

Re: [PATCH v10 00/36] Add directory rename detection to git

On 4/19/2018 2:41 PM, Stefan Beller wrote: On Thu, Apr 19, 2018 at 11:35 AM, Elijah Newren wrote: On Thu, Apr 19, 2018 at 10:57 AM, Elijah Newren wrote: This series is a reboot of the directory rename detection series that was merged to master and then

Re: [PATCH 01/11] t9902-completion: add tests demonstrating issues with quoted pathnames

On Wed, Apr 18, 2018 at 2:31 PM, Johannes Schindelin wrote: > I suspect that the culprit is once again Cygwin's trick where illegal > characters are mapped into a private Unicode page. Cygwin (and therefore > MSYS2 runtime, and therefore the Bash used to run the test

Re: [PATCH v2 1/1] completion: load completion file for external subcommand

On 2018-04-18 21:51, SZEDER Gábor wrote: On Tue, Apr 10, 2018 at 10:28 PM, Florian Gamböck wrote: Adding external subcommands to Git is as easy as to put an executable file git-foo into PATH. Packaging such subcommands for a Linux distribution can be achieved by unpacking the

Re: [PATCH v10 00/36] Add directory rename detection to git

On Thu, Apr 19, 2018 at 11:35 AM, Elijah Newren wrote: > On Thu, Apr 19, 2018 at 10:57 AM, Elijah Newren wrote: >> This series is a reboot of the directory rename detection series that was >> merged to master and then reverted due to the final patch having a

Re: [PATCH v10 00/36] Add directory rename detection to git

On Thu, Apr 19, 2018 at 10:57 AM, Elijah Newren wrote: > This series is a reboot of the directory rename detection series that was > merged to master and then reverted due to the final patch having a buggy > can-skip-update check, as noted at >

[PATCH v10 12/36] merge-recursive: move the get_renames() function

Move this function so it can re-use some others (without either moving all of them or adding an annoying split between function declarations and definitions). Cheat slightly by adding a blank line for readability, and in order to silence checkpatch.pl. Reviewed-by: Stefan Beller

[PATCH v10 05/36] directory rename detection: files/directories in the way of some renames

Reviewed-by: Stefan Beller Signed-off-by: Elijah Newren Signed-off-by: Junio C Hamano --- t/t6043-merge-rename-directories.sh | 330 1 file changed, 330 insertions(+) diff --git

[PATCH v10 03/36] directory rename detection: testcases to avoid taking detection too far

Reviewed-by: Stefan Beller Signed-off-by: Elijah Newren Signed-off-by: Junio C Hamano --- t/t6043-merge-rename-directories.sh | 153 1 file changed, 153 insertions(+) diff --git

[PATCH v10 11/36] directory rename detection: tests for handling overwriting dirty files

Reviewed-by: Stefan Beller Signed-off-by: Elijah Newren Signed-off-by: Junio C Hamano --- t/t6043-merge-rename-directories.sh | 458 1 file changed, 458 insertions(+) diff --git

[PATCH v10 22/36] merge-recursive: when comparing files, don't include trees

get_renames() would look up stage data that already existed (populated in get_unmerged(), taken from whatever unpack_trees() created), and if it didn't exist, would call insert_stage_data() to create the necessary entry for the given file. The insert_stage_data() fallback becomes much more

[PATCH v10 01/36] directory rename detection: basic testcases

Reviewed-by: Stefan Beller Signed-off-by: Elijah Newren Signed-off-by: Junio C Hamano --- t/t6043-merge-rename-directories.sh | 442 1 file changed, 442 insertions(+) create mode 100755

[PATCH v10 18/36] merge-recursive: add get_directory_renames()

This populates a set of directory renames for us. The set of directory renames is not yet used, but will be in subsequent commits. Note that the use of a string_list for possible_new_dirs in the new dir_rename_entry struct implies an O(n^2) algorithm; however, in practice I expect the number of

[PATCH v10 25/36] merge-recursive: fix overwriting dirty files involved in renames

This fixes an issue that existed before my directory rename detection patches that affects both normal renames and renames implied by directory rename detection. Additional codepaths that only affect overwriting of dirty files that are involved in directory rename detection will be added in a

[PATCH v10 02/36] directory rename detection: directory splitting testcases

Reviewed-by: Stefan Beller Signed-off-by: Elijah Newren Signed-off-by: Junio C Hamano --- t/t6043-merge-rename-directories.sh | 143 1 file changed, 143 insertions(+) diff --git

[PATCH v10 21/36] merge-recursive: check for file level conflicts then get new name

Before trying to apply directory renames to paths within the given directories, we want to make sure that there aren't conflicts at the file level either. If there aren't any, then get the new name from any directory renames. Reviewed-by: Stefan Beller Signed-off-by: Elijah

[PATCH v10 09/36] directory rename detection: miscellaneous testcases to complete coverage

I came up with the testcases in the first eight sections before coding up the implementation. The testcases in this section were mostly ones I thought of while coding/debugging, and which I was too lazy to insert into the previous sections because I didn't want to re-label with all the testcase

[PATCH v10 13/36] merge-recursive: introduce new functions to handle rename logic

The amount of logic in merge_trees() relative to renames was just a few lines, but split it out into new handle_renames() and cleanup_renames() functions to prepare for additional logic to be added to each. No code or logic changes, just a new place to put stuff for when the rename detection

[PATCH v10 04/36] directory rename detection: partially renamed directory testcase/discussion

Add a long note about why we are not considering "partial directory renames" for the current directory rename detection implementation. Reviewed-by: Stefan Beller Signed-off-by: Elijah Newren Signed-off-by: Junio C Hamano ---

[PATCH v10 08/36] directory rename detection: testcases exploring possibly suboptimal merges

Reviewed-by: Stefan Beller Signed-off-by: Elijah Newren Signed-off-by: Junio C Hamano --- t/t6043-merge-rename-directories.sh | 404 1 file changed, 404 insertions(+) diff --git

[PATCH v10 17/36] merge-recursive: make a helper function for cleanup for handle_renames

In anticipation of more involved cleanup to come, make a helper function for doing the cleanup at the end of handle_renames. Rename the already existing cleanup_rename[s]() to final_cleanup_rename[s](), name the new helper initial_cleanup_rename(), and leave the big comment in the code about why

[PATCH v10 06/36] directory rename detection: testcases checking which side did the rename

Reviewed-by: Stefan Beller Signed-off-by: Elijah Newren Signed-off-by: Junio C Hamano --- t/t6043-merge-rename-directories.sh | 336 1 file changed, 336 insertions(+) diff --git

[PATCH v10 10/36] directory rename detection: tests for handling overwriting untracked files

Reviewed-by: Stefan Beller Signed-off-by: Elijah Newren Signed-off-by: Junio C Hamano --- t/t6043-merge-rename-directories.sh | 367 1 file changed, 367 insertions(+) diff --git

[PATCH v10 27/36] directory rename detection: new testcases showcasing a pair of bugs

Add a testcase showing spurious rename/rename(1to2) conflicts occurring due to directory rename detection. Also add a pair of testcases dealing with moving directory hierarchies around that were suggested by Stefan Beller as "food for thought" during his review of an earlier patch series, but

[PATCH v10 15/36] merge-recursive: make !o->detect_rename codepath more obvious

Previously, if !o->detect_rename then get_renames() would return an empty string_list, and then process_renames() would have nothing to iterate over. It seems more straightforward to simply avoid calling either function in that case. Reviewed-by: Stefan Beller Signed-off-by:

[PATCH v10 16/36] merge-recursive: split out code for determining diff_filepairs

Create a new function, get_diffpairs() to compute the diff_filepairs between two trees. While these are currently only used in get_renames(), I want them to be available to some new functions. No actual logic changes yet. Reviewed-by: Stefan Beller Signed-off-by: Elijah

[PATCH v10 28/36] merge-recursive: avoid spurious rename/rename conflict from dir renames

If a file on one side of history was renamed, and merely modified on the other side, then applying a directory rename to the modified side gives us a rename/rename(1to2) conflict. We should only apply directory renames to pairs representing either adds or renames. Making this change means that a

[PATCH v10 30/36] merge-recursive: move more is_dirty handling to merge_content

conflict_rename_normal() was doing some handling for dirty files that more naturally belonged in merge_content. Move it, and rename a parameter for clarity while at it. Signed-off-by: Elijah Newren --- merge-recursive.c | 30 -- 1 file changed, 12

[PATCH v10 23/36] merge-recursive: apply necessary modifications for directory renames

This commit hooks together all the directory rename logic by making the necessary changes to the rename struct, it's dst_entry, and the diff_filepair under consideration. Reviewed-by: Stefan Beller Signed-off-by: Elijah Newren Signed-off-by: Junio C Hamano

[PATCH v10 20/36] merge-recursive: add computation of collisions due to dir rename & merging

directory renaming and merging can cause one or more files to be moved to where an existing file is, or to cause several files to all be moved to the same (otherwise vacant) location. Add checking and reporting for such cases, falling back to no-directory-rename handling for such paths.

[PATCH v10 31/36] merge-recursive: avoid triggering add_cacheinfo error with dirty mod

If a cherry-pick or merge with a rename results in a skippable update (due to the merged content matching what HEAD already had), but the working directory is dirty, avoid trying to refresh the index as that will fail. Signed-off-by: Elijah Newren --- merge-recursive.c

[PATCH v10 35/36] merge-recursive: make "Auto-merging" comment show for other merges

Previously, merge_content() would print "Auto-merging" whenever the final content and mode aren't already available from HEAD. There are a few problems with this: 1) There are other code paths doing merges that should probably have the same message printed, in particular

[PATCH v10 32/36] t6046: testcases checking whether updates can be skipped in a merge

Add several tests checking whether updates can be skipped in a merge. Also add several similar testcases for where updates cannot be skipped in a merge to make sure that we skip if and only if we should. In particular: * Testcase 1a (particularly 1a-check-L) would have pointed out the

[PATCH v10 14/36] merge-recursive: fix leaks of allocated renames and diff_filepairs

get_renames() has always zero'ed out diff_queued_diff.nr while only manually free'ing diff_filepairs that did not correspond to renames. Further, it allocated struct renames that were tucked away in the return string_list. Make sure all of these are deallocated when we are done with them.

[PATCH v10 00/36] Add directory rename detection to git

This series is a reboot of the directory rename detection series that was merged to master and then reverted due to the final patch having a buggy can-skip-update check, as noted at https://public-inbox.org/git/xmqqmuya43cs@gitster-ct.c.googlers.com/ This series based on top of master. This

[PATCH v10 26/36] merge-recursive: fix remaining directory rename + dirty overwrite cases

Reviewed-by: Stefan Beller Signed-off-by: Elijah Newren Signed-off-by: Junio C Hamano --- merge-recursive.c | 25 ++--- t/t6043-merge-rename-directories.sh | 8 2 files changed, 26

[PATCH v10 07/36] directory rename detection: more involved edge/corner testcases

Reviewed-by: Stefan Beller Signed-off-by: Elijah Newren Signed-off-by: Junio C Hamano --- t/t6043-merge-rename-directories.sh | 396 1 file changed, 396 insertions(+) diff --git

[PATCH v10 36/36] merge-recursive: fix check for skipability of working tree updates

The can-working-tree-updates-be-skipped check has had a long and blemished history. The update can be skipped iff: a) The merge is clean b) The merge matches what was in HEAD (content, mode, pathname) c) The target path is usable (i.e. not involved in D/F conflict) Traditionally, we split

[PATCH v10 19/36] merge-recursive: check for directory level conflicts

Before trying to apply directory renames to paths within the given directories, we want to make sure that there aren't conflicts at the directory level. There will be additional checks at the individual file level too, which will be added later. Reviewed-by: Stefan Beller

[PATCH v10 34/36] merge-recursive: fix remainder of was_dirty() to use original index

was_dirty() uses was_tracked(), which has been updated to use the original index rather than the current one. However, was_dirty() also had a separate call to cache_file_exists(), causing it to still implicitly use the current index. Update that to instead use index_file_exists(). Also,

[PATCH v10 33/36] merge-recursive: fix was_tracked() to quit lying with some renamed paths

In commit aacb82de3ff8 ("merge-recursive: Split was_tracked() out of would_lose_untracked()", 2011-08-11), was_tracked() was split out of would_lose_untracked() with the intent to provide a function that could answer whether a path was tracked in the index before the merge. Sadly, it instead

[PATCH v10 24/36] merge-recursive: avoid clobbering untracked files with directory renames

Reviewed-by: Stefan Beller Signed-off-by: Elijah Newren Signed-off-by: Junio C Hamano --- merge-recursive.c | 42 +++-- t/t6043-merge-rename-directories.sh | 6 ++--- 2 files changed, 43

[PATCH v10 29/36] merge-recursive: improve add_cacheinfo error handling

Four closely related changes all with the purpose of fixing error handling in this function: - fix reported function name in add_cacheinfo error messages - differentiate between the two error messages - abort early when we hit the error (stop ignoring return code) - mark a test which was

Re: [RFC PATCH v3 2/2] t7406: add test for non-default branch in submodule

Hi Eddy, > I suspect that in the tests, because the "server side" repos are > local, the git fetch-by-sha1/cloning by hash will be done correctly, > without the need of a branch hint, but the problem will still exist > for servers such as github which do not support fetch-by-sha1. > In case I

squash! Merge branch 'ps/test-chmtime-get'

Junio, you may want to squash this into your merge commit of branch ps/test-chmtime-get (today it is fa57c0871fc9) -- Hannes diff --git a/t/helper/test-chmtime.c b/t/helper/test-chmtime.c index daeddc1cbc..aa22af48c2 100644 --- a/t/helper/test-chmtime.c +++ b/t/helper/test-chmtime.c @@ -25,7

[PATCH] doc/clone: update caption for GIT URLS cross-reference

The description of the argument directs readers to "See the URLS section below". When generating HTML this becomes a link to the "GIT URLS" section. When reading the man page in a terminal, the caption is slightly misleading. Use "GIT URLS" as the caption to avoid any confusion.

Re: [RFC PATCH 04/12] commit-graph: parse commit from chosen graph

Derrick Stolee writes: > Before checking a commit-graph file against the object database, we Actually there is quite a few checks more that can be done without accessing the object database... I'll take a look at later commits why this one is that relatively early in the

Re: [RFC PATCH 03/12] commit-graph: check file header information

Derrick Stolee writes: > During a run of 'git commit-graph check', list the issues with the > header information in the commit-graph file. Some of this information > is inferred from the loaded 'struct commit_graph'. > > Signed-off-by: Derrick Stolee

pujcky

Jsem Ronald Bernstein, jsem úverový dustojník, dávám pujcky jednotlivcum a firme pro obchodní a osobní úcely, kontaktujte me, pokud potrebujete jakýkoliv druh pujcky. Poskytuji pujcky široké verejnosti s úrokovou sazbou 2%.

Re: [RFC PATCH 1/1] completion: Load completion file for external subcommand

On Mon, Apr 9, 2018 at 9:49 PM, Florian Gamböck wrote: > On 2018-04-09 11:26, Stefan Beller wrote: >> If Gits own completion script would be broken up by subcommand, would that >> also deliver an improvement in performance? > > > As it is now, the completion script is quite big. On

Bug Report - Pull remote branch does not retrieve new tags

What happens: When I create a new tag on the remote (changing nothing else) "git pull origin master" produces the following: From git.internal.company.com:team/testrepo * branchmaster -> FETCH_HEAD Already up-to-date. If I instead do a "git pull" I get: From

Re: [RFC PATCH 02/12] commit-graph: add 'check' subcommand

Derrick Stolee writes: > If the commit-graph file becomes corrupt, we need a way to verify > its contents match the object database. In the manner of 'git fsck' > we will implement a 'git commit-graph check' subcommand to report > all issues with the file. Bikeshed:

[PATCH v7 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 v7 14/17] rebase --rebase-merges: avoid "empty merges"

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)

[PATCH v7 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

Re: [PATCH] git-send-email: Cc more people

- On Apr 19, 2018, at 8:10 AM, Matthew Wilcox wi...@infradead.org wrote: > On Thu, Apr 19, 2018 at 06:21:42AM +0900, Junio C Hamano wrote: >> Ævar Arnfjörð Bjarmason writes: >> >> > But IMO this patch is really lacking a few things before being ready: >> > >> > 1. You have

[PATCH v7 15/17] pull: accept --rebase=merges to recreate the branch topology

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.

[PATCH v7 17/17] rebase -i --rebase-merges: add a section to the man page

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 --- Documentation/git-rebase.txt | 132 +++ 1 file changed, 132 insertions(+) diff

[PATCH v7 16/17] rebase -i: introduce --rebase-merges=[no-]rebase-cousins

This one is a bit tricky to explain, so let's try with a diagram: C / \ A - B - E - F \ / D To illustrate what this new mode is all about, let's consider what happens upon `git rebase -i --rebase-merges B`, in particular to the commit `D`. So far, the new branch structure

[PATCH v7 13/17] sequencer: handle post-rewrite for merge commands

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

[PATCH v7 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 v7 12/17] sequencer: make refs generated by the `label` command worktree-local

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 --- refs.c

[PATCH v7 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 v7 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 v7 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 v7 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 v7 07/17] # This is a combination of 2 commits. # This is the 1st commit message:

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

[PATCH v7 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 v7 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 v7 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

[PATCH v7 00/17] rebase -i: offer to recreate commit topology

Once upon a time, I dreamt of an interactive rebase that would not flatten branch structure, but instead recreate the commit topology faithfully. My original attempt was --preserve-merges, but that design was so limited that I did not even enable it in interactive mode. Subsequently, it *was*

Re: [PATCH] git-send-email: Cc more people

On Thu, Apr 19, 2018 at 06:21:42AM +0900, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason writes: > > > But IMO this patch is really lacking a few things before being ready: > > > > 1. You have no tests for this. See t/t9001-send-email.sh for examples, > > ... > > 2. Just a few

  1   2   >