* [PATCH] Change double quotes to single quotes in message
From: Jari Aalto @ 2009-03-21 9:08 UTC (permalink / raw)
To: git
>From 6daec692a39a1ecf0452f1ad1eb7ba6fbf5661c9 Mon Sep 17 00:00:00 2001
From: Jari Aalto <jari.aalto@cante.net>
Date: Sat, 21 Mar 2009 11:00:54 +0200
Subject: [PATCH] Change double quotes to single quotes in message
This helps selecting the text inside quotes by using mouse double-click
action (e.g. in Putty). Functions affected: update_refs_for_switch(),
update_refs_for_switch() and cmd_checkout().
---
builtin-checkout.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/builtin-checkout.c b/builtin-checkout.c
index 9fdfc58..49daade 100644
--- a/builtin-checkout.c
+++ b/builtin-checkout.c
@@ -503,10 +503,10 @@ static void update_refs_for_switch(struct checkout_opts *opts,
create_symref("HEAD", new->path, msg.buf);
if (!opts->quiet) {
if (old->path && !strcmp(new->path, old->path))
- fprintf(stderr, "Already on \"%s\"\n",
+ fprintf(stderr, "Already on '%s'\n",
new->name);
else
- fprintf(stderr, "Switched to%s branch \"%s\"\n",
+ fprintf(stderr, "Switched to%s branch '%s'\n",
opts->new_branch ? " a new" : "",
new->name);
}
@@ -515,7 +515,7 @@ static void update_refs_for_switch(struct checkout_opts *opts,
REF_NODEREF, DIE_ON_ERR);
if (!opts->quiet) {
if (old->path)
- fprintf(stderr, "Note: moving to \"%s\" which isn't a local branch\nIf you want to create a new branch from this checkout, you may do so\n(now or later) by using -b with the checkout command again. Example:\n git checkout -b <new_branch_name>\n", new->name);
+ fprintf(stderr, "Note: moving to '%s' which isn't a local branch\nIf you want to create a new branch from this checkout, you may do so\n(now or later) by using -b with the checkout command again. Example:\n git checkout -b <new_branch_name>\n", new->name);
describe_detached_head("HEAD is now at", new->commit);
}
}
--
1.6.1.3
^ permalink raw reply related
* What's cooking in git.git (Mar 2009, #06; Sat, 21)
From: Junio C Hamano @ 2009-03-21 7:58 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' while commits prefixed with '+' are in 'next'. The ones
marked with '.' do not appear in any of the branches, but I am still
holding onto them.
The topics list the commits in reverse chronological order. The topics
meant to be merged to the maintenance series have "maint-" in their names.
----------------------------------------------------------------
[New Topics]
* jk/reflog-date (Fri Mar 20 02:00:43 2009 -0400) 1 commit
- make oneline reflog dates more consistent with multiline format
* js/maint-1.6.0-exec-path-env (Wed Mar 18 08:42:53 2009 +0100) 1 commit
- export GIT_EXEC_PATH when git is run with --exec-path
* da/difftool (Thu Mar 19 01:25:25 2009 -0700) 1 commit
- difftool: move 'git-difftool' out of contrib
* jc/maint-1.6.0-keep-pack (Thu Mar 19 22:47:54 2009 -0500) 4 commits
- Remove --kept-pack-only option and associated infrastructure
- pack-objects: only repack or loosen objects residing in "local"
packs
- git-repack.sh: don't use --kept-pack-only option to pack-objects
- t7700-repack: add two new tests demonstrating repacking flaws
Brandon Casey fixed the regression previous patches introduced; thanks.
* jc/maint-1.6.0-blame-s (Wed Mar 18 00:13:03 2009 -0700) 1 commit
- blame: read custom grafts given by -S before calling
setup_revisions()
The above are all ready for 'next'.
* hv/cvsps-tests (Wed Mar 18 18:33:41 2009 +0100) 7 commits
- cvsimport: extend testcase about patchset order to contain
branches
- cvsimport: add test illustrating a bug in cvsps
- Add a test of "git cvsimport"'s handling of tags and branches
- Add some tests of git-cvsimport's handling of vendor branches
- Test contents of entire cvsimported "master" tree contents
- Use CVS's -f option if available (ignore user's ~/.cvsrc file)
- Start a library for cvsimport-related tests
Two cvsimport test topics were rewound from 'next' and merged into this
one. I'll keep this in 'pu' so that people can polish their cvsps skilz
to resolve issues these tests identify.
----------------------------------------------------------------
[Graduated to "master"]
* fc/parseopt-config (Tue Mar 17 10:46:37 2009 +0100) 10 commits
+ config: test for --replace-all with one argument and fix
documentation.
+ config: set help text for --bool-or-int
+ git config: don't allow --get-color* and variable type
+ git config: don't allow extra arguments for -e or -l.
+ git config: don't allow multiple variable types
+ git config: don't allow multiple config file locations
+ git config: reorganize to use parseopt
+ git config: reorganize get_color*
+ git config: trivial rename in preparation for parseopt
+ git_config(): not having a per-repo config file is not an error
* js/rebase-i-opt (Tue Mar 3 10:55:31 2009 +0100) 1 commit
+ rebase -i: avoid 'git reset' when possible
* jc/clone-branch-rebase (Tue Mar 10 01:20:42 2009 -0700) 2 commits
+ Improve "git branch --tracking" output
+ Make git-clone respect branch.autosetuprebase
This is a rewrite of a patch from Pat Notz.
* xx/db-refspec-vs-js-remote (Sun Mar 8 00:12:33 2009 -0800) 1 commit
+ Adjust js/remote-improvements and db/refspec-wildcard-in-the-
middle
* db/refspec-wildcard-in-the-middle (Sat Mar 7 01:11:39 2009 -0500) 5 commits
+ Support '*' in the middle of a refspec
+ Keep '*' in pattern refspecs
+ Use the matching function to generate the match results
+ Use a single function to match names against patterns
+ Make clone parse the default refspec with the normal code
* bw/autoconf (Thu Mar 12 15:20:12 2009 -0400) 7 commits
+ configure: rework pthread handling to allow for user defined flags
+ configure: make iconv tests aware of user arguments
+ configure: asciidoc version test cleanup
+ configure: wrap some library tests with GIT_STASH_FLAGS
+ configure: add macros to stash FLAG variables
+ configure: reorganize flow of argument checks
+ configure: ensure settings from user are also usable in the script
* mv/parseopt-ls-files (Sat Mar 7 20:27:22 2009 -0500) 4 commits
+ ls-files: fix broken --no-empty-directory
+ t3000: use test_cmp instead of diff
+ parse-opt: migrate builtin-ls-files.
+ Turn the flags in struct dir_struct into a single variable
The tip one was a subject for further discussion, but nothing is queued
yet.
----------------------------------------------------------------
[Will merge to 'master' soon]
* dm/maint-docco (Thu Mar 19 20:35:34 2009 -0700) 6 commits
+ Documentation: reword example text in git-bisect.txt.
+ Documentation: reworded the "Description" section of git-
bisect.txt.
+ Documentation: minor grammatical fixes in git-branch.txt.
+ Documentation: minor grammatical fixes in git-blame.txt.
+ Documentation: reword the "Description" section of git-bisect.txt.
+ Documentation: minor grammatical fixes in git-archive.txt.
* mg/test-installed (Mon Mar 16 18:03:12 2009 +0100) 2 commits
+ test-lib.sh: Allow running the test suite against installed git
+ test-lib.sh: Test for presence of git-init in the right path.
----------------------------------------------------------------
[Discarded]
* hv/cvsimport-tests (Mon Mar 2 18:59:36 2009 +0100) 1 commit
? cvsimport: add test illustrating a bug in cvsps
* mh/cvsimport-tests (Mon Feb 23 06:08:14 2009 +0100) 5 commits
? Add a test of "git cvsimport"'s handling of tags and branches
? Add some tests of git-cvsimport's handling of vendor branches
? Test contents of entire cvsimported "master" tree contents
? Use CVS's -f option if available (ignore user's ~/.cvsrc file)
? Start a library for cvsimport-related tests
----------------------------------------------------------------
[Stalled and may need help and prodding to go forward]
* ps/blame (Thu Mar 12 21:30:03 2009 +1100) 1 commit
- blame.c: start libifying the blame infrastructure
A few minor point remains in this initial one.
* jc/log-tz (Tue Mar 3 00:45:37 2009 -0800) 1 commit
- Allow --date=local --date=other-format to work as expected
The one I posted had a few corner-case bugs that was caught with the test
suite; this one has them fixed. People did not like the UI so it is kept
out of 'next'
* lh/submodule-tree-traversal (Sun Jan 25 01:52:06 2009 +0100) 1 commit
- archive.c: add support for --submodules[=(all|checkedout)]
Discussion stalled on the submodule selection criteria.
Probably I should discard it and wait for a reroll if needed.
* jc/merge-convert (Mon Jan 26 16:45:01 2009 -0800) 1 commit
- git-merge-file: allow converting the results for the work tree
This is a feature waiting for a user.
We did not give scripted Porcelains a way to say "this temporary file I am
using for merging is for this path, so use the core.autocrlf and attributes
rules for that final path". Instead, merge-file simply wrote out the
data in the canonical repository representation.
rerere has the same issue, but it is a lot worse. It reads the three
files (preimage, postimage and thisimage) from the work tree in the work
tree representation, merges them without converting them to the canonical
representation first but inserts the conflict markers with the canonical
representation and writes the resulting mess out. It needs to be fixed to
read with convert_to_git(), merge them while they are still in the
canonical representation and possibly add conflict markers, and then write
the results out after convert_to_working_tree(). It also needs to write
in binary mode as well.
* db/foreign-scm (Sun Jan 11 15:12:10 2009 -0500) 3 commits
- Support fetching from foreign VCSes
- Add specification of git-vcs helpers
- Add "vcs" config option in remotes
Daniel seems to have a plan for going forward with this series.
* cc/replace (Mon Feb 2 06:13:06 2009 +0100) 11 commits
- builtin-replace: use "usage_msg_opt" to give better error messages
- parse-options: add new function "usage_msg_opt"
- builtin-replace: teach "git replace" to actually replace
- Add new "git replace" command
- environment: add global variable to disable replacement
- mktag: call "check_sha1_signature" with the replacement sha1
- replace_object: add a test case
- object: call "check_sha1_signature" with the replacement sha1
- sha1_file: add a "read_sha1_file_repl" function
- replace_object: add mechanism to replace objects found in
"refs/replace/"
- refs: add a "for_each_replace_ref" function
I know, I really have to drop everything else and re-read these, but I
haven't managed to.
* js/notes (Wed Feb 18 11:17:27 2009 -0800) 14 commits
- tests: fix "export var=val"
- notes: refuse to edit notes outside refs/notes/
- t3301: use test_must_fail instead of !
- t3301: fix confusing quoting in test for valid notes ref
- notes: use GIT_EDITOR and core.editor over VISUAL/EDITOR
- notes: only clean up message file when editing
- handle empty notes gracefully
- git notes show: test empty notes
- git-notes: fix printing of multi-line notes
- notes: fix core.notesRef documentation
- Add an expensive test for git-notes
- Speed up git notes lookup
- Add a script to edit/inspect notes
- Introduce commit notes
----------------------------------------------------------------
[Actively cooking]
* jc/attributes-checkout (Fri Mar 20 10:32:09 2009 +0100) 2 commits
- Add a test for checking whether gitattributes is honored by
checkout.
- Read attributes from the index that is being checked out
Original issue identified, and test provided by Kristian Amlie.
* fg/push-default (Mon Mar 16 16:42:52 2009 +0100) 2 commits
- Display warning for default git push with no push.default config
+ New config push.default to decide default behavior for push
Replaced the old series with the first step to allow a smooth transition.
Some might argue that this should not give any warning but just give users
this new configuration to play with first, and after we know we are going
to switch default some day, start the warning.
* mg/http-auth (Wed Mar 18 18:46:41 2009 -0500) 6 commits
+ http-push.c: use a faux remote to pass to http_init
+ Do not name "repo" struct "remote" in push_http.c
+ http.c: CURLOPT_NETRC_OPTIONAL is not available in ancient
versions of cURL
+ http authentication via prompts
+ http_init(): Fix config file parsing
+ http.c: style cleanups
Amos King added push side support on top of my fetch side support.
We may want to also pass --remote parameter from git-push to this backend
as Daniel did as an interim solution for the fetch side, so that we can
handle the configuration better.
* db/push-cleanup (Sun Mar 8 21:06:07 2009 -0400) 2 commits
+ Move push matching and reporting logic into transport.c
+ Use a common function to get the pretty name of refs
* kb/tracking-count-no-merges (Wed Mar 4 18:47:39 2009 +0100) 1 commit
+ stat_tracking_info(): only count real commits
This gives the merge commits zero weight when talking about how many
commits you have ahead (or behind) of the branch you are tracking. Even
though I agree that they should carry much less weight than the "real"
commits, because your repeated merge from the other branch does not really
add any real value to the end result, giving them absolute zero weight
somehow feels wrong. At least it shows that your have been _active_ on the
branch. But I do not feel very strongly about it.
----------------------------------------------------------------
[On Hold]
* jc/deny-delete-current-1.7.0 (Mon Feb 9 00:19:46 2009 -0800) 1 commit
- receive-pack: default receive.denyDeleteCurrent to refuse
* jc/refuse-push-to-current-1.7.0 (Wed Feb 11 02:28:03 2009 -0800) 1 commit
- Refuse updating the current branch in a non-bare repository via
push
These are for 1.7.0, but the messages when they trigger together may need
to be rethought.
^ permalink raw reply
* Re: [PATCH v3 0/2] cvsimport: add test illustrating a bug in cvsps
From: Michael Haggerty @ 2009-03-21 5:41 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Junio C Hamano, Heiko Voigt, ydirson, git
In-Reply-To: <49C22166.3000807@drmicha.warpmail.net>
[-- Attachment #1: Type: text/plain, Size: 2628 bytes --]
Michael J Gruber wrote:
> [...]
> Right now this really seems to be going in the direction of: Make
> everyone feel uneasy about working with git on cvs repos at all (aka
> guerilla git), because git cvsimport still seems to be "recommended" or
> "the standard", we have all this talk about how bad it is, and no clear
> alternative.
>
> I wish we had something saying: "If your cvs repo fulfills these
> conditions you can use cvsimport. If not watch out for the following
> (cvsps related) caveats. If you don't need two-way sync you're better of
> with..."
Good idea. Let me try to summarize the situations I have found that can
result in cvsps/cvsimport giving objectively incorrect output. I am
only including the most blatant problems that can cause the content
checked out of git to differ from that checked out of CVS. I have
attached some scripts that illustrate some of the problems that I
haven't yet submitted to the test suite.
Problems known to occur in the conversion of CVS HEAD:
- If any files were ever "cvs import"ed more than once (e.g., import of
more than one vendor release) but not modified locally, then the HEAD
version is incorrect (t9601-cvsimport-vendor-branch.sh).
- If the CVS timestamps on subsequent revisions are out of order (e.g.,
because of clock skew) then file commits can be out of order in git
(e.g. b.txt<1.2> overwritten by b.txt<1.1>). This is demonstrated by
t9603-cvsimport-time.sh.
- If two files ever had what look like cross-cross commits within
cvsps's 5-minute time window (e.g.,
a.txt<1.1> Log message 1
a.txt<1.2> Log message 2
b.txt<1.1> Log message 2
b.txt<1.2> Log message 1
) then the commits of one file will be out of order in git (e.g.
b.txt<1.2> overwritten by b.txt<1.1>). I have a test for this that I
haven't yet submitted.
Problems known to occur in the conversion of CVS branches:
Any of the above problems can occur, plus:
- A branch does not appear in the git repository if no commits were made
on the branch (t01.sh)
- All files from the branching point are added to a branch, including
those that were never added to the branch in CVS. (CVS allows part of a
source tree to be added to a branch/tag.) (t06.sh)
- A file that was added to the source branch *after* a daughter branch
was created but before the first commit on the branch will incorrectly
be added to the daughter branch in git. (t04.sh)
Problems known to occur in the conversion of CVS tags:
Any of the above problems can affect the content of the tag, plus:
- If multiple tags mark the same revision, only one of them is included
in the conversion. (t03.sh)
Michael
[-- Attachment #2: t01.sh --]
[-- Type: application/x-sh, Size: 414 bytes --]
[-- Attachment #3: t06.sh --]
[-- Type: application/x-sh, Size: 678 bytes --]
[-- Attachment #4: t04.sh --]
[-- Type: application/x-sh, Size: 700 bytes --]
[-- Attachment #5: t03.sh --]
[-- Type: application/x-sh, Size: 448 bytes --]
^ permalink raw reply
* Re: [PATCH] Documentation: Reworded example text in git-bisect.txt.
From: Christian Couder @ 2009-03-21 4:28 UTC (permalink / raw)
To: David J. Mellor; +Cc: gitster, git, Michael J Gruber
In-Reply-To: <1237520134-18044-1-git-send-email-dmellor@whistlingcat.com>
Le vendredi 20 mars 2009, David J. Mellor a écrit :
[...]
> @@ -94,14 +95,14 @@ the bisection state).
> Bisect visualize
> ~~~~~~~~~~~~~~~~
>
> -During the bisection process, you issue the command:
> +To see the currently remaining suspects in 'gitk', the following command
> +is issued during the bisection process:
I think it's better to avoid the passive tone, for example like this:
"To see the currently remaining suspects in 'gitk', you issue the following
command during the bisection process:"
> ------------
> $ git bisect visualize
> ------------
[...]
> @@ -173,8 +175,8 @@ using the "'<commit1>'..'<commit2>'" notation. For
> example: $ git bisect skip v2.5..v2.6
> ------------
>
> -would mean that no commit between `v2.5` excluded and `v2.6` included
> -can be tested.
> +The effect of this would be that no commit between `v2.5` excluded and
> +`v2.6` included could be tested.
I'd prefer something like:
"This tells the bisect process that no commit between `v2.5` excluded and
`v2.6` included can be tested."
Otherwise it looks good to me.
Thanks,
Christian.
^ permalink raw reply
* Re: [PATCH 2/2] git-gui: some French translation enhancements
From: Christian Couder @ 2009-03-21 3:54 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Alexandre Bourget, Mike Hommey, Nicolas Sebrecht, Git List,
Sam Hocevar
In-Reply-To: <alpine.LFD.2.00.0903201438570.30483@xanadu.home>
Le vendredi 20 mars 2009, Nicolas Pitre a écrit :
> On Fri, 20 Mar 2009, Alexandre Bourget wrote:
> > Le vendredi 20 mars 2009 à 08:13 +0100, Mike Hommey a écrit :
> > > On Fri, Mar 20, 2009 at 01:54:02AM +0100, Nicolas Sebrecht wrote:
> > > IMHO, we should find a better way to say that than to use the "index"
> > > word at all. This obviously applies to all uses of "index" in french
> > > where we avoided it in english.
> > >
> > > OTOH, the best I can find for "staging area" is "zone de
> > > préparation", and that doesn't help finding a word for stage and
> > > unstage.
> >
> > "zone de préparation" sounds good to me.
>
> What about:
>
> "staging area" -> "zone de regroupement"
> "to stage" -> "regrouper"
> "to unstage" -> "dégrouper"
>
> But admitedly this doesn't convay the actual meaning perfectly either.
What about something like:
"staging area" -> "panier"
"to stage" -> "ajouter au panier"
"to unstage" -> "enlever du panier"
Regards,
Christian.
^ permalink raw reply
* Re: [PATCH 2/2] git-gui: some French translation enhancements
From: Christian Couder @ 2009-03-21 3:48 UTC (permalink / raw)
To: alexandre.bourget; +Cc: Mike Hommey, Nicolas Sebrecht, Git List, Sam Hocevar
In-Reply-To: <1237559694.25283.46.camel@alexandre-desktop>
Le vendredi 20 mars 2009, Alexandre Bourget a écrit :
> Le vendredi 20 mars 2009 à 08:13 +0100, Mike Hommey a écrit :
> > On Fri, Mar 20, 2009 at 01:54:02AM +0100, Nicolas Sebrecht wrote:
> > IMHO, we should find a better way to say that than to use the "index"
> > word at all. This obviously applies to all uses of "index" in french
> > where we avoided it in english.
> >
> > OTOH, the best I can find for "staging area" is "zone de préparation",
> > and that doesn't help finding a word for stage and unstage.
>
> "zone de préparation" sounds good to me.
>
>
> -------------
>
> > [from another e-mail]
> >
> > > We should care that the revert operation does *not* remove a commit
> > > but add a new one (this makes sense to Git). As a consequence, we
> > > should avoid "Annuler", "Révoquer" and "Défaire".
> > >
> > > "Inverser" looks like the best translation.
> >
> > Yeah, I agree with that reasoning.
>
> Hmm.. if you look at the git-gui program, when we use "Revert", it's not
> always the usage of the git-revert command that is invoked.
>
> Most of the time, it's the equivalent of running "git reset --hard", or
> "git checkout path/filename.ext" (in fact, it uses git-checkout-index,
> see git-gui/lib/index.tcl::revert_helper..).
>
> That is true for example in the "Commit" menu, 3rd to last item, which
> reads in french "Inverser les modifications" or "Révoker les
> modifications" as I modified it at some point.
>
> What happens here, is really not inversion of modifications; we're just
> wiping out all changes from the working dir, back to HEAD. Several of
> the translated messages are used in *that* context.
>
>
> So, considering this, which one of: "Annuler", "Révoquer", "Défaire",
> "Effacer", "Restaurer l'original", "Scrapper", "Trucider", "Supprimer" +
> "les modifications" would be best ?
Considering what you said, I think "Annuler" is best, but we really should
remove "(revert)" in "Annuler les modifications (revert)" as it is
definitely misleading translators ;-)
Sam could you please send a newer version of you original patch with the
above change and:
s/Essayez de récupéré/Essayez de récupérer/
s/selectionnés/sélectionnés/
About the index/staging area/adding/staging/unstaging, I think there is not
yet an agreeement about how we should translate that so we should discuss
it further.
Thanks,
Christian.
^ permalink raw reply
* Re: [PATCH] documentation: Makefile accounts for SHELL_PATH setting
From: Jeff King @ 2009-03-21 3:22 UTC (permalink / raw)
To: Ben Walton; +Cc: git
In-Reply-To: <1237603220-22897-1-git-send-email-bwalton@artsci.utoronto.ca>
On Fri, Mar 20, 2009 at 10:40:20PM -0400, Ben Walton wrote:
> Take SHELL_PATH into account, if set, in Documentation/Makefile. This
> allows the caller to provide a shell capable of running the install
> scripts on systems where sh is not bash.
Makes sense.
> +#retain original (but broken) behaviour if SHELL_PATH isn't overridden
> +ifndef SHELL_PATH
> + SHELL_PATH = sh
> +endif
The Makefile in t/Makefile does:
SHELL_PATH ?= $(SHELL)
which I think makes more sense (and yes, yours actually keeps the
existing behavior, but it's probably better to inherit from SHELL in
case it is set to something more useful).
> install-html: html
> - sh ./install-webdoc.sh $(DESTDIR)$(htmldir)
> + $(SHELL_PATH) ./install-webdoc.sh $(DESTDIR)$(htmldir)
You need a SHELL_PATH_SQ to handle paths with spaces; see t/Makefile for
an example.
I wonder if both subdirs should simply be pulling from
GIT-BUILD-OPTIONS, though, which would allow this to use the specified
SHELL_PATH:
$ make SHELL_PATH=whatever
$ cd Documentation && make
but maybe it is not worth caring about (since it may complicate building
Documentation if you _haven't_ build the actual code).
-Peff
^ permalink raw reply
* [PATCH] Allow setting default diff options via diff.defaultOptions
From: Johannes Schindelin @ 2009-03-21 3:15 UTC (permalink / raw)
To: Keith Cascio; +Cc: Jeff King, git
In-Reply-To: <1237600853-22815-1-git-send-email-keith@cs.ucla.edu>
The idea is from Keith Cascio.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
I do not particularly like what this patch does, but I like
the non-intrusiveness and conciseness of it.
Documentation/config.txt | 4 ++++
Documentation/git-diff.txt | 3 +++
builtin-diff.c | 1 +
builtin-log.c | 4 ++++
diff.c | 25 +++++++++++++++++++++++++
diff.h | 2 ++
t/t4037-diff-default-options.sh | 19 +++++++++++++++++++
7 files changed, 58 insertions(+), 0 deletions(-)
create mode 100755 t/t4037-diff-default-options.sh
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 7506755..4913bd6 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -625,6 +625,10 @@ diff.autorefreshindex::
affects only 'git-diff' Porcelain, and not lower level
'diff' commands, such as 'git-diff-files'.
+diff.defaultoptions:
+ The value of this option will be prepended to the command line
+ options of the porcelains showing diffs.
+
diff.external::
If this config variable is set, diff generation is not
performed using the internal diff machinery, but using the
diff --git a/Documentation/git-diff.txt b/Documentation/git-diff.txt
index a2f192f..7025717 100644
--- a/Documentation/git-diff.txt
+++ b/Documentation/git-diff.txt
@@ -74,6 +74,9 @@ and the range notations ("<commit>..<commit>" and
"<commit>\...<commit>") do not mean a range as defined in the
"SPECIFYING RANGES" section in linkgit:git-rev-parse[1].
+Default options can be set via the config variable
+`diff.defaultOptions`.
+
OPTIONS
-------
:git-diff: 1
diff --git a/builtin-diff.c b/builtin-diff.c
index d75d69b..d9a6e7d 100644
--- a/builtin-diff.c
+++ b/builtin-diff.c
@@ -296,6 +296,7 @@ int cmd_diff(int argc, const char **argv, const char *prefix)
if (nongit)
die("Not a git repository");
+ parse_default_diff_options(&rev.diffopt);
argc = setup_revisions(argc, argv, &rev, NULL);
if (!rev.diffopt.output_format) {
rev.diffopt.output_format = DIFF_FORMAT_PATCH;
diff --git a/builtin-log.c b/builtin-log.c
index 8af55d2..2a63652 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -243,6 +243,7 @@ int cmd_whatchanged(int argc, const char **argv, const char *prefix)
init_revisions(&rev, prefix);
rev.diff = 1;
rev.simplify_history = 0;
+ parse_default_diff_options(&rev.diffopt);
cmd_log_init(argc, argv, prefix, &rev);
if (!rev.diffopt.output_format)
rev.diffopt.output_format = DIFF_FORMAT_RAW;
@@ -314,6 +315,7 @@ int cmd_show(int argc, const char **argv, const char *prefix)
rev.always_show_header = 1;
rev.ignore_merges = 0;
rev.no_walk = 1;
+ parse_default_diff_options(&rev.diffopt);
cmd_log_init(argc, argv, prefix, &rev);
count = rev.pending.nr;
@@ -381,6 +383,7 @@ int cmd_log_reflog(int argc, const char **argv, const char *prefix)
init_reflog_walk(&rev.reflog_info);
rev.abbrev_commit = 1;
rev.verbose_header = 1;
+ parse_default_diff_options(&rev.diffopt);
cmd_log_init(argc, argv, prefix, &rev);
/*
@@ -412,6 +415,7 @@ int cmd_log(int argc, const char **argv, const char *prefix)
init_revisions(&rev, prefix);
rev.always_show_header = 1;
+ parse_default_diff_options(&rev.diffopt);
cmd_log_init(argc, argv, prefix, &rev);
return cmd_log_walk(&rev);
}
diff --git a/diff.c b/diff.c
index 75d9fab..0e1b321 100644
--- a/diff.c
+++ b/diff.c
@@ -2657,6 +2657,31 @@ int diff_opt_parse(struct diff_options *options, const char **av, int ac)
return 1;
}
+static int default_diff_options(const char *key, const char *value, void *cb)
+{
+ if (!strcmp(key, "diff.defaultoptions")) {
+ char **options = cb;
+ free(*options);
+ *options = xstrdup(value);
+ }
+ return 0;
+}
+
+void parse_default_diff_options(struct diff_options *options)
+{
+ char *default_options = NULL;
+ const char **argv;
+ int argc;
+
+ git_config(default_diff_options, &default_options);
+ if (!default_options)
+ return;
+
+ argc = split_cmdline(default_options, &argv);
+ diff_opt_parse(options, argv, argc);
+ free(argv);
+}
+
static int parse_num(const char **cp_p)
{
unsigned long num, scale;
diff --git a/diff.h b/diff.h
index 6616877..e05e796 100644
--- a/diff.h
+++ b/diff.h
@@ -270,4 +270,6 @@ extern void diff_no_index(struct rev_info *, int, const char **, int, const char
extern int index_differs_from(const char *def, int diff_flags);
+extern void parse_default_diff_options(struct diff_options *options);
+
#endif /* DIFF_H */
diff --git a/t/t4037-diff-default-options.sh b/t/t4037-diff-default-options.sh
new file mode 100755
index 0000000..0284f7b
--- /dev/null
+++ b/t/t4037-diff-default-options.sh
@@ -0,0 +1,19 @@
+#!/bin/sh
+
+test_description='default options for diff'
+
+. ./test-lib.sh
+
+test_expect_success 'setup' '
+ test_commit a &&
+ test_commit b
+'
+
+test_expect_success 'diff.defaultOptions' '
+ git config diff.defaultOptions --raw &&
+ git diff a > output &&
+ grep ^: output &&
+ test 1 = $(wc -l < output)
+'
+
+test_done
--
1.6.2.1.493.g67cf3
^ permalink raw reply related
* [PATCH] documentation: Makefile accounts for SHELL_PATH setting
From: Ben Walton @ 2009-03-21 2:40 UTC (permalink / raw)
To: git; +Cc: Ben Walton
Take SHELL_PATH into account, if set, in Documentation/Makefile. This
allows the caller to provide a shell capable of running the install
scripts on systems where sh is not bash.
Signed-off-by: Ben Walton <bwalton@artsci.utoronto.ca>
---
Documentation/Makefile | 17 +++++++++++------
1 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 144ec32..2eb5a72 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -67,6 +67,11 @@ ASCIIDOC_EXTRA += -a docbook-xsl-172
MANPAGE_XSL = manpage-1.72.xsl
endif
+#retain original (but broken) behaviour if SHELL_PATH isn't overridden
+ifndef SHELL_PATH
+ SHELL_PATH = sh
+endif
+
#
# Please note that there is a minor bug in asciidoc.
# The version after 6.0.3 _will_ include the patch found here:
@@ -116,7 +121,7 @@ install-pdf: pdf
$(INSTALL) -m 644 user-manual.pdf $(DESTDIR)$(pdfdir)
install-html: html
- sh ./install-webdoc.sh $(DESTDIR)$(htmldir)
+ $(SHELL_PATH) ./install-webdoc.sh $(DESTDIR)$(htmldir)
../GIT-VERSION-FILE: .FORCE-GIT-VERSION-FILE
$(MAKE) -C ../ GIT-VERSION-FILE
@@ -178,7 +183,7 @@ user-manual.xml: user-manual.txt user-manual.conf
technical/api-index.txt: technical/api-index-skel.txt \
technical/api-index.sh $(patsubst %,%.txt,$(API_DOCS))
- cd technical && sh ./api-index.sh
+ cd technical && $(SHELL_PATH) ./api-index.sh
$(patsubst %,%.html,$(API_DOCS) technical/api-index): %.html : %.txt
$(ASCIIDOC) -b xhtml11 -f asciidoc.conf \
@@ -220,7 +225,7 @@ $(patsubst %.txt,%.texi,$(MAN_TXT)): %.texi : %.xml
howto-index.txt: howto-index.sh $(wildcard howto/*.txt)
$(RM) $@+ $@
- sh ./howto-index.sh $(wildcard howto/*.txt) >$@+
+ $(SHELL_PATH) ./howto-index.sh $(wildcard howto/*.txt) >$@+
mv $@+ $@
$(patsubst %,%.html,$(ARTICLES)) : %.html : %.txt
@@ -234,14 +239,14 @@ $(patsubst %.txt,%.html,$(wildcard howto/*.txt)): %.html : %.txt
mv $@+ $@
install-webdoc : html
- sh ./install-webdoc.sh $(WEBDOC_DEST)
+ $(SHELL_PATH) ./install-webdoc.sh $(WEBDOC_DEST)
quick-install: quick-install-man
quick-install-man:
- sh ./install-doc-quick.sh $(DOC_REF) $(DESTDIR)$(mandir)
+ $(SHELL_PATH) ./install-doc-quick.sh $(DOC_REF) $(DESTDIR)$(mandir)
quick-install-html:
- sh ./install-doc-quick.sh $(HTML_REF) $(DESTDIR)$(htmldir)
+ $(SHELL_PATH) ./install-doc-quick.sh $(HTML_REF) $(DESTDIR)$(htmldir)
.PHONY: .FORCE-GIT-VERSION-FILE
--
1.6.0.5
^ permalink raw reply related
* [PATCH] documenation: Makefile accounts for SHELL_PATH setting
From: Ben Walton @ 2009-03-21 2:04 UTC (permalink / raw)
To: git; +Cc: Ben Walton
Take SHELL_PATH into account, if set, in Documentation/Makefile. This
allows the caller to provide a shell capable of running the install
scripts on systems where sh is not bash.
Signed-off-by: Ben Walton <bwalton@artsci.utoronto.ca>
---
Documentation/Makefile | 17 +++++++++++------
1 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 144ec32..2eb5a72 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -67,6 +67,11 @@ ASCIIDOC_EXTRA += -a docbook-xsl-172
MANPAGE_XSL = manpage-1.72.xsl
endif
+#retain original (but broken) behaviour if SHELL_PATH isn't overridden
+ifndef SHELL_PATH
+ SHELL_PATH = sh
+endif
+
#
# Please note that there is a minor bug in asciidoc.
# The version after 6.0.3 _will_ include the patch found here:
@@ -116,7 +121,7 @@ install-pdf: pdf
$(INSTALL) -m 644 user-manual.pdf $(DESTDIR)$(pdfdir)
install-html: html
- sh ./install-webdoc.sh $(DESTDIR)$(htmldir)
+ $(SHELL_PATH) ./install-webdoc.sh $(DESTDIR)$(htmldir)
../GIT-VERSION-FILE: .FORCE-GIT-VERSION-FILE
$(MAKE) -C ../ GIT-VERSION-FILE
@@ -178,7 +183,7 @@ user-manual.xml: user-manual.txt user-manual.conf
technical/api-index.txt: technical/api-index-skel.txt \
technical/api-index.sh $(patsubst %,%.txt,$(API_DOCS))
- cd technical && sh ./api-index.sh
+ cd technical && $(SHELL_PATH) ./api-index.sh
$(patsubst %,%.html,$(API_DOCS) technical/api-index): %.html : %.txt
$(ASCIIDOC) -b xhtml11 -f asciidoc.conf \
@@ -220,7 +225,7 @@ $(patsubst %.txt,%.texi,$(MAN_TXT)): %.texi : %.xml
howto-index.txt: howto-index.sh $(wildcard howto/*.txt)
$(RM) $@+ $@
- sh ./howto-index.sh $(wildcard howto/*.txt) >$@+
+ $(SHELL_PATH) ./howto-index.sh $(wildcard howto/*.txt) >$@+
mv $@+ $@
$(patsubst %,%.html,$(ARTICLES)) : %.html : %.txt
@@ -234,14 +239,14 @@ $(patsubst %.txt,%.html,$(wildcard howto/*.txt)): %.html : %.txt
mv $@+ $@
install-webdoc : html
- sh ./install-webdoc.sh $(WEBDOC_DEST)
+ $(SHELL_PATH) ./install-webdoc.sh $(WEBDOC_DEST)
quick-install: quick-install-man
quick-install-man:
- sh ./install-doc-quick.sh $(DOC_REF) $(DESTDIR)$(mandir)
+ $(SHELL_PATH) ./install-doc-quick.sh $(DOC_REF) $(DESTDIR)$(mandir)
quick-install-html:
- sh ./install-doc-quick.sh $(HTML_REF) $(DESTDIR)$(htmldir)
+ $(SHELL_PATH) ./install-doc-quick.sh $(HTML_REF) $(DESTDIR)$(htmldir)
.PHONY: .FORCE-GIT-VERSION-FILE
--
1.6.0.5
^ permalink raw reply related
* [PATCH/RFC v3] Introduce config variable "diff.defaultoptions"
From: Keith Cascio @ 2009-03-21 2:00 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20090320194930.GB26934@coredump.intra.peff.net>
Improve porcelain diff's accommodation of user preference by allowing any
command-line option to (a) persist over all invocations and (b) stay consistent
over multiple tools (e.g. command-line and gui). The approach taken here is
good because it delivers the consistency a user expects without breaking any
plumbing. It works by allowing the user, via git-config, to specify arbitrary
options to pass to porcelain diff on every invocation, including internal
invocations from other programs, e.g. git-gui.
Introduce diff command-line options --default-options and --no-default-options.
Affect only porcelain diff: we suppress default options for plumbing
diff-{files,index,tree}, format-patch, and all other commands unless explicitly
requested using --default-options (opt-in).
Signed-off-by: Keith Cascio <keith@cs.ucla.edu>
---
Please notice v3 supports all diff options (improvement over v2).
This is a RFC. I omitted the documentation and test portions for now.
-- Keith
diff.h | 17 ++++++--
diff.c | 112 +++++++++++++++++++++++++++++++++++++++++++++++++++++++-
builtin-diff.c | 1 +
builtin-log.c | 1 +
4 files changed, 125 insertions(+), 6 deletions(-)
diff --git a/diff.h b/diff.h
index 6616877..66f1518 100644
--- a/diff.h
+++ b/diff.h
@@ -66,12 +66,17 @@ typedef void (*diff_format_fn_t)(struct diff_queue_struct *q,
#define DIFF_OPT_DIRSTAT_CUMULATIVE (1 << 19)
#define DIFF_OPT_DIRSTAT_BY_FILE (1 << 20)
#define DIFF_OPT_ALLOW_TEXTCONV (1 << 21)
+#define DIFF_OPT_ALLOW_DEFAULT_OPTIONS (1 << 22)
#define DIFF_OPT_TST(opts, flag) ((opts)->flags & DIFF_OPT_##flag)
-#define DIFF_OPT_SET(opts, flag) ((opts)->flags |= DIFF_OPT_##flag)
+#define DIFF_OPT_SET(opts, flag) ((opts)->flags |= DIFF_OPT_##flag),\
+ ((opts)->mask |= DIFF_OPT_##flag)
-#define DIFF_OPT_CLR(opts, flag) ((opts)->flags &= ~DIFF_OPT_##flag)
+#define DIFF_OPT_CLR(opts, flag) ((opts)->flags &= ~DIFF_OPT_##flag),\
+ ((opts)->mask |= DIFF_OPT_##flag)
#define DIFF_XDL_TST(opts, flag) ((opts)->xdl_opts & XDF_##flag)
-#define DIFF_XDL_SET(opts, flag) ((opts)->xdl_opts |= XDF_##flag)
+#define DIFF_XDL_SET(opts, flag) ((opts)->xdl_opts |= XDF_##flag),\
+ ((opts)->xdl_mask |= XDF_##flag)
-#define DIFF_XDL_CLR(opts, flag) ((opts)->xdl_opts &= ~XDF_##flag)
+#define DIFF_XDL_CLR(opts, flag) ((opts)->xdl_opts &= ~XDF_##flag),\
+ ((opts)->xdl_mask |= XDF_##flag)
struct diff_options {
const char *filter;
@@ -80,6 +85,7 @@ struct diff_options {
const char *single_follow;
const char *a_prefix, *b_prefix;
unsigned flags;
+ unsigned mask;
int context;
int interhunkcontext;
int break_opt;
@@ -98,6 +104,7 @@ struct diff_options {
int prefix_length;
const char *stat_sep;
long xdl_opts;
+ long xdl_mask;
int stat_width;
int stat_name_width;
@@ -193,7 +200,7 @@ extern void diff_unmerge(struct diff_options *,
extern int git_diff_basic_config(const char *var, const char *value, void *cb);
extern int git_diff_ui_config(const char *var, const char *value, void *cb);
extern int diff_use_color_default;
-extern void diff_setup(struct diff_options *);
+extern struct diff_options* diff_setup(struct diff_options *);
extern int diff_opt_parse(struct diff_options *, const char **, int);
extern int diff_setup_done(struct diff_options *);
diff --git a/diff.c b/diff.c
index 75d9fab..1c4fec4 100644
--- a/diff.c
+++ b/diff.c
@@ -26,6 +26,8 @@ static int diff_suppress_blank_empty;
int diff_use_color_default = -1;
static const char *diff_word_regex_cfg;
static const char *external_diff_cmd_cfg;
+static const char *diff_defaults;
+static struct diff_options *defaults;
int diff_auto_refresh_index = 1;
static int diff_mnemonic_prefix;
@@ -106,6 +108,8 @@ int git_diff_basic_config(const char *var, const char *value, void *cb)
diff_rename_limit_default = git_config_int(var, value);
return 0;
}
+ if (!strcmp(var, "diff.defaultoptions"))
+ return git_config_string(&diff_defaults, var, value);
switch (userdiff_config(var, value)) {
case 0: break;
@@ -2314,7 +2318,101 @@ static void run_checkdiff(struct diff_filepair *p, struct diff_options *o)
builtin_checkdiff(name, other, attr_path, p->one, p->two, o);
}
+struct diff_options* parse_diff_defaults(struct diff_options *options)
+{
+ int count, len, i;
+ const char **new_argv;
+
+ if ((! diff_defaults) || ((len = (strlen(diff_defaults)+1)) < 3))
+ return options;
+ count = split_cmdline(strncpy(xmalloc(len), diff_defaults, len),
+ &new_argv);
+ for (i=0; i<count; i++)
+ diff_opt_parse(options, &new_argv[i], -1);
+ return options;
+}
+
+#define PRISTINE -0x40
+#define COALESCE_PTR(p) master->p = master->p ? master->p : slave->p
+#define COALESCE_INT(i) master->i = master->i != PRISTINE ? master->i : slave->i
+
+struct diff_options* flatten_diff_options(struct diff_options *master,
+ struct diff_options *slave)
+{
+ /*
+ * Our desired flags are:
+ *
+ * 1. Anything the master hasn't explicitly set, we can take from
+ * the slave.
+ * 2. Anything the slave didn't explicitly set, we can take whether
+ * or not the master set it explicitly.
+ * 3. Anything the master explicitly set, we take.
+ */
+ master->flags =
+ /* (1) */ (~master->mask & slave->flags & slave->mask) |
+ /* (2) */ (master->flags & ~slave->mask) |
+ /* (3) */ (master->flags & master->mask);
+ master->mask |= slave->mask;
+ master->xdl_opts =
+ /* (1) */ (~master->xdl_mask & slave->xdl_opts & slave->xdl_mask) |
+ /* (2) */ (master->xdl_opts & ~slave->xdl_mask) |
+ /* (3) */ (master->xdl_opts & master->xdl_mask);
+ master->xdl_mask |= slave->xdl_mask;
+ master->output_format |= slave->output_format;
+ master->setup |= slave->setup;
+ COALESCE_PTR(a_prefix);
+ COALESCE_PTR(b_prefix);
+ COALESCE_PTR(filter);
+ COALESCE_PTR(orderfile);
+ COALESCE_PTR(pickaxe);
+ COALESCE_PTR(prefix);
+ COALESCE_PTR(single_follow);
+ COALESCE_PTR(stat_sep);
+ COALESCE_PTR(word_regex);
+ COALESCE_INT(abbrev);
+ COALESCE_INT(break_opt);
+ COALESCE_INT(close_file);
+ COALESCE_INT(context);
+ COALESCE_INT(detect_rename);
+ COALESCE_INT(dirstat_percent);
+ COALESCE_INT(interhunkcontext);
+ COALESCE_INT(line_termination);
+ COALESCE_INT(pickaxe_opts);
+ COALESCE_INT(prefix_length);
+ COALESCE_INT(rename_limit);
+ COALESCE_INT(rename_score);
+ COALESCE_INT(skip_stat_unmatch);
+ COALESCE_INT(stat_name_width);
+ COALESCE_INT(stat_width);
+ COALESCE_INT(warn_on_too_large_rename);
+ COALESCE_PTR(file);
+ COALESCE_PTR(change);
+ COALESCE_PTR(add_remove);
+ COALESCE_PTR(format_callback);
+ COALESCE_PTR(format_callback_data);
+ if((! master->paths) && slave->paths){
+ master->nr_paths = slave->nr_paths;
+ master->paths = slave->paths;
+ master->pathlens = slave->pathlens;
+ }
+ return master;
+}
+
-void diff_setup(struct diff_options *options)
+struct diff_options* diff_setup(struct diff_options *options)
+{
+ memset(options, 0, sizeof(*options));
+ options->abbrev = options->break_opt = options->close_file =
+ options->context = options->detect_rename =
+ options->dirstat_percent = options->interhunkcontext =
+ options->line_termination = options->pickaxe_opts =
+ options->prefix_length = options->rename_limit =
+ options->rename_score = options->skip_stat_unmatch =
+ options->stat_name_width = options->stat_width =
+ options->warn_on_too_large_rename = PRISTINE;
+ return options;
+}
+
+struct diff_options* diff_fallback_values(struct diff_options *options)
{
memset(options, 0, sizeof(*options));
@@ -2336,11 +2434,19 @@ void diff_setup(struct diff_options *options)
options->a_prefix = "a/";
options->b_prefix = "b/";
}
+ return options;
}
int diff_setup_done(struct diff_options *options)
{
int count = 0;
+ struct diff_options fallback;
+
+ if (DIFF_OPT_TST(options, ALLOW_DEFAULT_OPTIONS))
+ flatten_diff_options(options, defaults ? defaults :
+ parse_diff_defaults(diff_setup(defaults =
+ xmalloc(sizeof(struct diff_options)))));
+ flatten_diff_options(options, diff_fallback_values(&fallback));
if (options->output_format & DIFF_FORMAT_NAME)
count++;
@@ -2615,6 +2721,10 @@ int diff_opt_parse(struct diff_options *options, const char **av, int ac)
DIFF_OPT_CLR(options, ALLOW_TEXTCONV);
else if (!strcmp(arg, "--ignore-submodules"))
DIFF_OPT_SET(options, IGNORE_SUBMODULES);
+ else if (!strcmp(arg, "--default-options"))
+ DIFF_OPT_SET(options, ALLOW_DEFAULT_OPTIONS);
+ else if (!strcmp(arg, "--no-default-options"))
+ DIFF_OPT_CLR(options, ALLOW_DEFAULT_OPTIONS);
/* misc options */
else if (!strcmp(arg, "-z"))
diff --git a/builtin-diff.c b/builtin-diff.c
index d75d69b..34c6ce2 100644
--- a/builtin-diff.c
+++ b/builtin-diff.c
@@ -283,6 +283,7 @@ int cmd_diff(int argc, const char **argv, const char *prefix)
diff_use_color_default = git_use_color_default;
init_revisions(&rev, prefix);
+ DIFF_OPT_SET(&rev.diffopt, ALLOW_DEFAULT_OPTIONS);
/* If this is a no-index diff, just run it and exit there. */
diff_no_index(&rev, argc, argv, nongit, prefix);
diff --git a/builtin-log.c b/builtin-log.c
index 8af55d2..1fa583f 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -37,6 +37,7 @@ static void cmd_log_init(int argc, const char **argv, const char *prefix,
get_commit_format(fmt_pretty, rev);
rev->verbose_header = 1;
DIFF_OPT_SET(&rev->diffopt, RECURSIVE);
+ DIFF_OPT_SET(&rev->diffopt, ALLOW_DEFAULT_OPTIONS);
rev->show_root_diff = default_show_root;
rev->subject_prefix = fmt_patch_subject_prefix;
DIFF_OPT_SET(&rev->diffopt, ALLOW_TEXTCONV);
--
1.6.2.1.337.g3b73.dirty
^ permalink raw reply related
* Re: [PATCH v4] Introduce %<branch> as shortcut to the tracked branch
From: Miles Bader @ 2009-03-21 1:10 UTC (permalink / raw)
To: git
In-Reply-To: <200903210135.33729.agruen@suse.de>
Andreas Gruenbacher <agruen@suse.de> writes:
> To me the most obvious escape sequence would be \x for disabling whatever
> special meaning x has (for non-alphabetic x). With quoting you likely
> eventually end up needing \' in some cases anyway...
I think it's a good idea to _avoid_ using backslash as an escape when
possible -- the potential for confusion and screwups from multiple
layers all interpreting backslash should be familiar to most people
here... (single-quote suffers from the same problem a bit, but at least
it's not quite as overused as backslash)
-Miles
--
One of the lessons of history is that nothing is often a good thing to
do, and always a clever thing to say. -- Will Durant
^ permalink raw reply
* Re: [PATCH v4] Introduce %<branch> as shortcut to the tracked branch
From: Andreas Gruenbacher @ 2009-03-21 0:35 UTC (permalink / raw)
To: Julian Phillips
Cc: Junio C Hamano, Johannes Schindelin, Shawn O. Pearce, Petr Baudis,
B.Steinbrink, git
In-Reply-To: <alpine.LNX.2.00.0903202300330.13726@reaper.quantumfyre.co.uk>
On Saturday, 21 March 2009 0:08:42 Julian Phillips wrote:
> How about adding a generic escape hatch, that would cover this and
> future extensions?
>
> Let a ref that starts with a single quote be taken as given and not
> processed. You have to escape it to get it past the shell, but that makes
> it rather unlikely that anyone has used a name that starts with a quote -
> and if they have you can still use this mechanism to rename it.
To me the most obvious escape sequence would be \x for disabling whatever
special meaning x has (for non-alphabetic x). With quoting you likely
eventually end up needing \' in some cases anyway...
Andreas
^ permalink raw reply
* Re: [PATCH v4] Introduce %<branch> as shortcut to the tracked branch
From: Sverre Rabbelier @ 2009-03-20 23:45 UTC (permalink / raw)
To: Julian Phillips
Cc: Junio C Hamano, Johannes Schindelin, Shawn O. Pearce, Petr Baudis,
Andreas Gruenbacher, B.Steinbrink, git
In-Reply-To: <alpine.LNX.2.00.0903202324170.13726@reaper.quantumfyre.co.uk>
Heya,
On Sat, Mar 21, 2009 at 00:41, Julian Phillips <julian@quantumfyre.co.uk> wrote:
> To use the new syntax you type %master only. What I was proposing was a way
> to get at the branch that you had before the wizzy new feature was added.
> Something you only do once to rename it - why waste an easy to type
> sequence on that?
Oooooh, sorry, I totally understood your suggestion the wrong way
around! In that case, I like it! :)
> I agree that adding some more reserved characters is a reasonable way
> forward - but I think a way should be provided for people who are _already_
> using those characters to rename their branches to something that avoids
> those characters in a simple (but not necessarily easy to type) way.
Your suggestion on how to escape the DWIMery sounds sane to me :).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH v4] Introduce %<branch> as shortcut to the tracked branch
From: Julian Phillips @ 2009-03-20 23:41 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Junio C Hamano, Johannes Schindelin, Shawn O. Pearce, Petr Baudis,
Andreas Gruenbacher, B.Steinbrink, git
In-Reply-To: <fabb9a1e0903201620l456bfc39n2422dcb1e738eb37@mail.gmail.com>
On Sat, 21 Mar 2009, Sverre Rabbelier wrote:
> Heya,
>
> On Sat, Mar 21, 2009 at 00:08, Julian Phillips <julian@quantumfyre.co.uk> wrote:
>> git branch -m "'%master" percent-master
>
> Which kinda defeats the purpose of having a short-and-easy-to-write
> refname, no? "'%master" is not that easy to type, I at least get my
> fingers mixed up in the "'% sequence. Perhaps we should reserve these
> special characters now, and deprecate their use? Junio seemed to be
> open to that (quoted below)...
But it's not supposed to be easy to type ...
To use the new syntax you type %master only. What I was proposing was a
way to get at the branch that you had before the wizzy new feature was
added. Something you only do once to rename it - why waste an easy to
type sequence on that?
I agree that adding some more reserved characters is a reasonable way
forward - but I think a way should be provided for people who are
_already_ using those characters to rename their branches to something that
avoids those characters in a simple (but not necessarily easy to type)
way.
--
Julian
---
panic("%s: CORRUPTED BTREE OR SOMETHING", __FUNCTION__);
linux-2.6.6/fs/xfs/xfs_bmap.c
^ permalink raw reply
* Re: [PATCH v4] Introduce %<branch> as shortcut to the tracked branch
From: Sverre Rabbelier @ 2009-03-20 23:20 UTC (permalink / raw)
To: Julian Phillips
Cc: Junio C Hamano, Johannes Schindelin, Shawn O. Pearce, Petr Baudis,
Andreas Gruenbacher, B.Steinbrink, git
In-Reply-To: <alpine.LNX.2.00.0903202300330.13726@reaper.quantumfyre.co.uk>
Heya,
On Sat, Mar 21, 2009 at 00:08, Julian Phillips <julian@quantumfyre.co.uk> wrote:
> git branch -m "'%master" percent-master
Which kinda defeats the purpose of having a short-and-easy-to-write
refname, no? "'%master" is not that easy to type, I at least get my
fingers mixed up in the "'% sequence. Perhaps we should reserve these
special characters now, and deprecate their use? Junio seemed to be
open to that (quoted below)...
> Just be honest and say "You may have a branch whose name begins with a '%'
> and you cannot refer to it anymore in certain contexts. Too bad. Don't
> do it next time you create a new branch". I _can_ buy that argument.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH v4] Introduce %<branch> as shortcut to the tracked branch
From: Julian Phillips @ 2009-03-20 23:08 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Shawn O. Pearce, Petr Baudis,
Andreas Gruenbacher, B.Steinbrink, git
In-Reply-To: <7v7i2ki0sw.fsf@gitster.siamese.dyndns.org>
On Fri, 20 Mar 2009, Junio C Hamano wrote:
> An most obvious one is that "git checkout branchname" and "git checkout
> refs/heads/branchname" behave differently. You cannot checkout a branch
> called %master after this patch goes in.
>
> Just be honest and say "You may have a branch whose name begins with a '%'
> and you cannot refer to it anymore in certain contexts. Too bad. Don't
> do it next time you create a new branch". I _can_ buy that argument.
>
> It however asks for a sane escape hatch. You cannot "fix" such branch
> names in most obvious ways (if you could, that would be a bug in this %
> feature).
>
> (1) git branch -m %master percent-master
>
> We would end up renaming what master tracks to new name.
>
> (2) git branch percent-master refs/heads/%master; git branch -d %master
>
> The first part is a good try, but the latter deletes what master
> tracks.
How about adding a generic escape hatch, that would cover this and
future extensions?
Let a ref that starts with a single quote be taken as given and not
processed. You have to escape it to get it past the shell, but that makes
it rather unlikely that anyone has used a name that starts with a quote -
and if they have you can still use this mechanism to rename it.
So now (1) above could be written:
git branch -m "'%master" percent-master
and other commands, such as
git branch -d "'%master"
or
git checkout "'%master"
would also do the right thing (i.e. use refs/heads/%master as a branch).
--
Julian
---
Stewie Griffin: [looking in the fridge for a drink] Soda... purple stuff... Sunny D, all right!
^ permalink raw reply
* Re: Minimum libCurl version for git
From: Junio C Hamano @ 2009-03-20 22:58 UTC (permalink / raw)
To: Mike Ralphson; +Cc: Daniel Stenberg, git list, Nick Hengeveld, Mike Hommey
In-Reply-To: <alpine.DEB.1.10.0903202316170.2600@yvahk2.pbagnpgbe.fr>
Daniel Stenberg <daniel@haxx.se> writes:
> On Fri, 20 Mar 2009, Junio C Hamano wrote:
>
>> For non-commercial Linux folks I think it should be Ok to assume not
>> too ancient libcurl, but I have no clue on how the table like the
>> above would look like for things like AIX, IRIX, HPUX etc. ... Oh,
>> and SCO.
>
> The oldest libcurl version I know is still being distributed to and
> therefor used by people is one IBM provides for AIX, and that is 7.9.3
> - dated "Jan 23 2002".
Thanks for the definitive words, Daniel.
Mike, I'd say we declare 7.9.3 as the floor and go from there. That's
your #3, I think.
^ permalink raw reply
* Re: Minimum libCurl version for git
From: Daniel Stenberg @ 2009-03-20 22:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Mike Ralphson, git list, Nick Hengeveld, Mike Hommey
In-Reply-To: <7vy6uzg98v.fsf@gitster.siamese.dyndns.org>
On Fri, 20 Mar 2009, Junio C Hamano wrote:
> For non-commercial Linux folks I think it should be Ok to assume not too
> ancient libcurl, but I have no clue on how the table like the above would
> look like for things like AIX, IRIX, HPUX etc. ... Oh, and SCO.
The oldest libcurl version I know is still being distributed to and therefor
used by people is one IBM provides for AIX, and that is 7.9.3 - dated "Jan 23
2002".
--
/ daniel.haxx.se
^ permalink raw reply
* Re: How to commit changes if remote repository changed directory structure?
From: J. Bruce Fields @ 2009-03-20 22:30 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, andholt, git
In-Reply-To: <20090320071319.GF27008@coredump.intra.peff.net>
On Fri, Mar 20, 2009 at 03:13:19AM -0400, Jeff King wrote:
> On Fri, Mar 20, 2009 at 12:08:51AM -0700, Junio C Hamano wrote:
>
> > > First, commit your changes. Then merge the other developer's changes. :)
> >
> > We should probably point out to new people that "first commit and then
> > worry about merges after your changes are safely committed" is always how
> > people would "go about" anything.
>
> Yes, absolutely.
>
> Most of the current documentation focuses on being a reference to
> particular commands or tasks. But this is more of a "philosophy of
> working with git" item. I guess it should go in the user manual
> somewhere. Cc'ing Bruce, who may have some comments.
I agree, that's kind of an odd hold in the user manual. Maybe it goes
without saying, but it might be useful somewhere in ch. 3, maybe when
introducing commits, something along the lines of: "note all of these
commits are stored only in your local repository, and are visible only
to you. With some version control systems, "committing" requires
sending the commit to a central server. With git, you are expected to
do all your work locally and only merge with others' work when
necessary; we'll learn how to do that in <chapter 4>."
And then say something similar again at the start of chapter 4?
--b.
^ permalink raw reply
* Re: [PATCH] Introduce a filter-path argument to git-daemon, for doing custom path transformations
From: Johannes Schindelin @ 2009-03-20 22:27 UTC (permalink / raw)
To: Johan Sørensen; +Cc: Junio C Hamano, git
In-Reply-To: <9e0f31700903190602h569a3d18y30477c7a136d875e@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2242 bytes --]
Hi,
On Thu, 19 Mar 2009, Johan Sørensen wrote:
> 2009/3/19 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> >> I actually was hoping (especially we have Dscho on Cc: list) that
> >> somebody like you would start suggesting a "plug in" approach to load
> >> .so files, which would lead to a easy-to-port dso support with the
> >> help from msysgit folks we can use later in other parts of the system
> >> (e.g. customizable filters used for diff textconv, clean/smudge,
> >> etc.)
> >
> > I do not like that at all. Dynamic libraries -- especially on Windows
> > -- are a major hassle.
> >
> > However, I cannot think of anything Johan might want to do that would
> > not be possible using a bunch of regular expressions together with
> > substitions.
>
> Let me reiterate my use-case then: I need to dynamically substitute one
> path with another. Perhaps "map" paints a better picture than
> "substitute" here. Please refer to my second mail in this thread for
> more details.
>
> The only way I can see regexps work, is that if they're read, on a
> per-request basis (reloading git-daemon every time they change is just
> silly), from somewhere outside the git-daemon. Then, you might as well
> take the full-on approach this patch provides.
>
> > FWIW I have experimental code in my personal tree that sports
> > strbuf_regsub(), a function to replace matches of a regular expression
> > (possibly with groups) by a given string (which may contain \0 .. \9,
> > being replaced with the respective group's contents).
Do not get me wrong, I can see your use case.
But I have been cautioning against other possibly regrettably things, and
it gave me _no_ pleasure at all to be proven correct in hindsight.
I'd rather be called grumpy old Git, be ridiculed and insulted, but at the
same time have precautions in git.git that prevent having to admit
mournfully that some change was not so brilliant after all.
So if some rules consisting of regular expressions with appropriate
substitutions, even if they will have to be updated from time to time,
solve your case, I'd rather have that than allow a server to run external
programs that are not exactly well audited against all kinds of attacks.
Ciao,
Dscho
^ permalink raw reply
* Re: Minimum libCurl version for git
From: Daniel Stenberg @ 2009-03-20 22:15 UTC (permalink / raw)
To: Mike Ralphson; +Cc: git list
In-Reply-To: <e2b179460903201059j20e37c1cr7ccfa4b42e45c9d9@mail.gmail.com>
On Fri, 20 Mar 2009, Mike Ralphson wrote:
> According to Daniel's list [1], CURLOPT_SSLKEY was introduced in 7.9.3, but
> we enable it in http.c if we see version >= 7.9.2. This could be a typo in
> the haxx.se list, or the option could have been available in (some) 7.9.2
> releases, or it could be a git bug. Again, not one which appears to be
> biting anyone.
I double-checked now against the changelog and it confirms that the info is
correct in that file: CURLOPT_SSLKEY was introduced in 7.9.3. It was first
released in a pre-release Jan 8th 2002.
I'd assume that very few git-builders have such an old libcurl installed...
--
/ daniel.haxx.se
^ permalink raw reply
* Re: Minimum libCurl version for git
From: Mike Hommey @ 2009-03-20 22:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Mike Ralphson, git list, Daniel Stenberg, Nick Hengeveld
In-Reply-To: <7vy6uzg98v.fsf@gitster.siamese.dyndns.org>
On Fri, Mar 20, 2009 at 02:44:16PM -0700, Junio C Hamano wrote:
> Mike Ralphson <mike.ralphson@gmail.com> writes:
>
> > Going forward there are various options:
> >
> > 1. Do nothing - go with the status quo.
> >
> > 2. Correct the #ifdefs for CURLOPT_SSLKEY
> >
> > 3. Drop the #ifdefs for CURLOPT_SSLKEY entirely and make 7.9.3 our
> > minimum supported version. I feel slightly embarrassed about that, as
> > that's exactly the version I have here on AIX (unless I wrest it back
> > from being sysadmin-installed to being user-supported). Add a check to
> > the Makefile and error if libCurl is too old.
> >
> > 4. Drop all current #ifdefs and one of the deprecated symbol names.
> > Our minimum supported libCurl version would be 7.9.8 from Jun 2002.
> >
> > 5. Drop all current #ifdefs and both of the deprecated symbol names.
> > Our minimum supported libCurl version would be 7.10.8 from Nov 2003.
> >
> > 6. Warn (not error) if libCurl is older than say the 3 years suggested
> > by Daniel. This would seem to require periodic updates to the Makefile
> > check.
> >
> > I'm happy to whip up a patch if required, but I thought a series of
> > mutually-exclusive alternative patches would be confusing without
> > prior agreement on the approach.
> >
> > Mike
> >
> > [1] http://cool.haxx.se/cvs.cgi/curl/docs/libcurl/symbols-in-versions?rev=HEAD&content-type=text/vnd.viewcvs-markup
>
> Thanks for a detailed analysis.
>
> My gut feeling is we should be able to do 3 safely.
>
> I am not sure if you are reading the "deprecated" column correctly,
> though:
>
> Name Introduced Deprecated Removed
> CURLINFO_HTTP_CODE 7.4.1 7.10.8
> CURLOPT_INFILE 7.1 7.9.7
>
> These two symbols are what we do use in our code, so the
> deprecated/removed column would give us the upper bound of the versions,
> not the lower bound.
>
> We can have these two macro definitions on our side
>
> #if curl older than 7.10.8
> #define CURLINFO_RESPONSE_CODE CURLINFO_HTTP_CODE
> #endif
>
> #if curl older than 7.9.7
> #define CURLOPT_READDATA CURLOPT_INFILE
> #endif
>
> for backward compatibility, while writing our code to the recent API by
> using CURLINFO_RESPONSE_CODE and CURLOPT_READDATA, and people with older
> curl would not have to suffer a bit.
>
> So I think your 4 and 5 are non issues.
>
> But this is without having a handy tally of what releases of various
> distros shipped their libcurl with. If we had a table like this...
>
> Distro Last update libcurl version
> ----------------------------------------------------------------
> Debian 3.1 sarge 2005-06-06 ???
> Debian 4.0 etch 2009-02-10 (4.0r7) 7.15.5
> Debian 5.0 lenny 2009-02-14 7.18.2
>
> ... then we could say "This is git, a tool primarily for developers to
> keep track of sources; nobody would be running on a box that was updated
> the last time four years ago, so we can safely assume libcurl more recent
> than version ???".
>
> It would also be valid to argue that "4.0 etch may have been updated last
> month, but libcurl 7.15.5 has been available on the release a lot before
> that, as of 200X-XX-XX, which is more than N years ago, which makes it
> safe to assume that assuming 7.15.5 or later is fine for Debian folks; do
> not get fooled by the date of last update," in which case it would be good
> to have entry for the original release date.
Original release date for etch is 2007-04-08.
Sarge was released with libcurl 7.13.2.
Woody, which was Debian 3.0, and can be considered dead already, was
released on 2002-07-19 with libcurl 7.9.5.
Mike
^ permalink raw reply
* Re: [PATCH] rebase -p: Preserve --no-ff merges
From: Johannes Schindelin @ 2009-03-20 22:04 UTC (permalink / raw)
To: Anders Kaseorg; +Cc: gitster, git
In-Reply-To: <alpine.DEB.2.00.0903201633440.4457@vinegar-pot.mit.edu>
Hi,
On Fri, 20 Mar 2009, Anders Kaseorg wrote:
> Previously, git rebase -p would turn some merges that had been constructed
> with git merge --no-ff into fast-forwards. Now it reconstructs those
> merges using --no-ff as well.
>
> Signed-off-by: Anders Kaseorg <andersk@mit.edu>
> ---
First, could I ask you to hold off with patches for rebase -p for a little
while? I did a _lot_ of work on rebase -p recently, but it has not
reached a state that I can submit yet without being ashamed.
Another thing to keep in mind is that some merges do _not_ want to be
preserved. IOW if you have a history like this:
- A - B
\ \
C - D - E
And your upstream cherry-picked B, after a rebase you are most likely to
want
- A' - C' - E'
as a result (rather than
- A' - --
\ \
C' - D' - E'
which would be rather awkward).
Ciao,
Dscho
P.S.: FWIW you can see my work as part of my 'master' in
http://repo.or.cz/w/git/dscho.git/
^ permalink raw reply
* Re: ref name troubles, was Re: [PATCH v2] Introduce %<branch> as shortcut to the tracked branch
From: Johannes Schindelin @ 2009-03-20 21:48 UTC (permalink / raw)
To: Daniel Barkalow
Cc: Junio C Hamano, Petr Baudis, Jeff King, Shawn O. Pearce,
Andreas Gruenbacher, git
In-Reply-To: <alpine.LNX.1.00.0903201515490.19665@iabervon.org>
Hi,
On Fri, 20 Mar 2009, Daniel Barkalow wrote:
> On Fri, 20 Mar 2009, Junio C Hamano wrote:
>
> > Petr Baudis <pasky@suse.cz> writes:
> >
> > >> "git branch" I agree with, but not "git update-ref". As plumbing,
> > >> the latter should be much more allowing, feeding rope aplenty (but
> > >> also allowing cool tricks we do not think about yet).
> > >
> > > We shouldn't allow creating insane ref names even with update-ref.
> > > That way porcelains cannot rely on update-ref to sanity check the
> > > user's crap. At most, maybe you might want to bypass this check with
> > > some force switch, though I really can't quite imagine why.
> >
> > That's all nice and clean in theory, but it was more or less the same
> > reasoning as what was behind the tightening not to allow anything but
> > refs/heads pointed by HEAD, but you know what fell out of it.
> > "Insane" and "crap" are in the eye of the beholder.
>
> I think there's no possible use to being able to use update-ref to
> create a ref that rev-parse can't be made to read. I think people will
> want to do all sorts of things that are insane (I'd personally like some
> refs with the basename "..."), but they're only likely to do insane
> things that happen to work, rather than insane things that aren't
> prevented but still don't work.
Of course, you are forgetting that rev-parse may well have been able to
grok such a ref at some stage.
And at that stage, it becomes not a user error, but a _huge_ mistake by
us, the Git developers.
Don't blame the user
(http://www.schneier.com/blog/archives/2009/03/it_security_bla.html).
Ciao,
Dscho
^ 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