git fsck: unreachable vs. dangling

[Sebastian Schuberth]

Hi,

reading through the fsck docs [1] I'm having a hard time understanding
what the difference between "unreachable" and "dangling" objects are.

By example, suppose I have a commit A that is the tip of exactly one
branch (and no tag or other ref points to A). If I delete that branch,
is A now dangling, or unreachable, or both?

[1] http://git-scm.com/docs/git-fsck.html

-- 
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: git fsck: unreachable vs. dangling

[Junio C Hamano]

On Tue, Apr 14, 2015 at 12:16 AM, Sebastian Schuberth
 wrote:
> Hi,
>
> reading through the fsck docs [1] I'm having a hard time understanding
> what the difference between "unreachable" and "dangling" objects are.
>
> By example, suppose I have a commit A that is the tip of exactly one
> branch (and no tag or other ref points to A). If I delete that branch,
> is A now dangling, or unreachable, or both?

Suppose that branch consists of two commits, A and A^.
When you lose that branch (git branch -D that-branch),
both A and A^ become unreachable. So are trees and
blobs that appear only in A and A^ and nowhere else;
they are also unreachable.

A dangling object is an unreachable object that cannot be
made reachable by any way other than pointing at it
directly with a ref. A^ is not dangling, because you can
make it reachable by pointing A (the tip of the original
branch you just lost) with a ref. A on the other hand is
dangling (if you had a tag object that points at A that
you lost, then A is merely unreachable but not dangling,
because you can point at that tag with a ref and make A
reachable).
--
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] reduce progress updates in background

[Johannes Schindelin]

Hi Brian,

On 2015-04-14 05:12, brian m. carlson wrote:
> On Mon, Apr 13, 2015 at 11:48:50PM +1000, Luke Mewburn wrote:
>
> I appreciated the opportunity to learn about tcgetpgrp(3).  The Windows
> folks will probably need to stub that function out, but they're no worse
> off than they were before.

Thanks for thinking of us!

Ciao,
Dscho
--
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 fsck: unreachable vs. dangling

[Michael J Gruber]

Junio C Hamano venit, vidit, dixit 14.04.2015 10:05:
> On Tue, Apr 14, 2015 at 12:16 AM, Sebastian Schuberth
>  wrote:
>> Hi,
>>
>> reading through the fsck docs [1] I'm having a hard time understanding
>> what the difference between "unreachable" and "dangling" objects are.
>>
>> By example, suppose I have a commit A that is the tip of exactly one
>> branch (and no tag or other ref points to A). If I delete that branch,
>> is A now dangling, or unreachable, or both?
> 
> Suppose that branch consists of two commits, A and A^.
> When you lose that branch (git branch -D that-branch),
> both A and A^ become unreachable. So are trees and
> blobs that appear only in A and A^ and nowhere else;
> they are also unreachable.
> 
> A dangling object is an unreachable object that cannot be
> made reachable by any way other than pointing at it
> directly with a ref. A^ is not dangling, because you can
> make it reachable by pointing A (the tip of the original
> branch you just lost) with a ref. A on the other hand is
> dangling (if you had a tag object that points at A that
> you lost, then A is merely unreachable but not dangling,
> because you can point at that tag with a ref and make A
> reachable).
> 

This terminology is established, but misleading if you try to
understanding things from the word and the technical tree structure:

"to dangle" means "to hang loosely".

So, in the description above, "A^ dangles from A loosely" because it
hangs from A (you can reach it from A) but loosely, because it would
"drop" if A gets dropped and A is "likely" to be dropped (because it is
unreachable by refs). But A^ is not dangling in our terminology.

If you *reverse the arrows*, i.e. consider A^ pointing to A, it becomes
more apparent that A is dangling: it is an unreferenced leaf node.

But really, we're switching directions of the arrows again and again
when, on the one hand, we talk about refs pointing to commits, commits
pointing to parent commits (which they are, of course) but then, on the
other hand, use terms like "root" and "dangling" which make sense only
when you think of the oppositely oriented tree.

Maybe we should introduce the terms DAG and reverse DAG (GAD?) to make
this clearer. Our DAG is technically oriented from commits to their
parents all the way "up" to the root.

Visually, we often orient it from the root towards child commits.

When we do a revision walk, do we walk forward or backwards?

I'd say users think in the ordering in which they create commits (from
root to children), let's call that DAG. It explains "root" and "dangle"
and such, and a revision walk is a walk backwards in that orientation.

Technically, our acyclic graph is oriented the other way, a revision
walk walks forward in that orientation - it couldn't walk any other way
without extensive searching. This orientation (GAD?) explains "points
to", be it "ref to rev" or "commit to parent".

Michael

P.S.: The more mathematically inclined will notice that we can have more
than 2 orientations if our graph is not connected... But I'd say we have
one "technical" orientation (commit->parent) and the opposite and can
forget about others.
--
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 fsck: unreachable vs. dangling

[Sebastian Schuberth]

On Tue, Apr 14, 2015 at 10:05 AM, Junio C Hamano  wrote:

> A dangling object is an unreachable object that cannot be
> made reachable by any way other than pointing at it
> directly with a ref.

Thanks a lot for the prompt explanation!

-- 
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: git fsck: unreachable vs. dangling

[Sebastian Schuberth]

On Tue, Apr 14, 2015 at 10:50 AM, Michael J Gruber
 wrote:

> "to dangle" means "to hang loosely".
>
> So, in the description above, "A^ dangles from A loosely" because it
> hangs from A (you can reach it from A) but loosely, because it would
> "drop" if A gets dropped and A is "likely" to be dropped (because it is
> unreachable by refs). But A^ is not dangling in our terminology.
>
> If you *reverse the arrows*, i.e. consider A^ pointing to A, it becomes
> more apparent that A is dangling: it is an unreferenced leaf node.

That's exactly what confused me. In the very literal sense, something
can only "hang loosely", i.e. dangle, if it's only tied at *one* end,
and that's the case for A (which is only connected to A^) but not for
A^ (which is connected to its parent, and A). Especially when talking
about A as a "leaf" node, like in the leaf of a natural tree, I would
think that A is dangling.

-- 
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: git fsck: unreachable vs. dangling

[Junio C Hamano]

Sebastian Schuberth  writes:

> On Tue, Apr 14, 2015 at 10:50 AM, Michael J Gruber
>  wrote:
>
>> "to dangle" means "to hang loosely".
>>
>> So, in the description above, "A^ dangles from A loosely" because it
>> hangs from A (you can reach it from A) but loosely, because it would
>> "drop" if A gets dropped and A is "likely" to be dropped (because it is
>> unreachable by refs). But A^ is not dangling in our terminology.
>>
>> If you *reverse the arrows*, i.e. consider A^ pointing to A, it becomes
>> more apparent that A is dangling: it is an unreferenced leaf node.
>
> That's exactly what confused me. In the very literal sense, something
> can only "hang loosely", i.e. dangle, if it's only tied at *one* end,
> and that's the case for A (which is only connected to A^) but not for
> A^ (which is connected to its parent, and A). Especially when talking
> about A as a "leaf" node, like in the leaf of a natural tree, I would
> think that A is dangling.

I am not sure if I follow, but probably it is just me who is not
strong at math, or whose eyesight is not keen enough to notice the
arrow heads on links between the commits.

I just visualize commits to be ping-pong balls with strings between
them, and then grab the root of the graph and lift the whole thing
up, while tips of the branches and tags are anchored.  Commit A will
be dangling in the wind if you shake the whole thing.

But that visualization breaks down once you start thinking about
what will happen to A^{tree} and its blobs; they are attached to A
with thin strings and they will have to float above A (i.e. sit
somewhere closer to the root of the tree) just like A^ will go
closer to the root, to make A appear the "dangling" one, as the
direction of the arrow is from A to A^{tree} just like we have an
arrow from A to A^; just like A^ is not dangling because of A,
A^{tree} is not dangling.
--
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 fsck: unreachable vs. dangling

[Sebastian Schuberth]

On Tue, Apr 14, 2015 at 11:22 AM, Junio C Hamano  wrote:

> I just visualize commits to be ping-pong balls with strings between
> them, and then grab the root of the graph and lift the whole thing
> up, while tips of the branches and tags are anchored.  Commit A will
> be dangling in the wind if you shake the whole thing.

I used to have exactly the same visualization in mind, but got
confused in between, unsure whether my understanding was correct. As
it turns out it is, and when sticking to that visualization everything
seems to be consistent in the fsck docs. They could still benefit some
more clarification I guess. I'll see if I can come up with something.

Thanks again.

-- 
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: Git add -p “Your edited hunk does not apply. Edit again”

[Matthieu Moy]

Tanky Woo  writes:

> -   coverage erase
> +
> +covhtml:
> +   make clean
> +   nosetests
> +   coverage html
> +   cd ${HTMLCOV} && python -m SimpleHTTPServer
> So I use e to manually edit the hunk, I delete all the + lines, it seems:

I can reproduce on git.git's master. Actually, you don't even have to
edit the patch, just save and exit, and you get the same error message.
So it's clearly a bug.

I can get the same kind of bug with "stash -p", without even using the
'e' command, by doing "split" and then answer n, y. On a simpler example
with two hunks:

$ git stash -p
diff --git a/bar.txt b/bar.txt
index 35fbd83..1d3fda3 100644
--- a/bar.txt
+++ b/bar.txt
@@ -1,4 +1,6 @@
 aaa
+added line 1
 bbb
+added line 2
 ccc
 ddd
Stash this hunk [y,n,q,a,d,/,s,e,?]? s
Split into 2 hunks.
@@ -1,2 +1,3 @@
 aaa
+added line 1
 bbb
Stash this hunk [y,n,q,a,d,/,j,J,g,e,?]? n
@@ -2,3 +3,4 @@
 bbb
+added line 2
 ccc
 ddd
Stash this hunk [y,n,q,a,d,/,K,g,e,?]? y

Saved working directory and index state WIP on master: 1cad001 abcd
error: patch failed: bar.txt:1
error: bar.txt: patch does not apply
Cannot remove worktree changes

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

[PATCH v2] reduce progress updates in background

[Luke Mewburn]

Updated patch where is_foreground_fd() is only called in display()
just before the output is to be displayed.
From d87997509fc631b8cdc7db63f289102d6ddfe933 Mon Sep 17 00:00:00 2001
From: Luke Mewburn 
Date: Mon, 13 Apr 2015 23:30:51 +1000
Subject: [PATCH] progress: no progress in background

Disable the display of the progress if stderr is not the
current foreground process.
Still display the final result when done.

Signed-off-by: Luke Mewburn 
---
 progress.c | 22 --
 1 file changed, 16 insertions(+), 6 deletions(-)

diff --git a/progress.c b/progress.c
index 412e6b1..43d9228 100644
--- a/progress.c
+++ b/progress.c
@@ -72,6 +72,11 @@ static void clear_progress_signal(void)
progress_update = 0;
 }
 
+static int is_foreground_fd(int fd)
+{
+   return getpgid(0) == tcgetpgrp(fd);
+}
+
 static int display(struct progress *progress, unsigned n, const char *done)
 {
const char *eol, *tp;
@@ -98,16 +103,21 @@ static int display(struct progress *progress, unsigned n, 
const char *done)
unsigned percent = n * 100 / progress->total;
if (percent != progress->last_percent || progress_update) {
progress->last_percent = percent;
-   fprintf(stderr, "%s: %3u%% (%u/%u)%s%s",
-   progress->title, percent, n,
-   progress->total, tp, eol);
-   fflush(stderr);
+   if (is_foreground_fd(fileno(stderr)) || done) {
+   fprintf(stderr, "%s: %3u%% (%u/%u)%s%s",
+   progress->title, percent, n,
+   progress->total, tp, eol);
+   fflush(stderr);
+   }
progress_update = 0;
return 1;
}
} else if (progress_update) {
-   fprintf(stderr, "%s: %u%s%s", progress->title, n, tp, eol);
-   fflush(stderr);
+   if (is_foreground_fd(fileno(stderr)) || done) {
+   fprintf(stderr, "%s: %u%s%s",
+   progress->title, n, tp, eol);
+   fflush(stderr);
+   }
progress_update = 0;
return 1;
}
-- 
2.3.5.1.gd879975



pgpxkGmuIlerx.pgp
Description: PGP signature

Re: [PATCH] reduce progress updates in background

[Luke Mewburn]

On Mon, Apr 13, 2015 at 11:01:04AM -0400, Nicolas Pitre wrote:
  | > That's what happens; the suppression only occurs if the process is
  | > currently background.  If I start a long-running operation (such as "git
  | > fsck"), the progress is displayed. I then suspend & background, and the
  | > progress is suppressed.  If I resume the process in the foreground, the
  | > progress starts to display again at the appropriate point.
  | 
  | I agree. I was just comenting on your suggestion about caching the 
  | in_progress_fd() result which would prevent that.

Ahh.  My suggestion about is_foreground_fd() result caching within
struct progress was only about caching the getpgid(0) portion of the
test (as that's not expected to change for the life of the process), and
not the tcgetpgrp(fd) portion.  I.e, add 'int curpgid' to struct
progress, set that to getpgid(0) in start_progress_display(), and
compare tcgetpgrp(fd) against progress->curpgid.

In any case, I think it's a micro optimisation not worth worrying about
at this point, given is_foreground_fd() is only called each time the
output would change, per your feedback.

regards,
Luke.


pgpGbPBkemS0K.pgp
Description: PGP signature

Re: [PATCH] git-p4: Use -m when running p4 changes

[Luke Diamand]

On 11 April 2015 at 16:17, Lex Spoon  wrote:
>
>
> Signed-off-by: Lex Spoon 
> ---
> This patch addresses a problem I am running into with a client. I am
> attempting to mirror their Perforce repository into Git, and on certain
> branches their Perforce server is responding with an error about "too many
> rows scanned". This change has git-p4 use the "-m" option to return just 500
> changes at a time, thus avoiding the problem.

Thanks - that's a problem I also occasionally hit, and it definitely
needs fixing.

Your fix is quite nice - I started out thinking this should be easy,
but it's not!

A test case addition would be good if you can though - otherwise it's
certain to break at some point in the future. Would you have time to
add that?

Thanks!
Luke


>
> I have tested this on a small test repository (2000 revisions) and it
> appears to work fine. I have also run all the t98* tests; those print a
> number of yellow "not ok" results but no red ones. I presume this is the
> expected test behavior?

Yes.

>
> I considered making the block size configurable, but it seems unlikely
> anyone will strongly benefit from changing it. 500 is large enough that it
> should only take a modest number of iterations to scan the full changes
> list, but it's small enough that any reasonable Perforce server should allow
> the request.

Might be useful when making test harnesses though :-)


>
> This patch is also available on GitHub:
> https://github.com/lexspoon/git/tree/p4-sync-batches
>
>  git-p4.py | 40 +---
>  1 file changed, 33 insertions(+), 7 deletions(-)
>
> diff --git a/git-p4.py b/git-p4.py
> index 549022e..ce1447b 100755
> --- a/git-p4.py
> +++ b/git-p4.py
> @@ -742,15 +742,41 @@ def originP4BranchesExist():
>
>  def p4ChangesForPaths(depotPaths, changeRange):
>  assert depotPaths
> -cmd = ['changes']
> -for p in depotPaths:
> -cmd += ["%s...%s" % (p, changeRange)]
> -output = p4_read_pipe_lines(cmd)
>
> +# Parse the change range into start and end
> +if changeRange is None or changeRange == '':
> +changeStart = '@1'
> +changeEnd = '#head'
> +else:
> +parts = changeRange.split(',')
> +assert len(parts) == 2
> +changeStart = parts[0]
> +changeEnd = parts[1]
> +
> +# Accumulate change numbers in a dictionary to avoid duplicates
>  changes = {}
> -for line in output:
> -changeNum = int(line.split(" ")[1])
> -changes[changeNum] = True
> +
> +for p in depotPaths:
> +# Retrieve changes a block at a time, to prevent running
> +# into a MaxScanRows error from the server.
> +block_size = 500
> +start = changeStart
> +end = changeEnd
> +get_another_block = True
> +while get_another_block:
> +new_changes = []
> +cmd = ['changes']
> +cmd += ['-m', str(block_size)]
> +cmd += ["%s...%s,%s" % (p, start, end)]
> +for line in p4_read_pipe_lines(cmd):
> +changeNum = int(line.split(" ")[1])
> +new_changes.append(changeNum)
> +changes[changeNum] = True
> +if len(new_changes) == block_size:
> +get_another_block = True
> +end = '@' + str(min(new_changes))
> +else:
> +get_another_block = False
>
>  changelist = changes.keys()
>  changelist.sort()
> --
> 1.9.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 3/4] t3904-stash-patch: factor PERL prereq at the top of the file

[Matthieu Moy]

Signed-off-by: Matthieu Moy 
---
 t/t3904-stash-patch.sh | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/t/t3904-stash-patch.sh b/t/t3904-stash-patch.sh
index 9a59683..0f8f47f 100755
--- a/t/t3904-stash-patch.sh
+++ b/t/t3904-stash-patch.sh
@@ -3,7 +3,13 @@
 test_description='stash -p'
 . ./lib-patch-mode.sh
 
-test_expect_success PERL 'setup' '
+if ! test_have_prereq PERL
+then
+   skip_all='skipping stash -p tests, perl not available'
+   test_done
+fi
+
+test_expect_success 'setup' '
mkdir dir &&
echo parent > dir/foo &&
echo dummy > bar &&
@@ -20,7 +26,7 @@ test_expect_success PERL 'setup' '
 
 # note: order of files with unstaged changes: HEAD bar dir/foo
 
-test_expect_success PERL 'saying "n" does nothing' '
+test_expect_success 'saying "n" does nothing' '
set_state HEAD HEADfile_work HEADfile_index &&
set_state dir/foo work index &&
(echo n; echo n; echo n) | test_must_fail git stash save -p &&
@@ -29,7 +35,7 @@ test_expect_success PERL 'saying "n" does nothing' '
verify_state dir/foo work index
 '
 
-test_expect_success PERL 'git stash -p' '
+test_expect_success 'git stash -p' '
(echo y; echo n; echo y) | git stash save -p &&
verify_state HEAD committed HEADfile_index &&
verify_saved_state bar &&
@@ -41,7 +47,7 @@ test_expect_success PERL 'git stash -p' '
verify_state dir/foo work head
 '
 
-test_expect_success PERL 'git stash -p --no-keep-index' '
+test_expect_success 'git stash -p --no-keep-index' '
set_state HEAD HEADfile_work HEADfile_index &&
set_state bar bar_work bar_index &&
set_state dir/foo work index &&
@@ -56,7 +62,7 @@ test_expect_success PERL 'git stash -p --no-keep-index' '
verify_state dir/foo work index
 '
 
-test_expect_success PERL 'git stash --no-keep-index -p' '
+test_expect_success 'git stash --no-keep-index -p' '
set_state HEAD HEADfile_work HEADfile_index &&
set_state bar bar_work bar_index &&
set_state dir/foo work index &&
@@ -71,7 +77,7 @@ test_expect_success PERL 'git stash --no-keep-index -p' '
verify_state dir/foo work index
 '
 
-test_expect_success PERL 'none of this moved HEAD' '
+test_expect_success 'none of this moved HEAD' '
verify_saved_head
 '
 
-- 
2.4.0.rc1.42.g9642cc6

--
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/4] t3904-stash-patch: fix test description

[Matthieu Moy]

The old description is rather clearly a wrong cut-and-paste from
t2016-checkout-patch.sh.

Signed-off-by: Matthieu Moy 
---
 t/t3904-stash-patch.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/t/t3904-stash-patch.sh b/t/t3904-stash-patch.sh
index 70655c1..9a59683 100755
--- a/t/t3904-stash-patch.sh
+++ b/t/t3904-stash-patch.sh
@@ -1,6 +1,6 @@
 #!/bin/sh
 
-test_description='git checkout --patch'
+test_description='stash -p'
 . ./lib-patch-mode.sh
 
 test_expect_success PERL 'setup' '
-- 
2.4.0.rc1.42.g9642cc6

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

[PATCH 0/4] demonstrate add -p and stash -p failures.

[Matthieu Moy]

Playing a bit with add -p and stash -p, I can confirm the bug reported
by Tanky. This series just adds failing tests, but I couldn't debug it.

I've exhausted my Git time budget for now, so if someone wants to take
over and fix the bugs, feel free to do it!

Matthieu Moy (4):
  add -p: demonstrate failure when running 'edit' after a split
  t3904-stash-patch: fix test description
  t3904-stash-patch: factor PERL prereq at the top of the file
  stash -p: demonstrate failure of split with mixed y/n

 t/t3701-add-interactive.sh | 25 +
 t/t3904-stash-patch.sh | 46 +++---
 2 files changed, 64 insertions(+), 7 deletions(-)

-- 
2.4.0.rc1.42.g9642cc6

--
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 4/4] stash -p: demonstrate failure of split with mixed y/n

[Matthieu Moy]

Signed-off-by: Matthieu Moy 
---
 t/t3904-stash-patch.sh | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/t/t3904-stash-patch.sh b/t/t3904-stash-patch.sh
index 0f8f47f..6f053ff 100755
--- a/t/t3904-stash-patch.sh
+++ b/t/t3904-stash-patch.sh
@@ -81,4 +81,30 @@ test_expect_success 'none of this moved HEAD' '
verify_saved_head
 '
 
+test_expect_failure 'stash -p with split hunk' '
+   git reset --hard &&
+   cat >test <<-\EOF &&
+   aaa
+   bbb
+   ccc
+   EOF
+   git add test &&
+   git commit -m "initial" &&
+   cat >test <<-\EOF &&
+   aaa
+   added line 1
+   bbb
+   added line 2
+   ccc
+   EOF
+   for a in s n y q
+   do
+   echo $a
+   done |
+   test_might_fail git stash -p 2>error &&
+   ! test_must_be_empty error &&
+   grep "added line 1" test &&
+   ! grep "added line 2" test
+'
+
 test_done
-- 
2.4.0.rc1.42.g9642cc6

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

[PATCH 1/4] add -p: demonstrate failure when running 'edit' after a split

[Matthieu Moy]

The test passes if one replaces the 'e' command with a 'y' command in
the 'add -p' session.

Reported-by: Tanky Woo 
Signed-off-by: Matthieu Moy 
---
 t/t3701-add-interactive.sh | 25 +
 1 file changed, 25 insertions(+)

diff --git a/t/t3701-add-interactive.sh b/t/t3701-add-interactive.sh
index 24ddd8a..b48a75c 100755
--- a/t/t3701-add-interactive.sh
+++ b/t/t3701-add-interactive.sh
@@ -335,6 +335,31 @@ test_expect_success 'split hunk "add -p (edit)"' '
! grep "^+15" actual
 '
 
+test_expect_failure 'split hunk "add -p (no, yes, edit)"' '
+   cat >test <<-\EOF &&
+   5
+   10
+   20
+   21
+   30
+   31
+   40
+   50
+   60
+   EOF
+   git reset &&
+   # test sequence is s(plit), n(o), y(es), e(dit)
+   # q n q q is there to make sure we exit at the end.
+   for a in s n y e   q n q q
+   do
+   echo $a
+   done |
+   EDITOR=: git add -p 2>error &&
+   test_must_be_empty error &&
+   git diff >actual &&
+   ! grep "^+31" actual
+'
+
 test_expect_success 'patch mode ignores unmerged entries' '
git reset --hard &&
test_commit conflict &&
-- 
2.4.0.rc1.42.g9642cc6

--
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: When and how to to contact the Git developers (gist)

[Thomas Ferris Nicolaisen]

On Mon, Apr 13, 2015 at 11:10 PM, Jonathan Nieder  wrote:
> Hi,
>
> Thomas Ferris Nicolaisen wrote:
>
>>  Perhaps someone here would prefer to use my gist when
>> redirecting people with "user questions" away from this list, or
>> inspire them to write better bug reports.
>
> This won't come as a surprise given what I said at Git Merge: I'd
> rather we don't redirect people with user questions away from this
> list.  The current volume has been pleasant and manageable.
>

I see your point. And I do see this working out well for freshly
created open-source projects with low traffic mailing lists.

However, this is a high traffic list, and that has the disadvantage of
blending user questions into a majority of patch- and expert
discussion.

This makes it (a) harder for the user needing help to recognise
existing contexts, and (b) harder for "amateurs" like myself to spot
other users that I can easily help out.

And then there is the whole Majordomo blocking emails for various
reasons issue, HTML being one of several, ref
. Here are some examples
of when we tried helping people on the Google Groups user list with
sending mail to this list:

https://groups.google.com/d/msg/git-users/iiNBWq3_uUs/ke2eDiumPEsJ
https://groups.google.com/d/msg/git-users/eT_UDv7TpjY/CfYE8jHQ_vYJ
https://groups.google.com/d/msg/git-users/qibnKchBf6I/UPtv1_Ctxm4J
https://groups.google.com/d/msg/git-users/4KXBwBXNd5Q/4yuBELlc8lUJ
https://groups.google.com/d/msg/git-users/Tl141kCJ45Q/-ToWHYfdmXEJ

And then there is the mental hurdle: I mean, I still consider it
intimidating to send mails to this list. A new user could in some
cases be terrified.

My personal reference are Apache projects: they always have one
dev-list, and a separate user-list. The key there is that the
user-list is adjacent to the dev-list, and all the devs (who are
interested) monitor the user-list closely.

So I'm historically/personally biased towards the dev/user split.
Perhaps you see this differently, and it is up to you (the consensus)
to choose what kind of traffic you want, or which behaviour you want
to discourage/encourage.

I'll also note the trend of how modern users are becoming less and
less users of email, turning to web-based forums instead for
assistance, and I enjoy the fact that Google Groups is an alternative
that offers seamless web- and email-based interaction.

To summarize: I think that usability problems of Majordomo have lead
you into a situation where you could consider embracing a user-list
like the one found at Google Groups.

Unless, of course, you believe that the users that make it through
here are a good representation of your user-base, and they provide
just enough input for you to steer the project forward. The rest of
the users in need of help, and I think that is a vast majority, will
find another outlet.

My own motivation is that I want all Git users to figure out their
problems as soon and as efficient as possible, and directing them to
the Google Group seems to be the best way IMHO.

> I especially disagree with
>
> Generally speaking, Git has very few bugs, and if you're not
> sure what you are doing, it's probably a user-issue, and not
> an issue for the Git developers.
>
> User issues are an issue for git developers.  The hardest part of
> making git work well is getting it to match how humans work, not
> getting it to be technically correct or theoretically bug free.
>
> So if I were writing it, I'd drop everything up to "If you believe
> you've found a bug in Git for Windows".

I've removed that sentence, and reformulated the part below. I'll keep
the link to the Groups list and StackOverflow for reasons mentioned
earlier.

> Another alternate forum to point people to is #git on freenode.  It is
> reachable from https://webchat.freenode.net, so a person seeking quick
> help doesn't even have to set up an IRC client.

Thanks, I've added this.

> It might be nice to add a note to the "If you can find no existing
> discussions" paragraph: if there's been a previous discussion, it's
> fine to raise the subject again.  A good practice is to link to and
> summarize the previous discussion so people can learn from what has
> happened before.

OK, added.
--
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

MDaemon Notification -- Attachment Removed

[Postmaster]

---
MDaemon has detected restricted attachments within an email message
---

>From  : git@vger.kernel.org
To: zafarzoba...@mega-in.com
Subject   : Report
Message-ID: 

-
Attachment(s) removed
-
zafarzoba...@mega-in.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: gitk won't show notes?

[Christian Couder]

On Sat, Apr 11, 2015 at 12:31 PM, Paul Mackerras  wrote:
> On Wed, Apr 08, 2015 at 01:51:40PM +0200, Michael J Gruber wrote:
>> Phillip Susi venit, vidit, dixit 07.04.2015 19:08:
>> > On 4/7/2015 10:13 AM, Michael J Gruber wrote:
>> >> Seriously: gitk knows F5 and Shift-F5 for refresh, and I think the
>> >> latter is the thorougher refreshment.
>> >
>> > Neither one makes newly added notes show up.  The only way seems to be
>> > to close and restart gitk.  Looks like a bug.
>> >
>> >
>>
>> Apparently, gitk rereads the refs but not commits it has read already -
>> and the commit reading includes the notes lookup.
>>
>> Unfortunately, my wish-fu is lacking. But I'll cc the master.
>>
>> Paulus: None of updatecommits, reloadcommits and rereadrefs seem to
>> reread the notes of a commit that has been displayed already if the
>> notes have changed (but the other refs have not).
>
> As far as shift-F5/reloadcommits is concerned, it looks like I should
> be unsetting commitinfo in reloadcommits.
>
> However, I agree gitk should refresh the notes in updatecommits as
> well, but that will take more work.  Is git notes list the best way to
> find out all the current notes?

It looks like it is from the documentation.
Anyway let's add some people in Cc in case they could help.
--
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 add -p “Your edited hunk does not apply. Edit again”

[Matthieu Moy]

Tanky Woo  writes:

> Stash this hunk [y,n,q,a,d,/,j,J,g,e,?]? y
> @@ -2,3 +3,4 @@
>  bbb
> +added line 2
>  ccc
>  ddd
> Stash this hunk [y,n,q,a,d,/,K,g,e,?]? y

My version does n, y, not y, y. The problem is the mix of stashed/not
stashed hunks. See my other message for a reproducible test, it does
fail on Git master.

-- 
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: git fsck: unreachable vs. dangling

[Sebastian Schuberth]

On Tue, Apr 14, 2015 at 10:52 AM, Sebastian Schuberth
 wrote:

>> A dangling object is an unreachable object that cannot be
>> made reachable by any way other than pointing at it
>> directly with a ref.
>
> Thanks a lot for the prompt explanation!

Note to myself: I just realized that both "dangling" and "unreachable"
are also nicely defined in the Git glossary [1].

[1] http://git-scm.com/docs/gitglossary/

-- 
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: Feature Request: provide cmdline args to git hooks

[Junio C Hamano]

"Chris O'Kelly"  writes:

> A brief background of my use case:
> I am wanting to write a pre-push hook to prevent tags being pushed to
> our production servers. The production servers in our case are --bare
> endpoints, and when we push a tag at them, they always checkout the
> commit that tag is attached to via some post-receive magic (WPEngine,
> FWIW). This behavior is even present when the tag was already pushed
> to the repo previously, if for instance a normal push is made with the
> --tags argument.

Do you mean that you want to forbid some people from pushing tags
into that repository while allowing others (i.e. those who manage
production deployment)?  If that is the goal, it sounds like that
the right place to do this is at the receiving end via pre-receive,
not at the sending end via pre-push.

--
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] reduce progress updates in background

[Nicolas Pitre]

On Tue, 14 Apr 2015, Luke Mewburn wrote:

> Updated patch where is_foreground_fd() is only called in display()
> just before the output is to be displayed.

Acked-by: Nicolas Pitre 


> 
--
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

PATH modifications for git-hook processes

[Matthew Rothenberg]

Using git 2.3.5 (on darwin, installed via homebrew), when executing a
script via the commit-msg githook, the following gets *prepended* to
the $PATH for the subprocess:

  
/usr/local/Cellar/git/2.3.5/libexec/git-core:/usr/local/Cellar/git/2.3.5/libexec/git-core:/usr/local/bin:{rest
of path...}

I can't find any documentation about this path modification behavior
in the git docs, and I'm not familiar enough with the source code to
locate it there either.

In our case, the prepending of /usr/local/bin is particularly
problematic, as it effectively reorders our chosen PATH hierarchy (in
which user-space versions of commands are picked up prior to system
installed ones).

(It's also curious that the git-core directory gets prepended twice,
but that doesn't cause us any particular issues.)

My questions:
 - what is the expected PATH modification behavior for subprocesses of
git-hooks? Is this documented anywhere?
 - what would be causing /usr/local/bin to be prepended here, and can
it be adjusted via preference?

Thanks!
--
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 fsck: unreachable vs. dangling

[Michael J Gruber]

Junio C Hamano venit, vidit, dixit 14.04.2015 11:22:
> Sebastian Schuberth  writes:
> 
>> On Tue, Apr 14, 2015 at 10:50 AM, Michael J Gruber
>>  wrote:
>>
>>> "to dangle" means "to hang loosely".
>>>
>>> So, in the description above, "A^ dangles from A loosely" because it
>>> hangs from A (you can reach it from A) but loosely, because it would
>>> "drop" if A gets dropped and A is "likely" to be dropped (because it is
>>> unreachable by refs). But A^ is not dangling in our terminology.
>>>
>>> If you *reverse the arrows*, i.e. consider A^ pointing to A, it becomes
>>> more apparent that A is dangling: it is an unreferenced leaf node.
>>
>> That's exactly what confused me. In the very literal sense, something
>> can only "hang loosely", i.e. dangle, if it's only tied at *one* end,
>> and that's the case for A (which is only connected to A^) but not for
>> A^ (which is connected to its parent, and A). Especially when talking
>> about A as a "leaf" node, like in the leaf of a natural tree, I would
>> think that A is dangling.
> 
> I am not sure if I follow, but probably it is just me who is not
> strong at math, or whose eyesight is not keen enough to notice the
> arrow heads on links between the commits.

"git log --graph" does not show arrow heads, obviously. Many
illustrations about Git do.

The relation between commits is clearly directed: A being a parent
commit of B is different from B being a parent commit of A (and both
cannot be true simultaneously due to the "A" in "DAG")

 > I just visualize commits to be ping-pong balls with strings between
> them, and then grab the root of the graph and lift the whole thing
> up, while tips of the branches and tags are anchored.  Commit A will
> be dangling in the wind if you shake the whole thing.

If you don't have a concept of direction it is difficult to distinguish
roots from tips...

Our commit relationship is certainly a directed one. You can define it
using either "is parent of" or "is child of". They are opposite, and
lead to opposite notions of "root" (a node without predecessors) and
"tip" (a node without successors).

> But that visualization breaks down once you start thinking about
> what will happen to A^{tree} and its blobs; they are attached to A
> with thin strings and they will have to float above A (i.e. sit
> somewhere closer to the root of the tree) just like A^ will go
> closer to the root, to make A appear the "dangling" one, as the
> direction of the arrow is from A to A^{tree} just like we have an
> arrow from A to A^; just like A^ is not dangling because of A,
> A^{tree} is not dangling.
> 
--
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 the "git merge" tee-shirt

[Matthieu Moy]

Jeff King  writes:

> On Mon, Apr 13, 2015 at 10:50:55PM +0200, Matthieu Moy wrote:
>
>> My second guess is that they represent directories.
>> But even then, I can't find which of the tee-shirt's circles represents
>> which directory, and the count doesn't match.
>> 
>> Does anybody have a better explanation? Or is it just a random drawing
>> to say "Git is bigger than it used to be"?
>
> I believe it is "gource"[1] output from 2005 and 2015, tweaked by a
> graphic designer to make it look nicer.

That would match my second guess. I guess the tweaks are what make it
hard to do the actual correspondance (there are 53 circles on the
drawing if I counted correctly, and 156 directory in today's Git for
example). The biggest dirs in number of files today are:

./builtin 99
./t/t5515 128
./t/t4013 144
./Documentation 221
./Documentation/RelNotes 242
. 378
./t 774

The directories at 4e7a2eccc21c902918 (Thu Dec 29 01:31:26 2005 -0800)
were:

./Documentation/technical 2
./mozilla-sha1 2
./arm 3
./ppc 3
./compat 4
./Documentation/howto 8
./templates 12
./debian 14
./t/t4100 14
./t 62
./Documentation 126
. 191

So, t/ would be a nice candidate for the big circle on the left hand
side (small in 2005, but biggest as of now), and ./ would be the one on
its right (used to be biggest, but no longer). Documentation/ is the one
at the top (with subdirs howto/ and technical/ in 2005, and the new
RelNotes/ today). I'm not sure where builtin/ is, it was probably
tweaked too much (it's supposed to be rather big in 2015 and inexistant
in 2005, without subdirs).

-- 
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

How to combine git repos with similar code and keep all branches and tags?

[Jose de Leon]

Hi All,


I've got an interesting problem and the possible solutions I've found from 
searching google don't seem to work for us.  In a nutshell, I need to combine 
multiple git repositories into single repository and preserve all history, 
branches and tags from each repository.

Does anybody have a solution for this, how do this kind of thing, is it even 
possible?

For some unknown reason to me, our developers started a git project, called 
Ver1, this was the first version.  Then sometime later, they created a new git 
repository called Ver2, the initial commit for Ver2 was essentially a copy of 
the code in Ver1 from the master.  They didn't clone it, they just copied the 
code at the latest point.  This wasn't done by forking.  Then they repeated 
this for Ver3 and Ver4, etc.  On top of all that, they have been adding new 
code to Ver1, Ver2, etc. that has caused each to divert from the other and each 
have their own branch and tag sets.  They have similar directory structure and 
similar file names, but there are some slight differences in structure.

Well, this has become unmanageable and now we want to combine them into one 
single git repository.   

Logically, these are the same project but at different versions, basically, 
Ver1 and Ver2, etc, should be simply branches at different times if these were 
combined into a single repository.





--
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

Ensimag students project on Git, 2015 edition

[Matthieu Moy]

Hi,

Like the years before, I'm going to offer my students a 1 month project
(mid May -> mid June) where they can contribute to a free software, in
particular Git. Last year we got no student, but in the past we got
interesting features merged in (e.g. "git blame" with textconv, hints in
"git status", git-remote-mediawiki, better error messages).

Students are free to pick the feature they want, but I maintain a list
of small project ideas on the wiki to help them:

  https://git.wiki.kernel.org/index.php/SmallProjectsIdeas

feel free to edit and comment, add new ideas,  Students will anyway
have to discuss on the mailing-list before starting to code anything
non-trivial.

Thanks,

-- 
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: How to combine git repos with similar code and keep all branches and tags?

[Matthieu Moy]

Jose de Leon  writes:

> For some unknown reason to me, our developers started a git project,
> called Ver1, this was the first version. Then sometime later, they
> created a new git repository called Ver2, the initial commit for Ver2
> was essentially a copy of the code in Ver1 from the master. They
> didn't clone it, they just copied the code at the latest point.

This is why "graft points" were created, and then superseeded by "git
replace".

See http://git-scm.com/blog/2010/03/17/replace.html and
http://git-scm.com/docs/git-replace

-- 
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: git commit --date format

[Junio C Hamano]

乙酸鋰  writes:

> Hi,
>
> In git < 2.0, git commit --amend --date="" can amend commit with
> current time as author time.
> But since git 2.0, this does not work, dying with "invalid date format".
> I have to instead type git commit --amend --date="now".
> Is empty string date format no longer supported? Or will be fixed?

I think this was a fix to the overly loose parser which took any
typo (including an empty string, e.g. --date="$prevuois" that
misspels the name of a shell variable that has the timestamp) as
"now".

--
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: PATH modifications for git-hook processes

[Junio C Hamano]

Matthew Rothenberg  writes:

>  - what is the expected PATH modification behavior for subprocesses of
> git-hooks? Is this documented anywhere?
>  - what would be causing /usr/local/bin to be prepended here, and can
> it be adjusted via preference?

This is not limited to hooks and very much deliberate, I think.  In
order to make sure anything that is called from "git" wrapper gets
picked up from GIT_EXEC_PATH so that the matching version of the git
subprogram is used, "git " does this before running "git-"
(in git.c):

/*
 * We use PATH to find git commands, but we prepend some higher
 * precedence paths: the "--exec-path" option, the GIT_EXEC_PATH
 * environment, and the $(gitexecdir) from the Makefile at build
 * time.
 */
setup_path();

And setup_path() is defined in exec_cmd.c to start the new PATH with
git-exec-path, and then the path to the running "git" itself, and
then finally the external PATH.
--
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: How to combine git repos with similar code and keep all branches and tags?

[Junio C Hamano]

Matthieu Moy  writes:

> Jose de Leon  writes:
>
>> For some unknown reason to me, our developers started a git project,
>> called Ver1, this was the first version. Then sometime later, they
>> created a new git repository called Ver2, the initial commit for Ver2
>> was essentially a copy of the code in Ver1 from the master. They
>> didn't clone it, they just copied the code at the latest point.
>
> This is why "graft points" were created, and then superseeded by "git
> replace".
>
> See http://git-scm.com/blog/2010/03/17/replace.html and
> http://git-scm.com/docs/git-replace

After setting up either grafts or replaces, I'd strongly recommend
running filter-branch or bfg to rewrite the history of the combined
result, and have the developers use that rewritten history _after_
removing the grafts (or replaces).

And if you are going to go that route, then graft is sufficient and
a lot more light-weight.  The only advantage replace has over grafts
is that they can be transferred using "git push" and "git fetch"
(while grafts can be transferred with some file transfer mechanism
outside Git) but if you are rewriting the history, that advantage is
lost.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 1/7] path.c: implement xdg_config_home()

[Paul Tan]

Hi,

On Mon, Apr 13, 2015 at 05:50:49PM +0200, Johannes Schindelin wrote:
> maybe it would be a good idea to add a `0/7` mail that describes the
> overall goal of this patch series, much like a Pull Request? I found
> it very useful -- even for myself -- to set a description via `git
> branch --edit-description` and to let `git format-patch` use that via
> the `--cover-letter` option.

In this case I felt that the first patch's commit message was
descriptive enough and a cover message would simply repeat it.

> below just two minor nits because the rest of the patches looks fine to me:
> 
> On 2015-04-12 09:46, Paul Tan wrote:
> > diff --git a/cache.h b/cache.h
> > index 3d3244b..7f9bab0 100644
> > --- a/cache.h
> > +++ b/cache.h
> > @@ -836,6 +836,13 @@ char *strip_path_suffix(const char *path, const
> > char *suffix);
> >  int daemon_avoid_alias(const char *path);
> >  extern int is_ntfs_dotgit(const char *name);
> >  
> > +/**
> > + * Returns the newly allocated string "$XDG_CONFIG_HOME/git/%s".  If
> > + * $XDG_CONFIG_HOME is unset or empty, returns the newly allocated string
> > + * "$HOME/.config/git/%s". Returns NULL if an error occurred.
> > + */
> > +extern char *xdg_config_home(const char *fn);
> 
> Should this not be inserted close to home_config_paths()?

A personal style thing, but I wanted to add the function's docstring to
cache.h (where I personally think it belongs), but I didn't want to
break up the huge block of path function declarations. Hence, it was
added at the end.

> Also, the name "fn" sounds more like "function" than like "filename"
> to me, especially keeping the name `config_fn_t` in mind. Maybe call
> the parameter "filename" to avoid confusion?

That's true, especially since there is still lots of horizontal space
for this name.

Below is the fixed patch. I also decided to return NULL if `filename` is
NULL because such an input usually indicated an uncaught error. The
docstring has also been modified to be a little clearer.

Thanks all for the reviews.

 >8 
The XDG base dir spec[1] specifies that configuration files be stored in
a subdirectory in $XDG_CONFIG_HOME. To construct such a configuration
file path, home_config_paths() can be used. However, home_config_paths()
combines distinct functionality:

1. Retrieve the home git config file path ~/.gitconfig

2. Construct the XDG config path of the file specified by `file`.

This function was introduced in commit 21cf3227 ("read (but not write)
from $XDG_CONFIG_HOME/git/config file").  While the intention of the
function was to allow the home directory configuration file path and the
xdg directory configuration file path to be retrieved with one function
call, the hard-coding of the path ~/.gitconfig prevents it from being
used for other configuration files. Furthermore, retrieving a file path
relative to the user's home directory can be done with
expand_user_path(). Hence, it can be seen that home_config_paths()
introduces unnecessary complexity, especially if a user just wants to
retrieve the xdg config file path.

As such, implement a simpler function xdg_config_home() for constructing
the XDG base dir spec configuration file path. This function, together
with expand_user_path(), can replace all uses of home_config_paths().

[1] http://standards.freedesktop.org/basedir-spec/basedir-spec-0.7.html

Signed-off-by: Paul Tan 
---
 cache.h |  8 
 path.c  | 16 
 2 files changed, 24 insertions(+)

diff --git a/cache.h b/cache.h
index 3d3244b..2db10b8 100644
--- a/cache.h
+++ b/cache.h
@@ -836,6 +836,14 @@ char *strip_path_suffix(const char *path, const char 
*suffix);
 int daemon_avoid_alias(const char *path);
 extern int is_ntfs_dotgit(const char *name);
 
+/**
+ * Returns the newly allocated string "$XDG_CONFIG_HOME/git/{filename}".  If
+ * $XDG_CONFIG_HOME is unset or empty, returns the newly allocated string
+ * "$HOME/.config/git/{filename}". Returns NULL if filename is NULL or an error
+ * occurred.
+ */
+extern char *xdg_config_home(const char *filename);
+
 /* object replacement */
 #define LOOKUP_REPLACE_OBJECT 1
 extern void *read_sha1_file_extended(const unsigned char *sha1, enum 
object_type *type, unsigned long *size, unsigned flag);
diff --git a/path.c b/path.c
index e608993..8ee7191 100644
--- a/path.c
+++ b/path.c
@@ -856,3 +856,19 @@ int is_ntfs_dotgit(const char *name)
len = -1;
}
 }
+
+char *xdg_config_home(const char *filename)
+{
+   const char *config_home = getenv("XDG_CONFIG_HOME");
+
+   if (!filename)
+   return NULL;
+   if (!config_home || !config_home[0]) {
+   const char *home = getenv("HOME");
+
+   if (!home)
+   return NULL;
+   return mkpathdup("%s/.config/git/%s", home, filename);
+   } else
+   return mkpathdup("%s/git/%s", config_home, filename);
+}
-- 
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe git" in
th

RE: How to combine git repos with similar code and keep all branches and tags?

[Jose de Leon]

Thank you!

-Original Message-
From: Max Horn [mailto:m...@quendi.de] 
Sent: Tuesday, April 14, 2015 10:15 AM
To: Jose de Leon
Cc: git@vger.kernel.org
Subject: Re: How to combine git repos with similar code and keep all branches 
and tags?

Hi Jose,

On 14.04.2015, at 18:44, Jose de Leon  wrote:

> Hi All,
> 
> 
> I've got an interesting problem and the possible solutions I've found from 
> searching google don't seem to work for us.  In a nutshell, I need to combine 
> multiple git repositories into single repository and preserve all history, 
> branches and tags from each repository.
> 
> Does anybody have a solution for this, how do this kind of thing, is it even 
> possible?
> 
> For some unknown reason to me, our developers started a git project, called 
> Ver1, this was the first version.  Then sometime later, they created a new 
> git repository called Ver2, the initial commit for Ver2 was essentially a 
> copy of the code in Ver1 from the master.  They didn't clone it, they just 
> copied the code at the latest point.  This wasn't done by forking.  Then they 
> repeated this for Ver3 and Ver4, etc.  On top of all that, they have been 
> adding new code to Ver1, Ver2, etc. that has caused each to divert from the 
> other and each have their own branch and tag sets.  They have similar 
> directory structure and similar file names, but there are some slight 
> differences in structure.
> 
> Well, this has become unmanageable and now we want to combine them into one 
> single git repository.   
> 
> Logically, these are the same project but at different versions, basically, 
> Ver1 and Ver2, etc, should be simply branches at different times if these 
> were combined into a single repository.

Here is one possible way to go about this using grafts (I used something 
similar in the past);

1) Get all the data into a single git repository.

  Since everything is already in a git repositories, you could e.g. create a
  clone of Ver1; then add remotes for Ver2 ... VerN, and fetch them all,
  along with tags. If there are conflicts between branch or tag names, deal
  with them at this point.

2) Create graft points to tie the history together.

   Identify the commit in Ver1 at which Ver2 branched off. Then, graft that
   as parent for the initial commits of Ver2. See here for some basic
   instructions 

 or feel
   free to ask for details (or Google, or... :)

   Repeat vor Ver2+Ver3, Ver3+Ver4, etc.

3) Finally, you can get rid of the graft points, and turn everything into a 
"proper" history, by running "git filter-branch". Something like

  git filter-branch -- --all

ought to do it, but I might be forgetting something (I am sure somebody will 
correct me soon in that case, though ;-). Best to have a look at 

 for yourself, though.


This all is under the assumption that you want to stay as close to how things 
really were (usually a good idea). But sometimes it may be desirable to make 
further adjustments. E.g. you may wish to adjust committer names, rearrange 
some stuff (though usually git is quite good at doing the right thing 
automatically, etc. How to do that of course depends on what exactly you want 
to do, but in many cases, filter-branch is your friend.

Hope that helps!

Max

--
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: How to combine git repos with similar code and keep all branches and tags?

[Max Horn]

Hi Jose,

On 14.04.2015, at 18:44, Jose de Leon  wrote:

> Hi All,
> 
> 
> I've got an interesting problem and the possible solutions I've found from 
> searching google don't seem to work for us.  In a nutshell, I need to combine 
> multiple git repositories into single repository and preserve all history, 
> branches and tags from each repository.
> 
> Does anybody have a solution for this, how do this kind of thing, is it even 
> possible?
> 
> For some unknown reason to me, our developers started a git project, called 
> Ver1, this was the first version.  Then sometime later, they created a new 
> git repository called Ver2, the initial commit for Ver2 was essentially a 
> copy of the code in Ver1 from the master.  They didn't clone it, they just 
> copied the code at the latest point.  This wasn't done by forking.  Then they 
> repeated this for Ver3 and Ver4, etc.  On top of all that, they have been 
> adding new code to Ver1, Ver2, etc. that has caused each to divert from the 
> other and each have their own branch and tag sets.  They have similar 
> directory structure and similar file names, but there are some slight 
> differences in structure.
> 
> Well, this has become unmanageable and now we want to combine them into one 
> single git repository.   
> 
> Logically, these are the same project but at different versions, basically, 
> Ver1 and Ver2, etc, should be simply branches at different times if these 
> were combined into a single repository.

Here is one possible way to go about this using grafts (I used something
similar in the past);

1) Get all the data into a single git repository.

  Since everything is already in a git repositories, you could e.g. create a
  clone of Ver1; then add remotes for Ver2 ... VerN, and fetch them all,
  along with tags. If there are conflicts between branch or tag names, deal
  with them at this point.

2) Create graft points to tie the history together.

   Identify the commit in Ver1 at which Ver2 branched off. Then, graft that
   as parent for the initial commits of Ver2. See here for some basic
   instructions  or feel
   free to ask for details (or Google, or... :)

   Repeat vor Ver2+Ver3, Ver3+Ver4, etc.

3) Finally, you can get rid of the graft points, and turn everything into a
"proper" history, by running "git filter-branch". Something like

  git filter-branch -- --all

ought to do it, but I might be forgetting something (I am sure somebody will
correct me soon in that case, though ;-). Best to have a look at
 for yourself, though.


This all is under the assumption that you want to stay as close to how
things really were (usually a good idea). But sometimes it may be desirable
to make further adjustments. E.g. you may wish to adjust committer names,
rearrange some stuff (though usually git is quite good at doing the right
thing automatically, etc. How to do that of course depends on what exactly
you want to do, but in many cases, filter-branch is your friend.

Hope that helps!

Max

--
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/4] demonstrate add -p and stash -p failures.

[Junio C Hamano]

Matthieu Moy  writes:

> Playing a bit with add -p and stash -p, I can confirm the bug reported
> by Tanky. This series just adds failing tests, but I couldn't debug it.
>
> I've exhausted my Git time budget for now, so if someone wants to take
> over and fix the bugs, feel free to do it!

I do not have time to dig this either for now, but I suspect this
"split a hunk into two overlapping hunks" issue may be related to
the caveat in the very original:


http://thread.gmane.org/gmane.comp.version-control.git/76650/focus=87197


where I seem to have said that the proposed change would make "add
-p" less robust than the original code (even without 'e'dit):

Junio C Hamano wrote:
> 
> I recall that the original "add--interactive" carefully counted
> numbers in hunks it reassembles (as it can let you split and then
> you can choose to use both parts, which requires it to merge
> overlapping hunks back), but if you are going to use --recount
> anyway, perhaps we can discard that logic?  It may make the patch
> application less robust, though.  I dunno.


It seems that we accepted that series saying "let's see what
happens" at the end, and I suspect we are seeing its consequences
;-).

--
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

Error staging submodule removal when empty directory present

[Josh Hagins]

I'm having a hard time understanding why ``git stash save" chokes on a
submodule removal when an empty directory is present at the removed
submodule's path. If the submodule is staged for deletion, why not
just leave the empty directory alone?

The following Gist illustrates the situation I am encountering, and
includes OS information, Git version (2.3.5), and GIT_TRACE output:
https://gist.github.com/jawshooah/d60ff70952cff18099d7

Relevant post in the git-users Google Group, where I was encouraged to
query the mailing list:
https://groups.google.com/forum/#!topic/git-users/3YxxpVVXtqg

Thanks,
Josh
--
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 + SFC Status Update

[Dave Borowitz]

On Mon, Apr 13, 2015 at 7:56 AM, Jeff King  wrote:
> # Money: How much do we have?
>
>  - $19,059.25 (USD)
>
> // Disclaimer: this is not necessarily up-to-the-minute, as
> // SFC's reports to us sometimes lag a bit. And also because
> // I am fairly inexperienced using the `ledger` program, so
> // it's possible I've misinterpreted the results. However, we
> // shouldn't have any serious outstanding expenses, so this
> // is close to correct.

If I recall correctly, Scott said onstage that some/all of the
conference proceeds would be going directly into this fund. So this
might need to be revised upward by 50-100% sometime soon :)
--
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 + SFC Status Update

[Junio C Hamano]

Dave Borowitz  writes:

> On Mon, Apr 13, 2015 at 7:56 AM, Jeff King  wrote:
>> # Money: How much do we have?
>>
>>  - $19,059.25 (USD)
>>
>> // Disclaimer: this is not necessarily up-to-the-minute, as
>> // SFC's reports to us sometimes lag a bit. And also because
>> // I am fairly inexperienced using the `ledger` program, so
>> // it's possible I've misinterpreted the results. However, we
>> // shouldn't have any serious outstanding expenses, so this
>> // is close to correct.
>
> If I recall correctly, Scott said onstage that some/all of the
> conference proceeds would be going directly into this fund. So this
> might need to be revised upward by 50-100% sometime soon :)

I think you misheard it.  The above is money earmarked for Git at
SFC; the admission for GitMerge were going to SFC general fund
without earmarked for us, IIUC.

--
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-p4: Use -m when running p4 changes

[Lex Spoon]

(resending with accidental HTML removed)


Great, I'm glad it looks like a good approach!

I'll add a test case for it and to support the test case, an
option for the block size. I guess the block-size option will go on
"sync", "clone", and "fetch". Alternatively, maybe someone has a
better suggestion of how to configure the block size.

Lex Spoon
--
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/7] path.c: implement xdg_config_home()

[Junio C Hamano]

Johannes Schindelin  writes:

>> diff --git a/cache.h b/cache.h
>> index 3d3244b..7f9bab0 100644
>> --- a/cache.h
>> +++ b/cache.h
>> @@ -836,6 +836,13 @@ char *strip_path_suffix(const char *path, const
>> char *suffix);
>>  int daemon_avoid_alias(const char *path);
>>  extern int is_ntfs_dotgit(const char *name);
>>  
>> +/**
>> + * Returns the newly allocated string "$XDG_CONFIG_HOME/git/%s".  If
>> + * $XDG_CONFIG_HOME is unset or empty, returns the newly allocated string
>> + * "$HOME/.config/git/%s". Returns NULL if an error occurred.
>> + */
>> +extern char *xdg_config_home(const char *fn);
>
> Should this not be inserted close to home_config_paths()? Also, the
> name "fn" sounds more like "function" than like "filename" to me,
> especially keeping the name `config_fn_t` in mind. Maybe call the
> parameter "filename" to avoid confusion?

It is OK to omit the name in the extern declaration here.  We have
to have a sensible variable name in the definition in path.c, of
course ;-), and "filename" sounds like a very sensible suggestion.


--
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 4/4] stash -p: demonstrate failure of split with mixed y/n

[Eric Sunshine]

On Tue, Apr 14, 2015 at 7:32 AM, Matthieu Moy  wrote:
> Signed-off-by: Matthieu Moy 
> ---
> diff --git a/t/t3904-stash-patch.sh b/t/t3904-stash-patch.sh
> index 0f8f47f..6f053ff 100755
> --- a/t/t3904-stash-patch.sh
> +++ b/t/t3904-stash-patch.sh
> @@ -81,4 +81,30 @@ test_expect_success 'none of this moved HEAD' '
> verify_saved_head
>  '
>
> +test_expect_failure 'stash -p with split hunk' '
> +   git reset --hard &&
> +   cat >test <<-\EOF &&
> +   aaa
> +   bbb
> +   ccc
> +   EOF
> +   git add test &&
> +   git commit -m "initial" &&
> +   cat >test <<-\EOF &&
> +   aaa
> +   added line 1
> +   bbb
> +   added line 2
> +   ccc
> +   EOF
> +   for a in s n y q
> +   do
> +   echo $a
> +   done |

Simplified:

printf '%s\n' s n y q |

> +   test_might_fail git stash -p 2>error &&
> +   ! test_must_be_empty error &&
> +   grep "added line 1" test &&
> +   ! grep "added line 2" test
> +'
> +
>  test_done
> --
> 2.4.0.rc1.42.g9642cc6
--
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/4] add -p: demonstrate failure when running 'edit' after a split

[Eric Sunshine]

On Tue, Apr 14, 2015 at 7:32 AM, Matthieu Moy  wrote:
> The test passes if one replaces the 'e' command with a 'y' command in
> the 'add -p' session.
>
> Reported-by: Tanky Woo 
> Signed-off-by: Matthieu Moy 
> ---
> diff --git a/t/t3701-add-interactive.sh b/t/t3701-add-interactive.sh
> index 24ddd8a..b48a75c 100755
> --- a/t/t3701-add-interactive.sh
> +++ b/t/t3701-add-interactive.sh
> @@ -335,6 +335,31 @@ test_expect_success 'split hunk "add -p (edit)"' '
> ! grep "^+15" actual
>  '
>
> +test_expect_failure 'split hunk "add -p (no, yes, edit)"' '
> +   cat >test <<-\EOF &&
> +   5
> +   10
> +   20
> +   21
> +   30
> +   31
> +   40
> +   50
> +   60
> +   EOF
> +   git reset &&
> +   # test sequence is s(plit), n(o), y(es), e(dit)
> +   # q n q q is there to make sure we exit at the end.
> +   for a in s n y e   q n q q
> +   do
> +   echo $a
> +   done |

Simplified:

printf '%s\n' s n y e q n q q |

> +   EDITOR=: git add -p 2>error &&
> +   test_must_be_empty error &&
> +   git diff >actual &&
> +   ! grep "^+31" actual
> +'
> +
>  test_expect_success 'patch mode ignores unmerged entries' '
> git reset --hard &&
> test_commit conflict &&
> --
> 2.4.0.rc1.42.g9642cc6
--
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: gitk won't show notes?

[Johan Herland]

On Tue, Apr 14, 2015 at 2:17 PM, Christian Couder
 wrote:
> On Sat, Apr 11, 2015 at 12:31 PM, Paul Mackerras  wrote:
>> However, I agree gitk should refresh the notes in updatecommits as
>> well, but that will take more work.  Is git notes list the best way to
>> find out all the current notes?

Yes. (if not, that's a bug and should be fixed).

...Johan

>
> It looks like it is from the documentation.
> Anyway let's add some people in Cc in case they could help.



-- 
Johan Herland, 
www.herland.net
--
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

What's cooking in git.git (Apr 2015, #02; Tue, 14)

[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'.

The second release candidate 2.4-rc2 has been tagged.  There were a
few more topics I felt are safe to merge, but they had updates to
translatable strings, which would add last-minute burden to our l10n
teams, so they are held back for the remainder of the cycle.

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"]

* iu/fix-parse-options-h-comment (2015-03-29) 1 commit
  (merged to 'next' on 2015-04-02 at 7fd3cef)
 + parse-options.h: OPTION_{BIT,SET_INT} do not store pointer to defval


* jc/update-instead-into-void (2015-04-01) 1 commit
  (merged to 'next' on 2015-04-08 at 8ef4e15)
 + push-to-deploy: allow pushing into an unborn branch and updating it

 A push into an unborn branch, with "receive.denyCurrentBranch" set
 to "updateInstead", did not check out the working tree as expected.


* jk/cherry-pick-docfix (2015-03-30) 1 commit
  (merged to 'next' on 2015-04-02 at 40da1d7)
 + cherry-pick: fix docs describing handling of empty commits


* jk/colors (2015-04-04) 1 commit
  (merged to 'next' on 2015-04-08 at 9b9e6f2)
 + diff-highlight: do not split multibyte characters

 "diff-highlight" (in contrib/) used to show byte-by-byte
 differences, which meant that multi-byte characters can be chopped
 in the middle.  It learned to pay attention to character boundaries
 (assuming the UTF-8 payload).


* jk/merge-quiet (2015-04-02) 1 commit
  (merged to 'next' on 2015-04-08 at 6475433)
 + merge: pass verbosity flag down to merge-recursive

 "git merge --quiet" did not squelch messages from the underlying
 merge-recursive strategy.


* jk/pack-corruption-post-mortem (2015-04-01) 1 commit
  (merged to 'next' on 2015-04-08 at 890c04e)
 + howto: document more tools for recovery corruption

 Documentation update.


* jn/doc-fast-import-no-16-octopus-limit (2015-03-31) 1 commit
  (merged to 'next' on 2015-04-08 at 341ca70)
 + fast-import doc: remove suggested 16-parent limit

 Documentation update.


* jz/gitweb-conf-doc-fix (2015-03-31) 1 commit
  (merged to 'next' on 2015-04-02 at 237d1bc)
 + gitweb.conf.txt: say "build-time", not "built-time"

 Documentation update.


* pt/enter-repo-comment-fix (2015-03-31) 1 commit
  (merged to 'next' on 2015-04-02 at 276ad7e)
 + enter_repo(): fix docs to match code

 Documentation update.


* sb/plug-streaming-leak (2015-03-31) 1 commit
  (merged to 'next' on 2015-04-08 at 226bdd8)
 + streaming.c: fix a memleak


* sb/plug-wt-shortstatus-tracking-leak (2015-03-30) 1 commit
  (merged to 'next' on 2015-04-08 at bd6291b)
 + wt-status.c: fix a memleak

--
[New Topics]

* ah/usage-strings (2015-04-02) 2 commits
 - branch: fix funny-sounding error message
 - standardize usage strings that were missed the first time

 A few usage string updates.

 Will hold.


* jk/reading-packed-refs (2015-04-05) 6 commits
 - refname_is_safe: avoid expensive normalize_path_copy call
 - t1430: add another refs-escape test
 - strbuf: add an optimized 1-character strbuf_grow
 - strbuf_getwholeline: use getc_unlocked
 - git-compat-util: add fallbacks for unlocked stdio
 - strbuf_getwholeline: use getc macro

 An earlier rewrite to use strbuf_getwholeline() instead of fgets(3)
 to read packed-refs file revealed that the former is unacceptably
 inefficient.

 There were further discussions on this topic to use getdelim(3).
 $gmane/266932

 Expecting a reroll.


* kk/log-merges-config (2015-04-04) 5 commits
 - bash-completion: add support for git-log --merges= and log.merges
 - t4202-log: add tests for --merges=
 - Documentation: add git-log --merges= option and log.merges config. var
 - log: honor log.merges= option
 - revision: add --merges={show|only|hide} option

 "git log" (but not other commands in the "log" family) learned to
 pay attention to the log.merges configuration variable that can be
 set to "show" (the normal behaviour), "only" (hide non-merge
 commits), or "hide" (hide merge commits).  --merges=(show|only|hide)
 can be used to override the setting from the command line.

 The documentation may need to be updated once more.


* kn/cat-file-literally (2015-04-05) 5 commits
 - SQUASH???
 - t1006: add tests for git cat-file --literally
 - cat-file: add documentation for '--literally' option.
 - cat-file: teach cat-file a '--literally' option
 - sha1_file.c: support reading from a loose object of unknown type

 Add the "--literally" option to "cat-file" to allow inspecting
 loose objects of an experimental or a broken type.

 This is v7 $gmane/266761; getting closer to the final, I would say.


* ld/p4-filetype-detection (2015-04-04) 3 commits
  (merged to 'next' on 2015-04-08 at da735b4)
 + git-p4: fix filety

[ANNOUNCE] Git v2.4.0-rc2

[Junio C Hamano]

A release candidate Git v2.4.0-rc2 is now available for testing at
the usual places.  The difference since -rc1 is mostly l10n and a
handful of documentation clean-ups.

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-rc2'
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. These are not meant to be parsed by scripts, but
the users still may want to be aware of the changes:

 * 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 before v1.0.

 * A new "push.followTags"

[PATCH 2/3] t7004: rename ULIMIT test prerequisite to ULIMIT_STACK_SIZE

[Stefan Beller]

During creation of the patch series our discussion we could have a
more descriptive name for the prerequisite for the test so it stays
unique when other limits of ulimit are introduced.

Signed-off-by: Stefan Beller 
Signed-off-by: Junio C Hamano 
---
 t/t7004-tag.sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/t/t7004-tag.sh b/t/t7004-tag.sh
index 796e9f7..06b8e0d 100755
--- a/t/t7004-tag.sh
+++ b/t/t7004-tag.sh
@@ -1463,10 +1463,10 @@ run_with_limited_stack () {
(ulimit -s 128 && "$@")
 }
 
-test_lazy_prereq ULIMIT 'run_with_limited_stack true'
+test_lazy_prereq ULIMIT_STACK_SIZE 'run_with_limited_stack true'
 
 # we require ulimit, this excludes Windows
-test_expect_success ULIMIT '--contains works in a deep repo' '
+test_expect_success ULIMIT_STACK_SIZE '--contains works in a deep repo' '
>expect &&
i=1 &&
while test $i -lt 8000
-- 
2.3.0.81.gc37f363

--
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/3] Large transactions in git

[Stefan Beller]

On Git Merge Wilhelm Bierbaum from Twitter made clear that we'd have problems
with large transactions in git. As I have been working on that series a few
months ago and it still bugs me, I thought about reviving the series.

However the series got stale a few months ago because we were not sure how
to do it right. The first few patches were deemed uncontroversial though,
which I am resending now. 

The first patch contains tests telling us what needs fixing.
The second patch renames the precondition for other tests, as ULIMIT is
a bit generic. The third patch removes the `lock_fd` field from struct
ref_lock which was duplicate information.

That said, this series is not fixing the actual issue, but I'd guess
having these patches is step forward actually.

Thanks,
Stefan

Stefan Beller (3):
  update-ref: test handling large transactions properly
  t7004: rename ULIMIT test prerequisite to ULIMIT_STACK_SIZE
  refs.c: remove lock_fd from struct ref_lock

 refs.c| 16 ++--
 t/t1400-update-ref.sh | 28 
 t/t7004-tag.sh|  4 ++--
 3 files changed, 36 insertions(+), 12 deletions(-)

-- 
2.3.0.81.gc37f363

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

[PATCH 3/3] refs.c: remove lock_fd from struct ref_lock

[Stefan Beller]

The 'lock_fd' is the same as 'lk->fd'. No need to store it twice so remove
it. You may argue this introduces more coupling as we need to know more
about the internals of the lock file mechanism, but this will be solved in
a later patch.

No functional changes intended.

Signed-off-by: Stefan Beller 
Signed-off-by: Junio C Hamano 
---
 refs.c | 16 ++--
 1 file changed, 6 insertions(+), 10 deletions(-)

diff --git a/refs.c b/refs.c
index 14e52ca..4066752 100644
--- a/refs.c
+++ b/refs.c
@@ -11,7 +11,6 @@ struct ref_lock {
char *orig_ref_name;
struct lock_file *lk;
unsigned char old_sha1[20];
-   int lock_fd;
int force_write;
 };
 
@@ -2259,7 +2258,6 @@ static struct ref_lock *lock_ref_sha1_basic(const char 
*refname,
int attempts_remaining = 3;
 
lock = xcalloc(1, sizeof(struct ref_lock));
-   lock->lock_fd = -1;
 
if (mustexist)
resolve_flags |= RESOLVE_REF_READING;
@@ -2335,8 +2333,8 @@ static struct ref_lock *lock_ref_sha1_basic(const char 
*refname,
goto error_return;
}
 
-   lock->lock_fd = hold_lock_file_for_update(lock->lk, ref_file, lflags);
-   if (lock->lock_fd < 0) {
+   if (hold_lock_file_for_update(lock->lk, ref_file, lflags) < 0) {
+   last_errno = errno;
if (errno == ENOENT && --attempts_remaining > 0)
/*
 * Maybe somebody just deleted one of the
@@ -2904,7 +2902,6 @@ static int close_ref(struct ref_lock *lock)
 {
if (close_lock_file(lock->lk))
return -1;
-   lock->lock_fd = -1;
return 0;
 }
 
@@ -2912,7 +2909,6 @@ static int commit_ref(struct ref_lock *lock)
 {
if (commit_lock_file(lock->lk))
return -1;
-   lock->lock_fd = -1;
return 0;
 }
 
@@ -3090,8 +3086,8 @@ static int write_ref_sha1(struct ref_lock *lock,
errno = EINVAL;
return -1;
}
-   if (write_in_full(lock->lock_fd, sha1_to_hex(sha1), 40) != 40 ||
-   write_in_full(lock->lock_fd, &term, 1) != 1 ||
+   if (write_in_full(lock->lk->fd, sha1_to_hex(sha1), 40) != 40 ||
+   write_in_full(lock->lk->fd, &term, 1) != 1 ||
close_ref(lock) < 0) {
int save_errno = errno;
error("Couldn't write %s", lock->lk->filename.buf);
@@ -4047,9 +4043,9 @@ int reflog_expire(const char *refname, const unsigned 
char *sha1,
status |= error("couldn't write %s: %s", log_file,
strerror(errno));
} else if ((flags & EXPIRE_REFLOGS_UPDATE_REF) &&
-   (write_in_full(lock->lock_fd,
+   (write_in_full(lock->lk->fd,
sha1_to_hex(cb.last_kept_sha1), 40) != 40 ||
-write_str_in_full(lock->lock_fd, "\n") != 1 ||
+write_str_in_full(lock->lk->fd, "\n") != 1 ||
 close_ref(lock) < 0)) {
status |= error("couldn't write %s",
lock->lk->filename.buf);
-- 
2.3.0.81.gc37f363

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

[PATCH 1/3] update-ref: test handling large transactions properly

[Stefan Beller]

Signed-off-by: Stefan Beller 
Signed-off-by: Junio C Hamano 
---
 t/t1400-update-ref.sh | 28 
 1 file changed, 28 insertions(+)

diff --git a/t/t1400-update-ref.sh b/t/t1400-update-ref.sh
index 7b4707b..47d2fe9 100755
--- a/t/t1400-update-ref.sh
+++ b/t/t1400-update-ref.sh
@@ -973,4 +973,32 @@ test_expect_success 'stdin -z delete refs works with 
packed and loose refs' '
test_must_fail git rev-parse --verify -q $c
 '
 
+run_with_limited_open_files () {
+   (ulimit -n 32 && "$@")
+}
+
+test_lazy_prereq ULIMIT_FILE_DESCRIPTORS 'run_with_limited_open_files true'
+
+test_expect_failure ULIMIT_FILE_DESCRIPTORS 'large transaction creating 
branches does not burst open file limit' '
+(
+   for i in $(test_seq 33)
+   do
+   echo "create refs/heads/$i HEAD"
+   done >large_input &&
+   run_with_limited_open_files git update-ref --stdin large_input &&
+   run_with_limited_open_files git update-ref --stdin http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/7] path.c: implement xdg_config_home()

[Stefan Beller]

On Tue, Apr 14, 2015 at 1:39 PM, Junio C Hamano  wrote:
> Johannes Schindelin  writes:
>
>>> diff --git a/cache.h b/cache.h
>>> index 3d3244b..7f9bab0 100644
>>> --- a/cache.h
>>> +++ b/cache.h
>>> @@ -836,6 +836,13 @@ char *strip_path_suffix(const char *path, const
>>> char *suffix);
>>>  int daemon_avoid_alias(const char *path);
>>>  extern int is_ntfs_dotgit(const char *name);
>>>
>>> +/**
>>> + * Returns the newly allocated string "$XDG_CONFIG_HOME/git/%s".  If
>>> + * $XDG_CONFIG_HOME is unset or empty, returns the newly allocated string
>>> + * "$HOME/.config/git/%s". Returns NULL if an error occurred.
>>> + */
>>> +extern char *xdg_config_home(const char *fn);
>>
>> Should this not be inserted close to home_config_paths()? Also, the
>> name "fn" sounds more like "function" than like "filename" to me,
>> especially keeping the name `config_fn_t` in mind. Maybe call the
>> parameter "filename" to avoid confusion?
>
> It is OK to omit the name in the extern declaration here.  We have
> to have a sensible variable name in the definition in path.c, of
> course ;-), and "filename" sounds like a very sensible suggestion.
>

It is OK, but I think this is bad practice.
Have a look at strbuf.h, there you'll find:

extern int strbuf_getwholeline_fd(struct strbuf *, int, int);

It's not clear what the 2 ints are, probably a fd and a max size?
Even if guessed correctly, you'd still need another guess for the order.
--
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: Feature Request: provide cmdline args to git hooks

[Chris O'Kelly]

Unfortunately in this case we don't have control over the hooks at the
receiving end - we want to prevent tags from being pushed by all users
to these repo's.

On Wed, Apr 15, 2015 at 1:08 AM, Junio C Hamano  wrote:
> "Chris O'Kelly"  writes:
>
>> A brief background of my use case:
>> I am wanting to write a pre-push hook to prevent tags being pushed to
>> our production servers. The production servers in our case are --bare
>> endpoints, and when we push a tag at them, they always checkout the
>> commit that tag is attached to via some post-receive magic (WPEngine,
>> FWIW). This behavior is even present when the tag was already pushed
>> to the repo previously, if for instance a normal push is made with the
>> --tags argument.
>
> Do you mean that you want to forbid some people from pushing tags
> into that repository while allowing others (i.e. those who manage
> production deployment)?  If that is the goal, it sounds like that
> the right place to do this is at the receiving end via pre-receive,
> not at the sending end via pre-push.
>
--
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/7] path.c: implement xdg_config_home()

[Junio C Hamano]

Stefan Beller  writes:

> On Tue, Apr 14, 2015 at 1:39 PM, Junio C Hamano  wrote:
>
>> It is OK to omit the name in the extern declaration here.
>
> It is OK, but I think this is bad practice.

Take a special note on the word "here", meaning "in this particular
case."  It is perfectly fine when the meaning of the parameter is
clear from its type.

I was assuming that our developers have common sense to disambiguate
ambiguous cases, of course ;-)
--
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/7] path.c: implement xdg_config_home()

[Stefan Beller]

I need to learn to read the whole sentence. :(
Apologies.

On Tue, Apr 14, 2015 at 3:30 PM, Junio C Hamano  wrote:
> Stefan Beller  writes:
>
>> On Tue, Apr 14, 2015 at 1:39 PM, Junio C Hamano  wrote:
>>
>>> It is OK to omit the name in the extern declaration here.
>>
>> It is OK, but I think this is bad practice.
>
> Take a special note on the word "here", meaning "in this particular
> case."  It is perfectly fine when the meaning of the parameter is
> clear from its type.
>
> I was assuming that our developers have common sense to disambiguate
> ambiguous cases, of course ;-)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] refs.c: remove lock_fd from struct ref_lock

[Junio C Hamano]

Stefan Beller  writes:

> The 'lock_fd' is the same as 'lk->fd'. No need to store it twice so remove
> it. You may argue this introduces more coupling as we need to know more
> about the internals of the lock file mechanism, but this will be solved in
> a later patch.
>
> No functional changes intended.

It is somewhat strange to hear "in a later patch" in [PATCH 3/3] of
a 3-patch series ;-), but I think this makes sense.  Whenever
we take a ref-lock, and we are going to actually write something
into the filesystem, we would go thru the lock_file API, so we can
depend on lk to have its own file descriptor field.




>
> Signed-off-by: Stefan Beller 
> Signed-off-by: Junio C Hamano 
> ---
>  refs.c | 16 ++--
>  1 file changed, 6 insertions(+), 10 deletions(-)
>
> diff --git a/refs.c b/refs.c
> index 14e52ca..4066752 100644
> --- a/refs.c
> +++ b/refs.c
> @@ -11,7 +11,6 @@ struct ref_lock {
>   char *orig_ref_name;
>   struct lock_file *lk;
>   unsigned char old_sha1[20];
> - int lock_fd;
>   int force_write;
>  };
>  
> @@ -2259,7 +2258,6 @@ static struct ref_lock *lock_ref_sha1_basic(const char 
> *refname,
>   int attempts_remaining = 3;
>  
>   lock = xcalloc(1, sizeof(struct ref_lock));
> - lock->lock_fd = -1;
>  
>   if (mustexist)
>   resolve_flags |= RESOLVE_REF_READING;
> @@ -2335,8 +2333,8 @@ static struct ref_lock *lock_ref_sha1_basic(const char 
> *refname,
>   goto error_return;
>   }
>  
> - lock->lock_fd = hold_lock_file_for_update(lock->lk, ref_file, lflags);
> - if (lock->lock_fd < 0) {
> + if (hold_lock_file_for_update(lock->lk, ref_file, lflags) < 0) {
> + last_errno = errno;
>   if (errno == ENOENT && --attempts_remaining > 0)
>   /*
>* Maybe somebody just deleted one of the
> @@ -2904,7 +2902,6 @@ static int close_ref(struct ref_lock *lock)
>  {
>   if (close_lock_file(lock->lk))
>   return -1;
> - lock->lock_fd = -1;
>   return 0;
>  }
>  
> @@ -2912,7 +2909,6 @@ static int commit_ref(struct ref_lock *lock)
>  {
>   if (commit_lock_file(lock->lk))
>   return -1;
> - lock->lock_fd = -1;
>   return 0;
>  }
>  
> @@ -3090,8 +3086,8 @@ static int write_ref_sha1(struct ref_lock *lock,
>   errno = EINVAL;
>   return -1;
>   }
> - if (write_in_full(lock->lock_fd, sha1_to_hex(sha1), 40) != 40 ||
> - write_in_full(lock->lock_fd, &term, 1) != 1 ||
> + if (write_in_full(lock->lk->fd, sha1_to_hex(sha1), 40) != 40 ||
> + write_in_full(lock->lk->fd, &term, 1) != 1 ||
>   close_ref(lock) < 0) {
>   int save_errno = errno;
>   error("Couldn't write %s", lock->lk->filename.buf);
> @@ -4047,9 +4043,9 @@ int reflog_expire(const char *refname, const unsigned 
> char *sha1,
>   status |= error("couldn't write %s: %s", log_file,
>   strerror(errno));
>   } else if ((flags & EXPIRE_REFLOGS_UPDATE_REF) &&
> - (write_in_full(lock->lock_fd,
> + (write_in_full(lock->lk->fd,
>   sha1_to_hex(cb.last_kept_sha1), 40) != 40 ||
> -  write_str_in_full(lock->lock_fd, "\n") != 1 ||
> +  write_str_in_full(lock->lk->fd, "\n") != 1 ||
>close_ref(lock) < 0)) {
>   status |= error("couldn't write %s",
>   lock->lk->filename.buf);
--
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: Feature Request: provide cmdline args to git hooks

[Junio C Hamano]

"Chris O'Kelly"  writes:

[administrivia: people read from top to bottom; please do not top
post]

> On Wed, Apr 15, 2015 at 1:08 AM, Junio C Hamano  wrote:
>> "Chris O'Kelly"  writes:
>>
>>> A brief background of my use case:
>>> I am wanting to write a pre-push hook to prevent tags being pushed to
>>> our production servers. The production servers in our case are --bare
>>> endpoints, and when we push a tag at them, they always checkout the
>>> commit that tag is attached to via some post-receive magic (WPEngine,
>>> FWIW). This behavior is even present when the tag was already pushed
>>> to the repo previously, if for instance a normal push is made with the
>>> --tags argument.
>>
>> Do you mean that you want to forbid some people from pushing tags
>> into that repository while allowing others (i.e. those who manage
>> production deployment)?  If that is the goal, it sounds like that
>> the right place to do this is at the receiving end via pre-receive,
>> not at the sending end via pre-push.
>>

> Unfortunately in this case we don't have control over the hooks at the
> receiving end - we want to prevent tags from being pushed by all users
> to these repo's.

Well, if you refuse to or are unable to use the mechanism that was
specifically designed to solve your problem, then there is no way we
can offer you a good solution.

Let's set the baseline of the discussion first.

We agree that any client-side mechanism (like the hook) is *not* a
good way to enforce policy or ensure security. It is merely a way to
avoid mistakes---prevent the users to avoid doing something they are
allowed to do (at the mechanical level) that is not desirable to the
project.  After all, the user's hook can be misconfigured (or
disabled) by mistake, or the user's workstation may have an older
version of Git that does not know about the hook, thereby bypassing
whategver you try to do on the client side.  The user can even say
"git push --no-verify".  That is why a true policy-enforcement and
security must be done on the receiving end.

So our conversation must start from the shared understanding that
you are seeking a client-side "convention" that helps users avoid
mistakes.  You do not have anything more than "convention" to force
certain behaviour on users.  Are we in agreement?

Now, if a "convention," is an acceptaible solution, you do not even
necessarily need a hook. You can give "git mypush" to the users,
tell them to use it instead of "git push" and do whatever check in
"git mypush" and you are done.  If your users can be told not to run
"git push" with --no-verify, they can certainly taught not to use
"git push" but to use "git mypush". Cf. 5 valid reasons to have hook
(http://thread.gmane.org/gmane.comp.version-control.git/71069).

The reason why we added pre-push is primarily because parsing the
command line is too brittle a way to guess what will be pushed.
When the user says "git push" and your "hook" sees "ah, there is no
argument", that does not mean the user did not try to push any
tags.  The user may have "remote.origin.push" refspec to always push
things without typing from the command line, for example.  The
approach to inspect the command line, whether it is done in "hook"
or "git mypush", is unworkable, and that is why pre-push is told
what "git push" decided to update on the remote end.

Having said all that, I am not sure if ec9f (push: Add support
for pre-push hooks, 2013-01-13) implemented the pre-push hook
correctly.

I do not offhand know (I am on a bus with terrible connection so I
won't bother checking the source now) if we send "this ref has to
point at that object" even for STATUS_UPTODATE cases, to cause your
remote to trigger the receive hook in the frist place, but if that
is the case, then the code in run_pre_push_hook() that omits such
refs from the hook input looks just *wrong*.  On the other hand, I
do not offhand think of a valid reason for the push codepath (with
or without the pre-push hook) to send "this ref has to point at that
object" when we know the ref is already pointing at that object, so
I am not sure if your claim (i.e. "when ... was already pushed
previously") is true for a correctly built receiving side of Git.

On the other side, if we are telling the other end "I know your
refs/tags/v1.0 is pointing at this object, but I am telling you to
point at it again anyway", then we should be feeding pre-push that,
too.  The code here in transport.c omits UPTODATE ones, and it may
need to be disabled to be consistent.

for (r = remote_refs; r; r = r->next) {
if (!r->peer_ref) continue;
if (r->status == REF_STATUS_REJECT_NONFASTFORWARD) continue;
if (r->status == REF_STATUS_REJECT_STALE) continue;
if (r->status == REF_STATUS_UPTODATE) continue;

strbuf_reset(&buf);
strbuf_addf( &buf, "%s %s %s %s\n",
 r->peer_ref->name, sha1_to_hex(r->new_sha1),

Re: Git + SFC Status Update

[Jeff King]

On Tue, Apr 14, 2015 at 12:30:23PM -0700, Junio C Hamano wrote:

> > If I recall correctly, Scott said onstage that some/all of the
> > conference proceeds would be going directly into this fund. So this
> > might need to be revised upward by 50-100% sometime soon :)
> 
> I think you misheard it.  The above is money earmarked for Git at
> SFC; the admission for GitMerge were going to SFC general fund
> without earmarked for us, IIUC.

Yeah, that's my understanding as well.

-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: Feature Request: provide cmdline args to git hooks

[Chris O'Kelly]

> I do not offhand know (I am on a bus with terrible connection so I
> won't bother checking the source now) if we send "this ref has to
> point at that object" even for STATUS_UPTODATE cases, to cause your
> remote to trigger the receive hook in the frist place, but if that
> is the case, then the code in run_pre_push_hook() that omits such
> refs from the hook input looks just *wrong*.  On the other hand, I
> do not offhand think of a valid reason for the push codepath (with
> or without the pre-push hook) to send "this ref has to point at that
> object" when we know the ref is already pointing at that object, so
> I am not sure if your claim (i.e. "when ... was already pushed
> previously") is true for a correctly built receiving side of Git.

No I totally understand that the pre-receive is the ideal place to do
it, and I can see that it's not feasible to rework how pre-push was
designed if it was specifically made not to handle this kind of
situation. In a perfect world I would just remove/modify the
post-receive hook causing the undesirable behavior, but I work within
the restrictions of my environment. To reiterate and clarify I'm not
saying the undesirable behavior is a built in part of git, just a
feature of our hosting platform's Git deployment mechanisms, although
if what you mean is that the post-receive hook on the receiving end
shouldn't be getting passed pushed tag refs that the local git
believed to be already up to date on the remote (as of most recent
fetch), then yeah... that is weird because it seems to be the behavior
in this case.

Anyway it sounds like the answer here is that it really isn't a
feasible task in a client side hook, and we should stick with the
current solution of "Don't use the GUI to push to Live" for now, which
is fine; I should probably stop trying to script around every single
problem anyway (https://xkcd.com/1319/).
--
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

Resort furniture

[lionhorest]

Resort furniture, we will provide a solution for your furniture resort.
please see and select resort furniture you need at http://www.horestco.com.
because we specialize in indoor and outdoor wood furniture, stainless steel
furniture, custom made furniture, teak furniture and wicker furniture
natural and synthetic weaving.




-
Resort furniture 

--
View this message in context: 
http://git.661346.n2.nabble.com/Resort-furniture-tp7628771.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: [PATCH v2 0/3] Improving performance of git clean

[Eric Sunshine]

On Sat, Apr 11, 2015 at 12:43 PM, Erik Elfström  wrote:
> v1 of the patch can be found here:
> http://thread.gmane.org/gmane.comp.version-control.git/266839/focus=266839
>
> changes in v2:
> * fixed commit message,
>   "p7300: added performance tests for clean"
>   change to:
>   "p7300: add performance tests for clean"
> * simplified test code
> * removed non portable ls -A in test
> * removed non portable $(seq ) in test
> * fixed missing " || return $?" in test
> * fixed missing sub shell for 'cd' command in test
> * fixed broken && chains in test
> * added assert new clean.c:is_git_repository to guard against
>   negative array index
> * use size_t instead of int for strbuf->len
>
> fixes held back for cleanup patches:
> * fixed existing broken && chains
> * added assert in existing code to guard against
>   negative array index
>
> Thanks to Eric Sunshine and Torsten Bögershausen for the very helpful
> review!

Thanks. This version looks much better.
--
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-p4: Use -m when running p4 changes

[Lex Spoon]

>From 9cc607667a20317c837afd90d50c078da659b72f Mon Sep 17 00:00:00 2001
From: Lex Spoon 
Date: Sat, 11 Apr 2015 10:01:15 -0400
Subject: [PATCH] git-p4: Use -m when running p4 changes

Signed-off-by: Lex Spoon 
---
Updated to include a test case

 git-p4.py   | 51 ++-
 t/t9818-git-p4-block.sh | 64 +
 2 files changed, 104 insertions(+), 11 deletions(-)
 create mode 100755 t/t9818-git-p4-block.sh

diff --git a/git-p4.py b/git-p4.py
index 549022e..2fc8d9c 100755
--- a/git-p4.py
+++ b/git-p4.py
@@ -740,17 +740,43 @@ def
createOrUpdateBranchesFromOrigin(localRefPrefix = "refs/remotes/p4/",
silent
 def originP4BranchesExist():
 return gitBranchExists("origin") or
gitBranchExists("origin/p4") or gitBranchExists("origin/p4/master")

-def p4ChangesForPaths(depotPaths, changeRange):
+def p4ChangesForPaths(depotPaths, changeRange, block_size):
 assert depotPaths
-cmd = ['changes']
-for p in depotPaths:
-cmd += ["%s...%s" % (p, changeRange)]
-output = p4_read_pipe_lines(cmd)
+assert block_size
+
+# Parse the change range into start and end
+if changeRange is None or changeRange == '':
+changeStart = '@1'
+changeEnd = '#head'
+else:
+parts = changeRange.split(',')
+assert len(parts) == 2
+changeStart = parts[0]
+changeEnd = parts[1]

+# Accumulate change numbers in a dictionary to avoid duplicates
 changes = {}
-for line in output:
-changeNum = int(line.split(" ")[1])
-changes[changeNum] = True
+
+for p in depotPaths:
+# Retrieve changes a block at a time, to prevent running
+# into a MaxScanRows error from the server.
+start = changeStart
+end = changeEnd
+get_another_block = True
+while get_another_block:
+new_changes = []
+cmd = ['changes']
+cmd += ['-m', str(block_size)]
+cmd += ["%s...%s,%s" % (p, start, end)]
+for line in p4_read_pipe_lines(cmd):
+changeNum = int(line.split(" ")[1])
+new_changes.append(changeNum)
+changes[changeNum] = True
+if len(new_changes) == block_size:
+get_another_block = True
+end = '@' + str(min(new_changes))
+else:
+get_another_block = False

 changelist = changes.keys()
 changelist.sort()
@@ -1912,6 +1938,8 @@ class P4Sync(Command, P4UserMap):
 optparse.make_option("--import-local",
dest="importIntoRemotes", action="store_false",
  help="Import into refs/heads/ ,
not refs/remotes"),
 optparse.make_option("--max-changes", dest="maxChanges"),
+optparse.make_option("--changes-block-size",
dest="changes_block_size", type="int",
+ help="Block size for calling p4 changes"),
 optparse.make_option("--keep-path",
dest="keepRepoPath", action='store_true',
  help="Keep entire
BRANCH/DIR/SUBDIR prefix during import"),
 optparse.make_option("--use-client-spec",
dest="useClientSpec", action='store_true',
@@ -1940,6 +1968,7 @@ class P4Sync(Command, P4UserMap):
 self.syncWithOrigin = True
 self.importIntoRemotes = True
 self.maxChanges = ""
+self.changes_block_size = 500
 self.keepRepoPath = False
 self.depotPaths = None
 self.p4BranchesInGit = []
@@ -2578,7 +2607,7 @@ class P4Sync(Command, P4UserMap):

 return ""

-def importNewBranch(self, branch, maxChange):
+def importNewBranch(self, branch, maxChange, changes_block_size):
 # make fast-import flush all changes to disk and update the
refs using the checkpoint
 # command so that we can try to find the branch parent in the
git history
 self.gitStream.write("checkpoint\n\n");
@@ -2586,7 +2615,7 @@ class P4Sync(Command, P4UserMap):
 branchPrefix = self.depotPaths[0] + branch + "/"
 range = "@1,%s" % maxChange
 #print "prefix" + branchPrefix
-changes = p4ChangesForPaths([branchPrefix], range)
+changes = p4ChangesForPaths([branchPrefix], range, changes_block_size)
 if len(changes) <= 0:
 return False
 firstChange = changes[0]
@@ -3002,7 +3031,7 @@ class P4Sync(Command, P4UserMap):
 if self.verbose:
 print "Getting p4 changes for %s...%s" % (',
'.join(self.depotPaths),
   self.changeRange)
-changes = p4ChangesForPaths(self.depotPaths, self.changeRange)
+changes = p4ChangesForPaths(self.depotPaths,
self.changeRange, self.changes_block_size)

 if len(self.maxChanges) > 0:
 changes = changes[:min(int(s

Odd broken "--date=now" behavior in current git

[Linus Torvalds]

I just noticed this because I had amended some merge commits with

   git commit --amend --date=now

to update them, and that gets some funny broken timezones. I suspect
it's some silly daylight savings time issue.

Lookie here, I can reproduce it trivially with current git (in the git
repo itself):

[torvalds@i7 git]$ date; git commit -m Test --allow-empty --date=now
Tue Apr 14 21:11:03 PDT 2015
[master ec7733db5360] Test
 Date: Tue Apr 14 20:11:03 2015 -0800

notice how the commit date message shows something funny. It shows an
hour earlier, but in -0800.

And the resulting commit is broken:

[torvalds@i7 git]$ git show --pretty=fuller
commit ec7733db5360966434e03eab1a849e6d4227231c (HEAD -> master)
Author: Linus Torvalds 
AuthorDate: Tue Apr 14 20:11:03 2015 -0800
Commit: Linus Torvalds 
CommitDate: Tue Apr 14 21:11:03 2015 -0700

Test

notice how the AuthorDate has that "-0800", but the CommitDate has "-0700".

Hmm.

I can't be the only one seeing this? My guess is that there's a
missing initialization of tm.tm_isdst somewhere or whatever.

The above is with current git:

[torvalds@i7 git]$ git version
git version 2.4.0.rc2

Anybody?

Linus
--
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: Odd broken "--date=now" behavior in current git

[Junio C Hamano]

Linus Torvalds  writes:

> I just noticed this because I had amended some merge commits with
>
>git commit --amend --date=now
>
> to update them, and that gets some funny broken timezones. I suspect
> it's some silly daylight savings time issue.
>
> Lookie here, I can reproduce it trivially with current git (in the git
> repo itself):
>
> [torvalds@i7 git]$ date; git commit -m Test --allow-empty --date=now
> Tue Apr 14 21:11:03 PDT 2015
> [master ec7733db5360] Test
>  Date: Tue Apr 14 20:11:03 2015 -0800
>
> notice how the commit date message shows something funny. It shows an
> hour earlier, but in -0800.
>
> And the resulting commit is broken:
>
> [torvalds@i7 git]$ git show --pretty=fuller
> commit ec7733db5360966434e03eab1a849e6d4227231c (HEAD -> master)
> Author: Linus Torvalds 
> AuthorDate: Tue Apr 14 20:11:03 2015 -0800
> Commit: Linus Torvalds 
> CommitDate: Tue Apr 14 21:11:03 2015 -0700
>
> Test
>
> notice how the AuthorDate has that "-0800", but the CommitDate has "-0700".
>
> Hmm.
>
> I can't be the only one seeing this? My guess is that there's a
> missing initialization of tm.tm_isdst somewhere or whatever.
>
> The above is with current git:
>
> [torvalds@i7 git]$ git version
> git version 2.4.0.rc2

With a quick check, the symptom exists at least at v2.1.4.  v2.0.x
series does not seem to have --date=now support but since there is
no change to date.c between v2.0.0 to v2.1.4, older approxidate may
be equally broken.

Will dig tomorrow, if nobody beats me to it, that is.

Thanks.

--
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 Rev News edition 2 published

[Christian Couder]

Hi,

Git Rev News edition 2 is now available:

https://git.github.io/rev_news/2015/04/05/edition-2/

Thanks a lot to all the helpers!

Enjoy,
Christian, Thomas and Nicola.
--
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