* Re: [PATCH] fix 'make test' for HP NonStop
From: Jeff King @ 2012-10-25 10:49 UTC (permalink / raw)
To: Joachim Schmitz; +Cc: git
In-Reply-To: <002e01cdb29a$893593f0$9ba0bbd0$@schmitz-digital.de>
On Thu, Oct 25, 2012 at 12:21:44PM +0200, Joachim Schmitz wrote:
> > > + # for 'make test'
> > > + # some test don't work with /bin/diff, some fail with /bin/tar
> > > + # some need bash, and some need ${prefix}/bin in PATH first
> > > + SHELL_PATH=${prefix}/bin/bash
> > > + SANE_TOOL_PATH=${prefix}/bin
> >
> > This feels a little too specific to go in our Makefile. Do we have any
> > reason to think that where you are installing git is going to be the
> > same place you have bash and other sane tools? Wouldn't this mean that
> > things work when you run "make" but mysteriously break when you run
> > "make prefix=/my/local/install/of/git"?
>
> Well, "make" won't break (I think), but "make test" very well might.
Sure.
> Well, so far all OpenSource packages ported to HP NonStop (at least
> the ones on ituglib.connect-community.org) use prefix=/usr/local and
> there is no intention to change that.
But then I would think using /usr/local would be the sane thing to put
there, if that is the closest to "standard" for your platform.
If there is not a standard, then I think we are better off leaving it
blank and letting people do the right thing for their system (including
packagers who are building for other people).
-Peff
^ permalink raw reply
* RE: [PATCH] fix 'make test' for HP NonStop
From: Joachim Schmitz @ 2012-10-25 10:51 UTC (permalink / raw)
To: 'Jeff King'; +Cc: git
In-Reply-To: <20121025104900.GA6363@sigill.intra.peff.net>
> From: Jeff King [mailto:peff@peff.net]
> Sent: Thursday, October 25, 2012 12:49 PM
> To: Joachim Schmitz
> Cc: git@vger.kernel.org
> Subject: Re: [PATCH] fix 'make test' for HP NonStop
>
> On Thu, Oct 25, 2012 at 12:21:44PM +0200, Joachim Schmitz wrote:
>
> > > > + # for 'make test'
> > > > + # some test don't work with /bin/diff, some fail with /bin/tar
> > > > + # some need bash, and some need ${prefix}/bin in PATH first
> > > > + SHELL_PATH=${prefix}/bin/bash
> > > > + SANE_TOOL_PATH=${prefix}/bin
> > >
> > > This feels a little too specific to go in our Makefile. Do we have any
> > > reason to think that where you are installing git is going to be the
> > > same place you have bash and other sane tools? Wouldn't this mean that
> > > things work when you run "make" but mysteriously break when you run
> > > "make prefix=/my/local/install/of/git"?
> >
> > Well, "make" won't break (I think), but "make test" very well might.
>
> Sure.
>
> > Well, so far all OpenSource packages ported to HP NonStop (at least
> > the ones on ituglib.connect-community.org) use prefix=/usr/local and
> > there is no intention to change that.
>
> But then I would think using /usr/local would be the sane thing to put
> there, if that is the closest to "standard" for your platform.
OK, yes, hardcoding /usr/local seems OK too.
Would I need to re-roll?
Bye, Jojo
^ permalink raw reply
* Re: [PATCH] fix 'make test' for HP NonStop
From: Jeff King @ 2012-10-25 10:52 UTC (permalink / raw)
To: Joachim Schmitz; +Cc: git
In-Reply-To: <002f01cdb29e$c2db47e0$4891d7a0$@schmitz-digital.de>
On Thu, Oct 25, 2012 at 12:51:59PM +0200, Joachim Schmitz wrote:
> > But then I would think using /usr/local would be the sane thing to put
> > there, if that is the closest to "standard" for your platform.
>
> OK, yes, hardcoding /usr/local seems OK too.
> Would I need to re-roll?
Please do.
-Peff
^ permalink raw reply
* RE: [PATCH v2] fix 'make test' for HP NonStop
From: Joachim Schmitz @ 2012-10-25 10:57 UTC (permalink / raw)
To: 'Jeff King'; +Cc: git
This fixes the vast majority of test failures on HP NonStop.
Signed-off-by: Joachim Schmitz <jojo@schmitz-digital.de>
---
v2: hardcode /usr/local rather than using ${prefix}
Makefile | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/Makefile b/Makefile
index f69979e..35380dd 100644
--- a/Makefile
+++ b/Makefile
@@ -1381,6 +1381,15 @@ ifeq ($(uname_S),NONSTOP_KERNEL)
MKDIR_WO_TRAILING_SLASH = YesPlease
# RFE 10-120912-4693 submitted to HP NonStop development.
NO_SETITIMER = UnfortunatelyYes
+
+ # for 'make test'
+ # some test don't work with /bin/diff, some fail with /bin/tar
+ # some need bash, and some need /usr/local/bin in PATH first
+ SHELL_PATH=/usr/local/bin/bash
+ SANE_TOOL_PATH=/usr/local/bin
+ # as of H06.25/J06.14, we might better use this
+ #SHELL_PATH=/usr/coreutils/bin/bash
+ #SANE_TOOL_PATH=/usr/coreutils/bin:/usr/local/bin
endif
ifneq (,$(findstring MINGW,$(uname_S)))
pathsep = ;
^ permalink raw reply related
* RE: [PATCH] fix 'make test' for HP NonStop
From: Joachim Schmitz @ 2012-10-25 10:59 UTC (permalink / raw)
To: 'Jeff King'; +Cc: git
In-Reply-To: <20121025105236.GA2962@sigill.intra.peff.net>
> From: Jeff King [mailto:peff@peff.net]
> Sent: Thursday, October 25, 2012 12:53 PM
> To: Joachim Schmitz
> Cc: git@vger.kernel.org
> Subject: Re: [PATCH] fix 'make test' for HP NonStop
>
> On Thu, Oct 25, 2012 at 12:51:59PM +0200, Joachim Schmitz wrote:
>
> > > But then I would think using /usr/local would be the sane thing to put
> > > there, if that is the closest to "standard" for your platform.
> >
> > OK, yes, hardcoding /usr/local seems OK too.
> > Would I need to re-roll?
>
> Please do.
Done. For some reason not 'chained' to this thread though
Bye, Jojo
^ permalink raw reply
* Re: [PATCH] git-send-email: skip RFC2047 quoting for ASCII subjects
From: Krzysztof Mazur @ 2012-10-25 11:12 UTC (permalink / raw)
To: Jeff King; +Cc: gitster, git
In-Reply-To: <20121025090149.GC8390@sigill.intra.peff.net>
On Thu, Oct 25, 2012 at 05:01:49AM -0400, Jeff King wrote:
>
> Hmm. What is this patch on top of? It looks like it is on top of your
> original patch, but when I tried it on top of that, it does not apply
> either, and the index lines in the patch do not mention a sha1 that I do
> not have.
Sorry, it's against km/send-email-compose-encoding (or current next)
+ "git-send-email: use compose-encoding for Subject".
>
> Do you mind re-rolling a final 2-patch series with:
>
> 1. Your original patch and this one squashed together, with an
> appropriate commit message.
I think that it's better to do refactoring and fix for ASCII in separate
patches. Maybe we should reverse order of first two patches. This first
will do refactoring and the second will just replace quote_rfc2047()
with quote_subject() in "broken" encoding case and add test
for this problem.
>
> 2. The second "quote when we see '=?'" patch.
>
> Thanks.
>
> -Peff
ok, I will resend the final series.
I need also to fix "git-send-email: use compose-encoding for Subject"
patch. Now it's depends both on this series and
km/send-email-compose-encoding branch.
Krzysiek
^ permalink raw reply
* Re: [PATCH] git-send-email: skip RFC2047 quoting for ASCII subjects
From: Jeff King @ 2012-10-25 11:21 UTC (permalink / raw)
To: Krzysztof Mazur; +Cc: gitster, git
In-Reply-To: <20121025111919.GA25272@shrek.podlesie.net>
On Thu, Oct 25, 2012 at 01:19:19PM +0200, Krzysztof Mazur wrote:
> On Thu, Oct 25, 2012 at 06:08:54AM -0400, Jeff King wrote:
> >
> > Ah, never mind. I missed your earlier "use compose-encoding for
> > Subject". I've queued it and all of the follow-ons onto the
> > km/send-email-compose-encoding topic.
> >
>
> thanks, what about the problem with whitespaces in "quote_subject" patch?
I fixed the whitespace problems, and just applying your patches in
sequence on top of send-email-compose-encoding actually looks sensible
(after looking at it, I came to the same conclusion as you that the two
patches should be kept separate). I'll push out the results of tonight's
work in a few minutes, if you want to eyeball what's in pu.
-Peff
^ permalink raw reply
* Re: [PATCH] git-send-email: skip RFC2047 quoting for ASCII subjects
From: Krzysztof Mazur @ 2012-10-25 11:19 UTC (permalink / raw)
To: Jeff King; +Cc: gitster, git
In-Reply-To: <20121025100854.GN8390@sigill.intra.peff.net>
On Thu, Oct 25, 2012 at 06:08:54AM -0400, Jeff King wrote:
>
> Ah, never mind. I missed your earlier "use compose-encoding for
> Subject". I've queued it and all of the follow-ons onto the
> km/send-email-compose-encoding topic.
>
thanks, what about the problem with whitespaces in "quote_subject" patch?
Krzysiek
^ permalink raw reply
* Re: [PATCH] Fixes handling of --reference argument.
From: W. Trevor King @ 2012-10-25 10:45 UTC (permalink / raw)
To: Jeff King; +Cc: szager, git
In-Reply-To: <20121025083625.GA8390@sigill.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 994 bytes --]
On Thu, Oct 25, 2012 at 04:36:26AM -0400, Jeff King wrote:
> On Wed, Oct 24, 2012 at 09:52:52PM -0700, szager@google.com wrote:
> > diff --git a/git-submodule.sh b/git-submodule.sh
> > index ab6b110..dcceb43 100755
> > --- a/git-submodule.sh
> > +++ b/git-submodule.sh
> > @@ -270,7 +270,6 @@ cmd_add()
> > ;;
> > --reference=*)
> > reference="$1"
> > - shift
> > ;;
>
> Is that right? We'll unconditionally do a "shift" at the end of the
> loop. If it were a two-part argument like "--reference foo", the extra
> shift would make sense, but for "--reference=*", no extra shift should
> be neccessary. Am I missing something?
Both the patch and Jeff's analysis are right. You only need an
in-case shift if you consume "$2", or you're on ‘--’ and you're
breaking before the end-of-case shift.
--
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
* What's cooking in git.git (Oct 2012, #08; Thu, 25)
From: Jeff King @ 2012-10-25 11:54 UTC (permalink / raw)
To: git
What's cooking in git.git (Oct 2012, #08; Thu, 25)
--------------------------------------------------
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
Now that 1.8.0 is out, I've graduated the first batch of topics to
master. I've also picked up some topics from the list, mostly
documentation fixes that went straight to next. I haven't yet moved any
of the cooking topics up to next.
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]
* gb/maint-doc-svn-log-window-size (2012-10-25) 1 commit
- Document git-svn fetch --log-window-size parameter
Looks good to me, but I'd like to get an ack from svn folks.
* jk/config-ignore-duplicates (2012-10-24) 8 commits
(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.
* 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.
* 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.
* ph/submodule-sync-recursive (2012-10-24) 2 commits
- Add tests for submodule sync --recursive
- Teach --recursive to submodule sync
I'd like review from submodule folks on this one.
* 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.
* 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.
--------------------------------------------------
[Graduated to "master"]
* bw/config-lift-variable-name-length-limit (2012-10-01) 1 commit
(merged to 'next' on 2012-10-08 at 69f54f4)
+ Remove the hard coded length limit on variable names in config files
The configuration parser had an unnecessary hardcoded limit on
variable names that was not checked consistently. Lift the limit.
* da/mergetools-p4 (2012-10-11) 1 commit
(merged to 'next' on 2012-10-12 at 16f5c06)
+ mergetools/p4merge: Handle "/dev/null"
* fa/remote-svn (2012-10-07) 16 commits
(merged to 'next' on 2012-10-07 at 7b90cf4)
+ Add a test script for remote-svn
+ remote-svn: add marks-file regeneration
+ Add a svnrdump-simulator replaying a dump file for testing
+ remote-svn: add incremental import
+ remote-svn: Activate import/export-marks for fast-import
+ Create a note for every imported commit containing svn metadata
+ vcs-svn: add fast_export_note to create notes
+ Allow reading svn dumps from files via file:// urls
+ remote-svn, vcs-svn: Enable fetching to private refs
+ When debug==1, start fast-import with "--stats" instead of "--quiet"
+ Add documentation for the 'bidi-import' capability of remote-helpers
+ Connect fast-import to the remote-helper via pipe, adding 'bidi-import' capability
+ Add argv_array_detach and argv_array_free_detached
+ Add svndump_init_fd to allow reading dumps from arbitrary FDs
+ Add git-remote-testsvn to Makefile
+ Implement a remote helper for svn in C
A GSoC project.
* jc/test-say-color-avoid-echo-escape (2012-10-11) 1 commit
(merged to 'next' on 2012-10-11 at 639036d)
+ test-lib: Fix say_color () not to interpret \a\b\c in the message
Recent nd/wildmatch series was the first to reveal this ancient bug
in the test scaffolding.
* jk/no-more-pre-exec-callback (2012-06-05) 1 commit
(merged to 'next' on 2012-10-12 at 69fed45)
+ pager: drop "wait for output to run less" hack
(Originally merged to 'next' on 2012-07-23)
Removes a workaround for buggy version of less older than version
406.
* jk/peel-ref (2012-10-04) 4 commits
(merged to 'next' on 2012-10-08 at 4adfa2f)
+ upload-pack: use peel_ref for ref advertisements
+ peel_ref: check object type before loading
+ peel_ref: do not return a null sha1
+ peel_ref: use faster deref_tag_noverify
Speeds up "git upload-pack" (what is invoked by "git fetch" on the
other side of the connection) by reducing the cost to advertise the
branches and tags that are available in the repository.
* jk/strbuf-detach-always-non-null (2012-10-18) 1 commit
(merged to 'next' on 2012-10-18 at 54561c7)
+ strbuf: always return a non-NULL value from strbuf_detach
* jm/diff-context-config (2012-10-02) 2 commits
(merged to 'next' on 2012-10-02 at e57700a)
+ t4055: avoid use of sed 'a' command
(merged to 'next' on 2012-10-01 at 509a558)
+ diff: diff.context configuration gives default to -U
Teaches a new configuration variable to "git diff" Porcelain and
its friends.
* js/mingw-fflush-errno (2012-10-17) 1 commit
(merged to 'next' on 2012-10-18 at 43d6ebb)
+ maybe_flush_or_die: move a too-loose Windows specific error
* nd/attr-match-optim (2012-10-05) 2 commits
(merged to 'next' on 2012-10-08 at bfbdd8a)
+ attr: avoid searching for basename on every match
+ attr: avoid strlen() on every match
(this branch is used by as/check-ignore, nd/attr-match-optim-more and nd/wildmatch.)
Trivial and obvious optimization for finding attributes that match
a given path.
--------------------------------------------------
[Stalled]
* rc/maint-complete-git-p4 (2012-09-24) 1 commit
- 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-21) 8 commits
- string_list_longest_prefix(): remove function
- normalize_ceiling_entry(): resolve symlinks
- 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-16) 10 commits
(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 used by mo/cvs-server-updates.)
* mo/cvs-server-updates (2012-10-16) 10 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
(this branch uses mo/cvs-server-cleanup.)
* 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.
* 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.
* jc/prettier-pretty-note (2012-10-25) 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()
Needs updates to the placeholder documentation.
* 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.
* 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.
* 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.
* 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.
* nd/tree-walk-enum-cleanup (2012-10-19) 1 commit
- tree-walk: use enum interesting instead of integer
* 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.
* 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.
* 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.
* fc/completion-send-email-with-format-patch (2012-10-16) 1 commit
- completion: add format-patch options to send-email
* fc/zsh-completion (2012-10-15) 3 commits
- completion: add new zsh completion
- tests: use __gitcompadd to simplify completion tests
- completion: add new __gitcompadd helper
* 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.
* as/check-ignore (2012-10-19) 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.
* 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.
* km/send-email-compose-encoding (2012-10-25) 5 commits
- 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.
Will merge to 'master' in the second batch after 1.8.0 ships.
* 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.
* 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.
* 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.
* 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.
* 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/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.
* 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.
* 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()
(this branch uses rs/branch-del-symref.)
"update-ref -d --deref SYM" to delete a ref through a symbolic ref
that points to it did not remove it correctly.
--------------------------------------------------
[Discarded]
* fa/vcs-svn (2012-10-07) 4 commits
- vcs-svn: remove repo_tree
- vcs-svn/svndump: rewrite handle_node(), begin|end_revision()
- vcs-svn/svndump: restructure node_ctx, rev_ctx handling
- svndump: move struct definitions to .h
(this branch uses fa/remote-svn.)
A follow-up to a GSoC project, but seems not quite ready.
* ph/credential-refactor (2012-09-02) 5 commits
- wincred: port to generic credential helper
- Merge branch 'ef/win32-cred-helper' into ph/credential-refactor
- osxkeychain: port to generic credential helper implementation
- gnome-keyring: port to generic helper implementation
- contrib: add generic credential helper
Attempts to refactor to share code among OSX keychain, Gnome keyring
and Win32 credential helpers. Turns out that the sharing wasn't
big enough to worth the churn.
* ms/contrib-thunderbird-updates (2012-08-31) 2 commits
- [SQUASH] minimum fixup
- Thunderbird: fix appp.sh format problems
Update helper to send out format-patch output using Thunderbird.
Seems to have design regression for silent users.
* jx/test-real-path (2012-08-27) 1 commit
- test: set the realpath of CWD as TRASH_DIRECTORY
Running tests with the "trash" directory elsewhere with the "--root"
option did not work well if the directory was specified by a symbolic
link pointing at it.
Seems broken as it makes $(pwd) and TRASH_DIRECTORY inconsistent.
* jc/maint-push-refs-all (2012-08-27) 2 commits
- get_fetch_map(): tighten checks on dest refs
- [BROKEN] fetch/push: allow refs/*:refs/*
This is broken (see the log message there). "git fetch/push
$there 'refs/*:refs/*'" already propagates heads, tags, notes,
etc. hierarchies; an attempt to propagate refs/stash will fail
against an older version of the other side and is not worth
supporting.
* tx/relative-in-the-future (2012-08-16) 2 commits
- date: show relative dates in the future
- date: refactor the relative date logic from presentation
Not my itch; rewritten an earlier submission by Tom Xue into
somewhat more maintainable form, though it breaks existing i18n.
Was waiting for a voluteer to fix it up, which never happend.
* jc/split-blob (2012-04-03) 6 commits
- chunked-object: streaming checkout
- chunked-object: fallback checkout codepaths
- bulk-checkin: support chunked-object encoding
- bulk-checkin: allow the same data to be multiply hashed
- new representation types in the packstream
- packfile: use varint functions
I finished the streaming checkout codepath, but as explained in
127b177 (bulk-checkin: support chunked-object encoding, 2011-11-30),
these are still early steps of a long and painful journey. At least
pack-objects and fsck need to learn the new encoding for the series
to be usable locally, and then index-pack/unpack-objects needs to
learn it to be used remotely.
Given that I heard a lot of noise that people want large files, and
that I was asked by somebody at GitTogether'11 privately for an
advice on how to pay developers (not me) to help adding necessary
support, I am somewhat disappointed that the original patch series
that was sent long time ago still remains here without much comments
and updates from the developer community. I even made the interface
to the logic that decides where to split chunks easily replaceable,
and I deliberately made the logic in the original patch extremely
stupid to entice others, especially the "bup" fanbois, to come up
with a better logic, thinking that giving people an easy target to
shoot for, they may be encouraged to help out. The plan is not
working :-<.
^ permalink raw reply
* Re: [PATCH] Move try_merge_command and checkout_fast_forward to libgit.a
From: Nguyen Thai Ngoc Duy @ 2012-10-25 12:50 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20121025094500.GJ8390@sigill.intra.peff.net>
On Thu, Oct 25, 2012 at 4:45 PM, Jeff King <peff@peff.net> wrote:
> On Tue, Oct 23, 2012 at 09:24:51AM +0700, Nguyen Thai Ngoc Duy wrote:
>
>> These functions are called in sequencer.c, which is part of
>> libgit.a. This makes libgit.a potentially require builtin/merge.c for
>> external git commands.
>>
>> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
>> ---
>> I made some unrelated changes in sequencer.c and this problem shown
>> up. merge-recursive.c is probably not the best place for these
>> functions. I just don't want to create merge.c for them.
>
> I'm fine with this conceptually, but merge-recursive really is the wrong
> place. I'd much rather see a new merge.c to collect merge-related helper
> functions that are not strategy-specific.
OK. I checked around for similar issues and found these used by
libgit.a but stay in builtin/ instead:
estimate_bisect_steps: bisect.c and builtin/rev-list.c
print_commit_list: bisect.c and builtin/rev-list.c
-> move them to bisect.c? another candidate is revision.c.
fetch_pack: transport.c and builtin/fetch-pack.c
send_pack: transport.c and builtin/send-pack.c
-> move them to transport.c? or new files fetch-pack.c and
send-pack.c? I haven't check how many functions they may pull
together.
setup_diff_pager: diff-no-index.c and builtin/diff.c
-> to diff-lib.c?
--
Duy
^ permalink raw reply
* Re: t9401 fails with OS X sed
From: Torsten Bögershausen @ 2012-10-25 12:51 UTC (permalink / raw)
To: Jeff King
Cc: Geert Bosch, Brian Gernhardt, Git List, Torsten Bögershausen
In-Reply-To: <20121025084132.GB8390@sigill.intra.peff.net>
On 25.10.12 10:41, Jeff King wrote:
> On Thu, Oct 25, 2012 at 01:04:11AM -0400, Geert Bosch wrote:
>
>> On Oct 24, 2012, at 23:54, Brian Gernhardt <brian@gernhardtsoftware.com> wrote:
>>
>>> It works if I change \s to [[:space:]], but I don't know how portable that is.
>>
>> As \s is shorthand for the POSIX character class [:space:], I'd say the latter
>> should be more portable: anything accepting the shorthand should also accept
>> the full character class. If not, you probably only care about horizontal tab
>> and space, for which you could just use a simple regular expression. Just a
>> literal space and tab character between square brackets is probably going to be
>> most portable, though not most readable.
>
> I agree that the POSIX character class would be more portable than "\s",
> but we do not have any existing uses of them, and I would worry a little
> about older systems like Solaris. If we can simply use a literal space
> and tab, that seems like the safest.
>
> Brian, can you work up a patch?
>
> -Peff
Would this be portable:
(It works on my Mac OS X box after installing cvs)
But I don't have solaris
diff --git a/t/t9401-git-cvsserver-crlf.sh b/t/t9401-git-cvsserver-crlf.sh
index cdb8360..f2ec9d2 100755
--- a/t/t9401-git-cvsserver-crlf.sh
+++ b/t/t9401-git-cvsserver-crlf.sh
@@ -46,7 +46,7 @@ check_status_options() {
echo "Error from cvs status: $1 $2" >> "${WORKDIR}/marked.log"
return 1;
fi
- got="$(sed -n -e 's/^\s*Sticky Options:\s*//p' "${WORKDIR}/status.out")"
+ got="$(tr '\t' ' ' < "${WORKDIR}/status.out" | sed -n -e 's/^ *Sticky Options: *//p')"
expect="$3"
if [ x"$expect" = x"" ] ; then
expect="(none)"
^ permalink raw reply related
* [PATCH] t9401: Use tr to handle TAB
From: Torsten Bögershausen @ 2012-10-25 13:06 UTC (permalink / raw)
To: git; +Cc: tboegi
Not all sed versions understand \s as whitespace
Use tr to translate '\t' into ' ' before feeding the line into sed
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
---
t/t9401-git-cvsserver-crlf.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t9401-git-cvsserver-crlf.sh b/t/t9401-git-cvsserver-crlf.sh
index cdb8360..f2ec9d2 100755
--- a/t/t9401-git-cvsserver-crlf.sh
+++ b/t/t9401-git-cvsserver-crlf.sh
@@ -46,7 +46,7 @@ check_status_options() {
echo "Error from cvs status: $1 $2" >> "${WORKDIR}/marked.log"
return 1;
fi
- got="$(sed -n -e 's/^\s*Sticky Options:\s*//p' "${WORKDIR}/status.out")"
+ got="$(tr '\t' ' ' < "${WORKDIR}/status.out" | sed -n -e 's/^ *Sticky Options: *//p')"
expect="$3"
if [ x"$expect" = x"" ] ; then
expect="(none)"
--
1.7.12
^ permalink raw reply related
* Re: [PATCH 1/3] t9350: point out that refs are not updated correctly
From: Felipe Contreras @ 2012-10-25 13:33 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Jonathan Nieder, Johannes Schindelin, Junio C Hamano, Jeff King,
Git List, Daniel Barkalow, Ramkumar Ramachandra, Dmitry Ivankov,
Ævar Arnfjörð, Eric Herman, Fernando Vezzosi
In-Reply-To: <CAGdFq_ifDYKTXt_cKkz5ZTBPgZKB7HFEbWereNnhSmS3qbhbsA@mail.gmail.com>
On Thu, Oct 25, 2012 at 9:50 AM, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> On Thu, Oct 25, 2012 at 12:48 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
>> Sverre Rabbelier wrote:
>>
>>> I know there was a reason why using UNINTERESTING didn't work
>>> (otherwise we could've used that to start with, instead of needing
>>> Junio's whence solution). I think all refs ended up being marked as
>>> UNINTERESTING or somesuch.
>>
>> True. Is it be possible to check UNINTERESTING in revs->cmdline
>> before the walk?
It is possible to check in revs->pending, but '^foo master' will mark
them both as UNINTERESTING, and 'master..master' as well, which again,
is what we actually want, because that's how it works in the rest of
git.
> That might work, maybe Dscho remembers why we did not go with that approach.
Because you want 'master..master' to output something, but that's
wrong; it's changing the semantics of commitishes, and you don't need
that to solve this problem.
--
Felipe Contreras
^ permalink raw reply
* Re: [RFC/PATCH] __git_ps1: migrate out of contrib/completion
From: Felipe Contreras @ 2012-10-25 14:19 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Danny Yates, git@vger.kernel.org, Anders Kaseorg, Ted Pavlic,
SZEDER Gábor, Dan McGee
In-Reply-To: <20121025074549.GC15790@elie.Belkin>
On Thu, Oct 25, 2012 at 9:45 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
> new file mode 120000
> index 00000000..a4fbb216
> --- /dev/null
> +++ b/contrib/completion/git-prompt.sh
> @@ -0,0 +1 @@
> +../../git-sh-prompt.sh
> \ No newline at end of file
^ no new line?
--
Felipe Contreras
^ permalink raw reply
* Re: Where should git-prompt.sh be installed?
From: SZEDER Gábor @ 2012-10-25 15:11 UTC (permalink / raw)
To: Jonathan Nieder
Cc: git, Anders Kaseorg, Danny Yates, Felipe Contreras, Ted Pavlic,
Dan McGee
In-Reply-To: <20121025005106.GA9112@elie.Belkin>
On Wed, Oct 24, 2012 at 05:51:06PM -0700, Jonathan Nieder wrote:
> Hi,
>
> In olden days the admin would copy contrib/completion/git-completion.sh
> to
>
> /etc/bash_completion.d/git
>
> and mortals could source /etc/bash_completion or
> /etc/bash_completion.d/git in their ~/.bashrc (possibly shared among
> multiple machines) so that the bash completion and __git_ps1 helpers
> could work.
Ah, the good old days! I even modified 'make install' to copy the
completion script to /etc/bash_completion.d/. And I was happy.
> With Git 1.7.12 __git_ps1 has been split into a separate file, to help
> users who only want __git_ps1 to avoid the overhead of loading the
> entire completion script (and allow the completion script to be loaded
> by bash-completion magic on the fly!). Now the sysadmin should copy
> contrib/completion/git-completion.sh to
>
> /usr/share/bash-completion/completions/git
>
> and contrib/completion/git-prompt.sh to
>
> /usr/share/git-core/contrib/?? (somewhere?)
>
> Mortals source /etc/bash_completion in their ~/.bashrc (possibly
> shared among multiple machines) and expect bash completion to work.
> For __git_ps1, users should source that ?? path.
>
> Questions:
>
> 1) what path is appropriate for ?? above?
> 2) is this documented anywhere?
Don't know what is appropriate, and it's not documented. I for one
copy it manually to ~/.git-prompt.sh every once in a while. And I'm
not all that happy with that.
> Possible answers:
>
> 1) Fedora uses /etc/profile.d/git-prompt.sh. Gentoo uses
> /usr/share/bash-completion/git-prompt. Maybe others use
> some other path.
>
> 2) The scripts themselves suggest copying to ~/.git-completion.sh
> and ~/.git-prompt.sh.
>
> Proposal:
>
> 1) /usr/lib/git-core/git-sh-prompt
> 2) git-sh-prompt(1)
Not sure about the "sh" part. The prompt function is very
Bash-specific, it won't work under a plain POSIX shell.
Do other VCSes have similar prompt scripts? Where do they install
theirs?
Gábor
^ permalink raw reply
* Unexpected behaviour after removing submodule
From: Nicolas Morey-Chaisemartin @ 2012-10-25 15:06 UTC (permalink / raw)
To: git
Hi,
At work, we use a lot of submodules (several levels of submodules actually).
As we also work with development branches, we use scripts to resync the whole checked-out tree (mainly in automated integration)
We recently run across an issue where a branch (dev) contained a submodule while it had been removed in master and the files were imported in a subdirectory with the same name (probably using git-subtree).
Basically:
On dev:
* top/refs(submodule)/file1
On master:
* top/refs(dir)/file1
Outside the fact that it is quite hard to move from one branch to the other while having a perfectly clean tree checked out underneath, we manage to end up into a weird (invalid) state
that was neither clearly described nor "easy" to cleanup (using standard git clean/checkout/reset commands).
While I cannot explain how we got in this state, here is a small test-case that produce the same results:
------
mkdir folder1
cd folder1
git init
echo "Ooops" > file
git add file
git commit -m "Add file"
cd ..
mkdir folder2
cd folder2
git init
mkdir folder1
echo "Ooops" > folder1/file
git add folder1/file
git commit -m "Add file again"
git checkout -b branch
cp -R ../folder1/.git ./folder1
------
The 'cp' just seems pointless but with the submodule described as above we manage to end up in a similar state.
In this state, when being in folder2, git status reports nothing. Dev branch is checked out and everything looks great.
However if you change dir to folder2/folder1, while still being inside folder2, git thinks (because of the .git dir) that you are actually on master branch of folder1 repository.
Which mean that if you happen to commit from a subdirectory, you may easily end-up committing in another repository than the one expected.
The issue is, there is no way from folder2 to see that something "wrong" is going on inside your tree!
As we manage to reach this state using only standard git commands (I'll try to reproduce it) with submodules, and this being part of an automated flow, it is quite worrying.
We may actually be committing in the wrong repo and pushing the wrong things around.
Is there or should there be a way to look for such issues? And is this an expected behaviour?
Thanks in advance
Nicolas
^ permalink raw reply
* [PATCH] Use character class for sed expression instead of \s
From: Ben Walton @ 2012-10-25 15:58 UTC (permalink / raw)
To: tboegi, peff, bosch, brian, git; +Cc: Ben Walton
In-Reply-To: <508935CB.9020408@web.de>
Sed on Mac OS X doesn't handle \s in a sed expressions so use a more
portable character set expression instead.
Signed-off-by: Ben Walton <bdwalton@gmail.com>
---
Hi Torsten,
I think this would be a nicer fix for the issue although your solution
should work as well.
Thanks
-Ben
t/t9401-git-cvsserver-crlf.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t9401-git-cvsserver-crlf.sh b/t/t9401-git-cvsserver-crlf.sh
index cdb8360..1c5bc84 100755
--- a/t/t9401-git-cvsserver-crlf.sh
+++ b/t/t9401-git-cvsserver-crlf.sh
@@ -46,7 +46,7 @@ check_status_options() {
echo "Error from cvs status: $1 $2" >> "${WORKDIR}/marked.log"
return 1;
fi
- got="$(sed -n -e 's/^\s*Sticky Options:\s*//p' "${WORKDIR}/status.out")"
+ got="$(sed -n -e 's/^[ ]*Sticky Options:[ ]*//p' "${WORKDIR}/status.out")"
expect="$3"
if [ x"$expect" = x"" ] ; then
expect="(none)"
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH] Use character class for sed expression instead of \s
From: Brian Gernhardt @ 2012-10-25 16:00 UTC (permalink / raw)
To: Ben Walton; +Cc: tboegi, peff, bosch, git
In-Reply-To: <1351180699-24695-1-git-send-email-bdwalton@gmail.com>
On Oct 25, 2012, at 11:58 AM, Ben Walton <bdwalton@gmail.com> wrote:
> Sed on Mac OS X doesn't handle \s in a sed expressions so use a more
> portable character set expression instead.
>
> Signed-off-by: Ben Walton <bdwalton@gmail.com>
Acked-by: Brian Gernhardt <brian@gernhardtsoftware.com>
I have an identical change sitting in my git.git, I've just been too distracted by other things to commit and send it.
~~ Brian Gernhardt
^ permalink raw reply
* Re: [PATCHv2] git-status: show short sequencer state
From: Phil Hord @ 2012-10-25 16:05 UTC (permalink / raw)
To: Jeff King
Cc: git, phil.hord, Junio C Hamano, konglu, Matthieu Moy, Kong Lucien,
Duperray Valentin, Jonas Franck, Nguy Thomas,
Nguyen Huynh Khoi Nguyen
In-Reply-To: <20121025092919.GG8390@sigill.intra.peff.net>
Jeff King wrote:
> On Tue, Oct 23, 2012 at 04:02:54PM -0400, Phil Hord wrote:
>
>> Teach git-status to report the sequencer state in short form
>> using a new --sequencer (-S) switch. Output zero or more
>> simple state token strings indicating the deduced state of the
>> git sequencer.
>>
>> Introduce a common function to determine the current sequencer
>> state so the regular status function and this short version can
>> share common code.
>>
>> Add a substate to wt_status_state to track more detailed
>> information about a state, such as "conflicted" or "resolved".
>> Move the am_empty_patch flage out of wt_status_state and into
> This patch ended up quite long. It might be a little easier to review
> if it were broken into refactoring steps (I have not looked at it too
> closely yet, but it seems like the three paragraphs above could each be
> their own commit).
I can do that.
>> State token strings which may be emitted and their meanings:
>> merge a git-merge is in progress
>> am a git-am is in progress
>> rebase a git-rebase is in progress
>> rebase-interactive a git-rebase--interactive is in progress
> A minor nit, but you might want to update this list from the one in the
> documentation.
I considered it, but I also considered the audience; then I took the
easier path. I'll look again.
>> diff --git a/builtin/commit.c b/builtin/commit.c
>> index a17a5df..9706ed9 100644
>> --- a/builtin/commit.c
>> +++ b/builtin/commit.c
>> @@ -114,7 +114,8 @@ static struct strbuf message = STRBUF_INIT;
>> static enum {
>> STATUS_FORMAT_LONG,
>> STATUS_FORMAT_SHORT,
>> - STATUS_FORMAT_PORCELAIN
>> + STATUS_FORMAT_PORCELAIN,
>> + STATUS_FORMAT_SEQUENCER
>> } status_format = STATUS_FORMAT_LONG;
> Hmm. So the new format is its own distinct output format. I could not
> say "I would like to see short status, and by the way, show me the
> sequencer state", as you can with "-b". Is it possible to do this (or
> even desirable; getting the sequencer state should be way cheaper, so
> conflating the two may not be what some callers want).
>
> Not complaining, just wondering about the intended use cases.
Originally I did place this output in the short-format display. I
particularly want this info to be available for scripts. But it feels
"right" to include it with the short status, since the long-form is
already available with 'git status --no-short'.
Since there may be more than one line reported, I did not feel there was
a simple way to contain these details in with the short status. For
branch this is a simple decision as the reported branch will take
exactly one line.
git status -b -s
## master
M Foo
But for sequencer state, this seemed like it could be too convoluted or
might encourage too much reliance line-counting:
git status -b -s -S
## master
## merge
## conflicted
M Foo
Maybe a different line-prefix would help make this clearer:
git status -b -s -S
## master
#! merge
#! conflicted
M Foo
It seemed to me this was someone else's itch and I might not scratch it
properly. But I am willing to try if you think this is more useful than
distracting.
> Also, does there need to be a --porcelain version of this output? It
> seems like we can have multiple words (e.g., in a merge, with conflicted
> entries). If there is no arbitrary data, we do not have to worry about
> delimiters and quoting. But I wonder if we would ever want to expand
> the information to include arbitrary strings, at which point we would
> want NUL delimiters; should we start with that now?
This works, though I haven't tested it on v2:
git status -S -z
>> + // Determine main sequencer activity
> Please avoid C99 comments (there are others in the patch, too).
Thanks.
>> +void wt_sequencer_print(struct wt_status *s)
>> +{
>> + struct wt_status_state state;
>> +
>> + wt_status_get_state(s, &state);
>> +
>> + if (state.merge_in_progress)
>> + wt_print_token(s, "merge");
>> + if (state.am_in_progress)
>> + wt_print_token(s, "am");
>> + if (state.rebase_in_progress)
>> + wt_print_token(s, "rebase");
>> + if (state.rebase_interactive_in_progress)
>> + wt_print_token(s, "rebase-interactive");
>> + if (state.cherry_pick_in_progress)
>> + wt_print_token(s, "cherry-pick");
>> + if (state.bisect_in_progress)
>> + wt_print_token(s, "bisect");
>> +
>> + switch (state.substate) {
>> + case WT_SUBSTATE_NOMINAL:
>> + break;
>> + case WT_SUBSTATE_CONFLICTED:
>> + wt_print_token(s, "conflicted");
>> + break;
>> + case WT_SUBSTATE_RESOLVED:
>> + wt_print_token(s, "resolved");
>> + break;
>> + case WT_SUBSTATE_EDITED:
>> + wt_print_token(s, "edited");
>> + break;
>> + case WT_SUBSTATE_EDITING:
>> + wt_print_token(s, "editing");
>> + break;
>> + case WT_SUBSTATE_SPLITTING:
>> + wt_print_token(s, "splitting");
>> + break;
>> + case WT_SUBSTATE_AM_EMPTY:
>> + wt_print_token(s, "am-empty");
>> + break;
>> + }
>> +}
> It is clear from this code that some tokens can happen together, and
> some are mutually exclusive. Should the documentation talk about that,
> or do we want to literally keep it as a list of tags?
>
> -Peff
I want to literally keep it as a list of tags. This code does not
presume any exclusivity in the main state and I I do not think it
should. I can imagine being in a "rebase cherry-pick conflicted" state,
even though the current wt_status_get_state function does not allow
detecting it. I think that function is overly restrictive, but it was
not important to me yet.
Perhaps it is useful to indicate that the substate values are mutually
exclusive, but I also feel like this is an implementation detail. It is
possible to be in "rebase-interactive edited conflicted" state, but it
is not possible for this code to tell you that. But should we document
that fact and thus restrict future improvement in this area? My first
inclination is to say no, that we should leave this open. But on the
other hand, I can see how someone could be confused if their expected
token never appeared only because another one took precedence.
Maybe the exclusive states should be explicit in the implementation.
Maybe I should not have a substate at all but each of these substates
should be a separate boolean (or ternary). Something like this:
struct wt_status_state {
int merge_in_progress;
int am_in_progress;
+ int am_empty_patch;
- int rebase_in_progress;
- int rebase_interactive_in_progress;
+ int rebase_in_progress; /* 0=no, 1=normal, 2=interactive */
int cherry_pick_in_progress;
int bisect_in_progress;
enum wt_status_substate substate;
+ int conflicts; /* 0=none, 1=yes, 2=resolved */
+ int editing; /* 0=no, 1=editing, 2=edited */
};
My primary motivation is to standardize the detection of these various
states so scripts do not need to know, for example, to look for the
presence of '$GIT_DIR/rebase-merge' or that a zero-length
'$GIT_DIR/rebase-apply/patch' is significant. An immediate need is to
show some tags in my shell prompt when my current state is not clean.
The current patch meets this latter need well. If I add the output of
$(git status -S) to my prompt, I see nothing when I am "clean" and I see
_something_ when I am not.
But the former need is not so clear. A script today which is interested
in an interactive rebase may simply say $(git status -S | grep
"^rebase-interactive$"). But a new flavor of rebase in the future could
muddy the waters. Maybe there is a need for another reporting state
which provides a definitive answer on all possible tokens. Consider
that I am in an interactive-rebase which has encountered a conflict.
1. Simple state, useful for humans and prompts:
$ git status -S
rebase-interactive
conflicted
2. More details for scripts who may not care to distinguish between
inclusive things like "rebase" and "rebase-interactive":
$ git status -S=detailed
rebase
rebase-interactive
conflicted
3. Complete disambiguation:
git status -S=all
no-merge
no-am
rebase
rebase-interactive
no-cherry-pick
no-bisect
conflicted
no-resolved
no-edited
no-editing
no-splitting
no-am-empty
Now a script interested in a condition can check for it explicitly in
two forms: "condition" and "no-condition". If neither is found, he can
assume that his token is obsolete (possibly it was replaced with
something more explicit). And if his goal is to detect any kind of
rebase, he can look for the "rebase" token rather than worrying about
its myriad types.
But at this point I feel overwhelmed by the possibilities. Uncertainty
comes from trying to scratch someone else's itch. But at the same time,
I do want to make this status-detector appealing as "The One True Way to
check git's state" to avoid more deviating implementations in the future.
And so I am conflicted.
I apologize for being so long-winded on this. Thanks for playing
along. I welcome your thoughts and advice.
Phil
^ permalink raw reply
* Re: Where should git-prompt.sh be installed?
From: Jonathan Nieder @ 2012-10-25 16:12 UTC (permalink / raw)
To: SZEDER Gábor
Cc: git, Anders Kaseorg, Danny Yates, Felipe Contreras, Ted Pavlic,
Dan McGee
In-Reply-To: <20121025151120.GA14740@goldbirke>
SZEDER Gábor wrote:
> On Wed, Oct 24, 2012 at 05:51:06PM -0700, Jonathan Nieder wrote:
>> Proposal:
>>
>> 1) /usr/lib/git-core/git-sh-prompt
>> 2) git-sh-prompt(1)
>
> Not sure about the "sh" part. The prompt function is very
> Bash-specific, it won't work under a plain POSIX shell.
That's an interesting point. Here's my logic:
The prompt function was originally Bash-specific, but over time
it gained support for Zsh as well. If we're lucky, some day it
might gain support for mksh.
Meanwhile something simple like "git-prompt" would sound too much
like a normal git command, I fear.
Shell language extensions used:
* future standard: local variables
* cosmetic: [[ and (( syntax in place of test and $(
* cosmetic: for ((n=1; n <= n_stop; n++)) instead of a more explicit
while loop
* cosmetic: var+=value syntax
* optimization: <<< syntax to iterate over lines in a variable
instead of, for example, sed + eval
* arrays: svn_remote, svn_upstream --- using plain variables would
require some escaping.
So nothing fundamental, but since this is only useful in shells like
Bash that support command substitution in $PS1, it seems reasonable
to keep using the extensions until someone wants to use it with a
more limited shell.
In other words, the interface is still "this is a scriptlet you might
source in your Bourne-style shell to get a __git_ps1 function to use
in your prompt". The implementation language just happens not to be
POSIX shell today.
Perhaps it should return early in shells other than bash and zsh to
help people keep their .shrc simple. What do you think?
> Do other VCSes have similar prompt scripts? Where do they install
> theirs?
Mercurial has an hg-prompt extension that can be used by running "hg
prompt".
http://mercurial.selenic.com/wiki/PromptExtension
I haven't found one for Subversion.
Bazaar has contrib/bash/bzrbashprompt.sh. It doesn't get installed.
Thanks,
Jonathan
^ permalink raw reply
* Re: [PATCH] Use character class for sed expression instead of \s
From: Torsten Bögershausen @ 2012-10-25 16:28 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Ben Walton, tboegi, peff, bosch, git
In-Reply-To: <C2AB6973-7BC2-45A4-836E-BB1FAAE7501C@gernhardtsoftware.com>
On 25.10.12 18:00, Brian Gernhardt wrote:
>
> On Oct 25, 2012, at 11:58 AM, Ben Walton <bdwalton@gmail.com> wrote:
>
>> Sed on Mac OS X doesn't handle \s in a sed expressions so use a more
>> portable character set expression instead.
>>
>> Signed-off-by: Ben Walton <bdwalton@gmail.com>
>
> Acked-by: Brian Gernhardt <brian@gernhardtsoftware.com>
>
> I have an identical change sitting in my git.git, I've just been too distracted by other things to commit and send it.
>
> ~~ Brian Gernhardt
Much nicer, indeed.
BTW: While we are talking CVS: (I installed a fresh version)
cvs --version
Concurrent Versions System (CVS) 1.11.23 (client/server)
And t9200 fails:
git checkout t9200-git-cvsexportcommit.sh
tb@birne:~/projects/git/git.pu/t> ./t9200-git-cvsexportcommit.sh
cvs [init aborted]: Cannot initialize repository under existing CVSROOT: `/Users/tb/projects/git/git.pu/t/trash directory.t9200-git-cvsexportcommit'
FATAL: Unexpected exit with code 1
The following fixes it, but there are possibly better solutions.
Any comments/suggestions ?
diff t9200-git-cvsexportcommit.sh t9200-git-cvsexportcommit.tb.sh
28,29c28
< mkdir "$CVSROOT" &&
< cvs init &&
---
> (cvs init || mkdir "$CVSROOT" && cvs init ) &&
^ permalink raw reply
* Re: [PATCH 1/3] t9350: point out that refs are not updated correctly
From: Felipe Contreras @ 2012-10-25 16:43 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Sverre Rabbelier, Junio C Hamano, Jeff King, Git List,
Daniel Barkalow, Ramkumar Ramachandra, Dmitry Ivankov,
Johannes Schindelin, Ævar Arnfjörð, Eric Herman,
Fernando Vezzosi
In-Reply-To: <20121025071815.GA15790@elie.Belkin>
On Thu, Oct 25, 2012 at 9:18 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Felipe Contreras wrote:
>
>> Show me a single remote helper that manually stores SHA-1's and I
>> might believe you, but I doubt that, marks are too convenient.
>
> Oh dear lord. Why are you arguing? Explain how coming to a consensus
> on this will help accomplish something useful, and then I can explain
> my point of view. In the meantime, this seems like a waste of time.
We don't need to come to a consensus because there is no problem.
Nobody has requested this feature, and nobody has faced any problem
with this. If you have no evidence of the contrary, that's what I'll
believe.
I agree it's a waste of time, so let's not talk about the :0 -> SHA-1
feature, or the master..master feature in this thread; they are
orthogonal.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: git push tags
From: Drew Northup @ 2012-10-25 17:19 UTC (permalink / raw)
To: Angelo Borsotti; +Cc: git
In-Reply-To: <CAB9Jk9DMOwhDf3SvMzTmTZiyZg_4pgXx-evrfWkB3U4w-KqtVw@mail.gmail.com>
On Thu, Oct 25, 2012 at 2:58 AM, Angelo Borsotti
<angelo.borsotti@gmail.com> wrote:
> Hello,
>
> git push tag updates silently the specified tag. E.g.
>
> git init --bare release.git
> git clone release.git integrator
> cd integrator
> git branch -avv
> touch f1; git add f1; git commit -m A
> git tag v1
> git push origin tag v1
> touch f2; git add f2; git commit -m B
> git tag -f v1
> git push origin tag v1
>
> the second git push updates the tag in the remote repository. This is
> somehow counterintuitive because tags normally do not move (unless
> forced to that), and is not documented.
You specified "-f" (force) and it did exactly what you asked. That is
fully documented (git help tag).
> This is also harmful because it allows to change silently something
> (tags) that normally must not change.
Tags have many uses. Some of those uses are harmed when tags change
and some aren't. That's a philosophical argument and Git is a computer
program, not a philosopher. It is not the job of the machine to
prevent the user from shooting himself in the foot when he clearly
expressed an interest in doing so.
--
-Drew Northup
--------------------------------------------------------------
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
^ permalink raw reply
* [PATCH 0/2] gitk: handle --full-diff corectly
From: Felipe Contreras @ 2012-10-25 17:23 UTC (permalink / raw)
To: git; +Cc: Johannes Sixt, Paul Mackerras, Felipe Contreras
Basically $SUBJECT. See details in the 2nd patch.
Felipe Contreras (2):
gitk: simplify file filtering
gitk: handle --full-diff correctly
gitk-git/gitk | 36 +++++++++++++++++-------------------
1 file changed, 17 insertions(+), 19 deletions(-)
--
1.8.0
^ 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