* Re: CodingGuidelines Perl amendment
From: Junio C Hamano @ 2013-02-06 18:16 UTC (permalink / raw)
To: Ted Zlatanov; +Cc: git, Jeff King
In-Reply-To: <87vca5gvx6.fsf@lifelogs.com>
Ted Zlatanov <tzz@lifelogs.com> writes:
> On Wed, 06 Feb 2013 08:29:30 -0800 Junio C Hamano <gitster@pobox.com> wrote:
>
> JCH> Is it ever (as opposed to "not always") possible to omit braces?
>
> Oh yes! Not that I recommend it, and I'm not even going to touch on
> Perl Golf :)
>
> JCH> It sounds as if we encourage the use of statement modifiers, which
> JCH> certainly is not what I want to see.
>
> Yup. I think I captured that in the patch, but please feel free to
> revise it after applying or throw it back to me.
I'd suggest to just drop that "try to write without braces" entirely.
> JCH> Incidentally, your sentence is a good example of where use of
> JCH> statement modifiers is appropriate: $youmust is rarely true.
>
> I was trying to be funny, honestly. But OK; reworded.
It wasn't a useful guidance, but it _was_ funny.
^ permalink raw reply
* Announcement of git-remote-gcrypt (A custom encrypted remote format)
From: Ulrik Sverdrup @ 2013-02-06 18:19 UTC (permalink / raw)
To: git
Hi,
git-remote-gcrypt is a remote helper for git that (ab)uses this format
to make it possible to push, pull and clone directly to and from a
custom encrypted repository format. Available from::
https://github.com/blake2-ppc/git-remote-gcrypt
It is relatively simple, and hopefully the protocol is sound and
secure; it uses GPG and allows multiple participants to possibly
collaborate using an untrusted and even public host. The git-on-git
backend is experimental and probably buggy, but it works.
The format intentionally targets mainly dumb hosts such as various
bulk storage providers and therefore there is nothing smart about the
protocol; when fetching we can do no better than downloading every new
packfile.
I hope it interests someone, and maybe it even reaches the target of
being both usable and secure. It also helps me if you point out
if/how/why it is broken(!).
-ulrik
^ permalink raw reply
* Re: CodingGuidelines Perl amendment
From: demerphq @ 2013-02-06 18:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ted Zlatanov, git, Jeff King
In-Reply-To: <7vip65cnt3.fsf@alter.siamese.dyndns.org>
On 6 February 2013 19:14, Junio C Hamano <gitster@pobox.com> wrote:
> demerphq <demerphq@gmail.com> writes:
>
>> As you mention below statement modifiers have their place. For instance
>>
>> next if $whatever;
>>
>> Is considered preferable to
>>
>> if ($whatever) {
>> next;
>> }
>>
>> Similarly
>>
>> open my $fh, ">", $filename
>> or die "Failed to open '$filename': $!";
>>
>> Is considered preferable by most Perl programmers to:
>>
>> my $fh;
>> if ( not open $fh, ">", $filename ) {
>> die "Failed to open '$filename': $!";
>> }
>
> Yeah, and that is for the same reason. When you are trying to get a
> birds-eye view of the codeflow, the former makes it clear that "we
> do something, and then we open, and then we ...", without letting
> the error handling (which also is rare case) distract us.
perldoc perlstyle has language which explains this well if you want to
crib a description from somewhere.
>> "unless" often leads to maintenance errors as the expression gets more
>> complicated over time,...
>
> That might also be true, but my comment was not an endorsement for
> (or suggestion against) use of unless. I was commenting on
> statement modifiers, which some people tend to overuse (or abuse)
> and make the resulting code harder to follow.
That's also my point about unless. They tend to get abused and then
lead to maint devs making errors, and people misunderstanding the
code. The only time that unless IMO is "ok" (ish) is when it really is
a very simple statement. As soon as it mentions more than one var it
should be converted to an if. This applies even more so to the
modifier form.
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
^ permalink raw reply
* Re: CodingGuidelines Perl amendment
From: demerphq @ 2013-02-06 18:25 UTC (permalink / raw)
To: Ted Zlatanov; +Cc: Junio C Hamano, git, Jeff King
In-Reply-To: <87vca5gvx6.fsf@lifelogs.com>
On 6 February 2013 19:05, Ted Zlatanov <tzz@lifelogs.com> wrote:
> On Wed, 06 Feb 2013 08:29:30 -0800 Junio C Hamano <gitster@pobox.com> wrote:
>
> JCH> Is it ever (as opposed to "not always") possible to omit braces?
>
> Oh yes! Not that I recommend it, and I'm not even going to touch on
> Perl Golf :)
I think you are wrong. Can you provide an example?
Larry specifically wanted to avoid the "dangling else" problem that C
suffers from, and made it so that blocks are mandatory. The only
exception is statement modifiers, which are not only allowed to omit
the braces but also the parens on the condition.
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
^ permalink raw reply
* Re: CodingGuidelines Perl amendment
From: Ted Zlatanov @ 2013-02-06 18:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeff King
In-Reply-To: <7vehgtcnpm.fsf@alter.siamese.dyndns.org>
On Wed, 06 Feb 2013 10:16:21 -0800 Junio C Hamano <gitster@pobox.com> wrote:
JCH> I'd suggest to just drop that "try to write without braces" entirely.
OK, I'll do it on the reroll, or you can just make the change directly.
I agree it was not going anywhere :)
Ted
diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
index 951d74c..857f4e2 100644
--- a/Documentation/CodingGuidelines
+++ b/Documentation/CodingGuidelines
@@ -187,10 +187,6 @@ For Perl 5 programs:
- use strict and use warnings are strongly preferred.
- - As in C (see above), we avoid using braces unnecessarily (but Perl forces
- braces around if/unless/else/foreach blocks, so this is not always possible).
- At least make sure braces do not sit on their own line, like with C.
-
- Don't abuse statement modifiers--they are discouraged. But in general:
... do something ...
^ permalink raw reply related
* What's cooking in git.git (Feb 2013, #03; Wed, 6)
From: Junio C Hamano @ 2013-02-06 18:29 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 this 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
--------------------------------------------------
[Graduated to "master"]
* ft/transport-report-segv (2013-01-31) 1 commit
(merged to 'next' on 2013-02-02 at 6c450a7)
+ push: fix segfault when HEAD points nowhere
A failure to push due to non-ff while on an unborn branch
dereferenced a NULL pointer when showing an error message.
* jc/fake-ancestor-with-non-blobs (2013-01-31) 3 commits
(merged to 'next' on 2013-02-02 at 86d457a)
+ apply: diagnose incomplete submodule object name better
+ apply: simplify build_fake_ancestor()
+ git-am: record full index line in the patch used while rebasing
(this branch is used by jc/extended-fake-ancestor-for-gitlink.)
Rebasing the history of superproject with change in the submodule
has been broken since v1.7.12.
* jn/auto-depend-workaround-buggy-ccache (2013-02-01) 1 commit
(merged to 'next' on 2013-02-02 at db5940a)
+ Makefile: explicitly set target name for autogenerated dependencies
An age-old workaround to prevent buggy versions of ccache from
breaking the auto-generation of dependencies, which unfortunately
is still relevant because some people use ancient distros.
* sb/gpg-plug-fd-leak (2013-01-31) 1 commit
(merged to 'next' on 2013-02-02 at c271a31)
+ gpg: close stderr once finished with it in verify_signed_buffer()
We forgot to close the file descriptor reading from "gpg" output,
killing "git log --show-signature" on a long history.
* ta/doc-no-small-caps (2013-02-01) 6 commits
(merged to 'next' on 2013-02-02 at 77cbd0e)
+ Documentation: StGit is the right spelling, not StGIT
+ Documentation: describe the "repository" in repository-layout
+ Documentation: add a description for 'gitfile' to glossary
+ Documentation: do not use undefined terms git-dir and git-file
+ Documentation: the name of the system is 'Git', not 'git'
+ Documentation: avoid poor-man's small caps GIT
Update documentation to change "GIT" which was a poor-man's small
caps to "Git". The latter was the intended spelling.
Also change "git" spelled in all-lowercase to "Git" when it refers
to the system as the whole or the concept it embodies, as opposed to
the command the end users would type.
--------------------------------------------------
[New Topics]
* jc/extended-fake-ancestor-for-gitlink (2013-02-05) 1 commit
- apply: verify submodule commit object name better
Instead of requiring the full 40-hex object names on the index
line, we can read submodule commit object names from the textual
diff when synthesizing a fake ancestore tree for "git am -3".
Will merge to 'next'.
* tz/credential-authinfo (2013-02-05) 1 commit
- Add contrib/credentials/netrc with GPG support
A new read-only credential helper (in contrib/) to interact with
the .netrc/.authinfo files. Hopefully mn/send-email-authinfo topic
can rebuild on top of something like this.
Waiting for further reviews.
* jx/utf8-printf-width (2013-02-05) 1 commit
- Add utf8_fprintf helper which returns correct columns
Use a new helper that prints a message and counts its display width
to align the help messages parse-options produces.
--------------------------------------------------
[Stalled]
* mn/send-email-authinfo (2013-01-29) 1 commit
- git-send-email: add ~/.authinfo parsing
This triggered a subtopic to add a credential helper for
authinfo/netrc files (with or without GPG encryption), but nobody
seems to be working on connecting send-email to the credential
framework.
* 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'.
Expecting a follow-up to add tests.
* mb/gitweb-highlight-link-target (2012-12-20) 1 commit
- Highlight the link target line in Gitweb using CSS
Expecting a reroll.
$gmane/211935
* 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.
* 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).
--------------------------------------------------
[Cooking]
* dg/subtree-fixes (2013-02-05) 6 commits
- contrib/subtree: make the manual directory if needed
- contrib/subtree: honor DESTDIR
- contrib/subtree: fix synopsis
- contrib/subtree: better error handling for 'subtree add'
- contrib/subtree: use %B for split subject/body
- contrib/subtree: remove test number comments
contrib/subtree updates, but here are only the ones that looked
ready to be merged to 'next'. For the remainder, they will have
another day.
Will merge to 'next'.
* jl/submodule-deinit (2013-02-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.
Will merge to 'next'.
* ct/autoconf-htmldir (2013-02-02) 1 commit
(merged to 'next' on 2013-02-05 at bba4f8c)
+ Honor configure's htmldir switch
The autoconf subsystem passed --mandir down to generated
config.mak.autogen but forgot to do the same for --htmldir.
Will merge to 'master'.
* mk/tcsh-complete-only-known-paths (2013-02-03) 1 commit
(merged to 'next' on 2013-02-05 at 4409b08)
+ completion: handle path completion and colon for tcsh script
(this branch uses mp/complete-paths.)
Manlio's "complete with known paths only" update to completion
scripts returns directory names without trailing slash to
compensate the addition of '/' done by bash that reads from our
completion result. tcsh completion code that reads from our
internal completion result does not add '/', so let it ask our
complletion code to keep the '/' at the end.
Will merge to 'master'.
* jc/combine-diff-many-parents (2013-02-05) 2 commits
(merged to 'next' on 2013-02-05 at e382aa6)
+ t4038: add tests for "diff --cc --raw <trees>"
+ combine-diff: lift 32-way limit of combined diff
We used to have an arbitrary 32 limit for combined diff input,
resulting in incorrect number of leading colons shown when showing
the "--raw --cc" output.
Will merge to 'master'.
* jc/remove-export-from-config-mak-in (2013-02-03) 1 commit
- config.mak.in: remove unused definitions
config.mak.in template had an "export" line to cause a few
common makefile variables to be exported; if they need to be
expoted for autoconf/configure users, they should also be exported
for people who write config.mak the same way. Move the "export" to
the main Makefile.
* jk/apply-similaritly-parsing (2013-02-03) 1 commit
(merged to 'next' on 2013-02-05 at ccf1c97)
+ builtin/apply: tighten (dis)similarity index parsing
Make sure the similarity value shown in the "apply --summary"
output is sensible, even when the input had a bogus value.
Will merge to 'master'.
* nd/status-show-in-progress (2013-02-05) 1 commit
- status: show the branch name if possible in in-progress info
Will merge to 'next'.
* sb/gpg-i18n (2013-01-31) 1 commit
(merged to 'next' on 2013-02-02 at 7a54574)
+ gpg: allow translation of more error messages
Will merge to 'master'.
* sb/run-command-fd-error-reporting (2013-02-01) 1 commit
(merged to 'next' on 2013-02-02 at be7e970)
+ run-command: be more informative about what failed
Will merge to 'master'.
* jk/remote-helpers-doc (2013-02-01) 1 commit
(merged to 'next' on 2013-02-02 at ce1461a)
+ Rename {git- => git}remote-helpers.txt
"git help remote-helpers" did not work; 'remote-helpers' is not
a subcommand name but a concept, so its documentation should have
been in gitremote-helpers, not git-remote-helpers.
Will merge to 'master'.
* sp/smart-http-content-type-check (2013-02-06) 3 commits
(merged to 'next' on 2013-02-06 at 8bc6434)
+ http_request: reset "type" strbuf before adding
(merged to 'next' on 2013-02-05 at 157812c)
+ t5551: fix expected error output
(merged to 'next' on 2013-02-04 at d0759cb)
+ Verify Content-Type from smart HTTP servers
The smart HTTP clients forgot to verify the content-type that comes
back from the server side to make sure that the request is being
handled properly.
* jc/mention-tracking-for-pull-default (2013-01-31) 1 commit
- doc: mention tracking for pull.default
We stopped mentioning `tracking` is a deprecated but supported
synonym for `upstream` in pull.default even though we have no
intention of removing the support for it.
This is my "don't list it to catch readers' eyes, but make sure it
can be found if the reader looks for it" version; I'm not married
to the layout and will be happy to take a replacement patch.
Waiting for couter-proposal patches.
* jk/doc-makefile-cleanup (2013-02-01) 1 commit
(merged to 'next' on 2013-02-02 at 86ff373)
+ Documentation/Makefile: clean up MAN*_TXT lists
Will merge to 'master'.
* ab/gitweb-use-same-scheme (2013-01-28) 1 commit
(merged to 'next' on 2013-02-02 at 7e4a108)
+ gitweb: refer to picon/gravatar images over the same scheme
Avoid mixed contents on a page coming via http and https when
gitweb is hosted on a https server.
Will merge to 'master'.
* jk/python-styles (2013-01-30) 1 commit
(merged to 'next' on 2013-02-02 at 293edc1)
+ CodingGuidelines: add Python coding guidelines
Will merge to 'master'.
* mp/complete-paths (2013-01-11) 1 commit
(merged to 'next' on 2013-01-30 at 70e4f1a)
+ git-completion.bash: add support for path completion
(this branch is used by mk/tcsh-complete-only-known-paths.)
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.
This is logically the right thing to do, and we would really love
to see people who have been involved in completion code to review
and comment on the implementation.
Will cook in 'next' to see if anybody screams.
* ss/mergetools-tortoise (2013-02-01) 2 commits
(merged to 'next' on 2013-02-03 at d306b83)
+ mergetools: teach tortoisemerge to handle filenames with SP correctly
+ mergetools: support TortoiseGitMerge
Update mergetools to work better with newer merge helper tortoise ships.
Will merge to 'master'.
* da/mergetool-docs (2013-02-02) 5 commits
(merged to 'next' on 2013-02-03 at f822dcf)
+ doc: generate a list of valid merge tools
+ mergetool--lib: list user configured tools in '--tool-help'
+ mergetool--lib: add functions for finding available tools
+ mergetool--lib: improve the help text in guess_merge_tool()
+ mergetool--lib: simplify command expressions
(this branch uses jk/mergetool.)
Build on top of the clean-up done by jk/mergetool and automatically
generate the list of mergetool and difftool backends the build
supports to be included in the documentation.
Will merge to 'master'.
* nd/branch-error-cases (2013-01-31) 6 commits
(merged to 'next' on 2013-02-02 at cf5e745)
+ branch: let branch filters imply --list
+ docs: clarify git-branch --list behavior
+ branch: mark more strings for translation
+ Merge branch 'nd/edit-branch-desc-while-detached' into HEAD
+ branch: give a more helpful message on redundant arguments
+ branch: reject -D/-d without branch name
Fix various error messages and conditions in "git branch", e.g. we
advertised "branch -d/-D" to remove one or more branches but actually
implemented removal of zero or more branches---request to remove no
branches was not rejected.
Will merge to 'master'.
* jk/mergetool (2013-01-28) 8 commits
(merged to 'next' on 2013-02-03 at 2ff5dee)
+ mergetools: simplify how we handle "vim" and "defaults"
+ mergetool--lib: don't call "exit" in setup_tool
+ mergetool--lib: improve show_tool_help() output
+ mergetools/vim: remove redundant diff command
+ git-difftool: use git-mergetool--lib for "--tool-help"
+ git-mergetool: don't hardcode 'mergetool' in show_tool_help
+ git-mergetool: remove redundant assignment
+ git-mergetool: move show_tool_help to mergetool--lib
(this branch is used by da/mergetool-docs.)
Cleans up mergetool/difftool combo.
Will merge to 'master'.
* jc/hidden-refs (2013-01-30) 7 commits
- fetch: fetch objects by their exact SHA-1 object names
- upload-pack: optionally allow fetching from the tips of hidden refs
- fetch: use struct ref to represent refs to be fetched
- parse_fetch_refspec(): clarify the codeflow a bit
- upload/receive-pack: allow hiding ref hierarchies
- upload-pack: simplify request validation
- upload-pack: share more code
Allow the server side to unclutter the refs/ namespace it shows to
the client. Optionally allow requests for histories leading to the
tips of hidden refs by updated clients.
Need to split the configuration into three (one for sending, one
for receiving, and then another to cover both for convenience)
before this topic can go forward. Perhaps people involved in the
review cycle can help.
* jc/remove-treesame-parent-in-simplify-merges (2013-01-17) 1 commit
(merged to 'next' on 2013-01-30 at b639b47)
+ 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.
This touches a fairly core part of the revision traversal
infrastructure; even though I think this change is correct, please
report immediately if you find any unintended side effect.
Will cook in 'next'.
* 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 ;-).
* bc/append-signed-off-by (2013-01-27) 11 commits
- Unify appending signoff in format-patch, commit and sequencer
- format-patch: update append_signoff prototype
- 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
- commit, cherry-pick -s: remove broken support for multiline rfc2822 fields
- sequencer.c: rework search for start of footer to improve clarity
Waiting for the final round of reroll before merging to 'next'.
After that we will go incremental.
^ permalink raw reply
* Re: Bug in "git log --graph -p -m" (version 1.7.7.6)
From: Matthieu Moy @ 2013-02-06 18:33 UTC (permalink / raw)
To: John Keeping; +Cc: Dale R. Worley, gitster, git
In-Reply-To: <20130206151447.GZ1342@serenity.lan>
John Keeping <john@keeping.me.uk> writes:
> I would argue that the line should start with "| | ", since it really is
> just a continuation of the same commit.
>
> | |
> | | commit a393ed598e9fb11436f85bd58f1a38c82f2cadb7 (from 33e70e70c0173d634826b998bdc304f93c0966b8)
> | | Merge: 2c1e6a3 33e70e7
> | | Author: Matthieu Moy <Matthieu.Moy@imag.fr>
> | | Date: Tue Feb 5 22:05:33 2013 +0100
Yes.
I had a look at the code, I guess the call to graph_show_commit() in
show_log() (in log-tree.c) should have called graph_show_padding() but
didn't in this case. Then I got lost in graph.c :-(.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: CodingGuidelines Perl amendment
From: Ted Zlatanov @ 2013-02-06 18:35 UTC (permalink / raw)
To: demerphq; +Cc: Junio C Hamano, git, Jeff King
In-Reply-To: <CANgJU+VbkQ+xa+_sSAu-3pMe+6gycHi9J4VR18M5YJt=pa9QUw@mail.gmail.com>
On Wed, 6 Feb 2013 19:25:43 +0100 demerphq <demerphq@gmail.com> wrote:
d> On 6 February 2013 19:05, Ted Zlatanov <tzz@lifelogs.com> wrote:
>> On Wed, 06 Feb 2013 08:29:30 -0800 Junio C Hamano <gitster@pobox.com> wrote:
>>
JCH> Is it ever (as opposed to "not always") possible to omit braces?
>>
>> Oh yes! Not that I recommend it, and I'm not even going to touch on
>> Perl Golf :)
d> I think you are wrong. Can you provide an example?
d> Larry specifically wanted to avoid the "dangling else" problem that C
d> suffers from, and made it so that blocks are mandatory. The only
d> exception is statement modifiers, which are not only allowed to omit
d> the braces but also the parens on the condition.
Oh, perhaps I didn't state it correctly. You can avoid braces, but not
if you want to use if/elsif/else/unless/etc. which require them:
condition && do_this();
condition || do_this();
condition ? do_this() : do_that();
(and others I can't recall right now)
But my point was only that it's always possible to get around these
artificial restrictions; it's more important to ask for legible sensible
code. Sorry if that was unclear!
Ted
^ permalink raw reply
* Re: CodingGuidelines Perl amendment
From: demerphq @ 2013-02-06 18:44 UTC (permalink / raw)
To: Ted Zlatanov; +Cc: Junio C Hamano, git, Jeff King
In-Reply-To: <87ip65guj8.fsf@lifelogs.com>
On 6 February 2013 19:35, Ted Zlatanov <tzz@lifelogs.com> wrote:
> On Wed, 6 Feb 2013 19:25:43 +0100 demerphq <demerphq@gmail.com> wrote:
>
> d> On 6 February 2013 19:05, Ted Zlatanov <tzz@lifelogs.com> wrote:
>>> On Wed, 06 Feb 2013 08:29:30 -0800 Junio C Hamano <gitster@pobox.com> wrote:
>>>
> JCH> Is it ever (as opposed to "not always") possible to omit braces?
>>>
>>> Oh yes! Not that I recommend it, and I'm not even going to touch on
>>> Perl Golf :)
>
> d> I think you are wrong. Can you provide an example?
>
> d> Larry specifically wanted to avoid the "dangling else" problem that C
> d> suffers from, and made it so that blocks are mandatory. The only
> d> exception is statement modifiers, which are not only allowed to omit
> d> the braces but also the parens on the condition.
>
> Oh, perhaps I didn't state it correctly. You can avoid braces, but not
> if you want to use if/elsif/else/unless/etc. which require them:
>
> condition && do_this();
> condition || do_this();
> condition ? do_this() : do_that();
>
> (and others I can't recall right now)
>
> But my point was only that it's always possible to get around these
> artificial restrictions; it's more important to ask for legible sensible
> code. Sorry if that was unclear!
Ah ok. Right, at a low level:
if (condition) { do_this() }
is identical to
condition && do_this();
IOW, Perl allows logical operators to act as control flow statements.
I hope your document include something that says that using logical
operators as control flow statements should be used sparingly, and
generally should be restricted to low precedence operators and should
never involve more than one operator.
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
^ permalink raw reply
* Re: CodingGuidelines Perl amendment
From: Ted Zlatanov @ 2013-02-06 18:54 UTC (permalink / raw)
To: demerphq; +Cc: Junio C Hamano, git, Jeff King
In-Reply-To: <CANgJU+X=Bb=ncqOxsd1hZDWsnFkt-bJw=Zbtuz8_KC0gO-dLaQ@mail.gmail.com>
On Wed, 6 Feb 2013 19:44:16 +0100 demerphq <demerphq@gmail.com> wrote:
d> Ah ok. Right, at a low level:
d> if (condition) { do_this() }
d> is identical to
d> condition && do_this();
d> IOW, Perl allows logical operators to act as control flow statements.
d> I hope your document include something that says that using logical
d> operators as control flow statements should be used sparingly, and
d> generally should be restricted to low precedence operators and should
d> never involve more than one operator.
I'd stay away from wording it so tightly, but instead just say
"Make your code readable and sensible, and don't try to be clever."
But this is good C and shell advice too, so I'd put it under "General
Guidelines" and leave it for Junio to decide if it's appropriate.
Ted
^ permalink raw reply
* Re: [PATCH v3 0/8] Hiding refs
From: Junio C Hamano @ 2013-02-06 19:17 UTC (permalink / raw)
To: Duy Nguyen
Cc: Michael Haggerty, Jonathan Nieder, git, Jeff King, Shawn Pearce
In-Reply-To: <CACsJy8BhL4qDb8BgOVuaUFF_9GXvgu55urYyKqPuZMZCTCoLwA@mail.gmail.com>
Duy Nguyen <pclouds@gmail.com> writes:
> On Tue, Feb 5, 2013 at 5:29 PM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
>> Hiderefs creates a "dark" corner of a remote git repo that can hold
>> arbitrary content that is impossible for anybody to discover but
>> nevertheless possible for anybody to download (if they know the name of
>> a hidden reference). In earlier versions of the patch series I believe
>> that it was possible to push to a hidden reference hierarchy, which made
>> it possible to upload dark content. The new version appears (from the
>> code) to prohibit adding references in a hidden hierarchy, which would
>> close the main loophole that I was worried about. But the documentation
>> and the unit tests only explicitly say that updates and deletes are
>> prohibited; nothing is said about adding references (unless "update" is
>> understood to include "add"). I think the true behavior should be
>> clarified and tested.
>>
>> I was worried that somehow this "dark" content could be used for
>> malicious purposes; for example, pushing compromised code then
>> convincing somebody to download it by SHA1 with the implicit argument
>> "it's safe since it comes directly from the project's official
>> repository". If it is indeed impossible to populate the dark namespace
>> remotely then I can't think of a way to exploit it.
>
> Or you can think hiderefs is the first step to addressing the
> initial ref advertisment problem. The series says hidden refs are
> to be fetched out of band, but that's not the only way.
Let me help unconfuse this thread.
I think the series as 8-patch series was poorly presented, and
separating it into two will help understanding what they are about.
The first three:
upload-pack: share more code
upload-pack: simplify request validation
upload/receive-pack: allow hiding ref hierarchies
is _the_ topic of the series. As far as I am concerned (I am not
speaking for Gerrit users, but am speaking as the Git maintainer),
the topic is solely about uncluttering. There may be refs that the
server end may need to keep for its operation, but that remote users
have _no_ business knowing about. Allowing the server to keep these
refs in the repository, while not showing these refs over the wire,
is the problem the series solves.
In other words, it is not about "these are *usually* not wanted by
clients, so do not show them by default". It is about "these are
not to be shown, ever".
OK?
Now, there may be some refs that are not *usually* wanted by clients
but there may be cases where clients want to
(1) learn about them via the same protocol; and/or
(2) fetch them over the protocol.
If you want to solve both of these two issues generally, the
solution has to involve a separate protocol from the today's
protocol. It would go like this:
* The upload-pack-2 service sits on a port different from today's,
waits for a ls-remote/fetch/clone client to connect to it, makes
a default advertisement that only includes the refs that are
usually wanted by clients with hints on what other refs the
initial advertisement omitted, to let the client know that it is
allowed to ask for them.
* An updated client, if it sees that some refs are omitted from the
initial advertisement *and* what the user told it to fetch or
list may be one of the omitted ones (this is why the server gives
hints in the previous step in the first step; when the server
says it did not omit anything, or when it says it omitted only
refs/pull/*, a client that wanted to fetch refs/heads/frotz will
know the request will fail without continuing this step), then
makes a "expand-refs" request to the server, asking for the refs
it did not see and the server could supply.
* When the server sees "expand-refs", it responds with additional
advertisement. "expand-refs refs/pull/*" may result in listing
of all refs in that hierarchy. "expand-refs refs/changes/1/1"
would result in listing that single ref. "expand-refs no-such"
may result in nothing, indicating an error.
* After the (possible) expand-refs exchange, the client knows
exactly the same and necessary information as the current
protocol gives it in order to go to the common ancestor discovery
step, and the protocol can continue the same way as the current
protocol.
Note that this cannot sit on the current port in general, as
existing clients will not be able to tell some refs are not
advertised, so unless you are hiding large and truly unused part of
the refspace, interoperability with older clients will render the
mechanism useless. You cannot use this to delay the refs/tags/
hierarchy with this mechanism and have older client come to the
updated service that by default does not advertise tags, for
example.
The above is what I called the "delayed advertisement" in the
discussion, which was brought up several months ago but nothing
materialized as the result. People who are interested in pursuing
this can volunteer and start discussing the design refinements now
and submit implementation for reviews.
But in the meantime, if there is a niche use case where a solution
to only the second problem is sufficient (and Gerrit and GitHub pull
requests could both be such use cases), the remainder of the series
can help, without waiting the solution to solve "usually not wanted
but may need to be learned" problem. That is the latter 4 patches
(the very last one is a demonstration to illustrate why allowing a
push to hidden ref hierarchy would not and should not work, and is
not for application):
parse_fetch_refspec(): clarify the codeflow a bit
fetch: use struct ref to represent refs to be fetched
upload-pack: optionally allow fetching from the tips of hidden refs
fetch: fetch objects by their exact SHA-1 object names
^ permalink raw reply
* Re: What's cooking in git.git (Feb 2013, #03; Wed, 6)
From: Jens Lehmann @ 2013-02-06 19:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8v71cn3m.fsf@alter.siamese.dyndns.org>
Am 06.02.2013 19:29, schrieb Junio C Hamano:
> * jl/submodule-deinit (2013-02-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.
>
> Will merge to 'next'.
Oops, I though you were waiting for a reroll. Currently I'm having the
appended interdiff compared to your version. Changes are:
- Add deinit to the --force documentation of "git submodule"
- Never remove submodules containing a .git dir, even when forced
- diagnostic output when "rm -rf" or "mkdir" fails
- More test cases
And I wanted to add three more test cases for modified submodules before
sending v4. You could squash in the first two hunks into the commit you
have in pu and I'll send a follow up patch with the extra tests soon or
you could wait for me sending an updated patch. What do you think?
---------------8<------------------
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index 7a149eb..45ee12b 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -227,8 +227,10 @@ OPTIONS
-f::
--force::
- This option is only valid for add and update commands.
+ This option is only valid for add, deinit and update commands.
When running add, allow adding an otherwise ignored submodule path.
+ When running deinit the submodule work trees will be removed even if
+ they contain local changes.
When running update, throw away local changes in submodules when
switching to a different commit; and always run a checkout operation
in the submodule, even if the commit listed in the index of the
diff --git a/git-submodule.sh b/git-submodule.sh
index f05b597..365c6de 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -595,14 +595,25 @@ cmd_deinit()
continue
fi
- # Remove the submodule work tree
- if test -z "$force"
+ # Remove the submodule work tree (unless the user already did it)
+ if test -d "$sm_path"
then
- git rm -n "$sm_path" ||
- die "$(eval_gettext "Submodule work tree $sm_path contains local modifications, use '-f' to discard them")"
+ # Protect submodules containing a .git directory
+ if test -d "$sm_path/.git"
+ then
+ echo >&2 "$(eval_gettext "Submodule work tree $sm_path contains a .git directory")"
+ die "$(eval_gettext "(use 'rm -rf' if you really want to remove it including all of its history)")"
+ fi
+
+ if test -z "$force"
+ then
+ git rm -n "$sm_path" ||
+ die "$(eval_gettext "Submodule work tree $sm_path contains local modifications, use '-f' to discard them")"
+ fi
+ rm -rf "$sm_path" || say "$(eval_gettext "Could not remove submodule work tree '\$sm_path'")"
fi
- rm -rf "$sm_path"
- mkdir "$sm_path"
+
+ mkdir "$sm_path" || say "$(eval_gettext "Could not create empty submodule directory '\$sm_path'")"
# Remove the whole section so we have a clean state when the
# user later decides to init this submodule again
diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
index 34d8274..0567f1a 100755
--- a/t/t7400-submodule-basic.sh
+++ b/t/t7400-submodule-basic.sh
@@ -757,20 +757,46 @@ test_expect_success 'submodule add with an existing name fails unless forced' '
)
'
+test_expect_success 'set up a second submodule' '
+ git submodule add ./init2 example2 &&
+ git commit -m "submodle example2 added"
+'
+
test_expect_success 'submodule deinit should remove the whole submodule section from .git/config' '
git config submodule.example.foo bar &&
+ git config submodule.example2.frotz nitfol &&
git submodule deinit init &&
test -z "$(git config submodule.example.url)" &&
- test -z "$(git config submodule.example.foo)"
+ test -z "$(git config submodule.example.foo)" &&
+ test -n "$(git config submodule.example2.url)" &&
+ test -n "$(git config submodule.example2.frotz)" &&
+ rmdir init
'
test_expect_success 'submodule deinit . deinits all initialized submodules' '
git submodule update --init &&
git config submodule.example.foo bar &&
+ git config submodule.example2.frotz nitfol &&
test_must_fail git submodule deinit &&
git submodule deinit . &&
test -z "$(git config submodule.example.url)" &&
- test -z "$(git config submodule.example.foo)"
+ test -z "$(git config submodule.example.foo)" &&
+ test -z "$(git config submodule.example2.url)" &&
+ test -z "$(git config submodule.example2.frotz)" &&
+ rmdir init example2
+'
+
+test_expect_success 'submodule deinit deinits a submodule when its work tree is missing or empty' '
+ git submodule update --init &&
+ rm -rf init example2/* example2/.git &&
+ git config submodule.example.foo bar &&
+ git config submodule.example2.frotz nitfol &&
+ git submodule deinit init example2 &&
+ test -z "$(git config submodule.example.url)" &&
+ test -z "$(git config submodule.example.foo)" &&
+ test -z "$(git config submodule.example2.url)" &&
+ test -z "$(git config submodule.example2.frotz)" &&
+ rmdir init
'
test_expect_success 'submodule deinit complains when explicitly used on an uninitialized submodule' '
@@ -778,7 +804,24 @@ test_expect_success 'submodule deinit complains when explicitly used on an unini
git submodule deinit init >actual &&
test_i18ngrep "Submodule .example. (.*) unregistered for path .init" actual
git submodule deinit init >actual &&
- test_i18ngrep "No url found for submodule path .init. in .git/config" actual
+ test_i18ngrep "No url found for submodule path .init. in .git/config" actual &&
+ git submodule deinit . >actual &&
+ test_i18ngrep "Submodule .example2. (.*) unregistered for path .example2" actual
+ rmdir init example2
+'
+
+test_expect_success 'submodule deinit fails when submodule has a .git directory even when forced' '
+ git submodule update --init &&
+ (
+ cd init &&
+ rm .git &&
+ cp -R ../.git/modules/example .git &&
+ GIT_WORK_TREE=. git config --unset core.worktree
+ ) &&
+ test_must_fail git submodule deinit init &&
+ test_must_fail git submodule deinit -f init &&
+ test -d init/.git &&
+ test -n "$(git config submodule.example.url)"
'
test_done
^ permalink raw reply related
* Re: CodingGuidelines Perl amendment
From: Junio C Hamano @ 2013-02-06 19:37 UTC (permalink / raw)
To: Ted Zlatanov; +Cc: demerphq, git, Jeff King
In-Reply-To: <87bobxgtmw.fsf@lifelogs.com>
Ted Zlatanov <tzz@lifelogs.com> writes:
> "Make your code readable and sensible, and don't try to be clever."
>
> But this is good C and shell advice too,...
Sounds sensible.
^ permalink raw reply
* Re: What's cooking in git.git (Feb 2013, #03; Wed, 6)
From: Junio C Hamano @ 2013-02-06 19:39 UTC (permalink / raw)
To: Jens Lehmann; +Cc: git
In-Reply-To: <5112AE34.6080107@web.de>
Jens Lehmann <Jens.Lehmann@web.de> writes:
> Am 06.02.2013 19:29, schrieb Junio C Hamano:
>> * jl/submodule-deinit (2013-02-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.
>>
>> Will merge to 'next'.
>
> Oops, I though you were waiting for a reroll. Currently I'm having the
> appended interdiff compared to your version. Changes are:
>
> - Add deinit to the --force documentation of "git submodule"
> - Never remove submodules containing a .git dir, even when forced
> - diagnostic output when "rm -rf" or "mkdir" fails
> - More test cases
>
> And I wanted to add three more test cases for modified submodules before
> sending v4. You could squash in the first two hunks into the commit you
> have in pu and I'll send a follow up patch with the extra tests soon or
> you could wait for me sending an updated patch. What do you think?
I haven't merged it down to 'next' yet. So please proceed as you
planned. Thanks for stopping me.
^ permalink raw reply
* Re: [PATCH v3 0/8] Hiding refs
From: Jonathan Nieder @ 2013-02-06 19:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Duy Nguyen, Michael Haggerty, git, Jeff King, Shawn Pearce
In-Reply-To: <7v4nhpckwd.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Duy Nguyen <pclouds@gmail.com> writes:
>> On Tue, Feb 5, 2013 at 5:29 PM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
>>> Hiderefs creates a "dark" corner of a remote git repo
[...]
>> Or you can think hiderefs is the first step to addressing the
>> initial ref advertisment problem. The series says hidden refs are
>> to be fetched out of band, but that's not the only way.
>
> Let me help unconfuse this thread.
>
> I think the series as 8-patch series was poorly presented, and
> separating it into two will help understanding what they are about.
>
> The first three:
>
> upload-pack: share more code
> upload-pack: simplify request validation
> upload/receive-pack: allow hiding ref hierarchies
>
> is _the_ topic of the series. As far as I am concerned (I am not
> speaking for Gerrit users, but am speaking as the Git maintainer),
> the topic is solely about uncluttering. There may be refs that the
> server end may need to keep for its operation, but that remote users
> have _no_ business knowing about.
An obvious question when looking at that alone is, is there ever
actually need for such private refs? If the refs are not meant to be
shared with users *at all*, why are they even refs?
An answer is "because refs force gc to keep the corresponding
objects". For example, the sysadmin may want to keep refs/archived/
refs for dead branches that should not be advertised or accessible to
the user any more. Seems sane, though not especially exciting.
What is more exciting to me is that it is a first step toward
addressing the complicated problem of offering access to more refs
than can be efficiently presented in the current ref advertisement. I
think that's a harder problem but something like this would be needed
in order to support existing clients without performance degredation.
And in the meantime, it helps with the refs/archived case.
Thanks for explaining.
Jonathan
^ permalink raw reply
* [PATCH v2] Update CodingGuidelines for Perl 5
From: Ted Zlatanov @ 2013-02-06 19:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: demerphq, git, Jeff King
In-Reply-To: <7vwqulb5el.fsf@alter.siamese.dyndns.org>
Update the coding guidelines for Perl 5.
Signed-off-by: Ted Zlatanov <tzz@lifelogs.com>
---
Changes since PATCHv1:
- removed brace guidelines
- add "don't try to be clever" at beginning
Documentation/CodingGuidelines | 42 ++++++++++++++++++++++++++++++++++++++++
1 files changed, 42 insertions(+), 0 deletions(-)
diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
index 1d7de5f..166c141 100644
--- a/Documentation/CodingGuidelines
+++ b/Documentation/CodingGuidelines
@@ -18,6 +18,8 @@ code. For Git in general, three rough rules are:
judgement call, the decision based more on real world
constraints people face than what the paper standard says.
+For any programming language below, make your code readable and sensible, and
+don't try to be clever.
As for more concrete guidelines, just imitate the existing code
(this is a good guideline, no matter which project you are
@@ -179,6 +181,46 @@ For C programs:
- Use Git's gettext wrappers to make the user interface
translatable. See "Marking strings for translation" in po/README.
+For Perl 5 programs:
+
+ - Most of the C guidelines above apply.
+
+ - We try to support Perl 5.8 and later ("use Perl 5.008").
+
+ - use strict and use warnings are strongly preferred.
+
+ - Don't abuse statement modifiers--they are discouraged. But in general:
+
+ ... do something ...
+ do_this() unless (condition);
+ ... do something else ...
+
+ should be used instead of
+
+ ... do something ...
+ unless (condition) {
+ do_this();
+ }
+ ... do something else ...
+
+ *only* when when the condition is so rare that do_this() will be called
+ almost always.
+
+ - We try to avoid assignments inside if().
+
+ - Learn and use Git.pm if you need that functionality.
+
+ - For Emacs, it's useful to put the following in
+ GIT_CHECKOUT/.dir-locals.el, assuming you use cperl-mode:
+
+ ;; note the first part is useful for C editing, too
+ ((nil . ((indent-tabs-mode . t)
+ (tab-width . 8)
+ (fill-column . 80)))
+ (cperl-mode . ((cperl-indent-level . 8)
+ (cperl-extra-newline-before-brace . nil)
+ (cperl-merge-trailing-else . t))))
+
Writing Documentation:
Every user-visible change should be reflected in the documentation.
--
1.7.9.rc2
^ permalink raw reply related
* Re: [PATCH v3 0/8] Hiding refs
From: Jonathan Nieder @ 2013-02-06 19:55 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Junio C Hamano, git, Jeff King, Shawn Pearce
In-Reply-To: <51122D9D.9040100@alum.mit.edu>
Michael Haggerty wrote:
> Scenario 1: Some providers junk up their users' repositories with
> content that is not created by the repository's owner and that the owner
> doesn't want to appear to vouch for (e.g., GitHub pull requests). These
> references might sometimes be useful to fetch, singly or in bulk.
>
> Scenario 2: Some systems junk up their users' repositories with
> additional references that are not interesting to most pullers (e.g.,
> Gerrit activity markers) though they don't add questionable content.
Actually Gerrit's refs/changes refs are pretty similar to Github's
refs/pull. Both are requests for code review.
[...]
> But now every time I do a "gitk --all" or "git log --decorate", the
> output is cluttered with all of his references (most of which are just
> old versions of references from the upstream repository that we both
> use). I would like to be able to hide his references most of the time
> but turn them back on when I need them.
>
> Scenario 5: Our upstream repository has gazillions of release tags under
> "refs/tags/releases/...", sometimes including customer-specific
> releases. In my daily life these are just clutter.
For both of these use cases, putting the refs somewhere other than
refs/heads, refs/tags, and refs/remotes should be enough to avoid
clutter.
I agree that a --decorate-glob along the lines of "git rev-parse"'s
--glob would be nice.
[...]
> * Some small improvements (e.g. allowing *multiple* views to be
> defined) would provide much more benefit for about the same effort,
> and would be a better base for building other features in the future
> (e.g., local views).
Would advertising GIT_CONFIG_PARAMETERS and giving examples for server
admins to set it in inetd et al to provide different kinds of access
to a same repository through different URLs work?
> Thanks for listening.
> Michael
>
> [1] Theoretically one could support multiple views of a single
> repository by using something like "GIT_CONFIG=view_1_config git
> upload-pack ..." or "git -c transfer.hiderefs=... git upload-pack ...",
> but this would be awkward.
Ah, I missed this comment before. What's awkward about that? I
think it's a clean way to make many aspects of how a repository is
presented (including hook actions) configurable.
Thanks for your help clarifying this feature. Hopefully some of the
discussion will filter into the documentation.
Jonathan
^ permalink raw reply
* [PATCH] graph: output padding for merge subsequent parents
From: John Keeping @ 2013-02-06 19:57 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Dale R. Worley, gitster, git
In-Reply-To: <vpqbobxwavv.fsf@grenoble-inp.fr>
On Wed, Feb 06, 2013 at 07:33:08PM +0100, Matthieu Moy wrote:
> John Keeping <john@keeping.me.uk> writes:
>
> > I would argue that the line should start with "| | ", since it really is
> > just a continuation of the same commit.
> >
> > | |
> > | | commit a393ed598e9fb11436f85bd58f1a38c82f2cadb7 (from 33e70e70c0173d634826b998bdc304f93c0966b8)
> > | | Merge: 2c1e6a3 33e70e7
> > | | Author: Matthieu Moy <Matthieu.Moy@imag.fr>
> > | | Date: Tue Feb 5 22:05:33 2013 +0100
>
> Yes.
>
> I had a look at the code, I guess the call to graph_show_commit() in
> show_log() (in log-tree.c) should have called graph_show_padding() but
> didn't in this case. Then I got lost in graph.c :-(.
I think this is the correct answer. But now I've found that "git log
--graph -c -p" doesn't indent the diff - that seems to be a separate
issue.
-- >8 --
When showing merges in git-log, the same commit is shown once for each
parent. Combined with "--graph" this results in graph_show_commit()
being called once for each parent without graph_update() being called.
Currently graph_show_commit() does not print anything on subsequent
invocations for the same commit (this was changed by commit 656197a -
"graph.c: infinite loop in git whatchanged --graph -m" from the previous
behaviour of looping infinitely).
Change this so that if the graph code believes it has already shown the
commit it prints a single padding line.
Signed-off-by: John Keeping <john@keeping.me.uk>
---
graph.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/graph.c b/graph.c
index 391a712..2a3fc5c 100644
--- a/graph.c
+++ b/graph.c
@@ -1227,6 +1227,16 @@ void graph_show_commit(struct git_graph *graph)
if (!graph)
return;
+ /*
+ * When showing a diff of a merge against each of its parents, we
+ * are called once for each parent without graph_update having been
+ * called. In this case, simply output a single padding line.
+ */
+ if (graph_is_commit_finished(graph)) {
+ graph_show_padding(graph);
+ shown_commit_line = 1;
+ }
+
while (!shown_commit_line && !graph_is_commit_finished(graph)) {
shown_commit_line = graph_next_line(graph, &msgbuf);
fwrite(msgbuf.buf, sizeof(char), msgbuf.len, stdout);
--
1.8.1.2
^ permalink raw reply related
* Re: [RFC] test-lib.sh: No POSIXPERM for cygwin
From: Torsten Bögershausen @ 2013-02-06 20:16 UTC (permalink / raw)
To: kusmabite; +Cc: Torsten Bögershausen, ramsay, git, j6t
In-Reply-To: <CABPQNSYmGhaDG0Dzpp2C0ZwKoFwP5EokJW+TC8JT-Bw6rKa79A@mail.gmail.com>
Am 2013-02-06 10:34, schrieb Erik Faye-Lund:
> On Sun, Jan 27, 2013 at 3:57 PM, Torsten Bögershausen <tboegi@web.de> wrote:
>> t0070 and t1301 fail when running the test suite under cygwin.
>> Skip the failing tests by unsetting POSIXPERM.
>>
>
> But is this the real reason? I thought Cygwin implemented POSIX permissions...?
t0070:
'mktemp to unwritable directory prints filename'
mkdir cannotwrite &&
chmod -w cannotwrite &&
test_when_finished "chmod +w cannotwrite" &&
test_must_fail test-mktemp cannotwrite/testXXXXXX 2>err &&
grep "cannotwrite/test" err
When a directory under Linux/*nix has no write permission,
it is not allowed to create another directory (or file..) here.
This is not working under cygwin, a directory/file can be created
even if the parent directory has chmod 0.
-------------
tb@PC /cygdrive/c/temp
$ mkdir ttt
tb@PC /cygdrive/c/temp
$ chmod 0 ttt
tb@PC /cygdrive/c/temp
$ ls -ld ttt
d---------+ 1 tb None 0 Feb 6 20:33 ttt
tb@PC /cygdrive/c/temp
$ touch ttt/x
tb@PC /cygdrive/c/temp
$ ls -ld ttt
d---------+ 1 tb None 0 Feb 6 20:33 ttt
tb@PC /cygdrive/c/temp
$ ls -l ttt
total 0
-rw-r--r--+ 1 tb None 0 Feb 6 20:33 x
-------------------------------------------
If this is POSIX compliant? I'm not an expert here.
On the other hand:
This test case does not test git, but rather the file system,
so we can probaly remove it?
About 1301:
Some resereach needs to be done, to find out the connection between
umask, cygwin and the mount options.
On my system I have:
$mount
C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto)
/Torsten
^ permalink raw reply
* [PATCH 0/4] Make git-send-email git-credential
From: Michal Nazarewicz @ 2013-02-06 20:34 UTC (permalink / raw)
To: Junio C Hamano, Ted Zlatanov, Jeff King, Matthieu Moy; +Cc: git
From: Michal Nazarewicz <mina86@mina86.com>
As discussed on the list, adding git-credential interface to Git.pm
(sort of copied from git-remote-mediawiki) and making git-send-email
use it.
I see git-remote-mediawiki does not have “use Git” so I did not touch
it. On top of that I'd have no way to tests the changes anyway.
Michal Nazarewicz (4):
Git.pm: Allow command_close_bidi_pipe() to be called as method
Git.pm: Allow pipes to be closed prior to calling
command_close_bidi_pipe
Git.pm: Add interface for git credential command.
git-send-email: Use git credential to obtain password.
Documentation/git-send-email.txt | 4 +-
git-send-email.perl | 60 +++++++++++---------
perl/Git.pm | 116 ++++++++++++++++++++++++++++++++++++++-
3 files changed, 149 insertions(+), 31 deletions(-)
--
1.8.1.2.550.g0d3a9c0.dirty
^ permalink raw reply
* Re: [PATCH 0/4] Make git-send-email git-credential
From: Michal Nazarewicz @ 2013-02-06 20:38 UTC (permalink / raw)
To: Junio C Hamano, Ted Zlatanov, Jeff King, Matthieu Moy; +Cc: git
In-Reply-To: <cover.1360172967.git.mina86@mina86.com>
[-- Attachment #1: Type: text/plain, Size: 1289 bytes --]
On Wed, Feb 06 2013, Michal Nazarewicz wrote:
> As discussed on the list, adding git-credential interface to Git.pm
> (sort of copied from git-remote-mediawiki) and making git-send-email
> use it.
>
> I see git-remote-mediawiki does not have “use Git” so I did not touch
> it. On top of that I'd have no way to tests the changes anyway.
>
> Michal Nazarewicz (4):
> Git.pm: Allow command_close_bidi_pipe() to be called as method
> Git.pm: Allow pipes to be closed prior to calling
> command_close_bidi_pipe
> Git.pm: Add interface for git credential command.
> git-send-email: Use git credential to obtain password.
>
> Documentation/git-send-email.txt | 4 +-
> git-send-email.perl | 60 +++++++++++---------
> perl/Git.pm | 116 ++++++++++++++++++++++++++++++++++++++-
> 3 files changed, 149 insertions(+), 31 deletions(-)
On second thought, give me a moment, ;) I've just discovered a bug
preventing git-send-email from mailing a patchset.
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michał “mina86” Nazarewicz (o o)
ooo +----<email/xmpp: mpn@google.com>--------------ooO--(_)--Ooo--
[-- Attachment #2.1: Type: text/plain, Size: 0 bytes --]
[-- Attachment #2.2: Type: application/pgp-signature, Size: 835 bytes --]
^ permalink raw reply
* Re: Why is ident_is_sufficient different on Windows?
From: Junio C Hamano @ 2013-02-06 20:41 UTC (permalink / raw)
To: Max Horn; +Cc: git
In-Reply-To: <991CBC1C-912C-4DD6-B911-93F6B41D895E@quendi.de>
Max Horn <max@quendi.de> writes:
> static int ident_is_sufficient(int user_ident_explicitly_given)
> {
> #ifndef WINDOWS
> return (user_ident_explicitly_given & IDENT_MAIL_GIVEN);
> #else
> return (user_ident_explicitly_given == IDENT_ALL_GIVEN);
> #endif
> }
>
>
> According to git blame, this was introduced here:
>
> commit 5aeb3a3a838b2cb03d250f3376cf9c41f4d4608e
> Author: Junio C Hamano <gitster@pobox.com>
> Date: Sun Jan 17 13:54:28 2010 -0800
>
> user_ident_sufficiently_given(): refactor the logic to be usable from elsewhere
>
>
> The commit message sounds as if this was only a refactoring, but
> the patch to me look as if it changes behaviour, too. Of course
> this could very well be false, say due to code elsewhere that
> already caused Windows to behave differently; I wouldn't know.
>
> Still, I wonder: Why does this difference exist?
Sorry but I do not recall why these ifdefs are there. The commit
did this to builtin-commit.c:
- if (user_ident_explicitly_given != IDENT_ALL_GIVEN)
+ if (!user_ident_sufficiently_given())
I would have written the function to always check with ALL_GIVEN
myself, and it is very likely that I was *not* the person who
noticed that the function needs to behave differently on Windows, as
I do not do Windows.
I suspect somebody from the Windows camp saw a patch I posted
without the ifdef, noticed that there is a problem to expect
IDENT_NAME_GIVEN to be set on Windows for some reason, and resulted
in a reroll of the function in that shape.
I didn't find anything in the list archive, though. So I am
stumped.
^ permalink raw reply
* [PATCH 0/4] Make git-send-email git-credential
From: Michal Nazarewicz @ 2013-02-06 20:47 UTC (permalink / raw)
To: Junio C Hamano, Ted Zlatanov, Jeff King, Matthieu Moy; +Cc: git
From: Michal Nazarewicz <mina86@mina86.com>
As discussed on the list, adding git-credential interface to Git.pm
(sort of copied from git-remote-mediawiki) and making git-send-email
use it.
I see git-remote-mediawiki does not have “use Git” so I did not touch
it. On top of that I'd have no way to tests the changes anyway.
Michal Nazarewicz (4):
Git.pm: Allow command_close_bidi_pipe() to be called as method
Git.pm: Allow pipes to be closed prior to calling
command_close_bidi_pipe
Git.pm: Add interface for git credential command.
git-send-email: Use git credential to obtain password.
Documentation/git-send-email.txt | 4 +-
git-send-email.perl | 59 +++++++++++---------
perl/Git.pm | 116 ++++++++++++++++++++++++++++++++++++++-
3 files changed, 149 insertions(+), 30 deletions(-)
--
1.8.1.2.549.g4fa355e
^ permalink raw reply
* [PATCH 1/4] Git.pm: Allow command_close_bidi_pipe() to be called as method
From: Michal Nazarewicz @ 2013-02-06 20:47 UTC (permalink / raw)
To: Junio C Hamano, Ted Zlatanov, Jeff King, Matthieu Moy; +Cc: git
In-Reply-To: <cover.1360183427.git.mina86@mina86.com>
From: Michal Nazarewicz <mina86@mina86.com>
The documentation of command_close_bidi_pipe() claims that it can
be called as a method, but it does not check whether the first
argument is $self or not assuming the latter. Using _maybe_self()
fixes this.
Signed-off-by: Michal Nazarewicz <mina86@mina86.com>
---
perl/Git.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/perl/Git.pm b/perl/Git.pm
index 931047c..bbb753a 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -430,7 +430,7 @@ have more complicated structure.
sub command_close_bidi_pipe {
local $?;
- my ($pid, $in, $out, $ctx) = @_;
+ my ($self, $pid, $in, $out, $ctx) = _maybe_self(@_);
foreach my $fh ($in, $out) {
unless (close $fh) {
if ($!) {
--
1.8.1.2.549.g4fa355e
^ permalink raw reply related
* [PATCH 2/4] Git.pm: Allow pipes to be closed prior to calling command_close_bidi_pipe
From: Michal Nazarewicz @ 2013-02-06 20:47 UTC (permalink / raw)
To: Junio C Hamano, Ted Zlatanov, Jeff King, Matthieu Moy; +Cc: git
In-Reply-To: <cover.1360183427.git.mina86@mina86.com>
From: Michal Nazarewicz <mina86@mina86.com>
The command_close_bidi_pipe() function will insist on closing both
input and output pipes returned by command_bidi_pipe(). With this
change it is possible to close one of the pipes in advance and
pass undef as an argument.
This allows for something like:
my ($pid, $in, $out, $ctx) = command_bidi_pipe(...);
print $out "write data";
close $out;
# ... do stuff with $in
command_close_bidi_pipe($pid, $in, undef, $ctx);
Signed-off-by: Michal Nazarewicz <mina86@mina86.com>
---
perl/Git.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/perl/Git.pm b/perl/Git.pm
index bbb753a..6a2d52d 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -432,7 +432,7 @@ sub command_close_bidi_pipe {
local $?;
my ($self, $pid, $in, $out, $ctx) = _maybe_self(@_);
foreach my $fh ($in, $out) {
- unless (close $fh) {
+ if (defined $fh && !close $fh) {
if ($!) {
carp "error closing pipe: $!";
} elsif ($? >> 8) {
--
1.8.1.2.549.g4fa355e
^ permalink raw reply related
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