Obscure error/warning/information message from git pull

Obscure error/warning/information message from git pull

[Alan Mackenzie]

Hello, Emacs.

Would somebody please help me with our new wonderfully simple and
elegant version control system.

I have two repositories in directories named .../master and
.../emacs-24, the second having been cloned from the first.

I've done "git pull" in master, and it seems to have worked.  I did "git
pull" in .../emacs-24, and it didn't work.  (Error messages lost).

When I now do "git pull" in .../emacs-24, I get the following
gobbledegook:

    Your configuration specifies to merge with the ref 'emacs-24'
    from the remote, but no such ref was fetched.

Is this an error message, is it a warning, or is merely informational?
I've a vague idea of what "ref" means here (having looked at the git
glossary), but not what "the remote" means (is it referring to the
.../master repository, or is it something within .../emacs-24?).

What does the ungrammatical "specifies to merge with the ref 'emacs-24'"
mean?  What does 'emacs-24' refer to?  Is it the branch within the
repository?  And what are the things, one of them implicit, that are to
be merged here, and where does the result of this merge go?

What about "but no such ref was fetched"?  Fetched from where?  From the
.../master repository, perhaps?

Is this message telling me that there are no changes to .../emacs-24, or
what?  Or is it telling me my configuration is broken?  Here is my
.../emacs-24/.git/config:

   [core]
          repositoryformatversion = 0
          filemode = true
          bare = false
          logallrefupdates = true
   [remote "origin"]
          url = /home/acm/emacs/emacs.git/master/.
          fetch = +refs/heads/*:refs/remotes/origin/*
   [branch "master"]
          remote = origin
          merge = refs/heads/master
   [branch "emacs-24"]
          remote = origin
          merge = refs/heads/emacs-24


I then tried looking at the log in .../master, to see if that might give
me a clue.  Not really.  It just lists a load of commits without saying
which branch they're in.  Does that mean they're all in the master
branch, and there's none in the emacs-24 branch?  This is where version
numbers would have come in handy, to see if there's anything missing.

Then I wanted to list only those those commits in the emacs-24 branch.
Ha!  "git help log" was of no help.  It goes into a man page, and there
is nothing helpful there thus to restrict the display.  There appears
not to be an option such as "-b emacs-24".  There is a "--branches"
option, but what that is supposed to do is completely opaque to me.  How
do I do what I want, here?

Thanks for the help!

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Obscure error/warning/information message from git pull

[Tassilo Horn]

Alan Mackenzie <acm@muc.de> writes:

Hi Alan,

> I have two repositories in directories named .../master and
> .../emacs-24, the second having been cloned from the first.

I'm no git super-expert, but using

  git clone tsdh@git.sv.gnu.org:/srv/git/emacs.git

I got a clone of the official repo containing all branches with the
master branch being current.  Then I did

  cd emacs
  git checkout emacs-24
  cd ..
  git clone emacs emacs-24

which gave me a new directory emacs-24 that automatically tracks the
emacs-24 branch so that I can pull/push in there.  However, now the
origin remote is the directory ../emacs, not savannah, so pulling/
pushing works with that, not upstream on savannah.  So I changed
emacs-24/.git/config from

--8<---------------cut here---------------start------------->8---
[core]
	repositoryformatversion = 0
	filemode = true
	bare = false
	logallrefupdates = true
[remote "origin"]
	url = /home/horn/Repos/el/emacs
	fetch = +refs/heads/*:refs/remotes/origin/*
[branch "emacs-24"]
	remote = origin
	merge = refs/heads/emacs-24
--8<---------------cut here---------------end--------------->8---

to

--8<---------------cut here---------------start------------->8---
[core]
	repositoryformatversion = 0
	filemode = true
	bare = false
	logallrefupdates = true
[remote "origin"]
	url = tsdh@git.sv.gnu.org:/srv/git/emacs.git
	fetch = +refs/heads/*:refs/remotes/origin/*
[branch "emacs-24"]
	remote = origin
	merge = refs/heads/emacs-24
--8<---------------cut here---------------end--------------->8---

Well, the result was that another "git pull" downloaded quite some
stuff, so now I also have all branches available also in emacs-24.  I
think I should have set the fetch ref-spec to emacs-24 instead of *
above...  Who knows.  But still my emacs-24 dir is only 364M whereas the
emacs dir I cloned from savannah is 619M.

Anyway, now I did

  cd ../emacs
  git checkout master

so that I have the master branch in emacs/ and the emacs-24 branch in
emacs-24/.  Pulling works in both, pushing untested so far (but I'm
pretty sure it'll do the trick).

> glossary), but not what "the remote" means (is it referring to the
> .../master repository, or is it something within .../emacs-24?).

The remotes are the servers you are pulling/pushing with.  The origin
remote is the one you initially cloned from, i.e., savannah.  It can
also be a directory if you did "git clone path/to/emacs
path/to/emacs-foo".

> What about "but no such ref was fetched"?  Fetched from where?  From
> the .../master repository, perhaps?

I guess your problem is that "git clone dir1 dir2" doesn't create a full
copy of all branches but only the branch that was current in dir1 which
is probably master in your case.  That's why I've switched to emacs-24
before cloning in my receipe above.

> Then I wanted to list only those those commits in the emacs-24 branch.
> Ha!  "git help log" was of no help.  It goes into a man page, and
> there is nothing helpful there thus to restrict the display.  There
> appears not to be an option such as "-b emacs-24".  There is a
> "--branches" option, but what that is supposed to do is completely
> opaque to me.  How do I do what I want, here?

Probably, "git checkout emacs-24 && git log".

HTH,
Tassilo

Re: Obscure error/warning/information message from git pull

[Andreas Schwab]

Tassilo Horn <tsdh@gnu.org> writes:

> So I changed emacs-24/.git/config

git remote set-url origin <url>

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Obscure error/warning/information message from git pull

[Andreas Schwab]

Alan Mackenzie <acm@muc.de> writes:

> I have two repositories in directories named .../master and
> .../emacs-24, the second having been cloned from the first.

I'd be much easier if you used git new-workdir.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Obscure error/warning/information message from git pull

[Lars Magne Ingebrigtsen]

Andreas Schwab <schwab@linux-m68k.org> writes:

> I'd be much easier if you used git new-workdir.

Let's see...  "git new-workdir" doesn't seem to exist on Debian Stale,
but it's in the contrib directory, so let's give it a go...

[larsi@stories ~/src]$ sh /usr/share/doc/git/contrib/workdir/git-new-workdir emacs 24-emacs
[larsi@stories ~/src]$ cd 24-emacs/
[larsi@stories ~/src/24-emacs]$ git checkout emacs-24
Branch emacs-24 set up to track remote branch emacs-24 from origin.
Switched to a new branch 'emacs-24'

<Here I check in a trivial .gitignore fix.>

[larsi@stories ~/src/24-emacs]$ git push
Counting objects: 5, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 355 bytes, done.
Total 3 (delta 2), reused 0 (delta 0)
remote: Sending notification emails to: emacs-diffs@gnu.org
To larsi@git.sv.gnu.org:/srv/git/emacs.git
   6688117..6a079d5  emacs-24 -> emacs-24

Yay!  It worked.

Perhaps somebody should put this on the wiki.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Obscure error/warning/information message from git pull

[Tassilo Horn]

Andreas Schwab <schwab@linux-m68k.org> writes:

> Alan Mackenzie <acm@muc.de> writes:
>
>> I have two repositories in directories named .../master and
>> .../emacs-24, the second having been cloned from the first.
>
> I'd be much easier if you used git new-workdir.

Hm, I have /usr/share/git/workdir/git-new-workdir on my system but what
do I have to do to enable it so that I can call "git new-workdir"?

Bye,
Tassilo

Re: Obscure error/warning/information message from git pull

[Andrew Burgess]

* Tassilo Horn <tsdh@gnu.org> [2014-11-14 14:10:15 +0100]:

> Alan Mackenzie <acm@muc.de> writes:
>
> > Then I wanted to list only those those commits in the emacs-24 branch.
> > Ha!  "git help log" was of no help.  It goes into a man page, and
> > there is nothing helpful there thus to restrict the display.  There
> > appears not to be an option such as "-b emacs-24".  There is a
> > "--branches" option, but what that is supposed to do is completely
> > opaque to me.  How do I do what I want, here?
>
> Probably, "git checkout emacs-24 && git log".

This is correct, but you can skip the checkout and just do:

  git log some-branch

to get a log of all commits in the local branch 'some-branch'.
Alternatively so see what's in the same branch on the remote:

  git log origin/some-branch

this will not include any commits you've made to your local copy of
'some-branch' (and assumes that you're remote is called origin).

Another useful feature I use a lot is:

  git log some-branch -- path/to/a/file

this restricts the log to only those commits on 'some-branch' that
touch 'path/to/a/file'.

HTH
Andrew

Re: Obscure error/warning/information message from git pull

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Date: Fri, 14 Nov 2014 14:46:20 +0100
> Cc: emacs-devel@gnu.org
> 
> I'd be much easier if you used git new-workdir.

Which Git versions are safe to use with this?  What are the caveats?
(I presume there are caveats, since you said on several occasions that
"it is being worked on".)

TIA

Re: Obscure error/warning/information message from git pull

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andreas Schwab <schwab@linux-m68k.org>
>> Date: Fri, 14 Nov 2014 14:46:20 +0100
>> Cc: emacs-devel@gnu.org
>> 
>> I'd be much easier if you used git new-workdir.
>
> Which Git versions are safe to use with this?  What are the caveats?

You just should avoid working on the same branch in different work
directories.  It won't result in data loss, but you might get confused.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Obscure error/warning/information message from git pull

[Andreas Schwab]

Tassilo Horn <tsdh@gnu.org> writes:

> Hm, I have /usr/share/git/workdir/git-new-workdir on my system but what
> do I have to do to enable it so that I can call "git new-workdir"?

Just put in PATH.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Obscure error/warning/information message from git pull

[Lars Magne Ingebrigtsen]

Andreas Schwab <schwab@linux-m68k.org> writes:

> Tassilo Horn <tsdh@gnu.org> writes:
>
>> Hm, I have /usr/share/git/workdir/git-new-workdir on my system but what
>> do I have to do to enable it so that I can call "git new-workdir"?
>
> Just put in PATH.

And chmod a+X it.  It's not executable by default -- at least in Debian
Stale.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Obscure error/warning/information message from git pull

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: acm@muc.de,  emacs-devel@gnu.org
> Date: Fri, 14 Nov 2014 16:50:52 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> I'd be much easier if you used git new-workdir.
> >
> > Which Git versions are safe to use with this?  What are the caveats?
> 
> You just should avoid working on the same branch in different work
> directories.

If that's all, then it will be easy to avoid.  Thanks.

Re: Obscure error/warning/information message from git pull

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Date: Fri, 14 Nov 2014 16:51:26 +0100
> Cc: emacs-devel@gnu.org
> 
> Tassilo Horn <tsdh@gnu.org> writes:
> 
> > Hm, I have /usr/share/git/workdir/git-new-workdir on my system but what
> > do I have to do to enable it so that I can call "git new-workdir"?
> 
> Just put in PATH.

Also, AFAIU, this script is only invoked once per new-dir, so it can
even be left out of PATH, no big deal.

Re: Obscure error/warning/information message from git pull

[Michael Welsh Duggan]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andreas Schwab <schwab@linux-m68k.org>
>> Date: Fri, 14 Nov 2014 14:46:20 +0100
>> Cc: emacs-devel@gnu.org
>> 
>> I'd be much easier if you used git new-workdir.
>
> Which Git versions are safe to use with this?  What are the caveats?
> (I presume there are caveats, since you said on several occasions that
> "it is being worked on".)

Looking at the shell script, what it does is create the new work
directory and a .git dir within it, and then symbolically links all
important files/directories from the original repository's .git
directory into the new .git dir, using ln -s.  The HEAD link is copied
rather than symlinked.

So, from Windows this will probably work if "ln -s" does something
reasonable and all the underlying stuff your version of git uses deals
with symlinks properly.  (This wasn't always a reasonable assumption
under Windows in the past.  You would know better than me what the
current state of symlinks on Windows is.)

-- 
Michael Welsh Duggan
(md5i@md5i.com)

Re: Obscure error/warning/information message from git pull

[Eli Zaretskii]

> From: Michael Welsh Duggan <mwd@md5i.com>
> Cc: Andreas Schwab <schwab@linux-m68k.org>,  acm@muc.de,  emacs-devel@gnu.org
> Date: Fri, 14 Nov 2014 12:03:43 -0500
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Andreas Schwab <schwab@linux-m68k.org>
> >> Date: Fri, 14 Nov 2014 14:46:20 +0100
> >> Cc: emacs-devel@gnu.org
> >> 
> >> I'd be much easier if you used git new-workdir.
> >
> > Which Git versions are safe to use with this?  What are the caveats?
> > (I presume there are caveats, since you said on several occasions that
> > "it is being worked on".)
> 
> Looking at the shell script, what it does is create the new work
> directory and a .git dir within it, and then symbolically links all
> important files/directories from the original repository's .git
> directory into the new .git dir, using ln -s.  The HEAD link is copied
> rather than symlinked.

Yes, I've read the script (before asking ;-).

> So, from Windows this will probably work if "ln -s" does something
> reasonable and all the underlying stuff your version of git uses deals
> with symlinks properly.  (This wasn't always a reasonable assumption
> under Windows in the past.  You would know better than me what the
> current state of symlinks on Windows is.)

I wasn't asking about Windows.  It is clear to me by reading the
script that using that on Windows is a bad idea, because symlinks are
(a) only supported since Vista, and (b) require to run the script "As
Administrator".  (And then there's a known caveat of removing the
symlinked directory that actually removes the target, if you aren't
careful to use rmdir.)

No, I was asking in general about potential problems, since Andreas
said several times that the feature is being improved.

Re: Obscure error/warning/information message from git pull

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> I wasn't asking about Windows.  It is clear to me by reading the
> script that using that on Windows is a bad idea, because symlinks are
> (a) only supported since Vista, and (b) require to run the script "As
> Administrator".  (And then there's a known caveat of removing the
> symlinked directory that actually removes the target, if you aren't
> careful to use rmdir.)

This is another point being worked on.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Obscure error/warning/information message from git pull

[Alan Mackenzie]

Hello, Andrew.

Thanks for the answer!

On Fri, Nov 14, 2014 at 03:14:34PM +0100, Andrew Burgess wrote:
> * Tassilo Horn <tsdh@gnu.org> [2014-11-14 14:10:15 +0100]:

> > Alan Mackenzie <acm@muc.de> writes:

> > > Then I wanted to list only those those commits in the emacs-24 branch.
> > > Ha!  "git help log" was of no help.  It goes into a man page, and
> > > there is nothing helpful there thus to restrict the display.  There
> > > appears not to be an option such as "-b emacs-24".  There is a
> > > "--branches" option, but what that is supposed to do is completely
> > > opaque to me.  How do I do what I want, here?

> > Probably, "git checkout emacs-24 && git log".

> This is correct, but you can skip the checkout and just do:

>   git log some-branch

> to get a log of all commits in the local branch 'some-branch'.
> Alternatively so see what's in the same branch on the remote:

Thanks!  But the log doesn't identify which branch the commits are in.
How do I persuade git log to do this?

Now, I've discovered I can do

    git log -n5 emacs24 master --

and this works, but it doesn't say which commit is in which branch.
YUCK.

It seems also that git clone hasn't worked properly.  The above command
didn't work until I "initialised" the emacs-24 branch by doing

    git checkout emacs-24

.  What's going on here?

git log is being piped into less, which is objectionable.  If I want it
in less, I'm quite capable of saying so.  Is there a flag I can give to
stop my stdout being hijacked, or can I configure it away somehow?

>   git log origin/some-branch

> this will not include any commits you've made to your local copy of
> 'some-branch' (and assumes that you're remote is called origin).

What does "origin" mean here?  Is it the repository whence the current
repository was cloned, or is it the one in savannah?

> Another useful feature I use a lot is:

>   git log some-branch -- path/to/a/file

> this restricts the log to only those commits on 'some-branch' that
> touch 'path/to/a/file'.

How do I specify "git log ALL-branches -- path/to/a/file".  This doesn't
seem to be the default.  Or am I just confused?

> HTH

It does!

> Andrew

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Obscure error/warning/information message from git pull

[Andreas Schwab]

Alan Mackenzie <acm@muc.de> writes:

> Thanks!  But the log doesn't identify which branch the commits are in.
> How do I persuade git log to do this?

git log --decorate

(permanently: git config [--global] log.decorate true)

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Obscure error/warning/information message from git pull

[Alan Mackenzie]

Hello, Andreas.

On Fri, Nov 14, 2014 at 07:58:14PM +0100, Andreas Schwab wrote:
> Alan Mackenzie <acm@muc.de> writes:

> > Thanks!  But the log doesn't identify which branch the commits are in.
> > How do I persuade git log to do this?

> git log --decorate

This doesn't work very well.  It prints out the information for the first
commit that is displayed, but no more.  This feels like a git bug.

> (permanently: git config [--global] log.decorate true)

> Andreas.

> -- 
> Andreas Schwab, schwab@linux-m68k.org
> GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
> "And now for something completely different."

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Obscure error/warning/information message from git pull

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: Michael Welsh Duggan <mwd@md5i.com>,  acm@muc.de,  emacs-devel@gnu.org
> Date: Fri, 14 Nov 2014 18:30:00 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I wasn't asking about Windows.  It is clear to me by reading the
> > script that using that on Windows is a bad idea, because symlinks are
> > (a) only supported since Vista, and (b) require to run the script "As
> > Administrator".  (And then there's a known caveat of removing the
> > symlinked directory that actually removes the target, if you aren't
> > careful to use rmdir.)
> 
> This is another point being worked on.

You mean, avoid using symlinks?  Or prevent accidental removal of the
original meta-data?

Re: Obscure error/warning/information message from git pull

[Tassilo Horn]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

>>> Hm, I have /usr/share/git/workdir/git-new-workdir on my system but
>>> what do I have to do to enable it so that I can call "git
>>> new-workdir"?
>>
>> Just put in PATH.
>
> And chmod a+X it.  It's not executable by default -- at least in
> Debian Stale.

Interesting.  It seems you can execute any command/script that starts
with "git-" as git command, e.g., I have a ruby script
`git-find-big-file.rb' in PATH which I can also execute as "git
find-big-file.rb".

Bye,
Tassilo

Re: Obscure error/warning/information message from git pull

[Christoph]

[-- Attachment #1: Type: text/plain, Size: 1093 bytes --]

I have this in my ~/.gitconfig file (global system configuration):

[alias]
    lg = log --graph --pretty=format:'%Cred%h%Creset
-%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset'
--abbrev-commit --date=relative


That gives me a prettiER (more useful) view of the log with 'git lg'.


On Fri, Nov 14, 2014 at 1:09 PM, Alan Mackenzie <acm@muc.de> wrote:

> Hello, Andreas.
>
> On Fri, Nov 14, 2014 at 07:58:14PM +0100, Andreas Schwab wrote:
> > Alan Mackenzie <acm@muc.de> writes:
>
> > > Thanks!  But the log doesn't identify which branch the commits are in.
> > > How do I persuade git log to do this?
>
> > git log --decorate
>
> This doesn't work very well.  It prints out the information for the first
> commit that is displayed, but no more.  This feels like a git bug.
>
> > (permanently: git config [--global] log.decorate true)
>
> > Andreas.
>
> > --
> > Andreas Schwab, schwab@linux-m68k.org
> > GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
> > "And now for something completely different."
>
> --
> Alan Mackenzie (Nuremberg, Germany).
>
>

[-- Attachment #2: Type: text/html, Size: 2125 bytes --]

Re: Obscure error/warning/information message from git pull

[Tassilo Horn]

Alan Mackenzie <acm@muc.de> writes:

> git log is being piped into less, which is objectionable.  If I want it
> in less, I'm quite capable of saying so.  Is there a flag I can give to
> stop my stdout being hijacked, or can I configure it away somehow?

As soon as you redirect it won't be piped into less.  But you can either
specify the global git option --no-pager, e.g.,

  git --no-pager log

or configure

  git config --global core.pager cat

But with that, you'll always see Jim Blandy's commit from 1985 in "git
log" and then have to scroll up some million lines...

Bye,
Tassilo

Re: Obscure error/warning/information message from git pull

[Eli Zaretskii]

> From: Tassilo Horn <tsdh@gnu.org>
> Date: Fri, 14 Nov 2014 21:41:26 +0100
> Cc: Alan Mackenzie <acm@muc.de>, Andreas Schwab <schwab@linux-m68k.org>,
> 	emacs-devel@gnu.org
> 
> Interesting.  It seems you can execute any command/script that starts
> with "git-" as git command

Welcome to git.

Re: Obscure error/warning/information message from git pull

[Andreas Schwab]

Alan Mackenzie <acm@muc.de> writes:

> Hello, Andreas.
>
> On Fri, Nov 14, 2014 at 07:58:14PM +0100, Andreas Schwab wrote:
>> Alan Mackenzie <acm@muc.de> writes:
>
>> > Thanks!  But the log doesn't identify which branch the commits are in.
>> > How do I persuade git log to do this?
>
>> git log --decorate
>
> This doesn't work very well.  It prints out the information for the first
> commit that is displayed, but no more.  This feels like a git bug.

No, this is the correct behaviour.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Obscure error/warning/information message from git pull

[Sergey Organov]

Alan Mackenzie <acm@muc.de> writes:

> Hello, Andrew.
>
> Thanks for the answer!
>
> On Fri, Nov 14, 2014 at 03:14:34PM +0100, Andrew Burgess wrote:
>> * Tassilo Horn <tsdh@gnu.org> [2014-11-14 14:10:15 +0100]:
>
>> > Alan Mackenzie <acm@muc.de> writes:
>
>> > > Then I wanted to list only those those commits in the emacs-24 branch.
>> > > Ha!  "git help log" was of no help.  It goes into a man page, and
>> > > there is nothing helpful there thus to restrict the display.  There
>> > > appears not to be an option such as "-b emacs-24".  There is a
>> > > "--branches" option, but what that is supposed to do is completely
>> > > opaque to me.  How do I do what I want, here?
>
>> > Probably, "git checkout emacs-24 && git log".
>
>> This is correct, but you can skip the checkout and just do:
>
>>   git log some-branch
>
>> to get a log of all commits in the local branch 'some-branch'.
>> Alternatively so see what's in the same branch on the remote:
>
> Thanks!  But the log doesn't identify which branch the commits are in.
> How do I persuade git log to do this?
>
> Now, I've discovered I can do
>
>     git log -n5 emacs24 master --
>
> and this works, but it doesn't say which commit is in which branch.
> YUCK.

Because in GIT commits are not on a branch. All commits are arranged into
DAG, and branch is just a pointer into the DAG. Any given commit is
either reachable from given branch or not. It's that simple.

Try:

$ git log --oneline --decorate emacs24 ^master

that will show all commits that are reachable from 'emacs24' but not
reachable from 'master'.

Look up SPECIFYING RANGES in

$ man gitrevisions

for other possibilities.

Also try:

$ git show-branch emacs24 master

HTH.

-- 
Sergey.

Re: Obscure error/warning/information message from git pull

[David Kastrup]

Alan Mackenzie <acm@muc.de> writes:

> Hello, Andrew.
>
> Thanks for the answer!
>
> On Fri, Nov 14, 2014 at 03:14:34PM +0100, Andrew Burgess wrote:
>> * Tassilo Horn <tsdh@gnu.org> [2014-11-14 14:10:15 +0100]:
>
>> > Alan Mackenzie <acm@muc.de> writes:
>
>> > > Then I wanted to list only those those commits in the emacs-24 branch.
>> > > Ha!  "git help log" was of no help.  It goes into a man page, and
>> > > there is nothing helpful there thus to restrict the display.  There
>> > > appears not to be an option such as "-b emacs-24".  There is a
>> > > "--branches" option, but what that is supposed to do is completely
>> > > opaque to me.  How do I do what I want, here?
>
>> > Probably, "git checkout emacs-24 && git log".
>
>> This is correct, but you can skip the checkout and just do:
>
>>   git log some-branch
>
>> to get a log of all commits in the local branch 'some-branch'.
>> Alternatively so see what's in the same branch on the remote:
>
> Thanks!  But the log doesn't identify which branch the commits are in.
> How do I persuade git log to do this?
>
> Now, I've discovered I can do
>
>     git log -n5 emacs24 master --
>
> and this works, but it doesn't say which commit is in which branch.
> YUCK.

git log --decorate marks _all_ branch _heads_, git log --source tells
through which reference it reached every displayed commit (which does
not mean that this would be the only way to reach them).

In practice, for multi-branch displays git log --graph is much more
helpful.

-- 
David Kastrup

Re: Obscure error/warning/information message from git pull

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andreas Schwab <schwab@linux-m68k.org>
>> Cc: Michael Welsh Duggan <mwd@md5i.com>,  acm@muc.de,  emacs-devel@gnu.org
>> Date: Fri, 14 Nov 2014 18:30:00 +0100
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > I wasn't asking about Windows.  It is clear to me by reading the
>> > script that using that on Windows is a bad idea, because symlinks are
>> > (a) only supported since Vista, and (b) require to run the script "As
>> > Administrator".  (And then there's a known caveat of removing the
>> > symlinked directory that actually removes the target, if you aren't
>> > careful to use rmdir.)
>> 
>> This is another point being worked on.
>
> You mean, avoid using symlinks?  Or prevent accidental removal of the
> original meta-data?

The first, which implies the latter IIUC.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Obscure error/warning/information message from git pull

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

> I wasn't asking about Windows.  It is clear to me by reading the
> script that using that on Windows is a bad idea, because symlinks are
> (a) only supported since Vista, and (b) require to run the script "As
> Administrator".  (And then there's a known caveat of removing the
> symlinked directory that actually removes the target, if you aren't
> careful to use rmdir.)

It's things like this that make me wonder whether the system programmers
at Microsoft are forbidden from using any other operating system.

How would anyone with modest exposure to decent operating systems stand
this kind of thing?

As programmer I somewhat regularly encounter the situation "this
behavior is far too inconsistent to make it worth documenting: let's
rather work on fixing it first".  It usually does not even need the
comparison to other systems to figure out the bad stuff from the good.

Now I can understand that at some times commercial development results
in decisions like "we won't invest work on implementing this".  But
"we'll invest into creating a quite crippled and mostly useless version
of the feature": where is the point in that?

How does this work?  Somebody knowing the feature from other system pins
down the salient points on a piece of scrap paper, someone else who
never saw it and speaks a different language then writes the spec sheet,
and somebody else who never saw the point in that feature implements
those parts of that spec sheet that are easiest to do?

Something must be going seriously wrong somewhere, and it's not the
first time that I cannot fathom just what.

-- 
David Kastrup

Re: Obscure error/warning/information message from git pull

[Eli Zaretskii]

> From: Sergey Organov <sorganov@gmail.com>
> Date: Fri, 14 Nov 2014 23:57:56 +0300
> 
> >     git log -n5 emacs24 master --
> >
> > and this works, but it doesn't say which commit is in which branch.
> > YUCK.
> 
> Because in GIT commits are not on a branch. All commits are arranged into
> DAG, and branch is just a pointer into the DAG. Any given commit is
> either reachable from given branch or not. It's that simple.

You just re-defined "on a branch", that's all.  A commit that's
reachable from a branch is on that branch.  It's that simple.

Re: Obscure error/warning/information message from git pull

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: mwd@md5i.com,  acm@muc.de,  emacs-devel@gnu.org
> Date: Fri, 14 Nov 2014 22:12:36 +0100
> 
> >> > I wasn't asking about Windows.  It is clear to me by reading the
> >> > script that using that on Windows is a bad idea, because symlinks are
> >> > (a) only supported since Vista, and (b) require to run the script "As
> >> > Administrator".  (And then there's a known caveat of removing the
> >> > symlinked directory that actually removes the target, if you aren't
> >> > careful to use rmdir.)
> >> 
> >> This is another point being worked on.
> >
> > You mean, avoid using symlinks?  Or prevent accidental removal of the
> > original meta-data?
> 
> The first, which implies the latter IIUC.

It does.  Thanks.

Re: Obscure error/warning/information message from git pull

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Fri, 14 Nov 2014 22:18:21 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I wasn't asking about Windows.  It is clear to me by reading the
> > script that using that on Windows is a bad idea, because symlinks are
> > (a) only supported since Vista, and (b) require to run the script "As
> > Administrator".  (And then there's a known caveat of removing the
> > symlinked directory that actually removes the target, if you aren't
> > careful to use rmdir.)
> 
> It's things like this that make me wonder whether the system programmers
> at Microsoft are forbidden from using any other operating system.
> 
> How would anyone with modest exposure to decent operating systems stand
> this kind of thing?
> 
> As programmer I somewhat regularly encounter the situation "this
> behavior is far too inconsistent to make it worth documenting: let's
> rather work on fixing it first".  It usually does not even need the
> comparison to other systems to figure out the bad stuff from the good.
> 
> Now I can understand that at some times commercial development results
> in decisions like "we won't invest work on implementing this".  But
> "we'll invest into creating a quite crippled and mostly useless version
> of the feature": where is the point in that?
> 
> How does this work?  Somebody knowing the feature from other system pins
> down the salient points on a piece of scrap paper, someone else who
> never saw it and speaks a different language then writes the spec sheet,
> and somebody else who never saw the point in that feature implements
> those parts of that spec sheet that are easiest to do?

Not sure what you are steaming about.  If that's the fact that
creating symlinks requires privileges, then the rationale is that a
suitably pointed symlink can be used to circumvent security
permissions.  I'm not a security expert, so I don't know whether this
argument holds water.

If you are talking about the accidental removal, then using "DEL" (the
equivalent of the Unix 'rm') to remove a symlink to a directory is
actually a Unix-ism brought to Windows, because on Windows a symlink
to a directory is treated as a directory, and has the directory mode
bit set.  For any directory X, "DEL X" always meant "remove all files
in X" on Windows.  Therefore, doing that with a symlink to a directory
simply behaves like DEL always behaved.  The culprit is the Unix
semantics molded on the muscle memory of those who type such commands
on Windows.

> Something must be going seriously wrong somewhere, and it's not the
> first time that I cannot fathom just what.

A very pertinent observation in a discussion about Git.

Re: Obscure error/warning/information message from git pull

[Alan Mackenzie]

Hello, Andreas.

On Fri, Nov 14, 2014 at 09:52:37PM +0100, Andreas Schwab wrote:
> Alan Mackenzie <acm@muc.de> writes:

> > Hello, Andreas.

> > On Fri, Nov 14, 2014 at 07:58:14PM +0100, Andreas Schwab wrote:
> >> Alan Mackenzie <acm@muc.de> writes:

> >> > Thanks!  But the log doesn't identify which branch the commits are in.
> >> > How do I persuade git log to do this?

> >> git log --decorate

> > This doesn't work very well.  It prints out the information for the first
> > commit that is displayed, but no more.  This feels like a git bug.

> No, this is the correct behaviour.

So, not very useful, then.  Also not what the FM says:

    "Print out the ref names of any commits that are shown."

.  Not one commit, but any (i.e. all) commits.  Of course, that's all
dependent on knowing what "ref name" means.  I suppose you're going to
tell me next that only the first commit actually has a "ref name"
(whatever that is).  But if you do, it would be really nice if you could
explain what is meant by "ref name", or even point me at a non
content-free definition.  :-)

> Andreas.

> -- 
> Andreas Schwab, schwab@linux-m68k.org
> GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
> "And now for something completely different."

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Obscure error/warning/information message from git pull

[Alan Mackenzie]

Hello, Sergey.

On Fri, Nov 14, 2014 at 11:57:56PM +0300, Sergey Organov wrote:
> Alan Mackenzie <acm@muc.de> writes:

> > Thanks!  But the log doesn't identify which branch the commits are in.
> > How do I persuade git log to do this?

> > Now, I've discovered I can do

> >     git log -n5 emacs24 master --

> > and this works, but it doesn't say which commit is in which branch.
> > YUCK.

> Because in GIT commits are not on a branch. All commits are arranged into
> DAG, and branch is just a pointer into the DAG. Any given commit is
> either reachable from given branch or not. It's that simple.

I think you're just playing with words, here.  We all know what a branch
is, and git knows which revisions are on which branch (or branches?),
otherwise your command below couldn't work.

> Try:

> $ git log --oneline --decorate emacs24 ^master

> that will show all commits that are reachable from 'emacs24' but not
> reachable from 'master'.

That's very impressive, but not what I want.  I want to see all recent
commits together, each one annotated with which branch it's on.  That's
surely not too much to ask for.  I want annotation, not filtering.

> Look up SPECIFYING RANGES in

> $ man gitrevisions

> for other possibilities.

> Also try:

> $ git show-branch emacs24 master

> HTH.

> -- 
> Sergey.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Obscure error/warning/information message from git pull

[David Engster]

Alan Mackenzie writes:
> I want to see all recent commits together, each one annotated with
> which branch it's on.  That's surely not too much to ask for.  I want
> annotation, not filtering.

Try

  git log --source emacs-24 master

-David

Re: Obscure error/warning/information message from git pull

[David Caldwell]

[-- Attachment #1: Type: text/plain, Size: 859 bytes --]

On 11/14/14 3:02 PM, Alan Mackenzie wrote:
> I want to see all recent commits together, each one annotated with
> which branch it's on.  That's surely not too much to ask for.  I want
> annotation, not filtering.

Git really doesn't have that exact feature (as far as I know). You can
get something similar with "git log --all --graph --decorate=full" which
will show you the graph so you can see which commits end up on what
branches. I find the graph format is better seen with "--oneline", but
it works with more verbose log formats (including -p).

Again, it might be worth you time trying to get tig[1] or gitk to work
on your system—they both have nice visualizations of the repo dag.

-David

[1] http://jonas.nitro.dk/tig/
A screenshot comparing the graphs of tig and gitk:
http://jonas.nitro.dk/tig/screenshots/rev-graph.png



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4219 bytes --]

Re: Obscure error/warning/information message from git pull

[Michael Welsh Duggan]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Sergey Organov <sorganov@gmail.com>
>> Date: Fri, 14 Nov 2014 23:57:56 +0300
>> 
>> >     git log -n5 emacs24 master --
>> >
>> > and this works, but it doesn't say which commit is in which branch.
>> > YUCK.
>> 
>> Because in GIT commits are not on a branch. All commits are arranged into
>> DAG, and branch is just a pointer into the DAG. Any given commit is
>> either reachable from given branch or not. It's that simple.
>
> You just re-defined "on a branch", that's all.  A commit that's
> reachable from a branch is on that branch.  It's that simple.

Right.  Asked another way, is there a way to do a git log where each
entry has the information from "git branch --contains <this>" for each
commit in the log?

-- 
Michael Welsh Duggan
(md5i@md5i.com)

Re: Obscure error/warning/information message from git pull

[Tassilo Horn]

Alan Mackenzie <acm@muc.de> writes:

>> > This doesn't work very well.  It prints out the information for the first
>> > commit that is displayed, but no more.  This feels like a git bug.
>
>> No, this is the correct behaviour.
>
> So, not very useful, then.  Also not what the FM says:
>
>     "Print out the ref names of any commits that are shown."
>
> .  Not one commit, but any (i.e. all) commits.  Of course, that's all
> dependent on knowing what "ref name" means.  I suppose you're going to
> tell me next that only the first commit actually has a "ref name"
> (whatever that is).  But if you do, it would be really nice if you
> could explain what is meant by "ref name", or even point me at a non
> content-free definition.  :-)

I'd say a ref name is a name for a commit which has some special
meaning.  Then you can use the ref name instead of the SHA1 to operate
on it.

For example, HEAD is the ref name for the most recent commit in the
current branch, and a branch is actually only a ref name for some
commit.  HEAD is called a symbolic ref because its value is a ref name
again.  That's what I get in the emacs-24 branch:

  % cat .git/HEAD .git/refs/heads/emacs-24 
  ref: refs/heads/emacs-24
  4cd0f2dc6f868bc76c2326db1a16b3bb21f78024

And any tag is a ref name, too.  When you do "git log --decorate" in the
emacs-24 branch, you'll see more decorated commits, e.g.,:

commit 83bad90efe943e7c88431b7a71bc1d5cf1304c92 (tag: emacs-24.4)
Author: Glenn Morris <rgm@gnu.org>
Date:   Mon Oct 20 20:21:15 2014 +0100

    Add 24.4 release ChangeLog entries

commit 9b4fdfd9b67aa9e370cd20e0188f08678daa665c (tag: emacs-24.4-rc1)
Author: Glenn Morris <rgm@gnu.org>
Date:   Fri Oct 17 09:08:40 2014 -0700

    Regenerate ldefs-boot

That's explained well in the git book at

  http://git-scm.com/book/en/v2/Git-Internals-Git-References

HTH,
Tassilo

Re: Obscure error/warning/information message from git pull

[David Kastrup]

Michael Welsh Duggan <mwd@md5i.com> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Sergey Organov <sorganov@gmail.com>
>>> Date: Fri, 14 Nov 2014 23:57:56 +0300
>>> 
>>> >     git log -n5 emacs24 master --
>>> >
>>> > and this works, but it doesn't say which commit is in which branch.
>>> > YUCK.
>>> 
>>> Because in GIT commits are not on a branch. All commits are arranged into
>>> DAG, and branch is just a pointer into the DAG. Any given commit is
>>> either reachable from given branch or not. It's that simple.
>>
>> You just re-defined "on a branch", that's all.  A commit that's
>> reachable from a branch is on that branch.  It's that simple.
>
> Right.  Asked another way, is there a way to do a git log where each
> entry has the information from "git branch --contains <this>" for each
> commit in the log?

--source, but that does not list _all_ ways to reach a commit but just
the one with which the current log command reached it.

-- 
David Kastrup

Re: Obscure error/warning/information message from git pull

[David Kastrup]

Alan Mackenzie <acm@muc.de> writes:

> That's very impressive, but not what I want.  I want to see all recent
> commits together, each one annotated with which branch it's on.  That's
> surely not too much to ask for.  I want annotation, not filtering.

Are you intentionally trying to sound like a petulent child?

At any rate, _as_ _I_ _already_ _wrote_:

git log --all --source

or git log --all --graph --decorate (I prefer not to have the branch
head information repeated all over).

-- 
David Kastrup

Re: Obscure error/warning/information message from git pull

[Eli Zaretskii]

> From: David Engster <david@engster.org>
> Date: Sat, 15 Nov 2014 00:17:49 +0100
> Cc: Sergey Organov <sorganov@gmail.com>, emacs-devel@gnu.org
> 
> Alan Mackenzie writes:
> > I want to see all recent commits together, each one annotated with
> > which branch it's on.  That's surely not too much to ask for.  I want
> > annotation, not filtering.
> 
> Try
> 
>   git log --source emacs-24 master

This spews an error message when invoked in the master branch.  Why?
Does it need the repository to track both branches or something?

What exactly is the semantics of this command when given branch names?
(The man page doesn't say, AFAICS.)

Re: Obscure error/warning/information message from git pull

[David Engster]

Eli Zaretskii writes:
>> From: David Engster <david@engster.org>
>> Date: Sat, 15 Nov 2014 00:17:49 +0100
>> Cc: Sergey Organov <sorganov@gmail.com>, emacs-devel@gnu.org
>
>> 
>> Alan Mackenzie writes:
>> > I want to see all recent commits together, each one annotated with
>> > which branch it's on.  That's surely not too much to ask for.  I want
>> > annotation, not filtering.
>> 
>> Try
>> 
>>   git log --source emacs-24 master
>
> This spews an error message when invoked in the master branch.  Why?
> Does it need the repository to track both branches or something?

Yes, this was for Alan's case, who has a local tracking branch for
emacs-24. If you don't track it locally, use the remote branch name,
which is 'origin/emacs-24'.

> What exactly is the semantics of this command when given branch names?
> (The man page doesn't say, AFAICS.)

It says

  The command takes options applicable to the git rev-list command to
  control what is shown and how [...].

So 'git help rev-list' will give you details on how this works.

-David

Re: Obscure error/warning/information message from git pull

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Sat, 15 Nov 2014 08:40:42 +0100
> 
> git log --all --source

This has the disadvantage of showing the branches in the obscure
refs/foo/bar/branch format.  Its advantage (AFAIK) is that it will
also show commits on remote branches that are not (yet) tracked by the
repo (please correct me if I'm wrong).

Re: Obscure error/warning/information message from git pull

[Eli Zaretskii]

> From: David Engster <deng@randomsample.de>
> Cc: acm@muc.de,  sorganov@gmail.com,  emacs-devel@gnu.org
> Date: Sat, 15 Nov 2014 09:18:36 +0100
> 
> >>   git log --source emacs-24 master
> >
> > This spews an error message when invoked in the master branch.  Why?
> > Does it need the repository to track both branches or something?
> 
> Yes, this was for Alan's case, who has a local tracking branch for
> emacs-24. If you don't track it locally, use the remote branch name,
> which is 'origin/emacs-24'.

OK, thanks.

> > What exactly is the semantics of this command when given branch names?
> > (The man page doesn't say, AFAICS.)
> 
> It says
> 
>   The command takes options applicable to the git rev-list command to
>   control what is shown and how [...].
> 
> So 'git help rev-list' will give you details on how this works.

A.k.a. "the man page doesn't say", because what the rev-list man page
says cannot be related back to the 'log' man page reference.  But
don't let me start with the quality of the Git documentation.

Re: Obscure error/warning/information message from git pull

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Date: Sat, 15 Nov 2014 08:40:42 +0100
>> 
>> git log --all --source
>
> This has the disadvantage of showing the branches in the obscure
> refs/foo/bar/branch format.  Its advantage (AFAIK) is that it will
> also show commits on remote branches that are not (yet) tracked by the
> repo (please correct me if I'm wrong).

git cannot magically show anything that isn't in the repo.  You are
probably thinking of git showing remote-tracking branches (those are
always destructively updated from the remote reference when fetching) as
well as local branches (which may or may not have a remote upstream).

-- 
David Kastrup

Re: Obscure error/warning/information message from git pull

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Sat, 15 Nov 2014 10:12:37 +0100
> 
> >> git log --all --source
> >
> > This has the disadvantage of showing the branches in the obscure
> > refs/foo/bar/branch format.  Its advantage (AFAIK) is that it will
> > also show commits on remote branches that are not (yet) tracked by the
> > repo (please correct me if I'm wrong).
> 
> git cannot magically show anything that isn't in the repo.

It is unclear to me, at my current level of knowledge, what exactly
"is in the repo".  I didn't see that explained in detail anywhere.

For example, "git clone" is advertised as "clone a repository", but
that evidently only "fully" clones the master branch; other branches
won't even be updated by the following "git pull"s unless you say
"git checkout BRANCH" once (or give some other command that has the
same effect).  Then what exactly is brought downstream by 'clone', and
why is it called "repository" rather than "branch"?

Furthermore, even if you have other branches tracked, "git pull"
evidently won't update them as it does with the current branch, since
switching to another branch after a pull will cheerfully tell you that
you are behind the branch tip and need another "git pull" to fix
that.  Then what exactly does "branch tracking" mean, by default?

These and other similar complexities stand in the way of my
understanding of what exactly do I have in my clone of the repository,
and what I don't have.  It is all the more perplexing, since (AFAIU)
the repo met-data is (or includes) the history DAG, where (AFAIK)
branches are all interwoven in a single graph.  So how come a 'pull'
doesn't update the whole DAG, and if it does, why do I need to do
something in addition to have all my branches updated?

> You are probably thinking of git showing remote-tracking branches
> (those are always destructively updated from the remote reference
> when fetching) as well as local branches (which may or may not have
> a remote upstream).

I was talking about local branches that track remote ones.  (And
"remote-tracking", btw, is a term that should have not been there,
because it unnecessarily muddies the water.  I suggest to refrain from
using it.)

Re: Obscure error/warning/information message from git pull

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Cc: emacs-devel@gnu.org
>> Date: Sat, 15 Nov 2014 10:12:37 +0100
>> 
>> >> git log --all --source
>> >
>> > This has the disadvantage of showing the branches in the obscure
>> > refs/foo/bar/branch format.  Its advantage (AFAIK) is that it will
>> > also show commits on remote branches that are not (yet) tracked by the
>> > repo (please correct me if I'm wrong).
>> 
>> git cannot magically show anything that isn't in the repo.
>
> It is unclear to me, at my current level of knowledge, what exactly
> "is in the repo".

All the references you fetched/cloned and everything they point to.

> I didn't see that explained in detail anywhere.
>
> For example, "git clone" is advertised as "clone a repository", but
> that evidently only "fully" clones the master branch; other branches
> won't even be updated by the following "git pull"s unless you say
> "git checkout BRANCH" once (or give some other command that has the
> same effect).  Then what exactly is brought downstream by 'clone', and
> why is it called "repository" rather than "branch"?

The manual is clear about that.

       Clones a repository into a newly created directory, creates
       remote-tracking branches for each branch in the cloned repository
       (visible using git branch -r), and creates and checks out an initial
       branch that is forked from the cloned repository\u2019s currently active
       branch.

       After the clone, a plain git fetch without arguments will update all
       the remote-tracking branches, and a git pull without arguments will in
       addition merge the remote master branch into the current master branch,
       if any (this is untrue when "--single-branch" is given; see below).

       This default configuration is achieved by creating references to the
       remote branch heads under refs/remotes/origin and by initializing
       remote.origin.url and remote.origin.fetch configuration variables.

git-clone does not create more _local_ branches than the one it creates
and checks out from the currently active branch of the remote
repository.

> Furthermore, even if you have other branches tracked, "git pull"
> evidently won't update them as it does with the current branch, since
> switching to another branch after a pull will cheerfully tell you that
> you are behind the branch tip and need another "git pull" to fix that.
> Then what exactly does "branch tracking" mean, by default?

It means that Git tracks the remote branches: it knows what's there and
can show you even when offline (of course, it shows the state since the
last fetch).  Updating a _local_ branch requires merging the state of
the local branch with the state of the remote-tracking branch.  Git only
performs merges in a checked out working directory (if you want to pick
nits: merges are performed in the index, but the index is kept
reasonably close to a working directory and/or a particular checkout).
So fetching will not update any local branch but only the
remote-tracking branches.  Fetching never merges: if the history of a
remote-tracking branch has diverged from that of the remote repository,
the old information will just get thrown away and replaced from the
up-to-date version in the remote repository.

Git does not throw away information from a _local_ branch without
explicit instructions and/or warning, however.

git-pull merges (or rebases) _one_ local branch.  The one that is
checked out.  But it updates all remote-tracking branches.

> These and other similar complexities stand in the way of my
> understanding of what exactly do I have in my clone of the repository,
> and what I don't have.

git branch -a should tell you.

> It is all the more perplexing, since (AFAIU) the repo met-data is (or
> includes) the history DAG, where (AFAIK) branches are all interwoven
> in a single graph.  So how come a 'pull' doesn't update the whole DAG,
> and if it does, why do I need to do something in addition to have all
> my branches updated?

A pull updates those parts of the DAG that can be reached from the
references you have in your "fetch" specification.

>> You are probably thinking of git showing remote-tracking branches
>> (those are always destructively updated from the remote reference
>> when fetching) as well as local branches (which may or may not have a
>> remote upstream).
>
> I was talking about local branches that track remote ones.

I'd call that "that have a remote upstream".  Because technically those
local branches track the remote-tracking branch.

> (And "remote-tracking", btw, is a term that should have not been
> there, because it unnecessarily muddies the water.  I suggest to
> refrain from using it.)

Then you need to devise alternative terminology and submit it to the Git
documentation.  You have my blessings for that since that bit of
terminology is really fundamentally messed up.  I tend to use "tracking"
_only_ in the context of remote-tracking, and otherwise refer to
"upstream branch".  But indeed, if you take a look at the option naming
and description of "git-branch", you get

       -t, --track
           When creating a new branch, set up branch.<name>.remote and
           branch.<name>.merge configuration entries to mark the start-point
           branch as "upstream" from the new branch. This configuration will
           tell git to show the relationship between the two branches in git
           status and git branch -v. Furthermore, it directs git pull without
           arguments to pull from the upstream when the new branch is checked
           out.

           This behavior is the default when the start point is a
           remote-tracking branch. Set the branch.autosetupmerge configuration
           variable to false if you want git checkout and git branch to always
           behave as if --no-track were given. Set it to always if you want
           this behavior when the start-point is either a local or
           remote-tracking branch.

       --no-track
           Do not set up "upstream" configuration, even if the
           branch.autosetupmerge configuration variable is true.

       --set-upstream
           If specified branch does not exist yet or if --force has been
           given, acts exactly like --track. Otherwise sets up configuration
           like --track would when creating the branch, except that where
           branch points to is not changed.

       -u <upstream>, --set-upstream-to=<upstream>
           Set up <branchname>'s tracking information so <upstream> is
           considered <branchname>'s upstream branch. If no <branchname> is
           specified, then it defaults to the current branch.

       --unset-upstream
           Remove the upstream information for <branchname>. If no branch is
           specified it defaults to the current branch.

which means that "remote-tracking" and "tracking a remote branch" are
actually describing different things.  Good luck figuring that out if
you are new to Git.  Maybe a global replace of "remote-tracking" with
"remote mirroring" and subsequent proofreading to check that one did not
have too many false positives or negatives would sort out the bulk of
this particular mess.

It's been pretty much around from the early beginnings so it's likely a
blind spot for people accustomed to Git.

But if you want the terminology to change, you cannot change it just for
Emacs developers.  You need to do it upstream.

-- 
David Kastrup

Re: Obscure error/warning/information message from git pull

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Sat, 15 Nov 2014 11:28:11 +0100
> 
> >> git cannot magically show anything that isn't in the repo.
> >
> > It is unclear to me, at my current level of knowledge, what exactly
> > "is in the repo".
> 
> All the references you fetched/cloned and everything they point to.

Thanks, but that explains nothing.

> > For example, "git clone" is advertised as "clone a repository", but
> > that evidently only "fully" clones the master branch; other branches
> > won't even be updated by the following "git pull"s unless you say
> > "git checkout BRANCH" once (or give some other command that has the
> > same effect).  Then what exactly is brought downstream by 'clone', and
> > why is it called "repository" rather than "branch"?
> 
> The manual is clear about that.

"Clear", right.

>        Clones a repository into a newly created directory, creates
>        remote-tracking branches for each branch in the cloned repository
>        (visible using git branch -r), and creates and checks out an initial
>        branch that is forked from the cloned repository\u2019s currently active
>        branch.
> 
>        After the clone, a plain git fetch without arguments will update all
>        the remote-tracking branches, and a git pull without arguments will in
>        addition merge the remote master branch into the current master branch,
>        if any (this is untrue when "--single-branch" is given; see below).
> 
>        This default configuration is achieved by creating references to the
>        remote branch heads under refs/remotes/origin and by initializing
>        remote.origin.url and remote.origin.fetch configuration variables.

Sorry, but that's a bunch of gobbledygook.  What does "create
remote-tracking branches" mean, and how is it different from "creates
the initial branch"?  What does "update" in "update the
remote-tracking branches" means, and how is it different from what is
described after that for the master branch?  Sorry, but this old
curmudgeon cannot grok that; I'd very much prefer your own words.

> > Furthermore, even if you have other branches tracked, "git pull"
> > evidently won't update them as it does with the current branch, since
> > switching to another branch after a pull will cheerfully tell you that
> > you are behind the branch tip and need another "git pull" to fix that.
> > Then what exactly does "branch tracking" mean, by default?
> 
> It means that Git tracks the remote branches: it knows what's there and
> can show you even when offline (of course, it shows the state since the
> last fetch).

Does that include updating their parts of the DAG?  Below you seem to
say it doesn't; but in that case, how would Git "know what's there"
and show that to me while offline?

> git-pull merges (or rebases) _one_ local branch.  The one that is
> checked out.  But it updates all remote-tracking branches.

"Updates" how?  Does it update their part of the DAG?  Does it do
something else?

> > These and other similar complexities stand in the way of my
> > understanding of what exactly do I have in my clone of the repository,
> > and what I don't have.
> 
> git branch -a should tell you.

It shows the list of the branches, where I know how to discern a
branch I call "tracking", i.e. the one for which I did a checkout at
some point, and those for which I didn't.  What else should it tell
me?

> > It is all the more perplexing, since (AFAIU) the repo met-data is (or
> > includes) the history DAG, where (AFAIK) branches are all interwoven
> > in a single graph.  So how come a 'pull' doesn't update the whole DAG,
> > and if it does, why do I need to do something in addition to have all
> > my branches updated?
> 
> A pull updates those parts of the DAG that can be reached from the
> references you have in your "fetch" specification.

What is my "fetch specification", and how did I specify that?

Thanks for taking time to explain this.

Re: Obscure error/warning/information message from git pull

[Alan Mackenzie]

Hello, David.

On Sat, Nov 15, 2014 at 11:28:11AM +0100, David Kastrup wrote:
> Eli Zaretskii <eliz@gnu.org> writes:

> >> From: David Kastrup <dak@gnu.org>
> >> Cc: emacs-devel@gnu.org
> >> Date: Sat, 15 Nov 2014 10:12:37 +0100

> >> >> git log --all --source

> >> > This has the disadvantage of showing the branches in the obscure
> >> > refs/foo/bar/branch format.  Its advantage (AFAIK) is that it will
> >> > also show commits on remote branches that are not (yet) tracked by the
> >> > repo (please correct me if I'm wrong).

> >> git cannot magically show anything that isn't in the repo.

> > It is unclear to me, at my current level of knowledge, what exactly
> > "is in the repo".

> All the references you fetched/cloned and everything they point to.

> > I didn't see that explained in detail anywhere.

> > For example, "git clone" is advertised as "clone a repository", but
> > that evidently only "fully" clones the master branch; other branches
> > won't even be updated by the following "git pull"s unless you say
> > "git checkout BRANCH" once (or give some other command that has the
> > same effect).  Then what exactly is brought downstream by 'clone', and
> > why is it called "repository" rather than "branch"?

> The manual is clear about that.

I second Eli's comment on this.

>        Clones a repository into a newly created directory, creates
>        remote-tracking branches for each branch in the cloned repository
>        (visible using git branch -r), and creates and checks out an initial
                                        ^^^
>        branch that is forked from the cloned repository\u2019s currently active
>        branch.

So "git clone" is defined in terms of "clone".  Looks like a recursive
"definition" to me - part of what "git clone" does is to "clone[s] a
repository".  There then follows an incoherent list of the form "does A,
then does B, then does C, ...".

What is missing is a definition of "clone".  It would appear to mean
"make a partial copy of".  This is in contrast to the word's uses in all
other contexts where it means "duplicate".

Please correct me if I'm mistaken here, but I think my "git clone"ing of
the repository at savannah only partially copied that repository, thus I
have an incomplete copy of it.

So git's concept of "distributed vcs" is that the repository is
collectively stored across many computers, as contrasted with bzr's and
hg's model where the complete repository is stored on each participating
computer.

>        After the clone, a plain git fetch without arguments will update all
>        the remote-tracking branches, and a git pull without arguments will in
>        addition merge the remote master branch into the current master branch,
>        if any (this is untrue when "--single-branch" is given; see below).

>        This default configuration is achieved by creating references to the
>        remote branch heads under refs/remotes/origin and by initializing
>        remote.origin.url and remote.origin.fetch configuration variables.

> git-clone does not create more _local_ branches than the one it creates
> and checks out from the currently active branch of the remote
> repository.

And a subsequent git checkout will require access, possibly net access,
to the repository from which the current one was copied, yes?

[ .... ]

> -- 
> David Kastrup

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Obscure error/warning/information message from git pull

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Cc: emacs-devel@gnu.org
>> Date: Sat, 15 Nov 2014 11:28:11 +0100
>> 
>> >> git cannot magically show anything that isn't in the repo.
>> >
>> > It is unclear to me, at my current level of knowledge, what exactly
>> > "is in the repo".
>> 
>> All the references you fetched/cloned and everything they point to.
>
> Thanks, but that explains nothing.

Unless you take very special pains (like using a "shallow" repository),
Git makes sure that it can follow _any_ SHA1/object/reference as far as
it wants: it knows the tree for any commit known to it, it knows the
parent commits to any commits known to it, it knows the blobs for any
file in any tree known to it.

When you do "git fetch", it updates the heads of its remote-mirroring
branches to point to the new SHA1 hash code.  Afterwards it makes sure
that it, again, knows everything about any reachable object from this
new state (the actual references are updated once this everything-can-be
reached state has actually been accomplished: if you bomb out with
SIGINT before, you'll get dangling objects, having some SHA1 and
substance behind it, but nothing pointing to them.  They will either
disappear with some future git-gc, or get a reference on some future
fetch and then stay around: there are no linkages other than the SHA1
for anything).

So "git fetch" updates references and then completes the repository by
fetching all objects that are referenced but not present.

>> > For example, "git clone" is advertised as "clone a repository", but
>> > that evidently only "fully" clones the master branch; other branches
>> > won't even be updated by the following "git pull"s unless you say
>> > "git checkout BRANCH" once (or give some other command that has the
>> > same effect).  Then what exactly is brought downstream by 'clone', and
>> > why is it called "repository" rather than "branch"?
>> 
>> The manual is clear about that.
>
> "Clear", right.
>
>>        Clones a repository into a newly created directory, creates
>>        remote-tracking branches for each branch in the cloned repository
>>        (visible using git branch -r), and creates and checks out an initial
>>        branch that is forked from the cloned repository\u2019s currently active
>>        branch.
>> 
>>        After the clone, a plain git fetch without arguments will update all
>>        the remote-tracking branches, and a git pull without arguments will in
>>        addition merge the remote master branch into the current master branch,
>>        if any (this is untrue when "--single-branch" is given; see below).
>> 
>>        This default configuration is achieved by creating references to the
>>        remote branch heads under refs/remotes/origin and by initializing
>>        remote.origin.url and remote.origin.fetch configuration variables.
>
> Sorry, but that's a bunch of gobbledygook.  What does "create
> remote-tracking branches" mean,

Fetching the references to their heads.

> and how is it different from "creates the initial branch"?

The initial branch is a local branch that is not a remote-tracking
branch but rather tracks the corresponding remote branch (remember that
"remote-tracking" is a magical phrase meaning "mirroring a remote
branch" rather than "tracking a remote branch" for some unfathomable
reason).

> What does "update" in "update the remote-tracking branches" means,

Making the references point to the same objects that the remote
repository has and making sure that the referenced objects (and
everything referenced by them) are fetched into your repository as well.

> and how is it different from what is described after that for the
> master branch?

_Your_ master branch is a local branch.  It cannot be fetched from the
remote site.  But the _remote_ master branch is fetched into its
remote-tracking branch in your repository, and then your local master
branch is merged with the remote-tracking branch of the corresponding
remote master branch.

>> > Furthermore, even if you have other branches tracked, "git pull"
>> > evidently won't update them as it does with the current branch, since
>> > switching to another branch after a pull will cheerfully tell you that
>> > you are behind the branch tip and need another "git pull" to fix that.
>> > Then what exactly does "branch tracking" mean, by default?
>> 
>> It means that Git tracks the remote branches: it knows what's there and
>> can show you even when offline (of course, it shows the state since the
>> last fetch).
>
> Does that include updating their parts of the DAG?

Yes.

> Below you seem to say it doesn't;

Then appearances would seem to deceive.

>> git-pull merges (or rebases) _one_ local branch.  The one that is
>> checked out.  But it updates all remote-tracking branches.
>
> "Updates" how?  Does it update their part of the DAG?

Yes.

>> > These and other similar complexities stand in the way of my
>> > understanding of what exactly do I have in my clone of the repository,
>> > and what I don't have.
>> 
>> git branch -a should tell you.
>
> It shows the list of the branches, where I know how to discern a
> branch I call "tracking", i.e. the one for which I did a checkout at
> some point, and those for which I didn't.  What else should it tell
> me?

That tells you the branches that are available for
viewing/merging/operating in your repository even when you are offline.
git branch -a -v
tells some more details.

>> > It is all the more perplexing, since (AFAIU) the repo met-data is (or
>> > includes) the history DAG, where (AFAIK) branches are all interwoven
>> > in a single graph.  So how come a 'pull' doesn't update the whole DAG,
>> > and if it does, why do I need to do something in addition to have all
>> > my branches updated?
>> 
>> A pull updates those parts of the DAG that can be reached from the
>> references you have in your "fetch" specification.
>
> What is my "fetch specification", and how did I specify that?

Take a look in your .git/config file.  You'll find a section
[remote "origin"] containing, among other things, a fetch specification.

For a typical repository containing all branches (whether that is the
case depends on the fetch specification), the complete DAG is
available.  git pull updates _all_ fetched remote-tracking branches.
But it only merges the currently checked-out _local_ branch with the
remote-tracking branch for the corresponding remote branch.

Strictly speaking, the local branch is tracking the remote-tracking
branch, and the remote-tracking branch is not actually "tracking" the
remote in the sense that "tracking" is used for local branches, but
mirroring it.

As I said: "remote-tracking" is a magical buzzword to be replaced by
"remote-mirroring" or whatever.  "tracking" in the "proper" sense is a
connection to a branch that is happening in your local repository,
either tracking another local branch, or tracking a remote-tracking
branch.

As I said: replace the exact letter-combination "remote-tracking" with
"remote-mirroring" everywhere, and you have one less muddled piece of
terminology to worry about.

I think that particular bit may well be about the most enfuriatingly
confuddled bit of terminology in general Git operations.

-- 
David Kastrup

Re: Obscure error/warning/information message from git pull

[David Kastrup]

Alan Mackenzie <acm@muc.de> writes:

> So "git clone" is defined in terms of "clone".  Looks like a recursive
> "definition" to me - part of what "git clone" does is to "clone[s] a
> repository".  There then follows an incoherent list of the form "does
> A, then does B, then does C, ...".
>
> What is missing is a definition of "clone".  It would appear to mean
> "make a partial copy of".

No.  Your copy is a complete copy of everything you ask for.  If you
don't clone a particular branch, for example, by using a single-branch
clone, that branch will not magically be in your repository.

> Please correct me if I'm mistaken here, but I think my "git clone"ing
> of the repository at savannah only partially copied that repository,
> thus I have an incomplete copy of it.

It depends on what you cloned.  It will clone exactly what you asked it
to clone.  If you chose not to clone some branches, they will not be in
your repository.

> So git's concept of "distributed vcs" is that the repository is
> collectively stored across many computers, as contrasted with bzr's
> and hg's model where the complete repository is stored on each
> participating computer.

Nonsense.  _Everything_ you asked for is stored on your computer.  Git
does not maintain any data off-computer.

> And a subsequent git checkout will require access, possibly net
> access, to the repository from which the current one was copied, yes?

No.  checkouts are a strictly local operation.

-- 
David Kastrup

Re: Obscure error/warning/information message from git pull

[Michael Welsh Duggan]

David Kastrup <dak@gnu.org> writes:

> Alan Mackenzie <acm@muc.de> writes:
>
>> So "git clone" is defined in terms of "clone".  Looks like a recursive
>> "definition" to me - part of what "git clone" does is to "clone[s] a
>> repository".  There then follows an incoherent list of the form "does
>> A, then does B, then does C, ...".
>>
>> What is missing is a definition of "clone".  It would appear to mean
>> "make a partial copy of".
>
> No.  Your copy is a complete copy of everything you ask for.  If you
> don't clone a particular branch, for example, by using a single-branch
> clone, that branch will not magically be in your repository.

I think I may understand the disconnect here, but I am a git novice, so
Dave, please jump in and correct any inaccuracies.  I honestly think the
term that is causing the most difficulty right now is the word "local."
Read on.

>> Please correct me if I'm mistaken here, but I think my "git clone"ing
>> of the repository at savannah only partially copied that repository,
>> thus I have an incomplete copy of it.
>
> It depends on what you cloned.  It will clone exactly what you asked it
> to clone.  If you chose not to clone some branches, they will not be in
> your repository.

When you clone a repo without giving it any special arguments (i.e.,
just the location of the remote repository and possible the name of the
directory you wish to clone into) you get a copy of the whole remote
repository; all branches, the whole DAG, and all blobs referenced by the
DAG.  Each branch in your on-disk copy of the clone is called a "remote
branch", since it is a branch from a remote source.  (That last sentence
is shaky, and perhaps incorrect, but bear with me.)

Now, you do not normally check-out these "remote branches", and by
check-out I mean specifically generate a working directory from them.
Rather you work with a "local branch" which is usually "linked" to the
"remote branch".  (The "link" is what the --track option to the branch
command handles, I believe.)  When you initially clone a repo, you (by
default) get a "local branch" named "master" which is linked to (tracks)
the remote master branch.

One of the fundamental confusing bits is that the word "local" in local
branch does not mean "on local disk".  It is on local disk.  But so are
the repositories copies of the "remote branches".  When you do a "git
fetch --all", it will sync up the on-disk representation of the "remote
branches" with an actual remote repository.  When you do a "git merge"
from a working directory (local branch), you merge the differences from
the linked (tracked) "remote branch" (on your local disk!) into your
local branch.  "git pull" does both the fetch, updating your on-disk
representation of the "remote branch", and the merge (updating your
"local branch").

I apologize if any of this is incorrect, but I agree with Alan and Eli
that much of this is confusing.  I'm not entirely certain I have a
correct understanding of this myself.

-- 
Michael Welsh Duggan
(md5i@md5i.com)

Re: Obscure error/warning/information message from git pull

[David Kastrup]

Michael Welsh Duggan <mwd@md5i.com> writes:

> When you clone a repo without giving it any special arguments (i.e.,
> just the location of the remote repository and possible the name of
> the directory you wish to clone into) you get a copy of the whole
> remote repository; all branches, the whole DAG, and all blobs
> referenced by the DAG.

Looks like it.  At some previous time, the default was to only clone the
default branch I think.  More often than not, that was a total nuisance.
At any rate, the behavior can be changed by editing .git/config, in
particular the [remote "origin"] section.

> Each branch in your on-disk copy of the clone is called a "remote
> branch", since it is a branch from a remote source.  (That last
> sentence is shaky, and perhaps incorrect, but bear with me.)

Not more shaky and perhaps incorrect than the normal Git documentation.
It's your local notion of the remote branches, also called
"remote-tracking branches".

> Now, you do not normally check-out these "remote branches", and by
> check-out I mean specifically generate a working directory from them.

Yes and no.  Remote-tracking branches are _not_ actually branches one
can check out.  If you check out such a "branch", you actually just
check out its current state as a "detached HEAD".  Whatever you commit
to such a detached HEAD will get _lost_ if you change branches without
creating a local branch or a tag for those commits.  The remote-tracking
branch cannot be associated with your new commits (unless you _push_
them) since it keeps mirroring the remote (in the last known form).

> Rather you work with a "local branch" which is usually "linked" to the
> "remote branch".  (The "link" is what the --track option to the branch
> command handles, I believe.)  When you initially clone a repo, you (by
> default) get a "local branch" named "master" which is linked to
> (tracks) the remote master branch.

According to your terminology.  I think it diverges more than necessary
for the purpose of arriving at something sane and consistent from the
Git terminology.

> One of the fundamental confusing bits is that the word "local" in
> local branch does not mean "on local disk".  It is on local disk.  But
> so are the repositories copies of the "remote branches".  When you do
> a "git fetch --all", it will sync up the on-disk representation of the
> "remote branches" with an actual remote repository.  When you do a
> "git merge" from a working directory (local branch), you merge the
> differences from the linked (tracked) "remote branch" (on your local
> disk!) into your local branch.  "git pull" does both the fetch,
> updating your on-disk representation of the "remote branch",

Of _all_ remote branches.

> and the merge (updating your "local branch").

> I apologize if any of this is incorrect, but I agree with Alan and Eli
> that much of this is confusing.  I'm not entirely certain I have a
> correct understanding of this myself.

As I stated already: in Git's documentation "remote-tracking" is not
treated sanely, at least as far as I remember it.  I haven't checked
recently.

-- 
David Kastrup

Re: Obscure error/warning/information message from git pull

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Sat, 15 Nov 2014 15:30:31 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: David Kastrup <dak@gnu.org>
> >> Cc: emacs-devel@gnu.org
> >> Date: Sat, 15 Nov 2014 11:28:11 +0100
> >> 
> >> >> git cannot magically show anything that isn't in the repo.
> >> >
> >> > It is unclear to me, at my current level of knowledge, what exactly
> >> > "is in the repo".
> >> 
> >> All the references you fetched/cloned and everything they point to.
> >
> > Thanks, but that explains nothing.
> [...]

Thanks, that's a lot to digest.  A couple of questions:

> >> > Furthermore, even if you have other branches tracked, "git pull"
> >> > evidently won't update them as it does with the current branch, since
> >> > switching to another branch after a pull will cheerfully tell you that
> >> > you are behind the branch tip and need another "git pull" to fix that.
> >> > Then what exactly does "branch tracking" mean, by default?
> >> 
> >> It means that Git tracks the remote branches: it knows what's there and
> >> can show you even when offline (of course, it shows the state since the
> >> last fetch).
> >
> > Does that include updating their parts of the DAG?
> 
> Yes.
> [...]
> >> > It is all the more perplexing, since (AFAIU) the repo met-data is (or
> >> > includes) the history DAG, where (AFAIK) branches are all interwoven
> >> > in a single graph.  So how come a 'pull' doesn't update the whole DAG,
> >> > and if it does, why do I need to do something in addition to have all
> >> > my branches updated?
> >> 
> >> A pull updates those parts of the DAG that can be reached from the
> >> references you have in your "fetch" specification.
> >
> > What is my "fetch specification", and how did I specify that?
> 
> Take a look in your .git/config file.  You'll find a section
> [remote "origin"] containing, among other things, a fetch specification.

That says "fetch = +refs/heads/*:refs/remotes/origin/*", which I guess
means everything, and is probably the default (since I never said
anything about that).  So I guess I can now forget everything about
partial DAG being fetched, because in my case, as in every default
case, the entire DAG will be updated by "git pull".  Is that correct?

> For a typical repository containing all branches (whether that is the
> case depends on the fetch specification), the complete DAG is
> available.  git pull updates _all_ fetched remote-tracking branches.
> But it only merges the currently checked-out _local_ branch with the
> remote-tracking branch for the corresponding remote branch.

So the suggestion to pull, displayed by Git when I checkout another
branch immediately after a pull, actually boils down to do the merge
for that other branch?  If so, why does it suggest a pull?

Thanks.

Re: Obscure error/warning/information message from git pull

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> Take a look in your .git/config file.  You'll find a section
>> [remote "origin"] containing, among other things, a fetch specification.
>
> That says "fetch = +refs/heads/*:refs/remotes/origin/*", which I guess
> means everything, and is probably the default (since I never said
> anything about that).

Apparently.  Good thing they got rid of the old default.  It was a
nuisance.

> So I guess I can now forget everything about partial DAG being
> fetched, because in my case, as in every default case, the entire DAG
> will be updated by "git pull".  Is that correct?

Yes.  I actually don't ever use "git pull" myself as I don't like the
automatic merging action: if I want a merge, I do it myself.  "git
fetch" is sufficient for the update and does not involve the current
branch or checkout or work directory at all, and git pull does it as its
first step anyway.  I often want to see what happened upstream _without_
having it automatically integrated into what I am currently working on.

>> For a typical repository containing all branches (whether that is the
>> case depends on the fetch specification), the complete DAG is
>> available.  git pull updates _all_ fetched remote-tracking branches.
>> But it only merges the currently checked-out _local_ branch with the
>> remote-tracking branch for the corresponding remote branch.
>
> So the suggestion to pull, displayed by Git when I checkout another
> branch immediately after a pull, actually boils down to do the merge
> for that other branch?  If so, why does it suggest a pull?

Because it has no notion of "immediately after a pull" would be one
reason.  Another reason might be that the branch might be set to rebase
on pull rather than merge, and the default suggestion does not want to
differentiate the two cases.

Also it might be that when you specify arguments, indeed only _some_
references are fetched rather than all.  The man page says:

SYNOPSIS
       git pull [options] [<repository> [<refspec>...]]

DESCRIPTION
       Incorporates changes from a remote repository into the current branch.
       In its default mode, git pull is shorthand for git fetch followed by
       git merge FETCH_HEAD.

       More precisely, git pull runs git fetch with the given parameters and
       calls git merge to merge the retrieved branch heads into the current
       branch. With --rebase, it runs git rebase instead of git merge.


So you can pull in other branches as well.

-- 
David Kastrup

Re: Obscure error/warning/information message from git pull

[Florian Weimer]

* Alan Mackenzie:

> This doesn't work very well.  It prints out the information for the first
> commit that is displayed, but no more.  This feels like a git bug.

Git does not record the branch on which a commit was made.  It's
sometimes recorded in merges, but only in the free-text commit
message.  For fast-forward merges (without a separate merge commit),
there is no trace that development of certain commits happened on a
separate branch.

gitk can show precedes/follows information for tags, though.
Depending on the project's history, this can be quite useful.  (I have
not seen a command line tool which does the same thing.)

Re: Obscure error/warning/information message from git pull

[Alan Mackenzie]

Hello, David.

On Sat, Nov 15, 2014 at 03:35:35PM +0100, David Kastrup wrote:
> Alan Mackenzie <acm@muc.de> writes:

> > So "git clone" is defined in terms of "clone".  Looks like a recursive
> > "definition" to me - part of what "git clone" does is to "clone[s] a
> > repository".  There then follows an incoherent list of the form "does
> > A, then does B, then does C, ...".

> > What is missing is a definition of "clone".  It would appear to mean
> > "make a partial copy of".

> No.  Your copy is a complete copy of everything you ask for.  If you
> don't clone a particular branch, for example, by using a single-branch
> clone, that branch will not magically be in your repository.

After a "git clone", the copy is not the same as the original.  In
particular, branches are not preserved.  I don't know, as yet, what else
fails to be copied, but I have no great confidence in the documentation
to tell me.

A branch foo in a repository degrades to remotes/origin/foo when that
repository is "cloned", and, failing special action to save it,
disappears altogether in a second generation "clone".

Thus in my repository .../emacs-24, "cloned" from .../master, the
emacs-23 branch is irretrievably lost.

"git clone" makes a partial copy of a repository.  It does not duplicate
it.  "Clone", as a verb, means "duplicate"; it never means "truncate".

> > Please correct me if I'm mistaken here, but I think my "git clone"ing
> > of the repository at savannah only partially copied that repository,
> > thus I have an incomplete copy of it.

> It depends on what you cloned.  It will clone exactly what you asked it
> to clone.  If you chose not to clone some branches, they will not be in
> your repository.

I chose to clone a repository.  git did not do this for me.

> > So git's concept of "distributed vcs" is that the repository is
> > collectively stored across many computers, as contrasted with bzr's
> > and hg's model where the complete repository is stored on each
> > participating computer.

> Nonsense.  _Everything_ you asked for is stored on your computer.  Git
> does not maintain any data off-computer.

This is confusing.  Is it the case that branches labelled
"remotes/origin/..." are completely contained within the same repository?

Is there anywhere in the git documentation, or elsewhere, which lists
what entities are preserved by "git clone", and which ones are deleted or
modified?

> > And a subsequent git checkout will require access, possibly net
> > access, to the repository from which the current one was copied, yes?

> No.  checkouts are a strictly local operation.

> -- 
> David Kastrup

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Obscure error/warning/information message from git pull

[Achim Gratz]

Alan Mackenzie writes:
> After a "git clone", the copy is not the same as the original.

If you really want an exact copy of your local repository, then just
make a plain copy or do a mirror clone, THis implies making it "bare"
(without a work tree), so you'd then have to move things around so that
you can have your work tree checked out.  But you can do that, it's just
that this is almost never what you want.

> In particular, branches are not preserved.  I don't know, as yet, what else
> fails to be copied, but I have no great confidence in the documentation
> to tell me.

You don't want second generation clone of the Savannah repository, you
want another first generation one.  Again, the most efficient way to do
this is to reference your already existing clone when doing it so that
the actual objects are not transferred again over the net, but taken
from the "master" clone.

[…]
> This is confusing.  Is it the case that branches labelled
> "remotes/origin/..." are completely contained within the same repository?

No, they are labels pointing to the (heads of the) corresponding
branches in the upstream repository.  A branch is nothing more than a
label in Git, all you really need to know is the SHA1 for the branch
head to (re-)create it.  You could give them different names in your
clone if you wanted (no, that isn't a good idea either) or drop all but
master and emacs-24 branches by changing the refspecs to be fetched.
You can do this with commands or (often more simply for larger changes)
by just opening the config file in Emacs and writing out what it is you
want Git to do with that repo.

> Is there anywhere in the git documentation, or elsewhere, which lists
> what entities are preserved by "git clone", and which ones are deleted or
> modified?

Yes, the manpage of git clone.  It talks at some length about the
relation of the clone to its upstream (that thing called "origin") and
that should make it pretty clear that two clones will not be exactly
identical if they are pointing to a different upstream.  However, all
the actual objects are indeed copied, so you can modify the upstream
even after the fact and the next git fetch will set things up as you
wanted.  Go ahead and try it, copy that section about the origin in
.git/config from master to emacs-24 and see for yourself.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves

Re: Obscure error/warning/information message from git pull

[Alan Mackenzie]

Hello, Florian.

On Sat, Nov 15, 2014 at 08:40:09PM +0100, Florian Weimer wrote:
> * Alan Mackenzie:

> > This doesn't work very well.  It prints out the information for the first
> > commit that is displayed, but no more.  This feels like a git bug.

> Git does not record the branch on which a commit was made.

But as I understand it, the head of each branch is identified by a
pointer, and all previous commits are in a chain starting at this
pointer.  So git should know which branch each commit is on.  Why can it
not display this information?

> It's sometimes recorded in merges, but only in the free-text commit
> message.  For fast-forward merges (without a separate merge commit),
> there is no trace that development of certain commits happened on a
> separate branch.

> gitk can show precedes/follows information for tags, though.
> Depending on the project's history, this can be quite useful.  (I have
> not seen a command line tool which does the same thing.)

I'll get gitk working sometime.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Obscure error/warning/information message from git pull

[Florian Weimer]

* Alan Mackenzie:

> Hello, Florian.
>
> On Sat, Nov 15, 2014 at 08:40:09PM +0100, Florian Weimer wrote:
>> * Alan Mackenzie:
>
>> > This doesn't work very well.  It prints out the information for the first
>> > commit that is displayed, but no more.  This feels like a git bug.
>
>> Git does not record the branch on which a commit was made.
>
> But as I understand it, the head of each branch is identified by a
> pointer, and all previous commits are in a chain starting at this
> pointer.  So git should know which branch each commit is on.  Why can it
> not display this information?

Branches are just names for commits, the only difference from tags is
that Git has tool support to automatically move the branch to the
child commit, effectively adding the commit to the branch.

It's really like lists in Emacs.  If you splice two of them together,
the resulting data structure no longer reflects that, it's seamless.
You can only recover the join point if you kept a reference to both
lists before modification.

Re: Obscure error/warning/information message from git pull

[David Kastrup]

Alan Mackenzie <acm@muc.de> writes:

> Hello, Florian.
>
> On Sat, Nov 15, 2014 at 08:40:09PM +0100, Florian Weimer wrote:
>> * Alan Mackenzie:
>
>> > This doesn't work very well.  It prints out the information for the first
>> > commit that is displayed, but no more.  This feels like a git bug.
>
>> Git does not record the branch on which a commit was made.
>
> But as I understand it, the head of each branch is identified by a
> pointer, and all previous commits are in a chain starting at this
> pointer.  So git should know which branch each commit is on.  Why can it
> not display this information?

git log --source --all

I might have mentioned this already.  Like, half a dozen times.

-- 
David Kastrup

Re: Obscure error/warning/information message from git pull

[David Kastrup]

Alan Mackenzie <acm@muc.de> writes:

> Hello, David.
>
> On Sat, Nov 15, 2014 at 03:35:35PM +0100, David Kastrup wrote:
>> Alan Mackenzie <acm@muc.de> writes:
>
>> > So "git clone" is defined in terms of "clone".  Looks like a recursive
>> > "definition" to me - part of what "git clone" does is to "clone[s] a
>> > repository".  There then follows an incoherent list of the form "does
>> > A, then does B, then does C, ...".
>
>> > What is missing is a definition of "clone".  It would appear to mean
>> > "make a partial copy of".
>
>> No.  Your copy is a complete copy of everything you ask for.  If you
>> don't clone a particular branch, for example, by using a single-branch
>> clone, that branch will not magically be in your repository.
>
> After a "git clone", the copy is not the same as the original.  In
> particular, branches are not preserved.

A local branch in the source directory becomes a remote branch in the
clone.  Remote branches in the clone are not exported.

> I don't know, as yet, what else fails to be copied, but I have no
> great confidence in the documentation to tell me.
>
> A branch foo in a repository degrades to remotes/origin/foo when that
> repository is "cloned", and, failing special action to save it,
> disappears altogether in a second generation "clone".
>
> Thus in my repository .../emacs-24, "cloned" from .../master, the
> emacs-23 branch is irretrievably lost.
>
> "git clone" makes a partial copy of a repository.  It does not
> duplicate it.  "Clone", as a verb, means "duplicate"; it never means
> "truncate".

If you do not want the upstream of the clone to be the original, then
use

git clone --mirror

> I chose to clone a repository.  git did not do this for me.

You'll find that creating a biological clone of you does not give an
identical twin either.  Different age, different descendency.  If you
want a replication, use git clone --mirror.

>> Nonsense.  _Everything_ you asked for is stored on your computer.
>> Git does not maintain any data off-computer.
>
> This is confusing.  Is it the case that branches labelled
> "remotes/origin/..." are completely contained within the same
> repository?

Yes.  You can create a local branch from them using

git checkout -b mywhatever origin/branchname

and then work on that branch, looking at its history, without once going
online.  If it's there at all, it is filled in.

You cannot _commit_ to such remote-tracking branches stored on your
computer.  If you check them out, you just get a detached HEAD if you
don't create a local branch tracking the remote.  You can commit to a
detached HEAD but that does not touch your remote branch information.
There are only two ways to update the remote branch information: either
by fetching.  _Or_ by successfully _pushing_ to the corresponding
repository in which case Git also updates its idea of it.

> Is there anywhere in the git documentation, or elsewhere, which lists
> what entities are preserved by "git clone", and which ones are deleted
> or modified?

I'd try

    man git-clone

or

    git clone --help

-- 
David Kastrup

Re: Obscure error/warning/information message from git pull

[David Kastrup]

Achim Gratz <Stromeko@nexgo.de> writes:

> Alan Mackenzie writes:
>> After a "git clone", the copy is not the same as the original.
>
> If you really want an exact copy of your local repository, then just
> make a plain copy or do a mirror clone, THis implies making it "bare"
> (without a work tree), so you'd then have to move things around so that
> you can have your work tree checked out.  But you can do that, it's just
> that this is almost never what you want.
>
>> In particular, branches are not preserved.  I don't know, as yet, what else
>> fails to be copied, but I have no great confidence in the documentation
>> to tell me.
>
> You don't want second generation clone of the Savannah repository, you
> want another first generation one.  Again, the most efficient way to do
> this is to reference your already existing clone when doing it so that
> the actual objects are not transferred again over the net, but taken
> from the "master" clone.
>
> […]
>> This is confusing.  Is it the case that branches labelled
>> "remotes/origin/..." are completely contained within the same repository?
>
> No, they are labels pointing to the (heads of the) corresponding
> branches in the upstream repository.

Git fetches all information sitting behind such labels whenever it
fetches a label, so that "No" is either used in some extremely
misleading manner or just mistaken.

_Every_ branch in Git, remote-tracking or local, is just a label
pointing to some object.  Both upstream repository and local repository
are object stores, and any object having the same SHA1 is the _same_
object.  There is no such thing as "corresponding branch in the upstream
repository".  Object ids mean exactly the same in upstream and clones.
It is one namespace.  I can manually set a label without getting the
information, local or remote.  Then the repository is incomplete (git
fsck would complain).  I can fill in the missing objects in any way
I like: by fetching them, or by using

    git hash-object -w

on a file with suitable content.

> A branch is nothing more than a label in Git, all you really need to
> know is the SHA1 for the branch head to (re-)create it.

Not really: you need the objects behind it as well.  When deleting a
branch, the object store of Git keeps them around for a few weeks and
will clean them out then on the next garbage collection.  If you
recreate the branch head any time before that, this will work without
problem.  If you recreate it afterwards, the repository will be
incomplete.  Fetching branches is more reliable than creating references
and hoping that the objects will happen to be around.

-- 
David Kastrup

Re: Obscure error/warning/information message from git pull

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 1534 bytes --]

() Alan Mackenzie <acm@muc.de>
() Fri, 14 Nov 2014 23:02:36 +0000

   > Because in GIT commits are not on a branch. All commits are
   > arranged into DAG, and branch is just a pointer into the DAG.
   > Any given commit is either reachable from given branch or
   > not. It's that simple.

   I think you're just playing with words, here.  We all know what
   a branch is,

Terminology differs between VCS models.  For RCS and conceptual
derivatives, a "branch" is a series of commits, and a commit can be
viewed as "contained in" or "belonging to" a branch; in the DAG,
"branch" includes both vertice and edge information.  For Git, a
"branch" is a vertice label only (edge information lies in the
"commit object").  Changing a label has no effect on the commit or
the edge info, and you can have more than one label on a commit.

   and git knows which revisions are on which branch (or
   branches?), otherwise your command below couldn't work.

It "knows" it, sure, but if the way it knows it and the way you
think it knows it differ, you will remain confused.  I read some
time back "Git for computer scientists" (or maybe it was "for Lisp
programmers") that explained the above, more elegantly.  I can't be
bothered to search for it now; perhaps someone has a link handy?

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Obscure error/warning/information message from git pull

[Tassilo Horn]

[-- Attachment #1: Type: text/plain, Size: 333 bytes --]

Thien-Thi Nguyen <ttn@gnu.org> writes:

> I read some time back "Git for computer scientists" (or maybe it was
> "for Lisp programmers") that explained the above, more elegantly.  I
> can't be bothered to search for it now; perhaps someone has a link
> handy?

  http://eagain.net/articles/git-for-computer-scientists/

Bye,
Tassilo

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 212 bytes --]

Re: Obscure error/warning/information message from git pull

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Sun, 16 Nov 2014 10:23:23 +0100
> 
> > "git clone" makes a partial copy of a repository.  It does not
> > duplicate it.  "Clone", as a verb, means "duplicate"; it never means
> > "truncate".
> 
> If you do not want the upstream of the clone to be the original, then
> use
> 
> git clone --mirror

But that implies --bare, which means no working tree, right?  So I
think this is not what Alan wants.

Re: Obscure error/warning/information message from git pull

[Eli Zaretskii]

> From: Thien-Thi Nguyen <ttn@gnu.org>
> Date: Sun, 16 Nov 2014 14:25:02 +0100
> 
> () Alan Mackenzie <acm@muc.de>
> () Fri, 14 Nov 2014 23:02:36 +0000
> 
>    > Because in GIT commits are not on a branch. All commits are
>    > arranged into DAG, and branch is just a pointer into the DAG.
>    > Any given commit is either reachable from given branch or
>    > not. It's that simple.
> 
>    I think you're just playing with words, here.  We all know what
>    a branch is,
> 
> Terminology differs between VCS models.  For RCS and conceptual
> derivatives, a "branch" is a series of commits, and a commit can be
> viewed as "contained in" or "belonging to" a branch; in the DAG,
> "branch" includes both vertice and edge information.  For Git, a
> "branch" is a vertice label only (edge information lies in the
> "commit object").

This is a red herring.  You are confusing the concept of a "branch"
with the Git implementation of branches.  The implementation is a
label, but "branch" the concept is the set of commits reachable from
the branch tip, in Git as in any other VCS.  Unlike what you wrote,
the revision history is conceptually _always_ a DAG, even in RCS.

>    and git knows which revisions are on which branch (or
>    branches?), otherwise your command below couldn't work.
> 
> It "knows" it, sure, but if the way it knows it and the way you
> think it knows it differ, you will remain confused.

You are in fact saying that it is impossible for a Git newbie to grasp
the basic concepts and do any useful work without a detailed
understanding of the internals.  I don't think it's true.

Re: Obscure error/warning/information message from git pull

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Date: Sun, 16 Nov 2014 10:23:23 +0100
>> 
>> > "git clone" makes a partial copy of a repository.  It does not
>> > duplicate it.  "Clone", as a verb, means "duplicate"; it never means
>> > "truncate".
>> 
>> If you do not want the upstream of the clone to be the original, then
>> use
>> 
>> git clone --mirror
>
> But that implies --bare, which means no working tree, right?  So I
> think this is not what Alan wants.

You can just clone into something like mymirror/.git and then edit the
"bare" flag in the config file.  Slightly ridiculous but workable.

-- 
David Kastrup

Re: Obscure error/warning/information message from git pull

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

> You are in fact saying that it is impossible for a Git newbie to grasp
> the basic concepts and do any useful work without a detailed
> understanding of the internals.  I don't think it's true.

Git has been designed and built from the internals up.  A number of
commands in daily use are what the Git authors call "plumbing".  There
are some mostly end-user oriented programs characterized as "porcelaine"
but they don't form a complete and coherent set.

The initial understanding was that actual version control applications
for "end users" would be designed with Git as an engine.  There have
been a few experiments for creating different workflows on top of Git
like "quilt" and "stgit" but while they have a bit of a user base, none
of those is actually used to any significant degree when compared to
just Git.

It's not that different from Emacs itself where a lot of defaults and
options and commands are "user-friendly" but, in contrast to other
"user-friendly" editors, when trying to solve real-world tasks on your
own you are likely going to run into complexity and Elisp leaking in
your face.  So it's not all that rare when demonstrating the user
friendliness of Emacs, there are the occasional 10 seconds where you
have to ask your audience to look away for a moment.

Git workflows with the default commands are rather close to the
"plumbing" and need to refer to it at times.  As a result, it's fairly
easy to run into "look away for a minute" territory.  So "I don't want
to learn about internals" may be even less successful in the long run
than "I don't want to learn about Elisp" is with Emacs, and there is
less of a tradition with Git over Emacs of having others around who have
built turnkey applications for your workflows.

-- 
David Kastrup

Re: Obscure error/warning/information message from git pull

[Andreas Schwab]

David Kastrup <dak@gnu.org> writes:

> The initial understanding was that actual version control applications
> for "end users" would be designed with Git as an engine.  There have
> been a few experiments for creating different workflows on top of Git
> like "quilt" and "stgit" but while they have a bit of a user base, none

s/quilt/guilt/

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Obscure error/warning/information message from git pull

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Sun, 16 Nov 2014 17:16:34 +0100
> 
> It's not that different from Emacs itself where a lot of defaults and
> options and commands are "user-friendly" but, in contrast to other
> "user-friendly" editors, when trying to solve real-world tasks on your
> own you are likely going to run into complexity and Elisp leaking in
> your face.  So it's not all that rare when demonstrating the user
> friendliness of Emacs, there are the occasional 10 seconds where you
> have to ask your audience to look away for a moment.
> 
> Git workflows with the default commands are rather close to the
> "plumbing" and need to refer to it at times.  As a result, it's fairly
> easy to run into "look away for a minute" territory.  So "I don't want
> to learn about internals" may be even less successful in the long run
> than "I don't want to learn about Elisp" is with Emacs, and there is
> less of a tradition with Git over Emacs of having others around who have
> built turnkey applications for your workflows.

I was talking about newbies starting to use Git.  Newbies, in Emacs
and Git alike, start with copying cookbook-like recipes without deep
understanding of the internals.  Later they learn more.  But even
before that, they need some mental model of what they are doing.  That
model does not need to be exact as far as details go, but it must
grasp the main concepts.

I'm saying that brainwashing newbies with implementation details, and
especially insisting on the point that Git is unlike anything else
they are familiar with, is counter-productive.  It just raises one
more high obstacle for them to negotiate, unnecessarily.  Let them get
to that in their due time.  Meanwhile, if they can successfully apply
familiar concepts, let them.

Re: Obscure error/warning/information message from git pull

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 2643 bytes --]

() Eli Zaretskii <eliz@gnu.org>
() Sun, 16 Nov 2014 17:35:53 +0200

   This is a red herring.  You are confusing the concept of a
   "branch" with the Git implementation of branches.

Maybe.

   The implementation is a label, but "branch" the concept is
   the set of commits reachable from the branch tip, in Git as
   in any other VCS.

Unfortunately, i get the impression from the few Git manpages
i've really read thoroughly that the clean distinction between
"branch" the concept and "branch" the user-facing specification
for a DAG vertex is not very important.

   Unlike what you wrote, the revision history is conceptually
   _always_ a DAG, even in RCS.

I'm sorry i gave that impression; at the conceptual level i
agree that all these systems manipulate DAGs.  My point was to
deconstruct (a bit) the different ways vertex/edge information
can be divvied, mainly to suggest that over-attachment to one
or another "branch" concept is a good place to apply awareness
hacking.

   > It "knows" it, sure, but if the way it knows it and the
   > way you think it knows it differ, you will remain
   > confused.

   You are in fact saying that it is impossible for a Git
   newbie to grasp the basic concepts and do any useful work
   without a detailed understanding of the internals.

That's a valid interpretation, i suppose, in which case...

   I don't think it's true.

i would agree.  However, it's not the only one.  Generally, i
think even the newest of newbies benefits from separating the
applicable from the inapplicable baggage carried into any new
effort.

Here, as elaborated (and nicely compared to Emacs) by dak,
there is also the opportunity (or needless pain, YMMV) for
users to touch some fundamental data structures and algorithms,
or at least to enjoy (or suffer) their touchings and teachings
by some real experts.  That these experts could not maintain
the putative distinction between "plumbing" and "porcelain" is
perhaps less a failing on their part and more indicative of the
strength of the underlying data model.

Anyway, i don't argue that the word "branch" is well suited for
the concept of "vertex label".  It is, by now, historical.
Same logic is why we talk about CAR and CDR, half a century on.
The only difference is that "branch" is a pre-existing word in
VCS, CS, biology, etc.  Unfortunate choice, in hindsight.

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Obscure error/warning/information message from git pull

[Sergey Organov]

Alan Mackenzie <acm@muc.de> writes:

>
>> Because in GIT commits are not on a branch. All commits are arranged into
>> DAG, and branch is just a pointer into the DAG. Any given commit is
>> either reachable from given branch or not. It's that simple.
>
> I think you're just playing with words, here.  We all know what a branch
> is, and git knows which revisions are on which branch (or branches?),

You pretend you don't understand what I said above? It's not for playing
with words. One better speaks "GIT language" if he wants to be efficient
with GIT. Doing otherwise is, well, like speaking procedural in
functional language...

> otherwise your command below couldn't work.

They could, because there is the DAG.

>> Try:
>
>> $ git log --oneline --decorate emacs24 ^master
>
>> that will show all commits that are reachable from 'emacs24' but not
>> reachable from 'master'.
>
> That's very impressive, but not what I want.  I want to see all recent
> commits together, each one annotated with which branch it's on.  That's
> surely not too much to ask for.  I want annotation, not filtering.

Did you try my another suggestion then?

$ git show-branch emacs24 master

-- 
Sergey.

Re: Obscure error/warning/information message from git pull

[Alan Mackenzie]

Hello, Sergey.

On Mon, Nov 17, 2014 at 02:54:06PM +0300, Sergey Organov wrote:
> Alan Mackenzie <acm@muc.de> writes:


> >> Because in GIT commits are not on a branch. All commits are arranged into
> >> DAG, and branch is just a pointer into the DAG. Any given commit is
> >> either reachable from given branch or not. It's that simple.

> > I think you're just playing with words, here.  We all know what a branch
> > is, and git knows which revisions are on which branch (or branches?),

> You pretend you don't understand what I said above?

I didn't understand when I wrote it, I think I do now.  You want to use
"branch" to mean what people like me would call "branch tip" or "branch
head".  This change in meaning can only lead to confusion and
difficulties communicating.

> It's not for playing with words. One better speaks "GIT language" if he
> wants to be efficient with GIT.

I looked in the git glossary, and that confirmed that the official usage
of "branch" is as I have used and continue to use it.

> Doing otherwise is, well, like speaking procedural in functional
> language...

If you use "branch" for what I call "branch head", what term do you use
for what I call "branch"?

It strikes me that the git people have failed to form working
abstractions.  In every other VCS system I've used, "branch" is a clean
abstraction with the same meaning.  In git, it is anything but clean -
the bifurcation of the (abstract) branch emacs-24 into
remotes/origin/emacs-24 and emacs-24 itself destroys the abstraction -
people using it are forced to think in terms of the implementation, and
are forced to do additional work (e.g. git merge; git checkout emacs-24;
git merge; git checkout master) to achieve what is automatic in, say,
Mercurial.

> > otherwise your command below couldn't work.

> They could, because there is the DAG.

> >> Try:

> >> $ git log --oneline --decorate emacs24 ^master

> >> that will show all commits that are reachable from 'emacs24' but not
> >> reachable from 'master'.

> > That's very impressive, but not what I want.  I want to see all recent
> > commits together, each one annotated with which branch it's on.  That's
> > surely not too much to ask for.  I want annotation, not filtering.

> Did you try my another suggestion then?

I can't remember.  I'm still very confused about git, and what I have and
haven't tried.  Somebody suggested a form of "git log" where an
approximation to branches was displayed, but rather poorly; it was
described by the manual in terms of how it was implemented rather than a
user abstraction.

> $ git show-branch emacs24 master

Just tried that; it's interesting!  Thanks.  Maybe there's some way I can
persuade it to display the commit date and committer too.  Then I'll have
all the essential information about commits together.

> -- 
> Sergey.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Obscure error/warning/information message from git pull

[Sergey Organov]

Alan Mackenzie <acm@muc.de> writes:

> Hello, Sergey.
>
> On Mon, Nov 17, 2014 at 02:54:06PM +0300, Sergey Organov wrote:
>> Alan Mackenzie <acm@muc.de> writes:
>
>
>> >> Because in GIT commits are not on a branch. All commits are arranged into
>> >> DAG, and branch is just a pointer into the DAG. Any given commit is
>> >> either reachable from given branch or not. It's that simple.
>
>> > I think you're just playing with words, here.  We all know what a branch
>> > is, and git knows which revisions are on which branch (or branches?),
>
>> You pretend you don't understand what I said above?
>
> I didn't understand when I wrote it, I think I do now.  You want to use
> "branch" to mean what people like me would call "branch tip" or "branch
> head".  This change in meaning can only lead to confusion and
> difficulties communicating.
>
>> It's not for playing with words. One better speaks "GIT language" if he
>> wants to be efficient with GIT.
>
> I looked in the git glossary, and that confirmed that the official usage
> of "branch" is as I have used and continue to use it.

Please continue to call branch "branch", no opposition.

My point is that once you send "branch" to a Git command, it effectively
becomes "branch tip", "branch head", or "ref", or a "pointer to
particular commit", whatever we might call it, as Git itself has no
"branches" that are "active lines of development" in its data model.

Understanding this makes it clear why you need to say something like this:

$ git log --source emacs-24 origin/master

to get "list of commits with branch names", where:

       --source
           Print out the ref name given on the command line by which each
           commit was reached.

Please notice no "branch" in the description of the "--source", and
notice that "origin/master" is a ref, but not actually a branch, that
makes no difference for Git. You can have used Git tag the same way and
it would still work.Kinda like "everything is a buffer" in Emacs.

-- 
Sergey.

Re: Obscure error/warning/information message from git pull

[Eli Zaretskii]

> From: Sergey Organov <sorganov@gmail.com>
> Date: Tue, 18 Nov 2014 19:59:51 +0300
> 
> My point is that once you send "branch" to a Git command

You don't send a branch to Git commands, you send the branch's
_label_, or _name_.  Let's distinguish between the thing and its name,
okay?

> Git itself has no "branches" that are "active lines of development"
> in its data model.

Git might not have it, but we its users do.

> Understanding this makes it clear why you need to say something like this:
> 
> $ git log --source emacs-24 origin/master

What's to understand? a branch name in this context represents its
last commit, a.k.a. "tip".  That's all.  Why are you trying to make
this more confusing than it should be?

>        --source
>            Print out the ref name given on the command line by which each
>            commit was reached.
> 
> Please notice no "branch" in the description of the "--source"

I'd suggest not to treat Git docs as a kind of "holy scripture" whose
exact wording has any magic meaning beyond what meets the eye.  Don't
look for some deep meaning in the words used there, because more often
than not there isn't any.

> Kinda like "everything is a buffer" in Emacs.

But everything is not a buffer in Emacs.  There are other objects as
well, most of them quite different from buffers.

Re: Obscure error/warning/information message from git pull

[Sergey Organov]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Sergey Organov <sorganov@gmail.com>
>> Date: Tue, 18 Nov 2014 19:59:51 +0300
>> 
>> My point is that once you send "branch" to a Git command
>
> You don't send a branch to Git commands, you send the branch's
> _label_, or _name_. Let's distinguish between the thing and its name,
> okay?

Yes, you send a _name_. It does not represent "branch" the "active line
of development" though. It just points to particular commit.

>
>> Git itself has no "branches" that are "active lines of development"
>> in its data model.
>
> Git might not have it, but we its users do.

You are welcome to have them. In your mind. This won't help you to
understand Git better. It's the latter that I've tried to help to
achieve. Sorry if I failed.

>
>> Understanding this makes it clear why you need to say something like this:
>> 
>> $ git log --source emacs-24 origin/master
>>
>> to get "list of commits with branch names", where:
>
> What's to understand?

Why it is not:

$ git log --show-branch-names emacs-24 origin/master

> a branch name in this context represents its last commit, a.k.a.
> "tip".That's all. Why are you trying to make this more confusing than
> it should be?

My point is that branch name doesn't represent anything else but
particular reference to particular commit in Git.

>>        --source
>>            Print out the ref name given on the command line by which each
>>            commit was reached.
>> 
>> Please notice no "branch" in the description of the "--source"
>
> I'd suggest not to treat Git docs as a kind of "holy scripture" whose
> exact wording has any magic meaning beyond what meets the eye. Don't
> look for some deep meaning in the words used there, because more often
> than not there isn't any.

The description in the docs is very exact. Sorry you don't see it, that
means I'm not very good at explaining it indeed.

BTW, Emacs docs are no less a "holy scripture" as well, until you start
to at least remotely understand the whole picture.

>
>> Kinda like "everything is a buffer" in Emacs.
>
> But everything is not a buffer in Emacs.  There are other objects as
> well, most of them quite different from buffers.

Sure, there are other objects but refs in Git as well, but all the refs
are as similar as possible, be them branches or not.

-- 
Sergey.

Re: Obscure error/warning/information message from git pull

[Eli Zaretskii]

> From: Sergey Organov <sorganov@gmail.com>
> Date: Tue, 18 Nov 2014 20:58:15 +0300
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Sergey Organov <sorganov@gmail.com>
> >> Date: Tue, 18 Nov 2014 19:59:51 +0300
> >> 
> >> My point is that once you send "branch" to a Git command
> >
> > You don't send a branch to Git commands, you send the branch's
> > _label_, or _name_. Let's distinguish between the thing and its name,
> > okay?
> 
> Yes, you send a _name_. It does not represent "branch" the "active line
> of development" though. It just points to particular commit.

So a branch's name can serve more than one duty, so what?

> >> Git itself has no "branches" that are "active lines of development"
> >> in its data model.
> >
> > Git might not have it, but we its users do.
> 
> You are welcome to have them. In your mind. This won't help you to
> understand Git better.

It's orthogonal to understanding Git.

> It's the latter that I've tried to help to achieve. Sorry if I
> failed.

You cannot help people understand new tools if you start by telling
them to forget everything they've learned.  You should instead build
on what they know, or think they know, gradually replacing that with
new knowledge.

Regardless, the concept of "branch" as a separate line of development
is not killed by Git.  It's just that a branch can be named by its
tip, and vice versa.

> My point is that branch name doesn't represent anything else but
> particular reference to particular commit in Git.

No, it also represents all the previous commits made on that branch
that are reachable through first-parents.

> >> Please notice no "branch" in the description of the "--source"
> >
> > I'd suggest not to treat Git docs as a kind of "holy scripture" whose
> > exact wording has any magic meaning beyond what meets the eye. Don't
> > look for some deep meaning in the words used there, because more often
> > than not there isn't any.
> 
> The description in the docs is very exact. Sorry you don't see it, that
> means I'm not very good at explaining it indeed.

It's not your fault.  It's the fault of those who wrote that.

Sometimes being "exact" means being useless.

Re: Obscure error/warning/information message from git pull

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

> Regardless, the concept of "branch" as a separate line of development
> is not killed by Git.  It's just that a branch can be named by its
> tip, and vice versa.

A local branch is slightly more than its tip: you can be "on" a branch,
and if you commit then, the tip is advanced.  In contrast, a
remote-mirroring branch is indeed not more than its tip: checking it out
gives you a detached HEAD.  Committing does not change the branch tip.

Being "on" a branch also implies some defaults for actions like pushing,
pulling, rebasing, merging, committing.

But this "extra branchiness" only applies to branch heads.  Indeed, if
you write master^0 instead of master, the branchiness is already gone:
master^0 is not associated with the master branch specially in any way.
It's just the same as a naked commit id.

-- 
David Kastrup

Re: Obscure error/warning/information message from git pull

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Tue, 18 Nov 2014 19:40:51 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Regardless, the concept of "branch" as a separate line of development
> > is not killed by Git.  It's just that a branch can be named by its
> > tip, and vice versa.
> 
> A local branch is slightly more than its tip: you can be "on" a branch,
> and if you commit then, the tip is advanced.  In contrast, a
> remote-mirroring branch is indeed not more than its tip: checking it out
> gives you a detached HEAD.  Committing does not change the branch tip.

That's all true, but it again refers to how a branch is labeled or
specified.  By contrast, I'm talking about a "branch of development",
if you like: the series of commits made on a branch.  For that, it
doesn't matter whether the branch is local or remote, or if I can or
cannot change it by committing.

Really, this whole discussion sounds like a chapter from the immortal
"Alice", remember?

    “[...]The name of the song is called “HADDOCKS’ EYES.”‘

    ‘Oh, that’s the name of the song, is it?’ Alice said, trying to
    feel interested.

    ‘No, you don’t understand,’ the Knight said, looking a little
    vexed. ‘That’s what the name is CALLED. The name really IS “THE
    AGED AGED MAN.”‘

    ‘Then I ought to have said “That’s what the SONG is called”?’
    Alice corrected herself.

    ‘No, you oughtn’t: that’s quite another thing! The SONG is called
    “WAYS AND MEANS”: but that’s only what it’s CALLED, you know!’

    ‘Well, what IS the song, then?’ said Alice, who was by this time
    completely bewildered.

    ‘I was coming to that,’ the Knight said. ‘The song really IS
    “A-SITTING ON A GATE”: and the tune’s my own invention.’

Re: Obscure error/warning/information message from git pull

[Sergey Organov]

Eli Zaretskii <eliz@gnu.org> writes:

>> It's the latter that I've tried to help to achieve. Sorry if I
>> failed.
>
> You cannot help people understand new tools if you start by telling
> them to forget everything they've learned.  You should instead build
> on what they know, or think they know, gradually replacing that with
> new knowledge.

Sorry, but I really think that to better understand Git, one should
forget, at least temporarily, some things she learned from other VCSes.
Then after she gets what, say, "branch" means to Git, she can tweak her
previous knowledge to fit.

>
> Regardless, the concept of "branch" as a separate line of development
> is not killed by Git.  It's just that a branch can be named by its
> tip, and vice versa.
>
>> My point is that branch name doesn't represent anything else but
>> particular reference to particular commit in Git.
>
> No, it also represents all the previous commits made on that branch
> that are reachable through first-parents.

Well, given the following history (time goes from left to right):

             - C - D <- foo
           / 
... - A - B
           \
             - E - F <- bar


what branch commit A was made on, 'foo' or 'bar'?

You see, you should have had no "made on that branch" in your
description, provided you describe Gits' idea of a branch, not your one,
as Git does not remember on what branch commit was made.

-- 
Sergey.

Re: Obscure error/warning/information message from git pull

[John Yates]

[-- Attachment #1: Type: text/plain, Size: 1393 bytes --]

On Tue, Nov 18, 2014 at 1:18 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> You cannot help people understand new tools if you start by telling
> them to forget everything they've learned.  You should instead build
> on what they know, or think they know, gradually replacing that with
> new knowledge.
>

Earlier VCS often had more reified branches.  A phrase that crops up a
lot in git descriptions is "lightweight branching".  This was achieved
by paring back the branch concept - leaving nothing more than the nodes
reachable from a named ref - and by making ref manipulation very common.

When contrasting git to earlier VCS in none of the git intros I have
read have I seen that particular point made.

I have been programming for well over 40 years and have used many VCS.
Personally I always found branching a hurdle in earlier VCS, something
I avoided.  After using git for less than a year I can say emphatically
that I am far happier and more confident working with git's notion of
lightweight branching than with branching in any previous VCS I used
(and I have used a _lot_!)  I have noticed that as I now use branches
actively (both privately and with colleagues) I have a better, deeper
understanding of their concepts and mechanics.  The fact that a single
set of concepts and mechanism scales from the tiny/personal to the
large/project-wide helps one polish one's skills.

/john

[-- Attachment #2: Type: text/html, Size: 3231 bytes --]

Re: Obscure error/warning/information message from git pull

[Alan Mackenzie]

Hello, Sergey.

On Tue, Nov 18, 2014 at 11:57:34PM +0300, Sergey Organov wrote:
> Eli Zaretskii <eliz@gnu.org> writes:

> >> It's the latter that I've tried to help to achieve. Sorry if I
> >> failed.

> > You cannot help people understand new tools if you start by telling
> > them to forget everything they've learned.  You should instead build
> > on what they know, or think they know, gradually replacing that with
> > new knowledge.

> Sorry, but I really think that to better understand Git, one should
> forget, at least temporarily, some things she learned from other VCSes.
> Then after she gets what, say, "branch" means to Git, she can tweak her
> previous knowledge to fit.

You must also admit that git is at fault here for misusing common words.
A "branch" in English is not and cannot mean a "tip of a branch".  Yet
git has twisted the language such that this has become its meaning.  And
any cultured person must suppress his revulsion at such abuse as part of
the cost of learning git.  YUCK!

> > Regardless, the concept of "branch" as a separate line of development
> > is not killed by Git.  It's just that a branch can be named by its
> > tip, and vice versa.

> >> My point is that branch name doesn't represent anything else but
> >> particular reference to particular commit in Git.

> > No, it also represents all the previous commits made on that branch
> > that are reachable through first-parents.

> Well, given the following history (time goes from left to right):

>              - C - D <- foo
>            / 
> ... - A - B
>            \
>              - E - F <- bar


> what branch commit A was made on, 'foo' or 'bar'?

Quite clearly, A was committed on branch foo, since bar didn't exist at
that time.

> You see, you should have had no "made on that branch" in your
> description, provided you describe Gits' idea of a branch, not your one,
> as Git does not remember on what branch commit was made.

Are you saying that at B, when bar is branched from foo, git discards
all information about this branching, remembering only that there are two
branches which are henceforth of fully equal status where before there
was just one?

If this is indeed the case, it is not surprising that git's abstraction
of branching is so broken.

> -- 
> Sergey.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Obscure error/warning/information message from git pull

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > > Git itself has no "branches" that are "active lines of development"
 > > in its data model.
 > 
 > Git might not have it, but we its users do.

True, but in practice there are *no* VCSes that have "active lines of
development".  They have branch heads (aka "tips" in some VCSes), and
the VCS will just extend the branch from there.  Some VCSes make it
hard to establish a new head, and bitch unmercifully if you leave it
unmerged.  But the active line of development is still in your head --
even Bazaar doesn't try to keep you from committing arbitrary crap to
the mainline.  It just tries to "encourage" you to commit arbitrary
crap to the mainline, or alternatively postpone nonlinear work.  If
that works for you, good for you, but git is explicitly designed to
avoid that constraint.

That constraint is fine for projects where you can move ahead in a
straight line, and Emacs's workflow has been designed that way (eg,
only one supported version plus a free-for-all on trunk).  A lot of us
find that chafing, and enjoy the freedom that git provides to unify
our nonlinear practices with *one* concept that I might call "focus
of development".  Git's notion of branch ref is an excellent
approximation to focus of development in my experience, and I use it
a *lot*.

The analogy to Emacs's "modeless editing"[1] is quite appropriate, I
think.

 > > Kinda like "everything is a buffer" in Emacs.
 > 
 > But everything is not a buffer in Emacs.  There are other objects as
 > well, most of them quite different from buffers.

You're missing the point.  There are other objects in *Lisp*, but most
things users do are operations on buffers as far as the UI is
concerned.  Similarly, there are lots of things in git besides branch
refs, but most things users do operate on branch heads.  It's both an
approximation to git and an approximation as an analogy of git to
Emacs, but there's some truth there.


Footnotes: 
[1]  Ie, no division into "insert mode" and "edit mode".

Re: Obscure error/warning/information message from git pull

[Stephen J. Turnbull]

Sergey Organov writes:

 > You see, you should have had no "made on that branch" in your
 > description, provided you describe Gits' idea of a branch, not your one,
 > as Git does not remember on what branch commit was made.

No DAG-based VCS (with the single exception of Mercurial's "named
branches" AFAIK) remembers on what branch a commit was made.  What
Mercurial and Bazaar try to do is ensure a one-to-many branch-to-
workspace mapping, so that you must change workspaces to change the
focus of development.  Some people apparently enjoy that restraint.
What amazes me is that they're not all Java developers. ;-)

Re: Obscure error/warning/information message from git pull

[Alan Mackenzie]

Hello, Stephen.

On Wed, Nov 19, 2014 at 08:07:12AM +0900, Stephen J. Turnbull wrote:
> Sergey Organov writes:

>  > You see, you should have had no "made on that branch" in your
>  > description, provided you describe Gits' idea of a branch, not your one,
>  > as Git does not remember on what branch commit was made.

> No DAG-based VCS (with the single exception of Mercurial's "named
> branches" AFAIK) remembers on what branch a commit was made.

Are you sure?  When I do
    hg log -b c++11-0-1
, Mercurial lists every changeset made on branch c++11-0-1, and no other
changesets.  It knows when the branch was created, and distinguishes it
from the other branch it separated from.

I think this last feature is missing in git.

> What Mercurial and Bazaar try to do is ensure a one-to-many branch-to-
> workspace mapping, so that you must change workspaces to change the
> focus of development.  Some people apparently enjoy that restraint.

Can't say I've ever felt that to be any sort of restriction.  I can
imagine that having nine or ten foci of development in on workspace
would be unworkable in the extreme.

> What amazes me is that they're not all Java developers. ;-)

:-)

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Obscure error/warning/information message from git pull

[Barry Warsaw]

[-- Attachment #1: Type: text/plain, Size: 809 bytes --]

On Nov 18, 2014, at 10:43 PM, Alan Mackenzie wrote:

>You must also admit that git is at fault here for misusing common words.
>A "branch" in English is not and cannot mean a "tip of a branch".  Yet
>git has twisted the language such that this has become its meaning.  And
>any cultured person must suppress his revulsion at such abuse as part of
>the cost of learning git.  YUCK!

I would concur.  For someone with decades of $vcs experience, I think the
subtly (and sometimes not-so-) differences in terminology, which translates to
non-obvious cli behavior is the biggest impediment to drinking the git
kool-aid.  OTOH, it's also true that if you use primarily git for long enough,
you lose the beginners mind and just sort of accept the differences.  Aliases
can help. :)

Cheers,
-Barry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Obscure error/warning/information message from git pull

[Yuri Khan]

On Wed, Nov 19, 2014 at 4:43 AM, Alan Mackenzie <acm@muc.de> wrote:
>
>> Well, given the following history (time goes from left to right):
>
>>              - C - D <- foo
>>            /
>> ... - A - B
>>            \
>>              - E - F <- bar
>
>
>> what branch commit A was made on, 'foo' or 'bar'?
>
> Quite clearly, A was committed on branch foo, since bar didn't exist at
> that time.

But git does not know that. For all it knows, bar could be the
original branch and foo branched from it at B. The history above is
symmetrical.

> Are you saying that at B, when bar is branched from foo, git discards
> all information about this branching, remembering only that there are two
> branches which are henceforth of fully equal status where before there
> was just one?

There *is* no information to discard. Heads are completely separate
from the DAG, a thin convenience layer over it, an /etc/hosts analog
for SHA1 hashes. Head names are arbitrary and can be changed at any
time. Indeed, it is a common thing for me to start development on
master and make a few commits:

$ git checkout master
$ hack; git commit
$ hack; git commit
$ hack; git commit
$ hack; git commit

           o---o---o---o *master*
         /
---o---o origin/master

Oops, it’s going out of control and I will possibly need a couple days
more and I envision a prettifying rebase down the road. Let’s make it
a feature branch.

$ git branch feature

           o---o---o---o feature, *master*
         /
---o---o origin/master

Put master where it belongs:

$ git reset --hard origin/master

           o---o---o---o feature
         /
---o---o origin/master, *master*

Now continue work:

$ git checkout feature
$ hack; git commit

           o---o---o---o---o *feature*
         /
---o---o origin/master, master

If git remembered the branch name with each commit, that retroactive
branching would not be possible.


(Nitpicker’s corner: Some will say such workflows are sloppy and a bad
practice and one should always start work on a feature branch, even if
the feature is a one-liner, and then merge it to master with a
--no-ff. They are missing the point. Git *allows* us to be sloppy and
correct mistakes afterwards, rather than require constant vigilance.)

Re: Obscure error/warning/information message from git pull

[Stephen J. Turnbull]

Alan Mackenzie writes:

 > Are you sure?  When I do
 >     hg log -b c++11-0-1
 > , Mercurial lists every changeset made on branch c++11-0-1, and no other
 > changesets.  It knows when the branch was created, and distinguishes it
 > from the other branch it separated from.

I believe it's lying to you, unless you're using named branches.  If
you're using named branches, yes, it knows, but then you have other
problems (nodes and merges -- arguably the more important commits --
can only be on one branch, and either choice is the wrong one in some
use cases).

Specifically, in an ordinary Mercurial branch if at (2) you "hg pull"
from upstream, merging (3) and committing to get (4):

      2              2              2
     /              / \            / \
0 - 1    =>    0 - 1   *  =>  0 - 1   4
                    \ /            \ /
                     3              3

I don't see how it's possible to identify branches.  (Note that (2)
and (3) might both be nontrivial sequences of commits, so that
"branch" would be idiomatic in referring to them.)

Also, you have the question of which branch are (1) and (4) "on".  You
could argue that because (2) was committed to this repo before (3),
(1) and (4) are on (2)'s branch, but that might be semantically
incorrect: (1) - (3) - (4) is actually the planned line of development
(and (3) may have been pushed upstream before you committed (2), while
(2) is a typo fix or an out-of-the-blue "volunteer" contribution.
               
 > I think this last feature is missing in git.

Could be.  I don't have a use for it, so I can't help you there.

 > Can't say I've ever felt that to be any sort of restriction.

Come back in a year and I bet you'll have changed your mind. :-)

 > I can imagine that having nine or ten foci of development in on
 > workspace would be unworkable in the extreme.

It's no problem for me.  I typically have about that many: the
mainline, my principal feature branches (usually two or three), a
typos branch, and a few "memos on future work" branches.  There you
are, ten foci of development.

The typical "emphemeral branch" workflow (eg, typo fixes) is like this:

1) Detect a typo
2) Fix it (but don't save)
3) Save off branch name            -+
3) git stash save                   |
4) git checkout "typos"             |
5) Save file                        +- Implemented as an Emacs command
6) git commit -m "Fix typo."        |
7) git checkout <previous branch>   |
8) git stash pop                   -+

Note that only the branch name is variable, and can be automatically
determined.  So the whole thing takes a few seconds, and steps 3-8
seem to happen almost instantaneously.  (Note that I accumulate
several typos in this branch, so I usually rebase and smash the
commits to a single commit before pushing.  That's when I do a proper
log message.)  That is, in git it's "instantaneous".  In hg, it's
noticable, and in bzr it's time-consuming.  I use pipelines (my
preference now) or looms in bzr for that reason, but they are harder
to automate (possibly because I don't use them much).

The "memos" branches take more time, I haven't automated them yet.
The basic difference is that each memo branch basically amounts to a
nontrivial task ("refactor this", "apply an analogous fix here", "new
feature?")  unrelated to any currently active lines of development.
Sometimes the "memo" is nothing more than a branch ref stuck on the
current commit, but usually it involves comments in one or more files
(ugly, incomplete, probably unintelligible if you're not me).  If the
whole list of branches gets to more than about 20, I know it's time to
drop other work and clean up the name space because I'm unlikely to
get to all of these tasks.

Works for me.  Your Mileage May Vary.

Re: Obscure error/warning/information message from git pull

[Eli Zaretskii]

> From: Sergey Organov <sorganov@gmail.com>
> Date: Tue, 18 Nov 2014 23:57:34 +0300
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> It's the latter that I've tried to help to achieve. Sorry if I
> >> failed.
> >
> > You cannot help people understand new tools if you start by telling
> > them to forget everything they've learned.  You should instead build
> > on what they know, or think they know, gradually replacing that with
> > new knowledge.
> 
> Sorry, but I really think that to better understand Git, one should
> forget, at least temporarily, some things she learned from other VCSes.

Then we will have to agree to disagree.

> >> My point is that branch name doesn't represent anything else but
> >> particular reference to particular commit in Git.
> >
> > No, it also represents all the previous commits made on that branch
> > that are reachable through first-parents.
> 
> Well, given the following history (time goes from left to right):
> 
>              - C - D <- foo
>            / 
> ... - A - B
>            \
>              - E - F <- bar
> 
> 
> what branch commit A was made on, 'foo' or 'bar'?

Depends on when each one of the branches was created, of course.

> You see, you should have had no "made on that branch" in your
> description, provided you describe Gits' idea of a branch, not your one,
> as Git does not remember on what branch commit was made.

But that's the whole point of our disagreement: I'm talking about what
human users mean when they say "branch", while you keep talking about
what Git means.  When you try to explain to a human something that
involves branches, you had better did it in human terms, not program
implementation terms.  AKA "concept" vs "implementation".

Re: Obscure error/warning/information message from git pull

[Eli Zaretskii]

> Date: Tue, 18 Nov 2014 16:59:58 -0500
> From: John Yates <john@yates-sheets.org>
> Cc: Sergey Organov <sorganov@gmail.com>, Emacs developers <emacs-devel@gnu.org>
> On Tue, Nov 18, 2014 at 1:18 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>     You cannot help people understand new tools if you start by telling
>     them to forget everything they've learned. You should instead build
>     on what they know, or think they know, gradually replacing that with
>     new knowledge.
> 
> Earlier VCS often had more reified branches. A phrase that crops up a
> lot in git descriptions is "lightweight branching". This was achieved
> by paring back the branch concept - leaving nothing more than the nodes
> reachable from a named ref - and by making ref manipulation very common.
> 
> When contrasting git to earlier VCS in none of the git intros I have
> read have I seen that particular point made.

You are again talking about differences in implementation.  "Branch"
the concept does not change a bit, no matter what VCS are you using.

Re: Obscure error/warning/information message from git pull

[Teemu Likonen]

[-- Attachment #1: Type: text/plain, Size: 1050 bytes --]

Alan Mackenzie [2014-11-18 22:43:26 +00:00] wrote:

>> Well, given the following history (time goes from left to right):
>
>>              - C - D <- foo
>>            / 
>> ... - A - B
>>            \
>>              - E - F <- bar
>
>
>> what branch commit A was made on, 'foo' or 'bar'?
>
> Quite clearly, A was committed on branch foo, since bar didn't exist
> at that time.

No. "A" could have been committed on a private branch called
"asdfasdfasdf" by some unknown person. Then it may have been forget
various ways into that project's commit DAG. Branches are not places.
They just labels (sometimes temporary) that point to a commit. Nothing
more.

Commit operation in Git is like PUSH:

    (defvar a (cons 'original nil))
    (defvar foo a)
    (defvar bar a)

    (push 'commit1 foo)
    (push 'commit2 foo)
    (push 'commit1 bar)
    (push 'commit2 bar)

Both "foo" and "bar" point to a single cons cell. They know nothing
about _variable_ "a" (i.e., branch label). The same applies for Git
branches.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 835 bytes --]

Re: Obscure error/warning/information message from git pull

[Stephen J. Turnbull]

Teemu Likonen writes:

 > No. "A" could have been committed on a private branch called
 > "asdfasdfasdf" by some unknown person. Then it may have been forget
 > various ways into that project's commit DAG.

True enough.

 > Branches are not places.

But they are, in both Mercurial and Bazaar branches that are "named by
the directory they are stored in".

 > They just labels (sometimes temporary) that point to a
 > commit. Nothing more.

That's not true in Mercurial named branches.  I believe it's true of
both Mercurial and Bazaar branches that are "named by the directory
they are stored in", as well.

 > Commit operation in Git is like PUSH:

But Alan (and Eli) are *specifically* talking about their *abstract*
concepts of branch, independent of implementation.

Re: Obscure error/warning/information message from git pull

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 588 bytes --]

() Alan Mackenzie <acm@muc.de>
() Tue, 18 Nov 2014 22:43:26 +0000

   And any cultured person must suppress his revulsion at
   such abuse as part of the cost of learning git.  YUCK!

If you float high above enough, the cost is small, and
proportionally, the revulsion.  But only the mind can do
that, the body must fulfill its PEBKAC potential.  :-D

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Obscure error/warning/information message from git pull

[David Kastrup]

Barry Warsaw <barry@python.org> writes:

> On Nov 18, 2014, at 10:43 PM, Alan Mackenzie wrote:
>
>>You must also admit that git is at fault here for misusing common words.
>>A "branch" in English is not and cannot mean a "tip of a branch".  Yet
>>git has twisted the language such that this has become its meaning.  And
>>any cultured person must suppress his revulsion at such abuse as part of
>>the cost of learning git.  YUCK!
>
> I would concur.  For someone with decades of $vcs experience, I think the
> subtly (and sometimes not-so-) differences in terminology, which translates to
> non-obvious cli behavior is the biggest impediment to drinking the git
> kool-aid.

You can view your branch as anything you want to, but new identifiable
growth happens on branch tips or on new branching points on any good old
English tree.  And I was not aware that in plain English language any
piece of a tree has to have a primary association with one particular
twiglet considered to be its principal identity.

At any rate, I don't see the point in further explaining anything about
Git to a bunch of petulant overbearing bickerings.  Less special people
manage learning to work with their tools.  There is a saying in German
"Wenn der Bauer nicht schwimmen kann, liegt's an der Badehose" -- "if
the farmer can't swim, it's the swimming trunks' fault".

If you are so much smarter than the others, bring up your lectures on
the Git developer list.

-- 
David Kastrup

Re: Obscure error/warning/information message from git pull

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Tue, 18 Nov 2014 16:59:58 -0500
>> From: John Yates <john@yates-sheets.org>
>> Cc: Sergey Organov <sorganov@gmail.com>, Emacs developers <emacs-devel@gnu.org>
>> On Tue, Nov 18, 2014 at 1:18 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> 
>>     You cannot help people understand new tools if you start by telling
>>     them to forget everything they've learned. You should instead build
>>     on what they know, or think they know, gradually replacing that with
>>     new knowledge.
>> 
>> Earlier VCS often had more reified branches. A phrase that crops up a
>> lot in git descriptions is "lightweight branching". This was achieved
>> by paring back the branch concept - leaving nothing more than the nodes
>> reachable from a named ref - and by making ref manipulation very common.
>> 
>> When contrasting git to earlier VCS in none of the git intros I have
>> read have I seen that particular point made.
>
> You are again talking about differences in implementation.  "Branch"
> the concept does not change a bit, no matter what VCS are you using.

When "Branch the concept" leads you to conclude "this can't happen" for
things that clearly can, it is of moderate usefulness.

In a Git repository, the branching structure evolves.  The original
branches something was committed on may no longer exist (this is the
rule rather than the exception for user-committed changes "directly" in
master).  In Git, a branch is a throwaway entity, created on a whim,
renamed, moved, merged, rebased on a whim.  In CVS, it was something
really expensive IIRC.

Git has a record of the "real history".  This record is kept in
"reflogs" which are periodically cleaned out, are ephemeral, limited to
local access and tied into one particular repository.  The reflogs are
good for analyzing major oopses and recovering from them.  But they are
not part of the _distributed_ version control.

Reflogs contain the _actual_ history.  In contrast, everything one
shares with others is a deliberate, vetted history.  And that's what on
public and shared record.  This deliberate vetted history does not
include information about what branch some commit originated from.  You
may put something about it in the commit message, but it is not part of
the automatically managed metadata.  Keeping it consistent would be
really hard, and Git does not even try.

Pretending that it must nevertheless be a part of Git's concepts does
not really buy you anything.  You cannot make useful deductions about
Git's behavior based on theories that ascribe magic properties to
branches that have no reflection in the data Git actually stores.

-- 
David Kastrup

Re: Obscure error/warning/information message from git pull

[Achim Gratz]

Alan Mackenzie writes:
>> Well, given the following history (time goes from left to right):
>
>>              - C - D <- foo
>>            / 
>> ... - A - B
>>            \
>>              - E - F <- bar
>
>
>> what branch commit A was made on, 'foo' or 'bar'?
>
> Quite clearly, A was committed on branch foo, since bar didn't exist at
> that time.

Neither foo nor bar might even have existed at the time commit A was
made (or even any of the other commits shown).

> Are you saying that at B, when bar is branched from foo, git discards
> all information about this branching, remembering only that there are two
> branches which are henceforth of fully equal status where before there
> was just one?

Again, the branch diagram tells you nothing about the sequence of
events.  Your assumption about when something branched off what seems to
be based on the sequence of labels A..F.  There are no such orderable
sequences.  E might have been created before F or after, but that is a
moot point now that the commits have been entered into the DAG in the
order E,F.

> If this is indeed the case, it is not surprising that git's abstraction
> of branching is so broken.

…or your expectation of what branches are is broken.  Branch foo
consists of a label pointing at commit D and everything reachable from D
is on that branch.  You can check the _local_ history of such labels in
the reflog, but they aren't kept around forever.  Git gives you a
guarantee that once you have D the DAG will always stay exactly the same
no matter what.  It doesn't care what branch label or how many are
pointing to D as long as D does not become dangling.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: Obscure error/warning/information message from git pull

[Alan Mackenzie]

Hello, Achim.

On Wed, Nov 19, 2014 at 01:14:40PM +0100, Achim Gratz wrote:
> Alan Mackenzie writes:
> >> Well, given the following history (time goes from left to right):

> >>              - C - D <- foo
> >>            / 
> >> ... - A - B
> >>            \
> >>              - E - F <- bar


> >> what branch commit A was made on, 'foo' or 'bar'?

> > Quite clearly, A was committed on branch foo, since bar didn't exist at
> > that time.

> Neither foo nor bar might even have existed at the time commit A was
> made (or even any of the other commits shown).

OK, commit A might have been made on some other branch not in the
diagram.  But commit A was made before commit B (that is what these lines
_mean_) and commit B was made before branch bar was created (and possibly
before branch foo if that was branched of of B also, rather than being
the continuation of the branch A was made on).

> > Are you saying that at B, when bar is branched from foo, git discards
> > all information about this branching, remembering only that there are two
> > branches which are henceforth of fully equal status where before there
> > was just one?

> Again, the branch diagram tells you nothing about the sequence of
> events.

It must do.  D is based on C is based on B, and F is based on E is based
ob B, which in its turn is based on A.  Commit D thus happened after C,
etc.  We have a partial ordering, not a total ordering though.

> Your assumption about when something branched off what seems to be
> based on the sequence of labels A..F.  There are no such orderable
> sequences.  E might have been created before F or after, ....

How can E have been created after F?  That doesn't seem to make sense.

> but that is a moot point now that the commits have been entered into
> the DAG in the order E,F.

???  A "commit" is the action of appending something onto a tip of the
DAG.  Commits do not somehow exist independently of a DAG and then get
entered into it.

> > If this is indeed the case, it is not surprising that git's
> > abstraction of branching is so broken.

> …or your expectation of what branches are is broken.

The very essence of a branch is its creation on the trunk (or other
branch) and divergence from it.  Its point of creation is essential -
without it, it isn't a branch at all.  It seems git simply discards this
information.

> Branch foo consists of a label pointing at commit D and everything
> reachable from D is on that branch.

That is where git's abstraction is broken.  A is reachable from branch
bar, yet isn't on it and never has been - it's on the trunk, (or maybe
branch foo).

The practical outcome is that git doesn't keep track of your branches.
You've got to remember your branching structure (or write it on a piece
of paper) if you ever want, say, to get a list of changes made on branch
bar.  This is something I would expect a VCS to do for me automatically.
I think that is what the "..." in "master...bar" is all about.

> You can check the _local_ history of such labels in the reflog, but
> they aren't kept around forever.  Git gives you a guarantee that once
> you have D the DAG will always stay exactly the same no matter what.
> It doesn't care what branch label or how many are pointing to D as long
> as D does not become dangling.

Yes, that's what I'm saying, I think.

> Regards,
> Achim.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Obscure error/warning/information message from git pull

[Teemu Likonen]

[-- Attachment #1: Type: text/plain, Size: 322 bytes --]

Stephen J. Turnbull [2014-11-19 15:57:07 +09:00] wrote:

> Teemu Likonen writes:
>> No. "A" could have been committed on a private branch called
>> "asdfasdfasdf" by some unknown person. Then it may have been forget
>> various ways into that project's commit DAG.
>
> True enough.

Except that I wanted to write "forged".

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 835 bytes --]

Re: Obscure error/warning/information message from git pull

[David Kastrup]

Alan Mackenzie <acm@muc.de> writes:

> Hello, Achim.
>
> On Wed, Nov 19, 2014 at 01:14:40PM +0100, Achim Gratz wrote:
>> Alan Mackenzie writes:
>> >> Well, given the following history (time goes from left to right):
>
>> >>              - C - D <- foo
>> >>            / 
>> >> ... - A - B
>> >>            \
>> >>              - E - F <- bar
>
>
>> >> what branch commit A was made on, 'foo' or 'bar'?
>
>> > Quite clearly, A was committed on branch foo, since bar didn't exist at
>> > that time.
>
>> Neither foo nor bar might even have existed at the time commit A was
>> made (or even any of the other commits shown).
>
> OK, commit A might have been made on some other branch not in the
> diagram.  But commit A was made before commit B (that is what these
> lines _mean_) and commit B was made before branch bar was created (and
> possibly before branch foo if that was branched of of B also, rather
> than being the continuation of the branch A was made on).

Shrug.  That's pure conjecture.  The graph can end up in that manner in
a variety of different ways.  It's like trying to proclaim that some
data structure like a linked list must have been created in a particular
order.  That's just not an invariant of the data structure, and it is
not seminal to it, anyway.

>> Again, the branch diagram tells you nothing about the sequence of
>> events.
>
> It must do.  D is based on C is based on B, and F is based on E is
> based ob B, which in its turn is based on A.  Commit D thus happened
> after C, etc.  We have a partial ordering, not a total ordering
> though.

The partial ordering is one of commit dates but does not have any
relation to branches.

> The very essence of a branch is its creation on the trunk (or other
> branch) and divergence from it.  Its point of creation is essential -
> without it, it isn't a branch at all.  It seems git simply discards
> this information.

So Git does not have branches.  Happy?

>> Branch foo consists of a label pointing at commit D and everything
>> reachable from D is on that branch.
>
> That is where git's abstraction is broken.  A is reachable from branch
> bar, yet isn't on it and never has been - it's on the trunk, (or maybe
> branch foo).

Git does not maintain abstractions for the only sake of complicating
matters.  Any tangible data needs to be maintained, merged, transferred,
and needs semantics for all of the possible operations on and with
commits.

> The practical outcome is that git doesn't keep track of your branches.

Correct.  Whatever information it hands out about branches, it deduces
from the commit tree.

> You've got to remember your branching structure (or write it on a
> piece of paper) if you ever want, say, to get a list of changes made
> on branch bar.

Nonsense.  You first define what you even mean by "on branch bar".  If
you mean "after branching off of master", you get the list by saying

git log master..bar

If you mean something else, there are other things you may say.

> This is something I would expect a VCS to do for me automatically.  I
> think that is what the "..." in "master...bar" is all about.

You are aware that ... is not the same as ..?

-- 
David Kastrup

Re: Obscure error/warning/information message from git pull

[Sergey Organov]

Alan Mackenzie <acm@muc.de> writes:

> Hello, Achim.
>
> On Wed, Nov 19, 2014 at 01:14:40PM +0100, Achim Gratz wrote:
>> Alan Mackenzie writes:
>> >> Well, given the following history (time goes from left to right):
>
>> >>              - C - D <- foo
>> >>            / 
>> >> ... - A - B
>> >>            \
>> >>              - E - F <- bar
>
>
>> >> what branch commit A was made on, 'foo' or 'bar'?
>
>> > Quite clearly, A was committed on branch foo, since bar didn't exist at
>> > that time.
>
>> Neither foo nor bar might even have existed at the time commit A was
>> made (or even any of the other commits shown).
>
> OK, commit A might have been made on some other branch not in the
> diagram.  But commit A was made before commit B (that is what these lines
> _mean_) and commit B was made before branch bar was created (and possibly
> before branch foo if that was branched of of B also, rather than being
> the continuation of the branch A was made on).
>
>> > Are you saying that at B, when bar is branched from foo, git discards
>> > all information about this branching, remembering only that there are two
>> > branches which are henceforth of fully equal status where before there
>> > was just one?
>
>> Again, the branch diagram tells you nothing about the sequence of
>> events.
>
> It must do.  D is based on C is based on B, and F is based on E is based
> ob B, which in its turn is based on A.  Commit D thus happened after C,
> etc.  We have a partial ordering, not a total ordering though.

Yes, and this still does not tell you "on which branch" commit A was
created. Here is very simple example how this history could have been
created:

A <- bar

A - B <- bar

      <- foo
A - B <- bar

       - C - D <- foo
     /
A - B  <- bar

       - C - D <- foo
     /
A - B - E - F <- bar

Now, after I gave you the sequence of events, what new /essential/
information have you got? How it makes any difference if commit A was
not made in the manner you originally thought ("on branch 'foo'")?

[...]

>
>> …or your expectation of what branches are is broken.
>
> The very essence of a branch is its creation on the trunk (or other
> branch) and divergence from it. Its point of creation is essential -
> without it, it isn't a branch at all. It seems git simply discards
> this information.

Wow! We've finally learned something! Do you have an idea of why it
discards it? My bet is that it's because it's not worth the trouble to
maintain it, especially universally, in distributed manner.

Another essential question is: can you implement your favorite
abstraction on top of what Git provides? Yes, you can. As a very simple
method, name your branch 'foo' starting from branch 'bar', say,
'bar/foo'. Then you will probably be able to ask Git where 'bar/foo' has
diverged from 'bar', should you ever need it (that I doubt).

Side note: 'trunk', or 'master' is not any different for Git then any
other branch. Just in case...

>> Branch foo consists of a label pointing at commit D and everything
>> reachable from D is on that branch.
>
> That is where git's abstraction is broken.  A is reachable from branch
> bar, yet isn't on it and never has been - it's on the trunk, (or maybe
> branch foo).

That's the whole point. Git is somehow successful while it
(deliberately) has no notion of your lovely abstraction. How comes it
still provides enough functionality people need, without such a
fundamental thing? Can't it be that it uses more suitable abstraction
that doesn't have all the troubles your favorite abstraction has when
one tries to implement it in distributed manner?

-- 
Sergey.

Re: Obscure error/warning/information message from git pull

[Achim Gratz]

Alan Mackenzie writes:
> OK, commit A might have been made on some other branch not in the
> diagram.  But commit A was made before commit B (that is what these lines
> _mean_) and commit B was made before branch bar was created (and possibly
> before branch foo if that was branched of of B also, rather than being
> the continuation of the branch A was made on).

No, that's only what the published or local history looks like.

>> > Are you saying that at B, when bar is branched from foo, git discards
>> > all information about this branching, remembering only that there are two
>> > branches which are henceforth of fully equal status where before there
>> > was just one?
>
>> Again, the branch diagram tells you nothing about the sequence of
>> events.
>
> It must do.  D is based on C is based on B, and F is based on E is based
> ob B, which in its turn is based on A.  Commit D thus happened after C,
> etc.  We have a partial ordering, not a total ordering though.

When that graph was constructed the objects must have been available in
that order.  That doesn't mean they would have had to be created that
way.

>> Your assumption about when something branched off what seems to be
>> based on the sequence of labels A..F.  There are no such orderable
>> sequences.  E might have been created before F or after, ....
>
> How can E have been created after F?  That doesn't seem to make sense.

This is a distributed VCS.  Somebody may have pushed E, then someone
else rebased his older F on top of that.  You are looking at it in a
repo where that brach is called bar, but it may have come from a repo
where it was called something else.  Again, your only guarantee is this:
if you look at some other repo at any point in time and have the SHA1
for the objects pointed to by foo and bar, provided they exist, then
you'll end up with the exact same DAG as what you have from foo and bar
in your repo right now.

>> but that is a moot point now that the commits have been entered into
>> the DAG in the order E,F.
>
> ???  A "commit" is the action of appending something onto a tip of the
> DAG.  Commits do not somehow exist independently of a DAG and then get
> entered into it.

No, but there are multiple DAG, at least one in each of the existing
repos.  In Git a commit is made immutable precisely by recording the
parent(s) and changing the parent -- moving the commit in the DAG --
changes it's SHA1, but unless there are conflicting edits the action of
the commit can be applied in many positions in each of the possible
versions of the DAG.

>> > If this is indeed the case, it is not surprising that git's
>> > abstraction of branching is so broken.
>
>> …or your expectation of what branches are is broken.
>
> The very essence of a branch is its creation on the trunk (or other
> branch) and divergence from it.  Its point of creation is essential -
> without it, it isn't a branch at all.  It seems git simply discards this
> information.

No it's not.  Let's assume that foo and bar are remote branches from
different repositories.  In these repositories, there are no branches
and A is clearly reachable from the branch tips (probably called master)
in both repositories.  But when I look at them in a single repository,
they have been diverging after B.  So nobody has done this "very
essential" thing you talk about, yet clearly we have a branch point.

>> Branch foo consists of a label pointing at commit D and everything
>> reachable from D is on that branch.
>
> That is where git's abstraction is broken.  A is reachable from branch
> bar, yet isn't on it and never has been - it's on the trunk, (or maybe
> branch foo).

That's your problem all along and it simply doesn't make any practical
sense in a dVCS.  What if I later throw away foo and keep only bar?
Should that make A disappear?  If A has created file a.el and none of
the commits ever changed it, is it not available in branch bar?  Why
should I care that some developer thought foo was the trunk when
everyone else clearly has decided that for now it's bar?

Even nature disagrees with your view… If you cut the main branch from a
tree, one of the other branches will take its role.  Depending on when
you do this it will be close to impossible to tell from the old tree
that the trunk has been a branch.  So, nature and Git know a branch when
they see one, not when you first label it.  It's an emergent feature and
not a designated one.

> The practical outcome is that git doesn't keep track of your branches.
> You've got to remember your branching structure (or write it on a piece
> of paper) if you ever want, say, to get a list of changes made on branch
> bar.  This is something I would expect a VCS to do for me automatically.
> I think that is what the "..." in "master...bar" is all about.

Absolutely not.  The purpose of three dots "..." is (and again, read the
documentation for gitrevisions) to show all commits that are reachable
from either master or bar, but not both.  So it finds the branch point
and shows all commits on either side of that.  In other words, if you
were to merge the two branches, then all the commits shown in the log
yould be reachable from the merged branch (and be part of either
branch).


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: Obscure error/warning/information message from git pull

[David Kastrup]

Achim Gratz <Stromeko@nexgo.de> writes:

> Alan Mackenzie writes:
>> OK, commit A might have been made on some other branch not in the
>> diagram.  But commit A was made before commit B (that is what these lines
>> _mean_) and commit B was made before branch bar was created (and possibly
>> before branch foo if that was branched of of B also, rather than being
>> the continuation of the branch A was made on).
>
> No, that's only what the published or local history looks like.
>
>>> > Are you saying that at B, when bar is branched from foo, git discards
>>> > all information about this branching, remembering only that there are two
>>> > branches which are henceforth of fully equal status where before there
>>> > was just one?
>>
>>> Again, the branch diagram tells you nothing about the sequence of
>>> events.
>>
>> It must do.  D is based on C is based on B, and F is based on E is based
>> ob B, which in its turn is based on A.  Commit D thus happened after C,
>> etc.  We have a partial ordering, not a total ordering though.
>
> When that graph was constructed the objects must have been available in
> that order.  That doesn't mean they would have had to be created that
> way.

The parent commit ids are one of the things hashed into a child commit
id, so in that sense there is an commit creation partial ordering.
Branches aren't part of commits, however.

-- 
David Kastrup

Re: Obscure error/warning/information message from git pull

[Sergey Organov]

Achim Gratz <Stromeko@nexgo.de> writes:


[...]

> No, but there are multiple DAG, at least one in each of the existing
> repos.

I rather prefer to think about it as one global DAG, possibly different
parts of which exist in different repos. IMHO, it's less confusing this
way.

[One minor thing that I think was missed in original Git design is
universal null-commit, ultimately reachable from any commit in the
world. This way, DAGs for even currently unrelated projects would be
parts of the whole single DAG, that in turn would make some current
corner cases non-issue. ]

-- 
Sergey.

Re: Obscure error/warning/information message from git pull

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: Sergey Organov <sorganov@gmail.com>,
>     emacs-devel@gnu.org
> Date: Wed, 19 Nov 2014 07:59:44 +0900
> 
> Eli Zaretskii writes:
> 
>  > > Git itself has no "branches" that are "active lines of development"
>  > > in its data model.
>  > 
>  > Git might not have it, but we its users do.
> 
> True, but in practice there are *no* VCSes that have "active lines of
> development".

I believe you.  But humans certainly do have that notion, at least
some people sometimes do.

Re: Obscure error/warning/information message from git pull

[Eli Zaretskii]

> Date: Wed, 19 Nov 2014 08:12:38 +0700
> From: Yuri Khan <yuri.v.khan@gmail.com>
> Cc: Sergey Organov <sorganov@gmail.com>, Emacs developers <emacs-devel@gnu.org>
> 
> On Wed, Nov 19, 2014 at 4:43 AM, Alan Mackenzie <acm@muc.de> wrote:
> >
> >> Well, given the following history (time goes from left to right):
> >
> >>              - C - D <- foo
> >>            /
> >> ... - A - B
> >>            \
> >>              - E - F <- bar
> >
> >
> >> what branch commit A was made on, 'foo' or 'bar'?
> >
> > Quite clearly, A was committed on branch foo, since bar didn't exist at
> > that time.
> 
> But git does not know that. For all it knows, bar could be the
> original branch and foo branched from it at B. The history above is
> symmetrical.

Bringing DAG rewriting into the picture doesn't help a bit in this
already messy discussion.  Nothing like that happened in Alan's case,
and the chances of its happening in the Emacs repo are slim at best.

Re: Obscure error/warning/information message from git pull

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Wed, 19 Nov 2014 11:08:05 +0100
> 
> >> Earlier VCS often had more reified branches. A phrase that crops up a
> >> lot in git descriptions is "lightweight branching". This was achieved
> >> by paring back the branch concept - leaving nothing more than the nodes
> >> reachable from a named ref - and by making ref manipulation very common.
> >> 
> >> When contrasting git to earlier VCS in none of the git intros I have
> >> read have I seen that particular point made.
> >
> > You are again talking about differences in implementation.  "Branch"
> > the concept does not change a bit, no matter what VCS are you using.
> 
> When "Branch the concept" leads you to conclude "this can't happen" for
> things that clearly can

It doesn't.

> Reflogs contain the _actual_ history.

I don't know whatever gave you the idea I was talking about anything
like that.  I wasn't.

Re: Obscure error/warning/information message from git pull

[Eli Zaretskii]

> From: Achim Gratz <Stromeko@nexgo.de>
> Date: Wed, 19 Nov 2014 13:14:40 +0100
> 
> Branch foo consists of a label pointing at commit D and everything
> reachable from D is on that branch.

Now we are finally getting somewhere!  Others claimed that a branch
_is_ just its label, and nothing else.

Re: Obscure error/warning/information message from git pull

[Sergey Organov]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Achim Gratz <Stromeko@nexgo.de>
>> Date: Wed, 19 Nov 2014 13:14:40 +0100
>> 
>> Branch foo consists of a label pointing at commit D and everything
>> reachable from D is on that branch.
>
> Now we are finally getting somewhere!  Others claimed that a branch
> _is_ just its label, and nothing else.

Branch /in Git/ is just a special kind of label, and nothing else. The
above is an abstraction built on top of Git's idea of branch. One can
get a chain of commits from Git DAG starting at branch 'foo' and call
the result "branch foo", if it suits him. Moreover, he can do this from
any reference, even from SHA1. If I get the same chain of commits from
branch 'foo' and from commit AF03276BC, is it the same branch? Is SHA1 a
branch? Is Git tag a branch? Why?

-- 
Sergey.

Re: Obscure error/warning/information message from git pull

[Sergey Organov]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Wed, 19 Nov 2014 08:12:38 +0700
>> From: Yuri Khan <yuri.v.khan@gmail.com>
>> Cc: Sergey Organov <sorganov@gmail.com>, Emacs developers <emacs-devel@gnu.org>
>> 
>> On Wed, Nov 19, 2014 at 4:43 AM, Alan Mackenzie <acm@muc.de> wrote:
>> >
>> >> Well, given the following history (time goes from left to right):
>> >
>> >>              - C - D <- foo
>> >>            /
>> >> ... - A - B
>> >>            \
>> >>              - E - F <- bar
>> >
>> >
>> >> what branch commit A was made on, 'foo' or 'bar'?
>> >
>> > Quite clearly, A was committed on branch foo, since bar didn't exist at
>> > that time.
>> 
>> But git does not know that. For all it knows, bar could be the
>> original branch and foo branched from it at B. The history above is
>> symmetrical.
>
> Bringing DAG rewriting into the picture doesn't help a bit in this
> already messy discussion.  Nothing like that happened in Alan's case,
> and the chances of its happening in the Emacs repo are slim at best.

You still don't get it. No DAG rewriting and we still get to this
history while A was made on "branch bar", see my other post.

-- 
Sergey.

Re: Obscure error/warning/information message from git pull

[Stephen J. Turnbull]

Alan Mackenzie writes:

 > > >>              - C - D <- foo
 > > >>            / 
 > > >> ... - A - B
 > > >>            \
 > > >>              - E - F <- bar

 > OK, commit A might have been made on some other branch not in the
 > diagram.  But commit A was made before commit B (that is what these
 > lines _mean_)

Yes.

 > and commit B was made before branch bar was created (and possibly
 > before branch foo if that was branched of of B also, rather than
 > being the continuation of the branch A was made on).

You can't tell that from the diagram though.  While the DAG gives you
information about the (partial) order of commits, it tells you nothing
about what branches existed at any given point of time except NOW, or
where the commits were actually created.  For example, starting on
trunk, you can

    bzr commit -m A       # all commits are preceded by hacking
    cd ..
    bzr branch trunk foo
    bzr branch foo bar
    cd trunk
    bzr commit -m B       # trunk and foo have diverged
    cd ../bar
    bzr pull ../trunk     # bar and foo have diverged
                          # at this point we must have 3 branches
                          # since bar did not branch from trunk
    bzr commit -m E
    bzr commit -m F
    cd ../foo
    bzr pull ../trunk     # trunk and foo have reconverged
    bzr commit -m C       # trunk and foo have diverged
    bzr commit -m D

I have no idea how you propose to interpret that consistently with
your claims about knowing where and when a branch was created, or what
commits are on which branch, apart from reachability.

 > The very essence of a branch is its creation on the trunk (or other
 > branch) and divergence from it.  Its point of creation is essential
 > - without it, it isn't a branch at all.

Uh, if it's not a branch, what in the world is it?

 > It seems git simply discards this information.

Yes.  AFAICS it's not terribly useful.  I used to use a tag in CVS,
and that could be done in git, too:

    # echo 'git tag $1-bp-`date +%Y%m%d%H%M%S` > /usr/local/bin/git-makenode
    # echo 'git branch $1 $2' >> /usr/local/bin/git-makenode
    # chmod 0755 /usr/local/bin/git-makenode

but I find git's ".." notation gives me everything I want.

 > That is where git's abstraction is broken.  A is reachable from branch
 > bar, yet isn't on it and never has been - it's on the trunk, (or maybe
 > branch foo).

Actually, I think *your* abstraction is incompatible with all DVCSes.
All support a mode of operation where repo == branch == workspace.
Now, suppose I have a branch foo, and from its parent directory I do
"$VCS clone foo bar".  Nobody (with the possible exception of you)
would say that bar is an empty branch, and that directory bar contains
branch foo.

 > The practical outcome is that git doesn't keep track of your branches.
 > You've got to remember your branching structure (or write it on a piece
 > of paper) if you ever want, say, to get a list of changes made on branch
 > bar.

Most of the time this is trivial.  "git log master..bar".  But I don't
understand why you care *where* the changes were made.  I always am
looking for a set of commits that represent the changes by which two
revisions or branches differ; I don't care that C is a branch of B
which branched from A, I just care about A and C (and want to know
what happened on B as well as C since "our" branches forked from A).

 > I think that is what the "..." in "master...bar" is all about.

You want ".." here.  "..." gives the changes on *both* branches since
the fork.  Note that a VCS that knows about branches is no help if you
want "bar..master" or "bar...master": master goes all the way back to
root!  Whose abstraction is broken here?

Re: Obscure error/warning/information message from git pull

[Stephen J. Turnbull]

Eli Zaretskii writes:
 > > From: "Stephen J. Turnbull" <stephen@xemacs.org>

 > > True, but in practice there are *no* VCSes that have "active lines of
 > > development".
 > 
 > I believe you.  But humans certainly do have that notion, at least
 > some people sometimes do.

Yes, but what's your difficulty with git branches, then?  Just say no
to "branch ref is a whole branch".  As Achim already wrote, a branch
is a branch ref plus what's reachable from that ref by following the
ref and commit parents.

Re: Obscure error/warning/information message from git pull

[Yuri Khan]

On Wed, Nov 19, 2014 at 10:18 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> Bringing DAG rewriting into the picture doesn't help a bit in this
> already messy discussion.  Nothing like that happened in Alan's case,
> and the chances of its happening in the Emacs repo are slim at best.

There is no rewriting in my example which you snipped, either. Branch
heads are explicitly not part of history.

Re: Obscure error/warning/information message from git pull

[Teemu Likonen]

[-- Attachment #1: Type: text/plain, Size: 693 bytes --]

Eli Zaretskii [2014-11-19 18:20:43 +02:00] wrote:

>> Branch foo consists of a label pointing at commit D and everything
>> reachable from D is on that branch.
>
> Now we are finally getting somewhere! Others claimed that a branch
> _is_ just its label, and nothing else.

I don't know anymore if this is some academic concept talk or concrete
talk but this helped me a few years ago:

    $ ls -l .git/refs/heads/
    -rw-r--r-- 1 dtw dtw 41 2014-11-19 19:23 emacs-24
    -rw-r--r-- 1 dtw dtw 41 2014-11-16 21:16 master

    $ cat .git/refs/heads/master 
    7261b4d9b2f35c3e520b488a8ba3cfde30f84a24

That's what branches are in Git. But maybe you are upto something else.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 835 bytes --]

Re: Obscure error/warning/information message from git pull

[Stephen J. Turnbull]

Sergey Organov writes:

 > Branch /in Git/ is just a special kind of label, and nothing else.

Those labels are /branch refs/.

 > The above is an abstraction built on top of Git's idea of
 > branch. One can get a chain of commits from Git DAG starting at
 > branch 'foo' and call the result "branch foo", if it suits
 > him.

And that's precisely what everyone does, IME.  In particular, "git
help branch" clearly presupposes that notion of "branch" throughout.
All DAGgy operations on branches operate on that chain of commits.
There are operations on the ref itself (create, move, delete, parse),
but those are not considered to be operations on the branch by me or
anyone I know.

 > Moreover, he can do this from any reference, even from
 > SHA1. If I get the same chain of commits from branch 'foo' and from
 > commit AF03276BC, is it the same branch? Is SHA1 a branch? Is Git
 > tag a branch? Why?

Maybe, no, and no.  Sometimes a chain of commits including the tip
commit is called a branch, but that's synecdoche (an expression where
a part is used to stand for the whole).  And of course it's possible
to create a branch that does not contain a tip commit (ie, a childless
commit), by branching off a non-tip commit (of course once you commit
to that branch, it will have a tip commit).  So properly speaking a
branch must contain both a chain of commits *and* a head which will
become the parent of the next commit to that branch.

SHA1 and tag clearly aren't branches because if checked out they
become detached heads, and if a commit is performed in that state, a
commit object is created and HEAD is updated to point to the new
commit, but the SHA1 and the tag are not updated.

Re: Obscure error/warning/information message from git pull

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: sorganov@gmail.com,
>     emacs-devel@gnu.org
> Date: Thu, 20 Nov 2014 01:48:46 +0900
> 
> Eli Zaretskii writes:
>  > > From: "Stephen J. Turnbull" <stephen@xemacs.org>
> 
>  > > True, but in practice there are *no* VCSes that have "active lines of
>  > > development".
>  > 
>  > I believe you.  But humans certainly do have that notion, at least
>  > some people sometimes do.
> 
> Yes, but what's your difficulty with git branches, then?

None I know of.  I don't have any trouble translating from my notions
and concepts to Git implementations and vice versa.  But I understand
why it could be difficult at first.

> Just say no to "branch ref is a whole branch".  As Achim already
> wrote, a branch is a branch ref plus what's reachable from that ref
> by following the ref and commit parents.

With that I fully agree, of course.

Re: Obscure error/warning/information message from git pull

[Eli Zaretskii]

> From: Sergey Organov <sorganov@gmail.com>
> Date: Wed, 19 Nov 2014 19:36:20 +0300
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Achim Gratz <Stromeko@nexgo.de>
> >> Date: Wed, 19 Nov 2014 13:14:40 +0100
> >> 
> >> Branch foo consists of a label pointing at commit D and everything
> >> reachable from D is on that branch.
> >
> > Now we are finally getting somewhere!  Others claimed that a branch
> > _is_ just its label, and nothing else.
> 
> Branch /in Git/ is just a special kind of label, and nothing else.

Well, now it's not only me you are up against ;-)

> The above is an abstraction built on top of Git's idea of
> branch. One can get a chain of commits from Git DAG starting at
> branch 'foo' and call the result "branch foo", if it suits
> him. Moreover, he can do this from any reference, even from SHA1. If
> I get the same chain of commits from branch 'foo' and from commit
> AF03276BC, is it the same branch? Is SHA1 a branch? Is Git tag a
> branch? Why?

As I already said elsewhere, you seem to have a serious problem
distinguishing the name of a thing from the thing itself.

But we are repeating ourselves.  It's time to stop.

Re: Obscure error/warning/information message from git pull

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Sergey Organov <sorganov@gmail.com>
>
>> The above is an abstraction built on top of Git's idea of
>> branch. One can get a chain of commits from Git DAG starting at
>> branch 'foo' and call the result "branch foo", if it suits
>> him. Moreover, he can do this from any reference, even from SHA1. If
>> I get the same chain of commits from branch 'foo' and from commit
>> AF03276BC, is it the same branch? Is SHA1 a branch? Is Git tag a
>> branch? Why?
>
> As I already said elsewhere, you seem to have a serious problem
> distinguishing the name of a thing from the thing itself.

You'll find that you can delete a branch, and not more than its name
will disappear.  If you _afterwards_ make another branch tip refer to
the same commit id that the old branch tip had, that branch will work
perfectly well.

So did I delete the branch or not?  What branch were the commits on
after the old branch was deleted and before the new one was created?

I can also do something like

git branch woozle hephalump

and create a branch woozle which is, for all intents and purposes,
equivalent to the branch hephalump.  But no commits were created in the
process of creating this new branch.  So what branch are the shared
commits on now if they have to be "on a branch"?

Branches are ephemeral, the commit graph is static.  Equating the two
will not do your understanding favors.

-- 
David Kastrup

Re: Obscure error/warning/information message from git pull

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Wed, 19 Nov 2014 21:05:39 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Sergey Organov <sorganov@gmail.com>
> >
> >> The above is an abstraction built on top of Git's idea of
> >> branch. One can get a chain of commits from Git DAG starting at
> >> branch 'foo' and call the result "branch foo", if it suits
> >> him. Moreover, he can do this from any reference, even from SHA1. If
> >> I get the same chain of commits from branch 'foo' and from commit
> >> AF03276BC, is it the same branch? Is SHA1 a branch? Is Git tag a
> >> branch? Why?
> >
> > As I already said elsewhere, you seem to have a serious problem
> > distinguishing the name of a thing from the thing itself.
> 
> You'll find that you can delete a branch, and not more than its name
> will disappear.  If you _afterwards_ make another branch tip refer to
> the same commit id that the old branch tip had, that branch will work
> perfectly well.
> 
> So did I delete the branch or not?

You didn't.  You deleted its name.

> What branch were the commits on after the old branch was deleted and
> before the new one was created?

Same one.  The branch wasn't deleted.

> I can also do something like
> 
> git branch woozle hephalump
> 
> and create a branch woozle which is, for all intents and purposes,
> equivalent to the branch hephalump.

A thing can have more than one name.

> But no commits were created in the process of creating this new
> branch.

You didn't create a branch, you added another name for an existing
branch.

> So what branch are the shared commits on now if they have to be "on
> a branch"?

You now have a branch with 2 names, that's all.

> Branches are ephemeral, the commit graph is static.  Equating the two
> will not do your understanding favors.

Didn't expect to hear this from you.  Others, yes, but not you.

Re: Obscure error/warning/information message from git pull

[Alexis]

Alan Mackenzie writes:

> The very essence of a branch is its creation on the trunk (or other
> branch) and divergence from it.  Its point of creation is essential -
> without it, it isn't a branch at all.  It seems git simply discards
> this information.

Well, here's a scenario to consider, again using the example from upthread:

              - C - D <- foo
            / 
... - A - B
            \
              - E - F <- bar

Let's say

... - A - B

is an exploratory feature branch called 'experiment'. After commit B,
the group working on this branch split into two camps as to how next to
proceed. So they decided to create two branches, 'foo' and 'bar', off
'experiment', to apply the two camps' respective approaches and see what
problems and solutions result.

At this point, neither 'foo' nor 'bar' are /the/ 'official' continuation
of 'experiment'. From a workflow perspective, they have equal authority
- any linear ordering imposed by when the branches got created is
irrelevant. Yes, at a later time, it might be decided that the 'bar'
branch becomes the 'official' continuation of the 'experiment' branch,
i.e. the structure would become:

              - C - D ... Z <- foo
            /   
... - A - B - E - F ... <- bar

But until that time, it makes no sense to speak of either the 'foo'
branch or 'bar' branch as /the/ continuation of the 'experiment' branch.


Alexis.

Re: Obscure error/warning/information message from git pull

[Rob Browning]

Florian Weimer <fw@deneb.enyo.de> writes:

> Git does not record the branch on which a commit was made.  It's
> sometimes recorded in merges, but only in the free-text commit
> message.  For fast-forward merges (without a separate merge commit),
> there is no trace that development of certain commits happened on a
> separate branch.

And as an aside, it can sometimes be useful to preserve the information
that "these commits go together", even when git could just tack the
commits on to the end of the branch (which it will, when possible, by
default, i.e. a fast-forward merge).  To prevent that you can specify
"merge --no-ff", which will force git to create a merge commit.

So you'd end up with something like this (on, say master):

   * merge commit to add new thing (master)
   |\
   | * third bit of thing
   | |
   | * second bit of thing
   | |
   | * first bit of thing
   |/
   * last commit on master before merging new thing with --no-ff
   |

instead of this (without --no-ff):

   * third bit of thing (master)
   |
   * second bit of thing
   |
   * first bit of thing
   |
   * last commit on master before merging new thing with --no-ff
   |

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Re: Obscure error/warning/information message from git pull

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > > Branches are ephemeral, the commit graph is static.  Equating the two
 > > will not do your understanding favors.
 > 
 > Didn't expect to hear this from you.  Others, yes, but not you.

David tends to be overly emphatic.

In this thread AIUI we're trying to help existing Emacs developers who
find git to be new and confusing.  Eli is proposing that *they* adopt
the abstraction of "branch" as being

    a structure defined by transitive closure of the parent relation
    that "really exists" in the DAG, *with* a "branch ref" as a
    (possibly mutable) name that is an *essential* "handle" to the
    branch for operations such as commit and merge.

I think it's reasonable to say that for the purposes of these
developers, that is useful and unlikely to cause them any harm.

During the transition period (broadly speaking; I wouldn't be
surprised if people are still digging patches out of dormant bzr
branches in late 2016!), it is highly unlikely that they will
encounter any behaviors in the public Emacs repos (renamed branches,
branches that have a social identity with a different extent from
master..branch in the DAG, etc) that violate the "branch ref +
reachable commits" model.  This isn't as restrictive a model as the
one Alan Mackenzie has in mind, with branch as an actual queryable
object with persistent identity and metadata.  The branch-is-object
model is clearly wrong in git.

In other words, branches are implemented in a way that makes them
ephemeral in principle, but you won't need to notice that in Emacs
practice (and Eli advocates ignoring that fact).

On the other hand, the ephemerality of branches is one of the
principal sources of power in git.  I agree entirely with David that
confusing the DAG of commits with a collection of branches means you
lose a lot of the benefits of git, and makes it very hard to use git
as effectively as you used branch-oriented VCSes.

Re: Obscure error/warning/information message from git pull

[Eli Zaretskii]

> From: Alexis <flexibeast@gmail.com>
> Date: Thu, 20 Nov 2014 11:57:15 +1100
> 
> At this point, neither 'foo' nor 'bar' are /the/ 'official' continuation
> of 'experiment'. From a workflow perspective, they have equal authority
> - any linear ordering imposed by when the branches got created is
> irrelevant. Yes, at a later time, it might be decided that the 'bar'
> branch becomes the 'official' continuation of the 'experiment' branch,
> i.e. the structure would become:
> 
>               - C - D ... Z <- foo
>             /   
> ... - A - B - E - F ... <- bar
> 
> But until that time, it makes no sense to speak of either the 'foo'
> branch or 'bar' branch as /the/ continuation of the 'experiment' branch.

They both are.

Re: Obscure error/warning/information message from git pull

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: David Kastrup <dak@gnu.org>,
>     emacs-devel@gnu.org
> Date: Thu, 20 Nov 2014 12:01:25 +0900
> 
> I agree entirely with David that confusing the DAG of commits with a
> collection of branches means you lose a lot of the benefits of git,
> and makes it very hard to use git as effectively as you used
> branch-oriented VCSes.

I agree.  A branch is some path through the DAG, but a DAG is not a
collection of branches.