Random Git Issues/Wishlist

Random Git Issues/Wishlist

[Petr Baudis]

  Hi,

  this is a random list of issues that come up in my mind when I was
thinking about things we could discuss at the Git BOF at OLS in case
enought Git developers gathered - which of course didn't happen but
perhaps it might be useful to mention them as well. Feel free to follow
up with *your* stuff (and comments or patches, of course).

  (i) libgit - right now it has just evolved from bundling random Git
internal calls and has no defined API whatsoever; luckily, nothing
external hopefully uses it yet. If we wait much longer, people will
probably start to and we might start getting into a trouble there.
Another thing is what to do with the builtins, shall we bundle most of
the code in libgit? If not, many libgit users will probably end up just
reimplementing large chunks of their functionality. I've actually
thought about also interfacing libbuiltin.so when doing Git.pm but I
didn't yet for the sake of simplicity.

  (ii) Documentation - it's currently very bad. Incomplete, out of sync,
missing tons of parameters and other things, and so on. We should be
more responsible when adding features to always document them right
away.

  (iii) Lazy clone, shallow clone, whatever you call it. This has
several possible degrees of implementation:

	(a) Just being able to get the latest revision (this really
	    shouldn't be that hard to do)
	(b) Arbitrarily cut off the revisions at some point; this means
	    that you will get _some_ repository but with incomplete
	    history and we should handle that sensibly, like...
	(c) ...having kind of "remote alternates", which means that if
	    we hit an object we don't have we will look it remotely as
	    well; this means moving the remote access functions much
	    more inside the really core Git; we want to be smart and
	    e.g. bundle tree requests with all the msisingblob requests
	    and so on; we don't want to fetch *everything* when the
	    user just does git log, though
	(d) As an extension of (a), having some side of server-client
	    stuff which would also know how to do rev-lists and such
	    remotely; I'm not sure if the demand here is big enough
	    to justify that

  (iv) Packing - I really feel bad about requiring users to manually
repack periodically, and also that's hurting the dumb server users
unless you take special provisions and so on

  (v) Subprojects support; in a sort of long-term limbo because I guess
everyone is too lazy to finally implement something and the users aren't
loud enough ;-) (or they just moved on to another VCS)

  (vi) Renames - should we follow them in logs? Will we? When? How
exactly in the interesting cases?

  (vii) Private tags. refs/private or refs/tags/.hidden? Will we even?
When?

  (viii) Patches versioning in StGit - many people I've told about StGit
complained that it doesn't version patches (and possibly moved to mq?).
We should have some scheme for doing meta-history (especially
interesting when/if we aim to make altering history easy).

  (ix) What about the user survey? It sorta stalled, as far as I can
see.

  (x) Metainformation over the Git protocol - kernel.org wants this
badly because rsyncing the repositories leads to *endless* problems;
there are some more complicated rsync schemes possible but hpa would be
happiest with making it possible to just use git to sync the
repositories out; this might be in part dependent on (iv) since the
repository maintainers basically lose control over the packing

  (xi) Annotate or blame? Most people seem to be in favour of blome,
but having both is confusing; by now one of them should've already won.

  (xii) Special merging - I now maintian the SuSE glibc package in git
and I'd like to use something more sensible than diff3 merger for
merging the changelogs from various branches; it's trivially solvable
conflicts all the time

  (xiii) General user interface issues, like confusing error messages,
incomplete usage help, needlessly complicated (see our git init
discussion in the other thread) or inconsistent usage (git rebase,
anyone?) in general and other stuff aside of (ii).

  That's probably all you'll hear from me for now, I guess. It's your
turn now.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam

Re: Random Git Issues/Wishlist

[Paolo Ciarrocchi]

On 7/22/06, Petr Baudis <pasky@suse.cz> wrote:
[...]
>   (ix) What about the user survey? It sorta stalled, as far as I can
> see.

Here it is the latest version:

About you

    1. What country are you in?
    2. What is your preferred language?

Getting started with GIT

    1. How did you hear about GIT?
    2. Did you find GIT easy to learn?
    3. What helped you most in learning to use it?
    4. When did you start using git?

How you use GIT

    1. Do you use GIT for work, unpaid projects, or both?
    2. How do you obtain GIT?  Source tarball, binary package, or
       pull the main repository?
    3. What hardware platforms do you use GIT on?
    4. What OS (please include the version) do you use GIT on?
    5. How many people do you collaborate with using GIT?
    6. How big are the repositories that you work on? (e.g. how many
       files, how much disk space, how deep is the history)
    7. How many different projects do you manage using GIT?
    8. Which porcelains do you use?
    9. Is the git.git repository including codes produced by you?

What you think of GIT

    1. Overall, how happy are you with GIT?
    2. How does GIT compare to other SCM tools you have used?
    3. What do you like about using GIT?
    4. What would you most like to see improved about GIT?
       (features, bugs, plugins, documentation, ...)
    5. If you want to see GIT more widely used, what do you
       think we could do to make this happen?

Documentation

    1. Do you use the GIT wiki?   If yes, do you find it useful?
    2. Do you find GIT's online help useful?
    3. What is your favourite user documentation for any software
       projects or products you have used?
    4. What could be improved on the GIT homepage?

Getting help, staying in touch

    1. Have you tried to get GIT help from other people?
          * If yes, did you get these problems resolved quickly and to
            your liking?
    2. Do you subscribe to the mailing list?
          * If yes, do you find it useful, and traffic levels OK?
    3. Do you use the IRC channel (#git on irc.freenode.net)?


Open forum

    1. What other comments or suggestions do you have that are not
       covered by the questions above?

Sorry for not  following closely this topic but unfortunately I had
personal problems.
Martin, can you upload the survey to  survey.net.nz as we privately discussed?

If not, I'll sending out it in the next following days.

Thanks.

regards,
-- 
Paolo
http://paolo.ciarrocchi.googlepages.com
http://picasaweb.google.com/paolo.ciarrocchi

Re: Random Git Issues/Wishlist

[Martin Langhoff]

> Martin, can you upload the survey to  survey.net.nz as we privately discussed?

Done. this is what it looks like:

http://www.survey.net.nz/survey.php?b5659bb2a599d0649871f56b59819c50

I'll send you the login details to modify it. I've changed a few
things ever so slightly so it made sense when boiled down to an array
of radio buttons and text boxes. Survey.net doesn't quite support
"section titles" so I added the section title to the first question of
the set, hoping for a "conversational" approach to introducing the
section to the user.

The best way to edit it is by downloading the text file, editing in
$EDITOR and posting it back. the format is trivial, and explained here
http://survey.net.nz/index.php?page=faq under "Upload Survey".

cheers,



martin

Re: Random Git Issues/Wishlist

[Shawn Pearce]

Petr Baudis <pasky@suse.cz> wrote:
>   (iii) Lazy clone, shallow clone, whatever you call it. This has
> several possible degrees of implementation:

I'd love to work on this, but I just don't have time.  :-(
 
>   (vi) Renames - should we follow them in logs? Will we? When? How
> exactly in the interesting cases?

I thought this has been settled as ``we will not record renames
directly, but instead rely on after-the-fact comparsions to identify
renames and copies based on content similarity''.

The rename identification code in diffcore isn't the fastest, but
I think someone suggested caching the results of rename comparsions
under .git as a way of speeding that up.  Unfortunately nobody has
stepped forward with a reasonable caching implementation, and I
think it was also debated that caching is probably not worthwhile
due to the high number of permutations people would typically be
asking for from diffcore.
 
>   (viii) Patches versioning in StGit - many people I've told about StGit
> complained that it doesn't version patches (and possibly moved to mq?).
> We should have some scheme for doing meta-history (especially
> interesting when/if we aim to make altering history easy).

Doesn't StGit now have a single ref for every patch commit?
What about turning on reflog support on those refs and reading the
reflog for the ``history'' of that patch?  Granted the reflog isn't
prune proof but it is a history of that ref's values over time.

You can already go back in that history with the @{yesterday}
syntax (e.g. "HEAD@{yesterday}") anywhere a sha1 expression is
valid (e.g. git-log) but StGit doesn't take advantage of it.
 
>   (xii) Special merging - I now maintian the SuSE glibc package in git
> and I'd like to use something more sensible than diff3 merger for
> merging the changelogs from various branches; it's trivially solvable
> conflicts all the time

I've been waiting for the C based recursive merger to get stable
before I take a crack at parameterizing the `merge` invocation.
I much prefer using patch reject files for conflict resolution,
but that's just me.  (Besides opening a single patch process and
shoving a stream of all diffs at it is faster on Cygwin than forking
30+ merge processes for 30 files with conflicts.)

I take it you are really asking for a way to parameterize the 3 way
merge tool on a file-by-file basis, e.g. adding to the config file:

	[mergetool "default"]
		program = merge %real %stage1 %stage3
		real = stage2

	[mergetool "ChangeLog"]
		program = change-log-merger %stage1 %stage2 %stage3 %real

	[mergetool "some/bad/binary-file"]
		program = cp %stage2 %real

An issue with storing this data in the config file is what happens
if the stuff stored at the path "some/bad/binary-file" changes such
that simply using `cp` (as above) is horribly wrong.  Another is how
do you pass these "reasonable defaults" off to other team members
on a repository-by-repository basis, assuming you all have access
to the same tools (e.g. the change-log-merger mentioned above).

-- 
Shawn.

Re: Random Git Issues/Wishlist

[Paolo Ciarrocchi]

On 7/23/06, Martin Langhoff <martin.langhoff@gmail.com> wrote:
> > Martin, can you upload the survey to  survey.net.nz as we privately discussed?
>
> Done. this is what it looks like:
>
> http://www.survey.net.nz/survey.php?b5659bb2a599d0649871f56b59819c50
>
> I'll send you the login details to modify it. I've changed a few
> things ever so slightly so it made sense when boiled down to an array
> of radio buttons and text boxes. Survey.net doesn't quite support
> "section titles" so I added the section title to the first question of
> the set, hoping for a "conversational" approach to introducing the
> section to the user.
>
> The best way to edit it is by downloading the text file, editing in
> $EDITOR and posting it back. the format is trivial, and explained here
> http://survey.net.nz/index.php?page=faq under "Upload Survey".

Thanks a lot Martin! I will send out an announce in a few minutes.

regards,

-- 
Paolo
http://paolo.ciarrocchi.googlepages.com
http://picasaweb.google.com/paolo.ciarrocchi

Re: Random Git Issues/Wishlist

[Catalin Marinas]

Shawn Pearce <spearce@spearce.org> wrote:
> Petr Baudis <pasky@suse.cz> wrote:
>>   (viii) Patches versioning in StGit - many people I've told about StGit
>> complained that it doesn't version patches (and possibly moved to mq?).
>> We should have some scheme for doing meta-history (especially
>> interesting when/if we aim to make altering history easy).
>
> Doesn't StGit now have a single ref for every patch commit?

Yes, it does and the history is lost.

> What about turning on reflog support on those refs and reading the
> reflog for the ``history'' of that patch?  Granted the reflog isn't
> prune proof but it is a history of that ref's values over time.

That's a good idea indeed (I haven't noticed this feature). Anyway, I
don't see any problem with not being prune-safe. I wouldn't want to
preserve the refresh history of a patch forever. If I have a stable
series I want to keep, I either clone it or simply tag it.

I think that people willing to keep the patch history for a number of
years (and be prune-safe) should use topic branches rather than
StGIT. Patches are meant to be more lightweight than topic branches
and might have a shorter life-time. There were some people at the OLS
BOF session even mentioning that they don't care about long-term
history.

The StGIT feature wish-list after the OLS is:

- patch history (I'll probably use reflogs as you suggested)
- configurable pull command (currently uses git-pull only)
- commit directly to a patch which is not top
- patch synchronisation between between branches (as some people,
  including me have the same patches based on different branches and
  they have scripts for moving the changes in one to the others)
- document the workflow on the StGIT wiki
- maybe a separate undo command rather than passing a --undo option to
  push and refresh

-- 
Catalin

Re: Random Git Issues/Wishlist

[Petr Baudis]

  Mailcromancy for fun'n'profit.

Dear diary, on Mon, Jul 24, 2006 at 12:19:01PM CEST, I got a letter
where Catalin Marinas <catalin.marinas@arm.com> said that...
> The StGIT feature wish-list after the OLS is:
> 
> - patch history (I'll probably use reflogs as you suggested)
> - configurable pull command (currently uses git-pull only)
> - commit directly to a patch which is not top
> - patch synchronisation between between branches (as some people,
>   including me have the same patches based on different branches and
>   they have scripts for moving the changes in one to the others)
> - document the workflow on the StGIT wiki
> - maybe a separate undo command rather than passing a --undo option to
>   push and refresh

  After talking with some more random and less random people, another
_big_ wishlist item is having something like a series file (not
necessarily used for storing stuff but just as a user interface), so
that you can easily _reorder_ your patches - that's an onerous task with
StGIT currently, involving a lot of involved popping and pushing.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)