hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karthik Kambatla <ka...@cloudera.com>
Subject Re: migrating private branches to the new git repo
Date Thu, 04 Sep 2014 00:25:04 GMT
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 <kasha@cloudera.com> wrote:

>
> 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. IMO, we spend way too much time in maintaining this redundant
> information.
>
>
>>
>>
>> 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.
>> >
>>
>
>

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