I personally find Target Version to be useful for tracking which version a change is intended for.
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. > > > > > >
