top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

How to do a recursive merge on 'master' using GIT?

0 votes
319 views
How to do a recursive merge on 'master' using GIT?
posted Apr 11, 2018 by Deepti Singh

Looking for an answer?  Promote on:
Facebook Share Button Twitter Share Button LinkedIn Share Button

Similar Questions
+1 vote

I have a large Git project which I would like to dissect into subprojects with their own repositories. Git subtrees are ideal for this task: I first

  • create a branch with the contents of only one subfoldergit subtree split -P -b

and then

  • pull this branch into another repository.

For a transitional phase, I would like to have the subprojects read-only and sync them from master. The question is how to organize this. For every commit to master, I could of course perform the above procedure repeatedly for all subprojects, but this seems less then ideal since it does all the work all over again.

Is there a way to merge master into the subtree branches?

+2 votes

I am learning, and experimenting. I was experimenting with "git merge", forgot the "--no-commit", and discovered the hard way that aborting the editor that comes up without saving does NOT abort the merge.

And git merge --abort fails, because the merge succeeded.

Git Gui has a way to amend the comment of the last merge, but no way to undo it. I figure this should be simple, but I don't know how.

0 votes

I work on some files and push/merge them to the remote server. Sometimes I get merge conflicts on those files and have to fix them. That's completely fine. I get that.

What I don't understand is that sometimes during this process I will get merge conflicts in files _I have never touched_. In fact they are in a completely different series of directories to the one I am working on and someone else project entirely. How am I meant to know how to fix these? I dont know what the other developer wanted to do and if they have done it right.

I thought git only merged/pushed the files you have changed? If someone else has changed Group A files on the remote repo, why must I change my local Group A files when I am _pushing _completely different set of Group B files?

Sure, Id understand if I were pulling files down to my local and had to resolve merge conflicts then, but this isn't happening when I push the files up.

Any help or advice is much appreciated. Sorry if I sound frustrated - I am really trying hard to get my head round this whole git thing but its just so weird.

+1 vote

In my superproject I have two submodules and I want them to track always master master. Using Git 1.8.2.
So I've added "branch = master" to .gitmodules and using git submodule update --remote to pull always recent master.
However everytime submodule master is updated, running superproject git status or diff shows its recorded sha1 has changed.
This doesn't make sense since I am tracking master? Shouldn't it show it has changed only when submodule HEAD is not the branch recorded in my superproject's .gitmodules ??

0 votes

At $dayjob we maintain internal forks of the a number of upstream repositories.

Unsurprisingly updating these forks can be extremely problematic, especially when it's only one person doing the merge. Fortunately most of us are in the same physical location so it is possible to drag in someone who knows more about the code than the person merging but I can't see that scaling with remote developers.

Is there any way where we could share the conflict resolution around but still end up with a single merge commit. I'm thinking of something like the following workflow

developer A:
git merge $upstream

git mergetool ...

git commit -m "WIP: Merge upstream" --something-like--all-but-not

developer B:
git pull developer_A
git reset HEAD^

git push

Any thoughts on if something like this is currently possible? Is this something other git users would find useful?

...