* Re: [PATCH] grep: --full-tree
From: Johannes Schindelin @ 2009-11-29 10:28 UTC (permalink / raw)
To: Jeff King; +Cc: James Pickens, Junio C Hamano, git
In-Reply-To: <20091127210530.GC26921@coredump.intra.peff.net>
Hi,
On Fri, 27 Nov 2009, Jeff King wrote:
> On Fri, Nov 27, 2009 at 09:07:51PM +0100, Johannes Schindelin wrote:
>
> > > Yes, as a matter of fact, I do work on 10 different computers. I'm sorry
> > > that you find managing your configuration so challenging. But if you
> > > don't use the configuration variable, then your own personal setup is
> > > totally irrelevant.
> >
> > As I just demonstrated, this is a false statement.
>
> I must have missed where you demonstrated it.
Usually, my mails are minimal, and I do not write as many mails as I
used to anymore, so it is hard to miss what I am saying.
For your benefit: both Junio and me talked about experts helping users.
Even if I do not use the config options, I am affected. And it does hurt.
> > > If your argument is that this lack of consistency will irritate users,
> > > you need to show that:
> > >
> > > 1. There are users who switch between a large number of setups, but
> > > will not apply config consistently.
> >
> > This is a strawman, and you should be ashamed to put it here. Just
>
> How is this a strawman?
You are comparing config settings which must be different, because they
affect _what_ project you are working with, with config settings that
affect _how_ you can work with them.
> When the number of "git grep" crash fatalities rises above zero, maybe
> this line of reasoning will be relevant.
Sure. Let's wait for the first crash fatality, and only react then. No
need to think ahead.
That's it. I don't think that I want to participate in this kind of
discussion anymore,
Dscho
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Johannes Schindelin @ 2009-11-29 10:21 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, James Pickens, git
In-Reply-To: <20091127205004.GA26921@coredump.intra.peff.net>
Hi,
On Fri, 27 Nov 2009, Jeff King wrote:
> On Fri, Nov 27, 2009 at 10:29:11AM -0800, Junio C Hamano wrote:
>
> > > If only somebody had written a "pager.status" configuration variable,
> > > you could use that. Oh wait. I did. And it shipped in v1.6.0.
> >
> > Nice try but, "grep" and "status" are apples and oranges comparision.
>
> Yes, I think you are right that the existence of pager.* does not
> necessarily imply that there should be a config option for grep. But
> that makes his example even more irrelevant: he is advocating that I use
> a solution in this instance because he uses it in another instance, when
> that solution is not even necessary in the other instance (and as I have
> hopefully already made clear, is in my opinion inferior).
Sorry, no, you got it all wrong.
My point was that your config option introduced something _BAD_. And my
point was that now, as a consequence of having managed to put it into Git,
you want more of such bad stuff.
You continue to ignore that inconsistency -- even if it is introduced with
the best of all intentions -- is bad, bad, bad.
But I guess that I continue to get ignored,
Dscho
^ permalink raw reply
* What's cooking in git.git (Nov 2009, #07; Sun, 29)
From: Junio C Hamano @ 2009-11-29 10:05 UTC (permalink / raw)
To: git
This will be the last update before deciding what should go in 1.6.6-rc1
and describes my current thinking.
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 integration branches, but I am
still holding onto them.
In 1.7.0, we plan to correct handful of warts in the interfaces everybody
agrees that they were mistakes. The resulting system may not be strictly
backward compatible. Currently planned changes are:
* refuse push to update the checked out branch in a non-bare repo by
default
Make "git push" into a repository to update the branch that is checked
out fail by default. You can countermand this default by setting a
configuration variable in the receiving repository.
http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007
* refuse push to delete the current branch by default
Make "git push $there :$killed" to delete the branch that is pointed at
by its HEAD fail by default. You can countermand this default by
setting a configuration variable in the receiving repository.
http://thread.gmane.org/gmane.comp.version-control.git/108862/focus=108936
* "git send-email" won't make deep threads by default
Many people said that by default when sending more than 2 patches the
threading git-send-email makes by default is hard to read, and they
prefer the default be one cover letter and each patch as a direct
follow-up to the cover letter. You can countermand this by setting a
configuration variable.
http://article.gmane.org/gmane.comp.version-control.git/109790
* "git status" won't be "git-commit --dry-run" anymore
http://thread.gmane.org/gmane.comp.version-control.git/125989/focus=125993
* "git diff -w --exit-code" will exit success if only differences it
found are whitespace changes that are stripped away from the output.
http://thread.gmane.org/gmane.comp.version-control.git/119731/focus=119751
* "git diff -w/-b" won't even produce "diff --git" header when all changes
are about whitespaces.
http://thread.gmane.org/gmane.comp.version-control.git/133256
--------------------------------------------------
[New Topics]
* fc/maint-format-patch-pathspec-dashes (2009-11-26) 2 commits.
- format-patch: add test for parsing of "--"
- format-patch: fix parsing of "--" on the command line
* bw/diff-color-hunk-header (2009-11-27) 2 commits
(merged to 'next' on 2009-11-29 at c446977)
+ Give the hunk comment its own color
(merged to 'next' on 2009-11-27 at 42ab131)
+ emit_line(): don't emit an empty <SET><RESET> followed by a newline
* jc/maint-am-keep (2009-11-27) 1 commit.
(merged to 'next' on 2009-11-27 at 7663874)
+ Remove dead code from "git am"
* tr/http-updates (2009-11-27) 2 commits
- Add an option for using any HTTP authentication scheme, not only basic
- http: maintain curl sessions
* jc/diff-whitespace-prepare (2009-11-28) 2 commits
- diff: flip the default diff.bwoutputonly to true
- diff: optionally allow traditional "-b/-w affects only output" semantics
(this branch uses gb/1.7.0-diff-whitespace-only-output and jc/1.7.0-diff-whitespace-only-status; is used by jc/1.7.0-diff-whitespace-prepare.)
This is to redo the two -b/-w semantic changes to prepare the migration of
existing users before 1.7.0 happens.
* jc/1.7.0-diff-whitespace-prepare (2009-11-28) 2 commits
- diff: disable diff.bwoutputonly warning
- diff: flip the diff.bwoutputonly default to false
(this branch uses gb/1.7.0-diff-whitespace-only-output, jc/1.7.0-diff-whitespace-only-status and jc/diff-whitespace-prepare.)
And this is to actually flip the default and eventually remove the warning.
* ns/send-email-no-chain-reply-to (2009-11-29) 1 commit
- prepare send-email for smoother change of --chain-reply-to default
(this branch is used by ns/1.7.0-send-email-no-chain-reply-to.)
Similarly, this is to start warning about the change to --no-chain-reply-to
in 1.7.0 for smoother transition.
* ns/1.7.0-send-email-no-chain-reply-to (2009-08-22) 1 commit
- send-email: make --no-chain-reply-to the default
(this branch uses ns/send-email-no-chain-reply-to.)
And this is to actually flip the default in 1.7.0.
--------------------------------------------------
[Stalled]
* je/send-email-no-subject (2009-08-05) 1 commit.
(merged to 'next' on 2009-10-11 at 1b99c56)
+ send-email: confirm on empty mail subjects
The existing tests cover the positive case (i.e. as long as the user says
"yes" to the "do you really want to send this message that lacks subject",
the message is sent) of this feature, but the feature itself needs its own
test to verify the negative case (i.e. does it correctly stop if the user
says "no"?)
* jn/rfc-pull-rebase-error-message (2009-11-12) 1 commit
- git-pull.sh --rebase: overhaul error handling when no candidates are found
I heard this needs at least retitling among other changes?
* jh/notes (2009-11-20) 10 commits
- Add more testcases to test fast-import of notes
- Rename t9301 to t9350, to make room for more fast-import tests
- fast-import: Proper notes tree manipulation using the notes API
- Refactor notes concatenation into a flexible interface for combining notes
- Notes API: Allow multiple concurrent notes trees with new struct notes_tree
- Notes API: for_each_note(): Traverse the entire notes tree with a callback
- Notes API: get_note(): Return the note annotating the given object
- Notes API: add_note(): Add note objects to the internal notes tree structure
- Notes API: init_notes(): Initialize the notes tree from the given notes ref
- Notes API: get_commit_notes() -> format_note() + remove the commit restriction
Johan waits for an Ack from Shawn on "fast-import" one.
* tr/maint-merge-ours-clarification (2009-11-15) 1 commit
(merged to 'next' on 2009-11-21 at fadaf7b)
+ rebase: refuse to rebase with -s ours
I do not think we reached a concensus for solving conflicts between "give
them rope" and "protect users from clearly meaningless combinations". The
author obviously is for the latter (and I am inclined to agree); Dscho
seems to think otherwise.
* jc/fix-tree-walk (2009-10-22) 8 commits
(merged to 'next' on 2009-10-22 at 10c0c8f)
+ Revert failed attempt since 353c5ee
+ read-tree --debug-unpack
(merged to 'next' on 2009-10-11 at 0b058e2)
+ unpack-trees.c: look ahead in the index
+ unpack-trees.c: prepare for looking ahead in the index
+ Aggressive three-way merge: fix D/F case
+ traverse_trees(): handle D/F conflict case sanely
+ more D/F conflict tests
+ tests: move convenience regexp to match object names to test-lib.sh
This has some stupid bugs and reverted from 'next' until I can fix it, but
the "temporarily" turned out to be very loooong. Sigh...
* sr/gfi-options (2009-09-06) 6 commits.
- fast-import: test the new option command
- fast-import: add option command
- fast-import: test the new feature command
- fast-import: add feature command
- fast-import: put marks reading in it's own function
- fast-import: put option parsing code in separate functions
Sverre is working on a re-roll to address comments from Shawn.
--------------------------------------------------
[Cooking]
* sr/vcs-helper (2009-11-18) 12 commits
(merged to 'next' on 2009-11-27 at 83268ab)
+ Add Python support library for remote helpers
+ Basic build infrastructure for Python scripts
+ Allow helpers to report in "list" command that the ref is unchanged
+ Fix various memory leaks in transport-helper.c
+ Allow helper to map private ref names into normal names
+ Add support for "import" helper command
+ Allow specifying the remote helper in the url
+ Add a config option for remotes to specify a foreign vcs
+ Allow fetch to modify refs
+ Use a function to determine whether a remote is valid
+ Allow programs to not depend on remotes having urls
+ Fix memory leak in helper method for disconnect
* jc/grep-full-tree (2009-11-24) 1 commit.
- grep: --full-tree
The interaction with this option and pathspecs need to be worked out
better. I _think_ "grep --full-tree -e pattern -- '*.h'" should find from
all the header files in the tree, for example.
* uk/maint-shortlog-encoding (2009-11-25) 1 commit.
- shortlog: respect commit encoding
The fix is a maint material but the patch was against next, so I
back-rebased it myself. I tried to be careful but please double check the
result.
Perhaps merge it to 'master' before 1.6.6-rc1?
* fc/send-email-envelope (2009-11-26) 2 commits.
(merged to 'next' on 2009-11-27 at 2d0257d)
+ send-email: automatic envelope sender
+ t9001: test --envelope-sender option of send-email
Perhaps merge it to 'master' before 1.6.6-rc1?
* jc/mailinfo-remove-brackets (2009-07-15) 1 commit.
(merged to 'next' on 2009-11-25 at 09d498f)
+ mailinfo: -b option keeps [bracketed] strings that is not a [PATCH] marker
Jim Meyering sent a patch to do a subset of what this does; to allow
keeping '[SECURITY]' when the subject says '[SECURITY][PATCH]', you need
to also teach "am" to pass the new -b option, but that is independent of
what Jim showed the need in real-world, so I think this can go in as-is.
Perhaps merge it to 'master' before 1.6.6-rc1?
* jc/checkout-merge-base (2009-11-20) 2 commits
- "rebase --onto A...B" replays history on the merge base between A and B
- "checkout A...B" switches to the merge base between A and B
I've been using the first one for a while myself but do not see many users
want this (yet); the new feature is not urgent anyway.
* tr/reset-checkout-patch (2009-11-19) 1 commit.
(merged to 'next' on 2009-11-22 at b224950)
+ {checkout,reset} -p: make patch direction configurable
I do not particularly like a configuration like this that changes the
behaviour of a command in a drastic way---it will make helping others much
harder.
Perhaps merge it to 'master' before 1.6.6-rc1?
* jn/gitweb-blame (2009-11-24) 8 commits.
(merged to 'next' on 2009-11-25 at 0a5b649)
+ gitweb.js: fix padLeftStr() and its usage
+ gitweb.js: Harden setting blamed commit info in incremental blame
+ gitweb.js: fix null object exception in initials calculation
+ gitweb: Minify gitweb.js if JSMIN is defined
+ gitweb: Create links leading to 'blame_incremental' using JavaScript
(merged to 'next' on 2009-10-11 at 73c4a83)
+ gitweb: Colorize 'blame_incremental' view during processing
+ gitweb: Incremental blame (using JavaScript)
+ gitweb: Add optional "time to generate page" info in footer
Ajax-y blame, with further fixes. As this does not seem to break existing
features, I am inclined to say that we push this out early, as a new
feature with known breakages, to give it wider audience.
* em/commit-claim (2009-11-04) 1 commit
(merged to 'next' on 2009-11-23 at b5df6fd)
+ commit -c/-C/--amend: reset timestamp and authorship to committer with --reset-author
I am not sure if the option name does a good job at explaining it to the
end users, but I think the code and feature is solid.
Perhaps merge it to 'master' before 1.6.6-rc1?
* cc/bisect-doc (2009-11-08) 1 commit
(merged to 'next' on 2009-11-27 at c46d648)
+ Documentation: add "Fighting regressions with git bisect" article
Perhaps merge it to 'master' before 1.6.6-rc1?
* nd/sparse (2009-11-25) 20 commits.
(merged to 'next' on 2009-11-25 at 71380f5)
+ tests: rename duplicate t1009
(merged to 'next' on 2009-11-23 at f712a41)
+ sparse checkout: inhibit empty worktree
+ Add tests for sparse checkout
+ read-tree: add --no-sparse-checkout to disable sparse checkout support
+ unpack-trees(): ignore worktree check outside checkout area
+ unpack_trees(): apply $GIT_DIR/info/sparse-checkout to the final index
+ unpack-trees(): "enable" sparse checkout and load $GIT_DIR/info/sparse-checkout
+ unpack-trees.c: generalize verify_* functions
+ unpack-trees(): add CE_WT_REMOVE to remove on worktree alone
+ Introduce "sparse checkout"
+ dir.c: export excluded_1() and add_excludes_from_file_1()
+ excluded_1(): support exclude files in index
+ unpack-trees(): carry skip-worktree bit over in merged_entry()
+ Read .gitignore from index if it is skip-worktree
+ Avoid writing to buffer in add_excludes_from_file_1()
+ Teach Git to respect skip-worktree bit (writing part)
+ Teach Git to respect skip-worktree bit (reading part)
+ Introduce "skip-worktree" bit in index, teach Git to get/set this bit
+ Add test-index-version
+ update-index: refactor mark_valid() in preparation for new options
* jc/pretty-lf (2009-10-04) 1 commit.
(merged to 'next' on 2009-11-27 at 73651c4)
+ Pretty-format: %[+-]x to tweak inter-item newlines
Perhaps merge it to 'master' before 1.6.6-rc1?
--------------------------------------------------
[For 1.7.0]
* jk/1.7.0-status (2009-11-27) 7 commits.
(merged to 'next' on 2009-11-27 at 91691ec)
+ t7508-status.sh: Add tests for status -s
+ status -s: respect the status.relativePaths option
(merged to 'next' on 2009-11-21 at 884bb56)
+ docs: note that status configuration affects only long format
(merged to 'next' on 2009-10-11 at 65c8513)
+ commit: support alternate status formats
+ status: add --porcelain output format
+ status: refactor format option parsing
+ status: refactor short-mode printing to its own function
(this branch uses jc/1.7.0-status.)
Gives the --short output format to post 1.7.0 "git commit --dry-run" that
is similar to that of post 1.7.0 "git status".
Immediately after 1.6.6 while rebuilding 'next', we may want to reorder a
few commits at the tip, as "docs: affects only long format" describes a
limitation that will disappear soon.
* jc/1.7.0-status (2009-09-05) 4 commits.
(merged to 'next' on 2009-10-11 at 9558627)
+ status: typo fix in usage
+ git status: not "commit --dry-run" anymore
+ git stat -s: short status output
+ git stat: the beginning of "status that is not a dry-run of commit"
(this branch is used by jk/1.7.0-status.)
With this, "git status" is no longer "git commit --dry-run".
* jc/1.7.0-send-email-no-thread-default (2009-08-22) 1 commit.
(merged to 'next' on 2009-10-11 at 043acdf)
+ send-email: make --no-chain-reply-to the default
* jc/1.7.0-diff-whitespace-only-status (2009-08-30) 4 commits.
(merged to 'next' on 2009-10-11 at 546c74d)
+ diff.c: fix typoes in comments
+ Make test case number unique
+ diff: Rename QUIET internal option to QUICK
+ diff: change semantics of "ignore whitespace" options
(this branch is used by jc/1.7.0-diff-whitespace-prepare and jc/diff-whitespace-prepare.)
This changes exit code from "git diff --ignore-whitespace" and friends
when there is no actual output. It is a backward incompatible change,
and jc/diff-whitespace-prepare topic is meant to ease the transition.
* gb/1.7.0-diff-whitespace-only-output (2009-11-19) 1 commit
(merged to 'next' on 2009-11-21 at 3375bf4)
+ No diff -b/-w output for all-whitespace changes
(this branch is used by jc/1.7.0-diff-whitespace-prepare and jc/diff-whitespace-prepare.)
Likewise.
* jc/1.7.0-push-safety (2009-02-09) 2 commits.
(merged to 'next' on 2009-10-11 at 81b8128)
+ Refuse deleting the current branch via push
+ Refuse updating the current branch in a non-bare repository via push
--------------------------------------------------
[Reverted from 'next']
* jc/botched-maint-cygwin-count-objects (2009-11-24) 2 commits
(merged to 'next' on 2009-11-25 at 8aa62a0)
+ Revert "ST_BLOCKS_COUNTS_IN_BLKSIZE to say on-disk size is (st_blksize * st_blocks)"
(merged to 'next' on 2009-11-22 at 4ba5880)
+ ST_BLOCKS_COUNTS_IN_BLKSIZE to say on-disk size is (st_blksize * st_blocks)
This is a revert of the tip one I merged prematurely to 'next'. The real
fix from Ramsay is already in 'master'.
* ks/precompute-completion (2009-11-15) 4 commits.
(merged to 'next' on 2009-11-15 at 23cdb96)
+ Revert ks/precompute-completion series
(merged to 'next' on 2009-10-28 at cd5177f)
+ completion: ignore custom merge strategies when pre-generating
(merged to 'next' on 2009-10-22 at f46a28a)
+ bug: precomputed completion includes scripts sources
(merged to 'next' on 2009-10-14 at adf722a)
+ Speedup bash completion loading
Reverted out of 'next', to be replaced with jn/faster-completion-startup
topic.
--------------------------------------------------
[I have been too busy to purge these]
* jc/log-tz (2009-03-03) 1 commit.
- Allow --date=local --date=other-format to work as expected
Maybe some people care about this. I dunno.
* jc/1.7.0-no-commit-no-ff-2 (2009-10-22) 1 commit.
. git-merge: forbid fast-forward and up-to-date when --no-commit is given
This makes "git merge --no-commit" fail when it results in fast-forward or
up-to-date. It appears nobody wants to have this, so I dropped it.
* ne/rev-cache (2009-10-19) 7 commits.
. support for commit grafts, slight change to general mechanism
. support for path name caching in rev-cache
. full integration of rev-cache into git, completed test suite
. administrative functions for rev-cache, start of integration into git
. support for non-commit object caching in rev-cache
. basic revision cache system, no integration or features
. man page and technical discussion for rev-cache
The author indicated that there is another round coming. Does not seem to
pass the tests when merged to 'pu', so it has been ejected for now.
* pb/gitweb-no-project-list (2009-11-06) 3 commits.
. gitweb: Polish the content tags support
. gitweb: Support for no project list on gitweb front page
. gitweb: Refactor project list routines
I picked these up but didn't queue as Warthog9's comments made certain
amount of sense to me.
^ permalink raw reply
* Re: non-US-ASCII file names (e.g. Hiragana) on Windows
From: Thomas Singer @ 2009-11-29 9:18 UTC (permalink / raw)
To: Maximilien Noal; +Cc: git
In-Reply-To: <4B11AD43.3070307@gmail.com>
Maximilien Noal wrote:
> About the 'boxes' :
>
> The thing is, Windows' files for Asian languages are _not_ installed by
> default.
>
> They can be installed (even while installing Windows), by checking the
> two checkboxes under the "Supplemtal languages support" groupbox in the
> "Languages" tab of the "Regional and language options" control panel.
> *re-take some breath ;-) *
>
> It will remove the "boxes" in Explorer and display nice Asian characters.
Thanks, now the characters are showing up fine in the Explorer.
Reece Dunn wrote:
> This is a bug in git's character encoding/conversion logic. It looks
> like git is taking the source string and converting it to ascii to be
> displayed on the console output (e.g. by using the WideCharToMultiByte
> conversion API) -- these APIs will use a '?' character for characters
> that it cannot map to the target character encoding (like the Hiragana
> characters that you are using).
I have a screenshot from a SmartGit user where 1) the console can show the
far-east-characters and 2) Git *can* show the characters escaped. Are there
two versions of Git available or does Gits behaviour depends somehow on the
system locale?
--
Tom
^ permalink raw reply
* Re: [PATCH 1/6] stg mail: Refactor __send_message and friends
From: Karl Wiberg @ 2009-11-29 9:13 UTC (permalink / raw)
To: Alex Chiang; +Cc: catalin.marinas, git
In-Reply-To: <20091128195016.949.17089.stgit@bob.kio>
Alex Chiang wrote:
> Instead of passing all the various smtp* args to __send_message
> individually, let's just pass the options list instead.
Looks good.
> + if (smtppassword and not smtpuser):
> + raise CmdException, 'SMTP password supplied, username needed'
> + if (smtpusetls and not smtpuser):
> + raise CmdException, 'SMTP over TLS requested, username needed'
Python style nit: Use "raise Exception('message')" in new code. (And
yes, I know you just moved these lines around.)
--
Karl Wiberg, kha@treskal.com
subrabbit.wordpress.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [RFC/PATCH] t7011: Mark fixed test as such
From: Nguyen Thai Ngoc Duy @ 2009-11-29 8:47 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git, Junio C Hamano
In-Reply-To: <0327ed3d7c4621f205d2d111254d716bd1b06c28.1259432535.git.git@drmicha.warpmail.net>
On 11/29/09, Michael J Gruber <git@drmicha.warpmail.net> wrote:
> Test 16/17 had been fixed since its introduction in b4d1690 (Teach Git
> to respect skip-worktree bit (reading part), 2009-08-20). So, mark it as
> expect_success rather than expect_failure.
>
> Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
No ACK. See below.
> ---
> I'm actually wondering about 17/17 as well.
> If commit is called with a file name then shouldn't it simply commit the
> current state of the file in the worktree, no matter what the index or
> skip-worktree say? I therefore think 17/17 should be expect_success
> and have no test_must_fail.
Both 16/17 and 17/17 ensure that Git won't look at files on worktree
if they are marked as skip-worktree (by definition of skip-worktree,
you can safely ignore worktree, otherwise you would not mark them as
such). 16/17 happens to pass, not because it does not touch worktree,
but because the base index does not have "1", which happens to is the
same situation in 16/17 (test commit when "1" is gone). The result is
OK but it is actually not (17/17 shows this clearer as it commits the
worktree version).
--
Duy
^ permalink raw reply
* Re: [RFH] Mention of 1.7.0 transition plans in Release Notes to 1.6.6
From: Junio C Hamano @ 2009-11-29 8:44 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git, Michael Witten, Jay Soffian
In-Reply-To: <20091129122448.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Subject: prepare send-email for smoother change of --chain-reply-to default
>
> Give a warning message when send-email uses chain-reply-to to thread the
> messages because of the current default, not because the user explicitly
> asked to, either from the command line or from the configuration.
>
> This way, by the time 1.7.0 switches the default, everybody will be ready.
>
> Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
> ---
Looks good.
^ permalink raw reply
* Re: git-svn: SVK merge commits can have >2 parents
From: Eric Wong @ 2009-11-29 8:08 UTC (permalink / raw)
To: Sam Vilain; +Cc: Alex Vandiver, git
In-Reply-To: <1259480367-sup-6891@utwig>
Alex Vandiver <alex@chmrr.net> wrote:
> At Sun Nov 29 02:28:39 -0500 2009, Alex Vandiver wrote:
> > While converting a mildly complicated svn repository that was managed
> > with SVK, I ran across the following oddness. `svk smerge` can only
> > merge between _two_ branches at once -- however, the way that svk
> > merge detection works, you can end up with erroneous extra parents
> > from long-dead branches.
>
> Upon a little more inspection, I now understand that the rev-parse
> lines in find_extra_svk_parents are attempting to deal with this exact
> circumstance -- but they fail to properly sort the merge tickets
> first, which leads to this incorrect behavior. Armed with this
> understanding, I'm more confident in the attached updated patch. I
Hi Alex, Sam,
I'll defer to Sam for the Ack, my svk knowledge is limited. Thanks.
--
Eric Wong
^ permalink raw reply
* git-svn: SVK merge commits can have >2 parents
From: Alex Vandiver @ 2009-11-29 7:28 UTC (permalink / raw)
To: Sam Vilain, Eric Wong; +Cc: git
[-- Attachment #1: Type: text/plain, Size: 1703 bytes --]
Heya,
While converting a mildly complicated svn repository that was managed
with SVK, I ran across the following oddness. `svk smerge` can only
merge between _two_ branches at once -- however, the way that svk
merge detection works, you can end up with erroneous extra parents
from long-dead branches. Case in point:
export SVKROOT=/tmp/svk-testing-$$
svk mkdir //trunk -m 'trunk'
svk mkdir //branches -m 'branches'
svk co //trunk
svk cp //trunk/ //branches/feature1 -m 'branch for feature1'
svk cp //trunk/ //branches/feature2 -m 'branch for feature2'
svk co //branches/feature1
cd feature1
echo "foo" >foo
svk add foo
svk ci -m 'feature1 development'
svk sm //branches/feature1 //trunk -m 'merge feature1 to trunk'
cd ..
svk co //branches/feature2
cd feature2
echo "bar" >bar
svk add bar
svk ci -m 'feature2 development'
svk sm //trunk //branches/feature2 -m 'merge from trunk'
cd ..
git svn clone -s file://$SVKROOT/local
The 'feature2' branch will appear to have three parents: r7, r6, _and_
r5. The r5 parent is extraneous, and only appears because r5 was
previously merged into trunk, as part of r6.
Given this, I'm a little confused why find_extra_svk_parents is
written the way that it is, in seemingly allowing multiple extra
parents to be found. Since the most recent (i.e., highest-numbered)
change is by definition the only one that can account for all of the
other svk:merge changes, I _believe_ the attached diff to be correct,
but I'm unsure because of the implicit current assumption that smerges
can produce multiple parents.
- Alex
--
Networking -- only one letter away from not working
[-- Attachment #2: 0001-git-svn-svk-merge-commits-should-only-add-one-exta-p.patch --]
[-- Type: application/octet-stream, Size: 1400 bytes --]
From b86b4bb0cecb70d828558b046aa0b3e7b899bf41 Mon Sep 17 00:00:00 2001
From: Alex Vandiver <alex@chmrr.net>
Date: Sun, 29 Nov 2009 02:20:21 -0500
Subject: [PATCH] git-svn: svk merge commits should only add one exta parent
When merging branches based on svk:merge properties, a single merge
can have updated or added multiple svk:merge lines. If so. only
include the minimal set of new parents.
Signed-off-by: Alex Vandiver <alex@chmrr.net>
---
git-svn.perl | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 957d44e..668e50c 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -2940,10 +2940,12 @@ sub find_extra_svk_parents {
if ( my $commit = $gs->rev_map_get($rev, $uuid) ) {
# wahey! we found it, but it might be
# an old one (!)
- push @known_parents, $commit;
+ push @known_parents, [ $rev, $commit ];
}
}
}
+ # We only care about the highest-numbered applicable commit
+ @known_parents = map {$_->[1]} sort {$b->[0] <=> $a->[0]} @known_parents;
for my $parent ( @known_parents ) {
my @cmd = ('rev-list', $parent, map { "^$_" } @$parents );
my ($msg_fh, $ctx) = command_output_pipe(@cmd);
@@ -2956,6 +2958,7 @@ sub find_extra_svk_parents {
print STDERR
"Found merge parent (svk:merge ticket): $parent\n";
push @$parents, $parent;
+ return;
}
}
}
--
1.6.6.rc0.254.g7352d
^ permalink raw reply related
* Re: git-svn: SVK merge commits can have >2 parents
From: Alex Vandiver @ 2009-11-29 7:46 UTC (permalink / raw)
To: Sam Vilain, Eric Wong; +Cc: git
In-Reply-To: <1259479636-sup-573@utwig>
[-- Attachment #1: Type: text/plain, Size: 1001 bytes --]
At Sun Nov 29 02:28:39 -0500 2009, Alex Vandiver wrote:
> While converting a mildly complicated svn repository that was managed
> with SVK, I ran across the following oddness. `svk smerge` can only
> merge between _two_ branches at once -- however, the way that svk
> merge detection works, you can end up with erroneous extra parents
> from long-dead branches.
Upon a little more inspection, I now understand that the rev-parse
lines in find_extra_svk_parents are attempting to deal with this exact
circumstance -- but they fail to properly sort the merge tickets
first, which leads to this incorrect behavior. Armed with this
understanding, I'm more confident in the attached updated patch. I
assume, however, that the logic allows for more than one extra parent
only because such an occurrance could be constructed by hand-editing
svk:merge, because AFAIK svk's command-line tools should be able to
construct such a circumstance.
- Alex
--
Networking -- only one letter away from not working
[-- Attachment #2: 0001-git-svn-sort-svk-merge-tickets-to-account-for-minima.patch --]
[-- Type: application/octet-stream, Size: 1369 bytes --]
From 4d30e57e5da7c2e880908bc742cf80990d6f9f5d Mon Sep 17 00:00:00 2001
From: Alex Vandiver <alex@chmrr.net>
Date: Sun, 29 Nov 2009 02:20:21 -0500
Subject: [PATCH] git-svn: sort svk merge tickets to account for minimal parents
When merging branches based on svk:merge properties, a single merge
can have updated or added multiple svk:merge lines. Attempt to
include the minimal set of parents by sorting the merge properties in
order of revision, highest to lowest.
Signed-off-by: Alex Vandiver <alex@chmrr.net>
---
git-svn.perl | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 957d44e..51f03ad 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -2940,10 +2940,14 @@ sub find_extra_svk_parents {
if ( my $commit = $gs->rev_map_get($rev, $uuid) ) {
# wahey! we found it, but it might be
# an old one (!)
- push @known_parents, $commit;
+ push @known_parents, [ $rev, $commit ];
}
}
}
+ # Ordering matters; highest-numbered commit merge tickets
+ # first, as they may account for later merge ticket additions
+ # or changes.
+ @known_parents = map {$_->[1]} sort {$b->[0] <=> $a->[0]} @known_parents;
for my $parent ( @known_parents ) {
my @cmd = ('rev-list', $parent, map { "^$_" } @$parents );
my ($msg_fh, $ctx) = command_output_pipe(@cmd);
--
1.6.6.rc0.254.g7352d
^ permalink raw reply related
* [PATCH 3/3] diff: disable diff.bwoutputonly warning
From: Junio C Hamano @ 2009-11-29 7:26 UTC (permalink / raw)
To: git
In-Reply-To: <7vmy25dc9h.fsf@alter.siamese.dyndns.org>
After 1.7.0 (or whatever version) ships and everybody expects the new
semantics from "diff", we can squelch the warning.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
diff.c | 11 -----------
t/t4015-diff-whitespace.sh | 4 ++--
2 files changed, 2 insertions(+), 13 deletions(-)
diff --git a/diff.c b/diff.c
index df67f18..ba1f482 100644
--- a/diff.c
+++ b/diff.c
@@ -30,7 +30,6 @@ static const char *external_diff_cmd_cfg;
int diff_auto_refresh_index = 1;
static int diff_mnemonic_prefix;
static int diff_b_w_output_only;
-static int diff_b_w_output_only_given;
static char diff_colors[][COLOR_MAXLEN] = {
GIT_COLOR_RESET,
@@ -136,7 +135,6 @@ int git_diff_basic_config(const char *var, const char *value, void *cb)
}
if (!strcmp(var, "diff.bwoutputonly")) {
- diff_b_w_output_only_given = 1;
diff_b_w_output_only = git_config_bool(var, value);
return 0;
}
@@ -2523,11 +2521,6 @@ void diff_setup(struct diff_options *options)
}
}
-static const char *bw_option_warning =
- "ignore-whitespace options will stop showing diff headers in later\n"
- "versions of git; set diff.bwoutputonly to true to keep the old\n"
- "behaviour, or set.bwoutputonly to false to squelch this message.\n";
-
int diff_setup_done(struct diff_options *options)
{
int count = 0;
@@ -2553,10 +2546,6 @@ int diff_setup_done(struct diff_options *options)
bw_options = (DIFF_XDL_TST(options, IGNORE_WHITESPACE) ||
DIFF_XDL_TST(options, IGNORE_WHITESPACE_CHANGE) ||
DIFF_XDL_TST(options, IGNORE_WHITESPACE_AT_EOL));
- if (!diff_b_w_output_only_given && bw_options && bw_option_warning) {
- warning("%s", bw_option_warning);
- bw_option_warning = NULL;
- }
if (!diff_b_w_output_only && bw_options)
DIFF_OPT_SET(options, DIFF_FROM_CONTENTS);
else
diff --git a/t/t4015-diff-whitespace.sh b/t/t4015-diff-whitespace.sh
index 8ca81e8..0964ea2 100755
--- a/t/t4015-diff-whitespace.sh
+++ b/t/t4015-diff-whitespace.sh
@@ -433,10 +433,10 @@ test_expect_success 'no warning without diff.bwoutputonly' '
! grep "stop showing" errors
'
-test_expect_success 'warning without diff.bwoutputonly' '
+test_expect_success 'no warning anymore' '
git config --unset diff.bwoutputonly
git diff -b 2>errors &&
- grep "stop showing" errors
+ ! grep "stop showing" errors
'
test_expect_success 'combined diff with autocrlf conversion' '
--
1.6.6.rc0.61.g41d5b.dirty
^ permalink raw reply related
* [PATCH 2/3] diff: flip the diff.bwoutputonly default to false
From: Junio C Hamano @ 2009-11-29 7:25 UTC (permalink / raw)
To: git
In-Reply-To: <7vmy25dc9h.fsf@alter.siamese.dyndns.org>
This finally corrects the broken "ignore whitespace options only
affect patch output and never affects status nor header output",
as we have been planning for 1.7.0
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
diff.c | 2 +-
t/t4015-diff-whitespace.sh | 5 +++--
t/t4040-whitespace-status.sh | 2 +-
3 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/diff.c b/diff.c
index fb93a22..df67f18 100644
--- a/diff.c
+++ b/diff.c
@@ -29,7 +29,7 @@ static const char *diff_word_regex_cfg;
static const char *external_diff_cmd_cfg;
int diff_auto_refresh_index = 1;
static int diff_mnemonic_prefix;
-static int diff_b_w_output_only = 1;
+static int diff_b_w_output_only;
static int diff_b_w_output_only_given;
static char diff_colors[][COLOR_MAXLEN] = {
diff --git a/t/t4015-diff-whitespace.sh b/t/t4015-diff-whitespace.sh
index 310421b..8ca81e8 100755
--- a/t/t4015-diff-whitespace.sh
+++ b/t/t4015-diff-whitespace.sh
@@ -114,6 +114,7 @@ index d99af23..8b32fb5 100644
EOF
test_w_b "bwoutputonly=true"
+>expect
git config --unset diff.bwoutputonly
test_w_b "bwoutputonly unset"
@@ -398,7 +399,7 @@ test_expect_success 'checkdiff allows new blank lines' '
git diff --check
'
-test_expect_success 'whitespace-only changes shown' '
+test_expect_success 'whitespace-only changes hidden' '
git config --unset diff.bwoutputonly
git reset --hard &&
echo >x "hello world" &&
@@ -406,7 +407,7 @@ test_expect_success 'whitespace-only changes shown' '
git commit -m "hello 1" &&
echo >x "hello world" &&
git diff -b >actual &&
- test 2 = $(wc -l <actual)
+ ! test -s actual
'
test_expect_success 'whitespace-only changes shown with diff.bwoutputonly' '
diff --git a/t/t4040-whitespace-status.sh b/t/t4040-whitespace-status.sh
index 95a93f7..57db3cc 100755
--- a/t/t4040-whitespace-status.sh
+++ b/t/t4040-whitespace-status.sh
@@ -72,6 +72,6 @@ git config diff.bwoutputonly false
test_once "bwoutputonly=false" ""
git config --unset diff.bwoutputonly
-test_once "bwoutputonly unset" "test_must_fail"
+test_once "bwoutputonly unset" ""
test_done
--
1.6.6.rc0.61.g41d5b.dirty
^ permalink raw reply related
* [PATCH 1/3] diff: flip the default diff.bwoutputonly to true
From: Junio C Hamano @ 2009-11-29 7:25 UTC (permalink / raw)
To: git
In-Reply-To: <7vmy25dc9h.fsf@alter.siamese.dyndns.org>
This switches the default behaviour of "diff -w/-b" back to the
traditional "ignore whitespace affects only output of patch text, not
status nor diff header", and allows the planned new semantics to be asked
in advance by setting diff.bwoutputonly configuration to false.
Also a loud warning is issued when the configuration is not set at all,
so that we can flip the default later more smoothly.
Update tests to check cases where the configuration is set to true, false
and not set at all; make sure the warning is issued when and only when
necessary.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
diff.c | 23 ++++++++++---
t/t4015-diff-whitespace.sh | 70 +++++++++++++++++++++++++++++++++---------
t/t4040-whitespace-status.sh | 48 ++++++++++++++++++----------
3 files changed, 103 insertions(+), 38 deletions(-)
diff --git a/diff.c b/diff.c
index 6e7c47c..fb93a22 100644
--- a/diff.c
+++ b/diff.c
@@ -29,7 +29,8 @@ static const char *diff_word_regex_cfg;
static const char *external_diff_cmd_cfg;
int diff_auto_refresh_index = 1;
static int diff_mnemonic_prefix;
-static int diff_b_w_output_only;
+static int diff_b_w_output_only = 1;
+static int diff_b_w_output_only_given;
static char diff_colors[][COLOR_MAXLEN] = {
GIT_COLOR_RESET,
@@ -135,6 +136,7 @@ int git_diff_basic_config(const char *var, const char *value, void *cb)
}
if (!strcmp(var, "diff.bwoutputonly")) {
+ diff_b_w_output_only_given = 1;
diff_b_w_output_only = git_config_bool(var, value);
return 0;
}
@@ -2521,9 +2523,15 @@ void diff_setup(struct diff_options *options)
}
}
+static const char *bw_option_warning =
+ "ignore-whitespace options will stop showing diff headers in later\n"
+ "versions of git; set diff.bwoutputonly to true to keep the old\n"
+ "behaviour, or set.bwoutputonly to false to squelch this message.\n";
+
int diff_setup_done(struct diff_options *options)
{
int count = 0;
+ int bw_options;
if (options->output_format & DIFF_FORMAT_NAME)
count++;
@@ -2542,11 +2550,14 @@ int diff_setup_done(struct diff_options *options)
* --ignore-whitespace* options force us to look
* inside contents.
*/
-
- if (!diff_b_w_output_only &&
- (DIFF_XDL_TST(options, IGNORE_WHITESPACE) ||
- DIFF_XDL_TST(options, IGNORE_WHITESPACE_CHANGE) ||
- DIFF_XDL_TST(options, IGNORE_WHITESPACE_AT_EOL)))
+ bw_options = (DIFF_XDL_TST(options, IGNORE_WHITESPACE) ||
+ DIFF_XDL_TST(options, IGNORE_WHITESPACE_CHANGE) ||
+ DIFF_XDL_TST(options, IGNORE_WHITESPACE_AT_EOL));
+ if (!diff_b_w_output_only_given && bw_options && bw_option_warning) {
+ warning("%s", bw_option_warning);
+ bw_option_warning = NULL;
+ }
+ if (!diff_b_w_output_only && bw_options)
DIFF_OPT_SET(options, DIFF_FROM_CONTENTS);
else
DIFF_OPT_CLR(options, DIFF_FROM_CONTENTS);
diff --git a/t/t4015-diff-whitespace.sh b/t/t4015-diff-whitespace.sh
index 90f3342..310421b 100755
--- a/t/t4015-diff-whitespace.sh
+++ b/t/t4015-diff-whitespace.sh
@@ -92,16 +92,30 @@ EOF
git diff > out
test_expect_success 'another test, without options' 'test_cmp expect out'
-cat << EOF > expect
+test_w_b () {
+ note=$1
+ for o in "-w" "-w -b" "-w --ignore-space-at-eol" "-w -b --ignore-space-at-eol"
+ do
+ test_expect_success "with $o ($note)" '
+ git diff $o >actual &&
+ test_cmp expect actual
+ '
+ done
+}
+
+git config diff.bwoutputonly false
+> expect
+test_w_b "bwoutputonly=false"
+
+git config diff.bwoutputonly true
+cat <<EOF >expect
+diff --git a/x b/x
+index d99af23..8b32fb5 100644
EOF
-git diff -w > out
-test_expect_success 'another test, with -w' 'test_cmp expect out'
-git diff -w -b > out
-test_expect_success 'another test, with -w -b' 'test_cmp expect out'
-git diff -w --ignore-space-at-eol > out
-test_expect_success 'another test, with -w --ignore-space-at-eol' 'test_cmp expect out'
-git diff -w -b --ignore-space-at-eol > out
-test_expect_success 'another test, with -w -b --ignore-space-at-eol' 'test_cmp expect out'
+test_w_b "bwoutputonly=true"
+
+git config --unset diff.bwoutputonly
+test_w_b "bwoutputonly unset"
tr 'Q' '\015' << EOF > expect
diff --git a/x b/x
@@ -384,20 +398,47 @@ test_expect_success 'checkdiff allows new blank lines' '
git diff --check
'
-cat <<EOF >expect
-EOF
-test_expect_success 'whitespace-only changes not reported' '
+test_expect_success 'whitespace-only changes shown' '
+ git config --unset diff.bwoutputonly
git reset --hard &&
echo >x "hello world" &&
git add x &&
git commit -m "hello 1" &&
echo >x "hello world" &&
git diff -b >actual &&
- test_cmp expect actual
+ test 2 = $(wc -l <actual)
'
-test_expect_success 'combined diff with autocrlf conversion' '
+test_expect_success 'whitespace-only changes shown with diff.bwoutputonly' '
+ git config diff.bwoutputonly true &&
+ git diff -b >actual &&
+ test 2 = $(wc -l <actual)
+'
+
+test_expect_success 'whitespace-only changes hidden with !diff.bwoutputonly' '
+ git config diff.bwoutputonly false &&
+ git diff -b >actual &&
+ ! test -s actual
+'
+
+test_expect_success 'no warning with diff.bwoutputonly given' '
+ git diff -b 2>errors &&
+ ! grep warn errors
+'
+test_expect_success 'no warning without diff.bwoutputonly' '
+ git config --unset diff.bwoutputonly
+ git diff -p 2>errors &&
+ ! grep "stop showing" errors
+'
+
+test_expect_success 'warning without diff.bwoutputonly' '
+ git config --unset diff.bwoutputonly
+ git diff -b 2>errors &&
+ grep "stop showing" errors
+'
+
+test_expect_success 'combined diff with autocrlf conversion' '
git reset --hard &&
echo >x hello &&
git commit -m "one side" x &&
@@ -409,7 +450,6 @@ test_expect_success 'combined diff with autocrlf conversion' '
git diff | sed -e "1,/^@@@/d" >actual &&
! grep "^-" actual
-
'
test_done
diff --git a/t/t4040-whitespace-status.sh b/t/t4040-whitespace-status.sh
index a30b03b..95a93f7 100755
--- a/t/t4040-whitespace-status.sh
+++ b/t/t4040-whitespace-status.sh
@@ -19,45 +19,59 @@ test_expect_success setup '
git add a/d
'
-test_expect_success 'diff-tree --exit-code' '
+test_once () {
+ note=$1 tmf=$2
+
+test_expect_success "diff-tree --exit-code ($note)" '
test_must_fail git diff --exit-code HEAD^ HEAD &&
test_must_fail git diff-tree --exit-code HEAD^ HEAD
'
-test_expect_success 'diff-tree -b --exit-code' '
- git diff -b --exit-code HEAD^ HEAD &&
- git diff-tree -b -p --exit-code HEAD^ HEAD &&
- git diff-tree -b --exit-code HEAD^ HEAD
+test_expect_success "diff-tree -b --exit-code ($note)" '
+ $tmf git diff -b --exit-code HEAD^ HEAD &&
+ $tmf git diff-tree -b -p --exit-code HEAD^ HEAD &&
+ $tmf git diff-tree -b --exit-code HEAD^ HEAD
'
-test_expect_success 'diff-index --cached --exit-code' '
+test_expect_success "diff-index --cached --exit-code ($note)" '
test_must_fail git diff --cached --exit-code HEAD &&
test_must_fail git diff-index --cached --exit-code HEAD
'
-test_expect_success 'diff-index -b -p --cached --exit-code' '
- git diff -b --cached --exit-code HEAD &&
- git diff-index -b -p --cached --exit-code HEAD
+test_expect_success "diff-index -b -p --cached --exit-code ($note)" '
+ $tmf git diff -b --cached --exit-code HEAD &&
+ $tmf git diff-index -b -p --cached --exit-code HEAD
'
-test_expect_success 'diff-index --exit-code' '
+test_expect_success "diff-index --exit-code ($note)" '
test_must_fail git diff --exit-code HEAD &&
test_must_fail git diff-index --exit-code HEAD
'
-test_expect_success 'diff-index -b -p --exit-code' '
- git diff -b --exit-code HEAD &&
- git diff-index -b -p --exit-code HEAD
+test_expect_success "diff-index -b -p --exit-code ($note)" '
+ $tmf git diff -b --exit-code HEAD &&
+ $tmf git diff-index -b -p --exit-code HEAD
'
-test_expect_success 'diff-files --exit-code' '
+test_expect_success "diff-files --exit-code ($note)" '
test_must_fail git diff --exit-code &&
test_must_fail git diff-files --exit-code
'
-test_expect_success 'diff-files -b -p --exit-code' '
- git diff -b --exit-code &&
- git diff-files -b -p --exit-code
+test_expect_success "diff-files -b -p --exit-code ($note)" '
+ $tmf git diff -b --exit-code &&
+ $tmf git diff-files -b -p --exit-code
'
+}
+
+git config diff.bwoutputonly true
+test_once "bwoutputonly=true" "test_must_fail"
+
+git config diff.bwoutputonly false
+test_once "bwoutputonly=false" ""
+
+git config --unset diff.bwoutputonly
+test_once "bwoutputonly unset" "test_must_fail"
+
test_done
--
1.6.6.rc0.61.g41d5b.dirty
^ permalink raw reply related
* Re: [RFH] Mention of 1.7.0 transition plans in Release Notes to 1.6.6
From: Junio C Hamano @ 2009-11-29 7:24 UTC (permalink / raw)
To: git
In-Reply-To: <7vfx7yfetb.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> - I do not think of a sane way to cover "diff -b/-w" changes, as this is
> a "bugfix --- but there may be some scripts that have been relying on
> the bug", and a configuration option that retains the buggy behaviour
> does not make much sense. But I may be mistaken and somebody can come
> up with an easy patch to allow both behaviour, in which case we should
> add similar anti-procrastination measure to this change.
The patch to enable/disable this feature would look like the attached,
which doesn't look too bad. This apply to a merge between two topics:
jc/1.7.0-diff-whitespace-only-status (97bf2a0)
gb/1.7.0-diff-whitespace-only-output (3e97c7c)
An anti-procrastination measure must be done in at least two, but probably
in three steps on top of this patch:
#1. Flip the default in this patch back to 1, as the traditional
behaviour is to treat ignore-whitespace options as purely affecting
output of patch text, not affecting status nor the header;
#2. Add extra logic to detect if a particular invocation may trigger a
different behaviour once the default is changed to 0, and issue an
warning if there is no configuration explicitly set;
#3. Flip the default to 0, perhaps still keeping the warning when there
is no configuration.
Make a major release after the second step is done, and wait for at least
one but preferrably two releases, and then ship the result of the third
step in the "flag day" release. In a much later version we would remove
the "no configuration warning".
Do we need an anti-procrastination measure for this? If so, I think we
probably need to postpone the "diff" semantics changes after 1.7.0, as I
am not very confident that we can solidly finish the second step before
the 1.6.6 final.
Also, I am not very keen on having this configuration, as its only purpose
is to ask for a broken semantics from "diff", even though it has been the
traditional behaviour for the past four years.
Comments?
---
diff.c | 15 +++++++++++----
1 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/diff.c b/diff.c
index da90e6e..6e7c47c 100644
--- a/diff.c
+++ b/diff.c
@@ -29,6 +29,7 @@ static const char *diff_word_regex_cfg;
static const char *external_diff_cmd_cfg;
int diff_auto_refresh_index = 1;
static int diff_mnemonic_prefix;
+static int diff_b_w_output_only;
static char diff_colors[][COLOR_MAXLEN] = {
GIT_COLOR_RESET,
@@ -133,6 +134,11 @@ int git_diff_basic_config(const char *var, const char *value, void *cb)
return 0;
}
+ if (!strcmp(var, "diff.bwoutputonly")) {
+ diff_b_w_output_only = git_config_bool(var, value);
+ return 0;
+ }
+
return git_color_default_config(var, value, cb);
}
@@ -1668,7 +1674,7 @@ static void builtin_diff(const char *name_a,
struct emit_callback ecbdata;
const struct userdiff_funcname *pe;
- if (!DIFF_XDL_TST(o, WHITESPACE_FLAGS)) {
+ if (!DIFF_XDL_TST(o, WHITESPACE_FLAGS) || diff_b_w_output_only) {
fprintf(o->file, "%s", header.buf);
strbuf_reset(&header);
}
@@ -2537,9 +2543,10 @@ int diff_setup_done(struct diff_options *options)
* inside contents.
*/
- if (DIFF_XDL_TST(options, IGNORE_WHITESPACE) ||
- DIFF_XDL_TST(options, IGNORE_WHITESPACE_CHANGE) ||
- DIFF_XDL_TST(options, IGNORE_WHITESPACE_AT_EOL))
+ if (!diff_b_w_output_only &&
+ (DIFF_XDL_TST(options, IGNORE_WHITESPACE) ||
+ DIFF_XDL_TST(options, IGNORE_WHITESPACE_CHANGE) ||
+ DIFF_XDL_TST(options, IGNORE_WHITESPACE_AT_EOL)))
DIFF_OPT_SET(options, DIFF_FROM_CONTENTS);
else
DIFF_OPT_CLR(options, DIFF_FROM_CONTENTS);
--
1.6.6.rc0.61.g41d5b.dirty
^ permalink raw reply related
* Re: Unable to checkout a particular SVN revision
From: Marc Liyanage @ 2009-11-29 6:41 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <4B113BAD.8090604@drmicha.warpmail.net>
Thanks for the explanation so far.
On 28.11.2009, at 07:03, Michael J Gruber wrote:
> No. Because "this" is different in the two cases above: "git svn clone"
> clones the history of an svn repo, and the command above clearly gives
> you the history of that branch in the specified revision range
> (consisting of 1 revision). It is empty.
I still don't quite understand why it couldn't do the same thing as the SVN checkout. That does exactly what I expect, it reflects the state of that part of the repository at the time of that revision. Would this be possible, but it's simply not (yet) implemented?
The problem I'm dealing with are svn:externals definitions that are pegged to such revisions. SVN checks them out fine, but git svn doesn't, so I have to hunt down the appropriate revision manually.
______________________________
Marc Liyanage
www.entropy.ch
skype mliyanage
iChat liyanage@mac.com
^ permalink raw reply
* Re: "git merge" merges too much!
From: Junio C Hamano @ 2009-11-29 5:15 UTC (permalink / raw)
To: Greg A. Woods; +Cc: The Git Mailing List
In-Reply-To: <m1NEaLp-000kn1C@most.weird.com>
In order to make things smoother and easier in the future, you may want to
learn "topic branch" workflows (found in many git tutorial material).
But it is too late for the history you already created; "cherry-pick" is
your friend to recover from the shape of your existing history.
^ permalink raw reply
* Re: "git merge" merges too much!
From: Jeff King @ 2009-11-29 5:14 UTC (permalink / raw)
To: The Git Mailing List
In-Reply-To: <m1NEaLp-000kn1C@most.weird.com>
On Sat, Nov 28, 2009 at 10:21:25PM -0500, Greg A. Woods wrote:
> Hope I've found the right list on which to ask potentially naive
> questions! I've been doing _lots_ of reading about Git, but I can't
> seem to find anything about the problems I relate below.
Yep, you're in the right place.
> master branch to represent release points -- is there any way to get
> "git log" to show which tags are associated with a given commit and/or
Try "git log --decorate".
> BL1.2 - A - B - C <- BL1.2 HEAD
> /
> master 1 - 2 - TR1.1 - 3 - 4 - 5 - TR1.2 <- master HEAD
>
> [...]
>
> git checkout -b BL1.1 TR1.1
> git merge BL1.2
>
> However this seems to merge all of 3, 4, and 5, as well as A, B, and C.
>
> I think I can (barely) understand why it's doing what it's doing, but
> that's not what I want it to do. However it looks like Git doesn't have
> the same idea of a branch "base" point as I think I do.
Yes. Git doesn't really view history as branches in the way you are
thinking. History is simply a directed graph, and when you merge two
nodes in the graph, it takes into account _everything_ that happened
to reach those two points since the last time they diverged (which in
your case is simply TR1.1, as BL1.2 is a strict superset).
There is no way in the history graph to represent "we have these
commits, but not this subsequence". You have to create new commits A',
B', and C' which introduce more or less the same changes as their
counterparts (and they may even be _exactly_ the same except for the
parentage, but then again, they may not if the changes they make do not
apply in the same way on top of TR1.1).
> Running "git log TR1.2..BL1.2" does show me exactly the changes I wish
> to propagate, but "git merge TR1.2..BL1.2" says "not something we can
> merge". Sigh.
>
> How can I get it to merge just the changes from the "base" of the BL1.2
> branch to its head?
>
> Is using either git-cherry-pick or "git log -p | git-am", the only way
> to do this? Which way best preserves Git's ability to realize if a
> change has already been included on the target branch, if any?
Yes, you must cherry-pick or use rebase (which is a more featureful
version of the pipeline you mentioned). Either way will produce an
equivalent set of commits (cherry-pick is useful when you are picking a
couple of commits; rebase is useful for rewriting a whole stretch of
history. It sounds like you want to do the latter).
The resulting commits will have different commit ids, but git generally
does a good job at merging such things, because it looks only at the
result state and not the intermediate commits. If both sides have made
an equivalent change, then there is no conflict.
> Is there any way to get "git log --graph" (and/or gitk) to show me all
> the branch heads, not just the current/specified one?
Try "--all" with either gitk or "git log". Or if you want a subset of
heads, just name them.
Hope that helps,
-Peff
^ permalink raw reply
* Re: [PATCH 3/4] build dashless "test-bin" directory similar to installed bindir
From: Jeff King @ 2009-11-29 5:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matthew Ogilvie, git
In-Reply-To: <7vzl65ex6u.fsf@alter.siamese.dyndns.org>
On Sat, Nov 28, 2009 at 09:07:05PM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > make && cd t && make tXXXX-YYYY.sh
> >
> > to work correctly ...
> >
> > I also like to be able to simply run ./tXXXX-YYYY.sh.
>
> I think both can be done by running "cd .. && make test-bin-stuff" from
> test-lib.sh if you wanted to. Isn't it essentially what you do for
> valgrind?
Yes, except that the valgrind setup doesn't actually interact with the
Makefile; it just assumes that git-* is interesting. I would be happy
with a solution that is triggered from test-lib. It may even be possible
to refactor the valgrind stuff, but I'm not sure. What Dscho eventually
submitted doesn't bear much resemblence to my original attempt, and I've
forgotten all of the details.
-Peff
^ permalink raw reply
* Re: [PATCH 3/4] build dashless "test-bin" directory similar to installed bindir
From: Junio C Hamano @ 2009-11-29 5:07 UTC (permalink / raw)
To: Jeff King; +Cc: Matthew Ogilvie, git
In-Reply-To: <20091129034313.GA28379@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> make && cd t && make tXXXX-YYYY.sh
>
> to work correctly ...
>
> I also like to be able to simply run ./tXXXX-YYYY.sh.
I think both can be done by running "cd .. && make test-bin-stuff" from
test-lib.sh if you wanted to. Isn't it essentially what you do for
valgrind?
^ permalink raw reply
* Re: [PATCH 3/4] build dashless "test-bin" directory similar to installed bindir
From: Matthew Ogilvie @ 2009-11-29 4:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7vaay6f4ce.fsf@alter.siamese.dyndns.org>
On Sat, Nov 28, 2009 at 06:32:33PM -0800, Junio C Hamano wrote:
> Why can't t/Makefile have a dependency on its 'default' target that goes
> up and prepares test-bin/, i.e. "cd .. && make test-bin-stuff"?
That wouldn't help with someone manually running specific tests,
which is a common way to run tests when working on git:
hackhackhack && make && cd t && ./tXXXX-*.sh
Perhaps we could invoke make from test-lib.sh, but at that point
it starts to look more attractive to just do it the same way as the
valgrind option, even though that means duplicating the appropriate
list of executables in test-lib.sh.
Also, "make all" already builds some test suite support
binaries (test-*). Is it really worth any effort to leave
a few short wrapper scripts out of "make all" when it is already
building several test binaries?
(See also my much longer email response that crossed this one in the
mail.)
--
Matthew Ogilvie [mmogilvi_git@miniinfo.net]
^ permalink raw reply
* Re: [PATCH 3/4] build dashless "test-bin" directory similar to installed bindir
From: Jeff King @ 2009-11-29 3:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matthew Ogilvie, git
In-Reply-To: <7vaay6f4ce.fsf@alter.siamese.dyndns.org>
On Sat, Nov 28, 2009 at 06:32:33PM -0800, Junio C Hamano wrote:
> > Would implementing it that way mean that:
> >
> > make && cd t && make
> >
> > does not work (or worse, might silently use stale information in
> > test-bin)?
>
> Why can't t/Makefile have a dependency on its 'default' target that goes
> up and prepares test-bin/, i.e. "cd .. && make test-bin-stuff"?
Yeah, that would work (I really should have phrased my other response
less as a critique and more as "please don't break this workflow"). But
I don't think the default target would be enough. I would also expect
make && cd t && make tXXXX-YYYY.sh
to work correctly (and to be pedantic, I am actually more interested in
the equivalent situation that one has one window looking at code and
compiling, and another window running a test script, but they are
functionally equivalent here).
I also like to be able to simply run ./tXXXX-YYYY.sh. I can accept
losing that if there is something to be gained, but if we can keep it, I
suspect I am not the only one who uses it.
-Peff
^ permalink raw reply
* "git merge" merges too much!
From: Greg A. Woods @ 2009-11-29 3:21 UTC (permalink / raw)
To: The Git Mailing List
[-- Attachment #1: Type: text/plain, Size: 2828 bytes --]
I'm trying to learn to use Git to manage local changes. I'm very new to
Git (hi all!), but not new at all to version tracking tools in general.
Hope I've found the right list on which to ask potentially naive
questions! I've been doing _lots_ of reading about Git, but I can't
seem to find anything about the problems I relate below.
One task I'm working on is to try to find the best way to merge changes
made from one branch to another, eg. to propagate local fixes from one
release to another.
However in at least one simple case "git merge" merges too much.
I have something like this started from a remote-cloned repository where
BL1.2 is a branch from the remote master HEAD, which happens to
correspond to a tag "TR1.2", the release-1.2 tag, and I've made three
local commits to my local BL1.2 branch: A, B, and C:
BL1.2 - A - B - C <- BL1.2 HEAD
/
master 1 - 2 - TR1.1 - 3 - 4 - 5 - TR1.2 <- master HEAD
(there are no "release" branches in this project, just tags on the
master branch to represent release points -- is there any way to get
"git log" to show which tags are associated with a given commit and/or
branch? The real project is freedesktop.org's xinit repo, but the real
tree is too messy to diagram here -- hopefully I've extracted the
essence of the problem correctly)
I now want to create a branch "BL1.1" and merge commits A, B, and C to it
in order to back-port my local fixes to the TR1.1 release. "TR1.1" is
simply a tag on the origin/master trunk.
I do the following:
git checkout -b BL1.1 TR1.1
git merge BL1.2
However this seems to merge all of 3, 4, and 5, as well as A, B, and C.
I think I can (barely) understand why it's doing what it's doing, but
that's not what I want it to do. However it looks like Git doesn't have
the same idea of a branch "base" point as I think I do.
Running "git log TR1.2..BL1.2" does show me exactly the changes I wish
to propagate, but "git merge TR1.2..BL1.2" says "not something we can
merge". Sigh.
How can I get it to merge just the changes from the "base" of the BL1.2
branch to its head?
Is using either git-cherry-pick or "git log -p | git-am", the only way
to do this? Which way best preserves Git's ability to realize if a
change has already been included on the target branch, if any?
Is this the kind of "problem" that drove the creators of Stacked-Git to
invent their tools?
Is there any way to get "git log --graph" (and/or gitk) to show me all
the branch heads, not just the current/specified one?
--
Greg A. Woods
+1 416 218-0098 VE3TCP RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com> Secrets of the Weird <woods@weird.com>
[-- Attachment #2: Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* Re: [RFH] Mention of 1.7.0 transition plans in Release Notes to 1.6.6
From: Nanako Shiraishi @ 2009-11-29 3:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Michael Witten, Jay Soffian
In-Reply-To: <7vfx7yfetb.fsf@alter.siamese.dyndns.org>
Subject: prepare send-email for smoother change of --chain-reply-to default
Give a warning message when send-email uses chain-reply-to to thread the
messages because of the current default, not because the user explicitly
asked to, either from the command line or from the configuration.
This way, by the time 1.7.0 switches the default, everybody will be ready.
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
---
Quoting Junio C Hamano <gitster@pobox.com>
> - I do not think we have such an anti-procrastination measure for
> send-email's --[no-]chain-reply-to change. We might want to have one
> before 1.6.6 ships; namely, if the code decided to use chain-reply-to
> behaviour by default because there was no sendemail.chainreplyto (or
> sendemail.$identity.chainreplyto) configured, nor --no-chain-reply-to
> or --chain-reply-to given from the command line, we issue a big fat
> warning just like we warn against unconfigured push.denyCurrentBranch
> when allowing pushing to a checked-out branch without being told.
Like this?
git-send-email.perl | 19 +++++++++++++++++--
t/t9001-send-email.sh | 40 ++++++++++++++++++++++++++++++++++++++++
2 files changed, 57 insertions(+), 2 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 4f5da4e..2afed76 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -187,9 +187,11 @@ my ($identity, $aliasfiletype, @alias_files, @smtp_host_parts);
my ($validate, $confirm);
my (@suppress_cc);
+my $not_set_by_user = "true but not set by the user";
+
my %config_bool_settings = (
"thread" => [\$thread, 1],
- "chainreplyto" => [\$chain_reply_to, 1],
+ "chainreplyto" => [\$chain_reply_to, $not_set_by_user],
"suppressfrom" => [\$suppress_from, undef],
"signedoffbycc" => [\$signed_off_by_cc, undef],
"signedoffcc" => [\$signed_off_by_cc, undef], # Deprecated
@@ -214,6 +216,19 @@ my %config_settings = (
"from" => \$sender,
);
+# Help users prepare for 1.7.0
+sub chain_reply_to {
+ if (defined $chain_reply_to &&
+ $chain_reply_to eq $not_set_by_user) {
+ print STDERR
+ "In git 1.7.0, the default will be changed to --no-chain-reply-to\n" .
+ "Set sendemail.chainreplyto configuration variable to true if\n" .
+ "you want to keep --chain-reply-to as your default.\n";
+ $chain_reply_to = 1;
+ }
+ return $chain_reply_to;
+}
+
# Handle Uncouth Termination
sub signal_handler {
@@ -1157,7 +1172,7 @@ foreach my $t (@files) {
# set up for the next message
if ($thread && $message_was_sent &&
- ($chain_reply_to || !defined $reply_to || length($reply_to) == 0)) {
+ (chain_reply_to() || !defined $reply_to || length($reply_to) == 0)) {
$reply_to = $message_id;
if (length $references > 0) {
$references .= "\n $message_id";
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index 84a7f03..4372774 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -769,4 +769,44 @@ test_expect_success 'threading but no chain-reply-to' '
grep "In-Reply-To: " stdout
'
+test_expect_success 'no warning with an explicit --chain-reply-to' '
+ git send-email \
+ --dry-run \
+ --from="Example <nobody@example.com>" \
+ --to=nobody@example.com \
+ --chain-reply-to \
+ outdir/000?-*.patch 2>errors >out &&
+ ! grep "no-chain-reply-to" errors
+'
+
+test_expect_success 'no warning with an explicit --no-chain-reply-to' '
+ git send-email \
+ --dry-run \
+ --from="Example <nobody@example.com>" \
+ --to=nobody@example.com \
+ --no-chain-reply-to \
+ outdir/000?-*.patch 2>errors >out &&
+ ! grep "no-chain-reply-to" errors
+'
+
+test_expect_success 'no warning with sendemail.chainreplyto = false' '
+ git config sendemail.chainreplyto false &&
+ git send-email \
+ --dry-run \
+ --from="Example <nobody@example.com>" \
+ --to=nobody@example.com \
+ outdir/000?-*.patch 2>errors >out &&
+ ! grep "no-chain-reply-to" errors
+'
+
+test_expect_success 'no warning with sendemail.chainreplyto = true' '
+ git config sendemail.chainreplyto true &&
+ git send-email \
+ --dry-run \
+ --from="Example <nobody@example.com>" \
+ --to=nobody@example.com \
+ outdir/000?-*.patch 2>errors >out &&
+ ! grep "no-chain-reply-to" errors
+'
+
test_done
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply related
* Re: [PATCH 3/4] build dashless "test-bin" directory similar to installed bindir
From: Matthew Ogilvie @ 2009-11-29 2:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, peff
In-Reply-To: <7vtywefn88.fsf@alter.siamese.dyndns.org>
On Sat, Nov 28, 2009 at 11:44:39AM -0800, Junio C Hamano wrote:
> - Patch #1 and #2 are good and are independent from the later patches, as
> without them running tests with GIT_TEST_INSTALLED would not work.
>
> By the way, 6720721 (test-lib.sh: Allow running the test suite against
> installed git, 2009-03-16) failed to document the feature in t/README.
> Could you please fix this while you are at it?
Sure, I'll include another patch for this when I re-roll the
series. It will probably mention something about still needing
a build so that it can access the test-* support executables.
> - It certainly is _possible_ to add $(pwd)/test-bin to $PATH instead of
> the established practice of using GIT_EXEC_PATH for every day/permanent
> use without installation, but I doubt we should _encourage_ it for a
> few reasons:
>
> . The set-up will force one extra exec due to the wrapper; this is good
> for the purpose of running tests, but unnecessary for a set-up for
> every day/permanent use by people, compared with the already working
> approach. The user needs to change an environment variable _anyway_
> (either GIT_EXEC_PATH with the traditional approach, or PATH with
> your patch).
>
> . The new component to be added to $PATH shouldn't be named "test-bin/"
> if it is meant for every day/permanent use.
>
> . Advertising this forces the Makefile build test-bin/ contents from
> "all" target. I think test-bin/ should only depend on "test" (iow,
> after "make all && make install" there shouldn't have to be "test-bin"
> directory.
>
> I would rather treat it an unintended side-effect that you can add that
> directory to the $PATH. It is designed to work in such an environment
> (otherwise the tests won't exercise the version of git they are meant
> to test), but I do not think it is _meant_ to be _used_ by end users
> that way. And an unintended side-effect does not have to be mentioned
> in INSTALL (especially with the directory name with "test" in it).
I personally like the idea of being able to use an uninstalled
build without touching environment variables at all. Just specify
the full path to the the version you want to run on the
command line, as in: ~/SANDBOX/test-bin/git WHATEVER
Especially handy for trying "ssh MACHINE /PATH/SANDBOX/...".
FYI: There are already a number of test suite support executables
built by "make all" (test-*). It might be hard to eliminate them
from "all" without risking stale executables. As Jeff
King <peff@peff.net> pointed out in a separate email, some people
(including me) often don't use the top-level "make test" target
to run tests.
I'm still thinking about this. I've noted some possible changes
to the patch series below, some of which are mutually exclusive.
Any opinions?
Options geared towards isolating/hiding test-bin:
1. Scrap the part of the patch that modifies INSTALL.
2. Perhaps use hardlinks, symlinks, and/or copies within test-bin,
instead of wrapper scripts, to eliminate the extra exec. Since
test-lib.sh already sets up necessary environment variables,
they don't strictly need to be set in the wrappers as
well. On the other hand, hardlinks and copies are potentially
vulnerable to stale executable issues, and symlinks typically
don't work on Windows.
3. Scrap pre-built test-bin completely, and switch to a solution
that more closely resembles the valgrind option (have test-lib.sh
build the directory). This can't use the same makefile variables
to define the contents of the directory, though.
Options geared towards making something like test-bin an official way
to run an uninstalled build:
4. Rename test-bin. Perhaps "bin-wrappers", "bin-dashless",
"bin-install", "bin", or "bindir". Any preferences?
5. The current patch doesn't quite handle the simple
"~/SANDBOX/test-bin/gitSOMETHING WHATEVER" idiom perfectly
if the executable (gitSOMETHING) tries to run additional
git commands without adjusting the PATH first. I could enhance
the wrapper to prefix test-bin onto the PATH just in case it
isn't there already.
Other cleanup options:
6. There is a stale script issue if someone does something like:
make
cp -a . /some/other/path
cd /some/other/path
[optional modifications, without a "make clean"]
make
[run tests; uses wrong executables...]
Including GIT-CFLAGS as a makefile dependency for the
wrappers was intended to address this, but looking
closer, I don't think it works. Perhaps I should
include $(shell pwd) in GIT-CFLAGS, or make a new GIT-PWD target
that works similarly to GIT-CFLAGS. Without this, a workaround
(and probably best option overall) is to do a "make clean" after
copying a sandbox.
7. Enable similar dashless environment when
GIT_TEST_INSTALLED and/or valgrind are enabled?
8. Include wrappers for other dashed-commands in test-bin, which
would always fail, in case someone runs tests with an installed
GIT_EXEC_PATH already in their PATH. This might catch a new test
using dashes in such an environment. I don't really think this
is worth it, though. Most people don't have GIT_EXEC_PATH in their
PATH, and some such person would notice any problems soon.
9. This may be outside the scope of this patch series, but perhaps
git executables could try to find argv[0] in the PATH
(if argv[0] is not absolute), and see if they can find various other
executables (GIT_EXEC_PATH) and data files (perl, templates,
etc) using paths relative to itself. This may include
manually dereferencing argv[0] if it is a symlink. GIT_EXEC_PATH
and friends still takes precedence, but only fallback on
compile-time defaults if "find relative to argv[0]" fails.
It looks like Makefile RUNTIME_PREFIX enables something like
this, but it is currently disabled by default on most platforms.
--
Matthew Ogilvie [mmogilvi_git@miniinfo.net]
^ permalink raw reply
* Re: [PATCH 2/2] Add gitk-git Hungarian translation
From: Laszlo Papp @ 2009-11-29 2:33 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Laszlo Papp, git
In-Reply-To: <a362e8010911220005u1783cd44yf84ae5bc5b42d980@mail.gmail.com>
On Sun, Nov 22, 2009 at 9:05 AM, Laszlo Papp <djszapi@archlinux.us> wrote:
> On Thu, Nov 19, 2009 at 10:07 AM, Paul Mackerras <paulus@samba.org> wrote:
>> Laszlo Papp writes:
>>
>>> Signed-off-by: Laszlo Papp <djszapi@archlinux.us>
>>> ---
>>> gitk-git/po/hu.po | 1151 +++++++++++++++++++++++++++++++++++++++++++++++++++++
>>
>> Is there a patch 1/2 that needs to be applied first, as the subject
>> line might imply?
>>
>> Paul.
>>
>
> It's the file of the new hungarian translation, it can be applied
> alone without any plus file/patch.
>
> Best Regards,
> Laszlo Papp
>
Up!
^ 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