mirror of http://darcs.net/screened (fork of darcs's darcs-reviewed) (http://darcs.net/Development/GettingStarted)

Make the rebase changes output more user-friendly

ganeshMon Oct 27 22:28:56 UTC 2014

resolve conflicts

ganeshSat Oct 25 17:11:46 UTC 2014

add a unit test for RebaseChange

This also involves adding some infrastructure for rebase unit tests

ganeshMon Mar 18 07:34:47 UTC 2013

resolve conflicts

ganeshSat Oct 25 16:07:29 UTC 2014

change/add various Show instances to ones that produce Haskell code

The existing instances are only used for diagnostic output in the test harness.

This change helps with using the instances in ghci for debugging and experimentation.

The instances aren't always as trivial as deriving Show or the equivalent, because of constructors that aren't exposed or whose names are ambiguous, but that's the starting point.

ganeshFri Mar 15 18:20:33 UTC 2013

stop using custom Show instance on PatchInfo

ganeshFri Mar 15 07:36:03 UTC 2013

rebase changes: delegate listConflictedFiles etc instead of using default

The default doesn't do the right thing with duplicates so V2 patches where the 'fixup' is the inverse of the 'toedit' patch aren't reported as conflicts.

ganeshTue Mar 12 07:05:43 UTC 2013

abstract code for treating RebaseChange as a merge

ganeshTue Mar 12 07:05:43 UTC 2013

resolve conflicts

ganeshSat Oct 25 16:00:30 UTC 2014

initial version of 'rebase changes' command

ganeshMon Mar 11 18:24:15 UTC 2013

introduce a new type class for patch matching

The class has more requirements than Patchy, but fewer than RepoPatch.

ganeshThu Feb 21 07:21:22 UTC 2013

resolve conflict (getChangesInfo flag changes and renaming)

ganeshFri Oct 24 17:18:39 UTC 2014

make getChangesInfo take specific flags only

ganeshTue Feb 19 00:50:14 UTC 2013

resolve conflicts (getChangesInfo renaming and refactoring)

ganeshSun Dec 1 20:05:50 UTC 2013

resolve conflicts (addition of diff algorithm and getChangesInfo refactoring)

ganeshThu Nov 28 07:05:54 UTC 2013

make getChangesInfo take a PatchFilter instead of a Repository

ganeshMon Feb 18 23:47:25 UTC 2013

fix warning

ganeshFri Oct 24 07:14:02 UTC 2014

reduce dependencies for Named/PatchInfoAnd Patchy instances

ganeshMon Feb 25 07:03:07 UTC 2013

drop unnecessary UndecidableInstances

ganeshTue Feb 26 07:28:49 UTC 2013

resolve conflict in improved 'darcs replace' message

ganeshFri Oct 24 07:14:12 UTC 2014

improve message from force-replace

ganeshTue Aug 20 05:47:35 UTC 2013

bundle up checking for patch index and using it

ganeshMon Feb 18 23:33:21 UTC 2013

tweaks to rebase help strings

ganeshWed Feb 20 18:04:22 UTC 2013

resolve issue2409: implement darcs rebase apply

ganeshWed Oct 22 07:34:48 UTC 2014

switch applyCmd to use the PatchApplier abstraction

ganeshWed Oct 22 00:55:42 UTC 2014

reuse the standard pullCmd for rebase

This involves a rather complicated abstraction that would be major overkill for the approximately 6 lines of copy and pasted code that it saves.

However it should extend to applyCmd, which is substantially bigger.

ganeshWed Oct 22 00:22:50 UTC 2014

generalise applyPatchesForRebase along the same lines as applyPatches

ganeshTue Oct 21 19:55:33 UTC 2014

add --no-minimize flag to fix broken tests

ghThu Oct 23 14:00:32 UTC 2014

resolve issue2403: need to avoid moving the rebase patch to the end

This bug is a pretty good example of why the "rebase internal patch" is a rather nasty hack - see 'Note [Rebase representation]' in src/Darcs/Patch/Rebase.hs

ganeshTue Oct 21 18:24:11 UTC 2014

Share applyPatches code between pull and apply

Abstract the applyPatches function from the apply command, and make pull use it.

This means the following changes to apply:

  • The outcome is now displayed using 'putInfo', which means it will respect options like '-q' where it didn't before. This seems reasonable.

It means the following changes to pull:

  • We now call 'setEnvDarcsPatches'. This seems reasonable.

  • We now call 'withSignalsBlocked' when applying patches. I think this is harmless or an improvement.

  • The output messages are a bit more generic, but I don't think any important detail is lost.

  • We now call 'redirectOutput' around the messages. --reply isn't passed to pull so this should make no difference.

ganeshTue Oct 21 16:08:25 UTC 2014