* Re: [PATCH] mingw: disable Python
From: Erik Faye-Lund @ 2010-01-08 10:49 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Johannes Sixt, msysgit, git
In-Reply-To: <alpine.DEB.1.00.1001081135180.4272@intel-tinevez-2-302>
On Fri, Jan 8, 2010 at 9:07 AM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> Wouldn't it be superior to set
>
> PYTHON_PATH =
Yes, I think it would. I've tested it (I've got Python 2.6 installed
in c:\Python26\, so with your fix I can re-enable it by setting
"PYTHON_PATH=/c/Python26/python.exe" in config.mak.
On Fri, Jan 8, 2010 at 11:35 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Fri, 8 Jan 2010, Johannes Sixt wrote:
>
>> Erik Faye-Lund schrieb:
>> > Python is not commonly installed on Windows machines, so
>> > we should disable it there by default.
>> >
>> > --- a/Makefile
>> > +++ b/Makefile
>> > @@ -1027,6 +1027,7 @@ ifneq (,$(findstring MINGW,$(uname_S)))
>> > + NO_PYTHON = YesPlease
>>
>> I'm worried that with this solution it is impossible to re-enable Python
>> in config.mak (how do you undefine a Makefile variable?);
> How about
>
> NO_PYTHON=
>
> in config.mak?
>
That doesn't work for me, at least not out of the box. NO_PYTHON is
still defined, it's just defined to an empty string. I guess we could
change to Makefile to accept empty NO_PYTHON as enabled, but since
Hannes' suggestion works fine, I think I'll stick with it, even if
it's a little inconsistent with the other stuff in the MinGW-section
of Makefile.
I'll resend a bit later.
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* Re: [PATCH] mingw: disable Python
From: Johannes Schindelin @ 2010-01-08 10:35 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Erik Faye-Lund, msysgit, git, Erik Faye-Lund
In-Reply-To: <4B46E7D6.3080702@viscovery.net>
Hi,
On Fri, 8 Jan 2010, Johannes Sixt wrote:
> Erik Faye-Lund schrieb:
> > Python is not commonly installed on Windows machines, so
> > we should disable it there by default.
> >
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -1027,6 +1027,7 @@ ifneq (,$(findstring MINGW,$(uname_S)))
> > + NO_PYTHON = YesPlease
>
> I'm worried that with this solution it is impossible to re-enable Python
> in config.mak (how do you undefine a Makefile variable?);
How about
NO_PYTHON=
in config.mak?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] mingw: disable Python
From: Johannes Sixt @ 2010-01-08 8:07 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: msysgit, git, Erik Faye-Lund
In-Reply-To: <1262902037-4420-1-git-send-email-kusmabite@gmail.com>
Erik Faye-Lund schrieb:
> Python is not commonly installed on Windows machines, so
> we should disable it there by default.
>
> --- a/Makefile
> +++ b/Makefile
> @@ -1027,6 +1027,7 @@ ifneq (,$(findstring MINGW,$(uname_S)))
> + NO_PYTHON = YesPlease
I'm worried that with this solution it is impossible to re-enable Python
in config.mak (how do you undefine a Makefile variable?); it would be
necessary to hack Makefile.
Wouldn't it be superior to set
PYTHON_PATH =
in the MinGW section[*]. It works because there is this heuristic later:
ifeq ($(PYTHON_PATH),)
NO_PYTHON=NoThanks
endif
To enable Python, the user would have to set PYTHON_PATH in config.mak.
[I have only Python 1.6 to test (doh!), so I can only tell that it gets
used during 'make', but this fails due to missing modules, so I cannot
tell whether there would be a usable result if Python were sufficiently
recent.]
[*] You should probably set the MSVC section as well, even if you cannot
test it. The effect of the change is predictable enough, I think.
-- Hannes
^ permalink raw reply
* What's cooking in git.git (Jan 2010, #02; Thu, 07)
From: Junio C Hamano @ 2010-01-08 7:42 UTC (permalink / raw)
To: git
In-Reply-To: <7vaawqna55.fsf@alter.siamese.dyndns.org>
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'.
--------------------------------------------------
[Graduated to "master"]
* 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'
--------------------------------------------------
[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]
* 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 (2010-01-04) 25 commits
- t7002: test for not using external grep on skip-worktree paths
- t7002: set test prerequisite "external-grep" if supported
(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-08) 8 commits
- t7111: check that reset options work as described in the tables
(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 (2010-01-07) 4 commits
(merged to 'next' on 2010-01-07 at 5229608)
+ rebase -i: teach --onto A...B syntax
+ rebase: fix --onto A...B parsing and add tests
(merged to 'next' on 2010-01-02 at 6a8f6fc)
+ "rebase --onto A...B" replays history on the merge base between A and B
+ "checkout A...B" switches to the merge base between A and B
* tr/http-push-ref-status (2009-12-24) 6 commits
- transport-helper.c::push_refs(): emit "no refs" error message
- transport-helper.c::push_refs(): ignore helper-reported status if ref is not to be pushed
- transport.c::transport_push(): make ref status affect return value
- refactor ref status logic for pushing
- t5541-http-push.sh: add test for unmatched, non-fast-forwarded refs
- t5541-http-push.sh: add tests for non-fast-forward pushes
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) 1 commit
(merged to 'next' on 2010-01-06 at da4e2f5)
+ 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: edit Author/Date metadata as part of 'git commit' $EDITOR invocation?
From: Adam Megacz @ 2010-01-08 7:35 UTC (permalink / raw)
To: git
In-Reply-To: <7v4omz17xz.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Nanako Shiraishi <nanako3@lavabit.com> writes:
>> Quoting Adam Megacz <adam@megacz.com>
>>> Perhaps a preference (off by default) demanding that they be set
>>> explicitly when "git commit -m" is used?
>> Sverre pointed out why this won't work.
I agree; making it a preference will not help.
I propose instead that "git commit -e" cause the metadata headers to be
provided to $EDITOR. People who care about the metadata can simply get
in the habit of always passing that option when invoking "git commit".
> The approach may have been Ok 10 years ago, back when `whoami`@`hostname`,
> at least on systems that were competently maintained, gave a reasonable
> mail address for most people, but I don't think it is adequate anymore to
> majority of people,
I agree.
> So I don't think anybody minds if we refuse to work if we are going to end
> up using a name that we didn't get from an explicit end user configuration
> (i.e. GIT_*_EMAIL and GIT_*_NAME environment and user.* configuration
> variables).
I support that as well, although I'd still like to be shown the data. I
wear a few different hats (each with its own email address), and I don't
think I want to pick one of them as the default.
Thanks,
- a
^ permalink raw reply
* Re: [StGit PATCH 2/2] Pass the --in-reply-to and --no-thread options to git send-email
From: Karl Wiberg @ 2010-01-08 6:43 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20100107160937.3226.14811.stgit@pc1117.cambridge.arm.com>
On Thu, Jan 7, 2010 at 5:09 PM, Catalin Marinas <catalin.marinas@arm.com> wrote:
> + if options.in_reply_to:
> + cmd.append("--in-reply-to %s" % options.in_reply_to)
Have you tested this? I'm pretty sure you need "--in-reply-to=%s", or
to add the two strings separately---since as far as I can see, this
command is never shell-expanded.
--
Karl Wiberg, kha@treskal.com
subrabbit.wordpress.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [StGit PATCH 1/2] Rename the mail --refid and --noreply options to match Git
From: Karl Wiberg @ 2010-01-08 6:35 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20100107160932.3226.95737.stgit@pc1117.cambridge.arm.com>
Looks good.
--
Karl Wiberg, kha@treskal.com
subrabbit.wordpress.com
www.treskal.com/kalle
^ permalink raw reply
* Re: git-log - hide parent (was: merging two equivalent branches)
From: Christian Couder @ 2010-01-08 5:00 UTC (permalink / raw)
To: David Reitter; +Cc: git, Christian MICHON
In-Reply-To: <DF05F91F-CBFD-458A-A99F-79E98ACA5146@gmail.com>
On jeudi 07 janvier 2010, David Reitter wrote:
> On Jan 7, 2010, at 1:22 PM, Christian MICHON wrote:
> > I recall asking a similar question in 2008, and the answer was to look
> > at "git graft" and use "git filter-branch" to recreate history.
>
> Thanks, I've tried that and I recall that filter-branch wasn't willing to
> rewrite just the recent history - at least in started going over all 100k
> revisions at a very slow pace.
>
> I'm still unsure how, after the filter-branch, I would have some ancestor
> from the B series so that future pulls from the remote work, while having
> an ancestor from A, to make sure I can continue merging into C. If
> history is rewritten, I'll get new revisions and lose ancestors. I'm
> beginning to thing that the cutting and pasting I'd like is conceptually
> impossible.
>
> So what one would need is to specify a "silent parent" for a revision
> that is relevant w.r.t. future three-way merges, but indicates that the
> history behind the silent parent is irrelevant and shouldn't be shown in
> a git-log. The runaway parent would be guaranteed to _not_ contribute
> any content to the tree of the child revision, as is the case with a
> "merge ours".
What you could perhaps do with "git replace" or a graft is to change the
merge commit so that it has only one parent instead of 2.
> This could be implemented as a way to mark a parent as silent (checked by
> git-log at least), but one could also allow for an empty commit that,
> while having a normal parent, clears out the tree.
>
> Let me know if this idea is completely crazy. --
This looks like the right thing to do using "git replace" or grafts.
Best regards,
Christian.
^ permalink raw reply
* [PATCH] t7111: check that reset options work as described in the tables
From: Christian Couder @ 2010-01-08 4:45 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Linus Torvalds, Johannes Schindelin, Stephan Beyer,
Daniel Barkalow, Jakub Narebski, Paolo Bonzini, Johannes Sixt,
Stephen Boyd
Some previous patches added some tables to the "git reset"
documentation. These tables describe the behavior of "git reset"
depending on the option it is passed and the state of the files
in the working tree, the index, HEAD and the target commit.
This patch adds some tests to make sure that the tables describe
the behavior of "git reset".
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
t/t7111-reset-table.sh | 121 ++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 121 insertions(+), 0 deletions(-)
create mode 100755 t/t7111-reset-table.sh
diff --git a/t/t7111-reset-table.sh b/t/t7111-reset-table.sh
new file mode 100755
index 0000000..16b33a5
--- /dev/null
+++ b/t/t7111-reset-table.sh
@@ -0,0 +1,121 @@
+#!/bin/sh
+#
+# Copyright (c) 2010 Christian Couder
+#
+
+test_description='Tests to check that "reset" options follow a known table'
+
+. ./test-lib.sh
+
+
+test_expect_success 'creating initial commits' '
+ test_commit E file1 &&
+ test_commit D file1 &&
+ test_commit C file1
+'
+
+test_expect_success 'creating table file 1' '
+ cat <<EOF >table1
+A B C D soft A B D
+A B C D mixed A D D
+A B C D hard D D D
+A B C D merge XXXXX
+A B C C soft A B C
+A B C C mixed A C C
+A B C C hard C C C
+A B C C merge XXXXX
+B B C D soft B B D
+B B C D mixed B D D
+B B C D hard D D D
+B B C D merge D D D
+B B C C soft B B C
+B B C C mixed B C C
+B B C C hard C C C
+B B C C merge C C C
+B C C D soft B C D
+B C C D mixed B D D
+B C C D hard D D D
+B C C D merge XXXXX
+B C C C soft B C C
+B C C C mixed B C C
+B C C C hard C C C
+B C C C merge B C C
+EOF
+'
+
+while read W1 I1 H1 T opt W2 I2 H2
+do
+ test_expect_success "check: $W1 $I1 $H1 $T --$opt $W2 $I2 $H2" '
+ git reset --hard C &&
+ if [ "$I1" != "$H1" ]
+ then
+ echo "$I1" > file1 &&
+ git add file1
+ fi &&
+ if [ "$W1" != "$I1" ]
+ then
+ echo "$W1" > file1
+ fi &&
+ if [ "$W2" != "XXXXX" ]
+ then
+ git reset --$opt $T &&
+ test "$(cat file1)" = "$W2" &&
+ git checkout-index -f -- file1 &&
+ test "$(cat file1)" = "$I2" &&
+ git checkout -f HEAD -- file1 &&
+ test "$(cat file1)" = "$H2"
+ else
+ test_must_fail git reset --$opt $T
+ fi
+ '
+done < table1
+
+test_expect_success 'setting up branches to test with unmerged entries' '
+ git reset --hard C &&
+ git branch branch1 &&
+ git branch branch2 &&
+ git checkout branch1 &&
+ test_commit B1 file1 &&
+ git checkout branch2 &&
+ test_commit B2 file1
+'
+
+test_expect_success 'creating table file 2' '
+ cat <<EOF >table2
+X U C D soft XXXXX
+X U C D mixed X D D
+X U C D hard D D D
+X U C D merge D D D
+X U C C soft XXXXX
+X U C C mixed X C C
+X U C C hard C C C
+X U C C merge C C C
+EOF
+'
+
+while read W1 I1 H1 T opt W2 I2 H2
+do
+ test_expect_success "check: $W1 $I1 $H1 $T --$opt $W2 $I2 $H2" '
+ git reset --hard B2 &&
+ test_must_fail git merge branch1 &&
+ cat file1 >X_file1 &&
+ if [ "$W2" != "XXXXX" ]
+ then
+ git reset --$opt $T &&
+ if [ "$W2" = "X" ]
+ then
+ test_cmp file1 X_file1
+ else
+ test "$(cat file1)" = "$W2"
+ fi &&
+ git checkout-index -f -- file1 &&
+ test "$(cat file1)" = "$I2" &&
+ git checkout -f HEAD -- file1 &&
+ test "$(cat file1)" = "$H2"
+ else
+ test_must_fail git reset --$opt $T
+ fi
+ '
+done < table2
+
+test_done
--
1.6.6.rc2.5.g49666
^ permalink raw reply related
* Re: Two versions of a project in one GIT repository
From: Dmitry Potapov @ 2010-01-08 3:57 UTC (permalink / raw)
To: Kacper; +Cc: git
In-Reply-To: <1262912794001-4269785.post@n2.nabble.com>
On Thu, Jan 07, 2010 at 05:06:34PM -0800, Kacper wrote:
>
> I have two versions of one project in one local git repository. I have to
> commit this repository into 2 remote repositories, one for each version;
>
> LOCAL GIT(V1/V2) -> REMOTE GIT(V1), REMOTE GIT(V2)
>
> I have some files in the LOCAL GIT repository which should only go to REMOTE
> GIT(V1) and other should only go to REMOTE GIT(V2). Now I commit full local
> repository to both remotes. Can I only commit some files to REMOTE1?
You do not commit to any remote. You _always_ commit to the local repository.
Then using 'git push', you propagate your changes, and you can propagate any
commit to any remote repository of your choice, but you can only to push the
_whole_ commit, which implies the whole tree and all parents commits as well.
> I need to have both version of the project in one repository, but would like
> to have an options to divide history a bit.
You can add as many remote repository as you like using 'git remote add'.
> I do not think that any
> branching can help as then I would have to make the same changes to both
> branches mostly. Most of the code, 90% of the code is the same for VER 1 and
> VER 2. New code is usually the same for both versions.
You can commit only to one branch and then merge your changes to another. In
general case, you may want to have a special branch to commit common changes
and then to merge it to V1 and V2. Though, I guess it is a bit inconvinient.
However, if the difference between V1 and V2 is not large, and you do mind
having V1 history visible as part of V2 history then you may have just two
branches. You create V2 based on V1, by adding V2 specific files and removing
V1 specific files. After that you made all your work on V1 and periodically
merge V1 to V2. Changes made to V1 specific files will cause conflict during
merge to V2, but you can easily resolve by doing 'git rm' on V1 specific
files.
To better understand Git model, I suggest you read "Git for Computer
Scientists" http://eagain.net/articles/git-for-computer-scientists/
Dmitry
^ permalink raw reply
* Re: [PATCH 1/5] MSVC: Windows-native implementation for subset of Pthreads API
From: Dmitry Potapov @ 2010-01-08 3:32 UTC (permalink / raw)
To: Johannes Sixt; +Cc: msysgit, git, Andrzej K. Haczewski
In-Reply-To: <44c7183e43089c64fb65bd248f7fa5b9731067ea.1262895936.git.j6t@kdbg.org>
On Thu, Jan 07, 2010 at 10:54:57PM +0100, Johannes Sixt wrote:
> +
> +int pthread_cond_init(pthread_cond_t *cond, const void *unused)
> +{
> + cond->waiters = 0;
> +
> + InitializeCriticalSection(&cond->waiters_lock);
Is waiters_lock really necessary?
> +
> +int pthread_cond_wait(pthread_cond_t *cond, CRITICAL_SECTION *mutex)
> +{
> + /* serialize access to waiters count */
> + EnterCriticalSection(&cond->waiters_lock);
> + ++cond->waiters;
> + LeaveCriticalSection(&cond->waiters_lock);
InterlockedIncrement(&cond->waiters);
> +
> + /*
> + * Unlock external mutex and wait for signal.
> + * NOTE: we've held mutex locked long enough to increment
> + * waiters count above, so there's no problem with
> + * leaving mutex unlocked before we wait on semaphore.
> + */
> + LeaveCriticalSection(mutex);
> +
> + /* let's wait - ignore return value */
> + WaitForSingleObject(cond->sema, INFINITE);
> +
> + /* we're done waiting, so make sure we decrease waiters count */
> + EnterCriticalSection(&cond->waiters_lock);
> + --cond->waiters;
> + LeaveCriticalSection(&cond->waiters_lock);
InterlockedDecrement(&cond->waiters);
> +
> + /* lock external mutex again */
> + EnterCriticalSection(mutex);
> +
> + return 0;
> +}
> +
> +int pthread_cond_signal(pthread_cond_t *cond)
> +{
> + int have_waiters;
> +
> + /* serialize access to waiters count */
> + EnterCriticalSection(&cond->waiters_lock);
> + have_waiters = cond->waiters > 0;
> + LeaveCriticalSection(&cond->waiters_lock);
AFAIK, Win32 API assumes that reading LONG is always atomic, so
the critical section is not really necesary here, but you need
to declare 'waiters' as 'volatile':
> + */
> +typedef struct {
> + LONG waiters;
volatile LONG waiters;
> + CRITICAL_SECTION waiters_lock;
> + HANDLE sema;
> +} pthread_cond_t;
> +
Dmitry
^ permalink raw reply
* Re: [PATCH] Add quiet option to git-ls-files
From: Ramkumar Ramachandra @ 2010-01-08 2:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1vi14qiy.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 400 bytes --]
> The code doesn't seem to match the claim.
I'm sorry- That was horribly sloppy of me. I figured that passing
`quiet' to report_path_error would break too many things, so I've
dropped that patch altogether. I've removed the reference to ls-files
--quiet in my second patch ( viz.
0002-Replace-redirect-to-dev-null-in-favor-of-quiet-optio.patch) and
attached version 2.
Thanks and regards,
Ramkumar
[-- Attachment #2: 0002-Replace-redirect-to-dev-null-in-favor-of-quiet-optio.patch --]
[-- Type: text/x-patch, Size: 3213 bytes --]
From c34c72801804da61169ab6866d6ce262ea6cf5c1 Mon Sep 17 00:00:00 2001
From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Fri, 8 Jan 2010 07:32:29 +0530
Subject: [PATCH v2] Replace redirect to /dev/null in favor of quiet option
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
---
git-mergetool.sh | 2 +-
git-pull.sh | 2 +-
git-rebase.sh | 2 +-
git-stash.sh | 12 ++++++------
4 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/git-mergetool.sh b/git-mergetool.sh
index b52a741..1c902aa 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -101,7 +101,7 @@ resolve_deleted_merge () {
return 0
;;
[dD]*)
- git rm -- "$MERGED" > /dev/null
+ git rm --quiet -- "$MERGED"
cleanup_temp_files
return 0
;;
diff --git a/git-pull.sh b/git-pull.sh
index 9e69ada..336e91a 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -170,7 +170,7 @@ test true = "$rebase" && {
. git-parse-remote &&
remoteref="$(get_remote_merge_branch "$@" 2>/dev/null)" &&
oldremoteref="$(git rev-parse -q --verify "$remoteref")" &&
- for reflog in $(git rev-list -g $remoteref 2>/dev/null)
+ for reflog in $(git rev-list --quiet --walk-reflogs $remoteref)
do
if test "$reflog" = "$(git merge-base $reflog $curr_branch)"
then
diff --git a/git-rebase.sh b/git-rebase.sh
index b121f45..bfe0475 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -100,7 +100,7 @@ call_merge () {
cmt="$(cat "$dotest/cmt.$1")"
echo "$cmt" > "$dotest/current"
hd=$(git rev-parse --verify HEAD)
- cmt_name=$(git symbolic-ref HEAD 2> /dev/null || echo HEAD)
+ cmt_name=$(git symbolic-ref --quiet HEAD || echo HEAD)
msgnum=$(cat "$dotest/msgnum")
end=$(cat "$dotest/end")
eval GITHEAD_$cmt='"${cmt_name##refs/heads/}~$(($end - $msgnum))"'
diff --git a/git-stash.sh b/git-stash.sh
index 3a0685f..5605d19 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -39,7 +39,7 @@ clear_stash () {
then
die "git stash clear with parameters is unimplemented"
fi
- if current=$(git rev-parse --verify $ref_stash 2>/dev/null)
+ if current=$(git rev-parse --quiet --verify $ref_stash)
then
git update-ref -d $ref_stash $current
fi
@@ -200,7 +200,7 @@ save_stash () {
}
have_stash () {
- git rev-parse --verify $ref_stash >/dev/null 2>&1
+ git rev-parse --quiet --verify $ref_stash >/dev/null
}
list_stash () {
@@ -337,16 +337,16 @@ drop_stash () {
fi
# Verify supplied argument looks like a stash entry
s=$(git rev-parse --verify "$@") &&
- git rev-parse --verify "$s:" > /dev/null 2>&1 &&
- git rev-parse --verify "$s^1:" > /dev/null 2>&1 &&
- git rev-parse --verify "$s^2:" > /dev/null 2>&1 ||
+ git rev-parse --quiet --verify "$s:" > /dev/null &&
+ git rev-parse --quiet --verify "$s^1:" > /dev/null &&
+ git rev-parse --quiet --verify "$s^2:" > /dev/null ||
die "$*: not a valid stashed state"
git reflog delete --updateref --rewrite "$@" &&
say "Dropped $* ($s)" || die "$*: Could not drop stash entry"
# clear_stash if we just dropped the last stash entry
- git rev-parse --verify "$ref_stash@{0}" > /dev/null 2>&1 || clear_stash
+ git rev-parse --quiet --verify "$ref_stash@{0}" > /dev/null || clear_stash
}
apply_to_branch () {
--
1.6.5
^ permalink raw reply related
* [PATCH v4 6/6] transport-helper.c::push_refs(): emit "no refs" error message
From: Tay Ray Chuan @ 2010-01-08 2:12 UTC (permalink / raw)
To: git; +Cc: Jeff King, Junio C Hamano, Daniel Barkalow, Shawn O. Pearce
In-Reply-To: <1262916765-3728-6-git-send-email-rctay89@gmail.com>
Emit an error message when remote_refs is not set.
This behaviour is consistent with that of builtin-send-pack.c and
http-push.c.
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
---
transport-helper.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/transport-helper.c b/transport-helper.c
index 71a1e50..8c0b575 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -321,8 +321,11 @@ static int push_refs(struct transport *transport,
struct child_process *helper;
struct ref *ref;
- if (!remote_refs)
+ if (!remote_refs) {
+ fprintf(stderr, "No refs in common and none specified; doing nothing.\n"
+ "Perhaps you should specify a branch such as 'master'.\n");
return 0;
+ }
helper = get_helper(transport);
if (!data->push)
--
1.6.6.341.ga7aec
^ permalink raw reply related
* [PATCH v4 5/6] transport-helper.c::push_refs(): ignore helper-reported status if ref is not to be pushed
From: Tay Ray Chuan @ 2010-01-08 2:12 UTC (permalink / raw)
To: git; +Cc: Jeff King, Junio C Hamano, Daniel Barkalow, Shawn O. Pearce
In-Reply-To: <1262916765-3728-5-git-send-email-rctay89@gmail.com>
If the status of a ref is REF_STATUS_NONE, the remote helper will not
be told to push the ref (via a 'push' command).
However, the remote helper may still act on these refs.
If the helper does act on the ref, and prints a status for it, ignore
the report (ie. don't overwrite the status of the ref with it, nor the
message in the remote_status member) if the reported status is 'no
match'.
This allows the user to be alerted to more "interesting" ref statuses,
like REF_STATUS_NONFASTFORWARD.
Cc: Jeff King <peff@peff.net>
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
---
Changed from v3:
- consider a ref as marked not for pushing if its status is _not_
none, rather than checking if the status is nonff or uptodate.
- ignore ref status reported by remote helper only if it reported 'no
match'
t/t5541-http-push.sh | 2 +-
transport-helper.c | 9 +++++++++
2 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/t/t5541-http-push.sh b/t/t5541-http-push.sh
index 979624d..83a8e14 100755
--- a/t/t5541-http-push.sh
+++ b/t/t5541-http-push.sh
@@ -111,7 +111,7 @@ Merge the remote changes before pushing again. See the '"'non-fast-forward'"'
section of '"'git push --help'"' for details." output
'
-test_expect_failure 'push fails for non-fast-forward refs unmatched by remote helper' '
+test_expect_success 'push fails for non-fast-forward refs unmatched by remote helper' '
# create a dissimilarly-named remote ref so that git is unable to match the
# two refs (viz. local, remote) unless an explicit refspec is provided.
git push origin master:retsam
diff --git a/transport-helper.c b/transport-helper.c
index 7c9b569..71a1e50 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -430,6 +430,15 @@ static int push_refs(struct transport *transport,
continue;
}
+ if (ref->status != REF_STATUS_NONE) {
+ /*
+ * Earlier, the ref was marked not to be pushed, so ignore the ref
+ * status reported by the remote helper if the latter is 'no match'.
+ */
+ if (status == REF_STATUS_NONE)
+ continue;
+ }
+
ref->status = status;
ref->remote_status = msg;
}
--
1.6.6.341.ga7aec
^ permalink raw reply related
* [PATCH v4 4/6] transport.c::transport_push(): make ref status affect return value
From: Tay Ray Chuan @ 2010-01-08 2:12 UTC (permalink / raw)
To: git; +Cc: Jeff King, Junio C Hamano, Daniel Barkalow, Shawn O. Pearce
In-Reply-To: <1262916765-3728-4-git-send-email-rctay89@gmail.com>
Use push_had_errors() to check the refs for errors and modify the
return value.
Mark the non-fast-forward push tests to succeed.
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
---
t/t5541-http-push.sh | 4 ++--
transport.c | 7 +++++--
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/t/t5541-http-push.sh b/t/t5541-http-push.sh
index 6d92196..979624d 100755
--- a/t/t5541-http-push.sh
+++ b/t/t5541-http-push.sh
@@ -88,7 +88,7 @@ test_expect_success 'used receive-pack service' '
test_cmp exp act
'
-test_expect_failure 'non-fast-forward push fails' '
+test_expect_success 'non-fast-forward push fails' '
cd "$ROOT_PATH"/test_repo_clone &&
git checkout master &&
echo "changed" > path2 &&
@@ -104,7 +104,7 @@ test_expect_success 'non-fast-forward push show ref status' '
grep "^ ! \[rejected\][ ]*master -> master (non-fast-forward)$" output
'
-test_expect_failure 'non-fast-forward push shows help message' '
+test_expect_success 'non-fast-forward push shows help message' '
grep \
"To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes before pushing again. See the '"'non-fast-forward'"'
diff --git a/transport.c b/transport.c
index 12c4423..9b23989 100644
--- a/transport.c
+++ b/transport.c
@@ -875,7 +875,7 @@ int transport_push(struct transport *transport,
int verbose = flags & TRANSPORT_PUSH_VERBOSE;
int quiet = flags & TRANSPORT_PUSH_QUIET;
int porcelain = flags & TRANSPORT_PUSH_PORCELAIN;
- int ret;
+ int ret, err;
if (flags & TRANSPORT_PUSH_ALL)
match_flags |= MATCH_REFS_ALL;
@@ -892,8 +892,11 @@ int transport_push(struct transport *transport,
flags & TRANSPORT_PUSH_FORCE);
ret = transport->push_refs(transport, remote_refs, flags);
+ err = push_had_errors(remote_refs);
- if (!quiet || push_had_errors(remote_refs))
+ ret |= err;
+
+ if (!quiet || err)
print_push_status(transport->url, remote_refs,
verbose | porcelain, porcelain,
nonfastforward);
--
1.6.6.341.ga7aec
^ permalink raw reply related
* [PATCH v4 3/6] refactor ref status logic for pushing
From: Tay Ray Chuan @ 2010-01-08 2:12 UTC (permalink / raw)
To: git; +Cc: Jeff King, Junio C Hamano, Daniel Barkalow, Shawn O. Pearce
In-Reply-To: <1262916765-3728-3-git-send-email-rctay89@gmail.com>
Move the logic that detects up-to-date and non-fast-forward refs to a
new function in remote.[ch], set_ref_status_for_push().
Make transport_push() invoke set_ref_status_for_push() before invoking
the push_refs() implementation. (As a side-effect, the push_refs()
implementation in transport-helper.c now knows of non-fast-forward
pushes.)
Removed logic for detecting up-to-date refs from the push_refs()
implementation in transport-helper.c, as transport_push() has already
done so for it.
Make cmd_send_pack() invoke set_ref_status_for_push() before invoking
send_pack(), as transport_push() can't do it for send_pack() here.
Mark the test on the return status of non-fast-forward push to fail.
Git now exits with success, as transport.c::transport_push() does not
check for refs with status REF_STATUS_REJECT_NONFASTFORWARD nor does it
indicate rejected pushes with its return value.
Mark the test for ref status to succeed. As mentioned earlier, refs
might be marked as non-fast-forwards, triggering the push status
printing mechanism in transport.c.
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
---
builtin-send-pack.c | 51 +++++++++++--------------------------------------
remote.c | 50 +++++++++++++++++++++++++++++++++++++++++++++++++
remote.h | 2 +
t/t5541-http-push.sh | 4 +-
transport-helper.c | 14 ++++++------
transport.c | 4 +++
6 files changed, 77 insertions(+), 48 deletions(-)
diff --git a/builtin-send-pack.c b/builtin-send-pack.c
index 8fffdbf..76c7206 100644
--- a/builtin-send-pack.c
+++ b/builtin-send-pack.c
@@ -406,50 +406,20 @@ int send_pack(struct send_pack_args *args,
*/
new_refs = 0;
for (ref = remote_refs; ref; ref = ref->next) {
-
- if (ref->peer_ref)
- hashcpy(ref->new_sha1, ref->peer_ref->new_sha1);
- else if (!args->send_mirror)
+ if (!ref->peer_ref && !args->send_mirror)
continue;
- ref->deletion = is_null_sha1(ref->new_sha1);
- if (ref->deletion && !allow_deleting_refs) {
- ref->status = REF_STATUS_REJECT_NODELETE;
- continue;
- }
- if (!ref->deletion &&
- !hashcmp(ref->old_sha1, ref->new_sha1)) {
- ref->status = REF_STATUS_UPTODATE;
+ /* Check for statuses set by set_ref_status_for_push() */
+ switch (ref->status) {
+ case REF_STATUS_REJECT_NONFASTFORWARD:
+ case REF_STATUS_UPTODATE:
continue;
+ default:
+ ; /* do nothing */
}
- /* This part determines what can overwrite what.
- * The rules are:
- *
- * (0) you can always use --force or +A:B notation to
- * selectively force individual ref pairs.
- *
- * (1) if the old thing does not exist, it is OK.
- *
- * (2) if you do not have the old thing, you are not allowed
- * to overwrite it; you would not know what you are losing
- * otherwise.
- *
- * (3) if both new and old are commit-ish, and new is a
- * descendant of old, it is OK.
- *
- * (4) regardless of all of the above, removing :B is
- * always allowed.
- */
-
- ref->nonfastforward =
- !ref->deletion &&
- !is_null_sha1(ref->old_sha1) &&
- (!has_sha1_file(ref->old_sha1)
- || !ref_newer(ref->new_sha1, ref->old_sha1));
-
- if (ref->nonfastforward && !ref->force && !args->force_update) {
- ref->status = REF_STATUS_REJECT_NONFASTFORWARD;
+ if (ref->deletion && !allow_deleting_refs) {
+ ref->status = REF_STATUS_REJECT_NODELETE;
continue;
}
@@ -673,6 +643,9 @@ int cmd_send_pack(int argc, const char **argv, const char *prefix)
if (match_refs(local_refs, &remote_refs, nr_refspecs, refspecs, flags))
return -1;
+ set_ref_status_for_push(remote_refs, args.send_mirror,
+ args.force_update);
+
ret = send_pack(&args, fd, conn, remote_refs, &extra_have);
if (helper_status)
diff --git a/remote.c b/remote.c
index e3afecd..c70181c 100644
--- a/remote.c
+++ b/remote.c
@@ -1247,6 +1247,56 @@ int match_refs(struct ref *src, struct ref **dst,
return 0;
}
+void set_ref_status_for_push(struct ref *remote_refs, int send_mirror,
+ int force_update)
+{
+ struct ref *ref;
+
+ for (ref = remote_refs; ref; ref = ref->next) {
+ if (ref->peer_ref)
+ hashcpy(ref->new_sha1, ref->peer_ref->new_sha1);
+ else if (!send_mirror)
+ continue;
+
+ ref->deletion = is_null_sha1(ref->new_sha1);
+ if (!ref->deletion &&
+ !hashcmp(ref->old_sha1, ref->new_sha1)) {
+ ref->status = REF_STATUS_UPTODATE;
+ continue;
+ }
+
+ /* This part determines what can overwrite what.
+ * The rules are:
+ *
+ * (0) you can always use --force or +A:B notation to
+ * selectively force individual ref pairs.
+ *
+ * (1) if the old thing does not exist, it is OK.
+ *
+ * (2) if you do not have the old thing, you are not allowed
+ * to overwrite it; you would not know what you are losing
+ * otherwise.
+ *
+ * (3) if both new and old are commit-ish, and new is a
+ * descendant of old, it is OK.
+ *
+ * (4) regardless of all of the above, removing :B is
+ * always allowed.
+ */
+
+ ref->nonfastforward =
+ !ref->deletion &&
+ !is_null_sha1(ref->old_sha1) &&
+ (!has_sha1_file(ref->old_sha1)
+ || !ref_newer(ref->new_sha1, ref->old_sha1));
+
+ if (ref->nonfastforward && !ref->force && !force_update) {
+ ref->status = REF_STATUS_REJECT_NONFASTFORWARD;
+ continue;
+ }
+ }
+}
+
struct branch *branch_get(const char *name)
{
struct branch *ret;
diff --git a/remote.h b/remote.h
index 8b7ecf9..6e13643 100644
--- a/remote.h
+++ b/remote.h
@@ -98,6 +98,8 @@ char *apply_refspecs(struct refspec *refspecs, int nr_refspec,
int match_refs(struct ref *src, struct ref **dst,
int nr_refspec, const char **refspec, int all);
+void set_ref_status_for_push(struct ref *remote_refs, int send_mirror,
+ int force_update);
/*
* Given a list of the remote refs and the specification of things to
diff --git a/t/t5541-http-push.sh b/t/t5541-http-push.sh
index cc740fe..6d92196 100755
--- a/t/t5541-http-push.sh
+++ b/t/t5541-http-push.sh
@@ -88,7 +88,7 @@ test_expect_success 'used receive-pack service' '
test_cmp exp act
'
-test_expect_success 'non-fast-forward push fails' '
+test_expect_failure 'non-fast-forward push fails' '
cd "$ROOT_PATH"/test_repo_clone &&
git checkout master &&
echo "changed" > path2 &&
@@ -100,7 +100,7 @@ test_expect_success 'non-fast-forward push fails' '
test $HEAD != $(git rev-parse --verify HEAD))
'
-test_expect_failure 'non-fast-forward push show ref status' '
+test_expect_success 'non-fast-forward push show ref status' '
grep "^ ! \[rejected\][ ]*master -> master (non-fast-forward)$" output
'
diff --git a/transport-helper.c b/transport-helper.c
index 11f3d7e..7c9b569 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -329,16 +329,16 @@ static int push_refs(struct transport *transport,
return 1;
for (ref = remote_refs; ref; ref = ref->next) {
- if (ref->peer_ref)
- hashcpy(ref->new_sha1, ref->peer_ref->new_sha1);
- else if (!mirror)
+ if (!ref->peer_ref && !mirror)
continue;
- ref->deletion = is_null_sha1(ref->new_sha1);
- if (!ref->deletion &&
- !hashcmp(ref->old_sha1, ref->new_sha1)) {
- ref->status = REF_STATUS_UPTODATE;
+ /* Check for statuses set by set_ref_status_for_push() */
+ switch (ref->status) {
+ case REF_STATUS_REJECT_NONFASTFORWARD:
+ case REF_STATUS_UPTODATE:
continue;
+ default:
+ ; /* do nothing */
}
if (force_all)
diff --git a/transport.c b/transport.c
index 3eea836..12c4423 100644
--- a/transport.c
+++ b/transport.c
@@ -887,6 +887,10 @@ int transport_push(struct transport *transport,
return -1;
}
+ set_ref_status_for_push(remote_refs,
+ flags & TRANSPORT_PUSH_MIRROR,
+ flags & TRANSPORT_PUSH_FORCE);
+
ret = transport->push_refs(transport, remote_refs, flags);
if (!quiet || push_had_errors(remote_refs))
--
1.6.6.341.ga7aec
^ permalink raw reply related
* [PATCH v4 2/6] t5541-http-push.sh: add test for unmatched, non-fast-forwarded refs
From: Tay Ray Chuan @ 2010-01-08 2:12 UTC (permalink / raw)
To: git; +Cc: Jeff King, Junio C Hamano, Daniel Barkalow, Shawn O. Pearce
In-Reply-To: <1262916765-3728-2-git-send-email-rctay89@gmail.com>
Some refs can only be matched to a remote ref with an explicit refspec.
When such a ref is a non-fast-forward of its remote ref, test that
pushing them (with the explicit refspec specified) fails with a non-
fast-foward-type error (viz. printing of ref status and help message).
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
---
Changed from v3:
- Reworded commit message
- Reword the comments
- Used '*' instead of '\+' for grep expressions
- Used [a-f0-9] instead of [a-z0-9] for matching hexadecimals
- Used ' ' instead of '[ ]' for matching SP
t/t5541-http-push.sh | 21 +++++++++++++++++++++
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/t/t5541-http-push.sh b/t/t5541-http-push.sh
index f49c7c4..cc740fe 100755
--- a/t/t5541-http-push.sh
+++ b/t/t5541-http-push.sh
@@ -111,5 +111,26 @@ Merge the remote changes before pushing again. See the '"'non-fast-forward'"'
section of '"'git push --help'"' for details." output
'
+test_expect_failure 'push fails for non-fast-forward refs unmatched by remote helper' '
+ # create a dissimilarly-named remote ref so that git is unable to match the
+ # two refs (viz. local, remote) unless an explicit refspec is provided.
+ git push origin master:retsam
+
+ echo "change changed" > path2 &&
+ git commit -a -m path2 --amend &&
+
+ # push master too; this ensures there is at least one '"'push'"' command to
+ # the remote helper and triggers interaction with the helper.
+ !(git push -v origin +master master:retsam >output 2>&1) &&
+
+ grep "^ + [a-f0-9]*\.\.\.[a-f0-9]* *master -> master (forced update)$" output &&
+ grep "^ ! \[rejected\] *master -> retsam (non-fast-forward)$" output &&
+
+ grep \
+"To prevent you from losing history, non-fast-forward updates were rejected
+Merge the remote changes before pushing again. See the '"'non-fast-forward'"'
+section of '"'git push --help'"' for details." output
+'
+
stop_httpd
test_done
--
1.6.6.341.ga7aec
^ permalink raw reply related
* [PATCH v4 1/6] t5541-http-push.sh: add tests for non-fast-forward pushes
From: Tay Ray Chuan @ 2010-01-08 2:12 UTC (permalink / raw)
To: git; +Cc: Jeff King, Junio C Hamano, Daniel Barkalow, Shawn O. Pearce
In-Reply-To: <1262916765-3728-1-git-send-email-rctay89@gmail.com>
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
---
t/t5541-http-push.sh | 23 +++++++++++++++++++++++
1 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/t/t5541-http-push.sh b/t/t5541-http-push.sh
index 2a58d0c..f49c7c4 100755
--- a/t/t5541-http-push.sh
+++ b/t/t5541-http-push.sh
@@ -88,5 +88,28 @@ test_expect_success 'used receive-pack service' '
test_cmp exp act
'
+test_expect_success 'non-fast-forward push fails' '
+ cd "$ROOT_PATH"/test_repo_clone &&
+ git checkout master &&
+ echo "changed" > path2 &&
+ git commit -a -m path2 --amend &&
+
+ HEAD=$(git rev-parse --verify HEAD) &&
+ !(git push -v origin >output 2>&1) &&
+ (cd "$HTTPD_DOCUMENT_ROOT_PATH"/test_repo.git &&
+ test $HEAD != $(git rev-parse --verify HEAD))
+'
+
+test_expect_failure 'non-fast-forward push show ref status' '
+ grep "^ ! \[rejected\][ ]*master -> master (non-fast-forward)$" output
+'
+
+test_expect_failure 'non-fast-forward push shows help message' '
+ grep \
+"To prevent you from losing history, non-fast-forward updates were rejected
+Merge the remote changes before pushing again. See the '"'non-fast-forward'"'
+section of '"'git push --help'"' for details." output
+'
+
stop_httpd
test_done
--
1.6.6.341.ga7aec
^ permalink raw reply related
* [PATCH v4 0/6] transport: catch non-fast forwards
From: Tay Ray Chuan @ 2010-01-08 2:12 UTC (permalink / raw)
To: git; +Cc: Jeff King, Junio C Hamano, Daniel Barkalow, Shawn O. Pearce
In-Reply-To: <20091204102039.GB27495@coredump.intra.peff.net>
Junio, this is re-roll of the 'tr/http-push-ref-status' branch in 'pu'.
Jeff, please don't see this re-roll as me assuming you gave your go-
ahead for the latest discussion; I didn't, I thought squashing in the
hunks I mentioned would make things easier for you, rather than having
them floating around.
Summary:
This patch series applies on top of 'next', and deals with alerting
the user to rejected non-fast-forward pushes when using helpers
(smart).
Previously, git silently exited. This situation involves the curl
helper and the smart protocol. The non-fast-forward push is only
detected when curl executes the rpc client (git-send-pack). Now, we
detect it before telling the helper to push.
The series also remedies the scenario where a user would not be aware
of rejected non-fast-forward pushes.
It occurs when
1) there are one or more pushes that succeed and
2) there are one or more rejected non-fast-forward pushes that
involve refs that cannot be matched without explicit refspecs.
This is due to the re-marking of ref status in transport-helper.c::
push_refs() when interacting with the remote helper.
If only non-matched, non-fast-forward refs are involved (ie.
condition #2 is present without #1), then the situtation does not
occur - no 'push' commands are passed to the remote helper, no
interaction with the helper takes place, and no re-marking of ref
status takes place. The user will be alerted to the rejected
non-fast-forward push.
If both are present, re-marking occurs. Even if a ref was not part
of a 'push' command to the helper, 'ok'/'error' status reports might
be made for it, since the remote helper does ref matching on its
side. This led to refs that cannot be matched without an explicit
refspec marked as REF_STATUS_REJECT_NONFASTFORWARD to be re-marked
REF_STATUS_NONE.
(Note: helpers fail to match refs as explicit refspecs are always
available to the top-level transport mechanism, but only on a need-
to-know basis to the remote helper via a 'push' command when a ref
is to be pushed.)
Interestingly, it is possible for a user to be forever unaware of
the rejected push if the user relies on information from git push
alone. As long as the user ensures that one or more other pushes are
successful (eg. change a tracked ref fast-forwardedly) between the
execution of git push, the rejected non-fast-forward push won't be
reported.
Changes from v3:
- reworded commit message for the test in patch 2
- added comment on what the switch block is checking for in patch 3
- changed condition under which ref status reported by remote helper
is ignored in patch 5
Tay Ray Chuan (6):
t5541-http-push.sh: add tests for non-fast-forward pushes
t5541-http-push.sh: add test for unmatched, non-fast-forwarded refs
refactor ref status logic for pushing
transport.c::transport_push(): make ref status affect return value
transport-helper.c::push_refs(): ignore helper-reported status if ref
is not to be pushed
transport-helper.c::push_refs(): emit "no refs" error message
builtin-send-pack.c | 51 +++++++++++--------------------------------------
remote.c | 50 +++++++++++++++++++++++++++++++++++++++++++++++++
remote.h | 2 +
t/t5541-http-push.sh | 44 +++++++++++++++++++++++++++++++++++++++++++
transport-helper.c | 28 +++++++++++++++++++-------
transport.c | 11 ++++++++-
6 files changed, 137 insertions(+), 49 deletions(-)
^ permalink raw reply
* Two versions of a project in one GIT repository
From: Kacper @ 2010-01-08 1:06 UTC (permalink / raw)
To: git
Hi all,
I have two versions of one project in one local git repository. I have to
commit this repository into 2 remote repositories, one for each version;
LOCAL GIT(V1/V2) -> REMOTE GIT(V1), REMOTE GIT(V2)
I have some files in the LOCAL GIT repository which should only go to REMOTE
GIT(V1) and other should only go to REMOTE GIT(V2). Now I commit full local
repository to both remotes. Can I only commit some files to REMOTE1?
I need to have both version of the project in one repository, but would like
to have an options to divide history a bit. I do not think that any
branching can help as then I would have to make the same changes to both
branches mostly. Most of the code, 90% of the code is the same for VER 1 and
VER 2. New code is usually the same for both versions.
THANK YOU,
Kacper
--
View this message in context: http://n2.nabble.com/Two-versions-of-a-project-in-one-GIT-repository-tp4269785p4269785.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH v3 5/6] transport-helper.c::push_refs(): ignore helper-reported status if ref is not to be pushed
From: Tay Ray Chuan @ 2010-01-08 1:04 UTC (permalink / raw)
To: Jeff King; +Cc: git, Shawn O. Pearce, Daniel Barkalow, Junio C Hamano
In-Reply-To: <20100107054120.84972788.rctay89@gmail.com>
Hi,
On Thu, Jan 7, 2010 at 5:41 AM, Tay Ray Chuan <rctay89@gmail.com> wrote:
> Regarding this point, I now think that we should ignore the
> helper-reported status only if that status is none, and continue
> updating the ref status in the top-level transport if the helper did
> push successfully/failed, even if we didn't tell it to push:
>
> @@ -429,7 +429,7 @@ static int push_refs(struct transport *transport,
>
> ref->status = status;
> ref->remote_status = msg;
> - if (ref->status == REF_STATUS_NONE) {
> + if (ref->status == REF_STATUS_NONE && status == REF_STATUS_NONE) {
> ref->status = status;
> ref->remote_status = msg;
> } else {
sorry for this broken hunk. I'll be re-sending shortly to make things clearer.
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: origin/branchname and tracking branch pointing to different commits?
From: Junio C Hamano @ 2010-01-08 0:32 UTC (permalink / raw)
To: Eugene Sajine; +Cc: Thomas Rast, git
In-Reply-To: <76c5b8581001071550g31e9f5a3n15ebdb10a806ab2e@mail.gmail.com>
Eugene Sajine <euguess@gmail.com> writes:
> $ git fetch origin branchname
>
> are both causing the output like this:
>
> From git://....
> * branch branchname -> FETCH_HEAD
> ...
>
> but "git fetch" says:
>
> From git://....
> * branch branchname -> origin/branchname
>
> Is this inconsistent behavior necessary by design?
It is by design; it is debatable if it still makes sense, though.
Back when "git fetch" was invented, there weren't separate refs/remotes/
hierarchy, the distinction between what's local and what's remote were
only in user's head. It made quite a lot of sense to have an explicit way
to prevent "fetch" from overwriting all the branches that track branches
from remote. Suppose you have already spend considerable time inspecting
'origin/branch' and decided that has a suitable commit to build your
changes on, but you needed to work on something else first. If "git fetch
origin other", an explicit request about "other" branch, updated an
unrelated "origin/branch" at the same time, you couldn't recover from it
by using "origin/branch@{1}", because reflog is a fairly recent invention.
An explicit "git fetch origin other" is a way to prevent such an update
from happening. It does not update anything in refs/ hierarchy, even when
you have configured to make an implicit 'git fetch $there' make a copy of
$this_ref somewhere in your refs/remotes/$there/ hierarchy in .git/config
(back then the same information came from .git/remotes).
Because we have reflogs on by default, and refs/remotes/ is a separate
hierarchy that is read-only from the local user's point of view, I think
the 'explicit fetch' syntax, as a way to stop tracking branches from
getting updated, ceased to be useful these days.
^ permalink raw reply
* Re: origin/branchname and tracking branch pointing to different commits?
From: Eugene Sajine @ 2010-01-07 23:50 UTC (permalink / raw)
To: Thomas Rast, git; +Cc: Eugene Sajine
In-Reply-To: <76c5b8581001070925g21ac3136x2928f12dc43437e5@mail.gmail.com>
>
> Yep. That's what i though it is. I.e. origin/branchname will point
> always to the last pushed commit only. Isn't it a bit strange that git
> fetch doesn't update origin/qa?
>
> Probably the problem is that whenever I'm pulling or pushing to remote
> repo i expect the last updated state of particular remote branch to be
> reflected in origin/branchname, but IMHO it is correct expectation...
>
> What do you think?
let me correct my self a little bit:
$ git pull origin branchname
and
$git fetch origin branchname
are both causing the output like this:
>From git://....
* branch branchname -> FETCH_HEAD
...
but "git fetch" says:
>From git://....
* branch branchname -> origin/branchname
Is this inconsistent behavior necessary by design?
Thanks,
Eugene
^ permalink raw reply
* Re: Difference between pull --rebase and fetch+rebase
From: martinvz @ 2010-01-07 23:38 UTC (permalink / raw)
To: git
In-Reply-To: <adf1fd3d1001071433j6cd36641sdd2dfd6a936d8483@mail.gmail.com>
Santi Béjar-2 wrote:
>
> Is your upstream branch rebased?
>
Sorry, but I'm not sure I understand what that means. Most of the commits in
the upstream branch (the remote main branch) were rebased onto that branch
at some point in time before being pushed to our shared repository. The
remote branch itself was never rebased against any other branch (all
destructive operations disallowed in Gitosis). I hope that (possibly along
with the information below) answers your question.
Santi Béjar-2 wrote:
>
> Can you provide, at least, a graph of your history (ala git log
> --graph --oneline for example)? And plot also the reflog entries and
> all the important commits.
>
$ git log --graph --format=%h --all
* 2038a46 # topic-2
* a7b93b2
* f2501ae # origin/main
* cd5aaa9
* cb232f3
...
* 5ed0d06
* 3067862
| * 6eba2fa # topic-1
| * b09aaf4
| * bc3b72a
|/
| * 03d0d84 # topic-3
| * 5160773
| * 3c25642
|/
| * 6e9b12b # topic-4
| * 75f5ab2
| * bdd08ce
| * b5d5759
|/
* 486b580
* a021696
* 3ffe7df
* d0f55c5
...
I have topic-1 checked out and run "git pull" and expect it to rebase (only)
commits bc3b72a, b09aaf4, 6eba2fa onto f2501ae, but it starts by applying
a021696 and 486b580.
$ git reflog -g origin/main
f2501ae refs/remotes/origin/mai\x7f\x7fn@{0}: fetch origin: fast forward
3ffe7df refs/remotes/origin/mai\x7f\x7fn@{1}: fetch origin: fast forward
...
I hope that's all that's all you need. It seems that the problem is that the
oldremoteref gets overwritten with the entry from the reflog. Is the problem
that 3ffe7df appears in the reflog or that 486b580 doesn't appear there? I'm
not clear on what ends up in the reflog.
I just realized that I myself created a021696 and 486b580 (but not 3ffe7df),
probably by rebasing some now-dead branch against origin/main.
Something else that may or may not have something to do with the problem is
that there is also a branch called origin/main-stable (pointing to the same
commit as origin/main). I also have a local main branch (also same commit as
origin/main). I don't know if any of this could confuse Git. (To be
perfectly honest, it is actually the origin/main-stable branch I'm trying to
pull from, just in case you think the branch name could have any impact.)
Thanks,
Martin
--
View this message in context: http://n2.nabble.com/Difference-between-pull-rebase-and-fetch-rebase-tp4266164p4269422.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Problem Using Git with Subversion Repository
From: Bryan Richardson @ 2010-01-07 22:53 UTC (permalink / raw)
To: git
Hello all,
Has anyone come across a similar problem as this?
Item already exists in filesystem: File already exists: filesystem
'/usr/local/svn/repos/my-apps/db', transaction '96-2v', path
'/app/trunk/vendor/rails/actionpack/test/fixtures/layout_tests/layouts/symlinked'
at /usr/lib/git-core/git-svn line 508
I *think* what happened is in a previous git-svn dcommit I removed the
vendor/rails directory (unfroze rails from my app) and now I'm trying
to freeze it again, in which case git-svn thinks a file needs to be
added (instead of modified) and the Subversion repository says the
file already exists.
Anyone know a way around it?!
--
Thanks!
Bryan
^ 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