* Re: [PATCH] grep: do not do external grep on skip-worktree entries
From: Jeff King @ 2010-01-04 6:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Miles Bader, Nguyen Thai Ngoc Duy, git
In-Reply-To: <7vbphaquwl.fsf@alter.siamese.dyndns.org>
On Sun, Jan 03, 2010 at 09:52:10PM -0800, Junio C Hamano wrote:
> > I agree that Solaris default tools are insane, but is there any reason
> > to munge the PATH for a single feature like external grep? Why not
> > EXTERNAL_GREP=/usr/xpg4/bin/grep (or /usr/local/bin/grep) in the
> > Makefile? Why not GIT_EXTERNAL_GREP=$HOME/bin/grep in the environment?
>
> That git-sh-setup "fix" is not for running external grep. It is for our
> scripted Porcelains that rely on working basic tools (sed, tr, who knows
> what else is broken).
Right, but I thought this thread was about external grep, and I thought
you were saying "if you want decent tools, you can use SANE_TOOL_PATH".
And I think we can do much better for that particular case than
recommending SANE_TOOL_PATH (but it seems that is not what you were
actually recommending).
But I admit, I have never really wanted to specify my own external grep.
Wanting your own grep for _features_ is probably insane, as some of your
greps (on worktree files) will use the external grep, and some (on
cached files) will not. So it is really just an optimization, and I
have never felt it so slow that I cared about messing with an
alternative grep on Solaris.
I have to wonder, though...did anybody ever actually profile our
internal grep to find out _why_ it was so much slower than GNU grep?
Could we simply ship a better grep engine and obsolete external grep?
> In fact, our Makefile by default punts on external grep on Sun's. Run
> "git grep NO_EXTERNAL_GREP -- Makefile" to see for yourself --- it would
> work even on Solaris ;-)
Yes, I am even mentioned in the commit log of 01ae841c. :)
-Peff
^ permalink raw reply
* A question about changing remote repo name
From: Dongas @ 2010-01-04 6:45 UTC (permalink / raw)
To: git
Hi ALL,
I'm running ubuntu 9.04 and the git coming along with it doesn't
support git remote rename command.
Below is the man page of it:
GIT-REMOTE(1)
Git Manual
GIT-REMOTE(1)
NAME
git-remote - manage set of tracked repositories
SYNOPSIS
git remote [-v | --verbose]
git remote add [-t <branch>] [-m <master>] [-f] [--mirror]
<name> <url>
git remote rm <name>
git remote show [-n] <name>
git remote prune [-n | --dry-run] <name>
git remote update [group]
Note: There's no rename option.
So i need to change the remote name manually.
I tried modifying the .git/config file locally but it didn't work.
Could someone help tell how to do it?
Thanks
Regards
Dongas
^ permalink raw reply
* Re: [PATCH] grep: do not do external grep on skip-worktree entries
From: Jeff King @ 2010-01-04 7:04 UTC (permalink / raw)
To: Mike Hommey
Cc: Linus Torvalds, Miles Bader, Junio C Hamano, Nguyen Thai Ngoc Duy,
git
In-Reply-To: <20100104060646.GA14520@glandium.org>
On Mon, Jan 04, 2010 at 07:06:46AM +0100, Mike Hommey wrote:
> Anyways, why not generate the hash-bang lines of the shell scripts from a
> Makefile variable that would be set to /usr/xpg4/bin/sh on Solaris and
> /bin/sh on others ?
We do that already (though we default it to /bin/bash). SANE_TOOL_PATH
is about picking up all the _other_ tools for use inside our shell
scripts, like non-crappy sed, grep, etc.
Brandon did some testing with ksh and sent a patch to default to the
stock ksh on Solaris and IRIX, which is probably saner than bash for a
default, but it seems to have gotten dropped:
http://article.gmane.org/gmane.comp.version-control.git/129830
-Peff
^ permalink raw reply
* Re: [PATCH] grep: do not do external grep on skip-worktree entries
From: Junio C Hamano @ 2010-01-04 7:08 UTC (permalink / raw)
To: Jeff King; +Cc: Linus Torvalds, Miles Bader, Nguyen Thai Ngoc Duy, git
In-Reply-To: <20100104064408.GA7785@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I have to wonder, though...did anybody ever actually profile our
> internal grep to find out _why_ it was so much slower than GNU grep?
I vaguely recall that somebody fairly competent mentioned that modern grep
implementations are based on DFA engines, but I offhand don't remember if
the discussion had concrete numbers.
> Could we simply ship a better grep engine and obsolete external grep?
Yes, that is a very constructive longer term solution.
^ permalink raw reply
* Re: [PATCH] grep: do not do external grep on skip-worktree entries
From: Junio C Hamano @ 2010-01-04 7:14 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jeff King, Linus Torvalds, Miles Bader, Nguyen Thai Ngoc Duy, git
In-Reply-To: <7vhbr2pcsh.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Jeff King <peff@peff.net> writes:
>
>> I have to wonder, though...did anybody ever actually profile our
>> internal grep to find out _why_ it was so much slower than GNU grep?
>
> I vaguely recall that somebody fairly competent mentioned that modern grep
> implementations are based on DFA engines, but I offhand don't remember if
> the discussion had concrete numbers.
I found only this one. The author was indeed somebody fairly competent.
http://thread.gmane.org/gmane.comp.version-control.git/23798
^ permalink raw reply
* Re: [PATCH] grep: do not do external grep on skip-worktree entries
From: Jeff King @ 2010-01-04 7:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Miles Bader, Nguyen Thai Ngoc Duy, git
In-Reply-To: <7vhbr2pcsh.fsf@alter.siamese.dyndns.org>
On Sun, Jan 03, 2010 at 11:08:46PM -0800, Junio C Hamano wrote:
> > I have to wonder, though...did anybody ever actually profile our
> > internal grep to find out _why_ it was so much slower than GNU grep?
>
> I vaguely recall that somebody fairly competent mentioned that modern grep
> implementations are based on DFA engines, but I offhand don't remember if
> the discussion had concrete numbers.
Probably this:
http://article.gmane.org/gmane.comp.version-control.git/41685
Also of interest is:
http://article.gmane.org/gmane.comp.version-control.git/50174
The pcre analysis there came from just using the "pcreposix" header, I
think. From my limited research, modern pcre may have some tuning
options (including a DFA engine!) that could do a lot better.
-Peff
^ permalink raw reply
* Re: [PATCH] grep: do not do external grep on skip-worktree entries
From: Jeff King @ 2010-01-04 7:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Miles Bader, Nguyen Thai Ngoc Duy, git
In-Reply-To: <7v4on2pciw.fsf@alter.siamese.dyndns.org>
On Sun, Jan 03, 2010 at 11:14:31PM -0800, Junio C Hamano wrote:
> > I vaguely recall that somebody fairly competent mentioned that modern grep
> > implementations are based on DFA engines, but I offhand don't remember if
> > the discussion had concrete numbers.
>
> I found only this one. The author was indeed somebody fairly competent.
>
> http://thread.gmane.org/gmane.comp.version-control.git/23798
Er, that link seems to be about internal grep beating external on a cold
cache because it does less I/O. Did you mean something else (maybe the
thread I pointed to in another message)?
-Peff
^ permalink raw reply
* Re: [PATCH] grep: do not do external grep on skip-worktree entries
From: Jeff King @ 2010-01-04 8:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Miles Bader, Nguyen Thai Ngoc Duy, git
In-Reply-To: <20100104072659.GA10611@coredump.intra.peff.net>
On Mon, Jan 04, 2010 at 02:26:59AM -0500, Jeff King wrote:
> The pcre analysis there came from just using the "pcreposix" header, I
> think. From my limited research, modern pcre may have some tuning
> options (including a DFA engine!) that could do a lot better.
Hmm. I was able to get some improvements by using pcre_dfa_exec, but
still not as good as external grep. For "git grep 'foo.*bar'" in the
linux-2.6 repo, I got:
external grep: 0.76s
pcre_dfa_exec: 1.85s
pcre_exec: 3.21s
glibc: 4.00s
However, gprof reports that for the pcre dfa case, we spend more time in
grep.c:end_of_line than we do actually running the regex. So clearly
there are some other micro-optimizations in GNU grep that are making a
difference, too.
By the way, you can see the abysmal performance of our internal code by
doing a "git grep foo". It uses the "fixed" internal engine and weighs
in at 3.24s on the same machine, _slower_ than pcre doing an actual
regex.
-Peff
^ permalink raw reply
* What's cooking in git.git (Jan 2010, #01; Mon, 04)
From: Junio C Hamano @ 2010-01-04 8:39 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 ones
marked with '.' do not appear in any of the integration branches, but I am
still holding onto them.
The tip of 'next' has been rebuilt on top of the current 'master'.
--------------------------------------------------
[New Topics]
* da/difftool (2009-12-22) 2 commits
- git-difftool: Add '--gui' for selecting a GUI tool
- t7800-difftool: Set a bogus tool for use by tests
* jh/gitweb-cached (2010-01-03) 4 commits
- gitweb: Makefile improvements
- gitweb: Optionally add "git" links in project list page
- gitweb: Add option to force version match
- gitweb: Load checking
* tc/test-locate-httpd (2010-01-02) 1 commit
- t/lib-http.sh: Restructure finding of default httpd location
* jc/fix-tree-walk (2009-09-14) 7 commits
- read-tree --debug-unpack
- unpack-trees.c: look ahead in the index
- unpack-trees.c: prepare for looking ahead in the index
- Aggressive three-way merge: fix D/F case
- traverse_trees(): handle D/F conflict case sanely
- more D/F conflict tests
- tests: move convenience regexp to match object names to test-lib.sh
Resurrected from "Ejected" category.
--------------------------------------------------
[Cooking]
* cc/reset-more (2010-01-04) 6 commits
(merged to 'next' on 2010-01-04 at 8802c2c)
+ Fix bit assignment for CE_CONFLICTED
(merged to 'next' on 2010-01-03 at f83d4c6)
+ "reset --merge": fix unmerged case
+ reset: use "unpack_trees()" directly instead of "git read-tree"
+ reset: add a few tests for "git reset --merge"
+ Documentation: reset: add some tables to describe the different options
+ reset: improve mixed reset error message when in a bare repo
* bg/maint-remote-update-default (2009-12-31) 1 commit
(merged to 'next' on 2010-01-03 at 113009e)
+ Fix "git remote update" with remotes.defalt set
* jc/branch-d (2009-12-29) 1 commit
- branch -d: base the "already-merged" safety on the branch it merges with
* jc/rerere (2009-12-04) 1 commit
- Teach --[no-]rerere-autoupdate option to merge, revert and friends
* jk/maint-1.6.5-reset-hard (2009-12-30) 1 commit
(merged to 'next' on 2010-01-02 at 190d63b)
+ reset: unbreak hard resets with GIT_WORK_TREE
* jk/push-to-delete (2009-12-30) 1 commit
(merged to 'next' on 2010-01-03 at 9ee293b)
+ builtin-push: add --delete as syntactic sugar for :foo
* jk/run-command-use-shell (2010-01-01) 8 commits
- t4030, t4031: work around bogus MSYS bash path conversion
- t0021: use $SHELL_PATH for the filter script
- diff: run external diff helper with shell
- textconv: use shell to run helper
- editor: use run_command's shell feature
- run-command: optimize out useless shell calls
- run-command: convert simple callsites to use_shell
- run-command: add "use shell" option
* mm/config-path (2009-12-30) 1 commit
(merged to 'next' on 2010-01-03 at 9c0e81a)
+ builtin-config: add --path option doing ~ and ~user expansion.
* pm/cvs-environ (2009-12-30) 1 commit
(merged to 'next' on 2010-01-03 at 4c22932)
+ CVS Server: Support reading base and roots from environment
* rs/maint-archive-match-pathspec (2009-12-12) 1 commit
(merged to 'next' on 2010-01-03 at 92d7d15)
+ archive: complain about path specs that don't match anything
* so/cvsserver-update (2009-12-07) 1 commit
(merged to 'next' on 2010-01-03 at 99959b6)
+ cvsserver: make the output of 'update' more compatible with cvs.
* tc/clone-v-progress (2009-12-26) 4 commits
- clone: use --progress to force progress reporting
- clone: set transport->verbose when -v/--verbose is used
- git-clone.txt: reword description of progress behaviour
- check stderr with isatty() instead of stdout when deciding to show progress
* tc/smart-http-restrict (2010-01-02) 4 commits
- Smart-http tests: Test http-backend without curl or a webserver
- Smart-http tests: Break test t5560-http-backend into pieces
- Smart-http tests: Improve coverage in test t5560
- Smart-http: check if repository is OK to export before serving it
* tr/maint-1.6.5-bash-prompt-show-submodule-changes (2009-12-31) 1 commit
(merged to 'next' on 2010-01-03 at b785974)
+ bash completion: factor submodules into dirty state
* jc/cache-unmerge (2009-12-25) 9 commits
- rerere forget path: forget recorded resolution
- rerere: refactor rerere logic to make it independent from I/O
- rerere: remove silly 1024-byte line limit
- resolve-undo: teach "update-index --unresolve" to use resolve-undo info
- resolve-undo: "checkout -m path" uses resolve-undo information
- resolve-undo: allow plumbing to clear the information
- resolve-undo: basic tests
- resolve-undo: record resolved conflicts in a new index extension section
- builtin-merge.c: use standard active_cache macros
* js/filter-branch-prime (2009-12-15) 1 commit
(merged to 'next' on 2010-01-03 at 7c90319)
+ filter-branch: remove an unnecessary use of 'git read-tree'
* mg/tag-d-show (2009-12-10) 1 commit
(merged to 'next' on 2010-01-03 at 87657d2)
+ tag -d: print sha1 of deleted tag
* sb/maint-octopus (2009-12-11) 3 commits
(merged to 'next' on 2010-01-03 at ffe77d6)
+ octopus: remove dead code
+ octopus: reenable fast-forward merges
+ octopus: make merge process simpler to follow
* jh/commit-status (2009-12-07) 1 commit
- [test?] Add commit.status, --status, and --no-status
* jc/checkout-merge-base (2009-11-20) 2 commits
(merged to 'next' on 2010-01-02 at 6a8f6fc)
+ "rebase --onto A...B" replays history on the merge base between A and B
+ "checkout A...B" switches to the merge base between A and B
* tr/http-push-ref-status (2009-12-24) 6 commits
- transport-helper.c::push_refs(): emit "no refs" error message
- transport-helper.c::push_refs(): ignore helper-reported status if ref is not to be pushed
- transport.c::transport_push(): make ref status affect return value
- refactor ref status logic for pushing
- t5541-http-push.sh: add test for unmatched, non-fast-forwarded refs
- t5541-http-push.sh: add tests for non-fast-forward pushes
* bg/maint-add-all-doc (2009-12-07) 4 commits
(merged to 'next' on 2010-01-03 at b19a323)
+ squash! rm documentation--also mention add-u where we mention commit-a
+ git-rm doc: Describe how to sync index & work tree
+ git-add/rm doc: Consistently back-quote
+ Documentation: 'git add -A' can remove files
* il/vcs-helper (2009-12-09) 8 commits
- Remove special casing of http, https and ftp
- Support remote archive from all smart transports
- Support remote helpers implementing smart transports
- Support taking over transports
- Refactor git transport options parsing
- Pass unknown protocols to external protocol handlers
- Support mandatory capabilities
- Add remote helper debug mode
* mm/diag-path-in-treeish (2009-12-07) 1 commit
- Detailed diagnosis when parsing an object name fails.
* mh/rebase-fixup (2009-12-07) 2 commits
- Add a command "fixup" to rebase --interactive
- t3404: Use test_commit to set up test repository
(this branch is used by ns/rebase-auto-squash.)
Initial round of "fixup" action that is similar to "squash" action in
"rebase -i" that excludes the commit log message from follow-up commits
when composing the log message for the updated one. Expected is a further
improvement to skip opening the editor if a pick is followed only by
"fixup" and no "squash".
* ns/rebase-auto-squash (2009-12-08) 2 commits
- fixup! rebase -i --autosquash
- rebase -i --autosquash: auto-squash commits
(this branch uses mh/rebase-fixup.)
* jh/notes (2009-12-07) 11 commits
- Refactor notes concatenation into a flexible interface for combining notes
- Notes API: Allow multiple concurrent notes trees with new struct notes_tree
- Notes API: for_each_note(): Traverse the entire notes tree with a callback
- Notes API: get_note(): Return the note annotating the given object
- Notes API: add_note(): Add note objects to the internal notes tree structure
- Notes API: init_notes(): Initialize the notes tree from the given notes ref
- Notes API: get_commit_notes() -> format_note() + remove the commit restriction
- Minor style fixes to notes.c
(merged to 'next' on 2010-01-02 at ae42130)
+ Add more testcases to test fast-import of notes
+ Rename t9301 to t9350, to make room for more fast-import tests
+ fast-import: Proper notes tree manipulation
* fc/opt-quiet-gc-reset (2009-12-02) 1 commit
- General --quiet improvements
* mv/commit-date (2009-12-03) 2 commits
(merged to 'next' on 2010-01-03 at 1c45fdf)
+ Document date formats accepted by parse_date()
+ builtin-commit: add --date option
* sr/gfi-options (2009-12-04) 7 commits
- fast-import: add (non-)relative-marks feature
- fast-import: allow for multiple --import-marks= arguments
- fast-import: test the new option command
- fast-import: add option command
- fast-import: add feature command
- fast-import: put marks reading in its own function
- fast-import: put option parsing code in separate functions
* ap/merge-backend-opts (2008-07-18) 6 commits
- Document that merge strategies can now take their own options
- Extend merge-subtree tests to test -Xsubtree=dir.
- Make "subtree" part more orthogonal to the rest of merge-recursive.
- Teach git-pull to pass -X<option> to git-merge
- git merge -X<option>
- git-merge-file --ours, --theirs
"git pull" patch needs sq-then-eval fix to protect it from $IFS
but otherwise seemed good.
* mo/bin-wrappers (2009-12-02) 3 commits
(merged to 'next' on 2010-01-03 at 8c5fa27)
+ INSTALL: document a simpler way to run uninstalled builds
+ run test suite without dashed git-commands in PATH
+ build dashless "bin-wrappers" directory similar to installed bindir
* tr/http-updates (2009-12-28) 4 commits
(merged to 'next' on 2010-01-02 at cf25698)
+ Remove http.authAny
+ Allow curl to rewind the RPC read buffer
+ Add an option for using any HTTP authentication scheme, not only basic
+ http: maintain curl sessions
* nd/sparse (2009-12-30) 23 commits
(merged to 'next' on 2010-01-02 at 5499bbe)
+ grep: do not do external grep on skip-worktree entries
+ commit: correctly respect skip-worktree bit
+ ie_match_stat(): do not ignore skip-worktree bit with CE_MATCH_IGNORE_VALID
+ tests: rename duplicate t1009
+ sparse checkout: inhibit empty worktree
+ Add tests for sparse checkout
+ read-tree: add --no-sparse-checkout to disable sparse checkout support
+ unpack-trees(): ignore worktree check outside checkout area
+ unpack_trees(): apply $GIT_DIR/info/sparse-checkout to the final index
+ unpack-trees(): "enable" sparse checkout and load $GIT_DIR/info/sparse-checkout
+ unpack-trees.c: generalize verify_* functions
+ unpack-trees(): add CE_WT_REMOVE to remove on worktree alone
+ Introduce "sparse checkout"
+ dir.c: export excluded_1() and add_excludes_from_file_1()
+ excluded_1(): support exclude files in index
+ unpack-trees(): carry skip-worktree bit over in merged_entry()
+ Read .gitignore from index if it is skip-worktree
+ Avoid writing to buffer in add_excludes_from_file_1()
+ Teach Git to respect skip-worktree bit (writing part)
+ Teach Git to respect skip-worktree bit (reading part)
+ Introduce "skip-worktree" bit in index, teach Git to get/set this bit
+ Add test-index-version
+ update-index: refactor mark_valid() in preparation for new options
^ permalink raw reply
* Re: RFC: display dirty submodule working directory in git gui and gitk
From: Johannes Schindelin @ 2010-01-04 9:44 UTC (permalink / raw)
To: Jens Lehmann
Cc: Git Mailing List, Junio C Hamano, Shawn O. Pearce, Paul Mackerras,
Heiko Voigt, Lars Hjemli
In-Reply-To: <4B3F6742.6060402@web.de>
Hi,
On Sat, 2 Jan 2010, Jens Lehmann wrote:
> Now that we have much better output when displaying diffs of submodules
> in git gui and gitk (many thanks to all involved!), another usability
> issue shows up: A dirty working directory of a submodule isn't visible
> in git gui or gitk.
>
> So you might think a "submodule update" would be ok - as you see no
> changes - just too see it fail because the submodules working directory
> is dirty.
>
> Or - even worse - you /think/ you committed your changes in a submodule
> while you didn't. That can lead to 'interesting' problems which can be
> pretty hard to diagnose (like breaking builds on other peoples
> machines).
>
>
> A possible solution could look like this:
>
> AFAICS, git gui and gitk use "git diff-files" both to get the file names
> of unstaged local changes and to later display the actual differences.
>
> If they could tell the diff core to also check the submodule working
> directories and to output an extra line - maybe something like
> "Submodule <name> contains uncommitted local changes" - when a
> submodules working directory is dirty, git gui and gitk could show the
> submodules state adequately.
The real problem is that submodules in the current form are not very well
designed. For example, a submodule being at a different commit than in
the superproject's index is not as fatal as the submodule having changes.
So in the long run, IMHO a proper redesign of the submodules would not
make only a little sense (it does not help, though, that those who
implemented and furthered the current approach over other discussed
approaches do not use submodules themselves -- not even now).
In ths short run, we can paper over the shortcomings of the submodules by
introducing a command line option "--include-submodules" to
update-refresh, diff-files and diff-index, though.
The implementation might be a bit tricky as parts of Git's source code
still use the_index, but at least adding the submodule's object database
is no longer that difficult.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] grep: do not do external grep on skip-worktree entries
From: Nguyen Thai Ngoc Duy @ 2010-01-04 10:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Linus Torvalds, Miles Bader, git
In-Reply-To: <7vbphaquwl.fsf@alter.siamese.dyndns.org>
On Mon, Jan 4, 2010 at 12:52 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> I agree that Solaris default tools are insane, but is there any reason
>> to munge the PATH for a single feature like external grep? Why not
>> EXTERNAL_GREP=/usr/xpg4/bin/grep (or /usr/local/bin/grep) in the
>> Makefile? Why not GIT_EXTERNAL_GREP=$HOME/bin/grep in the environment?
>
> That git-sh-setup "fix" is not for running external grep. It is for our
> scripted Porcelains that rely on working basic tools (sed, tr, who knows
> what else is broken).
>
> In fact, our Makefile by default punts on external grep on Sun's. Run
> "git grep NO_EXTERNAL_GREP -- Makefile" to see for yourself --- it would
> work even on Solaris ;-)
A bit off-topic. But it seems to me on linux (main development
platform?) GNU grep may be tested more than the builtin grep because
NO_EXTERNAL_GREP would be undefined by default. Should we test both
greps in that case?
--
Duy
^ permalink raw reply
* Re: [PATCH] git-update-index: report(...) now flushes stdout after printing the report line
From: Sebastian Thiel @ 2010-01-04 10:30 UTC (permalink / raw)
Cc: git
In-Reply-To: <be6fef0d1001031503h11cb65c6ha34eee345b9b7055@mail.gmail.com>
Thanks Ray Chuan, for the clarification, the progress is supposed to
be sent in git-push and git-fetch ( not git-pull as I mentioned ).
A --progress flag would already do it for me, is there a way to fetch
your code from somewhere for a test run ?
When do you think will your changes be available for a mainline merge,
or would it even be possible to separate the --progress adjustment
from your feature to merge it into mainline individually ?
Thanks,
Sebastian
^ permalink raw reply
* Re: RFC: display dirty submodule working directory in git gui and gitk
From: Heiko Voigt @ 2010-01-04 10:44 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Jens Lehmann, Git Mailing List, Junio C Hamano, Shawn O. Pearce,
Paul Mackerras, Heiko Voigt, Lars Hjemli
In-Reply-To: <alpine.DEB.1.00.1001041038520.4985@pacific.mpi-cbg.de>
Hi,
Johannes wrote:
> The real problem is that submodules in the current form are not very well
> designed. For example, a submodule being at a different commit than in
> the superproject's index is not as fatal as the submodule having changes.
>
> So in the long run, IMHO a proper redesign of the submodules would not
> make only a little sense (it does not help, though, that those who
> implemented and furthered the current approach over other discussed
> approaches do not use submodules themselves -- not even now).
Do you mean the complete workflow (submodules are links to other git repos)
or the current implementation? Do you have links to other design
approaches/threads? Would be nice if we could take that into account for any
decision.
cheers Heiko
^ permalink raw reply
* submodules, was Re: RFC: display dirty submodule working directory in git gui and gitk
From: Johannes Schindelin @ 2010-01-04 11:46 UTC (permalink / raw)
To: Heiko Voigt
Cc: Jens Lehmann, Git Mailing List, Junio C Hamano, Shawn O. Pearce,
Paul Mackerras, Lars Hjemli
In-Reply-To: <61083.85.16.196.198.1262601871.squirrel@archive.darksea.de>
Hi,
On Mon, 4 Jan 2010, Heiko Voigt wrote:
> Johannes wrote:
> > The real problem is that submodules in the current form are not very
> > well designed. For example, a submodule being at a different commit
> > than in the superproject's index is not as fatal as the submodule
> > having changes.
> >
> > So in the long run, IMHO a proper redesign of the submodules would not
> > make only a little sense (it does not help, though, that those who
> > implemented and furthered the current approach over other discussed
> > approaches do not use submodules themselves -- not even now).
>
> Do you mean the complete workflow (submodules are links to other git
> repos) or the current implementation? Do you have links to other design
> approaches/threads? Would be nice if we could take that into account for
> any decision.
Unfortunately, I do not have any information about different approaches
except the approach Subversion takes. While Subversion's externals are
not perfect for all applications, for some, they are. So I consider this
a serious shortcoming that Git does not support that workflow (and in
fact, AFAIR Shawn's repo does not use submodules for that exact reason).
But I think that an important precondition to come up with a better design
of the submodules is to have suffered the current implementation in
real-world work using submodules. (Which reminds me very much of the
autocrlf mess.)
Ciao,
Dscho
^ permalink raw reply
* Beginner's question on how to use git for multiple parallel versions
From: Christian C. Schouten @ 2010-01-04 11:29 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1131 bytes --]
Hello all,
I’ve got a project that I want to do version management on with git but being a beginner in
cvs/svn/dvcs etc. terminology I don’t know yet how to set it up.
My project needs to exist as several parallel copies, i.e. there is a “main version” in
which I do my development but it needs to end up being available as a couple of different
configurations.
For instance, say there is a file table.xml then this needs to contain different rows for versions
A and B. Likewise, a file process.bpel needs to be named identical for each version but contain
different content depending on whether it is distributed as version A or version B. Any changes
made in non-version specific files should be visible in all copies, but changes made to
version-specific files need to remain isolated to that particular version.
I read about branching, merging, rebasing and cherry-picking commits but I don’t get it yet.
Can anyone enlighten me on how I should approach this in a way that I can maintain easily
throughout future development for my situation?
Thanks in advance for any pointers,
Best,
Chris
^ permalink raw reply
* [PATCH 2/2] t7002: add tests for skip-worktree fixes in commit a67e281
From: Nguyễn Thái Ngọc Duy @ 2010-01-04 12:34 UTC (permalink / raw)
To: Junio C Hamano, git; +Cc: Nguyễn Thái Ngọc Duy
In-Reply-To: <7v7hs09tpi.fsf@alter.siamese.dyndns.org>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
builtin-grep.c | 1 +
t/t7002-grep.sh | 12 ++++++++++++
2 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/builtin-grep.c b/builtin-grep.c
index f093b60..59c4b12 100644
--- a/builtin-grep.c
+++ b/builtin-grep.c
@@ -222,6 +222,7 @@ static int exec_grep(int argc, const char **argv)
int status;
argv[argc] = NULL;
+ trace_argv_printf(argv, "trace: grep:");
pid = fork();
if (pid < 0)
return pid;
diff --git a/t/t7002-grep.sh b/t/t7002-grep.sh
index ffda0df..ac0a658 100755
--- a/t/t7002-grep.sh
+++ b/t/t7002-grep.sh
@@ -438,4 +438,16 @@ test_expect_success 'grep -Fi' '
test_cmp expected actual
'
+test_expect_success external-grep 'external grep is called' '
+ GIT_TRACE=2 git grep foo >/dev/null 2>actual &&
+ grep "trace: grep:.*foo" actual >/dev/null
+'
+
+test_expect_success external-grep 'no external grep when skip-worktree entries exist' '
+ git update-index --skip-worktree file &&
+ GIT_TRACE=2 git grep foo >/dev/null 2>actual &&
+ ! grep "trace: grep:" actual >/dev/null &&
+ git update-index --no-skip-worktree file
+'
+
test_done
--
1.6.6.315.g1a406
^ permalink raw reply related
* [PATCH 1/2] t7002: set test prerequisite "external-grep" if supported
From: Nguyễn Thái Ngọc Duy @ 2010-01-04 12:34 UTC (permalink / raw)
To: Junio C Hamano, git; +Cc: Nguyễn Thái Ngọc Duy
In-Reply-To: <7v7hs09tpi.fsf@alter.siamese.dyndns.org>
Add another test to set prerequisite "external-grep" if the current
build supports external grep. This can be used to skip external grep
only tests on builds that do not support this optimization.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
t/t7002-grep.sh | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/t/t7002-grep.sh b/t/t7002-grep.sh
index abd14bf..ffda0df 100755
--- a/t/t7002-grep.sh
+++ b/t/t7002-grep.sh
@@ -8,6 +8,18 @@ test_description='git grep various.
. ./test-lib.sh
+test_expect_success 'Check for external grep support' '
+ case "$(git grep -h 2>&1|grep ext-grep)" in
+ *"(default)"*)
+ test_set_prereq external-grep
+ true;;
+ *"(ignored by this build)"*)
+ true;;
+ *)
+ false;;
+ esac
+'
+
cat >hello.c <<EOF
#include <stdio.h>
int main(int argc, const char **argv)
--
1.6.6.315.g1a406
^ permalink raw reply related
* Re: Beginner's question on how to use git for multiple parallel versions
From: Bill Lear @ 2010-01-04 13:29 UTC (permalink / raw)
To: Christian C. Schouten; +Cc: git
In-Reply-To: <F8CC469C9CCA415696101414EA997C0.MAI@sohosted19.com>
On Monday, January 4, 2010 at 12:29:52 (+0100) Christian C. Schouten writes:
>Hello all,
>
>I've got a project that I want to do version management on with
>git but being a beginner in cvs/svn/dvcs etc. terminology I
>don't know yet how to set it up. My project needs to exist as
>several parallel copies, i.e. there is a "main version" in
>which I do my development but it needs to end up being available as a
>couple of different configurations. For instance, say there is a file
>table.xml then this needs to contain different rows for versions A and
>B. Likewise, a file process.bpel needs to be named identical for each
>version but contain different content depending on whether it is
>distributed as version A or version B. Any changes made in non-version
>specific files should be visible in all copies, but changes made to
>version-specific files need to remain isolated to that particular
>version.
What you are asking for is this, I think:
% git checkout A
% cat table.xml
<table A>
% echo "<table A v2>" > table.xml
% git commit -a -m "fix table on Branch A"
% git checkout B
% cat table.xml
<table B>
% echo "<table B v2>" > table.xml
% git commit -a -m "fix table on Branch B"
% git checkout master
% cat table.xml
<non-version-specific table info>
% cat process.bpel
main line process stuff
% echo "add more process stuff" >> process.bpel
% git commit -a -m "fix process stuff on mainline"
% git checkout A
% git merge master
% cat process.bpel
main line process stuff
add more process stuff
% git checkout B
% git merge master
% cat process.bpel
main line process stuff
add more process stuff
Is that not it?
Bill
^ permalink raw reply
* RE: Beginner's question on how to use git for multiple parallel versions
From: Christian C. Schouten @ 2010-01-04 13:35 UTC (permalink / raw)
To: git
In-Reply-To: <19265.60728.17437.665860@blake.zopyra.com>
Dear Bill,
Thanks for your prompt reply. It may very well be exactly what I need, but
I'm afraid that I don't understand the syntax just yet (am still in the
phase orienting on what version management is and how it should be set up).
Could you please add to your answer whether I am using branches or another
git technique (terminology?) and whether these are instructions that I can
use to commit a change once the system has already been set up or if these
actually are the instructions for defining the multiplicity of my project
versions?
Sorry for the newbie-ness and thanks in advance,
Best,
Chris
-----Original Message-----
From: Bill Lear [mailto:rael@zopyra.com]
Sent: maandag 4 januari 2010 14:29
To: Christian C. Schouten
Cc: git@vger.kernel.org
Subject: Re: Beginner's question on how to use git for multiple parallel
versions
On Monday, January 4, 2010 at 12:29:52 (+0100) Christian C. Schouten writes:
>Hello all,
>
>I've got a project that I want to do version management on with
>git but being a beginner in cvs/svn/dvcs etc. terminology I
>don't know yet how to set it up. My project needs to exist as
>several parallel copies, i.e. there is a "main version" in
>which I do my development but it needs to end up being available as a
>couple of different configurations. For instance, say there is a file
>table.xml then this needs to contain different rows for versions A and
>B. Likewise, a file process.bpel needs to be named identical for each
>version but contain different content depending on whether it is
>distributed as version A or version B. Any changes made in non-version
>specific files should be visible in all copies, but changes made to
>version-specific files need to remain isolated to that particular
>version.
What you are asking for is this, I think:
% git checkout A
% cat table.xml
<table A>
% echo "<table A v2>" > table.xml
% git commit -a -m "fix table on Branch A"
% git checkout B
% cat table.xml
<table B>
% echo "<table B v2>" > table.xml
% git commit -a -m "fix table on Branch B"
% git checkout master
% cat table.xml
<non-version-specific table info>
% cat process.bpel
main line process stuff
% echo "add more process stuff" >> process.bpel
% git commit -a -m "fix process stuff on mainline"
% git checkout A
% git merge master
% cat process.bpel
main line process stuff
add more process stuff
% git checkout B
% git merge master
% cat process.bpel
main line process stuff
add more process stuff
Is that not it?
Bill
^ permalink raw reply
* Re: [PATCH v3] Smart-http documentation: add example of how to execute from userdir
From: Shawn O. Pearce @ 2010-01-04 14:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Tay Ray Chuan, git, Tarmigan Casebolt
In-Reply-To: <7vzl4v1t91.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> Tarmigan Casebolt <tarmigan+git@gmail.com> writes:
>
> > Smart-http may be an attactive and easy way for people to setup git
> > hosting on shared servers whose primary web server configuration they
> > do not control. To facilite this, provide an example of how it may be
> > done.
> >
> > cc: Tay Ray Chuan <rctay89@gmail.com>
> > cc: Shawn O. Pearce <spearce@spearce.org>
> > Editing-by: Tay Ray Chuan <rctay89@gmail.com>
> > Signed-off-by: Tarmigan Casebolt <tarmigan+git@gmail.com>
>
> I still see Cc: here; are people named above (and others commented on
> earlier versions) happy with this round?
I don't get why Options +SymLinksIfOwnerMatch is needed here.
If we are linking to the root installed git-http-backend Apache
will actually reject the link, because the link owner is likely to
be $USER while the target is owned by root.
So I really can't ACK this, the instructions don't jive with my
understanding of the Apache configuration.
--
Shawn.
^ permalink raw reply
* What is the best way to convert a multi module CVS repository to git?
From: Wolfgang.Liebich @ 2010-01-04 15:53 UTC (permalink / raw)
To: git
Hi,
I have inherited a rather big, old, multi-module CVS repository which I
want to convert to GIT.
Most of the CVS modules do belong to one project now, i.e. the
separation into multiple modules is something of a historical accident
now. This means it does not make sense to put each CVS module into an
own GIT project and use submodules.
Furthermore the conversion will be one-way, i.e. afterwards the CVS repo
will be shutdown forever and moved to offline storage. Incremental
conversion is therefore not an issue.
If I need one day to convert everything (the repo is about 3GB), so be
it - the most important feature to me is correctness (I do NOT want to
have to run manual verifications for N days/weeks/months, just to verify
that everything was converted), and ideally even the possibility of
re-creating the history of files which were moved across directories
(this HAS happened sometimes - I did not fiddle around with the RCS
files, but used straight rm+add, and accepted the loss of history forced
on me by CVS).
What is the best (i.e. most trustworthy) method of conversion? For now
it seems to me that cvs2git (the ...2git companion to cvs2svn) is the
best choice (because it can handle multi-module projects in a sane way)
- but I'm open to suggestions!
Ciao,
Wolfgang Liebich
^ permalink raw reply
* Re: Beginner's question on how to use git for multiple parallel versions
From: Dmitry Potapov @ 2010-01-04 14:35 UTC (permalink / raw)
To: Christian C. Schouten; +Cc: git
In-Reply-To: <F8CC469C9CCA415696101414EA997C0.MAI@sohosted19.com>
Hi,
On Mon, Jan 4, 2010 at 2:29 PM, Christian C. Schouten <info@zark3.net> wrote:
>
> I’ve got a project that I want to do version management on with git but being a beginner in
> cvs/svn/dvcs etc. terminology I don’t know yet how to set it up.
> My project needs to exist as several parallel copies, i.e. there is a “main version” in
> which I do my development but it needs to end up being available as a couple of different
> configurations.
One way to achieve that is to use branches. You create a mainline
branch that will contain
what is common for all versions, and then create a few specific
branches from it. Each branch
will contain their own files, as well as modifications to some common
files if it is necessary.
Changes that a common to all branches should be committed to the
mainline, which is merged
to each version specific branch.
Git allows to quickly switch between branches, so you stay in all
worktree all the time.
Moreover, if you made modifications to some file on branchA but then
realized that it should
be commit to another branch, you can switch to another branch as usual
as long as the
modified files are the same on both branches. (If it is not the case,
you can use git stash).
Dmitry
^ permalink raw reply
* RE: Beginner's question on how to use git for multiple parallel versions
From: Bill Lear @ 2010-01-04 15:44 UTC (permalink / raw)
To: Christian C. Schouten; +Cc: git
In-Reply-To: <22D57EF90F8E4A2799F739FC14F8BA63@Duthler.local>
On Monday, January 4, 2010 at 14:35:25 (+0100) Christian C. Schouten writes:
>Dear Bill,
>
>Thanks for your prompt reply. It may very well be exactly what I need, but
>I'm afraid that I don't understand the syntax just yet (am still in the
>phase orienting on what version management is and how it should be set up).
>
>Could you please add to your answer whether I am using branches or another
>git technique (terminology?) and whether these are instructions that I can
>use to commit a change once the system has already been set up or if these
>actually are the instructions for defining the multiplicity of my project
>versions?
In my example, I used branches, but did not show how to set them up.
Here is the complete example, complete with repository and branch
creation; you would start your project here:
# Set up repo and add first file to main branch:
% mkdir my_project
% cd my_project
% git init
% echo "main line process stuff" > process.bpel
% git add process.bpel
% echo "<non-version-specific table info>" > table.xml
% git add table.xml
% git commit -a -m "First commit on master branch"
# Create branch A and branch B:
% git branch A
% git branch B
# Modify file on branch A:
% git checkout A
% echo "<table A>" > table.xml
% git commit -a -m "Modify table on Branch A"
# Modify file on branch B:
% git checkout B
% echo "<table B>" > table.xml
% git commit -a -m "Modify table on Branch B"
# Now go back to master and make some changes on common file:
% git checkout master
% cat process.bpel
main line process stuff
% echo "add more process stuff" >> process.bpel
% git commit -a -m "fix process stuff on master"
# Now go to branch A and pull in the common file:
% git checkout A
% git merge master
% cat process.bpel
main line process stuff
add more process stuff
# Now go to branch B and pull in the common file:
% git checkout B
% git merge master
% cat process.bpel
main line process stuff
add more process stuff
That should be just about all you need.
Bill
^ permalink raw reply
* Re: [PATCH 7/6] t0021: use $SHELL_PATH for the filter script
From: Johannes Sixt @ 2010-01-04 15:50 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Nanako Shiraishi, git
In-Reply-To: <20100103072408.GA23031@sigill.intra.peff.net>
Jeff King schrieb:
> On Fri, Jan 01, 2010 at 11:14:06PM +0100, Johannes Sixt wrote:
>
>> On Windows, we need the shbang line to correctly invoke shell scripts via
>> a POSIX shell, except when the script is invoked via 'sh -c' because
>> sh (a bash) does "the right thing". Since nowadays the clean and smudge
>> filters are not always invoked via 'sh -c' anymore, we have to mark the
>> the one in t0021-conversion with #!$SHELL_PATH.
>
> Hrm. This does mean we might be breaking users who have helper scripts
> in a similar state to those in the test suite...
Not helper scripts in general, but only clean and smudge filters, because
these have been invoked with "sh -c" so far. Everything else, that was not
run via "sh -c", but now is, is safe.
-- Hannes
^ permalink raw reply
* Re: [PATCH] grep: do not do external grep on skip-worktree entries
From: Linus Torvalds @ 2010-01-04 15:54 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Miles Bader, Nguyen Thai Ngoc Duy, git
In-Reply-To: <20100104064408.GA7785@coredump.intra.peff.net>
On Mon, 4 Jan 2010, Jeff King wrote:
>
> I have to wonder, though...did anybody ever actually profile our
> internal grep to find out _why_ it was so much slower than GNU grep?
> Could we simply ship a better grep engine and obsolete external grep?
The internal grep is about 2.5 times slower than the external one for me.
That's a big deal:
- external grep:
[torvalds@nehalem linux]$ time git grep qwerty
...
real 0m0.412s
user 0m0.196s
sys 0m0.132s
- NO_EXTERNAL_GREP:
[torvalds@nehalem linux]$ time ~/git/git grep qwerty
...
real 0m1.006s
user 0m0.900s
sys 0m0.096s
so that's not even close.
And "perf record" followed by "perf report" on the internal one shows
that it's not even regexec() - we use strstr() for the trivial case:
43.63% git /home/torvalds/git/git [.] grep_buffer_1
25.19% git /lib64/libc-2.11.so [.] __strstr_sse42
9.16% git /home/torvalds/git/git [.] match_one_pattern
4.79% git /lib64/libc-2.11.so [.] __m128i_strloadu
bit it seems to be all that line-per-line crud. If we got rid of that one,
and could do the match as a _single_ regexec() instead (at least for the
trivial cases of just one grep expression), perhaps we'd be better off.
Linus
^ 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