* Re: [PATCH 9/9] rerere forget path: forget recorded resolution
From: Junio C Hamano @ 2010-01-06 21:59 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <7vr5q31871.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> However, I think you need this fix for "checkout -m" to work as intended,
Here is a cleaner reroll with tests, meant to be applied on v1.6.1-rc1 or
later.
-- >8 --
Subject: [PATCH] checkout -m path: fix recreating conflicts
We should tell ll_merge() that the 3-way merge between stages #2 and #3 is
an outermost merge, not a virtual-ancestor creation.
Back when this code was originally written, users couldn't write custom
merge drivers easily, so the bug didn't matter, but these days it does.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-checkout.c | 2 +-
t/t7201-co.sh | 57 ++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 58 insertions(+), 1 deletions(-)
diff --git a/builtin-checkout.c b/builtin-checkout.c
index 7f3bd7b..e41e73b 100644
--- a/builtin-checkout.c
+++ b/builtin-checkout.c
@@ -179,7 +179,7 @@ static int checkout_merged(int pos, struct checkout *state)
fill_mm(active_cache[pos+2]->sha1, &theirs);
status = ll_merge(&result_buf, path, &ancestor,
- &ours, "ours", &theirs, "theirs", 1);
+ &ours, "ours", &theirs, "theirs", 0);
free(ancestor.ptr);
free(ours.ptr);
free(theirs.ptr);
diff --git a/t/t7201-co.sh b/t/t7201-co.sh
index 0e21632..3214ad2 100755
--- a/t/t7201-co.sh
+++ b/t/t7201-co.sh
@@ -534,4 +534,61 @@ test_expect_success 'failing checkout -b should not break working tree' '
'
+(
+ echo "#!$SHELL_PATH"
+ cat <<\EOF
+O=$1 A=$2 B=$3
+cat "$A" >.tmp
+exec >"$A"
+echo '<<<<<<< filfre-theirs'
+cat "$B"
+echo '||||||| filfre-common'
+cat "$O"
+echo '======='
+cat ".tmp"
+echo '>>>>>>> filfre-ours'
+rm -f .tmp
+exit 1
+EOF
+) >filfre.sh
+chmod +x filfre.sh
+
+test_expect_success 'custom merge driver with checkout -m' '
+ git reset --hard &&
+
+ git config merge.filfre.driver "./filfre.sh %O %A %B" &&
+ git config merge.filfre.name "Feel-free merge driver" &&
+ git config merge.filfre.recursive binary &&
+ echo "arm merge=filfre" >.gitattributes &&
+
+ git checkout -b left &&
+ echo neutral >arm &&
+ git add arm .gitattributes &&
+ test_tick &&
+ git commit -m neutral &&
+ git branch right &&
+
+ echo left >arm &&
+ test_tick &&
+ git commit -a -m left &&
+ git checkout right &&
+
+ echo right >arm &&
+ test_tick &&
+ git commit -a -m right &&
+
+ test_must_fail git merge left &&
+ (
+ for t in filfre-common left right
+ do
+ grep $t arm || exit 1
+ done
+ exit 0
+ ) &&
+
+ mv arm expect &&
+ git checkout -m arm &&
+ test_cmp expect arm
+'
+
test_done
--
1.6.6.184.ge163d
^ permalink raw reply related
* What's cooking in git.git (Jan 2010, #02 draft; Wed, 06)
From: Junio C Hamano @ 2010-01-06 22:22 UTC (permalink / raw)
To: git
I am experimenting with ideas to better manage the periodic "What's
cooking" messages, and here is one of such attempt based on the current
draft of the upcoming "2010 Jan, issue #02".
This is an incremental update (the full version will follow shortly) that
shows the changes since the previous issue, and was generated with a
custom diff driver. One of the things to notice is that the ones that
only moved across sections (e.g. bg/maint-remote-update-default) without
any other changes are shown without the list of commits.
----------------------------------------------------------------
-What's cooking in git.git (Jan 2010, #01; Mon, 04)
+What's cooking in git.git (Jan 2010, #02 draft; Wed, 06)
--------------------------------------------------
Born topics
[New Topics]
* jc/maint-1.6.1-checkout-m-custom-merge (2010-01-06) 1 commit
- checkout -m path: fix recreating conflicts
* jn/makefile (2010-01-06) 4 commits
- Makefile: consolidate .FORCE-* targets
- Makefile: learn to generate listings for targets requiring special flags
- Makefile: use target-specific variable to pass flags to cc
- Makefile: regenerate assembler listings when asked
--------------------------------------------------
Moved from [New Topics] to [Cooking]
* 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
+ (merged to 'next' on 2010-01-06 at e957395)
+ + 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
+
+Will merge to 'next', unless I hear objections within a few days.
* tc/test-locate-httpd (2010-01-02) 1 commit
- - t/lib-http.sh: Restructure finding of default httpd location
+ (merged to 'next' on 2010-01-06 at 9d913e5)
+ + t/lib-http.sh: Restructure finding of default httpd location
* jc/fix-tree-walk (2009-09-14) 7 commits
-Resurrected from "Ejected" category.
+Resurrected from "Ejected" category. This is fix for a tricky codepath
+and testing and improving before it hits 'next' by brave souls is greatly
+appreciated. I am not very happy about the solution myself.
--------------------------------------------------
Moved from [Cooking] to [Will graduate after a bit more cooking]
* bg/maint-remote-update-default (2009-12-31) 1 commit
* jk/maint-1.6.5-reset-hard (2009-12-30) 1 commit
* jk/push-to-delete (2009-12-30) 1 commit
* mm/config-path (2009-12-30) 1 commit
* pm/cvs-environ (2009-12-30) 1 commit
* so/cvsserver-update (2009-12-07) 1 commit
* tr/maint-1.6.5-bash-prompt-show-submodule-changes (2009-12-31) 1 commit
* js/filter-branch-prime (2009-12-15) 1 commit
* mg/tag-d-show (2009-12-10) 1 commit
* sb/maint-octopus (2009-12-11) 3 commits
* bg/maint-add-all-doc (2009-12-07) 4 commits
* mv/commit-date (2009-12-03) 2 commits
* mo/bin-wrappers (2009-12-02) 3 commits
* tr/http-updates (2009-12-28) 4 commits
* nd/sparse (2009-12-30) 23 commits
--------------------------------------------------
Other topics
[Cooking]
-* cc/reset-more (2010-01-04) 6 commits
+* cc/reset-more (2010-01-05) 7 commits
+ (merged to 'next' on 2010-01-06 at 96639cb)
+ + Documentation: reset: add some missing tables
(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
* jc/branch-d (2009-12-29) 1 commit
- branch -d: base the "already-merged" safety on the branch it merges with
+
+http://thread.gmane.org/gmane.comp.version-control.git/135837/focus=135863
+I am tempted to merge this to 'next', but please stop me if people see issues
+in it.
* 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
+ - t0021: use $SHELL_PATH for the filter script
- run-command: add "use shell" option
- Xref: news.gmane.org gmane.comp.version-control.git:136128
- * check t0021: drop one to t4030;
- * reorder and move t0021 up, immediately after run-command: optimize
+Shuffled the commits in the topic, following J6t's suggestion in
+http://thread.gmane.org/gmane.comp.version-control.git/136128
* 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
+
+Perhaps needs an entry in the Release Notes, but otherwise looked Ok.
* 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
+ (merged to 'next' on 2010-01-06 at 82736cb)
+ + 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
* 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
+
+Will wait a bit more before moving it to 'next'.
* jh/commit-status (2009-12-07) 1 commit
- [test?] Add commit.status, --status, and --no-status
+
+Needs tests.
* 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
+
+Users of "rebase -i" might want to teach this to the command. Volunteers?
* 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
+
+Peff: $gmane/136169, 136167, 136168
+RC: $gmane/136172
* 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
+ (merged to 'next' on 2010-01-06 at 7c79f42)
+ + 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.
+ (merged to 'next' on 2010-01-06 at 6b4201e)
+ + 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
+ (merged to 'next' on 2010-01-06 at c4779a7)
+ + 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.)
* ns/rebase-auto-squash (2009-12-08) 2 commits
- - fixup! rebase -i --autosquash
- - rebase -i --autosquash: auto-squash commits
+ (merged to 'next' on 2010-01-06 at 91913ca)
+ + 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
+
+http://thread.gmane.org/gmane.comp.version-control.git/134738
+
+What's the status of the fourth and later patches on this topic? Overall
+it looked reasonable, if I recall correctly what I thought when I reviewed
+it last time, and I am tempted to merge it to 'next' soonish. Please
+file complaints before I do so if people have objections.
+
+http://mid.gmane.org/201001051231.43048.johan@herland.net Hold!
* fc/opt-quiet-gc-reset (2009-12-02) 1 commit
- - General --quiet improvements
+ (merged to 'next' on 2010-01-06 at 03e00cd)
+ + General --quiet improvements
* 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
+
+http://thread.gmane.org/gmane.comp.version-control.git/134540
+
+I haven't seen comments on this round, and I am tempted to merge it to
+'next' soonish. Please file complaints before I do so if people have
+objections.
^ permalink raw reply
* What's cooking in git.git (Jan 2010, #02 draft; Wed, 06)
From: Junio C Hamano @ 2010-01-06 22:25 UTC (permalink / raw)
To: git
In-Reply-To: <7vvdfenaar.fsf@alter.siamese.dyndns.org>
This is the current draft of "2010 Jan, issue #2" that the experimental
"incremental update" I sent earlier was made out of, for comparison
purposes.
--------------------------------------------------
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]
* jc/maint-1.6.1-checkout-m-custom-merge (2010-01-06) 1 commit
- checkout -m path: fix recreating conflicts
* jn/makefile (2010-01-06) 4 commits
- Makefile: consolidate .FORCE-* targets
- Makefile: learn to generate listings for targets requiring special flags
- Makefile: use target-specific variable to pass flags to cc
- Makefile: regenerate assembler listings when asked
--------------------------------------------------
[Will graduate after a bit more cooking]
* 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
* 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
* 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
* 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.
* 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
* 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'
* 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
* 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
* 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
* 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
* 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
--------------------------------------------------
[Cooking]
* da/difftool (2009-12-22) 2 commits
(merged to 'next' on 2010-01-06 at e957395)
+ 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
Will merge to 'next', unless I hear objections within a few days.
* tc/test-locate-httpd (2010-01-02) 1 commit
(merged to 'next' on 2010-01-06 at 9d913e5)
+ 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. This is fix for a tricky codepath
and testing and improving before it hits 'next' by brave souls is greatly
appreciated. I am not very happy about the solution myself.
* cc/reset-more (2010-01-05) 7 commits
(merged to 'next' on 2010-01-06 at 96639cb)
+ Documentation: reset: add some missing tables
(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
* jc/branch-d (2009-12-29) 1 commit
- branch -d: base the "already-merged" safety on the branch it merges with
http://thread.gmane.org/gmane.comp.version-control.git/135837/focus=135863
I am tempted to merge this to 'next', but please stop me if people see issues
in it.
* jc/rerere (2009-12-04) 1 commit
- Teach --[no-]rerere-autoupdate option to merge, revert and friends
* jk/run-command-use-shell (2010-01-01) 8 commits
- t4030, t4031: work around bogus MSYS bash path conversion
- 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
- t0021: use $SHELL_PATH for the filter script
- run-command: add "use shell" option
Shuffled the commits in the topic, following J6t's suggestion in
http://thread.gmane.org/gmane.comp.version-control.git/136128
* 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
* 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
Perhaps needs an entry in the Release Notes, but otherwise looked Ok.
* tc/smart-http-restrict (2010-01-02) 4 commits
(merged to 'next' on 2010-01-06 at 82736cb)
+ 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
* 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
Will wait a bit more before moving it to 'next'.
* jh/commit-status (2009-12-07) 1 commit
- [test?] Add commit.status, --status, and --no-status
Needs tests.
* 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
Users of "rebase -i" might want to teach this to the command. Volunteers?
* 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
Peff: $gmane/136169, 136167, 136168
RC: $gmane/136172
* il/vcs-helper (2009-12-09) 8 commits
(merged to 'next' on 2010-01-06 at 7c79f42)
+ 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
(merged to 'next' on 2010-01-06 at 6b4201e)
+ Detailed diagnosis when parsing an object name fails.
* mh/rebase-fixup (2009-12-07) 2 commits
(merged to 'next' on 2010-01-06 at c4779a7)
+ 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
(merged to 'next' on 2010-01-06 at 91913ca)
+ 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
http://thread.gmane.org/gmane.comp.version-control.git/134738
What's the status of the fourth and later patches on this topic? Overall
it looked reasonable, if I recall correctly what I thought when I reviewed
it last time, and I am tempted to merge it to 'next' soonish. Please
file complaints before I do so if people have objections.
http://mid.gmane.org/201001051231.43048.johan@herland.net Hold!
* fc/opt-quiet-gc-reset (2009-12-02) 1 commit
(merged to 'next' on 2010-01-06 at 03e00cd)
+ General --quiet improvements
* 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
http://thread.gmane.org/gmane.comp.version-control.git/134540
I haven't seen comments on this round, and I am tempted to merge it to
'next' soonish. Please file complaints before I do so if people have
objections.
* 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.
^ permalink raw reply
* Re: gc.auto bug in 1.6.5.7
From: Jon Nelson @ 2010-01-06 22:27 UTC (permalink / raw)
Cc: git
In-Reply-To: <u1EMnFha7hfr0SI0p8dEvAJML7vykSCAA6YzQd7klvze6oKChlMCLg@cipher.nrlssc.navy.mil>
On Wed, Jan 6, 2010 at 12:31 PM, Brandon Casey
<brandon.casey.ctr@nrlssc.navy.mil> wrote:
> Jon Nelson wrote:
>> It would appear that there is a bug in git, at least as of 1.6.5.7, in
>> the gc command.
>> When gc.auto is non-zero, it appears to consider packfiles as "loose"
>> - this conflicts with pack.packSizeLimit, insofar as I have
>> pack.packSizeLimit set to 2M (which appears to work). If gc.auto is,
>> say, 50 - once I exceed 50 2MB packs then gc --auto repacks *every
>> single time* it is run. This is unexpected, at least.
>
> There is also a gc.autopacklimit which controls auto-gc'ing based on
> the number of packs. The default is 50 and it does not consider the
> pack.packSizeLimit setting when deciding whether or not to auto-gc.
> It can be raised, or it can be disabled by setting it to zero.
I disabled it entirely and that seemed to resolve the issue. Thanks!
--
Jon
^ permalink raw reply
* Re: [PATCHv3 0/4 (resent)] Miscelanous gitweb improvements from J.H.
From: J.H. @ 2010-01-06 22:28 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <1262534850-24572-1-git-send-email-jnareb@gmail.com>
Just a heads up I've been on vacation for two weeks and hadn't gotten
around to dealing with these e-mails. I'm going to get them imported
into my tree here and take a look over them.
- John 'Warthog9' Hawley
On 01/03/2010 08:07 AM, Jakub Narebski wrote:
> This is resend of early part of "[PATCH 0/6] Gitweb caching changes v2"
> thread by John 'Warthog9' Hawley (J.H.),
> Message-ID: <1260488743-25855-1-git-send-email-warthog9@kernel.org>
> http://thread.gmane.org/gmane.comp.version-control.git/135052
>
> or alternatively
> git://git.kernel.org/pub/scm/git/warthog9/gitweb.git gitweb-ml-v2
>
> with a few modifications of my own. Those patches were send originally as
> responses in the mentioned thread, for further comments from original
> author. As the discussion didn't pick up (because of kernel.org upgrade, and
> perhaps due to end-of-year stuff), I am resending those patches in a
> separate thread for a better visibility; only comments are changed.
>
> This series of patches is rebased on top of commit 37bae10
> (Merge branch 'maint', 2009-12-31) in 'master' branch.
>
>
> Change that apply to all patches in series:
> * moving from "GITWEB - " to "gitweb: " as subsystem prefix
> * changing author to John 'Warthog9' Hawley <warthog9@kernel.org>
> (it was John 'Warthog9' Hawley <warthog9@eaglescrag.net>)
> * add signoff or change it to John 'Warthog9' Hawley <warthog9@kernel.org>,
> and of course add my own signoff.
>
>
> I have included reply to neither "GITWEB - File based caching layer"
> nor "GITWEB - Separate defaults from main file" in this thread/series.
>
> I haven't included the main point of the whole series, namely adding
> response caching layer in the form that is used in git.kernel.org, because
> I think this patch should be split into smaller parts, and unit-tested.
> As it is now it is a bit of mess. I have done patch which makes gitweb
> always use explicit filehandle when printing (simplifying a bit it
> replaces 'print <something>' by 'print {$out} <something>', with $out set
> to \*STDOUT), as a patch that prepares for (optional) gitweb caching, while
> not affecting throughput, latency and memory consumption when caching is
> disabled, as opposed to original solution by J.H. of always storing whole
> response in scalar and writing it at the end.
>
> I haven't included splitting of gitweb_defaults.perl off gitweb.perl, as it
> was after large and invasive gitweb caching patch, it would require
> substantial changes to gitweb tests upfront (by testing built gitweb.cgi and
> not source gitweb.perl), and needs fixing of Makefile to actually work
> reliably (we could have to process both gitweb.perl and
> gitweb_defaults.perl, while provided Makefile process only the file which
> triggered the rule... I think).
>
>
> I am not sure if 'gitweb: Add option to force version match' is a good
> solution to the problem it tires to address, i.e. if it is worth having,
> and I am not sure if I did 'gitweb: Makefile improvements' correctly.
>
> John 'Warthog9' Hawley (4):
> gitweb: Load checking
> gitweb: Add option to force version match
> gitweb: Optionally add "git" links in project list page
> gitweb: Makefile improvements
>
> Makefile | 65 +++++---------------------
> gitweb/Makefile | 129 ++++++++++++++++++++++++++++++++++++++++++++++++++++
> gitweb/README | 14 +++++-
> gitweb/gitweb.perl | 80 ++++++++++++++++++++++++++++++--
> 4 files changed, 230 insertions(+), 58 deletions(-)
> create mode 100644 gitweb/Makefile
>
> John, any comments?
>
^ permalink raw reply
* Re: [spf:guess] Re: [PATCH 1/2] git-svn: ignore changeless commits when checking for a cherry-pick
From: Sam Vilain @ 2010-01-06 22:38 UTC (permalink / raw)
To: Eric Wong; +Cc: Andrew Myrick, git
In-Reply-To: <20100106214338.GA5115@dcvr.yhbt.net>
Eric Wong wrote:
> Andrew Myrick <amyrick@apple.com> wrote:
>
>> diff --git a/git-svn.perl b/git-svn.perl
>> index 650c9e5..8c7c034 100755
>> --- a/git-svn.perl
>> +++ b/git-svn.perl
>> @@ -3052,12 +3052,36 @@ sub check_cherry_pick {
>> for my $range ( @ranges ) {
>> delete @commits{_rev_list($range)};
>> }
>> + for my $commit (keys %commits) {
>>
>
> Hi Andrew,
>
> I'll again defer to Sam for Acks on these. Test cases would be nice to
> have, too.
>
They look fine to me, agreed a test case would be nice and make sure the
features aren't lost later inadvertently.
Thanks Andrew,
Sam
^ permalink raw reply
* Re: [PATCH 1/2] git-svn: ignore changeless commits when checking for a cherry-pick
From: Andrew Myrick @ 2010-01-06 22:52 UTC (permalink / raw)
To: Eric Wong; +Cc: git, sam
In-Reply-To: <20100106214338.GA5115@dcvr.yhbt.net>
On Jan 6, 2010, at 1:43 PM, Eric Wong wrote:
> Andrew Myrick <amyrick@apple.com> wrote:
>> diff --git a/git-svn.perl b/git-svn.perl
>> index 650c9e5..8c7c034 100755
>> --- a/git-svn.perl
>> +++ b/git-svn.perl
>> @@ -3052,12 +3052,36 @@ sub check_cherry_pick {
>> for my $range ( @ranges ) {
>> delete @commits{_rev_list($range)};
>> }
>> + for my $commit (keys %commits) {
>
> Hi Andrew,
>
> I'll again defer to Sam for Acks on these. Test cases would be nice to
> have, too.
I'll see what I can do. The test cases are conceptually simple (the svn dump I sent out the other day will exercise one of these patches), but it will take me some time to learn git's testing infrastructure, and I have impending deadlines on other work, so I can't promise anything immediate.
>
> A few notes:
>
> The prevailing standard for indentation in git is with hard tabs and
> that's certainly the case with the rest of git-svn.perl.
>
>> +sub has_no_changes {
>> + my $commit = shift;
>> +
>> + my @revs = split / /, command_oneline(
>> + qw(rev-list --parents -1 -m), $commit);
>> +
>> + # Commits with no parents, e.g. the start of a partial branch,
>> + # have changes by definition.
>> + return 1 if (@revs < 2);
>> +
>
> I've become very picky about trailing whitespace (from Junio :), too.
> "git diff --check" is helpful for this, especially in the pre-commit
> hook.
My apologies for not noticing this. I'll regenerate patches that conform to the style guidelines. Thanks for pointing out `git diff --check`; it's quite helpful.
-Andrew
^ permalink raw reply
* Re: [PATCHv3 0/4 (resent)] Miscelanous gitweb improvements from J.H.
From: Jakub Narebski @ 2010-01-06 23:22 UTC (permalink / raw)
To: J.H.; +Cc: git
In-Reply-To: <4B450EA2.5020104@kernel.org>
On Wed, 6 Jan 2010, J.H. wrote:
> Just a heads up I've been on vacation for two weeks and hadn't gotten
> around to dealing with these e-mails. I'm going to get them imported
> into my tree here and take a look over them.
They are also available from 'gitweb/cache-kernel' branch of my
git/jnareb-git.git repository at repo.or.cz... and are available from
'pu' branch in main git repository, as fbd43a8^2 (Merge branch
'jh/gitweb-cached' into pu, 2010-01-04).
It might be easier to import (fetch) them from that repository, and just
drop top two commits / merge jnareb-git/gitweb/cache-kernel~2
git://repo.or.cz/git/jnareb-git.git gitweb/cache-kernel
John 'Warthog9' Hawley (4):
gitweb: Load checking
gitweb: Add option to force version match
gitweb: Optionally add "git" links in project list page
gitweb: Makefile improvements
Jakub Narebski (2):
gitweb: Print to explicit filehandle (preparing for caching)
gitweb: href(..., -path_info => 0|1)
The two top commits on that branch are work in progress in preparation
for response caching for gitweb from J.H. (the one used on
git.kernel.org), and are not ready yet, I think; at least there would
be one more commit in "preparing for gitweb caching" (sub)series.
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH 1/2] git-svn: ignore changeless commits when checking for a cherry-pick
From: Andrew Myrick @ 2010-01-07 0:25 UTC (permalink / raw)
To: git; +Cc: sam, normalperson, Andrew Myrick
In-Reply-To: <E10FB265-0C47-44C7-9347-687A9F447603@apple.com>
Update git-svn to ignore commits that do not change the tree when it is
deciding if an svn merge ticket represents a real branch merge or just a
cherry-pick.
Consider the following integration model in the svn repository:
F---G branch1
/ \
D tag1 \ E tag2
/ \ /
A---B C trunk
branch1 is merged to trunk in commit C.
With this patch, git-svn will correctly identify branch1 as a proper merge
parent, instead of incorrectly ignoring it as a cherry-pick.
Signed-off-by: Andrew Myrick <amyrick@apple.com>
---
git-svn.perl | 24 ++++++++++++++++++++++++
1 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 650c9e5..947184a 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -3052,12 +3052,36 @@ sub check_cherry_pick {
for my $range ( @ranges ) {
delete @commits{_rev_list($range)};
}
+ for my $commit (keys %commits) {
+ if (has_no_changes($commit)) {
+ delete $commits{$commit};
+ }
+ }
return (keys %commits);
}
+sub has_no_changes {
+ my $commit = shift;
+
+ my @revs = split / /, command_oneline(
+ qw(rev-list --parents -1 -m), $commit);
+
+ # Commits with no parents, e.g. the start of a partial branch,
+ # have changes by definition.
+ return 1 if (@revs < 2);
+
+ # Commits with multiple parents, e.g a merge, have no changes
+ # by definition.
+ return 0 if (@revs > 2);
+
+ return (command_oneline("rev-parse", "$commit^{tree}") eq
+ command_oneline("rev-parse", "$commit~1^{tree}"));
+}
+
BEGIN {
memoize 'lookup_svn_merge';
memoize 'check_cherry_pick';
+ memoize 'has_no_changes';
}
sub parents_exclude {
--
1.6.6.2.g18c9a
^ permalink raw reply related
* [PATCH 2/2] git-svn: handle merge-base failures
From: Andrew Myrick @ 2010-01-07 0:25 UTC (permalink / raw)
To: git; +Cc: sam, normalperson, Andrew Myrick
In-Reply-To: <1262823922-3415-1-git-send-email-amyrick@apple.com>
Change git-svn to warn and continue when merge-base fails while processing svn
merge tickets.
merge-base can fail when a partial branch is created and merged back to trunk
in svn, because it cannot find a common ancestor between the partial branch and
trunk.
Signed-off-by: Andrew Myrick <amyrick@apple.com>
---
git-svn.perl | 19 +++++++++++++++----
1 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 947184a..1f201e4 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -3158,10 +3158,21 @@ sub find_extra_svn_parents {
my $ranges = $ranges{$merge_tip};
# check out 'new' tips
- my $merge_base = command_oneline(
- "merge-base",
- @$parents, $merge_tip,
- );
+ my $merge_base;
+ eval {
+ $merge_base = command_oneline(
+ "merge-base",
+ @$parents, $merge_tip,
+ );
+ };
+ if ($@) {
+ die "An error occurred during merge-base"
+ unless $@->isa("Git::Error::Command");
+
+ warn "W: Cannot find common ancestor between ".
+ "@$parents and $merge_tip. Ignoring merge info.\n";
+ next;
+ }
# double check that there are no missing non-merge commits
my (@incomplete) = check_cherry_pick(
--
1.6.6.2.g18c9a
^ permalink raw reply related
* 1.6.1.3: git merge --no-commit ... DID commit
From: layer @ 2010-01-07 1:41 UTC (permalink / raw)
To: git
quadra% git merge --no-commit duane-acl82/acl82
Updating 621f935..a94f7fc
Fast forward
ChangeLog | 23 ++++++++++++++
src/c/fio.c | 2 +-
src/c/mon1.c | 6 ++-
src/code/debug.cl | 10 +++++-
src/code/lldb.cl | 75 +++++++++++++++++++++++++++++++++++++---------
src/code/osi-alpha.cl | 33 ++++++++++++++++++++
src/code/osi-alpha64.cl | 33 ++++++++++++++++++++
src/code/x/disx86-64.cl | 4 ++
src/rs/vrlinux.cl | 3 +-
src/rs/xrlinux64.cl | 30 +++++++++++++++----
src/rs/xrmacosx64.cl | 44 ++++++++++++++++++++++++----
src/rs/xrms64.cl | 28 ++++++++++++++---
src/rs/xrsol64.cl | 28 ++++++++++++++---
13 files changed, 276 insertions(+), 43 deletions(-)
quadra% git status
# On branch acl82
# Your branch is ahead of 'origin/acl82' by 2 commits.
#
nothing to commit (working directory clean)
quadra%
Has this been fixed in a later version?
^ permalink raw reply
* Re: A question about changing remote repo name
From: Russell Steicke @ 2010-01-07 1:53 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Dongas, git
In-Reply-To: <alpine.DEB.1.00.1001060123280.4985@pacific.mpi-cbg.de>
On Wed, Jan 6, 2010 at 8:27 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> For everybody reading this thread: DON'T!
>
> Russel, it would be better if you knew about the mechanism before
> making other people believe that it is safe to delete a file that is _not_
> a cache, but _replaces_ the existing refs.
Thank you for explaining that. I apologise for the misleading information.
I have seen refs in packed-refs as duplicates of those in the refs/
tree. How would that come about?
--
Virus found in this message.
^ permalink raw reply
* Re: 1.6.1.3: git merge --no-commit ... DID commit
From: Junio C Hamano @ 2010-01-07 2:13 UTC (permalink / raw)
To: layer; +Cc: git
In-Reply-To: <11785.1262828518@relay.known.net>
layer <layer@known.net> writes:
> quadra% git merge --no-commit duane-acl82/acl82
> Updating 621f935..a94f7fc
> Fast forward
> ...
> quadra% git status
> # On branch acl82
> # Your branch is ahead of 'origin/acl82' by 2 commits.
> #
> nothing to commit (working directory clean)
> ...
> Has this been fixed in a later version?
In short, there is nothing to fix. You asked it not to create a commit,
and the merge was a fast-forward; there was no new commit created.
When a real merge is involved, e.g. you have this history:
x---x---x---x---B duane-acl82/acl82
/
---O---o---o---o---A HEAD
telling "--no-commit" to merge creates the state to be committed in your
work tree and the index, notes the fact that the next "git commit" will
record a merge between A and B, and stops. Hence, "git diff HEAD" will
show the damange merging duane-acl82/acl82 will cause to your current
branch, and then you can "git commit" to record the merge to result in
this history:
x---x---x---x---B duane-acl82/acl82
/ \
---O---o---o---o---A---* HEAD
A --no-commit merge followed by committing on your own will result in a
history of the same shape as "merge" without --no-commit will create.
Think what you want to happen if you started from this history:
x---x---x---x---B duane-acl82/acl82
/
---A HEAD
If "merge --no-commit" left HEAD at A but updated the index and the work
tree to the result of the merge, which would be the same as the tree
recorded by commit B, and prepared to record a merge commit between A and
B, then next "git commit" will not create a history of the same shape as
you would normally get from "merge" without --no-commit, which is:
HEAD
x---x---x---x---B duane-acl82/acl82
/
---A
Instead, you will end up with a history of this shape, with one useless
merge commit:
x---x---x---x---B duane-acl82/acl82
/ \
---A-------------------* HEAD
That is why "merge --no-commit" will fast-forward.
If you really want to do this, there is a way to create a history with
such a shape ("git merge --no-ff") but by default it is not recommended
and you need to explicitly ask for it (or configure). It can also be used
together with --no-commit option.
Often people claim that they want to review before actually merging, but
it is much better to get in the habit of running "git merge topic" first
then inspecting "git diff ORIG_HEAD^ after the fact. If the result is
undesirable, you can always "git reset --hard ORIG_HEAD" it away. The
reason it is better is that this will work regardless of the kind of merge
you would end up with; you can reset away a fast-forward using ORIG_HEAD.
Another technique that may be worth learning is to do "git diff ...topic"
before running a merge (notice three dots).
^ permalink raw reply
* Re: [PATCH git-gui 5/5] git-gui/Makefile: consolidate .FORCE-* targets
From: Shawn O. Pearce @ 2010-01-07 2:20 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, Junio C Hamano
In-Reply-To: <20100106081638.GF7298@progeny.tock>
Jonathan Nieder <jrnieder@gmail.com> wrote:
> Providing multiple targets to force a rebuild is unnecessary
> complication.
>
> Avoid using a name that could conflict with future special
> targets in GNU make (a leading period followed by uppercase
> letters).
>
> Cc: Junio C Hamano <gitster@pobox.com>
> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Thanks, applied.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] git-gui: Add hotkeys for "Unstage from commit" and "Revert changes"
From: Shawn O. Pearce @ 2010-01-07 2:22 UTC (permalink / raw)
To: public_vi; +Cc: git
In-Reply-To: <1262266373-7314-1-git-send-email-public_vi@tut.by>
public_vi@tut.by wrote:
> From: Vitaly _Vi Shukela <public_vi@tut.by>
>
> Signed-off-by: Vitaly _Vi Shukela <public_vi@tut.by>
> ---
> git-gui/git-gui.sh | 10 ++++++++--
> 1 files changed, 8 insertions(+), 2 deletions(-)
Thanks, applied.
(Ignore my private email from a few minutes ago asking for a repost,
its not necessary.)
--
Shawn.
^ permalink raw reply
* Re: [PATCH 1/2] t7002: set test prerequisite "external-grep" if supported
From: Junio C Hamano @ 2010-01-07 2:37 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1262608455-4045-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> 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.
Thanks. We seem to spell our prerequistes in a single-word, all-caps, so
I'll change this new one to EXTGREP in both [1/2] and [2/2].
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2010, #02 draft; Wed, 06)
From: Nanako Shiraishi @ 2010-01-07 3:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvdfenaar.fsf@alter.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com>
> I am experimenting with ideas to better manage the periodic "What's
> cooking" messages, and here is one of such attempt based on the current
> draft of the upcoming "2010 Jan, issue #02".
>
> This is an incremental update (the full version will follow shortly) that
> shows the changes since the previous issue, and was generated with a
> custom diff driver. One of the things to notice is that the ones that
> only moved across sections (e.g. bg/maint-remote-update-default) without
> any other changes are shown without the list of commits.
>
> ----------------------------------------------------------------
>
> -What's cooking in git.git (Jan 2010, #01; Mon, 04)
> +What's cooking in git.git (Jan 2010, #02 draft; Wed, 06)
>
> --------------------------------------------------
> Born topics
>
> [New Topics]
>
> * jc/maint-1.6.1-checkout-m-custom-merge (2010-01-06) 1 commit
> - checkout -m path: fix recreating conflicts
>
> * jn/makefile (2010-01-06) 4 commits
> - Makefile: consolidate .FORCE-* targets
> - Makefile: learn to generate listings for targets requiring special flags
> - Makefile: use target-specific variable to pass flags to cc
> - Makefile: regenerate assembler listings when asked
>
> --------------------------------------------------
> Moved from [New Topics] to [Cooking]
>
> * 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
> + (merged to 'next' on 2010-01-06 at e957395)
> + + 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
> +
> +Will merge to 'next', unless I hear objections within a few days.
For what it's worth, I think this new format very easy to spot the differences and much nicer.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: git-cherry-pick problem - directory not touched by commit is marked "added by us"
From: Junio C Hamano @ 2010-01-07 3:30 UTC (permalink / raw)
To: Hakim Cassimally; +Cc: git, Sam Vilain
In-Reply-To: <82cfa8031001060328r21aa8de3s5c2dd5dac005b679@mail.gmail.com>
Hakim Cassimally <hakim.cassimally@gmail.com> writes:
>>> (stable) $ git cherry-pick 301afce1
>>> Finished one cherry-pick.
>>> www/client/css/admin.css: needs merge
>>> <...snip>
>>> www/client/css/admin.css: unmerged (8e7cd850bf40d1a921b1f62ce0945abd374fa55d)
>>> <...snip>
>>> ...
>>> error: Error building trees
>>
> $ git ls-files -s -u www/client/css/admin.css # only staged/unmerged
> 100755 8e7cd850bf40d1a921b1f62ce0945abd374fa55d 2
> www/client/css/admin.css
>
> (i.e. when run after the failed cherry-pick)
>
>> Also take the 'git ls-tree -r HEAD', 'git ls-tree -r 301afce1' and 'git
>> ls-tree -r 301afce1^' output, and grep for the files in question. The
>> answer (or at least a bug triage) should be in the output of those
>> commands.
>
> $ git ls-tree HEAD | grep www/client/css/admin.css
> 100755 blob 8e7cd850bf40d1a921b1f62ce0945abd374fa55d
> www/client/css/admin.css
>
> There's no entry in git ls-tree 301afce1 or 301afce1^1 though. I'd
> guess that's significant, but I don't know what answer it suggests...
>
> (However the file exists in both (stable) and (experimental)...
> and is identical in both).
> ....
So in short:
* commit 301a added a new path bin/upload_module.pl;
* the state you cherry-picked this commit to was clean (i.e. before
running cherry-pick, "git status" reported no local changes to the
index nor to the work tree);
* the commit, the index, and the work tree before running this
cherry-pick had www/client/css/admin.css file, which also existed in
301a and 301a^, but all of these three commits had the same contents.
A simple minded attempt to reproduce this (attached below) by preparing a
commit that adds one new file and attempting to transplant to an unrelated
commit that doesn't have the file didn't work; I have been scratching my
head.
What "cherry-pick" internally does is to run:
git merge-recursive 301a^ -- HEAD 301a
That is, "We are at HEAD; consolidate the change since 301a^ to 301a into
our state, and leave the result in the index and the work tree". Then it
commits the result. One thing to try is to see if this gives the same
kind of breakage.
The only other thing that _may_ be involved is if there are paths that
turned between directories and files on the two histories, or perhaps
there are paths like "www-frotz", "www.frotz", etc (i.e. "www" followed by
a byte whose ASCII value comes before '/') involved, and unpack_trees()
machinery the merge-recursive internally uses are getting confused about
D/F conflicts. To diagnose it, it would be helpful to get the full output
from these two commands:
git ls-tree -r -t HEAD (before cherry-pick)
git ls-tree -r -t 301a (the commit you are transplanting)
Thanks
---
diff --git a/t/t3506-cherry-pick-addremove.sh b/t/t3506-cherry-pick-addremove.sh
new file mode 100755
index 0000000..e7dcd77
--- /dev/null
+++ b/t/t3506-cherry-pick-addremove.sh
@@ -0,0 +1,26 @@
+#!/bin/sh
+
+test_description='unrelated files added by our side'
+
+. ./test-lib.sh
+
+test_expect_success setup '
+ test_commit A &&
+ git branch side &&
+ test_commit B &&
+ test_commit C &&
+
+ git checkout side &&
+ test_commit D &&
+ test_commit E &&
+
+ git checkout master
+'
+
+test_expect_success 'cherry-pick' '
+ git reset --hard C &&
+ git cherry-pick side &&
+ git grep E E.t
+'
+
+test_done
^ permalink raw reply related
* Re: git-cherry-pick problem - directory not touched by commit is marked "added by us"
From: Junio C Hamano @ 2010-01-07 3:35 UTC (permalink / raw)
To: Hakim Cassimally; +Cc: git, Sam Vilain
In-Reply-To: <7v4omyfv6h.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> What "cherry-pick" internally does is to run:
>
> git merge-recursive 301a^ -- HEAD 301a
>
> That is, "We are at HEAD; consolidate the change since 301a^ to 301a into
> our state, and leave the result in the index and the work tree". Then it
> commits the result. One thing to try is to see if this gives the same
> kind of breakage.
There actually is another possibility; we used to run inside "cherry-pick"
git merge-resolve 301a^ -- HEAD 301a
instead. The request is the same but it uses a different algorithm, so if
one fails and one succeeds, that might give us a better clue to figure out
what is going on.
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2010, #02 draft; Wed, 06)
From: Junio C Hamano @ 2010-01-07 3:43 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git
In-Reply-To: <20100107122334.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Quoting Junio C Hamano <gitster@pobox.com>
>
>> I am experimenting with ideas to better manage the periodic "What's
>> cooking" messages, and here is one of such attempt based on the current
>> draft of the upcoming "2010 Jan, issue #02".
>> ...
>> Moved from [New Topics] to [Cooking]
>>
>> * 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
>> + (merged to 'next' on 2010-01-06 at e957395)
>> + + 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
>> +
>> +Will merge to 'next', unless I hear objections within a few days.
>
> For what it's worth, I think this new format very easy to spot the
> differences and much nicer.
This is _not_ a "new format" per-se, but is primarily a demonstration of
the external diff feature (all in 'todo' branch).
While I think it is easier to view when I am interested in the differences
since the previous issue (and that was why I wrote it) than the full list,
its "incremental" nature cuts both ways.
The primary reason I send out "What's cooking" is to make sure people are
aware of topics that are _not_ going forward, to encourage them to be
involved by helping such topics. When some topics are moved from Cooking
to Stalled category, they will show up in the incremental report, but
after that, until they start moving again, they won't be shown in the
incremental report. That defeats the whole point of sending the "What's
cooking" messages.
Topics that are in motion are watched actively by testers, developers and
documenters. They don't need as much exposure as stalled ones.
^ permalink raw reply
* [PATCH] Fix segfault in fast-export
From: Mike Mueller @ 2010-01-07 3:58 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1283 bytes --]
Hi all,
I'm working on a C++ static analyzer (Vigilant Sentry), and git
is one of my test subjects. In git-1.6.6, I found a crash in the
fast-export command:
The problem is in builtin-fast-export.c, function export_marks:
f = fopen(file, "w");
if (!f)
error("Unable to open marks file %s for writing.", file);
for (i = 0; i < idnums.size; i++) {
if (deco->base && deco->base->type == 1) {
mark = ptr_to_mark(deco->decoration);
if (fprintf(f, ":%"PRIu32" %s\n", mark,
sha1_to_hex(deco->base->sha1)) < 0) {
e = 1;
break;
}
}
deco++;
}
e |= ferror(f);
e |= fclose(f);
If fopen() fails, the error message is printed, but the function
doesn't exit. The subsequent calls to fprintf and/or ferror will
fail because f is NULL. A simple way to reproduce is to export
to a path you don't have write access to:
$ git fast-export --export-marks=/foo
error: Unable to open marks file /foo for writing.
Segmentation fault (core dumped)
I've attached a trivial patch that calls die_errno instead of
error, so the program exits if f is NULL.
Regards,
Mike
--
Mike Mueller
mmueller@vigilantsw.com
http://www.vigilantsw.com/
[-- Attachment #2: git-fast-export.patch --]
[-- Type: text/x-diff, Size: 449 bytes --]
diff --git a/builtin-fast-export.c b/builtin-fast-export.c
index b0a4029..963e89b 100644
--- a/builtin-fast-export.c
+++ b/builtin-fast-export.c
@@ -503,7 +503,7 @@ static void export_marks(char *file)
f = fopen(file, "w");
if (!f)
- error("Unable to open marks file %s for writing.", file);
+ die_errno("Unable to open marks file %s for writing", file);
for (i = 0; i < idnums.size; i++) {
if (deco->base && deco->base->type == 1) {
^ permalink raw reply related
* Re: [PATCH 1/2] t7002: set test prerequisite "external-grep" if supported
From: Junio C Hamano @ 2010-01-07 4:29 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <7v4omyhc7h.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
>
>> 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.
>
> Thanks. We seem to spell our prerequistes in a single-word, all-caps, so
> I'll change this new one to EXTGREP in both [1/2] and [2/2].
Sorry, but I had this "Sheesh, why didn't I think of that earlier before
wasting Nguyễn's time" moment.
Why don't we just test what we _want to_ test? After all what a67e281
(grep: do not do external grep on skip-worktree entries, 2009-12-30)
wanted to make sure was this:
"git grep" (without --cached) should grep from the index for paths
that are marked as skip-worktree.
So how about writing some string that does not appear in the version in
the index in the work tree file, and run "git grep" to make sure it
doesn't find it?
Yes, some implementations/builds of "git grep" may not even try to cheat
and run external grep and for them the test _should_ succeed (but your
logic to check with ce_skip_worktree() in grep_cache() may be broken by
later patch while you are looking the other way), and some will try to
cheat and the fix was about not letting them.
So by writing the test to check the desired outcome, instead of writing it
for the particular implementation of using external grep optimization, you
will catch both kinds of breakages.
Perhaps something like this (untested, of course)?
test_expect_success 'strings in work tree files are not found for skip-wt paths' '
no="no such string in the index" &&
test_must_fail git grep -e "$no" --cached file &&
git update-index --skip-worktree file &&
echo "$no" >file &&
test_must_fail git grep -e "$no" file &&
git update-index --no-skip-worktree file &&
git grep -e "$no" file
'
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2010, #02 draft; Wed, 06)
From: Sverre Rabbelier @ 2010-01-07 4:42 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Junio C Hamano
In-Reply-To: <7vaawqna55.fsf@alter.siamese.dyndns.org>
Heya,
On Wed, Jan 6, 2010 at 17:25, Junio C Hamano <gitster@pobox.com> wrote:
> * 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
>
> http://thread.gmane.org/gmane.comp.version-control.git/134540
>
> I haven't seen comments on this round, and I am tempted to merge it to
> 'next' soonish. Please file complaints before I do so if people have
> objections.
Shawn, it would be awesome if you could review this and let me know
what you think of it.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: checkout -m dumping core
From: Junio C Hamano @ 2010-01-07 5:07 UTC (permalink / raw)
To: Daniel; +Cc: Git List, Tomas Carnecky
In-Reply-To: <2b9e2ea1.461a9565.4b4445be.38bda@o2.pl>
Daniel <mjucde@o2.pl> writes:
> Does this patch help?
There actually is no point running parse_commit() at that point, as the
code obtained old->commit from lookup_commit_reference_gently() in
switch_branches() which must have already parsed it. We do use it to try
switching the branches before falling back to the --merge mode (or we
notice old->commit does not exist and switch from an empty tree).
Instead of silently dying without diagnosing what paths are problematic
like your patch does, we can unsquelch the error from the unpack_tree() we
run before falling back to the --merge mode, and allow it to notice and
report the paths that will be overwritten (since you do not have HEAD,
everything in the work tree will be overwritten). Perhaps like this.
builtin-checkout.c | 10 ++++++++--
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/builtin-checkout.c b/builtin-checkout.c
index 64f3a11..2708669 100644
--- a/builtin-checkout.c
+++ b/builtin-checkout.c
@@ -397,7 +397,7 @@ static int merge_working_tree(struct checkout_opts *opts,
topts.initial_checkout = is_cache_unborn();
topts.update = 1;
topts.merge = 1;
- topts.gently = opts->merge;
+ topts.gently = opts->merge && old->commit;
topts.verbose_update = !opts->quiet;
topts.fn = twoway_merge;
topts.dir = xcalloc(1, sizeof(*topts.dir));
@@ -422,7 +422,13 @@ static int merge_working_tree(struct checkout_opts *opts,
struct merge_options o;
if (!opts->merge)
return 1;
- parse_commit(old->commit);
+
+ /*
+ * Without old->commit, the below is the same as
+ * the two-tree unpack we already tried and failed.
+ */
+ if (!old->commit)
+ return 1;
/* Do more real merge */
^ permalink raw reply related
* Re: [spf:guess] Re: [PATCH 1/2] git-svn: ignore changeless commits when checking for a cherry-pick
From: Eric Wong @ 2010-01-07 6:49 UTC (permalink / raw)
To: Sam Vilain; +Cc: Andrew Myrick, git
In-Reply-To: <4B4510EE.4090504@vilain.net>
Sam Vilain <sam@vilain.net> wrote:
> Eric Wong wrote:
> > Andrew Myrick <amyrick@apple.com> wrote:
> >
> >> diff --git a/git-svn.perl b/git-svn.perl
> >
> > Hi Andrew,
> >
> > I'll again defer to Sam for Acks on these. Test cases would be nice to
> > have, too.
> >
>
> They look fine to me, agreed a test case would be nice and make sure the
> features aren't lost later inadvertently.
Thanks Sam,
Shall I consider this an Ack and push Andrew's new changes
up while waiting for test cases?
--
Eric Wong
^ 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