„Floating“ commit in git

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?

  • Git rebase -i does nothing
  • Why does a conflict occur for only one commit instead of two in my rebase operation?
  • How do you get a lost “autostash” commit from `git rebase --autostash`
  • git rebase fails with Unknown exit code (128) from command: git-merge-recursive
  • Git Changing rebase
  • git rebase command broken - mangled output
  • git rebase and deleted rebasing branches causing “Interactive rebase already started” error message
  • How to update git submodule who's history was rewritten
  • 2 Solutions collect form web for “„Floating“ commit in git”

    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.

    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.

    Git Baby is a git and github fan, let's start git clone.