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 d...@gnu.org wrote: Vincent van Ravesteijn v...@lyx.org 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 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 d...@gnu.org wrote:
Vincent van Ravesteijn v...@lyx.org 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
On 7 February 2014 18:26, Duy Nguyen pclo...@gmail.com 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
Confusing git log --- First time bug submission please advise on best practices
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 John Doe (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 Jeremy Doe (27 hours ago) 239ea21 (my-work) renamed class Jeremy Doe (28 hours ago) 27750b2 Merge branch 'master' of http://githost.companyname-dev.local/trading-development/sports-container-framework and Jeremy Doe (2 days ago) a933acb white space changes Jeremy Doe (2 days ago) b5e51e7 Merge branch 'master' of http://githost.companyname-dev.local/trading-development/sports-container-framework Jeremy Doe (2 days ago) 3a0f787 removed public methods Jeremy Doe (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. Technical details: He is using the Windows git client version 1.8.5.2.msysgit.0 Running on Windows 7 Every command was run through git bash Background: He previously had tortoise-git installed, but I had him uninstall it to solve some ssh problems While uninstalling tortoise-git we also reinstalled git - I don't know what the previous version of git was. Output of git branch -avv * master 6833fd4 Completed merge my-work 239ea21 renamed class remotes/origin/HEAD - origin/master remotes/origin/masterf269789 Cleaning up GIT step 1 remotes/originssh/master d85832d More pom fixes The background on the originssh remote branch is that his origin uses an HTTP url which wasn't allowing him to push a large commit. I helped him to create originssh to allow the push to be made. master Description: Binary data originssh_master Description: Binary data
Re: Confusing git log --- First time bug submission please advise on best practices
On Thu, Feb 6, 2014 at 3:02 PM, Francis Stephens francissteph...@gmail.com 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 John Doe (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 Jeremy Doe (27 hours ago) 239ea21 (my-work) renamed class Jeremy Doe (28 hours ago) 27750b2 Merge branch 'master' of http://githost.companyname-dev.local/trading-development/sports-container-framework and Jeremy Doe (2 days ago) a933acb white space changes Jeremy Doe (2 days ago) b5e51e7 Merge branch 'master' of http://githost.companyname-dev.local/trading-development/sports-container-framework Jeremy Doe (2 days ago) 3a0f787 removed public methods Jeremy Doe (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
Re: Confusing git log --- First time bug submission please advise on best practices
Vincent van Ravesteijn v...@lyx.org 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
