My name is Lisa i saw your email today when i was searching for
someone i can trust and let know more about me and i became interested
in you, i will also like to know you the more, I believe we can move
from here! I am waiting for your mail. and I have vital information
you need to know. Please,
On Mon, Jul 9, 2018 at 6:15 AM Derrick Stolee wrote:
> On 7/8/2018 11:12 PM, Jacob Keller wrote:
> > On Sun, Jul 8, 2018 at 4:39 PM brian m. carlson
> > wrote:
> >> This is the fourteenth series of patches to switch to using struct
> >> object_id and the_hash_algo. This series converts several c
Hi Elijah,
On Fri, 13 Jul 2018, Elijah Newren wrote:
> On Thu, Jul 12, 2018 at 8:49 AM, Johannes Schindelin
> wrote:
> >
> > On Wed, 27 Jun 2018, Elijah Newren wrote:
> >
> >> Signed-off-by: Elijah Newren
> >> ---
> >>
> >> Changes since v1:
> >> - Fixed up commit message (move below comment
Hi Junio,
On Thu, 12 Jul 2018, Junio C Hamano wrote:
> Ben Peart writes:
>
> >> > Thanks. I thought it was strange as well until I realized you only
> >> > see the error message if there _isn't_ a valid drive letter so seeing
> >> > the entire path makes sense as it will likely be something li
Hi Peff,
On Fri, 13 Jul 2018, Jeff King wrote:
> On Thu, Jul 12, 2018 at 12:23:28AM +0200, Johannes Schindelin via
> GitGitGadget wrote:
>
> > This is particularly important to keep in mind when looking at the
> > `.git/shallow` file: if any commits listed in that file become
> > unreachable, it
Currently rerere can't handle nested conflicts and will error out when
it encounters such conflicts. Do that by recursively calling the
'handle_conflict' function to normalize the conflict.
The conflict ID calculation here deserves some explanation:
As we are using the same handle_conflict funct
Currently we write the conflict to disk directly in the handle_path
function. To make it re-usable for nested conflicts, instead of
writing the conflict out directly, store it in a strbuf and let the
caller write it out.
This does mean some slight increase in memory usage, however that
increase i
Currently when a user doesn't resolve a conflict, commits the results,
and does an operation which creates another conflict, rerere will use
the ID of the previously unresolved conflict for the new conflict.
This is because the conflict is kept in the MERGE_RR file, which
'rerere' reads every time
We currently return the exact number of conflict hunks a certain path
has from the 'handle_paths' function. However all of its callers only
care whether there are conflicts or not or if there is an error.
Return only that information, and document that only that information
is returned. This will
Currently when a user doesn't resolve a conflict in a file, but
commits the file with the conflict markers, and later the file ends up
in a state in which rerere can't handle it, subsequent rerere
operations that are interested in that path, such as 'rerere clear' or
'rerere forget ' will fail, or
Factor out the handle_conflict function, which handles a single
conflict in a path. This is in preparation for a subsequent commit,
where this function will be re-used. No functional changes intended.
Signed-off-by: Thomas Gummerer
---
rerere.c | 87 ++--
Add some documentation for the logic behind the conflict normalization
in rerere.
Helped-by: Junio C Hamano
Signed-off-by: Thomas Gummerer
---
Documentation/technical/rerere.txt | 140 +
rerere.c | 4 -
2 files changed, 140 insertions(+),
Documentation/CodingGuidelines mentions that error messages should be
lowercase. Prior to marking them for translation follow that pattern
in rerere as well, so translators won't have to translate messages
that don't conform to our guidelines.
Signed-off-by: Thomas Gummerer
---
rerere.c | 24 ++
'git rerere' is considered a plumbing command and as such its output
should be translated. Its functionality is also only enabled through
a config setting, so scripts really shouldn't rely on the output
either way.
Signed-off-by: Thomas Gummerer
---
builtin/rerere.c | 4 +--
rerere.c |
We have multiple different variants of the error message we show to
the user if 'read_cache' fails. The "Could not read index" variant we
are using in 'rerere.c' is currently not used anywhere in translated
form.
As a subsequent commit will mark all output that comes from 'rerere.c'
for translati
The previous rounds were at
<20180520211210.1248-1-t.gumme...@gmail.com> and
<20180605215219.28783-1-t.gumme...@gmail.com>.
This round is a more polished version of the previous round, as
suggested by Junio in .
It's also rebased on v2.18.
The series grew by one patch, because 8/10 has been split
It looks like most paths in the output in the git codebase are wrapped
in single quotes. Standardize on that in rerere as well.
Apart from being more consistent, this also makes some of the strings
match strings that are already translated in other parts of the
codebase, thus reducing the work fo
Hello Jeff,
thanks for your answer. You are right: I have forgotten to run 'make
install'. After doing so the completion works again.
type git reports /usr/local/bin/git
Regards
Дилян
On Sat, 2018-07-14 at 17:24 -0400, Jeff King wrote:
> On Sat, Jul 14, 2018 at 02:46:17PM +, Дилян Палау
Hi David,
On Thu, 12 Jul 2018, David Brown wrote:
> Howdy, I want to hack the getweb_make_index.perl script to create a string
> search using: https://github.com/git/git/blob/master/levenshtein.c.
>
> How do i reference the compiled code?
>
> I would like to call this routine using Java and may
On Sat, Jul 14, 2018 at 02:46:17PM +, Дилян Палаузов wrote:
> After upgrading to 2.18 the completion does not work:
>
> typing "git de" prints
> my@host:~$ git deUnknown option: --list-cmds=list-
> mainporcelain,others,nohelpers,alias,list-complete,config
> usage: git [--version] [--help] [-C
On Sat, Jul 14, 2018 at 06:38:59PM +, brian m. carlson wrote:
> The sequencer currently passes GIT_DIR, but not GIT_WORK_TREE, to exec
> commands. In that configuration, we assume that whatever directory
> we're in is the top level of the work tree, and git rev-parse
> --show-toplevel respond
On Sat, Jul 14, 2018 at 11:05:34PM +0200, Johannes Schindelin wrote:
> Hi Brian,
>
> On Sat, 14 Jul 2018, brian m. carlson wrote:
> > Dscho, is this test going to cause a problem on Windows with the forward
> > slash in the grep statement?
>
> It passes on Windows. The reason is that you are aski
Hi Brian,
On Sat, 14 Jul 2018, brian m. carlson wrote:
> The sequencer currently passes GIT_DIR, but not GIT_WORK_TREE, to exec
> commands. In that configuration, we assume that whatever directory
> we're in is the top level of the work tree, and git rev-parse
> --show-toplevel responds accordin
On Tue, Jul 10, 2018 at 10:03:10AM -0400, Jeff King wrote:
> My point is that aside from RUNTIME_PREFIX, we don't need /proc. So
> somebody who currently builds Git with a static path like
> "/usr/libexec/git-core" and runs it inside a chroot will be just fine as
> long as /usr/libexec/git-core is
The sequencer currently passes GIT_DIR, but not GIT_WORK_TREE, to exec
commands. In that configuration, we assume that whatever directory
we're in is the top level of the work tree, and git rev-parse
--show-toplevel responds accordingly. However, when we're in a
subdirectory, that isn't correct:
On Tue, Jul 10, 2018 at 01:12:24PM -0400, Jeff King wrote:
> On Tue, Jul 10, 2018 at 10:52:22AM +0200, Henning Schild wrote:
> > This series can be seen as a follow up of a series that appeared under
> > the name "gpg-interface: Multiple signing tools" in april 2018 [1]. After
> > that series was n
On Wed, Jul 11, 2018 at 12:38:24PM +0200, Henning Schild wrote:
> Am Tue, 10 Jul 2018 13:09:01 -0400
> schrieb Jeff King :
>
> > On Tue, Jul 10, 2018 at 10:52:31AM +0200, Henning Schild wrote:
> >
> > > diff --git a/t/lib-gpg.sh b/t/lib-gpg.sh
> > > index a5d3b2cba..9dcb4e990 100755
> > > --- a/t
On Tue, Jul 10, 2018 at 12:56:38PM -0400, Jeff King wrote:
> On Tue, Jul 10, 2018 at 12:54:13PM -0400, Jeff King wrote:
>
> > Should we allow:
> >
> > [gpg "OpenPGP"]
> > program = whatever
> >
> > given that we allow:
> >
> > [gpg]
> > format = OpenPGP
> >
> > ? I think just using str
On Fri, Jul 13, 2018 at 08:57:03PM -0400, Jeff King wrote:
> On Sat, Jul 14, 2018 at 12:35:05AM +, brian m. carlson wrote:
>
> > diff --git a/sequencer.c b/sequencer.c
> > index 5354d4d51e..c8e16f9168 100644
> > --- a/sequencer.c
> > +++ b/sequencer.c
> > @@ -2636,6 +2636,8 @@ static int do_ex
Hello,
in /git/git I have v2.18.0 and in ~/.bashrc :
export
PS1='${debian_chroot:+($debian_chroot)}\[\e[01;32m\]\u@\h\[\e[00m\]:\[\
e[
01;34m\]\w\[\e[36m\]$(__git_ps1 " %s")\$ \[\e[0m\]'
source /git/git/contrib/completion/git-completion.bash
source /git/git/contrib/completion/git-prompt.sh
Afte
The variable smtp_encryption must keep it's value between two batches.
Otherwise the authentication is skipped after the first batch.
Signed-off-by: Jules Maselbas
---
git-send-email.perl | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.p
On Fri, Jul 13, 2018 at 04:55:57PM +, g...@jeffhostetler.com wrote:
> diff --git a/Documentation/technical/structured-logging.txt
> b/Documentation/technical/structured-logging.txt
> new file mode 100644
> index 000..794c614
> --- /dev/null
> +++ b/Documentation/technical/structured-loggin
32 matches
Mail list logo
