nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

1 Commit but I have multiple "push"

jmejiaa1986

I've been using Sourcetree for a couple of weeks with great results. I have a doubt about the counts and what they really mean.

Say that I have 4 pulls to do, and uncommited files. I do the following:

1.Commit

2.Pull

3.Push

After I pull my files, I have 2 push to do.. But why? Should I just be pushing my 1 commit?

Also, can I tell what files will be part of the push? I can't seem to find it anywhere.

Accepted answers

All comments

KieranA

Hi John,

This doesn't sound unusual at all. When you pull what actually happens (assuming you're using Git) is that it fetches the changes and merges those changes into your branch. If those pull changes conflict with some other changes you've made then it will merge them in creating a 'merge commit'. There's no indication of this visually but that's what's happened. It means a new commit will be created locally. This is quite a common thing to happen when working in teams. So technically you should be pushing two commits in that case.

As for telling which files will be part of the push, one way to find this out is to look at the ahead count in the log view, then select the commits (use shift) which will be pushed, then look at the file changes in the log view to see what will get pushed.

You can see from this image that the entire branch is new as it's "2 ahead".

Hope that helps, feel free to ask more questions if you need.

jmejiaa1986

Thanks.. That doesn't quite make sense in my scenario, I only have 1 file that I am working on.. So when I pull I expect the other files in my local to now be up to date and only one file changed(the one I'm working on).. Why would I have more than one push since I'm essentially up to date with the repo except this one file?

KieranA

The question you have to ask is whether that 'one file' was in a changeset from which you pulled (in any downstream changes). If the answer is yes, then you can expect an extra 'merge commit' from the fetched and merged changes.

jmejiaa1986

No, there were no changes to that file.. What's even stranger is that it went from 1 push to 3 in this scenario..

I'll see if I can get better details next time since you pointed out how I can tell what has changed. Maybe if I don't do a automatic commit I can figure out exactly what it's doing.

KieranA

OK that's useful to know. It'd be good to see the commits and what's actually in the commits. Do let me know when you spot it, I'll see your response via my e-mail through here.

jmejiaa1986

So I juist tried this. I did a commit on multiple files, at this point I have 1 pull and 1 push.

I confirmed the files to be pulled were not files I have changed, I pulled with commiting, and I can see these are two files I did not touch. So when I commit i expect these two files to now be up to date with the repo.

Once I commit, I see two push. Now, why do I have a second push for this commit that I just made? If this commit essentially brings these 2 files up to date with the repo. What exactly am I pushing, the same 2 files again? even though I'm not making changes to them?

Shawn Fox1

For what it is worth, I am having the same trouble in understanding how this works. I can't push my commits until I pull everything that changed on the remote branch. However, this creates an additional merge, and commit even though nothing in the list of pulled files conflicts with what I changed locally. So whenever I pull in changes while working on something else, I always end up having to do a merge and additional commit for changes to files that I never made, and that do not conflict with anything that I have done. That seems counterintuitive to me.

KieranA

Merge commits are created because there's two separate lines of development which are on the same branch. A merge happens even if there's no conflicts if there are changes to pull before you've pushed yours. Your history has diverged as a result and so the two lines of development need to merge together. There might not be any conflicts at all, the merge commit will determine this and you'll be prompted for the necessary action if so.

The merge commit then can allow you to go through the merge process and thus resolve any conflicts if any. There may be no conflicts at which point a merge commit just gets created automatically.

If you want to avoid this from happening then you need to make sure you auto-rebase the changes when pulling in a diverging line of development. In SourceTree the default setting is to rebase rather than merge. In the pull sheet there's a checkbox that says "Rebase instead of merge". If this isn't checked then it'll create a merge commit when pulling down changes if the lines of development have diverged.

It can seem confusing if you use this option, because the question is 'why did you have to create that commit?'. The answer is that it didn't, it's just your Git settings will cause an explicit merge commit to be created so it's clear that the two lines of development merged together. Some teams like to know this as it's very important to know that multiple people were working on the same branch at the same time as the only other way to tell is by looking at the commit dates and noticing they're not in date order (out-of-order commits).

HTH

jmejiaa1986

The commit is because those changes need to be applied to your local repository, so that first commit makes sense to me.

What doesn't make sense is why do I need to push this commit, if the remote branch alreayd has these changes.