Usability outrage as far as I am concerned

Usability outrage as far as I am concerned

[Cristian Achim]

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.

Re: Usability outrage as far as I am concerned

[Ævar Arnfjörð Bjarmason]

On Wed, Dec 20, 2017 at 5:40 PM, Cristian Achim <brancoliticus@gmail.com> wrote:
> 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.

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.

Re: Usability outrage as far as I am concerned

[Jacob Keller]

On Wed, Dec 20, 2017 at 8:40 AM, Cristian Achim <brancoliticus@gmail.com> wrote:
> 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
>

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.

> 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.

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

Re: Usability outrage as far as I am concerned

[Cristian Achim]

> Can you show the output of "git remote"

# in usb_subfolder
$git remote
origin
$

#in home_subfolder
$git remote
$

> and also
> clearly explain with details the layout of what the folders are and
> what is or is not a repository?

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.

Re: Usability outrage as far as I am concerned

[Jacob Keller]

On Fri, Dec 22, 2017 at 7:57 AM, Cristian Achim <brancoliticus@gmail.com> wrote:
>> Can you show the output of "git remote"
>
> # in usb_subfolder
> $git remote
> origin
> $
>
> #in home_subfolder
> $git remote
> $
>

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

>> and also
>> clearly explain with details the layout of what the folders are and
>> what is or is not a repository?
>
> 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.

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.

Re: Usability outrage as far as I am concerned

[Anatolii Borodin]

Hi Jacob,

On Sat, Dec 23, 2017 at 12:05 AM, Jacob Keller <jacob.keller@gmail.com> wrote:
> 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)

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.


-- 
Mit freundlichen Grüßen,
Anatolii Borodin

Re: Usability outrage as far as I am concerned

[Cristian Achim]

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.