What's cooking in git.git (Jul 2012, #07; Mon, 23)
Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. The tip of 'master' has been tagged as 1.7.12-rc0; this deliberately contains a few topics that have been in 'next' only for a few days, so please make sure to spot any possible issues and report soonish to avoid regressions in the upcoming release. You can find the changes described here in the integration branches of the repositories listed at http://git-blame.blogspot.com/p/git-public-repositories.html -- [Graduated to "master"] * jk/mediawiki-credential (2012-07-18) 4 commits (merged to 'next' on 2012-07-22 at 2cb99b2) + mw-to-git: use git-credential's URL parser + credential: convert "url" attribute into its parsed subparts + mw-to-git: check blank credential attributes via length + docs/credential: minor clarity fixups Mediawiki importer updates. * jn/block-sha1 (2012-07-23) 3 commits (merged to 'next' on 2012-07-23 at a11a08b) + Makefile: BLK_SHA1 does not require fast htonl() and unaligned loads + block-sha1: put expanded macro parameters in parentheses + block-sha1: avoid pointer conversion that violates alignment constraints The code to load a word one-byte-at-a-time was optimized into a word-wide load instruction even when the pointer was not aligned, which caused issues on architectures that do not like unaligned access. * jn/make-assembly-in-right-directory (2012-07-22) 1 commit (merged to 'next' on 2012-07-23 at 3c155cc) + Makefile: fix location of listing produced by "make subdir/foo.s" * jv/maint-no-ext-diff (2012-07-19) 2 commits (merged to 'next' on 2012-07-22 at eefcf45) + diff: test precedence of external diff drivers + diff: correctly disable external_diff with --no-ext-diff "git diff --no-ext-diff" did not output anything for a typechange filepair when GIT_EXTERNAL_DIFF is in effect. * kk/maint-1.7.9-commit-tree (2012-07-17) 1 commit + commit-tree: resurrect command line parsing updates (this branch is used by kk/maint-commit-tree.) A more natural-looking "git commit-tree -p " syntax was introduced long time ago, but we accidentally broke it in the 1.7.9 era. * kk/maint-commit-tree (2012-07-17) 2 commits (merged to 'next' on 2012-07-22 at ab15d56) + Revert "git-commit-tree(1): update synopsis" + Merge branch 'kk/maint-1.7.9-commit-tree' into kk/maint-commit-tree (this branch uses kk/maint-1.7.9-commit-tree.) The same as above, for merging to the upcoming release. * mm/mediawiki-usability (2012-07-17) 10 commits (merged to 'next' on 2012-07-22 at fe66a95) + git-remote-mediawiki: allow page names with a ':' + git-remote-mediawiki: fix incorrect test usage in test + git-remote-mediawiki: properly deal with invalid remote revisions + git-remote-mediawiki: show progress information when getting last remote revision + git-remote-mediawiki: show progress information when listing pages + git-remote-mediawiki: use --force when adding notes + git-remote-mediawiki: get rid of O(N^2) loop + git-remote-mediawiki: make mediafiles export optional + git-remote-mediawiki: actually send empty comment when they're empty + git-remote-mediawiki: don't split namespaces with spaces Mediawiki importer updates. * nk/maint-gitweb-log-by-lines (2012-07-05) 3 commits (merged to 'next' on 2012-07-13 at 780e16a) + gitweb: Add support to Link: tag + gitweb: Handle other types of tag in git_print_log + gitweb: Cleanup git_print_log() Teach gitweb to pay attention to various forms of credits that are similar to "Signed-off-by:" lines. Needs to be eyeballed for the correctness of the esc_html() in the tip one. * sl/autoconf (2012-07-19) 7 commits (merged to 'next' on 2012-07-23 at dc94990) + build: reconfigure automatically if configure.ac changes + build: "make clean" should not remove configure-generated files + autoconf: use AC_CONFIG_COMMANDS instead of ad-hoc 'config.mak.append' + autoconf: remove few redundant semicolons + autoconf: remove some redundant shell indirections + autoconf: GIT_CONF_APPEND_LINE -> GIT_CONF_SUBST + autoconf: GIT_CONF_APPEND_LINE: change signature * sn/doc-typofix (2012-07-14) 1 commit (merged to 'next' on 2012-07-22 at 168bba9) + doc: A few minor copy edits. * tg/ce-namelen-field (2012-07-11) 2 commits (merged to 'next' on 2012-07-22 at 2d85b05) + Strip namelen out of ce_flags into a ce_namelen field + Merge branch 'tg/maint-cache-name-compare' into tg/ce-namelen-field Split lower bits of ce_flags field and creates a new ce_namelen field in the in-core index structure. * th/difftool-diffall (2012-07-19) 1 commit (merged to 'next' on 2012-07-23 at db62371) + difftool: only copy back files modified during directory diff (this branch is used by da/difftool-updates.) Finishing touches to "difftool --dir-diff". -- [New Topics] * da/difftool-updates (2
[ANNOUNCE] Git v1.7.12-rc0
A release candidate Git v1.7.12-rc0 is now available for testing at the usual places. The release tarballs are found at: http://code.google.com/p/git-core/downloads/list and their SHA-1 checksums are: 09016e819a69b49090756e9bc5c97a4df25c2f78 git-1.7.12.rc0.tar.gz e85ad0780ff81eacdb05a10762060812bc9367dd git-htmldocs-1.7.12.rc0.tar.gz b641a9664c333518ede3b1d8b67d84d18f5b0e14 git-manpages-1.7.12.rc0.tar.gz Also the following public repositories all have a copy of the v1.7.12-rc0 tag and the master branch that the tag points at: url = git://repo.or.cz/alt-git.git url = https://code.google.com/p/git-core/ url = git://git.sourceforge.jp/gitroot/git-core/git.git url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core url = https://github.com/gitster/git Git v1.7.12 Release Notes (draft) = Updates since v1.7.11 - UI, Workflows & Features * Git can be told to normalize pathnames it read from readdir(3) and all arguments it got from the command line into precomposed UTF-8 (assuming that they come as decomposed UTF-8), in order to work around issues on Mac OS. I think there still are other places that need conversion (e.g. paths that are read from stdin for some commands), but this should be a good first step in the right direction. * Per-user $HOME/.gitconfig file can optionally be stored in $HOME/.config/git/config instead, which is in line with XDG. * The value of core.attributesfile and core.excludesfile default to $HOME/.config/attributes and $HOME/.config/ignore respectively when these files exist. * Logic to disambiguate abbreviated object names have been taught to take advantage of object types that are expected in the context, e.g. XX in the "git describe" output v1.2.3-gXX must be a commit object, not a blob nor a tree. This will help us prolong the lifetime of abbreviated object names. * "git apply" learned to wiggle the base version and perform three-way merge when a patch does not exactly apply to the version you have. * Scripted Porcelain writers now have access to the credential API via the "git credential" plumbing command. * "git help" used to always default to "man" format even on platforms where "man" viewer is not widely available. * "git clone --local $path" started its life as an experiment to optionally use link/copy when cloning a repository on the disk, but we didn't deprecate it after we made the option a no-op to always use the optimization. The command learned "--no-local" option to turn this off, as a more explicit alternative over use of file:// URL. * "git fetch" and friends used to say "remote side hung up unexpectedly" when they failed to get response they expect from the other side, but one common reason why they don't get expected response is that the remote repository does not exist or cannot be read. The error message in this case was updated to give better hints to the user. * git native protocol agents learned to show software version over the wire, so that the server log can be examined to see the vintage distribution of clients. * "git help -w $cmd" can show HTML version of documentation for "git-$cmd" by setting help.htmlpath to somewhere other than the default location where the build procedure installs them locally; the variable can even point at a http:// URL. * "git rebase [-i] --root $tip" can now be used to rewrite all the history leading to "$tip" down to the root commit. * "git rebase -i" learned "-x " to insert "exec " after each commit in the resulting history. * "git status" gives finer classification to various states of paths in conflicted state and offer advice messages in its output. * "git submodule" learned to deal with nested submodule structure where a module is contained within a module whose origin is specified as a relative URL to its superproject's origin. * A rather heavy-ish "git completion" script has been split to create a separate "git prompting" script, to help lazy-autoloading of the completion part while making prompting part always available. * "gitweb" pays attention to various forms of credits that are similar to "Signed-off-by:" lines in the commit objects and highlights them accordingly. Foreign Interface * "mediawiki" remote helper (in contrib/) learned to handle file attachments. * "git p4" now uses "Jobs:" and "p4 move" when appropriate. * vcs-svn has been updated to clean-up compilation, lift 32-bit limitations, etc. Performance, Internal Implementation, etc. (please report possible regressions) * Some tests showed false failures caused by a bug in ecryptofs. * We no longer use AsciiDoc7 syntax in our documentation and favor a more modern style. * "git am --rebasing" codepath was taught to grab authorship, log message and the patch text directly out of existing commi
git pull --quiet is not quiet
I have noticed that git pull --quiet is actually only "quiet" if no problems are found If unmerged error occurs, output is seen on BOTH stdout and stderr $ git pull -q >/dev/null Pull is not possible because you have unmerged files. Please, fix them up in the work tree, and then use 'git add/rm ' as appropriate to mark resolution, or use 'git commit -a'. $ git pull -q 2>/dev/null U AdobeHDS.php The --quiet option should at least silence the stdout. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GSoC] Designing a faster index format - Progress report week 14
On Tue, Jul 24, 2012 at 2:08 AM, Thomas Gummerer wrote: > - We added a POC, for partial loading in git grep. This is still a > pretty hacky implementation, but it demonstrates pretty well > how much can be gained. Here are the timings Thomas posted on > IRC yesterday. The improvements of ls-files are not drastic > compared to index-v4, but git greps in subdirs benefit a lot > from partial loading. > > Test this tree > --- > 0002.2: v[23]: ls-files 0.13(0.11+0.02) > 0002.3: v[23]: grep nonexistent -- subdir 0.12(0.10+0.02) > 0002.5: v4: ls-files 0.11(0.09+0.01) > 0002.6: v4: grep nonexistent -- subdir0.10(0.08+0.02) > 0002.8: v5: ls-files 0.10(0.07+0.02) > 0002.9: v5: grep nonexistent -- subdir0.01(0.00+0.00) > Is ls-files improvement not drastic because you do not limit subdir like grep? I see Thomas Rast put similar partial loading hack to ls-files.c so I assume it can partial load too. Is partial loading still fast with when a lot of unmerged entries are present? -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Solve git-submodule issues with detached work trees
Jens Lehmann writes: > Not inside the submodule, me thinks they only make sense in the > superproject (that's why we clean the environment before working > inside the submodule). Yes, that is fundamental and the only sane behaviour that comes from what submodules are. They are free-standing projects. Not clearing these environments when Git recurses into submodule was simply a bug (the original bug was that we added recursion without thinking these things through). Hence... > But setting the superproject's GIT_WORK_TREE > to something else won't work for an already initialized submodule, ... if you point the _root_ of the toplevel superproject with GIT_WORK_TREE (and the repository of the superproject with GIT_DIR), and chdir into one of its submodule's working tree, we shouldn't say $GIT_WORK_TREE/$smpath is the submodule world. That will make it impossible to work only on submodules by setting GIT_WORK_TREE to point at its root level (and the submodule repository with GIT_DIR). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 6/7] build: "make clean" should not remove configure-generated files
Stefano Lattarini writes: > ... and here we should add "invocation": > > ... the "make install" invocation ... > >> falls back to the default prefix of '$HOME', thus installing git >> in the user's home directory -- definitely unexpected. > > Can you fix those nits locally before merging to 'next', or should > I send a re-roll? Too late X-<. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 7/7] build: reconfigure automatically if configure.ac changes
Hi Junio. I've just noticed a minor typo in the commit message ... On 07/19/2012 09:50 AM, Stefano Lattarini wrote: > This provides a reduced but still useful sibling of the Automake's > "automatic Makefile rebuild" feature. It's important to note that > we take care to enable the new rules only if the tree that has already > be > ... here, it should read "been", not "be". Can you fix that locally before merging to 'next', or should I send a re-roll? > configured with './configure', so that users relying on manual > configuration won't be negatively impacted. Thanks, Stefano -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Solve git-submodule issues with detached work trees
Am 23.07.2012 22:34, schrieb Junio C Hamano: > Jens Lehmann writes: > >> We could get rid of the core.worktree setting by assuming that the >> directory a gitfile was found in is the root of the repo's work >> tree (unless configured otherwise). > > Now you lost me. If you have .git that is not a directory but is a > gitfile, then you do not need GIT_DIR nor GIT_WORK_TREE in the first > place, no? Not inside the submodule, me thinks they only make sense in the superproject (that's why we clean the environment before working inside the submodule). But setting the superproject's GIT_WORK_TREE to something else won't work for an already initialized submodule, as the core.worktree setting will still point to the old work tree which was set when the submodule was initialized. One could expect the submodule's work tree to be $GIT_WORK_TREE/$sm_path when GIT_WORK_TREE is set, but it isn't. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 6/7] build: "make clean" should not remove configure-generated files
Hi Junio. On 07/19/2012 09:50 AM, Stefano Lattarini wrote: > Those filed > Oops, this should read "files", not "filed" ... > hold variables, settings and information set by the > configuration process run by './configure'; in Autotools-based > build system that kind of stuff should only be removed by > "make distclean". Having it removed by "make clean" is not only > inconsistent, but causes real confusion for that part of the Git > audience that is used to the Autotools semantics; for example, > an autotools old-timer that has run: > > ./configure --prefix /opt/git > > in the past, without running "make distclean" afterwards, would > expect a "make install" issued after a "make clean" to rebuild and > install git in '/opt/git'; but with the current behaviour, the > "make clean" invocation removes (among the other things) the file > 'config.mak.autogen', so that the "make install" > ... and here we should add "invocation": ... the "make install" invocation ... > falls back to the default prefix of '$HOME', thus installing git > in the user's home directory -- definitely unexpected. Can you fix those nits locally before merging to 'next', or should I send a re-roll? Thanks, and sorry for the confusion, Stefano -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Make sure to use Araxis' "compare" and not e.g. ImageMagick's
On 24.07.2012 00:41, Junio C Hamano wrote:
> + if test -f $(dirname "$(type --path compare)")/AraxisMerge
We would need additional quotes around the whole path here as the Windows
installation path is usually something like "C:\Program Files\Araxis\Araxis
Merge" and contains spaces.
Moreover, "test -f" requires the ".exe" extension to be explicitly present for
the file to test. But I'd rather not do that because the test would be specific
to Windows then and e.g. not work on Mac OS X. That's why I'd still like to use
ls like in my first patch:
mergetools/araxis | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/mergetools/araxis b/mergetools/araxis
index 64f97c5..c406ead 100644
--- a/mergetools/araxis
+++ b/mergetools/araxis
@@ -16,5 +16,18 @@ merge_cmd () {
}
translate_merge_tool_path() {
- echo compare
+ case "$BASH_VERSION" in
+ ??*)
+ # we can safely use "type --path"
+ if ls "$(dirname "$(type --path compare)")"/Araxis* >/dev/null
2>&1
+ then
+ echo compare
+ else
+ echo "$1"
+ fi
+ ;;
+ *)
+ echo compare
+ ;;
+ esac
}
--
Sebastian Schuberth
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Make sure to use Araxis' "compare" and not e.g. ImageMagick's
Junio C Hamano writes:
> If we limit the problem space by special casing Windows installation
> (e.g. check "uname -s" or something), would it make the problem
> easier to solve? Perhaps it is much more likely that the path the
> program is installed in can be safely identified with a call to
> "type --path compare" (bash is the only shell shipped in msysgit,
> isn't it?).
E.g. something along the lines of your original patch. I do not
know what other commands are typically installed in the same
directory as "compare", so it is likely you need to fix the name of
the file to let us positively identify "compare" is from the Araxis
suite.
mergetools/araxis | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/mergetools/araxis b/mergetools/araxis
index 64f97c5..1180a32 100644
--- a/mergetools/araxis
+++ b/mergetools/araxis
@@ -16,5 +16,18 @@ merge_cmd () {
}
translate_merge_tool_path() {
- echo compare
+ case "$BASH_VERSION" in
+ ??*)
+ # we can safely use "type --path"
+ if test -f $(dirname "$(type --path compare)")/AraxisMerge
+ then
+ echo compare
+ else
+ echo "$1"
+ fi
+ ;;
+ *)
+ echo compare
+ ;;
+ esac
}
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Make sure to use Araxis' "compare" and not e.g. ImageMagick's
On Tue, Jul 24, 2012 at 12:22 AM, Junio C Hamano wrote: > On the other hand, if the user has bought and installed Araxis, but > we incorrectly identify it as unusable, the user has wasted good > money and there is no easy recourse as far as I can see in your > patch. Agreed. > If we limit the problem space by special casing Windows installation > (e.g. check "uname -s" or something), would it make the problem > easier to solve? Perhaps it is much more likely that the path the > program is installed in can be safely identified with a call to > "type --path compare" (bash is the only shell shipped in msysgit, > isn't it?), and its output is likely to contain "/Program Files/Araxis/" > as a substring, or something? Yes, I could come up with basically a variant of my first version of the patch that is limited to Windows only and uses "type --path" instead of "which", but then again this is too non-generic for my taste. Moreover, as I'm also using Mac OS X, I'd be interested in a solution that works there, too. I don't see a good (read generic and concise) solution to the issue. I think we should just drop my patch and not waste all of our time on it any more. -- Sebastian Schuberth -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mergetool: support --tool-help option like difftool does
Sebastian Schuberth writes: > On Mon, Jul 23, 2012 at 11:16 PM, Junio C Hamano wrote: > >> There are only five or six classes of environment that matter in the >> real world for the purpose of giving "well known" examples: Windows, >> MacOS X, Gnome, KDE and Linux terminal. By picking a representative >> one from each and listing them, the end result would have at least >> one that people from various platforms have _heard of_ and can guess >> what they do. The "most common" is secondary, and "well known" is > > I completely agree with this. So we should take the chance and add a > Windows representative to the list of difftools, no? I do not care very deeply either way. I am more interested in seeing --tool-list options supported by both so that we can get rid of hardcoded list from the completion script. > This drops the explicit mention of --tool-help as an option in the > documentation compared to my patch. Do you want to keep --tool-help > being mentioned inline as part of the --tool option documentation > only? While I do not think having one would hurt that much, I do not think a separate entry would add much value either, so I chose not to clutter the documentation further. The "--tool=" entry is enough hint to draw eyes of readers who want to find out what kind of backends are supported, and --tool-help is mentioned there quite prominently. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GSoC] Designing a faster index format - Progress report week 13
Junio C Hamano skrev 2012-07-22 23.08: Thomas Rast writes: Hum, I'm a bit lost now. What is the status quo? I take it JGit does not have any of ctime, dev, ino etc., and either leaves the existing value or puts a 0 an argument in favor of splitting stat_crc into its fields again? A difference is that JGit already has such code, and we would be adding a burden to do so yet again. It also may not just be JGit, but anything that wants to be "compatible" with systems whose filesystem interface does not give enough data by omitting fields the current index pays attention to. It isn't really a discussion about splitting again, but more about not squishing them into a new field in the first place---IIUC, even outside Windows, ctime is already problematic on some systems where background processes muck with extended attributes Git does not pay attention to. If the patch makes us lose the ability to selectively ignore changes to certain fields (e.g. changes to dev and ino are noticed but ctime are ignored) by squishing them into one new field, wouldn't removing them without adding such a useless field a simpler way to go? I wasnt't thinking of splitting, but now I read it again, I do think it should split. Having size accessible is a good thing, and even better if it a 64-bit value so we don't have the modulo-4G problem when looking at it. Current size is 4G + 33 bytes, index says 33. Did the file change or not? Having access to size make the need for actually invoking the racy git logic and comparing file content less likely. As for ctime it is accessible in Java7, though everyone aren't using it and JGit code has to run on Java5. An idea is to make an optional component, but that doesn't make ctime available everywhere. -- robin -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Make sure to use Araxis' "compare" and not e.g. ImageMagick's
Sebastian Schuberth writes: > Personally, I've valued the gain of > the patch to not list araxis as an available diff tool by "git > difftool --tool-help" when in fact just ImageMagick is in PATH higher > than the loss to support araxis installations that are in a path not > containung "araxis" but are in PATH. I agree that running ImageMagick's compare by accident is one thing we would want to avoid, but once the problem is diagnosed, it is something the user can easily work around by futzing %PATH%, I think. On the other hand, if the user has bought and installed Araxis, but we incorrectly identify it as unusable, the user has wasted good money and there is no easy recourse as far as I can see in your patch. That is why I wanted to see a reasonable assurance. If we limit the problem space by special casing Windows installation (e.g. check "uname -s" or something), would it make the problem easier to solve? Perhaps it is much more likely that the path the program is installed in can be safely identified with a call to "type --path compare" (bash is the only shell shipped in msysgit, isn't it?), and its output is likely to contain "/Program Files/Araxis/" as a substring, or something? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] commit: give a hint when a commit message has been abandoned
Jeff King writes:
> On Mon, Jul 23, 2012 at 02:35:01PM -0700, Junio C Hamano wrote:
> ...
>> I also wondered if something like the following might be useful, but
>> it probably falls into the "water under the bridge" category.
>>
>> builtin/commit.c | 5 +
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/builtin/commit.c b/builtin/commit.c
>> index 149e07d..83bcee4 100644
>> --- a/builtin/commit.c
>> +++ b/builtin/commit.c
>> @@ -768,6 +768,11 @@ static int prepare_to_commit(const char *index_file,
>> const char *prefix,
>> "with '#' will be kept; you may remove them"
>> " yourself if you want to.\n"
>> "An empty message aborts the commit.\n"));
>> +status_printf(s, GIT_COLOR_NORMAL,
>> + _("The file '%s' keeps a copy of the log
>> message\n"
>> +"you edited, if you wish to inspect it later.\n"
>> +"It will be wiped by the next invocation of
>> 'git commit'.\n"),
>> + git_path("COMMIT_EDITMSG"));
>
> That seems excessive, as it is inside the file itself. Unless your
> editor is terrible, it already shows you that information.
The pathname was not the part that was interesting; "If you wish to
inspect it later" was.
But that is what makes it water under the bridge. The message will
be gone by the time you really need it.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Make sure to use Araxis' "compare" and not e.g. ImageMagick's
On Mon, Jul 23, 2012 at 11:34 PM, David Aguilar wrote: > Sebastian, are you testing on Windows? The araxis "compare" I used is > OS X. Does "compare version" open a GUI window for you? For me it > does not. > What about "compare -h", or just "compare" ? Yes, I'm testing on Windows, and unfortunately Araxis behaves differently here: - running "compare version" or "compare blah" prints nothing on the console, but the GUI opens saying it is unable to open a file "version" (which it would compare to nothing), - "compare -h" or just "compare" both open up the usage dialog listing all valid command line options (because "-h" is invalid). -- Sebastian Schuberth -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] commit: give a hint when a commit message has been abandoned
On Mon, Jul 23, 2012 at 02:35:01PM -0700, Junio C Hamano wrote:
> > +FILES
> > +-
> > +
> > +`$GIT_DIR/COMMIT_EDITMSG`::
> > + This file contains the commit message of a commit in progress.
> > + If `git-commit` exits due to an error before creating a commit,
> > + any commit message that has been provided by the user (e.g., in
> > + an editor session) will be available in this file, but will be
> > + overwritten by the next invocation of `git-commit`.
> >
> > SEE ALSO
> >
>
> Very sensible, modulo s/git-commit/git commit/ and lack of S-o-b.
Yeah, I'm used to using the dashed form in documentation, but it's
probably reasonable to use the normal spaced form here. I assume you can
forge my S-o-b?
> I also wondered if something like the following might be useful, but
> it probably falls into the "water under the bridge" category.
>
> builtin/commit.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/builtin/commit.c b/builtin/commit.c
> index 149e07d..83bcee4 100644
> --- a/builtin/commit.c
> +++ b/builtin/commit.c
> @@ -768,6 +768,11 @@ static int prepare_to_commit(const char *index_file,
> const char *prefix,
> "with '#' will be kept; you may remove them"
> " yourself if you want to.\n"
> "An empty message aborts the commit.\n"));
> + status_printf(s, GIT_COLOR_NORMAL,
> + _("The file '%s' keeps a copy of the log
> message\n"
> + "you edited, if you wish to inspect it later.\n"
> + "It will be wiped by the next invocation of
> 'git commit'.\n"),
> + git_path("COMMIT_EDITMSG"));
That seems excessive, as it is inside the file itself. Unless your
editor is terrible, it already shows you that information.
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] commit: give a hint when a commit message has been abandoned
Jeff King writes:
> Here's a documentation patch.
>
> -- >8 --
> Subject: [PATCH] commit: document the temporary commit message file
>
> We do not document COMMIT_EDITMSG at all, but users may want
> to know about it for two reasons:
>
> 1. They may want to tell their editor to configure itself
> for formatting a commit message.
>
> 2. If a commit is aborted by an error, the user may want
> to recover the commit message they typed.
>
> Let's put a note in git-commit(1).
> ---
> Documentation/git-commit.txt | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
> index f400835..87297dc 100644
> --- a/Documentation/git-commit.txt
> +++ b/Documentation/git-commit.txt
> @@ -407,6 +407,15 @@ This command can run `commit-msg`, `prepare-commit-msg`,
> `pre-commit`,
> and `post-commit` hooks. See linkgit:githooks[5] for more
> information.
>
> +FILES
> +-
> +
> +`$GIT_DIR/COMMIT_EDITMSG`::
> + This file contains the commit message of a commit in progress.
> + If `git-commit` exits due to an error before creating a commit,
> + any commit message that has been provided by the user (e.g., in
> + an editor session) will be available in this file, but will be
> + overwritten by the next invocation of `git-commit`.
>
> SEE ALSO
>
Very sensible, modulo s/git-commit/git commit/ and lack of S-o-b.
I also wondered if something like the following might be useful, but
it probably falls into the "water under the bridge" category.
builtin/commit.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/builtin/commit.c b/builtin/commit.c
index 149e07d..83bcee4 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -768,6 +768,11 @@ static int prepare_to_commit(const char *index_file, const
char *prefix,
"with '#' will be kept; you may remove them"
" yourself if you want to.\n"
"An empty message aborts the commit.\n"));
+ status_printf(s, GIT_COLOR_NORMAL,
+ _("The file '%s' keeps a copy of the log
message\n"
+ "you edited, if you wish to inspect it later.\n"
+ "It will be wiped by the next invocation of
'git commit'.\n"),
+ git_path("COMMIT_EDITMSG"));
if (only_include_assumed)
status_printf_ln(s, GIT_COLOR_NORMAL,
"%s", only_include_assumed);
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Make sure to use Araxis' "compare" and not e.g. ImageMagick's
On Mon, Jul 23, 2012 at 2:24 PM, Junio C Hamano wrote: > Sebastian Schuberth writes: > >> We have no such assurance. That's why you correctly call it a >> heuristics after all > > ImageMagick "compare" takes "--version" and says something like > this to its standard output: > > $ compare --version > Version: ImageMagick 6.6.0-4 2012-05-02 Q16 > http://www.imagemagick.org > Copyright: Copyright (C) 1999-2010 ImageMagick Studio LLC > > Does Araxis compare take "--version" and behave in a way that is > cheaply controllable? If it opens a GUI window and pops up a dialog > that says "Option not understood", then it is not "controllable", > but if it quickly dies with "No such option" sent to the standard > error output, or sending its version string to the standard output, > then we could use something like: > > case "$(compare --version 2>/dev/null)" in > "Araxis compare version"*) > echo compare ;; > *) > echo "$1" ;; > esac > > instead, and that would be more robust than the path based > heuristics. Araxis compare (the one I have) does not accept --version. Also, the GraphicsMagick (ImageMagick fork) compare does not have --version, but it does have "compare version": $ compare version GraphicsMagick 1.3.12 2010-03-08 Q8 http://www.GraphicsMagick.org/ Copyright (C) 2002-2010 GraphicsMagick Group. Additional copyrights and licenses apply to this software. See http://www.GraphicsMagick.org/www/Copyright.html for details. ... If we care to blacklist *Magick compare, then we may be able to call "compare version" and parse the output looking for "Magic". I tested ImageMagick compare and it also understands "compare version". Araxis compare prints nothing when "compare version" is called. Likely because it thinks it has nothing to do. It does the same if I say "compare blahblah", and returns exit status 0. So its output is useless. It seems like the best we can do is specifically blacklist the *Magick "compare" commands so that they do not show up as false positives. And the only way to identify them is to parse their output, since all commands return status 0 for "compare version". Another possibility is to parse the output of "compare" (no args) and grep for "merge". The name "Araxis Merge" is never actually printed, but the help text for "-merge" does appear yep.. it's a heuristic. Sebastian, are you testing on Windows? The araxis "compare" I used is OS X. Does "compare version" open a GUI window for you? For me it does not. What about "compare -h", or just "compare" ? -- David -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Make sure to use Araxis' "compare" and not e.g. ImageMagick's
On Mon, Jul 23, 2012 at 11:24 PM, Junio C Hamano wrote: > Does Araxis compare take "--version" and behave in a way that is > cheaply controllable? If it opens a GUI window and pops up a dialog > that says "Option not understood", then it is not "controllable", Araxis opens up a GUI dialog with usage info in that case, so it's not controllable, unfortunately. -- Sebastian Schuberth -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mergetool: support --tool-help option like difftool does
On Mon, Jul 23, 2012 at 11:16 PM, Junio C Hamano wrote: > There are only five or six classes of environment that matter in the > real world for the purpose of giving "well known" examples: Windows, > MacOS X, Gnome, KDE and Linux terminal. By picking a representative > one from each and listing them, the end result would have at least > one that people from various platforms have _heard of_ and can guess > what they do. The "most common" is secondary, and "well known" is I completely agree with this. So we should take the chance and add a Windows representative to the list of difftools, no? > Unlike POSIXy folks, where IRIX or Solaris users are likely to have > heard of Gnome tools even if they do not use the environment on > their platforms, Windows users tend to be isolated bunch, so it > would not hurt to include at least one well-known Windows-only tool > in the list. Heh. I believe POSIX folks are no less isolated. (How many Windows-only tools would you recognize by name?) They're just isolated in a bigger world ;-) > Here is a v2, with documentation updates. This drops the explicit mention of --tool-help as an option in the documentation compared to my patch. Do you want to keep --tool-help being mentioned inline as part of the --tool option documentation only? -- Sebastian Schuberth -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Make sure to use Araxis' "compare" and not e.g. ImageMagick's
Sebastian Schuberth writes: > Please feel free to ignore the patch if you feel the heuristics is not > sufficiently safe. I'm currently unable to come up with a safer > solution while maintaining portability, i.e. not use "which" or doing > rather laborious string parsing on the output of "type". How about looking at "compare --version"? Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Make sure to use Araxis' "compare" and not e.g. ImageMagick's
Sebastian Schuberth writes: > We have no such assurance. That's why you correctly call it a > heuristics after all ImageMagick "compare" takes "--version" and says something like this to its standard output: $ compare --version Version: ImageMagick 6.6.0-4 2012-05-02 Q16 http://www.imagemagick.org Copyright: Copyright (C) 1999-2010 ImageMagick Studio LLC Does Araxis compare take "--version" and behave in a way that is cheaply controllable? If it opens a GUI window and pops up a dialog that says "Option not understood", then it is not "controllable", but if it quickly dies with "No such option" sent to the standard error output, or sending its version string to the standard output, then we could use something like: case "$(compare --version 2>/dev/null)" in "Araxis compare version"*) echo compare ;; *) echo "$1" ;; esac instead, and that would be more robust than the path based heuristics. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mergetool: support --tool-help option like difftool does
David Aguilar writes:
> On Mon, Jul 23, 2012 at 1:14 PM, Sebastian Schuberth
> wrote:
>> On Mon, Jul 23, 2012 at 9:52 PM, Junio C Hamano wrote:
>>
-t ::
--tool=::
- Use the diff tool specified by . Valid values include
- emerge, kompare, meld, and vimdiff. Run `git difftool --tool-help`
- for the list of valid settings.
+ Use the diff tool specified by .
>>>
>>> I do not see how it is an improvement to drop the most common ones.
>>> People sometimes read documentation without having an access to
>>> shell to run "cmd --tool-help", and a list of handful of well known
>>> ones would serve as a good hint to let the reader know the kind of
>>> commands the front-end is capable of spawning, which in turn help
>>> such a reader to imagine how the command is used to judge if it is
>>> something the reader wants to use.
>>
>> I don't agree. What "most common ones" are depends on your platform
>> and is sort of subjective. So it should be either all or non here.
>
> Let's please leave this section as-is.
Yes.
There are only five or six classes of environment that matter in the
real world for the purpose of giving "well known" examples: Windows,
MacOS X, Gnome, KDE and Linux terminal. By picking a representative
one from each and listing them, the end result would have at least
one that people from various platforms have _heard of_ and can guess
what they do. The "most common" is secondary, and "well known" is
the keyword. "Can guess what they do" is the point of the phrase
"Valid values _include_". Even if you are hard-core Emacs user, it
is likely that you've heard of vimdiff---and in that case, including
vimdiff would be enough. Likewise for showing kompare to Gnome users.
Unlike POSIXy folks, where IRIX or Solaris users are likely to have
heard of Gnome tools even if they do not use the environment on
their platforms, Windows users tend to be isolated bunch, so it
would not hurt to include at least one well-known Windows-only tool
in the list.
> Yes, indeed, it is arbitrary. It does have some merit, though--it is
> also a good compromise between unhelpful (listing nothing) and painful
> to maintain (listing everything).
Here is a v2, with documentation updates.
-- >8 --
Subject: [PATCH] mergetool: support --tool-help option like difftool does
This way we do not have to risk the list of tools going out of sync
between the implementation and the documentation.
In the same spirit as bf73fc2 (difftool: print list of valid tools
with '--tool-help', 2012-03-29), trim the list of merge backends in
the documentation. We do not want to have a complete of valid tools
there; we only want a list to help people guess what kind of things
the tools that can be specified there, and refer them to --tool-help
for a complete list.
Signed-off-by: Junio C Hamano
---
Documentation/git-mergetool.txt | 6 +++---
git-mergetool--lib.sh | 6 +-
git-mergetool.sh| 42 -
3 files changed, 49 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-mergetool.txt b/Documentation/git-mergetool.txt
index 2a49de7..d1e08d2 100644
--- a/Documentation/git-mergetool.txt
+++ b/Documentation/git-mergetool.txt
@@ -27,9 +27,9 @@ OPTIONS
-t ::
--tool=::
Use the merge resolution program specified by .
- Valid merge tools are:
- araxis, bc3, diffuse, ecmerge, emerge, gvimdiff, kdiff3,
- meld, opendiff, p4merge, tkdiff, tortoisemerge, vimdiff and xxdiff.
+ Valid values include emerge, gvimdiff, kdiff3,
+ meld, vimdiff, and tortoisemerge. Run `git mergetool --tool-help`
+ for the list of valid settings.
+
If a merge resolution program is not specified, 'git mergetool'
will use the configuration variable `merge.tool`. If the
diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
index ed630b2..f730253 100644
--- a/git-mergetool--lib.sh
+++ b/git-mergetool--lib.sh
@@ -111,7 +111,7 @@ run_merge_tool () {
return $status
}
-guess_merge_tool () {
+list_merge_tool_candidates () {
if merge_mode
then
tools="tortoisemerge"
@@ -136,6 +136,10 @@ guess_merge_tool () {
tools="$tools emerge vimdiff"
;;
esac
+}
+
+guess_merge_tool () {
+ list_merge_tool_candidates
echo >&2 "merge tool candidates: $tools"
# Loop over each candidate and stop when a valid merge tool is found.
diff --git a/git-mergetool.sh b/git-mergetool.sh
index a9f23f7..0db0c44 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -8,7 +8,7 @@
# at the discretion of Junio C Hamano.
#
-USAGE='[--tool=tool] [-y|--no-prompt|--prompt] [file to merge] ...'
+USAGE='[--tool=tool] [--tool-help] [-y|--no-prompt|--prompt] [file to merge]
...'
SUBDIRECTORY_OK=Yes
OPTIONS_SPEC=
TOOL_MODE=merge
@@ -284,11 +284,51 @@ merge_file () {
return 0
}
+show_tool_help () {
+ TOOL_MODE=merge
+ lis
Re: [PATCH 3/3] commit: give a hint when a commit message has been abandoned
On Mon, Jul 23, 2012 at 02:00:19PM -0700, Junio C Hamano wrote: > >> Liberal use of atexit() for something like this makes me cringe > >> somewhat. > > > > I don't like it either, but there's not really a better way. The die() > > that Ramana triggered in the initial report is deep inside the ident > > code. The only other option would be to hook into die_routine, which I > > think is even uglier. > > Then I would rather not worry about it. A documentation update is > probably a good first step, though. I'm OK with dropping this one; the likely cause is ident problems, and the previous patch already helped with that (the next likely is probably commit hooks failing, but that is just a guess). Here's a documentation patch. -- >8 -- Subject: [PATCH] commit: document the temporary commit message file We do not document COMMIT_EDITMSG at all, but users may want to know about it for two reasons: 1. They may want to tell their editor to configure itself for formatting a commit message. 2. If a commit is aborted by an error, the user may want to recover the commit message they typed. Let's put a note in git-commit(1). --- Documentation/git-commit.txt | 9 + 1 file changed, 9 insertions(+) diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt index f400835..87297dc 100644 --- a/Documentation/git-commit.txt +++ b/Documentation/git-commit.txt @@ -407,6 +407,15 @@ This command can run `commit-msg`, `prepare-commit-msg`, `pre-commit`, and `post-commit` hooks. See linkgit:githooks[5] for more information. +FILES +- + +`$GIT_DIR/COMMIT_EDITMSG`:: + This file contains the commit message of a commit in progress. + If `git-commit` exits due to an error before creating a commit, + any commit message that has been provided by the user (e.g., in + an editor session) will be available in this file, but will be + overwritten by the next invocation of `git-commit`. SEE ALSO -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Make sure to use Araxis' "compare" and not e.g. ImageMagick's
On Mon, Jul 23, 2012 at 10:47 PM, Junio C Hamano wrote: > For example, when the user tells it to install in "/home/ss/bin", if > it installs its "compare" program in "/home/ss/bin/araxis/compare" > without allowing the "/araxis/" part to be stripped away, the above > heuristics is sufficiently safe. Otherwise, it is not. To the best of my knowledge, Araxis does not enforce any naming convention for the path it gets installed in. That means the user may indeed install the program in a path that does not contain "araxis". I was aware of this when writing the patch, but should have probably made it more clear in the commit message. > It is unclear from your proposed commit log message what assurance > do we have that it is installed under such a path and why the > heuristics the patch implements is the sane way forward. We have no such assurance. That's why you correctly call it a heuristics after all: it may fail. Personally, I've valued the gain of the patch to not list araxis as an available diff tool by "git difftool --tool-help" when in fact just ImageMagick is in PATH higher than the loss to support araxis installations that are in a path not containung "araxis" but are in PATH. Please feel free to ignore the patch if you feel the heuristics is not sufficiently safe. I'm currently unable to come up with a safer solution while maintaining portability, i.e. not use "which" or doing rather laborious string parsing on the output of "type". -- Sebastian Schuberth -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] commit: give a hint when a commit message has been abandoned
Jeff King writes: > On Mon, Jul 23, 2012 at 01:49:55PM -0700, Junio C Hamano wrote: > >> Jeff King writes: >> >> > If we launch an editor for the user to create a commit >> > message, they may put significant work into doing so. >> > Typically we try to check common mistakes that could cause >> > the commit to fail early, so that we die before the user >> > goes to the trouble. >> > >> > We may still experience some errors afterwards, though; in >> > this case, the user is given no hint that their commit >> > message has been saved. Let's tell them where it is. >> >> Liberal use of atexit() for something like this makes me cringe >> somewhat. > > I don't like it either, but there's not really a better way. The die() > that Ramana triggered in the initial report is deep inside the ident > code. The only other option would be to hook into die_routine, which I > think is even uglier. Then I would rather not worry about it. A documentation update is probably a good first step, though. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] commit: check committer identity more strictly
On Mon, Jul 23, 2012 at 01:51:25PM -0700, Junio C Hamano wrote:
> > diff --git a/builtin/commit.c b/builtin/commit.c
> > index 95eeab1..20cef95 100644
> > --- a/builtin/commit.c
> > +++ b/builtin/commit.c
> > @@ -725,7 +725,7 @@ static int prepare_to_commit(const char *index_file,
> > const char *prefix,
> > strbuf_release(&sb);
> >
> > /* This checks if committer ident is explicitly given */
> > - strbuf_addstr(&committer_ident, git_committer_info(0));
> > + strbuf_addstr(&committer_ident, git_committer_info(IDENT_STRICT));
> > if (use_editor && include_status) {
> > char *ai_tmp, *ci_tmp;
> > if (whence != FROM_COMMIT)
>
> Looks sensible. Is this something we can detect in automated tests,
> or is it too cumbersome to set up?
Sorry, I meant to mention that in the cover letter. No, we can't test
this easily, because the code path in question is triggered by finding a
blank name in /etc/passwd. We'd have to override our getpwent lookup.
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] commit: give a hint when a commit message has been abandoned
On Mon, Jul 23, 2012 at 01:49:55PM -0700, Junio C Hamano wrote: > Jeff King writes: > > > If we launch an editor for the user to create a commit > > message, they may put significant work into doing so. > > Typically we try to check common mistakes that could cause > > the commit to fail early, so that we die before the user > > goes to the trouble. > > > > We may still experience some errors afterwards, though; in > > this case, the user is given no hint that their commit > > message has been saved. Let's tell them where it is. > > Liberal use of atexit() for something like this makes me cringe > somewhat. I don't like it either, but there's not really a better way. The die() that Ramana triggered in the initial report is deep inside the ident code. The only other option would be to hook into die_routine, which I think is even uglier. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] commit: check committer identity more strictly
Jeff King writes:
> Incidentally, this bug was masked prior to 060d4bb, as the
> initial loose call would taint the later strict call. So the
> commit would succeed (albeit with a bogus committer line in
> the commit object), and nobody noticed that our early check
> did not match the later one.
>
> Signed-off-by: Jeff King
> ---
> builtin/commit.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/builtin/commit.c b/builtin/commit.c
> index 95eeab1..20cef95 100644
> --- a/builtin/commit.c
> +++ b/builtin/commit.c
> @@ -725,7 +725,7 @@ static int prepare_to_commit(const char *index_file,
> const char *prefix,
> strbuf_release(&sb);
>
> /* This checks if committer ident is explicitly given */
> - strbuf_addstr(&committer_ident, git_committer_info(0));
> + strbuf_addstr(&committer_ident, git_committer_info(IDENT_STRICT));
> if (use_editor && include_status) {
> char *ai_tmp, *ci_tmp;
> if (whence != FROM_COMMIT)
Looks sensible. Is this something we can detect in automated tests,
or is it too cumbersome to set up?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] commit: give a hint when a commit message has been abandoned
Jeff King writes:
> If we launch an editor for the user to create a commit
> message, they may put significant work into doing so.
> Typically we try to check common mistakes that could cause
> the commit to fail early, so that we die before the user
> goes to the trouble.
>
> We may still experience some errors afterwards, though; in
> this case, the user is given no hint that their commit
> message has been saved. Let's tell them where it is.
Liberal use of atexit() for something like this makes me cringe
somewhat.
>
> Signed-off-by: Jeff King
> ---
> I did not bother protecting this with advice.* config, as it is unlikely
> to come up regularly. If somebody cares, they are welcome to add it on
> top.
>
> builtin/commit.c | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/builtin/commit.c b/builtin/commit.c
> index 20cef95..149e07d 100644
> --- a/builtin/commit.c
> +++ b/builtin/commit.c
> @@ -116,6 +116,16 @@ static enum {
> STATUS_FORMAT_PORCELAIN
> } status_format = STATUS_FORMAT_LONG;
>
> +static int mention_abandoned_message;
> +static void maybe_mention_abandoned_message(void)
> +{
> + if (!mention_abandoned_message)
> + return;
> + advise(_("Your commit message has been saved in '%s' and will be\n"
> + "overwritten by the next invocation of \"git commit\"."),
> +git_path(commit_editmsg));
> +}
> +
> static int opt_parse_m(const struct option *opt, const char *arg, int unset)
> {
> struct strbuf *buf = opt->value;
> @@ -848,6 +858,8 @@ static int prepare_to_commit(const char *index_file,
> const char *prefix,
> _("Please supply the message using either -m or -F
> option.\n"));
> exit(1);
> }
> + atexit(maybe_mention_abandoned_message);
> + mention_abandoned_message = 1;
> }
>
> if (!no_verify &&
> @@ -1532,11 +1544,13 @@ int cmd_commit(int argc, const char **argv, const
> char *prefix)
> if (template_untouched(&sb) && !allow_empty_message) {
> rollback_index_files();
> fprintf(stderr, _("Aborting commit; you did not edit the
> message.\n"));
> + mention_abandoned_message = 0;
> exit(1);
> }
> if (message_is_empty(&sb) && !allow_empty_message) {
> rollback_index_files();
> fprintf(stderr, _("Aborting commit due to empty commit
> message.\n"));
> + mention_abandoned_message = 0;
> exit(1);
> }
>
> @@ -1579,6 +1593,7 @@ int cmd_commit(int argc, const char **argv, const char
> *prefix)
> die(_("cannot update HEAD ref"));
> }
>
> + mention_abandoned_message = 0;
> unlink(git_path("CHERRY_PICK_HEAD"));
> unlink(git_path("REVERT_HEAD"));
> unlink(git_path("MERGE_HEAD"));
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Make sure to use Araxis' "compare" and not e.g. ImageMagick's
Sebastian Schuberth writes:
> Signed-off-by: Sebastian Schuberth
> ---
> mergetools/araxis | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/mergetools/araxis b/mergetools/araxis
> index 64f97c5..f8899f8 100644
> --- a/mergetools/araxis
> +++ b/mergetools/araxis
> @@ -16,5 +16,12 @@ merge_cmd () {
> }
>
> translate_merge_tool_path() {
> - echo compare
> + # Only accept "compare" in a path that contains "araxis" to not
> + # accidently use e.g. ImageMagick's "compare".
> + if type compare | grep -i araxis >/dev/null 2>&1
> + then
> + echo compare
> + else
> + echo "$1"
> + fi
> }
I do not use araxis, and I do not know how rigid its installation
procedure is to prevent the end user from naming a path that does
not have the string in it.
For example, when the user tells it to install in "/home/ss/bin", if
it installs its "compare" program in "/home/ss/bin/araxis/compare"
without allowing the "/araxis/" part to be stripped away, the above
heuristics is sufficiently safe. Otherwise, it is not.
It is unclear from your proposed commit log message what assurance
do we have that it is installed under such a path and why the
heuristics the patch implements is the sane way forward.
Please convince me.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mergetool: support --tool-help option like difftool does
On Mon, Jul 23, 2012 at 1:14 PM, Sebastian Schuberth wrote: > On Mon, Jul 23, 2012 at 9:52 PM, Junio C Hamano wrote: > >>> -t :: >>> --tool=:: >>> - Use the diff tool specified by . Valid values include >>> - emerge, kompare, meld, and vimdiff. Run `git difftool --tool-help` >>> - for the list of valid settings. >>> + Use the diff tool specified by . >> >> I do not see how it is an improvement to drop the most common ones. >> People sometimes read documentation without having an access to >> shell to run "cmd --tool-help", and a list of handful of well known >> ones would serve as a good hint to let the reader know the kind of >> commands the front-end is capable of spawning, which in turn help >> such a reader to imagine how the command is used to judge if it is >> something the reader wants to use. > > I don't agree. What "most common ones" are depends on your platform > and is sort of subjective. So it should be either all or non here. Let's please leave this section as-is. This part of the documentation has had a fair amount of churn. Specifically, it would get touched every time a new tool was added. The point of bf73fc212a159210398b6d46ed5e9101c650e7db was to change it *one last time* into something that is helpful, but not a substitute for the real list output by --tool-help. If any changes are done then it should be to make git-mergetool.txt match the advice given in git-difftool.txt. > Your argument about people not having shell access is a valid one, but > still that would mean to list all tools in my opinion. And listing all > tools again thwarts our goal to reduce the number of places where new > merge / diff tools need to be added. For people adding new merge / > diff tools it is just clearer what places need to be modified if there > are no places that list an arbitrary subset of tools. Yes, indeed, it is arbitrary. It does have some merit, though--it is also a good compromise between unhelpful (listing nothing) and painful to maintain (listing everything). -- David -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add a svnrdump-simulator replaying a dump file for testing.
Florian Achleitner writes: > To ease testing without depending on a reachable svn server, this > compact python script mimics parts of svnrdumps behaviour. > It requires the remote url to start with sim://. > Eventual slashes at the end of the url are stripped. s/ventual/xcess/ perhaps? > The url specifies the path of the svn dump file (as created by > svnrdump). Selectable parts of it, or the whole file, are written > to stdout. The part is selectable by giving start and end revision > on the command line. > > Start and end revisions can be specified on the command line > (-rSTART:END, like for svnrdump). > Only revisions between START and excluding END are replayed from > the dumpfile specified by the url. END can also be HEAD. > > If the start revision specified on the command line doesn't exist > in the dump file, it returns 1. > This emulates the behaviour of svnrdump when START>HEAD, i.e. the > requested start revision doesn't exist on the server. Much more understandable than before. > To allow using the same dump file for simulating multiple > incremental imports the highest visible revision can be limited by > setting the environment variable SVNRMAX to that value. This > effectively limits HEAD to simulate the situation where higher > revs don't exist yet. It is unclear how this is different from giving the ceiling by specifying it as the "END" in -rSTART:END command line. Is this feature really needed? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Solve git-submodule issues with detached work trees
Jens Lehmann writes: > We could get rid of the core.worktree setting by assuming that the > directory a gitfile was found in is the root of the repo's work > tree (unless configured otherwise). Now you lost me. If you have .git that is not a directory but is a gitfile, then you do not need GIT_DIR nor GIT_WORK_TREE in the first place, no? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mergetool: support --tool-help option like difftool does
On Mon, Jul 23, 2012 at 9:52 PM, Junio C Hamano wrote: >> -t :: >> --tool=:: >> - Use the diff tool specified by . Valid values include >> - emerge, kompare, meld, and vimdiff. Run `git difftool --tool-help` >> - for the list of valid settings. >> + Use the diff tool specified by . > > I do not see how it is an improvement to drop the most common ones. > People sometimes read documentation without having an access to > shell to run "cmd --tool-help", and a list of handful of well known > ones would serve as a good hint to let the reader know the kind of > commands the front-end is capable of spawning, which in turn help > such a reader to imagine how the command is used to judge if it is > something the reader wants to use. I don't agree. What "most common ones" are depends on your platform and is sort of subjective. So it should be either all or non here. Your argument about people not having shell access is a valid one, but still that would mean to list all tools in my opinion. And listing all tools again thwarts our goal to reduce the number of places where new merge / diff tools need to be added. For people adding new merge / diff tools it is just clearer what places need to be modified if there are no places that list an arbitrary subset of tools. -- Sebastian Schuberth -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Add a svnrdump-simulator replaying a dump file for testing.
To ease testing without depending on a reachable svn server, this
compact python script mimics parts of svnrdumps behaviour.
It requires the remote url to start with sim://.
Eventual slashes at the end of the url are stripped.
The url specifies the path of the svn dump file (as created by
svnrdump). Selectable parts of it, or the whole file, are written
to stdout. The part is selectable by giving start and end revision
on the command line.
Start and end revisions can be specified on the command line
(-rSTART:END, like for svnrdump).
Only revisions between START and excluding END are replayed from
the dumpfile specified by the url. END can also be HEAD.
If the start revision specified on the command line doesn't exist
in the dump file, it returns 1.
This emulates the behaviour of svnrdump when START>HEAD, i.e. the
requested start revision doesn't exist on the server.
To allow using the same dump file for simulating multiple
incremental imports the highest visible revision can be limited by
setting the environment variable SVNRMAX to that value. This
effectively limits HEAD to simulate the situation where higher
revs don't exist yet.
Signed-off-by: Florian Achleitner
---
contrib/svn-fe/svnrdump_sim.py | 53
1 file changed, 53 insertions(+)
create mode 100755 contrib/svn-fe/svnrdump_sim.py
diff --git a/contrib/svn-fe/svnrdump_sim.py b/contrib/svn-fe/svnrdump_sim.py
new file mode 100755
index 000..4701d76
--- /dev/null
+++ b/contrib/svn-fe/svnrdump_sim.py
@@ -0,0 +1,53 @@
+#!/usr/bin/python
+"""
+Simulates svnrdump by replaying an existing dump from a file, taking care
+of the specified revision range.
+To simulate incremental imports the environment variable SVNRMAX can be set
+to the highest revision that should be available.
+"""
+import sys, os
+
+
+def getrevlimit():
+ var = 'SVNRMAX'
+ if os.environ.has_key(var):
+ return os.environ[var]
+ return None
+
+def writedump(url, lower, upper):
+ if url.startswith('sim://'):
+ filename = url[6:]
+ if filename[-1] == '/': filename = filename[:-1] #remove
terminating slash
+ else:
+ raise ValueError('sim:// url required')
+ f = open(filename, 'r');
+ state = 'header'
+ wroterev = False
+ while(True):
+ l = f.readline()
+ if l == '': break
+ if state == 'header' and l.startswith('Revision-number: '):
+ state = 'prefix'
+ if state == 'prefix' and l == 'Revision-number: %s\n' % lower:
+ state = 'selection'
+ if not upper == 'HEAD' and state == 'selection' and l ==
'Revision-number: %s\n' % upper:
+ break;
+
+ if state == 'header' or state == 'selection':
+ if state == 'selection': wroterev = True
+ sys.stdout.write(l)
+ return wroterev
+
+if __name__ == "__main__":
+ if not (len(sys.argv) in (3, 4, 5)):
+ print "usage: %s dump URL -rLOWER:UPPER"
+ sys.exit(1)
+ if not sys.argv[1] == 'dump': raise NotImplementedError('only "dump" is
suppported.')
+ url = sys.argv[2]
+ r = ('0', 'HEAD')
+ if len(sys.argv) == 4 and sys.argv[3][0:2] == '-r':
+ r = sys.argv[3][2:].lstrip().split(':')
+ if not getrevlimit() is None: r[1] = getrevlimit()
+ if writedump(url, r[0], r[1]): ret = 0
+ else: ret = 1
+ sys.exit(ret)
\ No newline at end of file
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Solve git-submodule issues with detached work trees
Am 23.07.2012 20:21, schrieb Junio C Hamano: > Jens Lehmann writes: > >> Am 23.07.2012 07:09, schrieb Junio C Hamano: >>> Daniel Graña writes: >>> A common way to track dotfiles with git is using GIT_DIR and GIT_WORK_TREE to move repository out of ~/.git with something like: git init --bare ~/.dotfiles alias dotfiles="GIT_DIR=~/.dotfiles GIT_WORK_TREE=~ git" dotfiles add ~/.bashrc dotfiles commit -a -m "add my bashrc" ... but git-submodule complains when trying to add submodules: dotfiles submodule add http://path.to/submodule fatal: working tree '/home/user' already exists. git --git-dir ~/.dotfiles submodule add http://path.to/submodule fatal: /usr/lib/git-core/git-submodule cannot be used without a working tree. Signed-off-by: Daniel Graña --- >>> >>> I think this is in line with what we discussed earlier on list when >>> the interaction between GIT_DIR/GIT_WORK_TREE and submodules came up >>> the last time. Jens? >> >> Yes, I think this is the only way submodules in current git can >> be used with the GIT_DIR and GIT_WORK_TREE environment variables: >> set them when adding or initializing the submodule and always use >> the same settings when accessing them later. Daniel's dotfile >> alias achieves exactly that, so his fix looks good. But I agree >> the tests should be improved as you already pointed out. > > Thanks for a quick review. The "the only way ... in current git can > be used" part makes it sound as if it is a somewhat suboptimal ugly > workaround, but if that is what you meant, what is a more optimal > and less ugly way that you have in mind? I don't see it as an ugly workaround, I just don't see a way to get the flexibility GIT_DIR and GIT_WORK_TREE offer for repos without submodules (e.g. put the work tree temporarily somewhere else for deployment or compare the current work tree with the history in a different git directory) without changing core git. I have no idea how many people use this flexibility but when submodules are involved, you have to stick to the choices you made in the first place or things will break. Right now the two relative links tie exactly two directories together as git dir and work tree. I suspect e.g. some setups using symlinks could benefit if we could get rid of one of them or even both. We could get rid of the core.worktree setting by assuming that the directory a gitfile was found in is the root of the repo's work tree (unless configured otherwise). And we could introduce a new gitfile notation which gives the git dir relative to a parent repo's git dir (e.g. "parent: modules/name" or such). But I'm not sure if it is worth the hassle. > If you want to move .git out of way with GIT_DIR and if you want to > sit somewhere different from the top of your working tree, you must > use GIT_WORK_TREE (or core.worktree) to tell where the top resides, > whether your project use submodules or not, so I do not think it is > an ugly workaround but is the one true way to use such a dismembered > layout, I would think. That is a perfect use case and we should make it work. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add a svnrdump-simulator replaying a dump file for testing.
On Mon, Jul 23, 2012 at 09:46:49PM +0200, Matthieu Moy wrote:
> > Damn. That's usually no problem with kmail either, if the config is right.
> > I've already used git-send-email several times.
> > But for replying to threads and adding several Cc: addresses it's a little
> > cumbersome.
> > How do you do that in a nice way?
>
> For the threading itself, I usually find the message-id, and use
> "git send-email --in-reply-to=''". The painful part
> is when you want to reproduce a Cc: list, but I have no magic trick for
> that ;-).
I save a copy of the message I am replying to (usually my cover letter,
which I generated by just replying in my MUA) into a well-known location
(I use a mutt hot-key to do this), and then run it through this
monstrosity:
get_reply_headers() {
perl -ne '
if (defined $opt && /^\s+(.*)/) {
$val .= " $1";
next;
}
if (defined $opt) {
print "--$opt=", quotemeta($val), " ";
$opt = $val = undef;
}
if (/^(cc|to):\s*(.*)/i) {
$opt = lc($1);
$val = $2;
}
elsif (/^message-id:\s*(.*)/i) {
$opt = "in-reply-to";
$val = $1;
}
'
}
which can be used on the command line of format-patch or send-email, like:
eval "git format-patch $(get_reply_headers http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mergetool: support --tool-help option like difftool does
Sebastian Schuberth writes:
> This way we do not have to risk the list of tools go out of sync
> between the implementation and the documentation. Adjust the documentation
> accordingly to not explicitly list the tools but refer to --tool-help.
>
> Signed-off-by: Junio C Hamano
> Signed-off-by: Sebastian Schuberth
> ---
> Documentation/git-difftool.txt | 7 ---
> Documentation/git-mergetool.txt | 8
> git-mergetool--lib.sh | 11 ++-
> git-mergetool.sh| 42
> -
> 4 files changed, 59 insertions(+), 9 deletions(-)
>
> diff --git a/Documentation/git-difftool.txt b/Documentation/git-difftool.txt
> index 31fc2e3..0bdfe35 100644
> --- a/Documentation/git-difftool.txt
> +++ b/Documentation/git-difftool.txt
> @@ -36,9 +36,10 @@ OPTIONS
>
> -t ::
> --tool=::
> - Use the diff tool specified by . Valid values include
> - emerge, kompare, meld, and vimdiff. Run `git difftool --tool-help`
> - for the list of valid settings.
> + Use the diff tool specified by .
I do not see how it is an improvement to drop the most common ones.
People sometimes read documentation without having an access to
shell to run "cmd --tool-help", and a list of handful of well known
ones would serve as a good hint to let the reader know the kind of
commands the front-end is capable of spawning, which in turn help
such a reader to imagine how the command is used to judge if it is
something the reader wants to use.
> +
> +--tool-help::
> + List all supported values for .
> +
> If a diff tool is not specified, 'git difftool'
> will use the configuration variable `diff.tool`. If the
> diff --git a/Documentation/git-mergetool.txt b/Documentation/git-mergetool.txt
> index 2a49de7..99e53b1 100644
> --- a/Documentation/git-mergetool.txt
> +++ b/Documentation/git-mergetool.txt
> @@ -26,10 +26,10 @@ OPTIONS
> ---
> -t ::
> --tool=::
> - Use the merge resolution program specified by .
> - Valid merge tools are:
> - araxis, bc3, diffuse, ecmerge, emerge, gvimdiff, kdiff3,
> - meld, opendiff, p4merge, tkdiff, tortoisemerge, vimdiff and xxdiff.
> + Use the merge tool specified by .
Likewise. Dropping araxis, bc3, etc. to trim the list to 4-5 items
that people would know what they are would make sense, though. The
purpose of the list is not to tell if the reader's favorite tool is
supported or not---it is to hint the flavor of what kind of things
the command spawned would be capable of.
> +
> +--tool-help::
> + List all supported values for .
> +
> If a merge resolution program is not specified, 'git mergetool'
> will use the configuration variable `merge.tool`. If the
> diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
> index ed630b2..f0865d4 100644
> --- a/git-mergetool--lib.sh
> +++ b/git-mergetool--lib.sh
> @@ -111,15 +111,18 @@ run_merge_tool () {
> return $status
> }
>
> -guess_merge_tool () {
> +list_merge_tool_candidates () {
> + # Add tools that can either do merging or diffing, but not both.
> if merge_mode
> then
> tools="tortoisemerge"
> else
> tools="kompare"
> fi
> +
> if test -n "$DISPLAY"
> then
> + # Prefer GTK-based tools under Gnome.
> if test -n "$GNOME_DESKTOP_SESSION_ID"
> then
> tools="meld opendiff kdiff3 tkdiff xxdiff $tools"
> @@ -128,6 +131,8 @@ guess_merge_tool () {
> fi
> tools="$tools gvimdiff diffuse ecmerge p4merge araxis bc3"
> fi
> +
> + # Prefer vimdiff if vim is the default editor.
> case "${VISUAL:-$EDITOR}" in
> *vim*)
> tools="$tools vimdiff emerge"
> @@ -136,6 +141,10 @@ guess_merge_tool () {
> tools="$tools emerge vimdiff"
> ;;
> esac
> +}
> +
> +guess_merge_tool () {
> + list_merge_tool_candidates
> echo >&2 "merge tool candidates: $tools"
>
> # Loop over each candidate and stop when a valid merge tool is found.
> diff --git a/git-mergetool.sh b/git-mergetool.sh
> index a9f23f7..0db0c44 100755
> --- a/git-mergetool.sh
> +++ b/git-mergetool.sh
> @@ -8,7 +8,7 @@
> # at the discretion of Junio C Hamano.
> #
>
> -USAGE='[--tool=tool] [-y|--no-prompt|--prompt] [file to merge] ...'
> +USAGE='[--tool=tool] [--tool-help] [-y|--no-prompt|--prompt] [file to merge]
> ...'
> SUBDIRECTORY_OK=Yes
> OPTIONS_SPEC=
> TOOL_MODE=merge
> @@ -284,11 +284,51 @@ merge_file () {
> return 0
> }
>
> +show_tool_help () {
> + TOOL_MODE=merge
> + list_merge_tool_candidates
> + unavailable= available= LF='
> +'
> + for i in $tools
> + do
> + merge_tool_path=$(translate_merge_tool_path "$i")
> + if type "$merge_tool_path" >/dev/null 2>&1
> + then
> + available="$available$i$LF"
> + else
> + unavailable="$
Re: [PATCH] Add a svnrdump-simulator replaying a dump file for testing.
Florian Achleitner writes: > On Monday 23 July 2012 18:24:40 Matthieu Moy wrote: >> You also have whitespace damages (i.e. line wrapping introduced by your >> mailer). Using git-send-email avoids this kind of problem (there are >> also some advices for some mailers in Documentation/SubmittingPatches). > > Damn. That's usually no problem with kmail either, if the config is right. > I've already used git-send-email several times. > But for replying to threads and adding several Cc: addresses it's a little > cumbersome. > How do you do that in a nice way? For the threading itself, I usually find the message-id, and use "git send-email --in-reply-to=''". The painful part is when you want to reproduce a Cc: list, but I have no magic trick for that ;-). -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Make sure to use Araxis' "compare" and not e.g. ImageMagick's
Signed-off-by: Sebastian Schuberth
---
mergetools/araxis | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/mergetools/araxis b/mergetools/araxis
index 64f97c5..f8899f8 100644
--- a/mergetools/araxis
+++ b/mergetools/araxis
@@ -16,5 +16,12 @@ merge_cmd () {
}
translate_merge_tool_path() {
- echo compare
+ # Only accept "compare" in a path that contains "araxis" to not
+ # accidently use e.g. ImageMagick's "compare".
+ if type compare | grep -i araxis >/dev/null 2>&1
+ then
+ echo compare
+ else
+ echo "$1"
+ fi
}
--
1.7.11.msysgit.2
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add a svnrdump-simulator replaying a dump file for testing.
On Monday 23 July 2012 18:24:40 Matthieu Moy wrote: > You also have whitespace damages (i.e. line wrapping introduced by your > mailer). Using git-send-email avoids this kind of problem (there are > also some advices for some mailers in Documentation/SubmittingPatches). Damn. That's usually no problem with kmail either, if the config is right. I've already used git-send-email several times. But for replying to threads and adding several Cc: addresses it's a little cumbersome. How do you do that in a nice way? -- Florian -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Document rev^! and rev^@ as revision specifiers
Max Horn writes:
>>
> On 06.07.2012, at 21:18, Junio C Hamano wrote:
>
>> Max Horn writes:
>>
> +'{caret}!', e.g. 'HEAD{caret}!'::
> + A suffix '{caret}' followed by an exclamation mark
> + means commit '' but forces all of its parents to be excluded. For
> + commands that deal with a single revision, this is the same as '".
Is this sentence correct? "git commit -C 'HEAD^!'" might be a
command that expects a single revision, but I do not think it is the
same as "git commit -C HEAD".
>>>
>>> Ignoring the exact words I used for the moment, what I meant is
>>> that these two commands should be functionally
>>> equivalent. Aren't they?
>>
>> No. When a single commit is wanted HEAD^! shouldn't be used, and
>> they cannot be functionally equivalent. I haven't tried but I think
>> "commit -C HEAD^!" would give you a syntax error.
>
> Indeed, it says
> fatal: could not lookup commit HEAD^!
>
> I'll iterate over this once more.
Let's do this instead.
-- >8 --
Subject: Enumerate revision range specifiers in the documentation
It was a bit hard to learn how ^@, ^! and various other
forms of range specification are used, because they were discussed
mostly in the prose part of the documentation, unlike various forms
of extended SHA-1 expressions that are listed in enumerated list.
Also add a few more examples showing use of , .. and
^! forms, stolen from a patch by Max Horn.
Signed-off-by: Junio C Hamano
---
Documentation/revisions.txt | 31 +++
1 file changed, 31 insertions(+)
diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt
index f4f6f28..6506ec6 100644
--- a/Documentation/revisions.txt
+++ b/Documentation/revisions.txt
@@ -218,13 +218,44 @@ and its parent commits exist. The 'r1{caret}@' notation
means all
parents of 'r1'. 'r1{caret}!' includes commit 'r1' but excludes
all of its parents.
+To summarize:
+
+''::
+ Include commits that are reachable from (i.e. ancestors of)
+ .
+
+'{caret}'::
+ Exclude commits that are reachable from (i.e. ancestors of)
+ .
+
+'..'::
+ Include commits that are reachable from but exclude
+ those that are reachable from .
+
+'...'::
+ Include commits that are reachable from either or
+but exclude those that are reachable from both.
+
+'{caret}@', e.g. 'HEAD{caret}@'::
+ A suffix '{caret}' followed by an at sign is the same as listing
+ all parents of '' (meaning, include anything reachable from
+ its parents, but not the commit itself).
+
+'{caret}!', e.g. 'HEAD{caret}!'::
+ A suffix '{caret}' followed by an exclamation mark is the same
+ as giving commit '' and then all its parents prefixed with
+ '{caret}' to exclude them (and their ancestors).
+
Here are a handful of examples:
DG H D
D F G H I J D F
^G D H D
^D B E I J F B
+ B..C C
B...CG H D E B C
^D B C E I J F B C
+ CI J F C
C^@ I J F
+ C^! C
F^! DG H D F
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[GSoC] Designing a faster index format - Progress report week 14
== Work done in the previous 13 weeks == - Definition of a tentative index file v5 format [1]. This differs from the proposal in making it possible to bisect the directory entries and file entries, to do a binary search. The exact bits for each section were also defined. To further compress the index, along with prefix compression, the stat data is hashed, since it's only used for equality comparison, but the plain data is never used. Thanks to Michael Haggerty, Nguyen Thai Ngoc Duy, Thomas Rast and Robin Rosenberg for feedback. - Prototype of a converter from the index format v2/v3 to the index format v5. [2] The converter reads the index from a git repository, can output parts of the index (header, index entries as in git ls-files --debug, cache tree as in test-dump-cache-tree, or the reuc data). Then it writes the v5 index file format to .git/index-v5. Thanks to Michael Haggerty for the code review. - Prototype of a reader for the new index file format. [3] The reader has mainly the purpose to show the algorithm used to read the index lexicographically sorted after the full name which is required by the current internal memory format. Big thanks for reviewing this code and giving me advice on refactoring goes to Michael Haggerty. - Read the on-disk index file format and translate it to the current in memory format. This doesn't include reading any of the current extensions, which are now part of the main index. The code again is on github. [4] Thanks for reviewing the first steps to Thomas Rast. - Read the cache-tree data (formerly an extension, now it's integrated with the rest of the directory data) from the new ondisk format. There are still a few optimizations to do in this algorithm. - Started implementing the API (suggested by Duy), but it's still in the very early stages. There is one commit for this on GitHub [1], but it's a very early work in progress. - Started implementing the writer, which extracts the directories from the in-memory format, and writes the header and the directories to disk. The algorithm uses a hash-table instead of a simple list, to avoid many corner cases. - Implemented writing the file block to disk, and basic tests from the test suite are running fine, not including tests that require conflicted data or the cache-tree to work, which both are not implemented yet. - Started implementing a patch to introduce a ce_namelen field in struct cache_entry and drop the name length from the flags. [5] Thanks to Junio, Duy and Thomas for reviews and suggestions for improving it. - Implemented the cache-tree and conflict data writing to the index-v5 file. == Work done in the last week == - Fixed a few bugs in cache-tree and conflict writing in my index-v5 code. - I visited Thomas in Zuerich this weekend, as some of you may have noticed on the mailing list, thanks a lot for the hospitality. And thanks also to Tomas for the company on saturday night. - With the help of Thomas I fixed the resolve undo data writing, and a couple more bugs in my code, so that the test suite passes with INDEX_VERSION_DEFAULT = 5. - We added a POC, for partial loading in git grep. This is still a pretty hacky implementation, but it demonstrates pretty well how much can be gained. Here are the timings Thomas posted on IRC yesterday. The improvements of ls-files are not drastic compared to index-v4, but git greps in subdirs benefit a lot from partial loading. Test this tree --- 0002.2: v[23]: ls-files 0.13(0.11+0.02) 0002.3: v[23]: grep nonexistent -- subdir 0.12(0.10+0.02) 0002.5: v4: ls-files 0.11(0.09+0.01) 0002.6: v4: grep nonexistent -- subdir0.10(0.08+0.02) 0002.8: v5: ls-files 0.10(0.07+0.02) 0002.9: v5: grep nonexistent -- subdir0.01(0.00+0.00) - All changes again are in my repository on github, in case someone wants to try them out. [4] == Outlook for the next week == - Refactoring of the code. There are still some code smells in the current code, which need to be refactored. - There are also still some possible optimizations for the code, which will be included. - I'll also bring the reader up to date again, and make it possible for it to update a single index entry, to test the implementation of rereading a entry when the crc is wrong (for the future partial write, both writer and reader side still have to be implemented). [1] https://github.com/tgummerer/git/wiki/Index-file-format-v5 [2] https://github.com/tgummerer/git/blob/pythonprototype/git-convert-index.py [3] https://github.com/tgummerer/git/blob/pythonprototype/git-read-index-v5.py [4] https://github.com/tgummerer/git/tree/index-v5 [5] http://thread.gmane.org/gmane.comp.version-control.git/200997 -- To unsubscribe from this list: send the line "unsubscrib
Re: [PATCH v2 2/5] Use variables for the lists of tools that support merging / diffing
On 23.07.2012 20:37, Junio C Hamano wrote: This patch makes sense to me, but at the same time makes [PATCH 1/5] a "Meh", methinks. Yeah, I can see why. So I've renamed __git_mergetools_common to __git_diffmerge_tools and squashed with [PATCH 1/5] to make it less "Meh" as it does not stand on its own. As you append kcompare or tortoise _after_ the common list, any code that uses the variable cannot assume that the list is sorted, and needs to sort the elements if it wants to give a sorted output, so squashing does not make the Meh-ness go away. Well, that (mostly) sorted listed still helps to find out a little quicker whether a specific tool that can do both merging and diffing is already in the list. At least that's the case for me. By the way, would it make sense to remove these three variables from the completion code, and instead ask "git mergetool --tool-help" when it needs the list of supported tools for the first time? It would be trivial to introduce --tool-list that gives a one tool per line output to both "git difftool" and "git mergetool" and we would remove the risk of separately maintained list drifting away over time. Sounds like a good idea now that you've added "git mergetool --tool-help". But I'd like to save this for a future exercise to not do too much stuff at the same time. -- Sebastian Schuberth -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] mergetool: support --tool-help option like difftool does
This way we do not have to risk the list of tools go out of sync
between the implementation and the documentation. Adjust the documentation
accordingly to not explicitly list the tools but refer to --tool-help.
Signed-off-by: Junio C Hamano
Signed-off-by: Sebastian Schuberth
---
Documentation/git-difftool.txt | 7 ---
Documentation/git-mergetool.txt | 8
git-mergetool--lib.sh | 11 ++-
git-mergetool.sh| 42 -
4 files changed, 59 insertions(+), 9 deletions(-)
diff --git a/Documentation/git-difftool.txt b/Documentation/git-difftool.txt
index 31fc2e3..0bdfe35 100644
--- a/Documentation/git-difftool.txt
+++ b/Documentation/git-difftool.txt
@@ -36,9 +36,10 @@ OPTIONS
-t ::
--tool=::
- Use the diff tool specified by . Valid values include
- emerge, kompare, meld, and vimdiff. Run `git difftool --tool-help`
- for the list of valid settings.
+ Use the diff tool specified by .
+
+--tool-help::
+ List all supported values for .
+
If a diff tool is not specified, 'git difftool'
will use the configuration variable `diff.tool`. If the
diff --git a/Documentation/git-mergetool.txt b/Documentation/git-mergetool.txt
index 2a49de7..99e53b1 100644
--- a/Documentation/git-mergetool.txt
+++ b/Documentation/git-mergetool.txt
@@ -26,10 +26,10 @@ OPTIONS
---
-t ::
--tool=::
- Use the merge resolution program specified by .
- Valid merge tools are:
- araxis, bc3, diffuse, ecmerge, emerge, gvimdiff, kdiff3,
- meld, opendiff, p4merge, tkdiff, tortoisemerge, vimdiff and xxdiff.
+ Use the merge tool specified by .
+
+--tool-help::
+ List all supported values for .
+
If a merge resolution program is not specified, 'git mergetool'
will use the configuration variable `merge.tool`. If the
diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
index ed630b2..f0865d4 100644
--- a/git-mergetool--lib.sh
+++ b/git-mergetool--lib.sh
@@ -111,15 +111,18 @@ run_merge_tool () {
return $status
}
-guess_merge_tool () {
+list_merge_tool_candidates () {
+ # Add tools that can either do merging or diffing, but not both.
if merge_mode
then
tools="tortoisemerge"
else
tools="kompare"
fi
+
if test -n "$DISPLAY"
then
+ # Prefer GTK-based tools under Gnome.
if test -n "$GNOME_DESKTOP_SESSION_ID"
then
tools="meld opendiff kdiff3 tkdiff xxdiff $tools"
@@ -128,6 +131,8 @@ guess_merge_tool () {
fi
tools="$tools gvimdiff diffuse ecmerge p4merge araxis bc3"
fi
+
+ # Prefer vimdiff if vim is the default editor.
case "${VISUAL:-$EDITOR}" in
*vim*)
tools="$tools vimdiff emerge"
@@ -136,6 +141,10 @@ guess_merge_tool () {
tools="$tools emerge vimdiff"
;;
esac
+}
+
+guess_merge_tool () {
+ list_merge_tool_candidates
echo >&2 "merge tool candidates: $tools"
# Loop over each candidate and stop when a valid merge tool is found.
diff --git a/git-mergetool.sh b/git-mergetool.sh
index a9f23f7..0db0c44 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -8,7 +8,7 @@
# at the discretion of Junio C Hamano.
#
-USAGE='[--tool=tool] [-y|--no-prompt|--prompt] [file to merge] ...'
+USAGE='[--tool=tool] [--tool-help] [-y|--no-prompt|--prompt] [file to merge]
...'
SUBDIRECTORY_OK=Yes
OPTIONS_SPEC=
TOOL_MODE=merge
@@ -284,11 +284,51 @@ merge_file () {
return 0
}
+show_tool_help () {
+ TOOL_MODE=merge
+ list_merge_tool_candidates
+ unavailable= available= LF='
+'
+ for i in $tools
+ do
+ merge_tool_path=$(translate_merge_tool_path "$i")
+ if type "$merge_tool_path" >/dev/null 2>&1
+ then
+ available="$available$i$LF"
+ else
+ unavailable="$unavailable$i$LF"
+ fi
+ done
+ if test -n "$available"
+ then
+ echo "'git mergetool --tool=' may be set to one of the
following:"
+ echo "$available" | sort | sed -e 's/^/ /'
+ else
+ echo "No suitable tool for 'git mergetool --tool=' found."
+ fi
+ if test -n "$unavailable"
+ then
+ echo
+ echo 'The following tools are valid, but not currently
available:'
+ echo "$unavailable" | sort | sed -e 's/^/ /'
+ fi
+ if test -n "$unavailable$available"
+ then
+ echo
+ echo "Some of the tools listed above only work in a windowed"
+ echo "environment. If run in a terminal-only session, they will
fail."
+ fi
+ exit 0
+}
+
prompt=$(git config --bool mergetool.prompt || echo true)
while test $# != 0
do
ca
Re: mergetool: support --tool-help option like difftool does
On 23.07.2012 19:21, Junio C Hamano wrote: > This way we do not have to risk the list of tools go out of sync > between the implementation and the documentation. > > Signed-off-by: Junio C Hamano Thanks! I've squashed this with [PATCH v2 5/5] Add a few more code comments and blank lines in guess_merge_tool and parts of [PATCH 3/5] Explicitly list all valid diff tools and document --tool-help as an option and adjusted the docs for git-mergetool accordingly. -- Sebastian Schuberth -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] commit: give a hint when a commit message has been abandoned
If we launch an editor for the user to create a commit
message, they may put significant work into doing so.
Typically we try to check common mistakes that could cause
the commit to fail early, so that we die before the user
goes to the trouble.
We may still experience some errors afterwards, though; in
this case, the user is given no hint that their commit
message has been saved. Let's tell them where it is.
Signed-off-by: Jeff King
---
I did not bother protecting this with advice.* config, as it is unlikely
to come up regularly. If somebody cares, they are welcome to add it on
top.
builtin/commit.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/builtin/commit.c b/builtin/commit.c
index 20cef95..149e07d 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -116,6 +116,16 @@ static enum {
STATUS_FORMAT_PORCELAIN
} status_format = STATUS_FORMAT_LONG;
+static int mention_abandoned_message;
+static void maybe_mention_abandoned_message(void)
+{
+ if (!mention_abandoned_message)
+ return;
+ advise(_("Your commit message has been saved in '%s' and will be\n"
+"overwritten by the next invocation of \"git commit\"."),
+ git_path(commit_editmsg));
+}
+
static int opt_parse_m(const struct option *opt, const char *arg, int unset)
{
struct strbuf *buf = opt->value;
@@ -848,6 +858,8 @@ static int prepare_to_commit(const char *index_file, const
char *prefix,
_("Please supply the message using either -m or -F
option.\n"));
exit(1);
}
+ atexit(maybe_mention_abandoned_message);
+ mention_abandoned_message = 1;
}
if (!no_verify &&
@@ -1532,11 +1544,13 @@ int cmd_commit(int argc, const char **argv, const char
*prefix)
if (template_untouched(&sb) && !allow_empty_message) {
rollback_index_files();
fprintf(stderr, _("Aborting commit; you did not edit the
message.\n"));
+ mention_abandoned_message = 0;
exit(1);
}
if (message_is_empty(&sb) && !allow_empty_message) {
rollback_index_files();
fprintf(stderr, _("Aborting commit due to empty commit
message.\n"));
+ mention_abandoned_message = 0;
exit(1);
}
@@ -1579,6 +1593,7 @@ int cmd_commit(int argc, const char **argv, const char
*prefix)
die(_("cannot update HEAD ref"));
}
+ mention_abandoned_message = 0;
unlink(git_path("CHERRY_PICK_HEAD"));
unlink(git_path("REVERT_HEAD"));
unlink(git_path("MERGE_HEAD"));
--
1.7.10.5.40.g059818d
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] commit: check committer identity more strictly
The identity of the committer will ultimately be pulled from
the ident code by commit_tree(). However, we make an attempt
to check the author and committer identity early, before the
user has done any manual work like inputting a commit
message. That lets us abort without them having to worry
about salvaging the work from .git/COMMIT_EDITMSG.
The early check for committer ident does not use the
IDENT_STRICT flag, meaning that it would not find an empty
name field. The motivation was presumably because we did not
want to be too restrictive, as later calls might be more lax
(for example, when we create the reflog entry, we do not
care too much about a real name). However, because
commit_tree will always get a strict identity to put in the
commit object itself, there is no point in being lax only to
die later (and in fact it is harmful, because the user will
have wasted time typing their commit message).
Incidentally, this bug was masked prior to 060d4bb, as the
initial loose call would taint the later strict call. So the
commit would succeed (albeit with a bogus committer line in
the commit object), and nobody noticed that our early check
did not match the later one.
Signed-off-by: Jeff King
---
builtin/commit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index 95eeab1..20cef95 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -725,7 +725,7 @@ static int prepare_to_commit(const char *index_file, const
char *prefix,
strbuf_release(&sb);
/* This checks if committer ident is explicitly given */
- strbuf_addstr(&committer_ident, git_committer_info(0));
+ strbuf_addstr(&committer_ident, git_committer_info(IDENT_STRICT));
if (use_editor && include_status) {
char *ai_tmp, *ci_tmp;
if (whence != FROM_COMMIT)
--
1.7.10.5.40.g059818d
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] advice: pass varargs to strbuf_vaddf, not strbuf_addf
The advise() function takes a variable number of arguments
and converts them into a va_list object to pass to strbuf
for handling. However, we accidentally called strbuf_addf
(that takes a variable number of arguments) instead of
strbuf_vaddf (that takes a va_list).
This bug dates back to v1.7.8.1-1-g23cb5bf, but we never
noticed because none of the current callers passes a string
with a format specifier in it. And the compiler did not
notice because the format string is not available at
compile time.
Signed-off-by: Jeff King
---
advice.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/advice.c b/advice.c
index a492eea..edfbd4a 100644
--- a/advice.c
+++ b/advice.c
@@ -32,7 +32,7 @@ void advise(const char *advice, ...)
const char *cp, *np;
va_start(params, advice);
- strbuf_addf(&buf, advice, params);
+ strbuf_vaddf(&buf, advice, params);
va_end(params);
for (cp = buf.buf; *cp; cp = np) {
--
1.7.10.5.40.g059818d
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: empty ident name trashes commit message
On Mon, Jul 23, 2012 at 01:27:26PM -0400, Jeff King wrote: > On Sat, Jul 21, 2012 at 03:26:26PM +0100, Ramana Kumar wrote: > > > If I forget to set user.email and user.name config options and do a commit > > (possibly the --amend option also required to make this show up), then git > > 1.7.11.2 will drops me into an editor for a commit message, then after that > > complain with the fatal message: > > > >*** Please tell me who you are. > > [...] > > Hmm. I think this is an artifact of running --amend. In the normal case, > we check the author ident beforehand. But in the --amend case, we take > the existing author, but then fail trying to generate the committer > ident. So we could probably do better by checking both explicitly > beforehand. It seems we already had such a check, but it was not done correctly. This is fixed by patch 2 below. > > The commit message I wrote is now lost. This is bad behaviour - the error > > should happen before one writes the commit message, or the message should be > > saved somewhere. > > It's not lost. It's in .git/COMMIT_EDITMSG. > > We could probably do a better job of informing the user of this when > commit dies prematurely. And patch 3 improves this situation. [1/3]: advice: pass varargs to strbuf_vaddf, not strbuf_addf [2/3]: commit: check committer identity more strictly [3/3]: commit: give a hint when a commit message has been abandoned -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Cannot delete weirdly named branch
"abhisek...@gmail.com" writes: > Now I cannot delete this branch. Running: > git branch -d --tracking > gives an error: unknown option `tracking' I do not think this is supposed to work, but it does by accident. $ git branch -d -- --tracking Deleted branch --tracking (was 8670e20). A more recent git would not let you create such a branch to begin with. Perhaps time to upgrade? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/5] Use variables for the lists of tools that support merging / diffing
Sebastian Schuberth writes: >> This patch makes sense to me, but at the same time makes [PATCH 1/5] >> a "Meh", methinks. > > Yeah, I can see why. So I've renamed __git_mergetools_common to > __git_diffmerge_tools and squashed with [PATCH 1/5] to make it > less "Meh" as it does not stand on its own. As you append kcompare or tortoise _after_ the common list, any code that uses the variable cannot assume that the list is sorted, and needs to sort the elements if it wants to give a sorted output, so squashing does not make the Meh-ness go away. By the way, would it make sense to remove these three variables from the completion code, and instead ask "git mergetool --tool-help" when it needs the list of supported tools for the first time? It would be trivial to introduce --tool-list that gives a one tool per line output to both "git difftool" and "git mergetool" and we would remove the risk of separately maintained list drifting away over time. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Enhanced git branch list (proposal)
John Bartholomew writes:
> I find the output of `git branch' to be quite bare, and would like to
> see more information; most importantly, what the state of the branch
> is in relation to its upstream.
That is already present: just run git branch -vv.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Cannot delete weirdly named branch
Hi, I am a new user to git and I found an interesting behavior in git. I am not sure if this is a bug, but I thought I would report this anyway! So I can create a local branch called "--tracking" like this: git checkout -b --tracking origin/somebranch I messed up the syntax while trying to create a tracking branch, but this resulted in a local branch called "--tracking". Now I cannot delete this branch. Running: git branch -d --tracking gives an error: unknown option `tracking' Using quotes around the name does not help. Is there another command I can use to delete this branch? Thank you! -- Abhisek Live Long and Prosper -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] Use variables for the lists of tools that support merging / diffing
Also, add a few comments that clarify the meaning of these variables and
sort the list of tools alphabetically.
Signed-off-by: Sebastian Schuberth
---
contrib/completion/git-completion.bash | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 5be9dee..4a76120 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1325,17 +1325,24 @@ _git_diff ()
__git_complete_revlist_file
}
-__git_mergetools_common="diffuse ecmerge emerge kdiff3 meld opendiff
- tkdiff vimdiff gvimdiff xxdiff araxis p4merge bc3
+# Tools that support both merging and diffing.
+__git_diffmerge_tools="araxis bc3 diffuse ecmerge emerge gvimdiff
+ kdiff3 meld opendiff p4merge tkdiff vimdiff xxdiff
"
+# Tools that support diffing.
+__git_difftools="$__git_diffmerge_tools kcompare"
+
+# Tools that support merging.
+__git_mergetools="$__git_diffmerge_tools tortoisemerge"
+
_git_difftool ()
{
__git_has_doubledash && return
case "$cur" in
--tool=*)
- __gitcomp "$__git_mergetools_common kompare" ""
"${cur##--tool=}"
+ __gitcomp "$__git_difftools" "" "${cur##--tool=}"
return
;;
--*)
@@ -1623,7 +1630,7 @@ _git_mergetool ()
{
case "$cur" in
--tool=*)
- __gitcomp "$__git_mergetools_common tortoisemerge" ""
"${cur##--tool=}"
+ __gitcomp "$__git_mergetools" "" "${cur##--tool=}"
return
;;
--*)
--
1.7.11.msysgit.2
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/5] Use variables for the lists of tools that support merging / diffing
On 23.07.2012 18:46, Junio C Hamano wrote: >> +# Tools that support both merging and diffing. >> __git_mergetools_common="araxis bc3 diffuse ecmerge emerge gvimdiff >> kdiff3 meld opendiff p4merge tkdiff vimdiff xxdiff >> " > > As the set of merge capable tools is not a superset of diff capable > tools (tortoise can only merge but not diff), perhaps rename this to > __git_diffmerge_tools or something? Makes perfect sense. > This patch makes sense to me, but at the same time makes [PATCH 1/5] > a "Meh", methinks. Yeah, I can see why. So I've renamed __git_mergetools_common to __git_diffmerge_tools and squashed with [PATCH 1/5] to make it less "Meh" as it does not stand on its own. -- Sebastian -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Solve git-submodule issues with detached work trees
PPS: Yes, I know that I am replying in a patch thread. I will try it asap. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Solve git-submodule issues with detached work trees
On Mon, Jul 23, 2012 at 7:09 AM, Junio C Hamano wrote: > I think this is in line with what we discussed earlier on list when > the interaction between GIT_DIR/GIT_WORK_TREE and submodules came up > the last time. Jens? Yes, it is. I still have your email marked as TODO to get back to you as I am still unsure how to solve this whole mess in a way that works with vcsh[1]. Richard PS: Thanks for being so dedicated you all. I really do appreciate this more than you most likely suspect. [1] vcsh -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Solve git-submodule issues with detached work trees
On Mon, Jul 23, 2012 at 2:38 PM, Jens Lehmann wrote: > Am 23.07.2012 07:09, schrieb Junio C Hamano: >> Daniel Graña writes: >> >>> A common way to track dotfiles with git is using GIT_DIR and >>> GIT_WORK_TREE to move repository out of ~/.git with something like: >>> >>> git init --bare ~/.dotfiles >>> alias dotfiles="GIT_DIR=~/.dotfiles GIT_WORK_TREE=~ git" >>> >>> dotfiles add ~/.bashrc >>> dotfiles commit -a -m "add my bashrc" >>> ... >>> >>> but git-submodule complains when trying to add submodules: >>> >>> dotfiles submodule add http://path.to/submodule >>> fatal: working tree '/home/user' already exists. >>> >>> git --git-dir ~/.dotfiles submodule add http://path.to/submodule >>> fatal: /usr/lib/git-core/git-submodule cannot be used without a >>> working tree. >>> >>> Signed-off-by: Daniel Graña >>> --- >> >> I think this is in line with what we discussed earlier on list when >> the interaction between GIT_DIR/GIT_WORK_TREE and submodules came up >> the last time. Jens? > > Yes, I think this is the only way submodules in current git can > be used with the GIT_DIR and GIT_WORK_TREE environment variables: > set them when adding or initializing the submodule and always use > the same settings when accessing them later. Daniel's dotfile > alias achieves exactly that, so his fix looks good. But I agree > the tests should be improved as you already pointed out. Hi Jens, Junio. Thanks for reviewing the patch, glad to hear this is acceptable way to fix my itch. I will work soon on getting the test cases improved and the patch submitted without line wrapping. thanks again, Daniel. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Solve git-submodule issues with detached work trees
Jens Lehmann writes: > Am 23.07.2012 07:09, schrieb Junio C Hamano: >> Daniel Graña writes: >> >>> A common way to track dotfiles with git is using GIT_DIR and >>> GIT_WORK_TREE to move repository out of ~/.git with something like: >>> >>> git init --bare ~/.dotfiles >>> alias dotfiles="GIT_DIR=~/.dotfiles GIT_WORK_TREE=~ git" >>> >>> dotfiles add ~/.bashrc >>> dotfiles commit -a -m "add my bashrc" >>> ... >>> >>> but git-submodule complains when trying to add submodules: >>> >>> dotfiles submodule add http://path.to/submodule >>> fatal: working tree '/home/user' already exists. >>> >>> git --git-dir ~/.dotfiles submodule add http://path.to/submodule >>> fatal: /usr/lib/git-core/git-submodule cannot be used without a >>> working tree. >>> >>> Signed-off-by: Daniel Graña >>> --- >> >> I think this is in line with what we discussed earlier on list when >> the interaction between GIT_DIR/GIT_WORK_TREE and submodules came up >> the last time. Jens? > > Yes, I think this is the only way submodules in current git can > be used with the GIT_DIR and GIT_WORK_TREE environment variables: > set them when adding or initializing the submodule and always use > the same settings when accessing them later. Daniel's dotfile > alias achieves exactly that, so his fix looks good. But I agree > the tests should be improved as you already pointed out. Thanks for a quick review. The "the only way ... in current git can be used" part makes it sound as if it is a somewhat suboptimal ugly workaround, but if that is what you meant, what is a more optimal and less ugly way that you have in mind? If you want to move .git out of way with GIT_DIR and if you want to sit somewhere different from the top of your working tree, you must use GIT_WORK_TREE (or core.worktree) to tell where the top resides, whether your project use submodules or not, so I do not think it is an ugly workaround but is the one true way to use such a dismembered layout, I would think. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Enhanced git branch list (proposal)
I find the output of `git branch' to be quite bare, and would like to
see more information; most importantly, what the state of the branch
is in relation to its upstream. For some time I have been using my
own script to do this. It produces output like this:
$ git lsb
commodity-market-lua [behind 'brianetta/commodity-market-lua' by 2
commits]
filesystem [up-to-date with 'jpab/filesystem']
fix-ring-blending [ahead of 'jpab/fix-ring-blending' by 1 commit]
galaxy-refactor
galaxy-refactor-2 [diverged from 'jpab/galaxy-refactor', by 6
commits/626 commits (us/them)]
hud-pitch-ladder [up-to-date with 'jpab/hud-pitch-ladder']
= issue-1388
issue-695
lmr-mtllib-improvements
marcel-stations
* master [up-to-date with 'jpab/master']
refcounted-body [up-to-date with 'jpab/refcounted-body']
string-formatter [up-to-date with 'jpab/string-formatter']
The first column indicates the relation to HEAD: '*' marks the current
head, '=' marks a branch which is identical with the current HEAD.
Branches which have a configured upstream (branch.remote and
branch.merge are set) show the relation to the corresponding remote
branch.
Some key text ('up-to-date', 'ahead', 'behind' or 'diverged', and the
name of the current HEAD) is displayed with colour if colour is
enabled.
Arguments can be passed to show remote branches (for all remotes, or
for a specified remote), or all branches, and to show each branch
in relation to a specified target branch instead of the configured
remote tracking branch.
I would like to know whether there is any interest in incorporating
this functionality into the main git distribution, either as a
separate command, or within `git branch'. For my purposes I have it
aliased under the name `git lsb' for `list branches'.
You can examine the script I'm using for this at:
https://github.com/johnbartholomew/gitvoodoo/blob/master/bin/git-xbranch
Regards,
John B
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: empty ident name trashes commit message
On Mon, Jul 23, 2012 at 6:27 PM, Jeff King wrote: > On Sat, Jul 21, 2012 at 03:26:26PM +0100, Ramana Kumar wrote: > >> If I forget to set user.email and user.name config options and do a commit >> (possibly the --amend option also required to make this show up), then git >> 1.7.11.2 will drops me into an editor for a commit message, then after that >> complain with the fatal message: >> >>*** Please tell me who you are. >> [...] > > Hmm. I think this is an artifact of running --amend. In the normal case, > we check the author ident beforehand. But in the --amend case, we take > the existing author, but then fail trying to generate the committer > ident. So we could probably do better by checking both explicitly > beforehand. Indeed. > Usually we would fall back to your name from /etc/passwd. I guess it is > blank on your system. > >> The commit message I wrote is now lost. [...] > > It's not lost. It's in .git/COMMIT_EDITMSG. > > We could probably do a better job of informing the user of this when > commit dies prematurely. > > -Peff I agree, and thank you very much for those two useful pieces of information! (names stored in /etc/passwd and saving of .git/COMMIT_EDITMSG). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Solve git-submodule issues with detached work trees
Am 23.07.2012 07:09, schrieb Junio C Hamano: > Daniel Graña writes: > >> A common way to track dotfiles with git is using GIT_DIR and >> GIT_WORK_TREE to move repository out of ~/.git with something like: >> >> git init --bare ~/.dotfiles >> alias dotfiles="GIT_DIR=~/.dotfiles GIT_WORK_TREE=~ git" >> >> dotfiles add ~/.bashrc >> dotfiles commit -a -m "add my bashrc" >> ... >> >> but git-submodule complains when trying to add submodules: >> >> dotfiles submodule add http://path.to/submodule >> fatal: working tree '/home/user' already exists. >> >> git --git-dir ~/.dotfiles submodule add http://path.to/submodule >> fatal: /usr/lib/git-core/git-submodule cannot be used without a >> working tree. >> >> Signed-off-by: Daniel Graña >> --- > > I think this is in line with what we discussed earlier on list when > the interaction between GIT_DIR/GIT_WORK_TREE and submodules came up > the last time. Jens? Yes, I think this is the only way submodules in current git can be used with the GIT_DIR and GIT_WORK_TREE environment variables: set them when adding or initializing the submodule and always use the same settings when accessing them later. Daniel's dotfile alias achieves exactly that, so his fix looks good. But I agree the tests should be improved as you already pointed out. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: empty ident name trashes commit message
On Sat, Jul 21, 2012 at 03:26:26PM +0100, Ramana Kumar wrote: > If I forget to set user.email and user.name config options and do a commit > (possibly the --amend option also required to make this show up), then git > 1.7.11.2 will drops me into an editor for a commit message, then after that > complain with the fatal message: > >*** Please tell me who you are. > [...] Hmm. I think this is an artifact of running --amend. In the normal case, we check the author ident beforehand. But in the --amend case, we take the existing author, but then fail trying to generate the committer ident. So we could probably do better by checking both explicitly beforehand. >fatal: empty ident name (for ) not allowed Usually we would fall back to your name from /etc/passwd. I guess it is blank on your system. > The commit message I wrote is now lost. This is bad behaviour - the error > should happen before one writes the commit message, or the message should be > saved somewhere. It's not lost. It's in .git/COMMIT_EDITMSG. We could probably do a better job of informing the user of this when commit dies prematurely. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
mergetool: support --tool-help option like difftool does
This way we do not have to risk the list of tools go out of sync
between the implementation and the documentation.
Signed-off-by: Junio C Hamano
---
Junio C Hamano writes:
>> +--tool-help::
>> +List the supported and available diff tools.
>
> This part is a good addition (but it already is mentioned in the
> description of --tool above, so it is more or less a "Meh").
I noticed that the main while loop has style violations in its
case/esac, but I left it as-is. Reindenting it would be a low
hanging fruit janitor patch that would be a separate topic.
git-mergetool--lib.sh | 6 +-
git-mergetool.sh | 42 +-
2 files changed, 46 insertions(+), 2 deletions(-)
diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
index ed630b2..f730253 100644
--- a/git-mergetool--lib.sh
+++ b/git-mergetool--lib.sh
@@ -111,7 +111,7 @@ run_merge_tool () {
return $status
}
-guess_merge_tool () {
+list_merge_tool_candidates () {
if merge_mode
then
tools="tortoisemerge"
@@ -136,6 +136,10 @@ guess_merge_tool () {
tools="$tools emerge vimdiff"
;;
esac
+}
+
+guess_merge_tool () {
+ list_merge_tool_candidates
echo >&2 "merge tool candidates: $tools"
# Loop over each candidate and stop when a valid merge tool is found.
diff --git a/git-mergetool.sh b/git-mergetool.sh
index a9f23f7..0db0c44 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -8,7 +8,7 @@
# at the discretion of Junio C Hamano.
#
-USAGE='[--tool=tool] [-y|--no-prompt|--prompt] [file to merge] ...'
+USAGE='[--tool=tool] [--tool-help] [-y|--no-prompt|--prompt] [file to merge]
...'
SUBDIRECTORY_OK=Yes
OPTIONS_SPEC=
TOOL_MODE=merge
@@ -284,11 +284,51 @@ merge_file () {
return 0
}
+show_tool_help () {
+ TOOL_MODE=merge
+ list_merge_tool_candidates
+ unavailable= available= LF='
+'
+ for i in $tools
+ do
+ merge_tool_path=$(translate_merge_tool_path "$i")
+ if type "$merge_tool_path" >/dev/null 2>&1
+ then
+ available="$available$i$LF"
+ else
+ unavailable="$unavailable$i$LF"
+ fi
+ done
+ if test -n "$available"
+ then
+ echo "'git mergetool --tool=' may be set to one of the
following:"
+ echo "$available" | sort | sed -e 's/^/ /'
+ else
+ echo "No suitable tool for 'git mergetool --tool=' found."
+ fi
+ if test -n "$unavailable"
+ then
+ echo
+ echo 'The following tools are valid, but not currently
available:'
+ echo "$unavailable" | sort | sed -e 's/^/ /'
+ fi
+ if test -n "$unavailable$available"
+ then
+ echo
+ echo "Some of the tools listed above only work in a windowed"
+ echo "environment. If run in a terminal-only session, they will
fail."
+ fi
+ exit 0
+}
+
prompt=$(git config --bool mergetool.prompt || echo true)
while test $# != 0
do
case "$1" in
+ --tool-help)
+ show_tool_help
+ ;;
-t|--tool*)
case "$#,$1" in
*,*=*)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/5] Make sure to use Araxis' "compare" and not e.g. ImageMagick's
Sebastian Schuberth writes:
> Signed-off-by: Sebastian Schuberth
> ---
> mergetools/araxis | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/mergetools/araxis b/mergetools/araxis
> index 64f97c5..aeba1b9 100644
> --- a/mergetools/araxis
> +++ b/mergetools/araxis
> @@ -16,5 +16,11 @@ merge_cmd () {
> }
>
> translate_merge_tool_path() {
> - echo compare
> + # Make sure to use Araxis' "compare" and not e.g. ImageMagick's.
> + if ls "$(dirname "$(which compare)")"/Araxis* >/dev/null 2>&1
Use of "which" in scripts that are meant to be portable is a no-no.
Some platforms would say "compare is /usr/local/bin/compare" instead
of saying "/usr/local/bin/compare".
> + then
> + echo compare
> + else
> + echo "$1"
> + fi
> }
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] Explicitly list all valid diff tools and document --tool-help as an option
Sebastian Schuberth writes: > Signed-off-by: Sebastian Schuberth > --- > Documentation/git-difftool.txt | 9 ++--- > 1 file changed, 6 insertions(+), 3 deletions(-) > > diff --git a/Documentation/git-difftool.txt b/Documentation/git-difftool.txt > index 31fc2e3..5dd54f1 100644 > --- a/Documentation/git-difftool.txt > +++ b/Documentation/git-difftool.txt > @@ -36,9 +36,12 @@ OPTIONS > > -t :: > --tool=:: > - Use the diff tool specified by . Valid values include > - emerge, kompare, meld, and vimdiff. Run `git difftool --tool-help` > - for the list of valid settings. I thought we say "include" because we really do not want to list millions of tools here, so mild NAK on this part. > + Use the diff tool specified by . Valid diff tools are: > + araxis, bc3, diffuse, ecmerge, emerge, gvimdiff, kcompare, kdiff3, > + meld, opendiff, p4merge, tkdiff, vimdiff and xxdiff. > + > +--tool-help:: > + List the supported and available diff tools. This part is a good addition (but it already is mentioned in the description of --tool above, so it is more or less a "Meh"). > + > If a diff tool is not specified, 'git difftool' > will use the configuration variable `diff.tool`. If the -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/5] Use variables for the lists of tools that support merging / diffing
Sebastian Schuberth writes:
> Also, add a few comments that clarify the meaning of these variables.
>
> Signed-off-by: Sebastian Schuberth
> ---
> contrib/completion/git-completion.bash | 11 +--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/contrib/completion/git-completion.bash
> b/contrib/completion/git-completion.bash
> index f2c4894..6b9b79d 100755
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -1325,17 +1325,24 @@ _git_diff ()
> __git_complete_revlist_file
> }
>
> +# Tools that support both merging and diffing.
> __git_mergetools_common="araxis bc3 diffuse ecmerge emerge gvimdiff
> kdiff3 meld opendiff p4merge tkdiff vimdiff xxdiff
> "
As the set of merge capable tools is not a superset of diff capable
tools (tortoise can only merge but not diff), perhaps rename this to
__git_diffmerge_tools or something?
> +# Tools that support diffing.
> +__git_difftools="$__git_mergetools_common kcompare"
> +
> +# Tools that support merging.
> +__git_mergetools="$__git_mergetools_common tortoisemerge"
> +
This patch makes sense to me, but at the same time makes [PATCH 1/5]
a "Meh", methinks.
> _git_difftool ()
> {
> __git_has_doubledash && return
>
> case "$cur" in
> --tool=*)
> - __gitcomp "$__git_mergetools_common kompare" ""
> "${cur##--tool=}"
> + __gitcomp "$__git_difftools" "" "${cur##--tool=}"
> return
> ;;
> --*)
> @@ -1623,7 +1630,7 @@ _git_mergetool ()
> {
> case "$cur" in
> --tool=*)
> - __gitcomp "$__git_mergetools_common tortoisemerge" ""
> "${cur##--tool=}"
> + __gitcomp "$__git_mergetools" "" "${cur##--tool=}"
> return
> ;;
> --*)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 4/5] difftool: Use symlinks when diffing against the worktree
David Aguilar writes: > Teach difftool's --dir-diff mode to use symlinks to represent > files from the working copy, and make it the default behavior > for the non-Windows platforms. > > Using symlinks is simpler and safer since we do not need to > worry about copying files back into the worktree. > The old behavior is still available as --no-symlinks. > > Signed-off-by: David Aguilar > --- > Handles the case where an editor unlinks the original symlink, > replacing it with a file. Thanks; will replace. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add a svnrdump-simulator replaying a dump file for testing.
Florian Achleitner writes: > I had to fix the missing sign-off anyways.. > > contrib/svn-fe/svnrdump_sim.py | 53 > You also have whitespace damages (i.e. line wrapping introduced by your mailer). Using git-send-email avoids this kind of problem (there are also some advices for some mailers in Documentation/SubmittingPatches). -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add a svnrdump-simulator replaying a dump file for testing.
Florian Achleitner writes: > It requires the remote url to start with sim://. > Start and end revisions are evaluated. It is a bit unclear where "start" and "end" comes from, and if "evaluated" is the most important aspect of the handling of these two values. Do you mean the tool takes start and end revisions as arguments? If so, describe "how". E.g. as two arguments (-rSTART -rEND)? As an argument that shows a range (-rSTART-END? -rSTART,END)? Do not answer with "It is in the code" (I cheated and peeked to find out it is -rSTART:END, but the reader should not have to peek). > If the requested revision doesn't exist, as it is the case with > incremental imports, if no new commit was added, it returns 1 > (like svnrdump). This sentence does not parse for me. What is it trying to say? Requested revision does not exist _where_? It is unclear how "incremental import" and "revision doesn't exist" are related. "no new commit was added" to _what_ by _whom_? I presume that nobody is adding new commit _to_ an existing dump file, and the only thing this script does is to read and selectively write part of a dump file, so that would not add any new commit either. Puzzled. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add a svnrdump-simulator replaying a dump file for testing.
To ease testing without depending on a reachable svn server, this
compact python script mimics parts of svnrdumps behaviour.
It requires the remote url to start with sim://.
Start and end revisions are evaluated.
If the requested revision doesn't exist, as it is the case with
incremental imports, if no new commit was added, it returns 1
(like svnrdump).
To allow using the same dump file for simulating multiple
incremental imports the highest revision can be limited by setting
the environment variable SVNRMAX to that value. This simulates the
situation where higher revs don't exist yet.
Signed-off-by: Florian Achleitner
---
I had to fix the missing sign-off anyways..
contrib/svn-fe/svnrdump_sim.py | 53
1 file changed, 53 insertions(+)
create mode 100755 contrib/svn-fe/svnrdump_sim.py
diff --git a/contrib/svn-fe/svnrdump_sim.py b/contrib/svn-fe/svnrdump_sim.py
new file mode 100755
index 000..4701d76
--- /dev/null
+++ b/contrib/svn-fe/svnrdump_sim.py
@@ -0,0 +1,53 @@
+#!/usr/bin/python
+"""
+Simulates svnrdump by replaying an existing dump from a file, taking care
+of the specified revision range.
+To simulate incremental imports the environment variable SVNRMAX can be set
+to the highest revision that should be available.
+"""
+import sys, os
+
+
+def getrevlimit():
+ var = 'SVNRMAX'
+ if os.environ.has_key(var):
+ return os.environ[var]
+ return None
+
+def writedump(url, lower, upper):
+ if url.startswith('sim://'):
+ filename = url[6:]
+ if filename[-1] == '/': filename = filename[:-1] #remove
terminating slash
+ else:
+ raise ValueError('sim:// url required')
+ f = open(filename, 'r');
+ state = 'header'
+ wroterev = False
+ while(True):
+ l = f.readline()
+ if l == '': break
+ if state == 'header' and l.startswith('Revision-number: '):
+ state = 'prefix'
+ if state == 'prefix' and l == 'Revision-number: %s\n' % lower:
+ state = 'selection'
+ if not upper == 'HEAD' and state == 'selection' and l ==
'Revision-
number: %s\n' % upper:
+ break;
+
+ if state == 'header' or state == 'selection':
+ if state == 'selection': wroterev = True
+ sys.stdout.write(l)
+ return wroterev
+
+if __name__ == "__main__":
+ if not (len(sys.argv) in (3, 4, 5)):
+ print "usage: %s dump URL -rLOWER:UPPER"
+ sys.exit(1)
+ if not sys.argv[1] == 'dump': raise NotImplementedError('only "dump" is
suppported.')
+ url = sys.argv[2]
+ r = ('0', 'HEAD')
+ if len(sys.argv) == 4 and sys.argv[3][0:2] == '-r':
+ r = sys.argv[3][2:].lstrip().split(':')
+ if not getrevlimit() is None: r[1] = getrevlimit()
+ if writedump(url, r[0], r[1]): ret = 0
+ else: ret = 1
+ sys.exit(ret)
\ No newline at end of file
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add a svnrdump-simulator replaying a dump file for testing.
On Monday 23 July 2012 07:59:21 Jonathan Nieder wrote: > Florian Achleitner wrote: > > To ease testing without depending on a reachable svn server, this > > compact python script mimics parts of svnrdumps behaviour. > > Thanks. Mind if I forge your sign-off? Ups. No problem, anyways I've added it locally, so here's the new version .. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add a svnrdump-simulator replaying a dump file for testing.
Florian Achleitner wrote: > To ease testing without depending on a reachable svn server, this > compact python script mimics parts of svnrdumps behaviour. Thanks. Mind if I forge your sign-off? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Add a svnrdump-simulator replaying a dump file for testing.
To ease testing without depending on a reachable svn server, this
compact python script mimics parts of svnrdumps behaviour.
It requires the remote url to start with sim://.
Start and end revisions are evaluated.
If the requested revision doesn't exist, as it is the case with
incremental imports, if no new commit was added, it returns 1
(like svnrdump).
To allow using the same dump file for simulating multiple
incremental imports the highest revision can be limited by setting
the environment variable SVNRMAX to that value. This simulates the
situation where higher revs don't exist yet.
---
contrib/svn-fe/svnrdump_sim.py | 53
1 file changed, 53 insertions(+)
create mode 100755 contrib/svn-fe/svnrdump_sim.py
diff --git a/contrib/svn-fe/svnrdump_sim.py b/contrib/svn-fe/svnrdump_sim.py
new file mode 100755
index 000..4701d76
--- /dev/null
+++ b/contrib/svn-fe/svnrdump_sim.py
@@ -0,0 +1,53 @@
+#!/usr/bin/python
+"""
+Simulates svnrdump by replaying an existing dump from a file, taking care
+of the specified revision range.
+To simulate incremental imports the environment variable SVNRMAX can be set
+to the highest revision that should be available.
+"""
+import sys, os
+
+
+def getrevlimit():
+ var = 'SVNRMAX'
+ if os.environ.has_key(var):
+ return os.environ[var]
+ return None
+
+def writedump(url, lower, upper):
+ if url.startswith('sim://'):
+ filename = url[6:]
+ if filename[-1] == '/': filename = filename[:-1] #remove
terminating slash
+ else:
+ raise ValueError('sim:// url required')
+ f = open(filename, 'r');
+ state = 'header'
+ wroterev = False
+ while(True):
+ l = f.readline()
+ if l == '': break
+ if state == 'header' and l.startswith('Revision-number: '):
+ state = 'prefix'
+ if state == 'prefix' and l == 'Revision-number: %s\n' % lower:
+ state = 'selection'
+ if not upper == 'HEAD' and state == 'selection' and l ==
'Revision-number: %s\n' % upper:
+ break;
+
+ if state == 'header' or state == 'selection':
+ if state == 'selection': wroterev = True
+ sys.stdout.write(l)
+ return wroterev
+
+if __name__ == "__main__":
+ if not (len(sys.argv) in (3, 4, 5)):
+ print "usage: %s dump URL -rLOWER:UPPER"
+ sys.exit(1)
+ if not sys.argv[1] == 'dump': raise NotImplementedError('only "dump" is
suppported.')
+ url = sys.argv[2]
+ r = ('0', 'HEAD')
+ if len(sys.argv) == 4 and sys.argv[3][0:2] == '-r':
+ r = sys.argv[3][2:].lstrip().split(':')
+ if not getrevlimit() is None: r[1] = getrevlimit()
+ if writedump(url, r[0], r[1]): ret = 0
+ else: ret = 1
+ sys.exit(ret)
\ No newline at end of file
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GSOC remote-svn
Florian Achleitner wrote: > But when I fetch from a git repo that imported from svn, the notes are not > fetched automatically. In this case I currently loose marks and notes. > What can I do? In the long term, git will need to be tweaked to automatically fetch notes along with branches by default. There are other reasons not related to remote helpers to want this, too. In the short term, we can document which ref the notes are expected to be fetched to. Maybe someone interested would provide commands like "git remote-testsvn --clone " and "git remote-testsvn --add-remote " as a stopgap to set up the appropriate fetch refspec automatically so the user doesn't have to worry about it. Thanks, Jonathan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GSOC remote-svn
Matthieu Moy wrote: > The man page for git-remote-helpers says: > > refspec > [...] It is recommended that all importers providing the import > capability use this. > > I'm not sure I fully understand the rationale, but one difference > between refs//* and refs/remotes/ is that > refs/remotes/ is automatically updated by Git on push, while the private > namespace isn't (it only receives updates when importing). It's mostly to allow "git fetch" to avoid non fast-forward updates unless -f was used or the refspec starts with +. I always liked the idea of tweaking the fast-import stream format to allow the import to happen on no branch at all since it would avoid all these questions. Maybe another day. Thanks, Jonathan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GSOC remote-svn
On Sunday 22 July 2012 23:03:27 Florian Achleitner wrote: > This got stuck on another problem: > Incremental update of the note tree doesn't work. fast-import refuses to > update the notes tree: ' doesn't contain '. > I don't yet know what's the reason for this. > I'm digging into the internals of notes to find out why.. > (no problem with the file tree). btw, this one was rather simple, just a syntax error in the fast-import stream.. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GSOC remote-svn
On Sunday 22 July 2012 16:43:33 Jonathan Nieder wrote: > Hi, > > Florian Achleitner wrote: > > After several mailing iterations, showing me that I was wrong, I found > > what > > the right point is, namely that the remote helper writes references to a > > really private dir in refs//, it doesn't touch anything else, > > and by advertising the 'refspec' capability, git-fetch knows where the > > private refs are and updates non-private references according to the > > fetch refspec in some post-processing in store_updated_refs. > > Right, that's fine. And you did a fine job of navigating the existing > documentation (which could be improved, hint hint). > > What I am more concerned about is that you had code you sent a while > ago for review, that this would have been obvious to David, Ram, > Dmitry, or me if we had seen it, and yet none of us gave you that > help. We are failing at _our_ job of giving you prompt advice and > instead you have had to work on your own. > > Isn't it likely that there are multiple other bugs like that which > still haven't been fixed? > > That's why I think we need to get into a habit of giving and getting > feedback quickly and incrementally improving work. Soon, before the > summer ends. > > [...] > > >> [23:01:10] and it should not be named remote-svn, since we > > > > haven't pinned down details about the svn:: conversion yet. That's why > > Dmitry's was called git-remote-svn-alpha) > > > > Ok. Why is that important? I think if it's not called remote-svn git > > doesn't fid it as a helper for the 'svn' protocol. > > It finds it as a helper for the 'svn-alpha' protocol instead. > > The point is that when I perform the following steps: > > git clone svn://path/to/remote/repo > > ... wait a day, update git > > cd repo > git pull > > nobody would expect the result to be a non-fast-forward update caused > by the details of svn-to-git conversion changing. Using a name like > testsvn or svn-alpha would help in managing expectations --- the > remote helper is meant for experimentation for now and not meant to be > something people can rely on for collaboration. Ok, that makes sense. Renaming is easily done! > > > I wrote a small simulation script in python that mimics svnrdumps > > behaviour by replaying an existing svn dump file from a start rev up to > > an end rev to test incremental imports. I use it together with a little > > testrepo shell script. Will need to bring that into t/ later, after > > figuring out how the test framework works. As it's not finished it's not > > published. > > Sounds neat --- how can one try it out? I'll send a patch ... > > > Incremental import: > > By reading the latest svn revision number from a note attached to the > > private master ref, it starts future imports from the next svn revision. > > That basically works well. > > It doesn't reuse mark files. What's the point of reusing them? Dmitry's > > svn- alpha did that. > > All I need to know is the revision to start from and the branch i want to > > add commits to, right? It now simply reads that from the note. > > The marks are used to handle copyfrom operations referring to older > revisions. Are you sure you want to abandon them? Can you explain a > little more about your plan? Ok, that makes sense. I didn't need the marks for incremental import. But to evaluate the copyfrom props we need some revision->sha1 mapping. I just added the options to save and import marks to fast-import's command line. If the file is missing, it will need to be generated from the notes, or the whole history will be reimported. But when I fetch from a git repo that imported from svn, the notes are not fetched automatically. In this case I currently loose marks and notes. What can I do? Florian -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Egit is not included into eclipse bundles
Hello, Egit is not a part of git. It's not developed by the git developers, so this question is not really fit for this mailing list. You'd have to ask the Eclipse developers why it's not included. Ikke On Fri, Jul 20, 2012 at 11:51 PM, Eugene Sajine wrote: > > Hi, > > I have a strong impression that Egit was supposed to be included into > the default eclipse distribution starting from Eclipse Helios. May be > it was my wild dream that I would like to become true, but I would > appreciate any info about why I still can't see it in Juno? > > Thanks, > Eugene > -- > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/7] i18n for git-am, git-rebase and git-merge
2012/7/23 Nguyen Thai Ngoc Duy : > On Mon, Jul 23, 2012 at 2:32 PM, Jiang Xin wrote: >> If build git with GETTEXT_POISON and test, lots of test cases failed. >> It seems that we haven't run these test cases for i18n for a long time. > > Gaah.. I should have resent the poison-fix series but so far > procrastination is winning. Will do it soon. So, I will just try to fix what I am responsible for. -- Jiang Xin -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GSOC remote-svn
Florian Achleitner writes: > But my remote-helper didn't advertise the refspec capability, so transport- > helper assumed it imports to refs/heads/master, which is the default import > refspec. The man page for git-remote-helpers says: refspec [...] It is recommended that all importers providing the import capability use this. I'm not sure I fully understand the rationale, but one difference between refs//* and refs/remotes/ is that refs/remotes/ is automatically updated by Git on push, while the private namespace isn't (it only receives updates when importing). I played a bit with that it git-remote-mediawiki. There's a configuration variable mediawiki.dumbPush that controls what "push" does. It can either export the local history without touching local metadata (and then, it is expected that the user does a "git pull --rebase" right after to re-import the history), or update the local metadata (private ref, and notes that keep the <-> map), so that the next "git pull" says "Already up to date.". -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] git-remote-mediawiki: allow page names with a ':'
Dan Johnson writes: > On Tue, Jul 17, 2012 at 10:06 AM, Matthieu Moy wrote: >> Traditionnally, pages named Foo:Bar are page 'Bar' in namespace 'Foo'. >> However, it is also possible to call a page Foo:Bar if 'Foo' is not a >> namespace. In this case, the actual name of the page is 'Foo:Bar', in the >> main namespace. Since we can't tell with only the filename, query the >> wiki for a namespace 'Foo' in these cases, but deal with the case where >> no such namespace is found. > > Might not be worth fixing, and it's just a typo in the commit message, but: > s/Traditionnally/Traditionally/ > ? Thanks, but the topic is in next already, so it's too late to fix the commit message. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] Explicitly list all valid diff tools and document --tool-help as an option
Signed-off-by: Sebastian Schuberth --- Documentation/git-difftool.txt | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/Documentation/git-difftool.txt b/Documentation/git-difftool.txt index 31fc2e3..5dd54f1 100644 --- a/Documentation/git-difftool.txt +++ b/Documentation/git-difftool.txt @@ -36,9 +36,12 @@ OPTIONS -t :: --tool=:: - Use the diff tool specified by . Valid values include - emerge, kompare, meld, and vimdiff. Run `git difftool --tool-help` - for the list of valid settings. + Use the diff tool specified by . Valid diff tools are: + araxis, bc3, diffuse, ecmerge, emerge, gvimdiff, kcompare, kdiff3, + meld, opendiff, p4merge, tkdiff, vimdiff and xxdiff. + +--tool-help:: + List the supported and available diff tools. + If a diff tool is not specified, 'git difftool' will use the configuration variable `diff.tool`. If the -- 1.7.11.msysgit.2 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/7] i18n for git-am, git-rebase and git-merge
On Mon, Jul 23, 2012 at 2:32 PM, Jiang Xin wrote: > If build git with GETTEXT_POISON and test, lots of test cases failed. > It seems that we haven't run these test cases for i18n for a long time. Gaah.. I should have resent the poison-fix series but so far procrastination is winning. Will do it soon. -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 5/5] Add a few more code comments and blank lines in guess_merge_tool
Signed-off-by: Sebastian Schuberth
---
git-mergetool--lib.sh | 6 ++
1 file changed, 6 insertions(+)
diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
index ed630b2..ac9a8f0 100644
--- a/git-mergetool--lib.sh
+++ b/git-mergetool--lib.sh
@@ -112,14 +112,17 @@ run_merge_tool () {
}
guess_merge_tool () {
+ # Add tools that can either do merging or diffing, but not both.
if merge_mode
then
tools="tortoisemerge"
else
tools="kompare"
fi
+
if test -n "$DISPLAY"
then
+ # Prefer GTK-based tools under Gnome.
if test -n "$GNOME_DESKTOP_SESSION_ID"
then
tools="meld opendiff kdiff3 tkdiff xxdiff $tools"
@@ -128,6 +131,8 @@ guess_merge_tool () {
fi
tools="$tools gvimdiff diffuse ecmerge p4merge araxis bc3"
fi
+
+ # Prefer vimdiff if vim is the default editor.
case "${VISUAL:-$EDITOR}" in
*vim*)
tools="$tools vimdiff emerge"
@@ -136,6 +141,7 @@ guess_merge_tool () {
tools="$tools emerge vimdiff"
;;
esac
+
echo >&2 "merge tool candidates: $tools"
# Loop over each candidate and stop when a valid merge tool is found.
--
1.7.11.msysgit.2
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/7] i18n for git-am, git-rebase and git-merge
2012/7/23 Junio C Hamano : >> I find one test case failed, and correct it in PATCH 3/7. > > That test used i18ncmp already, so the update to expected string > would be sufficient. I was worried if there were existing tests > that have been expecting that the output from am/rebase/merge would > not be i18n'ised and using "test_cmp expect actual" to compare their > output with expected result. If build git with GETTEXT_POISON and test, lots of test cases failed. It seems that we haven't run these test cases for i18n for a long time. test of t0006-date.sh failed, because of i18n in commit 7d29af. 7d29a i18n: mark relative dates for translation test of t0040-parse-options.sh failed, because of i18n in commit 54e6dc7: 54e6d i18n: parseopt: lookup help and argument translations when showing usage I will try to fix them in next version of the patches. Test Summary Report --- ./t0006-date.sh(Wstat: 256 Tests: 45 Failed: 11) Failed tests: 1-11 Non-zero exit status: 1 ./t0050-filesystem.sh (Wstat: 0 Tests: 10 Failed: 0) TODO passed: 6 ./t0040-parse-options.sh (Wstat: 256 Tests: 36 Failed: 4) Failed tests: 1, 11-12, 27 Non-zero exit status: 1 ./t1502-rev-parse-parseopt.sh (Wstat: 256 Tests: 8 Failed: 1) Failed test: 1 Non-zero exit status: 1 ./t1450-fsck.sh(Wstat: 256 Tests: 16 Failed: 1) Failed test: 13 Non-zero exit status: 1 ./t1300-repo-config.sh (Wstat: 256 Tests: 104 Failed: 1) Failed test: 48 Non-zero exit status: 1 ./t2006-checkout-index-basic.sh(Wstat: 256 Tests: 2 Failed: 2) Failed tests: 1-2 Non-zero exit status: 1 ./t2107-update-index-basic.sh (Wstat: 256 Tests: 3 Failed: 1) Failed test: 2 Non-zero exit status: 1 ./t3004-ls-files-basic.sh (Wstat: 256 Tests: 4 Failed: 2) Failed tests: 3-4 Non-zero exit status: 1 ./t3200-branch.sh (Wstat: 256 Tests: 82 Failed: 2) Failed tests: 3, 10 Non-zero exit status: 1 ./t3406-rebase-message.sh (Wstat: 256 Tests: 6 Failed: 1) Failed test: 6 Non-zero exit status: 1 ./t3400-rebase.sh (Wstat: 256 Tests: 26 Failed: 4) Failed tests: 5-8 Non-zero exit status: 1 ./t3501-revert-cherry-pick.sh (Wstat: 256 Tests: 7 Failed: 2) Failed tests: 2-3 Non-zero exit status: 1 ./t4006-diff-mode.sh (Wstat: 256 Tests: 7 Failed: 4) Failed tests: 4-7 Non-zero exit status: 1 ./t4012-diff-binary.sh (Wstat: 256 Tests: 13 Failed: 2) Failed tests: 7-8 Non-zero exit status: 1 ./t4035-diff-quiet.sh (Wstat: 256 Tests: 20 Failed: 3) Failed tests: 16, 18, 20 Non-zero exit status: 1 ./t4120-apply-popt.sh (Wstat: 256 Tests: 8 Failed: 2) Failed tests: 3, 5 Non-zero exit status: 1 ./t4133-apply-filenames.sh (Wstat: 256 Tests: 2 Failed: 1) Failed test: 2 Non-zero exit status: 1 ./t4200-rerere.sh (Wstat: 256 Tests: 25 Failed: 2) Failed tests: 24-25 Non-zero exit status: 1 ./t4205-log-pretty-formats.sh (Wstat: 256 Tests: 13 Failed: 1) Failed test: 12 Non-zero exit status: 1 ./t4202-log.sh (Wstat: 256 Tests: 33 Failed: 1) Failed test: 33 Non-zero exit status: 1 ./t3903-stash.sh (Wstat: 256 Tests: 46 Failed: 1) Failed test: 45 Non-zero exit status: 1 ./t5300-pack-object.sh (Wstat: 256 Tests: 33 Failed: 2) Failed tests: 32-33 Non-zero exit status: 1 ./t5505-remote.sh (Wstat: 256 Tests: 68 Failed: 9) Failed tests: 2-3, 6-9, 13, 15, 46 Non-zero exit status: 1 ./t5530-upload-pack-error.sh (Wstat: 256 Tests: 10 Failed: 1) Failed test: 3 Non-zero exit status: 1 ./t6500-gc.sh (Wstat: 256 Tests: 3 Failed: 2) Failed tests: 2-3 Non-zero exit status: 1 ./t6042-merge-rename-corner-cases.sh (Wstat: 256 Tests: 26 Failed: 1) Failed test: 18 Non-zero exit status: 1 ./t6022-merge-rename.sh(Wstat: 256 Tests: 46 Failed: 3) Failed tests: 12, 15-16 Non-zero exit status: 1 ./t7008-grep-binary.sh (Wstat: 0 Tests: 20 Failed: 0) TODO passed: 12 ./t7508-status.sh (Wstat: 256 Tests: 76 Failed: 1) Failed test: 5 Non-zero exit status: 1 ./t7600-merge.sh (Wstat: 256 Tests: 48 Failed: 1) Failed test: 3 Non-zero exit status: 1 ./t9903-bash-prompt.sh (Wstat: 256 Tests: 44 Faile
[PATCH v2 4/5] Make sure to use Araxis' "compare" and not e.g. ImageMagick's
Signed-off-by: Sebastian Schuberth
---
mergetools/araxis | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/mergetools/araxis b/mergetools/araxis
index 64f97c5..aeba1b9 100644
--- a/mergetools/araxis
+++ b/mergetools/araxis
@@ -16,5 +16,11 @@ merge_cmd () {
}
translate_merge_tool_path() {
- echo compare
+ # Make sure to use Araxis' "compare" and not e.g. ImageMagick's.
+ if ls "$(dirname "$(which compare)")"/Araxis* >/dev/null 2>&1
+ then
+ echo compare
+ else
+ echo "$1"
+ fi
}
--
1.7.11.msysgit.2
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/5] Sort the list of tools that support both merging and diffing alphabetically
Signed-off-by: Sebastian Schuberth --- contrib/completion/git-completion.bash | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash index 5be9dee..f2c4894 100755 --- a/contrib/completion/git-completion.bash +++ b/contrib/completion/git-completion.bash @@ -1325,8 +1325,8 @@ _git_diff () __git_complete_revlist_file } -__git_mergetools_common="diffuse ecmerge emerge kdiff3 meld opendiff - tkdiff vimdiff gvimdiff xxdiff araxis p4merge bc3 +__git_mergetools_common="araxis bc3 diffuse ecmerge emerge gvimdiff + kdiff3 meld opendiff p4merge tkdiff vimdiff xxdiff " _git_difftool () -- 1.7.11.msysgit.2 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git with large files...
2012/7/23 Sitaram Chamarty : > On Mon, Jul 23, 2012 at 2:24 AM, Junio C Hamano wrote: >> mer...@stonehenge.com (Randal L. Schwartz) writes: >> "Darek" == Darek Bridges writes: >>> >>> Darek> I use git for many things, but I am trying to work out the >>> Darek> workflow to use git for deployment. >>> >>> Don't. >> >> Yeah, "don't think 'git checkout' is a way to 'deploy'". Using Git >> as a transport measure is probably fine. > > You can also try > http://sitaramc.github.com/the-list-and-irc/deploy.html. Whether it's > saying you *can* use git for deploying something, or you *can* but > *should not*, or you *cannot*, will depend on your own thoughts on the > matter ;-) Nice summary list of options! If you combine that with several key concepts: 1. You plan and design to deploy - hence you have separate deploy repositories dedicated for that 2. You design for modularity and complete audit trail, hence you have this: http://abstractiondev.files.wordpress.com/2011/12/git-distribution-overview.png You can combine the staging with any approach, that *tries* to maintain the local version copy. But if any problem arises in pull/fetch, simply trash that part and get it from fresh (or just use the git archive approach). Now this model would introduce complete and as detailed security enforcement - as the deployment can validate with certificates (from the additional catalogue-metadata binding, whether there is authorized party confirmed signature available for the wished deployable version). I don't see much overhead in any of the steps here - and the deployment is as detailed and as securely controlled as desired. With just Git (and well, possibly GnuPG or alike common tool for digital certificate work). Everything is also transparent - which is very important in having that complete control and audit trail. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/5] Use variables for the lists of tools that support merging / diffing
Also, add a few comments that clarify the meaning of these variables.
Signed-off-by: Sebastian Schuberth
---
contrib/completion/git-completion.bash | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index f2c4894..6b9b79d 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1325,17 +1325,24 @@ _git_diff ()
__git_complete_revlist_file
}
+# Tools that support both merging and diffing.
__git_mergetools_common="araxis bc3 diffuse ecmerge emerge gvimdiff
kdiff3 meld opendiff p4merge tkdiff vimdiff xxdiff
"
+# Tools that support diffing.
+__git_difftools="$__git_mergetools_common kcompare"
+
+# Tools that support merging.
+__git_mergetools="$__git_mergetools_common tortoisemerge"
+
_git_difftool ()
{
__git_has_doubledash && return
case "$cur" in
--tool=*)
- __gitcomp "$__git_mergetools_common kompare" ""
"${cur##--tool=}"
+ __gitcomp "$__git_difftools" "" "${cur##--tool=}"
return
;;
--*)
@@ -1623,7 +1630,7 @@ _git_mergetool ()
{
case "$cur" in
--tool=*)
- __gitcomp "$__git_mergetools_common tortoisemerge" ""
"${cur##--tool=}"
+ __gitcomp "$__git_mergetools" "" "${cur##--tool=}"
return
;;
--*)
--
1.7.11.msysgit.2
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/5] Various merge / diff tool related minor clean-ups and improvements
This series introduces various minor clean-ups and improvements to the merge / diff tool scripts and documentation. Sorry, the first version was missing a patch. Sebastian Schuberth (5): Sort the list of tools that support both merging and diffing alphabetically Use variables for the lists of tools that support merging / diffing Explicitly list all valid diff tools and document --tool-help as an option Make sure to use Araxis' "compare" and not e.g. ImageMagick's Add a few more code comments and blank lines in guess_merge_tool Documentation/git-difftool.txt | 9 ++--- contrib/completion/git-completion.bash | 15 +++ git-mergetool--lib.sh | 6 ++ mergetools/araxis | 8 +++- 4 files changed, 30 insertions(+), 8 deletions(-) -- 1.7.11.msysgit.2 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] Various merge / diff tool related minor clean-ups and improvements
This series introduce various minor clean-ups and improvements to the merge / diff tool scripts and documentation. Sebastian Schuberth (4): Use variables for the lists of tools that support merging / diffing Explicitly list all valid diff tools and document --tool-help as an option Make sure to use Araxis' "compare" and not e.g. ImageMagick's Add a few more code comments and blank lines in guess_merge_tool Documentation/git-difftool.txt | 9 ++--- contrib/completion/git-completion.bash | 11 +-- git-mergetool--lib.sh | 6 ++ mergetools/araxis | 8 +++- 4 files changed, 28 insertions(+), 6 deletions(-) -- 1.7.11.msysgit.2 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
