[petsc-dev] [petsc-users] petsc git next branch *is* unwound!

[Satish Balay]

I believe the workflow used by petsc is same as what most projects
with git do - so there is nothing special about it.

Try 'man gitworkflows'

I think your reason for using next is flawed (you get more bugs than
bugfixes on next - as its an integration branch - and features are
merged here for testing purposes). But if thats what you want to do -
thats fine. We can benift with the extra testing that you are now
providing on next. And I believe git gives you tools to manage
whatever workflow you choose.

Generally we don't branch off next. New branches are created from
master (or maint). This works well for new features workflow (or bug
fix workflow).

In your case - you'd like to maintain 'wdn_mods_next' branch - which
is 'next' + local fixes that are specific to next (and not shared
across other branches - like master). And these fixes are next
specific - hence you want this branch to start off next. Presumably
this is low over head stuff - and don't need permanant history for
this (as we usually do with feature branches)

For the above requirement - currently you do:

a. branch wdn_mods_next from next
b. add local commits in this branch
c. merge latest next into wdn_mods_next. (as needed)

Alternative is to use 'git rebase' to manage your local commits.  This
is not critical - but it lets you keep track of them more sanely.

<rebase local commits over latest next>
git checkout next
git pull
git checkout wdn_mods_next
git rebase next

[also check 'git rebase -i']

In the present situation - when next is unwound - you have to unwind
and recreate wdn_mods_next. For this you'd like to extract your
current modifications from wdn_mods_next - and apply to a new
wdn_mods_next branch.

<First step is to backup current wdn_mods_next. i.e:>
git checkout wdn_mods_next
git checkout -b wdn_mods_next-oct-2014

<Now reset wdn_mods_next to current next>
git checkout wdn_mods_next
git reset --hard next # assuming you've already reset 'next' to latest

<check previous local modifications>
git log origin/next-oct-2014..wdn_mods_next-oct-2014
git diff origin/next-oct-2014..wdn_mods_next-oct-2014

Now you can 'git cherrypick' the commits you need [from the above
list] or grab the above diff - and apply to dn_mods_next(new) branch. for eg:

git diff origin/next-oct-2014..wdn_mods_next-oct-2014 > my_changes
patch -Np1 < my_changes
<resolve patch conflicts manually>
git commit

Satish

On Fri, 10 Oct 2014, Nystrom, William David wrote:

> Jed,
> 
> I don't think your reply below really does what I want to do.  My wdn_mods_next branch is
> a branch that I maintain that was derived from the next branch.  I do not merge changes
> from wdn_mods_next into the next branch.  The next branch is supposed to be a mirror of
> the official petsc next branch and I only update the next branch in my petsc clones by first
> performing a "git remote -v update origin" in my bare mirror repo which mirrors the petsc maint,
> master and next branches as well as containing any additional branches that I create.
> 
> So, I update wdn_mods_next from the latest copy of next that I have by using the following
> command:
> 
> git pull origin next
> 
> in the petsc directory where I have wdn_mods_next checked out.  Generally this is easy and
> has no conflicts to resolve but on a rare occasion, I might have to resolve a conflict.  This is
> because my wdn_mods_next branch does not differ much from next - just a few hacks I have
> had to resort to.
> 
> So here is one way I think I could accomplish my goal.  In my bare, mirror repo execute
> 
> git remote -v update origin
> 
> At this point my bare mirror repo now has a copy of the new unwound next branch - if I am
> understanding correctly.
> 
> Then in a clone of my mirror repo execute
> 
> git checkout wdn_mods_next
> git reset --hard next
> git push origin +wdn_mods_next
> 
> If I understand correctly, then my wdn_mods_next branch would be identical to the next
> branch and I would not have the changes I made to next that resulted in wdn_mods_next.
> 
> Then I could untar a file of those changes on top of my clone with wdn_mods_next checked
> out and recommit those changes.  This is about half a dozen files.  But this seems like a
> hacky way to do business that is only reasonable because I have a small number of files.
> 
> Isn't there a better way to do this?
> 
> Perhaps you or Satish might ask why I am using next instead of master.  The reason is that
> I am forever uncovering some bug in petsc that you guys fix on the next branch and I don't
> want to wait for several days before it gets pulled into master and I can resume productive
> work.
> 
> So maybe there is some flaw or weakness in my git work flow.  I have been using git for
> several years now but am not a power user.  I like git but do not really want to have to
> become a git guru.  However, this petsc policy of periodically unwinding the next branch
> seems to always disrupt my workflow - so I have not found a robust way to deal with it
> yet.
> 
> Dave
> 
> ________________________________________
> From: Jed Brown [jed at jedbrown.org]
> Sent: Thursday, October 02, 2014 4:39 PM
> To: Satish Balay; Nystrom, William David
> Cc: petsc-users; petsc-dev at mcs.anl.gov
> Subject: Re: [petsc-dev] [petsc-users] petsc git next branch *is* unwound!
> 
> Satish Balay <balay at mcs.anl.gov> writes:
> 
> > You would have to delete both 'next' and 'wdn_mods_next' branches from
> > all your clones - and recreate them.
> 
> Do your normal "git remote update" (or git fetch) in your "master" clone
> (confusing to use the same name to refer to a repository and a branch).
> I'll call the repository Mirror.  Anyway, you should see that all three
> branches are updated.  'maint' and 'master' should fast-forward, while
> 'next' will say "forced update".
> 
> After that, recreate 'next' on the clones just like in Satish's original
> email.
>