16

My office uses Git and SourceTree for our version control. This came about because when I joined there was zero version control and SourceTree was the only system I had ever used. I am not an expert by any means, but I am the most experienced out of my coworkers so I am the de facto expert responsible for teaching everyone to use Git properly and fix any mistakes they are making.

I am making a tutorial document that goes through Git and SourceTree and explains every step of the process. In the Pull process, the SourceTree dialogue allows you to select the option "Commit merged changes immediately". I understand what this does and why it is useful. What I don't understand is why anyone would not want to use this feature.

Could someone explain why you would ever not want to have your merged changes committed automatically? I am trying to understand the reasoning so I can explain the feature's usefulness better and get an idea of what pitfalls to look out for in the future.

Edit: I do not believe my question is a duplicate of the linked question. The linked question is broadly asking how often to commit. I am asking about why one would choose not to use a specific feature related to commiting merges in SourceTree.

  • Possible duplicate of git / other VCS - how often to commit? – gnat Jan 19 '18 at 21:18
  • 1
    Do you want good reasons? Because I can provide a variety of reasons to delay checking code that I've heard people say in the wild, but few of them are good reasons. – whatsisname Jan 19 '18 at 21:23
  • The only reason I can think of is when a merge fails due to merge conflicts. But SourceTree won't commit if that happens anyway. – Robert Harvey Jan 19 '18 at 21:53
  • On a side note: Why are you writing your own tutorial? bitbucket has a great tutorial already.confluence.atlassian.com/bitbucket/… – winkbrace Jan 25 '18 at 22:19
  • @winkbrace We aren't using Bitbucket; we keep everything on a local network. I do reference Atlassian's great tutorial, but I wanted something a little more concise I could hand to people who were brand new to Git and version control. It's really more an introduction and procedural "this is how and why you commit/push/pull/etc" so people can hit the ground running. – David K Jan 26 '18 at 12:45
26

I would not want to use this feature.

The fact that there were no conflicts means pretty much that the changes being merged in my branch are roughly not in the same lines of code as the ones I've made. It does not mean that those changes are compatible with my changes. It does not mean that the code will compile, or that the code will work, or that the tests will pass.

In other words, by using this option I potentially end up with a spurious commit of code that may not be in a good state and which requires a new commit to fix. As I am doing this work anyways, and as I should never push this spurious commit upstream, not even by mistake (Goodness forbid, someone may then merge that into some other branch!), I see no reason to create this commit in the first place.

  • Presumably, you're creating feature branches, and not merging every little change onto the main branch. Merges are unlikely to cause conflicts on a feature branch unless multiple people are working on the same class on the same feature branch. – Robert Harvey Jan 19 '18 at 23:57
  • 4
    @RobertHarvey Yes but I presumably frequently merge the main branch into my branch. There is a hidden assumption in your comment that different features will naturally touch different classes/modules, but not everyone is lucky. By (mis)fortune you have a God class somewhere that everyone who does anything needs to touch, and you cannot do much about it. Also there are cross-cutting features (upgrade some library because of which one of every 10 lines of code needs to change...) I know the argument "try to not get there", but what if you are already there? Better safe than sorry. – user285148 Jan 20 '18 at 0:02
2

After a merge, there may be changes to files in the local repo. These changes are not automatically committed to the local, unless you set "Commit merged changes immediately".

If you don't set that option, the files appear in SourceTree as uncommitted changes.

That's because Git itself doesn't commit unless you explicitly tell it to, and SourceTree is a Git GUI. The "Commit merged changes immediately" option is not so much an option, as it is a command shortcut.

So, the reason for not wanting to use this feature is self-evident: you want to perform the commit manually, or not at all.

Let's say you pull master to your feature branch. A co-worker is working on a different feature branch. This co-worker has a history of breaking things. The merge contains changes to shared common code made by this co-worker. So, you -- along with the rest of the team -- don't commit merged changes until you are sure that there are no changes made by this co-worker that will affect your work.

Just because there is no good reason -- in theory -- to not use this feature, in reality, there can be any number of good reasons. With regard to your tutorial, I would just say that "99 times out of 100, this is the option you want to use". I don't think you really need to go into detail about not using it, especially if the others are new to version control. That all depends on how in-depth you intend for the tutorial to be.

2

If you are using a post commit hook to auto push your commits (as in https://stackoverflow.com/a/7925891/6781678), you might need this option to avoid pushing some commit of dubious quality.

I would never use either.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.