On Sat, Dec 8, 2018 at 6:37 PM Robert P. J. Day wrote:
>
> On Sat, 8 Dec 2018, Duy Nguyen wrote:
>
> > On Sat, Dec 8, 2018 at 6:32 PM Robert P. J. Day
> > wrote:
> > >
> > > On Sat, 8 Dec 2018, Duy Nguyen wrote:
> > >
> > > > On Sat, Dec 8, 2018 at 5:08 PM Robert P. J. Day
> > > > wrote:
> >
On Sat, 8 Dec 2018, Duy Nguyen wrote:
> On Sat, Dec 8, 2018 at 6:32 PM Robert P. J. Day wrote:
> >
> > On Sat, 8 Dec 2018, Duy Nguyen wrote:
> >
> > > On Sat, Dec 8, 2018 at 5:08 PM Robert P. J. Day
> > > wrote:
> > > >
> > > >
> > > > from "man git-reset":
> > > >
> > > > SYNOPSIS
> > > >
On Sat, 8 Dec 2018, Duy Nguyen wrote:
> On Sat, Dec 8, 2018 at 6:32 PM Robert P. J. Day wrote:
> >
> > On Sat, 8 Dec 2018, Duy Nguyen wrote:
> >
> > > On Sat, Dec 8, 2018 at 5:08 PM Robert P. J. Day
> > > wrote:
> > > >
> > > >
> > > > from "man git-reset":
> > > >
> > > > SYNOPSIS
> > > >
On Sat, Dec 8, 2018 at 6:32 PM Robert P. J. Day wrote:
>
> On Sat, 8 Dec 2018, Duy Nguyen wrote:
>
> > On Sat, Dec 8, 2018 at 5:08 PM Robert P. J. Day
> > wrote:
> > >
> > >
> > > from "man git-reset":
> > >
> > > SYNOPSIS
> > > git reset [-q] [] [--] ...
> > > git reset (--patch | -p) []
On Sat, 8 Dec 2018, Duy Nguyen wrote:
> On Sat, Dec 8, 2018 at 5:08 PM Robert P. J. Day wrote:
> >
> >
> > from "man git-reset":
> >
> > SYNOPSIS
> > git reset [-q] [] [--] ...
> > git reset (--patch | -p) [] [--] [...]
> > git reset [--soft | --mixed [-N] | --hard | --merge | --keep]
On Sat, Dec 8, 2018 at 5:08 PM Robert P. J. Day wrote:
>
>
> from "man git-reset":
>
> SYNOPSIS
> git reset [-q] [] [--] ...
> git reset (--patch | -p) [] [--] [...]
> git reset [--soft | --mixed [-N] | --hard | --merge | --keep] [-q]
> []
>
> oddly, the third form says nothing about
On Sat, Dec 8, 2018 at 9:11 AM wrote:
> Changes since V2:
latest patch still fixes original issue - thanks
> - Settled on a better name:
> The common code is in compat/win32/path-utils.c/h
> [...]
> - The "DOS" moniker is still used for 2 reasons:
> Windows inherited the "drive letter"
On Sun, 2 Dec 2018, Duy Nguyen wrote:
> On Sun, Dec 2, 2018 at 6:05 PM Robert P. J. Day wrote:
> > > Patch update>> 2
> > > staged unstaged path
> > > * 1:unchanged+1/-0 README.md
> > > * 2:unchanged+1/-0 contrib/README
> > > 3:unchanged
On Sat, Dec 08 2018, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> On Fri, Dec 7, 2018 at 1:40 PM Jonathan Nieder wrote:
>>>
>>> Brandon Williams wrote:
>>>
>>> > Signed-off-by: Brandon Williams
>>> > ---
>>> > .mailmap | 1 +
>>> > 1 file changed, 1 insertion(+)
>>>
>>> I can confirm
On Sat, Dec 8, 2018 at 7:09 AM Junio C Hamano wrote:
> If this were "Jonathan asked Brandon if we want to record an address
> we can reach him in our .mailmap file and sent a patch to add one",
Not sure about Jonathan, but I did.
> then the story is different, and I tend to agree with you that
On Fri, Dec 07, 2018 at 01:50:57PM -0800, biswaranjan panda wrote:
> Thanks Jeff and Bryan! However, I am curious that if there were a way
> to tell git blame to skip a commit (the one which added the file again
> and maybe the one which deleted it originally) while it walks back
> through
On Fri, Dec 07, 2018 at 07:09:58PM -0500, George King wrote:
> My goal is to detect SGR color sequences, e.g. '\x1b[32m', that exist
> in the source text, and have my highlighter print escaped
> representations of those. For example, I have checked in files that
> are expected test outputs for
Stefan Beller writes:
> This re-introduces 984cd77ddb (submodule deinit: unset core.worktree,
> 2018-06-18), which was reverted as part of f178c13fda (Revert "Merge
> branch 'sb/submodule-core-worktree'", 2018-09-07)
>
> The whole series was reverted as the of
Stefan Beller writes:
> Shortly after f178c13fda (Revert "Merge branch
> 'sb/submodule-core-worktree'", 2018-09-07), we had another series
> that implemented partially the same, ensuring that core.worktree was
> set in a checked out submodule, namely 74d4731da1 (submodule--helper:
> replace
On Fri, Dec 7, 2018 at 10:08 PM Junio C Hamano wrote:
>
> Stefan Beller writes:
>
> > On Fri, Dec 7, 2018 at 1:40 PM Jonathan Nieder wrote:
> >>
> >> Brandon Williams wrote:
> >>
> >> > Signed-off-by: Brandon Williams
> >> > ---
> >> > .mailmap | 1 +
> >> > 1 file changed, 1 insertion(+)
>
ed as its followup commit was faulty, but without
> the accompanying change of the followup, we'd have an incomplete workflow
> of setting `core.worktree` again, when it is needed such as checking out
> a revision that contains a submodule.
>
> So re-introduce that commit as-is, focusing
Matthew DeVore writes:
> $ git -C pc1 fetch-pack --stdin "file://$(pwd)/srv.bare"
> Where observed.oids contains all the blobs that were missing. It tells
> the remote that it already has the "refs/heads/master" commit, which
> means it is excluded. Before, this worked fine, since it didn't
Stefan Beller writes:
> On Fri, Dec 7, 2018 at 1:40 PM Jonathan Nieder wrote:
>>
>> Brandon Williams wrote:
>>
>> > Signed-off-by: Brandon Williams
>> > ---
>> > .mailmap | 1 +
>> > 1 file changed, 1 insertion(+)
>>
>> I can confirm that this is indeed the same person.
>
> What would be more
Jonathan Nieder writes:
>> So it seems most sensible to me if this is going to be supported that we
>> go a bit beyond the call of duty and fake up the start of it, namely:
>>
>> --- a/arch/x86/kernel/process.c
>> +++ b/arch/x86/kernel/process.c
>>
>> To be:
>>
>> diff --git
> update'
> not working in old style repository setups.
>
> This series re-introduces those reverted patches, with no changes in code,
> but with drastically changed commit messages, as those focus on why it is safe
> to re-introduce them instead of explaining the desire for the
Jonathan Tan writes:
> When a user runs "git commit" without specifying a message, an editor
> appears with advice:
>
> Please enter the commit message for your changes. Lines starting
> with '#' will be ignored, and an empty message aborts the commit.
>
> However, if the user supplies
On Fri, 07 Dec 2018, Yaroslav Halchenko wrote:
> On Fri, 07 Dec 2018, Stefan Beller wrote:
> > > the initial "git submodule update --reset-hard" is pretty much a
> > > crude workaround for some of those cases, so I would just go earlier in
> > > the history, and redo some things, whenever I
On Fri, Dec 7, 2018 at 6:14 PM Josh Wolfe wrote:
>
> git version 2.19.1
> steps to reproduce:
>
> # start in a brand new repo
> git init
>
> # create lots of unreachable loose objects
> for i in {1..1}; do git commit-tree -m "$(head -c 12 /dev/urandom
> | base64)" "$(git mktree <&-)" <&-;
On Fri, 07 Dec 2018, Stefan Beller wrote:
> > the initial "git submodule update --reset-hard" is pretty much a
> > crude workaround for some of those cases, so I would just go earlier in
> > the history, and redo some things, whenever I could just drop or revert
> > some selected set of commits.
On Fri, Dec 7, 2018 at 11:04 AM wrote:
> The solution is to implement has_dos_drive_prefix(), skip_dos_drive_prefix()
> is_dir_sep(), offset_1st_component() and convert_slashes() for cygwin
> in the same way as it is done in 'Git for Windows' in compat/mingw.[ch]
>
> Instead of duplicating the
On Fri, Dec 7, 2018 at 7:45 PM Jonathan Nieder wrote:
>
>
> Thanks for fixing it. May we forge your sign-off?
Yes please, guess I didn't read far enough down that document. My apologies.
Consider the previous patch email:
Signed-off-by: FeRD (Frank Dana)
Hi,
Frank Dana wrote:
> The documentation for the feature 'snapshot' claimed
> "This feature can be configured on a per-repository basis via
> repository's `gitweb.blame` configuration variable"
>
> Fixed to specify `gitweb.snapshot` as the variable name.
> ---
> Documentation/gitweb.conf.txt |
Hi,
Jonathan Tan wrote:
> (The implementation in this commit reads the commit message twice even
> if there is no commit-msg hook. I think that this is fine, since this is
> for interactive use - an alternative would be to plumb information about
> the absence of the hook from run_hook_ve()
On Sun, Oct 21, 2018 at 7:21 PM Junio C Hamano wrote:
>
> Matthew DeVore writes:
>
> >> It is more like "this is a set operation across commits. We also
> >> show objects that are reachable from the commits in the resulting
> >> set and are not reachable from the commits in the set that were
>
William Hubbs wrote:
> On Thu, Dec 06, 2018 at 11:20:07PM +0100, Johannes Schindelin wrote:
>> There *is* a way to get what you want that is super easy and will
>> definitely work: if you sit down and do it ;-)
>>
>> Please let us know if you need any additional information before you can
>>
Ævar Arnfjörð Bjarmason wrote:
> On Fri, Dec 07 2018, Jonathan Nieder wrote:
>> The patch-id appears to only care about the diff text, so it should be
>> able to handle this. So if we have a better heuristic for where the
>> diff starts, it would be good to use it.
>
> No, the patch-id doesn't
On Fri, Dec 07 2018, Jonathan Nieder wrote:
> Hi,
>
> Konstantin Ryabitsev wrote:
>
>> Every now and again I come across a patch sent to LKML without a leading
>> "diff a/foo b/foo" -- usually produced by quilt. E.g.:
>>
>> https://lore.kernel.org/lkml/20181125185004.151077...@linutronix.de/
>>
Hi,
Stefan Beller wrote:
> What would be more of interest is why we'd be interested in this patch
> as there is no commit/patch sent by Brandon with this email in gits history.
I think there's an implicit assumption in this question that isn't
spelled out. Do I understand correctly that you're
Hi Johannes,
On Thu, Dec 06, 2018 at 11:20:07PM +0100, Johannes Schindelin wrote:
> Hi William,
>
>[...]
>
> There *is* a way to get what you want that is super easy and will
> definitely work: if you sit down and do it ;-)
>
> Please let us know if you need any additional information before
Hi Torsten,
On Fri, 7 Dec 2018, tbo...@web.de wrote:
> diff --git a/compat/mingw-cygwin.c b/compat/mingw-cygwin.c
> index 5552c3ac20..c379a72775 100644
> --- a/compat/mingw-cygwin.c
> +++ b/compat/mingw-cygwin.c
> @@ -10,10 +10,8 @@ size_t mingw_cygwin_skip_dos_drive_prefix(char **path)
>
On Fri, Dec 7, 2018 at 1:40 PM Jonathan Nieder wrote:
>
> Brandon Williams wrote:
>
> > Signed-off-by: Brandon Williams
> > ---
> > .mailmap | 1 +
> > 1 file changed, 1 insertion(+)
>
> I can confirm that this is indeed the same person.
What would be more of interest is why we'd be interested
Hi,
Konstantin Ryabitsev wrote:
> Every now and again I come across a patch sent to LKML without a leading
> "diff a/foo b/foo" -- usually produced by quilt. E.g.:
>
> https://lore.kernel.org/lkml/20181125185004.151077...@linutronix.de/
>
> I am guessing quilt does not bother including the
On Thu, Dec 6, 2018 at 5:23 PM Yaroslav Halchenko wrote:
> > There was a proposal to "re-attach HEAD" in the submodule, i.e.
> > if the branch branch points at the same commit, we don't need
> > a detached HEAD, but could go with the branch instead.
>
> if I got
Hi Torsten,
On Fri, 7 Dec 2018, tbo...@web.de wrote:
> compat/mingw-cygwin.c | 28
> compat/mingw-cygwin.h | 20
Please use compat/win32/path.c (or .../path-utils.c) instead. This is not
so much about MINGW or Cygwin or MSys or MSYS2 or Visual
On Thu, Dec 6, 2018 at 11:26 PM Jeff King wrote:
>>
>> On Thu, Dec 06, 2018 at 11:07:00PM -0800, biswaranjan panda wrote:
>>
> >> Thanks! Strangely git log --follow does work.
>>
>> I suspect it would work even without --follow. When you limit a log
>> traversal with a pathspec, like:
>>
>> git
Brandon Williams wrote:
> Signed-off-by: Brandon Williams
> ---
> .mailmap | 1 +
> 1 file changed, 1 insertion(+)
I can confirm that this is indeed the same person.
Reviewed-by: Jonathan Nieder
Welcome back!
On Fri, Dec 07 2018, Konstantin Ryabitsev wrote:
> Hi, all:
>
> Every now and again I come across a patch sent to LKML without a leading
> "diff a/foo b/foo" -- usually produced by quilt. E.g.:
>
> https://lore.kernel.org/lkml/20181125185004.151077...@linutronix.de/
>
> I am guessing quilt does
On Fri, Dec 7, 2018 at 9:51 AM Johannes Sixt wrote:
>
> From: Elijah Newren
>
> In commit 6aba117d5cf7 ("am: avoid directory rename detection when
> calling recursive merge machinery", 2018-08-29), the git-rebase manpage
> probably should have also been updated to note the stronger
>
On 12/6/2018 6:36 PM, Jonathan Tan wrote:
AFAICT oid_object_info doesn't take advantage of the commit graph,
but just looks up the object header, which is still less than completely
parsing it. Then lookup_commit is overly strict, as it may return
NULL as when there still is a type mismatch (I
On 12/6/2018 3:20 PM, Josh Steadmon wrote:
+
+# usage: corrupt_and_zero_graph_then_verify
+# Manipulates the commit-graph file at by inserting the
data,
+# then zeros the file starting at . Finally, runs
+# 'git commit-graph verify' and places the output in the file 'err'. Tests
'err'
+#
Am Fr., 7. Dez. 2018 um 13:45 Uhr schrieb Eric Sunshine
:
>
> On Fri, Dec 7, 2018 at 7:36 AM Victor Toni wrote:
> > I'm wondering if there is any way to show which rules (ideally with
> > the .gitignore file they are coming from) are causing a specific file
> > to get ignored so I could easily
On Fri, Dec 7, 2018 at 7:36 AM Victor Toni wrote:
> I'm wondering if there is any way to show which rules (ideally with
> the .gitignore file they are coming from) are causing a specific file
> to get ignored so I could easily fix the .gitignore file?
Perhaps the "git check-ignore" command would
On Thu, Dec 06, 2018 at 12:20:54PM -0800, Josh Steadmon wrote:
> diff --git a/commit-graph.c b/commit-graph.c
> index 07dd410f3c..224a5f161e 100644
> --- a/commit-graph.c
> +++ b/commit-graph.c
> @@ -165,10 +165,20 @@ struct commit_graph *parse_commit_graph(void
> *graph_map, int fd,
>
On Thu, Dec 06, 2018 at 03:54:46PM -0800, Jonathan Tan wrote:
> This makes sense - I thought I shouldn't mention the commit graph in the
> code since it seems like a layering violation, but I felt the need to
> mention commit graph in a comment, so maybe the need to mention commit
> graph in the
On Thu, Dec 6, 2018 at 11:26 PM Jeff King wrote:
>
> On Thu, Dec 06, 2018 at 11:07:00PM -0800, biswaranjan panda wrote:
>
> > Thanks! Strangely git log --follow does work.
>
> I suspect it would work even without --follow. When you limit a log
> traversal with a pathspec, like:
>
> git log foo
On Thu, Dec 06, 2018 at 11:07:00PM -0800, biswaranjan panda wrote:
> Thanks! Strangely git log --follow does work.
I suspect it would work even without --follow. When you limit a log
traversal with a pathspec, like:
git log foo
that is not about following some continuous stream of content,
Thanks! Strangely git log --follow does work.
On Thu, Dec 6, 2018 at 10:55 PM Bryan Turner wrote:
>
> On Thu, Dec 6, 2018 at 10:49 PM biswaranjan panda
> wrote:
> >
> > I have the following scenario:
> >
> > On a branch A, I deleted a file foo.txt and committed the change. Then
> > I did a bunch
On Thu, Dec 6, 2018 at 10:49 PM biswaranjan panda
wrote:
>
> I have the following scenario:
>
> On a branch A, I deleted a file foo.txt and committed the change. Then
> I did a bunch of other changes.
> Now I want to undelete foo.txt.
>
> One way is to checkout a separate branch B where the file
nistic.
yeap, makes total sense to be the thing do that by default ;-)
> There was a proposal to "re-attach HEAD" in the submodule, i.e.
> if the branch branch points at the same commit, we don't need
> a detached HEAD, but could go with the branch instead.
if I got the idea right, if we a
On Fri, Dec 07, 2018 at 12:10:05AM +0100, SZEDER Gábor wrote:
> On Wed, Dec 05, 2018 at 04:56:21PM -0500, Jeff King wrote:
> > Could we just kill them all?
> >
> > I guess it's a little tricky, because $! is going to give us the pid of
> > each subshell. We actually want to kill the test
On Thu, Dec 06, 2018 at 11:56:01PM +0100, SZEDER Gábor wrote:
> > +test_expect_success 'roll those dice' '
> > + case "$(openssl rand -base64 1)" in
> > + z*)
> > + return 1
> > + esac
> > +'
>
> Wasteful :)
>
> test $(($$ % 42)) -ne 0
Oh, indeed, that is much more clever. :)
On 2018.11.28 16:27, Stefan Beller wrote:
> This is a resend of sb/submodule-recursive-fetch-gets-the-tip,
> with all feedback addressed. As it took some time, I'll send it
> without range-diff, but would ask for full review.
>
> I plan on resending after the next release as this got delayed
Jonathan Tan writes:
>> Jonathan Tan writes:
>>
>> > @@ -126,6 +129,12 @@ static int read_pack_objects_stdout(int outfd, struct
>> > output_state *os)
>> >}
>> >os->used += readsz;
>> >
>> > + if (!os->packfile_started) {
>> > + os->packfile_started = 1;
>> > + if
Konstantin Khomoutov writes:
>> I do not see why the "name each rev relative to HEAD" formatting
>> option cannot produce HEAD^2~2 etc.
>> ...
> My reading was that the OP explicitly wanted to just glance at a single
> integer number and use it right away in a subsequent rebase command.
>
> I
Also CC-ing Stolee since I mention multi-pack indices at the end.
> This seems like a reasonable thing to do, but I have sort of a
> meta-comment. In several places we've started doing this kind of "if
> it's this type of object, do X, otherwise do Y" optimization (e.g.,
> handling large blobs
> > This is on sb/more-repo-in-api because I'm using the repo_parse_commit()
> > function.
>
> This is a mere nicety, not strictly required.
> Before we had parse_commit(struct commit *) which would accomplish the
> same, (and we'd still have that afterwards as a #define falling back onto
>
> Jonathan Tan writes:
>
> > @@ -126,6 +129,12 @@ static int read_pack_objects_stdout(int outfd, struct
> > output_state *os)
> > }
> > os->used += readsz;
> >
> > + if (!os->packfile_started) {
> > + os->packfile_started = 1;
> > + if (use_protocol_v2)
> > +
> > +This feature allows servers to serve part of their packfile response as
> > URIs.
> > +This allows server designs that improve scalability in bandwidth and CPU
> > usage
> > +(for example, by serving some data through a CDN), and (in the future)
> > provides
> > +some measure of
On Wed, Dec 05, 2018 at 04:56:21PM -0500, Jeff King wrote:
> Could we just kill them all?
>
> I guess it's a little tricky, because $! is going to give us the pid of
> each subshell. We actually want to kill the test sub-process. That takes
> a few contortions, but the output is nice (every
On Thu, Dec 6, 2018 at 6:30 PM Lukáš Krejčí wrote:
>
> I am talking about `git bisect replay`. The shell script, as far as I
> can see, only updates the references (ref/bisect/*) and never checks if
> the revisions marked as 'good' are ancestors of the 'bad' one.
> Therefore,
Johannes,
Thanks for your feedback.
I'm not looking closely at submodules, as it's my understanding that
VFSForGit does not support them. A VFS would be a killer feature for us.
If VFSForGit were to support submodules, we'd look at them. They would
provide access control in a way that's
On Wed, Dec 05, 2018 at 04:36:26PM -0500, Jeff King wrote:
> The signal interrupts the first wait.
Ah, of course. I'm ashamed to say that this is not the first time I
forget about that...
> > Bash 4.3 or later are strange: I get back the shell prompt immediately
> > after ctrl-C as well, so it
> > The git command line expects Git servers to follow a specific order of
>
> "Command line"? It sounds like you are talking about the order of
> command line arguments and options, but apparently that is not what
> you are doing. Is it "The git over-the-wire protocol"?
I meant to say the
Hi William,
On Thu, 6 Dec 2018, William Hubbs wrote:
> On Thu, Dec 06, 2018 at 07:38:08PM +0100, Martin Ågren wrote:
> > Hi William,
> >
> > [...]
> >
> > This idea was floated a couple of months ago [1]. Junio seemed to find
> > the request sensible and outlined a design. No patches
On Thu, Dec 6, 2018 at 12:09 PM Johannes Schindelin
wrote:
>
> Hi,
>
> On Wed, 5 Dec 2018, Jeff King wrote:
>
> > The model that fits more naturally with how Git is implemented would be
> > to use submodules. There you leak the hash of the commit from the
> > private submodule, but that's
Hello, Jeff.
So, this is what I currently have. It still does the same thing but a
lot more generic in terms of both interface and implementation.
* All core logics are implemented as core helpers / features.
* Trailer parsing and reverse-mapping in trailer_rev_xrefs_*().
* Note refs
On Tue, Dec 4, 2018 at 7:10 PM Junio C Hamano wrote:
>
> Stefan Beller writes:
>
> > This is a resend of sb/submodule-recursive-fetch-gets-the-tip,
> > with all feedback addressed. As it took some time, I'll send it
> > without range-diff, but would ask for full review.
>
> Is that a "resend" or
Right.
git reset --hard would the branch (as well as the working tree) to the
given sha1, which is confusing as submodules get involved.
The Right Thing as of now is the sha1 as found in the
superprojects gitlink. But as that can be different from any branch
in the submodule, we'd rather detach the
On Thu, 06 Dec 2018, Stefan Beller wrote:
> On Thu, Dec 6, 2018 at 10:02 AM Yaroslav Halchenko
> wrote:
> > Dear Git Gurus,
> > I wondered what would be your take on my wishlist request to add
> > --reset-hard option, which would be very similar to regular "update" which
> > checks out
Hi,
On Wed, 5 Dec 2018, Jeff King wrote:
> The model that fits more naturally with how Git is implemented would be
> to use submodules. There you leak the hash of the commit from the
> private submodule, but that's probably obscure enough (and if you're
> really worried, you can add a random
On Thu, Dec 06, 2018 at 07:38:08PM +0100, Martin Ågren wrote:
> Hi William,
>
> [...]
>
> This idea was floated a couple of months ago [1]. Junio seemed to find
> the request sensible and outlined a design. No patches materialized, as
> far as I know, but that could be because Eric suggested a
ng directory and the repository has LF line endings.
> This variable can be set to 'input',
> in which case no output conversion is performed.
Argh... crap. I was missing that I have to set the "text" attribute
manually...
Thats why core.eol=crlf didn't make a
On Tue, Nov 27, 2018 at 1:56 PM Jacob Keller wrote:
> Personally, I would rather err on the side which requires the least
> interaction from users to avoid silently clobbering an ignored file.
>
> Either Duy's solution with a sort of "untracked" reflog, or the
> garbage/trashable notion.
The
Hi William,
On Thu, 6 Dec 2018 at 19:18, William Hubbs wrote:
> We are in a situation where we would like to use author information that is
> different from committer information when we commit to certain
> repositories.
[...]
> [...] I would like to propose the addition of author.email and
>
On Thu, Dec 6, 2018 at 10:02 AM Yaroslav Halchenko wrote:
>
> Dear Git Gurus,
>
> I wondered what would be your take on my wishlist request to add
> --reset-hard option, which would be very similar to regular "update" which
> checks out necessary commit, but I want it to remain in the branch.
On Thu, Dec 6, 2018 at 6:58 AM Phillip Wood wrote:
> > So is there some "must be at least two consecutive lines" condition for
> > not-plain, or is something else going on here?
>
> To be considered a block has to have 20 alphanumeric characters - see
> commit f0b8fb6e59 ("diff: define block by
On Thu, 2018-12-06 at 17:31 +0100, Christian Couder wrote:
> > When Git replays the bisect log, it only updates refs/bisect/bad,
> > refs/bisect/good-*, refs/bisect/skip-* and reconstructs the log in
> > .git/BISECT_LOG. After that check_good_are_ancestors_of_bad() verifies
> > that all good
Hi,
On Thu, Dec 6, 2018 at 3:43 PM Lukáš Krejčí wrote:
>
> Hello again,
>
> after looking into this today, I'm not sure if this can be considered a
> bug - it's just that I expected Git to check out the exact commit to
> test that was there before resetting the bisect. That made me uncertain
>
Hello!
> Yeah, it does look indirect. Despite what you said, it also would
> support users giving an absolute path via GITWEB_CONFIG.
>
> With "use File::Spec", perhaps something like this?
Yes, this looks right.
Martin
Hi Ævar
On 06/12/2018 13:54, Ævar Arnfjörð Bjarmason wrote:
Let's ignore how bad this patch is for git.git, and just focus on how
diff.colorMoved treats it:
diff --git a/builtin/add.c b/builtin/add.c
index f65c172299..d1155322ef 100644
--- a/builtin/add.c
+++
Hello again,
after looking into this today, I'm not sure if this can be considered a
bug - it's just that I expected Git to check out the exact commit to
test that was there before resetting the bisect. That made me uncertain
whether Git restored the correct state.
When I looked at what Git
On 12/5/2018 5:32 PM, Josh Steadmon wrote:
+ if (chunk_lookup + GRAPH_CHUNKLOOKUP_WIDTH > data + graph_size) {
+ error(_("chunk lookup table entry missing; graph file may be
incomplete"));
+ free(graph);
+ return NULL;
+
Hi,
thanks for your great work! Just two remarks:
#: midx.c:407
-#, fuzzy, c-format
+#, c-format
msgid "failed to add packfile '%s'"
-msgstr "Fehler beim Lesen der Reihenfolgedatei '%s'."
+msgstr "Fehler beim Hinzufügen von Packdatei'%s'."
A Space is missing: "Fehler beim Hinzufügen von
On Thu, Dec 06, 2018 at 09:31:36AM +0900, Junio C Hamano wrote:
> >> It would be great if git-log has a formatting option to insert an
> >> index of the current commit since HEAD.
> >>
> >> It would allow after quitting the git-log to immediately fire up "git
> >> rebase -i HEAD~index" instead
On Thu, Dec 06, 2018 at 10:17:24AM +0100, Ævar Arnfjörð Bjarmason wrote:
> > The other major user of that feature I can think of is LFS. There Git
> > ends up diffing the LFS pointers, not the big files. Which arguably is
> > the wrong thing (you'd prefer to see the actual file contents diffed),
On Thu, Dec 06 2018, Jeff King wrote:
> On Thu, Dec 06, 2018 at 10:08:57AM +0900, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>> > In my opinion this feature is so contrary to Git's general assumptions
>> > that it's likely to create a ton of information leaks of the supposedly
>> >
On Wed, Dec 05, 2018 at 11:42:09PM +, Coiner, John wrote:
> > For instance, Git is very eager to try to find delta-compression
> > opportunities between objects, even if they don't have any relationship
> > within the tree structure. So imagine I want to know the contents of
> > tree X. I
On Thu, Dec 06, 2018 at 10:08:57AM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > In my opinion this feature is so contrary to Git's general assumptions
> > that it's likely to create a ton of information leaks of the supposedly
> > protected data.
> > ...
>
> Yup, with
Jeff King writes:
> Each "wait" will try to collect all processes, but may be interrupted by
> a signal. So the correct number is actually "1 plus the number of times
> the user hits ^C".
Yeah and that is not bounded. It is OK not to catch multiple ^C
that races with what we do, so having ane
Jonathan Tan writes:
> @@ -126,6 +129,12 @@ static int read_pack_objects_stdout(int outfd, struct
> output_state *os)
> }
> os->used += readsz;
>
> + if (!os->packfile_started) {
> + os->packfile_started = 1;
> + if (use_protocol_v2)
> +
On Thu, Dec 06, 2018 at 09:22:23AM +0900, Junio C Hamano wrote:
> > So the right number of waits is either "1" or "2". Looping means we do
> > too many (which is mostly a harmless noop) or too few (in the off chance
> > that you have only a single job ;) ). So it works out in practice.
>
> Well,
Josh Steadmon writes:
> diff --git a/fuzz-commit-graph.c b/fuzz-commit-graph.c
> new file mode 100644
> index 00..420851d0d2
> --- /dev/null
> +++ b/fuzz-commit-graph.c
> @@ -0,0 +1,18 @@
> +#include "object-store.h"
> +#include "commit-graph.h"
> +
> +struct commit_graph
Junio C Hamano writes:
>> +if (graph_size < GRAPH_MIN_SIZE)
>> +return NULL;
>> +
>
> The load_commit_graph_one() grabbed graph_map out of xmmap() so it
> is guaranteed to be non-NULL, but we need to check graph_map != NULL
> when we're calling this directly from the fuzz tests,
Josh Steadmon writes:
> @@ -108,27 +106,61 @@ struct commit_graph *load_commit_graph_one(const char
> *graph_file)
> die(_("graph file %s is too small"), graph_file);
> }
> graph_map = xmmap(NULL, graph_size, PROT_READ, MAP_PRIVATE, fd, 0);
> + ret =
Matthew DeVore writes:
> When a command is invoked with both --exclude-promisor-objects,
> --objects-edge-aggressive, and a missing object on the command line,
> the rev_info.cmdline array could get a NULL pointer for the value of
> an 'item' field. Prevent dereferencing of a NULL pointer in
1 - 100 of 100371 matches
Mail list logo
