On Fri, Jun 5, 2015 at 7:56 AM, Gondek, Andreas
andreas.gon...@dwpbank.de wrote:
Thanks, thanks, thanks.
One last question. If I don't want to compile Git myself, how long may the pu
branch take approx. to get into a next release?
According to:
On Fri, Jun 05, 2015 at 01:41:21AM +, brian m. carlson wrote:
However, with the object_id conversion, we run into a problem: casting
those unsigned char * values into struct object_id * values is not
allowed by the C standard. There are two possible solutions: copying;
and the just-do-it
On Fri, Jun 5, 2015 at 1:26 AM, Junio C Hamano gits...@pobox.com wrote:
Paul Tan pyoka...@gmail.com writes:
git-am generally supports applying patches to unborn branches.
However, there are 2 cases where git-am does not handle unborn
branches which I would like to address before the git-am
Dear Philip and Christian,
Here my answers:
1) We have a repository that we got from another person in another
city.We use the same CENTOS_6 . We put the repository on Windows
machine, on which we can access remotely and mounted the directory on
CENTOS_6, that we use by the WMVare Player
On Fri, Jun 5, 2015 at 1:27 AM, Stefan Beller sbel...@google.com wrote:
On Thu, Jun 4, 2015 at 3:34 AM, Paul Tan pyoka...@gmail.com wrote:
Or, the current behavior of git-am.sh will print some scary errors
about the missing HEAD, but will then continue on to the next patch.
If the index is not
On Fri, Jun 5, 2015 at 10:07 AM, Christian Couder
christian.cou...@gmail.com wrote:
On Fri, Jun 5, 2015 at 7:56 AM, Gondek, Andreas
andreas.gon...@dwpbank.de wrote:
Thanks, thanks, thanks.
One last question. If I don't want to compile Git myself, how long may the
pu branch take approx. to
The last argument of reencode_string_len() is an 'int *' which is
assigned the length of the converted string. When NO_ICONV is defined,
however, reencode_string_len() is stubbed out by the macro:
#define reencode_string_len(a,b,c,d,e) NULL
which never assigns a value to the final argument.
Torsten Bögershausen tboegi at web.de writes:
Do you think you can write a patch to improve the documentation ?
Here is my attempt, but it is only a starting point.
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index d263a56..ee25354 100644
---
On Fri, Jun 05, 2015 at 02:42:16AM -0400, Eric Sunshine wrote:
The last argument of reencode_string_len() is an 'int *' which is
assigned the length of the converted string. When NO_ICONV is defined,
however, reencode_string_len() is stubbed out by the macro:
#define
On Fri, Jun 5, 2015 at 4:45 PM, Jeff King p...@peff.net wrote:
On Fri, Jun 05, 2015 at 01:41:21AM +, brian m. carlson wrote:
However, with the object_id conversion, we run into a problem: casting
those unsigned char * values into struct object_id * values is not
allowed by the C standard.
On Tue, May 19, 2015 at 03:29:23PM +0200, Johannes Schindelin wrote:
On 2015-05-18 20:55, Jeff King wrote:
As a side note, I've also considered better support for running the
debugger on git commands inside a test (right now, I usually stick a
gdb --args in the pipeline, but you have to
Ping.
--
Sincerely,
Johannes Löthberg
(Sent from my
phone.)N�r��yb�X��ǧv�^�){.n�+ا���ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z� �w���?��)ߢf
On Fri, Jun 5, 2015 at 4:32 PM, Ed Avis e...@waniasset.com wrote:
Torsten Bögershausen tboegi at web.de writes:
Do you think you can write a patch to improve the documentation ?
Here is my attempt, but it is only a starting point.
diff --git a/Documentation/git-checkout.txt
On Sunday, May 24, 2015 @ 10:01 AM Duy Nguyen [mailto:pclo...@gmail.com] did
scribble:
In case you want to back away from option 2 because it starts to leak
raciness, which your old commit tried to fix in the first place. I
think the only other place that tests for lots of non-existent loose
On Fri, Jun 05, 2015 at 12:01:16PM +, steve.nor...@thomsonreuters.com wrote:
On Sunday, May 24, 2015 @ 10:01 AM Duy Nguyen [mailto:pclo...@gmail.com] did
scribble:
In case you want to back away from option 2 because it starts to leak
raciness, which your old commit tried to fix in
On Fri, Jun 05, 2015 at 05:14:25PM +0700, Duy Nguyen wrote:
I'm more concerned about breaking object_id abstraction than C
standard. Let's think a bit about future. I suppose we need to support
both sha-1 and sha-512, at least at the source code level.
I think that's going to be a much bigger
On 05/06, Michael J Gruber wrote:
It appears your patch proposes to fix a problem. It's a good idea to
expose the problem by writing a test so that one can check that the fix
actually fixes the problem.
Right, will look into writing a test for it.
(Also, your patch duplicates the line struct
On Fri, Jun 05, 2015 at 08:18:17AM -0400, Jeff King wrote:
1. Devise some torture to tests to see whether my patch series is in
fact racy on Linux.
2. Assuming it is, scrap it and make a has_sha1_file_quick() which
might sometimes return a false negative (if somebody else is
Johannes Löthberg venit, vidit, dixit 05.06.2015 13:53:
Ping.
--
Sincerely,
Johannes Löthberg
(Sent from my phone.)
It appears your patch proposes to fix a problem. It's a good idea to
expose the problem by writing a test so that one can check that the fix
actually fixes the problem.
On Fri, Jun 5, 2015 at 5:36 PM, Jeff King p...@peff.net wrote:
On Fri, Jun 05, 2015 at 05:14:25PM +0700, Duy Nguyen wrote:
I'm more concerned about breaking object_id abstraction than C
standard. Let's think a bit about future. I suppose we need to support
both sha-1 and sha-512, at least at
Hi Junio,
On Fri, Jun 5, 2015 at 2:39 AM, Junio C Hamano gits...@pobox.com wrote:
Tay Ray Chuan rcta...@gmail.com writes:
When running git-commit`, --verbose appends a diff to the prepared
message, while --no-status omits git-status output.
The --verbose option is called --verbose and
Test that the master ref is set up properly when cloning from a ref
namespace
Signed-off-by: Johannes Löthberg johan...@kyriasis.com
---
t/t9904-clone-from-ref-namespace.sh | 33 +
1 file changed, 33 insertions(+)
create mode 100755
Each ref namespace have their own separate branches, tags, and HEAD, so
when pushing to a namespace we need to make sure that there exists a
HEAD ref for the namespace, otherwise you will not be able to check out
the repo after cloning from a namespace
Signed-off-by: Johannes Löthberg
Since v1:
* Added a test case
Johannes Löthberg (2):
receive-pack: Create a HEAD ref for ref namespace
t: Add test for cloning from ref namespace
builtin/receive-pack.c | 12 +++-
t/t9904-clone-from-ref-namespace.sh | 33 +
2 files
On 05/06, Michael J Gruber wrote:
(Also, your patch duplicates the line struct strbuf namespaced_head_buf
= STRBUF_INIT;)
I replied too soon, it doesn't duplicate it, it's a different variable
named similarly.
--
Sincerely,
Johannes Löthberg
PGP Key ID: 0x50FB9B273A9D0BB5
On Friday, June 05, 2015 @ 1:18 PM Jeff King [mailto:p...@peff.net] did
scribble:
Sorry, I haven't had a chance to look at it further. It still on my todo
list. My plan is:
1. Devise some torture to tests to see whether my patch series is in
fact racy on Linux.
2. Assuming it
On 05/06, Johannes Löthberg wrote:
On 05/06, Junio C Hamano wrote:
Johannes Löthberg johan...@kyriasis.com writes:
git -C ../bare symbolic-ref HEAD actual
echo refs/heads/master expect
test_cmp expect actual
git -C ../bare
Christian Stimming stimm...@tuhh.de wrote:
Am Montag, 1. Juni 2015, 09:38:37 schrieb g...@drmicha.warpmail.net:
Ralf Thielow venit, vidit, dixit 29.05.2015 20:54:
The term index is translated as Staging-Area to
not confuse beginners who don't know about Git's index.
Since the term
Signed-off-by: Ralf Thielow ralf.thie...@gmail.com
---
po/de.po | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/po/de.po b/po/de.po
index 7d603c2..945bd13 100644
--- a/po/de.po
+++ b/po/de.po
@@ -5679,11 +5679,11 @@ msgstr Hauptwurzeln melden
#: builtin/fsck.c:613
Eric Sunshine sunsh...@sunshineco.com writes:
...
Again:
...`hello.c` will also be restored,...
because the file globbing is used to match entries in the index
(not in the working tree by the shell).
Thanks for a thorough review. I agree with all the comments and
suggestions you
I'm not attached to the wording changes posted earlier. As I said, it is
only a starting point.
I do feel that 'git checkout PATH' is rather a dangerous operation, and
moreover a surprisingly dangerous one, since 'git checkout BRANCH' is
careful not to lose local changes, as are other common
On Fri, Jun 5, 2015 at 5:32 AM, Ed Avis e...@waniasset.com wrote:
Torsten Bögershausen tboegi at web.de writes:
Do you think you can write a patch to improve the documentation ?
Here is my attempt, but it is only a starting point.
diff --git a/Documentation/git-checkout.txt
On Fri, Jun 5, 2015 at 1:44 PM, Eric Sunshine sunsh...@sunshineco.com wrote:
On Fri, Jun 5, 2015 at 5:32 AM, Ed Avis e...@waniasset.com wrote:
Torsten Bögershausen tboegi at web.de writes:
Do you think you can write a patch to improve the documentation ?
Here is my attempt, but it is only a
Acked-by: Phillip Sz phillip.sze...@gmail.com
Signed-off-by: Ralf Thielow ralf.thie...@gmail.com
---
po/de.po | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/po/de.po b/po/de.po
index 7d603c2..945bd13 100644
--- a/po/de.po
+++ b/po/de.po
@@ -5679,11 +5679,11 @@
Each ref namespace have their own separate branches, tags, and HEAD, so
when pushing to a namespace we need to make sure that there exists a
HEAD ref for the namespace, otherwise you will not be able to check out
the repo after cloning from a namespace
Signed-off-by: Johannes Löthberg
On 05/06, Junio C Hamano wrote:
Johannes Löthberg johan...@kyriasis.com writes:
+
+ echo ref: refs/namespaces/new_namespace/refs/heads/master expect
+ test_cmp expect ../bare/refs/namespaces/new_namespace/HEAD
Use symbolic-ref
The term index is translated as Staging-Area to
not confuse beginners who don't know about Git's index.
Since the term staging area doesn't appear in original
Git messages (not even in the glossary) and index is a
well known term for experienced users, we should treat
index as a Git term and
I find that If I am doing a rebase with the intention to squash or
re-order commits, it is helpful to know the commit author.
However, the alteration that I have made to git-rebase--interactive
may not be entirely correct. Here is the change:
---
diff --git a/git-rebase--interactive.sh
Tay Ray Chuan rcta...@gmail.com writes:
Would it be a good idea to have a --diff-only option to include diff,
but not status output? Or perhaps a --diff option, while leaving it to
the user to specify if status output is to be included with
--no-status, which would open the doors for mixing
Johannes Löthberg johan...@kyriasis.com writes:
Would it be acceptable to check against
../bare/refs/namespaces/new_namespace/HEAD and
../bare/refs/namespaces/new_namespace/refs/heads/master instead, until
rev-parse is thaught about namespaces?
Yes.
Because I do not immediately see any
On Fri, Jun 5, 2015 at 11:36 PM, Junio C Hamano gits...@pobox.com wrote:
Paul Tan pyoka...@gmail.com writes:
Hmm, actually git-am.sh doesn't seem to do that even when we have a
history to apply patches to. This is okay in the non-3way case, as
git-apply will check to see if the patch applies
Duy Nguyen pclo...@gmail.com writes:
I'm more concerned about breaking object_id abstraction than C
standard. Let's think a bit about future. I suppose we need to support
both sha-1 and sha-512, at least at the source code level. That might
make casting tricky.
If we support both, the code
On Fri, Jun 5, 2015 at 8:54 AM, Rossella Barletta
rossella.barle...@gmail.com wrote:
[...]
FIST ONE (PERMISSION PROBLEMS)
- Repo is on windows
- Repo folder is shared
-Repo is a copy of another repository being on a machine in another
city on which we cannot access. We got all the files,
Signed-off-by: Louis Stuber stub...@ensimag.grenoble-inp.fr
Signed-off-by: Antoine Delaite antoine.dela...@ensimag.grenoble-inp.fr
---
git-bisect.sh |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/git-bisect.sh b/git-bisect.sh
index 109bd65..d3d19cb 100644
---
David Deutsch dd212303 at gmail.com writes:
When I checkout a particular commit in my repo and immediately do a
git status, there is a file that show up as changed. If I look at the
SHAs for my working copy and the copy in the index/repo, they are
indeed different. The working copy has
Paul Tan pyoka...@gmail.com writes:
Hmm, thinking about it, the equivalent C code would be greatly
affected by whatever behavior we go with, so I think we should try
fixing the behavior first.
I am glad to see that sometimes people see the light when I say
one of the greatest strength in
Johannes Löthberg johan...@kyriasis.com writes:
diff --git a/t/t5509-fetch-push-namespaces.sh
b/t/t5509-fetch-push-namespaces.sh
index cc0b31f..7bc3a1f 100755
--- a/t/t5509-fetch-push-namespaces.sh
+++ b/t/t5509-fetch-push-namespaces.sh
@@ -1,6 +1,7 @@
#!/bin/sh
Gondek, Andreas andreas.gon...@dwpbank.de writes:
One last question. If I don't want to compile Git myself, how long may
the pu branch take approx. to get into a next release?
There is no general estimate; not all topics necessarily graduate to
the released version.
I'd leave it on the list
Paul Tan pyoka...@gmail.com writes:
Hmm, actually git-am.sh doesn't seem to do that even when we have a
history to apply patches to. This is okay in the non-3way case, as
git-apply will check to see if the patch applies before it modifies
the index, but if we fall back on 3-way merge, any new
On 05/06, Junio C Hamano wrote:
Johannes Löthberg johan...@kyriasis.com writes:
+
It seems that 5509 already has a few tests for namespaced transfer
in both directions. Perhaps this new test would fit there better?
Missed that, will move it there.
Also I
Johannes Löthberg johan...@kyriasis.com writes:
Hmm, it seems that git-rev-parse doesn't handle GIT_NAMESPACE yet, so
can't check it for the namespaced push right now. Not sure if I can
fix that myself though.
I do not see a need for rev-parse to pay attention to GIT_NAMESPACE
at all, though.
On 05/06, Junio C Hamano wrote:
Johannes Löthberg johan...@kyriasis.com writes:
Hmm, it seems that git-rev-parse doesn't handle GIT_NAMESPACE yet, so
can't check it for the namespaced push right now. Not sure if I can
fix that myself though.
I do not see a need for rev-parse to pay attention
On Sat, Jun 6, 2015 at 12:03 AM, Junio C Hamano gits...@pobox.com wrote:
Tay Ray Chuan rcta...@gmail.com writes:
Would it be a good idea to have a --diff-only option to include diff,
but not status output? Or perhaps a --diff option, while leaving it to
the user to specify if status output is
Guillaume Pages guillaume.pa...@ensimag.grenoble-inp.fr writes:
I felt that was not the right way to do so. What do you think of a
function like that:
/*
* Puts nb_commands commands from filename in lines,
* returns the total number of commands in the file
* ignores comments and empty
Johannes Löthberg johan...@kyriasis.com writes:
Test that the master ref is set up properly when cloning from a ref
namespace
Signed-off-by: Johannes Löthberg johan...@kyriasis.com
---
t/t9904-clone-from-ref-namespace.sh | 33 +
It seems that 5509 already
Signed-off-by: Louis Stuber stub...@ensimag.grenoble-inp.fr
Signed-off-by: Antoine Delaite antoine.dela...@ensimag.grenoble-inp.fr
---
revision.c | 15 +--
1 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/revision.c b/revision.c
index 7ddbaa0..b631596 100644
---
Junio C Hamano gits...@pobox.com writes
Matthieu Moy matthieu@grenoble-inp.fr writes:
+void get_two_last_lines(char *filename, int *numlines, char **lines)
+{
+...
+}
+
+void get_two_first_lines(char *filename, int *numlines, char **lines)
+{
+...
+}
I had a handful of
Each ref namespace have their own separate branches, tags, and HEAD, so
when pushing to a namespace we need to make sure that there exists a
HEAD ref for the namespace, otherwise you will not be able to check out
the repo after cloning from a namespace
Signed-off-by: Johannes Löthberg
Tay Ray Chuan rcta...@gmail.com writes:
All of the above assumes that showing only the patch and not other
hints to help situation awareness while making a commit is a useful
thing in the first place. I am undecided on that point myself.
Hmm, perhaps such functionality should be off-loaded
I should also look into why the other tests in t5509 fail later.
--
Sincerely,
Johannes Löthberg
PGP Key ID: 0x50FB9B273A9D0BB5
https://theos.kyriasis.com/~kyrias/
signature.asc
Description: PGP signature
On 06/05/2015 11:45 AM, Jeff King wrote:
On Fri, Jun 05, 2015 at 01:41:21AM +, brian m. carlson wrote:
However, with the object_id conversion, we run into a problem: casting
those unsigned char * values into struct object_id * values is not
allowed by the C standard. There are two
Johannes Sixt j...@kdbg.org writes:
The remaining 3 patches replace the select() invocation that waits
for a short time period by the version with poll() that we already
use in help.c. This is necessary because a select() call where all
three sets of file descriptors are empty is not
2015-06-05 21:17 GMT+02:00 Phillip Sz phillip.sze...@gmail.com:
Acked-by: Phillip Sz phillip.sze...@gmail.com
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
On Fri, Jun 5, 2015 at 3:35 PM, Junio C Hamano gits...@pobox.com wrote:
Mike Rappazzo rappa...@gmail.com writes:
I find that If I am doing a rebase with the intention to squash or
re-order commits, it is helpful to know the commit author.
There is not a fundamental reason why the remainder of
On 06/05/2015 09:45 PM, Johannes Sixt wrote:
The first patch is the same that I posted earlier. It fixes a build
failure on Windows on master due to missing random/srandom.
The remaining 3 patches replace the select() invocation that waits
for a short time period by the version with poll()
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
A handful of topics that graduated to 'master' a few weeks ago are
now in 'maint', the tip of which has been tagged as v2.4.3.
On the 'master'
Mike Rappazzo rappa...@gmail.com writes:
I find that If I am doing a rebase with the intention to squash or
re-order commits, it is helpful to know the commit author.
There is not a fundamental reason why the remainder of the line
after the object name in the rebase insn sheet should not be
On Fri, Jun 5, 2015 at 6:34 PM, Louis Stuber
stub...@ensimag.grenoble-inp.fr wrote:
Signed-off-by: Louis Stuber stub...@ensimag.grenoble-inp.fr
Signed-off-by: Antoine Delaite antoine.dela...@ensimag.grenoble-inp.fr
---
It looks like this patch applies on top of the bisect old/new series
Jeff King p...@peff.net writes:
But if you are OK to eventually stop dying, I think this line of
reasoning is OK.
diff --git a/builtin/log.c b/builtin/log.c
index 4c4e6be..3b568a1 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -148,6 +148,9 @@ static void cmd_log_init_finish(int argc,
On Fri, Jun 05, 2015 at 06:36:39AM -0400, Jeff King wrote:
On Fri, Jun 05, 2015 at 05:14:25PM +0700, Duy Nguyen wrote:
I'm more concerned about breaking object_id abstraction than C
standard. Let's think a bit about future. I suppose we need to support
both sha-1 and sha-512, at least at
Use the new function sleep_millisec() to delay execution for a short
time. This avoids the invocation of select() with just a timeout, but
no file descriptors. Such a use of select() is quit with EINVAL on
Windows, leading to no delay at all.
Signed-off-by: Johannes Sixt j...@kdbg.org
---
We want to use the new function elsewhere in a moment.
Signed-off-by: Johannes Sixt j...@kdbg.org
---
cache.h | 1 +
help.c| 2 +-
wrapper.c | 5 +
3 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/cache.h b/cache.h
index 54f108a..328cdb7 100644
--- a/cache.h
+++ b/cache.h
When the goal is to wait for some random amount of time up to one
second, it is not necessary to compute with microsecond precision.
This is a preparation to re-use sleep_millisec().
Signed-off-by: Johannes Sixt j...@kdbg.org
---
lockfile.c | 21 -
1 file changed, 8
On Windows, we do not have functions srandom() and random(). Use srand()
and rand(). These functions produce random numbers of lesser quality,
but for the purpose (a retry time-out) they are still good enough.
Signed-off-by: Johannes Sixt j...@kdbg.org
---
This is the same version I posted
The first patch is the same that I posted earlier. It fixes a build
failure on Windows on master due to missing random/srandom.
The remaining 3 patches replace the select() invocation that waits
for a short time period by the version with poll() that we already
use in help.c. This is necessary
On Fri, Jun 5, 2015 at 12:34 PM, Louis Stuber
stub...@ensimag.grenoble-inp.fr wrote:
git-bisect.sh : create a file if the bisection is in old/new mode,
named BISECT_OLDNEWMODE, so it can easily be seen outside the
program without having to read BISECT_TERMS. This will have to be
changed in
On 06/05/2015 09:42 PM, brian m. carlson wrote:
On Fri, Jun 05, 2015 at 05:22:08PM +0200, Michael Haggerty wrote:
I don't know that there would necessarily be problems, but I
would worry about code involving structure assignment. For
example, suppose the following snippet:
void f(struct
The latest maintenance release Git v2.4.3 is now available at
the usual places.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/
The following public repositories all have a copy of the 'v2.4.3'
tag and the 'maint' branch that the tag points at:
url =
On Fri, Jun 05, 2015 at 05:22:08PM +0200, Michael Haggerty wrote:
I don't know that there would necessarily be problems, but I would worry
about code involving structure assignment. For example, suppose the
following snippet:
void f(struct object_id *oid)
{
struct object_id
On Fri, Jun 5, 2015 at 12:34 PM, Louis Stuber
stub...@ensimag.grenoble-inp.fr wrote:
Fix git rev-list --bisect and git bisect visualize when the bisection
is done in old/new mode.
See my review of patch 1/2 regarding writing a good commit message. In
particular, explain what is broken about git
I think the custom format makes sense. I took a first pass.
A config option 'rebase.interactive.todo-format' can override the
default 'oneline' format of the TODO list. Since the list is
parsed using the left, right or boundary mark plus the sha1, then if the
custom format does not start with
In anticipation of extending this behaviour, add tests verifying the
handling of exclamation marks when looking up a commit by name.
Specifically, as documented: 'rev^{/!Message}' should fail, as the '!'
prefix is reserved; while 'rev^{!!Message}' should search for a commit
whose message contains
add support for negative pattern matching in @^{/pattern} style
revision specifiers. So now you can find the first commit whose message
doesn't match a pattern, complementing the existing positive matching.
e.g.:
$ git rebase -i @^{/!-^WIP}
My use-case is in having a work, work, work,
To name a commit, you can now say
$ git rev-parse HEAD^{/!-foo}
and it will return the hash of the first commit reachable from HEAD,
whose commit message does not contain foo. This is the opposite of the
existing rev^{/pattern} syntax.
The specific use-case this is intended for is to
When running the test suite with GIT_TEST_SPLIT_INDEX set, tests 17-18
in t7063 fail. Unset GIT_TEST_SPLIT_INDEX at the beginning of the test,
in order to fix it.
Signed-off-by: Thomas Gummerer t.gumme...@gmail.com
---
Hi,
This breakage is both in the current master and next. I'm not entirely
Hi folks,
I'm not sure how to respond to a particular mail [1] while keeping
this new one in the same thread, being that I just subscribed to the
list and I can't find a Message-ID in [1][2] either, so please forgive
me.
I bumped to 2.4.2 and I'm experiencing the very same issue Jonathan
Kamens
On 05/25/2015 08:38 PM, brian m. carlson wrote:
From: Michael Haggerty mhag...@alum.mit.edu
They were never used.
[...]
I happened to dig into the background of this change a little more, and
this is what I found out.
When deleting remote-tracking references, we used to record the old_sha1
87 matches
Mail list logo
