On 07/20/2016 11:47 PM, Pranit Bauva wrote:
Reimplement the `get_terms` and `bisect_terms` shell function in C and
add `bisect-terms` subcommand to `git bisect--helper` to call it from
git-bisect.sh .
In the shell version, the terms were identified by strings but in C
version its done by bit m
FYI: I started working on a series that decouples existence of a
submodule from the URL
as a preparatory series to this one. Then we can have the same URL in
all working trees, but
the existence is configured differently for each working tree.
I'll try to send it out tomorrow.
Thanks,
Stefan
--
T
On Thu, Jul 21, 2016 at 10:59:07PM +0200, larsxschnei...@gmail.com wrote:
> From: Lars Schneider
>
> If three files processed by a filter are added and committed to a
> repository then I expect three clean invocations per Git operation.
> Apparently Git invokes the clean process 12 times.
>
> S
On 2016-07-21 03:54 PM, Philip Oakley wrote:
From: "Marc Branchaud"
On 2016-07-20 05:10 PM, Philip Oakley wrote:
While there, also break out the other shorthand notations and
add a title for the revision range summary (which also appears
in git-rev-parse, so keep it mixed case).
Signed-off-by
On Thu, Jul 21, 2016 at 06:46:44PM +0200, René Scharfe wrote:
> >> - strbuf_add(out, untracked->ident.buf, untracked->ident.len);
> >> + strbuf_addbuf(out, &untracked->ident);
> >
> > This is actually slightly _less_ efficient, because we already are using
> > the precomputed len, and the new c
The previous commit introduced the first use of ENOTSOCK. This macro is
not available on Windows. Define it as WSAENOTSOCK because that is the
corresponding error value reported by the Windows versions of socket
functions.
Signed-off-by: Johannes Sixt
---
compat/mingw.h | 3 +++
1 file changed,
From: Lars Schneider
If three files processed by a filter are added and committed to a
repository then I expect three clean invocations per Git operation.
Apparently Git invokes the clean process 12 times.
Signed-off-by: Lars Schneider
---
It's pretty late here and I hope do not miss something
From: "Marc Branchaud"
On 2016-07-20 05:10 PM, Philip Oakley wrote:
While there, also break out the other shorthand notations and
add a title for the revision range summary (which also appears
in git-rev-parse, so keep it mixed case).
Signed-off-by: Philip Oakley
---
Documentation/revisions
On 07/21/2016 11:46 AM, Johannes Schindelin wrote:
On Wed, 20 Jul 2016, Jeff King wrote:
On Wed, Jul 20, 2016 at 02:20:24PM -0400, Jeff Hostetler wrote:
IIRC, it happens when HEAD points to a broken ref. So something like:
git init
echo broken >.git/refs/heads/master
would cause r
On 07/20/2016 05:31 PM, Junio C Hamano wrote:
The code seems to assume that d->porcelain_v2.* fields are
initialized earlier in the callchain to reasonable values
(e.g. STATUS_ADDED case does not clear .mode_head to "missing"); I
am not sure if that is easier to read or fill in all the values
Am 20.07.2016 um 10:25 schrieb Heiko Voigt:
Hi,
On Tue, Jul 19, 2016 at 09:05:43PM +0200, René Scharfe wrote:
Use a string constant instead of an empty strbuf to shorten the code
and make it easier to read.
This must have been some oversight from my original code. I also can not
see any purpo
[re-sending as plain-text so the list software doesn't reject as
spam... what decade is this?]
Hey,
Sorry about the empty commit message... there was one originally
(albeit not as detailed as the pull request), but I guess it got
stripped? As you have probably guessed, I have no idea how you guys
Johannes Schindelin wrote:
> The common work-around is to install Info-Zip on FreeBSD, into
> /usr/local/bin/.
>
> Signed-off-by: Johannes Schindelin
Thanks, t5003 now works out-of-the-box.
Tested with Info-ZIP unzip installed and uninstalled.
Tested-by: Eric Wong
--
To unsubscribe from this
On Thu, Jul 21, 2016 at 5:58 AM, Matthieu Moy wrote:
> We already suggest 'git rebase --abort' during a conflicted rebase.
> Similarly, suggest 'git merge --abort' during conflict resolution on
> 'git merge'.
I think this is a good addition.
Thanks,
Stefan
--
To unsubscribe from this list: send
Am 20.07.2016 um 15:20 schrieb Jeff King:
> On Tue, Jul 19, 2016 at 08:36:29PM +0200, René Scharfe wrote:
>
>> Use strbuf_addbuf() where possible; it's shorter and more efficient.
>
> After seeing "efficient", I was momentarily surprised by the first hunk:
>
>> diff --git a/dir.c b/dir.c
>> inde
From: Johannes Schindelin
Eric Wong reported that while FreeBSD has a /usr/bin/unzip, it uses
different semantics from those that are needed by Git's tests: When
passing the -a option to Info-Zip, it heeds the text attribute of the
.zip file's central directory, while FreeBSD's unzip ignores that
Hi Peff & Jeff ;-)
On Wed, 20 Jul 2016, Jeff King wrote:
> On Wed, Jul 20, 2016 at 03:27:45PM -0400, Jeff Hostetler wrote:
>
> > > A totally reasonable response is "haha no. Please stop moving the
> > > goalposts". I just wanted to throw it out there as an option (and in
> > > case you are inter
Hi,
On Wed, 20 Jul 2016, Jakub Narębski wrote:
> On 20 July 2016 at 17:47, Jeff Hostetler wrote:
> > On 07/20/2016 11:30 AM, Jakub Narębski wrote:
> >> W dniu 2016-07-20 o 00:10, Jeff Hostetler pisze:
> >>>
> >>> +test_expect_success pre_initial_commit_0 '
> >>> + printf "## branch: (initi
Hi Peff & Jeff ;-)
On Wed, 20 Jul 2016, Jeff King wrote:
> On Wed, Jul 20, 2016 at 02:20:24PM -0400, Jeff Hostetler wrote:
>
> > > IIRC, it happens when HEAD points to a broken ref. So something like:
> > >
> > >git init
> > >echo broken >.git/refs/heads/master
> > >
> > > would cause
Hi David,
On Wed, 20 Jul 2016, David Aguilar wrote:
> As-is, the commit itself should probably be amended to contain
> that information [the better explanation].
Definitely. Keep in mind: if this gets merged or cherry-picked elsewhere,
the Pull Request's message is just as lost.
Ciao,
Johannes
Hi Eric,
On Wed, 20 Jul 2016, Eric Wong wrote:
> Johannes Schindelin wrote:
> >
> > On Wed, 20 Jul 2016, Eric Wong wrote:
> >
> > > diff --git a/config.mak.uname b/config.mak.uname
> > > index a88f139..6c29545 100644
> > > --- a/config.mak.uname
> > > +++ b/config.mak.uname
> > > @@ -202,6 +20
Hi Everyone,
In one of the environments where I work, we experience a very strange
and so far unresolved problem: "git clone" operation gets stuck almost
always near 42% - 45%. For many days we have been unable to pinpoint
the root cause of the issue. Now we would like to see if the "clone"
gets s
On 2016-07-20 05:10 PM, Philip Oakley wrote:
While there, also break out the other shorthand notations and
add a title for the revision range summary (which also appears
in git-rev-parse, so keep it mixed case).
Signed-off-by: Philip Oakley
---
Documentation/revisions.txt | 58 +++
Hi,
On Wed, 20 Jul 2016, Christian Couder wrote:
> On Wed, Jul 20, 2016 at 8:05 PM, Junio C Hamano wrote:
> > On Wed, Jul 20, 2016 at 5:58 AM, Christian Couder
> > wrote:
> >> Hi everyone,
> >>
> >> I'm happy announce that the 17th edition of Git Rev News is now published:
> >>
> >> https://git
Hi Jeff,
On Wed, 20 Jul 2016, Jeff Hostetler wrote:
> On 07/20/2016 11:08 AM, Johannes Schindelin wrote:
> > On Tue, 19 Jul 2016, Jeff Hostetler wrote:
> > > @@ -1336,9 +1347,9 @@ int cmd_status(int argc, const char **argv, const
> > > char *prefix)
> > > N_("show status concisely")
Hi Brian,
On Mon, 18 Jul 2016, brian m. carlson wrote:
> On Mon, Jul 18, 2016 at 09:00:06AM +0200, Johannes Schindelin wrote:
>
> > FWIW it never crossed my mind to allow different same-sized hash
> > algorithms. So I never thought we'd need a way to distinguish, say,
> > BLAKE2b-256 from SHA-25
Hi,
On Wed, 20 Jul 2016, Junio C Hamano wrote:
> Jeff Hostetler writes:
>
> Just to avoid later headaches... please look at your commit titles
> and imagine how they will look when listed among 400+ other changes
> when they are included in a future release in "git shortlog" output.
>
> > Sub
Hi Brian,
On Mon, 18 Jul 2016, brian m. carlson wrote:
> On Mon, Jul 18, 2016 at 11:00:35AM -0700, Junio C Hamano wrote:
> > Continuing this thought process, I do not see a good way to allow us
> > to wean ourselves off of the old hash, unless we _break_ the pack
> > stream format so that each ob
Hi Junio,
On Mon, 18 Jul 2016, Junio C Hamano wrote:
> "brian m. carlson" writes:
>
> > I will say that the pack format will likely require some changes,
> > because it assumes ... The reason is that we can't have an
> > unambiguous parse of the current objects if two hash algorithms are in
>
We already suggest 'git rebase --abort' during a conflicted rebase.
Similarly, suggest 'git merge --abort' during conflict resolution on
'git merge'.
Signed-off-by: Matthieu Moy
---
t/t7060-wtstatus.sh| 4
t/t7512-status-help.sh | 1 +
wt-status.c| 7 +--
3 files changed
On Thu, 21 Jul 2016, Jakub Narębski wrote:
> Or you can use third-party tools with support for such cases, such
Not if the repository is already managed by some other tool
(FusionForge, in this case).
Thanks anyway,
//mirabilos
--
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://ww
W dniu 2016-07-14 o 18:57, Stefan Beller pisze:
> On Thu, Jul 14, 2016 at 8:31 AM, Thorsten Glaser wrote:
>> Hi *,
>>
>> is there a way, for example with some sort of pre-receive hook,
>> to prevent some files from being overwritten by a push?
>
> pre-receive hooks are a thing!
Or you can use th
On Thu, Jul 21, 2016 at 12:07 PM, Vasco Almeida wrote:
> Mark comment displayed when editing a note for translation.
I'm not sure, but wouldn't this make more sense:
> Signed-off-by: Vasco Almeida
> ---
> builtin/notes.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --gi
Mark comment displayed when editing a note for translation.
Signed-off-by: Vasco Almeida
---
builtin/notes.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin/notes.c b/builtin/notes.c
index 0572051..37933bd 100644
--- a/builtin/notes.c
+++ b/builtin/notes.c
@@ -91,
34 matches
Mail list logo
