1

When I have a release imminent I leave the version intact in git and checkout a new branch for future work.

There are times when I know there will be file conflicts as I'll need to make edits (reason A) in the current (release) version and in the forward looking branch (reason B).

Is thee anyway of telling git that the changes I just made to a file (reason A) in the version release can be applied (moved. copied, fast-fowarded) to the same file in the new branch? (and of course merged with the reason B changes)

I wish to subsequently make changes to the file in the branch (reason C now) and not have yet another conflict to address come merge time. (Especially for trivial edits).

Techmag
  • 1,383
  • 13
  • 24
  • So let me get this straight. You have a release branch which you need to base your work off of. You then want to make changes to the release branch, and back-port those changes to the branch you created earlier (which was off an earlier ancestor of your release branch)? – Makoto Jun 30 '15 at 19:13
  • Correct - possible en mass when we merge the branch I know - just seeing if we can intelligently eliminate some of the merge pain on a file by file basis before that day arrives. – Techmag Jun 30 '15 at 20:27

2 Answers2

0

Git will only fast-forward if there are no conflicts. If there are conflicts, then Git will actively refuse to fast-forward until the conflicts can be resolved.

In general, this is meant to mitigate against human error. You may believe that an edit is trivial, but it may conflict with other work that you've done elsewhere on a different branch.

If you're noticing that Git is warning you about these conflicts, then your changes aren't as trivial or as narrow as you first assumed.

Think of it like this: you have master and feature branches. feature is based on the tip of master.

    master
------[]
    feature

You do some work on master and push that.

      feature     master
  ------[]----------[]

You then do some work on feature and push that up as well.

                  master
  ------[]----------[] 
         \
          \       feature
           ---------[]

Suppose now that the work you had based your approach on in feature had changed drastically in master. Of course, you're going to get a notification about a merge conflict in it. Git makes absolutely no assumptions about the interopability of your code; it only detects the potential for conflict and alerts the user to it.

If you want a specific version to win regardless, then you can forcefully take a merge and specify their history as the winner. This is a dangerous operation, so I implore you to read the documentation and be sure that this is what you need.

Makoto
  • 104,088
  • 27
  • 192
  • 230
  • I've done merges before and I'm well aware of the reversely proportional impact of changes relative to their size :) This questions was explicitly to see fi there was path to deal with this on a file by file basis in those situations where I'm being held in stasis by a release pending client approvals. I have a complicated environment with git-submodules crossing multiple projects so anything to reduce merge pain into byte sized chunks would be extremely helpful. – Techmag Jul 01 '15 at 14:18
0

Pretty impressed with git as it seems to have this ability built in.

I was researching diff between two branches How to compare files from two different branches? and figured out how to do this manually. e.g. just create a .diff patch and apply it. 

git checkout B
git diff ..master path/file.scala > path/file.diff
git apply path/file.diff

Note that silence is golden on that last command.

So I was all set to do that and low and behold when I woke up the dev environment (via a script that calls git pull origin master) into the current branch it figured out the changes and applied them. (And as predicted balked at those that could not be auto-applied) 

On branch B
nothing to commit, working directory clean
* remote origin
  Fetch URL: https://github.com/xxx/xxxx.git
  Push  URL: https://github.com/xxx/xxxx.git
  HEAD branch: master
  Remote branches:
    master     tracked
    B tracked
  Local branch configured for 'git pull':
    master merges with remote master
  Local refs configured for 'git push':
    master     pushes to master     (up to date)
    B          pushes to membership (up to date)
From https://github.com/xxx/xxxx
 * branch            master     -> FETCH_HEAD
 = [up to date]      master     -> origin/master
Auto-merging path/file.scala
Merge made by the 'recursive' strategy.
 path/file.scala | 13 +++++++++++++
 1 file changed, 13 insertions(+)

So I guess the answer is git pull origin BRANCH at least in the simple cases.

Community
  • 1
  • 1
Techmag
  • 1,383
  • 13
  • 24