Usability outrage as far as I am concerned

All I will do is paste the stackoverflow question below. It covers the commands I made in chronological order and the way I would have expected git to behave differently.

So I did

git pull home_subfolder

while in usb_subfolder. Can't remember the immediate output, but it included a part about two repos having no commits in common. Would have been wiser for git to just error out with a message that in one of the folders there is not git repository.

At all times

git status

in home_subfolder gives

branch master Working directory clean

This is so stupid considering the circumstances.

Doing again

git pull home_subfolder

at all times from usb_folder now returns U in front of 2 files in home_folder and A in front of another file and then says

Pull is not possible because you have unmerged files

Had the bright idea to do

git clone home_subfolder

from the usb_subfolder because of my worries going away when

git status

in home_subfolder conforted me that there must be nothing bad about the situation. Therefore I suspect that now doing

git pull usb_subfolder

from home_subfolder will do the same broken result as above.

I do not want to resolve merge conflicts because git doesn't error out with a sane message of the situation when it should. I just want to get the home_subfolder and usb_subfolder repositories state to where it was before my breakage generating git pull and git clone commands.

Ubuntu 14.04 64 bit, git 1.9.1.

Thank you for your time.

On Wed, Dec 20, 2017 at 5:40 PM, Cristian Achim <brancoliticus@gmail.com> wrote:

Hi. While I'm sure you'll still find some fault with git's UI could you please:

1) Try to see if the latest git version (or some approximation) fixes
some of this, as you said you're on 1.9.1 which was released in 2014,
there's been a lot of UI work since then, including some that by my
reading of your mail should address some of your concerns

2) It would be really useful if you could distill the complaints you
have down to some sequence of commands to run, preferably just a small
shellscript with comments saying "the message at this point is bad for
such-and-such a reason". I may have just misread what you said (or
maybe it's since been fixed), but per my reading we're already doing
some of what you've pointed out we should be doing, and if not maybe
that's because I'm not imagining how you're running git exactly, a
reproducible recipe would really help.

Thanks.

On Wed, Dec 20, 2017 at 8:40 AM, Cristian Achim <brancoliticus@gmail.com> wrote:

This by itself should be attempting to pull from a remote named home_subfolder. Can you show the output of "git remote" and also clearly explain with details the layout of what the folders are and what is or is not a repository? I can't really make heads or tails of your problem without more details.

So you have home_subfolder and usb_subfolder which are repositories? Are they submodules within a parent project? Are they simply folders? Were you trying to merge the two together?

Without knowing more of what you intended to do, vs what you did, and without more information about the setup it's not really possible to understand the situation or what broke.

From the looks of it, I think you might have tried to do something like try to pull from usb_subfolder directly into the home_subfolder.

Are these two repositories nested? ie: you have "home_subfolder" as "/home/subfolder" and you have usb_subfolder as "/home/subfolder/usb/subfolder"?

That might explain why git pull would interpret such a command as a path from which to do a file based pull...

Thanks, Jake

# in usb_subfolder $git remote origin $

#in home_subfolder $git remote $

Take the following update into consideration and then reread my first email hopefully with improved clarity:

'home_subfolder' is the path on disk inside my user account home folder in the 'home' root folder to the initial repo from which I meant to do a backup.

'usb_subfolder' is the path on disk in the 'media' root folder to the initial empty folder into which I wanted to do the backup above that points into a usb stick I mounted in the default Kubuntu KDE file manager way of mounting usb stick folder hierarchies.

Current situation is that 'git log' in both home_subfolder and usb_subfolder show the same hash with only one branch in both. From usb_subfolder 'git pull home_subfolder' is broken as in the original message.

On Fri, Dec 22, 2017 at 7:57 AM, Cristian Achim <brancoliticus@gmail.com> wrote:

With the -v switch you can see where each remote points to (tho your home local repo has no remote which is fine).

Ok. So you have a repository inside your home directory which you wish to copy into the USB stick?

So what steps did you take to setup the repository usb_subfolder initially?

You're basically trying to create a backup copy of what's in home_subfolder into your USB stick?

If you're confident that home_subfolder is accurate right now, (ie: you inspect its contents with git log, git status, and regaulr commands to check that everything is as you expect), here's what I would do:

cd to your usb stick, then run git clone /path/to/home_subfolder

this will create an initial clone.

If you wish to update it later, you can mount hte usb stick, and then just run git pull from inside the new subfolder. Note that you do *not* run "git pull home_subfolder", as git pull expects the name of a remote, which in this case is just origin (since the default remote name you clone from is origin)

I'm still not certain what state you got in, but I believe based on your commands that the home_subfolder is fine, and you somehow incorrectly setup the usb_subfolder.

Thanks, Jake

PS/Tangent:

If you never need the checked out files on the USB disk, and only wish to keep history saved, then you can actually do "git clone --mirror <path>" in order to make a bare copy which is a complete mirror of all refs in the original repository.

Then you can update it with just git fetch, or git remote update. (tho, keep in mind this clone would not have any working tree, but merely a bare repository contents). (You can, ofcourse, recover the files by simply cloning to somewhere else, or adding a new work tree or similar.

Hi Jacob,

On Sat, Dec 23, 2017 at 12:05 AM, Jacob Keller <jacob.keller@gmail.com> wrote:

From git-fetch(8):

       <repository>
           The "remote" repository that is the source of a fetch or
pull operation.
           This parameter can be either a URL (see the section GIT URLS below)
           or the name of a remote (see the section REMOTES below).

You can run git fetch / git pull with a URL or a local path to a repository, not only origin etc.

Basically somehow at the point when I investigated stuff on the usb stick I found the repository at the top level of the usb folder hierarchy. Therefore git got confused by what I was doing at usb_subfolder which is lower in the folder hierarchy and that is way it was having amasement inducing reports when trying to do a pull saying that pull is not possible because of unmerged and newly added files.

Thank you to all that replied.