* [PATCH] Documentation/fetch-options.txt: order options alphabetically
From: Jari Aalto @ 2009-10-21 20:07 UTC (permalink / raw)
To: git
Signed-off-by: Jari Aalto <jari.aalto@cante.net>
---
Documentation/fetch-options.txt | 48 +++++++++++++++++++-------------------
1 files changed, 24 insertions(+), 24 deletions(-)
diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
index 5eb2b0e..2886874 100644
--- a/Documentation/fetch-options.txt
+++ b/Documentation/fetch-options.txt
@@ -1,25 +1,13 @@
-ifndef::git-pull[]
--q::
---quiet::
- Pass --quiet to git-fetch-pack and silence any other internally
- used git commands.
-
--v::
---verbose::
- Be verbose.
-endif::git-pull[]
-
-a::
--append::
Append ref names and object names of fetched refs to the
existing contents of `.git/FETCH_HEAD`. Without this
option old data in `.git/FETCH_HEAD` will be overwritten.
---upload-pack <upload-pack>::
- When given, and the repository to fetch from is handled
- by 'git-fetch-pack', '--exec=<upload-pack>' is passed to
- the command to specify non-default path for the command
- run on the other end.
+--depth=<depth>::
+ Deepen the history of a 'shallow' repository created by
+ `git clone` with `--depth=<depth>` option (see linkgit:git-clone[1])
+ by the specified number of commits.
-f::
--force::
@@ -29,6 +17,10 @@ endif::git-pull[]
fetches is a descendant of `<lbranch>`. This option
overrides that check.
+-k::
+--keep::
+ Keep downloaded pack.
+
ifdef::git-pull[]
--no-tags::
endif::git-pull[]
@@ -49,10 +41,6 @@ endif::git-pull[]
flag lets all tags and their associated objects be
downloaded.
--k::
---keep::
- Keep downloaded pack.
-
-u::
--update-head-ok::
By default 'git-fetch' refuses to update the head which
@@ -62,7 +50,19 @@ endif::git-pull[]
implementing your own Porcelain you are not supposed to
use it.
---depth=<depth>::
- Deepen the history of a 'shallow' repository created by
- `git clone` with `--depth=<depth>` option (see linkgit:git-clone[1])
- by the specified number of commits.
+--upload-pack <upload-pack>::
+ When given, and the repository to fetch from is handled
+ by 'git-fetch-pack', '--exec=<upload-pack>' is passed to
+ the command to specify non-default path for the command
+ run on the other end.
+
+ifndef::git-pull[]
+-q::
+--quiet::
+ Pass --quiet to git-fetch-pack and silence any other internally
+ used git commands.
+
+-v::
+--verbose::
+ Be verbose.
+endif::git-pull[]
--
1.6.4.3
^ permalink raw reply related
* Re: [Foundation-l] Wikipedia meets git
From: jamesmikedupont @ 2009-10-21 20:08 UTC (permalink / raw)
To: Bernie Innocenti; +Cc: Samuel Klein, Wikimedia Foundation Mailing List, git
In-Reply-To: <1256154567.1477.87.camel@giskard>
Wow,
I am impressed.
Let me remind you of one thing,
most people are working on very small subsets of the data. Very few
people will want to have all the data, think about getting all the
versions from all the git repos, it would be the same.
My idea is for smaller chapters who want to get started easily, or
towns, regions to host their own branches of relevant data.
Given a world full of such servers, the sum would be great but the
individual branches needed at one time would be small.
mike
On Wed, Oct 21, 2009 at 9:49 PM, Bernie Innocenti <bernie@codewiz.org> wrote:
> [cc+=git@vger.kernel.org]
>
> El Wed, 21-10-2009 a las 08:43 -0400, Samuel Klein escribió:
>> That sounds like a great idea. I know a few other people who have
>> worked on git-based wikis and toyed with making them compatible with
>> mediawiki (copying bernie innocenti, one of the most eloquent :).
>
> Then I'll do my best to sound as eloquent as expected :)
>
> While I think git's internal structure is wonderfully simple and
> elegant, I'm a little worried about its scalability in the wiki usecase.
>
> The scenario for which git's repository format was designed is "patch
> oriented" revision control of a filesystem tree. The central object of a
> git tree is the "commit", which represents a set of changes on multiple
> files. I'll disregard all the juicy details on how the changes are
> actually packed together to save disk space, making git's repository
> format amazingly compact.
>
> Commits are linked to each other in order to represent the history. Git
> can efficiently represent a highly non-linear history with thousands of
> branches, each containing hundreds of thousands revisions. Branching and
> merging huge trees is so fast that one is left wondering if anything has
> happened at all.
>
> So far, so good. This commit-oriented design is great if you want to
> track the history *the whole tree* at once, applying related changes to
> multiple files atomically. In Git, as well as most other version control
> systems, there's no such thing as a *file* revision! Git manages entire
> trees. Trees are assigned unique revision numbers (in fact, ugly sha-1
> hashes), and can optionally by tagged or branched at will.
>
> And here's the the catch: the history of individual files is not
> directly represented in a git repository. It is typically scattered
> across thousands of commit objects, with no direct links to help find
> them. If you want to retrieve the log of a file that was changed only 6
> times in the entire history of the Linux kernel, you'd have to dig
> through *all* of the 170K revisions in the "master" branch.
>
> And it takes some time even if git is blazingly fast:
>
> bernie@giskard:~/src/kernel/linux-2.6$ time git log --pretty=oneline REPORTING-BUGS | wc -l
> 6
>
> real 0m1.668s
> user 0m1.416s
> sys 0m0.210s
>
> (my laptop has a low-power CPU. A fast server would be 8-10x faster).
>
>
> Now, the English Wikipedia seems to have slightly more than 3M articles,
> with--how many? tenths of millions of revisions for sure. Going through
> them *every time* one needs to consult the history of a file would be
> 100x slower. Tens of seconds. Not acceptable, uh?
>
> It seems to me that the typical usage pattern of an encyclopedia is to
> change each article individually. Perhaps I'm underestimating the role
> of bots here. Anyway, there's no consistency *requirement* for mass
> changes to be applied atomically throughout all the encyclopedia, right?
>
> In conclusion, the "tree at a time" design is going to be a performance
> bottleneck for a large wiki, with no useful application. Unless of
> course the concept of changesets was exposed in the UI, which would be
> an interesting idea to explore.
>
> Mercurial (Hg) seems to have a better repository layout for the "one
> file at a time" access pattern... Unfortunately, it's also much slower
> than git for almost any other purpose, sometimes by an order of
> magnitude. I'm not even sure how well Hg would cope with a repository
> containing 3M files and some 30M revisions. The largest Hg tree I've
> dealt with is the "mozilla central" repo, which is already unbearably
> slow to work with.
>
> It would be interesting to compare notes with the other DSCM hackers,
> too.
>
> --
> // Bernie Innocenti - http://codewiz.org/
> \X/ Sugar Labs - http://sugarlabs.org/
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [RFC] What to you think about a loose status for submodules?
From: Junio C Hamano @ 2009-10-21 20:23 UTC (permalink / raw)
To: Heiko Voigt; +Cc: git, Jens Lehmann, Lars Hjemli
In-Reply-To: <20091021160122.GA2067@book.hvoigt.net>
Heiko Voigt <hvoigt@hvoigt.net> writes:
> For such a workflow I would like to implement what I call 'loose'
> submodules. Where a
>
> git clone project.git
> cd project
> git submodule init && git submodule update
>
> would omit the 'help' folder. But in case I specify it directly like
I thought a blanket "submodule init/update" wasn't even a recommended
practice for this exact reason. We tried to keep the default not to
gratuitously populate and checkout all submodule repositories, but
probably what you are trying to do was made more difficult by mistake
because people who wanted the other behaviour pushed too hard?
Defaulting to "do not populate and checkout unless explicitly asked"
sounds like the right thing to do, and if we broke it, it should be
corrected, I think. Shouldn't it be a simple matter of teaching "--all"
option to "submodule init" (and "update") to let them blindly affect all
submodules, while making the default not to do anything?
> git submodule init help
>
> it would update to the recorded revision.
>
> Of course the relation would be configurable. E.g.:
>
> git config submodule."name".relation loose
>
> and the opposite as
>
> git config submodule."name".relation tight
I do not think this should be a project-wide configuration that is
recorded in .gitmodules; if you are "help documentation" participant to
the project you would want "help" submodule, and other people will want
different submodules.
It would probably make more sense to introduce the notion of "module
groups", similar to the way "remote update <group>" can name a group of
remotes to affect. Then documentation people can say
submodule init doc && submodule update
if .gitmodules file records the mapping from "doc" to one or more
submodules (e.g. "help" and "doc"). If we are going to take this route,
it would still make sense to teach "--all" to "submodule init" and perhaps
default to init the "default" group if one exists, instead of making the
parameterless "init" a no-op as I suggested earlier.
But it is quite a long time since I looked at git-submodule.sh so please
take the above with a healthy dose of salt.
^ permalink raw reply
* Re: [Foundation-l] Wikipedia meets git
From: Avery Pennarun @ 2009-10-21 20:31 UTC (permalink / raw)
To: Bernie Innocenti; +Cc: Samuel Klein, Wikimedia Foundation Mailing List, git
In-Reply-To: <1256154567.1477.87.camel@giskard>
On Wed, Oct 21, 2009 at 3:49 PM, Bernie Innocenti <bernie@codewiz.org> wrote:
> And here's the the catch: the history of individual files is not
> directly represented in a git repository. It is typically scattered
> across thousands of commit objects, with no direct links to help find
> them. If you want to retrieve the log of a file that was changed only 6
> times in the entire history of the Linux kernel, you'd have to dig
> through *all* of the 170K revisions in the "master" branch.
>
> And it takes some time even if git is blazingly fast:
>
> bernie@giskard:~/src/kernel/linux-2.6$ time git log --pretty=oneline REPORTING-BUGS | wc -l
> 6
>
> real 0m1.668s
> user 0m1.416s
> sys 0m0.210s
>
> (my laptop has a low-power CPU. A fast server would be 8-10x faster).
>
>
> Now, the English Wikipedia seems to have slightly more than 3M articles,
> with--how many? tenths of millions of revisions for sure. Going through
> them *every time* one needs to consult the history of a file would be
> 100x slower. Tens of seconds. Not acceptable, uh?
I think this slowness could be overcome using a simple cache of
filename -> commitid list, right?
That is, you run some variant of "git log --name-only" and, for each
file changed by each commit, add an element to the commit list for
that file. When committing in the future, use a hook that updates the
cache. When you want to view the history of a particular file, simply
retrieve exactly the list of commits in that file's commitlist, not
other commits.
It sounds like such a cache could be implemented quite easily outside
of git itself.
Would that help?
That said, I'll bet you find other performance glitches when you
import millions of files and tens/hundreds of millions of commits.
But we probably won't know what those problems are until someone
imports them :)
Have fun,
Avery
^ permalink raw reply
* Re: [PATCH] Documentation/fetch-options.txt: order options alphabetically
From: Junio C Hamano @ 2009-10-21 20:39 UTC (permalink / raw)
To: Jari Aalto; +Cc: git
In-Reply-To: <87eiow1pey.fsf@jondo.cante.net>
Jari Aalto <jari.aalto@cante.net> writes:
> Signed-off-by: Jari Aalto <jari.aalto@cante.net>
> ---
> Documentation/fetch-options.txt | 48 +++++++++++++++++++-------------------
> 1 files changed, 24 insertions(+), 24 deletions(-)
Does this even make sense when git-pull.txt itself includes files other
than this one? fetch-options.txt may begin with the description of -a
that is very early in the alphabetical sequence, but git-pull.txt includes
merge-options.txt before this file, whose contents would describe what
probably would come after -a (I didn't check). Also git-pull.txt itself
has description of --rebase and --no-rebase that definitely come before -a
(I did check).
^ permalink raw reply
* Re: [PATCH] Documentation/fetch-options.txt: order options alphabetically
From: Junio C Hamano @ 2009-10-21 20:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jari Aalto, git
In-Reply-To: <7vpr8g32ht.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Jari Aalto <jari.aalto@cante.net> writes:
>
>> Signed-off-by: Jari Aalto <jari.aalto@cante.net>
>> ---
>> Documentation/fetch-options.txt | 48 +++++++++++++++++++-------------------
>> 1 files changed, 24 insertions(+), 24 deletions(-)
>
> Does this even make sense when git-pull.txt itself includes files other
> than this one? fetch-options.txt may begin with the description of -a
> that is very early in the alphabetical sequence, but git-pull.txt includes
> merge-options.txt before this file, whose contents would describe what
> probably would come after -a (I didn't check). Also git-pull.txt itself
> has description of --rebase and --no-rebase that definitely come before -a
> (I did check).
Ah, in your defense ;-) I think you looked only at git-fetch.txt without
checking where else this file is included. Then the patch certainly is
understandable. It would probably make git-fetch.{1,html} easier to scan,
while making things not worse for git-pull.{1,html}
^ permalink raw reply
* Re: keeping track of where a patch begins
From: Nicolas Pitre @ 2009-10-21 20:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: E R, git, Jeff King
In-Reply-To: <7veiow4iqc.fsf@alter.siamese.dyndns.org>
On Wed, 21 Oct 2009, Junio C Hamano wrote:
> Nicolas Pitre <nico@fluxnic.net> writes:
>
> > On Wed, 21 Oct 2009, E R wrote:
> >
> >> What solutions have you come up with to either to catch or prevent
> >> this from happening? It is possible to determine what node a branch
> >> started from?
> >
> > This can be determined by looking at the gitk output.
> >
> > Also 'git merge-base' can give you that node, given the main branch and
> > the topic branch. See documentation about git-merge-base.
> >
> > Then if you need to move a branch to another starting node, then 'git
> > rebase' is what you need (again the git-rebase documentation is pretty
> > detailed).
>
> That is a correct way to diagnose the mistake and recover from it, but
> unfortunately it is a rather weak tool to identify the mistake in the
> first place.
Well... The "mistake" is probably going to be different depending on the
work flow used. I don't think there is a generic definition of such
mistakes.
In this case, simply having
if [ $(git merge-base $expected_branch_point $branch) != \
$(git rev-parse $expected_branch_point) ]; then
(complain/refuse the merge of $branch)
fi
should be quite sufficient as an enforcing proper branch policy. Of
course the $expected_branch_point is something that is determined
outside of Git.
> A branch in git, as Randal often used to say on #git, is an illusion---it
> points only at the top and does not identify the bottom.
>
> But it does _not_ have to stay that way at the Porcelain level.
>
> Here is a rough sketch of one possible solution. It is not fully thought
> out; the basic idea is probably sound but I did not try to exhaustively
> cover changes to various tools that are necessary to maintain the
> invariants this scheme requires.
I never came across a situation where such an elaborated scheme was
needed to actually record and maintain that information, or could be
really useful. And some branches might be built on top of a sub-branch
already, making the real branch's bottom the sub-branch's instead in a
given context. It all depends on the work flow and the convention used
for a project. And the tool has no way to figure that out (is this the
real branch bottom or should it be one or more level down?), etc.
> We probably could kill the other bird in the nearby thread that wants to
> add a description to a branch, if this scheme is fully implemented
Well, I think we gain in flexibility by keeping those things separate
though. Blending data structures together is not always a good thing.
We have reflog data separate from the refs themselves, so I think that
having .git/desc/refs/* containing simple text files would be good
enough and simple to implement/use.
Nicolas
^ permalink raw reply
* Re: [PATCH] git push: say that --tag can't be used with --all or --mirror in help text
From: Nanako Shiraishi @ 2009-10-21 21:21 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Miklos Vajna, Sebastian Pipping, git,
Bjorn Gustavsson
In-Reply-To: <20091021144203.GA30485@coredump.intra.peff.net>
Quoting Jeff King <peff@peff.net>
> On Mon, Oct 19, 2009 at 12:57:01PM +0900, Nanako Shiraishi wrote:
>
>> - OPT_BOOLEAN( 0 , "tags", &tags, "push tags"),
>> + OPT_BOOLEAN( 0 , "tags", &tags, "push tags (can't be used with --all nor --mirror"),
>
> Hmm. We apparently all managed to miss this typo. It's visually hard to
> notice because of the ")" closing the macro.
How embarrassing. Thank you for a fix.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [PATCH 3/3] git checkout --nodwim
From: Nanako Shiraishi @ 2009-10-21 21:21 UTC (permalink / raw)
To: Avery Pennarun
Cc: Junio C Hamano, Alex Riesen, git, Johannes Schindelin,
Jay Soffian
In-Reply-To: <32541b130910211029x2f4295c3w40dd13b3cdc7762c@mail.gmail.com>
Quoting Avery Pennarun <apenwarr@gmail.com>
> On Sun, Oct 18, 2009 at 3:53 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Helping hands in polishing it up is very welcome.
>
> I find the idea of an option for "don't do what I mean" to be pretty
> entertaining. Or maybe just misleading :)
>
> Have fun,
>
> Avery
As Junio asked for helping hands, let's try to be helpful and constructive.
Maybe "don't second-guess" explains it better?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [Foundation-l] Wikipedia meets git
From: Nicolas Pitre @ 2009-10-21 21:05 UTC (permalink / raw)
To: Bernie Innocenti; +Cc: Samuel Klein, Wikimedia Foundation Mailing List, git
In-Reply-To: <1256154567.1477.87.camel@giskard>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1818 bytes --]
On Wed, 21 Oct 2009, Bernie Innocenti wrote:
> And here's the the catch: the history of individual files is not
> directly represented in a git repository. It is typically scattered
> across thousands of commit objects, with no direct links to help find
> them. If you want to retrieve the log of a file that was changed only 6
> times in the entire history of the Linux kernel, you'd have to dig
> through *all* of the 170K revisions in the "master" branch.
>
> And it takes some time even if git is blazingly fast:
>
> bernie@giskard:~/src/kernel/linux-2.6$ time git log --pretty=oneline REPORTING-BUGS | wc -l
> 6
>
> real 0m1.668s
> user 0m1.416s
> sys 0m0.210s
>
> (my laptop has a low-power CPU. A fast server would be 8-10x faster).
>
>
> Now, the English Wikipedia seems to have slightly more than 3M articles,
> with--how many? tenths of millions of revisions for sure. Going through
> them *every time* one needs to consult the history of a file would be
> 100x slower. Tens of seconds. Not acceptable, uh?
>
> It seems to me that the typical usage pattern of an encyclopedia is to
> change each article individually. Perhaps I'm underestimating the role
> of bots here. Anyway, there's no consistency *requirement* for mass
> changes to be applied atomically throughout all the encyclopedia, right?
You certainly don't need to put all files in the same tree then.
Having the whole thing split according to some sections that are
unlikely to overlap would be the way to go. Therefore you could arrange
subsections to have their own branches with no other files in them, or
even rely on Git submodules. The partitioning doesn't necessarily have
to be one of the two extremes such as one branch per file à la CVS or
all files in the same branch/tree as Git does by default.
Nicolas
^ permalink raw reply
* [RFC PATCH 1/2] Fix applying a line when all following lines are deletions
From: Jeff Epler @ 2009-10-21 21:20 UTC (permalink / raw)
To: git; +Cc: Jeff Epler
In-Reply-To: <1256160023-29629-1-git-send-email-jepler@unpythonic.net>
If a diff looked like
@@
context
-del1
-del2
and you wanted to stage the deletion 'del1', the generated patch
wouldn't apply because it was missing the line 'del2' converted to
context, but this line was counted in the @@-line
---
lib/diff.tcl | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/lib/diff.tcl b/lib/diff.tcl
index bd5d189..066755b 100644
--- a/lib/diff.tcl
+++ b/lib/diff.tcl
@@ -664,6 +664,7 @@ proc apply_line {x y} {
}
set i_l $next_l
}
+ set patch "$patch$pre_context"
set patch "@@ -$hln,$n +$hln,[eval expr $n $sign 1] @@\n$patch"
if {[catch {
--
1.6.5.rc1.49.ge970
^ permalink raw reply related
* [RFC PATCH v2 0/2] git-gui: (un)stage a range of changes at once
From: Jeff Epler @ 2009-10-21 21:20 UTC (permalink / raw)
To: git; +Cc: Jeff Epler
Compared to the first version, I fixed a bug concerning staging line(s)
when all following lines are deletions (a preexisting bug in git-gui).
This version is made based off the master branch of git-gui.git, rather
than the master branch of git.git.
The first change fixes a long-standing git-gui bug in an area that the
new feature is rewriting anyway. If there's interest in the new feature
then maybe the two should just be squashed (using the message from the
second). If not, it'd be nice to see the bugfix applied anyway.
Jeff Epler (2):
Fix applying a line when all following lines are deletions
Make it possible to apply a range of changes at once
git-gui.sh | 15 +++-
lib/diff.tcl | 224 ++++++++++++++++++++++++++++++++--------------------------
2 files changed, 135 insertions(+), 104 deletions(-)
^ permalink raw reply
* [RFC PATCH 2/2] Make it possible to apply a range of changes at once
From: Jeff Epler @ 2009-10-21 21:20 UTC (permalink / raw)
To: git; +Cc: Jeff Epler
In-Reply-To: <1256160023-29629-1-git-send-email-jepler@unpythonic.net>
---
The diff looks bigger than it is because it changed the indentation
level of about 80 lines, and that made it necessary to reflow a lengthy
commit block as well.
git-gui.sh | 15 +++-
lib/diff.tcl | 225 ++++++++++++++++++++++++++++++++--------------------------
2 files changed, 135 insertions(+), 105 deletions(-)
diff --git a/git-gui.sh b/git-gui.sh
index 09b2720..c69d904 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -3194,7 +3194,7 @@ set ui_diff_applyhunk [$ctxm index last]
lappend diff_actions [list $ctxm entryconf $ui_diff_applyhunk -state]
$ctxm add command \
-label [mc "Apply/Reverse Line"] \
- -command {apply_line $cursorX $cursorY; do_rescan}
+ -command {apply_range_or_line $cursorX $cursorY; do_rescan}
set ui_diff_applyline [$ctxm index last]
lappend diff_actions [list $ctxm entryconf $ui_diff_applyline -state]
$ctxm add separator
@@ -3234,12 +3234,21 @@ proc popup_diff_menu {ctxm ctxmmg x y X Y} {
if {[string first {U} $state] >= 0} {
tk_popup $ctxmmg $X $Y
} else {
+ set has_range [expr {[$::ui_diff tag nextrange sel 0.0] != {}}]
if {$::ui_index eq $::current_diff_side} {
set l [mc "Unstage Hunk From Commit"]
- set t [mc "Unstage Line From Commit"]
+ if {$has_range} {
+ set t [mc "Unstage Lines From Commit"]
+ } else {
+ set t [mc "Unstage Line From Commit"]
+ }
} else {
set l [mc "Stage Hunk For Commit"]
- set t [mc "Stage Line For Commit"]
+ if {$has_range} {
+ set t [mc "Stage Lines For Commit"]
+ } else {
+ set t [mc "Stage Line For Commit"]
+ }
}
if {$::is_3way_diff || $::is_submodule_diff
|| $current_diff_path eq {}
diff --git a/lib/diff.tcl b/lib/diff.tcl
index 066755b..0fe3ec6 100644
--- a/lib/diff.tcl
+++ b/lib/diff.tcl
@@ -533,10 +533,23 @@ proc apply_hunk {x y} {
}
}
-proc apply_line {x y} {
+proc apply_range_or_line {x y} {
global current_diff_path current_diff_header current_diff_side
global ui_diff ui_index file_states
+ set selected [$ui_diff tag nextrange sel 0.0]
+
+ if {$selected == {}} {
+ set first [$ui_diff index "@$x,$y"]
+ set last $first
+ } else {
+ set first [lindex $selected 0]
+ set last [lindex $selected 1]
+ }
+
+ set first_l [$ui_diff index "$first linestart"]
+ set last_l [$ui_diff index "$last lineend"]
+
if {$current_diff_path eq {} || $current_diff_header eq {}} return
if {![lock_index apply_hunk]} return
@@ -559,120 +572,128 @@ proc apply_line {x y} {
}
}
- set the_l [$ui_diff index @$x,$y]
+ set wholepatch {}
- # operate only on change lines
- set c1 [$ui_diff get "$the_l linestart"]
- if {$c1 ne {+} && $c1 ne {-}} {
- unlock_index
- return
- }
- set sign $c1
-
- set i_l [$ui_diff search -backwards -regexp ^@@ $the_l 0.0]
- if {$i_l eq {}} {
- unlock_index
- return
- }
- # $i_l is now at the beginning of a line
+ while {$first_l < $last_l} {
+ set i_l [$ui_diff search -backwards -regexp ^@@ $first_l 0.0]
+ if {$i_l eq {}} {
+ # If there's not a @@ above, then the selected range
+ # must have come before the first_l @@
+ set i_l [$ui_diff search -regexp ^@@ $first_l $last_l]
+ }
+ if {$i_l eq {}} {
+ unlock_index
+ return
+ }
+ # $i_l is now at the beginning of a line
- # pick start line number from hunk header
- set hh [$ui_diff get $i_l "$i_l + 1 lines"]
- set hh [lindex [split $hh ,] 0]
- set hln [lindex [split $hh -] 1]
+ # pick start line number from hunk header
+ set hh [$ui_diff get $i_l "$i_l + 1 lines"]
+ set hh [lindex [split $hh ,] 0]
+ set hln [lindex [split $hh -] 1]
- # There is a special situation to take care of. Consider this hunk:
- #
- # @@ -10,4 +10,4 @@
- # context before
- # -old 1
- # -old 2
- # +new 1
- # +new 2
- # context after
- #
- # We used to keep the context lines in the order they appear in the
- # hunk. But then it is not possible to correctly stage only
- # "-old 1" and "+new 1" - it would result in this staged text:
- #
- # context before
- # old 2
- # new 1
- # context after
- #
- # (By symmetry it is not possible to *un*stage "old 2" and "new 2".)
- #
- # We resolve the problem by introducing an asymmetry, namely, when
- # a "+" line is *staged*, it is moved in front of the context lines
- # that are generated from the "-" lines that are immediately before
- # the "+" block. That is, we construct this patch:
- #
- # @@ -10,4 +10,5 @@
- # context before
- # +new 1
- # old 1
- # old 2
- # context after
- #
- # But we do *not* treat "-" lines that are *un*staged in a special
- # way.
- #
- # With this asymmetry it is possible to stage the change
- # "old 1" -> "new 1" directly, and to stage the change
- # "old 2" -> "new 2" by first staging the entire hunk and
- # then unstaging the change "old 1" -> "new 1".
-
- # This is non-empty if and only if we are _staging_ changes;
- # then it accumulates the consecutive "-" lines (after converting
- # them to context lines) in order to be moved after the "+" change
- # line.
- set pre_context {}
-
- set n 0
- set i_l [$ui_diff index "$i_l + 1 lines"]
- set patch {}
- while {[$ui_diff compare $i_l < "end - 1 chars"] &&
- [$ui_diff get $i_l "$i_l + 2 chars"] ne {@@}} {
- set next_l [$ui_diff index "$i_l + 1 lines"]
- set c1 [$ui_diff get $i_l]
- if {[$ui_diff compare $i_l <= $the_l] &&
- [$ui_diff compare $the_l < $next_l]} {
- # the line to stage/unstage
- set ln [$ui_diff get $i_l $next_l]
- if {$c1 eq {-}} {
- set n [expr $n+1]
+ # There is a special situation to take care of. Consider this
+ # hunk:
+ #
+ # @@ -10,4 +10,4 @@
+ # context before
+ # -old 1
+ # -old 2
+ # +new 1
+ # +new 2
+ # context after
+ #
+ # We used to keep the context lines in the order they appear in
+ # the hunk. But then it is not possible to correctly stage only
+ # "-old 1" and "+new 1" - it would result in this staged text:
+ #
+ # context before
+ # old 2
+ # new 1
+ # context after
+ #
+ # (By symmetry it is not possible to *un*stage "old 2" and "new
+ # 2".)
+ #
+ # We resolve the problem by introducing an asymmetry, namely,
+ # when a "+" line is *staged*, it is moved in front of the
+ # context lines that are generated from the "-" lines that are
+ # immediately before the "+" block. That is, we construct this
+ # patch:
+ #
+ # @@ -10,4 +10,5 @@
+ # context before
+ # +new 1
+ # old 1
+ # old 2
+ # context after
+ #
+ # But we do *not* treat "-" lines that are *un*staged in a
+ # special way.
+ #
+ # With this asymmetry it is possible to stage the change "old
+ # 1" -> "new 1" directly, and to stage the change "old 2" ->
+ # "new 2" by first staging the entire hunk and then unstaging
+ # the change "old 1" -> "new 1".
+
+ # This is non-empty if and only if we are _staging_ changes;
+ # then it accumulates the consecutive "-" lines (after
+ # converting them to context lines) in order to be moved after
+ # the "+" change line.
+ set pre_context {}
+
+ set n 0
+ set m 0
+ set i_l [$ui_diff index "$i_l + 1 lines"]
+ set patch {}
+ while {[$ui_diff compare $i_l < "end - 1 chars"] &&
+ [$ui_diff get $i_l "$i_l + 2 chars"] ne {@@}} {
+ set next_l [$ui_diff index "$i_l + 1 lines"]
+ set c1 [$ui_diff get $i_l]
+ if {[$ui_diff compare $first_l <= $i_l] &&
+ [$ui_diff compare $i_l < $last_l] &&
+ ($c1 eq {-} || $c1 eq {+})} {
+ # a line to stage/unstage
+ set ln [$ui_diff get $i_l $next_l]
+ if {$c1 eq {-}} {
+ set n [expr $n+1]
+ set patch "$patch$pre_context$ln"
+ } else {
+ set m [expr $m+1]
+ set patch "$patch$ln$pre_context"
+ }
+ set pre_context {}
+ } elseif {$c1 ne {-} && $c1 ne {+}} {
+ # context line
+ set ln [$ui_diff get $i_l $next_l]
set patch "$patch$pre_context$ln"
- } else {
- set patch "$patch$ln$pre_context"
- }
- set pre_context {}
- } elseif {$c1 ne {-} && $c1 ne {+}} {
- # context line
- set ln [$ui_diff get $i_l $next_l]
- set patch "$patch$pre_context$ln"
- set n [expr $n+1]
- set pre_context {}
- } elseif {$c1 eq $to_context} {
- # turn change line into context line
- set ln [$ui_diff get "$i_l + 1 chars" $next_l]
- if {$c1 eq {-}} {
- set pre_context "$pre_context $ln"
- } else {
- set patch "$patch $ln"
+ set n [expr $n+1]
+ set m [expr $m+1]
+ set pre_context {}
+ } elseif {$c1 eq $to_context} {
+ # turn change line into context line
+ set ln [$ui_diff get "$i_l + 1 chars" $next_l]
+ if {$c1 eq {-}} {
+ set pre_context "$pre_context $ln"
+ } else {
+ set patch "$patch $ln"
+ }
+ set n [expr $n+1]
+ set m [expr $m+1]
}
- set n [expr $n+1]
+ set i_l $next_l
}
- set i_l $next_l
+ set patch "$patch$pre_context"
+ set wholepatch "$wholepatch@@ -$hln,$n +$hln,$m @@\n$patch"
+ set first_l [$ui_diff index "$next_l + 1 lines"]
}
- set patch "$patch$pre_context"
- set patch "@@ -$hln,$n +$hln,[eval expr $n $sign 1] @@\n$patch"
if {[catch {
set enc [get_path_encoding $current_diff_path]
set p [eval git_write $apply_cmd]
fconfigure $p -translation binary -encoding $enc
puts -nonewline $p $current_diff_header
- puts -nonewline $p $patch
+ puts -nonewline $p $wholepatch
close $p} err]} {
error_popup [append $failed_msg "\n\n$err"]
}
--
1.6.5.rc1.49.ge970
^ permalink raw reply related
* [PATCH] Document GNU_ROFF in Makefile
From: Miklos Vajna @ 2009-10-21 21:31 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Anders Kaseorg, Junio C Hamano, bill lam
In-Reply-To: <7a3e6c8c5a11e14c19bc1a27608dcc78171c9feb.1256151199.git.trast@student.ethz.ch>
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
On Wed, Oct 21, 2009 at 08:57:27PM +0200, Thomas Rast <trast@student.ethz.ch> wrote:
> Unfortunately, as Anders Kaseorg kindly pointed out, this is not
> portable beyond groff, so we add an extra Makefile variable GNU_ROFF
> which you need to enable to get the new quoting.
You forgot to document this in Makefile. Maybe this could be just
squashed in, Junio will decide.
Makefile | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index fea237b..40da590 100644
--- a/Makefile
+++ b/Makefile
@@ -159,6 +159,9 @@ all::
# Define ASCIIDOC_NO_ROFF if your DocBook XSL escapes raw roff directives
# (versions 1.72 and later and 1.68.1 and earlier).
#
+# Define GNU_ROFF if you have GNU roff and you don't want to have pretty
+# apostrophe so that cut&pasting examples to the shell will work.
+#
# Define NO_PERL_MAKEMAKER if you cannot use Makefiles generated by perl's
# MakeMaker (e.g. using ActiveState under Cygwin).
#
--
1.6.5
^ permalink raw reply related
* Re: [PATCH] modernize fetch/merge/pull examples
From: Junio C Hamano @ 2009-10-21 21:38 UTC (permalink / raw)
To: Clemens Buchacher
Cc: Björn Steinbrink, Daniel Barkalow, Thomas Rast, git
In-Reply-To: <20091021172123.GB27495@localhost>
Clemens Buchacher <drizzd@aon.at> writes:
> The "git pull" documentation has examples which follow an outdated
> style. Update the examples to use "git merge" where appropriate and
> move the examples to the corresponding manpages.
Makes sense, although I did some minor rewording.
I noticed something related while reading this (the issue does not affect
the validity of this patch).
> +* Merge branch `maint` into the current branch, but do not make
> + a commit automatically:
> ++
> +------------------------------------------------
> +$ git merge --no-commit maint
> +------------------------------------------------
> ++
> +This can be used when you want to include further changes to the
> +merge, or want to write your own merge commit message.
When you are up to date with maint this would be a no-op, and when you are
strictly behind maint it will succeed without creating a new commit.
I have two possible approaches to fix this issue.
^ permalink raw reply
* [RFC/PATCH] git-merge: forbid fast-forward and up-to-date when --no-commit is given
From: Junio C Hamano @ 2009-10-21 21:41 UTC (permalink / raw)
To: git; +Cc: Clemens Buchacher, Björn Steinbrink, Daniel Barkalow,
Thomas Rast
In-Reply-To: <7v3a5c2zrr.fsf@alter.siamese.dyndns.org>
Traditionally "git merge --no-commit" meant just that: do not create a new
commit even when a merge succeeds. But this leads to confusion when the
merged commit is a descendant of the current commit, in which case we
succeed the merge by fast-forwarding and without creating a new commit.
Also when the merged commit is already a part of the history, we succeeded
without doing anything.
Error out when --no-commit is given but the merge would result in a
fast-forward or an up-to-date.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* This is the first alternative. I think it makes more sense than the
other one, but I am unsure, as I obviously do not get confused when
--no-commit becomes no-op due to a fast-forward nor an up-to-date and
am rather happy with the current behaviour.
builtin-merge.c | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/builtin-merge.c b/builtin-merge.c
index b6b8428..4cfdf75 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -829,6 +829,12 @@ static int evaluate_result(void)
return cnt;
}
+static void check_no_commit(const char *msg)
+{
+ if (!option_commit)
+ die("The merge will %s but --no-commit was given.", msg);
+}
+
int cmd_merge(int argc, const char **argv, const char *prefix)
{
unsigned char result_tree[20];
@@ -996,6 +1002,7 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
* If head can reach all the merge then we are up to date.
* but first the most common case of merging one remote.
*/
+ check_no_commit("be a no-op because you are up-to-date");
finish_up_to_date("Already up-to-date.");
return 0;
} else if (allow_fast_forward && !remoteheads->next &&
@@ -1006,6 +1013,9 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
struct object *o;
char hex[41];
+ if (allow_fast_forward)
+ check_no_commit("fast forward");
+
strcpy(hex, find_unique_abbrev(head, DEFAULT_ABBREV));
if (verbosity >= 0)
@@ -1074,6 +1084,7 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
}
}
if (up_to_date) {
+ check_no_commit("fast forward");
finish_up_to_date("Already up-to-date. Yeeah!");
return 0;
}
--
1.6.5.1.107.gba912
^ permalink raw reply related
* Re: [PATCH v2] Quote ' as \(aq in manpages
From: Anders Kaseorg @ 2009-10-21 21:42 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Miklos Vajna, Junio C Hamano, bill lam
In-Reply-To: <7a3e6c8c5a11e14c19bc1a27608dcc78171c9feb.1256151199.git.trast@student.ethz.ch>
On Wed, 21 Oct 2009, Thomas Rast wrote:
> Unfortunately, as Anders Kaseorg kindly pointed out, this is not
> portable beyond groff, so we add an extra Makefile variable GNU_ROFF
> which you need to enable to get the new quoting.
Note that GNU_ROFF is a property of the target system on which the
manpages will be read, unlike the existing variables (ASCIIDOC8,
DOCBOOK_XSL_172, ASCIIDOC_NO_ROFF) which are properties of the host system
on which they are built.
> To save you the effort of clicking the links, the header definitions
> would be
>
> .ie \n(.g .ds Aq \(aq
> .el .ds Aq '
>
> and you then have to change the template to quote to \(Aq instead.
If someone knows how to get this definition into the header, that would be
preferable, because then you could read the same manpage on both GNU and
non-GNU systems instead of building separately for each.
It would be even better if someone would work with the Docbook developers
to get this fixed upstream. (Unfortunately, there has been no reply to my
comment in their bug tracker.)
Anders
^ permalink raw reply
* [PATCH] git-merge: imply --no-ff when --no-commit is given
From: Junio C Hamano @ 2009-10-21 21:46 UTC (permalink / raw)
To: git; +Cc: Clemens Buchacher, Björn Steinbrink, Daniel Barkalow,
Thomas Rast
In-Reply-To: <7v3a5c2zrr.fsf@alter.siamese.dyndns.org>
Traditionally "git merge --no-commit" meant just that: do not create a new
commit even when a merge succeeds. But this leads to confusion when the
merged commit is a descendant of the current commit, in which case we
succeed the merge by fast-forwarding and without creating a new commit.
Make --no-commit imply --no-ff; --no-commit is a request by the user to
tweak the resulting merge and it is clear indication that the user wants
to have a merge, even if it is an extra one, to futz with.
There is a test that relies on --no-commit silently fast forwarding; that
is obviously broken by this change.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* This is another possibility, which I think is worse than the other one
in practice but the justification sounds more respectable.
Unlike the other one, this will still make --no-commit a no-op when you
are already up-to-date. As I do not think --no-ff makes much sense in
my own workflow (either here or dayjob) it is not exactly my itch, but
I suspect that people who wanted to have --no-ff may want to create an
extra commit even in such a case; it may be a bug to allow up-to-date
when --no-ff is given. Yes, it would make the --no-ff even more insane
than it already is, but I suspect it would be more consistent with the
original reasoning of wanting to have the option in the first place,
namely, to leave the trace of the fact that a "merge" was done at that
point in the history.
builtin-merge.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/builtin-merge.c b/builtin-merge.c
index b6b8428..fa86799 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -874,6 +874,9 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
option_commit = 0;
}
+ if (!option_commit)
+ allow_fast_forward = 0;
+
if (!argc)
usage_with_options(builtin_merge_usage,
builtin_merge_options);
--
1.6.5.1.107.gba912
^ permalink raw reply related
* Re: [PATCH v3] new --dirty option for git describe
From: Junio C Hamano @ 2009-10-21 22:07 UTC (permalink / raw)
To: Jean Privat; +Cc: git, Junio C Hamano, Shawn O. Pearce
In-Reply-To: <1256132122-12509-1-git-send-email-jean@pryen.org>
Thanks. I'll queue it to 'pu' after minor reformatting and typofixes to
the log message.
> 3 Use --dirty as in this patch
> ...
> Pro: has an easy fallback to alternative 1 if the world become suddenly
> ideal, or at least allows some kind of future transition plan if
> people *really* bother:
> 1- ask that scripts use either "git describe HEAD" or
> "git describe --dirty" (no more "git describe")
> 2- change default
> Once the transition is done, the role of the --dirty option will
> just be the way to specify an alternative mark (and a noop if alone)
Also I'd drop this as a Pro specific to #3. It is clear that the first
one is incompatible from the beginning and there is no "smooth migration
path" possible; also I think the second one can be migrated equally well
in exactly the same way, so this is not an advantage specific to #3.
> diff --git a/t/t6120-describe.sh b/t/t6120-describe.sh
> index 8c7e081..e061177 100755
> --- a/t/t6120-describe.sh
> +++ b/t/t6120-describe.sh
> @@ -123,6 +123,20 @@ test_expect_success 'rename tag Q back to A' '
> test_expect_success 'pack tag refs' 'git pack-refs'
> check_describe A-* HEAD
>
> +check_describe "A-*[0-9a-f]" --dirty
> +
> +test_expect_success 'set-up dirty working tree' '
> + echo >>file
> +'
> +
> +check_describe "A-*[0-9a-f]-dirty" --dirty
> +
> +check_describe "A-*[0-9a-f].mod" --dirty=.mod
> +
> +test_expect_success 'describe --dirty HEAD' '
> + test_must_fail git describe --dirty HEAD
> +'
"clean work tree gets no marks; dirty work tree gets expected marks with
or without the mark string; the option is incompatible with an explicit
rev". Nicely covers all cases. Good job.
^ permalink raw reply
* Re: [PATCH 3/3] git checkout --nodwim
From: Junio C Hamano @ 2009-10-21 22:14 UTC (permalink / raw)
To: Nanako Shiraishi
Cc: Avery Pennarun, Junio C Hamano, Alex Riesen, git,
Johannes Schindelin, Jay Soffian
In-Reply-To: <20091022062145.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> As Junio asked for helping hands, let's try to be helpful and constructive.
>
> Maybe "don't second-guess" explains it better?
Perhaps --no-guess, as --no-second-guess is rather hard to read even in scripts.
^ permalink raw reply
* Re: confusion with git diff-tree output
From: David Roundy @ 2009-10-21 22:23 UTC (permalink / raw)
To: git
In-Reply-To: <20091021195103.01cef9c4@perceptron>
You're right. I figured I must be overlooking something obvious, and
that was it. What surprised me was that -p implies -r, which is not
documented. Since the -p output was recursive, I incorrectly presumed
that this was the default.
David
On Wed, Oct 21, 2009 at 1:51 PM, Jan Krüger <jk@jk.gs> wrote:
> Tree objects are recursively nested, i.e.
>
>> 66b67ea1763799c0b2ac01f6803177ca870f6544 M Iolaus
>
> is a reference to another tree object... and since a file in that
> subtree changed, a new tree object that contains a different file
> record is now referenced as "Iolaus".
>
> By default git diff-tree doesn't recurse, but you can use -r for that.
> Which is documented, I might add. ;)
^ permalink raw reply
* Re: [PATCH] Document GNU_ROFF in Makefile
From: Junio C Hamano @ 2009-10-21 22:22 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Thomas Rast, git, Anders Kaseorg, Junio C Hamano, bill lam
In-Reply-To: <20091021213149.GX6115@genesis.frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
> ---
>
> On Wed, Oct 21, 2009 at 08:57:27PM +0200, Thomas Rast <trast@student.ethz.ch> wrote:
>> Unfortunately, as Anders Kaseorg kindly pointed out, this is not
>> portable beyond groff, so we add an extra Makefile variable GNU_ROFF
>> which you need to enable to get the new quoting.
>
> You forgot to document this in Makefile. Maybe this could be just
> squashed in, Junio will decide.
>
> Makefile | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index fea237b..40da590 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -159,6 +159,9 @@ all::
> # Define ASCIIDOC_NO_ROFF if your DocBook XSL escapes raw roff directives
> # (versions 1.72 and later and 1.68.1 and earlier).
> #
> +# Define GNU_ROFF if you have GNU roff and you don't want to have pretty
> +# apostrophe so that cut&pasting examples to the shell will work.
> +#
This makes it sound as if groff is the only roff implementation that has
this problem---iow, if we use non-GNU roff then the documentation comes
out just fine. Is that the case?
Or is the situation more like "we know how to fix this for groff, and the
fix is enabled if this variable is defined---on other roff implementations
the output is still broken"?
> # Define NO_PERL_MAKEMAKER if you cannot use Makefiles generated by perl's
> # MakeMaker (e.g. using ActiveState under Cygwin).
> #
> --
> 1.6.5
^ permalink raw reply
* [PATCH 1/2] gc --auto --quiet: make the notice a bit less verboase
From: Junio C Hamano @ 2009-10-21 22:30 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Nicolas Pitre, Johan Herland, git, H. Peter Anvin, ftpadmin
In-Reply-To: <4ADEC0DB.4000104@viscovery.net>
When "gc --auto --quiet" decides there is something to do, it tells the
user what it is doing, as it is going to make the user wait for a bit.
But the message was a bit too long.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Johannes Sixt <j.sixt@viscovery.net> writes:
> I'm slightly in favor of adding "--quiet", because even with this option
> we see some output:
>
> $ git gc --auto --quiet
> Auto packing your repository for optimum performance. You may also
> run "git gc" manually. See "git help gc" for more information.
>
> A compromise would be to reduce this message to the first sentence if
> --quiet was given.
builtin-gc.c | 11 +++++++----
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/builtin-gc.c b/builtin-gc.c
index 7d3e9cc..093517e 100644
--- a/builtin-gc.c
+++ b/builtin-gc.c
@@ -216,10 +216,13 @@ int cmd_gc(int argc, const char **argv, const char *prefix)
*/
if (!need_to_gc())
return 0;
- fprintf(stderr, "Auto packing your repository for optimum "
- "performance. You may also\n"
- "run \"git gc\" manually. See "
- "\"git help gc\" for more information.\n");
+ fprintf(stderr,
+ "Auto packing the repository for optimum performance.%s\n",
+ quiet
+ ? ""
+ : (" You may also\n"
+ "run \"git gc\" manually. See "
+ "\"git help gc\" for more information."));
} else
append_option(argv_repack,
prune_expire && !strcmp(prune_expire, "now")
--
1.6.5.1.107.gba912
^ permalink raw reply related
* [PATCH 2/2] receive-pack: run "gc --auto --quiet " and optionally "update-server-info"
From: Junio C Hamano @ 2009-10-21 22:32 UTC (permalink / raw)
To: Johannes Sixt
Cc: Junio C Hamano, Nicolas Pitre, Johan Herland, git, H. Peter Anvin,
ftpadmin
In-Reply-To: <4ADEC0DB.4000104@viscovery.net>
Introduce two new configuration variables, receive.autogc (defaults to
true) and receive.updateserverinfo (defaults to false). When these are
set, receive-pack runs "gc --auto --quiet" and "update-server-info"
respectively after it finishes receiving data from "git push" and updating
refs.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Acked-by: Nicolas Pitre <nico@fluxnic.net>
---
* third round; autogc is default (since v2) and runs "gc --auto"
with "--quiet" (change in this round).
Documentation/config.txt | 9 +++++++++
builtin-receive-pack.c | 20 ++++++++++++++++++++
2 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index cd17814..ba6ed10 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1320,6 +1320,11 @@ rebase.stat::
Whether to show a diffstat of what changed upstream since the last
rebase. False by default.
+receive.autogc::
+ By default, git-receive-pack will run "git-gc --auto" after
+ receiving data from git-push and updating refs. You can stop
+ it by setting this variable to false.
+
receive.fsckObjects::
If it is set to true, git-receive-pack will check all received
objects. It will abort in the case of a malformed object or a
@@ -1355,6 +1360,10 @@ receive.denyNonFastForwards::
even if that push is forced. This configuration variable is
set when initializing a shared repository.
+receive.updateserverinfo::
+ If set to true, git-receive-pack will run git-update-server-info
+ after receiving data from git-push and updating refs.
+
remote.<name>.url::
The URL of a remote repository. See linkgit:git-fetch[1] or
linkgit:git-push[1].
diff --git a/builtin-receive-pack.c b/builtin-receive-pack.c
index b771fe9..e8bde02 100644
--- a/builtin-receive-pack.c
+++ b/builtin-receive-pack.c
@@ -28,6 +28,8 @@ static int transfer_unpack_limit = -1;
static int unpack_limit = 100;
static int report_status;
static int prefer_ofs_delta = 1;
+static int auto_update_server_info;
+static int auto_gc = 1;
static const char *head_name;
static char *capabilities_to_send;
@@ -88,6 +90,16 @@ static int receive_pack_config(const char *var, const char *value, void *cb)
return 0;
}
+ if (strcmp(var, "receive.updateserverinfo") == 0) {
+ auto_update_server_info = git_config_bool(var, value);
+ return 0;
+ }
+
+ if (strcmp(var, "receive.autogc") == 0) {
+ auto_gc = git_config_bool(var, value);
+ return 0;
+ }
+
return git_default_config(var, value, cb);
}
@@ -672,6 +684,14 @@ int cmd_receive_pack(int argc, const char **argv, const char *prefix)
report(unpack_status);
run_receive_hook(post_receive_hook);
run_update_post_hook(commands);
+ if (auto_gc) {
+ const char *argv_gc_auto[] = {
+ "gc", "--auto", "--quiet", NULL,
+ };
+ run_command_v_opt(argv_gc_auto, RUN_GIT_CMD);
+ }
+ if (auto_update_server_info)
+ update_server_info(0);
}
return 0;
}
--
1.6.5.1.107.gba912
^ permalink raw reply related
* [PATCH] git checkout --no-guess
From: Junio C Hamano @ 2009-10-21 22:35 UTC (permalink / raw)
To: git
Cc: Nanako Shiraishi, Avery Pennarun, Alex Riesen,
Johannes Schindelin, Jay Soffian
In-Reply-To: <7vskdcz973.fsf@alter.siamese.dyndns.org>
Porcelains may want to make sure their calls to "git checkout" will
reliably fail regardless of the presense of random remote tracking
branches by the new DWIMmery introduced.
Luckily all existing in-tree callers have extra checks to make sure they
feed local branch name when they want to switch, or they explicitly ask to
detach HEAD at the given commit, so there is no need to add this option
for them.
As this is strictly script-only option, do not even bother to document it,
and do bother to hide it from "git checkout -h".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Junio C Hamano <gitster@pobox.com> writes:
> Nanako Shiraishi <nanako3@lavabit.com> writes:
>
>> As Junio asked for helping hands, let's try to be helpful and constructive.
>>
>> Maybe "don't second-guess" explains it better?
>
> Perhaps --no-guess, as --no-second-guess is rather hard to read even in scripts.
builtin-checkout.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/builtin-checkout.c b/builtin-checkout.c
index fb7e68a..da04eed 100644
--- a/builtin-checkout.c
+++ b/builtin-checkout.c
@@ -616,6 +616,7 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
struct tree *source_tree = NULL;
char *conflict_style = NULL;
int patch_mode = 0;
+ int dwim_new_local_branch = 1;
struct option options[] = {
OPT__QUIET(&opts.quiet),
OPT_STRING('b', NULL, &opts.new_branch, "new branch", "branch"),
@@ -631,6 +632,9 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
OPT_STRING(0, "conflict", &conflict_style, "style",
"conflict style (merge or diff3)"),
OPT_BOOLEAN('p', "patch", &patch_mode, "select hunks interactively"),
+ { OPTION_BOOLEAN, 0, "guess", &dwim_new_local_branch, NULL,
+ "second guess 'git checkout no-such-branch'",
+ PARSE_OPT_NOARG | PARSE_OPT_HIDDEN },
OPT_END(),
};
int has_dash_dash;
@@ -715,6 +719,7 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
if (has_dash_dash) /* case (1) */
die("invalid reference: %s", arg);
if (!patch_mode &&
+ dwim_new_local_branch &&
opts.track == BRANCH_TRACK_UNSPECIFIED &&
!opts.new_branch &&
!check_filename(NULL, arg) &&
--
1.6.5.1.107.gba912
^ 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