to `git_config()`. Let's modify the code we wrote in the previous commit.
Be sure to include the header to allow you to use `struct wt_status`:
+
----
#include "wt-status.h"
----
====
Instead of using the shorthand `add_head_to_pending()`, you could do
something like this:
+
----
struct setup_revision_opt opt;
opt.revarg_opt = REVARG_COMMITTISH;
setup_revisions(argc, argv, rev, &opt);
----
+
Using a `setup_revision_opt` gives you finer control over your walk's starting
point.
====
- To follow the rules in CodingGuidelines, it's useful to put the following in
GIT_CHECKOUT/.dir-locals.el, assuming you use cperl-mode:
+
----
;; note the first part is useful for C editing, too
((nil . ((indent-tabs-mode . t)
------------
+
or:
++
------------
$ git bisect start --term-old broken --term-new fixed
$ git bisect fixed
For example, `--batch` without a custom format would produce:
-------------
+-----------
<oid> SP <type> SP <size> LF
<contents> LF
-------------
+-----------
Whereas `--batch-check='%(objectname) %(objecttype)'` would produce:
--------
In the examples, the following '.gitattributes' file is used:
+
---------------
*.java diff=java -crlf myAttr
NoMyAttr.java !myAttr
---------------
* Listing a single attribute:
++
---------------
$ git check-attr diff org/example/MyClass.java
org/example/MyClass.java: diff: java
---------------
* Listing multiple attributes for a file:
++
---------------
$ git check-attr crlf diff myAttr -- org/example/MyClass.java
org/example/MyClass.java: crlf: unset
---------------
* Listing all attributes for a file:
++
---------------
$ git check-attr --all -- org/example/MyClass.java
org/example/MyClass.java: diff: java
---------------
* Listing an attribute for multiple files:
++
---------------
$ git check-attr myAttr -- org/example/MyClass.java org/example/NoMyAttr.java
org/example/MyClass.java: myAttr: set
---------------
* Not all values are equally unambiguous:
++
---------------
$ git check-attr caveat README
README: caveat: unspecified
--------
Format data by columns:
++
------------
$ seq 1 24 | git column --mode=column --padding=5
1 4 7 10 13 16 19 22
------------
Format data by rows:
++
------------
$ seq 1 21 | git column --mode=row --padding=5
1 2 3 4 5 6 7
------------
List some tags in a table with unequal column widths:
++
------------
$ git tag --list 'v2.4.*' --column=row,dense
v2.4.0 v2.4.0-rc0 v2.4.0-rc1 v2.4.0-rc2 v2.4.0-rc3
pwhash in NetBSD) and paste it in the right location.
Then provide your password via the pserver method, for example:
+
------
cvs -d:pserver:someuser:somepassword@server:/path/repo.git co <HEAD_name>
------
+
No special setup is needed for SSH access, other than having Git tools
in the PATH. If you have clients that do not accept the CVS_SERVER
environment variable, you can rename 'git-cvsserver' to `cvs`.
------
cvs -d ":ext;CVS_SERVER=git cvsserver:user@server/path/repo.git" co <HEAD_name>
------
+
This has the advantage that it will be saved in your 'CVS/Root' files and
you don't need to worry about always setting the correct environment
variable. SSH users restricted to 'git-shell' don't need to override the default
access. Valid method names are "ext" (for SSH access) and "pserver". The
following example configuration would disable pserver access while still
allowing access over SSH.
+
------
[gitcvs]
enabled=0
A simple example showing the use of shell eval on the output,
demonstrating the use of --shell. List the prefixes of all heads:
+
------------
#!/bin/sh
A bit more elaborate report on tags, demonstrating that the format
may be an entire script:
+
------------
#!/bin/sh
To reproduce the entire p4 history in Git, use the '@all' modifier on
the depot path:
+
------------
$ git p4 clone //depot/path/project@all
------------
~~~~
As development continues in the p4 repository, those changes can
be included in the Git repository using:
+
------------
$ git p4 sync
------------
+
This command finds new changes in p4 and imports them as Git commits.
P4 repositories can be added to an existing Git repository using
'git p4 sync' too:
+
------------
$ mkdir repo-git
$ cd repo-git
$ git init
$ git p4 sync //path/in/your/perforce/depot
------------
+
This imports the specified depot into
'refs/remotes/p4/master' in an existing Git repository. The
`--branch` option can be used to specify a different branch to
is the ultimate location for all code, thus a rebase workflow makes
sense. This command does 'git p4 sync' followed by 'git rebase' to move
local commits on top of updated p4 changes.
+
------------
$ git p4 rebase
------------
To submit all changes that are in the current Git branch but not in
the 'p4/master' branch, use:
+
------------
$ git p4 submit
------------
To specify a branch other than the current one, use:
+
------------
$ git p4 submit topicbranch
------------
To specify a single commit or a range of commits, use:
+
------------
$ git p4 submit --commit <sha1>
$ git p4 submit --commit <sha1..sha1>
subdirectories in p4, and to generate these as branches in Git.
For example, if the P4 repository structure is:
+
----
//depot/main/...
//depot/branch1/...
----
And "p4 branch -o branch1" shows a View line that looks like:
+
----
//depot/main/... //depot/branch1/...
----
Then this 'git p4 clone' command:
+
----
git p4 clone --detect-branches //depot@all
----
+
produces a separate branch in 'refs/remotes/p4/' for //depot/main,
called 'master', and one for //depot/branch1 called 'depot/branch1'.
the path elements in the p4 repository. The example above relied on the
presence of the p4 branch. Without p4 branches, the same result will
occur with:
+
----
git init depot
cd depot
changes that are already present in the new upstream (unless
`--reapply-cherry-picks` is given). So if you say
(assuming you're on 'topic')
+
------------
$ git rebase subsystem
------------
you will end up with the fixed history
+
------------
o---o---o---o---o---o---o---o master
\
You can then transplant the old `subsystem..topic` to the new tip by
saying (for the reflog case, and assuming you are on 'topic' already):
+
------------
$ git rebase --onto subsystem subsystem@{1}
------------
final flush packet. Also note that the "value" of a "key=value" pair
can contain the "=" character whereas the key would never contain
that character.
-------------------------
+
+-----------------------
packet: git> command=smudge
packet: git> pathname=path/testfile.dat
packet: git> 0000
packet: git> CONTENT
packet: git> 0000
-------------------------
+-----------------------
The filter is expected to respond with a list of "key=value" pairs
terminated with a flush packet. If the filter does not experience
If the result content is empty then the filter is expected to respond
with a "success" status and a flush packet to signal the empty content.
+
------------------------
packet: git< status=success
packet: git< 0000
In case the filter cannot or does not want to process the content,
it is expected to respond with an "error" status.
-------------------------
+
+-----------------------
packet: git< status=error
packet: git< 0000
-------------------------
+-----------------------
If the filter experiences an error during processing, then it can
send the status "error" after the content was (partially or
completely) sent.
+
------------------------
packet: git< status=success
packet: git< 0000
as well as any future content for the lifetime of the Git process,
then it is expected to respond with an "abort" status at any point
in the protocol.
-------------------------
+
+-----------------------
packet: git< status=abort
packet: git< 0000
-------------------------
+-----------------------
Git neither stops nor restarts the filter process in case the
"error"/"abort" status is set. However, Git sets its exit code
denotes that the filter can delay filtering the current blob (e.g. to
compensate network latencies) by responding with no content but with
the status "delayed" and a flush packet.
-------------------------
+
+-----------------------
packet: git> command=smudge
packet: git> pathname=path/testfile.dat
packet: git> can-delay=1
packet: git> 0000
packet: git< status=delayed
packet: git< 0000
-------------------------
+-----------------------
If the filter supports the "delay" capability then it must support the
"list_available_blobs" command. If Git sends this command, then the
packet: git< 0000
------------------------
+
After Git received the pathnames, it will request the corresponding
blobs again. These requests contain a pathname and an empty content
section. The filter is expected to respond with the smudged content
in the usual way as explained above.
+
------------------------
packet: git> command=smudge
packet: git> pathname=path/testfile.dat
However, this is *NOT* allowed for switches with an optional value, where the
'stuck' form must be used:
+
----------------------------
$ git describe --abbrev HEAD # correct
$ git describe --abbrev=10 HEAD # correct
$ git describe --abbrev 10 HEAD # NOT WHAT YOU MEANT
----------------------------
-
NOTES ON FREQUENTLY CONFUSED OPTIONS
------------------------------------
ABNF notation as described by RFC 5234 is used within the protocol documents,
except the following replacement core rules are used:
+
----
HEXDIG = DIGIT / "a" / "b" / "c" / "d" / "e" / "f"
----
We also define the following common rules:
+
----
NUL = %x00
zero-id = 40*"0"
"Generating projects list using gitweb" section below.
Example contents:
+
-----------------------------------------------------------------------
foo.git Joe+R+Hacker+<joe@example.com>
foo/bar.git O+W+Ner+<owner@example.org>
We assume that GITWEB_CONFIG has its default Makefile value, namely
'gitweb_config.perl'. Put the following in 'gitweb_make_index.perl' file:
+
----------------------------------------------------------------------------
read_config_file("gitweb_config.perl");
$projects_list = $projectroot;
If you use the rewrite rules from the example you *might* also need
something like the following in your gitweb configuration file
(`/etc/gitweb.conf` following example):
+
----------------------------------------------------------------------------
@stylesheets = ("/some/absolute/path/gitweb.css");
$my_uri = "/";
$home_link = "/";
$per_request_config = 1;
----------------------------------------------------------------------------
+
Nowadays though gitweb should create HTML base tag when needed (to set base
URI for relative links), so it should work automatically.
The virtual host configuration (in Apache configuration file) should look
like this:
+
--------------------------------------------------------------------------
<VirtualHost *:80>
ServerName git.example.org
Here actual project root is passed to gitweb via `GITWEB_PROJECT_ROOT`
environment variable from a web server, so you need to put the following
line in gitweb configuration file (`/etc/gitweb.conf` in above example):
+
--------------------------------------------------------------------------
$projectroot = $ENV{'GITWEB_PROJECTROOT'} || "/pub/git";
--------------------------------------------------------------------------
+
*Note* that this requires to be set for each request, so either
`$per_request_config` must be false, or the above must be put in code
referenced by `$per_request_config`;
PATH_INFO usage
~~~~~~~~~~~~~~~
If you enable PATH_INFO usage in gitweb by putting
+
----------------------------------------------------------------------------
$feature{'pathinfo'}{'default'} = [1];
----------------------------------------------------------------------------
+
in your gitweb configuration file, it is possible to set up your server so
that it consumes and produces URLs in the form
</Directory>
</VirtualHost>
----------------------------------------------------------------------------
+
The rewrite rule guarantees that existing static files will be properly
served, whereas any other URL will be passed to gitweb as PATH_INFO
parameter.
following: in your project root dir (e.g. `/pub/git`) have the projects
named *without* a .git extension (e.g. `/pub/git/project` instead of
`/pub/git/project.git`) and configure Apache as follows:
+
----------------------------------------------------------------------------
<VirtualHost *:80>
ServerAlias git.example.com
Each `%feature` hash element is a hash reference and has the following
structure:
+
----------------------------------------------------------------------
"<feature-name>" => {
"sub" => <feature-sub-(subroutine)>,
Some features cannot be overridden per project. For those
features the structure of appropriate `%feature` hash element has a simpler
form:
+
----------------------------------------------------------------------
"<feature-name>" => {
"override" => 0,
In the following, we will always refer to the same example history to
illustrate the differences between simplification settings. We assume
that you are filtering for a file `foo` in this commit graph:
+
-----------------------------------------------------------------------
.-A---M---N---O---P---Q
/ / / / / /
\ / / / / /
`-------------' X
-----------------------------------------------------------------------
+
The horizontal line of history A---Q is taken to be the first parent of
each merge. The commits are:
projects / rit / commitdiff