From: Junio C Hamano <hidden> Date: 2016-06-15 22:57:24
Andreas Krey [off-list ref] writes:
A short trial showed that representing first parent chains as
straight lines in the graph does actually improve understandability,
as feature branches clearly stand out as separate lines even when
they no longer carry a branch name.
If you have a four-commit segment in your commit ancestry graph
(time flows from left to right; turn your head 90-degrees to the
right if you want a gitk representation):
---A--X
\/
/\
---B--Y
where X and Y are both merges between A and B, having A as their
first parent, how would you express such a graph with first-parent
chain going a straight line?
Also, there is an implication with 'git pull': You'd expect the
master branch to be a first parent line, but when I do a small
thing directly on master and need to pull before pushing back,
then origin/master is merged into my branch, and thus my side
branch becomes the first parent line.
From: Andreas Krey <hidden> Date: 2016-06-15 22:57:25
On Wed, 22 May 2013 11:07:07 +0000, Junio C Hamano wrote:
...
If you have a four-commit segment in your commit ancestry graph
I never had yet. :-(
(time flows from left to right; turn your head 90-degrees to the
right if you want a gitk representation):
---A--X
\/
/\
---B--Y
where X and Y are both merges between A and B, having A as their
first parent, how would you express such a graph with first-parent
chain going a straight line?
Of course there are multiple possible straight lines and how it looks
depends on the order I use the existing heads to fish them out. (That
is, when the straight lines join, I need to bend one of them.) Assuming
I take the one where X is on, I expect a look like
-----A-------X-----
\ |
+- Y--------
| |
-----B----+--+
Branch heads that are reachable from other head are picked after those
that aren't reachable.
The point is to get the feature branches being displayed on separate
lanes (and thus visibly sticking out) and not being intermingled with
the longer-living branches.
...
Don't do that, then.
:-) Problem is, in this case 'I' expands to about
1<<7 people I need to educate on this.
Andreas
--
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800
From: Jeremy Rosen <hidden> Date: 2016-06-15 22:57:25
----- Mail original -----
On Thu, May 23, 2013 at 5:06 AM, Andreas Krey [off-list ref] wrote:
[snip]
quoted
...
quoted
Don't do that, then.
:-) Problem is, in this case 'I' expands to about
1<<7 people I need to educate on this.
This is a feature of `git pull` that I really despise. I really wish
`git pull` treated the remote as the first parent in its merge
operation.
seconded...
github's network pages (which display the commit graph of projects) seems to follow the "first parent at the top" rule and the pull merges are standing out as "wrong" because of that...
From: Andreas Krey <hidden> Date: 2016-06-15 22:57:25
On Thu, 23 May 2013 05:48:38 +0000, John Szakmeister wrote:
...
This is a feature of `git pull` that I really despise. I really wish
`git pull` treated the remote as the first parent in its merge
operation.
I'd actually only like it that way when pulling from
the tracking branch, not for any pull.
Andreas
--
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800
From: John Keeping <hidden> Date: 2016-06-15 22:57:25
On Thu, May 23, 2013 at 12:29:59PM +0200, Andreas Krey wrote:
On Thu, 23 May 2013 05:48:38 +0000, John Szakmeister wrote:
...
quoted
This is a feature of `git pull` that I really despise. I really wish
`git pull` treated the remote as the first parent in its merge
operation.
I'd actually only like it that way when pulling from
the tracking branch, not for any pull.
I'll add my voice to the "annoyed by this" pile ;-)
I've been annoyed by this at $DAYJOB recently. A lot of people seem to
blindly "git pull" without much thought about how the history is ending
up and what they actually want to do.
I wonder if it would make sense for "git pull" (with no arguments) to
pass "--ff-only" to git-merge, allowing this to be overridden with
--rebase and --merge (which doesn't currently exist). With some
suitable advice output we could hopefully educate users about how to
shape their history.
From: Andreas Krey <hidden> Date: 2016-06-15 22:57:25
On Thu, 23 May 2013 11:06:57 +0000, Andreas Krey wrote:
...
...
quoted
Don't do that, then.
Ouch, you're right. The problem is not actually in the
pull; only the *last* pull into a feature branch that
then get pushed back ff to master needs to be reversed.
And at that time you don't know it's the last one
-> swap parents before the push if necessary.
Andreas
--
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800
On Thu, 23 May 2013 11:06:57 +0000, Andreas Krey wrote:
...
quoted
...
quoted
Don't do that, then.
Ouch, you're right. The problem is not actually in the
pull; only the *last* pull into a feature branch that
then get pushed back ff to master needs to be reversed.
And at that time you don't know it's the last one
-> swap parents before the push if necessary.
if you have to be so careful to ensure the correct ordering of parents
it almost defeats the initial objective to make commit graphs in gitk
look nice without re-educating/restricting other users. A solution that
works for everyone should work without users having to think about it.
Here is an idea (probably already discussed in the long history of git):
1) the branch name is recorded in a commit (for merges the branch that
is updated)
2) unique identifier of repository is recorded in commit (optional)
3) simple configurable ordering and/or coloring scheme in gitk based on
committer,branch name and repo (with wildcards).
With this users could pull and push as often as they like, the main
branches would always be ordered and straight lines. If instead you
already do the work to keep your history clean you could just use the
coloring scheme and see committers color coded in gitk. Further benefit:
the history of really old commits could be more easily remembered if you
knew in what branch they originated
Is this a bad idea or just no one did it yet?
From: Andreas Krey <hidden> Date: 2016-06-15 22:57:25
On Fri, 24 May 2013 11:29:00 +0000, Holger Hellmuth (IKS) wrote:
...
Here is an idea (probably already discussed in the long history of git):
1) the branch name is recorded in a commit (for merges the branch that
is updated)
The branch name is almost completely meaningless. I could just
do my feature in my local master and never have a different name.
Or commit something onto tmp that I then fast-forward into my
(properly named) feature branch.
2) unique identifier of repository is recorded in commit (optional)
That is pure noise (in my workflow).
3) simple configurable ordering and/or coloring scheme in gitk based on
committer,branch name and repo (with wildcards).
Ok, gitk could use some features. :-)
...
Is this a bad idea or just no one did it yet?
Possibly not bad (hg does parts of it), but un-git-ish?
(I'm not sure that it was *intended* that the parents
of a merge commit have an order, except that they need
to for deterministic hashes.)
Andreas
--
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800
On Fri, 24 May 2013 11:29:00 +0000, Holger Hellmuth (IKS) wrote:
...
quoted
Here is an idea (probably already discussed in the long history of git):
1) the branch name is recorded in a commit (for merges the branch that
is updated)
The branch name is almost completely meaningless. I could just
do my feature in my local master and never have a different name.
In which case parent switching in the commit wouldn't help you either.
But even you could keep your master always on the left side of gitk if
you deem it special. And you could keep longer running cooperative
branches (the main develop and the release branch of your project for
example) in a seperate lane.
Depending on your use of branches many branches won't get any ordering,
but at a minimum important branches can easily be "highlighted".
Or commit something onto tmp that I then fast-forward into my
(properly named) feature branch.
Yes, but then you would see a feature branch in its expected column in
gitk and you would also see (even years later) that it didn't start as a
feature but later was made into one. Cues like this help to remember
what happened even if you forgot to mention them in the commit message
quoted
2) unique identifier of repository is recorded in commit (optional)
That is pure noise (in my workflow).
It is important to differentiate between branches of the same name in
different repositories. For example if your project has a central
repository with master getting all the release stuff you want to sort
that master differently than your own master.
The unique identifier might be just a random number or string created at
init time of the repo.
quoted
3) simple configurable ordering and/or coloring scheme in gitk based on
committer,branch name and repo (with wildcards).
Ok, gitk could use some features. :-)
Without additional information about the commit history gitk can do
exactly what it does now.
...
quoted
Is this a bad idea or just no one did it yet?
Possibly not bad (hg does parts of it), but un-git-ish?
Don't know. No CVS does branches as good as git. But then it drops that
information which depending on development style could be useful or not.
Not that useful for people who keep their history clean, a lot for
people who don't.
From: Andreas Krey <hidden> Date: 2016-06-15 22:57:26
On Fri, 24 May 2013 17:05:26 +0000, Holger Hellmuth (IKS) wrote:
Am 24.05.2013 15:42, schrieb Andreas Krey:
...
quoted
The branch name is almost completely meaningless. I could just
do my feature in my local master and never have a different name.
In which case parent switching in the commit wouldn't help you either.
Oh, it does; I tried. Names are meaningless, the parent ordering
isn't. ( [And at least, it's already in there.]
But even you could keep your master always on the left side of gitk if
you deem it special. And you could keep longer running cooperative
branches (the main develop and the release branch of your project for
example) in a seperate lane.
I need gitk (or similar) to do it. Will take some time to understand
the code (and triggers the 'I can write it (the interesting part) faster
than I can grok gitk').
...
Without additional information about the commit history gitk can do
exactly what it does now.
Most definitely not. There are quite some situations where the graph
deteriorates pretty heavily, even when not expecting it to pay attention
to first parent. When you have two branches, of which one regularly
gets merge into the other, it sometimes manages to display first the
one, then the other branch, with a log of merge edges going upwards
in parallel, for example.
Andreas
--
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800