On Sat, Oct 7, 2023 at 1:29 AM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Naomi Ibe <naomi.ibeh69@xxxxxxxxx> writes: > > > First issue is here https://github.com/gitgitgadget/git/issues/635 , > > involving changing the "die()" error msg outputs to all lowercase. I > > found a few files here https://github.com/git/git/tree/master/builtin > > where the "die()" error msg had some uppercase in them (add.c in lines > > 185, 203, 205, 211 and 571) (branch.c in lines 521, 525, 581, 597, > > 599, 627, 629, 643, 650, 652, 776, 926, 954 and 968). If I'm allowed > > to work on this issue, how many files should I edit? The last closed > > issues related to this issue had edited five files. > > As the "general microproject information" page says, it is a good > idea to do just one quality-focused microproject per applicant. > > If I were on the receiving end to review such a patch, I would > probably find it is too boring a burden if it had several unrelated > commands covered by a single patch, and would stop reading in the > middle. > > If I were on the sending end to work on them for real (not as "dip > my toe in the water and say hello to the more experienced > developers" exercise), I would probably prepare a series of patches, > one for each git subcommand (e.g. "add", "branch", "log", etc.), and > for shared infrastructure files, one for each subsystem that they > are part of (this is harder to do for a new person who do not know > what subsystems exist, and which files implement which subsystem), > but for a microproject, I would say a single file under builtin/* > hierarchy would be a good size. Yeah, I agree. In my opinion, a single patch focused on a single file like builtin/add.c or builtin/branch.c is the best. > > Second issue is this https://github.com/gitgitgadget/git/issues/302 . > > Is it still available to be worked on? I notice it was opened in 2019 > > Stepping back a bit, do you agree with what the issue says? > Remember, these "issue"s are merely one person's opinion and not > endorsed by the community. > > Before you ask "is it still available", do you know the current > status (not the status of the "issue")? Have you looked at "git > commit --help" to find it out yourself to see if "now" is singled > out? Here is what we say in our documentation: > > In addition to recognizing all date formats above, the --date > option will also try to make sense of other, more human-centric > date formats, such as relative dates like "yesterday" or "last > Friday at noon". > > So apparently it is still "available". It is a different matter how > well a patch that adds "now" to the examples listed there will be > accepted, though. During a microproject, one of the things new > contributors are expected to learn is to convince others the cause > of their patches with the proposed commit log message well. Yeah, I think this issue, if it is indeed an issue, is not something easy to "fix" for a newcomer as it requires to be familiar with our documentation and perhaps our code too, or to research them enough to understand what a good improvement would be. So you could perhaps do it, but it would likely require more work. > Finally, you do not need to obtain permission to work on anything > around here. You work on what interests you, send the result (or > send request for help, to which others may offer advices if the > problem you are solving looks interesting) to be reviewed, and will > be thanked for working on it when your patch is applied. To avoid > duplicated work, you might want to say "I'm interested in doing > this, but is anybody already doing it? If so I'll avoid stepping on > their toes", but otherwise, you are expected to go wild on your own > ;-) I think it's a good idea to ask if the task would be too difficult, too time consuming, too big or otherwise not appropriate for a microproject. But true, we don't want applicants to ask for some kind of permission. We prefer if they just ask for advice.
