2

I've been using SVN for some time and is now using Git on a project. I am unsure exactly what to do after I've resolved conflicts after I've done a git pull. I am using tortoise GIT by the way.

So in most cases I can do my commits and then pull and it will automatically merge and I can proceed to push. However if there is a conflict, it asks me to solve the conflicts. I do that using the built in tools for tortoiseGit. Then it asks me to commit, and I get big list of every single modified file in the project.

Now, many of these are local changes should never be committed.. but I read this git blog: http://randyfay.com/node/89 , more specifcally:

One user of Tortoise Git would do a pull, have a merge conflict, resolve the merge conflict, and then look carefully at his list of files to be committed back when he was committing the results. There were lots of files there, and he knew that the merge conflict only involved a couple of files. For his commit, he unchecked all the other files changes that he was not involved in, committed the results and pushed the commit.

How do I know which files I must select and commit to now screw up the state of the git repository?

EDIT: This sums it up nicely, something that has occured to me, we fixed but we need to understand how to prevent in the future.

When several people are committing... and I pull their work into mine, by default an automatic merge takes place. I have to push that merge commit back and not mess it up, or things go bad.

The situation I'm describing happened when a pull with its automatic merge happened. Most of the merge (as usually happens) was successful. But one thing conflicted. The conflict was resolved. But in this case the developer didn't commit all the other things (that were successfully merged and automatically added to the index.). He only committed the thing that he had resolved (that he understood). He didn't know that he was responsible for all that other merged stuff that had been successfully merged and added to his index. That's the story of this disaster.

KaiserJohaan
  • 9,028
  • 20
  • 112
  • 199
  • If you have a large number of locally modified files you don't want to push in the branch you're pushing from, that's usually a sign you're doing something odd. – Wooble Aug 07 '12 at 12:38
  • Is there a reason that what you commit would potentially build locally but not from the repository after you commit? Or are you saying that if your code changes `function foo(x)`, you're worried about everywhere `foo(x)` is called not knowing of the change? Or that a developer might simply `merge` incorrectly? Now *that* happens all the time. "I know my code; I don't know your code. I merge anyway. Merge borked." Welcome to [users using] git. ;^) – ruffin Aug 07 '12 at 12:50
  • Can you explain, "many of these are local changes should never be committed" when those changes are [?] related to fixing the code? – ruffin Aug 07 '12 at 13:00

2 Answers2

1

EDIT2: I think I've caught up. Sounds like folks are pushing their changes without regression testing locally first, or regression testing and only staging the file that initially had conflicts. That is bad. git commit -a?

It also sounds like there aren't enough branches and the current workflow has everyone committing very different, un-normalized work to the same repo. If you're losing time from bad merges, configure the project so that developers aren't interacting until necessary. From the article linked in your question:

The second alternative is promoted or assumed by Github and used widely by the Linux Core project (where Git came from). In that scenario, you don't let more than one maintainer push to the important branches on the authoritative repository.

So maybe I'm missing something.

This article on branching workflows might be a good read.

EDIT: Ah, with the edit, perhaps you're arguing for a workflow based on fetching instead, as the first commenter on your linked article ran into.

What is the difference between 'git pull' and 'git fetch'?

If you're saying that sometimes a poorly informed merger can unintentionally mis-merge good code, you are correct. Merging is a fine art at times, and often requires bugging the other developers directly to pair merge changes. (I enjoy looking through git blame first.)

Community
  • 1
  • 1
ruffin
  • 16,507
  • 9
  • 88
  • 138
0

I suppose that first, you should commit only the files you edited, you should probably know what they are.

You can figure which files have been modified in the last commits, even though I don't know TortoiseGit there is probably a History feature.

For the future, I recommend you to create a .gitignore file at the base of your local copy of the repository and list all the files you know you will never commit (such as .project, .settings and stuff like that, and including .gitignore). Indeed, Git scans your filesystem to know which file is changed and sometimes it's not useful.

If you need more info : http://www.kernel.org/pub/software/scm/git/docs/gitignore.html

Vince
  • 1,570
  • 3
  • 27
  • 48
  • Ah, if it's IDE specific stuff/overhead (or any file that's not part of the "code") that's popping up, then this is a better answer. I can't tell if "every single modified file in the project" means "files that should never hit the repo" or not. – ruffin Aug 07 '12 at 12:44
  • OK, I see your problem. So first, figure what you did and what come from IDE or other external tools. Then, there are probably features in TortoiseGit to figure what happened. I only used command line so I can't tell, but you probably want to list the files changed when you pulled from repo. Then you would want to run a "diff" on files you actually merged (those you probably edited). You need to be patient, though. Note: you can commit as much as you want. Only "push" will be annoying for your colleagues – Vince Aug 07 '12 at 12:50
  • (Note that though I posted the first comment here, I'm not the OP -- was just trying to figure out his question) – ruffin Aug 07 '12 at 12:59