* Re: [PATCH] Optional shrinking of RCS keywords in git-p4
From: Jing Xue @ 2008-09-16 12:58 UTC (permalink / raw)
To: David Brown
Cc: Daniel Barkalow, Junio C Hamano, dhruva, GIT SCM, Simon Hausmann
In-Reply-To: <20080916041201.GA25033@linode.davidb.org>
On Mon, Sep 15, 2008 at 09:12:01PM -0700, David Brown wrote:
> A simple way to be paranoid would be something (shell-ish) like:
>
> p4 print filename | collapse-keywords | git hash-object --stdin
>
> and make sure that is the version we think the file should have
> started with. I think we're really just making sure we didn't miss a
> P4 change that someone else made underneath, and we're about to back
> out.
> Even this isn't robust from p4's point of view. The p4 model is to do
> a 'p4 edit' on the file, and then the later 'p4 submit' will give an
> error if someone else has updated the file. This would require using
> p4's conflict resolution, and I'm guessing someone using git-p4 would
> rather abort the submit and rebase.
How about collapsing the keywords in the _p4_ version after "p4 edit"
but before applying the patch, and just "p4 submit" the collapsed
version if patching succeeds? As pointed out earlier in this thread, p4
submit doesn't care about whether keywords are expanded or not anyway.
Cheers.
--
Jing Xue
^ permalink raw reply
* [PATCH] Documentation: disable sub/superscript characters ^/~
From: Thomas Rast @ 2008-09-16 12:47 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Avery Pennarun
In-Reply-To: <7vy71s7b26.fsf@gitster.siamese.dyndns.org>
Disables the special meaning of ^ and ~ as per the Asciidoc FAQ,
http://www.methods.co.nz/asciidoc/faq.html#_how_can_i_disable_a_quoted_text_substitution
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Junio C Hamano wrote:
> Sorry, but this unfortunately does not seem to help asciidoc 8.2.5 on FC9
> at all, which is the combination used at k.org machine that feeds the
> html/man branches to everybody else.
This seems to do the trick on 8.2.5 here.
Unfortunately, the changelog for 8.0 says that setting the quote
character to an empty replacement is new in 8.0 (I can't test with
7.x), and I cannot find a way to make an 'if version >= 8' block.
(Why does it have ifdef but no if?)
So maybe if someone sees a way to do this version-dependent, then we
can combine the two approaches and work with both 7.x and 8.x.
- Thomas
Documentation/asciidoc.conf | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/Documentation/asciidoc.conf b/Documentation/asciidoc.conf
index 40d43b7..37bf195 100644
--- a/Documentation/asciidoc.conf
+++ b/Documentation/asciidoc.conf
@@ -15,6 +15,11 @@ startsb=[
endsb=]
tilde=~
+# disable sub/superscripts -- they collide with our ref notation
+[quotes]
+^=
+~=
+
ifdef::backend-docbook[]
[linkgit-inlinemacro]
{0%{target}}
--
tg: (5ab2757..) t/doc-disable-tilde (depends on: next)
^ permalink raw reply related
* Re: [PATCH 15/16] checkout: add new options to support narrow checkout
From: Nguyen Thai Ngoc Duy @ 2008-09-16 12:21 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200809152205.15388.jnareb@gmail.com>
On 9/16/08, Jakub Narebski <jnareb@gmail.com> wrote:
> >> Couldn't you simply escape ':', i.e. write for example Git\:\:Tag.3pm,
> >> or Eichten_PRD21\:313,1980_erratum.tex, or \:0.log, or perhaps
> >> kmail/jnareb@gmail.com\:@pop.gmail.com\:995, or even something like
> >> Mail/inbox/cur/1194202360.32296.mprnq\:2,S, in the same way like you
> >> can escape other special characters, for example wildcard characters
> >> like '\*' for '*' and '\?' for '?', and of course '\\' for '\'?
> >
> > Sure. Somehow I forgot that.
>
>
> Well, if it is possible, it should be stated in documentation.
> Even if it is obvious.
I mean it should be possible, but not yet implemented. Next time
document will be updated when '\' escape is implemented.
> > --<--
> > Narrow checkout
> > ---------------
> >
> > Normally when you do checkout a branch, your working directory
> > will be fully populated. In some situations, you just need to
> > work on certain files, no full checkout is needed. Narrow
> > checkout is a mode that limits checkout area according to your
> > needs.
>
>
> You have decided then on the term 'narrow checkout', and not
> 'partial checkout' or 'sparse checkout', then?
Not yet. I tend to prefer partial/sparse checkout. Probably should
have a look at how other SCMs do and what term they use. If Git's
functionality is so different, a different term might notice people
about that.
> > Because narrow checkout uses new index format, it will be
> > incompatible with git prior to 1.6.0 regarding worktree operations.
> > Repository-only operations such as clone, push, pull... should not be
>
>
> s/pull/fetch/. pull affects working repository, and it can affect
> narrow checkout unexpectedly by conflicts during merge part of pull.
Bad writing. I mean pull/fetch from a narrow-checkout-ed repository to
another fully populated one. Will fix.
>
> > affected by narrow checkout. In order to make your working directory
> > work again with those versions, you can use `git checkout --full` to
> > return to normal mode (and compatible index format).
>
>
> By the way, you have made "git checkout <file>" get file and mark
> it "wanted", i.e. clear/zero "no-checkout" bit. Wouldn't then
> "git checkout ." be shorter equivalent to "git checkout --full"?
> I'm not saying that '--full' option should be abandoned...
It is not equivalent. "git checkout ." will happily overwrite any
modified files in your working directory.
>
> >
> > In narrow checkout mode, checkout status of every files in your
> > working directory will be recorded in index. If a file is marked
> > "no-checkout", it means that file is not needed to be present in
> > working directory by user or any git command. When a new file is added
> > to index, it will be marked "checkout" unless narrow spec is applied.
> > Unmerged files are always "checkout". linkgit:git-update-index[1] can
> > be used to update "checkout/no-checkout" status in index. When you
> > checkout new files using "git checkout <file>" they will be
> > automatically marked "checkout". Other commands such as "git apply"
> > can also checkout new files if they are needed.
> >
> > "No-checkout" status is very similar to "assume-unchanged bit"
> > (see linkgit:git-update-index[1]). The main difference between them
> > is "assume unchanged" bit just ignores corresponding files in working
> > directory while narrow checkout goes a bit farther, remove those files
> > when it is safe to do so.
>
>
> Good description (although probably could be improved even further).
Contributions are welcome ;)
>
> >
> > When you apply new narrow spec to your working directory using either
> > --path, --add-path or --remove-path, it will update "checkout" status
> > in index accordingly. Moreover, if a file is marked "no-checkout" and
> > is present in working directory, it will be removed. If a file is
> > turned from "no-checkout" to "checkout", then it will be added again
> > to working directory. Modified and unmerged entries can't bear
> > "no-checkout" status, if narrow spec applies to them, "git checkout"
> > will refuse to update working directory.
>
>
> Do I understand correctly, that if one uses --path=<colon separated list>
> _only_ filenames matching one of patterns specified would be checked out,
> --add-path=<path> would additionally checkout given path and mark "wanted",
> and --remove-path=<path> would additionally mark "no-checkout" and remove
> path?
--add-path/--remove-path also use narrow spec, which could be more
than one pattern.
> What --add-path starts from, i.e. does
>
> $ git checkout --add-path=.gitignore
>
> starts from empty set if --add-path is first, or from full set as without
> --add-path?
I'm not sure I understand this.
> And is <pathspec> matched against full pathname, or like .gitignore
> rules, i.e. as full pathname if it has at least one '/' in it?
like shell wildcard, full pathname must match. On my way back home, I
thought I should have removed mention of "pathspec", which behaves a
little bit different.
Also those specs are relative to working directory though, so if you
are in b/c and want to match d, you only need to type --add-path=d
instead of --add-path=b/c/d. Will add this to doc.
>
> >
> > Narrow spec is not saved by "git checkout". You can form your checkout
> > area on one go with --path option, or do it incrementally
> > with --add-path and --remove-path.
> > --<--
>
>
> I would probably say that specification used to select which paths to
> check out is not saved anywhere, and used only to mark paths in index
> as "no-checkout" or not. Or somehing like that.
>
Thanks (as for other parts of your comments stripped by me)
--
Duy
^ permalink raw reply
* Re: [PATCH 16/16] ls-files: add --overlay option
From: Nguyen Thai Ngoc Duy @ 2008-09-16 12:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vljxtb3tf.fsf@gitster.siamese.dyndns.org>
On 9/16/08, Junio C Hamano <gitster@pobox.com> wrote:
> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
>
> > The same situation happens for "assume unchanged" bit, but I would
> > expect narrow checkout to be more user-friendly and should notify users
> > these cases so users will not be confused. On this first step, users
>
> > may check by themselves with "git ls-files --overlay",...
>
> Could you explain how the earlier --narrow-checkout option introduced in
> [05/16] interacts with this one?
>
> The user has X inside narrow area and Y outside. ls-files reports both X
> and Y. 'ls-files --narrow-checkout' reports only X. Y is tracked but not
> really, so 'ls-files --narrow-checkout -o' shouldn't say Y is untracked;
> there is no cue to tell between X and Y.
Right, "ls-files -o" should not list Y as untracked.
> But with a half of your patch to 'ls-files -t', you already can show these
> potentially stale (leftover from an ancient checkout un-updated because of
> narrowness) files. Could a simpler alternative be to do this processing
> not inside "if (show_deleted/modified)" part of show_files(), but inside
> "if (show_cached/stage)" part of it? Instead of saying tag_cached
> unconditionally, if the entry is marked no_checkout, then you would
> lstat(2) it there and report that the path is "marked not to be checked
> out but somehow something exists there".
Yes, makes sense.
> By the way, I do not see an easy way to review what paths are marked with
> no-checkout easily from your command set. It might be worthwhile to add a
> new option that iterates over the index, finds a set of common prefixes to
> no-checkout entries and reports that set.
What is it for? I can only think of it (actually the opposite, find a
set of common prefixes to checkout entries) as a way to reconstruct
narrow spec (simple rules only).
--
Duy
^ permalink raw reply
* Re: [PATCH 11/16] unpack_trees(): add support for narrow checkout
From: Nguyen Thai Ngoc Duy @ 2008-09-16 11:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vsks1b3tq.fsf@gitster.siamese.dyndns.org>
On 9/16/08, Junio C Hamano <gitster@pobox.com> wrote:
> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
>
> > diff --git a/cache.h b/cache.h
> > index 2b2c90f..1fc0f83 100644
> > --- a/cache.h
> > +++ b/cache.h
> > @@ -167,6 +167,9 @@ struct cache_entry {
> > #define CE_HASHED (0x100000)
> > #define CE_UNHASHED (0x200000)
> >
> > +/* Only remove in work directory, not index */
> > +#define CE_WD_REMOVE (0x400000)
> > +
> > /*
> > * Extended on-disk flags
> > */
> > diff --git a/unpack-trees.c b/unpack-trees.c
> > index e59d144..968cc98 100644
> > --- a/unpack-trees.c
> > +++ b/unpack-trees.c
> > @@ -96,6 +96,15 @@ static int check_updates(struct unpack_trees_options *o)
> > if (o->update && o->verbose_update) {
> > for (total = cnt = 0; cnt < index->cache_nr; cnt++) {
> > struct cache_entry *ce = index->cache[cnt];
> > +
> > + if (ce->ce_flags & CE_WD_REMOVE) {
> > + total++;
> > + continue;
> > + }
> > +
> > + if (ce_no_checkout(ce))
> > + continue;
> > +
> > if (ce->ce_flags & (CE_UPDATE | CE_REMOVE))
> > total++;
> > }
>
>
> This check for ce_no_checkout() before the existing check to see if
> CE_UPDATE and/or CE_REMOVE are on puzzles me (you have the same check
> sequence in later loop that does the actualy worktree updates). If
> apply_narrow_checkout() check is working correctly, would we ever give
> CE_UPDATE and/or CE_REMOVE bits to a cache entry with CE_NO_CHECKOUT set?
>
> IOW, I think this extra check is Ok as it is expected to be no-op when
> combined with the existing check, but it leaves me wondering if it is
> hiding some codepath that incorrectly sets CE_UPDATE/CE_REMOVE to an entry
> outside the narrow checkout area.
Gaaah.. I was confused with older series where verify_uptodate() was
patched to ignore missing files. You are right, the check is not
necessary, will need more test for this. With the current patch, it
will fail to merge as soon as some files need to be updated outside
narrow area.
--
Duy
^ permalink raw reply
* Re: [PATCH 15/16] checkout: add new options to support narrow checkout
From: Johannes Sixt @ 2008-09-16 10:17 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1221397685-27715-16-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy schrieb:
> +--full::
> + Quit narrow checkout mode. Return to full checkout.
> +
> +--path=<narrow_spec>::
> + Re-apply new narrow spec on current working directory to
> + form new checkout area.
> +
> +--add-path=<narrow_spec>::
> + Checkout more areas specified by narrow spec to current
> + checkout area.
> +
> +--remove-path=<narrow_spec>::
> + Narrow checkout area by removing files specified by narrow spec
> + from current checkout area. This operation will fail if there
> + is unmerged or modified files in the removing areas.
The option --path is named a bit too generic for my taste. How about
--narrow=...? And how would you like --more= instead of --add-path= and
--less= instead of --remove-path=? I do think that --full is OK.
-- Hannes
^ permalink raw reply
* Re: [PATCH 15/16] checkout: add new options to support narrow checkout
From: Baz @ 2008-09-16 9:53 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1221397685-27715-16-git-send-email-pclouds@gmail.com>
Just a few minor grammar nits and typos in the docs, and one leftover
mention of 'sparse' that should be 'narrow'.
On Sun, Sep 14, 2008 at 2:08 PM, Nguyễn Thái Ngọc Duy <pclouds@gmail.com> wrote:
> These options include:
>
> --full: return to full checkout (default)
> --path: narrow checkout to some areas according to given spec
> --add-path/--remove-path: adjust current narrow checkout
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
> Documentation/git-checkout.txt | 68 +++++++++++++++++++++++++++++++++-
> builtin-checkout.c | 44 ++++++++++++++++++++++
> t/t2011-checkout-narrow.sh | 80 ++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 190 insertions(+), 2 deletions(-)
> create mode 100755 t/t2011-checkout-narrow.sh
>
> diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
> index 82e154d..2ae483b 100644
> --- a/Documentation/git-checkout.txt
> +++ b/Documentation/git-checkout.txt
> @@ -8,8 +8,10 @@ git-checkout - Checkout a branch or paths to the working tree
> SYNOPSIS
> --------
> [verse]
> -'git checkout' [-q] [-f] [--track | --no-track] [-b <new_branch> [-l]] [-m] [<branch>]
> -'git checkout' [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <paths>...
> +'git checkout' [-q] [-f] [--track | --no-track] [-b <new_branch> [-l]] [-m]
> + [<narrow options>] [<branch>]
> +'git checkout' [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>]
> + [<narrow options>] [--] <paths>...
>
> DESCRIPTION
> -----------
> @@ -34,6 +36,10 @@ used to specify a specific tree-ish (i.e. commit, tag or tree)
> to update the index for the given paths before updating the
> working tree.
>
> +<narrow options> include --full, --path, --add-path and --remove-path.
> +The last three require narrow spec. Please refer to "narrow checkout"
> +section to have more information about this mode.
s/to have/for/
> +
> The index may contain unmerged entries after a failed merge. By
> default, if you try to check out such an entry from the index, the
> checkout operation will fail and nothing will be checked out.
> @@ -108,6 +114,22 @@ exlicitly give a name with '-b' in such a case.
> However, with this option, a three-way merge between the current
> branch, your working tree contents, and the new branch
> is done, and you will be on the new branch.
> +
> +--full::
> + Quit narrow checkout mode. Return to full checkout.
> +
> +--path=<narrow_spec>::
> + Re-apply new narrow spec on current working directory to
> + form new checkout area.
> +
> +--add-path=<narrow_spec>::
> + Checkout more areas specified by narrow spec to current
> + checkout area.
> +
> +--remove-path=<narrow_spec>::
> + Narrow checkout area by removing files specified by narrow spec
> + from current checkout area. This operation will fail if there
> + is unmerged or modified files in the removing areas.
s/is/are/
> +
> When a merge conflict happens, the index entries for conflicting
> paths are left unmerged, and you need to resolve the conflicts
> @@ -171,6 +193,48 @@ the reflog for HEAD where you were, e.g.
> $ git log -g -2 HEAD
> ------------
>
> +Narrow checkout
> +---------------
> +
> +Normally when you do checkout a branch, your working directory
s/do//
> +will be fully populated. In some situations, you just need to
> +work on certain files, no full checkout is required. Narrow
> +checkout is a mode that limits checkout area according to your
s/limits checkout area/limits the checkout area/
> +rules.
> +
> +Because narrow checkout uses new index format, it will be
s/uses new index format/uses a new index format/
> +incompatible with git prior to 1.6.0. In order to make your
> +working directory work with those versions, you can use `git
> +checkout --full` to return to normal mode (and compatible index
> +format).
> +
> +Narrow works by applying your rules to the index, marking which
> +file you need and which file you need not. Modified/Unmerged
s/file you need and file you need not/files you need and which you do not/
> +files cannot be marked unneeded. Unnecessary files will be
This reads a bit awkwardly. 'marked as unneeded' maybe, or 'marked
"unneeded"' as you've done elsewhere.
> +removed from working directory. Note that after this step,
> +removed files can still be added to working directory when they
> +are needed by any git command. For example, when you have a merge
> +conflict, conflicted files will be checked out on working
> +directory and will no longer be marked "unneeded".
> +
> +New files after merges will always be "needed". You can also
> +apply rules when switching branches to avoid unwanted new files.
> +
> +Files that are marked "no-checkout" will be treated like entries
> +with "assume-unchanged bit" (see linkgit:git-update-index[1]). In
> +short, Git will never look for those files in working directory
> +no matter whether they exist in working directory.
> +
> +You can apply your rules at once with --path option, or do it
> +incrementally with --add-path and --remove-path.
> +
> +Narrow spec will be used to specify how you want to narrow your
"The narrow spec specifies how you want to narrow your..."
> +checkout. It is a list of pathspecs separated by colons. Each
> +patchspec specifies what files should be checked out on working
pathspec here, not patchspec.
> +directory. Pathspec can contain wildcards and is relative to
> +current working directory. Usually asterisk (*) does not match
> +slashes. If a pathspec is prefixed by a plus sign (+), then
> +any asterisk will match anything, even slashes.
>
> EXAMPLES
> --------
> diff --git a/builtin-checkout.c b/builtin-checkout.c
> index c7b0aad..b6bc3c5 100644
> --- a/builtin-checkout.c
> +++ b/builtin-checkout.c
> @@ -33,6 +33,12 @@ struct checkout_opts {
> const char *new_branch;
> int new_branch_log;
> enum branch_track track;
> +
> + const char *prefix;
> + char *new_path;
> + char *add_path;
> + char *remove_path;
> + int no_narrow_checkout;
> };
>
> static int post_checkout_hook(struct commit *old, struct commit *new,
> @@ -412,6 +418,24 @@ static int merge_working_tree(struct checkout_opts *opts,
> tree = parse_tree_indirect(new->commit->object.sha1);
> init_tree_desc(&trees[1], tree->buffer, tree->size);
>
> + topts.narrow_prefix = opts->prefix;
> + if (opts->no_narrow_checkout) {
> + /* leave narrow_spec NULL */
> + topts.new_narrow_path = 1;
> + }
> + else if (opts->new_path) {
> + topts.narrow_spec = opts->new_path;
> + topts.new_narrow_path = 1;
> + }
> + else if (opts->add_path) {
> + topts.narrow_spec = opts->add_path;
> + topts.add_narrow_path = 1;
> + }
> + else if (opts->remove_path) {
> + topts.narrow_spec = opts->remove_path;
> + topts.remove_narrow_path = 1;
> + }
> +
> ret = unpack_trees(2, trees, &topts);
> if (ret == -1) {
> /*
> @@ -600,6 +624,10 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
> OPT_BOOLEAN('m', "merge", &opts.merge, "merge"),
> OPT_STRING(0, "conflict", &conflict_style, "style",
> "conflict style (merge or diff3)"),
> + OPT_BOOLEAN(0, "full", &opts.no_narrow_checkout, "quit sparse checkout"),
s/quit sparse checkout/quit narrow checkout mode/
As per your documentation above. I noticed this because I was
searching for 'sparse checkout' and was surprised when only one mail
in a patch series matched :)
Hope this helps,
Baz
> + OPT_STRING(0, "path", &opts.new_path, "prefixes", "apply new narrow checkout path"),
> + OPT_STRING(0, "add-path", &opts.add_path, "prefixes", "add more checkout area"),
> + OPT_STRING(0, "remove-path", &opts.remove_path, "prefixes", "narrow checkout area"),
> OPT_END(),
> };
> int has_dash_dash;
> @@ -610,6 +638,7 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
> git_config(git_checkout_config, NULL);
>
> opts.track = BRANCH_TRACK_UNSPECIFIED;
> + opts.prefix = prefix;
>
> argc = parse_options(argc, argv, options, checkout_usage,
> PARSE_OPT_KEEP_DASHDASH);
> @@ -639,6 +668,18 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
> if (!opts.new_branch && (opts.track != git_branch_track))
> die("git checkout: --track and --no-track require -b");
>
> + if (((opts.no_narrow_checkout ? 1 : 0) +
> + (opts.new_path ? 1 : 0) +
> + (opts.add_path ? 1 : 0) +
> + (opts.remove_path ? 1 : 0)) > 1)
> + die("git checkout: --path, --full, --add-path and --remove-path are incompatible");
> +
> + if (opts.new_branch && (opts.add_path || opts.remove_path))
> + die("git checkout: --add-path and --remove-path should only be used on current branch");
> +
> + if (opts.new_branch && opts.no_narrow_checkout)
> + die("git checkout: switching branch with --full does not make sense");
> +
> if (opts.force && opts.merge)
> die("git checkout: -f and -m are incompatible");
>
> @@ -732,6 +773,9 @@ no_reference:
> if (1 < !!opts.writeout_stage + !!opts.force + !!opts.merge)
> die("git checkout: --ours/--theirs, --force and --merge are incompatible when\nchecking out of the index.");
>
> + if (opts.no_narrow_checkout || opts.new_path || opts.add_path || opts.remove_path)
> + die("git checkout: updating paths is incompatible with setting sparse checkout");
> +
> return checkout_paths(source_tree, pathspec, &opts);
> }
>
> diff --git a/t/t2011-checkout-narrow.sh b/t/t2011-checkout-narrow.sh
> new file mode 100755
> index 0000000..77b99e1
> --- /dev/null
> +++ b/t/t2011-checkout-narrow.sh
> @@ -0,0 +1,80 @@
> +#!/bin/sh
> +
> +test_description='narrow checkout'
> +
> +. ./test-lib.sh
> +
> +test_expect_success setup '
> + mkdir work1 work2 work3
> + touch one two three
> + touch work1/one work2/two work3/three
> + git add one work1/one
> + git commit -m work1
> + git add two work2/two
> + git commit -m work2
> + git add three work3/three
> + git commit -m work3
> +'
> +
> +test_expect_success '--full on no-narrow checkout' '
> + git checkout --full
> +'
> +
> +test_expect_success '--full and --path incompatible' '
> + test_must_fail git checkout --full --path=work1
> +'
> +
> +test_expect_success 'limit worktree to work1 and work2' '
> + git checkout --path="work1/*:work2/*" &&
> + test -f work1/one &&
> + test -f work2/two &&
> + ! test -f work3/three
> +'
> +
> +test_expect_success 'update worktree to work2 and work3' '
> + git checkout --path="work2/*:work3/*" &&
> + ! test -f work1/one &&
> + test -f work2/two &&
> + test -f work3/three
> +'
> +
> +test_expect_success 'update narrow prefix with modification' '
> + echo modified >> work2/two &&
> + git checkout --path="work1/*:work2/*" &&
> + test -f work1/one &&
> + test -f work2/two &&
> + ! test -f work3/three &&
> + grep -q modified work2/two
> +'
> +
> +test_expect_success 'update narrow should not lose modification' '
> + ! git checkout --path="work1/*:work3/*" &&
> + test -f work1/one &&
> + test -f work2/two &&
> + ! test -f work3/three &&
> + grep -q modified work2/two
> +'
> +
> +test_expect_success 'widen checkout area' '
> + git checkout --add-path="work3/*" &&
> + test -f work1/one &&
> + test -f work2/two &&
> + test -f work3/three
> +'
> +
> +test_expect_success 'narrow checkout area' '
> + git checkout --remove-path="work3/*" &&
> + test -f work1/one &&
> + test -f work2/two &&
> + ! test -f work3/three
> +'
> +
> +test_expect_success 'exit narrow checkout' '
> + git checkout --full &&
> + test -f work1/one &&
> + test -f work2/two &&
> + test -f work3/three &&
> + test one
> +'
> +
> +test_done
> --
> 1.6.0.96.g2fad1.dirty
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH] Documentation: replace [^~] with escapes everywhere
From: Junio C Hamano @ 2008-09-16 8:24 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Thomas Rast, git, Junio C Hamano
In-Reply-To: <32541b130809151710j59963af9id84b3c1553ec738d@mail.gmail.com>
"Avery Pennarun" <apenwarr@gmail.com> writes:
> On Mon, Sep 15, 2008 at 8:05 PM, Thomas Rast <trast@student.ethz.ch> wrote:
>> Avery Pennarun wrote:
>>> Rather than uglifying all the documentation to work around the syntax,
>>> perhaps we just want to disable subscripts and superscripts
>>> altogether? I can't really imagine the git documentation needing
>>> them.
>>>
>>> To do so, we can add these lines to asciidoc.conf (I just did this on
>>> another project yesterday, but I haven't tested in git.git):
>>>
>>> [replacements]
>>> # Disable superscripts.
>>> \^(.+?)\^=^\1^
>>> # Disable subscripts.
>>> ~(.+?)~=~\1~
>>
>> That's indeed a far superior solution. I withdraw my patches in
>> favour of this.
>
> Er, do you mind submitting (and testing :)) a new patch that does it?
> I don't have time right now.
Sorry, but this unfortunately does not seem to help asciidoc 8.2.5 on FC9
at all, which is the combination used at k.org machine that feeds the
html/man branches to everybody else.
asciidoc 7.1.2 on Deb does not have the problem in git-bundle.html to
begin with, but it does have the same issue in git-show-ref.html, which
the patch does fix.
diff --git a/Documentation/asciidoc.conf b/Documentation/asciidoc.conf
index 40d43b7..8fcdb54 100644
--- a/Documentation/asciidoc.conf
+++ b/Documentation/asciidoc.conf
@@ -15,6 +15,12 @@ startsb=[
endsb=]
tilde=~
+[replacements]
+# Disable superscripts.
+\^(.+?)\^=^\1^
+# Disable subscripts.
+~(.+?)~=~\1~
+
ifdef::backend-docbook[]
[linkgit-inlinemacro]
{0%{target}}
^ permalink raw reply related
* Re: Management of opendocument (openoffice.org) files in git
From: Paolo Bonzini @ 2008-09-16 8:12 UTC (permalink / raw)
To: Sergio Callegari; +Cc: Git Mailing List
In-Reply-To: <48CF5ABC.5060507@gmail.com>
> With regards to
>
>> And maybe -b,-qq,-X and -q,-r respectively could be added by default?
>>
>>
> I would prefer not to do so: if you do you get something that is
> somehow "specialised", otherwise you have a totally generic "rezipper"
> that might also find other applications (who knows).
Yeah, but regarding -b/-X, their effect can/should be undone with zip
command line options (-l, -ll, -X). And for zip's -r option, a rezipper
that by default only rezips the top directory does not seem very useful. :-)
You're right about letting the user specify -qq/-q. Or maybe you can
have a -q/--quiet option to rezip that adds both -qq to unzip, and -q to
zip. This way you can use the openoffice profile both in quiet mode
(for git) and in non-quiet mode (for manual use).
Putting all of this together, it would make the filter look like this:
[filter "opendocument"]
clean = "rezip --quiet --zip-opts -D,-0"
smudge = "rezip --quiet --zip-opts -D,-6"
or similarly with profiles:
[filter "opendocument"]
clean = "rezip --quiet -p ODF_UNCOMPRESS"
smudge = "rezip --quiet -p ODF_COMPRESS"
After my signature you can find my attempt at making rezip more useful
as a general program. It supports --quiet, multiple input files, and -
for stdin. (And I learnt from you that >&$foo works).
> BTW, that is why I added the profiles, so that there was no need to type
> repetitive stuff.
Understood.
Paolo
-----8<-----------------------
#! /bin/sh
#
# (c) 2008 Sergio Callegari
#
# Rewrites a zip archive, possibly changing the compression level
USAGE='Usage: rezip OPTIONS FILE...
with options:
-h, --help Gives help
--unzip-opts OPTIONS Pass options to unzip helper to read zip file
--zip-opts OPTIONS Pass options to zip helper to write zip file
-p, --profile PROFILE Get options for helpers from profile
-q, --quiet Make unzip and zip quiet
Rewrites a zip archive, possibily changing the compression level.
If the archive name is unspecified or "-", then the command operates
like a filter, reading from standard input and writing to standard
output. Options (either space- or comma-separated) can be manually
provided to the unzip process doing the read and to the zip process
doing the write. Alternatively a profile can be used to set options
automatically.'
PROFILES="ODF_UNCOMPRESS ODF_COMPRESS"
PROFILE_UNZIP_ODF_UNCOMPRESS=
PROFILE_ZIP_ODF_UNCOMPRESS=-D,-0
PROFILE_UNZIP_ODF_COMPRESS=
PROFILE_ZIP_ODF_COMPRESS=-D,-6
die()
{
echo "$3$USAGE
Available profiles: ${PROFILES}" >&$1
exit $2
}
UNZIP_OPTS=""
ZIP_OPTS=""
while true ; do
case "$1" in
-h | --help)
die 1 0 ;;
# TODO: handle -p*, --profile=* and similarly for other options
-p | --profile)
eval UNZIP_OPTS=\$PROFILE_UNZIP_$2
eval ZIP_OPTS=\$PROFILE_ZIP_$2
shift ;;
--unzip-opts)
UNZIP_OPTS="${UNZIP_OPTS} $2"
shift ;;
--zip-opts)
ZIP_OPTS="${ZIP_OPTS} $2"
shift ;;
-q | --quiet)
UNZIP_QUIET=-qq
ZIP_QUIET=-q ;;
-*)
die 2 1 "Invalid option: $1
" ;;
*)
break ;;
esac
shift
done
UNZIP_OPTS="$UNZIP_QUIET -b -X `echo $UNZIP_OPTS | sed 'y/,/ /'`"
ZIP_OPTS="$ZIP_QUIET -r `echo $ZIP_OPTS | sed 'y/,/ /'`"
if [ $# = 0 ] ; then
set fnord -
shift
fi
redir=1
for filename
do
if [ "$filename" = - ]; then
redir=2
break
fi
done
for filename
do
workdir=`mktemp -d -t rezip.workdir.XXXXXX`
if [ "$filename" = - ]; then
tmpcopy=:
filename=`mktemp rezip.zip.XXXXXX`
cat > $filename
else
tmpcopy=false
fi
(case $filename in
/*) ;;
*) filename=`pwd`/$filename ;;
esac
cd "$workdir"
unzip $UNZIP_OPTS "$filename" >&$redir
zip $ZIP_OPTS "$filename" . >&$redir)
rm -fr "$workdir"
if $tmpcopy ; then
cat "$filename"
rm "$filename"
fi
done
--------8<------------------------
^ permalink raw reply
* Re: Grafts workflow for a "shallow" repository...?
From: Björn Steinbrink @ 2008-09-16 8:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, Martin Langhoff, Git Mailing List
In-Reply-To: <7v3ak08v5l.fsf@gitster.siamese.dyndns.org>
On 2008.09.15 23:25:10 -0700, Junio C Hamano wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
> > Martin Langhoff <martin.langhoff@gmail.com> wrote:
> >> Here is my attempt at a "let's publish a shallow repository for branch
> >> of moodle". Let me show you what I did...
> > ...
> >> # 1.7 was a significant release, anything earlier than that
> >> # is just not interesting -- even for pickaxe/annotate purposes
> >> # so add a graft point right at the branching point.
> > ...
> >> Is this kind of workflow (or a variation of it) supported? For this to
> >> work, we should communicate the grafts in some push operations and
> >> read them in clone ops - and perhaps in fetch too.
> > ...
> > I think that in this case the best thing to do is give users
> > a shell script that does roughly:
> >
> > git init
> > echo $BASE >.git/info/grafts
> > git remote add -f origin $url
> > git checkout -b master origin/master
> >
> > Sign the script, and let users verify it before executing. You may
> > also want a script to drag in the history behind by removing the
> > graft and fetching $BASE^, but that is hard because your repository
> > already "has" that.
>
> Why not just filter-branch _once at the origin_ and publish the result?
I think the idea was to have a shallow clone starting at a certain
point, as opposed to the --depth option, where you cannot specify a
starting point, but only the depth of the clone.
Björn
^ permalink raw reply
* [PATCH] contrib: add a 'git difftool' command for driving common merge tools
From: David Aguilar @ 2008-09-16 7:57 UTC (permalink / raw)
To: gitster; +Cc: git, tytso
'git-difftool' is a git command that allows you to compare and edit files
between revisions using standard git merge tools. At its most basic level,
'git-difftool' does what 'git-mergetool' does but its use is for non-merge
situations, such as when preparing commits or comparing changes against
the index. It uses the same configuration variables as git-mergetool,
so it automagically supports existing custom merge tool configurations.
'git-difftool' shows differences between the work tree and the index by
default but can also show differences between arbitrary commits by using
the --start and --end options. When operating on the index, saving the
merged file from within the merge tool (and a successful exit code) will
instruct 'git-difftool' to stage the new content for commit.
Signed-off-by: David Aguilar <davvid@gmail.com>
---
git-difftool was adapted from git-mergetool, so there's some common code.
If people like this enough to move it out of contrib then I'll happily help
factor out the similarities.
Every CVS user I've met has asked for the functionality provided by this
command in one form or another. For some reason they just can't let go of
their side-by-side diff viewer.
contrib/difftool/git-difftool.sh | 538 +++++++++++++++++++++++++++++++++++++
contrib/difftool/git-difftool.txt | 130 +++++++++
2 files changed, 668 insertions(+), 0 deletions(-)
diff --git a/contrib/difftool/git-difftool.sh b/contrib/difftool/git-difftool.sh
new file mode 100755
index 0000000..bafd650
--- /dev/null
+++ b/contrib/difftool/git-difftool.sh
@@ -0,0 +1,538 @@
+#!/bin/sh
+#
+# This program uses merge tools to stage and compare commits
+#
+# Copyright (c) 2008 David Aguilar
+#
+# Adapted from git-mergetool.sh
+# Copyright (c) 2006 Theodore Y. Ts'o
+#
+# This file is licensed under the GPL v2, or a later version
+# at the discretion of Junio C Hamano.
+#
+USAGE='[--tool=tool] [--commit=ref] [--start=ref --end=ref] [--no-prompt] [file to merge] ...'
+SUBDIRECTORY_OK=Yes
+OPTIONS_SPEC=
+. git-sh-setup
+require_work_tree
+cd_to_toplevel
+dirname=
+keep_backup_mode="$(git config --bool mergetool.keepBackup || echo true)"
+
+keep_backup () {
+ test "$keep_backup_mode" = "true"
+}
+
+parse_arg () {
+ expr "z$1" : 'z-[^=]*=\(.*\)'
+}
+
+index_present () {
+ test -n "$index_mode"
+}
+
+modified_present () {
+ test -n "$modified_mode"
+}
+
+commitish_present () {
+ test -n "$commitish"
+}
+
+should_prompt () {
+ ! test -n "$no_prompt"
+}
+
+use_rev_range () {
+ test -n "$start" && test -n "$end"
+}
+
+handle_dir () {
+ test -n "$non_existant_dir"
+}
+
+merge_three () {
+ index_present && modified_present && ! use_rev_range
+}
+
+modified_files () {
+ if use_rev_range; then
+ git diff --name-only "$start".."$end" -- "$@" 2>/dev/null
+ elif commitish_present; then
+ git diff --name-only "$commitish" -- "$@" 2>/dev/null
+ else
+ git diff --name-only -- "$@" 2>/dev/null
+ fi
+}
+
+staged_files() {
+ git diff --name-only --cached "$@" 2>/dev/null
+}
+
+cleanup_temp_files () {
+ if keep_backup && test "$MERGED" -nt "$BACKUP"; then
+ test -f "$BACKUP" && mv -- "$BACKUP" "$MERGED.orig"
+ rm -f -- "$LOCAL" "$REMOTE" "$BASE"
+ else
+ rm -f -- "$LOCAL" "$REMOTE" "$BASE" "$BACKUP"
+ fi
+ handle_dir && rmdir -p "$dirname"
+}
+
+check_unchanged () {
+ if test "$MERGED" -nt "$BACKUP"; then
+ status=0
+ else
+ status=1
+ use_rev_range && status=0 # we don't 'git add' in rev-range mode
+ if ! use_rev_range && should_prompt; then
+ while true
+ do
+ printf "\n$MERGED seems unchanged.\n"
+ printf "Was the merge successful? [y/n] "
+ read answer < /dev/tty
+ case "$answer" in
+ y*|Y*) status=0; break ;;
+ n*|N*) status=1; break ;;
+ esac
+ done
+ fi
+ fi
+}
+
+merge_file ()
+{
+ MERGED="$1"
+
+ modified_mode=$(modified_files "$MERGED")
+ index_mode=$(staged_files "$MERGED")
+
+ if ! modified_present && use_rev_range; then
+ echo "$MERGED: no changes between '$start' and '$end'."
+ exit 1
+ elif ! modified_present && ! index_present; then
+ if ! test -f "$MERGED"; then
+ echo $(pwd)
+ echo "$MERGED: file not found"
+ else
+ echo "$MERGED: file is unchanged."
+ fi
+ exit 1
+ fi
+
+ dirname=$(dirname "$MERGED")
+ test -d "$dirname" || non_existant_dir=true
+ handle_dir && mkdir -p "$dirname"
+
+ ext="$$$(expr "$MERGED" : '.*\(\.[^/]*\)$')"
+ BACKUP="./$MERGED.BACKUP.$ext"
+
+ test -f "$MERGED" &&
+ mv -- "$MERGED" "$BACKUP" &&
+ cp -- "$BACKUP" "$MERGED"
+
+ if use_rev_range; then
+ BASE="./$MERGED.LOCAL.$ext"
+ LOCAL="./$MERGED.START.$ext"
+ REMOTE="./$MERGED.END.$ext"
+ base=local
+ local=start
+ remote=end
+
+ if ! git show "$start":"$MERGED" > "$LOCAL" 2>/dev/null; then
+ cleanup_temp_files;
+ if ! should_prompt; then
+ echo "$MERGED does not exist at $start"
+ exit 1
+ fi
+ return
+ fi
+ if ! git show "$end":"$MERGED" > "$REMOTE" 2>/dev/null; then
+ cleanup_temp_files;
+ if ! should_prompt; then
+ echo "$MERGED does not exist at $end"
+ exit 1
+ fi
+ return
+ fi
+
+ # $BASE could be used by custom mergetool commands, so provide it.
+ # $MERGED might not exist in the worktree, start or end so commit
+ # so check in that order.
+ if test -f "$MERGED"; then
+ cp -- "$MERGED" "$BASE"
+ elif test -f "$REMOTE"; then
+ cp -- "$REMOTE" "$BASE"
+ elif test -f "$LOCAL"; then
+ cp -- "$LOCAL" "$BASE"
+ else
+ touch "$BASE"
+ fi
+ else
+ base=index
+ local=local
+ remote=${commitish-HEAD}
+ LOCAL="./$MERGED.LOCAL.$ext"
+ REMOTE="./$MERGED.HEAD.$ext"
+ BASE="./$MERGED.INDEX.$ext"
+ cp -- "$MERGED" "$LOCAL"
+ git show "$remote":"$MERGED" > "$REMOTE" 2>&1
+ # If changes are present in the index use them as $BASE
+ git checkout-index --prefix=.index- "$MERGED"
+ mv -- .index-"$MERGED" "$BASE"
+ fi
+
+ if should_prompt; then
+ printf "\nEditing '$MERGED':\n"
+ printf "Hit return to start merge tool (%s): " "$merge_tool"
+ read ans
+ fi
+
+ case "$merge_tool" in
+ kdiff3)
+ basename=$(basename "$MERGED")
+ if merge_three; then
+ (
+ "$merge_tool_path" --auto \
+ --L1 "[$base] $basename" \
+ --L2 "[$local] $basename" \
+ --L3 "[$remote] $basename" \
+ -o "$MERGED" "$BASE" "$LOCAL" "$REMOTE" \
+ > /dev/null 2>&1
+ )
+ else
+ (
+ "$merge_tool_path" --auto \
+ --L1 "[$local] $basename" \
+ --L2 "[$remote] $basename" \
+ -o "$MERGED" "$LOCAL" "$REMOTE" \
+ > /dev/null 2>&1
+ )
+ fi
+ status=$?
+ ;;
+
+ tkdiff)
+ if merge_three; then
+ "$merge_tool_path" \
+ -a "$BASE" \
+ -o "$MERGED" "$LOCAL" "$REMOTE"
+ else
+ "$merge_tool_path" \
+ -o "$MERGED" "$LOCAL" "$REMOTE"
+ fi
+ status=$?
+ ;;
+
+ meld|vimdiff)
+ "$merge_tool_path" "$LOCAL" "$MERGED" "$REMOTE"
+ check_unchanged
+ ;;
+
+ gvimdiff)
+ "$merge_tool_path" -f "$LOCAL" "$MERGED" "$REMOTE"
+ check_unchanged
+ ;;
+
+ xxdiff)
+ if merge_three; then
+ "$merge_tool_path" -X --show-merged-pane \
+ -R 'Accel.SaveAsMerged: "Ctrl-S"' \
+ -R 'Accel.Search: "Ctrl+F"' \
+ -R 'Accel.SearchForward: "Ctrl-G"' \
+ --merged-file "$MERGED" \
+ "$LOCAL" "$BASE" "$REMOTE"
+ else
+ "$merge_tool_path" -X --show-merged-pane \
+ -R 'Accel.SaveAsMerged: "Ctrl-S"' \
+ -R 'Accel.Search: "Ctrl+F"' \
+ -R 'Accel.SearchForward: "Ctrl-G"' \
+ --merged-file "$MERGED" \
+ "$LOCAL" "$REMOTE"
+ fi
+ check_unchanged
+ ;;
+
+ opendiff)
+ if merge_three; then
+ "$merge_tool_path" "$LOCAL" "$REMOTE" \
+ -ancestor "$BASE" \
+ -merge "$MERGED" | cat
+ else
+ "$merge_tool_path" "$LOCAL" "$REMOTE" \
+ -merge "$MERGED" | cat
+ fi
+ check_unchanged
+ ;;
+
+ ecmerge)
+ if merge_three; then
+ "$merge_tool_path" "$BASE" "$LOCAL" "$REMOTE" \
+ --default --mode=merge3 --to="$MERGED"
+ else
+ "$merge_tool_path" "$LOCAL" "$REMOTE" \
+ --default --mode=merge2 --to="$MERGED"
+ fi
+ check_unchanged
+ ;;
+
+ emerge)
+ if merge_three; then
+ "$merge_tool_path" \
+ -f emerge-files-with-ancestor-command \
+ "$LOCAL" "$REMOTE" "$BASE" \
+ "$(basename "$MERGED")"
+ else
+ "$merge_tool_path" -f emerge-files-command \
+ "$LOCAL" "$REMOTE" "$(basename "$MERGED")"
+ fi
+ status=$?
+ ;;
+ *)
+ if test -n "$merge_tool_cmd"; then
+ if test "$merge_tool_trust_exit_code" = "false"; then
+ ( eval $merge_tool_cmd )
+ check_unchanged
+ else
+ ( eval $merge_tool_cmd )
+ status=$?
+ fi
+ fi
+ ;;
+ esac
+
+ if ! use_rev_range; then
+ if test "$status" -ne 0; then
+ if should_prompt; then
+ echo "merge of $MERGED failed" 1>&2
+ fi
+ cleanup_temp_files
+ exit 1
+ fi
+ git add -- "$MERGED"
+ fi
+ cleanup_temp_files
+}
+
+while test $# != 0
+do
+ case "$1" in
+ -t|--tool*)
+ case "$#,$1" in
+ *,*=*)
+ merge_tool=$(parse_arg "$1")
+ shift
+ ;;
+ 1,*)
+ usage
+ ;;
+ *)
+ shift
+ merge_tool="$1"
+ shift
+ ;;
+ esac
+ ;;
+ -c|--commit*)
+ case "$#,$1" in
+ *,*=*)
+ commitish=$(parse_arg "$1")
+ shift
+ ;;
+ 1,*)
+ usage
+ ;;
+ *)
+ shift
+ commitish="$1"
+ shift
+ ;;
+ esac
+ ;;
+ -s|--start*)
+ case "$#,$1" in
+ *,*=*)
+ start=$(parse_arg "$1")
+ shift
+ ;;
+ 1,*)
+ usage
+ ;;
+ *)
+ shift
+ start="$1"
+ shift
+ ;;
+ esac
+ ;;
+ -e|--end*)
+ case "$#,$1" in
+ *,*=*)
+ end=$(parse_arg "$1")
+ shift
+ ;;
+ 1,*)
+ usage
+ ;;
+ *)
+ shift
+ end="$1"
+ shift
+ ;;
+ esac
+ ;;
+ --no-prompt)
+ no_prompt=true
+ shift
+ ;;
+ --)
+ shift
+ break
+ ;;
+ -*)
+ usage
+ ;;
+ *)
+ break
+ ;;
+ esac
+done
+
+valid_custom_tool()
+{
+ merge_tool_cmd="$(git config mergetool.$1.cmd)"
+ test -n "$merge_tool_cmd"
+}
+
+valid_tool()
+{
+ case "$1" in
+ kdiff3 | tkdiff | xxdiff | meld | opendiff | emerge | vimdiff | gvimdiff | ecmerge)
+ ;; # happy
+ *)
+ if ! valid_custom_tool "$1"
+ then
+ return 1
+ fi
+ ;;
+ esac
+}
+
+init_merge_tool_path()
+{
+ merge_tool_path=$(git config mergetool."$1".path)
+ if test -z "$merge_tool_path"; then
+ case "$1" in
+ emerge)
+ merge_tool_path=emacs
+ ;;
+ *)
+ merge_tool_path="$1"
+ ;;
+ esac
+ fi
+}
+
+
+if test -z "$merge_tool"; then
+ merge_tool=$(git config merge.tool)
+ if test -n "$merge_tool" && ! valid_tool "$merge_tool"; then
+ echo >&2 "git config option merge.tool set to unknown tool: $merge_tool"
+ echo >&2 "Resetting to default..."
+ unset merge_tool
+ fi
+fi
+
+if test -z "$merge_tool"; then
+ if test -n "$DISPLAY"; then
+ merge_tool_candidates="kdiff3 tkdiff xxdiff meld gvimdiff"
+ if test -n "$GNOME_DESKTOP_SESSION_ID"; then
+ merge_tool_candidates="meld $merge_tool_candidates"
+ fi
+ if test "$KDE_FULL_SESSION" = "true"; then
+ merge_tool_candidates="kdiff3 $merge_tool_candidates"
+ fi
+ fi
+
+ if echo "${VISUAL:-$EDITOR}" | grep 'emacs' > /dev/null 2>&1; then
+ merge_tool_candidates="$merge_tool_candidates emerge"
+ fi
+
+ if echo "${VISUAL:-$EDITOR}" | grep 'vim' > /dev/null 2>&1; then
+ merge_tool_candidates="$merge_tool_candidates vimdiff"
+ fi
+
+ merge_tool_candidates="$merge_tool_candidates opendiff emerge vimdiff"
+ echo "merge tool candidates: $merge_tool_candidates"
+
+ for i in $merge_tool_candidates
+ do
+ init_merge_tool_path $i
+ if type "$merge_tool_path" > /dev/null 2>&1; then
+ merge_tool=$i
+ break
+ fi
+ done
+
+ if test -z "$merge_tool" ; then
+ echo "No known merge resolution program available."
+ exit 1
+ fi
+
+else
+ if ! valid_tool "$merge_tool"; then
+ echo >&2 "Unknown merge tool $merge_tool"
+ exit 1
+ fi
+
+ init_merge_tool_path "$merge_tool"
+
+ if test -z "$merge_tool_cmd" && ! type "$merge_tool_path" > /dev/null 2>&1; then
+ echo "The merge tool $merge_tool is not available as '$merge_tool_path'"
+ exit 1
+ fi
+
+ if ! test -z "$merge_tool_cmd"; then
+ merge_tool_trust_exit_code="$(git config --bool mergetool.$merge_tool.trustExitCode || echo false)"
+ fi
+fi
+
+
+if test $# -eq 0; then
+ use_index=0
+ files=$(modified_files)
+
+ if test -z "$files"; then
+ use_index=1
+ files=$(staged_files)
+ fi
+
+ if test -z "$files"; then
+ echo "No modified files exist."
+ exit 0
+ fi
+
+ if test $use_index -eq 0; then
+ modified_files |
+ while IFS= read i
+ do
+ merge_file "$i" < /dev/tty > /dev/tty
+ done
+ elif ! use_rev_range; then
+ staged_files |
+ while IFS= read i
+ do
+ merge_file "$i" < /dev/tty > /dev/tty
+ done
+ else
+ echo "Nothing to compare."
+ exit 0
+ fi
+else
+ while test $# -gt 0
+ do
+ merge_file "$1"
+ shift
+ done
+fi
+exit $status
diff --git a/contrib/difftool/git-difftool.txt b/contrib/difftool/git-difftool.txt
new file mode 100644
index 0000000..ddc090d
--- /dev/null
+++ b/contrib/difftool/git-difftool.txt
@@ -0,0 +1,130 @@
+git-difftool(1)
+===============
+
+NAME
+----
+git-difftool - stage and compare changes using git merge tools
+
+SYNOPSIS
+--------
+'git difftool' [--tool=<tool>]
+ [--commit=<ref> | --start=<ref> --end=<ref>]
+ [--no-prompt]
+ [--] [<file>]...
+
+DESCRIPTION
+-----------
+'git-difftool' is a git command that allows you to compare and edit files
+between revisions using standard git merge tools. At its most basic level,
+'git-difftool' does what 'git-mergetool' does but its use is for non-merge
+situations, such as when preparing commits or comparing changes against
+the index.
+
+'git-difftool' shows differences between the work tree and the index by
+default but can also show differences between arbitrary commits by using
+the --start and --end options. When operating on the index, saving the
+merged file from within the merge tool (and a successful exit code) will
+instruct 'git-difftool' to stage the new content for commit.
+
+OPTIONS
+-------
+
+-t or --tool=<tool>::
+ Use the merge resolution program specified by <tool>.
+ Valid merge tools are:
+ kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge, and opendiff
++
+If a merge resolution program is not specified, 'git-difftool'
+will use the configuration variable `merge.tool`. If the
+configuration variable `merge.tool` is not set, 'git-difftool'
+will pick a suitable default.
++
+You can explicitly provide a full path to the tool by setting the
+configuration variable `mergetool.<tool>.path`. For example, you
+can configure the absolute path to kdiff3 by setting
+`mergetool.kdiff3.path`. Otherwise, 'git-difftool' assumes the
+tool is available in PATH.
++
+Instead of running one of the known merge tool programs,
+'git-difftool' can be customized to run an alternative program
+by specifying the command line to invoke in a configuration
+variable `mergetool.<tool>.cmd`.
++
+When 'git-difftool' is invoked with this tool (either through the
+`-t` or `--tool` option or the `merge.tool` configuration variable)
+the configured command line will be invoked with the following
+variables available: `$BASE` is set to the name of a temporary file
+containing the contents of the index; `$LOCAL` set to the name of a
+temporary file containing the contents of the file as it appears in
+the work tree; `$REMOTE` set to the name of a temporary file
+containing the contents of the file to be merged, and `$MERGED` set
+to the name of the file to which the merge tool should write the
+result of the merge resolution.
++
+When `--start=<ref>` and `--end=<ref>` are specified
+`$LOCAL` contains the contents of the file from the
+starting revision and `$REMOTE` contains the contents
+of the file in the ending revision. `$BASE` contains
+the contents of the file in the work tree if it exists,
+and the starting revision otherwise.
++
+If the custom merge tool correctly indicates the success of a
+merge resolution with its exit code then the configuration
+variable `mergetool.<tool>.trustExitCode` can be set to `true`.
+Otherwise, 'git-difftool' will prompt the user to indicate the
+success of the resolution after the custom tool has exited.
+
+-c or --commit=<ref>::
+ Specifies a commit reference for comparing against.
+ 'git-difftool' compares against the index by default.
+
+--no-prompt::
+ Do not prompt before and after launching a merge tool.
+
+-s or --start=<ref> and -e or --end=<ref>::
+ See changes between commits start and end.
+ This example shows the latest commit: `--start=HEAD^ --end=HEAD`.
+
+CONFIG VARIABLES
+----------------
+
+merge.tool::
+ The default merge tool to use.
++
+See the `--tool=<tool>` option above for more details.
+
+mergetool.<tool>.path::
+ Override the path for the given tool. This is useful in case
+ your tool is not in the PATH.
+
+mergetool.<tool>.cmd::
+ Specify the command to invoke the specified merge tool.
++
+See the `--tool=<tool>` option above for more details.
+
+mergetool.<tool>.trustExitCode::
+ For a custom merge command, specify whether the exit code of
+ the merge command can be used to determine whether the merge was
+ successful. If this is not set to true then the merge target file
+ timestamp is checked and the merge assumed to have been successful
+ if the file has been updated, otherwise the user is prompted to
+ indicate the success of the merge.
+
+mergetool.keepBackup::
+ The original, unedit file content can be saved to a file with
+ a `.orig` extension. Defaults to `true` (i.e. keep the backup files).
+
+
+SEE ALSO
+--------
+linkgit:git-mergetool[1]::
+ 'git-difftool' uses many of the same concepts as the core
+ 'git-mergetool' command.
+
+linkgit:git-config[7]::
+ Get and set repository or global options.
+
+AUTHOR
+------
+Written by David Aguilar <davvid@gmail.com>.
+
--
1.6.0.2.229.g1293c
^ permalink raw reply related
* Re: Management of opendocument (openoffice.org) files in git
From: Johannes Sixt @ 2008-09-16 7:52 UTC (permalink / raw)
To: Sergio Callegari; +Cc: git
In-Reply-To: <48CF630F.4090808@gmail.com>
Sergio Callegari schrieb:
> Johannes Sixt wrote:
>>
>> You don't need a temporay zip filename in filter mode:
>>
>> unzip $UNZIP_OPTS /dev/stdin # works for me, but not 100% portable
>> zip $ZIP_OPTS - . # writes to stdout
>>
>>
> The unzip documentation says "Archives read from standard input are not
> yet supported", so I was a bit worried about using the /dev/stdin
> thing. Might it be that there are subtle cases where unzip needs to
> seek or rewind?
I didn't test thoroughly nor did I read the documentation. So if the
documentation says stdin is a no-go, you better do what it says. ;)
> In any case - but this is just my feeling - it is much more disturbing
> the delay that the clean filter introduces in operations like add or
> status or commit, than the one introduced by the (slower) smudge filter
> in checkout.
My feeling is that the temporary tree that is written slows it down. If
rezip were a true filter it could be faster.
-- Hannes
^ permalink raw reply
* Re: Management of opendocument (openoffice.org) files in git
From: Sergio Callegari @ 2008-09-16 7:41 UTC (permalink / raw)
Cc: git
In-Reply-To: <vpqwshctwr7.fsf@bauges.imag.fr>
Matthieu Moy wrote:
> Sergio Callegari <sergio.callegari@gmail.com> writes:
>
>
>> Hi,
>>
>> Management of opendocument files in git has been discussed a short time ago.
>> Here is an helper script that may help achieving better density in git packs
>> containg blobs from openoffice files.
>>
>
> If you don't get "oh, sh*t, I lost data with it"-kind of feedback, can
> you add it to the wiki:
>
> http://git.or.cz/gitwiki/GitTips#head-1cdd4ab777e74f12d1ffa7f0a793e46dd06e5945
>
> Thanks,
>
>
Sure. I'll wait a few days for feedback (also from myself), then I'll
add it there.
I've already got a couple of corrections and suggestions from Paolo.
Would it be useful also to add a note about how to filter-branches with
a plain "--tree-filter true" to convert archives so that they take
advantage of storing ODF stuff uncompressed?
If proper, I can add that too.
Sergio
^ permalink raw reply
* Re: Management of opendocument (openoffice.org) files in git
From: Sergio Callegari @ 2008-09-16 7:41 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <48CF5B90.5050800@viscovery.net>
Johannes Sixt wrote:
>
> You don't need a temporay zip filename in filter mode:
>
> unzip $UNZIP_OPTS /dev/stdin # works for me, but not 100% portable
> zip $ZIP_OPTS - . # writes to stdout
>
>
The unzip documentation says "Archives read from standard input are not
yet supported", so I was a bit worried about using the /dev/stdin
thing. Might it be that there are subtle cases where unzip needs to
seek or rewind?
>> then put in your .git/config something like
>>
>> [filter "opendocument"]
>> clean = "rezip -p ODF_UNCOMPRESS"
>> smudge = "rezip -p ODF_COMPRESS"
>>
>
> Is the smudge filter really necessary? Can't OOo work with files at
> compression level 0?
>
Yes, you can live perfectly without smudge. But at times it is not that
nice. Just think of finding a directory with say 15 lectures as impress
slides taking 10 times the space it needs, particularly if you need to
pass those files to someone else. As a matter of fact, ODF xml is very
verbose and compresses particularly well having long tags.
But you might want to compress -1 rather than the default in smudge to
speed it up a little. Can be done either adding a new profile to the
script (say ODF_COMPRESS_FAST) or by adding --zip_opts -1 to the smudge
command line.
Also, we might want to add some -n suffixes to zip, to prevent it from
trying to compress a few things like .png or .jpeg images and that have
their own compression. That should gain us some speed in smudging.
In any case - but this is just my feeling - it is much more disturbing
the delay that the clean filter introduces in operations like add or
status or commit, than the one introduced by the (slower) smudge filter
in checkout. There must be some psychological reason for that.
Possibly we are "programmed" to accept waiting when we need to get
something and conversely we are impatient when someone should accept
something from us.
Sergio
^ permalink raw reply
* Re: You don't exist, Go away! although user.name has been set
From: Andreas Ericsson @ 2008-09-16 7:38 UTC (permalink / raw)
To: Marc Weber; +Cc: git
In-Reply-To: <20080916010529.GB22597@gmx.de>
Marc Weber wrote:
> Today I was glad. I 've been able to compile git on a maanged server.
> git clone did work as well however running
> git fetch <remote location> caused the line
> die("You don't exist. Go away!");
>
> to be executed. (the first one)
>
> Before examining that I asked at #git and got the tip to set
> user.name and user.email which I did. Then I verified that git
> git var GIT_AUTHOR_IDENT and
> git var GIT_COMMITTER_IDENT
> both printed some values.
>
> I still got the failure above.
> I've fixed it for my case by setting
> git_default_name and git_default_email just before the check within the
> ident.c file (line 76)..
>
> However I want to ask wether I've hit a known problem and wether you
> would appreciate me debggung this issue any further?
>
I can assure you that people are capable of fetching, pulling and
committing with git. I do it all day long at least.
Can you post your ~/.gitconfig (and/or .git/config) file, please?
In conjunction, I also need to know the exact username you're using
on your system.
> Maybe I should add that I've been running that git from the build
> directory if that matters. The version is 1.6.0 from the official
> mirror site.
>
If you'd been running 0.99 I'd have been worried. 1.6.0 is pretty
solid.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [StGit PATCH] Convert "sink" to the new infrastructure
From: Karl Hasselström @ 2008-09-16 7:40 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0809150944o71acafe7ndeda500b1fba97df@mail.gmail.com>
On 2008-09-15 17:44:38 +0100, Catalin Marinas wrote:
> Since we are talking about this, the transactions documentation
> doesn't explain when to use a iw and when to pass allow_conflicts. I
> kind of figured out but I'm not convinced. At a first look, passing
> allow_conflicts = True would seem that it may allow conflicts and not
> revert the changes, however, this only works if I pass an "iw". But
> passing it doesn't allow the default case where I want the changes
> reverted.
In my experimental branch, one of the patches adds the following piece
of documentation:
+ @param allow_conflicts: Whether to allow pre-existing conflicts
+ @type allow_conflicts: bool or function of L{StackTransaction}"""
That is, allow_conflicts decides whether to abort the transaction in
case there already were conflicts -- undo and friends need to allow
existing conflicts, but most other commands just want to abort in that
case.
This should of course have been a separate patch (in kha/safe), but it
seems I was lazy ...
iw is the index+worktree object. The idea is that you provide one if
your branch is checked out, and not if not. Operations that have no
need of index+worktree, like pop, and push in case automatic merging
succeeds, will just work anyway, while operations that need
index+worktree, such as a conflicting push, will cause the whole
transaction to abort.
> Please have a look at the attached patch which is my last version of
> the sink command rewriting. I'm not that happy (or maybe I don't
> understand the reasons) with setting iw = None if not
> options.conflict but that's the way I could get it to work.
That's not the right way to do it. iw = None will tell the transaction
that you have no index+worktree, so the resulting tree will not be
checked out in the end. Since you don't change the set of applied
patches, and since all the automatic merges succeeded, you'll probably
get the exact same tree 99% of the time and not notice, but I wouldn't
recommend it.
The right way to do it, I guess, would be to add a
stop_before_conflicts flag to run(). As for implementing it, note how
the "if merge_conflict:" conditional in push_patch() delays the
recording of the final conflicting push so that the patch log can get
two entries for this transaction, one that undoes just the conflicting
push and one that undoes it all. It would probably not be hard to
teach that code to skip the conflicting push altogether.
( Oh, and note that what I just said talks about the "patch stack
log", meaning that I'm talking about the code in kha/experimental.
The code in kha/safe doesn't look quite the same -- in particular,
there's no obvious place to place code that ignores the conflicting
push. Unless you really don't want your sink changes to depend on
the stack log stuff (e.g. because you doubt you'll be merging it
anytime soon), I suggest we do this: I'll prepare, and ask you to
pull, a "stacklog" branch, and once you've pulled it we won't rebase
it anymore. You can merge it directly to your master or publish it
as a separate development branch, whichever you feel is best. )
> 2008/9/15 Karl Hasselström <kha@treskal.com>:
>
> > What I've always wanted is "sink this patch as far as it will go
> > without conflicting". This comes awfully close.
>
> But this means that sink would try several consecutive sinks until
> it can't find one. Not that it is try to implement but I wouldn't
> complicate "sink" for this.
OK.
> I would rather add support for patch dependency tracking (which used
> to be on the long term wish list). It might be useful for other
> things as well like mailing a patch together with those on which it
> depends (like darcs).
Do you mean automatically detected dependencies, or dependencies that
the user has told us about?
> > BTW, this kind of flag might potentially be useful in many
> > commands (with default value on or off depending on the command).
> > Maybe
> >
> > --conflicts=roll-back|stop-before|allow
>
> ATM, I only added a --conflict option which has the "allow" meaning.
OK.
> + if options.conflict:
> + iw = stack.repository.default_iw
> + else:
> + iw = None
As I said above, this doesn't (or at least isn't supposed to) work.
> + # pop any patches to be sinked in case they are applied
> + to_push = trans.pop_patches(lambda pn: pn in patches)
I see what made you want those utility functions ...
> + if options.to:
> + if options.to in to_push:
> + # this is the case where sinking actually brings some
> + # patches forward
> + for p in to_push:
> + if p == options.to:
> + del to_push[:to_push.index(p)]
> + break
> + trans.push_patch(p, iw)
> + else:
> + # target patch below patches to be sinked
> + to_pop = trans.applied[trans.applied.index(options.to):]
> + to_push = to_pop + to_push
> + trans.pop_patches(lambda pn: pn in to_pop)
> + else:
> + # pop all the remaining patches
> + to_push = trans.applied + to_push
> + trans.pop_patches(lambda pn: True)
>
> + # push the sinked and other popped patches
> if not options.nopush:
> - newapplied = crt_series.get_applied()
> - def not_reapplied_yet(p):
> - return not p in newapplied
> - push_patches(crt_series, filter(not_reapplied_yet, oldapplied))
> + patches.extend(to_push)
> + try:
> + for p in patches:
> + trans.push_patch(p, iw)
Have you seen the reorder_patches() function last in transaction.py?
It seems you could save a lot of work here by using it.
> + except transaction.TransactionHalted:
> + if not options.conflict:
> + raise
Not catching TransactionHalted will have the effect of rolling back
the whole transaction if it stops half-way through. But what you
really wanted was the new flag I described above, I think.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: Management of opendocument (openoffice.org) files in git
From: Johannes Sixt @ 2008-09-16 7:09 UTC (permalink / raw)
To: Sergio Callegari; +Cc: git
In-Reply-To: <loom.20080915T222909-709@post.gmane.org>
Sergio Callegari schrieb:
> if [ $# = 0 ] ; then
> tmpcopy=$(mktemp rezip.zip.XXXXXX)
> cat > $tmpcopy
> filename="$tmpcopy"
> else
> tmpcopy=""
> filename="$1"
> fi
>
> workdir=$(mktemp -d -t rezip.workdir.XXXXXX)
> curdir=$(pwd)
>
> cd $workdir
> unzip $UNZIP_OPTS "$curdir/$filename"
> zip $ZIP_OPTS "$curdir/$filename" .
> cd $curdir
> rm -fr $workdir
> if [ ! -z "$tmpcopy" ] ; then
> cat $filename
> rm $tmpcopy
> fi
You don't need a temporay zip filename in filter mode:
unzip $UNZIP_OPTS /dev/stdin # works for me, but not 100% portable
zip $ZIP_OPTS - . # writes to stdout
> then put in your .git/config something like
>
> [filter "opendocument"]
> clean = "rezip -p ODF_UNCOMPRESS"
> smudge = "rezip -p ODF_COMPRESS"
Is the smudge filter really necessary? Can't OOo work with files at
compression level 0?
-- Hannes
^ permalink raw reply
* Re: Management of opendocument (openoffice.org) files in git
From: Sergio Callegari @ 2008-09-16 7:05 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: Git Mailing List
In-Reply-To: <48CF5127.5040507@gnu.org>
Thanks for the fixes (particularly the missing quotation!) and the
suggestions.
With regards to
> And maybe -b,-qq,-X and -q,-r respectively could be added by default?
>
>
I would prefer not to do so: if you do you get something that is
somehow "specialised", otherwise you have a totally generic "rezipper"
that might also find other applications (who knows).
BTW, that is why I added the profiles, so that there was no need to type
repetitive stuff.
Sergio
^ permalink raw reply
* Re: Management of opendocument (openoffice.org) files in git
From: Matthieu Moy @ 2008-09-16 6:45 UTC (permalink / raw)
To: Sergio Callegari; +Cc: git
In-Reply-To: <loom.20080915T222909-709@post.gmane.org>
Sergio Callegari <sergio.callegari@gmail.com> writes:
> Hi,
>
> Management of opendocument files in git has been discussed a short time ago.
> Here is an helper script that may help achieving better density in git packs
> containg blobs from openoffice files.
If you don't get "oh, sh*t, I lost data with it"-kind of feedback, can
you add it to the wiki:
http://git.or.cz/gitwiki/GitTips#head-1cdd4ab777e74f12d1ffa7f0a793e46dd06e5945
Thanks,
--
Matthieu
^ permalink raw reply
* Re: Management of opendocument (openoffice.org) files in git
From: Paolo Bonzini @ 2008-09-16 6:24 UTC (permalink / raw)
To: Sergio Callegari, Git Mailing List
> profile_unzip=PROFILE_UNZIP_${profile}
> profile_zip=PROFILE_ZIP_${profile}
> UNZIP_OPTS=${!profile_unzip}
> ZIP_OPTS=${!profile_zip}
Can be written (in pure bourne shell) as
eval UNZIP_OPTS=\$PROFILE_UNZIP_${profile}
eval ZIP_OPTS=\$PROFILE_ZIP_${profile}
> --unzip_opts)
> UNZIP_OPTS=${UNZIP_OPTS} $2
Missing quotes:
UNZIP_OPTS="${UNZIP_OPTS} $2"
It could also be a good idea to do
UNZIP_OPTS="${UNZIP_OPTS} `echo $2 | sed 'y/,/ /' `"
(compare with the -Wa/-Wl/-Wp options of gcc) so you can do
[filter "opendocument"]
clean = "rezip --unzip-opts -b,-qq,-X --zip-opts -q,-r,-D,-0"
smudge = "rezip --unzip-opts -b,-qq,-X --zip-opts -q,-r,-D,-6"
And maybe -b,-qq,-X and -q,-r respectively could be added by default?
Anyway, nice script, thanks!
Paolo
^ permalink raw reply
* Re: Grafts workflow for a "shallow" repository...?
From: Junio C Hamano @ 2008-09-16 6:25 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Martin Langhoff, Git Mailing List
In-Reply-To: <20080916052425.GA14644@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Martin Langhoff <martin.langhoff@gmail.com> wrote:
>> Here is my attempt at a "let's publish a shallow repository for branch
>> of moodle". Let me show you what I did...
> ...
>> # 1.7 was a significant release, anything earlier than that
>> # is just not interesting -- even for pickaxe/annotate purposes
>> # so add a graft point right at the branching point.
> ...
>> Is this kind of workflow (or a variation of it) supported? For this to
>> work, we should communicate the grafts in some push operations and
>> read them in clone ops - and perhaps in fetch too.
> ...
> I think that in this case the best thing to do is give users
> a shell script that does roughly:
>
> git init
> echo $BASE >.git/info/grafts
> git remote add -f origin $url
> git checkout -b master origin/master
>
> Sign the script, and let users verify it before executing. You may
> also want a script to drag in the history behind by removing the
> graft and fetching $BASE^, but that is hard because your repository
> already "has" that.
Why not just filter-branch _once at the origin_ and publish the result?
^ permalink raw reply
* Re: Diff-tree does not work for initial commit
From: Jeff King @ 2008-09-16 6:21 UTC (permalink / raw)
To: sverre; +Cc: Michael J Gruber, Anatol Pomozov, Git Mailing List
In-Reply-To: <bd6139dc0809152319m31a79877h5dc1b701a8210802@mail.gmail.com>
On Tue, Sep 16, 2008 at 08:19:37AM +0200, Sverre Rabbelier wrote:
> I like it, although I think that if we add broader support for it, we
> should probably be consequent and add it everywhere where appropriate?
> (That is ofcourse, assuming that does not take too long to implement
> etc.)
Right, that was what I meant by "incomplete". I think there are several
other cases where giving "--root" would have expected behavior but is
currently ignored. I'll take a closer look, but I probably won't have
time for a few days.
-Peff
^ permalink raw reply
* Re: Diff-tree does not work for initial commit
From: Sverre Rabbelier @ 2008-09-16 6:19 UTC (permalink / raw)
To: Jeff King; +Cc: Michael J Gruber, Anatol Pomozov, Git Mailing List
In-Reply-To: <20080915223442.GD20677@sigill.intra.peff.net>
On Tue, Sep 16, 2008 at 00:34, Jeff King <peff@peff.net> wrote:
> I posted this a week or so ago, but I am sure it is incomplete. If there
> is interest I can clean it up and do a proper submission.
<patch snipped>
I like it, although I think that if we add broader support for it, we
should probably be consequent and add it everywhere where appropriate?
(That is ofcourse, assuming that does not take too long to implement
etc.)
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] help git-upload-pack find git
From: Johannes Sixt @ 2008-09-16 6:17 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Junio C Hamano, git
In-Reply-To: <48CEC3FB.5070101@drmicha.warpmail.net>
Michael J Gruber schrieb:
> I was actually surprised that setup_path() uses argv0_path without
> setting it, same as with argv_exec_path. I assumed this is for a good
> reason, I'm lacking the code base overview to judge this myself.
It argv_exec_path comes from git --exec-path=..., hence, git (via git.c)
is the only caller of setup_path() that is able to set it. We can leave
that one out of the equation.
> In any case, git.c sets argv0_path early, messes a bit with argv[0] and
> calls setup_path afterwards anyways. So adding the path in setup_path()
> should not hurt any "git foo" command.
>
> One could construe situations where even that wouldn't help, because
> git-upload-pack can't pass --exec-dir to git and they can be in
> different locations - but I think that's crazy.
>
> git.c, upload-pack.c, receive.pack.c and shell.c are the only callers.
> setup_path() needs to get a parameter. If shell.c should profit from the
> change then it needs to be taught how to pass an absolute path to
> do_{generic,cvs}_cmd().
>
> So, I guess the general approach (change setup() path and have every
> caller profit) is OK. OK with you?
Have you studied the commit message of e1464ca7bb0d (Record the command
invocation path early) and the context in which this commit occurs? It's
about relocatable git installations and how system_path() derives various
other paths from argv[0].
Please show how you think you could change setup_path(), but keep in mind
that in git.c you neither can do the equivalent of git_set_argv0_path()
later nor setup_path() earlier.
-- Hannes
^ permalink raw reply
* [JGIT PATCH] Add support for ~/.ssh/config PreferredAuthentications
From: Shawn O. Pearce @ 2008-09-16 5:48 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
Some configurations may wish to disable interactive methods of
authentication, such as when running from automated cron or batch
style jobs that have no user available.
Typically in an OpenSSH based system this would be configured on a
per-host basis in the current user's ~/.ssh/config file, by setting
PreferredAuthentications to the list of authentication methods
(e.g. just "publickey") that are reasonable.
JSch honors this configuration setting, but we need to transfer it
from our own OpenSshConfig class, otherwise it has no knowledge of
the setting.
http://code.google.com/p/egit/issues/detail?id=33
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
.../spearce/egit/ui/EclipseSshSessionFactory.java | 4 ++++
.../jgit/transport/DefaultSshSessionFactory.java | 4 ++++
.../org/spearce/jgit/transport/OpenSshConfig.java | 12 ++++++++++++
3 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/org.spearce.egit.ui/src/org/spearce/egit/ui/EclipseSshSessionFactory.java b/org.spearce.egit.ui/src/org/spearce/egit/ui/EclipseSshSessionFactory.java
index 640a165..67c5f16 100644
--- a/org.spearce.egit.ui/src/org/spearce/egit/ui/EclipseSshSessionFactory.java
+++ b/org.spearce.egit.ui/src/org/spearce/egit/ui/EclipseSshSessionFactory.java
@@ -50,6 +50,10 @@ if (pass != null)
session.setPassword(pass);
else
new UserInfoPrompter(session);
+
+ final String pauth = hc.getPreferredAuthentications();
+ if (pauth != null)
+ session.setConfig("PreferredAuthentications", pauth);
return session;
}
diff --git a/org.spearce.jgit/src/org/spearce/jgit/transport/DefaultSshSessionFactory.java b/org.spearce.jgit/src/org/spearce/jgit/transport/DefaultSshSessionFactory.java
index 74fca66..b6f58f0 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/transport/DefaultSshSessionFactory.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/transport/DefaultSshSessionFactory.java
@@ -103,6 +103,10 @@ if (pass != null)
session.setPassword(pass);
else
session.setUserInfo(new AWT_UserInfo());
+
+ final String pauth = hc.getPreferredAuthentications();
+ if (pauth != null)
+ session.setConfig("PreferredAuthentications", pauth);
return session;
}
diff --git a/org.spearce.jgit/src/org/spearce/jgit/transport/OpenSshConfig.java b/org.spearce.jgit/src/org/spearce/jgit/transport/OpenSshConfig.java
index cf7c388..748199c 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/transport/OpenSshConfig.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/transport/OpenSshConfig.java
@@ -278,6 +278,8 @@ if (ret.isAbsolute())
String user;
+ String preferredAuthentications;
+
void copyFrom(final Host src) {
if (hostName == null)
hostName = src.hostName;
@@ -287,6 +289,8 @@ if (identityFile == null)
identityFile = src.identityFile;
if (user == null)
user = src.user;
+ if (preferredAuthentications == null)
+ preferredAuthentications = src.preferredAuthentications;
}
/**
@@ -317,5 +321,13 @@ public File getIdentityFile() {
public String getUser() {
return user;
}
+
+ /**
+ * @return return the preferred authentication methods, separated by
+ * commas if more than one authentication method is preferred.
+ */
+ public String getPreferredAuthentications() {
+ return preferredAuthentications;
+ }
}
}
--
1.6.0.1.337.g5c7d67
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox