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
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
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
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
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,
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
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,
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
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,
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
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
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
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
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".
>
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
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
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
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
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
/
19 matches
Mail list logo
