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

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.

Heya,

On Thu, Jul 22, 2010 at 21:39, Junio C Hamano <gitster@pobox.com> wrote:

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

On Fri, Jul 23, 2010 at 12:04 AM, Sverre Rabbelier <srabbelier@gmail.com> 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?

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

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

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

On Tue, Jul 27, 2010 at 1:30 AM, Jeff King <peff@peff.net> wrote:

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

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

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

Jeff King <peff@peff.net> writes:

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

On Thu, 2010-07-22 at 19:39 -0700, Junio C Hamano wrote:

...snip...

...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".

On Fri, 2010-07-23 at 07:54 +0100, Will Palmer wrote:

  [...]

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

  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?

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

What is the issue with the current status?

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 wrote:

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
 $

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

Jonathan Nieder wrote:

[...]

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

Good night.

The 24/07/10, Jonathan Nieder wrote:

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

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.

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.

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

Nicolas Sebrecht wrote:

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

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

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

Avery Pennarun wrote:

The first one is not.

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

On Sat, Jul 24, 2010 at 3:34 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:

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