@EliahKagan I think it's fine for them to stay

@EliahKagan Did anything break?

@Kulfy I'm not sure what you mean. Everything seemed to work fine in the system after I ran all those commands and then rebooted. But the first sudo apt dist-upgrade did fail. The commands between it and the second sudo apt dist-upgrade were needed (and the sudo dpkg --configure -a command was needed, though perhaps the first command with --fix-broken could've been omitted).

@EliahKagan I mean like is Unity/GNOME ok? Is everything working fine? Any conflicts in packages? Unmet dependencies?

Since AFAIK do-release upgrade first removes obsolete packages and repository information.

Like I think today extras.ubuntu isn't needed. But if we use sed command, the "extras" will be there. But OTOH, do-release-upgrade will remove all 'extra" repository info.

I didn't notice any problems either time after rebooting into the new system. GNOME worked, LibreOffice and Firefox seemed to work okay, and I was able to install new packages.

@EliahKagan That's great then.

@Kulfy I think there are packages left over that sudo apt --purge autoremove didn't remove. And I'm very reluctant to recommend this procedure, because I think it's almost only of interest to people who are curious if it works. I don't trust the resulting system even though everything seems to work fine. But I've gone through that old page and other ways at that question and none seem to work from 17.04.

Wait! I have missed one that is relevant!

I'm glad I looked through again before posting an answer or something.

Would it make any sense to add some kind of answer index to the question?

Probably yes, but if that answer still works well, it should probably get a bounty. I should test it.

It might also be good to check the anonymous/low-rep feedback on the answers there.

So, I actually don't think that answer will work in this situation. I am not sure.

That answer works in the situation where do-release-upgrade doesn't know there is a release to upgrade to.

But the problem here is that do-release-upgrade does know there is a release to upgrade to, succeeds at downloading the upgrade tool for it, runs the tool, and the too report that upgrading from the current release to it is not supported.

So I'm pretty sure upgrading from Zesty to Bionic won't work using that method. However, that method may still be the best approach there (besides a fresh install, which is actually the best approach) if it will still work to upgrade from Zesty to Artful.

However, I expect that to fail too, because Artful is also EOL now and the stuff for it has been moved to the old-releases server where I don't think the upgrade tool will look for it.

@Zanna It may be a while before I've come up with anything concrete... on the other hand, whatever I find might help in making an answer index for that question because it might reveal what methods are suitable for what situations.

indeed!

@EliahKagan that one has 14 anon upvotes and no anon downvotes

that's a great ratio

Sounds promising. I still don't think it'll work for this... but I'm going to test it with at least Bionic and Artful as direct upgrade targets.

yeah, that can happen, just need to do a few chores and then I will be ready

Okay--cool! It's also all right if it doesn't work out, of course. Either way, I will move these few messages to the Island. :)

← 3 messages moved from Raiders of the Lost Downboat

@Zanna Attempting to upgrade to Bionic that way failed as I expected. But upgrading to Artful looks like it might be working.

If this does work, I expect upgrading from Artful to Bionic to work as well.

@EliahKagan Note that, as shown in the first screenshot, I had to change the URL given in the meta-release file from archive.ubuntu.com/ubuntu/dists/artful-updates/main/… to old-releases.ubuntu.com/ubuntu/dists/artful-updates/main/… in order to download the upgrade tool artful.tar.gz.

If this does work then maybe that answer could use an edit mentioning that and saying when it's necessary.

Still going well:

looks good!

I have a bit of time now

@Zanna Cool.

So how do you want to proceed?

What's the...

...gituation?

hahaha

:D

In the hello-world repository, have you tried running git pull while on a local branch whose remote still exists and that has unfetched commits?

probably not haha

I suggest picking up from there, then.

And then moving on to git push.

So, first, do you feel comfortable with git fetch and understand the difference between that and git pull?

I think so yes

What branches do you have in hello-world right now?

only the master branch

I'll make a new one

Can you make a change to it on GitHub? I suggest committing something to it, or committing something to a new branch and merging from that branch (which you can do on GitHub via a PR).

@Zanna But the changes can also just stay on a new branch. It's up to you.

I will change something on the master branch

Okay.

I mean you can do that by committing on another branch and merging if you want, which is what I think you did before (with the readme-edits branch).

Or you can commit directly to master.

@EliahKagan I did it that way

Okay. So now, locally, what's the output of git status?

Actually, instead of asking that, I should have just suggested that you run:

git status
git pull
git status

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.

nothing to commit, working tree clean

zanna@toaster:~/playground/hello-world$ git pull
remote: Enumerating objects: 6, done.
remote: Counting objects: 100% (6/6), done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 4 (delta 0), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (4/4), done.
From github.com/ZannaStar/hello-world
   294c8e8..3f5ebe3  master     -> origin/master
Updating 294c8e8..3f5ebe3
Fast-forward
 list | 1 +
 1 file changed, 1 insertion(+)
zanna@toaster:~/playground/hello-world$ git status

When you run git pull, that does a fetch as if you ran git fetch (so your remote tracking branches will all be updated) followed by a merge (as if, or in any case usually as if, you then ran git merge), which merges just the branch you're on.

Maybe I'm not getting that... merges just the branch you are on... that is, merges the respective remote tracking branch into the one you're on?

Yes.

So, if you're on master (and assuming that master is set up to synchronize with origin/master as its primary remote tracking branch, which is common but it doesn't have to be that way), then running git merge without specifying anything to merge from merges from origin/master into master.

@Zanna You'll notice that both git status invocations told you "up to date" because, at the time of the first one, your origin/master didn't have the commits yet, and at the time of the second one, it had the commits but they had been not merely fetched but merged into master. You can contrast this with what you saw when you ran git status after running git fetch.

yes

@EliahKagan What I really meant by "merges just the branch you're on" is that is has the same effect you expect to get by running git merge with no arguments.

I would have been surprised if I hadn't got that output the second time I ran git status just now

Surprised because you knew git pull entailed a merge into the current branch, you mean? Or for some other reason?

Sure, but I don't think I had really got what git merge with no arguments would do either :)

But it makes sense now?

yes, definitely, it's clear

Cool. So, can you go ahead and make another change upstream?

@EliahKagan right. I saw the merge even, in the output of git pull. So it was what I expected :)

@EliahKagan doing so

@Zanna But please don't fetch or merge yet afterwards.

@Zanna Excellent.

After causing at least one more commit to be on the upstream master branch (either by committing to it or by committing to another branch and merging), please create and check out a new local branch.

You could also do that before. Either way.

I was surprised to find that the upgrade from Artful to Bionic, which didn't require e to do anything special -- the Software Updater offered it and was able to start it -- actually had errors. It performed the upgrade, but I had to run sudo apt install --fix-broken to fix problems (it ran dpkg --configure -a itself to attempt to fix them, but apparently did not proceed to run apt-get install --fix-broken or equivalent) with a couple packages.

Because the release upgrader tool didn't manage to finish without errors, it didn't remove obsolete packages. I'm not sure if removing obsolete packages is equivalent to the autoremove action in APT or not, but I was able to run sudo apt --purge autoremove successfully. After rebooting, the system seems to work.

The problem might just be with open-vm-tools and open-vm-tools-desktop, which I had installed so I could copy and paste between the virtual machine and the host. However, these packages are from Ubuntu's repositories--from main, even--and they shouldn't have caused a problem.

While on the new local branch, then try running git pull. :)

Unfortunately I didn't take a screenshot of the last message box telling me that the upgrade had completed but with errors. But here's screenshots of the other main things that happened (both good and bad):

$ git pull
remote: Enumerating objects: 5, done.
remote: Counting objects: 100% (5/5), done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 4 (delta 0), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (4/4), done.
From github.com/ZannaStar/hello-world
   3f5ebe3..2ec66c8  master     -> origin/master
There is no tracking information for the current branch.
Please specify which branch you want to merge with.
See git-pull(1) for details.

    git pull <remote> <branch>

is the first part of this output from the fetch?

Yes.

I'm told that the master branch has moved ahead of me, but no merge

:)

The fetch succeeded and you got the changes in origin/master. The attempt to merge to the branch you are currently on from its remote tracking branch failed, because that branch doesn't currently trakc anything.

@Zanna Right. Because the merge is only for the branch you're currently on.

makes perfect sense

If you like, you can run git pull --all and observe that it still doesn't merge to branches other than the one you're currently on. :)

This is a common source of confusion. git pull --all is like running git fetch --all followed by git merge, and thus only attempts to merge to the currently checked out local branch, just like git pull without --all.

same as the second part of the output

The --all option to git fetch fetches from all remotes (because it's possible to have more than one set up, though you don't in this repository).

I was about to ask that

:)

git fetch, and thus git pull, always fetches all branches from the default remote (if any).

@Zanna The first part was different because there was nothing new to fetch, because the previous git pull fetched all the new commits.

yes

Fortunately you can merge the changes into master yourself.

After doing that, try making and committing local changes on master and pushing them.

cool

that worked!

I take it you did this with git push?

zanna@toaster:~/playground/hello-world$ git add words
zanna@toaster:~/playground/hello-world$ git commit
[master f40ee98] added a new word to the list
 1 file changed, 1 insertion(+)
zanna@toaster:~/playground/hello-world$ git push
Username for 'https://github.com': ZannaStar
Password for 'https://[email protected]':
Counting objects: 3, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 295 bytes | 147.00 KiB/s, done.
Total 3 (delta 1), reused 0 (delta 0)

Cool.

then I went to GitHub and refreshed the page and there it was

Yes. That happens. :)

:D

What I recommend you try now is to clone that same remote repository in another directory.

Like, keep the local repository you have for it, but make a new one by cloning (again) from GitHub.

upgrading is a bit dicey even when you're not on an old release

I've actually only had problems upgrading Ubuntu once, except in situations on virtual machines where I'm deliberately trying out weird stuff.

The one time I had problems was when upgrading WSL (on a Windows 10 system) when lxc and lxd related packages were no longer provided by APT and the upgrader tool tried to install the relevant snap packages instead, but failed to do so because snaps aren't supported on WSL systems.

@Zanna Now that the volume has increased, I feel like they should eventually be moved. I'm thinking, we can see how many times it touches on stuff that's on-topic for this room. If seldom, I'll try and pick a point (fairly early) after which the EOL upgrade posts can be moved to the Island.

done

Otherwise... we can figure out which of (a) keeping them and (b) moving them to a new room specifically for them (which will then presumably get frozen automatically but, given the volume of messages, not deleted automatically. How do you feel about this?

sorry that took so long

it took so many attempts to type the password

No problem!

So now, you can commit to both your local repositories and synchronize them both with the remote (and thus each other).

This is essentially the same situation that you have as you've been committing (or performing operations) both from your local repository and from GitHub.

I meant to say, we can figure out which of those things is less bad.

First I recommend committing and pushing from one local repository, then pulling (or fetching and merging) from the other.

if it's not too difficult to move them, then moving them could be good. Otherwise, I don't think it's a big problem for them to remain

Okay. I will either move them or keep them, depending on how things look later.

ok :)

You've done this?

If the on-topic (for the Downboat) aspect ends up being basically limited to if and how an answer index on the EOL upgrades question should be added, then unless that ends up being complicated or controversial, I think all but the earliest messages relating to the new EOL upgrade question could just be moved. Because moved messages show up with arrows, there will be minimal confusion on the Island even though they'll be interleaved with other messsages.

If so, then try making and committing different but non-conflicting local changes to both without pushing either, then pushing one, then attempting to push the other.

@EliahKagan I'm going to restore a snapshot from before I started the release upgrades and try it without those two packages installed (Ubuntu runs okay on a VMware virtual machine without them, and for this purpose the only negative impact will be not having clipboard integration between the host and guest systems).

I get a surprising everything up-to-date

In which situation?

@EliahKagan makes sense

Like, can you describe more what happened and/or show text from the terminal?

@Zanna To be clear, what you're saying sounds normal. I'm not sure why it's surprising.

zanna@toaster:~/playground/hello-world$ vim words
zanna@toaster:~/playground/hello-world$ git add words
zanna@toaster:~/playground/hello-world$ git commit
[master 21ce76f] added a new word
 1 file changed, 1 insertion(+)
zanna@toaster:~/playground/hello-world$ cd ../nest/hello-world/
zanna@toaster:~/playground/nest/hello-world$ vim list
zanna@toaster:~/playground/nest/hello-world$ git add list
zanna@toaster:~/playground/nest/hello-world$ git commit
[master 6944c24] Corrected an entry
 1 file changed, 1 insertion(+), 1 deletion(-)

brb

@Zanna You shouldn't have to type a password to perform remote operations, though. At least not after the first time in a session. Do you have to?

@Zanna Ok.

@Zanna Oh, yeah, that's normal. That's what I'm trying to show. :)

Normally you should fetch or pull before merging if there might be something new on the remote.

@EliahKagan no, that was the first time and haven't been asked for it since

Anyway, what happens when you pull to both local repositories?

@Zanna Ah, good.

@EliahKagan definitely makes sense

Already up-to-date for both

Okay.

Do they both have the changes?

no

Oh, wait.

they both have one change

Did you ever end up pushing from the first local repository?

I don't see that in the text you pasted from your terminal.

You pushed from nest/hello-world but did you push from hello-world?

it's my fault

I'm not actually changing directories when I think I'm doing that

Huh?

haha I thought I was going back to the first repository but I was still in the second one

Oh okay.

when I try to push from the first one I get this

zanna@toaster:~/playground/hello-world$ git push
Username for 'https://github.com': ZannaStar
Password for 'https://[email protected]':
To github.com/ZannaStar/hello-world.git
 ! [rejected]        master -> master (fetch first)
error: failed to push some refs to 'https://github.com/ZannaStar/hello-world.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes

Okay. That's the thing I was going to show you next.

For some reason I thought the simple case you tried first would not do that.

It does though.

So, pushing from multiple local repositories to the same branch on the same remote doesn't merge.

(Actually I should check if it's technically doing a fast-forward merge or not.)

@Zanna So you can fix this problem by doing what it recommends.

That is, run git pull (or git fetch followed by git merge).

Because the commits don't conflict, the merge will succeed easily.

pulled and pushed and now everything looks fine

Excellent.

Now you should be able to pull in the other local repository and see the changes there.

yes :)

Cool. Now try making incompatible changes.

ok!

You could do this by making a change on the remote through the GitHub interface and, without merging the change, committing an incompatible change to the same branch from one of the local repositories. Or you can do it by making the change in a local repository, pushing it, and committing and incompatible change to the smae ranch from the other local repository.

In either case, you could even fetch (but not merge) in the local repository where you then make the incompatible change. git doesn't restrict what you commit to a local branch even if it would conflict with what it already has on a corresponding remote tracking branch.

I'm not saying you should try all those combinations though, unless you really want to. One is enough. :)

@Zanna Do you have a merge conflict now?

yes I do

Excellent.

Is the conflict due to incompatible changes in the same file?

yes

(Technically I think all merge conflicts meet that description. But you can create them by doing things that don't feel like that, like if you're merging with a commit that renames one file and another that renames a different file to the same name.)

Cool.

Rather than just resolving it in vim as you did last time, I'd like to show you some other options.

ok!

First, try running:

git merge --abort

what did that do?

It should have aborted the merge. Did it?

git status should tell you.

zanna@toaster:~/playground/nest/hello-world$ git merge --abort
zanna@toaster:~/playground/nest/hello-world$ git status
On branch master
Your branch and 'origin/master' have diverged,
and have 1 and 1 different commits each, respectively.
  (use "git pull" to merge the remote branch into yours)

nothing to commit, working tree clean

Right. So that successfully aborted the merge.

ok :)

I think you'll have more uses for git merge --abort when you're merging branches that aren't a local branch and its associated remote tracking branch. But I figured this was an opportunity to show it. Plus it could be useful even in this situation.

Okay, so go ahead and create the merge conflict again by running git merge.

(Running git pull did a fetch followed by a merge. You aborted the merge but the effects of the fetch are unaffected.)

@Zanna To clarify, that's the same thing git status shows when your local branch is one commit ahead and one commit behind, whether or not those commits conflict. "Diverged" means what it sounds like--it's about the topology of the graph of commits. It doesn't refer to the conflict.

After bringing the merge conflict back, try running git status.

Then I suggest fixing the merge conflict using a mergetool.

Since I think you've not yet done that.

no I haven't

Do you have the merge conflict back?

you suggested using something called meld

@EliahKagan yes, I have it

@Zanna Yes. It's popular and has a simple interface.

It is a one of many graphical mergetools.

In Ubuntu it is provided by the meld package.

Once you've installed it (or some other merge tool), you can run git mergetool in the local repository where you're merging and have a merge conflcit.

ok, fixed it and pushed the fixed version

What did you think of meld?

Btw you can configure a default mergetool for git (as it would have told you when you ran git mergetool) and, whether or not you have configured a default mergetool, you can run git mergetool with a specific mergetool command by providing that command as an operation to git mergetool's --tool option.

As I'd mentioned before, mergetools are usually also usable as difftools.

I encourage you to try out git difftool.

(It accepts arguments similarly to git diff.)

@EliahKagan I liked it, though it took me a few minutes to figure out what I should do

Mergetools and difftools help you visualize specific changes, but there are also tools to help you visualize the graph of commits in your repository.

I don't remember if you've already tried running:

git log --graph

you mentioned it but I must have been distracted

I love graphs

This (and other techniques for visualizing the graph of your commits) may not be that interesting in your hello-world repository. You might want to try it in a repository that has a more interesting structure, like your recipes repository. You can also pass --all.

If you haven't tried git difftool then I suggest doing so but after that, please do try out git log --graph in both repositories.

The --graph option doesn't affect which commits are displayed from the log or in what order, and it composes just fine with options that do affect that.

yes it was more interesting in the recipes repository as it had numerous layers in the middle, although it's flat now

So for example you can pass the --graph option as well as a non-option argument specifying a branch or commit.

nice :)

@Zanna Even with --all? Did you delete your branches?

(Besides master, I mean.)

yes I deleted them

Is your graph really just a single chain of commits though?

Like, were all merges fast-forwards?

If not, then the graph structure should be more complicated.

Even if all but one of the branches that participated in the merges are deleted (or have since diverged and are not being viewed in the log of the master branch).

there are some layers...

hmm I need to go and take care of some stuff :/

I will run git difftool later

thank you for teaching!

@Zanna Okay!

@Zanna You're welcome! By organizing information in my head, I am also refining my own knowledge.

When you come back, I suggest trying gitg.

:)

I don't think the g stands for "graph."

Git includes a command called gitk, though that is not installed when you install the git package in Ubuntu. You can easily install it through the gitk package and you may want to try it. However, I find that gitg is much, much nicer. These are simple, lightweight tools for visualizing the commits in a repository. There are much nicer and more sophisticated tools (though most, that I'm aware of, are proprietary), but I definitely recommend trying out gitg.

@Zanna Upgrading from Artful to Bionic without the open-vm-tools and open-vm-tools-desktop packages (and packages that were only installed as their dependencies, including dkms) worked without any apparent problems.

gitg is often described as gitk for GNOME, but when I tried installing it on Ubuntu MATE, it didn't pull in much as dependencies.

@EliahKagan nice! It's great you are doing all this testing...

@EliahKagan Why so?

Interacting with snapd is not yet supported on Windows Subsystem for Linux.
This command has been left available for documentation purposes only.

@EliahKagan TIL ^^