SuperGitMe

[Johannes Schindelin]

Hi,

some more comments on SuperGitMe: you checked in binaries of the git files
we generate. Why not take the generated ones? I grow a little wary of
things which are compiled for me, and where I cannot see what they do (and
how they do it).

It also adds to the bloat of msysgit.git, which I tried very much to get
down a little (note that we cannot easily compile qgit because of that,
since I even squeezed out c++).

And I am still not at all convinced (it would take some good arguments to
do so) that having an unversioned installer would be a good idea, an
installer which loads whatever crap there is on repo.or.cz and executes
that.

You told me very much about corporate ways to handle issues, by
bug-tracking, purportedly because it is a known and proven technique. Why
do you stop at versioning programs?

Ciao,
Dscho

[Dmitry Kakurin]

First I want to explicitly state my goal:
I want to make pushing devel->master (or rc->master now) to be just
that: a single git operation. No additional steps like rebuild and
upload installer should be necessary.
A secondary goal: I want to rebuild GitMe.exe as rare as possible.
Preferably never.

Now to address your specific concerns...

On 8/15/07, Johannes Schindelin <Johannes....@gmx.de> wrote:
> some more comments on SuperGitMe: you checked in binaries of the git files
> we generate. Why not take the generated ones? I grow a little wary of
> things which are compiled for me, and where I cannot see what they do (and
> how they do it).

This is the only way that would allow us to upgrade these binaries
without rebuilding installer.
Taking into account that Git is smart enough not to store the same
file twice we don't pay for all these files from /bin like
msys-1.0.dll, sort, tar etc. So the extra space is only for git* files
and is ~3MB uncompressed.

> It also adds to the bloat of msysgit.git, which I tried very much to get
> down a little (note that we cannot easily compile qgit because of that,
> since I even squeezed out c++).

I think if we *really* need/want to build qgit then we should
sacrifice some space.

> And I am still not at all convinced (it would take some good arguments to
> do so) that having an unversioned installer would be a good idea, an
> installer which loads whatever crap there is on repo.or.cz and executes
> that.
> You told me very much about corporate ways to handle issues, by
> bug-tracking, purportedly because it is a known and proven technique. Why
> do you stop at versioning programs?

If it's the versioning of installer that concerns you then it's the
versioning of installer that we will address :-).
Seriously, I share the concern. We will solve it by tagging and
allowing to supply desired version to GitMe. Also we can have a
"moving tag" 'stable' that always reflect the latest stable version.
But in general master/head should be just that.

--
- Dmitry

[Johannes Schindelin]

Hi,

On Wed, 15 Aug 2007, Dmitry Kakurin wrote:

> First I want to explicitly state my goal:
>
> I want to make pushing devel->master (or rc->master now) to be just
> that: a single git operation. No additional steps like rebuild and
> upload installer should be necessary.

It cannot be a single operation. Because you have to test it. Alas, this
is no longer possible with SuperGitMe, because you have to update the
"moving tag" and during that test phase _everybody_ tests with you.

IOW I still think SuperGitMe is wrong.

> A secondary goal: I want to rebuild GitMe.exe as rare as possible.
> Preferably never.

But why? I do not see why it should be built rarely. It's not like it
takes ages to begin with.

> On 8/15/07, Johannes Schindelin <Johannes....@gmx.de> wrote:
>
> > some more comments on SuperGitMe: you checked in binaries of the git
> > files we generate. Why not take the generated ones? I grow a little
> > wary of things which are compiled for me, and where I cannot see what
> > they do (and how they do it).
>
> This is the only way that would allow us to upgrade these binaries
> without rebuilding installer.

It makes things way more complicated. And that is almost _always_ the
wrong solution.

With GitMe:

$ cd /git && make test && make install
$ sh /share/GitMe/release.sh <version number>

With SuperGitMe:

[update the git binaries, keeping the utterly uninteresting _generated_
old binaries in the repo]
[possibly introduce a backdoor]
[check it in]
[move the moving tag, thereby removing the possibility to _reliably_
determine what the old version was]
[test, possibly fixing breakages]
[get bug reports from all the people installing with SuperGitMe during the
test phase]

Is there really any doubt left?

> Taking into account that Git is smart enough not to store the same file
> twice we don't pay for all these files from /bin like msys-1.0.dll,
> sort, tar etc. So the extra space is only for git* files and is ~3MB
> uncompressed.

Which we do not _need_ in there at all.

The way I really, _really_ would like things to be: Do a complete git
build, test it, install it. Build the installer from there and tag the
current revision.

Since we even tag the used gcc version, there is really _no_ need to check
in generated files.

> > It also adds to the bloat of msysgit.git, which I tried very much to
> > get down a little (note that we cannot easily compile qgit because of
> > that, since I even squeezed out c++).
>
> I think if we *really* need/want to build qgit then we should sacrifice
> some space.

Yes.

> > And I am still not at all convinced (it would take some good arguments
> > to do so) that having an unversioned installer would be a good idea,
> > an installer which loads whatever crap there is on repo.or.cz and
> > executes that.
> >
> > You told me very much about corporate ways to handle issues, by
> > bug-tracking, purportedly because it is a known and proven technique.
> > Why do you stop at versioning programs?
>
> If it's the versioning of installer that concerns you then it's the
> versioning of installer that we will address :-).
>
> Seriously, I share the concern. We will solve it by tagging and
> allowing to supply desired version to GitMe. Also we can have a
> "moving tag" 'stable' that always reflect the latest stable version.
> But in general master/head should be just that.

I do not like that approach at all. It reminds me of all the problems
that were solved by introducing version numbers. With git.git, I only
need to know the version people are using and I can see what their feature
set is.

Also, I do not see what it buys us. Generating GitMe.exe is _easy_.

Ciao,
Dscho

[Torgil Svensson]

On 8/15/07, Johannes Schindelin <Johannes....@gmx.de> wrote:

> It also adds to the bloat of msysgit.git, which I tried very much to get
> down a little (note that we cannot easily compile qgit because of that,
> since I even squeezed out c++).

No worries since they were deleted before the "start anew" - scheme.

What about more "start anew" branches but with a more sophisticated
(and easy to follow) name-space and relation-ships?

Imagine:

master1 branch -> commit -> commit -> commit -> Release : too bloated
master2 branch -> commit -> ...

all branches has different root-nodes ("start anew")

Then have one branch to track all history with all other branches as
sub-projects in the root folder (pointing to each root-node) plus
some clever scripts that does some cheating to fool gitk that they're
actually linked together.

> And I am still not at all convinced (it would take some good arguments to
> do so) that having an unversioned installer would be a good idea, an
> installer which loads whatever crap there is on repo.or.cz and executes
> that.

This will make it hard to go back and forth from, for instance, a
broken compiler to a good one with just "git checkout" or "git reset".
I really liked that.

//Torgil

[Johannes Schindelin]

Hi,

On Thu, 16 Aug 2007, Torgil Svensson wrote:

> On 8/15/07, Johannes Schindelin <Johannes....@gmx.de> wrote:
>
> > It also adds to the bloat of msysgit.git, which I tried very much to get
> > down a little (note that we cannot easily compile qgit because of that,
> > since I even squeezed out c++).
>
> No worries since they were deleted before the "start anew" - scheme.
>
> What about more "start anew" branches but with a more sophisticated
> (and easy to follow) name-space and relation-ships?
>
> Imagine:
>
> master1 branch -> commit -> commit -> commit -> Release : too bloated
> master2 branch -> commit -> ...
>
> all branches has different root-nodes ("start anew")
>
> Then have one branch to track all history with all other branches as
> sub-projects in the root folder (pointing to each root-node) plus
> some clever scripts that does some cheating to fool gitk that they're
> actually linked together.

I'd like it more if we did not have to start anew, but to branch for new
things like msmtp, SuperGitMe, etc. If it turns out that it is a dead end,
we either forget it, or delete it right away.

GitMe.exe should really only fetch the 'master' branch. Then we really do
not need any more "start anew"s...

Ciao,
Dscho

[Marius Storm-Olsen]

Johannes Schindelin wrote:
> And I am still not at all convinced (it would take some good
> arguments to do so) that having an unversioned installer would be a
> good idea, an installer which loads whatever crap there is on
> repo.or.cz and executes that.

GitMe-5:

Uses HTTP to download repos on my machine, (Guess that was the missing fetch-pack?) and fails:

Also look at http://repo.or.cz/srv/git/git/mingw.git/
Getting pack list for http://repo.or.cz/r/git/mingw/4msysgit.git
Getting index for pack a6accc71c7fa48c5a3e9ced2578fab7e6992fcf3
Getting pack a6accc71c7fa48c5a3e9ced2578fab7e6992fcf3
which contains d1f83218dce62affd1d7a82a9e654cca08dade9c
walk d1f83218dce62affd1d7a82a9e654cca08dade9c
Getting pack list for http://repo.or.cz/srv/git/git/mingw.git/
error: Unable to find 5529b198e8d14decbe4ad99db3f7fb632de0439d under http://repo.or.cz/r/git/mingw/4msysgit.git
Cannot obtain needed blob 5529b198e8d14decbe4ad99db3f7fb632de0439d
while processing commit d1f83218dce62affd1d7a82a9e654cca08dade9c.
Waiting for http://repo.or.cz/srv/git/git/mingw.git//objects/8d/12287f037c499acad26ea81acab73490c38d5c
Waiting for http://repo.or.cz/r/git/mingw/4msysgit.git/objects/91/6355ca5d04ec571d4100c98b969b693c830a18
Waiting for http://repo.or.cz/srv/git/git/mingw.git//objects/61/eba343ab781341a0baf127b323508a0c2af332
Waiting for http://repo.or.cz/srv/git/git/mingw.git//objects/9c/f22fef417cee29e550a35fef1bac1050482afa
Waiting for http://repo.or.cz/srv/git/git/mingw.git//objects/23/f6b0040f1cda9a550e5b1d90589fa4a7f76eb5
rm: cannot remove directory `/c/msysgit_temp/git/.git/clone-tmp': Directory notempty
rm: cannot remove directory `/c/msysgit_temp/git/.git': Directory not empty
rm: cannot remove directory `/c/msysgit_temp/git': Directory not empty
Clone of 'http://repo.or.cz/r/git/mingw/4msysgit.git' into submodule path 'git'
failed
* error: Couldn't update submodules!
INSTALLATION ABORTED

GitMe-6:
Fails when downloading the 4msysgit.git repo:

-------------------------------------------------------
Fetching the latest MinGW Git sources
-------------------------------------------------------
Submodule 'git' (git://repo.or.cz/git/mingw/4msysgit.git/) registered for path 'git'
warning: templates not found C:/GitDev/share/git-core/templates
Initialized empty Git repository in c:/msysgit_temp/git/.git/
fatal: early EOF
fatal: index-pack died with error code 128
fetch-pack from 'git://repo.or.cz/git/mingw/4msysgit.git/' failed.
Clone of 'git://repo.or.cz/git/mingw/4msysgit.git/' into submodule path 'git' failed
warning: templates not found C:/GitDev/share/git-core/templates
Initialized empty Git repository in c:/msysgit_temp/git/.git/
got a0b4827288741c7939e40e269aa8298454a56eff
walk a0b4827288741c7939e40e269aa8298454a56eff
Getting alternates list for http://repo.or.cz/r/git/mingw/4msysgit.git
Also look at http://repo.or.cz/srv/git/git/mingw.git/
got f56186fc3737b55d5cd7f89a208065d7b8f7d834
Getting pack list for http://repo.or.cz/r/git/mingw/4msysgit.git
Getting index for pack a6accc71c7fa48c5a3e9ced2578fab7e6992fcf3
Getting pack a6accc71c7fa48c5a3e9ced2578fab7e6992fcf3
which contains d1f83218dce62affd1d7a82a9e654cca08dade9c
walk d1f83218dce62affd1d7a82a9e654cca08dade9c
Getting pack list for http://repo.or.cz/srv/git/git/mingw.git/
error: Unable to find 5529b198e8d14decbe4ad99db3f7fb632de0439d under http://repo.or.cz/r/git/mingw/4msysgit.git
Cannot obtain needed blob 5529b198e8d14decbe4ad99db3f7fb632de0439d
while processing commit d1f83218dce62affd1d7a82a9e654cca08dade9c.
Waiting for http://repo.or.cz/srv/git/git/mingw.git//objects/6c/b30c8e12488f42521df71a844a86a2e9a968c7
Waiting for http://repo.or.cz/r/git/mingw/4msysgit.git/objects/0b/591c87169ff4b8c2173bedb26d6ed1a8a84b68
Waiting for http://repo.or.cz/srv/git/git/mingw.git//objects/18/7491bc172571b783a0be4f4dfa3d94d58bb0fe
Waiting for http://repo.or.cz/srv/git/git/mingw.git//objects/0a/fa1c5c41e79a05ddebb7d874956163510daf0b
Waiting for http://repo.or.cz/r/git/mingw/4msysgit.git/objects/8d/12287f037c499acad26ea81acab73490c38d5c
rm: cannot remove directory `/c/msysgit_temp/git/.git/clone-tmp': Directory not empty
rm: cannot remove directory `/c/msysgit_temp/git/.git': Directory not empty
rm: cannot remove directory `/c/msysgit_temp/git': Directory not empty
Clone of 'http://repo.or.cz/r/git/mingw/4msysgit.git' into submodule path 'git' failed
* error: Couldn't update submodules!
INSTALLATION ABORTED

--
.marius

[Dmitry Kakurin]

With GitMe6, are you sure that you've nuked c:\msysgit directory before trying?
When I was fixing issue with tags yesterday I have thoroughly tested it.
Including installing it on machine that never had any git.
In the past I had troubles with installer when c:\msysgit already had
a previous version.

--
- Dmitry

[Dmitry Kakurin]

We are debating over nothing. Let me just say that most (probably all)
you concerns will be addressed.
Let me finish SuperGitMe first and then we'll discuss it. I'm doing it
in a separate branch anyway.

--
- Dmitry

[Johannes Schindelin]

Hi,

On Thu, 16 Aug 2007, Dmitry Kakurin wrote:

> We are debating over nothing. Let me just say that most (probably all)
> you concerns will be addressed.
> Let me finish SuperGitMe first and then we'll discuss it. I'm doing it
> in a separate branch anyway.

Yeah, but I don't want you to work on something that will be nuked anyway.
Better work on the continuation of GitMe (and let's not confuse people and
rename GitMe-6.exe to SuperGitMe-6.exe).

Ciao,
Dscho

[Dmitry Kakurin]

On 8/16/07, Johannes Schindelin <Johannes....@gmx.de> wrote:
> > We are debating over nothing. Let me just say that most (probably all)
> > you concerns will be addressed.
> > Let me finish SuperGitMe first and then we'll discuss it. I'm doing it
> > in a separate branch anyway.
>
> Yeah, but I don't want you to work on something that will be nuked anyway.

Don't be so sure. Just wait till you see it :-). Worse case we'll keep
them both.

> Better work on the continuation of GitMe (and let's not confuse people and
> rename GitMe-6.exe to SuperGitMe-6.exe).

Renamed.
--
- Dmitry

[Johannes Schindelin]

Hi,

On Thu, 16 Aug 2007, Dmitry Kakurin wrote:

> On 8/16/07, Johannes Schindelin <Johannes....@gmx.de> wrote:
> > > We are debating over nothing. Let me just say that most (probably all)
> > > you concerns will be addressed.
> > > Let me finish SuperGitMe first and then we'll discuss it. I'm doing it
> > > in a separate branch anyway.
> >
> > Yeah, but I don't want you to work on something that will be nuked anyway.
>
> Don't be so sure. Just wait till you see it :-). Worse case we'll keep
> them both.

Heh. That option is always there, since you wisely started a new branch.

> > Better work on the continuation of GitMe (and let's not confuse people
> > and rename GitMe-6.exe to SuperGitMe-6.exe).
>
> Renamed.

Thanks.

Ciao,
Dscho