"git worktree repair" modifies the wrong repository

"git worktree repair" modifies the wrong repository

[Russell Stuart]

What did you do before the bug happened? (Steps to reproduce your issue)
    /tmp$ mkdir -p gb/a gb/b
    /tmp$ cd gb/a
    /tmp/gb/a$ git init r
    Initialized empty Git repository in /tmp/gb/a/r/.git/
    /tmp/gb/a$ cd r
    /tmp/gb/a/r$ touch x
    /tmp/gb/a/r$ git add x
    /tmp/gb/a/r$ git commit -am .
    [main (root-commit) 6323b04] .
    1 file changed, 0 insertions(+), 0 deletions(-)
    create mode 100644 x
    /tmp/gb/a/r$ git branch foo
    /tmp/gb/a/r$ git worktree add ../r.foo
    Preparing worktree (new branch 'r.foo')
    HEAD is now at 6323b04 .
    /tmp/gb/a/r$ -r cp ../* ../../b/.
    -bash: -r: command not found
    /tmp/gb/a/r$ cp -a ../* ../../b/.
    /tmp/gb/a/r$ cd ../../b/r
    /tmp/gb/b/r$ git worktree repair ../r.foo
    repair: gitdir incorrect: /tmp/gb/a/r/.git/worktrees/r.foo/gitdir
    repair: .git file incorrect: /tmp/gb/a/r.foo
    /tmp/gb/b/r$ cat .git/worktrees/r.foo/gitdir 
    /tmp/gb/a/r.foo/.git
    /tmp/gb/b/r$ cat ../r.foo/.git
    gitdir: /tmp/gb/a/r/.git/worktrees/r.foo
    /tmp/gb/b/r$ cat ../../a/.git/worktrees/r.foo/gitdir 
    cat: ../../a/.git/worktrees/r.foo/gitdir: No such file or directory
    /tmp/gb/b/r$ cat ../../a/r/.git/worktrees/r.foo/gitdir 
    /tmp/gb/b/r.foo/.git
    /tmp/gb/b/r$ cat ../../a/r.foo/.git
    gitdir: /tmp/gb/b/r/.git/worktrees/r.foo
    /tmp/gb/b/r$ 

What did you expect to happen? (Expected behavior)
    I expected "/tmp/gb/b/r$ git worktree repair ../r.foo" to alter the
    repositories it was run from, ie those under the directory "/tmp/gb/b".

What happened instead? (Actual behavior)
    "/tmp/gb/b/r$ git worktree repair ../r.foo" modified the repositories
    under the directory "/tmp/gb/a".

[System Info]
git version:
git version 2.39.3 (Apple Git-146)
cpu: arm64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon
uname: Darwin 23.6.0 Darwin Kernel Version 23.6.0: Mon Jul 29 21:14:21 PDT 2024; root:xnu-10063.141.2~1/RELEASE_ARM64_T8103 arm64
compiler info: clang: 15.0.0 (clang-1500.3.9.4)
libc info: no libc information available
$SHELL (typically, interactive shell): /opt/homebrew/bin/bash


--
Regards,
Russell Stuart

Re: "git worktree repair" modifies the wrong repository

[Eric Sunshine]

On Wed, Sep 18, 2024 at 9:27 PM Russell Stuart
<russell+git.vger.kernel.org@stuart.id.au> wrote:
> What did you do before the bug happened? (Steps to reproduce your issue)
>     /tmp/gb/a$ git init r
>     /tmp/gb/a/r$ git worktree add ../r.foo

Had you run `git worktree list` at this point in /tmp/gb/a/r/, you
would have seen:

    /tmp/gb/a/r      3699610 [main]
    /tmp/gb/a/r.foo  3699610 [r.foo]

>     /tmp/gb/a/r$ cp -a ../* ../../b/.
>     /tmp/gb/a/r$ cd ../../b/r

Had you run `git worktree list` at this point in /tmp/gb/b/r/, you
would have seen:

    /tmp/gb/b/r      3699610 [main]
    /tmp/gb/a/r.foo  3699610 [r.foo]

from which it can be seen that /tmp/gb/b/r/.git/worktree/r.foo/gitdir
is pointing at /tmp/gb/a/r.foo, which makes sense since that gitdir
file is an exact copy of /tmp/gb/a/r/.git/worktree/r.foo/gitdir. So
/tmp/gb/a/r.foo is being shared by both repositories, /tmp/gb/a/ and
/tmp/gb/b/, and neither one knows about /tmp/gb/b/r.foo.

>     /tmp/gb/b/r$ git worktree repair ../r.foo
>     repair: gitdir incorrect: /tmp/gb/a/r/.git/worktrees/r.foo/gitdir
>     repair: .git file incorrect: /tmp/gb/a/r.foo
>     /tmp/gb/b/r$ cat .git/worktrees/r.foo/gitdir
>     /tmp/gb/a/r.foo/.git
>     /tmp/gb/b/r$ cat ../r.foo/.git
>     gitdir: /tmp/gb/a/r/.git/worktrees/r.foo
>     /tmp/gb/b/r$ cat ../../a/r/.git/worktrees/r.foo/gitdir
>     /tmp/gb/b/r.foo/.git
>     /tmp/gb/b/r$ cat ../../a/r.foo/.git
>     gitdir: /tmp/gb/b/r/.git/worktrees/r.foo

The implementation of `git worktree repair` started out (relatively)
simple, handling the most common cases, and has been extended to
handle additional cases when identified and reported. The case of
merely copying a repository and its worktrees (and leaving the
originals intact) is not yet implemented, so the above all makes sense
given the current implementation.

> What did you expect to happen? (Expected behavior)
>     I expected "/tmp/gb/b/r$ git worktree repair ../r.foo" to alter the
>     repositories it was run from, ie those under the directory "/tmp/gb/b".
>
> What happened instead? (Actual behavior)
>     "/tmp/gb/b/r$ git worktree repair ../r.foo" modified the repositories
>     under the directory "/tmp/gb/a".

I have a tentative fix implemented which seems to handle this case
correctly. Once I've finished polishing it and formalizing the related
test, I'll send out a patch.

Re: "git worktree repair" modifies the wrong repository

[Russell Stuart]

On 19/9/24 18:58, Eric Sunshine wrote:
> I have a tentative fix implemented which seems to handle this case 
> correctly. Once I've finished polishing it and formalizing the
> related test, I'll send out a patch.

Fantastic.

I noticed repair hadn't changed the directories I thought it had, but
had said it was changing something.  Pondering what on earth could of
happened, my first thought "surely not" - and then checked the
originals.  It caught me totally by surprise.  Everyone I showed it to
expressed the same surprise.

I can't resist pointing out if "git worktree add" had of preserved the
relative paths I gave it, it would not have happened.


-- 
Regards,
Russell Stuart

Re: "git worktree repair" modifies the wrong repository

[Eric Sunshine]

On Thu, Sep 19, 2024 at 6:16 AM Russell Stuart
<russell+git.vger.kernel.org@stuart.id.au> wrote:
> I can't resist pointing out if "git worktree add" had of preserved the
> relative paths I gave it, it would not have happened.

The idea of relative paths has been discussed previously[*] but was
never implemented; although they may help some cases, they break other
cases or at least make the other cases more difficult. For instance,
relative paths only help if the main and linked worktrees move
together in some uniform fashion, but don't help if they move in
distinct ways. Storing *both* the absolute and relative paths rather
than only the absolute path was also discussed and seemed promising,
but concerns were raised that doing so could break other Git-related
tools or non-canonical Git implementations (or even perhaps older
versions of Git itself), thus was never pursued.

FOOTNOTES

[*] The previous discussion was in the context of an earlier
implementation of git-worktree, long before there was a "repair"
subcommand. In fact, the very original implementation of linked
worktrees (which was actually `git checkout --to=<path>` would attempt
to automatically repair itself whenever any Git command discovered
some sort of breakage, however, that initial implementation was buggy
in some fashion (I don't have the details at hand), so the auto-repair
feature was removed very early on. The "repair" subcommand came much
later and took the conservative approach of addressing common problems
people were reporting at the time, and was extended as new reports
came in, rather than trying to tackle every possible way in which
someone could wield a foot-gun.

Re: "git worktree repair" modifies the wrong repository

[Russell Stuart]

On 19/9/24 20:47, Eric Sunshine wrote:
> The idea of relative paths has been discussed previously[*] but was 
> never implemented; although they may help some cases, they break 
> other cases or at least make the other cases more difficult. For 
> instance, relative paths only help if the main and linked worktrees 
> move together in some uniform fashion, but don't help if they move in
> distinct ways.

If breaking when moved is the criteria, then absolute paths always
break.  Relative paths break slightly less often.  So it seems to me
relative paths are an improvement - but not a fix.

It's always possible to break something by moving the wrong thing.  For
example moving the .git directory in a normal repository would create a
mess.  Yet, unlike moving worktrees (most?) people do not attempt to
move the .git directory in illegal ways.  They always copy/more copy the
entire repository.  It's intuitively obvious if you keep the .git
directory in the same relative position, it will work.

So my uniformed guess on how to "fix" the problem of people
moving/copying worktrees is to make equally obvious they must remain in
the same relative position to the parent.  One way to do that is to use
the same structure hg uses, which is the child worktrees must all be in
the one common parent directory, and the parent directory contains the
.git metadata.  It then becomes self-evident you can only more/copy the
entire thing - not bits of it.

> [*] The previous discussion was in the context of an earlier 
> implementation of git-worktree, long before there was a "repair" 
> subcommand. In fact, the very original implementation of linked 
> worktrees

Thanks.  The starting point of "linked git directories" (I presume to
save on metadata storage?) explains a how worktrees ended up where they
have.

Interestingly, people (including me as it happens) start out by trying
to emulate the hg approach using a single parent directory to hold a
bare repository, and the child worktree directories.  Then they discover
bare repositories mangle the remote links, and give up on the idea.  In
my case I then tried moving/copying the worktrees as a group using "git
worktree repair" to fix the mess, which eventually lead to this email :)

Others have published of hacks / tricks that try to solve problem in
other ways, eg: https://github.com/Kristian-Tan/git-worktree-relative

None of them work very well.  Going on what Google throws up, moving
worktrees remains a commonly felt pain point.


-- 
Regards,
Russell Stuart

Re: "git worktree repair" modifies the wrong repository

[Eric Sunshine]

On Thu, Sep 19, 2024 at 7:40 AM Russell Stuart
<russell+git.vger.kernel.org@stuart.id.au> wrote:
> On 19/9/24 20:47, Eric Sunshine wrote:
> > The idea of relative paths has been discussed previously[*] but was
> > never implemented; although they may help some cases, they break
> > other cases or at least make the other cases more difficult. For
> > instance, relative paths only help if the main and linked worktrees
> > move together in some uniform fashion, but don't help if they move in
> > distinct ways.
>
> If breaking when moved is the criteria, then absolute paths always
> break.  Relative paths break slightly less often.  So it seems to me
> relative paths are an improvement - but not a fix.

Indeed, I don't think anyone has argued against relative paths
outright, but only pointed out that absolute and relative paths each
have their strengths with regards to making the repair process
(whether automatic or not) more robust. It was for this reason that
the previous discussion[1] eventually settled on the idea of storing
both absolute and relative paths.

[1]: The discussion begins at the "Also Eric" paragraph of this email
and continues in emails following it:
https://lore.kernel.org/git/CACsJy8CXEKG+WNdSPOWF7JDzPXidSRWZZ5zkdMW3N3Dg8SGW_Q@mail.gmail.com/

> It's always possible to break something by moving the wrong thing.  For
> example moving the .git directory in a normal repository would create a
> mess.  Yet, unlike moving worktrees (most?) people do not attempt to
> move the .git directory in illegal ways.  They always copy/more copy the
> entire repository.  It's intuitively obvious if you keep the .git
> directory in the same relative position, it will work.

This intuition perhaps arises from your background with "hg", but I
have not formed any such intuition.

> So my uniformed guess on how to "fix" the problem of people
> moving/copying worktrees is to make equally obvious they must remain in
> the same relative position to the parent.  One way to do that is to use
> the same structure hg uses, which is the child worktrees must all be in
> the one common parent directory, and the parent directory contains the
> .git metadata.  It then becomes self-evident you can only more/copy the
> entire thing - not bits of it.

That's a very restrictive and limiting organization. As I understand
it, one of the design goals of Git's linked worktrees was to allow
worktrees to be placed anywhere, including on removable media or
not-always-mounted network drives. (Yes, you may be able to do
something similar with "hg" and symbolic links, but that doesn't play
well with Windows users, at least not in the era when Git's worktree
support was implemented.)

> Interestingly, people (including me as it happens) start out by trying
> to emulate the hg approach using a single parent directory to hold a
> bare repository, and the child worktree directories.  Then they discover
> bare repositories mangle the remote links, and give up on the idea.

Can you provide more details about this "mangling"? Although the
use-case you describe was not directly considered in the initial
design, worktrees hanging off a bare repository became an
explicitly-supported use-case not long after worktrees were
introduced. So, it should work properly and we know that people use
worktrees this way, but we haven't had any reports of mangling in this
scenario.

> In
> my case I then tried moving/copying the worktrees as a group using "git
> worktree repair" to fix the mess, which eventually lead to this email :)

Moving should have worked, either using "git worktree move" or by
using "git worktree repair" after moving them manually. The copy case
was broken as you reported. By the way, I posted a fix[2].

[2]: https://lore.kernel.org/git/20240923075416.54289-1-ericsunshine@charter.net/

> Others have published of hacks / tricks that try to solve problem in
> other ways, eg: https://github.com/Kristian-Tan/git-worktree-relative

Interesting reading.

> None of them work very well.  Going on what Google throws up, moving
> worktrees remains a commonly felt pain point.

I suspect that the best way forward is to store both absolute and
relative paths, but this needs to be done with care so as to not break
existing tooling or other implementations of Git or Git libraries
(including older versions of Git itself).

By the way, have you seen the patch recently posted[3] to explicitly
support relative paths for worktrees?

[3]: https://lore.kernel.org/git/pull.1783.git.git.1726880551891.gitgitgadget@gmail.com/

Re: "git worktree repair" modifies the wrong repository

[Phillip Wood]

On 23/09/2024 19:52, Eric Sunshine wrote:
> On Thu, Sep 19, 2024 at 7:40 AM Russell Stuart
> <russell+git.vger.kernel.org@stuart.id.au> wrote:
>> Interestingly, people (including me as it happens) start out by trying
>> to emulate the hg approach using a single parent directory to hold a
>> bare repository, and the child worktree directories.  Then they discover
>> bare repositories mangle the remote links, and give up on the idea.
> 
> Can you provide more details about this "mangling"? Although the
> use-case you describe was not directly considered in the initial
> design, worktrees hanging off a bare repository became an
> explicitly-supported use-case not long after worktrees were
> introduced. So, it should work properly and we know that people use
> worktrees this way, but we haven't had any reports of mangling in this
> scenario.

I can't speak for Russell but a while ago when I added a worktree to an 
existing bare repository I had to update remote.origin.fetch and 
remote.origin.mirror because "git clone --bare" implies "--mirror". I 
also needed to enable extensions.worktreeConfig and ensure core.bare was 
set appropriately.

Best Wishes

Phillip

Re: "git worktree repair" modifies the wrong repository

[Eric Sunshine]

On Tue, Sep 24, 2024 at 9:53 AM Phillip Wood <phillip.wood123@gmail.com> wrote:
> On 23/09/2024 19:52, Eric Sunshine wrote:
> > On Thu, Sep 19, 2024 at 7:40 AM Russell Stuart
> > <russell+git.vger.kernel.org@stuart.id.au> wrote:
> >> Interestingly, people (including me as it happens) start out by trying
> >> to emulate the hg approach using a single parent directory to hold a
> >> bare repository, and the child worktree directories.  Then they discover
> >> bare repositories mangle the remote links, and give up on the idea.
> >
> > Can you provide more details about this "mangling"? Although the
> > use-case you describe was not directly considered in the initial
> > design, worktrees hanging off a bare repository became an
> > explicitly-supported use-case not long after worktrees were
> > introduced. So, it should work properly and we know that people use
> > worktrees this way, but we haven't had any reports of mangling in this
> > scenario.
>
> I can't speak for Russell but a while ago when I added a worktree to an
> existing bare repository I had to update remote.origin.fetch and
> remote.origin.mirror because "git clone --bare" implies "--mirror". I
> also needed to enable extensions.worktreeConfig and ensure core.bare was
> set appropriately.

Thanks, Phillip. This is interesting information, but I'm not sure I
understand what the actual problems are that you encountered. When you
say that --bare implies --mirror, do you mean the other way around?
The documentation states the opposite; that --mirror implies --bare,
and my own testing seems to confirm that.

That aside, I played around a bit again with bare and mirror
repositories with worktrees hanging off them, but didn't encounter any
anomalous behavior, which (almost certainly) indicates that I'm not
exercising it thoroughly enough. Thus, can you provide more detail
about the actual problems you encountered which required the manual
adjustments you made to the configuration? (Does this also imply that
Documentation/git-worktree.txt could use an update to discuss how to
use them with a bare repository?)

Regarding core.bare: That's one of the settings which is special-cased
(hard-coded) to work "properly" when extensions.worktreeConfig is not
enabled, so it's not clear what problem you were experiencing in that
regard. In my testing, `git rev-parse --is-bare-repository` correctly
reported "true" in the bare repository, and "false" in a worktree
hanging off the bare repository even when extensions.worktreeConfig
was not enabled.

Re: "git worktree repair" modifies the wrong repository

[phillip.wood123]

Hi Eric

On 03/10/2024 07:28, Eric Sunshine wrote:
> On Tue, Sep 24, 2024 at 9:53 AM Phillip Wood <phillip.wood123@gmail.com> wrote:
>> On 23/09/2024 19:52, Eric Sunshine wrote:
>>> On Thu, Sep 19, 2024 at 7:40 AM Russell Stuart
>>> <russell+git.vger.kernel.org@stuart.id.au> wrote:
>>>> Interestingly, people (including me as it happens) start out by trying
>>>> to emulate the hg approach using a single parent directory to hold a
>>>> bare repository, and the child worktree directories.  Then they discover
>>>> bare repositories mangle the remote links, and give up on the idea.
>>>
>>> Can you provide more details about this "mangling"? Although the
>>> use-case you describe was not directly considered in the initial
>>> design, worktrees hanging off a bare repository became an
>>> explicitly-supported use-case not long after worktrees were
>>> introduced. So, it should work properly and we know that people use
>>> worktrees this way, but we haven't had any reports of mangling in this
>>> scenario.
>>
>> I can't speak for Russell but a while ago when I added a worktree to an
>> existing bare repository I had to update remote.origin.fetch and
>> remote.origin.mirror because "git clone --bare" implies "--mirror". I
>> also needed to enable extensions.worktreeConfig and ensure core.bare was
>> set appropriately.
> 
> Thanks, Phillip. This is interesting information, but I'm not sure I
> understand what the actual problems are that you encountered. When you
> say that --bare implies --mirror, do you mean the other way around?
> The documentation states the opposite; that --mirror implies --bare,
> and my own testing seems to confirm that.

Sorry I must have mis-remembered - it was quite a while ago. In my case 
the bare repository was set up with --mirror.

> That aside, I played around a bit again with bare and mirror
> repositories with worktrees hanging off them, but didn't encounter any
> anomalous behavior, which (almost certainly) indicates that I'm not
> exercising it thoroughly enough. Thus, can you provide more detail
> about the actual problems you encountered which required the manual
> adjustments you made to the configuration? (Does this also imply that
> Documentation/git-worktree.txt could use an update to discuss how to
> use them with a bare repository?)

"git clone --mirror" sets up a fetch refspec that forcibly update 
"refs/heads/*" when fetching. This means fetching overwrites your local 
branches and I think the fetch fails if you have a branch checked out 
that it wants to update. "git clone --bare" does not set up any fetch 
refspec. In both cases there are no remote tracking branches to base 
your local work on.

> Regarding core.bare: That's one of the settings which is special-cased
> (hard-coded) to work "properly" when extensions.worktreeConfig is not
> enabled, so it's not clear what problem you were experiencing in that
> regard. In my testing, `git rev-parse --is-bare-repository` correctly
> reported "true" in the bare repository, and "false" in a worktree
> hanging off the bare repository even when extensions.worktreeConfig
> was not enabled.

I've a feeling I thought I needed to set it because I didn't realize 
that core.bare was special cased rather than doing so in response to a 
particular problem but I can't remember for sure.

Best Wishes

Phillip

Re: "git worktree repair" modifies the wrong repository

[Junio C Hamano]

phillip.wood123@gmail.com writes:

> "git clone --mirror" sets up a fetch refspec that forcibly update
> "refs/heads/*" when fetching. This means fetching overwrites your
> local branches and I think the fetch fails if you have a branch
> checked out that it wants to update. "git clone --bare" does not set
> up any fetch refspec. In both cases there are no remote tracking
> branches to base your local work on.
>
>> Regarding core.bare: That's one of the settings which is special-cased
>> (hard-coded) to work "properly" when extensions.worktreeConfig is not
>> enabled, so it's not clear what problem you were experiencing in that
>> regard. In my testing, `git rev-parse --is-bare-repository` correctly
>> reported "true" in the bare repository, and "false" in a worktree
>> hanging off the bare repository even when extensions.worktreeConfig
>> was not enabled.
>
> I've a feeling I thought I needed to set it because I didn't realize
> that core.bare was special cased rather than doing so in response to a
> particular problem but I can't remember for sure.

I recently encountered a funny behaviour in a worktree linked to a
bare repository.

    $ git clone --bare file://$(pwd)/git.git victim-00.git
    $ git -C victim-00.git worktree add ../victim-01
    $ cd victim-01
    $ git grep -i -e subscribe
    fatal: this operation must be run in a work tree

Of course, "git grep -i subscribe HEAD" works (as it does not
require a working tree and works on a proper bare repository).

What is curious is that this also works:

    $ git grep -i -e subscribe --cached

That mode of operation can work only when the index exists,
which means it needs a working tree.  Perhaps the working tree
version is written in a more strict way to avoid unexpected
behaviour (and gets the implementation of strictness wrong), while
the index version has no such protection?  Running the index version
in the bare repository

    $ git -C ../victim-00.git -i -e subscribe --cached; echo $?
    1

seems to confirm.  The command does not fail, but in a bare
repository, the in-core the_index has 0 elements, so it thinks it
successfully looked for the needle in the haystack and found
nothing, without complaining "hey, there is no haystack".

With the extensions.worktreeConfig things work as expected in the
worktree linked to the bare repository, like so:

    $ cd ../victim-01
    $ git config set extensions.worktreeConfig true
    $ git config set core.bare false
    $ git grep -i -e subscribe

So, I dunno.  Is core.bare really "special cased"?  It seems to me
that any halfway special case harms users more than helps.

Re: "git worktree repair" modifies the wrong repository

[Russell Stuart]

Sorry, I missed this reply.

On 24/9/24 04:52, Eric Sunshine wrote:
> [1]: The discussion begins at the "Also Eric" paragraph of this email
> and continues in emails following it:
> https://lore.kernel.org/git/CACsJy8CXEKG+WNdSPOWF7JDzPXidSRWZZ5zkdMW3N3Dg8SGW_Q@mail.gmail.com/

Yes, Duh's comments pretty much sums it up.

> This intuition perhaps arises from your background with "hg", but I
> have not formed any such intuition.

Not only from hg.  You can freely move the parent directory of all CVS 
systems I'm aware of - hg, svn, cvs, rcs, sccs and yes git too.  It only 
breaks when you add worktrees to git.

> That's a very restrictive and limiting organization. As I understand
> it, one of the design goals of Git's linked worktrees was to allow
> worktrees to be placed anywhere, including on removable media or
> not-always-mounted network drives. (Yes, you may be able to do
> something similar with "hg" and symbolic links, but that doesn't play
> well with Windows users, at least not in the era when Git's worktree
> support was implemented.)

Yes, it is far more restrictive than git worktrees are now.  It 
simplifies the users the mental model of what is going on, but that 
simplification comes at a cost.  I only mentioned it because relative 
paths in worktrees would allow you to pretend it works that way.

> Can you provide more details about this "mangling"? Although the
> use-case you describe was not directly considered in the initial
> design, worktrees hanging off a bare repository became an
> explicitly-supported use-case not long after worktrees were
> introduced. So, it should work properly and we know that people use
> worktrees this way, but we haven't had any reports of mangling in this
> scenario.

Phillip's reply was spot on: 
https://lore.kernel.org/git/87afa860-52f4-414a-82da-09e7eeac1301@gmail.com/

> By the way, have you seen the patch recently posted[3] to explicitly
> support relative paths for worktrees?
> 
> [3]: https://lore.kernel.org/git/pull.1783.git.git.1726880551891.gitgitgadget@gmail.com/

Ahh, now I see why using both is attractive