* Re: [PATCH 3/5] setup_revisions: remember whether a ref was positive or not
From: Junio C Hamano @ 2011-08-08 22:36 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Junio C Hamano, Johannes Schindelin, Jonathan Nieder, Jeff King,
Git List, Daniel Barkalow, Ramkumar Ramachandra, Dmitry Ivankov
In-Reply-To: <CAGdFq_joHskwhp=934OjirmXiRMR3NbGd4s-hSjJc-gCFT_Jew@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> On Tue, Aug 9, 2011 at 00:07, Junio C Hamano <gitster@pobox.com> wrote:
>> Sverre Rabbelier <srabbelier@gmail.com> writes:
>>> Nobody needs the stuff you mentioned right now.
>>
>> Wrong.
>>
>> "diff ^C A B" is a bug, isn't it? And that is a bug in the current code.
>
> I think I missed something, can you point me to the relevant thread
> about this bug in diff? Maybe I can convince the people involved in
> fixing that to help out.
It is in this thread; <7vy5zabbz7.fsf@alter.siamese.dyndns.org>
^ permalink raw reply
* Re: [PATCH 3/5] setup_revisions: remember whether a ref was positive or not
From: Sverre Rabbelier @ 2011-08-08 22:38 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Jonathan Nieder, Jeff King, Git List,
Daniel Barkalow, Ramkumar Ramachandra, Dmitry Ivankov
In-Reply-To: <7vliv3v8cx.fsf@alter.siamese.dyndns.org>
Heya,
On Tue, Aug 9, 2011 at 00:36, Junio C Hamano <gitster@pobox.com> wrote:
> It is in this thread; <7vy5zabbz7.fsf@alter.siamese.dyndns.org>
Then I don't understand why you're mentioning it in reference to a
problem someone is actually having?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH 3/5] setup_revisions: remember whether a ref was positive or not
From: Junio C Hamano @ 2011-08-08 22:46 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Johannes Schindelin, Jonathan Nieder, Jeff King, Git List,
Daniel Barkalow, Ramkumar Ramachandra, Dmitry Ivankov
In-Reply-To: <CAGdFq_iHBE7eESpsX_doyfJu6EAkPOJpBgqkw1psMhqATf2oCw@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> On Tue, Aug 9, 2011 at 00:36, Junio C Hamano <gitster@pobox.com> wrote:
>> It is in this thread; <7vy5zabbz7.fsf@alter.siamese.dyndns.org>
>
> Then I don't understand why you're mentioning it in reference to a
> problem someone is actually having?
What?
Why isn't it a real problem when I have it in the currently released code,
and why is it a real problem if you have it with your wip series that uses
the current code? Both are real problems that somebody is actually
having.
^ permalink raw reply
* Re: [PATCH 3/5] setup_revisions: remember whether a ref was positive or not
From: Sverre Rabbelier @ 2011-08-08 22:48 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Jonathan Nieder, Jeff King, Git List,
Daniel Barkalow, Ramkumar Ramachandra, Dmitry Ivankov
In-Reply-To: <7vhb5rv7x0.fsf@alter.siamese.dyndns.org>
Heya,
On Tue, Aug 9, 2011 at 00:46, Junio C Hamano <gitster@pobox.com> wrote:
> Why isn't it a real problem when I have it in the currently released code,
> and why is it a real problem if you have it with your wip series that uses
> the current code? Both are real problems that somebody is actually
> having.
Because no actual users are actually having this problem (e.g., at
times typing "git diff ^C A B" and are seriously troubled by it), or
at least haven't spoken up? Or do you meant that you are that user?
I'm confused.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH 3/5] setup_revisions: remember whether a ref was positive or not
From: Junio C Hamano @ 2011-08-08 22:56 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Junio C Hamano, Johannes Schindelin, Jonathan Nieder, Jeff King,
Git List, Daniel Barkalow, Ramkumar Ramachandra, Dmitry Ivankov
In-Reply-To: <CAGdFq_jzraS-_afjs+MmRS4ML805h73hXAjrRkrQ=tGUdSQqkQ@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
>> Please remind yourself why then it is not sufficient for your patch to
>> read from the name field please?
>
> Sure, we could do it. But it would be duplicating all the effort
> already being done in rev-parse!
>
>> After all, wasn't the issue that "master^0..master" yields an empty set
>> but you somehow wanted to know that the RHS of that dotdot was given as a
>> positive ref?
>
> The issue was that if I push "master" to origin but I already pushed a
> "next" which points at the same commit nothing happens...
Would we have the same issue with "git bundle", by the way, caused by the
same setup_revisions() limitation? Over there we would also need to
decide the set of refs that the user wanted to record their values while
computing the set of commits we would need to transfer.
In this message I am not interested in talking about what implementation
to use to fix it, but just wondering the scope of the same issue and
trying to figure out the (positive) impact of _a_ fix.
^ permalink raw reply
* Re: [PATCH 39/48] merge-recursive: Fix rename/rename(1to2) resolution for virtual merge base
From: Elijah Newren @ 2011-08-08 22:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, jgfouca
In-Reply-To: <7vhb6aqdw7.fsf@alter.siamese.dyndns.org>
On Mon, Jul 25, 2011 at 2:55 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Elijah Newren <newren@gmail.com> writes:
>> + update_file(o, 0, mfi.sha, mfi.mode, src);
>> + remove_file_from_cache(ren1_dst);
>> + remove_file_from_cache(ren2_dst);
>
> ... the use of "src" here is taking a "middle ground" and punting on
> resolving the conflicting opinions of both branches for the outer merge to
> resolve. I think that is a sensible thing to do.
>
> The rename destinations of both branches are removed. What happens if
> ren1_dst (the path one branch wanted to rename src to) were added by the
> other branch (which wanted to rename src to ren2_dst), causing rename/add
> conflict between branches (i.e. not the one you worry about in the above
> FIXME which is about one branch renaming src to ren1_dst while adding an
> unrelated content to src)?
You found another bug; this time one that was already present in git
rather than having been introduced by my series (the
remove_file_from_cache() calls were already present, I just moved them
around a little bit). I have a testcase that exposes this new bug
now.
Good catch. :-)
^ permalink raw reply
* What's cooking in git.git (Aug 2011, #02; Mon, 8)
From: Junio C Hamano @ 2011-08-08 22:59 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'.
There are a few 'fixup!' commits queued in topics still in 'pu', so that
authors have a choice to just say "that fix looks good, squash it in!"
instead of going through an extra round.
--------------------------------------------------
[Graduated to "master"]
* jc/diff-index-refactor (2011-07-13) 2 commits
(merged to 'next' on 2011-08-01 at 98d8b08)
+ diff-lib: refactor run_diff_index() and do_diff_cache()
+ diff-lib: simplify do_diff_cache()
* jc/pack-order-tweak (2011-07-08) 2 commits
(merged to 'next' on 2011-07-25 at 1460c31)
+ pack-objects: optimize "recency order"
+ core: log offset pack data accesses happened
* jk/reset-reflog-message-fix (2011-07-22) 1 commit
(merged to 'next' on 2011-08-01 at 6c88837)
+ reset: give better reflog messages
* jl/submodule-status-summary-doc (2011-08-01) 1 commit
(merged to 'next' on 2011-08-03 at 88f97a9)
+ Documentation/submodule: add command references and update options
* jl/submodule-update-quiet (2011-07-28) 1 commit
(merged to 'next' on 2011-08-01 at c611587)
+ submodule: update and add must honor --quiet flag
* jn/gitweb-config-list-case (2011-07-31) 1 commit
(merged to 'next' on 2011-08-01 at 9268738)
+ gitweb: Git config keys are case insensitive, make config search too
* jn/gitweb-system-config (2011-07-24) 1 commit
(merged to 'next' on 2011-08-01 at 4941e45)
+ gitweb: Introduce common system-wide settings for convenience
* js/ls-tree-error (2011-07-25) 2 commits
(merged to 'next' on 2011-08-01 at 61bae55)
+ Ensure git ls-tree exits with a non-zero exit code if read_tree_recursive fails.
+ Add a test to check that git ls-tree sets non-zero exit code on error.
* ms/reflog-show-is-default (2011-08-01) 1 commit
(merged to 'next' on 2011-08-03 at ae9cf6f)
+ reflog: actually default to subcommand 'show'
* oa/pull-reflog (2011-08-01) 1 commit
(merged to 'next' on 2011-08-03 at faeff94)
+ pull: remove extra space from reflog message
* tc/minix (2011-07-20) 1 commit
(merged to 'next' on 2011-07-25 at 36ad29f)
+ Makefile: add Minix configuration options.
--------------------------------------------------
[New Topics]
* jc/maint-combined-diff-work-tree (2011-08-04) 1 commit
(merged to 'next' on 2011-08-05 at 976a4d4)
+ diff -c/--cc: do not mistake "resolved as deletion" as "use working tree"
Will merge to "master" after cooking for a bit more.
* jk/fast-export-quote-path (2011-08-05) 1 commit
(merged to 'next' on 2011-08-05 at a80e5f5)
+ fast-export: quote paths in output
Will merge to "master".
* js/sh-style (2011-08-05) 2 commits
- filter-branch.sh: de-dent usage string
- misc-sh: fix up whitespace in some other .sh files.
Will merge to "next".
* ma/am-exclude (2011-08-03) 1 commit
(merged to 'next' on 2011-08-05 at 658e57c)
+ am: pass exclude down to apply
Will merge to "master" after cooking for a bit more.
* po/cygwin-backslash (2011-08-05) 2 commits
- On Cygwin support both UNIX and DOS style path-names
- git-compat-util: add generic find_last_dir_sep that respects is_dir_sep
I think a further refactoring (no, not my suggestion) was offered?
* rc/maint-http-wrong-free (2011-08-03) 2 commits
(merged to 'next' on 2011-08-05 at cea08ed)
+ Makefile: some changes for http-related flag documentation
+ http.c: fix an invalid free()
Will merge to "master".
* db/am-skip-blank-at-the-beginning (2011-08-08) 2 commits
- RE: [PATCH v2] am: ignore leading whitespace before patch
- am: ignore leading whitespace before patch
Hmmm, perhaps mailinfo should consider [Rr][Ee]: instead of [Rr]e:
as a known noise?
Will merge to "next" after squashing them into one.
* jc/maint-smart-http-race-upload-pack (2011-08-08) 1 commit
- helping smart-http/stateless-rpc fetch race
Will merge to "next".
* jn/maint-test-return (2011-08-08) 2 commits
- test: cope better with use of return for errors
- test: simplify return value of test_run_
Will merge to "next".
* rt/zlib-smaller-window (2011-08-08) 3 commits
- test: consolidate definition of $LF
- fixup! Tolerate zlib deflation with window
- Tolerate zlib deflation with window size < 32Kb
Will merge to "next" after squashing the second one into the bottom one.
* fg/submodule-git-file-git-dir (2011-08-08) 3 commits
- Move git-dir for submodules
- fixup! rev-parse: add option --is-well-formed-git-dir
- rev-parse: add option --is-well-formed-git-dir <path>
--------------------------------------------------
[Stalled]
* jc/merge-reword (2011-05-25) 2 commits
- merge: mark the final "Merge made by..." message for l10n
- merge: reword the final message
Probably the topmost commit should be dropped.
* cb/maint-ls-files-error-report (2011-08-01) 2 commits
- squash! ls-files: fix pathspec display on error
- ls-files: fix pathspec display on error
Will merge to "next" after getting an Ack for the fix-up and squashing it.
* ac/describe-dirty-refresh (2011-08-01) 2 commits
- fixup! describe: Refresh the index when run with --dirty
- describe: Refresh the index when run with --dirty
Will merge to "next" after squashing the fixup into the bottom one.
* nk/branch-v-abbrev (2011-07-01) 1 commit
- branch -v: honor core.abbrev
Perhaps needs an updated commit log message?
* di/fast-import-doc (2011-07-13) 2 commits
- doc/fast-import: document feature import-marks-if-exists
- doc/fast-import: clarify notemodify command
Comments from fast-import folks?
* jh/receive-count-limit (2011-05-23) 10 commits
- receive-pack: Allow server to refuse pushes with too many objects
- pack-objects: Estimate pack size; abort early if pack size limit is exceeded
- send-pack/receive-pack: Allow server to refuse pushing too large packs
- pack-objects: Allow --max-pack-size to be used together with --stdout
- send-pack/receive-pack: Allow server to refuse pushes with too many commits
- pack-objects: Teach new option --max-commit-count, limiting #commits in pack
- receive-pack: Prepare for addition of the new 'limit-*' family of capabilities
- Tighten rules for matching server capabilities in server_supports()
- send-pack: Attempt to retrieve remote status even if pack-objects fails
- Update technical docs to reflect side-band-64k capability in receive-pack
Would need another round to separate per-pack and per-session limits.
* jm/mergetool-pathspec (2011-06-22) 2 commits
- mergetool: Don't assume paths are unmerged
- mergetool: Add tests for filename with whitespace
I think this is a good idea, but it probably needs a re-roll.
Cf. $gmane/176254, 176255, 166256
* jk/generation-numbers (2011-07-14) 7 commits
- limit "contains" traversals based on commit generation
- check commit generation cache validity against grafts
- pretty: support %G to show the generation number of a commit
- commit: add commit_generation function
- add metadata-cache infrastructure
- decorate: allow storing values instead of pointers
- Merge branch 'jk/tag-contains-ab' (early part) into HEAD
The initial "tag --contains" de-pessimization without need for generation
numbers is already in; backburnered.
* en/merge-recursive (2011-08-04) 49 commits
- t3030: fix accidental success in symlink rename
- merge-recursive: Fix working copy handling for rename/rename/add/add
- merge-recursive: add handling for rename/rename/add-dest/add-dest
- merge-recursive: Have conflict_rename_delete reuse modify/delete code
- merge-recursive: Make modify/delete handling code reusable
- merge-recursive: Consider modifications in rename/rename(2to1) conflicts
- merge-recursive: Create function for merging with branchname:file markers
- merge-recursive: Record more data needed for merging with dual renames
- merge-recursive: Defer rename/rename(2to1) handling until process_entry
- merge-recursive: Small cleanups for conflict_rename_rename_1to2
- merge-recursive: Fix rename/rename(1to2) resolution for virtual merge base
- merge-recursive: Introduce a merge_file convenience function
- merge-recursive: Fix modify/delete resolution in the recursive case
- merge-recursive: Provide more info in conflict markers with file renames
- merge-recursive: Cleanup and consolidation of rename_conflict_info
- merge-recursive: Consolidate process_entry() and process_df_entry()
- merge-recursive: Improve handling of rename target vs. directory addition
- merge-recursive: Add comments about handling rename/add-source cases
- merge-recursive: Make dead code for rename/rename(2to1) conflicts undead
- merge-recursive: Fix deletion of untracked file in rename/delete conflicts
- merge-recursive: When we detect we can skip an update, actually skip it
- merge-recursive: Split update_stages_and_entry; only update stages at end
- merge-recursive: Consolidate different update_stages functions
- merge-recursive: Allow make_room_for_path() to remove D/F entries
- merge-recursive: Split was_tracked() out of would_lose_untracked()
- merge-recursive: Save D/F conflict filenames instead of unlinking them
- merge-recursive: Fix code checking for D/F conflicts still being present
- merge-recursive: Fix sorting order and directory change assumptions
- merge-recursive: Fix recursive case with D/F conflict via add/add conflict
- merge-recursive: Avoid working directory changes during recursive case
- merge-recursive: Remember to free generated unique path names
- merge-recursive: Mark some diff_filespec struct arguments const
- merge-recursive: Correct a comment
- merge-recursive: Make BUG message more legible by adding a newline
- t6022: Add testcase for merging a renamed file with a simple change
- t6022: New tests checking for unnecessary updates of files
- t6022: Remove unnecessary untracked files to make test cleaner
- t6036: criss-cross + rename/rename(1to2)/add-source + modify/modify
- t6036: criss-cross w/ rename/rename(1to2)/modify+rename/rename(2to1)/modify
- t6036: tests for criss-cross merges with various directory/file conflicts
- t6036: criss-cross with weird content can fool git into clean merge
- t6036: Add differently resolved modify/delete conflict in criss-cross test
- t6042: Ensure rename/rename conflicts leave index and workdir in sane state
- t6042: Add failing testcases for rename/rename/add-{source,dest} conflicts
- t6042: Add tests for content issues with modify/rename/directory conflicts
- t6042: Add a testcase where undetected rename causes silent file deletion
- t6042: Add a pair of cases where undetected renames cause issues
- t6042: Add failing testcase for rename/modify/add-source conflict
- t6042: Add a testcase where git deletes an untracked file
Re-roll being worked on.
* sr/transport-helper-fix-rfc (2011-07-19) 2 commits
- t5800: point out that deleting branches does not work
- t5800: document inability to push new branch with old content
--------------------------------------------------
[Cooking]
* ef/ipv4-connect-error-report (2011-08-01) 2 commits
(merged to 'next' on 2011-08-03 at ea4842b)
+ connect: only log if all attempts failed (ipv4)
+ Merge branch 'maint' into ef/ipv4-connect-error-report
Will merge to "master".
* js/bisect-no-checkout (2011-08-05) 10 commits
- bisect: further style nitpicks
- bisect: replace "; then" with "\n<tab>*then"
- bisect: cleanup whitespace errors in git-bisect.sh.
- bisect: add documentation for --no-checkout option.
- bisect: add tests for the --no-checkout option.
- bisect: introduce --no-checkout support into porcelain.
- bisect: introduce support for --no-checkout option.
- bisect: add tests to document expected behaviour in presence of broken trees.
- bisect: use && to connect statements that are deferred with eval.
- bisect: move argument parsing before state modification.
Will merge to "next".
* rs/grep-function-context (2011-08-01) 2 commits
(merged to 'next' on 2011-08-05 at 8d63a8c)
+ grep: long context options
+ grep: add option to show whole function as context
Will merge to "master".
* cb/partial-commit-relative-pathspec (2011-08-02) 1 commit
(merged to 'next' on 2011-08-03 at 6918f69)
+ commit: allow partial commits with relative paths
Ideally the pathspec-prefix helper should be renamed to something more
sensible, but we could live with it for now.
* cb/maint-exec-error-report (2011-08-01) 2 commits
(merged to 'next' on 2011-08-05 at 2764424)
+ notice error exit from pager
+ error_routine: use parent's stderr if exec fails
Will merge to "master" after cooking for a bit more.
* cb/maint-quiet-push (2011-08-08) 2 commits
(merged to 'next' on 2011-08-08 at 917d73b)
+ receive-pack: do not overstep command line argument array
(merged to 'next' on 2011-08-01 at 87df938)
+ propagate --quiet to send-pack/receive-pack
Will merge to "master" after cooking for a bit more.
* jk/add-i-hunk-filter (2011-07-27) 5 commits
- add--interactive: add option to autosplit hunks
- add--interactive: allow negatation of hunk filters
- add--interactive: allow hunk filtering on command line
- add--interactive: factor out regex error handling
- add--interactive: refactor patch mode argument processing
Will merge to "next".
* mh/check-attr-listing (2011-08-04) 23 commits
- Rename git_checkattr() to git_check_attr()
- git-check-attr: Fix command-line handling to match docs
- git-check-attr: Drive two tests using the same raw data
- git-check-attr: Add an --all option to show all attributes
- git-check-attr: Error out if no pathnames are specified
- git-check-attr: Process command-line args more systematically
- git-check-attr: Handle each error separately
- git-check-attr: Extract a function error_with_usage()
- git-check-attr: Introduce a new variable
- git-check-attr: Extract a function output_attr()
- Allow querying all attributes on a file
- Remove redundant check
- Remove redundant call to bootstrap_attr_stack()
- Extract a function collect_all_attrs()
- Teach prepare_attr_stack() to figure out dirlen itself
- git-check-attr: Use git_attr_name()
- Provide access to the name attribute of git_attr
- git-check-attr: Add tests of command-line parsing
- git-check-attr: Add missing "&&"
- Disallow the empty string as an attribute name
- Remove anachronism from comment
- doc: Correct git_attr() calls in example code
- doc: Add a link from gitattributes(5) to git-check-attr(1)
(this branch is used by mh/check-attr-relative.)
Will merge to "next".
* mh/check-attr-relative (2011-08-04) 6 commits
- test-path-utils: Add subcommand "prefix_path"
- test-path-utils: Add subcommand "absolute_path"
- git-check-attr: Normalize paths
- git-check-attr: Demonstrate problems with relative paths
- git-check-attr: Demonstrate problems with unnormalized paths
- git-check-attr: test that no output is written to stderr
(this branch uses mh/check-attr-listing.)
Will merge to "next".
* jk/http-auth-keyring (2011-08-03) 13 commits
(merged to 'next' on 2011-08-03 at b06e80e)
+ credentials: add "getpass" helper
+ credentials: add "store" helper
+ credentials: add "cache" helper
+ docs: end-user documentation for the credential subsystem
+ http: use hostname in credential description
+ allow the user to configure credential helpers
+ look for credentials in config before prompting
+ http: use credential API to get passwords
+ introduce credentials API
+ http: retry authentication failures for all http requests
+ remote-curl: don't retry auth failures with dumb protocol
+ improve httpd auth tests
+ url: decode buffers that are not NUL-terminated
Looked mostly reasonable except for the limitation that it is not clear
how to deal with a site at which a user needs to use different passwords
for different repositories.
* js/ref-namespaces (2011-07-21) 5 commits
(merged to 'next' on 2011-07-25 at 5b7dcfe)
+ ref namespaces: tests
+ ref namespaces: documentation
+ ref namespaces: Support remote repositories via upload-pack and receive-pack
+ ref namespaces: infrastructure
+ Fix prefix handling in ref iteration functions
* rc/histogram-diff (2011-08-08) 12 commits
- xdiff/xhistogram: drop need for additional variable
- xdiff/xhistogram: rely on xdl_trim_ends()
- xdiff/xhistogram: rework handling of recursed results
- xdiff: do away with xdl_mmfile_next()
(merged to 'next' on 2011-08-03 at f9e2328)
+ Make test number unique
(merged to 'next' on 2011-07-25 at 3351028)
+ xdiff/xprepare: use a smaller sample size for histogram diff
+ xdiff/xprepare: skip classification
+ teach --histogram to diff
+ t4033-diff-patience: factor out tests
+ xdiff/xpatience: factor out fall-back-diff function
+ xdiff/xprepare: refactor abort cleanups
+ xdiff/xprepare: use memset()
Will merge to "next".
* rr/revert-cherry-pick-continue (2011-08-08) 18 commits
- revert: Propagate errors upwards from do_pick_commit
- revert: Introduce --continue to continue the operation
- revert: Don't implicitly stomp pending sequencer operation
- revert: Remove sequencer state when no commits are pending
- reset: Make reset remove the sequencer state
- revert: Introduce --reset to remove sequencer state
- revert: Make pick_commits functionally act on a commit list
- revert: Save command-line options for continuing operation
- revert: Save data for continuing after conflict resolution
- revert: Don't create invalid replay_opts in parse_args
- revert: Separate cmdline parsing from functional code
- revert: Introduce struct to keep command-line options
- revert: Eliminate global "commit" variable
- revert: Rename no_replay to record_origin
- revert: Don't check lone argument in get_encoding
- revert: Simplify and inline add_message_to_msg
- config: Introduce functions to write non-standard file
- advice: Introduce error_resolve_conflict
Getting into a reasonable shape. Is another round of re-roll coming?
^ permalink raw reply
* Re: [PATCH 3/5] setup_revisions: remember whether a ref was positive or not
From: Sverre Rabbelier @ 2011-08-08 23:04 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Jonathan Nieder, Jeff King, Git List,
Daniel Barkalow, Ramkumar Ramachandra, Dmitry Ivankov
In-Reply-To: <7vd3gfv7gd.fsf@alter.siamese.dyndns.org>
Heya,
On Tue, Aug 9, 2011 at 00:56, Junio C Hamano <gitster@pobox.com> wrote:
> Would we have the same issue with "git bundle", by the way, caused by the
> same setup_revisions() limitation? Over there we would also need to
> decide the set of refs that the user wanted to record their values while
> computing the set of commits we would need to transfer.
I think so.
$ git init test && cd test
Initialized empty Git repository in /home/sverre/code/test/test/.git/
$ echo content >> file
$ git add file && git commit -m "first"
[master (root-commit) c7f5a27] first
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 file
$ (git init ../another && cd ../another && git pull ../test)
Initialized empty Git repository in /home/sverre/code/another/.git/
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From ../test
* branch HEAD -> FETCH_HEAD
sverre@laptop-sverre:~/code/test
$ git branch second
$ git bundle create bundle second
Counting objects: 3, done.
Writing objects: 100% (3/3), 215 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
sverre@laptop-sverre:~/code/test
$ mv bundle ../another/
$ (cd ../another/ && git bundle unbundle bundle)
c7f5a273b11a438bf78aecff0dfcbb8b16344555 refs/heads/second
$ (cd ../another/ && git for-each-ref)
c7f5a273b11a438bf78aecff0dfcbb8b16344555 commit refs/heads/master
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [RFC] helping smart-http/stateless-rpc fetch race
From: Ilari Liusvaara @ 2011-08-08 23:08 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Junio C Hamano, Shawn Pearce, git
In-Reply-To: <CAGdFq_i=8p4jvKo1C=UFpmQyPtUd9JOtr9VW8vn7viC0dQkQmg@mail.gmail.com>
On Mon, Aug 08, 2011 at 11:05:27PM +0200, Sverre Rabbelier wrote:
> Heya,
>
> On Mon, Aug 8, 2011 at 19:13, Junio C Hamano <gitster@pobox.com> wrote:
> >> (1) It might make sense to give admins who run upload-pack not behind
> >> smart-http an option to allow fetching from a non-tip; and
>
> You said earlier it isn't needed since the server process caches the
> refs for git and ssh, that leaves dumb-http right?
It seems that everything currently possible falls into three
categories:
1) Stateful upload-pack (git://, file://, ssh://, CONNECT): No fix
needed.
2) Stateless upload-pack (smart http://, some bizarre helper):
Needs fix to avoid races.
3) Dumb protocols (dumb http://, ftp://, rsync://): Won't invoke
upload-pack anyway, no fix needed.
So I think that the only thing that needs the option to allow
fetching from non-tips is anything using --stateless-rpc.
-Ilari
^ permalink raw reply
* Re: [PATCH 3/5] setup_revisions: remember whether a ref was positive or not
From: Junio C Hamano @ 2011-08-08 23:17 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Johannes Schindelin, Jonathan Nieder, Jeff King, Git List,
Daniel Barkalow, Ramkumar Ramachandra, Dmitry Ivankov
In-Reply-To: <CAGdFq_ioxeZUCnn-fFKuiT-6eVzVoph8eQE2j0hEbAxtDZzGnQ@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> Because no actual users are actually having this problem (e.g., at
> times typing "git diff ^C A B" and are seriously troubled by it), or
> at least haven't spoken up? Or do you meant that you are that user?
Yes, I am that user who have been disturbed by the command line revision
parser limitation for a loooooooong time and have been wanting to see it
properly fixed for quite a while (by myself or by somebody else).
Otherwise why would I have bothered to spend 93 lines to describe it and
its one possible solution that I _think_ is general enough to cover both
of the real issue identified in this thread?
I may probably be being slightly unfair, for two reasons. The primary
reason is because the affected codepath is so central to the UI that
fixing this properly is more important than various random tweaks we make
in other areas (which makes me particularly picky with respect to ensuring
that the future expansion would be easy). Seeing a single-bit "hack" not
from a complete newbie but from two known-to-be-competent long timers of
Git is another.
There are numerous hacks that try to work around the same revision parser
limitation (lossage of information), and I have been hoping that a series
that touch the parser to leave more information during parsing to be
cleanly enhancible to get rid of them (e.g. "git checkout $commit" vs "git
checkout $branch" looks at the command line itself, but it should be able
to call into the revision parser and inspect what the parser gives it
back).
^ permalink raw reply
* Re: [RFC] helping smart-http/stateless-rpc fetch race
From: Junio C Hamano @ 2011-08-08 23:24 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: Sverre Rabbelier, Shawn Pearce, git
In-Reply-To: <20110808230812.GA16974@LK-Perkele-VI.localdomain>
Ilari Liusvaara <ilari.liusvaara@elisanet.fi> writes:
> On Mon, Aug 08, 2011 at 11:05:27PM +0200, Sverre Rabbelier wrote:
>> Heya,
>>
>> On Mon, Aug 8, 2011 at 19:13, Junio C Hamano <gitster@pobox.com> wrote:
>> >> (1) It might make sense to give admins who run upload-pack not behind
>> >> smart-http an option to allow fetching from a non-tip; and
>>
>> You said earlier it isn't needed since the server process caches the
>> refs for git and ssh, that leaves dumb-http right?
>
> It seems that everything currently possible falls into three
> categories:
>
> 1) Stateful upload-pack (git://, file://, ssh://, CONNECT): No fix
> needed.
> 2) Stateless upload-pack (smart http://, some bizarre helper):
> Needs fix to avoid races.
> 3) Dumb protocols (dumb http://, ftp://, rsync://): Won't invoke
> upload-pack anyway, no fix needed.
>
> So I think that the only thing that needs the option to allow
> fetching from non-tips is anything using --stateless-rpc.
These (1) and (2) were never meant to be fixes to work around the
smart-http protocol limitation; I know "No fix _needed_" and it was never
a consideration to decide (or choose not to decide) about these two
points.
A separate option would allow admins to let their clients ask to fetch
4bc5fbf (that is v0.99~2) even if that commit is not at the tip of any ref
if they choose to. That is what (1) is about, and people who do not want
a separate option needs to argue that it is an unnecessary "feature".
^ permalink raw reply
* Re: [PATCH 3/5] setup_revisions: remember whether a ref was positive or not
From: Sverre Rabbelier @ 2011-08-08 23:25 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Jonathan Nieder, Jeff King, Git List,
Daniel Barkalow, Ramkumar Ramachandra, Dmitry Ivankov
In-Reply-To: <7vy5z3trwu.fsf@alter.siamese.dyndns.org>
Heya,
On Tue, Aug 9, 2011 at 01:17, Junio C Hamano <gitster@pobox.com> wrote:
> Yes, I am that user who have been disturbed by the command line revision
> parser limitation for a loooooooong time and have been wanting to see it
> properly fixed for quite a while (by myself or by somebody else).
Aaaah, well that does explain a thing or two :).
> Seeing a single-bit "hack" not
> from a complete newbie but from two known-to-be-competent long timers of
> Git is another.
Perhaps known-to-be-competent, but time-constrained nonetheless.
Sometimes one is forced to chose between fixing something you care
about and doing something in a non-hacky way... There's only so much
time in a day to work on side-projects such as this after all :).
> There are numerous hacks that try to work around the same revision parser
> limitation (lossage of information), and I have been hoping that a series
> that touch the parser to leave more information during parsing to be
> cleanly enhancible to get rid of them (e.g. "git checkout $commit" vs "git
> checkout $branch" looks at the command line itself, but it should be able
> to call into the revision parser and inspect what the parser gives it
> back).
Ok, knowing that, I am somewhat more inclined to have a look at this.
I'm still not sure that I know how to implement the design you
described though. I mean, I understand the general concept, but I have
no idea in what places it would need to hook in to make it work (ditto
on how to fix the diff bug).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [RFC] helping smart-http/stateless-rpc fetch race
From: Junio C Hamano @ 2011-08-08 23:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ilari Liusvaara, Sverre Rabbelier, Shawn Pearce, git
In-Reply-To: <7vty9rtrk4.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> A separate option would allow admins to let their clients ask to fetch
> 4bc5fbf (that is v0.99~2) even if that commit is not at the tip of any ref
> if they choose to. That is what (1) is about, and people who do not want
> a separate option needs to argue that it is an unnecessary "feature".
By the way, I personally do not think it is necessary, but as long timers
on the list may recall, this has come up on the list for a few times.
^ permalink raw reply
* Re: [RFC] helping smart-http/stateless-rpc fetch race
From: Shawn Pearce @ 2011-08-08 23:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ilari Liusvaara, Sverre Rabbelier, git
In-Reply-To: <7vpqkftrhg.fsf@alter.siamese.dyndns.org>
On Mon, Aug 8, 2011 at 16:26, Junio C Hamano <gitster@pobox.com> wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> A separate option would allow admins to let their clients ask to fetch
>> 4bc5fbf (that is v0.99~2) even if that commit is not at the tip of any ref
>> if they choose to. That is what (1) is about, and people who do not want
>> a separate option needs to argue that it is an unnecessary "feature".
>
> By the way, I personally do not think it is necessary, but as long timers
> on the list may recall, this has come up on the list for a few times.
My feeling is clients aren't likely to do this, or grow this feature
anytime soon, so why add a backend option for it now? Lets add the
feature when the feature is necessary... and right now just fix the
race in smart HTTP.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 3/5] setup_revisions: remember whether a ref was positive or not
From: Junio C Hamano @ 2011-08-08 23:39 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Johannes Schindelin, Jonathan Nieder, Jeff King, Git List,
Daniel Barkalow, Ramkumar Ramachandra, Dmitry Ivankov
In-Reply-To: <CAGdFq_hO-MYC_kXZZhoqXhTRvVhCDfTT4EHPoYDyHjGtRiSB9g@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> Ok, knowing that, I am somewhat more inclined to have a look at this.
> I'm still not sure that I know how to implement the design you
> described though. I mean, I understand the general concept, but I have
> no idea in what places it would need to hook in to make it work (ditto
> on how to fix the diff bug).
It is entirely possible, as Dscho hinted in his response, that your "flag"
word may be sufficient to encode "where did this object (whether it is
marked as uninteresting or interesting) come from? what did the user want
to do with it?" information for all practical purposes, even though I
doubt one bit would be sufficient. So how about ignoring "diff A...B" vs
"diff ^C A B" in the meantime and see if your change to revision.c is
applicable to the same issue in "git bundle" as a starter?
I would imagine that "diff A...B" vs "diff ^C A B" case would be solved by
the former (^C is the common ancestor between A and B) add a flag
COMMON_ANCESTOR to pending object array entry that holds ^C,
SYMMETRIC_LEFT to the one with A and SYMMETRIC_RIGHT to the one with B,
while the latter would stuff one SINGLE_NEGATIVE (^C), and two
SINGLE_POSITIVE (A and B), and the caller would tell between the two, or
something like that. And "bundle master^0..master" (and similarly your
export stream) would note the RHS of the dot operator with SYMMETRIC_RIGHT
so that "master", even though the commit object gets marked as
uninteresting at the end, can be recovered to be of interest to the end
user.
I am not suggesting the exact flag word names above, but just trying to
enumerate how many kinds would be needed). Your single-bit in the patch
would be SYMMETRIC_RIGHT in the above ugly notation, but you can call it
REF_INTERESTING or whatever.
^ permalink raw reply
* Re: [RFC] helping smart-http/stateless-rpc fetch race
From: Junio C Hamano @ 2011-08-08 23:42 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Junio C Hamano, Ilari Liusvaara, Sverre Rabbelier, git
In-Reply-To: <CAJo=hJu=nuy8Ws8PP16F=ay-Wp9vAdW_U113WLVCFs4hPQOeQA@mail.gmail.com>
Shawn Pearce <spearce@spearce.org> writes:
> On Mon, Aug 8, 2011 at 16:26, Junio C Hamano <gitster@pobox.com> wrote:
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>>> A separate option would allow admins to let their clients ask to fetch
>>> 4bc5fbf (that is v0.99~2) even if that commit is not at the tip of any ref
>>> if they choose to. That is what (1) is about, and people who do not want
>>> a separate option needs to argue that it is an unnecessary "feature".
>>
>> By the way, I personally do not think it is necessary, but as long timers
>> on the list may recall, this has come up on the list for a few times.
>
> My feeling is clients aren't likely to do this, or grow this feature
> anytime soon, so why add a backend option for it now? Lets add the
> feature when the feature is necessary... and right now just fix the
> race in smart HTTP.
Yes, that is what is queued in today's 'pu'.
^ permalink raw reply
* [PATCH v2 0/2] bisect: add support for bisecting bare repositories
From: Jon Seymour @ 2011-08-09 1:21 UTC (permalink / raw)
To: git; +Cc: gitster, chriscool, j6t, jnareb, jrnieder, Jon Seymour
This extension to js/bisect-no-checkout (currently in pu) adds support for bisecting bare repositories.
It does this by relaxing the requirement that git bisect is invoked in a repository with a working tree and by
defaulting to --no-checkout in the case of a bare repository.
Two tests are included to demonstrate this behaviour.
Revisions
=========
v2:
Squashed documentation patch into code change patch.
Simplified test, per Jonathan Nieder.
v1:
Initial release.
Jon Seymour (2):
bisect: relax requirement for a working tree.
bisect: add tests for bisection on bare repositories
Documentation/git-bisect.txt | 2 ++
git-bisect.sh | 8 ++++++--
git.c | 2 +-
t/t6030-bisect-porcelain.sh | 31 +++++++++++++++++++++++++++++++
4 files changed, 40 insertions(+), 3 deletions(-)
--
1.7.6.522.g810f.dirty
^ permalink raw reply
* [PATCH v2 1/2] bisect: relax requirement for a working tree.
From: Jon Seymour @ 2011-08-09 1:21 UTC (permalink / raw)
To: git; +Cc: gitster, chriscool, j6t, jnareb, jrnieder, Jon Seymour
In-Reply-To: <1312852900-29457-1-git-send-email-jon.seymour@gmail.com>
Now that bisection does not require checkout, it can work
on bare repositories too.
In this case, we default the checkout mode to --no-checkout,
thereby forcing the creation of BISECT_HEAD on either a manual
or automatic start.
The require_work_tree check in git-bisect.sh and the NEED_WORK_TREE
check in git.c are relaxed.
Suggested-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
---
Documentation/git-bisect.txt | 2 ++
git-bisect.sh | 8 ++++++--
git.c | 2 +-
3 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt
index 41e6ca8..e4f46bc 100644
--- a/Documentation/git-bisect.txt
+++ b/Documentation/git-bisect.txt
@@ -273,6 +273,8 @@ it point to the commit that should be tested.
+
This option may be useful when the test you would perform in each step
does not require a checked out tree.
++
+If the repository is bare, `--no-checkout` is assumed.
EXAMPLES
--------
diff --git a/git-bisect.sh b/git-bisect.sh
index 22c4da5..72f79d6 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -29,7 +29,6 @@ Please use "git help bisect" to get the full man page.'
OPTIONS_SPEC=
. git-sh-setup
. git-sh-i18n
-require_work_tree
_x40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'
_x40="$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40"
@@ -79,7 +78,12 @@ bisect_start() {
orig_args=$(git rev-parse --sq-quote "$@")
bad_seen=0
eval=''
- mode=''
+ if test "z$(git rev-parse --is-bare-repository)" != zfalse
+ then
+ mode=--no-checkout
+ else
+ mode=
+ fi
while [ $# -gt 0 ]; do
arg="$1"
case "$arg" in
diff --git a/git.c b/git.c
index 8828c18..7fdcab2 100644
--- a/git.c
+++ b/git.c
@@ -320,7 +320,7 @@ static void handle_internal_command(int argc, const char **argv)
{ "annotate", cmd_annotate, RUN_SETUP },
{ "apply", cmd_apply, RUN_SETUP_GENTLY },
{ "archive", cmd_archive },
- { "bisect--helper", cmd_bisect__helper, RUN_SETUP | NEED_WORK_TREE },
+ { "bisect--helper", cmd_bisect__helper, RUN_SETUP },
{ "blame", cmd_blame, RUN_SETUP },
{ "branch", cmd_branch, RUN_SETUP },
{ "bundle", cmd_bundle, RUN_SETUP_GENTLY },
--
1.7.6.522.g810f.dirty
^ permalink raw reply related
* [PATCH v2 2/2] bisect: add tests for bisection on bare repositories
From: Jon Seymour @ 2011-08-09 1:21 UTC (permalink / raw)
To: git; +Cc: gitster, chriscool, j6t, jnareb, jrnieder, Jon Seymour
In-Reply-To: <1312852900-29457-1-git-send-email-jon.seymour@gmail.com>
We add a test to check that bisection works on bare repositories
both when --no-checkout is specified explicitly and when it
is defaulted.
Improved-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
---
t/t6030-bisect-porcelain.sh | 31 +++++++++++++++++++++++++++++++
1 files changed, 31 insertions(+), 0 deletions(-)
diff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh
index 4fb7d11..62125ec 100755
--- a/t/t6030-bisect-porcelain.sh
+++ b/t/t6030-bisect-porcelain.sh
@@ -592,6 +592,37 @@ test_expect_success 'erroring out when using bad path parameters' '
grep "bad path parameters" error.txt
'
+test_expect_success 'test bisection on bare repo - --no-checkout specified' '
+ git clone --bare . bare.nocheckout &&
+ (
+ cd bare.nocheckout &&
+ git bisect start --no-checkout &&
+ git bisect good $HASH1 &&
+ git bisect bad $HASH4 &&
+ git bisect run eval \
+ "test \$(git rev-list BISECT_HEAD ^$HASH2 --max-count=1 | wc -l) = 0" \
+ >../nocheckout.log &&
+ git bisect reset
+ ) &&
+ grep "$HASH3 is the first bad commit" nocheckout.log
+'
+
+
+test_expect_success 'test bisection on bare repo - --no-checkout defaulted' '
+ git clone --bare . bare.defaulted &&
+ (
+ cd bare.defaulted &&
+ git bisect start &&
+ git bisect good $HASH1 &&
+ git bisect bad $HASH4 &&
+ git bisect run eval \
+ "test \$(git rev-list BISECT_HEAD ^$HASH2 --max-count=1 | wc -l) = 0" \
+ >../defaulted.log &&
+ git bisect reset
+ ) &&
+ grep "$HASH3 is the first bad commit" defaulted.log
+'
+
#
# This creates a broken branch which cannot be checked out because
# the tree created has been deleted.
--
1.7.6.522.g810f.dirty
^ permalink raw reply related
* Re: Suppressing auto-cc for specific addresses
From: Joe Perches @ 2011-08-09 1:41 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Daniel Mack, git, Greg Kroah-Hartman,
Ævar Arnfjörð Bjarmason, J. Bruce Fields,
Jeff King
In-Reply-To: <20110808211726.GA18619@elie.gateway.2wire.net>
On Mon, 2011-08-08 at 23:17 +0200, Jonathan Nieder wrote:
> (+cc: some send-email people)
> Daniel Mack wrote:
> > I'm looking for a way to suppress certain Cc: fields that are normally
> > automatically added for addresses mentioned in Cc: lines found in patches.
> Makes sense. Could you please add a quick commit message, following
> the guidelines in Documentation/SubmittingPatches (i.e., explaining
> the problem this intends to solve and justifying how it is solved)?
It seems an odd use case to me.
Why are these added addresses undesired?
Also this does not work for cccmd addresses.
You'll need to add similar logic to recipient_cmd
uses.
cheers, Joe
^ permalink raw reply
* Re: [PATCH v2 0/2] bisect: add support for bisecting bare repositories
From: Jonathan Nieder @ 2011-08-09 1:54 UTC (permalink / raw)
To: Jon Seymour; +Cc: git, gitster, chriscool, j6t, jnareb
In-Reply-To: <1312852900-29457-1-git-send-email-jon.seymour@gmail.com>
Jon Seymour wrote:
> This extension to js/bisect-no-checkout (currently in pu) adds
> support for bisecting bare repositories.
>
> It does this by relaxing the requirement that git bisect is invoked
> in a repository with a working tree and by defaulting to
> --no-checkout in the case of a bare repository.
>
> Two tests are included to demonstrate this behaviour.
Thanks! I think the two patches should be squashed, with the above
as commit message.
With or without that change, for what it's worth,
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
^ permalink raw reply
* [PATCH v3 1/1] bisect: add support for bisecting bare repositories
From: Jon Seymour @ 2011-08-09 2:11 UTC (permalink / raw)
To: git; +Cc: gitster, chriscool, j6t, jnareb, jrnieder, Jon Seymour
This extension to js/bisect-no-checkout adds support for bisecting bare repositories.
It does this by relaxing the requirement that git bisect is invoked in a repository with a working tree and by defaulting to --no-checkout in the case of a bare repository.
Two tests are included to demonstrate this behaviour.
Suggested-by: Junio C Hamano <gitster@pobox.com>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
---
Documentation/git-bisect.txt | 2 ++
git-bisect.sh | 8 ++++++--
git.c | 2 +-
t/t6030-bisect-porcelain.sh | 31 +++++++++++++++++++++++++++++++
4 files changed, 40 insertions(+), 3 deletions(-)
v3: squashed entire series.
diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt
index 41e6ca8..e4f46bc 100644
--- a/Documentation/git-bisect.txt
+++ b/Documentation/git-bisect.txt
@@ -273,6 +273,8 @@ it point to the commit that should be tested.
+
This option may be useful when the test you would perform in each step
does not require a checked out tree.
++
+If the repository is bare, `--no-checkout` is assumed.
EXAMPLES
--------
diff --git a/git-bisect.sh b/git-bisect.sh
index 22c4da5..e0ca3fb 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -29,7 +29,6 @@ Please use "git help bisect" to get the full man page.'
OPTIONS_SPEC=
. git-sh-setup
. git-sh-i18n
-require_work_tree
_x40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'
_x40="$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40"
@@ -79,7 +78,12 @@ bisect_start() {
orig_args=$(git rev-parse --sq-quote "$@")
bad_seen=0
eval=''
- mode=''
+ if test "z$(git rev-parse --is-bare-repository)" != zfalse
+ then
+ mode=--no-checkout
+ else
+ mode=''
+ fi
while [ $# -gt 0 ]; do
arg="$1"
case "$arg" in
diff --git a/git.c b/git.c
index 8828c18..7fdcab2 100644
--- a/git.c
+++ b/git.c
@@ -320,7 +320,7 @@ static void handle_internal_command(int argc, const char **argv)
{ "annotate", cmd_annotate, RUN_SETUP },
{ "apply", cmd_apply, RUN_SETUP_GENTLY },
{ "archive", cmd_archive },
- { "bisect--helper", cmd_bisect__helper, RUN_SETUP | NEED_WORK_TREE },
+ { "bisect--helper", cmd_bisect__helper, RUN_SETUP },
{ "blame", cmd_blame, RUN_SETUP },
{ "branch", cmd_branch, RUN_SETUP },
{ "bundle", cmd_bundle, RUN_SETUP_GENTLY },
diff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh
index 4fb7d11..62125ec 100755
--- a/t/t6030-bisect-porcelain.sh
+++ b/t/t6030-bisect-porcelain.sh
@@ -592,6 +592,37 @@ test_expect_success 'erroring out when using bad path parameters' '
grep "bad path parameters" error.txt
'
+test_expect_success 'test bisection on bare repo - --no-checkout specified' '
+ git clone --bare . bare.nocheckout &&
+ (
+ cd bare.nocheckout &&
+ git bisect start --no-checkout &&
+ git bisect good $HASH1 &&
+ git bisect bad $HASH4 &&
+ git bisect run eval \
+ "test \$(git rev-list BISECT_HEAD ^$HASH2 --max-count=1 | wc -l) = 0" \
+ >../nocheckout.log &&
+ git bisect reset
+ ) &&
+ grep "$HASH3 is the first bad commit" nocheckout.log
+'
+
+
+test_expect_success 'test bisection on bare repo - --no-checkout defaulted' '
+ git clone --bare . bare.defaulted &&
+ (
+ cd bare.defaulted &&
+ git bisect start &&
+ git bisect good $HASH1 &&
+ git bisect bad $HASH4 &&
+ git bisect run eval \
+ "test \$(git rev-list BISECT_HEAD ^$HASH2 --max-count=1 | wc -l) = 0" \
+ >../defaulted.log &&
+ git bisect reset
+ ) &&
+ grep "$HASH3 is the first bad commit" defaulted.log
+'
+
#
# This creates a broken branch which cannot be checked out because
# the tree created has been deleted.
--
1.7.6.523.g2ad34
^ permalink raw reply related
* Re: [PATCH v2 4/4] upload-archive: use start_command instead of fork
From: Jeff King @ 2011-08-09 5:02 UTC (permalink / raw)
To: René Scharfe; +Cc: Johannes Sixt, Erik Faye-Lund, Junio C Hamano, git
In-Reply-To: <4E401869.8060702@lsrfire.ath.cx>
On Mon, Aug 08, 2011 at 07:10:01PM +0200, René Scharfe wrote:
> > - tar_filter_config("tar.tgz.command", "gzip -cn", NULL);
> > + tar_filter_config("tar.tgz.command", "gzip -cn | cat", NULL);
> > tar_filter_config("tar.tgz.remote", "true", NULL);
> > - tar_filter_config("tar.tar.gz.command", "gzip -cn", NULL);
> > + tar_filter_config("tar.tar.gz.command", "gzip -cn | cat", NULL);
> > tar_filter_config("tar.tar.gz.remote", "true", NULL);
> > git_config(git_tar_config, NULL);
> > for (i = 0; i < nr_tar_filters; i++) {
> >
> > (provided that 'cat' magically does not suffer from the same problem,
> > and I do think that it does not.)
>
> The external cat can indeed be used. We'd need to do that for user
> supplied commands as well, though, like this (ugh):
>
> diff --git a/archive-tar.c b/archive-tar.c
> index 20af005..eaa9a1c 100644
> --- a/archive-tar.c
> +++ b/archive-tar.c
> @@ -326,6 +326,9 @@ static int write_tar_filter_archive(const struct archiver *ar,
> die("BUG: tar-filter archiver called with no filter defined");
>
> strbuf_addstr(&cmd, ar->data);
> +#ifdef WIN32
> + strbuf_addstr(&cmd, " | cat");
> +#endif
> if (args->compression_level >= 0)
> strbuf_addf(&cmd, " -%d", args->compression_level);
Do we need to? It seems to me that defaulting to "gzip -cn | cat" is not
"we are on Windows, a platform that needs a special workaround in git",
but rather "this gzip is horribly broken, but at build-time you can
set a gzip that works".
So if the user wants to specify some broken filter, it is up to them to
add "| cat" if their filter merits it.
But that is somewhat a matter of perception, and it won't make a user on
Windows who does "git config archive.bz2 bzip2 -c" any happier when they
are told it is their responsibility to deal with it.
BTW, as nice as this "gzip -cn | cat" idea is, I think it needs to be
wrapped in a shell script. With the code above, we will generate "gzip
-cn | cat -9". So we really need:
$ cat `which gzip`
#!/bin/sh
gzip.real -cn "$@" | cat
and then no hacks need to go into git at all. The fix is about providing
a sane gzip, not fixing git.
BTW, from what Johannes said, the issue is about a non-msys program
calling an msys one. Does that mean that having git run:
sh -c 'gzip -cn'
would work? If so, then could the solution be as simple as turning off
the "don't bother with the shell" optimization that run-command uses?
Something like "gzip -cn" gets split by git and run via spawn now
(because it has no metacharacters). But we could easily make it always
run through the shell.
-Peff
^ permalink raw reply
* Re: [PATCH 17/18] revert: Introduce --continue to continue the operation
From: Ramkumar Ramachandra @ 2011-08-09 5:26 UTC (permalink / raw)
To: Junio C Hamano
Cc: Christian Couder, Git List, Jonathan Nieder, Christian Couder,
Daniel Barkalow, Jeff King
In-Reply-To: <7vobzzwvug.fsf@alter.siamese.dyndns.org>
Hi Junio,
Junio C Hamano writes:
> Ramkumar Ramachandra <artagnon@gmail.com> writes:
>
>> Junio: Here's another small fixup patch for your convenience.
>
> Not very convenient I am afraid ;-)
Hm, I actually thought about this a bit. Due to the volume of patches
you have to pick up and apply from emails everyday, I figured that you
must have optimized your email-patch application pipeline to such a
ridiculous extent that it's probably faster for you to apply patches
than even typing out a word. A quick interactive rebase with
autosquash will then fix rr/revert-cherry-pick-continue, no?
>> --8<--
>
> This seems to be too short for "am -c"; have you tried applying it
> yourself first before sending it out?
No, I haven't tried this. Will try it and patch "am -c" if necessary,
because I like this minimal scissor (picked it up from Jonathan I
think).
>> -test_expect_success '--signoff is not automatically propogated to
>> resolved conflict' '
>> +test_expect_success '--signoff is not automatically propagated to
>> resolved conflict' '
>
> Linewrapped.
Ugh. Classic GMail web interface mistake. I sometimes risk sending
small patches without git-send-email, and this is what happens.
Nothing helps: mutt's single-threaded'ness is starting to get on my
nerves now.
> I'll squash this manually, so no need to resend. Thanks.
Thanks.
-- Ram
^ permalink raw reply
* Re: What's cooking in git.git (Aug 2011, #02; Mon, 8)
From: Ramkumar Ramachandra @ 2011-08-09 5:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8vr3v7az.fsf@alter.siamese.dyndns.org>
Hi Junio,
Junio C Hamano writes:
> * rr/revert-cherry-pick-continue (2011-08-08) 18 commits
> [...]
> Getting into a reasonable shape. Is another round of re-roll coming?
I certainly have no plans of re-rolling. Although there are times I
wish I'd done a few things slightly differently while developing the
new series (on top of rr/revert-cherry-pick-continue), I'll refrain
from making any changes to this series. That little ugliness is the
price we have to pay for my lack of experience :) All the recent
reviews have mainly pointed out nits, and I really don't think there
are any other urgent issues with this series.
Thanks.
-- Ram
^ 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