Re: GET PAID DRIVING YOUR CAR BY ROCKSTAR ENERGY DRINK FOR ADVERTISEMENT

Wow! That sounds like a great opportunity!! I would love to work for this Green drink brand. This is really famous brand that provide quality products. I wonder if you can s

Re: 'git status -z' missing separators on OSX

On Tue, Jun 16, 2015 at 06:21:56PM -0500, Tad Hardesty wrote: > ~/test (master #)$ git status -z | hexdump -C > 41 20 20 61 41 20 20 62 |A aA b| > 0008 That's really weird. I don't have a Yosemite box available, but I can't reproduce on the Mavericks box

Re: [PATCH] notes: Use get_sha1_committish instead of read_ref in init_notes()

On Wed, Jun 17, 2015 at 10:15:31AM +0900, Mike Hommey wrote: > init_notes() is essentially the only point of entry to the notes API. > It is an arbitrary restriction that all it allows as input is a strict > ref name, when callers may want to give an arbitrary committish. > > This has the side ef

Re: [PATCH] notes: Use get_sha1_committish instead of read_ref in init_notes()

Mike Hommey writes: > init_notes() is essentially the only point of entry to the notes API. > It is an arbitrary restriction that all it allows as input is a strict > ref name, when callers may want to give an arbitrary committish. While it may be a good idea to allow reading from any note-shape

[PATCH] notes: Use get_sha1_committish instead of read_ref in init_notes()

init_notes() is essentially the only point of entry to the notes API. It is an arbitrary restriction that all it allows as input is a strict ref name, when callers may want to give an arbitrary committish. This has the side effect of enabling the use of committish as notes refs in commands allowin

'git status -z' missing separators on OSX

I have been experiencing a problem where git on OSX prints incorrect output to the `git status -z` command, where instead of NUL separators records are simply not separated. This is causing problems with IDE integration. While I have a workaround involving manually replacing \n with \0, it would be

[PATCH] pull.c: fix some sparse warnings

Commit 191241e5 ("pull: pass git-fetch's options to git-fetch", 14-06-2015) uses the OPT_PASSTHRU macro to add some command line 'struct option' initialisations to the pull_options array. This causes sparse to complain, thus: SP builtin/pull.c builtin/pull.c:160:9: warning: Using plain in

What's cooking in git.git (Jun 2015, #04; Tue, 16)

Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. Hopefully the pre-release freeze can start late next week, and the next cycle would reopen mid next month. In the meantime, let's shift the foc

[ANNOUNCE] Git v2.4.4

The latest maintenance release Git v2.4.4 is now available at the usual places. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/ The following public repositories all have a copy of the 'v2.4.4' tag and the 'maint' branch that the tag points at: url = https://kernel

[PATCH] mergetools: add config option to disable auto-merge

During conflict resolution, invoking a mergetool which supports auto-merge will pass that option by default to the underlying tool. This patch is intended to allow one to set 'merge.automerge' to 'false' in order to override this behavior. Michael Rappazzo (1): mergetools: add config option to

[PATCH] mergetools: add config option to disable auto-merge

For some mergetools, the current invocation of git mergetool will include an auto-merge flag. By default the flag is included, however if the git config option 'merge.automerge' is set to 'false', then that flag will now be omitted. Signed-off-by: Michael Rappazzo --- Documentation/config.txt

Re: [PATCH 3/3] trace: add GIT_TRACE_STDIN

On Tue, Jun 16, 2015 at 03:49:07PM -0400, Jeff King wrote: > Another option would be to stop trying to intercept stdin in git.c, and > instead make this a feature of run-command.c. That is, right before we > exec a process, tee its stdin there. That means that you cannot do: > > GIT_TRACE_STDIN

[PATCH v2 7/7] bisect: allows any terms set by user

Matthieu Moy writes: ># terms_defined is 0 when the user did not define the terms explicitely ># yet. This is the case when running 'git bisect start bad_rev good_rev' ># before we see an explicit reference to a term. >terms_defined=0 The thing is: 'git bisect reset git bisect new HEAD (autostar

[PATCH v2 7/7] bisect: allows any terms set by user

Matthieu Moy writes: >I would say "for the current bisection", i.e. > >$ git bisect start >$ git bisect terms foo bar # Scope starts here >... >The first 'bar' commit is deadbeef. # Scope ends here > >$ git bisect terms foo bar >You need to start by "git bisect start" >Do you want me to

Re: Troubleshoot clone issue to NFS.

On Fri, Jun 05, 2015 at 08:18:17AM -0400, Jeff King wrote: > On Fri, Jun 05, 2015 at 12:01:16PM +, steve.nor...@thomsonreuters.com > wrote: > > > On Sunday, May 24, 2015 @ 10:01 AM Duy Nguyen [mailto:pclo...@gmail.com] > > did scribble: > > > > > In case you want to back away from option 2

Re: [PATCH] Documentation/describe: improve one-line summary

Matthieu Moy writes: > diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt > index d20ca40..e045fc7 100644 > --- a/Documentation/git-describe.txt > +++ b/Documentation/git-describe.txt > @@ -3,7 +3,7 @@ git-describe(1) > > NAME > > -git-describe - Show the most r

Re: Visualizing merge conflicts after the fact (using kdiff3)

On 6/16/2015 2:43 AM, Johannes Schindelin wrote: > Hi Eric, > > On 2015-06-16 03:17, Eric Raible wrote: >> I'm running 1.9.5.msysgit.1, but this is a general git question... >> >> Upon returning from a vacation, I was looking at what people had been >> up to, and discovered on merge in which a co

Re: Should the --encoding argument to log/show commands make any guarantees about their output?

On 2015-06-16 11.38, Jan-Philip Gehrcke wrote: > On 15.06.2015 18:21, Torsten Bögershausen wrote: >> On 2015-06-15 10.50, Jan-Philip Gehrcke wrote: >>> Let me describe what I think it currently does: >>> >>> The program attempts to re-code a log message, so it follows the chain >>> >>> raw inp

Re: [PATCH 3/3] trace: add GIT_TRACE_STDIN

On Tue, Jun 16, 2015 at 03:37:16PM -0400, Jeff King wrote: > For instance: > > GIT_TRACE=/tmp/processes.out \ > GIT_TRACE_STDIN=/tmp/stdin.%p \ > git daemon ... > > After a fetch, processes.out will contain a line like: > > 15:19:08.275493 [pid=13196] git.c:348 trace: > bu

[PATCH 2/3] trace: add pid to each output line

When there are many git commands running, it can be confusing which process is producing which message. And if one is trying to correlate a specific invocation with a trace-file created using "%p", it's rather impossible. Let's print the pid alongside each line. This does extend the already-wide t

[PATCH 3/3] trace: add GIT_TRACE_STDIN

Sometimes tracing the invocation of git programs with GIT_TRACE is not quite enough to replay a situation; the interesting input to the program often comes over its standard input. For instance, if you want to replay a particular fetch (e.g., for performance analysis or debugging), you would want b

[PATCH 1/3] trace: implement %p placeholder for filenames

This lets you trace output on a per-process basis by naming the trace file after the PID. This is probably not all that useful for GIT_TRACE itself (which is about a global view of the process hierarchy anyway), but will be useful for traces which produce large amounts of data (e.g., whole packfile

[PATCH/RFC 0/3] add GIT_TRACE_STDIN

On Tue, Jun 16, 2015 at 01:23:31PM -0400, Augie Fackler wrote: > > I guess there is really room for both. Just because you _can_ accomplish > > the same thing with both does not mean we cannot have two ways to do it > > (an easy way, and a harder, more flexible way). > > *nod* that might make the

Re: [PATCH] Fix power checking on OS X

Ah, thanks. Not many people do that, so I was wondering what was going on ;-). On Tue, Jun 16, 2015 at 10:35 AM, Panagiotis Astithas wrote: > On Tue, Jun 16, 2015 at 8:32 PM, Junio C Hamano wrote: >> Panagiotis Astithas writes: >> >>> The output of "pmset -g batt" changed at some point from >>

Re: [PATCH] Fix power checking on OS X

On Tue, Jun 16, 2015 at 8:32 PM, Junio C Hamano wrote: > Panagiotis Astithas writes: > >> The output of "pmset -g batt" changed at some point from >> "Currently drawing from 'AC Power'" to the slightly different >> "Now drawing from 'AC Power'". Starting the match from "drawing" >> makes the chec

Re: [PATCH] Fix power checking on OS X

Panagiotis Astithas writes: > The output of "pmset -g batt" changed at some point from > "Currently drawing from 'AC Power'" to the slightly different > "Now drawing from 'AC Power'". Starting the match from "drawing" > makes the check work in both old and new versions of OS X. > > Signed-off-by:

Re: [PATCH 3/3] pkt-line: support tracing verbatim pack contents

On Tue, Jun 16, 2015 at 1:18 PM, Jeff King wrote: > On Tue, Jun 16, 2015 at 01:14:03PM -0400, Augie Fackler wrote: > >> Yeah, not having it for the push side is a slight bummer, but in >> general I haven't had problems debugging git clients pushing bogus >> data in the same way that I've had probl

Re: [PATCH 3/3] pkt-line: support tracing verbatim pack contents

On Tue, Jun 16, 2015 at 12:52:46PM -0400, Augie Fackler wrote: > Yeah, I don't have one - I may have been making assumptions because I > knew something of the background on your implementation. i'd say let > it live and if people provide feedback later figure out a reword > (writing for humans is

Re: [PATCH 3/3] pkt-line: support tracing verbatim pack contents

On Tue, Jun 16, 2015 at 01:14:03PM -0400, Augie Fackler wrote: > Yeah, not having it for the push side is a slight bummer, but in > general I haven't had problems debugging git clients pushing bogus > data in the same way that I've had problems with weirdness in new > server features. Being in ch

Re: [PATCH 3/3] pkt-line: support tracing verbatim pack contents

On Tue, Jun 16, 2015 at 1:10 PM, Jeff King wrote: > On Tue, Jun 16, 2015 at 11:38:41AM -0400, Augie Fackler wrote: > >> > We already have a GIT_TRACE_PACKET mechanism for tracing >> > packets. Let's extend it with GIT_TRACE_PACK to dump the >> > verbatim packfile. >> >> FWIW, this also works for m

Re: [PATCH 3/3] pkt-line: support tracing verbatim pack contents

On Tue, Jun 16, 2015 at 11:38:41AM -0400, Augie Fackler wrote: > > We already have a GIT_TRACE_PACKET mechanism for tracing > > packets. Let's extend it with GIT_TRACE_PACK to dump the > > verbatim packfile. > > FWIW, this also works for me - I have no preference between my patches > and Jeff's.

Re: [PATCH 3/3] pkt-line: support tracing verbatim pack contents

On Tue, Jun 16, 2015 at 12:43 PM, Jeff King wrote: > On Tue, Jun 16, 2015 at 09:39:19AM -0700, Junio C Hamano wrote: > >> As to the documentation, I have a feeling that, unless the reader >> and/or the user intimately knows that TRACE_PACK is implemented by >> hooking into the same mechanism that

Re: [PATCH 3/3] pkt-line: support tracing verbatim pack contents

On Tue, Jun 16, 2015 at 09:39:19AM -0700, Junio C Hamano wrote: > As to the documentation, I have a feeling that, unless the reader > and/or the user intimately knows that TRACE_PACK is implemented by > hooking into the same mechanism that TRACE_PACKET needs to, s/he > would not even wonder if TRA

Re: [PATCH 3/3] pkt-line: support tracing verbatim pack contents

Augie Fackler writes: > On Fri, Jun 12, 2015 at 5:28 PM, Jeff King wrote: >> When debugging the pack protocol, it is sometimes useful to >> store the verbatim pack that we sent or received on the >> wire. Looking at the on-disk result is often not helpful for >> a few reasons: >> >> 1. If the

Re: [PATCH v3 05/11] ref-filter: add parse_opt_merge_filter()

On Tue, Jun 16, 2015 at 9:48 PM, Matthieu Moy wrote: > Karthik Nayak writes: > >> This is copied from 'builtin/branch.c' which will eventually be removed >> when we port 'branch.c' to use ref-filter APIs. > > Earlier in the series you took code from tag.c. > > I think you should focus on either m

Re: [PATCH v3 05/11] ref-filter: add parse_opt_merge_filter()

Karthik Nayak writes: > This is copied from 'builtin/branch.c' which will eventually be removed > when we port 'branch.c' to use ref-filter APIs. Earlier in the series you took code from tag.c. I think you should focus on either merge or tag, get a ref-filter-based replacement that passes the t

Re: [PATCH v3 04/11] for-each-ref: add '--points-at' option

On Tue, Jun 16, 2015 at 9:30 PM, Matthieu Moy wrote: > Karthik Nayak writes: > >> --- a/Documentation/git-for-each-ref.txt >> +++ b/Documentation/git-for-each-ref.txt >> @@ -62,6 +63,8 @@ OPTIONS >> the specified host language. This is meant to produce >> a scriptlet that can directl

Re: [PATCH v3 01/11] t6301: for-each-ref tests for ref-filter APIs

On Tue, Jun 16, 2015 at 8:51 PM, Matthieu Moy wrote: > Karthik Nayak writes: > >> Add tests for 'for-each-ref' which utilizes the ref-filter APIs. >> Currently it's redundant with the tests in 't6300' but more tests >> will be eventually added as we implement more options into >> 'for-each-ref'.

Re: [PATCH v3 04/11] for-each-ref: add '--points-at' option

Karthik Nayak writes: > --- a/Documentation/git-for-each-ref.txt > +++ b/Documentation/git-for-each-ref.txt > @@ -62,6 +63,8 @@ OPTIONS > the specified host language. This is meant to produce > a scriptlet that can directly be `eval`ed. > > +--points-at :: > + Only list refs of

Re: [PATCH 2/2] Documentation on git-checkout --ours/--theirs improved

Simon Eugster writes: > 2015-06-15 22:10 GMT+02:00 Junio C Hamano : >> >> "Simon A. Eugster" writes: >> >> > --- >> >> - Lack of explanation as to why this is a good thing. >> - Lack of sign-off. >> >> Why is there still 1/2, if its effect is wholly annulled by a >> subsequent step 2/2? > > > So

Re: [PATCH 3/3] pkt-line: support tracing verbatim pack contents

On Fri, Jun 12, 2015 at 5:28 PM, Jeff King wrote: > When debugging the pack protocol, it is sometimes useful to > store the verbatim pack that we sent or received on the > wire. Looking at the on-disk result is often not helpful for > a few reasons: > > 1. If the operation is a clone, we destroy

Re: [PATCH] git-prompt.sh: Document GIT_PS1_STATESEPARATOR

Quoting SZEDER Gábor : >> diff --git a/contrib/completion/git-prompt.sh >> b/contrib/completion/git-prompt.sh >> index f18aedc..366f0bc 100644 >> --- a/contrib/completion/git-prompt.sh >> +++ b/contrib/completion/git-prompt.sh >> @@ -66,6 +66,10 @@ >> # git always compare HEAD to @{u

Re: [PATCH v3 01/11] t6301: for-each-ref tests for ref-filter APIs

Karthik Nayak writes: > Add tests for 'for-each-ref' which utilizes the ref-filter APIs. > Currently it's redundant with the tests in 't6300' but more tests > will be eventually added as we implement more options into > 'for-each-ref'. Actually, I'm not convinced that the actual tests have a rea

Re: rebase -i might leave CHERRY_PICK_HEAD behind

Hi, On 2015-06-16 14:06, SZEDER Gábor wrote: > When skipping an empty commit with 'git rebase --continue' a > CHERRY_PICK_HEAD file might be left behind. Yeah, I noticed that, too... it even survives the cleanup of the finished rebase under certain circumstances. Maybe something like this? --

Re: [PATCH] [RFC] Make git-update-ref invoke the update and post-update hooks

On Mon, Jun 15, 2015 at 3:45 PM, Junio C Hamano wrote: > Those who want to bypass your policy can use "vi .git/packed-refs" > and/or "rm .git/refs/heads/foo"; you would not propose to patch "rm" > and "vi" to pay attention to git configuration, because they are not > about "git" at all, and there

[PATCH v3 09/11] parse-options.h: add macros for '--contains' option

Add a macro for using the '--contains' option in parse-options.h also include an optional '--with' option macro which performs the same action as '--contains'. Make tag.c use this new macro. Mentored-by: Christian Couder Mentored-by: Matthieu Moy Signed-off-by: Karthik Nayak --- builtin/tag.c

[PATCH v3 08/11] parse-option: rename parse_opt_with_commit()

Rename parse_opt_with_commit() to parse_opt_commit_object_name() to show that it can be used to obtain a list of commits and is not constricted to usage of '--contains' option. Mentored-by: Christian Couder Mentored-by: Matthieu Moy Signed-off-by: Karthik Nayak --- builtin/branch.c | 4 ++--

[PATCH v3 07/11] for-each-ref: add '--merged' and '--no-merged' options

Add the '--merged' and '--no-merged' options provided by 'ref-filter'. The '--merged' option lets the user to only list refs merged into the named commit. The '--no-merged' option lets the user to only list refs not merged into the named commit. Add documentation and tests for the same. Based-on-

[PATCH v3 10/11] ref-filter: implement '--contains' option

'tag -l' and 'branch -l' have two different ways of finding out if a certain ref contains a commit. Implement both these methods in ref-filter and give the caller of ref-filter API the option to pick which implementation to be used. 'branch -l' uses 'is_descendant_of()' from commit.c which is left

[PATCH v3 11/11] for-each-ref: add '--contains' option

Add the '--contains' option provided by 'ref-filter'. The '--contains' option lists only refs which are contain the mentioned commit (HEAD if no commit is explicitly given). Add documentation and tests for the same. Mentored-by: Christian Couder Mentored-by: Matthieu Moy Signed-off-by: Karthik

[PATCH v3 06/11] ref-filter: implement '--merged' and '--no-merged' options

In 'branch -l' we have '--merged' option which only lists refs (branches) merged into the named commit and '--no-merged' option which only lists refs (branches) not merged into the named commit. Implement these two options in ref-filter.{c,h} so that other commands can benefit from this. Based-on-

[PATCH v3 05/11] ref-filter: add parse_opt_merge_filter()

Add 'parse_opt_merge_filter()' to parse '--merged' and '--no-merged' options and write MACROS for the same. This is copied from 'builtin/branch.c' which will eventually be removed when we port 'branch.c' to use ref-filter APIs. Based-on-patch-by: Jeff King Mentored-by: Christian Couder Mentored

[PATCH v3 03/11] ref-filter: implement '--points-at' option

In 'tag -l' we have '--points-at' option which lets users list only tags which point to a particular commit. Implement this option in 'ref-filter.{c,h}' so that other commands can benefit from this. This is duplicated from tag.c, we will eventually remove that when we port tag.c to use ref-filter

[PATCH v3 02/11] tag: libify parse_opt_points_at()

Rename 'parse_opt_points_at()' to 'parse_opt_object_name()' and move it from 'tag.c' to 'parse-options'. This now acts as a common parse_opt function which accepts an objectname and stores it into a sha1_array. Based-on-patch-by: Jeff King Mentored-by: Christian Couder Mentored-by: Matthieu Moy

[PATCH v3 04/11] for-each-ref: add '--points-at' option

Add the '--points-at' option provided by 'ref-filter'. The option lets the user to pick only refs which point to a particular commit. Add documentation and tests for the same. Based-on-patch-by: Jeff King Mentored-by: Christian Couder Mentored-by: Matthieu Moy Signed-off-by: Karthik Nayak ---

[PATCH v3 01/11] t6301: for-each-ref tests for ref-filter APIs

Add tests for 'for-each-ref' which utilizes the ref-filter APIs. Currently it's redundant with the tests in 't6300' but more tests will be eventually added as we implement more options into 'for-each-ref'. Based-on-patch-by: Jeff King Mentored-by: Christian Couder Mentored-by: Matthieu Moy Sign

[PATCH v3 00/11] add options to for-each-ref

This is continuation of the patch series 'Create ref-filter from for-each-ref' found at : http://thread.gmane.org/gmane.comp.version-control.git/271563 The previous version of this series can be found at : http://thread.gmane.org/gmane.comp.version-control.git/271575 Changes made: * Add PARSE_OPT

Using clean/smudge filters with difftool

Hi everyone, I created a clean filter to apply on some files before commiting them. The filter works correctly when I commit the file and is also applied when I usethe iff command line tool. However, when using difftool with meld, the filter is not applied and the different versions of the files a

Re: [PATCH] git-prompt.sh: Document GIT_PS1_STATESEPARATOR

Quoting Joe Cridge : The environment variable GIT_PS1_STATESEPARATOR can be used to set the separator between the branch name and the state symbols in the prompt. At present the variable is not mentioned in the inline documentation which makes it difficult for the casual user to identify. Tha

[PATCH] Documentation/describe: improve one-line summary

git describe does not show 'the most recent tag that is reachable from a commit', but a descriptive name based on this tag. Fix the description to reflect that. Suggested-by: Albert Netymk Signed-off-by: Matthieu Moy --- > According to the man of git-describe, http://git-scm.com/docs/git-describ

rebase -i might leave CHERRY_PICK_HEAD behind

Hi, When skipping an empty commit with 'git rebase --continue' a CHERRY_PICK_HEAD file might be left behind. What I did boils down to this: echo one >file git add file git commit -m first echo two >file git commit -a -m second echo three >file git commit -a -m third

Re: [PATCH v5 1/4] implement submodule config API for lookup of .gitmodules values

On Mon, Jun 15, 2015 at 11:06:11PM +0200, Heiko Voigt wrote: > In a superproject some commands need to interact with submodules. They > need to query values from the .gitmodules file either from the worktree > of from certain revisions. At the moment this is quite hard since a > caller would need t

git-describe manual page's one sentence summary is misleading

According to the man of git-describe, http://git-scm.com/docs/git-describe git-describe - Show the most recent tag that is reachable from a commit It means that this command shows the name of the most recent tag. However, actually, it construct a new tag name if the current commit is not tagged.

Re: [PATCH/RFC] Revert "git am/mailinfo: Don't look at in-body headers when rebasing"

Hi Paul, On 2015-06-16 11:03, Paul Tan wrote: > This reverts commit d25e51596be9271ad833805a3d6f9012dc24ee79, removing > git-mailsplit's --no-inbody-headers option. > > While --no-inbody-headers was introduced to prevent commit messages from > being munged by git-mailinfo while rebasing, the need

Re: Visualizing merge conflicts after the fact (using kdiff3)

Hi Eric, On 2015-06-16 03:17, Eric Raible wrote: > I'm running 1.9.5.msysgit.1, but this is a general git question... > > Upon returning from a vacation, I was looking at what people had been > up to, and discovered on merge in which a colleague had resolved a merge > incorrectly. It turns out t

Re: Should the --encoding argument to log/show commands make any guarantees about their output?

On 15.06.2015 18:21, Torsten Bögershausen wrote: On 2015-06-15 10.50, Jan-Philip Gehrcke wrote: Let me describe what I think it currently does: The program attempts to re-code a log message, so it follows the chain raw input -> unicode -> raw output Not sure what "raw input/output" means

Re: GitHub Pull Request merge commands

On 16/06, Florian Lindner wrote: My question is, if davidsblom make further commits to his develop branch (after the pull request was issued) aren't these commits also included in the pull and therefore in the merge? If yes, isn't the idea to merge just the changes that the pull request was about

GitHub Pull Request merge commands

Hello, GitHub proposes these commands to merge a pull requests (explanations from me, to make sure I got it correctly) # Basically branch develop to davidsblom-develop git checkout -b davidsblom-develop develop # Pull in foreign repos commits from foreign develop branch. git pull git://github.c

[PATCH/RFC] Revert "git am/mailinfo: Don't look at in-body headers when rebasing"

This reverts commit d25e51596be9271ad833805a3d6f9012dc24ee79, removing git-mailsplit's --no-inbody-headers option. While --no-inbody-headers was introduced to prevent commit messages from being munged by git-mailinfo while rebasing, the need for this option disappeared since 5e835ca (rebase: do no

[PATCH] Fix power checking on OS X

The output of "pmset -g batt" changed at some point from "Currently drawing from 'AC Power'" to the slightly different "Now drawing from 'AC Power'". Starting the match from "drawing" makes the check work in both old and new versions of OS X. Signed-off-by: Panagiotis Astithas --- contrib/hooks/

Re: [PATCH 2/2] Documentation on git-checkout --ours/--theirs improved

2015-06-15 22:10 GMT+02:00 Junio C Hamano : > > "Simon A. Eugster" writes: > > > --- > > - Lack of explanation as to why this is a good thing. > - Lack of sign-off. > > Why is there still 1/2, if its effect is wholly annulled by a > subsequent step 2/2? Sorry for that, still trying to find out h