* [PATCH] Documentation: remove '\' from front of options in githooks doc
From: SZEDER Gábor @ 2008-09-30 13:37 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, SZEDER Gábor
... because they show up in the man and html outputs.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
---
Documentation/githooks.txt | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt
index 046a2a7..5bb7b33 100644
--- a/Documentation/githooks.txt
+++ b/Documentation/githooks.txt
@@ -66,7 +66,7 @@ pre-commit
----------
This hook is invoked by 'git-commit', and can be bypassed
-with `\--no-verify` option. It takes no parameter, and is
+with `--no-verify` option. It takes no parameter, and is
invoked before obtaining the proposed commit log message and
making a commit. Exiting with non-zero status from this script
causes the 'git-commit' to abort.
@@ -87,17 +87,17 @@ default log message, and before the editor is started.
It takes one to three parameters. The first is the name of the file
that the commit log message. The second is the source of the commit
-message, and can be: `message` (if a `\-m` or `\-F` option was
-given); `template` (if a `\-t` option was given or the
+message, and can be: `message` (if a `-m` or `-F` option was
+given); `template` (if a `-t` option was given or the
configuration option `commit.template` is set); `merge` (if the
commit is a merge or a `.git/MERGE_MSG` file exists); `squash`
(if a `.git/SQUASH_MSG` file exists); or `commit`, followed by
-a commit SHA1 (if a `\-c`, `\-C` or `\--amend` option was given).
+a commit SHA1 (if a `-c`, `-C` or `--amend` option was given).
If the exit status is non-zero, 'git-commit' will abort.
The purpose of the hook is to edit the message file in place, and
-it is not suppressed by the `\--no-verify` option. A non-zero exit
+it is not suppressed by the `--no-verify` option. A non-zero exit
means a failure of the hook and aborts the commit. It should not
be used as replacement for pre-commit hook.
@@ -108,7 +108,7 @@ commit-msg
----------
This hook is invoked by 'git-commit', and can be bypassed
-with `\--no-verify` option. It takes a single parameter, the
+with `--no-verify` option. It takes a single parameter, the
name of the file that holds the proposed commit log message.
Exiting with non-zero status causes the 'git-commit' to
abort.
--
1.6.0.2.448.g0c4e5
^ permalink raw reply related
* Re: [PATCH] t0024: add executable permission
From: SZEDER Gábor @ 2008-09-30 13:38 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <1222781567-5235-1-git-send-email-szeder@ira.uka.de>
Oh, well...
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
^ permalink raw reply
* [PATCH 4/4 v2] cygwin: Use native Win32 API for stat
From: Dmitry Potapov @ 2008-09-30 13:53 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Johannes Sixt, git, Junio C Hamano, Alex Riesen, Marcus Griep
In-Reply-To: <20080929153400.GJ17584@spearce.org>
lstat/stat functions in Cygwin are very slow, because they try to emulate
some *nix things that Git does not actually need. This patch adds Win32
specific implementation of these functions for Cygwin.
This implementation handles most situation directly but in some rare cases
it falls back on the implementation provided for Cygwin. This is necessary
for two reasons:
- Cygwin has its own file hierarchy, so absolute paths used in Cygwin is
not suitable to be used Win32 API. cygwin_conv_to_win32_path can not be
used because it automatically dereference Cygwin symbol links, also it
causes extra syscall. Fortunately Git rarely use absolute paths, so we
always use Cygwin implementation for absolute paths.
- Support of symbol links. Cygwin stores symbol links as ordinary using
one of two possible formats. Therefore, the fast implementation falls
back to Cygwin functions if it detects potential use of symbol links.
The speed of this implementation should be the same as mingw_lstat for
common cases, but it is considerable slower when the specified file name
does not exist.
Despite all efforts to make the fast implementation as robust as possible,
it may not work well for some very rare situations. I am aware only one
situation: use Cygwin mount to bind unrelated paths inside repository
together. Therefore, the core.ignoreCygwinFSTricks configuration option is
provided, which controls whether native or Cygwin version of stat is used.
Signed-off-by: Dmitry Potapov <dpotapov@gmail.com>
---
This version of patch has the following correction:
1. cygwinNativeStat renamed as ignoreCygwinFSTricks
2. lines in filetime_to_timespec are reformatted to fit in 80 columns
3. extra spaces after function names are removed
Documentation/config.txt | 9 +++
Makefile | 4 ++
compat/cygwin.c | 127 ++++++++++++++++++++++++++++++++++++++++++++++
compat/cygwin.h | 9 +++
git-compat-util.h | 1 +
5 files changed, 150 insertions(+), 0 deletions(-)
create mode 100644 compat/cygwin.c
create mode 100644 compat/cygwin.h
diff --git a/Documentation/config.txt b/Documentation/config.txt
index bea867d..61437fe 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -117,6 +117,15 @@ core.fileMode::
the working copy are ignored; useful on broken filesystems like FAT.
See linkgit:git-update-index[1]. True by default.
+core.ignoreCygwinFSTricks::
+ This option is only used by Cygwin implementation of Git. If false,
+ the Cygwin stat() and lstat() functions are used. This may be useful
+ if your repository consists of a few separate directories joined in
+ one hierarchy using Cygwin mount. If true, Git uses native Win32 API
+ whenever it is possible and falls back to Cygwin functions only to
+ handle symbol links. The native mode is more than twice faster than
+ normal Cygwin l/stat() functions. True by default.
+
core.trustctime::
If false, the ctime differences between the index and the
working copy are ignored; useful when the inode change time
diff --git a/Makefile b/Makefile
index 3c0664a..0708390 100644
--- a/Makefile
+++ b/Makefile
@@ -347,6 +347,7 @@ LIB_H += cache.h
LIB_H += cache-tree.h
LIB_H += commit.h
LIB_H += compat/mingw.h
+LIB_H += compat/cygwin.h
LIB_H += csum-file.h
LIB_H += decorate.h
LIB_H += delta.h
@@ -747,6 +748,9 @@ ifeq ($(uname_S),HP-UX)
NO_SYS_SELECT_H = YesPlease
SNPRINTF_RETURNS_BOGUS = YesPlease
endif
+ifneq (,$(findstring CYGWIN,$(uname_S)))
+ COMPAT_OBJS += compat/cygwin.o
+endif
ifneq (,$(findstring MINGW,$(uname_S)))
NO_MMAP = YesPlease
NO_PREAD = YesPlease
diff --git a/compat/cygwin.c b/compat/cygwin.c
new file mode 100644
index 0000000..423ff20
--- /dev/null
+++ b/compat/cygwin.c
@@ -0,0 +1,127 @@
+#define WIN32_LEAN_AND_MEAN
+#include "../git-compat-util.h"
+#include "win32.h"
+#include "../cache.h" /* to read configuration */
+
+static inline void filetime_to_timespec(const FILETIME *ft, struct timespec *ts)
+{
+ long long winTime = ((long long)ft->dwHighDateTime << 32) +
+ ft->dwLowDateTime;
+ winTime -= 116444736000000000LL; /* Windows to Unix Epoch conversion */
+ /* convert 100-nsecond interval to seconds and nanoseconds */
+ ts->tv_sec = (time_t)(winTime/10000000);
+ ts->tv_nsec = (long)(winTime - ts->tv_sec*10000000LL) * 100;
+}
+
+#define size_to_blocks(s) (((s)+511)/512)
+
+/* do_stat is a common implementation for cygwin_lstat and cygwin_stat.
+ *
+ * To simplify its logic, in the case of cygwin symlinks, this implementation
+ * falls back to the cygwin version of stat/lstat, which is provided as the
+ * last argument.
+ */
+static int do_stat(const char *file_name, struct stat *buf, stat_fn_t cygstat)
+{
+ WIN32_FILE_ATTRIBUTE_DATA fdata;
+
+ if (file_name[0] == '/')
+ return cygstat (file_name, buf);
+
+ if (!(errno = get_file_attr(file_name, &fdata))) {
+ /*
+ * If the system attribute is set and it is not a directory then
+ * it could be a symbol link created in the nowinsymlinks mode.
+ * Normally, Cygwin works in the winsymlinks mode, so this situation
+ * is very unlikely. For the sake of simplicity of our code, let's
+ * Cygwin to handle it.
+ */
+ if ((fdata.dwFileAttributes & FILE_ATTRIBUTE_SYSTEM) &&
+ !(fdata.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY))
+ return cygstat(file_name, buf);
+
+ /* fill out the stat structure */
+ buf->st_dev = buf->st_rdev = 0; /* not used by Git */
+ buf->st_ino = 0;
+ buf->st_mode = file_attr_to_st_mode(fdata.dwFileAttributes);
+ buf->st_nlink = 1;
+ buf->st_uid = buf->st_gid = 0;
+#ifdef __CYGWIN_USE_BIG_TYPES__
+ buf->st_size = ((_off64_t)fdata.nFileSizeHigh << 32) +
+ fdata.nFileSizeLow;
+#else
+ buf->st_size = (off_t)fdata.nFileSizeLow;
+#endif
+ buf->st_blocks = size_to_blocks(buf->st_size);
+ filetime_to_timespec(&fdata.ftLastAccessTime, &buf->st_atim);
+ filetime_to_timespec(&fdata.ftLastWriteTime, &buf->st_mtim);
+ filetime_to_timespec(&fdata.ftCreationTime, &buf->st_ctim);
+ return 0;
+ } else if (errno == ENOENT) {
+ /*
+ * In the winsymlinks mode (which is the default), Cygwin
+ * emulates symbol links using Windows shortcut files. These
+ * files are formed by adding .lnk extension. So, if we have
+ * not found the specified file name, it could be that it is
+ * a symbol link. Let's Cygwin to deal with that.
+ */
+ return cygstat(file_name, buf);
+ }
+ return -1;
+}
+
+/* We provide our own lstat/stat functions, since the provided Cygwin versions
+ * of these functions are too slow. These stat functions are tailored for Git's
+ * usage, and therefore they are not meant to be complete and correct emulation
+ * of lstat/stat functionality.
+ */
+static int cygwin_lstat(const char *path, struct stat *buf)
+{
+ return do_stat(path, buf, lstat);
+}
+
+static int cygwin_stat(const char *path, struct stat *buf)
+{
+ return do_stat(path, buf, stat);
+}
+
+
+/*
+ * At start up, we are trying to determine whether Win32 API or cygwin stat
+ * functions should be used. The choice is determined by core.ignorecygwinfstricks.
+ * Reading this option is not always possible immediately as git_dir may be
+ * not be set yet. So until it is set, use cygwin lstat/stat functions.
+ */
+static int native_stat = 1;
+
+static int git_cygwin_config(const char *var, const char *value, void *cb)
+{
+ if (!strcmp(var, "core.ignorecygwinfstricks"))
+ native_stat = git_config_bool(var, value);
+ return 0;
+}
+
+static int init_stat(void)
+{
+ if (have_git_dir()) {
+ git_config(git_cygwin_config, NULL);
+ cygwin_stat_fn = native_stat ? cygwin_stat : stat;
+ cygwin_lstat_fn = native_stat ? cygwin_lstat : lstat;
+ return 0;
+ }
+ return 1;
+}
+
+static int cygwin_stat_stub(const char *file_name, struct stat *buf)
+{
+ return (init_stat() ? stat : *cygwin_stat_fn)(file_name, buf);
+}
+
+static int cygwin_lstat_stub(const char *file_name, struct stat *buf)
+{
+ return (init_stat() ? lstat : *cygwin_lstat_fn)(file_name, buf);
+}
+
+stat_fn_t cygwin_stat_fn = cygwin_stat_stub;
+stat_fn_t cygwin_lstat_fn = cygwin_lstat_stub;
+
diff --git a/compat/cygwin.h b/compat/cygwin.h
new file mode 100644
index 0000000..a3229f5
--- /dev/null
+++ b/compat/cygwin.h
@@ -0,0 +1,9 @@
+#include <sys/types.h>
+#include <sys/stat.h>
+
+typedef int (*stat_fn_t)(const char*, struct stat*);
+extern stat_fn_t cygwin_stat_fn;
+extern stat_fn_t cygwin_lstat_fn;
+
+#define stat(path, buf) (*cygwin_stat_fn)(path, buf)
+#define lstat(path, buf) (*cygwin_lstat_fn)(path, buf)
diff --git a/git-compat-util.h b/git-compat-util.h
index db2836f..cd9752c 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -85,6 +85,7 @@
#undef _XOPEN_SOURCE
#include <grp.h>
#define _XOPEN_SOURCE 600
+#include "compat/cygwin.h"
#else
#undef _ALL_SOURCE /* AIX 5.3L defines a struct list with _ALL_SOURCE. */
#include <grp.h>
--
1.6.0
^ permalink raw reply related
* [PATCH] Improve git-log documentation wrt file filters
From: martin f. krafft @ 2008-09-30 14:36 UTC (permalink / raw)
To: git; +Cc: martin f. krafft
The need for "--" in the git-log synopsis was previously unclear and
confusing. This patch makes it a little clearer.
Thanks to hyy <yiyihu@gmail.com> for his help.
Signed-off-by: martin f. krafft <madduck@madduck.net>
---
Documentation/git-log.txt | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt
index 0446bad..b7409f8 100644
--- a/Documentation/git-log.txt
+++ b/Documentation/git-log.txt
@@ -8,7 +8,7 @@ git-log - Show commit logs
SYNOPSIS
--------
-'git log' <option>...
+'git log' [<options>] [<since>..<until>] [[--] <path>...]
DESCRIPTION
-----------
@@ -57,8 +57,10 @@ include::diff-options.txt[]
Note that only message is considered, if also a diff is shown
its size is not included.
-<path>...::
- Show only commits that affect any of the specified paths.
+-- <path>...::
+ Show only commits that affect any of the specified paths. To
+ prevent confusion with options and branch names, paths should be
+ prefixed with "-- " to separate them from options or refnames.
include::rev-list-options.txt[]
--
1.5.6.5
^ permalink raw reply related
* Re: [PATCH 4/4 v2] cygwin: Use native Win32 API for stat
From: Marcus Griep @ 2008-09-30 14:57 UTC (permalink / raw)
To: Dmitry Potapov
Cc: Shawn O. Pearce, Johannes Sixt, git, Junio C Hamano, Alex Riesen
In-Reply-To: <20080930135347.GK21650@dpotapov.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 588 bytes --]
Dmitry Potapov wrote:
> lstat/stat functions in Cygwin are very slow, because they try to emulate
> some *nix things that Git does not actually need. This patch adds Win32
> specific implementation of these functions for Cygwin.
Can't wait to see this patch in next or master! If you recall my benchmarks
from earlier, the speed-up is pretty good for cygwin users working with
large repositories.
> Signed-off-by: Dmitry Potapov <dpotapov@gmail.com>
Thanks for the work, Dmitry!
--
Marcus Griep
GPG Key ID: 0x5E968152
——
http://www.boohaunt.net
את.ψο´
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: [PATCH v2] Add OS X support to the pre-auto-gc example hook
From: Miklos Vajna @ 2008-09-30 15:00 UTC (permalink / raw)
To: Jonathan del Strother; +Cc: git
In-Reply-To: <1222731388-833-1-git-send-email-jon.delStrother@bestbefore.tv>
[-- Attachment #1: Type: text/plain, Size: 298 bytes --]
On Tue, Sep 30, 2008 at 12:36:28AM +0100, Jonathan del Strother <jon.delStrother@bestbefore.tv> wrote:
> Second attempt - this simplifies the test while making it more
> specific (it will only pack when on AC power, rather than, say, UPS).
Acked-by: Miklos Vajna <vmiklos@frugalware.org>
Thanks.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* How Blobs Work ( Blobs Vs. Deltas)
From: Feanil Patel @ 2008-09-30 15:14 UTC (permalink / raw)
To: git
Hello,
I was reading about git objects on The Git
Book(http://book.git-scm.com/1_the_git_object_model.html) which was
posted on the mailing list a while back and I was wondering something
about blobs and how files are stored in any particular version. If
file A is changed from version one to version two there are two
different blobs that exist for the two versions of the file, is that
correct? The Book was saying Git does not use delta storage so does
this mean that there are two almost identical copies of the file with
the difference being the change that was put in from version one to
version two?
-Feanil
^ permalink raw reply
* Re: Implementation of a "textconv" filter for easy custom diff.
From: Matthieu Moy @ 2008-09-30 15:19 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20080928161106.GA30199@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Sun, Sep 28, 2008 at 11:57:05AM +0200, Matthieu Moy wrote:
>
>> > Neat. I started on something like this quite a while ago,
>>
>> Did you publish/send it anywhere?
>
> No, I was waiting to clean it up and test it a bit more.
Well, if you have time and you think your code is better than mine, I
can let you continue on this (and you can pick the parts you want in
mine). Otherwise, I'd be interested in seeing your draft to
incorporate the good things in my version.
Cheers,
--
Matthieu
^ permalink raw reply
* Re: How Blobs Work ( Blobs Vs. Deltas)
From: Bruce Stephens @ 2008-09-30 15:28 UTC (permalink / raw)
To: git
In-Reply-To: <16946e800809300814v134a42dft37becdbd8aa7669a@mail.gmail.com>
"Feanil Patel" <feanil@gmail.com> writes:
> I was reading about git objects on The Git
> Book(http://book.git-scm.com/1_the_git_object_model.html) which was
> posted on the mailing list a while back and I was wondering something
> about blobs and how files are stored in any particular version.
[...]
> The Book was saying Git does not use delta storage so does this mean
> that there are two almost identical copies of the file with the
> difference being the change that was put in from version one to
> version two?
There might be. git may also end up using deltas, see
<http://book.git-scm.com/7_the_packfile.html>.
^ permalink raw reply
* Re: How Blobs Work ( Blobs Vs. Deltas)
From: Johannes Sixt @ 2008-09-30 15:29 UTC (permalink / raw)
To: Feanil Patel; +Cc: git
In-Reply-To: <16946e800809300814v134a42dft37becdbd8aa7669a@mail.gmail.com>
Feanil Patel schrieb:
> I was reading about git objects on The Git
> Book(http://book.git-scm.com/1_the_git_object_model.html) which was
> posted on the mailing list a while back and I was wondering something
> about blobs and how files are stored in any particular version. If
> file A is changed from version one to version two there are two
> different blobs that exist for the two versions of the file, is that
> correct? The Book was saying Git does not use delta storage so does
> this mean that there are two almost identical copies of the file with
> the difference being the change that was put in from version one to
> version two?
At the conceptual level, yes. An entire file (== blob) is the smallest
unit that you can address. Even git's internals do not work with smaller
units.
But there is, of course, a mechanism that stores the database in a more
compact format, the so-called pack files, that basically store differences
between files as much as possible.
-- Hannes
^ permalink raw reply
* Re: [PATCH] Documentation: remove '\' from front of options in githooks doc
From: Thomas Rast @ 2008-09-30 15:56 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: Shawn O. Pearce, git
In-Reply-To: <1222781831-6620-1-git-send-email-szeder@ira.uka.de>
[-- Attachment #1: Type: text/plain, Size: 1158 bytes --]
SZEDER Gábor wrote:
> ... because they show up in the man and html outputs.
...
> diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt
...
> @@ -66,7 +66,7 @@ pre-commit
> ----------
>
> This hook is invoked by 'git-commit', and can be bypassed
> -with `\--no-verify` option. It takes no parameter, and is
> +with `--no-verify` option. It takes no parameter, and is
> invoked before obtaining the proposed commit log message and
> making a commit. Exiting with non-zero status from this script
> causes the 'git-commit' to abort.
This must be checked against older asciidocs to verify that it does
not turn the unescaped sequence -- into an em-dash. The \-- traces
back to e1ccf53 ([PATCH] Escape asciidoc's built-in em-dash
replacement, 2005-09-12), which indicates that it _was_ a problem in
the past. (The asciidoc 8.2.5 on my system does not use an em-dash in
either case.)
ACK on all single-dash cases though, which are indeed wrong and were
apparently introduced later in 8089c85 (git-commit: add a
prepare-commit-msg hook, 2008-02-05).
- Thomas
--
Thomas Rast
trast@student.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [RFC PATCH] Documentation: add manpage about workflows
From: Thomas Rast @ 2008-09-30 16:05 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: git, Santi Béjar, Junio C Hamano
In-Reply-To: <20080921202620.GG21650@dpotapov.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 12980 bytes --]
As a quick status update, mostly to show that I haven't forgotten
about this topic:
Thanks Santi and Dmitry for your comments. You have raised some very
good points, and I attempted to fix these issues.
Unfortunately, in some places I got stuck trying to work out good
explanations for the workings of git.git, and some of the newer
rearrangements left the lead of "Merging branches" in a dire state.
I'll see if I can find a good solution myself, but suggestions would
be welcome in any case. The WIP text is below, and I'll follow up
with an interdiff to the last version.
- Thomas
--- 8< ---
gitworkflows(7)
===============
NAME
----
gitworkflows - An overview of recommended workflows with git
SYNOPSIS
--------
git *
DESCRIPTION
-----------
This document attempts to write down and motivate some of the workflow
elements used for `git.git` itself. Many ideas apply in general,
though the full workflow is rarely required for smaller projects with
fewer people involved.
We formulate a set of 'rules' for quick reference, while the prose
tries to motivate each of them. Do not always take them literally;
you should value good reasons for your actions higher than manpages
such as this one.
SEPARATE CHANGES
----------------
As a general rule, you should try to split your changes into small
logical steps, and commit each of them. They should be consistent,
working independently of any later commits, pass the test suite, etc.
This makes the review process much easier, and the history much more
useful for later inspection and analysis, for example with
linkgit:git-blame[1] and linkgit:git-bisect[1].
To achieve this, try to split your work into small steps from the very
beginning. It is always easier to squash a few commits together than
to split one big commit into several. Don't be afraid of making too
small or imperfect steps along the way. You can always go back later
and edit the commits with `git rebase \--interactive` before you
publish them.
MANAGING BRANCHES
-----------------
Usually a feature (or other change) evolves in stages: it "graduates"
from patch to the testing branches and on to stable releases. During
this process, it may require fixes or improvements. XXX terrible
paragraph XXX
Merges (as opposed to cherry-picks, see below) greatly simplify
handling large numbers of commits, so a scalable workflow needs to use
merges. Fortunately Git is very good at merging.
XXX non sequitur XXX
In the following sections we discuss some problems that arise from
such a "change flow", and how to solve them with Git.
Graduation
~~~~~~~~~~
As a given feature goes from experimental to stable, it also
"graduates" between the corresponding branches of the software.
`git.git` uses the following 'main branches':
* 'master' tracks the commits that should go into the next release;
* 'maint' tracks the commits that should go into the next "maintenance
release", i.e., update of the last released stable version; and
* 'next' is intended as a testing branch for people who like to use
more experimental stuff.
There is a fourth official branch that is used slightly differently:
* 'pu' (proposed updates) is an integration branch for things that are
not quite ready for inclusion yet (see "Integration Branches"
below).
Conceptually, the feature enters at an unstable branch (usually 'next'
or 'pu'), and "graduates" to 'master' for the next release once it is
considered stable enough.
Merging upwards
~~~~~~~~~~~~~~~
As explained above, features conceptually "graduate downwards" to
older releases. This cannot be done by actually merging downwards,
however, since that would merge 'all' changes on the unstable branch
into the stable one. Hence the following:
.Merge upwards
[caption="Rule: "]
=====================================
Always commit your fixes to the oldest supported branch that require
them. Then (periodically) merge the main branches upwards into each
other.
=====================================
This gives a very controlled flow of fixes. If you notice that you
have applied a fix to e.g. 'master' that is also required in 'maint',
you will need to cherry-pick it (using linkgit:git-cherry-pick[1])
downwards. This will happen a few times and is nothing to worry about
unless you do it very frequently.
Topic branches
~~~~~~~~~~~~~~
Any nontrivial feature will require several patches to implement, and
may get extra bugfixes or improvements during its lifetime.
Committing everything directly on the main branches leads to many
problems: Bad commits cannot be undone, so they must be reverted one
by one, which creates confusing histories and further error potential
when you forget to revert part of a group of changes. Working in
parallel mixes up the changes, creating further confusion.
The key concept here is "topic branches". The name is pretty self
explanatory, with a caveat that comes from the "merge upwards" rule
above:
.Topic branches
[caption="Rule: "]
=====================================
Make a side branch for every topic (feature, bugfix, ...). Fork it off
at the oldest main branch that you will eventually want to merge it
into.
=====================================
Many things can then be done very naturally:
* To get the feature/bugfix into a main branch, simply merge it. If
the topic has evolved further in the meantime, merge again.
* If you find you need new features from the branch 'other' to continue
working on your topic, merge 'other' to 'topic'. (However, do not
do this "just habitually", see below.)
* If you find you forked off the wrong branch and want to move it
"back in time", use linkgit:git-rebase[1].
Note that the last two points clash: a topic that has been merged
elsewhere should not be rebased. See the section on RECOVERING FROM
UPSTREAM REBASE in linkgit:git-rebase[1].
We should point out that "habitually" (regularly for no real reason)
merging a main branch into your topics -- and by extension, merging
anything upstream into anything downstream on a regular basis -- is
frowned upon:
.Merge to downstream only at well-defined points
[caption="Rule: "]
=====================================
Do not merge to downstream except:
* with a good reason: upstream API changes affect your branch; your
branch no longer merges to upstream cleanly; etc.
* at well-defined points such as when an upstream release has been tagged.
=====================================
Otherwise, the many resulting small merges will greatly clutter up
history. Anyone who later investigates the history of a file will
have to find out whether that merge affected the topic in development.
An upstream might even inadvertently be merged into a "more stable"
branch. And so on.
Integration branches
~~~~~~~~~~~~~~~~~~~~
If you followed the last paragraph, you will now have many small topic
branches, and occasionally wonder how they interact. Perhaps the
result of merging them does not even work? But on the other hand, we
want to avoid merging them anywhere "stable" because such merges
cannot easily be undone.
The solution, of course, is to make a merge that we can undo: merge
into a throw-away branch.
.Integration branches
[caption="Rule: "]
=====================================
To test the interaction of several topics, merge them into a
throw-away branch.
=====================================
If you make it (very) clear that this branch is going to be deleted
right after the testing, you can even publish this branch, for example
to give the testers a chance to work with it, or other developers a
chance to see if their in-progress work will be compatible. `git.git`
has such an official integration branch called 'pu'. You must never
base any work on such a throw-away branch!
SHARING WORK
------------
After the last section, you should know how to manage topics. In
general, you will not be the only person working on the project, so
you will have to share your work.
Roughly speaking, there are two important workflows: push/pull and
format-patch/am. The important difference is that push/pull can
propagate merges, while format-patch cannot. Medium to large projects
will typically employ some mixture of the two:
* "Upstream" in the most general sense 'pushes' changes to the
repositor(ies) holding the official history of the project.
Everyone can 'fetch' from there to stay up to date.
* Frequent contributors, subsystem maintainers, etc. may push to a
public repository to make their changes available to upstream.
* The rest -- typically anyone more than one or two levels away from the
main maintainer -- send patches by mail.
None of these boundaries are sharp, so find out what works best for
you.
Push/pull
~~~~~~~~~
There are three main tools that can be used for this:
* linkgit:git-push[1] copies your branches to a remote repository,
usually to one that can be read by all involved parties;
* linkgit:git-fetch[1] that copies remote branches to your repository;
and
* linkgit:git-pull[1] that does fetch and merge in one go.
Note the last point. Do 'not' use 'git-pull' unless you actually want
to merge the remote branch.
Getting changes out is easy:
.Push/pull: Publishing branches/topics
[caption="Recipe: "]
=====================================
`git push <remote> <branch>` and tell everyone where they can fetch
from.
=====================================
You will still have to tell people by other means, such as mail. (Git
provides the linkgit:request-pull[1] to send preformatted pull
requests to upstream maintainers to simplify this task.)
If you just want to get the newest copies of the main branches,
staying up to date is easy too:
.Push/pull: Staying up to date
[caption="Recipe: "]
=====================================
Use `git fetch <remote>` or `git remote update` to stay up to date.
=====================================
Then simply fork your topic branches from the stable remotes as
explained earlier.
If you are a maintainer and would like to merge other people's topic
branches to the main branches, they will typically send a request to
do so by mail. Such a request might say
-------------------------------------
Please pull from
git://some.server.somewhere/random/repo.git mytopic
-------------------------------------
In that case, 'git-pull' can do the fetch and merge in one go, as
follows.
.Push/pull: Merging remote topics
[caption="Recipe: "]
=====================================
`git pull <url> <branch>`
=====================================
Occasionally, the maintainer may get merge conflicts when he tries to
pull changes from downstream. In this case, he can ask downstream to
do the merge and resolve the conflicts themselves (perhaps they will
know better how to resolve them). It is one of the rare cases where
downstream 'should' merge from upstream.
format-patch/am
~~~~~~~~~~~~~~~
If you are a contributor that sends changes upstream in the form of
emails, you should use topic branches as usual (see above). Then use
linkgit:git-format-patch[1] to generate the corresponding emails
(highly recommended over manually formatting them because it makes the
maintainer's life easier).
.format-patch/am: Publishing branches/topics
[caption="Recipe: "]
=====================================
* `git format-patch -M upstream..topic` to turn them into preformatted
patch files
* `git send-email --to=<recipient> <patches>`
=====================================
See the linkgit:git-format-patch[1] and linkgit:git-send-email[1]
manpages for further usage notes. Also you should be aware that the
maintainer may impose further restrictions, such as "Signed-off-by"
requirements.
If the maintainer tells you that your patch no longer applies to the
current upstream, you will have to rebase your topic (you cannot use a
merge because you cannot format-patch merges):
.format-patch/am: Keeping topics up to date
[caption="Recipe: "]
=====================================
`git pull --rebase <url> <branch>`
=====================================
You can then fix the conflicts during the rebase. Presumably you have
not published your topic other than by mail, so rebasing it is not a
problem.
If you receive such a patch (as maintainer, or perhaps as a reader of
the mailing list it was sent to), save the mail to a file and use
'git-am':
.format-patch/am: Publishing branches/topics
[caption="Recipe: "]
=====================================
`git am < patch`
=====================================
One feature worth pointing out is the three-way merge, which can help
if you get conflicts: `git am -3` will use index information contained
in patches to figure out the merge base. See linkgit:git-am[1] for
other options.
SEE ALSO
--------
linkgit:gittutorial[7],
linkgit:git-push[1],
linkgit:git-pull[1],
linkgit:git-merge[1],
linkgit:git-rebase[1],
linkgit:git-format-patch[1],
linkgit:git-send-email[1],
linkgit:git-am[1]
GIT
---
Part of the linkgit:git[1] suite.
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [RFC PATCH] Documentation: add manpage about workflows
From: Thomas Rast @ 2008-09-30 16:07 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: git, Santi Béjar, Junio C Hamano
In-Reply-To: <200809301805.30753.trast@student.ethz.ch>
I wrote:
> The WIP text is below, and I'll follow up with an interdiff to the
> last version.
diff --git a/Documentation/gitworkflows.txt b/Documentation/gitworkflows.txt
index b4b43da..87c2270 100644
--- a/Documentation/gitworkflows.txt
+++ b/Documentation/gitworkflows.txt
@@ -13,13 +13,15 @@ git *
DESCRIPTION
-----------
-This tutorial gives a brief overview of workflows recommended to
-use, and collaborate with, Git.
+This document attempts to write down and motivate some of the workflow
+elements used for `git.git` itself. Many ideas apply in general,
+though the full workflow is rarely required for smaller projects with
+fewer people involved.
-While the prose tries to motivate each of them, we formulate a set of
-'rules' for quick reference. Do not always take them literally; you
-should value good reasons higher than following a random manpage to
-the letter.
+We formulate a set of 'rules' for quick reference, while the prose
+tries to motivate each of them. Do not always take them literally;
+you should value good reasons for your actions higher than manpages
+such as this one.
SEPARATE CHANGES
@@ -28,49 +30,68 @@ SEPARATE CHANGES
As a general rule, you should try to split your changes into small
logical steps, and commit each of them. They should be consistent,
working independently of any later commits, pass the test suite, etc.
+This makes the review process much easier, and the history much more
+useful for later inspection and analysis, for example with
+linkgit:git-blame[1] and linkgit:git-bisect[1].
-To achieve this, try to commit your new work at least every couple
-hours. You can always go back and edit the commits with `git rebase
---interactive` to further improve the history before you publish it.
+To achieve this, try to split your work into small steps from the very
+beginning. It is always easier to squash a few commits together than
+to split one big commit into several. Don't be afraid of making too
+small or imperfect steps along the way. You can always go back later
+and edit the commits with `git rebase \--interactive` before you
+publish them.
MANAGING BRANCHES
-----------------
-In the following, we will assume there are 'developers', 'testers' and
-'users'. Even if the "Testers" are actually an automated test suite
-and all "Users" are developers themselves, try to think in these terms
-as you follow a software change through its life cycle.
+Usually a feature (or other change) evolves in stages: it "graduates"
+from patch to the testing branches and on to stable releases. During
+this process, it may require fixes or improvements. XXX terrible
+paragraph XXX
-Usually a change evolves in a few steps:
+Merges (as opposed to cherry-picks, see below) greatly simplify
+handling large numbers of commits, so a scalable workflow needs to use
+merges. Fortunately Git is very good at merging.
-* The developers implement a few iterations until it "seems to work".
+XXX non sequitur XXX
+In the following sections we discuss some problems that arise from
+such a "change flow", and how to solve them with Git.
-* The testers play with it, report bugs, test the fixes, eventually
- clearing the change for stable releases.
-* As the users work with the new feature, they report bugs which will
- have to be fixed.
+Graduation
+~~~~~~~~~~
-In the following sections we discuss some problems that arise from
-such a "change flow", and how to solve them with Git.
+As a given feature goes from experimental to stable, it also
+"graduates" between the corresponding branches of the software.
+`git.git` uses the following 'main branches':
+
+* 'master' tracks the commits that should go into the next release;
+
+* 'maint' tracks the commits that should go into the next "maintenance
+ release", i.e., update of the last released stable version; and
-We consider a fictional project with (supported) stable branch
-'maint', main testing/development branch 'master' and "bleeding edge"
-branch 'next'. We collectively call these three branches 'main
-branches'.
+* 'next' is intended as a testing branch for people who like to use
+ more experimental stuff.
+
+There is a fourth official branch that is used slightly differently:
+
+* 'pu' (proposed updates) is an integration branch for things that are
+ not quite ready for inclusion yet (see "Integration Branches"
+ below).
+
+Conceptually, the feature enters at an unstable branch (usually 'next'
+or 'pu'), and "graduates" to 'master' for the next release once it is
+considered stable enough.
Merging upwards
~~~~~~~~~~~~~~~
-Since Git is quite good at merges, one should try to use them to
-propagate changes. For example, if a bug is fixed, you would want to
-apply the corresponding fix to all main branches.
-
-A quick moment of thought reveals that you cannot do this by merging
-"downwards" to older releases, since that would merge 'all' changes.
-Hence the following:
+As explained above, features conceptually "graduate downwards" to
+older releases. This cannot be done by actually merging downwards,
+however, since that would merge 'all' changes on the unstable branch
+into the stable one. Hence the following:
.Merge upwards
[caption="Rule: "]
@@ -84,27 +105,31 @@ This gives a very controlled flow of fixes. If you notice that you
have applied a fix to e.g. 'master' that is also required in 'maint',
you will need to cherry-pick it (using linkgit:git-cherry-pick[1])
downwards. This will happen a few times and is nothing to worry about
-unless you do it all the time.
+unless you do it very frequently.
Topic branches
~~~~~~~~~~~~~~
Any nontrivial feature will require several patches to implement, and
-may get extra bugfixes or improvements during its lifetime. If all
-such commits were in one long linear history chain (e.g., if they were
-all committed directly to 'master'), it becomes very hard to see how
-they belong together.
+may get extra bugfixes or improvements during its lifetime.
+
+Committing everything directly on the main branches leads to many
+problems: Bad commits cannot be undone, so they must be reverted one
+by one, which creates confusing histories and further error potential
+when you forget to revert part of a group of changes. Working in
+parallel mixes up the changes, creating further confusion.
The key concept here is "topic branches". The name is pretty self
-explanatory, with a minor caveat that comes from the "merge upwards"
-rule above:
+explanatory, with a caveat that comes from the "merge upwards" rule
+above:
.Topic branches
[caption="Rule: "]
=====================================
-Make a side branch for every topic. Fork it off at the oldest main
-branch that you will eventually want to merge it into.
+Make a side branch for every topic (feature, bugfix, ...). Fork it off
+at the oldest main branch that you will eventually want to merge it
+into.
=====================================
Many things can then be done very naturally:
@@ -112,7 +137,7 @@ Many things can then be done very naturally:
* To get the feature/bugfix into a main branch, simply merge it. If
the topic has evolved further in the meantime, merge again.
-* If you find you need new features from an 'other' branch to continue
+* If you find you need new features from the branch 'other' to continue
working on your topic, merge 'other' to 'topic'. (However, do not
do this "just habitually", see below.)
@@ -133,16 +158,17 @@ frowned upon:
=====================================
Do not merge to downstream except:
-* with a good reason (such as upstream API changes that affect you), or
+* with a good reason: upstream API changes affect your branch; your
+ branch no longer merges to upstream cleanly; etc.
* at well-defined points such as when an upstream release has been tagged.
=====================================
Otherwise, the many resulting small merges will greatly clutter up
history. Anyone who later investigates the history of a file will
-have to find out whether that merge affected the topic in
-development. Linus hates it. An upstream might even inadvertently be
-merged into a "more stable" branch. And so on.
+have to find out whether that merge affected the topic in development.
+An upstream might even inadvertently be merged into a "more stable"
+branch. And so on.
Integration branches
@@ -167,7 +193,9 @@ throw-away branch.
If you make it (very) clear that this branch is going to be deleted
right after the testing, you can even publish this branch, for example
to give the testers a chance to work with it, or other developers a
-chance to see if their in-progress work will be compatible.
+chance to see if their in-progress work will be compatible. `git.git`
+has such an official integration branch called 'pu'. You must never
+base any work on such a throw-away branch!
SHARING WORK
@@ -177,17 +205,17 @@ After the last section, you should know how to manage topics. In
general, you will not be the only person working on the project, so
you will have to share your work.
-Roughly speaking, there are two important workflows. Their
-distinguishing mark is whether they can be used to propagate merges.
-Medium to large projects will typically employ some mixture of the
-two:
+Roughly speaking, there are two important workflows: push/pull and
+format-patch/am. The important difference is that push/pull can
+propagate merges, while format-patch cannot. Medium to large projects
+will typically employ some mixture of the two:
* "Upstream" in the most general sense 'pushes' changes to the
- repositor(ies) holding the main history. Everyone can 'pull' from
- there to stay up to date.
+ repositor(ies) holding the official history of the project.
+ Everyone can 'fetch' from there to stay up to date.
-* Frequent contributors, subsystem maintainers, etc. may use push/pull
- to send their changes upstream.
+* Frequent contributors, subsystem maintainers, etc. may push to a
+ public repository to make their changes available to upstream.
* The rest -- typically anyone more than one or two levels away from the
main maintainer -- send patches by mail.
@@ -291,15 +319,15 @@ merge because you cannot format-patch merges):
.format-patch/am: Keeping topics up to date
[caption="Recipe: "]
=====================================
-`git rebase upstream`
+`git pull --rebase <url> <branch>`
=====================================
You can then fix the conflicts during the rebase. Presumably you have
not published your topic other than by mail, so rebasing it is not a
problem.
-If you receive such a patch (as maintainer, or perhaps reader of the
-mailing list it was sent to), save the mail to a file and use
+If you receive such a patch (as maintainer, or perhaps as a reader of
+the mailing list it was sent to), save the mail to a file and use
'git-am':
.format-patch/am: Publishing branches/topics
@@ -309,9 +337,9 @@ mailing list it was sent to), save the mail to a file and use
=====================================
One feature worth pointing out is the three-way merge, which can help
-if you get conflicts because of renames: `git am -3` will use index
-information contained in patches to reconstruct a merge base. See
-linkgit:git-am[1] for other options.
+if you get conflicts: `git am -3` will use index information contained
+in patches to figure out the merge base. See linkgit:git-am[1] for
+other options.
SEE ALSO
^ permalink raw reply related
* Re: Implementation of a "textconv" filter for easy custom diff.
From: Jeff King @ 2008-09-30 16:45 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqk5ctfyp6.fsf@bauges.imag.fr>
On Tue, Sep 30, 2008 at 05:19:49PM +0200, Matthieu Moy wrote:
> Well, if you have time and you think your code is better than mine, I
> can let you continue on this (and you can pick the parts you want in
> mine). Otherwise, I'd be interested in seeing your draft to
> incorporate the good things in my version.
I am about 90% done cleaning it up for preparation (there is a bit of
refactoring, and I want to make sure I get that just right). I'll post
it in the next day or so.
-Peff
^ permalink raw reply
* [PATCH] git-gui: Implement a 'clone' subcommand
From: Petr Baudis @ 2008-09-30 16:51 UTC (permalink / raw)
To: git, git; +Cc: spearce, Petr Baudis
This enables git-gui to be started with the clone dialog opened right
away, possibly with the URL prefilled when it is passed as another
argument. git-gui can then be e.g. registered as the git:// protocol
handler.
This is just a simple implementation - we construct the front actions
page, then throw it away immediately; I wanted to avoid unnecessary
refactoring and complication of the code, though.
Signed-off-by: Petr Baudis <petr.baudis@novartis.com>
---
Documentation/git-gui.txt | 5 +++++
git-gui/git-gui.sh | 21 ++++++++++++++++++---
git-gui/lib/choose_repository.tcl | 11 ++++++++++-
3 files changed, 33 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-gui.txt b/Documentation/git-gui.txt
index 0e650f4..9ce63be 100644
--- a/Documentation/git-gui.txt
+++ b/Documentation/git-gui.txt
@@ -43,6 +43,11 @@ citool::
to only commit actions, slightly reducing the application's
startup time and simplifying the menubar.
+clone::
+ Start the 'git-gui' clone dialog, optionally taking
+ a source location as an extra argument to pre-fill
+ in the dialog.
+
version::
Display the currently running version of 'git-gui'.
diff --git a/git-gui/git-gui.sh b/git-gui/git-gui.sh
index 4085e8f..86f0151 100755
--- a/git-gui/git-gui.sh
+++ b/git-gui/git-gui.sh
@@ -950,6 +950,8 @@ enable_option multicommit
enable_option branch
enable_option transport
disable_option bare
+set init_action {}
+set clone_url {}
switch -- $subcommand {
browser -
@@ -960,6 +962,13 @@ blame {
disable_option branch
disable_option transport
}
+clone {
+ set init_action "clone"
+ if {[llength $argv] > 0} {
+ set clone_url [lindex $argv 0]
+ set argv [lrange $argv 1 end]
+ }
+}
citool {
enable_option singlecommit
enable_option retcode
@@ -995,7 +1004,12 @@ citool {
##
## repository setup
-if {[catch {
+if {$init_action != ""} {
+ load_config 1
+ apply_config
+ choose_repository::pick $init_action
+
+} elseif {[catch {
set _gitdir $env(GIT_DIR)
set _prefix {}
}]
@@ -1005,7 +1019,7 @@ if {[catch {
} err]} {
load_config 1
apply_config
- choose_repository::pick
+ choose_repository::pick {}
}
if {![file isdirectory $_gitdir] && [is_Cygwin]} {
catch {set _gitdir [exec cygpath --windows $_gitdir]}
@@ -2622,6 +2636,7 @@ blame {
return
}
citool -
+clone -
gui {
if {[llength $argv] != 0} {
puts -nonewline stderr "usage: $argv0"
@@ -2635,7 +2650,7 @@ gui {
# fall through to setup UI for commits
}
default {
- puts stderr "usage: $argv0 \[{blame|browser|citool}\]"
+ puts stderr "usage: $argv0 \[{blame|browser|citool|clone}\]"
exit 1
}
}
diff --git a/git-gui/lib/choose_repository.tcl b/git-gui/lib/choose_repository.tcl
index 3180786..290fbc0 100644
--- a/git-gui/lib/choose_repository.tcl
+++ b/git-gui/lib/choose_repository.tcl
@@ -21,7 +21,7 @@ field clone_type hardlink ; # Type of clone to construct
field readtree_err ; # Error output from read-tree (if any)
field sorted_recent ; # recent repositories (sorted)
-constructor pick {} {
+constructor pick {action} {
global M1T M1B
make_toplevel top w
@@ -195,6 +195,11 @@ constructor pick {} {
bind $top <Visibility> {}
"
wm deiconify $top
+
+ if {$action != ""} {
+ _next $this $action
+ }
+
tkwait variable @done
if {$top eq {.}} {
@@ -447,6 +452,10 @@ proc _new_ok {p} {
## Clone Existing Repository
method _do_clone {} {
+ if {$::clone_url != ""} {
+ set origin_url $::clone_url
+ }
+
$w_next conf \
-state disabled \
-command [cb _do_clone2] \
--
tg: (9800c0d..) t/git-gui/clonecmd (depends on: vanilla/master)
^ permalink raw reply related
* Re: [PATCH] Documentation: remove '\' from front of options in githooks doc
From: SZEDER Gábor @ 2008-09-30 17:21 UTC (permalink / raw)
To: Thomas Rast; +Cc: Shawn O. Pearce, git
In-Reply-To: <200809301756.41518.trast@student.ethz.ch>
Hi Thomas,
On Tue, Sep 30, 2008 at 05:56:32PM +0200, Thomas Rast wrote:
> This must be checked against older asciidocs to verify that it does
> not turn the unescaped sequence -- into an em-dash. The \-- traces
> back to e1ccf53 ([PATCH] Escape asciidoc's built-in em-dash
> replacement, 2005-09-12), which indicates that it _was_ a problem in
> the past. (The asciidoc 8.2.5 on my system does not use an em-dash in
> either case.)
Indeed, now that I look more closely, I had those '\' characters only
in front of short options in the outputs.
However, it worth noting that there are plenty other places where
the double dash in long options are not escaped with a '\'.
> ACK on all single-dash cases though, which are indeed wrong and were
> apparently introduced later in 8089c85 (git-commit: add a
> prepare-commit-msg hook, 2008-02-05).
I will send a corrected patch shortly.
Thanks,
Gábor
^ permalink raw reply
* [PATCH] Documentation: remove '\' in front of short options
From: SZEDER Gábor @ 2008-09-30 17:27 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Thomas Rast, git
In-Reply-To: <20080930172155.GJ6941@neumann>
... because they show up in the man and html outputs.
This escaping is only needed for double dashes to be compatible with
older asciidoc versions; see commit e1ccf53 ([PATCH] Escape asciidoc's
built-in em-dash replacement, 2005-09-12).
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
---
Documentation/git-rev-list.txt | 6 +++---
Documentation/githooks.txt | 6 +++---
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt
index fd1de92..1c9cc28 100644
--- a/Documentation/git-rev-list.txt
+++ b/Documentation/git-rev-list.txt
@@ -32,9 +32,9 @@ SYNOPSIS
[ \--cherry-pick ]
[ \--encoding[=<encoding>] ]
[ \--(author|committer|grep)=<pattern> ]
- [ \--regexp-ignore-case | \-i ]
- [ \--extended-regexp | \-E ]
- [ \--fixed-strings | \-F ]
+ [ \--regexp-ignore-case | -i ]
+ [ \--extended-regexp | -E ]
+ [ \--fixed-strings | -F ]
[ \--date={local|relative|default|iso|rfc|short} ]
[ [\--objects | \--objects-edge] [ \--unpacked ] ]
[ \--pretty | \--header ]
diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt
index 046a2a7..7fefdb1 100644
--- a/Documentation/githooks.txt
+++ b/Documentation/githooks.txt
@@ -87,12 +87,12 @@ default log message, and before the editor is started.
It takes one to three parameters. The first is the name of the file
that the commit log message. The second is the source of the commit
-message, and can be: `message` (if a `\-m` or `\-F` option was
-given); `template` (if a `\-t` option was given or the
+message, and can be: `message` (if a `-m` or `-F` option was
+given); `template` (if a `-t` option was given or the
configuration option `commit.template` is set); `merge` (if the
commit is a merge or a `.git/MERGE_MSG` file exists); `squash`
(if a `.git/SQUASH_MSG` file exists); or `commit`, followed by
-a commit SHA1 (if a `\-c`, `\-C` or `\--amend` option was given).
+a commit SHA1 (if a `-c`, `-C` or `\--amend` option was given).
If the exit status is non-zero, 'git-commit' will abort.
--
1.6.0.2.448.g0c4e5
^ permalink raw reply related
* git gui rescane_stage2 error on windows
From: astubbs @ 2008-09-30 17:41 UTC (permalink / raw)
To: git
Fresh install and fresh repository on Vista.Getting this error when launching
git gui:child process exited abnormallychild process exited abnormally
while executing"close $fd" (procedure "rescan_stage2" line 7) invoked
from within"rescan_stage2 file1192de8 ui_ready"Any ideas?git version 1.6.0.2
--
View this message in context: http://n2.nabble.com/git-gui-rescane_stage2-error-on-windows-tp1129562p1129562.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: git gui rescane_stage2 error on windows
From: astubbs @ 2008-09-30 17:43 UTC (permalink / raw)
To: git
In-Reply-To: <1222796473795-1129562.post@n2.nabble.com>
Ok, that's odd. nabble and chrome ate the line breaks
Fresh install and fresh repository on Vista.
Getting this error when launching git gui:
child process exited abnormally
child process exited abnormally
while executing"close $fd"
(procedure "rescan_stage2" line 7)
invoked from within"rescan_stage2
file1192de8 ui_ready"
Any ideas?git version 1.6.0.2
git version 1.6.0.2
astubbs wrote:
>
> Fresh install and fresh repository on Vista.Getting this error when
> launching git gui:child process exited abnormallychild process exited
> abnormally while executing"close $fd" (procedure "rescan_stage2"
> line 7) invoked from within"rescan_stage2 file1192de8 ui_ready"Any
> ideas?git version 1.6.0.2
>
--
View this message in context: http://n2.nabble.com/git-gui-rescane_stage2-error-on-windows-tp1129562p1129570.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: What's cooking in git/spearce.git (Sep 2008, #04; Mon, 22)
From: Shawn O. Pearce @ 2008-09-30 18:28 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0809300545m7bc39fb8v2a724c05141d8d37@mail.gmail.com>
Alex Riesen <raa.lkml@gmail.com> wrote:
> 2008/9/30 Alex Riesen <raa.lkml@gmail.com>:
> > 2008/9/29 Shawn O. Pearce <spearce@spearce.org>:
> >> Here are the topics that have been cooking. Commits prefixed
> >> with '-' are only in 'pu' while commits prefixed with '+' are
> >> in 'next'.
> >
> > Would you mind adding the remove_path factorization patches
> > in there somewhere?
> >
> > http://marc.info/?l=git&m=122246984212129&w=4
> > http://marc.info/?l=git&m=122246997012269&w=4
>
> Oh, I see: they're in your master
Yea. They were trivial enough that I didn't see a reason to hold
off on applying them. That section of code has been difficult to
deal with merge conflicts on, due to all of the code moving around.
Ironically enough, its the merge code itself that is ugly to
merge... ;-)
--
Shawn.
^ permalink raw reply
* Re: What's cooking in git/spearce.git (Sep 2008, #04; Mon, 22)
From: Shawn O. Pearce @ 2008-09-30 18:36 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <48E1DAC2.7070304@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> wrote:
> > * mg/maint-remote-fix (Mon Sep 22 10:57:51 2008 +0200) 1 commit
> > + make "git remote" report multiple URLs
...
> > The above two are ready for 'maint'.
>
> They are already in maint, as per "What's in..." and the repo.
*sigh*.
I sent out issue #4. Not #5 like I should have.
--
Shawn.
^ permalink raw reply
* What's cooking in git.git (Sep 2008, #05; Mon, 29)
From: Shawn O. Pearce @ 2008-09-30 18:37 UTC (permalink / raw)
To: git
Sorry for sending out two issues in two days; yesterday I resent
issue #4 by mistake. :-)
Everything below is worded for yesterday, as that is when I wrote
it, and when I meant to mail it.
*sigh*
----
Here are the topics that have been cooking. Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'.
The topics list the commits in reverse chronological order. The topics
meant to be merged to the maintenance series have "maint-" in their names.
If I have dropped anything recently its not because I don't want
to apply it, it just slipped through the cracks. Please feel free
to give me a gentle prod (and a patch resend or a pointer to the
series on gmane). Thanks.
----------------------------------------------------------------
[New Topics]
* gb/gitweb-pathinfo (Mon Sep 29 17:26:57 2008 +0200) 4 commits
- gitweb: generate parent..current URLs
- gitweb: parse parent..current syntax from pathinfo
- gitweb: generate project/action/hash URLs
- gitweb: parse project/action/hash_base:filename PATH_INFO
This series just came in today. I haven't had a chance to look at
it beyond stashing in `pu`.
* mw/sendemail (Mon Sep 29 12:41:06 2008 -0500) 8 commits
- send-email: signedoffcc -> signedoffbycc, but handle both
- Docs: send-email: Create logical groupings for man text
- Docs: send-email: Remove unnecessary config variable description
- Docs: send-email: --chain_reply_to -> --[no-]chain-reply-to
- send-email: change --no-validate to boolean --[no-]validate
- Docs: send-email: Man page option ordering
- Docs: send-email usage text much sexier
- Docs: send-email's usage text and man page mention same options
This series has already gone through 3 iterations before I could
start to carry it in-tree. I haven't had a chance to read it yet
myself, so its sitting around in `pu` for futher review.
* pb/gitweb (Thu Sep 25 18:48:48 2008 +0200) 2 commits
- gitweb: Sort the list of forks on the summary page by age
- gitweb: Clean-up sorting of project list
I forgot to look at this series today. I meant to review and try
to merge it to `next` before publishing. Will do that tomorrow.
* ae/preservemerge (Tue Sep 23 22:58:20 2008 +0200) 3 commits
- git pull: Support --preserve-merges as a flag to rebase
- git rebase: Support non-interactive merge-preserving rebase
- Prepare for non-interactive merge-preserving rebase
Andreas says there's some issues in here. I'm waiting for a respin
on the series before I look at it futher.
* mg/verboseprune (Mon Sep 29 18:49:52 2008 +0200) 1 commit
- make prune report removed objects on -v
Just came in today. Looks sane. I'll drop it onto `next` tomorrow.
----------------------------------------------------------------
[Graduated to "master"]
* mv/merge-recursive (Sat Sep 6 18:29:49 2008 +0200) 11 commits
+ builtin-merge: release the lockfile in try_merge_strategy()
+ merge-recursive: get rid of virtual_id
+ merge-recursive: move current_{file,directory}_set to struct
merge_options
+ merge-recursive: move the global obuf to struct merge_options
+ merge-recursive: get rid of the index_only global variable
+ merge-recursive: move call_depth to struct merge_options
+ cherry-pick/revert: make direct internal call to merge_tree()
+ builtin-merge: avoid run_command_v_opt() for recursive and subtree
+ merge-recursive: introduce merge_options
+ merge-recursive.c: Add more generic merge_recursive_generic()
+ Split out merge_recursive() to merge-recursive.c
(Tip at 4271666)
* ho/dirstat-by-file (Fri Sep 5 22:27:35 2008 +0300) 1 commit
+ diff --dirstat-by-file: count changed files, not lines
(Tip at fd33777)
* jc/safe-c-l-d (Tue Sep 2 14:10:15 2008 -0700) 1 commit
+ safe_create_leading_directories(): make it about "leading"
directories
(Tip at 5f0bdf5)
* jc/apply-include-exclude (Mon Aug 25 01:05:31 2008 -0700) 1 commit
+ git-apply:--include=pathspec
(Tip at 6ecb1ee)
* mv/commit-tree (Wed Sep 10 22:10:33 2008 +0200) 3 commits
+ t7603: add new testcases to ensure builtin-commit uses
reduce_heads()
+ builtin-commit: use commit_tree()
+ commit_tree(): add a new author parameter
(Tip at 7a172b0)
* pb/autocorrect-wrapper (Wed Sep 10 17:54:28 2008 +0200) 1 commit
+ git wrapper: also use aliases to correct mistyped commands
(Tip at 746c221)
* jc/better-conflict-resolution (Thu Sep 4 23:48:48 2008 +0200) 15 commits
+ Fix AsciiDoc errors in merge documentation
+ git-merge documentation: describe how conflict is presented
+ checkout --conflict=<style>: recreate merge in a non-default style
+ checkout -m: recreate merge when checking out of unmerged index
+ Merge branch 'jc/maint-checkout-fix' into 'jc/better-conflict-
resolution'
+ git-merge-recursive: learn to honor merge.conflictstyle
+ merge.conflictstyle: choose between "merge" and "diff3 -m" styles
+ rerere: understand "diff3 -m" style conflicts with the original
+ rerere.c: use symbolic constants to keep track of parsing states
+ xmerge.c: "diff3 -m" style clips merge reduction level to EAGER or
less
+ xmerge.c: minimum readability fixups
+ xdiff-merge: optionally show conflicts in "diff3 -m" style
+ xdl_fill_merge_buffer(): separate out a too deeply nested function
+ checkout --ours/--theirs: allow checking out one side of a
conflicting merge
+ checkout -f: allow ignoring unmerged paths when checking out of
the index
(Tip at 3407a7a)
* jc/alternate-push (Tue Sep 9 01:27:10 2008 -0700) 4 commits
+ push: receiver end advertises refs from alternate repositories
+ push: prepare sender to receive extended ref information from the
receiver
+ receive-pack: make it a builtin
+ is_directory(): a generic helper function
(Tip at d79796b)
* bc/master-diff-hunk-header-fix (Sat Sep 20 18:36:22 2008 -0700) 10 commits
+ Merge branch 'bc/maint-diff-hunk-header-fix' into bc/master-diff-
hunk-header-fix
+ diff hunk pattern: fix misconverted "\{" tex macro introducers
+ diff: fix "multiple regexp" semantics to find hunk header comment
+ diff: use extended regexp to find hunk headers
+ Merge branch 'bc/maint-diff-hunk-header-fix' into bc/master-diff-
hunk-header-fix
+ diff: use extended regexp to find hunk headers
+ Merge branch 'bc/maint-diff-hunk-header-fix' into bc/master-diff-
hunk-header-fix
+ diff.*.xfuncname which uses "extended" regex's for hunk header
selection
+ diff.c: associate a flag with each pattern and use it for
compiling regex
+ diff.c: return pattern entry pointer rather than just the hunk
header pattern
(Tip at 92bb978)
* am/status (Mon Sep 8 00:05:03 2008 +0200) 2 commits
+ wt-status: Teach how to discard changes in the working directory
+ wt-status: Split header generation into three functions
(Tip at 4d6e4c4)
* mg/maint-remote-fix (Mon Sep 22 10:57:51 2008 +0200) 1 commit
+ make "git remote" report multiple URLs
(Tip at 7d20e21)
* bc/maint-diff-hunk-header-fix (Sat Sep 20 15:30:12 2008 -0700) 5 commits
+ diff hunk pattern: fix misconverted "\{" tex macro introducers
+ diff: use extended regexp to find hunk headers
+ diff.*.xfuncname which uses "extended" regex's for hunk header
selection
+ diff.c: associate a flag with each pattern and use it for
compiling regex
+ diff.c: return pattern entry pointer rather than just the hunk
header pattern
(Tip at 96d1a8e)
----------------------------------------------------------------
[Old New Topics]
* nd/narrow (Sun Sep 14 20:07:59 2008 +0700) 9 commits
- grep: skip files that have not been checked out
- checkout_entry(): CE_NO_CHECKOUT on checked out entries.
- Prevent diff machinery from examining worktree outside narrow
checkout
- Add tests for updating no-checkout entries in index
- ls-files: add --narrow-checkout option to "will checkout" entries
- update-index: add --checkout/--no-checkout to update
CE_NO_CHECKOUT bit
- update-index: refactor mark_valid() in preparation for new options
- Introduce CE_NO_CHECKOUT bit
- Extend index to save more flags
[jc: This is an early half of the earlier series (I haven't had
chance to look at the updated series yet), and should be replaced
with the updated one posted recently.]
I haven't touched this branch since I inherited it from Junio.
I'd appreciate a resend or a pointer to the updated series so I
can at least replace it.
----------------------------------------------------------------
[Stalled -- Needs Action to Proceed (or to be dropped)]
* pb/submodule (Fri Sep 12 23:09:19 2008 +0200) 1 commit
- t7400: Add short "git submodule add" testsuite
[jc: Waiting for a reroll.]
* bd/blame (Thu Aug 21 18:22:01 2008 -0500) 5 commits
- Use xdiff caching to improve git blame performance
- Allow xdiff machinery to cache hash results for a file
- Always initialize xpparam_t to 0
- Bypass textual patch generation and parsing in git blame
- Allow alternate "low-level" emit function from xdl_diff
[jc: Réne had good comments on how the callback should be
structured.]
* kb/am-directory (Fri Aug 29 15:27:50 2008 -0700) 1 commit
- git-am: Pass the --directory option through to git-apply
[jc: I think this is still buggy and drops the option when am stops
with conflicts.]
All three of these are stalled. I'm not going to drop them just
yet, but Junio's comments still hold. If there's no action on
these next week we may seem them drop off.
----------------------------------------------------------------
[Will be merged to 'master/maint' soon]
* jc/add-ita (Thu Aug 21 01:44:53 2008 -0700) 1 commit
+ git-add --intent-to-add (-N)
Teaches "git add" to record only the intent to add a path later.
[jc: I rerolled this without the fake empty blob object.]
I'm inclined to merge this next week.
(Tip at 3942581)
----------------------------------------------------------------
[Actively Cooking]
* tr/workflow-doc (Sat Sep 13 18:11:01 2008 +0200) 2 commits
+ Documentation: Refer to git-rebase(1) to warn against rewriting
+ Documentation: new upstream rebase recovery section in git-rebase
[jc: My impression from the last round of discusson on the third
patch in this series (not queued here) was that as long as we
do not present it as "One True Workflow", the description was
a good starting point, possibly others to add other recommended
flows later.]
I haven't looked at this series yet. Based on Junios remarks above
I'm looking for more input on this series before it goes anywhere.
* pb/commit-where (Mon Sep 8 01:05:41 2008 +0200) 1 commit
+ builtin-commit.c: show on which branch a commit was added
[jc: Tentatively kicked back to "still cooking" status after
Jeff voiced his annoyance. I personally do not like making this
multi-line as Jeff suggested as an alternative (the message already
is too verbose to my taste).]
Agree with Junio. Hence its still here.
* lt/time-reject-fractional-seconds (Sat Aug 16 21:25:40 2008 -0700) 1 commit
+ date/time: do not get confused by fractional seconds
I need to look at this in more detail. I suspect we can merge
this to master soon, but its been kicking around since Aug 16th.
I need to look at it to see if there's any obvious reason why Junio
has no notes on this branch and why it hasn't merged yet.
----------------------------------------------------------------
[On Hold]
* jc/post-simplify (Fri Aug 15 01:34:51 2008 -0700) 2 commits
- revision --simplify-merges: incremental simplification
- revision --simplify-merges: prepare for incremental simplification
[jc: I started making this incremental but the progress is not so great.]
* jc/stripspace (Sun Mar 9 00:30:35 2008 -0800) 6 commits
- git-am --forge: add Signed-off-by: line for the author
- git-am: clean-up Signed-off-by: lines
- stripspace: add --log-clean option to clean up signed-off-by:
lines
- stripspace: use parse_options()
- Add "git am -s" test
- git-am: refactor code to add signed-off-by line for the committer
[jc: The one at second from the tip needs reworking.]
* jc/send-pack-tell-me-more (Thu Mar 20 00:44:11 2008 -0700) 1 commit
- "git push": tellme-more protocol extension
* jc/merge-whitespace (Sun Feb 24 23:29:36 2008 -0800) 1 commit
. WIP: start teaching the --whitespace=fix to merge machinery
This has a merge conflict with `next` and isn't even in pu right now.
* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 2 commits
- blame: show "previous" information in --porcelain/--incremental
format
- git-blame: refactor code to emit "porcelain format" output
I should look at this in more detail. We may be able to merge it
to next soon-ish.
* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 1 commit
+ merge: remove deprecated summary and diffstat options and config
variables
[jc: This was previously in "will be in master soon" category,
but it turns out that the synonyms to the ones this one deletes
are fairly new invention that happend in 1.5.6 timeframe, and
we cannot do this just yet. Perhaps in 1.7.0, but with the loud
whining about moving git-foo out of $PATH we have been hearing,
it might not be a bad idea to drop this.]
* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 1 commit
- diff: enable "too large a rename" warning when -M/-C is explicitly
asked for
[jc: This would be the right thing to do for command line use,
but gitk will be hit due to tcl/tk's limitation, so I am holding
this back for now.]
--
Shawn.
^ permalink raw reply
* [GUILT] Use git_editor
From: Alan Jenkins @ 2008-09-30 18:43 UTC (permalink / raw)
To: Josef 'Jeff' Sipek; +Cc: git
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
diff --git a/guilt b/guilt
index 1cef7b9..8d023e9 100755
--- a/guilt
+++ b/guilt
@@ -693,10 +693,6 @@ fi
series="$GUILT_DIR/$branch/series"
applied="$GUILT_DIR/$branch/status"
-# determine an editor to use for anything interactive (fall back to vi)
-editor="vi"
-[ ! -z "$EDITOR" ] && editor="$EDITOR"
-
# determine a pager to use for anything interactive (fall back to more)
pager="more"
[ ! -z "$PAGER" ] && pager="$PAGER"
diff --git a/guilt-header b/guilt-header
index da46c82..66521ac 100755
--- a/guilt-header
+++ b/guilt-header
@@ -46,7 +46,7 @@ if [ -z "$edit" ]; then
else
do_get_full_header "$GUILT_DIR/$branch/$patch" > "$TMP_MSG"
do_get_patch "$GUILT_DIR/$branch/$patch" > "$TMP_DIFF"
- $editor "$TMP_MSG"
+ git_editor "$TMP_MSG"
mv "$GUILT_DIR/$branch/$patch" "$GUILT_DIR/$branch/$patch~"
(
diff --git a/guilt-new b/guilt-new
index 05318a5..7845d00 100755
--- a/guilt-new
+++ b/guilt-new
@@ -77,7 +77,7 @@ mkdir_dir=`dirname "$GUILT_DIR/$branch/$patch"`
) >> "$GUILT_DIR/$branch/$patch"
# edit -e ?
-[ "$edit" = "t" ] && $editor "$GUILT_DIR/$branch/$patch"
+[ "$edit" = "t" ] && git_editor "$GUILT_DIR/$branch/$patch"
if [ ! -z "$force" ]; then
(
diff --git a/guilt-series b/guilt-series
index 7d8f8e9..4f24ffd 100755
--- a/guilt-series
+++ b/guilt-series
@@ -22,7 +22,7 @@ do
done
if [ ! -z "$edit" ]; then
- $editor "$series"
+ git_editor "$series"
elif [ ! -z "$gui" ]; then
[ -z "`get_top`" ] && die "No patches applied."
bottom=`git rev-parse refs/patches/$branch/$(head -1 $applied)`
^ permalink raw reply related
* Re: How Blobs Work ( Blobs Vs. Deltas)
From: Jakub Narebski @ 2008-09-30 18:54 UTC (permalink / raw)
To: Feanil Patel; +Cc: git
In-Reply-To: <16946e800809300814v134a42dft37becdbd8aa7669a@mail.gmail.com>
"Feanil Patel" <feanil@gmail.com> writes:
> Hello,
>
> I was reading about git objects in "The Git Community Book"
> (http://book.git-scm.com/1_the_git_object_model.html), which was
> posted on the mailing list a while back, and I was wondering something
> about blobs and how files are stored in any particular version. If
> file A is changed from version one to version two there are two
> different blobs that exist for the two versions of the file, is that
> correct? The Book was saying Git does not use delta storage so does
> this mean that there are two almost identical copies of the file with
> the difference being the change that was put in from version one to
> version two?
In Git there are two kinds of storage: loose objects and packs. Each
object generally starts as a loose object; for those it is like you
wrote: if you have two versions of some file, you would have both
of those contents of a file stored as separate objects (blobs). Note
that those 'blob' objects are compressed, so they usually don't take
more time than current version of file and its backup.
But there exists also other type of storage, namely packed. In the
past you had to pack (repack) objects by invoking "git repack" and
"git prune", and in more modern times by calling "git gc"; nowadays
this should be taken care of by git using "git gc --auto" behind.
When packing git tries to find objects which are close contents,
and store them as base object and binary delta (based on LibXDiff).
So you get benefits of delta storage, while on the API and script
level you always see single objects.
Note that explicit repacking allow git to not only consider versions
of the same file to diff against, tree and not only linear chains of
deltas (think branches), and while recency order is preferred it is
not enforced; objects and deltas are then compressed individually.
HTH
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] doc: enhance git describe --tags help
From: Shawn O. Pearce @ 2008-09-30 19:04 UTC (permalink / raw)
To: Uwe Kleine-KKKnig
Cc: Pierre Habouzit, Erez Zilber, git@vger.kernel.org, open-iscsi,
Junio C Hamano
In-Reply-To: <20080930095641.GA9001@strlen.de>
Uwe Kleine-KKKnig <ukleinek@strlen.de> wrote:
> On Mon, Sep 29, 2008 at 08:01:27AM -0700, Shawn O. Pearce wrote:
> > --tags::
> > If a lightweight tag exactly matches, output it. If no
> > annotated tag is found in the ancestry but a lightweight
> > tag is found, output the lightweight tag.
>
> IMHO --tags should behave as Erez expected (because it's what I
> expected, too). As --tags currently behaves it's only usable in very
> rare cases (most of the time it only makes a difference on repos without
> any annotated tag).
>
> When do you pass --tags? Only if a lightweight tag is OK for an answer.
> And then I would prefer a "near" lightweight tag to a "farer" annotated
> one.
I don't disagree. I've been tempted to write a patch to change the
behavior of git-describe so that --tags and --all control what names
are inserted into the candidate list, but don't control the ordering
of their selection.
I think this is all that is needed to make the behavior do what you
and Erez expected. But its a pretty big change in the results if
you are passing in --all or --tags today.
--8<--
[WIP] Change meaning of --tags and --all
---
builtin-describe.c | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/builtin-describe.c b/builtin-describe.c
index ec404c8..fd54fec 100644
--- a/builtin-describe.c
+++ b/builtin-describe.c
@@ -15,8 +15,8 @@ static const char * const describe_usage[] = {
};
static int debug; /* Display lots of verbose info */
-static int all; /* Default to annotated tags only */
-static int tags; /* But allow any tags if --tags is specified */
+static int all; /* Any valid ref can be used */
+static int tags; /* Either lightweight or annotated tags */
static int longformat;
static int abbrev = DEFAULT_ABBREV;
static int max_candidates = 10;
@@ -112,8 +112,6 @@ static int compare_pt(const void *a_, const void *b_)
{
struct possible_tag *a = (struct possible_tag *)a_;
struct possible_tag *b = (struct possible_tag *)b_;
- if (a->name->prio != b->name->prio)
- return b->name->prio - a->name->prio;
if (a->depth != b->depth)
return a->depth - b->depth;
if (a->found_order != b->found_order)
--
1.6.0.2.513.g6dbd
--
Shawn.
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox