Re: [git-users] How to handle a longrunning branch

[Konstantin Khomoutov]

On Tue, 17 Nov 2015 23:47:13 -0800 (PST)
mike  wrote:

> > > I have had a branch, feature_xyz, for a long time ( yes I know I 
> > > should not but it was not my call). Problem is I have not updated
> > > it with changes from master. So I started to do a regular rebase
> > > ( i want to keep history): 
> > > 
> > > git fetch origin master 
> > > git rebase origin/master 
> > > 
> > > After a while with conflicting patches (over 30...) I guess that 
> > > there must be an easier way to do this, 
> > > 
> > > So anyone out there with an better idea I am open to new ideas.
> > > What do you suggest? 
> >
> > What prevents you from just merging master into it? 
> >
> 
> Not absolutely sure but I guess it is for keeping history of changes
> when I merge back to master. 

Merges in Git are different from those in some other tools, namely,
Subversion: when you merge in Git, the merge commit created contains
the merged state of both lines of history which were merged *and*
references both tip commits which were merged together.

This means, that if you have:

  ...->A->B->C (master)

Then fork a branch "feature", and both branches receive a number of
commits so that they look like this:

  ...->A->B->C->D->E->F (master)
 |
 `->O->P->Q (feature)

Then when you merge "master" to "feature", you'll get a
"diamond-looking" history:

  ...->A->B->C->D->E->F-\ (master)
 |   |
 `->O->P->Q->M (feature)

So your "D..F" line on "master" and "O..Q" line on "feature" are both
there.

When you proceed developing on both branches again, you'll get:

  ...->A->B->C->D->E->F--+->R->S->T (master)
 |   |
 `->O->P->Q->M->X->Y->Z (feature)

With M being the last "merge base" between "master" and "feature".

That is, no history on any branch is "lost".

> > Rebasing is only actually needed if you want to keep your work "on
> > top" of the branch it was based on.
> What do you mean with the expression "on top"?

That's quite a literal meaning.

I've tried to explain how rebase works to someone here [1] (with
pictures borrowed from the "Pro Git" book) -- feel free to read it.

1. http://stackoverflow.com/a/11837630/720999

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] How to handle a longrunning branch

[Johannes Müller]

Hi,

There is no way around resolving the conflicts if you want to keep your
history. But there are strategies that can simplify the process.
To decrease the number of conflicts you need to resolve, you can first
interactively rebase your branch and "squash" successive commits. This
means you create one big commit replacing two or several successive commits.
The second strategy is to use a visual tool to resolve the conflicts.
With this you won't have to remove the conflict markers.

Johannes


On 17.11.2015 19:02, mike wrote:
> Hi,
> 
> I have had a branch, feature_xyz, for a long time ( yes I know I should
> not but it was not my call). Problem is I have not updated it with
> changes from master. So I started to do a regular rebase ( i want to
> keep history):
> 
> git fetch origin master
> git rebase origin/master
> 
> After a while with conflicting patches (over 30...) I guess that there
> must be an easier way to do this,
> 
> So anyone out there with an better idea I am open to new ideas. What do
> you suggest?
> 
> br,
> 
> //mikael
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Git for human beings" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to git-users+unsubscr...@googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] How to handle a longrunning branch

[Magnus Therning]

On Tue, Nov 17, 2015 at 10:02:03AM -0800, mike wrote:
> Hi,
> 
> I have had a branch, feature_xyz, for a long time ( yes I know I should not 
> but it was not my call). Problem is I have not updated it with changes from 
> master. So I started to do a regular rebase ( i want to keep history):
> 
> git fetch origin master
> git rebase origin/master
> 
> After a while with conflicting patches (over 30...) I guess that there must 
> be an easier way to do this,
> 
> So anyone out there with an better idea I am open to new ideas. What do you 
> suggest?

Maybe git-imerge,  can help out.

I've only used it once or twice, but found it very nice for performing
large merges.

/M

-- 
Magnus Therning  OpenPGP: 0xAB4DFBA4 
email: mag...@therning.org   jabber: mag...@therning.org
twitter: magthe   http://therning.org/magnus

The day after tomorrow is the third day of the rest of your life.

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: [git-users] How to handle a longrunning branch

[Konstantin Khomoutov]

On Tue, 17 Nov 2015 10:02:03 -0800 (PST)
mike  wrote:

> I have had a branch, feature_xyz, for a long time ( yes I know I
> should not but it was not my call). Problem is I have not updated it
> with changes from master. So I started to do a regular rebase ( i
> want to keep history):
> 
> git fetch origin master
> git rebase origin/master
> 
> After a while with conflicting patches (over 30...) I guess that
> there must be an easier way to do this,
> 
> So anyone out there with an better idea I am open to new ideas. What
> do you suggest?

What prevents you from just merging master into it?

Rebasing is only actually needed if you want to keep your work "on top"
of the branch it was based on.  The primary use case for keeping your
patch series on top of an "upstream" branch is the need to mail them
as a series of patches to upstream or have a clean run of history for
the upstream to have an easy-to-digest merge from your branch.

If that is not needed and you just want to have your feature branch
synchronized with the branch of its origin, just merge.  And re-merge
later, when needed -- it's perfectly okay to do.

On the other hand, try analyzing what that feature branch is really for.
I mean, if merging becomes a pain, it might be a signal that the feature
branch have diverged too much from the branch of its origin and may be
an effort should be taken to bring it more in shape with the "master"
code base.  This should make both rebasing and merging easier.

Yet another approach it considering the `git rerere` tool which
basically tries to remember how you have solved conflicts during a merge
and then allows to use this "canned solution" when again in the same
situation.  I honestly did not try it but may be it will make your
rebases easier.

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] How to handle a longrunning branch

[mike]

Den tisdag 17 november 2015 kl. 19:40:15 UTC+1 skrev Konstantin Khomoutov:
>
> On Tue, 17 Nov 2015 10:02:03 -0800 (PST) 
> mike  wrote: 
>
> > I have had a branch, feature_xyz, for a long time ( yes I know I 
> > should not but it was not my call). Problem is I have not updated it 
> > with changes from master. So I started to do a regular rebase ( i 
> > want to keep history): 
> > 
> > git fetch origin master 
> > git rebase origin/master 
> > 
> > After a while with conflicting patches (over 30...) I guess that 
> > there must be an easier way to do this, 
> > 
> > So anyone out there with an better idea I am open to new ideas. What 
> > do you suggest? 
>
> What prevents you from just merging master into it? 
>

Not absolutely sure but I guess it is for keeping history of changes when I 
merge back to master. 

>
> Rebasing is only actually needed if you want to keep your work "on top" 
> of the branch it was based on.


What do you mean with the expression "on top"?
 

>  The primary use case for keeping your 
> patch series on top of an "upstream" branch is the need to mail them 
> as a series of patches to upstream or have a clean run of history for 
> the upstream to have an easy-to-digest merge from your branch. 
>
> br,.
>

//mikael 

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.