{"thread":{"id":"4950","subject":"Random Git Issues/Wishlist","startedAt":"2006-07-22T19:55:02Z","lastAt":"2006-09-23T23:18:25Z","messageCount":7,"participants":["Petr Baudis","Paolo Ciarrocchi","Martin Langhoff","Shawn Pearce","Catalin Marinas"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"24000","messageId":"20060722195502.GS13776@pasky.or.cz","threadId":"4950","inReplyTo":null,"subject":"Random Git Issues/Wishlist","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-07-22T19:55:02Z","receivedAt":"2006-07-22T19:55:02Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":" Hi,\n\n this is a random list of issues that come up in my mind when I was\nthinking about things we could discuss at the Git BOF at OLS in case\nenought Git developers gathered - which of course didn't happen but\nperhaps it might be useful to mention them as well. Feel free to follow\nup with *your* stuff (and comments or patches, of course).\n\n (i) libgit - right now it has just evolved from bundling random Git\ninternal calls and has no defined API whatsoever; luckily, nothing\nexternal hopefully uses it yet. If we wait much longer, people will\nprobably start to and we might start getting into a trouble there.\nAnother thing is what to do with the builtins, shall we bundle most of\nthe code in libgit? If not, many libgit users will probably end up just\nreimplementing large chunks of their functionality. I've actually\nthought about also interfacing libbuiltin.so when doing Git.pm but I\ndidn't yet for the sake of simplicity.\n\n (ii) Documentation - it's currently very bad. Incomplete, out of sync,\nmissing tons of parameters and other things, and so on. We should be\nmore responsible when adding features to always document them right\naway.\n\n (iii) Lazy clone, shallow clone, whatever you call it. This has\nseveral possible degrees of implementation:\n\n\t(a) Just being able to get the latest revision (this really\n\t shouldn't be that hard to do)\n\t(b) Arbitrarily cut off the revisions at some point; this means\n\t that you will get _some_ repository but with incomplete\n\t history and we should handle that sensibly, like...\n\t(c) ...having kind of \"remote alternates\", which means that if\n\t we hit an object we don't have we will look it remotely as\n\t well; this means moving the remote access functions much\n\t more inside the really core Git; we want to be smart and\n\t e.g. bundle tree requests with all the msisingblob requests\n\t and so on; we don't want to fetch *everything* when the\n\t user just does git log, though\n\t(d) As an extension of (a), having some side of server-client\n\t stuff which would also know how to do rev-lists and such\n\t remotely; I'm not sure if the demand here is big enough\n\t to justify that\n\n (iv) Packing - I really feel bad about requiring users to manually\nrepack periodically, and also that's hurting the dumb server users\nunless you take special provisions and so on\n\n (v) Subprojects support; in a sort of long-term limbo because I guess\neveryone is too lazy to finally implement something and the users aren't\nloud enough ;-) (or they just moved on to another VCS)\n\n (vi) Renames - should we follow them in logs? Will we? When? How\nexactly in the interesting cases?\n\n (vii) Private tags. refs/private or refs/tags/.hidden? Will we even?\nWhen?\n\n (viii) Patches versioning in StGit - many people I've told about StGit\ncomplained that it doesn't version patches (and possibly moved to mq?).\nWe should have some scheme for doing meta-history (especially\ninteresting when/if we aim to make altering history easy).\n\n (ix) What about the user survey? It sorta stalled, as far as I can\nsee.\n\n (x) Metainformation over the Git protocol - kernel.org wants this\nbadly because rsyncing the repositories leads to *endless* problems;\nthere are some more complicated rsync schemes possible but hpa would be\nhappiest with making it possible to just use git to sync the\nrepositories out; this might be in part dependent on (iv) since the\nrepository maintainers basically lose control over the packing\n\n (xi) Annotate or blame? Most people seem to be in favour of blome,\nbut having both is confusing; by now one of them should've already won.\n\n (xii) Special merging - I now maintian the SuSE glibc package in git\nand I'd like to use something more sensible than diff3 merger for\nmerging the changelogs from various branches; it's trivially solvable\nconflicts all the time\n\n (xiii) General user interface issues, like confusing error messages,\nincomplete usage help, needlessly complicated (see our git init\ndiscussion in the other thread) or inconsistent usage (git rebase,\nanyone?) in general and other stuff aside of (ii).\n\n That's probably all you'll hear from me for now, I guess. It's your\nturn now.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nSnow falling on Perl. White noise covering line noise.\nHides all the bugs too. -- J. Putnam\n"},{"id":"24003","messageId":"4d8e3fd30607221400j1839883es6c948464cdf22439@mail.gmail.com","threadId":"4950","inReplyTo":"20060722195502.GS13776@pasky.or.cz","subject":"Re: Random Git Issues/Wishlist","fromName":"Paolo Ciarrocchi","fromEmail":"paolo.ciarrocchi@gmail.com","sentAt":"2006-07-22T21:00:47Z","receivedAt":"2006-07-22T21:00:47Z","isPatch":false,"sender":{"key":"paolo.ciarrocchi@gmail.com","avatar":null},"body":"On 7/22/06, Petr Baudis wrote:\n[...]\n> (ix) What about the user survey? It sorta stalled, as far as I can\n> see.\n\nHere it is the latest version:\n\nAbout you\n\n 1. What country are you in?\n 2. What is your preferred language?\n\nGetting started with GIT\n\n 1. How did you hear about GIT?\n 2. Did you find GIT easy to learn?\n 3. What helped you most in learning to use it?\n 4. When did you start using git?\n\nHow you use GIT\n\n 1. Do you use GIT for work, unpaid projects, or both?\n 2. How do you obtain GIT? Source tarball, binary package, or\n pull the main repository?\n 3. What hardware platforms do you use GIT on?\n 4. What OS (please include the version) do you use GIT on?\n 5. How many people do you collaborate with using GIT?\n 6. How big are the repositories that you work on? (e.g. how many\n files, how much disk space, how deep is the history)\n 7. How many different projects do you manage using GIT?\n 8. Which porcelains do you use?\n 9. Is the git.git repository including codes produced by you?\n\nWhat you think of GIT\n\n 1. Overall, how happy are you with GIT?\n 2. How does GIT compare to other SCM tools you have used?\n 3. What do you like about using GIT?\n 4. What would you most like to see improved about GIT?\n (features, bugs, plugins, documentation, ...)\n 5. If you want to see GIT more widely used, what do you\n think we could do to make this happen?\n\nDocumentation\n\n 1. Do you use the GIT wiki? If yes, do you find it useful?\n 2. Do you find GIT's online help useful?\n 3. What is your favourite user documentation for any software\n projects or products you have used?\n 4. What could be improved on the GIT homepage?\n\nGetting help, staying in touch\n\n 1. Have you tried to get GIT help from other people?\n * If yes, did you get these problems resolved quickly and to\n your liking?\n 2. Do you subscribe to the mailing list?\n * If yes, do you find it useful, and traffic levels OK?\n 3. Do you use the IRC channel (#git on irc.freenode.net)?\n\n\nOpen forum\n\n 1. What other comments or suggestions do you have that are not\n covered by the questions above?\n\nSorry for not following closely this topic but unfortunately I had\npersonal problems.\nMartin, can you upload the survey to survey.net.nz as we privately discussed?\n\nIf not, I'll sending out it in the next following days.\n\nThanks.\n\nregards,\n-- \nPaolo\nhttp://paolo.ciarrocchi.googlepages.com\nhttp://picasaweb.google.com/paolo.ciarrocchi\n"},{"id":"24005","messageId":"46a038f90607221712gadae5b3tde2de4653fcc9e69@mail.gmail.com","threadId":"4950","inReplyTo":"4d8e3fd30607221400j1839883es6c948464cdf22439@mail.gmail.com","subject":"Re: Random Git Issues/Wishlist","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2006-07-23T00:12:06Z","receivedAt":"2006-07-23T00:12:06Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"> Martin, can you upload the survey to survey.net.nz as we privately discussed?\n\nDone. this is what it looks like:\n\nhttp://www.survey.net.nz/survey.php?b5659bb2a599d0649871f56b59819c50\n\nI'll send you the login details to modify it. I've changed a few\nthings ever so slightly so it made sense when boiled down to an array\nof radio buttons and text boxes. Survey.net doesn't quite support\n\"section titles\" so I added the section title to the first question of\nthe set, hoping for a \"conversational\" approach to introducing the\nsection to the user.\n\nThe best way to edit it is by downloading the text file, editing in\n$EDITOR and posting it back. the format is trivial, and explained here\nhttp://survey.net.nz/index.php?page=faq under \"Upload Survey\".\n\ncheers,\n\n\n\nmartin\n"},{"id":"24007","messageId":"20060723042725.GA12306@spearce.org","threadId":"4950","inReplyTo":"20060722195502.GS13776@pasky.or.cz","subject":"Re: Random Git Issues/Wishlist","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-07-23T04:27:25Z","receivedAt":"2006-07-23T04:27:25Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Petr Baudis wrote:\n> (iii) Lazy clone, shallow clone, whatever you call it. This has\n> several possible degrees of implementation:\n\nI'd love to work on this, but I just don't have time. :-(\n \n> (vi) Renames - should we follow them in logs? Will we? When? How\n> exactly in the interesting cases?\n\nI thought this has been settled as ``we will not record renames\ndirectly, but instead rely on after-the-fact comparsions to identify\nrenames and copies based on content similarity''.\n\nThe rename identification code in diffcore isn't the fastest, but\nI think someone suggested caching the results of rename comparsions\nunder .git as a way of speeding that up. Unfortunately nobody has\nstepped forward with a reasonable caching implementation, and I\nthink it was also debated that caching is probably not worthwhile\ndue to the high number of permutations people would typically be\nasking for from diffcore.\n \n> (viii) Patches versioning in StGit - many people I've told about StGit\n> complained that it doesn't version patches (and possibly moved to mq?).\n> We should have some scheme for doing meta-history (especially\n> interesting when/if we aim to make altering history easy).\n\nDoesn't StGit now have a single ref for every patch commit?\nWhat about turning on reflog support on those refs and reading the\nreflog for the ``history'' of that patch? Granted the reflog isn't\nprune proof but it is a history of that ref's values over time.\n\nYou can already go back in that history with the @{yesterday}\nsyntax (e.g. \"HEAD@{yesterday}\") anywhere a sha1 expression is\nvalid (e.g. git-log) but StGit doesn't take advantage of it.\n \n> (xii) Special merging - I now maintian the SuSE glibc package in git\n> and I'd like to use something more sensible than diff3 merger for\n> merging the changelogs from various branches; it's trivially solvable\n> conflicts all the time\n\nI've been waiting for the C based recursive merger to get stable\nbefore I take a crack at parameterizing the `merge` invocation.\nI much prefer using patch reject files for conflict resolution,\nbut that's just me. (Besides opening a single patch process and\nshoving a stream of all diffs at it is faster on Cygwin than forking\n30+ merge processes for 30 files with conflicts.)\n\nI take it you are really asking for a way to parameterize the 3 way\nmerge tool on a file-by-file basis, e.g. adding to the config file:\n\n\t[mergetool \"default\"]\n\t\tprogram = merge %real %stage1 %stage3\n\t\treal = stage2\n\n\t[mergetool \"ChangeLog\"]\n\t\tprogram = change-log-merger %stage1 %stage2 %stage3 %real\n\n\t[mergetool \"some/bad/binary-file\"]\n\t\tprogram = cp %stage2 %real\n\nAn issue with storing this data in the config file is what happens\nif the stuff stored at the path \"some/bad/binary-file\" changes such\nthat simply using `cp` (as above) is horribly wrong. Another is how\ndo you pass these \"reasonable defaults\" off to other team members\non a repository-by-repository basis, assuming you all have access\nto the same tools (e.g. the change-log-merger mentioned above).\n\n-- \nShawn.\n"},{"id":"24011","messageId":"4d8e3fd30607230118y29a1f99rc6693d751d1b1f38@mail.gmail.com","threadId":"4950","inReplyTo":"46a038f90607221712gadae5b3tde2de4653fcc9e69@mail.gmail.com","subject":"Re: Random Git Issues/Wishlist","fromName":"Paolo Ciarrocchi","fromEmail":"paolo.ciarrocchi@gmail.com","sentAt":"2006-07-23T08:18:21Z","receivedAt":"2006-07-23T08:18:21Z","isPatch":false,"sender":{"key":"paolo.ciarrocchi@gmail.com","avatar":null},"body":"On 7/23/06, Martin Langhoff wrote:\n> > Martin, can you upload the survey to survey.net.nz as we privately discussed?\n>\n> Done. this is what it looks like:\n>\n> http://www.survey.net.nz/survey.php?b5659bb2a599d0649871f56b59819c50\n>\n> I'll send you the login details to modify it. I've changed a few\n> things ever so slightly so it made sense when boiled down to an array\n> of radio buttons and text boxes. Survey.net doesn't quite support\n> \"section titles\" so I added the section title to the first question of\n> the set, hoping for a \"conversational\" approach to introducing the\n> section to the user.\n>\n> The best way to edit it is by downloading the text file, editing in\n> $EDITOR and posting it back. the format is trivial, and explained here\n> http://survey.net.nz/index.php?page=faq under \"Upload Survey\".\n\nThanks a lot Martin! I will send out an announce in a few minutes.\n\nregards,\n\n-- \nPaolo\nhttp://paolo.ciarrocchi.googlepages.com\nhttp://picasaweb.google.com/paolo.ciarrocchi\n"},{"id":"24058","messageId":"tnxirln5mqy.fsf@arm.com","threadId":"4950","inReplyTo":"20060723042725.GA12306@spearce.org","subject":"Re: Random Git Issues/Wishlist","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@arm.com","sentAt":"2006-07-24T10:19:01Z","receivedAt":"2006-07-24T10:19:01Z","isPatch":false,"sender":{"key":"catalin.marinas@arm.com","avatar":null},"body":"Shawn Pearce wrote:\n> Petr Baudis wrote:\n>> (viii) Patches versioning in StGit - many people I've told about StGit\n>> complained that it doesn't version patches (and possibly moved to mq?).\n>> We should have some scheme for doing meta-history (especially\n>> interesting when/if we aim to make altering history easy).\n>\n> Doesn't StGit now have a single ref for every patch commit?\n\nYes, it does and the history is lost.\n\n> What about turning on reflog support on those refs and reading the\n> reflog for the ``history'' of that patch? Granted the reflog isn't\n> prune proof but it is a history of that ref's values over time.\n\nThat's a good idea indeed (I haven't noticed this feature). Anyway, I\ndon't see any problem with not being prune-safe. I wouldn't want to\npreserve the refresh history of a patch forever. If I have a stable\nseries I want to keep, I either clone it or simply tag it.\n\nI think that people willing to keep the patch history for a number of\nyears (and be prune-safe) should use topic branches rather than\nStGIT. Patches are meant to be more lightweight than topic branches\nand might have a shorter life-time. There were some people at the OLS\nBOF session even mentioning that they don't care about long-term\nhistory.\n\nThe StGIT feature wish-list after the OLS is:\n\n- patch history (I'll probably use reflogs as you suggested)\n- configurable pull command (currently uses git-pull only)\n- commit directly to a patch which is not top\n- patch synchronisation between between branches (as some people,\n including me have the same patches based on different branches and\n they have scripts for moving the changes in one to the others)\n- document the workflow on the StGIT wiki\n- maybe a separate undo command rather than passing a --undo option to\n push and refresh\n\n-- \nCatalin\n"},{"id":"27523","messageId":"20060923231825.GG20017@pasky.or.cz","threadId":"4950","inReplyTo":"tnxirln5mqy.fsf@arm.com","subject":"Re: Random Git Issues/Wishlist","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-09-23T23:18:25Z","receivedAt":"2006-09-23T23:18:25Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":" Mailcromancy for fun'n'profit.\n\nDear diary, on Mon, Jul 24, 2006 at 12:19:01PM CEST, I got a letter\nwhere Catalin Marinas said that...\n> The StGIT feature wish-list after the OLS is:\n> \n> - patch history (I'll probably use reflogs as you suggested)\n> - configurable pull command (currently uses git-pull only)\n> - commit directly to a patch which is not top\n> - patch synchronisation between between branches (as some people,\n> including me have the same patches based on different branches and\n> they have scripts for moving the changes in one to the others)\n> - document the workflow on the StGIT wiki\n> - maybe a separate undo command rather than passing a --undo option to\n> push and refresh\n\n After talking with some more random and less random people, another\n_big_ wishlist item is having something like a series file (not\nnecessarily used for storing stuff but just as a user interface), so\nthat you can easily _reorder_ your patches - that's an onerous task with\nStGIT currently, involving a lot of involved popping and pushing.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i