--animate log in chronological order of the commits #96
Comments
|
Thanks for creating this. Ok yes I'll think about the author date vs commit date as well. One other question - if commits are displayed chronologically, do you expect to see all commits displayed linearly (even if they If commits are purely chronological we may want to rethink how the arrows are draw, since by convention the arrows in the Git dag represent parent/child relationships and not time. Thoughts? |
if I got question right -- "in parallel" is the correct answer if it is how
it could retain that semantic no problem. Time would just define in which order commits with their arrows to parents would appear. IIRC ATM it goes backwards - from most recent commits to parents and so on, and I was thinking about from oldest to newer ones (arrows could still point to parents), and commits appearing in chronological order across branches. note 1: it would be nice if order (but not necessarily chronological distance) along "horizontal axes" across branches is preserved, i.e. later commit on branch Y comes after earlier commit on branch X note 2: Sure thing it could be that commits order in a branch would be incongruent with chronological order (clock could be changed backward so child commit is earlier than parent) -- then I guess it is up to decision on how to handle it ;) |
I think we are understanding each other, but just in case, here are the 2 ways I'm thinking we could do this:
For (2) I think we could start from the most recent commit timestamp and display commits one by one until we reach one with multiple parents. Then we can split the chain so it displays in parallel, and continue each chain using chronological ordering. Each time we find a commit with multiple parents, we split again the same way.
Even in Git's default log, I believe that if a child commit somehow has an earlier timestamp than its parent, it would display first in the log (by that I mean later if we're talking reverse-chronological order). So I think we could just match Git's default behavior and not handle this in a special way. |
It seems indeed the case unless I use this script which also collected time stamps per above hackery but with 1 sec sleep added#!/bin/bash
# https://github.com/datalad/datalad/issues/7371
#
# A helper
# with 1 sec delay
export PS4='> $(date "+%Y-%m-%d %H:%M:%S.%N"): $(sleep 1)';
log="$(mktemp /tmp/sim-XXXXXXX)"
exec 2> "$log"
set -x
bash -x "$@"
echo "Commands with time stamps collected in $log"
ran on this one#!/bin/bash
# https://github.com/datalad/datalad/issues/7371
#
# do not overload so we could use it outside
# export PS4='> '
# set -x
set -eu
umask 022
cd "$(mktemp -d /tmp/dl-XXXXXXX)"
mkdir remote
(
cd remote
git init
git annex init
)
# Let's slow down now and have it each 1 second
# export PS4='> $(sleep 1)'
mkdir origin
(
cd origin;
git init # creates main branch, no commit
git annex init # creates git-annex branch with a commit, also modifies .git/config
echo big-data > file.dat
git annex add file.dat # creates commit in git-annex branches
git commit -m "Adding file.dat" # creates commit in main
git annex addurl --file file.dat http:https://www.oneukrainian.com/tmp/file.dat # only updates git-annex branch if no content change
# For now no remote
git remote add --fetch remote ../remote # no commits
git annex sync # if remote had its own history for git-annex branch -- it would get merged
git annex copy --to=remote file.dat # commit in git-annex branch updating availability information
# now another file
echo text > text.txt
git add text.txt && git commit -m 'Added text file'
git merge --always HEAD^^ # some fake merge arch
echo more-data > another.dat
git annex add another.dat && git commit -m 'Added another.dat'
)
(
cd origin
#git sim log --all
git sim --animate log --all
)
pwd
produces following time stamps and following NB addition of that |
but what about going in reverse order -- from oldest to newest? |
Hmm, so with the graph why is it showing the second commit
I actually had that feature in my original program |
if I got it right -- it just confirms my point that it is not chronological in i messed around with chatgpt a bit to see if it could give me something usable but "we" didn't figure out how to enforce chronological order. FWIW here is the script#!/bin/bash
echo 'digraph G {'
git log --all --abbrev-commit --pretty=format:'%h [label="%h %s %ci",shape=ellipse];' --date-order |
while IFS=' ' read -r commit label; do
echo "\"$commit\" $label"
for parent in $(git log --pretty=%P -n 1 $commit); do
echo "\"${parent:0:7}\" -> \"$commit\";"
done
done
echo '}'which if ran produces smth like
which isn't good really |
|
Hahaha nice, I like the idea of referring to yourself and ChatGPT as "we". While we're being honest I also used it to help decipher your shell commands 😸... Anyway - ok that's true, we don't need to mimic Git's ordering exactly. One thing that's not too encouraging for this is that if you try and run |
|
Closing without implementation as the effort to implement such a thing likely outweighs the demand from a user perspective. However, if more folks request this I will reconsider. |
Originally brought up in #95 (comment) that the order of commits appearing in --animate is not necessarily chronological. In that example commits are actually happening in parallel on two branches -- the default (e.g.
master) and supplemental (git-annex) managed by a tool (git-annex).Note: there is bother Committer and Author dates
which might differ. So may be it should be an option with value, e.g.
--chronological=(author|commit)The text was updated successfully, but these errors were encountered: