Paul Wise <pa...@bonedaddy.net> writes:
> It definitely wouldn't be appropriate to add screen scraping and
> parsing of different version control systems to myrepos.
Huh? If the tool claims to support VCS X and Y and Z, it needs to
know how to cause X and Y and Z to "fetch" in their own ways, and it
needs to know how X and Y and Z report what they have done.
The tool can choose to be lazy and not understand the outcome. But
then if the tool misbehaves because it does not know and care what
happened, don't come here blaming the underlying VCS. It is the
laziness of the tool that causes such a bug in the tool.
>> Having said all that, this time I read the change and the change
>> itself feels 40% sensible, even for those who do not care about
>> "myrepos" at all.
> All I want is for "Fetching remote" to not be printed when there are no
> changes fetched and I haven't used the --verbose option.
>
> I realise now that my patch is actually incorrect in that it also
> suppresses "Fetching remote" messages when some changes were fetched.
I actually think it makes things even worse. I can come up with a
justification for the change in your patch as posted (but with
reservations, aka "the last paragraph"), but not with such a
behaviour.
> I will come back with a correct patch that is better explained.
>
>> I'd sell it like the attached, if I were doing this patch. The last
>> paragraph is where the remaining 60% went ;-)
>
> Thanks, I will try to re-use that for the next patch.
>
>> Note that the current output was deliberately designed like this to
>> give an easy reminder for the user what the components of 'group'
>> are. With this change, we are selfishly and unilaterally breaking a
>> feature that was designed to help them, but if they strongly care,
>> they can complain and revert this change.
>
> To be honest I didn't know this group feature existed and I am
> surprised that anyone would want anything other than --all.
I admit that I do not care too deeply myself, but I do care about
existing users (and possibly tools) that expect the current output,
so if you are going to argue for discarding some information from
the output, I'd want to make sure that you understand what you are
discarding and how they are supposed to be used and how they are
useful.
Unfortunately I am not getting that sense from the above "I'll show
the message only for the ones that were updated".
The thing is, the story does not change an iota between --all and a
named group. Imagine you have three remotes X, Y and Z, and you
have a named group that contains all of them called G. These are
the same:
$ git fetch G
$ git fetch --all
Further imagine that only X has something new. Both of the above
would give you
$ git fetch --all ;# or G
Fetching X
From git://...
xxxxx..yyyyy master -> X/master
Fetching Y
Fetching Z
Remember that the user never said "X Y Z" from the command line; it
is because "--all" (and named group) is "once I configure, I do not
have to remember each and every one every time" mechanism. That is
the crucial point.
The above output shows that the command tried to fetch from X and Y
and Z, it got something interesting from X, *AND* it also shows that
Y and Z were unchanged. And this last part "Y and Z were unchanged"
is a useful information. If you do not give the last two lines, the
user _must_ remember that --all (or G) consists of X, Y and Z, in
order to infer that. That defeats the whole point of --all/group to
relieve the user from having to remember the set of remotes and
having to type them from the command line every time.
Contrast the following command sequence with the above:
$ git fetch X
From git://...
xxxxx..yyyyy master -> X/master
$ git fetch Y
$ git fetch Z
The responses from the command in the above sequence do not say
anything about Y and Z and that is totally sensible. The user
explicitly said Y (and Z), and the command did not say anything for
them--it is clear enough for the user to know Y (and Z) did not have
anything new.
So fetching from multiple repositories with "--all" or group cannot
be fundamentally "consistent" with the single remote case, if you do
not want to lose information.
One tangent worth noting is this. You can fetch from multiple
repositories that are explicitly named from the command line:
$ git fetch --multiple X Y
Fetching X
From git://...
xxxxx..yyyyy master -> X/master
Fetching Y
I do think that we do not need "Fetching Y" for this case, and I
actually think we shouldn't even say "Fetching X".
> I am not sure what the solution here is but perhaps the behaviour
> demonstrated below is acceptable to users of this feature:
I do not think so. It does not address the fact that it loses
information to throw away "Fetching ..." message for repositories
with nothing new at all. What gives us the right to break existing
users' expectations and force them to add --verbose on their command
line?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
