hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Todd Lipcon <t...@cloudera.com>
Subject Re: migrating private branches to the new git repo
Date Wed, 03 Sep 2014 01:47:36 GMT
On Tue, Sep 2, 2014 at 2:38 PM, Andrew Wang <andrew.wang@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 <stevel@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.wang@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 <stevel@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message