* Re: Python extension commands in git - request for policy change
From: Philippe Vaucher @ 2012-12-03 21:45 UTC (permalink / raw)
To: Felipe Contreras
Cc: esr, Magnus Bäck, Michael Haggerty, git@vger.kernel.org
In-Reply-To: <CAMP44s27gdDJGNx-UTe1rdQZFpn3M60L=nMyd69gAFo15VnMAA@mail.gmail.com>
> Also, you are ignoring all the advantages that shell has and python does not.
Out of curiosity, can you list the advantages? From what I gathered:
- no need to install bash
- git contributors are more used to bash
- there's only one "version" of bash (no real need to handle different
versions compared to py26, py27, etc)
Are there any "language" advantage or are all the advantages in the
"pragmatic" section?
I don't really have an opinion on this topic. A "real language" seems
better, but bash's pragmaticity seems to outweight the cons,
especially the "contributors want bash" argument.
Thanks,
Philippe
^ permalink raw reply
* Re: [PATCH] gitk: read and write a repository specific configuration file
From: Stefan Haller @ 2012-12-03 21:15 UTC (permalink / raw)
To: Lukasz Stelmach, git; +Cc: paulus, gitster
In-Reply-To: <1354483766-13925-1-git-send-email-stlman@poczta.fm>
Lukasz Stelmach <stlman@poczta.fm> wrote:
> Enable gitk read and write repository specific configuration
> file: ".git/k" if the file exists. To make gitk use the local
> file simply create one, e.g. with the touch(1) command.
I'm not sure I like this proposal. While it may be desirable to have
*some* settings stored per repository, for most settings I want them to
be remembered globally.
Git-gui tries to solve this by presenting two panes in the preferences
dialog, so that I can choose the scope of every setting I change. This
still doesn't help for things that are remembered implicitly, like the
window size.
I don't have good suggestions how to solve this; just pointing out
problems.
--
Stefan Haller
Berlin, Germany
http://www.haller-berlin.de/
^ permalink raw reply
* [ANNOUNCE] Git v1.8.1-rc0
From: Junio C Hamano @ 2012-12-03 21:09 UTC (permalink / raw)
To: git; +Cc: Linux Kernel
A release candidate preview, Git v1.8.1-rc0, is now available for
testing at the usual places.
This cycle has been a bit slow (perhaps because it had a major US
holiday to slow people down) but we seem to have managed to apply
reasonably large number of usability improvement changes, with a
handful of new features. There are several new and large-ish topics
that are cooking in 'next', but I think we would better keep them
cooking there without merging them to 'master' before the upcoming
release to happen before the year end. So as far as features goes,
this preview release is pretty much *it*.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
39faaa15bc71f8eb52048e77ea564cecf78c7adf git-1.8.1.rc0.tar.gz
2eeba24488337de02b58dc442258d58b79e2b8f4 git-htmldocs-1.8.1.rc0.tar.gz
b28d1f8e8b9268b712b33fbdfb67dd6f14afb499 git-manpages-1.8.1.rc0.tar.gz
Also the following public repositories all have a copy of the v1.8.1-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.8.1 Release Notes (draft)
========================
Backward compatibility notes
----------------------------
In the next major release (not *this* one), we will change the
behavior of the "git push" command.
When "git push [$there]" does not say what to push, we have used the
traditional "matching" semantics so far (all your branches were sent
to the remote as long as there already are branches of the same name
over there). We will use the "simple" semantics that pushes the
current branch to the branch with the same name, only when the current
branch is set to integrate with that remote branch. There is a user
preference configuration variable "push.default" to change this, and
"git push" will warn about the upcoming change until you set this
variable in this release.
"git branch --set-upstream" is deprecated and may be removed in a
relatively distant future. "git branch [-u|--set-upstream-to]" has
been introduced with a saner order of arguments to replace it.
Updates since v1.8.0
--------------------
UI, Workflows & Features
* Command-line completion scripts for tcsh and zsh have been added.
* A new remote-helper interface for Mercurial has been added to
contrib/remote-helpers.
* We used to have a workaround for a bug in ancient "less" that
causes it to exit without any output when the terminal is resized.
The bug has been fixed in "less" version 406 (June 2007), and the
workaround has been removed in this release.
* Some documentation pages that used to ship only in the plain text
format are now formatted in HTML as well.
* "git-prompt" scriptlet (in contrib/completion) can be told to paint
pieces of the hints in the prompt string in colors.
* A new configuration variable "diff.context" can be used to
give the default number of context lines in the patch output, to
override the hardcoded default of 3 lines.
* When "git checkout" checks out a branch, it tells the user how far
behind (or ahead) the new branch is relative to the remote tracking
branch it builds upon. The message now also advises how to sync
them up by pushing or pulling. This can be disabled with the
advice.statusHints configuration variable.
* "git config --get" used to diagnose presence of multiple
definitions of the same variable in the same configuration file as
an error, but it now applies the "last one wins" rule used by the
internal configuration logic. Strictly speaking, this may be an
API regression but it is expected that nobody will notice it in
practice.
* "git log -p -S<string>" now looks for the <string> after applying
the textconv filter (if defined); earlier it inspected the contents
of the blobs without filtering.
* "git format-patch" learned the "--notes=<ref>" option to give
notes for the commit after the three-dash lines in its output.
* "git log --grep=<pcre>" learned to honor the "grep.patterntype"
configuration set to "perl".
* "git replace -d <object>" now interprets <object> as an extended
SHA-1 (e.g. HEAD~4 is allowed), instead of only accepting full hex
object name.
* "git rm $submodule" used to punt on removing a submodule working
tree to avoid losing the repository embedded in it. Because
recent git uses a mechanism to separate the submodule repository
from the submodule working tree, "git rm" learned to detect this
case and removes the submodule working tree when it is safe to do so.
* "git send-email" used to prompt for the sender address, even when
the committer identity is well specified (e.g. via user.name and
user.email configuration variables). The command no longer gives
this prompt when not necessary.
* "git send-email" did not allow non-address garbage strings to
appear after addresses on Cc: lines in the patch files (and when
told to pick them up to find more recipients), e.g.
Cc: Stable Kernel <stable@k.org> # for v3.2 and up
The command now strips " # for v3.2 and up" part before adding the
remainder of this line to the list of recipients.
* "git submodule add" learned to add a new submodule at the same
path as the path where an unrelated submodule was bound to in an
existing revision via the "--name" option.
* "git submodule sync" learned the "--recursive" option.
* "diff.submodule" configuration variable can be used to give custom
default value to the "git diff --submodule" option.
* "git symbolic-ref" learned the "-d $symref" option to delete the
named symbolic ref, which is more intuitive way to spell it than
"update-ref -d --no-deref $symref".
Foreign Interface
* "git cvsimport" can be told to record timezones (other than GMT)
per-author via its author info file.
* The remote helper interface to interact with subversion
repositories (one of the GSoC 2012 projects) has been merged.
Performance, Internal Implementation, etc.
* Compilation on Cygwin with newer header files are supported now.
* The logic to generate the initial advertisement from "upload-pack"
(i.e. what is invoked by "git fetch" on the other side of the
connection) to list what refs are available in the repository has
been optimized.
* The logic to find set of attributes that match a given path has
been optimized.
* Use preloadindex in "git diff-index" and "git update-index", which
has a nice speedup on systems with slow stat calls (and even on
Linux).
Also contains minor documentation updates and code clean-ups.
Fixes since v1.8.0
------------------
Unless otherwise noted, all the fixes since v1.8.0 in the maintenance
track are contained in this release (see release notes to them for
details).
* The configuration parser had an unnecessary hardcoded limit on
variable names that was not checked consistently.
(merge 0971e99 bw/config-lift-variable-name-length-limit later to maint).
* The "say" function in the test scaffolding incorrectly allowed
"echo" to interpret "\a" as if it were a C-string asking for a
BEL output.
(merge 7bc0911 jc/test-say-color-avoid-echo-escape later to maint).
* "git mergetool" feeds /dev/null as a common ancestor when dealing
with an add/add conflict, but p4merge backend cannot handle
it. Work it around by passing a temporary empty file.
(merge 3facc60 da/mergetools-p4 later to maint).
* "git log -F -E --grep='<ere>'" failed to use the given <ere>
pattern as extended regular expression, and instead looked for the
string literally.
(merge 727b6fc jc/grep-pcre-loose-ends~1 later to maint).
* "git grep -e pattern <tree>" asked the attribute system to read
"<tree>:.gitattributes" file in the working tree, which was
nonsense.
(merge 55c6168 nd/grep-true-path later to maint).
* A symbolic ref refs/heads/SYM was not correctly removed with "git
branch -d SYM"; the command removed the ref pointed by SYM
instead.
(merge 13baa9f rs/branch-del-symref later to maint).
* Update "remote tracking branch" in the documentation to
"remote-tracking branch".
(merge a6d3bde mm/maint-doc-remote-tracking later to maint).
* "git pull --rebase" run while the HEAD is detached tried to find
the upstream branch of the detached HEAD (which by definition
does not exist) and emitted unnecessary error messages.
(merge e980765 ph/pull-rebase-detached later to maint).
* The refs/replace hierarchy was not mentioned in the
repository-layout docs.
(merge 11fbe18 po/maint-refs-replace-docs later to maint).
* Various rfc2047 quoting issues around a non-ASCII name on the
From: line in the output from format-patch have been corrected.
(merge 25dc8da js/format-2047 later to maint).
* Sometimes curl_multi_timeout() function suggested a wrong timeout
value when there is no file descriptor to wait on and the http
transport ended up sleeping for minutes in select(2) system call.
A workaround has been added for this.
(merge 7202b81 sz/maint-curl-multi-timeout later to maint).
* For a fetch refspec (or the result of applying wildcard on one),
we always want the RHS to map to something inside "refs/"
hierarchy, but the logic to check it was not exactly right.
(merge 5c08c1f jc/maint-fetch-tighten-refname-check later to maint).
* "git diff -G<pattern>" did not honor textconv filter when looking
for changes.
(merge b1c2f57 jk/maint-diff-grep-textconv later to maint).
* Some HTTP servers ask for auth only during the actual packing phase
(not in ls-remote phase); this is not really a recommended
configuration, but the clients used to fail to authenticate with
such servers.
(merge 2e736fd jk/maint-http-half-auth-fetch later to maint).
* "git p4" used to try expanding malformed "$keyword$" that spans
across multiple lines.
(merge 6b2bf41 pw/maint-p4-rcs-expansion-newline later to maint).
* Syntax highlighting in "gitweb" was not quite working.
(merge 048b399 rh/maint-gitweb-highlight-ext later to maint).
* RSS feed from "gitweb" had a xss hole in its title output.
(merge 0f0ecf6 jk/maint-gitweb-xss later to maint).
* "git config --path $key" segfaulted on "[section] key" (a boolean
"true" spelled without "=", not "[section] key = true").
(merge 962c38e cn/config-missing-path later to maint).
* "git checkout -b foo" while on an unborn branch did not say
"Switched to a new branch 'foo'" like other cases.
(merge afa8c07 jk/checkout-out-of-unborn later to maint).
* We failed to mention a file without any content change but whose
permission bit was modified, or (worse yet) a new file without any
content in the "git diff --stat" output.
(merge de9095955 lt/diff-stat-show-0-lines later to maint).
* When "--stat-count" hides a diffstat for binary contents, the total
number of added and removed lines at the bottom was computed
incorrectly.
(merge de9095955 lt/diff-stat-show-0-lines later to maint).
* When "--stat-count" hides a diffstat for unmerged paths, the total
number of affected files at the bottom of the "diff --stat" output
was computed incorrectly.
(merge de9095955 lt/diff-stat-show-0-lines later to maint).
* "diff --shortstat" miscounted the total number of affected files
when there were unmerged paths.
(merge de9095955 lt/diff-stat-show-0-lines later to maint).
* "update-ref -d --deref SYM" to delete a ref through a symbolic ref
that points to it did not remove it correctly.
(merge b274a71 jh/update-ref-d-through-symref later to maint).
^ permalink raw reply
* Re: [PATCH v6 2/4] submodule update: add --remote for submodule's upstream changes
From: Junio C Hamano @ 2012-12-03 20:29 UTC (permalink / raw)
To: W. Trevor King
Cc: Git, Heiko Voigt, Jeff King, Phil Hord, Shawn Pearce,
Jens Lehmann, Nahor
In-Reply-To: <20121203183802.GD14981@odin.tremily.us>
"W. Trevor King" <wking@tremily.us> writes:
> As an example to make this clearer:
>
> $ cat .gitmodules
> [submodule "sub1"]
> path = sub1
> url = git://example.com/sub1.git
> remote = remote1
> branch = branch1
> update-source = submodule-upstream
> update = rebase
> [submodule "sub2"]
> ...
Maybe it is just me but that "remote = remote1" sticks out like a
sore thumb.
If you are showing the .gitmodules file to be shared as hints to
project participants, why does it even need to have both URL and
remote1? If remote1 points at some other repository, the recipient
of this .gitmodules file would not have any clue where it is. If
remote1 points at the same repository as the URL, why should it be
there in the first place? The superproject is in no business to
force what local remote name each participant would call in their
submodule checkout, and more importantly, there is no _need_ to do
so.
We could extend that reasoning to the branch name (which is also a
local matter, at least technically), but this is a lot more
justifiable. If the upstream of the superproject is the same
organization as the upstream of the submodule project, which is
often the case when a large project is organized as a forest of
submodules bound at the top-level with a superproject, the
superproject commit on a particular superproject branch may want any
update necessary to complete the superproject made to submodules on
specific branches at the central meeting place. The superproject's
Milestone22 branch may want to bind commits that is on submodule's
Milestone22 branch.
While a participant locally *can* create M22 branch in the submodule
and set it to build upon Milestone22 branch taken from the central
repository, most people don't. They use the same branch names
between local and remote (i.e. refs/heads/*:refs/remotes/origin/* to
keep the remote-tracking branches under the same name, and the local
branch $any builds upon the corresponding remote-tracking branch
refs/remotes/origin/$any. Most importantly, the work done on local
branch $any is pushed out to refs/heads/$any at the remote of the
submodule). Because of how people use "push" to push $any branch to
the branch of the same name $any at the central meeting place, and
because the upstream wants participants to use a particular branch
name in the submodule at the central meeting place, the set-up ends
up dictating what local branch name should be used.
But I do not see any reason to require or even suggest any local
nickname that is to be used to call the remote. It really is a
local matter. Why should .gitmodules have "remote = ..." line?
On the other hand, if you meant the above as an excerpt from
$GIT_DIR/config, it also does not make sense. At that point, the
participant own the file and updating url to point at whatever
different repository without changing the remote name is sufficient.
It looks way over-engineered for unclear/dubious benefit.
^ permalink raw reply
* Re: [PATCH v2 0/4] git-svn: More docs for branch handling in
From: Junio C Hamano @ 2012-12-03 19:32 UTC (permalink / raw)
To: Sebastian Leske; +Cc: git, Michael J Gruber, Eric Wong
In-Reply-To: <cover.1354324110.git.Sebastian.Leske@sleske.name>
I've sent comments on small nits I found but overall they looked
quite well researched. Will tentatively queue on the 'pu' branch,
expecting further updates and Acks from people involved polishing
these patches.
Thanks for writing it up.
^ permalink raw reply
* Re: [PATCH v2 3/4] git-svn: Expand documentation for --follow-parent
From: Junio C Hamano @ 2012-12-03 19:30 UTC (permalink / raw)
To: Sebastian Leske; +Cc: git, Michael J Gruber, Eric Wong
In-Reply-To: <cf118fcd52a0cf7bdf7b08a5a52cd0e285bd056b.1354324110.git.Sebastian.Leske@sleske.name>
Sebastian Leske <Sebastian.Leske@sleske.name> writes:
> Describe what the option --follow-parent does, and what happens if it is
> set or unset.
>
> Signed-off-by: Sebastian Leske <sebastian.leske@sleske.name>
> ---
> Documentation/git-svn.txt | 15 ++++++++++++---
> 1 file changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
> index bfa8788..6bda014 100644
> --- a/Documentation/git-svn.txt
> +++ b/Documentation/git-svn.txt
> @@ -628,10 +628,19 @@ ADVANCED OPTIONS
> Default: "svn"
>
> --follow-parent::
> + This option is only relevant if we are tracking branches (using
> + one of the repository layout options --trunk, --tags,
> + --branches, --stdlayout). For each tracked branch, try to find
> + out where its revision was copied (i.e. branched) from, and set
> + a suitable parent in the first git commit for the branch.
I also commit this sin myself often, but it is a good habit to get
into to re-read the sentence after writing "... X (i.e. Y)", "... V
(meaning W)", "... A (in other words B)". We often write these
after realizing that "... X", "... V" or "... A" is hard to
understand and attempt to paraphrase to make it easier, but while
doing so we unconsciously hesitate to remove what we originally
wrote. The results sometimes (but not always) reads better if you
do not say X, V or A and only used the rephrased version that is
meant to be easier-to-read.
In this case, I think "was copied" and "was branched" alone are
equally good but adding "(i.e. branched)" sounds redundant.
> This is especially helpful when we're tracking a directory
> - that has been moved around within the repository, or if we
> - started tracking a branch and never tracked the trunk it was
> - descended from. This feature is enabled by default, use
> + that has been moved around within the repository. If this
> + feature is disabled, the branches created by 'git svn' will all
> + be linear and not share any history, meaning that there will be
> + no information on where branches where branched off or merged.
I think the second "where" is a typo for "were" here.
> + However, following long/convoluted histories can take a long
> + time, so disabling this feature may speed up the cloning
> + process. This feature is enabled by default, use
> --no-follow-parent to disable it.
> +
> [verse]
^ permalink raw reply
* Re: [PATCH v2 2/4] Recommend use of structure options for git svn.
From: Junio C Hamano @ 2012-12-03 19:30 UTC (permalink / raw)
To: Sebastian Leske; +Cc: git, Michael J Gruber, Eric Wong
In-Reply-To: <5cb2f71bc9be3323e425205020105dcfd948fca5.1354324110.git.Sebastian.Leske@sleske.name>
Sebastian Leske <Sebastian.Leske@sleske.name> writes:
> Document that when using git svn, one should usually either use the
> directory structure options to import branches as branches, or only
> import one subdirectory. The default behaviour of cloning all branches
> and tags as subdirectories in the working copy is usually not what the
> user wants.
>
> Signed-off-by: Sebastian Leske <sebastian.leske@sleske.name>
> ---
> Documentation/git-svn.txt | 24 +++++++++++++++++++++---
> 1 file changed, 21 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
> index 824bf82..bfa8788 100644
> --- a/Documentation/git-svn.txt
> +++ b/Documentation/git-svn.txt
> @@ -739,7 +739,8 @@ for rewriteRoot and rewriteUUID which can be used together.
> BASIC EXAMPLES
> --------------
>
> -Tracking and contributing to the trunk of a Subversion-managed project:
> +Tracking and contributing to the trunk of a Subversion-managed project
> +(ignoring tags and branches):
>
> ------------------------------------------------------------------------
> # Clone a repo (like git clone):
> @@ -764,8 +765,10 @@ Tracking and contributing to an entire Subversion-managed project
> (complete with a trunk, tags and branches):
>
> ------------------------------------------------------------------------
> -# Clone a repo (like git clone):
> - git svn clone http://svn.example.com/project -T trunk -b branches -t tags
> +# Clone a repo with standard SVN directory layout (like git clone):
> + git svn clone http://svn.example.com/project --stdlayout
> +# Or, if the repo uses a non-standard directory layout:
> + git svn clone http://svn.example.com/project -T tr -b branch -t tag
These command line, given that the SYNPOSIS section says:
git svn <command> [options] [arguments]
look strange to have the URL argument before all the options.
Because the original shares the same trait, this should not be fixed
in this patch, but it may be a good idea to fix the order of the
arguments in a separate follow-up patch.
> @@ -871,6 +874,21 @@ already dcommitted. It is considered bad practice to --amend commits
> you've already pushed to a remote repository for other users, and
> dcommit with SVN is analogous to that.
>
> +When cloning an SVN repository, if none of the options for describing
> +the repository layout is used (--trunk, --tags, --branches,
> +--stdlayout), 'git svn clone' will create a git repository with
> +completely linear history, where branches and tags appear as separate
> +folders in the working copy. ...
As existing text in git-svn.txt consistently uses "directory" and
never "folder", please match that terminology (like you did in a
later sentence in your patch).
> ... While this is the easiest way to get a
> +copy of a complete repository, for projects with many branches it will
> +lead to a working copy many times larger than just the trunk. Thus for
> +projects using the standard directory structure (trunk/branches/tags),
> +it is recommended to clone with option '--stdlayout'. If the project
> +uses a non-standard structure, and/or if branches and tags are not
> +required, it is easiest to only clone one directory (typically trunk),
> +without giving any repository layout options. If the full history with
> +branches and tags is required, the options '--trunk' / '--branches' /
> +'--tags' must be used.
> +
> When using multiple --branches or --tags, 'git svn' does not automatically
> handle name collisions (for example, if two branches from different paths have
> the same name, or if a branch and a tag have the same name). In these cases,
^ permalink raw reply
* Re: [PATCH v6 1/4] submodule: add get_submodule_config helper funtion
From: Junio C Hamano @ 2012-12-03 19:30 UTC (permalink / raw)
To: W. Trevor King
Cc: Git, Heiko Voigt, Jeff King, Phil Hord, Shawn Pearce,
Jens Lehmann, Nahor
In-Reply-To: <436a73a8fdc8f0695aa597d53483d4c4bae16ebb.1354417618.git.wking@tremily.us>
"W. Trevor King" <wking@tremily.us> writes:
> From: "W. Trevor King" <wking@tremily.us>
>
> Several submodule configuration variables
> (e.g. fetchRecurseSubmodules) are read from .gitmodules with local
> overrides from the usual git config files. This shell function mimics
> that logic to help initialize configuration variables in
> git-submodule.sh.
>
> Signed-off-by: W. Trevor King <wking@tremily.us>
> ---
> git-submodule.sh | 27 +++++++++++++++++++++++++++
> 1 file changed, 27 insertions(+)
>
> diff --git a/git-submodule.sh b/git-submodule.sh
> index ab6b110..97ce5e4 100755
> --- a/git-submodule.sh
> +++ b/git-submodule.sh
> @@ -152,6 +152,33 @@ die_if_unmatched ()
> }
>
> #
> +# Print a submodule configuration setting
> +#
> +# $1 = submodule name
> +# $2 = option name
> +# $3 = default value
> +#
> +# Checks in the usual git-config places first (for overrides),
> +# otherwise it falls back on .gitmodules. This allows you to
> +# distribute project-wide defaults in .gitmodules, while still
> +# customizing individual repositories if necessary. If the option is
> +# not in .gitmodules either, print a default value.
> +#
> +get_submodule_config()
> +{
style (see CodingGuidelines):
get_submodule_config () {
> + name="$1"
> + option="$2"
> + default="$3"
> + value=$(git config submodule."$name"."$option")
This will get unwieldy quickly once we have submodule.$name.$var
that takes a boolean option, as there are different ways to spell
boolean and "git config --bool" is the way to ask for canonicalized
"true" or "false".
If we never query any boolean via this helper function, it is
obviously not an issue, though.
> + if test -z "$value"
> + then
> + value=$(git config -f .gitmodules submodule."$name"."$option")
> + fi
> + printf '%s' "${value:-$default}"
> +}
> +
> +
> +#
> # Map submodule path to submodule name
> #
> # $1 = path
^ permalink raw reply
* Re: [PATCH v2 1/4] git-svn: Document branches with at-sign(@).
From: Junio C Hamano @ 2012-12-03 19:28 UTC (permalink / raw)
To: Sebastian Leske; +Cc: git, Michael J Gruber, Eric Wong
In-Reply-To: <67e9db6f948315f3c733dda0ad970e6257c075af.1354324110.git.Sebastian.Leske@sleske.name>
Sebastian Leske <Sebastian.Leske@sleske.name> writes:
> git svn will sometimes create branches with an at-sign in the name
It may be just me but "git svn sometimes creates" without "will"
reads much better to me (there is the same phrasing in the patch
text as well).
> (branchname@revision). These branches confuse many users and it is a FAQ
> why they are created. Document when git svn will create them.
>
> Signed-off-by: Sebastian Leske <sebastian.leske@sleske.name>
> ---
> Documentation/git-svn.txt | 38 ++++++++++++++++++++++++++++++++++++++
> 1 file changed, 38 insertions(+)
>
> diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
> index 8b0d3ad..824bf82 100644
> --- a/Documentation/git-svn.txt
> +++ b/Documentation/git-svn.txt
> @@ -881,6 +881,44 @@ different name spaces. For example:
> branches = stable/*:refs/remotes/svn/stable/*
> branches = debug/*:refs/remotes/svn/debug/*
>
> +If 'git svn' is configured to fetch branches (and --follow-branches
> +is in effect), it will sometimes create multiple branches for one SVN
> +branch, where the addtional branches have names of the form
> +'branchname@nnn' (with nnn an SVN revision number). These additional
> +branches are created if 'git svn' cannot find a parent commit for the
> +first commit in an SVN branch, to connect the branch to the history of
> +the other branches. Normally, the first commit in an SVN branch consists
> +of a copy operation. 'git svn' will read this commit to get the SVN
> +revision the branch was created (copied) from. It will then try to find the
> +git commit that corresponds to this SVN revision, and use that as the
> +parent of the branch. However, it is possible that there is no suitable
> +git commit to serve as parent. This will happen, among other reasons,
> +if the SVN branch is a copy of a revision that was not fetched by 'git
> +svn' (e.g. because it is an old revision that was skipped with
> +'--revision'), or if in SVN a directory was copied that is not tracked
> +by 'git svn' (such as a branch that is not tracked at all, or a
> +subdirectory of a tracked branch). In these cases, 'git svn' will still
> +create a git branch, but instead of using an existing git commit as the
> +parent of the branch, it will read the SVN history of the directory the
> +branch was copied from and create appropriate git commits (this is
> +indicated by the message "Initializing parent: <branchname>").
> +Additionally, it will create a special branch named
> +'<branchname>@<SVN-Revision>', where <SVN-Revision> is the SVN revision
> +number the branch was copied from. This branch will point to the newly
> +created parent commit of the branch. If in SVN the branch was deleted
> +and later recreated from a different version, there will be multiple
> +such branches with an '@'.
> +Note that this may mean that multiple git commits are created for a
> +single SVN revision. An example: In an SVN repository with a standard
> +trunk/tags/branches layout, a directory trunk/sub is created in r.100.
> +In r.200, trunk/sub is branched by copying it to branches/. 'git svn
> +clone -s' will then create a branch 'sub'. It will also create new git
> +commits for r.100 through r.199 and use these as the history of branch
> +'sub'. Thus there will be two git commits for each revision from r.100
> +to r.199 (one containing trunk/, one containing trunk/sub/). Finally,
> +it will create a branch 'sub@200' pointing to the new parent commit of
> +branch 'sub' (i.e. the commit for r.200 and trunk/sub/).
> +
Have you looked at the formatted result? This is quite detailed and
long, and may deserve to be split into a few paragraphs. I'd
probably suggest a paragraph break before "Normally, the first...",
"Additionally", "Note that", and "An example:"
^ permalink raw reply
* Re: [PATCH v6 0/8] push: update remote tags only with force
From: Junio C Hamano @ 2012-12-03 18:53 UTC (permalink / raw)
To: Chris Rorvick
Cc: git, Angelo Borsotti, Drew Northup, Michael Haggerty,
Philip Oakley, Johannes Sixt, Kacper Kornet, Jeff King,
Felipe Contreras
In-Reply-To: <1354239700-3325-1-git-send-email-chris@rorvick.com>
Thanks; will queue.
^ permalink raw reply
* Re: [PATCH v6 2/4] submodule update: add --remote for submodule's upstream changes
From: W. Trevor King @ 2012-12-03 18:38 UTC (permalink / raw)
To: Junio C Hamano
Cc: Git, Heiko Voigt, Jeff King, Phil Hord, Shawn Pearce,
Jens Lehmann, Nahor
In-Reply-To: <20121203181519.GC14981@odin.tremily.us>
[-- Attachment #1: Type: text/plain, Size: 1209 bytes --]
As an example to make this clearer:
$ cat .gitmodules
[submodule "sub1"]
path = sub1
url = git://example.com/sub1.git
remote = remote1
branch = branch1
update-source = submodule-upstream
update = rebase
[submodule "sub2"]
...
Means that `git submodule update sub1` will fetch remote1 and rebase
the current sub1 checkout against the tip of remote1/branch1. The
git://example.com/sub1.git URL is not actually used during this
update. Presumably the user setup remote1 intentionally in the
submodule, and wants to use the URL they've configured there.
Perhaps I need to ammend my
submodule update: add submodule.<name>.remote config option
patch (#4) to adjust the remote that has it's URL changed by `sync`?
I may also want to append some form of the following commit (from my
submodule.<name>.active proposal):
submodule add: configure existing submodule url if not set [1]
Cheers,
Trevor
[1]: https://github.com/wking/git/commit/b045c16cffe6eb86c157a6c7397166a46e147442
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] status: respect advice.statusHints for ahead/behind advice
From: Jeff King @ 2012-12-03 18:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matthieu Moy, git
In-Reply-To: <7vr4n7rrgb.fsf@alter.siamese.dyndns.org>
On Mon, Dec 03, 2012 at 09:11:32AM -0800, Junio C Hamano wrote:
> > On top of mm/status-push-pull-advise.
> >
> > I left "git checkout" alone, though I'd also like to turn it off there,
> > too. Should it get a separate advice option there? Should it simply
> > respect statusHints (it seems odd because I know that "status" there
> > means "git status", not "hints about the status of your repo")?
>
> I agree that we should have a toggle to turn it off and I think it
> is OK to reuse the same "hints about the status" option for this
> purpose. It is not like there is a released version that already
> gives the advice (possibly with some other option to turn it off)
> and you are changing the behaviour of "checkout" by suddenly making
> it honor statusHints advice.
>
> So let's do a lot simpler patch instead.
>
> -- >8 --
Perfect, thanks.
-Peff
^ permalink raw reply
* Re: [PATCH v6 2/4] submodule update: add --remote for submodule's upstream changes
From: W. Trevor King @ 2012-12-03 18:15 UTC (permalink / raw)
To: Junio C Hamano
Cc: Git, Heiko Voigt, Jeff King, Phil Hord, Shawn Pearce,
Jens Lehmann, Nahor
In-Reply-To: <7v8v9ft761.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 5148 bytes --]
On Mon, Dec 03, 2012 at 08:46:46AM -0800, Junio C Hamano wrote:
> As you hinted in the first paragraph, you could flip between merge,
> rebase, and detach with a command line option when running the
> "update" subcommand, but I would imagine that the expected use
> pattern is that for a particular project, you would choose one mode
> and consistently stick to that mode. To make it easier, the user
> can set submodule.$name.update once and run "update" without having
> to give any flags.
Sure.
> And this is about adding another mode to the "update" subcommand
> where the HEAD is not detached, nor merged, nor rebased, but is set
> to follow whatever commit a remote branch points at.
This is about adding another suite of modes. Currently you can
rebase/merge/checkout the superproject-recorded $sha1. I'm adding the
ability to rebase/merge/checkout a submodule-upstream branch. I
discuss this explicitly in Documentation/git-submodule.txt when
describing --remote.
> Shouldn't the patch add a way for the user to set a configuration
> variable to signal that this new mode is always used when "update"
> is run without a command line flag?
How about a new submodule.<name>.update-source with (which can be
either superproject-gitlink or submodule-upstream)? Or to be a bit
simpler and less explicit, a submodule.<name>.update-remote boolean?
For lack of a better name, I'll call this submodule.<name>.<something>
below.
> As the user has to configure submodule.$name.branch in order to use
> this mode anyway, I have a feeling that taking that as a signal, and
> ignoring submodule.$name.update altogether, might be a simpler
> interface from the end user's point of view. That is,
As I mention earlier, submodule.<name>.update is still important. I
think it's good to add a new submodule.<name>.<something> config and a
--no-remote option (to override a configured
submodule.<name>.<something>). This way a user that generally updates
via the superproject's gitlink can still configure a branch to update
from when they use --remote.
> (1) if you are not interested in the submodule $name, you do not
> "init" it; you "init" it for all of the following.
>
> (2) if you want to have the tree state as recorded in the
> superproject, you do "update" without any option to make the
> HEAD of the submodule detached at the commit the superproject's
> tree records;
>
> (3) if you want to follow the upstream project of the submodule,
> you set submodule.$name.branch to the branch you want to
> follow, and you do "update"---submodule.$name.update is ignored
> and you will make the HEAD of the submodule detached at the tip
> of the branch at the remote (using remote-tracking branch);
>
> (4) if you want to --merge or --rebase, you give them from the
> command line, or use submodule.$name.update.
But what if your whant to merge the upstream project into a currently
checked out submodule branch? Or rebase a currently detached head
against the upstream branch?
> I may be oversimplifying a bit, but a separate
> submodule.$name.remote feels very wrong;
I use submodule.<name>.remote in patch 4 to specify the name of the
superproject's remote (for when get_default_remote doesn't give the
value you want), but I think you're referring to the potential
submodule.<name>.<something> and the presense of the --remote option.
> How does this compare with the floating submodules Heiko has been
> working on?
Heiko's older hv/floating_submodules also uses submodule.<name>.branch
(with a similar interpretation). There's also a --branch option to
`update` for command-line overrides (which I don't have, perhaps I
should add them?). He reverts to the original behavior in the
presense of submodule.<name>.branch with `update --checkout`, or when
submodule.<name>.branch=HEAD.
He also fetches all remotes, while I fetch just the explicitly
configured submodule.<name>.remote falling back on
$(get_default_remote. His submodule.<name>.branch is the full local
ref for the branch (e.g. 'origin/master'), while mine is just the
remote branch (e.g. 'master'). I split the remote (e.g. 'origin')
into submodule.<name>.remote in patch 4 so you can explicitly fetch
just that remote (and not all the remotes you may have configured for
that submodule).
For reasons that I don't understand, he only supports the `checkout`
update logic for remote branches.
Heiko's newer hv/floating_submodules_draft builds on my earlier v4
--local-branch option, but he uses his own processing logic. He pulls
the existing 'update to $sha1' logic out into a new
handle_on_demand_update() and uses the stored submodule.<name>.branch
as the name of a local submodule branch to check out when tracking.
Then he pulls that local branches default upstream (configured in
.git/modules/<name>/config) with --ff-only.
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: Ubuntu: gitweb always looks for projects in /var/cache/git (“404 - no projects found”)
From: Alfonso Muñoz-Pomer Fuentes @ 2012-12-03 17:10 UTC (permalink / raw)
Cc: git
In-Reply-To: <20121129182826.GB17309@sigill.intra.peff.net>
Thank you very much for the clarification. Noticing how this wasn’t
documented anywhere I had the feeling that I was missing something.
On Thu 29 Nov 2012 19:28:26 CET, Jeff King wrote:
> On Thu, Nov 29, 2012 at 01:55:57PM +0000, Alfonso Muñoz-Pomer Fuentes wrote:
>
>> I’ve discovered this weird behaviour in gitweb and documented a workaround in
>> StackOverflow:
>> http://stackoverflow.com/questions/13609475/ubuntu-gitweb-always-looks-for-projects-in-var-cache-git-404-no-projects-f
>>
>> Basically, the variable $projectroot in gitweb.cgi in the beginning is reset to
>> the system default value in git_get_projects_list, when it is declared again.
>>
>> Is this a known bug? Or am I missing something?
>
> I think the analysis in that stack overflow post is wrong. The use of
> "our" in git_get_projects_list is not the culprit.
>
> The problem is that one should not edit gitweb.cgi directly; its
> built-in defaults (which you are tweaking) are overridden by
> /etc/gitweb.conf, which is shipped by the Ubuntu package. You should
> be making your changes in the config file, not the CGI script.
>
> -Peff
--
Alfonso Muñoz-Pomer Fuentes
Johann Heinrich von Thünen-Institut
Bundesforschungsinstitut für Ländliche Räume, Wald und Fischerei
Institut für Forstgenetik
Sieker Landstrasse 2
22927 Grosshansdorf
Telefon: +49 (0)4102/696-145
Fax: +49 (0)4102/696-200
Email: alfonso.munozpomer@vti.bund.de
Web: http://www.vti.bund.de
^ permalink raw reply
* Re: [PATCH] status: respect advice.statusHints for ahead/behind advice
From: Junio C Hamano @ 2012-12-03 17:11 UTC (permalink / raw)
To: Jeff King; +Cc: Matthieu Moy, git
In-Reply-To: <20121203061656.GA20164@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> If the user has unset advice.statusHints, we already
> suppress the "use git reset to..." hints in each stanza. The
> new "use git push to publish..." hint is the same type of
> hint. Let's respect statusHints for it, rather than making
> the user set yet another advice flag.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> On top of mm/status-push-pull-advise.
>
> I left "git checkout" alone, though I'd also like to turn it off there,
> too. Should it get a separate advice option there? Should it simply
> respect statusHints (it seems odd because I know that "status" there
> means "git status", not "hints about the status of your repo")?
I agree that we should have a toggle to turn it off and I think it
is OK to reuse the same "hints about the status" option for this
purpose. It is not like there is a released version that already
gives the advice (possibly with some other option to turn it off)
and you are changing the behaviour of "checkout" by suddenly making
it honor statusHints advice.
So let's do a lot simpler patch instead.
-- >8 --
From: Jeff King <peff@peff.net>
Date: Mon, 3 Dec 2012 01:16:57 -0500
If the user has unset advice.statusHints, we already
suppress the "use git reset to..." hints in each stanza. The
new "use git push to publish..." hint is the same type of
hint. Let's respect statusHints for it, rather than making
the user set yet another advice flag.
Signed-off-by: Jeff King <peff@peff.net>
Acked-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
remote.c | 15 +++++++++------
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/remote.c b/remote.c
index 9c19689..18dc8ec 100644
--- a/remote.c
+++ b/remote.c
@@ -1633,8 +1633,9 @@ int format_tracking_info(struct branch *branch, struct strbuf *sb)
"Your branch is ahead of '%s' by %d commits.\n",
num_ours),
base, num_ours);
- strbuf_addf(sb,
- _(" (use \"git push\" to publish your local commits)\n"));
+ if (advice_status_hints)
+ strbuf_addf(sb,
+ _(" (use \"git push\" to publish your local commits)\n"));
} else if (!num_ours) {
strbuf_addf(sb,
Q_("Your branch is behind '%s' by %d commit, "
@@ -1643,8 +1644,9 @@ int format_tracking_info(struct branch *branch, struct strbuf *sb)
"and can be fast-forwarded.\n",
num_theirs),
base, num_theirs);
- strbuf_addf(sb,
- _(" (use \"git pull\" to update your local branch)\n"));
+ if (advice_status_hints)
+ strbuf_addf(sb,
+ _(" (use \"git pull\" to update your local branch)\n"));
} else {
strbuf_addf(sb,
Q_("Your branch and '%s' have diverged,\n"
@@ -1655,8 +1657,9 @@ int format_tracking_info(struct branch *branch, struct strbuf *sb)
"respectively.\n",
num_theirs),
base, num_ours, num_theirs);
- strbuf_addf(sb,
- _(" (use \"git pull\" to merge the remote branch into yours)\n"));
+ if (advice_status_hints)
+ strbuf_addf(sb,
+ _(" (use \"git pull\" to merge the remote branch into yours)\n"));
}
return 1;
}
--
1.8.0.1.420.g52a5207
^ permalink raw reply related
* Re: [RFC] Add basic syntax check on shell scripts
From: Junio C Hamano @ 2012-12-03 16:56 UTC (permalink / raw)
To: Torsten Bögershausen; +Cc: git
In-Reply-To: <201212021417.25525.tboegi@web.de>
Torsten Bögershausen <tboegi@web.de> writes:
> The test suite needs to be run on different platforms.
> As it may be difficult for contributors to catch syntax
> which work on GNU/linux, but is unportable, make a quick check
> for the most common problems.
> "sed -i", "echo -n" or "array in shell scripts"
> This list is not complete, and may need to be extended
>
> Signed-off-by: Torsten Bögershausen <tboegi@web.de>
> ---
> We add 1 second test execution time
> Is this a useful idea at all?
Please do not name it after t/t[0-9]*.sh pattern, which are about
testing git.
This (once it gets cleaned up to reduce false positives) belongs to
"cd t && make test-lint".
>
> t/t99999-syntax-check.sh | 28 ++++++++++++++++++++++++++++
> 1 file changed, 28 insertions(+)
> create mode 100755 t/t99999-syntax-check.sh
>
> diff --git a/t/t99999-syntax-check.sh b/t/t99999-syntax-check.sh
> new file mode 100755
> index 0000000..c4a9289
> --- /dev/null
> +++ b/t/t99999-syntax-check.sh
> @@ -0,0 +1,28 @@
> +#!/bin/sh
> +
> +test_description='Basic check if shell syntax is portable'
> +
> +. ./test-lib.sh
> +
> +
> +test_expect_success 'No arrays in shell scripts' '
> + >expected &&
> + (grep -i -n "^[ ]*declare[ ][ ]*" ../*.sh ../../git-* >actual 2>&1 || : ) &&
> + test_cmp expected actual &&
> + rm expected actual
> +'
> +
> +test_expect_success 'No sed -i' '
> + >expected &&
> + (grep -n "^[ ]*sed[ ][ ]*\-i" ../*.sh ../../git-* >actual 2>&1 || : ) &&
> + test_cmp expected actual &&
> + rm expected actual
> +'
> +
> +test_expect_success 'No echo -n' '
> + >expected &&
> + (grep -n "^[ ]*echo[ ][ ]*\-n" ../*.sh ../../git-* >actual 2>&1 || : ) &&
> + test_cmp expected actual &&
> + rm expected actual
> +'
> +test_done
^ permalink raw reply
* Re: [PATCH] t9402: sed -i is not portable
From: Junio C Hamano @ 2012-12-03 16:53 UTC (permalink / raw)
To: Torsten Bögershausen; +Cc: git, mmogilvi_git
In-Reply-To: <201212021322.45418.tboegi@web.de>
Torsten Bögershausen <tboegi@web.de> writes:
> On some systems sed allows the usage of e.g.
> sed -i -e "s/line1/line2/" afile
> to edit the file "in place".
> Other systems don't allow that: one observed behaviour is that
> sed -i -e "s/line1/line2/" afile
> creates a backup file called afile-e, which breaks the test.
> As sed -i is not part of POSIX, avoid it.
>
> Use test_cmp, makes the test easier to debug.
> Chain all shell commands with && to detect all kinds of failure.
> While at it, Use TAB to indent.
>
> Signed-off-by: Torsten Bögershausen <tboegi@web.de>
> ---
> Note: this should go on top of pu
>
> t/t9402-git-cvsserver-refs.sh | 764 +++++++++++++++++++++---------------------
> 1 file changed, 383 insertions(+), 381 deletions(-)
>
> diff --git a/t/t9402-git-cvsserver-refs.sh b/t/t9402-git-cvsserver-refs.sh
> index 858ef0f..39c6b01 100755
> --- a/t/t9402-git-cvsserver-refs.sh
> +++ b/t/t9402-git-cvsserver-refs.sh
> @@ -10,59 +10,58 @@ tags, branches and other git refspecs'
> #########
>
> check_start_tree() {
> - rm -f "$WORKDIR/check.list"
> - echo "start $1" >> "${WORKDIR}/check.log"
> + rm -f "$WORKDIR/check.list"
> + echo "start $1" >> "${WORKDIR}/check.log"
I think the indentation is broken throughout the patch. Why two
tabs at the beginning?
Please do not do many unrelated things at once in a commit, as it
makes the changes unnecessarily noisy for reviewing. When a
reviewer wants to concentrate on formatting, changes to other text
become distracting. When a reviewer wants to concentrate on the
logic of replacing "sed -i" with a temporary file, formatting
changes become distracting.
If you want to fix "sed -i", do that and only that in one patch. If
you want to fix indentation and other style fixes (which is a good
thing to do), do that and only that in a separate patch, either
before or after the main patch.
Thanks.
> }
>
> check_file() {
> - sandbox="$1"
> - file="$2"
> - ver="$3"
> - GIT_DIR=$SERVERDIR git show "${ver}:${file}" \
> + sandbox="$1"
> + file="$2"
> + ver="$3"
> + GIT_DIR=$SERVERDIR git show "${ver}:${file}" \
> > "$WORKDIR/check.got" 2> "$WORKDIR/check.stderr"
> - test_cmp "$WORKDIR/check.got" "$sandbox/$file"
> - stat=$?
> - echo "check_file $sandbox $file $ver : $stat" >> "$WORKDIR/check.log"
> - echo "$file" >> "$WORKDIR/check.list"
> - return $stat
> + test_cmp "$WORKDIR/check.got" "$sandbox/$file"
> + stat=$?
> + echo "check_file $sandbox $file $ver : $stat" >> "$WORKDIR/check.log"
> + echo "$file" >> "$WORKDIR/check.list"
> + return $stat
> }
>
> check_end_tree() {
> - sandbox="$1"
> - expectCount=$(wc -l < "$WORKDIR/check.list")
> - cvsCount=$(find "$sandbox" -name CVS -prune -o -type f -print | wc -l)
> - test x"$cvsCount" = x"$expectCount"
> - stat=$?
> - echo "check_end $sandbox : $stat cvs=$cvsCount expect=$expectCount" \
> - >> "$WORKDIR/check.log"
> - return $stat
> + sandbox="$1" &&
> + wc -l < "$WORKDIR/check.list" > expected &&
> + find "$sandbox" -type f | grep -v "/CVS" > "$WORKDIR/check.cvsCount" &&
> + wc -l < "$WORKDIR/check.cvsCount" >actual &&
> + test_cmp expected actual &&
> + rm expected actual &&
> + sort < "$WORKDIR/check.list" > expected &&
> + sort < "$WORKDIR/check.cvsCount" | sed -e "s%cvswork/%%" >actual &&
> + test_cmp expected actual &&
> + rm expected actual
> }
>
> check_end_full_tree() {
> - sandbox="$1"
> - ver="$2"
> - expectCount=$(wc -l < "$WORKDIR/check.list")
> - cvsCount=$(find "$sandbox" -name CVS -prune -o -type f -print | wc -l)
> - gitCount=$(git ls-tree -r "$2" | wc -l)
> - test x"$cvsCount" = x"$expectCount" -a x"$gitCount" = x"$expectCount"
> - stat=$?
> - echo "check_end $sandbox : $stat cvs=$cvsCount git=$gitCount expect=$expectCount" \
> - >> "$WORKDIR/check.log"
> - return $stat
> + sandbox="$1" &&
> + sort < "$WORKDIR/check.list" >expected &&
> + find "$sandbox" -name CVS -prune -o -type f -print | sed -e "s%$sandbox/%%" | sort >act1 &&
> + test_cmp expected act1 &&
> + git ls-tree -r "$2" | sed -e "s/^.*blob [0-9a-fA-F]*[ ]*//" | sort > act2 &&
> + test_cmp expected act2 &&
> + rm expected act1 act2
> }
>
> #########
>
> check_diff() {
> - diffFile="$1"
> - vOld="$2"
> - vNew="$3"
> - rm -rf diffSandbox
> - git clone -q -n . diffSandbox &&
> - ( cd diffSandbox &&
> - git checkout "$vOld" &&
> - git apply -p0 --index <"../$diffFile" &&
> - git diff --exit-code "$vNew" ) > check_diff_apply.out 2>&1
> + diffFile="$1"
> + vOld="$2"
> + vNew="$3"
> + rm -rf diffSandbox
> + git clone -q -n . diffSandbox &&
> + ( cd diffSandbox &&
> + git checkout "$vOld" &&
> + git apply -p0 --index <"../$diffFile" &&
> + git diff --exit-code "$vNew" ) > check_diff_apply.out 2>&1
> }
>
> #########
> @@ -70,17 +69,17 @@ check_diff() {
> cvs >/dev/null 2>&1
> if test $? -ne 1
> then
> - skip_all='skipping git-cvsserver tests, cvs not found'
> - test_done
> + skip_all='skipping git-cvsserver tests, cvs not found'
> + test_done
> fi
> if ! test_have_prereq PERL
> then
> - skip_all='skipping git-cvsserver tests, perl not available'
> - test_done
> + skip_all='skipping git-cvsserver tests, perl not available'
> + test_done
> fi
> "$PERL_PATH" -e 'use DBI; use DBD::SQLite' >/dev/null 2>&1 || {
> - skip_all='skipping git-cvsserver tests, Perl SQLite interface unavailable'
> - test_done
> + skip_all='skipping git-cvsserver tests, Perl SQLite interface unavailable'
> + test_done
> }
>
> unset GIT_DIR GIT_CONFIG
> @@ -94,465 +93,468 @@ export CVSROOT CVS_SERVER
>
> rm -rf "$CVSWORK" "$SERVERDIR"
> test_expect_success 'setup v1, b1' '
> - echo "Simple text file" > textfile.c &&
> - echo "t2" > t2 &&
> - mkdir adir &&
> - echo "adir/afile line1" > adir/afile &&
> - echo "adir/afile line2" >> adir/afile &&
> - echo "adir/afile line3" >> adir/afile &&
> - echo "adir/afile line4" >> adir/afile &&
> - echo "adir/a2file" >> adir/a2file &&
> - mkdir adir/bdir &&
> - echo "adir/bdir/bfile line 1" > adir/bdir/bfile &&
> - echo "adir/bdir/bfile line 2" >> adir/bdir/bfile &&
> - echo "adir/bdir/b2file" > adir/bdir/b2file &&
> - git add textfile.c t2 adir &&
> - git commit -q -m "First Commit (v1)" &&
> - git tag v1 &&
> - git branch b1 &&
> - git clone -q --bare "$WORKDIR/.git" "$SERVERDIR" >/dev/null 2>&1 &&
> - GIT_DIR="$SERVERDIR" git config --bool gitcvs.enabled true &&
> - GIT_DIR="$SERVERDIR" git config gitcvs.logfile "$SERVERDIR/gitcvs.log"
> + echo "Simple text file" > textfile.c &&
> + echo "t2" > t2 &&
> + mkdir adir &&
> + echo "adir/afile line1" > adir/afile &&
> + echo "adir/afile line2" >> adir/afile &&
> + echo "adir/afile line3" >> adir/afile &&
> + echo "adir/afile line4" >> adir/afile &&
> + echo "adir/a2file" >> adir/a2file &&
> + mkdir adir/bdir &&
> + echo "adir/bdir/bfile line 1" > adir/bdir/bfile &&
> + echo "adir/bdir/bfile line 2" >> adir/bdir/bfile &&
> + echo "adir/bdir/b2file" > adir/bdir/b2file &&
> + git add textfile.c t2 adir &&
> + git commit -q -m "First Commit (v1)" &&
> + git tag v1 &&
> + git branch b1 &&
> + git clone -q --bare "$WORKDIR/.git" "$SERVERDIR" >/dev/null 2>&1 &&
> + GIT_DIR="$SERVERDIR" git config --bool gitcvs.enabled true &&
> + GIT_DIR="$SERVERDIR" git config gitcvs.logfile "$SERVERDIR/gitcvs.log"
> '
>
> rm -rf cvswork
> test_expect_success 'cvs co v1' '
> - cvs -f -Q co -r v1 -d cvswork master >cvs.log 2>&1 &&
> - check_start_tree cvswork &&
> - check_file cvswork textfile.c v1 &&
> - check_file cvswork t2 v1 &&
> - check_file cvswork adir/afile v1 &&
> - check_file cvswork adir/a2file v1 &&
> - check_file cvswork adir/bdir/bfile v1 &&
> - check_file cvswork adir/bdir/b2file v1 &&
> - check_end_tree cvswork
> + cvs -f -Q co -r v1 -d cvswork master >cvs.log 2>&1 &&
> + check_start_tree cvswork &&
> + check_file cvswork textfile.c v1 &&
> + check_file cvswork t2 v1 &&
> + check_file cvswork adir/afile v1 &&
> + check_file cvswork adir/a2file v1 &&
> + check_file cvswork adir/bdir/bfile v1 &&
> + check_file cvswork adir/bdir/b2file v1 &&
> + check_end_tree cvswork
> '
>
> rm -rf cvswork
> test_expect_success 'cvs co b1' '
> - cvs -f co -r b1 -d cvswork master >cvs.log 2>&1 &&
> - check_start_tree cvswork &&
> - check_file cvswork textfile.c v1 &&
> - check_file cvswork t2 v1 &&
> - check_file cvswork adir/afile v1 &&
> - check_file cvswork adir/a2file v1 &&
> - check_file cvswork adir/bdir/bfile v1 &&
> - check_file cvswork adir/bdir/b2file v1 &&
> - check_end_tree cvswork
> + cvs -f co -r b1 -d cvswork master >cvs.log 2>&1 &&
> + check_start_tree cvswork &&
> + check_file cvswork textfile.c v1 &&
> + check_file cvswork t2 v1 &&
> + check_file cvswork adir/afile v1 &&
> + check_file cvswork adir/a2file v1 &&
> + check_file cvswork adir/bdir/bfile v1 &&
> + check_file cvswork adir/bdir/b2file v1 &&
> + check_end_tree cvswork
> '
>
> test_expect_success 'cvs co b1 [cvswork3]' '
> - cvs -f co -r b1 -d cvswork3 master >cvs.log 2>&1 &&
> - check_start_tree cvswork3 &&
> - check_file cvswork3 textfile.c v1 &&
> - check_file cvswork3 t2 v1 &&
> - check_file cvswork3 adir/afile v1 &&
> - check_file cvswork3 adir/a2file v1 &&
> - check_file cvswork3 adir/bdir/bfile v1 &&
> - check_file cvswork3 adir/bdir/b2file v1 &&
> - check_end_full_tree cvswork3 v1
> + cvs -f co -r b1 -d cvswork3 master >cvs.log 2>&1 &&
> + check_start_tree cvswork3 &&
> + check_file cvswork3 textfile.c v1 &&
> + check_file cvswork3 t2 v1 &&
> + check_file cvswork3 adir/afile v1 &&
> + check_file cvswork3 adir/a2file v1 &&
> + check_file cvswork3 adir/bdir/bfile v1 &&
> + check_file cvswork3 adir/bdir/b2file v1 &&
> + check_end_full_tree cvswork3 v1
> '
>
> test_expect_success 'edit cvswork3 and save diff' '
> - ( cd cvswork3 &&
> - sed -i -e "s/line1/line1 - data/" adir/afile &&
> - echo "afile5" > adir/afile5 &&
> - rm t2 &&
> - cvs -f add adir/afile5 &&
> - cvs -f rm t2 &&
> - test_must_fail cvs -f diff -N -u >"$WORKDIR/cvswork3edit.diff"
> - )
> + ( cd cvswork3 &&
> + sed -e "s/line1/line1 - data/" adir/afile >adir/afileNEW &&
> + mv -f adir/afileNEW adir/afile &&
> + echo "afile5" > adir/afile5 &&
> + rm t2 &&
> + cvs -f add adir/afile5 &&
> + cvs -f rm t2 &&
> + test_must_fail cvs -f diff -N -u >"$WORKDIR/cvswork3edit.diff"
> + )
> '
>
> test_expect_success 'setup v1.2 on b1' '
> - git checkout b1 &&
> - echo "new v1.2" > t3 &&
> - rm t2 &&
> - sed -i -e "s/line3/line3 - more data/" adir/afile &&
> - rm adir/a2file &&
> - echo "a3file" >> adir/a3file &&
> - echo "bfile line 3" >> adir/bdir/bfile &&
> - rm adir/bdir/b2file &&
> - echo "b3file" > adir/bdir/b3file &&
> - mkdir cdir &&
> - echo "cdir/cfile" > cdir/cfile &&
> - git add -A cdir adir t3 t2 &&
> - git commit -q -m 'v1.2' &&
> - git tag v1.2 &&
> - git push --tags gitcvs.git b1:b1
> + git checkout b1 &&
> + echo "new v1.2" > t3 &&
> + rm t2 &&
> + sed -e "s/line3/line3 - more data/" adir/afile >adir/afileNEW &&
> + mv -f adir/afileNEW adir/afile &&
> + rm adir/a2file &&
> + echo "a3file" >> adir/a3file &&
> + echo "bfile line 3" >> adir/bdir/bfile &&
> + rm adir/bdir/b2file &&
> + echo "b3file" > adir/bdir/b3file &&
> + mkdir cdir &&
> + echo "cdir/cfile" > cdir/cfile &&
> + git add -A cdir adir t3 t2 &&
> + git commit -q -m 'v1.2' &&
> + git tag v1.2 &&
> + git push --tags gitcvs.git b1:b1
> '
>
> test_expect_success 'cvs -f up (on b1 adir)' '
> - ( cd cvswork/adir &&
> - cvs -f up -d ) >cvs.log 2>&1 &&
> - check_start_tree cvswork &&
> - check_file cvswork textfile.c v1 &&
> - check_file cvswork t2 v1 &&
> - check_file cvswork adir/afile v1.2 &&
> - check_file cvswork adir/a3file v1.2 &&
> - check_file cvswork adir/bdir/bfile v1.2 &&
> - check_file cvswork adir/bdir/b3file v1.2 &&
> - check_end_tree cvswork
> + ( cd cvswork/adir &&
> + cvs -f up -d ) >cvs.log 2>&1 &&
> + check_start_tree cvswork &&
> + check_file cvswork textfile.c v1 &&
> + check_file cvswork t2 v1 &&
> + check_file cvswork adir/afile v1.2 &&
> + check_file cvswork adir/a3file v1.2 &&
> + check_file cvswork adir/bdir/bfile v1.2 &&
> + check_file cvswork adir/bdir/b3file v1.2 &&
> + check_end_tree cvswork
> '
>
> test_expect_success 'cvs up (on b1 /)' '
> - ( cd cvswork &&
> - cvs -f up -d ) >cvs.log 2>&1 &&
> - check_start_tree cvswork &&
> - check_file cvswork textfile.c v1.2 &&
> - check_file cvswork t3 v1.2 &&
> - check_file cvswork adir/afile v1.2 &&
> - check_file cvswork adir/a3file v1.2 &&
> - check_file cvswork adir/bdir/bfile v1.2 &&
> - check_file cvswork adir/bdir/b3file v1.2 &&
> - check_file cvswork cdir/cfile v1.2 &&
> - check_end_tree cvswork
> + ( cd cvswork &&
> + cvs -f up -d ) >cvs.log 2>&1 &&
> + check_start_tree cvswork &&
> + check_file cvswork textfile.c v1.2 &&
> + check_file cvswork t3 v1.2 &&
> + check_file cvswork adir/afile v1.2 &&
> + check_file cvswork adir/a3file v1.2 &&
> + check_file cvswork adir/bdir/bfile v1.2 &&
> + check_file cvswork adir/bdir/b3file v1.2 &&
> + check_file cvswork cdir/cfile v1.2 &&
> + check_end_tree cvswork
> '
>
> # Make sure "CVS/Tag" files didn't get messed up:
> test_expect_success 'cvs up (on b1 /) (again; check CVS/Tag files)' '
> - ( cd cvswork &&
> - cvs -f up -d ) >cvs.log 2>&1 &&
> - check_start_tree cvswork &&
> - check_file cvswork textfile.c v1.2 &&
> - check_file cvswork t3 v1.2 &&
> - check_file cvswork adir/afile v1.2 &&
> - check_file cvswork adir/a3file v1.2 &&
> - check_file cvswork adir/bdir/bfile v1.2 &&
> - check_file cvswork adir/bdir/b3file v1.2 &&
> - check_file cvswork cdir/cfile v1.2 &&
> - check_end_tree cvswork
> + ( cd cvswork &&
> + cvs -f up -d ) >cvs.log 2>&1 &&
> + check_start_tree cvswork &&
> + check_file cvswork textfile.c v1.2 &&
> + check_file cvswork t3 v1.2 &&
> + check_file cvswork adir/afile v1.2 &&
> + check_file cvswork adir/a3file v1.2 &&
> + check_file cvswork adir/bdir/bfile v1.2 &&
> + check_file cvswork adir/bdir/b3file v1.2 &&
> + check_file cvswork cdir/cfile v1.2 &&
> + check_end_tree cvswork
> '
>
> # update to another version:
> test_expect_success 'cvs up -r v1' '
> - ( cd cvswork &&
> - cvs -f up -r v1 ) >cvs.log 2>&1 &&
> - check_start_tree cvswork &&
> - check_file cvswork textfile.c v1 &&
> - check_file cvswork t2 v1 &&
> - check_file cvswork adir/afile v1 &&
> - check_file cvswork adir/a2file v1 &&
> - check_file cvswork adir/bdir/bfile v1 &&
> - check_file cvswork adir/bdir/b2file v1 &&
> - check_end_tree cvswork
> + ( cd cvswork &&
> + cvs -f up -r v1 ) >cvs.log 2>&1 &&
> + check_start_tree cvswork &&
> + check_file cvswork textfile.c v1 &&
> + check_file cvswork t2 v1 &&
> + check_file cvswork adir/afile v1 &&
> + check_file cvswork adir/a2file v1 &&
> + check_file cvswork adir/bdir/bfile v1 &&
> + check_file cvswork adir/bdir/b2file v1 &&
> + check_end_tree cvswork
> '
>
> test_expect_success 'cvs up' '
> - ( cd cvswork &&
> - cvs -f up ) >cvs.log 2>&1 &&
> - check_start_tree cvswork &&
> - check_file cvswork textfile.c v1 &&
> - check_file cvswork t2 v1 &&
> - check_file cvswork adir/afile v1 &&
> - check_file cvswork adir/a2file v1 &&
> - check_file cvswork adir/bdir/bfile v1 &&
> - check_file cvswork adir/bdir/b2file v1 &&
> - check_end_tree cvswork
> + ( cd cvswork &&
> + cvs -f up ) >cvs.log 2>&1 &&
> + check_start_tree cvswork &&
> + check_file cvswork textfile.c v1 &&
> + check_file cvswork t2 v1 &&
> + check_file cvswork adir/afile v1 &&
> + check_file cvswork adir/a2file v1 &&
> + check_file cvswork adir/bdir/bfile v1 &&
> + check_file cvswork adir/bdir/b2file v1 &&
> + check_end_tree cvswork
> '
>
> test_expect_success 'cvs up (again; check CVS/Tag files)' '
> - ( cd cvswork &&
> - cvs -f up -d ) >cvs.log 2>&1 &&
> - check_start_tree cvswork &&
> - check_file cvswork textfile.c v1 &&
> - check_file cvswork t2 v1 &&
> - check_file cvswork adir/afile v1 &&
> - check_file cvswork adir/a2file v1 &&
> - check_file cvswork adir/bdir/bfile v1 &&
> - check_file cvswork adir/bdir/b2file v1 &&
> - check_end_tree cvswork
> + ( cd cvswork &&
> + cvs -f up -d ) >cvs.log 2>&1 &&
> + check_start_tree cvswork &&
> + check_file cvswork textfile.c v1 &&
> + check_file cvswork t2 v1 &&
> + check_file cvswork adir/afile v1 &&
> + check_file cvswork adir/a2file v1 &&
> + check_file cvswork adir/bdir/bfile v1 &&
> + check_file cvswork adir/bdir/b2file v1 &&
> + check_end_tree cvswork
> '
>
> test_expect_success 'setup simple b2' '
> - git branch b2 v1 &&
> - git push --tags gitcvs.git b2:b2
> + git branch b2 v1 &&
> + git push --tags gitcvs.git b2:b2
> '
>
> test_expect_success 'cvs co b2 [into cvswork2]' '
> - cvs -f co -r b2 -d cvswork2 master >cvs.log 2>&1 &&
> - check_start_tree cvswork &&
> - check_file cvswork textfile.c v1 &&
> - check_file cvswork t2 v1 &&
> - check_file cvswork adir/afile v1 &&
> - check_file cvswork adir/a2file v1 &&
> - check_file cvswork adir/bdir/bfile v1 &&
> - check_file cvswork adir/bdir/b2file v1 &&
> - check_end_tree cvswork
> + cvs -f co -r b2 -d cvswork2 master >cvs.log 2>&1 &&
> + check_start_tree cvswork &&
> + check_file cvswork textfile.c v1 &&
> + check_file cvswork t2 v1 &&
> + check_file cvswork adir/afile v1 &&
> + check_file cvswork adir/a2file v1 &&
> + check_file cvswork adir/bdir/bfile v1 &&
> + check_file cvswork adir/bdir/b2file v1 &&
> + check_end_tree cvswork
> '
>
> test_expect_success 'root dir edit [cvswork2]' '
> - ( cd cvswork2 &&
> - echo "Line 2" >> textfile.c &&
> - test_must_fail cvs -f diff -u >"$WORKDIR/cvsEdit1.diff" &&
> - cvs -f commit -m "edit textfile.c" textfile.c
> - ) >cvsEdit1.log 2>&1
> + ( cd cvswork2 &&
> + echo "Line 2" >> textfile.c &&
> + test_must_fail cvs -f diff -u >"$WORKDIR/cvsEdit1.diff" &&
> + cvs -f commit -m "edit textfile.c" textfile.c
> + ) >cvsEdit1.log 2>&1
> '
>
> test_expect_success 'root dir rm file [cvswork2]' '
> - ( cd cvswork2 &&
> - cvs -f rm -f t2 &&
> - cvs -f diff -u > ../cvsEdit2-empty.diff &&
> - test_must_fail cvs -f diff -N -u >"$WORKDIR/cvsEdit2-N.diff" &&
> - cvs -f commit -m "rm t2"
> - ) > cvsEdit2.log 2>&1
> + ( cd cvswork2 &&
> + cvs -f rm -f t2 &&
> + cvs -f diff -u > ../cvsEdit2-empty.diff &&
> + test_must_fail cvs -f diff -N -u >"$WORKDIR/cvsEdit2-N.diff" &&
> + cvs -f commit -m "rm t2"
> + ) > cvsEdit2.log 2>&1
> '
>
> test_expect_success 'subdir edit/add/rm files [cvswork2' '
> - ( cd cvswork2 &&
> - sed -i -e "s/line 1/line 1 (v2)/" adir/bdir/bfile &&
> - rm adir/bdir/b2file &&
> - cd adir &&
> - cvs -f rm bdir/b2file &&
> - echo "4th file" > bdir/b4file &&
> - cvs -f add bdir/b4file &&
> - test_must_fail cvs -f diff -N -u >"$WORKDIR/cvsEdit3.diff" &&
> - git fetch gitcvs.git b2:b2 &&
> - ( cd .. &&
> + ( cd cvswork2 &&
> + sed -e "s/line 1/line 1 (v2)/" adir/bdir/bfile >adir/bdir/bfileNEW &&
> + mv -f adir/bdir/bfileNEW adir/bdir/bfile &&
> + rm adir/bdir/b2file &&
> + cd adir &&
> + cvs -f rm bdir/b2file &&
> + echo "4th file" > bdir/b4file &&
> + cvs -f add bdir/b4file &&
> + test_must_fail cvs -f diff -N -u >"$WORKDIR/cvsEdit3.diff" &&
> + git fetch gitcvs.git b2:b2 &&
> + ( cd .. &&
> test_must_fail cvs -f diff -u -N -r v1.2 >"$WORKDIR/cvsEdit3-v1.2.diff" &&
> test_must_fail cvs -f diff -u -N -r v1.2 -r v1 >"$WORKDIR/cvsEdit3-v1.2-v1.diff"
> - ) &&
> - cvs -f commit -m "various add/rm/edit"
> - ) >cvs.log 2>&1
> + ) &&
> + cvs -f commit -m "various add/rm/edit"
> + ) >cvs.log 2>&1
> '
>
> test_expect_success 'validate result of edits [cvswork2]' '
> - git fetch gitcvs.git b2:b2 &&
> - git tag v2 b2 &&
> - git push --tags gitcvs.git b2:b2 &&
> - check_start_tree cvswork2 &&
> - check_file cvswork2 textfile.c v2 &&
> - check_file cvswork2 adir/afile v2 &&
> - check_file cvswork2 adir/a2file v2 &&
> - check_file cvswork2 adir/bdir/bfile v2 &&
> - check_file cvswork2 adir/bdir/b4file v2 &&
> - check_end_full_tree cvswork2 v2
> + git fetch gitcvs.git b2:b2 &&
> + git tag v2 b2 &&
> + git push --tags gitcvs.git b2:b2 &&
> + check_start_tree cvswork2 &&
> + check_file cvswork2 textfile.c v2 &&
> + check_file cvswork2 adir/afile v2 &&
> + check_file cvswork2 adir/a2file v2 &&
> + check_file cvswork2 adir/bdir/bfile v2 &&
> + check_file cvswork2 adir/bdir/b4file v2 &&
> + check_end_full_tree cvswork2 v2
> '
>
> test_expect_success 'validate basic diffs saved during above cvswork2 edits' '
> - test $(grep Index: cvsEdit1.diff | wc -l) = 1 &&
> - test ! -s cvsEdit2-empty.diff &&
> - test $(grep Index: cvsEdit2-N.diff | wc -l) = 1 &&
> - test $(grep Index: cvsEdit3.diff | wc -l) = 3 &&
> - rm -rf diffSandbox &&
> - git clone -q -n . diffSandbox &&
> - ( cd diffSandbox &&
> - git checkout v1 &&
> - git apply -p0 --index <"$WORKDIR/cvsEdit1.diff" &&
> - git apply -p0 --index <"$WORKDIR/cvsEdit2-N.diff" &&
> - git apply -p0 --directory=adir --index <"$WORKDIR/cvsEdit3.diff" &&
> - git diff --exit-code v2 ) >"check_diff_apply.out" 2>&1
> + test $(grep Index: cvsEdit1.diff | wc -l) = 1 &&
> + test ! -s cvsEdit2-empty.diff &&
> + test $(grep Index: cvsEdit2-N.diff | wc -l) = 1 &&
> + test $(grep Index: cvsEdit3.diff | wc -l) = 3 &&
> + rm -rf diffSandbox &&
> + git clone -q -n . diffSandbox &&
> + ( cd diffSandbox &&
> + git checkout v1 &&
> + git apply -p0 --index <"$WORKDIR/cvsEdit1.diff" &&
> + git apply -p0 --index <"$WORKDIR/cvsEdit2-N.diff" &&
> + git apply -p0 --directory=adir --index <"$WORKDIR/cvsEdit3.diff" &&
> + git diff --exit-code v2 ) >"check_diff_apply.out" 2>&1
> '
>
> test_expect_success 'validate v1.2 diff saved during last cvswork2 edit' '
> - test $(grep Index: cvsEdit3-v1.2.diff | wc -l) = 9 &&
> - check_diff cvsEdit3-v1.2.diff v1.2 v2
> + test $(grep Index: cvsEdit3-v1.2.diff | wc -l) = 9 &&
> + check_diff cvsEdit3-v1.2.diff v1.2 v2
> '
>
> test_expect_success 'validate v1.2 v1 diff saved during last cvswork2 edit' '
> - test $(grep Index: cvsEdit3-v1.2-v1.diff | wc -l) = 9 &&
> - check_diff cvsEdit3-v1.2-v1.diff v1.2 v1
> + test $(grep Index: cvsEdit3-v1.2-v1.diff | wc -l) = 9 &&
> + check_diff cvsEdit3-v1.2-v1.diff v1.2 v1
> '
>
> test_expect_success 'cvs up [cvswork2]' '
> - ( cd cvswork2 &&
> - cvs -f up ) >cvs.log 2>&1 &&
> - check_start_tree cvswork2 &&
> - check_file cvswork2 textfile.c v2 &&
> - check_file cvswork2 adir/afile v2 &&
> - check_file cvswork2 adir/a2file v2 &&
> - check_file cvswork2 adir/bdir/bfile v2 &&
> - check_file cvswork2 adir/bdir/b4file v2 &&
> - check_end_full_tree cvswork2 v2
> + ( cd cvswork2 &&
> + cvs -f up ) >cvs.log 2>&1 &&
> + check_start_tree cvswork2 &&
> + check_file cvswork2 textfile.c v2 &&
> + check_file cvswork2 adir/afile v2 &&
> + check_file cvswork2 adir/a2file v2 &&
> + check_file cvswork2 adir/bdir/bfile v2 &&
> + check_file cvswork2 adir/bdir/b4file v2 &&
> + check_end_full_tree cvswork2 v2
> '
>
> test_expect_success 'cvs up -r b2 [back to cvswork]' '
> - ( cd cvswork &&
> - cvs -f up -r b2 ) >cvs.log 2>&1 &&
> - check_start_tree cvswork &&
> - check_file cvswork textfile.c v2 &&
> - check_file cvswork adir/afile v2 &&
> - check_file cvswork adir/a2file v2 &&
> - check_file cvswork adir/bdir/bfile v2 &&
> - check_file cvswork adir/bdir/b4file v2 &&
> - check_end_full_tree cvswork v2
> + ( cd cvswork &&
> + cvs -f up -r b2 ) >cvs.log 2>&1 &&
> + check_start_tree cvswork &&
> + check_file cvswork textfile.c v2 &&
> + check_file cvswork adir/afile v2 &&
> + check_file cvswork adir/a2file v2 &&
> + check_file cvswork adir/bdir/bfile v2 &&
> + check_file cvswork adir/bdir/b4file v2 &&
> + check_end_full_tree cvswork v2
> '
>
> test_expect_success 'cvs up -r b1' '
> - ( cd cvswork &&
> - cvs -f up -r b1 ) >cvs.log 2>&1 &&
> - check_start_tree cvswork &&
> - check_file cvswork textfile.c v1.2 &&
> - check_file cvswork t3 v1.2 &&
> - check_file cvswork adir/afile v1.2 &&
> - check_file cvswork adir/a3file v1.2 &&
> - check_file cvswork adir/bdir/bfile v1.2 &&
> - check_file cvswork adir/bdir/b3file v1.2 &&
> - check_file cvswork cdir/cfile v1.2 &&
> - check_end_full_tree cvswork v1.2
> + ( cd cvswork &&
> + cvs -f up -r b1 ) >cvs.log 2>&1 &&
> + check_start_tree cvswork &&
> + check_file cvswork textfile.c v1.2 &&
> + check_file cvswork t3 v1.2 &&
> + check_file cvswork adir/afile v1.2 &&
> + check_file cvswork adir/a3file v1.2 &&
> + check_file cvswork adir/bdir/bfile v1.2 &&
> + check_file cvswork adir/bdir/b3file v1.2 &&
> + check_file cvswork cdir/cfile v1.2 &&
> + check_end_full_tree cvswork v1.2
> '
>
> test_expect_success 'cvs up -A' '
> - ( cd cvswork &&
> - cvs -f up -A ) >cvs.log 2>&1 &&
> - check_start_tree cvswork &&
> - check_file cvswork textfile.c v1 &&
> - check_file cvswork t2 v1 &&
> - check_file cvswork adir/afile v1 &&
> - check_file cvswork adir/a2file v1 &&
> - check_file cvswork adir/bdir/bfile v1 &&
> - check_file cvswork adir/bdir/b2file v1 &&
> - check_end_full_tree cvswork v1
> + ( cd cvswork &&
> + cvs -f up -A ) >cvs.log 2>&1 &&
> + check_start_tree cvswork &&
> + check_file cvswork textfile.c v1 &&
> + check_file cvswork t2 v1 &&
> + check_file cvswork adir/afile v1 &&
> + check_file cvswork adir/a2file v1 &&
> + check_file cvswork adir/bdir/bfile v1 &&
> + check_file cvswork adir/bdir/b2file v1 &&
> + check_end_full_tree cvswork v1
> '
>
> test_expect_success 'cvs up (check CVS/Tag files)' '
> - ( cd cvswork &&
> - cvs -f up ) >cvs.log 2>&1 &&
> - check_start_tree cvswork &&
> - check_file cvswork textfile.c v1 &&
> - check_file cvswork t2 v1 &&
> - check_file cvswork adir/afile v1 &&
> - check_file cvswork adir/a2file v1 &&
> - check_file cvswork adir/bdir/bfile v1 &&
> - check_file cvswork adir/bdir/b2file v1 &&
> - check_end_full_tree cvswork v1
> + ( cd cvswork &&
> + cvs -f up ) >cvs.log 2>&1 &&
> + check_start_tree cvswork &&
> + check_file cvswork textfile.c v1 &&
> + check_file cvswork t2 v1 &&
> + check_file cvswork adir/afile v1 &&
> + check_file cvswork adir/a2file v1 &&
> + check_file cvswork adir/bdir/bfile v1 &&
> + check_file cvswork adir/bdir/b2file v1 &&
> + check_end_full_tree cvswork v1
> '
>
> # This is not really legal CVS, but it seems to work anyway:
> test_expect_success 'cvs up -r heads/b1' '
> - ( cd cvswork &&
> - cvs -f up -r heads/b1 ) >cvs.log 2>&1 &&
> - check_start_tree cvswork &&
> - check_file cvswork textfile.c v1.2 &&
> - check_file cvswork t3 v1.2 &&
> - check_file cvswork adir/afile v1.2 &&
> - check_file cvswork adir/a3file v1.2 &&
> - check_file cvswork adir/bdir/bfile v1.2 &&
> - check_file cvswork adir/bdir/b3file v1.2 &&
> - check_file cvswork cdir/cfile v1.2 &&
> - check_end_full_tree cvswork v1.2
> + ( cd cvswork &&
> + cvs -f up -r heads/b1 ) >cvs.log 2>&1 &&
> + check_start_tree cvswork &&
> + check_file cvswork textfile.c v1.2 &&
> + check_file cvswork t3 v1.2 &&
> + check_file cvswork adir/afile v1.2 &&
> + check_file cvswork adir/a3file v1.2 &&
> + check_file cvswork adir/bdir/bfile v1.2 &&
> + check_file cvswork adir/bdir/b3file v1.2 &&
> + check_file cvswork cdir/cfile v1.2 &&
> + check_end_full_tree cvswork v1.2
> '
>
> # But this should work even if CVS client checks -r more carefully:
> test_expect_success 'cvs up -r heads_-s-b2 (cvsserver escape mechanism)' '
> - ( cd cvswork &&
> - cvs -f up -r heads_-s-b2 ) >cvs.log 2>&1 &&
> - check_start_tree cvswork &&
> - check_file cvswork textfile.c v2 &&
> - check_file cvswork adir/afile v2 &&
> - check_file cvswork adir/a2file v2 &&
> - check_file cvswork adir/bdir/bfile v2 &&
> - check_file cvswork adir/bdir/b4file v2 &&
> - check_end_full_tree cvswork v2
> + ( cd cvswork &&
> + cvs -f up -r heads_-s-b2 ) >cvs.log 2>&1 &&
> + check_start_tree cvswork &&
> + check_file cvswork textfile.c v2 &&
> + check_file cvswork adir/afile v2 &&
> + check_file cvswork adir/a2file v2 &&
> + check_file cvswork adir/bdir/bfile v2 &&
> + check_file cvswork adir/bdir/b4file v2 &&
> + check_end_full_tree cvswork v2
> '
>
> v1hash=$(git rev-parse v1)
> test_expect_success 'cvs up -r $(git rev-parse v1)' '
> - test -n "$v1hash" &&
> - ( cd cvswork &&
> - cvs -f up -r "$v1hash" ) >cvs.log 2>&1 &&
> - check_start_tree cvswork &&
> - check_file cvswork textfile.c v1 &&
> - check_file cvswork t2 v1 &&
> - check_file cvswork adir/afile v1 &&
> - check_file cvswork adir/a2file v1 &&
> - check_file cvswork adir/bdir/bfile v1 &&
> - check_file cvswork adir/bdir/b2file v1 &&
> - check_end_full_tree cvswork v1
> + test -n "$v1hash" &&
> + ( cd cvswork &&
> + cvs -f up -r "$v1hash" ) >cvs.log 2>&1 &&
> + check_start_tree cvswork &&
> + check_file cvswork textfile.c v1 &&
> + check_file cvswork t2 v1 &&
> + check_file cvswork adir/afile v1 &&
> + check_file cvswork adir/a2file v1 &&
> + check_file cvswork adir/bdir/bfile v1 &&
> + check_file cvswork adir/bdir/b2file v1 &&
> + check_end_full_tree cvswork v1
> '
>
> test_expect_success 'cvs diff -r v1 -u' '
> - ( cd cvswork &&
> - cvs -f diff -r v1 -u ) >cvsDiff.out 2>cvs.log &&
> - test ! -s cvsDiff.out &&
> - test ! -s cvs.log
> + ( cd cvswork &&
> + cvs -f diff -r v1 -u ) >cvsDiff.out 2>cvs.log &&
> + test ! -s cvsDiff.out &&
> + test ! -s cvs.log
> '
>
> test_expect_success 'cvs diff -N -r v2 -u' '
> - ( cd cvswork &&
> - test_must_fail cvs -f diff -N -r v2 -u ) >cvsDiff.out 2>cvs.log &&
> - test ! -s cvs.log &&
> - test -s cvsDiff.out &&
> - check_diff cvsDiff.out v2 v1 > check_diff.out 2>&1
> + ( cd cvswork &&
> + test_must_fail cvs -f diff -N -r v2 -u ) >cvsDiff.out 2>cvs.log &&
> + test ! -s cvs.log &&
> + test -s cvsDiff.out &&
> + check_diff cvsDiff.out v2 v1 > check_diff.out 2>&1
> '
>
> test_expect_success 'cvs diff -N -r v2 -r v1.2' '
> - ( cd cvswork &&
> - test_must_fail cvs -f diff -N -r v2 -r v1.2 -u ) >cvsDiff.out 2>cvs.log &&
> - test ! -s cvs.log &&
> - test -s cvsDiff.out &&
> - check_diff cvsDiff.out v2 v1.2 > check_diff.out 2>&1
> + ( cd cvswork &&
> + test_must_fail cvs -f diff -N -r v2 -r v1.2 -u ) >cvsDiff.out 2>cvs.log &&
> + test ! -s cvs.log &&
> + test -s cvsDiff.out &&
> + check_diff cvsDiff.out v2 v1.2 > check_diff.out 2>&1
> '
>
> test_expect_success 'apply early [cvswork3] diff to b3' '
> - git clone -q . gitwork3 &&
> - ( cd gitwork3 &&
> - git checkout -b b3 v1 &&
> - git apply -p0 --index <"$WORKDIR/cvswork3edit.diff" &&
> - git commit -m "cvswork3 edits applied" ) &&
> - git fetch gitwork3 b3:b3 &&
> - git tag v3 b3
> + git clone -q . gitwork3 &&
> + ( cd gitwork3 &&
> + git checkout -b b3 v1 &&
> + git apply -p0 --index <"$WORKDIR/cvswork3edit.diff" &&
> + git commit -m "cvswork3 edits applied" ) &&
> + git fetch gitwork3 b3:b3 &&
> + git tag v3 b3
> '
>
> test_expect_success 'check [cvswork3] diff' '
> - ( cd cvswork3 &&
> - test_must_fail cvs -f diff -N -u ) >"$WORKDIR/cvsDiff.out" 2>cvs.log &&
> - test ! -s cvs.log &&
> - test -s cvsDiff.out &&
> - test $(grep Index: cvsDiff.out | wc -l) = 3 &&
> - test_cmp cvsDiff.out cvswork3edit.diff &&
> - check_diff cvsDiff.out v1 v3 > check_diff.out 2>&1
> + ( cd cvswork3 &&
> + test_must_fail cvs -f diff -N -u ) >"$WORKDIR/cvsDiff.out" 2>cvs.log &&
> + test ! -s cvs.log &&
> + test -s cvsDiff.out &&
> + test $(grep Index: cvsDiff.out | wc -l) = 3 &&
> + test_cmp cvsDiff.out cvswork3edit.diff &&
> + check_diff cvsDiff.out v1 v3 > check_diff.out 2>&1
> '
>
> test_expect_success 'merge early [cvswork3] b3 with b1' '
> - ( cd gitwork3 &&
> - git merge "message" HEAD b1 )
> - git fetch gitwork3 b3:b3 &&
> - git tag v3merged b3 &&
> - git push --tags gitcvs.git b3:b3
> + ( cd gitwork3 &&
> + git merge "message" HEAD b1 )
> + git fetch gitwork3 b3:b3 &&
> + git tag v3merged b3 &&
> + git push --tags gitcvs.git b3:b3
> '
>
> # This test would fail if cvsserver properly created a ".#afile"* file
> # for the merge.
> # TODO: Validate that the .# file was saved properly, and then
> -# delete/ignore it when checking the tree.
> +# delete/ignore it when checking the tree.
> test_expect_success 'cvs up dirty [cvswork3]' '
> - ( cd cvswork3 &&
> - cvs -f up &&
> - test_must_fail cvs -f diff -N -u >"$WORKDIR/cvsDiff.out" ) >cvs.log 2>&1 &&
> - test -s cvsDiff.out &&
> - test $(grep Index: cvsDiff.out | wc -l) = 2
> - check_start_tree cvswork3 &&
> - check_file cvswork3 textfile.c v3merged &&
> - check_file cvswork3 t3 v3merged &&
> - check_file cvswork3 adir/afile v3merged &&
> - check_file cvswork3 adir/a3file v3merged &&
> - check_file cvswork3 adir/afile5 v3merged &&
> - check_file cvswork3 adir/bdir/bfile v3merged &&
> - check_file cvswork3 adir/bdir/b3file v3merged &&
> - check_file cvswork3 cdir/cfile v3merged &&
> - check_end_full_tree cvswork3 v3merged
> + ( cd cvswork3 &&
> + cvs -f up &&
> + test_must_fail cvs -f diff -N -u >"$WORKDIR/cvsDiff.out" ) >cvs.log 2>&1 &&
> + test -s cvsDiff.out &&
> + test $(grep Index: cvsDiff.out | wc -l) = 2
> + check_start_tree cvswork3 &&
> + check_file cvswork3 textfile.c v3merged &&
> + check_file cvswork3 t3 v3merged &&
> + check_file cvswork3 adir/afile v3merged &&
> + check_file cvswork3 adir/a3file v3merged &&
> + check_file cvswork3 adir/afile5 v3merged &&
> + check_file cvswork3 adir/bdir/bfile v3merged &&
> + check_file cvswork3 adir/bdir/b3file v3merged &&
> + check_file cvswork3 cdir/cfile v3merged &&
> + check_end_full_tree cvswork3 v3merged
> '
>
> # TODO: test cvs status
>
> test_expect_success 'cvs commit [cvswork3' '
> - ( cd cvswork3 &&
> - cvs -f commit -m "dirty sandbox after auto-merge"
> - ) > cvs.log 2>&1 &&
> - check_start_tree cvswork3 &&
> - check_file cvswork3 textfile.c v3merged &&
> - check_file cvswork3 t3 v3merged &&
> - check_file cvswork3 adir/afile v3merged &&
> - check_file cvswork3 adir/a3file v3merged &&
> - check_file cvswork3 adir/afile5 v3merged &&
> - check_file cvswork3 adir/bdir/bfile v3merged &&
> - check_file cvswork3 adir/bdir/b3file v3merged &&
> - check_file cvswork3 cdir/cfile v3merged &&
> - check_end_full_tree cvswork3 v3merged &&
> - git fetch gitcvs.git b3:b4 &&
> - git tag v4.1 b4 &&
> - git diff --exit-code v4.1 v3merged > check_diff_apply.out 2>&1
> + ( cd cvswork3 &&
> + cvs -f commit -m "dirty sandbox after auto-merge"
> + ) > cvs.log 2>&1 &&
> + check_start_tree cvswork3 &&
> + check_file cvswork3 textfile.c v3merged &&
> + check_file cvswork3 t3 v3merged &&
> + check_file cvswork3 adir/afile v3merged &&
> + check_file cvswork3 adir/a3file v3merged &&
> + check_file cvswork3 adir/afile5 v3merged &&
> + check_file cvswork3 adir/bdir/bfile v3merged &&
> + check_file cvswork3 adir/bdir/b3file v3merged &&
> + check_file cvswork3 cdir/cfile v3merged &&
> + check_end_full_tree cvswork3 v3merged &&
> + git fetch gitcvs.git b3:b4 &&
> + git tag v4.1 b4 &&
> + git diff --exit-code v4.1 v3merged > check_diff_apply.out 2>&1
> '
>
> test_done
^ permalink raw reply
* Re: [PATCH v6 2/4] submodule update: add --remote for submodule's upstream changes
From: Junio C Hamano @ 2012-12-03 16:46 UTC (permalink / raw)
To: W. Trevor King
Cc: Git, Heiko Voigt, Jeff King, Phil Hord, Shawn Pearce,
Jens Lehmann, Nahor
In-Reply-To: <ec5d0235322619aff6c1c64b0a346efb0e4d0a32.1354417618.git.wking@tremily.us>
"W. Trevor King" <wking@tremily.us> writes:
> From: "W. Trevor King" <wking@tremily.us>
>
> The current `update` command incorporates the superproject's gitlinked
> SHA-1 ($sha1) into the submodule HEAD ($subsha1). Depending on the
> options you use, it may checkout $sha1, rebase the $subsha1 onto
> $sha1, or merge $sha1 into $subsha1. This helps you keep up with
> changes in the upstream superproject.
>
> However, it's also useful to stay up to date with changes in the
> upstream subproject. Previous workflows for incorporating such
> changes include the ungainly:
>
> $ git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && git pull'
>
> With this patch, all of the useful functionality for incorporating
> superproject changes can be reused to incorporate upstream subproject
> updates. When you specify --remote, the target $sha1 is replaced with
> a $sha1 of the submodule's origin/master tracking branch. If you want
> to merge a different tracking branch, you can configure the
> `submodule.<name>.branch` option in `.gitmodules`. You can override
> the `.gitmodules` configuration setting for a particular superproject
> by configuring the option in that superproject's default configuration
> (using the usual configuration hierarchy, e.g. `.git/config`,
> `~/.gitconfig`, etc.).
>
> Previous use of submodule.<name>.branch
> =======================================
>
> Because we're adding a new configuration option, it's a good idea to
> check if anyone else is already using the option. The foreach-pull
> example above was described by Ævar in
>
> commit f030c96d8643fa0a1a9b2bd9c2f36a77721fb61f
> Author: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
> Date: Fri May 21 16:10:10 2010 +0000
>
> git-submodule foreach: Add $toplevel variable
>
> Gerrit uses the same interpretation for the setting, but because
> Gerrit has direct access to the subproject repositories, it updates
> the superproject repositories automatically when a subproject changes.
> Gerrit also accepts the special value '.', which it expands into the
> superproject's branch name.
>
> Although the --remote functionality is using `submodule.<name>.branch`
> slightly differently, the effect is the same. The foreach-pull
> example uses the option to record the name of the local branch to
> checkout before pulls. The tracking branch to be pulled is recorded
> in `.git/modules/<name>/config`, which was initialized by the module
> clone during `submodule add` or `submodule init`. Because the branch
> name stored in `submodule.<name>.branch` was likely the same as the
> branch name used during the initial `submodule add`, the same branch
> will be pulled in each workflow.
>
> Implementation details
> ======================
>
> In order to ensure a current tracking branch state, `update --remote`
> fetches the submodule's remote repository before calculating the
> SHA-1. However, I didn't change the logic guarding the existing fetch:
>
> if test -z "$nofetch"
> then
> # Run fetch only if $sha1 isn't present or it
> # is not reachable from a ref.
> (clear_local_git_env; cd "$path" &&
> ( (rev=$(git rev-list -n 1 $sha1 --not --all 2>/dev/null) &&
> test -z "$rev") || git-fetch)) ||
> die "$(eval_gettext "Unable to fetch in submodule path '\$path'")"
> fi
>
> There will not be a double-fetch, because the new $sha1 determined
> after the `--remote` triggered fetch should always exist in the
> repository. If it doesn't, it's because some racy process removed it
> from the submodule's repository and we *should* be re-fetching.
As you hinted in the first paragraph, you could flip between merge,
rebase, and detach with a command line option when running the
"update" subcommand, but I would imagine that the expected use
pattern is that for a particular project, you would choose one mode
and consistently stick to that mode. To make it easier, the user
can set submodule.$name.update once and run "update" without having
to give any flags.
And this is about adding another mode to the "update" subcommand
where the HEAD is not detached, nor merged, nor rebased, but is set
to follow whatever commit a remote branch points at.
Shouldn't the patch add a way for the user to set a configuration
variable to signal that this new mode is always used when "update"
is run without a command line flag?
As the user has to configure submodule.$name.branch in order to use
this mode anyway, I have a feeling that taking that as a signal, and
ignoring submodule.$name.update altogether, might be a simpler
interface from the end user's point of view. That is,
(1) if you are not interested in the submodule $name, you do not
"init" it; you "init" it for all of the following.
(2) if you want to have the tree state as recorded in the
superproject, you do "update" without any option to make the
HEAD of the submodule detached at the commit the superproject's
tree records;
(3) if you want to follow the upstream project of the submodule,
you set submodule.$name.branch to the branch you want to
follow, and you do "update"---submodule.$name.update is ignored
and you will make the HEAD of the submodule detached at the tip
of the branch at the remote (using remote-tracking branch);
(4) if you want to --merge or --rebase, you give them from the
command line, or use submodule.$name.update.
I may be oversimplifying a bit, but a separate
submodule.$name.remote feels very wrong; if it were a new token
"remote" that can be set as the value of submodule.$name.update (in
addition to existing "none", "rebase" and "merge"), it might be a
bit more understandable, though.
How does this compare with the floating submodules Heiko has been
working on?
^ permalink raw reply
* Re: [RFC] remove/deprecate 'submodule init' and 'sync'
From: W. Trevor King @ 2012-12-03 15:38 UTC (permalink / raw)
To: Jens Lehmann, Phil Hord
Cc: Git, Heiko Voigt, Junio C Hamano, Jeff King, Shawn Pearce, Nahor
In-Reply-To: <20121201165404.GD4823@odin.tremily.us>
[-- Attachment #1: Type: text/plain, Size: 3385 bytes --]
On Sun, Dec 02, 2012 at 04:11:59PM -0500, W. Trevor King wrote:
> On Sun, Dec 02, 2012 at 09:29:29PM +0100, Jens Lehmann wrote:
> > Am 01.12.2012 18:49, schrieb W. Trevor King:
> > > On Sat, Dec 01, 2012 at 06:25:17PM +0100, Jens Lehmann wrote:
> > >> What real world problems do we have with the current init/sync that
> > >> this approach would solve?
> > >
> > > I don't have any, ...
> >
> > We don't want to change working code and cause compatibility issues
> > just because we /could/ do things differently, no?
>
> In principle, yes, but in this case I think changing the
> implementation does not risk much in the way of compatibility issues
> (it only hurts users who rely on `submodule init` setting
> submodule.<name>.url for reasons of their own. A few of the existing
> tests explictly check the url setting, so perhaps there are a number
> of users who do require this side effect?
>
> I think this risk is outweighed by the benefits of having a clearer
> activation option.
For anyone interested in an implementation of my
submodule.<name>.active proposal, I've posted an initial version:
git://github.com/wking/git.git wtk/submodule.name.active
I can re-post it here as a PATCH series, but I don't think we're at
the level of patch-specific feedback yet.
I'm currently pretty happy with it except for the last commit:
HACK work around missing index entry for existing empty submodules
To solve that cleanly, I'd need a solution to the commit-less existing
repository problem which I mentioned earlier:
On Sat, Dec 01, 2012 at 11:54:04AM -0500, W. Trevor King wrote:
> I'm currently stuck with adding a commit-less existing repository as a
> submodule (which happens in t7400-submodule-basic.sh, ../bar/a/b/c
> works with relative local path):
>
> $ mkdir -p super/sub
> $ cd super
> $ git init
> $ (cd sub && git init)
> $ git submodule add ./ sub
> $ git status
> # On branch master
> #
> # Initial commit
> #
> # Changes to be committed:
> # (use "git rm --cached <file>..." to unstage)
> #
> # new file: .gitmodules
> #
>
> What I'm missing is a gitlink form sub for 'Subproject commit
> 00000...' or some such. When the subproject has an actual commit,
> things work as expected:
>
> $ mkdir -p super/sub
> $ cd super
> $ git init
> $ (cd sub && git init && echo line-1 > file && git add file && git commit -m file)
> $ git submodule add ./ sub
> $ git status
> # On branch master
> #
> # Initial commit
> #
> # Changes to be committed:
> # (use "git rm --cached <file>..." to unstage)
> #
> # new file: .gitmodules
> # new file: sub
> #
>
> This means that module_list isn't aware of the empty submodule, when
> the user has just explicitly added it. Fixing this would seem to need
> either 'Subproject commit 00000...' as I suggested earlier, or an
> adjustment to module_list that also spits out submodules that are in
> .gitmodules but not in the index.
Other than that, I think all the changes in the test suite are
logically sound and unlikely to cause problems with existing usage.
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] l10n: de.po: translate 22 new messages
From: Michael J Gruber @ 2012-12-03 15:09 UTC (permalink / raw)
To: Ralf Thielow; +Cc: trast, jk, stimming, git
In-Reply-To: <1354510146-2919-1-git-send-email-ralf.thielow@gmail.com>
Ralf Thielow venit, vidit, dixit 03.12.2012 05:49:
> Translate 22 new messages came from git.pot
> updates in 9306b5b (l10n: Update git.pot (3 new,
> 6 removed messages)), fe52cd6 (l10n: Update git.pot
> (14 new, 3 removed messages)) and f9472e3
> (l10n: Update git.pot (5 new, 1 removed messages)).
>
> Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
> ---
> po/de.po | 68 ++++++++++++++++++++++++++++++++++------------------------------
> 1 file changed, 36 insertions(+), 32 deletions(-)
>
> diff --git a/po/de.po b/po/de.po
> index a0bf3da..7350818 100644
> --- a/po/de.po
> +++ b/po/de.po
...
> #: remote.c:1659
> -#, fuzzy
> msgid " (use \"git pull\" to merge the remote branch into yours)\n"
> msgstr ""
> -" (benutze \"git am --abort\" um den ursprünglichen Zweig wiederherzustellen)"
> +" (benutze \"git pull\" um den externen Zweig mit Deinem zusammenzuführen)\n"
That sounds as if git-pull did something to the remote branch, whereas
it would do something with your local branch. Reverting the roles may help:
+" (benutze \"git pull\" um Deinen Zweig mit dem externen
zusammenzuführen)\n"
BTW: Is there a standard about capitalising or not "Deine/Du" in de.pot?
I think I've seen both here. (New spelling after the reform(s)
recommends du/deine but Sie/Ihr, me thinks.)
> #: builtin/grep.c:740
> msgid "pager"
> @@ -8029,6 +8024,9 @@ msgid ""
> "submodule '%s' (or one of its nested submodules) uses a .git directory\n"
> "(use 'rm -rf' if you really want to remove it including all of its history)"
> msgstr ""
> +"Unterprojekt '%s' (oder ein geschachteltes Unterprojekt dessen) verwendet \n"
s/dessen/hiervon/ ?
> +"ein .git-Verzeichnis (benutze 'rm -rf' wenn du dieses wirklich mit seiner\n"
> +"Historie löschen möchtest)"
s/mit/mitsamt/ ?
(to emphasize "including" like in the original and avoid "mit=by"
misinterpretation)
Michael
^ permalink raw reply
* Re: [PATCH 6/8] imap-send: change msg_data from storing (char *, len) to storing strbuf
From: Thiago Farina @ 2012-12-03 15:06 UTC (permalink / raw)
To: Junio C Hamano
Cc: Michael Haggerty, git, Jeremy White, Johannes Schindelin,
Jeff King
In-Reply-To: <7v624lns00.fsf@alter.siamese.dyndns.org>
On Sat, Dec 1, 2012 at 11:48 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> I suggest a separate patch series dedicated to deleting *all* the extra
>> imap infrastructure at once. That being said, I'm not committing to do
>> so. (We could add it to an "straightforward projects for aspiring git
>> developers" list, if we had such a thing.)
>
> A "low-hanging fruit and/or janitorial work" stack may be worth
> having.
That would be good for not so versed developers, I think. Do we have a
place for listing janitor projects?
^ permalink raw reply
* Re: [RFC/PATCH] l10n: de.po: translate 825 new messages
From: Michael J Gruber @ 2012-12-03 14:59 UTC (permalink / raw)
To: Ralf Thielow; +Cc: trast, git, git, jk, stimming
In-Reply-To: <1354510131-2881-1-git-send-email-ralf.thielow@gmail.com>
Ralf Thielow venit, vidit, dixit 03.12.2012 05:48:
> Thanks Thomas and Michael!
>
> 2012/11/30 Thomas Rast <trast@inf.ethz.ch>:
>
>>> #: builtin/update-index.c:756
>>> msgid "mark files as \"index-only\""
>>> -msgstr ""
>>> +msgstr "markiert Dateien als \"index-only\""
>>
>> Likewise, but here I don't even understand what the manpage is trying to
>> tell me, in particular I don't see how it would be different from
>> assume-unchanged. Maybe "see manpage" would be the best documentation.
>
> I'm not really sure what to do with it. In this version (see below) I kept
> it. Did you mean we should add "(siehe Hilfeseite)" or something in the
> translation, or does it belong to the original message and the translation
> would just follow?
>
I'd say the translation above is fine, and no matter what language the
user messages are in, the user would have to consult the man page for
this very special feature, but I don't think we have to say so explicitly.
>>> +"wiederholte Ausführung der Phasen #2 und #3 für die aufgelisteten Pfade"
>>
>> ISTR we settled on something for 'stage', but it's not in the glossary.
>> Either way I don't think this is it. "Ausführung der Phasen" would mean
>> that it's some part of a process, whereas the stages are a state.
>>
> I've changed it to
> "wiederholtes Einpflegen der Zustände #2 und #3 für die aufgelisteten Pfade"
> What do you think?
>
> ---
> po/de.po | 123 +++++++++++++++++++++++++++++++--------------------------------
> 1 file changed, 61 insertions(+), 62 deletions(-)
...
> #: builtin/fsck.c:620
> msgid "also consider packs and alternate objects"
> -msgstr "betrachtet auch Pakete und wechselnde Objekte"
> +msgstr ""
Oops ;)
> #: builtin/push.c:391
> msgid "check"
> -msgstr "Überprüfung"
> +msgstr ""
Is this meant to omit the text? (I may have missed the pertaining
discussion.)
> #: builtin/update-index.c:753
> msgid "clear assumed-unchanged bit"
> @@ -8568,7 +8567,7 @@ msgstr "fügt Einträge von der Standard-Eingabe der Bereitstellung hinzu"
> #: builtin/update-index.c:776
> msgid "repopulate stages #2 and #3 for the listed paths"
> msgstr ""
> -"wiederholte Ausführung der Phasen #2 und #3 für die aufgelisteten Pfade"
> +"wiederholtes Einpflegen der Zustände #2 und #3 für die aufgelisteten Pfade"
I can't seem to find the other occurence in de.po, but state should be
the same as in
"copy out the files from named stage" (checkout-index).
"Zustand" seems to be appropriate.
Cheers,
Michael
^ permalink raw reply
* Re: does a successful 'git gc' imply 'git fsck'
From: Junio C Hamano @ 2012-12-03 14:06 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Sitaram Chamarty, Git Mailing List
In-Reply-To: <vpq4nk3uu39.fsf@grenoble-inp.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> But a "gc" does not necessarily run "repack -a" when it does not see
>> too many pack files, so it can end up scanning only the surface of
>> the history to collect the recently created loose objects into a
>> pack, and stop its traversal without going into existing packfiles.
>
> Isn't that the behavior of "git gc --auto", not plain "git gc" ?
True; I missed that Sitaram was running "gc" manually.
^ permalink raw reply
* Re: does a successful 'git gc' imply 'git fsck'
From: Matthieu Moy @ 2012-12-03 13:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sitaram Chamarty, Git Mailing List
In-Reply-To: <7vlidgls09.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> But a "gc" does not necessarily run "repack -a" when it does not see
> too many pack files, so it can end up scanning only the surface of
> the history to collect the recently created loose objects into a
> pack, and stop its traversal without going into existing packfiles.
Isn't that the behavior of "git gc --auto", not plain "git gc" ?
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: does a successful 'git gc' imply 'git fsck'
From: Sitaram Chamarty @ 2012-12-03 13:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vlidgls09.fsf@alter.siamese.dyndns.org>
On Sun, Dec 2, 2012 at 3:01 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Sitaram Chamarty <sitaramc@gmail.com> writes:
>
>> If I could assume that a successful 'git gc' means an fsck is not
>> needed, I'd save a lot of time. Hence my question.
>
> When it does "repack -a", it at least scans the whole history so you
> would be sure that all the commits and trees are readable for the
> purpose of enumerating the objects referred by them (and a bit flip
> in them will likely be noticed by zlib inflation).
>
> But a "gc" does not necessarily run "repack -a" when it does not see
> too many pack files, so it can end up scanning only the surface of
> the history to collect the recently created loose objects into a
> pack, and stop its traversal without going into existing packfiles.
Thanks; I'd missed this nuance as well...
--
Sitaram
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox