Trying to use insteadOf trick to use different SSH keys for separate github accounts - not working

Hello, Here's what I'm trying to do, that i need your help with to make work: I have 2 github accounts, each with their own SSH key: my home account (default SSH key) and my work account (alternative SSH key). I can create a virtual hostname in my ~/.ssh/config like so: Host work.github.com

Re: What's cooking in git.git (Dec 2017, #03; Wed, 13)

On Friday 15 December 2017 02:38 AM, Junio C Hamano wrote: Junio C Hamano writes: I think you only sent 3/3 in newer rounds, which made it not to apply to my tree. If you meant to drop changes in 1/3 and 2/3, perhaps because they were needless churn, then 3/3 needs to be

Re: [PATCH v4 2/2] Doc/check-ref-format: clarify information about @{-N} syntax

On Thursday 14 December 2017 11:32 PM, Junio C Hamano wrote: Kaartic Sivaraam writes: Looks alright. It was made unnecessarily harder to review because it was marked as 2/2, even though this no longer applies on top of the copy of 1/2 that was merged some time ago.

Re: [PATCH 2/2] fsmonitor: Store fsmonitor bitmap before splitting index

On Mon, 13 Nov 2017, Ben Peart wrote: > Why do you redirect stdout to stderr and then and perform an "echo" > afterwards? I don't understand what benefit that provides. I removed this > logic and the test still passes so am confused as to what its purpose is. Ah -- the "echo" was purely to

Re: feature-request: git "cp" like there is git mv.

Hi Simon, Simon Doodkin wrote: > please develop a new feature, git "cp" like there is git mv tomovefile1 > tofile2 > (to save space). > > there is a solution in https://stackoverflow.com/a/44036771/466363 > however, it is not single easy command. This sounds like a reasonable thing to add.

Re: Git Hooks

Thanks, Bryan. To give the code pullers a chance to review, can we not have a `trusted-hooks: default` and `trusted-SHA: ` field in .git/. I'm assuming githooks/ are source tracked here. When developer tries to execute `git commit`, git can ask developer to change `trusted-hooks` field to true

Re* [PATCH v2 2/2] t: add tests for pull --verify-signatures

Junio C Hamano writes: > Interestingly, the tests that do expect 'git pull' to succeed > protect themselves with "when-finished" mechanism correctly [*1*], > like so: > >> +test_expect_success GPG 'pull signed commit with --verify-signatures' ' >> +test_when_finished "git

Re: Question about the ahead-behind computation and status

On 12/15/2017 1:30 PM, Junio C Hamano wrote: Derrick Stolee writes: The biggest reason for the 20 seconds is not just the number of commits in the ahead/behind but how many commits are walked (including common to both branches) before paint_down_to_common() breaks its while

Re: [PATCH] git-svn: convert CRLF to LF in commit message to SVN

"Bennett, Brian" writes: > Thank you all for your guidance, > > I have completed my test this morning with the patch and the 'git > svn dcommit' is now SUCCESSFUl! Thanks, all.

Re: "git describe" documentation and behavior mismatch

Daniel Knittl-Frank writes: > Forget the above patch. I should compile my code after refactoring ... > > Here is the fixed version. > > -- >8 -- > > From 8203bd0ad5baab7024ebff597c9f35a0250d09ff Mon Sep 17 00:00:00 2001 > From: Daniel Knittl-Frank

Re: Git Hooks

On Fri, Dec 15, 2017 at 11:12 AM, Satyakiran Duggina wrote: > I see that `git init` creates a .git directory and hooks are to be > placed in that directory and these hooks are not tracked by version > control. To achieve tracked hooks, either each developer has to copy > the

Re: Need help migrating workflow from svn to git.

On 15/12/2017 20:09, Junio C Hamano wrote: > > > Junio, what about consecutive runs, while merge conflicts are still > > unresolved? > > The impression I got was that the original running with svn does not > deal with conflicting situation anyway, so I did not think about it > at all, and I

Git Hooks

I see that `git init` creates a .git directory and hooks are to be placed in that directory and these hooks are not tracked by version control. To achieve tracked hooks, either each developer has to copy the hooks or use tools like overcommit, pre-commit, husky etc. I'm wondering why hooks are

Re: Need help migrating workflow from svn to git.

Igor Djordjevic writes: > Junio, what about consecutive runs, while merge conflicts are still > unresolved? The impression I got was that the original running with svn does not deal with conflicting situation anyway, so I did not think about it at all, and I

Frau Ruth Michael

Mein Liebster im Herrn, Grüße an Sie im Namen unseres Herrn Jesus Christus. Es war nach dem Durchlaufen Ihres Profils. Ich bin bewegt, Sie mit diesem wichtigen Thema in Kontakt zu bringen, mit dem Glauben und der Zuversicht, dass Sie ein guter Assistent dieses Werkes Gottes sein werden.

Re: Need help migrating workflow from svn to git.

On 15/12/2017 17:33, Junio C Hamano wrote: > > $ git fetch > $ git checkout -m -B FETCH_HEAD ... aaand that`s how you do it[1] without a temporary branch :) Junio, what about consecutive runs, while merge conflicts are still unresolved? Seeing Josef having a pretty relaxed flow,

Re: Question about the ahead-behind computation and status

Derrick Stolee writes: > The biggest reason for the 20 seconds is not just the number of > commits in the ahead/behind but how many commits are walked (including > common to both branches) before paint_down_to_common() breaks its > while loop due to queue_has_nonstale(). Hmm,

Re: Need help migrating workflow from svn to git.

Hi Josef, Thank you for your patient answers. From what you said here and in that other reply[1], it looks like you know what you`re doing, you`re aware of circumstances, and you still prefer doing it that way. So, here it goes... :) On 15/12/2017 13:47, Josef Wolf wrote: > > > I`m thinking

Re: [PATCH v2 0/2] Offer more information in `git version --build-options`'s output

Eric Sunshine writes: > On Fri, Dec 15, 2017 at 12:45 PM, Junio C Hamano wrote: >> Johannes Schindelin writes: >>> no commit associated with this build >> >> I find this output somewhat klunky for machine parsing

Re: [PATCH v2 0/2] Offer more information in `git version --build-options`'s output

On Fri, Dec 15, 2017 at 12:45 PM, Junio C Hamano wrote: > Johannes Schindelin writes: >> no commit associated with this build > > I find this output somewhat klunky for machine parsing (and it is > inconsistent with the style used for

Re: [PATCH v2 0/2] Offer more information in `git version --build-options`'s output

Johannes Schindelin writes: > - when no commit can be determined, it now says > > no commit associated with this build > instead of > > built from commit: (unknown) I find this output somewhat klunky for machine parsing (and it is inconsistent with the

Re: [PATCH v3] Makefile: replace perl/Makefile.PL with simple make rules

On Fri, Dec 15, 2017 at 11:35 AM, Michael J Gruber wrote: > Ævar Arnfjörð Bjarmason venit, vidit, dixit 12.12.2017 23:26: >> >> On Tue, Dec 12 2017, Randall S. Becker jotted: >> >>> -Original Message- >>> On December 10, 2017 4:14 PM, Ævar Arnfjörð Bjarmason wrote: >>>

Re: [PATCH v2 4/4] t/Makefile: introduce TEST_SHELL_PATH

Jeff King writes: > I think (4) and (5) are the only things that actually change the > behavior in a meaningful way. But they're a bit more hacky and > repetitive than I'd like. Especially given that I'm not really sure > we're solving an interesting problem. I'm happy enough with

Re: Need help migrating workflow from svn to git.

Josef Wolf writes: > With git, by contrast, this won't work. Git will refuse to pull anything as > long as there are ANY local modifications. The cron job would need to > >git stash >git pull >git stash pop I'd assume that this "pull" is expected to be

Re: [PATCH v2] doc: add triangular workflow

ALBERTIN TIMOTHEE p1514771 writes: +This workflow is commonly used on different platforms like BitBucket, +GitHub or GitLab which provide a dedicated mechanism for requesting merges. >>> >>> As a user, I find it terribly frustrating when

Re: [PATCH v2] doc: add triangular workflow

ALBERTIN TIMOTHEE p1514771 writes: >>> +Example with master as : >>> +=== >>> +* `git config branch.master.remote upstream` >>> +* `git config branch.master.pushRemote origin` >>> +=== > >>origin

RE: [PATCH v2] doc: add triangular workflow

>>> +This workflow is commonly used on different platforms like BitBucket, >>> +GitHub or GitLab which provide a dedicated mechanism for requesting merges. >> >> As a user, I find it terribly frustrating when reading documentation >> telling me that "there's a dedicated mechanism" for something

Re: [PATCH] send-email: extract email-parsing code into a subroutine

PAYRE NATHAN p1508475 writes: >>> +sub parse_header_line { >>> + my $lines = shift; >>> + my $parsed_line = shift; >>> + my $pattern = join "|", qw(To Cc Bcc); >> >> Nit: you may want to rename it to something more explicit, like >> $addr_headers_pat.

Re: Question about the ahead-behind computation and status

On 12/15/2017 10:08 AM, Jeff Hostetler wrote: On 12/15/2017 5:08 AM, Jeff King wrote: On Thu, Dec 14, 2017 at 04:49:31PM -0500, Jeff Hostetler wrote: [*] Sadly, the local repo was only about 20 days out of date (including the Thanksgiving holidays) Taking 20 seconds to traverse 20

[PATCH] send-email: extract email-parsing code into a subroutine

The existing code mixes parsing of email header with regular expression and actual code. Extract the parsing code into a new subroutine "parse_header_line()". This improves the code readability and make parse_header_line reusable in other place. "parsed_header_line()" and "filter_body()" could be

Re: [PATCH 1/4] travis-ci: use 'set -x' in 'ci/*' scripts for extra tracing output

Hi Gábor, On Fri, 15 Dec 2017, SZEDER Gábor wrote: > On Fri, Dec 15, 2017 at 1:10 PM, Johannes Schindelin > wrote: > > > >> There is a lot going on in 'run-windows-build.sh', so the output of > >> 'set -x' might be useful or might be considered too much clutter, I >

Re: What's cooking in git.git (Dec 2017, #03; Wed, 13)

On Thursday 14 December 2017 10:50 PM, Junio C Hamano wrote: Kaartic Sivaraam writes: It seems my series that fixes an error message in 'git-rebase'[1] (apart from a little cleanups) is missing. I guess I addressed the issue that was raised in 3/3 as a v3 for that

RE: [PATCH v2] doc: add triangular workflow

>> + >> + >> +-- - >> +| UPSTREAM | maintainer | PUBLISH | >> +||- - - - - - - -| | >> +-- <- - >> + \

Re: [PATCH v3] Makefile: replace perl/Makefile.PL with simple make rules

Hi Michael, Michael J Gruber wrote: > This patch (currently in origin/next) makes a ton of tests from our test > suite fail for me on pretty standard systems (Fedora 27, CentOS 7.4.1708). > > Is there anything I'm supposed to do differently now to make our test > suite run? If yes then a clear

Re: Question about the ahead-behind computation and status

On 12/15/2017 5:08 AM, Jeff King wrote: On Thu, Dec 14, 2017 at 04:49:31PM -0500, Jeff Hostetler wrote: I don't want to jump into the graph algorithm at this time, but was wondering about adding a --no-ahead-behind flag (or something similar or a config setting) that would disable the a/b

Mrs.Susan Ibrahim

Remain Blessed,.pdf Description: Adobe PDF document

RE: [PATCH] git-svn: convert CRLF to LF in commit message to SVN

Thank you all for your guidance, I have completed my test this morning with the patch and the 'git svn dcommit' is now SUCCESSFUl! Thank you again for all of your help and I'll await to see when the patch is posted. Brian Bennett | Supv System Admin & Support, TA TECH Change Mgmt/Production

Re: Need help migrating workflow from svn to git.

On Fri, Dec 15, 2017 at 02:17:40AM +0100, Igor Djordjevic wrote: > > This said, and without having you to change your habits too much (nor > use Git in possibly awkward ways), I`m thinking you may actually > benefit of using `git worktree add `[1] to create a > temporary working tree ("working

Re: [PATCH 1/4] travis-ci: use 'set -x' in 'ci/*' scripts for extra tracing output

On Fri, Dec 15, 2017 at 1:10 PM, Johannes Schindelin wrote: > Hi, > >> There is a lot going on in 'run-windows-build.sh', so the output of 'set >> -x' might be useful or might be considered too much clutter, I don't >> know. I put Dscho on Cc, I think it's mainly his

Re: Need help migrating workflow from svn to git.

Thanks for your input, Igor! On Thu, Dec 14, 2017 at 11:27:09PM +0100, Igor Djordjevic wrote: > Aside "update and merge" working copy while you`re hacking on it, > what happens with "execute" part? It seems really strange that you > don`t mind cron job running the same scripts which you are

Re: What's cooking in git.git (Dec 2017, #03; Wed, 13)

Hi Junio, On Wed, 13 Dec 2017, Junio C Hamano wrote: > * db/doc-workflows-neuter-the-maintainer (2017-12-08) 1 commit I hope you do not mean this literally. There is no need to bring family planning into a technical document. Ciao, Dscho

Re: [PATCH 1/4] travis-ci: use 'set -x' in 'ci/*' scripts for extra tracing output

Hi, > There is a lot going on in 'run-windows-build.sh', so the output of 'set > -x' might be useful or might be considered too much clutter, I don't > know. I put Dscho on Cc, I think it's mainly his call. Certainly it might be useful. However, please make sure that the secret token is not

Re: [PATCH v2 4/4] t/Makefile: introduce TEST_SHELL_PATH

On Mon, Dec 11, 2017 at 12:37:42PM -0800, Junio C Hamano wrote: > > Interestingly, many of those do something like this in the Makefile: > > > > ifdef GIT_TEST_CMP > > @echo GIT_TEST_OPTS=... >>$@+ > > endif > > > > which seems utterly confusing to me. Because it means that if you build >

Re: [PATCH v3] Makefile: replace perl/Makefile.PL with simple make rules

Ævar Arnfjörð Bjarmason venit, vidit, dixit 12.12.2017 23:26: > > On Tue, Dec 12 2017, Randall S. Becker jotted: > >> -Original Message- >> On December 10, 2017 4:14 PM, Ævar Arnfjörð Bjarmason wrote: >> Subject: [PATCH v3] Makefile: replace perl/Makefile.PL with simple make rules >> >>>

Re: Need help migrating workflow from svn to git.

Thanks for your answer, Randall, On Thu, Dec 14, 2017 at 04:07:15PM -0500, Randall S. Becker wrote: > > You might want to consider a slight modification to your approach as > follows. > Instead of using git pull, use git fetch. > Have each system on its own branch (sys1 = my-sys1-branch, for

Re: Question about the ahead-behind computation and status

On Thu, Dec 14, 2017 at 04:49:31PM -0500, Jeff Hostetler wrote: > I don't want to jump into the graph algorithm at this time, > but was wondering about adding a --no-ahead-behind flag (or > something similar or a config setting) that would disable > the a/b computation during status. > > For

Re: [PATCH] decorate: clean up and document API

On Mon, Dec 11, 2017 at 10:32:49AM -0800, Jonathan Tan wrote: > > Other than that philosophical point, the documentation you added looks > > pretty good to me. Two possible improvements to the API we could do on > > top: > > > > 1. Should there be a DECORATION_INIT macro (possibly taking the

Re: [PATCH v1] convert: add support for 'encoding' attribute

On Mon, Dec 11, 2017 at 04:50:23PM +0100, lars.schnei...@autodesk.com wrote: > From: Lars Schneider > > Git and its tools (e.g. git diff) expect all text files in UTF-8 > encoding. Git will happily accept content in all other encodings, too, > but it might not be able

Assalamu`Alaikum.

Greetings from Dr. mohammad ouattara. Assalamu`Alaikum. My Name is Dr. mohammad ouattara, I am a banker by profession. I'm from Ouagadougou, Burkina Faso, West Africa. My reason for contacting you is to transfer an abandoned $14.6M to your account. The owner of this fund died since 2004 with