Hi,
I think you can just have a very simple script that
for each branchX in branchList
git checkout branchX
for each branchY in branchList
mergeResult = git merge branchY
if mergeResult
git reset HEAD~
else
notify about conflict between branchX and branchY
git merge --abort
I would do that in a bash script for faster writing but if it will need
more improvement, you can write in your language of choice.
You can cache the branchXHash-branchYHash so you compute only new changes.
Notification can extract data about the conflict so it will be more
relevant.
Notification can be an email based the commiter's one or a slack message or
whatever.
Regards,
Alex
On Wed, Nov 18, 2020, 00:11 Philip Oakley <philipoakley@iee.email> wrote:
> Hi Tassilo
>
> Some random thoughts.
>
> On 17/11/2020 16:35, Tassilo Horn wrote:
> > Hi all,
> >
> > in some project with a quite large codebase and several independent
> > teams working on it,
>
> How independent are the teams - when do you even find out they exist?
> For most FOSS code bases, the teams don't even know of each other until
> the send patches or pull requests.
>
> How well is the code structured? If it's corporate code then behind the
> branding and PR will be a Big Ball of Mud of code that's barely keeping
> its head above water for purity (etc). i.e. as a general observation,
> it's almost always doomed by cost and schedule ;-)
>
> > the following situation occurs every once in a
> > while:
> >
> > 1. Some developer is analyzing and fixing some bug reported to the
> > team. Thereby, he finds some file XXX involved in the scenario
> > which clearly needs some refactoring, and so he does, because he'll
> > execute that part of the code many times anyway and add/improve the
> > tests, so now's a good chance to do that.
> >
> > 2. Some other team has some feature branch where the file XXX is also
> > heavily changed. Now a team member merges from the branch where
> > the refactoring took place and now has many hours of joy solving
> > conflicts.
> >
> > So the (rhetorical) question is: could the developer in step 1 have
> > known beforehand that his changes are going to cause such troubles so
> > that instead of doing a major refactoring he would just do the most
> > minimal change fixing the bug?
> Ah, the big ball of mud minimalism problem - touch as little as
> possible, it's all booby trapped, especially if it also old.
>
> >
> > I guess, the question is "yes" because the required information is there
> > for sure.
>
> It's mainly a social/management problem about mutual communication and
> the wider team spirit.
> - make sure you know hat other projects are going on and
> - get some visibility of the areas they are 'playing' in (working on)
>
> > So the practical question is more like "has somebody written
> > a script/tool" which helps answering that question?
> >
> > Or formulated in a more concrete question: Is there a branch which
> >
> > a) hasn't been merged into the current branch yet,
> > b) has a common predecessor with the current branch,
> > c) changed file XXX in a significant way (expressed maybe as a ratio of
> > changed lines when diffing that file on the other branch and the
> > current one and the number of lines in the file).
>
> If everyone is working from the same merge-base or tagged release you
> can compare the numstat and diffstat values for the files on the two
> branches.
>
> Unfortunately there isn't a method yet for doing trail merges that limit
> themselves to particular subsets of files (so that know conflict areas
> aren't excluded) - a clean merge of the restricted subsets means that
> you won't have stepped on each others toes directly.
>
> You probably also need a static checker to see if any functional APIs
> have changed between the two sides.
>
> >
> > Bye,
> > Tassilo
> >
> --
> /random
>
> Philip
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/git-users/2e2bb9ab-9a11-5384-918e-81c22888dd6a%40iee.email
> .
>
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/git-users/CAAwdEzCr%3D6vzbdF9%2Bv5XGimUXe5mL0kSt0O0WL8iU114DQ_ovg%40mail.gmail.com.
