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 [[email protected]] Sent: Thursday, October 02, 2014 4:39 PM To: Satish Balay; Nystrom, William David Cc: petsc-users; [email protected] Subject: Re: [petsc-dev] [petsc-users] petsc git next branch *is* unwound!

Satish Balay <[email protected]> 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.