* RE: Question re. git remote repository
From: David Lang @ 2013-01-17 23:19 UTC (permalink / raw)
To: Lang, David
Cc: Konstantin Khomoutov, Jeff King, git@vger.kernel.org,
Stephen Smith
In-Reply-To: <201301172153.r0HLrUIr001039@smtpb01.one-mail.on.ca>
distributed version control systems let each developer have a full repository
locally on their machine, they then can send updates to other people who have a
repository (or a pull request which asks the other person to pull from the
developers repository to the other persons repository)
Most projects have one repository that they designate as being the 'main'
repository for the project, and developers push updates to it (or send pull
requests to the people who own that repository)
The communication between developers is typically via e-mail and the repository
updates are sent via the git-daemon and the git network protocol.
This sort of thing is very different from the model where there is one
repository on a shared disk somewhere and everyone accesses that shared disk to
do their work or apply updates via NFS/CIFS protocols.
Does this clarify the difference?
David Lang
On Thu, 17 Jan 2013, Lang, David wrote:
> Hi David,
>
> Ok, now I'm really lost! This is definitely due to my newbie git status but
> I'll ask anyway. I'm confused by your statement "... if you try to have one
> filesystem, with multiple people running git on their machines against that
> shared filesystem, I would expect you to have all sorts of problems."
>
> Isn't that the whole point of git, or any versioning system? I thought the
> idea was that each developer installed git locally on their machines and (as
> needed) committed their changes to the master repository which resides
> externally to any of the local machines, such as on a network server (and
> which I'm assuming has git installed locally as well).
>
> What am I missing?
>
> The 'other' David Lang ;-)
>
> -----Original Message-----
> From: David Lang [mailto:david@lang.hm]
> Sent: Wednesday, January 16, 2013 6:01 PM
> To: Stephen Smith
> Cc: Konstantin Khomoutov; Jeff King; git@vger.kernel.org; Lang, David
> Subject: Re: Question re. git remote repository
>
> On Wed, 16 Jan 2013, Stephen Smith wrote:
>
>>>>>> Ideally we'd prefer to simply create our remote repository on a
>>>>>> drive of one of our local network servers. Is this possible?
>>>>>
>>>>> Yes, this is possible, but it's not advised to keep such a
>>>>> "reference" repository on an exported networked drive for a number
>>>>> of reasons (both performance and bug-free operation).
>>>>
>>>> I agree that performance is not ideal (although if you are on a fast
>>>> LAN, it probably would not matter much), but I do not recall any
>>>> specific bugs in that area. Can you elaborate?
>>>
>>> This one [1] for instance. I also recall seing people having other
>>> "mystical" problems with setups like this so I somehow developed an
>>> idea than having a repository on a networked drive is asking for troubles.
>>> Of course, if there are happy users of such setups, I would be glad
>>> to hear as my precautions might well be unfounded for the recent
>>> versions of Git.
>>>
>>> 1. http://code.google.com/p/msysgit/issues/detail?id=130
>>
>> A group I was with used a master repository on a windows share for quite some time without a database corruption being seen. --
>
> I think the risk is that if you have multiple people doing actions on the shared filesystem you can run into trouble.
>
> As long as only one copy of git is ever running against the repository, I don't see any reason for there to be a problem.
>
> But if you try to have one filesystem, with multiple people running git on their machines against that shared filesystem, I would expect you to have all sorts of problems.
>
> David Lang
>
> This e-mail may contain confidential and/or privileged information for the sole use of the intended recipient.
> Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited.
> If you have received this e-mail in error, please contact the sender and delete all copies.
> Opinions, conclusions or other information contained in this e-mail may not be that of the organization.
>
>
^ permalink raw reply
* Re: Question re. git remote repository
From: Jeff King @ 2013-01-17 23:49 UTC (permalink / raw)
To: David Lang
Cc: Stephen Smith, Konstantin Khomoutov, git@vger.kernel.org,
Lang, David
In-Reply-To: <alpine.DEB.2.02.1301161459060.21503@nftneq.ynat.uz>
On Wed, Jan 16, 2013 at 03:00:41PM -0800, David Lang wrote:
> >>This one [1] for instance. I also recall seing people having other
> >>"mystical" problems with setups like this so I somehow developed an idea
> >>than having a repository on a networked drive is asking for troubles.
> >>Of course, if there are happy users of such setups, I would be glad to
> >>hear as my precautions might well be unfounded for the recent versions
> >>of Git.
> >>
> >>1. http://code.google.com/p/msysgit/issues/detail?id=130
> >
> >A group I was with used a master repository on a windows share for quite some time without a database corruption being seen. --
>
> I think the risk is that if you have multiple people doing actions on
> the shared filesystem you can run into trouble.
>
> As long as only one copy of git is ever running against the
> repository, I don't see any reason for there to be a problem.
That should not be an issue. Git on a server has to deal with multiple
independent receive-pack's running to accept several simultaneous
pushes. They coordinate through the use of file locks. Having multiple
machines pushing over a shared filesystem should work the same, as long
as the filesystem support atomic creation of files with O_EXCL.
There may be other subtle issues lurking (e.g., the Windows issue that
Konstantin mentioned), but as far as I know, it _should_ work in
general.
-Peff
^ permalink raw reply
* Re: t9902 fails (Was: [PATCH] attr: fix off-by-one directory component length calculation)
From: Jonathan Nieder @ 2013-01-18 0:04 UTC (permalink / raw)
To: Jean-Noël AVILA
Cc: Torsten Bögershausen, Jeff King, Junio C Hamano, git,
Nguyễn Thái Ngọc Duy, Felipe Contreras
In-Reply-To: <201301172347.50157.avila.jn@gmail.com>
Jean-Noël AVILA wrote:
> OK. I have installed practically everything related to git from the package
> manager and there is a git-checkout-branches utility available.
>
> That result defeats the purpose of the test. This needs a tighter environment
> to work whatever the configuration of the user may be.
Presumably 'git checkout-branches' is from git-stuff.
Here's a patch to make the tested command a little less likely to
conflict with commands from the user's $PATH. I'm not thrilled with
it because the contents of $PATH are still not tightly controlled, and
this does nothing to avoid problems due to existence of, for example,
a "git cherry-pick-branches" command.
Thoughts? Maybe it would be enough to check that the intended get
commands are present in the completion list and other git commands are
not, ignoring binaries that might live elsewhere on the $PATH?
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
t/t9902-completion.sh | 26 +++++++++++++-------------
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
index 3cd53f8..06dcfb2 100755
--- a/t/t9902-completion.sh
+++ b/t/t9902-completion.sh
@@ -192,19 +192,19 @@ test_expect_success 'general options' '
'
test_expect_success 'general options plus command' '
- test_completion "git --version check" "checkout " &&
- test_completion "git --paginate check" "checkout " &&
- test_completion "git --git-dir=foo check" "checkout " &&
- test_completion "git --bare check" "checkout " &&
- test_completion "git --help des" "describe " &&
- test_completion "git --exec-path=foo check" "checkout " &&
- test_completion "git --html-path check" "checkout " &&
- test_completion "git --no-pager check" "checkout " &&
- test_completion "git --work-tree=foo check" "checkout " &&
- test_completion "git --namespace=foo check" "checkout " &&
- test_completion "git --paginate check" "checkout " &&
- test_completion "git --info-path check" "checkout " &&
- test_completion "git --no-replace-objects check" "checkout "
+ test_completion "git --version cherry-p" "cherry-pick " &&
+ test_completion "git --paginate cherry-p" "cherry-pick " &&
+ test_completion "git --git-dir=foo cherry-p" "cherry-pick " &&
+ test_completion "git --bare cherry-p" "cherry-pick " &&
+ test_completion "git --help cherry-p" "cherry-pick " &&
+ test_completion "git --exec-path=foo cherry-p" "cherry-pick " &&
+ test_completion "git --html-path cherry-p" "cherry-pick " &&
+ test_completion "git --no-pager cherry-p" "cherry-pick " &&
+ test_completion "git --work-tree=foo cherry-p" "cherry-pick " &&
+ test_completion "git --namespace=foo cherry-p" "cherry-pick " &&
+ test_completion "git --paginate cherry-p" "cherry-pick " &&
+ test_completion "git --info-path cherry-p" "cherry-pick " &&
+ test_completion "git --no-replace-objects cherry-p" "cherry-pick "
'
test_expect_success 'setup for ref completion' '
--
1.8.1
^ permalink raw reply related
* Re: t9902 fails
From: Junio C Hamano @ 2013-01-18 0:12 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Jean-Noël AVILA, Torsten Bögershausen, Jeff King, git,
Nguyễn Thái Ngọc Duy, Felipe Contreras
In-Reply-To: <20130118000454.GI13449@google.com>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Thoughts? Maybe it would be enough to check that the intended get
> commands are present in the completion list and other git commands are
> not, ignoring binaries that might live elsewhere on the $PATH?
Yeah, it would be a robust alternative approach to verify that (1)
output is a superset of what we expect, and (2) they all share the
string we fed to the machinery as the common prefix, I would think.
^ permalink raw reply
* What's cooking in git.git (Jan 2013, #07; Thu, 17)
From: Junio C Hamano @ 2013-01-18 0:14 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
As usual, this cycle is expected to last for 8 to 10 weeks, with a
preview -rc0 sometime in the middle of next month.
You can find the changes described here in the integration branches of the
repositories listed at
http://git-blame.blogspot.com/p/git-public-repositories.html
--------------------------------------------------
[New Topics]
* fc/remote-hg-fixup-url (2013-01-15) 1 commit
(merged to 'next' on 2013-01-15 at d2acb2d)
+ remote-hg: store converted URL
Update to the Hg remote helper (in contrib/).
Will merge to 'master'.
* mh/remote-hg-mode-bits-fix (2013-01-15) 1 commit
(merged to 'next' on 2013-01-15 at ad57d9f)
+ remote-hg: fix handling of file perms when pushing
Update to the Hg remote helper (in contrib/).
Will merge to 'master'.
* jc/valgrind-memcmp-bsearch (2013-01-14) 1 commit
- ignore memcmp() overreading in bsearch() callback
Squelch false positive in valgrind tests
Will discard.
* mh/imap-send-shrinkage (2013-01-15) 14 commits
- imap-send.c: simplify logic in lf_to_crlf()
- imap-send.c: fold struct store into struct imap_store
- imap-send.c: remove unused field imap_store::uidvalidity
- imap-send.c: use struct imap_store instead of struct store
- imap-send.c: remove unused field imap_store::trashnc
- imap-send.c: remove namespace fields from struct imap
- imap-send.c: remove struct imap argument to parse_imap_list_l()
- imap-send.c: inline parse_imap_list() in parse_list()
- imap-send.c: remove some unused fields from struct store
- imap-send.c: remove struct message
- imap-send.c: remove struct store_conf
- iamp-send.c: remove unused struct imap_store_conf
- imap-send.c: remove struct msg_data
- imap-send.c: remove msg_data::flags, which was always zero
Remove a lot of unused code from "git imap-send".
With a further comment fixup in patch #6, this seems ready for
'next'.
Expecting a reroll.
* nd/attr-debug-fix (2013-01-15) 1 commit
(merged to 'next' on 2013-01-15 at 8460acf)
+ attr: make it build with DEBUG_ATTR again
Fix debugging support that was broken in earlier change.
Will merge to 'master'.
* nd/fix-directory-attrs-off-by-one (2013-01-16) 2 commits
(merged to 'next' on 2013-01-16 at bd63e61)
+ attr: avoid calling find_basename() twice per path
(merged to 'next' on 2013-01-15 at e0a0129)
+ attr: fix off-by-one directory component length calculation
Fix performance regression introduced by an earlier change to let
attributes apply to directories.
Will merge to 'master'.
* nd/fix-perf-parameters-in-tests (2013-01-15) 1 commit
(merged to 'next' on 2013-01-15 at fedbdb9)
+ test-lib.sh: unfilter GIT_PERF_*
Allow GIT_PERF_* environment variables to be passed through the
test framework.
Will merge to 'master'.
* pw/p4-branch-fixes (2013-01-15) 14 commits
(merged to 'next' on 2013-01-15 at 1ee379e)
+ git p4: fix submit when no master branch
+ git p4 test: keep P4CLIENT changes inside subshells
+ git p4: fix sync --branch when no master branch
+ git p4: fail gracefully on sync with no master branch
+ git p4: rearrange self.initialParent use
+ git p4: allow short ref names to --branch
+ git p4 doc: fix branch detection example
+ git p4: clone --branch should checkout master
+ git p4: verify expected refs in clone --bare test
+ git p4: create p4/HEAD on initial clone
+ git p4: inline listExistingP4GitBranches
+ git p4: add comments to p4BranchesInGit
+ git p4: rearrange and simplify hasOrigin handling
+ git p4: test sync/clone --branch behavior
Fix "git p4" around branch handling.
Will merge to 'master'.
* ss/help-htmlpath-config-doc (2013-01-15) 1 commit
(merged to 'next' on 2013-01-17 at 99bfae2)
+ config.txt: Document help.htmlpath config parameter
Add missing doc.
Will merge to 'master'.
* cr/push-force-tag-update (2013-01-16) 1 commit
- push: fix "refs/tags/ hierarchy cannot be updated without --force"
Regression fix.
Will merge to 'next' and then to 'master' soonish.
* jk/suppress-clang-warning (2013-01-16) 1 commit
- fix clang -Wunused-value warnings for error functions
Will merge to 'next'.
* rs/clarify-entry-cmp-sslice (2013-01-16) 1 commit
- refs: use strncmp() instead of strlen() and memcmp()
Will merge to 'next'.
* ch/add-auto-submitted-in-sample-post-receive-email (2013-01-17) 1 commit
- Add Auto-Submitted header to post-receive-email
Will merge to 'next'.
* jc/remove-treesame-parent-in-simplify-merges (2013-01-17) 1 commit
- simplify-merges: drop merge from irrelevant side branch
The --simplify-merges logic did not cull irrelevant parents from a
merge that is otherwise not interesting with respect to the paths
we are following.
As this touches a fairly core part of the revision traversal
infrastructure, it is appreciated to have an extra set of eyes for
sanity check.
Waiting for comments.
* jk/remote-helpers-in-python-3 (2013-01-17) 8 commits
- git-remote-testpy: call print as a function
- git-remote-testpy: don't do unbuffered text I/O
- git-remote-testpy: hash bytes explicitly
- svn-fe: allow svnrdump_sim.py to run with Python 3
- git_remote_helpers: use 2to3 if building with Python 3
- git_remote_helpers: force rebuild if python version changes
- git_remote_helpers: fix input when running under Python 3
- git_remote_helpers: allow building with Python 3
Except for one instance of <user-generated-string>.encode('utf-8'),
nothing looked wrong. People who have worked on git_remote_helpers
should review and Ack, though. Perhaps Sverre?
Waiting for further comments.
--------------------------------------------------
[Stalled]
* mp/complete-paths (2013-01-11) 1 commit
- git-completion.bash: add support for path completion
The completion script used to let the default completer to suggest
pathnames, which gave too many irrelevant choices (e.g. "git add"
would not want to add an unmodified path). Teach it to use a more
git-aware logic to enumerate only relevant ones.
Waiting for area-experts' help and review.
* jl/submodule-deinit (2012-12-04) 1 commit
- submodule: add 'deinit' command
There was no Porcelain way to say "I no longer am interested in
this submodule", once you express your interest in a submodule with
"submodule init". "submodule deinit" is the way to do so.
Expecting a reroll.
$gmane/212884
* jk/lua-hackery (2012-10-07) 6 commits
- pretty: fix up one-off format_commit_message calls
- Minimum compilation fixup
- Makefile: make "lua" a bit more configurable
- add a "lua" pretty format
- add basic lua infrastructure
- pretty: make some commit-parsing helpers more public
Interesting exercise. When we do this for real, we probably would want
to wrap a commit to make it more like an "object" with methods like
"parents", etc.
* rc/maint-complete-git-p4 (2012-09-24) 1 commit
- Teach git-completion about git p4
Comment from Pete will need to be addressed ($gmane/206172).
* jc/maint-name-rev (2012-09-17) 7 commits
- describe --contains: use "name-rev --algorithm=weight"
- name-rev --algorithm=weight: tests and documentation
- name-rev --algorithm=weight: cache the computed weight in notes
- name-rev --algorithm=weight: trivial optimization
- name-rev: --algorithm option
- name_rev: clarify the logic to assign a new tip-name to a commit
- name-rev: lose unnecessary typedef
"git name-rev" names the given revision based on a ref that can be
reached in the smallest number of steps from the rev, but that is
not useful when the caller wants to know which tag is the oldest one
that contains the rev. This teaches a new mode to the command that
uses the oldest ref among those which contain the rev.
I am not sure if this is worth it; for one thing, even with the help
from notes-cache, it seems to make the "describe --contains" even
slower. Also the command will be unusably slow for a user who does
not have a write access (hence unable to create or update the
notes-cache).
Stalled mostly due to lack of responses.
* jc/xprm-generation (2012-09-14) 1 commit
- test-generation: compute generation numbers and clock skews
A toy to analyze how bad the clock skews are in histories of real
world projects.
Stalled mostly due to lack of responses.
* jc/add-delete-default (2012-08-13) 1 commit
- git add: notice removal of tracked paths by default
"git add dir/" updated modified files and added new files, but does
not notice removed files, which may be "Huh?" to some users. They
can of course use "git add -A dir/", but why should they?
Resurrected from graveyard, as I thought it was a worthwhile thing
to do in the longer term.
Stalled mostly due to lack of responses.
* mb/remote-default-nn-origin (2012-07-11) 6 commits
- Teach get_default_remote to respect remote.default.
- Test that plain "git fetch" uses remote.default when on a detached HEAD.
- Teach clone to set remote.default.
- Teach "git remote" about remote.default.
- Teach remote.c about the remote.default configuration setting.
- Rename remote.c's default_remote_name static variables.
When the user does not specify what remote to interact with, we
often attempt to use 'origin'. This can now be customized via a
configuration variable.
Expecting a reroll.
$gmane/210151
"The first remote becomes the default" bit is better done as a
separate step.
--------------------------------------------------
[Cooking]
* jc/cvsimport-upgrade (2013-01-14) 8 commits
- t9600: adjust for new cvsimport
- t9600: further prepare for sharing
- cvsimport-3: add a sample test
- cvsimport: make tests reusable for cvsimport-3
- cvsimport: start adding cvsps 3.x support
- cvsimport: introduce a version-switch wrapper
- cvsimport: allow setting a custom cvsps (2.x) program name
- Makefile: add description on PERL/PYTHON_PATH
The most important part of this series is the addition of the new
cvsimport by Eric Raymond that works with cvsps 3.x. Given some
distros have inertia to be conservative, Git with cvsimport that
does not work with both 3.x will block adoption of cvsps 3.x by
them, and shipping Git with cvsimport that does not work with cvsps
2.x will block such a version of Git, so we'll do the proven "both
old and new are available, but we aim to deprecate and remove the
old one in due time" strategy that we used successfully in the
past.
Both folks on the Git side and Chris Rorvick (contributor to cvsps
3.0 and new cvsimport) seem happy with the new layout, so let's
wait for a few days to see how it evolves and merge it to 'next'.
Waiting for Eric to say something, but otherwise will merge to 'next'.
* as/pre-push-hook (2013-01-14) 4 commits
- Add sample pre-push hook script
- [SQUASH???] t5571 sample hooks should consume their input
- push: Add support for pre-push hooks
- hooks: Add function to check if a hook exists
Add an extra hook so that "git push" that is run without making
sure what is being pushed is sane can be checked and rejected (as
opposed to the user deciding not pushing).
Will merge to 'next' after squashing the fix in.
* dl/am-hg-locale (2013-01-14) 1 commit
- am: invoke perl's strftime in C locale
Datestamp recorded in "Hg" format patch was reformatted incorrectly
to an e-mail looking date using locale dependant strftime, causing
patch application to fail.
This is an original "everything in C locale" version; the later one
that uses LC_TIME may technically be more correct, so I may replace
this with it later ($gmane/213660).
* jk/config-parsing-cleanup (2013-01-14) 7 commits
- [DONTMERGE] reroll coming
- submodule: simplify memory handling in config parsing
- submodule: use match_config_key when parsing config
- userdiff: drop parse_driver function
- convert some config callbacks to match_config_key
- archive-tar: use match_config_key when parsing config
- config: add helper function for parsing key names
Expecting a reroll.
* mp/diff-algo-config (2013-01-16) 3 commits
- diff: Introduce --diff-algorithm command line option
- config: Introduce diff.algorithm variable
- git-completion.bash: Autocomplete --minimal and --histogram for git-diff
Add diff.algorithm configuration so that the user does not type
"diff --histogram".
Looking better; may want tests to protect it from future breakages,
but otherwise it looks ready for 'next'.
* ph/rebase-preserve-all-merges (2013-01-14) 1 commit
(merged to 'next' on 2013-01-15 at 3a67878)
+ rebase --preserve-merges: keep all merge commits including empty ones
An earlier change to add --keep-empty option broke "git rebase
--preserve-merges" and lost merge commits that end up being the
same as its parent.
Will merge to 'master'.
* rs/archive-tar-config-parsing-fix (2013-01-14) 1 commit
- archive-tar: fix sanity check in config parsing
Configuration parsing for tar.* configuration variables were
broken; Peff's config parsing clean-up topic will address the same
breakage, so this may be superseded by that other topic.
* rs/pretty-use-prefixcmp (2013-01-14) 1 commit
(merged to 'next' on 2013-01-15 at d76452d)
+ pretty: use prefixcmp instead of memcmp on NUL-terminated strings
Will merge to 'master'.
* rt/commit-cleanup-config (2013-01-10) 1 commit
(merged to 'next' on 2013-01-15 at c4742ae)
+ commit: make default of "cleanup" option configurable
Add a configuration variable to set default clean-up mode other
than "strip".
Will merge to 'master'.
* jc/custom-comment-char (2013-01-16) 1 commit
- Allow custom "comment char"
An illustration to show codepaths that need to be touched to change
the hint lines in the edited text to begin with something other
than '#'.
This is half my work and half by Ralf Thielow. There may still be
leftover '#' lurking around, though. My "git grep" says C code
should be already fine, but git-rebase--interactive.sh could be
converted (it should not matter, as the file is not really a
free-form text).
I don't know how useful this will be in real life, though.
Waiting for bug reports and user feedback.
* jn/maint-trim-vim-contrib (2013-01-10) 1 commit
(merged to 'next' on 2013-01-15 at ad80a9d)
+ contrib/vim: simplify instructions for old vim support
Will merge to 'master'.
* mz/reset-misc (2013-01-16) 20 commits
(merged to 'next' on 2013-01-16 at 937bc20)
+ reset: update documentation to require only tree-ish with paths
(merged to 'next' on 2013-01-15 at a93b394)
+ reset [--mixed]: use diff-based reset whether or not pathspec was given
+ reset: allow reset on unborn branch
+ reset $sha1 $pathspec: require $sha1 only to be treeish
+ reset.c: inline update_index_refresh()
+ reset.c: finish entire cmd_reset() whether or not pathspec is given
+ reset [--mixed]: only write index file once
+ reset.c: move lock, write and commit out of update_index_refresh()
+ reset.c: move update_index_refresh() call out of read_from_tree()
+ reset.c: replace switch by if-else
+ reset: avoid redundant error message
+ reset --keep: only write index file once
+ reset.c: share call to die_if_unmerged_cache()
+ reset.c: extract function for updating {ORIG_,}HEAD
+ reset.c: remove unnecessary variable 'i'
+ reset.c: extract function for parsing arguments
+ reset: don't allow "git reset -- $pathspec" in bare repo
+ reset.c: pass pathspec around instead of (prefix, argv) pair
+ reset $pathspec: exit with code 0 if successful
+ reset $pathspec: no need to discard index
Various 'reset' optimizations and clean-ups, followed by a change
to allow "git reset" to work even on an unborn branch.
Will merge to 'master'.
* pe/doc-email-env-is-trumped-by-config (2013-01-10) 1 commit
(merged to 'next' on 2013-01-14 at 6b4d555)
+ git-commit-tree(1): correct description of defaults
In the precedence order, the environment variable $EMAIL comes
between the built-in default (i.e. taking value by asking the
system's gethostname() etc.) and the user.email configuration
variable; the documentation implied that it is stronger than the
configuration like $GIT_COMMITTER_EMAIL is, which is wrong.
Will merge to 'master'.
* ds/completion-silence-in-tree-path-probe (2013-01-11) 1 commit
(merged to 'next' on 2013-01-15 at 7542d21)
+ git-completion.bash: silence "not a valid object" errors
An internal ls-tree call made by completion code only to probe if
a path exists in the tree recorded in a commit object leaked error
messages when the path is not there. It is not an error at all and
should not be shown to the end user.
Will merge to 'master'.
* nd/fetch-depth-is-broken (2013-01-11) 3 commits
(merged to 'next' on 2013-01-15 at 70a5ca7)
+ fetch: elaborate --depth action
+ upload-pack: fix off-by-one depth calculation in shallow clone
+ fetch: add --unshallow for turning shallow repo into complete one
"git fetch --depth" was broken in at least three ways. The
resulting history was deeper than specified by one commit, it was
unclear how to wipe the shallowness of the repository with the
command, and documentation was misleading.
Will cook in 'next'.
* jc/no-git-config-in-clone (2013-01-11) 1 commit
(merged to 'next' on 2013-01-15 at feeffe1)
+ clone: do not export and unexport GIT_CONFIG
We stopped paying attention to $GIT_CONFIG environment that points
at a single configuration file from any command other than "git config"
quite a while ago, but "git clone" internally set, exported, and
then unexported the variable during its operation unnecessarily.
Will cook in 'next'.
* mk/complete-tcsh (2013-01-07) 1 commit
(merged to 'next' on 2013-01-11 at b8b30b1)
+ Prevent space after directories in tcsh completion
Update tcsh command line completion so that an unwanted space is
not added to a single directory name.
Will merge to 'master'.
* dg/subtree-fixes (2013-01-08) 7 commits
- contrib/subtree: mkdir the manual directory if needed
- contrib/subtree: honor $(DESTDIR)
- contrib/subtree: fix synopsis and command help
- contrib/subtree: better error handling for "add"
- contrib/subtree: add --unannotate option
- contrib/subtree: use %B for split Subject/Body
- t7900: remove test number comments
contrib/subtree updates; there are a few more from T. Zheng that
were posted separately, with an overlap.
Expecting a reroll.
* ap/log-mailmap (2013-01-10) 11 commits
(merged to 'next' on 2013-01-10 at 8544084)
+ log --use-mailmap: optimize for cases without --author/--committer search
+ log: add log.mailmap configuration option
+ log: grep author/committer using mailmap
+ test: add test for --use-mailmap option
+ log: add --use-mailmap option
+ pretty: use mailmap to display username and email
+ mailmap: add mailmap structure to rev_info and pp
+ mailmap: simplify map_user() interface
+ mailmap: remove email copy and length limitation
+ Use split_ident_line to parse author and committer
+ string-list: allow case-insensitive string list
Teach commands in the "log" family to optionally pay attention to
the mailmap.
Will merge to 'master'.
* jc/push-2.0-default-to-simple (2013-01-16) 14 commits
(merged to 'next' on 2013-01-16 at 23f5df2)
+ t5570: do not assume the "matching" push is the default
+ t5551: do not assume the "matching" push is the default
+ t5550: do not assume the "matching" push is the default
(merged to 'next' on 2013-01-09 at 74c3498)
+ doc: push.default is no longer "matching"
+ push: switch default from "matching" to "simple"
+ t9401: do not assume the "matching" push is the default
+ t9400: do not assume the "matching" push is the default
+ t7406: do not assume the "matching" push is the default
+ t5531: do not assume the "matching" push is the default
+ t5519: do not assume the "matching" push is the default
+ t5517: do not assume the "matching" push is the default
+ t5516: do not assume the "matching" push is the default
+ t5505: do not assume the "matching" push is the default
+ t5404: do not assume the "matching" push is the default
Will cook in 'next' until Git 2.0 ;-).
* nd/clone-no-separate-git-dir-with-bare (2013-01-10) 1 commit
(merged to 'next' on 2013-01-15 at 64f441a)
+ clone: forbid --bare --separate-git-dir <dir>
Forbid a useless combination of options to "git clone".
Will merge to 'master'.
* nd/parse-pathspec (2013-01-11) 20 commits
. Convert more init_pathspec() to parse_pathspec()
. Convert add_files_to_cache to take struct pathspec
. Convert {read,fill}_directory to take struct pathspec
. Convert refresh_index to take struct pathspec
. Convert report_path_error to take struct pathspec
. checkout: convert read_tree_some to take struct pathspec
. Convert unmerge_cache to take struct pathspec
. Convert read_cache_preload() to take struct pathspec
. add: convert to use parse_pathspec
. archive: convert to use parse_pathspec
. ls-files: convert to use parse_pathspec
. rm: convert to use parse_pathspec
. checkout: convert to use parse_pathspec
. rerere: convert to use parse_pathspec
. status: convert to use parse_pathspec
. commit: convert to use parse_pathspec
. clean: convert to use parse_pathspec
. Export parse_pathspec() and convert some get_pathspec() calls
. Add parse_pathspec() that converts cmdline args to struct pathspec
. pathspec: save the non-wildcard length part
Uses the parsed pathspec structure in more places where we used to
use the raw "array of strings" pathspec.
Ejected from 'pu' for now; will take a look at the rerolled one
later ($gmane/213340).
* jc/doc-maintainer (2013-01-03) 2 commits
(merged to 'next' on 2013-01-11 at f35d582)
+ howto/maintain: mark titles for asciidoc
+ Documentation: update "howto maintain git"
Describe tools for automation that were invented since this
document was originally written.
* mo/cvs-server-updates (2012-12-09) 18 commits
(merged to 'next' on 2013-01-08 at 75e2d11)
+ t9402: Use TABs for indentation
+ t9402: Rename check.cvsCount and check.list
+ t9402: Simplify git ls-tree
+ t9402: Add missing &&; Code style
+ t9402: No space after IO-redirection
+ t9402: Dont use test_must_fail cvs
+ t9402: improve check_end_tree() and check_end_full_tree()
+ t9402: sed -i is not portable
+ cvsserver Documentation: new cvs ... -r support
+ cvsserver: add t9402 to test branch and tag refs
+ cvsserver: support -r and sticky tags for most operations
+ cvsserver: Add version awareness to argsfromdir
+ cvsserver: generalize getmeta() to recognize commit refs
+ cvsserver: implement req_Sticky and related utilities
+ cvsserver: add misc commit lookup, file meta data, and file listing functions
+ cvsserver: define a tag name character escape mechanism
+ cvsserver: cleanup extra slashes in filename arguments
+ cvsserver: factor out git-log parsing logic
Various git-cvsserver updates.
Will cook in 'next' for a while to see if anybody screams.
* as/check-ignore (2013-01-16) 13 commits
- clean.c, ls-files.c: respect encapsulation of exclude_list_groups
(merged to 'next' on 2013-01-14 at 9df2afc)
+ t0008: avoid brace expansion
+ add git-check-ignore sub-command
+ setup.c: document get_pathspec()
+ add.c: extract new die_if_path_beyond_symlink() for reuse
+ add.c: extract check_path_for_gitlink() from treat_gitlinks() for reuse
+ pathspec.c: rename newly public functions for clarity
+ add.c: move pathspec matchers into new pathspec.c for reuse
+ add.c: remove unused argument from validate_pathspec()
+ dir.c: improve docs for match_pathspec() and match_pathspec_depth()
+ dir.c: provide clear_directory() for reclaiming dir_struct memory
+ dir.c: keep track of where patterns came from
+ dir.c: use a single struct exclude_list per source of excludes
Add a new command "git check-ignore" for debugging .gitignore
files.
The variable names may want to get cleaned up but that can be done
in-tree.
Will merge to 'next'.
* nd/retire-fnmatch (2013-01-01) 7 commits
(merged to 'next' on 2013-01-07 at ab31f9b)
+ Makefile: add USE_WILDMATCH to use wildmatch as fnmatch
+ wildmatch: advance faster in <asterisk> + <literal> patterns
+ wildmatch: make a special case for "*/" with FNM_PATHNAME
+ test-wildmatch: add "perf" command to compare wildmatch and fnmatch
+ wildmatch: support "no FNM_PATHNAME" mode
+ wildmatch: make dowild() take arbitrary flags
+ wildmatch: rename constants and update prototype
Originally merged to 'next' on 2013-01-04
Replace our use of fnmatch(3) with a more feature-rich wildmatch.
A handful patches at the bottom have been moved to nd/wildmatch to
graduate as part of that branch, before this series solidifies.
Will cook in 'next' a bit longer than other topics.
* mb/gitweb-highlight-link-target (2012-12-20) 1 commit
- Highlight the link target line in Gitweb using CSS
Expecting a reroll.
$gmane/211935
* zk/clean-report-failure (2013-01-14) 1 commit
(merged to 'next' on 2013-01-15 at 5b31614)
+ git-clean: Display more accurate delete messages
"git clean" states what it is going to remove and then goes on to
remove it, but sometimes it only discovers things that cannot be
removed after recursing into a directory, which makes the output
confusing and even wrong.
Will merge to 'master'.
* bc/append-signed-off-by (2013-01-01) 12 commits
- t4014: do not use echo -n
- Unify appending signoff in format-patch, commit and sequencer
- format-patch: update append_signoff prototype
- format-patch: stricter S-o-b detection
- t4014: more tests about appending s-o-b lines
- sequencer.c: teach append_signoff to avoid adding a duplicate newline
- sequencer.c: teach append_signoff how to detect duplicate s-o-b
- sequencer.c: always separate "(cherry picked from" from commit body
- sequencer.c: recognize "(cherry picked from ..." as part of s-o-b footer
- t/t3511: add some tests of 'cherry-pick -s' functionality
- t/test-lib-functions.sh: allow to specify the tag name to test_commit
- sequencer.c: remove broken support for rfc2822 continuation in footer
Expecting a reroll.
$gmane/212507
--------------------------------------------------
[Discarded]
* er/replace-cvsimport (2013-01-12) 7 commits
. t/lib-cvs: cvsimport no longer works without Python >= 2.7
. t9605: test for cvsps commit ordering bug
. t9604: fixup for new cvsimport
. t9600: fixup for new cvsimport
. t/lib-cvs.sh: allow cvsps version 3.x.
. t/t960[123]: remove leftover scripts
. cvsimport: rewrite to use cvsps 3.x to fix major bugs
Rerolled as jc/cvsimport-upgrade.
^ permalink raw reply
* Re: [PATCH] git-svn: teach find-rev to find near matches
From: Eric Wong @ 2013-01-18 0:49 UTC (permalink / raw)
To: John Keeping; +Cc: git
In-Reply-To: <20130117221933.GK4574@serenity.lan>
John Keeping <john@keeping.me.uk> wrote:
> When a single SVN repository is split into multiple Git repositories
> many SVN revisions will exist in only one of the Git repositories
> created. For some projects the only way to build a working artifact is
> to check out corresponding versions of various repositories, with no
> indication of what those are in the Git world - in the SVN world the
> revision numbers are sufficient.
>
> By adding "--before" to "git-svn find-rev" we can say "tell me what this
> repository looked like when that other repository looked like this":
>
> git svn find-rev --before \
> r$(git --git-dir=/over/there.git svn find-rev HEAD)
>
> Signed-off-by: John Keeping <john@keeping.me.uk>
Thanks.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
I've pushed this out to git://bogomips.org/git-svn along with a few
other things I seem to have forgotten about :x
John Keeping (1):
git-svn: teach find-rev to find near matches
Jonathan Nieder (2):
Git::SVN::Editor::T: pass $deletions to ->A and ->D
git svn: do not overescape URLs (fallback case)
^ permalink raw reply
* Re: [PATCH v6 0/8] push: update remote tags only with force
From: Jeff King @ 2013-01-18 1:06 UTC (permalink / raw)
To: Chris Rorvick
Cc: Junio C Hamano, Max Horn, git, Angelo Borsotti, Drew Northup,
Michael Haggerty, Philip Oakley, Johannes Sixt, Kacper Kornet,
Felipe Contreras
In-Reply-To: <CAEUsAPYAL6TD_nzu-YumRK_b-kFy7mNz1VivmSxGeuFYVxVL4g@mail.gmail.com>
On Thu, Jan 17, 2013 at 07:09:16AM -0600, Chris Rorvick wrote:
> I was referring to your concern about rejecting based on type. A push
> causing a reference to move (for example) from a commit to a blob is
> rejected as "already exists" with this patch. You emphatically state
> this is not OK and your solution is to revert back to behavior that
> advises a merge.
>
> Clearly the bug regarding an 'old' unknown to the client should be
> fixed. This is a obvious test case I should have covered and it's
> unfortunate it made it into master. But I don't understand why
> is_forwardable() was misguided (maybe poorly named) nor why
> ref_newer() is a better place to solve the issues it was addressing.
I think that a type-based rule that relies on knowing the type of the
other side will always have to guess in some cases, because we do not
necessarily have that information. However, if instead of the rule being
"blobs on the remote side cannot be replaced", if it becomes "the old
value on the remote side must be referenced by what we replace it with",
that _is_ something we can calculate reliably on the sending side. And
that is logically an extension of the fast-forward rule, which is why I
suggested placing it with ref_newer (but the latter should probably be
extended to not suggest merging if we _know_ it is a non-commit object).
-Peff
^ permalink raw reply
* Re: [PATCH v6 0/8] push: update remote tags only with force
From: Chris Rorvick @ 2013-01-18 3:18 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Max Horn, git, Angelo Borsotti, Drew Northup,
Michael Haggerty, Philip Oakley, Johannes Sixt, Kacper Kornet,
Felipe Contreras
In-Reply-To: <20130118010638.GA29453@sigill.intra.peff.net>
On Thu, Jan 17, 2013 at 7:06 PM, Jeff King <peff@peff.net> wrote:
> However, if instead of the rule being
> "blobs on the remote side cannot be replaced", if it becomes "the old
> value on the remote side must be referenced by what we replace it with",
> that _is_ something we can calculate reliably on the sending side.
Interesting. I would have thought knowing reachability implied having
the old object in the sending repository.
> And
> that is logically an extension of the fast-forward rule, which is why I
> suggested placing it with ref_newer (but the latter should probably be
> extended to not suggest merging if we _know_ it is a non-commit object).
Sounds great, especially if it is not dependent on the sender actually
having the old object. Until this is implemented, though, I don't
understand what was wrong with doing the checks in the
is_forwardable() helper function (of course after fixing the
regression/bug.)
Chris
^ permalink raw reply
* Re: [PATCH v2 8/8] git-remote-testpy: call print as a function
From: Sverre Rabbelier @ 2013-01-18 3:48 UTC (permalink / raw)
To: John Keeping; +Cc: Junio C Hamano, Michael Haggerty, Git List, Pete Wyckoff
In-Reply-To: <88502ee7b090454352b46d496741029817b27482.1358448207.git.john@keeping.me.uk>
Looks harmless enough.
Acked-by: Sverre Rabbelier <srabbelier@gmail.com>
On Thu, Jan 17, 2013 at 10:54 AM, John Keeping <john@keeping.me.uk> wrote:
> This is harmless in Python 2, which sees the parentheses as redundant
> grouping, but is required for Python 3. Since this is the only change
> required to make this script just run under Python 3 without needing
> 2to3 it seems worthwhile.
>
> The case of an empty print must be handled specially because in that
> case Python 2 will interpret '()' as an empty tuple and print it as
> '()'; inserting an empty string fixes this.
>
> Signed-off-by: John Keeping <john@keeping.me.uk>
> ---
> git-remote-testpy.py | 28 ++++++++++++++--------------
> 1 file changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/git-remote-testpy.py b/git-remote-testpy.py
> index bc5e3cf..ccdb2dc 100644
> --- a/git-remote-testpy.py
> +++ b/git-remote-testpy.py
> @@ -87,9 +87,9 @@ def do_capabilities(repo, args):
> """Prints the supported capabilities.
> """
>
> - print "import"
> - print "export"
> - print "refspec refs/heads/*:%s*" % repo.prefix
> + print("import")
> + print("export")
> + print("refspec refs/heads/*:%s*" % repo.prefix)
>
> dirname = repo.get_base_path(repo.gitdir)
>
> @@ -98,11 +98,11 @@ def do_capabilities(repo, args):
>
> path = os.path.join(dirname, 'git.marks')
>
> - print "*export-marks %s" % path
> + print("*export-marks %s" % path)
> if os.path.exists(path):
> - print "*import-marks %s" % path
> + print("*import-marks %s" % path)
>
> - print # end capabilities
> + print('') # end capabilities
>
>
> def do_list(repo, args):
> @@ -115,16 +115,16 @@ def do_list(repo, args):
>
> for ref in repo.revs:
> debug("? refs/heads/%s", ref)
> - print "? refs/heads/%s" % ref
> + print("? refs/heads/%s" % ref)
>
> if repo.head:
> debug("@refs/heads/%s HEAD" % repo.head)
> - print "@refs/heads/%s HEAD" % repo.head
> + print("@refs/heads/%s HEAD" % repo.head)
> else:
> debug("@refs/heads/master HEAD")
> - print "@refs/heads/master HEAD"
> + print("@refs/heads/master HEAD")
>
> - print # end list
> + print('') # end list
>
>
> def update_local_repo(repo):
> @@ -164,7 +164,7 @@ def do_import(repo, args):
> ref = line[7:].strip()
> refs.append(ref)
>
> - print "feature done"
> + print("feature done")
>
> if os.environ.get("GIT_REMOTE_TESTGIT_FAILURE"):
> die('Told to fail')
> @@ -172,7 +172,7 @@ def do_import(repo, args):
> repo = update_local_repo(repo)
> repo.exporter.export_repo(repo.gitdir, refs)
>
> - print "done"
> + print("done")
>
>
> def do_export(repo, args):
> @@ -192,8 +192,8 @@ def do_export(repo, args):
> repo.non_local.push(repo.gitdir)
>
> for ref in changed:
> - print "ok %s" % ref
> - print
> + print("ok %s" % ref)
> + print('')
>
>
> COMMANDS = {
> --
> 1.8.1.1.260.g99b33f4.dirty
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH v2 7/8] git-remote-testpy: don't do unbuffered text I/O
From: Sverre Rabbelier @ 2013-01-18 3:50 UTC (permalink / raw)
To: John Keeping; +Cc: Junio C Hamano, Michael Haggerty, Git List, Pete Wyckoff
In-Reply-To: <6bc90f3afc86d53eb6e4b4d6b87f6afd20023769.1358448207.git.john@keeping.me.uk>
On Thu, Jan 17, 2013 at 10:54 AM, John Keeping <john@keeping.me.uk> wrote:
> - sys.stdin = os.fdopen(sys.stdin.fileno(), 'r', 0)
> + sys.stdin = os.fdopen(sys.stdin.fileno(), 'rb', 0)
It is not immediately obvious why you would open stdin in rb mode,
please add a comment.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* bug: git-svn seg fault during 'git svn fetch' due to perl < 5.10
From: Durham Goode @ 2013-01-18 4:14 UTC (permalink / raw)
To: git@vger.kernel.org
In git 1.8.1, when we do 'git svn fetch' on a large repo, we're seeing a
seg fault. It's caused by git-svn trying to parse a large yaml file
(introduced in
https://github.com/git/git/commit/68f532f4ba888f277637a94b4a49136054df0540
) which encounters a perl regex stack overflow bug that was present in
perl < 5.10 (https://bugzilla.redhat.com/show_bug.cgi?id=192400).
We'll find a work around, but it'd be nice if there was a config setting
to let us choose not to use the yaml format.
Let me know if there's a better place to report this.
-Durham
^ permalink raw reply
* Re: [PATCH v6 0/8] push: update remote tags only with force
From: Junio C Hamano @ 2013-01-18 4:36 UTC (permalink / raw)
To: Jeff King
Cc: Chris Rorvick, Max Horn, git, Angelo Borsotti, Drew Northup,
Michael Haggerty, Philip Oakley, Johannes Sixt, Kacper Kornet,
Felipe Contreras
In-Reply-To: <20130118010638.GA29453@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> However, if instead of the rule being "blobs on the remote side
> cannot be replaced", if it becomes "the old value on the remote
> side must be referenced by what we replace it with", that _is_
> something we can calculate reliably on the sending side. And that
> is logically an extension of the fast-forward rule,...
It may be an extension of the fast-forward, but only in the graph
reachability sense. I can buy that it is mathmatically consistent
with the mode that has proven to be useful for commits at the branch
tips, which we know why "fast-forward" rule is an appropriate
default for. You haven't shown if that mathmatical consistency is
useful for non-commit case.
The primary reason "fast-forward" is a good default for branches is
not that "we do not want to lose objects to gc" (you have reflog for
that). The reason is non fast-forward is a sign of unintended
rewind, and later will cause duplicated history with merge
conflicts.
That comes from the way objects pointed by refs/heads aka branches
are used. It is not just "commit" (as object type), but how these
objects are used. Think why we decided it was a good idea to do one
thing in the topic that introduced the regression under discussion:
"Even if the new commit is a descendant of the old commit, we do not
want to fast-forward a ref if it is under refs/tags/". Type of object
may be one factor, but how it is used is more important factor in
deciding what kind of policy is appropriate.
If users have workflows that want to have a ref hierarchy that point
at a blob, there will not be any update to such a ref that will
satisfy your definition of "extended" fast-forward requirement, and
that requirement came solely from mathematical purity (i.e. graph
reachability), not from any workflow consideration. That is very
disturbing to me.
A workflow that employes such a "blob at a ref" may perfectly be
happy with replacing the blob as last-one-wins basis. I do not think
the client side should enforce a policy to forbid such a push.
I personally think the current client side that insists that updates
to any ref has to have the current object and must fast-forward and
requires --force otherwise was a mistake (this predates the change
by Chris). The receiving end does not implement such an arbitrary
restriction outside refs/heads/, and does so only for refs/heads/
only when deny-non-fast-forwards is set.
^ permalink raw reply
* Re: [PATCH v2 4/8] git_remote_helpers: use 2to3 if building with Python 3
From: Sverre Rabbelier @ 2013-01-18 5:15 UTC (permalink / raw)
To: John Keeping; +Cc: Junio C Hamano, Michael Haggerty, Git List, Pete Wyckoff
In-Reply-To: <bcef80fb913ca829bd2d08284e364ebd55b7297e.1358448207.git.john@keeping.me.uk>
On Thu, Jan 17, 2013 at 10:53 AM, John Keeping <john@keeping.me.uk> wrote:
> [1] http://wiki.python.org/moin/PortingPythonToPy3k
This link seems dead.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: t9902 fails (Was: [PATCH] attr: fix off-by-one directory component length calculation)
From: Torsten Bögershausen @ 2013-01-18 5:20 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Jean-Noël AVILA, Torsten Bögershausen, Jeff King,
Junio C Hamano, git, Nguyễn Thái Ngọc Duy,
Felipe Contreras
In-Reply-To: <20130118000454.GI13449@google.com>
On 18.01.13 01:04, Jonathan Nieder wrote:
> Jean-Noël AVILA wrote:
>
>> OK. I have installed practically everything related to git from the package
>> manager and there is a git-checkout-branches utility available.
>>
>> That result defeats the purpose of the test. This needs a tighter environment
>> to work whatever the configuration of the user may be.
> Presumably 'git checkout-branches' is from git-stuff.
>
> Here's a patch to make the tested command a little less likely to
> conflict with commands from the user's $PATH. I'm not thrilled with
> it because the contents of $PATH are still not tightly controlled, and
> this does nothing to avoid problems due to existence of, for example,
> a "git cherry-pick-branches" command.
>
> Thoughts? Maybe it would be enough to check that the intended get
> commands are present in the completion list and other git commands are
> not, ignoring binaries that might live elsewhere on the $PATH?
>
> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
> ---
> t/t9902-completion.sh | 26 +++++++++++++-------------
> 1 file changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
> index 3cd53f8..06dcfb2 100755
> --- a/t/t9902-completion.sh
> +++ b/t/t9902-completion.sh
> @@ -192,19 +192,19 @@ test_expect_success 'general options' '
> '
>
> test_expect_success 'general options plus command' '
> - test_completion "git --version check" "checkout " &&
> - test_completion "git --paginate check" "checkout " &&
> - test_completion "git --git-dir=foo check" "checkout " &&
> - test_completion "git --bare check" "checkout " &&
> - test_completion "git --help des" "describe " &&
> - test_completion "git --exec-path=foo check" "checkout " &&
> - test_completion "git --html-path check" "checkout " &&
> - test_completion "git --no-pager check" "checkout " &&
> - test_completion "git --work-tree=foo check" "checkout " &&
> - test_completion "git --namespace=foo check" "checkout " &&
> - test_completion "git --paginate check" "checkout " &&
> - test_completion "git --info-path check" "checkout " &&
> - test_completion "git --no-replace-objects check" "checkout "
> + test_completion "git --version cherry-p" "cherry-pick " &&
> + test_completion "git --paginate cherry-p" "cherry-pick " &&
> + test_completion "git --git-dir=foo cherry-p" "cherry-pick " &&
> + test_completion "git --bare cherry-p" "cherry-pick " &&
> + test_completion "git --help cherry-p" "cherry-pick " &&
> + test_completion "git --exec-path=foo cherry-p" "cherry-pick " &&
> + test_completion "git --html-path cherry-p" "cherry-pick " &&
> + test_completion "git --no-pager cherry-p" "cherry-pick " &&
> + test_completion "git --work-tree=foo cherry-p" "cherry-pick " &&
> + test_completion "git --namespace=foo cherry-p" "cherry-pick " &&
> + test_completion "git --paginate cherry-p" "cherry-pick " &&
> + test_completion "git --info-path cherry-p" "cherry-pick " &&
> + test_completion "git --no-replace-objects cherry-p" "cherry-pick "
> '
>
> test_expect_success 'setup for ref completion' '
That looks good to me, thanks.
^ permalink raw reply
* RE: Question re. git remote repository
From: Matt Seitz @ 2013-01-18 5:51 UTC (permalink / raw)
To: Lang, David, David Lang
Cc: Konstantin Khomoutov, Jeff King, git@vger.kernel.org,
Stephen Smith
In-Reply-To: <201301172153.r0HLrU4F019815@smtpb02.one-mail.on.ca>
From: git-owner@vger.kernel.org [git-owner@vger.kernel.org] on behalf of Lang, David [David.Lang@uhn.ca]
> I thought the idea was that each developer installed git locally on their machines
Yes.
> and (as needed) committed their changes to the master repository which resides externally to any of the local machines, such as on a network
> server
Yes, but committing their changes to the master repository is a two step process:
1. Each developer first commits their changes to their personal repository using the "git commit" command.
2. Each developer pushes their changes from their personal repository to the master repository with the "git push" command
> (and which I'm assuming has git installed locally as well).
Maybe.
If the machine with the master repository has git installed locally, then each developer can push their changes to the master repository using either the git protocol or the ssh protocol.
If the machine with the master repository does not have git installed locally, then each developer can push their changes to the master repository using NFS or CIFS/SMB. The git documentation refers to this method as the "file protocol".
The other David Lang (david@lang.hm) believes that using "git push" using NFS or CIFS/SMB may not be safe and reliable. Based on the following article by the creator of git, I believe using "git push" over NFS or CIFS/SMB is safe and reliable:
http://permalink.gmane.org/gmane.comp.version-control.git/122670
The GitFaq wiki also says that using "git push" over NFS or CIFS/SMB is safe and reliable:
https://git.wiki.kernel.org/index.php/GitFaq#What_can_I_use_to_set_up_a_public_repository.3F
^ permalink raw reply
* RE: Question re. git remote repository
From: David Lang @ 2013-01-18 6:18 UTC (permalink / raw)
To: Matt Seitz
Cc: Lang, David, Konstantin Khomoutov, Jeff King, git@vger.kernel.org,
Stephen Smith
In-Reply-To: <1BBEF94B6B46E54980290D150A6F2EDD46B7AAE2@BN1PRD0612MB635.namprd06.prod.outlook.com>
On Fri, 18 Jan 2013, Matt Seitz wrote:
> From: git-owner@vger.kernel.org [git-owner@vger.kernel.org] on behalf of Lang, David [David.Lang@uhn.ca]
>
> The other David Lang (david@lang.hm) believes that using "git push" using NFS or CIFS/SMB may not be safe and reliable. Based on the following article by the creator of git, I believe using "git push" over NFS or CIFS/SMB is safe and reliable:
>
> http://permalink.gmane.org/gmane.comp.version-control.git/122670
>
> The GitFaq wiki also says that using "git push" over NFS or CIFS/SMB is safe and reliable:
>
> https://git.wiki.kernel.org/index.php/GitFaq#What_can_I_use_to_set_up_a_public_repository.3F
I'm glad to learn that git is more robust than I feared.
David Lang
^ permalink raw reply
* [PATCH] git-completion.bash: replace zsh notation that breaks bash 3.X
From: Brandon Casey @ 2013-01-18 10:31 UTC (permalink / raw)
To: gitster; +Cc: felipe.contreras, git, Brandon Casey
When commit d8b45314 began separating the zsh completion from the bash
completion, it introduced a zsh completion "bridge" section into the bash
completion script for zsh users to use until they migrated to the zsh
script. The zsh '+=()' append-to-array notation prevents bash 3.00.15 on
CentOS 4.x from loading the completion script and breaks test 9902. We can
easily work around this by using standard Bash array notation.
Signed-off-by: Brandon Casey <drafnel@gmail.com>
---
contrib/completion/git-completion.bash | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index a4c48e1..c14e329 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -2431,7 +2431,7 @@ if [[ -n ${ZSH_VERSION-} ]]; then
--*=*|*.) ;;
*) c="$c " ;;
esac
- array+=("$c")
+ array[$(($#array+1))]="$c"
done
compset -P '*[=:]'
compadd -Q -S '' -p "${2-}" -a -- array && _ret=0
--
1.8.1.1.252.gdb33759
^ permalink raw reply related
* Re: [PATCH v2 4/8] git_remote_helpers: use 2to3 if building with Python 3
From: John Keeping @ 2013-01-18 10:32 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Junio C Hamano, Michael Haggerty, Git List, Pete Wyckoff
In-Reply-To: <CAGdFq_gew1-YmeUh=brWREHSYQvaV7vRBmEo0KFzi-ViqzOnaw@mail.gmail.com>
On Thu, Jan 17, 2013 at 09:15:08PM -0800, Sverre Rabbelier wrote:
> On Thu, Jan 17, 2013 at 10:53 AM, John Keeping <john@keeping.me.uk> wrote:
> > [1] http://wiki.python.org/moin/PortingPythonToPy3k
>
> This link seems dead.
Looks like the Python wiki is down [1].
I'll replace it with [2] since the content is similar and it should be
easier to find a mirror of the Python documentation than of the wiki.
[1] http://pyfound.blogspot.co.uk/2013/01/wikipythonorg-compromised.html
[2] http://docs.python.org/3.3/howto/pyporting.html#during-installation
John
^ permalink raw reply
* Re: [DOCBUG] git subtree synopsis needs updating
From: Yann Dirson @ 2013-01-18 14:37 UTC (permalink / raw)
To: greened; +Cc: git list
In-Reply-To: <877gnx39aa.fsf@waller.obbligato.org>
On Mon, 31 Dec 2012 20:51:41 -0600
greened@obbligato.org wrote:
> Yann Dirson <dirson@bertin.fr> writes:
>
> > As the examples in git-subtree.txt show, the synopsis in the same file should
> > surely get a patch along the lines of:
> >
> > -'git subtree' add -P <prefix> <commit>
> > +'git subtree' add -P <prefix> <repository> <commit>
> >
> > Failure to specify the repository (by just specifying a local commit) fails with
> > the cryptic:
> >
> > warning: read-tree: emptying the index with no arguments is deprecated; use --empty
> > fatal: just how do you expect me to merge 0 trees?
>
> Specifying a local branch works fine, though, as does a raw commit
> hash. What do you mean by "local commit?"
With no <repository> arg documented, my understanding was that I should first
"git remote add" and fetch the repo in which the branch to be added as subtree
lived. This when running "git subtree add", the commit was indeed existing
locally.
> > As a sidenote it someone wants to do some maintainance, using "." as repository when
> > the branch to subtree-add is already locally available does not work well either
> > (fails with "could not find ref myremote/myhead").
>
> Seems to work for me. Can you give me the command you're using when you
> see the problem?
Hm, can't remember exactly how I reached that. But when experimenting to
reproduce:
$ contrib/subtree/git-subtree.sh add -P foo . origin/maint
git fetch . origin/maint
From .
* remote-tracking branch origin/maint -> FETCH_HEAD
Added dir 'foo'
=> OK
$ contrib/subtree/git-subtree.sh add -P fooo . origin/maint^0
git fetch . origin/maint^0
fatal: Invalid refspec 'origin/maint^0'
=> a commit is advertised, but in fact it seems to require a refspec
--
Yann Dirson - Bertin Technologies
^ permalink raw reply
* Re: [PATCH] git-completion.bash: replace zsh notation that breaks bash 3.X
From: Andreas Schwab @ 2013-01-18 15:02 UTC (permalink / raw)
To: Brandon Casey; +Cc: gitster, felipe.contreras, git
In-Reply-To: <1358505065-16913-1-git-send-email-drafnel@gmail.com>
Brandon Casey <drafnel@gmail.com> writes:
> + array[$(($#array+1))]="$c"
You don't need $(( )) since the array index is already evaluated as an
arithmethic expression.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2013, #07; Thu, 17)
From: Michael Haggerty @ 2013-01-18 15:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vsj5zs5y2.fsf@alter.siamese.dyndns.org>
On 01/18/2013 01:14 AM, Junio C Hamano wrote:
> [...]
> * mh/imap-send-shrinkage (2013-01-15) 14 commits
> - imap-send.c: simplify logic in lf_to_crlf()
> - imap-send.c: fold struct store into struct imap_store
> - imap-send.c: remove unused field imap_store::uidvalidity
> - imap-send.c: use struct imap_store instead of struct store
> - imap-send.c: remove unused field imap_store::trashnc
> - imap-send.c: remove namespace fields from struct imap
> - imap-send.c: remove struct imap argument to parse_imap_list_l()
> - imap-send.c: inline parse_imap_list() in parse_list()
> - imap-send.c: remove some unused fields from struct store
> - imap-send.c: remove struct message
> - imap-send.c: remove struct store_conf
> - iamp-send.c: remove unused struct imap_store_conf
> - imap-send.c: remove struct msg_data
> - imap-send.c: remove msg_data::flags, which was always zero
>
> Remove a lot of unused code from "git imap-send".
>
> With a further comment fixup in patch #6, this seems ready for
> 'next'.
> Expecting a reroll.
I'm confused. It seems like you are referring to the comment
improvement suggested by Jonathan Nieder [1] that you have already
incorporated [2] into mh/imap-send-shrinkage. If you think there is
something that needs rerolling, please explain.
Thanks,
Michael
[1] http://permalink.gmane.org/gmane.comp.version-control.git/213672
[2] http://permalink.gmane.org/gmane.comp.version-control.git/213681
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: Unable to convert a subversion repo to git
From: Michael J Gruber @ 2013-01-18 16:48 UTC (permalink / raw)
To: Timothy Kretschmer; +Cc: git
In-Reply-To: <CAO2=c4nr8PsbHmyKptWewQMmpqWP=YasKZSnCuB9CCkExpSF8A@mail.gmail.com>
Timothy Kretschmer venit, vidit, dixit 16.01.2013 15:06:
> I am seeing the following output while converting a subversion repo to git.
>
> >Found possible branch point: <repo-url>/trunk =>
> <repo-url>/branches/CMT_PHASE3, 18441
>> fatal: Not a valid object name refs/remotes/BlueSimViewer 5.0 20110316 Branch
>> cat-file commit refs/remotes/BlueSimViewer 5.0 20110316 Branch: command returned error: 128
>
> The command I am running to convert the repo is
>
>> git svn clone <repo-url> -A authors-transform.txt --stdlayout bluebox-git > svnlist
>
> I am running git version 1.8.1.1 on an Ubuntu 12.10 server. I am happy
> to provide any other information that would be helpful.
>
> I appreciate any assistance you can provide in this matter,
> -Tim
git-svn should cope with funky branch names. What is the exact name of
the "CMT..." and "BlueSimViewer..." branches? Are you using a case
challenged file system or just some standard linux fs?
Michael
^ permalink raw reply
* Re: t9902 fails
From: Junio C Hamano @ 2013-01-18 16:49 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Jean-Noël AVILA, Torsten Bögershausen, Jeff King, git,
Nguyễn Thái Ngọc Duy, Felipe Contreras
In-Reply-To: <20130118000454.GI13449@google.com>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Here's a patch to make the tested command a little less likely to
> conflict with commands from the user's $PATH. I'm not thrilled with
> it because the contents of $PATH are still not tightly controlled, and
> this does nothing to avoid problems due to existence of, for example,
> a "git cherry-pick-branches" command.
>
> Thoughts?
How about doing something like this and set that variable in the
test instead? If STD_ONLY is not set, you will get everything, but
when STD_ONLY is set, we will stop reading from "help -a" when it
starts listing additional stuff.
contrib/completion/git-completion.bash | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index a4c48e1..415a078 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -534,7 +534,8 @@ __git_complete_strategy ()
__git_list_all_commands ()
{
local i IFS=" "$'\n'
- for i in $(git help -a|egrep '^ [a-zA-Z0-9]')
+ for i in $(LANG=C LC_ALL=C git help -a |
+ sed -n ${GIT_HELP_STD_ONLY+-e /^git.*elsewhere/q} -e '/^ [a-zA-Z0-9]/p')
do
case $i in
*--*) : helper pattern;;
^ permalink raw reply related
* Re: What's cooking in git.git (Jan 2013, #07; Thu, 17)
From: Junio C Hamano @ 2013-01-18 16:58 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git
In-Reply-To: <50F96589.4010408@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
> On 01/18/2013 01:14 AM, Junio C Hamano wrote:
>> [...]
>> * mh/imap-send-shrinkage (2013-01-15) 14 commits
>> - imap-send.c: simplify logic in lf_to_crlf()
>> - imap-send.c: fold struct store into struct imap_store
>> - imap-send.c: remove unused field imap_store::uidvalidity
>> - imap-send.c: use struct imap_store instead of struct store
>> - imap-send.c: remove unused field imap_store::trashnc
>> - imap-send.c: remove namespace fields from struct imap
>> - imap-send.c: remove struct imap argument to parse_imap_list_l()
>> - imap-send.c: inline parse_imap_list() in parse_list()
>> - imap-send.c: remove some unused fields from struct store
>> - imap-send.c: remove struct message
>> - imap-send.c: remove struct store_conf
>> - iamp-send.c: remove unused struct imap_store_conf
>> - imap-send.c: remove struct msg_data
>> - imap-send.c: remove msg_data::flags, which was always zero
>>
>> Remove a lot of unused code from "git imap-send".
>>
>> With a further comment fixup in patch #6, this seems ready for
>> 'next'.
>> Expecting a reroll.
>
> I'm confused. It seems like you are referring to the comment
> improvement suggested by Jonathan Nieder...
It was an indication that I just forgot our previous exchange in
which I said "the remaining issues are so minor I can squash these
in". Sorry about that.
Will merge to 'next'.
Thanks.
^ permalink raw reply
* Re: [PATCH 2/2] fix clang -Wtautological-compare with unsigned enum
From: Phil Hord @ 2013-01-18 17:15 UTC (permalink / raw)
To: Linus Torvalds
Cc: John Keeping, Antoine Pelisse, Max Horn, git, Johannes Sixt,
Junio C Hamano
In-Reply-To: <CA+55aFxYSX2iYPSafKdCDSfWSMfQxP3R3Hqh8GuiiR6EbWfk3w@mail.gmail.com>
On Thu, Jan 17, 2013 at 11:44 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Thu, Jan 17, 2013 at 3:00 AM, John Keeping <john@keeping.me.uk> wrote:
>>
>> There's also a warning that triggers with clang 3.2 but not clang trunk, which
>> I think is a legitimate warning - perhaps someone who understands integer type
>> promotion better than me can explain why the code is OK (patch->score is
>> declared as 'int'):
>>
>> builtin/apply.c:1044:47: warning: comparison of constant 18446744073709551615
>> with expression of type 'int' is always false
>> [-Wtautological-constant-out-of-range-compare]
>> if ((patch->score = strtoul(line, NULL, 10)) == ULONG_MAX)
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~
>
> The warning seems to be very very wrong, and implies that clang has
> some nasty bug in it.
>
> Since patch->score is 'int', and UNLONG_MAX is 'unsigned long', the
> conversion rules for the comparison is that the int result from the
> assignment is cast to unsigned long. And if you cast (int)-1 to
> unsigned long, you *do* get ULONG_MAX. That's true regardless of
> whether "long" has the same number of bits as "int" or is bigger. The
> implicit cast will be done as a sign-extension (unsigned long is not
> signed, but the source type of 'int' *is* signed, and that is what
> determines the sign extension on casting).
>
> So the "is always false" is pure and utter crap. clang is wrong, and
> it is wrong in a way that implies that it actually generates incorrect
> code. It may well be worth making a clang bug report about this.
>
> That said, clang is certainly understandably confused. The code
> depends on subtle conversion rules and bit patterns, and is clearly
> very confusingly written.
>
> So it would probably be good to rewrite it as
>
> unsigned long val = strtoul(line, NULL, 10);
> if (val == ULONG_MAX) ..
> patch->score = val;
>
> instead. At which point you might as well make the comparison be ">=
> INT_MAX" instead, since anything bigger than that is going to be
> bogus.
>
> So the git code is probably worth cleaning up, but for git it would be
> a cleanup. For clang, this implies a major bug and bad code
> generation.
Yes, I can tell by the wording of the error message that you are right
and clang has a problem. But the git code it complained about does
have a real problem, because the result of "signed int a = ULONG_MAX"
is implementation-defined. It cannot be guaranteed or expected that
patch->score will ever be assigned -1 there, and so the comparison may
always be false. I guess the warning is correct, but only
accidentally. :-)
Your rewrite is more sane and corrects the problem, I think.
Phil
^ 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