* What's cooking in git.git (Oct 2008, #05; Wed, 22)
From: Junio C Hamano @ 2008-10-23 5:41 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'.
The topics list the commits in reverse chronological order. The topics
meant to be merged to the maintenance series have "maint-" in their names.
----------------------------------------------------------------
[New Topics]
* cj/maint-gitpm-fix-maybe-self (Sat Oct 18 20:25:12 2008 +0200) 1 commit
+ Git.pm: do not break inheritance
Looked Ok; will be in 'master' soon.
* gb/gitweb-pathinfo (Tue Oct 21 21:34:54 2008 +0200) 5 commits
- gitweb: generate parent..current URLs
- gitweb: parse parent..current syntax from PATH_INFO
- gitweb: use_pathinfo filenames start with /
- gitweb: generate project/action/hash URLs
- gitweb: parse project/action/hash_base:filename PATH_INFO
Seventh iteration; hopefully the usual gitweb gangs will give quick
comments and ack to push this out to 'next' soon.
* ag/blame-encoding (Wed Oct 22 00:55:57 2008 +0400) 1 commit
+ builtin-blame: Reencode commit messages according to git-log
rules.
Looked Ok; will be in 'master' soon.
* mv/parseopt-checkout-index (Sat Oct 18 03:17:23 2008 +0200) 1 commit
+ parse-opt: migrate builtin-checkout-index.
Looked Ok; will be in 'master' soon.
----------------------------------------------------------------
[Graduated to "master"]
* rs/alloc-ref (Sat Oct 18 10:44:18 2008 +0200) 3 commits
+ make alloc_ref_from_str() the new alloc_ref()
+ use alloc_ref_from_str() everywhere
+ add alloc_ref_with_prefix()
* jc/maint-reset-remove-unmerged-new (Wed Oct 15 16:00:06 2008 -0700) 1 commit
+ reset --hard/read-tree --reset -u: remove unmerged new paths
Teaches "reset --hard" to remove new paths in conflict.
* jk/fix-ls-files-other (Fri Oct 17 13:03:52 2008 -0700) 2 commits
+ Merge branch 'jk/maint-ls-files-other' into jk/fix-ls-files-other
+ refactor handling of "other" files in ls-files and status
* jc/maint-co-track (Fri Oct 17 15:44:39 2008 -0700) 4 commits
+ Fix checkout not to clobber the branch when using symlinked HEAD
upon detaching
+ Enhance hold_lock_file_for_{update,append}() API
+ demonstrate breakage of detached checkout with symbolic link HEAD
+ Fix "checkout --track -b newbranch" on detached HEAD
* jk/maint-ls-files-other (Thu Oct 16 11:07:26 2008 -0400) 1 commit
+ refactor handling of "other" files in ls-files and status
* pb/commit-where (Fri Oct 3 22:13:49 2008 -0400) 4 commits
+ tutorial: update output of git commit
+ reformat informational commit message
+ git commit: Reformat output somewhat
+ builtin-commit.c: show on which branch a commit was added
* js/maint-fetch-update-head (Tue Oct 14 15:32:20 2008 -0700) 2 commits
+ pull: allow "git pull origin $something:$current_branch" into an
unborn branch
+ Fix fetch/pull when run without --update-head-ok
* ns/rebase-noverify (Tue Oct 14 08:17:16 2008 +0900) 2 commits
+ rebase: Document --no-verify option to bypass pre-rebase hook
+ rebase --no-verify
This adds --no-verify to git rebase, to avoid the pre-rebase hook.
* mv/merge-noff (Fri Oct 3 14:04:47 2008 +0200) 1 commit
+ builtin-commit: use reduce_heads() only when appropriate
Fixes "git merge --no-ff --no-commit".
* ae/preservemerge (Mon Sep 29 22:28:57 2008 +0200) 1 commit
+ rebase: Support preserving merges in non-interactive mode
* pb/rename-rowin32 (Fri Oct 3 12:20:43 2008 +0200) 1 commit
+ Do not rename read-only files during a push
Fixes pack file renames on Windows.
* sp/describe-lwtag (Mon Oct 13 07:39:46 2008 -0700) 1 commit
+ describe: Make --tags and --all match lightweight tags more often
When the user gives --tags, the request is asking to treat lightweight and
annotated tags at equal weight, and if lightweight ones are closer, they
should be used.
* gb/formatpatch-autonbr (Thu Oct 2 16:55:39 2008 -0400) 1 commit
+ format-patch: autonumber by default
* dp/checkattr (Wed Oct 15 09:11:52 2008 +0200) 3 commits
+ git-check-attr(1): use 'verse' for multi-line synopsis sections
+ check-attr: Add --stdin option
+ check-attr: add an internal check_attr() function
Batch attr lookup via --stdin, for gitk and git-gui.
* gb/refactor-pathinfo (Fri Oct 10 20:42:26 2008 +0200) 1 commit
+ gitweb: refactor input parameters parse/validation
A major cleanup on the way gitweb parses its input arguments.
Future gitweb patches to add more arguments into the PATH_INFO
depend upon this initial cleanup work.
* ml/cygwin-filemode (Mon Oct 13 00:33:31 2008 -0400) 1 commit
+ compat/cygwin.c - Use cygwin's stat if core.filemode == true
* mv/clonev (Thu Oct 9 01:40:32 2008 +0200) 1 commit
+ Implement git clone -v
Does what it says it does. This may be ready for master soon,
its a pretty trivial change.
* tr/workflow-doc (Sat Sep 13 18:11:01 2008 +0200) 2 commits
+ Documentation: Refer to git-rebase(1) to warn against rewriting
+ Documentation: new upstream rebase recovery section in git-rebase
Also the workflow document itself is now in 'master'.
* sh/maint-rebase3 (Sun Oct 5 23:26:52 2008 -0500) 1 commit
+ rebase--interactive: fix parent rewriting for dropped commits
* jk/diff-convfilter (Sun Oct 5 17:43:45 2008 -0400) 4 commits
+ diff: add filter for converting binary to text
+ diff: introduce diff.<driver>.binary
+ diff: unify external diff and funcname parsing code
+ t4012: use test_cmp instead of cmp
A general cleanup on how diff drivers are implemented. Its still
missing documentation updates and tests but doesn't break anything
current as far as I can tell.
----------------------------------------------------------------
[Stalled]
* nd/narrow (Wed Oct 1 11:04:09 2008 +0700) 9 commits
- grep: skip files outside sparse checkout area
- checkout_entry(): CE_NO_CHECKOUT on checked out entries.
- Prevent diff machinery from examining worktree outside sparse
checkout
- ls-files: Add tests for --sparse and friends
- update-index: add --checkout/--no-checkout to update
CE_NO_CHECKOUT bit
- update-index: refactor mark_valid() in preparation for new options
- ls-files: add options to support sparse checkout
- Introduce CE_NO_CHECKOUT bit
- Extend index to save more flags
Needs review.
* bd/blame (Thu Aug 21 18:22:01 2008 -0500) 5 commits
- Use xdiff caching to improve git blame performance
- Allow xdiff machinery to cache hash results for a file
- Always initialize xpparam_t to 0
- Bypass textual patch generation and parsing in git blame
- Allow alternate "low-level" emit function from xdl_diff
Réne had good comments on how the callback should be structured.
Waiting for a reroll.
* jn/gitweb-customlinks (Sun Oct 12 00:02:32 2008 +0200) 1 commit
- gitweb: Better processing format string in custom links in navbar
Waiting for some sort of response from Pasky.
* jc/gitweb-fix-cloud-tag (Tue Oct 14 21:27:12 2008 -0700) 1 commit
+ Fix reading of cloud tags
Request-for-review-and-ack sent; waiting for response.
----------------------------------------------------------------
[Actively Cooking]
* np/index-pack (Wed Oct 22 20:59:22 2008 -0400) 4 commits
- improve index-pack tests
+ fix multiple issues in index-pack
+ index-pack: smarter memory usage during delta resolution
+ index-pack: rationalize delta resolution code
The buglets that caused people on 'next' some surprises are quickly
killed. Thanks.
* sh/rebase-i-p (Wed Oct 22 11:59:30 2008 -0700) 9 commits
+ git-rebase--interactive.sh: comparision with == is bashism
+ rebase-i-p: minimum fix to obvious issues
+ rebase-i-p: if todo was reordered use HEAD as the rewritten parent
+ rebase-i-p: do not include non-first-parent commits touching
UPSTREAM
+ rebase-i-p: only list commits that require rewriting in todo
+ rebase-i-p: fix 'no squashing merges' tripping up non-merges
+ rebase-i-p: delay saving current-commit to REWRITTEN if squashing
+ rebase-i-p: use HEAD for updating the ref instead of mapping
OLDHEAD
+ rebase-i-p: test to exclude commits from todo based on its parents
Changes the `rebase -i -p` behavior to behave like git sequencer's
rewrite of `rebase -i` would behave.
----------------------------------------------------------------
[On Hold]
* jc/post-simplify (Fri Aug 15 01:34:51 2008 -0700) 2 commits
- revision --simplify-merges: incremental simplification
- revision --simplify-merges: prepare for incremental simplification
I started making this incremental but the progress is not
so great.
* jc/send-pack-tell-me-more (Thu Mar 20 00:44:11 2008 -0700) 1 commit
- "git push": tellme-more protocol extension
This seems to have a deadlock during communication between the peers.
Someone needs to pick up this topic and resolve the deadlock before it can
continue.
* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 2 commits
- blame: show "previous" information in --porcelain/--incremental
format
- git-blame: refactor code to emit "porcelain format" output
* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 1 commit
- diff: enable "too large a rename" warning when -M/-C is explicitly
asked for
This would be the right thing to do for command line use,
but gitk will be hit due to tcl/tk's limitation, so I am holding
this back for now.
^ permalink raw reply
* What's in git.git (Oct 2008, #05; Wed, 22)
From: Junio C Hamano @ 2008-10-23 5:41 UTC (permalink / raw)
To: git
The latest maintenance release 1.6.0.3 is out. 'master' has gitk updates
and also quite a lot of topics that have been cooking in 'next'.
* The 'maint' branch has these fixes since the last announcement.
Abhijit Bhopatkar (1):
Documentation: Clarify '--signoff' for git-commit
Junio C Hamano (2):
Fix testcase failure when extended attributes are in use
GIT 1.6.0.3
Nicolas Pitre (1):
rehabilitate 'git index-pack' inside the object store
* The 'master' branch has these since the last announcement
in addition to the above.
Alexander Gavrilov (3):
gitk: Fix a bug in collapsing deeply nested trees
gitk: Enhance file encoding support
gitk: Implement batch lookup and caching of encoding attrs
Andreas Ericsson (1):
rebase: Support preserving merges in non-interactive mode
Brian Gernhardt (1):
format-patch: autonumber by default
Christian Stimming (1):
gitk: Add untranslated error messages to translation
Dmitry Potapov (2):
check-attr: add an internal check_attr() function
check-attr: Add --stdin option
Fredrik Skolmli (1):
Documentation: Spelling fix
Giuseppe Bilotta (1):
gitweb: refactor input parameters parse/validation
Jeff King (8):
refactor handling of "other" files in ls-files and status
t4012: use test_cmp instead of cmp
diff: unify external diff and funcname parsing code
diff: introduce diff.<driver>.binary
diff: add filter for converting binary to text
document "intent to add" option to git-add
rm: loosen safety valve for empty files
submodule: fix some non-portable grep invocations
Johannes Schindelin (1):
Fix fetch/pull when run without --update-head-ok
Johannes Sixt (1):
git-remote: list branches in vertical lists
Jonas Fonseca (1):
git-check-attr(1): use 'verse' for multi-line synopsis sections
Junio C Hamano (6):
pull: allow "git pull origin $something:$current_branch" into an unborn
branch
Fix "checkout --track -b newbranch" on detached HEAD
reset --hard/read-tree --reset -u: remove unmerged new paths
demonstrate breakage of detached checkout with symbolic link HEAD
Enhance hold_lock_file_for_{update,append}() API
Fix mismerge at cdb22c4 in builtin-checkout.c
Lee Marlow (2):
bash completion: Add 'workflows' to 'git help'
workflows documentation: fix link to git-request-pull[1]
Mark Levedahl (1):
compat/cygwin.c - Use cygwin's stat if core.filemode == true
Matt McCutchen (1):
git-merge-recursive: honor merge.conflictstyle once again
Miklos Vajna (2):
builtin-commit: use reduce_heads() only when appropriate
Implement git clone -v
Nanako Shiraishi (2):
rebase --no-verify
rebase: Document --no-verify option to bypass pre-rebase hook
Paul Mackerras (6):
gitk: Use <Button-2> for context menus on OSX
gitk: Clean up file encoding code and add enable/disable option
gitk: Fix binding for <Return> in sha1 entry field
gitk: New way of constructing menus that allows for Alt+letter
accelerators
gitk: Regenerate .po files
gitk: Turn short SHA1 names into links too
Petr Baudis (1):
Do not rename read-only files during a push
René Scharfe (3):
add alloc_ref_with_prefix()
use alloc_ref_from_str() everywhere
make alloc_ref_from_str() the new alloc_ref()
Richard Quirk (1):
gitk: Bind Key-Return to create on new branch dialog
Shawn O. Pearce (1):
describe: Make --tags and --all match lightweight tags more often
Stephen Haberman (1):
rebase--interactive: fix parent rewriting for dropped commits
Thomas Rast (3):
Documentation: new upstream rebase recovery section in git-rebase
Documentation: Refer to git-rebase(1) to warn against rewriting
Documentation: add manpage about workflows
^ permalink raw reply
* Re: [PATCH 2/3] Add -n/--no-prompt option to mergetool
From: Charles Bailey @ 2008-10-23 6:44 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Jeff King, William Pursell, Andreas Ericsson,
Theodore Ts'o
In-Reply-To: <7vr668tdvy.fsf@gitster.siamese.dyndns.org>
On Wed, Oct 22, 2008 at 04:21:21PM -0700, Junio C Hamano wrote:
> Charles Bailey <charles@hashpling.org> writes:
>
> > I'm pretty keen on this patch, but have no strong opinions on which
> > short option is used, so are there any votes against -y?
>
> Between 'n' and 'y', I am in favour of the latter, but at the same time I
> have to wonder if there are other commands that would want "Assume yes"
> option. It could be that this single command that prompts for "Is this
> Ok" is an oddball and giving it an "interactive" option to trigger the
> current behaviour might make things more consistent. I dunno.
>
I think that git mergetool probably counts as at least 'unusual', and
I think that there is some merit in the current default behaviour. It
gives you a prompt at which you can C-c if it's about to run something
that you don't want it to do the first few times that you try
mergetool.
After more thoughts, I'm somewhat in favour of dropping the short
switch altogether. As it just saves a single keypress per merge I
imagine that most mergetool users, once they discover this new
feature and decide that they want to use it, will prefer to use a user
config option to switch it on. The command line option then becomes
something that you would only need to use to override your normal
default and something on which to hang the option description in the
man page.
--
Charles Bailey
http://ccgi.hashpling.plus.com/blog/
^ permalink raw reply
* Re: git performance
From: Andreas Ericsson @ 2008-10-23 7:41 UTC (permalink / raw)
To: Edward Ned Harvey; +Cc: git
In-Reply-To: <000901c93490$e0c40ed0$a24c2c70$@com>
Edward Ned Harvey wrote:
>> Yes, it does stat all the files. How many files are you talking
>> about, and what platform? From a warm cache on Linux, the 23,000
>> files kernel repo takes about a tenth of a second to stat all files
>> for me (and this on a several year-old machine). And of course many
>> operations don't require stat'ing at all (like looking at logs, or
>> diffs that don't involve the working tree).
>
> No worries. No solution can meet everyone's needs.
>
> I'm talking about 40-50,000 files, on multi-user production linux,
Umm... using git to track a production server? I think there's something
in your specific use-case that eluded pretty much everyone here the
first time you asked about it.
git was built to maintain the linux kernel with its patch-and-merge based
workflow, 117k commits and 25k files. It's *good* at that sort of thing,
but a lot of features are "source-code management" specific. It sounds to
me you're asking for something that will keep a backup of most of your
entire system (apart from /home), which it's not really suited for. For
instance, it doesn't keep track of mode-bits on files (apart from
"executable or not").
> which means the cache is never warm, except when I'm benchmarking.
> Specifically RHEL 4 with the files on NFS mount. Cold cache "svn st"
> takes ~10 mins. Warm cache 20-30 sec. Surprisingly to me,
> performance was approx the same for files on local disk versus NFS.
> Probably the best solution for us is perforce, we just don't like the
> pricetag.
>
> Out of curiosity, what are they talking about, when they say "git is
> fast?"
Merges, patch application, committing, history walking and data
transfers are all extremely quick operations under git.
Actually, history walking isn't extremely quick, but several neat
tricks are in place that make it *seem* quick. Running
"git log drivers/net/wireless" on the linux kernel with a cold
cache starts spitting out output after about 1 second on my measly
laptop (where the kernel has 117k commits on 25k files).
> Just the fact that it's all local disk, or is there more to
> it than that? I could see - git would probably outperform perforce
> for versioning of large files (let's say iso files) to benefit from
> sustained local disk IO, while perforce would probably outperform
> anything I can think of, operating on thousands of tiny files,
> because it will never walk the tree.
>
Git doesn't *have* to walk the tree either. "git status" obviously
has to do that, since you're asking "what files have changed in this
tree since I last added stuff to the index", but you can use git just
fine without ever issuing "git status" (assuming you're the one
controlling the changes, that is).
"git rm" and "git add" won't walk the tree. They're just interested in
the paths you give them and won't touch anything else.
"git commit path1 path2" won't walk the tree. It has to walk the paths
(which can be entire subdirectories, or all of them), but not more than
that.
"git push" (ie, send your changes upstream) won't walk the tree. It'll
just look at the history and how they differ.
"git merge" (and therefore also "git pull") doesn't walk the tree. It
only makes sure paths that are touched by the merge are up-to-date.
Apart from that, it would be trivial to hack up some inotify config
and scripts that stages changes in a separate index-file and then
add a simple wrapper that operates on the separate index-file rather
than the "regular" one.
Sample "giti" wrapper:
--%<--%<--%<--
#!/bin/sh
# giti - inotify driven git wrapper
GIT_INDEX=.git/inotify-index
export GIT_INDEX
case "$@" in
status)
git diff --name-only --cached
exit $?
;;
esac
git "$@"
--%<--%<--%<--
Sample inotify script:
--%<--%<--%<--
#!/bin/sh
GIT_INDEX=.git/inotify-index git add $1
--%<--%<--%<--
Sample incrontab(5) entry:
--%<--%<--%<--
/watched/path IN_CLOSE_WRITE inotify.git $@/$#
--%<--%<--%<--
Totally untested ofcourse, so it probably needs tweaking. It should
work rather well though, assuming you're somewhat careful what
arguments you send to the "giti" wrapper and make sure to never
use any git-commands that *have* to walk the entire tree (such as
"git commit -a").
Let us know how it pans out.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git performance
From: Andreas Ericsson @ 2008-10-23 7:43 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Edward Ned Harvey, git
In-Reply-To: <m3d4hsi708.fsf@localhost.localdomain>
Jakub Narebski wrote:
> "Edward Ned Harvey" <git@nedharvey.com> writes:
>
>> I see things all over the Internet saying git is fast. I'm
>> currently struggling with poor svn performance and poor attitude of
>> svn developers, so I'd like to consider switching to git. A quick
>> question first.
>>
>> The core of the performance problem I'm facing is the need to "walk
>> the tree" for many thousand files. Every time I do "svn update" or
>> "svn status" the svn client must stat every file to check for local
>> modifications (a coffee cup or a beer worth of stats). In essence,
>> this is unavoidable if there is no mechanism to constantly monitor
>> filesystem activity during normal operations. Analogous to
>> filesystem journaling.
>>
>> So - I didn't see anything out there saying "git is fast because it
>> uses inotify" or anything like that. Perhaps git would not help me
>> at all? Because git still needs to stat all the files in the tree?
>
> http://git.or.cz/gitwiki/GitBenchmarks
>
> While it should be possible to use 'assume unchanged' bit together
> with inotify / icron, it is not something tha is done; IIRC Mercurial
> had Linux-only InotifyPlugin...
>
Well, inotify() is Linux specific, so it'd be quite hard to support on
another platform. Emulating it with a billion stat() calls feels rather
like a disk (and I/O performance) killer.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Terminology question: "tracking" branches
From: Michael J Gruber @ 2008-10-23 8:07 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Marc Branchaud, Peter Harris, git, Junio C Hamano
In-Reply-To: <20081022161302.GC16946@atjola.homenet>
Björn Steinbrink venit, vidit, dixit 22.10.2008 18:13:
> On 2008.10.22 16:59:58 +0200, Michael J Gruber wrote:
>> - a remote branch (a branch in your local repo which is a copy of a
>> branch in a remote repo; stored under refs/remotes, never to be modified
>> locally)
>> - a (remote) tracking branch (a local branch which is set up to pull
>> from a remote branch by default)
>
> (Remote) tracking branches are actually what you called remote branches,
> at least according to the git glossary. But I wonder, what is the right
> term for a branch that has the --track setup for pull?
Ooops, I'm sorry. I went by the name of the "--track" option and was
sure that that "git help branch" used the name "tracking branch" for the
branches created with "--track", but I was wrong. So:
"(remote) tracking branch" is a local branch stored under refs/remotes/
which is a "copy" of a branch on a remote repository.
That leaves open:
- What does "remote branch" mean, if it means anything at all? It could
be used for a branch in a remote repository, i.e. the other side of
fetch/push refspec (remote branch:tracking branch).
- How to name a local branch created with --track off of a (remote)
tracking branch? Local tracking branch? Downstream/work/modification branch?
I think that linguistically, the confusion comes from using the noun as
well as the adjective "remote". As an adjective: "remote something"
cleary is something residing remotely. As a noun it's the config added
by "git remote add".
Note that the glossary doesn't define remote at all. I'd volunteer
changing that once the discussion reaches a consensus.
My suggestion would be:
remote (noun): A configuration as created by "git remote add" which
points to a remote repository (using a URL) and sets up refspecs for
fetching and/or pulling. Note that the URL may point to a local
filesystem or even ".". See also remote (adjective).
remote (adjective): Anything residing in another repository. See also
remote (noun).
local: Sometimes used to emphasize things residing "locally", i.e. in
the repository at hand, as opposed to "remotely".
tracking branch: A branch tracking a (remote) branch on a remote
repository, i.e. a local branch stored under refs/remotes/ which is a
"copy" of a branch on a remote repository; typically created by "git
clone" or "git remote add/update".
remote tracking branch: Synonymous with tracking branch. [remote is a
noun, an object for track here]
[adjective to be found] branch: A local branch which is set up to pull
or rebase automatically from a tracking branch. Used for local
modifications to remote branches. [I'm tempted to use local tracking
branch here, but that would just add to the confusion.]
Come to think of it: "Off-track" branch would be the ideal name for a
local branch created off of a (remote) tracking branch, using --track to
specify the track where things go off. But I'm not sure everyone would
like the implied pun...
Cheers,
Michael
^ permalink raw reply
* Re: Tip: avoiding net overhead using git over sshfs
From: Michael J Gruber @ 2008-10-23 8:32 UTC (permalink / raw)
To: Felipe Carvalho Oliveira; +Cc: git
In-Reply-To: <a2075f4c0810221826w511a3b87r6fea4fb0dee24e1f@mail.gmail.com>
Felipe Carvalho Oliveira venit, vidit, dixit 23.10.2008 03:26:
> Use git over sshfs is not so good, but is an option for people that
> don't have shell acess to the server/hosting like me.
I'm sorry but I'm afraid I'm missing the point: If you don't have shell
access then you can't use ssh(fs), can you?
Maybe you mean you can't set up git daemon or gitweb.cgi on the server?
> # mounting
> sshfs -o workaround=rename <user>@<host>:/home/<user>/ <mount_point>
> cd <the_directory_of_your_project>
>
> # we will move the .git directory to the local filesystem
> mv .git ~/.my_project_git
> # and create a symlink to the local .git
> ln -s ~/.my_project_git .git
>
> Done!
>
> Now you can open gitk instantly ;-) and don't need to have the entire
> .git thing on a remote filesystem.
In fact your complete git repository is now on the local filesystem,
with only the worktree checked out on sshfs. Is that what you are trying
to achieve? Or do you want to "synchronize" repos on local and sshfs
filesystems?
Michael
^ permalink raw reply
* Re: Tip: avoiding net overhead using git over sshfs
From: Matthieu Moy @ 2008-10-23 9:00 UTC (permalink / raw)
To: Felipe Carvalho Oliveira; +Cc: git
In-Reply-To: <a2075f4c0810221826w511a3b87r6fea4fb0dee24e1f@mail.gmail.com>
"Felipe Carvalho Oliveira" <felipekde@gmail.com> writes:
> Use git over sshfs is not so good, but is an option for people that
> don't have shell acess to the server/hosting like me.
>
> # mounting
> sshfs -o workaround=rename <user>@<host>:/home/<user>/ <mount_point>
> cd <the_directory_of_your_project>
>
> # we will move the .git directory to the local filesystem
> mv .git ~/.my_project_git
> # and create a symlink to the local .git
> ln -s ~/.my_project_git .git
I think you'd better work locally, and push to the sshfs directory
from time to time. Then, you'd both have working tree and .git locally
and fast, while keeping the safety of replicating to your ssh server.
--
Matthieu
^ permalink raw reply
* Re: git performance
From: Andreas Ericsson @ 2008-10-23 7:11 UTC (permalink / raw)
To: Edward Ned Harvey; +Cc: git
In-Reply-To: <000901c93490$e0c40ed0$a24c2c70$@com>
Edward Ned Harvey wrote:
>> Yes, it does stat all the files. How many files are you talking about,
>> and what platform? From a warm cache on Linux, the 23,000 files kernel
>> repo takes about a tenth of a second to stat all files for me (and this
>> on a several year-old machine). And of course many operations don't
>> require stat'ing at all (like looking at logs, or diffs that don't
>> involve the working tree).
>
> No worries. No solution can meet everyone's needs.
>
> I'm talking about 40-50,000 files, on multi-user production linux, which means the cache is never warm, except when I'm benchmarking. Specifically RHEL 4 with the files on NFS mount. Cold cache "svn st" takes ~10 mins. Warm cache 20-30 sec. Surprisingly to me, performance was approx the same for files on local disk versus NFS. Probably the best solution for us is perforce, we just don't like the pricetag.
>
> Out of curiosity, what are they talking about, when they say "git is fast?" Just the fact that it's all local disk, or is there more to it than that? I could see - git would probably outperform perforce for versioning of large files (let's say iso files) to benefit from sustained local disk IO, while perforce would probably outperform anything I can think of, operating on thousands of tiny files, because it will never walk the tree.
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git performance
From: Andreas Ericsson @ 2008-10-23 7:11 UTC (permalink / raw)
To: Edward Ned Harvey; +Cc: git
In-Reply-To: <000901c93490$e0c40ed0$a24c2c70$@com>
Edward Ned Harvey wrote:
>> Yes, it does stat all the files. How many files are you talking about,
>> and what platform? From a warm cache on Linux, the 23,000 files kernel
>> repo takes about a tenth of a second to stat all files for me (and this
>> on a several year-old machine). And of course many operations don't
>> require stat'ing at all (like looking at logs, or diffs that don't
>> involve the working tree).
>
> No worries. No solution can meet everyone's needs.
>
> I'm talking about 40-50,000 files, on multi-user production linux, which means the cache is never warm, except when I'm benchmarking. Specifically RHEL 4 with the files on NFS mount. Cold cache "svn st" takes ~10 mins. Warm cache 20-30 sec. Surprisingly to me, performance was approx the same for files on local disk versus NFS. Probably the best solution for us is perforce, we just don't like the pricetag.
>
> Out of curiosity, what are they talking about, when they say "git is fast?" Just the fact that it's all local disk, or is there more to it than that? I could see - git would probably outperform perforce for versioning of large files (let's say iso files) to benefit from sustained local disk IO, while perforce would probably outperform anything I can think of, operating on thousands of tiny files, because it will never walk the tree.
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Tip: avoiding net overhead using git over sshfs
From: Felipe Carvalho Oliveira @ 2008-10-23 11:51 UTC (permalink / raw)
To: Michael J Gruber, Matthieu Moy; +Cc: git
In-Reply-To: <490036A2.20608@drmicha.warpmail.net>
On Thu, Oct 23, 2008 at 6:32 AM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> I'm sorry but I'm afraid I'm missing the point: If you don't have shell
> access then you can't use ssh(fs), can you?
> Maybe you mean you can't set up git daemon or gitweb.cgi on the server?
Yes, i can't set up any git daemon or any other software.
I have just sftp acess. And sftp is a "dumb protocol" to use git.
On Thu, Oct 23, 2008 at 7:00 AM, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
> I think you'd better work locally, and push to the sshfs directory
> from time to time. Then, you'd both have working tree and .git locally
> and fast, while keeping the safety of replicating to your ssh server.
I can't use git-push as I explained before.
I use git as a deployment tool in this case.
I work locallly and use git-pull to sync my local repo and the
"production"(server).
Git works better than a manual (S)FTP sync.
I hope I'm more clear now.
--
Felipe
^ permalink raw reply
* Re: [PATCH 3/7] gitk: Allow starting gui blame for a specific line.
From: Paul Mackerras @ 2008-10-23 11:58 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: git
In-Reply-To: <1223449540-20457-4-git-send-email-angavrilov@gmail.com>
Alexander Gavrilov writes:
> Adds a context menu item to the diff viewer pane that
> calls blame, focusing it on the clicked line. In case
> of combined diffs, it also automatically deduces which
> parent is to be blamed.
I have some comments on this one, but I haven't finished reviewing it
completely, so I may have more... :)
> +proc find_hunk_blamespec {base line} {
> + global ctext
> +
> + # Find and parse the hunk header
> + set s_lix [$ctext search -backwards -regexp ^@@ "$line.0 lineend" $base.0]
> + if {$s_lix eq {}} return
> +
> + set s_line [$ctext get $s_lix "$s_lix + 1 lines"]
> + if {![regexp {^@@@?(( -\d+(,\d+)?)+) \+(\d+)(,\d+)? @@} $s_line \
In fact there can be many @ characters at the beginning of the line;
the number of parents plus one, in fact. See commit
c465a76af658b443075d6efee1c3131257643020 in the kernel tree for an
example. I suggest starting with ^@@@* rather than ^@@@?.
> + # Now scan the lines to determine offset within the hunk
> + set parent {}
> + set dline 0
> + set s_lno [lindex [split $s_lix "."] 0]
> +
> + for {set i $line} {$i > $s_lno} {incr i -1} {
> + set c_line [$ctext get $i.0 "$i.0 + 1 lines"]
> + if {$parent eq {}} {
> + # find first preceeding line that belongs to some parent
> + for {set j 0} {$j < [llength $old_lines]} {incr j} {
> + set code [string index $c_line $j]
> + if {$code ne {-} && $code ne { }} continue
> + if {$code eq { } && $parent ne {}} continue
> + set parent $j
> + if {$code eq {-}} break
> + }
> + }
This part worries me a bit. If the user clicks on a line where all
the $code values are "+" then I think we should blame the current
commit. Either that, or we disable the context menu item before
posting it if the user clicks on a line that starts with all "+"
characters (as many "+" as there are parents).
BTW, writing "-" rather than {-} in expressions is more idiomatic.
Paul.
^ permalink raw reply
* git-cvsimport bug? Newly created branch not seen unless there's at least one commit in it
From: Francis Galiegue @ 2008-10-23 12:01 UTC (permalink / raw)
To: git
Hello,
I've tried to git-cvsimport a module from CVS, where a branch named "foo"
existed. CVSROOT set in the environment, CVS_RSH too, and I imported with:
git-cvsimport -k -a -C themodule themodule
However, it didn't do what I expected: I couldn't see the branch named "foo".
I had to make a commit using CVS on that very same module on that "foo"
branch. After the commit, out of curiosity, I executed the same git command
again in the same directory: this time the branch was seen.
Is this a bug, or is there a git-cvsimport option that I missed? I have looked
at the manpage several times, and couldn't find what option could be of any
use in my case (mind you, I haven't looked at the cvsps manpage either).
Thanks,
--
fge
^ permalink raw reply
* git-cvsimport bug? Newly created branch not seen unless there's at least one commit in it
From: Francis Galiegue @ 2008-10-23 12:00 UTC (permalink / raw)
To: git
Hello,
I've tried to git-cvsimport a module from CVS, where a branch named "foo"
existed. CVSROOT set in the environment, CVS_RSH too, and I imported with:
git-cvsimport -k -a -C themodule themodule
However, it didn't do what I expected: I couldn't see the branch named "foo".
I had to make a commit using CVS on that very same module on that "foo"
branch. After the commit, out of curiosity, I executed the same git command
again in the same directory: this time the branch was seen.
Is this a bug, or is there a git-cvsimport option that I missed? I have looked
at the manpage several times, and couldn't find what option could be of any
use in my case (mind you, I haven't looked at the cvsps manpage either).
Thanks,
--
Francis Galiegue
ONE2TEAM
Ingénieur système
Mob : +33 (0) 6 83 87 78 75
Tel : +33 (0) 1 78 94 55 52
fge@one2team.com
40 avenue Raymond Poincaré
75116 Paris
^ permalink raw reply
* Re: [RFC] Zit: the git-based single file content tracker
From: Felipe Oliveira Carvalho @ 2008-10-23 12:33 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git
In-Reply-To: <gdok16$vh2$1@ger.gmane.org>
It sounds interesting. I have some single files that I would like to track
using git, zit seems to be a good solution.
--
Felipe
^ permalink raw reply
* Re: git performance
From: Matthieu Moy @ 2008-10-23 12:16 UTC (permalink / raw)
To: Edward Ned Harvey; +Cc: git
In-Reply-To: <000901c93490$e0c40ed0$a24c2c70$@com>
"Edward Ned Harvey" <git@nedharvey.com> writes:
>> Yes, it does stat all the files. How many files are you talking about,
>> and what platform? From a warm cache on Linux, the 23,000 files kernel
>> repo takes about a tenth of a second to stat all files for me (and this
>> on a several year-old machine). And of course many operations don't
>> require stat'ing at all (like looking at logs, or diffs that don't
>> involve the working tree).
>
> No worries. No solution can meet everyone's needs.
>
> I'm talking about 40-50,000 files, on multi-user production linux,
> which means the cache is never warm, except when I'm benchmarking.
> Specifically RHEL 4 with the files on NFS mount. Cold cache "svn st"
> takes ~10 mins. Warm cache 20-30 sec.
SVN does not only has to stat the files. It also has to read the
stat-cache information wich is split in one .svn/ per directory in the
working tree. Not sure which operation dominates the performance,
though. Best is just to try.
> Out of curiosity, what are they talking about, when they say "git is
> fast?" Just the fact that it's all local disk, or is there more to
> it than that?
Not just local disk: bzr also works locally, and git is much faster on
most operations (bzr status can now compete with git, but "git log"
and "git commit" can be instantaneous where bzr take 1 minute for
example).
For sure, doing most operations locally is the key to being fast, but
Git has also been written so that the complexity of algorithms be as
low as possible.
> I could see - git would probably outperform perforce for versioning
> of large files (let's say iso files) to benefit from sustained local
> disk IO, while perforce would probably outperform anything I can
> think of, operating on thousands of tiny files, because it will
> never walk the tree.
Mercurial has an extension called "inotify" that avoids walking the
disk too. AFAIK doesn't have an equivalent in Git (mostly because most
people interested find git fast enough).
--
Matthieu
^ permalink raw reply
* Re: [RFC] Zit: the git-based single file content tracker
From: Nguyen Thai Ngoc Duy @ 2008-10-23 12:50 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git
In-Reply-To: <gdok16$vh2$1@ger.gmane.org>
On 10/23/08, Giuseppe Bilotta <giuseppe.bilotta@gmail.com> wrote:
> The principle is extremely simple: when you choose to start tracking a
> file with Zit,
>
> zit track file
>
> Zit will create a directory .zit.file to hold a git repository
> tracking the single file .zit.file/file, which is just a hard link to
> file.
Why not use one .zit repo and track each file on each own branch?.
--
Duy
^ permalink raw reply
* Re: Tip: avoiding net overhead using git over sshfs
From: Johannes Sixt @ 2008-10-23 12:54 UTC (permalink / raw)
To: Felipe Carvalho Oliveira; +Cc: Michael J Gruber, Matthieu Moy, git
In-Reply-To: <a2075f4c0810230451lefff6ffnc283f4078eff9f9c@mail.gmail.com>
Felipe Carvalho Oliveira schrieb:
> On Thu, Oct 23, 2008 at 7:00 AM, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
>> I think you'd better work locally, and push to the sshfs directory
>> from time to time. Then, you'd both have working tree and .git locally
>> and fast, while keeping the safety of replicating to your ssh server.
>
> I can't use git-push as I explained before.
> I use git as a deployment tool in this case.
> I work locallly and use git-pull to sync my local repo and the
> "production"(server).
> Git works better than a manual (S)FTP sync.
Then how about this: You keep your repository local, and you also hack
locally. When it's time to push your changes to the production server, you
do this:
$ GIT_INDEX_FILE=.git/index.published \
GIT_WORK_TREE=/sshfs-mount/on/production/server \
git reset --hard
This will update only files that changed since you did this the last time.
Disclaimer: I didn't try this myself.
-- Hannes
^ permalink raw reply
* [PATCH] Implement git remote rename
From: Miklos Vajna @ 2008-10-23 12:56 UTC (permalink / raw)
To: Jeff King; +Cc: Brandon Casey, Junio C Hamano, git
In-Reply-To: <20081023035213.GA8396@coredump.intra.peff.net>
The new rename subcommand does the followings:
1) Renames the remote.foo configuration section to remote.bar
2) Updates the remote.bar.fetch refspecs
3) Updates the branch.*.remote settings
4) Renames the tracking branches.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
On Wed, Oct 22, 2008 at 11:52:14PM -0400, Jeff King <peff@peff.net> wrote:
> I can't help but notice that the word "rename" appears all over the
> commit description and in the code, but not in the user interface.
> Maybe
> "rename" would be a better name for the command instead of (or in
> addition to) "mv"?
I called it "mv" because of "rm" (it is not "remove") and
git-mv/git-add, but I don't think it's a problem if it's called
"rename". Here is an updated patch.
The function name is still "mv" because of rename(2).
Documentation/git-remote.txt | 6 ++
builtin-remote.c | 106 ++++++++++++++++++++++++++++++++++++++++++
t/t5505-remote.sh | 14 ++++++
3 files changed, 126 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt
index bb99810..7b227b3 100644
--- a/Documentation/git-remote.txt
+++ b/Documentation/git-remote.txt
@@ -11,6 +11,7 @@ SYNOPSIS
[verse]
'git remote' [-v | --verbose]
'git remote add' [-t <branch>] [-m <master>] [-f] [--mirror] <name> <url>
+'git remote rename' <old> <new>
'git remote rm' <name>
'git remote show' [-n] <name>
'git remote prune' [-n | --dry-run] <name>
@@ -61,6 +62,11 @@ only makes sense in bare repositories. If a remote uses mirror
mode, furthermore, `git push` will always behave as if `\--mirror`
was passed.
+'rename'::
+
+Rename the remote named <old> to <new>. All remote tracking branches and
+configuration settings for the remote are updated.
+
'rm'::
Remove the remote named <name>. All remote tracking branches and
diff --git a/builtin-remote.c b/builtin-remote.c
index 6b3325d..106d6f6 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c
@@ -10,6 +10,7 @@
static const char * const builtin_remote_usage[] = {
"git remote",
"git remote add <name> <url>",
+ "git remote rename <old> <new>",
"git remote rm <name>",
"git remote show <name>",
"git remote prune <name>",
@@ -329,6 +330,109 @@ static int add_branch_for_removal(const char *refname,
return 0;
}
+struct rename_info {
+ const char *old;
+ const char *new;
+ struct string_list *remote_branches;
+};
+
+static int read_remote_branches(const char *refname,
+ const unsigned char *sha1, int flags, void *cb_data)
+{
+ struct rename_info *rename = cb_data;
+ struct strbuf buf = STRBUF_INIT;
+
+ strbuf_addf(&buf, "refs/remotes/%s", rename->old);
+ if(!prefixcmp(refname, buf.buf))
+ string_list_append(xstrdup(refname), rename->remote_branches);
+
+ return 0;
+}
+
+static int mv(int argc, const char **argv)
+{
+ struct option options[] = {
+ OPT_END()
+ };
+ struct remote *oldremote, *newremote;
+ struct strbuf buf = STRBUF_INIT, buf2 = STRBUF_INIT;
+ struct string_list remote_branches = { NULL, 0, 0, 0 };
+ struct rename_info rename;
+ int i;
+
+ if (argc != 3)
+ usage_with_options(builtin_remote_usage, options);
+
+ rename.old = argv[1];
+ rename.new = argv[2];
+ rename.remote_branches = &remote_branches;
+
+ oldremote = remote_get(rename.old);
+ if (!oldremote)
+ die("No such remote: %s", rename.old);
+
+ newremote = remote_get(rename.new);
+ if (newremote && (newremote->url_nr > 1 || newremote->fetch_refspec_nr))
+ die("remote %s already exists.", rename.new);
+
+ strbuf_addf(&buf, "refs/heads/test:refs/remotes/%s/test", rename.new);
+ if (!valid_fetch_refspec(buf.buf))
+ die("'%s' is not a valid remote name", rename.new);
+
+ strbuf_reset(&buf);
+ strbuf_addf(&buf, "remote.%s", rename.old);
+ strbuf_addf(&buf2, "remote.%s", rename.new);
+ if (git_config_rename_section(buf.buf, buf2.buf) < 1)
+ return error("Could not rename config section '%s' to '%s'",
+ buf.buf, buf2.buf);
+
+ strbuf_reset(&buf);
+ strbuf_addf(&buf, "remote.%s.fetch", rename.new);
+ if (git_config_set_multivar(buf.buf, NULL, NULL, 1))
+ return error("Could not remove config section '%s'", buf.buf);
+ for (i = 0; i < oldremote->fetch_refspec_nr; i++) {
+ char *ptr;
+
+ strbuf_reset(&buf2);
+ strbuf_addstr(&buf2, oldremote->fetch_refspec[i]);
+ ptr = strstr(buf2.buf, rename.old);
+ if (ptr)
+ strbuf_splice(&buf2, ptr-buf2.buf, strlen(rename.old),
+ rename.new, strlen(rename.new));
+ if (git_config_set_multivar(buf.buf, buf2.buf, "^$", 0))
+ return error("Could not append '%s'", buf.buf);
+ }
+
+ read_branches();
+ for (i = 0; i < branch_list.nr; i++) {
+ struct string_list_item *item = branch_list.items + i;
+ struct branch_info *info = item->util;
+ if (info->remote && !strcmp(info->remote, rename.old)) {
+ strbuf_reset(&buf);
+ strbuf_addf(&buf, "branch.%s.remote", item->string);
+ if (git_config_set(buf.buf, rename.new)) {
+ return error("Could not set '%s'", buf.buf);
+ }
+ }
+ }
+
+ for_each_ref(read_remote_branches, &rename);
+ for (i = 0; i < remote_branches.nr; i++) {
+ struct string_list_item *item = remote_branches.items + i;
+ strbuf_reset(&buf);
+ strbuf_addstr(&buf, item->string);
+ strbuf_splice(&buf, strlen("refs/remotes/"), strlen(rename.old),
+ rename.new, strlen(rename.new));
+ strbuf_reset(&buf2);
+ strbuf_addf(&buf2, "remote: renamed %s to %s",
+ item->string, buf.buf);
+ if (rename_ref(item->string, buf.buf, buf2.buf))
+ die("renaming '%s' failed", item->string);
+ }
+
+ return 0;
+}
+
static int remove_branches(struct string_list *branches)
{
int i, result = 0;
@@ -696,6 +800,8 @@ int cmd_remote(int argc, const char **argv, const char *prefix)
result = show_all();
else if (!strcmp(argv[0], "add"))
result = add(argc, argv);
+ else if (!strcmp(argv[0], "rename"))
+ result = mv(argc, argv);
else if (!strcmp(argv[0], "rm"))
result = rm(argc, argv);
else if (!strcmp(argv[0], "show"))
diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh
index c449663..58bd7bf 100755
--- a/t/t5505-remote.sh
+++ b/t/t5505-remote.sh
@@ -324,4 +324,18 @@ test_expect_success 'reject adding remote with an invalid name' '
'
+# The first three tests if the config is properly updated, the last one
+# checks if the branches are renamed.
+
+test_expect_success 'rename a remote' '
+
+ git clone one four &&
+ (cd four &&
+ git remote rename origin upstream &&
+ git remote show |grep -q upstream &&
+ git config remote.upstream.fetch |grep -q upstream &&
+ test $(git config branch.master.remote) = "upstream" &&
+ git for-each-ref|grep -q refs/remotes/upstream)
+
+'
test_done
--
1.6.0.2
^ permalink raw reply related
* Re: [RFC] Zit: the git-based single file content tracker
From: Johannes Sixt @ 2008-10-23 13:03 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git
In-Reply-To: <gdok16$vh2$1@ger.gmane.org>
Giuseppe Bilotta schrieb:
> Zit will create a directory .zit.file to hold a git repository
> tracking the single file .zit.file/file, which is just a hard link to
> file.
git breaks hard links, mind you! (Just in case you check out older
versions and you wonder why your "real" file is not updated).
But there's a recent patch by Dscho floating around that takes care of the
hard link case.
-- Hannes
^ permalink raw reply
* Re: git performance
From: Nguyen Thai Ngoc Duy @ 2008-10-23 13:04 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Jakub Narebski, Edward Ned Harvey, git
In-Reply-To: <49002B27.50201@op5.se>
On 10/23/08, Andreas Ericsson <ae@op5.se> wrote:
> Jakub Narebski wrote:
>
> > "Edward Ned Harvey" <git@nedharvey.com> writes:
> >
> >
> > > I see things all over the Internet saying git is fast. I'm
> > > currently struggling with poor svn performance and poor attitude of
> > > svn developers, so I'd like to consider switching to git. A quick
> > > question first.
> > >
> > > The core of the performance problem I'm facing is the need to "walk
> > > the tree" for many thousand files. Every time I do "svn update" or
> > > "svn status" the svn client must stat every file to check for local
> > > modifications (a coffee cup or a beer worth of stats). In essence,
> > > this is unavoidable if there is no mechanism to constantly monitor
> > > filesystem activity during normal operations. Analogous to
> > > filesystem journaling.
> > >
> > > So - I didn't see anything out there saying "git is fast because it
> > > uses inotify" or anything like that. Perhaps git would not help me
> > > at all? Because git still needs to stat all the files in the tree?
> > >
> >
> > http://git.or.cz/gitwiki/GitBenchmarks
> >
> > While it should be possible to use 'assume unchanged' bit together
> > with inotify / icron, it is not something tha is done; IIRC Mercurial
> > had Linux-only InotifyPlugin...
> >
> >
>
> Well, inotify() is Linux specific, so it'd be quite hard to support on
> another platform. Emulating it with a billion stat() calls feels rather
> like a disk (and I/O performance) killer.
There is "filemon" on Windows, which monitors file access. I don't
know how it impacts performance though. A quick search revealed kqueue
for FreeBSD/Mac OSX.
--
Duy
^ permalink raw reply
* [PATCH] Only update the cygwin-related configuration during state auto-setup
From: Alex Riesen @ 2008-10-23 13:07 UTC (permalink / raw)
To: Mark Levedahl; +Cc: gitster, spearce, dpotapov, git
[-- Attachment #1: Type: text/plain, Size: 1506 bytes --]
Otherwise the other global settings which were already read and set up will
be overwritten because the auto-setup code can be called really late in
game. For instance, t3901-i18n-patch and --encoding=something of revision
argument parser are actually broken at the moment. The parser
(handle_revision_opt) sets git_log_output_encoding, which is also updated
(or in this case - overwritten) in the default config handler.
The code still has the problem if someone loads the configuration,
sets trust_executable_bit according to other conditions (a future
command-line option, perhaps) and than causes the init_stat call.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
compat/cygwin.c | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
2008/10/13 Mark Levedahl <mlevedahl@gmail.com>:
> static int git_cygwin_config(const char *var, const char *value, void *cb)
> {
> - if (!strcmp(var, "core.ignorecygwinfstricks"))
> - native_stat = git_config_bool(var, value);
> - return 0;
> + if (!strcmp(var, "core.ignorecygwinfstricks")) {
> + native_stat = git_config_bool(var, value);
> + return 0;
> + }
> + return git_default_config(var, value, cb);
> }
This actually breaks t3901-i18n-patch (and --encoding=something of
revision argument parser). The parser (handle_revision_opt) sets
git_log_output_encoding, which is also updated (or in this case - overwritten)
in the default config handler.
[-- Attachment #2: 0001-Only-update-the-cygwin-related-configuration-during.patch --]
[-- Type: application/xxxxx, Size: 1669 bytes --]
^ permalink raw reply
* Re: [RFC] Zit: the git-based single file content tracker
From: Giuseppe Bilotta @ 2008-10-23 13:28 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <49007623.1060606@viscovery.net>
On Thu, Oct 23, 2008 at 3:03 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> Giuseppe Bilotta schrieb:
>> Zit will create a directory .zit.file to hold a git repository
>> tracking the single file .zit.file/file, which is just a hard link to
>> file.
>
> git breaks hard links, mind you! (Just in case you check out older
> versions and you wonder why your "real" file is not updated).
>
> But there's a recent patch by Dscho floating around that takes care of the
> hard link case.
I feared that the hardlink choice was not the best one. I would
definitely prefer finding a solution that didn't depend on hardlinks:
not only there would be no worry about breaking them, it'd also be
more portable.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: [RFC] Zit: the git-based single file content tracker
From: Giuseppe Bilotta @ 2008-10-23 13:33 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <fcaeb9bf0810230550t54813c09m3b1984f065732c0@mail.gmail.com>
On Thu, Oct 23, 2008 at 2:50 PM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> On 10/23/08, Giuseppe Bilotta <giuseppe.bilotta@gmail.com> wrote:
>> The principle is extremely simple: when you choose to start tracking a
>> file with Zit,
>>
>> zit track file
>>
>> Zit will create a directory .zit.file to hold a git repository
>> tracking the single file .zit.file/file, which is just a hard link to
>> file.
>
> Why not use one .zit repo and track each file on each own branch?.
So your proposal is to have a single .zit repo which is actually a git
repo and where each additional tracked file becomes its own branch,
and zit would take care of switching from branch to branch when zit
commands are called?
I think this solution would have a number of problems, apart from
being generally quite messy. First of all, moving a file and its
history somewhere else means toying around with the history of a much
wider repo, whereas the current approach would mean just moving the
.zit.file dir together with the file (modulo hardlinks). Non-linear
histories for a single file would be more complex to handle, too. And
publishing just the history of one file would be damn complex.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: [RFC] Zit: the git-based single file content tracker
From: Nguyen Thai Ngoc Duy @ 2008-10-23 13:51 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git
In-Reply-To: <cb7bb73a0810230633r9970a50mbb4ecf3a855c3a21@mail.gmail.com>
On 10/23/08, Giuseppe Bilotta <giuseppe.bilotta@gmail.com> wrote:
> On Thu, Oct 23, 2008 at 2:50 PM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> > On 10/23/08, Giuseppe Bilotta <giuseppe.bilotta@gmail.com> wrote:
> >> The principle is extremely simple: when you choose to start tracking a
> >> file with Zit,
> >>
> >> zit track file
> >>
> >> Zit will create a directory .zit.file to hold a git repository
> >> tracking the single file .zit.file/file, which is just a hard link to
> >> file.
> >
> > Why not use one .zit repo and track each file on each own branch?.
>
>
> So your proposal is to have a single .zit repo which is actually a git
> repo and where each additional tracked file becomes its own branch,
> and zit would take care of switching from branch to branch when zit
> commands are called?
I don't know if switching is necessary. With one file per pranch, the
index is even not necessary.
> I think this solution would have a number of problems, apart from
> being generally quite messy. First of all, moving a file and its
> history somewhere else means toying around with the history of a much
> wider repo, whereas the current approach would mean just moving the
> .zit.file dir together with the file (modulo hardlinks). Non-linear
> histories for a single file would be more complex to handle, too. And
> publishing just the history of one file would be damn complex.
The history should be linear. Git (or zit) repository is just a
container for git branches. Each branch contains only one file. Moving
a file history is equivalent to "git push" + "git branch -D".
Something like this (not tested):
cd dst
git init
cd src
git push dst local-branch:remote-branch
git branch -D local-branch
git gc
> --
> Giuseppe "Oblomov" Bilotta
>
--
Duy
^ 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