FAQ
Is it possible to preserve the commit history of a tree of files as it
moves out of one repository and into another?

I have two use-cases to consider: one long-term, one short-term.

I.

Long-term: I am considering trying to move Pod-Html from its current
location within ext/ in the Perl 5 core distribution to cpan/, i.e.,
have CPAN be upstream.[1] That really can't be done right away because,
as the subject line of a META ticket opened by rjbs indicates, "Pod-Html
is a mess." It's code is poorly structured. Its test coverage is
unsatisfactory. It has many RTs open. It would be shameful to put it
out on CPAN in its current state. I've made one sustained attempt at a
cleanup[2]; I'm now considering another. But once it's out on CPAN and
its principal repository is presumably on github.com, I would like the
code to retain as much of its history from the Perl 5 repository as
possible.

How do we do that?

II.

Short-term: In order to do a thorough cleanup on Pod-Html, I want to be
free to poke and prod it to my heart's content. Among other things,
that's means constant checking of the test coverage with Devel-Cover.
My preference would be to do that in a repo other than Perl 5, but if I
did so I would want my changes to go back into Perl 5's Pod-Html so that
people could get used to it before we moved it to CPAN. And I would
want to preserve the commit history in lib/Pod/Htmlm.pm and the test
suite throughout that round trip.[3]

How do I do that?

Thank you very much.
Jim Keenan


[1] Personally, I don't think Pod-Html needs to be distributed with core
at all. But since I know there will be differences of opinion about
this and since moving it to upstream CPAN is a prerequisite to
expulsion, moving it to cpan/ is all we need to discuss for now.

[2] At the DuckDuckGo hackathon in Paoli in June/July 2012, rjbs
suggested I look at Pod-Html and start cleaning it up so that it could
eventually go to CPAN. I spent about six weeks working on it. I myself
had not used Pod-Html in more than a decade. I didn't know anyone who
did. So I ran out of motivation. But since I've recently met one
person who does use it, I'm considering resuming my efforts.

[3] In my 2012 attempts, I moved the existing codebase into a typical
CPAN structure, then committed that to a new git repo, losing the
existing history in the process. I knew much less about git back then.
   I discussed that with rjbs and he said we could worry about the commit
history later. If I embark on this project again, I'd like to get it
right from the git-go.

Search Discussions

  • Mark Allen at Dec 22, 2013 at 4:02 pm
    I haven't tried this (yet) but it looks like a promising solution...

    http://gbayer.com/development/moving-files-from-one-git-repository-to-another-preserving-history/


    Since repo B would presumably be empty, you can avoid the second merge described in the article
    and just push into a repo on github (or locally).

    Mark



    On Sunday, December 22, 2013 8:51 AM, James E Keenan wrote:

    Is it possible to preserve the commit history of a tree of files as it
    moves out of one repository and into another?

    I have two use-cases to consider: one long-term, one short-term.

    I.

    Long-term:  I am considering trying to move Pod-Html from its current
    location within ext/ in the Perl 5 core distribution to cpan/, i.e.,
    have CPAN be upstream.[1]  That really can't be done right away because,
    as the subject line of a META ticket opened by rjbs indicates, "Pod-Html
    is a mess."  It's code is poorly structured.  Its test coverage is
    unsatisfactory.  It has many RTs open.  It would be shameful to put it
    out on CPAN in its current state.  I've made one sustained attempt at a
    cleanup[2]; I'm now considering another.  But once it's out on CPAN and
    its principal repository is presumably on github.com, I would like the
    code to retain as much of its history from the Perl 5 repository as
    possible.

    How do we do that?

    II.

    Short-term:  In order to do a thorough cleanup on Pod-Html, I want to be
    free to poke and prod it to my heart's content.  Among other things,
    that's means constant checking of the test coverage with Devel-Cover.
    My preference would be to do that in a repo other than Perl 5, but if I
    did so I would want my changes to go back into Perl 5's Pod-Html so that
    people could get used to it before we moved it to CPAN.  And I would
    want to preserve the commit history in lib/Pod/Htmlm.pm and the test
    suite throughout that round trip.[3]

    How do I do that?

    Thank you very much.
    Jim Keenan


    [1] Personally, I don't think Pod-Html needs to be distributed with core
    at all.  But since I know there will be differences of opinion about
    this and since moving it to upstream CPAN is a prerequisite to
    expulsion, moving it to cpan/ is all we need to discuss for now.

    [2] At the DuckDuckGo hackathon in Paoli in June/July 2012, rjbs
    suggested I look at Pod-Html and start cleaning it up so that it could
    eventually go to CPAN.  I spent about six weeks working on it.  I myself
    had not used Pod-Html in more than a decade.  I didn't know anyone who
    did.  So I ran out of motivation.  But since I've recently met one
    person who does use it, I'm considering resuming my efforts.

    [3] In my 2012 attempts, I moved the existing codebase into a typical
    CPAN structure, then committed that to a new git repo, losing the
    existing history in the process.  I knew much less about git back then.
      I discussed that with rjbs and he said we could worry about the commit
    history later.  If I embark on this project again, I'd like to get it
    right from the git-go.
  • James E Keenan at Dec 28, 2013 at 6:11 pm

    On 12/22/13 11:02 AM, Mark Allen wrote:
    I haven't tried this (yet) but it looks like a promising solution...

    http://gbayer.com/development/moving-files-from-one-git-repository-to-another-preserving-history/
    It turned out that for my purpose I only needed some of the instructions
    at that site.

    It took me two tries, but on the second, these commands sufficed:

        540 git clone git://perl5.git.perl.org/perl.git perl4podhtml
        541 cd perl4podhtml/
        542 git remote rm origin
        543 vi .git/config
        544 git filter-branch --subdirectory-filter ext/Pod-Html/ -- --all

    At this point, the top-level directory merely contained the directories
    formerly found in ext/Pod-Html/. And 'git log' and 'git blame'
    indicated that the history had been preserved. So I quit right there.

    After the usual finagling and some renaming, I was able to put a
    repository on github:

    https://github.com/jkeenan/opodhtml

    It currently has two branches: 'blead', which should represent the
    state of ext/Pod-Html in Perl 5 blead as of today; 'master', which will
    be my master branch for refactoring, adding tests, giving Pod-Html the
    old Phalanx treatment.

    Thank you very much.
    Jim Keenan
  • Aristotle Pagaltzis at Dec 29, 2013 at 10:30 am

    * James E Keenan [2013-12-28 19:15]:
    At this point, the top-level directory merely contained the
    directories formerly found in ext/Pod-Html/. And 'git log' and 'git
    blame' indicated that the history had been preserved.
    Except, at one time it had lived in lib/ and you are completely missing
    that history. Yours effectively starts at the point where Nick moved it:
    https://github.com/jkeenan/opodhtml/commit/75e62e6c1c6203daf034df38b525a6428d419b19
    But you then have a couple of commits before that, at the beginning of
    your local history… which are completely empty.
    git filter-branch --subdirectory-filter ext/Pod-Html/ -- --all
    So first, make sure there are no useless commits:

         git filter-branch --prune-empty \
             --subdirectory-filter ext/Pod-Html/ -- --all

    Next, you REALLY don’t want --all, which makes some 63 THOUSAND commits
    that will take forEVER to process (hours). You want to look at only the
    commits that touch relevant paths, which is some 530 total. On an SSD
    that can be index-filtered in half a minute. MUCH better.

         git filter-branch --prune-empty \
             --subdirectory-filter ext/Pod-Html/ -- -- lib/Pod ext/Pod-Html

    Note the double `--` – that is not a typo, the first `--` is for telling
    git-filter-branch that the rest of the arguments are for git-rev-list,
    so the second one gets passed through to git-rev-list, which takes it to
    mean that only paths follow.

    Next, since unfortunately --subdirectory-filter cannot extract multiple
    directories at once, this job will need --index-filter.

         git filter-branch --prune-empty --index-filter '
             git rm --cached -r -q -- . ;
             git reset -q $GIT_COMMIT -- ext/Pod-Html/ lib/Pod/
         ' -- -- ext/Pod-Html/ lib/Pod/

    The first line will clear out the index entirely. The next line restores
    the relevant directories from the original commit undergoing rewriting.

    Now comes the hard part, because lib/Pod/ alone is both too much (there
    have been a number of other modules in there over time) as well as too
    little (the relevant files used to be strewn all over the place before
    there were consolidated into ext/Pod-Html/). This requires sleuthing.
    I started with a full clone of perl5.git and did

         git log --name-status --full-diff -- ext/Pod-Html | egrep ^R

    to find out all the files that were ever moved into ext/Pod-Html from
    elsewhere:

         lib/Pod/Html.pm
         lib/Pod/t/eol.t
         lib/Pod/t/htmlescp.pod
         lib/Pod/t/htmlescp.t
         lib/Pod/t/htmllink.pod
         lib/Pod/t/htmllink.t
         lib/Pod/t/htmlview.pod
         lib/Pod/t/htmlview.t
         lib/Pod/t/pod2html-lib.pl
         pod/pod2html.PL

    That’s not necessarily sufficient since those files may have chequered
    histories of their own that may need tracking. E.g. it turns out that
    pod/pod2html.PL had a predecessor called pod/pod2html.SH very early on,
    which had been called pod/pod2html before even that. Are they relevant?
    Maybe. In this case it turns out the answer is yes: they were not actual
    shell scripts, but wrappers that generated a Perl pod2html script whose
    code became the installed pod2html became the module plus stub script…
    so you don’t want to miss them.

    The other files turn out to be boring and obvious. (Thankfully!)

    A potential complication is that Pod::Html used to load Pod::Functions.
    But it turns out that it never actually used anything from that module…
    as far as I can tell. So I’d take the easy way out: simply ignore that.

    In the final analysis, you get this:

         export L='ext/Pod-Html/ lib/Pod/Html.pm ...' # all the files listed above
         git filter-branch --prune-empty --index-filter '
             git rm --cached -r -q -- . ;
             git reset -q $GIT_COMMIT -- $L
         ' -- -- $L

    This extracts 287 commits from perl5.git, including the far beginning of
    history. It leaves everything in the subdirectories it was in while it
    was in perl5.git, but I figure that’s better here since the history of
    splits and moves among files becomes unintelligible otherwise.

    I’ve put up the result:

         https://github.com/ap/opodhtml

    Feel free to clone that as a basis for the rest of your work.

    I figure a commit that moves ext/Pod-Html/* to the root of the repo is
    a clean cut to document “today begins the rest of life for this module”.
    I have not done this, figuring I’ll leave it to you to do the honours.

    (I want to get rid of that repo once it has served its purpose so please
    let me know either way. If you do choose to use it, ideally, do not fork
    it on GitHub (since that would record it as a fork), just git-clone it,
    change the origin URL in to your existing GH repo, and force-push.)

    --
    Aristotle Pagaltzis // <http://plasmasturm.org/>
  • James E Keenan at Dec 29, 2013 at 1:01 pm

    On 12/29/13 5:30 AM, Aristotle Pagaltzis wrote:

    I’ve put up the result:

    https://github.com/ap/opodhtml

    Feel free to clone that as a basis for the rest of your work.
    When I went to that page, I saw a box labelled "HTTPS clone URL" where I
    most often see "SSH clone URL". I tried the following and did not succeed.

    $ git clone https://github.com/ap/opodhtml.git aristotle-opodhtml
    Initialized empty Git repository in
    /Users/jimk/gitwork/aristotle-opodhtml/.git/
    fatal: https://github.com/ap/opodhtml.git/info/refs download error -
    Protocol https not supported or disabled in libcurl

    I have available:
    $ git version
    git version 1.6.3.2

    Can you identify the problem -- or enable clone via SSH?

    Thank you very much.
    Jim Keenan
  • Aristotle Pagaltzis at Dec 29, 2013 at 1:45 pm

    * James E Keenan [2013-12-29 14:05]:
    When I went to that page, I saw a box labelled "HTTPS clone URL" where
    I most often see "SSH clone URL".
    Uhm yeah, GitHub defaults the clone URL to HTTPS everywhere you do not
    have push access.
    I tried the following and did not succeed.

    $ git clone https://github.com/ap/opodhtml.git aristotle-opodhtml
    Initialized empty Git repository in
    /Users/jimk/gitwork/aristotle-opodhtml/.git/
    fatal: https://github.com/ap/opodhtml.git/info/refs download error -
    Protocol https not supported or disabled in libcurl
       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    I have available:
    $ git version
    git version 1.6.3.2

    Can you identify the problem
    I wager it’s exactly what it says the problem is: the libcurl that your
    Git is linked against does not support HTTPS.
    or enable clone via SSH?
    It’s nothing I did and nothing I can do. There’s a little label saying
    “You can clone with HTTPS, SSH, or Subversion” right below the little
    box you’re copy-pasting from though. How about trying that?

    --
    Aristotle Pagaltzis // <http://plasmasturm.org/>
  • Zefram at Dec 29, 2013 at 2:27 pm

    James E Keenan wrote:
    When I went to that page, I saw a box labelled "HTTPS clone URL"
    where I most often see "SSH clone URL". I tried the following and
    did not succeed.
    Github also supports the Git protocol, for which you just need to change
    the scheme part of the URL:

    $ git clone git://github.com/ap/opodhtml.git
    Cloning into 'opodhtml'...
    remote: Counting objects: 1596, done.
    remote: Compressing objects: 100% (632/632), done.
    remote: Total 1596 (delta 474), reused 1596 (delta 474)
    Receiving objects: 100% (1596/1596), 372.52 KiB | 445 KiB/s, done.
    Resolving deltas: 100% (474/474), done.

    -zefram
  • James E Keenan at Dec 29, 2013 at 3:41 pm

    On 12/29/13 9:27 AM, Zefram wrote:
    James E Keenan wrote:
    When I went to that page, I saw a box labelled "HTTPS clone URL"
    where I most often see "SSH clone URL". I tried the following and
    did not succeed.
    Github also supports the Git protocol, for which you just need to change
    the scheme part of the URL:

    $ git clone git://github.com/ap/opodhtml.git
    Cloning into 'opodhtml'...
    remote: Counting objects: 1596, done.
    remote: Compressing objects: 100% (632/632), done.
    remote: Total 1596 (delta 474), reused 1596 (delta 474)
    Receiving objects: 100% (1596/1596), 372.52 KiB | 445 KiB/s, done.
    Resolving deltas: 100% (474/474), done.

    -zefram
    I tried this on my laptop after trying 'https' and before posting my
    last message and did not succeed.

    Or, more precisely, I *thought* I tried this on my laptop.

    But I see now that I was using the wrong syntax. I was using:

        git clone git@github.com/ap/opodhtml.git aristotle-opodhtml

    instead of this based on yours above:

        git clone git://github.com/ap/opodhtml.git aristotle-opodhtml

    And I see that this repo does indeed have history going back all the way
    to Larry's original commit. I hope to pursue the rest of Aristotle's
    suggestions later today.

    Thank you very much.
    Jim Keenan
  • James E Keenan at Dec 30, 2013 at 1:24 am

    On 12/29/13 5:30 AM, Aristotle Pagaltzis wrote:
    * James E Keenan[2013-12-28 19:15]:
    At this point, the top-level directory merely contained the
    directories formerly found in ext/Pod-Html/. And 'git log' and 'git
    blame' indicated that the history had been preserved.
    Except, at one time it had lived in lib/ and you are completely missing
    that history. Yours effectively starts at the point where Nick moved it:
    https://github.com/jkeenan/opodhtml/commit/75e62e6c1c6203daf034df38b525a6428d419b19
    But you then have a couple of commits before that, at the beginning of
    your local history… which are completely empty.
    git filter-branch --subdirectory-filter ext/Pod-Html/ -- --all
    So first, make sure there are no useless commits:

    git filter-branch --prune-empty \
    --subdirectory-filter ext/Pod-Html/ -- --all

    Next, you REALLY don’t want --all, which makes some 63 THOUSAND commits
    that will take forEVER to process (hours). You want to look at only the
    commits that touch relevant paths, which is some 530 total. On an SSD
    that can be index-filtered in half a minute. MUCH better.

    git filter-branch --prune-empty \
    --subdirectory-filter ext/Pod-Html/ -- -- lib/Pod ext/Pod-Html

    Note the double `--` – that is not a typo, the first `--` is for telling
    git-filter-branch that the rest of the arguments are for git-rev-list,
    so the second one gets passed through to git-rev-list, which takes it to
    mean that only paths follow.

    Next, since unfortunately --subdirectory-filter cannot extract multiple
    directories at once, this job will need --index-filter.

    git filter-branch --prune-empty --index-filter '
    git rm --cached -r -q -- . ;
    git reset -q $GIT_COMMIT -- ext/Pod-Html/ lib/Pod/
    ' -- -- ext/Pod-Html/ lib/Pod/

    The first line will clear out the index entirely. The next line restores
    the relevant directories from the original commit undergoing rewriting.

    Now comes the hard part, because lib/Pod/ alone is both too much (there
    have been a number of other modules in there over time) as well as too
    little (the relevant files used to be strewn all over the place before
    there were consolidated into ext/Pod-Html/). This requires sleuthing.
    I started with a full clone of perl5.git and did

    git log --name-status --full-diff -- ext/Pod-Html | egrep ^R

    to find out all the files that were ever moved into ext/Pod-Html from
    elsewhere:

    lib/Pod/Html.pm
    lib/Pod/t/eol.t
    lib/Pod/t/htmlescp.pod
    lib/Pod/t/htmlescp.t
    lib/Pod/t/htmllink.pod
    lib/Pod/t/htmllink.t
    lib/Pod/t/htmlview.pod
    lib/Pod/t/htmlview.t
    lib/Pod/t/pod2html-lib.pl
    pod/pod2html.PL

    That’s not necessarily sufficient since those files may have chequered
    histories of their own that may need tracking. E.g. it turns out that
    pod/pod2html.PL had a predecessor called pod/pod2html.SH very early on,
    which had been called pod/pod2html before even that. Are they relevant?
    Maybe. In this case it turns out the answer is yes: they were not actual
    shell scripts, but wrappers that generated a Perl pod2html script whose
    code became the installed pod2html became the module plus stub script…
    so you don’t want to miss them.

    The other files turn out to be boring and obvious. (Thankfully!)

    A potential complication is that Pod::Html used to load Pod::Functions.
    But it turns out that it never actually used anything from that module…
    as far as I can tell. So I’d take the easy way out: simply ignore that.

    In the final analysis, you get this:

    export L='ext/Pod-Html/ lib/Pod/Html.pm ...' # all the files listed above
    git filter-branch --prune-empty --index-filter '
    git rm --cached -r -q -- . ;
    git reset -q $GIT_COMMIT -- $L
    ' -- -- $L

    This extracts 287 commits from perl5.git, including the far beginning of
    history. It leaves everything in the subdirectories it was in while it
    was in perl5.git, but I figure that’s better here since the history of
    splits and moves among files becomes unintelligible otherwise.

    I’ve put up the result:

    https://github.com/ap/opodhtml

    Feel free to clone that as a basis for the rest of your work.

    I figure a commit that moves ext/Pod-Html/* to the root of the repo is
    a clean cut to document “today begins the rest of life for this module”.
    I have not done this, figuring I’ll leave it to you to do the honours.

    (I want to get rid of that repo once it has served its purpose so please
    let me know either way. If you do choose to use it, ideally, do not fork
    it on GitHub (since that would record it as a fork), just git-clone it,
    change the origin URL in to your existing GH repo, and force-push.)
    Aristotle,

    Thanks for the git work; it's years beyond my own git fu and that of
    almost everyone I know.

    Can you check out that the 'master' branch at
    https://github.com/jkeenan/opodhtml has the correct history?

    Thank you very much.
    Jim Keenan
  • Aristotle Pagaltzis at Dec 30, 2013 at 2:13 am

    * James E Keenan [2013-12-30 02:25]:
    Can you check out that the 'master' branch at
    https://github.com/jkeenan/opodhtml has the correct history?
    Looks fine. I guess you want to do something like

         git push -f origin aristotle:blead

    to do away with the old extracted history on the blead branch
    and point it at the tip of the new extraction?

    --
    Aristotle Pagaltzis // <http://plasmasturm.org/>
  • Kent Fredric at Dec 22, 2013 at 5:33 pm

    On 23 December 2013 03:51, James E Keenan wrote:
    Is it possible to preserve the commit history of a tree of files as it moves
    out of one repository and into another

    I believe what you want to do is as follows:

    1. Clone the Perl repository
    2. Perform a branch filter on all branches to move ext/Pod-Html/* to /
    ( See git filter-branch --subdirectory-filter )
    3. Possibly perform a branch filter to remove empty commits

    At this point, you've got a mirror or perl.git, but its only the Pod-Html path.

    Getting that working _and_ having it respect move history will be the
    problem if ext/Pod-Html has ever been somewhere else.

    Though, after doing this, once you've got your workflow targeted at
    Pod-Html being independent, its reasonably straight forward to
    dynamically graft that on to the perl repo with git subtree

    `git subtree` is similar to git submodule, except it doesn't work with
    repository references, and instead simply rewrites commits before
    merging them against the branch.

    For example, I have this repository:
    https://github.com/kentfredric/travis-scripts

    It shares all the stuff I need to make travis work, and its a right
    pain to make it work as a submodule.

    So all my repositories that I use with travis testing share that code
    via git subtree

    For example:

    https://github.com/kentfredric/Dist-Zilla-PluginBundle-Author-KENTNL/tree/master/maint-travis-ci

    And you'll see the automated merge points here:
    https://github.com/kentfredric/Dist-Zilla-PluginBundle-Author-KENTNL/commits/master

    Here, you'll see the separate history of my travis-ci repo being
    merged into master on a regular basis, thats the bottom blue line.

    https://github.com/kentfredric/Dist-Zilla-PluginBundle-Author-KENTNL/network

    Though I note, this is not yet showing the effect of my changes to use
    commit squashing prior to merges, because it proves not very useful to
    have the whole history of the source repository visible on the
    repository its being merged into, just causes useless clutter ( at
    least, thats what I've found ).

    Just not sure if the subtree workflow is something perl core are happy
    with doing yet.
    --
    Kent
  • Ricardo Signes at Dec 23, 2013 at 3:33 am
    * Kent Fredric [2013-12-22T12:33:39]
    2. Perform a branch filter on all branches to move ext/Pod-Html/* to /
    ( See git filter-branch --subdirectory-filter )
    That is the tool I would use.

    --
    rjbs
  • Brian d foy at Dec 23, 2013 at 8:43 pm
    In article
    <CAATnKFC2=66r7b-DgrbrU+6v7vnvf2mgy1rp87hp3oa86a=vpg@mail.gmail.com>,
    Kent Fredric wrote:
    On 23 December 2013 03:51, James E Keenan wrote:
    Is it possible to preserve the commit history of a tree of files as it moves
    out of one repository and into another

    I believe what you want to do is as follows:

    1. Clone the Perl repository
    2. Perform a branch filter on all branches to move ext/Pod-Html/* to /
    ( See git filter-branch --subdirectory-filter )
    3. Possibly perform a branch filter to remove empty commits
    I did this to move all of my modules from the big, single SVN repo I
    had in SourceForge to separate repos for GitHub. It still seems like
    wonderful magic to me.

    After the filter you probably want to do a gc.

    http://use.perl.org/use.perl.org/_brian_d_foy/journal/37296.html
  • Karen Etheridge at Dec 22, 2013 at 6:58 pm

    On Sun, Dec 22, 2013 at 09:51:23AM -0500, James E Keenan wrote:
    Is it possible to preserve the commit history of a tree of files as
    it moves out of one repository and into another?
    This is a bit fiddly but it's quite doable. The steps look something like
    this:

    - create your new repository, cloned from the 'perl' repository.

    - find the files/directories you care about. Delete EVERYTHING else -- not
       just 'git rm -r', but actually wipe out knowledge of those files'
       existence from the history. One guide to this is here:
       https://help.github.com/articles/remove-sensitive-data -- and now that
       you know the name of the git commands to use, you should be able to find
       lots of other documents describing variants to this technique.

    - now you should be left with just the one tree in the repo, including all
       commits in the history: ext/Pod-Html. Now you can move it to its new
       location using a normal 'git mv', and continue with development.

    (FWIW, I'd suggest doing only minimal changes at this point - rename the
    code to live under lib/, add a Makefile.PL, META.* and Changes, and then
    immediately releasing to the CPAN, to mark its move out of core -- and then
    continue with cleaning up the code in subsequent releases.)

    Thanks for taking this on -- it looks like Pod-Html has wanted a caretaker
    for quite some time!

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcpan-workers @
categoriesperl
postedDec 22, '13 at 2:51p
activeDec 30, '13 at 2:13a
posts14
users8
websitecpan.org

People

Translate

site design / logo © 2018 Grokbase