On git 1.6 (novice's opinion)

On git 1.6 (novice's opinion)

[Ulrich Windl]

Hello everybody,

[About my experience on version control systems: I started out with SCCS in
the eighties, and I thought it must be cool as the UNIX guys used it to
maintain their sources. Some times later I was using Emacs' numbered backup
files as a poor substiutute for nothing else. Then I came across RCS, and I
liked it soon ,because it was fully documented and well-written. I even ported
it to MS-DOS (whew!). I was attaching tags to individual files to mark
"releases" at those times. Then I heard about CVS. It seemed to help with the
tagging, so I used it for the mopre complex projects. I even did branches and
merging with it for the Linux sources. I spontaneously diskliked Bitkeeper,
because it would not work off-line. I heard about Git some time ago, but using
it seems very non-obvious. After having read the tutorial, and playing some
simple scenarios, I must admit that I really like the fully distributed nature
of it. However some commands seem to be a bit strange (e.g. "git add" is
almost, but quite a "commit" (if you come from CVS)), and sources are quite
complex. Also some seemingly dangerous commands that cannot easily be undone
should ask safety questions ("cvs merge (-j)" would also fall into that
category.]

What I'd like to see in git (My apologies if some were already discussed to 
death):

1) The ability to use the file's time at the time of add/commit instead of the
current time, and the ability tho check outfiles with the times stored in the
repository.

2) Keyword substitution. I know it's controverse (dealing with binary files),
but I'd like to have some automatic version numbering keyword at least:
Initial idea is that every commit with a change increments the number by one,
and when merging numbers a and b, the resulting number is max(a, b) + 1.

3) "git undo": If possible undo the effects of the last command.

Following are some random remarks from a first-time git user, regarding the 
buld/install:

Notes on building git-1.6.1.3 on openSUSE 11.0:
There is no "asciidoc"; the INSTALL should be more verbose on special
requirements (i.e. additional packages needed, and where to get them).
LANG= make configure
/bin/sh: curl-config: command not found
make: `configure' is up to date.

make[2]: Entering directory `/git/git-1.6.1.3'
make[2]: `GIT-VERSION-FILE' is up to date.
make[2]: Leaving directory `/git/git-1.6.1.3'
rm -f git-add.html+ git-add.html
asciidoc -b xhtml11 -d manpage -f asciidoc.conf \
                 -agit_version=1.6.1.3 -o git-add.html+ git-add.txt
make[1]: asciidoc: Command not found
make[1]: *** [git-add.html] Error 127
make[1]: Leaving directory `/git/git-1.6.1.3/Documentation'
make: *** [doc] Error 2

Some parts of the make process may look like an error if they pass by quickly:

[...]
    GEN git-request-pull
    GEN git-sh-setup
    GEN git-stash
    GEN git-submodule
    GEN git-web--browse
    SUBDIR perl
/usr/bin/perl Makefile.PL PREFIX='/home/windl/Projects/git/inst'
Writing perl.mak for Git
    GEN git-add--interactive
    GEN git-archimport
    GEN git-cvsexportcommit
    GEN git-cvsimport
[...]

Same is true for the install process:
make[1]: Leaving directory `/home/windl/Projects/git/git-1.6.1.3/git-gui'
bindir=$(cd '/home/windl/Projects/git/inst/bin' && pwd) && \
        execdir=$(cd '/home/windl/Projects/git/inst/libexec/git-core/' && pwd) && 
\
        { rm -f "$execdir/git-add" && \
                ln git-add "$execdir/git-add" 2>/dev/null || \
                cp git-add "$execdir/git-add"; } && \
        {  rm -f "$execdir/git-annotate" && ln "$execdir/git-add" "$execdir/git-
annotate" 2>/dev/null || ln -s "git-add" "$execdir/git-annotate" 2>/dev/null || cp 
"$execdir/git-add" "$execdir/git-annotate" || exit;  rm -f "$execdir/git-apply" && 
ln "$execdir/git-add" "$execdir/git-apply" 2>/dev/null || ln -s "git-add" 
"$execdir/git-apply" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-apply" || 
exit;  rm -f "$execdir/git-archive" && ln "$execdir/git-add" "$execdir/git-
archive" 2>/dev/null || ln -s "git-add" "$execdir/git-archive" 2>/dev/null || cp 
"$execdir/git-add" "$execdir/git-archive" || exit;  rm -f "$execdir/git-blame" && 
ln "$execdir/git-add" "$execdir/git-blame" 2>/dev/null || ln -s "git-add" 
"$execdir/git-blame" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-blame" || 
exit;  rm -f "$execdir/git-branch" && ln "$execdir/git-add" "$execdir/git-branch" 
2>/dev/null || ln -s "git-add" "$execdir/git-branch" 2>/dev/null || cp 
"$execdir/git-add" "$execdir/git-branch" || exit;  rm -f "$execdir/git-bundle" && 
ln "$execdir/git-add" "$execdir/git-bundle" 2>/dev/null || ln -s "git-add" 
"$execdir/git-bundle" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-bundle" 
|| exit;  rm -f "$execdir/git-cat-file" && ln "$execdir/git-add" "$execdir/git-
cat-file" 2>/dev/null || ln -s "git-add" "$execdir/git-cat-file" 2>/dev/null || cp 
"$execdir/git-add" "$execdir/git-cat-file" || exit;  rm -f "$execdir/git-check-
attr" && ln "$execdir/git-add" "$execdir/git-check-attr" 2>/dev/null || ln -s 
"git-add" "$execdir/git-check-attr" 2>/dev/null || cp "$execdir/git-add" 
"$execdir/git-check-attr" || exit;  rm -f "$execdir/git-check-ref-format" && ln 
"$execdir/git-add" "$execdir/git-check-ref-format" 2>/dev/null || ln -s "git-add" 
"$execdir/git-check-ref-format" 2>/dev/null || cp "$execdir/git-add" 
"$execdir/git-check-ref-format" || exit;  rm -f "$execdir/git-checkout-index" && 
ln "$execdir/git-add" "$execdir/git-checkout-index" 2>/dev/null || ln -s "git-add" 
"$execdir/git-checkout-index" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-
checkout-index" || exit;  rm -f "$execdir/git-checkout" && ln "$execdir/git-add" 
"$execdir/git-checkout" 2>/dev/null || ln -s "git-add" "$execdir/git-checkout" 
2>/dev/null || cp "$execdir/git-add" "$execdir/git-checkout" || exit;  rm -f 
"$execdir/git-clean" && ln "$execdir/git-add" "$execdir/git-clean" 2>/dev/null || 
ln -s "git-add" "$execdir/git-clean" 2>/dev/null || cp "$execdir/git-add" 
"$execdir/git-clean" || exit;  rm -f "$execdir/git-clone" && ln "$execdir/git-add" 
"$execdir/git-clone" 2>/dev/null || ln -s "git-add" "$execdir/git-clone" 
2>/dev/null || cp "$execdir/git-add" "$execdir/git-clone" || exit;  rm -f 
"$execdir/git-commit-tree" && ln "$execdir/git-add" "$execdir/git-commit-tree" 
2>/dev/null || ln -s "git-add" "$execdir/git-commit-tree" 2>/dev/null || cp 
"$execdir/git-add" "$execdir/git-commit-tree" || exit;  rm -f "$execdir/git-
commit" && ln "$execdir/git-add" "$execdir/git-commit" 2>/dev/null || ln -s "git-
add" "$execdir/git-commit" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-
commit" || exit;  rm -f "$execdir/git-config" && ln "$execdir/git-add" 
"$execdir/git-config" 2>/dev/null || ln -s "git-add" "$execdir/git-config" 
2>/dev/null || cp "$execdir/git-add" "$execdir/git-config" || exit;  rm -f 
"$execdir/git-count-objects" && ln "$execdir/git-add" "$execdir/git-count-objects" 
2>/dev/null || ln -s "git-add" "$execdir/git-count-objects" 2>/dev/null || cp 
"$execdir/git-add" "$execdir/git-count-objects" || exit;  rm -f "$execdir/git-
describe" && ln "$execdir/git-add" "$execdir/git-describe" 2>/dev/null || ln -s 
"git-add" "$execdir/git-describe" 2>/dev/null || cp "$execdir/git-add" 
"$execdir/git-describe" || exit;  rm -f "$execdir/git-diff-files" && ln 
"$execdir/git-add" "$execdir/git-diff-files" 2>/dev/null || ln -s "git-add" 
"$execdir/git-diff-files" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-diff-
files" || exit;  rm -f "$execdir/git-diff-index" && ln "$execdir/git-add" 
"$execdir/git-diff-index" 2>/dev/null || ln -s "git-add" "$execdir/git-diff-index" 
2>/dev/null || cp "$execdir/git-add" "$execdir/git-diff-index" || exit;  rm -f 
"$execdir/git-diff-tree" && ln "$execdir/git-add" "$execdir/git-diff-tree" 
2>/dev/null || ln -s "git-add" "$execdir/git-diff-tree" 2>/dev/null || cp 
"$execdir/git-add" "$execdir/git-diff-tree" || exit;  rm -f "$execdir/git-diff" && 
ln "$execdir/git-add" "$execdir/git-diff" 2>/dev/null || ln -s "git-add" 
"$execdir/git-diff" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-diff" || 
exit;  rm -f "$execdir/git-fast-export" && ln "$execdir/git-add" "$execdir/git-
fast-export" 2>/dev/null || ln -s "git-add" "$execdir/git-fast-export" 2>/dev/null 
|| cp "$execdir/git-add" "$execdir/git-fast-export" || exit;  rm -f "$execdir/git-
fetch--tool" && ln "$execdir/git-add" "$execdir/git-fetch--tool" 2>/dev/null || ln 
-s "git-add" "$execdir/git-fetch--tool" 2>/dev/null || cp "$execdir/git-add" 
"$execdir/git-fetch--tool" || exit;  rm -f "$execdir/git-fetch-pack" && ln 
"$execdir/git-add" "$execdir/git-fetch-pack" 2>/dev/null || ln -s "git-add" 
"$execdir/git-fetch-pack" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-
fetch-pack" || exit;  rm -f "$execdir/git-fetch" && ln "$execdir/git-add" 
"$execdir/git-fetch" 2>/dev/null || ln -s "git-add" "$execdir/git-fetch" 
2>/dev/null || cp "$execdir/git-add" "$execdir/git-fetch" || exit;  rm -f 
"$execdir/git-fmt-merge-msg" && ln "$execdir/git-add" "$execdir/git-fmt-merge-msg" 
2>/dev/null || ln -s "git-add" "$execdir/git-fmt-merge-msg" 2>/dev/null || cp 
"$execdir/git-add" "$execdir/git-fmt-merge-msg" || exit;  rm -f "$execdir/git-for-
each-ref" && ln "$execdir/git-add" "$execdir/git-for-each-ref" 2>/dev/null || ln -
s "git-add" "$execdir/git-for-each-ref" 2>/dev/null || cp "$execdir/git-add" 
"$execdir/git-for-each-ref" || exit;  rm -f "$execdir/git-fsck" && ln 
"$execdir/git-add" "$execdir/git-fsck" 2>/dev/null || ln -s "git-add" 
"$execdir/git-fsck" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-fsck" || 
exit;  rm -f "$execdir/git-gc" && ln "$execdir/git-add" "$execdir/git-gc" 
2>/dev/null || ln -s "git-add" "$execdir/git-gc" 2>/dev/null || cp "$execdir/git-
add" "$execdir/git-gc" || exit;  rm -f "$execdir/git-grep" && ln "$execdir/git-
add" "$execdir/git-grep" 2>/dev/null || ln -s "git-add" "$execdir/git-grep" 
2>/dev/null || cp "$execdir/git-add" "$execdir/git-grep" || exit;  rm -f 
"$execdir/git-help" && ln "$execdir/git-add" "$execdir/git-help" 2>/dev/null || ln 
-s "git-add" "$execdir/git-help" 2>/dev/null || cp "$execdir/git-add" 
"$execdir/git-help" || exit;  rm -f "$execdir/git-init-db" && ln "$execdir/git-
add" "$execdir/git-init-db" 2>/dev/null || ln -s "git-add" "$execdir/git-init-db" 
2>/dev/null || cp "$execdir/git-add" "$execdir/git-init-db" || exit;  rm -f 
"$execdir/git-log" && ln "$execdir/git-add" "$execdir/git-log" 2>/dev/null || ln -
s "git-add" "$execdir/git-log" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-
log" || exit;  rm -f "$execdir/git-ls-files" && ln "$execdir/git-add" 
"$execdir/git-ls-files" 2>/dev/null || ln -s "git-add" "$execdir/git-ls-files" 
2>/dev/null || cp "$execdir/git-add" "$execdir/git-ls-files" || exit;  rm -f 
"$execdir/git-ls-remote" && ln "$execdir/git-add" "$execdir/git-ls-remote" 
2>/dev/null || ln -s "git-add" "$execdir/git-ls-remote" 2>/dev/null || cp 
"$execdir/git-add" "$execdir/git-ls-remote" || exit;  rm -f "$execdir/git-ls-tree" 
&& ln "$execdir/git-add" "$execdir/git-ls-tree" 2>/dev/null || ln -s "git-add" 
"$execdir/git-ls-tree" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-ls-tree" 
|| exit;  rm -f "$execdir/git-mailinfo" && ln "$execdir/git-add" "$execdir/git-
mailinfo" 2>/dev/null || ln -s "git-add" "$execdir/git-mailinfo" 2>/dev/null || cp 
"$execdir/git-add" "$execdir/git-mailinfo" || exit;  rm -f "$execdir/git-
mailsplit" && ln "$execdir/git-add" "$execdir/git-mailsplit" 2>/dev/null || ln -s 
"git-add" "$execdir/git-mailsplit" 2>/dev/null || cp "$execdir/git-add" 
"$execdir/git-mailsplit" || exit;  rm -f "$execdir/git-merge" && ln "$execdir/git-
add" "$execdir/git-merge" 2>/dev/null || ln -s "git-add" "$execdir/git-merge" 
2>/dev/null || cp "$execdir/git-add" "$execdir/git-merge" || exit;  rm -f 
"$execdir/git-merge-base" && ln "$execdir/git-add" "$execdir/git-merge-base" 
2>/dev/null || ln -s "git-add" "$execdir/git-merge-base" 2>/dev/null || cp 
"$execdir/git-add" "$execdir/git-merge-base" || exit;  rm -f "$execdir/git-merge-
file" && ln "$execdir/git-add" "$execdir/git-merge-file" 2>/dev/null || ln -s 
"git-add" "$execdir/git-merge-file" 2>/dev/null || cp "$execdir/git-add" 
"$execdir/git-merge-file" || exit;  rm -f "$execdir/git-merge-ours" && ln 
"$execdir/git-add" "$execdir/git-merge-ours" 2>/dev/null || ln -s "git-add" 
"$execdir/git-merge-ours" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-
merge-ours" || exit;  rm -f "$execdir/git-merge-recursive" && ln "$execdir/git-
add" "$execdir/git-merge-recursive" 2>/dev/null || ln -s "git-add" "$execdir/git-
merge-recursive" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-merge-
recursive" || exit;  rm -f "$execdir/git-mv" && ln "$execdir/git-add" 
"$execdir/git-mv" 2>/dev/null || ln -s "git-add" "$execdir/git-mv" 2>/dev/null || 
cp "$execdir/git-add" "$execdir/git-mv" || exit;  rm -f "$execdir/git-name-rev" && 
ln "$execdir/git-add" "$execdir/git-name-rev" 2>/dev/null || ln -s "git-add" 
"$execdir/git-name-rev" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-name-
rev" || exit;  rm -f "$execdir/git-pack-objects" && ln "$execdir/git-add" 
"$execdir/git-pack-objects" 2>/dev/null || ln -s "git-add" "$execdir/git-pack-
objects" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-pack-objects" || exit;  
rm -f "$execdir/git-pack-refs" && ln "$execdir/git-add" "$execdir/git-pack-refs" 
2>/dev/null || ln -s "git-add" "$execdir/git-pack-refs" 2>/dev/null || cp 
"$execdir/git-add" "$execdir/git-pack-refs" || exit;  rm -f "$execdir/git-prune-
packed" && ln "$execdir/git-add" "$execdir/git-prune-packed" 2>/dev/null || ln -s 
"git-add" "$execdir/git-prune-packed" 2>/dev/null || cp "$execdir/git-add" 
"$execdir/git-prune-packed" || exit;  rm -f "$execdir/git-prune" && ln 
"$execdir/git-add" "$execdir/git-prune" 2>/dev/null || ln -s "git-add" 
"$execdir/git-prune" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-prune" || 
exit;  rm -f "$execdir/git-push" && ln "$execdir/git-add" "$execdir/git-push" 
2>/dev/null || ln -s "git-add" "$execdir/git-push" 2>/dev/null || cp 
"$execdir/git-add" "$execdir/git-push" || exit;  rm -f "$execdir/git-read-tree" && 
ln "$execdir/git-add" "$execdir/git-read-tree" 2>/dev/null || ln -s "git-add" 
"$execdir/git-read-tree" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-read-
tree" || exit;  rm -f "$execdir/git-receive-pack" && ln "$execdir/git-add" 
"$execdir/git-receive-pack" 2>/dev/null || ln -s "git-add" "$execdir/git-receive-
pack" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-receive-pack" || exit;  
rm -f "$execdir/git-reflog" && ln "$execdir/git-add" "$execdir/git-reflog" 
2>/dev/null || ln -s "git-add" "$execdir/git-reflog" 2>/dev/null || cp 
"$execdir/git-add" "$execdir/git-reflog" || exit;  rm -f "$execdir/git-remote" && 
ln "$execdir/git-add" "$execdir/git-remote" 2>/dev/null || ln -s "git-add" 
"$execdir/git-remote" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-remote" 
|| exit;  rm -f "$execdir/git-rerere" && ln "$execdir/git-add" "$execdir/git-
rerere" 2>/dev/null || ln -s "git-add" "$execdir/git-rerere" 2>/dev/null || cp 
"$execdir/git-add" "$execdir/git-rerere" || exit;  rm -f "$execdir/git-reset" && 
ln "$execdir/git-add" "$execdir/git-reset" 2>/dev/null || ln -s "git-add" 
"$execdir/git-reset" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-reset" || 
exit;  rm -f "$execdir/git-rev-list" && ln "$execdir/git-add" "$execdir/git-rev-
list" 2>/dev/null || ln -s "git-add" "$execdir/git-rev-list" 2>/dev/null || cp 
"$execdir/git-add" "$execdir/git-rev-list" || exit;  rm -f "$execdir/git-rev-
parse" && ln "$execdir/git-add" "$execdir/git-rev-parse" 2>/dev/null || ln -s 
"git-add" "$execdir/git-rev-parse" 2>/dev/null || cp "$execdir/git-add" 
"$execdir/git-rev-parse" || exit;  rm -f "$execdir/git-revert" && ln 
"$execdir/git-add" "$execdir/git-revert" 2>/dev/null || ln -s "git-add" 
"$execdir/git-revert" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-revert" 
|| exit;  rm -f "$execdir/git-rm" && ln "$execdir/git-add" "$execdir/git-rm" 
2>/dev/null || ln -s "git-add" "$execdir/git-rm" 2>/dev/null || cp "$execdir/git-
add" "$execdir/git-rm" || exit;  rm -f "$execdir/git-send-pack" && ln 
"$execdir/git-add" "$execdir/git-send-pack" 2>/dev/null || ln -s "git-add" 
"$execdir/git-send-pack" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-send-
pack" || exit;  rm -f "$execdir/git-shortlog" && ln "$execdir/git-add" 
"$execdir/git-shortlog" 2>/dev/null || ln -s "git-add" "$execdir/git-shortlog" 
2>/dev/null || cp "$execdir/git-add" "$execdir/git-shortlog" || exit;  rm -f 
"$execdir/git-show-branch" && ln "$execdir/git-add" "$execdir/git-show-branch" 
2>/dev/null || ln -s "git-add" "$execdir/git-show-branch" 2>/dev/null || cp 
"$execdir/git-add" "$execdir/git-show-branch" || exit;  rm -f "$execdir/git-show-
ref" && ln "$execdir/git-add" "$execdir/git-show-ref" 2>/dev/null || ln -s "git-
add" "$execdir/git-show-ref" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-
show-ref" || exit;  rm -f "$execdir/git-stripspace" && ln "$execdir/git-add" 
"$execdir/git-stripspace" 2>/dev/null || ln -s "git-add" "$execdir/git-stripspace" 
2>/dev/null || cp "$execdir/git-add" "$execdir/git-stripspace" || exit;  rm -f 
"$execdir/git-symbolic-ref" && ln "$execdir/git-add" "$execdir/git-symbolic-ref" 
2>/dev/null || ln -s "git-add" "$execdir/git-symbolic-ref" 2>/dev/null || cp 
"$execdir/git-add" "$execdir/git-symbolic-ref" || exit;  rm -f "$execdir/git-tag" 
&& ln "$execdir/git-add" "$execdir/git-tag" 2>/dev/null || ln -s "git-add" 
"$execdir/git-tag" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-tag" || 
exit;  rm -f "$execdir/git-tar-tree" && ln "$execdir/git-add" "$execdir/git-tar-
tree" 2>/dev/null || ln -s "git-add" "$execdir/git-tar-tree" 2>/dev/null || cp 
"$execdir/git-add" "$execdir/git-tar-tree" || exit;  rm -f "$execdir/git-unpack-
objects" && ln "$execdir/git-add" "$execdir/git-unpack-objects" 2>/dev/null || ln 
-s "git-add" "$execdir/git-unpack-objects" 2>/dev/null || cp "$execdir/git-add" 
"$execdir/git-unpack-objects" || exit;  rm -f "$execdir/git-update-index" && ln 
"$execdir/git-add" "$execdir/git-update-index" 2>/dev/null || ln -s "git-add" 
"$execdir/git-update-index" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-
update-index" || exit;  rm -f "$execdir/git-update-ref" && ln "$execdir/git-add" 
"$execdir/git-update-ref" 2>/dev/null || ln -s "git-add" "$execdir/git-update-ref" 
2>/dev/null || cp "$execdir/git-add" "$execdir/git-update-ref" || exit;  rm -f 
"$execdir/git-upload-archive" && ln "$execdir/git-add" "$execdir/git-upload-
archive" 2>/dev/null || ln -s "git-add" "$execdir/git-upload-archive" 2>/dev/null 
|| cp "$execdir/git-add" "$execdir/git-upload-archive" || exit;  rm -f 
"$execdir/git-verify-pack" && ln "$execdir/git-add" "$execdir/git-verify-pack" 
2>/dev/null || ln -s "git-add" "$execdir/git-verify-pack" 2>/dev/null || cp 
"$execdir/git-add" "$execdir/git-verify-pack" || exit;  rm -f "$execdir/git-
verify-tag" && ln "$execdir/git-add" "$execdir/git-verify-tag" 2>/dev/null || ln -
s "git-add" "$execdir/git-verify-tag" 2>/dev/null || cp "$execdir/git-add" 
"$execdir/git-verify-tag" || exit;  rm -f "$execdir/git-write-tree" && ln 
"$execdir/git-add" "$execdir/git-write-tree" 2>/dev/null || ln -s "git-add" 
"$execdir/git-write-tree" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-
write-tree" || exit;  rm -f "$execdir/git-cherry-pick" && ln "$execdir/git-add" 
"$execdir/git-cherry-pick" 2>/dev/null || ln -s "git-add" "$execdir/git-cherry-
pick" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-cherry-pick" || exit;  rm 
-f "$execdir/git-cherry" && ln "$execdir/git-add" "$execdir/git-cherry" 
2>/dev/null || ln -s "git-add" "$execdir/git-cherry" 2>/dev/null || cp 
"$execdir/git-add" "$execdir/git-cherry" || exit;  rm -f "$execdir/git-format-
patch" && ln "$execdir/git-add" "$execdir/git-format-patch" 2>/dev/null || ln -s 
"git-add" "$execdir/git-format-patch" 2>/dev/null || cp "$execdir/git-add" 
"$execdir/git-format-patch" || exit;  rm -f "$execdir/git-fsck-objects" && ln 
"$execdir/git-add" "$execdir/git-fsck-objects" 2>/dev/null || ln -s "git-add" 
"$execdir/git-fsck-objects" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-
fsck-objects" || exit;  rm -f "$execdir/git-get-tar-commit-id" && ln 
"$execdir/git-add" "$execdir/git-get-tar-commit-id" 2>/dev/null || ln -s "git-add" 
"$execdir/git-get-tar-commit-id" 2>/dev/null || cp "$execdir/git-add" 
"$execdir/git-get-tar-commit-id" || exit;  rm -f "$execdir/git-init" && ln 
"$execdir/git-add" "$execdir/git-init" 2>/dev/null || ln -s "git-add" 
"$execdir/git-init" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-init" || 
exit;  rm -f "$execdir/git-merge-subtree" && ln "$execdir/git-add" "$execdir/git-
merge-subtree" 2>/dev/null || ln -s "git-add" "$execdir/git-merge-subtree" 
2>/dev/null || cp "$execdir/git-add" "$execdir/git-merge-subtree" || exit;  rm -f 
"$execdir/git-peek-remote" && ln "$execdir/git-add" "$execdir/git-peek-remote" 
2>/dev/null || ln -s "git-add" "$execdir/git-peek-remote" 2>/dev/null || cp 
"$execdir/git-add" "$execdir/git-peek-remote" || exit;  rm -f "$execdir/git-repo-
config" && ln "$execdir/git-add" "$execdir/git-repo-config" 2>/dev/null || ln -s 
"git-add" "$execdir/git-repo-config" 2>/dev/null || cp "$execdir/git-add" 
"$execdir/git-repo-config" || exit;  rm -f "$execdir/git-show" && ln 
"$execdir/git-add" "$execdir/git-show" 2>/dev/null || ln -s "git-add" 
"$execdir/git-show" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-show" || 
exit;  rm -f "$execdir/git-stage" && ln "$execdir/git-add" "$execdir/git-stage" 
2>/dev/null || ln -s "git-add" "$execdir/git-stage" 2>/dev/null || cp 
"$execdir/git-add" "$execdir/git-stage" || exit;  rm -f "$execdir/git-status" && 
ln "$execdir/git-add" "$execdir/git-status" 2>/dev/null || ln -s "git-add" 
"$execdir/git-status" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-status" 
|| exit;  rm -f "$execdir/git-whatchanged" && ln "$execdir/git-add" "$execdir/git-
whatchanged" 2>/dev/null || ln -s "git-add" "$execdir/git-whatchanged" 2>/dev/null 
|| cp "$execdir/git-add" "$execdir/git-whatchanged" || exit; } && \
        ./check_bindir "z$bindir" "z$execdir" "$bindir/git-add"

There's a problem with "make quick-install-man":
LANG= make quick-install-man
make -C Documentation quick-install-man
make[1]: Entering directory `/git/git-1.6.1.3/Documentation'
make -C ../ GIT-VERSION-FILE
make[2]: Entering directory `/git/git-1.6.1.3'
make[2]: `GIT-VERSION-FILE' is up to date.
make[2]: Leaving directory `/git/git-1.6.1.3'
sh ./install-doc-quick.sh origin/man /git/inst/share/man
./install-doc-quick.sh: line 9: /git/inst/libexec/git-sh-setup: No such file or 
directory
make[1]: *** [quick-install-man] Error 1
make[1]: Leaving directory `/git/git-1.6.1.3/Documentation'
make: *** [quick-install-man] Error 2

Regards,
Ulrich Windl

Re: On git 1.6 (novice's opinion)

[H.Merijn Brand]

On Fri, 27 Mar 2009 08:21:36 +0100, "Ulrich Windl"
<ulrich.windl@rz.uni-regensburg.de> wrote:

> What I'd like to see in git (My apologies if some were already discussed to 
> death):
> 
> 1) The ability to use the file's time at the time of add/commit instead of
>    the current time, and the ability tho check outfiles with the times stored
>    in the repository.
> 
> 2) Keyword substitution. I know it's controverse (dealing with binary files),
>    but I'd like to have some automatic version numbering keyword at least:
>    Initial idea is that every commit with a change increments the number by
>    one, and when merging numbers a and b, the resulting number is max(a, b) + 1.

impossible. Even with checkin- and checkout hooks, you won't get that
SCCS behaviour. They have to be better in something too :)
/me still misses that but got used to it

> 3) "git undo": If possible undo the effects of the last command.
> 
> Following are some random remarks from a first-time git user, regarding the 
> buld/install:
> 
> Notes on building git-1.6.1.3 on openSUSE 11.0:
> There is no "asciidoc"; the INSTALL should be more verbose on special
> requirements (i.e. additional packages needed, and where to get them).

# zypper in asciidoc libcurl-devel

(yes, 'make install-man' should stop soon after detecting asciidoc is
not installed


-- 
H.Merijn Brand  http://tux.nl      Perl Monger  http://amsterdam.pm.org/
using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00,
11.11, 11.23, and 11.31, SuSE 10.3, 11.0, and 11.1, AIX 5.2, and Cygwin.
http://mirrors.develooper.com/hpux/           http://www.test-smoke.org/
http://qa.perl.org      http://www.goldmark.org/jeff/stupid-disclaimers/

Re: On git 1.6 (novice's opinion)

[Ulrich Windl]

On 27 Mar 2009 at 9:05, H.Merijn Brand wrote:

> On Fri, 27 Mar 2009 08:21:36 +0100, "Ulrich Windl"
> <ulrich.windl@rz.uni-regensburg.de> wrote:
> 
> > What I'd like to see in git (My apologies if some were already discussed to 
> > death):
> > 
> > 1) The ability to use the file's time at the time of add/commit instead of
> >    the current time, and the ability tho check outfiles with the times stored
> >    in the repository.
> > 
> > 2) Keyword substitution. I know it's controverse (dealing with binary files),
> >    but I'd like to have some automatic version numbering keyword at least:
> >    Initial idea is that every commit with a change increments the number by
> >    one, and when merging numbers a and b, the resulting number is max(a, b) + 1.
> 
> impossible. Even with checkin- and checkout hooks, you won't get that
> SCCS behaviour. They have to be better in something too :)
> /me still misses that but got used to it

Hi,

what made me wonder is this (about item 1): I thought I've read that blobs store 
content and attributes, so very obviously I wondered why not store thr "right 
attributes" (i.e. the time of the file). My reasoning: You make some changes, then 
test them (which might last several hours or days). The if I'm happy I'll 
"commit". Naturally I want to see the time of change for each file when the change 
had been actually made, not when the change was committed. Likewise when checking 
out, I want to be able to see the time of modification, not the time of commit. 
I'm aware that many people don't care about such differences...

> 
> > 3) "git undo": If possible undo the effects of the last command.

If impossible, add confirmations for some "dangerous" (non-obvious) commands 
before doing possibly harmful things. Maybe adding a kind of "user-level setting" 
(novice, expert, guro) could control such confirmations.

> > 
> > Following are some random remarks from a first-time git user, regarding the 
> > buld/install:
> > 
> > Notes on building git-1.6.1.3 on openSUSE 11.0:
> > There is no "asciidoc"; the INSTALL should be more verbose on special
> > requirements (i.e. additional packages needed, and where to get them).
> 
> # zypper in asciidoc libcurl-devel

"asciidoc" doesn't seem a popular package on some distributions; mine lacks it...
> 
> (yes, 'make install-man' should stop soon after detecting asciidoc is
> not installed

Regards,
Ulrich

Re: On git 1.6 (novice's opinion)

[Etienne Vallette d'Osia]

Ulrich Windl a écrit :
>>> 3) "git undo": If possible undo the effects of the last command.
> 
> If impossible, add confirmations for some "dangerous" (non-obvious) commands 
> before doing possibly harmful things. Maybe adding a kind of "user-level setting" 
> (novice, expert, guro) could control such confirmations.
> 
Why ?
All objects stored are immutable, and some tools keep informations 
(ORIGIN_HEAD, refs/original) to allow a undo hand-made.
Moreover the reflog (and stash if you want to use it for this use) store 
  informations during time...

So it's possible to provide a generic undo for all commands that change 
refs.

Maybe an "undo" directory in $GIT_DIR, which will a keep a copy version 
of all refs. Every commands store the current refs in this folder _before_
to change anything, and the undo restore them all.
At least, a "lastcmd" (for example) file could be added in this 
directory to allow an more clever undo.

Re: On git 1.6 (novice's opinion)

[Etienne Vallette d'Osia]

Etienne Vallette d'Osia a écrit :
> Ulrich Windl a écrit :
>>>> 3) "git undo": If possible undo the effects of the last command.
>>
>> If impossible, add confirmations for some "dangerous" (non-obvious) 
>> commands before doing possibly harmful things. Maybe adding a kind of 
>> "user-level setting" (novice, expert, guro) could control such 
>> confirmations.
>>
> Why ?
Oops, I have readed "it is impossible"

Re: On git 1.6 (novice's opinion)

[Dmitry Potapov]

On Fri, Mar 27, 2009 at 10:21 AM, Ulrich Windl
<ulrich.windl@rz.uni-regensburg.de> wrote:
>
> 1) The ability to use the file's time at the time of add/commit instead of the
> current time, and the ability tho check outfiles with the times stored in the
> repository.

To check out with the times stored in repository is a a bad idea, because it
will screw up 'make'.

>
> 2) Keyword substitution. I know it's controverse (dealing with binary files),
> but I'd like to have some automatic version numbering keyword at least:
> Initial idea is that every commit with a change increments the number by one,
> and when merging numbers a and b, the resulting number is max(a, b) + 1.

I am not sure what you want to achieve by having this number. Also, take
a look at "git describe", it may be close to what you want (or may be not).


Dmitry

Re: On git 1.6 (novice's opinion)

[Dmitry Potapov]

On Fri, Mar 27, 2009 at 12:50 PM, Ulrich Windl
<ulrich.windl@rz.uni-regensburg.de> wrote:
>
> what made me wonder is this (about item 1): I thought I've read that blobs store
> content and attributes, so very obviously I wondered why not store thr "right
> attributes" (i.e. the time of the file). My reasoning: You make some changes, then
> test them (which might last several hours or days). The if I'm happy I'll
> "commit".

With Git, you usually commit your changes immediately (without waiting
the result
of testing), because you can always undo commit until you publish your changes.


Dmitry

Re: On git 1.6 (novice's opinion)

[Michael J Gruber]

Ulrich Windl venit, vidit, dixit 27.03.2009 08:21:
> Hello everybody,
> 
> [About my experience on version control systems: I started out with SCCS in
> the eighties, and I thought it must be cool as the UNIX guys used it to
> maintain their sources. Some times later I was using Emacs' numbered backup
> files as a poor substiutute for nothing else. Then I came across RCS, and I
> liked it soon ,because it was fully documented and well-written. I even ported
> it to MS-DOS (whew!). I was attaching tags to individual files to mark
> "releases" at those times. Then I heard about CVS. It seemed to help with the
> tagging, so I used it for the mopre complex projects. I even did branches and
> merging with it for the Linux sources. I spontaneously diskliked Bitkeeper,
> because it would not work off-line. I heard about Git some time ago, but using
> it seems very non-obvious. After having read the tutorial, and playing some
> simple scenarios, I must admit that I really like the fully distributed nature
> of it. However some commands seem to be a bit strange (e.g. "git add" is
> almost, but quite a "commit" (if you come from CVS)), and sources are quite
> complex. Also some seemingly dangerous commands that cannot easily be undone
> should ask safety questions ("cvs merge (-j)" would also fall into that
> category.]
> 
> What I'd like to see in git (My apologies if some were already discussed to 
> death):
> 
> 1) The ability to use the file's time at the time of add/commit instead of the
> current time, and the ability tho check outfiles with the times stored in the
> repository.
> 
> 2) Keyword substitution. I know it's controverse (dealing with binary files),
> but I'd like to have some automatic version numbering keyword at least:
> Initial idea is that every commit with a change increments the number by one,
> and when merging numbers a and b, the resulting number is max(a, b) + 1.

Keyword substitution and cvs/svn style version numbers are independent
issues. The sha1 describes a commit uniquely, one could use that as a
keyword.

Increasing version numbers are meaningless in a true DVCS world. What is
your 100th commit may not be someone else's, even if both your master's
heads are the same! This is why hg version numbers are a local thing.
They are merely a local shortcut for specifying a revision and serve the
same purpose as git's "backward" counts like HEAD~3 etc. Neither of them
work permanently, not even in a local repo, if you allow rebasing.

git rev-list HEAD|wc may produce something like it, but be sure to read
up on --sparse and --full-history.

> 3) "git undo": If possible undo the effects of the last command.
> 
> Following are some random remarks from a first-time git user, regarding the 
> buld/install:
> 
> Notes on building git-1.6.1.3 on openSUSE 11.0:
> There is no "asciidoc"; the INSTALL should be more verbose on special
> requirements (i.e. additional packages needed, and where to get them).
> LANG= make configure
> /bin/sh: curl-config: command not found
> make: `configure' is up to date.
> 
> make[2]: Entering directory `/git/git-1.6.1.3'
> make[2]: `GIT-VERSION-FILE' is up to date.
> make[2]: Leaving directory `/git/git-1.6.1.3'
> rm -f git-add.html+ git-add.html
> asciidoc -b xhtml11 -d manpage -f asciidoc.conf \
>                  -agit_version=1.6.1.3 -o git-add.html+ git-add.txt
> make[1]: asciidoc: Command not found
> make[1]: *** [git-add.html] Error 127
> make[1]: Leaving directory `/git/git-1.6.1.3/Documentation'
> make: *** [doc] Error 2
> 
> Some parts of the make process may look like an error if they pass by quickly:
> 
> [...]
>     GEN git-request-pull
>     GEN git-sh-setup
>     GEN git-stash
>     GEN git-submodule
>     GEN git-web--browse
>     SUBDIR perl
> /usr/bin/perl Makefile.PL PREFIX='/home/windl/Projects/git/inst'
> Writing perl.mak for Git
>     GEN git-add--interactive
>     GEN git-archimport
>     GEN git-cvsexportcommit
>     GEN git-cvsimport
> [...]
> 
> Same is true for the install process:
> make[1]: Leaving directory `/home/windl/Projects/git/git-1.6.1.3/git-gui'
> bindir=$(cd '/home/windl/Projects/git/inst/bin' && pwd) && \
>         execdir=$(cd '/home/windl/Projects/git/inst/libexec/git-core/' && pwd) && 
> \
>         { rm -f "$execdir/git-add" && \
>                 ln git-add "$execdir/git-add" 2>/dev/null || \
>                 cp git-add "$execdir/git-add"; } && \
>         {  rm -f "$execdir/git-annotate" && ln "$execdir/git-add" "$execdir/git-
> annotate" 2>/dev/null || ln -s "git-add" "$execdir/git-annotate" 2>/dev/null || cp 
> "$execdir/git-add" "$execdir/git-annotate" || exit;  rm -f "$execdir/git-apply" && 
> ln "$execdir/git-add" "$execdir/git-apply" 2>/dev/null || ln -s "git-add" 
> "$execdir/git-apply" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-apply" || 
> exit;  rm -f "$execdir/git-archive" && ln "$execdir/git-add" "$execdir/git-
> archive" 2>/dev/null || ln -s "git-add" "$execdir/git-archive" 2>/dev/null || cp 
> "$execdir/git-add" "$execdir/git-archive" || exit;  rm -f "$execdir/git-blame" && 
> ln "$execdir/git-add" "$execdir/git-blame" 2>/dev/null || ln -s "git-add" 
> "$execdir/git-blame" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-blame" || 
> exit;  rm -f "$execdir/git-branch" && ln "$execdir/git-add" "$execdir/git-branch" 
> 2>/dev/null || ln -s "git-add" "$execdir/git-branch" 2>/dev/null || cp 
> "$execdir/git-add" "$execdir/git-branch" || exit;  rm -f "$execdir/git-bundle" && 
> ln "$execdir/git-add" "$execdir/git-bundle" 2>/dev/null || ln -s "git-add" 
> "$execdir/git-bundle" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-bundle" 
> || exit;  rm -f "$execdir/git-cat-file" && ln "$execdir/git-add" "$execdir/git-
> cat-file" 2>/dev/null || ln -s "git-add" "$execdir/git-cat-file" 2>/dev/null || cp 
> "$execdir/git-add" "$execdir/git-cat-file" || exit;  rm -f "$execdir/git-check-
> attr" && ln "$execdir/git-add" "$execdir/git-check-attr" 2>/dev/null || ln -s 
> "git-add" "$execdir/git-check-attr" 2>/dev/null || cp "$execdir/git-add" 
> "$execdir/git-check-attr" || exit;  rm -f "$execdir/git-check-ref-format" && ln 
> "$execdir/git-add" "$execdir/git-check-ref-format" 2>/dev/null || ln -s "git-add" 
> "$execdir/git-check-ref-format" 2>/dev/null || cp "$execdir/git-add" 
> "$execdir/git-check-ref-format" || exit;  rm -f "$execdir/git-checkout-index" && 
> ln "$execdir/git-add" "$execdir/git-checkout-index" 2>/dev/null || ln -s "git-add" 
> "$execdir/git-checkout-index" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-
> checkout-index" || exit;  rm -f "$execdir/git-checkout" && ln "$execdir/git-add" 
> "$execdir/git-checkout" 2>/dev/null || ln -s "git-add" "$execdir/git-checkout" 
> 2>/dev/null || cp "$execdir/git-add" "$execdir/git-checkout" || exit;  rm -f 
> "$execdir/git-clean" && ln "$execdir/git-add" "$execdir/git-clean" 2>/dev/null || 
> ln -s "git-add" "$execdir/git-clean" 2>/dev/null || cp "$execdir/git-add" 
> "$execdir/git-clean" || exit;  rm -f "$execdir/git-clone" && ln "$execdir/git-add" 
> "$execdir/git-clone" 2>/dev/null || ln -s "git-add" "$execdir/git-clone" 
> 2>/dev/null || cp "$execdir/git-add" "$execdir/git-clone" || exit;  rm -f 
> "$execdir/git-commit-tree" && ln "$execdir/git-add" "$execdir/git-commit-tree" 
> 2>/dev/null || ln -s "git-add" "$execdir/git-commit-tree" 2>/dev/null || cp 
> "$execdir/git-add" "$execdir/git-commit-tree" || exit;  rm -f "$execdir/git-
> commit" && ln "$execdir/git-add" "$execdir/git-commit" 2>/dev/null || ln -s "git-
> add" "$execdir/git-commit" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-
> commit" || exit;  rm -f "$execdir/git-config" && ln "$execdir/git-add" 
> "$execdir/git-config" 2>/dev/null || ln -s "git-add" "$execdir/git-config" 
> 2>/dev/null || cp "$execdir/git-add" "$execdir/git-config" || exit;  rm -f 
> "$execdir/git-count-objects" && ln "$execdir/git-add" "$execdir/git-count-objects" 
> 2>/dev/null || ln -s "git-add" "$execdir/git-count-objects" 2>/dev/null || cp 
> "$execdir/git-add" "$execdir/git-count-objects" || exit;  rm -f "$execdir/git-
> describe" && ln "$execdir/git-add" "$execdir/git-describe" 2>/dev/null || ln -s 
> "git-add" "$execdir/git-describe" 2>/dev/null || cp "$execdir/git-add" 
> "$execdir/git-describe" || exit;  rm -f "$execdir/git-diff-files" && ln 
> "$execdir/git-add" "$execdir/git-diff-files" 2>/dev/null || ln -s "git-add" 
> "$execdir/git-diff-files" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-diff-
> files" || exit;  rm -f "$execdir/git-diff-index" && ln "$execdir/git-add" 
> "$execdir/git-diff-index" 2>/dev/null || ln -s "git-add" "$execdir/git-diff-index" 
> 2>/dev/null || cp "$execdir/git-add" "$execdir/git-diff-index" || exit;  rm -f 
> "$execdir/git-diff-tree" && ln "$execdir/git-add" "$execdir/git-diff-tree" 
> 2>/dev/null || ln -s "git-add" "$execdir/git-diff-tree" 2>/dev/null || cp 
> "$execdir/git-add" "$execdir/git-diff-tree" || exit;  rm -f "$execdir/git-diff" && 
> ln "$execdir/git-add" "$execdir/git-diff" 2>/dev/null || ln -s "git-add" 
> "$execdir/git-diff" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-diff" || 
> exit;  rm -f "$execdir/git-fast-export" && ln "$execdir/git-add" "$execdir/git-
> fast-export" 2>/dev/null || ln -s "git-add" "$execdir/git-fast-export" 2>/dev/null 
> || cp "$execdir/git-add" "$execdir/git-fast-export" || exit;  rm -f "$execdir/git-
> fetch--tool" && ln "$execdir/git-add" "$execdir/git-fetch--tool" 2>/dev/null || ln 
> -s "git-add" "$execdir/git-fetch--tool" 2>/dev/null || cp "$execdir/git-add" 
> "$execdir/git-fetch--tool" || exit;  rm -f "$execdir/git-fetch-pack" && ln 
> "$execdir/git-add" "$execdir/git-fetch-pack" 2>/dev/null || ln -s "git-add" 
> "$execdir/git-fetch-pack" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-
> fetch-pack" || exit;  rm -f "$execdir/git-fetch" && ln "$execdir/git-add" 
> "$execdir/git-fetch" 2>/dev/null || ln -s "git-add" "$execdir/git-fetch" 
> 2>/dev/null || cp "$execdir/git-add" "$execdir/git-fetch" || exit;  rm -f 
> "$execdir/git-fmt-merge-msg" && ln "$execdir/git-add" "$execdir/git-fmt-merge-msg" 
> 2>/dev/null || ln -s "git-add" "$execdir/git-fmt-merge-msg" 2>/dev/null || cp 
> "$execdir/git-add" "$execdir/git-fmt-merge-msg" || exit;  rm -f "$execdir/git-for-
> each-ref" && ln "$execdir/git-add" "$execdir/git-for-each-ref" 2>/dev/null || ln -
> s "git-add" "$execdir/git-for-each-ref" 2>/dev/null || cp "$execdir/git-add" 
> "$execdir/git-for-each-ref" || exit;  rm -f "$execdir/git-fsck" && ln 
> "$execdir/git-add" "$execdir/git-fsck" 2>/dev/null || ln -s "git-add" 
> "$execdir/git-fsck" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-fsck" || 
> exit;  rm -f "$execdir/git-gc" && ln "$execdir/git-add" "$execdir/git-gc" 
> 2>/dev/null || ln -s "git-add" "$execdir/git-gc" 2>/dev/null || cp "$execdir/git-
> add" "$execdir/git-gc" || exit;  rm -f "$execdir/git-grep" && ln "$execdir/git-
> add" "$execdir/git-grep" 2>/dev/null || ln -s "git-add" "$execdir/git-grep" 
> 2>/dev/null || cp "$execdir/git-add" "$execdir/git-grep" || exit;  rm -f 
> "$execdir/git-help" && ln "$execdir/git-add" "$execdir/git-help" 2>/dev/null || ln 
> -s "git-add" "$execdir/git-help" 2>/dev/null || cp "$execdir/git-add" 
> "$execdir/git-help" || exit;  rm -f "$execdir/git-init-db" && ln "$execdir/git-
> add" "$execdir/git-init-db" 2>/dev/null || ln -s "git-add" "$execdir/git-init-db" 
> 2>/dev/null || cp "$execdir/git-add" "$execdir/git-init-db" || exit;  rm -f 
> "$execdir/git-log" && ln "$execdir/git-add" "$execdir/git-log" 2>/dev/null || ln -
> s "git-add" "$execdir/git-log" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-
> log" || exit;  rm -f "$execdir/git-ls-files" && ln "$execdir/git-add" 
> "$execdir/git-ls-files" 2>/dev/null || ln -s "git-add" "$execdir/git-ls-files" 
> 2>/dev/null || cp "$execdir/git-add" "$execdir/git-ls-files" || exit;  rm -f 
> "$execdir/git-ls-remote" && ln "$execdir/git-add" "$execdir/git-ls-remote" 
> 2>/dev/null || ln -s "git-add" "$execdir/git-ls-remote" 2>/dev/null || cp 
> "$execdir/git-add" "$execdir/git-ls-remote" || exit;  rm -f "$execdir/git-ls-tree" 
> && ln "$execdir/git-add" "$execdir/git-ls-tree" 2>/dev/null || ln -s "git-add" 
> "$execdir/git-ls-tree" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-ls-tree" 
> || exit;  rm -f "$execdir/git-mailinfo" && ln "$execdir/git-add" "$execdir/git-
> mailinfo" 2>/dev/null || ln -s "git-add" "$execdir/git-mailinfo" 2>/dev/null || cp 
> "$execdir/git-add" "$execdir/git-mailinfo" || exit;  rm -f "$execdir/git-
> mailsplit" && ln "$execdir/git-add" "$execdir/git-mailsplit" 2>/dev/null || ln -s 
> "git-add" "$execdir/git-mailsplit" 2>/dev/null || cp "$execdir/git-add" 
> "$execdir/git-mailsplit" || exit;  rm -f "$execdir/git-merge" && ln "$execdir/git-
> add" "$execdir/git-merge" 2>/dev/null || ln -s "git-add" "$execdir/git-merge" 
> 2>/dev/null || cp "$execdir/git-add" "$execdir/git-merge" || exit;  rm -f 
> "$execdir/git-merge-base" && ln "$execdir/git-add" "$execdir/git-merge-base" 
> 2>/dev/null || ln -s "git-add" "$execdir/git-merge-base" 2>/dev/null || cp 
> "$execdir/git-add" "$execdir/git-merge-base" || exit;  rm -f "$execdir/git-merge-
> file" && ln "$execdir/git-add" "$execdir/git-merge-file" 2>/dev/null || ln -s 
> "git-add" "$execdir/git-merge-file" 2>/dev/null || cp "$execdir/git-add" 
> "$execdir/git-merge-file" || exit;  rm -f "$execdir/git-merge-ours" && ln 
> "$execdir/git-add" "$execdir/git-merge-ours" 2>/dev/null || ln -s "git-add" 
> "$execdir/git-merge-ours" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-
> merge-ours" || exit;  rm -f "$execdir/git-merge-recursive" && ln "$execdir/git-
> add" "$execdir/git-merge-recursive" 2>/dev/null || ln -s "git-add" "$execdir/git-
> merge-recursive" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-merge-
> recursive" || exit;  rm -f "$execdir/git-mv" && ln "$execdir/git-add" 
> "$execdir/git-mv" 2>/dev/null || ln -s "git-add" "$execdir/git-mv" 2>/dev/null || 
> cp "$execdir/git-add" "$execdir/git-mv" || exit;  rm -f "$execdir/git-name-rev" && 
> ln "$execdir/git-add" "$execdir/git-name-rev" 2>/dev/null || ln -s "git-add" 
> "$execdir/git-name-rev" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-name-
> rev" || exit;  rm -f "$execdir/git-pack-objects" && ln "$execdir/git-add" 
> "$execdir/git-pack-objects" 2>/dev/null || ln -s "git-add" "$execdir/git-pack-
> objects" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-pack-objects" || exit;  
> rm -f "$execdir/git-pack-refs" && ln "$execdir/git-add" "$execdir/git-pack-refs" 
> 2>/dev/null || ln -s "git-add" "$execdir/git-pack-refs" 2>/dev/null || cp 
> "$execdir/git-add" "$execdir/git-pack-refs" || exit;  rm -f "$execdir/git-prune-
> packed" && ln "$execdir/git-add" "$execdir/git-prune-packed" 2>/dev/null || ln -s 
> "git-add" "$execdir/git-prune-packed" 2>/dev/null || cp "$execdir/git-add" 
> "$execdir/git-prune-packed" || exit;  rm -f "$execdir/git-prune" && ln 
> "$execdir/git-add" "$execdir/git-prune" 2>/dev/null || ln -s "git-add" 
> "$execdir/git-prune" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-prune" || 
> exit;  rm -f "$execdir/git-push" && ln "$execdir/git-add" "$execdir/git-push" 
> 2>/dev/null || ln -s "git-add" "$execdir/git-push" 2>/dev/null || cp 
> "$execdir/git-add" "$execdir/git-push" || exit;  rm -f "$execdir/git-read-tree" && 
> ln "$execdir/git-add" "$execdir/git-read-tree" 2>/dev/null || ln -s "git-add" 
> "$execdir/git-read-tree" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-read-
> tree" || exit;  rm -f "$execdir/git-receive-pack" && ln "$execdir/git-add" 
> "$execdir/git-receive-pack" 2>/dev/null || ln -s "git-add" "$execdir/git-receive-
> pack" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-receive-pack" || exit;  
> rm -f "$execdir/git-reflog" && ln "$execdir/git-add" "$execdir/git-reflog" 
> 2>/dev/null || ln -s "git-add" "$execdir/git-reflog" 2>/dev/null || cp 
> "$execdir/git-add" "$execdir/git-reflog" || exit;  rm -f "$execdir/git-remote" && 
> ln "$execdir/git-add" "$execdir/git-remote" 2>/dev/null || ln -s "git-add" 
> "$execdir/git-remote" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-remote" 
> || exit;  rm -f "$execdir/git-rerere" && ln "$execdir/git-add" "$execdir/git-
> rerere" 2>/dev/null || ln -s "git-add" "$execdir/git-rerere" 2>/dev/null || cp 
> "$execdir/git-add" "$execdir/git-rerere" || exit;  rm -f "$execdir/git-reset" && 
> ln "$execdir/git-add" "$execdir/git-reset" 2>/dev/null || ln -s "git-add" 
> "$execdir/git-reset" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-reset" || 
> exit;  rm -f "$execdir/git-rev-list" && ln "$execdir/git-add" "$execdir/git-rev-
> list" 2>/dev/null || ln -s "git-add" "$execdir/git-rev-list" 2>/dev/null || cp 
> "$execdir/git-add" "$execdir/git-rev-list" || exit;  rm -f "$execdir/git-rev-
> parse" && ln "$execdir/git-add" "$execdir/git-rev-parse" 2>/dev/null || ln -s 
> "git-add" "$execdir/git-rev-parse" 2>/dev/null || cp "$execdir/git-add" 
> "$execdir/git-rev-parse" || exit;  rm -f "$execdir/git-revert" && ln 
> "$execdir/git-add" "$execdir/git-revert" 2>/dev/null || ln -s "git-add" 
> "$execdir/git-revert" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-revert" 
> || exit;  rm -f "$execdir/git-rm" && ln "$execdir/git-add" "$execdir/git-rm" 
> 2>/dev/null || ln -s "git-add" "$execdir/git-rm" 2>/dev/null || cp "$execdir/git-
> add" "$execdir/git-rm" || exit;  rm -f "$execdir/git-send-pack" && ln 
> "$execdir/git-add" "$execdir/git-send-pack" 2>/dev/null || ln -s "git-add" 
> "$execdir/git-send-pack" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-send-
> pack" || exit;  rm -f "$execdir/git-shortlog" && ln "$execdir/git-add" 
> "$execdir/git-shortlog" 2>/dev/null || ln -s "git-add" "$execdir/git-shortlog" 
> 2>/dev/null || cp "$execdir/git-add" "$execdir/git-shortlog" || exit;  rm -f 
> "$execdir/git-show-branch" && ln "$execdir/git-add" "$execdir/git-show-branch" 
> 2>/dev/null || ln -s "git-add" "$execdir/git-show-branch" 2>/dev/null || cp 
> "$execdir/git-add" "$execdir/git-show-branch" || exit;  rm -f "$execdir/git-show-
> ref" && ln "$execdir/git-add" "$execdir/git-show-ref" 2>/dev/null || ln -s "git-
> add" "$execdir/git-show-ref" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-
> show-ref" || exit;  rm -f "$execdir/git-stripspace" && ln "$execdir/git-add" 
> "$execdir/git-stripspace" 2>/dev/null || ln -s "git-add" "$execdir/git-stripspace" 
> 2>/dev/null || cp "$execdir/git-add" "$execdir/git-stripspace" || exit;  rm -f 
> "$execdir/git-symbolic-ref" && ln "$execdir/git-add" "$execdir/git-symbolic-ref" 
> 2>/dev/null || ln -s "git-add" "$execdir/git-symbolic-ref" 2>/dev/null || cp 
> "$execdir/git-add" "$execdir/git-symbolic-ref" || exit;  rm -f "$execdir/git-tag" 
> && ln "$execdir/git-add" "$execdir/git-tag" 2>/dev/null || ln -s "git-add" 
> "$execdir/git-tag" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-tag" || 
> exit;  rm -f "$execdir/git-tar-tree" && ln "$execdir/git-add" "$execdir/git-tar-
> tree" 2>/dev/null || ln -s "git-add" "$execdir/git-tar-tree" 2>/dev/null || cp 
> "$execdir/git-add" "$execdir/git-tar-tree" || exit;  rm -f "$execdir/git-unpack-
> objects" && ln "$execdir/git-add" "$execdir/git-unpack-objects" 2>/dev/null || ln 
> -s "git-add" "$execdir/git-unpack-objects" 2>/dev/null || cp "$execdir/git-add" 
> "$execdir/git-unpack-objects" || exit;  rm -f "$execdir/git-update-index" && ln 
> "$execdir/git-add" "$execdir/git-update-index" 2>/dev/null || ln -s "git-add" 
> "$execdir/git-update-index" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-
> update-index" || exit;  rm -f "$execdir/git-update-ref" && ln "$execdir/git-add" 
> "$execdir/git-update-ref" 2>/dev/null || ln -s "git-add" "$execdir/git-update-ref" 
> 2>/dev/null || cp "$execdir/git-add" "$execdir/git-update-ref" || exit;  rm -f 
> "$execdir/git-upload-archive" && ln "$execdir/git-add" "$execdir/git-upload-
> archive" 2>/dev/null || ln -s "git-add" "$execdir/git-upload-archive" 2>/dev/null 
> || cp "$execdir/git-add" "$execdir/git-upload-archive" || exit;  rm -f 
> "$execdir/git-verify-pack" && ln "$execdir/git-add" "$execdir/git-verify-pack" 
> 2>/dev/null || ln -s "git-add" "$execdir/git-verify-pack" 2>/dev/null || cp 
> "$execdir/git-add" "$execdir/git-verify-pack" || exit;  rm -f "$execdir/git-
> verify-tag" && ln "$execdir/git-add" "$execdir/git-verify-tag" 2>/dev/null || ln -
> s "git-add" "$execdir/git-verify-tag" 2>/dev/null || cp "$execdir/git-add" 
> "$execdir/git-verify-tag" || exit;  rm -f "$execdir/git-write-tree" && ln 
> "$execdir/git-add" "$execdir/git-write-tree" 2>/dev/null || ln -s "git-add" 
> "$execdir/git-write-tree" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-
> write-tree" || exit;  rm -f "$execdir/git-cherry-pick" && ln "$execdir/git-add" 
> "$execdir/git-cherry-pick" 2>/dev/null || ln -s "git-add" "$execdir/git-cherry-
> pick" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-cherry-pick" || exit;  rm 
> -f "$execdir/git-cherry" && ln "$execdir/git-add" "$execdir/git-cherry" 
> 2>/dev/null || ln -s "git-add" "$execdir/git-cherry" 2>/dev/null || cp 
> "$execdir/git-add" "$execdir/git-cherry" || exit;  rm -f "$execdir/git-format-
> patch" && ln "$execdir/git-add" "$execdir/git-format-patch" 2>/dev/null || ln -s 
> "git-add" "$execdir/git-format-patch" 2>/dev/null || cp "$execdir/git-add" 
> "$execdir/git-format-patch" || exit;  rm -f "$execdir/git-fsck-objects" && ln 
> "$execdir/git-add" "$execdir/git-fsck-objects" 2>/dev/null || ln -s "git-add" 
> "$execdir/git-fsck-objects" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-
> fsck-objects" || exit;  rm -f "$execdir/git-get-tar-commit-id" && ln 
> "$execdir/git-add" "$execdir/git-get-tar-commit-id" 2>/dev/null || ln -s "git-add" 
> "$execdir/git-get-tar-commit-id" 2>/dev/null || cp "$execdir/git-add" 
> "$execdir/git-get-tar-commit-id" || exit;  rm -f "$execdir/git-init" && ln 
> "$execdir/git-add" "$execdir/git-init" 2>/dev/null || ln -s "git-add" 
> "$execdir/git-init" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-init" || 
> exit;  rm -f "$execdir/git-merge-subtree" && ln "$execdir/git-add" "$execdir/git-
> merge-subtree" 2>/dev/null || ln -s "git-add" "$execdir/git-merge-subtree" 
> 2>/dev/null || cp "$execdir/git-add" "$execdir/git-merge-subtree" || exit;  rm -f 
> "$execdir/git-peek-remote" && ln "$execdir/git-add" "$execdir/git-peek-remote" 
> 2>/dev/null || ln -s "git-add" "$execdir/git-peek-remote" 2>/dev/null || cp 
> "$execdir/git-add" "$execdir/git-peek-remote" || exit;  rm -f "$execdir/git-repo-
> config" && ln "$execdir/git-add" "$execdir/git-repo-config" 2>/dev/null || ln -s 
> "git-add" "$execdir/git-repo-config" 2>/dev/null || cp "$execdir/git-add" 
> "$execdir/git-repo-config" || exit;  rm -f "$execdir/git-show" && ln 
> "$execdir/git-add" "$execdir/git-show" 2>/dev/null || ln -s "git-add" 
> "$execdir/git-show" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-show" || 
> exit;  rm -f "$execdir/git-stage" && ln "$execdir/git-add" "$execdir/git-stage" 
> 2>/dev/null || ln -s "git-add" "$execdir/git-stage" 2>/dev/null || cp 
> "$execdir/git-add" "$execdir/git-stage" || exit;  rm -f "$execdir/git-status" && 
> ln "$execdir/git-add" "$execdir/git-status" 2>/dev/null || ln -s "git-add" 
> "$execdir/git-status" 2>/dev/null || cp "$execdir/git-add" "$execdir/git-status" 
> || exit;  rm -f "$execdir/git-whatchanged" && ln "$execdir/git-add" "$execdir/git-
> whatchanged" 2>/dev/null || ln -s "git-add" "$execdir/git-whatchanged" 2>/dev/null 
> || cp "$execdir/git-add" "$execdir/git-whatchanged" || exit; } && \
>         ./check_bindir "z$bindir" "z$execdir" "$bindir/git-add"
> 
> There's a problem with "make quick-install-man":
> LANG= make quick-install-man
> make -C Documentation quick-install-man
> make[1]: Entering directory `/git/git-1.6.1.3/Documentation'
> make -C ../ GIT-VERSION-FILE
> make[2]: Entering directory `/git/git-1.6.1.3'
> make[2]: `GIT-VERSION-FILE' is up to date.
> make[2]: Leaving directory `/git/git-1.6.1.3'
> sh ./install-doc-quick.sh origin/man /git/inst/share/man
> ./install-doc-quick.sh: line 9: /git/inst/libexec/git-sh-setup: No such file or 
> directory
> make[1]: *** [quick-install-man] Error 1
> make[1]: Leaving directory `/git/git-1.6.1.3/Documentation'
> make: *** [quick-install-man] Error 2
> 
> Regards,
> Ulrich Windl
> 

Re: On git 1.6 (novice's opinion)

[Ulrich Windl]

On 27 Mar 2009 at 15:24, Dmitry Potapov wrote:

> On Fri, Mar 27, 2009 at 10:21 AM, Ulrich Windl
> <ulrich.windl@rz.uni-regensburg.de> wrote:
> >
> > 1) The ability to use the file's time at the time of add/commit instead of the
> > current time, and the ability tho check outfiles with the times stored in the
> > repository.
> 
> To check out with the times stored in repository is a a bad idea, because it
> will screw up 'make'.

Hi,

I don't understand:
If I modify files, then do a make, then do check-in/check-out (and the file times 
are unchanged), how would that affect make?

If I do an "update/merge from remote" (there is no total ordering of release 
numbers anyway) without a "make clean" before, I'm having a problem anyway.

> 
> >
> > 2) Keyword substitution. I know it's controverse (dealing with binary files),
> > but I'd like to have some automatic version numbering keyword at least:
> > Initial idea is that every commit with a change increments the number by one,
> > and when merging numbers a and b, the resulting number is max(a, b) + 1.
> 
> I am not sure what you want to achieve by having this number. Also, take
> a look at "git describe", it may be close to what you want (or may be not).

Basically I want to support my laziness: The system will increment some number and 
maybe change some text automatically that I'm to lazy to do. OK, there are still 
many commands I'll have to learn. Unfortunately some command names are not as 
"crispy" as they could be (i.e. you cannot easily find the right command name if 
you know what you are looking for, and if you have a command name, it's not very 
clear what it really does). That makes it hard for the beginners.

Regards,
Ulrich

Re: On git 1.6 (novice's opinion)

[Ulrich Windl]

On 27 Mar 2009 at 15:24, Dmitry Potapov wrote:

> On Fri, Mar 27, 2009 at 12:50 PM, Ulrich Windl
> <ulrich.windl@rz.uni-regensburg.de> wrote:
> >
> > what made me wonder is this (about item 1): I thought I've read that blobs store
> > content and attributes, so very obviously I wondered why not store thr "right
> > attributes" (i.e. the time of the file). My reasoning: You make some changes, then
> > test them (which might last several hours or days). The if I'm happy I'll
> > "commit".
> 
> With Git, you usually commit your changes immediately (without waiting
> the result
> of testing), because you can always undo commit until you publish your changes.

Hi!

AFAIK, "committing" in git is "kind of publishing your work" (others may pull it). 
I don't like publishing my mistakes ;-) Even if no-one pulls the commit, your 
"undo" refers to "committing a fix for the last committed mistake", right? Again, 
I don't really want to document/archive (i.e. commit) my mistake. Or did I miss 
something here?
I know: Other's opinions are quite different on these issues.

Regards,
Ulrich

Re: On git 1.6 (novice's opinion)

[Matthieu Moy]

"Ulrich Windl" <ulrich.windl@rz.uni-regensburg.de> writes:

> I don't understand:
> If I modify files, then do a make, then do check-in/check-out (and the file times 
> are unchanged), how would that affect make?

>From "make"'s point of view, chechout is just a modification of the
file (as any other modification you would do with a text editor). If
you compile foo.c to foo.o, then checkout another version of foo.c,
then you want foo.c to be recompiled. If checkout modifies the
timestamp to pretend it was modified before foo.o, then make thinks
the file is up to date.

> If I do an "update/merge from remote" (there is no total ordering of release 
> numbers anyway) without a "make clean" before, I'm having a problem
> anyway.

No, you don't have a problem. Recompiling files after they're modified
is the job of make, and it just does it. make doesn't know about
revision numbers or identifiers, just timestamps.

-- 
Matthieu

Re: On git 1.6 (novice's opinion)

[Matthieu Moy]

"Ulrich Windl" <ulrich.windl@rz.uni-regensburg.de> writes:

> Hi!
>
> AFAIK, "committing" in git is "kind of publishing your work" 

It's not. It's "take a snapshot". Publish is "push" (to a public
place).

> (others may pull it). I don't like publishing my mistakes ;-) Even
> if no-one pulls the commit, your "undo" refers to "committing a fix
> for the last committed mistake", right? Again, I don't really want
> to document/archive (i.e. commit) my mistake. Or did I miss
> something here? 

git commit --amend
git reset HEAD^ and friends (to uncommit something)

-- 
Matthieu

Re: On git 1.6 (novice's opinion)

[Etienne Vallette d'Osia]

Ulrich Windl a écrit :
> AFAIK, "committing" in git is "kind of publishing your work" (others may pull it). 
> I don't like publishing my mistakes ;-) Even if no-one pulls the commit, your 
> "undo" refers to "committing a fix for the last committed mistake", right? Again, 
> I don't really want to document/archive (i.e. commit) my mistake. Or did I miss 
> something here?
> I know: Other's opinions are quite different on these issues.

commit is local.
The good way is to commit in your local and private repository.
Then you can do anything, reset commit you have just done, etc
When all is ok, you push in a public repository.

With this workflow, no one see your local work and you can commit very 
often, undo commit, rebase a lot etc.

The only result of a such job is a large number of useless objects in 
your local repository. They will be delete automatically by git, so it's 
not a problem.

Regard,
Etienne

Re: On git 1.6 (novice's opinion)

[Ulrich Windl]

On 27 Mar 2009 at 13:49, Michael J Gruber wrote:

> Ulrich Windl venit, vidit, dixit 27.03.2009 08:21:

[...]

> Keyword substitution and cvs/svn style version numbers are independent
> issues. The sha1 describes a commit uniquely, one could use that as a
> keyword.

However version numbers and time stamps have the property of being at least 
partially ordered in respect of "newer/older". That property does not hold for 
SHA-1 checksums. Just imagine suggesting users to upgrade from Microsoft 
Word/004765c2a1e9771e886f0dbe87d4f89643cd6f70 to Microsoft 
Word/00b7e6f51130f234a969c84ee9231a5ff7fc8a82 ;-)


> 
> Increasing version numbers are meaningless in a true DVCS world. What is
> your 100th commit may not be someone else's, even if both your master's
> heads are the same! This is why hg version numbers are a local thing.
> They are merely a local shortcut for specifying a revision and serve the
> same purpose as git's "backward" counts like HEAD~3 etc. Neither of them
> work permanently, not even in a local repo, if you allow rebasing.

Maybe I didn't fully understand, but having a version number that is larger than 
any parent's version numbers when doing a merge/commit doesn't look wrong to me.

> 
> git rev-list HEAD|wc may produce something like it, but be sure to read
> up on --sparse and --full-history.

I'm not deep enough into it, yet.

[...]

Regards,
Ulrich

Re: On git 1.6 (novice's opinion)

[Jakub Narebski]

"Ulrich Windl" <ulrich.windl@rz.uni-regensburg.de> writes:
> On 27 Mar 2009 at 13:49, Michael J Gruber wrote: 
> > Ulrich Windl venit, vidit, dixit 27.03.2009 08:21:
> 
> [...]
> 
> > Keyword substitution and cvs/svn style version numbers are independent
> > issues. The sha1 describes a commit uniquely, one could use that as a
> > keyword.
> 
> However version numbers and time stamps have the property of being at least 
> partially ordered in respect of "newer/older". That property does not hold for 
> SHA-1 checksums. Just imagine suggesting users to upgrade from Microsoft 
> Word/004765c2a1e9771e886f0dbe87d4f89643cd6f70 to Microsoft 
> Word/00b7e6f51130f234a969c84ee9231a5ff7fc8a82 ;-)

That is why people use output of git-describe and _tag_ their releases,
and make embedding version number in released version (tarball / binary)
the job of make: see GIT-VERSION-GEN script in git sources, and how it
is used in Makefile.

> 
> > 
> > Increasing version numbers are meaningless in a true DVCS world. What is
> > your 100th commit may not be someone else's, even if both your master's
> > heads are the same! This is why hg version numbers are a local thing.
> > They are merely a local shortcut for specifying a revision and serve the
> > same purpose as git's "backward" counts like HEAD~3 etc. Neither of them
> > work permanently, not even in a local repo, if you allow rebasing.
> 
> Maybe I didn't fully understand, but having a version number that is larger than 
> any parent's version numbers when doing a merge/commit doesn't look wrong to me.

I'm sorry to dissapoint you, but without central server assigning
numbers to commits it wouldn't simply work in distributed version
control world.  Take for example the following situation: somebody
clones your repository, and creates new commit on 'master' (trunk) and
it gets version number N.  Meanwhile you also independently create new
commit on 'master'... and without central authority it would also get
version number N.  Then you would merge (pull) his/her changes, and
you would have two commits with the same number; not something you want.

Not to mention that you can have multiple roots (multiple commits with
no parent) in git repository; besides independent branches (like
'man', 'html' or 'todo') it is usually result of absorbing or
subtree-merging other projects.  In 'master' branch there are 5 roots
or more: joined 'git-tools' (mailinfo / mailsplit), absorbed gitweb,
and subtree-merged gitk and git-gui.  And here you would again have
multiple commits with the same number...

The idea of generation numbers was discussed on git mailing list, but
rather as mechanism helping in faster topological ordering of commits
(--topo-sort)... but it was dropped.

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: On git 1.6 (novice's opinion)

[Junio C Hamano]

"Ulrich Windl" <ulrich.windl@rz.uni-regensburg.de> writes:

> ... Also some seemingly dangerous commands that cannot easily be undone
> should ask safety questions ("cvs merge (-j)" would also fall into that
> category.

This is slightly an interesting point.

In CVS and Subversion, "merge" (rather "update") can be a dangerous
operation.  You start working, you keep building, and you eventually
accumulate quite a lot of changes but you still cannot see the end of the
tunnel.  Your changes are incomplete and you will upset others if you
commit.  Your changes are extensive enough that it can conflict heavily
with what others have done already, and there is a high chance that you
can screw up the merging but there is no easy way (unless you tar-up the
whole work tree before attempting to update) to get back to the state
before your merge.  Damned if you commit, damned if you don't.  You lose
either way.

This is because you cannot have a local commit.  The problem is inherent
to the centralized nature of these systems.

Distributed systems are different.  Unlike CVS/Subversion's

	work work work; then

        update to merge, risk screwing up the work in progress (or almost
	finished work); then

        commit

workflow, in a distributed system, you first commit and then merge,
preferably from a clean slate.  You will not have to worry about screwing
up the conflict resolution, because both states (what the other guy did,
and what you did) are committed safely away and you can reset back to the
state before you start your merge.

Re: On git 1.6 (novice's opinion)

[Junio C Hamano]

Dmitry Potapov <dpotapov@gmail.com> writes:

> On Fri, Mar 27, 2009 at 12:50 PM, Ulrich Windl
> <ulrich.windl@rz.uni-regensburg.de> wrote:
>>
>> what made me wonder is this (about item 1): I thought I've read that blobs store
>> content and attributes, so very obviously I wondered why not store thr "right
>> attributes" (i.e. the time of the file). My reasoning: You make some changes, then
>> test them (which might last several hours or days). The if I'm happy I'll
>> "commit".
>
> With Git, you usually commit your changes immediately (without waiting
> the result
> of testing), because you can always undo commit until you publish your changes.

Heh, "can" and "usually" are somewhat different.  I don't.

Re: On git 1.6 (novice's opinion)

[Junio C Hamano]

"Ulrich Windl" <ulrich.windl@rz.uni-regensburg.de> writes:

> AFAIK, "committing" in git is "kind of publishing your work" (others may
> pull it).

You, like all the other people who worked with centralized systems for too
long, need a break from this misconception.  Once you get rid of it, you
will realize that the separation of commit (which is merely "recording so
that you can later refer to it, including for the purposes of going back
to it, comparing something else with it and merge something else with it")
and push (which is the "publishing" part) is the fundamental difference
between centralized and distributed systems.  It frees you from having to
worry about the "damned if you commit, damned if you don't" issue I
mentioned in my other message.

Re: On git 1.6 (novice's opinion)

[Dmitry Potapov]

On Sat, Mar 28, 2009 at 4:30 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Dmitry Potapov <dpotapov@gmail.com> writes:
>
>> On Fri, Mar 27, 2009 at 12:50 PM, Ulrich Windl
>> <ulrich.windl@rz.uni-regensburg.de> wrote:
>>>
>>> what made me wonder is this (about item 1): I thought I've read that blobs store
>>> content and attributes, so very obviously I wondered why not store thr "right
>>> attributes" (i.e. the time of the file). My reasoning: You make some changes, then
>>> test them (which might last several hours or days). The if I'm happy I'll
>>> "commit".
>>
>> With Git, you usually commit your changes immediately (without waiting
>> the result
>> of testing), because you can always undo commit until you publish your changes.
>
> Heh, "can" and "usually" are somewhat different.  I don't.

Fair enough. But I was refering to the situation where testing may take
several hours or days. Leaving uncommitted changes in your working tree
for a few days is rarely a good idea if you can undo the commit later. Of
course, the situation is different if the testing takes only a couple minutes.

Dmitry

Re: On git 1.6 (novice's opinion)

[demerphq]

2009/3/27 Ulrich Windl <ulrich.windl@rz.uni-regensburg.de>:
> On 27 Mar 2009 at 13:49, Michael J Gruber wrote:
>
>> Ulrich Windl venit, vidit, dixit 27.03.2009 08:21:
>
> [...]
>
>> Keyword substitution and cvs/svn style version numbers are independent
>> issues. The sha1 describes a commit uniquely, one could use that as a
>> keyword.
>
> However version numbers and time stamps have the property of being at least
> partially ordered in respect of "newer/older". That property does not hold for
> SHA-1 checksums. Just imagine suggesting users to upgrade from Microsoft
> Word/004765c2a1e9771e886f0dbe87d4f89643cd6f70 to Microsoft
> Word/00b7e6f51130f234a969c84ee9231a5ff7fc8a82 ;-)

The problem here is that in some "version control" systems the concept
of "release version" has been conflated with "version control system
revision number".

They arent the same thing, never were, and conflating the two only
caused and causes trouble.

A "release version" is a *tag*, always has been or should have been
really, and in git is in fact.

Cheers,
yves



-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

Re: On git 1.6 (novice's opinion)

[Bryan Donlan]

On Fri, Mar 27, 2009 at 3:21 AM, Ulrich Windl
<ulrich.windl@rz.uni-regensburg.de> wrote:


> 3) "git undo": If possible undo the effects of the last command.

You can roll back the state of most local references by using the git
reflog (see git reflog --help for more information). This covers most
situations - but note that it only works to roll back to a committed
state, and won't save any uncommitted data at all.

Re: On git 1.6 (novice's opinion)

[Johannes Schindelin]

Hi,

On Sun, 29 Mar 2009, Bryan Donlan wrote:

> On Fri, Mar 27, 2009 at 3:21 AM, Ulrich Windl
> <ulrich.windl@rz.uni-regensburg.de> wrote:
> 
> > 3) "git undo": If possible undo the effects of the last command.
> 
> You can roll back the state of most local references by using the git 
> reflog (see git reflog --help for more information). This covers most 
> situations - but note that it only works to roll back to a committed 
> state, and won't save any uncommitted data at all.

Which is why you should commit early and often, and certainly before doing 
something bigger.

Ciao,
Dscho

Re: On git 1.6 (novice's opinion)

[Russ Dill]

On Fri, Mar 27, 2009 at 2:50 AM, Ulrich Windl
<ulrich.windl@rz.uni-regensburg.de> wrote:
> On 27 Mar 2009 at 9:05, H.Merijn Brand wrote:
>
>> On Fri, 27 Mar 2009 08:21:36 +0100, "Ulrich Windl"
>> <ulrich.windl@rz.uni-regensburg.de> wrote:
>>
>> > What I'd like to see in git (My apologies if some were already discussed to
>> > death):
>> >
>> > 1) The ability to use the file's time at the time of add/commit instead of
>> >    the current time, and the ability tho check outfiles with the times stored
>> >    in the repository.
>> >
>> > 2) Keyword substitution. I know it's controverse (dealing with binary files),
>> >    but I'd like to have some automatic version numbering keyword at least:
>> >    Initial idea is that every commit with a change increments the number by
>> >    one, and when merging numbers a and b, the resulting number is max(a, b) + 1.
>>
>> impossible. Even with checkin- and checkout hooks, you won't get that
>> SCCS behaviour. They have to be better in something too :)
>> /me still misses that but got used to it
>
> Hi,
>
> what made me wonder is this (about item 1): I thought I've read that blobs store
> content and attributes, so very obviously I wondered why not store thr "right
> attributes" (i.e. the time of the file). My reasoning: You make some changes, then
> test them (which might last several hours or days). The if I'm happy I'll
> "commit". Naturally I want to see the time of change for each file when the change
> had been actually made, not when the change was committed. Likewise when checking
> out, I want to be able to see the time of modification, not the time of commit.
> I'm aware that many people don't care about such differences...
>

Ok, so if Nancy did some work on the part number form 6 months ago,
but it got merged into master yesterday. What date should the file
have? This kind of incremental version number, and trusting of file
dates really only matters on a centralized system with a single
branch.

Not only that, but modification times are much more useful with make.
Merging or pulling small changes into a tree shouldn't require a full
rebuild of the entire tree which in some cases could take hours.
Especially since 'git log <file>', 'gitk <file>', or 'git blame
<file>' give much more information anyway.

I know some people sort their directory by date to see what kind of
stuff happened since they last worked on the repository, but it
doesn't scale to a project with many directories and the log is much
more useful anyway.

Re: On git 1.6 (novice's opinion)

[Andreas Ericsson]

Ulrich Windl wrote:
> 
> 1) The ability to use the file's time at the time of add/commit instead of the
> current time, and the ability tho check outfiles with the times stored in the
> repository.
> 

You can set the time manually for each commit. I suppose it's not quite the
same as doing it by taking the timestamp of a single file. Personally, I've
never quite understood the point of it, since I always have to do at least
*some* testing (even if it's only a compile-test) after I'm done editing so
I know what I'm committing isn't totally broken.

Can you describe a use-case where this would be handy?

> 2) Keyword substitution. I know it's controverse (dealing with binary files),
> but I'd like to have some automatic version numbering keyword at least:
> Initial idea is that every commit with a change increments the number by one,
> and when merging numbers a and b, the resulting number is max(a, b) + 1.
> 

This has been discussed to death, and it's much, much harier than just
handling binary files. Browse the list archives for the (many, lengthy and
sometimes heated) discussions on this topic. A quick recap of the outcome
of *ALL* such discussions is as follows, though:
1 It would potentially make git horribly slow at switching branches.
2 It's rarely interesting to version a single file, but always interesting
  to version the entire project (what do I care if README was v1,1 in CVS
  when what I *really* want to know is which version of the program I should
  file my bug-report against).
3 It's far better to set the version number in the release-process. Usually
  this can be done automatically by one invocation of "git describe", just
  as git.git does it.

We've adopted "3" full out at $dayjob. Our build-machinery gets the version
number from the git tag (releases can only be built from signed tags), and
it updates macros and whatnot used for informing the user which version he
or she is running. This makes a lot more sense both from a bug-reporting
and from a release process view than having generated version-numbers in
files. On a side-note; When I told my co-workers I'd like us to switch to
git, two of them asked about autoversioning features. I said there weren't
any and asked them to name a single time when we've actually used them for
anything *at all*. In a team of eight, having been programming for three
years with 12 releases and about 800 bugreports + feature-requests, noone
could mention a single time when the autogenerated version numbers had
actually been used for anything.

Otoh, having the entire repository locally makes it painless to view the
commit-log for an entire project (or parts of it) and see who changed what
when and why, which is information that's actually *useful*.

> 3) "git undo": If possible undo the effects of the last command.
> 

Immensely complex to create, and the command would almost certainly cause
more confusion than order before it can handle every single operation that
a user would want to undo. Instead, the most common operations that require
some form of user-interaction have an "--abort" switch which does roughly
what a "git undo" command would.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

Re: On git 1.6 (novice's opinion)

[Kris Shannon]

2009/3/27 Ulrich Windl <ulrich.windl@rz.uni-regensburg.de>:
> 2) Keyword substitution. I know it's controverse (dealing with binary files),
> but I'd like to have some automatic version numbering keyword at least:
> Initial idea is that every commit with a change increments the number by one,
> and when merging numbers a and b, the resulting number is max(a, b) + 1.

Check out gitattributes(5) - the ident attribute:

When the attribute ident is set for a path, git replaces $Id$ in the blob
object with $Id:, followed by the 40-character hexadecimal blob object name,
followed by a dollar sign $ upon checkout. Any byte sequence that begins
with $Id: and ends with $ in the worktree file is replaced with $Id$ upon
check-in.

That means the Id is file specific, not commit specific - just like the $Id$
expansion for CVS and SCCS is about the file (as there is no real concept
of a commit in CVS and SCCS)

Re: On git 1.6 (novice's opinion)

[Ulrich Windl]

On 27 Mar 2009 at 14:44, Matthieu Moy wrote:

> "Ulrich Windl" <ulrich.windl@rz.uni-regensburg.de> writes:
> 
> > I don't understand:
> > If I modify files, then do a make, then do check-in/check-out (and the file times 
> > are unchanged), how would that affect make?
> 
> From "make"'s point of view, chechout is just a modification of the
> file (as any other modification you would do with a text editor). If
> you compile foo.c to foo.o, then checkout another version of foo.c,
> then you want foo.c to be recompiled. If checkout modifies the
> timestamp to pretend it was modified before foo.o, then make thinks
> the file is up to date.
> 
> > If I do an "update/merge from remote" (there is no total ordering of release 
> > numbers anyway) without a "make clean" before, I'm having a problem
> > anyway.
> 
> No, you don't have a problem. Recompiling files after they're modified
> is the job of make, and it just does it. make doesn't know about
> revision numbers or identifiers, just timestamps.

Hi!

If you compiled a Linux kernel, then do an "upgrade" to the tree, it's quite 
likely that a "make clean" after that upgrade does something different to the 
"make clean" before the upgrade. Thus I'd "make clean" before the upgrade. (which, 
I think, proves my point)

Regards,
Ulrich

Re: On git 1.6 (novice's opinion)

[Ulrich Windl]

On 27 Mar 2009 at 14:47, Etienne Vallette d'Osia wrote:

> Ulrich Windl a écrit :
> > AFAIK, "committing" in git is "kind of publishing your work" (others may pull it). 
> > I don't like publishing my mistakes ;-) Even if no-one pulls the commit, your 
> > "undo" refers to "committing a fix for the last committed mistake", right? Again, 
> > I don't really want to document/archive (i.e. commit) my mistake. Or did I miss 
> > something here?
> > I know: Other's opinions are quite different on these issues.
> 
> commit is local.

I had made the experience that you can "pull" from a local directory (unless 
permissions forbid it). As I can't control what others are doing, a "commit" is 
still more or less making the results public (unless you can convince me that 
	I'm wrong). OK, I grew up with servers that host hundreds of users, not with 
having my own laptop...

> The good way is to commit in your local and private repository.
> Then you can do anything, reset commit you have just done, etc
> When all is ok, you push in a public repository.
> 
> With this workflow, no one see your local work and you can commit very 
> often, undo commit, rebase a lot etc.
> 
> The only result of a such job is a large number of useless objects in 
> your local repository. They will be delete automatically by git, so it's 
> not a problem.
> 
> Regard,
> Etienne

Re: On git 1.6 (novice's opinion)

[Ulrich Windl]

On 27 Mar 2009 at 7:09, Jakub Narebski wrote:

> "Ulrich Windl" <ulrich.windl@rz.uni-regensburg.de> writes:
> > On 27 Mar 2009 at 13:49, Michael J Gruber wrote: 
> > > Ulrich Windl venit, vidit, dixit 27.03.2009 08:21:
> > 
> > [...]
> > 
> > > Keyword substitution and cvs/svn style version numbers are independent
> > > issues. The sha1 describes a commit uniquely, one could use that as a
> > > keyword.
> > 
> > However version numbers and time stamps have the property of being at least 
> > partially ordered in respect of "newer/older". That property does not hold for 
> > SHA-1 checksums. Just imagine suggesting users to upgrade from Microsoft 
> > Word/004765c2a1e9771e886f0dbe87d4f89643cd6f70 to Microsoft 
> > Word/00b7e6f51130f234a969c84ee9231a5ff7fc8a82 ;-)
> 
> That is why people use output of git-describe and _tag_ their releases,
> and make embedding version number in released version (tarball / binary)
> the job of make: see GIT-VERSION-GEN script in git sources, and how it
> is used in Makefile.

OK, but imaginge someone sends you some file that originated from some git 
version, maybe with minor modifications. Is there a way to find out from what git 
version that file was derived? IMHO that's where "automatically replaced 
placeholders" (like $id$) make sense.

> 
> > 
> > > 
> > > Increasing version numbers are meaningless in a true DVCS world. What is
> > > your 100th commit may not be someone else's, even if both your master's
> > > heads are the same! This is why hg version numbers are a local thing.
> > > They are merely a local shortcut for specifying a revision and serve the
> > > same purpose as git's "backward" counts like HEAD~3 etc. Neither of them
> > > work permanently, not even in a local repo, if you allow rebasing.
> > 
> > Maybe I didn't fully understand, but having a version number that is larger than 
> > any parent's version numbers when doing a merge/commit doesn't look wrong to me.
> 
> I'm sorry to dissapoint you, but without central server assigning
> numbers to commits it wouldn't simply work in distributed version
> control world.  Take for example the following situation: somebody
> clones your repository, and creates new commit on 'master' (trunk) and
> it gets version number N.  Meanwhile you also independently create new
> commit on 'master'... and without central authority it would also get
> version number N.  Then you would merge (pull) his/her changes, and
> you would have two commits with the same number; not something you want.

Anyway the result would have number "N+1". Maybe you misunderstood: I'm not 
proposing to replace git's internal version numbering (SHA-1), but so introduce 
some more comprehensible, primitive user-level numbering.

> 
> Not to mention that you can have multiple roots (multiple commits with
> no parent) in git repository; besides independent branches (like
> 'man', 'html' or 'todo') it is usually result of absorbing or
> subtree-merging other projects.  In 'master' branch there are 5 roots
> or more: joined 'git-tools' (mailinfo / mailsplit), absorbed gitweb,
> and subtree-merged gitk and git-gui.  And here you would again have
> multiple commits with the same number...

Which would not harm, because it would be version N from committer X. Any if 
committer X merges from anything else, the next number would be > N. I did not 
claim that my method makes a total ordering of commits and merges possible.

I truly believe in unique IDs, but they are just not handy in every situation.

[...]

Regards,
Ulrich

Re: On git 1.6 (novice's opinion)

[Andreas Ericsson]

Ulrich Windl wrote:
> On 27 Mar 2009 at 7:09, Jakub Narebski wrote:
> 
>> "Ulrich Windl" <ulrich.windl@rz.uni-regensburg.de> writes:
>>> On 27 Mar 2009 at 13:49, Michael J Gruber wrote: 
>>>> Ulrich Windl venit, vidit, dixit 27.03.2009 08:21:
>>> [...]
>>>
>>>> Keyword substitution and cvs/svn style version numbers are independent
>>>> issues. The sha1 describes a commit uniquely, one could use that as a
>>>> keyword.
>>> However version numbers and time stamps have the property of being at least 
>>> partially ordered in respect of "newer/older". That property does not hold for 
>>> SHA-1 checksums. Just imagine suggesting users to upgrade from Microsoft 
>>> Word/004765c2a1e9771e886f0dbe87d4f89643cd6f70 to Microsoft 
>>> Word/00b7e6f51130f234a969c84ee9231a5ff7fc8a82 ;-)
>> That is why people use output of git-describe and _tag_ their releases,
>> and make embedding version number in released version (tarball / binary)
>> the job of make: see GIT-VERSION-GEN script in git sources, and how it
>> is used in Makefile.
> 
> OK, but imaginge someone sends you some file that originated from some git 
> version, maybe with minor modifications. Is there a way to find out from what git 
> version that file was derived? IMHO that's where "automatically replaced 
> placeholders" (like $id$) make sense.
> 

Actually, that's where communication makes sense. With the CVS style keywords,
that file could have come from 1.3.7, or 2.9.1 (if it hasn't changed), and
the bug the changes are fixing might be in some other file entirely (such as
a header file on some particular system, but the offending call could well
be made in some other file).

If they build from the version control system, they're most likely quite
competent enough in finding the version number of the project they're using.
If they're building from sources, you can easily put the version number of
the project in every source-file you have with just a simple sed script.
Git makes that quite easy for you. Consider something like this:

--8<--8<-- release.sh --8<--8<--
#!/bin/sh
project=foo
latest_tag=$(git describe --abbrev=0)
version=$(echo tag | sed 's/^v//')
git archive --format=tar $latest_tag --prefix=$project-$version/ | \
	sed s/@@VERSION@@/$version/ | \
	gzip -9 > $project-$version.tar.gz
--8<--8<--8<--8<--

Now, if you put @@VERSION@@ as the keyword in all the source-files, all
the files released as anything but a clone of your version control system
will have a version tag that marks the version of your *project* rather
than some arbitrary number indicating how many times that particular file
has been changed over the course of your project.

I know which I prefer.

>>>> Increasing version numbers are meaningless in a true DVCS world. What is
>>>> your 100th commit may not be someone else's, even if both your master's
>>>> heads are the same! This is why hg version numbers are a local thing.
>>>> They are merely a local shortcut for specifying a revision and serve the
>>>> same purpose as git's "backward" counts like HEAD~3 etc. Neither of them
>>>> work permanently, not even in a local repo, if you allow rebasing.
>>> Maybe I didn't fully understand, but having a version number that is larger than 
>>> any parent's version numbers when doing a merge/commit doesn't look wrong to me.
>> I'm sorry to dissapoint you, but without central server assigning
>> numbers to commits it wouldn't simply work in distributed version
>> control world.  Take for example the following situation: somebody
>> clones your repository, and creates new commit on 'master' (trunk) and
>> it gets version number N.  Meanwhile you also independently create new
>> commit on 'master'... and without central authority it would also get
>> version number N.  Then you would merge (pull) his/her changes, and
>> you would have two commits with the same number; not something you want.
> 
> Anyway the result would have number "N+1". Maybe you misunderstood: I'm not 
> proposing to replace git's internal version numbering (SHA-1), but so introduce 
> some more comprehensible, primitive user-level numbering.
> 

It's been discussed to death and noone has been able to solve all the corner
cases. If you do, feel free to send the patches. In my experience though, the
git notation (HEAD~3) is totally superior to any made-up version numbers.
This is because in 99% of the cases where you're referring to anything but
"latest", you're either interested in some stable release (which should be
tagged, so you get to pick whatever version number you want) for diffing
purposes, or you want a *range* of commits (to send as patches, or to give
as an indication of "I think something happened somewhere here"), and the
backward count notation of git fits that mindset a whole lot better than
having numbers that increment from the start, and therefore quickly become
as unwieldy as the SHA1's for the human brain.

>> Not to mention that you can have multiple roots (multiple commits with
>> no parent) in git repository; besides independent branches (like
>> 'man', 'html' or 'todo') it is usually result of absorbing or
>> subtree-merging other projects.  In 'master' branch there are 5 roots
>> or more: joined 'git-tools' (mailinfo / mailsplit), absorbed gitweb,
>> and subtree-merged gitk and git-gui.  And here you would again have
>> multiple commits with the same number...
> 
> Which would not harm, because it would be version N from committer X. Any if 
> committer X merges from anything else, the next number would be > N. I did not 
> claim that my method makes a total ordering of commits and merges possible.
> 
> I truly believe in unique IDs, but they are just not handy in every situation.
> 

What do they solve that the HEAD~3 syntax does not?

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

Re: On git 1.6 (novice's opinion)

[Ulrich Windl]

On 27 Mar 2009 at 18:30, Junio C Hamano wrote:

> "Ulrich Windl" <ulrich.windl@rz.uni-regensburg.de> writes:
> 
> > ... Also some seemingly dangerous commands that cannot easily be undone
> > should ask safety questions ("cvs merge (-j)" would also fall into that
> > category.
> 
> This is slightly an interesting point.
> 
> In CVS and Subversion, "merge" (rather "update") can be a dangerous
> operation.  You start working, you keep building, and you eventually
> accumulate quite a lot of changes but you still cannot see the end of the
> tunnel.  Your changes are incomplete and you will upset others if you
> commit.  Your changes are extensive enough that it can conflict heavily
> with what others have done already, and there is a high chance that you
> can screw up the merging but there is no easy way (unless you tar-up the
> whole work tree before attempting to update) to get back to the state
> before your merge.  Damned if you commit, damned if you don't.  You lose
> either way.
> 
> This is because you cannot have a local commit.  The problem is inherent
> to the centralized nature of these systems.
> 
> Distributed systems are different.  Unlike CVS/Subversion's
> 
> 	work work work; then
> 
>         update to merge, risk screwing up the work in progress (or almost
> 	finished work); then
> 
>         commit
> 
> workflow, in a distributed system, you first commit and then merge,
> preferably from a clean slate.  You will not have to worry about screwing
> up the conflict resolution, because both states (what the other guy did,
> and what you did) are committed safely away and you can reset back to the
> state before you start your merge.

Hi!

OK, that example is not that dangerous in git, but git also has commands a 
beginner could make some undesired damage ("git rebase", maybe).

Regards,
Ulrich

Re: On git 1.6 (novice's opinion)

[Ulrich Windl]

On 29 Mar 2009 at 1:41, Bryan Donlan wrote:

> On Fri, Mar 27, 2009 at 3:21 AM, Ulrich Windl
> <ulrich.windl@rz.uni-regensburg.de> wrote:
> 
> 
> > 3) "git undo": If possible undo the effects of the last command.
> 
> You can roll back the state of most local references by using the git
> reflog (see git reflog --help for more information). This covers most
> situations - but note that it only works to roll back to a committed
> state, and won't save any uncommitted data at all.

Hmm...kind of an idea:

"git undo <command>" print help text on how to undo the effect of <command>.
I feel that may be useful. maybe replace "undo" with "undo-instructions".

Regards,
Ulrich

Re: On git 1.6 (novice's opinion)

[Matthieu Moy]

"Ulrich Windl" <ulrich.windl@rz.uni-regensburg.de> writes:

> On 27 Mar 2009 at 14:47, Etienne Vallette d'Osia wrote:
>
>> Ulrich Windl a écrit :
>> > AFAIK, "committing" in git is "kind of publishing your work" (others may pull it). 
>> > I don't like publishing my mistakes ;-) Even if no-one pulls the commit, your 
>> > "undo" refers to "committing a fix for the last committed mistake", right? Again, 
>> > I don't really want to document/archive (i.e. commit) my mistake. Or did I miss 
>> > something here?
>> > I know: Other's opinions are quite different on these issues.
>> 
>> commit is local.
>
> I had made the experience that you can "pull" from a local directory (unless 
> permissions forbid it). As I can't control what others are doing, a "commit" is 
> still more or less making the results public (unless you can convince me that 
> 	I'm wrong). OK, I grew up with servers that host hundreds of users, not with 
> having my own laptop...

Multi-users server, or NFS-shared $HOME, yes, expose every working
tree and therefore directories to other users. But still, the good
practice would be to distinguish your working area, and a "clean"
area if you want to get all the power of distributed version control.

One of the main points in having version control distributed is
precisely to allow you to distinguish private things and published
ones (i.e. commit != push). Linus explains this better than I do in
his talk:

  http://www.youtube.com/watch?v=4XpnKHJAok8

You _can_ expose your working tree directly to others, but if you do
so, you'll have to forget about "git commit --amend", 
"git reset <anything-else-than-HEAD>", "git rebase", 
"git filter-branch", ... (any history-editing feature of Git indeed).

OTOH, the common setup for people is to have a workstation (laptop or
desktop) without a public access (for example, my home computer is
switched of when I'm not using it, and my office station is only
reachable from outside with ssh), and to publish things on another
server. So, in the common case, the distinction private/public is
natural.

-- 
Matthieu

Re: On git 1.6 (novice's opinion)

[Matthieu Moy]

"Ulrich Windl" <ulrich.windl@rz.uni-regensburg.de> writes:

> If you compiled a Linux kernel, then do an "upgrade" to the tree, it's quite 
> likely that a "make clean" after that upgrade does something different to the 
> "make clean" before the upgrade. Thus I'd "make clean" before the upgrade. (which, 
> I think, proves my point)

But why do a "make clean", at all?

-- 
Matthieu

Re: On git 1.6 (novice's opinion)

[Ulrich Windl]

On 29 Mar 2009 at 11:50, Johannes Schindelin wrote:

> Hi,
> 
> On Sun, 29 Mar 2009, Bryan Donlan wrote:
> 
> > On Fri, Mar 27, 2009 at 3:21 AM, Ulrich Windl
> > <ulrich.windl@rz.uni-regensburg.de> wrote:
> > 
> > > 3) "git undo": If possible undo the effects of the last command.
> > 
> > You can roll back the state of most local references by using the git 
> > reflog (see git reflog --help for more information). This covers most 
> > situations - but note that it only works to roll back to a committed 
> > state, and won't save any uncommitted data at all.
> 
> Which is why you should commit early and often, and certainly before doing 
> something bigger.

A user will only "commit" if he knows how to "undo" it. Proposing to use "commit" 
to help with "undo" is a partial solution at best...

> 
> Ciao,
> Dscho
> 

Re: On git 1.6 (novice's opinion)

[Ulrich Windl]

On 29 Mar 2009 at 23:18, Russ Dill wrote:

> On Fri, Mar 27, 2009 at 2:50 AM, Ulrich Windl
> <ulrich.windl@rz.uni-regensburg.de> wrote:
> > On 27 Mar 2009 at 9:05, H.Merijn Brand wrote:
> >
> >> On Fri, 27 Mar 2009 08:21:36 +0100, "Ulrich Windl"
> >> <ulrich.windl@rz.uni-regensburg.de> wrote:
> >>
> >> > What I'd like to see in git (My apologies if some were already discussed to
> >> > death):
> >> >
> >> > 1) The ability to use the file's time at the time of add/commit instead of
> >> >    the current time, and the ability tho check outfiles with the times stored
> >> >    in the repository.
> >> >
> >> > 2) Keyword substitution. I know it's controverse (dealing with binary files),
> >> >    but I'd like to have some automatic version numbering keyword at least:
> >> >    Initial idea is that every commit with a change increments the number by
> >> >    one, and when merging numbers a and b, the resulting number is max(a, b) + 1.
> >>
> >> impossible. Even with checkin- and checkout hooks, you won't get that
> >> SCCS behaviour. They have to be better in something too :)
> >> /me still misses that but got used to it
> >
> > Hi,
> >
> > what made me wonder is this (about item 1): I thought I've read that blobs store
> > content and attributes, so very obviously I wondered why not store thr "right
> > attributes" (i.e. the time of the file). My reasoning: You make some changes, then
> > test them (which might last several hours or days). The if I'm happy I'll
> > "commit". Naturally I want to see the time of change for each file when the change
> > had been actually made, not when the change was committed. Likewise when checking
> > out, I want to be able to see the time of modification, not the time of commit.
> > I'm aware that many people don't care about such differences...
> >
> 
> Ok, so if Nancy did some work on the part number form 6 months ago,
> but it got merged into master yesterday. What date should the file
> have? This kind of incremental version number, and trusting of file

If Nancy committed it with my semantics, the file's date would be 6 months old 
before the merge. If the merge would not require any change, the file's date would 
still be six months old. If a change was required, the file's date would be the 
time of change. That sounds quite logical to me.

> dates really only matters on a centralized system with a single
> branch.
> 
> Not only that, but modification times are much more useful with make.
> Merging or pulling small changes into a tree shouldn't require a full
> rebuild of the entire tree which in some cases could take hours.

Git is not a build system, and I really dislike "full rebuilds", but for 
stability, before releasing anything, one should test it with a full rebuild. I 
think that's what configuration management systems are about. So for a merge or 
checkout of any make source object (opposed to: make target object), an automated 
cleanup of the corresponding target objects should be made. I know that you don't 
like it, but for RCS you have the couce whether to check-in with "-d", or check 
out with "-M". If it's optional in GIT also, you shouldn't be unhappy.

> Especially since 'git log <file>', 'gitk <file>', or 'git blame
> <file>' give much more information anyway.
> 
> I know some people sort their directory by date to see what kind of
> stuff happened since they last worked on the repository, but it
> doesn't scale to a project with many directories and the log is much
> more useful anyway.

I agree.

Regards,
Ulrich

Re: On git 1.6 (novice's opinion)

[Matthieu Moy]

"Ulrich Windl" <ulrich.windl@rz.uni-regensburg.de> writes:

>> Not to mention that you can have multiple roots (multiple commits with
>> no parent) in git repository; besides independent branches (like
>> 'man', 'html' or 'todo') it is usually result of absorbing or
>> subtree-merging other projects.  In 'master' branch there are 5 roots
>> or more: joined 'git-tools' (mailinfo / mailsplit), absorbed gitweb,
>> and subtree-merged gitk and git-gui.  And here you would again have
>> multiple commits with the same number...
>
> Which would not harm, because it would be version N from committer X. Any if 
> committer X merges from anything else, the next number would be > N. I did not 
> claim that my method makes a total ordering of commits and merges possible.

Neither does it make the numbers unique for committer X.

If commiter X commits a successor to commit N, it's labeled N+1. If
later, he creates another branch from commit N, and commit, the new,
other commit will be labeled N+1.

This means even within a repository, you cannot say things like
"commit number N", so, OK, you have numerical IDs, but you can't use
them.

What can be interesting is that a commit takes 
max{all commits in repository}+1, not just max{parents} + 1. Then, you
have local revision numbers, but they're not stable. Indeed, that's
precisely what Mercurial does.

But I'm not sure how much simplicity it adds compared to the confusion
it adds. Newbies will see Mercurial identifiers as

changeset:   2:699b81a5851b
changeset:   1:fd4b6597548f
changeset:   0:58cff172192e

And think "OK, the revision numbers are 0, 1, 2, and the hexadecimal
stuff beside is useless". And one day, he'll send a mail, post a
bugreport, or whatever, saying "I have a problem with revision number
42", and no one else but him will know which revision is called "42".

> I truly believe in unique IDs, but they are just not handy in every situation.

Usually, people find Git IDs to be non-handy until the find out they
can cut-and-paste only the first few digits in most cases, like
442dd42 instead of 442dd42d6d4903640b0dc5561481a77c88dcea90 ;-).

-- 
Matthieu

Re: On git 1.6 (novice's opinion)

[Ulrich Windl]

On 30 Mar 2009 at 11:06, Andreas Ericsson wrote:

[...]
> 3 It's far better to set the version number in the release-process. Usually
>   this can be done automatically by one invocation of "git describe", just
>   as git.git does it.

However if you put a version number into every file and THEN commit, it's somewhat 
ridiculous (I'll have to learn about "git describe"). But for configuration 
management you want to have exactly that (find exactly the file that was shipped 
(or used to build)).

> 
> We've adopted "3" full out at $dayjob. Our build-machinery gets the version
> number from the git tag (releases can only be built from signed tags), and
> it updates macros and whatnot used for informing the user which version he
> or she is running. This makes a lot more sense both from a bug-reporting
> and from a release process view than having generated version-numbers in

So your "release commits" are outside GIT? (see above)

> files. On a side-note; When I told my co-workers I'd like us to switch to
> git, two of them asked about autoversioning features. I said there weren't
> any and asked them to name a single time when we've actually used them for
> anything *at all*. In a team of eight, having been programming for three
> years with 12 releases and about 800 bugreports + feature-requests, noone
> could mention a single time when the autogenerated version numbers had
> actually been used for anything.

Hmm: Were they visible to customers?

> 
> Otoh, having the entire repository locally makes it painless to view the
> commit-log for an entire project (or parts of it) and see who changed what
> when and why, which is information that's actually *useful*.

[Big meals need time to digest: Just give me more time to do so (getting into 
git). As with vi and Emacs (usualy I prefer Emacs), there will be situations when 
I won't use Git however]

Regards,
Ulrich

Re: On git 1.6 (novice's opinion)

[Andreas Ericsson]

Ulrich Windl wrote:
> On 29 Mar 2009 at 23:18, Russ Dill wrote:
> 
>> On Fri, Mar 27, 2009 at 2:50 AM, Ulrich Windl
>> <ulrich.windl@rz.uni-regensburg.de> wrote:
>>> On 27 Mar 2009 at 9:05, H.Merijn Brand wrote:
>>>
>>>> On Fri, 27 Mar 2009 08:21:36 +0100, "Ulrich Windl"
>>>> <ulrich.windl@rz.uni-regensburg.de> wrote:
>>>>
>>>>> What I'd like to see in git (My apologies if some were already discussed to
>>>>> death):
>>>>>
>>>>> 1) The ability to use the file's time at the time of add/commit instead of
>>>>>    the current time, and the ability tho check outfiles with the times stored
>>>>>    in the repository.
>>>>>
>>>>> 2) Keyword substitution. I know it's controverse (dealing with binary files),
>>>>>    but I'd like to have some automatic version numbering keyword at least:
>>>>>    Initial idea is that every commit with a change increments the number by
>>>>>    one, and when merging numbers a and b, the resulting number is max(a, b) + 1.
>>>> impossible. Even with checkin- and checkout hooks, you won't get that
>>>> SCCS behaviour. They have to be better in something too :)
>>>> /me still misses that but got used to it
>>> Hi,
>>>
>>> what made me wonder is this (about item 1): I thought I've read that blobs store
>>> content and attributes, so very obviously I wondered why not store thr "right
>>> attributes" (i.e. the time of the file). My reasoning: You make some changes, then
>>> test them (which might last several hours or days). The if I'm happy I'll
>>> "commit". Naturally I want to see the time of change for each file when the change
>>> had been actually made, not when the change was committed. Likewise when checking
>>> out, I want to be able to see the time of modification, not the time of commit.
>>> I'm aware that many people don't care about such differences...
>>>
>> Ok, so if Nancy did some work on the part number form 6 months ago,
>> but it got merged into master yesterday. What date should the file
>> have? This kind of incremental version number, and trusting of file
> 
> If Nancy committed it with my semantics, the file's date would be 6 months old 
> before the merge. If the merge would not require any change, the file's date would 
> still be six months old. If a change was required, the file's date would be the 
> time of change. That sounds quite logical to me.
> 

But if you built the old source before you merged but after Nancy made her
changes, make wouldn't grok that the file is actually changed. Trust me,
the current semantics are far better.

>> dates really only matters on a centralized system with a single
>> branch.
>>
>> Not only that, but modification times are much more useful with make.
>> Merging or pulling small changes into a tree shouldn't require a full
>> rebuild of the entire tree which in some cases could take hours.
> 
> Git is not a build system, and I really dislike "full rebuilds", but for 
> stability, before releasing anything, one should test it with a full rebuild.

I build all the time. Before and after every commit (merges are one type of
commit). I rely on file timestamps to be an accurate indicator of when the
file last changed *on my disk*.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

Re: On git 1.6 (novice's opinion)

[Andreas Ericsson]

Ulrich Windl wrote:
> On 30 Mar 2009 at 11:06, Andreas Ericsson wrote:
> 
> [...]
>> 3 It's far better to set the version number in the release-process. Usually
>>   this can be done automatically by one invocation of "git describe", just
>>   as git.git does it.
> 
> However if you put a version number into every file and THEN commit, it's somewhat 
> ridiculous (I'll have to learn about "git describe"). But for configuration 
> management you want to have exactly that (find exactly the file that was shipped 
> (or used to build)).
> 
>> We've adopted "3" full out at $dayjob. Our build-machinery gets the version
>> number from the git tag (releases can only be built from signed tags), and
>> it updates macros and whatnot used for informing the user which version he
>> or she is running. This makes a lot more sense both from a bug-reporting
>> and from a release process view than having generated version-numbers in
> 
> So your "release commits" are outside GIT? (see above)
> 

They aren't release commits. Just a script that creates a tarball and an RPM
(in our case).

>> files. On a side-note; When I told my co-workers I'd like us to switch to
>> git, two of them asked about autoversioning features. I said there weren't
>> any and asked them to name a single time when we've actually used them for
>> anything *at all*. In a team of eight, having been programming for three
>> years with 12 releases and about 800 bugreports + feature-requests, noone
>> could mention a single time when the autogenerated version numbers had
>> actually been used for anything.
> 
> Hmm: Were they visible to customers?
> 

Ofcourse they were, but they were rather useless even there, as a customer
could upgrade and the $Id$ tag still wouldn't get updated. It caused a lot
of confusion for our not-so-techsavvy users and customers.

>> Otoh, having the entire repository locally makes it painless to view the
>> commit-log for an entire project (or parts of it) and see who changed what
>> when and why, which is information that's actually *useful*.
> 
> [Big meals need time to digest: Just give me more time to do so (getting into 
> git). As with vi and Emacs (usualy I prefer Emacs), there will be situations when 
> I won't use Git however]
> 

Take all the time you need. It's a paradigm-shift, because the information you
thought you needed is made obsolete by the information you *actually* need.
Wrapping ones head around the fact that one's been wrong for several years takes
a little time ;-)

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

Re: On git 1.6 (novice's opinion)

[Ulrich Windl]

On 1 Apr 2009 at 9:54, Matthieu Moy wrote:

> "Ulrich Windl" <ulrich.windl@rz.uni-regensburg.de> writes:
> 
> >> Not to mention that you can have multiple roots (multiple commits with
> >> no parent) in git repository; besides independent branches (like
> >> 'man', 'html' or 'todo') it is usually result of absorbing or
> >> subtree-merging other projects.  In 'master' branch there are 5 roots
> >> or more: joined 'git-tools' (mailinfo / mailsplit), absorbed gitweb,
> >> and subtree-merged gitk and git-gui.  And here you would again have
> >> multiple commits with the same number...
> >
> > Which would not harm, because it would be version N from committer X. Any if 
> > committer X merges from anything else, the next number would be > N. I did not 
> > claim that my method makes a total ordering of commits and merges possible.
> 
> Neither does it make the numbers unique for committer X.
> 
> If commiter X commits a successor to commit N, it's labeled N+1. If
> later, he creates another branch from commit N, and commit, the new,
> other commit will be labeled N+1.

Correct: They live in a parallel universe. But on the long term they will either 
vanish or be merged in which case the number will be "> N+1" (on the main branch). 
So we have a branch plus a sequence number all the time.

> 
> This means even within a repository, you cannot say things like
> "commit number N", so, OK, you have numerical IDs, but you can't use
> them.

I never wanted to have such a thing (using those numbers for commit).

> 
> What can be interesting is that a commit takes 
> max{all commits in repository}+1, not just max{parents} + 1. Then, you
> have local revision numbers, but they're not stable. Indeed, that's
> precisely what Mercurial does.

That would be a (temporary) total ordering, which I did not want, exactly for that 
reason.

[I did not intend the following use case]

Ulrich

> 
> But I'm not sure how much simplicity it adds compared to the confusion
> it adds. Newbies will see Mercurial identifiers as
> 
> changeset:   2:699b81a5851b
> changeset:   1:fd4b6597548f
> changeset:   0:58cff172192e
> 
> And think "OK, the revision numbers are 0, 1, 2, and the hexadecimal
> stuff beside is useless". And one day, he'll send a mail, post a
> bugreport, or whatever, saying "I have a problem with revision number
> 42", and no one else but him will know which revision is called "42".
> 
> > I truly believe in unique IDs, but they are just not handy in every situation.
> 
> Usually, people find Git IDs to be non-handy until the find out they
> can cut-and-paste only the first few digits in most cases, like
> 442dd42 instead of 442dd42d6d4903640b0dc5561481a77c88dcea90 ;-).
> 
> -- 
> Matthieu

Re: On git 1.6 (novice's opinion)

[Ulrich Windl]

On 1 Apr 2009 at 10:37, Andreas Ericsson wrote:

> >> Not only that, but modification times are much more useful with make.
> >> Merging or pulling small changes into a tree shouldn't require a full
> >> rebuild of the entire tree which in some cases could take hours.
> > 
> > Git is not a build system, and I really dislike "full rebuilds", but for 
> > stability, before releasing anything, one should test it with a full rebuild.
> 
> I build all the time. Before and after every commit (merges are one type of
> commit). I rely on file timestamps to be an accurate indicator of when the
> file last changed *on my disk*.
> 

But you are silently assuming that the make files are correct: If a file is not 
being rebuilt, you might be using an old compile without noticing. There a full 
recompile will at least 1) either trigger an error (missing object file) or 2) 
build every file. So I really don't see that relying on file dates is much better 
than doing a full rebuild. That's specifically true if you pull a new tree: If I 
understand things right, EVERY file will have a current date, so you'll rebuild 
everything anyway. So you could also have the "real file dates" and then do "make 
clean; make all". I see no benefit from either approach.

Regards,
Ulrich

Re: On git 1.6 (novice's opinion)

[Ulrich Windl]

On 1 Apr 2009 at 10:41, Andreas Ericsson wrote:

> Ulrich Windl wrote:
> > On 30 Mar 2009 at 11:06, Andreas Ericsson wrote:
> > 
> > [...]
> >> 3 It's far better to set the version number in the release-process. Usually
> >>   this can be done automatically by one invocation of "git describe", just
> >>   as git.git does it.
> > 
> > However if you put a version number into every file and THEN commit, it's somewhat 
> > ridiculous (I'll have to learn about "git describe"). But for configuration 
> > management you want to have exactly that (find exactly the file that was shipped 
> > (or used to build)).
> > 
> >> We've adopted "3" full out at $dayjob. Our build-machinery gets the version
> >> number from the git tag (releases can only be built from signed tags), and
> >> it updates macros and whatnot used for informing the user which version he
> >> or she is running. This makes a lot more sense both from a bug-reporting
> >> and from a release process view than having generated version-numbers in
> > 
> > So your "release commits" are outside GIT? (see above)
> > 
> 
> They aren't release commits. Just a script that creates a tarball and an RPM
> (in our case).

OK, that's what I did with CVS also, but with "CVS diff" I see the revision 
numbers (old and new) for every single file in a patch, while Git just uses "a" 
and "b". There I'd still prefer what CVS does.

> 
> >> files. On a side-note; When I told my co-workers I'd like us to switch to
> >> git, two of them asked about autoversioning features. I said there weren't
> >> any and asked them to name a single time when we've actually used them for
> >> anything *at all*. In a team of eight, having been programming for three
> >> years with 12 releases and about 800 bugreports + feature-requests, noone
> >> could mention a single time when the autogenerated version numbers had
> >> actually been used for anything.
> > 
> > Hmm: Were they visible to customers?
> > 
> 
> Ofcourse they were, but they were rather useless even there, as a customer
> could upgrade and the $Id$ tag still wouldn't get updated. It caused a lot
> of confusion for our not-so-techsavvy users and customers.

What I don't understand here is: Why wouldn't the $Id$ be updated upon upgrade? 
Because it's a manual process?

[...]

Regards,
Ulrich

Re: On git 1.6 (novice's opinion)

[Andreas Ericsson]

Ulrich Windl wrote:
> On 1 Apr 2009 at 9:54, Matthieu Moy wrote:
> 
>> "Ulrich Windl" <ulrich.windl@rz.uni-regensburg.de> writes:
>>
>>>> Not to mention that you can have multiple roots (multiple commits with
>>>> no parent) in git repository; besides independent branches (like
>>>> 'man', 'html' or 'todo') it is usually result of absorbing or
>>>> subtree-merging other projects.  In 'master' branch there are 5 roots
>>>> or more: joined 'git-tools' (mailinfo / mailsplit), absorbed gitweb,
>>>> and subtree-merged gitk and git-gui.  And here you would again have
>>>> multiple commits with the same number...
>>> Which would not harm, because it would be version N from committer X. Any if 
>>> committer X merges from anything else, the next number would be > N. I did not 
>>> claim that my method makes a total ordering of commits and merges possible.
>> Neither does it make the numbers unique for committer X.
>>
>> If commiter X commits a successor to commit N, it's labeled N+1. If
>> later, he creates another branch from commit N, and commit, the new,
>> other commit will be labeled N+1.
> 
> Correct: They live in a parallel universe. But on the long term they will either 
> vanish or be merged in which case the number will be "> N+1" (on the main branch). 
> So we have a branch plus a sequence number all the time.
> 
>> This means even within a repository, you cannot say things like
>> "commit number N", so, OK, you have numerical IDs, but you can't use
>> them.
> 
> I never wanted to have such a thing (using those numbers for commit).
> 

If you weren't going to use them for commits, what use are they at all?

I think you need to show us at least one use-case where this would
be beneficial *at all* before anyone is going to take this suggestion
seriously (this time around; It's been dropped on the floor numerous
times before when those original posters came to their senses).

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

Re: On git 1.6 (novice's opinion)

[Andreas Ericsson]

Ulrich Windl wrote:
> On 1 Apr 2009 at 10:37, Andreas Ericsson wrote:
> 
>>>> Not only that, but modification times are much more useful with make.
>>>> Merging or pulling small changes into a tree shouldn't require a full
>>>> rebuild of the entire tree which in some cases could take hours.
>>> Git is not a build system, and I really dislike "full rebuilds", but for 
>>> stability, before releasing anything, one should test it with a full rebuild.
>> I build all the time. Before and after every commit (merges are one type of
>> commit). I rely on file timestamps to be an accurate indicator of when the
>> file last changed *on my disk*.
>>
> 
> But you are silently assuming that the make files are correct: If a file is not 
> being rebuilt, you might be using an old compile without noticing. There a full 
> recompile will at least 1) either trigger an error (missing object file) or 2) 
> build every file. So I really don't see that relying on file dates is much better 
> than doing a full rebuild. That's specifically true if you pull a new tree: If I 
> understand things right, EVERY file will have a current date, so you'll rebuild 
> everything anyway. So you could also have the "real file dates" and then do "make 
> clean; make all". I see no benefit from either approach.
> 

You'll see the benefit of not rebuilding everything when your projects start
spanning more than 30k lines. Buildtesting a subsystem of the linux kernel
would be a major pain if object files weren't kept around from previous builds,
and integration-testing the hundreds (sometimes) of feature-branches would be
completely impossible if timestamps on files weren't updated when files change
on disk.

Incidentally, we do full rebuilds too, but no developer sits around watching
them. They're handled by our (stupid but efficient) homegrown CI-solution,
which emails the results to the devs. This happens every push though, not
every commit, but in our rather tight environment at $dayjob we push
frequently enough for that not to be a problem.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

Re: On git 1.6 (novice's opinion)

[Andreas Ericsson]

Ulrich Windl wrote:
> On 1 Apr 2009 at 10:41, Andreas Ericsson wrote:
> 
>> Ulrich Windl wrote:
>>> On 30 Mar 2009 at 11:06, Andreas Ericsson wrote:
>>>
>>> [...]
>>>> 3 It's far better to set the version number in the release-process. Usually
>>>>   this can be done automatically by one invocation of "git describe", just
>>>>   as git.git does it.
>>> However if you put a version number into every file and THEN commit, it's somewhat 
>>> ridiculous (I'll have to learn about "git describe"). But for configuration 
>>> management you want to have exactly that (find exactly the file that was shipped 
>>> (or used to build)).
>>>
>>>> We've adopted "3" full out at $dayjob. Our build-machinery gets the version
>>>> number from the git tag (releases can only be built from signed tags), and
>>>> it updates macros and whatnot used for informing the user which version he
>>>> or she is running. This makes a lot more sense both from a bug-reporting
>>>> and from a release process view than having generated version-numbers in
>>> So your "release commits" are outside GIT? (see above)
>>>
>> They aren't release commits. Just a script that creates a tarball and an RPM
>> (in our case).
> 
> OK, that's what I did with CVS also, but with "CVS diff" I see the revision 
> numbers (old and new) for every single file in a patch, while Git just uses "a" 
> and "b". There I'd still prefer what CVS does.
> 
>>>> files. On a side-note; When I told my co-workers I'd like us to switch to
>>>> git, two of them asked about autoversioning features. I said there weren't
>>>> any and asked them to name a single time when we've actually used them for
>>>> anything *at all*. In a team of eight, having been programming for three
>>>> years with 12 releases and about 800 bugreports + feature-requests, noone
>>>> could mention a single time when the autogenerated version numbers had
>>>> actually been used for anything.
>>> Hmm: Were they visible to customers?
>>>
>> Ofcourse they were, but they were rather useless even there, as a customer
>> could upgrade and the $Id$ tag still wouldn't get updated. It caused a lot
>> of confusion for our not-so-techsavvy users and customers.
> 
> What I don't understand here is: Why wouldn't the $Id$ be updated upon upgrade? 
> Because it's a manual process?
> 

It MAY not get updated, since $Id$ tags are per-file instead of per-project.
Any sane project will have more than one file, and the file listing the
$Id$ that the end-user sees may not have changed since the last release.

Per-file revision tags are stupid and useless for anything but a one-file
project.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

Re: On git 1.6 (novice's opinion)

[Ulrich Windl]

On 1 Apr 2009 at 12:21, Andreas Ericsson wrote:

[...]
> > What I don't understand here is: Why wouldn't the $Id$ be updated upon upgrade? 
> > Because it's a manual process?
> > 
> 
> It MAY not get updated, since $Id$ tags are per-file instead of per-project.
> Any sane project will have more than one file, and the file listing the
> $Id$ that the end-user sees may not have changed since the last release.
> 
> Per-file revision tags are stupid and useless for anything but a one-file
> project.

Hmm...:
# what vmunix
vmunix:
         ivt.s $Date: 2008/11/21 09:10:19 $Revision: r11.31/5 PATCH_11.31 (B11.3
1.0903LR)
         side_dumpdev - HP IDE Dump Driver B.11.31 /ux/core/kern/em/svc/dump/scs
i_ide_dumpdev.c: Jan  8 2009, 23:48:25
         eschgr - Changer Driver B.11.31.01 /ux/core/kern/common/io/escsi/eschgr
/eschgr.c:Jan 10 2007,17:04:47
         eschgr - Changer Driver B.11.31.01 /ux/core/kern/common/io/escsi/eschgr
/eschgr_diag.c:Dec 27 2006,16:59:17
[...]
        vxfs:$RCSfile: vx_portal.c,v $  $Revision: 4.14.26.3 $
        vxfs:$RCSfile: vx_portal_osrel.c,v $    $Revision: 1.1.2.1 $
        vxfs:$RCSfile: vx_portal_dlkm.c,v $     $Revision: 1.1.2.1 $
        vxfs:$RCSfile: vxportal50.modmeta,v $   $Revision: 1.1.2.5 $
         wsio_cdio.c $Date: 2008/06/03 05:52:50 $Revision: r11.31/13 PATCH_11.31
 (B11.31.0809LR)
         $Revision: wsio:    B11.31.0809LR
         $Revision: wxb_hp:    B.11.31_LR
         tracer.s $Date: 2008/04/28 17:14:06 $Revision: r11.31/3 PATCH_11.31 (B1
1.31.0809LR)

For a kernel, where development is decentralized, it would make sense: Imageine a 
user (or distributor) will nut upgrade anything to the latest version, but only 
parts (subsystems). Then the single kernel version number is meaningless.

Regards,
Ulrich

Re: On git 1.6 (novice's opinion)

[Andreas Ericsson]

Ulrich Windl wrote:
> On 1 Apr 2009 at 12:21, Andreas Ericsson wrote:
> 
> [...]
>>> What I don't understand here is: Why wouldn't the $Id$ be updated upon upgrade? 
>>> Because it's a manual process?
>>>
>> It MAY not get updated, since $Id$ tags are per-file instead of per-project.
>> Any sane project will have more than one file, and the file listing the
>> $Id$ that the end-user sees may not have changed since the last release.
>>
>> Per-file revision tags are stupid and useless for anything but a one-file
>> project.
> 
> Hmm...:
> # what vmunix
> vmunix:
>          ivt.s $Date: 2008/11/21 09:10:19 $Revision: r11.31/5 PATCH_11.31 (B11.3
> 1.0903LR)
>          side_dumpdev - HP IDE Dump Driver B.11.31 /ux/core/kern/em/svc/dump/scs
> i_ide_dumpdev.c: Jan  8 2009, 23:48:25
>          eschgr - Changer Driver B.11.31.01 /ux/core/kern/common/io/escsi/eschgr
> /eschgr.c:Jan 10 2007,17:04:47
>          eschgr - Changer Driver B.11.31.01 /ux/core/kern/common/io/escsi/eschgr
> /eschgr_diag.c:Dec 27 2006,16:59:17
> [...]
>         vxfs:$RCSfile: vx_portal.c,v $  $Revision: 4.14.26.3 $
>         vxfs:$RCSfile: vx_portal_osrel.c,v $    $Revision: 1.1.2.1 $
>         vxfs:$RCSfile: vx_portal_dlkm.c,v $     $Revision: 1.1.2.1 $
>         vxfs:$RCSfile: vxportal50.modmeta,v $   $Revision: 1.1.2.5 $
>          wsio_cdio.c $Date: 2008/06/03 05:52:50 $Revision: r11.31/13 PATCH_11.31
>  (B11.31.0809LR)
>          $Revision: wsio:    B11.31.0809LR
>          $Revision: wxb_hp:    B.11.31_LR
>          tracer.s $Date: 2008/04/28 17:14:06 $Revision: r11.31/3 PATCH_11.31 (B1
> 1.31.0809LR)
> 
> For a kernel, where development is decentralized, it would make sense: Imageine a 
> user (or distributor) will nut upgrade anything to the latest version, but only 
> parts (subsystems). Then the single kernel version number is meaningless.
> 

Not really. They can (and should) create their own version numbers. I can't make
sense of the above output. If you ask a developer to piece together the puzzle
that makes up this subsystem and then fit it into the bigger picture, he won't
love you for it. Not only because this particular subsystem might well be the
same version across several different releases with all their different API's
(the input system has changed its API's incompatibly quite frequently over the
last six months, fe, so a driver-version *alone* in that system makes absolutely
no sense if you're trying to debug it).

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

Re: On git 1.6 (novice's opinion)

[Heiko Voigt]

On Wed, Apr 01, 2009 at 11:47:31AM +0200, Ulrich Windl wrote:
> So I really don't see that relying on file dates is much better than
> doing a full rebuild. That's specifically true if you pull a new tree:
> If I understand things right, EVERY file will have a current date, so
> you'll rebuild everything anyway. So you could also have the "real
> file dates" and then do "make clean; make all". I see no benefit from
> either approach.

I am not sure if you understand it right. When switching branches git
will only touch the files that have changed between your old and your
new tree. make will then only build those files that are actually
different between those two trees because they have been given a newer
date than their target files. All other files in your working copy will
not be touched.

cheers Heiko

Re: On git 1.6 (novice's opinion)

[Jakub Narebski]

On Wed, 1 April 2009, Ulrich Windl wrote:
> On 27 Mar 2009 at 7:09, Jakub Narebski wrote:
>> "Ulrich Windl" <ulrich.windl@rz.uni-regensburg.de> writes:
>>> On 27 Mar 2009 at 13:49, Michael J Gruber wrote: 
>>>> Ulrich Windl venit, vidit, dixit 27.03.2009 08:21:
>>> 
>>> [...]
>>> 
>>>> Keyword substitution and cvs/svn style version numbers are independent
>>>> issues. The sha1 describes a commit uniquely, one could use that as a
>>>> keyword.
>>> 
>>> However version numbers and time stamps have the property of being at least 
>>> partially ordered in respect of "newer/older". That property does not hold for 
>>> SHA-1 checksums. Just imagine suggesting users to upgrade from Microsoft 
>>> Word/004765c2a1e9771e886f0dbe87d4f89643cd6f70 to Microsoft 
>>> Word/00b7e6f51130f234a969c84ee9231a5ff7fc8a82 ;-)
>> 
>> That is why people use output of git-describe and _tag_ their releases,
>> and make embedding version number in released version (tarball / binary)
>> the job of make: see GIT-VERSION-GEN script in git sources, and how it
>> is used in Makefile.
> 
> OK, but imaginge someone sends you some file that originated from some git 
> version, maybe with minor modifications. Is there a way to find out from what git 
> version that file was derived? IMHO that's where "automatically replaced 
> placeholders" (like $id$) make sense.

Is it theoretical exercise or some real problem?


First, if the file with modification was taken from _release_ (from
tarball of sources), they can have placeholders like @@VERSION@@ replaced
by actual version (taken from git-describe / GIT-VERSION-GEN) by make
during "make dist" step, or its equivalent. Usually it would be e.g.
v1.6.2.1, as you make distribution of tagged release.

Second, if the files was taken from _repository_ (from version control),
you can get modification send as git diff of changes (which includes
shortened sha-1 of original file contents, and tools such as git-am --3way
can make use of this information to apply patch), or at least in unified
patch format.


Last, you can use `ident` attribute to make git replace the only
"automatic replaced placeholder" (keyword) that makes sense for
distributed VCS, namely $Id$ keyword which get replaced by 
$Id: <40-character hexadecimal blob object name>$; you can based
on this iformation find commit or commits that introduced this exact
version of a file.

See gitattributes(5).

>>>> Increasing version numbers are meaningless in a true DVCS world. What is
>>>> your 100th commit may not be someone else's, even if both your master's
>>>> heads are the same! This is why hg version numbers are a local thing.
>>>> They are merely a local shortcut for specifying a revision and serve the
>>>> same purpose as git's "backward" counts like HEAD~3 etc. Neither of them
>>>> work permanently, not even in a local repo, if you allow rebasing.
>>> 
>>> Maybe I didn't fully understand, but having a version number that is larger than 
>>> any parent's version numbers when doing a merge/commit doesn't look wrong to me.
>> 
>> I'm sorry to dissapoint you, but without central server assigning
>> numbers to commits it wouldn't simply work in distributed version
>> control world.  Take for example the following situation: somebody
>> clones your repository, and creates new commit on 'master' (trunk) and
>> it gets version number N.  Meanwhile you also independently create new
>> commit on 'master'... and without central authority it would also get
>> version number N.  Then you would merge (pull) his/her changes, and
>> you would have two commits with the same number; not something you want.
> 
> Anyway the result would have number "N+1". Maybe you misunderstood: I'm not 
> proposing to replace git's internal version numbering (SHA-1), but so introduce 
> some more comprehensible, primitive user-level numbering.

Errr... what? You would want to renumber _all_ (possibly large amount
of) fetched commits from other repository? It is very costly, and you
are left with commit numbers which are local to repository...

Or perhaps you would want to number only commits in first line parentage
of a branch, i.e. created in repository or fast-forwarded? This is what
Mercurial and (from what I understand) Bazaar does, and it also results
in commit numbers which are local to repository.

Or you were talking about having merge ("result") to have number "N+1".
But then you would have _two_ commits with number "N", and "N" would not
identify commit uniquely, even local for repository. Which means that
it would be useless.


Numbers local to repository cannot be used to pass in communication
to others (e.g. bug was caused by commit 5436); additionally I don't
see how revision number 7654 is any easier to use than HEAD~3, or
f348eae (copy'n'pasted).
 
>> Not to mention that you can have multiple roots (multiple commits with
>> no parent) in git repository; besides independent branches (like
>> 'man', 'html' or 'todo') it is usually result of absorbing or
>> subtree-merging other projects.  In 'master' branch there are 5 roots
>> or more: joined 'git-tools' (mailinfo / mailsplit), absorbed gitweb,
>> and subtree-merged gitk and git-gui.  And here you would again have
>> multiple commits with the same number...
> 
> Which would not harm, because it would be version N from committer X. Any if 
> committer X merges from anything else, the next number would be> N. I did not 
> claim that my method makes a total ordering of commits and merges possible.
> 
> I truly believe in unique IDs, but they are just not handy in every situation.

You have <branch>~<n>, <branch>@<n>, shortened sha-1, result of git-describe
that can be used in place of full sha-1...

-- 
Jakub Narebski
Poland