0

I have a Git repository containing a Java library with two branches: main and jdk8.

The jdk8 branch is the main development branch, with all changes merged into main, whereas the main branch is modular and based on jdk11, with module-info.java files and changes in Gradle build files, different build plugins and modular versions of dependencies, where available. The source code itself is close to identical between the two branches.

What I'd like to do, is to stop developing on the jdk8 branch and start using main as the main development branch, merging changes into the jdk8 branch, from there on.

Some googling led me to these:

How to make empty merge commit (ignoring changes)?

Git - Ignore files during merge

And from that I came up with this strategy:

git checkout jdk8

git merge -s ours main

I have tested this and it looks like it works as expected, that is, allows me to start developing on main and merge the changes into the jdk8 branch, excluding any modified files that don't belong there during merge (perhaps I can use git attributes to exclude the module-info.java files automatically, for example).

On the face of it, this appears quite manageable, but since my understanding of Git is quite rudimentary, I'm wondering if this will cause some problems down the road, is there perhaps a better ("correct" even?) way of doing this?

darri
  • 562
  • 1
  • 5
  • 10

1 Answers1

1

It seems like a dangerous flow. Even if you succeed to make the empty merge that will allow you to merge back future changes in main to jdk8, as soon as you will have any new jdk>8 change you will have conflict you will have to resolve manually. For example any change in your module-info.java or in gradle scripts will give you headache... I suggest you 2 options:

(option 1) you can make only the common features to the jdk8 branch and merge them easily to main and jdk>8 devs directly to main

(option 2) you can develop with feature branches from main that you merge back to the main branch and cherry-pick them to jdk8.

(option 3) if you want to keep the history of the feature branches: you can (once the branch is merged into main) to use rebase --onto to get only the interesting commit segment into jdk8

As now the jdk8 branch seems more like a maintenance branch I think that (option 2) is the preferred one

Yosef-at-Panaya
  • 676
  • 4
  • 13
  • Thank you YosefY, but I think there is some misunderstanding here though. I don't want to continue developing on my old jdk8 branch, but on main. I want to be able to merge my future changes in main into jdk8, that is, reverse my old workflow, where I did my development on jdk8 and merged into main. What I'm looking for is the step where I "reconcile" the two branches before I start developing on main, if that makes sense. – darri Dec 07 '21 at 11:32
  • You need to see branches in Git not as a set of commit but only as a pointer to a specific commit in the git commit graph. In your case, as far as I understand the jdk8 is your stable branch and the main one is the ongoing devs. This is the reason I think you first should reverse the branch names and make the jdk8 branch to be called 'main' and to merge the second one. The git commit graph will be more correct. Once the change is done and the main the reconciled changes. The best practice should be to work with short term dev branches (one for each development) and to merge them to main. – Yosef-at-Panaya Dec 09 '21 at 10:55
  • The "branch -m" is only to rename the branches to make the jdk8 as base for your devs (by renaming it to main and to change the current 'main' branch name to whatever you want and to merge it to the newly called 'main' (that was your old jdk8 branch). Is this now clearer? – Yosef-at-Panaya Dec 09 '21 at 10:57
  • **THIS IS THE MAIN POINT TO UNDERSTAND HERE** `You need to see branches in Git not as a set of commit but only as a pointer to a specific commit in the git commit graph` – Yosef-at-Panaya Dec 09 '21 at 10:59
  • Yes, it sure feels like I'm not grasping something here. I'll give it some more thought. One thing though, the jdk8 branch will be a long lived branch, since I want my library to support both jdk8 and jdk11 and beyond. I'll create short lived feature branches in the future, merge those into main, and from there into jdk8, or at least, that's how I'm (perhaps incorrectly) understanding this. – darri Dec 09 '21 at 14:01
  • okay this should not be an issue too. just rename the current main to futur-devs-to-merge `git checkout main && git branch -m futur-devs-to-merge` and create a new main from jdk8 `git checkout jdk8 && git checkout -b main` like that you will have the jdk8 same as before to handle the support of jdk8 only and the main that will start its life from the jdk8 latest commit... – Yosef-at-Panaya Dec 09 '21 at 14:14
  • All right, I feel like we're getting closer, again, thank you for your patience. But it still seems like we're trying to solve different problems. I want the branches to stay exactly the same way as they are now, jdk8 will continue being jdk8 and main will continue being main, as in, I don't want main to start a new life from the latest jdk8 commit. I just want to be able to merge future changes in main into jdk8, excluding changes that are not compatible with jdk8, such as module-info.java files and build logic relevant only to java modules, that is, reversing my current workflow. – darri Dec 09 '21 at 15:07
  • Okay I now understand what you mean. it seems like a dangerous flow. Even if you succeed to make the empty merge that will allow you to merge back future changes in main to jdk8, as soon as you will have any new jdk>8 change you will have conflict you will have to resolve manually. For example any change in your module-info.java or in gradle scripts will give you headache... I suggest you 2 options: (option 1) you can make only the common features to the jdk8 branch and merge them easily to main and jdk>8 devs directly to main OR (option 2) [in the next comment] – Yosef-at-Panaya Dec 09 '21 at 20:11
  • (option 2) you can develop with feature branches from main that you merge back to the main branch and cherry-pick them to jdk8. – Yosef-at-Panaya Dec 09 '21 at 20:12
  • (option 3) if you want to keep the history of the feature branches: you can (once the branch is merged into main) to use rebase --onto to get only the interesting commit segment into jdk8 – Yosef-at-Panaya Dec 09 '21 at 20:14
  • As now the jdk8 branch seems more like a maintenance branch I think that (option 2) is the prefered one – Yosef-at-Panaya Dec 09 '21 at 20:16
  • We are on the same page now, thanks for sticking with me. Your option 1 is my current workflow, it works pretty well, but it "pollutes" the commit log of my main branch with a bunch of merge commits, so that the latest commit message in my main branch is always "Merge branch 'jdk8'", and that is starting to bother me quite a bit. That's basically my motivation, to move this constant flow of merge commits to the jdk8 branch, which will eventually fade into obscurity, when I stop supporting jdk8, while main will become my main development branch and have a more informative last commit message. – darri Dec 09 '21 at 22:48
  • I realize option 2 will mean resolving conflicts arising from modifications in module-info.java files and build file sections that do not apply to jdk8, but I'm hoping that will be manageable and worth the effort. I've looked into git attributes a bit and it seems I should be able to use those to handle the module-info.java files automatically (**/module-info.java merge=ours), if I'm understanding git attributes correctly (I'm always in doubt when it comes to my understanding of Git). I'll have to experiment with that. – darri Dec 09 '21 at 22:48
  • My biggest worry, and the reason behind my original question, is that I'll somehow damage my repository by doing this, in a way that I'll perhaps only realize a long time from now when it's too late to go back and fix. This repository contains over a decade of development history, which I'm quite fond of and don't want to mess up. – darri Dec 09 '21 at 22:48
  • If you edit your answer in light of our new understanding, with your options 2 and 3 and, if you feel like it, add a thought or two about the merits (or demerits) of what I'm trying to achieve, I will happily accept it. – darri Dec 09 '21 at 22:49
  • 1
    <> your repo won't be damaged, in all case you can get the old content back and change the specific problematic files (if you have like) back to an old version (before the merge ours) and merge from jdk8 again, manually resolve the conflict and start from fresh state with this file. BTW I edited my answer :) – Yosef-at-Panaya Dec 14 '21 at 11:31