{"thread":{"id":"18586","subject":"On git 1.6 (novice's opinion)","startedAt":"2009-03-27T07:21:36Z","lastAt":"2009-04-02T02:17:08Z","messageCount":49,"participants":["Ulrich Windl","H.Merijn Brand","Etienne Vallette d'Osia","Dmitry Potapov","Michael J Gruber","Matthieu Moy","Jakub Narebski","Junio C Hamano","demerphq","Bryan Donlan","Johannes Schindelin","Russ Dill","Andreas Ericsson","Kris Shannon","Heiko Voigt"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"109620","messageId":"49CC8C90.12268.242CEFCE@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de","threadId":"18586","inReplyTo":null,"subject":"On git 1.6 (novice's opinion)","fromName":"Ulrich Windl","fromEmail":"ulrich.windl@rz.uni-regensburg.de","sentAt":"2009-03-27T07:21:36Z","receivedAt":"2009-03-27T07:21:36Z","isPatch":false,"sender":{"key":"ulrich.windl@rz.uni-regensburg.de","avatar":null},"body":"Hello everybody,\n\n[About my experience on version control systems: I started out with SCCS in\nthe eighties, and I thought it must be cool as the UNIX guys used it to\nmaintain their sources. Some times later I was using Emacs' numbered backup\nfiles as a poor substiutute for nothing else. Then I came across RCS, and I\nliked it soon ,because it was fully documented and well-written. I even ported\nit to MS-DOS (whew!). I was attaching tags to individual files to mark\n\"releases\" at those times. Then I heard about CVS. It seemed to help with the\ntagging, so I used it for the mopre complex projects. I even did branches and\nmerging with it for the Linux sources. I spontaneously diskliked Bitkeeper,\nbecause it would not work off-line. I heard about Git some time ago, but using\nit seems very non-obvious. After having read the tutorial, and playing some\nsimple scenarios, I must admit that I really like the fully distributed nature\nof it. However some commands seem to be a bit strange (e.g. \"git add\" is\nalmost, but quite a \"commit\" (if you come from CVS)), and sources are quite\ncomplex. Also some seemingly dangerous commands that cannot easily be undone\nshould ask safety questions (\"cvs merge (-j)\" would also fall into that\ncategory.]\n\nWhat I'd like to see in git (My apologies if some were already discussed to \ndeath):\n\n1) The ability to use the file's time at the time of add/commit instead of the\ncurrent time, and the ability tho check outfiles with the times stored in the\nrepository.\n\n2) Keyword substitution. I know it's controverse (dealing with binary files),\nbut I'd like to have some automatic version numbering keyword at least:\nInitial idea is that every commit with a change increments the number by one,\nand when merging numbers a and b, the resulting number is max(a, b) + 1.\n\n3) \"git undo\": If possible undo the effects of the last command.\n\nFollowing are some random remarks from a first-time git user, regarding the \nbuld/install:\n\nNotes on building git-1.6.1.3 on openSUSE 11.0:\nThere is no \"asciidoc\"; the INSTALL should be more verbose on special\nrequirements (i.e. additional packages needed, and where to get them).\nLANG= make configure\n/bin/sh: curl-config: command not found\nmake: `configure' is up to date.\n\nmake[2]: Entering directory `/git/git-1.6.1.3'\nmake[2]: `GIT-VERSION-FILE' is up to date.\nmake[2]: Leaving directory `/git/git-1.6.1.3'\nrm -f git-add.html+ git-add.html\nasciidoc -b xhtml11 -d manpage -f asciidoc.conf \\\n                 -agit_version=1.6.1.3 -o git-add.html+ git-add.txt\nmake[1]: asciidoc: Command not found\nmake[1]: *** [git-add.html] Error 127\nmake[1]: Leaving directory `/git/git-1.6.1.3/Documentation'\nmake: *** [doc] Error 2\n\nSome parts of the make process may look like an error if they pass by quickly:\n\n[...]\n    GEN git-request-pull\n    GEN git-sh-setup\n    GEN git-stash\n    GEN git-submodule\n    GEN git-web--browse\n    SUBDIR perl\n/usr/bin/perl Makefile.PL PREFIX='/home/windl/Projects/git/inst'\nWriting perl.mak for Git\n    GEN git-add--interactive\n    GEN git-archimport\n    GEN git-cvsexportcommit\n    GEN git-cvsimport\n[...]\n\nSame is true for the install process:\nmake[1]: Leaving directory `/home/windl/Projects/git/git-1.6.1.3/git-gui'\nbindir=$(cd '/home/windl/Projects/git/inst/bin' && pwd) && \\\n        execdir=$(cd '/home/windl/Projects/git/inst/libexec/git-core/' && pwd) && \n\\\n        { rm -f \"$execdir/git-add\" && \\\n                ln git-add \"$execdir/git-add\" 2>/dev/null || \\\n                cp git-add \"$execdir/git-add\"; } && \\\n        {  rm -f \"$execdir/git-annotate\" && ln \"$execdir/git-add\" \"$execdir/git-\nannotate\" 2>/dev/null || ln -s \"git-add\" \"$execdir/git-annotate\" 2>/dev/null || cp \n\"$execdir/git-add\" \"$execdir/git-annotate\" || exit;  rm -f \"$execdir/git-apply\" && \nln \"$execdir/git-add\" \"$execdir/git-apply\" 2>/dev/null || ln -s \"git-add\" \n\"$execdir/git-apply\" 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-apply\" || \nexit;  rm -f \"$execdir/git-archive\" && ln \"$execdir/git-add\" \"$execdir/git-\narchive\" 2>/dev/null || ln -s \"git-add\" \"$execdir/git-archive\" 2>/dev/null || cp \n\"$execdir/git-add\" \"$execdir/git-archive\" || exit;  rm -f \"$execdir/git-blame\" && \nln \"$execdir/git-add\" \"$execdir/git-blame\" 2>/dev/null || ln -s \"git-add\" \n\"$execdir/git-blame\" 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-blame\" || \nexit;  rm -f \"$execdir/git-branch\" && ln \"$execdir/git-add\" \"$execdir/git-branch\" \n2>/dev/null || ln -s \"git-add\" \"$execdir/git-branch\" 2>/dev/null || cp \n\"$execdir/git-add\" \"$execdir/git-branch\" || exit;  rm -f \"$execdir/git-bundle\" && \nln \"$execdir/git-add\" \"$execdir/git-bundle\" 2>/dev/null || ln -s \"git-add\" \n\"$execdir/git-bundle\" 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-bundle\" \n|| exit;  rm -f \"$execdir/git-cat-file\" && ln \"$execdir/git-add\" \"$execdir/git-\ncat-file\" 2>/dev/null || ln -s \"git-add\" \"$execdir/git-cat-file\" 2>/dev/null || cp \n\"$execdir/git-add\" \"$execdir/git-cat-file\" || exit;  rm -f \"$execdir/git-check-\nattr\" && ln \"$execdir/git-add\" \"$execdir/git-check-attr\" 2>/dev/null || ln -s \n\"git-add\" \"$execdir/git-check-attr\" 2>/dev/null || cp \"$execdir/git-add\" \n\"$execdir/git-check-attr\" || exit;  rm -f \"$execdir/git-check-ref-format\" && ln \n\"$execdir/git-add\" \"$execdir/git-check-ref-format\" 2>/dev/null || ln -s \"git-add\" \n\"$execdir/git-check-ref-format\" 2>/dev/null || cp \"$execdir/git-add\" \n\"$execdir/git-check-ref-format\" || exit;  rm -f \"$execdir/git-checkout-index\" && \nln \"$execdir/git-add\" \"$execdir/git-checkout-index\" 2>/dev/null || ln -s \"git-add\" \n\"$execdir/git-checkout-index\" 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-\ncheckout-index\" || exit;  rm -f \"$execdir/git-checkout\" && ln \"$execdir/git-add\" \n\"$execdir/git-checkout\" 2>/dev/null || ln -s \"git-add\" \"$execdir/git-checkout\" \n2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-checkout\" || exit;  rm -f \n\"$execdir/git-clean\" && ln \"$execdir/git-add\" \"$execdir/git-clean\" 2>/dev/null || \nln -s \"git-add\" \"$execdir/git-clean\" 2>/dev/null || cp \"$execdir/git-add\" \n\"$execdir/git-clean\" || exit;  rm -f \"$execdir/git-clone\" && ln \"$execdir/git-add\" \n\"$execdir/git-clone\" 2>/dev/null || ln -s \"git-add\" \"$execdir/git-clone\" \n2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-clone\" || exit;  rm -f \n\"$execdir/git-commit-tree\" && ln \"$execdir/git-add\" \"$execdir/git-commit-tree\" \n2>/dev/null || ln -s \"git-add\" \"$execdir/git-commit-tree\" 2>/dev/null || cp \n\"$execdir/git-add\" \"$execdir/git-commit-tree\" || exit;  rm -f \"$execdir/git-\ncommit\" && ln \"$execdir/git-add\" \"$execdir/git-commit\" 2>/dev/null || ln -s \"git-\nadd\" \"$execdir/git-commit\" 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-\ncommit\" || exit;  rm -f \"$execdir/git-config\" && ln \"$execdir/git-add\" \n\"$execdir/git-config\" 2>/dev/null || ln -s \"git-add\" \"$execdir/git-config\" \n2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-config\" || exit;  rm -f \n\"$execdir/git-count-objects\" && ln \"$execdir/git-add\" \"$execdir/git-count-objects\" \n2>/dev/null || ln -s \"git-add\" \"$execdir/git-count-objects\" 2>/dev/null || cp \n\"$execdir/git-add\" \"$execdir/git-count-objects\" || exit;  rm -f \"$execdir/git-\ndescribe\" && ln \"$execdir/git-add\" \"$execdir/git-describe\" 2>/dev/null || ln -s \n\"git-add\" \"$execdir/git-describe\" 2>/dev/null || cp \"$execdir/git-add\" \n\"$execdir/git-describe\" || exit;  rm -f \"$execdir/git-diff-files\" && ln \n\"$execdir/git-add\" \"$execdir/git-diff-files\" 2>/dev/null || ln -s \"git-add\" \n\"$execdir/git-diff-files\" 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-diff-\nfiles\" || exit;  rm -f \"$execdir/git-diff-index\" && ln \"$execdir/git-add\" \n\"$execdir/git-diff-index\" 2>/dev/null || ln -s \"git-add\" \"$execdir/git-diff-index\" \n2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-diff-index\" || exit;  rm -f \n\"$execdir/git-diff-tree\" && ln \"$execdir/git-add\" \"$execdir/git-diff-tree\" \n2>/dev/null || ln -s \"git-add\" \"$execdir/git-diff-tree\" 2>/dev/null || cp \n\"$execdir/git-add\" \"$execdir/git-diff-tree\" || exit;  rm -f \"$execdir/git-diff\" && \nln \"$execdir/git-add\" \"$execdir/git-diff\" 2>/dev/null || ln -s \"git-add\" \n\"$execdir/git-diff\" 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-diff\" || \nexit;  rm -f \"$execdir/git-fast-export\" && ln \"$execdir/git-add\" \"$execdir/git-\nfast-export\" 2>/dev/null || ln -s \"git-add\" \"$execdir/git-fast-export\" 2>/dev/null \n|| cp \"$execdir/git-add\" \"$execdir/git-fast-export\" || exit;  rm -f \"$execdir/git-\nfetch--tool\" && ln \"$execdir/git-add\" \"$execdir/git-fetch--tool\" 2>/dev/null || ln \n-s \"git-add\" \"$execdir/git-fetch--tool\" 2>/dev/null || cp \"$execdir/git-add\" \n\"$execdir/git-fetch--tool\" || exit;  rm -f \"$execdir/git-fetch-pack\" && ln \n\"$execdir/git-add\" \"$execdir/git-fetch-pack\" 2>/dev/null || ln -s \"git-add\" \n\"$execdir/git-fetch-pack\" 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-\nfetch-pack\" || exit;  rm -f \"$execdir/git-fetch\" && ln \"$execdir/git-add\" \n\"$execdir/git-fetch\" 2>/dev/null || ln -s \"git-add\" \"$execdir/git-fetch\" \n2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-fetch\" || exit;  rm -f \n\"$execdir/git-fmt-merge-msg\" && ln \"$execdir/git-add\" \"$execdir/git-fmt-merge-msg\" \n2>/dev/null || ln -s \"git-add\" \"$execdir/git-fmt-merge-msg\" 2>/dev/null || cp \n\"$execdir/git-add\" \"$execdir/git-fmt-merge-msg\" || exit;  rm -f \"$execdir/git-for-\neach-ref\" && ln \"$execdir/git-add\" \"$execdir/git-for-each-ref\" 2>/dev/null || ln -\ns \"git-add\" \"$execdir/git-for-each-ref\" 2>/dev/null || cp \"$execdir/git-add\" \n\"$execdir/git-for-each-ref\" || exit;  rm -f \"$execdir/git-fsck\" && ln \n\"$execdir/git-add\" \"$execdir/git-fsck\" 2>/dev/null || ln -s \"git-add\" \n\"$execdir/git-fsck\" 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-fsck\" || \nexit;  rm -f \"$execdir/git-gc\" && ln \"$execdir/git-add\" \"$execdir/git-gc\" \n2>/dev/null || ln -s \"git-add\" \"$execdir/git-gc\" 2>/dev/null || cp \"$execdir/git-\nadd\" \"$execdir/git-gc\" || exit;  rm -f \"$execdir/git-grep\" && ln \"$execdir/git-\nadd\" \"$execdir/git-grep\" 2>/dev/null || ln -s \"git-add\" \"$execdir/git-grep\" \n2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-grep\" || exit;  rm -f \n\"$execdir/git-help\" && ln \"$execdir/git-add\" \"$execdir/git-help\" 2>/dev/null || ln \n-s \"git-add\" \"$execdir/git-help\" 2>/dev/null || cp \"$execdir/git-add\" \n\"$execdir/git-help\" || exit;  rm -f \"$execdir/git-init-db\" && ln \"$execdir/git-\nadd\" \"$execdir/git-init-db\" 2>/dev/null || ln -s \"git-add\" \"$execdir/git-init-db\" \n2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-init-db\" || exit;  rm -f \n\"$execdir/git-log\" && ln \"$execdir/git-add\" \"$execdir/git-log\" 2>/dev/null || ln -\ns \"git-add\" \"$execdir/git-log\" 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-\nlog\" || exit;  rm -f \"$execdir/git-ls-files\" && ln \"$execdir/git-add\" \n\"$execdir/git-ls-files\" 2>/dev/null || ln -s \"git-add\" \"$execdir/git-ls-files\" \n2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-ls-files\" || exit;  rm -f \n\"$execdir/git-ls-remote\" && ln \"$execdir/git-add\" \"$execdir/git-ls-remote\" \n2>/dev/null || ln -s \"git-add\" \"$execdir/git-ls-remote\" 2>/dev/null || cp \n\"$execdir/git-add\" \"$execdir/git-ls-remote\" || exit;  rm -f \"$execdir/git-ls-tree\" \n&& ln \"$execdir/git-add\" \"$execdir/git-ls-tree\" 2>/dev/null || ln -s \"git-add\" \n\"$execdir/git-ls-tree\" 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-ls-tree\" \n|| exit;  rm -f \"$execdir/git-mailinfo\" && ln \"$execdir/git-add\" \"$execdir/git-\nmailinfo\" 2>/dev/null || ln -s \"git-add\" \"$execdir/git-mailinfo\" 2>/dev/null || cp \n\"$execdir/git-add\" \"$execdir/git-mailinfo\" || exit;  rm -f \"$execdir/git-\nmailsplit\" && ln \"$execdir/git-add\" \"$execdir/git-mailsplit\" 2>/dev/null || ln -s \n\"git-add\" \"$execdir/git-mailsplit\" 2>/dev/null || cp \"$execdir/git-add\" \n\"$execdir/git-mailsplit\" || exit;  rm -f \"$execdir/git-merge\" && ln \"$execdir/git-\nadd\" \"$execdir/git-merge\" 2>/dev/null || ln -s \"git-add\" \"$execdir/git-merge\" \n2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-merge\" || exit;  rm -f \n\"$execdir/git-merge-base\" && ln \"$execdir/git-add\" \"$execdir/git-merge-base\" \n2>/dev/null || ln -s \"git-add\" \"$execdir/git-merge-base\" 2>/dev/null || cp \n\"$execdir/git-add\" \"$execdir/git-merge-base\" || exit;  rm -f \"$execdir/git-merge-\nfile\" && ln \"$execdir/git-add\" \"$execdir/git-merge-file\" 2>/dev/null || ln -s \n\"git-add\" \"$execdir/git-merge-file\" 2>/dev/null || cp \"$execdir/git-add\" \n\"$execdir/git-merge-file\" || exit;  rm -f \"$execdir/git-merge-ours\" && ln \n\"$execdir/git-add\" \"$execdir/git-merge-ours\" 2>/dev/null || ln -s \"git-add\" \n\"$execdir/git-merge-ours\" 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-\nmerge-ours\" || exit;  rm -f \"$execdir/git-merge-recursive\" && ln \"$execdir/git-\nadd\" \"$execdir/git-merge-recursive\" 2>/dev/null || ln -s \"git-add\" \"$execdir/git-\nmerge-recursive\" 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-merge-\nrecursive\" || exit;  rm -f \"$execdir/git-mv\" && ln \"$execdir/git-add\" \n\"$execdir/git-mv\" 2>/dev/null || ln -s \"git-add\" \"$execdir/git-mv\" 2>/dev/null || \ncp \"$execdir/git-add\" \"$execdir/git-mv\" || exit;  rm -f \"$execdir/git-name-rev\" && \nln \"$execdir/git-add\" \"$execdir/git-name-rev\" 2>/dev/null || ln -s \"git-add\" \n\"$execdir/git-name-rev\" 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-name-\nrev\" || exit;  rm -f \"$execdir/git-pack-objects\" && ln \"$execdir/git-add\" \n\"$execdir/git-pack-objects\" 2>/dev/null || ln -s \"git-add\" \"$execdir/git-pack-\nobjects\" 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-pack-objects\" || exit;  \nrm -f \"$execdir/git-pack-refs\" && ln \"$execdir/git-add\" \"$execdir/git-pack-refs\" \n2>/dev/null || ln -s \"git-add\" \"$execdir/git-pack-refs\" 2>/dev/null || cp \n\"$execdir/git-add\" \"$execdir/git-pack-refs\" || exit;  rm -f \"$execdir/git-prune-\npacked\" && ln \"$execdir/git-add\" \"$execdir/git-prune-packed\" 2>/dev/null || ln -s \n\"git-add\" \"$execdir/git-prune-packed\" 2>/dev/null || cp \"$execdir/git-add\" \n\"$execdir/git-prune-packed\" || exit;  rm -f \"$execdir/git-prune\" && ln \n\"$execdir/git-add\" \"$execdir/git-prune\" 2>/dev/null || ln -s \"git-add\" \n\"$execdir/git-prune\" 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-prune\" || \nexit;  rm -f \"$execdir/git-push\" && ln \"$execdir/git-add\" \"$execdir/git-push\" \n2>/dev/null || ln -s \"git-add\" \"$execdir/git-push\" 2>/dev/null || cp \n\"$execdir/git-add\" \"$execdir/git-push\" || exit;  rm -f \"$execdir/git-read-tree\" && \nln \"$execdir/git-add\" \"$execdir/git-read-tree\" 2>/dev/null || ln -s \"git-add\" \n\"$execdir/git-read-tree\" 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-read-\ntree\" || exit;  rm -f \"$execdir/git-receive-pack\" && ln \"$execdir/git-add\" \n\"$execdir/git-receive-pack\" 2>/dev/null || ln -s \"git-add\" \"$execdir/git-receive-\npack\" 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-receive-pack\" || exit;  \nrm -f \"$execdir/git-reflog\" && ln \"$execdir/git-add\" \"$execdir/git-reflog\" \n2>/dev/null || ln -s \"git-add\" \"$execdir/git-reflog\" 2>/dev/null || cp \n\"$execdir/git-add\" \"$execdir/git-reflog\" || exit;  rm -f \"$execdir/git-remote\" && \nln \"$execdir/git-add\" \"$execdir/git-remote\" 2>/dev/null || ln -s \"git-add\" \n\"$execdir/git-remote\" 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-remote\" \n|| exit;  rm -f \"$execdir/git-rerere\" && ln \"$execdir/git-add\" \"$execdir/git-\nrerere\" 2>/dev/null || ln -s \"git-add\" \"$execdir/git-rerere\" 2>/dev/null || cp \n\"$execdir/git-add\" \"$execdir/git-rerere\" || exit;  rm -f \"$execdir/git-reset\" && \nln \"$execdir/git-add\" \"$execdir/git-reset\" 2>/dev/null || ln -s \"git-add\" \n\"$execdir/git-reset\" 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-reset\" || \nexit;  rm -f \"$execdir/git-rev-list\" && ln \"$execdir/git-add\" \"$execdir/git-rev-\nlist\" 2>/dev/null || ln -s \"git-add\" \"$execdir/git-rev-list\" 2>/dev/null || cp \n\"$execdir/git-add\" \"$execdir/git-rev-list\" || exit;  rm -f \"$execdir/git-rev-\nparse\" && ln \"$execdir/git-add\" \"$execdir/git-rev-parse\" 2>/dev/null || ln -s \n\"git-add\" \"$execdir/git-rev-parse\" 2>/dev/null || cp \"$execdir/git-add\" \n\"$execdir/git-rev-parse\" || exit;  rm -f \"$execdir/git-revert\" && ln \n\"$execdir/git-add\" \"$execdir/git-revert\" 2>/dev/null || ln -s \"git-add\" \n\"$execdir/git-revert\" 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-revert\" \n|| exit;  rm -f \"$execdir/git-rm\" && ln \"$execdir/git-add\" \"$execdir/git-rm\" \n2>/dev/null || ln -s \"git-add\" \"$execdir/git-rm\" 2>/dev/null || cp \"$execdir/git-\nadd\" \"$execdir/git-rm\" || exit;  rm -f \"$execdir/git-send-pack\" && ln \n\"$execdir/git-add\" \"$execdir/git-send-pack\" 2>/dev/null || ln -s \"git-add\" \n\"$execdir/git-send-pack\" 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-send-\npack\" || exit;  rm -f \"$execdir/git-shortlog\" && ln \"$execdir/git-add\" \n\"$execdir/git-shortlog\" 2>/dev/null || ln -s \"git-add\" \"$execdir/git-shortlog\" \n2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-shortlog\" || exit;  rm -f \n\"$execdir/git-show-branch\" && ln \"$execdir/git-add\" \"$execdir/git-show-branch\" \n2>/dev/null || ln -s \"git-add\" \"$execdir/git-show-branch\" 2>/dev/null || cp \n\"$execdir/git-add\" \"$execdir/git-show-branch\" || exit;  rm -f \"$execdir/git-show-\nref\" && ln \"$execdir/git-add\" \"$execdir/git-show-ref\" 2>/dev/null || ln -s \"git-\nadd\" \"$execdir/git-show-ref\" 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-\nshow-ref\" || exit;  rm -f \"$execdir/git-stripspace\" && ln \"$execdir/git-add\" \n\"$execdir/git-stripspace\" 2>/dev/null || ln -s \"git-add\" \"$execdir/git-stripspace\" \n2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-stripspace\" || exit;  rm -f \n\"$execdir/git-symbolic-ref\" && ln \"$execdir/git-add\" \"$execdir/git-symbolic-ref\" \n2>/dev/null || ln -s \"git-add\" \"$execdir/git-symbolic-ref\" 2>/dev/null || cp \n\"$execdir/git-add\" \"$execdir/git-symbolic-ref\" || exit;  rm -f \"$execdir/git-tag\" \n&& ln \"$execdir/git-add\" \"$execdir/git-tag\" 2>/dev/null || ln -s \"git-add\" \n\"$execdir/git-tag\" 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-tag\" || \nexit;  rm -f \"$execdir/git-tar-tree\" && ln \"$execdir/git-add\" \"$execdir/git-tar-\ntree\" 2>/dev/null || ln -s \"git-add\" \"$execdir/git-tar-tree\" 2>/dev/null || cp \n\"$execdir/git-add\" \"$execdir/git-tar-tree\" || exit;  rm -f \"$execdir/git-unpack-\nobjects\" && ln \"$execdir/git-add\" \"$execdir/git-unpack-objects\" 2>/dev/null || ln \n-s \"git-add\" \"$execdir/git-unpack-objects\" 2>/dev/null || cp \"$execdir/git-add\" \n\"$execdir/git-unpack-objects\" || exit;  rm -f \"$execdir/git-update-index\" && ln \n\"$execdir/git-add\" \"$execdir/git-update-index\" 2>/dev/null || ln -s \"git-add\" \n\"$execdir/git-update-index\" 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-\nupdate-index\" || exit;  rm -f \"$execdir/git-update-ref\" && ln \"$execdir/git-add\" \n\"$execdir/git-update-ref\" 2>/dev/null || ln -s \"git-add\" \"$execdir/git-update-ref\" \n2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-update-ref\" || exit;  rm -f \n\"$execdir/git-upload-archive\" && ln \"$execdir/git-add\" \"$execdir/git-upload-\narchive\" 2>/dev/null || ln -s \"git-add\" \"$execdir/git-upload-archive\" 2>/dev/null \n|| cp \"$execdir/git-add\" \"$execdir/git-upload-archive\" || exit;  rm -f \n\"$execdir/git-verify-pack\" && ln \"$execdir/git-add\" \"$execdir/git-verify-pack\" \n2>/dev/null || ln -s \"git-add\" \"$execdir/git-verify-pack\" 2>/dev/null || cp \n\"$execdir/git-add\" \"$execdir/git-verify-pack\" || exit;  rm -f \"$execdir/git-\nverify-tag\" && ln \"$execdir/git-add\" \"$execdir/git-verify-tag\" 2>/dev/null || ln -\ns \"git-add\" \"$execdir/git-verify-tag\" 2>/dev/null || cp \"$execdir/git-add\" \n\"$execdir/git-verify-tag\" || exit;  rm -f \"$execdir/git-write-tree\" && ln \n\"$execdir/git-add\" \"$execdir/git-write-tree\" 2>/dev/null || ln -s \"git-add\" \n\"$execdir/git-write-tree\" 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-\nwrite-tree\" || exit;  rm -f \"$execdir/git-cherry-pick\" && ln \"$execdir/git-add\" \n\"$execdir/git-cherry-pick\" 2>/dev/null || ln -s \"git-add\" \"$execdir/git-cherry-\npick\" 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-cherry-pick\" || exit;  rm \n-f \"$execdir/git-cherry\" && ln \"$execdir/git-add\" \"$execdir/git-cherry\" \n2>/dev/null || ln -s \"git-add\" \"$execdir/git-cherry\" 2>/dev/null || cp \n\"$execdir/git-add\" \"$execdir/git-cherry\" || exit;  rm -f \"$execdir/git-format-\npatch\" && ln \"$execdir/git-add\" \"$execdir/git-format-patch\" 2>/dev/null || ln -s \n\"git-add\" \"$execdir/git-format-patch\" 2>/dev/null || cp \"$execdir/git-add\" \n\"$execdir/git-format-patch\" || exit;  rm -f \"$execdir/git-fsck-objects\" && ln \n\"$execdir/git-add\" \"$execdir/git-fsck-objects\" 2>/dev/null || ln -s \"git-add\" \n\"$execdir/git-fsck-objects\" 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-\nfsck-objects\" || exit;  rm -f \"$execdir/git-get-tar-commit-id\" && ln \n\"$execdir/git-add\" \"$execdir/git-get-tar-commit-id\" 2>/dev/null || ln -s \"git-add\" \n\"$execdir/git-get-tar-commit-id\" 2>/dev/null || cp \"$execdir/git-add\" \n\"$execdir/git-get-tar-commit-id\" || exit;  rm -f \"$execdir/git-init\" && ln \n\"$execdir/git-add\" \"$execdir/git-init\" 2>/dev/null || ln -s \"git-add\" \n\"$execdir/git-init\" 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-init\" || \nexit;  rm -f \"$execdir/git-merge-subtree\" && ln \"$execdir/git-add\" \"$execdir/git-\nmerge-subtree\" 2>/dev/null || ln -s \"git-add\" \"$execdir/git-merge-subtree\" \n2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-merge-subtree\" || exit;  rm -f \n\"$execdir/git-peek-remote\" && ln \"$execdir/git-add\" \"$execdir/git-peek-remote\" \n2>/dev/null || ln -s \"git-add\" \"$execdir/git-peek-remote\" 2>/dev/null || cp \n\"$execdir/git-add\" \"$execdir/git-peek-remote\" || exit;  rm -f \"$execdir/git-repo-\nconfig\" && ln \"$execdir/git-add\" \"$execdir/git-repo-config\" 2>/dev/null || ln -s \n\"git-add\" \"$execdir/git-repo-config\" 2>/dev/null || cp \"$execdir/git-add\" \n\"$execdir/git-repo-config\" || exit;  rm -f \"$execdir/git-show\" && ln \n\"$execdir/git-add\" \"$execdir/git-show\" 2>/dev/null || ln -s \"git-add\" \n\"$execdir/git-show\" 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-show\" || \nexit;  rm -f \"$execdir/git-stage\" && ln \"$execdir/git-add\" \"$execdir/git-stage\" \n2>/dev/null || ln -s \"git-add\" \"$execdir/git-stage\" 2>/dev/null || cp \n\"$execdir/git-add\" \"$execdir/git-stage\" || exit;  rm -f \"$execdir/git-status\" && \nln \"$execdir/git-add\" \"$execdir/git-status\" 2>/dev/null || ln -s \"git-add\" \n\"$execdir/git-status\" 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-status\" \n|| exit;  rm -f \"$execdir/git-whatchanged\" && ln \"$execdir/git-add\" \"$execdir/git-\nwhatchanged\" 2>/dev/null || ln -s \"git-add\" \"$execdir/git-whatchanged\" 2>/dev/null \n|| cp \"$execdir/git-add\" \"$execdir/git-whatchanged\" || exit; } && \\\n        ./check_bindir \"z$bindir\" \"z$execdir\" \"$bindir/git-add\"\n\nThere's a problem with \"make quick-install-man\":\nLANG= make quick-install-man\nmake -C Documentation quick-install-man\nmake[1]: Entering directory `/git/git-1.6.1.3/Documentation'\nmake -C ../ GIT-VERSION-FILE\nmake[2]: Entering directory `/git/git-1.6.1.3'\nmake[2]: `GIT-VERSION-FILE' is up to date.\nmake[2]: Leaving directory `/git/git-1.6.1.3'\nsh ./install-doc-quick.sh origin/man /git/inst/share/man\n./install-doc-quick.sh: line 9: /git/inst/libexec/git-sh-setup: No such file or \ndirectory\nmake[1]: *** [quick-install-man] Error 1\nmake[1]: Leaving directory `/git/git-1.6.1.3/Documentation'\nmake: *** [quick-install-man] Error 2\n\nRegards,\nUlrich Windl\n"},{"id":"109624","messageId":"20090327090554.5d6160f2@pc09.procura.nl","threadId":"18586","inReplyTo":"49CC8C90.12268.242CEFCE@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de","subject":"Re: On git 1.6 (novice's opinion)","fromName":"H.Merijn Brand","fromEmail":"h.m.brand@xs4all.nl","sentAt":"2009-03-27T08:05:54Z","receivedAt":"2009-03-27T08:05:54Z","isPatch":false,"sender":{"key":"h.m.brand@xs4all.nl","avatar":"https://gravatar.com/avatar/5b8f83ee35c427a646cbea3b104346e00ab3663b99bbf435cddeb75cd4b3857b?d=mp&s=160"},"body":"On Fri, 27 Mar 2009 08:21:36 +0100, \"Ulrich Windl\"\n<ulrich.windl@rz.uni-regensburg.de> wrote:\n\n> What I'd like to see in git (My apologies if some were already discussed to \n> death):\n> \n> 1) The ability to use the file's time at the time of add/commit instead of\n>    the current time, and the ability tho check outfiles with the times stored\n>    in the repository.\n> \n> 2) Keyword substitution. I know it's controverse (dealing with binary files),\n>    but I'd like to have some automatic version numbering keyword at least:\n>    Initial idea is that every commit with a change increments the number by\n>    one, and when merging numbers a and b, the resulting number is max(a, b) + 1.\n\nimpossible. Even with checkin- and checkout hooks, you won't get that\nSCCS behaviour. They have to be better in something too :)\n/me still misses that but got used to it\n\n> 3) \"git undo\": If possible undo the effects of the last command.\n> \n> Following are some random remarks from a first-time git user, regarding the \n> buld/install:\n> \n> Notes on building git-1.6.1.3 on openSUSE 11.0:\n> There is no \"asciidoc\"; the INSTALL should be more verbose on special\n> requirements (i.e. additional packages needed, and where to get them).\n\n# zypper in asciidoc libcurl-devel\n\n(yes, 'make install-man' should stop soon after detecting asciidoc is\nnot installed\n\n\n-- \nH.Merijn Brand  http://tux.nl      Perl Monger  http://amsterdam.pm.org/\nusing & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00,\n11.11, 11.23, and 11.31, SuSE 10.3, 11.0, and 11.1, AIX 5.2, and Cygwin.\nhttp://mirrors.develooper.com/hpux/           http://www.test-smoke.org/\nhttp://qa.perl.org      http://www.goldmark.org/jeff/stupid-disclaimers/\n"},{"id":"109627","messageId":"49CCAF5D.21814.24B4DE63@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de","threadId":"18586","inReplyTo":"20090327090554.5d6160f2@pc09.procura.nl","subject":"Re: On git 1.6 (novice's opinion)","fromName":"Ulrich Windl","fromEmail":"ulrich.windl@rz.uni-regensburg.de","sentAt":"2009-03-27T09:50:04Z","receivedAt":"2009-03-27T09:50:04Z","isPatch":false,"sender":{"key":"ulrich.windl@rz.uni-regensburg.de","avatar":null},"body":"On 27 Mar 2009 at 9:05, H.Merijn Brand wrote:\n\n> On Fri, 27 Mar 2009 08:21:36 +0100, \"Ulrich Windl\"\n> <ulrich.windl@rz.uni-regensburg.de> wrote:\n> \n> > What I'd like to see in git (My apologies if some were already discussed to \n> > death):\n> > \n> > 1) The ability to use the file's time at the time of add/commit instead of\n> >    the current time, and the ability tho check outfiles with the times stored\n> >    in the repository.\n> > \n> > 2) Keyword substitution. I know it's controverse (dealing with binary files),\n> >    but I'd like to have some automatic version numbering keyword at least:\n> >    Initial idea is that every commit with a change increments the number by\n> >    one, and when merging numbers a and b, the resulting number is max(a, b) + 1.\n> \n> impossible. Even with checkin- and checkout hooks, you won't get that\n> SCCS behaviour. They have to be better in something too :)\n> /me still misses that but got used to it\n\nHi,\n\nwhat made me wonder is this (about item 1): I thought I've read that blobs store \ncontent and attributes, so very obviously I wondered why not store thr \"right \nattributes\" (i.e. the time of the file). My reasoning: You make some changes, then \ntest them (which might last several hours or days). The if I'm happy I'll \n\"commit\". Naturally I want to see the time of change for each file when the change \nhad been actually made, not when the change was committed. Likewise when checking \nout, I want to be able to see the time of modification, not the time of commit. \nI'm aware that many people don't care about such differences...\n\n> \n> > 3) \"git undo\": If possible undo the effects of the last command.\n\nIf impossible, add confirmations for some \"dangerous\" (non-obvious) commands \nbefore doing possibly harmful things. Maybe adding a kind of \"user-level setting\" \n(novice, expert, guro) could control such confirmations.\n\n> > \n> > Following are some random remarks from a first-time git user, regarding the \n> > buld/install:\n> > \n> > Notes on building git-1.6.1.3 on openSUSE 11.0:\n> > There is no \"asciidoc\"; the INSTALL should be more verbose on special\n> > requirements (i.e. additional packages needed, and where to get them).\n> \n> # zypper in asciidoc libcurl-devel\n\n\"asciidoc\" doesn't seem a popular package on some distributions; mine lacks it...\n> \n> (yes, 'make install-man' should stop soon after detecting asciidoc is\n> not installed\n\nRegards,\nUlrich\n"},{"id":"109631","messageId":"49CCB129.1070606@gmail.com","threadId":"18586","inReplyTo":"49CCAF5D.21814.24B4DE63@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de","subject":"Re: On git 1.6 (novice's opinion)","fromName":"Etienne Vallette d'Osia","fromEmail":"etienne.vallettedosia@gmail.com","sentAt":"2009-03-27T10:57:45Z","receivedAt":"2009-03-27T10:57:45Z","isPatch":false,"sender":{"key":"etienne.vallettedosia@gmail.com","avatar":null},"body":"Ulrich Windl a écrit :\n>>> 3) \"git undo\": If possible undo the effects of the last command.\n> \n> If impossible, add confirmations for some \"dangerous\" (non-obvious) commands \n> before doing possibly harmful things. Maybe adding a kind of \"user-level setting\" \n> (novice, expert, guro) could control such confirmations.\n> \nWhy ?\nAll objects stored are immutable, and some tools keep informations \n(ORIGIN_HEAD, refs/original) to allow a undo hand-made.\nMoreover the reflog (and stash if you want to use it for this use) store \n  informations during time...\n\nSo it's possible to provide a generic undo for all commands that change \nrefs.\n\nMaybe an \"undo\" directory in $GIT_DIR, which will a keep a copy version \nof all refs. Every commands store the current refs in this folder _before_\nto change anything, and the undo restore them all.\nAt least, a \"lastcmd\" (for example) file could be added in this \ndirectory to allow an more clever undo.\n"},{"id":"109634","messageId":"49CCB8D8.2040603@gmail.com","threadId":"18586","inReplyTo":"49CCB129.1070606@gmail.com","subject":"Re: On git 1.6 (novice's opinion)","fromName":"Etienne Vallette d'Osia","fromEmail":"dohzya@gmail.com","sentAt":"2009-03-27T11:30:32Z","receivedAt":"2009-03-27T11:30:32Z","isPatch":false,"sender":{"key":"dohzya@gmail.com","avatar":"https://gravatar.com/avatar/2ec58d74d930356327523e6b5fe992a0a9b2d2748b733ba63a9d1298798853c3?d=mp&s=160"},"body":"Etienne Vallette d'Osia a écrit :\n> Ulrich Windl a écrit :\n>>>> 3) \"git undo\": If possible undo the effects of the last command.\n>>\n>> If impossible, add confirmations for some \"dangerous\" (non-obvious) \n>> commands before doing possibly harmful things. Maybe adding a kind of \n>> \"user-level setting\" (novice, expert, guro) could control such \n>> confirmations.\n>>\n> Why ?\nOops, I have readed \"it is impossible\"\n"},{"id":"109635","messageId":"37fcd2780903270524x1987a622wb9e693be41fc02c4@mail.gmail.com","threadId":"18586","inReplyTo":"49CC8C90.12268.242CEFCE@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de","subject":"Re: On git 1.6 (novice's opinion)","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2009-03-27T12:24:02Z","receivedAt":"2009-03-27T12:24:02Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Fri, Mar 27, 2009 at 10:21 AM, Ulrich Windl\n<ulrich.windl@rz.uni-regensburg.de> wrote:\n>\n> 1) The ability to use the file's time at the time of add/commit instead of the\n> current time, and the ability tho check outfiles with the times stored in the\n> repository.\n\nTo check out with the times stored in repository is a a bad idea, because it\nwill screw up 'make'.\n\n>\n> 2) Keyword substitution. I know it's controverse (dealing with binary files),\n> but I'd like to have some automatic version numbering keyword at least:\n> Initial idea is that every commit with a change increments the number by one,\n> and when merging numbers a and b, the resulting number is max(a, b) + 1.\n\nI am not sure what you want to achieve by having this number. Also, take\na look at \"git describe\", it may be close to what you want (or may be not).\n\n\nDmitry\n"},{"id":"109636","messageId":"37fcd2780903270524y39456c5fre0a2f8f9c5f4d160@mail.gmail.com","threadId":"18586","inReplyTo":"49CCAF5D.21814.24B4DE63@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de","subject":"Re: On git 1.6 (novice's opinion)","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2009-03-27T12:24:37Z","receivedAt":"2009-03-27T12:24:37Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Fri, Mar 27, 2009 at 12:50 PM, Ulrich Windl\n<ulrich.windl@rz.uni-regensburg.de> wrote:\n>\n> what made me wonder is this (about item 1): I thought I've read that blobs store\n> content and attributes, so very obviously I wondered why not store thr \"right\n> attributes\" (i.e. the time of the file). My reasoning: You make some changes, then\n> test them (which might last several hours or days). The if I'm happy I'll\n> \"commit\".\n\nWith Git, you usually commit your changes immediately (without waiting\nthe result\nof testing), because you can always undo commit until you publish your changes.\n\n\nDmitry\n"},{"id":"109637","messageId":"49CCCB3D.8010706@drmicha.warpmail.net","threadId":"18586","inReplyTo":"49CC8C90.12268.242CEFCE@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de","subject":"Re: On git 1.6 (novice's opinion)","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-03-27T12:49:01Z","receivedAt":"2009-03-27T12:49:01Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Ulrich Windl venit, vidit, dixit 27.03.2009 08:21:\n> Hello everybody,\n> \n> [About my experience on version control systems: I started out with SCCS in\n> the eighties, and I thought it must be cool as the UNIX guys used it to\n> maintain their sources. Some times later I was using Emacs' numbered backup\n> files as a poor substiutute for nothing else. Then I came across RCS, and I\n> liked it soon ,because it was fully documented and well-written. I even ported\n> it to MS-DOS (whew!). I was attaching tags to individual files to mark\n> \"releases\" at those times. Then I heard about CVS. It seemed to help with the\n> tagging, so I used it for the mopre complex projects. I even did branches and\n> merging with it for the Linux sources. I spontaneously diskliked Bitkeeper,\n> because it would not work off-line. I heard about Git some time ago, but using\n> it seems very non-obvious. After having read the tutorial, and playing some\n> simple scenarios, I must admit that I really like the fully distributed nature\n> of it. However some commands seem to be a bit strange (e.g. \"git add\" is\n> almost, but quite a \"commit\" (if you come from CVS)), and sources are quite\n> complex. Also some seemingly dangerous commands that cannot easily be undone\n> should ask safety questions (\"cvs merge (-j)\" would also fall into that\n> category.]\n> \n> What I'd like to see in git (My apologies if some were already discussed to \n> death):\n> \n> 1) The ability to use the file's time at the time of add/commit instead of the\n> current time, and the ability tho check outfiles with the times stored in the\n> repository.\n> \n> 2) Keyword substitution. I know it's controverse (dealing with binary files),\n> but I'd like to have some automatic version numbering keyword at least:\n> Initial idea is that every commit with a change increments the number by one,\n> and when merging numbers a and b, the resulting number is max(a, b) + 1.\n\nKeyword substitution and cvs/svn style version numbers are independent\nissues. The sha1 describes a commit uniquely, one could use that as a\nkeyword.\n\nIncreasing version numbers are meaningless in a true DVCS world. What is\nyour 100th commit may not be someone else's, even if both your master's\nheads are the same! This is why hg version numbers are a local thing.\nThey are merely a local shortcut for specifying a revision and serve the\nsame purpose as git's \"backward\" counts like HEAD~3 etc. Neither of them\nwork permanently, not even in a local repo, if you allow rebasing.\n\ngit rev-list HEAD|wc may produce something like it, but be sure to read\nup on --sparse and --full-history.\n\n> 3) \"git undo\": If possible undo the effects of the last command.\n> \n> Following are some random remarks from a first-time git user, regarding the \n> buld/install:\n> \n> Notes on building git-1.6.1.3 on openSUSE 11.0:\n> There is no \"asciidoc\"; the INSTALL should be more verbose on special\n> requirements (i.e. additional packages needed, and where to get them).\n> LANG= make configure\n> /bin/sh: curl-config: command not found\n> make: `configure' is up to date.\n> \n> make[2]: Entering directory `/git/git-1.6.1.3'\n> make[2]: `GIT-VERSION-FILE' is up to date.\n> make[2]: Leaving directory `/git/git-1.6.1.3'\n> rm -f git-add.html+ git-add.html\n> asciidoc -b xhtml11 -d manpage -f asciidoc.conf \\\n>                  -agit_version=1.6.1.3 -o git-add.html+ git-add.txt\n> make[1]: asciidoc: Command not found\n> make[1]: *** [git-add.html] Error 127\n> make[1]: Leaving directory `/git/git-1.6.1.3/Documentation'\n> make: *** [doc] Error 2\n> \n> Some parts of the make process may look like an error if they pass by quickly:\n> \n> [...]\n>     GEN git-request-pull\n>     GEN git-sh-setup\n>     GEN git-stash\n>     GEN git-submodule\n>     GEN git-web--browse\n>     SUBDIR perl\n> /usr/bin/perl Makefile.PL PREFIX='/home/windl/Projects/git/inst'\n> Writing perl.mak for Git\n>     GEN git-add--interactive\n>     GEN git-archimport\n>     GEN git-cvsexportcommit\n>     GEN git-cvsimport\n> [...]\n> \n> Same is true for the install process:\n> make[1]: Leaving directory `/home/windl/Projects/git/git-1.6.1.3/git-gui'\n> bindir=$(cd '/home/windl/Projects/git/inst/bin' && pwd) && \\\n>         execdir=$(cd '/home/windl/Projects/git/inst/libexec/git-core/' && pwd) && \n> \\\n>         { rm -f \"$execdir/git-add\" && \\\n>                 ln git-add \"$execdir/git-add\" 2>/dev/null || \\\n>                 cp git-add \"$execdir/git-add\"; } && \\\n>         {  rm -f \"$execdir/git-annotate\" && ln \"$execdir/git-add\" \"$execdir/git-\n> annotate\" 2>/dev/null || ln -s \"git-add\" \"$execdir/git-annotate\" 2>/dev/null || cp \n> \"$execdir/git-add\" \"$execdir/git-annotate\" || exit;  rm -f \"$execdir/git-apply\" && \n> ln \"$execdir/git-add\" \"$execdir/git-apply\" 2>/dev/null || ln -s \"git-add\" \n> \"$execdir/git-apply\" 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-apply\" || \n> exit;  rm -f \"$execdir/git-archive\" && ln \"$execdir/git-add\" \"$execdir/git-\n> archive\" 2>/dev/null || ln -s \"git-add\" \"$execdir/git-archive\" 2>/dev/null || cp \n> \"$execdir/git-add\" \"$execdir/git-archive\" || exit;  rm -f \"$execdir/git-blame\" && \n> ln \"$execdir/git-add\" \"$execdir/git-blame\" 2>/dev/null || ln -s \"git-add\" \n> \"$execdir/git-blame\" 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-blame\" || \n> exit;  rm -f \"$execdir/git-branch\" && ln \"$execdir/git-add\" \"$execdir/git-branch\" \n> 2>/dev/null || ln -s \"git-add\" \"$execdir/git-branch\" 2>/dev/null || cp \n> \"$execdir/git-add\" \"$execdir/git-branch\" || exit;  rm -f \"$execdir/git-bundle\" && \n> ln \"$execdir/git-add\" \"$execdir/git-bundle\" 2>/dev/null || ln -s \"git-add\" \n> \"$execdir/git-bundle\" 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-bundle\" \n> || exit;  rm -f \"$execdir/git-cat-file\" && ln \"$execdir/git-add\" \"$execdir/git-\n> cat-file\" 2>/dev/null || ln -s \"git-add\" \"$execdir/git-cat-file\" 2>/dev/null || cp \n> \"$execdir/git-add\" \"$execdir/git-cat-file\" || exit;  rm -f \"$execdir/git-check-\n> attr\" && ln \"$execdir/git-add\" \"$execdir/git-check-attr\" 2>/dev/null || ln -s \n> \"git-add\" \"$execdir/git-check-attr\" 2>/dev/null || cp \"$execdir/git-add\" \n> \"$execdir/git-check-attr\" || exit;  rm -f \"$execdir/git-check-ref-format\" && ln \n> \"$execdir/git-add\" \"$execdir/git-check-ref-format\" 2>/dev/null || ln -s \"git-add\" \n> \"$execdir/git-check-ref-format\" 2>/dev/null || cp \"$execdir/git-add\" \n> \"$execdir/git-check-ref-format\" || exit;  rm -f \"$execdir/git-checkout-index\" && \n> ln \"$execdir/git-add\" \"$execdir/git-checkout-index\" 2>/dev/null || ln -s \"git-add\" \n> \"$execdir/git-checkout-index\" 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-\n> checkout-index\" || exit;  rm -f \"$execdir/git-checkout\" && ln \"$execdir/git-add\" \n> \"$execdir/git-checkout\" 2>/dev/null || ln -s \"git-add\" \"$execdir/git-checkout\" \n> 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-checkout\" || exit;  rm -f \n> \"$execdir/git-clean\" && ln \"$execdir/git-add\" \"$execdir/git-clean\" 2>/dev/null || \n> ln -s \"git-add\" \"$execdir/git-clean\" 2>/dev/null || cp \"$execdir/git-add\" \n> \"$execdir/git-clean\" || exit;  rm -f \"$execdir/git-clone\" && ln \"$execdir/git-add\" \n> \"$execdir/git-clone\" 2>/dev/null || ln -s \"git-add\" \"$execdir/git-clone\" \n> 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-clone\" || exit;  rm -f \n> \"$execdir/git-commit-tree\" && ln \"$execdir/git-add\" \"$execdir/git-commit-tree\" \n> 2>/dev/null || ln -s \"git-add\" \"$execdir/git-commit-tree\" 2>/dev/null || cp \n> \"$execdir/git-add\" \"$execdir/git-commit-tree\" || exit;  rm -f \"$execdir/git-\n> commit\" && ln \"$execdir/git-add\" \"$execdir/git-commit\" 2>/dev/null || ln -s \"git-\n> add\" \"$execdir/git-commit\" 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-\n> commit\" || exit;  rm -f \"$execdir/git-config\" && ln \"$execdir/git-add\" \n> \"$execdir/git-config\" 2>/dev/null || ln -s \"git-add\" \"$execdir/git-config\" \n> 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-config\" || exit;  rm -f \n> \"$execdir/git-count-objects\" && ln \"$execdir/git-add\" \"$execdir/git-count-objects\" \n> 2>/dev/null || ln -s \"git-add\" \"$execdir/git-count-objects\" 2>/dev/null || cp \n> \"$execdir/git-add\" \"$execdir/git-count-objects\" || exit;  rm -f \"$execdir/git-\n> describe\" && ln \"$execdir/git-add\" \"$execdir/git-describe\" 2>/dev/null || ln -s \n> \"git-add\" \"$execdir/git-describe\" 2>/dev/null || cp \"$execdir/git-add\" \n> \"$execdir/git-describe\" || exit;  rm -f \"$execdir/git-diff-files\" && ln \n> \"$execdir/git-add\" \"$execdir/git-diff-files\" 2>/dev/null || ln -s \"git-add\" \n> \"$execdir/git-diff-files\" 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-diff-\n> files\" || exit;  rm -f \"$execdir/git-diff-index\" && ln \"$execdir/git-add\" \n> \"$execdir/git-diff-index\" 2>/dev/null || ln -s \"git-add\" \"$execdir/git-diff-index\" \n> 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-diff-index\" || exit;  rm -f \n> \"$execdir/git-diff-tree\" && ln \"$execdir/git-add\" \"$execdir/git-diff-tree\" \n> 2>/dev/null || ln -s \"git-add\" \"$execdir/git-diff-tree\" 2>/dev/null || cp \n> \"$execdir/git-add\" \"$execdir/git-diff-tree\" || exit;  rm -f \"$execdir/git-diff\" && \n> ln \"$execdir/git-add\" \"$execdir/git-diff\" 2>/dev/null || ln -s \"git-add\" \n> \"$execdir/git-diff\" 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-diff\" || \n> exit;  rm -f \"$execdir/git-fast-export\" && ln \"$execdir/git-add\" \"$execdir/git-\n> fast-export\" 2>/dev/null || ln -s \"git-add\" \"$execdir/git-fast-export\" 2>/dev/null \n> || cp \"$execdir/git-add\" \"$execdir/git-fast-export\" || exit;  rm -f \"$execdir/git-\n> fetch--tool\" && ln \"$execdir/git-add\" \"$execdir/git-fetch--tool\" 2>/dev/null || ln \n> -s \"git-add\" \"$execdir/git-fetch--tool\" 2>/dev/null || cp \"$execdir/git-add\" \n> \"$execdir/git-fetch--tool\" || exit;  rm -f \"$execdir/git-fetch-pack\" && ln \n> \"$execdir/git-add\" \"$execdir/git-fetch-pack\" 2>/dev/null || ln -s \"git-add\" \n> \"$execdir/git-fetch-pack\" 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-\n> fetch-pack\" || exit;  rm -f \"$execdir/git-fetch\" && ln \"$execdir/git-add\" \n> \"$execdir/git-fetch\" 2>/dev/null || ln -s \"git-add\" \"$execdir/git-fetch\" \n> 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-fetch\" || exit;  rm -f \n> \"$execdir/git-fmt-merge-msg\" && ln \"$execdir/git-add\" \"$execdir/git-fmt-merge-msg\" \n> 2>/dev/null || ln -s \"git-add\" \"$execdir/git-fmt-merge-msg\" 2>/dev/null || cp \n> \"$execdir/git-add\" \"$execdir/git-fmt-merge-msg\" || exit;  rm -f \"$execdir/git-for-\n> each-ref\" && ln \"$execdir/git-add\" \"$execdir/git-for-each-ref\" 2>/dev/null || ln -\n> s \"git-add\" \"$execdir/git-for-each-ref\" 2>/dev/null || cp \"$execdir/git-add\" \n> \"$execdir/git-for-each-ref\" || exit;  rm -f \"$execdir/git-fsck\" && ln \n> \"$execdir/git-add\" \"$execdir/git-fsck\" 2>/dev/null || ln -s \"git-add\" \n> \"$execdir/git-fsck\" 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-fsck\" || \n> exit;  rm -f \"$execdir/git-gc\" && ln \"$execdir/git-add\" \"$execdir/git-gc\" \n> 2>/dev/null || ln -s \"git-add\" \"$execdir/git-gc\" 2>/dev/null || cp \"$execdir/git-\n> add\" \"$execdir/git-gc\" || exit;  rm -f \"$execdir/git-grep\" && ln \"$execdir/git-\n> add\" \"$execdir/git-grep\" 2>/dev/null || ln -s \"git-add\" \"$execdir/git-grep\" \n> 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-grep\" || exit;  rm -f \n> \"$execdir/git-help\" && ln \"$execdir/git-add\" \"$execdir/git-help\" 2>/dev/null || ln \n> -s \"git-add\" \"$execdir/git-help\" 2>/dev/null || cp \"$execdir/git-add\" \n> \"$execdir/git-help\" || exit;  rm -f \"$execdir/git-init-db\" && ln \"$execdir/git-\n> add\" \"$execdir/git-init-db\" 2>/dev/null || ln -s \"git-add\" \"$execdir/git-init-db\" \n> 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-init-db\" || exit;  rm -f \n> \"$execdir/git-log\" && ln \"$execdir/git-add\" \"$execdir/git-log\" 2>/dev/null || ln -\n> s \"git-add\" \"$execdir/git-log\" 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-\n> log\" || exit;  rm -f \"$execdir/git-ls-files\" && ln \"$execdir/git-add\" \n> \"$execdir/git-ls-files\" 2>/dev/null || ln -s \"git-add\" \"$execdir/git-ls-files\" \n> 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-ls-files\" || exit;  rm -f \n> \"$execdir/git-ls-remote\" && ln \"$execdir/git-add\" \"$execdir/git-ls-remote\" \n> 2>/dev/null || ln -s \"git-add\" \"$execdir/git-ls-remote\" 2>/dev/null || cp \n> \"$execdir/git-add\" \"$execdir/git-ls-remote\" || exit;  rm -f \"$execdir/git-ls-tree\" \n> && ln \"$execdir/git-add\" \"$execdir/git-ls-tree\" 2>/dev/null || ln -s \"git-add\" \n> \"$execdir/git-ls-tree\" 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-ls-tree\" \n> || exit;  rm -f \"$execdir/git-mailinfo\" && ln \"$execdir/git-add\" \"$execdir/git-\n> mailinfo\" 2>/dev/null || ln -s \"git-add\" \"$execdir/git-mailinfo\" 2>/dev/null || cp \n> \"$execdir/git-add\" \"$execdir/git-mailinfo\" || exit;  rm -f \"$execdir/git-\n> mailsplit\" && ln \"$execdir/git-add\" \"$execdir/git-mailsplit\" 2>/dev/null || ln -s \n> \"git-add\" \"$execdir/git-mailsplit\" 2>/dev/null || cp \"$execdir/git-add\" \n> \"$execdir/git-mailsplit\" || exit;  rm -f \"$execdir/git-merge\" && ln \"$execdir/git-\n> add\" \"$execdir/git-merge\" 2>/dev/null || ln -s \"git-add\" \"$execdir/git-merge\" \n> 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-merge\" || exit;  rm -f \n> \"$execdir/git-merge-base\" && ln \"$execdir/git-add\" \"$execdir/git-merge-base\" \n> 2>/dev/null || ln -s \"git-add\" \"$execdir/git-merge-base\" 2>/dev/null || cp \n> \"$execdir/git-add\" \"$execdir/git-merge-base\" || exit;  rm -f \"$execdir/git-merge-\n> file\" && ln \"$execdir/git-add\" \"$execdir/git-merge-file\" 2>/dev/null || ln -s \n> \"git-add\" \"$execdir/git-merge-file\" 2>/dev/null || cp \"$execdir/git-add\" \n> \"$execdir/git-merge-file\" || exit;  rm -f \"$execdir/git-merge-ours\" && ln \n> \"$execdir/git-add\" \"$execdir/git-merge-ours\" 2>/dev/null || ln -s \"git-add\" \n> \"$execdir/git-merge-ours\" 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-\n> merge-ours\" || exit;  rm -f \"$execdir/git-merge-recursive\" && ln \"$execdir/git-\n> add\" \"$execdir/git-merge-recursive\" 2>/dev/null || ln -s \"git-add\" \"$execdir/git-\n> merge-recursive\" 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-merge-\n> recursive\" || exit;  rm -f \"$execdir/git-mv\" && ln \"$execdir/git-add\" \n> \"$execdir/git-mv\" 2>/dev/null || ln -s \"git-add\" \"$execdir/git-mv\" 2>/dev/null || \n> cp \"$execdir/git-add\" \"$execdir/git-mv\" || exit;  rm -f \"$execdir/git-name-rev\" && \n> ln \"$execdir/git-add\" \"$execdir/git-name-rev\" 2>/dev/null || ln -s \"git-add\" \n> \"$execdir/git-name-rev\" 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-name-\n> rev\" || exit;  rm -f \"$execdir/git-pack-objects\" && ln \"$execdir/git-add\" \n> \"$execdir/git-pack-objects\" 2>/dev/null || ln -s \"git-add\" \"$execdir/git-pack-\n> objects\" 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-pack-objects\" || exit;  \n> rm -f \"$execdir/git-pack-refs\" && ln \"$execdir/git-add\" \"$execdir/git-pack-refs\" \n> 2>/dev/null || ln -s \"git-add\" \"$execdir/git-pack-refs\" 2>/dev/null || cp \n> \"$execdir/git-add\" \"$execdir/git-pack-refs\" || exit;  rm -f \"$execdir/git-prune-\n> packed\" && ln \"$execdir/git-add\" \"$execdir/git-prune-packed\" 2>/dev/null || ln -s \n> \"git-add\" \"$execdir/git-prune-packed\" 2>/dev/null || cp \"$execdir/git-add\" \n> \"$execdir/git-prune-packed\" || exit;  rm -f \"$execdir/git-prune\" && ln \n> \"$execdir/git-add\" \"$execdir/git-prune\" 2>/dev/null || ln -s \"git-add\" \n> \"$execdir/git-prune\" 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-prune\" || \n> exit;  rm -f \"$execdir/git-push\" && ln \"$execdir/git-add\" \"$execdir/git-push\" \n> 2>/dev/null || ln -s \"git-add\" \"$execdir/git-push\" 2>/dev/null || cp \n> \"$execdir/git-add\" \"$execdir/git-push\" || exit;  rm -f \"$execdir/git-read-tree\" && \n> ln \"$execdir/git-add\" \"$execdir/git-read-tree\" 2>/dev/null || ln -s \"git-add\" \n> \"$execdir/git-read-tree\" 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-read-\n> tree\" || exit;  rm -f \"$execdir/git-receive-pack\" && ln \"$execdir/git-add\" \n> \"$execdir/git-receive-pack\" 2>/dev/null || ln -s \"git-add\" \"$execdir/git-receive-\n> pack\" 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-receive-pack\" || exit;  \n> rm -f \"$execdir/git-reflog\" && ln \"$execdir/git-add\" \"$execdir/git-reflog\" \n> 2>/dev/null || ln -s \"git-add\" \"$execdir/git-reflog\" 2>/dev/null || cp \n> \"$execdir/git-add\" \"$execdir/git-reflog\" || exit;  rm -f \"$execdir/git-remote\" && \n> ln \"$execdir/git-add\" \"$execdir/git-remote\" 2>/dev/null || ln -s \"git-add\" \n> \"$execdir/git-remote\" 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-remote\" \n> || exit;  rm -f \"$execdir/git-rerere\" && ln \"$execdir/git-add\" \"$execdir/git-\n> rerere\" 2>/dev/null || ln -s \"git-add\" \"$execdir/git-rerere\" 2>/dev/null || cp \n> \"$execdir/git-add\" \"$execdir/git-rerere\" || exit;  rm -f \"$execdir/git-reset\" && \n> ln \"$execdir/git-add\" \"$execdir/git-reset\" 2>/dev/null || ln -s \"git-add\" \n> \"$execdir/git-reset\" 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-reset\" || \n> exit;  rm -f \"$execdir/git-rev-list\" && ln \"$execdir/git-add\" \"$execdir/git-rev-\n> list\" 2>/dev/null || ln -s \"git-add\" \"$execdir/git-rev-list\" 2>/dev/null || cp \n> \"$execdir/git-add\" \"$execdir/git-rev-list\" || exit;  rm -f \"$execdir/git-rev-\n> parse\" && ln \"$execdir/git-add\" \"$execdir/git-rev-parse\" 2>/dev/null || ln -s \n> \"git-add\" \"$execdir/git-rev-parse\" 2>/dev/null || cp \"$execdir/git-add\" \n> \"$execdir/git-rev-parse\" || exit;  rm -f \"$execdir/git-revert\" && ln \n> \"$execdir/git-add\" \"$execdir/git-revert\" 2>/dev/null || ln -s \"git-add\" \n> \"$execdir/git-revert\" 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-revert\" \n> || exit;  rm -f \"$execdir/git-rm\" && ln \"$execdir/git-add\" \"$execdir/git-rm\" \n> 2>/dev/null || ln -s \"git-add\" \"$execdir/git-rm\" 2>/dev/null || cp \"$execdir/git-\n> add\" \"$execdir/git-rm\" || exit;  rm -f \"$execdir/git-send-pack\" && ln \n> \"$execdir/git-add\" \"$execdir/git-send-pack\" 2>/dev/null || ln -s \"git-add\" \n> \"$execdir/git-send-pack\" 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-send-\n> pack\" || exit;  rm -f \"$execdir/git-shortlog\" && ln \"$execdir/git-add\" \n> \"$execdir/git-shortlog\" 2>/dev/null || ln -s \"git-add\" \"$execdir/git-shortlog\" \n> 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-shortlog\" || exit;  rm -f \n> \"$execdir/git-show-branch\" && ln \"$execdir/git-add\" \"$execdir/git-show-branch\" \n> 2>/dev/null || ln -s \"git-add\" \"$execdir/git-show-branch\" 2>/dev/null || cp \n> \"$execdir/git-add\" \"$execdir/git-show-branch\" || exit;  rm -f \"$execdir/git-show-\n> ref\" && ln \"$execdir/git-add\" \"$execdir/git-show-ref\" 2>/dev/null || ln -s \"git-\n> add\" \"$execdir/git-show-ref\" 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-\n> show-ref\" || exit;  rm -f \"$execdir/git-stripspace\" && ln \"$execdir/git-add\" \n> \"$execdir/git-stripspace\" 2>/dev/null || ln -s \"git-add\" \"$execdir/git-stripspace\" \n> 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-stripspace\" || exit;  rm -f \n> \"$execdir/git-symbolic-ref\" && ln \"$execdir/git-add\" \"$execdir/git-symbolic-ref\" \n> 2>/dev/null || ln -s \"git-add\" \"$execdir/git-symbolic-ref\" 2>/dev/null || cp \n> \"$execdir/git-add\" \"$execdir/git-symbolic-ref\" || exit;  rm -f \"$execdir/git-tag\" \n> && ln \"$execdir/git-add\" \"$execdir/git-tag\" 2>/dev/null || ln -s \"git-add\" \n> \"$execdir/git-tag\" 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-tag\" || \n> exit;  rm -f \"$execdir/git-tar-tree\" && ln \"$execdir/git-add\" \"$execdir/git-tar-\n> tree\" 2>/dev/null || ln -s \"git-add\" \"$execdir/git-tar-tree\" 2>/dev/null || cp \n> \"$execdir/git-add\" \"$execdir/git-tar-tree\" || exit;  rm -f \"$execdir/git-unpack-\n> objects\" && ln \"$execdir/git-add\" \"$execdir/git-unpack-objects\" 2>/dev/null || ln \n> -s \"git-add\" \"$execdir/git-unpack-objects\" 2>/dev/null || cp \"$execdir/git-add\" \n> \"$execdir/git-unpack-objects\" || exit;  rm -f \"$execdir/git-update-index\" && ln \n> \"$execdir/git-add\" \"$execdir/git-update-index\" 2>/dev/null || ln -s \"git-add\" \n> \"$execdir/git-update-index\" 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-\n> update-index\" || exit;  rm -f \"$execdir/git-update-ref\" && ln \"$execdir/git-add\" \n> \"$execdir/git-update-ref\" 2>/dev/null || ln -s \"git-add\" \"$execdir/git-update-ref\" \n> 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-update-ref\" || exit;  rm -f \n> \"$execdir/git-upload-archive\" && ln \"$execdir/git-add\" \"$execdir/git-upload-\n> archive\" 2>/dev/null || ln -s \"git-add\" \"$execdir/git-upload-archive\" 2>/dev/null \n> || cp \"$execdir/git-add\" \"$execdir/git-upload-archive\" || exit;  rm -f \n> \"$execdir/git-verify-pack\" && ln \"$execdir/git-add\" \"$execdir/git-verify-pack\" \n> 2>/dev/null || ln -s \"git-add\" \"$execdir/git-verify-pack\" 2>/dev/null || cp \n> \"$execdir/git-add\" \"$execdir/git-verify-pack\" || exit;  rm -f \"$execdir/git-\n> verify-tag\" && ln \"$execdir/git-add\" \"$execdir/git-verify-tag\" 2>/dev/null || ln -\n> s \"git-add\" \"$execdir/git-verify-tag\" 2>/dev/null || cp \"$execdir/git-add\" \n> \"$execdir/git-verify-tag\" || exit;  rm -f \"$execdir/git-write-tree\" && ln \n> \"$execdir/git-add\" \"$execdir/git-write-tree\" 2>/dev/null || ln -s \"git-add\" \n> \"$execdir/git-write-tree\" 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-\n> write-tree\" || exit;  rm -f \"$execdir/git-cherry-pick\" && ln \"$execdir/git-add\" \n> \"$execdir/git-cherry-pick\" 2>/dev/null || ln -s \"git-add\" \"$execdir/git-cherry-\n> pick\" 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-cherry-pick\" || exit;  rm \n> -f \"$execdir/git-cherry\" && ln \"$execdir/git-add\" \"$execdir/git-cherry\" \n> 2>/dev/null || ln -s \"git-add\" \"$execdir/git-cherry\" 2>/dev/null || cp \n> \"$execdir/git-add\" \"$execdir/git-cherry\" || exit;  rm -f \"$execdir/git-format-\n> patch\" && ln \"$execdir/git-add\" \"$execdir/git-format-patch\" 2>/dev/null || ln -s \n> \"git-add\" \"$execdir/git-format-patch\" 2>/dev/null || cp \"$execdir/git-add\" \n> \"$execdir/git-format-patch\" || exit;  rm -f \"$execdir/git-fsck-objects\" && ln \n> \"$execdir/git-add\" \"$execdir/git-fsck-objects\" 2>/dev/null || ln -s \"git-add\" \n> \"$execdir/git-fsck-objects\" 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-\n> fsck-objects\" || exit;  rm -f \"$execdir/git-get-tar-commit-id\" && ln \n> \"$execdir/git-add\" \"$execdir/git-get-tar-commit-id\" 2>/dev/null || ln -s \"git-add\" \n> \"$execdir/git-get-tar-commit-id\" 2>/dev/null || cp \"$execdir/git-add\" \n> \"$execdir/git-get-tar-commit-id\" || exit;  rm -f \"$execdir/git-init\" && ln \n> \"$execdir/git-add\" \"$execdir/git-init\" 2>/dev/null || ln -s \"git-add\" \n> \"$execdir/git-init\" 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-init\" || \n> exit;  rm -f \"$execdir/git-merge-subtree\" && ln \"$execdir/git-add\" \"$execdir/git-\n> merge-subtree\" 2>/dev/null || ln -s \"git-add\" \"$execdir/git-merge-subtree\" \n> 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-merge-subtree\" || exit;  rm -f \n> \"$execdir/git-peek-remote\" && ln \"$execdir/git-add\" \"$execdir/git-peek-remote\" \n> 2>/dev/null || ln -s \"git-add\" \"$execdir/git-peek-remote\" 2>/dev/null || cp \n> \"$execdir/git-add\" \"$execdir/git-peek-remote\" || exit;  rm -f \"$execdir/git-repo-\n> config\" && ln \"$execdir/git-add\" \"$execdir/git-repo-config\" 2>/dev/null || ln -s \n> \"git-add\" \"$execdir/git-repo-config\" 2>/dev/null || cp \"$execdir/git-add\" \n> \"$execdir/git-repo-config\" || exit;  rm -f \"$execdir/git-show\" && ln \n> \"$execdir/git-add\" \"$execdir/git-show\" 2>/dev/null || ln -s \"git-add\" \n> \"$execdir/git-show\" 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-show\" || \n> exit;  rm -f \"$execdir/git-stage\" && ln \"$execdir/git-add\" \"$execdir/git-stage\" \n> 2>/dev/null || ln -s \"git-add\" \"$execdir/git-stage\" 2>/dev/null || cp \n> \"$execdir/git-add\" \"$execdir/git-stage\" || exit;  rm -f \"$execdir/git-status\" && \n> ln \"$execdir/git-add\" \"$execdir/git-status\" 2>/dev/null || ln -s \"git-add\" \n> \"$execdir/git-status\" 2>/dev/null || cp \"$execdir/git-add\" \"$execdir/git-status\" \n> || exit;  rm -f \"$execdir/git-whatchanged\" && ln \"$execdir/git-add\" \"$execdir/git-\n> whatchanged\" 2>/dev/null || ln -s \"git-add\" \"$execdir/git-whatchanged\" 2>/dev/null \n> || cp \"$execdir/git-add\" \"$execdir/git-whatchanged\" || exit; } && \\\n>         ./check_bindir \"z$bindir\" \"z$execdir\" \"$bindir/git-add\"\n> \n> There's a problem with \"make quick-install-man\":\n> LANG= make quick-install-man\n> make -C Documentation quick-install-man\n> make[1]: Entering directory `/git/git-1.6.1.3/Documentation'\n> make -C ../ GIT-VERSION-FILE\n> make[2]: Entering directory `/git/git-1.6.1.3'\n> make[2]: `GIT-VERSION-FILE' is up to date.\n> make[2]: Leaving directory `/git/git-1.6.1.3'\n> sh ./install-doc-quick.sh origin/man /git/inst/share/man\n> ./install-doc-quick.sh: line 9: /git/inst/libexec/git-sh-setup: No such file or \n> directory\n> make[1]: *** [quick-install-man] Error 1\n> make[1]: Leaving directory `/git/git-1.6.1.3/Documentation'\n> make: *** [quick-install-man] Error 2\n> \n> Regards,\n> Ulrich Windl\n> \n"},{"id":"109640","messageId":"49CCE421.16918.2582FE84@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de","threadId":"18586","inReplyTo":"37fcd2780903270524x1987a622wb9e693be41fc02c4@mail.gmail.com","subject":"Re: On git 1.6 (novice's opinion)","fromName":"Ulrich Windl","fromEmail":"ulrich.windl@rz.uni-regensburg.de","sentAt":"2009-03-27T13:35:13Z","receivedAt":"2009-03-27T13:35:13Z","isPatch":false,"sender":{"key":"ulrich.windl@rz.uni-regensburg.de","avatar":null},"body":"On 27 Mar 2009 at 15:24, Dmitry Potapov wrote:\n\n> On Fri, Mar 27, 2009 at 10:21 AM, Ulrich Windl\n> <ulrich.windl@rz.uni-regensburg.de> wrote:\n> >\n> > 1) The ability to use the file's time at the time of add/commit instead of the\n> > current time, and the ability tho check outfiles with the times stored in the\n> > repository.\n> \n> To check out with the times stored in repository is a a bad idea, because it\n> will screw up 'make'.\n\nHi,\n\nI don't understand:\nIf I modify files, then do a make, then do check-in/check-out (and the file times \nare unchanged), how would that affect make?\n\nIf I do an \"update/merge from remote\" (there is no total ordering of release \nnumbers anyway) without a \"make clean\" before, I'm having a problem anyway.\n\n> \n> >\n> > 2) Keyword substitution. I know it's controverse (dealing with binary files),\n> > but I'd like to have some automatic version numbering keyword at least:\n> > Initial idea is that every commit with a change increments the number by one,\n> > and when merging numbers a and b, the resulting number is max(a, b) + 1.\n> \n> I am not sure what you want to achieve by having this number. Also, take\n> a look at \"git describe\", it may be close to what you want (or may be not).\n\nBasically I want to support my laziness: The system will increment some number and \nmaybe change some text automatically that I'm to lazy to do. OK, there are still \nmany commands I'll have to learn. Unfortunately some command names are not as \n\"crispy\" as they could be (i.e. you cannot easily find the right command name if \nyou know what you are looking for, and if you have a command name, it's not very \nclear what it really does). That makes it hard for the beginners.\n\nRegards,\nUlrich\n"},{"id":"109641","messageId":"49CCE520.17260.2586E134@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de","threadId":"18586","inReplyTo":"37fcd2780903270524y39456c5fre0a2f8f9c5f4d160@mail.gmail.com","subject":"Re: On git 1.6 (novice's opinion)","fromName":"Ulrich Windl","fromEmail":"ulrich.windl@rz.uni-regensburg.de","sentAt":"2009-03-27T13:39:28Z","receivedAt":"2009-03-27T13:39:28Z","isPatch":false,"sender":{"key":"ulrich.windl@rz.uni-regensburg.de","avatar":null},"body":"On 27 Mar 2009 at 15:24, Dmitry Potapov wrote:\n\n> On Fri, Mar 27, 2009 at 12:50 PM, Ulrich Windl\n> <ulrich.windl@rz.uni-regensburg.de> wrote:\n> >\n> > what made me wonder is this (about item 1): I thought I've read that blobs store\n> > content and attributes, so very obviously I wondered why not store thr \"right\n> > attributes\" (i.e. the time of the file). My reasoning: You make some changes, then\n> > test them (which might last several hours or days). The if I'm happy I'll\n> > \"commit\".\n> \n> With Git, you usually commit your changes immediately (without waiting\n> the result\n> of testing), because you can always undo commit until you publish your changes.\n\nHi!\n\nAFAIK, \"committing\" in git is \"kind of publishing your work\" (others may pull it). \nI don't like publishing my mistakes ;-) Even if no-one pulls the commit, your \n\"undo\" refers to \"committing a fix for the last committed mistake\", right? Again, \nI don't really want to document/archive (i.e. commit) my mistake. Or did I miss \nsomething here?\nI know: Other's opinions are quite different on these issues.\n\nRegards,\nUlrich\n"},{"id":"109643","messageId":"vpq63hvdqs2.fsf@bauges.imag.fr","threadId":"18586","inReplyTo":"49CCE421.16918.2582FE84@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de","subject":"Re: On git 1.6 (novice's opinion)","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2009-03-27T13:44:13Z","receivedAt":"2009-03-27T13:44:13Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"\"Ulrich Windl\" <ulrich.windl@rz.uni-regensburg.de> writes:\n\n> I don't understand:\n> If I modify files, then do a make, then do check-in/check-out (and the file times \n> are unchanged), how would that affect make?\n\n>From \"make\"'s point of view, chechout is just a modification of the\nfile (as any other modification you would do with a text editor). If\nyou compile foo.c to foo.o, then checkout another version of foo.c,\nthen you want foo.c to be recompiled. If checkout modifies the\ntimestamp to pretend it was modified before foo.o, then make thinks\nthe file is up to date.\n\n> If I do an \"update/merge from remote\" (there is no total ordering of release \n> numbers anyway) without a \"make clean\" before, I'm having a problem\n> anyway.\n\nNo, you don't have a problem. Recompiling files after they're modified\nis the job of make, and it just does it. make doesn't know about\nrevision numbers or identifiers, just timestamps.\n\n-- \nMatthieu\n"},{"id":"109644","messageId":"vpq1vsjdqpk.fsf@bauges.imag.fr","threadId":"18586","inReplyTo":"49CCE520.17260.2586E134@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de","subject":"Re: On git 1.6 (novice's opinion)","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2009-03-27T13:45:43Z","receivedAt":"2009-03-27T13:45:43Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"\"Ulrich Windl\" <ulrich.windl@rz.uni-regensburg.de> writes:\n\n> Hi!\n>\n> AFAIK, \"committing\" in git is \"kind of publishing your work\" \n\nIt's not. It's \"take a snapshot\". Publish is \"push\" (to a public\nplace).\n\n> (others may pull it). I don't like publishing my mistakes ;-) Even\n> if no-one pulls the commit, your \"undo\" refers to \"committing a fix\n> for the last committed mistake\", right? Again, I don't really want\n> to document/archive (i.e. commit) my mistake. Or did I miss\n> something here? \n\ngit commit --amend\ngit reset HEAD^ and friends (to uncommit something)\n\n-- \nMatthieu\n"},{"id":"109642","messageId":"49CCD90F.6090707@gmail.com","threadId":"18586","inReplyTo":"49CCE520.17260.2586E134@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de","subject":"Re: On git 1.6 (novice's opinion)","fromName":"Etienne Vallette d'Osia","fromEmail":"dohzya@gmail.com","sentAt":"2009-03-27T13:47:59Z","receivedAt":"2009-03-27T13:47:59Z","isPatch":false,"sender":{"key":"dohzya@gmail.com","avatar":"https://gravatar.com/avatar/2ec58d74d930356327523e6b5fe992a0a9b2d2748b733ba63a9d1298798853c3?d=mp&s=160"},"body":"Ulrich Windl a écrit :\n> AFAIK, \"committing\" in git is \"kind of publishing your work\" (others may pull it). \n> I don't like publishing my mistakes ;-) Even if no-one pulls the commit, your \n> \"undo\" refers to \"committing a fix for the last committed mistake\", right? Again, \n> I don't really want to document/archive (i.e. commit) my mistake. Or did I miss \n> something here?\n> I know: Other's opinions are quite different on these issues.\n\ncommit is local.\nThe good way is to commit in your local and private repository.\nThen you can do anything, reset commit you have just done, etc\nWhen all is ok, you push in a public repository.\n\nWith this workflow, no one see your local work and you can commit very \noften, undo commit, rebase a lot etc.\n\nThe only result of a such job is a large number of useless objects in \nyour local repository. They will be delete automatically by git, so it's \nnot a problem.\n\nRegard,\nEtienne\n"},{"id":"109645","messageId":"49CCE72E.20081.258EE61F@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de","threadId":"18586","inReplyTo":"49CCCB3D.8010706@drmicha.warpmail.net","subject":"Re: On git 1.6 (novice's opinion)","fromName":"Ulrich Windl","fromEmail":"ulrich.windl@rz.uni-regensburg.de","sentAt":"2009-03-27T13:48:13Z","receivedAt":"2009-03-27T13:48:13Z","isPatch":false,"sender":{"key":"ulrich.windl@rz.uni-regensburg.de","avatar":null},"body":"On 27 Mar 2009 at 13:49, Michael J Gruber wrote:\n\n> Ulrich Windl venit, vidit, dixit 27.03.2009 08:21:\n\n[...]\n\n> Keyword substitution and cvs/svn style version numbers are independent\n> issues. The sha1 describes a commit uniquely, one could use that as a\n> keyword.\n\nHowever version numbers and time stamps have the property of being at least \npartially ordered in respect of \"newer/older\". That property does not hold for \nSHA-1 checksums. Just imagine suggesting users to upgrade from Microsoft \nWord/004765c2a1e9771e886f0dbe87d4f89643cd6f70 to Microsoft \nWord/00b7e6f51130f234a969c84ee9231a5ff7fc8a82 ;-)\n\n\n> \n> Increasing version numbers are meaningless in a true DVCS world. What is\n> your 100th commit may not be someone else's, even if both your master's\n> heads are the same! This is why hg version numbers are a local thing.\n> They are merely a local shortcut for specifying a revision and serve the\n> same purpose as git's \"backward\" counts like HEAD~3 etc. Neither of them\n> work permanently, not even in a local repo, if you allow rebasing.\n\nMaybe I didn't fully understand, but having a version number that is larger than \nany parent's version numbers when doing a merge/commit doesn't look wrong to me.\n\n> \n> git rev-list HEAD|wc may produce something like it, but be sure to read\n> up on --sparse and --full-history.\n\nI'm not deep enough into it, yet.\n\n[...]\n\nRegards,\nUlrich\n"},{"id":"109648","messageId":"m3fxgz2h2n.fsf@localhost.localdomain","threadId":"18586","inReplyTo":"49CCE72E.20081.258EE61F@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de","subject":"Re: On git 1.6 (novice's opinion)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-03-27T14:09:28Z","receivedAt":"2009-03-27T14:09:28Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"\"Ulrich Windl\" <ulrich.windl@rz.uni-regensburg.de> writes:\n> On 27 Mar 2009 at 13:49, Michael J Gruber wrote: \n> > Ulrich Windl venit, vidit, dixit 27.03.2009 08:21:\n> \n> [...]\n> \n> > Keyword substitution and cvs/svn style version numbers are independent\n> > issues. The sha1 describes a commit uniquely, one could use that as a\n> > keyword.\n> \n> However version numbers and time stamps have the property of being at least \n> partially ordered in respect of \"newer/older\". That property does not hold for \n> SHA-1 checksums. Just imagine suggesting users to upgrade from Microsoft \n> Word/004765c2a1e9771e886f0dbe87d4f89643cd6f70 to Microsoft \n> Word/00b7e6f51130f234a969c84ee9231a5ff7fc8a82 ;-)\n\nThat is why people use output of git-describe and _tag_ their releases,\nand make embedding version number in released version (tarball / binary)\nthe job of make: see GIT-VERSION-GEN script in git sources, and how it\nis used in Makefile.\n\n> \n> > \n> > Increasing version numbers are meaningless in a true DVCS world. What is\n> > your 100th commit may not be someone else's, even if both your master's\n> > heads are the same! This is why hg version numbers are a local thing.\n> > They are merely a local shortcut for specifying a revision and serve the\n> > same purpose as git's \"backward\" counts like HEAD~3 etc. Neither of them\n> > work permanently, not even in a local repo, if you allow rebasing.\n> \n> Maybe I didn't fully understand, but having a version number that is larger than \n> any parent's version numbers when doing a merge/commit doesn't look wrong to me.\n\nI'm sorry to dissapoint you, but without central server assigning\nnumbers to commits it wouldn't simply work in distributed version\ncontrol world.  Take for example the following situation: somebody\nclones your repository, and creates new commit on 'master' (trunk) and\nit gets version number N.  Meanwhile you also independently create new\ncommit on 'master'... and without central authority it would also get\nversion number N.  Then you would merge (pull) his/her changes, and\nyou would have two commits with the same number; not something you want.\n\nNot to mention that you can have multiple roots (multiple commits with\nno parent) in git repository; besides independent branches (like\n'man', 'html' or 'todo') it is usually result of absorbing or\nsubtree-merging other projects.  In 'master' branch there are 5 roots\nor more: joined 'git-tools' (mailinfo / mailsplit), absorbed gitweb,\nand subtree-merged gitk and git-gui.  And here you would again have\nmultiple commits with the same number...\n\nThe idea of generation numbers was discussed on git mailing list, but\nrather as mechanism helping in faster topological ordering of commits\n(--topo-sort)... but it was dropped.\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"109681","messageId":"7veiwi5t8j.fsf@gitster.siamese.dyndns.org","threadId":"18586","inReplyTo":"49CC8C90.12268.242CEFCE@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de","subject":"Re: On git 1.6 (novice's opinion)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-03-28T01:30:36Z","receivedAt":"2009-03-28T01:30:36Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Ulrich Windl\" <ulrich.windl@rz.uni-regensburg.de> writes:\n\n> ... Also some seemingly dangerous commands that cannot easily be undone\n> should ask safety questions (\"cvs merge (-j)\" would also fall into that\n> category.\n\nThis is slightly an interesting point.\n\nIn CVS and Subversion, \"merge\" (rather \"update\") can be a dangerous\noperation.  You start working, you keep building, and you eventually\naccumulate quite a lot of changes but you still cannot see the end of the\ntunnel.  Your changes are incomplete and you will upset others if you\ncommit.  Your changes are extensive enough that it can conflict heavily\nwith what others have done already, and there is a high chance that you\ncan screw up the merging but there is no easy way (unless you tar-up the\nwhole work tree before attempting to update) to get back to the state\nbefore your merge.  Damned if you commit, damned if you don't.  You lose\neither way.\n\nThis is because you cannot have a local commit.  The problem is inherent\nto the centralized nature of these systems.\n\nDistributed systems are different.  Unlike CVS/Subversion's\n\n\twork work work; then\n\n        update to merge, risk screwing up the work in progress (or almost\n\tfinished work); then\n\n        commit\n\nworkflow, in a distributed system, you first commit and then merge,\npreferably from a clean slate.  You will not have to worry about screwing\nup the conflict resolution, because both states (what the other guy did,\nand what you did) are committed safely away and you can reset back to the\nstate before you start your merge.\n"},{"id":"109682","messageId":"7v8wmq5t8d.fsf@gitster.siamese.dyndns.org","threadId":"18586","inReplyTo":"37fcd2780903270524y39456c5fre0a2f8f9c5f4d160@mail.gmail.com","subject":"Re: On git 1.6 (novice's opinion)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-03-28T01:30:42Z","receivedAt":"2009-03-28T01:30:42Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Dmitry Potapov <dpotapov@gmail.com> writes:\n\n> On Fri, Mar 27, 2009 at 12:50 PM, Ulrich Windl\n> <ulrich.windl@rz.uni-regensburg.de> wrote:\n>>\n>> what made me wonder is this (about item 1): I thought I've read that blobs store\n>> content and attributes, so very obviously I wondered why not store thr \"right\n>> attributes\" (i.e. the time of the file). My reasoning: You make some changes, then\n>> test them (which might last several hours or days). The if I'm happy I'll\n>> \"commit\".\n>\n> With Git, you usually commit your changes immediately (without waiting\n> the result\n> of testing), because you can always undo commit until you publish your changes.\n\nHeh, \"can\" and \"usually\" are somewhat different.  I don't.\n"},{"id":"109683","messageId":"7v3acy5t86.fsf@gitster.siamese.dyndns.org","threadId":"18586","inReplyTo":"49CCE520.17260.2586E134@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de","subject":"Re: On git 1.6 (novice's opinion)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-03-28T01:30:49Z","receivedAt":"2009-03-28T01:30:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Ulrich Windl\" <ulrich.windl@rz.uni-regensburg.de> writes:\n\n> AFAIK, \"committing\" in git is \"kind of publishing your work\" (others may\n> pull it).\n\nYou, like all the other people who worked with centralized systems for too\nlong, need a break from this misconception.  Once you get rid of it, you\nwill realize that the separation of commit (which is merely \"recording so\nthat you can later refer to it, including for the purposes of going back\nto it, comparing something else with it and merge something else with it\")\nand push (which is the \"publishing\" part) is the fundamental difference\nbetween centralized and distributed systems.  It frees you from having to\nworry about the \"damned if you commit, damned if you don't\" issue I\nmentioned in my other message.\n"},{"id":"109695","messageId":"37fcd2780903280253t189bf437h2948dd451d4d2179@mail.gmail.com","threadId":"18586","inReplyTo":"7v8wmq5t8d.fsf@gitster.siamese.dyndns.org","subject":"Re: On git 1.6 (novice's opinion)","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2009-03-28T09:53:46Z","receivedAt":"2009-03-28T09:53:46Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Sat, Mar 28, 2009 at 4:30 AM, Junio C Hamano <gitster@pobox.com> wrote:\n> Dmitry Potapov <dpotapov@gmail.com> writes:\n>\n>> On Fri, Mar 27, 2009 at 12:50 PM, Ulrich Windl\n>> <ulrich.windl@rz.uni-regensburg.de> wrote:\n>>>\n>>> what made me wonder is this (about item 1): I thought I've read that blobs store\n>>> content and attributes, so very obviously I wondered why not store thr \"right\n>>> attributes\" (i.e. the time of the file). My reasoning: You make some changes, then\n>>> test them (which might last several hours or days). The if I'm happy I'll\n>>> \"commit\".\n>>\n>> With Git, you usually commit your changes immediately (without waiting\n>> the result\n>> of testing), because you can always undo commit until you publish your changes.\n>\n> Heh, \"can\" and \"usually\" are somewhat different.  I don't.\n\nFair enough. But I was refering to the situation where testing may take\nseveral hours or days. Leaving uncommitted changes in your working tree\nfor a few days is rarely a good idea if you can undo the commit later. Of\ncourse, the situation is different if the testing takes only a couple minutes.\n\nDmitry\n"},{"id":"109698","messageId":"9b18b3110903280333t1b7ec8d9x252f7e67e0753796@mail.gmail.com","threadId":"18586","inReplyTo":"49CCE72E.20081.258EE61F@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de","subject":"Re: On git 1.6 (novice's opinion)","fromName":"demerphq","fromEmail":"demerphq@gmail.com","sentAt":"2009-03-28T10:33:10Z","receivedAt":"2009-03-28T10:33:10Z","isPatch":false,"sender":{"key":"demerphq@gmail.com","avatar":null},"body":"2009/3/27 Ulrich Windl <ulrich.windl@rz.uni-regensburg.de>:\n> On 27 Mar 2009 at 13:49, Michael J Gruber wrote:\n>\n>> Ulrich Windl venit, vidit, dixit 27.03.2009 08:21:\n>\n> [...]\n>\n>> Keyword substitution and cvs/svn style version numbers are independent\n>> issues. The sha1 describes a commit uniquely, one could use that as a\n>> keyword.\n>\n> However version numbers and time stamps have the property of being at least\n> partially ordered in respect of \"newer/older\". That property does not hold for\n> SHA-1 checksums. Just imagine suggesting users to upgrade from Microsoft\n> Word/004765c2a1e9771e886f0dbe87d4f89643cd6f70 to Microsoft\n> Word/00b7e6f51130f234a969c84ee9231a5ff7fc8a82 ;-)\n\nThe problem here is that in some \"version control\" systems the concept\nof \"release version\" has been conflated with \"version control system\nrevision number\".\n\nThey arent the same thing, never were, and conflating the two only\ncaused and causes trouble.\n\nA \"release version\" is a *tag*, always has been or should have been\nreally, and in git is in fact.\n\nCheers,\nyves\n\n\n\n-- \nperl -Mre=debug -e \"/just|another|perl|hacker/\"\n"},{"id":"109749","messageId":"3e8340490903282241u355ce5b3u1a6ff23b27f4ec12@mail.gmail.com","threadId":"18586","inReplyTo":"49CC8C90.12268.242CEFCE@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de","subject":"Re: On git 1.6 (novice's opinion)","fromName":"Bryan Donlan","fromEmail":"bdonlan@gmail.com","sentAt":"2009-03-29T05:41:06Z","receivedAt":"2009-03-29T05:41:06Z","isPatch":false,"sender":{"key":"bdonlan@gmail.com","avatar":null},"body":"On Fri, Mar 27, 2009 at 3:21 AM, Ulrich Windl\n<ulrich.windl@rz.uni-regensburg.de> wrote:\n\n\n> 3) \"git undo\": If possible undo the effects of the last command.\n\nYou can roll back the state of most local references by using the git\nreflog (see git reflog --help for more information). This covers most\nsituations - but note that it only works to roll back to a committed\nstate, and won't save any uncommitted data at all.\n"},{"id":"109759","messageId":"alpine.DEB.1.00.0903291149460.10279@pacific.mpi-cbg.de","threadId":"18586","inReplyTo":"3e8340490903282241u355ce5b3u1a6ff23b27f4ec12@mail.gmail.com","subject":"Re: On git 1.6 (novice's opinion)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-03-29T09:50:14Z","receivedAt":"2009-03-29T09:50:14Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 29 Mar 2009, Bryan Donlan wrote:\n\n> On Fri, Mar 27, 2009 at 3:21 AM, Ulrich Windl\n> <ulrich.windl@rz.uni-regensburg.de> wrote:\n> \n> > 3) \"git undo\": If possible undo the effects of the last command.\n> \n> You can roll back the state of most local references by using the git \n> reflog (see git reflog --help for more information). This covers most \n> situations - but note that it only works to roll back to a committed \n> state, and won't save any uncommitted data at all.\n\nWhich is why you should commit early and often, and certainly before doing \nsomething bigger.\n\nCiao,\nDscho\n"},{"id":"109833","messageId":"f9d2a5e10903292318w6108bc50u2ddc830a6d9d85df@mail.gmail.com","threadId":"18586","inReplyTo":"49CCAF5D.21814.24B4DE63@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de","subject":"Re: On git 1.6 (novice's opinion)","fromName":"Russ Dill","fromEmail":"russ.dill@gmail.com","sentAt":"2009-03-30T06:18:54Z","receivedAt":"2009-03-30T06:18:54Z","isPatch":false,"sender":{"key":"russ.dill@gmail.com","avatar":"https://gravatar.com/avatar/989b24f3fa63126a35d7c74069e2626e715a3b1a86616be9962f7ceae04ff9c5?d=mp&s=160"},"body":"On Fri, Mar 27, 2009 at 2:50 AM, Ulrich Windl\n<ulrich.windl@rz.uni-regensburg.de> wrote:\n> On 27 Mar 2009 at 9:05, H.Merijn Brand wrote:\n>\n>> On Fri, 27 Mar 2009 08:21:36 +0100, \"Ulrich Windl\"\n>> <ulrich.windl@rz.uni-regensburg.de> wrote:\n>>\n>> > What I'd like to see in git (My apologies if some were already discussed to\n>> > death):\n>> >\n>> > 1) The ability to use the file's time at the time of add/commit instead of\n>> >    the current time, and the ability tho check outfiles with the times stored\n>> >    in the repository.\n>> >\n>> > 2) Keyword substitution. I know it's controverse (dealing with binary files),\n>> >    but I'd like to have some automatic version numbering keyword at least:\n>> >    Initial idea is that every commit with a change increments the number by\n>> >    one, and when merging numbers a and b, the resulting number is max(a, b) + 1.\n>>\n>> impossible. Even with checkin- and checkout hooks, you won't get that\n>> SCCS behaviour. They have to be better in something too :)\n>> /me still misses that but got used to it\n>\n> Hi,\n>\n> what made me wonder is this (about item 1): I thought I've read that blobs store\n> content and attributes, so very obviously I wondered why not store thr \"right\n> attributes\" (i.e. the time of the file). My reasoning: You make some changes, then\n> test them (which might last several hours or days). The if I'm happy I'll\n> \"commit\". Naturally I want to see the time of change for each file when the change\n> had been actually made, not when the change was committed. Likewise when checking\n> out, I want to be able to see the time of modification, not the time of commit.\n> I'm aware that many people don't care about such differences...\n>\n\nOk, so if Nancy did some work on the part number form 6 months ago,\nbut it got merged into master yesterday. What date should the file\nhave? This kind of incremental version number, and trusting of file\ndates really only matters on a centralized system with a single\nbranch.\n\nNot only that, but modification times are much more useful with make.\nMerging or pulling small changes into a tree shouldn't require a full\nrebuild of the entire tree which in some cases could take hours.\nEspecially since 'git log <file>', 'gitk <file>', or 'git blame\n<file>' give much more information anyway.\n\nI know some people sort their directory by date to see what kind of\nstuff happened since they last worked on the repository, but it\ndoesn't scale to a project with many directories and the log is much\nmore useful anyway.\n"},{"id":"109861","messageId":"49D08B8B.1000309@op5.se","threadId":"18586","inReplyTo":"49CC8C90.12268.242CEFCE@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de","subject":"Re: On git 1.6 (novice's opinion)","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2009-03-30T09:06:19Z","receivedAt":"2009-03-30T09:06:19Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Ulrich Windl wrote:\n> \n> 1) The ability to use the file's time at the time of add/commit instead of the\n> current time, and the ability tho check outfiles with the times stored in the\n> repository.\n> \n\nYou can set the time manually for each commit. I suppose it's not quite the\nsame as doing it by taking the timestamp of a single file. Personally, I've\nnever quite understood the point of it, since I always have to do at least\n*some* testing (even if it's only a compile-test) after I'm done editing so\nI know what I'm committing isn't totally broken.\n\nCan you describe a use-case where this would be handy?\n\n> 2) Keyword substitution. I know it's controverse (dealing with binary files),\n> but I'd like to have some automatic version numbering keyword at least:\n> Initial idea is that every commit with a change increments the number by one,\n> and when merging numbers a and b, the resulting number is max(a, b) + 1.\n> \n\nThis has been discussed to death, and it's much, much harier than just\nhandling binary files. Browse the list archives for the (many, lengthy and\nsometimes heated) discussions on this topic. A quick recap of the outcome\nof *ALL* such discussions is as follows, though:\n1 It would potentially make git horribly slow at switching branches.\n2 It's rarely interesting to version a single file, but always interesting\n  to version the entire project (what do I care if README was v1,1 in CVS\n  when what I *really* want to know is which version of the program I should\n  file my bug-report against).\n3 It's far better to set the version number in the release-process. Usually\n  this can be done automatically by one invocation of \"git describe\", just\n  as git.git does it.\n\nWe've adopted \"3\" full out at $dayjob. Our build-machinery gets the version\nnumber from the git tag (releases can only be built from signed tags), and\nit updates macros and whatnot used for informing the user which version he\nor she is running. This makes a lot more sense both from a bug-reporting\nand from a release process view than having generated version-numbers in\nfiles. On a side-note; When I told my co-workers I'd like us to switch to\ngit, two of them asked about autoversioning features. I said there weren't\nany and asked them to name a single time when we've actually used them for\nanything *at all*. In a team of eight, having been programming for three\nyears with 12 releases and about 800 bugreports + feature-requests, noone\ncould mention a single time when the autogenerated version numbers had\nactually been used for anything.\n\nOtoh, having the entire repository locally makes it painless to view the\ncommit-log for an entire project (or parts of it) and see who changed what\nwhen and why, which is information that's actually *useful*.\n\n> 3) \"git undo\": If possible undo the effects of the last command.\n> \n\nImmensely complex to create, and the command would almost certainly cause\nmore confusion than order before it can handle every single operation that\na user would want to undo. Instead, the most common operations that require\nsome form of user-interaction have an \"--abort\" switch which does roughly\nwhat a \"git undo\" command would.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n\nConsidering the successes of the wars on alcohol, poverty, drugs and\nterror, I think we should give some serious thought to declaring war\non peace.\n"},{"id":"110086","messageId":"e51f4f550903311932x118e1378yc1b25e5d9c97d50d@mail.gmail.com","threadId":"18586","inReplyTo":"49CC8C90.12268.242CEFCE@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de","subject":"Re: On git 1.6 (novice's opinion)","fromName":"Kris Shannon","fromEmail":"kris@shannon.id.au","sentAt":"2009-04-01T02:32:21Z","receivedAt":"2009-04-01T02:32:21Z","isPatch":false,"sender":{"key":"kris@shannon.id.au","avatar":"https://gravatar.com/avatar/13a7c0b3c50ffacf54f456e543023fd702898bb134165fa805f019930524151f?d=mp&s=160"},"body":"2009/3/27 Ulrich Windl <ulrich.windl@rz.uni-regensburg.de>:\n> 2) Keyword substitution. I know it's controverse (dealing with binary files),\n> but I'd like to have some automatic version numbering keyword at least:\n> Initial idea is that every commit with a change increments the number by one,\n> and when merging numbers a and b, the resulting number is max(a, b) + 1.\n\nCheck out gitattributes(5) - the ident attribute:\n\nWhen the attribute ident is set for a path, git replaces $Id$ in the blob\nobject with $Id:, followed by the 40-character hexadecimal blob object name,\nfollowed by a dollar sign $ upon checkout. Any byte sequence that begins\nwith $Id: and ends with $ in the worktree file is replaced with $Id$ upon\ncheck-in.\n\nThat means the Id is file specific, not commit specific - just like the $Id$\nexpansion for CVS and SCCS is about the file (as there is no real concept\nof a commit in CVS and SCCS)\n"},{"id":"110091","messageId":"49D329A0.10769.2C57DE@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de","threadId":"18586","inReplyTo":"vpq63hvdqs2.fsf@bauges.imag.fr","subject":"Re: On git 1.6 (novice's opinion)","fromName":"Ulrich Windl","fromEmail":"ulrich.windl@rz.uni-regensburg.de","sentAt":"2009-04-01T06:45:19Z","receivedAt":"2009-04-01T06:45:19Z","isPatch":false,"sender":{"key":"ulrich.windl@rz.uni-regensburg.de","avatar":null},"body":"On 27 Mar 2009 at 14:44, Matthieu Moy wrote:\n\n> \"Ulrich Windl\" <ulrich.windl@rz.uni-regensburg.de> writes:\n> \n> > I don't understand:\n> > If I modify files, then do a make, then do check-in/check-out (and the file times \n> > are unchanged), how would that affect make?\n> \n> From \"make\"'s point of view, chechout is just a modification of the\n> file (as any other modification you would do with a text editor). If\n> you compile foo.c to foo.o, then checkout another version of foo.c,\n> then you want foo.c to be recompiled. If checkout modifies the\n> timestamp to pretend it was modified before foo.o, then make thinks\n> the file is up to date.\n> \n> > If I do an \"update/merge from remote\" (there is no total ordering of release \n> > numbers anyway) without a \"make clean\" before, I'm having a problem\n> > anyway.\n> \n> No, you don't have a problem. Recompiling files after they're modified\n> is the job of make, and it just does it. make doesn't know about\n> revision numbers or identifiers, just timestamps.\n\nHi!\n\nIf you compiled a Linux kernel, then do an \"upgrade\" to the tree, it's quite \nlikely that a \"make clean\" after that upgrade does something different to the \n\"make clean\" before the upgrade. Thus I'd \"make clean\" before the upgrade. (which, \nI think, proves my point)\n\nRegards,\nUlrich\n"},{"id":"110092","messageId":"49D32ABF.11569.30BC41@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de","threadId":"18586","inReplyTo":"49CCD90F.6090707@gmail.com","subject":"Re: On git 1.6 (novice's opinion)","fromName":"Ulrich Windl","fromEmail":"ulrich.windl@rz.uni-regensburg.de","sentAt":"2009-04-01T06:50:07Z","receivedAt":"2009-04-01T06:50:07Z","isPatch":false,"sender":{"key":"ulrich.windl@rz.uni-regensburg.de","avatar":null},"body":"On 27 Mar 2009 at 14:47, Etienne Vallette d'Osia wrote:\n\n> Ulrich Windl a écrit :\n> > AFAIK, \"committing\" in git is \"kind of publishing your work\" (others may pull it). \n> > I don't like publishing my mistakes ;-) Even if no-one pulls the commit, your \n> > \"undo\" refers to \"committing a fix for the last committed mistake\", right? Again, \n> > I don't really want to document/archive (i.e. commit) my mistake. Or did I miss \n> > something here?\n> > I know: Other's opinions are quite different on these issues.\n> \n> commit is local.\n\nI had made the experience that you can \"pull\" from a local directory (unless \npermissions forbid it). As I can't control what others are doing, a \"commit\" is \nstill more or less making the results public (unless you can convince me that \n\tI'm wrong). OK, I grew up with servers that host hundreds of users, not with \nhaving my own laptop...\n\n> The good way is to commit in your local and private repository.\n> Then you can do anything, reset commit you have just done, etc\n> When all is ok, you push in a public repository.\n> \n> With this workflow, no one see your local work and you can commit very \n> often, undo commit, rebase a lot etc.\n> \n> The only result of a such job is a large number of useless objects in \n> your local repository. They will be delete automatically by git, so it's \n> not a problem.\n> \n> Regard,\n> Etienne\n"},{"id":"110093","messageId":"49D32CE5.21780.391D18@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de","threadId":"18586","inReplyTo":"m3fxgz2h2n.fsf@localhost.localdomain","subject":"Re: On git 1.6 (novice's opinion)","fromName":"Ulrich Windl","fromEmail":"ulrich.windl@rz.uni-regensburg.de","sentAt":"2009-04-01T06:59:16Z","receivedAt":"2009-04-01T06:59:16Z","isPatch":false,"sender":{"key":"ulrich.windl@rz.uni-regensburg.de","avatar":null},"body":"On 27 Mar 2009 at 7:09, Jakub Narebski wrote:\n\n> \"Ulrich Windl\" <ulrich.windl@rz.uni-regensburg.de> writes:\n> > On 27 Mar 2009 at 13:49, Michael J Gruber wrote: \n> > > Ulrich Windl venit, vidit, dixit 27.03.2009 08:21:\n> > \n> > [...]\n> > \n> > > Keyword substitution and cvs/svn style version numbers are independent\n> > > issues. The sha1 describes a commit uniquely, one could use that as a\n> > > keyword.\n> > \n> > However version numbers and time stamps have the property of being at least \n> > partially ordered in respect of \"newer/older\". That property does not hold for \n> > SHA-1 checksums. Just imagine suggesting users to upgrade from Microsoft \n> > Word/004765c2a1e9771e886f0dbe87d4f89643cd6f70 to Microsoft \n> > Word/00b7e6f51130f234a969c84ee9231a5ff7fc8a82 ;-)\n> \n> That is why people use output of git-describe and _tag_ their releases,\n> and make embedding version number in released version (tarball / binary)\n> the job of make: see GIT-VERSION-GEN script in git sources, and how it\n> is used in Makefile.\n\nOK, but imaginge someone sends you some file that originated from some git \nversion, maybe with minor modifications. Is there a way to find out from what git \nversion that file was derived? IMHO that's where \"automatically replaced \nplaceholders\" (like $id$) make sense.\n\n> \n> > \n> > > \n> > > Increasing version numbers are meaningless in a true DVCS world. What is\n> > > your 100th commit may not be someone else's, even if both your master's\n> > > heads are the same! This is why hg version numbers are a local thing.\n> > > They are merely a local shortcut for specifying a revision and serve the\n> > > same purpose as git's \"backward\" counts like HEAD~3 etc. Neither of them\n> > > work permanently, not even in a local repo, if you allow rebasing.\n> > \n> > Maybe I didn't fully understand, but having a version number that is larger than \n> > any parent's version numbers when doing a merge/commit doesn't look wrong to me.\n> \n> I'm sorry to dissapoint you, but without central server assigning\n> numbers to commits it wouldn't simply work in distributed version\n> control world.  Take for example the following situation: somebody\n> clones your repository, and creates new commit on 'master' (trunk) and\n> it gets version number N.  Meanwhile you also independently create new\n> commit on 'master'... and without central authority it would also get\n> version number N.  Then you would merge (pull) his/her changes, and\n> you would have two commits with the same number; not something you want.\n\nAnyway the result would have number \"N+1\". Maybe you misunderstood: I'm not \nproposing to replace git's internal version numbering (SHA-1), but so introduce \nsome more comprehensible, primitive user-level numbering.\n\n> \n> Not to mention that you can have multiple roots (multiple commits with\n> no parent) in git repository; besides independent branches (like\n> 'man', 'html' or 'todo') it is usually result of absorbing or\n> subtree-merging other projects.  In 'master' branch there are 5 roots\n> or more: joined 'git-tools' (mailinfo / mailsplit), absorbed gitweb,\n> and subtree-merged gitk and git-gui.  And here you would again have\n> multiple commits with the same number...\n\nWhich would not harm, because it would be version N from committer X. Any if \ncommitter X merges from anything else, the next number would be > N. I did not \nclaim that my method makes a total ordering of commits and merges possible.\n\nI truly believe in unique IDs, but they are just not handy in every situation.\n\n[...]\n\nRegards,\nUlrich\n"},{"id":"110094","messageId":"49D317D2.8030403@op5.se","threadId":"18586","inReplyTo":"49D32CE5.21780.391D18@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de","subject":"Re: On git 1.6 (novice's opinion)","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2009-04-01T07:29:22Z","receivedAt":"2009-04-01T07:29:22Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Ulrich Windl wrote:\n> On 27 Mar 2009 at 7:09, Jakub Narebski wrote:\n> \n>> \"Ulrich Windl\" <ulrich.windl@rz.uni-regensburg.de> writes:\n>>> On 27 Mar 2009 at 13:49, Michael J Gruber wrote: \n>>>> Ulrich Windl venit, vidit, dixit 27.03.2009 08:21:\n>>> [...]\n>>>\n>>>> Keyword substitution and cvs/svn style version numbers are independent\n>>>> issues. The sha1 describes a commit uniquely, one could use that as a\n>>>> keyword.\n>>> However version numbers and time stamps have the property of being at least \n>>> partially ordered in respect of \"newer/older\". That property does not hold for \n>>> SHA-1 checksums. Just imagine suggesting users to upgrade from Microsoft \n>>> Word/004765c2a1e9771e886f0dbe87d4f89643cd6f70 to Microsoft \n>>> Word/00b7e6f51130f234a969c84ee9231a5ff7fc8a82 ;-)\n>> That is why people use output of git-describe and _tag_ their releases,\n>> and make embedding version number in released version (tarball / binary)\n>> the job of make: see GIT-VERSION-GEN script in git sources, and how it\n>> is used in Makefile.\n> \n> OK, but imaginge someone sends you some file that originated from some git \n> version, maybe with minor modifications. Is there a way to find out from what git \n> version that file was derived? IMHO that's where \"automatically replaced \n> placeholders\" (like $id$) make sense.\n> \n\nActually, that's where communication makes sense. With the CVS style keywords,\nthat file could have come from 1.3.7, or 2.9.1 (if it hasn't changed), and\nthe bug the changes are fixing might be in some other file entirely (such as\na header file on some particular system, but the offending call could well\nbe made in some other file).\n\nIf they build from the version control system, they're most likely quite\ncompetent enough in finding the version number of the project they're using.\nIf they're building from sources, you can easily put the version number of\nthe project in every source-file you have with just a simple sed script.\nGit makes that quite easy for you. Consider something like this:\n\n--8<--8<-- release.sh --8<--8<--\n#!/bin/sh\nproject=foo\nlatest_tag=$(git describe --abbrev=0)\nversion=$(echo tag | sed 's/^v//')\ngit archive --format=tar $latest_tag --prefix=$project-$version/ | \\\n\tsed s/@@VERSION@@/$version/ | \\\n\tgzip -9 > $project-$version.tar.gz\n--8<--8<--8<--8<--\n\nNow, if you put @@VERSION@@ as the keyword in all the source-files, all\nthe files released as anything but a clone of your version control system\nwill have a version tag that marks the version of your *project* rather\nthan some arbitrary number indicating how many times that particular file\nhas been changed over the course of your project.\n\nI know which I prefer.\n\n>>>> Increasing version numbers are meaningless in a true DVCS world. What is\n>>>> your 100th commit may not be someone else's, even if both your master's\n>>>> heads are the same! This is why hg version numbers are a local thing.\n>>>> They are merely a local shortcut for specifying a revision and serve the\n>>>> same purpose as git's \"backward\" counts like HEAD~3 etc. Neither of them\n>>>> work permanently, not even in a local repo, if you allow rebasing.\n>>> Maybe I didn't fully understand, but having a version number that is larger than \n>>> any parent's version numbers when doing a merge/commit doesn't look wrong to me.\n>> I'm sorry to dissapoint you, but without central server assigning\n>> numbers to commits it wouldn't simply work in distributed version\n>> control world.  Take for example the following situation: somebody\n>> clones your repository, and creates new commit on 'master' (trunk) and\n>> it gets version number N.  Meanwhile you also independently create new\n>> commit on 'master'... and without central authority it would also get\n>> version number N.  Then you would merge (pull) his/her changes, and\n>> you would have two commits with the same number; not something you want.\n> \n> Anyway the result would have number \"N+1\". Maybe you misunderstood: I'm not \n> proposing to replace git's internal version numbering (SHA-1), but so introduce \n> some more comprehensible, primitive user-level numbering.\n> \n\nIt's been discussed to death and noone has been able to solve all the corner\ncases. If you do, feel free to send the patches. In my experience though, the\ngit notation (HEAD~3) is totally superior to any made-up version numbers.\nThis is because in 99% of the cases where you're referring to anything but\n\"latest\", you're either interested in some stable release (which should be\ntagged, so you get to pick whatever version number you want) for diffing\npurposes, or you want a *range* of commits (to send as patches, or to give\nas an indication of \"I think something happened somewhere here\"), and the\nbackward count notation of git fits that mindset a whole lot better than\nhaving numbers that increment from the start, and therefore quickly become\nas unwieldy as the SHA1's for the human brain.\n\n>> Not to mention that you can have multiple roots (multiple commits with\n>> no parent) in git repository; besides independent branches (like\n>> 'man', 'html' or 'todo') it is usually result of absorbing or\n>> subtree-merging other projects.  In 'master' branch there are 5 roots\n>> or more: joined 'git-tools' (mailinfo / mailsplit), absorbed gitweb,\n>> and subtree-merged gitk and git-gui.  And here you would again have\n>> multiple commits with the same number...\n> \n> Which would not harm, because it would be version N from committer X. Any if \n> committer X merges from anything else, the next number would be > N. I did not \n> claim that my method makes a total ordering of commits and merges possible.\n> \n> I truly believe in unique IDs, but they are just not handy in every situation.\n> \n\nWhat do they solve that the HEAD~3 syntax does not?\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n\nConsidering the successes of the wars on alcohol, poverty, drugs and\nterror, I think we should give some serious thought to declaring war\non peace.\n"},{"id":"110095","messageId":"49D33556.24356.5A16ED@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de","threadId":"18586","inReplyTo":"7veiwi5t8j.fsf@gitster.siamese.dyndns.org","subject":"Re: On git 1.6 (novice's opinion)","fromName":"Ulrich Windl","fromEmail":"ulrich.windl@rz.uni-regensburg.de","sentAt":"2009-04-01T07:35:17Z","receivedAt":"2009-04-01T07:35:17Z","isPatch":false,"sender":{"key":"ulrich.windl@rz.uni-regensburg.de","avatar":null},"body":"On 27 Mar 2009 at 18:30, Junio C Hamano wrote:\n\n> \"Ulrich Windl\" <ulrich.windl@rz.uni-regensburg.de> writes:\n> \n> > ... Also some seemingly dangerous commands that cannot easily be undone\n> > should ask safety questions (\"cvs merge (-j)\" would also fall into that\n> > category.\n> \n> This is slightly an interesting point.\n> \n> In CVS and Subversion, \"merge\" (rather \"update\") can be a dangerous\n> operation.  You start working, you keep building, and you eventually\n> accumulate quite a lot of changes but you still cannot see the end of the\n> tunnel.  Your changes are incomplete and you will upset others if you\n> commit.  Your changes are extensive enough that it can conflict heavily\n> with what others have done already, and there is a high chance that you\n> can screw up the merging but there is no easy way (unless you tar-up the\n> whole work tree before attempting to update) to get back to the state\n> before your merge.  Damned if you commit, damned if you don't.  You lose\n> either way.\n> \n> This is because you cannot have a local commit.  The problem is inherent\n> to the centralized nature of these systems.\n> \n> Distributed systems are different.  Unlike CVS/Subversion's\n> \n> \twork work work; then\n> \n>         update to merge, risk screwing up the work in progress (or almost\n> \tfinished work); then\n> \n>         commit\n> \n> workflow, in a distributed system, you first commit and then merge,\n> preferably from a clean slate.  You will not have to worry about screwing\n> up the conflict resolution, because both states (what the other guy did,\n> and what you did) are committed safely away and you can reset back to the\n> state before you start your merge.\n\nHi!\n\nOK, that example is not that dangerous in git, but git also has commands a \nbeginner could make some undesired damage (\"git rebase\", maybe).\n\nRegards,\nUlrich\n"},{"id":"110096","messageId":"49D33686.30872.5EB934@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de","threadId":"18586","inReplyTo":"3e8340490903282241u355ce5b3u1a6ff23b27f4ec12@mail.gmail.com","subject":"Re: On git 1.6 (novice's opinion)","fromName":"Ulrich Windl","fromEmail":"ulrich.windl@rz.uni-regensburg.de","sentAt":"2009-04-01T07:40:21Z","receivedAt":"2009-04-01T07:40:21Z","isPatch":false,"sender":{"key":"ulrich.windl@rz.uni-regensburg.de","avatar":null},"body":"On 29 Mar 2009 at 1:41, Bryan Donlan wrote:\n\n> On Fri, Mar 27, 2009 at 3:21 AM, Ulrich Windl\n> <ulrich.windl@rz.uni-regensburg.de> wrote:\n> \n> \n> > 3) \"git undo\": If possible undo the effects of the last command.\n> \n> You can roll back the state of most local references by using the git\n> reflog (see git reflog --help for more information). This covers most\n> situations - but note that it only works to roll back to a committed\n> state, and won't save any uncommitted data at all.\n\nHmm...kind of an idea:\n\n\"git undo <command>\" print help text on how to undo the effect of <command>.\nI feel that may be useful. maybe replace \"undo\" with \"undo-instructions\".\n\nRegards,\nUlrich\n"},{"id":"110098","messageId":"vpqhc18rfca.fsf@bauges.imag.fr","threadId":"18586","inReplyTo":"49D32ABF.11569.30BC41@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de","subject":"Re: On git 1.6 (novice's opinion)","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2009-04-01T07:41:09Z","receivedAt":"2009-04-01T07:41:09Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"\"Ulrich Windl\" <ulrich.windl@rz.uni-regensburg.de> writes:\n\n> On 27 Mar 2009 at 14:47, Etienne Vallette d'Osia wrote:\n>\n>> Ulrich Windl a écrit :\n>> > AFAIK, \"committing\" in git is \"kind of publishing your work\" (others may pull it). \n>> > I don't like publishing my mistakes ;-) Even if no-one pulls the commit, your \n>> > \"undo\" refers to \"committing a fix for the last committed mistake\", right? Again, \n>> > I don't really want to document/archive (i.e. commit) my mistake. Or did I miss \n>> > something here?\n>> > I know: Other's opinions are quite different on these issues.\n>> \n>> commit is local.\n>\n> I had made the experience that you can \"pull\" from a local directory (unless \n> permissions forbid it). As I can't control what others are doing, a \"commit\" is \n> still more or less making the results public (unless you can convince me that \n> \tI'm wrong). OK, I grew up with servers that host hundreds of users, not with \n> having my own laptop...\n\nMulti-users server, or NFS-shared $HOME, yes, expose every working\ntree and therefore directories to other users. But still, the good\npractice would be to distinguish your working area, and a \"clean\"\narea if you want to get all the power of distributed version control.\n\nOne of the main points in having version control distributed is\nprecisely to allow you to distinguish private things and published\nones (i.e. commit != push). Linus explains this better than I do in\nhis talk:\n\n  http://www.youtube.com/watch?v=4XpnKHJAok8\n\nYou _can_ expose your working tree directly to others, but if you do\nso, you'll have to forget about \"git commit --amend\", \n\"git reset <anything-else-than-HEAD>\", \"git rebase\", \n\"git filter-branch\", ... (any history-editing feature of Git indeed).\n\nOTOH, the common setup for people is to have a workstation (laptop or\ndesktop) without a public access (for example, my home computer is\nswitched of when I'm not using it, and my office station is only\nreachable from outside with ssh), and to publish things on another\nserver. So, in the common case, the distinction private/public is\nnatural.\n\n-- \nMatthieu\n"},{"id":"110099","messageId":"vpqd4bwrfa1.fsf@bauges.imag.fr","threadId":"18586","inReplyTo":"49D329A0.10769.2C57DE@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de","subject":"Re: On git 1.6 (novice's opinion)","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2009-04-01T07:42:30Z","receivedAt":"2009-04-01T07:42:30Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"\"Ulrich Windl\" <ulrich.windl@rz.uni-regensburg.de> writes:\n\n> If you compiled a Linux kernel, then do an \"upgrade\" to the tree, it's quite \n> likely that a \"make clean\" after that upgrade does something different to the \n> \"make clean\" before the upgrade. Thus I'd \"make clean\" before the upgrade. (which, \n> I think, proves my point)\n\nBut why do a \"make clean\", at all?\n\n-- \nMatthieu\n"},{"id":"110097","messageId":"49D3371C.20188.610353@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de","threadId":"18586","inReplyTo":"alpine.DEB.1.00.0903291149460.10279@pacific.mpi-cbg.de","subject":"Re: On git 1.6 (novice's opinion)","fromName":"Ulrich Windl","fromEmail":"ulrich.windl@rz.uni-regensburg.de","sentAt":"2009-04-01T07:42:51Z","receivedAt":"2009-04-01T07:42:51Z","isPatch":false,"sender":{"key":"ulrich.windl@rz.uni-regensburg.de","avatar":null},"body":"On 29 Mar 2009 at 11:50, Johannes Schindelin wrote:\n\n> Hi,\n> \n> On Sun, 29 Mar 2009, Bryan Donlan wrote:\n> \n> > On Fri, Mar 27, 2009 at 3:21 AM, Ulrich Windl\n> > <ulrich.windl@rz.uni-regensburg.de> wrote:\n> > \n> > > 3) \"git undo\": If possible undo the effects of the last command.\n> > \n> > You can roll back the state of most local references by using the git \n> > reflog (see git reflog --help for more information). This covers most \n> > situations - but note that it only works to roll back to a committed \n> > state, and won't save any uncommitted data at all.\n> \n> Which is why you should commit early and often, and certainly before doing \n> something bigger.\n\nA user will only \"commit\" if he knows how to \"undo\" it. Proposing to use \"commit\" \nto help with \"undo\" is a partial solution at best...\n\n> \n> Ciao,\n> Dscho\n> \n"},{"id":"110100","messageId":"49D339B2.4388.6B1DEF@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de","threadId":"18586","inReplyTo":"f9d2a5e10903292318w6108bc50u2ddc830a6d9d85df@mail.gmail.com","subject":"Re: On git 1.6 (novice's opinion)","fromName":"Ulrich Windl","fromEmail":"ulrich.windl@rz.uni-regensburg.de","sentAt":"2009-04-01T07:53:53Z","receivedAt":"2009-04-01T07:53:53Z","isPatch":false,"sender":{"key":"ulrich.windl@rz.uni-regensburg.de","avatar":null},"body":"On 29 Mar 2009 at 23:18, Russ Dill wrote:\n\n> On Fri, Mar 27, 2009 at 2:50 AM, Ulrich Windl\n> <ulrich.windl@rz.uni-regensburg.de> wrote:\n> > On 27 Mar 2009 at 9:05, H.Merijn Brand wrote:\n> >\n> >> On Fri, 27 Mar 2009 08:21:36 +0100, \"Ulrich Windl\"\n> >> <ulrich.windl@rz.uni-regensburg.de> wrote:\n> >>\n> >> > What I'd like to see in git (My apologies if some were already discussed to\n> >> > death):\n> >> >\n> >> > 1) The ability to use the file's time at the time of add/commit instead of\n> >> >    the current time, and the ability tho check outfiles with the times stored\n> >> >    in the repository.\n> >> >\n> >> > 2) Keyword substitution. I know it's controverse (dealing with binary files),\n> >> >    but I'd like to have some automatic version numbering keyword at least:\n> >> >    Initial idea is that every commit with a change increments the number by\n> >> >    one, and when merging numbers a and b, the resulting number is max(a, b) + 1.\n> >>\n> >> impossible. Even with checkin- and checkout hooks, you won't get that\n> >> SCCS behaviour. They have to be better in something too :)\n> >> /me still misses that but got used to it\n> >\n> > Hi,\n> >\n> > what made me wonder is this (about item 1): I thought I've read that blobs store\n> > content and attributes, so very obviously I wondered why not store thr \"right\n> > attributes\" (i.e. the time of the file). My reasoning: You make some changes, then\n> > test them (which might last several hours or days). The if I'm happy I'll\n> > \"commit\". Naturally I want to see the time of change for each file when the change\n> > had been actually made, not when the change was committed. Likewise when checking\n> > out, I want to be able to see the time of modification, not the time of commit.\n> > I'm aware that many people don't care about such differences...\n> >\n> \n> Ok, so if Nancy did some work on the part number form 6 months ago,\n> but it got merged into master yesterday. What date should the file\n> have? This kind of incremental version number, and trusting of file\n\nIf Nancy committed it with my semantics, the file's date would be 6 months old \nbefore the merge. If the merge would not require any change, the file's date would \nstill be six months old. If a change was required, the file's date would be the \ntime of change. That sounds quite logical to me.\n\n> dates really only matters on a centralized system with a single\n> branch.\n> \n> Not only that, but modification times are much more useful with make.\n> Merging or pulling small changes into a tree shouldn't require a full\n> rebuild of the entire tree which in some cases could take hours.\n\nGit is not a build system, and I really dislike \"full rebuilds\", but for \nstability, before releasing anything, one should test it with a full rebuild. I \nthink that's what configuration management systems are about. So for a merge or \ncheckout of any make source object (opposed to: make target object), an automated \ncleanup of the corresponding target objects should be made. I know that you don't \nlike it, but for RCS you have the couce whether to check-in with \"-d\", or check \nout with \"-M\". If it's optional in GIT also, you shouldn't be unhappy.\n\n> Especially since 'git log <file>', 'gitk <file>', or 'git blame\n> <file>' give much more information anyway.\n> \n> I know some people sort their directory by date to see what kind of\n> stuff happened since they last worked on the repository, but it\n> doesn't scale to a project with many directories and the log is much\n> more useful anyway.\n\nI agree.\n\nRegards,\nUlrich\n"},{"id":"110102","messageId":"vpq63horepl.fsf@bauges.imag.fr","threadId":"18586","inReplyTo":"49D32CE5.21780.391D18@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de","subject":"Re: On git 1.6 (novice's opinion)","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2009-04-01T07:54:46Z","receivedAt":"2009-04-01T07:54:46Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"\"Ulrich Windl\" <ulrich.windl@rz.uni-regensburg.de> writes:\n\n>> Not to mention that you can have multiple roots (multiple commits with\n>> no parent) in git repository; besides independent branches (like\n>> 'man', 'html' or 'todo') it is usually result of absorbing or\n>> subtree-merging other projects.  In 'master' branch there are 5 roots\n>> or more: joined 'git-tools' (mailinfo / mailsplit), absorbed gitweb,\n>> and subtree-merged gitk and git-gui.  And here you would again have\n>> multiple commits with the same number...\n>\n> Which would not harm, because it would be version N from committer X. Any if \n> committer X merges from anything else, the next number would be > N. I did not \n> claim that my method makes a total ordering of commits and merges possible.\n\nNeither does it make the numbers unique for committer X.\n\nIf commiter X commits a successor to commit N, it's labeled N+1. If\nlater, he creates another branch from commit N, and commit, the new,\nother commit will be labeled N+1.\n\nThis means even within a repository, you cannot say things like\n\"commit number N\", so, OK, you have numerical IDs, but you can't use\nthem.\n\nWhat can be interesting is that a commit takes \nmax{all commits in repository}+1, not just max{parents} + 1. Then, you\nhave local revision numbers, but they're not stable. Indeed, that's\nprecisely what Mercurial does.\n\nBut I'm not sure how much simplicity it adds compared to the confusion\nit adds. Newbies will see Mercurial identifiers as\n\nchangeset:   2:699b81a5851b\nchangeset:   1:fd4b6597548f\nchangeset:   0:58cff172192e\n\nAnd think \"OK, the revision numbers are 0, 1, 2, and the hexadecimal\nstuff beside is useless\". And one day, he'll send a mail, post a\nbugreport, or whatever, saying \"I have a problem with revision number\n42\", and no one else but him will know which revision is called \"42\".\n\n> I truly believe in unique IDs, but they are just not handy in every situation.\n\nUsually, people find Git IDs to be non-handy until the find out they\ncan cut-and-paste only the first few digits in most cases, like\n442dd42 instead of 442dd42d6d4903640b0dc5561481a77c88dcea90 ;-).\n\n-- \nMatthieu\n"},{"id":"110103","messageId":"49D33EC0.29775.7EDC13@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de","threadId":"18586","inReplyTo":"49D08B8B.1000309@op5.se","subject":"Re: On git 1.6 (novice's opinion)","fromName":"Ulrich Windl","fromEmail":"ulrich.windl@rz.uni-regensburg.de","sentAt":"2009-04-01T08:15:27Z","receivedAt":"2009-04-01T08:15:27Z","isPatch":false,"sender":{"key":"ulrich.windl@rz.uni-regensburg.de","avatar":null},"body":"On 30 Mar 2009 at 11:06, Andreas Ericsson wrote:\n\n[...]\n> 3 It's far better to set the version number in the release-process. Usually\n>   this can be done automatically by one invocation of \"git describe\", just\n>   as git.git does it.\n\nHowever if you put a version number into every file and THEN commit, it's somewhat \nridiculous (I'll have to learn about \"git describe\"). But for configuration \nmanagement you want to have exactly that (find exactly the file that was shipped \n(or used to build)).\n\n> \n> We've adopted \"3\" full out at $dayjob. Our build-machinery gets the version\n> number from the git tag (releases can only be built from signed tags), and\n> it updates macros and whatnot used for informing the user which version he\n> or she is running. This makes a lot more sense both from a bug-reporting\n> and from a release process view than having generated version-numbers in\n\nSo your \"release commits\" are outside GIT? (see above)\n\n> files. On a side-note; When I told my co-workers I'd like us to switch to\n> git, two of them asked about autoversioning features. I said there weren't\n> any and asked them to name a single time when we've actually used them for\n> anything *at all*. In a team of eight, having been programming for three\n> years with 12 releases and about 800 bugreports + feature-requests, noone\n> could mention a single time when the autogenerated version numbers had\n> actually been used for anything.\n\nHmm: Were they visible to customers?\n\n> \n> Otoh, having the entire repository locally makes it painless to view the\n> commit-log for an entire project (or parts of it) and see who changed what\n> when and why, which is information that's actually *useful*.\n\n[Big meals need time to digest: Just give me more time to do so (getting into \ngit). As with vi and Emacs (usualy I prefer Emacs), there will be situations when \nI won't use Git however]\n\nRegards,\nUlrich\n"},{"id":"110106","messageId":"49D327C4.7000101@op5.se","threadId":"18586","inReplyTo":"49D339B2.4388.6B1DEF@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de","subject":"Re: On git 1.6 (novice's opinion)","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2009-04-01T08:37:24Z","receivedAt":"2009-04-01T08:37:24Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Ulrich Windl wrote:\n> On 29 Mar 2009 at 23:18, Russ Dill wrote:\n> \n>> On Fri, Mar 27, 2009 at 2:50 AM, Ulrich Windl\n>> <ulrich.windl@rz.uni-regensburg.de> wrote:\n>>> On 27 Mar 2009 at 9:05, H.Merijn Brand wrote:\n>>>\n>>>> On Fri, 27 Mar 2009 08:21:36 +0100, \"Ulrich Windl\"\n>>>> <ulrich.windl@rz.uni-regensburg.de> wrote:\n>>>>\n>>>>> What I'd like to see in git (My apologies if some were already discussed to\n>>>>> death):\n>>>>>\n>>>>> 1) The ability to use the file's time at the time of add/commit instead of\n>>>>>    the current time, and the ability tho check outfiles with the times stored\n>>>>>    in the repository.\n>>>>>\n>>>>> 2) Keyword substitution. I know it's controverse (dealing with binary files),\n>>>>>    but I'd like to have some automatic version numbering keyword at least:\n>>>>>    Initial idea is that every commit with a change increments the number by\n>>>>>    one, and when merging numbers a and b, the resulting number is max(a, b) + 1.\n>>>> impossible. Even with checkin- and checkout hooks, you won't get that\n>>>> SCCS behaviour. They have to be better in something too :)\n>>>> /me still misses that but got used to it\n>>> Hi,\n>>>\n>>> what made me wonder is this (about item 1): I thought I've read that blobs store\n>>> content and attributes, so very obviously I wondered why not store thr \"right\n>>> attributes\" (i.e. the time of the file). My reasoning: You make some changes, then\n>>> test them (which might last several hours or days). The if I'm happy I'll\n>>> \"commit\". Naturally I want to see the time of change for each file when the change\n>>> had been actually made, not when the change was committed. Likewise when checking\n>>> out, I want to be able to see the time of modification, not the time of commit.\n>>> I'm aware that many people don't care about such differences...\n>>>\n>> Ok, so if Nancy did some work on the part number form 6 months ago,\n>> but it got merged into master yesterday. What date should the file\n>> have? This kind of incremental version number, and trusting of file\n> \n> If Nancy committed it with my semantics, the file's date would be 6 months old \n> before the merge. If the merge would not require any change, the file's date would \n> still be six months old. If a change was required, the file's date would be the \n> time of change. That sounds quite logical to me.\n> \n\nBut if you built the old source before you merged but after Nancy made her\nchanges, make wouldn't grok that the file is actually changed. Trust me,\nthe current semantics are far better.\n\n>> dates really only matters on a centralized system with a single\n>> branch.\n>>\n>> Not only that, but modification times are much more useful with make.\n>> Merging or pulling small changes into a tree shouldn't require a full\n>> rebuild of the entire tree which in some cases could take hours.\n> \n> Git is not a build system, and I really dislike \"full rebuilds\", but for \n> stability, before releasing anything, one should test it with a full rebuild.\n\nI build all the time. Before and after every commit (merges are one type of\ncommit). I rely on file timestamps to be an accurate indicator of when the\nfile last changed *on my disk*.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n\nConsidering the successes of the wars on alcohol, poverty, drugs and\nterror, I think we should give some serious thought to declaring war\non peace.\n"},{"id":"110107","messageId":"49D328C2.4000006@op5.se","threadId":"18586","inReplyTo":"49D33EC0.29775.7EDC13@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de","subject":"Re: On git 1.6 (novice's opinion)","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2009-04-01T08:41:38Z","receivedAt":"2009-04-01T08:41:38Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Ulrich Windl wrote:\n> On 30 Mar 2009 at 11:06, Andreas Ericsson wrote:\n> \n> [...]\n>> 3 It's far better to set the version number in the release-process. Usually\n>>   this can be done automatically by one invocation of \"git describe\", just\n>>   as git.git does it.\n> \n> However if you put a version number into every file and THEN commit, it's somewhat \n> ridiculous (I'll have to learn about \"git describe\"). But for configuration \n> management you want to have exactly that (find exactly the file that was shipped \n> (or used to build)).\n> \n>> We've adopted \"3\" full out at $dayjob. Our build-machinery gets the version\n>> number from the git tag (releases can only be built from signed tags), and\n>> it updates macros and whatnot used for informing the user which version he\n>> or she is running. This makes a lot more sense both from a bug-reporting\n>> and from a release process view than having generated version-numbers in\n> \n> So your \"release commits\" are outside GIT? (see above)\n> \n\nThey aren't release commits. Just a script that creates a tarball and an RPM\n(in our case).\n\n>> files. On a side-note; When I told my co-workers I'd like us to switch to\n>> git, two of them asked about autoversioning features. I said there weren't\n>> any and asked them to name a single time when we've actually used them for\n>> anything *at all*. In a team of eight, having been programming for three\n>> years with 12 releases and about 800 bugreports + feature-requests, noone\n>> could mention a single time when the autogenerated version numbers had\n>> actually been used for anything.\n> \n> Hmm: Were they visible to customers?\n> \n\nOfcourse they were, but they were rather useless even there, as a customer\ncould upgrade and the $Id$ tag still wouldn't get updated. It caused a lot\nof confusion for our not-so-techsavvy users and customers.\n\n>> Otoh, having the entire repository locally makes it painless to view the\n>> commit-log for an entire project (or parts of it) and see who changed what\n>> when and why, which is information that's actually *useful*.\n> \n> [Big meals need time to digest: Just give me more time to do so (getting into \n> git). As with vi and Emacs (usualy I prefer Emacs), there will be situations when \n> I won't use Git however]\n> \n\nTake all the time you need. It's a paradigm-shift, because the information you\nthought you needed is made obsolete by the information you *actually* need.\nWrapping ones head around the fact that one's been wrong for several years takes\na little time ;-)\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n\nConsidering the successes of the wars on alcohol, poverty, drugs and\nterror, I think we should give some serious thought to declaring war\non peace.\n"},{"id":"110110","messageId":"49D35254.4137.CB56FE@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de","threadId":"18586","inReplyTo":"vpq63horepl.fsf@bauges.imag.fr","subject":"Re: On git 1.6 (novice's opinion)","fromName":"Ulrich Windl","fromEmail":"ulrich.windl@rz.uni-regensburg.de","sentAt":"2009-04-01T09:38:59Z","receivedAt":"2009-04-01T09:38:59Z","isPatch":false,"sender":{"key":"ulrich.windl@rz.uni-regensburg.de","avatar":null},"body":"On 1 Apr 2009 at 9:54, Matthieu Moy wrote:\n\n> \"Ulrich Windl\" <ulrich.windl@rz.uni-regensburg.de> writes:\n> \n> >> Not to mention that you can have multiple roots (multiple commits with\n> >> no parent) in git repository; besides independent branches (like\n> >> 'man', 'html' or 'todo') it is usually result of absorbing or\n> >> subtree-merging other projects.  In 'master' branch there are 5 roots\n> >> or more: joined 'git-tools' (mailinfo / mailsplit), absorbed gitweb,\n> >> and subtree-merged gitk and git-gui.  And here you would again have\n> >> multiple commits with the same number...\n> >\n> > Which would not harm, because it would be version N from committer X. Any if \n> > committer X merges from anything else, the next number would be > N. I did not \n> > claim that my method makes a total ordering of commits and merges possible.\n> \n> Neither does it make the numbers unique for committer X.\n> \n> If commiter X commits a successor to commit N, it's labeled N+1. If\n> later, he creates another branch from commit N, and commit, the new,\n> other commit will be labeled N+1.\n\nCorrect: They live in a parallel universe. But on the long term they will either \nvanish or be merged in which case the number will be \"> N+1\" (on the main branch). \nSo we have a branch plus a sequence number all the time.\n\n> \n> This means even within a repository, you cannot say things like\n> \"commit number N\", so, OK, you have numerical IDs, but you can't use\n> them.\n\nI never wanted to have such a thing (using those numbers for commit).\n\n> \n> What can be interesting is that a commit takes \n> max{all commits in repository}+1, not just max{parents} + 1. Then, you\n> have local revision numbers, but they're not stable. Indeed, that's\n> precisely what Mercurial does.\n\nThat would be a (temporary) total ordering, which I did not want, exactly for that \nreason.\n\n[I did not intend the following use case]\n\nUlrich\n\n> \n> But I'm not sure how much simplicity it adds compared to the confusion\n> it adds. Newbies will see Mercurial identifiers as\n> \n> changeset:   2:699b81a5851b\n> changeset:   1:fd4b6597548f\n> changeset:   0:58cff172192e\n> \n> And think \"OK, the revision numbers are 0, 1, 2, and the hexadecimal\n> stuff beside is useless\". And one day, he'll send a mail, post a\n> bugreport, or whatever, saying \"I have a problem with revision number\n> 42\", and no one else but him will know which revision is called \"42\".\n> \n> > I truly believe in unique IDs, but they are just not handy in every situation.\n> \n> Usually, people find Git IDs to be non-handy until the find out they\n> can cut-and-paste only the first few digits in most cases, like\n> 442dd42 instead of 442dd42d6d4903640b0dc5561481a77c88dcea90 ;-).\n> \n> -- \n> Matthieu\n"},{"id":"110111","messageId":"49D35454.12423.D32681@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de","threadId":"18586","inReplyTo":"49D327C4.7000101@op5.se","subject":"Re: On git 1.6 (novice's opinion)","fromName":"Ulrich Windl","fromEmail":"ulrich.windl@rz.uni-regensburg.de","sentAt":"2009-04-01T09:47:31Z","receivedAt":"2009-04-01T09:47:31Z","isPatch":false,"sender":{"key":"ulrich.windl@rz.uni-regensburg.de","avatar":null},"body":"On 1 Apr 2009 at 10:37, Andreas Ericsson wrote:\n\n> >> Not only that, but modification times are much more useful with make.\n> >> Merging or pulling small changes into a tree shouldn't require a full\n> >> rebuild of the entire tree which in some cases could take hours.\n> > \n> > Git is not a build system, and I really dislike \"full rebuilds\", but for \n> > stability, before releasing anything, one should test it with a full rebuild.\n> \n> I build all the time. Before and after every commit (merges are one type of\n> commit). I rely on file timestamps to be an accurate indicator of when the\n> file last changed *on my disk*.\n> \n\nBut you are silently assuming that the make files are correct: If a file is not \nbeing rebuilt, you might be using an old compile without noticing. There a full \nrecompile will at least 1) either trigger an error (missing object file) or 2) \nbuild every file. So I really don't see that relying on file dates is much better \nthan doing a full rebuild. That's specifically true if you pull a new tree: If I \nunderstand things right, EVERY file will have a current date, so you'll rebuild \neverything anyway. So you could also have the \"real file dates\" and then do \"make \nclean; make all\". I see no benefit from either approach.\n\nRegards,\nUlrich\n"},{"id":"110113","messageId":"49D35616.1812.DA02BA@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de","threadId":"18586","inReplyTo":"49D328C2.4000006@op5.se","subject":"Re: On git 1.6 (novice's opinion)","fromName":"Ulrich Windl","fromEmail":"ulrich.windl@rz.uni-regensburg.de","sentAt":"2009-04-01T09:55:01Z","receivedAt":"2009-04-01T09:55:01Z","isPatch":false,"sender":{"key":"ulrich.windl@rz.uni-regensburg.de","avatar":null},"body":"On 1 Apr 2009 at 10:41, Andreas Ericsson wrote:\n\n> Ulrich Windl wrote:\n> > On 30 Mar 2009 at 11:06, Andreas Ericsson wrote:\n> > \n> > [...]\n> >> 3 It's far better to set the version number in the release-process. Usually\n> >>   this can be done automatically by one invocation of \"git describe\", just\n> >>   as git.git does it.\n> > \n> > However if you put a version number into every file and THEN commit, it's somewhat \n> > ridiculous (I'll have to learn about \"git describe\"). But for configuration \n> > management you want to have exactly that (find exactly the file that was shipped \n> > (or used to build)).\n> > \n> >> We've adopted \"3\" full out at $dayjob. Our build-machinery gets the version\n> >> number from the git tag (releases can only be built from signed tags), and\n> >> it updates macros and whatnot used for informing the user which version he\n> >> or she is running. This makes a lot more sense both from a bug-reporting\n> >> and from a release process view than having generated version-numbers in\n> > \n> > So your \"release commits\" are outside GIT? (see above)\n> > \n> \n> They aren't release commits. Just a script that creates a tarball and an RPM\n> (in our case).\n\nOK, that's what I did with CVS also, but with \"CVS diff\" I see the revision \nnumbers (old and new) for every single file in a patch, while Git just uses \"a\" \nand \"b\". There I'd still prefer what CVS does.\n\n> \n> >> files. On a side-note; When I told my co-workers I'd like us to switch to\n> >> git, two of them asked about autoversioning features. I said there weren't\n> >> any and asked them to name a single time when we've actually used them for\n> >> anything *at all*. In a team of eight, having been programming for three\n> >> years with 12 releases and about 800 bugreports + feature-requests, noone\n> >> could mention a single time when the autogenerated version numbers had\n> >> actually been used for anything.\n> > \n> > Hmm: Were they visible to customers?\n> > \n> \n> Ofcourse they were, but they were rather useless even there, as a customer\n> could upgrade and the $Id$ tag still wouldn't get updated. It caused a lot\n> of confusion for our not-so-techsavvy users and customers.\n\nWhat I don't understand here is: Why wouldn't the $Id$ be updated upon upgrade? \nBecause it's a manual process?\n\n[...]\n\nRegards,\nUlrich\n"},{"id":"110114","messageId":"49D33D7C.1080200@op5.com","threadId":"18586","inReplyTo":"49D35254.4137.CB56FE@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de","subject":"Re: On git 1.6 (novice's opinion)","fromName":"Andreas Ericsson","fromEmail":"exon@op5.com","sentAt":"2009-04-01T10:10:04Z","receivedAt":"2009-04-01T10:10:04Z","isPatch":false,"sender":{"key":"exon@op5.com","avatar":null},"body":"Ulrich Windl wrote:\n> On 1 Apr 2009 at 9:54, Matthieu Moy wrote:\n> \n>> \"Ulrich Windl\" <ulrich.windl@rz.uni-regensburg.de> writes:\n>>\n>>>> Not to mention that you can have multiple roots (multiple commits with\n>>>> no parent) in git repository; besides independent branches (like\n>>>> 'man', 'html' or 'todo') it is usually result of absorbing or\n>>>> subtree-merging other projects.  In 'master' branch there are 5 roots\n>>>> or more: joined 'git-tools' (mailinfo / mailsplit), absorbed gitweb,\n>>>> and subtree-merged gitk and git-gui.  And here you would again have\n>>>> multiple commits with the same number...\n>>> Which would not harm, because it would be version N from committer X. Any if \n>>> committer X merges from anything else, the next number would be > N. I did not \n>>> claim that my method makes a total ordering of commits and merges possible.\n>> Neither does it make the numbers unique for committer X.\n>>\n>> If commiter X commits a successor to commit N, it's labeled N+1. If\n>> later, he creates another branch from commit N, and commit, the new,\n>> other commit will be labeled N+1.\n> \n> Correct: They live in a parallel universe. But on the long term they will either \n> vanish or be merged in which case the number will be \"> N+1\" (on the main branch). \n> So we have a branch plus a sequence number all the time.\n> \n>> This means even within a repository, you cannot say things like\n>> \"commit number N\", so, OK, you have numerical IDs, but you can't use\n>> them.\n> \n> I never wanted to have such a thing (using those numbers for commit).\n> \n\nIf you weren't going to use them for commits, what use are they at all?\n\nI think you need to show us at least one use-case where this would\nbe beneficial *at all* before anyone is going to take this suggestion\nseriously (this time around; It's been dropped on the floor numerous\ntimes before when those original posters came to their senses).\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n\nConsidering the successes of the wars on alcohol, poverty, drugs and\nterror, I think we should give some serious thought to declaring war\non peace.\n"},{"id":"110116","messageId":"49D33F31.80605@op5.com","threadId":"18586","inReplyTo":"49D35454.12423.D32681@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de","subject":"Re: On git 1.6 (novice's opinion)","fromName":"Andreas Ericsson","fromEmail":"exon@op5.com","sentAt":"2009-04-01T10:17:21Z","receivedAt":"2009-04-01T10:17:21Z","isPatch":false,"sender":{"key":"exon@op5.com","avatar":null},"body":"Ulrich Windl wrote:\n> On 1 Apr 2009 at 10:37, Andreas Ericsson wrote:\n> \n>>>> Not only that, but modification times are much more useful with make.\n>>>> Merging or pulling small changes into a tree shouldn't require a full\n>>>> rebuild of the entire tree which in some cases could take hours.\n>>> Git is not a build system, and I really dislike \"full rebuilds\", but for \n>>> stability, before releasing anything, one should test it with a full rebuild.\n>> I build all the time. Before and after every commit (merges are one type of\n>> commit). I rely on file timestamps to be an accurate indicator of when the\n>> file last changed *on my disk*.\n>>\n> \n> But you are silently assuming that the make files are correct: If a file is not \n> being rebuilt, you might be using an old compile without noticing. There a full \n> recompile will at least 1) either trigger an error (missing object file) or 2) \n> build every file. So I really don't see that relying on file dates is much better \n> than doing a full rebuild. That's specifically true if you pull a new tree: If I \n> understand things right, EVERY file will have a current date, so you'll rebuild \n> everything anyway. So you could also have the \"real file dates\" and then do \"make \n> clean; make all\". I see no benefit from either approach.\n> \n\nYou'll see the benefit of not rebuilding everything when your projects start\nspanning more than 30k lines. Buildtesting a subsystem of the linux kernel\nwould be a major pain if object files weren't kept around from previous builds,\nand integration-testing the hundreds (sometimes) of feature-branches would be\ncompletely impossible if timestamps on files weren't updated when files change\non disk.\n\nIncidentally, we do full rebuilds too, but no developer sits around watching\nthem. They're handled by our (stupid but efficient) homegrown CI-solution,\nwhich emails the results to the devs. This happens every push though, not\nevery commit, but in our rather tight environment at $dayjob we push\nfrequently enough for that not to be a problem.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n\nConsidering the successes of the wars on alcohol, poverty, drugs and\nterror, I think we should give some serious thought to declaring war\non peace.\n"},{"id":"110117","messageId":"49D34015.9080709@op5.com","threadId":"18586","inReplyTo":"49D35616.1812.DA02BA@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de","subject":"Re: On git 1.6 (novice's opinion)","fromName":"Andreas Ericsson","fromEmail":"exon@op5.com","sentAt":"2009-04-01T10:21:09Z","receivedAt":"2009-04-01T10:21:09Z","isPatch":false,"sender":{"key":"exon@op5.com","avatar":null},"body":"Ulrich Windl wrote:\n> On 1 Apr 2009 at 10:41, Andreas Ericsson wrote:\n> \n>> Ulrich Windl wrote:\n>>> On 30 Mar 2009 at 11:06, Andreas Ericsson wrote:\n>>>\n>>> [...]\n>>>> 3 It's far better to set the version number in the release-process. Usually\n>>>>   this can be done automatically by one invocation of \"git describe\", just\n>>>>   as git.git does it.\n>>> However if you put a version number into every file and THEN commit, it's somewhat \n>>> ridiculous (I'll have to learn about \"git describe\"). But for configuration \n>>> management you want to have exactly that (find exactly the file that was shipped \n>>> (or used to build)).\n>>>\n>>>> We've adopted \"3\" full out at $dayjob. Our build-machinery gets the version\n>>>> number from the git tag (releases can only be built from signed tags), and\n>>>> it updates macros and whatnot used for informing the user which version he\n>>>> or she is running. This makes a lot more sense both from a bug-reporting\n>>>> and from a release process view than having generated version-numbers in\n>>> So your \"release commits\" are outside GIT? (see above)\n>>>\n>> They aren't release commits. Just a script that creates a tarball and an RPM\n>> (in our case).\n> \n> OK, that's what I did with CVS also, but with \"CVS diff\" I see the revision \n> numbers (old and new) for every single file in a patch, while Git just uses \"a\" \n> and \"b\". There I'd still prefer what CVS does.\n> \n>>>> files. On a side-note; When I told my co-workers I'd like us to switch to\n>>>> git, two of them asked about autoversioning features. I said there weren't\n>>>> any and asked them to name a single time when we've actually used them for\n>>>> anything *at all*. In a team of eight, having been programming for three\n>>>> years with 12 releases and about 800 bugreports + feature-requests, noone\n>>>> could mention a single time when the autogenerated version numbers had\n>>>> actually been used for anything.\n>>> Hmm: Were they visible to customers?\n>>>\n>> Ofcourse they were, but they were rather useless even there, as a customer\n>> could upgrade and the $Id$ tag still wouldn't get updated. It caused a lot\n>> of confusion for our not-so-techsavvy users and customers.\n> \n> What I don't understand here is: Why wouldn't the $Id$ be updated upon upgrade? \n> Because it's a manual process?\n> \n\nIt MAY not get updated, since $Id$ tags are per-file instead of per-project.\nAny sane project will have more than one file, and the file listing the\n$Id$ that the end-user sees may not have changed since the last release.\n\nPer-file revision tags are stupid and useless for anything but a one-file\nproject.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n\nConsidering the successes of the wars on alcohol, poverty, drugs and\nterror, I think we should give some serious thought to declaring war\non peace.\n"},{"id":"110122","messageId":"49D37190.23422.145597D@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de","threadId":"18586","inReplyTo":"49D34015.9080709@op5.com","subject":"Re: On git 1.6 (novice's opinion)","fromName":"Ulrich Windl","fromEmail":"ulrich.windl@rz.uni-regensburg.de","sentAt":"2009-04-01T11:52:15Z","receivedAt":"2009-04-01T11:52:15Z","isPatch":false,"sender":{"key":"ulrich.windl@rz.uni-regensburg.de","avatar":null},"body":"On 1 Apr 2009 at 12:21, Andreas Ericsson wrote:\n\n[...]\n> > What I don't understand here is: Why wouldn't the $Id$ be updated upon upgrade? \n> > Because it's a manual process?\n> > \n> \n> It MAY not get updated, since $Id$ tags are per-file instead of per-project.\n> Any sane project will have more than one file, and the file listing the\n> $Id$ that the end-user sees may not have changed since the last release.\n> \n> Per-file revision tags are stupid and useless for anything but a one-file\n> project.\n\nHmm...:\n# what vmunix\nvmunix:\n         ivt.s $Date: 2008/11/21 09:10:19 $Revision: r11.31/5 PATCH_11.31 (B11.3\n1.0903LR)\n         side_dumpdev - HP IDE Dump Driver B.11.31 /ux/core/kern/em/svc/dump/scs\ni_ide_dumpdev.c: Jan  8 2009, 23:48:25\n         eschgr - Changer Driver B.11.31.01 /ux/core/kern/common/io/escsi/eschgr\n/eschgr.c:Jan 10 2007,17:04:47\n         eschgr - Changer Driver B.11.31.01 /ux/core/kern/common/io/escsi/eschgr\n/eschgr_diag.c:Dec 27 2006,16:59:17\n[...]\n        vxfs:$RCSfile: vx_portal.c,v $  $Revision: 4.14.26.3 $\n        vxfs:$RCSfile: vx_portal_osrel.c,v $    $Revision: 1.1.2.1 $\n        vxfs:$RCSfile: vx_portal_dlkm.c,v $     $Revision: 1.1.2.1 $\n        vxfs:$RCSfile: vxportal50.modmeta,v $   $Revision: 1.1.2.5 $\n         wsio_cdio.c $Date: 2008/06/03 05:52:50 $Revision: r11.31/13 PATCH_11.31\n (B11.31.0809LR)\n         $Revision: wsio:    B11.31.0809LR\n         $Revision: wxb_hp:    B.11.31_LR\n         tracer.s $Date: 2008/04/28 17:14:06 $Revision: r11.31/3 PATCH_11.31 (B1\n1.31.0809LR)\n\nFor a kernel, where development is decentralized, it would make sense: Imageine a \nuser (or distributor) will nut upgrade anything to the latest version, but only \nparts (subsystems). Then the single kernel version number is meaningless.\n\nRegards,\nUlrich\n"},{"id":"110128","messageId":"49D360BE.6030100@op5.com","threadId":"18586","inReplyTo":"49D37190.23422.145597D@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de","subject":"Re: On git 1.6 (novice's opinion)","fromName":"Andreas Ericsson","fromEmail":"exon@op5.com","sentAt":"2009-04-01T12:40:30Z","receivedAt":"2009-04-01T12:40:30Z","isPatch":false,"sender":{"key":"exon@op5.com","avatar":null},"body":"Ulrich Windl wrote:\n> On 1 Apr 2009 at 12:21, Andreas Ericsson wrote:\n> \n> [...]\n>>> What I don't understand here is: Why wouldn't the $Id$ be updated upon upgrade? \n>>> Because it's a manual process?\n>>>\n>> It MAY not get updated, since $Id$ tags are per-file instead of per-project.\n>> Any sane project will have more than one file, and the file listing the\n>> $Id$ that the end-user sees may not have changed since the last release.\n>>\n>> Per-file revision tags are stupid and useless for anything but a one-file\n>> project.\n> \n> Hmm...:\n> # what vmunix\n> vmunix:\n>          ivt.s $Date: 2008/11/21 09:10:19 $Revision: r11.31/5 PATCH_11.31 (B11.3\n> 1.0903LR)\n>          side_dumpdev - HP IDE Dump Driver B.11.31 /ux/core/kern/em/svc/dump/scs\n> i_ide_dumpdev.c: Jan  8 2009, 23:48:25\n>          eschgr - Changer Driver B.11.31.01 /ux/core/kern/common/io/escsi/eschgr\n> /eschgr.c:Jan 10 2007,17:04:47\n>          eschgr - Changer Driver B.11.31.01 /ux/core/kern/common/io/escsi/eschgr\n> /eschgr_diag.c:Dec 27 2006,16:59:17\n> [...]\n>         vxfs:$RCSfile: vx_portal.c,v $  $Revision: 4.14.26.3 $\n>         vxfs:$RCSfile: vx_portal_osrel.c,v $    $Revision: 1.1.2.1 $\n>         vxfs:$RCSfile: vx_portal_dlkm.c,v $     $Revision: 1.1.2.1 $\n>         vxfs:$RCSfile: vxportal50.modmeta,v $   $Revision: 1.1.2.5 $\n>          wsio_cdio.c $Date: 2008/06/03 05:52:50 $Revision: r11.31/13 PATCH_11.31\n>  (B11.31.0809LR)\n>          $Revision: wsio:    B11.31.0809LR\n>          $Revision: wxb_hp:    B.11.31_LR\n>          tracer.s $Date: 2008/04/28 17:14:06 $Revision: r11.31/3 PATCH_11.31 (B1\n> 1.31.0809LR)\n> \n> For a kernel, where development is decentralized, it would make sense: Imageine a \n> user (or distributor) will nut upgrade anything to the latest version, but only \n> parts (subsystems). Then the single kernel version number is meaningless.\n> \n\nNot really. They can (and should) create their own version numbers. I can't make\nsense of the above output. If you ask a developer to piece together the puzzle\nthat makes up this subsystem and then fit it into the bigger picture, he won't\nlove you for it. Not only because this particular subsystem might well be the\nsame version across several different releases with all their different API's\n(the input system has changed its API's incompatibly quite frequently over the\nlast six months, fe, so a driver-version *alone* in that system makes absolutely\nno sense if you're trying to debug it).\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n\nConsidering the successes of the wars on alcohol, poverty, drugs and\nterror, I think we should give some serious thought to declaring war\non peace.\n"},{"id":"110164","messageId":"20090401203730.GB90837@macbook.lan","threadId":"18586","inReplyTo":"49D35454.12423.D32681@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de","subject":"Re: On git 1.6 (novice's opinion)","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2009-04-01T20:37:30Z","receivedAt":"2009-04-01T20:37:30Z","isPatch":false,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"On Wed, Apr 01, 2009 at 11:47:31AM +0200, Ulrich Windl wrote:\n> So I really don't see that relying on file dates is much better than\n> doing a full rebuild. That's specifically true if you pull a new tree:\n> If I understand things right, EVERY file will have a current date, so\n> you'll rebuild everything anyway. So you could also have the \"real\n> file dates\" and then do \"make clean; make all\". I see no benefit from\n> either approach.\n\nI am not sure if you understand it right. When switching branches git\nwill only touch the files that have changed between your old and your\nnew tree. make will then only build those files that are actually\ndifferent between those two trees because they have been given a newer\ndate than their target files. All other files in your working copy will\nnot be touched.\n\ncheers Heiko\n"},{"id":"110180","messageId":"200904020417.09993.jnareb@gmail.com","threadId":"18586","inReplyTo":"49D32CE5.21780.391D18@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de","subject":"Re: On git 1.6 (novice's opinion)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-04-02T02:17:08Z","receivedAt":"2009-04-02T02:17:08Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Wed, 1 April 2009, Ulrich Windl wrote:\n> On 27 Mar 2009 at 7:09, Jakub Narebski wrote:\n>> \"Ulrich Windl\" <ulrich.windl@rz.uni-regensburg.de> writes:\n>>> On 27 Mar 2009 at 13:49, Michael J Gruber wrote: \n>>>> Ulrich Windl venit, vidit, dixit 27.03.2009 08:21:\n>>> \n>>> [...]\n>>> \n>>>> Keyword substitution and cvs/svn style version numbers are independent\n>>>> issues. The sha1 describes a commit uniquely, one could use that as a\n>>>> keyword.\n>>> \n>>> However version numbers and time stamps have the property of being at least \n>>> partially ordered in respect of \"newer/older\". That property does not hold for \n>>> SHA-1 checksums. Just imagine suggesting users to upgrade from Microsoft \n>>> Word/004765c2a1e9771e886f0dbe87d4f89643cd6f70 to Microsoft \n>>> Word/00b7e6f51130f234a969c84ee9231a5ff7fc8a82 ;-)\n>> \n>> That is why people use output of git-describe and _tag_ their releases,\n>> and make embedding version number in released version (tarball / binary)\n>> the job of make: see GIT-VERSION-GEN script in git sources, and how it\n>> is used in Makefile.\n> \n> OK, but imaginge someone sends you some file that originated from some git \n> version, maybe with minor modifications. Is there a way to find out from what git \n> version that file was derived? IMHO that's where \"automatically replaced \n> placeholders\" (like $id$) make sense.\n\nIs it theoretical exercise or some real problem?\n\n\nFirst, if the file with modification was taken from _release_ (from\ntarball of sources), they can have placeholders like @@VERSION@@ replaced\nby actual version (taken from git-describe / GIT-VERSION-GEN) by make\nduring \"make dist\" step, or its equivalent. Usually it would be e.g.\nv1.6.2.1, as you make distribution of tagged release.\n\nSecond, if the files was taken from _repository_ (from version control),\nyou can get modification send as git diff of changes (which includes\nshortened sha-1 of original file contents, and tools such as git-am --3way\ncan make use of this information to apply patch), or at least in unified\npatch format.\n\n\nLast, you can use `ident` attribute to make git replace the only\n\"automatic replaced placeholder\" (keyword) that makes sense for\ndistributed VCS, namely $Id$ keyword which get replaced by \n$Id: <40-character hexadecimal blob object name>$; you can based\non this iformation find commit or commits that introduced this exact\nversion of a file.\n\nSee gitattributes(5).\n\n>>>> Increasing version numbers are meaningless in a true DVCS world. What is\n>>>> your 100th commit may not be someone else's, even if both your master's\n>>>> heads are the same! This is why hg version numbers are a local thing.\n>>>> They are merely a local shortcut for specifying a revision and serve the\n>>>> same purpose as git's \"backward\" counts like HEAD~3 etc. Neither of them\n>>>> work permanently, not even in a local repo, if you allow rebasing.\n>>> \n>>> Maybe I didn't fully understand, but having a version number that is larger than \n>>> any parent's version numbers when doing a merge/commit doesn't look wrong to me.\n>> \n>> I'm sorry to dissapoint you, but without central server assigning\n>> numbers to commits it wouldn't simply work in distributed version\n>> control world.  Take for example the following situation: somebody\n>> clones your repository, and creates new commit on 'master' (trunk) and\n>> it gets version number N.  Meanwhile you also independently create new\n>> commit on 'master'... and without central authority it would also get\n>> version number N.  Then you would merge (pull) his/her changes, and\n>> you would have two commits with the same number; not something you want.\n> \n> Anyway the result would have number \"N+1\". Maybe you misunderstood: I'm not \n> proposing to replace git's internal version numbering (SHA-1), but so introduce \n> some more comprehensible, primitive user-level numbering.\n\nErrr... what? You would want to renumber _all_ (possibly large amount\nof) fetched commits from other repository? It is very costly, and you\nare left with commit numbers which are local to repository...\n\nOr perhaps you would want to number only commits in first line parentage\nof a branch, i.e. created in repository or fast-forwarded? This is what\nMercurial and (from what I understand) Bazaar does, and it also results\nin commit numbers which are local to repository.\n\nOr you were talking about having merge (\"result\") to have number \"N+1\".\nBut then you would have _two_ commits with number \"N\", and \"N\" would not\nidentify commit uniquely, even local for repository. Which means that\nit would be useless.\n\n\nNumbers local to repository cannot be used to pass in communication\nto others (e.g. bug was caused by commit 5436); additionally I don't\nsee how revision number 7654 is any easier to use than HEAD~3, or\nf348eae (copy'n'pasted).\n \n>> Not to mention that you can have multiple roots (multiple commits with\n>> no parent) in git repository; besides independent branches (like\n>> 'man', 'html' or 'todo') it is usually result of absorbing or\n>> subtree-merging other projects.  In 'master' branch there are 5 roots\n>> or more: joined 'git-tools' (mailinfo / mailsplit), absorbed gitweb,\n>> and subtree-merged gitk and git-gui.  And here you would again have\n>> multiple commits with the same number...\n> \n> Which would not harm, because it would be version N from committer X. Any if \n> committer X merges from anything else, the next number would be> N. I did not \n> claim that my method makes a total ordering of commits and merges possible.\n> \n> I truly believe in unique IDs, but they are just not handy in every situation.\n\nYou have <branch>~<n>, <branch>@<n>, shortened sha-1, result of git-describe\nthat can be used in place of full sha-1...\n\n-- \nJakub Narebski\nPoland\n"}]}