* Re: [PATCH] gitk: add a checkbox to control the visibility of tags
From: Felipe Contreras @ 2012-12-02 21:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Paul Mackerras, git, Łukasz Stelmach
In-Reply-To: <7vlidhmc5i.fsf@alter.siamese.dyndns.org>
On Sat, Dec 1, 2012 at 8:16 PM, Junio C Hamano <gitster@pobox.com> wrote:
> We _may_ want to unify these two "hidestuff" into a list of patterns
> that hides any ref that match one of the patterns in the list, e.g.
>
> set hidestuff {refs/heads/*/* refs/tags/* refs/remotes/*}
>
> may hide all tags, all remote-tracking branches and local branches
> that have a slash in their names.
And hide the rest. Currently gitk shows all other refs (e.g. refs/hg/*).
--
Felipe Contreras
^ permalink raw reply
* [PATCH] gitk: read and write a repository specific configuration file
From: Łukasz Stelmach @ 2012-12-02 21:29 UTC (permalink / raw)
To: git; +Cc: paulus, gitster, Łukasz Stelmach
In-Reply-To: <50BBC760.7030208@poczta.fm>
Enable gitk read and write repository specific configuration
file: ".git/k" if the file exists. To make gitk use the local
file simply create one, e.g. with the touch(1) command.
This is very useful if one uses different views for different
repositories. Now there is no need to store all of them in
~/.gitk and make the views list needlesly long.
Signed-off-by: Łukasz Stelmach <stlman@poczta.fm>
---
gitk-git/gitk | 25 ++++++++++++++-----------
1 files changed, 14 insertions(+), 11 deletions(-)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index d93bd99..60cf4cd 100755
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -2696,7 +2696,7 @@ proc doprogupdate {} {
proc savestuff {w} {
global canv canv2 canv3 mainfont textfont uifont tabstop
- global stuffsaved findmergefiles maxgraphpct
+ global stuffsaved findmergefiles maxgraphpct gitdir
global maxwidth showneartags showlocalchanges
global viewname viewfiles viewargs viewargscmd viewperm nextviewnum
global cmitmode wrapcomment datetimeformat limitdiffs
@@ -2707,10 +2707,12 @@ proc savestuff {w} {
if {$stuffsaved} return
if {![winfo viewable .]} return
catch {
- if {[file exists ~/.gitk-new]} {file delete -force ~/.gitk-new}
- set f [open "~/.gitk-new" w]
+ set fn [expr [file exists [file join $gitdir k]] ? \
+ {[file join $gitdir k-new]} : {"~/.gitk-new"}]
+ if {[file exists $fn]} {file delete -force $fn}
+ set f [open $fn w]
if {$::tcl_platform(platform) eq {windows}} {
- file attributes "~/.gitk-new" -hidden true
+ catch {file attributes "~/.gitk-new" -hidden true}
}
puts $f [list set mainfont $mainfont]
puts $f [list set textfont $textfont]
@@ -2762,7 +2764,7 @@ proc savestuff {w} {
}
puts $f "}"
close $f
- file rename -force "~/.gitk-new" "~/.gitk"
+ file rename -force $fn [regsub {\-new$} $fn {}]
}
set stuffsaved 1
}
@@ -11663,7 +11665,14 @@ namespace import ::msgcat::mc
## And eventually load the actual message catalog
::msgcat::mcload $gitk_msgsdir
+# check that we can find a .git directory somewhere...
+if {[catch {set gitdir [exec git rev-parse --git-dir]}]} {
+ show_error {} . [mc "Cannot find a git repository here."]
+ exit 1
+}
+
catch {source ~/.gitk}
+catch {source [file join $gitdir k]}
parsefont mainfont $mainfont
eval font create mainfont [fontflags mainfont]
@@ -11680,12 +11689,6 @@ setui $uicolor
setoptions
-# check that we can find a .git directory somewhere...
-if {[catch {set gitdir [exec git rev-parse --git-dir]}]} {
- show_error {} . [mc "Cannot find a git repository here."]
- exit 1
-}
-
set selecthead {}
set selectheadid {}
--
1.7.8.6
^ permalink raw reply related
* Re: [PATCH] gitk: add a checkbox to control the visibility of tags
From: Lukasz Stelmach @ 2012-12-02 21:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Paul Mackerras, git
In-Reply-To: <7vlidhmc5i.fsf@alter.siamese.dyndns.org>
W dniu 02.12.2012 03:16, Junio C Hamano pisze:
> Łukasz Stelmach <stlman@poczta.fm> writes:
>
>> Enable hiding of tags displayed in the tree as yellow labels.
>> If a repository is used together with a system like Gerrit
>> there may be quite a lot of tags used to control building
>> and there may be hardly any place left for commit subjects.
>>
>> Signed-off-by: Łukasz Stelmach <stlman@poczta.fm>
>> ---
>
> Paul, this patch is not done against your tree (does not have gitk
> at the top-level),
I did it on the master from github. Should I rebase it onto something else?
> but other than that, the change mimics the way
> existing hideremoes is implemented and looks reasonable to me.
>
> We _may_ want to unify these two "hidestuff" into a list of patterns
> that hides any ref that match one of the patterns in the list, e.g.
>
> set hidestuff {refs/heads/*/* refs/tags/* refs/remotes/*}
>
> may hide all tags, all remote-tracking branches and local branches
> that have a slash in their names.
>
> But that is an independent change that can come later.
This would make much more sense with gitk being abel to read a
per-repository configuration file, say from [file join $gitdir k] and
then save it there (but only if the file exists). I will send a separate
patch in a moment.
>> gitk-git/gitk | 23 +++++++++++++++--------
>> 1 files changed, 15 insertions(+), 8 deletions(-)
>>
>> diff --git a/gitk-git/gitk b/gitk-git/gitk
>> index d93bd99..274b46b 100755
>> --- a/gitk-git/gitk
>> +++ b/gitk-git/gitk
>> @@ -1754,7 +1754,7 @@ proc readrefs {} {
>> global tagids idtags headids idheads tagobjid
>> global otherrefids idotherrefs mainhead mainheadid
>> global selecthead selectheadid
>> - global hideremotes
>> + global hideremotes hidetags
>>
>> foreach v {tagids idtags headids idheads otherrefids idotherrefs} {
>> catch {unset $v}
>> @@ -1776,6 +1776,7 @@ proc readrefs {} {
>> set headids($name) $id
>> lappend idheads($id) $name
>> } elseif {[string match "tags/*" $name]} {
>> + if {$hidetags} continue
>> # this lets refs/tags/foo^{} overwrite refs/tags/foo,
>> # which is what we want since the former is the commit ID
>> set name [string range $name 5 end]
>> @@ -2702,7 +2703,7 @@ proc savestuff {w} {
>> global cmitmode wrapcomment datetimeformat limitdiffs
>> global colors uicolor bgcolor fgcolor diffcolors diffcontext selectbgcolor
>> global autoselect autosellen extdifftool perfile_attrs markbgcolor use_ttk
>> - global hideremotes want_ttk
>> + global hideremotes hidetags want_ttk
>>
>> if {$stuffsaved} return
>> if {![winfo viewable .]} return
>> @@ -2725,6 +2726,7 @@ proc savestuff {w} {
>> puts $f [list set autosellen $autosellen]
>> puts $f [list set showneartags $showneartags]
>> puts $f [list set hideremotes $hideremotes]
>> + puts $f [list set hidetags $hidetags]
>> puts $f [list set showlocalchanges $showlocalchanges]
>> puts $f [list set datetimeformat $datetimeformat]
>> puts $f [list set limitdiffs $limitdiffs]
>> @@ -10864,7 +10866,7 @@ proc create_prefs_page {w} {
>> proc prefspage_general {notebook} {
>> global NS maxwidth maxgraphpct showneartags showlocalchanges
>> global tabstop limitdiffs autoselect autosellen extdifftool perfile_attrs
>> - global hideremotes want_ttk have_ttk
>> + global hideremotes hidetags want_ttk have_ttk
>>
>> set page [create_prefs_page $notebook.general]
>>
>> @@ -10887,6 +10889,9 @@ proc prefspage_general {notebook} {
>> ${NS}::checkbutton $page.hideremotes -text [mc "Hide remote refs"] \
>> -variable hideremotes
>> grid x $page.hideremotes -sticky w
>> + ${NS}::checkbutton $page.hidetags -text [mc "Hide tag labels"] \
>> + -variable hidetags
>> + grid x $page.hidetags -sticky w
>>
>> ${NS}::label $page.ddisp -text [mc "Diff display options"]
>> grid $page.ddisp - -sticky w -pady 10
>> @@ -10988,7 +10993,7 @@ proc doprefs {} {
>> global oldprefs prefstop showneartags showlocalchanges
>> global uicolor bgcolor fgcolor ctext diffcolors selectbgcolor markbgcolor
>> global tabstop limitdiffs autoselect autosellen extdifftool perfile_attrs
>> - global hideremotes want_ttk have_ttk
>> + global hideremotes hidetags want_ttk have_ttk
>>
>> set top .gitkprefs
>> set prefstop $top
>> @@ -10997,7 +11002,7 @@ proc doprefs {} {
>> return
>> }
>> foreach v {maxwidth maxgraphpct showneartags showlocalchanges \
>> - limitdiffs tabstop perfile_attrs hideremotes want_ttk} {
>> + limitdiffs tabstop perfile_attrs hideremotes hidetags want_ttk} {
>> set oldprefs($v) [set $v]
>> }
>> ttk_toplevel $top
>> @@ -11117,7 +11122,7 @@ proc prefscan {} {
>> global oldprefs prefstop
>>
>> foreach v {maxwidth maxgraphpct showneartags showlocalchanges \
>> - limitdiffs tabstop perfile_attrs hideremotes want_ttk} {
>> + limitdiffs tabstop perfile_attrs hideremotes hidetags want_ttk} {
>> global $v
>> set $v $oldprefs($v)
>> }
>> @@ -11131,7 +11136,7 @@ proc prefsok {} {
>> global oldprefs prefstop showneartags showlocalchanges
>> global fontpref mainfont textfont uifont
>> global limitdiffs treediffs perfile_attrs
>> - global hideremotes
>> + global hideremotes hidetags
>>
>> catch {destroy $prefstop}
>> unset prefstop
>> @@ -11177,7 +11182,8 @@ proc prefsok {} {
>> $limitdiffs != $oldprefs(limitdiffs)} {
>> reselectline
>> }
>> - if {$hideremotes != $oldprefs(hideremotes)} {
>> + if {$hideremotes != $oldprefs(hideremotes) ||
>> + $hidetags != $oldprefs(hidetags)} {
>> rereadrefs
>> }
>> }
>> @@ -11601,6 +11607,7 @@ set cmitmode "patch"
>> set wrapcomment "none"
>> set showneartags 1
>> set hideremotes 0
>> +set hidetags 0
>> set maxrefs 20
>> set maxlinelen 200
>> set showlocalchanges 1
>
--
Było mi bardzo miło. Czwarta pospolita klęska, [...]
>Łukasz< Już nie katolicka lecz złodziejska. (c)PP
^ permalink raw reply
* Re: [RFC] remove/deprecate 'submodule init' and 'sync'
From: W. Trevor King @ 2012-12-02 21:11 UTC (permalink / raw)
To: Jens Lehmann
Cc: Junio C Hamano, Phil Hord, Git, Heiko Voigt, Jeff King,
Shawn Pearce, Nahor
In-Reply-To: <50BBBA29.2000106@web.de>
From: "W. Trevor King" <wking@tremily.us>
To: Jens Lehmann <Jens.Lehmann@web.de>, Junio C Hamano <gitster@pobox.com>
Cc: Phil Hord <phil.hord@gmail.com>, Git <git@vger.kernel.org>,
Heiko Voigt <hvoigt@hvoigt.net>, Jeff King <peff@peff.net>,
Shawn Pearce <spearce@spearce.org>, Nahor <nahor.j+gmane@gmail.com>
Bcc:
Subject: Re: [RFC] remove/deprecate 'submodule init' and 'sync'
Reply-To:
In-Reply-To: <50BBBA29.2000106@web.de>
<50BBB22A.7050901@web.de>
<20121202190929.GG9401@odin.tremily.us>
OpenPGP: id=39A2F3FA2AB17E5D8764F388FC29BDCDF15F5BE8;
url=http://tremily.us/pubkey.txt
On Sun, Dec 02, 2012 at 09:29:29PM +0100, Jens Lehmann wrote:
> Am 02.12.2012 20:09, schrieb W. Trevor King:
> > Before I get into the details, I'd like to point out that I actually
> > understand the purpose of `submodule init` now ;). To avoid further
> > confusion, my current one-line command summaries would be:
> >
> > init: mark a submodule as active for future submodule operation
> > deinit: mark a submodule as inactive for future submodule operation
> > sync: update remote.<name>.origin in submodules to reflect changes
> > in .gitmodules or the superproject's remote URL.
> >
> > I don't think we disagree on that, we just don't agree on how to
> > implement it.
>
> Nope, it is already implemented and you are arguing to change the
> current implementation.
Agreed.
> To quote from another mail:
>
> Am 01.12.2012 18:49, schrieb W. Trevor King:
> > On Sat, Dec 01, 2012 at 06:25:17PM +0100, Jens Lehmann wrote:
> >> What real world problems do we have with the current init/sync that
> >> this approach would solve?
> >
> > I don't have any, ...
>
> We don't want to change working code and cause compatibility issues
> just because we /could/ do things differently, no?
In principle, yes, but in this case I think changing the
implementation does not risk much in the way of compatibility issues
(it only hurts users who rely on `submodule init` setting
submodule.<name>.url for reasons of their own. A few of the existing
tests explictly check the url setting, so perhaps there are a number
of users who do require this side effect?
I think this risk is outweighed by the benefits of having a clearer
activation option. For example:
On Sun, Dec 02, 2012 at 08:55:22PM +0100, Jens Lehmann wrote:
> Sure. I was worried about throwing away other settings the user
> might have set in the submodule.$name section and the first reflex
> was to protect them. But thinking about that again I noticed we are
> already throwing away a possibly user customized "url" setting, so
> we already remove a possibly customized setting.
With submodule.<name>.active, there's nothing customized that you'd
have to nuke on deinit (except 'active' iteself, which the user is
explicitly asking for).
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
^ permalink raw reply
* [PATCH] remote.c: fix grammatical error in comment
From: Chris Rorvick @ 2012-12-02 20:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Chris Rorvick
In-Reply-To: <1354239700-3325-9-git-send-email-chris@rorvick.com>
The sentence originally began "Note that ..." and was changed to
"NOTE: ..." This change should have been made at the same time.
Signed-off-by: Chris Rorvick <chris@rorvick.com>
---
This applies to the current cr/push-force-tag-update branch. It can
probably just be folded into the last commit.
Thanks,
Chris
remote.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/remote.c b/remote.c
index 6309a87..aa6b719 100644
--- a/remote.c
+++ b/remote.c
@@ -1337,8 +1337,8 @@ void set_ref_status_for_push(struct ref *remote_refs, int send_mirror,
*
* NOTE: We must actually have the old object in
* order to overwrite it in the remote reference,
- * and that the new object must be commit-ish.
- * These are implied by (b) and (c) respectively.
+ * and the new object must be commit-ish. These are
+ * implied by (b) and (c) respectively.
*
* (4) it is forced using the +A:B notation, or by
* passing the --force argument
--
1.8.0.1.541.g73be2da
^ permalink raw reply related
* Re: [RFC] remove/deprecate 'submodule init' and 'sync'
From: Jens Lehmann @ 2012-12-02 20:29 UTC (permalink / raw)
To: W. Trevor King
Cc: Junio C Hamano, Phil Hord, Git, Heiko Voigt, Jeff King,
Shawn Pearce, Nahor
In-Reply-To: <20121202190929.GG9401@odin.tremily.us>
Am 02.12.2012 20:09, schrieb W. Trevor King:
> Before I get into the details, I'd like to point out that I actually
> understand the purpose of `submodule init` now ;). To avoid further
> confusion, my current one-line command summaries would be:
>
> init: mark a submodule as active for future submodule operation
> deinit: mark a submodule as inactive for future submodule operation
> sync: update remote.<name>.origin in submodules to reflect changes
> in .gitmodules or the superproject's remote URL.
>
> I don't think we disagree on that, we just don't agree on how to
> implement it.
Nope, it is already implemented and you are arguing to change the
current implementation. To quote from another mail:
Am 01.12.2012 18:49, schrieb W. Trevor King:
> On Sat, Dec 01, 2012 at 06:25:17PM +0100, Jens Lehmann wrote:
>> What real world problems do we have with the current init/sync that
>> this approach would solve?
>
> I don't have any, ...
We don't want to change working code and cause compatibility issues
just because we /could/ do things differently, no?
^ permalink raw reply
* Re: [PATCH] submodule: add 'deinit' command
From: Jens Lehmann @ 2012-12-02 19:55 UTC (permalink / raw)
To: Junio C Hamano
Cc: Phil Hord, W. Trevor King, Git, Heiko Voigt, Jeff King,
Shawn Pearce, Nahor
In-Reply-To: <7vy5hhmcwp.fsf@alter.siamese.dyndns.org>
Am 02.12.2012 03:00, schrieb Junio C Hamano:
> Jens Lehmann <Jens.Lehmann@web.de> writes:
>
>> With "git submodule init" the user is able to tell git he cares about one
>> or more submodules and wants to have it populated on the next call to "git
>> submodule update". But currently there is no easy way he could tell git he
>> does not care about a submodule anymore and wants to get rid of his local
>> work tree (except he knows a lot about submodule internals and removes the
>> "submodule.$name.url" setting from .git/config himself).
>>
>> Help those users by providing a 'deinit' command. This removes the url
>> setting from .git/config either for the given submodule(s) or for all
>> those which have been initialized if none were given. Complain only when
>> for a submodule given on the command line the url setting can't be found
>> in .git/config.
>>
>> Add tests and link the man pages of "git submodule deinit" and "git rm" to
>> assist the user in deciding whether removing or unregistering the submodule
>> is the right thing to do for him.
>>
>> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
>> ---
>
> I fully agree with your analysis on the reason why the "url" element
> is special and has to be copied to $GIT_DIR/config, but when you
> deinit (or uninit) a submodule to say you are no longer interested
> in it and do not want it populated in the context of the
> superproject, I am not sure if removing only submodule.$name.url (so
> that when you later decide to "init" it again, you will keep the
> values for submodule.$name.update and other things from the previous
> life) is the sane thing to do, or it is better to remove
> submodule.$name.* altogether as if an earlier "init" has never
> happened. Would it be worth analyzing the pros-and-cons here?
Sure. I was worried about throwing away other settings the user
might have set in the submodule.$name section and the first reflex
was to protect them. But thinking about that again I noticed we are
already throwing away a possibly user customized "url" setting, so
we already remove a possibly customized setting.
Maybe the principle of least surprise is better followed when we
nuke the whole section, as it might surprise the user more to have
a setting resurrected he customized in the last life cycle of the
submodule than seeing that after an deinit followed by an init all
former customizations are consistently gone. So I tend to think now
that removing the whole section would be the better solution here.
Opinions by other submodule users?
^ permalink raw reply
* Re: [PATCH v5 0/2] submodule update: add --remote for submodule's upstream changes
From: Jens Lehmann @ 2012-12-02 19:32 UTC (permalink / raw)
To: W. Trevor King
Cc: Phil Hord, Git, Junio C Hamano, Heiko Voigt, Jeff King,
Shawn Pearce, Nahor
In-Reply-To: <20121130032719.GE29257@odin.tremily.us>
Am 30.11.2012 04:27, schrieb W. Trevor King:
> On Thu, Nov 29, 2012 at 08:11:20PM -0500, Phil Hord wrote:
>> On Thu, Nov 29, 2012 at 2:13 PM, W. Trevor King <wking@tremily.us> wrote:
>>> On Thu, Nov 29, 2012 at 01:29:12PM -0500, Phil Hord wrote:
>>>> But I really don't want to figure out how to handle submodule
>>>> collisions during a merge (or rebase!) of my superproject with changes that
>>>> someone else auto-committed in his local $superproject as he and I
>>>> arbitrarily floated up the upstream independently. There is nothing but
>>>> loathing down that path.
>>>
>>> This is true. I'm not sure how gitlink collisions are currently
>>> handled…
>>
>> They've always been trouble for me. But it may be that I am ignorant.
>
> I haven't dealt with any gitlink merges, but I think that supporting
> easy gitlink merges is orthogonal to this --remote option. For simple
> cases like "autocommitted submodule floats", one of the conflicting
> gitlinks will be an ancestor of the other, so it should be easy to
> automate that merge.
Submodule merges where one submodule commit is the ancestor of the
other are already resolved automatically in recent git. So Phil's
example will just work as long as only fast-forward merges are needed.
^ permalink raw reply
* Re: [RFC] remove/deprecate 'submodule init' and 'sync'
From: W. Trevor King @ 2012-12-02 19:09 UTC (permalink / raw)
To: Jens Lehmann, Junio C Hamano
Cc: Phil Hord, Git, Heiko Voigt, Jeff King, Shawn Pearce, Nahor
In-Reply-To: <20121201181643.GF4823@odin.tremily.us>
[-- Attachment #1: Type: text/plain, Size: 5933 bytes --]
Before I get into the details, I'd like to point out that I actually
understand the purpose of `submodule init` now ;). To avoid further
confusion, my current one-line command summaries would be:
init: mark a submodule as active for future submodule operation
deinit: mark a submodule as inactive for future submodule operation
sync: update remote.<name>.origin in submodules to reflect changes
in .gitmodules or the superproject's remote URL.
I don't think we disagree on that, we just don't agree on how to
implement it.
Currently, Git uses submodule.<name>.url in the superproject's local
configuration as a marker for submodule activation. This is not (as
far as I know) discussed in the docs, which is why I initially
missunderstood the purpose of `init` to be “setup the superproject's
local configuration so we don't have to keep resolving the submodules
URL relative to the superproject's upstream URL”. With the proposed
`deinit` docs, this role for the submodule.<name>.url is mentioned,
but not in a place where casual users will be able to easily connect
it to the purpose of `init`.
I floated using submodule.<name>.update (with 'none' for inactive and
anything else for active) as an alternative marker:
On Sat, Dec 01, 2012 at 01:16:43PM -0500, W. Trevor King wrote:
> On Sat, Dec 01, 2012 at 07:04:05PM +0100, Jens Lehmann wrote:
> > Am 01.12.2012 18:49, schrieb W. Trevor King:
> > > I think removing `init` will cause some compatibility issues anyway,
> > > so I was re-imaging how you do it. I don't think update='none' and
> > > "don't populate my submodule" are distinct ideas, while a locally
> > > configured url="somwhere" and "please populate my submodule" are (with
> > > the blank-url case defaulting to the superproject itself).
> >
> > Why would we want to remove "init"? It still has to copy the "url"
> > setting (and it would be a compatibility nightmare if we would change
> > that, imagine different git versions used on the same work tree).
>
> In my init-less rewrite, it doesn't have to copy the url setting.
> People using older versions of Git would need to run `init` using
> their old version. Having the url defined in .git/config won't break
> my init-less submodule commands, it just means that the value in
> .gitmodules will be masked.
but that doesn't seem to be going over very well. Junio may have been
weighing in obliquely with:
On Sat, Dec 01, 2012 at 06:00:06PM -0800, Junio C Hamano wrote:
> Jens Lehmann <Jens.Lehmann@web.de> writes:
> > [snip v1 deinit commit message]
>
> I fully agree with your analysis on the reason why the "url" element
> is special and has to be copied to $GIT_DIR/config, but when you
> deinit (or uninit) a submodule to say you are no longer interested
> in it and do not want it populated in the context of the
> superproject, I am not sure if removing only submodule.$name.url (so
> that when you later decide to "init" it again, you will keep the
> values for submodule.$name.update and other things from the previous
> life) is the sane thing to do, or it is better to remove
> submodule.$name.* altogether as if an earlier "init" has never
> happened. Would it be worth analyzing the pros-and-cons here?
Let me take another stab at presenting my argument in favor of a
different activity marker.
Proposal:
Add a new boolean option, submodule.<name>.active, to explicitly mark
submodules as active (with “active” defined as “to be returned by
module_list()”). Strip down `init` (and the --init part of `update
--init`) to just setting this option to true. `deinit` only sets this
option to false (but a `deinit --clean` could remove the whole
submodule.<name> section).
With this in place, extracting URLs for submodule operations be
similar to the extraction of other variables (.gitmodules defaults
with superproject-local .git/config overrides). This also makes it
easier to track maintenance updates in .gitmodules-defined URLs,
because you aren't forced to bake overrides into your local
.git/config
The upgrade path from earlier versions of Git is easy: if
submodule.<name>.active is unset, use the presence of
submodule.<name>.url to determine its initial value.
In the case where you check out an earlier superproject commit which
is missing a particular submodule (or remove a submodule without
deinit-ing), the presense of an active setting in .git/config should
not cause an error, which they currently seem to:
On Sat, Dec 01, 2012 at 11:37:14AM -0500, W. Trevor King wrote:
> On Sat, Dec 01, 2012 at 04:56:02PM +0100, Jens Lehmann wrote:
> > Am 01.12.2012 00:52, schrieb Phil Hord:
> > > If I never 'submodule init' a submodule, it does not get visited by
> > > 'git submodule foreach', among others. I think some people use this
> > > behavior explicitly.
> > >
> > > On the other hand, I've also notice that a submodule which I have
> > > removed does not get de-inited later one. It causes my 'git submodule
> > > foreach' to emit errors. :-(
> >
> > I'm currently hacking on "git submodule deinit" which removes the 'url'
> > setting from git/config. This should do the trick for you, right?
> >
> > Just removing that submodule automagically would not work that well, as
> > it would deinitialize a submodule when you switch to a branch where it
> > isn't present and you'd have to reinitialize it when you come back.
>
> I think this is another case where we should be looping through
> submodules based on the revision-specific .gitmodules content, and
> querying the local config only to determine if the user wants to
> update them (to drop into them with foreach, etc.).
Thoughts?
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [RFC] Add basic syntax check on shell scripts
From: Stefano Lattarini @ 2012-12-02 14:30 UTC (permalink / raw)
To: Torsten Bögershausen; +Cc: git
In-Reply-To: <201212021417.25525.tboegi@web.de>
On 12/02/2012 02:17 PM, Torsten Bögershausen wrote:
> The test suite needs to be run on different platforms.
> As it may be difficult for contributors to catch syntax
> which work on GNU/linux, but is unportable, make a quick check
> for the most common problems.
> "sed -i", "echo -n" or "array in shell scripts"
> This list is not complete, and may need to be extended
>
> Signed-off-by: Torsten Bögershausen <tboegi@web.de>
> ---
> We add 1 second test execution time
> Is this a useful idea at all?
>
FWIW, I think such an idea is useful (and also easy to implement,
so another +1 from me).
> t/t99999-syntax-check.sh | 28 ++++++++++++++++++++++++++++
> 1 file changed, 28 insertions(+)
> create mode 100755 t/t99999-syntax-check.sh
>
> diff --git a/t/t99999-syntax-check.sh b/t/t99999-syntax-check.sh
> new file mode 100755
> index 0000000..c4a9289
> --- /dev/null
> +++ b/t/t99999-syntax-check.sh
> @@ -0,0 +1,28 @@
> +#!/bin/sh
> +
> +test_description='Basic check if shell syntax is portable'
> +
> +. ./test-lib.sh
> +
> +
> +test_expect_success 'No arrays in shell scripts' '
> + >expected &&
> + (grep -i -n "^[ ]*declare[ ][ ]*" ../*.sh ../../git-* >actual 2>&1 || : ) &&
>
Here I'd simply use:
! grep -n "^declare[ ][ ]*" ../*.sh ../../*.sh
And similarly for the tests below.
In addition, the globs above still miss some files ('perf/perf-lib.sh'
and 'valgrind/analyze.sh', for example); so we might want to improve
it, using, say, "git ls-files" (or find(1), in case the test is to be
run also from distribution tarballs).
HTH,
Stefano
^ permalink raw reply
* [RFC] Add basic syntax check on shell scripts
From: Torsten Bögershausen @ 2012-12-02 13:17 UTC (permalink / raw)
To: git; +Cc: tboegi
The test suite needs to be run on different platforms.
As it may be difficult for contributors to catch syntax
which work on GNU/linux, but is unportable, make a quick check
for the most common problems.
"sed -i", "echo -n" or "array in shell scripts"
This list is not complete, and may need to be extended
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
---
We add 1 second test execution time
Is this a useful idea at all?
t/t99999-syntax-check.sh | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
create mode 100755 t/t99999-syntax-check.sh
diff --git a/t/t99999-syntax-check.sh b/t/t99999-syntax-check.sh
new file mode 100755
index 0000000..c4a9289
--- /dev/null
+++ b/t/t99999-syntax-check.sh
@@ -0,0 +1,28 @@
+#!/bin/sh
+
+test_description='Basic check if shell syntax is portable'
+
+. ./test-lib.sh
+
+
+test_expect_success 'No arrays in shell scripts' '
+ >expected &&
+ (grep -i -n "^[ ]*declare[ ][ ]*" ../*.sh ../../git-* >actual 2>&1 || : ) &&
+ test_cmp expected actual &&
+ rm expected actual
+'
+
+test_expect_success 'No sed -i' '
+ >expected &&
+ (grep -n "^[ ]*sed[ ][ ]*\-i" ../*.sh ../../git-* >actual 2>&1 || : ) &&
+ test_cmp expected actual &&
+ rm expected actual
+'
+
+test_expect_success 'No echo -n' '
+ >expected &&
+ (grep -n "^[ ]*echo[ ][ ]*\-n" ../*.sh ../../git-* >actual 2>&1 || : ) &&
+ test_cmp expected actual &&
+ rm expected actual
+'
+test_done
--
1.8.0.197.g5a90748
^ permalink raw reply related
* [PATCH] t9402: sed -i is not portable
From: Torsten Bögershausen @ 2012-12-02 12:22 UTC (permalink / raw)
To: git, mmogilvi_git; +Cc: tboegi
On some systems sed allows the usage of e.g.
sed -i -e "s/line1/line2/" afile
to edit the file "in place".
Other systems don't allow that: one observed behaviour is that
sed -i -e "s/line1/line2/" afile
creates a backup file called afile-e, which breaks the test.
As sed -i is not part of POSIX, avoid it.
Use test_cmp, makes the test easier to debug.
Chain all shell commands with && to detect all kinds of failure.
While at it, Use TAB to indent.
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
---
Note: this should go on top of pu
t/t9402-git-cvsserver-refs.sh | 764 +++++++++++++++++++++---------------------
1 file changed, 383 insertions(+), 381 deletions(-)
diff --git a/t/t9402-git-cvsserver-refs.sh b/t/t9402-git-cvsserver-refs.sh
index 858ef0f..39c6b01 100755
--- a/t/t9402-git-cvsserver-refs.sh
+++ b/t/t9402-git-cvsserver-refs.sh
@@ -10,59 +10,58 @@ tags, branches and other git refspecs'
#########
check_start_tree() {
- rm -f "$WORKDIR/check.list"
- echo "start $1" >> "${WORKDIR}/check.log"
+ rm -f "$WORKDIR/check.list"
+ echo "start $1" >> "${WORKDIR}/check.log"
}
check_file() {
- sandbox="$1"
- file="$2"
- ver="$3"
- GIT_DIR=$SERVERDIR git show "${ver}:${file}" \
+ sandbox="$1"
+ file="$2"
+ ver="$3"
+ GIT_DIR=$SERVERDIR git show "${ver}:${file}" \
> "$WORKDIR/check.got" 2> "$WORKDIR/check.stderr"
- test_cmp "$WORKDIR/check.got" "$sandbox/$file"
- stat=$?
- echo "check_file $sandbox $file $ver : $stat" >> "$WORKDIR/check.log"
- echo "$file" >> "$WORKDIR/check.list"
- return $stat
+ test_cmp "$WORKDIR/check.got" "$sandbox/$file"
+ stat=$?
+ echo "check_file $sandbox $file $ver : $stat" >> "$WORKDIR/check.log"
+ echo "$file" >> "$WORKDIR/check.list"
+ return $stat
}
check_end_tree() {
- sandbox="$1"
- expectCount=$(wc -l < "$WORKDIR/check.list")
- cvsCount=$(find "$sandbox" -name CVS -prune -o -type f -print | wc -l)
- test x"$cvsCount" = x"$expectCount"
- stat=$?
- echo "check_end $sandbox : $stat cvs=$cvsCount expect=$expectCount" \
- >> "$WORKDIR/check.log"
- return $stat
+ sandbox="$1" &&
+ wc -l < "$WORKDIR/check.list" > expected &&
+ find "$sandbox" -type f | grep -v "/CVS" > "$WORKDIR/check.cvsCount" &&
+ wc -l < "$WORKDIR/check.cvsCount" >actual &&
+ test_cmp expected actual &&
+ rm expected actual &&
+ sort < "$WORKDIR/check.list" > expected &&
+ sort < "$WORKDIR/check.cvsCount" | sed -e "s%cvswork/%%" >actual &&
+ test_cmp expected actual &&
+ rm expected actual
}
check_end_full_tree() {
- sandbox="$1"
- ver="$2"
- expectCount=$(wc -l < "$WORKDIR/check.list")
- cvsCount=$(find "$sandbox" -name CVS -prune -o -type f -print | wc -l)
- gitCount=$(git ls-tree -r "$2" | wc -l)
- test x"$cvsCount" = x"$expectCount" -a x"$gitCount" = x"$expectCount"
- stat=$?
- echo "check_end $sandbox : $stat cvs=$cvsCount git=$gitCount expect=$expectCount" \
- >> "$WORKDIR/check.log"
- return $stat
+ sandbox="$1" &&
+ sort < "$WORKDIR/check.list" >expected &&
+ find "$sandbox" -name CVS -prune -o -type f -print | sed -e "s%$sandbox/%%" | sort >act1 &&
+ test_cmp expected act1 &&
+ git ls-tree -r "$2" | sed -e "s/^.*blob [0-9a-fA-F]*[ ]*//" | sort > act2 &&
+ test_cmp expected act2 &&
+ rm expected act1 act2
}
#########
check_diff() {
- diffFile="$1"
- vOld="$2"
- vNew="$3"
- rm -rf diffSandbox
- git clone -q -n . diffSandbox &&
- ( cd diffSandbox &&
- git checkout "$vOld" &&
- git apply -p0 --index <"../$diffFile" &&
- git diff --exit-code "$vNew" ) > check_diff_apply.out 2>&1
+ diffFile="$1"
+ vOld="$2"
+ vNew="$3"
+ rm -rf diffSandbox
+ git clone -q -n . diffSandbox &&
+ ( cd diffSandbox &&
+ git checkout "$vOld" &&
+ git apply -p0 --index <"../$diffFile" &&
+ git diff --exit-code "$vNew" ) > check_diff_apply.out 2>&1
}
#########
@@ -70,17 +69,17 @@ check_diff() {
cvs >/dev/null 2>&1
if test $? -ne 1
then
- skip_all='skipping git-cvsserver tests, cvs not found'
- test_done
+ skip_all='skipping git-cvsserver tests, cvs not found'
+ test_done
fi
if ! test_have_prereq PERL
then
- skip_all='skipping git-cvsserver tests, perl not available'
- test_done
+ skip_all='skipping git-cvsserver tests, perl not available'
+ test_done
fi
"$PERL_PATH" -e 'use DBI; use DBD::SQLite' >/dev/null 2>&1 || {
- skip_all='skipping git-cvsserver tests, Perl SQLite interface unavailable'
- test_done
+ skip_all='skipping git-cvsserver tests, Perl SQLite interface unavailable'
+ test_done
}
unset GIT_DIR GIT_CONFIG
@@ -94,465 +93,468 @@ export CVSROOT CVS_SERVER
rm -rf "$CVSWORK" "$SERVERDIR"
test_expect_success 'setup v1, b1' '
- echo "Simple text file" > textfile.c &&
- echo "t2" > t2 &&
- mkdir adir &&
- echo "adir/afile line1" > adir/afile &&
- echo "adir/afile line2" >> adir/afile &&
- echo "adir/afile line3" >> adir/afile &&
- echo "adir/afile line4" >> adir/afile &&
- echo "adir/a2file" >> adir/a2file &&
- mkdir adir/bdir &&
- echo "adir/bdir/bfile line 1" > adir/bdir/bfile &&
- echo "adir/bdir/bfile line 2" >> adir/bdir/bfile &&
- echo "adir/bdir/b2file" > adir/bdir/b2file &&
- git add textfile.c t2 adir &&
- git commit -q -m "First Commit (v1)" &&
- git tag v1 &&
- git branch b1 &&
- git clone -q --bare "$WORKDIR/.git" "$SERVERDIR" >/dev/null 2>&1 &&
- GIT_DIR="$SERVERDIR" git config --bool gitcvs.enabled true &&
- GIT_DIR="$SERVERDIR" git config gitcvs.logfile "$SERVERDIR/gitcvs.log"
+ echo "Simple text file" > textfile.c &&
+ echo "t2" > t2 &&
+ mkdir adir &&
+ echo "adir/afile line1" > adir/afile &&
+ echo "adir/afile line2" >> adir/afile &&
+ echo "adir/afile line3" >> adir/afile &&
+ echo "adir/afile line4" >> adir/afile &&
+ echo "adir/a2file" >> adir/a2file &&
+ mkdir adir/bdir &&
+ echo "adir/bdir/bfile line 1" > adir/bdir/bfile &&
+ echo "adir/bdir/bfile line 2" >> adir/bdir/bfile &&
+ echo "adir/bdir/b2file" > adir/bdir/b2file &&
+ git add textfile.c t2 adir &&
+ git commit -q -m "First Commit (v1)" &&
+ git tag v1 &&
+ git branch b1 &&
+ git clone -q --bare "$WORKDIR/.git" "$SERVERDIR" >/dev/null 2>&1 &&
+ GIT_DIR="$SERVERDIR" git config --bool gitcvs.enabled true &&
+ GIT_DIR="$SERVERDIR" git config gitcvs.logfile "$SERVERDIR/gitcvs.log"
'
rm -rf cvswork
test_expect_success 'cvs co v1' '
- cvs -f -Q co -r v1 -d cvswork master >cvs.log 2>&1 &&
- check_start_tree cvswork &&
- check_file cvswork textfile.c v1 &&
- check_file cvswork t2 v1 &&
- check_file cvswork adir/afile v1 &&
- check_file cvswork adir/a2file v1 &&
- check_file cvswork adir/bdir/bfile v1 &&
- check_file cvswork adir/bdir/b2file v1 &&
- check_end_tree cvswork
+ cvs -f -Q co -r v1 -d cvswork master >cvs.log 2>&1 &&
+ check_start_tree cvswork &&
+ check_file cvswork textfile.c v1 &&
+ check_file cvswork t2 v1 &&
+ check_file cvswork adir/afile v1 &&
+ check_file cvswork adir/a2file v1 &&
+ check_file cvswork adir/bdir/bfile v1 &&
+ check_file cvswork adir/bdir/b2file v1 &&
+ check_end_tree cvswork
'
rm -rf cvswork
test_expect_success 'cvs co b1' '
- cvs -f co -r b1 -d cvswork master >cvs.log 2>&1 &&
- check_start_tree cvswork &&
- check_file cvswork textfile.c v1 &&
- check_file cvswork t2 v1 &&
- check_file cvswork adir/afile v1 &&
- check_file cvswork adir/a2file v1 &&
- check_file cvswork adir/bdir/bfile v1 &&
- check_file cvswork adir/bdir/b2file v1 &&
- check_end_tree cvswork
+ cvs -f co -r b1 -d cvswork master >cvs.log 2>&1 &&
+ check_start_tree cvswork &&
+ check_file cvswork textfile.c v1 &&
+ check_file cvswork t2 v1 &&
+ check_file cvswork adir/afile v1 &&
+ check_file cvswork adir/a2file v1 &&
+ check_file cvswork adir/bdir/bfile v1 &&
+ check_file cvswork adir/bdir/b2file v1 &&
+ check_end_tree cvswork
'
test_expect_success 'cvs co b1 [cvswork3]' '
- cvs -f co -r b1 -d cvswork3 master >cvs.log 2>&1 &&
- check_start_tree cvswork3 &&
- check_file cvswork3 textfile.c v1 &&
- check_file cvswork3 t2 v1 &&
- check_file cvswork3 adir/afile v1 &&
- check_file cvswork3 adir/a2file v1 &&
- check_file cvswork3 adir/bdir/bfile v1 &&
- check_file cvswork3 adir/bdir/b2file v1 &&
- check_end_full_tree cvswork3 v1
+ cvs -f co -r b1 -d cvswork3 master >cvs.log 2>&1 &&
+ check_start_tree cvswork3 &&
+ check_file cvswork3 textfile.c v1 &&
+ check_file cvswork3 t2 v1 &&
+ check_file cvswork3 adir/afile v1 &&
+ check_file cvswork3 adir/a2file v1 &&
+ check_file cvswork3 adir/bdir/bfile v1 &&
+ check_file cvswork3 adir/bdir/b2file v1 &&
+ check_end_full_tree cvswork3 v1
'
test_expect_success 'edit cvswork3 and save diff' '
- ( cd cvswork3 &&
- sed -i -e "s/line1/line1 - data/" adir/afile &&
- echo "afile5" > adir/afile5 &&
- rm t2 &&
- cvs -f add adir/afile5 &&
- cvs -f rm t2 &&
- test_must_fail cvs -f diff -N -u >"$WORKDIR/cvswork3edit.diff"
- )
+ ( cd cvswork3 &&
+ sed -e "s/line1/line1 - data/" adir/afile >adir/afileNEW &&
+ mv -f adir/afileNEW adir/afile &&
+ echo "afile5" > adir/afile5 &&
+ rm t2 &&
+ cvs -f add adir/afile5 &&
+ cvs -f rm t2 &&
+ test_must_fail cvs -f diff -N -u >"$WORKDIR/cvswork3edit.diff"
+ )
'
test_expect_success 'setup v1.2 on b1' '
- git checkout b1 &&
- echo "new v1.2" > t3 &&
- rm t2 &&
- sed -i -e "s/line3/line3 - more data/" adir/afile &&
- rm adir/a2file &&
- echo "a3file" >> adir/a3file &&
- echo "bfile line 3" >> adir/bdir/bfile &&
- rm adir/bdir/b2file &&
- echo "b3file" > adir/bdir/b3file &&
- mkdir cdir &&
- echo "cdir/cfile" > cdir/cfile &&
- git add -A cdir adir t3 t2 &&
- git commit -q -m 'v1.2' &&
- git tag v1.2 &&
- git push --tags gitcvs.git b1:b1
+ git checkout b1 &&
+ echo "new v1.2" > t3 &&
+ rm t2 &&
+ sed -e "s/line3/line3 - more data/" adir/afile >adir/afileNEW &&
+ mv -f adir/afileNEW adir/afile &&
+ rm adir/a2file &&
+ echo "a3file" >> adir/a3file &&
+ echo "bfile line 3" >> adir/bdir/bfile &&
+ rm adir/bdir/b2file &&
+ echo "b3file" > adir/bdir/b3file &&
+ mkdir cdir &&
+ echo "cdir/cfile" > cdir/cfile &&
+ git add -A cdir adir t3 t2 &&
+ git commit -q -m 'v1.2' &&
+ git tag v1.2 &&
+ git push --tags gitcvs.git b1:b1
'
test_expect_success 'cvs -f up (on b1 adir)' '
- ( cd cvswork/adir &&
- cvs -f up -d ) >cvs.log 2>&1 &&
- check_start_tree cvswork &&
- check_file cvswork textfile.c v1 &&
- check_file cvswork t2 v1 &&
- check_file cvswork adir/afile v1.2 &&
- check_file cvswork adir/a3file v1.2 &&
- check_file cvswork adir/bdir/bfile v1.2 &&
- check_file cvswork adir/bdir/b3file v1.2 &&
- check_end_tree cvswork
+ ( cd cvswork/adir &&
+ cvs -f up -d ) >cvs.log 2>&1 &&
+ check_start_tree cvswork &&
+ check_file cvswork textfile.c v1 &&
+ check_file cvswork t2 v1 &&
+ check_file cvswork adir/afile v1.2 &&
+ check_file cvswork adir/a3file v1.2 &&
+ check_file cvswork adir/bdir/bfile v1.2 &&
+ check_file cvswork adir/bdir/b3file v1.2 &&
+ check_end_tree cvswork
'
test_expect_success 'cvs up (on b1 /)' '
- ( cd cvswork &&
- cvs -f up -d ) >cvs.log 2>&1 &&
- check_start_tree cvswork &&
- check_file cvswork textfile.c v1.2 &&
- check_file cvswork t3 v1.2 &&
- check_file cvswork adir/afile v1.2 &&
- check_file cvswork adir/a3file v1.2 &&
- check_file cvswork adir/bdir/bfile v1.2 &&
- check_file cvswork adir/bdir/b3file v1.2 &&
- check_file cvswork cdir/cfile v1.2 &&
- check_end_tree cvswork
+ ( cd cvswork &&
+ cvs -f up -d ) >cvs.log 2>&1 &&
+ check_start_tree cvswork &&
+ check_file cvswork textfile.c v1.2 &&
+ check_file cvswork t3 v1.2 &&
+ check_file cvswork adir/afile v1.2 &&
+ check_file cvswork adir/a3file v1.2 &&
+ check_file cvswork adir/bdir/bfile v1.2 &&
+ check_file cvswork adir/bdir/b3file v1.2 &&
+ check_file cvswork cdir/cfile v1.2 &&
+ check_end_tree cvswork
'
# Make sure "CVS/Tag" files didn't get messed up:
test_expect_success 'cvs up (on b1 /) (again; check CVS/Tag files)' '
- ( cd cvswork &&
- cvs -f up -d ) >cvs.log 2>&1 &&
- check_start_tree cvswork &&
- check_file cvswork textfile.c v1.2 &&
- check_file cvswork t3 v1.2 &&
- check_file cvswork adir/afile v1.2 &&
- check_file cvswork adir/a3file v1.2 &&
- check_file cvswork adir/bdir/bfile v1.2 &&
- check_file cvswork adir/bdir/b3file v1.2 &&
- check_file cvswork cdir/cfile v1.2 &&
- check_end_tree cvswork
+ ( cd cvswork &&
+ cvs -f up -d ) >cvs.log 2>&1 &&
+ check_start_tree cvswork &&
+ check_file cvswork textfile.c v1.2 &&
+ check_file cvswork t3 v1.2 &&
+ check_file cvswork adir/afile v1.2 &&
+ check_file cvswork adir/a3file v1.2 &&
+ check_file cvswork adir/bdir/bfile v1.2 &&
+ check_file cvswork adir/bdir/b3file v1.2 &&
+ check_file cvswork cdir/cfile v1.2 &&
+ check_end_tree cvswork
'
# update to another version:
test_expect_success 'cvs up -r v1' '
- ( cd cvswork &&
- cvs -f up -r v1 ) >cvs.log 2>&1 &&
- check_start_tree cvswork &&
- check_file cvswork textfile.c v1 &&
- check_file cvswork t2 v1 &&
- check_file cvswork adir/afile v1 &&
- check_file cvswork adir/a2file v1 &&
- check_file cvswork adir/bdir/bfile v1 &&
- check_file cvswork adir/bdir/b2file v1 &&
- check_end_tree cvswork
+ ( cd cvswork &&
+ cvs -f up -r v1 ) >cvs.log 2>&1 &&
+ check_start_tree cvswork &&
+ check_file cvswork textfile.c v1 &&
+ check_file cvswork t2 v1 &&
+ check_file cvswork adir/afile v1 &&
+ check_file cvswork adir/a2file v1 &&
+ check_file cvswork adir/bdir/bfile v1 &&
+ check_file cvswork adir/bdir/b2file v1 &&
+ check_end_tree cvswork
'
test_expect_success 'cvs up' '
- ( cd cvswork &&
- cvs -f up ) >cvs.log 2>&1 &&
- check_start_tree cvswork &&
- check_file cvswork textfile.c v1 &&
- check_file cvswork t2 v1 &&
- check_file cvswork adir/afile v1 &&
- check_file cvswork adir/a2file v1 &&
- check_file cvswork adir/bdir/bfile v1 &&
- check_file cvswork adir/bdir/b2file v1 &&
- check_end_tree cvswork
+ ( cd cvswork &&
+ cvs -f up ) >cvs.log 2>&1 &&
+ check_start_tree cvswork &&
+ check_file cvswork textfile.c v1 &&
+ check_file cvswork t2 v1 &&
+ check_file cvswork adir/afile v1 &&
+ check_file cvswork adir/a2file v1 &&
+ check_file cvswork adir/bdir/bfile v1 &&
+ check_file cvswork adir/bdir/b2file v1 &&
+ check_end_tree cvswork
'
test_expect_success 'cvs up (again; check CVS/Tag files)' '
- ( cd cvswork &&
- cvs -f up -d ) >cvs.log 2>&1 &&
- check_start_tree cvswork &&
- check_file cvswork textfile.c v1 &&
- check_file cvswork t2 v1 &&
- check_file cvswork adir/afile v1 &&
- check_file cvswork adir/a2file v1 &&
- check_file cvswork adir/bdir/bfile v1 &&
- check_file cvswork adir/bdir/b2file v1 &&
- check_end_tree cvswork
+ ( cd cvswork &&
+ cvs -f up -d ) >cvs.log 2>&1 &&
+ check_start_tree cvswork &&
+ check_file cvswork textfile.c v1 &&
+ check_file cvswork t2 v1 &&
+ check_file cvswork adir/afile v1 &&
+ check_file cvswork adir/a2file v1 &&
+ check_file cvswork adir/bdir/bfile v1 &&
+ check_file cvswork adir/bdir/b2file v1 &&
+ check_end_tree cvswork
'
test_expect_success 'setup simple b2' '
- git branch b2 v1 &&
- git push --tags gitcvs.git b2:b2
+ git branch b2 v1 &&
+ git push --tags gitcvs.git b2:b2
'
test_expect_success 'cvs co b2 [into cvswork2]' '
- cvs -f co -r b2 -d cvswork2 master >cvs.log 2>&1 &&
- check_start_tree cvswork &&
- check_file cvswork textfile.c v1 &&
- check_file cvswork t2 v1 &&
- check_file cvswork adir/afile v1 &&
- check_file cvswork adir/a2file v1 &&
- check_file cvswork adir/bdir/bfile v1 &&
- check_file cvswork adir/bdir/b2file v1 &&
- check_end_tree cvswork
+ cvs -f co -r b2 -d cvswork2 master >cvs.log 2>&1 &&
+ check_start_tree cvswork &&
+ check_file cvswork textfile.c v1 &&
+ check_file cvswork t2 v1 &&
+ check_file cvswork adir/afile v1 &&
+ check_file cvswork adir/a2file v1 &&
+ check_file cvswork adir/bdir/bfile v1 &&
+ check_file cvswork adir/bdir/b2file v1 &&
+ check_end_tree cvswork
'
test_expect_success 'root dir edit [cvswork2]' '
- ( cd cvswork2 &&
- echo "Line 2" >> textfile.c &&
- test_must_fail cvs -f diff -u >"$WORKDIR/cvsEdit1.diff" &&
- cvs -f commit -m "edit textfile.c" textfile.c
- ) >cvsEdit1.log 2>&1
+ ( cd cvswork2 &&
+ echo "Line 2" >> textfile.c &&
+ test_must_fail cvs -f diff -u >"$WORKDIR/cvsEdit1.diff" &&
+ cvs -f commit -m "edit textfile.c" textfile.c
+ ) >cvsEdit1.log 2>&1
'
test_expect_success 'root dir rm file [cvswork2]' '
- ( cd cvswork2 &&
- cvs -f rm -f t2 &&
- cvs -f diff -u > ../cvsEdit2-empty.diff &&
- test_must_fail cvs -f diff -N -u >"$WORKDIR/cvsEdit2-N.diff" &&
- cvs -f commit -m "rm t2"
- ) > cvsEdit2.log 2>&1
+ ( cd cvswork2 &&
+ cvs -f rm -f t2 &&
+ cvs -f diff -u > ../cvsEdit2-empty.diff &&
+ test_must_fail cvs -f diff -N -u >"$WORKDIR/cvsEdit2-N.diff" &&
+ cvs -f commit -m "rm t2"
+ ) > cvsEdit2.log 2>&1
'
test_expect_success 'subdir edit/add/rm files [cvswork2' '
- ( cd cvswork2 &&
- sed -i -e "s/line 1/line 1 (v2)/" adir/bdir/bfile &&
- rm adir/bdir/b2file &&
- cd adir &&
- cvs -f rm bdir/b2file &&
- echo "4th file" > bdir/b4file &&
- cvs -f add bdir/b4file &&
- test_must_fail cvs -f diff -N -u >"$WORKDIR/cvsEdit3.diff" &&
- git fetch gitcvs.git b2:b2 &&
- ( cd .. &&
+ ( cd cvswork2 &&
+ sed -e "s/line 1/line 1 (v2)/" adir/bdir/bfile >adir/bdir/bfileNEW &&
+ mv -f adir/bdir/bfileNEW adir/bdir/bfile &&
+ rm adir/bdir/b2file &&
+ cd adir &&
+ cvs -f rm bdir/b2file &&
+ echo "4th file" > bdir/b4file &&
+ cvs -f add bdir/b4file &&
+ test_must_fail cvs -f diff -N -u >"$WORKDIR/cvsEdit3.diff" &&
+ git fetch gitcvs.git b2:b2 &&
+ ( cd .. &&
test_must_fail cvs -f diff -u -N -r v1.2 >"$WORKDIR/cvsEdit3-v1.2.diff" &&
test_must_fail cvs -f diff -u -N -r v1.2 -r v1 >"$WORKDIR/cvsEdit3-v1.2-v1.diff"
- ) &&
- cvs -f commit -m "various add/rm/edit"
- ) >cvs.log 2>&1
+ ) &&
+ cvs -f commit -m "various add/rm/edit"
+ ) >cvs.log 2>&1
'
test_expect_success 'validate result of edits [cvswork2]' '
- git fetch gitcvs.git b2:b2 &&
- git tag v2 b2 &&
- git push --tags gitcvs.git b2:b2 &&
- check_start_tree cvswork2 &&
- check_file cvswork2 textfile.c v2 &&
- check_file cvswork2 adir/afile v2 &&
- check_file cvswork2 adir/a2file v2 &&
- check_file cvswork2 adir/bdir/bfile v2 &&
- check_file cvswork2 adir/bdir/b4file v2 &&
- check_end_full_tree cvswork2 v2
+ git fetch gitcvs.git b2:b2 &&
+ git tag v2 b2 &&
+ git push --tags gitcvs.git b2:b2 &&
+ check_start_tree cvswork2 &&
+ check_file cvswork2 textfile.c v2 &&
+ check_file cvswork2 adir/afile v2 &&
+ check_file cvswork2 adir/a2file v2 &&
+ check_file cvswork2 adir/bdir/bfile v2 &&
+ check_file cvswork2 adir/bdir/b4file v2 &&
+ check_end_full_tree cvswork2 v2
'
test_expect_success 'validate basic diffs saved during above cvswork2 edits' '
- test $(grep Index: cvsEdit1.diff | wc -l) = 1 &&
- test ! -s cvsEdit2-empty.diff &&
- test $(grep Index: cvsEdit2-N.diff | wc -l) = 1 &&
- test $(grep Index: cvsEdit3.diff | wc -l) = 3 &&
- rm -rf diffSandbox &&
- git clone -q -n . diffSandbox &&
- ( cd diffSandbox &&
- git checkout v1 &&
- git apply -p0 --index <"$WORKDIR/cvsEdit1.diff" &&
- git apply -p0 --index <"$WORKDIR/cvsEdit2-N.diff" &&
- git apply -p0 --directory=adir --index <"$WORKDIR/cvsEdit3.diff" &&
- git diff --exit-code v2 ) >"check_diff_apply.out" 2>&1
+ test $(grep Index: cvsEdit1.diff | wc -l) = 1 &&
+ test ! -s cvsEdit2-empty.diff &&
+ test $(grep Index: cvsEdit2-N.diff | wc -l) = 1 &&
+ test $(grep Index: cvsEdit3.diff | wc -l) = 3 &&
+ rm -rf diffSandbox &&
+ git clone -q -n . diffSandbox &&
+ ( cd diffSandbox &&
+ git checkout v1 &&
+ git apply -p0 --index <"$WORKDIR/cvsEdit1.diff" &&
+ git apply -p0 --index <"$WORKDIR/cvsEdit2-N.diff" &&
+ git apply -p0 --directory=adir --index <"$WORKDIR/cvsEdit3.diff" &&
+ git diff --exit-code v2 ) >"check_diff_apply.out" 2>&1
'
test_expect_success 'validate v1.2 diff saved during last cvswork2 edit' '
- test $(grep Index: cvsEdit3-v1.2.diff | wc -l) = 9 &&
- check_diff cvsEdit3-v1.2.diff v1.2 v2
+ test $(grep Index: cvsEdit3-v1.2.diff | wc -l) = 9 &&
+ check_diff cvsEdit3-v1.2.diff v1.2 v2
'
test_expect_success 'validate v1.2 v1 diff saved during last cvswork2 edit' '
- test $(grep Index: cvsEdit3-v1.2-v1.diff | wc -l) = 9 &&
- check_diff cvsEdit3-v1.2-v1.diff v1.2 v1
+ test $(grep Index: cvsEdit3-v1.2-v1.diff | wc -l) = 9 &&
+ check_diff cvsEdit3-v1.2-v1.diff v1.2 v1
'
test_expect_success 'cvs up [cvswork2]' '
- ( cd cvswork2 &&
- cvs -f up ) >cvs.log 2>&1 &&
- check_start_tree cvswork2 &&
- check_file cvswork2 textfile.c v2 &&
- check_file cvswork2 adir/afile v2 &&
- check_file cvswork2 adir/a2file v2 &&
- check_file cvswork2 adir/bdir/bfile v2 &&
- check_file cvswork2 adir/bdir/b4file v2 &&
- check_end_full_tree cvswork2 v2
+ ( cd cvswork2 &&
+ cvs -f up ) >cvs.log 2>&1 &&
+ check_start_tree cvswork2 &&
+ check_file cvswork2 textfile.c v2 &&
+ check_file cvswork2 adir/afile v2 &&
+ check_file cvswork2 adir/a2file v2 &&
+ check_file cvswork2 adir/bdir/bfile v2 &&
+ check_file cvswork2 adir/bdir/b4file v2 &&
+ check_end_full_tree cvswork2 v2
'
test_expect_success 'cvs up -r b2 [back to cvswork]' '
- ( cd cvswork &&
- cvs -f up -r b2 ) >cvs.log 2>&1 &&
- check_start_tree cvswork &&
- check_file cvswork textfile.c v2 &&
- check_file cvswork adir/afile v2 &&
- check_file cvswork adir/a2file v2 &&
- check_file cvswork adir/bdir/bfile v2 &&
- check_file cvswork adir/bdir/b4file v2 &&
- check_end_full_tree cvswork v2
+ ( cd cvswork &&
+ cvs -f up -r b2 ) >cvs.log 2>&1 &&
+ check_start_tree cvswork &&
+ check_file cvswork textfile.c v2 &&
+ check_file cvswork adir/afile v2 &&
+ check_file cvswork adir/a2file v2 &&
+ check_file cvswork adir/bdir/bfile v2 &&
+ check_file cvswork adir/bdir/b4file v2 &&
+ check_end_full_tree cvswork v2
'
test_expect_success 'cvs up -r b1' '
- ( cd cvswork &&
- cvs -f up -r b1 ) >cvs.log 2>&1 &&
- check_start_tree cvswork &&
- check_file cvswork textfile.c v1.2 &&
- check_file cvswork t3 v1.2 &&
- check_file cvswork adir/afile v1.2 &&
- check_file cvswork adir/a3file v1.2 &&
- check_file cvswork adir/bdir/bfile v1.2 &&
- check_file cvswork adir/bdir/b3file v1.2 &&
- check_file cvswork cdir/cfile v1.2 &&
- check_end_full_tree cvswork v1.2
+ ( cd cvswork &&
+ cvs -f up -r b1 ) >cvs.log 2>&1 &&
+ check_start_tree cvswork &&
+ check_file cvswork textfile.c v1.2 &&
+ check_file cvswork t3 v1.2 &&
+ check_file cvswork adir/afile v1.2 &&
+ check_file cvswork adir/a3file v1.2 &&
+ check_file cvswork adir/bdir/bfile v1.2 &&
+ check_file cvswork adir/bdir/b3file v1.2 &&
+ check_file cvswork cdir/cfile v1.2 &&
+ check_end_full_tree cvswork v1.2
'
test_expect_success 'cvs up -A' '
- ( cd cvswork &&
- cvs -f up -A ) >cvs.log 2>&1 &&
- check_start_tree cvswork &&
- check_file cvswork textfile.c v1 &&
- check_file cvswork t2 v1 &&
- check_file cvswork adir/afile v1 &&
- check_file cvswork adir/a2file v1 &&
- check_file cvswork adir/bdir/bfile v1 &&
- check_file cvswork adir/bdir/b2file v1 &&
- check_end_full_tree cvswork v1
+ ( cd cvswork &&
+ cvs -f up -A ) >cvs.log 2>&1 &&
+ check_start_tree cvswork &&
+ check_file cvswork textfile.c v1 &&
+ check_file cvswork t2 v1 &&
+ check_file cvswork adir/afile v1 &&
+ check_file cvswork adir/a2file v1 &&
+ check_file cvswork adir/bdir/bfile v1 &&
+ check_file cvswork adir/bdir/b2file v1 &&
+ check_end_full_tree cvswork v1
'
test_expect_success 'cvs up (check CVS/Tag files)' '
- ( cd cvswork &&
- cvs -f up ) >cvs.log 2>&1 &&
- check_start_tree cvswork &&
- check_file cvswork textfile.c v1 &&
- check_file cvswork t2 v1 &&
- check_file cvswork adir/afile v1 &&
- check_file cvswork adir/a2file v1 &&
- check_file cvswork adir/bdir/bfile v1 &&
- check_file cvswork adir/bdir/b2file v1 &&
- check_end_full_tree cvswork v1
+ ( cd cvswork &&
+ cvs -f up ) >cvs.log 2>&1 &&
+ check_start_tree cvswork &&
+ check_file cvswork textfile.c v1 &&
+ check_file cvswork t2 v1 &&
+ check_file cvswork adir/afile v1 &&
+ check_file cvswork adir/a2file v1 &&
+ check_file cvswork adir/bdir/bfile v1 &&
+ check_file cvswork adir/bdir/b2file v1 &&
+ check_end_full_tree cvswork v1
'
# This is not really legal CVS, but it seems to work anyway:
test_expect_success 'cvs up -r heads/b1' '
- ( cd cvswork &&
- cvs -f up -r heads/b1 ) >cvs.log 2>&1 &&
- check_start_tree cvswork &&
- check_file cvswork textfile.c v1.2 &&
- check_file cvswork t3 v1.2 &&
- check_file cvswork adir/afile v1.2 &&
- check_file cvswork adir/a3file v1.2 &&
- check_file cvswork adir/bdir/bfile v1.2 &&
- check_file cvswork adir/bdir/b3file v1.2 &&
- check_file cvswork cdir/cfile v1.2 &&
- check_end_full_tree cvswork v1.2
+ ( cd cvswork &&
+ cvs -f up -r heads/b1 ) >cvs.log 2>&1 &&
+ check_start_tree cvswork &&
+ check_file cvswork textfile.c v1.2 &&
+ check_file cvswork t3 v1.2 &&
+ check_file cvswork adir/afile v1.2 &&
+ check_file cvswork adir/a3file v1.2 &&
+ check_file cvswork adir/bdir/bfile v1.2 &&
+ check_file cvswork adir/bdir/b3file v1.2 &&
+ check_file cvswork cdir/cfile v1.2 &&
+ check_end_full_tree cvswork v1.2
'
# But this should work even if CVS client checks -r more carefully:
test_expect_success 'cvs up -r heads_-s-b2 (cvsserver escape mechanism)' '
- ( cd cvswork &&
- cvs -f up -r heads_-s-b2 ) >cvs.log 2>&1 &&
- check_start_tree cvswork &&
- check_file cvswork textfile.c v2 &&
- check_file cvswork adir/afile v2 &&
- check_file cvswork adir/a2file v2 &&
- check_file cvswork adir/bdir/bfile v2 &&
- check_file cvswork adir/bdir/b4file v2 &&
- check_end_full_tree cvswork v2
+ ( cd cvswork &&
+ cvs -f up -r heads_-s-b2 ) >cvs.log 2>&1 &&
+ check_start_tree cvswork &&
+ check_file cvswork textfile.c v2 &&
+ check_file cvswork adir/afile v2 &&
+ check_file cvswork adir/a2file v2 &&
+ check_file cvswork adir/bdir/bfile v2 &&
+ check_file cvswork adir/bdir/b4file v2 &&
+ check_end_full_tree cvswork v2
'
v1hash=$(git rev-parse v1)
test_expect_success 'cvs up -r $(git rev-parse v1)' '
- test -n "$v1hash" &&
- ( cd cvswork &&
- cvs -f up -r "$v1hash" ) >cvs.log 2>&1 &&
- check_start_tree cvswork &&
- check_file cvswork textfile.c v1 &&
- check_file cvswork t2 v1 &&
- check_file cvswork adir/afile v1 &&
- check_file cvswork adir/a2file v1 &&
- check_file cvswork adir/bdir/bfile v1 &&
- check_file cvswork adir/bdir/b2file v1 &&
- check_end_full_tree cvswork v1
+ test -n "$v1hash" &&
+ ( cd cvswork &&
+ cvs -f up -r "$v1hash" ) >cvs.log 2>&1 &&
+ check_start_tree cvswork &&
+ check_file cvswork textfile.c v1 &&
+ check_file cvswork t2 v1 &&
+ check_file cvswork adir/afile v1 &&
+ check_file cvswork adir/a2file v1 &&
+ check_file cvswork adir/bdir/bfile v1 &&
+ check_file cvswork adir/bdir/b2file v1 &&
+ check_end_full_tree cvswork v1
'
test_expect_success 'cvs diff -r v1 -u' '
- ( cd cvswork &&
- cvs -f diff -r v1 -u ) >cvsDiff.out 2>cvs.log &&
- test ! -s cvsDiff.out &&
- test ! -s cvs.log
+ ( cd cvswork &&
+ cvs -f diff -r v1 -u ) >cvsDiff.out 2>cvs.log &&
+ test ! -s cvsDiff.out &&
+ test ! -s cvs.log
'
test_expect_success 'cvs diff -N -r v2 -u' '
- ( cd cvswork &&
- test_must_fail cvs -f diff -N -r v2 -u ) >cvsDiff.out 2>cvs.log &&
- test ! -s cvs.log &&
- test -s cvsDiff.out &&
- check_diff cvsDiff.out v2 v1 > check_diff.out 2>&1
+ ( cd cvswork &&
+ test_must_fail cvs -f diff -N -r v2 -u ) >cvsDiff.out 2>cvs.log &&
+ test ! -s cvs.log &&
+ test -s cvsDiff.out &&
+ check_diff cvsDiff.out v2 v1 > check_diff.out 2>&1
'
test_expect_success 'cvs diff -N -r v2 -r v1.2' '
- ( cd cvswork &&
- test_must_fail cvs -f diff -N -r v2 -r v1.2 -u ) >cvsDiff.out 2>cvs.log &&
- test ! -s cvs.log &&
- test -s cvsDiff.out &&
- check_diff cvsDiff.out v2 v1.2 > check_diff.out 2>&1
+ ( cd cvswork &&
+ test_must_fail cvs -f diff -N -r v2 -r v1.2 -u ) >cvsDiff.out 2>cvs.log &&
+ test ! -s cvs.log &&
+ test -s cvsDiff.out &&
+ check_diff cvsDiff.out v2 v1.2 > check_diff.out 2>&1
'
test_expect_success 'apply early [cvswork3] diff to b3' '
- git clone -q . gitwork3 &&
- ( cd gitwork3 &&
- git checkout -b b3 v1 &&
- git apply -p0 --index <"$WORKDIR/cvswork3edit.diff" &&
- git commit -m "cvswork3 edits applied" ) &&
- git fetch gitwork3 b3:b3 &&
- git tag v3 b3
+ git clone -q . gitwork3 &&
+ ( cd gitwork3 &&
+ git checkout -b b3 v1 &&
+ git apply -p0 --index <"$WORKDIR/cvswork3edit.diff" &&
+ git commit -m "cvswork3 edits applied" ) &&
+ git fetch gitwork3 b3:b3 &&
+ git tag v3 b3
'
test_expect_success 'check [cvswork3] diff' '
- ( cd cvswork3 &&
- test_must_fail cvs -f diff -N -u ) >"$WORKDIR/cvsDiff.out" 2>cvs.log &&
- test ! -s cvs.log &&
- test -s cvsDiff.out &&
- test $(grep Index: cvsDiff.out | wc -l) = 3 &&
- test_cmp cvsDiff.out cvswork3edit.diff &&
- check_diff cvsDiff.out v1 v3 > check_diff.out 2>&1
+ ( cd cvswork3 &&
+ test_must_fail cvs -f diff -N -u ) >"$WORKDIR/cvsDiff.out" 2>cvs.log &&
+ test ! -s cvs.log &&
+ test -s cvsDiff.out &&
+ test $(grep Index: cvsDiff.out | wc -l) = 3 &&
+ test_cmp cvsDiff.out cvswork3edit.diff &&
+ check_diff cvsDiff.out v1 v3 > check_diff.out 2>&1
'
test_expect_success 'merge early [cvswork3] b3 with b1' '
- ( cd gitwork3 &&
- git merge "message" HEAD b1 )
- git fetch gitwork3 b3:b3 &&
- git tag v3merged b3 &&
- git push --tags gitcvs.git b3:b3
+ ( cd gitwork3 &&
+ git merge "message" HEAD b1 )
+ git fetch gitwork3 b3:b3 &&
+ git tag v3merged b3 &&
+ git push --tags gitcvs.git b3:b3
'
# This test would fail if cvsserver properly created a ".#afile"* file
# for the merge.
# TODO: Validate that the .# file was saved properly, and then
-# delete/ignore it when checking the tree.
+# delete/ignore it when checking the tree.
test_expect_success 'cvs up dirty [cvswork3]' '
- ( cd cvswork3 &&
- cvs -f up &&
- test_must_fail cvs -f diff -N -u >"$WORKDIR/cvsDiff.out" ) >cvs.log 2>&1 &&
- test -s cvsDiff.out &&
- test $(grep Index: cvsDiff.out | wc -l) = 2
- check_start_tree cvswork3 &&
- check_file cvswork3 textfile.c v3merged &&
- check_file cvswork3 t3 v3merged &&
- check_file cvswork3 adir/afile v3merged &&
- check_file cvswork3 adir/a3file v3merged &&
- check_file cvswork3 adir/afile5 v3merged &&
- check_file cvswork3 adir/bdir/bfile v3merged &&
- check_file cvswork3 adir/bdir/b3file v3merged &&
- check_file cvswork3 cdir/cfile v3merged &&
- check_end_full_tree cvswork3 v3merged
+ ( cd cvswork3 &&
+ cvs -f up &&
+ test_must_fail cvs -f diff -N -u >"$WORKDIR/cvsDiff.out" ) >cvs.log 2>&1 &&
+ test -s cvsDiff.out &&
+ test $(grep Index: cvsDiff.out | wc -l) = 2
+ check_start_tree cvswork3 &&
+ check_file cvswork3 textfile.c v3merged &&
+ check_file cvswork3 t3 v3merged &&
+ check_file cvswork3 adir/afile v3merged &&
+ check_file cvswork3 adir/a3file v3merged &&
+ check_file cvswork3 adir/afile5 v3merged &&
+ check_file cvswork3 adir/bdir/bfile v3merged &&
+ check_file cvswork3 adir/bdir/b3file v3merged &&
+ check_file cvswork3 cdir/cfile v3merged &&
+ check_end_full_tree cvswork3 v3merged
'
# TODO: test cvs status
test_expect_success 'cvs commit [cvswork3' '
- ( cd cvswork3 &&
- cvs -f commit -m "dirty sandbox after auto-merge"
- ) > cvs.log 2>&1 &&
- check_start_tree cvswork3 &&
- check_file cvswork3 textfile.c v3merged &&
- check_file cvswork3 t3 v3merged &&
- check_file cvswork3 adir/afile v3merged &&
- check_file cvswork3 adir/a3file v3merged &&
- check_file cvswork3 adir/afile5 v3merged &&
- check_file cvswork3 adir/bdir/bfile v3merged &&
- check_file cvswork3 adir/bdir/b3file v3merged &&
- check_file cvswork3 cdir/cfile v3merged &&
- check_end_full_tree cvswork3 v3merged &&
- git fetch gitcvs.git b3:b4 &&
- git tag v4.1 b4 &&
- git diff --exit-code v4.1 v3merged > check_diff_apply.out 2>&1
+ ( cd cvswork3 &&
+ cvs -f commit -m "dirty sandbox after auto-merge"
+ ) > cvs.log 2>&1 &&
+ check_start_tree cvswork3 &&
+ check_file cvswork3 textfile.c v3merged &&
+ check_file cvswork3 t3 v3merged &&
+ check_file cvswork3 adir/afile v3merged &&
+ check_file cvswork3 adir/a3file v3merged &&
+ check_file cvswork3 adir/afile5 v3merged &&
+ check_file cvswork3 adir/bdir/bfile v3merged &&
+ check_file cvswork3 adir/bdir/b3file v3merged &&
+ check_file cvswork3 cdir/cfile v3merged &&
+ check_end_full_tree cvswork3 v3merged &&
+ git fetch gitcvs.git b3:b4 &&
+ git tag v4.1 b4 &&
+ git diff --exit-code v4.1 v3merged > check_diff_apply.out 2>&1
'
test_done
--
1.8.0.197.g5a90748
^ permalink raw reply related
* Re: [PATCH/RFC 1/5] mingw: make fgetc raise SIGINT if apropriate
From: Junio C Hamano @ 2012-12-02 10:42 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: git, msysgit, peff
In-Reply-To: <1352815447-8824-2-git-send-email-kusmabite@gmail.com>
Erik Faye-Lund <kusmabite@gmail.com> writes:
> @@ -1538,13 +1563,7 @@ static sig_handler_t timer_fn = SIG_DFL;
> static unsigned __stdcall ticktack(void *dummy)
> {
> while (WaitForSingleObject(timer_event, timer_interval) == WAIT_TIMEOUT) {
> - if (timer_fn == SIG_DFL) {
> - if (isatty(STDERR_FILENO))
> - fputs("Alarm clock\n", stderr);
> - exit(128 + SIGALRM);
> - }
> - if (timer_fn != SIG_IGN)
> - timer_fn(SIGALRM);
> + mingw_raise(SIGALRM);
> if (one_shot)
> break;
> }
This hunk seems to have been based on a slightly newer codebase than
what I have, and I had to wiggle the patch a bit to make the series
apply. Please double check the result when I push out the 'pu'
branch.
Thanks.
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
^ permalink raw reply
* Re: [PATCH v6 2/8] push: add advice for rejected tag reference
From: Junio C Hamano @ 2012-12-02 10:42 UTC (permalink / raw)
To: Chris Rorvick
Cc: git, Angelo Borsotti, Drew Northup, Michael Haggerty,
Philip Oakley, Johannes Sixt, Kacper Kornet, Jeff King,
Felipe Contreras
In-Reply-To: <1354239700-3325-3-git-send-email-chris@rorvick.com>
Chris Rorvick <chris@rorvick.com> writes:
> static void advise_pull_before_push(void)
> {
> if (!advice_push_non_ff_current || !advice_push_nonfastforward)
> @@ -241,6 +245,11 @@ static void advise_checkout_pull_push(void)
> advise(_(message_advice_checkout_pull_push));
> }
>
> +static void advise_ref_already_exists(void)
> +{
> + advise(_(message_advice_ref_already_exists));
> +}
> +
> static int push_with_options(struct transport *transport, int flags)
> {
> int err;
> @@ -272,6 +281,8 @@ static int push_with_options(struct transport *transport, int flags)
> advise_use_upstream();
> else
> advise_checkout_pull_push();
> + } else if (reject_reasons & REJECT_ALREADY_EXISTS) {
> + advise_ref_already_exists();
> }
The existing advise_* functions that are called from this function
honor the advice.* configuration, and advise_ref_already_exists()
would want to follow suit here (it is OK to do so as a follow-up
patch without further rerolling the entire series).
Thanks.
^ permalink raw reply
* Re: [PATCH 8/8] wrap_in_html(): process message in bulk rather than line-by-line
From: Michael Haggerty @ 2012-12-02 10:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeremy White, Johannes Schindelin, Jeff King
In-Reply-To: <7vpq2slsb4.fsf@alter.siamese.dyndns.org>
On 12/02/2012 10:25 AM, Junio C Hamano wrote:
> Michael Haggerty <mhagger@alum.mit.edu> writes:
>
>> Nevertheless, the old code was even *more* broken because it added a
>> "</pre>" regardless of whether the separator line had been seen,...
>
> OK. I'll rewrite the tail-end of the original log message to read:
>
> The old code would have created invalid output when there was no
> body, emitting a closing </pre> without a blank line nor an opening
> <pre> after the header. The new code simply returns in this
> situation without doing harm (even though either would not make much
> sense in the context of imap-send that is meant to send out patches).
>
> and squash this in.
ACK. Thanks.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: [PATCH 0/5] ignore SIG{INT,QUIT} when launching editor
From: Junio C Hamano @ 2012-12-02 10:04 UTC (permalink / raw)
To: Jeff King; +Cc: git, Paul Fox, Krzysztof Mazur
In-Reply-To: <20121130223943.GA27120@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Since this can be thought of as "act more like system(3)", I wondered
> whether the signal-ignore logic should be moved into run-command, or
> even used by default for blocking calls to run_command (which are
> basically our version of system(3)). But it is detrimental in the common
> case that the child is not taking control of the terminal, and is just
> an implementation detail (e.g., we call "git update-ref" behind the
> scenes, but the user does not know or care). If they hit ^C during such
> a run and we are ignoring SIGINT, then either:
>
> 1. we will notice the child died by signal and report an
> error in the subprocess rather than just dying; the end result is
> similar, but the error is unnecessarily confusing
>
> 2. we do not bother to check the child's return code (because we do
> not care whether the child succeeded or not, like a "gc --auto");
> we end up totally ignoring the user's request to abort the
> operation
>
> So I do not think we care about this behavior except for launching the
> editor. And the signal-propagation behavior of 5/5 is really so weirdly
> editor-specific (because it is about behaving well whether the child
> blocks signals or not).
Nicely explained. Very much appreciated.
^ permalink raw reply
* Re: does a successful 'git gc' imply 'git fsck'
From: Junio C Hamano @ 2012-12-02 9:31 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: Git Mailing List
In-Reply-To: <CAMK1S_iBq1ReGkjuy2UBENSQXOWyKj2ZzSCcg7Z89FVtVL2wMw@mail.gmail.com>
Sitaram Chamarty <sitaramc@gmail.com> writes:
> If I could assume that a successful 'git gc' means an fsck is not
> needed, I'd save a lot of time. Hence my question.
When it does "repack -a", it at least scans the whole history so you
would be sure that all the commits and trees are readable for the
purpose of enumerating the objects referred by them (and a bit flip
in them will likely be noticed by zlib inflation).
But a "gc" does not necessarily run "repack -a" when it does not see
too many pack files, so it can end up scanning only the surface of
the history to collect the recently created loose objects into a
pack, and stop its traversal without going into existing packfiles.
^ permalink raw reply
* Re: [PATCH 8/8] wrap_in_html(): process message in bulk rather than line-by-line
From: Junio C Hamano @ 2012-12-02 9:25 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git, Jeremy White, Johannes Schindelin, Jeff King
In-Reply-To: <50B8B73A.4060801@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
> Nevertheless, the old code was even *more* broken because it added a
> "</pre>" regardless of whether the separator line had been seen,...
OK. I'll rewrite the tail-end of the original log message to read:
The old code would have created invalid output when there was no
body, emitting a closing </pre> without a blank line nor an opening
<pre> after the header. The new code simply returns in this
situation without doing harm (even though either would not make much
sense in the context of imap-send that is meant to send out patches).
and squash this in.
Thanks.
^ permalink raw reply
* Re: does a successful 'git gc' imply 'git fsck'
From: Sitaram Chamarty @ 2012-12-02 8:46 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Git Mailing List
In-Reply-To: <CAJo=hJvHeA4g1fJZXm9VxpdvMFoHeEJW_r5YtXTDACEp09Xm_Q@mail.gmail.com>
On Sun, Dec 2, 2012 at 9:58 AM, Shawn Pearce <spearce@spearce.org> wrote:
> On Sat, Dec 1, 2012 at 6:31 PM, Sitaram Chamarty <sitaramc@gmail.com> wrote:
>> Background: I have a situation where I have to fix up a few hundred
>> repos in terms of 'git gc' (the auto gc seems to have failed in many
>> cases; they have far more than 6700 loose objects). I also found some
>> corrupted objects in some cases that prevent the gc from completing.
>>
>> I am running "git gc" followed by "git fsck". The majority of the
>> repos I have worked through so far appear to be fine, but in the
>> larger repos (upwards of 2-3 GB) the git fsck is taking almost 5 times
>> longer than the 'gc'.
>>
>> If I could assume that a successful 'git gc' means an fsck is not
>> needed, I'd save a lot of time. Hence my question.
>
> Not really. For example fsck verifies that every blob when
> decompressed and fully inflated matches its SHA-1. gc only checks
OK that makes sense. After I posted I happened to check using strace
and kinda guessed this from what I saw, but it's nice to have
confirmation.
> connectivity of the commit and tree graph by making sure every object
> was accounted for. But when creating the output pack it only verifies
> a CRC-32 was correct when copying the bits from the source to the
> destination, it does not verify that the data decompresses and matches
> the SHA-1 it should match.
>
> So it depends on what level of check you need to feel safe.
Yup; thanks.
All the repos my internal client manages are mirrored in multiple
places, and they set (or were at least told to set, heh!)
receive.fsckObjects so the lesser check is fine in most cases.
--
Sitaram
^ permalink raw reply
* Re: [PATCH v2 1/4] t4014: more tests about appending s-o-b lines
From: Brandon Casey @ 2012-12-02 8:03 UTC (permalink / raw)
To: Torsten Bögershausen
Cc: Nguyễn Thái Ngọc Duy, git, Junio C Hamano
In-Reply-To: <50BAFE04.4080100@web.de>
On Sat, Dec 1, 2012 at 11:06 PM, Torsten Bögershausen <tboegi@web.de> wrote:
> On 22.11.12 17:38, Nguyễn Thái Ngọc Duy wrote:
>>
>> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
>> ---
>> t/t4014-format-patch.sh | 145 ++++++++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 145 insertions(+)
>> + echo -n subject | append_signoff >actual &&
>
>
> "echo -n" is not portable, and we use printf everywhere.
> I found one "echo -n" in line 996.
>
> Can we squeeze that in, before going to next?
I got it. I'll squash it into the next series.
-Brandon
^ permalink raw reply
* Re: [PATCH v2 1/4] t4014: more tests about appending s-o-b lines
From: Torsten Bögershausen @ 2012-12-02 7:06 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Junio C Hamano
In-Reply-To: <1353602289-9418-2-git-send-email-pclouds@gmail.com>
On 22.11.12 17:38, Nguyễn Thái Ngọc Duy wrote:
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
> t/t4014-format-patch.sh | 145 ++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 145 insertions(+)
> + echo -n subject | append_signoff >actual &&
"echo -n" is not portable, and we use printf everywhere.
I found one "echo -n" in line 996.
Can we squeeze that in, before going to next?
diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh
index 6cfad13..f460930 100755
--- a/t/t4014-format-patch.sh
+++ b/t/t4014-format-patch.sh
@@ -993,7 +993,7 @@ EOF
'
test_expect_success 'signoff: commit with only subject that does not end with NL' '
- echo -n subject | append_signoff >actual &&
+ printf subject | append_signoff >actual &&
cat >expected <<\EOF &&
4:Subject: [PATCH] subject
8:
^ permalink raw reply related
* Re: [PATCH 6/8] imap-send: change msg_data from storing (char *, len) to storing strbuf
From: Michael Haggerty @ 2012-12-02 6:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeremy White, Johannes Schindelin, Jeff King
In-Reply-To: <7v624lns00.fsf@alter.siamese.dyndns.org>
On 12/02/2012 02:48 AM, Junio C Hamano wrote:
> Michael Haggerty <mhagger@alum.mit.edu> writes:
>
>> On 11/29/2012 10:30 PM, Junio C Hamano wrote:
>>
>>>> A side effect of this change is that the memory for each message is
>>>> freed after it is used rather than leaked, though that detail is
>>>> unimportant given that imap-send is a top-level command.
>>>>
>>>> --
>>>
>>> ?
>>
>> If by "?" you are wondering where the memory leak was, it was:
>
> No, I was wondering if you meant to say "---" to mark te remainder
> of what you wrote does not exactly belong to the log message.
Oh. Yes, that was my intention.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: does a successful 'git gc' imply 'git fsck'
From: Shawn Pearce @ 2012-12-02 4:28 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: Git Mailing List
In-Reply-To: <CAMK1S_iBq1ReGkjuy2UBENSQXOWyKj2ZzSCcg7Z89FVtVL2wMw@mail.gmail.com>
On Sat, Dec 1, 2012 at 6:31 PM, Sitaram Chamarty <sitaramc@gmail.com> wrote:
> Background: I have a situation where I have to fix up a few hundred
> repos in terms of 'git gc' (the auto gc seems to have failed in many
> cases; they have far more than 6700 loose objects). I also found some
> corrupted objects in some cases that prevent the gc from completing.
>
> I am running "git gc" followed by "git fsck". The majority of the
> repos I have worked through so far appear to be fine, but in the
> larger repos (upwards of 2-3 GB) the git fsck is taking almost 5 times
> longer than the 'gc'.
>
> If I could assume that a successful 'git gc' means an fsck is not
> needed, I'd save a lot of time. Hence my question.
Not really. For example fsck verifies that every blob when
decompressed and fully inflated matches its SHA-1. gc only checks
connectivity of the commit and tree graph by making sure every object
was accounted for. But when creating the output pack it only verifies
a CRC-32 was correct when copying the bits from the source to the
destination, it does not verify that the data decompresses and matches
the SHA-1 it should match.
So it depends on what level of check you need to feel safe.
^ permalink raw reply
* [PATCH v6 0/4] submodule update: add --remote for submodule's upstream changes
From: W. Trevor King @ 2012-12-02 3:17 UTC (permalink / raw)
To: Git
Cc: Junio C Hamano, Heiko Voigt, Jeff King, Phil Hord, Shawn Pearce,
Jens Lehmann, Nahor, W. Trevor King
In-Reply-To: <20121130032719.GE29257@odin.tremily.us>
From: "W. Trevor King" <wking@tremily.us>
On Thu, Nov 29, 2012 at 10:27:19PM -0500, W. Trevor King wrote:
> On Thu, Nov 29, 2012 at 08:11:20PM -0500, Phil Hord wrote:
> > I've always felt that the "origin" defaults are broken and are simply
> > being ignored because most users do not trip over them. But ISTR that
> > submodule commands use the remote indicated by the superproject's
> > current remote-tracking configuration, with a fallback to 'origin' if
> > there is none. Sort of a "best effort" algorithm, I think. Am I
> > remembering that wrong?
>
> The current code uses a bare "git-fetch". I'm not sure what that
> defaults to if you're on a detached head. If it bothers you, I'm fine
> adding the submodule.<name>.remote option in v6.
Here it is. Now the remote defaults to $(get_default_remote) with an
optional override via submodule.<name>.remote.
Changes since v5:
* New patch 1 for easy config variable setup.
* Minor tweaks and rewordings in patches 2 and 3 (v5 patches 1 and 2).
* New patch 4 adding submodule.<name>.remote.
I'm fine with squashing patches 1, 2, and 4 together, if people prefer
a more compact series.
W. Trevor King (4):
submodule: add get_submodule_config helper funtion
submodule update: add --remote for submodule's upstream changes
submodule add: If --branch is given, record it in .gitmodules
submodule update: add submodule.<name>.remote config option
Documentation/config.txt | 8 ++++-
Documentation/git-submodule.txt | 27 ++++++++++++++-
Documentation/gitmodules.txt | 5 +++
git-submodule.sh | 74 ++++++++++++++++++++++++++++++++++++++---
t/t7400-submodule-basic.sh | 1 +
t/t7406-submodule-update.sh | 49 +++++++++++++++++++++++++++
6 files changed, 158 insertions(+), 6 deletions(-)
--
1.8.0.4.gf74b0fc.dirty
^ permalink raw reply
* [PATCH v6 1/4] submodule: add get_submodule_config helper funtion
From: W. Trevor King @ 2012-12-02 3:17 UTC (permalink / raw)
To: Git
Cc: Junio C Hamano, Heiko Voigt, Jeff King, Phil Hord, Shawn Pearce,
Jens Lehmann, Nahor, W. Trevor King
In-Reply-To: <cover.1354417618.git.wking@tremily.us>
From: "W. Trevor King" <wking@tremily.us>
Several submodule configuration variables
(e.g. fetchRecurseSubmodules) are read from .gitmodules with local
overrides from the usual git config files. This shell function mimics
that logic to help initialize configuration variables in
git-submodule.sh.
Signed-off-by: W. Trevor King <wking@tremily.us>
---
git-submodule.sh | 27 +++++++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/git-submodule.sh b/git-submodule.sh
index ab6b110..97ce5e4 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -152,6 +152,33 @@ die_if_unmatched ()
}
#
+# Print a submodule configuration setting
+#
+# $1 = submodule name
+# $2 = option name
+# $3 = default value
+#
+# Checks in the usual git-config places first (for overrides),
+# otherwise it falls back on .gitmodules. This allows you to
+# distribute project-wide defaults in .gitmodules, while still
+# customizing individual repositories if necessary. If the option is
+# not in .gitmodules either, print a default value.
+#
+get_submodule_config()
+{
+ name="$1"
+ option="$2"
+ default="$3"
+ value=$(git config submodule."$name"."$option")
+ if test -z "$value"
+ then
+ value=$(git config -f .gitmodules submodule."$name"."$option")
+ fi
+ printf '%s' "${value:-$default}"
+}
+
+
+#
# Map submodule path to submodule name
#
# $1 = path
--
1.8.0.4.gf74b0fc.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