Re: Confusing git log --- First time bug submission please advise on best practices
On 7 February 2014 18:26, Duy Nguyen wrote: > On Fri, Feb 07, 2014 at 09:43:46AM +, Francis Stephens wrote: >> Thanks for your clear response. I can see where I went wrong now. > > Maybe something like this would help avoid confusion a bit in the > future? This toy patch puts a horizontal line as a break between two > commits if they are not related, so we can clearly see linear commit > segments. FWIW, this would have saved a lot of head scratching at work over the years. I'd love to see this in place. Yves -- perl -Mre=debug -e "/just|another|perl|hacker/" -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Confusing git log --- First time bug submission please advise on best practices
On Fri, Feb 07, 2014 at 09:43:46AM +, Francis Stephens wrote:
> Thanks for your clear response. I can see where I went wrong now.
Maybe something like this would help avoid confusion a bit in the
future? This toy patch puts a horizontal line as a break between two
commits if they are not related, so we can clearly see linear commit
segments.
--graph definitely helps, but it's too many threads for topic-based
development model like git.git that I avoid it most of the time.
-- 8< --
diff --git a/log-tree.c b/log-tree.c
index 08970bf..7841bf2 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -795,6 +795,7 @@ static int log_tree_diff(struct rev_info *opt, struct
commit *commit, struct log
int log_tree_commit(struct rev_info *opt, struct commit *commit)
{
+ static struct commit_list *last_parents;
struct log_info log;
int shown;
@@ -805,6 +806,17 @@ int log_tree_commit(struct rev_info *opt, struct commit
*commit)
if (opt->line_level_traverse)
return line_log_print(opt, commit);
+ if (last_parents) {
+ struct commit_list *p = last_parents;
+ int got_parent = 0;
+ for (; p && !got_parent; p = p->next)
+ got_parent = !hashcmp(p->item->object.sha1,
+ commit->object.sha1);
+ if (!got_parent)
+
printf("__\n");
+ free_commit_list(last_parents);
+ last_parents = NULL;
+ }
shown = log_tree_diff(opt, commit, &log);
if (!shown && opt->loginfo && opt->always_show_header) {
log.parent = NULL;
@@ -813,5 +825,6 @@ int log_tree_commit(struct rev_info *opt, struct commit
*commit)
}
opt->loginfo = NULL;
maybe_flush_or_die(stdout, "stdout");
+ last_parents = copy_commit_list(commit->parents);
return shown;
}
-- 8< --
>
> On Thu, Feb 6, 2014 at 4:10 PM, David Kastrup wrote:
> > Vincent van Ravesteijn writes:
> >
> >> The commits that are in the log for master and which are not in the
> >> log for originssh/master are merged in at "6833fd4 (HEAD, master);
> >> Completed merge".
> >>
> >> As "git log" can only present the commits in a linear way, it shows
> >> the commits from the ancentry of both parents of HEAD in a reverse
> >> chronological order. This means that the commits from the two
> >> ancestries are mixed and commits that are shown after each other don't
> >> have to be parent and child. See the documentation of "git log" and
> >> the section "Commit Ordering": "By default, the commits are shown in
> >> reverse chronological order."
> >
> > git log --graph can help with getting a better picture.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Confusing git log --- First time bug submission please advise on best practices
Thanks for your clear response. I can see where I went wrong now. On Thu, Feb 6, 2014 at 4:10 PM, David Kastrup wrote: > Vincent van Ravesteijn writes: > >> The commits that are in the log for master and which are not in the >> log for originssh/master are merged in at "6833fd4 (HEAD, master); >> Completed merge". >> >> As "git log" can only present the commits in a linear way, it shows >> the commits from the ancentry of both parents of HEAD in a reverse >> chronological order. This means that the commits from the two >> ancestries are mixed and commits that are shown after each other don't >> have to be parent and child. See the documentation of "git log" and >> the section "Commit Ordering": "By default, the commits are shown in >> reverse chronological order." > > git log --graph can help with getting a better picture. > > -- > David Kastrup -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Confusing git log --- First time bug submission please advise on best practices
Vincent van Ravesteijn writes: > The commits that are in the log for master and which are not in the > log for originssh/master are merged in at "6833fd4 (HEAD, master); > Completed merge". > > As "git log" can only present the commits in a linear way, it shows > the commits from the ancentry of both parents of HEAD in a reverse > chronological order. This means that the commits from the two > ancestries are mixed and commits that are shown after each other don't > have to be parent and child. See the documentation of "git log" and > the section "Commit Ordering": "By default, the commits are shown in > reverse chronological order." git log --graph can help with getting a better picture. -- David Kastrup -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Confusing git log --- First time bug submission please advise on best practices
On Thu, Feb 6, 2014 at 3:02 PM, Francis Stephens wrote: > > My co-worker has an inconsistent git log output. Please see that > attached files for output (I've made a best effort to remove > confidential info from them). > > Comparing the two log commands we can see that master and > originssh/master have a shared common commit at > > (4 hours ago) d85832d > More pom fixes > > The top commit for originssh/master and the second to top for master. > > I would expect that both logs would share an _identical_ history from > that commit onward. But the log for master contains the following > > (27 hours ago) 239ea21 (my-work) > renamed class > > (28 hours ago) 27750b2 > Merge branch 'master' of > http://githost.companyname-dev.local/trading-development/sports-container-framework > > and > > (2 days ago) a933acb > white space changes > > (2 days ago) b5e51e7 > Merge branch 'master' of > http://githost.companyname-dev.local/trading-development/sports-container-framework > > (2 days ago) 3a0f787 > removed public methods > > (2 days ago) 4e91130 > added the xml deserialisation > > None of which appear in the originssh/master log. Is there a scenario > in which this is expected. It was my understanding that any two > commits with the same hash have exactly the same history. > > Thanks for your time. The commits that are in the log for master and which are not in the log for originssh/master are merged in at "6833fd4 (HEAD, master); Completed merge". As "git log" can only present the commits in a linear way, it shows the commits from the ancentry of both parents of HEAD in a reverse chronological order. This means that the commits from the two ancestries are mixed and commits that are shown after each other don't have to be parent and child. See the documentation of "git log" and the section "Commit Ordering": "By default, the commits are shown in reverse chronological order." Vincent -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
