Lines Matching refs:to
9 older than version 1.4.4, then you'd do well to get a newer version.
26 dating back to 1991. The repository (the part you download, and which
28 don't want to download it more often than necessary. Once downloaded,
35 If you *have* made changes and mistakenly committed them to "master",
36 do the following to put your changes on a private branch, "br", and
37 to restore master to its unmodified (relative-to-upstream) state:
49 authorship. That is important not just to give credit where due, but
63 First of all, realize that to "commit" a change in git is a purely
68 need to tell git about it with "git add new-file.c". Commit all changes
75 changes. Use this command to save that single, most-recent change set:
82 When you "pull" from a remote repository to get the latest, your local
84 may want to keep "master" free of any local changes, so that you can
85 use it to track unadulterated upstream sources.
88 you're going to remove it right afterwards, then this approach is fine.
106 To get back to the trunk, do this:
111 Be careful to run "git pull" only when on the "master" branch,
113 trouble if you forget, so this is a good reason to ensure you're
117 It's best not to try to switch from one branch to another if
120 modifications conflict with changes required to switch branches.
122 Run "git stash" to temporarily hide uncommitted changes in your
133 Personally, no matter what package I'm working on, I find it useful to
135 I plan to commit/push right away. Otherwise, I tend to get unnecessary
145 then see that someone else changed something and pushed it to the
146 public repository. Now, you want to update your trunk and "rebase"
147 your changes on the branch so that they are once again relative to the
148 tip of the trunk. Currently, your branch is attached to the trunk at
149 the next-to-last change set.
157 Now, return to your branch, and "rebase" relative to trunk (master):
166 file, and instruct you to resolve it and then resume with
171 That will fail, with a diagnostic telling you to mark
181 Once it finishes, your changes on the branch are now relative to
191 It's easy to adjust:
219 to write a few lines of prose describing the change, when the summary
221 leading TABs that you're used to seeing in a "real" ChangeLog file, but
228 Try to make the summary line fit one of the following forms:
237 If your commit fixes a bug, try to find the commit that introduced that
243 Note that we used to use an 8-byte SHA1 prefix like "54cbe6e6", because
253 This ensures that it is trivially easy to identify a single-*statement* loop:
263 add braces. Otherwise, it would be too easy to insert a statement just
286 It is safe to omit the braces in the code above, since the
325 few lines long, because it is easier to read and grasp the semantics of
386 Send patches to the address listed in --help output
400 you shouldn't need to change anything under man/. User-visible changes
413 [I hesitate to write this one down, because it appears to be an
415 (if not truly backwards) to nearly anyone who doesn't have a strong
427 Be nice to translators
441 If you add a feature, add tests to exercise as much of the new code
442 as possible. If you add a new test file (as opposed to adding a test to
443 an existing test file) add the new test file to 'tests/local.mk'.
444 Note to run tests/misc/new-test in isolation you can do:
464 examples of running the tool to demonstrate the new or changed feature,
472 then you'll have to have a copyright assignment on file with the FSF.
474 and then the exchange (FSF to you, then back) of an actual sheet of paper
478 The forms to choose from are in gnulib's doc/Copyright/ directory.
479 If you want to assign a single change, you should use the file,
484 If you would like to assign past and future contributions to a project,
489 You may make assignments for up to four projects at a time.
504 unless you have a reasonably up to date installation including recent
512 induce no change in indentation. Try not to add any more.
522 will alert you if you slip up, it's better to nip any problem in the
523 bud, as you're typing. A good way to help you adapt to this rule is
524 to configure your editor to highlight any offending characters in the
530 If you use vim, add this to ~/.vimrc:
538 add trailing blanks. The example pre-commit hook contains code to check
540 to the right place and making sure it is executable:
552 Git also has some settings to enable suitable internal whitespace checks.
563 * git log: to get most of the same info in text form
565 * git log -p SOME_FILE: same as above, but limit to SOME_FILE
569 change set, in a format suitable to be submitted and/or applied via
571 * git reset --soft HEAD^: Commit the delta required to restore
572 state to the revision just before HEAD (i.e., next-to-last).
578 it's no longer reachable by any branch, you can use "git fsck" to find
588 you could run "git show 556fbb57216b119" to examine the change set,
589 or "git checkout -b found 556fbb5721" to give it a branch name.
591 to put that change on the tip of "master".
595 Finding things to do
597 If you don't know where to start, check out the TODO file for projects
599 option is always to improve tests. You never know what you might
601 any bugs your contribution is sure to be appreciated.
603 A good way to quickly assess current test coverage, for standard
604 and root only tests, is to follow these steps (requires lcov to be installed):
621 Permission is granted to copy, distribute and/or modify this document