[L10N] Kickoff of translation for Git 2.4.0 round 1

[Jiang Xin]

Hi,

Git v2.4.0-rc0 is released, and it's time to start new round of git l10n.
This time there are 99 updated messages need to be translated since
last update for v2.3.0:

l10n: git.pot: v2.4.0 round 1 (99 new, 92 removed)

Generate po/git.pot from v2.4.0-rc0 for git v2.4.0 l10n round 1.

Signed-off-by: Jiang Xin 

You can get it from the usual place:

https://github.com/git-l10n/git-po/

As how to update your XX.po and help to translate Git, please see
"Updating a XX.po file" and other sections in “po/README" file.

--
Jiang Xin
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/2] git-p4: Small updates to test cases

[Vitor Antunes]

On Fri, 27 Mar 2015 at 01:26 Junio C Hamano  wrote:

>As to 1/2 the lack of esac is clearly a bug---any self respecting
>POSIX shell should have executed it without complaining. But
>changing from ':' to true should not be necessary---after all, the
>colon is a more traditional way to spell true to Bourne shells, and
>we use it in many places already. Can you try reverting all the
>"colon to true" bits, keeping only the "add missing esac" part, and
>run your tests again?

I confirm that it still works with ':' instead of true; could swear I tested
that at the time... Anyway, I'll re-submit this patch with this fixed
tomorrow.

Thanks for taking the time to review the patch.

One more thing: was there any change in way diff-tree detects copies?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/2] git-p4: Small updates to test cases

[Junio C Hamano]

Junio C Hamano  writes:

> As to 1/2 the lack of esac is clearly a bug---any self respecting
> POSIX shell should have executed it without complaining.  But

s/should/shouldn't/; sorry for a noise.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/2] git-p4: Small updates to test cases

[Junio C Hamano]

Vitor Antunes  writes:

> This patch set includes two small fixes to the rename test case. The fix to
> support dash should be trivial, but in the fix to the copy detection test case
> it isn't obvious to me what changed in diff-tree to result in a different file
> being detected as the origin of a copy.

Thanks.

As to 1/2 the lack of esac is clearly a bug---any self respecting
POSIX shell should have executed it without complaining.  But
changing from ':' to true should not be necessary---after all, the
colon is a more traditional way to spell true to Bourne shells, and
we use it in many places already.  Can you try reverting all the
"colon to true" bits, keeping only the "add missing esac" part, and
run your tests again?

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] git-p4: Fix copy detection test

[Vitor Antunes]

File file11 is copied from file2 and diff-tree correctly reports this file as
its the source, but the test expression was checking for file10 instead (which
was a file that also originated from file2). It is possible that the diff-tree
algorithm was updated in recent versions, which resulted in this mismatch in
behavior.

Signed-off-by: Vitor Antunes 
---
 t/t9814-git-p4-rename.sh |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/t/t9814-git-p4-rename.sh b/t/t9814-git-p4-rename.sh
index 24008ff..018f01d 100755
--- a/t/t9814-git-p4-rename.sh
+++ b/t/t9814-git-p4-rename.sh
@@ -156,14 +156,14 @@ test_expect_success 'detect copies' '
git diff-tree -r -C HEAD &&
git p4 submit &&
p4 filelog //depot/file10 &&
-   p4 filelog //depot/file10 | grep -q "branch from //depot/file" 
&&
+   p4 filelog //depot/file10 | grep -q "branch from //depot/file2" 
&&
 
cp file2 file11 &&
git add file11 &&
git commit -a -m "Copy file2 to file11" &&
git diff-tree -r -C --find-copies-harder HEAD &&
src=$(git diff-tree -r -C --find-copies-harder HEAD | sed 1d | 
cut -f2) &&
-   test "$src" = file10 &&
+   test "$src" = file2 &&
git config git-p4.detectCopiesHarder true &&
git p4 submit &&
p4 filelog //depot/file11 &&
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] git-p4: Make rename test case runnable under dash

[Vitor Antunes]

Signed-off-by: Vitor Antunes 
---
 t/t9814-git-p4-rename.sh |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/t/t9814-git-p4-rename.sh b/t/t9814-git-p4-rename.sh
index 95f4421..24008ff 100755
--- a/t/t9814-git-p4-rename.sh
+++ b/t/t9814-git-p4-rename.sh
@@ -178,9 +178,9 @@ test_expect_success 'detect copies' '
test -n "$level" && test "$level" -gt 0 && test "$level" -lt 98 
&&
src=$(git diff-tree -r -C --find-copies-harder HEAD | sed 1d | 
cut -f2) &&
case "$src" in
-   file10 | file11) : ;; # happy
+   file10 | file11) true ;; # happy
*) false ;; # not
-   &&
+   esac &&
git config git-p4.detectCopies $(($level + 2)) &&
git p4 submit &&
p4 filelog //depot/file12 &&
@@ -195,9 +195,9 @@ test_expect_success 'detect copies' '
test -n "$level" && test "$level" -gt 2 && test "$level" -lt 
100 &&
src=$(git diff-tree -r -C --find-copies-harder HEAD | sed 1d | 
cut -f2) &&
case "$src" in
-   file10 | file11 | file12) : ;; # happy
+   file10 | file11 | file12) true ;; # happy
*) false ;; # not
-   &&
+   esac &&
git config git-p4.detectCopies $(($level - 2)) &&
git p4 submit &&
p4 filelog //depot/file13 &&
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/2] git-p4: Small updates to test cases

[Vitor Antunes]

This patch set includes two small fixes to the rename test case. The fix to
support dash should be trivial, but in the fix to the copy detection test case
it isn't obvious to me what changed in diff-tree to result in a different file
being detected as the origin of a copy.

Vitor Antunes (2):
  git-p4: Make rename test case runnable under dash
  git-p4: Fix copy detection test

 t/t9814-git-p4-rename.sh |   12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 5/5] gitweb: make category headings into links when they are directories

[Tony Finch]

> On 26 Mar 2015, at 19:49, Junio C Hamano  wrote:
> 
> Any comments from those who use or have their own code in Gitweb on
> this topic?

Thanks for chasing up my patches. I should have written a covering letter, to 
say that you can see these patches in action at 
https://git.csx.cam.ac.uk/x/ucs/ - try clicking on the category headings, and 
observe the pathinfo, breadcrumbs, and links under the search box.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2/RFC][GSoC] diff-no-index: transform "$directory $file" args to "$directory/$file $file"

[Junio C Hamano]

Yurii Shevtsov  writes:

> git diff --no-index refuses to compare if args are directory and file,
> instead of usual diff.
>
> Now git diff --no-index modifies args, if they're directory and file,
> and diffs files, as usual diff does.
>
> Changes are done in diff_no_index().
>
> Helped-by: Junio C Hamano 
> Signed-off-by: Yurii Shevtsov 
> ---
>  diff-no-index.c |   31 +--
>  1 files changed, 29 insertions(+), 2 deletions(-)

This round looks sensible.  Good catch to notice that POSIX wants
you to append not just the "path to the file", but the basename of
the file, to the directory name.

I didn't try your patch, but I wouldn't be surprised if it passed
the tests in the patches I wrote last night in the $gmane/266315
thread ;-).

Good luck with your GSoC application.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] config.c: split some variables to $GIT_DIR/config.worktree

[Max Kirillov]

On Thu, Mar 26, 2015 at 07:04:24PM +0700, Nguyễn Thái Ngọc Duy wrote:
> When you define $GIT_DIR/info/config.worktree, which contains of
> gitignore-style patterns (*), config variables that match these
> patterns will be saved in $GIT_DIR/config.worktree instead of
> $GIT_DIR/config.

Should it rather be in GIT_COMMON_DIR? As far as I
understand, its meaning is "variables which we allow to use
per-worktree because we intend to have them different in
different worktrees, and sure no bad issues
can happen because this. It is not hardcored in git because
the list is going to extend, and we'd like to allow older
versions of git (and other git implementations) to be still
able to understand newer repositories". So there should be
no sense to make the list worktree-specific.

Also, probably the per-worktree variables should be searched
for in both common config and per-worktree config, and the
main repository should not have config.worktree, to be able
to work with implementations which are not aware of the
whole multiple worktrees feature. And in worktrees, if the
variable is not defined in config.wortree, the default
vaalue should come from common config. This though has
downside that worktree cannot use the more global vlue for
variable implicitly.

-- 
Max

> On the surface, they are just like any other variables. You can read
> or modify them with `git config` command, or config_* API. Underneath,
> they are always stored in $GIT_DIR/config.worktree instead of
> $GIT_DIR/config (and never in $HOME/.gitconfig or /etc/gitconfig)
> 
> The reason for this split is, as the name implies, for
> worktree-specific configuration. When the same repo is attached to
> more than one worktree, we can't use $GIT_DIR/config to store worktree
> specific stuff because it's shared across worktrees.
> 
> (*) Config variable names are separated by dots. However as this is a
> quick and dirty patch to experiment with submodules and multiple
> worktrees, you must substitute dots with slashes when writing these
> patterns, for now. E.g. write "remote/*/foo" instead of "remote.*.foo"
> 
> Signed-off-by: Nguyễn Thái Ngọc Duy 
> ---
>  Something for Max to play with if he's still experimenting with
>  multiple worktree support for submodules :-) It's far from perfect,
>  but good enough for this purpose.
> 
>  Documentation/config.txt |  6 -
>  builtin/config.c |  8 ++
>  config.c | 67 
> 
>  t/t1300-repo-config.sh   | 34 
>  4 files changed, 114 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index 2700a1b..6d00f49 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -2,11 +2,15 @@ CONFIGURATION FILE
>  --
>  
>  The Git configuration file contains a number of variables that affect
> -the Git commands' behavior. The `.git/config` file in each repository
> +the Git commands' behavior. The `.git/config` and `.git/config.worktree`
> +files in each repository
>  is used to store the configuration for that repository, and
>  `$HOME/.gitconfig` is used to store a per-user configuration as
>  fallback values for the `.git/config` file. The file `/etc/gitconfig`
>  can be used to store a system-wide default configuration.
> +If `.git/info/core.worktree` exists, it contains gitignore-style
> +patterns. Variables that match these patterns can only be contained in
> +`.git/config.worktree`.
>  
>  The configuration variables are used by both the Git plumbing
>  and the porcelains. The variables are divided into sections, wherein
> diff --git a/builtin/config.c b/builtin/config.c
> index 8cc2604..4ca8fc2 100644
> --- a/builtin/config.c
> +++ b/builtin/config.c
> @@ -555,6 +555,14 @@ int cmd_config(int argc, const char **argv, const char 
> *prefix)
>   usage_with_options(builtin_config_usage, 
> builtin_config_options);
>   }
>  
> + /*
> +  * For set operations, --local could be either config or
> +  * config.worktree. Let config.c determine the path based on
> +  * config keys.
> +  */
> + if (use_local_config && actions != ACTION_LIST)
> + given_config_source.file = NULL;
> +
>   if (actions == ACTION_LIST) {
>   check_argc(argc, 0, 0);
>   if (git_config_with_options(show_all_config, NULL,
> diff --git a/config.c b/config.c
> index 15a2983..f68eb6a 100644
> --- a/config.c
> +++ b/config.c
> @@ -12,6 +12,7 @@
>  #include "quote.h"
>  #include "hashmap.h"
>  #include "string-list.h"
> +#include "dir.h"
>  
>  struct config_source {
>   struct config_source *prev;
> @@ -37,6 +38,7 @@ struct config_source {
>  };
>  
>  static struct config_source *cf;
> +static struct exclude_list config_local;
>  
>  static int zlib_compression_seen;
>  
> @@ -84,6 +86,34 @@ static long config_buf_ftell(struct config_source *conf)
>   return conf->u.buf.pos;
>  }

Re: [RFC] git submodule purge

[Jens Lehmann]

Am 26.03.2015 um 14:30 schrieb Patrick Steinhardt:

On Wed, Mar 25, 2015 at 08:47:59PM +0100, Jens Lehmann wrote:

Am 25.03.2015 um 10:06 schrieb Patrick Steinhardt:

Optionally I could
implement `git gc --purge-submodule=` as a second
way to access the feature so that we have a way of purging them
without using the submodules-interface. I doubt though that this
will provide much of a benefit as the user still has to be aware
that he is working with submodules as he has to provide the
`--purge-submodule` option, so there is not much to be gained by
this.


Hmm, I still believe cleaning up a submodule repo which is already
deinited makes sense. Using 'rm -rf .git/modules/'
will work just fine, but is missing any safeguards. The deinit
command takes submodule paths, not submodule names. So it looks
to me like 'git gc --purge-submodule=' would make
sense here (and this command should check that the submodule has
already been deinited and fail otherwise telling the user so).


Ah, okay. I thought your intention was to provide `git gc
--purge-sm` _instead_ of `git sm deinit --purge`. Guess it makes
sense to have both available for the different use cases
(explicitly removing a submodule vs removing unreferenced ones).


Yup. And I wonder if `--purge` should be the default for deinit
if no unpushed commits will be lost ... but let's hear what
others think about this one.


I guess one could even provide another option
`--purge-submodules` in addition to `--purge-sm=` that
will remove all deinitialized submodules without local commits.
Maybe its desirable to have a `--dry-run` flag as well that would
print which repositories would be deleted by `--purge-sms`.


Hmm, thinking about that some more maybe we might wanna simplify
this a bit. Adding a `--prune-submodules` option to gc which will
remove all deinitialized submodules repos that don't have any
unpushed commits should be sufficient to do the housekeeping. If
people demand to be able to prune specific submodules later we
could still add a `--prune-submodule=`, but I suspect we
might not need that.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] docs: Clarify what git-rebase's "--preserve-merges" does

[Johannes Sixt]

Am 26.03.2015 um 22:17 schrieb Sergey Organov:

Junio C Hamano  writes:

There however were repeated wishes (or wishful misunderstandings ;-)
that there were a mode to rebuild the trunk, considering only the
commits on the first-parent chain as "commits to be rebased",
recreating the history by replaying the merge commits (whose first
parent might be rewritten during the rebase, but the tips of side
branches these merges bring into the history are kept intact).

Surely there is no such mode right now,


Isn't it what Johannes Sixt  mentions here?:

[QUOTE]
If you want a version of --preserve-merges that does what *you* need,
consider this commit:

   git://repo.or.cz/git/mingw/j6t.git rebase-p-first-parent

Use it like this:

   git rebase -i -p --first-parent ...

Beware, its implementation is incomplete: if the rebase is interrupted,
then 'git rebase --continue' behaves as if --first-parent were not given.
[/QUOTE].

ref: http://permalink.gmane.org/gmane.comp.version-control.git/263584

If so, then I'd say such mode almost exists.


The patch was discussed here:
http://thread.gmane.org/gmane.comp.version-control.git/198125

The reason that this has not progressed any further is this response in 
the thread:


http://thread.gmane.org/gmane.comp.version-control.git/198125/focus=198483

where you basically say that a --first-parent mode is good, but it 
should be separate from --preserve-merges. I haven't made up my mind, 
yet, how to proceed from there.


If somebody wants to pick up the baton, I'll happily pass it on.

-- Hannes

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] docs: Clarify what git-rebase's "--preserve-merges" does

[Sergey Organov]

Junio C Hamano  writes:

[...]

> I think the current preserve-merges considers everything between
>  and  as "commits to be rebased", and recreate
> merges across these rebased tips of branches that are merged.
>
> There however were repeated wishes (or wishful misunderstandings ;-)
> that there were a mode to rebuild the trunk, considering only the
> commits on the first-parent chain as "commits to be rebased",
> recreating the history by replaying the merge commits (whose first
> parent might be rewritten during the rebase, but the tips of side
> branches these merges bring into the history are kept intact).
>
> Surely there is no such mode right now,

Isn't it what Johannes Sixt  mentions here?:

[QUOTE]
If you want a version of --preserve-merges that does what *you* need,
consider this commit:

  git://repo.or.cz/git/mingw/j6t.git rebase-p-first-parent

Use it like this:

  git rebase -i -p --first-parent ...

Beware, its implementation is incomplete: if the rebase is interrupted,
then 'git rebase --continue' behaves as if --first-parent were not given.
[/QUOTE].

ref: http://permalink.gmane.org/gmane.comp.version-control.git/263584

If so, then I'd say such mode almost exists.

> but I am fairly sure that I wouldn't have any objection against a
> patch to implement such a feature (perhaps "--first-parent
> --preserve-merges"?),

It'd be very welcome feature here, preferably along with a way to pass
it to 'git pull --rebase', including a way to configure it to be the
default. 

> and with or without such a feature in the system, I would be happier
> if we made sure that the description we are discussing to update makes
> it clear that the current behaviour is "everything between 
> and ", and cannot be misread as "do not touch side branches
> instead of dropping merged commits".

I'd also suggest to somehow warn in the manual that current modes of
operation silently drop changes to merge commits that were made to
non-conflicting paths (either during conflict resolution or otherwise.)

-- Sergey.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[ANNOUNCE] Git v2.4.0-rc0

[Junio C Hamano]

An early preview release Git v2.4.0-rc0 is now available for testing
at the usual places.  This cycle is turning out to be a "product
excellence" release---majority of the changes are bugfixes, about
one-third of which are also already in the v2.3.x maintenance track.

The tarballs are found at:

https://www.kernel.org/pub/software/scm/git/testing/

The following public repositories all have a copy of the 'v2.4.0-rc0'
tag and the 'master' branch that the tag points at:

  url = https://kernel.googlesource.com/pub/scm/git/git
  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 2.4 Release Notes (draft)
=

Backward compatibility warning(s)
-

This release has a few changes in the user-visible output from
Porcelain commands, which the users may want to be aware of.

 * Output from "git log --decorate" (and "%d" format specifier used in
   the userformat "--format=" parameter "git log" family of
   command takes) used to list "HEAD" just like other tips of branch
   names, separated with a comma in between.  E.g.

 $ git log --decorate -1 master
 commit bdb0f6788fa5e3cacc4315e9ff318a27b2676ff4 (HEAD, master)
 ...

   This release updates the output slightly when HEAD refers to the tip
   of a branch whose name is also shown in the output.  The above is
   shown as:

 $ git log --decorate -1 master
 commit bdb0f6788fa5e3cacc4315e9ff318a27b2676ff4 (HEAD -> master)
 ...

 * The phrasing "git branch" uses to describe a detached HEAD has been
   updated to match that of "git status":

- When the HEAD is at the same commit as it was originally
  detached, they now both show "detached at ".

- When the HEAD has moved since it was originally detached,
  they now both show "detached from ".

Earlier "git branch" always used "from"


Updates since v2.3
--

Ports

 * Our default I/O size (8 MiB) for large files was too large for some
   platforms with smaller SSIZE_MAX, leading to read(2)/write(2)
   failures.

 * We did not check the curl library version before using
   CURLOPT_PROXYAUTH feature that may not exist.

 * We now detect number of CPUs on older BSD-derived systems.

 * Portability fixes and workarounds for shell scripts have been added
   to help BSD-derived systems.


UI, Workflows & Features

 * The command usage info strings given by "git cmd -h" and in
   documentation have been tweaked for consistency.

 * The "sync" subcommand of "git p4" now allows users to exclude
   subdirectories like its "clone" subcommand does.

 * "git log --invert-grep --grep=WIP" will show only commits that do
   not have the string "WIP" in their messages.

 * "git push" has been taught a "--atomic" option that makes push to
   update more than one ref an "all-or-none" affair.

 * Extending the "push to deploy" added in 2.3, the behaviour of "git
   push" when updating the branch that is checked out can now be
   tweaked by push-to-checkout hook.

 * Using environment variable LANGUAGE and friends on the client side,
   HTTP-based transports now send Accept-Language when making requests.

 * "git send-email" used to accept a mistaken "y" (or "yes") as an
   answer to "What encoding do you want to use [UTF-8]? " without
   questioning.  Now it asks for confirmation when the answer looks
   too short to be a valid encoding name.

 * When "git apply --whitespace=fix" fixed whitespace errors in the
   common context lines, the command reports that it did so.

 * "git status" now allows the "-v" to be given twice to show the
   differences that are left in the working tree not to be committed.

 * "git cherry-pick" used to clean-up the log message even when it is
   merely replaying an existing commit.  It now replays the message
   verbatim unless you are editing the message of resulting commits.

 * "git archive" can now be told to set the 'text' attribute in the
   resulting zip archive.

 * Output from "git log --decorate" mentions HEAD when it points at a
   tip of an branch differently from a detached HEAD.

   This is a potentially backward-incompatible change.

 * "git branch" on a detached HEAD always said "(detached from xyz)",
   even when "git status" would report "detached at xyz".  The HEAD is
   actually at xyz and haven't been moved since it was detached in
   such a case, but the user cannot read what the current value of
   HEAD is when "detached from" is used.

 * "git -C '' subcmd" refused to work in the current directory, unlike
   "cd ''" which silently behaves as a no-op.
   (merge 6a536e2 kn/git-cd-to-empty later to maint).

 * The versionsort.prerelease configuration variable can be used to
   specify that v1.0-pre1 comes b

What's cooking in git.git (Mar 2015, #09; Thu, 26)

[Junio C Hamano]

Here are the topics that have been cooking.  Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.

Good news is that a few GSoC Microprojects have been merged already
to 'master'; from my vague recollection of past years, perhaps this
year's batch of students are of better quality?  I dunno, but it
that is the case, it is a welcome change.

A preview release 2.4-rc0 has been tagged.  I do not expect no major
topics to graduate to 'master' before the final; many topics in
'next' touch important issues and crucial code paths and I'd prefer
to see them cooked in 'next' for a few more weeks, rather than
merging them early and having to make last-minute reverts for the
upcoming release.

I'll also start dropping stalled topics from 'pu' as part of spring
cleaning.

You can find the changes described here in the integration branches
of the repositories listed at

http://git-blame.blogspot.com/p/git-public-repositories.html

--
[Graduated to "master"]

* ct/prompt-untracked-fix (2015-03-15) 1 commit
  (merged to 'next' on 2015-03-20 at 0d57eaf)
 + git prompt: use toplevel to find untracked files

 The prompt script (in contrib/) did not show the untracked sign
 when working in a subdirectory without any untracked files.


* dj/log-graph-with-no-walk (2015-03-19) 1 commit
  (merged to 'next' on 2015-03-20 at cb636c0)
 + revision: forbid combining --graph and --no-walk

 "git log --graph --no-walk A B..." is a otcnflicting request that
 asks nonsense; no-walk tells us show discrete points in the
 history, while graph asks to draw connections between these
 discrete points. Forbid the combination.


* jc/report-path-error-to-dir (2015-03-24) 1 commit
  (merged to 'next' on 2015-03-24 at 6e97221)
 + report_path_error(): move to dir.c

 Code clean-up.


* jc/submitting-patches-mention-send-email (2015-03-15) 1 commit
  (merged to 'next' on 2015-03-23 at a9581fd)
 + SubmittingPatches: encourage users to use format-patch and send-email

 Recommend format-patch and send-email for those who want to submit
 patches to this project.


* jk/cleanup-failed-clone (2015-03-19) 2 commits
  (merged to 'next' on 2015-03-23 at 1f26d93)
 + clone: drop period from end of die_errno message
 + clone: initialize atexit cleanup handler earlier

 An failure early in the "git clone" that started creating the
 working tree and repository could have resulted in some directories
 and files left without getting cleaned up.


* jk/fetch-pack (2015-03-19) 4 commits
  (merged to 'next' on 2015-03-23 at 4357f3d)
 + fetch-pack: remove dead assignment to ref->new_sha1
 + fetch_refs_via_pack: free extra copy of refs
 + filter_ref: make a copy of extra "sought" entries
 + filter_ref: avoid overwriting ref->old_sha1 with garbage

 "git fetch" that fetches a commit using the allow-tip-sha1-in-want
 extension could have failed to fetch all the requested refs.


* jk/prune-with-corrupt-refs (2015-03-20) 5 commits
  (merged to 'next' on 2015-03-23 at 68af8a9)
 + refs.c: drop curate_packed_refs
 + repack: turn on "ref paranoia" when doing a destructive repack
 + prune: turn on ref_paranoia flag
 + refs: introduce a "ref paranoia" flag
 + t5312: test object deletion code paths in a corrupted repository

 "git prune" used to largely ignore broken refs when deciding which
 objects are still being used, which could spread an existing small
 damage and make it a larger one.


* jk/run-command-capture (2015-03-22) 7 commits
  (merged to 'next' on 2015-03-23 at f6db88b)
 + run-command: forbid using run_command with piped output
 + trailer: use capture_command
 + submodule: use capture_command
 + wt-status: use capture_command
 + run-command: introduce capture_command helper
 + wt_status: fix signedness mismatch in strbuf_read call
 + wt-status: don't flush before running "submodule status"

 The run-command interface was easy to abuse and make a pipe for us
 to read from the process, wait for the process to finish and then
 attempt to read its output, which is a pattern that lead to a
 deadlock.  Fix such uses by introducing a helper to do this
 correctly (i.e. we need to read first and then wait the process to
 finish) and also add code to prevent such abuse in the run-command
 helper.


* jk/simplify-csum-file-sha1fd-check (2015-03-19) 1 commit
  (merged to 'next' on 2015-03-20 at 6f6d1c2)
 + sha1fd_check: die when we cannot open the file

 Code simplification.


* jk/test-chain-lint (2015-03-25) 36 commits
  (merged to 'next' on 2015-03-25 at 011a687)
 + t9001: drop save_confirm helper
 + t0020: use test_* helpers instead of hand-rolled messages
 + t: simplify loop exit-code status variables
 + t: fix some trivial cases of ignored exit codes in loops
 + t7701: fix ignored exit code inside loop
 + t3305: fix ignored exit code inside loop
 + t0020: fix ignored exit code inside loops
 + perf-lib: fix ignored exit code inside loop
  (merged to 'next' on 2015-

Dr Harry Thomas

[Dr. Harry Thomas]

Dr Harry Thomas
Brondesbury, North West
Londyn Anglia

Drogi Przyjacielu.
 



Jestem dr Harry Thomas z Brondesbury, North West London, tutaj w Anglii. 

Pracuję dla UBS Investment Bank Londyn. Piszę wam o propozycji biznesowych, 

które będą z ogromną korzyścią dla nas obu. W moim departamencie, jako członek 

Komitetu Wykonawczego UBS Investment Bank i również Officer Chief Risk tutaj 

(Greater London Regional Office). Odkryłem opuszczonej sumę 15 milionów Great 

British funtach (piętnaście milionów Great British Pounds Sterling) na koncie 

należącym do jednego z naszych zagranicznych klientów zmarłego, miliarder 

Business Man (Late Pan Mojżesz Saba Masri) z Meksyku, który był ofiarą 

katastrofy lotniczej, w wyniku jego śmierci i członków jego rodziny. Saba był 

51-letni. Również w katastrofie lotniczej był z żoną i synem Abrahama (Saba) i 

jego córka-in-law.
 

Wybór kontaktowania się budzi z charakter geograficzny, gdzie mieszkasz, w 

szczególności ze względu na wrażliwość transakcji i poufność w niniejszym 

wynalazku. Teraz nasz bank został czeka na którykolwiek z krewnymi, aby przyjść 

się do roszczenia, ale nikt tego nie zrobił. Ja osobiście przegrali sprawę w 

odnalezieniu krewnych do 10 miesięcy teraz, szukam Twojej zgody, aby 

zaprezentować Państwu jak najbliższych krewnych / Will Beneficjenta do zmarłego 

tak, że wpływy z tego konta wyceniono na 15 milionów funtów funtów może być 

wypłacona do Ciebie ,
 

To będzie wypłacane lub udostępniane w tych procentów, 60% do 40% mnie i dla 

Ciebie. Mam zabezpieczone wszystkie niezbędne dokumenty prawne, które mogą być 

wykorzystane do wykonania kopii zapasowej tego twierdzenia jest uczynienie. 

Wszystko, co musisz zrobić, to wypełnić swoje nazwiska do dokumentów i 

zalegalizować go w sądzie, aby udowodnić Ci za prawowitego beneficjenta. All I 

wymagają teraz jest uczciwy współpracy, poufności i zaufania w celu 

umożliwienia nam patrz poprzez tę transakcję. Gwarantuję, że będzie to wykonane 

zgodnie z prawem rozwiązanie, które będzie chronić komputer z wszelkich 

przypadków naruszenia prawa.
 

Proszę dostarczyć mi następujące: jak mamy 7 dni, aby go uruchomić poprzez. To 

jest bardzo pilne PLEASE.
 

1. Imię i nazwisko:
2. Twój numer telefonu komórkowego:
3. Twój Adres kontaktowy:
4. Twój Wiek:
5. Płeć:
 

Po przejściu przez metodyczne wyszukiwania, postanowiłem skontaktować się z 

Tobą nadzieję, że znajdziesz to propozycja interesująca. Na potwierdzenie tej 

wiadomości i wskazując zainteresowanie dostarczą Państwu więcej informacji. 

Starania, aby dać mi znać swojej decyzji zamiast trzymać mnie czeka.
 

Pozdrawiam,
Dr Harry Thomas
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] docs: Clarify what git-rebase's "--preserve-merges" does

[Junio C Hamano]

Sebastian Schuberth  writes:

>>  Instead of flattening the history by replaying each
>>  non-merge commit to be rebased, preserve the shape of the
>>  rebased history by recreating merge commits as well.
>>
>> or something along that line, perhaps?
>
> Hm, I'm not sure about the "as well" here. Non-merge commits basically
> are just picked, not recreated in the same sense as merge
> commits. I'll come up with another proposal.

OK.  I do not see qualitative difference between picking a non-merge
and picking a merge; they are both being replayed and it is not like
the machiery is trying to preserve an evil merge.  Having said that,
I do not have a strong feeling either way between keeping and
dropping that "as well".  I threw it in there only to contrast the
preserve mode (where merges are also picked) with the normal mode
(where merges are not picked).
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V2/RFC][GSoC] diff-no-index: transform "$directory $file" args to "$directory/$file $file"

[Yurii Shevtsov]

git diff --no-index refuses to compare if args are directory and file,
instead of usual diff.

Now git diff --no-index modifies args, if they're directory and file,
and diffs files, as usual diff does.

Changes are done in diff_no_index().

Helped-by: Junio C Hamano 
Signed-off-by: Yurii Shevtsov 
---
 diff-no-index.c |   31 +--
 1 files changed, 29 insertions(+), 2 deletions(-)

diff --git a/diff-no-index.c b/diff-no-index.c
index 265709b..ecff15e 100644
--- a/diff-no-index.c
+++ b/diff-no-index.c
@@ -186,7 +186,7 @@ void diff_no_index(struct rev_info *revs,
int argc, const char **argv,
const char *prefix)
 {
-int i, prefixlen;
+int i, prefixlen, mode1 = 0, mode2 = 0;
 const char *paths[2];

 diff_setup(&revs->diffopt);
@@ -229,8 +229,35 @@ void diff_no_index(struct rev_info *revs,
 setup_diff_pager(&revs->diffopt);
 DIFF_OPT_SET(&revs->diffopt, EXIT_WITH_STATUS);

-if (queue_diff(&revs->diffopt, paths[0], paths[1]))
+if (get_mode(paths[0], &mode1) || get_mode(paths[1], &mode2))
+exit(2);
+
+if (mode1 && mode2 && S_ISDIR(mode1) != S_ISDIR(mode2)) {
+struct strbuf pathtofile;
+const char *dir, *file;
+char *filename;
+int ret;
+
+dir = S_ISDIR(mode1) ? paths[0] : paths[1];
+file = (dir == paths[0]) ? paths[1] : paths[0];
+strbuf_init(&pathtofile, strlen(paths[0]) + strlen(paths[1]) + 1);
+strbuf_addstr(&pathtofile, dir);
+if (pathtofile.len && pathtofile.buf[pathtofile.len - 1] != '/')
+   strbuf_addch(&pathtofile, '/');
+filename = strrchr(file, '/');
+strbuf_addstr(&pathtofile, filename ? (filename + 1) : file);
+
+if (file == paths[0])
+ret = queue_diff(&revs->diffopt, file, pathtofile.buf);
+else
+ret = queue_diff(&revs->diffopt, pathtofile.buf, file);
+strbuf_release(&pathtofile);
+if (ret)
+exit(1);
+}
+else if (queue_diff(&revs->diffopt, paths[0], paths[1]))
 exit(1);
+
 diff_set_mnemonic_prefix(&revs->diffopt, "1/", "2/");
 diffcore_std(&revs->diffopt);
 diff_flush(&revs->diffopt);
-- 

Attached patch file because gmail always replaces tabs with spaces and
refuses to authorize 'git send-email'


0001-git-diff-no-index-refuses-to-compare-if-args-are-dir.patch
Description: Binary data

[PATCH] Fix two typos

[Thomas Ackermann]

Signed-off-by: Thomas Ackermann 
---
 Documentation/RelNotes/2.4.0.txt   | 2 +-
 Documentation/technical/api-error-handling.txt | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/RelNotes/2.4.0.txt b/Documentation/RelNotes/2.4.0.txt
index 386c75d..cdfd578 100644
--- a/Documentation/RelNotes/2.4.0.txt
+++ b/Documentation/RelNotes/2.4.0.txt
@@ -296,7 +296,7 @@ notes for details).
(merge 35840a3 jc/conf-var-doc later to maint).
 
  * An earlier workaround to squelch unhelpful deprecation warnings
-   from the complier on Mac OSX unnecessarily set minimum required
+   from the compiler on Mac OSX unnecessarily set minimum required
version of the OS, which the user might want to raise (or lower)
for other reasons.
(merge 88c03eb es/squelch-openssl-warnings-on-macosx later to maint).
diff --git a/Documentation/technical/api-error-handling.txt 
b/Documentation/technical/api-error-handling.txt
index fc68db1..ceeedd4 100644
--- a/Documentation/technical/api-error-handling.txt
+++ b/Documentation/technical/api-error-handling.txt
@@ -58,7 +58,7 @@ to `die` or `error` as-is.  For example:
if (ref_transaction_commit(transaction, &err))
die("%s", err.buf);
 
-The 'err' parameter will be untouched if no error occured, so multiple
+The 'err' parameter will be untouched if no error occurred, so multiple
 function calls can be chained:
 
t = ref_transaction_begin(&err);
-- 
1.9.5.msysgit.0
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] docs: Clarify what git-rebase's "--preserve-merges" does

[Sebastian Schuberth]

On 26.03.2015 19:18, Junio C Hamano wrote:


Also, do not say that merge commits are *tried* to be recreated.


Good point.  "We will try but it might fail" is better left unsaid
as that is true almost everywhere.


Exactly.


  -p::
  --preserve-merges::
-Instead of ignoring merges, try to recreate them.
+Recreate merge commits instead of replaying commits a merge
commit introduces.


Hmm, is this line-wrapped?


Probably, I had to send this via GMail.


Although I fully agree that the new text is better than the original,
I think the new text fails to point out one major aspect by not
mentioning "linear" or "flatten" anywhere.  The point of "git rebase"
without "-p" is not just to replay but to flatten

Instead of flattening the history by replaying each
non-merge commit to be rebased, preserve the shape of the
rebased history by recreating merge commits as well.

or something along that line, perhaps?


Hm, I'm not sure about the "as well" here. Non-merge commits basically 
are just picked, not recreated in the same sense as merge commits. I'll 
come up with another proposal.



I think the current preserve-merges considers everything between
 and  as "commits to be rebased", and recreate
merges across these rebased tips of branches that are merged.  There
however were repeated wishes (or wishful misunderstandings ;-) that
there were a mode to rebuild the trunk, considering only the commits
on the first-parent chain as "commits to be rebased", recreating the
history by replaying the merge commits (whose first parent might be
rewritten during the rebase, but the tips of side branches these
merges bring into the history are kept intact).


I guess I'm a victim of that wishful misunderstanding then, as I indeed 
though that's exactly what the current -p is doing. Well, modulo the 
special case where the second parent is the tip of a branch whose 
fork-point with the trunk is part of the rebase, see "Example 1" at [1].


In other word, you're saying that the current preserve-merges does not 
keep the tips of side branches intact. If that's so, what is is doing 
with the tips of the side branches?



without such a feature in the system, I would be happier if we made
sure that the description we are discussing to update makes it clear
that the current behaviour is "everything between  and
", and cannot be misread as "do not touch side branches
instead of dropping merged commits".


Agreed. As soon as I understand the difference between the two :-)

[1] http://stackoverflow.com/a/15915431/1127485

--
Sebastian Schuberth
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] docs: Clarify "preserve" option wording for git-pull

[Junio C Hamano]

Thanks; this time I do not see whitespace breakages ;-)

Will queue with a minimum tweak of the log message.



--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] docs: Clarify "preserve" option wording for git-pull

[Sebastian Schuberth]

Before this path, the "also" sounded as if "preserve" was doing a rebase
as additional work that "true" would not do. Clarify this by omitting the
"also" and rewording the sentence a bit.

Signed-off-by: Sebastian Schuberth 
---
 Documentation/git-pull.txt | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
index d3d236c..712ab4b 100644
--- a/Documentation/git-pull.txt
+++ b/Documentation/git-pull.txt
@@ -111,9 +111,8 @@ include::merge-options.txt[]
was rebased since last fetched, the rebase uses that information
to avoid rebasing non-local changes.
 +
-When preserve, also rebase the current branch on top of the upstream
-branch, but pass `--preserve-merges` along to `git rebase` so that
-locally created merge commits will not be flattened.
+When set to preserve, rebase with the `--preserve-merges` option passed
+to `git rebase` so that locally created merge commits will not be flattened.
 +
 When false, merge the current branch into the upstream branch.
 +
-- 
1.9.5.msysgit.1


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 5/5] gitweb: make category headings into links when they are directories

[Junio C Hamano]

Any comments from those who use or have their own code in Gitweb on
this topic?

* tf/gitweb-project-listing (2015-03-19) 5 commits
 - gitweb: make category headings into links when they are directories
 - gitweb: optionally set project category from its pathname
 - gitweb: add a link under the search box to clear a project filter
 - gitweb: if the PATH_INFO is incomplete, use it as a project_filter
 - gitweb: fix typo in man page

 Update gitweb to make it more pleasant to deal with a hierarchical
 forest of repositories.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] git-push.txt: clean up force-with-lease wording

[Junio C Hamano]

Phil Hord  writes:

> The help text for the --force-with-lease option to git-push
> does not parse cleanly.  Clean up the wording and syntax to
> be more sensible.  Also remove redundant information in the
> "--force-with-lease alone" description.
>
> Signed-off-by: Phil Hord 
> ---

Thanks.  The updated text reads well.

Will queue.

>  Documentation/git-push.txt | 14 ++
>  1 file changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
> index 5171086..863c30c 100644
> --- a/Documentation/git-push.txt
> +++ b/Documentation/git-push.txt
> @@ -157,9 +157,8 @@ already exists on the remote side.
>   Usually, "git push" refuses to update a remote ref that is
>   not an ancestor of the local ref used to overwrite it.
>  +
> -This option bypasses the check, but instead requires that the
> -current value of the ref to be the expected value.  "git push"
> -fails otherwise.
> +This option overrides this restriction if the current value of the
> +remote ref is the expected value.  "git push" fails otherwise.
>  +
>  Imagine that you have to rebase what you have already published.
>  You will have to bypass the "must fast-forward" rule in order to
> @@ -171,15 +170,14 @@ commit, and blindly pushing with `--force` will lose 
> her work.
>  This option allows you to say that you expect the history you are
>  updating is what you rebased and want to replace. If the remote ref
>  still points at the commit you specified, you can be sure that no
> -other people did anything to the ref (it is like taking a "lease" on
> -the ref without explicitly locking it, and you update the ref while
> -making sure that your earlier "lease" is still valid).
> +other people did anything to the ref. It is like taking a "lease" on
> +the ref without explicitly locking it, and the remote ref is updated
> +only if the "lease" is still valid.
>  +
>  `--force-with-lease` alone, without specifying the details, will protect
>  all remote refs that are going to be updated by requiring their
>  current value to be the same as the remote-tracking branch we have
> -for them, unless specified with a `--force-with-lease=:`
> -option that explicitly states what the expected value is.
> +for them.
>  +
>  `--force-with-lease=`, without specifying the expected value, will
>  protect the named ref (alone), if it is going to be updated, by
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] docs: Clarify what git-rebase's "--preserve-merges" does

[Junio C Hamano]

Sebastian Schuberth  writes:

> Also, do not say that merge commits are *tried* to be recreated.

Good point.  "We will try but it might fail" is better left unsaid
as that is true almost everywhere.


> Signed-off-by: Sebastian Schuberth 
> ---
>  Documentation/git-rebase.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
> index d728030..3a6d139 100644
> --- a/Documentation/git-rebase.txt
> +++ b/Documentation/git-rebase.txt
> @@ -362,7 +362,7 @@ default is `--no-fork-point`, otherwise the
> default is `--fork-point`.
>
>  -p::
>  --preserve-merges::
> -Instead of ignoring merges, try to recreate them.
> +Recreate merge commits instead of replaying commits a merge
> commit introduces.

Hmm, is this line-wrapped?

Although I fully agree that the new text is better than the original,
I think the new text fails to point out one major aspect by not
mentioning "linear" or "flatten" anywhere.  The point of "git rebase"
without "-p" is not just to replay but to flatten

Instead of flattening the history by replaying each
non-merge commit to be rebased, preserve the shape of the
rebased history by recreating merge commits as well.

or something along that line, perhaps?

This reminds me a related tangent discussion we had long time ago (I
thought j6t was involved hence a new Cc:, but my apologies to j6t if
I am misremembering), about what exactly is "recreate merges instead
of replaying commits".

I think the current preserve-merges considers everything between
 and  as "commits to be rebased", and recreate
merges across these rebased tips of branches that are merged.  There
however were repeated wishes (or wishful misunderstandings ;-) that
there were a mode to rebuild the trunk, considering only the commits
on the first-parent chain as "commits to be rebased", recreating the
history by replaying the merge commits (whose first parent might be
rewritten during the rebase, but the tips of side branches these
merges bring into the history are kept intact).

Surely there is no such mode right now, but I am fairly sure that I
wouldn't have any objection against a patch to implement such a
feature (perhaps "--first-parent --preserve-merges"?), and with or
without such a feature in the system, I would be happier if we made
sure that the description we are discussing to update makes it clear
that the current behaviour is "everything between  and
", and cannot be misread as "do not touch side branches
instead of dropping merged commits".

>  +
>  This uses the `--interactive` machinery internally, but combining it
>  with the `--interactive` option explicitly is generally not a good
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] docs: Clarify "preserve" option wording for git-pull

[Junio C Hamano]

Sebastian Schuberth  writes:

> Before this path, the "also" sounded as if "preserve" was doing a rebase
> as additional work that "true" would not do. Clarify this by saying
> "still" instead of "also".

I agree that the original "also" is confusing.  I however wonder if
we even want "still", though.  For that matter, I doubt if we even
want "also" in front of "pass".  "When set to preserve, rebase and
pass the extra flag" sounds as clear as, if not clearer than, "When
set to preserve, still rebase and also pass the extra flag", at
least to me.

Thanks.

> Signed-off-by: Sebastian Schuberth 
> ---
>  Documentation/git-pull.txt | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
> index d3d236c..96829be 100644
> --- a/Documentation/git-pull.txt
> +++ b/Documentation/git-pull.txt
> @@ -111,8 +111,8 @@ include::merge-options.txt[]
>  was rebased since last fetched, the rebase uses that information
>  to avoid rebasing non-local changes.
>  +
> -When preserve, also rebase the current branch on top of the upstream
> -branch, but pass `--preserve-merges` along to `git rebase` so that
> +When preserve, still rebase the current branch on top of the upstream
> +branch, but also pass `--preserve-merges` along to `git rebase` so that
>  locally created merge commits will not be flattened.
>  +
>  When false, merge the current branch into the upstream branch.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] gc: save log from daemonized gc --auto and print it next time

[Junio C Hamano]

Nguyễn Thái Ngọc Duy   writes:

> While commit 9f673f9 (gc: config option for running --auto in
> background - 2014-02-08) helps reduce some complaints about 'gc
> --auto' hogging the terminal, it creates another set of problems.
>
> The latest in this set is, as the result of daemonizing, stderr is
> closed and all warnings are lost. This warning at the end of cmd_gc()
> is particularly important because it tells the user how to avoid "gc
> --auto" running repeatedly. Because stderr is closed, the user does
> not know, naturally they complain about 'gc --auto' wasting CPU.
>
> Besides reverting 9f673f9 and looking at the problem from another
> angle, we could save the stderr in $GIT_DIR/gc.log. Next time, 'gc
> --auto' will print the saved warnings, delete gc.log and exit.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy 
> ---
>  The test is dropped. It does not feel good enough.. The rest of
>  changes is minor

I still wonder what this buys us if multiple auto-gc's are triggered,
because the user is running a long svn import or something similar.

I cannot tell what problem this is trying to solve.

 (1) If the error output from the previous "gc --auto" indicates a
 grave error condition that further re-running of "gc --auto" is
 pointless, why is it a good idea to blindly remove the log and
 "let the next one run as usual"?

 (2) If the problem it is trying to solve is that "gc --auto"
 sometimes gives a good suggestion but that is lost when
 daemonized, why not address that problem in a more direct way,
 e.g. introduce a new option "gc --probe-auto" that only checks
 and reports if "gc --auto" would spend actual cycles to do its
 work, and then run the daemonized version of "gc --auto" when
 necessary?  Either "gc --probe-auto" itself or the caller of
 "gc --probe-auto" can give the "you should do this to avoid
 repeated auto-gc" when this happens.

 Also the same issue I have with (1) above applies; I do not see
 much linkage with solving this issue with halving the frequency
 of running "gc --auto" which is what this patch does.

In other words, I would understand what the change is trying to
achieve if it were to always stop, instruct the user to take
corrective action, and never remove the .log file itself (naturally,
the corrective action would include "remove the .log when you are
done").  I do not necessarily agree that it would be a good change
for the overall system, but at least such a change is internally
consistent between its perception of a problem and its approach to
solve it.

I would also understand, and I suspect I would prefer it if I see
the result, if the change were to allow "gc --auto" to report
severity of its findings (i.e. "nothing wrong in your repository but
you should do X to avoid triggering me too often" vs "no point
running me again and again"), do something similar to what this
patch does and after showing the message and (1) stop without
removing the log but give instruction when the situation is grave,
or (2) show the message, remove the .log, and continue to go ahead
with "gc --auto" when the situation is *not* grave.

But the approach taken by this patch looks very confused about its
own purpose to me and I cannot quite tell what it is trying to
solve.

>   diff --git a/builtin/gc.c b/builtin/gc.c
>   index 07769a9..3886937 100644
>   --- a/builtin/gc.c
>   +++ b/builtin/gc.c
>   @@ -32,8 +32,6 @@ static int aggressive_window = 250;
>static int gc_auto_threshold = 6700;
>static int gc_auto_pack_limit = 50;
>static int detach_auto = 1;
>   -static struct strbuf log_filename = STRBUF_INIT;
>   -static int daemonized;
>static const char *prune_expire = "2.weeks.ago";
>
>static struct argv_array pack_refs_cmd = ARGV_ARRAY_INIT;
>   @@ -43,6 +41,8 @@ static struct argv_array prune = ARGV_ARRAY_INIT;
>static struct argv_array rerere = ARGV_ARRAY_INIT;
>
>static char *pidfile;
>   +static struct strbuf log_filename = STRBUF_INIT;
>   +static int daemonized;
>
>static void remove_pidfile(void)
>{
>   @@ -338,7 +338,7 @@ int cmd_gc(int argc, const char **argv, const char 
> *prefix)
>   struct strbuf sb = STRBUF_INIT;
>
>   if (strbuf_read_file(&sb, git_path("gc.log"), 0) > 0) {
>   -   warning(_("Last gc run reported the following, 
> gc skipped"));
>   +   warning(_("skipping gc; last gc reported:"));
>   fputs(sb.buf, stderr);
>   strbuf_release(&sb);
>   /* let the next gc --auto run as usual */
>   @@ -352,8 +352,7 @@ int cmd_gc(int argc, const char **argv, const char 
> *prefix)
>* failure to daemonize is ok, we'll continue
>* in foreground
>*/
>   -   if (!daemonize())
>   -   daemonized = 

Re: [PATCH] clone: Warn if clone lacks LICENSE or COPYING file

[Kevin D]

On Sat, Mar 21, 2015 at 02:06:33PM -0400, David A. Wheeler wrote:
> Warn cloners if there is no LICENSE* or COPYING* file that makes
> the license clear.  This is a useful warning, because if there is
> no license somewhere, then local copyright laws (which forbid many uses)
> and terms of service apply - and the cloner may not be expecting that.
> Many projects accidentally omit a license, so this is common enough to note.
> For more info on the issue, feel free to see:
> http://choosealicense.com/no-license/
> http://www.wired.com/2013/07/github-licenses/
> https://twitter.com/stephenrwalli/status/247597785069789184
> 

LWN article that lead to this patch: https://lwn.net/Articles/636261/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/GSoC] Proposal Draft: Unifying git branch -l, git tag -l, and git for-each-ref

[Jeff King]

On Mon, Mar 23, 2015 at 06:39:20PM +0530, karthik nayak wrote:

> All three commands select a subset of the repository’s refs and print the
> result. There has been an attempt to unify these commands by Jeff King[3]. I
> plan on continuing his work[4] and using his approach to tackle this
> project.

I would be cautious about the work in my for-each-ref-contains-wip
branch. At one point it was reasonably solid, but it's now a year and a
half old, and I've been rebasing it without paying _too_ much attention
to correctness. I think some subtle bugs have been introduced as it has
been carried forward.

Also, the very first patch (factoring out the contains traversal) is
probably better served by this series:

  http://thread.gmane.org/gmane.comp.version-control.git/252472

I don't remember all of the issues offhand that need to be addressed in
it, but there were plenty of review comments.

> For extended selection behaviour such as ‘--contains’ or ‘--merged’ we could
> implement these within
> the library by providing functions which closely mimic the current methods
> used individually by ‘branch -l’ and ‘tag -l’. For eg to implement
> ‘--merged’ we implement a ‘compute_merge()’ function, which with the help of
> the revision API’s will be able to perform the same function as ‘branch -l
> --merged’.

One trick with making a library-like interface is that some of the
selection routines can work on a "streaming" list of refs (i.e., as we
see each ref we can say "yes" or "no") and some must wait until the end
(e.g., --merged does a single big merge traversal). It's probably not
the end of the world to just always collect all the refs, then filter
them, then sort them, then print them. It may delay the start of output
in some minor cases, but I doubt that's a big deal (and anyway, the
packed-refs code will load them all into an array anyway, so collecting
them in a second array is probably not a big deal).

> For formatting functionality provided by ‘for-each-ref’ we replicate the
> ‘show_ref’ function in ‘for-each-ref.c’ where the format is given to the
> function and the function uses the format to obtain atom values and prints
> the corresponding atom values to the screen. This feature would allow us to
> provide format functionality which could act as a base for the ‘-v’ option
> also.

Yeah, I'd really like to see "--format" for "git branch", and have "-v"
just feed that a hard-coded format string (or even a configurable one).

> Although Jeff has built a really good base to build upon, I shall use
> his work as more of a reference and work on unification of the three
> commands from scratch.

Good. :)

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: About GSoc idea.

[Jeff King]

On Wed, Mar 25, 2015 at 08:36:41PM +0530, Shanti Swarup Tunga wrote:

> Duy Nguyen and Stephen Robin , the two developers worked
> on converting git-pull.sh to C code . But in the idea page it is
> written that we should start with git-pull.sh. Should I worked on
> "git-pull.sh" or other shell script for the GSoc.

You don't have to start with git-pull; the ideas page is mostly about
suggesting a direction. However, my impression was that the work that
has been done so far on git-pull is far from complete (I didn't look at
it closely, though). So there may be more to do there, too.

-Peff

PS You may try cc-ing people relevant to what you're posting, which is a
   good way of making sure you get their attention.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: What's cooking in git.git (Mar 2015, #08; Mon, 23)

[Jeff King]

On Tue, Mar 24, 2015 at 03:21:24PM -0700, Junio C Hamano wrote:

> > * pw/remote-set-url-fetch (2014-11-26) 1 commit
> >  - remote: add --fetch and --both options to set-url
> 
> This has not seen any activity for a few months since $gmane/261483; 
> is anybody still interested in resurrecting it?

I actually thought this had been merged. I was happy enough with the v4
you linked above, though it looks like you had some minor-ish comments.
I do not personally have a big interest in it and wasn't planning
anything else on it. But if Peter is still interested, I think it is
close to ready, and I'd be happy to do another round of review.

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFH/PATCH] git-svn: adjust info to svn 1.7 and 1.8

[Michael J Gruber]

Michael J Gruber venit, vidit, dixit 24.03.2015 16:10:
> t9119 refuses to run with svn versions greater than 1.6 since "git svn
> info" does not even try to match the output of "svn info" for later
> versions.
> 
> Adjust "git svn info" to match these versions and make t9119 run with
> them. This requires the following changes:
> 
> * compute checksums with SHA1 instead of MD5 with svn >= 1.7.0
> * omit the line "Revision: 0" for added content with svn >= 1.8.0 (TBC)
> * print the "Repository UUID" line even for added content with svn >=
>   1.8.0 (TBC)
> * add a "Relative URL" line for svn >= 1.8.0
> * add a "Working Copy Root Path" line for svn >= 1.8.0 (TBC, RFH)
> 
> Signed-off-by: Michael J Gruber 
> ---
> 
> Notes:
> While trying to increase my test run coverage I noticed that most of us 
> won't
> run t9119 at all. Bad bad.
> 
> My svn is 1.8.11 (r1643975) on Fedora 21.
> 
> I would appreciate help with the following items:
> 
> TBC = to be confirmed: confirm the svn version where this change kicked 
> it,
> or run this patch and t9119 with an svn version other than mine. Please
> run with "-v" to make sure only the RFH item fails, see below.
> 
> RFH = request for help: I couldn't figure out how to get the working
> copy root path in cmd_info.
> 
> 18 subtests will fail because of the RFH item.

I've figured out the exact revisions meanwhile - there's a git repo for
svn :)

I would appreciate help with the RFH item, though: How to teach "git svn
info" to output the "Working Copy Root Path"?

Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] git-push.txt: clean up force-with-lease wording

[Phil Hord]

The help text for the --force-with-lease option to git-push
does not parse cleanly.  Clean up the wording and syntax to
be more sensible.  Also remove redundant information in the
"--force-with-lease alone" description.

Signed-off-by: Phil Hord 
---
 Documentation/git-push.txt | 14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 5171086..863c30c 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -157,9 +157,8 @@ already exists on the remote side.
Usually, "git push" refuses to update a remote ref that is
not an ancestor of the local ref used to overwrite it.
 +
-This option bypasses the check, but instead requires that the
-current value of the ref to be the expected value.  "git push"
-fails otherwise.
+This option overrides this restriction if the current value of the
+remote ref is the expected value.  "git push" fails otherwise.
 +
 Imagine that you have to rebase what you have already published.
 You will have to bypass the "must fast-forward" rule in order to
@@ -171,15 +170,14 @@ commit, and blindly pushing with `--force` will lose her 
work.
 This option allows you to say that you expect the history you are
 updating is what you rebased and want to replace. If the remote ref
 still points at the commit you specified, you can be sure that no
-other people did anything to the ref (it is like taking a "lease" on
-the ref without explicitly locking it, and you update the ref while
-making sure that your earlier "lease" is still valid).
+other people did anything to the ref. It is like taking a "lease" on
+the ref without explicitly locking it, and the remote ref is updated
+only if the "lease" is still valid.
 +
 `--force-with-lease` alone, without specifying the details, will protect
 all remote refs that are going to be updated by requiring their
 current value to be the same as the remote-tracking branch we have
-for them, unless specified with a `--force-with-lease=:`
-option that explicitly states what the expected value is.
+for them.
 +
 `--force-with-lease=`, without specifying the expected value, will
 protect the named ref (alone), if it is going to be updated, by
-- 
2.3.3.377.gdac1145

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: A good time to pull from your gitk tree?

[Marc Branchaud]

On 15-03-24 07:06 PM, Paul Mackerras wrote:
> On Mon, Mar 23, 2015 at 12:03:37PM -0700, Junio C Hamano wrote:
>>
>> Is it a good time for me to pull from you, or do you recommend me to
>> wait for a bit, expecting more?  We'll go in the pre-release freeze
>> soon-ish, so I thought I should ping.
> 
> Now is a good time to pull from the usual place, thanks.

Paul, could you react to the gitk window-title patches I've posted:

http://news.gmane.org/find-root.php?group=gmane.comp.version-control.git&article=262080

Thanks!

M.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] merge: deprecate 'git merge HEAD ' syntax

[Eric Sunshine]

On Thu, Mar 26, 2015 at 12:58 AM, Junio C Hamano  wrote:
> We had this in "git merge" manual for eternity:
>
> 'git merge'  HEAD ...
>
> [This] syntax ( `HEAD` ...) is supported for
> historical reasons.  Do not use it from the command line or in
> new scripts.  It is the same as `git merge -m  ...`.
>
> I wanted to see how much damage we would incur to people by checking
> what the damage to _our_ system, including the test scripts, if we
> dropped the support for the syntax.  The last time I tried this, I
> thought that replacing the use of this syntax in "git pull" with its
> obvious and trivial rewrite 'git merge -m  ' broke some
> output, and that is the primary reason why I stayed away from trying
> this again, but it no longer seems to be the case with today's code
> for some reason.
>
> There are quite a few fallouts in the test scripts, and it turns out
> that "git cvsimport" also uses this old syntax to record a merge.
>
> Judging from this result, I would not be surprised if dropping the
> support of the old syntax broke scripts people have written and been
> relying on for the past ten years.  But at least we can start the
> deprecation process by throwing a warning message when the syntax is
> used.
>
> With luck, we might be able to drop the support in a few years.
>
> Signed-off-by: Junio C Hamano 
> ---
> diff --git a/builtin/merge.c b/builtin/merge.c
> index 3b0f8f9..0795358 100644
> --- a/builtin/merge.c
> +++ b/builtin/merge.c
> @@ -1182,6 +1182,7 @@ int cmd_merge(int argc, const char **argv, const char 
> *prefix)
>
> if (!have_message && head_commit &&
> is_old_style_invocation(argc, argv, head_commit->object.sha1)) {
> +   warning("old-style 'git merge  HEAD ' is 
> deprecated.");

To be a bit more helpful, perhaps point the user at "git merge -m
 ..." as the recommended replacement?

> strbuf_addstr(&merge_msg, argv[0]);
> head_arg = argv[1];
> argv += 2;
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: What's cooking in git.git (Sep 2014, #01; Tue, 2)

[Tommy38]

That’s great dear, can you share link for those  cooking videos
   too. Actually I am a new learner and I need
detailed information to execute everything properly. Thanks in advance for
your help.




--
View this message in context: 
http://git.661346.n2.nabble.com/What-s-cooking-in-git-git-Sep-2014-01-Tue-2-tp7617955p7627922.html
Sent from the git mailing list archive at Nabble.com.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] git submodule purge

[Patrick Steinhardt]

On Wed, Mar 25, 2015 at 08:47:59PM +0100, Jens Lehmann wrote:
> Am 25.03.2015 um 10:06 schrieb Patrick Steinhardt:
> > On Mon, Mar 23, 2015 at 10:32:27PM +0100, Jens Lehmann wrote:
> >> Am 17.03.2015 um 08:56 schrieb Patrick Steinhardt:
[snip]
> >> Hmm, cmd_deinit() seems to cope with submodules removed by the
> >> user just fine (as long as they are still present in the index).
> >> To me it feels natural to extend deinit to remove the repo from
> >> .git/modules too when --purge is given (as long as no unpushed
> >> commits are present or -f is given).
> >>
> >>> `git gc` feels saner in that regard, but I don't think it would
> >>> be easy to spot for users as this command is in general not used
> >>> very frequently by them. One could argue though that it does not
> >>> need to be discoverable.
> >>
> >> The error message of "git submodule deinit --purge" for a
> >> submodule that isn't recorded in the index anymore could point
> >> the user to the appropriate gc command. But how do we tell gc
> >> which submodule it should purge? "--purge="
> >> maybe?
> >
> > This might work, but at least the option would need to provide a
> > hint to the user that it has something to do with submodules. So
> > if the feature was implemented by `git gc` I'd rather name the
> > parameter "--purge-submodule=" which in my
> > opinion clearly states its intention, even though it is longer to
> > type. But with working bash-completion this should be non-issue,
> > especially as this command would not need to be run frequently.
> 
> Agreed.
> 
> > That said, I think by now I agree with the common (?) opinion
> > that the command is best placed in `git submodule deinit --purge`
> > and I will likely implement it there.
> 
> Me thinks that makes sense. But be aware that this will only work
> for those submodules that are still present in the current index.
> 
> > Optionally I could
> > implement `git gc --purge-submodule=` as a second
> > way to access the feature so that we have a way of purging them
> > without using the submodules-interface. I doubt though that this
> > will provide much of a benefit as the user still has to be aware
> > that he is working with submodules as he has to provide the
> > `--purge-submodule` option, so there is not much to be gained by
> > this.
> 
> Hmm, I still believe cleaning up a submodule repo which is already
> deinited makes sense. Using 'rm -rf .git/modules/'
> will work just fine, but is missing any safeguards. The deinit
> command takes submodule paths, not submodule names. So it looks
> to me like 'git gc --purge-submodule=' would make
> sense here (and this command should check that the submodule has
> already been deinited and fail otherwise telling the user so).

Ah, okay. I thought your intention was to provide `git gc
--purge-sm` _instead_ of `git sm deinit --purge`. Guess it makes
sense to have both available for the different use cases
(explicitly removing a submodule vs removing unreferenced ones).
I guess one could even provide another option
`--purge-submodules` in addition to `--purge-sm=` that
will remove all deinitialized submodules without local commits.
Maybe its desirable to have a `--dry-run` flag as well that would
print which repositories would be deleted by `--purge-sms`.


Patrick


signature.asc
Description: PGP signature

Re: [PATCH v5 3/3] t0302: test credential-store support for XDG_CONFIG_HOME

[Matthieu Moy]

Paul Tan  writes:

> On Wed, Mar 25, 2015 at 01:25:07PM -0700, Junio C Hamano wrote:
>> Junio C Hamano  writes:
>> I've already queued the following and merged it to 'next'.
>
> Thanks Matthieu and Eric for your reviews, and Johannes for following up
> on this.
>
> Will keep in view XDG support for ~/.git-credential-cache next because I
> don't like to leave things unfinished, unless we want to keep it around
> as a microproject. Perhaps home_config_paths() can also be
> simplified/removed because it hardcodes '~/.gitconfig'.

I may be able to get some students to work on it in May-June (I teach in
Ensimag, a french computer-science school and offer "contribute to
open-source" as an end-of-year project), but no guarantee. If you want
to do it before, just do it.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] merge: deprecate 'git merge HEAD ' syntax

[Jeff King]

On Wed, Mar 25, 2015 at 09:58:45PM -0700, Junio C Hamano wrote:

> We had this in "git merge" manual for eternity:
> 
> 'git merge'  HEAD ...
> 
> [This] syntax ( `HEAD` ...) is supported for
> historical reasons.  Do not use it from the command line or in
> new scripts.  It is the same as `git merge -m  ...`.

It would be nice to see this ancient wart ago. I agree we need a
deprecation period, though, as you've outlined here.

>  builtin/merge.c   | 1 +
>  git-cvsimport.perl| 2 +-
>  git-pull.sh   | 2 +-
>  t/t3402-rebase-merge.sh   | 2 +-
>  t/t6021-merge-criss-cross.sh  | 6 +++---
>  t/t9402-git-cvsserver-refs.sh | 2 +-
>  6 files changed, 8 insertions(+), 7 deletions(-)

Maybe squash in:

diff --git a/t/t6020-merge-df.sh b/t/t6020-merge-df.sh
index 27c3d73..2af1bee 100755
--- a/t/t6020-merge-df.sh
+++ b/t/t6020-merge-df.sh
@@ -24,7 +24,7 @@ test_expect_success 'prepare repository' '
 '
 
 test_expect_success 'Merge with d/f conflicts' '
-   test_expect_code 1 git merge "merge msg" B master
+   test_expect_code 1 git merge -m "merge msg" master
 '
 
 test_expect_success 'F/D conflict' '


We do not call it HEAD here, but the setup test just before has put us
on branch B, so I think it is equivalent.

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] docs: Clarify what git-rebase's "--preserve-merges" does

[Sebastian Schuberth]

Ignoring a merge sounds like ignoring the changes a merge commit
introduces altogether, as if the merge commit was skipped or dropped from
history. But that is not what happens if this options is not specified.
Instead, what happens is that the separate commits a merge commit
introduces are replayed in order, and only any possible merge conflict
resolutions are ignored. Get this straight in the docs.

Also, do not say that merge commits are *tried* to be recreated. They are
recreated, but possibly with conflicts, which in turn are likely to be
different from any original conflicts. Still recreating a merge commit does
not just silently fail in any case, which is how "try to recreate" might
sound.

Signed-off-by: Sebastian Schuberth 
---
 Documentation/git-rebase.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index d728030..3a6d139 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -362,7 +362,7 @@ default is `--no-fork-point`, otherwise the
default is `--fork-point`.

 -p::
 --preserve-merges::
-Instead of ignoring merges, try to recreate them.
+Recreate merge commits instead of replaying commits a merge
commit introduces.
 +
 This uses the `--interactive` machinery internally, but combining it
 with the `--interactive` option explicitly is generally not a good
-- 
1.9.5.msysgit.1
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] config.c: split some variables to $GIT_DIR/config.worktree

[Nguyễn Thái Ngọc Duy]

When you define $GIT_DIR/info/config.worktree, which contains of
gitignore-style patterns (*), config variables that match these
patterns will be saved in $GIT_DIR/config.worktree instead of
$GIT_DIR/config.

On the surface, they are just like any other variables. You can read
or modify them with `git config` command, or config_* API. Underneath,
they are always stored in $GIT_DIR/config.worktree instead of
$GIT_DIR/config (and never in $HOME/.gitconfig or /etc/gitconfig)

The reason for this split is, as the name implies, for
worktree-specific configuration. When the same repo is attached to
more than one worktree, we can't use $GIT_DIR/config to store worktree
specific stuff because it's shared across worktrees.

(*) Config variable names are separated by dots. However as this is a
quick and dirty patch to experiment with submodules and multiple
worktrees, you must substitute dots with slashes when writing these
patterns, for now. E.g. write "remote/*/foo" instead of "remote.*.foo"

Signed-off-by: Nguyễn Thái Ngọc Duy 
---
 Something for Max to play with if he's still experimenting with
 multiple worktree support for submodules :-) It's far from perfect,
 but good enough for this purpose.

 Documentation/config.txt |  6 -
 builtin/config.c |  8 ++
 config.c | 67 
 t/t1300-repo-config.sh   | 34 
 4 files changed, 114 insertions(+), 1 deletion(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 2700a1b..6d00f49 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -2,11 +2,15 @@ CONFIGURATION FILE
 --
 
 The Git configuration file contains a number of variables that affect
-the Git commands' behavior. The `.git/config` file in each repository
+the Git commands' behavior. The `.git/config` and `.git/config.worktree`
+files in each repository
 is used to store the configuration for that repository, and
 `$HOME/.gitconfig` is used to store a per-user configuration as
 fallback values for the `.git/config` file. The file `/etc/gitconfig`
 can be used to store a system-wide default configuration.
+If `.git/info/core.worktree` exists, it contains gitignore-style
+patterns. Variables that match these patterns can only be contained in
+`.git/config.worktree`.
 
 The configuration variables are used by both the Git plumbing
 and the porcelains. The variables are divided into sections, wherein
diff --git a/builtin/config.c b/builtin/config.c
index 8cc2604..4ca8fc2 100644
--- a/builtin/config.c
+++ b/builtin/config.c
@@ -555,6 +555,14 @@ int cmd_config(int argc, const char **argv, const char 
*prefix)
usage_with_options(builtin_config_usage, 
builtin_config_options);
}
 
+   /*
+* For set operations, --local could be either config or
+* config.worktree. Let config.c determine the path based on
+* config keys.
+*/
+   if (use_local_config && actions != ACTION_LIST)
+   given_config_source.file = NULL;
+
if (actions == ACTION_LIST) {
check_argc(argc, 0, 0);
if (git_config_with_options(show_all_config, NULL,
diff --git a/config.c b/config.c
index 15a2983..f68eb6a 100644
--- a/config.c
+++ b/config.c
@@ -12,6 +12,7 @@
 #include "quote.h"
 #include "hashmap.h"
 #include "string-list.h"
+#include "dir.h"
 
 struct config_source {
struct config_source *prev;
@@ -37,6 +38,7 @@ struct config_source {
 };
 
 static struct config_source *cf;
+static struct exclude_list config_local;
 
 static int zlib_compression_seen;
 
@@ -84,6 +86,34 @@ static long config_buf_ftell(struct config_source *conf)
return conf->u.buf.pos;
 }
 
+static int is_config_local(const char *key_)
+{
+   static struct strbuf key = STRBUF_INIT;
+   static int loaded;
+   int i, dtype;
+
+   if (!loaded) {
+   add_excludes_from_file_to_list(git_path("info/config.worktree"),
+  "", 0, &config_local, 0);
+   loaded = 1;
+   }
+
+   if (!config_local.nr)
+   return 0;
+
+   strbuf_reset(&key);
+   strbuf_addstr(&key, key_);
+   for (i = 0; i < key.len; i++) {
+   if (key.buf[i] == '.')
+   key.buf[i] = '/';
+   else
+   key.buf[i] = tolower(key.buf[i]);
+   }
+   dtype = DT_REG;
+   return is_excluded_from_list(key.buf, key.len, "", &dtype,
+&config_local) > 0;
+}
+
 #define MAX_INCLUDE_DEPTH 10
 static const char include_depth_advice[] =
 "exceeded maximum include depth (%d) while including\n"
@@ -1167,6 +1197,15 @@ int git_config_system(void)
return !git_env_bool("GIT_CONFIG_NOSYSTEM", 0);
 }
 
+static int config_local_filter(const char *var, const char *value, void *data)
+{
+   struct config_include_data *inc = data;
+

Re: very weird behaviour with

[Kirill Marchuk]

Kirill Marchuk <62mkv  mail.ru> writes:

> 
> Hi everyone
> 
>   I'm totally stuck with a following problem:
(censor cut)
...
> 
> But I believe that it might be due to my total misunderstanding of something
> 
> Anyway, I totally appreciate your help !
> 
> Thanks a lot
> 
> Kirill, frustrated unexperienced git user...
> 
> 

Hi Again

With "git subtree" today I have had even worse experience: 

1) git checkout test
2) git branch test-tmp
3) mv adminUI adminUI2 (because otherwise errors..)
4) git commit -a -m "Renamed adminUI" 
5) git subtree add --prefix=adminUI adminui-origin/test --squash
6) mv adminUI adminUI2 (because I don't want here the "deploy" versions)
7) git commit -a -m "Added adminui as subtree"
8) git merge develop (!! it went smoothly, but... see below)
9) git checkout adminui-test
10) git subtree merge --prefix=adminUI test-tmp
11) git push adminui-origin test-adminui:test
(instead of 9-11 I've tried to use "git subtree push", it's basically the
same, I believe, only takes FAR more time to complete)

I was very glad and happy. Unless I've realized that, in fact, step 7 did
not proceed as it was intended to (by me, at least)

It has 2 parents, and 2 diffs, and one of them shows exactly what it has to
show (i.e. diff between tips of "develop" and "test-tmp"), but the files on
the commit snapshot were left unchanged (I cannot imagine how could that
happen, but that did)

If I modify files and commit them RIGHT INTO test-tmp branch, all the rest
goes fine (so far), but that unability to merge from "develop" is something
that's killing the whole point of it :(( 

I believe I am not the only one on this mailing list, so pleeease... 

Kirill


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] docs: Clarify "preserve" option wording for git-pull

[Sebastian Schuberth]

Before this path, the "also" sounded as if "preserve" was doing a rebase
as additional work that "true" would not do. Clarify this by saying
"still" instead of "also".

Signed-off-by: Sebastian Schuberth 
---
 Documentation/git-pull.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
index d3d236c..96829be 100644
--- a/Documentation/git-pull.txt
+++ b/Documentation/git-pull.txt
@@ -111,8 +111,8 @@ include::merge-options.txt[]
 was rebased since last fetched, the rebase uses that information
 to avoid rebasing non-local changes.
 +
-When preserve, also rebase the current branch on top of the upstream
-branch, but pass `--preserve-merges` along to `git rebase` so that
+When preserve, still rebase the current branch on top of the upstream
+branch, but also pass `--preserve-merges` along to `git rebase` so that
 locally created merge commits will not be flattened.
 +
 When false, merge the current branch into the upstream branch.
-- 
1.9.5.msysgit.1
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] gc: save log from daemonized gc --auto and print it next time

[Nguyễn Thái Ngọc Duy]

While commit 9f673f9 (gc: config option for running --auto in
background - 2014-02-08) helps reduce some complaints about 'gc
--auto' hogging the terminal, it creates another set of problems.

The latest in this set is, as the result of daemonizing, stderr is
closed and all warnings are lost. This warning at the end of cmd_gc()
is particularly important because it tells the user how to avoid "gc
--auto" running repeatedly. Because stderr is closed, the user does
not know, naturally they complain about 'gc --auto' wasting CPU.

Besides reverting 9f673f9 and looking at the problem from another
angle, we could save the stderr in $GIT_DIR/gc.log. Next time, 'gc
--auto' will print the saved warnings, delete gc.log and exit.

Signed-off-by: Nguyễn Thái Ngọc Duy 
---
 The test is dropped. It does not feel good enough.. The rest of
 changes is minor
 
  diff --git a/builtin/gc.c b/builtin/gc.c
  index 07769a9..3886937 100644
  --- a/builtin/gc.c
  +++ b/builtin/gc.c
  @@ -32,8 +32,6 @@ static int aggressive_window = 250;
   static int gc_auto_threshold = 6700;
   static int gc_auto_pack_limit = 50;
   static int detach_auto = 1;
  -static struct strbuf log_filename = STRBUF_INIT;
  -static int daemonized;
   static const char *prune_expire = "2.weeks.ago";
   
   static struct argv_array pack_refs_cmd = ARGV_ARRAY_INIT;
  @@ -43,6 +41,8 @@ static struct argv_array prune = ARGV_ARRAY_INIT;
   static struct argv_array rerere = ARGV_ARRAY_INIT;
   
   static char *pidfile;
  +static struct strbuf log_filename = STRBUF_INIT;
  +static int daemonized;
   
   static void remove_pidfile(void)
   {
  @@ -338,7 +338,7 @@ int cmd_gc(int argc, const char **argv, const char 
*prefix)
struct strbuf sb = STRBUF_INIT;
   
if (strbuf_read_file(&sb, git_path("gc.log"), 0) > 0) {
  - warning(_("Last gc run reported the following, 
gc skipped"));
  + warning(_("skipping gc; last gc reported:"));
fputs(sb.buf, stderr);
strbuf_release(&sb);
/* let the next gc --auto run as usual */
  @@ -352,8 +352,7 @@ int cmd_gc(int argc, const char **argv, const char 
*prefix)
 * failure to daemonize is ok, we'll continue
 * in foreground
 */
  - if (!daemonize())
  - daemonized = 1;
  + daemonized = !daemonize();
}
} else
add_repack_all_option();

 builtin/gc.c | 36 +++-
 1 file changed, 35 insertions(+), 1 deletion(-)

diff --git a/builtin/gc.c b/builtin/gc.c
index 5c634af..3886937 100644
--- a/builtin/gc.c
+++ b/builtin/gc.c
@@ -41,9 +41,20 @@ static struct argv_array prune = ARGV_ARRAY_INIT;
 static struct argv_array rerere = ARGV_ARRAY_INIT;
 
 static char *pidfile;
+static struct strbuf log_filename = STRBUF_INIT;
+static int daemonized;
 
 static void remove_pidfile(void)
 {
+   if (daemonized && log_filename.len) {
+   struct stat st;
+
+   close(2);
+   if (stat(log_filename.buf, &st) ||
+   !st.st_size ||
+   rename(log_filename.buf, git_path("gc.log")))
+   unlink(log_filename.buf);
+   }
if (pidfile)
unlink(pidfile);
 }
@@ -324,13 +335,24 @@ int cmd_gc(int argc, const char **argv, const char 
*prefix)
fprintf(stderr, _("See \"git help gc\" for manual 
housekeeping.\n"));
}
if (detach_auto) {
+   struct strbuf sb = STRBUF_INIT;
+
+   if (strbuf_read_file(&sb, git_path("gc.log"), 0) > 0) {
+   warning(_("skipping gc; last gc reported:"));
+   fputs(sb.buf, stderr);
+   strbuf_release(&sb);
+   /* let the next gc --auto run as usual */
+   unlink(git_path("gc.log"));
+   return 0;
+   }
+
if (gc_before_repack())
return -1;
/*
 * failure to daemonize is ok, we'll continue
 * in foreground
 */
-   daemonize();
+   daemonized = !daemonize();
}
} else
add_repack_all_option();
@@ -343,6 +365,18 @@ int cmd_gc(int argc, const char **argv, const char *prefix)
name, (uintmax_t)pid);
}
 
+   if (daemonized) {
+   int fd;
+
+   strbuf_addstr(&log_filename, git_path("gc.log_XX"));
+   fd = xmkstemp(log_filename.buf);
+   if (fd >= 0) {
+

Re: [BUG] [PATCH] infinite loop due to broken symlink

[Petr Stodulka]

On 25.3.2015  23:53 Michael Haggerty wrote:

On 03/23/2015 05:04 PM, Petr Stodulka wrote:

git goes into an infinite loop due to broken symlink (minimal reproducer
[0]).  Affected code is in function
"resolve_ref_unsafe" in file refs.c - notice 'stat_ref'. There is comment
about problem with race condition, hovewer in that case it's regular broken
symlink which cause infinite loop.

Thanks for the bug report. I can confirm the problem. In fact, I noticed
the same problem when I was working on a refactoring in the area, but I
still haven't submitted those patches. Luckily, modern Git doesn't use
symlinks in the loose reference hierarchy, so most users will never
encounter this problem.

In fact I think it is only the open() call that can lead to the infinite
loop. Meanwhile, there is another problem caused by falling through the
symlink-handling code, namely that st reflects the lstat() of the
symlink rather than the stat() of the file that it points to.

My approach was to run stat() on the path if the symlink-handling code
falls through. You can see my work in progress in my GitHub repo [1].


Yes, I thought up about similar solution, but I wasn't sure about this way
because of race condition (I don't know well code of git yet). In the case
of approved lstat/stat patch, I am more familiar with this solution.

Possible patch could be something
like this:

---
diff --git a/refs.c b/refs.c
index e23542b..9efe8d2 100644
--- a/refs.c
+++ b/refs.c
@@ -1356,6 +1356,7 @@ static struct ref_dir *get_loose_refs(struct
ref_cache *refs)
  /* We allow "recursive" symbolic refs. Only within reason, though */
  #define MAXDEPTH 5
  #define MAXREFLEN (1024)
+#define MAXLOOP 1024

  /*
   * Called by resolve_gitlink_ref_recursive() after it failed to read
@@ -1482,6 +1483,7 @@ const char *resolve_ref_unsafe(const char
*refname, int resolve_flags, unsigned
 char buffer[256];
 static char refname_buffer[256];
 int bad_name = 0;
+int loop_counter = 0;

 if (flags)
 *flags = 0;
@@ -1546,7 +1548,8 @@ const char *resolve_ref_unsafe(const char
*refname, int resolve_flags, unsigned
 if (S_ISLNK(st.st_mode)) {
 len = readlink(path, buffer, sizeof(buffer)-1);
 if (len < 0) {
-   if (errno == ENOENT || errno == EINVAL)
+   if (loop_counter++ < MAXLOOP &&
+(errno == ENOENT || errno == EINVAL))
 /* inconsistent with lstat;
retry */
 goto stat_ref;
 else
@@ -1579,7 +1582,7 @@ const char *resolve_ref_unsafe(const char
*refname, int resolve_flags, unsigned
  */
 fd = open(path, O_RDONLY);
 if (fd < 0) {
-   if (errno == ENOENT)
+   if (loop_counter++ < MAXLOOP && errno == ENOENT)
 /* inconsistent with lstat; retry */
 goto stat_ref;
 else
---

If I understand well that simple check of broken symlink is not possible
due to race conditions.

This change also prevents the infinite loop, in fact in a more failproof
way that doesn't depend on errno values being interpreted correctly. I
would suggest a few stylistic changes, like for example here [2]. On the
other hand, this change doesn't solve the lstat()/stat() problem.

Nevertheless, I wouldn't object to a fix like this being accepted in
addition to the stat() fix when it's ready. It doesn't hurt to wear both
a belt *and* suspenders.

Michael

[1] https://github.com/mhagger/git, branch "wip/refactor-resolve-ref".
 See especially commit d2425d8ac8cf73494b318078b92f5b1c510a68fb.
[2] https://github.com/mhagger/git, branch "ref-broken-symlinks"

When stat/lstat  is ready, probably this will not be valuable anymore, 
but it
could be reliable 'stop' for some unexpected/unknown possibly ways in 
future.


Petr.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html