Smalltalk › Squeak › Squeak VM

weird git history

‹ Previous Topic Next Topic ›
 
classic Classic list List threaded Threaded
♦
♦
 5 messages Options
Nicolas Cellier
Reply | Threaded
Open this post in threaded view
♦
♦
|

weird git history

Nicolas Cellier
 
Hi all,
In an obsolete working copy, I had some local changes to build.win32x86/thirdparty/Makefile.libssh2

    tar x -f $(LIBSSH2ARCHIVE) -C $(THIRDPARTYDIR)
    cd $(LIBSSH2DIR) \
        && ./configure \
--            --build=x86_64-w64-cygwin \
++            --build=i686-w64-cygwin \
            --host=i686-w64-mingw32 \
            --prefix='$(THIRDPARTYOUTDIR)' \
            CFLAGS='$(THIRDPARTY_CFLAGS)' \

If I go into current version:

I don't see the x86_64 line, good, this must have been already fixed!
But when I look at history thru github interface to know when and how, I see a very partial and truncated history:

And itseems like none of the commits referenced did remove this x86_64 line, like if it never existed...

If I go a little further in the past commit log, in early november (still thru github interface https://github.com/OpenSmalltalk/opensmalltalk-vm/commits/Cog?after=0fae80c28ee3ce2b3eb09cb31ec94f0a590893f7+174), select one of the commits and go tho this same file, then i see another unrelated short history:

This time, the x86_64 matching line is there...
This kind of unconventional rewrite of history makes me worry...
If we can't rely on history, then what a VCS is good for?

It's possible that the minheadless merge introduced that, so it would be good if more pairs of eyes could check that we did not loose anything important, especially for Pharo builds.


Capture_change.PNG (15K) Download Attachment
history1.png (27K) Download Attachment
history2.PNG (20K) Download Attachment
Nicolas Cellier
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: weird git history

Nicolas Cellier
 


Le lun. 7 janv. 2019 à 15:01, Nicolas Cellier <[hidden email]> a écrit :
Hi all,
In an obsolete working copy, I had some local changes to build.win32x86/thirdparty/Makefile.libssh2

    tar x -f $(LIBSSH2ARCHIVE) -C $(THIRDPARTYDIR)
    cd $(LIBSSH2DIR) \
        && ./configure \
--            --build=x86_64-w64-cygwin \
++            --build=i686-w64-cygwin \
            --host=i686-w64-mingw32 \
            --prefix='$(THIRDPARTYOUTDIR)' \
            CFLAGS='$(THIRDPARTY_CFLAGS)' \

If I go into current version:

I don't see the x86_64 line, good, this must have been already fixed!
But when I look at history thru github interface to know when and how, I see a very partial and truncated history:

And itseems like none of the commits referenced did remove this x86_64 line, like if it never existed...

If I go a little further in the past commit log, in early november (still thru github interface https://github.com/OpenSmalltalk/opensmalltalk-vm/commits/Cog?after=0fae80c28ee3ce2b3eb09cb31ec94f0a590893f7+174), select one of the commits and go tho this same file, then i see another unrelated short history:

This time, the x86_64 matching line is there...
This kind of unconventional rewrite of history makes me worry...
If we can't rely on history, then what a VCS is good for?

It's possible that the minheadless merge introduced that, so it would be good if more pairs of eyes could check that we did not loose anything important, especially for Pharo builds.

Or maybe it is from this commit?
in which case i guess that the Pharo stuff should be OK.

But in such case, couldn't we rather rebase works performed on remote repos rather than merge?
Otherwise, I find it very hard to understand a disrupted non linear history... Or is it just me?
Nicolas Cellier
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: weird git history

Nicolas Cellier
 


Le lun. 7 janv. 2019 à 15:11, Nicolas Cellier <[hidden email]> a écrit :


Le lun. 7 janv. 2019 à 15:01, Nicolas Cellier <[hidden email]> a écrit :
Hi all,
In an obsolete working copy, I had some local changes to build.win32x86/thirdparty/Makefile.libssh2

    tar x -f $(LIBSSH2ARCHIVE) -C $(THIRDPARTYDIR)
    cd $(LIBSSH2DIR) \
        && ./configure \
--            --build=x86_64-w64-cygwin \
++            --build=i686-w64-cygwin \
            --host=i686-w64-mingw32 \
            --prefix='$(THIRDPARTYOUTDIR)' \
            CFLAGS='$(THIRDPARTY_CFLAGS)' \

If I go into current version:

I don't see the x86_64 line, good, this must have been already fixed!
But when I look at history thru github interface to know when and how, I see a very partial and truncated history:

And itseems like none of the commits referenced did remove this x86_64 line, like if it never existed...

If I go a little further in the past commit log, in early november (still thru github interface https://github.com/OpenSmalltalk/opensmalltalk-vm/commits/Cog?after=0fae80c28ee3ce2b3eb09cb31ec94f0a590893f7+174), select one of the commits and go tho this same file, then i see another unrelated short history:

This time, the x86_64 matching line is there...
This kind of unconventional rewrite of history makes me worry...
If we can't rely on history, then what a VCS is good for?

It's possible that the minheadless merge introduced that, so it would be good if more pairs of eyes could check that we did not loose anything important, especially for Pharo builds.

Or maybe it is from this commit?
in which case i guess that the Pharo stuff should be OK.

But in such case, couldn't we rather rebase works performed on remote repos rather than merge?
Otherwise, I find it very hard to understand a disrupted non linear history... Or is it just me?

Also, note that I was worrying about it, because I think that it was me who introduced this X86_64 error :(
Jakob Reschke
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: weird git history

Jakob Reschke
In reply to this post by Nicolas Cellier
 
Hi Nicolas,

The two histories are of two different files: one is in build.linux32x86, the other one is in build.win32x86. Does that resolve your concerns?

Kind regards,
Jakob

Am Mo., 7. Jan. 2019 um 15:02 Uhr schrieb Nicolas Cellier <[hidden email]>:
 
Hi all,
In an obsolete working copy, I had some local changes to build.win32x86/thirdparty/Makefile.libssh2

    tar x -f $(LIBSSH2ARCHIVE) -C $(THIRDPARTYDIR)
    cd $(LIBSSH2DIR) \
        && ./configure \
--            --build=x86_64-w64-cygwin \
++            --build=i686-w64-cygwin \
            --host=i686-w64-mingw32 \
            --prefix='$(THIRDPARTYOUTDIR)' \
            CFLAGS='$(THIRDPARTY_CFLAGS)' \

If I go into current version:

I don't see the x86_64 line, good, this must have been already fixed!
But when I look at history thru github interface to know when and how, I see a very partial and truncated history:

And itseems like none of the commits referenced did remove this x86_64 line, like if it never existed...

If I go a little further in the past commit log, in early november (still thru github interface https://github.com/OpenSmalltalk/opensmalltalk-vm/commits/Cog?after=0fae80c28ee3ce2b3eb09cb31ec94f0a590893f7+174), select one of the commits and go tho this same file, then i see another unrelated short history:

This time, the x86_64 matching line is there...
This kind of unconventional rewrite of history makes me worry...
If we can't rely on history, then what a VCS is good for?

It's possible that the minheadless merge introduced that, so it would be good if more pairs of eyes could check that we did not loose anything important, especially for Pharo builds.
Nicolas Cellier
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: weird git history

Nicolas Cellier
 

Le lun. 7 janv. 2019 à 16:38, Jakob Reschke <[hidden email]> a écrit :
 
Hi Nicolas,

The two histories are of two different files: one is in build.linux32x86, the other one is in build.win32x86. Does that resolve your concerns?

Kind regards,
Jakob

Yes thanks,my bad, I just realized that!
When I said that we had too many duplicated files, it seems to be at least too many files for me!


Am Mo., 7. Jan. 2019 um 15:02 Uhr schrieb Nicolas Cellier <[hidden email]>:
 
Hi all,
In an obsolete working copy, I had some local changes to build.win32x86/thirdparty/Makefile.libssh2

    tar x -f $(LIBSSH2ARCHIVE) -C $(THIRDPARTYDIR)
    cd $(LIBSSH2DIR) \
        && ./configure \
--            --build=x86_64-w64-cygwin \
++            --build=i686-w64-cygwin \
            --host=i686-w64-mingw32 \
            --prefix='$(THIRDPARTYOUTDIR)' \
            CFLAGS='$(THIRDPARTY_CFLAGS)' \

If I go into current version:

I don't see the x86_64 line, good, this must have been already fixed!
But when I look at history thru github interface to know when and how, I see a very partial and truncated history:

And itseems like none of the commits referenced did remove this x86_64 line, like if it never existed...

If I go a little further in the past commit log, in early november (still thru github interface https://github.com/OpenSmalltalk/opensmalltalk-vm/commits/Cog?after=0fae80c28ee3ce2b3eb09cb31ec94f0a590893f7+174), select one of the commits and go tho this same file, then i see another unrelated short history:

This time, the x86_64 matching line is there...
This kind of unconventional rewrite of history makes me worry...
If we can't rely on history, then what a VCS is good for?

It's possible that the minheadless merge introduced that, so it would be good if more pairs of eyes could check that we did not loose anything important, especially for Pharo builds.
Free forum by Nabble Edit this page