Hi all,
I tried to run
git gui blame -C somefile
but I got the following error message:
error: Unknown switch `C'
usage: git cat-file (-t [What exactly "git cat-file -C" prints
out for me]
Is there a way to pass in additional options to git gui blame for now?
Thanks!
Hong
Junio,
On Thu, Jul 18, 2019 at 05:22:34PM +0200, SZEDER Gábor wrote:
> Subject: [PATCH] travis-ci: build with GCC 4.8 as well
This patch conflicts with topic 'js/trace2-json-schema', and the
current conflict resolution in 'pu' is not quite correct.
> diff --git a/ci/run-build-and-tests.sh b/ci/r
SZEDER Gábor writes:
> Junio,
>
> On Thu, Jul 18, 2019 at 05:22:34PM +0200, SZEDER Gábor wrote:
>> Subject: [PATCH] travis-ci: build with GCC 4.8 as well
>
> This patch conflicts with topic 'js/trace2-json-schema', and the
> current conflict resolution in 'pu' is not quite correct.
Thanks.
"git
Hi folks,
When a single remote has multiple push URLs, Git’s force-with-lease
logic appears to be:
For each URL:
1. Read refs/heads/mybranch (call this commit X)
2. Read refs/remotes/myremote/mybranch (call this commit Y)
3. Send to the URL an atomic compare-and-swap, replacing Y with X.
4. If ste
Christopher Head writes:
> Hi folks,
> When a single remote has multiple push URLs, Git’s force-with-lease
> logic appears to be:
>
> For each URL:
> 1. Read refs/heads/mybranch (call this commit X)
> 2. Read refs/remotes/myremote/mybranch (call this commit Y)
> 3
> from Y to X, and therefore
On July 27, 2019 10:46:43 AM PDT, Junio C Hamano wrote:
>Christopher Head writes:
>
>Quite honestly, the true culprit of the above story is that you are
>letting multiple logically different remote repositories [*1*] use
>the same single remote-tracking refes/remotes/myremote/ hierarchy.
They we
Hi Junio
On Thu, 25 Jul 2019 17:19:23 -0700 Junio C Hamano wrote:
>
> [...]
> [New Topics]
>
> * bb/grep-pcre2-bug-message-fix (2019-07-23) 1 commit
> (merged to 'next' on 2019-07-23 at 8bd5a68618)
> + grep: print the pcre2_jit_on value
>
> BUG() message fix.
>
> The codepath may want to
6d4b5747f0 ("grep: change internal *pcre* variable & function names
to be *pcre1*", 2017-05-25), renamed most variables to be PCRE1
specific to give space to similarly named variables for PCRE2, but
in this case the change wasn't needed as the types were compatible
enough (const unsigned char* vs c
94da9193a6 ("grep: add support for PCRE v2", 2017-06-01) added a
local variable to keep track of the chartables (used when locale
is not UTF-8 but non-ASCII characters are needed)
Remove that local variable in favor of the shared one within the
grep structure and that can be shared by all function
Just as it is done with PCRE1, make sure that the allocated chartables
get free at cleanup time.
This assumes no global context is used (NULL passed when created the
tables), but will likely be updated in tandem if that ever changes.
Signed-off-by: Carlo Marcelo Arenas Belón
---
grep.c | 1 +
1
This series fixes a small memory leak that was introduced when PCRE2
support was added, and that should be visible with t7813 and valgrind
Applies cleanly to maint and master but will conflict slightly with
ab/no-kwset (currently in next) and most likely other changes introduced
about this same co
Hi Rohit,
Let me attempt to answer on Junio's behalf...
On Sat, Jul 27, 2019 at 12:48 PM Rohit Ashiwal
wrote:
>
> Hi Junio
>
> On Thu, 25 Jul 2019 17:19:23 -0700 Junio C Hamano wrote:
> >
> > * ra/rebase-i-more-options (2019-07-23) 4 commits
> > - SQUASH???
>
> There are only 3 commits in this
Christopher Head writes:
> On July 27, 2019 10:46:43 AM PDT, Junio C Hamano wrote:
>>Christopher Head writes:
>>
>>Quite honestly, the true culprit of the above story is that you are
>>letting multiple logically different remote repositories [*1*] use
>>the same single remote-tracking refes/rem
Hi Elijah
On Sat, 27 Jul 2019 13:40:13 -0700 Elijah Newren wrote:
>
> Let me attempt to answer on Junio's behalf...
:)
> [...]
> There are four, including Junio's commit he had to add in order to
> make the series merge with pu (a rename of your t3431 to the
> unoccupied t3433 slot). He label
Hey Everyone!
Here an update about my last week[1]. There were reviews on
patches I submitted which need to be accounted. There is also
some _mess_ (commit ordering and merging topics) that needs to
be taken out. Polishing them will teach rebase -i some new flags!
Thanks
Rohit
[1]: https://rashi
On Sat, Jul 27, 2019 at 2:00 PM Rohit Ashiwal
wrote:
> > In general, once submitted, avoid rebasing unless needed to integrate
> > with someone else's work and clean up conflicts.
>
> I have not checked but git/git:master is like 569 commits ahead of
> r1walz/git:master, there _might_ be conflicts
On July 27, 2019 1:57:18 PM PDT, Junio C Hamano wrote:
>What I would call "logically the same" is the set of repositories
>that are synchronized at the server side, which may or may not have
>multiple URLs to reach it, but behave as if it is just a single one
>without your doing anything special.
Hi!
Some of my Git repositories have mirrors, maintained with 'rsync'. I
want to have some level of repacking, so that the repositories are
efficient, but I also want it to minimize it, so that 'rsync' never
has to perform a big transfer for the repositories.
For example, I think it would be fine
On Sat, Jul 27 2019, Carlo Marcelo Arenas Belón wrote:
> 6d4b5747f0 ("grep: change internal *pcre* variable & function names
> to be *pcre1*", 2017-05-25), renamed most variables to be PCRE1
> specific to give space to similarly named variables for PCRE2, but
> in this case the change wasn't nee
On Sat, Jul 27 2019, Carlo Marcelo Arenas Belón wrote:
> Just as it is done with PCRE1, make sure that the allocated chartables
> get free at cleanup time.
>
> This assumes no global context is used (NULL passed when created the
> tables), but will likely be updated in tandem if that ever change
On Sat, Jul 27, 2019 at 4:48 PM Ævar Arnfjörð Bjarmason
wrote:
> > + free((void *)p->pcre_tables);
>
> Is the cast really needed? I'm rusty on the rules, removing it from the
> pcre_free() you might have copied this from produces a warning for me,
> but not for free() itself. This is on GCC 8.
On Sat, Jul 27, 2019 at 4:47 PM Ævar Arnfjörð Bjarmason
wrote:
>
> On Sat, Jul 27 2019, Carlo Marcelo Arenas Belón wrote:
>
> > 6d4b5747f0 ("grep: change internal *pcre* variable & function names
> > to be *pcre1*", 2017-05-25), renamed most variables to be PCRE1
> > specific to give space to simi
22 matches
Mail list logo
