From: Petr Baudis <hidden> Date: 2016-06-15 22:42:34
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
From: Paolo Ciarrocchi <hidden> Date: 2016-06-15 22:42:34
On 7/22/06, Petr Baudis [off-list ref] 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.comhttp://picasaweb.google.com/paolo.ciarrocchi
From: Martin Langhoff <hidden> Date: 2016-06-15 22:42:34
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
(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.
From: Paolo Ciarrocchi <hidden> Date: 2016-06-15 22:42:34
On 7/23/06, Martin Langhoff [off-list ref] wrote:
quoted
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".