4 ms·

'git commit -a' is not the answer to your merge problem. You should 'git add <file-you-merged>', then commit.

greendestiny 16y ago
You'd still need to commit the files you pulled (that have changes) though right? Which is sort of fundamental to the whole distributed VCS, it doesn't matter that they were committed in the pulled repository, you have to commit them in the new one.
MikeTaylor 16y ago
That doesn't work. The "git add README.md" completes with no output, but thereafter, "git commit README.md" still fails with "fatal: cannot do a partial commit during a merge."
- llimllib 16y ago
  just "git commit" after that, not "git commit README.md" edit: it's infuriating that yc won't let me reply to you, so I have to reply in this edit. Anyway. "git commit" says to git: "move anything in the index (i.e. things which I have 'git add'ed, or which have been merged) into the local repository". "git add FILE && git commit" says "put FILE in the index and then commit the whole index to the local repository" "git commit FILE" says "assume the index is clear, and only commit FILE" to which git says the logical response, "sorry, dude, the index isn't clear, I can't do that" perhaps this will help: http://osteele.com/archives/2008/05/commit-policies http://osteele.com/archives/2008/05/commit-policies
  - MikeTaylor 16y ago
    Oh! Well, thank you. Yes, I see that that works. But: (A) I see that it still commits everything, just like "commit -a", including all the files that I didn't change but that my colleague did in the branch that I'm pulling; and (B) Why would "git add FILE; git commit" but "git commit FILE" not work? I bet it's something to do with the index.
    - pyre 16y ago
      > (A) I see that it still commits everything, just like "commit -a", including all the files that I didn't change but that my colleague did in the branch that I'm pulling; and 'git commit' commits everything that is currently in the index. 'git commit -a' commits all files currently tracked by git in their current state (if the version in the index and in the working directory differ, IIRC, the version in the working directory is used). It's the equivalent of a "git add FILE" for all tracked files with outstanding changes, right before a 'git commit'. > (B) Why would "git add FILE; git commit" but "git commit FILE" not work? I bet it's something to do with the index. The index is meant to be the 'staging area' where you can pick and choose what you want to commit. See "git add -p FILE" for an example of more complex usage of the index than just picking and choosing which files to commit. In general, think of 'git add' as your ability to promote changes from the working directory to the index, and 'git commit' as your ability to create a commit from the contents of the index.
      - prodigal_erik 16y ago
        > you can pick and choose what you want to commit How is that supposed to be a reasonable thing to do? Unlike my working directory, I can't build and test the contents of the index. To me, making a commit that I've never tested is somewhere between sloppy and negligent, so why is git encouraging me to do it?
        pyre 16y ago
        I think that your issue is that you're thinking of a commit in git in the same way that you would think of a commit in svn. They are not the same. To commit in svn you are forced to push to the remote repo. Therefore you screw everybody up if your commit hoses things. In git, you can commit locally, and you are not even required to push those changes out. You could trash those commit without anyone ever knowing that you made them. You could make small atomic commits of small changes, and when the feature is ready to be pushed out to the 'canonical' repo, you could squash all of those small commits into one large commit, then push it out.
  - smallblacksun 16y ago
    This is exactly the kind of unintuitive behavior that he was complaining about.
    - thenduks 16y ago
      The thing is that it is intuitive if you only take some time to learn the new tool's features and how it is effectively used. Simply treating it like svn wont work. Yes you can 'get by' with some svn-like behaviors, but really dvcs is an entirely new thing you will have to learn to make sense of. Here's an analogy. Svn is a horse and git is a car. You can imagine all these horse-riders (and there are tons of them) sitting around in a bar saying to each other "these new cars? What is up with them? It makes no sense that you change 'gears' and push pedals to stop and go! I just want to <insert whatever you do to ride a horse> and I'll get to my destination!" -- Well, yea, horses work fine a lot of the time. But it's 2010 (1910? :)) and I have more eclectic needs in my change management. I'm willing to invest some time in learning it just like I was willing to invest time into learning vim, or Erlang, or anything else of value.
llimllib 16y ago
Also, doesn't it tell you to do thst when the conflict happens? edit, yup: $ git status # On branch master # Your branch and 'origin/master' have diverged, # and have 1 and 1 different commit(s) each, respectively. # # Unmerged paths: # (use "git add/rm <file>..." as appropriate to mark resolution) # # both modified: readme # no changes added to commit (use "git add" and/or "git commit -a")
- MikeTaylor 16y ago
  Nope.
  - llimllib 16y ago
    see above, I edited to add what I'm talking about
    - MikeTaylor 16y ago
      My bad, I was wrong on this. I would just delete my comment, but that would leave your replies looking dumb. Instead, feel free to downvote my earlier "Nope." into oblivion.
      - llimllib 16y ago
        No worries, color me unoffended. I should have generated the message I was talking about before I posted anyway.
  - pyre 16y ago
    I'm confused about what part of: (use "git add/rm <file>..." as appropriate to mark resolution) is confusing...

You'd still need to commit the files you pulled (that have changes) though right? Which is sort of fundamental to the whole distributed VCS, it doesn't matter that they were committed in the pulled repository, you have to commit them in the new one.

MikeTaylor 16y ago

That doesn't work. The "git add README.md" completes with no output, but thereafter, "git commit README.md" still fails with "fatal: cannot do a partial commit during a merge."

llimllib 16y ago
just "git commit" after that, not "git commit README.md" edit: it's infuriating that yc won't let me reply to you, so I have to reply in this edit. Anyway. "git commit" says to git: "move anything in the index (i.e. things which I have 'git add'ed, or which have been merged) into the local repository". "git add FILE && git commit" says "put FILE in the index and then commit the whole index to the local repository" "git commit FILE" says "assume the index is clear, and only commit FILE" to which git says the logical response, "sorry, dude, the index isn't clear, I can't do that" perhaps this will help: http://osteele.com/archives/2008/05/commit-policies http://osteele.com/archives/2008/05/commit-policies
- MikeTaylor 16y ago
  Oh! Well, thank you. Yes, I see that that works. But: (A) I see that it still commits everything, just like "commit -a", including all the files that I didn't change but that my colleague did in the branch that I'm pulling; and (B) Why would "git add FILE; git commit" but "git commit FILE" not work? I bet it's something to do with the index.
  - pyre 16y ago
    > (A) I see that it still commits everything, just like "commit -a", including all the files that I didn't change but that my colleague did in the branch that I'm pulling; and 'git commit' commits everything that is currently in the index. 'git commit -a' commits all files currently tracked by git in their current state (if the version in the index and in the working directory differ, IIRC, the version in the working directory is used). It's the equivalent of a "git add FILE" for all tracked files with outstanding changes, right before a 'git commit'. > (B) Why would "git add FILE; git commit" but "git commit FILE" not work? I bet it's something to do with the index. The index is meant to be the 'staging area' where you can pick and choose what you want to commit. See "git add -p FILE" for an example of more complex usage of the index than just picking and choosing which files to commit. In general, think of 'git add' as your ability to promote changes from the working directory to the index, and 'git commit' as your ability to create a commit from the contents of the index.
    - prodigal_erik 16y ago
      > you can pick and choose what you want to commit How is that supposed to be a reasonable thing to do? Unlike my working directory, I can't build and test the contents of the index. To me, making a commit that I've never tested is somewhere between sloppy and negligent, so why is git encouraging me to do it?
      - pyre 16y ago
        I think that your issue is that you're thinking of a commit in git in the same way that you would think of a commit in svn. They are not the same. To commit in svn you are forced to push to the remote repo. Therefore you screw everybody up if your commit hoses things. In git, you can commit locally, and you are not even required to push those changes out. You could trash those commit without anyone ever knowing that you made them. You could make small atomic commits of small changes, and when the feature is ready to be pushed out to the 'canonical' repo, you could squash all of those small commits into one large commit, then push it out.
- smallblacksun 16y ago
  This is exactly the kind of unintuitive behavior that he was complaining about.
  - thenduks 16y ago
    The thing is that it is intuitive if you only take some time to learn the new tool's features and how it is effectively used. Simply treating it like svn wont work. Yes you can 'get by' with some svn-like behaviors, but really dvcs is an entirely new thing you will have to learn to make sense of. Here's an analogy. Svn is a horse and git is a car. You can imagine all these horse-riders (and there are tons of them) sitting around in a bar saying to each other "these new cars? What is up with them? It makes no sense that you change 'gears' and push pedals to stop and go! I just want to <insert whatever you do to ride a horse> and I'll get to my destination!" -- Well, yea, horses work fine a lot of the time. But it's 2010 (1910? :)) and I have more eclectic needs in my change management. I'm willing to invest some time in learning it just like I was willing to invest time into learning vim, or Erlang, or anything else of value.

llimllib 16y ago

Also, doesn't it tell you to do thst when the conflict happens? edit, yup: $ git status # On branch master # Your branch and 'origin/master' have diverged, # and have 1 and 1 different commit(s) each, respectively. # # Unmerged paths: # (use "git add/rm <file>..." as appropriate to mark resolution) # # both modified: readme # no changes added to commit (use "git add" and/or "git commit -a")

MikeTaylor 16y ago
Nope.
- llimllib 16y ago
  see above, I edited to add what I'm talking about
  - MikeTaylor 16y ago
    My bad, I was wrong on this. I would just delete my comment, but that would leave your replies looking dumb. Instead, feel free to downvote my earlier "Nope." into oblivion.
    - llimllib 16y ago
      No worries, color me unoffended. I should have generated the message I was talking about before I posted anyway.
- pyre 16y ago
  I'm confused about what part of: (use "git add/rm <file>..." as appropriate to mark resolution) is confusing...