[petsc-users] MatMPIBAIJSetPreallocationCSR i and j indices

[Jed Brown]

Barry Smith <bsmith at mcs.anl.gov> writes:

>    I am fine with this. In fact I would go ahead and make the change
>    in the branch I already made exactly for this work. Sadly, git
>    allowed me to fuck up the branch so I cannot easily work on that
>    branch since it empty, if only git could have warned me I was
>    fucking up…..

You can still create a new branch and we can merge later so that it
looks like your current commit had been in the branch all along,
provided we merge it to 'maint' before merging something else there.

(maint) $ git checkout -b barry/new-branch
        ... make changes, commit ...

        discuss, merge to 'next', decide branch is good

        $ git checkout maint
(maint) $ git reset --hard HEAD^   # move local 'maint' back to before this commit
(maint) $ git merge --no-ff barry/new-branch

The original commit is still an ancestor of the merge (just not via
first-parent) so the resulting push will still fast-forward.

Hold off on the above if you're not confident about what the steps are
doing.

> I actually got to the stage of pushing my branch to the repository,
> then I went to bitbucket.org/petsc/petsc to make the pull request of
> my branch to next (where you could have made all these suggestions in
> an organized way) when I realized the branch wasn't in the repository
> because I forgot to check it out after making it. 

You can reset the branch marker at that time.  I would have done

(maint) $ git branch barry/the-branch              # create branch, but forget to check it out
... edit ...
(maint) $ git commit -am'commit intended for barry/the-branch, but made in maint'
(maint) $ git push -u origin barry/the-branch

... look on bitbucket and notice barry/the-branch is at an old commit ...

(maint) $ git branch -f barry/the-branch HEAD   # move barry/the-branch to where I am now
(maint) $ git reset --hard HEAD^                # move (unpushed) 'maint' back before this commit

        $ git push origin barry/the-branch

> If this sad story doesn't make you realize git having optional
> enforceable policies and warnings are a good thing then I guess
> nothing will and we'll continue to limp along with constant mistakes,
> not caught by simple tests, slowing down our productivity.

I'm just not convinced the tests are simple, and maintaining buggy and
incomplete validators sounds more confusing than using the tools right
the first time.  If you know how to do it reliably and simply enough
that the failure modes are reasonable, then let's write these things.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20130929/840f84f7/attachment.pgp>