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 `--preserve-merges` with
> a substantially im
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
> s'. Keep showing it ho
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 object_array_pop()
>> after only one of the two UN
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, as noted at
>> https://public-inbox.
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 strictly necessary for the de
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 misconception that the value of the tes
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 | 59 ++-
> 2 f
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 functions, this is a big no-no, so we
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 a
> similar behavior
Æ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" elsewhere that
>> can
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 where people are writing their own
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 '--messag
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
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 'push_o
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.
Rather I was pointing out
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 the
> method handle_tail().
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 of the two UNSHOWN parents i
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
>* branchmaster -> FETCH_HEAD
>
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 sti
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 new target for main Makefile and
>
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
the code.
> > Unless I am m
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
>> directory rename detection. Additional codepaths t
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,
>>struct tree *hea
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.
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
>> setup_unpack_trees_porcelain()
>> +* tucked away i
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 files that are invol
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 that only
> +
Just a couple of minor things:
> +###
> +# SECTION 1: Cases involving no renames (one side has subset of changes of
> +#the other side)
> +###
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 buggy
>> can-skip-update check, as not
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 reverted due to the final patch having a
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 script) can use
> those filen
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 executable into
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 buggy
>> can-skip-update check, as not
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
> https://public-inbox.org/git/xmqqmuya43cs@gitst
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
Signed-off-by: E
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 a/t/t6043-merge-rename-directories.sh
b/t/t6043-merge-rename-directories.sh
index 713a
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 a/t/t6043-merge-rename-directories.sh
b/t/t6043-merge-rename-directories.sh
index b22a
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 a/t/t6043-merge-rename-directories.sh
b/t/t6043-merge-rename-directories.sh
index a6cd
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 importa
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 t/t6043-merge-rename-directories.sh
diff --git a/t/t6043-merge-rename-director
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 d
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 subs
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 a/t/t6043-merge-rename-directories.sh
b/t/t6043-merge-rename-directories.sh
index d045
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 Newren
Signed-off-by
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 re
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
gains
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
---
t/t6043-merge-rename-directories.sh | 115 ++
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 a/t/t6043-merge-rename-directories.sh
b/t/t6043-merge-rename-directories.sh
index 6db1
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 w
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 a/t/t6043-merge-rename-directories.sh
b/t/t6043-merge-rename-directories.sh
index b469
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 a/t/t6043-merge-rename-directories.sh
b/t/t6043-merge-rename-directories.sh
index cbbb
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 whic
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: Elijah Newren
Signe
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 Newren
Signed-off-by: J
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
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 insertions(+), 18 d
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
---
merge-recursive.c
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.
Reviewed-
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 | 2 +-
t/t350
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 rename/rename(2to1
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
probl
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
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.
Reviewe
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 insertions(+), 7 deletions(-)
diff --git a/merge-recursive.c b/me
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 a/t/t6043-merge-rename-directories.sh
b/t/t6043-merge-rename-directories.sh
index 9ae2
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 b
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
Signed-off-by: Elijah N
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, was_dirt
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 retur
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 insertions(+), 5 deletions(-)
diff --git a/merge-recursive.c b/m
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 hi
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 real
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 +25
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.
Signed-off-by:
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 series.
> need to parse
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
> ---
> commit-graph.c | 29
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%.
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 a system with l
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 git.internal.c
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: should the subcommand be call
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 co
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)
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
1 file changed, 16 inser
- 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 no tests for this.
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-
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 --git a/Documentation/git-reb
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
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
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
---
t/t3421-rebase-topology-linear.sh | 1 +
1 file changed, 1 insertion(+)
diff --git a/t/t
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 | 3 ++-
t/t3430-rebase-
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
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
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
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
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 pr
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
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 list.
Signed-off-by: Stefan
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 file changed, 6 insertions(+
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* ena
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 lines down from yo
1 - 100 of 124 matches
Mail list logo