Commits
- Commit:
f4ab0e5770b96257cb1a43cfe292daa54f2b402e
- From:
- Stefan Sperling <stsp@stsp.name>
- Date:
make 'got status' display interrupted rebase, histedit, and merge operations
When an operation is interrupted add a trailing message to status output
which displays the operation and branches involved.
This information will be useful when diagnosing problem reports and it
helps new users with contextualizing multi-operation work tree state.
ok op@
- Commit:
e12cc036c3e7a71d71bb6a83a9a97bd53f5ba497
- From:
- Stefan Sperling <stsp@stsp.name>
- Date:
make 'got rebase' find a merge base with topological sorting if needed
Fixes a problematic case of spurious conflicts encountered by
naddy@ on landry's firefox package git repository.
The current implementation of toposort is expensive, so this might
make rebase appear to run slowly on large repositories. However,
this is better than letting users deal with spurious conflicts.
ok op@
- Commit:
102fba8b84c74851ac56ae5a99a5739e2a4b2514
- From:
- Stefan Sperling <stsp@stsp.name>
- Date:
add an xfail test for a case where rebase fails to forward a branch
Because 'got rebase' only does a first-parent traversal it will try to
rebase commits which appear in the history of a branch, even when the
branch to be rebased is already based on that history. This results in
spurious merge conflicts as existing changes get re-applied.
The desired behaviour would be that 'got rebase' forwards the branch,
as it does when the 'got merge -M' command used by this test case is
replaced by a simple 'got merge' which avoids creating a merge commit.
Problem reported by naddy in the "Landry's firefox repository" thread:
https://marc.gameoftrees.org/mail/1706721001.20565_0.html
- Commit:
4cbe2b468089c3a0d8cc4963ef0056060b82049a
- From:
- Stefan Sperling <stsp@stsp.name>
- Date:
add a test which checks what happens when rebasing onto a merge commit
- Commit:
13cd1d190795ee2b0bd10c7e4590dac2900cc248
- From:
- Stefan Sperling <stsp@stsp.name>
- Date:
add a test which checks what happens when a merge commit is rebased
- Commit:
f73bf5bd9e54af999a744c731dfb492e1c9b2b6d
- From:
- Christian Weisgerber <naddy@mips.inka.de>
- Date:
replace "(cd path && git cmd)" with "git -C path cmd"
This matches the existing use of "got -r path cmd" and
"git_commit path args".
- Commit:
af179be739cacd6576fdf9596ac7e61b714ee367
- From:
- Stefan Sperling <stsp@stsp.name>
- Date:
when aborting rebase/histedit/merge, unlink files added by merged changes
Otherwise we leave unversioned files behind in the work tree which may
interfere with new attempts to rebase or merge the changes again.
Problem found by + ok naddy@
- Commit:
1b093d84c1f8f17f66aec3a337a121edcc6f77d9
- From:
- Stefan Sperling <stsp@stsp.name>
- Date:
fix rebase/histedit -a leaving some files on the temporary branch
The commands 'got rebase -a' and 'got histedit -a' were checking out
files from the wrong commit. Make them check files out from the commit
we are switching the work tree to, as intended.
Avoids spurious merge conflicts when the work tree is later used for
another rebase operation. It also makes 'got update' right after
'rebase -a' a no-op, as it should be.
Problem found by naddy@ while rebasing jca's llvm15 branch
ok op, jamsek earlier version
- Commit:
885e96dfba200f362ddd1d9795740251bcb6e39b
- From:
- Christian Weisgerber <naddy@mips.inka.de>
- Date:
regress: replace "sed -i" with ed(1) for portable in-place editing
"sed -i" is fundamentally unportable. GNU and OpenBSD sed(1) treat
the extension for the backup file as an optional argument and use
"sed -i" for no backup file. FreeBSD sed(1) treats the extension
as an obligatory argument and uses "sed -i ''" for no backup file.
There is no single syntax that works for both.
ok stsp op
- Commit:
980c6786a419950816c67eb1b53e021ebdfe483c
- From:
- Stefan Sperling <stsp@stsp.name>
- Date:
make 'got rebase' work when the to-be-rebased branch has no parent commit
found by and ok op@, who also provided the test case
- Commit:
49a1ae4b7fbd435b06a58d71186f4675d399e2c7
- From:
- Stefan Sperling <stsp@stsp.name>
- Date:
fix 'got rebase' not detecting an out-of-date work tree in some cases
ok jamsek, op
- Commit:
b2b3fce13e4eca588bb28a869b07f0063568b505
- From:
- Omar Polo <op@omarpolo.com>
- Date:
respect umask when creating or changing files and directories
This behaviour is already documented in got-worktree(5) but wasn't
actually implemented.
ok stsp@
- Commit:
2c75f174eaa5edecfcf15dd4e81c87a70c53b21e
- From:
- Christian Weisgerber <naddy@mips.inka.de>
- Date:
rebase.sh: remove accidentally included absolute path to "got"
- Commit:
0a706d22c0eedf209fc5cc5821872ac9b47ecfd4
- From:
- Stefan Sperling <stsp@stsp.name>
- Date:
add regression test which covers fast-forward rebase + path-prefix
- Commit:
442ede73eadb025cdc45bede186bf31aee869dad
- From:
- Stefan Sperling <stsp@stsp.name>
- Date:
forbid rebase of references outside the refs/heads/ namespace
ok jrick