* 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
* 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
* [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
* 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] 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: 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
* 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: [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: [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: 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: 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: 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
* 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: [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
* 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
* [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
* [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
* 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] 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
* [PATCH] t0024: add executable permission
From: SZEDER Gábor @ 2008-09-30 13:32 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, SZEDER Gábor
---
0 files changed, 0 insertions(+), 0 deletions(-)
mode change 100644 => 100755 t/t0024-crlf-archive.sh
diff --git a/t/t0024-crlf-archive.sh b/t/t0024-crlf-archive.sh
old mode 100644
new mode 100755
--
1.6.0.2.448.g0c4e5
^ permalink raw reply
* [PATCH 3/9] Docs: send-email: Man page option ordering
From: Michael Witten @ 2008-09-30 12:58 UTC (permalink / raw)
To: spearce; +Cc: git
In-Reply-To: <1222779512-58936-2-git-send-email-mfwitten@mit.edu>
Now the man page lists the options in alphabetical
order (in terms of the 'main' part of an option's
name).
Signed-off-by: Michael Witten <mfwitten@mit.edu>
---
Documentation/git-send-email.txt | 138 ++++++++++++++++++--------------------
1 files changed, 66 insertions(+), 72 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 9b31626..0c6dbf6 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -11,7 +11,6 @@ SYNOPSIS
'git send-email' [options] <file|directory> [... file|directory]
-
DESCRIPTION
-----------
Takes the patches given on the command line and emails them out.
@@ -45,19 +44,35 @@ The --cc option must be repeated for each user you want on the cc list.
email sent. If disabled with "--no-chain-reply-to", all emails after
the first will be sent as replies to the first email sent. When using
this, it is recommended that the first file given be an overview of the
- entire patch series.
- Default is the value of the 'sendemail.chainreplyto' configuration
- value; if that is unspecified, default to --chain-reply-to.
+ entire patch series. Default is the value of the 'sendemail.chainreplyto'
+ configuration value; if that is unspecified, default to --chain-reply-to.
--compose::
Use $GIT_EDITOR, core.editor, $VISUAL, or $EDITOR to edit an
introductory message for the patch series.
+--dry-run::
+ Do everything except actually send the emails.
+
+--envelope-sender::
+ Specify the envelope sender used to send the emails.
+ This is useful if your default address is not the address that is
+ subscribed to a list. If you use the sendmail binary, you must have
+ suitable privileges for the -f parameter. Default is the value of
+ the 'sendemail.envelopesender' configuration variable; if that is
+ unspecified, choosing the envelope sender is left to your MTA.
+
--from::
Specify the sender of the emails. This will default to
the value GIT_COMMITTER_IDENT, as returned by "git var -l".
The user will still be prompted to confirm this entry.
+--identity::
+ A configuration identity. When given, causes values in the
+ 'sendemail.<identity>' subsection to take precedence over
+ values in the 'sendemail' section. The default identity is
+ the value of 'sendemail.identity'.
+
--in-reply-to::
Specify the contents of the first In-Reply-To header.
Subsequent emails will refer to the previous email
@@ -65,21 +80,40 @@ The --cc option must be repeated for each user you want on the cc list.
Only necessary if --compose is also set. If --compose
is not set, this will be prompted for.
---[no-]signed-off-by-cc::
- If this is set, add emails found in Signed-off-by: or Cc: lines to the
- cc list.
- Default is the value of 'sendemail.signedoffcc' configuration value;
- if that is unspecified, default to --signed-off-by-cc.
-
--quiet::
Make git-send-email less verbose. One line per email should be
all that is output.
---identity::
- A configuration identity. When given, causes values in the
- 'sendemail.<identity>' subsection to take precedence over
- values in the 'sendemail' section. The default identity is
- the value of 'sendemail.identity'.
+--[no-]signed-off-by-cc::
+ If this is set, add emails found in Signed-off-by: or Cc: lines to the
+ cc list. Default is the value of 'sendemail.signedoffcc' configuration
+ value; if that is unspecified, default to --signed-off-by-cc.
+
+--smtp-encryption::
+ Specify the encryption to use, either 'ssl' or 'tls'. Any other
+ value reverts to plain SMTP. Default is the value of
+ 'sendemail.smtpencryption'.
+
+--smtp-pass::
+ Password for SMTP-AUTH. The argument is optional: If no
+ argument is specified, then the empty string is used as
+ the password.
++
+In place of this option, the following configuration variables
+can be specified:
++
+--
+ * sendemail.smtppass
+ * sendemail.<identity>.smtppass (see sendemail.identity).
+--
++
+However, --smtp-pass always overrides these variables.
++
+Furthermore, passwords need not be specified in configuration files
+or on the command line. If a username has been specified (with
+--smtp-user or a configuration variable), but no password has been
+specified (with --smtp-pass or a configuration variable), then the
+user is prompted for a password while the input is masked for privacy.
--smtp-server::
If set, specifies the outgoing SMTP server to use (e.g.
@@ -96,6 +130,9 @@ The --cc option must be repeated for each user you want on the cc list.
servers typically listen to smtp port 25 and ssmtp port
465).
+--smtp-ssl::
+ Legacy alias for '--smtp-encryption=ssl'.
+
--smtp-user::
Username for SMTP-AUTH. In place of this option, the following
configuration variables can be specified:
@@ -110,45 +147,11 @@ However, --smtp-user always overrides these variables.
If a username is not specified (with --smtp-user or a
configuration variable), then authentication is not attempted.
---smtp-pass::
- Password for SMTP-AUTH. The argument is optional: If no
- argument is specified, then the empty string is used as
- the password.
-+
-In place of this option, the following configuration variables
-can be specified:
-+
---
- * sendemail.smtppass
- * sendemail.<identity>.smtppass (see sendemail.identity).
---
-+
-However, --smtp-pass always overrides these variables.
-+
-Furthermore, passwords need not be specified in configuration files
-or on the command line. If a username has been specified (with
---smtp-user or a configuration variable), but no password has been
-specified (with --smtp-pass or a configuration variable), then the
-user is prompted for a password while the input is masked for privacy.
-
---smtp-encryption::
- Specify the encryption to use, either 'ssl' or 'tls'. Any other
- value reverts to plain SMTP. Default is the value of
- 'sendemail.smtpencryption'.
-
---smtp-ssl::
- Legacy alias for '--smtp-encryption=ssl'.
-
--subject::
Specify the initial subject of the email thread.
Only necessary if --compose is also set. If --compose
is not set, this will be prompted for.
---[no-]suppress-from::
- If this is set, do not add the From: address to the cc: list.
- Default is the value of 'sendemail.suppressfrom' configuration value;
- if that is unspecified, default to --no-suppress-from.
-
--suppress-cc::
Specify an additional category of recipients to suppress the
auto-cc of. 'self' will avoid including the sender, 'author' will
@@ -160,24 +163,24 @@ user is prompted for a password while the input is masked for privacy.
if that is unspecified, default to 'self' if --suppress-from is
specified, as well as 'sob' if --no-signed-off-cc is specified.
+--[no-]suppress-from::
+ If this is set, do not add the From: address to the cc: list.
+ Default is the value of 'sendemail.suppressfrom' configuration
+ value; if that is unspecified, default to --no-suppress-from.
+
--[no-]thread::
If this is set, the In-Reply-To header will be set on each email sent.
If disabled with "--no-thread", no emails will have the In-Reply-To
- header set.
- Default is the value of the 'sendemail.thread' configuration value;
- if that is unspecified, default to --thread.
+ header set. Default is the value of the 'sendemail.thread' configuration
+ value; if that is unspecified, default to --thread.
---dry-run::
- Do everything except actually send the emails.
-
---envelope-sender::
- Specify the envelope sender used to send the emails.
- This is useful if your default address is not the address that is
- subscribed to a list. If you use the sendmail binary, you must have
- suitable privileges for the -f parameter.
- Default is the value of the 'sendemail.envelopesender' configuration
- variable; if that is unspecified, choosing the envelope sender is left
- to your MTA.
+--to::
+ Specify the primary recipient of the emails generated. Generally, this
+ will be the upstream maintainer of the project involved. Default is the
+ value of the 'sendemail.to' configuration value; if that is unspecified,
+ this will be prompted for.
++
+The --to option must be repeated for each user you want on the to list.
--no-validate::
Don't perform any sanity checks on patches.
@@ -188,15 +191,6 @@ user is prompted for a password while the input is masked for privacy.
is due to SMTP limits as described by http://www.ietf.org/rfc/rfc2821.txt.
--
---to::
- Specify the primary recipient of the emails generated.
- Generally, this will be the upstream maintainer of the
- project involved.
- Default is the value of the 'sendemail.to' configuration value;
- if that is unspecified, this will be prompted for.
-+
-The --to option must be repeated for each user you want on the to list.
-
CONFIGURATION
-------------
--
1.6.0.2.304.gdcf23.dirty
^ permalink raw reply related
* [PATCH 5/9] Docs: send-email: --chain_reply_to -> --[no-]chain-reply-to
From: Michael Witten @ 2008-09-30 12:58 UTC (permalink / raw)
To: spearce; +Cc: git
In-Reply-To: <1222779512-58936-4-git-send-email-mfwitten@mit.edu>
Signed-off-by: Michael Witten <mfwitten@mit.edu>
---
Documentation/git-send-email.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 81970f3..6b62032 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -221,7 +221,7 @@ sendemail.bcc::
Email address (or alias) to always bcc.
sendemail.chainreplyto::
- Boolean value specifying the default to the '--chain_reply_to'
+ Boolean value specifying the default to the '--[no-]chain-reply-to'
parameter.
sendemail.smtpserver::
--
1.6.0.2.304.gdcf23.dirty
^ permalink raw reply related
* [PATCH 9/9] send-email: signedoffcc -> signedoffbycc, but handle both
From: Michael Witten @ 2008-09-30 12:58 UTC (permalink / raw)
To: spearce; +Cc: git
In-Reply-To: <1222779512-58936-8-git-send-email-mfwitten@mit.edu>
The documentation now mentions sendemail.signedoffbycc instead
of sendemail.signedoffcc in order to match with the options
--signed-off-by-cc; the code has been updated to reflect this
as well, but sendemail.signedoffcc is still handled.
Signed-off-by: Michael Witten <mfwitten@mit.edu>
---
Documentation/git-send-email.txt | 2 +-
git-send-email.perl | 9 +++++----
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index d566c34..82f5056 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -144,7 +144,7 @@ Automating
--[no-]signed-off-by-cc::
If this is set, add emails found in Signed-off-by: or Cc: lines to the
- cc list. Default is the value of 'sendemail.signedoffcc' configuration
+ cc list. Default is the value of 'sendemail.signedoffbycc' configuration
value; if that is unspecified, default to --signed-off-by-cc.
--suppress-cc::
diff --git a/git-send-email.perl b/git-send-email.perl
index 80dae88..bdbfac6 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -151,7 +151,7 @@ if ($@) {
my ($quiet, $dry_run) = (0, 0);
# Variables with corresponding config settings
-my ($thread, $chain_reply_to, $suppress_from, $signed_off_cc, $cc_cmd);
+my ($thread, $chain_reply_to, $suppress_from, $signed_off_by_cc, $cc_cmd);
my ($smtp_server, $smtp_server_port, $smtp_authuser, $smtp_encryption);
my ($identity, $aliasfiletype, @alias_files, @smtp_host_parts);
my ($validate);
@@ -161,7 +161,8 @@ my %config_bool_settings = (
"thread" => [\$thread, 1],
"chainreplyto" => [\$chain_reply_to, 1],
"suppressfrom" => [\$suppress_from, undef],
- "signedoffcc" => [\$signed_off_cc, undef],
+ "signedoffbycc" => [\$signed_off_by_cc, undef],
+ "signedoffcc" => [\$signed_off_by_cc, undef], # Deprecated
"validate" => [\$validate, 1],
);
@@ -225,7 +226,7 @@ my $rc = GetOptions("sender|from=s" => \$sender,
"cc-cmd=s" => \$cc_cmd,
"suppress-from!" => \$suppress_from,
"suppress-cc=s" => \@suppress_cc,
- "signed-off-cc|signed-off-by-cc!" => \$signed_off_cc,
+ "signed-off-cc|signed-off-by-cc!" => \$signed_off_by_cc,
"dry-run" => \$dry_run,
"envelope-sender=s" => \$envelope_sender,
"thread!" => \$thread,
@@ -301,7 +302,7 @@ if ($suppress_cc{'all'}) {
# If explicit old-style ones are specified, they trump --suppress-cc.
$suppress_cc{'self'} = $suppress_from if defined $suppress_from;
-$suppress_cc{'sob'} = !$signed_off_cc if defined $signed_off_cc;
+$suppress_cc{'sob'} = !$signed_off_by_cc if defined $signed_off_by_cc;
# Debugging, print out the suppressions.
if (0) {
--
1.6.0.2.304.gdcf23.dirty
^ permalink raw reply related
* [PATCH 1/9] Docs: send-email's usage text and man page mention same options
From: Michael Witten @ 2008-09-30 12:58 UTC (permalink / raw)
To: spearce; +Cc: git
In-Reply-To: <20080929174445.GA6015@coredump.intra.peff.net>
Specifically, boolean options are now listed in the form
--[no-]option
and both forms of documentation now consistently use
--[no-]signed-off-by-cc
Signed-off-by: Michael Witten <mfwitten@mit.edu>
---
Documentation/git-send-email.txt | 21 +++++++++++++--------
git-send-email.perl | 8 ++++----
2 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 3c3e1b0..9b31626 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -40,8 +40,7 @@ The --cc option must be repeated for each user you want on the cc list.
Output of this command must be single email address per line.
Default is the value of 'sendemail.cccmd' configuration value.
---chain-reply-to::
---no-chain-reply-to::
+--[no-]chain-reply-to::
If this is set, each email will be sent as a reply to the previous
email sent. If disabled with "--no-chain-reply-to", all emails after
the first will be sent as replies to the first email sent. When using
@@ -66,8 +65,7 @@ The --cc option must be repeated for each user you want on the cc list.
Only necessary if --compose is also set. If --compose
is not set, this will be prompted for.
---signed-off-by-cc::
---no-signed-off-by-cc::
+--[no-]signed-off-by-cc::
If this is set, add emails found in Signed-off-by: or Cc: lines to the
cc list.
Default is the value of 'sendemail.signedoffcc' configuration value;
@@ -146,8 +144,7 @@ user is prompted for a password while the input is masked for privacy.
Only necessary if --compose is also set. If --compose
is not set, this will be prompted for.
---suppress-from::
---no-suppress-from::
+--[no-]suppress-from::
If this is set, do not add the From: address to the cc: list.
Default is the value of 'sendemail.suppressfrom' configuration value;
if that is unspecified, default to --no-suppress-from.
@@ -163,8 +160,7 @@ user is prompted for a password while the input is masked for privacy.
if that is unspecified, default to 'self' if --suppress-from is
specified, as well as 'sob' if --no-signed-off-cc is specified.
---thread::
---no-thread::
+--[no-]thread::
If this is set, the In-Reply-To header will be set on each email sent.
If disabled with "--no-thread", no emails will have the In-Reply-To
header set.
@@ -183,6 +179,15 @@ user is prompted for a password while the input is masked for privacy.
variable; if that is unspecified, choosing the envelope sender is left
to your MTA.
+--no-validate::
+ Don't perform any sanity checks on patches.
+ Currently, validation means the following:
++
+--
+ * Warn of patches that contain lines longer than 998 characters; this
+ is due to SMTP limits as described by http://www.ietf.org/rfc/rfc2821.txt.
+--
+
--to::
Specify the primary recipient of the emails generated.
Generally, this will be the upstream maintainer of the
diff --git a/git-send-email.perl b/git-send-email.perl
index d2fd899..9f56162 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -64,11 +64,11 @@ Options:
Only used if --compose is also set. If --compose is not
set, this will be prompted for.
- --chain-reply-to If set, the replies will all be to the previous
+ --[no-]chain-reply-to If set, the replies will all be to the previous
email sent, rather than to the first email sent.
Defaults to on.
- --signed-off-cc Automatically add email addresses that appear in
+ --[no-]signed-off-by-cc Automatically add email addresses that appear in
Signed-off-by: or Cc: lines to the cc: list. Defaults to on.
--identity The configuration identity, a subsection to prioritise over
@@ -95,9 +95,9 @@ Options:
'cccmd' for the output of the cccmd, or 'all' to suppress
all of these.
- --suppress-from Suppress sending emails to yourself. Defaults to off.
+ --[no-]suppress-from Suppress sending emails to yourself. Defaults to off.
- --thread Specify that the "In-Reply-To:" header should be set on all
+ --[no-]thread Specify that the "In-Reply-To:" header should be set on all
emails. Defaults to on.
--quiet Make git-send-email less verbose. One line per email
--
1.6.0.2.304.gdcf23.dirty
^ permalink raw reply related
* [PATCH 4/9] send-email: change --no-validate to boolean --[no-]validate
From: Michael Witten @ 2008-09-30 12:58 UTC (permalink / raw)
To: spearce; +Cc: git
In-Reply-To: <1222779512-58936-3-git-send-email-mfwitten@mit.edu>
There is also now a configuration variable:
sendemail[.<identity>].validate
Signed-off-by: Michael Witten <mfwitten@mit.edu>
---
Documentation/git-send-email.txt | 9 +++++++--
git-send-email.perl | 9 +++++----
2 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 0c6dbf6..81970f3 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -182,14 +182,16 @@ configuration variable), then authentication is not attempted.
+
The --to option must be repeated for each user you want on the to list.
---no-validate::
- Don't perform any sanity checks on patches.
+--[no-]validate::
+ Perform sanity checks on patches.
Currently, validation means the following:
+
--
* Warn of patches that contain lines longer than 998 characters; this
is due to SMTP limits as described by http://www.ietf.org/rfc/rfc2821.txt.
--
++
+This option can be set with sendemail[.<identity>].validate; default to --validate
CONFIGURATION
@@ -242,6 +244,9 @@ sendemail.smtpencryption::
sendemail.smtpssl::
Legacy boolean that sets 'smtpencryption=ssl' if enabled.
+sendemail.validate::
+ Boolean override for --[no-]validate.
+
Author
------
Written by Ryan Anderson <ryan@michonline.com>
diff --git a/git-send-email.perl b/git-send-email.perl
index 2c31a25..3467cf1 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -65,7 +65,7 @@ Options:
--smtp-ssl * Deprecated. Use '--smtp-encryption ssl'.
--quiet * Output one line of info per email.
--dry-run * Don't actually send the emails.
- --no-validate * Don't perform sanity checks on patches.
+ --[no-]validate * Perform patch sanity checks. Default on.
EOT
exit(1);
@@ -147,7 +147,7 @@ my ($quiet, $dry_run) = (0, 0);
my ($thread, $chain_reply_to, $suppress_from, $signed_off_cc, $cc_cmd);
my ($smtp_server, $smtp_server_port, $smtp_authuser, $smtp_encryption);
my ($identity, $aliasfiletype, @alias_files, @smtp_host_parts);
-my ($no_validate);
+my ($validate);
my (@suppress_cc);
my %config_bool_settings = (
@@ -155,6 +155,7 @@ my %config_bool_settings = (
"chainreplyto" => [\$chain_reply_to, 1],
"suppressfrom" => [\$suppress_from, undef],
"signedoffcc" => [\$signed_off_cc, undef],
+ "validate" => [\$validate, 1],
);
my %config_settings = (
@@ -221,7 +222,7 @@ my $rc = GetOptions("sender|from=s" => \$sender,
"dry-run" => \$dry_run,
"envelope-sender=s" => \$envelope_sender,
"thread!" => \$thread,
- "no-validate" => \$no_validate,
+ "validate!" => \$validate,
);
unless ($rc) {
@@ -374,7 +375,7 @@ for my $f (@ARGV) {
}
}
-if (!$no_validate) {
+if ($validate) {
foreach my $f (@files) {
unless (-p $f) {
my $error = validate_patch($f);
--
1.6.0.2.304.gdcf23.dirty
^ 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