* Re: Migrate away from vger to GitHub or (on-premise) GitLab?
From: Junio C Hamano @ 2024-02-02 17:39 UTC (permalink / raw)
To: rsbecker; +Cc: git
In-Reply-To: <009601da55fa$1ecc9580$5c65c080$@nexbridge.com>
<rsbecker@nexbridge.com> writes:
> I should have qualified this with "free" NNTP. I have only been able to find
> for fee NNTP servers where I am. The search continues.
The NNTP server "nntp.lore.kernel.org" carries the mailing list
served by lore.kernel.org archives, including this list.
^ permalink raw reply
* Re: [PATCH v2 0/2] add-patch: Support '@' as a synonym for 'HEAD'
From: Ghanshyam Thakkar @ 2024-02-02 17:31 UTC (permalink / raw)
To: Ghanshyam Thakkar, git; +Cc: gitster, ps
In-Reply-To: <20240202150434.11256-1-shyamthakkar001@gmail.com>
On Fri Feb 2, 2024 at 8:33 PM IST, Ghanshyam Thakkar wrote:
> This patch series removes a non-relevant NEEDSWORK comment and addresses
> disparity between '@' and 'HEAD' in patch mode for (checkout, restore,
> reset) commands.
>
> The removal of the NEEDSWORK comment and the '@' support are split into
> different patches because the former is still up for discussion. And if
s/former/latter/
> it is decided against, the NEEDSWORK comment can still go as it would not
> be the desired solution anyway (described in the commit message).
^ permalink raw reply
* Re: [PATCH v3 03/10] trailer: unify trailer formatting machinery
From: Junio C Hamano @ 2024-02-02 17:26 UTC (permalink / raw)
To: Linus Arver
Cc: Linus Arver via GitGitGadget, git, Christian Couder,
Emily Shaffer, Josh Steadmon, Randall S. Becker
In-Reply-To: <owlyil371g96.fsf@fine.c.googlers.com>
Linus Arver <linusa@google.com> writes:
> The hard part is not so much the rearranging of
> code but rather thinking up of good commit messages to explain the
> intent of each smaller step.
Good.
Coming up with a good explanation of what you did forces you to
think it thorough again. People often discover bugs in the code
they just wrote, or different and better ways to solve the problem,
while explaining the change to their colleagues, and I found it has
very similar effect to try to write a good explanation in the commit
log. Time to write such a good explanation is time worth investing
in.
Incidentally, this is why we value clearly written proposed log
message while reviewing. A commit that is a product of "I tried
this, which did not work, and then tried something else, which did
not work either, and after some more random tries, this seems to
work" would not have a clear thinking behind it, but if such
iterations of random tries happened to hit the best solution,
thinking backwards from the result to the original problem and
explaining how the solution works would result in a good
description.
Thanks.
^ permalink raw reply
* Re: Migrate away from vger to GitHub or (on-premise) GitLab?
From: Michal Suchánek @ 2024-02-02 17:23 UTC (permalink / raw)
To: Theodore Ts'o
Cc: rsbecker, 'Sergey Organov', 'Hans Meiser', git
In-Reply-To: <20240202161643.GD119530@mit.edu>
On Fri, Feb 02, 2024 at 11:16:43AM -0500, Theodore Ts'o wrote:
> On Fri, Feb 02, 2024 at 10:22:18AM -0500, rsbecker@nexbridge.com wrote:
> > >
> > >Did you consider to rather read the list through
> > >gmane.comp.version-control.git nntp newsgroup?
> > >
> > >This way you get only very specific mails in your mail-box, those
> > >where you are explicitly CC'ed, and you usually get more support
> > >for structuring from NNTP readers than from mail clients.
> >
> > Google is dropping Usenet NNTP updates on 22 Feb 2024. I would love
> > that idea, but it has a limited lifespan.
>
> Google might be dropping Usenix NNTP updates, but news.gmaine.io and
> nntp.lore.kernel.org are not not run by Google. So whether or not
> Google groups are supporting NNTP is not really supporting.
>
> One other thing I would note that is that if someone isn't interested
> in following most of the git mailing list, it's unclear how much they
> can actually contribute. Maybe they could fix spelling or grammer
> issues in the git man pages, but it's unlikely they could actually
> make code contributions.
>
> So from an open source project perspective, which is primarily run by
> volunteers, each open source project has to make a cost-benefit
> tradeoff as far as the *project* is concerned. Individuals do not
> have a fundamental human right to contribute to a project. Hence, the
> open source project doesn't owe an obligation to spend a huge amount
> of effort supporting some kind of forge web site just because some
> potential contributors are clammoring for it. Especially if they are
> saying that they can't be bothered to follow the mailing list traffic
> because it's somehow too much.
That's not to say that the mailing list traffic cannot be wrapped in
another interface if somebody has the motivation and spends the effort
to do it.
For example, there used to be (and maybe still is) a bidirectional
gateway that bridged the ruby-talk mailing list into a web forum that was
run by a person who thought it's a good idea, and resolved the problems
that came out of it.
e-mails have pretty good 1:! correspondence to forum posts or forge PR
comments. Some features like post edits or emoji reactions do not
translate, and cannot be provided with e-mail backend.
However, presenting the mailing list through a different interface, and
hosting the application doing the translation is a work that the person
suggesting the change would have to do, or hire someone to do for them,
rather than coming and saying 'Throw away all the tools you have now,
and install and run this thing instead to make it easy for me'.
Thanks
Michal
^ permalink raw reply
* Re: [PATCH v2 2/2] add-patch: classify '@' as a synonym for 'HEAD'
From: Junio C Hamano @ 2024-02-02 17:08 UTC (permalink / raw)
To: Ghanshyam Thakkar; +Cc: git, ps
In-Reply-To: <20240202150434.11256-3-shyamthakkar001@gmail.com>
Ghanshyam Thakkar <shyamthakkar001@gmail.com> writes:
> Currently, (checkout, reset, restore) commands correctly take '@' as a
> synonym for 'HEAD'. However, in patch mode (-p/--patch), for both '@' and
> 'HEAD', different prompts/messages are given by the commands mentioned
> above. This is due to the literal and only string comparison with the word
> 'HEAD' in run_add_p(). Synonymity between '@' and 'HEAD' is obviously
> desired, especially since '@' already resolves to 'HEAD'.
>
> Therefore, make a new function user_meant_head() which takes the
> revision string and compares it to 'HEAD' as well as '@'. However, in
> builtin/checkout.c, there is some logic to convert all revs besides
> 'HEAD' to hex revs due to 'diff-index', which is used in patch mode
> machinery, not being able to handle '<a>...<b>' revs. Therefore, in
> addition to 'HEAD', do not convert '@' as well, so it can be later
> used in assigning patch_mode_(...)_head.
In this context <a>...<b> names a single rev (not two revs) that is
the merge base of <a> and <b>. Perhaps
... there is a logic to convert all command line input rev to
the raw object name for underlying machinery (e.g., diff-index)
that does not recognize the <a>...<b> notation, but we'd need to
leave "HEAD" intact. Now we need to teach that "@" is a synonym
to "HEAD" to that code, too.
which may be a bit shorter.
You decided to use is_rev_head() instead of user_meant_head(), so
you'd need to update the above description to match, I think.
> - if (rev && new_branch_info->commit && strcmp(rev, "HEAD"))
> + if (rev && new_branch_info->commit && strcmp(rev, "HEAD") &&
> + strcmp(rev, "@"))
Shouldn't this be
if (rev && new_branch_info->commit && !is_rev_head(rev))
instead of "HEAD" and "@" spelled out?
Other than the above, nicely done.
^ permalink raw reply
* RE: Migrate away from vger to GitHub or (on-premise) GitLab?
From: rsbecker @ 2024-02-02 17:06 UTC (permalink / raw)
To: 'Junio C Hamano'
Cc: 'Sergey Organov', 'Hans Meiser', git
In-Reply-To: <xmqqcytevmwq.fsf@gitster.g>
On Friday, February 2, 2024 11:42 AM, Junio C Hamano wrote:
><rsbecker@nexbridge.com> writes:
>
>>>Did you consider to rather read the list through
>>>gmane.comp.version-control.git nntp newsgroup?
>>>
>>>This way you get only very specific mails in your mail-box, those
>>>where you are explicitly CC'ed, and you usually get more support for
>>>structuring from NNTP readers than from mail clients.
>>
>> Google is dropping Usenet NNTP updates on 22 Feb 2024. I would love
>> that idea, but it has a limited lifespan.
>
>You do not have to read NNTP newsgroup via Google Groups, which has, but
will be
>ending, support to gateway between them. The suggestion was to read these
>articles over NNTP instead of subscribing to the list, which does not
involve
>anything Google would (or wouldn't) do.
I should have qualified this with "free" NNTP. I have only been able to find
for fee NNTP servers where I am. The search continues.
^ permalink raw reply
* Re: [PATCH 3/3] rev-list: add --allow-missing-tips to be used with --missing=...
From: Junio C Hamano @ 2024-02-02 16:54 UTC (permalink / raw)
To: Christian Couder
Cc: git, Patrick Steinhardt, John Cai, Christian Couder,
Elijah Newren, Jeff Hostetler
In-Reply-To: <CAP8UFD3Hfgud19y_K1bZOudkBE-ss1_SgWTRVkJ7gUbYJ400yQ@mail.gmail.com>
Christian Couder <christian.couder@gmail.com> writes:
>> An obvious question is if this even needs to be a new option. What
>> are expected use cases where --missing=print without this option is
>> beneficial?
>
> I am not sure if such a case is really beneficial but some
> people/script/forges might rely on an error from `git rev-list
> --missing=print` to propagate back an error to some user interface.
Yes, and they are missing errors for starting point objects right
now, which is a bug, just like they were missing output for commit
objects before we fixed it recently?
>> If there is no plausible use case, perhaps we can treat
>> it as a mere bugfix to the existing --missing mechanism, especially
>> given that support of commits in "--missing" itself is relatively
>> a new thing.
>
> `--missing=...` detecting missing commits is new, but it might have
> been used to find missing blobs or trees for some time as it exists
> since:
>
> caf3827e2f (rev-list: add list-objects filtering support, 2017-11-21)
So it fixes a long-standing bug. So what?
Especially given that the change in behaviour is to error out only
when the user gave an object name for a missing object, and we know
the user wants to be notified on all missing objects "found" during
the traversal, it smells like (1) a rare enough case that may not
matter in the real world and (2) the existing scripts that may feed
potentially missing objects to the command would be doing an extra
check to ensure what they feed the command are not missing, in order
to avoid triggering that "starting point objects induce an error
instead of --missing=print report" bug, and the bugfix will make
such a workaround unnecessary.
^ permalink raw reply
* Re: [PATCH 3/3] rev-list: add --allow-missing-tips to be used with --missing=...
From: Junio C Hamano @ 2024-02-02 16:47 UTC (permalink / raw)
To: Christian Couder; +Cc: git, Patrick Steinhardt, John Cai, Christian Couder
In-Reply-To: <CAP8UFD0HwQr+qj=FrDQXJeY8PhVH1e7oErbVopgtv2X8ig7a7Q@mail.gmail.com>
Christian Couder <christian.couder@gmail.com> writes:
> I am also not happy with adding yet another dump loop like this. I did
> it because I couldn't think of a simple solution to avoid that.
FWIW, that word is "dumB" loop, if you are including the word in
your updated version.
But I am still wondering if this can be unconditionally turned on
any time --missing=... is used. Have you considered it? If we can
do that, it would eliminate the need for that extra broken loop that
will fail with "git rev-list --grep --allow-missing-tips -20 HEAD".
^ permalink raw reply
* Re: Migrate away from vger to GitHub or (on-premise) GitLab?
From: Junio C Hamano @ 2024-02-02 16:41 UTC (permalink / raw)
To: rsbecker; +Cc: 'Sergey Organov', 'Hans Meiser', git
In-Reply-To: <008b01da55eb$9f3c36d0$ddb4a470$@nexbridge.com>
<rsbecker@nexbridge.com> writes:
>>Did you consider to rather read the list through gmane.comp.version-control.git
>>nntp newsgroup?
>>
>>This way you get only very specific mails in your mail-box, those where you are
>>explicitly CC'ed, and you usually get more support for structuring from NNTP
>>readers than from mail clients.
>
> Google is dropping Usenet NNTP updates on 22 Feb 2024. I would
> love that idea, but it has a limited lifespan.
You do not have to read NNTP newsgroup via Google Groups, which has,
but will be ending, support to gateway between them. The suggestion
was to read these articles over NNTP instead of subscribing to the
list, which does not involve anything Google would (or wouldn't) do.
^ permalink raw reply
* Re: Migrate away from vger to GitHub or (on-premise) GitLab?
From: Theodore Ts'o @ 2024-02-02 16:16 UTC (permalink / raw)
To: rsbecker; +Cc: 'Sergey Organov', 'Hans Meiser', git
In-Reply-To: <008b01da55eb$9f3c36d0$ddb4a470$@nexbridge.com>
On Fri, Feb 02, 2024 at 10:22:18AM -0500, rsbecker@nexbridge.com wrote:
> >
> >Did you consider to rather read the list through
> >gmane.comp.version-control.git nntp newsgroup?
> >
> >This way you get only very specific mails in your mail-box, those
> >where you are explicitly CC'ed, and you usually get more support
> >for structuring from NNTP readers than from mail clients.
>
> Google is dropping Usenet NNTP updates on 22 Feb 2024. I would love
> that idea, but it has a limited lifespan.
Google might be dropping Usenix NNTP updates, but news.gmaine.io and
nntp.lore.kernel.org are not not run by Google. So whether or not
Google groups are supporting NNTP is not really supporting.
One other thing I would note that is that if someone isn't interested
in following most of the git mailing list, it's unclear how much they
can actually contribute. Maybe they could fix spelling or grammer
issues in the git man pages, but it's unlikely they could actually
make code contributions.
So from an open source project perspective, which is primarily run by
volunteers, each open source project has to make a cost-benefit
tradeoff as far as the *project* is concerned. Individuals do not
have a fundamental human right to contribute to a project. Hence, the
open source project doesn't owe an obligation to spend a huge amount
of effort supporting some kind of forge web site just because some
potential contributors are clammoring for it. Especially if they are
saying that they can't be bothered to follow the mailing list traffic
because it's somehow too much.
(Of course, I have all of the Linux kernel mailing list flowing into
my inbox, and have e-mail practices that can handle that load --- so
it's hard for me to have much sympathy about people complaining that
the e-mail load for git is too large --- compared to LKML, it's
*nothing*. :-)
- Ted
^ permalink raw reply
* Re: [PATCH v4 0/2] index-pack: fsck honor checks
From: Christian Couder @ 2024-02-02 15:48 UTC (permalink / raw)
To: John Cai via GitGitGadget; +Cc: git, Jonathan Tan, Patrick Steinhardt, John Cai
In-Reply-To: <pull.1658.v4.git.git.1706751483.gitgitgadget@gmail.com>
(John, sorry for having already sent this only to you.)
On Thu, Feb 1, 2024 at 2:47 AM John Cai via GitGitGadget
<gitgitgadget@gmail.com> wrote:
>
> git-index-pack has a --strict mode that can take an optional argument to
> provide a list of fsck issues to change their severity. --fsck-objects does
> not have such a utility, which would be useful if one would like to be more
> lenient or strict on data integrity in a repository.
>
> Like --strict, Allow --fsck-objects to also take a list of fsck msgs to
> change the severity.
>
> Changes since V3:
>
> * clarification of --fsck-objects documentation wording
>
> Changes since V2:
>
> * fixed some typos in the documentation
> * added commit trailers
>
> Change since V1:
>
> * edited commit messages
> * clarified formatting in documentation for --strict= and --fsck-objects=
>
> John Cai (2):
> index-pack: test and document --strict=<msg-id>=<severity>...
> index-pack: --fsck-objects to take an optional argument for fsck msgs
I reviewed internally on GitLab the initial versions of this series
and I reviewed this version 4. It looks great to me, so I am happy to
give my "Reviewed-by:".
Thanks!
^ permalink raw reply
* RE: Migrate away from vger to GitHub or (on-premise) GitLab?
From: rsbecker @ 2024-02-02 15:22 UTC (permalink / raw)
To: 'Sergey Organov', 'Hans Meiser'; +Cc: git
In-Reply-To: <877cjm53bf.fsf@osv.gnss.ru>
On Friday, February 2, 2024 9:49 AM, Sergey Organov wrote:
>Hans Meiser <brille1@hotmail.com> writes:
>
>> Hi,
>>
>> is there any current discussion about moving Git development away from
>> using a mailing list to some modern form of collaboration?
>
>Yes, now there is (again).
>
>> I'd like to be able to follow a structured discussion in issues and to
>> contribute to the Git documentation, but the mailing list currently
>> just bloats my personal inbox with loads of uninteresting e-mails in
>> an unstructured waterfall of messy discussion that I am not able to
>> follow professionally.
>
>Did you consider to rather read the list through gmane.comp.version-control.git
>nntp newsgroup?
>
>This way you get only very specific mails in your mail-box, those where you are
>explicitly CC'ed, and you usually get more support for structuring from NNTP
>readers than from mail clients.
Google is dropping Usenet NNTP updates on 22 Feb 2024. I would love that idea, but it has a limited lifespan.
^ permalink raw reply
* [PATCH v2 2/2] add-patch: classify '@' as a synonym for 'HEAD'
From: Ghanshyam Thakkar @ 2024-02-02 15:03 UTC (permalink / raw)
To: git; +Cc: gitster, ps, Ghanshyam Thakkar
In-Reply-To: <20240202150434.11256-1-shyamthakkar001@gmail.com>
Currently, (checkout, reset, restore) commands correctly take '@' as a
synonym for 'HEAD'. However, in patch mode (-p/--patch), for both '@' and
'HEAD', different prompts/messages are given by the commands mentioned
above. This is due to the literal and only string comparison with the word
'HEAD' in run_add_p(). Synonymity between '@' and 'HEAD' is obviously
desired, especially since '@' already resolves to 'HEAD'.
Therefore, make a new function user_meant_head() which takes the
revision string and compares it to 'HEAD' as well as '@'. However, in
builtin/checkout.c, there is some logic to convert all revs besides
'HEAD' to hex revs due to 'diff-index', which is used in patch mode
machinery, not being able to handle '<a>...<b>' revs. Therefore, in
addition to 'HEAD', do not convert '@' as well, so it can be later
used in assigning patch_mode_(...)_head.
There is one unintended side-effect/behavior change of this, even if
there exists a branch named '@', when providing '@' as a rev-source to
(checkout, reset, restore) commands in patch mode, it will consider it
as HEAD. This is due to the behavior of diff-index. However, naming a
branch '@' is an obvious foot-gun and there are many existing commands
which take '@' for 'HEAD' even if 'refs/heads/@' exists (e.g., 'git log
@', 'git push origin @' etc.). Therefore, this should be fine.
Also, add tests to check the above mentioned synonymity between 'HEAD'
and '@'.
Signed-off-by: Ghanshyam Thakkar <shyamthakkar001@gmail.com>
---
add-patch.c | 11 +++++++---
builtin/checkout.c | 11 +++++-----
t/t2016-checkout-patch.sh | 46 ++++++++++++++++++++++-----------------
t/t2071-restore-patch.sh | 18 +++++++++------
t/t7105-reset-patch.sh | 10 +++++++++
5 files changed, 61 insertions(+), 35 deletions(-)
diff --git a/add-patch.c b/add-patch.c
index 68f525b35c..6c70a0240c 100644
--- a/add-patch.c
+++ b/add-patch.c
@@ -378,6 +378,11 @@ static int parse_hunk_header(struct add_p_state *s, struct hunk *hunk)
return 0;
}
+static inline int is_rev_head(const char *rev)
+{
+ return !strcmp(rev, "HEAD") || !strcmp(rev, "@");
+}
+
static int is_octal(const char *p, size_t len)
{
if (!len)
@@ -1729,21 +1734,21 @@ int run_add_p(struct repository *r, enum add_p_mode mode,
if (mode == ADD_P_STASH)
s.mode = &patch_mode_stash;
else if (mode == ADD_P_RESET) {
- if (!revision || !strcmp(revision, "HEAD"))
+ if (!revision || is_rev_head(revision))
s.mode = &patch_mode_reset_head;
else
s.mode = &patch_mode_reset_nothead;
} else if (mode == ADD_P_CHECKOUT) {
if (!revision)
s.mode = &patch_mode_checkout_index;
- else if (!strcmp(revision, "HEAD"))
+ else if (is_rev_head(revision))
s.mode = &patch_mode_checkout_head;
else
s.mode = &patch_mode_checkout_nothead;
} else if (mode == ADD_P_WORKTREE) {
if (!revision)
s.mode = &patch_mode_checkout_index;
- else if (!strcmp(revision, "HEAD"))
+ else if (is_rev_head(revision))
s.mode = &patch_mode_worktree_head;
else
s.mode = &patch_mode_worktree_nothead;
diff --git a/builtin/checkout.c b/builtin/checkout.c
index a6e30931b5..79e208ee6d 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -539,12 +539,13 @@ static int checkout_paths(const struct checkout_opts *opts,
* recognized by diff-index), we will always replace the name
* with the hex of the commit (whether it's in `...` form or
* not) for the run_add_interactive() machinery to work
- * properly. However, there is special logic for the HEAD case
- * so we mustn't replace that. Also, when we were given a
- * tree-object, new_branch_info->commit would be NULL, but we
- * do not have to do any replacement, either.
+ * properly. However, there is special logic for the 'HEAD' and
+ * '@' case so we mustn't replace that. Also, when we were
+ * given a tree-object, new_branch_info->commit would be NULL,
+ * but we do not have to do any replacement, either.
*/
- if (rev && new_branch_info->commit && strcmp(rev, "HEAD"))
+ if (rev && new_branch_info->commit && strcmp(rev, "HEAD") &&
+ strcmp(rev, "@"))
rev = oid_to_hex_r(rev_oid, &new_branch_info->commit->object.oid);
if (opts->checkout_index && opts->checkout_worktree)
diff --git a/t/t2016-checkout-patch.sh b/t/t2016-checkout-patch.sh
index 747eb5563e..c4f9bf09aa 100755
--- a/t/t2016-checkout-patch.sh
+++ b/t/t2016-checkout-patch.sh
@@ -38,26 +38,32 @@ test_expect_success 'git checkout -p with staged changes' '
verify_state dir/foo index index
'
-test_expect_success 'git checkout -p HEAD with NO staged changes: abort' '
- set_and_save_state dir/foo work head &&
- test_write_lines n y n | git checkout -p HEAD &&
- verify_saved_state bar &&
- verify_saved_state dir/foo
-'
-
-test_expect_success 'git checkout -p HEAD with NO staged changes: apply' '
- test_write_lines n y y | git checkout -p HEAD &&
- verify_saved_state bar &&
- verify_state dir/foo head head
-'
-
-test_expect_success 'git checkout -p HEAD with change already staged' '
- set_state dir/foo index index &&
- # the third n is to get out in case it mistakenly does not apply
- test_write_lines n y n | git checkout -p HEAD &&
- verify_saved_state bar &&
- verify_state dir/foo head head
-'
+for opt in "HEAD" "@"
+do
+ test_expect_success "git checkout -p $opt with NO staged changes: abort" '
+ set_and_save_state dir/foo work head &&
+ test_write_lines n y n | git checkout -p $opt >output &&
+ verify_saved_state bar &&
+ verify_saved_state dir/foo &&
+ test_grep "Discard" output
+ '
+
+ test_expect_success "git checkout -p $opt with NO staged changes: apply" '
+ test_write_lines n y y | git checkout -p $opt >output &&
+ verify_saved_state bar &&
+ verify_state dir/foo head head &&
+ test_grep "Discard" output
+ '
+
+ test_expect_success "git checkout -p $opt with change already staged" '
+ set_state dir/foo index index &&
+ # the third n is to get out in case it mistakenly does not apply
+ test_write_lines n y n | git checkout -p $opt >output &&
+ verify_saved_state bar &&
+ verify_state dir/foo head head &&
+ test_grep "Discard" output
+ '
+done
test_expect_success 'git checkout -p HEAD^...' '
# the third n is to get out in case it mistakenly does not apply
diff --git a/t/t2071-restore-patch.sh b/t/t2071-restore-patch.sh
index b5c5c0ff7e..3dc9184b4a 100755
--- a/t/t2071-restore-patch.sh
+++ b/t/t2071-restore-patch.sh
@@ -44,13 +44,17 @@ test_expect_success PERL 'git restore -p with staged changes' '
verify_state dir/foo index index
'
-test_expect_success PERL 'git restore -p --source=HEAD' '
- set_state dir/foo work index &&
- # the third n is to get out in case it mistakenly does not apply
- test_write_lines n y n | git restore -p --source=HEAD &&
- verify_saved_state bar &&
- verify_state dir/foo head index
-'
+for opt in "HEAD" "@"
+do
+ test_expect_success PERL "git restore -p --source=$opt" '
+ set_state dir/foo work index &&
+ # the third n is to get out in case it mistakenly does not apply
+ test_write_lines n y n | git restore -p --source=$opt >output &&
+ verify_saved_state bar &&
+ verify_state dir/foo head index &&
+ test_grep "Discard" output
+ '
+done
test_expect_success PERL 'git restore -p --source=HEAD^' '
set_state dir/foo work index &&
diff --git a/t/t7105-reset-patch.sh b/t/t7105-reset-patch.sh
index 05079c7246..ec7f16dfb6 100755
--- a/t/t7105-reset-patch.sh
+++ b/t/t7105-reset-patch.sh
@@ -33,6 +33,16 @@ test_expect_success PERL 'git reset -p' '
test_grep "Unstage" output
'
+for opt in "HEAD" "@"
+do
+ test_expect_success PERL "git reset -p $opt" '
+ test_write_lines n y | git reset -p $opt >output &&
+ verify_state dir/foo work head &&
+ verify_saved_state bar &&
+ test_grep "Unstage" output
+ '
+done
+
test_expect_success PERL 'git reset -p HEAD^' '
test_write_lines n y | git reset -p HEAD^ >output &&
verify_state dir/foo work parent &&
--
2.43.0
^ permalink raw reply related
* [PATCH v2 1/2] add-patch: remove non-relevant NEEDSWORK comment
From: Ghanshyam Thakkar @ 2024-02-02 15:03 UTC (permalink / raw)
To: git; +Cc: gitster, ps, Ghanshyam Thakkar
In-Reply-To: <20240202150434.11256-1-shyamthakkar001@gmail.com>
The comment suggested to compare commit objects instead of string
comparison to 'HEAD' for supporting more ways of saying 'HEAD' (e.g.
'@'). However, this approach has unintended behavior of also counting a
non-checked out branch pointing to same commit as HEAD, as HEAD. This
would cause confusion to the user.
Junio described it best as[1]:
"Users may consider 'HEAD' and '@' the same and
may want them to behave the same way, but the user, when explicitly
naming '$branch', means they want to "check contents out of that
OTHER thing named '$branch', not the current branch"; it may or
may not happen to be pointing at the same commit as HEAD, but if
the user meant to say "check contents out of the current commit,
(partially) reverting the local changes I have", the user would have
said HEAD. After all, the user may not even be immediately aware
that '$branch' happens to point at the same commit as HEAD."
[1]: https://lore.kernel.org/git/xmqqmssohu69.fsf@gitster.g/
Signed-off-by: Ghanshyam Thakkar <shyamthakkar001@gmail.com>
---
add-patch.c | 8 --------
1 file changed, 8 deletions(-)
diff --git a/add-patch.c b/add-patch.c
index 79eda168eb..68f525b35c 100644
--- a/add-patch.c
+++ b/add-patch.c
@@ -1729,14 +1729,6 @@ int run_add_p(struct repository *r, enum add_p_mode mode,
if (mode == ADD_P_STASH)
s.mode = &patch_mode_stash;
else if (mode == ADD_P_RESET) {
- /*
- * NEEDSWORK: Instead of comparing to the literal "HEAD",
- * compare the commit objects instead so that other ways of
- * saying the same thing (such as "@") are also handled
- * appropriately.
- *
- * This applies to the cases below too.
- */
if (!revision || !strcmp(revision, "HEAD"))
s.mode = &patch_mode_reset_head;
else
--
2.43.0
^ permalink raw reply related
* [PATCH v2 0/2] add-patch: Support '@' as a synonym for 'HEAD'
From: Ghanshyam Thakkar @ 2024-02-02 15:03 UTC (permalink / raw)
To: git; +Cc: gitster, ps, Ghanshyam Thakkar
In-Reply-To: <20240128181202.986753-2-shyamthakkar001@gmail.com>
This patch series removes a non-relevant NEEDSWORK comment and addresses
disparity between '@' and 'HEAD' in patch mode for (checkout, restore,
reset) commands.
The removal of the NEEDSWORK comment and the '@' support are split into
different patches because the former is still up for discussion. And if
it is decided against, the NEEDSWORK comment can still go as it would not
be the desired solution anyway (described in the commit message).
Ghanshyam Thakkar (2):
add-patch: remove unnecessary NEEDSWORK comment
add-patch: classify '@' as a synonym for 'HEAD'
add-patch.c | 19 +++++++---------
builtin/checkout.c | 11 +++++-----
t/t2016-checkout-patch.sh | 46 ++++++++++++++++++++++-----------------
t/t2071-restore-patch.sh | 18 +++++++++------
t/t7105-reset-patch.sh | 10 +++++++++
5 files changed, 61 insertions(+), 43 deletions(-)
--
2.43.0
^ permalink raw reply
* Re: single-char options
From: Sergey Organov @ 2024-02-02 14:59 UTC (permalink / raw)
To: Martin Guy; +Cc: git
In-Reply-To: <0e88ac8ad60d2da689d0a308cc59a02d468bc15f.camel@gmail.com>
Martin Guy <martinwguy@gmail.com> writes:
> I'm sure this must have been thought of before and rejected, but us RSI
> sufferers would like to be able to say "git rebase -c" for "--continue"
> not only for speed and ease, but for all the other RSI sufferers out
> there.
I'm afraid you'll have hard time to bring *any* one-letter option into
core Git.
That said, an option here is to maintain suitable set of aliases,
probably contributed to Git to be easily installed, containing, say,
git config --global alias.re 'rebase'
git config --global alias.rc 'rebase --continue'
git config --global alias.ra 'rebase --abort'
etc.
HTH,
--
Sergey Organov
^ permalink raw reply
* Re: Migrate away from vger to GitHub or (on-premise) GitLab?
From: Sergey Organov @ 2024-02-02 14:49 UTC (permalink / raw)
To: Hans Meiser; +Cc: git@vger.kernel.org
In-Reply-To: <AS2P195MB2135D91EE464FF30EE84E77EE2432@AS2P195MB2135.EURP195.PROD.OUTLOOK.COM>
Hans Meiser <brille1@hotmail.com> writes:
> Hi,
>
> is there any current discussion about moving Git development away from
> using a mailing list to some modern form of collaboration?
Yes, now there is (again).
> I'd like to be able to follow a structured discussion in issues and to
> contribute to the Git documentation, but the mailing list currently
> just bloats my personal inbox with loads of uninteresting e-mails in
> an unstructured waterfall of messy discussion that I am not able to
> follow professionally.
Did you consider to rather read the list through
gmane.comp.version-control.git nntp newsgroup?
This way you get only very specific mails in your mail-box, those where
you are explicitly CC'ed, and you usually get more support for
structuring from NNTP readers than from mail clients.
HTH
--
Sergey Organov
^ permalink raw reply
* Re: single-char options
From: Kristoffer Haugsbakk @ 2024-02-02 14:42 UTC (permalink / raw)
To: Martin Guy; +Cc: git
In-Reply-To: <0e88ac8ad60d2da689d0a308cc59a02d468bc15f.camel@gmail.com>
On Fri, Feb 2, 2024, at 14:45, Martin Guy wrote:
> I'm sure this must have been thought of before and rejected, but us RSI
> sufferers would like to be able to say "git rebase -c" for "--continue"
> not only for speed and ease, but for all the other RSI sufferers out
> there.
>
> I mean, yes, I can implement them for myself (at least for the most
> common long ones) but wondere what the zeitgeist was on this issue - at
> least that way they would be the same letters for everybody.
>
> Thanks
>
> M
Magit is nice if you use Emacs. All interactions are a combination of
one-letter commands and one-letter options.
The CLI is too tedious to do everything in for me.
--
Kristoffer Haugsbakk
^ permalink raw reply
* single-char options
From: Martin Guy @ 2024-02-02 13:45 UTC (permalink / raw)
To: git
I'm sure this must have been thought of before and rejected, but us RSI
sufferers would like to be able to say "git rebase -c" for "--continue"
not only for speed and ease, but for all the other RSI sufferers out
there.
I mean, yes, I can implement them for myself (at least for the most
common long ones) but wondere what the zeitgeist was on this issue - at
least that way they would be the same letters for everybody.
Thanks
M
^ permalink raw reply
* Re: [PATCH v2 0/2] refs: introduce reftable backend
From: Karthik Nayak @ 2024-02-02 13:02 UTC (permalink / raw)
To: Patrick Steinhardt, git; +Cc: Junio C Hamano, Han-Wen Nienhuys
In-Reply-To: <cover.1706862705.git.ps@pks.im>
[-- Attachment #1: Type: text/plain, Size: 279 bytes --]
Hello,
Patrick Steinhardt <ps@pks.im> writes:
> Hi,
>
> this is the second version of my patch series that introduces the
> reftable backend.
>
The diff looks good to, apart from the tests (which I didn't get around
to reviewing), everything else looks great!
Thanks,
Karthik
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 690 bytes --]
^ permalink raw reply
* Re: Migrate away from vger to GitHub or (on-premise) GitLab?
From: Dragan Simic @ 2024-02-02 12:36 UTC (permalink / raw)
To: Michal Suchánek
Cc: phillip.wood, Patrick Steinhardt, brian m. carlson, Hans Meiser,
Konstantin Ryabitsev, git
In-Reply-To: <20240202115004.GV9696@kitsune.suse.cz>
On 2024-02-02 12:50, Michal Suchánek wrote:
> Given the open nature of lore it should be feasible to provide
> additional interfaces on top of it that cater to people used to PRs
> on popular forge web UIs without hijacking the whole project and the
> existing tools and interfaces. For some reason people are set on
> replacing it as a whole, and removing the interfaces they personally
> don't use, calling them obosolete.
>
> In a project with large numger of collaborators with varying
> backgrounds
> that's not going to work well. There are many people working on git
> using different workflows, and adding support for new workflow by
> removing a number of existing ones will cause problems. The goal of
> changing the forge software should be to be more open, supporting more
> users with more varying workflows and needs, not less.
Totally agreed. Augmenting the traditional interfaces and workflows,
instead of declaring them obsolete and killing them, should be the way
to go. Having different options available is always good.
^ permalink raw reply
* Re: Migrate away from vger to GitHub or (on-premise) GitLab?
From: Michal Suchánek @ 2024-02-02 11:50 UTC (permalink / raw)
To: phillip.wood
Cc: Patrick Steinhardt, brian m. carlson, Hans Meiser, Dragan Simic,
Konstantin Ryabitsev, git@vger.kernel.org
In-Reply-To: <0e3e6102-40eb-4462-b541-0c7452e79f42@gmail.com>
Hello,
On Fri, Feb 02, 2024 at 11:15:26AM +0000, Phillip Wood wrote:
> On 02/02/2024 05:10, Patrick Steinhardt wrote:
> > On Fri, Feb 02, 2024 at 01:44:03AM +0000, brian m. carlson wrote:
> > > On 2024-02-01 at 18:36:48, Hans Meiser wrote:
> > [snip]
> > > > In the end, it's all just about git. You may create your own git
> > > > webserver (https://git-scm.com/book/en/v2/Git-on-the-Server-GitWeb),
> > > > or just use an existing one, like the GitLab server:
> > > > https://about.gitlab.com/install/
> > >
> > > The Git project has tried for a long time to be neutral on any
> > > particular external piece of software. Installing a GitLab server as
> > > our preferred development platform would promote GitLab as the preferred
> > > forge to other users. Similarly, moving to GitHub would prefer GitHub
> > > over other forges. That's not a thing we want to do.
> > >
> > > We also don't accept patches or features for the benefit of one
> > > particular forge or external project. Patches and features must be
> > > of general benefit to the project at large.
> >
> > I think this point is indeed really important in the context of the Git
> > project.
>
> Agreed, thank you for making it brian. If we did decide to use a forge we'd
> need to be very clear in our decision making that it was selected based on
> the specific needs of this project and was not a general endorsement of one
> product over another. We'd also need to address the important practical
> problems of finding resources to maintain the infrastructure and software to
> run it.
In this context using lore is basically also a forge choice. It is built
on top of git, and expands the functionality of what the project git
repository alone provides.
Unlike most other forge software it is based completely on open
standards such as e-mail headers and git itself, very open and modular,
and does not in any way tie the project git repository to this
additional functionality provided by lore.
This open and separate nature of lore is what makes it the tool of
choice for Linux and git, and any forge that aims to replace lore should
aim at similar level of openness. Of the forges I am aware of only
sourcehut comes close in terms of planned functionality but it's nowhere
near completed as far as I am aware.
Given the open nature of lore it should be feasible to provide
additional interfaces on top of it that cater to people used to PRs
on popular forge web UIs without hijacking the whole project and the
existing tools and interfaces. For some reason people are set on
replacing it as a whole, and removing the interfaces they personally
don't use, calling them obosolete.
In a project with large numger of collaborators with varying backgrounds
that's not going to work well. There are many people working on git
using different workflows, and adding support for new workflow by
removing a number of existing ones will cause problems. The goal of
changing the forge software should be to be more open, supporting more
users with more varying workflows and needs, not less.
Thanks
Michal
^ permalink raw reply
* Re: [PATCH 3/3] rev-list: add --allow-missing-tips to be used with --missing=...
From: Christian Couder @ 2024-02-02 11:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Patrick Steinhardt, John Cai, Christian Couder
In-Reply-To: <xmqqo7d0x7fm.fsf@gitster.g>
On Thu, Feb 1, 2024 at 9:20 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> Christian Couder <christian.couder@gmail.com> writes:
>
> > In 9830926c7d (rev-list: add commit object support in `--missing`
> > option, 2023-10-27) we fixed the `--missing` option in `git rev-list`
> > so that it now works with commits too.
> >
> > Unfortunately, such a command would still fail with a "fatal: bad
> > object <oid>" if it is passed a missing commit, blob or tree as an
> > argument.
> >
> > When such a command is used to find the dependencies of some objects,
> > for example the dependencies of quarantined objects, it would be
> > better if the command would instead consider such missing objects,
> > especially commits, in the same way as other missing objects.
> >
> > If, for example `--missing=print` is used, it would be nice for some
> > use cases if the missing tips passed as arguments were reported in
> > the same way as other missing objects instead of the command just
> > failing.
> >
> > Let's introduce a new `--allow-missing-tips` option to make it work
> > like this.
>
> OK. Unlike a missing object referenced by a tree, a commit, or a
> tag, where the expected type of the missing object is known to Git,
> I would expect that nobody knowsn what type these missing objects at
> the tip have. So do we now require "object X missing" instead of
> "commit X missing" in the output? If we are not giving any type
> information even when we know what the type we expect is, then we do
> not have to worry about this change introducing a new output logic,
> I guess.
Yeah, we are not giving type information in the output, only a `?`
before the oid.
> > diff --git a/builtin/rev-list.c b/builtin/rev-list.c
> > index b3f4783858..ae7bb15478 100644
> > --- a/builtin/rev-list.c
> > +++ b/builtin/rev-list.c
> > @@ -562,6 +562,16 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)
> > break;
> > }
> > }
> > + for (i = 1; i < argc; i++) {
> > + const char *arg = argv[i];
> > + if (!strcmp(arg, "--allow-missing-tips")) {
> > + if (arg_missing_action == MA_ERROR)
> > + die(_("option '%s' only makes sense with '%s' set to '%s' or '%s'"),
> > + "--allow-missing-tips", "--missing=", "allow-*", "print");
> > + revs.do_not_die_on_missing_tips = 1;
> > + break;
> > + }
> > + }
>
> It is unfortunate that we need to add yet another dumb loop that
> does not even try to understand there may be an option whose value
> happens to be the string strcmp() looks for (we already have two
> such loops above this hunk). I have to wonder if we can do better.
I am also not happy with adding yet another dump loop like this. I did
it because I couldn't think of a simple solution to avoid that.
> An idle piece of idea. Perhaps we can instruct setup_revisions()
> not to die immediately upon seeing a problematic argument, marking
> the revs as "broken" instead, and keep going and interpreting as
> much as it could, so that it may record the presence of "--missing",
> "--exclude-promisor-objects", and "--allow-missing-tips". Then upon
> seeing setup_revisions() return with such an error, we can redo the
> call with these bits already on.
When we discussed rejecting some rev walking options before calling
setup_revisions() in the context of `git replay`, one thing people
seemed to agree on was that there should be a mechanism in
setup_revisions() that allows us to tell setup_revisions() which rev
walking options it should allow or not. I think that such a mechanism
might need an early parsing of options which could be reused for
options like `--exclude-promisor-objects`, `--missing=...` and
`--allow-missing-tips`. But I think adding such a mechanism does not
belong to this patch series. It's some cleanup and refactoring that we
might have needed for a long time already.
In my current version, I have added the following NEEDSWORK comment
before the three dump loops to make sure we remember about this:
/*
* NEEDSWORK: These dump loops to look for some options early
* are ugly. We really need setup_revisions() to have a
* mechanism to allow and disallow some sets of options for
* different commands (like rev-list, replay, etc). Such
* mechanism should do an early parsing of option and be able
* to manage the `--exclude-promisor-objects`, `--missing=...`
* and `--allow-missing-tips` options below.
*/
I have also added the following to the commit message:
"We introduce another dump loop to look for that options early, but
addressing the dump loops should likely be part of adding a new
mechanism to setup_revisions() which is a different topic. Anyway
let's add a big NEEDSWORK comment to remember that we really need to
do this."
> Anyway, I digress.
>
> > diff --git a/t/t6022-rev-list-missing.sh b/t/t6022-rev-list-missing.sh
> > index 527aa94f07..283e8fc2c2 100755
> > --- a/t/t6022-rev-list-missing.sh
> > +++ b/t/t6022-rev-list-missing.sh
> > @@ -77,4 +77,55 @@ do
> > done
> > done
> >
> > +for obj in "HEAD~1" "HEAD~1^{tree}" "HEAD:1.t"
> > +do
> > + for tip in "" "HEAD"
> > + do
> > + for action in "allow-any" "print"
> > + do
> > + test_expect_success "--missing=$action --allow-missing-tips with tip '$obj' missing and tip '$tip'" '
> > + oid="$(git rev-parse $obj)" &&
> > + path=".git/objects/$(test_oid_to_path $oid)" &&
> > +
> > + # Before the object is made missing, we use rev-list to
> > + # get the expected oids.
> > + if [ "$tip" = "HEAD" ]; then
>
> Style:
>
> if test "$tip" = "HEAD"
> then
Fixed in my current version. In it, I also fixed in patch 2/3 a
similar style typo in the tests before these ones.
> > + git rev-list --objects --no-object-names \
> > + HEAD ^$obj >expect.raw
> > + else
> > + >expect.raw
> > + fi &&
> > +
> > + # Blobs are shared by all commits, so even though a commit/tree
> > + # might be skipped, its blob must be accounted for.
> > + if [ "$tip" = "HEAD" ] && [ $obj != "HEAD:1.t" ]; then
>
> Ditto.
Fixed too in my current version.
> > + echo $(git rev-parse HEAD:1.t) >>expect.raw &&
> > + echo $(git rev-parse HEAD:2.t) >>expect.raw
> > + fi &&
> > +
> > + mv "$path" "$path.hidden" &&
> > + test_when_finished "mv $path.hidden $path" &&
> > +
> > + git rev-list --missing=$action --allow-missing-tips \
> > + --objects --no-object-names $oid $tip >actual.raw &&
> > +
> > + # When the action is to print, we should also add the missing
> > + # oid to the expect list.
> > + case $action in
> > + allow-any)
> > + ;;
> > + print)
> > + grep ?$oid actual.raw &&
> > + echo ?$oid >>expect.raw
> > + ;;
>
> OK. We do not say anything more than the object name (and the fact
> that it is missing with a single byte '?'), so my earlier worry was
> unfounded. Good.
>
> > + esac &&
> > +
> > + sort actual.raw >actual &&
> > + sort expect.raw >expect &&
> > + test_cmp expect actual
> > + '
> > + done
> > + done
> > +done
> > +
> > test_done
>
> THanks.
Thanks for the review!
^ permalink raw reply
* Re: [PATCH 3/3] rev-list: add --allow-missing-tips to be used with --missing=...
From: Christian Couder @ 2024-02-02 11:29 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Patrick Steinhardt, John Cai, Christian Couder,
Elijah Newren, Jeff Hostetler
In-Reply-To: <xmqqil37yix1.fsf@gitster.g>
On Thu, Feb 1, 2024 at 10:27 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> Christian Couder <christian.couder@gmail.com> writes:
>
> > When such a command is used to find the dependencies of some objects,
> > for example the dependencies of quarantined objects, it would be
> > better if the command would instead consider such missing objects,
> > especially commits, in the same way as other missing objects.
> >
> > If, for example `--missing=print` is used, it would be nice for some
> > use cases if the missing tips passed as arguments were reported in
> > the same way as other missing objects instead of the command just
> > failing.
> >
> > Let's introduce a new `--allow-missing-tips` option to make it work
> > like this.
>
> An obvious question is if this even needs to be a new option. What
> are expected use cases where --missing=print without this option is
> beneficial?
I am not sure if such a case is really beneficial but some
people/script/forges might rely on an error from `git rev-list
--missing=print` to propagate back an error to some user interface.
> If there is no plausible use case, perhaps we can treat
> it as a mere bugfix to the existing --missing mechanism, especially
> given that support of commits in "--missing" itself is relatively
> a new thing.
`--missing=...` detecting missing commits is new, but it might have
been used to find missing blobs or trees for some time as it exists
since:
caf3827e2f (rev-list: add list-objects filtering support, 2017-11-21)
> If we can do this as a bugfix that is always on when --missing is
> used, then we do not have to worry about adding another tasteless
> loop outside the main command line parser, which is a huge upside
> ;-).
Even if I very much dislike the tasteless loops, I'd rather not risk
user regressions by changing how `git rev-list --missing=...` handles
errors in the commits it is passed as arguments. See my other message
responding to your previous comments about how I'd prefer we handle
this.
^ permalink raw reply
* Muting and unmuting threads (Was: Migrate away from vger to GitHub or (on-premise) GitLab?)
From: Dragan Simic @ 2024-02-02 11:23 UTC (permalink / raw)
To: git
Cc: Konstantin Ryabitsev, Hans Meiser, Patrick Steinhardt,
brian m. carlson, rsbecker, Nico Williams, Kristoffer Haugsbakk,
Antonin Delpeuch, Phillip Wood
In-Reply-To: <c9a0cb1fe64f8e7d21c21458e5e76af9@manjaro.org>
Hello everyone,
I went ahead and contacted the mlmmj project, which runs the vger
mailing
lists, [1] with an idea to implement a new command/feature that allows
threads to be muted or unmuted. For example, that would allow receiving
only the replies to one's patch that was sent to a list.
The initial reactions are good, but various concerns have been raised
regarding the actual implementation. I'll think about the way to
implement
it in an efficient and simple way. I think this would make using
mailing
lists much more friendly to many users.
All suggestions and thoughts are welcome, of course.
[1] https://people.kernel.org/monsieuricon/subspace-mailing-list-server
On 2024-02-02 11:54, Dragan Simic wrote:
> On 2024-02-02 11:18, Hans Meiser wrote:
>>> Please keep in mind that editing the git man pages requires very
>>> intimate knowledge of the related git source code. Many times even
>>> small changes to the language style can change the meaning and
>>> diverge
>>> the man pages from the source code, making the man pages useless.
>>
>> Sure. Eventually, I'd rather propose to have parts of the man pages be
>> generated from code comments (XmlDoc, JsDoc or similar), particularly
>> syntax and parameter list. That would keep documentation from
>> deviating from code right from the beginning. And it would keep
>> documentation writers from manually updating obvious parts.
>
> That might work out in some places, but I'm not really sure about the
> overall effectiveness. The git man pages don't document function
> calls.
>
>>> A git server? I was under impression that you proposed running an
>>> own instance of GitLab or something similar.
>>
>> Basically, GitLab, GitHub, Azure DevOps are all just Git servers, plus
>> collaboration and automation functionality. I suggested using GitWeb
>> only in case you wanted to write (and keep control over)
>> collaboration and automation functionality yourself. Otherwise you may
>> use one of the existing ones that have already been written (i.e.,
>> GitLab, GitHub, Azure DevOps).
>
> The plus brings additional issues. It's been already noted that
> favoring
> any of those solutions actually wouldn't be in the interest of git
> itself
> as a project, because it wants to remain neutral.
>
> IMHO, these days too much is expected to be handled by "something
> else",
> instead of the developers handling that. It's like offloading the
> basically
> unavoidable complexity to some utility, and expecting that the
> complexity
> will somehow go away.
>
> In other words, a developer has to keep quite a lot in their short-term
> memory, and a lot in their long-term memory, to be able to accomplish
> some
> task, and hardly any utility is going to make that significantly
> easier.
> The same principle, in general, applies to a group of developers
> working
> on the same task.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox