Re: Slightly off topic, question about git
On Wed, 2022-06-08 at 06:45 -0400, Mouse wrote:
>
> > Interactive add ('git add -u -p', and 'git reset -p' before 'git
> > commit') lets you separate unrelated changes into individual commits
> > as they should be.
>
> Based on the documentation I've seen, though, they're somewhat
> crippled, in that they work at diff-hunk granularity, and tend to be
> single-pass - I haven't used them myself, because they depend on perl,
> so I have to depend on documentation. I wrote a curses tool that,
> while still pre-alpha quality, does philosophically similar things
> (without needing perl).
Not crippled at all, quite the opposite. Interactive add
_defaults_ to diff hunks, and you can pick them or skip them from
the staging which constructs the next commit. But you can also
's' split hunks for finer selection, and 'e' edit the hunk to
create exactly what you would like to get staged. You can have
chunks revisited later in the selection after seeing other hunks.
Total control, your choice. Just see the legend near the prompt
(assuming the git subcommand is available to you, of course).
In the past I've seen people use some other UI than 'git add -p'
but cannot remember the name. These UIs may differ, can't tell
from first hand experience.
> > And do not mistake github.com the service provider or its many
> > unaware users as representative for git-scm.org the tool and concept.
>
> Eh. The tool is git. git-scm.org is a domain name (colloquially used
> to refer to a website), not the tool.
I'd assume that you got what I intended to express. The fact that
'github' has 'git' in its name leads unaware people to think
they'd be the same. They are not. That's what I tried to say.
virtually yours
Gerhard Sittig
--
If you don't understand or are scared by any of the above
ask your parents or an adult to help you.
Re: Slightly off topic, question about git
[ incomplete list of git features that a BSD developer may like ]
On Mon, 2022-06-06 at 14:40 +0200, Gerhard Sittig wrote:
>
> [ ... Brian Buhrow asked for useful access to VCS history ... ]
Your question started with a specific command accessing the
information for a single file ('cvs log sys/dev/pci/if_bge.c').
There could be something else that you intend perhaps. Let's see
whether these things help you, too.
There is 'git describe' that lets you see what you currently are
looking at. Typically results in the most recent tag plus a
number of commits and the resulting hash of what you specified as
input. Can be helpful to tell you how far your development has
gone since a release.
There is 'git describe --contains' which tells you which next tag
(read: a released version) contains a specific commit (read: a
fix or new feature or changed behaviour). This is useful for
maintenance, and the reason why some mention "Fixes: " in
their commit messages, so that other people or machinery can tell
whether their stable release needs updating/amending.
That git thinks of the whole content of the tree, and that a
filter is applied to narrow the result set when you specify dirs
or files, was mentioned before. Changes your perspective.
Tinker with 'git log' options, there are tons of them, and your
needs will differ depending on which situation you are in. One
aspect is "the zoom level": --oneline alone for bird's view, no
spec for author/date/message, -p to include the content change.
Others are --reverse, --format=, --name-status, --staged, etc.
The --stat option is very useful for reviewers/maintainers.
I don't like the 'git blame' name, because it's additional
information that I'm looking for and not a guilty person. :)
That's why I got an 'ann' alias to invoke 'blame'.
The default 'git status' output is very helpful if you are
looking for help on what to do next. But terrible to digest in
quick iterations. 'git status -s' helps parse that stuff. And
I feel that 'git commit -v' should be the default. To help create
useful commit messages.
Other things that can help the BSD projects regardless of whether
the decentralized development model is considered a fit:
Bisection lets you quickly navigate to a commit of interest. When
HEAD works for you, and an older version is said to have an
issue, then 'git bisect' lets you identify the commit which
probably introduced the change in behaviour. Either driven by a
human and supported by the machine, or fully automated if you
have a test condition which the machine can check for you. This
reduces a set of 10k changes between two releases to some 15
steps that you need to look at, before your attention is where
it needs to be. Of course this depends on whether a one-liner
enables something that got introduced a few hundred commits
before that which just did not take effect immediately. But it
helps you narrow in to what you should be looking at. Linear
history helps there. That's again why rebase is useful.
Interactive add ('git add -u -p', and 'git reset -p' before 'git
commit') lets you separate unrelated changes into individual
commits as they should be. Without tediously copying files around
or losing part of what you accumulated. Interactive rebase ('git
rebase -i') lets you create a proper patch series that others can
digest during review, and reason about why it's desirable to pick
up. Rebasing is useful in these iterations before submission, and
what ends up in the mainline project is clean and maintainable.
Showing other people you local changes could be done by pushing
to a public place. Or by the 'git format-patch -o $DIR $BASE..'
command. The counterpart is 'git am' (apply a set of changes).
Even if you don't do the "popularity contest" among several
mainlines(?) that others suggested, it's a useful feature to have
between involved developers. The result would be similar to
patches that currently are attached to emails, just easier to
review and test perhaps. There is 'git apply' if you have a patch
that is not git-am formatted.
'git diff' has a few options that can make it more pleasant to
view than mere diff(1) output. But that's cosmetics. Diffstats
are very useful to have once you get familiar with them.
This is not an attempt to cram git down your throat just because
I happen to like it after getting to know it. It's a plea to
consider whether the tool could help you in ways that you haven't
seen before, before assuming that "these people" don't know how
to create a proper tool because it's different from what you used
so far in your daily routine.
The reason why git is different is that no other tool matched the
Linux kernel development model with its thousands of mostly
disconnected participants. The tool still can be applied in a
centralized manner (many companies do), and can be more
convenient than other tools. I'm often using git to communicate
to a subversion server. Don't know if ther
Re: Slightly off topic, question about git
On Mon, 2022-06-06 at 15:39 +0200, Johnny Billquist wrote: > > On 2022-06-06 15:12, Mouse wrote: > >>>>[H]istory rewriting seems to be a favorite pastime of git users. > >>>That's not a fault of git; that's a fault of how some people use > >>>git. > >>Well, you could argue that it's a fault in git that it allows it. > > > >>If there is a way, then some people will use it that way. > > > >But, if there isn't, some people will add it. git rebase is very > >little more than a loop containing git cherry-pick. > > It is more, since this can be done without any hint that this > actually happened. > > Basically, what I've seen in git: > > > o Some commit (1-Jan-2022) > | > | o Some branch commit (29-Dec-2021) > | | > | / > | / > | / > |/ > oA commit (31-Dec-2021) > | > | > > > Now, how could "some branch commit" happen on Dec 29, when what it > was based on was committed Dec 31 that same year? That's obviously > not possible, and yet, that is what I see in git. This image may be incomplete. Are you "thinking centrally" perhaps? Or am I missing something else? It's true that commit "Some branch commit" could never have been _committed_ before "A commit". But it perfectly could have been _authored_ before that commit, pick, merge or whatever the action was which made the commit appear in the tree. Could be helpful to see --format=fuller, which is why I have an alias for that to enable the option by default. In my perspective git is just more honest here, and tries hard to reflect what happened in the real world to the source code. Which now makes you see roles that just did not exist at all in the centralized setup. IIUC the CVS or SVN history only has the concept of a committer doing a commit, and this name and this date is taken and placed into the history. Which results in a linear sequence based on the server machine's timebase. In git you have the author (the person who created that content), which can be different from the committer (a maintainer or integrator or other user who happened to bring this content into _this_ specific repository). This better reflects the development model of where git originated. May not translate equally well to the NetBSD development model which appears to be centralized indeed. But then git metadata will just have identical names and dates for authoring and commits, no problem there. In the past I had occurences where a maintainer picked up a submitted change some three years after I submitted it. That's not unusual AFAICS. The BSD projects probably also have branches sitting somewhere which may get merged later into more recent releases, and nobody would suggest that the content creation would have been at the time of the merge. This could even be seen as a misattribution of the work that was done. And this metadata may matter with regard to prior art, licensing, or similar. You remember AT who stalled some BSD development, and SCO who tried to misrepresent the Linux history and resulting ownership? Something similar would be seen when you pick fixes and merge them to a release. The branch may be new but the commit with the fixes may be newer or older than the branch point. Does that explain what you outline above in the illustration, or am I missing something? virtually yours Gerhard Sittig -- If you don't understand or are scared by any of the above ask your parents or an adult to help you.
Re: Slightly off topic, question about git
On Mon, 2022-06-06 at 08:33 -0400, Mouse wrote: > > > I've recently come to realize a thing with git I really abhor. It > > has a very loose view on history immutability. I've seen branches, > > which claims to come from some point, where the branch is way older > > than the revision it claims to have been branched off. Which > > obviously is impossible. But history rewriting seems to be a > > favorite pastime of git users. > > That's not a fault of git; that's a fault of how some people use git. What Mouse said. Rebasing or force pushing what was _published_ before is even frowned upon. What you do to your local tree is up to you. Go and arrange at will. This results in a better submission that is easier to maintain at the upstream project's side by the way, a useful feature and the reason why it exists. But what was published, and what others are working with, "is sacred" and must not change. Rebasing a work in progress upon submission to upstream is a useful feature, if the project prefers a linear history. The maze of merges for feature branches are not preferred by everybody alike. Rebase is not about making yourself look better to others. It's beyond cosmetics. It's a means to achieve a code base that is easier to work with at the maintainers' side. As always: Go try it for yourself. Get a copy of a kernel, work for weeks on a local change, and see how rebase against the then-current version of upstream works for you. I liked it a lot. It's careless force-pushing which makes me mad, and I don't want to work with such a repo either. It's unfriendly behaviour. Regarding dates, that an interesting thing. Git has the concept of author date and commit date, which reflects the organization of the project where the tool originated. Work on a change really can have happened in any order which need not be the order of acceptance into the common tree. And which repo is considered _the_ tree of the project is not a git feature, but a convention among involved persons. Some UIs may be adding to the confusion, I believe github is one of those which doesn't present the order of commits as they are in the repo. Their implementation detail, not a limitation nor the fault of the git tool. This git feature also BTW lets you locally use and explore work that others are currently at, without going through one central server. This is the very point of being distributed. No copying patch files around manually. virtually yours Gerhard Sittig -- If you don't understand or are scared by any of the above ask your parents or an adult to help you.
Re: Slightly off topic, question about git
idual command's page. There are generic subjects, the 'git --help' output refers to these as "concepts". You may be looking for gitrevisions(7) perhaps. Git lets you express things that may not map to cvs' capabilities. Go explore. I find myself using some of these phrases, others I haven't inhaled yet. It's similar to vim and other tools, everyone finds a working set that works for him in his environment. Others mentioned that for git-log specifically the syntax is $ git log [commit-ish] -- [file/dir]... or similar. And yes you will quickly accumulate a ~/.gitconfig file with several aliases. You know best what you keep using all day. Format options are another area to customize and alias (think -p, --stat, file names, --format=fuller, ISO date, etc). Other features that you may never want to miss could be interactive add, interactive rebase, and bisection as mentioned above. Lots to explore. Don't assume that git would just be a different kind of subversion, it so totally is not. Another important thing that I notice when people ask questions: Don't let others tell you that there is just one way, don't try to come up with the most clever and the shortest (read: maximum terseness) command. Just get a few concepts in your head, pick up a working set of primitives, and combine these. After some 15 years of git use I don't have everything in my head either. Just take the steps that get you to where you want to go to. Being confident that your small or wide strided steps do take you there is nice, I like it. Another great experience: You have to twist and bend before you lose data, it's actually hard to do that with git. There are a few "dangerous" commands (some three of them in total I guess), and they have red flags so that you will be aware. But the majority of git commands just adds to the metadata. And you got means to recover from your mistakes because nothing was really lost. (See reflog et al.) Did I mention that I like git a lot after overcoming the first hurdles? You may have guessed that from the above text. There really are convincing reasons to switch, or to seriously consider one of the distributed systems. It's not that the older tools are bad, they have served the community a long time, and are better than what existed before them. It's just that better tools have become available in the meantime. virtually yours Gerhard Sittig -- If you don't understand or are scared by any of the above ask your parents or an adult to help you.
Re: style change: explicitly permit braces for single statements
On Mon, 2020-07-13 at 09:18 -0700, Greg A. Woods wrote:
>
> At Mon, 13 Jul 2020 09:48:07 -0400 (EDT), Mouse
> wrote:
> Subject: Re: style change: explicitly permit braces for single statements
> >
> > Slavishly always
> > adding them makes it difficult to keep code from walking into the right
> > margin:
>
> These days one really should consider the right margin to be a virtual
> concept -- there's really no valid reason not to have and use horizontal
> scrolling (any code editor I'll ever use can do it on any display), and
> even most any small-ish laptop can have a nice readable font at 50x132,
> or even 50x160. (i.e. that's another style guide rule that should die)
Sorry, but I strongly have to disagree.
Text line length does matter to those of us who put several
copies of code side by side. In that scenario your total screen
size does not matter, there still is not enough room for 120
characters on a line in one of the files, or all of them. "But
_my_ screen is soo wide" only kind of works when one considers a
single file on the screen at any time, or only vertically split
windows. That's only half the truth. Even with multiple screens
you still may want to put several applications including editors
or text windows side by side, and avoid having to switch between
them, or chose which of them you can see at a time.
And no, I would not want to _have_ to side scroll, just to (start
to) see the code with runs out of the screen's right hand side.
It breaks the flow, is terribly slow and tedious to control, and
makes it hard(er) to spot matching braces that are vertically
aligned to their opening construct. While none of the flow
breaking obstacles are necessary.
There are useful cases where longer text lines are appropriate
("stupid" data tables, user visible string literals that you want
to be able to grep for when researching a bug report). Those
_are_ useful, but should remain the exception. From personal
experience I found the 80 chars limit the hardest to get used to,
but once you get it, a very useful one. Even today. Because
reasons, it's not as arbitrary as it may seem.
There is a reason why papers and web pages are laid out in
columns. It's more than just a tradition. Has to do with
readability. Really. Try to find the start of the next line after
the previous line was rather long. Even more so with the tiny
fonts that you mention above. And screens got smaller again with
mobile devices after they got bigger before. History keeps
repeating. :)
virtually yours
Gerhard Sittig
--
If you don't understand or are scared by any of the above
ask your parents or an adult to help you.
