Githttps://u.to/mQMuFg Duncan Ferguson
Greetings,
I am Mr.Abdelkader Alsamman from Syria,It's possible for a
foreigner to invest in education in your country?let me know the
feasibility studies as I want to relocate my investment to your
country and I need a local partner because I want to relocate my
family out from Syria due to t
Luke,
28.08.2019, 04:49, "Luke Diamand" :
> We're coming up on when Python2 is end-of-lifed - we have until
> January 1st 2020.
>
> git-p4 uses python2, and doesn't work under python3 at all.
>
> The problem is the conversions between Python3 unicode strings and git
> (utf-8) and p4 (utf-8, except
On Tue, Aug 27, 2019 at 8:46 PM Matheus Tavares Bernardino
wrote:
>
> Hi, Duy
>
> On Tue, Aug 27, 2019 at 6:26 AM Duy Nguyen wrote:
> >
> > On Tue, Aug 27, 2019 at 6:57 AM Matheus Tavares
> > wrote:
> > >
> > > Currently, config_with_options() relies on the global the_repository
> > > when it ha
Johannes Schindelin writes:
> Yes, this was me trying to re-send the patch via GMail's web UI because
> the first time GitGitGadget sent it, it did not get through (only the
> cover letter did).
As long as that was manual screw-up, while fixing some glitches in
the machinery, that is fine. I ca
Dmitry Nikulin writes:
> $ env GIT_EXTERNAL_DIFF=./print_argv.py git diff
> origin/branch1:file1.txt origin/branch2:file2.txt
I didn't even know external-diff driver is called (and does not even segfaut)
in the "compare two blobs" hack codepath.
The syntax : you have on the command
line resolve
Paul Mackerras writes:
> I was expecting some comments and suggestions, so I didn't push it out
> yet. One suggestion which seems reasonable is to match any http or
> https URL anywhere in the commit description, not just with Link: or
> BugLink: at the start of the line. What do you think of t
Konstantin Ryabitsev writes:
> If I know that a project uses tag signing, would "git clone" followed
> by "git verify-tag" be meaningful without a "git fsck" in-between?
> I.e. if an attacker has control over the remote server, can they sneak
> in any badness into any of the resulting files and s
This makes gitk look for http or https URLs in the commit description
and make the URLs clickable. Clicking on them will invoke an external
web browser with the URL.
The web browser command is by default "xdg-open" on Linux, "open" on
MacOS, and "cmd /c start" on Windows. The command can be chan
Hi Junio,
On Tue, Aug 27, 2019 at 01:32:30PM -0700, Junio C Hamano wrote:
> Paul Mackerras writes:
>
> > This makes gitk look for lines in the commit message which start with
> > "Link:" or "BugLink:" followed by a http or https URL, and make the
> > URL clickable. Clicking on it will invoke an
filter-branch suffers from a deluge of disguised dangers that disfigure
history rewrites (i.e. deviate from the deliberate changes). Many of
these problems are unobtrusive and can easily go undiscovered until the
new repository is in use. This can result in problems ranging from an
even messier h
fast-export and fast-import can easily handle the simple rewrite that
was being done by filter-branch, and should be significantly faster on
systems with a slow fork. Timings from before and after on two laptops
that I have access to (measured via `time ./t3427-rebase-subtree.sh`,
i.e. including e
t9902 had a list of three random porcelain commands as a sanity check,
one of which was filter-branch. Since we are recommending people not
use filter-branch, let's update this test to use rebase instead of
filter-branch.
Signed-off-by: Elijah Newren
---
t/t9902-completion.sh | 12 ++--
Here's a series warns about git-filter-branch usage and avoids it
ourselves.
Changes since v2 (full range-diff below):
* [Patch 2] testcase syntax cleanups
* [Patch 3] fixed "linkgit:" references to filter-repo to be url
links (or footnotes)
* [Patch 3] fixed the mode on filter-branch.sh
Test t6006.71 ("oneline with empty message") was creating two commits
with simple commit messages, and then running filter-branch to rewrite
the commit messages to be empty. This test was written this way because
the --allow-empty-message option to git commit did not exist at the
time. Simplify t
On Wed, Aug 28, 2019 at 04:32:24PM -0400, Konstantin Ryabitsev wrote:
> If I know that a project uses tag signing, would "git clone" followed by
> "git verify-tag" be meaningful without a "git fsck" in-between? I.e. if an
> attacker has control over the remote server, can they sneak in any badness
On Wed, Aug 28, 2019 at 04:18:23PM -0400, Jon Simons wrote:
> Fix a bug in partial cloning with sparse filters by ensuring to check
> for 'have_git_dir' before attempting to resolve the sparse filter OID.
>
> Otherwise the client will trigger:
>
> BUG: refs.c:1851: attempting to get main_ref
On 2019-08-28 at 20:32:24, Konstantin Ryabitsev wrote:
> Hi, all:
>
> If I know that a project uses tag signing, would "git clone" followed by
> "git verify-tag" be meaningful without a "git fsck" in-between? I.e. if an
> attacker has control over the remote server, can they sneak in any badness
>
Hi,
This just happened to me while cherry-pick'ing:
$ git cherry-pick HEAD@{1}
error: could not apply 614fe5e629b84... try
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add ' or 'git rm '
hint: and commit the result with 'git commit'
Recorded preimage for 'taskclus
As discovered on the mailing list, some of the descriptions of the
ff-related options were unclear. Try to be more precise with what these
options do.
Signed-off-by: Elijah Newren
---
Changes since v2:
* reordered the options
* typeset the option flags differently to ensure they are monospac
On Wed, Aug 28, 2019 at 12:15 PM Sergey Organov wrote:
>
> Hi,
>
[...]
> Dunno if it helps, but here is what I came up with somewhere in previous
> discussions:
>
> --ff::
> --no-ff::
> --ff-only::
> When the merge resolves as a fast-forward, only update the
I think this loose wording (th
In the procedure apply_or_revert_range_or_line, if the patch does not
apply successfully, a dialog is shown, but execution proceeds after
that. Instead, return early on error so the parts that come after this
don't work on top of an error state.
Signed-off-by: Pratyush Yadav
---
lib/diff.tcl | 2
Just like the user can select lines to stage or unstage, add the
ability to revert selected lines.
Signed-off-by: Pratyush Yadav
---
git-gui.sh | 25 -
lib/diff.tcl | 20 ++--
2 files changed, 38 insertions(+), 7 deletions(-)
diff --git a/git-gui.sh b/g
Just like the user can select a hunk to stage or unstage, add the
ability to revert hunks.
Signed-off-by: Pratyush Yadav
---
git-gui.sh | 14 +-
lib/diff.tcl | 21 -
2 files changed, 29 insertions(+), 6 deletions(-)
diff --git a/git-gui.sh b/git-gui.sh
index 6d
Accidental clicks on the revert hunk/lines buttons can cause loss of
work, and can be frustrating. So, allow undoing the last revert.
Right now, a stack or deque are not being used for the sake of
simplicity, so only one undo is possible. Any reverts before the
previous one are lost.
Signed-off-b
Hi,
This series adds the ability to revert selected lines and hunks in
git-gui. Partially based on the patch by Bert Wesarg [0].
The commits can be found in the topic branch 'py/revert-hunks-lines'
at https://github.com/prati0100/git-gui/tree/py/revert-hunks-lines
Changes in v3:
- Drop the confi
On Tue, Aug 27, 2019 at 11:17 PM Eric Sunshine wrote:
>
> On Tue, Aug 27, 2019 at 8:22 PM Elijah Newren wrote:
> > filter-branch suffers from a deluge of disguised dangers that disfigure
> > history rewrites (i.e. deviate from the deliberate changes). [...]
> >
> > Signed-off-by: Elijah Newren
>
On Wed, Aug 28, 2019 at 4:27 PM Jon Simons wrote:
> Fix a bug in partial cloning with sparse filters by ensuring to check
> for 'have_git_dir' before attempting to resolve the sparse filter OID.
> [...]
> Signed-off-by: Jon Simons
> ---
> diff --git a/t/t5616-partial-clone.sh b/t/t5616-partial-cl
Hi, all:
If I know that a project uses tag signing, would "git clone" followed by
"git verify-tag" be meaningful without a "git fsck" in-between? I.e. if
an attacker has control over the remote server, can they sneak in any
badness into any of the resulting files and still have the clone,
che
Included here are two fixes for partial cloning with sparse filters.
These issues were uncovered in early testing internally at GitHub,
where Taylor and Peff have provided early offlist review feedback.
Jon Simons (2):
list-objects-filter: only parse sparse OID when 'have_git_dir'
list-objects
Fix a bug in partial cloning with sparse filters by ensuring to check
for 'have_git_dir' before attempting to resolve the sparse filter OID.
Otherwise the client will trigger:
BUG: refs.c:1851: attempting to get main_ref_store outside of repository
when attempting to git clone with a sparse
Handle a potential NULL 'sparse_oid_value' when attempting to load
sparse filter exclusions by blob, to avoid segfaulting later during
'add_excludes_from_blob_to_list'.
While here, uniquify the errors emitted to distinguish between the
case that a given OID is NULL due to an earlier failure to res
Hiya,
On Wed, 28 Aug 2019 at 21:15, Sergey Organov wrote:
> > I was sort of expecting these to be listed in the order "--ff, --no-ff,
> > --ff-only", and I see Sergey suggested the same ordering. The way your
> > proposed text reads does make sense though... Would it read as well
> > turning it o
Hi,
Martin Ågren writes:
[...]
>> ++
>> +With --ff-only, resolve the merge as a fast-forward when possible
>> +(when the merged branch contains the current branch in its history).
>> +When not possible, refuse to merge and exit with a non-zero status.
>> ++
>> +With --no-ff, create a merge com
Hi Elijah,
Elijah Newren writes:
> Hi Sergey,
>
> On Wed, Aug 28, 2019 at 1:52 AM Sergey Organov wrote:
>>
>> Elijah Newren writes:
>>
>> > On Tue, Aug 27, 2019 at 1:43 AM Sergey Organov wrote:
>> >>
>> >> Eric Wong writes:
>> >>
>> >>
>> >> [...]
[...]
>> >
>> > Side note: Is the goal to
Hi Elijah,
On Wed, 28 Aug 2019 at 17:52, Elijah Newren wrote:
> ---ff::
> - When the merge resolves as a fast-forward, only update the branch
> - pointer, without creating a merge commit. This is the default
> - behavior.
> -
> +--ff-only::
> --no-ff::
> - Create a merge
Hi Sergey,
On Wed, Aug 28, 2019 at 1:52 AM Sergey Organov wrote:
>
> Elijah Newren writes:
>
> > On Tue, Aug 27, 2019 at 1:43 AM Sergey Organov wrote:
> >>
> >> Eric Wong writes:
> >>
> >>
> >> [...]
> >>
> >> > AFAIK, filter-branch is not causing support headaches for any
> >> > git developer
The new blame options (--ignore-rev, --ignore-revs-file) and config options
(blame.markIgnoredLines, blame.markUnblamables, blame.ignoreRevsFile) are
great, and much appreciated. However, for my primary use (one-time
automated reformatting of an entire repository), there is still some
friction pr
FWIW, the changes in grep.h are IMHO optional and hadn't been really
tested as I couldn't find a version of PCRE1 old enough to trigger it
but I am hoping are simple enough to work.
As in my original proposal, there is no test because this is going to
(as documented) trigger undefined behaviour an
Implement find_unique_prefixes() by sorting the prefix items
lexicographically and then looking for unique prefixes in adjacent
pairs. It's definitely shorter than the current hashmap-based
implementation (101 vs 149 lines), subjectively easier to follow, and
hopefully less buggy (some of the new
On Tue, Aug 27, 2019 at 02:14:06PM +0200, Johannes Schindelin wrote:
> Hi Gábor,
>
> On Sat, 24 Aug 2019, SZEDER Gábor wrote:
>
> > On Tue, Jul 16, 2019 at 07:58:42AM -0700, Slavica Djukic via GitGitGadget
> > wrote:
> > > In the `git add -i` command, we show unique prefixes of the commands and
On Wed, Aug 28, 2019 at 11:39:44AM -0400, Jeff King wrote:
> On Wed, Aug 28, 2019 at 10:54:12AM -0400, Jeff King wrote:
>
> > > Unfortunately, however, while running './t5516-fetch-push.sh -r 1,79
> > > --stress' to try to reproduce a failure caused by those mingled
> > > messages, the same check
Junio C Hamano writes:
> IIUC, the bug is twofold:
> ...
> - A message is given only when the above happens. When rebasing
> ...
>That "reset --hard" is done only to clean the index and the
>working tree and talking about "HEAD is now..." is a bug in its
>context.
Actually, this "l
On Tue, 27 Aug 2019 at 12:15, Thomas Gummerer wrote:
> struct lock_file lock = LOCK_INIT;
> const char *head_arg = "HEAD";
>
> - hold_locked_index(&lock, LOCK_DIE_ON_ERROR);
> - refresh_cache(REFRESH_QUIET);
> - if (write_locked_index(&the_index, &lock,
> -
As discovered on the mailing list, some of the descriptions of the
ff-related options were unclear. Try to be more precise with what these
options do.
Signed-off-by: Elijah Newren
---
Changes since v1:
* Grouped much like --option/--no-option items are to make it clearer
that these are rel
On Tue, 27 Aug 2019 at 12:14, Thomas Gummerer wrote:
>
> Getting the lock for the index, refreshing it and then writing it is a
> pattern that happens more than once throughout the codebase. Factor
> out the refresh_and_write_cache function from builtin/am.c to
> read-cache.c, so it can be re-use
On Wed, Aug 28, 2019 at 10:54:12AM -0400, Jeff King wrote:
> > Unfortunately, however, while running './t5516-fetch-push.sh -r 1,79
> > --stress' to try to reproduce a failure caused by those mingled
> > messages, the same check only failed for a different reason so far
> > (both on Linux and macO
Johannes Schindelin writes:
>> Ah, so "add.usebuiltin = interactive patch" can (eventually) choose
>> to use the C code for both while "add.usebuiltin = interactive"
>> would not use it for the patch mode, or something? Or even
>>
>> add.interactive.usebuiltin = yes
>
> This is what I had i
Johannes Schindelin writes:
> FWIW I disagree with the decision to mingle a bug fix with a change of
> behavior. Resetting to the correct OID is of course the bug fix.
> Dropping the message is a change of behavior.
In general I strongly advocate that a patch should fix one thing and
one thing w
On Wed, Aug 28, 2019 at 10:05 PM Jeff King wrote:
> > > Note that there _are_ some commands which are not reversible: mostly
> > > things that drop content from the working tree. So "git reset --hard" is
> > > one, and "git clean" is another. There have been discussions and even
> > > some patches
Carlo Arenas writes:
> On Fri, Aug 23, 2019 at 6:16 PM Junio C Hamano wrote:
>>
>> * cb/pcre2-chartables-leakfix (2019-08-06) 3 commits
>> - grep: avoid leak of chartables in PCRE2
>> - grep: make PCRE2 aware of custom allocator
>> - grep: make PCRE1 aware of custom allocator
>>
>> WIP
>
> t
Johannes Schindelin writes:
> FWIW if anybody cares about my opinion: I would be totally fine with
> integrating git-filter-repo into git.git, have it there for a major
> version or two, then patch `git filter-branch` to spew out a deprecation
> warning, and then remove that latter command a majo
Hi Junio,
On Tue, 27 Aug 2019, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > Besides, I really hope that this would be only temporary,...
>
> Oh, no question about it. This should be temporary knob.
>
> I still do worry about giving a bad example for others to copy.
> People tend to
On Tue, Aug 27, 2019 at 10:42:03PM +, Vipul wrote:
> Jeff King wrote:
> > The usual philosophy in Git is not to bother the user with
> > confirmations, but to allow recovery after a mistake.
> >
>
> Well, always prompting for confirmation will be annoying for some people
> specially who are
Hi Junio,
On Tue, 27 Aug 2019, Junio C Hamano wrote:
> My plan is to have ew/hashmap topic for a few days while ejecting
> the js/add-i topic which semantically conflicts with the changed way
> hashmaps ought to be used temporarily, and when I have enough time
> and concentration, try to see if I
Hi Stolee,
On Tue, 27 Aug 2019, Derrick Stolee wrote:
> On 8/25/2019 10:43 PM, Eric Wong wrote:
> > C compilers do type checking to make life easier for us. So
> > rely on that and update all hashmap_entry_init callers to take
> > "struct hashmap_entry *" to avoid future bugs while improving
> >
On Wed, Aug 28, 2019 at 02:33:15PM +, Giuseppe Crino' wrote:
> On Mon, Aug 26, 2019 at 03:14:55PM -0400, Jeff King wrote:
> > But we'd still need something at least for
> > GECOS, where "Your Name" is common.
>
> As I understand this, those commas are *not* removed by
> strbuf_addstr_with
18547aacf5 ("grep/pcre: support utf-8", 2016-06-25) that was released
with git 2.10 added the PCRE_UTF8 flag to PCRE1 matching including a
call to has_non_ascii() to try to avoid breakage if there was non-utf8
encoded content in the haystack.
Usually PCRE is compiled with JIT support (even if is n
On Wed, Aug 28, 2019 at 11:34:08AM +0200, SZEDER Gábor wrote:
> On Tue, Aug 27, 2019 at 06:43:29PM -0700, Derrick Stolee via GitGitGadget
> wrote:
> > Test t5516-fetch-push.sh has a test 'deny fetch unreachable SHA1,
> > allowtipsha1inwant=true' that checks stderr for a specific error
> > string
On Mon, Aug 26, 2019 at 03:14:55PM -0400, Jeff King wrote:
> But we'd still need something at least for
> GECOS, where "Your Name" is common.
As I understand this, those commas are *not* removed by
strbuf_addstr_without_crud(). Instead they're skipped from /etc/pass
-- see `ident.c/copy_gecos(
Hi Ben,
On Mon, 26 Aug 2019, Ben Wijen wrote:
> Dscho's review got me thinking about the rationale behind the 'HEAD is now
> at...'
> message.
>
> A 'stash push' is followed by a 'reset -q' but since 'stash create autostash'
> is
> not, we must do it ourselves. I guess the legacy implementation
On Wed, Aug 28, 2019 at 11:00:46AM +, Giuseppe Crino' wrote:
> Maybe I'm biased by my incompetence with Makefile's but since rebuilding
> the project with `install` but different flags from the first make is
> unusual this is worth mentioning to developers.
Definitely *not* sarcastic
Hi Junio,
On Mon, 26 Aug 2019, Junio C Hamano wrote:
> Funny that the patch is line-wrapped, which I do not recall ever
> seeing in GGG-generated e-mails. Dscho, do you know if anything
> funny is going on?
Yes, this was me trying to re-send the patch via GMail's web UI because
the first time G
Hi Gábor,
On Mon, 26 Aug 2019, SZEDER Gábor wrote:
> On Sun, Aug 25, 2019 at 11:21:23PM +0100, Philip Oakley wrote:
> > diff --git a/.gitignore b/.gitignore
> > index e096e0a51c..e7bb15d301 100644
> > --- a/.gitignore
> > +++ b/.gitignore
> > @@ -230,6 +230,7 @@
> > *.ip
Hi brian,
[chiming in from the peanut gallery; if my comments don't make any
sense, please do feel free to completely ignore me.]
On Sun, 25 Aug 2019, brian m. carlson wrote:
> diff --git a/convert.c b/convert.c
> index 94ff837649..0e6e9d2d75 100644
> --- a/convert.c
> +++ b/convert.c
> @@ -8,6
Hi Elijah,
On Fri, 23 Aug 2019, Elijah Newren wrote:
> On Thu, Aug 22, 2019 at 8:01 PM Eric Wong wrote:
> >
> > Elijah Newren wrote:
> > > * Remove git-filter-branch from git.git. Mention in the release
> > > notes where people can go to get it.[1]
> > >
> > > filter-branch is not merely a s
On Wed, Aug 28, 2019 at 12:32:17PM +0200, SZEDER Gábor wrote:
> I don't think it's unusual at all that the 'install' target depends on
> 'all'. A quick and incomprehensive survey of Makefiles from a few
> open source projects that I happen to have lying around seems to
> confirm this.
>
> What mi
On Wed, Aug 28, 2019 at 08:15:57AM +, Giuseppe Crino' wrote:
> On Tue, Aug 27, 2019 at 08:36:40PM +0200, SZEDER Gábor wrote:
> > Try using the same build flags for the install, i.e.:
> >
> > make prefix=/usr/local DEVELOPER=1 CFLAGS="-O0 -g" install
>
> Yes, now it works thanks!
>
> On Tue
Hello,
On Tue, Aug 27, 2019 at 02:38:57PM -0700, Bryan Turner wrote:
> On Tue, Aug 27, 2019 at 2:32 PM Uwe Kleine-König
> wrote:
> >
> > On Tue, Aug 27, 2019 at 02:59:30PM -0400, Jeff King wrote:
> > > On Tue, Aug 27, 2019 at 12:04:27PM +0200, Uwe Kleine-König wrote:
> > >
> > > to see the loose
On Fri, Aug 23, 2019 at 6:16 PM Junio C Hamano wrote:
>
> * cb/pcre2-chartables-leakfix (2019-08-06) 3 commits
> - grep: avoid leak of chartables in PCRE2
> - grep: make PCRE2 aware of custom allocator
> - grep: make PCRE1 aware of custom allocator
>
> WIP
this was v3 and doesn't sufficiently
On Tue, Aug 27, 2019 at 06:43:29PM -0700, Derrick Stolee via GitGitGadget wrote:
> Test t5516-fetch-push.sh has a test 'deny fetch unreachable SHA1,
> allowtipsha1inwant=true' that checks stderr for a specific error
> string from the remote. In some build environments the error sent
> over the remo
On 27/08/2019 15:49, Derrick Stolee wrote:
On 8/25/2019 10:43 PM, Eric Wong wrote:
This macro is popular within the Linux kernel for supporting
intrusive data structures such as linked lists, red-black trees,
and chained hash tables while allowing the compiler to do
type checking.
I intend to u
Elijah Newren writes:
> As discovered on the mailing list, some of the descriptions of the
> ff-related options were unclear. Try to be more precise with what these
> options do.
>
> Signed-off-by: Elijah Newren
> ---
> I noticed this patch sitting around in one of my branches, and noticed it
>
Hi Eric
On 27/08/2019 10:49, Eric Wong wrote:
Johannes Schindelin wrote:
Hi Eric,
On Mon, 26 Aug 2019, Eric Wong wrote:
By renaming the "hash" field to "_hash", it's easy to spot
improper initialization of hashmap_entry structs which
can leave "hashmap_entry.next" uninitialized.
Would you
Elijah Newren writes:
> On Tue, Aug 27, 2019 at 1:43 AM Sergey Organov wrote:
>>
>> Eric Wong writes:
>>
>>
>> [...]
>>
>> > AFAIK, filter-branch is not causing support headaches for any
>> > git developers today. With so many commands in git, it's
>> > unlikely newbies will ever get around to
We're coming up on when Python2 is end-of-lifed - we have until
January 1st 2020.
git-p4 uses python2, and doesn't work under python3 at all.
The problem is the conversions between Python3 unicode strings and git
(utf-8) and p4 (utf-8, except when it isn't).
I had a go at fixing this here:
http
On Tue, 27 Aug 2019 at 23:31, Junio C Hamano wrote:
>
> Andrey Mazo writes:
>
> > From: "Philip.McGraw"
> >
> > Avoid double-open exceptions on Windows platform when
> > calculating for lfs compressed size threshold
> > (git-p4.largeFileCompressedThreshold) comparisons.
> >
> > Take new approach
On Tue, Aug 27, 2019 at 08:36:40PM +0200, SZEDER Gábor wrote:
> Try using the same build flags for the install, i.e.:
>
> make prefix=/usr/local DEVELOPER=1 CFLAGS="-O0 -g" install
Yes, now it works thanks!
On Tue, Aug 27, 2019 at 08:34:23PM +0200, Johannes Sixt wrote:
> That is because the co
78 matches
Mail list logo
