(request) Use local repos for fetch instead of cloning

[mgurov]

In case I already have a repository cloned on my workstation for active work with it, it could be beneficial to use it for fetches instead of cloning a new one. Especially if the repo is voluminous. That would bring following advantages:

• no wasted space concerns
• working repo always up to date

potential issues:

• some updates might be lost on manual / other tool fetch. Minor, as one would just see the fetched changes via a different interface.
• simultaneous access to local git repository. Would be surprised if this caused a problem though.

[mgurov]

proof of the concept implementation available @ https://github.com/mgurov/Gitifier/tree/noClonesButInlineFetchingForLocal

[mzsanford]

Bump. This is a huge pain as I work on several large repos. Any issue with the cons listed above?

[mackuba]

Point 1 is what I'm worried about every time someone asks about this - git fetch is what Gitifier currently uses to check if there's anything new, so if you do a git fetch or git pull yourself, Gitifier won't see anything. Although I guess I could just check for git branch and branch hashes directly, and compare them against last known value... But that works the other way too, if Gitifier does a fetch for you, you won't see anything next time you do a pull. Sorry, but I don't have time to investigate this right now... maybe sometime in autumn...

[mgurov]

From my personal experience, neither of the points appeared to be a problem.

• when doing get fetch/git pull manually, you clearly see the updates and then there are no problems in Gitifier missing those commits. More than that, with Gitifier running constantly in the background, it was rare for me that I had to do get fetch manually. Gitifier has become a good enough 'git sync' daemon for me.
• at the same time pull is still preserved as Gitifier's fetch doesn't affect your local references/working directory as illustrated below.

before fetch:

~/tmp/git/clone$ git lol
* c1f134c (HEAD, origin/master, origin/HEAD, master) initial

Gitifier fetches new revisions:

~/tmp/git/clone$ git fetch
remote: Counting objects: 5, done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From /Users/mgu/tmp/git/repo
   c1f134c..a582210  master     -> origin/master

as we see, local references hasn't been changed

 ~/tmp/git/clone$ git lol
* a582210 (origin/master, origin/HEAD) change
* c1f134c (HEAD, master) initial

we do pull and still see the same change c1f134c..a582210

~/tmp/git/clone$ git pull
Updating c1f134c..a582210
Fast-forward
 a | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
~/tmp/git/clone$ git lol
* a582210 (HEAD, origin/master, origin/HEAD, master) change
* c1f134c initial

Conclusion.

The feature is useful and adds new value to the Gitifier. The only potentially negative, from the user experience point of view, effect of some commits missed by Gitifer on manual fetch is negligible for many workflows, where Gitifier is not the main git tool. This issue can be mitigated by preserving the original option of cloning remote repository into Gitifier's own copy. This option could also be useful to watch repositories user does not actively involved in (and has no working directory checked out).

[jaredmoody]

+1

[hacfi]

+1
I would like to watch a lot of repos and I already have most of them on my machine so this feature would be great!!

[aaroncaito]

I really want this for tracking repos I already have on the system. This would be handy.