how to git log between two branches

[juliaschell]

Is there a way to do the equivalent of git log master...my/branch? Very new to this package, but really only seeing timestamps as a way to limit log results.

My goal is to iterate through all the commit messages between my current branch and master

[HejVkt]

Try this

	cIter, err := g.Log(&git.LogOptions{
		From:  reference.Hash(),
		Order: git.LogOrderCommitterTime,
	})

where reference is a ref to your branch

[juliaschell]

Tried the code below but it gives me all the commits in the branch. I need all commits between my branch and master.

			dir, err := os.Getwd()

			repo, err := git.PlainOpenWithOptions(dir, &git.PlainOpenOptions{DetectDotGit: true})
			if err != nil {
				return fmt.Errorf("Failed to open git repository at %s: %s", dir, err)
			}

			log.Debugf("Opened git repository at %s", dir)

			ref, err := repo.Head()
			if err != nil {
				return fmt.Errorf("Failed to get head: %s", err)
			}

			cIter, err := repo.Log(&git.LogOptions{
				From:  ref.Hash(),
				Order: git.LogOrderCommitterTime,
			})

			cIter.ForEach(func(c *object.Commit) error {
				fmt.Println(c)
		
				return nil
			})

[HejVkt]

This seems to be unsupported right now. You can read the log of the main branch and the log of your branch and compare them.

[tbe]

I would:

• get the mergebase between the current branch and master
• get the log from the current branch
• iterate over the log until the merge-base is reached

[movelazar]

Has any update been made here? @ilius 's PR looked promising. Log between any two commits would be highly useful.

There are certainly manual workarounds for most use cases. Just would be nice to fully mirror the tasks easily done by the git cli.

[ilius]

The correct algorithm that comes to my mind right now is this. Assuming we want log A..B where A and B are commits:

1. Iterate over ancestors of both A and B (at the same time) in time-order (committor or author time), until we find their nearest common ancestor (closest parent of both), call it C.
2. Iterate over ancestors of A and then yield (return in an iterator) all commits until we reach C.

This approach has a passible problem:

• It takes a linear time before the output/resulting iteration begins.

My PR only supported ordering by committer time to avoid this. Which is different than git's default order. I think that's why I closed my PR (I was kind of confused myself at the time).

[Ajnasz]

There is a mergeBase method which is to find the best common ancestors of commits. That should help with point 1 I think.

[viktomas]

• get the mergebase between the current branch and master
• get the log from the current branch
• iterate over the log until the merge-base is reached

FYI @tbe, @Ajnasz The git merge-base might not help us. Consider the following scenario:

* F3 (HEAD -> feature) feature-third
*   MERGE Merge branch 'main' into feature
|\  
* | F2 feature-second
* | F1 feature-first
| | * M4 (main) main fourth
| | * M3 main third
| |/  
| * M2 main second
| * M1 main first
|/  
* A first

merge-base looks for the best commit to be a base for 3-way merge. In the above repo, the git merge-base returns M2 commit (because the M2 has been merged to the feature branch).

The git log iteration over commits would hit the MERGE commit, and then we would have to ensure that it follows both ancestors (branches). In one of the branches (M2, M1, A) it would encounter the merge-base commit, but in the other (F2, F1, A) it wouldn't.

[dinvlad]

I believe there's an issue with MergeBase where it fails when base ref is grafted. For example, if one clones with a --shallow-since timestamp of the base-ref commit, then MergeBase will fail with could not find common base between the given references: object not found.

This is unlike git merge-base, which doesn't fail in such case.

[FreddieMcHeart]

Is there any option to realize git log dev ^main command? The result of this command shows the list of commits that are different between the dev and the main branch

[github-actions[bot]]

To help us keep things tidy and focus on the active tasks, we've introduced a stale bot to spot issues/PRs that haven't had any activity in a while.

This particular issue hasn't had any updates or activity in the past 90 days, so it's been labeled as 'stale'. If it remains inactive for the next 30 days, it'll be automatically closed.

We understand everyone's busy, but if this issue is still important to you, please feel free to add a comment or make an update to keep it active.

Thanks for your understanding and cooperation!

[github-actions[bot]]

To help us keep things tidy and focus on the active tasks, we've introduced a stale bot to spot issues/PRs that haven't had any activity in a while.

This particular issue hasn't had any updates or activity in the past 90 days, so it's been labeled as 'stale'. If it remains inactive for the next 30 days, it'll be automatically closed.

We understand everyone's busy, but if this issue is still important to you, please feel free to add a comment or make an update to keep it active.

Thanks for your understanding and cooperation!

[indrajit-roy-sc]

This is a vital feature for generating change-logs for repos. Has there been traction on this?

[nomaed]

I think that from..to requires topological order which is not available at this moment. I added my use case here: https://github.com/go-git/go-git/issues/372#issuecomment-2265635661