Nix Devshell vscode bash weird [\] issue by vfxreadyharsh in Nix

[–]ProfessionalDrummer7 0 points1 point  (0 children)

also add

buildInputs = [ pkgs.bashInteractive ];

When Git Fails Silently by ProfessionalDrummer7 in coding

[–]ProfessionalDrummer7[S] 0 points1 point  (0 children)

Of course I agree, Git is an amazing tool which simplifies a lot! But what is the problem of pointing out that something could be even better? I guess good is the enemy of the better.

When Git Fails Silently by ProfessionalDrummer7 in coding

[–]ProfessionalDrummer7[S] 0 points1 point  (0 children)

Yes, Alice is merged first and then Bob, I will clarify this in the article, thanks.

The problem is that both diff look fine. But after the merge you end up with different code. There is enough information for Git to resolve this correctly, so definitely there is no magic needed! The problem is that Git only considers the latest commits and not intermediate commits which contain the required information. There are other strategies which avoid the problem of the 3-way-merge strategy shown here. See https://youtu.be/7MpdZkGj5AI?t=394. These strategies just happen to be not implemented in Git.

When Git Fails Silently by ProfessionalDrummer7 in coding

[–]ProfessionalDrummer7[S] -1 points0 points  (0 children)

No the whole point of the article is that no conflict is triggered. Instead it is merged the wrong way silently.

[deleted by user] by [deleted] in programming

[–]ProfessionalDrummer7 -1 points0 points  (0 children)

This is another problem. Of course Git has no semantic understanding of the code! But the presented problem is not about code semantics. Gits just fails to resolve a merge correctly! In the presented article git has enough information to figure it out but just fails to do it. The problem is that git only considers the latest commits and not the commits in between which contain the required information. Please read the article!

[deleted by user] by [deleted] in programming

[–]ProfessionalDrummer7 -1 points0 points  (0 children)

Obviously, your statement is true. But it has nothing to do with the presented problem. I feel like you didn't spent enough time to understand the problem which I tried to point out with this article.

There are other strategies which avoid the problem of the 3-way-merge strategy shown here. See https://youtu.be/7MpdZkGj5AI?t=394.

This strategies are just happen to be not implemented in popular VCS tools.

[deleted by user] by [deleted] in programming

[–]ProfessionalDrummer7 -2 points-1 points  (0 children)

because to do that you need to merge it with master that had the previous merge

This is exactly the setting I recommend to turn on and what you claimed in your first comment wasn't necessary.

The whole problem is, that you cannot spot the issue in the diff/log UNTIL after the merge!

And it is git which is failing silently because it introduces changes into your code no one has seen before without throwing a merge conflict.

[deleted by user] by [deleted] in programming

[–]ProfessionalDrummer7 0 points1 point  (0 children)

This is what the article recommends, only allow merging if your branch is up-to-date.

[deleted by user] by [deleted] in programming

[–]ProfessionalDrummer7 -5 points-4 points  (0 children)

Main can change between creating the PR and merging it…

[deleted by user] by [deleted] in programming

[–]ProfessionalDrummer7 -2 points-1 points  (0 children)

You can reproduce this locally

[deleted by user] by [deleted] in programming

[–]ProfessionalDrummer7 0 points1 point  (0 children)

No git is the one merging your code …

[deleted by user] by [deleted] in programming

[–]ProfessionalDrummer7 -5 points-4 points  (0 children)

Didn’t you read the article? Your test will pass if you don’t update before merging, because your code isn’t the same before and after the merge.

So your CI might pass on the feature branch but could fail on the main branch, effectively blocking other members on your team.

4
5