Yami fails to learn Git
-
I thought I was doing pretty good with git. I thought wrong.
So I have this big old pull request, and it's got merge conflicts. Github.com says I have to merge locally and push. uh oh.
I had originally forked the repo, so I added another remote called
upstream
to my copy. Now I have two: origin, which is my fork, and upstream, which is the original. I am trying to merge from my branch into upstream's master.I did a
git fetch upstream
followed by, on my branch,git merge upstream/master
. I resolved the issues and committed and pushed. Travis failed the build, I fixed that issue, committed, pushed. Both commits show up on the PR... but it's still conflicted.I went back to my local master and did a
git merge upstream/master
. Now that my master is up to date, I switched back to my branch and didgit merge master
. Some of the conflicts came back! I resolved them, committed, and pushed again. That also shows up on the PR.... but it's still conflicted.@accalia was able to fork my fork, and merging upstream into my branch shows conflicts. What the heck do I do to make them go away once and for all? Only one file was actually changed by both upstream and myself; the others are modifications of a file the other person deleted, one on my side and one on his.
This is the PR: https://github.com/visionmedia/debug/pull/378
-
@Yamikuronue
My strategy for this scenario is to dorebase
, which puts your change on top of the upstream branch (an operation which i find easy to understand).
-
@Yamikuronue said in Yami fails to learn Git:
What the heck do I do to make them go away once and for all?
My advice is to delete your PR. Make a new branch based off of the current head of the upstream master branch and put your changes in there and submit a new PR based on that.
-
@boomzilla My changes are pretty extensive.
I gave @accalia write access to my repo and she somehow fixed it by doing exactly what I already did, but from her machine. I guess that works?
-
@Yamikuronue said in Yami fails to learn Git:
@boomzilla My changes are pretty extensive.
I gave @accalia write access to my repo and she somehow fixed it by doing exactly what I already did, but from her machine. I guess that works?
i swear Git smells fear, and misbehaves when it does. :-)
-
Insanity (n):
- Doing the same thing repeatedly and expecting different results
- Using Git
-
@accalia
So git is a puppy? I guess that explains all the messes on the living room carpet.
-
@izzion said in Yami fails to learn Git:
@accalia
So git is a puppy? I guess that explains all the messes on the living room carpet.hmm.... an apt analogy.
-
@Jaloopa said in Yami fails to learn Git:
Using Git
Using Git:
- Doing the same thing repeatedly and getting different results
-
@accalia said in Yami fails to learn Git:
@izzion said in Yami fails to learn Git:
@accalia
So git is a puppy? I guess that explains all the messes on the living room carpet.hmm.... an apt analogy.
Puppies are cute in between being infuriating. Git is never cute.
Also, nobody hates puppies
-
-
This post is deleted!
-
@Jaloopa
I mean, I kind of hate puppies. Especially the upstairs neighbor's puppy. But I've always claimed I'm a bit weird.
-
@Yamikuronue said in Yami fails to learn Git:
@boomzilla My changes are pretty extensive.
They are contained in a couple commit ? cherry-pick is your friend.
-
This is what you get for using a product whose very name means "obnoxious idiot".
Parable of the scorpion, folks...
-
@Yamikuronue said in Yami fails to learn Git:
she somehow fixed it by doing exactly what I already did
she probably made a type or two on the command line forcing git into submission
-
@Yamikuronue said in Yami fails to learn Git:
Both commits show up on the PR... but it's still conflicted.
What? Where did you push to? The PR should have automatically closed when you pushed the merge commit, and the commits definitely should not have shown up in the PR.
-
@Luhmann said in Yami fails to learn Git:
@Yamikuronue said in Yami fails to learn Git:
she somehow fixed it by doing exactly what I already did
she probably made a type or two on the command line forcing git into submission
:git: OMG! It's !
hehehe. Submit!
:git: I bow to your will mistress!
-
@LB_ said in Yami fails to learn Git:
The PR should have automatically closed when you pushed the merge commit
What? Why would it? I merged master into my branch, but I was PRing my branch into master.
-
@Yamikuronue said in Yami fails to learn Git:
@LB_ said in Yami fails to learn Git:
The PR should have automatically closed when you pushed the merge commit
What? Why would it? I merged master into my branch, but I was PRing my branch into master.
Well there's your problem.
-
@Yamikuronue said in Yami fails to learn Git:
My changes are pretty extensive.
It helps if you can avoid doing those sorts of changes.
Which sounds really sententious. I'm sorry. The bigger the change, the more likely it is to conflict with something and cause problems. Smaller changes go more easily. This applies much more so when there are many people working on a codebase (and yes, that's why you don't really want single megarepositories; the code can cope, but programmers probably can't).
-
@dkf said in Yami fails to learn Git:
The bigger the change, the more likely it is to conflict with something and cause problems
But Git is great at merging. People always say it's far better than other source control systems!
-
@dkf said in Yami fails to learn Git:
It helps if you can avoid doing those sorts of changes.
Sometimes you have to refactor a project to remove a tool you don't want to depend on anymore. shrug
-
The problem with the original merge was that it wasn't a merge commit. Here is the log viewed from a graphical tool
The original merge only had one line leading into it from below, meaning it only had one parent (i.e. not a merge commit), whereas accalia's commit had 2 parents (i.e. is a merge commit).
The right thing to do in this case would have been to remove the incorrect merge commit (reset, rebase etc) and re-do it. Right now, you've introduced code changes into your branch that have nothing to do with what you were trying to do.
-
@cark said in Yami fails to learn Git:
The original merge only had one line leading into it from below, meaning it only had one parent (i.e. not a merge commit)
How the hell did the result of
git merge
not be a merge commit?
-
@Yamikuronue detached head?
doesn't have a clue what he's talking about
-
-
@Yamikuronue said in Yami fails to learn Git:
@cark said in Yami fails to learn Git:
The original merge only had one line leading into it from below, meaning it only had one parent (i.e. not a merge commit)
How the hell did the result of
git merge
not be a merge commit?When you attempt a merge and run into merge conflicts, git sets a flag that marks your repo as currently in merge mode. When you resolve the conflicts and do a
git commit
, it knows it needs to create a merge commit because of that flag. Without the flag, git would do a simple non-merge commitI'm guessing you somehow cleared the flag, either by doing a
git merge --abort
or some variation ofgit reset
. If you do agit status
it will tell you whether you're currently in merge/rebase mode. One thing you can watch out for is that if you are doing a merge commit, git automatically fills in the commit message for you (Merge remote tracking branch foo/bar into baz
).
-
@cark said in Yami fails to learn Git:
I'm guessing you somehow cleared the flag, either by doing a git merge --abort or some variation of git reset
I did neither. My shell said "MERGING" the whole time, to boot, and my
git status
listed the files I had left to resolve as I worked through it.Though, I did not get the automatic commit message, because I did finally commit with
git commit -m "Merged from upstream/master"
. Could that have broken it?
-
@Yamikuronue said in Yami fails to learn Git:
@cark said in Yami fails to learn Git:
I'm guessing you somehow cleared the flag, either by doing a git merge --abort or some variation of git reset
I did neither. My shell said "MERGING" the whole time, to boot, and my
git status
listed the files I had left to resolve as I worked through it.Though, I did not get the automatic commit message, because I did finally commit with
git commit -m "Merged from upstream/master"
. Could that have broken it?I just tried the
git commit -m "Merged from upstream/master"
with a merge commit and it worked, so it probably isn't that. (Unless this was a bug they recently fixed. I always use the latest version)At this point, I have no idea
-
@Jaloopa said in Yami fails to learn Git:
But Git is great at merging. People always say it's far better than other source control systems!
Yes
-
Good thing I use per-project VMs; I was able to snag the entirety of the console session
Aha! There's the trouble -- something wrong with my precommit hook
yamikuronue:~/workspace (replace-babel-with-browserify|MERGING) $ git status On branch replace-babel-with-browserify All conflicts fixed but you are still merging. (use "git commit" to conclude merge) Changes to be committed: modified: .eslintrc modified: CHANGELOG.md modified: Makefile modified: README.md modified: component.json modified: package.json modified: src/browser.js modified: src/debug.js modified: test/debug_spec.js Untracked files: (use "git add <file>..." to include in what will be committed) coverage/ lib/ yamikuronue:~/workspace (replace-babel-with-browserify|MERGING) $ git commit -m "Merged from upstream/master. I left the dist/debug in place because my hook now updates it automatically, but I removed the babelrc file since we don't need it anymore." Generating dist make: `dist' is up to date. Distribution generation complete Adding updated files to commit fatal: could not open '.git/MERGE_HEAD' for reading: No such file or directory yamikuronue:~/workspace (replace-babel-with-browserify) $ git status On branch replace-babel-with-browserify Changes to be committed: (use "git reset HEAD <file>..." to unstage) modified: .eslintrc modified: CHANGELOG.md modified: Makefile modified: README.md modified: component.json modified: package.json modified: src/browser.js modified: src/debug.js modified: test/debug_spec.js Untracked files: (use "git add <file>..." to include in what will be committed) coverage/ lib/ yamikuronue:~/workspace (replace-babel-with-browserify) $ git commit -m "Merged from upstream/master. I left the dist/debug in place because my hook now updates it automatically, but I removed the babelrc file since we don't need it anymore." Generating dist make: `dist' is up to date. Distribution generation complete Adding updated files to commit [replace-babel-with-browserify 2a01c6c] Merged from upstream/master. I left the dist/debug in place because my hook now updates it automatically, but I removed the babelrc file since we don't need it anymore. 9 files changed, 65 insertions(+), 12 deletions(-) yamikuronue:~/workspace (replace-babel-with-browserify) $ git push Warning: Permanently added 'github.com,192.30.253.113' (RSA) to the list of known hosts. Counting objects: 13, done. Delta compression using up to 8 threads. Compressing objects: 100% (12/12), done. Writing objects: 100% (13/13), 2.19 KiB | 0 bytes/s, done. Total 13 (delta 10), reused 0 (delta 0) remote: Resolving deltas: 100% (10/10), completed with 10 local objects. To github.com:yamikuronue/debug.git 6a8d525..2a01c6c replace-babel-with-browserify -> replace-babel-with-browserify
-
I wouldn't use a pre-commit hook to do anything non-trivial. If it takes more than half a second, it's going to get annoying really quickly
-
@Yamikuronue said in Yami fails to learn Git:
Good thing I use per-project VMs; I was able to snag the entirety of the console session
Aha! There's the trouble -- something wrong with my precommit hook
yamikuronue:~/workspace (replace-babel-with-browserify|MERGING) $ git status On branch replace-babel-with-browserify All conflicts fixed but you are still merging. (use "git commit" to conclude merge) Changes to be committed: modified: .eslintrc modified: CHANGELOG.md modified: Makefile modified: README.md modified: component.json modified: package.json modified: src/browser.js modified: src/debug.js modified: test/debug_spec.js Untracked files: (use "git add <file>..." to include in what will be committed) coverage/ lib/ yamikuronue:~/workspace (replace-babel-with-browserify|MERGING) $ git commit -m "Merged from upstream/master. I left the dist/debug in place because my hook now updates it automatically, but I removed the babelrc file since we don't need it anymore." Generating dist make: `dist' is up to date. Distribution generation complete Adding updated files to commit fatal: could not open '.git/MERGE_HEAD' for reading: No such file or directory yamikuronue:~/workspace (replace-babel-with-browserify) $ git status On branch replace-babel-with-browserify Changes to be committed: (use "git reset HEAD <file>..." to unstage) modified: .eslintrc modified: CHANGELOG.md modified: Makefile modified: README.md modified: component.json modified: package.json modified: src/browser.js modified: src/debug.js modified: test/debug_spec.js Untracked files: (use "git add <file>..." to include in what will be committed) coverage/ lib/ yamikuronue:~/workspace (replace-babel-with-browserify) $ git commit -m "Merged from upstream/master. I left the dist/debug in place because my hook now updates it automatically, but I removed the babelrc file since we don't need it anymore." Generating dist make: `dist' is up to date. Distribution generation complete Adding updated files to commit [replace-babel-with-browserify 2a01c6c] Merged from upstream/master. I left the dist/debug in place because my hook now updates it automatically, but I removed the babelrc file since we don't need it anymore. 9 files changed, 65 insertions(+), 12 deletions(-) yamikuronue:~/workspace (replace-babel-with-browserify) $ git push Warning: Permanently added 'github.com,192.30.253.113' (RSA) to the list of known hosts. Counting objects: 13, done. Delta compression using up to 8 threads. Compressing objects: 100% (12/12), done. Writing objects: 100% (13/13), 2.19 KiB | 0 bytes/s, done. Total 13 (delta 10), reused 0 (delta 0) remote: Resolving deltas: 100% (10/10), completed with 10 local objects. To github.com:yamikuronue/debug.git 6a8d525..2a01c6c replace-babel-with-browserify -> replace-babel-with-browserify
that would explain why i was able to merge correctly then.... i hadn't installed any npm package so the precommit hook never fired for me.
-
@Yamikuronue said in Yami fails to learn Git:
Aha! There's the trouble -- something wrong with my precommit hook
So, it was a code 18 ? :p
-
@cark said in Yami fails to learn Git:
If it takes more than half a second
It doesn't. Anyway, we've since removed the hook since we found another way around the issue (don't keep the dist folder up to date on commit, but build it before publishing)
-
I would just like to report that I successfully merged on another project when my branch drifted out of date with no issues.
I'd get me hence to yonder cupcake thread, but I'm literally falling asleep at my desk today, I dun wanna.
-
@Yamikuronue said in Yami fails to learn Git:
I'd get me hence to yonder cupcake thread, but I'm literally falling asleep at my desk today, I dun wanna.
Then I shall bring the cupcake thread to you:
http://thecandycakecompany.com/wp-content/uploads/2014/12/Winter-Wonderland-themed-cupcakes.jpg
-
@Yamikuronue said in Yami fails to learn Git:
I'd get me hence to yonder cupcake thread, but I'm literally falling asleep at my desk today, I dun wanna.
I got two words for you: Dark chocolate.
-
-
@dse No, it's really not. Git is plenty capable of screwing up in bizarre ways all on its own.
-
@Yamikuronue Use Bitbucket Fork Syncing.
git pull --rebase upstream master
is what I'd do TBH, but I don't mind doing agit push -f
on my fork.Also why has GitHub not implemented fork syncing? Does Atlassian have a patent on it or something?
-
@masonwheeler said in Yami fails to learn Git:
@dse No, it's really not. Git is plenty capable of screwing up in bizarre ways all on its own.
It depends who is complaining. If it is Yami, it is bound to be something that is not just related to getting confused about DAG