Monitoring commits on all branches

Marc Branchaud marcnarc at gmail.com
Sat Nov 21 19:07:00 UTC 2020


(trimmed some of the quoting)

On 2020-11-21 9:11 a.m., Dan Langille wrote:
> On Thu, Nov 19, 2020, at 5:30 PM, Marc Branchaud wrote:
> 
>> Watch out with that "git checkout branch" part: This is where a lot of
>> people get tripped up when they move from svn to git.  It doesn't help
>> that git tries to do some hand-holding here, but really git users would
>> benefit from simply understanding how branch names are just labels for
>> commit SHA IDs.  Without that understanding, people end up going down
>> the rabbit-hole that is the "git pull" command, a wretched hive of scum
>> and villainy if there ever was one.
> 
> I understand the concern and I think I follow.  Within the confines of
> 'only wanting the files for reference, never local modification', pull and
> fetch might be the same for me. I'll look at fetch more.

"git fetch" is just the "get updates from the remote repo" part of "git 
pull".

The thing with pull is that it wants to "help" you update your local 
branches the "right" way.  But the "right" way really depends on how you 
work and how your project works.  So most advice to "do a 'git pull'" is 
only useful for the most general of cases.

I consider "git pull" to be one of git's most advanced commands.  It's 
very powerful, and can certainly make life easier -- once you actually 
understand how git works and how to configure pull to do what you 
actually want.  I always advise git beginners to stay away from using 
pull until they have a firm grasp of git's branches and of how they want 
to use them.

I personally never use "git pull" because I regularly want to use my 
local branches in different ways, even within a single project/repo.

>> Looking through the set of hooks ("git help hooks"), I don't see
>> anything that would help you.
> 
> My idea for a hook: FreeBSD tells FreshPorts when a new commit arrives.
> FreshPorts wakes up and processes it.

That's certainly doable, though a bit unusual:  Most "downstream" 
projects fetch updates from their upstream.  I was assuming you didn't 
want any special consideration from the FreeBSD repositories.

>>> * Once branch exists, how do you find out about the commits when you have no
>>> starting point for 'git log'?
>>
>> Use "git merge-base" to find where the new branch split off from the
>> "master" or "main" branch.
> 
> That is my starting commit for that branch?

No, it's the *parent* of your starting commit.

To list the SHA IDs of all the commits in the branch, do:

	BASE=`git merge-base master..$BRANCH`
	git rev-list $BASE..$BRANCH

>> One last, small idea:  Consider using tags in your local repos to track
>> your $branch_last_hash.  For example, after you finish processing the
>> 2020Q4 branch, do
>>     git tag -f last-2020Q4 origin/branches/2020Q4
>> Then the next time through the 2020Q4 branch you can start at the
>> "last-2020Q4" tag.  For a new branch that doesn't have a tag yet, use
>> "git merge-base" to find the starting point.
> 
> Tags in my local repos won't get things upset?

Not at all: tags are local in git -- just make sure to choose unique tag 
names, since you don't want to collide with any tags your upstream repo 
might use.  Tags can be pushed to / fetched from other repos, but since 
you're not updating the upstream FreeBSD repos (or any other public 
repo, I assume) you can do anything you want with your tags.

> If I lose the local repo....

That problem exists no matter how to choose to store state for your scripts.

With git it's easy to backup your local repository, including its tags: 
just "clone --mirror" it.

		M.



More information about the freebsd-git mailing list