2015-04-11 18:20:07 +00:00
|
|
|
# git ls-files --others --exclude-from=.git/info/exclude
|
|
|
|
|
# Lines that start with '#' are comments.
|
|
|
|
|
# For a project mostly in C, the following would be a good set of
|
|
|
|
|
# exclude patterns (uncomment them if you want to use them):
|
|
|
|
|
# *.[oa]
|
|
|
|
|
# *~
|
|
|
|
|
|
|
|
|
|
# See .gitignore in subdirectories for more ignored files
|
|
|
|
|
|
|
|
|
|
*~
|
|
|
|
|
*.[oadi]
|
2015-04-12 04:22:59 +00:00
|
|
|
*.gz
|
2015-04-11 18:20:07 +00:00
|
|
|
*.ii
|
|
|
|
|
*.oo
|
|
|
|
|
*.eo
|
|
|
|
|
*.so
|
|
|
|
|
*.exports
|
|
|
|
|
*.moduleinfo
|
|
|
|
|
*.makeopts
|
|
|
|
|
*.makedeps
|
|
|
|
|
.lastclean
|
2018-01-11 14:09:04 +00:00
|
|
|
/.pc
|
2015-04-14 00:06:46 +00:00
|
|
|
aclocal.m4
|
|
|
|
|
autom4te.cache
|
2015-04-11 18:20:07 +00:00
|
|
|
config.log
|
|
|
|
|
config.status
|
|
|
|
|
defaults.h
|
2015-04-14 00:06:46 +00:00
|
|
|
makeopts
|
2015-04-11 18:20:07 +00:00
|
|
|
makeopts.embed_rules
|
|
|
|
|
menuselect-tree
|
2015-04-15 21:08:09 +00:00
|
|
|
*.sha1
|
|
|
|
|
*.pyc
|
2015-04-22 21:32:53 +00:00
|
|
|
*.gcno
|
|
|
|
|
*.gcda
|
2015-05-07 19:54:35 +00:00
|
|
|
latex
|
|
|
|
|
doxygen.log
|
2016-02-25 16:29:05 +00:00
|
|
|
out/
|
2018-05-09 14:30:41 +00:00
|
|
|
*.orig
|
2018-07-11 11:14:49 +00:00
|
|
|
tests/CI/output
|
build: Refactor the earlier "basebranch" commit
Recap from earlier commit: If you have a development branch for a
major project that will receive gerrit reviews it'll probably be
named something like "development/16/newproject" or a work branch
based on that "development" branch. That will necessitate
setting "defaultbranch=development/16/newproject" in .gitreview.
The make_version script uses that variable to construct the
asterisk version however, which results in versions
like "GIT-development/16/newproject-ee582a8c7b" which is probably
not what you want. It also constructs the URLs for downloading
external modules with that version, which will fail.
Fast-forward:
The earlier attempt at adding a "basebranch" variable to
.gitreview didn't work out too well in practice because changes
were made to .gitreview, which is a checked-in file. So, if
you wanted to rebase your work branch on the base branch, rebase
would attempt to overwrite your .gitreview with the one from
the base branch and complain about a conflict.
This is a slighltly different approach that adds three methods to
determine the mainline branch:
1. --- MAINLINE_BRANCH from the environment
If MAINLINE_BRANCH is already set in the environment, that will
be used. This is primarily for the Jenkins jobs.
2. --- .develvars
Instead of storing the basebranch in .gitreview, it can now be
stored in a non-checked-in ".develvars" file and keyed by the
current branch. So, if you were working on a branch named
"new-feature-work" based on "development/16/new-feature" and wanted
to push to that branch in Gerrit but wanted to pull the external
modules for 16, you'd create the following .develvars file:
[branch "new-feature-work"]
mainline-branch = 16
The .gitreview file would still look like:
[gerrit]
defaultbranch=development/16/new-feature
...which would cause any reviews pushed from "new-feature-work" to
go to the "development/16/new-feature" branch in Gerrit.
The key is that the .develvars file is NEVER checked in (it's been
added to .gitignore).
3. --- Well Known Development Branch
If you're actually working in a branch named like
"development/<mainline_branch>/some-feature", the mainline branch
will be parsed from it.
4. --- .gitreview
If none of the earlier conditions exist, the .gitreview
"defaultbranch" variable will be used just as before.
Change-Id: I1cdeeaa0944bba3f2e01d7a2039559d0c266f8c9
2022-02-17 16:26:46 +00:00
|
|
|
.develvars
|
