[Octave-bug-tracker] [bug #51333] Reductions on an empty matrix is inconsistent

[Nicholas Jankowski]

Follow-up Comment #11, bug #51333 (project octave):

the two versions of your patch build on each other.  someone cannot apply the
last version of your patch without having applied the first one. Note also
since the two patches you uploaded are named the same thing, it may not be
obvious that one depends on the other. 

It's best when updating a patch to roll back to a clean state, then apply all
of the changes so they are contained in a single patch file.  (sometimes this
also needs to be done to 'refresh' patches in old bug reports that no longer
apply to the current source anymore).

You do not need to reclone the source.  It may not be the best way (others
more experienced can correct/add to my suggestions) but  you can 'rebase' a
patch using 'hg strip' and 'hg patch' commands:

(This assumes you aren't using branches to make changes alonge another 
developmnet line, and also the process will destroy any pending changes you've
made, so don't do it if you have other changes not captured elsewhere,
exported to a patch, etc.)

To get back to the current development tip (where you would be from  a fresh
source clone) 'hg strip -r tip' will step you back one commit at a time. (Note
it will also create backup bundles for recovery unless you use --no-backup,
and that it will stop you if you have any uncommitted edits which you can
override (carefully!) with a -f.) 

depending on how many draft commits you have on your clone, at some point a
summary will show commit: (clean) and update: (current), e.g,:  


$ hg summ
parent: 30992:4ef25c610433 tip
 format: Add 'default' format option (bug #62430)
branch: default
bookmarks: @
commit: (clean)
update: (current)


if you know how far back you have to go, you can specify the revision  to go
back to in the strip command instead of '-r tip'.

from there, 'hg pull' and 'hg update' to be sure you have the latest revision.
 

then, 'hg patch --no-commit <filename>' for the patches you want to apply (in
this case, reapply your first then your second patch).  make any further
changes you want, then do a single 'hg commit' to capture all of the changes,
and 'hg export' a single patch others can use to test your changes.

generally, after exporting and uploading a patch, unless I'm testing further
related changes I will repeat the 'hg strip' of my changes so that the next
thing I'm doing will be based on a clean source. I can always reapply my own
patch as above to make updates or changes. Branches can be a better way to
manage multiple independent tasks as long as you're still generating 'clean'
patches for others to test.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?51333>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/