* Re: Git-daemon messing up permissions for gitweb
From: Alex Riesen @ 2006-06-10 22:30 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Post, Mark K, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0606101439530.5498@g5.osdl.org>
Linus Torvalds, Sat, Jun 10, 2006 23:41:52 +0200:
> >
> > ~/.ssh/rc
> >
> > AFAIK, it was always there.
>
> Note that since umask is a per-process flag, and only inherited from
> parents to children, not the other way around, if the rc file is run as a
> separate shell script (and I assume it is) instead of "sourced" from the
> the shell that actually executes the programs you run, then this won't
> help at all.
Right, it doesn't. I should have tried ~/.ssh/rc with umask, really.
Because of this it can't be used for environment too (that's why they
have ~/.ssh/environment).
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.4.0
From: Tilman Sauerbeck @ 2006-06-10 22:05 UTC (permalink / raw)
To: git
In-Reply-To: <7vmzckhfsx.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 399 bytes --]
Junio C Hamano [2006-06-10 14:16]:
> git-htmldocs-1.4.0.tar.{gz,bz2} (preformatted documentation)
> git-manpages-1.4.0.tar.{gz,bz2} (preformatted documentation)
Thanks! :)
Regards,
Tilman
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Git-daemon messing up permissions for gitweb
From: Linus Torvalds @ 2006-06-10 21:41 UTC (permalink / raw)
To: Alex Riesen; +Cc: Post, Mark K, Junio C Hamano, git
In-Reply-To: <20060610213051.GB5825@steel.home>
On Sat, 10 Jun 2006, Alex Riesen wrote:
>
> ~/.ssh/rc
>
> AFAIK, it was always there.
Note that since umask is a per-process flag, and only inherited from
parents to children, not the other way around, if the rc file is run as a
separate shell script (and I assume it is) instead of "sourced" from the
the shell that actually executes the programs you run, then this won't
help at all.
Try:
sh -c "umask 0777 ; umask" ; umask
to see in more graphic ("textual") detail what I mean.
Linus
^ permalink raw reply
* Re: Git-daemon messing up permissions for gitweb
From: Alex Riesen @ 2006-06-10 21:30 UTC (permalink / raw)
To: Post, Mark K; +Cc: Linus Torvalds, Junio C Hamano, git
In-Reply-To: <5A14AF34CFF8AD44A44891F7C9FF410507957896@usahm236.amer.corp.eds.com>
Post, Mark K, Fri, Jun 09, 2006 22:52:22 +0200:
> Since umask isn't an environment variable, per se, I'm not sure how this
> will change anything.
$ ssh -V
OpenSSH_4.2p1, OpenSSL 0.9.7i 14 Oct 2005
$ man sshd
~/.ssh/rc
If this file exists, it is run with /bin/sh after reading the
environment files but before starting the user's shell or com-
mand. It must not produce any output on stdout; stderr must be
used instead. If X11 forwarding is in use, it will receive the
"proto cookie" pair in its standard input (and DISPLAY in its
environment). The script must call xauth(1) because sshd will
not run xauth automatically to add X11 cookies.
AFAIK, it was always there.
^ permalink raw reply
* [ANNOUNCE] GIT 1.4.0
From: Junio C Hamano @ 2006-06-10 21:16 UTC (permalink / raw)
To: git; +Cc: linux-kernel
The latest feature release GIT 1.4.0 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.4.0.tar.{gz,bz2} (tarball)
git-htmldocs-1.4.0.tar.{gz,bz2} (preformatted documentation)
git-manpages-1.4.0.tar.{gz,bz2} (preformatted documentation)
RPMS/$arch/git-*-1.4.0-1.$arch.rpm (RPM)
This is a significant update since v1.3.0 (and v1.3.3 which is
the same codebase with bugfixes-only). User visible changes
are:
- Many commands are now coded in C instead of implemented as
shell scripts.
- Checkout is more careful not to clobber untracked files.
- You can "alias" git commands with leading arguments in your
configuration file.
- Documentation set, especially the tutorial, has been reworked.
- Comes with the latest gitk, gitweb, and contributed software.
----------------------------------------------------------------
Changes since v1.3.0 are as follows:
Alex Riesen:
make update-index --chmod work with multiple files and --stdin
remove superflous "const"
Aneesh Kumar K.V:
gitview: Add key binding for F5.
gitview: Move the console error messages to message dialog
gitview: Add some useful keybindings.
Ben Clifford:
include header to define uint32_t, necessary on Mac OS X
Björn Engelmann:
remove the artificial restriction tagsize < 8kb
add more informative error messages to git-mktag
Catalin Marinas:
Add a test-case for git-apply trying to add an ending line
Christian Couder:
Builtin git-rev-parse.
Dennis Stosberg:
Fix git-pack-objects for 64-bit platforms
Fix compilation on newer NetBSD systems
git-write-tree writes garbage on sparc64
git-clean fails on files beginning with a dash
Update documentation for git-format-patch
Dmitry V. Levin:
Separate object name errors from usage errors
execv_git_cmd: Fix stack buffer overflow.
git_exec_path, execv_git_cmd: ignore empty environment variables
Elrond:
git-cvsimport: Handle "Removed" from pserver
Eric W. Biederman:
Implement git-quiltimport
Implement a --dry-run option to git-quiltimport
Make read_one_header_line return a flag not a length.
Move B and Q decoding into check header.
Refactor commit messge handling.
In handle_body only read a line if we don't already have one.
More accurately detect header lines in read_one_header_line
Allow in body headers beyond the in body header prefix.
Eric Wong:
git-svn: documentation updates
git-svn 1.0.0
apply: fix infinite loop with multiple patches with --index
send-email: address expansion for common mailers
Install git-send-email by default
send-email: allow sendmail binary to be used instead of SMTP
send-email: quiet some warnings, reject invalid addresses
Install git-send-email by default
commit: allow --pretty= args to be abbreviated
git-svn: starting a 1.1.0-pre development version
git-svn: ignore expansion of svn:keywords
t3300-funny-names: shell portability fixes
tests: Remove heredoc usage inside quotes
t5500-fetch-pack: remove local (bashism) usage.
t6000lib: workaround a possible dash bug
git-svn: t0001: workaround a heredoc bug in old versions of dash
git-svn: remove assertion that broke with older versions of svn
Florian Forster:
git-svnimport: Improved detection of merges.
Francis Daly:
Some doc typo fixes
config.txt grammar, typo, and asciidoc fixes
git-cvsserver asciidoc formatting tweaks
Fredrik Kuivinen:
blame: Fix path pruning
Update the documentation for git-merge-base
Horst H. von Brand:
Documentation: Spelling fixes
Cleanup git-send-email.perl:extract_valid_email
Add example xinetd(8) configuration to Documentation/everyday.txt
Fix Documentation/everyday.txt: Junio's workflow
Fix formatting of Documentation/git-clone.txt
Horst von Brand:
Fix some documentation typoes
Huw Davies:
git-format-patch: Use rfc2822 compliant date.
J. Bruce Fields:
tutorial: replace "whatchanged" by "log"
tutorial: expanded discussion of commit history
tutorial: add discussion of index file, object database
documentation: mention gitk font adjustment in tutorial
documentation: add brief mention of cat-file to tutorial part I
Documentation: retitle the git-core tutorial
Documentation: fix a tutorial-2 typo
Jeff King:
cvsimport: use git-update-index --index-info
cvsimport: cleanup commit function
cvsimport: set up commit environment in perl instead of using env
cat-file: document -p option
cvsimport: avoid "use" with :tag
handle concurrent pruning of packed objects
sha1_file: avoid re-preparing duplicate packs
Jim Meyering:
Don't write directly to a make target ($@).
Johannes Schindelin:
builtin-push: resurrect parsing of Push: lines
cache-tree: replace a sscanf() by two strtol() calls
builtin-push: also ask config for remote information
fetch, pull: ask config for remote information
repo-config: fix segfault with no argument.
repo-config: trim white-space before comment
repo-config: support --get-regexp
repo-config: deconvolute logics
fetch, pull: ask config for remote information
Add a conversion tool to migrate remote information into the config
builtin-push: --all and --tags _are_ explicit refspecs
Teach fmt-patch to write individual files.
fmt-patch: output file names to stdout
fmt-patch: implement -o <dir>
Teach fmt-patch about --numbered
Teach fmt-patch about --keep-subject
repo-config: trim white-space before comment
fmt-patch: understand old <his> notation
Fix users of prefix_path() to free() only when necessary
Fix users of prefix_path() to free() only when necessary
Fix crash when reading the empty tree
diff family: add --check option
fmt-patch: Support --attach
git-format-patch --start-number <n>
send-email: only 'require' instead of 'use' Net::SMTP
format-patch: resurrect extra headers from config
If you have a config containing something like this:
Jon Loeliger:
Alphabetize the glossary.
Added definitions for a few words:
Add a few more words to the glossary.
Refactor git_tcp_connect() functions a little.
Jonas Fonseca:
Fix filename scaling for binary files
Misc doc improvements
Document git-ls-tree --fullname
Josef Weidendorfer:
gitk: Add a visual tag for remote refs
Junio C Hamano:
Fix up default abbrev in setup_revisions() argument parser.
Fix up rev-list option parsing.
Split init_revisions() out of setup_revisions()
rev-list option parser fix.
Built-in git-whatchanged.
Do not fork PAGER=cat
Simplify common default options setup for built-in log family.
log/whatchanged/show - log formatting cleanup.
rev-list --header: output format fix
git.c: LOGSIZE is unused after log printing cleanup.
combine-diff: show diffstat with the first parent.
Fix "git log --stat": make sure to set recursive with --stat.
Tentative built-in format-patch.
sha1_name.c: prepare to make get_tree_entry() reusable from others.
sha1_name.c: no need to include diff.h; tree-walk.h will do.
get_tree_entry(): make it available from tree-walk
Minor tweak on subject line in --pretty=email
git-merge: a bit more readable user guidance.
pre-commit hook: complain about conflict markers.
diff: move diff.c to diff-lib.c to make room.
Add git-unresolve <paths>...
diff --stat: do not drop rename information.
git-update-index --unresolve
git-commit --amend: two fixes.
rename internal format-patch wip
pack-objects: do not stop at object that is "too small"
mailinfo: decode underscore used in "Q" encoding properly.
Makefile: dependency for builtin-help.o
Add colordiff for git to contrib/colordiff.
Fix "git show --stat"
Libify diff-files.
Libify diff-index.
git-fmt-patch: thinkofix to show properly.
Libified diff-index: backward compatibility fix.
read-cache/write-cache: optionally return cache checksum SHA1.
Add cache-tree.
Update write-tree to use cache-tree.
Invalidate cache-tree entries for touched paths in git-apply.
Use cache-tree in update-index.
Add test-dump-cache-tree
cache-tree: protect against "git prune".
index: make the index file format extensible.
Teach fsck-objects about cache-tree.
cache-tree: sort the subtree entries.
test-dump-cache-tree: report number of subtrees.
Makefile: remove and create libgit.a from scratch.
diff --stat: show complete rewrites consistently.
git-cvsserver: typofixes
t0000-basic: Add ls-tree recursive test back.
Makefile: remove and create xdiff library from scratch.
commit-tree: allow generic object name for the tree as well.
rebase: typofix.
commit-tree.c: check_valid() microoptimization.
revision parsing: make "rev -- paths" checks stronger.
t0000-basic: more commit-tree tests.
update-index: when --unresolve, smudge the relevant cache-tree entries.
read-tree: teach 1 and 2 way merges about cache-tree.
read-tree: teach 1-way merege and plain read to prime cache-tree.
diff-index: fix compilation warnings.
verify-pack: check integrity in a saner order.
cache_tree_update: give an option to update cache-tree only.
test-dump-cache-tree: validate the cached data as well.
pack-objects: update size heuristucs.
built-in count-objects.
cache-tree.c: typefix
git-am --resolved: more usable error message.
built-in diff.
built-in diff: assorted updates.
builtin-diff.c: die() formatting type fix.
Fix builtin-push to honor Push: lines in remotes file.
Extended SHA1 -- "rev^@" syntax to mean "all parents"
get_sha1(): :path and :[0-3]:path to extract from index.
built-in "git grep"
Use RFC2822 dates from "git fmt-patch".
builtin-grep: wildcard pathspec fixes
builtin-grep: support '-l' option.
builtin-grep: do not use setup_revisions()
fsck-objects: mark objects reachable from cache-tree
builtin-count-objects: make it official.
builtin-diff: call it "git-diff", really.
builtin-log/whatchanged/show: make them official.
show-branch: omit uninteresting merges.
builtin-push: make it official.
builtin-grep: printf %.*s length is int, not ptrdiff_t.
Revert "fetch, pull: ask config for remote information"
builtin-grep: allow -<n> and -[ABC]<n> notation for context lines.
builtin-grep: allow more than one patterns.
builtin-grep: support -c (--count).
builtin-grep: support -w (--word-regexp).
builtin-grep: tighten path wildcard vs tree traversal.
core.prefersymlinkrefs: use symlinks for .git/HEAD
repo-config: readability fixups.
builtin-count-objects: open packs when running -v
Fix test-dump-cache-tree in one-tree disappeared case.
read-tree: invalidate cache-tree entry when a new index entry is added.
cache-tree: a bit more debugging support.
builtin-grep: terminate correctly at EOF
builtin-grep: binary files -a and -I
fsck-objects: do not segfault on missing tree in cache-tree
builtin-grep: -L (--files-without-match).
Makefile: do not link rev-list any specially.
delta: stricter constness
core.prefersymlinkrefs: use symlinks for .git/HEAD
pack-object: squelch eye-candy on non-tty
binary patch.
binary diff: further updates.
update-index --unresolve: work from a subdirectory.
checkout-index: plug memory leak from prefix_path()
update-index: plug memory leak from prefix_path()
update-index --again
update-index --again: take optional pathspecs
binary diff and apply: testsuite.
repo-config: document what value_regexp does a bit more clearly.
Fix repo-config set-multivar error return path.
Teach -f <file> option to builtin-grep.
builtin-grep: documentation
Documentation: {caret} fixes (git-rev-list.txt)
get_sha1() - fix infinite loop on nonexistent stage.
Teach git-clean optional <paths>... parameters.
builtin-grep: tighten argument parsing.
builtin-grep: typofix
builtin-grep: -w fix
builtin-grep: -F (--fixed-strings)
checkout: use --aggressive when running a 3-way merge (-m).
checkout: use --aggressive when running a 3-way merge (-m).
diffstat rename squashing fix.
read-tree -u one-way merge fix to check out locally modified paths.
apply --numstat: show new name, not old name.
Fix pack-index issue on 64-bit platforms a bit more portably.
builtin-grep: unparse more command line options.
apply --cached: apply a patch without using working tree.
git-am: use apply --cached
builtin-diff: fix comparison between two blobs.
merge-base: Clarify the comments on post processing.
read-tree -m -u: do not overwrite or remove untracked working tree files.
builtin-grep: workaround for non GNU grep.
Revert "builtin-grep: workaround for non GNU grep."
apply --cached: do not check newly added file in the working tree
builtin-add: fix unmatched pathspec warnings.
builtin-diff: do not say files are renamed when blob and file are given
Fix build procedure for builtin-init-db
built-in tar-tree and remote tar-tree
git-format-patch: now built-in.
checkdiff_consume: strtol parameter fix.
git-rebase: use canonical A..B syntax to format-patch
tutorial-2: typofix in examples.
mailinfo: skip bogus UNIX From line inside body
CMIT_FMT_EMAIL: Q-encode Subject: and display-name part of From: fields.
builtin format-patch: squelch content-type for 7-bit ASCII
diff: minor option combination fix.
fetch-pack: output refs in the order they were given on the command line.
Tutorial #2: broken link fix.
builtin-rm: squelch compiler warnings.
cvsimport: do not barf on creation of an empty file.
apply: force matching at the beginning.
fetch.c: remove an unused variable and dead code.
ls-remote: fix rsync:// to report HEAD
mailinfo: More carefully parse header lines in read_one_header_line()
gitk: start-up bugfix
built-in format-patch: various fixups.
format-patch: -n and -k are mutually exclusive.
Let git-clone to pass --template=dir option to git-init-db.
git-fetch: avoid using "case ... in (arm)"
adjust to the rebased series by Linus.
send-email: do not pass bogus address to local sendmail binary
format-patch --signoff
fetch.c: do not pass uninitialized lock to unlock_ref().
fetch.c: do not call process_tree() from process_tree().
fetch: do not report "same" unless -verbose.
read-tree --reset: update working tree file for conflicted paths.
git alias: try alias last.
rev-parse: tighten constness properly.
send-email: be more lenient and just catch obvious mistakes.
send-email: a bit more careful domain regexp.
git-format-patch: add --output-directory long option again
HTTP cleanup
Make index file locking code reusable to others.
refs.c: convert it to use lockfile interface.
ref-log: style fixes.
Documentation: add missing docs make check-docs found.
make clean: remove dist-doc targets.
Documentation: git-ls-tree (typofix)
Documentation: add another example to git-ls-files
git-clone: fix duplicated "master" in $GIT_DIR/remotes/origin
git-rm: honor -n flag.
builtin-init-db: spell the in-program configuration variable in lowercase.
shared repository - add a few missing calls to adjust_shared_perm().
git-clone: fix --bare over dumb-http
GIT 1.4.0
Linus Torvalds:
Common option parsing for "git log --diff" and friends
Tentative built-in "git show"
Fixes for option parsing
Log message printout cleanups
Log message printout cleanups (#2)
Log message printout cleanups (#3): fix --pretty=oneline
Fix uninteresting tags in new revision parsing
get_sha1() shorthands for blob/tree objects
Allow "git repack" users to specify repacking window/depth
git log: don't do merge diffs by default
git-log produces no output
Split up builtin commands into separate files from git.c
Fix filename verification when in a subdirectory
Fix "git help -a" terminal autosizing
git builtin "push"
Fix "git-log --parents" breakage post v1.3.0
sha1_to_hex() usage cleanup
Fix "git diff --stat" with long filenames
revert/cherry-pick: use aggressive merge.
git config syntax updates
git diff: support "-U" and "--unified" options properly
Allow one-way tree merge to remove old files
Simplify "git reset --hard"
builtin-grep: use external grep when we can take advantage of it
read-tree --reset -u fix.
Fix silly typo in new builtin grep
Remove old "git-grep.sh" remnants
libify git-ls-files directory traversal
Clean up git-ls-file directory walking library interface
Do "git add" as a builtin
builtin-add: warn on unmatched pathspecs
builtin-grep: workaround for non GNU grep.
Remove old "git-add.sh" remnants
Prevent bogus paths from being added to the index.
Make "git rev-list" be a builtin
Libify the index refresh logic
Move pathspec matching from builtin-add.c into dir.c
Add builtin "git rm" command
cvsimport: repack every kilo-commits.
apply: treat EOF as proper context.
Clean up sha1 file writing
bogus "fatal: Not a git repository"
t1002: use -U0 instead of --unified=0
Fix "--abbrev=xyz" for revision listing
Fix memory leak in "git rev-list --objects"
Don't use "sscanf()" for tree mode scanning
Add raw tree buffer info to "struct tree"
Make "tree_entry" have a SHA1 instead of a union of object pointers
Switch "read_tree_recursive()" over to tree-walk functionality
Remove "tree->entries" tree-entry list from tree parser
Make "struct tree" contain the pointer to the tree buffer
Make "tree_entry" have a SHA1 instead of a union of object pointers
Switch "read_tree_recursive()" over to tree-walk functionality
builtin-read-tree.c: avoid tree_entry_list in prime_cache_tree_rec()
Remove "tree->entries" tree-entry list from tree parser
fsck-objects: avoid unnecessary tree_entry_list usage
Remove unused "zeropad" entry from tree_list_entry
Convert "mark_tree_uninteresting()" to raw tree walker
Convert fetch.c: process_tree() to raw tree walker
Remove last vestiges of generic tree_entry_list
tree_entry(): new tree-walking helper function
read-tree: fix eye-candy.
Fix typo in tutorial-2.txt
rev-list: fix process_tree() conversion.
pack-objects: improve path grouping heuristics.
Lukas Sandström:
Make git-check-format-ref a builtin.
SubmittingPatches: The download location of External Editor has moved
Martin Langhoff:
git-cvsexportcommit: Add -f(orce) and -m(essage prefix) flags, small cleanups.
git-send-email: fix version string to be valid perl
cvsserver: use git-rev-list instead of git-log
cvsserver: use git-rev-list instead of git-log
cvsimport: minor fixups
cvsimport: replace anonymous sub ref with a normal sub
cvsimport: introduce -L<imit> option to workaround memory leaks
cvsimport: introduce _fetchfile() method and used a 1M buffer to read()
Martin Waitz:
clone: keep --reference even with -l -s
repack: honor -d even when no new pack was created
Transitively read alternatives
test case for transitive info/alternates
clone: don't clone the info/alternates file
git help: remove whatchanged from list of common commands
Documentation/Makefile: remove extra /
Add instructions to commit template.
Martyn Smith:
Added logged warnings for CVS error returns
Many fixes for most operations in Eclipse.
Change to allow subdir updates from Eclipse
Matthias Kestenholz:
annotate: fix warning about uninitialized scalar
annotate: display usage information if no filename was given
fix various typos in documentation
add documentation for update-index --unresolve
Matthias Lederhofer:
core-tutorial.txt: escape asterisk
git status: skip empty directories, and add -u to show all untracked files
Nick Hengeveld:
git-fetch: resolve remote symrefs for HTTP transport
http: prevent segfault during curl handle reuse
builtin-push: don't pass --thin to HTTP transport
HTTP cleanup
http-fetch: fix possible segfault
Nicolas Pitre:
fix pack-object buffer size
split the diff-delta interface
use delta index data when finding best delta matches
replace adler32 with Rabin's polynomial in diff-delta
tiny optimization to diff-delta
improve diff-delta with sparse and/or repetitive data
improve base85 generated assembly code
fix diff-delta bad memory access
simple euristic for further free packing improvements
pack-object: slightly more efficient
improve depth heuristic for maximum delta size
Paul Mackerras:
gitk: Implement multiple views
gitk: Make File->Update work properly again
gitk: Fix various bugs in the view support
gitk: Don't reread git-rev-list output from scratch on view switch
gitk: Remember the view in the history list
gitk: Let git-rev-list do the argument list parsing
gitk: Use git-rev-parse only to identify file/dir names on cmd line
rev-parse: better error message for ambiguous arguments
gitk: Implement "permanent" views (stored in ~/.gitk)
gitk: add menu item for editing the current view
gitk: Use a text widget for the file list
gitk: Add a tree-browsing mode
gitk: Basic support for highlighting one view within another
gitk: Fix file list display when files are renamed
gitk: Allow view to specify arbitrary arguments to git-rev-list
gitk: Fix display of "(...)" for parents/children we haven't drawn
Provide a way to flush git-diff-tree's output
gitk: Make a row of controls for controlling highlighting
gitk: Fix bug where page-up/down wouldn't always work properly
gitk: Highlight entries in the file list as well
gitk: Highlight paths of interest in tree view as well
gitk: First cut at a search function in the patch/file display window
gitk: Improve the text window search function
gitk: Move "pickaxe" find function to highlight facility
gitk: Fix bug in highlight stuff when no line is selected
gitk: show_error fix
gitk: Provide ability to highlight based on relationship to selected commit
Make git-diff-tree indicate when it flushes
gitk: Add a goto next/previous highlighted commit function
gitk: Show nearby tags
gitk: Show branch name(s) as well, if "show nearby tags" is enabled
gitk: Re-read the descendent/ancestor tag & head info on update
Paul T Darga:
check for error return from fork()
Pavel Roskin:
Release config lock if the regex is invalid
Peter Eriksen:
Add git-quiltimport to .gitignore.
Builtin git-ls-files.
Builtin git-ls-tree.
Builtin git-tar-tree.
Builtin git-read-tree.
Builtin git-commit-tree.
Builtin git-apply.
Builtin git-show-branch.
Builtin git-diff-files, git-diff-index, git-diff-stages, and git-diff-tree.
Peter Hagervall:
Sparse fix for builtin-diff
Petr Baudis:
Document git-var -l listing also configuration variables
Document the configuration file
git-repo-config --list support
Deprecate usage of git-var -l for getting config vars list
Call builtin ls-tree in git-cat-file -p
Document git aliases support
Documentation: git aliases
Rene Scharfe:
Off-by-one error in get_path_prefix(), found by Valgrind
Built-in git-get-tar-commit-id
Robert Fitzsimons:
builtin-grep: pass ignore case option to external grep
Robert Shearman:
Give the user a hint for how to continue in the case that git-am fails because it requires user intervention
Ryan Anderson:
git-send-email: Add References: headers to emails, in addition to In-Reply-To:
Add support for --bcc to git-send-email.
Fix a bug in email extraction used in git-send-email.
Add a basic test case for git send-email, and fix some real bugs discovered.
Salikh Zakirov:
Fixed Cygwin CR-munging problem in mailsplit
Santi:
Document that "git add" only adds non-ignored files.
Santi_Béjar:
Reintroduce svn pools to solve the memory leak.
Sean Estabrooks:
Add --continue and --abort options to git-rebase.
Update the git-branch man page to include the "-r" option,
Fix up remaining man pages that use asciidoc "callouts".
Properly render asciidoc "callouts" in git man pages.
Fix trivial typo in git-log man page.
Several trivial documentation touch ups.
Fix up docs where "--" isn't displayed correctly.
Update git-unpack-objects documentation.
Clarify git-cherry documentation.
Fix for config file section parsing.
Another config file parsing fix.
t1300-repo-config: two new config parsing tests.
Another config file parsing fix.
Add "--branches", "--tags" and "--remotes" options to git-rev-parse.
Ensure author & committer before asking for commit message.
Make git rebase interactive help match documentation.
Add "--summary" option to git diff.
Convert some "apply --summary" users to "diff --summary".
Strip useless "tags/" prefix from git-tag -l output
Allow pickaxe and diff-filter options to be used by git log.
Avoid segfault in diff --stat rename output.
Change GIT-VERSION-GEN to call git commands with "git" not "git-".
Install git builtins into gitexecdir rather than bindir.
Remove possible segfault in http-fetch.
--summary output should print immediately after stats.
A Perforce importer for git.
Serge E. Hallyn:
socksetup: don't return on set_reuse_addr() error
socksetup: don't return on set_reuse_addr() error
Sergey Vlasov:
gitk: Display commit messages with word wrap
Shawn Pearce:
Document git-clone --reference
Remove unnecessary local in get_ref_sha1.
Improve abstraction of ref lock/write.
Convert update-ref to use ref_lock API.
Log ref updates to logs/refs/<ref>
Support 'master@2 hours ago' syntax
Fix ref log parsing so it works properly.
General ref log reading improvements.
Added logs/ directory to repository layout.
Force writing ref if it doesn't exist.
Log ref updates made by fetch.
Change 'master@noon' syntax to 'master@{noon}'.
Correct force_write bug in refs.c
Change order of -m option to update-ref.
Include ref log detail in commit, reset, etc.
Create/delete branch ref logs.
Enable ref log creation in git checkout -b.
Reference git-check-ref-format in git-branch.
Elaborate on why ':' is a bad idea in a ref name.
Built git-upload-tar should be ignored.
Verify git-commit provides a reflog message.
Test that git-branch -l works.
Remove unnecessary output from t3600-rm.
Improved pack format documentation.
Allow multiple -m options to git-commit.
Tilman Sauerbeck:
Documentation/Makefile: create tarballs for the man pages and html files
Timo Hirvonen:
Builtin git-init-db
Builtin git-cat-file
gitk: Replace "git-" commands with "git "
Uwe Zeisberger:
Document git-clone --use-separate-remote
Yakov Lerner:
read-cache.c: use xcalloc() not calloc()
NO_INET_NTOP and compat/inet_ntop.c for some systems (e.g. old Cygwin).
Problem: 'trap...exit' causes error message when /bin/sh is ash.
Yann Dirson:
Do not call 'cmp' with non-existant -q flag.
Document current cvsexportcommit limitations.
Make cvsexportcommit create parent directories as needed.
^ permalink raw reply
* Re: gitk on Windows: layout problem
From: Christopher Faylor @ 2006-06-10 20:34 UTC (permalink / raw)
To: git
In-Reply-To: <20060610111321.GA6790@nospam.com>
On Sat, Jun 10, 2006 at 01:13:21PM +0200, Rutger Nijlunsing wrote:
>On Sat, Jun 03, 2006 at 07:43:38PM +1000, Paul Mackerras wrote:
>> Rutger Nijlunsing writes:
>>>Is this a known problem? gitk-du-jour on Windows starts up with an
>>>unusable layout. Screenshot attached.
>>
>>Is that using Tk with the cygwin X server, or the native Windows Tk
>>port?
>
>I installed the default cygwin version but I don't have to start an X
>server for it. So while it's not the native Windows Tk port, it also
>doesn't seem to be the X-server version.
Cygwin's Tk is pretty close to a pure windows version. It doesn't even
understand cygwin path names. Its main purpose is to support the
insight debugger and it does not require an X-server to run.
^ permalink raw reply
* Re: [PATCH] Ignore commits for which cvsps can't identify a branch
From: Christian Biesinger @ 2006-06-10 19:45 UTC (permalink / raw)
To: Yann Dirson; +Cc: GIT list
In-Reply-To: <20060610192457.GA6620@nowhere.earth>
Yann Dirson wrote:
> I have seen such CVSPS_NO_BRANCH things with "cvsps -u", and could
> always get rid of it using "cvspx -x". Christian, did you try to run
> "cvsps -x" to be sure the cache is valid, and did it get rid of the
> CVSPS_NO_BRANCH ? It could help if you could make a cvsps cache
> available, which exhibits the problem.
I'm pretty sure that I did use -x and didn't have a cache. Unfortunately
I don't have anything about that cvsps setup available anymore.
^ permalink raw reply
* Re: [PATCH] Ignore commits for which cvsps can't identify a branch
From: Yann Dirson @ 2006-06-10 19:24 UTC (permalink / raw)
To: Christian Biesinger; +Cc: GIT list
In-Reply-To: <200602102102.k1AL2Xkd010415@biesi.no-ip.org>
On Fri, Feb 10, 2006 at 10:02:33PM +0100, Christian Biesinger wrote:
> cvps sometimes can't identify a branch for a specific revision, it shows
> messages like:
> WARNING: revision 1.36.2.2 of file Makefile.in on unnamed branch
> and uses #CVSPS_NO_BRANCH as branch name in its output.
This issue is a bit old, but still...
I have seen such CVSPS_NO_BRANCH things with "cvsps -u", and could
always get rid of it using "cvspx -x". Christian, did you try to run
"cvsps -x" to be sure the cache is valid, and did it get rid of the
CVSPS_NO_BRANCH ? It could help if you could make a cvsps cache
available, which exhibits the problem.
Best regards,
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* Re: Figured out how to get Mozilla into git
From: Lars Johannsen @ 2006-06-10 18:55 UTC (permalink / raw)
To: Jon Smirl; +Cc: git
In-Reply-To: <9e4733910606100844v5f4765d8o85c9a6f239faed43@mail.gmail.com>
On (10/06/06 11:44), Jon Smirl wrote:
> Date: Sat, 10 Jun 2006 11:44:58 -0400
> From: "Jon Smirl" <jonsmirl@gmail.com>
> To: "Junio C Hamano" <junkio@cox.net>
> Subject: Re: Figured out how to get Mozilla into git
> Cc: git@vger.kernel.org
>
> On 6/10/06, Junio C Hamano <junkio@cox.net> wrote:
> >"Jon Smirl" <jonsmirl@gmail.com> writes:
> >
> >> Here's a new transport problem. When using git-clone to fetch Martin's
> >> tree it kept failing for me at dreamhost. I had a parallel fetch
> >> running on my local machine which has a much slower net connection. It
> >> finally finished and I am watching the end phase where it prints all
> >> of the 'walk' messages. The git-http-fetch process has jumped up to
> >> 800MB in size after being 2MB during the download. dreamhost has a
> >> 500MB process size limit so that is why my fetches kept failing there.
> >
> >The http-fetch process uses by mmaping the downloaded pack, and
> >if I recall correctly we are talking about 600MB pack, so 500MB
> >limit sounds impossible, perhaps?
>
> The fetch on my local machine failed too. It left nothing behind, now
> I have to download the 680MB again.
>
> walk 1f19465388a4ef7aff7527a13f16122a809487d4
> walk c3ca840256e3767d08c649f8d2761a1a887351ab
> walk 7a74e42699320c02b814b88beadb1ae65009e745
> error: Couldn't get
> http://mirrors.catalyst.net.nz/pub/mozilla.git//refs/tags/JS%5F1%5F7%5FALPHA%5FBASE
> for tags/JS_1_7_ALPHA_BASE
> Couldn't resolve host 'mirrors.catalyst.net.nz'
> error: Could not interpret tags/JS_1_7_ALPHA_BASE as something to pull
> [jonsmirl@jonsmirl mozgit]$ cg update
> There is no GIT repository here (.git not found)
> [jonsmirl@jonsmirl mozgit]$ ls -a
> . ..
> [jonsmirl@jonsmirl mozgit]$
To prevent repeat (on this repo) your could grab it with a browser:
-mkdir tmp; cd tmp; git init-db;
-copy mirror../pu/mozilla.git/objects/* to .git/objects/
-copy --||---.git/info/refs to refsinfo in tmp-dir
gawk '{if ($2 !~ /\^\{\}$/) print $1 > sprintf(".git/%s",$2);}' refsinfo
to extract branches and tags into ./git/refs/{heads,tags}
start playing (after a backup) with git-fsck-objects, git-checkout etc.
--
Lars Johannsen
mail@Lars-johannsen.dk
^ permalink raw reply
* Re: Figured out how to get Mozilla into git
From: Petr Baudis @ 2006-06-10 18:37 UTC (permalink / raw)
To: Jon Smirl; +Cc: Junio C Hamano, git
In-Reply-To: <9e4733910606100844v5f4765d8o85c9a6f239faed43@mail.gmail.com>
Dear diary, on Sat, Jun 10, 2006 at 05:44:58PM CEST, I got a letter
where Jon Smirl <jonsmirl@gmail.com> said that...
> The fetch on my local machine failed too. It left nothing behind, now
> I have to download the 680MB again.
>
> walk 1f19465388a4ef7aff7527a13f16122a809487d4
> walk c3ca840256e3767d08c649f8d2761a1a887351ab
> walk 7a74e42699320c02b814b88beadb1ae65009e745
> error: Couldn't get
> http://mirrors.catalyst.net.nz/pub/mozilla.git//refs/tags/JS%5F1%5F7%5FALPHA%5FBASE
> for tags/JS_1_7_ALPHA_BASE
> Couldn't resolve host 'mirrors.catalyst.net.nz'
> error: Could not interpret tags/JS_1_7_ALPHA_BASE as something to pull
> [jonsmirl@jonsmirl mozgit]$ cg update
> There is no GIT repository here (.git not found)
> [jonsmirl@jonsmirl mozgit]$ ls -a
> . ..
> [jonsmirl@jonsmirl mozgit]$
You could try with cg-clone, which won't delete the repository if
things fail. It will clone only the master branch, though.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply
* Re: Figured out how to get Mozilla into git
From: Rogan Dawes @ 2006-06-10 18:36 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jon Smirl, Martin Langhoff, git
In-Reply-To: <Pine.LNX.4.64.0606101041490.5498@g5.osdl.org>
Linus Torvalds wrote:
>
> On Sat, 10 Jun 2006, Rogan Dawes wrote:
>> Here's an idea. How about separating trees and commits from the actual blobs
>> (e.g. in separate packs)? My reasoning is that the commits and trees should
>> only be a small portion of the overall repository size, and should not be that
>> expensive to transfer. (Of course, this is only a guess, and needs some
>> numbers to back it up.)
>
> The trees in particular are actually a pretty big part of the history.
>
> More importantly, the blobs compress horribly badly in the absense of
> history - a _lot_ of the compression in git packing comes very much from
> the fact that we do a good job at delta-compression.
>
> So if you get all of the commit/tree history, but none of the blob
> history, you're actually not going to win that much space. As already
> discussed, the _whole_ history packed with git is usually not insanely
> bigger than just the whole unpacked tree (with no history at all).
>
> So you'd think that getting just the top version of the tree would be a
> much bigger space-saving that it actually is. If you _also_ get all the
> tree and commit objects, the space saving is even less.
>
One possibility, given that the full commit and tree history is so
large, is simply to get the HEAD commit and the trees that the commit
depends directly on, rather than fetching them all up front.
> I actually suspect that the most realistic way to handle this is to use
> the "fetch.c" logic (ie the incremental fetcher used by http), and add
> some mode to the git daemon where you fetch literally one object at a time
> (ie this would be totally _separate_ from the pack-file thing: you'd not
> ask for "git-upload-pack", you'd ask for something like
> "git-serve-objects" instead).
>
> The fetch.c logic really does allow for on-demand object fetching, and is
> thus much more suitable for incomplete repositories.
>
> HOWEVER. The fetch.c logic - by necessity - works on a object-by-object
> level. That means that you'd get no delta compression AT ALL, and I
> suspect that the downside of that would be a factor of ten expansion or
> more, which means that it would really not work that well in practice.
Would it be possible to add a mode where fetch.c is given a list of
desired objects, and returns a list of pointers to those objects? Then
callers that already have such a list could be modified to pass the
whole list at once, allowing at least SOME compression, and optimisation
of round trips, etc? There would be a tradeoff in memory use, though, I
guess.
Rogan
^ permalink raw reply
* Re: Figured out how to get Mozilla into git
From: Jon Smirl @ 2006-06-10 18:02 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Rogan Dawes, Martin Langhoff, git
In-Reply-To: <Pine.LNX.4.64.0606101041490.5498@g5.osdl.org>
Here's a random idea, how about a tool that turns a real pack into one
that is segmented and then faults in segments if you do an operation
that needs the old segments? The full pack would always look like it
is there even if it isn't. Something like gitk would be modified not
to fault in the missing segments.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Figured out how to get Mozilla into git
From: Linus Torvalds @ 2006-06-10 17:53 UTC (permalink / raw)
To: Rogan Dawes; +Cc: Jon Smirl, Martin Langhoff, git
In-Reply-To: <448A847C.20105@dawes.za.net>
On Sat, 10 Jun 2006, Rogan Dawes wrote:
>
> Here's an idea. How about separating trees and commits from the actual blobs
> (e.g. in separate packs)? My reasoning is that the commits and trees should
> only be a small portion of the overall repository size, and should not be that
> expensive to transfer. (Of course, this is only a guess, and needs some
> numbers to back it up.)
The trees in particular are actually a pretty big part of the history.
More importantly, the blobs compress horribly badly in the absense of
history - a _lot_ of the compression in git packing comes very much from
the fact that we do a good job at delta-compression.
So if you get all of the commit/tree history, but none of the blob
history, you're actually not going to win that much space. As already
discussed, the _whole_ history packed with git is usually not insanely
bigger than just the whole unpacked tree (with no history at all).
So you'd think that getting just the top version of the tree would be a
much bigger space-saving that it actually is. If you _also_ get all the
tree and commit objects, the space saving is even less.
I actually suspect that the most realistic way to handle this is to use
the "fetch.c" logic (ie the incremental fetcher used by http), and add
some mode to the git daemon where you fetch literally one object at a time
(ie this would be totally _separate_ from the pack-file thing: you'd not
ask for "git-upload-pack", you'd ask for something like
"git-serve-objects" instead).
The fetch.c logic really does allow for on-demand object fetching, and is
thus much more suitable for incomplete repositories.
HOWEVER. The fetch.c logic - by necessity - works on a object-by-object
level. That means that you'd get no delta compression AT ALL, and I
suspect that the downside of that would be a factor of ten expansion or
more, which means that it would really not work that well in practice.
It might be worth testing, though. It would work fine for the "after I
have the initial cauterized tree, fetch small incremental updates" case.
The operative word here being "small" and "incremental", because I'm
pretty sure it really would suck for the case of a big fetch.
But it would be _simple_, which is why it's worth trying out. It also has
the advantage that it would solve the "I had data corruption on my disk,
and lost 100 objects, but all the the rest is fine" issue. Again, that's
not something that the efficient packing protocol handles, exactly because
it assumes full history, and uses that to do all its optimizations.
Linus
^ permalink raw reply
* Re: Figured out how to get Mozilla into git
From: Timo Hirvonen @ 2006-06-10 16:15 UTC (permalink / raw)
To: Jon Smirl; +Cc: junkio, git
In-Reply-To: <9e4733910606100844v5f4765d8o85c9a6f239faed43@mail.gmail.com>
"Jon Smirl" <jonsmirl@gmail.com> wrote:
> On 6/10/06, Junio C Hamano <junkio@cox.net> wrote:
> > "Jon Smirl" <jonsmirl@gmail.com> writes:
> >
> > > Here's a new transport problem. When using git-clone to fetch Martin's
> > > tree it kept failing for me at dreamhost. I had a parallel fetch
> > > running on my local machine which has a much slower net connection. It
> > > finally finished and I am watching the end phase where it prints all
> > > of the 'walk' messages. The git-http-fetch process has jumped up to
> > > 800MB in size after being 2MB during the download. dreamhost has a
> > > 500MB process size limit so that is why my fetches kept failing there.
> >
> > The http-fetch process uses by mmaping the downloaded pack, and
> > if I recall correctly we are talking about 600MB pack, so 500MB
> > limit sounds impossible, perhaps?
>
> The fetch on my local machine failed too. It left nothing behind, now
> I have to download the 680MB again.
That's sad. Could git-clone be changed to not remove .git directory if
fetching objects fails (after other files in the .git directory have
been fetched)? You could then hopefully continue with git-pull.
--
http://onion.dynserv.net/~timo/
^ permalink raw reply
* Re: Figured out how to get Mozilla into git
From: Jon Smirl @ 2006-06-10 15:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr71xk047.fsf@assigned-by-dhcp.cox.net>
On 6/10/06, Junio C Hamano <junkio@cox.net> wrote:
> "Jon Smirl" <jonsmirl@gmail.com> writes:
>
> > Here's a new transport problem. When using git-clone to fetch Martin's
> > tree it kept failing for me at dreamhost. I had a parallel fetch
> > running on my local machine which has a much slower net connection. It
> > finally finished and I am watching the end phase where it prints all
> > of the 'walk' messages. The git-http-fetch process has jumped up to
> > 800MB in size after being 2MB during the download. dreamhost has a
> > 500MB process size limit so that is why my fetches kept failing there.
>
> The http-fetch process uses by mmaping the downloaded pack, and
> if I recall correctly we are talking about 600MB pack, so 500MB
> limit sounds impossible, perhaps?
The fetch on my local machine failed too. It left nothing behind, now
I have to download the 680MB again.
walk 1f19465388a4ef7aff7527a13f16122a809487d4
walk c3ca840256e3767d08c649f8d2761a1a887351ab
walk 7a74e42699320c02b814b88beadb1ae65009e745
error: Couldn't get
http://mirrors.catalyst.net.nz/pub/mozilla.git//refs/tags/JS%5F1%5F7%5FALPHA%5FBASE
for tags/JS_1_7_ALPHA_BASE
Couldn't resolve host 'mirrors.catalyst.net.nz'
error: Could not interpret tags/JS_1_7_ALPHA_BASE as something to pull
[jonsmirl@jonsmirl mozgit]$ cg update
There is no GIT repository here (.git not found)
[jonsmirl@jonsmirl mozgit]$ ls -a
. ..
[jonsmirl@jonsmirl mozgit]$
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Figured out how to get Mozilla into git
From: Nicolas Pitre @ 2006-06-10 15:14 UTC (permalink / raw)
To: Rogan Dawes; +Cc: Junio C Hamano, git
In-Reply-To: <448ADB8A.3070506@dawes.za.net>
On Sat, 10 Jun 2006, Rogan Dawes wrote:
> Out of curiosity, do you think that it may be possible for tree objects to
> compress more/better if they are packed together? Or does the existing pack
> compression logic already do the diff against similar tree objects?
Tree objects for the same directories are already packed and deltified
against each other in a pack.
Nicolas
^ permalink raw reply
* Re: Figured out how to get Mozilla into git
From: Jakub Narebski @ 2006-06-10 14:58 UTC (permalink / raw)
To: git
In-Reply-To: <448ADB8A.3070506@dawes.za.net>
Rogan Dawes wrote:
> Junio C Hamano wrote:
>> Rogan Dawes <lists@dawes.za.net> writes:
>>
>>> Here's an idea. How about separating trees and commits from the actual
>>> blobs (e.g. in separate packs)?
>>
>> If I remember my numbers correctly, trees for any project with a
>> size that matters contribute nonnegligible amount of the total
>> pack weight. Perhaps 10-25%.
>
> Out of curiosity, do you think that it may be possible for tree objects
> to compress more/better if they are packed together? Or does the
> existing pack compression logic already do the diff against similar tree
> objects?
The problem with compressing and deltafying trees is with sha1 objects
identifiers, I guess.
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: Figured out how to get Mozilla into git
From: Rogan Dawes @ 2006-06-10 14:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzmglgyz0.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Rogan Dawes <lists@dawes.za.net> writes:
>
>> Here's an idea. How about separating trees and commits from the actual
>> blobs (e.g. in separate packs)?
>
> If I remember my numbers correctly, trees for any project with a
> size that matters contribute nonnegligible amount of the total
> pack weight. Perhaps 10-25%.
Out of curiosity, do you think that it may be possible for tree objects
to compress more/better if they are packed together? Or does the
existing pack compression logic already do the diff against similar tree
objects?
>> In this way, the user has a history that will show all of the commit
>> messages, and would be able to see _which_ files have changed over
>> time e.g. gitk would still work - except for the actual file level
>> diff, "git log" should also still work, etc
>
> I suspect it would make a very unpleasant system to use.
> Sometimes "git diff -p" would show diffs, and other times it
> mysteriously complain saying that it lacks necessary blobs to do
> its job. You cannot even run fsck and tell from its output
> which missing objects are OK (because you chose to create such a
> sparse repository) and which are real corruption.
The fsck problem could be worked around by maintaining a list of objects
that are explicitly not expected to be present. As the list gets shorter
(perhaps as diffs are performed, other parts of the blob history are
retrieved, etc), the list will get shorter until we have a complete
clone of the original tree.
Of course diffs against a version further back in the history would
fail. But if you start with a checkout of a complete tree, any changes
made since that point would at least have one version to compare against.
In effect, what we would have is a caching repository (or as Jakub said,
a lazy clone). An initial checkout would effectively be pre-seeding the
cache. One does not necessarily even need to get the complete set of
commit and tree objects, either. The bare minimum would probably be to
get the HEAD commit, and the tree objects that correspond to that commit.
At that point, one could populate the "uncached objects" list with the
parent commits. One would not be in a position to get any history at
all, of course.
As the user performs various operations, e.g. git log, git could either
go and fetch the necessary objects (updating the uncached list as it
goes), or fail with a message such as "Cannot perform the requested
operation - required objects are not available". (We may require another
utility that would list the objects required for an operation, and
compare it against the list of "uncached objects", printing out a list
of which are not yet available locally. I realise that this may be
expensive. Maybe a repo configuration option "cached" to enable or
disable this.)
As Jakub suggested, it would be necessary to configure the location of
the source for any missing objects, but that is probably in the repo
config anyway.
> A shallow clone with explicit cauterization in grafts file at
> least would not have that problem. Although the user will still
> not see the exact same result as what would happen in a full
> repository, at least we can say "your git log ends at that
> commit because your copy of the history does not go back beyond
> that" and the user would understand.
Or, we could say, perform the operation while you are online, and can
access the necessary objects. If the user has explicitly chosen to make
a lazy clone, then they should expect that at some point, whatever they
do may require them to be online to access items that they have not yet
cloned.
Rogan
^ permalink raw reply
* [PATCH] Built-in git-get-tar-commit-id (was: [PATCH/RFC] Retire SIMPLE_*** stuff.)
From: Rene Scharfe @ 2006-06-10 14:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7v3bedn8ym.fsf_-_@assigned-by-dhcp.cox.net>
By being an internal command git-get-commit-id can make use of
struct ustar_header and other stuff and stops wasting precious
disk space.
Note: I recycled one of the two "tar-tree" entries instead of
splitting that cleanup into a separate patch.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
diff --git a/Makefile b/Makefile
index 5226fa1..2a1e639 100644
--- a/Makefile
+++ b/Makefile
@@ -142,11 +142,11 @@ SCRIPTS = $(patsubst %.sh,%,$(SCRIPT_SH)
$(patsubst %.py,%,$(SCRIPT_PYTHON)) \
git-cherry-pick git-status
# The ones that do not have to link with lcrypto, lz nor xdiff.
SIMPLE_PROGRAMS = \
- git-get-tar-commit-id$X git-mailsplit$X \
+ git-mailsplit$X \
git-stripspace$X git-daemon$X
# ... and all the rest that could be moved out of bindir to gitexecdir
PROGRAMS = \
git-checkout-index$X git-clone-pack$X \
@@ -167,11 +167,11 @@ PROGRAMS = \
BUILT_INS = git-log$X git-whatchanged$X git-show$X \
git-count-objects$X git-diff$X git-push$X \
git-grep$X git-add$X git-rm$X git-rev-list$X \
git-check-ref-format$X git-rev-parse$X \
git-init-db$X git-tar-tree$X git-upload-tar$X git-format-patch$X \
- git-ls-files$X git-ls-tree$X \
+ git-ls-files$X git-ls-tree$X git-get-tar-commit-id$X \
git-read-tree$X git-commit-tree$X \
git-apply$X git-show-branch$X git-diff-files$X \
git-diff-index$X git-diff-stages$X git-diff-tree$X git-cat-file$X
# what 'all' will build and 'install' will install, in gitexecdir
diff --git a/builtin-tar-tree.c b/builtin-tar-tree.c
index 7663b9b..58a8ccd 100644
--- a/builtin-tar-tree.c
+++ b/builtin-tar-tree.c
@@ -400,5 +400,30 @@ int cmd_tar_tree(int argc, const char **
usage(tar_tree_usage);
if (!strncmp("--remote=", argv[1], 9))
return remote_tar(argc, argv);
return generate_tar(argc, argv, envp);
}
+
+/* ustar header + extended global header content */
+#define HEADERSIZE (2 * RECORDSIZE)
+
+int cmd_get_tar_commit_id(int argc, const char **argv, char **envp)
+{
+ char buffer[HEADERSIZE];
+ struct ustar_header *header = (struct ustar_header *)buffer;
+ char *content = buffer + RECORDSIZE;
+ ssize_t n;
+
+ n = xread(0, buffer, HEADERSIZE);
+ if (n < HEADERSIZE)
+ die("git-get-tar-commit-id: read error");
+ if (header->typeflag[0] != 'g')
+ return 1;
+ if (memcmp(content, "52 comment=", 11))
+ return 1;
+
+ n = xwrite(1, content + 11, 41);
+ if (n < 41)
+ die("git-get-tar-commit-id: write error");
+
+ return 0;
+}
diff --git a/builtin.h b/builtin.h
index ffa9340..b9f36be 100644
--- a/builtin.h
+++ b/builtin.h
@@ -30,10 +30,11 @@ extern int cmd_add(int argc, const char
extern int cmd_rev_list(int argc, const char **argv, char **envp);
extern int cmd_check_ref_format(int argc, const char **argv, char **envp);
extern int cmd_init_db(int argc, const char **argv, char **envp);
extern int cmd_tar_tree(int argc, const char **argv, char **envp);
extern int cmd_upload_tar(int argc, const char **argv, char **envp);
+extern int cmd_get_tar_commit_id(int argc, const char **argv, char **envp);
extern int cmd_ls_files(int argc, const char **argv, char **envp);
extern int cmd_ls_tree(int argc, const char **argv, char **envp);
extern int cmd_read_tree(int argc, const char **argv, char **envp);
extern int cmd_commit_tree(int argc, const char **argv, char **envp);
extern int cmd_apply(int argc, const char **argv, char **envp);
diff --git a/get-tar-commit-id.c b/get-tar-commit-id.c
deleted file mode 100644
index 4166290..0000000
--- a/get-tar-commit-id.c
+++ /dev/null
@@ -1,30 +0,0 @@
-/*
- * Copyright (C) 2005 Rene Scharfe
- */
-#include <stdio.h>
-#include <string.h>
-#include <unistd.h>
-
-#define HEADERSIZE 1024
-
-int main(int argc, char **argv)
-{
- char buffer[HEADERSIZE];
- ssize_t n;
-
- n = read(0, buffer, HEADERSIZE);
- if (n < HEADERSIZE) {
- fprintf(stderr, "read error\n");
- return 3;
- }
- if (buffer[156] != 'g')
- return 1;
- if (memcmp(&buffer[512], "52 comment=", 11))
- return 1;
- n = write(1, &buffer[523], 41);
- if (n < 41) {
- fprintf(stderr, "write error\n");
- return 2;
- }
- return 0;
-}
diff --git a/git.c b/git.c
index 6db8f2b..9469d44 100644
--- a/git.c
+++ b/git.c
@@ -161,11 +161,11 @@ static void handle_internal_command(int
{ "grep", cmd_grep },
{ "rm", cmd_rm },
{ "add", cmd_add },
{ "rev-list", cmd_rev_list },
{ "init-db", cmd_init_db },
- { "tar-tree", cmd_tar_tree },
+ { "get-tar-commit-id", cmd_get_tar_commit_id },
{ "upload-tar", cmd_upload_tar },
{ "check-ref-format", cmd_check_ref_format },
{ "ls-files", cmd_ls_files },
{ "ls-tree", cmd_ls_tree },
{ "tar-tree", cmd_tar_tree },
^ permalink raw reply related
* Re: gitk on Windows: layout problem
From: Rutger Nijlunsing @ 2006-06-10 11:13 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git, git
In-Reply-To: <17537.22986.653849.367731@cargo.ozlabs.ibm.com>
On Sat, Jun 03, 2006 at 07:43:38PM +1000, Paul Mackerras wrote:
> Rutger Nijlunsing writes:
>
> > Is this a known problem? gitk-du-jour on Windows starts up with an
> > unusable layout. Screenshot attached.
>
> Is that using Tk with the cygwin X server, or the native Windows Tk
> port?
I installed the default cygwin version but I don't have to start an X
server for it. So while it's not the native Windows Tk port, it also
doesn't seem to be the X-server version.
--
Rutger Nijlunsing ---------------------------------- eludias ed dse.nl
never attribute to a conspiracy which can be explained by incompetence
----------------------------------------------------------------------
^ permalink raw reply
* Re: Figured out how to get Mozilla into git
From: Junio C Hamano @ 2006-06-10 9:08 UTC (permalink / raw)
To: Rogan Dawes; +Cc: git
In-Reply-To: <448A847C.20105@dawes.za.net>
Rogan Dawes <lists@dawes.za.net> writes:
> Here's an idea. How about separating trees and commits from the actual
> blobs (e.g. in separate packs)?
If I remember my numbers correctly, trees for any project with a
size that matters contribute nonnegligible amount of the total
pack weight. Perhaps 10-25%.
> In this way, the user has a history that will show all of the commit
> messages, and would be able to see _which_ files have changed over
> time e.g. gitk would still work - except for the actual file level
> diff, "git log" should also still work, etc
I suspect it would make a very unpleasant system to use.
Sometimes "git diff -p" would show diffs, and other times it
mysteriously complain saying that it lacks necessary blobs to do
its job. You cannot even run fsck and tell from its output
which missing objects are OK (because you chose to create such a
sparse repository) and which are real corruption.
A shallow clone with explicit cauterization in grafts file at
least would not have that problem. Although the user will still
not see the exact same result as what would happen in a full
repository, at least we can say "your git log ends at that
commit because your copy of the history does not go back beyond
that" and the user would understand.
^ permalink raw reply
* Re: Figured out how to get Mozilla into git
From: Junio C Hamano @ 2006-06-10 9:00 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e6dvds$oes$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Couldn't it be solved by enhancing initial handshake to send from puller
> (object receivier) to pullee (object sender) the contents of graft file, or
> better the contents of cauterizing graft file - without splitting graft
> file we better have an option to send graft file or not, when graft file is
> used to join historical repository line of development not to cauterize
> history.
>
> Then the sender would use sent cauterizing history graft file for
> calculating which objects to sedn _only_, "in memory" cauterizing it's own
> history.
>
> Now I guess you would tell me why this very simple idea is stupid...
It is not stupid at all; what you said is actually on a correct
track. You indeed just reinvented a half of what I've outlined
earlier for implementing shallow clone (the other half you
missed is that the graft exchange needs to happen both ways,
limiting the commit ancestry graph the both ends walk to the
intersection of the fake view of the ancestry graph both ends
have, but that is a minor detail).
The problem is that what Linus described as "fundamentally hard"
is not the initial "shallow clone" stage, but lies elsewhere.
Namely, what to do after you create such a shallow clone and
when you want to unplug an earlier cauterization points.
In order to unplug a cauterization point (a commit we faked to
be parentless earlier, whose parents and associated objects we
ought to have but we do not because we made a shallow clone),
the downloader needs to re-fetch that commit while temporarily
pretending that it does not have any objects that are newer,
perhaps defining another earlier point as a new cauterization
point at the same time. Git format allows for that, and the
protocol exchange certainly can be extensible to support
something like that, but the design work would be quite
involved.
^ permalink raw reply
* Lazy clone ideas
From: Jakub Narebski @ 2006-06-10 8:58 UTC (permalink / raw)
To: git
I've started new thread for lazy clone ideas,
splitting from "Figured out how to get Mozilla into git"
Rogan Dawes wrote:
> Here's an idea. How about separating trees and commits from the actual
> blobs (e.g. in separate packs)? My reasoning is that the commits and
> trees should only be a small portion of the overall repository size, and
> should not be that expensive to transfer. (Of course, this is only a
> guess, and needs some numbers to back it up.)
>
> So, a shallow clone would receive all of the tree objects, and all of
> the commit objects, and could then request a pack containing the blobs
> represented by the current HEAD.
That would be _lazy_ clone (with on-demand pack downloading from "master"
full history repository), rather than shallow clone.
I had an idea for having all the commit objects (without all the tree
objects) below the soft-grafts line (beyond the line we cut-off full
history and start being lazy).
> In this way, the user has a history that will show all of the commit
> messages, and would be able to see _which_ files have changed over time
> e.g. gitk would still work - except for the actual file level diff, "git
> log" should also still work, etc
>
> This would also enable other optimisations.
>
> For example, documentation people would only need to get the objects
> under the doc/ tree, and would not need to actually check out the
> source. Git could detect any actual changes by checking whether it has
> the previous blob in its local repository, and whether the file exists
> locally. Creating a patch would obviously require that the person checks
> out the previous version, but one could theoretically commit a new blob
> to a repo without having the previous one (not saying that this would be
> a good idea, of course)
Something akin to CVS's modules, or rather to how CVS modules can be abused?
Something called, I think, partial checkout?
This is a separate idea and I think worth implementing even for full
repository.
> This would probably require Eric Biederman's "direct access to blob"
> patches, I guess, in order to be feasible.
And it would need place to store URI from where to doenload objects
on-demand: perhaps 'remote alternatives'?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Figured out how to get Mozilla into git
From: Rogan Dawes @ 2006-06-10 8:36 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jon Smirl, Martin Langhoff, git
In-Reply-To: <Pine.LNX.4.64.0606092001590.5498@g5.osdl.org>
Linus Torvalds wrote:
>
> On Fri, 9 Jun 2006, Carl Worth wrote:
>
>> On Fri, 9 Jun 2006 22:21:17 -0400, "Jon Smirl" wrote:
>>> Could you clone the repo and delete changesets earlier than 2004? Then
>>> I would clone the small repo and work with it. Later I decide I want
>>> full history, can I pull from a full repository at that point and get
>>> updated? That would need a flag to trigger it since I don't want full
>>> history to come over if I am just getting updates from someone else's
>>> tree that has a full history.
>> This is clearly a desirable feature, and has been requested by several
>> people (including myself) looking to switch some large-ish histories
>> from an existing system to git.
>
> The thing is, to some degree it's really fundamentally hard.
>
> It's easy for a linear history. What you do for a linear history is to
> just get the top commit, and the tree associated with it, and then you
> cauterize the parent by just grafting it to go away. Boom. You're done.
>
> The problems are that if the preceding history _wasn't_ linear (or, in
> fact, _subsequent_ development refers to it by having branched off at an
> earlier point), and you try to pull your updates, the other end (that
> knows about all the history) will assume you have all the history that you
> don't have, and will send you a pack assuming that.
>
> Which won't even necessarily have all the tree/blob objects (it assumed
> you already had them), but more annoyingly, the history won't be
> cauterized, and you'll have dangling commits. Which you can cauterize by
> hand, of course, but you literally _will_ have to get the objects and
> cauterize the thing by hand.
>
> You're right that it's not "fundamentally impossible" to do: the git
> format certainly _allows_ it. But the git protocol handshake really does
> end up optimizing away all the unnecessary work by knowing that the other
> side will have all the shared history, so lacking the shared history will
> mean that you're a bit screwed.
Here's an idea. How about separating trees and commits from the actual
blobs (e.g. in separate packs)? My reasoning is that the commits and
trees should only be a small portion of the overall repository size, and
should not be that expensive to transfer. (Of course, this is only a
guess, and needs some numbers to back it up.)
So, a shallow clone would receive all of the tree objects, and all of
the commit objects, and could then request a pack containing the blobs
represented by the current HEAD.
In this way, the user has a history that will show all of the commit
messages, and would be able to see _which_ files have changed over time
e.g. gitk would still work - except for the actual file level diff, "git
log" should also still work, etc
This would also enable other optimisations.
For example, documentation people would only need to get the objects
under the doc/ tree, and would not need to actually check out the
source. Git could detect any actual changes by checking whether it has
the previous blob in its local repository, and whether the file exists
locally. Creating a patch would obviously require that the person checks
out the previous version, but one could theoretically commit a new blob
to a repo without having the previous one (not saying that this would be
a good idea, of course)
This would probably require Eric Biederman's "direct access to blob"
patches, I guess, in order to be feasible.
Regards,
Rogan
^ permalink raw reply
* Re: Figured out how to get Mozilla into git
From: Jakub Narebski @ 2006-06-10 8:21 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0606092001590.5498@g5.osdl.org>
Linus Torvalds wrote:
> On Fri, 9 Jun 2006, Carl Worth wrote:
>
>> On Fri, 9 Jun 2006 22:21:17 -0400, "Jon Smirl" wrote:
>> >
>> > Could you clone the repo and delete changesets earlier than 2004? Then
>> > I would clone the small repo and work with it. Later I decide I want
>> > full history, can I pull from a full repository at that point and get
>> > updated? That would need a flag to trigger it since I don't want full
>> > history to come over if I am just getting updates from someone else's
>> > tree that has a full history.
>>
>> This is clearly a desirable feature, and has been requested by several
>> people (including myself) looking to switch some large-ish histories
>> from an existing system to git.
>
> The thing is, to some degree it's really fundamentally hard.
>
> It's easy for a linear history. What you do for a linear history is to
> just get the top commit, and the tree associated with it, and then you
> cauterize the parent by just grafting it to go away. Boom. You're done.
>
> The problems are that if the preceding history _wasn't_ linear (or, in
> fact, _subsequent_ development refers to it by having branched off at an
> earlier point), and you try to pull your updates, the other end (that
> knows about all the history) will assume you have all the history that you
> don't have, and will send you a pack assuming that.
Couldn't it be solved by enhancing initial handshake to send from puller
(object receivier) to pullee (object sender) the contents of graft file, or
better the contents of cauterizing graft file - without splitting graft
file we better have an option to send graft file or not, when graft file is
used to join historical repository line of development not to cauterize
history.
Then the sender would use sent cauterizing history graft file for
calculating which objects to sedn _only_, "in memory" cauterizing it's own
history.
Main disadvantage is if one cauterized history too eagerly, and shallow
clone history can lack merge bases, and have no way to get them _simply_
using this approach...
Now I guess you would tell me why this very simple idea is stupid...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ 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