On Tue, Sep 2, 2014 at 2:38 PM, Andrew Wang <andrew.w...@cloudera.com> 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 <ste...@hortonworks.com> > 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 <andrew.w...@cloudera.com> 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 <ste...@hortonworks.com > > > > > 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
