Sorry, if I wasn't clear. I find Target and Fix versions useful. I find CHANGES.txt redundant.
On Wed, Sep 3, 2014 at 2:55 PM, Karthik Kambatla <ka...@cloudera.com> wrote: > > 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. IMO, we spend way too much time in maintaining this redundant > information. > > >> >> >> 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. >> > >> > >
