rfc - Changing the way gitk and git-gui are managed

rfc - Changing the way gitk and git-gui are managed

[Junio C Hamano]

Somebody off-list suggested removing gitk and git-gui directories from my
repository and I've been playing with the idea and kind of like the end
result.

The plan (I am not decided to buy into it yet, hence I am sending this
rfc) is to:

    - remove gitk-git and git-gui directories;
    - add modules/gitk and modules/git-gui submodules;
    - teach the top-level Makefile about the new location of these two
      packages.

Switching from 1.7.2 to this tree will of course give you a tree without
gitk and git-gui (nothing a simple "git submodule init/update" cannot
fix), and switching back from there to 1.7.2 codebase needs manual removal
of these two directories that will become leftover directories if you want
to keep the superproject directory pristine clean, but other than that, I
do not see major downsides.

I am wondering what people think.  Especially distro people who download
and package git may be heavily affected.  I haven't adjusted the RPM spec
file or "make dist" target, so I cannot assess the damage to these people
myself yet.

Re: rfc - Changing the way gitk and git-gui are managed

[Sverre Rabbelier]

Heya,

On Thu, Jul 22, 2010 at 21:39, Junio C Hamano <gitster@pobox.com> wrote:
> Somebody off-list suggested removing gitk and git-gui directories from my
> repository and I've been playing with the idea and kind of like the end
> result.

The neighboring thread [0] about git subtree seems highly relevant to
this decision. Avery, do you perhaps any additional insights wrt this
particular use case?

I on one hand like that we're going to (finally) start dogfooding
submodules, but after reading Avery's emails I feel unsure whether
that really is the right course of action...

[0] http://thread.gmane.org/gmane.comp.version-control.git/151408

-- 
Cheers,

Sverre Rabbelier

Re: rfc - Changing the way gitk and git-gui are managed

[Avery Pennarun]

On Fri, Jul 23, 2010 at 12:04 AM, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> On Thu, Jul 22, 2010 at 21:39, Junio C Hamano <gitster@pobox.com> wrote:
>> Somebody off-list suggested removing gitk and git-gui directories from my
>> repository and I've been playing with the idea and kind of like the end
>> result.
>
> The neighboring thread [0] about git subtree seems highly relevant to
> this decision. Avery, do you perhaps any additional insights wrt this
> particular use case?

Only this: Junio said that there are no major downsides to this change
- and given the slow pace of change in gitk/git-gui, this is probably
true - but are there any *upsides*?  What problem does this solve?

git-submodule and git-subtree solve different problems, so which one
is "better" depends on the problem to be solved.  As a
mostly-just-user of git, whatever is currently being done is super
convenient and easy for me and I wouldn't ask for any change at all.
Obviously it might be very different from Junio's point of view :)

Have fun,

Avery

Re: rfc - Changing the way gitk and git-gui are managed

[Will Palmer]

On Thu, 2010-07-22 at 19:39 -0700, Junio C Hamano wrote:
> Somebody off-list suggested removing gitk and git-gui directories from my
> repository and I've been playing with the idea and kind of like the end
> result.
...snip...
> 
> I am wondering what people think.
...snip...

I really like the idea of using submodules, though only so that they
will almost certainly get the UI attention they deserve. Indeed, in my
mind that attention is needed enough that this sort of switch shouldn't
be made until it's been given for a while.

The problem is that, unlike so much of git, submodules make themselves
known. They're loud, they're in the way, they require management to
work. Case in point:
"Switching from 1.7.2 to this tree will of course give you a tree
without gitk and git-gui (nothing a simple "git submodule init/update"
cannot fix)"

So already in order to build a working git again, someone needs to
manually run some extra commands, which could potentially (but not
necessarily) download a bunch of objects they already have. Basic
operations like switching branches, get an extra (and easily overlooked)
burden, to which there is sometimes no obvious solution Ouch.

I've always hated how clunky and non-transparent submodules are. There
are some serious issues which would need to be worked out in order to
make them more transparent (not the least of which is "to be
transparent, where do you put the extra data, and when do you put it
there / when do you remove it?". I do wish that these issues would get
resolved, and it's hard to give them the attention they need because [I
assume, like me] the people who don't like them simply avoid using
submodules, as "just track everything" just sounds more like the git
way.

Git is simple. It's easy to understand because of some simple
assumptions and definitions. Submodules are less-simple. There are a lot
of edge-cases and a lot of not-so-edge cases which need to be looked out
for in order to make them sane. Handling the tricky-but-common cases by
putting it on the user to always hand-hold the VCS is stupid and broken.

What do people really want which a move to submodules would get them?
  - Sub-Projects can obviously be developed separately (no need to clone
all of git in order to work on gitk, for example)
  - Merges that make more sense, since you don't need to pass special
"subtree" options, all you need to do is update the commit which gitk
points to. This ignores that merges across the submodule/subtree
boundary will not work, and similarly changes which span submodules have
no way of being blamed or sanely merged.

It certainly doesn't help that whenever I think about "how to fix
submodules", the more I think about them, the less I think they make any
sense at all. [rant deleted]

Put me down as: I've wanted to use submodules in the past, and I like
the idea of using them in the future, but I've yet to be at the point
where I wanted to use submodules "now".

-- 
-- Will

Re: rfc - Changing the way gitk and git-gui are managed

[Greg Troxel]

[-- Attachment #1: Type: text/plain, Size: 2242 bytes --]


  The plan (I am not decided to buy into it yet, hence I am sending this
  rfc) is to:

      - remove gitk-git and git-gui directories;
      - add modules/gitk and modules/git-gui submodules;
      - teach the top-level Makefile about the new location of these two
        packages.

  Switching from 1.7.2 to this tree will of course give you a tree without
  gitk and git-gui (nothing a simple "git submodule init/update" cannot
  fix), and switching back from there to 1.7.2 codebase needs manual removal
  of these two directories that will become leftover directories if you want
  to keep the superproject directory pristine clean, but other than that, I
  do not see major downsides.

  I am wondering what people think.  Especially distro people who download
  and package git may be heavily affected.  I haven't adjusted the RPM spec
  file or "make dist" target, so I cannot assess the damage to these people
  myself yet.

(I am perhaps going to be involved in maintaining the git package in pkgsrc.)

In general, the effort to update the package control files is basically
5 minutes per release (to change version, test, and summarize release
notes) plus coping with structural changes in how the package builds and
what it installs.

Perhaps implicit in your mail above:

  create new distribution packages for gitk and git-gui.  These would
  have their own autoconf setup, and be independent packages, depending
  on the base git package.

Assuming that:

  From a packager viewpoint this is good.  That would make it easier to
  have a base git package that doesn't depend on much, and then a gitk
  package that just has gitk, depending on what it needs to.

  (A problem with git now is that it depends on tcl.  I gather Linux
  packaging systems tend to build everything with the full set of
  possible dependencies and then split it into separate binary packages.
  pkgsrc is more focused on source builds and thus we really don't want
  to have tcl installed if the user doesn't want the gui, and a side
  effect of this focus is the lack of support for split packages from
  one build.)

If you don't mean separate distribution tarballs, then could you explain
how the released tarballs would change structurally?




[-- Attachment #2: Type: application/pgp-signature, Size: 194 bytes --]

Re: rfc - Changing the way gitk and git-gui are managed

[Nicolas Sebrecht]

The 22/07/10, Junio C Hamano wrote:

> Somebody off-list suggested removing gitk and git-gui directories from my
> repository and I've been playing with the idea and kind of like the end
> result.

What is the issue with the current status?

> The plan (I am not decided to buy into it yet, hence I am sending this
> rfc) is to:
> 
>     - remove gitk-git and git-gui directories;
>     - add modules/gitk and modules/git-gui submodules;
>     - teach the top-level Makefile about the new location of these two
>       packages.

Going this way, why would we want gitk and git-gui as submodules at all?
They are porcelain tools as many other not in git.git.

-- 
Nicolas Sebrecht

Re: rfc - Changing the way gitk and git-gui are managed

[Jonathan Nieder]

Nicolas Sebrecht wrote:

> What is the issue with the current status?

Here is one:

 $ git log --oneline -SListbox.font -- gitk-git/gitk
 $ git log --oneline --follow -SListbox.font -- gitk-git/gitk
 62ba514 Move gitk to its own subdirectory
 $ git log --oneline -SListbox.font -- gitk-git/gitk gitk
 207ad7b gitk: Set the font for all listbox widgets
 $

> Going this way, why would we want gitk and git-gui as submodules at all?

If we want to stop distributing them completely (though I am not
convinced that would be a good idea), then submodules would be a
good stopping point along the way to avoid changing the world too
much at a time.

git archive hasn’t learned to do recursive archive yet; I think
the last murmurs of that topic were [1] and [2], though it would
be simple enough to use "git archive" more than once together
with "tar rf" to take care of it by hand in this case.

[1] http://thread.gmane.org/gmane.comp.version-control.git/107030
which is a reroll of
http://thread.gmane.org/gmane.comp.version-control.git/106788/focus=106787

[2] http://thread.gmane.org/gmane.comp.version-control.git/106788/focus=106787

Re: rfc - Changing the way gitk and git-gui are managed

[Jonathan Nieder]

Jonathan Nieder wrote:

> git archive hasn’t learned to do recursive archive yet; I think
> the last murmurs of that topic were [1] and [2]
[...]
> [2] http://thread.gmane.org/gmane.comp.version-control.git/106788/focus=106787

Operator error, sorry.  That link should read
http://thread.gmane.org/gmane.comp.version-control.git/140032

Good night.

Re: rfc - Changing the way gitk and git-gui are managed

[Nicolas Sebrecht]

The 24/07/10, Jonathan Nieder wrote:
> Nicolas Sebrecht wrote:
> 
> > What is the issue with the current status?
> 
> Here is one:
> 
>  $ git log --oneline -SListbox.font -- gitk-git/gitk
>  $ git log --oneline --follow -SListbox.font -- gitk-git/gitk
>  62ba514 Move gitk to its own subdirectory
>  $ git log --oneline -SListbox.font -- gitk-git/gitk gitk
>  207ad7b gitk: Set the font for all listbox widgets
>  $

I'm sorry, I don't get your point here.

> > Going this way, why would we want gitk and git-gui as submodules at all?
> 
> If we want to stop distributing them completely (though I am not
> convinced that would be a good idea), then submodules would be a
> good stopping point along the way to avoid changing the world too
> much at a time.

It depends on why we would want to split gitk and git-gui from git. If
it's a packaging issue only (especially for distribution maintainers),
going by the "submodule" step looks more like adding a non-valuable
extra step in the "splitting packages" mainstream.

Changing the world once seems better than twice.

> git archive hasn’t learned to do recursive archive yet; I think
> the last murmurs of that topic were [1] and [2],

I understand gitk and git-gui are in the Git repository mostly for
historical reason. I don't want to hurt someone here but I still don't
see what both have so special against other porcelain tools not in
git.git.

>                                                  though it would
> be simple enough to use "git archive" more than once together
> with "tar rf" to take care of it by hand in this case.

So, doing a tar archive of them all (with or whitout submodules) is not
such an issue.

-- 
Nicolas Sebrecht

Re: rfc - Changing the way gitk and git-gui are managed

[Jonathan Nieder]

Nicolas Sebrecht wrote:
> The 24/07/10, Jonathan Nieder wrote:
>> Nicolas Sebrecht wrote:

>>> What is the issue with the current status?
>>
>> Here is one:
>>
>>  $ git log --oneline -SListbox.font -- gitk-git/gitk
>>  $ git log --oneline --follow -SListbox.font -- gitk-git/gitk
>>  62ba514 Move gitk to its own subdirectory
>>  $ git log --oneline -SListbox.font -- gitk-git/gitk gitk
>>  207ad7b gitk: Set the font for all listbox widgets
>>  $
>
> I'm sorry, I don't get your point here.

If a person tries to drill into history to figure out the answer to a
question like "when was that code involving Listbox.font added", it is
totally counterintuitive how to do that now.

I run into this with git.git very often (you would think I would
learn).

I don’t have any argument with the rest of what you have said.  I
probably did not make it clear enough that I was not trying to
advocate for one side, only presenting pertinent information.

Regards,
Jonathan

Re: rfc - Changing the way gitk and git-gui are managed

[Avery Pennarun]

On Sat, Jul 24, 2010 at 8:54 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Nicolas Sebrecht wrote:
>> What is the issue with the current status?
>
> Here is one:
>
>  $ git log --oneline -SListbox.font -- gitk-git/gitk
>  $ git log --oneline --follow -SListbox.font -- gitk-git/gitk
>  62ba514 Move gitk to its own subdirectory
>  $ git log --oneline -SListbox.font -- gitk-git/gitk gitk
>  207ad7b gitk: Set the font for all listbox widgets
>  $

This is a bug in git log --follow, not a reason to completely redesign the repo.

FWIW, I previously tracked the bug down to the fact that it doesn't
track file renames that happen during a merge commit, which is what
subtree merge produces.  I don't have the time or knowledge required
to fix it.

Have fun,

Avery

Re: rfc - Changing the way gitk and git-gui are managed

[Jonathan Nieder]

Avery Pennarun wrote:
> On Sat, Jul 24, 2010 at 8:54 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:

>>  $ git log --oneline -SListbox.font -- gitk-git/gitk
>>  $ git log --oneline --follow -SListbox.font -- gitk-git/gitk
>>  62ba514 Move gitk to its own subdirectory
>>  $ git log --oneline -SListbox.font -- gitk-git/gitk gitk
>>  207ad7b gitk: Set the font for all listbox widgets
>>  $
>
> This is a bug in git log --follow

The first one is not.

> FWIW, I previously tracked the bug down to the fact that it doesn't
> track file renames that happen during a merge commit, which is what
> subtree merge produces.  I don't have the time or knowledge required
> to fix it.

Another pointer for interested people:

  http://thread.gmane.org/gmane.comp.version-control.git/150727/focus=150796

I prefer to work without --follow, anyway. :)

Hope that helps,
Jonathan

Re: rfc - Changing the way gitk and git-gui are managed

[Avery Pennarun]

On Sat, Jul 24, 2010 at 3:34 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Avery Pennarun wrote:
>> On Sat, Jul 24, 2010 at 8:54 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
>
>>>  $ git log --oneline -SListbox.font -- gitk-git/gitk
>>>  $ git log --oneline --follow -SListbox.font -- gitk-git/gitk
>>>  62ba514 Move gitk to its own subdirectory
>>>  $ git log --oneline -SListbox.font -- gitk-git/gitk gitk
>>>  207ad7b gitk: Set the font for all listbox widgets
>>>  $
>>
>> This is a bug in git log --follow
>
> The first one is not.

That one is a bug in history simplification, which has simplified away
commits that affected files that got renamed into gitk-git/gitk during
a merge commit.  So the bug is very similar, albeit probably in a
different place in the code.  (-M doesn't help either.)

Avery

Re: rfc - Changing the way gitk and git-gui are managed

[Sam Vilain]

On Fri, 2010-07-23 at 07:54 +0100, Will Palmer wrote:
> The problem is that, unlike so much of git, submodules make themselves
> known. They're loud, they're in the way, they require management to
> work. Case in point:
> "Switching from 1.7.2 to this tree will of course give you a tree
> without gitk and git-gui (nothing a simple "git submodule init/update"
> cannot fix)"
> 
> So already in order to build a working git again, someone needs to
> manually run some extra commands, which could potentially (but not
  [...]

There's a relatively comprehensive list of TODO items on the git wiki
along with the summer of code ideas page.  They have been known for some
time, but up till now most people have just worked around them.  I think
using it for git-core would possibly assist in creating the anger that
some of these changes will need to be performed in to be of greater
benefit to the community as a whole ;-)

submodules are nice; it's good for instance to be able to keep unrelated
parts of the project out of the history view, squashed in the main
project yet still fine-grained and bisectable in the sub-project.  While
I haven't gone through the other people who have described their use
cases/requirements in detail, it strikes me that many of the existing
ideas would help these requirements be met too.

Sam

Re: rfc - Changing the way gitk and git-gui are managed

[Jeff King]

On Fri, Jul 23, 2010 at 02:16:45AM -0400, Avery Pennarun wrote:

> Only this: Junio said that there are no major downsides to this change
> - and given the slow pace of change in gitk/git-gui, this is probably
> true - but are there any *upsides*?  What problem does this solve?

One minor complaint with the current setup is that browsing the history
with path limiting is unintuitive. You can't do "gitk gitk" in the
gitk-git directory. You must instead do "cd .. && gitk -- gitk".

-Peff

Re: rfc - Changing the way gitk and git-gui are managed

[Avery Pennarun]

On Tue, Jul 27, 2010 at 1:30 AM, Jeff King <peff@peff.net> wrote:
> On Fri, Jul 23, 2010 at 02:16:45AM -0400, Avery Pennarun wrote:
>> Only this: Junio said that there are no major downsides to this change
>> - and given the slow pace of change in gitk/git-gui, this is probably
>> true - but are there any *upsides*?  What problem does this solve?
>
> One minor complaint with the current setup is that browsing the history
> with path limiting is unintuitive. You can't do "gitk gitk" in the
> gitk-git directory. You must instead do "cd .. && gitk -- gitk".

Arguably this would be an encouragement to fix the path limiting code,
in a similar way that people expect switching to a submodule setup to
encourage people to fix submodules :)

Have fun,

Avery

Re: rfc - Changing the way gitk and git-gui are managed

[Jeff King]

On Tue, Jul 27, 2010 at 01:42:39AM -0400, Avery Pennarun wrote:

> On Tue, Jul 27, 2010 at 1:30 AM, Jeff King <peff@peff.net> wrote:
> > On Fri, Jul 23, 2010 at 02:16:45AM -0400, Avery Pennarun wrote:
> >> Only this: Junio said that there are no major downsides to this change
> >> - and given the slow pace of change in gitk/git-gui, this is probably
> >> true - but are there any *upsides*?  What problem does this solve?
> >
> > One minor complaint with the current setup is that browsing the history
> > with path limiting is unintuitive. You can't do "gitk gitk" in the
> > gitk-git directory. You must instead do "cd .. && gitk -- gitk".
> 
> Arguably this would be an encouragement to fix the path limiting code,
> in a similar way that people expect switching to a submodule setup to
> encourage people to fix submodules :)

Heh. Somewhat true. My multi-file --follow code actually handles "git
log --follow gitk-git", but it does look awful in gitk. And that is not
likely to be fixed soon, as --follow and things like parent rewriting
simply don't work together at this point.

-Peff

Re: rfc - Changing the way gitk and git-gui are managed

[Jakub Narebski]

Jeff King <peff@peff.net> writes:

> On Fri, Jul 23, 2010 at 02:16:45AM -0400, Avery Pennarun wrote:
> 
> > Only this: Junio said that there are no major downsides to this change
> > - and given the slow pace of change in gitk/git-gui, this is probably
> > true - but are there any *upsides*?  What problem does this solve?
> 
> One minor complaint with the current setup is that browsing the history
> with path limiting is unintuitive. You can't do "gitk gitk" in the
> gitk-git directory. You must instead do "cd .. && gitk -- gitk".

Do 'gitk --relative=gitk' or 'gitk --relative' work?

-- 
Jakub Narebski
Poland
ShadeHawk on #git