Re: [git-users] Estimating the likeliness of a change leading to major conflicts
Uwe Brauer writes: Hi Uwe, > BTW did you run > > git fetch --all ; git fetch --tags > > Before executing this script? Tags are not important for the script which only looks at branches. And I assume that the user of the script does "git fetch/pull" once in a while. And since I wrote it for work where there is only one remote anyway, no need for --all. Of course, your projects may be different, so feel free to add a "git fetch --all" at the start. BTW, that's the updated incarnation of the script which fixes some "fatal: unexpected argument: ->" error which could occur in some situations because "git branch --list --remote" also lists a line origin/HEAD -> origin/master which is obviously no branch name, adds a column with last commit infos, and works for multiple files. -- 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/87v9dun34g.fsf%40gnu.org. git-check-file-changes Description: git-check-file-changes Bye, Tassilo -- 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/87v9dun34g.fsf%40gnu.org. signature.asc Description: PGP signature
Re: [git-users] Estimating the likeliness of a change leading to major conflicts
>>> "TH" == Tassilo Horn writes: > Philip Oakley writes: > Hi again, >> If you do come up with a reasonably simple script for this purpose, it >> maybe worth proposing to the Git-List for possible inclusion in the >> /contrib part of the git hierarchy as part of being inclusive of other >> folks problems ;-) > I currently use this: BTW did you run git fetch --all ; git fetch --tags Before executing this script? -- 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/87k0uaeoyx.fsf%40mat.ucm.es. smime.p7s Description: S/MIME cryptographic signature
Re: [git-users] Estimating the likeliness of a change leading to major conflicts
On 2020-11-17, at 8:35 AM, Tassilo Horn wrote: > Hi all, > > in some project with a quite large codebase and several independent > teams working on it, 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. If you are looking at this AFTER it happens, and want to get help in fixing the merge, my best recommendation is imerge. Basically, instead of having to solve a single big huge difficult mess, you solve lots of tiny easy messes. -- 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/885CE04F-6273-48A0-BAB5-AC8303E834EC%40gmail.com.
Re: [git-users] Estimating the likeliness of a change leading to major conflicts
>>> "TH" == Tassilo Horn writes: > Philip Oakley writes: > Hi again, >> If you do come up with a reasonably simple script for this purpose, it >> maybe worth proposing to the Git-List for possible inclusion in the >> /contrib part of the git hierarchy as part of being inclusive of other >> folks problems ;-) > I currently use this: > #!/bin/sh Interesting, thanks. I just pulled from emacs repository and run the script on a couple of files for example th-check-conflict.sh ChangeLog.2 LOC changed | % | branch 54/35805 |.15% | origin/emacs-27 54/35805 |.15% | origin/feature/icomplete-vertical 6/35805 |.01% | origin/feature/integration-of-dictionary-el 54/35805 |.15% | origin/feature/simple-16-theme 6/35805 |.01% | origin/scratch/eldoc-display-functions 54/35805 |.15% | origin/scratch/erc-oldies 544/35805 | 1.51% | origin/scratch/gnus-search 54/35805 |.15% | origin/scratch/modern-mode 54/35805 |.15% | origin/scratch/shorthand-namespacing I'll think about how to use it in mercurial ;-) -- 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/87wnydra4c.fsf%40mat.ucm.es. smime.p7s Description: S/MIME cryptographic signature
Re: [git-users] Estimating the likeliness of a change leading to major conflicts
Philip Oakley writes:
Hi again,
> If you do come up with a reasonably simple script for this purpose, it
> maybe worth proposing to the Git-List for possible inclusion in the
> /contrib part of the git hierarchy as part of being inclusive of other
> folks problems ;-)
I currently use this:
--8<---cut here---start->8---
#!/bin/sh
file="$1"
# Non-merged branches which have had activity within the last 3 month.
active_branches () {
git branch --remote --list --no-merged HEAD \
| while read branch; do
commit=`git log -n1 --since='3 months' $branch`
if [ x"$commit" != "x" ]; then
echo $branch
fi
done
}
printf "%15s | %6s%% | %s\n" 'LOC changed' '' 'branch'
for branch in `active_branches`; do
changed_lines=`git diff HEAD..$branch -- $file \
| grep '^[+-][^+-]' \
| wc -l`
if [ "$changed_lines" != "0" ]; then
file_lines=`cat $file | wc -l`
percentage=`echo "scale=4; x=$changed_lines/$file_lines*100; scale=2;
(100*x)/100" | bc`
printf "%15s | %6s%% | %s\n" "$changed_lines/$file_lines" "$percentage"
"$branch"
fi
done
--8<---cut here---end--->8---
It's very simple (so probably nothing for git/contrib) but enough to get
a clue at which branch to look at in more detail.
Bye,
Tassilo
--
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/87r1olzqt3.fsf%40gnu.org.
Re: [git-users] Estimating the likeliness of a change leading to major conflicts
If you do come up with a reasonably simple script for this purpose, it maybe worth proposing to the Git-List for possible inclusion in the /contrib part of the git hierarchy as part of being inclusive of other folks problems ;-) Some times the list can be dismissive of some real world problems because 'they are doing it wrong', while the different workflows create these unexpected issues (such as yours). On Thursday, November 19, 2020 at 5:35:05 AM UTC Tassilo Horn wrote: > Philip Oakley writes: > > >> That's a good starter, although I'd rather have a less precise > >> solution which doesn't require that I've already done and committed > >> my changes, i.e., I'd rather run the script *before* I start changing > >> anything. So maybe something along these lines. > > I know the 'before' feeling (!), but isn't that one of the 'git smells' > > (like code smells..) where we should be using a quick temporary branch > > for a side commit, or a WIP-on-top (almost the same as a stash) so that > > you do have a temporary local revision (blobs/trees/commit) stored > > *early*, just in case of mistakes. > > Yes, in general, I agree. However, the purpose of the script in > question is more like this: > > 1. I find some smelly code and I'm tempted to refactor it. > 2. I run my script which tells me quickly that my colleagues on the > other team already changed major parts of it on their feature branch. > 3. Because of that, I spin off a short-lived temporary branch from their > feature branch, do the refactoring there, and open a PR for them to > review. > > I can only see benefits. It costs me just some seconds to find out that > my intended changes would create much less friction if I just base them > on work of another team and so I do. > > Bye, > Tassilo > -- 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/120e8a75-03b4-4b9a-b02e-8dc813b8c0bbn%40googlegroups.com.
Re: [git-users] Estimating the likeliness of a change leading to major conflicts
On Thu, Nov 19, 2020 at 7:35 AM Tassilo Horn wrote: > > Philip Oakley writes: > > >> That's a good starter, although I'd rather have a less precise > >> solution which doesn't require that I've already done and committed > >> my changes, i.e., I'd rather run the script *before* I start changing > >> anything. So maybe something along these lines. > > I know the 'before' feeling (!), but isn't that one of the 'git smells' > > (like code smells..) where we should be using a quick temporary branch > > for a side commit, or a WIP-on-top (almost the same as a stash) so that > > you do have a temporary local revision (blobs/trees/commit) stored > > *early*, just in case of mistakes. > > Yes, in general, I agree. However, the purpose of the script in > question is more like this: > > 1. I find some smelly code and I'm tempted to refactor it. > 2. I run my script which tells me quickly that my colleagues on the >other team already changed major parts of it on their feature branch. Yes, I understand this pattern and what I usually do as a developer for fast checking it: git log --pretty=oneline --all --not HEAD -- file1 file2 file3 >From the list retrieved I check branches or open pull/merge requests and see if change should be done on top of them or not > 3. Because of that, I spin off a short-lived temporary branch from their >feature branch, do the refactoring there, and open a PR for them to >review. > > I can only see benefits. It costs me just some seconds to find out that > my intended changes would create much less friction if I just base them > on work of another team and so I do. > > Bye, > Tassilo > > -- > 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/87v9e1rjsz.fsf%40gnu.org. -- 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/CAAwdEzDAgNCQvGAy-B0yEPj%3DbkCT3HuhNXdGqJr-LicpaLqhJg%40mail.gmail.com.
Re: [git-users] Estimating the likeliness of a change leading to major conflicts
Philip Oakley writes: >> That's a good starter, although I'd rather have a less precise >> solution which doesn't require that I've already done and committed >> my changes, i.e., I'd rather run the script *before* I start changing >> anything. So maybe something along these lines. > I know the 'before' feeling (!), but isn't that one of the 'git smells' > (like code smells..) where we should be using a quick temporary branch > for a side commit, or a WIP-on-top (almost the same as a stash) so that > you do have a temporary local revision (blobs/trees/commit) stored > *early*, just in case of mistakes. Yes, in general, I agree. However, the purpose of the script in question is more like this: 1. I find some smelly code and I'm tempted to refactor it. 2. I run my script which tells me quickly that my colleagues on the other team already changed major parts of it on their feature branch. 3. Because of that, I spin off a short-lived temporary branch from their feature branch, do the refactoring there, and open a PR for them to review. I can only see benefits. It costs me just some seconds to find out that my intended changes would create much less friction if I just base them on work of another team and so I do. Bye, Tassilo -- 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/87v9e1rjsz.fsf%40gnu.org.
Re: [git-users] Estimating the likeliness of a change leading to major conflicts
On 18/11/2020 10:15, Tassilo Horn wrote: >> 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 > That's a good starter, although I'd rather have a less precise solution > which doesn't require that I've already done and committed my changes, > i.e., I'd rather run the script *before* I start changing anything. So > maybe something along these lines. I know the 'before' feeling (!), but isn't that one of the 'git smells' (like code smells..) where we should be using a quick temporary branch for a side commit, or a WIP-on-top (almost the same as a stash) so that you do have a temporary local revision (blobs/trees/commit) stored *early*, just in case of mistakes. Likewise, it's taken me a long time to stop having a local 'main' (was master) branch that mimics (duplicates) the upstream origin/main RTB to no real benefit. This feeling of wanting to check that stuff is ok before committing has the same psychological safety worries that we've carried over from older centralised VCS systems (public shame & blame;-). I had one this morning where I tried out a bit of Octave code that was supposed to be a simple renaming of variables that crashed, which though gritted teeth I committed, with note of the issue, then amended after I'd found the name clash, so I didn't lose all the good work for just one typo ;-) Do we have a "git smells" list? -- 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/8b11f1be-fb0b-46dd-618c-3d377e624c70%40iee.email.
Re: [git-users] Estimating the likeliness of a change leading to major conflicts
Alexandru Pătrănescu writes: Hi Alexandru, > 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 That's a good starter, although I'd rather have a less precise solution which doesn't require that I've already done and committed my changes, i.e., I'd rather run the script *before* I start changing anything. So maybe something along these lines. for each $branchX in $ActiveBranches X = git diff HEAD..$branchX -- $FILE | grep '^[+-][^+-]' | wc -l C = $X * 100 / 2 / (cat $FILE | wc -l) echo "$FILE changed $C % on branch $branchX." I'll play with it when I find some time and post the results. Bye, Tassilo -- 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/87d00bdl7t.fsf%40gnu.org.
Re: [git-users] Estimating the likeliness of a change leading to major conflicts
Philip Oakley writes: Hi Philip, > How independent are the teams - when do you even find out they exist? They know each other and at least have a vague idea about what the others are doing. But since many development topics are cross-cutting, it's hard to tell if you and they will stomp on each others' toas. > 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 ;-) I have nothing to add. ;-) (Ok, it's not that bad but surely shows signs of many of your arguments and age.) >> 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. No, not really. It's the "ensure no two persons refactor the very same code in parallel" problem. >> 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 Sure, but that's usually more a birds-eye view which is not enough for a concrete technical question. > - get some visibility of the areas they are 'playing' in (working on) Bye, Tassilo -- 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/87h7pndluk.fsf%40gnu.org.
Re: [git-users] Estimating the likeliness of a change leading to major conflicts
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 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.
Re: [git-users] Estimating the likeliness of a change leading to major conflicts
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.
