> In the current SVN workflow we record the history > about that and we see all related commits of this merge
Sigh. My opinion on SVN merges are quite the opposite -- at the low-level (which I had to go to, unfortunately) they are nothing *but* recorded merge history -- they're path-copy and aggregated diff commands that originate from nowhere... The "mergeinfo" property you refer to is not really a solution here, it's a workaround for an architectural flaw. > So what’s the right way to merge 3 commits from trunk (now master) to > branch_5x? Cherry-Pick and the commit and push? A git merge has two parent branches. So you merge changes on another branch inclusively (all of them). For example, in the git history of Solr and Lucene, a "merge" commit between the two projects effectively means "take all patches from solr + take all patches from Lucene and apply them". You can amend the merge commit and revert or modify certain bits, but it can be confusing (and I agree with Mark here). My personal preference is to work with individual commits, so yes, the workflow would be something like this: git checkout master # changeset1 git add -A . && git commit -m "changeset1" # changeset2 git add -A . && git commit -m "changeset2" # changeset3 git add -A . && git commit -m "changeset3" git checkout branch_5x git log master # note hashes of commits you wish to apply on the branch git cherry-pick hash-changeset1 hash-changeset2 hash-changeset3 The result would be three commits on master and three (identical) commits on branch_5x. If a changeset cannot be applied cleanly, git will let you know -- you can then either abort a cherry pick or modify the changeset and apply it on the branch. Note that if you're working on something you would squash the interim commits into one and then it's just one cherry pick to any of the maintenance branches you wish to apply it to. > just know how to use TortoiseGit and I see many buttons and checkboxes there > that I don’t know. Calm down and give it some time, although I have no clue what TortoiseGit looks like... The advantage of working with command line is that it's the same everywhere (windows, linux, mac). > I want to see that those merges came from trunk/master in history. If you cherry pick a commit you won't see it as a merge. It is an "apply this commit's diff and log to another branch" command, it has nothing to do with merging. > For large feature > branches where more than one comitter are working on, we should of course > keep history and not only the final merge. You will grow to dislike this type of workflow with git if you then intend to apply the same feature to another branch... Yes there are workflows that make heavy use of branches, but they do require some understanding of what can be merged and where. I think it's not the right moment to introduce these. Think of a patch in Jira -- if it's self contained, you can just take it and apply it elsewhere. A merge commit of 40 commits that forked from the mainline is like taking those 40 patches that have occurred since the branch was forked and applying them successively back to the mainline. But if you have another branch, forked at a different "parent" commit then a merge of the feature branch is not just 40 patches -- their entire diverging history of parent commits needs to be considered. The closest thing to svn's "merge reintegrate" would be to copy and rebase those 40 commits from the feature branch and then apply it again, but this is where you're getting into more advanced workflows. I'd stick with simple cases, at least at the beginning. Dawid --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
