Re: [git-users] keeping two branches with partially different history in sync

2017-05-21 Thread Philip Oakley
A small word of caution/care.

If I understand correctly, the `git merge -s ours` may not do quite what you 
expect. If the differences apply cleanly then there is no recourse to any of 
the `-s ours` strategy. It is only if there is a conflict that the strategy 
comes into force. This means that you may have merged in content that should 
not be there.


The alternative approach is possibly, as I understand it, the use of `git 
rerere` which maintains a database of how to resolve the conflicts, so you 
don't have to remember. This should then be used in conjunction with the `git 
cherry-pick` of the particular local branch fixes, which need the same old 
remembered resolutions every time.

Ultimately, I've not seen a good exposition of how to manage your (rather 
common) situation that captures all the local nuances. 

It almost needs a commit footer that marks specific commits as special to a 
particular branch and indicates what merge policy to use!  


Another alternative is to look at how Git for Windows has to cope with the 
upstream git, and the use by @dscho of his 'garden-shears' script which 
continuosly rebases the GfW fixes on top of the every changing upsteam while 
retaining old history and tags (of gfw) on the same lead branch. Not as pretty 
as you might hope, but it shows what can be done.

Philip

top four links of http://www.lmgtfy.com/?q=git+rerere+usage
https://git-scm.com/docs/git-rerere
https://git-scm.com/blog/2010/03/08/rerere.html
https://hackernoon.com/fix-conflicts-only-once-with-git-rerere-7d116b2cec67
https://chuva-inc.com/blog/fast-tip-enable-git-rerere-right-now
  - Original Message - 
  From: matevz.lan...@borea.si 
  To: Git for human beings 
  Sent: Wednesday, May 17, 2017 11:22 PM
  Subject: Re: [git-users] keeping two branches with partially different 
history in sync


  Hi Michael,


  thanks for your help, I would give up otherwise, but now I managed to get 
this working with a special git merge script that automatically performs merge 
from A to B and vice versa by ignoring (with git merge -s ours) all opposite 
commits created by automated merge script (by itself), 


  Also with "git merge -s ours" we can select which parts of the history we 
want to carry forward and which parts not. After performing single merge with 
-s ours for certain part of the history git will no longer complain about that 
in future merges (even normal merges) as it has already marked it as merged.


  regards,
Matevz

  -- 
  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] keeping two branches with partially different history in sync

2017-05-18 Thread Matevz . langus
Hi Igor,

script and sample git repo attached.

regards,
  Matevz

-- 
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.


git-sync-repo-script.tar.xz
Description: Binary data


Re: [git-users] keeping two branches with partially different history in sync

2017-05-17 Thread Igor Djordjevic
Hi Matevz,

On Thursday, May 18, 2017 at 12:22:09 AM UTC+2, matevz...@borea.si wrote:
>
> thanks for your help, I would give up otherwise, but now I managed to get 
> this working with a special git merge script that automatically performs 
> merge from A to B and vice versa by ignoring (with git merge -s ours) all 
> opposite commits created by automated merge script (by itself), 
>

Would you mind sharing the script, please? I`m curious to see what works 
for you, still struggling to comprehend what benefits merging provides in 
your use-case.
 

> Also with "git merge -s ours" we can select which parts of the history we 
> want to carry forward and which parts not. After performing single merge 
> with -s ours for certain part of the history git will no longer complain 
> about that in future merges (even normal merges) as it has already marked 
> it as merged.
>

This is true, but this "fake merge" is usually used for single way merging 
only, where you`re disregarding part of the history of the branch you`re 
merging from (say, A), kind of declaring it obsolete/superseded by the 
branch you`re merging into (say, B), but keeping the reference to it. Then 
you can keep merging in the same direction (from A to B), having only new A 
commits being included in the the future merge(s) to B.

But as soon as you try to merge the other way around, hoping to merge only 
new commits from B to A, you may be surprised by the outcome, having 
changes contained in your "private" B commits coming along, too, with 
"private" A commit changes now actually being removed inside the very A 
branch - a behavior you already experienced in your simple test repository.

If you instead do another `git merge -s ours` but in a different direction 
first (from B to A), then merging the new commits found on B to A, this 
will work, but it kind of seems as a glorified cherry-picking...? Not sure 
if any advantages you`re looking for in merging, if any in this case, are 
worth the badly messed up history with these repetitive `-s ours` cross 
merges :/

Hey, but if it works for you, I guess all is good :) I`m just curious.

Regards,
Buga

-- 
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] keeping two branches with partially different history in sync

2017-05-17 Thread Igor Djordjevic
Hi Matevz,

On Wednesday, May 17, 2017 at 6:15:49 PM UTC+2, matevz...@borea.si wrote:
>
> I managed on simple repository with
> merge -s ours
> To ignore specific commits from the other side.
>
> However in real life repo things get broken pretty soon. A changes are 
> propagated to B and then back to A and are lost in A, but remain in B :-)
>

This is exactly what I referred to as "while possible to accomplish, may be 
rather confusing and greatly complicate our life down the road" in my 
initial reply[1]... :)

[1] https://groups.google.com/d/msg/git-users/ovqx55Fv6bY/vuirLMmXAgAJ

-- 
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] keeping two branches with partially different history in sync

2017-05-17 Thread Matevz . langus
Hi Igor,

yes, I was referring to "2 messages have been deleted"

I think this happened because I left Michael's email in my reply and Google 
was not too happy with several Youtube links in that reply. Deleting 
Michael's contents and only writing my reply into the message resolved.

thanks,
  Matevz

-- 
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] keeping two branches with partially different history in sync

2017-05-17 Thread Igor Djordjevic
On Wednesday, May 17, 2017 at 9:48:04 PM UTC+2, rh kramer wrote:
>
> I see no evidence your messages are being deleted from this list.  Are you 
> referring to something else?  You do know that (for some reason I don't 
> know) 
> messages that you send to most lists are either not sent back to you or, 
> at 
> least, are not displayed in typical mail clients?
>

Google Groups web interface shows "2 messages have been deleted" in the 
middle of the thread[1]. Not sure what happened, though, as no more info 
seems to be provided...?

[1] https://groups.google.com/forum/?fromgroups#!topic/git-users/ovqx55Fv6bY

-- 
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] keeping two branches with partially different history in sync

2017-05-17 Thread rhkramer
I see no evidence your messages are being deleted from this list.  Are you 
referring to something else?  You do know that (for some reason I don't know) 
messages that you send to most lists are either not sent back to you or, at 
least, are not displayed in typical mail clients?

On Wednesday, May 17, 2017 11:32:31 AM matevz.lan...@borea.si wrote:
> Hi,
> 
> do you have any idea why my messages are being deleted?
> 
> regards,
>   Matevz


Re: [git-users] keeping two branches with partially different history in sync

2017-05-17 Thread Matevz Langus
Hi,

I managed on simple repository with
merge -s ours
To ignore specific commits from the other side.

However in real life repo things get broken pretty soon. A changes are 
propagated to B and then back to A and are lost in A, but remain in B :-)
Matevz Langus

-- 
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] keeping two branches with partially different history in sync

2017-05-17 Thread Michael
Then I think it should be possible.
Just need to know how to tell merge to only look at changes from "start of A's 
mergeable's changes to tip of A".
And I don't know that.

Or:
Should be possible
Limit merging to a range
How do you do that?

(Haiku because ... haiku)

On 2017-05-17, at 8:54 AM, Matevz Langus  wrote:

> Hi,
> 
> 1,2,3 yes.
> 
> 4: no, 100% of updates go from A to B and vice versa
> 
> thanks,
>  Matevz
> 
> -- 
> 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.

---
Entertaining minecraft videos
http://YouTube.com/keybounce

-- 
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] keeping two branches with partially different history in sync

2017-05-17 Thread Matevz Langus

Hi,

1,2,3 yes.

4: no, 100% of updates go from A to B and vice versa

thanks,
  Matevz

--
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] keeping two branches with partially different history in sync

2017-05-17 Thread Michael

On 2017-05-17, at 8:35 AM, matevz.lan...@borea.si wrote:

> Hi,
> 
> orphaned branch would work, but is very inconvenient for the process we have.
> 
> we would like for some people to work on A and commit patches to A.
> other people to work on B and commit patches on B.
> 
> Once a week we would like to get all A patches propagated to B and all B 
> patches propagated to A.
> 
> We would like to do that without cherry-picking as git's merge is really 
> fantastical and never forgets.

So:

1. You want to have a "common" "center" branch
2. You want to merge everything on A after a certain point to common
3. You want to merge everything on B after a certain point to common

(i.e. -- instead of everything from "start-of-history .. A", it's 
"end-of-client-specific .. A")

... I'll let someone else indicate if it's possible for merge to only take 
portions of a history like that.

And you want to merge that common back to both branches so that A's and B's 
updates are cross-propagated.

BUT:
4. This is only for about 95% of the updates to A and B -- a few things are 
still going to be side specific.

Is that correct?

I think 4 might just kill your use of git.

---
Entertaining minecraft videos
http://YouTube.com/keybounce

-- 
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] keeping two branches with partially different history in sync

2017-05-17 Thread Matevz . langus
Hi,

orphaned branch would work, but is very inconvenient for the process we 
have.

we would like for some people to work on A and commit patches to A.
other people to work on B and commit patches on B.

Once a week we would like to get all A patches propagated to B and all B 
patches propagated to A.

We would like to do that without cherry-picking as git's merge is really 
fantastical and never forgets.

thanks,
  Matevz

-- 
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] keeping two branches with partially different history in sync

2017-05-17 Thread Matevz . langus
Hi,

do you have any idea why my messages are being deleted?

regards,
  Matevz

-- 
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] keeping two branches with partially different history in sync

2017-05-17 Thread Michael
AHH...

So what you want is a new, orphaned branch of changes, and you want to merge 
that new branch into both A and B. Correct?

I'll let someone that knows how to set that up chime in.

On 2017-05-17, at 6:33 AM, matevz.lan...@borea.si wrote:

> Hi,
> 
> 
> You have a common source "master".
> You have two very large sets of changes from master, A and B.
> You need to apply patches to both A and B. These patches will apply cleanly 
> to both.
> But these patches will not apply to the last common "master" where A and B 
> diverged.'
> 
> Is that correct so far?
> 
>  CORRECT. 99% of cases they will apply cleanly on both, 1% with conflicts.
> Some of the patches might even apply to "old common master", but it would not 
> compile or not work if it would compile. Old master is a third branch we do 
> not want to maintain because it is useless without very large sets of changes 
> in A and B.
> 
> regards,
>   Matevz
> 
> -- 
> 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.

---
Entertaining minecraft videos
http://YouTube.com/keybounce

-- 
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] keeping two branches with partially different history in sync

2017-05-17 Thread Matevz . langus
Hi,


> You have a common source "master".
> You have two very large sets of changes from master, A and B.
> You need to apply patches to both A and B. These patches will apply 
> cleanly to both.
> But these patches will not apply to the last common "master" where A and B 
> diverged.'
>
> Is that correct so far?
>

 CORRECT. 99% of cases they will apply cleanly on both, 1% with conflicts.
Some of the patches might even apply to "old common master", but it would 
not compile or not work if it would compile. Old master is a third branch 
we do not want to maintain because it is useless without very large sets of 
changes in A and B.

regards,
  Matevz

-- 
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] keeping two branches with partially different history in sync

2017-05-16 Thread Michael

On 2017-05-16, at 1:36 PM, matevz.lan...@borea.si wrote:

> Hi Michael,
> 
> that would work normally, however we have a problem that we can not keep 
> common master and we need to split the master to A and B. The base code 
> changes are huge and there is no way for us to ever merge A and B branches 
> completely. 
> However the commits applied to A and B are compatible with both branches. 
> Cherry-picking everything after conflicting commits from A to B and B to A 
> would work, but we would like to avoid cherry-picking as it requires too much 
> manual checking and attention.
> 
> regards,
>   Matevz


So, lets see if I understand this:

You have a common source "master".
You have two very large sets of changes from master, A and B.
You need to apply patches to both A and B. These patches will apply cleanly to 
both.
But these patches will not apply to the last common "master" where A and B 
diverged.'

Is that correct so far?

> 
> 
> 
> On Tuesday, May 16, 2017 at 6:57:16 PM UTC+2, Michael Gersten wrote:
> 
> If so, I think that either doing merges from master to A and B, or rebasing 
> the few commits of A and B to the tip of master as you go, is the right 
> answer.
> 
> Am I correct in thinking that A and B are per-client customizations to your 
> main code?
> 
> 
> -- 
> 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.

---
Entertaining minecraft videos
http://YouTube.com/keybounce

-- 
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] keeping two branches with partially different history in sync

2017-05-16 Thread Matevz . langus
Hi Michael,

that would work normally, however we have a problem that we can not keep 
common master and we need to split the master to A and B. The base code 
changes are huge and there is no way for us to ever merge A and B branches 
completely. 
However the commits applied to A and B are compatible with both branches. 
Cherry-picking everything after conflicting commits from A to B and B to A 
would work, but we would like to avoid cherry-picking as it requires too 
much manual checking and attention.

regards,
  Matevz



On Tuesday, May 16, 2017 at 6:57:16 PM UTC+2, Michael Gersten wrote:
>
>
> If so, I think that either doing merges from master to A and B, or 
> rebasing the few commits of A and B to the tip of master as you go, is the 
> right answer.
>
> Am I correct in thinking that A and B are per-client customizations to 
> your main code?
>
>

-- 
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] keeping two branches with partially different history in sync

2017-05-16 Thread Michael
Let me see if I understand this correctly.

You want two things that differ from a common master by a few private commits, 
such as
Master = A, B, C, D, I, J, K, L, M

branch A = E, H, plus master
branch B = F, G, plus master

Did I understand that correctly?

If so, I think that either doing merges from master to A and B, or rebasing the 
few commits of A and B to the tip of master as you go, is the right answer.

Am I correct in thinking that A and B are per-client customizations to your 
main code?

On 2017-05-16, at 7:56 AM, matevz.lan...@borea.si wrote:

> Hi,
> 
> does anybody know how to keep 2 branches synced, each of them having 2 
> specific/private commits, which must not be pushed to the second branch. They 
> have common history and common future.
> 
> I want to have something like this:
> 
> branch A: E--H--I--J--K--M
>/   \  \  \/
> master:  A--B--C--D \  \  \  /
>\ \  \  \/
> branch B:   F--G--I--J--K--L
> 
> At any point in the future I would like to use regular "git merge A" and "git 
> merge B" to sync and B without loosing E,H and F,G respectively.
> 
> This could be done by using orphaned branches A and B, but then I loose 
> common history which I also need to keep.
> 
> Any ideas?
> 
> thanks,
>   Matevz
> 
> -- 
> 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.

---
Entertaining minecraft videos
http://YouTube.com/keybounce

-- 
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.


[git-users] keeping two branches with partially different history in sync

2017-05-16 Thread matevz . langus
Hi,

does anybody know how to keep 2 branches synced, each of them having 2 
specific/private commits, which must not be pushed to the second branch. 
They have common history and common future.

I want to have something like this:

branch A:E--H--I--J--K--M
   /   \  \  \/
master:  A--B--C--D \  \  \  /
   \ \  \  \/
branch B:   F--G--I--J--K--L

At any point in the future I would like to use regular "git merge A" and 
"git merge B" to sync and B without loosing E,H and F,G respectively.

This could be done by using orphaned branches A and B, but then I loose 
common history which I also need to keep.

Any ideas?

thanks,
  Matevz

-- 
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.