Re: [PATCH 5/5] git-worktree.txt: mention about the config file split

[Eric Sunshine]

On Wed, Dec 2, 2015 at 2:13 PM, Nguyễn Thái Ngọc Duy  wrote:
> Signed-off-by: Nguyễn Thái Ngọc Duy 
> ---
> diff --git a/Documentation/git-worktree.txt b/Documentation/git-worktree.txt
> @@ -147,6 +147,19 @@ to `/path/main/.git/worktrees/test-next` then a file 
> named
>  `test-next` entry from being pruned.  See
>  linkgit:gitrepository-layout[5] for details.
>
> +Similar to the file system split in ".git", the repository config file
> +is also split. Certain variables, for example core.worktree, are
> +per-worktree while the majority of variables are still shared (see
> +linkgit:git-config[1] for details). Shared variables and per-working
> +tree ones that belong to the main working tree are in .git/config.
> +Per-working tree variables for working tree X are in
> +$GIT_COMMON_DIR/worktrees/X/config.worktree. Even though per-working

Existing examples in the DETAILS section call this "test-next" rather
than "X", so perhaps s/X/test-next/g ?

> +tree variables for the main working tree are in the default config
> +place, they are invisible from all linked working trees.  You can make
> +more config variables per-working tree by adding them in
> +.git/info/config.worktree (see linkgit:gitrepository-layout[5] for
> +details).
> +
>  LIST OUTPUT FORMAT
>  --
>  The worktree list command has two output formats.  The default format shows 
> the
> --
> 2.2.0.513.g477eb31
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/5] config.c: move worktree-specific variables to .git/worktrees/...

[Duy Nguyen]

On Sun, Dec 6, 2015 at 8:47 AM, Eric Sunshine  wrote:
> On Wed, Dec 2, 2015 at 2:13 PM, Nguyễn Thái Ngọc Duy  
> wrote:
>> .git/info/config.worktree is a pattern list that splits .git/config in
>> to sets: the worktree set matches the patterns, the commmon set does
>> not.
>>
>> In normal worktrees, both sets are stored in .git/config. The
>> config.worktree has no effect. Nothing is changed.
>>
>> In linked worktrees, the common and worktree sets are read from and
>> saved to .git/config and .git/config.worktree respectively. Config
>> keys in .git/config that belong to the worktree set is ignored. Those
>> are for the main worktree only. Similarly, keys not matching the
>> patterns come from .git/config, duplicate keys from
>> .git/config.worktree are ignored.
>>
>> The effect is similar to the $GIT_DIR/$GIT_COMMON_DIR split, we can
>> define that some vars can be shared and some cannot. And as a result
>> of the $GIT_DIR/$GIT_COMMON_DIR split, config.worktree is actually
>> found at .git/worktrees//config.worktree.
>
> Why does this worktree-specific file need/have a .worktree suffix?

I think in the beginning it was supposed to support git-new-workdir as
well. With a separate name, you can symlink .git/config back to
original repo and create a new .git/config.worktree. The actual code
in this patch does not support this though. I guess as 'git worktree'
is maturing, we probably don't have to worry about git-new-workdir and
could drop .worktree suffix.

>> +static int is_config_local(const char *key_)
>> +{
>> +   static struct strbuf key = STRBUF_INIT;
>> +   int i, dtype;
>> +
>> +   if (!config_local.nr)
>> +   return 0;
>> +
>> +   strbuf_reset(&key);
>> +   strbuf_addstr(&key, key_);
>
> Why does 'key' need to be static considering that it is overwritten on
> each call and its value is never accessed after the function returns?

Mostly to avoid re-allocation because this function will be called for
every configuration variable. But this may be premature optimization.
On top of that, if we go with builtin per-worktree list only as being
discussed, then we can drop exclude machinery, we don't have to
preprocess "key" and we can finally kill this "strbuf key".

>> @@ -198,4 +198,30 @@ test_expect_success 'local clone from linked checkout' '
>> +test_expect_success 'setting worktree.foo goes to config.worktree' '
>> +   echo worKtree.Foo >> .git/info/config.worktree &&
>
> Perhaps? s/>> />/

Yeah. In the previous iteration, config.worktree would contain the
default list (core.worktree and stuff) so > may force following tests
to re-initialize config.worktree again. But that's now gone and >
makes more sense.

>> +test_expect_success 'shared config still goes to config' '
>> +   git config random.key randomValue &&
>> +   git --git-dir=wt.foo/.git config random.key >actual &&
>
> What about also testing the opposite scenario?
>
> git --git-dir=wt.foo/.git  config random.key randomValue &&
> git config random.key >actual &&

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

Re: Multiple fetches when unshallowing a shallow clone

[Duy Nguyen]

On Sun, Dec 6, 2015 at 8:01 AM, Jeff King  wrote:
> On Sun, Dec 06, 2015 at 01:37:18AM -0500, Jeff King wrote:
>
>> And indeed, replacing the logic with what I wrote does make the backfill
>> go away in my test case. But it's so far from what is there that I feel
>> like I must be missing something.
>
> I think one thing I was missing is that we need to just grab the
> _object_, but we need to realize that the ref needs updating[1]. So we
> cannot skip backfill of any tag that we do not already have, even if we
> already have the tag object.

It's probably worth adding a few comment lines about this. I did
search back commit history but did not get this.

> Which made me wonder why this:
>
>   git init parent &&
>   git -C parent commit --allow-empty -m one &&
>   git clone parent child &&
>   git -C parent commit --allow-empty -m two &&
>   git -C parent tag -m mytag foo &&
>   git -C parent commit --allow-empty -m three &&
>   git -C child fetch
>
> does not appear to need to backfill to pick up refs/tags/foo. But it
> does. It's just that it hits the quickfetch() code path and does not
> have to ask the other side for a pack. And that explains why it does hit
> in the --shallow case: we explicitly disable quickfetch in such cases.
>
> For the unshallow case, of course we could use it (but only for the
> second, backfill fetch). Something like this seems to work for me:
>
> diff --git a/builtin/fetch.c b/builtin/fetch.c
> index ed84963..b33b90f 100644
> --- a/builtin/fetch.c
> +++ b/builtin/fetch.c
> @@ -881,6 +881,8 @@ static void backfill_tags(struct transport *transport, 
> struct ref *ref_map)
>
> transport_set_option(transport, TRANS_OPT_FOLLOWTAGS, NULL);
> transport_set_option(transport, TRANS_OPT_DEPTH, "0");
> +   if (unshallow)
> +   depth = NULL;
> fetch_refs(transport, ref_map);
>
> if (gsecondary) {
>
> But I admit I am not at all confident that it doesn't cause other
> problems, or that it covers all cases. Even in a shallow repo, we should
> be able to quickfetch individual tags, shouldn't we?

Yes. depth is only non-NULL when you pass --depth (or --unshallow).
quickfetch should happen when you fetch without those options.

> I wonder if we could just always set "depth = NULL" here.

--unshallow is essentially --depth=, so I don't see why
--unshallow should be singled out here. We probably want to restore
depth back (or pass a flag to explicitly ignore the "depth" exception
in quickfetch). For multiple fetches, we spawn new commands so depth
being NULL does not harm. Just in case somebody tries to fetch a
couple more times in the same process in future.
-- 
Duy
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] git-p4: support multiple depot paths in p4 submit

[Lars Schneider]

Thanks for the patch! Do you see a way to demonstrate the bug in a test case 
similar to t9821 [1]?

Cheers,
Lars

[1] https://github.com/git/git/blob/master/t/t9821-git-p4-path-variations.sh

> On 05 Dec 2015, at 12:22, Sam Hocevar  wrote:
> 
> When submitting from a repository that was cloned using a client spec,
> use the full list of paths when ruling out files that are outside the
> view.  This fixes a bug where only files pertaining to the first path
> would be included in the p4 submit.
> 
> Signed-off-by: Sam Hocevar 
> ---
> git-p4.py | 11 +--
> 1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/git-p4.py b/git-p4.py
> index a79b6d8..210f100 100755
> --- a/git-p4.py
> +++ b/git-p4.py
> @@ -1253,6 +1253,8 @@ class P4Submit(Command, P4UserMap):
>Remove lines in the Files section that show changes to files
>outside the depot path we're committing into."""
> 
> +[upstream, settings] = findUpstreamBranchPoint()
> +
> template = ""
> inFilesSection = False
> for line in p4_read_pipe_lines(['change', '-o']):
> @@ -1265,8 +1267,13 @@ class P4Submit(Command, P4UserMap):
> lastTab = path.rfind("\t")
> if lastTab != -1:
> path = path[:lastTab]
> -if not p4PathStartsWith(path, self.depotPath):
> -continue
> +if settings.has_key('depot-paths'):
> +if not [p for p in settings['depot-paths']
> +if p4PathStartsWith(path, p)]:
> +continue
> +else:
> +if not p4PathStartsWith(path, self.depotPath):
> +continue
> else:
> inFilesSection = False
> else:
> -- 
> 2.6.2

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

[PATCH 0/2] gitk spacing/sizing tuning for HiDPI

[Giuseppe Bilotta]

On my HiDPI monitor, most elements in gitk are correctly rendered, with two
exceptions:

* when using ttk, some elements do not use the same fonts as gitk would use
  without, and since ttk picks _unscaled_ sizes this is very noticeable (and
borderline illegible); the first patch fixes this;
* the spacing between the checkboxes on top of the diff window are a little too
  tightly-spaced; the second patch adds a little bit of breathing space.

Giuseppe Bilotta (2):
  gitk: match ttk fonts to gitk fonts
  gitk: let .bleft.mid widgets 'breathe'

 gitk | 26 --
 1 file changed, 24 insertions(+), 2 deletions(-)

-- 
2.6.3.659.gfdd8f28

--
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] gitk: let .bleft.mid widgets 'breathe'

[Giuseppe Bilotta]

The widgets on top of the diff window are very tightly packed. Make
them breathe a little by adding an 'i'-spaced padding between them.
---
 gitk | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/gitk b/gitk
index e04264b..b621762 100755
--- a/gitk
+++ b/gitk
@@ -2361,6 +2361,9 @@ proc makewindow {} {
 ${NS}::frame .bleft.mid
 ${NS}::frame .bleft.bottom
 
+# gap between sub-widgets
+set wgap [font measure uifont "i"]
+
 ${NS}::button .bleft.top.search -text [mc "Search"] -command dosearch
 pack .bleft.top.search -side left -padx 5
 set sstring .bleft.top.sstring
@@ -2375,8 +2378,9 @@ proc makewindow {} {
-command changediffdisp -variable diffelide -value {0 1}
 ${NS}::radiobutton .bleft.mid.new -text [mc "New version"] \
-command changediffdisp -variable diffelide -value {1 0}
+
 ${NS}::label .bleft.mid.labeldiffcontext -text "  [mc "Lines of 
context"]: "
-pack .bleft.mid.diff .bleft.mid.old .bleft.mid.new -side left
+pack .bleft.mid.diff .bleft.mid.old .bleft.mid.new -side left -ipadx $wgap
 spinbox .bleft.mid.diffcontext -width 5 \
-from 0 -increment 1 -to 1000 \
-validate all -validatecommand "diffcontextvalidate %P" \
@@ -2384,7 +2388,7 @@ proc makewindow {} {
 .bleft.mid.diffcontext set $diffcontext
 trace add variable diffcontextstring write diffcontextchange
 lappend entries .bleft.mid.diffcontext
-pack .bleft.mid.labeldiffcontext .bleft.mid.diffcontext -side left
+pack .bleft.mid.labeldiffcontext .bleft.mid.diffcontext -side left -ipadx 
$wgap
 ${NS}::checkbutton .bleft.mid.ignspace -text [mc "Ignore space change"] \
-command changeignorespace -variable ignorespace
 pack .bleft.mid.ignspace -side left -padx 5
-- 
2.6.3.659.gfdd8f28

--
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] gitk: match ttk fonts to gitk fonts

[Giuseppe Bilotta]

The fonts set in setoptions aren't consistently picked up by ttk, who
uses its own predefined fonts. This is noticeable when switching
between using and not using ttk with custom fonts or in HiDPI settings
(where the default TTK fonts do _not_ respect tk sclaing).

Fix by mapping the ttk fontset to the one used by gitk internally.
---
 gitk | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/gitk b/gitk
index fcc606e..e04264b 100755
--- a/gitk
+++ b/gitk
@@ -1943,6 +1943,8 @@ proc confirm_popup {msg {owner .}} {
 }
 
 proc setoptions {} {
+global use_ttk
+
 if {[tk windowingsystem] ne "win32"} {
 option add *Panedwindow.showHandle 1 startupFile
 option add *Panedwindow.sashRelief raised startupFile
@@ -1965,6 +1967,18 @@ proc setoptions {} {
 option add *Listbox.font mainfont startupFile
 }
 
+proc setttkstyle {} {
+eval font configure TkDefaultFont [fontflags mainfont]
+eval font configure TkTextFont [fontflags textfont]
+eval font configure TkHeadingFont [fontflags mainfont]
+eval font configure TkCaptionFont [fontflags mainfont] -weight bold
+eval font configure TkTooltipFont [fontflags uifont]
+eval font configure TkFixedFont   [fontflags textfont]
+eval font configure TkIconFont[fontflags uifont]
+eval font configure TkMenuFont[fontflags uifont]
+eval font configure TkSmallCaptionFont [fontflags uifont]
+}
+
 # Make a menu and submenus.
 # m is the window name for the menu, items is the list of menu items to add.
 # Each item is a list {mc label type description options...}
@@ -12356,6 +12370,10 @@ if {![info exists have_ttk]} {
 set use_ttk [expr {$have_ttk && $want_ttk}]
 set NS [expr {$use_ttk ? "ttk" : ""}]
 
+if {$use_ttk} {
+setttkstyle
+}
+
 regexp {^git version ([\d.]*\d)} [exec git version] _ git_version
 
 set show_notes {}
-- 
2.6.3.659.gfdd8f28

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

[PATCH v2 2/2] clean: new option --exclude-from

[James]

From: James Rouzier 

Specify a file to read for exclude patterns.
---
 Documentation/git-clean.txt |  5 +++-
 builtin/clean.c | 15 ++--
 t/t7300-clean.sh| 60 +
 3 files changed, 77 insertions(+), 3 deletions(-)

diff --git a/Documentation/git-clean.txt b/Documentation/git-clean.txt
index 641681f..ef5dc41 100644
--- a/Documentation/git-clean.txt
+++ b/Documentation/git-clean.txt
@@ -8,7 +8,7 @@ git-clean - Remove untracked files from the working tree
 SYNOPSIS
 
 [verse]
-'git clean' [-d] [-f] [-i] [-n] [-q] [-e ] [-x | -X] [--] ...
+'git clean' [-d] [-f] [-i] [-n] [-q] [-e ] [--exclude-from=] 
[-x | -X] [--] ...
 
 DESCRIPTION
 ---
@@ -61,6 +61,9 @@ OPTIONS
$GIT_DIR/info/exclude, also consider these patterns to be in the
set of the ignore rules in effect.
 
+--exclude-from=::
+   Read exclude patterns from ; 1 per line.
+
 -x::
Don't use the standard ignore rules read from .gitignore (per
directory) and $GIT_DIR/info/exclude, but do still use the ignore
diff --git a/builtin/clean.c b/builtin/clean.c
index d7acb94..8e652f8 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
@@ -22,7 +22,7 @@ static struct string_list del_list = STRING_LIST_INIT_DUP;
 static unsigned int colopts;
 
 static const char *const builtin_clean_usage[] = {
-   N_("git clean [-d] [-f] [-i] [-n] [-q] [-e ] [-x | -X] [--] 
..."),
+   N_("git clean [-d] [-f] [-i] [-n] [-q] [-e ] 
[--exclude-from=] [-x | -X] [--] ..."),
NULL
 };
 
@@ -875,6 +875,14 @@ static void interactive_main_loop(void)
}
 }
 
+static int exclude_from_cb(const struct option *opt,
+const char *arg, int unset)
+{
+   struct dir_struct *dir = opt->value;
+   add_excludes_from_file(dir, arg);
+   return 0;
+}
+
 int cmd_clean(int argc, const char **argv, const char *prefix)
 {
int i, res;
@@ -898,12 +906,16 @@ int cmd_clean(int argc, const char **argv, const char 
*prefix)
N_("remove whole directories")),
{ OPTION_CALLBACK, 'e', "exclude", &exclude_list, N_("pattern"),
  N_("add  to ignore rules"), PARSE_OPT_NONEG, 
exclude_cb },
+   { OPTION_CALLBACK, 0, "exclude-from", &dir, N_("file"),
+   N_("read exclude patterns from "),
+   0, exclude_from_cb },
OPT_BOOL('x', NULL, &ignored, N_("remove ignored files, too")),
OPT_BOOL('X', NULL, &ignored_only,
N_("remove only ignored files")),
OPT_END()
};
 
+   memset(&dir, 0, sizeof(dir));
git_config(git_clean_config, NULL);
if (force < 0)
force = 0;
@@ -913,7 +925,6 @@ int cmd_clean(int argc, const char **argv, const char 
*prefix)
argc = parse_options(argc, argv, prefix, options, builtin_clean_usage,
 0);
 
-   memset(&dir, 0, sizeof(dir));
if (ignored_only)
dir.flags |= DIR_SHOW_IGNORED;
 
diff --git a/t/t7300-clean.sh b/t/t7300-clean.sh
index d555bb6..c6bfdda 100755
--- a/t/t7300-clean.sh
+++ b/t/t7300-clean.sh
@@ -628,6 +628,66 @@ test_expect_success 'git clean -e' '
test_path_is_file known
 '
 
+test_expect_success 'git clean --exclude-from' '
+   rm -fr repo &&
+   mkdir repo &&
+   cd repo &&
+   git init &&
+   touch known 1 2 3 &&
+   git add known &&
+   cat >.git/clean-exclude <<-\EOF &&
+   1
+   2
+   EOF
+   git clean -f --exclude-from=.git/clean-exclude &&
+   test_path_is_file 1 &&
+   test_path_is_file 2 &&
+   test_path_is_missing 3 &&
+   test_path_is_file known
+'
+
+test_expect_success 'git clean -e --exclude-from' '
+   rm -fr repo &&
+   mkdir repo &&
+   cd repo &&
+   git init &&
+   touch known 1 2 3 &&
+   git add known &&
+   echo 1 >> .git/clean-exclude &&
+   git clean -f -e 2 --exclude-from=.git/clean-exclude &&
+   test_path_is_file 1 &&
+   test_path_is_file 2 &&
+   test_path_is_missing 3 &&
+   test_path_is_file known
+'
+
+test_expect_success 'git clean --exclude-from --exclude-from' '
+   rm -fr repo &&
+   mkdir repo &&
+   git init &&
+   touch known 1 2 3 &&
+   git add known &&
+   cat >.git/clean-exclude1 <<-\EOF &&
+   1
+   EOF
+   cat >.git/clean-exclude2 <<-\EOF &&
+   2
+   EOF
+   git clean -f --exclude-from=.git/clean-exclude1 
--exclude-from=.git/clean-exclude2 &&
+   test_path_is_file 1 &&
+   test_path_is_file 2 &&
+   test_path_is_missing 3 &&
+   test_path_is_file known
+'
+
+test_expect_success 'git clean --exclude-from=BADFILE' '
+   rm -fr repo &&
+   mkdir repo &&
+   cd repo &&
+   git init &&
+   test_expect_code 128 git clean -f 
--exclude-from=.git/clean-exclude-not-th

[PATCH v2 1/2] modernize t7300

[James]

From: James Rouzier 

---
 t/t7300-clean.sh | 382 +++
 1 file changed, 190 insertions(+), 192 deletions(-)

diff --git a/t/t7300-clean.sh b/t/t7300-clean.sh
index 86ceb38..d555bb6 100755
--- a/t/t7300-clean.sh
+++ b/t/t7300-clean.sh
@@ -28,15 +28,15 @@ test_expect_success 'git clean with skip-worktree 
.gitignore' '
mkdir -p build docs &&
touch a.out src/part3.c docs/manual.txt obj.o build/lib.so &&
git clean &&
-   test -f Makefile &&
-   test -f README &&
-   test -f src/part1.c &&
-   test -f src/part2.c &&
-   test ! -f a.out &&
-   test ! -f src/part3.c &&
-   test -f docs/manual.txt &&
-   test -f obj.o &&
-   test -f build/lib.so &&
+   test_path_is_file Makefile &&
+   test_path_is_file README &&
+   test_path_is_file src/part1.c &&
+   test_path_is_file src/part2.c &&
+   test_path_is_missing a.out &&
+   test_path_is_missing src/part3.c &&
+   test_path_is_file docs/manual.txt &&
+   test_path_is_file obj.o &&
+   test_path_is_file build/lib.so &&
git update-index --no-skip-worktree .gitignore &&
git checkout .gitignore
 '
@@ -46,15 +46,15 @@ test_expect_success 'git clean' '
mkdir -p build docs &&
touch a.out src/part3.c docs/manual.txt obj.o build/lib.so &&
git clean &&
-   test -f Makefile &&
-   test -f README &&
-   test -f src/part1.c &&
-   test -f src/part2.c &&
-   test ! -f a.out &&
-   test ! -f src/part3.c &&
-   test -f docs/manual.txt &&
-   test -f obj.o &&
-   test -f build/lib.so
+   test_path_is_file Makefile &&
+   test_path_is_file README &&
+   test_path_is_file src/part1.c &&
+   test_path_is_file src/part2.c &&
+   test_path_is_missing a.out &&
+   test_path_is_missing src/part3.c &&
+   test_path_is_file docs/manual.txt &&
+   test_path_is_file obj.o &&
+   test_path_is_file build/lib.so
 
 '
 
@@ -63,15 +63,15 @@ test_expect_success 'git clean src/' '
mkdir -p build docs &&
touch a.out src/part3.c docs/manual.txt obj.o build/lib.so &&
git clean src/ &&
-   test -f Makefile &&
-   test -f README &&
-   test -f src/part1.c &&
-   test -f src/part2.c &&
-   test -f a.out &&
-   test ! -f src/part3.c &&
-   test -f docs/manual.txt &&
-   test -f obj.o &&
-   test -f build/lib.so
+   test_path_is_file Makefile &&
+   test_path_is_file README &&
+   test_path_is_file src/part1.c &&
+   test_path_is_file src/part2.c &&
+   test_path_is_file a.out &&
+   test_path_is_missing src/part3.c &&
+   test_path_is_file docs/manual.txt &&
+   test_path_is_file obj.o &&
+   test_path_is_file build/lib.so
 
 '
 
@@ -80,15 +80,15 @@ test_expect_success 'git clean src/ src/' '
mkdir -p build docs &&
touch a.out src/part3.c docs/manual.txt obj.o build/lib.so &&
git clean src/ src/ &&
-   test -f Makefile &&
-   test -f README &&
-   test -f src/part1.c &&
-   test -f src/part2.c &&
-   test -f a.out &&
-   test ! -f src/part3.c &&
-   test -f docs/manual.txt &&
-   test -f obj.o &&
-   test -f build/lib.so
+   test_path_is_file Makefile &&
+   test_path_is_file README &&
+   test_path_is_file src/part1.c &&
+   test_path_is_file src/part2.c &&
+   test_path_is_file a.out &&
+   test_path_is_missing src/part3.c &&
+   test_path_is_file docs/manual.txt &&
+   test_path_is_file obj.o &&
+   test_path_is_file build/lib.so
 
 '
 
@@ -97,16 +97,16 @@ test_expect_success 'git clean with prefix' '
mkdir -p build docs src/test &&
touch a.out src/part3.c docs/manual.txt obj.o build/lib.so src/test/1.c 
&&
(cd src/ && git clean) &&
-   test -f Makefile &&
-   test -f README &&
-   test -f src/part1.c &&
-   test -f src/part2.c &&
-   test -f a.out &&
-   test ! -f src/part3.c &&
-   test -f src/test/1.c &&
-   test -f docs/manual.txt &&
-   test -f obj.o &&
-   test -f build/lib.so
+   test_path_is_file Makefile &&
+   test_path_is_file README &&
+   test_path_is_file src/part1.c &&
+   test_path_is_file src/part2.c &&
+   test_path_is_file a.out &&
+   test_path_is_missing src/part3.c &&
+   test_path_is_file src/test/1.c &&
+   test_path_is_file docs/manual.txt &&
+   test_path_is_file obj.o &&
+   test_path_is_file build/lib.so
 
 '
 
@@ -160,16 +160,16 @@ test_expect_success 'git clean -d with prefix and path' '
mkdir -p build docs src/feature &&
touch a.out src/part3.c src/feature/file.c docs/manual.txt obj.o 
build/lib.so &&
(cd src/ && git clean -d feature/) &&
-   test -f Makefile &&
-   test -f README &&
-   test -f src/part1.c &&
-   test -f src/part2.c &&
-   test -f a.out &&
-   test -f src/part3.c &

Re: What's cooking in git.git (Dec 2015, #02; Fri, 4)

[Edmundo Carmona Antoranz]

Hi, Junio, Jeff!

On Fri, Dec 4, 2015 at 5:15 PM, Junio C Hamano  wrote:
> * ec/annotate-deleted (2015-11-20) 1 commit
>  - annotate: skip checking working tree if a revision is provided
>
>  Usability fix for annotate-specific " " syntax with deleted
>  files.
>
>  Waiting for review.

Is there something I have to do about it?

And, another thing, I had sent the fifth version of my patch about
progress for blame where I took care of all the comments hat Junio
stated before and I got no comments since. I hoped that patch would be
listed sometime but I didn't see it in this what's cooking or the
previous one. Maybe it's bellow your radar? Is there something else I
can to do about it? ($gmane/281677)

Thanks in advance!
--
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: best practices against long git rebase times?

[Andreas Krey]

On Fri, 04 Dec 2015 18:09:33 +, demerphq wrote:
...
> I bet you have a lot of refs; tags, or branches.

We do, but removing them doesn't noticably change the times
(12k refs vs. 120, mostly tags). I'm just running the
second series, the first (with many refs) ended
with rebasing over 3000 commits, for which git log -p
outputs 64 MByte, and the rebase takes 12 minutes.

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds 
Date: Fri, 22 Jan 2010 07:29:21 -0800
--
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: best practices against long git rebase times?

[Andreas Krey]

On Fri, 04 Dec 2015 15:31:03 +, John Keeping wrote:
...
> I'm pretty sure that you're right and the cherry-pick analysis is where
> the time is spent.

But I'm pretty surprised as to the amount of CPU time that goes there.

I'm now rebasing a single commit with a single blank line added,
and for 3000 new commits to rebase over (with 64 MByte of git log -
for them) it takes twelve minutes, or about for commits per second,
and all user CPU, no I/O. It's pretty linear in number of commits, too.

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds 
Date: Fri, 22 Jan 2010 07:29:21 -0800
--
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/RFC 3/3] ls-files/dir: use is_git_repo to detect submodules

[Andreas Krey]

On Sat, 05 Dec 2015 02:37:44 +, Jeff King wrote:
...
> Hrm. Weird. You'd think it would break with the existing code if I do
> this, then:
> 
...
> - (cd a/b/c; git init) &&
> + (cd a/b/c; git init && git commit --allow-empty -m foo) &&
>   git config remote.origin.url ../foo/bar.git &&
>   git submodule add ../bar/a/b/c ./a/b/c &&

I tried a -f here instead; did not work either.

I guess I will first wade through the other failures my 'fix'
causes to see the total damage.

...
> We know it is a git dir, but there is no sha1 for us to actually add as
> the gitlink entry.
> 
> If that is the case, then there is either some very tricky refactoring
> required,

Yes, it looks like the return code delivered need to be slightly different
dependent on the user.

> or what we are trying to do here is simply wrong. Maybe it
> would be simpler to just speed up resolve_gitlink_ref with a better data
> structure.

Which is what I did on square one, but now we already have a real fix
for git clean, and now it's even less advantageous the fix the consequence
(the submodule cache blowing up) instead of the cause (asking for it
in the first place).

I don't think we should let is_git_repository look for a valid(ish) HEAD.

Andreas

PS: I seem to not quite have send-email under control, the envelope from
seems to made the patches not reach the mailing list (nor me in the CC).

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds 
Date: Fri, 22 Jan 2010 07:29:21 -0800
--
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

Show total commit count of two authors or more authors into first author

[Jagan Teki]

I usually count commits as below command

$ git shortlog -s -n
   149  Jagan Teki
   148  Otavio Salvador
   143  Bo Shen
   137  Lokesh Vutla
   134  Minkyu Kang
   132  Marian Balakowicz
   129  Haavard Skinnemoen
   127  Holger Brunck
   124  Tim Harvey
   122  Jagannadha Teki
   120  Daniel Schwierzeck
   119  Eric Nelson
   118  Andy Fleming
   116  Jagannadha Sutradharudu Teki

Out of which below three names are with same author which changed
while submitted patches.
  149  Jagan Teki
  122  Jagannadha Teki
  116  Jagannadha Sutradharudu Teki

I need a command to show to add all commits and show first one as
   387 Jagan Teki

Can anyone help to do this?

thanks!
-- 
Jagan.
--
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: Show total commit count of two authors or more authors into first author

[Andreas Schwab]

Jagan Teki  writes:

> Out of which below three names are with same author which changed
> while submitted patches.
>   149  Jagan Teki
>   122  Jagannadha Teki
>   116  Jagannadha Sutradharudu Teki
>
> I need a command to show to add all commits and show first one as
>387 Jagan Teki
>
> Can anyone help to do this?

See the "MAPPING AUTHORS" section of git-shortlog(1).

   The .mailmap feature is used to coalesce together commits by the same
   person in the shortlog, where their name and/or email address was
   spelled differently.

   If the file .mailmap exists at the toplevel of the repository, or at
   the location pointed to by the mailmap.file or mailmap.blob
   configuration options, it is used to map author and committer names and
   email addresses to canonical real names and email addresses.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6] ls-files: Add eol diagnostics

[Torsten Bögershausen]

When working in a cross-platform environment, a user wants to
check if text files are stored normalized in the repository and if
.gitattributes are set appropriately.

Make it possible to let Git show the line endings in the index and
in the working tree and the effective text/eol attributes.

The end of line ("eolinfo") are shown like this:
"binary"   binary file
"text-no-eol"  text file without any EOL
"text-lf"  text file with LF
"text-crlf"text file with CRLF
"text-crlf-lf" text file with mixed line endings.

The effective text/eol attribute is one of these:
"", "-text", "text", "text=auto", "eol=lf", "eol=crlf"

git ls-files --eol gives an output like this:

i/text-no-eol   w/text-no-eol   attr/text=auto t/t5100/empty
i/binaryw/binaryattr/-text t/test-binary-2.png
i/text-lf   w/text-lf   attr/eol=lft/t5100/rfc2047-info-0007
i/text-lf   w/text-crlf attr/eol=crlf  doit.bat
i/text-crlf-lf  w/text-crlf-lf  attr/  locale/XX.po

Note that the output is meant to be human-readable and may change.

Signed-off-by: Torsten Bögershausen 
---
Thanks everybody for contributing to this patch, expecially Eric Sunshine
Changes since v5:
- shell here document without substitions (Thanks Eric)
Changes since v4:
- gather_convert_stats_ascii() is static (Thanks Ramsay)
Changes since v3:
- typos (thanks for careful review)
- Remove un-intended changes in check-attr.c (they should not have been there)
- Improved t0027 (Thanks Eric)
Changes since v2:
- Major rework
- New prefix, more common to what we use in Git (i/, w/ attr/)
- Only one option: git ls-files --eol (may be combined with -s or -o or -d
- Simplify the diagnostics: either the file is binary or text
  As empty files are not binary, they are text-no-eol
- Test cases in t0027

 Documentation/git-ls-files.txt |  22 +
 builtin/ls-files.c |  19 +++
 convert.c  |  86 
 convert.h  |   3 ++
 t/t0027-auto-crlf.sh   | 109 -
 5 files changed, 227 insertions(+), 12 deletions(-)

diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt
index e26f01f..8f29c99 100644
--- a/Documentation/git-ls-files.txt
+++ b/Documentation/git-ls-files.txt
@@ -12,6 +12,7 @@ SYNOPSIS
 'git ls-files' [-z] [-t] [-v]

(--[cached|deleted|others|ignored|stage|unmerged|killed|modified])*
(-[c|d|o|i|s|u|k|m])*
+   [--eol]
[-x |--exclude=]
[-X |--exclude-from=]
[--exclude-per-directory=]
@@ -147,6 +148,18 @@ a space) at the start of each line:
possible for manual inspection; the exact format may change at
any time.
 
+--eol::
+   Show line endings ("eolinfo") and the text/eol attributes 
("texteolattr") of files.
+   "eolinfo" is the file content identification used by Git when
+   the "text" attribute is "auto", or core.autocrlf != false.
+
+   "eolinfo" is either "" (when the the info is not available"), or one of 
"binary",
+   "text-no-eol", "text-lf", "text-crlf" or "text-crlf-lf".
+   The "texteolattr" can be "", "-text", "text", "text=auto", "eol=lf", 
"eol=crlf".
+
+   Both the content in the index ("i/") and the content in the working 
tree ("w/")
+   are shown for regular files, followed by the "texteolattr ("attr/").
+
 \--::
Do not interpret any more arguments as options.
 
@@ -161,6 +174,15 @@ which case it outputs:
 
 [ ]   
 
+'git ls-files --eol' will show
+   i/ w/ attr/ 
+
+'git ls-files --eol -o' will show
+   i/  w/ attr/ 
+
+'git ls-files --eol -s' will show
+[ ]   i/ w/ attr/ 
+
 'git ls-files --unmerged' and 'git ls-files --stage' can be used to examine
 detailed information on unmerged paths.
 
diff --git a/builtin/ls-files.c b/builtin/ls-files.c
index b6a7cb0..ef892bc 100644
--- a/builtin/ls-files.c
+++ b/builtin/ls-files.c
@@ -27,6 +27,7 @@ static int show_killed;
 static int show_valid_bit;
 static int line_terminator = '\n';
 static int debug_mode;
+static int show_eol;
 
 static const char *prefix;
 static int max_prefix_len;
@@ -47,6 +48,21 @@ static const char *tag_modified = "";
 static const char *tag_skip_worktree = "";
 static const char *tag_resolve_undo = "";
 
+static void write_eolinfo(const struct cache_entry *ce, const char *path)
+{
+   struct stat st;
+   const char *i_txt = "";
+   const char *w_txt = "";
+   if (!show_eol)
+   return;
+   if (ce && S_ISREG(ce->ce_mode))
+   i_txt = get_cached_convert_stats_ascii(ce->name);
+   if (!lstat(path, &st) && (S_ISREG(st.st_mode)))
+   w_txt = get_wt_convert_stats_ascii(path);
+   printf("i/%-13s w/%-13s attr/%-9s ", i_txt, w_txt,
+get_convert_attr_ascii(path));
+}
+
 static void write_name(const char *name)
 {
/*
@@ -68,6 +84

git subtree bug produces divergent descendants

[David Ware]

My group has run into a bug with "git-subtree split". Under some
circumstances a split created from a descendant of another earlier
split is not a descendant of that earlier split (thus blocking
pushes). We originally noticed this on v1.9.1 but have also checked it
on v2.6.3

When scanning the commits to produce the subtree it seems to skip
creating a new commit if any of the parent commits have the same tree
and instead uses that tree in its place. This is fine when the cause
is a branch that did not cause any changes to the subtree.  However it
creates an issue when the cause is both branches ending up with the
same tree through identical alterations (or more likely, one of the
branches has just a subset of the alterations on the other, such as a
branch just containing cherry-picks).

The attached bash script (makerepo.sh) reproduces the problem. To use
create an empty directory and run the script in it. The resulting
'master' branch has had the latest commits on the 'branch' branch
merged into it, so it follows that a subtree on 'folder/' at 'master'
should contain all the commits of a subtree on 'folder/' at 'branch'.
(These subtrees have been produced at 'subtree_tip' and
'subtree_branch' respectively.)

The attached patch (against v2.6.3) fixes the issue for the cases
we've encountered, however since we're not particularly familiar with
git internals we may not have approached this optimally. We suspect it
could be improved to also handle the cases where there are more than 2
parents.

Cheers,
Dave Ware


makerepo.sh
Description: Bourne shell script
From 4bdcd742e5f21d7af57de3e307741efede7d2c6c Mon Sep 17 00:00:00 2001
From: Dave Ware 
Date: Fri, 4 Dec 2015 16:30:03 +1300
Subject: [PATCH] Fix bug in git-subtree split.

A bug occurs in 'git-subtree split' where a merge is skipped even when
both parents act on the subtree, provided the merge results in a tree
identical to one of the parents. Fixed by copying the merge if at least
one parent is non-identical, and the non-identical parent is not an
ancestor of the identical parent.
---
 contrib/subtree/git-subtree.sh | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
index 9f06571..b837531 100755
--- a/contrib/subtree/git-subtree.sh
+++ b/contrib/subtree/git-subtree.sh
@@ -479,8 +479,16 @@ copy_or_skip()
 			p="$p -p $parent"
 		fi
 	done
-	
-	if [ -n "$identical" ]; then
+
+	copycommit=
+	if [ -n "$identical" ] && [ -n "$nonidentical" ]; then
+		extras=$(git rev-list --boundary $identical..$nonidentical)
+		if [ -n "$extras" ]; then
+			# we need to preserve history along the other branch
+			copycommit=1
+		fi
+	fi
+	if [ -n "$identical" ] && [ -z "$copycommit" ]; then
 		echo $identical
 	else
 		copy_commit $rev $tree "$p" || exit $?
-- 
1.9.1

Re: Show total commit count of two authors or more authors into first author

[Jagan Teki]

On 7 December 2015 at 01:01, Andreas Schwab  wrote:
> Jagan Teki  writes:
>
>> Out of which below three names are with same author which changed
>> while submitted patches.
>>   149  Jagan Teki
>>   122  Jagannadha Teki
>>   116  Jagannadha Sutradharudu Teki
>>
>> I need a command to show to add all commits and show first one as
>>387 Jagan Teki
>>
>> Can anyone help to do this?
>
> See the "MAPPING AUTHORS" section of git-shortlog(1).
>
>The .mailmap feature is used to coalesce together commits by the same
>person in the shortlog, where their name and/or email address was
>spelled differently.
>
>If the file .mailmap exists at the toplevel of the repository, or at
>the location pointed to by the mailmap.file or mailmap.blob
>configuration options, it is used to map author and committer names and
>email addresses to canonical real names and email addresses.

Thanks for the info, I'm able to map two author with e-mail but it's
not working when I group 3

$ .mailmap
Jagan Teki  Jagannadha Teki 

The above worked but how about 3 names mapping

$ .mailmap
Jagan Teki  Jagannadha Teki  Jagannadha
Sutradharudu Teki

Finally I need to map all 3 into Jagan Teki 

-- 
Jagan.
--
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: Show total commit count of two authors or more authors into first author

[brian m. carlson]

On Mon, Dec 07, 2015 at 01:45:19AM +0530, Jagan Teki wrote:
> Thanks for the info, I'm able to map two author with e-mail but it's
> not working when I group 3
> 
> $ .mailmap
> Jagan Teki  Jagannadha Teki 
> 
> The above worked but how about 3 names mapping
> 
> $ .mailmap
> Jagan Teki  Jagannadha Teki  Jagannadha
> Sutradharudu Teki
> 
> Finally I need to map all 3 into Jagan Teki 

You probably want to map two at a time.  So something like this:

  Jagan Teki  Jagannadha Teki 
  Jagan Teki  Jagannadha Sutradharudu Teki 
-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: PGP signature

git subtree bug produces divergent descendants

[David Ware]

My group has run into a bug with "git-subtree split". Under some
circumstances a split created from a descendant of another earlier
split is not a descendant of that earlier split (thus blocking
pushes). We originally noticed this on v1.9.1 but have also checked it
on v2.6.3

When scanning the commits to produce the subtree it seems to skip
creating a new commit if any of the parent commits have the same tree
and instead uses that tree in its place. This is fine when the cause
is a branch that did not cause any changes to the subtree.  However it
creates an issue when the cause is both branches ending up with the
same tree through identical alterations (or more likely, one of the
branches has just a subset of the alterations on the other, such as a
branch just containing cherry-picks).

The attached patch (against v2.6.3) includes a test that reproduces
the problem.  The created 'master' branch has had the latest commits
on the 'branch' branch merged into it, so it follows that a subtree on
'folder/' at 'master' (subtree_tip) should contain all the commits of
a subtree on 'folder/' at 'branch' (subtree_branch). Hence it should
be possible to push subtree_tip to subtree_branch.

The attached patch also fixes the issue for the cases we've
encountered, however since we're not particularly familiar with git
internals we may not have approached this optimally. We suspect it
could be improved to also handle the cases where there are more than 2
parents.

Cheers,
Dave Ware
From ce6e2bcb2116624082bf46663aa33c706fcab930 Mon Sep 17 00:00:00 2001
From: Dave Ware 
Date: Fri, 4 Dec 2015 16:30:03 +1300
Subject: [PATCH] Fix bug in git-subtree split.

A bug occurs in 'git-subtree split' where a merge is skipped even when
both parents act on the subtree, provided the merge results in a tree
identical to one of the parents. Fixed by copying the merge if at least
one parent is non-identical, and the non-identical parent is not an
ancestor of the identical parent.

Also adding a test case, this checks that a descendant can be pushed to
it's ancestor in this case.
---
 contrib/subtree/git-subtree.sh   | 12 +--
 contrib/subtree/t/t7901-subtree-split.sh | 62 
 2 files changed, 72 insertions(+), 2 deletions(-)
 create mode 100755 contrib/subtree/t/t7901-subtree-split.sh

diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
index 9f06571..b837531 100755
--- a/contrib/subtree/git-subtree.sh
+++ b/contrib/subtree/git-subtree.sh
@@ -479,8 +479,16 @@ copy_or_skip()
 			p="$p -p $parent"
 		fi
 	done
-	
-	if [ -n "$identical" ]; then
+
+	copycommit=
+	if [ -n "$identical" ] && [ -n "$nonidentical" ]; then
+		extras=$(git rev-list --boundary $identical..$nonidentical)
+		if [ -n "$extras" ]; then
+			# we need to preserve history along the other branch
+			copycommit=1
+		fi
+	fi
+	if [ -n "$identical" ] && [ -z "$copycommit" ]; then
 		echo $identical
 	else
 		copy_commit $rev $tree "$p" || exit $?
diff --git a/contrib/subtree/t/t7901-subtree-split.sh b/contrib/subtree/t/t7901-subtree-split.sh
new file mode 100755
index 000..0a1ea56
--- /dev/null
+++ b/contrib/subtree/t/t7901-subtree-split.sh
@@ -0,0 +1,62 @@
+#!/bin/bash
+
+test_description='Test for bug in subtree commit filtering'
+
+
+TEST_DIRECTORY=$(pwd)/../../../t
+export TEST_DIRECTORY
+
+. ../../../t/test-lib.sh
+
+
+test_expect_success 'subtree descendent check' '
+  mkdir git_subtree_split_check &&
+  cd git_subtree_split_check &&
+  git init &&
+
+  mkdir folder &&
+
+  echo a > folder/a &&
+  git add . &&
+  git commit -m "first commit" &&
+
+  git branch branch &&
+
+  echo 0 > folder/0 &&
+  git add . &&
+  git commit -m "adding 0 to folder" &&
+
+  echo b > folder/b &&
+  git add . &&
+  git commit -m "adding b to folder" &&
+  git rev-list HEAD -1 > cherry.rev &&
+
+  git checkout branch &&
+  echo text > textBranch.txt &&
+  git add . &&
+  git commit -m "commit to fiddle with branch: branch" &&
+
+  git cherry-pick $(cat cherry.rev) &&
+  git checkout master &&
+  git merge -m "merge" branch &&
+
+  git branch noop_branch &&
+
+  echo d > folder/d &&
+  git add . &&
+  git commit -m "adding d to folder" &&
+
+  git checkout noop_branch &&
+  echo moreText > anotherText.txt &&
+  git add . &&
+  git commit -m "irrelevant" &&
+
+  git checkout master &&
+  git merge -m "second merge" noop_branch &&
+
+  git subtree split --prefix folder/ --branch subtree_tip master &&
+  git subtree split --prefix folder/ --branch subtree_branch branch &&
+  git push . subtree_tip:subtree_branch
+  '
+
+test_done
-- 
1.9.1

Git 2.3.7 hangs on fetch but not clone

[Randall S. Becker]

I have some strange behaviour I am trying to diagnose on the NonStop port of
git 2.3.7. The situation is we have a *LARGE* cloned repository with some
local modifications of openssl, which we are trying to clone again for a
Jenkins build. The command:
git clone /local/openssl openssl
works fine and rapidly (well under 30 seconds), but with a newly created
empty repo, simulating what the Jenkins Git plugin does:
mkdir /local/test/openssl
cd /local/test/openssl
git init /local/test/openssl
git -c core.askpass=true fetch --verbose --progress
/local/git/openssl +refs/heads/*:refs/remotes/origin/*
does the usual:
remote: Counting objects: 113436, done.
remote: Compressing objects: 100% (23462/23462), done.
then hangs forever without creating any files in the working directory.
There are also no files or directories modified since the init operation.
Processes left around, and without consuming resources, are:
1493172290 2030043151 - 15:58:29   00:15 git pack-objects --revs --thin
--stdout --progress --delta-base-offset --include-tag
452984908  402653262 - 15:58:29   00:00 git -c core.askpass=true fetch
--verbose --progress /local/git/openssl +refs/heads/*:refs/remotes/origin/*
402653262 1694498903 - 15:58:28   00:00 git -c core.askpass=true fetch
--verbose --progress /local/git/openssl +refs/heads/*:refs/remotes/origin/*
2030043151  402653262 - 15:58:29   00:00 git-upload-pack
/local/git/openssl

This does not happen for our smaller repositories. Any pointers on where to
look would be appreciated.

Kindly,
Randall

-- Brief whoami: NonStop&UNIX developer since approximately
UNIX(421664400)/NonStop(2112884442)
-- In my real life, I talk too much.



--
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] Introduce a null_oid constant.

[brian m. carlson]

null_oid is the struct object_id equivalent to null_sha1.

Signed-off-by: brian m. carlson 
---
 cache.h | 1 +
 sha1_file.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/cache.h b/cache.h
index 5ab6cb50..c63fcc11 100644
--- a/cache.h
+++ b/cache.h
@@ -831,6 +831,7 @@ extern const char *find_unique_abbrev(const unsigned char 
*sha1, int len);
 extern int find_unique_abbrev_r(char *hex, const unsigned char *sha1, int len);
 
 extern const unsigned char null_sha1[GIT_SHA1_RAWSZ];
+extern const struct object_id null_oid;
 
 static inline int hashcmp(const unsigned char *sha1, const unsigned char *sha2)
 {
diff --git a/sha1_file.c b/sha1_file.c
index 27ce7b70..a54deb05 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -36,6 +36,7 @@
 static inline uintmax_t sz_fmt(size_t s) { return s; }
 
 const unsigned char null_sha1[20];
+const struct object_id null_oid;
 
 /*
  * This is meant to hold a *small* number of objects that you would
-- 
2.6.3.658.g85d7f57

--
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] format-patch: introduce option to suppress commit hashes

[brian m. carlson]

git format-patch is often used to create patches that are then stored in
version control or displayed with diff.  Having the commit hash in the
"From " line usually just creates diff noise in these cases, so this
series introduces --no-hash to set that to all zeros.

The idea for this series came from Dominic Hargreaves in Debian bug
#635663.

This series is based off of next so as not to conflict with the
conversion of struct object to struct object_id.

Careful readers will note that this option is referred to by both
"no_hash" and "zero_commit".  I felt that the latter made more sense as
an option in struct rev_info, as it's strictly more accurate, while the
former is less accurate but more friendly to humans.  Of course, this
can be changed if reviewers feel it to be undesirable.

brian m. carlson (2):
  Introduce a null_oid constant.
  format-patch: add an option to suppress commit hash

 Documentation/git-format-patch.txt | 4 
 builtin/log.c  | 5 +
 cache.h| 1 +
 log-tree.c | 3 ++-
 revision.h | 1 +
 sha1_file.c| 1 +
 t/t4014-format-patch.sh| 6 ++
 7 files changed, 20 insertions(+), 1 deletion(-)

-- 
2.6.3.658.g85d7f57

--
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] format-patch: add an option to suppress commit hash

[brian m. carlson]

Oftentimes, patches created by git format-patch will be stored in
version control or compared with diff.  In these cases, two otherwise
identical patches can have different commit hashes, leading to diff
noise.  Teach git format-patch a --no-hash option that instead produces
an all-zero hash to avoid this diff noise.

Signed-off-by: brian m. carlson 
---
 Documentation/git-format-patch.txt | 4 
 builtin/log.c  | 5 +
 log-tree.c | 3 ++-
 revision.h | 1 +
 t/t4014-format-patch.sh| 6 ++
 5 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/Documentation/git-format-patch.txt 
b/Documentation/git-format-patch.txt
index 40356491..1266f135 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -256,6 +256,10 @@ you can use `--suffix=-patch` to get 
`0001-description-of-my-change-patch`.
using this option cannot be applied properly, but they are
still useful for code review.
 
+--no-hash::
+  Output an all-zero hash in each patch's From header instead
+  of the hash of the commit.
+
 --root::
Treat the revision argument as a , even if it
is just a single commit (that would normally be treated as a
diff --git a/builtin/log.c b/builtin/log.c
index 069bd3a9..774ec1bf 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -1196,6 +1196,7 @@ int cmd_format_patch(int argc, const char **argv, const 
char *prefix)
int cover_letter = -1;
int boundary_count = 0;
int no_binary_diff = 0;
+   int no_hash = 0;
struct commit *origin = NULL;
const char *in_reply_to = NULL;
struct patch_ids ids;
@@ -1236,6 +1237,8 @@ int cmd_format_patch(int argc, const char **argv, const 
char *prefix)
PARSE_OPT_NOARG | PARSE_OPT_NONEG, keep_callback },
OPT_BOOL(0, "no-binary", &no_binary_diff,
 N_("don't output binary diffs")),
+   OPT_BOOL(0, "no-hash", &no_hash,
+N_("output all-zero hash in From header")),
OPT_BOOL(0, "ignore-if-in-upstream", &ignore_if_in_upstream,
 N_("don't include a patch matching a commit 
upstream")),
{ OPTION_SET_INT, 'p', "no-stat", &use_patch_format, NULL,
@@ -1380,6 +1383,8 @@ int cmd_format_patch(int argc, const char **argv, const 
char *prefix)
/* Always generate a patch */
rev.diffopt.output_format |= DIFF_FORMAT_PATCH;
 
+   rev.zero_commit = no_hash;
+
if (!DIFF_OPT_TST(&rev.diffopt, TEXT) && !no_binary_diff)
DIFF_OPT_SET(&rev.diffopt, BINARY);
 
diff --git a/log-tree.c b/log-tree.c
index 35e78017..f70a30e1 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -342,7 +342,8 @@ void log_write_email_headers(struct rev_info *opt, struct 
commit *commit,
 {
const char *subject = NULL;
const char *extra_headers = opt->extra_headers;
-   const char *name = oid_to_hex(&commit->object.oid);
+   const char *name = oid_to_hex(opt->zero_commit ?
+ &null_oid : &commit->object.oid);
 
*need_8bit_cte_p = 0; /* unknown */
if (opt->total > 0) {
diff --git a/revision.h b/revision.h
index 5bc96868..23857c0e 100644
--- a/revision.h
+++ b/revision.h
@@ -135,6 +135,7 @@ struct rev_info {
pretty_given:1,
abbrev_commit:1,
abbrev_commit_given:1,
+   zero_commit:1,
use_terminator:1,
missing_newline:1,
date_mode_explicit:1,
diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh
index 890db117..ce8313c7 100755
--- a/t/t4014-format-patch.sh
+++ b/t/t4014-format-patch.sh
@@ -1431,4 +1431,10 @@ test_expect_success 'cover letter auto user override' '
test_line_count = 2 list
 '
 
+test_expect_success 'format-patch --no-hash' '
+   git format-patch --no-hash --stdout v2..v1 >patch2 &&
+   cnt=$(egrep "^From 0+ Mon Sep 17 00:00:00 2001" patch2 | wc -l) &&
+   test $cnt = 3
+'
+
 test_done
-- 
2.6.3.658.g85d7f57

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

Re: git subtree bug produces divergent descendants

[David Ware]

Sorry for the double post, I received a mail blocking notification
message (due to the attached .sh file) and erroneously thought this
message had been blocked from the entire list. My later one includes
the test case as part of the attached patch.

Cheers,
Dave Ware

On Mon, Dec 7, 2015 at 9:41 AM, David Ware  wrote:
> My group has run into a bug with "git-subtree split". Under some
> circumstances a split created from a descendant of another earlier
> split is not a descendant of that earlier split (thus blocking
> pushes). We originally noticed this on v1.9.1 but have also checked it
> on v2.6.3
>
> When scanning the commits to produce the subtree it seems to skip
> creating a new commit if any of the parent commits have the same tree
> and instead uses that tree in its place. This is fine when the cause
> is a branch that did not cause any changes to the subtree.  However it
> creates an issue when the cause is both branches ending up with the
> same tree through identical alterations (or more likely, one of the
> branches has just a subset of the alterations on the other, such as a
> branch just containing cherry-picks).
>
> The attached bash script (makerepo.sh) reproduces the problem. To use
> create an empty directory and run the script in it. The resulting
> 'master' branch has had the latest commits on the 'branch' branch
> merged into it, so it follows that a subtree on 'folder/' at 'master'
> should contain all the commits of a subtree on 'folder/' at 'branch'.
> (These subtrees have been produced at 'subtree_tip' and
> 'subtree_branch' respectively.)
>
> The attached patch (against v2.6.3) fixes the issue for the cases
> we've encountered, however since we're not particularly familiar with
> git internals we may not have approached this optimally. We suspect it
> could be improved to also handle the cases where there are more than 2
> parents.
>
> Cheers,
> Dave Ware
--
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] filter-branch: pass tag name via stdin without newline

[Eric N. Vander Weele]

"git filter-branch --tag-name-filter" fails when the user-provided
command attempts to trivially append text to the originally tag name,
passed via stdin, due to an unexpected newline ('\n').  The newline is
introduced due to "echo" piping the original tag name to the
user-provided tag name filter command.

The only portable usage of "echo" is without any options and escape
sequences.  Therefore, replacing "echo" with "printf" is a suitable,
POSIX compliant alternative.

Signed-off-by: Eric N. Vander Weele 
---
 git-filter-branch.sh | 2 +-
 t/t7003-filter-branch.sh | 5 +
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index 98f1779..949cd30 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -503,7 +503,7 @@ if [ "$filter_tag_name" ]; then
new_sha1="$(cat "../map/$sha1")"
GIT_COMMIT="$sha1"
export GIT_COMMIT
-   new_ref="$(echo "$ref" | eval "$filter_tag_name")" ||
+   new_ref="$(printf "$ref" | eval "$filter_tag_name")" ||
die "tag name filter failed: $filter_tag_name"
 
echo "$ref -> $new_ref ($sha1 -> $new_sha1)"
diff --git a/t/t7003-filter-branch.sh b/t/t7003-filter-branch.sh
index 869e0bf..0db6808 100755
--- a/t/t7003-filter-branch.sh
+++ b/t/t7003-filter-branch.sh
@@ -269,6 +269,11 @@ test_expect_success 'Tag name filtering retains tag 
message' '
test_cmp expect actual
 '
 
+test_expect_success 'Tag name filter does not pass tag ref with newline' '
+   git filter-branch -f --tag-name-filter "cat && printf "_append"" -- A &&
+   git rev-parse A_append > /dev/null 2>&1
+'
+
 faux_gpg_tag='object XX
 type commit
 tag S
-- 
2.6.3

--
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] format-patch: introduce option to suppress commit hashes

[Junio C Hamano]

"brian m. carlson"  writes:

> git format-patch is often used to create patches that are then stored in
> version control or displayed with diff.  Having the commit hash in the
> "From " line usually just creates diff noise in these cases, so this
> series introduces --no-hash to set that to all zeros.

I am somewhat negative on this change that deliberately loses
information in a way that seems too specific to a single workflow.

I understand that in that particular workflow, the patch stored as
payload in a history needs only the diff part and the commit that
the patch was taken from is deemed irrelevant.

But the reason why that and only that piece of information is
expendable, while author, subject and log message text are not is
because...?  The answer to that question would very much be
project's workflow dependant.  From that point of view, I'd say the
users are much better off without the addition of this feature, but
have a custom script in their workflow to remove parts that their
project and workflow deems unnecessary.  Your project may deem the
source commit object name unnecessary.  Another one may think the
author date and name are, too.  Patch e-mail signature (i.e. what
comes after a line with "-- ") by default depends on the version of
Git that happened to have been used to prepare the patch, which may
not be something you would want.

Stepping back a bit, why is the history from which the patches are
taken from irrelevant in the first place?  Perhaps because you
replayed these patches on top of the same base but did not preserve
their timestamps?  If this user, i.e. the part of the workflow that
commits generated patches to version control, finds the "irrelevant"
change irritating, isn't it fair to expect other users, i.e. other
parts of the same workflow, also find that unnecessary and
irrelevant rebasing irritating?  It feels like I am seeing an
entrance to an X-Y problem whose real solution is to stop doing the
pointless rebases in the first place.

And if that rebase is not pointless, then I am not sure if it is a
good thing to discard the information that records which incarnation
of that constantly rebased source tree the patches were taken from.

So...
--
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] filter-branch: pass tag name via stdin without newline

[Junio C Hamano]

"Eric N. Vander Weele"  writes:

> "git filter-branch --tag-name-filter" fails when the user-provided
> command attempts to trivially append text to the originally tag name,
> passed via stdin, due to an unexpected newline ('\n').  The newline is
> introduced due to "echo" piping the original tag name to the
> user-provided tag name filter command.

Is there any other place where we feed such an incomplete line
(i.e. a line without the terminating LF) to the filters in this
command?

I am guessing that the answer to that question would be no, and all
existing scripts by users expect the newline at the end of each
line.  So I would have to say that "due to an unexpected newline" is
a misleading statement--isn't it a bug in your filter that it did
not expect one?

> The only portable usage of "echo" is without any options and escape
> sequences.  Therefore, replacing "echo" with "printf" is a suitable,
> POSIX compliant alternative.

Yes, if we wanted to emit an incomplete line, we would be using

printf "%s" "$var"

instead of

echo -n "$var"

for portability.  But that would not belong to the log message for
this patch.  If the patch were to correct a script that originally
used "echo -n" to produce an incomplete line to instead use "printf",
these three lines would have been a perfect log message.

Thanks.

> Signed-off-by: Eric N. Vander Weele 
> ---
>  git-filter-branch.sh | 2 +-
>  t/t7003-filter-branch.sh | 5 +
>  2 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/git-filter-branch.sh b/git-filter-branch.sh
> index 98f1779..949cd30 100755
> --- a/git-filter-branch.sh
> +++ b/git-filter-branch.sh
> @@ -503,7 +503,7 @@ if [ "$filter_tag_name" ]; then
>   new_sha1="$(cat "../map/$sha1")"
>   GIT_COMMIT="$sha1"
>   export GIT_COMMIT
> - new_ref="$(echo "$ref" | eval "$filter_tag_name")" ||
> + new_ref="$(printf "$ref" | eval "$filter_tag_name")" ||
>   die "tag name filter failed: $filter_tag_name"
>  
>   echo "$ref -> $new_ref ($sha1 -> $new_sha1)"
> diff --git a/t/t7003-filter-branch.sh b/t/t7003-filter-branch.sh
> index 869e0bf..0db6808 100755
> --- a/t/t7003-filter-branch.sh
> +++ b/t/t7003-filter-branch.sh
> @@ -269,6 +269,11 @@ test_expect_success 'Tag name filtering retains tag 
> message' '
>   test_cmp expect actual
>  '
>  
> +test_expect_success 'Tag name filter does not pass tag ref with newline' '
> + git filter-branch -f --tag-name-filter "cat && printf "_append"" -- A &&
> + git rev-parse A_append > /dev/null 2>&1
> +'
> +
>  faux_gpg_tag='object XX
>  type commit
>  tag S
--
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] format-patch: introduce option to suppress commit hashes

[brian m. carlson]

On Sun, Dec 06, 2015 at 06:49:14PM -0800, Junio C Hamano wrote:
> "brian m. carlson"  writes:
> 
> > git format-patch is often used to create patches that are then stored in
> > version control or displayed with diff.  Having the commit hash in the
> > "From " line usually just creates diff noise in these cases, so this
> > series introduces --no-hash to set that to all zeros.
> 
> I am somewhat negative on this change that deliberately loses
> information in a way that seems too specific to a single workflow.
> 
> I understand that in that particular workflow, the patch stored as
> payload in a history needs only the diff part and the commit that
> the patch was taken from is deemed irrelevant.

Not exactly.  At $DAYJOB, we store pristine-tar files, the contents of
the tarball, and patches against the source in Git.  We do it because
RPM likes patches and doesn't know how to speak to Git, but many Debian
source packages are stored similarly.  Every source change results in a
rebase and reformat of all the patches.

> But the reason why that and only that piece of information is
> expendable, while author, subject and log message text are not is
> because...?  The answer to that question would very much be
> project's workflow dependant.  From that point of view, I'd say the
> users are much better off without the addition of this feature, but
> have a custom script in their workflow to remove parts that their
> project and workflow deems unnecessary.  Your project may deem the
> source commit object name unnecessary.  Another one may think the
> author date and name are, too.  Patch e-mail signature (i.e. what
> comes after a line with "-- ") by default depends on the version of
> Git that happened to have been used to prepare the patch, which may
> not be something you would want.

We do want to know who wrote the patch and the reason behind the patch,
and so pretty much all the information except for the actual hash of the
commit is useful to us.  The hash is not useful because we've just
rebased the commit on a temporary branch.  We do, of course, want
--no-signature, which already exists, as you pointed out.

The hash of the source file isn't generally as much of a problem,
because the patch tends to change, even incidentally (line numbers and
such), when the hash of the file changes.  It's also something that we
have in our history, whereas the temporary branch we rebased in is not.

> Stepping back a bit, why is the history from which the patches are
> taken from irrelevant in the first place?  Perhaps because you
> replayed these patches on top of the same base but did not preserve
> their timestamps?  If this user, i.e. the part of the workflow that
> commits generated patches to version control, finds the "irrelevant"
> change irritating, isn't it fair to expect other users, i.e. other
> parts of the same workflow, also find that unnecessary and
> irrelevant rebasing irritating?  It feels like I am seeing an
> entrance to an X-Y problem whose real solution is to stop doing the
> pointless rebases in the first place.

The history is irrelevant because it happens on a temporary branch which
is not pushed anywhere.  The patches are the canonical form.  As I said,
this workflow is not specific to us; it's also used by certain Debian
maintainers to handle their source packages.

The rebase is required because we're not sure if the patches all apply
to the updated source (e.g. we had Git 2.6.2 and are rebasing them on
2.6.3).  If patch 1 needed changes, but patch 2 did not, then patch 2
shows up in the diff even though we don't want it to.

> And if that rebase is not pointless, then I am not sure if it is a
> good thing to discard the information that records which incarnation
> of that constantly rebased source tree the patches were taken from.

I was looking through the Debian BTS for Git and I saw this feature
request and thought, "Gee, I've always wanted this functionality, but I
never thought to ask for it."  This frequent, throwaway rebasing is very
common in patch-based workflows.
-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: PGP signature

Re: What's cooking in git.git (Dec 2015, #02; Fri, 4)

[Eric Sunshine]

On Sun, Dec 6, 2015 at 11:12 AM, Edmundo Carmona Antoranz
 wrote:
> And, another thing, I had sent the fifth version of my patch about
> progress for blame where I took care of all the comments hat Junio
> stated before and I got no comments since. I hoped that patch would be
> listed sometime but I didn't see it in this what's cooking or the
> previous one. Maybe it's bellow your radar? Is there something else I
> can to do about it? ($gmane/281677)

v5 of that patch is still in my review queue (which keeps getting
longer rather than shorter). I did a quick read through of it when you
sent it and saw a few things deserving of comment, but haven't found
time to do a formal review.
--
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] gitk spacing/sizing tuning for HiDPI

[Eric Sunshine]

On Sun, Dec 6, 2015 at 7:25 AM, Giuseppe Bilotta
 wrote:
> On my HiDPI monitor, most elements in gitk are correctly rendered, with two
> exceptions:
>
> * when using ttk, some elements do not use the same fonts as gitk would use
>   without, and since ttk picks _unscaled_ sizes this is very noticeable (and
> borderline illegible); the first patch fixes this;
> * the spacing between the checkboxes on top of the diff window are a little 
> too
>   tightly-spaced; the second patch adds a little bit of breathing space.

Both patches are missing your Signed-off-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: git subtree bug produces divergent descendants

[Eric Sunshine]

On Mon, Dec 07, 2015 at 11:09:48AM +1300, David Ware wrote:
> My group has run into a bug with "git-subtree split". Under some
> circumstances a split created from a descendant of another earlier
> split is not a descendant of that earlier split (thus blocking
> pushes). [...]

I'm not a git-subtree user, so this review will be superficial.

> The attached patch (against v2.6.3) includes a test that reproduces
> the problem. [...]

Please include patches inline rather than as attachments since
reviewers will want to comment on portions of the patch as part of
their response to your email. Patches as attachments make this
process more painful.

> From: Dave Ware 
> Date: Fri, 4 Dec 2015 16:30:03 +1300
> Subject: [PATCH] Fix bug in git-subtree split.

For the subject, mention the area you're working on, followed by a
colon, followed by a concise description of the problem. If possible,
try to say something more specific than "fix bug". You might, for
instance, say something like:

contrib/subtree: fix "subtree split" skipped-merge bug

> A bug occurs in 'git-subtree split' where a merge is skipped even when
> both parents act on the subtree, provided the merge results in a tree
> identical to one of the parents. Fixed by copying the merge if at least

Imperative mood: s/Fixed/Fix/

> one parent is non-identical, and the non-identical parent is not an
> ancestor of the identical parent.
> 
> Also adding a test case, this checks that a descendant can be pushed to
> it's ancestor in this case.

Your Signed-off-by: is missing. See Documentation/SubmittingPatches.

> ---
> diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
> index 9f06571..b837531 100755
> --- a/contrib/subtree/git-subtree.sh
> +++ b/contrib/subtree/git-subtree.sh
> @@ -479,8 +479,16 @@ copy_or_skip()
>   p="$p -p $parent"
>   fi
>   done
> - 
> - if [ -n "$identical" ]; then
> +
> + copycommit=
> + if [ -n "$identical" ] && [ -n "$nonidentical" ]; then
> + extras=$(git rev-list --boundary $identical..$nonidentical)
> + if [ -n "$extras" ]; then
> + # we need to preserve history along the other branch
> + copycommit=1
> + fi
> + fi
> + if [ -n "$identical" ] && [ -z "$copycommit" ]; then

Typically, I'd say something about how this project uses 'test'
rather than '[' and that 'then' is placed on its own line (with no
semicolon), however, in this case, you're sticking to existing style
(in this script), so I won't mention it.

>   echo $identical
>   else
>   copy_commit $rev $tree "$p" || exit $?
> diff --git a/contrib/subtree/t/t7901-subtree-split.sh 
> b/contrib/subtree/t/t7901-subtree-split.sh
> new file mode 100755
> index 000..0a1ea56
> --- /dev/null
> +++ b/contrib/subtree/t/t7901-subtree-split.sh

Is there a strong reason why this demands a new test script rather
than being incorporated into the existing t7900-subtree.sh?

> @@ -0,0 +1,62 @@
> +#!/bin/bash
> +
> +test_description='Test for bug in subtree commit filtering'

A somewhat strange description. Typically, scripts want to verify
correct behavior, rather than buggy behavior.

> +TEST_DIRECTORY=$(pwd)/../../../t
> +export TEST_DIRECTORY
> +
> +. ../../../t/test-lib.sh
> +
> +
> +test_expect_success 'subtree descendent check' '
> +  mkdir git_subtree_split_check &&
> +  cd git_subtree_split_check &&

Tests don't automatically return to the directory prior to the 'cd',
so when this test ends, the current directory will still be
'git_subtree_split_check'. If someone later adds a test following
this one, that test will execute within 'git_subtree_split_check',
which might not be expected by the test writer.

To ensure that the prior working directory is restored at the end of
the test (regardless of success or failure), tests typically employ a
subshell using this idiom:

mkdir foo &&
(
cd foo &&
... &&
...
)

In this case, though, I'm wondering what is the purpose of having the
'git_subtree_split_check' subdirectory at all? Is there a reason you
can't just perform the test in the existing directory created
automatically specifically for the test script (which is already the
script's current working directory)? If, on the other hand, you
incorporate this test into t7900-subtree.sh, then the separate
'git_subtree_split_check' directory may make sense if it needs to be
isolated from the other gunk in that script's test directory.

> +  git init &&
> +
> +  mkdir folder &&
> +
> +  echo a > folder/a &&

Typical style is to drop the space after the redirection operator,
however, since you're following existing style in t7900-subtree.sh, I
won't mention it.

> +  git add . &&
> +  git commit -m "first commit" &&
> +
> +  git branch branch &&
> +
> +  echo 0 > folder/0 &&
> +  git add . &&
> +  git commit -m "adding 0 to folder" &&
> +
> +  echo b > folder/b &&
>

Re: [PATCH] filter-branch: pass tag name via stdin without newline

[Eric Vander Weele]

On Sun, Dec 6, 2015 at 6:55 PM, Junio C Hamano  wrote:
> "Eric N. Vander Weele"  writes:
>
>> "git filter-branch --tag-name-filter" fails when the user-provided
>> command attempts to trivially append text to the originally tag name,
>> passed via stdin, due to an unexpected newline ('\n').  The newline is
>> introduced due to "echo" piping the original tag name to the
>> user-provided tag name filter command.
>
> Is there any other place where we feed such an incomplete line
> (i.e. a line without the terminating LF) to the filters in this
> command?
>
> I am guessing that the answer to that question would be no, and all
> existing scripts by users expect the newline at the end of each
> line.  So I would have to say that "due to an unexpected newline" is
> a misleading statement--isn't it a bug in your filter that it did
> not expect one?
>
I agree that there isn't any other place in "git filter-branch" where
an incomplete line is fed to the filters.

My surprise was due to asymmetry between of the filter receiving a tag
name with a newline and that the behavior of trailing newlines being
stripped from what is fed to stdout (due to behavior of command
substitution).  Given that an embedded newline within a ref name is
invalid, I thought it may be desirable suppress newline.  Actually,
now that I think about, POSIX standard defines a line as "a sequence
of zero or more non-  characters plus a terminating 
character."

My apologies for the misleading statement and will correct my filter
accordingly to handle the terminating newline for appending text.
>
>> The only portable usage of "echo" is without any options and escape
>> sequences.  Therefore, replacing "echo" with "printf" is a suitable,
>> POSIX compliant alternative.
>
> Yes, if we wanted to emit an incomplete line, we would be using
>
> printf "%s" "$var"
>
> instead of
>
> echo -n "$var"
>
> for portability.  But that would not belong to the log message for
> this patch.  If the patch were to correct a script that originally
> used "echo -n" to produce an incomplete line to instead use "printf",
> these three lines would have been a perfect log message.
>
I appreciate the feedback - thanks.  The intention of those three
lines were to give context for using "printf" instead of adding
options to "echo" to suppress the newline; however, that was under the
assumption that suppressing the newline was desired behavior.
>
> Thanks.
>
>> Signed-off-by: Eric N. Vander Weele 
>> ---
>>  git-filter-branch.sh | 2 +-
>>  t/t7003-filter-branch.sh | 5 +
>>  2 files changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/git-filter-branch.sh b/git-filter-branch.sh
>> index 98f1779..949cd30 100755
>> --- a/git-filter-branch.sh
>> +++ b/git-filter-branch.sh
>> @@ -503,7 +503,7 @@ if [ "$filter_tag_name" ]; then
>>   new_sha1="$(cat "../map/$sha1")"
>>   GIT_COMMIT="$sha1"
>>   export GIT_COMMIT
>> - new_ref="$(echo "$ref" | eval "$filter_tag_name")" ||
>> + new_ref="$(printf "$ref" | eval "$filter_tag_name")" ||
>>   die "tag name filter failed: $filter_tag_name"
>>
>>   echo "$ref -> $new_ref ($sha1 -> $new_sha1)"
>> diff --git a/t/t7003-filter-branch.sh b/t/t7003-filter-branch.sh
>> index 869e0bf..0db6808 100755
>> --- a/t/t7003-filter-branch.sh
>> +++ b/t/t7003-filter-branch.sh
>> @@ -269,6 +269,11 @@ test_expect_success 'Tag name filtering retains tag 
>> message' '
>>   test_cmp expect actual
>>  '
>>
>> +test_expect_success 'Tag name filter does not pass tag ref with newline' '
>> + git filter-branch -f --tag-name-filter "cat && printf "_append"" -- A 
>> &&
>> + git rev-parse A_append > /dev/null 2>&1
>> +'
>> +
>>  faux_gpg_tag='object XX
>>  type commit
>>  tag S
--
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 v6] ls-files: Add eol diagnostics

[Eric Sunshine]

On Sun, Dec 6, 2015 at 3:38 PM, Torsten Bögershausen  wrote:
> When working in a cross-platform environment, a user wants to
> check if text files are stored normalized in the repository and if
> .gitattributes are set appropriately.
> [...]
> Signed-off-by: Torsten Bögershausen 
> ---
> diff --git a/convert.c b/convert.c
> @@ -95,6 +100,63 @@ static int is_binary(unsigned long size, struct text_stat 
> *stats)
> +const char *get_wt_convert_stats_ascii(const char *path)
> +{
> +   const char *ret;
> +   struct strbuf sb = STRBUF_INIT;
> +   if (strbuf_read_file(&sb, path, 0) < 0)
> +   return "";

Given the implementation of strbuf_read_file(), some memory may have
been allocated to the strbuf even if it returns a failure, therefore
this may be leaking.

> +   ret = gather_convert_stats_ascii(sb.buf, sb.len);
> +   strbuf_release(&sb);
> +   return ret;
> +}

You may, therefore, want to restructure the code like this to avoid the leak:

const char *ret = "";
struct strbuf sb = STRBUF_INIT;
if (strbuf_read_file(...) >= 0)
ret = gather_convert_stats_ascii(...);
strbuf_release(&sb);
return ret;

> diff --git a/t/t0027-auto-crlf.sh b/t/t0027-auto-crlf.sh
> @@ -213,7 +238,20 @@ checkout_files () {
> git -c core.eol=$eol checkout $src$f.txt
> fi
> done
> -

Was dropping this blank line intentional?

> +   test_expect_success "ls-files --eol $lfname ${pfx}LF.txt" "
> +   cat >e <<-EOF &&
> +   i/text-crlf w/$(stats_ascii $crlfname) ${src}CRLF.txt
> +   i/text-crlf-lf w/$(stats_ascii $lfmixcrlf) 
> ${src}CRLF_mix_LF.txt
> +   i/text-lf w/$(stats_ascii $lfname) ${src}LF.txt
> +   i/binary w/$(stats_ascii $lfmixcr) ${src}LF_mix_CR.txt
> +   i/binary w/$(stats_ascii $crlfnul) ${src}CRLF_nul.txt
> +   i/binary w/$(stats_ascii $crlfnul) ${src}LF_nul.txt
> +   EOF
> +   sort expect &&
> +   git ls-files --eol $src* | sed -e 's!attr/[=a-z-]*!!g' -e 's/ 
>  */ /g' | sort >actual &&
> +   test_cmp expect actual &&
> +   rm e expect actual

If it is indeed important to cleanup these files so that they don't
muck up following tests, then you'd be better off using:

test_when_finished "rm -f e expect actual"

at the top of the test to ensure that the cleanup happens regardless
of the whether the test succeeds or fails. On the other hand, if these
files won't muck up subsequent tests, then it may be fine to skip
cleanup altogether.

> +   "
> test_expect_success "checkout core.eol=$eol core.autocrlf=$crlf 
> gitattributes=$attr file=LF" "
> compare_ws_file $pfx $lfname${src}LF.txt
> "
> @@ -231,6 +269,37 @@ checkout_files () {
> +# Test control characters
> +# NUL SOH CR EOF==^Z
> +test_expect_success 'ls-files --eol -o Text/Binary' '
> +   test_when_finished "rm e expect actual TeBi_*" &&

It's probably not a big deal, but "rm -f" perhaps?

> +   STRT=AAA &&
> +   STR=$STRT$STRT$STRT$STRT &&
> +   printf "${STR}BBB\001" >TeBi_127_S &&
> +   printf "${STR}\001">TeBi_128_S &&
> +   printf "${STR}BBB\032" >TeBi_127_E &&
> +   printf "\032${STR}BBB" >TeBi_E_127 &&
> +   printf "${STR}\000">TeBi_128_N &&
> +   printf "${STR}BBB\012">TeBi_128_L &&
> +   printf "${STR}BBB\015">TeBi_127_C &&
> +   printf "${STR}BB\015\012" >TeBi_126_CL &&
> +   printf "${STR}BB\015\012\015" >TeBi_126_CLC &&
> +   cat >e <<-\EOF &&
> +   i/ w/binary TeBi_127_S
> +   i/ w/text-no-eol TeBi_128_S
> +   i/ w/text-no-eol TeBi_127_E
> +   i/ w/binary TeBi_E_127
> +   i/ w/binary TeBi_128_N
> +   i/ w/text-lf TeBi_128_L
> +   i/ w/binary TeBi_127_C
> +   i/ w/text-crlf TeBi_126_CL
> +   i/ w/binary TeBi_126_CLC
> +   EOF
> +   sort expect &&
> +   git ls-files --eol -o | egrep "TeBi_" | sed -e 's!attr/[=a-z-]*!!g' 
> -e "s/  */ /g" | sort >actual &&

Okay. "egrep" is used about as frequently in test scripts as "grep -E".

> +   test_cmp expect actual
> +'
> @@ -480,4 +549,20 @@ checkout_filesnative  true  "lf"  LFCRLF  
> CRLF_mix_LF  LF_mix_CR
> +# Should be the last test case
> +test_expect_success 'ls-files --eol -d' "
> +   rm  crlf_false_attr__CRLF.txt crlf_false_attr__CRLF_mix_LF.txt 
> crlf_false_attr__LF.txt .gitattributes &&

Did you mean to wrap this in test_when_finished()?

If not, is it cleaning up gunk left by some earlier test(s)? If so,
what happens if one of those tests failed and didn't create one of
these files? In that case, this 'rm' would fail, causing this entire
test to fail. Better would be to use "rm -f".

> +   cat >expect <<-\EOF &&
> +   i/text-crlf w/ crlf_false_attr__CRLF.txt
> +   i/text-crlf-lf w/ crlf_false_attr__CRLF_mix_LF.txt
> +   i/text-lf w/ .gitattrib

Re: [RFC/PATCH 7/8] update-index: prevent --untracked-cache from performing tests

[Christian Couder]

On Wed, Dec 2, 2015 at 8:18 PM, Duy Nguyen  wrote:
> On Tue, Dec 1, 2015 at 9:31 PM, Christian Couder
>  wrote:
>  diff --git a/t/t7063-status-untracked-cache.sh
> b/t/t7063-status-untracked-cache.sh
>> index 0e8d0d4..8c3e703 100755
>> --- a/t/t7063-status-untracked-cache.sh
>> +++ b/t/t7063-status-untracked-cache.sh
>> @@ -11,7 +11,7 @@ avoid_racy() {
>>  # It's fine if git update-index returns an error code other than one,
>>  # it'll be caught in the first test.
>
> Notice this comment. You probably have to chance --test-untr.. for the
> first test too if it's stilll true, or delete the comment.

Ok, I think I will remove the comment and still use "git update-index
--untracked-cache" in the first test.

>>  test_lazy_prereq UNTRACKED_CACHE '
>> -   { git update-index --untracked-cache; ret=$?; } &&
>> +   { git update-index --test-untracked-cache; ret=$?; } &&
>> test $ret -ne 1
>>  '

Thanks,
Christian.
--
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/PATCH] config: add core.trustmtime

[Christian Couder]

On Wed, Dec 2, 2015 at 8:28 PM, Duy Nguyen  wrote:
> On Wed, Nov 25, 2015 at 10:00 AM, Ævar Arnfjörð Bjarmason
>  wrote:
>> Aside from the slight hassle of enabling this and keeping it enabled
>> this feature is great. It's sped up "git status" across the board by
>> about 40%. Slightly less than that on faster spinning disks, slightly
>> more than that on slower ones.
>
> Before I forget again, you should also enable split-index. That
> feature was added because index update time cut so much into the
> saving from untracked cache (unless you have small indexes, unlikely).
> And untracked cache can update the index often. Then maybe you can
> also think about improving the usability for it to ;-)

Yeah, we will probably have a look at split-index next.

Thanks for developing it too,
Christian.
--
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

Can't get 'git archive' to work

[Yuri]

Getting the errors, see below.

Why "operation is not supported" through http and https? 'archive' is 
supposed to be the most efficient operation to get the specific snapshot 
of the repository, and it should be available without authentication.


In case of ssh with the key there is the strange error message about 
"core.gitProxy". What is this about? I am not using a proxy.


I couldn't get git archive to work even once.

# through ssh with an active ssh key
$ git archive --format=tar --remote=g...@github.com:yurivict/vm-to-tor.git
Invalid command: 'git-upload-archive 'yurivict/vm-to-tor.git''
  You appear to be using ssh to clone a git:// URL.
  Make sure your core.gitProxy config option and the
  GIT_PROXY_COMMAND environment variable are NOT set.
fatal: The remote end hung up unexpectedly

# through ssh without an ssh key
$  git archive --format=tar --remote=g...@github.com:yurivict/vm-to-tor.git
Permission denied (publickey).
fatal: The remote end hung up unexpectedly

# through https
$  git archive --format=tar 
--remote=https://github.com/yurivict/vm-to-tor.git

fatal: Operation not supported by protocol.

# through http
$  git archive --format=tar 
--remote=http://github.com/yurivict/vm-to-tor.git

fatal: Operation not supported by protocol.


git-2.6.2 on FreeBSD 10.2

Yuri

--
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: Show total commit count of two authors or more authors into first author

[Jagan Teki]

On 7 December 2015 at 02:50, brian m. carlson
 wrote:
> On Mon, Dec 07, 2015 at 01:45:19AM +0530, Jagan Teki wrote:
>> Thanks for the info, I'm able to map two author with e-mail but it's
>> not working when I group 3
>>
>> $ .mailmap
>> Jagan Teki  Jagannadha Teki 
>>
>> The above worked but how about 3 names mapping
>>
>> $ .mailmap
>> Jagan Teki  Jagannadha Teki  Jagannadha
>> Sutradharudu Teki
>>
>> Finally I need to map all 3 into Jagan Teki 
>
> You probably want to map two at a time.  So something like this:
>
>   Jagan Teki  Jagannadha Teki 
>   Jagan Teki  Jagannadha Sutradharudu Teki 

I tried this before seems like some more hidden name's with same
author. anyway I found all and mapped the same. Thanks you very much.

-- 
Jagan.
--
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/PATCH 2/8] update-index: add --test-untracked-cache

[Christian Couder]

On Wed, Dec 2, 2015 at 8:17 PM, Duy Nguyen  wrote:
> On Tue, Dec 1, 2015 at 9:31 PM, Christian Couder
>  wrote:
>> diff --git a/builtin/update-index.c b/builtin/update-index.c
>> index e568acc..b7b5108 100644
>> --- a/builtin/update-index.c
>> +++ b/builtin/update-index.c
>> @@ -996,8 +996,10 @@ int cmd_update_index(int argc, const char **argv, const 
>> char *prefix)
>> N_("enable or disable split index")),
>> OPT_BOOL(0, "untracked-cache", &untracked_cache,
>> N_("enable/disable untracked cache")),
>> +   OPT_SET_INT(0, "test-untracked-cache", &untracked_cache,
>> +   N_("test if the filesystem supports untracked 
>> cache"), 2),
>> OPT_SET_INT(0, "force-untracked-cache", &untracked_cache,
>> -   N_("enable untracked cache without testing the 
>> filesystem"), 2),
>> +   N_("enable untracked cache without testing the 
>> filesystem"), 3),
>> OPT_END()
>> };
>
> I think we got enough numbers to start using enum instead.

Ok, I will use an enum.
--
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: [PATCHv3] gitweb: fill in missing parts of JavaScript minify support

[mikelilin]

i find a free online tool to  minify javascript
  .




--
View this message in context: 
http://git.661346.n2.nabble.com/PATCHv3-gitweb-fill-in-missing-parts-of-JavaScript-minify-support-tp4767036p7643775.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