Date: Sat, 21 Nov 2020 14:06:56 -0500 From: Marc Branchaud <marcnarc@gmail.com> To: Dan Langille <dan@langille.org> Cc: freebsd-git@freebsd.org Subject: Re: Monitoring commits on all branches Message-ID: <ef10bac7-c30d-8197-3164-7b0aff00c80d@gmail.com> In-Reply-To: <785f1386-f521-46d2-8e2e-a7c502fd943a@www.fastmail.com> References: <197541CC-FEA7-4B4C-936E-66A5625BB64C@langille.org> <3c9f6285-ae7c-1062-2dd3-42f8c953a230@gmail.com> <BE9B078D-633B-4340-9A79-03B0FA60C431@langille.org> <93aa2a3e-7e8a-8199-3feb-6e464a590d72@gmail.com> <785f1386-f521-46d2-8e2e-a7c502fd943a@www.fastmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
(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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ef10bac7-c30d-8197-3164-7b0aff00c80d>