5

In a project of ours we have, as usual, a master branch. Based on that is the deployment branch, where the settings are modified. Also based on that is a mirror branch that runs the mirror of the deployment. The master branch ought not contain any config changing patches.

Small features and fixes are developed in the mirror branch. So after adding a feature, it looks like this:

master:      history ┐
deployment:          ├─ deployment-config
mirror:              └─ mirror-config ── feature

Now to move the feature back into master, I first have to reorder the patches in the mirror branch:

master:      history ┐
deployment:          ├─ deployment-config
mirror:              └─ feature ── mirror-config

Now I can fast-forward-merge that into master

master:      history ┬─ feature ┐
mirror:              │          └─ mirror-config
deployment:          └─ deployment-config

And then merge master into mirror, and rebasing it onto master

master:      history ── feature ┐
mirror:                         ├─ mirror-config
deployment:                     └─ deployment-config

Is there a plugin or tool that would automate that, so that

  • every new commit is automatically applied „below“ the top commit,
  • every merge or cherry-pick is also automatically applied „below“ the top commit,
  • a merge from such a branch pulls from the state „below“ the top commit?
Joachim Breitner
  • 25,395
  • 6
  • 78
  • 139
  • Why do you develop on the mirror branch? Using a third branch (or simply master) would avoid all that. – Mat Dec 23 '12 at 12:08
  • You could consider the mirror branch a development branch. The point is that master alone cannot be used, because with *no* configuration patch, the program does not work. – Joachim Breitner Dec 23 '12 at 12:10

2 Answers2

4

In general I would recommend to try and get away from that config commit situation. Can’t you just store the config on your deployments? Or use smudge filters, as I explained here: https://stackoverflow.com/a/13616911/758345

If that’s not an option, let me answer your questions, as there are simpler ways to achieve what you want thanks to the fact that branches in git are so light-weight. None of these are a complete automation, but quite simple and you could definitely write some small scripts for that.

every new commit is automatically applied „below“ the top commit

Not quite sure about the situation, but assuming you made changes and want to commit them:

  1. Remember your current branch-head’s SHA
  2. Stash your changes
  3. git reset --hard HEAD^
  4. stash pop
  5. commit
  6. cherry-pick your old branch-head

every merge or cherry-pick is also automatically applied „below“ the top commit

same as above: reset --hard, do your work, cherry-pick old branch head

a merge from such a branch pulls from the state „below“ the top commit?

This one is very simple: git merge mybranch^

If you do not want to change your working dir, and the files modified by your “config commit” are not touched by your other operations, you can do this:

  1. Remeber your current branch-head’s SHA
  2. Do a soft reset: git reset HEAD^
  3. Make git ignore your config files via git update-index --assume-unchanged
  4. create your commit
  5. run git update-index --no-assume-unchanged for your config files
  6. commit again – this will recreate your config files.

If you automate this via script, you can use git to get a list of config files for --assume-unchanged by looking at the config commit. If you do not want to automate this, you can skip step 3 and 5, and just make sure you don’t commit your config files in step 4.

Community
  • 1
  • 1
Chronial
  • 66,706
  • 14
  • 93
  • 99
  • Useful advice at any rate. I still don’t like that these temporarily modify my working directory, e.g. in `git reset --hard`, but it is a good start. – Joachim Breitner Dec 24 '12 at 12:03
  • Good use of git reset, easier than my answer. +1 – VonC Dec 24 '12 at 14:00
  • Did you have a look at my smudge filter link? That would be my definite recommendation. Otherwise the core question is if you want to commit changes to your config files. I updated my answer with details for a solution that does not modify your working directory. But please realize, that `git rebase` will also temporarily change your working directory, so you are already doing that. – Chronial Dec 24 '12 at 14:17
  • Nice, I very much like how the edited solutions works internally. The UI is still lacking, but that ought to be solvable, as you write, by automating this. Thanks! – Joachim Breitner Dec 25 '12 at 14:17
  • Happy I could help. „The UI is still lacking“ – git :) – Chronial Dec 26 '12 at 11:21
0

What can automate the reordering is a git rebase -i --autosquash, which can reorder / squash commits for you, based on the commits message:

If you know what commit you want to squash something in to you can commit it with a message of “squash! $other_commit_subject”.
Then if you run git rebase --interactive --autosquash commitish, the line will automatically be set as squash, and placed below the commit with the subject of $other_commit_subject.

(More details in the second part of "Trimming GIT Checkins/Squashing GIT History")

That could be an idea to facilitate the reordering of the 'feature' commits together, especially if you have "feature" and 'mirror-config' commits mixed together.

Once reordered, a rebase --onto can move those feature merge to the right branch.
See for instance "Complex git rebase maneuver".

Beside that, I don't know of any plugin which can automate those tasks: there are all about git rebase.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250