Return-Path: X-Original-To: apmail-flex-dev-archive@www.apache.org Delivered-To: apmail-flex-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 33ACBFE50 for ; Tue, 16 Apr 2013 02:05:17 +0000 (UTC) Received: (qmail 17570 invoked by uid 500); 16 Apr 2013 02:05:16 -0000 Delivered-To: apmail-flex-dev-archive@flex.apache.org Received: (qmail 17542 invoked by uid 500); 16 Apr 2013 02:05:16 -0000 Mailing-List: contact dev-help@flex.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@flex.apache.org Delivered-To: mailing list dev@flex.apache.org Received: (qmail 17530 invoked by uid 99); 16 Apr 2013 02:05:16 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 16 Apr 2013 02:05:16 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of webdoublefx@hotmail.com designates 157.55.2.109 as permitted sender) Received: from [157.55.2.109] (HELO dub0-omc4-s34.dub0.hotmail.com) (157.55.2.109) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 16 Apr 2013 02:05:10 +0000 Received: from DUB118-DS14 ([157.55.2.73]) by dub0-omc4-s34.dub0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 15 Apr 2013 19:04:49 -0700 X-EIP: [Xw9s97LQUPnjYL5n+HSSWqHrWNt0JtCI] X-Originating-Email: [webdoublefx@hotmail.com] Message-ID: From: =?iso-8859-1?Q?Fr=E9d=E9ric_THOMAS?= To: References: <9F6EF460-1153-4520-94A3-ACE6A0F93816@classsoftware.com> <49E60C0C-54AA-4FC0-98F4-42ED57636107@classsoftware.com> <39763F94-758F-4EF3-A38E-901CD7531B51@classsoftware.com> In-Reply-To: Subject: Re: Git merge of README and RELEASE_NOTES Date: Tue, 16 Apr 2013 04:04:46 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3505.912 x-mimeole: Produced By Microsoft MimeOLE V16.4.3505.912 X-OriginalArrivalTime: 16 Apr 2013 02:04:49.0058 (UTC) FILETIME=[C65F5020:01CE3A46] X-Virus-Checked: Checked by ClamAV on apache.org and I just noticed as well, to check the diff on RELEASE_NOTES, use: git diff origin/release4.9 RELEASE_NOTES -----Message d'origine----- From: Fr�d�ric THOMAS Sent: Tuesday, April 16, 2013 3:31 AM To: dev@flex.apache.org Subject: Re: Git merge of README and RELEASE_NOTES Re wrote a bit better I hope: As I said before, in git merge or rebase will apply only on commits, not on files, if you have files with conflicts you want to merge, you will have to go by an intermediary branch (temp), checkout the files you want to merge from the branch where they are, add and commit them into the temp branch, it will indeed add and commit files only if they are different, once committed on a temp branch, from the develop branch you can do a git rebase, it will stop the rebase operation on conflicts, you can then use a mergeTool if it has been configured, you can then continue the rebase. -Fred -----Message d'origine----- From: Fr�d�ric THOMAS Sent: Tuesday, April 16, 2013 3:23 AM To: dev@flex.apache.org Subject: Re: Git merge of README and RELEASE_NOTES > If we want to merge the entire tree would we follow the same process? (eg > like what we have to do after a release) Do you have to do a git mergeTool > on every file? As I said before, in git merge or rebase will apply only on commits, not on files, if you have files with conflicts you want to merge, you will have to go by an intermediary branch checkout the files you want from the branch they are, add commit them, it will indeed add and commit only if the files are different, once committed on this temp branch, from the develop branch you can do a git rebase, it will stop the rebase operation on conflicts, you can then you a mergeTool if it has been configured, you can then continue the rebase. Obviously, if you merge or rebase an entire branch, you don't need to go by an intermediary branch. The good trick is to make your commits atomic, like that, you can merge/rebase this particular commit. > OK I ran "git checkout origin/release4.9 RELEASE_NOTES README" and a "git > status" only show README changed, however "git diff README" shows no > changes, ignoring that I continue. that means only README was changed, you can see the diff running git diff --cached README, apparently the RELEASE_NOTES README are the same, you can check that running git diff develop..release4.9 RELEASE_NOTES > git add -u Means add all my untracked files and the stages ones, that's the reason why I ask you to be on a clean develop branch. > A bit scary: 1 file changed, 36 insertions(+), 63 deletions(-) . See the previous answer. And for the rest, it comes from what I just explained, the only thing wrong in what I wrote was 'git branch -d temp' instead of ''git branch -D temp'. -Fred -----Message d'origine----- From: Justin Mclean Sent: Tuesday, April 16, 2013 2:39 AM To: dev@flex.apache.org Subject: Re: Git merge of README and RELEASE_NOTES Hi, > ok, so, you need to go by an intermediary branch as git merge or rebase > only commits It there a simpler way of doing this? In svn it just a "svn merge" followed by a "svn ci" - assuming you're happy with the merge. If we want to merge the entire tree would we follow the same process? (eg like what we have to do after a release) Do you have to do a git mergeTool on every file? Lets give that a try: > git checkout -b temp > git checkout origin/release4.9 RELEASE_NOTES OK I ran "git checkout origin/release4.9 RELEASE_NOTES README" and a "git status" only show README changed, however "git diff README" shows no changes, ignoring that I continue. > git add -u Why is "-u" needed? > git commit -m "Merge RELEASE_NOTES, etc.. from release4.9 branch" A bit scary: 1 file changed, 36 insertions(+), 63 deletions(-) Why did it do this when "git diff" showed no changes? > git checkout develop Switched to branch 'develop' Your branch is ahead of 'origin/develop' by 1 commit. (use "git push" to publish your local commits) Think that's OK. > git rebase temp At this point if I do a git status I get: # On branch develop # Your branch is ahead of 'origin/develop' by 2 commits. # (use "git push" to publish your local commits) # nothing to commit, working directory clean Which is a little strange as I would of expected changed from the "git checkout develop". > git mergeTool RELEASE_NOTES Gives "No files need merging" So I assume no need to to do a "git rebase --continue"? Try "git mergeTool README" and I also get "No files need merging" This is not what I expected I know it made changes to the file in the commit above. git status give at this point: # On branch develop # Your branch is ahead of 'origin/develop' by 2 commits. # (use "git push" to publish your local commits) # nothing to commit, working directory clean What are here 2 commits when I've only done one? > git branch -d temp deletes branch If at this point if I do this "git diff --stat origin/develop" I get: README | 99 ++++++++++++++++++++++++++++++++++++--------------------------------------------------------------- RELEASE_NOTES | 26 +++++++++++++++++++++++++- Why is it saying both README and RELEASE_NOTES have changed when only one file was changed with the commit? Looking at the changes (via "git diff origin/develop") to README I see that it has merged the files incorrectly and certainly not what I expected. It's removed the more recent changes about FP 11.7 and AIR 3.7, using git rather than svn and changes to TLF but it did add the single line that changed the version number 4.9 to 4.9.1. RELEASE_NOTES have similar issues. Why did this not merge as expected? Why did "git mergeTool" say in both cases "No files need merging" when it obviously has (incorrectly) merged the files? Obviously Im not an expert git user and just know enough to keep getting myself into trouble. :-) I am just trying to understand what is going on here as currently it really doesn't make any sense to me at all and worse looks like it done the merge mostly in reverse? Thanks, Justin