Return-Path: X-Original-To: apmail-hadoop-common-dev-archive@www.apache.org Delivered-To: apmail-hadoop-common-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 4AF8711D3F for ; Wed, 3 Sep 2014 01:48:25 +0000 (UTC) Received: (qmail 18658 invoked by uid 500); 3 Sep 2014 01:48:23 -0000 Delivered-To: apmail-hadoop-common-dev-archive@hadoop.apache.org Received: (qmail 18581 invoked by uid 500); 3 Sep 2014 01:48:23 -0000 Mailing-List: contact common-dev-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: common-dev@hadoop.apache.org Delivered-To: mailing list common-dev@hadoop.apache.org Received: (qmail 18569 invoked by uid 99); 3 Sep 2014 01:48:23 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 Sep 2014 01:48:23 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of todd@cloudera.com designates 209.85.217.181 as permitted sender) Received: from [209.85.217.181] (HELO mail-lb0-f181.google.com) (209.85.217.181) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 Sep 2014 01:48:19 +0000 Received: by mail-lb0-f181.google.com with SMTP id s7so325399lbd.26 for ; Tue, 02 Sep 2014 18:47:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=h+L8359mbB6qom/kE0EKWZqJoFEjNUJc/h3SbaqZGoQ=; b=fFznfUbFUnnJs/AdYJa3UsHdPryQ7EfbQuhR1HXmzLZ9yvYo8njNmu2jy/FYEVRihq FoXa6tzlh4kjbs4CwKNI8E0GAbmqxzy/uTxH/3kVaxd1JMrC0anHNCQz1sDY/i3tbXnr Qj2ROZwbTb8+A07T5ZJhigOu9BXVmKeUu4YVQM/2rxs2JYrgMuKUiC9716MZ0CQNpZG/ oAoIt85c6H9QWzP78rwvtJrOA8UdEbk3JiVepAifVgCTR0zStKSLnOF758zf8c5CHhdf EUfYTyHeqA52C7FZk8FPtBxrgOZBcyFN6OtlObrHGYgLYiTPlTziIa8k7JpORAivKNsv shQA== X-Gm-Message-State: ALoCoQncVYnon0HEPePJ9tIbhmpLvXlMJWdl3M/cATUmJj/4zkIUnqkApAglilN0XlU/5TeK3dUa X-Received: by 10.112.172.130 with SMTP id bc2mr7632032lbc.5.1409708877181; Tue, 02 Sep 2014 18:47:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.171.231 with HTTP; Tue, 2 Sep 2014 18:47:36 -0700 (PDT) In-Reply-To: References: From: Todd Lipcon Date: Tue, 2 Sep 2014 18:47:36 -0700 Message-ID: Subject: Re: migrating private branches to the new git repo To: "common-dev@hadoop.apache.org" Content-Type: multipart/alternative; boundary=001a11c385fadc8ef405021f6cb4 X-Virus-Checked: Checked by ClamAV on apache.org --001a11c385fadc8ef405021f6cb4 Content-Type: text/plain; charset=UTF-8 On Tue, Sep 2, 2014 at 2:38 PM, Andrew Wang wrote: > Not to derail the conversation, but if CHANGES.txt is making backports more > annoying, why don't we get rid of it? It seems like we should be able to > generate it via a JIRA query, and "git log" can also be used for a quick > check (way faster than svn log). > +1, I've always found CHANGES.txt to be a big pain in the butt, and often it gets incorrect, too. > > > On Tue, Sep 2, 2014 at 12:38 PM, Steve Loughran > wrote: > > > I've now done my first commits; one into trunk (10373), one into branch-2 > > and cherry picked (fix in > > hadoop-common-project/hadoop-common/src/main/native/README ; no JIRA). > > > > I made an initial attempt to cherry pick the HADOOP-10373 patch from > trunk > > into branch-2, with CHANGES.TXT being a dramatic enough change that it > > takes human intervention to patch. > > > > implication > > > > > > 1. committing to branch-2 with changes.txt in the same commit followed > > by a cherry pick forwards works. > > 2. committing to trunk only backports reliably if the changes.txt > files > > are patched in a separate commit > > > > This is no different from SVN, except that an svn merge used different > > commands. > > > > I have not tried the git format-patch/git am option, which would be: > > > > > > 1. -use git am -3 to apply the patch to the HEAD of both branch-2 and > > trunk > > 2. -patch changes.txt in each branch, then either commit separately > > 3. -or try and "amend latest commit" for the patches > > > > #3 seems appealing, but it'd make the diff on the two branches different. > > > > > > > > On 2 September 2014 19:01, Andrew Wang wrote: > > > > > This is basically what I did, make patches of each of my branches and > > then > > > reapply to the new trunk. One small recommendation would be to make the > > > remote named "apache" rather than "asflive" so it's consistent with the > > > GitAndHadoop wikipage. IMO naming branches with a "/" (e.g. > "live/trunk") > > > is also kind of ambiguous, since it's the same syntax used to specify a > > > remote. It seems there can also be difficulties with directory and > > > filenames. > > > > > > Somewhat related, it'd be nice to update the GitAndHadoop instructions > on > > > how to generate a patch using git-format-patch. I've been using plain > old > > > "git diff" for a while, but format-patch seems better. It'd be > especially > > > nice if a recommended .gitconfig section was made available :) > > > > > > I plan to play with format-patch some in the near future and might do > > this > > > myself, but if any git gurus already have this ready to go, feel free > to > > > edit. > > > > > > > > > On Tue, Sep 2, 2014 at 4:10 AM, Steve Loughran > > > > wrote: > > > > > > > Now that hadoop is using git, I'm migrating my various > work-in-progress > > > > branches to the new commit tree > > > > > > > > > > > > 1. This is the process I've written up for using git format-patch > then > > > git > > > > am to export the patch sequence and merge it in, then rebasing onto > > trunk > > > > to finally get in sync > > > > > > > > https://wiki.apache.org/hadoop/MigratingPrivateGitBranches > > > > > > > > 2. The Git and hadoop docs cover git graft: > > > > > > > > > > > > > > https://wiki.apache.org/hadoop/GitAndHadoop#Grafts_for_complete_project_history > > > > > > > > I'm not sure if/how that relates > > > > > > > > Is there any easier way than what I've described for doing the move? > > > > > > > > -- > > > > CONFIDENTIALITY NOTICE > > > > NOTICE: This message is intended for the use of the individual or > > entity > > > to > > > > which it is addressed and may contain information that is > confidential, > > > > privileged and exempt from disclosure under applicable law. If the > > reader > > > > of this message is not the intended recipient, you are hereby > notified > > > that > > > > any printing, copying, dissemination, distribution, disclosure or > > > > forwarding of this communication is strictly prohibited. If you have > > > > received this communication in error, please contact the sender > > > immediately > > > > and delete it from your system. Thank You. > > > > > > > > > > > -- > > CONFIDENTIALITY NOTICE > > NOTICE: This message is intended for the use of the individual or entity > to > > which it is addressed and may contain information that is confidential, > > privileged and exempt from disclosure under applicable law. If the reader > > of this message is not the intended recipient, you are hereby notified > that > > any printing, copying, dissemination, distribution, disclosure or > > forwarding of this communication is strictly prohibited. If you have > > received this communication in error, please contact the sender > immediately > > and delete it from your system. Thank You. > > > -- Todd Lipcon Software Engineer, Cloudera --001a11c385fadc8ef405021f6cb4--