Date: Sun, 22 Nov 2020 19:58:59 -0500 From: Dan Langille <dan@langille.org> To: Marc Branchaud <marcnarc@gmail.com> Cc: freebsd-git@freebsd.org Subject: Re: Monitoring commits on all branches Message-ID: <6EA93D4C-B399-413D-8C35-224103CC48D6@langille.org> In-Reply-To: <ef10bac7-c30d-8197-3164-7b0aff00c80d@gmail.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> <ef10bac7-c30d-8197-3164-7b0aff00c80d@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Today I managed to sit down and go through the multiple scripts involved = in pulling in a commit. = https://news.freshports.org/2020/11/22/git-commit-processing-how-is-it-don= e/ Some changes were made.... > On Nov 21, 2020, at 2:06 PM, Marc Branchaud <marcnarc@gmail.com> = wrote: >=20 > (trimmed some of the quoting) >=20 > 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. >=20 > "git fetch" is just the "get updates from the remote repo" part of = "git pull". >=20 > 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. Commits on the quarterly branch are now being automatically processed. Now that the code is not doing 'git checkout master', which made sense = on master, things are going better. git fetch git checkout master git rebase $REMOTE/master Now its just doing: git pull git rev-list <HASH>..HEAD This seems to be working. However, that may change if I start doing local tags. > 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. >=20 > I personally never use "git pull" because I regularly want to use my = local branches in different ways, even within a single project/repo. I'll keep that in mind should I start using branches in different ways. >=20 >>> 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. >=20 > 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. I am purposely avoiding the github commit hooks. They are too tied in... >=20 >>>> * Once branch exists, how do you find out about the commits when = you have no >>>> starting point for 'git log'? >>>=20 >>> 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? >=20 > No, it's the *parent* of your starting commit. >=20 > To list the SHA IDs of all the commits in the branch, do: >=20 > BASE=3D`git merge-base master..$BRANCH` > git rev-list $BASE..$BRANCH Thanks. >=20 >>> 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? >=20 > 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. That may be for next weekend. =20 >> If I lose the local repo.... >=20 > That problem exists no matter how to choose to store state for your = scripts. >=20 > With git it's easy to backup your local repository, including its = tags: just "clone --mirror" it. Got it. --=20 Dan Langille - BSDCan / PGCon dan@langille.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6EA93D4C-B399-413D-8C35-224103CC48D6>