Re: [Mingw-cross-env-list] new tool: patch-tool-mingw

[Volker Grabsch]

Mark Brand <address@hidden> schrieb:
>>>
>>> I have checked in a script to make it easy to convert between patch
>>> files and short-lived git repos. This version is newer than the one I
>>> already shared with some of you.
>>>
>>> http://hg.savannah.gnu.org/hgweb/mingw-cross-env/rev/5d51efc6e43a
>>>
>>> There's room for improvement, so feel free to criticize, improve,
>>> rename, etc.
>>
>> I see fundamental design flaw in the tool, and in the idea of
>> having a bunch of shell scripts in a "tools/" folder.
>
> I don't like "tools/" either. I just saw it as a temporary solution to  
> get it "out there".

Okay, so let's try to replace it with a better solution. Maybe not
before the release, but ASAP after that.

I like your approach to mataining patches, and I didn't intent to
talk your scripts down. Rather, I think they don't go far enogh. :-)

>> 2)  Although not everyone likes GNU Make's macros, they at least
>>      provide _some_ means of abstraction. Doing that in Bash is
>>      almost impossible. So the choice of language is far from
>>      optimal.
>>
>> 3)  The main Makefile provides lots of helpers for the package
>>      files (src/*.mk, src/*.patch, ...). Not using them means
>>      having to parse those files "by hand", and this is what
>>      quite a big part of your shell script does.
>
> I completely agree. Again, that parsing was just a quick hack to get it  
> working.
>
> I see 2 approaches to improving the current situation. The first invokes  
> make from the bash script to parse the pkg strings. The second involves  
> implementing the "init", 'import", "export" functions in the make file,  
> so the makefile invokes smalls bits of bash instead of the other way  
> around. The second approach seems clearly the right one, consistent with  
> the design of mingw-cross-env.

No, even the second one doesn't fit well, IMHO, because it still
requires a cumbersome workflow. See point 5) where I proposed
another kind of integration.

>> 5)  Separate shell scripts may automate some tasks, but still
>>      require a quite cumbersome workflow. Why not thinking about
>>      the workflow _first_? For instance, why not creating a mode /
>>      command that does a normal build, and if one packages fails,
>>      creates an ad-hoc repository automatically, filled with the
>>      already exported patches? When calling "make" or "make PKG"
>>      after that, the patches could be recreated from the repository
>>      automatically before the build starts.
>
> That sounds reasonable, but that would be an application of the basic  
> "init", "import", "export" functions prototyped in my bash script, right?

Maybe this. Or maybe some kind of combination of those actions. For
instance, I don't see why "init" should be explicit (it should be
run automatically), and why "import" should be a separate step from
"init". This may save some CPU cycles, but saving human time is IMHO
more desirable. :-)

>> 4)  The script uses Git for no good reason. That is, it doesn't
>>      use any of the advanced Git features. Everyone who uses the
>>      development version of Mingw-cross-env already has Mercurial.
>>      Why requiring them to install yet another tool for the same
>>      job?
>
> Here are my reasons for using git:

Thanks for clarifying. Note that I'm not against Git (although I
personally prefer Mercurial and Darcs). I just think that we should
use only _one_ tool for one job. So if Git provides some killer
features that are unavailable in Mercurial, I'd like to switch
the _whole_ project to Git. Otherwise, I'd like to use Mercurial
consistently.

>    The user can use the "advanced Git features", particularly "git
>    rebase -i" before exporting work back to the patch file.

Is this something you cannot do in Mercurial? What's the difference
to e.g. "hg rebase"?

>    Supports "git format-patch" format which is probably something like
>    a standard.

This standard seems to be accepted by Mercurial, too. For instance,
there are "hg diff --git", "hg export --git" and maybe more. What
advantage does "git format-patch" provide over those?

> But there's no reason that hg couldn't be used here. We might have to  
> sacrifice the "git format-patch" format.  It would be nice to have a  
> format that works with git and hg so the choice would be up to the user.

That's a very diplomatic way to say "I'd like to keep working with Git
because Git is the better tool". :-)


Greets,
Volker

-- 
Volker Grabsch
---<<(())>>---