FLTK logo

Re: [fltk.coredev] git question: sync branch with master

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 All Forums  |  Back to fltk.coredev  ]
 
Previous Message ]New Message | Reply ]Next Message ]

Re: git question: sync branch with master Albrecht Schlosser Dec 18, 2021  
 
On 12/18/21 2:49 PM Greg Ercolano wrote:

So if you're working on a branch, and occassionally want to keep up with
current development on origin/master to continue working, what's the best way to sync up?

I believe albrecht said this one command would do the job
if you run into trouble pushing a branch:

    git pull --rebase


This is correct if you want to sync the branch you're working on with the remote repository where someone else (or even you, e.g. from another system) may have pushed branches to.

This is often the case with FLTK development in the main branch if the remote branch (e.g. origin/master) got pushes while you were working with your local copy of 'master' and committed in master. This can also be the case after you merged your development branch into master.

Assume remote/master got a commit from Manolo, say commit A.

You were working on your local master and committed B. Now you can't push because Git(Hub) tells you that the branches have diverged and you should 'git pull'. As I wrote you shouldn't do this because it would merge the remote branchThe situation is:

remote: origin/master - A
local:  master        - B

after git pull --rebase:

remote: origin/master - A
local:  master        - A - B'

Note that I wrote B' because this is formally another commit than B because it was rebased (it has another hash).

Now it is safe to `git push' because it would append your commit B' to the remote commit A. The new situation after `git push' is:

remote: origin/master - A - B'
local:  master        - A - B'

which is what you want.

Now, after you rebased your local branch and everything looks fine you try to push again. It can happen that git tells you again that your local and the remote branch diverged. What's going on? Well, someone else pushed commit C in the meantime. Don't worry, just go back to `git pull --rebase' and try again...

Is that also sufficient to keep an "in progress" branch synced with origin/master? The net seems to recommend the following for resync'ing an in progress branch:

    git checkout master         -- switch from your branch to master
    git pull                    -- get the latest from the remote. If your local master is clean, this shouldn't fail
    git checkout <local-branch> -- switch back to your branch
    git rebase master           -- rebase your branch to master

..or is that pretty much the same thing that 'git pull --rebase' does while you're
on your branch?


It's different because you want to "move your local branch forward on top of another branch". I'm calling your local branch "working" in the following graphs (use a fixed font if the HTML mail I'm sending doesn't do this for you):

Current situation:

remote: origin/master - A - B - C - D
local:  master        - A
                         \
local:  working . . . .   E - F - G

What you want to achieve is that your commits E - F - G are "rebased" onto the tip of remote branch origin/master after commit D, like this:

remote: origin/master - A - B - C - D
local:  master        - A - B - C - D
                                     \
local:  working . . . . . . . . . .   E' - F' - G'

The recipe above does exactly that (replace "<local-branch>") with "working". Again, commits E' - F' - G' differ from your original E - F - G in that they have different hashes.

Note: although Git is good at doing such things it can happen that you need to resolve merge conflicts when doing a rebase. Then it is obvious that you should test your updated branch and/or verify with tools like `gitk' that your commits and the result of the merge are consistent and what you wanted to do.

However, even if Git does not flag merge conflicts it is still possible that merging two branches (or rebasing one on top of another one) may introduce bugs. A simple example is if two changes to fix a bug in different places of the code merge silently but create another bug (think of adding 1 in two different places of the code which git does not notice as a conflict).

Hint for advanced git users: the commands can be "simplified" if you remember the correct syntax (be careful not to flip arguments). Assume your local branch is "working":
                                -- (on branch working)
    git checkout master         -- switch from your branch (working) to master     git pull                    -- get the latest from the remote. If your local master is clean, this shouldn't fail     git rebase master working   -- rebase your branch 'working' on 'master' and checkout 'working'

--
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/e5f64d96-0805-2408-396a-2e0b5c1071a5%40online.de.
Direct Link to Message ]
 
     
Previous Message ]New Message | Reply ]Next Message ]
 
 

Comments are owned by the poster. All other content is copyright 1998-2024 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.