Cherry-picking changes, a.k.a. throw away all code fixes done yesterday



  • First, few general WTFs to give context:

    1. We have some git fanatics at our work that love to use every feature that git has and svn doesn't even if it's not appropriate, just to show git superiority.
    2. Every month, we're making a "feature branch" that's supposedly a release version that won't change anymore except for critical bugfixes, but actually they're still getting new features; effectively, we're backporting about 80% of trunk changes into five older feature branches, which is very time-consuming because the remaining 20% is huge code changes that prevent any straight-forward diff-patching from working.
    3. C++
    4. One of the changes that's on trunk but not on still-maintained feature branch is going from C++03 to C++11. Now, not only patches, but also copy-pasting doesn't work anymore.

    So, two days ago, a git-fanatic colleague backported some trunk changes to old feature branch. Of course, since it was his own code, it was full of autos and lambdas and initialization lists. How he completed his task? Cherry-picking, of course. Didn't even check if the code compiles after his commit - because it was obvious to him that it doesn't.

    It was my work to clean up after him. Spent whole yesterday on that. But in the mean time, the trunk code went through code review, and some small but significant corrections were made, including moving files. My dear colleague was assigned to backport those changes back to old branch. What did he do? Cherry-picking, of course. He didn't think about that this would remove any and all changes I've made to those files in order to make the code compile after his fuckup. Or maybe he did, but went with it anyway because fuck you, that's why!



  • Makes me glad I get to forward all build/test breaks straight to the responsible party. Especially if I can defend it.


  • Discourse touched me in a no-no place

    @Gaska said:

    Every month, we're making a "feature branch" that's supposedly a release version that won't change anymore except for critical bugfixes, but actually they're still getting new features; effectively, we're backporting about 80% of trunk changes into five older feature branches

    ... you work for us, and I haven't realised it yet...

    @Gaska said:

    git

    @Gaska said:

    C++

    Oh - maybe not.



  • @Gaska said:

    a git-fanatic colleague backported some trunk changes to old feature branch
    ...
    Cherry-picking, of course

    What you should propose to your colleague is to create a different feature branch to do this sort of things.

    Another thing, when you hear "cherry pick" be afraid. Now you have two problems.



  • @PJH said:

    ... you work for us, and I haven't realised it yet...

    Well, it's a pretty normal setup, the problem comes when you have to actively maintain several different release versions. Why they're doing this baffles me.

    OTOH imagine this scenario without VCS.



  • @PJH said:

    Oh - maybe not.

    My company isn't all-C++, just our project and some others. And git is unofficial tool - officially it's SVN, but git fanatics fucked up mergeinfo by using git-svn, and former SVN people decided it's too much hassle to clean up the properties after those fanatics and switched too.

    @Eldelshell said:

    What you should propose to your colleague is to create a different feature branch to do this sort of things.

    No - what I should propose is to just reimplement each of those 20 issues from scratch. It wasn't that much work. Definitely less than cherry-picking and then fixing all the stuff.

    @Eldelshell said:

    the problem comes when you have to actively maintain several different release versions. Why they're doing this baffles me.

    One feature branch is to be released and is undergoing integration testing, another two are used by two different projects that depend on us (we're sort of a common foundation for both (not really)), and another two might or might not be selected by the downstream projects as the new target versions, so all five must be (mostly) up to date with trunk. That's pathological situation everyone here complains about, but nothing can be done about it.


  • Fake News

    @Gaska said:

    It was my work to clean up after him. Spent whole yesterday on that. But in the mean time, the trunk code went through code review, and some small but significant corrections were made, including moving files. My dear colleague was assigned to backport those changes back to old branch. What did he do? Cherry-picking, of course. He didn't think about that this would remove any and all changes I've made to those files in order to make the code compile after his fuckup. Or maybe he did, but went with it anyway because fuck you, that's why!

    I'm not that familiar with cherry-picking, but wouldn't such an operation trigger a merge conflict if you got your cleanup changes pushed out to the feature branch before any cherry-picking happened? If so, it's technically not git throwing away all code fixes, it's the other tool invoking git cherry-pick which happens to be an asshole.

    I've seen this happen in SVN as well BTW:

    • Keep your branched working copy from last time you did any changes to it.
    • Copy files from trunk to branch.
    • Try to commit, get a "remote version updated" error.
    • Do an update.
    • Pick "Resolve conflicts with MINE" and redo the commit.
    • All checked in, total mess.

    The only difference so far is that Git actually helps you copy over those files. Still, merging with an ego just can't do.



  • @JBert said:

    I'm not that familiar with cherry-picking, but wouldn't such an operation trigger a merge conflict if you got your cleanup changes pushed out to the feature branch before any cherry-picking happened?

    No, because:

    1. the file was moved (in SVN: deleted and created), which possibly fucked up conflict checker;
    2. git has a magical ability to brute-force through any conflict without really resolving it via cherry-picking.
      Note: it's not pure git, it's SVN server with me using pure SVN and him using git-svn.

  • Fake News

    @Gaska said:

    2) git has a magical ability to brute-force through any conflict without really resolving it via cherry-picking.Note: it's not pure git, it's SVN server with me using pure SVN and him using git-svn.

    Ah, so you are still using SVN as central repository... I buttumed that the non-GIT-fanboys also switched to a true Git repository just to get rid of this nonsense. I guess that means that the powers-that-be are still unaware that people are using Git in this way?

    Git doesn't do the brute-force thing by default, because even if git-svn is made up of voodoo and concentrated contempt for any sane workflow, it's internal rebase step should fail on conflicting changes.

    I still put my money on your psychopathic "colleague" failing to listen to any alarm bells going off, maybe because he's gotten used to ignore them.

    My condolences BTW.



  • @JBert said:

    I buttumed that the non-GIT-fanboys also switched to a true Git repository just to get rid of this nonsense.

    That would require rewriting dozens upon dozens bash scripts in our CI system that heavily depend on SVN, and no one wants to do this, and also the real switch from SVN to git must be officially approved by L2 and possibly L3 management (that's the easy part).


  • Discourse touched me in a no-no place

    @Eldelshell said:

    the problem comes when you have to actively maintain several different release versions. Why they're doing this baffles me.

    Oh - I know. We have the same problem. And I'm none the wiser either.



  • @Gaska said:

    Didn't even check if the code compiles after his commit - because it was obvious to him that it doesn't.

    It was my work to clean up after him.

    Why is it your job to clean up after him in the first place? Every place I've worked, you break something and it's your responsibility to fix it. Some places won't even let you check in broken code (build is triggered after every commit and if it fails to build or pass any tests your change is rejected).

    If he was your boss, he could tell you to port his changes into the other branches. It would save some time if as you say the new features are easy to port. Avoiding the problem in the first place. If you were his boss, you could tell him to clean up his mess.

    So I imagine you're on even footing, which then makes me wonder why your boss tells him to port the changes, and you to fix the problems he caused when he failed to do his assigned task.



  • We're working in agile; the smallest operational unit is a team, not an individual, so boss has no power over here. Also, currently he's working on something that I don't want to deal with even more than the 'auto' changes meaning in C++11; please remove it errors.


  • Discourse touched me in a no-no place

    I moved 3 posts to a new topic: Now about that change request...



  • @Gaska said:

    effectively, we're backporting about 80% of trunk changes into five older feature branches, which is very time-consuming

    If we hadn't recently seen the light and decided that this is an asinine way to work, I'd assume you're talking about my company...



  • Except we DO realize this. It's just, you can't negotiate with Germans when you're Polish and your mediator is from India. International corporation with dozens of divisions at your finest.


  • Winner of the 2016 Presidential Election

    @Eldelshell said:

    when you hear "cherry pick" be afraid.

    QFFT



  • @Gaska said:

    It's just, you can't negotiate with Germans when you're Polish

    Well, we know how that worked out for us the last time we tried...



  • For anyone who doesn't know, git cherry-pick copies a set of changes from one branch to another. Think of changes as cherries, the repository as a tree, and the command as a ladder.



  • @ben_lubar said:

    Think of changes as cannonballs, the repository as a tree, and the command as a field gun.

    FTFY


  • Discourse touched me in a no-no place

    @ben_lubar said:

    For anyone who doesn't know, git cherry-pick copies a set of changes from one branch to another.

    I believe it also records that the changes have been transferred, so when you later decide to merge the branches, the merging algorithm has more to work on. This is part of the secret sauce that makes merging less painful with git than with svn: git knows more about what's happened.


  • Fake News

    That's incorrect, a modern Subversion install records every little merge between branches whereas Git doesn't unless you tell it to. The thing is that Git merges can only happen on a full branch and for all commits before the merge, Subversion actually allows you to cherry-pick revisions at that time and stores ranges of merged commits (unless some Id10T uses git-svn).

    Git can live fine without most of this metadata, it will just compare two filesystem snapshots on reintegrating branches and skips identical files. Subversion On the other hand will for some reason try to replay patches, and then gets its head stuck in a paper bag because it can't replay an already applied patch unless it knows to skip it.



  • And the reason for this is that git tracks file contents and svn tracks directory diffs.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.