|
|
|
|
GIT-BUILD-OPTIONS
|
|
|
|
|
GIT-CFLAGS
|
|
|
|
|
GIT-GUI-VARS
|
|
|
|
|
GIT-VERSION-FILE
|
|
|
|
|
git
|
|
|
|
|
git-add
|
git-add --interactive
A script to be driven when the user says "git add --interactive"
is introduced.
When it is run, first it runs its internal 'status' command to
show the current status, and then goes into its internactive
command loop.
The command loop shows the list of subcommands available, and
gives a prompt "What now> ". In general, when the prompt ends
with a single '>', you can pick only one of the choices given
and type return, like this:
*** Commands ***
1: status 2: update 3: revert 4: add untracked
5: patch 6: diff 7: quit 8: help
What now> 1
You also could say "s" or "sta" or "status" above as long as the
choice is unique.
The main command loop has 6 subcommands (plus help and quit).
* 'status' shows the change between HEAD and index (i.e. what
will be committed if you say "git commit"), and between index
and working tree files (i.e. what you could stage further
before "git commit" using "git-add") for each path. A sample
output looks like this:
staged unstaged path
1: binary nothing foo.png
2: +403/-35 +1/-1 git-add--interactive.perl
It shows that foo.png has differences from HEAD (but that is
binary so line count cannot be shown) and there is no
difference between indexed copy and the working tree
version (if the working tree version were also different,
'binary' would have been shown in place of 'nothing'). The
other file, git-add--interactive.perl, has 403 lines added
and 35 lines deleted if you commit what is in the index, but
working tree file has further modifications (one addition and
one deletion).
* 'update' shows the status information and gives prompt
"Update>>". When the prompt ends with double '>>', you can
make more than one selection, concatenated with whitespace or
comma. Also you can say ranges. E.g. "2-5 7,9" to choose
2,3,4,5,7,9 from the list. You can say '*' to choose
everything.
What you chose are then highlighted with '*', like this:
staged unstaged path
1: binary nothing foo.png
* 2: +403/-35 +1/-1 git-add--interactive.perl
To remove selection, prefix the input with - like this:
Update>> -2
After making the selection, answer with an empty line to
stage the contents of working tree files for selected paths
in the index.
* 'revert' has a very similar UI to 'update', and the staged
information for selected paths are reverted to that of the
HEAD version. Reverting new paths makes them untracked.
* 'add untracked' has a very similar UI to 'update' and
'revert', and lets you add untracked paths to the index.
* 'patch' lets you choose one path out of 'status' like
selection. After choosing the path, it presents diff between
the index and the working tree file and asks you if you want
to stage the change of each hunk. You can say:
y - add the change from that hunk to index
n - do not add the change from that hunk to index
a - add the change from that hunk and all the rest to index
d - do not the change from that hunk nor any of the rest to index
j - do not decide on this hunk now, and view the next
undecided hunk
J - do not decide on this hunk now, and view the next hunk
k - do not decide on this hunk now, and view the previous
undecided hunk
K - do not decide on this hunk now, and view the previous hunk
After deciding the fate for all hunks, if there is any hunk
that was chosen, the index is updated with the selected hunks.
* 'diff' lets you review what will be committed (i.e. between
HEAD and index).
This is still rough, but does everything except a few things I
think are needed.
* 'patch' should be able to allow splitting a hunk into
multiple hunks.
* 'patch' does not adjust the line offsets @@ -k,l +m,n @@
in the hunk header. This does not have major problem in
practice, but it _should_ do the adjustment.
* It does not have any explicit support for a merge in
progress; it may not work at all.
Signed-off-by: Junio C Hamano <junkio@cox.net>
18 years ago
|
|
|
git-add--interactive
|
|
|
|
|
git-am
|
|
|
|
|
git-annotate
|
|
|
|
|
git-apply
|
|
|
|
|
git-archimport
|
Add git-archive
git-archive is a command to make TAR and ZIP archives of a git tree.
It helps prevent a proliferation of git-{format}-tree commands.
Instead of directly calling git-{tar,zip}-tree command, it defines
a very simple API, that archiver should implement and register in
"git-archive.c". This API is made up by 2 functions whose prototype
is defined in "archive.h" file.
- The first one is used to parse 'extra' parameters which have
signification only for the specific archiver. That would allow
different archive backends to have different kind of options.
- The second one is used to ask to an archive backend to build
the archive given some already resolved parameters.
The main reason for making this API is to avoid using
git-{tar,zip}-tree commands, hence making them useless. Maybe it's
time for them to die ?
It also implements remote operations by defining a very simple
protocol: it first sends the name of the specific uploader followed
the repository name (git-upload-tar git://example.org/repo.git).
Then it sends options. It's done by sending a sequence of one
argument per packet, with prefix "argument ", followed by a flush.
The remote protocol is implemented in "git-archive.c" for client
side and is triggered by "--remote=<repo>" option. For example,
to fetch a TAR archive in a remote repo, you can issue:
$ git archive --format=tar --remote=git://xxx/yyy/zzz.git HEAD
We choose to not make a new command "git-fetch-archive" for example,
avoind one more GIT command which should be nice for users (less
commands to remember, keeps existing --remote option).
Signed-off-by: Franck Bui-Huu <vagabon.xyz@gmail.com>
Acked-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
|
|
|
git-archive
|
|
|
|
|
git-bisect
|
|
|
|
|
git-blame
|
|
|
|
|
git-branch
|
Add git-bundle: move objects and references by archive
Some workflows require use of repositories on machines that cannot be
connected, preventing use of git-fetch / git-push to transport objects and
references between the repositories.
git-bundle provides an alternate transport mechanism, effectively allowing
git-fetch and git-pull to operate using sneakernet transport. `git-bundle
create` allows the user to create a bundle containing one or more branches
or tags, but with specified basis assumed to exist on the target
repository. At the receiving end, git-bundle acts like git-fetch-pack,
allowing the user to invoke git-fetch or git-pull using the bundle file as
the URL. git-fetch and git-ls-remote determine they have a bundle URL by
checking that the URL points to a file, but are otherwise unchanged in
operation with bundles.
The original patch was done by Mark Levedahl <mdl123@verizon.net>.
It was updated to make git-bundle a builtin, and get rid of the tar
format: now, the first line is supposed to say "# v2 git bundle", the next
lines either contain a prerequisite ("-" followed by the hash of the
needed commit), or a ref (the hash of a commit, followed by the name of
the ref), and finally the pack. As a result, the bundle argument can be
"-" now.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
18 years ago
|
|
|
git-bundle
|
|
|
|
|
git-cat-file
|
Add basic infrastructure to assign attributes to paths
This adds the basic infrastructure to assign attributes to
paths, in a way similar to what the exclusion mechanism does
based on $GIT_DIR/info/exclude and .gitignore files.
An attribute is just a simple string that does not contain any
whitespace. They can be specified in $GIT_DIR/info/attributes
file, and .gitattributes file in each directory.
Each line in these files defines a pattern matching rule.
Similar to the exclusion mechanism, a later match overrides an
earlier match in the same file, and entries from .gitattributes
file in the same directory takes precedence over the ones from
parent directories. Lines in $GIT_DIR/info/attributes file are
used as the lowest precedence default rules.
A line is either a comment (an empty line, or a line that begins
with a '#'), or a rule, which is a whitespace separated list of
tokens. The first token on the line is a shell glob pattern.
The rest are names of attributes, each of which can optionally
be prefixed with '!'. Such a line means "if a path matches this
glob, this attribute is set (or unset -- if the attribute name
is prefixed with '!'). For glob matching, the same "if the
pattern does not have a slash in it, the basename of the path is
matched with fnmatch(3) against the pattern, otherwise, the path
is matched with the pattern with FNM_PATHNAME" rule as the
exclusion mechanism is used.
This does not define what an attribute means. Tying an
attribute to various effects it has on git operation for paths
that have it will be specified separately.
Signed-off-by: Junio C Hamano <junkio@cox.net>
18 years ago
|
|
|
git-check-attr
|
|
|
|
|
git-check-ref-format
|
|
|
|
|
git-checkout
|
|
|
|
|
git-checkout-index
|
|
|
|
|
git-cherry
|
|
|
|
|
git-cherry-pick
|
|
|
|
|
git-clean
|
|
|
|
|
git-clone
|
|
|
|
|
git-commit
|
|
|
|
|
git-commit-tree
|
|
|
|
|
git-config
|
|
|
|
|
git-count-objects
|
|
|
|
|
git-cvsexportcommit
|
|
|
|
|
git-cvsimport
|
|
|
|
|
git-cvsserver
|
|
|
|
|
git-daemon
|
|
|
|
|
git-diff
|
|
|
|
|
git-diff-files
|
|
|
|
|
git-diff-index
|
|
|
|
|
git-diff-tree
|
|
|
|
|
git-describe
|
|
|
|
|
git-fast-export
|
|
|
|
|
git-fast-import
|
|
|
|
|
git-fetch
|
|
|
|
|
git-fetch--tool
|
|
|
|
|
git-fetch-pack
|
|
|
|
|
git-filter-branch
|
|
|
|
|
git-fmt-merge-msg
|
|
|
|
|
git-for-each-ref
|
|
|
|
|
git-format-patch
|
|
|
|
|
git-fsck
|
|
|
|
|
git-fsck-objects
|
|
|
|
|
git-gc
|
|
|
|
|
git-get-tar-commit-id
|
|
|
|
|
git-grep
|
|
|
|
|
git-hash-object
|
|
|
|
|
git-help
|
|
|
|
|
git-http-fetch
|
|
|
|
|
git-http-push
|
|
|
|
|
git-imap-send
|
|
|
|
|
git-index-pack
|
|
|
|
|
git-init
|
|
|
|
|
git-init-db
|
|
|
|
|
git-instaweb
|
|
|
|
|
git-log
|
|
|
|
|
git-lost-found
|
|
|
|
|
git-ls-files
|
|
|
|
|
git-ls-remote
|
|
|
|
|
git-ls-tree
|
|
|
|
|
git-mailinfo
|
|
|
|
|
git-mailsplit
|
|
|
|
|
git-merge
|
|
|
|
|
git-merge-base
|
|
|
|
|
git-merge-index
|
|
|
|
|
git-merge-file
|
|
|
|
|
git-merge-tree
|
|
|
|
|
git-merge-octopus
|
|
|
|
|
git-merge-one-file
|
|
|
|
|
git-merge-ours
|
|
|
|
|
git-merge-recursive
|
|
|
|
|
git-merge-resolve
|
|
|
|
|
git-merge-subtree
|
|
|
|
|
git-mergetool
|
|
|
|
|
git-mktag
|
|
|
|
|
git-mktree
|
|
|
|
|
git-name-rev
|
|
|
|
|
git-mv
|
|
|
|
|
git-pack-redundant
|
|
|
|
|
git-pack-objects
|
|
|
|
|
git-pack-refs
|
|
|
|
|
git-parse-remote
|
|
|
|
|
git-patch-id
|
|
|
|
|
git-peek-remote
|
|
|
|
|
git-prune
|
|
|
|
|
git-prune-packed
|
|
|
|
|
git-pull
|
|
|
|
|
git-push
|
|
|
|
|
git-quiltimport
|
|
|
|
|
git-read-tree
|
|
|
|
|
git-rebase
|
|
|
|
|
git-rebase--interactive
|
|
|
|
|
git-receive-pack
|
|
|
|
|
git-reflog
|
|
|
|
|
git-relink
|
|
|
|
|
git-remote
|
|
|
|
|
git-repack
|
|
|
|
|
git-repo-config
|
|
|
|
|
git-request-pull
|
|
|
|
|
git-rerere
|
|
|
|
|
git-reset
|
|
|
|
|
git-rev-list
|
|
|
|
|
git-rev-parse
|
|
|
|
|
git-revert
|
|
|
|
|
git-rm
|
|
|
|
|
git-send-email
|
|
|
|
|
git-send-pack
|
|
|
|
|
git-sh-setup
|
|
|
|
|
git-shell
|
|
|
|
|
git-shortlog
|
|
|
|
|
git-show
|
|
|
|
|
git-show-branch
|
|
|
|
|
git-show-index
|
|
|
|
|
git-show-ref
|
|
|
|
|
git-stage
|
|
|
|
|
git-stash
|
|
|
|
|
git-status
|
|
|
|
|
git-stripspace
|
|
|
|
|
git-submodule
|
|
|
|
|
git-svn
|
|
|
|
|
git-symbolic-ref
|
|
|
|
|
git-tag
|
|
|
|
|
git-tar-tree
|
|
|
|
|
git-unpack-file
|
|
|
|
|
git-unpack-objects
|
|
|
|
|
git-update-index
|
|
|
|
|
git-update-ref
|
|
|
|
|
git-update-server-info
|
|
|
|
|
git-upload-archive
|
|
|
|
|
git-upload-pack
|
|
|
|
|
git-var
|
|
|
|
|
git-verify-pack
|
|
|
|
|
git-verify-tag
|
|
|
|
|
git-web--browse
|
|
|
|
|
git-whatchanged
|
|
|
|
|
git-write-tree
|
|
|
|
|
git-core-*/?*
|
|
|
|
|
gitk-wish
|
|
|
|
|
gitweb/gitweb.cgi
|
|
|
|
|
test-chmtime
|
|
|
|
|
test-ctype
|
|
|
|
|
test-date
|
|
|
|
|
test-delta
|
|
|
|
|
test-dump-cache-tree
|
|
|
|
|
test-genrandom
|
|
|
|
|
test-match-trees
|
|
|
|
|
test-parse-options
|
|
|
|
|
test-path-utils
|
|
|
|
|
test-sha1
|
chain kill signals for cleanup functions
If a piece of code wanted to do some cleanup before exiting
(e.g., cleaning up a lockfile or a tempfile), our usual
strategy was to install a signal handler that did something
like this:
do_cleanup(); /* actual work */
signal(signo, SIG_DFL); /* restore previous behavior */
raise(signo); /* deliver signal, killing ourselves */
For a single handler, this works fine. However, if we want
to clean up two _different_ things, we run into a problem.
The most recently installed handler will run, but when it
removes itself as a handler, it doesn't put back the first
handler.
This patch introduces sigchain, a tiny library for handling
a stack of signal handlers. You sigchain_push each handler,
and use sigchain_pop to restore whoever was before you in
the stack.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
16 years ago
|
|
|
test-sigchain
|
|
|
|
|
common-cmds.h
|
|
|
|
|
*.tar.gz
|
|
|
|
|
*.dsc
|
|
|
|
|
*.deb
|
|
|
|
|
git.spec
|
|
|
|
|
*.exe
|
|
|
|
|
*.[aos]
|
|
|
|
|
*.py[co]
|
|
|
|
|
config.mak
|
|
|
|
|
autom4te.cache
|
|
|
|
|
config.cache
|
|
|
|
|
config.log
|
|
|
|
|
config.status
|
|
|
|
|
config.mak.autogen
|
|
|
|
|
config.mak.append
|
|
|
|
|
configure
|
|
|
|
|
tags
|
|
|
|
|
TAGS
|
|
|
|
|
cscope*
|
