Skip to content

Conversation

@mjgallag
Copy link
Contributor

General items:

If your code changes how something works on the device (i.e., it affects the companion):

  • I branched from ucr
  • My pull request has ucr as the base

Further, if you've changed the blocks language or another user-facing designer/blocks API (added a SimpleProperty, etc.):

  • I have updated the corresponding version number in appinventor/components/src/.../common/YaVersion.java
  • I have updated the corresponding upgrader in appinventor/appengine/src/.../client/youngandroid/YoungAndroidFormUpgrader.java (components only)
  • I have updated the corresponding entries in appinventor/blocklyeditor/src/versioning.js

For all other changes:

  • I branched from master
  • My pull request has master as the base

@mjgallag mjgallag requested review from a team and josmas October 18, 2025 00:17
@ewpatton
Copy link
Member

@jisqyv You've had opinions about the gitignore file in the past. Do you want to weigh in here?

@jisqyv
Copy link
Member

jisqyv commented Oct 21, 2025

Yes. I'll say more in a few hours.

Copy link
Member

@jisqyv jisqyv left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was an explicit decision to check in sample-.gitignore instead of .gitignore. Some of us customize our .gitignore for various reasons, and having it checked in makes life a bit more complicated.

I opposed this change.

@mjgallag
Copy link
Contributor Author

Might we consider $GIT_DIR/info/exclude for that purpose?

Patterns which are specific to a particular repository but which do not need to be shared with other related repositories (e.g., auxiliary files that live inside the repository but are specific to one user’s workflow) should go into the $GIT_DIR/info/exclude file.
https://git-scm.com/docs/gitignore

@ewpatton
Copy link
Member

From my perspective, I think it would be good to establish a ground set of gitignore rules. Unfortunately, it seems like many intro courses around git like to teach git add ., which is fine for a homework assignment but introduces a whole bunch of cruft in a real world project like App Inventor. It would protect us from ginormous PRs that include all of the build directories, etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants