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 w
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 th
In anticipation of extending this behaviour, add tests verifying the
handling of exclamation marks when looking up a commit "by name".
Specifically, as documented: '^{/!Message}' should fail, as the '!'
prefix is reserved; while '^{!!Message}' should search for a commit
whose message contains the
add support for negative pattern matching in @^{/} 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, rebase, push"
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 ^{/} syntax.
The specific use-case this is intended for is to perform an oper
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
---
Hi,
This breakage is both in the current master and next. I'm not entirely
sure this is the bes
Jeff King writes:
> So I think your patch is the best option, but it might be good to give
> one more look at the callers to be sure we are not missing something.
The two callers both leave the outsz uninitialized and to a human it
is obvious that uninitialized outsz is never used when the funct
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'
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 = https://kernel
Jeff King 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, c
On Fri, Jun 5, 2015 at 6:34 PM, Louis Stuber
wrote:
>
> Signed-off-by: Louis Stuber
> Signed-off-by: Antoine Delaite
> ---
It looks like this patch applies on top of the bisect old/new series
posted by Antoine.
This should be stated somewhere.
> git-bisect.sh |8 +++-
> 1 files change
On Fri, Jun 5, 2015 at 12:34 PM, Louis Stuber
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 rev-list --bisect" and
"git
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
On Fri, Jun 5, 2015 at 12:34 PM, Louis Stuber
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 further versions if new terms
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(
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 le
Johannes Sixt 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 supported on Windo
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
---
lockfile.c | 21 -
1 file changed, 8 insertions(+), 13 delet
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
---
This is the same version I posted earlier.
lockfile
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 bec
We want to use the new function elsewhere in a moment.
Signed-off-by: Johannes Sixt
---
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
@@ -1680,5 +16
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
---
lockfile.c | 10 +---
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 obj
On Fri, Jun 5, 2015 at 3:35 PM, Junio C Hamano wrote:
> Mike Rappazzo 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
Mike Rappazzo 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
customizable, and I
2015-06-05 21:17 GMT+02:00 Phillip Sz :
> Acked-by: Phillip Sz
>
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
Christian Stimming 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 "sta
Acked-by: Phillip Sz
> Signed-off-by: Ralf Thielow
> ---
> 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"
>
> #
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 b/git-reb
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 comm
On Fri, Jun 5, 2015 at 1:44 PM, Eric Sunshine wrote:
> On Fri, Jun 5, 2015 at 5:32 AM, Ed Avis wrote:
>> Torsten Bögershausen 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/Documen
Eric Sunshine 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 gave. Also, Ed,
Signed-off-by: Ralf Thielow
---
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
msgid "make index objects
On Fri, Jun 5, 2015 at 5:32 AM, Ed Avis wrote:
> Torsten Bögershausen 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
> ind
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
---
Changes
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
On 05/06, Junio C Hamano wrote:
Johannes Löthberg writes:
+
+ echo "ref: refs/namespaces/new_namespace/refs/heads/master" >expect
&&
+ test_cmp expect ../bare/refs/namespaces/new_namespace/HEAD &&
Use "symbolic-ref refs/namespaces/new_namespace/HEAD"; HEAD is no
Johannes Löthberg 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
>
> -test_description='fetch/push invo
Tay Ray Chuan 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 to a third
Guillaume Pages 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 lines
> * lines needs to be at le
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
David Deutsch 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 carriage r
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 v
On Sat, Jun 6, 2015 at 12:03 AM, Junio C Hamano wrote:
> Tay Ray Chuan 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
>> --n
Johannes Löthberg 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 legitimate reason for
Duy Nguyen 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 that writes tod
Junio C Hamano writes
>Matthieu Moy 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 comments on these:
Signed-off-by: Louis Stuber
Signed-off-by: Antoine Delaite
---
revision.c | 15 +--
1 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/revision.c b/revision.c
index 7ddbaa0..b631596 100644
--- a/revision.c
+++ b/revision.c
@@ -2075,12 +2075,23 @@ void parse_revision_o
Signed-off-by: Louis Stuber
Signed-off-by: Antoine Delaite
---
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
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -183,6 +183,10 @@ bisect_start() {
Paul Tan 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 scripted Porcelains
On 05/06, Junio C Hamano wrote:
Johannes Löthberg 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 a
On Fri, Jun 5, 2015 at 11:36 PM, Junio C Hamano wrote:
> Paul Tan 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 in
On 05/06, Johannes Löthberg wrote:
On 05/06, Junio C Hamano wrote:
Johannes Löthberg writes:
git -C ../bare symbolic-ref HEAD >actual &&
echo refs/heads/master >expect &&
test_cmp expect actual &&
git -C ../bare rev-parse HEAD >actu
Johannes Löthberg 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.
The destination t
On 05/06, Junio C Hamano wrote:
Johannes Löthberg 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 think it probably is
Tay Ray Chuan 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 and matching st
On Fri, Jun 5, 2015 at 8:54 AM, Rossella Barletta
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, included the
> folder .
"Gondek, Andreas" 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 (and in 'pu') for a few
Paul Tan 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 files the
> fa
Johannes Löthberg writes:
> Test that the master ref is set up properly when cloning from a ref
> namespace
>
> Signed-off-by: Johannes Löthberg
> ---
> t/t9904-clone-from-ref-namespace.sh | 33 +
It seems that 5509 already has a few tests for namespaced transfer
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 tw
On 05/25/2015 08:38 PM, brian m. carlson wrote:
> From: Michael Haggerty
>
> 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
of each reference
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. Assumin
Test that the master ref is set up properly when cloning from a ref
namespace
Signed-off-by: Johannes Löthberg
---
t/t9904-clone-from-ref-namespace.sh | 33 +
1 file changed, 33 insertions(+)
create mode 100755 t/t9904-clone-from-ref-namespace.sh
diff --git a/t/
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
---
builti
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 chang
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
https://theos
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 5, 2015 at 5:36 PM, 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 the so
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 prob
Hi Junio,
On Fri, Jun 5, 2015 at 2:39 AM, Junio C Hamano wrote:
>
> Tay Ray Chuan 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 not --diff or --patch
> for
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 i
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
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 loos
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 wrote:
> Torsten Bögershausen 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
> i
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
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 bigg
On Fri, Jun 5, 2015 at 4:45 PM, 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. Ther
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
Torsten Bögershausen 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
--- a/Documentation/git-checkou
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 reencode_string
On Fri, Jun 5, 2015 at 10:07 AM, Christian Couder
wrote:
> On Fri, Jun 5, 2015 at 7:56 AM, Gondek, Andreas
> 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 5, 2015 at 1:27 AM, Stefan Beller wrote:
> On Thu, Jun 4, 2015 at 3:34 AM, Paul Tan 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 clean, it will then error out
On Fri, Jun 5, 2015 at 7:56 AM, Gondek, Andreas
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:
https://github.com/git/git/blob/master/Documentation/howto/maintain-
85 matches
Mail list logo
