4 ms·

I agree, but I've been bitten by this more times that I would admit. Usually it's for "silly" things, like updating the readme with the online editor over GitH

by Spittie 13y ago

I agree, but I've been bitten by this more times that I would admit. Usually it's for "silly" things, like updating the readme with the online editor over GitHub (to quickly fix a type for example, when I'm not on my desktop) and then forgetting to do a "git pull" as the next thing on my local branch.

anentropic 13y ago
I don't understand... I do those silly things too quite often and I've never been 'bitten' you try to push and it tells you you can't until you do a pull you do a pull, resolve conflicts if any where is the problem?
- Spittie 13y ago
  You get those "Merge branch 'master' of github.com:Username/Repository" commits, that introduce "unnecessary nonlinearities in the history" (to quote the reply). I mean, it's not an huge problem (and that's why I still use git pull), but it does comport some kind of annoyance.
  - krisdol 13y ago
    It seems that the SO answer doesn't understand that there is a `git pull --rebase` option. It attempts to rebase local commits on top of what was fetched, and by default shows merge issues if the conflicts could not be resolved automatically. It is my default for my workflow, but I will use different merge strategy when necessary (which is almost never).
  - bronson 13y ago
    git pull --rebase would take care of those nonlinearities. In my experience, on projects with a few developers, --rebase is awesome.
- syllogism 13y ago
  Let's say I've got a copy on my server and a copy on my laptop. I fix a typo in the README on the server, as that's the window I've got in front of me. I push the change, but don't pull it onto my laptop. I don't pull the change to my laptop. I fix a different typo, and push it. I pull down the new version on the server. I fix another typo. Now this commit has two parents: the one from the server earlier, and the new one from my laptop. Because it has two parents, it's a merge commit.
  - mcv 13y ago
    But why is that a problem? If you're merging changes from two different sources, of course the merge is going to have two parents. What else do you expect?
  - deleted 13y ago
    [deleted]

by Spittie 13y ago

anentropic 13y ago

I don't understand... I do those silly things too quite often and I've never been 'bitten' you try to push and it tells you you can't until you do a pull you do a pull, resolve conflicts if any where is the problem?

Spittie 13y ago
You get those "Merge branch 'master' of github.com:Username/Repository" commits, that introduce "unnecessary nonlinearities in the history" (to quote the reply). I mean, it's not an huge problem (and that's why I still use git pull), but it does comport some kind of annoyance.
- krisdol 13y ago
  It seems that the SO answer doesn't understand that there is a `git pull --rebase` option. It attempts to rebase local commits on top of what was fetched, and by default shows merge issues if the conflicts could not be resolved automatically. It is my default for my workflow, but I will use different merge strategy when necessary (which is almost never).
- bronson 13y ago
  git pull --rebase would take care of those nonlinearities. In my experience, on projects with a few developers, --rebase is awesome.
syllogism 13y ago
Let's say I've got a copy on my server and a copy on my laptop. I fix a typo in the README on the server, as that's the window I've got in front of me. I push the change, but don't pull it onto my laptop. I don't pull the change to my laptop. I fix a different typo, and push it. I pull down the new version on the server. I fix another typo. Now this commit has two parents: the one from the server earlier, and the new one from my laptop. Because it has two parents, it's a merge commit.
- mcv 13y ago
  But why is that a problem? If you're merging changes from two different sources, of course the merge is going to have two parents. What else do you expect?
- deleted 13y ago
  [deleted]