[Cuis-dev] FileList annoyance

Wed Mar 4 16:24:27 PST 2020

Here's what I've come up with (anyone with more extensive git knowledge
please read on and chime in with more/better information):

I have a full fork of https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
that I periodically sync via:

git fetch upstream; git checkout master; git merge upstream/master

I make sure I do this immediately before committing any of my own changes,
which I only do when I know I'm going to submit a pull request.  I then
push my changes to my personal repo on github and submit a pull request via
the github web UI.

I *think* what might have happened here is either that your shallow clone
caused git to think that my merges were something new (they weren't, they
were just your commits being folded back into my repo) or if it realized
that, when you did a regular git pull, it was going back and grabbing the
rest of the repo that your shallow clone didn't originally download.

The only things I've found so far related to duplicate commits revolves
around branches and the variety of ways that they can be handled via
squashing/cherry picking/rebasing.  But we're not doing any of that here:
we're just trying to add a few changed files to what should otherwise be
identical repos.  So what I'm wondering is, if there is an issue, was it
doing the shallow clone?  And if so what, if anything, should we do to
clean it up?

On Wed, Mar 4, 2020 at 3:44 PM Juan Vuletich <juan at jvuletich.org> wrote:

> I just clicked on the [merge] button in the GitHub web UI.
>
> Maybe (not sure!) in all previous merge requests from you I added the
> files 'by hand', not actually using the merge request, to avoid the bogus
> commits.
>
> And maybe (again not sure) the 490MiB were because I originally cloned the
> repo by doing `git clone --depth 1
> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev.git' as suggested in
> GettingStarted.md, to avoid fetching all the repo history. If this was the
> case, these kind of merge request forces other users to pull all the
> history on `git pull` even if not really needed.
>
> In any case, there should be some way to avoid the bogus commits.
>
> Thanks,
>
> --
> Juan Vuletichwww.cuis-smalltalk.orghttps://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Devhttps://github.com/jvuletichhttps://www.linkedin.com/in/juan-vuletich-75611b3
> @JuanVuletich
>
>
>
> On 3/4/2020 2:29 PM, Phil B via Cuis-dev wrote:
>
> That doesn't sound right... how did you do the merge?  (I don't doubt this
> is a problem since now when I look at the commit history on the main repo I
> see all my merge commits in there which I don't recall seeing after
> previous pull request merges)
>
> On Wed, Mar 4, 2020 at 11:02 AM Juan Vuletich <juan at jvuletich.org> wrote:
>
>> Hi Phil,
>>
>> On 2/26/2020 4:39 PM, Phil B via Cuis-dev wrote:
>>
>> Pull request submitted (there are a couple of impacted core packages)
>>
>>
>> Integrated. Thanks!
>>
>> As always, ignore all the commits (that's just me keeping in sync with
>> the main repo) and look at the diffs.
>>
>>
>> Still, after merge, doing 'git pull' in my machine fetched almost half a
>> gigabyte of stuff! In the future, can you please exclude all those commits
>> from the pull request? (No, I don't know how to do that. I don't know git
>> in such detail. But there must be a way. It doesn't make much sense for
>> everybody else to need to fetch 479MiB when all they want is a few KiB)
>>
>> Thanks,
>>
>>
>> Juans-MacBook-Pro:Cuis-Smalltalk juanvuletich$ cd Cuis-Smalltalk-Dev/
>> Juans-MacBook-Pro:Cuis-Smalltalk-Dev juanvuletich$ git pull
>> remote: Enumerating objects: 10179, done.
>> remote: Counting objects: 100% (9663/9663), done.
>> remote: Compressing objects: 100% (4950/4950), done.
>> remote: Total 9559 (delta 4626), reused 9486 (delta 4563), pack-reused 0
>> Receiving objects: 100% (9559/9559), 479.00 MiB | 10.33 MiB/s, done.
>> Resolving deltas: 100% (4626/4626), completed with 57 local objects.
>> From https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
>>    7e23a84..32e2f22  master     -> origin/master
>> Updating 7e23a84..32e2f22
>> Fast-forward
>>  CoreUpdates/
>> 4048-fileReaderServices-use-FileEntry-PhilBellalouna-2020Feb26-12h37m-pb.001.cs.st
>> | 325
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>  Packages/Features/Compression.pck.st
>> |  80 ++++++++++-----------
>>  Packages/Features/Wallpaper.pck.st
>> |   8 +--
>>  3 files changed, 369 insertions(+), 44 deletions(-)
>>  create mode 100644 CoreUpdates/
>> 4048-fileReaderServices-use-FileEntry-PhilBellalouna-2020Feb26-12h37m-pb.001.cs.st
>> Juans-MacBook-Pro:Cuis-Smalltalk-Dev juanvuletich$
>>
>> Thanks,
>> Phil
>>
>> On Wed, Feb 26, 2020 at 9:43 AM Juan Vuletich via Cuis-dev <
>> cuis-dev at lists.cuis.st> wrote:
>>
>>> Hi Phil,
>>>
>>> Feel free to replace Strings with FileEntries anywhere. It will be a
>>> great contribution. Those Strings are leftovers from before FileEntry.
>>>
>>> I'm sure there are plenty of places in need of cleanup. As we can't
>>> schedule anyone the task of cleaning up the system, we do it in small
>>> unplanned steps, anytime we find an annoyance and feel like cleaning it.
>>>
>>> On 2/25/2020 5:46 AM, Phil B via Cuis-dev wrote:
>>> > Here's something I've been meaning to fix for a while now: we have
>>> > FileList and the related #fileReaderServicesForFile:suffix: methods
>>> > (and in turn the methods they point to) which almost all have 'File'
>>> > in their name but then proceed to take and expect a string filename
>>> > rather than a FileEntry.  Would there be any objection to a changeset
>>> > that renames the vague *File* method names to *FileEntry* and actually
>>> > passes around FileEntry rather than String instances?  If anyone has a
>>> > problem with that and wants to keep using strings, then how about we
>>> > at least rename these methods from *File* to *Filename*?
>>>
>>> Thanks,
>>>
>>> --
>>> Juan Vuletich
>>> www.cuis-smalltalk.org
>>> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
>>> https://github.com/jvuletich
>>> https://www.linkedin.com/in/juan-vuletich-75611b3
>>> @JuanVuletich
>>>
>>> --
>>> Cuis-dev mailing list
>>> Cuis-dev at lists.cuis.st
>>> https://lists.cuis.st/mailman/listinfo/cuis-dev
>>>
>>
>>
>> --
>> Juan Vuletichwww.cuis-smalltalk.orghttps://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Devhttps://github.com/jvuletichhttps://www.linkedin.com/in/juan-vuletich-75611b3
>> @JuanVuletich
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20200304/f9866f27/attachment.htm>