Olaf Hering wrote:
> On Tue, Feb 14, Olaf Hering wrote:
>
> > How would I debug it?
>
> One line is supposed to be longer than 998 chars, but something along
> the way truncated it and corrupted the patch.
998 sounds like the SMTP limit.
Perhaps git format-patch should emit binary diffs in tha
On Mon, Feb 20, 2017 at 12:10:15AM +, brian m. carlson wrote:
> /* Diff one or more commits. */
> -static int stdin_diff_commit(struct commit *commit, char *line, int len)
> +static int stdin_diff_commit(struct commit *commit, const char *p)
> {
> - unsigned char sha1[20];
> - if (is
Thomas Gummerer writes:
> @@ -55,10 +53,13 @@ push [-p|--patch] [-k|--[no-]keep-index]
> [-u|--include-untracked] [-a|--all] [-q
>
> Save your local modifications to a new 'stash', and run `git reset
> --hard` to revert them. The part is optional and gives
I didn't notice this d
On Sun, Feb 19, 2017 at 10:12:28PM +0100, Toolforger wrote:
> I am trying to make url..insteadOf work on the URLs inside
> .gitmodules, but it won't work (applying it to the repo itself works fine,
> to the config setting seems to be fine).
The submodule operations happen in their own processes,
Jeff King writes:
> On Sun, Feb 19, 2017 at 11:32:32PM +0100, Damien Regad wrote:
>
>> Use of 'iff' may be confusing to people not familiar with this term.
>>
>> Improving the --normalize option's documentation to remove the use of
>> 'iff', and clearly describe what happens when the condition i
Hello, I work with a private security vault firm. I will be happy to discuss a
very important proposal with you.
Kindly reply if you are interested for further details.
Regards,
Darren
Christian Couder writes:
> git bisect makes some assumptions that are true most of the time, so
> in practice it works well most of the time.
I think we need to clarify the documentation and ask you to stop
using such fuzzy phrases like "assumptions" and "most of the time"
;-).
For bisection to
Junio C Hamano writes:
> I still haven't queued any of the variants I posted (and I do not
> think other people sent their own versions, either). I need to pick
> one and queue, with a test or two. Perhaps after -rc2.
>
> Others are welcome to work on it while I cut -rc2 tomorrow, so that
> b
Hi Josh,
On Mon, 6 Feb 2017, Johannes Schindelin wrote:
> as discussed at the GitMerge, I am trying to come up with tooling that
> will allow for substantially less tedious navigation between the local
> repository, the mailing list, and what ends up in the `pu` branch.
I found a little bit more
On 02/16/2017 12:48 PM, Nguyễn Thái Ngọc Duy wrote:
> This centralizes all path rewriting of files-backend.c in one place so
> we have easier time removing the path rewriting later. There could be
> some hidden indirect git_path() though, I didn't audit the code to the
> bottom.
Almost all of the
On 02/18/2017 02:32 PM, Nguyễn Thái Ngọc Duy wrote:
> Given $GIT_DIR and $GIT_COMMON_DIR, files-backend is now in charge of
> deciding what goes where. The end goal is to pass $GIT_DIR only. A
> refs "view" of a linked worktree is a logical ref store that combines
> two files backends together.
>
Adding comments after a tag in the body is a common practise (e.g. in
the Linux kernel) and git-send-email has been supporting this for years
by removing any trailing cruft after the address.
After some recent changes, any trailing comment is now instead appended
to the recipient name (with some r
Johan Hovold writes:
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -1563,7 +1563,7 @@ foreach my $t (@files) {
> # Now parse the message body
> while(<$fh>) {
> $message .= $_;
> - if (/^(Signed-off-by|Cc): (.*)$/i) {
> + if (/^(Si
On 02/18/2017 02:33 PM, Nguyễn Thái Ngọc Duy wrote:
> Since submodule or not is irrelevant to files-backend after the last
> patch, remove the parameter from files_downcast() and kill
> files_assert_main_repository().
>
> PS. This implies that all ref operations are allowed for submodules. But
> w
On Mon, Feb 20, 2017 at 7:11 PM, Michael Haggerty wrote:
> On 02/18/2017 02:33 PM, Nguyễn Thái Ngọc Duy wrote:
>> Since submodule or not is irrelevant to files-backend after the last
>> patch, remove the parameter from files_downcast() and kill
>> files_assert_main_repository().
>>
>> PS. This imp
On Mon, Feb 20, 2017 at 6:23 PM, Michael Haggerty wrote:
> On 02/16/2017 12:48 PM, Nguyễn Thái Ngọc Duy wrote:
>> This centralizes all path rewriting of files-backend.c in one place so
>> we have easier time removing the path rewriting later. There could be
>> some hidden indirect git_path() thoug
W dniu 20.02.2017 o 08:38, Oleg Taranenko pisze:
Then you must adjust your definition of "good": All commits that do not
have
the feature, yet, are "good": since they do not have the feature in the
first place, they cannot have the breakage that you found in the feature.
On 02/20/2017 01:21 PM, Duy Nguyen wrote:
> On Mon, Feb 20, 2017 at 7:11 PM, Michael Haggerty
> wrote:
>> On 02/18/2017 02:33 PM, Nguyễn Thái Ngọc Duy wrote:
>>> Since submodule or not is irrelevant to files-backend after the last
>>> patch, remove the parameter from files_downcast() and kill
>>>
On Mon, Feb 20, 2017 at 6:34 PM, Michael Haggerty wrote:
> On 02/18/2017 02:32 PM, Nguyễn Thái Ngọc Duy wrote:
>> Given $GIT_DIR and $GIT_COMMON_DIR, files-backend is now in charge of
>> deciding what goes where. The end goal is to pass $GIT_DIR only. A
>> refs "view" of a linked worktree is a log
On Mon, Feb 20, 2017 at 7:30 PM, Michael Haggerty wrote:
> On 02/20/2017 01:21 PM, Duy Nguyen wrote:
>> On Mon, Feb 20, 2017 at 7:11 PM, Michael Haggerty
>> wrote:
>>> On 02/18/2017 02:33 PM, Nguyễn Thái Ngọc Duy wrote:
Since submodule or not is irrelevant to files-backend after the last
>>
On 02/20/2017 01:33 PM, Duy Nguyen wrote:
> On Mon, Feb 20, 2017 at 7:30 PM, Michael Haggerty
> wrote:
>> On 02/20/2017 01:21 PM, Duy Nguyen wrote:
>>> On Mon, Feb 20, 2017 at 7:11 PM, Michael Haggerty
>>> wrote:
[...]
These limitations, I think, imply that submodule references have t
On 02/18/2017 02:32 PM, Nguyễn Thái Ngọc Duy wrote:
> get_ref_store() will soon be renamed to get_submodule_ref_store().
> Together with future get_worktree_ref_store(), the three functions
> provide an appropriate ref store for different operation modes. New APIs
> will be added to operate directl
Hey, you lovely people <3
Every once in a while this:
£ git add -p .
warning: empty strings as pathspecs will be made invalid in upcoming
releases. please use . instead if you meant to match all paths
No changes.
It seems to happen only when there are no more modified files and git
still works w
Hi Junio,
On Fri, 17 Feb 2017, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > diff --git a/hashmap.c b/hashmap.c
> > index b10b642229c..061b7d61da6 100644
> > --- a/hashmap.c
> > +++ b/hashmap.c
> > @@ -50,6 +50,20 @@ unsigned int memihash(const void *buf, size_t len)
> > return
On 02/18/2017 02:32 PM, Nguyễn Thái Ngọc Duy wrote:
> v4:
I very much like the direction of this patch series. I reviewed the
design pretty carefully and left some comments about it, and skimmed
through the code changes. But I haven't yet reviewed the code in detail.
I'll wait for your reaction to
On Mon, Feb 20, 2017 at 7:42 PM, Michael Haggerty wrote:
> On 02/18/2017 02:32 PM, Nguyễn Thái Ngọc Duy wrote:
>> v4:
>
> I very much like the direction of this patch series. I reviewed the
> design pretty carefully and left some comments about it, and skimmed
> through the code changes. But I hav
> Anyway, I don't think it is feasible to weaken the assumption that there
> is only one transition from 'old' ('good') to 'new' ('bad'); this is
> what allows O(log(N)) operations. See bisection method of root finding,
> that is finding zeros of a continuous function.
I don't intended to change
On 17 February 2017 at 00:38, Junio C Hamano wrote:
> Having said all that, I do not think the remainder of the code is
> prepared to take "-", not yet anyway [*1*], so turning "-" into
> "@{-1}" this patch does before it calls get_sha1_basic(), while it
> is not an ideal final state, is probably
On Friday 17 February 2017 at 22:19:58 +, Mike Crowe wrote:
> On Friday 17 February 2017 at 14:05:17 -0800, Junio C Hamano wrote:
> > Mike Crowe writes:
> >
> > > If "git diff --quiet" finds it necessary to compare actual file contents,
> > > and a file requires CRLF conversion, then it incor
> On 20 Feb 2017, at 10:58, Junio C Hamano wrote:
>
> Junio C Hamano writes:
>
>> I still haven't queued any of the variants I posted (and I do not
>> think other people sent their own versions, either). I need to pick
>> one and queue, with a test or two. Perhaps after -rc2.
>>
>> Others
Hi Folks!
The issue is best explained on an example. You can reproduce it using the
Lucene repo https://github.com/apache/lucene-solr.git. Tested with the
following versions: 1.8.1.6 (Ubuntu), 2.11.0.windows.1, 2.11.1.windows.1.
First, let's produce the correct results without using --procelai
Hi,
It would be handy to be able to show a message to the user when
cloning/fetching from a repository (e.g. to show a warning if a
repository is deprecated). This should technically already be possible
using the current pack protocol and sidebands. However, to my knowledge,
there is no easy way t
On Mon, Feb 20, 2017 at 07:38:02PM +0100, Lukas Fleischer wrote:
> It would be handy to be able to show a message to the user when
> cloning/fetching from a repository (e.g. to show a warning if a
> repository is deprecated). This should technically already be possible
> using the current pack pro
Johannes Schindelin writes:
> There is a third category, and this one *does* come as a surprise to me.
> It appears that at least *some* patches' Date: lines are either ignored or
> overridden or changed on their way from the mailing list into Git's commit
> history. There was only one commit in
Thomas Gummerer writes:
> @@ -55,10 +53,13 @@ push [-p|--patch] [-k|--[no-]keep-index]
> [-u|--include-untracked] [-a|--all] [-q
>
> Save your local modifications to a new 'stash', and run `git reset
> --hard` to revert them. The part is optional and gives
I didn't notice this d
Junio C Hamano writes:
> Johannes Schindelin writes:
>
>> There is a third category, and this one *does* come as a surprise to me.
>> It appears that at least *some* patches' Date: lines are either ignored or
>> overridden or changed on their way from the mailing list into Git's commit
>> histor
Leon George writes:
> Every once in a while this:
>
> £ git add -p .
> warning: empty strings as pathspecs will be made invalid in upcoming
> releases. please use . instead if you meant to match all paths
> No changes.
>
> It seems to happen only when there are no more modified files and git
> st
Johannes Schindelin writes:
>> If an extra call level really matters, its "inline" equivalent in
>> the header would probably be good.
>
> Well, the hashing is supposed to be as fast as possible, so I would like
> to avoid that extra call level. However, the end result is not so pretty
> because
Siddharth Kannan writes:
> On 17 February 2017 at 00:38, Junio C Hamano wrote:
>> Having said all that, I do not think the remainder of the code is
>> prepared to take "-", not yet anyway [*1*], so turning "-" into
>> "@{-1}" this patch does before it calls get_sha1_basic(), while it
>> is not a
I see two different problems each with a different assumption (see the
definition of "bisectable" in the email of Junio C Hamano):
1. (Current) Assume the entire history graph is bisectable. DO: Search
where in the entire graph the first 'trait'/transition occurs.
2. (New) Assume only the graph be
On 20.02.2017 10:01, Jeff King wrote:
On Sun, Feb 19, 2017 at 10:12:28PM +0100, Toolforger wrote:
I am trying to make url..insteadOf work on the URLs inside
.gitmodules, but it won't work (applying it to the repo itself works fine,
to the config setting seems to be fine).
The submodule operat
W dniu 20.02.2017 o 21:31, Alex Hoffman pisze:
> I see two different problems each with a different assumption (see the
> definition of "bisectable" in the email of Junio C Hamano):
>
> 1. (Current) Assume the entire history graph is bisectable. DO: Search
> where in the entire graph the first 'tr
> If `git bisect` is/would be affected by `git log` history-related options
> then this is what `--strict-ancestor` option gives/would give.
Exactly my thoughts. All that needs to be changed in the 2nd problem
is the graph where to search.
But first we must agree about the usefulness of the 2nd p
On Mon, Feb 20, 2017 at 09:31:40PM +0100, Toolforger wrote:
> > The submodule operations happen in their own processes, and do not look
> > at the config of the parent repo.
>
> Ah, then we have a docbug.
> git help config has this to say:
>
> url..insteadOf
> Any URL that starts with this v
Mike Crowe writes:
> I think that if there's a risk that file contents will undergo conversion
> then this should force the diff to check the file contents. Something like:
>
> diff --git a/diff.c b/diff.c
> index 051761b..bee1662 100644
> --- a/diff.c
> +++ b/diff.c
> @@ -3413,13 +3413,14 @@ voi
"Sokolov, Konstantin" writes:
> However, when using --porcelain DirectoryReader.java is reported as the
> origin of lines 502-504:
> ...
> This is not only inconsistent with the other outputs but the output is also
> inconsistent in itself because lines 496 -498 do not even exist in a previous
Do you need a loan to pay up bill or to start a business? Email Us
On Mon, Feb 20, 2017 at 01:30:29PM -0800, Junio C Hamano wrote:
> "Sokolov, Konstantin" writes:
>
> > However, when using --porcelain DirectoryReader.java is reported as the
> > origin of lines 502-504:
> > ...
> > This is not only inconsistent with the other outputs but the output is also
> >
From: "Jakub Narębski"
W dniu 20.02.2017 o 21:31, Alex Hoffman pisze:
I see two different problems each with a different assumption (see the
definition of "bisectable" in the email of Junio C Hamano):
1. (Current) Assume the entire history graph is bisectable. DO: Search
where in the entire gr
On Mon, Feb 20, 2017 at 03:09:02AM -0500, Jeff King wrote:
> It's a little disturbing that we do not seem to have even a basic test
> of:
>
> git rev-list --parents HEAD | git diff-tree --stdin
>
> which would exercise this code.
I'm unsure, so I'll add a test. The only way to know if it work
On Tue, Feb 21, 2017 at 12:25:19AM +, brian m. carlson wrote:
> On Mon, Feb 20, 2017 at 03:09:02AM -0500, Jeff King wrote:
> > It's a little disturbing that we do not seem to have even a basic test
> > of:
> >
> > git rev-list --parents HEAD | git diff-tree --stdin
> >
> > which would exer
Renaming the current branch adds an event to the current branch's log
and to HEAD's log. However, the logged entries differ. The entry in
the branch's log represents the entire renaming operation (the old and
new hash are identical), whereas the entry in HEAD's log represents
the deletion only (t
Now that delete_ref() accepts a reflog message, pass the user-provided
message to delete_ref() rather than silently dropping it.
Signed-off-by: Kyle Meyer
---
builtin/update-ref.c | 2 +-
t/t1400-update-ref.sh | 18 ++
2 files changed, 19 insertions(+), 1 deletion(-)
diff --gi
Thanks to Junio and Peff for their feedback on v1.
https://public-inbox.org/git/20170217035800.13214-1-k...@kyleam.com/T/#u
Changes from v1:
* "msg" is now positioned as the first argument to delete_ref() to
match update_ref().
20170217081205.zn7j6d5cffgdv...@sigill.intra.peff.net
*
When the current branch is renamed, the deletion of the old ref is
recorded in HEAD's log with an empty message. Now that delete_ref()
accepts a reflog message, provide a more descriptive message by
passing along the log message that is given to rename_ref().
The next step will be to extend HEAD'
When the current branch is renamed with 'git branch -m/-M' or deleted
with 'git update-ref -m -d', the event is recorded in HEAD's log
with an empty message. In preparation for adding a more meaningful
message to HEAD's log in these cases, update delete_ref() to take a
message argument and pass it
On Mon, Feb 20, 2017 at 08:08:36PM -0500, Jeff King wrote:
> On Tue, Feb 21, 2017 at 12:25:19AM +, brian m. carlson wrote:
>
> > On Mon, Feb 20, 2017 at 03:09:02AM -0500, Jeff King wrote:
> > > It's a little disturbing that we do not seem to have even a basic test
> > > of:
> > >
> > > git
Hello
and thank you for your time.
On 20/02/17 21:19, Junio C Hamano wrote:
> This sounds vaguely familiar and indeed I think it is this one:
> https://public-inbox.org/git/CAEnOLdvG=sokfxej_plmamgj_8osc+28tsg+pbflltr+zlc...@mail.gmail.com/
> which was from late last year.
Which means I should hav
Leon George writes:
> On 20/02/17 21:19, Junio C Hamano wrote:
>> This sounds vaguely familiar and indeed I think it is this one:
>> https://public-inbox.org/git/CAEnOLdvG=sokfxej_plmamgj_8osc+28tsg+pbflltr+zlc...@mail.gmail.com/
>> which was from late last year.
> Which means I should have found
I'm using git svn with a project that uses SubWCRev.exe to incorporate the SVN
revision into the build number.
I've updated it to use 'git svn find-rev HEAD' in git svn usage, to achieve the
same effect.
This works until I have a local commit that hasn't yet been pushed to SVN with
'git svn dc
Junio: ping?
https://public-inbox.org/git/20161223014202.GA8327@starla/raw
Thanks.
On 20.02.2017 21:52, Jeff King wrote:
> I think if there is a doc bug, it is that the repo boundary between the
> submodule and the super-project is not made more clear.
It's not mentioned anywhere I'm aware of, particularly not on the
insteadOf docs.
> That said, I do think it would be a usef
On Mon, 20 Feb 2017 at 20:21:03, Jeff King wrote:
> On Mon, Feb 20, 2017 at 07:38:02PM +0100, Lukas Fleischer wrote:
>
> > It would be handy to be able to show a message to the user when
> > cloning/fetching from a repository (e.g. to show a warning if a
> > repository is deprecated). This should
Eric Wong writes:
> Junio: ping?
>
> https://public-inbox.org/git/20161223014202.GA8327@starla/raw
>
> Thanks.
Thanks for reminding. This indeed fell thru cracks.
Jeff King writes:
> The simplest way (IMHO) to parse --porcelain output is:
>
> - maintain a mapping of commit sha1s to the commit's details
>
> - whenever you see a " []"
> line, any key-value fields which follow impact _only_ that sha1, and
> you should update the details for that
Matt McCutchen writes:
> Currently "git fetch REMOTE SHA1" silently exits 1 if the server doesn't
> allow requests for unadvertised objects by sha1. The more common case
> of requesting a nonexistent ref normally triggers a die() in
> get_fetch_map, so "git fetch" wasn't bothering to check after
On Tue, Feb 21, 2017 at 06:11:51AM +0100, Toolforger wrote:
> > I'm not sure I understand. You have a project policy to use certain
> > URLs. But you, the user, want to override that. Why isn't the
> > user-specific config file the right place to put that?
>
> Ah right, I mistook ~/ for "project
On Mon, Feb 20, 2017 at 08:10:31PM -0500, Kyle Meyer wrote:
> Kyle Meyer (4):
> delete_ref: accept a reflog message argument
> update-ref: pass reflog message to delete_ref()
> rename_ref: replace empty message in HEAD's log
> branch: record creation of renamed branch in HEAD's log
These
Kyle Meyer writes:
> Kyle Meyer (4):
> delete_ref: accept a reflog message argument
> update-ref: pass reflog message to delete_ref()
> rename_ref: replace empty message in HEAD's log
> branch: record creation of renamed branch in HEAD's log
These looked reasonable. I had to resolve con
On Mon, Feb 20, 2017 at 01:58:07AM -0800, Junio C Hamano wrote:
> Since nothing seems to have happened in the meantime, here is what
> I'll queue so that we won't forget for now. Lars's tests based on
> how the scripted "git submodule" uses "git config" may still be
> valid, but it is somewhat a
70 matches
Mail list logo
