* Re: [PATCH] replace: parse revision argument for -d
From: Michael J Gruber @ 2012-10-29 9:02 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20121029065836.GC5102@sigill.intra.peff.net>
Jeff King venit, vidit, dixit 29.10.2012 07:58:
> On Fri, Oct 26, 2012 at 03:33:27PM +0200, Michael J Gruber wrote:
>
>> for (p = argv; *p; p++) {
>> - if (snprintf(ref, sizeof(ref), "refs/replace/%s", *p)
>> + q = *p;
>> + if (get_sha1(q, sha1))
>> + warning("Failed to resolve '%s' as a valid ref; taking it literally.", q);
>> + else
>> + q = sha1_to_hex(sha1);
>
> Doesn't get_sha1 already handle this for 40-byte sha1s (and for anything
> else, it would not work anyway)?
What is "this"???
So far, "git replace -d <rev>" only accepts a full sha1, because it uses
it literally as a ref name "resf/replace/<rev>" without resolving anything.
The patch makes it so that <rev> gets resolved to a sha1 even if it is
abbreviated, and then it gets used.
Or do you mean the warning?
Michael
^ permalink raw reply
* Re: [PATCH] replace: parse revision argument for -d
From: Jeff King @ 2012-10-29 9:04 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <508E4637.2060903@drmicha.warpmail.net>
On Mon, Oct 29, 2012 at 10:02:47AM +0100, Michael J Gruber wrote:
> Jeff King venit, vidit, dixit 29.10.2012 07:58:
> > On Fri, Oct 26, 2012 at 03:33:27PM +0200, Michael J Gruber wrote:
> >
> >> for (p = argv; *p; p++) {
> >> - if (snprintf(ref, sizeof(ref), "refs/replace/%s", *p)
> >> + q = *p;
> >> + if (get_sha1(q, sha1))
> >> + warning("Failed to resolve '%s' as a valid ref; taking it literally.", q);
> >> + else
> >> + q = sha1_to_hex(sha1);
> >
> > Doesn't get_sha1 already handle this for 40-byte sha1s (and for anything
> > else, it would not work anyway)?
>
> What is "this"???
>
> So far, "git replace -d <rev>" only accepts a full sha1, because it uses
> it literally as a ref name "resf/replace/<rev>" without resolving anything.
>
> The patch makes it so that <rev> gets resolved to a sha1 even if it is
> abbreviated, and then it gets used.
>
> Or do you mean the warning?
Sorry, yeah, I meant the warning and fallback.
If I understand correctly, the fallback will never work unless we are
fed a 40-byte sha1. But get_sha1 should always return a 40-byte sha1
without doing any further processing.
-Peff
^ permalink raw reply
* Re: [PATCH] gitk: Do not select file list entries during diff loading
From: Stefan Haller @ 2012-10-29 8:56 UTC (permalink / raw)
To: Peter Oberndorfer, git; +Cc: Paul Mackerras
In-Reply-To: <508B08CB.5060702@arcor.de>
Peter Oberndorfer <kumbayo84@arcor.de> wrote:
> Please review/test the patch carefully before applying,
> since i do not often work with tcl/tk :-)
The patch makes perfect sense to me. (I'm not a great tcl coder either
though, and not very familiar with the gitk code; so another review
would be helpful.)
Just one minor suggestion:
> proc scrolltext {f0 f1} {
> - global searchstring cmitmode ctext
> + global searchstring cmitmode ctext ctext_last_scroll_pos
> global suppress_highlighting_file_for_this_scrollpos
>
> + .bleft.bottom.sb set $f0 $f1
> + if {$searchstring ne {}} {
> + searchmarkvisible 0
> + }
> +
> set topidx [$ctext index @0,0]
> + if {$topidx eq $ctext_last_scroll_pos} return
> + set ctext_last_scroll_pos $topidx
> +
> if {![info exists suppress_highlighting_file_for_this_scrollpos]
> || $topidx ne $suppress_highlighting_file_for_this_scrollpos} {
> highlightfile_for_scrollpos $topidx
> }
>
> catch {unset suppress_highlighting_file_for_this_scrollpos}
> -
> - .bleft.bottom.sb set $f0 $f1
> - if {$searchstring ne {}} {
> - searchmarkvisible 0
> - }
> }
I don't like early returns, they can easily become a source of bugs when
someone adds more code to the end of a function without realizing that
there's an early return in the middle. I'd much rather say something
like
if {$topidx ne $ctext_last_scroll_pos} {
if {![info exists suppress_highlighting_file_for_this_scrollpos]
|| $topidx ne $suppress_highlighting_file_for_this_scrollpos} {
highlightfile_for_scrollpos $topidx
}
set ctext_last_scroll_pos $topidx
}
-Stefan
--
Stefan Haller
Berlin, Germany
http://www.haller-berlin.de/
^ permalink raw reply
* Re: git push tags
From: Michael Haggerty @ 2012-10-29 9:58 UTC (permalink / raw)
To: Angelo Borsotti; +Cc: Philip Oakley, Chris Rorvick, Johannes Sixt, git
In-Reply-To: <CAB9Jk9AOBGL785rSo1FLQd4pKpHRdvmJ21wWsZ=L0z7SF=6Suw@mail.gmail.com>
I agree with you that it is too easy to create chaos by changing tags in
a published repository and that git should do more to prevent this from
happening without explicit user forcing. The fact that git internally
handles tags similarly to other references is IMO an excuse for the
current behavior, but not a justification.
On 10/29/2012 09:12 AM, Angelo Borsotti wrote:
> to let the owner of a remote repository (one on which git-push
> deposits objects) disallow
> others to change tags, a key on its config file could be used.
> An option on git-push, or environment variable, or key in config file
> of the repo from which git-push takes objects do not help in enforcing
> the policy not to update tags in the remote repo.
If your remote repository is managed using gitolite, you can institute
restrictions on changing tags via the gitolite config.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: [PATCH] replace: parse revision argument for -d
From: Michael J Gruber @ 2012-10-29 10:08 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20121029090419.GA29464@sigill.intra.peff.net>
Jeff King venit, vidit, dixit 29.10.2012 10:04:
> On Mon, Oct 29, 2012 at 10:02:47AM +0100, Michael J Gruber wrote:
>
>> Jeff King venit, vidit, dixit 29.10.2012 07:58:
>>> On Fri, Oct 26, 2012 at 03:33:27PM +0200, Michael J Gruber wrote:
>>>
>>>> for (p = argv; *p; p++) {
>>>> - if (snprintf(ref, sizeof(ref), "refs/replace/%s", *p)
>>>> + q = *p;
>>>> + if (get_sha1(q, sha1))
>>>> + warning("Failed to resolve '%s' as a valid ref; taking it literally.", q);
>>>> + else
>>>> + q = sha1_to_hex(sha1);
>>>
>>> Doesn't get_sha1 already handle this for 40-byte sha1s (and for anything
>>> else, it would not work anyway)?
>>
>> What is "this"???
>>
>> So far, "git replace -d <rev>" only accepts a full sha1, because it uses
>> it literally as a ref name "resf/replace/<rev>" without resolving anything.
>>
>> The patch makes it so that <rev> gets resolved to a sha1 even if it is
>> abbreviated, and then it gets used.
>>
>> Or do you mean the warning?
>
> Sorry, yeah, I meant the warning and fallback.
>
> If I understand correctly, the fallback will never work unless we are
> fed a 40-byte sha1. But get_sha1 should always return a 40-byte sha1
> without doing any further processing.
You do understand correctly, and I misunderstood get_sha1(). I does not
check for the presence of that sha1 in the object db, so that it
succeeds no matter what, that is: if it's valid hex. So I should
probably rewrite the error handling: no more need to check for lengths.
Michael
^ permalink raw reply
* Re: git push tags
From: Kacper Kornet @ 2012-10-29 10:10 UTC (permalink / raw)
To: Angelo Borsotti; +Cc: Philip Oakley, Chris Rorvick, Johannes Sixt, git
In-Reply-To: <CAB9Jk9AOBGL785rSo1FLQd4pKpHRdvmJ21wWsZ=L0z7SF=6Suw@mail.gmail.com>
On Mon, Oct 29, 2012 at 09:12:52AM +0100, Angelo Borsotti wrote:
> Hi,
> to let the owner of a remote repository (one on which git-push
> deposits objects) disallow
> others to change tags, a key on its config file could be used.
> An option on git-push, or environment variable, or key in config file
> of the repo from which git-push takes objects do not help in enforcing
> the policy not to update tags in the remote repo.
It think these are two separate issues:
1. Enforcing policy that the server should not accept changes in
existing tags. This can be easily done with hooks.
2. Perform operation: push my tag if and only if it doesn't overwrite
tag which already exists on the server. I think currently it is not possible
with git.
--
Kacper
^ permalink raw reply
* What's cooking in git.git (Oct 2012, #09; Mon, 29)
From: Jeff King @ 2012-10-29 10:21 UTC (permalink / raw)
To: git
What's cooking in git.git (Oct 2012, #09; Mon, 29)
--------------------------------------------------
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
The second batch of topics has graduated to master. Most of the new
topics have been minor bugfixes or documentation updates, so I've merged
a lot of those to master.
You can find the changes described here in the integration branches of
my repository at:
git://github.com/peff/git.git
Until Junio returns, kernel.org and the other "usual" places will not be
updated.
--------------------------------------------------
[New Topics]
* fc/completion-test-simplification (2012-10-29) 2 commits
- completion: simplify __gitcomp test helper
- completion: refactor __gitcomp related tests
Clean up completion tests.
Will merge to 'next'.
* fc/remote-testgit-feature-done (2012-10-29) 1 commit
- remote-testgit: properly check for errors
* jk/maint-diff-grep-textconv (2012-10-28) 1 commit
- diff_grep: use textconv buffers for add/deleted files
(this branch is used by jk/pickaxe-textconv.)
Fixes inconsistent use of textconv with "git log -G".
Will merge to 'next'.
* jk/pickaxe-textconv (2012-10-28) 2 commits
- pickaxe: use textconv for -S counting
- pickaxe: hoist empty needle check
(this branch uses jk/maint-diff-grep-textconv.)
Use textconv filters when searching with "log -S".
Waiting for a sanity check and review from Junio.
* km/maint-doc-git-reset (2012-10-29) 1 commit
(merged to 'next' on 2012-10-29 at cdb4e8f)
+ doc: git-reset: make "<mode>" optional
Will merge to 'master' in the third batch.
* mh/maint-parse-dirstat-fix (2012-10-29) 1 commit
- parse_dirstat_params(): use string_list to split comma-separated string
Cleans up some code and avoids a potential bug.
Will merge to 'next'.
* nd/builtin-to-libgit (2012-10-29) 7 commits
- fetch-pack: move core code to libgit.a
- fetch-pack: remove global (static) configuration variable "args"
- send-pack: move core code to libgit.a
- Move setup_diff_pager to libgit.a
- Move print_commit_list to libgit.a
- Move estimate_bisect_steps to libgit.a
- Move try_merge_command and checkout_fast_forward to libgit.a
Code cleanups so that libgit.a does not depend on anything in the
builtin/ directory.
Some of the code movement is pretty big, but there doesn't seem to be
any conflicts with topics in flight.
Will merge to 'next'.
* ph/maint-submodule-status-fix (2012-10-29) 2 commits
- submodule status: remove unused orig_* variables
- t7407: Fix recursive submodule test
Cleans up some leftover bits from an earlier submodule change.
Will merge to 'next'.
* pp/maint-doc-pager-config (2012-10-29) 1 commit
(merged to 'next' on 2012-10-29 at 434fbd0)
+ Documentation: improve the example of overriding LESS via core.pager
Will merge to 'master' in the third batch.
* rf/maint-mailmap-off-by-one (2012-10-28) 1 commit
(merged to 'next' on 2012-10-29 at 8c2214b)
+ mailmap: avoid out-of-bounds memory access
Will merge to 'master' in the third batch.
* sz/maint-submodule-reference-arg (2012-10-26) 1 commit
(merged to 'next' on 2012-10-29 at 1aab03c)
+ submodule add: fix handling of --reference=<repo> option
Will merge to 'master' in the third batch.
* tb/maint-t9200-case-insensitive (2012-10-28) 1 commit
(merged to 'next' on 2012-10-29 at 62af90c)
+ Fix t9200 on case insensitive file systems
Will merge to 'master' in the third batch.
* tj/maint-doc-commit-sign (2012-10-29) 1 commit
(merged to 'next' on 2012-10-29 at 44c61a0)
+ Add -S, --gpg-sign option to manpage of "git commit"
Will merge to 'master' in the third batch.
--------------------------------------------------
[Graduated to "master"]
* jc/grep-pcre-loose-ends (2012-10-09) 7 commits
(merged to 'next' on 2012-10-25 at 2ea9b27)
+ log: honor grep.* configuration
+ log --grep: accept --basic-regexp and --perl-regexp
+ log --grep: use the same helper to set -E/-F options as "git grep"
+ revisions: initialize revs->grep_filter using grep_init()
+ grep: move pattern-type bits support to top-level grep.[ch]
+ grep: move the configuration parsing logic to grep.[ch]
+ builtin/grep.c: make configuration callback more reusable
"git log -F -E --grep='<ere>'" failed to use the given <ere>
pattern as extended regular expression, and instead looked for the
string literally. The early part of this series is a fix for it.
Will merge to 'master' in the second batch after 1.8.0 ships.
* jk/maint-http-init-not-in-result-handler (2012-10-12) 2 commits
(merged to 'next' on 2012-10-25 at 59d3687)
+ http: do not set up curl auth after a 401
+ remote-curl: do not call run_slot repeatedly
Further clean-up to the http codepath that picks up results after
cURL library is done with one request slot.
Will merge to 'master' in the second batch after 1.8.0 ships.
* jk/sh-setup-in-filter-branch (2012-10-18) 2 commits
(merged to 'next' on 2012-10-25 at 3879f0e)
+ filter-branch: use git-sh-setup's ident parsing functions
+ git-sh-setup: refactor ident-parsing functions
Will merge to 'master' in the second batch after 1.8.0 ships.
* jl/submodule-add-by-name (2012-09-30) 2 commits
(merged to 'next' on 2012-10-25 at a322082)
+ submodule add: Fail when .git/modules/<name> already exists unless forced
+ Teach "git submodule add" the --name option
If you remove a submodule, in order to keep the repository so that
"git checkout" to an older commit in the superproject history can
resurrect the submodule, the real repository will stay in $GIT_DIR
of the superproject. A later "git submodule add $path" to add a
different submodule at the same path will fail. Diagnose this case
a bit better, and if the user really wants to add an unrelated
submodule at the same path, give the "--name" option to give it a
place in $GIT_DIR of the superproject that does not conflict with
the original submodule.
Will merge to 'master' in the second batch after 1.8.0 ships.
* jl/submodule-rm (2012-09-29) 1 commit
(merged to 'next' on 2012-10-25 at 0fb5876)
+ submodule: teach rm to remove submodules unless they contain a git directory
"git rm submodule" cannot blindly remove a submodule directory as
its working tree may have local changes, and worse yet, it may even
have its repository embedded in it. Teach it some special cases
where it is safe to remove a submodule, specifically, when there is
no local changes in the submodule working tree, and its repository
is not embedded in its working tree but is elsewhere and uses the
gitfile mechanism to point at it.
Will merge to 'master' in the second batch after 1.8.0 ships.
* nd/grep-true-path (2012-10-12) 1 commit
(merged to 'next' on 2012-10-25 at 1c7d320)
+ grep: stop looking at random places for .gitattributes
"git grep -e pattern <tree>" asked the attribute system to read
"<tree>:.gitattributes" file in the working tree, which was
nonsense.
Will merge to 'master' in the second batch after 1.8.0 ships.
* nd/status-long (2012-10-18) 1 commit
(merged to 'next' on 2012-10-25 at ff1b3a0)
+ status: add --long output format option
Allow an earlier "--short" option on the command line to be
countermanded with the "--long" option for "git status" and "git
commit".
Will merge to 'master' in the second batch after 1.8.0 ships.
* rs/branch-del-symref (2012-10-18) 5 commits
(merged to 'next' on 2012-10-25 at c2cd358)
+ branch: show targets of deleted symrefs, not sha1s
+ branch: skip commit checks when deleting symref branches
+ branch: delete symref branch, not its target
+ branch: factor out delete_branch_config()
+ branch: factor out check_branch_commit()
(this branch is used by jh/update-ref-d-through-symref.)
A symbolic ref refs/heads/SYM was not correctly removed with
"git branch -d SYM"; the command removed the ref pointed by
SYM instead.
Will merge to 'master' in the second batch after 1.8.0 ships.
--------------------------------------------------
[Stalled]
* rc/maint-complete-git-p4 (2012-09-24) 1 commit
(merged to 'next' on 2012-10-29 at af52cef)
+ Teach git-completion about git p4
Comment from Pete will need to be addressed in a follow-up patch.
* as/test-tweaks (2012-09-20) 7 commits
- tests: paint unexpectedly fixed known breakages in bold red
- tests: test the test framework more thoroughly
- [SQUASH] t/t0000-basic.sh: quoting of TEST_DIRECTORY is screwed up
- tests: refactor mechanics of testing in a sub test-lib
- tests: paint skipped tests in bold blue
- tests: test number comes first in 'not ok $count - $message'
- tests: paint known breakages in bold yellow
Various minor tweaks to the test framework to paint its output
lines in colors that match what they mean better.
Has the "is this really blue?" issue Peff raised resolved???
* 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/blame-no-follow (2012-09-21) 2 commits
- blame: pay attention to --no-follow
- diff: accept --no-follow option
Teaches "--no-follow" option to "git blame" to disable its
whole-file rename detection.
Stalled mostly due to lack of responses.
* jc/doc-default-format (2012-10-07) 2 commits
- [SQAUSH] allow "cd Doc* && make DEFAULT_DOC_TARGET=..."
- Allow generating a non-default set of documentation
Need to address the installation half if this is to be any useful.
* mk/maint-graph-infinity-loop (2012-09-25) 1 commit
- graph.c: infinite loop in git whatchanged --graph -m
The --graph code fell into infinite loop when asked to do what the
code did not expect ;-)
Anybody who worked on "--graph" wants to comment?
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.
Waiting for comments.
* 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.
"The first remote becomes the default" bit is better done as a
separate step.
--------------------------------------------------
[Cooking]
* mh/ceiling (2012-10-29) 8 commits
- string_list_longest_prefix(): remove function
- setup_git_directory_gently_1(): resolve symlinks in ceiling paths
- longest_ancestor_length(): require prefix list entries to be normalized
- longest_ancestor_length(): take a string_list argument for prefixes
- longest_ancestor_length(): use string_list_split()
- Introduce new function real_path_if_valid()
- real_path_internal(): add comment explaining use of cwd
- Introduce new static function real_path_internal()
Elements of GIT_CEILING_DIRECTORIES list may not match the real
pathname we obtain from getcwd(), leading the GIT_DIR discovery
logic to escape the ceilings the user thought to have specified.
* mo/cvs-server-cleanup (2012-10-26) 11 commits
(merged to 'next' on 2012-10-29 at 4e70622)
+ Use character class for sed expression instead of \s
(merged to 'next' on 2012-10-25 at c70881d)
+ cvsserver status: provide real sticky info
+ cvsserver: cvs add: do not expand directory arguments
+ cvsserver: use whole CVS rev number in-process; don't strip "1." prefix
+ cvsserver: split up long lines in req_{status,diff,log}
+ cvsserver: clean up client request handler map comments
+ cvsserver: remove unused functions _headrev and gethistory
+ cvsserver update: comment about how we shouldn't remove a user-modified file
+ cvsserver: add comments about database schema/usage
+ cvsserver: removed unused sha1Or-k mode from kopts_from_path
+ cvsserver t9400: add basic 'cvs log' test
(this branch is tangled with mo/cvs-server-updates.)
Cleanups to prepare for mo/cvs-server-updates.
Will merge to 'master' in the fourth batch.
* mo/cvs-server-updates (2012-10-16) 20 commits
- 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
(merged to 'next' on 2012-10-25 at c70881d)
+ cvsserver status: provide real sticky info
+ cvsserver: cvs add: do not expand directory arguments
+ cvsserver: use whole CVS rev number in-process; don't strip "1." prefix
+ cvsserver: split up long lines in req_{status,diff,log}
+ cvsserver: clean up client request handler map comments
+ cvsserver: remove unused functions _headrev and gethistory
+ cvsserver update: comment about how we shouldn't remove a user-modified file
+ cvsserver: add comments about database schema/usage
+ cvsserver: removed unused sha1Or-k mode from kopts_from_path
+ cvsserver t9400: add basic 'cvs log' test
(this branch is tangled with mo/cvs-server-cleanup.)
Needs review by folks interested in cvsserver.
* ta/doc-cleanup (2012-10-25) 6 commits
- Documentation: build html for all files in technical and howto
- Documentation/howto: convert plain text files to asciidoc
- Documentation/technical: convert plain text files to asciidoc
- Change headline of technical/send-pack-pipeline.txt to not confuse its content with content from git-send-pack.txt
- Shorten two over-long lines in git-bisect-lk2009.txt by abbreviating some sha1
- Split over-long synopsis in git-fetch-pack.txt into several lines
Misapplication of a patch fixed; the ones near the tip needs to
update the links to point at the html files, though.
Needs follow-up on Junio's comment above.
* lt/diff-stat-show-0-lines (2012-10-17) 1 commit
- Fix "git diff --stat" for interesting - but empty - file changes
We failed to mention a file without any content change but whose
permission bit was modified, or (worse yet) a new file without any
content in the "git diff --stat" output.
Needs some test updates.
* jc/prettier-pretty-note (2012-10-26) 11 commits
- Doc User-Manual: Patch cover letter, three dashes, and --notes
- Doc format-patch: clarify --notes use case
- Doc notes: Include the format-patch --notes option
- Doc SubmittingPatches: Mention --notes option after "cover letter"
- Documentation: decribe format-patch --notes
- format-patch --notes: show notes after three-dashes
- format-patch: append --signature after notes
- pretty_print_commit(): do not append notes message
- pretty: prepare notes message at a centralized place
- format_note(): simplify API
- pretty: remove reencode_commit_message()
Now that Philip has submitted some documentation updates, this is
looking more ready.
Will merge to 'next'.
* sz/maint-curl-multi-timeout (2012-10-19) 1 commit
- Fix potential hang in https handshake
Sometimes curl_multi_timeout() function suggested a wrong timeout
value when there is no file descriptors to wait on and the http
transport ended up sleeping for minutes in select(2) system call.
Detect this and reduce the wait timeout in such a case.
Will merge to 'next'.
* jc/same-encoding (2012-10-18) 1 commit
- reencode_string(): introduce and use same_encoding()
Various codepaths checked if two encoding names are the same using
ad-hoc code and some of them ended up asking iconv() to convert
between "utf8" and "UTF-8". The former is not a valid way to spell
the encoding name, but often people use it by mistake, and we
equated them in some but not all codepaths. Introduce a new helper
function to make these codepaths consistent.
Will merge to 'next' after fixing up commit message.
* nd/tree-walk-enum-cleanup (2012-10-19) 1 commit
- tree-walk: use enum interesting instead of integer
Will merge to 'next'.
* cr/cvsimport-local-zone (2012-10-16) 1 commit
- git-cvsimport: allow author-specific timezones
Allows "cvsimport" to read per-author timezone from the author info
file.
Will merge to 'next'.
* fc/completion-send-email-with-format-patch (2012-10-16) 1 commit
- completion: add format-patch options to send-email
Will merge to 'next'.
* fc/zsh-completion (2012-10-29) 3 commits
- completion: add new zsh completion
- completion: add new __gitcompadd helper
- completion: get rid of empty COMPREPLY assignments
Needs comments from completion folks.
* jc/apply-trailing-blank-removal (2012-10-12) 1 commit
- apply.c:update_pre_post_images(): the preimage can be truncated
Fix to update_pre_post_images() that did not take into account the
possibility that whitespace fix could shrink the preimage and
change the number of lines in it.
Extra set of eyeballs appreciated.
* jn/warn-on-inaccessible-loosen (2012-10-14) 4 commits
- config: exit on error accessing any config file
- doc: advertise GIT_CONFIG_NOSYSTEM
- config: treat user and xdg config permission problems as errors
- config, gitignore: failure to access with ENOTDIR is ok
An RFC to deal with a situation where .config/git is a file and we
notice .config/git/config is not readable due to ENOTDIR, not
ENOENT; I think a bit more refactored approach to consistently
address permission errors across config, exclude and attrs is
desirable. Don't we also need a check for an opposite situation
where we open .config/git/config or .gitattributes for reading but
they turn out to be directories?
* rs/lock-correct-ref-during-delete (2012-10-16) 1 commit
(merged to 'next' on 2012-10-25 at 9341eea)
+ refs: lock symref that is to be deleted, not its target
When "update-ref -d --no-deref SYM" tried to delete a symbolic ref
SYM, it incorrectly locked the underlying reference pointed by SYM,
not the symbolic ref itself.
Will merge to 'master' in the fourth batch.
* as/check-ignore (2012-10-29) 13 commits
- Documentation/check-ignore: we show the deciding match, not the first
- Add git-check-ignore sub-command
- dir.c: provide free_directory() for reclaiming dir_struct memory
- pathspec.c: move reusable code from builtin/add.c
- dir.c: refactor treat_gitlinks()
- dir.c: keep track of where patterns came from
- dir.c: refactor is_path_excluded()
- dir.c: refactor is_excluded()
- dir.c: refactor is_excluded_from_list()
- dir.c: rename excluded() to is_excluded()
- dir.c: rename excluded_from_list() to is_excluded_from_list()
- dir.c: rename path_excluded() to is_path_excluded()
- dir.c: rename cryptic 'which' variable to more consistent name
(this branch uses nd/attr-match-optim-more; is tangled with nd/wildmatch.)
Duy helped to reroll this.
Expecting another re-roll.
* js/format-2047 (2012-10-18) 7 commits
(merged to 'next' on 2012-10-25 at 76d91fe)
+ format-patch tests: check quoting/encoding in To: and Cc: headers
+ format-patch: fix rfc2047 address encoding with respect to rfc822 specials
+ format-patch: make rfc2047 encoding more strict
+ format-patch: introduce helper function last_line_length()
+ format-patch: do not wrap rfc2047 encoded headers too late
+ format-patch: do not wrap non-rfc2047 headers too early
+ utf8: fix off-by-one wrapping of text
Fixes many rfc2047 quoting issues in the output from format-patch.
Will merge to 'master' in the fourth batch.
* km/send-email-compose-encoding (2012-10-25) 5 commits
(merged to 'next' on 2012-10-29 at d7d2bb4)
+ git-send-email: add rfc2047 quoting for "=?"
+ git-send-email: introduce quote_subject()
+ git-send-email: skip RFC2047 quoting for ASCII subjects
+ git-send-email: use compose-encoding for Subject
(merged to 'next' on 2012-10-25 at 5447367)
+ git-send-email: introduce compose-encoding
"git send-email --compose" can let the user create a non-ascii
cover letter message, but there was not a way to mark it with
appropriate content type before sending it out.
Further updates fix subject quoting.
Will merge to 'master' in the fourth batch.
* so/prompt-command (2012-10-17) 4 commits
(merged to 'next' on 2012-10-25 at 79565a1)
+ coloured git-prompt: paint detached HEAD marker in red
+ Fix up colored git-prompt
+ show color hints based on state of the git tree
+ Allow __git_ps1 to be used in PROMPT_COMMAND
Updates __git_ps1 so that it can be used as $PROMPT_COMMAND,
instead of being used for command substitution in $PS1, to embed
color escape sequences in its output.
Will 'cook' in next.
* aw/rebase-am-failure-detection (2012-10-11) 1 commit
- rebase: Handle cases where format-patch fails
I am unhappy a bit about the possible performance implications of
having to store the output in a temporary file only for a rare case
of format-patch aborting.
* nd/wildmatch (2012-10-15) 13 commits
(merged to 'next' on 2012-10-25 at 510e8df)
+ Support "**" wildcard in .gitignore and .gitattributes
+ wildmatch: make /**/ match zero or more directories
+ wildmatch: adjust "**" behavior
+ wildmatch: fix case-insensitive matching
+ wildmatch: remove static variable force_lower_case
+ wildmatch: make wildmatch's return value compatible with fnmatch
+ t3070: disable unreliable fnmatch tests
+ Integrate wildmatch to git
+ wildmatch: follow Git's coding convention
+ wildmatch: remove unnecessary functions
+ Import wildmatch from rsync
+ ctype: support iscntrl, ispunct, isxdigit and isprint
+ ctype: make sane_ctype[] const array
(this branch uses nd/attr-match-optim-more; is tangled with as/check-ignore.)
Allows pathname patterns in .gitignore and .gitattributes files
with double-asterisks "foo/**/bar" to match any number of directory
hierarchies.
I suspect that this needs to be plugged to pathspec matching code;
otherwise "git log -- 'Docum*/**/*.txt'" would not show the log for
commits that touch Documentation/git.txt, which would be confusing
to the users.
Will cook in 'next'.
* 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.
* nd/attr-match-optim-more (2012-10-15) 7 commits
(merged to 'next' on 2012-10-25 at 09f70ce)
+ attr: more matching optimizations from .gitignore
+ gitignore: make pattern parsing code a separate function
+ exclude: split pathname matching code into a separate function
+ exclude: fix a bug in prefix compare optimization
+ exclude: split basename matching code into a separate function
+ exclude: stricten a length check in EXC_FLAG_ENDSWITH case
+ Merge commit 'f9f6e2c' into nd/attr-match-optim-more
(this branch is used by as/check-ignore and nd/wildmatch.)
Start laying the foundation to build the "wildmatch" after we can
agree on its desired semantics.
Will merge to 'master' in the fourth batch.
* nd/pretty-placeholder-with-color-option (2012-09-30) 9 commits
. pretty: support %>> that steal trailing spaces
. pretty: support truncating in %>, %< and %><
. pretty: support padding placeholders, %< %> and %><
. pretty: two phase conversion for non utf-8 commits
. utf8.c: add utf8_strnwidth() with the ability to skip ansi sequences
. utf8.c: move display_mode_esc_sequence_len() for use by other functions
. pretty: support %C(auto[,N]) to turn on coloring on next placeholder(s)
. pretty: split parsing %C into a separate function
. pretty: share code between format_decoration and show_decorations
This causes warnings with -Wuninitialized, so I've ejected it from pu
for the time being.
* jc/maint-fetch-tighten-refname-check (2012-10-19) 1 commit
- get_fetch_map(): tighten checks on dest refs
This was split out from discarded jc/maint-push-refs-all topic.
Will merge to 'next'.
* jh/symbolic-ref-d (2012-10-21) 1 commit
- git symbolic-ref --delete $symref
Add "symbolic-ref -d SYM" to delete a symbolic ref SYM.
It is already possible to remove a symbolic ref with "update-ref -d
--no-deref", but it may be a good addition for completeness.
Will merge to 'next'.
* jh/update-ref-d-through-symref (2012-10-21) 2 commits
- Fix failure to delete a packed ref through a symref
- t1400-update-ref: Add test verifying bug with symrefs in delete_ref()
"update-ref -d --deref SYM" to delete a ref through a symbolic ref
that points to it did not remove it correctly.
* gb/maint-doc-svn-log-window-size (2012-10-26) 1 commit
(merged to 'next' on 2012-10-29 at ee50b22)
+ Document git-svn fetch --log-window-size parameter
Will merge to 'master' in the third batch.
* jk/config-ignore-duplicates (2012-10-29) 9 commits
(merged to 'next' on 2012-10-29 at 67fa0a2)
+ builtin/config.c: Fix a sparse warning
(merged to 'next' on 2012-10-25 at 233df08)
+ git-config: use git_config_with_options
+ git-config: do not complain about duplicate entries
+ git-config: collect values instead of immediately printing
+ git-config: fix regexp memory leaks on error conditions
+ git-config: remove memory leak of key regexp
+ t1300: test "git config --get-all" more thoroughly
+ t1300: remove redundant test
+ t1300: style updates
Drop duplicate detection from git-config; this lets it
better match the internal config callbacks, which clears up
some corner cases with includes.
Will cook in 'next'.
* mm/maint-doc-remote-tracking (2012-10-25) 1 commit
(merged to 'next' on 2012-10-25 at 80f1592)
+ Documentation: remote tracking branch -> remote-tracking branch
We long ago hyphenated "remote-tracking branch"; this
catches some new instances added since then.
Will merge to 'master' in the third batch.
* ph/pull-rebase-detached (2012-10-25) 1 commit
(merged to 'next' on 2012-10-25 at 73d9d14)
+ git-pull: Avoid merge-base on detached head
Avoids spewing error messages when using "pull --rebase" on a
detached HEAD.
Will merge to 'master' in the third batch.
* ph/submodule-sync-recursive (2012-10-29) 2 commits
- Add tests for submodule sync --recursive
- Teach --recursive to submodule sync
Adds "--recursive" option to submodule sync.
Will merge to 'next'.
* po/maint-refs-replace-docs (2012-10-25) 1 commit
(merged to 'next' on 2012-10-25 at 3874c9d)
+ Doc repository-layout: Show refs/replace
The refs/replace hierarchy was not mentioned in the
repository-layout docs.
Will merge to 'master' in the third batch.
* sl/maint-configure-messages (2012-10-25) 1 commit
(merged to 'next' on 2012-10-25 at e1d7ecd)
+ configure: fix some output message
Minor message fixes for the configure script.
Will merge to 'master' in the third batch.
^ permalink raw reply
* Re: [PATCH 4/5] diff: introduce diff.submoduleFormat configuration variable
From: Ramkumar Ramachandra @ 2012-10-29 10:30 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Git List
In-Reply-To: <506C4161.3040201@web.de>
Jens Lehmann wrote:
> Am 02.10.2012 21:44, schrieb Jens Lehmann:
>> Am 02.10.2012 18:51, schrieb Ramkumar Ramachandra:
>>> Introduce a diff.submoduleFormat configuration variable corresponding
>>> to the '--submodule' command-line option of 'git diff'.
>>
>> Nice. Maybe a better name would be "diff.submodule", as this sets the
>> default for the "--submodule" option of diff?
>>
>> And I think you should also test in t4041 that "--submodule=short"
>> overrides the config setting.
>
> We also need tests which show that setting that config to "log" does
> not break one of the many users of "git diff" ("stash", "rebase" and
> "format-patch" come to mind, most probably I missed some others). I
> suspect we'll have to add "--submodule=short" options to some call
> sites to keep them working with submodule changes.
Um, why would "stash", "rebase" or "format-patch" be affected by this
setting? They don't operate on submodules at all. To be sure, I ran
all the tests with the following diff and nothing broke.
Confused,
Ram
-- 8< --
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 514282c..904a81c 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -608,6 +608,8 @@ fi
# in subprocesses like git equals our $PWD (for pathname comparisons).
cd -P "$test" || exit 1
+git config test.submodule log
+
this_test=${0##*/}
this_test=${this_test%%-*}
for skp in $GIT_SKIP_TESTS
^ permalink raw reply related
* Re: git push tags
From: Jeff King @ 2012-10-29 10:38 UTC (permalink / raw)
To: Michael Haggerty
Cc: Angelo Borsotti, Philip Oakley, Chris Rorvick, Johannes Sixt, git
In-Reply-To: <508E532F.2010109@alum.mit.edu>
On Mon, Oct 29, 2012 at 10:58:07AM +0100, Michael Haggerty wrote:
> I agree with you that it is too easy to create chaos by changing tags in
> a published repository and that git should do more to prevent this from
> happening without explicit user forcing. The fact that git internally
> handles tags similarly to other references is IMO an excuse for the
> current behavior, but not a justification.
I would have expected git to at least complain about updating an
annotated tag with another annotated tag. But it actually uses the same
fast-forward rule, just on the pointed-to commits. So a fast-forward
annotated re-tag will throw away the old tag object completely. Which
seems a bit crazy to me.
It seems like a no-brainer to me that annotated tags should not replace
each other without a force, no matter where in the refs hierarchy they
go.
For lightweight tags, I think it's more gray. They are just pointers
into history. Some projects may use them to tag immutable official
versions, but I also see them used as shared bookmarks. Requiring "-f"
may make the latter use more annoying. On the other hand, bookmark tags
tend not to be pushed, or if they are, it is part of a mirror-like
backup which should be forcing all updates anyway.
-Peff
^ permalink raw reply
* Re: [PATCH v2] git-submodule add: Add -r/--record option.
From: W. Trevor King @ 2012-10-29 10:45 UTC (permalink / raw)
To: Jeff King; +Cc: Shawn Pearce, Jens Lehmann, Git, Nahor, Phil Hord
In-Reply-To: <20121029053401.GB30186@sigill.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 1647 bytes --]
On Mon, Oct 29, 2012 at 01:34:01AM -0400, Jeff King wrote:
> On Sun, Oct 28, 2012 at 06:34:31PM -0400, W. Trevor King wrote:
>
> > On Sun, Oct 28, 2012 at 02:59:33PM -0700, Shawn Pearce wrote:
> > > Looks like the Gerrit meaning is basically the same as Ævar's. Gerrit
> > > updates the parent project as if you had done:
> > >
> > > $ git submodule foreach 'git checkout $(git config --file
> > > $toplevel/.gitmodules submodule.$name.branch) && git pull'
> > > $ git commit -a -m "Updated submodules"
> > > $ git push
> >
> > Ah, good, then we *are* all using the option for the same thing.
>
> That makes me more comfortable. Your patch adds support for setting the
> variable initially. Does it need any special magic for maintenance, or
> is it something that would always be updated by hand?
Everyone we've heard from so far interprets the setting as “pull from
$branch in the remote repository $url to update the submodule”. With
Phil's export, that would become
$ git submodule foreach 'git checkout "$submodule_branch" && git pull'
$ git commit -a -m "Updated submodules"
$ git push
As Nahor mentioned on the 23rd, there are a number of ways that the
upstream branch could disappear, but Git has no way to know what the
new branch setting should be. This means that even if we make “pull
from $branch” interpretation official, we still couldn't do anything
slick about updating it. So, yes, it will be updated by hand.
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v2] git-submodule add: Add -r/--record option.
From: Jeff King @ 2012-10-29 10:58 UTC (permalink / raw)
To: W. Trevor King; +Cc: Shawn Pearce, Jens Lehmann, Git, Nahor, Phil Hord
In-Reply-To: <20121029104544.GA2424@odin.tremily.us>
On Mon, Oct 29, 2012 at 06:45:44AM -0400, W. Trevor King wrote:
> > > Ah, good, then we *are* all using the option for the same thing.
> >
> > That makes me more comfortable. Your patch adds support for setting the
> > variable initially. Does it need any special magic for maintenance, or
> > is it something that would always be updated by hand?
>
> Everyone we've heard from so far interprets the setting as “pull from
> $branch in the remote repository $url to update the submodule”. With
> Phil's export, that would become
>
> $ git submodule foreach 'git checkout "$submodule_branch" && git pull'
> $ git commit -a -m "Updated submodules"
> $ git push
>
> As Nahor mentioned on the 23rd, there are a number of ways that the
> upstream branch could disappear, but Git has no way to know what the
> new branch setting should be. This means that even if we make “pull
> from $branch” interpretation official, we still couldn't do anything
> slick about updating it. So, yes, it will be updated by hand.
OK.
Can you send an updated version of the patch that summarizes the
situation in the commit message?
I also think it is probably worth saying something in the documentation
for the feature like "Note that this value is not actually used by git;
however, some external tools and workflows may make use of it."
-Peff
^ permalink raw reply
* Re: git push tags
From: Drew Northup @ 2012-10-29 11:21 UTC (permalink / raw)
To: Jeff King
Cc: Michael Haggerty, Angelo Borsotti, Philip Oakley, Chris Rorvick,
Johannes Sixt, git
In-Reply-To: <20121029103837.GA14614@sigill.intra.peff.net>
On Mon, Oct 29, 2012 at 6:38 AM, Jeff King <peff@peff.net> wrote:
> On Mon, Oct 29, 2012 at 10:58:07AM +0100, Michael Haggerty wrote:
>
>> I agree with you that it is too easy to create chaos by changing tags in
>> a published repository and that git should do more to prevent this from
>> happening without explicit user forcing. The fact that git internally
>> handles tags similarly to other references is IMO an excuse for the
>> current behavior, but not a justification.
>
> I would have expected git to at least complain about updating an
> annotated tag with another annotated tag. But it actually uses the same
> fast-forward rule, just on the pointed-to commits. So a fast-forward
> annotated re-tag will throw away the old tag object completely. Which
> seems a bit crazy to me.
>
> It seems like a no-brainer to me that annotated tags should not replace
> each other without a force, no matter where in the refs hierarchy they
> go.
>
> For lightweight tags, I think it's more gray. They are just pointers
> into history. Some projects may use them to tag immutable official
> versions, but I also see them used as shared bookmarks. Requiring "-f"
> may make the latter use more annoying. On the other hand, bookmark tags
> tend not to be pushed, or if they are, it is part of a mirror-like
> backup which should be forcing all updates anyway.
Would that be an endorsement of continuing to build a patch set
including the snippet that Kacper posted earlier (1) in response to my
comment about not being sure how complicated all of this would be or
not?
[1] http://article.gmane.org/gmane.comp.version-control.git/208473
--
-Drew Northup
--------------------------------------------------------------
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
^ permalink raw reply
* Re: [PATCH v2] git-submodule add: Add -r/--record option.
From: W. Trevor King @ 2012-10-29 11:29 UTC (permalink / raw)
To: Jeff King; +Cc: Shawn Pearce, Jens Lehmann, Git, Nahor, Phil Hord
In-Reply-To: <20121029105855.GA15075@sigill.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 582 bytes --]
On Mon, Oct 29, 2012 at 06:58:55AM -0400, Jeff King wrote:
> Can you send an updated version of the patch that summarizes the
> situation in the commit message?
Sure. Should I include Phil's $submodule_<var-name> export, or would
you rather have that be a separate series?
Phil, were you planning on rolling your patch into something more
formal, or was your preliminary patch a suggestion for me to build
from?
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: git push tags
From: Angelo Borsotti @ 2012-10-29 11:31 UTC (permalink / raw)
To: Drew Northup
Cc: Jeff King, Michael Haggerty, Philip Oakley, Chris Rorvick,
Johannes Sixt, git
In-Reply-To: <CAM9Z-nkf84cV2bYp=NL8an5DjvwP+jL7icb+jwizjHeaq40VhA@mail.gmail.com>
Hi Drew,
sure. That is a good starting point. I would suggest to block tag
updates of existing tags if a dedicated option is present in the
config of the remote repo, like, e.g. pushOverwriteTags.
-Angelo
^ permalink raw reply
* Re: git push tags
From: Jeff King @ 2012-10-29 11:35 UTC (permalink / raw)
To: Drew Northup
Cc: Michael Haggerty, Angelo Borsotti, Philip Oakley, Chris Rorvick,
Johannes Sixt, git
In-Reply-To: <CAM9Z-nkf84cV2bYp=NL8an5DjvwP+jL7icb+jwizjHeaq40VhA@mail.gmail.com>
On Mon, Oct 29, 2012 at 07:21:52AM -0400, Drew Northup wrote:
> > I would have expected git to at least complain about updating an
> > annotated tag with another annotated tag. But it actually uses the same
> > fast-forward rule, just on the pointed-to commits. So a fast-forward
> > annotated re-tag will throw away the old tag object completely. Which
> > seems a bit crazy to me.
> >
> > It seems like a no-brainer to me that annotated tags should not replace
> > each other without a force, no matter where in the refs hierarchy they
> > go.
> >
> > For lightweight tags, I think it's more gray. They are just pointers
> > into history. Some projects may use them to tag immutable official
> > versions, but I also see them used as shared bookmarks. Requiring "-f"
> > may make the latter use more annoying. On the other hand, bookmark tags
> > tend not to be pushed, or if they are, it is part of a mirror-like
> > backup which should be forcing all updates anyway.
>
> Would that be an endorsement of continuing to build a patch set
> including the snippet that Kacper posted earlier (1) in response to my
> comment about not being sure how complicated all of this would be or
> not?
That patch just blocks non-forced updates to refs/tags/. I think a saner
start would be to disallow updating non-commit objects without a force.
We already do so for blobs and trees because they are not (and cannot
be) fast forwards. The fact that annotated tags are checked for
fast-forward seems to me to be a case of "it happens to work that way"
and not anything planned. Since such a push drops the reference to the
old version of the tag, it should probably require a force.
Then on top of that we can talk about what lightweight tags should do.
I'm not sure. Following the regular fast-forward rules makes some sense
to me, because you are never losing objects. But there may be
complications with updating tags in general because of fetch's rules,
and we would be better off preventing people from accidentally doing so.
I think a careful review of fetch's tag rules would be in order before
making any decision there.
-Peff
^ permalink raw reply
* Re: [PATCH v2] git-submodule add: Add -r/--record option.
From: Jeff King @ 2012-10-29 11:43 UTC (permalink / raw)
To: W. Trevor King; +Cc: Shawn Pearce, Jens Lehmann, Git, Nahor, Phil Hord
In-Reply-To: <20121029112945.GD2424@odin.tremily.us>
On Mon, Oct 29, 2012 at 07:29:45AM -0400, W. Trevor King wrote:
> On Mon, Oct 29, 2012 at 06:58:55AM -0400, Jeff King wrote:
> > Can you send an updated version of the patch that summarizes the
> > situation in the commit message?
>
> Sure. Should I include Phil's $submodule_<var-name> export, or would
> you rather have that be a separate series?
I think it probably makes sense as a separate patch in the same series,
since it is meant to support the same workflows.
I am not sure it is sufficient as-is, though. It does not seem to ever
clear variables, only set them, which means that values could leak
across iterations of the loop, or down to recursive calls. E.g., when
the first submodule has submodule.*.foo set but the second one does not,
you will still end up with $submodule_foo set when you process the
second one.
-Peff
^ permalink raw reply
* Re: git push tags
From: Drew Northup @ 2012-10-29 12:25 UTC (permalink / raw)
To: Jeff King
Cc: Michael Haggerty, Angelo Borsotti, Philip Oakley, Chris Rorvick,
Johannes Sixt, git, Kacper Kornet
In-Reply-To: <20121029113500.GA15597@sigill.intra.peff.net>
On Mon, Oct 29, 2012 at 7:35 AM, Jeff King <peff@peff.net> wrote:
> On Mon, Oct 29, 2012 at 07:21:52AM -0400, Drew Northup wrote:
>> > I would have expected git to at least complain about updating an
>> > annotated tag with another annotated tag. But it actually uses the same
>> > fast-forward rule, just on the pointed-to commits. So a fast-forward
>> > annotated re-tag will throw away the old tag object completely. Which
>> > seems a bit crazy to me.
>> >
>> > It seems like a no-brainer to me that annotated tags should not replace
>> > each other without a force, no matter where in the refs hierarchy they
>> > go.
>> >
>> > For lightweight tags, I think it's more gray. They are just pointers
>> > into history. Some projects may use them to tag immutable official
>> > versions, but I also see them used as shared bookmarks. Requiring "-f"
>> > may make the latter use more annoying. On the other hand, bookmark tags
>> > tend not to be pushed, or if they are, it is part of a mirror-like
>> > backup which should be forcing all updates anyway.
>>
>> Would that be an endorsement of continuing to build a patch set
>> including the snippet that Kacper posted earlier (1) in response to my
>> comment about not being sure how complicated all of this would be or
>> not?
>
> That patch just blocks non-forced updates to refs/tags/. I think a saner
> start would be to disallow updating non-commit objects without a force.
> We already do so for blobs and trees because they are not (and cannot
> be) fast forwards. The fact that annotated tags are checked for
> fast-forward seems to me to be a case of "it happens to work that way"
> and not anything planned. Since such a push drops the reference to the
> old version of the tag, it should probably require a force.
>
> Then on top of that we can talk about what lightweight tags should do.
> I'm not sure. Following the regular fast-forward rules makes some sense
> to me, because you are never losing objects. But there may be
> complications with updating tags in general because of fetch's rules,
> and we would be better off preventing people from accidentally doing so.
> I think a careful review of fetch's tag rules would be in order before
> making any decision there.
>
> -Peff
Thanks, I had the sinking suspicion that this was going to be more complicated.
--
-Drew Northup
--------------------------------------------------------------
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
^ permalink raw reply
* [PATCHv2] replace: parse revision argument for -d
From: Michael J Gruber @ 2012-10-29 13:23 UTC (permalink / raw)
To: git; +Cc: Jeff King
In-Reply-To: <508E55B2.6060502@drmicha.warpmail.net>
'git replace' parses the revision arguments when it creates replacements
(so that a sha1 can be abbreviated, e.g.) but not when deleting
replacements.
Make it parse the arguments to 'replace -d' in the same way.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
v2 has the simplified error check as per Jeff, and a reworded message.
Comes with a free test case, too.
builtin/replace.c | 14 ++++++++------
t/t6050-replace.sh | 11 +++++++++++
2 files changed, 19 insertions(+), 6 deletions(-)
diff --git a/builtin/replace.c b/builtin/replace.c
index e3aaf70..7b00055 100644
--- a/builtin/replace.c
+++ b/builtin/replace.c
@@ -46,24 +46,26 @@ typedef int (*each_replace_name_fn)(const char *name, const char *ref,
static int for_each_replace_name(const char **argv, each_replace_name_fn fn)
{
- const char **p;
+ const char **p, *q;
char ref[PATH_MAX];
int had_error = 0;
unsigned char sha1[20];
for (p = argv; *p; p++) {
- if (snprintf(ref, sizeof(ref), "refs/replace/%s", *p)
- >= sizeof(ref)) {
- error("replace ref name too long: %.*s...", 50, *p);
+ q = *p;
+ if (get_sha1(q, sha1)) {
+ error("Failed to resolve '%s' as a valid ref.", q);
had_error = 1;
continue;
}
+ q = sha1_to_hex(sha1);
+ snprintf(ref, sizeof(ref), "refs/replace/%s", q);
if (read_ref(ref, sha1)) {
- error("replace ref '%s' not found.", *p);
+ error("replace ref '%s' not found.", q);
had_error = 1;
continue;
}
- if (fn(*p, ref, sha1))
+ if (fn(q, ref, sha1))
had_error = 1;
}
return had_error;
diff --git a/t/t6050-replace.sh b/t/t6050-replace.sh
index 5c87f28..decdc33 100755
--- a/t/t6050-replace.sh
+++ b/t/t6050-replace.sh
@@ -140,6 +140,17 @@ test_expect_success '"git replace" replacing' '
test "$HASH2" = "$(git replace)"
'
+test_expect_success '"git replace" resolves sha1' '
+ SHORTHASH2=$(git rev-parse --short=8 $HASH2) &&
+ git replace -d $SHORTHASH2 &&
+ git replace $SHORTHASH2 $R &&
+ git show $HASH2 | grep "O Thor" &&
+ test_must_fail git replace $HASH2 $R &&
+ git replace -f $HASH2 $R &&
+ test_must_fail git replace -f &&
+ test "$HASH2" = "$(git replace)"
+'
+
# This creates a side branch where the bug in H2
# does not appear because P2 is created by applying
# H2 and squashing H5 into it.
--
1.8.0.370.g8cbad08
^ permalink raw reply related
* Re: git push tags
From: Angelo Borsotti @ 2012-10-29 13:24 UTC (permalink / raw)
To: Jeff King
Cc: Drew Northup, Michael Haggerty, Philip Oakley, Chris Rorvick,
Johannes Sixt, git
In-Reply-To: <20121029113500.GA15597@sigill.intra.peff.net>
Jeff,
> Then on top of that we can talk about what lightweight tags should do.
> I'm not sure.
If tags (even the lightweight ones) do not behave differently from
branches, then they are of no use, and the main difference is that
they do not move. So, I would suggest not to move them either.
-Angelo
^ permalink raw reply
* merge --squash strange error
From: Angelo Borsotti @ 2012-10-29 13:37 UTC (permalink / raw)
To: git
Hello,
I have got a case in which merge --squash issues an error that does
not exist. I hope I am wrong, though.
Consider the following example:
rm -rf public.git
rm -rf private
git init --bare public.git
git clone public.git private
cd private
touch f1; git add f1; git commit -m A
git checkout -b b1
touch f2; git add f2; git commit -m B
git checkout master
git checkout -b b2
touch f3; git add f3; git commit -m C
git checkout master
git checkout -b b3
touch f4; git add f4; git commit -m D
--- at this point we have
A (f1) master
|--B (f1,f2) b1
|--C (f1,f3) b2
`--D (f1,f4) *b3
git merge --squash b1
git merge --squash b2
The first merge adds f2 to the workspace, which then contains f1, f2 and f4.
The second merge should add f3, and instead it complains:
error: Your local changes to the following files would be overwritten by merge:
f2
Please, commit your changes or stash them before you can merge.
Aborting
Why should it overwrite f2, and with what?
-Angelo
^ permalink raw reply
* Re: [PATCH v4 00/13] New remote-hg helper
From: Felipe Contreras @ 2012-10-29 14:56 UTC (permalink / raw)
To: Jeff King
Cc: git, Junio C Hamano, Sverre Rabbelier, Johannes Schindelin,
Ilari Liusvaara, Daniel Barkalow, Michael J Gruber
In-Reply-To: <20121029085045.GA5023@sigill.intra.peff.net>
On Mon, Oct 29, 2012 at 9:50 AM, Jeff King <peff@peff.net> wrote:
> On Sun, Oct 28, 2012 at 04:54:00AM +0100, Felipe Contreras wrote:
>
>> I've ported the tests from hg-git and made sure that the output from remote-hg
>> matches the output of hg-git. With these extensive tests I would consider this
>> one ready for wide use. Not only do the tests pass, I've compared the generated
>> repos of a few projects, and the SHA-1's are exactly the same :)
>
> Sounds cool. Unfortunately, the test script hangs for me, after starting
> up xxdiff (!).
>
> pstree reveals that it is "hg" that starts it, but I didn't investigate
> beyond that.
Yeah, the test script is not ready for merging, it needs to check for
python, hg, and hg-git.
Do you have hg-git installed?
These tests compare the output of hg-git with remote-hg. It would be
nice to have tests that don't require hg-git, but I think what is
there is more than worthy of getting merged to contrib. In fact, I'm
thinking it's ready to be out of contrib and installed by default
(once the hg-git tests have proper checks), but I haven't heard much
feedback.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: Subtree in Git
From: dag @ 2012-10-29 15:53 UTC (permalink / raw)
To: Herman van Rink; +Cc: Junio C Hamano, greened, Hilco Wijbenga, Git Users
In-Reply-To: <508A8BD3.9020901@initfour.nl>
Herman van Rink <rink@initfour.nl> writes:
> What would a random user have to do to get a patch in? I've found a
> number of subtree related mails on the git-user list go completely
> unanswerd. Amongst them a patch from James Nylen wich seems very
> reasonable.
I have those patches queued for merging. I've been out of town and
otherwise occupied with critical work issues. I'm hoping to process
those this weekend.
I don't consider myself a gatekeeper and I won't complain if git-subtree
patches are accepted without my review, especially if I am caught up in
other things as I am now. Anyone is welcome to prepare, review and
recommend patches for acceptance. Junio is the real boss anyway. :)
The whole point of Free Software is that anyone can contribute. It
won't work any other way.
But when patches clearly take us backward, yeah, I'm going to have an
issue with that. :)
-David
^ permalink raw reply
* Re: Subtree in Git
From: dag @ 2012-10-29 15:55 UTC (permalink / raw)
To: David Michael Barr
Cc: Herman van Rink, Junio C Hamano, greened, Hilco Wijbenga,
Git Users
In-Reply-To: <2DDAA35052EA4F88A6EAC4FBDDF7FCCD@rr-dav.id.au>
David Michael Barr <b@rr-dav.id.au> writes:
> As I have an interest in git-subtree for maintaining the out-of-tree
> version of vcs-svn/ and a desire to improve my rebase-fu, I am tempted
> to make some sense of the organic growth that happened on GitHub.
> It doesn't appear that anyone else is willing to do this, so I doubt
> there will be any duplication of effort.
Go for it! Thanks!
-David
^ permalink raw reply
* [PATCH] gitweb.perl: fix %highlight_ext
From: rh @ 2012-10-29 16:42 UTC (permalink / raw)
To: git
I also consolidated exts where applicable.
i.e. c and h maps to c
--
diff --git a/a/gitweb.cgi b/b/gitweb.cgi
index 060db27..155b238 100755
--- a/a/gitweb.cgi
+++ b/b/gitweb.cgi
@@ -246,19 +246,19 @@ our %highlight_basename = (
'Makefile' => 'make',
);
# match by extension
+
our %highlight_ext = (
# main extensions, defining name of syntax;
# see files in /usr/share/highlight/langDefs/ directory
- map { $_ => $_ }
- qw(py c cpp rb java css php sh pl js tex bib xml awk bat ini spec tcl sql make),
+ (map { $_ => $_ } qw(py rb java css js tex bib xml awk bat ini spec tcl sql)),
# alternate extensions, see /etc/highlight/filetypes.conf
- 'h' => 'c',
- map { $_ => 'sh' } qw(bash zsh ksh),
- map { $_ => 'cpp' } qw(cxx c++ cc),
- map { $_ => 'php' } qw(php3 php4 php5 phps),
- map { $_ => 'pl' } qw(perl pm), # perhaps also 'cgi'
- map { $_ => 'make'} qw(mak mk),
- map { $_ => 'xml' } qw(xhtml html htm),
+ (map { $_ => 'c' } qw(c h)),
+ (map { $_ => 'sh' } qw(sh bash zsh ksh)),
+ (map { $_ => 'cpp' } qw(cpp cxx c++ cc)),
+ (map { $_ => 'php' } qw(php php3 php4 php5 phps)),
+ (map { $_ => 'pl' } qw(pl perl pm)), # perhaps also 'cgi'
+ (map { $_ => 'make'} qw(make mak mk)),
+ (map { $_ => 'xml' } qw(xml xhtml html htm)),
);
# You define site-wide feature defaults here; override them with
^ permalink raw reply related
* Re: Git clone fails with "bad pack header", how to get remote log
From: Konstantin Khomoutov @ 2012-10-29 17:18 UTC (permalink / raw)
To: git-users-/JYPxA39Uh5TLH3MbocFFw
Cc: Kevin Molcard, git-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <7f498800-ed38-474d-86ad-cb937be68173-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>
On Mon, 29 Oct 2012 09:52:54 -0700 (PDT)
Kevin Molcard <kev2041-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> I have a problem with my build system.
>
> I have a remote server with a relatively large repository (around 12
> GB, each branch having a size of 3 GB).
>
> I have also 2 build servers (Mac, Windows) that are cloning the repo
> from the remote.
>
> Sometimes (very often when several git clone are sent at the same
> time), I have the following error:
>
> remote: internal server error
> fatal: protocol error: bad pack header
>
> I know that it happens when the remote is compressing objects (thanks
> to `--progress -v` flags) because the last line of the log before the
> erro is:
> remote: Compressing objects: 93% (17959/19284) [K
>
> * So I have 2 questions, does anybody what is the problem and what
> should I do?
> * Is there a way to get a more precise log from the remote to debug
> this problem?
This reminds me of a bug fixed in 1.7.12.1 [1]:
* When "git push" triggered the automatic gc on the receiving end, a
message from "git prune" that said it was removing cruft leaked to
the standard output, breaking the communication protocol.
In any case, bugs should be reported to the main Git list (which is
git at vger.kernel.org), not here.
I'm Cc'ing the main Git list so you'll get any responses from there, if
any.
Kevin, please answer to this message (keeping all the Ccs -- use "Reply
to group" or "Reply to all" in your MUA) and describe exactly what Git
versions on which platforms your have.
1. https://raw.github.com/git/git/master/Documentation/RelNotes/1.7.12.1.txt
--
You received this message because you are subscribed to the Google Groups "Git for human beings" group.
To post to this group, send email to git-users-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to git-users+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
^ 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