using negative patterns. For example, to remove the file
> `unwanted`:
> !unwanted
>
>
> -Another tricky thing is fully repopulating the working directory when you
> -no longer want sparse checkout. You cannot just disable "spa
> >> ...
> >> Luke, does this look good?
> >>
> >> I know Mazo is the only other contributor who has multiple commits
> >> to git-p4.py in the past 2 years, to make Reviewed-by carry some
> >> weight ;-) but as we have so small number of people touching this
> >> script anyway, I'd rather see
Bert Wesarg writes:
> + switch
> (safe_create_leading_directories_const(output_directory)) {
> + case SCLD_OK:
> + case SCLD_EXISTS:
> + break;
> + default:
> + die(_("could not create leading directories "
>
René Scharfe writes:
> Strip "UTF" and an optional dash from the start of 'upper' without
> passing a NULL pointer to skip_prefix() in the second call, as it cannot
> handle that.
Did the original meant to say "skip UTF- from the beginning of upper
and store it to stripped, or if that cannot be
On Sat, Oct 5, 2019 at 3:44 PM Elijah Newren wrote:
>
> On Thu, Sep 19, 2019 at 3:07 PM Derrick Stolee via GitGitGadget
> wrote:
> > +static int write_patterns_and_update(struct pattern_list *pl)
> > +{
> > + char *sparse_filename;
> > + FILE *fp;
> > +
> > + sparse_filename = g
"Johannes Schindelin via GitGitGadget"
writes:
> Changes since v2:
>
> * The overflow check introduced in v1 was consolidated into a single
>helper.
Looks good to me.
> Range-diff vs v2:
>
> 1: 4d0b38125a = 1: 4d0b38125a push: do not pretend to return `int` from
> `die_push_simple()`
Eric Wong writes:
> That said, there could be other compilers which don't set
> __GNUC__ and have the same problem as clang. But maybe those
> compilers are too buggy and we already ignore invalid warnings
> on those compilers.
Perhaps.
Johannes Schindelin writes:
>> IMHO, if you don't accompany insert_pos_as_negative_offset() with a
>> corresponding extract_pos_and_found_condition() and use it everywhere,
>> it is more obfuscating than necessary.
>
> I do disagree here. No overflow checking needs to be performed for `-1 -
> `.
René Scharfe writes:
> It works best for changes whose effects are constrained to within the
> affected functions, but have crucial information located outside the
> three default lines of context. An example would be a change at the end
> of a function for which a reviewer might need to know th
Phillip Wood writes:
>> * ra/rebase-i-more-options (2019-09-09) 6 commits
>> ...
>> Is this ready for 'next'.
>
> Nearly, but not quite I think cf [1]. Also I'm still not convinced
> that having different behaviors for --ignore-whitespace depending on
> the backend is going to be helpful but ma
Junio C Hamano writes:
>> if (len <= 0) {
>> free(fragment);
>> -return error(_("corrupt patch at line %d"),
>> state->linenr);
>> +return error(_("corrupt patch at %s:%d"),
>> state->patch_input_file, state->linenr);
>>
On Thu, Sep 19, 2019 at 3:07 PM Derrick Stolee via GitGitGadget
wrote:
> +static int write_patterns_and_update(struct pattern_list *pl)
> +{
> + char *sparse_filename;
> + FILE *fp;
> +
> + sparse_filename = get_sparse_checkout_filename();
> + fp = fopen(sparse_filename, "w
Junio C Hamano writes:
>> An alternate design was considered which involved printing the line
>> numbers relative to the output of `git am --show-current-patch` (in
>> other words, the actual mail file that's provided to am). This design
>> was not chosen because am does not store the whole mail
> > +letter. A cover letter is an email explaining in brief what the series is
> > +supposed to do. A cover letter template can be generated by passing
> > +`--cover-letter` to `git-format-patch`.
> > +
> > +After you send your patches, you might get a review suggesti
Hi Johannes,
On 05/10/19 09:56PM, Johannes Schindelin wrote:
> Hi Pratyush,
>
> On Sat, 5 Oct 2019, Pratyush Yadav wrote:
>
> > It is a good idea to have a readme so people finding the project can
> > know more about it, and know how they can get involved.
> >
> > Signed-off-by: Pratyush Yadav
On 06/10/19 01:46AM, Harish Karumuthil wrote:
> Hi All,
>
> From https://www.kernel.org/doc/html/v4.10/process/email-clients.html, I
> understood that, my current email client ( that is gmail web ) is not good
> for submitting patches. So I was tying to setup a mail client which is
> compatible wi
Hi All,
>From https://www.kernel.org/doc/html/v4.10/process/email-clients.html, I
understood that, my current email client ( that is gmail web ) is not good
for submitting patches. So I was tying to setup a mail client which is
compatible with `git send-mail`. But I was not able to get a satisfact
t. Commits can be converted to emails via the two tools provided by
> +git: `git-send-email` and `git-format-patch`.
> +
> +If you are sending multiple patches, it is recommended to include a cover
> +letter. A cover letter is an email explaining in brief what the series is
> +suppo
Hi Elijah
On 05/10/2019 01:40, Elijah Newren wrote:
On Fri, Oct 4, 2019 at 4:49 AM Phillip Wood wrote:
Hi Junio
On 03/10/2019 06:04, Junio C Hamano wrote:
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'
On Thu, Sep 19, 2019 at 3:06 PM Derrick Stolee via GitGitGadget
wrote:
> During the 'git sparse-checkout init' call, we must first look
> to see if HEAD is valid, or else we will fail while trying to
> update the working directory. The first checkout will actually
> update the working directory c
On Thu, Sep 19, 2019 at 3:06 PM Derrick Stolee via GitGitGadget
wrote:
>
> From: Derrick Stolee
>
> Getting started with a sparse-checkout file can be daunting. Help
> users start their sparse enlistment using 'git sparse-checkout init'.
> This will set 'core.sparseCheckout=true' in their config,
agraphs you were
copying.
> +Another tricky thing is fully repopulating the working directory when you
> +no longer want sparse checkout. You cannot just disable "sparse
> +checkout" because skip-worktree bits are still in the index and your working
> +directory is still sparsel
On Fri, Oct 4, 2019 at 2:29 AM Phillip Wood wrote:
>
> Hi Rohit
>
> On 07/09/2019 12:50, Rohit Ashiwal wrote:
> > There are two backends available for rebasing, viz, the am and the
> > interactive. Naturally, there shall be some features that are
> > implemented in one but not in the other. One su
On 05/10/2019 17:14, Alexander Litvinov wrote:
unsibscribe git
try sending to majordomo, see http://vger.kernel.org/vger-lists.html#git
Am 04.10.19 um 01:15 schrieb Junio C Hamano:
> René Scharfe writes:
>
>> Found with "git grep '^#include ' '*.c' | sort | uniq -d".
>>
>> Signed-off-by: René Scharfe
>> ---
>> Patch formatted with --function-context for easier review.
>
> I have a mixed feelings about that.
>
> The only audience
Am 04.10.19 um 23:30 schrieb Stephen Boyd:
> While reviewing some dts diffs recently I noticed that the hunk header
> logic was failing to find the containing node. This is because the regex
> doesn't consider properties that may span multiple lines, i.e.
>
> property = ,
>
n
> +text format. Commits can be converted to emails via the two tools provided by
> +git: `git-send-email` and `git-format-patch`.
> +
> +If you are sending multiple patches, it is recommended to include a cover
> +letter. A cover letter is an email explaining in brief what the serie
Denton Liu writes:
> The synopsis section in git-rev-list.txt has grown to be a huge list
> that probably needs its own synopsis. Since the list is huge, users may
> be given the false impression that the list is complete, however it is
> not. It is missing many of the available options.
>
> Sinc
Pratyush Yadav writes:
> Signed-off-by: Pratyush Yadav
> ---
> Documentation/git-gui.txt | 8 ++--
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/git-gui.txt b/Documentation/git-gui.txt
> index 5f93f8003d..98337b69f1 100644
> --- a/Documentation/git-gui.txt
Denton Liu writes:
> When `git am` runs into a corrupt patch, it'll error out and give a
> message such as,
>
> error: corrupt patch at line 87
>
> Casual users of am may assume that this line number refers to the
> file that they provided on the command-line. This assumption, however,
> i
On Fri, Oct 4, 2019 at 4:49 AM Phillip Wood wrote:
>
> Hi Junio
>
> On 03/10/2019 06:04, Junio C Hamano wrote:
> > 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 ones marked with
On 2019.10.04 11:12, Johannes Schindelin wrote:
> Hi Josh,
>
> On Thu, 3 Oct 2019, Josh Steadmon wrote:
>
> > [...]
> > diff --git a/trace2/tr2_dst.c b/trace2/tr2_dst.c
> > index 5dda0ca1cd..af3405f179 100644
> > --- a/trace2/tr2_dst.c
> > +++ b/trace2/tr2_dst.c
> > @@ -1,3 +1,5 @@
> > +#include
Hi Junio,
On Fri, 4 Oct 2019, Junio C Hamano wrote:
> "Johannes Schindelin via GitGitGadget"
> writes:
>
> > +test_expect_success 'parallel' '
> > + git remote add one ./bogus1 &&
> > + git remote add two ./bogus2 &&
> > +
> > + test_must_fail env GIT_TRACE="$PWD/trace" \
> > + g
On 2019.10.04 09:25, Junio C Hamano wrote:
> Josh Steadmon writes:
>
> > trace2 can write files into a target directory. With heavy usage, this
> > directory can fill up with files, causing difficulty for
> > trace-processing systems.
>
> Sorry for not mentioning this, but "don't overload" is a
Hi Hannes,
On Fri, 4 Oct 2019, Johannes Sixt wrote:
> Am 04.10.19 um 11:55 schrieb Johannes Schindelin:
> > On Fri, 4 Oct 2019, Junio C Hamano wrote:
> >> These three look good and too similar to each other, which makes me
> >> wonder if we want to allow them simply write
> >>
> >>return inse
Hi Pratyush,
On Fri, 4 Oct 2019, Pratyush Yadav wrote:
> On 01/10/19 07:38PM, Johannes Schindelin wrote:
> >
> > On Tue, 1 Oct 2019, Pratyush Yadav wrote:
> >
> > > On 30/09/19 11:42AM, Johannes Schindelin wrote:
> > > > On Fri, 27 Sep 2019, Pratyush Yadav wrote:
> > > > > On 27/09/19 08:10AM, Be
Junio C Hamano wrote:
> Eric Wong writes:
>
> > That seems too tedious. I'm learning towards just initializing
> > var = NULL in the start of the for-loop:
> >
> > @@ -449,7 +449,8 @@ static inline struct hashmap_entry
> > *hashmap_iter_first(struct hashmap *map,
> > * containing a @member w
Am 04.10.19 um 11:55 schrieb Johannes Schindelin:
> On Fri, 4 Oct 2019, Junio C Hamano wrote:
>> These three look good and too similar to each other, which makes me
>> wonder if we want to allow them simply write
>>
>> return insert_pos_as_negative_offset(nr);
>>
>> with something like
>>
>>
On 01/10/19 07:38PM, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 1 Oct 2019, Pratyush Yadav wrote:
>
> > On 30/09/19 11:42AM, Johannes Schindelin wrote:
> > > On Fri, 27 Sep 2019, Pratyush Yadav wrote:
> > > > On 27/09/19 08:10AM, Bert Wesarg wrote:
> > > > > On Fri, Sep 27, 2019 at 12:40 AM Pra
On 04/10/2019 16:22, Bert Wesarg wrote:
On Thu, Oct 3, 2019 at 11:40 PM Philip Oakley wrote:
On 03/10/2019 21:54, Pratyush Yadav wrote:
My only remaining bikeshed question it prompted was to check which parts
would be committed as part of committing the whole "hunk". But haven't had
time to lo
"brian m. carlson" writes:
> I think GitGitGadget is a useful tool which I haven't really had the
> time to learn how to use. I appreciate that many people prefer a
> patch-based workflow, and that using a patch-based workflow and a
> mailing list provides the project independence and avoids fav
Derrick Stolee writes:
> On 9/25/2019 9:36 AM, Pierre Tardy wrote:
[...]
>> And why restrict on DVCS?
>> Isn't it admitted that the distributed version control is nowadays
>> much better in term of software productivity?
>> Is there some use cases that "traditional" centralized VCS are better
>> o
On 10/4/2019 4:52 AM, Johannes Schindelin wrote:
> Hi George,
>
> if you have Visual Studio, you could also check out the `vs/master`
> branch of https://github.com/git-for-windows/git and build Git inside
> Visual Studio. The tests can still be run in Git Bash (the regular one
> this time, no nee
On 04/10/19 10:49AM, Johannes Schindelin wrote:
> Hi Pratyush,
>
> please don't top-post on this list (yet another of these things
> requiring extra brain cycles in the mailing list workflow).
I didn't top-post, or at least it wasn't the intention. The text above
the quoted text is the "preface"
Don't forget the reply-all..
On 04/10/2019 11:48, Colin Agnew wrote:
Hi,
Sorry the screenshot was blocked. The screenshot:
http://media.makingthingswork.org/gui.png
png shows https://git-scm.com/video/what-is-version-control 2m:21s
position, and the spoken word is that it is the "GitHub for
Elijah Newren writes:
> On Thu, Sep 19, 2019 at 11:37 AM Derrick Stolee wrote:
[...]
>> II. Approach
>>
>> The action items below match the problems listed above.
>>
>> 1. Improve the documentation for contributing to Git.
>>
>> In preparation for this email, I talked to someone familiar with is
On Fri, 4 Oct 2019 at 12:14, Philip Oakley wrote:
> On 04/10/2019 08:19, Colin Agnew wrote:
> > Could you confirm which GUI is featured in the first video?
> > Please advise - thanks
> Dunno,
>
> Do you have a web reference for the "Git Basics Episode 1" and then
> which video you are watching?
I
On 04/10/2019 08:19, Colin Agnew wrote:
Could you confirm which GUI is featured in the first video?
Please advise - thanks
Dunno,
Do you have a web reference for the "Git Basics Episode 1" and then
which video you are watching?
I guess that if it is the plain vanila Git, then it will be `git
Hi Junio,
On Fri, 4 Oct 2019, Junio C Hamano wrote:
> "Johannes Schindelin via GitGitGadget"
> writes:
>
> > While at it, we take care of reporting overflows (which are unlikely,
> > but hey, defensive programming is good!).
> >
> > We _also_ take pains of casting the unsigned value to signed: o
Hi Junio
On 03/10/2019 06:04, Junio C Hamano wrote:
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 ones marked with '.' do not appear in any of
the integration branches, but I am still
Hi Rohit
The handling of ident_split is looking better now but I've got a
question below about returning vs going to a cleanup section when
there's an error.
On 07/09/2019 12:50, Rohit Ashiwal wrote:
rebase am already has this flag to "lie" about the committer date
by changing it to the auth
Hi Junio,
On Fri, 4 Oct 2019, Junio C Hamano wrote:
> "Johannes Schindelin via GitGitGadget"
> writes:
>
> > From: Johannes Schindelin
> >
> > This function is marked as `NORETURN`, and it indeed does not want to
> > return anything. So let's not declare it with the return type `int`.
> > This
Hi Alexander,
On Thu, 3 Oct 2019, Alexander Mills wrote:
> when running git commands outside of a git repo, we often see:
>
> fatal: Not a git repository (or any of the parent directories): .git
>
> such a lame message lol.
An equally ornery response might point out that reporting this as a bug
Hi Rohit
On 07/09/2019 12:50, Rohit Ashiwal wrote:
There are two backends available for rebasing, viz, the am and the
interactive. Naturally, there shall be some features that are
implemented in one but not in the other. One such flag is
--ignore-whitespace which indicates merge mechanism to tre
feels
> a bit disturbing, at least to me, though.
You're absolutely right! Of course, the problem this patch fixes is
_because_ `GIT_DIR` is defined, but I should make sure that I don't
introduce the reverse problem ;-)
> I wondered if this misbehaves when the end user has GIT_WORK_TREE
Hi Josh,
On Thu, 3 Oct 2019, Josh Steadmon wrote:
> [...]
> diff --git a/trace2/tr2_dst.c b/trace2/tr2_dst.c
> index 5dda0ca1cd..af3405f179 100644
> --- a/trace2/tr2_dst.c
> +++ b/trace2/tr2_dst.c
> @@ -1,3 +1,5 @@
> +#include
> +
This completely breaks the Windows build:
In file inclu
Hi George,
if you have Visual Studio, you could also check out the `vs/master`
branch of https://github.com/git-for-windows/git and build Git inside
Visual Studio. The tests can still be run in Git Bash (the regular one
this time, no need for the Git for Windows SDK in that case).
Ciao,
Johannes
-e zsh
> > + noconsole = yes
> > + gitgui-shortcut = "Control-y"
> > + [guitool "Sync"]
> > + cmd = "git pull; git push"
> > + gitgui-shortcut = "Alt-s"
>
> The "Documentation/" subdirectory belongs to the Git pro
"Kunal Tyagi via GitGitGadget" writes:
> From: Kunal Tyagi
>
> Report the current hunk count and total number of hunks for the current
> file in the prompt
> Adjust the expected output in some tests to account for new data on the prompt
>
> Signed-off-by: Kunal Tyagi
> ---
> git-add--interacti
Denton Liu writes:
> Range-diff against v1:
> 1: e77af8cde5 = 1: e77af8cde5 test-lib: let test_merge() perform octopus
> merges
micronit: I would say s/let/allow/ if I were writing this.
> 2: 4a93deb3f6 = 2: 4a93deb3f6 t4214: use test_merge
> 3: c09f761185 = 3: c09f761185 t4214: generate
Elijah Newren writes:
> This series improves the incremental export story for fast-export and
> fast-import (--export-marks and --import-marks fell a bit short),
> fixes a couple small export/import bugs, and enables handling nested
> tags. In particular, the nested tags handling makes it so tha
"Johannes Schindelin via GitGitGadget"
writes:
> +test_expect_success 'parallel' '
> + git remote add one ./bogus1 &&
> + git remote add two ./bogus2 &&
> +
> + test_must_fail env GIT_TRACE="$PWD/trace" \
> + git fetch --jobs=2 --multiple one two 2>err &&
> + grep "2 t
Eric Wong writes:
> That seems too tedious. I'm learning towards just initializing
> var = NULL in the start of the for-loop:
>
> @@ -449,7 +449,8 @@ static inline struct hashmap_entry
> *hashmap_iter_first(struct hashmap *map,
> * containing a @member which is a "struct hashmap_entry"
> */
Junio C Hamano wrote:
> Eric Wong writes:
>
> > In the future, list iterator macros (e.g. list_for_each_entry)
> > may also be implemented using OFFSETOF_VAR to save hackers the
> > trouble of using container_of/list_entry macros and without
> > relying on non-portable `__typeof__'.
>
> Can we
Eric Wong writes:
> In the future, list iterator macros (e.g. list_for_each_entry)
> may also be implemented using OFFSETOF_VAR to save hackers the
> trouble of using container_of/list_entry macros and without
> relying on non-portable `__typeof__'.
Can we add something like this as a preliminar
Josh Steadmon writes:
> trace2 can write files into a target directory. With heavy usage, this
> directory can fill up with files, causing difficulty for
> trace-processing systems.
Sorry for not mentioning this, but "don't overload" is a suboptimal
keyword for the entire topic and for this part
"William Baker via GitGitGadget" writes:
> create mode 100755 t/t7519/fsmonitor-env
> ...
> + if (pos >= istate->cache_nr)
> + BUG("fsmonitor_dirty has more entries than the index
> (%"PRIuMAX" >= %"PRIuMAX")",
> + (uintmax_t)pos, (uintmax_t)istate->cache_nr);
T
Johannes Schindelin writes:
> Hi all,
>
> On Thu, 3 Oct 2019, William Baker via GitGitGadget wrote:
>
>> This patch series fixes a segfault that I encountered while testing
>> fsmonitor. Under some circumstances, the fsmonitor extension was being
>> written with too many bits, and subsequent git
René Scharfe writes:
> Found with "git grep '^#include ' '*.c' | sort | uniq -d".
>
> Signed-off-by: René Scharfe
> ---
> Patch formatted with --function-context for easier review.
I have a mixed feelings about that.
The only audience benefitted by --function-context patch are those
who read t
Carlo Arenas writes:
> or we could drop the current branch in pu and start again from scratch
> now that all of the required dependencies had been merged.
That would be the cleanest from my point of view. Thanks, both.
Duy Nguyen writes:
> On Thu, Oct 3, 2019 at 7:52 AM Junio C Hamano wrote:
>> > In fact, running `git am --show-current-patch` shows the whole mail, not
>> > only the 'patch' file so users would have no reason to expect the line
>> > numbers to refer to the 'patch' file.
>>
>> Yeah, show-current-
"William Baker via GitGitGadget" writes:
> This is the third iteration of changes for adding support for
> --[no-]progress to multi-pack-index, and it includes the following updates
> for the feedback I received on v2:
>
> * Fixed commit message formatting
> * Updated 'pack_paths_checked' from
"Johannes Schindelin via GitGitGadget"
writes:
> While at it, we take care of reporting overflows (which are unlikely,
> but hey, defensive programming is good!).
>
> We _also_ take pains of casting the unsigned value to signed: otherwise,
> the signed operand (i.e. the `-1`) would be cast to uns
"Johannes Schindelin via GitGitGadget"
writes:
> From: Johannes Schindelin
>
> This function is marked as `NORETURN`, and it indeed does not want to
> return anything. So let's not declare it with the return type `int`.
> This fixes the following warning when building with MSVC:
>
> C4646:
Elijah Newren writes:
> Actually, René posted a code cleanup suggestion for patch 2/8, so I
> sent a V3 re-roll[1]. Could you pick up V3 instead of merging V2 down
> to next?
>
> [1] https://public-inbox.org/git/20191003202709.26279-1-new...@gmail.com/
Thanks for stopping me.
Will take a look.
Emily Shaffer writes:
> On Thu, Oct 03, 2019 at 02:04:39PM +0900, Junio C Hamano wrote:
>> 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 ones marked with '.' do not appear in any
like to save those for a follow-up series.
>
> Junio: I know you didn't track this in the recent "what's cooking"
> list, and I don't expect you to take it until I re-roll v3 to
> include the .gitignore interaction I already pointed out.
I have made a mental no
_array_push(&cp.args, "status");
> run_command(&cp);
> }
Nicely spotted. Exporting GIT_WORK_TREE alone without GIT_DIR feels
a bit disturbing, at least to me, though.
I wondered if this misbehaves when the end user has GIT_WORK_TREE
environment expo
Jeff King writes:
> That works for the diagram in the code:
>
>| *---.
>| |\ \ \
>|/ / / /
>x 0 1 2
>
> where one of the parent lines is collapsing back to the left. But not
> for this more mundane case:
>
> | *-. commit 211232bae64bcc60bbf5
On 03/10/2019 21:35, Emily Shaffer wrote:
Hi George, it sounds like you are probably using Git for Windows
(https://github.com/git-for-windows/git).
I'm actually not very familiar with how folks who primarily use GfW as
their client manage their contributions to the main Git project.
However, I
ely there is
none yet. I have been meaning to start working towards it, but just
haven't found the time or motivation to do it yet.
> diff --git a/git-gui/lib/tools.tcl b/git-gui/lib/tools.tcl
Like I mentioned before, please base your patches on the git-gui.git
repo, and not git.git. So
On 03/10/2019 21:54, Pratyush Yadav wrote:
My only remaining bikeshed question it prompted was to check which parts
would be committed as part of committing the whole "hunk". But haven't had
time to look at all!
I'm not sure what you mean by "committing the whole hunk". In a merge
conflict state
Hi,
yes, there is no `make` or `gcc` available on Windows by default. You
will have to download and install the Git for Windows SDK:
https://gitforwindows.org/#download-sdk
Ciao,
Johannes
On Thu, 3 Oct 2019, Emily Shaffer wrote:
> Hi George, it sounds like you are probably using Git for Window
Hi all,
On Thu, 3 Oct 2019, William Baker via GitGitGadget wrote:
> This patch series fixes a segfault that I encountered while testing
> fsmonitor. Under some circumstances, the fsmonitor extension was being
> written with too many bits, and subsequent git commands would segfault when
> trying t
On 03/10/19 09:02PM, Philip Oakley wrote:
> On 30/09/2019 13:17, Bert Wesarg wrote:
> > Pratyush,
> >
> > On Sun, Sep 29, 2019 at 5:04 PM Pratyush Yadav
> > wrote:
> > > Hi Philip, Bert,
> > >
> > > Is there any way I can test this change? Philip, I ran the rebase you
> > > mention in the GitHu
Hi George, it sounds like you are probably using Git for Windows
(https://github.com/git-for-windows/git).
I'm actually not very familiar with how folks who primarily use GfW as
their client manage their contributions to the main Git project.
However, I know there are plenty - the GfW maintainer i
else
>
> Updates to fast-import/export.
>
> Will merge to 'next'.
Actually, René posted a code cleanup suggestion for patch 2/8, so I
sent a V3 re-roll[1]. Could you pick up V3 instead of merging V2 down
to next?
[1] https://public-inbox.org/git/20191003202709.26279-1-new...@gmail.com/
On 03/10/2019 19:02, Rohit Sanjay wrote:
subscribe me
try http://vger.kernel.org/vger-lists.html#git for more info...
(email to majord...@vger.kernel.org
body = `subscribe git`)
--
Philip
PS. the list uses bottom posting
https://en.wikipedia.org/wiki/Posting_style
depends on it.
I actually only need to detect the pre-image lines, which starts with
the ||| conflict-marker and ends with the === conflict-marker, instead
of all possible states.
Is there some extra code that you have and I don't?
Also, this function is long and complicated already.
On Thu, Oct 03, 2019 at 02:04:39PM +0900, Junio C Hamano wrote:
> 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 ones marked with '.' do not appear in any of
> the integration branche
Hi Carlo,
On Thu, 3 Oct 2019, Carlo Arenas wrote:
> On Thu, Oct 3, 2019 at 1:09 AM Johannes Schindelin
> wrote:
> > I still need
> > https://github.com/git-for-windows/git/commit/719beb813e4f27f090696ce583df3e5f3c480545
> > and
> > https://github.com/git-for-windows/git/commit/3369c322bbd95820b9
Denton,
On Wed, Oct 2, 2019 at 11:47 PM Denton Liu wrote:
>
> Hi Bert,
>
> > Subject: format-patch: document and exercise that -o does only create the
> > trailing directory
>
> s/does only create/only creates/ ?
>
> Anyway, as a prepatory patch, I don't think that it's necessary. Maybe
> it's j
Hi All,
I', Just reopening this feature request.
A quick summary of my proposal is given below.
1. This PR will allow an additional configuration option
"guitool..gitgui-shortcut" which will allow us to specify
keyboard shortcut for custom commands in git-gui
2. Even there exists a parameter cal
Am 30.09.19 um 23:10 schrieb Elijah Newren:
> If our input stream includes a tag which is later deleted, we were not
> properly deleting it. We did have a step which would delete it, but we
> left a tag in the tag list noting that it needed to be updated, and the
> updating of annotated tags occur
On Thu, Oct 3, 2019 at 1:09 AM Johannes Schindelin
wrote:
> I still need
> https://github.com/git-for-windows/git/commit/719beb813e4f27f090696ce583df3e5f3c480545
> and
> https://github.com/git-for-windows/git/commit/3369c322bbd95820b971701fef7db44b26dd826f
> to fix that part in Git for Windows' `s
Hi Junio,
On Thu, 3 Oct 2019, Junio C Hamano wrote:
> Carlo Arenas writes:
>
> > On Tue, Aug 27, 2019 at 2:07 AM Johannes Schindelin
> > wrote:
> >>
> >> Unfortunately, this is _still_ incorrect.
> > ...
> > Just to clarify, I think my patch accounts for that (haven't tested
> > that assumption
On Thu, Oct 3, 2019 at 4:06 AM Junio C Hamano wrote:
>
> Jeff King writes:
>
> > Hmm, I see the early parts of this graduated to 'next'. I'm not sure
> > everything there is completely correct, though. E.g. I'm not sure of the
> > reasoning in df75281e78 (ewah/bitmap: always allocate 2 more words
On Thu, Oct 3, 2019 at 7:52 AM Junio C Hamano wrote:
> > In fact, running `git am --show-current-patch` shows the whole mail, not
> > only the 'patch' file so users would have no reason to expect the line
> > numbers to refer to the 'patch' file.
>
> Yeah, show-current-patch was a misguided attemp
Carlo Arenas writes:
> On Tue, Aug 27, 2019 at 2:07 AM Johannes Schindelin
> wrote:
>>
>> Unfortunately, this is _still_ incorrect.
> ...
> Just to clarify, I think my patch accounts for that (haven't tested
> that assumption, but will do now that I have a windows box, probably
> even with mi-al
"Johannes Schindelin via GitGitGadget"
writes:
> From: Johannes Schindelin
>
> When parsing the diffs, `range-diff` expects to see the prefixes `a/`
> and `b/` in the diff headers.
>
> These prefixes can be forced off via the config setting
> `diff.noprefix=true`. As `range-diff` is not prepared
701 - 800 of 116325 matches
Mail list logo
