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.


Re: [git-users] Will Git suit my needs? If so then which version/toolset?

2017-05-16 Thread Nelson Efrain A. Cruz
Hi, you are confusing git with the tools that use git. Git it's only a
version control system, ie it has no authorization or authentication
methods nor concepts of projcts. It only cares about versioning.

Then you have tools like github (which I think you call Git Enterprise)
which are builded around git to add extra features like authorization or
code review tools.

To clarify your ideas you should take a look at:

* The Pro Git book(1), at least the first chapter
* Read about Git Workflows. The Pro Git Book has a chapter about that,
another (but maybe overcomplicated one) good thing to read is (2)
* Search about Continous Integration tools (like Jenkins or gitlab-ci) to
automatize some task. But I think you will have some troubles to use this.
Also take a look at the git hooks.

1 - https://git-scm.com/book/en/v2
2 - http://nvie.com/posts/a-successful-git-branching-model/

El dom., 14 de may. de 2017 a la(s) 15:20, barrjamy via Git for human
beings  escribió:

> First of all, apologies if this is not the right place to ask this lengthy
> question. I have done quite a bit of research so far, and am at the stage
> of being overwhelmed with info, and just getting more confused.
>
>
>
> I work for a company in a department that has just been merged into with
> IT area. The significance of this, and the reason for this question, is
> that I have been advised that we need to start using Git for version
> control. Which is all fine, however we seem to have numerous types of Git
> available, and I am struggling to determine which will be best for our
> team’s needs. Then the main issue being that the system we do development
> is an enclosed ecosystem, with its own editor. So for Git to work, it means
> exporting the developments to text files, which we can do, but we don’t
> work from these text files.
>
>
>
> We have access to:
>
> Git Enterprise, Git Bash, Git stash (same as bitbucket?) and Git Desktop
> (I think)
>
>
>
> What we do:
>
> The company has an accounting/leger system, and provides administration
> services to clients. From this system we provide reports to clients
> containing various info. Our job is to develop these reports and update
> them as required.
>
>
>
> How we do it:
>
> We develop these reports on a proprietary (some might say archaic!)
> system, using the system provided GUI. The code for these reports are
> backed up as a text file. It is these text files that we would be looking
> to version control.
>
> At the moment we have various area’s that we work in. We have the “live”
> area, which is where the reports get copied to once development and testing
> is complete. Then we have numerous “project” area, which start of as copies
> of the live area, and is where we do the development and testing of the
> new/amended reports.
>
> Once the development of a report is complete, we copy the new/amended
> report from the project area, to the live area.
>
>
>
> Question:
>
> 1) I am really struggling to visualise how this will work using Git. The
> way I think we will use it is,
>
> -  Treat the project areas as branches
>
> -  do the dev in the project area under a new branch
>
> -  then when the dev is complete, merge with the main version in
> the project area
>
> -  then (not sure of this part) daily export the files in the
> project area,
>
> -  find any that have changed (i.e. been merged with the dev
> branch)
>
> -  then merge any changes into the live report backups
>
> -  import any changed backups into the live area
>
>
> 2) Which Git tools to use? We need to be able to automate this process to
> some degree, needs to be relatively simple to use and collaborate over
> various locations (which is why Git is being pushed I imagine)
>
>
>
> From my initial investigation, I am unsure of the best way to get started.
> The only limited experience I have of version control software was SVN some
> time ago, which I used briefly as part of a module at when I was a student.
>
>
>
> I am not expecting a step by step guide from here, just some
> suggestion/advice of which interface will possibly best suit our needs.
> Maybe even some pointers with good resources on where to get started, that
> would be relivant to these needs.
>
>
>
> Many thanks in advance to anyone who takes time to offer advice. It’s much
> appreciated!
>
> --
> 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