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).
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. >
