0

I have a bunch of bash scripts loaded from my .bashrc that I store in a private github repo so I can use them across computers. Each computer has its own quirks, so I have a branch for each one. I started this project on my work computer, so master has a bunch of code that's not relevant for my home environments.

In those branches, I've deleted the work-related changes, however it would be much better if I could make work its own branch and make master a base, non-customized set of code. That way, whenever I make a change in my work branch, I don't get merge conflicts about deleted files when I rebase my home computers onto master. However, I want to make changes to master that apply to all of my branches; if I then rebase work back onto master--which has deleted my work code--work will receive those deletions.

How can I branch master into work, delete the work-related changes on master, and then rebase work back onto my cleaned master without deleting all the work-related code in work?

I could use git rebase --interactive and split out all of my work changes since the beginning of time, but that seems tedious for an action that can't be all that uncommon.

I saw git rebase --onto and git filter-branch but from what I read, neither of those look like the right approach.

mkrieger1
  • 19,194
  • 5
  • 54
  • 65
dx_over_dt
  • 13,240
  • 17
  • 54
  • 102
  • 1
    What do you mean by "all differences"? – evolutionxbox Jul 24 '21 at 18:54
  • I mean don't change any of the code of the rebasing branch that was deleted by the base branch. – dx_over_dt Jul 24 '21 at 18:55
  • `Each computer has its own quirks, so I have a branch for each one` sounds like a nightmare. Consider researching a templating system, like `chezmoi`. ` I branch master into work` - `git checkout master ; git checkout -b work` - `delete the work-related changes on master` - `git reset --hard ` - `then rebase work back onto my cleaned master` - I do not understand that part. If `work` is on top of `master` there's nothing to rebase. If you want to shuffle commits, yes, use `git rebase -i`. – KamilCuk Jul 24 '21 at 18:55
  • If the commit being rebased adds or changes the code then it must change it... why rebase at all? The "base-branch" won't be affected however. – evolutionxbox Jul 24 '21 at 18:56
  • @KamilCuk When I make changes in `master` that apply to all branches, I need to rebase each branch onto master, no? If master has deleted files that are in `work`, and I rebase to get my new changes, then all my deletions will also apply. – dx_over_dt Jul 24 '21 at 18:57
  • @dx_over_dt are you treating branches as separate projects? – evolutionxbox Jul 24 '21 at 19:03
  • @evolutionxbox No? Depends on what you mean by projects. I define a bunch of aliases/functions/variables in `~/shellrc/*` which are loaded by `.bashrc`. *Most* of those are common to all of my computers. However, each computer has its own set of custom values. – dx_over_dt Jul 24 '21 at 19:06
  • @KamilCuk I peeked at chezmoi. It looks exactly like what I'm trying to achieve with my repo. I'll look into setting it up. Thanks! – dx_over_dt Jul 24 '21 at 19:10
  • `onto master, no?` yes. `then all my deletions will also apply` Yes, but if there are new commits on those deleted files, you'll get rebase conflicts that you have to manually deal with. – KamilCuk Jul 24 '21 at 19:17

1 Answers1

1

How can I branch master into work, delete the work-related changes on master, and then rebase work back onto my cleaned master without deleting all the work-related code in work?

A rebase onto master would use a... rebase --onto:

git rebase --onto master $(git merge-base master work) work

That would replay your commits from work on top of the cleaned master

  git merge-base master work
      |
m--m--m--M       (master, cleaned-up)
       \
        w--w--w  (work)

    git rebase --onto master $(git merge-base master work) work

m--m--m--M            (master, cleaned-up)
          \
           w'--w'--w' (work, rebased)
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • I tried this and it didn't work. `work` received all the deletions I made in `master`. – dx_over_dt Jul 25 '21 at 19:19
  • @dx_over_dt Strange, considering work is supposed to be replayed on top of master, recreating those deleted files. – VonC Jul 25 '21 at 20:28
  • I think the issue may be that work is essentially master renamed. When it does the rebase --onto, there is no w to become w'. w is just the m before M. – dx_over_dt Jul 25 '21 at 20:31
  • @dx_over_dt Got it: I now know whay rebase drop those files (deleted in master): https://stackoverflow.com/a/37064182/6309. Are those files modified in work? – VonC Jul 25 '21 at 20:33
  • They haven't been yet – dx_over_dt Jul 25 '21 at 20:35
  • @dx_over_dt Can you try and modify them (in the work branch) *before* the rebase? Even a dummy modification. – VonC Jul 25 '21 at 21:03
  • Sorry for the wait. I added a space to the file and committed. `rebase --onto master` worked great, after that! – dx_over_dt Jul 31 '21 at 17:52