top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

Merge commits in GIT

+1 vote
404 views

I have a question about merge commits. Now when I perform git pull from somebody. Sometimes I'm getting a merge commit where I should write a merge commit message. Sometimes it does not happen, I just hit the git pull and it pulls the updates without creating a merge commit.

What is the difference? note that the files modified in the new commit -when getting a merge commit- are only maintained by a single user. And how can I avoid these merge commits as long as the file is maintained by one user ?

posted Jul 1, 2015 by anonymous

Share this question
Facebook Share Button Twitter Share Button LinkedIn Share Button

1 Answer

0 votes

This happens depending on how the history of the repos has diverged. Basically when you make a pull you are doing a fetch and a merge in the background. So there are two types of merges, one of them ends with a commit merge the other dont.

Its better explained in https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging

answer Jul 1, 2015 by Majula Joshi
Similar Questions
+1 vote

I have two branch in one repository that I need to maintain for 2 different deliveries.
Say branch1 and branch2 in test.git repo.

test.git
- branch1
foo_v1/text.txt
foo_v2/text.txt
- branch2
foo/text.txt

branch1 is developers branch all source looks version'ed manner and branch2 is superset for branch1, example foo_v1 and foo_v2 are the directories in branch1 where developer will update the latest one here foo_v2 and branch2 foo is same as the latest one of branch1 for an instance.

Suppose developer send 10 patches on branch1 where are changes in terms of _/ then I need to apply on my local repo branch1, till now is fine then I need to apply same 10 patches on to my branch2 where source tree which is quite question here how can I do.

0 votes

There are shorthands for going back from HEAD, but not for the initial commit, AFAICT.

I often want to do this when rebasing, and have come to tagging the initial commit in my repos with INITIAL.

Is there a better syntax I'm missing?

+2 votes

Can someone help me on how to delete an intermediate commit?

+1 vote

I have many commits: A, B, C, ..., Z. I plan to do some housekeeping using rebase. One thing I want to do is to reorder Z to be the first commit. However, other commits will be in conflict with Z's changes. I know I can go through and interactively resolve the conflicts manually. But this is tedious and error prone. I would like to be able to mark Z's changes as authoritative while rebasing. That is, I want to tell git, "whenever a commit conflicts with Z (during this rebase operation) I want you to keep Z's changes and ignore the other." Is this possible? Is there another (hopefully better) way to accomplish what I'm trying to do?

+2 votes

In coreboot we try to check for whitespace errors before committing. Of course a pre-commit hook is the way to go, but unfortunately it is not so simple (at least for me) as the following requirements exist.

  1. Only the files actually committed should be checked. That means running git commit -a, abort that and then running git commit some/file should only check some/file for whitespace errors.

  2. There are certain files that are allowed to have whitespace errors. In our case these are *.patch and *.diff files which by design seem to contain whitespace error.

Currently the whole tree is checked, which takes a lot of time. I tried to come up with a patch, but failed so far. Best would be to have

$ git diff --check --only-committed-files --exclude "*patch$"

where I could not find a way for the last to switches.

Currently, I would use

$ git diff-index --cached --name-only $against -- | grep -v patch$

and pass that list to some whitespace check program. Unfortunately that still does not fulfill the first requirement. What am I missing to solve this elegantly?

...