3 ms·

only related by "git" but while I believe i'm fairly proficient in git I'm not sure how to go about explaining to an inexperienced person how to fix a merge con

only related by "git" but while I believe i'm fairly proficient in git I'm not sure how to go about explaining to an inexperienced person how to fix a merge conflict. It feels like not a simple thing to explain. As an example someone sent me a PR with 15 commits. github claims only 1 file has changed and it's a new file so no conflicts (which AFAIK is correct) but git complains that somewhere around commit 4 there's a conflict. The person sending the PR is not git comfortable, otherwise they wouldn't have this PR with 14 old unrelated commits showing up. I have no idea what state they are currently in as well. meaning, I know the state of the PR but I don't know the state of their local machine. I can clone their branch and make the merge myself but their next PR will just be the same branch they continue to work on. Explaining to them how to fix what they have and how to proceed going forward seems like it requires a very large reply. Several pages. (here's how to fix this PR, this how to fix the state of your main/master branch, here's how to make different branches, here's how to update after each PR, here's what to do if the conflicts are real, here's what to do if you haven't made any more changes to your main branch., here's what to do if you have already made changes to your main branch. I have no suggestions for solutions except to try to point them to other articles/pages/tutorials on the web

jakeva 6y ago
> git complains that somewhere around commit 4 there's a conflict. That sounds like a rebase merge, which might be the setting in the repo. A normal merge wouldn't attempt commit by commit.
darekkay 6y ago
I can relate, and I don't think there's a way around learning Git properly. Here's a quote from a post of mine: > Version control is an underrated skill. Most software engineers use it daily, and yet, many are not willing to invest more than necessary to learn it. That’s fine, but knowing more than commit/push/pull will at least make you more efficient. It will also help you solve issues you (and your colleagues) may encounter. I've had this issue a lot in the past, but mostly at work. So yes, I will spend the time to help my colleague debugging their issue. Eventually, they will get fewer issues, but the time I have to spend for their "learning by doing" would have been better invested in learning Git fundamentals. I've also had some open source contributions during Hacktoberfest, and I went with the easy way out of doing the clean-up work myself. But as you've stated, people might not learn from this, so that's not optimal.

jakeva 6y ago

> git complains that somewhere around commit 4 there's a conflict. That sounds like a rebase merge, which might be the setting in the repo. A normal merge wouldn't attempt commit by commit.

darekkay 6y ago

I can relate, and I don't think there's a way around learning Git properly. Here's a quote from a post of mine: > Version control is an underrated skill. Most software engineers use it daily, and yet, many are not willing to invest more than necessary to learn it. That’s fine, but knowing more than commit/push/pull will at least make you more efficient. It will also help you solve issues you (and your colleagues) may encounter. I've had this issue a lot in the past, but mostly at work. So yes, I will spend the time to help my colleague debugging their issue. Eventually, they will get fewer issues, but the time I have to spend for their "learning by doing" would have been better invested in learning Git fundamentals. I've also had some open source contributions during Hacktoberfest, and I went with the easy way out of doing the clean-up work myself. But as you've stated, people might not learn from this, so that's not optimal.