* Re: Cleaning up git user-interface warts
From: Junio C Hamano @ 2006-11-15 5:35 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git, Andy Whitcroft, Carl Worth
In-Reply-To: <Pine.LNX.4.64.0611142048350.2591@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> What is the point of hiding tracking branches? Why just not making them
> easier to use instead? There are currently so many ways to specify
> remote branches that even I get confused.
Ok, I think in essence we are saying the same thing except I
went overboard by suggsting to extend sha1_name to also look at
.git/remotes/$name which is not necessary, because we already
have the .git/refs/remotes/%s/HEAD magic there. Consider the
suggestion of "upstream#next" syntax retracted, please.
> 1) make "git init" an alias for "git init-db".
Or even better, have "gh init".
> 2) "pull" and "push" should be symmetrical operations
I think that makes a lot of sense to have "gh pull" and "gh
push" as symmetric operations, and make "gh merge" do the
fast-forward and 3-way merge magic done in the current "git
pull". These three words would have a lot saner meaning.
> 3) remote branch handling should become more straight forward.
>
> OK! Now that we've solved the pull issue and that everybody agrees with
> me (how can't you all agree with me anyway) let's have a look at remote
> branches.
I would probably prefer making the default namespace under
.git/refs/remotes/remote-name for the tracking branches this
proposal creates, but other than that I agree with the general
direction this proposal is taking us, including branch groups.
We have .git/refs/remotes/%s/HEAD magic so I do not think we
even need to treat one branch repository any specially as you
suggsted.
The reason I am suggsting "gh" instead of "git" is primarily to
deal with stale documentation people would find googling. I can
easily see people get confused by reading "pull = fetch + merge"
from either mailing list archive or Git cheat sheet various
projects seem to have developed.
It does not mean we need to redo _all_ UI. I think most of the
archaeology commands have sane UI so during the transition
period (git 1.99) we can have "git log" and "gh log" which are
one and the same program, and perhaps git 2.0 can be shipped
with clear distinction between plumbing (i.e. git-update-index
and friends) and porcelain (e.g. "gh pull" that only fetches but
with the user friendliness you outlined here), with backward
compatibility wart to help old timers (e.g. "git pull" that
still does "git fetch" followed by "git merge").
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Junio C Hamano @ 2006-11-15 4:58 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0611142306090.2591@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> ... We simply won't gain anything trying to teach people "a pull
> in HG is a download in GIT". If a pull becomes the same thing for both
> then it's one less oddball in the GIT interface.
I personally do not have any issue with that, as long as you
would help us convert existing users that what was known as pull
is not available and new pull means fetching only.
If I recall correctly in this thread, you also advocated to
always have tracking branches. I am a bit worried about losing
the promiscuous pull usage, which can easily become a regression
for people like Linus in the integrator role unless done with an
escape hatch.
^ permalink raw reply
* Re: [GIT PATCH] Makefile missing git-runstatus in PROGRAMS list
From: Junio C Hamano @ 2006-11-15 4:51 UTC (permalink / raw)
To: Bhavesh Davda; +Cc: git
In-Reply-To: <FE74AC4E0A23124DA52B99F17F44159701A11D6A@PA-EXCH03.vmware.com>
[-- Attachment #1: Type: text/plain, Size: 1357 bytes --]
"Bhavesh Davda" <bhavesh@vmware.com> writes:
> So I just blew away /usr/bin/git*, and removed my Makefile patch, and did
> another:
>
> make prefix=/usr all (as myself)
>
> and then
>
> sudo make prefix=/usr install
>
> I now *don't* have /usr/bin/git-runstatus.
>
> And none of the files under /usr/bin/git* are hard links. There are in all 79
> files beginning with /usr/bin/git*:
>
> git git-am git-applymbox git-applypatch git-archimport git-bisect
> git-checkout git-cherry-pick git-clean git-clone git-commit
>...
> git-var git-verify-pack git-verify-tag gitk
>
> I haven't tried make -p yet, but can do that to see why git-runstatus isn't
> installed under /usr/bin
Interesting. You do not seem to have not just git-runstatus but
anything built-in. The last action in "make install" should
look like this log entry (I just did "make prefix=/var/tmp/ggg
clean all install"):
rm -f '/var/tmp/ggg/bin/git-format-patch' && ln '/var/tmp/ggg/bin/git' '/var/tmp/ggg/bin/git-format-patch' ; rm -f '/var/tmp/ggg/bin/git-show' && ln '/var/tmp/ggg/bin/git' '/var/tmp/ggg/bin/git-show' ; ... rm -f '/var/tmp/ggg/bin/git-verify-pack' && ln '/var/tmp/ggg/bin/git' '/var/tmp/ggg/bin/git-verify-pack' ; rm -f '/var/tmp/ggg/bin/git-write-tree' && ln '/var/tmp/ggg/bin/git' '/var/tmp/ggg/bin/git-write-tree' ;
that installs 47 hardlinks to $(prefix)/bin/git.
[-- Attachment #2: script from \"make prefix=/var/tmp/ggg clean all install\" --]
[-- Type: text/plain, Size: 51345 bytes --]
Script started on Tue 14 Nov 2006 08:42:08 PM PST
gitster; make prefix=/var/tmp/ggg clean all install
GIT_VERSION = 1.4.3.5.gfe14
rm -f *.o mozilla-sha1/*.o arm/*.o ppc/*.o compat/*.o xdiff/*.o \
libgit.a xdiff/lib.a
rm -f git-convert-objects git-fetch-pack git-fsck-objects git-hash-object git-index-pack git-local-fetch git-merge-base git-daemon git-merge-index git-mktag git-mktree git-patch-id git-peek-remote git-receive-pack git-send-pack git-shell git-show-index git-ssh-fetch git-ssh-upload git-unpack-file git-update-server-info git-upload-pack git-verify-pack git-pack-redundant git-var git-describe git-merge-tree git-blame git-imap-send git-merge-recursive git-ssh-pull git-ssh-push git-http-fetch git-http-push git-bisect git-branch git-checkout git-cherry git-clean git-clone git-commit git-fetch git-ls-remote git-merge-one-file git-parse-remote git-pull git-rebase git-repack git-request-pull git-reset git-resolve git-revert git-sh-setup git-tag git-verify-tag git-applymbox git-applypatch git-am git-merge git-merge-stupid git-merge-octopus git-merge-resolve git-merge-ours git-lost-found git-quiltimport git-archimport git-cvsimport git-relink git-shortlog git-rerere git-annotate git-cvsserver git-svnimport git-cvsexportcommit git-send-email git-svn git-merge-recursive-old git-cherry-pick git-status git-instaweb git-merge-recur git-format-patch git-show git-whatchanged git-get-tar-commit-id git-add git-apply git-archive git-cat-file git-checkout-index git-check-ref-format git-commit-tree git-count-objects git-diff git-diff-files git-diff-index git-diff-stages git-diff-tree git-fmt-merge-msg git-grep git-init-db git-log git-ls-files git-ls-tree git-mailinfo git-mailsplit git-mv git-name-rev git-pack-objects git-prune git-prune-packed git-push git-read-tree git-repo-config git-rev-list git-rev-parse git-rm git-runstatus git-show-branch git-stripspace git-symbolic-ref git-tar-tree git-unpack-objects git-update-index git-update-ref git-upload-archive git-verify-pack git-write-tree git
rm -f *.spec *.pyc *.pyo */*.pyc */*.pyo common-cmds.h TAGS tags
rm -rf autom4te.cache
rm -f configure config.log config.mak.autogen config.mak.append config.status config.cache
rm -rf git-1.4.3.5.gfe14 .doc-tmp-dir
rm -f git-1.4.3.5.gfe14.tar.gz git-core_1.4.3.5.gfe14-*.tar.gz
rm -f git-htmldocs-1.4.3.5.gfe14.tar.gz git-manpages-1.4.3.5.gfe14.tar.gz
rm -f gitweb/gitweb.cgi
make -C Documentation/ clean
make[1]: Entering directory `/git.git/Documentation'
rm -f doc.dep+ doc.dep
perl ./build-docdep.perl >doc.dep+
mv doc.dep+ doc.dep
make[1]: Leaving directory `/git.git/Documentation'
make[1]: Entering directory `/git.git/Documentation'
rm -f *.xml *.html *.1 *.7 howto-index.txt howto/*.html doc.dep README
make[1]: Leaving directory `/git.git/Documentation'
[ ! -f perl/Makefile ] || make -C perl/ clean || make -C perl/ clean
rm -f perl/ppport.h perl/Makefile.old
make -C templates/ clean
make[1]: Entering directory `/git.git/templates'
rm -rf blt boilerplates.made
make[1]: Leaving directory `/git.git/templates'
make -C t/ clean
make[1]: Entering directory `/git.git/t'
rm -fr trash
make[1]: Leaving directory `/git.git/t'
rm -f GIT-VERSION-FILE GIT-CFLAGS
* new build flags or prefix
(cd perl && /usr/bin/perl Makefile.PL \
PREFIX='/var/tmp/ggg')
Writing Makefile for Git
gcc -o convert-objects.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY convert-objects.c
gcc -o blob.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY blob.c
gcc -o commit.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY commit.c
gcc -o connect.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY connect.c
gcc -o csum-file.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY csum-file.c
gcc -o cache-tree.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY cache-tree.c
gcc -o base85.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY base85.c
gcc -o date.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY date.c
gcc -o diff-delta.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY diff-delta.c
gcc -o entry.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY entry.c
gcc -o exec_cmd.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY '-DGIT_EXEC_PATH="/var/tmp/ggg/bin"' exec_cmd.c
gcc -o ident.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY ident.c
gcc -o interpolate.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY interpolate.c
gcc -o lockfile.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY lockfile.c
gcc -o object.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY object.c
gcc -o pack-check.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY pack-check.c
gcc -o patch-delta.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY patch-delta.c
gcc -o path.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY path.c
gcc -o pkt-line.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY pkt-line.c
gcc -o sideband.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY sideband.c
gcc -o quote.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY quote.c
gcc -o read-cache.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY read-cache.c
gcc -o refs.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY refs.c
gcc -o run-command.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY run-command.c
gcc -o dir.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY dir.c
gcc -o object-refs.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY object-refs.c
gcc -o server-info.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY server-info.c
gcc -o setup.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY setup.c
gcc -o sha1_file.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY sha1_file.c
gcc -o sha1_name.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY sha1_name.c
gcc -o strbuf.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY strbuf.c
gcc -o tag.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY tag.c
gcc -o tree.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY tree.c
gcc -o usage.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY usage.c
gcc -o config.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY config.c
gcc -o environment.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY environment.c
gcc -o ctype.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY ctype.c
gcc -o copy.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY copy.c
gcc -o fetch-clone.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY fetch-clone.c
gcc -o revision.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY revision.c
gcc -o pager.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY pager.c
gcc -o tree-walk.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY tree-walk.c
gcc -o xdiff-interface.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY xdiff-interface.c
gcc -o write_or_die.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY write_or_die.c
gcc -o trace.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY trace.c
gcc -o list-objects.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY list-objects.c
gcc -o grep.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY grep.c
gcc -o alloc.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY alloc.c
gcc -o merge-file.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY merge-file.c
gcc -o path-list.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY path-list.c
./generate-cmdlist.sh > common-cmds.h+
mv common-cmds.h+ common-cmds.h
gcc -o help.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY help.c
gcc -o unpack-trees.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY unpack-trees.c
gcc -o diff.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY diff.c
gcc -o diff-lib.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY diff-lib.c
gcc -o diffcore-break.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY diffcore-break.c
gcc -o diffcore-order.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY diffcore-order.c
gcc -o diffcore-pickaxe.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY diffcore-pickaxe.c
gcc -o diffcore-rename.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY diffcore-rename.c
gcc -o tree-diff.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY tree-diff.c
gcc -o combine-diff.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY combine-diff.c
gcc -o diffcore-delta.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY diffcore-delta.c
gcc -o log-tree.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY log-tree.c
gcc -o color.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY color.c
gcc -o wt-status.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY wt-status.c
gcc -o archive-zip.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY archive-zip.c
gcc -o archive-tar.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY archive-tar.c
gcc -o compat/strlcpy.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY compat/strlcpy.c
rm -f libgit.a && ar rcs libgit.a blob.o commit.o connect.o csum-file.o cache-tree.o base85.o date.o diff-delta.o entry.o exec_cmd.o ident.o interpolate.o lockfile.o object.o pack-check.o patch-delta.o path.o pkt-line.o sideband.o quote.o read-cache.o refs.o run-command.o dir.o object-refs.o server-info.o setup.o sha1_file.o sha1_name.o strbuf.o tag.o tree.o usage.o config.o environment.o ctype.o copy.o fetch-clone.o revision.o pager.o tree-walk.o xdiff-interface.o write_or_die.o trace.o list-objects.o grep.o alloc.o merge-file.o path-list.o help.o unpack-trees.o diff.o diff-lib.o diffcore-break.o diffcore-order.o diffcore-pickaxe.o diffcore-rename.o tree-diff.o combine-diff.o diffcore-delta.o log-tree.o color.o wt-status.o archive-zip.o archive-tar.o compat/strlcpy.o
gcc -o xdiff/xdiffi.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY xdiff/xdiffi.c
gcc -o xdiff/xprepare.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY xdiff/xprepare.c
gcc -o xdiff/xutils.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY xdiff/xutils.c
gcc -o xdiff/xemit.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY xdiff/xemit.c
rm -f xdiff/lib.a && ar rcs xdiff/lib.a xdiff/xdiffi.o xdiff/xprepare.o xdiff/xutils.o xdiff/xemit.o
gcc -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o git-convert-objects convert-objects.o libgit.a xdiff/lib.a -lz -lcrypto
gcc -o fetch-pack.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY fetch-pack.c
gcc -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o git-fetch-pack fetch-pack.o libgit.a xdiff/lib.a -lz -lcrypto
gcc -o fsck-objects.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY fsck-objects.c
gcc -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o git-fsck-objects fsck-objects.o libgit.a xdiff/lib.a -lz -lcrypto
gcc -o hash-object.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY hash-object.c
gcc -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o git-hash-object hash-object.o libgit.a xdiff/lib.a -lz -lcrypto
gcc -o index-pack.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY index-pack.c
gcc -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o git-index-pack index-pack.o libgit.a xdiff/lib.a -lz -lcrypto
gcc -o local-fetch.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY local-fetch.c
gcc -o fetch.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY fetch.c
gcc -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o git-local-fetch local-fetch.o fetch.o libgit.a xdiff/lib.a -lz -lcrypto
gcc -o merge-base.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY merge-base.c
gcc -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o git-merge-base merge-base.o libgit.a xdiff/lib.a -lz -lcrypto
gcc -o daemon.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY daemon.c
gcc -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o git-daemon daemon.o libgit.a xdiff/lib.a -lz -lcrypto
gcc -o merge-index.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY merge-index.c
gcc -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o git-merge-index merge-index.o libgit.a xdiff/lib.a -lz -lcrypto
gcc -o mktag.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY mktag.c
gcc -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o git-mktag mktag.o libgit.a xdiff/lib.a -lz -lcrypto
gcc -o mktree.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY mktree.c
gcc -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o git-mktree mktree.o libgit.a xdiff/lib.a -lz -lcrypto
gcc -o patch-id.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY patch-id.c
gcc -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o git-patch-id patch-id.o libgit.a xdiff/lib.a -lz -lcrypto
gcc -o peek-remote.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY peek-remote.c
gcc -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o git-peek-remote peek-remote.o libgit.a xdiff/lib.a -lz -lcrypto
gcc -o receive-pack.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY receive-pack.c
gcc -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o git-receive-pack receive-pack.o libgit.a xdiff/lib.a -lz -lcrypto
gcc -o send-pack.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY send-pack.c
gcc -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o git-send-pack send-pack.o libgit.a xdiff/lib.a -lz -lcrypto
gcc -o shell.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY shell.c
gcc -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o git-shell shell.o libgit.a xdiff/lib.a -lz -lcrypto
gcc -o show-index.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY show-index.c
gcc -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o git-show-index show-index.o libgit.a xdiff/lib.a -lz -lcrypto
gcc -o ssh-fetch.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY ssh-fetch.c
gcc -o rsh.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY rsh.c
gcc -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o git-ssh-fetch ssh-fetch.o rsh.o fetch.o libgit.a xdiff/lib.a -lz -lcrypto
gcc -o ssh-upload.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY ssh-upload.c
gcc -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o git-ssh-upload ssh-upload.o rsh.o libgit.a xdiff/lib.a -lz -lcrypto
gcc -o unpack-file.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY unpack-file.c
gcc -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o git-unpack-file unpack-file.o libgit.a xdiff/lib.a -lz -lcrypto
gcc -o update-server-info.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY update-server-info.c
gcc -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o git-update-server-info update-server-info.o libgit.a xdiff/lib.a -lz -lcrypto
gcc -o upload-pack.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY upload-pack.c
gcc -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o git-upload-pack upload-pack.o libgit.a xdiff/lib.a -lz -lcrypto
gcc -o builtin-add.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-add.c
gcc -o builtin-apply.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-apply.c
gcc -o builtin-archive.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-archive.c
gcc -o builtin-cat-file.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-cat-file.c
gcc -o builtin-checkout-index.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-checkout-index.c
gcc -o builtin-check-ref-format.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-check-ref-format.c
gcc -o builtin-commit-tree.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-commit-tree.c
gcc -o builtin-count-objects.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-count-objects.c
gcc -o builtin-diff.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-diff.c
gcc -o builtin-diff-files.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-diff-files.c
gcc -o builtin-diff-index.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-diff-index.c
gcc -o builtin-diff-stages.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-diff-stages.c
gcc -o builtin-diff-tree.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-diff-tree.c
gcc -o builtin-fmt-merge-msg.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-fmt-merge-msg.c
gcc -o builtin-grep.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-grep.c
gcc -o builtin-init-db.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -DDEFAULT_GIT_TEMPLATE_DIR='"/var/tmp/ggg/share/git-core/templates/"' builtin-init-db.c
gcc -o builtin-log.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-log.c
gcc -o builtin-ls-files.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-ls-files.c
gcc -o builtin-ls-tree.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-ls-tree.c
gcc -o builtin-mailinfo.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-mailinfo.c
gcc -o builtin-mailsplit.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-mailsplit.c
gcc -o builtin-mv.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-mv.c
gcc -o builtin-name-rev.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-name-rev.c
gcc -o builtin-pack-objects.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-pack-objects.c
gcc -o builtin-prune.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-prune.c
gcc -o builtin-prune-packed.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-prune-packed.c
gcc -o builtin-push.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-push.c
gcc -o builtin-read-tree.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-read-tree.c
gcc -o builtin-repo-config.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-repo-config.c
gcc -o builtin-rev-list.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-rev-list.c
gcc -o builtin-rev-parse.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-rev-parse.c
gcc -o builtin-rm.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-rm.c
gcc -o builtin-runstatus.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-runstatus.c
gcc -o builtin-show-branch.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-show-branch.c
gcc -o builtin-stripspace.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-stripspace.c
gcc -o builtin-symbolic-ref.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-symbolic-ref.c
gcc -o builtin-tar-tree.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-tar-tree.c
gcc -o builtin-unpack-objects.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-unpack-objects.c
gcc -o builtin-update-index.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-update-index.c
gcc -o builtin-update-ref.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-update-ref.c
gcc -o builtin-upload-archive.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-upload-archive.c
gcc -o builtin-verify-pack.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-verify-pack.c
gcc -o builtin-write-tree.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-write-tree.c
gcc -DGIT_VERSION='"1.4.3.5.gfe14"' \
-g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o git git.c \
builtin-add.o builtin-apply.o builtin-archive.o builtin-cat-file.o builtin-checkout-index.o builtin-check-ref-format.o builtin-commit-tree.o builtin-count-objects.o builtin-diff.o builtin-diff-files.o builtin-diff-index.o builtin-diff-stages.o builtin-diff-tree.o builtin-fmt-merge-msg.o builtin-grep.o builtin-init-db.o builtin-log.o builtin-ls-files.o builtin-ls-tree.o builtin-mailinfo.o builtin-mailsplit.o builtin-mv.o builtin-name-rev.o builtin-pack-objects.o builtin-prune.o builtin-prune-packed.o builtin-push.o builtin-read-tree.o builtin-repo-config.o builtin-rev-list.o builtin-rev-parse.o builtin-rm.o builtin-runstatus.o builtin-show-branch.o builtin-stripspace.o builtin-symbolic-ref.o builtin-tar-tree.o builtin-unpack-objects.o builtin-update-index.o builtin-update-ref.o builtin-upload-archive.o builtin-verify-pack.o builtin-write-tree.o libgit.a xdiff/lib.a -lz -lcrypto
rm -f git-verify-pack && ln git git-verify-pack
gcc -o pack-redundant.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY pack-redundant.c
gcc -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o git-pack-redundant pack-redundant.o libgit.a xdiff/lib.a -lz -lcrypto
gcc -o var.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY var.c
gcc -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o git-var var.o libgit.a xdiff/lib.a -lz -lcrypto
gcc -o describe.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY describe.c
gcc -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o git-describe describe.o libgit.a xdiff/lib.a -lz -lcrypto
gcc -o merge-tree.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY merge-tree.c
gcc -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o git-merge-tree merge-tree.o libgit.a xdiff/lib.a -lz -lcrypto
gcc -o blame.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY blame.c
gcc -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o git-blame blame.o libgit.a xdiff/lib.a -lz -lcrypto
gcc -o imap-send.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY imap-send.c
gcc -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o git-imap-send imap-send.o libgit.a xdiff/lib.a -lz -lcrypto
gcc -o merge-recursive.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY merge-recursive.c
gcc -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o git-merge-recursive merge-recursive.o libgit.a xdiff/lib.a -lz -lcrypto
gcc -o ssh-pull.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY ssh-pull.c
gcc -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o git-ssh-pull ssh-pull.o rsh.o fetch.o libgit.a xdiff/lib.a -lz -lcrypto
gcc -o ssh-push.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY ssh-push.c
gcc -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o git-ssh-push ssh-push.o rsh.o libgit.a xdiff/lib.a -lz -lcrypto
gcc -o http.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -DGIT_USER_AGENT='"git/1.4.3.5.gfe14"' http.c
gcc -o http-fetch.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY http-fetch.c
gcc -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o git-http-fetch fetch.o http.o http-fetch.o \
libgit.a xdiff/lib.a -lz -lcrypto -lcurl -lexpat
gcc -o http-push.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY http-push.c
gcc -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o git-http-push revision.o http.o http-push.o \
libgit.a xdiff/lib.a -lz -lcrypto -lcurl -lexpat
rm -f git-bisect git-bisect+
sed -e '1s|#!.*/sh|#!/bin/sh|' \
-e 's|@@PERL@@|/usr/bin/perl|g' \
-e 's/@@GIT_VERSION@@/1.4.3.5.gfe14/g' \
-e 's/@@NO_CURL@@//g' \
-e 's/@@NO_PYTHON@@//g' \
git-bisect.sh >git-bisect+
chmod +x git-bisect+
mv git-bisect+ git-bisect
rm -f git-branch git-branch+
sed -e '1s|#!.*/sh|#!/bin/sh|' \
-e 's|@@PERL@@|/usr/bin/perl|g' \
-e 's/@@GIT_VERSION@@/1.4.3.5.gfe14/g' \
-e 's/@@NO_CURL@@//g' \
-e 's/@@NO_PYTHON@@//g' \
git-branch.sh >git-branch+
chmod +x git-branch+
mv git-branch+ git-branch
rm -f git-checkout git-checkout+
sed -e '1s|#!.*/sh|#!/bin/sh|' \
-e 's|@@PERL@@|/usr/bin/perl|g' \
-e 's/@@GIT_VERSION@@/1.4.3.5.gfe14/g' \
-e 's/@@NO_CURL@@//g' \
-e 's/@@NO_PYTHON@@//g' \
git-checkout.sh >git-checkout+
chmod +x git-checkout+
mv git-checkout+ git-checkout
rm -f git-cherry git-cherry+
sed -e '1s|#!.*/sh|#!/bin/sh|' \
-e 's|@@PERL@@|/usr/bin/perl|g' \
-e 's/@@GIT_VERSION@@/1.4.3.5.gfe14/g' \
-e 's/@@NO_CURL@@//g' \
-e 's/@@NO_PYTHON@@//g' \
git-cherry.sh >git-cherry+
chmod +x git-cherry+
mv git-cherry+ git-cherry
rm -f git-clean git-clean+
sed -e '1s|#!.*/sh|#!/bin/sh|' \
-e 's|@@PERL@@|/usr/bin/perl|g' \
-e 's/@@GIT_VERSION@@/1.4.3.5.gfe14/g' \
-e 's/@@NO_CURL@@//g' \
-e 's/@@NO_PYTHON@@//g' \
git-clean.sh >git-clean+
chmod +x git-clean+
mv git-clean+ git-clean
rm -f git-clone git-clone+
sed -e '1s|#!.*/sh|#!/bin/sh|' \
-e 's|@@PERL@@|/usr/bin/perl|g' \
-e 's/@@GIT_VERSION@@/1.4.3.5.gfe14/g' \
-e 's/@@NO_CURL@@//g' \
-e 's/@@NO_PYTHON@@//g' \
git-clone.sh >git-clone+
chmod +x git-clone+
mv git-clone+ git-clone
rm -f git-commit git-commit+
sed -e '1s|#!.*/sh|#!/bin/sh|' \
-e 's|@@PERL@@|/usr/bin/perl|g' \
-e 's/@@GIT_VERSION@@/1.4.3.5.gfe14/g' \
-e 's/@@NO_CURL@@//g' \
-e 's/@@NO_PYTHON@@//g' \
git-commit.sh >git-commit+
chmod +x git-commit+
mv git-commit+ git-commit
rm -f git-fetch git-fetch+
sed -e '1s|#!.*/sh|#!/bin/sh|' \
-e 's|@@PERL@@|/usr/bin/perl|g' \
-e 's/@@GIT_VERSION@@/1.4.3.5.gfe14/g' \
-e 's/@@NO_CURL@@//g' \
-e 's/@@NO_PYTHON@@//g' \
git-fetch.sh >git-fetch+
chmod +x git-fetch+
mv git-fetch+ git-fetch
rm -f git-ls-remote git-ls-remote+
sed -e '1s|#!.*/sh|#!/bin/sh|' \
-e 's|@@PERL@@|/usr/bin/perl|g' \
-e 's/@@GIT_VERSION@@/1.4.3.5.gfe14/g' \
-e 's/@@NO_CURL@@//g' \
-e 's/@@NO_PYTHON@@//g' \
git-ls-remote.sh >git-ls-remote+
chmod +x git-ls-remote+
mv git-ls-remote+ git-ls-remote
rm -f git-merge-one-file git-merge-one-file+
sed -e '1s|#!.*/sh|#!/bin/sh|' \
-e 's|@@PERL@@|/usr/bin/perl|g' \
-e 's/@@GIT_VERSION@@/1.4.3.5.gfe14/g' \
-e 's/@@NO_CURL@@//g' \
-e 's/@@NO_PYTHON@@//g' \
git-merge-one-file.sh >git-merge-one-file+
chmod +x git-merge-one-file+
mv git-merge-one-file+ git-merge-one-file
rm -f git-parse-remote git-parse-remote+
sed -e '1s|#!.*/sh|#!/bin/sh|' \
-e 's|@@PERL@@|/usr/bin/perl|g' \
-e 's/@@GIT_VERSION@@/1.4.3.5.gfe14/g' \
-e 's/@@NO_CURL@@//g' \
-e 's/@@NO_PYTHON@@//g' \
git-parse-remote.sh >git-parse-remote+
chmod +x git-parse-remote+
mv git-parse-remote+ git-parse-remote
rm -f git-pull git-pull+
sed -e '1s|#!.*/sh|#!/bin/sh|' \
-e 's|@@PERL@@|/usr/bin/perl|g' \
-e 's/@@GIT_VERSION@@/1.4.3.5.gfe14/g' \
-e 's/@@NO_CURL@@//g' \
-e 's/@@NO_PYTHON@@//g' \
git-pull.sh >git-pull+
chmod +x git-pull+
mv git-pull+ git-pull
rm -f git-rebase git-rebase+
sed -e '1s|#!.*/sh|#!/bin/sh|' \
-e 's|@@PERL@@|/usr/bin/perl|g' \
-e 's/@@GIT_VERSION@@/1.4.3.5.gfe14/g' \
-e 's/@@NO_CURL@@//g' \
-e 's/@@NO_PYTHON@@//g' \
git-rebase.sh >git-rebase+
chmod +x git-rebase+
mv git-rebase+ git-rebase
rm -f git-repack git-repack+
sed -e '1s|#!.*/sh|#!/bin/sh|' \
-e 's|@@PERL@@|/usr/bin/perl|g' \
-e 's/@@GIT_VERSION@@/1.4.3.5.gfe14/g' \
-e 's/@@NO_CURL@@//g' \
-e 's/@@NO_PYTHON@@//g' \
git-repack.sh >git-repack+
chmod +x git-repack+
mv git-repack+ git-repack
rm -f git-request-pull git-request-pull+
sed -e '1s|#!.*/sh|#!/bin/sh|' \
-e 's|@@PERL@@|/usr/bin/perl|g' \
-e 's/@@GIT_VERSION@@/1.4.3.5.gfe14/g' \
-e 's/@@NO_CURL@@//g' \
-e 's/@@NO_PYTHON@@//g' \
git-request-pull.sh >git-request-pull+
chmod +x git-request-pull+
mv git-request-pull+ git-request-pull
rm -f git-reset git-reset+
sed -e '1s|#!.*/sh|#!/bin/sh|' \
-e 's|@@PERL@@|/usr/bin/perl|g' \
-e 's/@@GIT_VERSION@@/1.4.3.5.gfe14/g' \
-e 's/@@NO_CURL@@//g' \
-e 's/@@NO_PYTHON@@//g' \
git-reset.sh >git-reset+
chmod +x git-reset+
mv git-reset+ git-reset
rm -f git-resolve git-resolve+
sed -e '1s|#!.*/sh|#!/bin/sh|' \
-e 's|@@PERL@@|/usr/bin/perl|g' \
-e 's/@@GIT_VERSION@@/1.4.3.5.gfe14/g' \
-e 's/@@NO_CURL@@//g' \
-e 's/@@NO_PYTHON@@//g' \
git-resolve.sh >git-resolve+
chmod +x git-resolve+
mv git-resolve+ git-resolve
rm -f git-revert git-revert+
sed -e '1s|#!.*/sh|#!/bin/sh|' \
-e 's|@@PERL@@|/usr/bin/perl|g' \
-e 's/@@GIT_VERSION@@/1.4.3.5.gfe14/g' \
-e 's/@@NO_CURL@@//g' \
-e 's/@@NO_PYTHON@@//g' \
git-revert.sh >git-revert+
chmod +x git-revert+
mv git-revert+ git-revert
rm -f git-sh-setup git-sh-setup+
sed -e '1s|#!.*/sh|#!/bin/sh|' \
-e 's|@@PERL@@|/usr/bin/perl|g' \
-e 's/@@GIT_VERSION@@/1.4.3.5.gfe14/g' \
-e 's/@@NO_CURL@@//g' \
-e 's/@@NO_PYTHON@@//g' \
git-sh-setup.sh >git-sh-setup+
chmod +x git-sh-setup+
mv git-sh-setup+ git-sh-setup
rm -f git-tag git-tag+
sed -e '1s|#!.*/sh|#!/bin/sh|' \
-e 's|@@PERL@@|/usr/bin/perl|g' \
-e 's/@@GIT_VERSION@@/1.4.3.5.gfe14/g' \
-e 's/@@NO_CURL@@//g' \
-e 's/@@NO_PYTHON@@//g' \
git-tag.sh >git-tag+
chmod +x git-tag+
mv git-tag+ git-tag
rm -f git-verify-tag git-verify-tag+
sed -e '1s|#!.*/sh|#!/bin/sh|' \
-e 's|@@PERL@@|/usr/bin/perl|g' \
-e 's/@@GIT_VERSION@@/1.4.3.5.gfe14/g' \
-e 's/@@NO_CURL@@//g' \
-e 's/@@NO_PYTHON@@//g' \
git-verify-tag.sh >git-verify-tag+
chmod +x git-verify-tag+
mv git-verify-tag+ git-verify-tag
rm -f git-applymbox git-applymbox+
sed -e '1s|#!.*/sh|#!/bin/sh|' \
-e 's|@@PERL@@|/usr/bin/perl|g' \
-e 's/@@GIT_VERSION@@/1.4.3.5.gfe14/g' \
-e 's/@@NO_CURL@@//g' \
-e 's/@@NO_PYTHON@@//g' \
git-applymbox.sh >git-applymbox+
chmod +x git-applymbox+
mv git-applymbox+ git-applymbox
rm -f git-applypatch git-applypatch+
sed -e '1s|#!.*/sh|#!/bin/sh|' \
-e 's|@@PERL@@|/usr/bin/perl|g' \
-e 's/@@GIT_VERSION@@/1.4.3.5.gfe14/g' \
-e 's/@@NO_CURL@@//g' \
-e 's/@@NO_PYTHON@@//g' \
git-applypatch.sh >git-applypatch+
chmod +x git-applypatch+
mv git-applypatch+ git-applypatch
rm -f git-am git-am+
sed -e '1s|#!.*/sh|#!/bin/sh|' \
-e 's|@@PERL@@|/usr/bin/perl|g' \
-e 's/@@GIT_VERSION@@/1.4.3.5.gfe14/g' \
-e 's/@@NO_CURL@@//g' \
-e 's/@@NO_PYTHON@@//g' \
git-am.sh >git-am+
chmod +x git-am+
mv git-am+ git-am
rm -f git-merge git-merge+
sed -e '1s|#!.*/sh|#!/bin/sh|' \
-e 's|@@PERL@@|/usr/bin/perl|g' \
-e 's/@@GIT_VERSION@@/1.4.3.5.gfe14/g' \
-e 's/@@NO_CURL@@//g' \
-e 's/@@NO_PYTHON@@//g' \
git-merge.sh >git-merge+
chmod +x git-merge+
mv git-merge+ git-merge
rm -f git-merge-stupid git-merge-stupid+
sed -e '1s|#!.*/sh|#!/bin/sh|' \
-e 's|@@PERL@@|/usr/bin/perl|g' \
-e 's/@@GIT_VERSION@@/1.4.3.5.gfe14/g' \
-e 's/@@NO_CURL@@//g' \
-e 's/@@NO_PYTHON@@//g' \
git-merge-stupid.sh >git-merge-stupid+
chmod +x git-merge-stupid+
mv git-merge-stupid+ git-merge-stupid
rm -f git-merge-octopus git-merge-octopus+
sed -e '1s|#!.*/sh|#!/bin/sh|' \
-e 's|@@PERL@@|/usr/bin/perl|g' \
-e 's/@@GIT_VERSION@@/1.4.3.5.gfe14/g' \
-e 's/@@NO_CURL@@//g' \
-e 's/@@NO_PYTHON@@//g' \
git-merge-octopus.sh >git-merge-octopus+
chmod +x git-merge-octopus+
mv git-merge-octopus+ git-merge-octopus
rm -f git-merge-resolve git-merge-resolve+
sed -e '1s|#!.*/sh|#!/bin/sh|' \
-e 's|@@PERL@@|/usr/bin/perl|g' \
-e 's/@@GIT_VERSION@@/1.4.3.5.gfe14/g' \
-e 's/@@NO_CURL@@//g' \
-e 's/@@NO_PYTHON@@//g' \
git-merge-resolve.sh >git-merge-resolve+
chmod +x git-merge-resolve+
mv git-merge-resolve+ git-merge-resolve
rm -f git-merge-ours git-merge-ours+
sed -e '1s|#!.*/sh|#!/bin/sh|' \
-e 's|@@PERL@@|/usr/bin/perl|g' \
-e 's/@@GIT_VERSION@@/1.4.3.5.gfe14/g' \
-e 's/@@NO_CURL@@//g' \
-e 's/@@NO_PYTHON@@//g' \
git-merge-ours.sh >git-merge-ours+
chmod +x git-merge-ours+
mv git-merge-ours+ git-merge-ours
rm -f git-lost-found git-lost-found+
sed -e '1s|#!.*/sh|#!/bin/sh|' \
-e 's|@@PERL@@|/usr/bin/perl|g' \
-e 's/@@GIT_VERSION@@/1.4.3.5.gfe14/g' \
-e 's/@@NO_CURL@@//g' \
-e 's/@@NO_PYTHON@@//g' \
git-lost-found.sh >git-lost-found+
chmod +x git-lost-found+
mv git-lost-found+ git-lost-found
rm -f git-quiltimport git-quiltimport+
sed -e '1s|#!.*/sh|#!/bin/sh|' \
-e 's|@@PERL@@|/usr/bin/perl|g' \
-e 's/@@GIT_VERSION@@/1.4.3.5.gfe14/g' \
-e 's/@@NO_CURL@@//g' \
-e 's/@@NO_PYTHON@@//g' \
git-quiltimport.sh >git-quiltimport+
chmod +x git-quiltimport+
mv git-quiltimport+ git-quiltimport
rm -f git-archimport git-archimport+
INSTLIBDIR=`make -C perl -s --no-print-directory instlibdir` && \
sed -e '1{' \
-e ' s|#!.*perl|#!/usr/bin/perl|' \
-e ' h' \
-e ' s=.*=use lib (split(/:/, $ENV{GITPERLLIB} || "@@INSTLIBDIR@@"));=' \
-e ' H' \
-e ' x' \
-e '}' \
-e 's|@@INSTLIBDIR@@|'"$INSTLIBDIR"'|g' \
-e 's/@@GIT_VERSION@@/1.4.3.5.gfe14/g' \
git-archimport.perl >git-archimport+
chmod +x git-archimport+
mv git-archimport+ git-archimport
rm -f git-cvsimport git-cvsimport+
INSTLIBDIR=`make -C perl -s --no-print-directory instlibdir` && \
sed -e '1{' \
-e ' s|#!.*perl|#!/usr/bin/perl|' \
-e ' h' \
-e ' s=.*=use lib (split(/:/, $ENV{GITPERLLIB} || "@@INSTLIBDIR@@"));=' \
-e ' H' \
-e ' x' \
-e '}' \
-e 's|@@INSTLIBDIR@@|'"$INSTLIBDIR"'|g' \
-e 's/@@GIT_VERSION@@/1.4.3.5.gfe14/g' \
git-cvsimport.perl >git-cvsimport+
chmod +x git-cvsimport+
mv git-cvsimport+ git-cvsimport
rm -f git-relink git-relink+
INSTLIBDIR=`make -C perl -s --no-print-directory instlibdir` && \
sed -e '1{' \
-e ' s|#!.*perl|#!/usr/bin/perl|' \
-e ' h' \
-e ' s=.*=use lib (split(/:/, $ENV{GITPERLLIB} || "@@INSTLIBDIR@@"));=' \
-e ' H' \
-e ' x' \
-e '}' \
-e 's|@@INSTLIBDIR@@|'"$INSTLIBDIR"'|g' \
-e 's/@@GIT_VERSION@@/1.4.3.5.gfe14/g' \
git-relink.perl >git-relink+
chmod +x git-relink+
mv git-relink+ git-relink
rm -f git-shortlog git-shortlog+
INSTLIBDIR=`make -C perl -s --no-print-directory instlibdir` && \
sed -e '1{' \
-e ' s|#!.*perl|#!/usr/bin/perl|' \
-e ' h' \
-e ' s=.*=use lib (split(/:/, $ENV{GITPERLLIB} || "@@INSTLIBDIR@@"));=' \
-e ' H' \
-e ' x' \
-e '}' \
-e 's|@@INSTLIBDIR@@|'"$INSTLIBDIR"'|g' \
-e 's/@@GIT_VERSION@@/1.4.3.5.gfe14/g' \
git-shortlog.perl >git-shortlog+
chmod +x git-shortlog+
mv git-shortlog+ git-shortlog
rm -f git-rerere git-rerere+
INSTLIBDIR=`make -C perl -s --no-print-directory instlibdir` && \
sed -e '1{' \
-e ' s|#!.*perl|#!/usr/bin/perl|' \
-e ' h' \
-e ' s=.*=use lib (split(/:/, $ENV{GITPERLLIB} || "@@INSTLIBDIR@@"));=' \
-e ' H' \
-e ' x' \
-e '}' \
-e 's|@@INSTLIBDIR@@|'"$INSTLIBDIR"'|g' \
-e 's/@@GIT_VERSION@@/1.4.3.5.gfe14/g' \
git-rerere.perl >git-rerere+
chmod +x git-rerere+
mv git-rerere+ git-rerere
rm -f git-annotate git-annotate+
INSTLIBDIR=`make -C perl -s --no-print-directory instlibdir` && \
sed -e '1{' \
-e ' s|#!.*perl|#!/usr/bin/perl|' \
-e ' h' \
-e ' s=.*=use lib (split(/:/, $ENV{GITPERLLIB} || "@@INSTLIBDIR@@"));=' \
-e ' H' \
-e ' x' \
-e '}' \
-e 's|@@INSTLIBDIR@@|'"$INSTLIBDIR"'|g' \
-e 's/@@GIT_VERSION@@/1.4.3.5.gfe14/g' \
git-annotate.perl >git-annotate+
chmod +x git-annotate+
mv git-annotate+ git-annotate
rm -f git-cvsserver git-cvsserver+
INSTLIBDIR=`make -C perl -s --no-print-directory instlibdir` && \
sed -e '1{' \
-e ' s|#!.*perl|#!/usr/bin/perl|' \
-e ' h' \
-e ' s=.*=use lib (split(/:/, $ENV{GITPERLLIB} || "@@INSTLIBDIR@@"));=' \
-e ' H' \
-e ' x' \
-e '}' \
-e 's|@@INSTLIBDIR@@|'"$INSTLIBDIR"'|g' \
-e 's/@@GIT_VERSION@@/1.4.3.5.gfe14/g' \
git-cvsserver.perl >git-cvsserver+
chmod +x git-cvsserver+
mv git-cvsserver+ git-cvsserver
rm -f git-svnimport git-svnimport+
INSTLIBDIR=`make -C perl -s --no-print-directory instlibdir` && \
sed -e '1{' \
-e ' s|#!.*perl|#!/usr/bin/perl|' \
-e ' h' \
-e ' s=.*=use lib (split(/:/, $ENV{GITPERLLIB} || "@@INSTLIBDIR@@"));=' \
-e ' H' \
-e ' x' \
-e '}' \
-e 's|@@INSTLIBDIR@@|'"$INSTLIBDIR"'|g' \
-e 's/@@GIT_VERSION@@/1.4.3.5.gfe14/g' \
git-svnimport.perl >git-svnimport+
chmod +x git-svnimport+
mv git-svnimport+ git-svnimport
rm -f git-cvsexportcommit git-cvsexportcommit+
INSTLIBDIR=`make -C perl -s --no-print-directory instlibdir` && \
sed -e '1{' \
-e ' s|#!.*perl|#!/usr/bin/perl|' \
-e ' h' \
-e ' s=.*=use lib (split(/:/, $ENV{GITPERLLIB} || "@@INSTLIBDIR@@"));=' \
-e ' H' \
-e ' x' \
-e '}' \
-e 's|@@INSTLIBDIR@@|'"$INSTLIBDIR"'|g' \
-e 's/@@GIT_VERSION@@/1.4.3.5.gfe14/g' \
git-cvsexportcommit.perl >git-cvsexportcommit+
chmod +x git-cvsexportcommit+
mv git-cvsexportcommit+ git-cvsexportcommit
rm -f git-send-email git-send-email+
INSTLIBDIR=`make -C perl -s --no-print-directory instlibdir` && \
sed -e '1{' \
-e ' s|#!.*perl|#!/usr/bin/perl|' \
-e ' h' \
-e ' s=.*=use lib (split(/:/, $ENV{GITPERLLIB} || "@@INSTLIBDIR@@"));=' \
-e ' H' \
-e ' x' \
-e '}' \
-e 's|@@INSTLIBDIR@@|'"$INSTLIBDIR"'|g' \
-e 's/@@GIT_VERSION@@/1.4.3.5.gfe14/g' \
git-send-email.perl >git-send-email+
chmod +x git-send-email+
mv git-send-email+ git-send-email
rm -f git-svn git-svn+
INSTLIBDIR=`make -C perl -s --no-print-directory instlibdir` && \
sed -e '1{' \
-e ' s|#!.*perl|#!/usr/bin/perl|' \
-e ' h' \
-e ' s=.*=use lib (split(/:/, $ENV{GITPERLLIB} || "@@INSTLIBDIR@@"));=' \
-e ' H' \
-e ' x' \
-e '}' \
-e 's|@@INSTLIBDIR@@|'"$INSTLIBDIR"'|g' \
-e 's/@@GIT_VERSION@@/1.4.3.5.gfe14/g' \
git-svn.perl >git-svn+
chmod +x git-svn+
mv git-svn+ git-svn
rm -f git-merge-recursive-old git-merge-recursive-old+
sed -e '1s|#!.*python|#!/usr/bin/python|' \
-e 's|@@GIT_PYTHON_PATH@@|/var/tmp/ggg/share/git-core/python|g' \
-e 's/@@GIT_VERSION@@/1.4.3.5.gfe14/g' \
git-merge-recursive-old.py >git-merge-recursive-old+
chmod +x git-merge-recursive-old+
mv git-merge-recursive-old+ git-merge-recursive-old
cp git-revert git-cherry-pick+
mv git-cherry-pick+ git-cherry-pick
cp git-commit git-status+
mv git-status+ git-status
rm -f gitweb/gitweb.cgi gitweb/gitweb.cgi+
sed -e '1s|#!.*perl|#!/usr/bin/perl|' \
-e 's|++GIT_VERSION++|1.4.3.5.gfe14|g' \
-e 's|++GIT_BINDIR++|/var/tmp/ggg/bin|g' \
-e 's|++GITWEB_CONFIG++|gitweb_config.perl|g' \
-e 's|++GITWEB_HOME_LINK_STR++|projects|g' \
-e 's|++GITWEB_SITENAME++||g' \
-e 's|++GITWEB_PROJECTROOT++|/pub/git|g' \
-e 's|++GITWEB_EXPORT_OK++||g' \
-e 's|++GITWEB_STRICT_EXPORT++||g' \
-e 's|++GITWEB_BASE_URL++||g' \
-e 's|++GITWEB_LIST++||g' \
-e 's|++GITWEB_HOMETEXT++|indextext.html|g' \
-e 's|++GITWEB_CSS++|gitweb.css|g' \
-e 's|++GITWEB_LOGO++|git-logo.png|g' \
-e 's|++GITWEB_FAVICON++|git-favicon.png|g' \
gitweb/gitweb.perl >gitweb/gitweb.cgi+
chmod +x gitweb/gitweb.cgi+
mv gitweb/gitweb.cgi+ gitweb/gitweb.cgi
rm -f git-instaweb git-instaweb+
sed -e '1s|#!.*/sh|#!/bin/sh|' \
-e 's/@@GIT_VERSION@@/1.4.3.5.gfe14/g' \
-e 's/@@NO_CURL@@//g' \
-e 's/@@NO_PYTHON@@//g' \
-e '/@@GITWEB_CGI@@/r gitweb/gitweb.cgi' \
-e '/@@GITWEB_CGI@@/d' \
-e '/@@GITWEB_CSS@@/r gitweb/gitweb.css' \
-e '/@@GITWEB_CSS@@/d' \
git-instaweb.sh > git-instaweb+
chmod +x git-instaweb+
mv git-instaweb+ git-instaweb
rm -f git-merge-recur && ln git-merge-recursive git-merge-recur
rm -f git-format-patch && ln git git-format-patch
rm -f git-show && ln git git-show
rm -f git-whatchanged && ln git git-whatchanged
rm -f git-get-tar-commit-id && ln git git-get-tar-commit-id
rm -f git-add && ln git git-add
rm -f git-apply && ln git git-apply
rm -f git-archive && ln git git-archive
rm -f git-cat-file && ln git git-cat-file
rm -f git-checkout-index && ln git git-checkout-index
rm -f git-check-ref-format && ln git git-check-ref-format
rm -f git-commit-tree && ln git git-commit-tree
rm -f git-count-objects && ln git git-count-objects
rm -f git-diff && ln git git-diff
rm -f git-diff-files && ln git git-diff-files
rm -f git-diff-index && ln git git-diff-index
rm -f git-diff-stages && ln git git-diff-stages
rm -f git-diff-tree && ln git git-diff-tree
rm -f git-fmt-merge-msg && ln git git-fmt-merge-msg
rm -f git-grep && ln git git-grep
rm -f git-init-db && ln git git-init-db
rm -f git-log && ln git git-log
rm -f git-ls-files && ln git git-ls-files
rm -f git-ls-tree && ln git git-ls-tree
rm -f git-mailinfo && ln git git-mailinfo
rm -f git-mailsplit && ln git git-mailsplit
rm -f git-mv && ln git git-mv
rm -f git-name-rev && ln git git-name-rev
rm -f git-pack-objects && ln git git-pack-objects
rm -f git-prune && ln git git-prune
rm -f git-prune-packed && ln git git-prune-packed
rm -f git-push && ln git git-push
rm -f git-read-tree && ln git git-read-tree
rm -f git-repo-config && ln git git-repo-config
rm -f git-rev-list && ln git git-rev-list
rm -f git-rev-parse && ln git git-rev-parse
rm -f git-rm && ln git git-rm
rm -f git-runstatus && ln git git-runstatus
rm -f git-show-branch && ln git git-show-branch
rm -f git-stripspace && ln git git-stripspace
rm -f git-symbolic-ref && ln git git-symbolic-ref
rm -f git-tar-tree && ln git git-tar-tree
rm -f git-unpack-objects && ln git git-unpack-objects
rm -f git-update-index && ln git git-update-index
rm -f git-update-ref && ln git git-update-ref
rm -f git-upload-archive && ln git git-upload-archive
rm -f git-write-tree && ln git git-write-tree
make -C perl
make[1]: Entering directory `/git.git/perl'
cp Git.pm blib/lib/Git.pm
Manifying blib/man3/Git.3pm
make[1]: Leaving directory `/git.git/perl'
make -C templates
make[1]: Entering directory `/git.git/templates'
ls *--* 2>/dev/null | \
while read boilerplate; \
do \
case "$boilerplate" in *~) continue ;; esac && \
dst=`echo "$boilerplate" | sed -e 's|^this|.|;s|--|/|g'` && \
dir=`expr "$dst" : '\(.*\)/'` && \
mkdir -p blt/$dir && \
case "$boilerplate" in \
*--) ;; \
*) cp $boilerplate blt/$dst ;; \
esac || exit; \
done || exit
date >boilerplates.made
: no custom templates yet
make[1]: Leaving directory `/git.git/templates'
install -d -m755 '/var/tmp/ggg/bin'
install -d -m755 '/var/tmp/ggg/bin'
install git-convert-objects git-fetch-pack git-fsck-objects git-hash-object git-index-pack git-local-fetch git-merge-base git-daemon git-merge-index git-mktag git-mktree git-patch-id git-peek-remote git-receive-pack git-send-pack git-shell git-show-index git-ssh-fetch git-ssh-upload git-unpack-file git-update-server-info git-upload-pack git-verify-pack git-pack-redundant git-var git-describe git-merge-tree git-blame git-imap-send git-merge-recursive git-ssh-pull git-ssh-push git-http-fetch git-http-push git-bisect git-branch git-checkout git-cherry git-clean git-clone git-commit git-fetch git-ls-remote git-merge-one-file git-parse-remote git-pull git-rebase git-repack git-request-pull git-reset git-resolve git-revert git-sh-setup git-tag git-verify-tag git-applymbox git-applypatch git-am git-merge git-merge-stupid git-merge-octopus git-merge-resolve git-merge-ours git-lost-found git-quiltimport git-archimport git-cvsimport git-relink git-shortlog git-rerere git-annotate git-cvsserver git-svnimport git-cvsexportcommit git-send-email git-svn git-merge-recursive-old git-cherry-pick git-status git-instaweb git-merge-recur '/var/tmp/ggg/bin'
install git gitk '/var/tmp/ggg/bin'
make -C templates DESTDIR='' install
make[1]: Entering directory `/git.git/templates'
: no custom templates yet
install -d -m755 '/var/tmp/ggg/share/git-core/templates/'
(cd blt && tar cf - .) | \
(cd '/var/tmp/ggg/share/git-core/templates/' && tar xf -)
make[1]: Leaving directory `/git.git/templates'
make -C perl install
make[1]: Entering directory `/git.git/perl'
Installing /var/tmp/ggg/share/perl/5.8.8/Git.pm
Installing /var/tmp/ggg/man/man3/Git.3pm
Writing /var/tmp/ggg/lib/perl/5.8.8/auto/Git/.packlist
Appending installation info to /var/tmp/ggg/lib/perl/5.8.8/perllocal.pod
make[1]: Leaving directory `/git.git/perl'
install -d -m755 '/var/tmp/ggg/share/git-core/python'
install gitMergeCommon.py '/var/tmp/ggg/share/git-core/python'
if test 'z/var/tmp/ggg/bin' != 'z/var/tmp/ggg/bin'; \
then \
ln -f '/var/tmp/ggg/bin/git' \
'/var/tmp/ggg/bin/git' || \
cp '/var/tmp/ggg/bin/git' \
'/var/tmp/ggg/bin/git'; \
fi
rm -f '/var/tmp/ggg/bin/git-format-patch' && ln '/var/tmp/ggg/bin/git' '/var/tmp/ggg/bin/git-format-patch' ; rm -f '/var/tmp/ggg/bin/git-show' && ln '/var/tmp/ggg/bin/git' '/var/tmp/ggg/bin/git-show' ; rm -f '/var/tmp/ggg/bin/git-whatchanged' && ln '/var/tmp/ggg/bin/git' '/var/tmp/ggg/bin/git-whatchanged' ; rm -f '/var/tmp/ggg/bin/git-get-tar-commit-id' && ln '/var/tmp/ggg/bin/git' '/var/tmp/ggg/bin/git-get-tar-commit-id' ; rm -f '/var/tmp/ggg/bin/git-add' && ln '/var/tmp/ggg/bin/git' '/var/tmp/ggg/bin/git-add' ; rm -f '/var/tmp/ggg/bin/git-apply' && ln '/var/tmp/ggg/bin/git' '/var/tmp/ggg/bin/git-apply' ; rm -f '/var/tmp/ggg/bin/git-archive' && ln '/var/tmp/ggg/bin/git' '/var/tmp/ggg/bin/git-archive' ; rm -f '/var/tmp/ggg/bin/git-cat-file' && ln '/var/tmp/ggg/bin/git' '/var/tmp/ggg/bin/git-cat-file' ; rm -f '/var/tmp/ggg/bin/git-checkout-index' && ln '/var/tmp/ggg/bin/git' '/var/tmp/ggg/bin/git-checkout-index' ; rm -f '/var/tmp/ggg/bin/git-check-ref-format' && ln '/var/tmp/ggg/bin/git' '/var/tmp/ggg/bin/git-check-ref-format' ; rm -f '/var/tmp/ggg/bin/git-commit-tree' && ln '/var/tmp/ggg/bin/git' '/var/tmp/ggg/bin/git-commit-tree' ; rm -f '/var/tmp/ggg/bin/git-count-objects' && ln '/var/tmp/ggg/bin/git' '/var/tmp/ggg/bin/git-count-objects' ; rm -f '/var/tmp/ggg/bin/git-diff' && ln '/var/tmp/ggg/bin/git' '/var/tmp/ggg/bin/git-diff' ; rm -f '/var/tmp/ggg/bin/git-diff-files' && ln '/var/tmp/ggg/bin/git' '/var/tmp/ggg/bin/git-diff-files' ; rm -f '/var/tmp/ggg/bin/git-diff-index' && ln '/var/tmp/ggg/bin/git' '/var/tmp/ggg/bin/git-diff-index' ; rm -f '/var/tmp/ggg/bin/git-diff-stages' && ln '/var/tmp/ggg/bin/git' '/var/tmp/ggg/bin/git-diff-stages' ; rm -f '/var/tmp/ggg/bin/git-diff-tree' && ln '/var/tmp/ggg/bin/git' '/var/tmp/ggg/bin/git-diff-tree' ; rm -f '/var/tmp/ggg/bin/git-fmt-merge-msg' && ln '/var/tmp/ggg/bin/git' '/var/tmp/ggg/bin/git-fmt-merge-msg' ; rm -f '/var/tmp/ggg/bin/git-grep' && ln '/var/tmp/ggg/bin/git' '/var/tmp/ggg/bin/git-grep' ; rm -f '/var/tmp/ggg/bin/git-init-db' && ln '/var/tmp/ggg/bin/git' '/var/tmp/ggg/bin/git-init-db' ; rm -f '/var/tmp/ggg/bin/git-log' && ln '/var/tmp/ggg/bin/git' '/var/tmp/ggg/bin/git-log' ; rm -f '/var/tmp/ggg/bin/git-ls-files' && ln '/var/tmp/ggg/bin/git' '/var/tmp/ggg/bin/git-ls-files' ; rm -f '/var/tmp/ggg/bin/git-ls-tree' && ln '/var/tmp/ggg/bin/git' '/var/tmp/ggg/bin/git-ls-tree' ; rm -f '/var/tmp/ggg/bin/git-mailinfo' && ln '/var/tmp/ggg/bin/git' '/var/tmp/ggg/bin/git-mailinfo' ; rm -f '/var/tmp/ggg/bin/git-mailsplit' && ln '/var/tmp/ggg/bin/git' '/var/tmp/ggg/bin/git-mailsplit' ; rm -f '/var/tmp/ggg/bin/git-mv' && ln '/var/tmp/ggg/bin/git' '/var/tmp/ggg/bin/git-mv' ; rm -f '/var/tmp/ggg/bin/git-name-rev' && ln '/var/tmp/ggg/bin/git' '/var/tmp/ggg/bin/git-name-rev' ; rm -f '/var/tmp/ggg/bin/git-pack-objects' && ln '/var/tmp/ggg/bin/git' '/var/tmp/ggg/bin/git-pack-objects' ; rm -f '/var/tmp/ggg/bin/git-prune' && ln '/var/tmp/ggg/bin/git' '/var/tmp/ggg/bin/git-prune' ; rm -f '/var/tmp/ggg/bin/git-prune-packed' && ln '/var/tmp/ggg/bin/git' '/var/tmp/ggg/bin/git-prune-packed' ; rm -f '/var/tmp/ggg/bin/git-push' && ln '/var/tmp/ggg/bin/git' '/var/tmp/ggg/bin/git-push' ; rm -f '/var/tmp/ggg/bin/git-read-tree' && ln '/var/tmp/ggg/bin/git' '/var/tmp/ggg/bin/git-read-tree' ; rm -f '/var/tmp/ggg/bin/git-repo-config' && ln '/var/tmp/ggg/bin/git' '/var/tmp/ggg/bin/git-repo-config' ; rm -f '/var/tmp/ggg/bin/git-rev-list' && ln '/var/tmp/ggg/bin/git' '/var/tmp/ggg/bin/git-rev-list' ; rm -f '/var/tmp/ggg/bin/git-rev-parse' && ln '/var/tmp/ggg/bin/git' '/var/tmp/ggg/bin/git-rev-parse' ; rm -f '/var/tmp/ggg/bin/git-rm' && ln '/var/tmp/ggg/bin/git' '/var/tmp/ggg/bin/git-rm' ; rm -f '/var/tmp/ggg/bin/git-runstatus' && ln '/var/tmp/ggg/bin/git' '/var/tmp/ggg/bin/git-runstatus' ; rm -f '/var/tmp/ggg/bin/git-show-branch' && ln '/var/tmp/ggg/bin/git' '/var/tmp/ggg/bin/git-show-branch' ; rm -f '/var/tmp/ggg/bin/git-stripspace' && ln '/var/tmp/ggg/bin/git' '/var/tmp/ggg/bin/git-stripspace' ; rm -f '/var/tmp/ggg/bin/git-symbolic-ref' && ln '/var/tmp/ggg/bin/git' '/var/tmp/ggg/bin/git-symbolic-ref' ; rm -f '/var/tmp/ggg/bin/git-tar-tree' && ln '/var/tmp/ggg/bin/git' '/var/tmp/ggg/bin/git-tar-tree' ; rm -f '/var/tmp/ggg/bin/git-unpack-objects' && ln '/var/tmp/ggg/bin/git' '/var/tmp/ggg/bin/git-unpack-objects' ; rm -f '/var/tmp/ggg/bin/git-update-index' && ln '/var/tmp/ggg/bin/git' '/var/tmp/ggg/bin/git-update-index' ; rm -f '/var/tmp/ggg/bin/git-update-ref' && ln '/var/tmp/ggg/bin/git' '/var/tmp/ggg/bin/git-update-ref' ; rm -f '/var/tmp/ggg/bin/git-upload-archive' && ln '/var/tmp/ggg/bin/git' '/var/tmp/ggg/bin/git-upload-archive' ; rm -f '/var/tmp/ggg/bin/git-verify-pack' && ln '/var/tmp/ggg/bin/git' '/var/tmp/ggg/bin/git-verify-pack' ; rm -f '/var/tmp/ggg/bin/git-write-tree' && ln '/var/tmp/ggg/bin/git' '/var/tmp/ggg/bin/git-write-tree' ;
: gitster;
Script done on Tue 14 Nov 2006 08:44:28 PM PST
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Nicolas Pitre @ 2006-11-15 4:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git
In-Reply-To: <7vd57ps51c.fsf@assigned-by-dhcp.cox.net>
On Tue, 14 Nov 2006, Junio C Hamano wrote:
> Yes. The current "merge" started its life as Linus's porcelain
> (we did not have fetch and pull infrastructure back then) but
> quickly has become just a helper for pull to produce a merge
> commit. If anybody thinks its UI is good as a general end-user
> level command, there is a need for "head examination".
If you mean "git merge" it sure needs to be brought forward. It can't
be clearer than:
git-merge the_other_branch
or
git-merge git://repo.com/time_machine.git
to instantaneously understand what is going on.
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Junio C Hamano @ 2006-11-15 4:33 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20061115040852.GL7201@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> On Wed, Nov 15, 2006 at 01:31:50AM CET, Junio C Hamano wrote:
>>
>> I am of two minds here.
>>
>> I do not think the Porcelain-ish UI that is shipped with git
>> should be taken with the same degree of "authority" as git
>> Plumbing.
> ..snip passage about workflows..
>
> Controversy's fun, so...
>
> <Cogito maintainer hat _off_> (But yeah, it still looks silly that I'm
> saying this.)
It appears that you are not grumpy as you were anymore ;-). I
mostly agree with what you said in your message.
> (i) Clearly divided porcelain/plumbing interface, so that you can
> really isolate the two UI-wise; endless confusion reigns there now. Is
> git-update-index porcelain or plumbing? _You_ call git-merge a proper
> porcelain? From my perspective, git-update-ref is as plumbing as it
> gets, but it's classified as porcelain. Etc, etc. This would be by far
> the most important advantage.
Yes. The current "merge" started its life as Linus's porcelain
(we did not have fetch and pull infrastructure back then) but
quickly has become just a helper for pull to produce a merge
commit. If anybody thinks its UI is good as a general end-user
level command, there is a need for "head examination".
As you say, update-ref is as plumbing as it gets and it should
not be listed as Porcelain; I am a bit surprised that it is
labelled as such myself.
No disagreement here, nor (ii) nor (iii).
> (ii) The plumbing and porcelain would not share the same namespace,
> leading to clearer UI. (I'm just inflating (i).)
>
> (iii) The documentation would not be a strange mix of porcelain and
> plumbing. (More (i) inflation.)
>
> (iv) (i) is troublesome because I have a feeling that Junio declared
> several times that he doesn't care that much about stable API for
> porcelain compared to the plumbing. But with the current mix it's
> desirable to use some porcelain even in other porcelains and in scripts.
This is true and it is a problem.
While we encourage Porcelain writers to use plumbing in order to
give git Porcelain-ish more freedom to evolve to give better UI
for humans, not having a clear distinction between the two makes
it harder.
> (v) Git would be properly libified by now. If you wanted to convert
> bits of porcelain to C, it would be at least much higher priority.
I am not sure about "libified" part and I do not know what bits
of porcelain wants to become C right now. But I do not think
this point is important part of your list.
> (vi) You wouldn't need to make the gruesome choice on what is the
> canonical workflow the _the_ Git porcelain supports (see the snipped
> passage). Or you would, but it would have less impact.
Yes. This is really important.
Linus and me having done Porcelain-ish that supports integrator
role workflow better than other workflows such as contributor
role should not discourage people from working on alternative or
complementary Porcelains to help other workflows better (see the
snipped passage).
StGIT sets a great example, and efforts like it is encoraged
more.
I think both Linus and myself tried to make it clear that the
purpose of Porcelain-ish that comes with core git is 50% to make
plumbing (perhaps minimally) usable and the other 50% to serve
as an example for Porcelain writers to learn how to use the
plumbing, but we should probably have stressed the latter
better.
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Nicolas Pitre @ 2006-11-15 4:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Andy Whitcroft, Carl Worth
In-Reply-To: <7virhhy76h.fsf@assigned-by-dhcp.cox.net>
On Tue, 14 Nov 2006, Junio C Hamano wrote:
> Junio C Hamano <junkio@cox.net> writes:
>
> > - I think it would be sensible to make remote tracking branches
> > less visible. For example:
> >...
> > - "git merge" to merge another branch into the current would
> > make sense. "git pull . remotes/origin/next" is showing too
> > much implementation detail. It should just be:
> >
> > git merge origin#next
>
> This and other examples in "making remote tracking branches less
> visible" are hard to read because I used the word "origin" in
> two different sense. So here is a needed clarification.
>
> If you have remotes/upstream that says:
>
> URL: git://git.xz/repo.git
> Pull: refs/heads/master:remotes/origin/master
> Pull: refs/heads/next:remotes/origin/next
>
> Then, currently the users need to say:
>
> git diff remotes/origin/master
> git merge remotes/origin/next
>
> By "making tracking branches less visible", what I mean is to
> let the users say this instead:
>
> git diff upstream
> git merge upstream#next
What is the point of hiding tracking branches? Why just not making them
easier to use instead? There are currently so many ways to specify
remote branches that even I get confused.
OK..... let's pretend this is my follow-up to your "If I were redoing
git from scratch" query. Actually I would not redo it from scratch
since the vast majority of it is rather sane already. But here's some
changes that I would do:
1) make "git init" an alias for "git init-db".
What's the point of "-db"? Sure we're initializing the GIT database.
But who cares? The user doesn't care if GIT uses a "database" or
whatever. And according to some people's definition of a "database" it
could be argued that GIT doesn't use a database at all in the purist
sense of it. What the user wants is to get started and "init" (without
the "-db" is so much more to the point. Doesn't matter if incidentally
it happens to be the same keyword HG uses for the same operation because
we are not afflicted by the NIH disease, right? And it has 3 chars less
to type which is for sure a premium improvement to the very first GIT
user experience!
2) "pull" and "push" should be symmetrical operations
They are symmetrical in the dictionary and in people's mind. OK but what
if I merge content from another _local_ branch into the current one?
Isn't that kind of a pull as well? Answer: NO IT IS NOT! Reason:
because we already have "merge" for that very operation for damn sake!
And because "merging" isn't a synonym for "pulling" at all, we cannot
pretend it should sort of become more true if taken the other way
around.
Actually, if we _merge_ stuff together, we certainly have to /pull/ some
of it, meaning that "merge" might imply a "pull", even in real life
situations outside of the GIT context (think merging Vodka and Kahlua in
a glass where you might have to pull the Vodka bottle out of the freezer
before you can merge it). And thankfully we got it right with git-merge
which can take either a branch or an URL as argument which in the later
case will perform a pull implicitly (OK currently a fetch but you know
what I mean).
But trying to put in people's head that "pulling" implies a "merge"? No
that doesn't work really well. OK if you pull too hard on the Vodka
bottle that might imply a merge at some point but it would certainly be
accidental. And it is not without coincidence that some people had
accidental GIT merges by using git-pull.
Conclusion: git-pull must not perform any merge. It is the symmetrical
operation of a push meaning that it pulls content from a remote branch
and does no more. People understands that pretty well, . This makes
git-fetch redundant (or an alias to git-pull) in that case, and again we
don't mind it becoming similar to in HG because we admit HG was right
about it.
3) remote branch handling should become more straight forward.
OK! Now that we've solved the pull issue and that everybody agrees with
me (how can't you all agree with me anyway) let's have a look at remote
branches. It should be simple:
a) git-pull git://repo.com/time_machine.git
This pulls every branches from the time_machine.git repository and
create identically named branches locally, except for the remote
master becoming origin locally. All those branches are marked read-only
(i.e. cannot commit to them) and _each_ of those branches get an URL
associated to them somehow (the association is an implementation
detail).
If then you do:
b) git-pull origin
Then it will pull the git://repo.com/time_machine.git:master branch into
the local "origin" branch. IOW, local tracking branches becomes
synonyms for their remote URLs after they've been pulled once. If the
remote branch "next" became a local "next" with the first pull (because
it didn't specify any branch meaning that they were all pulled), doing
a:
c) git-pull next
would actually be the same as:
d) git-pull git://repo.com/time_machine.git:next
Now to have different remote and local names for those tracking
branches:
e) git-pull git://repo.com/time_machine.git:master upstream
would be a variation where a remote branch gets a different local name.
This pulls the remote master branch but calls it "upstream" locally.
If that "upstream" branch does exist locally already then fail with
appropriate error message, unless the local branch happens to have the
same URL attribute already. You then have two local branches tracking
the same remote branch which is weird but still fine if someone wants
to have different views (today's pull and yesterday's pull). This is
not necessarily something to encourage but only a fallout of the branch
semantic. And again a simple:
f) git-pull upstream
would update the "upstream" branch from the remote master branch.
I think the concept of "branch group" should be preserved too. So if
you create a group called "warp", then add "origin", "next", and
"upstream" to it, then:
g) git-pull warp
would pull all the included branches. One way to create a branch group
with the initial pull is not to specify the remote branch but only the
repository URL, like:
h) git-pull git://repo.com/time_machine.git warp
Because no specific branch in the remote repository was specified just
like in (a) then all branches are pulled, but because a local name was
provided then this becomes a branch group.
Branch groups could be used to extend the branch namespace as well to
avoid clashes with different remote repositories. In this case the
branch groups could be a way to arrange branches in a hierarchy so
"warp" refer to all branches included in the warp group while
"warp/upstream" refer to only one branch. In this case "upstream" and
"warp/upstream" would be the same branch if "upstream" was effectively
added to the "warp" group, but it doesn't need to be so. And branches
in a group don't have to come from the same remote repository either
since the source of each branch (the URL) is a per branch attribute.
To make it "easy" on the user, I think that any branch (or tag) down the
hierarchy should be used without the "path" leading to it if there is no
conflict. We already do that with heads and tags, So if for example the
"warp" group contained a branch named "lightspeed" but no such branch
(or tag) existed anywhere else then it could be referenced with simply
"lightspeed" or "warp/lightspeed".
Then you don't need any strange scheme for diff and merge. Just using
"git-diff upstream" or "git-merge origin next" suffice. Oh and I don't
think it would be a good idea to have a completely separate namespace
for local vs remote aka tracking branches. Maybe in .git/refs/ they
should be separate to distinguish which ones are read-only remote
tracking ones and which ones are local, but that must not be forced on
the UI.
Thinking about it some more, maybe (a) should create a default branch
group if the remote repository has more than one branches, say "origin".
This way, git-pull without any argument would be the same as
"git-pull origin" by default. If "origin" is a single branch then
(git-pull" would pull only one branch, but if "origin" is a branch group
then all included branches would be pulled.
This becomes formalized as:
git_pull [<URL>] [<local_name>]
If <URL> includes a branch name then <local_name> is a single branch
name. If <URL> doesn't include any branch name then <local_name>
becomes a local branch group name containing all branches in the remote
repository. If <URL> is specified but not <local_name> then <local_name>
is set to "origin" by default, unless it already exists in which case it
is an error and the pull fails. If <URL> is not specified then the URL
attribute to the specified branch(es) is used. If nothing is specified
then "origin" is used for <local_name> by default and URL attribute of
the origin branch or the origin branch group is/are used.
*****
OK I think this is enough for now. I know that parts of what I've said
can already be found in GIT, but I wanted the explanation to be
complete and therefore tentatively coherent.
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Nicolas Pitre @ 2006-11-15 4:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3b8ltq7r.fsf@assigned-by-dhcp.cox.net>
On Tue, 14 Nov 2006, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > "You pull the remote changes with 'git-pull upstream,, then you can
> > merge them in your current branch with 'git-merge upstream'."
> >
> > Isn't it much simpler to understand (and to teach) that way?
>
> If it were "you download the remote changes with 'git download
> upstream' and then merge with 'git merge'", then perhaps, but if
> you used the word "pull" or "fetch", I do not think so.
>
> I would be all for changing the semantics of "pull" from one
> thing to another, if the new semantics were (1) what everybody
> welcomed, (2) what "pull" traditionally meant everywhere else.
> In that case, we have been misusing it to be confusing to
> outsiders and I agree it makes a lot of sense to remove the
> source of confusion. But I do not think CVS nor SVN ever used
> the term, and I was told that BK was what introduced the term,
> and the word meant something different from what you are
> proposing.
>
> You have to admit both pull and fetch have been contaminated
> with loaded meanings from different backgrounds. I was talking
> about killing the source of confusion in the longer term by
> removing fetch/pull/push, so we are still on the same page.
>
> That's where my "you download from the upstream and merge" comes
> from.
But the fact is that HG (which has a growing crowd of happy campers,
maybe even larger than the BK crowd now) did work with and got used to a
sensible definition of what a "pull" is. This means that their
definition is becoming rather more relevant with time than what it used
to, and because it is a saner definition than what GIT has for the same
word which HG users really have no issue with, I think we really should
leverage the "common wisdom" and consider aligning ourselves with them
in this case rather than trying to go into a totally different
direction. We simply won't gain anything trying to teach people "a pull
in HG is a download in GIT". If a pull becomes the same thing for both
then it's one less oddball in the GIT interface.
^ permalink raw reply
* RE: [GIT PATCH] Makefile missing git-runstatus in PROGRAMS list
From: Bhavesh Davda @ 2006-11-15 4:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
> > diff --git a/Makefile b/Makefile
> > index 36ce8cd..24a0dc7 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -202,7 +202,7 @@ PROGRAMS = \
> > git-upload-pack$X git-verify-pack$X \
> > git-pack-redundant$X git-var$X \
> > git-describe$X git-merge-tree$X git-imap-send$X \
> > - git-merge-recursive$X \
> > + git-merge-recursive$X git-runstatus$X \
> > $(EXTRA_PROGRAMS)
> >
> > # Empty...
>
> This cannot be right. There is builtin-runstatus.o defined as
> part of BUILTIN_OBJS so you already should have git-runstatus as
> a hardlink to other binaries such as git-add, git-apply
> etc. in the same directory as you have them.
>
> I seem to have 55 hardlinks to that file under my ~/bin/.
>
So I just blew away /usr/bin/git*, and removed my Makefile patch, and did
another:
make prefix=/usr all (as myself)
and then
sudo make prefix=/usr install
I now *don't* have /usr/bin/git-runstatus.
And none of the files under /usr/bin/git* are hard links. There are in all 79
files beginning with /usr/bin/git*:
git git-am git-applymbox git-applypatch git-archimport git-bisect
git-checkout git-cherry-pick git-clean git-clone git-commit
git-convert-objects git-cvsexportcommit git-cvsimport git-cvsserver
git-daemon git-describe git-fetch git-fetch-pack git-fsck-objects
git-hash-object git-http-fetch git-http-push git-imap-send git-index-pack
git-instaweb git-local-fetch git-lost-found git-ls-remote git-merge
git-merge-base git-merge-index git-merge-octopus git-merge-one-file
git-merge-ours git-merge-recur git-merge-recursive git-merge-recursive-old
git-merge-resolve git-merge-stupid git-merge-tree git-mktag git-mktree
git-pack-redundant git-parse-remote git-patch-id git-peek-remote git-pull
git-quiltimport git-rebase git-receive-pack git-relink git-repack
git-request-pull git-rerere git-reset git-resolve git-revert git-send-email
git-send-pack git-sh-setup git-shell git-shortlog git-show-index
git-ssh-fetch git-ssh-pull git-ssh-push git-ssh-upload git-status git-svn
git-svnimport git-tag git-unpack-file git-update-server-info git-upload-pack
git-var git-verify-pack git-verify-tag gitk
I haven't tried make -p yet, but can do that to see why git-runstatus isn't
installed under /usr/bin
Thanks
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Petr Baudis @ 2006-11-15 4:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Carl Worth, git, Andy Whitcroft
In-Reply-To: <7v3b8lv9c9.fsf@assigned-by-dhcp.cox.net>
On Wed, Nov 15, 2006 at 01:31:50AM CET, Junio C Hamano wrote:
> Carl Worth <cworth@cworth.org> writes:
>
> > On Tue, 14 Nov 2006 20:47:07 +0100, Petr Baudis wrote:
> >> Hmm, did they (not) consider Cogito? They wouldn't have those issues.
> >
> > I didn't ask.
> >
> > Frankly, I don't see a lot of value in the git/cogito split right now.
> > ...
> > It's great that git is written in a script-friendly way so that new
> > interfaces can be built on top of it. And I think the benefits of new
> > user interfaces are clear when they work in fundamentally different
> > ways, (say, being operated through a GUI). But where git and cogito
> > are both command-line utilities and have the same basic functionality,
> > ...
> > There are some things that cogito does that git does not that I would
> > like to have in git.
> > ...
> > I don't see any defining difference that justifies cogito's
> > existence ("hide the index" maybe? let's just hide it a tiny bit more
> > in git). And I would like to help work to get the remaining good
> > stuff that has been proven in cogito---to get it pushed down into git
> > itself.
>
> I am of two minds here.
>
> I do not think the Porcelain-ish UI that is shipped with git
> should be taken with the same degree of "authority" as git
> Plumbing.
..snip passage about workflows..
Controversy's fun, so...
<Cogito maintainer hat _off_> (But yeah, it still looks silly that I'm
saying this.)
From the current perspective, I think it has been a mistake that the
porcelain and plumbing was not kept separate in independent packages,
and perhaps even maintained separately (and perhaps not; at least having
a single tree with plumbing/ and porcelain/ directories and separate
packages in distributions might already help something), so that "git"
would be kept as a kind of library and then there would be a separate
package providing an interface to it. Or you could select one of several
packages. Not only would that make Cogito prevail in the world and bring
me a flood of marriage proposals, but look at how would it help the
general public:
(i) Clearly divided porcelain/plumbing interface, so that you can
really isolate the two UI-wise; endless confusion reigns there now. Is
git-update-index porcelain or plumbing? _You_ call git-merge a proper
porcelain? From my perspective, git-update-ref is as plumbing as it
gets, but it's classified as porcelain. Etc, etc. This would be by far
the most important advantage.
(ii) The plumbing and porcelain would not share the same namespace,
leading to clearer UI. (I'm just inflating (i).)
(iii) The documentation would not be a strange mix of porcelain and
plumbing. (More (i) inflation.)
(iv) (i) is troublesome because I have a feeling that Junio declared
several times that he doesn't care that much about stable API for
porcelain compared to the plumbing. But with the current mix it's
desirable to use some porcelain even in other porcelains and in scripts.
(v) Git would be properly libified by now. If you wanted to convert
bits of porcelain to C, it would be at least much higher priority.
(vi) You wouldn't need to make the gruesome choice on what is the
canonical workflow the _the_ Git porcelain supports (see the snipped
passage). Or you would, but it would have less impact.
(vii) The world would be a happier place.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply
* Re: Sometimes "Failed to find remote refs" means "try git-fetch --no-tags"
From: Junio C Hamano @ 2006-11-15 4:05 UTC (permalink / raw)
To: Michael K. Edwards; +Cc: git
In-Reply-To: <f2b55d220611141953t48d81ac5q4f48183ae79ba0a@mail.gmail.com>
"Michael K. Edwards" <medwards.linux@gmail.com> writes:
> Down inside git-ls-remote there is a die "Failed to find remote refs".
> This struck when I tried to fetch an http repository with a missing
> info/refs file. Using "git fetch --no-tags" succeeds because it
> doesn't have to call git-ls-remote at all. Does git-ls-remote have
> any way of knowing who is calling it so that it can print a
> context-appropriate error message? If not, is it worth adding some
> sort of "caller context" mechanism, perhaps at the boundary between
> porcelain and plumbing?
I think letting git-ls-remote know who called it makes sense for
better error reporting. I am all for it.
However "fetch --no-tags" from http upstream is a band-aid to
hide that the upstream repository has stale info/refs, and I do
not think we would want to encourage the band-aid. Rather, the
message should say "yell loudly at the repository owner" ;-).
Seriously, when people starts using packed-refs that will be in
v1.4.4 scheduled for tomorrow on the public site, I think the
best way to adjust the commit walker clients is to have them
download info/refs and start traversing from the objects listed
there, instead of downloading .git/refs/heads/$branch and
.git/refs/tags/$tag files as we currently do, so the band-aid
would become less useful.
^ permalink raw reply
* Sometimes "Failed to find remote refs" means "try git-fetch --no-tags"
From: Michael K. Edwards @ 2006-11-15 3:53 UTC (permalink / raw)
To: git
Down inside git-ls-remote there is a die "Failed to find remote refs".
This struck when I tried to fetch an http repository with a missing
info/refs file. Using "git fetch --no-tags" succeeds because it
doesn't have to call git-ls-remote at all. Does git-ls-remote have
any way of knowing who is calling it so that it can print a
context-appropriate error message? If not, is it worth adding some
sort of "caller context" mechanism, perhaps at the boundary between
porcelain and plumbing? Or should the error message include, "If you
were trying to do a 'git fetch', try --no-tags; you won't get tags but
you may get a good update of the branch content"?
Cheers,
^ permalink raw reply
* how to authenticate with git-svn on a subversion repository
From: Comète @ 2006-11-14 14:32 UTC (permalink / raw)
To: git
hello !
i would like to use git-svn to commit some modifications to a Subversion
repository but i don't know where i can enter my username and password
to commit to the repository ? Is there any special file to put them.
For now i get an error:
# git-svn commit remotes/git-svn
Autorisation refusée: MKACTIVITY de
'/svn/!svn/act/8115f5df-c0da-4a6d-91ef-135dcb76141c': Échec à
l'autorisation (http://projet.archlinuxfr.org) at /usr/bin/git-svn line 553
512 at /usr/bin/git-svn line 574
main::commit_lib('f45ba41060287fedfcedfb5fc4c29ecfe30a7466') called at
/usr/bin/git-svn line 480
main::commit('remotes/git-svn') called at /usr/bin/git-svn line 172
Thanks
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Michael K. Edwards @ 2006-11-15 2:27 UTC (permalink / raw)
To: git
In-Reply-To: <7v3b8ltq7r.fsf@assigned-by-dhcp.cox.net>
I would kind of like to see "git poll" -- visit all remote branches,
fetching objects and tags into the local repository, so that I can
inspect changes off-line and merge, cherry-pick, etc. to my heart's
content. That would fit the platform integrator's workflow nicely --
"git poll" into a tracking tree, do some merges there (such as
backporting a subsystem to a "stable" base kernel), then merge this
backport branch to each platform working copy and cherry-pick other
changes as necessary.
Cheers,
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Junio C Hamano @ 2006-11-15 2:10 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0611142007010.2591@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> "You pull the remote changes with 'git-pull upstream,, then you can
> merge them in your current branch with 'git-merge upstream'."
>
> Isn't it much simpler to understand (and to teach) that way?
If it were "you download the remote changes with 'git download
upstream' and then merge with 'git merge'", then perhaps, but if
you used the word "pull" or "fetch", I do not think so.
I would be all for changing the semantics of "pull" from one
thing to another, if the new semantics were (1) what everybody
welcomed, (2) what "pull" traditionally meant everywhere else.
In that case, we have been misusing it to be confusing to
outsiders and I agree it makes a lot of sense to remove the
source of confusion. But I do not think CVS nor SVN ever used
the term, and I was told that BK was what introduced the term,
and the word meant something different from what you are
proposing.
You have to admit both pull and fetch have been contaminated
with loaded meanings from different backgrounds. I was talking
about killing the source of confusion in the longer term by
removing fetch/pull/push, so we are still on the same page.
That's where my "you download from the upstream and merge" comes
from.
^ permalink raw reply
* Re: git fetch --reference?
From: Junio C Hamano @ 2006-11-15 1:49 UTC (permalink / raw)
To: Michael K. Edwards; +Cc: git
In-Reply-To: <f2b55d220611141717r4507c9demddb1cf872dbee073@mail.gmail.com>
"Michael K. Edwards" <medwards.linux@gmail.com> writes:
> On 11/14/06, Junio C Hamano <junkio@cox.net> wrote:
>> I am somewhat doubtful that this is common enough to warrant
>> adding an extra option to "git fetch", but you could add
>> alternates to these new reference object stores before
>> initiating the fetch.
>> ...
>
> Thanks, that's what I was looking for. I can just set up a "tracking"
> tree where I don't attempt any merges, include it in the alternates
> for each working tree, and "git fetch" in the tracking tree when it's
> convenient. Now, will tags from the tracking tree propagate into the
> working trees?
For the working trees, if you "fetch" from the tracking tree
using short-hand, just like you "fetch" from the origin using
short-hand, tags will be followed, I think.
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Nicolas Pitre @ 2006-11-15 1:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbqn9y6w6.fsf@assigned-by-dhcp.cox.net>
On Tue, 14 Nov 2006, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > On Tue, 14 Nov 2006, Jakub Narebski wrote:
> >
> >> The git interface refactoring should be I think the cause for git 2.0.0
> >> release...
> >
> > Good idea indeed.
>
> We need to avoid user confusion, so making a command that used
> to do one thing to suddenly do something completely different is
> a no-no. However, I do not think it needs to wait for 2.0.0.
> We can start with a separate namespace (or even a separate
> "Improved git UI project") and introduce the "improved UI set"
> in 1.5.0 timeframe.
Dunno. I feel this is a bit overboard. Actually the naming problem is
rather localized to one command, namely git-pull. In my opinion going
with yet another namespace which would rather add to the confusion not
clear it.
The best way to avoid user confusion is to remove the source of the
confusion not let it live. In other words I think we should _fix_
git-pull instead of replacing it. People are already confused about it
so simply fixing this command will have a net confusion reduction. Yet
we're not talking about "suddenly doing something completely different"
either. If git-pull doesn't merge automatically anymore it is easy to
tell people to use git-merge after a pull.
"You pull the remote changes with 'git-pull upstream,, then you can
merge them in your current branch with 'git-merge upstream'."
Isn't it much simpler to understand (and to teach) that way?
Also I don't think using git-upload and git-download is much better.
This adds yet more commands that do almost the same as existing ones but
with a different name which is yet not necessarily fully adequate. I
for example would think that "download" is more like git-clone than
git-fetch or git-pull.
Let's face it: HG got it right with pull and push and newbies have much
less difficulty grokking it. We screwed it by not using the most
intuitive semantic of a pull and locking the word "pull" away is not the
better solution given all considerations. Why just not admit it and
avoid being different than HG just for the sake of it?
^ permalink raw reply
* Re: git fetch --reference?
From: Michael K. Edwards @ 2006-11-15 1:17 UTC (permalink / raw)
To: git
In-Reply-To: <7vy7qdttc0.fsf@assigned-by-dhcp.cox.net>
On 11/14/06, Junio C Hamano <junkio@cox.net> wrote:
> I am somewhat doubtful that this is common enough to warrant
> adding an extra option to "git fetch", but you could add
> alternates to these new reference object stores before
> initiating the fetch.
> ...
Thanks, that's what I was looking for. I can just set up a "tracking"
tree where I don't attempt any merges, include it in the alternates
for each working tree, and "git fetch" in the tracking tree when it's
convenient. Now, will tags from the tracking tree propagate into the
working trees?
Cheers,
^ permalink raw reply
* Re: git fetch --reference?
From: Jakub Narebski @ 2006-11-15 1:04 UTC (permalink / raw)
To: git
In-Reply-To: <f2b55d220611141638k5f4a0aeas1a43301e4b40bf59@mail.gmail.com>
Michael K. Edwards wrote:
> When setting up a working area for kernel integration for a new
> embedded target, I generally do a "git clone --reference" so that the
> new area has its own repository (and its own branch structure) but
> most of the blobs come from a local reference copy. But now that I'm
> integrating bits from several non-trivially divergent trees (mtd-2.6,
> netdev-2.6, linux-2.6.16.y, etc.), it would be nice to avoid
> re-downloading blobs for these additional remote branches, which are
> also available in the local reference copy. Is it feasible to
> implement "git fetch --reference" for this purpose? Or is there a
> better way to manage this sort of integration effort?
All (I think) that --reference does is to create alternates file.
You can simply add another alternate before fetch.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git fetch --reference?
From: Junio C Hamano @ 2006-11-15 1:02 UTC (permalink / raw)
To: Michael K. Edwards; +Cc: git
In-Reply-To: <f2b55d220611141638k5f4a0aeas1a43301e4b40bf59@mail.gmail.com>
"Michael K. Edwards" <medwards.linux@gmail.com> writes:
> When setting up a working area for kernel integration for a new
> embedded target, I generally do a "git clone --reference" so that the
> new area has its own repository (and its own branch structure) but
> most of the blobs come from a local reference copy. But now that I'm
> integrating bits from several non-trivially divergent trees (mtd-2.6,
> netdev-2.6, linux-2.6.16.y, etc.), it would be nice to avoid
> re-downloading blobs for these additional remote branches, which are
> also available in the local reference copy. Is it feasible to
> implement "git fetch --reference" for this purpose? Or is there a
> better way to manage this sort of integration effort?
I am somewhat doubtful that this is common enough to warrant
adding an extra option to "git fetch", but you could add
alternates to these new reference object stores before
initiating the fetch.
For example, if you have pristine linux-2.6/ and your work was
started by cloning with --reference to it into my-2.6/, you
would have something like this:
$ cd /usr/src
$ ls -F
linux-2.6/ linux-2.6.16.y/ netdev-2.6/ my-2.6/
$ cd my-2.6/
$ cat .git/objects/info/alternates
/usr/src/linux-2.6/.git/objects
Then you would (still in my-2.6 repository):
$ cat >>.git/objects/info/alternates
/usr/src/linux-2.6.16.y/.git/objects
/usr/src/netdev-2.6/.git/objects
$ git pull ../netdev-2.6/ ALL
which would hopefully not download _any_ objects but just gets
the ALL branch and makes a merge commit in your working
repository.
^ permalink raw reply
* [PATCH] Make cvsexportcommit work with filenames with spaces and non-ascii characters.
From: Robin Rosenberg @ 2006-11-15 0:55 UTC (permalink / raw)
To: git
From: Robin Rosenberg <robin.rosenberg@dewire.com>
This patch uses git-apply to do the patching which simplifies the code a lot.
Removed the test for checking for matching binary files when deleting them
since git-apply happily deletes the file. This is matter of taste since we
allow some fuzz for text patches also.
Error handling was cleaned up, but not much testd (it did not work before).
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
git-cvsexportcommit.perl | 141 ++++++++++++++++------------------------
t/t9200-git-cvsexportcommit.sh | 79 +++++++++++++++++++---
2 files changed, 124 insertions(+), 96 deletions(-)
diff --git a/git-cvsexportcommit.perl b/git-cvsexportcommit.perl
index 7bac16e..feff681 100755
--- a/git-cvsexportcommit.perl
+++ b/git-cvsexportcommit.perl
@@ -2,9 +2,8 @@ #!/usr/bin/perl -w
# Known limitations:
# - does not propagate permissions
-# - tells "ready for commit" even when things could not be completed
-# (not sure this is true anymore, more testing is needed)
-# - does not handle whitespace in pathnames at all.
+# - error handling has not been extensively tested
+#
use strict;
use Getopt::Std;
@@ -116,12 +115,18 @@ if ($opt_a) {
close MSG;
my (@afiles, @dfiles, @mfiles, @dirs);
-my @files = safe_pipe_capture('git-diff-tree', '-r', $parent, $commit);
-#print @files;
+my $files = safe_pipe_capture_blob('git-diff-tree', '-z', '-r', $parent, $commit);
$? && die "Error in git-diff-tree";
-foreach my $f (@files) {
- chomp $f;
- my @fields = split(m!\s+!, $f);
+while ($files =~ m/(.*?\000.*?\000)/g) {
+ my $f=$1;
+ $f =~ m/^(\S+) (\S+) (\S+) (\S+) (\S+)\000(.*)\000/;
+ my @fields = ();
+ $fields[++$#fields] = $1;
+ $fields[++$#fields] = $2;
+ $fields[++$#fields] = $3;
+ $fields[++$#fields] = $4;
+ $fields[++$#fields] = $5;
+ $fields[++$#fields] = $6;
if ($fields[4] eq 'A') {
my $path = $fields[5];
push @afiles, $path;
@@ -139,12 +144,20 @@ foreach my $f (@files) {
push @dfiles, $fields[5];
}
}
+
my (@binfiles, @abfiles, @dbfiles, @bfiles, @mbfiles);
@binfiles = grep m/^Binary files/, safe_pipe_capture('git-diff-tree', '-p', $parent, $commit);
map { chomp } @binfiles;
@abfiles = grep s/^Binary files \/dev\/null and b\/(.*) differ$/$1/, @binfiles;
@dbfiles = grep s/^Binary files a\/(.*) and \/dev\/null differ$/$1/, @binfiles;
@mbfiles = grep s/^Binary files a\/(.*) and b\/(.*) differ$/$1/, @binfiles;
+push @abfiles, grep s/^Binary files \/dev\/null and "b\/(.*)" differ$/$1/, @binfiles;
+push @dbfiles, grep s/^Binary files "a\/(.*)" and \/dev\/null differ$/$1/, @binfiles;
+push @mbfiles, grep s/^Binary files "a\/(.*)" and \"b\/(.*)\" differ$/$1/, @binfiles;
+map { s/\\([\d]{3})/sprintf('%c',oct $1)/eg; } @abfiles;
+map { s/\\([\d]{3})/sprintf('%c',oct $1)/eg; } @dbfiles;
+map { s/\\([\d]{3})/sprintf('%c',oct $1)/eg; } @mbfiles;
+
push @bfiles, @abfiles;
push @bfiles, @dbfiles;
push @bfiles, @mbfiles;
@@ -152,7 +165,6 @@ push @mfiles, @mbfiles;
$opt_v && print "The commit affects:\n ";
$opt_v && print join ("\n ", @afiles,@mfiles,@dfiles) . "\n\n";
-undef @files; # don't need it anymore
# check that the files are clean and up to date according to cvs
my $dirty;
@@ -195,76 +207,36 @@ if ($dirty) {
}
}
-###
-### NOTE: if you are planning to die() past this point
-### you MUST call cleanupcvs(@files) before die()
-###
-
-
+my $dirtypatch = 0;
print "Creating new directories\n";
foreach my $d (@dirs) {
unless (mkdir $d) {
warn "Could not mkdir $d: $!";
- $dirty = 1;
+ $dirtypatch = 1;
}
- `cvs add $d`;
- if ($?) {
- $dirty = 1;
+ print "Adding directory $d";
+ if (system('cvs','add',$d)) {
+ $dirtypatch = 1;
warn "Failed to cvs add directory $d -- you may need to do it manually";
}
}
-print "'Patching' binary files\n";
-
-foreach my $f (@bfiles) {
- # check that the file in cvs matches the "old" file
- # extract the file to $tmpdir and compare with cmp
- if (not(grep { $_ eq $f } @afiles)) {
- my $tree = safe_pipe_capture('git-rev-parse', "$parent^{tree}");
- chomp $tree;
- my $blob = `git-ls-tree $tree "$f" | cut -f 1 | cut -d ' ' -f 3`;
- chomp $blob;
- `git-cat-file blob $blob > $tmpdir/blob`;
- if (system('cmp', '-s', $f, "$tmpdir/blob")) {
- warn "Binary file $f in CVS does not match parent.\n";
- if (not $opt_f) {
- $dirty = 1;
- next;
- }
- }
- }
- if (not(grep { $_ eq $f } @dfiles)) {
- my $tree = safe_pipe_capture('git-rev-parse', "$commit^{tree}");
- chomp $tree;
- my $blob = `git-ls-tree $tree "$f" | cut -f 1 | cut -d ' ' -f 3`;
- chomp $blob;
- # replace with the new file
- `git-cat-file blob $blob > $f`;
- }
-
- # TODO: something smart with file modes
-
-}
-if ($dirty) {
- cleanupcvs(@files);
- die "Exiting: Binary files in CVS do not match parent";
-}
-
## apply non-binary changes
my $fuzz = $opt_p ? 0 : 2;
-print "Patching non-binary files\n";
+print "Patching\n";
if (scalar(@afiles)+scalar(@dfiles)+scalar(@mfiles) != scalar(@bfiles)) {
- print `(git-diff-tree -p $parent -p $commit | patch -p1 -F $fuzz ) 2>&1`;
-}
-
-my $dirtypatch = 0;
-if (($? >> 8) == 2) {
- cleanupcvs(@files);
- die "Exiting: Patch reported serious trouble -- you will have to apply this patch manually";
-} elsif (($? >> 8) == 1) { # some hunks failed to apply
- $dirtypatch = 1;
+ `git-diff-tree --binary -z -p $parent -p $commit >.cvsexportcommit.diff`;
+ if ($?) {
+ die("cannot diff");
+ }
+ `GIT_DIR= git-apply -z -C$fuzz .cvsexportcommit.diff`;
+ if ($?) {
+ $dirtypatch = 1;
+ } else {
+ $opt_v || unlink(".cvsexportcommit.diff");
+ }
}
foreach my $f (@afiles) {
@@ -274,7 +246,7 @@ foreach my $f (@afiles) {
system('cvs', 'add', $f);
}
if ($?) {
- $dirty = 1;
+ $dirtypatch = 1;
warn "Failed to cvs add $f -- you may need to do it manually";
}
}
@@ -282,19 +254,21 @@ foreach my $f (@afiles) {
foreach my $f (@dfiles) {
system('cvs', 'rm', '-f', $f);
if ($?) {
- $dirty = 1;
+ $dirtypatch = 1;
warn "Failed to cvs rm -f $f -- you may need to do it manually";
}
}
print "Commit to CVS\n";
-print "Patch: $title\n";
-my $commitfiles = join(' ', @afiles, @mfiles, @dfiles);
-my $cmd = "cvs commit -F .msg $commitfiles";
+print "Patch title: $title\n";
+my @commitfiles = map { unless (m/\s/) { '\''.$_.'\''; } else { $_; }; } (@afiles, @mfiles, @dfiles);
+my $cmd = "cvs commit -F .msg @commitfiles";
if ($dirtypatch) {
print "NOTE: One or more hunks failed to apply cleanly.\n";
- print "Resolve the conflicts and then commit using:\n";
+ print "You'll need to apply the patch in .cvsexportcommit.diff manually\n";
+ print "using a patch program. After applying the patch and resolving the\n";
+ print "problems you may commit using:";
print "\n $cmd\n\n";
exit(1);
}
@@ -304,7 +278,6 @@ if ($opt_c) {
print "Autocommit\n $cmd\n";
print safe_pipe_capture('cvs', 'commit', '-F', '.msg', @afiles, @mfiles, @dfiles);
if ($?) {
- cleanupcvs(@files);
die "Exiting: The commit did not succeed";
}
print "Committed successfully to CVS\n";
@@ -318,17 +291,6 @@ END
exit(1);
}
-# ensure cvs is clean before we die
-sub cleanupcvs {
- my @files = @_;
- foreach my $f (@files) {
- system('cvs', '-q', 'update', '-C', $f);
- if ($?) {
- warn "Warning! Failed to cleanup state of $f\n";
- }
- }
-}
-
# An alternative to `command` that allows input to be passed as an array
# to work around shell problems with weird characters in arguments
# if the exec returns non-zero we die
@@ -342,3 +304,16 @@ sub safe_pipe_capture {
}
return wantarray ? @output : join('',@output);
}
+
+sub safe_pipe_capture_blob {
+ my $output;
+ if (my $pid = open my $child, '-|') {
+ local $/;
+ undef $/;
+ $output = (<$child>);
+ close $child or die join(' ',@_).": $! $?";
+ } else {
+ exec(@_) or die "$! $?"; # exec() can fail the executable can't be found
+ }
+ return $output;
+}
diff --git a/t/t9200-git-cvsexportcommit.sh b/t/t9200-git-cvsexportcommit.sh
index 6e566d4..75b9f38 100755
--- a/t/t9200-git-cvsexportcommit.sh
+++ b/t/t9200-git-cvsexportcommit.sh
@@ -89,18 +89,17 @@ test_expect_success \
! git cvsexportcommit -c $id
)'
-# Should fail, but only on the git-cvsexportcommit stage
-test_expect_success \
- 'Fail to remove binary file more than one generation old' \
- 'git reset --hard HEAD^ &&
- cat F/newfile6.png >>D/newfile4.png &&
- git commit -a -m "generation 2 (again)" &&
- rm -f D/newfile4.png &&
- git commit -a -m "generation 3" &&
- id=$(git rev-list --max-count=1 HEAD) &&
- (cd "$CVSWORK" &&
- ! git cvsexportcommit -c $id
- )'
+#test_expect_success \
+# 'Fail to remove binary file more than one generation old' \
+# 'git reset --hard HEAD^ &&
+# cat F/newfile6.png >>D/newfile4.png &&
+# git commit -a -m "generation 2 (again)" &&
+# rm -f D/newfile4.png &&
+# git commit -a -m "generation 3" &&
+# id=$(git rev-list --max-count=1 HEAD) &&
+# (cd "$CVSWORK" &&
+# ! git cvsexportcommit -c $id
+# )'
# We reuse the state from two tests back here
@@ -108,7 +107,7 @@ # This test is here because a patch for
# fail with gnu patch, so cvsexportcommit must handle that.
test_expect_success \
'Remove only binary files' \
- 'git reset --hard HEAD^^^ &&
+ 'git reset --hard HEAD^^ &&
rm -f D/newfile4.png &&
git commit -a -m "test: remove only a binary file" &&
id=$(git rev-list --max-count=1 HEAD) &&
@@ -142,4 +141,58 @@ test_expect_success \
diff F/newfile6.png ../F/newfile6.png
)'
+test_expect_success \
+ 'New file with spaces in file name' \
+ 'mkdir "G g" &&
+ echo ok then >"G g/with spaces.txt" &&
+ git add "G g/with spaces.txt" && \
+ cp ../test9200a.png "G g/with spaces.png" && \
+ git add "G g/with spaces.png" &&
+ git commit -a -m "With spaces" &&
+ id=$(git rev-list --max-count=1 HEAD) &&
+ (cd "$CVSWORK" &&
+ git-cvsexportcommit -c $id &&
+ test "$(echo $(sort "G g/CVS/Entries"|cut -d/ -f2,3,5))" = "with spaces.png/1.1/-kb with spaces.txt/1.1/"
+ )'
+
+test_expect_success \
+ 'Update file with spaces in file name' \
+ 'echo Ok then >>"G g/with spaces.txt" &&
+ cat ../test9200a.png >>"G g/with spaces.png" && \
+ git add "G g/with spaces.png" &&
+ git commit -a -m "Update with spaces" &&
+ id=$(git rev-list --max-count=1 HEAD) &&
+ (cd "$CVSWORK" &&
+ git-cvsexportcommit -c $id
+ test "$(echo $(sort "G g/CVS/Entries"|cut -d/ -f2,3,5))" = "with spaces.png/1.2/-kb with spaces.txt/1.2/"
+ )'
+
+# This test contains ISO-8859-1 characters
+test_expect_success \
+ 'File with non-ascii file name' \
+ 'mkdir Å &&
+ echo Foo >Å/gårdetsågårdet.txt &&
+ git add Å/gårdetsågårdet.txt &&
+ cp ../test9200a.png Å/gårdetsågårdet.png &&
+ git add Å/gårdetsågårdet.png &&
+ git commit -a -m "Går det så går det" && \
+ id=$(git rev-list --max-count=1 HEAD) &&
+ (cd "$CVSWORK" &&
+ git-cvsexportcommit -v -c $id &&
+ test "$(echo $(sort Å/CVS/Entries|cut -d/ -f2,3,5))" = "gårdetsågårdet.png/1.1/-kb gårdetsågårdet.txt/1.1/"
+ )'
+
+test_expect_success \
+ 'Mismatching patch should fail' \
+ 'date >>"E/newfile5.txt" &&
+ git add "E/newfile5.txt" &&
+ git commit -a -m "Update one" &&
+ date >>"E/newfile5.txt" &&
+ git add "E/newfile5.txt" &&
+ git commit -a -m "Update two" &&
+ id=$(git rev-list --max-count=1 HEAD) &&
+ (cd "$CVSWORK" &&
+ ! git-cvsexportcommit -c $id
+ )'
+
^ permalink raw reply related
* git fetch --reference?
From: Michael K. Edwards @ 2006-11-15 0:38 UTC (permalink / raw)
To: git
When setting up a working area for kernel integration for a new
embedded target, I generally do a "git clone --reference" so that the
new area has its own repository (and its own branch structure) but
most of the blobs come from a local reference copy. But now that I'm
integrating bits from several non-trivially divergent trees (mtd-2.6,
netdev-2.6, linux-2.6.16.y, etc.), it would be nice to avoid
re-downloading blobs for these additional remote branches, which are
also available in the local reference copy. Is it feasible to
implement "git fetch --reference" for this purpose? Or is there a
better way to manage this sort of integration effort?
Cheers,
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Junio C Hamano @ 2006-11-15 0:31 UTC (permalink / raw)
To: Carl Worth; +Cc: git, Andy Whitcroft, Petr Baudis
In-Reply-To: <87d57pu4qa.wl%cworth@cworth.org>
Carl Worth <cworth@cworth.org> writes:
> On Tue, 14 Nov 2006 20:47:07 +0100, Petr Baudis wrote:
>> Hmm, did they (not) consider Cogito? They wouldn't have those issues.
>
> I didn't ask.
>
> Frankly, I don't see a lot of value in the git/cogito split right now.
> ...
> It's great that git is written in a script-friendly way so that new
> interfaces can be built on top of it. And I think the benefits of new
> user interfaces are clear when they work in fundamentally different
> ways, (say, being operated through a GUI). But where git and cogito
> are both command-line utilities and have the same basic functionality,
> ...
> There are some things that cogito does that git does not that I would
> like to have in git.
> ...
> I don't see any defining difference that justifies cogito's
> existence ("hide the index" maybe? let's just hide it a tiny bit more
> in git). And I would like to help work to get the remaining good
> stuff that has been proven in cogito---to get it pushed down into git
> itself.
I am of two minds here.
I do not think the Porcelain-ish UI that is shipped with git
should be taken with the same degree of "authority" as git
Plumbing. The plumbing needed to have something that worked for
one particular workflow (namely, workflow of the people in the
integrator role of kernel-style project) and that is where the
current set of Porcelain-ish originates. Linus works primarily
as an integrator so the toolsets he did tend to be more pleasant
to use for integrators and less so for contributors. I started
as a contributor and added some commands like format-patch and
rebase that Linus never would have felt the need for. I think
single isolated developers, contributors and CVS style shared
repository usage could be a lot improved because neither of us
were concentrating in their workflows. This needs somebody
motivated enough to improve things in that area. For example,
StGIT with its 'float' command is a great improvement over what
rebase does for people in the contributor role.
By now, perhaps git may be good enough for the kernel folks,
even for those not in the integrator role, but I have no doubt
that they have many dislikes to the way some commands work.
They and X.org folks are using git primarily because Linus and
Keith forced them to ;-), and being interoperable is more
important than having to tolerate sucky UI here and there.
Everybody knows that git Porcelain-ish sucks, and making it more
usable is a worthy goal.
But making it more usable for whom is a big question.
Quite frankly, I do not think there can be _the_ single UI that
would satisfy different types of workflows for some of the
commands. The commands related to software archaeology, in
which my main interest and strength lie, would easily be usable
across workflows, but commands to build commits locally and
propagate them to and from other repositories would be affected
by the workflow.
For example, fetching and merging from many places without
necessarily having corresponding tracking branches is a great
thing for people in the integrator role. On the other hand, for
people doing CVS-style centralized repository interaction, it is
often more useful to have tracking branches. You could support
both but it has been painful.
For another example, having a commit command to commit
everything by default is disastrous for people who allow their
workflows to often be interrupted. When I respond to a message
from the list with an example patch, my repository is often in
the middle of doing something completely unrelated, and I edit
and make diff to send the message out and I do not necessarily
revert that change afterwards immediately. For more organized
people it may not be a problem so you either support both types
of workflows or do a specialized toolset.
It is not just command line syntax and the defaults, but
concepts as well. People in the integrator role often need to
deal with merges and you would need to be aware of the role of
the index and need to be able to manipulate the index, a lot
more often than people in the contributor role. To satisify
both kinds of workflows, you would either have switches, or do a
specialized toolset, like Cogito, that tries to hide the index.
A Porcelain that does a very similar thing in slightly different
way is obviously a waste, but otherwise I do not think it is a
problem to have different Porcelains. StGIT does not compete
with the "sucky" Porcelain-ish shipped with git but makes the
user's life a lot more pleasant by complementing what the sucky
one does not do well. It is not very useful while I am playing
the integrator role, but when I am doing my own thing it is a
great addition to my toolchest.
I am from the camp that does _not_ want to hide the index, so
obviously I do not see any value in its effort to hide the
index. But other aspects of it, most notably being friendly to
simpler workflows, is a very good thing.
^ permalink raw reply
* Re: [PATCH] gitweb: Make RSS feed output prettier
From: Jakub Narebski @ 2006-11-15 0:24 UTC (permalink / raw)
To: git
In-Reply-To: <11635494363452-git-send-email-asf@boinkor.net>
Andreas Fuchs <asf@boinkor.net> wrote:
> * Wrap the commit message in <pre>
We use <div class="pre"> in "commit" view if I remember correctly.
> * Make file names into an unordered list
Good idea.
> * Add links (diff, conditional blame, history) to the file list.
I'd rather keep RSS output as simple as possible, no frills.
> ---
> gitweb/gitweb.perl | 22 ++++++++++++++++------
> 1 files changed, 16 insertions(+), 6 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index e54a29e..2a79895 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -4134,20 +4134,30 @@ XML
> "<content:encoded>" .
> "<![CDATA[\n";
> my $comment = $co{'comment'};
> + print "<pre>\n";
> foreach my $line (@$comment) {
> - $line = to_utf8($line);
> - print "$line<br/>\n";
> + $line = to_utf8(esc_html($line));
esc_html does to_utf8, so to_utf8 is unnecessary (and spurious).
But it is a good catch: esc_html is certainly needed.
> + print "$line\n";
> }
> - print "<br/>\n";
> + print "</pre><ul>\n";
> foreach my $line (@difftree) {
> if (!($line =~ m/^:([0-7]{6}) ([0-7]{6}) ([0-9a-fA-F]{40}) ([0-9a-fA-F]{40}) (.)([0-9]{0,3})\t(.*)$/)) {
> next;
> }
> - my $file = esc_path(unquote($7));
> + my $file_name = unquote($7);
> + my $file = esc_html($file_name);
We have introduced esc_path for escaping pathnames. Use it!
> + my $parent = $co{'parent'};
> + my $hash = git_get_hash_by_path($commit, $file_name);
> + my $hashparent = git_get_hash_by_path($parent, $file_name);
Two unnecessary calls to git command. Use
my %difftree = parse_difftree_raw_line($line)
instead. The conditions would probably be
next if (!$difftree{'from_id'});
(or equivalent).
> +
> $file = to_utf8($file);
> - print "$file<br/>\n";
> + print "<li>$file ";
> + print "[<a href=\"". esc_html("$my_url?p=$project;a=blobdiff;f=$file;h=$hash;hp=$hashparent;hb=$commit;hpb=$parent") ."\">diff</a>] ";
> + print "[<a href=\"". esc_html("$my_url?p=$project;a=blame;f=$file;hb=$commit") ."\">blame</a>] " if gitweb_check_feature('blame');
> + print "[<a href=\"". esc_html("$my_url?p=$project;a=history;f=$file;h=$commit") ."\">history</a>] ";
> + print "</li>\n";
esc_url, not esc_html here. Or use the href() subroutine with -full=>1
option (after applying the patch I send which added this to href()).
P.S. Please reply also to git mailing list.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] gitweb: Make RSS feed output prettier
From: asf @ 2006-11-15 0:10 UTC (permalink / raw)
To: git; +Cc: Andreas Fuchs
From: Andreas Fuchs <asf@boinkor.net>
* Wrap the commit message in <pre>
* Make file names into an unordered list
* Add links (diff, conditional blame, history) to the file list.
---
gitweb/gitweb.perl | 22 ++++++++++++++++------
1 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index e54a29e..2a79895 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -4134,20 +4134,30 @@ XML
"<content:encoded>" .
"<![CDATA[\n";
my $comment = $co{'comment'};
+ print "<pre>\n";
foreach my $line (@$comment) {
- $line = to_utf8($line);
- print "$line<br/>\n";
+ $line = to_utf8(esc_html($line));
+ print "$line\n";
}
- print "<br/>\n";
+ print "</pre><ul>\n";
foreach my $line (@difftree) {
if (!($line =~ m/^:([0-7]{6}) ([0-7]{6}) ([0-9a-fA-F]{40}) ([0-9a-fA-F]{40}) (.)([0-9]{0,3})\t(.*)$/)) {
next;
}
- my $file = esc_path(unquote($7));
+ my $file_name = unquote($7);
+ my $file = esc_html($file_name);
+ my $parent = $co{'parent'};
+ my $hash = git_get_hash_by_path($commit, $file_name);
+ my $hashparent = git_get_hash_by_path($parent, $file_name);
+
$file = to_utf8($file);
- print "$file<br/>\n";
+ print "<li>$file ";
+ print "[<a href=\"". esc_html("$my_url?p=$project;a=blobdiff;f=$file;h=$hash;hp=$hashparent;hb=$commit;hpb=$parent") ."\">diff</a>] ";
+ print "[<a href=\"". esc_html("$my_url?p=$project;a=blame;f=$file;hb=$commit") ."\">blame</a>] " if gitweb_check_feature('blame');
+ print "[<a href=\"". esc_html("$my_url?p=$project;a=history;f=$file;h=$commit") ."\">history</a>] ";
+ print "</li>\n";
}
- print "]]>\n" .
+ print "</ul>]]>\n" .
"</content:encoded>\n" .
"</item>\n";
}
--
1.4.3.2
^ permalink raw reply related
* Re: [PATCH] commit: Steer new users toward "git commit -a" rather than update-index
From: Junio C Hamano @ 2006-11-14 23:30 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: git, Carl Worth
In-Reply-To: <455A1137.8030301@shadowen.org>
Andy Whitcroft <apw@shadowen.org> writes:
> Are we sure this isn't porcelain-ish? We need to use it in merge
> conflict correction and the like? You can't use git-commit there as a
> replacement. I'd expect it to be 'git update-index' rather than
> 'git-update-index' of course.
I think status should be taken as Porcelain-ish so it should
notice more about the environment to see why the user has
changed but not updated files and recommend the possible action
depending on the context.
For that, you would need to enumerate what kind of 'context'
there could be with the current set of tools. Here is a
strawman.
1. None of the below.
2. A merge was attempted and resulted in a conflict.
3. An am or rebase without --merge was attempted and
resulted in a conflict or patch rejection.
4. A "rebase --merge was attempted and resulted in a conflict.
In the normal case, the next user action would be:
1-1. The user wants that change in the next commit, and should
run "git update-index $that_path" to prepare the index for
partial commit, or "git commit -a" to commit all the
changes made to the working tree so far. Carl's patch
helps the user in this case.
1-2. The user realizes that the some of the changes in the
working tree were not desirable, and "git checkout --
$that_path" to revert them before continuing. Before
deciding to revert, the user may want to check what the
difference is by running "git diff -- $that_path" so
suggesting these two might also be helpful.
1-3. The user wants to keep that change a strictly local change
in the working tree (this is often very useful and making
"commit -a" the default will not be acceptable unless
there is a very compelling reason to do so). This means
the suggestion we would make should clearly be
_suggestion_.
The earlier wording was bad in that it suggested to use a
Plumbing command update-index, but was attempting to convey that
it was merely a conditional suggestion by saying "use it TO MARK
FOR COMMIT", implying that if the user does not want to mark
them for commit, it is Ok not to use update-index.
When a merge is in progress, we would have .git/MERGE_HEAD and
that would be the way to tell case 2. In that case, the next
user action would be:
2-1. The user resolves conflicts and marks them as resolved,
with update-index (or "git mark-resolved"), to prepare the
index for the merge commit. But this is not done for
"Changed but not updated" files but "unmerged" files. We
should strongly suggest not to do _anything_ to "Changed
but not updated" files here.
2-2. The user decides this conflict is too much to handle right
now, and abandones the change by "git reset --hard". This
would lose the local changes ("Changed but not updated"),
so we should suggest to save the change before doing so.
If you are going to abandone this merge with "reset
--hard", your changes to these files will be lost. You
can save them with "git diff HEAD -- $this_path
$that_path..."
which is probably too long for that part of the output but
that is what we would want to say if we want to be
helpful.
When either rebase without --merge or am is in progress, there
would be .dotest/ directory (whose name could be changed but I
think this was a mistake and we would be better off using fixed
names for this kind of application) for git-status to notice.
The next user action would be:
3-1. The user resolves the conflict or manually apply the
patch, update-index the paths involved and proceeds with
"rebase --continue" or "am --resolved". "Changed but not
updated" paths should not be touched in this case,
similarly to 2-1.
3-2. The user gives up. Same as 2-2.
Designing for the "rebase --merge" case and coming up with other
cases are left as exercise to the list for further discussion.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox