Dumps the internal marks table to <file> when complete.
Marks are written one per line as `:markid SHA-1`.
Frontends can use this file to validate imports after they
- have been completed.
+ have been completed, or to save the marks table across
+ incremental runs. As <file> is only opened and truncated
+ at checkpoint (or completion) the same path can also be
+ safely given to \--import-marks.
+
+--import-marks=<file>::
+ Before processing any input, load the marks specified in
+ <file>. The input file must exist, must be readable, and
+ must use the same format as produced by \--export-marks.
+ Multiple options may be supplied to import more than one
+ set of marks. If a mark is defined to different values,
+ the last file wins.
--export-pack-edges=<file>::
After creating a packfile, print a line of data to
In both formats `<path>` is the complete path of the file to be added
(if not already existing) or modified (if already existing).
- A `<path>` string must use UNIX-style directory seperators (forward
+ A `<path>` string must use UNIX-style directory separators (forward
slash `/`), may contain any byte other than `LF`, and must not
start with double quote (`"`).
The value of `<path>` must be in canoncial form. That is it must not:
* contain an empty directory component (e.g. `foo//bar` is invalid),
- * end with a directory seperator (e.g. `foo/` is invalid),
- * start with a directory seperator (e.g. `/foo` is invalid),
+ * end with a directory separator (e.g. `foo/` is invalid),
+ * start with a directory separator (e.g. `/foo` is invalid),
* contain the special component `.` or `..` (e.g. `foo/./bar` and
`foo/../bar` are invalid).
below. Commits are shown as "o", and the links between them with
lines drawn with - / and \. Time goes left to right:
+
+ ................................................
o--o--o <-- Branch A
/
o--o--o <-- master
\
o--o--o <-- Branch B
+ ................................................
If we need to talk about a particular commit, the character "o" may
be replaced with another letter or number.
$ cat .git/config
...
[remote "linux-nfs"]
- url = git://linux-nfs.org/~bfields/git.git
- fetch = +refs/heads/*:refs/remotes/linux-nfs-read/*
+ url = git://linux-nfs.org/pub/nfs-2.6.git
+ fetch = +refs/heads/*:refs/remotes/linux-nfs/*
...
-------------------------------------------------
branch--then you are warned; the output may look something like this:
-------------------------------------------------
- $ git pull . next
- Trying really trivial in-index merge...
- fatal: Merge requires file-level merging
- Nope.
- Merging HEAD with 77976da35a11db4580b80ae27e8d65caf5208086
- Merging:
- 15e2162 world
- 77976da goodbye
- found 1 common ancestor(s):
- d122ed4 initial
- Auto-merging file.txt
+ $ git merge next
+ 100% (4/4) done
+ Auto-merged file.txt
CONFLICT (content): Merge conflict in file.txt
Automatic merge failed; fix conflicts and then commit the result.
-------------------------------------------------
gitlink:git-show[1]:
-------------------------------------------------
- $ git show HEAD^ path/to/file
+ $ git show HEAD^:path/to/file
-------------------------------------------------
which will display the given version of the file.
You have performed no merges into mywork, so it is just a simple linear
sequence of patches on top of "origin":
-
+ ................................................
o--o--o <-- origin
\
o--o--o <-- mywork
+ ................................................
Some more interesting work has been done in the upstream project, and
"origin" has advanced:
+ ................................................
o--o--O--o--o--o <-- origin
\
a--b--c <-- mywork
+ ................................................
At this point, you could use "pull" to merge your changes back in;
the result would create a new merge commit, like this:
-
+ ................................................
o--o--O--o--o--o <-- origin
\ \
a--b--c--m <-- mywork
+ ................................................
However, if you prefer to keep the history in mywork a simple series of
commits without any merges, you may instead choose to use
patches to the new mywork. The result will look like:
+ ................................................
o--o--O--o--o--o <-- origin
\
a'--b'--c' <-- mywork
+ ................................................
In the process, it may discover conflicts. In that case it will stop
and allow you to fix the conflicts; after fixing conflicts, use "git
with merging. Suppose somebody fetches your branch and merges it into
their branch, with a result something like this:
+ ................................................
o--o--O--o--o--o <-- origin
\ \
t--t--t--m <-- their branch:
+ ................................................
Then suppose you modify the last three commits:
+ ................................................
o--o--o <-- new head of origin
/
o--o--O--o--o--o <-- old head of origin
+ ................................................
If we examined all this history together in one repository, it will
look like:
+ ................................................
o--o--o <-- new head of origin
/
o--o--O--o--o--o <-- old head of origin
\ \
t--t--t--m <-- their branch:
+ ................................................
Git has no way of knowing that the new head is an updated version of
the old head; it treats this situation exactly the same as it would if
A fast forward looks something like this:
+ ................................................
o--o--o--o <-- old head of the branch
\
o--o--o <-- new head of the branch
+ ................................................
In some cases it is possible that the new head will *not* actually be
realized she made a serious mistake, and decided to backtrack,
resulting in a situation like:
+ ................................................
o--o--o--o--a--b <-- old head of the branch
\
o--o--o <-- new head of the branch
-
-
+ ................................................
In this case, "git fetch" will fail, and print out a warning.
$ git-merge-index git-merge-one-file hello.c
-------------------------------------------------
-and that is what higher level `git resolve` is implemented with.
+and that is what higher level `git merge -s resolve` is implemented with.
How git stores objects efficiently: pack files
----------------------------------------------
goto rollback;
}
- if (!strncmp(oldref, "refs/heads/", 11) &&
- !strncmp(newref, "refs/heads/", 11)) {
+ if (!prefixcmp(oldref, "refs/heads/") &&
+ !prefixcmp(newref, "refs/heads/")) {
char oldsection[1024], newsection[1024];
snprintf(oldsection, 1024, "branch.%s", oldref + 11);
log_file = git_path("logs/%s", ref_name);
if (log_all_ref_updates &&
- (!strncmp(ref_name, "refs/heads/", 11) ||
- !strncmp(ref_name, "refs/remotes/", 13) ||
+ (!prefixcmp(ref_name, "refs/heads/") ||
+ !prefixcmp(ref_name, "refs/remotes/") ||
!strcmp(ref_name, "HEAD"))) {
if (safe_create_leading_directories(log_file) < 0)
return error("unable to create directory for %s",
log_file, strerror(errno));
}
+ adjust_shared_perm(log_file);
+
msglen = 0;
if (msg) {
/* clean up the message and make sure it is a single line */
unsigned long date;
unsigned char logged_sha1[20];
void *log_mapped;
+ size_t mapsz;
logfile = git_path("logs/%s", ref);
logfd = open(logfile, O_RDONLY, 0);
fstat(logfd, &st);
if (!st.st_size)
die("Log %s is empty.", logfile);
- log_mapped = xmmap(NULL, st.st_size, PROT_READ, MAP_PRIVATE, logfd, 0);
+ mapsz = xsize_t(st.st_size);
+ log_mapped = xmmap(NULL, mapsz, PROT_READ, MAP_PRIVATE, logfd, 0);
logdata = log_mapped;
close(logfd);
logfile, show_rfc2822_date(date, tz));
}
}
- munmap(log_mapped, st.st_size);
+ munmap(log_mapped, mapsz);
return 0;
}
lastrec = rec;
die("Log %s is corrupt.", logfile);
if (msg)
*msg = ref_msg(logdata, logend);
- munmap(log_mapped, st.st_size);
+ munmap(log_mapped, mapsz);
if (cutoff_time)
*cutoff_time = date;
projects / git.git / commitdiff