Re: [PATCH v3 4/5] t4202-log: add tests for --merges=
On Mon, Apr 13, 2015 at 11:29 AM, Koosha Khajehmoogahi koo...@posteo.de wrote:
From: Eric Sunshine sunsh...@sunshineco.com
Signed-off-by: Koosha Khajehmoogahi koo...@posteo.de
Signed-off-by: Eric Sunshine sunsh...@sunshineco.com
---
diff --git a/t/t4202-log.sh b/t/t4202-log.sh
index 1b2e981..3edcd81 100755
--- a/t/t4202-log.sh
+++ b/t/t4202-log.sh
@@ -270,6 +270,35 @@ cat expect \EOF
* initial
EOF
+test_expect_success 'setup merges=' '
This differs slightly from the version I posted[1], in which I had
intentionally dropped the '=' from merges= in the description to
normalize the output. (I think it looks slightly nicer without the
'='.)
[1]: http://article.gmane.org/gmane.comp.version-control.git/266902/
+ git log --min-parents=2 --pretty=tformat:%s expect_only
+ git log --max-parents=1 --pretty=tformat:%s expect_hide
+ git log --min-parents=-1 --pretty=tformat:%s expect_show
+'
+
+test_log_merges() {
+ expect=expect_$1
+ config=${2:+-c log.merges=$2}
+ option=${3:+--merges=$3}
+ option=${4:-$option}
+ test_expect_success merges${config:+ $config}${option:+ $option}
+ git $config log $option --pretty=tformat:%s actual
+ test_cmp $expect actual
+
+}
+
+states=show only hide
+for c in '' $states
+do
+ for o in '' $states
+ do
+ test_log_merges ${o:-${c:-show}} $c $o
+ done
+done
+
+test_log_merges hide show '' --no-merges
+test_log_merges only hide '' '--merges --max-parents=2'
+
test_expect_success 'log --graph with merge' '
git log --graph --date-order --pretty=tformat:%s |
sed s/ *\$// actual
--
2.3.3.263.g095251d.dirty
--
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
git fsck: unreachable vs. dangling
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
Please let me know if you need to print color box, display box and labels
Hi, this is David Wu from Shanghai, China. Please let me know if you need color box, display box, corrugated box, label, hang tag etc. I will send you the website. Best regards, David Wu -- 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 venit, vidit, dixit 14.04.2015 10:05: On Tue, Apr 14, 2015 at 12:16 AM, Sebastian Schuberth sschube...@gmail.com 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
On Tue, Apr 14, 2015 at 10:50 AM, Michael J Gruber g...@drmicha.warpmail.net 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 add -p “Your edited hunk does not apply. Edit again”
Tanky Woo wtq1...@gmail.com 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
Re: git fsck: unreachable vs. dangling
On Tue, Apr 14, 2015 at 11:22 AM, Junio C Hamano gits...@pobox.com 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 fsck: unreachable vs. dangling
On Tue, Apr 14, 2015 at 10:05 AM, Junio C Hamano gits...@pobox.com 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 sschube...@gmail.com writes:
On Tue, Apr 14, 2015 at 10:50 AM, Michael J Gruber
g...@drmicha.warpmail.net 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
On Tue, Apr 14, 2015 at 12:16 AM, Sebastian Schuberth sschube...@gmail.com 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
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: gitk won't show notes?
On Sat, Apr 11, 2015 at 12:31 PM, Paul Mackerras pau...@samba.org 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: [PATCH] reduce progress updates in background
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
[PATCH 4/4] stash -p: demonstrate failure of split with mixed y/n
Signed-off-by: Matthieu Moy matthieu@imag.fr --- 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 2error + ! 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
The test passes if one replaces the 'e' command with a 'y' command in the 'add -p' session. Reported-by: Tanky Woo wtq1...@gmail.com Signed-off-by: Matthieu Moy matthieu@imag.fr --- 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 2error + 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
[PATCH 2/4] t3904-stash-patch: fix test description
The old description is rather clearly a wrong cut-and-paste from t2016-checkout-patch.sh. Signed-off-by: Matthieu Moy matthieu@imag.fr --- 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
MDaemon Notification -- Attachment Removed
--- 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
[PATCH v2] reduce progress updates in background
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 l...@mewburn.net
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 l...@mewburn.net
---
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] git-p4: Use -m when running p4 changes
On 11 April 2015 at 16:17, Lex Spoon l...@lexspoon.org wrote:
Signed-off-by: Lex Spoon l...@lexspoon.org
---
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
Re: When and how to to contact the Git developers (gist)
On Mon, Apr 13, 2015 at 11:10 PM, Jonathan Nieder jrnie...@gmail.com 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 http://vger.kernel.org/majordomo-info.html. 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
Re: How to combine git repos with similar code and keep all branches and tags?
Matthieu Moy matthieu@grenoble-inp.fr writes: Jose de Leon jdel...@ensim.com 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
RE: How to combine git repos with similar code and keep all branches and tags?
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 jdel...@ensim.com 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 http://cp.mcafee.com/d/1jWVIq6hEi6jqb2pEVKOyUqenztPqqdNPaabzz1Jd6UVB54sepdFET7cEEKefCQQrzCkknxPVIhgY_WM1nMF9nBPvMF9nBPqa91x1dZ_HYCCMOeWZOWr8W_c3AnXYJteOaqJT6ul3PWApmU6CQjqpK_nd7bwUsMyqemnPtPpesRG9px6k-ciaOUHYouvM070bU8U4EWXcblB2pJngY52PvMgBO7CS1Ob1I5-Aq80LkMq89Rd42V2kfd416kPh17RGQd41ykOpEwF9mh-Nd45GEuq8dwwq82L-Iq8dffd412eMIj-xEwS21EwDF6x8SeudOB_GPPAJ5zzZ 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 http://cp.mcafee.com/d/2DRPowcCQm4PhPtB5MQsL6XCQQrzCkkn763qqdNPaa8UsOrjhKephhssvdFET7cEEL3DPoyxV_Rw2LxiiLbC_xiiLbCQki322rX_nVddxAtRXBQShR-o78LTVqWtAkRrKcYG7DR8OJMddFCQPt-Kqen1MVx4QsILCXCM0p6kOZbaYLy5rkMzaptShY_yn8hS5ypJngY52PvMgBO7CS1Ob1I5-Aq80LkMq89Rd42V2kfd416kPh17RGQd41ykOpEwF9mh-Nd45GEuq8dwwq82L-Iq8dffd412eMIj-xEwS21EwDF6x8SeudXyyH 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?
Hi Jose, On 14.04.2015, at 18:44, Jose de Leon jdel...@ensim.com 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 https://git.wiki.kernel.org/index.php/GraftPoint 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 http://git-scm.com/docs/git-filter-branch 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
[PATCH v2 1/7] path.c: implement xdg_config_home()
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 pyoka...@gmail.com
---
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
the body of a message to majord...@vger.kernel.org
More
Ensimag students project on Git, 2015 edition
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?
Jose de Leon jdel...@ensim.com 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: [PATCH 0/4] demonstrate add -p and stash -p failures.
Matthieu Moy matthieu@imag.fr 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
Re: git commit --date format
乙酸鋰 ch3co...@gmail.com 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
Matthew Rothenberg mr...@khanacademy.org 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 cmd does this before running git-cmd (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
Error staging submodule removal when empty directory present
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 fsck: unreachable vs. dangling
On Tue, Apr 14, 2015 at 10:52 AM, Sebastian Schuberth sschube...@gmail.com 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
PATH modifications for git-hook processes
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
Junio C Hamano venit, vidit, dixit 14.04.2015 11:22:
Sebastian Schuberth sschube...@gmail.com writes:
On Tue, Apr 14, 2015 at 10:50 AM, Michael J Gruber
g...@drmicha.warpmail.net 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: Feature Request: provide cmdline args to git hooks
Chris O'Kelly ch...@mapcreative.com.au 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
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 n...@fluxnic.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
Re: Feature Request: provide cmdline args to git hooks
Chris O'Kelly ch...@mapcreative.com.au 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 gits...@pobox.com wrote:
Chris O'Kelly ch...@mapcreative.com.au 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),
r-name,
Re: Git + SFC Status Update
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
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
Re: [PATCH v2 0/3] Improving performance of git clean
On Sat, Apr 11, 2015 at 12:43 PM, Erik Elfström erik.elfst...@gmail.com 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
Resort furniture
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] git-p4: Use -m when running p4 changes
From 9cc607667a20317c837afd90d50c078da659b72f Mon Sep 17 00:00:00 2001
From: Lex Spoon l...@lexspoon.org
Date: Sat, 11 Apr 2015 10:01:15 -0400
Subject: [PATCH] git-p4: Use -m when running p4 changes
Signed-off-by: Lex Spoon l...@lexspoon.org
---
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(self.maxChanges),
Re: Odd broken --date=now behavior in current git
Linus Torvalds torva...@linux-foundation.org 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 torva...@linux-foundation.org AuthorDate: Tue Apr 14 20:11:03 2015 -0800 Commit: Linus Torvalds torva...@linux-foundation.org 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
Odd broken --date=now behavior in current git
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 torva...@linux-foundation.org AuthorDate: Tue Apr 14 20:11:03 2015 -0800 Commit: Linus Torvalds torva...@linux-foundation.org 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: Git add -p “Your edited hunk does not apply. Edit again”
Tanky Woo wtq1...@gmail.com 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
What's cooking in git.git (Apr 2015, #02; Tue, 14)
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 filetype detection on files
[ANNOUNCE] Git v2.4.0-rc2
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=string 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 commit object name. - When the HEAD has moved since it was originally detached, they now both show detached from commit object name. 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 configuration turns the --follow-tags
Re: Git + SFC Status Update
On Mon, Apr 13, 2015 at 7:56 AM, Jeff King p...@peff.net 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
Dave Borowitz dborow...@google.com writes: On Mon, Apr 13, 2015 at 7:56 AM, Jeff King p...@peff.net 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
(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()
Johannes Schindelin johannes.schinde...@gmx.de 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
On Tue, Apr 14, 2015 at 7:32 AM, Matthieu Moy matthieu@imag.fr wrote: Signed-off-by: Matthieu Moy matthieu@imag.fr --- 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 2error + ! 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
On Tue, Apr 14, 2015 at 7:32 AM, Matthieu Moy matthieu@imag.fr wrote: The test passes if one replaces the 'e' command with a 'y' command in the 'add -p' session. Reported-by: Tanky Woo wtq1...@gmail.com Signed-off-by: Matthieu Moy matthieu@imag.fr --- 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 2error + 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
[PATCH 2/3] t7004: rename ULIMIT test prerequisite to ULIMIT_STACK_SIZE
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 sbel...@google.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
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
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
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 sbel...@google.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
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
Signed-off-by: Stefan Beller sbel...@google.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
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
+ git rev-parse --verify -q refs/heads/33
+)
+'
+
+test_expect_failure ULIMIT_FILE_DESCRIPTORS 'large transaction deleting
branches does not burst open file limit' '
+(
+ for i in $(test_seq 33)
+ do
+ echo delete refs/heads/$i HEAD
+ done large_input
+ run_with_limited_open_files git update-ref --stdin large_input
+ test_must_fail git rev-parse --verify -q refs/heads/33
+)
+'
+
test_done
--
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
Re: Feature Request: provide cmdline args to git hooks
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 gits...@pobox.com wrote: Chris O'Kelly ch...@mapcreative.com.au 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()
On Tue, Apr 14, 2015 at 1:39 PM, Junio C Hamano gits...@pobox.com wrote: Johannes Schindelin johannes.schinde...@gmx.de 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: [PATCH 1/7] path.c: implement xdg_config_home()
Stefan Beller sbel...@google.com writes: On Tue, Apr 14, 2015 at 1:39 PM, Junio C Hamano gits...@pobox.com 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()
I need to learn to read the whole sentence. :( Apologies. On Tue, Apr 14, 2015 at 3:30 PM, Junio C Hamano gits...@pobox.com wrote: Stefan Beller sbel...@google.com writes: On Tue, Apr 14, 2015 at 1:39 PM, Junio C Hamano gits...@pobox.com 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: gitk won't show notes?
On Tue, Apr 14, 2015 at 2:17 PM, Christian Couder christian.cou...@gmail.com wrote: On Sat, Apr 11, 2015 at 12:31 PM, Paul Mackerras pau...@samba.org 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, jo...@herland.net 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
Re: [PATCH 3/3] refs.c: remove lock_fd from struct ref_lock
Stefan Beller sbel...@google.com 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 sbel...@google.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
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
