[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Alan Mackenzie
Subject: Re: Obscure error/warning/information message from git pull
Date: Mon, 17 Nov 2014 14:11:23 +0000
User-agent: Mutt/1.5.21 (2010-09-15)

Hello, Sergey.

On Mon, Nov 17, 2014 at 02:54:06PM +0300, Sergey Organov wrote:
> Alan Mackenzie <address@hidden> 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,

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]