Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should we show an automatically resolvable merge conflict first? #728

Open
edbennett opened this issue Mar 3, 2020 · 2 comments
Open

Should we show an automatically resolvable merge conflict first? #728

edbennett opened this issue Mar 3, 2020 · 2 comments

Comments

@edbennett
Copy link
Contributor

edbennett commented Mar 3, 2020

Currently in Conflicts the learner encounters GitHub rejecting their push for the first time, and then on pulling encounters a merge conflict that must be resolved manually.

This conflates two ideas—GitHub rejecting a commit, and conflicts that cannot be automatically resolved. It may also give the idea that any time the same file is edited by two people, it will generate a conflict that must be resolved manually. Since once of the good things about Git is its powerful conflict resolution, it would be good to avoid this impression.

Should we instead first introduce a change that Git can automatically resolve, before then making a second change that requires a manual resolution? This would give the learner a clearer picture that GitHub rejects all pushes that contain work not available locally, and also show that most of the time Git takes care of merging, with merge conflicts being a fallback used only in the minority of cases.

If we agree this is a good idea, I'm more than happy to draft the changes to the episode.

@kekoziar
Copy link
Contributor

kekoziar commented Jul 26, 2021

@edbennett Thanks for the comment. It sounds like what you're describing is collaborating, but where different lines of the same file are modified at the same time. However, there is a problem that adding another example adds time to the lesson. Since the lesson already has more content than a workshop has time for, what do you propose is removed?

@edbennett
Copy link
Contributor Author

edbennett commented Oct 30, 2021

This is a good point. I think this addition would add 5, maximally 10 minutes to the episode, but that some of this would be compensated by less confusion around the conflict that Git can't automatically resolve.

The lesson is already relatively streamlined, including almost the minimal possible content to get from "nothing" to "able to push and pull to GitHub and resolve conflicts when they occur". I do think some of the callouts in episode 4 could be trimmed or streamlined. For example, in "Limit log size", the -1 option isn't one I've ever found useful, and --graph isn't particularly useful until you start to use branches.

If we choose not to include an extra piece of live code on this, I think at a minimum there should be an extra couple of sentences added in this section explaining that Git can resolve conflicts automatically, unless they affect the same or adjacent lines of text (ignoring binary files, which we don't cover anyway). Currently a learner can easily get the mistaken impression that any commit that touches same file, or even any commit that happens on the remote in between pulling and pushing, causes a conflict that must be resolved with the workflow described in the lesson.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants