* Re: [PATCH] push: support remote branches in guess_ref DWIM
From: Junio C Hamano @ 2009-10-27 22:33 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20091027014525.GA29583@sigio.peff.net>
Jeff King <peff@peff.net> writes:
> On Mon, Oct 26, 2009 at 04:31:57PM -0700, Junio C Hamano wrote:
>
>> As _our_ origin can never be _their_ origin if we are clone of them, I do
>> not think anybody sane would expect it to push into refs/remotes/origin/
>> to begin with.
>
> OK, I agree.
>
>> But "not in refs/remotes/" does not automatically mean "the only sensible
>> place is refs/heads", does it? "We do not know what kind of mistake the
>> user is trying to make" could be more plausible answer, and in that case,
>> "complain and die" may be a more valid course of action.
>
> The thing is that I can't think of another sensible place. And this
> sensible place is useful for one particular action: renaming a remote
> branch, like this:
>
> $ git fetch ;# presumably gets origin/branch
> $ git push origin/branch:renamed-branch
>
> which is much nicer than exposing clueless users to
> ":refs/heads/renamed-branch".
You would need to expose ":refs/heads/branch" to make this a rename, not a
copy, wouldn't you?
>> For example,
>>
>> git push origin origin/master:refs/heads/master
>>
>> is most likely to be a mistake. The only situation something similar to
>> this makes sense is where you pushed out a bogus commit earlier and are
>> trying to correct it perhaps with
>
> I'm not sure why it's likely to be a mistake.
> ...
> Am I missing some part of your argument?
I do not see much point (other than your "rename" example) in pushing what
you got from the other end without changing anything yourself back to the
same remote.
There was a thread in which people argued that the primary thing that is
dangerous in this sequence
$ git checkout origin/next; work-commit; work-commit; ...
is when you leave the detached HEAD state without saving it to a local
branch. I think what is more dangerous is that it will not give the user
a solid understanding that these commits do _not_ change origin/next in
any way. After doing the above, it is understandable that a novice would
mistakenly think: "I started from origin/next and built some, let's push
the result".
Side note: This is the reason why I think Dscho's "git checkout
next" that dwims to "-t -b next origin/next" is OK (perhaps on the
right side of the borderline), because it is more clear that this
is about creating and using your own "next", compared to the
existing "-t origin/next" shorthand. The latter risks imprinting
a misconception on an uninitiated that we are somehow working on
origin/next.
With such a misconception, you will see the likely mistake here, too:
$ git push origin origin/next:refs/heads/next
If "rename" is the _only_ valid reason you might want to push what you got
from there back to the same remote, _and_ if "rename" is something very
often needed, I think we would prefer to have a way to support that
operation directly, instead of more general DWIM that would risk passing
mistakes like the above unwarned.
> ... But I'm not sure why
> you would accidentally provide something in refs/remotes, or not want to
> be pushing to refs/heads. Where _else_ do you push, except for tags?
The above "checking out origin/next" illustrates the mistake on the $src
side, not on the $dst side. That's why my alternative solution in the
previous message was to see the type of $src and push commits to local
branches, exactly because "where else do you push".
IOW, it's between "prevent push with dubious $src from happening in the
first place" vs "give them rope". Historically I always sided with the
latter camp, but I am trying to play a devil's advocate for a change ;-).
^ permalink raw reply
* [PATCH] mergetool--lib: add p4merge as a pre-configured mergetool option
From: Scott Chacon @ 2009-10-27 22:36 UTC (permalink / raw)
To: git list
p4merge is now a built-in diff/merge tool.
This adds p4merge to git-completion and updates
the documentation to mention p4merge.
---
Documentation/git-difftool.txt | 2 +-
Documentation/git-mergetool.txt | 2 +-
Documentation/merge-config.txt | 2 +-
contrib/completion/git-completion.bash | 2 +-
git-mergetool--lib.sh | 17 +++++++++++++++--
5 files changed, 19 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-difftool.txt b/Documentation/git-difftool.txt
index 96a6c51..8e9aed6 100644
--- a/Documentation/git-difftool.txt
+++ b/Documentation/git-difftool.txt
@@ -31,7 +31,7 @@ OPTIONS
Use the diff tool specified by <tool>.
Valid merge tools are:
kdiff3, kompare, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff,
- ecmerge, diffuse, opendiff and araxis.
+ ecmerge, diffuse, opendiff, p4merge and araxis.
+
If a diff tool is not specified, 'git-difftool'
will use the configuration variable `diff.tool`. If the
diff --git a/Documentation/git-mergetool.txt b/Documentation/git-mergetool.txt
index 68ed6c0..4a6f7f3 100644
--- a/Documentation/git-mergetool.txt
+++ b/Documentation/git-mergetool.txt
@@ -27,7 +27,7 @@ OPTIONS
Use the merge resolution program specified by <tool>.
Valid merge tools are:
kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge,
- diffuse, tortoisemerge, opendiff and araxis.
+ diffuse, tortoisemerge, opendiff, p4merge and araxis.
+
If a merge resolution program is not specified, 'git-mergetool'
will use the configuration variable `merge.tool`. If the
diff --git a/Documentation/merge-config.txt b/Documentation/merge-config.txt
index c0f96e7..a403155 100644
--- a/Documentation/merge-config.txt
+++ b/Documentation/merge-config.txt
@@ -23,7 +23,7 @@ merge.tool::
Controls which merge resolution program is used by
linkgit:git-mergetool[1]. Valid built-in values are: "kdiff3",
"tkdiff", "meld", "xxdiff", "emerge", "vimdiff", "gvimdiff",
- "diffuse", "ecmerge", "tortoisemerge", "araxis", and
+ "diffuse", "ecmerge", "tortoisemerge", "p4merge", "araxis" and
"opendiff". Any other value is treated is custom merge tool
and there must be a corresponding mergetool.<tool>.cmd option.
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index d3fec32..5fb6017 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -953,7 +953,7 @@ _git_diff ()
}
__git_mergetools_common="diffuse ecmerge emerge kdiff3 meld opendiff
- tkdiff vimdiff gvimdiff xxdiff araxis
+ tkdiff vimdiff gvimdiff xxdiff araxis p4merge
"
_git_difftool ()
diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
index bfb01f7..f7c571e 100644
--- a/git-mergetool--lib.sh
+++ b/git-mergetool--lib.sh
@@ -46,7 +46,7 @@ check_unchanged () {
valid_tool () {
case "$1" in
kdiff3 | tkdiff | xxdiff | meld | opendiff | \
- emerge | vimdiff | gvimdiff | ecmerge | diffuse | araxis)
+ emerge | vimdiff | gvimdiff | ecmerge | diffuse | araxis | p4merge)
;; # happy
tortoisemerge)
if ! merge_mode; then
@@ -130,6 +130,19 @@ run_merge_tool () {
"$merge_tool_path" "$LOCAL" "$REMOTE"
fi
;;
+ p4merge)
+ if merge_mode; then
+ touch "$BACKUP"
+ if $base_present; then
+ "$merge_tool_path" "$BASE" "$LOCAL" "$REMOTE" "$MERGED"
+ else
+ "$merge_tool_path" "$LOCAL" "$LOCAL" "$REMOTE" "$MERGED"
+ fi
+ check_unchanged
+ else
+ "$merge_tool_path" "$LOCAL" "$REMOTE"
+ fi
+ ;;
meld)
if merge_mode; then
touch "$BACKUP"
@@ -323,7 +336,7 @@ guess_merge_tool () {
else
tools="opendiff kdiff3 tkdiff xxdiff meld $tools"
fi
- tools="$tools gvimdiff diffuse ecmerge araxis"
+ tools="$tools gvimdiff diffuse ecmerge p4merge araxis"
fi
if echo "${VISUAL:-$EDITOR}" | grep emacs > /dev/null 2>&1; then
# $EDITOR is emacs so add emerge as a candidate
--
1.6.5.2.75.g16dea.dirty
^ permalink raw reply related
* git svn branch tracking + ignore paths
From: Lachlan Deck @ 2009-10-27 23:00 UTC (permalink / raw)
To: git list
Hi there,
(Note: relative newby)
I'm wondering if it's possible to create a branch (starting as local
but later on pushed to svn) that essentially stays in sync with the
main branch (svn trunk) but both (a) ignores pulling in certain paths
from trunk and (b) provides a few extra paths of its own (some of
which overlap with those ignored from trunk) and (c) only pushes to
trunk paths that are relevant for trunk (i.e., not specifically
ignored)?
If someone's able to share how they'd go about setting this up that'd
be great.
Thanks!
with regards,
--
Lachlan Deck
^ permalink raw reply
* Re: [PATCH] mergetool--lib: add p4merge as a pre-configured mergetool option
From: Charles Bailey @ 2009-10-27 23:00 UTC (permalink / raw)
To: Scott Chacon; +Cc: git list
In-Reply-To: <d411cc4a0910271536u5817802at43f7477dd8ccabc7@mail.gmail.com>
On Tue, Oct 27, 2009 at 03:36:49PM -0700, Scott Chacon wrote:
> p4merge is now a built-in diff/merge tool.
> This adds p4merge to git-completion and updates
> the documentation to mention p4merge.
> ---
I approve (but haven't had a chance to test this). p4merge is a
good mergetool, but now I'll have to find something else as an example
that you need to use custom mergetool support for.
I'm just wondering, does this work well with unixes and Mac OS X? I
think it's recommended install practice to symlink p4v as p4merge on
*nix, but Mac OS X needs some sort of 'launchp4merge' to be called
IIRC, or is this something that users can just configure with
mergetool.p4diff.path?
--
Charles Bailey
http://ccgi.hashpling.plus.com/blog/
^ permalink raw reply
* Re: git svn branch tracking + ignore paths
From: Avery Pennarun @ 2009-10-27 23:16 UTC (permalink / raw)
To: Lachlan Deck; +Cc: git list
In-Reply-To: <41F0F1D6-4F99-4828-9259-1B2BDC689747@gmail.com>
On Tue, Oct 27, 2009 at 7:00 PM, Lachlan Deck <lachlan.deck@gmail.com> wrote:
> I'm wondering if it's possible to create a branch (starting as local but
> later on pushed to svn) that essentially stays in sync with the main branch
> (svn trunk) but both (a) ignores pulling in certain paths from trunk and (b)
> provides a few extra paths of its own (some of which overlap with those
> ignored from trunk) and (c) only pushes to trunk paths that are relevant for
> trunk (i.e., not specifically ignored)?
>
> If someone's able to share how they'd go about setting this up that'd be
> great.
This sounds like a generally scary idea. Perhaps if you described
your problem at a higher level (what are you really trying to
achieve?) there would be a less scary way to do it.
That said, if you *really* need this... one option that comes to mind is:
1. extract the history from svn into git using 'git svn' as usual.
2. extract the subtree of svn that you're interested in (if you're
lucky enough that you only need one subtree) by using 'git subtree
split'. This creates a new branch or new git repo, depending how you
do it.
3. Create a third project that will host your new work with extra
subtrees that you don't want. Use 'git subtree add' and 'git subtree
merge' to keep this up to date with the stuff you extracted in step 2.
(Repeat steps 1-3 as necessary to keep your project up to date with
the svn project.)
4. When you want to merge your own changes back into svn, first
extract them from your own project (step 3) using 'git subtree split'.
Then merge those changes into the main project (step 1) using 'git
subtree merge'. Then use git-svn to upload them to the main svn repo.
You can save yourself some steps if you import the *entire* svn
project into your own project, rather than trying to trim it on
import. That way you only have to split when going from #3 to #1, not
in the other direction, and you don't need repository #2.
If all this sounds crazy, it probably is. Maybe see if you can come
up with a way to avoid trying to do this altogether.
Good luck... :)
Avery
[1] http://github.com/apenwarr/git-subtree
^ permalink raw reply
* Re: git update --prune issue
From: Björn Steinbrink @ 2009-10-27 23:30 UTC (permalink / raw)
To: Jeff King; +Cc: Clemens Buchacher, Jeffrey Middleton, Michael J Gruber, git
In-Reply-To: <20091027184627.GA19292@sigill.intra.peff.net>
On 2009.10.27 14:46:27 -0400, Jeff King wrote:
> On Tue, Oct 27, 2009 at 12:50:55PM -0400, Jeff King wrote:
>
> > > Actually, it's beta_gc_dev_old and beta_gc_dev, not the same refs.
> >
> > OK, I'm a bit blind. Thanks for pointing it out. I'll still see if I can
> > replicate it.
>
> I'm not having any luck reproducing here with a simple case. :( I'm
> trying:
You need more parent repos, and you need packs. What I guess what
happens is:
The first remote gets fetched from.
The first remote gets pruned. This initializes the pack stuff.
The second remote gets fetched from, and creates a _new_ _pack_.
The second remote gets pruned (*)
The third remote gets fetched from.
The third remote gets pruned.
Now, this prune step calls for_each_ref, which looks through the new
refs for the second remote. This fails, because the new pack was not
present when the pack "system" got initialzed.
(*) I have no idea why this step doesn't fail... But hey, I have no idea
about the whole pack handling either. I just recall that there's some
initialization step...
This reproduces the issue here:
#!/bin/sh
rm -rf parent* child
commit() {
echo $1 >file && git add file && git commit -m $1
}
mkdir parent0 && (
cd parent0 &&
git init &&
commit one
) &&
mkdir parent1 && (
cd parent1 &&
git init &&
commit two &&
commit three &&
git checkout -b other
) &&
mkdir parent2 && (
cd parent2 &&
git init &&
commit four
) &&
mkdir child && (
cd child &&
git init &&
git config fetch.unpackLimit 1
git remote add parent0 file://$PWD/../parent0 &&
git remote add parent1 file://$PWD/../parent1 &&
git remote add parent2 file://$PWD/../parent2 &&
git remote update
) && (
cd parent1 &&
git checkout master &&
git branch -d other &&
git reset --hard HEAD^ &&
commit five
) && (
cd child &&
git remote update --prune
)
^ permalink raw reply
* [PATCH] commit: More generous accepting of RFC-2822 footer lines.
From: David Brown @ 2009-10-27 23:45 UTC (permalink / raw)
To: git
From: David Brown <davidb@quicinc.com>
'git commit -s' will insert a blank line before the Signed-off-by
line at the end of the message, unless this last line is a
Signed-off-by line itself. Common use has other trailing lines
at the ends of commit text, in the style of RFC2822 headers.
Be more generous in considering lines to be part of this footer.
This may occasionally leave out the blank line for cases where
the commit text happens to start with a word ending in a colon,
but this results in less fixups than the extra blank lines with
Acked-by, or other custom footers.
Signed-off-by: David Brown <davidb@quicinc.com>
---
builtin-commit.c | 17 ++++++++++++++++-
t/t7501-commit.sh | 19 +++++++++++++++++++
2 files changed, 35 insertions(+), 1 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index 200ffda..f081e80 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -414,6 +414,21 @@ static void determine_author_info(void)
author_date = date;
}
+static int is_rfc2822_footer(const char *line)
+{
+ int ch;
+
+ while ((ch = *line++)) {
+ if (ch == ':')
+ return 1;
+ if ((33 <= ch && ch <= 57) ||
+ (59 <= ch && ch <= 126))
+ continue;
+ break;
+ }
+ return 0;
+}
+
static int prepare_to_commit(const char *index_file, const char *prefix,
struct wt_status *s)
{
@@ -489,7 +504,7 @@ static int prepare_to_commit(const char *index_file, const char *prefix,
for (i = sb.len - 1; i > 0 && sb.buf[i - 1] != '\n'; i--)
; /* do nothing */
if (prefixcmp(sb.buf + i, sob.buf)) {
- if (prefixcmp(sb.buf + i, sign_off_header))
+ if (!is_rfc2822_footer(sb.buf + i))
strbuf_addch(&sb, '\n');
strbuf_addbuf(&sb, &sob);
}
diff --git a/t/t7501-commit.sh b/t/t7501-commit.sh
index e2ef532..05542b4 100755
--- a/t/t7501-commit.sh
+++ b/t/t7501-commit.sh
@@ -247,6 +247,25 @@ $existing" &&
'
+test_expect_success 'signoff gap' '
+
+ echo 3 >positive &&
+ git add positive &&
+ alt="Alt-RFC-822-Header: Value" &&
+ git commit -s -m "welcome
+
+$alt" &&
+ git cat-file commit HEAD | sed -e "1,/^\$/d" > actual &&
+ (
+ echo welcome
+ echo
+ echo $alt
+ git var GIT_COMMITTER_IDENT |
+ sed -e "s/>.*/>/" -e "s/^/Signed-off-by: /"
+ ) >expected &&
+ test_cmp expected actual
+'
+
test_expect_success 'multiple -m' '
>negative &&
--
1.6.5.1
^ permalink raw reply related
* Re: [PATCH] push: support remote branches in guess_ref DWIM
From: Jeff King @ 2009-10-28 0:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vaazc31sj.fsf@alter.siamese.dyndns.org>
On Tue, Oct 27, 2009 at 03:33:16PM -0700, Junio C Hamano wrote:
> > $ git fetch ;# presumably gets origin/branch
> > $ git push origin/branch:renamed-branch
> >
> > which is much nicer than exposing clueless users to
> > ":refs/heads/renamed-branch".
>
> You would need to expose ":refs/heads/branch" to make this a rename, not a
> copy, wouldn't you?
Yeah, you're right. This was based on an actual user request, and I
didn't think too closely about the other steps. But since the deletion
is of an existing branch, you should be able to do that without
refs/heads. So:
$ git push origin origin/branch:renamed-branch
$ git push origin :branch
Which of course you could do in one command if you wanted to live
(more) dangerously.
> > Am I missing some part of your argument?
>
> I do not see much point (other than your "rename" example) in pushing what
> you got from the other end without changing anything yourself back to the
> same remote.
I don't either; my hope was that we can make that case a little bit
easier without creating undue hardship for anybody else.
> There was a thread in which people argued that the primary thing that is
> dangerous in this sequence
>
> $ git checkout origin/next; work-commit; work-commit; ...
>
> is when you leave the detached HEAD state without saving it to a local
> branch. I think what is more dangerous is that it will not give the user
> a solid understanding that these commits do _not_ change origin/next in
> any way. After doing the above, it is understandable that a novice would
> mistakenly think: "I started from origin/next and built some, let's push
> the result".
I suppose it's possible. I don't have any evidence that users actually
think that way.
> With such a misconception, you will see the likely mistake here, too:
>
> $ git push origin origin/next:refs/heads/next
>
> If "rename" is the _only_ valid reason you might want to push what you got
> from there back to the same remote, _and_ if "rename" is something very
> often needed, I think we would prefer to have a way to support that
> operation directly, instead of more general DWIM that would risk passing
> mistakes like the above unwarned.
OK, I can buy that. It would be much nicer even to support explicit
renaming (in fact, the user request started with that, and I just didn't
want to give them an answer that involved refs/heads/, which I think is
unnecessarily scary to users).
> IOW, it's between "prevent push with dubious $src from happening in the
> first place" vs "give them rope". Historically I always sided with the
> latter camp, but I am trying to play a devil's advocate for a change ;-).
Heh. Thanks for explaining your thinking.
Let's scrap this for now, then. Remote rename doesn't actually come up
very often, and I agree that it would be nice to have an actual atomic
movement, which is what people really want.
-Peff
^ permalink raw reply
* Re: [PATCH] commit: More generous accepting of RFC-2822 footer lines.
From: Shawn O. Pearce @ 2009-10-28 0:05 UTC (permalink / raw)
To: David Brown; +Cc: git
In-Reply-To: <20091027234520.GA11433@quaoar.codeaurora.org>
David Brown <davidb@codeaurora.org> wrote:
> From: David Brown <davidb@quicinc.com>
>
> 'git commit -s' will insert a blank line before the Signed-off-by
> line at the end of the message, unless this last line is a
> Signed-off-by line itself. Common use has other trailing lines
> at the ends of commit text, in the style of RFC2822 headers.
>
> Be more generous in considering lines to be part of this footer.
> This may occasionally leave out the blank line for cases where
> the commit text happens to start with a word ending in a colon,
> but this results in less fixups than the extra blank lines with
> Acked-by, or other custom footers.
The nasty perl I use in Gerrit's commit-msg hook is a bit more
expressive. Basically the rule is we insert a blank line before
the new footer unless all lines in the last paragraph (so all text
after the last "\n\n" sequence) match the regex "^[a-zA-Z0-9-]+:".
> +test_expect_success 'signoff gap' '
> +
> + echo 3 >positive &&
> + git add positive &&
> + alt="Alt-RFC-822-Header: Value" &&
> + git commit -s -m "welcome
> +
> +$alt" &&
I wonder if we shouldn't also have a test case for the message:
msg="test
this is a test that
fixes: 42.
"
as the result would be expected to be:
exp="test
this is a test that
fixes: 42.
Signed-off-by A. U. Thor <...>
"
But:
msg="test
this is a test
fixes: 42
"
would produce:
exp="test
this is a test
fixes: 42
Signed-off-by A. U. Thor <...>
"
--
Shawn.
^ permalink raw reply
* Re: [PATCH 1/3] update http tests according to remote-curl capabilities
From: Shawn O. Pearce @ 2009-10-28 0:10 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: Mark Lodato, git
In-Reply-To: <1256472380-924-2-git-send-email-drizzd@aon.at>
Clemens Buchacher <drizzd@aon.at> wrote:
> o Pushing packed refs is now fixed.
>
> o The transport helper fails if refs are already up-to-date. Add a
> test for that.
>
> o The transport helper will notice if refs are already up-to-date. We
> therefore need to update server info in the unpacked-refs test.
>
> o The transport helper will purge deleted branches automatically.
>
> Signed-off-by: Clemens Buchacher <drizzd@aon.at>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
> t/t5540-http-push.sh | 14 +++++++++-----
> 1 files changed, 9 insertions(+), 5 deletions(-)
--
Shawn.
^ permalink raw reply
* Re: [PATCH 2/3] remote-helpers: return successfully if everything up-to-date
From: Shawn O. Pearce @ 2009-10-28 0:11 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: Mark Lodato, git
In-Reply-To: <1256472380-924-3-git-send-email-drizzd@aon.at>
Clemens Buchacher <drizzd@aon.at> wrote:
>
> Signed-off-by: Clemens Buchacher <drizzd@aon.at>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
> t/t5540-http-push.sh | 2 +-
> transport-helper.c | 2 ++
> 2 files changed, 3 insertions(+), 1 deletions(-)
--
Shawn.
^ permalink raw reply
* Re: [PATCH 3/3] add smart HTTP tests
From: Shawn O. Pearce @ 2009-10-28 0:17 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: Mark Lodato, git
In-Reply-To: <1256472380-924-4-git-send-email-drizzd@aon.at>
Clemens Buchacher <drizzd@aon.at> wrote:
> Set LIB_HTTPD_GIT to enable smart HTTP tests.
My concern here is we have to run the test suite twice in order to
test HTTP support. We should only run it once, with GIT_TEST_HTTPD=1
set and have it all run at once.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] bash: complete more options for 'git rebase'
From: Shawn O. Pearce @ 2009-10-28 0:32 UTC (permalink / raw)
To: Bj??rn Gustavsson; +Cc: git
In-Reply-To: <4AD98F72.1060901@gmail.com>
Bj??rn Gustavsson <bgustavsson@gmail.com> wrote:
> Complete all long options for 'git rebase' except --no-verify
> (probably used very seldom) and the long options corresponding
> to -v, -q, and -f.
>
> Signed-off-by: Bj??rn Gustavsson <bgustavsson@gmail.com>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
> I am primarily interested in having the --whitespace= option completed,
> but while at it I have added completion for the other potentially useful
> long options.
Indeed, this would be nice. :-)
--
Shawn.
^ permalink raw reply
* [PATCH] add-interactive: handle deletion of empty files
From: Jeff King @ 2009-10-28 0:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Usually we show deletion as a big hunk deleting all of the
file's text. However, for files with no content, the diff
shows just the 'deleted file mode ...' line. This patch
cause "add -p" (and related commands) to recognize that line
and explicitly ask about deleting the file.
We only add the "stage this deletion" hunk for empty files,
since other files will already ask about the big content
deletion hunk. We could also change those files to simply
display "stage this deletion", but showing the actual
deleted content is probably what an interactive user wants.
Signed-off-by: Jeff King <peff@peff.net>
---
This bit me today. I expect it's pretty rare, but I don't see a reason
not to handle the corner case (and nor do I see a reason to change the
non-corner case, as explained above).
git-add--interactive.perl | 18 +++++++++++++-----
t/t3701-add-interactive.sh | 17 +++++++++++++++++
2 files changed, 30 insertions(+), 5 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index 69aeaf0..8ce1ec9 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -731,14 +731,17 @@ sub parse_diff_header {
my $head = { TEXT => [], DISPLAY => [], TYPE => 'header' };
my $mode = { TEXT => [], DISPLAY => [], TYPE => 'mode' };
+ my $deletion = { TEXT => [], DISPLAY => [], TYPE => 'deletion' };
for (my $i = 0; $i < @{$src->{TEXT}}; $i++) {
- my $dest = $src->{TEXT}->[$i] =~ /^(old|new) mode (\d+)$/ ?
- $mode : $head;
+ my $dest =
+ $src->{TEXT}->[$i] =~ /^(old|new) mode (\d+)$/ ? $mode :
+ $src->{TEXT}->[$i] =~ /^deleted file/ ? $deletion :
+ $head;
push @{$dest->{TEXT}}, $src->{TEXT}->[$i];
push @{$dest->{DISPLAY}}, $src->{DISPLAY}->[$i];
}
- return ($head, $mode);
+ return ($head, $mode, $deletion);
}
sub hunk_splittable {
@@ -1206,7 +1209,7 @@ sub patch_update_file {
my ($ix, $num);
my $path = shift;
my ($head, @hunk) = parse_diff($path);
- ($head, my $mode) = parse_diff_header($head);
+ ($head, my $mode, my $deletion) = parse_diff_header($head);
for (@{$head->{DISPLAY}}) {
print;
}
@@ -1214,6 +1217,9 @@ sub patch_update_file {
if (@{$mode->{TEXT}}) {
unshift @hunk, $mode;
}
+ if (@{$deletion->{TEXT}} && !@hunk) {
+ @hunk = ($deletion);
+ }
$num = scalar @hunk;
$ix = 0;
@@ -1267,7 +1273,9 @@ sub patch_update_file {
print;
}
print colored $prompt_color, $patch_mode_flavour{VERB},
- ($hunk[$ix]{TYPE} eq 'mode' ? ' mode change' : ' this hunk'),
+ ($hunk[$ix]{TYPE} eq 'mode' ? ' mode change' :
+ $hunk[$ix]{TYPE} eq 'deletion' ? ' deletion' :
+ ' this hunk'),
$patch_mode_flavour{TARGET},
" [y,n,q,a,d,/$other,?]? ";
my $line = prompt_single_character;
diff --git a/t/t3701-add-interactive.sh b/t/t3701-add-interactive.sh
index 687bd7a..768236b 100755
--- a/t/t3701-add-interactive.sh
+++ b/t/t3701-add-interactive.sh
@@ -228,4 +228,21 @@ test_expect_success 'add first line works' '
test_cmp expected diff
'
+cat >expected <<EOF
+diff --git a/empty b/empty
+deleted file mode 100644
+index e69de29..0000000
+EOF
+
+test_expect_success 'deleting an empty file' '
+ git reset --hard &&
+ > empty &&
+ git add empty &&
+ git commit -m empty &&
+ rm empty &&
+ echo y | git add -p empty &&
+ git diff --cached >diff &&
+ test_cmp expected diff
+'
+
test_done
--
1.6.5.2.193.g57820
^ permalink raw reply related
* Re: [RFC PATCH v3 10/17] Move WebDAV HTTP push under remote-curl
From: Shawn O. Pearce @ 2009-10-28 1:08 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: git, Daniel Barkalow, Mike Hommey
In-Reply-To: <20091019105921.d58c2728.rctay89@gmail.com>
Tay Ray Chuan <rctay89@gmail.com> wrote:
> On Thu, Oct 15, 2009 at 11:36 AM, Shawn O. Pearce <spearce@spearce.org> wrote:
> > diff --git a/Documentation/git-remote-helpers.txt b/Documentation/git-remote-helpers.txt
> > @@ -34,6 +34,10 @@ Commands are given by the caller on the helper's standard input, one per line.
> > value of the ref. A space-separated list of attributes follows
> > the name; unrecognized attributes are ignored. After the
> > complete list, outputs a blank line.
> > ++
> > +If 'push' is supported this may be called as 'list for-push'
> > +to obtain the current refs prior to sending one or more 'push'
> > +commands to the helper.
>
> The new paragraph should have the same indentation as 'list'.
Isn't the style I have here the standard way of adding a second
paragraph to a list item?
> It would have been great if you implemented this as a filter, such that
> 'list <attr>' lists the refs with the specified attribute <attr>,
> rather than hardcoding it.
Ack, will fix.
> > @@ -59,6 +63,22 @@ suitably updated.
> > +When the push is complete, outputs one or more 'ok <dst>' or
> > +'error <dst> <why>?' lines to indicate success or failure of
> > +each pushed ref. The status report output is terminated by
> > +a blank line. The option field <why> may be quoted in a C
> > +style string if it contains an LF.
>
> You should mention that this behaviour only occurs when the
> --helper-status option is used.
No. This manual page is about what a helper program must do, so I
mean what "git-remote-curl" must do. The fact that git-remote-curl
honors this output format via passing the --helper-status option
into a command it executes is an implementation detail.
> > @@ -106,6 +132,11 @@ OPTIONS
> > +'option dry-run' \{'true'|'false'\}:
> > + If true, pretend like the operation completed successfully,
> > + but don't actually change any repository data. For most
> > + helpers this only applies to the 'push', if supported.
> > +
>
> The 'like' after 'pretend' can be, like, removed. :)
Thanks, fixed.
> Two more areas in http-push.c that should have status messages
> (generated on top of pu):
I folded your patches into my series, thanks.
--
Shawn.
^ permalink raw reply
* Re: [PATCH/RFC 2/2] completion: allow use without compiling
From: Stephen Boyd @ 2009-10-28 1:43 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git, Clemens Buchacher, Sverre Rabbelier
In-Reply-To: <20091027185223.GH10505@spearce.org>
Shawn O. Pearce wrote:
> NAK on code duplication, especially this much. As Junio already
> pointed out in this thread we need an approach that doesn't cause
> this sort of redundant code.
Ok. Following Junio's suggestion I think we would have to do the following:
(1) Revert the rename (git-completion.bash.in -> git-completion.bash)
(2) Add a "generation" mode to git-completion.bash.generate to generate
the lists and output them to a file
(3) Add logic in git-completion.bash.generate to source the generated
file if it exists
(4) Source git-completion.bash.generate in git-completion.bash to get
the functions moved there
In the end we would have git-completion.bash sourcing
git-completion.bash.generate which then sources the generated file. I
assume this is slower than compiling to just one file.
Or we could just not load the caches until they're needed. This just
delays the performance hit to completion time, but at least it speeds up
loading the script without the need to compile and still has the benefit
of some caching. It also allows users to keep the completion of their
custom merge strategies and git programs in their PATH.
----8<----
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index d3fec32..8a7cde3 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -326,10 +326,15 @@ __git_remotes ()
__git_merge_strategies ()
{
- if [ -n "${__git_merge_strategylist-}" ]; then
+ if [ -n "${__git_merge_strategylist-}" ] || {
+ __git_merge_strategylist=$(__git_merge_strategies_gen 2>/dev/null)
+ }; then
echo "$__git_merge_strategylist"
- return
fi
+}
+
+__git_merge_strategies_gen ()
+{
git merge -s help 2>&1 |
sed -n -e '/[Aa]vailable strategies are: /,/^$/{
s/\.$//
@@ -340,7 +345,6 @@ __git_merge_strategies ()
}'
}
__git_merge_strategylist=
-__git_merge_strategylist=$(__git_merge_strategies 2>/dev/null)
__git_complete_file ()
{
@@ -491,10 +495,15 @@ __git_complete_strategy ()
__git_all_commands ()
{
- if [ -n "${__git_all_commandlist-}" ]; then
+ if [ -n "${__git_all_commandlist-}" ] || {
+ __git_all_commandlist="$(__git_all_commands_gen 2>/dev/null)"
+ }; then
echo "$__git_all_commandlist"
- return
fi
+}
+
+__git_all_commands_gen ()
+{
local i IFS=" "$'\n'
for i in $(git help -a|egrep '^ [a-zA-Z0-9]')
do
@@ -505,14 +514,18 @@ __git_all_commands ()
done
}
__git_all_commandlist=
-__git_all_commandlist="$(__git_all_commands 2>/dev/null)"
__git_porcelain_commands ()
{
- if [ -n "${__git_porcelain_commandlist-}" ]; then
+ if [ -n "${__git_porcelain_commandlist-}" ] || {
+ __git_porcelain_commandlist="$(__git_porcelain_commands_gen 2>/dev/null)"
+ }; then
echo "$__git_porcelain_commandlist"
- return
fi
+}
+
+__git_porcelain_commands_gen ()
+{
local i IFS=" "$'\n'
for i in "help" $(__git_all_commands)
do
@@ -596,7 +609,6 @@ __git_porcelain_commands ()
done
}
__git_porcelain_commandlist=
-__git_porcelain_commandlist="$(__git_porcelain_commands 2>/dev/null)"
__git_aliases ()
{
^ permalink raw reply related
* how to split a hunk
From: bill lam @ 2009-10-28 2:21 UTC (permalink / raw)
To: git
There are occasions where diff of a file is
- aaaa
+ bbbb
+ cccc
I want to add lines bbbb and cccc as separated commits, but git-add -p
seem cannot further split this hunk. Do I have no choice but to edit
it by hand and commit the bbbb and then edit the file to add back the
cccc?
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
^ permalink raw reply
* Re: git svn branch tracking + ignore paths
From: Lachlan Deck @ 2009-10-28 3:00 UTC (permalink / raw)
To: Avery Pennarun; +Cc: git list
In-Reply-To: <32541b130910271616ha861d08xa4b90b822d31f0ea@mail.gmail.com>
On 28/10/2009, at 10:16 AM, Avery Pennarun wrote:
> On Tue, Oct 27, 2009 at 7:00 PM, Lachlan Deck
> <lachlan.deck@gmail.com> wrote:
>> I'm wondering if it's possible to create a branch (starting as
>> local but
>> later on pushed to svn) that essentially stays in sync with the
>> main branch
>> (svn trunk) but both (a) ignores pulling in certain paths from
>> trunk and (b)
>> provides a few extra paths of its own (some of which overlap with
>> those
>> ignored from trunk) and (c) only pushes to trunk paths that are
>> relevant for
>> trunk (i.e., not specifically ignored)?
>>
>> If someone's able to share how they'd go about setting this up
>> that'd be
>> great.
>
> This sounds like a generally scary idea. Perhaps if you described
> your problem at a higher level (what are you really trying to
> achieve?) there would be a less scary way to do it.
:) Sure. Essentially a project that I'm contributing to has both maven
poms and ant/lib-based configs (with the ant ones as default for
eclipse .project etc files). I'd like to be able to import the
projects with maven into Eclipse to work on things but without
committing back changes to eclipse .project/.classpath/.settings/*.
So I'm hoping for a fairly transparent process.
> That said, if you *really* need this... one option that comes to
> mind is:
>
> 1. extract the history from svn into git using 'git svn' as usual.
>
> 2. extract the subtree of svn that you're interested in (if you're
> lucky enough that you only need one subtree) by using 'git subtree
> split'. This creates a new branch or new git repo, depending how you
> do it.
>
> 3. Create a third project that will host your new work with extra
> subtrees that you don't want. Use 'git subtree add' and 'git subtree
> merge' to keep this up to date with the stuff you extracted in step 2.
> (Repeat steps 1-3 as necessary to keep your project up to date with
> the svn project.)
>
> 4. When you want to merge your own changes back into svn, first
> extract them from your own project (step 3) using 'git subtree split'.
> Then merge those changes into the main project (step 1) using 'git
> subtree merge'. Then use git-svn to upload them to the main svn repo.
>
> You can save yourself some steps if you import the *entire* svn
> project into your own project, rather than trying to trim it on
> import. That way you only have to split when going from #3 to #1, not
> in the other direction, and you don't need repository #2.
>
> If all this sounds crazy, it probably is. Maybe see if you can come
> up with a way to avoid trying to do this altogether.
>
> Good luck... :)
Sounding scary. But if the above description of what I'm trying to
achieve helps in finding a simple way to work I'm all ears :)
Thanks.
> Avery
>
> [1] http://github.com/apenwarr/git-subtree
I'll check this out anyway. Thanks.
with regards,
--
Lachlan Deck
^ permalink raw reply
* Re: how to split a hunk
From: Geert Bosch @ 2009-10-28 3:11 UTC (permalink / raw)
To: bill lam; +Cc: git
In-Reply-To: <20091028022105.GE3938@debian.b2j>
On Oct 27, 2009, at 22:21, bill lam wrote:
> There are occasions where diff of a file is
>
> - aaaa
> + bbbb
> + cccc
>
> I want to add lines bbbb and cccc as separated commits, but git-add -p
> seem cannot further split this hunk. Do I have no choice but to edit
> it by hand and commit the bbbb and then edit the file to add back the
> cccc?
>
I like to use "git gui" for this. This allows you to pick individual
lines to commit. I really like the "git gui" interface for staging/
unstaging
changes and making a series of commits.
-Geert
^ permalink raw reply
* Re: [PATCH] gitk: Use the --submodule option for diffs
From: Paul Mackerras @ 2009-10-28 4:03 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <4AE70AC9.6040302@web.de>
Jens Lehmann writes:
> Instead of just showing not-quite-helpful SHA-1 pairs display the first
> lines of the corresponding commit messages in the submodule (similar to
> the output of 'git submodule summary').
>
> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
> ---
>
> This patch applies to 'next' and uses the new --submodule option of git
> diff to achieve a more meaningful output of submodule differences in
> gitk.
(That sentence should have been in the commit message.)
> Any objections against making this the default?
What version of git is the first to have the --submodule option?
Since it's a new option we should make gitk use it only if the
underlying git is new enough, like we do with the --textconv option.
Also, the commit message is a bit sparse; it doesn't mention that this
affects the diff display, for instance.
Paul.
^ permalink raw reply
* [PATCH] imap-send.c: fix pointer to be const
From: Vietor Liu @ 2009-10-28 5:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Fixes some compiler warnings:
imap-send.c: In function ‘ssl_socket_connect’:
warning: assignment discards qualifiers from pointer target type
Signed-off-by: Vietor Liu <vietor@vxwo.org>
---
imap-send.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/imap-send.c b/imap-send.c
index 3847fd1..10dd025 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -273,7 +273,7 @@ static int ssl_socket_connect(struct imap_socket *sock, int use_tls_only, int ve
fprintf(stderr, "SSL requested but SSL support not compiled in\n");
return -1;
#else
- SSL_METHOD *meth;
+ const SSL_METHOD *meth;
SSL_CTX *ctx;
int ret;
--
1.6.5.2
^ permalink raw reply related
* Re: git svn branch tracking + ignore paths
From: Avery Pennarun @ 2009-10-28 5:20 UTC (permalink / raw)
To: Lachlan Deck; +Cc: git list
In-Reply-To: <AC7B0CB1-1B14-4EAE-A6B6-D0845EACE626@gmail.com>
On Tue, Oct 27, 2009 at 11:00 PM, Lachlan Deck <lachlan.deck@gmail.com> wrote:
> :) Sure. Essentially a project that I'm contributing to has both maven poms
> and ant/lib-based configs (with the ant ones as default for eclipse .project
> etc files). I'd like to be able to import the projects with maven into
> Eclipse to work on things but without committing back changes to eclipse
> .project/.classpath/.settings/*.
>
> So I'm hoping for a fairly transparent process.
So which are the files you don't want to import from trunk? It
doesn't sound like there are any... so it's getting simpler already.
Also, can you just simply not commit any changes to the other files?
That would be the easiest way to deal with committing back. The other
option (slightly messier) is to change them in a single commit, and
use git rebase to move that commit out of the way when you're about to
push your changes back into svn.
Have fun,
Avery
^ permalink raw reply
* Re: git svn branch tracking + ignore paths
From: Lachlan Deck @ 2009-10-28 5:59 UTC (permalink / raw)
To: Avery Pennarun; +Cc: git list
In-Reply-To: <32541b130910272220p59482397wef0d51b1adf1a5bd@mail.gmail.com>
On 28/10/2009, at 4:20 PM, Avery Pennarun wrote:
> On Tue, Oct 27, 2009 at 11:00 PM, Lachlan Deck
> <lachlan.deck@gmail.com> wrote:
>> :) Sure. Essentially a project that I'm contributing to has both
>> maven poms
>> and ant/lib-based configs (with the ant ones as default for
>> eclipse .project
>> etc files). I'd like to be able to import the projects with maven
>> into
>> Eclipse to work on things but without committing back changes to
>> eclipse
>> .project/.classpath/.settings/*.
>>
>> So I'm hoping for a fairly transparent process.
>
> So which are the files you don't want to import from trunk? It
> doesn't sound like there are any... so it's getting simpler already.
There are. I've currently (as a workaround) done the following within
the main branch:
add the following to .git/info/exclude
.settings
target
.classpath
.project
The last two of these has no effect of course because .project
and .classpath files already exist -- and thus are marked as modified.
So I'm currently doing a git stash && git svn rebase && git svn
dcommit && git stash pop
I'm also wanting to exclude 'lib' folders from trunk (as these are not
needed).
> Also, can you just simply not commit any changes to the other files?
> That would be the easiest way to deal with committing back.
That's what I'm doing now I guess - but it means I can't share the
project setups (specific for maven, for example) with anyone.
> The other
> option (slightly messier) is to change them in a single commit, and
> use git rebase to move that commit out of the way when you're about to
> push your changes back into svn.
Yeah that'd be a bit of a slippery slope.
with regards,
--
Lachlan Deck
^ permalink raw reply
* Re: [PATCH] gitignore: root most patterns at the top-level directory
From: Junio C Hamano @ 2009-10-28 6:03 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20091027011024.GA29361@sigio.peff.net>
Jeff King <peff@peff.net> writes:
> Our gitignore doesn't use a preceding "/" to root its
> patterns in the top of the repository. This means that if
> you add a file or directory called "git" (for example)
> inside a subdirectory, it will be erroneously ignored.
>
> This patch was done mechanically with "s/^[^*]/\/&/" with
> one exception: instead of ignoring gitk-wish, we should
> gitk-git/gitk-wish (arguably, this should be done in
> gitk-git/.gitignore, but because that is a subtree merge
> from elsewhere, this is easier).
>
> Acked-by: Sverre Rabbelier <srabbelier@gmail.com>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
>
> This bit Sverre while I was looking over his shoulder. I doubt it comes
> up very often, but we should probably be modeling good gitignore
> behavior. I have to admit it looks a lot uglier, though.
How does .cvsignore and .svnignore work? Don't they have the same issue,
and perhaps worse as I do not recall seeing a way to anchor a pattern to a
particular directory like we do in their .SCMignore files? And judging
from the fact that they can get away with the lack of that "feature", this
perhaps is not an issue in real life?
I am actually a bit reluctant to queue this, even though I most likely
will, and then hope that we will think of a better solution later, at
which time this file again needs to change.
For example, it crossed my mind that perhaps we can change the ignore
rules so that a non-globbing pattern is automatically anchored at the
current directly but globbing ones are recursive as before.
If we do so, there is no need to change the current .gitignore entires.
You need to spell a concrete filename as a glob pattern that matches only
one path if you want the recursive behaviour. E.g. if you have a Makefile
per subdirectory, each of which generates and includes Makefile.depend
file, you would write "Makefile.depen[d]" in the toplevel .gitignore file.
But that is a kind of incompatible change whose necessity is unproven and
has to cook and wait.
^ permalink raw reply
* Re: [PATCH 2/2] git-completion.bash: prevent 'git help' from searching for git repository
From: Junio C Hamano @ 2009-10-28 6:11 UTC (permalink / raw)
To: Gerrit Pape; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <20091027133040.28836.qmail@fe20635a713ff7.315fe32.mid.smarden.org>
Gerrit Pape <pape@smarden.org> writes:
> Hi Junio, I suggest to apply this patch from Johannes to master.
>
> Thanks, Gerrit.
Could you help by coming up with a suitable log message?
It's a bit too much to ask me to hunt for ancient discussion to correct
the <<all the ack go here>> myself to describe what the issue was,
especially when I wasn't heavily involved in the review of the patch
itself. My impression is that the original description of the problem
and the solution in your first message does not apply to what Dscho and
you agreed to be the best solution.
>
> On Fri, Sep 04, 2009 at 11:09:36AM +0000, Gerrit Pape wrote:
>> On Fri, Sep 04, 2009 at 12:22:36PM +0200, Johannes Schindelin wrote:
>> > -- snipsnap --
>> > [PATCH] git help -a: do not look for a repository
>>
>> Perfect, thanks.
>>
>> Acked-by: Gerrit Pape <pape@smarden.org>
>>
>> > Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
>> >
>> > ---
>> >
>> > builtin-help.c | 6 +++---
>> > 1 files changed, 3 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/builtin-help.c b/builtin-help.c
>> > index e1eba77..719aa23 100644
>> > --- a/builtin-help.c
>> > +++ b/builtin-help.c
>> > @@ -416,9 +416,6 @@ int cmd_help(int argc, const char **argv, const char *prefix)
>> > const char *alias;
>> > load_command_list("git-", &main_cmds, &other_cmds);
>> >
>> > - setup_git_directory_gently(&nongit);
>> > - git_config(git_help_config, NULL);
>> > -
>> > argc = parse_options(argc, argv, prefix, builtin_help_options,
>> > builtin_help_usage, 0);
>> >
>> > @@ -429,6 +426,9 @@ int cmd_help(int argc, const char **argv, const char *prefix)
>> > return 0;
>> > }
>> >
>> > + setup_git_directory_gently(&nongit);
>> > + git_config(git_help_config, NULL);
>> > +
>> > if (!argv[0]) {
>> > printf("usage: %s\n\n", git_usage_string);
>> > list_common_cmds_help();
>> > --
>> > To unsubscribe from this list: send the line "unsubscribe git" in
>> > the body of a message to majordomo@vger.kernel.org
>> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>> --
>> To unsubscribe from this list: send the line "unsubscribe git" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
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