Re: [lmi] konsole clipboard stopped working (fixed)

[Vadim Zeitlin]

On Fri, 3 Nov 2017 12:57:04 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2017-11-02 17:23, Vadim Zeitlin wrote:
[...]
GC> > Of course, it absolutely doesn't hurt to run it in any case, although
GC> > personally I prefer "git fetch --all" (which is its exact synonym
GC> > AFAICS) that I find more clear.
GC> 
GC> I'm guessing that what I really want is
GC>   git fetch --all --dry-run
...
GC> Yes, it is, so that's the command I want.

 Well, yes and no. "Yes" in the sense that it does work in the way you
want, but it's inefficient and requires completely unnecessary multiple
trips to the server. So I would still recommend omitting the "--dry-run"
part. "git fetch" doesn't modify the working tree (or index) in any way, so
while it's "mutating", strictly speaking, it only mutates Git internal
storage and this shouldn't, and doesn't, matter in any way to you. You also
shouldn't rely on the (purely informative) messages from git fetch, if only
because they're not idempotent, but compare your branch directly with its
remote counterpart to get the real state of things. I.e. the right commands
to check the state of the local branch are

        $ git fetch # --all if you want but you typically only need one

        # This assumes you're on the local branch already
        $ git log ..remote/branch
        ... or ...
        $ git diff remote/branch
        ... or ...
        $ git diff --stat remote/branch

and so on. Notice that the "..remote/branch" is the same as
"HEAD..remote/branch" which is (by assumption above) the same as
"branch..remote/branch" and means "all the commits in remote/branch but not
in the local branch", i.e. all the new commits. If you want to view all the
commits done in your branch but not pushed to the remote yet, you would
reverse the order and use "remote/branch..". And if you wanted to view all
commits not present in both branches, i.e. the union of these two commands
output, you could use "remote/branch..." or "...remote/branch" -- the order
here doesn't matter as "..." is symmetric. Personally I prefer to avoid
"..." however and just run 2 separate commands instead as I find it more
clear.

[Purely theoretic digression]

 You may notice that there is an inevitable race condition here: someone
could change the remote branch between your execution of "git fetch" and
"git log-or-diff" and you won't know it until you tried to "git push" your
branch which would then be refused by server as being out of date. And you
would need to redo "git fetch" then, merge or rebase your changes and push
again and hope the remote branch hasn't changed in the meanwhile. This is
indeed a problem for some very busy repositories with hundreds or even
thousands of contributors, but it has, of course, no chances of happening
with lmi, so I'll just ignore this possibility.

[End of digression]


 And if you want to update your local branch to be the same as the remote
branch, you don't need to run "git pull" as it would do "git fetch" again
which is unnecessary because you've just done it. Instead, you can do

        $ git merge --ff-only remote/branch

to advance your branch pointer to point to the last commit in the remote
branch if you don't have any local commits not present remotely. If you do
have them, and the remote branch also has some commits that you don't have,
it means that your branches have diverged. There is nothing tragic in this,
but it does mean that you have the choice between doing a real merge or
just rebasing your changes on top of those done remotely. Usually, for one
(or few unrelated) commits you would prefer to rebase to keep the (branch)
history linear while more involved sets of changes would merit having their
own (sub-)branch and be merged at the end. But we can speak more about this
when/if you run into such situation, which normally shouldn't happen any
time soon.

 Regards,
VZ