* Re: Re: submodules' shortcomings, was Re: RFC: display dirty submodule working directory in git gui and gitk
From: Heiko Voigt @ 2010-01-05 14:27 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Jens Lehmann, Git Mailing List, Junio C Hamano, Shawn O. Pearce,
Paul Mackerras, Lars Hjemli, Avery Pennarun
In-Reply-To: <alpine.DEB.1.00.1001051032440.4985@pacific.mpi-cbg.de>
On Tue, Jan 05, 2010 at 10:46:11AM +0100, Johannes Schindelin wrote:
> On Tue, 5 Jan 2010, Jens Lehmann wrote:
> > Yes. This synchronization could be either obsoleted by only using
> > .gitmodules or automated.
>
> I start to wonder whether the insistence that .gitmodules' settings must
> be overrideable makes any sense in practice.
I just read this and felt the need to comment.
Yes, it definitely makes sense in practise to have it overrideable
otherwise we loose the distributed nature of git for submodules.
Imagine you fork a project and you want to work with others on a change
that involves chaning a subproject. If you can not override .gitmodules
you can only work on the central repository.
I am actually working like this in practise. I have a private clone of
all the subprojects msysgit has and commit/push locally first. Once I
sense the change is going to be useful for a wider audience I send it
upstream. This would be more uncomfortable if it is not overideable.
But I know what you mean by the general confusion about manual updates.
So how about an approach like this:
* clone will initialise all submodules in .git/config from .gitmodules
* if a change in .gitmodules happens git scans .git/config for that
entry and in case nothing is there it syncronises the new one and
notifies the user.
* if a change in .gitmodules happens and the entry before was the same
in .git/config we also automatically update that entry there.
* In every other case we just leave .git/config alone.
Did I miss anything? I think you should get the idea and that it could
get rid of the confusion caused by manual .gitmodule updates.
cheers Heiko
P.S.: Additionally (for my use case) we could add a "hint mechanism"
which allows git to "guess" a new submodules address. For example in
case I have all my local clones on "git@my.server.net:<modulename>.git".
Now when a new submodule gets seen in .gitmodules it will infer the
address from the hint configuration and not take the original one from
upstream.
^ permalink raw reply
* Re: How to exclude files from "git diff"
From: H.J. Lu @ 2010-01-05 14:20 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20100105064509.GC19025@coredump.intra.peff.net>
On Mon, Jan 4, 2010 at 10:45 PM, Jeff King <peff@peff.net> wrote:
> On Fri, Dec 18, 2009 at 09:09:15AM -0800, H.J. Lu wrote:
>
>> I have some bookkeeping files in my git repository. How do I
>> exclude them from "git diff"? Does "git diff" support
>>
>> # git diff --exclude="foo.*.bar*"
>
> No, I don't believe there is a way to do that. You would have to do
> something like:
>
> git diff $(git ls-files | grep -v whatever)
>
> The usual concept of "exclusion" for git is not to track files at all
> via the .gitignore mechanism. Are these files that have content you
> really _want_ in the repository, but you just don't want to see them
> when doing some diffs? Or are they files that could not be in the
> repository at all?
Yes, I want those files in repository. They are for my personal use only.
Thanks.
--
H.J.
^ permalink raw reply
* [PATCH RFC] gitk: display submodule diffs with appropriate encoding
From: Kirill Smelkov @ 2010-01-05 12:44 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Kirill Smelkov, git
Previsously, when submodule commits headings contained non-latin-1
characters, they were displayed incorrectly in gitk, because $line was
not properly decoded, i.e.
----------------------------- Documentation/Dokko -----------------------------
Submodule Documentation/Dokko 2ca20c7..0ea204d:
> ßрþтþúþûы ÑÂþÿрÑÂöõýøѠØÃχ "ÃœþÑÂтøú-21631" (ÛØ2 ø áðýôðû)
> hardware: ôþúуüõýтðцøѠýð InnoDisk SATA 10000
> hardware: ôþúуüõýтðцøѠýð IEI PCISA-6770E2 v3.0
> hardware: ôþúуüõýтðцøѠýð Fastwel NIB941
> hardware: ôþúуüõýтðцøѠýð IEI IPX-9S
> hardware: ôþúуüõýтðцøѠýð Hirschmann 5TX-EEC
instead of
----------------------------- Documentation/Dokko -----------------------------
Submodule Documentation/Dokko 2ca20c7..0ea204d:
> Протоколы ÑопрÑÐ¶ÐµÐ½Ð¸Ñ Ð˜ÐœÐ¡ "МоÑтик-21631" (ЛИ2 и Сандал)
> hardware: Ð´Ð¾ÐºÑƒÐ¼ÐµÐ½Ñ‚Ð°Ñ†Ð¸Ñ Ð½Ð° InnoDisk SATA 10000
> hardware: Ð´Ð¾ÐºÑƒÐ¼ÐµÐ½Ñ‚Ð°Ñ†Ð¸Ñ Ð½Ð° IEI PCISA-6770E2 v3.0
> hardware: Ð´Ð¾ÐºÑƒÐ¼ÐµÐ½Ñ‚Ð°Ñ†Ð¸Ñ Ð½Ð° Fastwel NIB941
> hardware: Ð´Ð¾ÐºÑƒÐ¼ÐµÐ½Ñ‚Ð°Ñ†Ð¸Ñ Ð½Ð° IEI IPX-9S
> hardware: Ð´Ð¾ÐºÑƒÐ¼ÐµÐ½Ñ‚Ð°Ñ†Ð¸Ñ Ð½Ð° Hirschmann 5TX-EEC
This fixes it.
Signed-off-by: Kirill Smelkov <kirr@landau.phys.spbu.ru>
---
gitk | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/gitk b/gitk
index 86dff0f..0edef8f 100755
--- a/gitk
+++ b/gitk
@@ -7689,8 +7689,10 @@ proc getblobdiffline {bdf ids} {
makediffhdr $fname $ids
$ctext insert end "\n$line\n" filesep
} elseif {![string compare -length 3 " >" $line]} {
+ set line [encoding convertfrom $diffencoding $line]
$ctext insert end "$line\n" dresult
} elseif {![string compare -length 3 " <" $line]} {
+ set line [encoding convertfrom $diffencoding $line]
$ctext insert end "$line\n" d0
} elseif {$diffinhdr} {
if {![string compare -length 12 "rename from " $line]} {
--
1.6.6.78.gbd757c.dirty
^ permalink raw reply related
* Re: "git add -i" with path gives "Argument list too long"
From: Wincent Colaiuta @ 2010-01-05 12:34 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20100105041438.GB12574@coredump.intra.peff.net>
El 05/01/2010, a las 05:14, Jeff King escribió:
>> - or, preferably, teach "git diff index" to recurse into directories
>> rather than expect a list of paths-of-blobs (possibly with a command
>> line switch to activate the behaviour if it were deemed a dangerous
>> default)
>
> Doesn't it already do this? If I say "git diff index subdir" it
> will limit the diff only to things inside subdir/.
[snip patch]
I tried out the patch and it obviously does avoid the "Argument list
too long" problem. At least for my usage patterns the superficial
differences in behavior that you note would not be a problem (I
usually want to limit things to a subdir, and seldom if ever pass in
things like '*.c').
> but note that the pathspecs given to ls-files and the path limiters
> given to diff are not quite the same. So "git add -i '*.c'" will
> currently find "subdir/foo.c", but would not with the above patch. Is
> that what you meant when you said "recurse into directories"?
In my relative ignorance of the finer details here, I meant that I
would want "diff-index" to give us the exact same set of blobs as we
get from "ls-files", so as to fix the error without modifying the user
visible behavior.
As I said, I personally wouldn't be impacted by the change in behavior
that your patch produces, but maybe others might.
Cheers,
Wincent
^ permalink raw reply
* git-cherry-pick problem - directory not touched by commit is marked "added by us"
From: Hakim Cassimally @ 2010-01-05 12:33 UTC (permalink / raw)
To: git
I got into a bit of trouble with a git-cherry-pick last night, and
though mugwump
and others on #git helped me as far as a workaround, I'm still very confused,
and would like to make sure it doesn't happen again
I'm fairly sure the problem is due to my ignorance, so I'll firstly describe
the mess I've made of my repo :-)
BACKGROUND
==========
* I had a (trunk) branch that contained most of the code
* I started to experiment with porting our .cgi code to a framework and later,
after the fact, created (experimental) off (trunk)
* As experimental has of course taken longer than expected, I've since forked
(stable) again from (trunk), but from a commit before the experimental stages
started.
* I've developed Feature "X", which took advantage of some of the experimental
refactoring... so of course I developed it in (experimental)...
* I now want to port it back to (stable) so I can release it...
* I was recommended to use 'git rebase -i' but didn't understand how
* ... so I was also recommended to use 'git cherry-pick'. As there were
only 6 relevant commits, I chose to do that
WHAT HAPPENS
============
When I'm in (stable), and try to cherry-pick the change from (experimental),
git thinks that I'm making a massive number of changes in a directory that
wasn't touched by the relevant commit.
Here's a sample transcript which hopefully makes sense: I've included output
of 'git show' and 'git whatchanged' which seem to suggest that the commit
I'm cherry-picking shouldn't be changing these files.
(stable) $ git --version
git version 1.6.6
# I tried previously on 1.6.0.4 but upgraded in case it helped
(stable) $ git status
# On branch stable
# nothing to commit (working directory clean)
(stable) $ git show --stat 301afce1
commit 301afce1c78380276d208077ef4ec76b469c1024
Author: osfameron <...>
Date: Wed Dec 23 23:45:20 2009 +0000
Proof of concept for import module (parse Excel)
bin/upload_module.pl | 142
++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 142 insertions(+), 0 deletions(-)
(stable) $ git whatchanged -1 301afce1
commit 301afce1c78380276d208077ef4ec76b469c1024
Author: osfameron <...>
Date: Wed Dec 23 23:45:20 2009 +0000
Proof of concept for import module (parse Excel)
:000000 100644 0000000... c90e261... A bin/upload_module.pl
(stable) $ git cherry-pick 301afce1
Finished one cherry-pick.
www/client/css/admin-clean.css: needs merge
www/client/css/admin.css: needs merge
www/client/css/error.css: needs merge
www/client/css/public.css: needs merge
www/client/css/user-clean.css: needs merge
<...snip>
www/client/css/admin-clean.css: unmerged
(832c41e99d19f2dd39c9cf3709f14619ffab24b8)
www/client/css/admin.css: unmerged
(8e7cd850bf40d1a921b1f62ce0945abd374fa55d)
www/client/css/error.css: unmerged
(88945d05640c0820c9cf68922392573d4ac07b2c)
<...snip>
...
error: Error building trees
(stable) $ git status
# On branch stable
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: bin/upload_module.pl
#
# Unmerged paths:
# (use "git reset HEAD <file>..." to unstage)
# (use "git add <file>..." to mark resolution)
#
# added by us: www/client/css/admin-clean.css
# added by us: www/client/css/admin.css
# added by us: www/client/css/error.css
# added by us: www/client/css/public.css
<...snip>
As mugwump suggested, I can resolve by doing
(stable) $ git checkout HEAD www/
And then proceed by commiting that cherry-pick. This is how I've fixed it.
(Slightly annoying to repeat/lather/rinse for 6 separate commits, but works).
Oddly, though I've done some messing about in the www/ tree, these files exist
in both, for example "www/client/css/admin.css" exists in both (experimental)
and in (stable).
Please let me know if I should be submitting different or more detailed
information to describe the problem better!
Any help in working out what I'm doing wrong would be really appreciated,
osfameron
^ permalink raw reply
* Re: submodules' shortcomings, was Re: RFC: display dirty submodule working directory in git gui and gitk
From: Jens Lehmann @ 2010-01-05 12:19 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Git Mailing List, Junio C Hamano, Shawn O. Pearce, Paul Mackerras,
Heiko Voigt, Lars Hjemli, Avery Pennarun
In-Reply-To: <alpine.DEB.1.00.1001051032440.4985@pacific.mpi-cbg.de>
Am 05.01.2010 10:46, schrieb Johannes Schindelin:
> But I have a use case here where the shared content is _not_ a library
> that can live in a subdirectory naturally.
Yes, we had to reorganize a major part of one project too. Heiko could
tell more about that.
>> Having read up about svn externals in the meantime, what about something
>> like this:
>> - Add a command like "git submodule forward" (as update is already in
>> use) that takes an optional -b <branchname>. It does a fetch in the
>> submodule, then tries to fast forward (or rebase) to master or the
>> branch given and stages this commit in the superproject. This should
>> be the equivalent to doing an "svn update" in a repo with externals.
>> Or am i missing something?
>
> Yes. It is not the decision of the fetcher, but of the guy who adds the
> submodule to decide what it is.
>
>> - We could also add an option to "git submodule add" to specify the
>> default branch name for forward.
>
> That's an obvious precondition for proper always-tip-submodules. But
> Git's core data structure, the index, does not allow for it. _That_ is
> the difficulty, not what the user interface would look like.
I have never experienced (and never had the need for) such an always-tip
scenario and therefore still seem to have difficulties to grok it. I
assume you always want to have the newest tip at /checkout/ time, not at
/commit/ time? Then my proposal would really not help you.
> I start to wonder whether the insistence that .gitmodules' settings must
> be overrideable makes any sense in practice.
I know of none, maybe someone else can speak up here?
(And even if it is overrideable, do the settings necessarily have to be
copied into .git/config when they aren't even overridden?)
^ permalink raw reply
* Re: submodules' shortcomings, was Re: RFC: display dirty submodule working directory in git gui and gitk
From: Jens Lehmann @ 2010-01-05 11:57 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Git Mailing List, Shawn O. Pearce,
Paul Mackerras, Heiko Voigt, Lars Hjemli, Avery Pennarun
In-Reply-To: <7v1vi428w0.fsf@alter.siamese.dyndns.org>
Am 05.01.2010 10:33, schrieb Junio C Hamano:
> So it is not necessarily a bad thing if the commit checked out in the
> submodule repository is different from what the superproject records in
> its index when a commit is made in the superproject. We allow committing
> with local changes in regular files, while we do notify the users about
> them to avoid mistakes. We should give the same kind of notification
> about submodules, but the "local changes" need to be thought out more
> carefully than plain files in the superproject itself. Does uncommitted
> changes in the index of submodule repository count? Local changes in the
> work tree files? What about untracked files that the user might have
> forgot to add? Should they be warned? What about the commit in the
> submodule repository being a non-descendant of the commit recorded in the
> HEAD of the superproject's tree, resulting in a non-ff change at the
> submodule level?
Committing in the superproject with any dirty state in a submodule
should always work (same as it does with local changes in regular files),
but be visible for the user (again as local changes in regular files are).
Right now we do not show enough information about a submodule to protect
the user from accidentally throwing away changes made inside it.
The only thing we show right now are the differences between submodule
commits and what the superproject has in its index and in its commits.
Missing are:
a) modified files
I think these have to be shown, no matter if they are checked into
the submodules index or not (because until they are committed, they
can't be staged in the superproject anyway).
b) new unignored files
IMO these files should show up too (the superproject doesn't show
ignored files, the submodule state shouldn't do that either). But
OTOH i don't see a possibility for loss of data when this state is
not shown.
c) a detached HEAD not on any local *or* remote branch
This can be fatal when doing a reset, revert or checkout, so it
should be shown. Alternatively when applied on a submodule, forcing
could be disabled to let the command fail instead of throwing stuff
away.
d) a detached HEAD not on any remote branch
AFAICS this is only important for a push, and could just error out
there.
(But i don't think it is necessary to show detailed information, just
what type of states are found in the submodule)
Concerning Dscho's remarks about the performace impact: We could control
this behavior via .gitmodules too (and later have different settings
for the submodules depending on the group the user chose). So you could
turn these checks off for repos where you don't care, saving the time to
go through the whole working directory of the submodule. But i would vote
for the default to show at least case a) and maybe even c) to follow the
principle of least surprise.
> I think "clone" has a chicken-and-egg problem. If all of your project
> participant are expected to check out all the submodules, are expected to
> make commits in all of them, and essentially have to track everything in
> sync, then "clone" can obviously do that without asking what kind of
> participant you are [*1*]. Otherwise, you need to have some mechanism
> (e.g. "group mapping" you mentioned earlier) for the user to specify "I am
> interested in these submodules" before the actual sub-clones to happen,
> but until you clone the superproject that has some description for that
> mechanism to use, and the user to see what's available, you cannot say
> what kind of participant you are. It has to become two-step process;
> either "clone" going interactive in the middle, or you let the clone to
> happen and then "submodule init" to express that information.
Yes, we can leave it that way for now (first "clone" and then "submodule
init <the submodules you need>"). We can migrate to the "group mapping"
functionality later (which would then allow to force certain submodules
to always be populated because they appear in every group).
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2010, #01; Mon, 04)
From: Ilari Liusvaara @ 2010-01-05 11:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vskal5c11.fsf@alter.siamese.dyndns.org>
On Mon, Jan 04, 2010 at 09:57:46PM -0800, Junio C Hamano wrote:
>
> * il/vcs-helper (2009-12-09) 8 commits
> According to http://thread.gmane.org/gmane.comp.version-control.git/134980
> this is very close to completion (or did I overlook a reroll after that?)
> but the final touch is not there yet.
AFAICT, the only nits about that series in that thread were:
- SoB ping-pong
- Not using warning()
And AFAICT both have been fixed in current pu. Or did I overlook some nit?
-Ilari
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2010, #01; Mon, 04)
From: Johan Herland @ 2010-01-05 11:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vskal5c11.fsf@alter.siamese.dyndns.org>
On Tuesday 05 January 2010, Junio C Hamano wrote:
> I am tempted to merge the following to 'next' soonish; please
> complain and stop me before I do so in a few days if there are
> issues.
>
> * jh/notes (2009-12-07) 11 commits
> I didn't see any negative comments after this round; is everybody
> happy with this? If so let's move it to 'next'. If not, please
> complain.
Please hold until I send a new iteration of the series (which will be
based on what is currently in 'next'). The new iteration should be
ready in a few days.
Have fun! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: submodules' shortcomings, was Re: RFC: display dirty submodule working directory in git gui and gitk
From: Johannes Schindelin @ 2010-01-05 10:07 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jens Lehmann, Git Mailing List, Shawn O. Pearce, Paul Mackerras,
Heiko Voigt, Lars Hjemli, Avery Pennarun
In-Reply-To: <7v1vi428w0.fsf@alter.siamese.dyndns.org>
Hi,
On Tue, 5 Jan 2010, Junio C Hamano wrote:
> Jens Lehmann <Jens.Lehmann@web.de> writes:
>
> > Am 04.01.2010 23:29, schrieb Johannes Schindelin:
> > ...
> >> - among other use cases, submodules are recommended for sharing
> >> content between two different repositories. But it is part of the
> >> design that it is _very_ easy to forget to commit, or push the
> >> changes in the submodule that are required for the integrity of the
> >> superproject.
> >
> > Definitely (and if i got that right, svn externals have the same
> > problem).
> >
> > What about checking for every submodule before a push in the
> > superproject that its HEAD is on a remote branch? I don't think we can
> > provide full safety here, but we could handle the 99% case of a
> > forgotten push in the submodule. This could even be done with a rather
> > simple hook (if we had a pre-push hook that is :-).
>
> You don't need "pre-push" hook, if the eventual goal is to integrate this
> into "git push" proper; it can notice submodule directories, descending
> into them, check if the remote lacks the necessary commit and invoke "git
> push" via run_command() interface as needed.
That is obvious, _iff_ we make the necessary changes in core Git. Jens'
point was that you can do it with hooks, too.
> >> - related are the use cases where it is desired not to have a fixed
> >> submodule tip committed to the superproject, but always to update
> >> to the current, say, master (like Subversion's externals). This
> >> use case has been wished away by the people who implemented
> >> submodules in Git. But reality has this nasty habit of ignoring
> >> your wishes, does it not?
> >
> > Having read up about svn externals in the meantime, what about
> > something like this:
> > - Add a command like "git submodule forward" (as update is already in
> > use) that takes an optional -b <branchname>. It does a fetch in the
> > submodule, then tries to fast forward (or rebase) to master or the
> > branch given and stages this commit in the superproject. This should
> > be the equivalent to doing an "svn update" in a repo with externals.
> > Or am i missing something? (And we could avoid the detached HEAD in
> > the fast forward case by really checking out the branch in the
> > submodule)
> > - We could also add an option to "git submodule add" to specify the
> > default branch name for forward.
>
> Instead of recording a specific submodule commit in the superproject, we
> could record a branch name (this would need a separate "gitlink" type of
> object we toyed around during the early days of submodule design) to say
> "the tip of the branch".
Yes, and it would be as limited (but in a different way) as the current
gitlink.
You might argue that "gitlink" in its current form has not raised too many
complaints. But that is only because next to nobody uses submodules
unless forced to.
> But there is a difference between a distributed system and a centralized
> one like Subversion. When you say "tip of the branch", you have to say
> "which repository". If your position is that _any_ repository will do
> as long as the commit is at the tip of the named branch, that is like
> saying you don't care what commit it really is, as you are free to muck
> with branch heads in your copy of submodule repository, by adding
> commits, or resetting new ones away. For that matter, your 'master'
> branch in the submodule repository may not build-on/fork-from the
> 'master' branch in the upstream of it, so even "tip of the branch by
> _this name_" is still fuzzy.
>
> I am not saying "any commit will do" is necessarily a bad position to
> take. But people who claim they want to say "this branch" need to
> realize what they are really saying: whatever you record in the
> superproject commit is immaterial. In other words, "this superproject
> will work no matter which version of submodule is checked out at its
> location".
>
> Thatv actually is a very valid thing to say in some situations (Dscho
> mentioned different versions of artwork checked out as a submodule in a
> developer's superproject to build an app). Interestingly enough, some
> people seem to think that we place too much importance on not having to
> check out submodules, but it indeed is a very natural extention of "any
> commit will do". If the configuration you chose for your build does not
> depend on any files from there, it will truly be "any commit will do",
> including "nothing checked out there is just fine".
Come on Junio, do not insult my intelligence.
You know all too well about scenarios where a superproject tracks a
3rd-party project which the superproject's developers do not contribute
to.
"nothing checked out there is just fine". Pfff. That's ridiculous.
You'll have to try much harder than that.
Ciao,
Johannes
^ permalink raw reply
* Re: [PATCH v3 2/6] t5541-http-push.sh: add test for unmatched, non-fast-forwarded refs
From: Tay Ray Chuan @ 2010-01-05 10:01 UTC (permalink / raw)
To: Jeff King; +Cc: git, Shawn O. Pearce, Daniel Barkalow, Junio C Hamano
In-Reply-To: <20100105063546.GB19368@coredump.intra.peff.net>
Hi,
On Tue, Jan 5, 2010 at 2:35 PM, Jeff King <peff@peff.net> wrote:
> On Thu, Dec 24, 2009 at 03:41:58PM +0800, Tay Ray Chuan wrote:
>
>> Test that when non-fast-forwarded refs cannot be matched without an
>> explicit refspect, the push fails with a non-fast-forward ref status and
>> help message.
>
> I don't understand what you're testing here. If it's not matched, then
> how is it a non-fast-forward? Isn't it simply unmatched?
Let me rephrase this as:
Some refs can only be matched to a remote ref with an explicit
refspec. When such a ref is a non-fast-forward of its remote ref,
test that pushing them (with the explicit refspec specified) fails
with a non-fast-foward-type error.
> Your test:
>
>> +test_expect_failure 'push fails for non-fast-forward refs unmatched by remote helper' '
>> + # create a dissimilarly-named ref so that git is unable to match the refs
>> + git push origin master:retsam
>> +
>> + echo "change changed" > path2 &&
>> + git commit -a -m path2 --amend &&
>> +
>> + # push master too. This ensures there is at least one '"'push'"' command to
>> + # the remote helper and triggers interaction with the helper.
>> + !(git push -v origin +master master:retsam >output 2>&1) &&
>> +
>> + grep "^ + [a-z0-9]\+\.\.\.[a-z0-9]\+[ ]*master -> master (forced update)$" output &&
>> + grep "^ ! \[rejected\][ ]*master -> retsam (non-fast-forward)$" output &&
>
> Looks like you're just testing the usual "master -> retsam is not a
> fast-forward" case. I don't understand how this is different from the
> previous tests. Can you elaborate?
The problem in question is that a non-fast-forward error is not being
reported, and this test sets up a situation to trigger this - it's not
meant to be just another non-fast-forward test.
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: [PATCH v3 5/6] transport-helper.c::push_refs(): ignore helper-reported status if ref is not to be pushed
From: Tay Ray Chuan @ 2010-01-05 10:01 UTC (permalink / raw)
To: Jeff King; +Cc: git, Shawn O. Pearce, Daniel Barkalow, Junio C Hamano
In-Reply-To: <20100105063253.GA19368@coredump.intra.peff.net>
Hi,
On Tue, Jan 5, 2010 at 2:32 PM, Jeff King <peff@peff.net> wrote:
> On Thu, Dec 24, 2009 at 03:44:45PM +0800, Tay Ray Chuan wrote:
>
>> - ref->status = status;
>> - ref->remote_status = msg;
>> + switch (ref->status) {
>> + case REF_STATUS_REJECT_NONFASTFORWARD:
>> + case REF_STATUS_UPTODATE:
>> + /*
>> + * Earlier, the ref was marked not to be pushed, so ignore what
>> + * the remote helper said about the ref.
>> + */
>> + continue;
>> + default:
>> + ref->status = status;
>> + ref->remote_status = msg;
>> + }
>
> It seems like this should be checking for REF_STATUS_NONE explicitly
> instead of trying to enumerate the reasons we might not have tried to
> push. Shouldn't helpers _only_ be pushing REF_STATUS_NONE refs?
>
> I think right now the two cases are equivalent, since non-ff and
> uptodate are the only two states set before the helper is invoked. But
> we have discussed in the past (and I still have a patch floating around
> for) a REF_STATUS_REWIND which would treat strict rewinds differently
> (silently ignoring them instead of making an error). Explicitly checking
> REF_STATUS_NONE future-proofs against new states being added.
I'm not really sure if this is true (ie. that if status is not non-ff
or uptodate, then it is REF_STATUS_NONE), but we could step around this
by introducing a property, say, ref->should_push, that is set to 1,
after all the vetting has been carried out and just before we talk to
the server.
That way, we just check that property, without having to know the ref
statuses that would mark a ref not-for-pushing. Sounds future-proof (in
your sense) to me.
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: submodules' shortcomings, was Re: RFC: display dirty submodule working directory in git gui and gitk
From: Johannes Schindelin @ 2010-01-05 9:46 UTC (permalink / raw)
To: Jens Lehmann
Cc: Git Mailing List, Junio C Hamano, Shawn O. Pearce, Paul Mackerras,
Heiko Voigt, Lars Hjemli, Avery Pennarun
In-Reply-To: <4B42F425.4010901@web.de>
Hi,
On Tue, 5 Jan 2010, Jens Lehmann wrote:
> Am 04.01.2010 23:29, schrieb Johannes Schindelin:
>
> > - submodules were designed with a strong emphasis on not being forced
> > to check them out. But Git makes it very unconvenient to actually
> > check submodules out, let alone check them out at clone-time. And
> > it is outright impossible to _enforce_ a submodule to be checked
> > out.
>
> Absolutely. But i think the group mappings discussed by Junio and Heiko
> are a good starting point to solve that problem:
> http://thread.gmane.org/gmane.comp.version-control.git/130928/
>
> This should be solvable by putting the necessary information into
> .gitmodules and have git clone use it.
And of course, existing Git versions will not handle it correctly.
Judging from the rebasing-submodule patch, the next Git version will not
handle it either.
But you're correct, one has to start _somewhere_.
> > - among other use cases, submodules are recommended for sharing
> > content between two different repositories. But it is part of the
> > design that it is _very_ easy to forget to commit, or push the
> > changes in the submodule that are required for the integrity of the
> > superproject.
>
> Definitely (and if i got that right, svn externals have the same problem).
Yes, svn externals have that problem. But we do not need to take the svn
externals example more seriously than it deserves: it illustrates a valid
use case that is not handled by submodules. But svn externals are not
what I would call "elegant design" either.
> What about checking for every submodule before a push in the
> superproject that its HEAD is on a remote branch? I don't think we can
> provide full safety here, but we could handle the 99% case of a
> forgotten push in the submodule. This could even be done with a rather
> simple hook (if we had a pre-push hook that is :-).
The problem with hooks is that for security reasons, every user has to
install them in every repository herself (unless she is working on a
machine serviced by an overzealous administrator).
> > - that use case -- sharing content between different repositories --
> > is not really supported by submodules, but rather an afterthought.
> > This is all too obvious when you look at the restriction that the
> > shared content must be in a single subdirectory.
>
> I don't see that as a problem (and it's the same with svn externals, no?).
>
> And having worked for a long time with a RCS variant which allowed
> "projects" to contain an arbitrary list of files, i don't think this is
> a problem (but forgetting to add new files to this list really is, so
> putting everything in one directory is *much* safer IMHO).
> And: almost all files were properly grouped in directories after a decade
> of development even though that was not enforced by the scm at all.
That happens to be the case here, I agree.
But I have a use case here where the shared content is _not_ a library
that can live in a subdirectory naturally.
> > - related are the use cases where it is desired not to have a fixed
> > submodule tip committed to the superproject, but always to update to
> > the current, say, master (like Subversion's externals). This use
> > case has been wished away by the people who implemented submodules
> > in Git. But reality has this nasty habit of ignoring your wishes,
> > does it not?
>
> Having read up about svn externals in the meantime, what about something
> like this:
> - Add a command like "git submodule forward" (as update is already in
> use) that takes an optional -b <branchname>. It does a fetch in the
> submodule, then tries to fast forward (or rebase) to master or the
> branch given and stages this commit in the superproject. This should
> be the equivalent to doing an "svn update" in a repo with externals.
> Or am i missing something?
Yes. It is not the decision of the fetcher, but of the guy who adds the
submodule to decide what it is.
> - We could also add an option to "git submodule add" to specify the
> default branch name for forward.
That's an obvious precondition for proper always-tip-submodules. But
Git's core data structure, the index, does not allow for it. _That_ is
the difficulty, not what the user interface would look like.
> > - while it might be called clever that the submodules' metadata are
> > stored in .gitmodules in the superproject (and are therefore
> > naturally tracked with Git), the synchronization with .git/config is
> > performed exactly once -- when you initialize the submodule. You
> > are likely to miss out on _every_ change you pulled into the
> > superproject.
>
> Yes. This synchronization could be either obsoleted by only using
> .gitmodules or automated.
I start to wonder whether the insistence that .gitmodules' settings must
be overrideable makes any sense in practice.
> > Besides, as long as there is enough reason to have out-of-Git
> > alternative solutions such as repo, submodules deserve to be 2nd-class
> > citizens.
>
> I think in the long run to make submodules first class citizens the
> following submodule commands must be obsoleted by their regular git
> parts: init (by git clone), status (by git status), update (by git
> checkout), summary (already in git diff thanks to your patch) and sync
> (maybe Avery's idea of only relying on .gitmodules and not copying data
> int .git/config would solve this).
Avery's idea was to make .gitmodules overrideable in .git/config, which
would share almost all the shortcomings I listed for the current solution.
> That would leave git submodule add, foreach and maybe a command to do
> what svn update does for externals and another to manipulate things like
> group membership etc..
>
> Which reminds me of Sverre's quote from Alles Wird Git: "Yes, it is
> possible. But it will be hard."
Yeah, it will be hard. Especially since the fact that submodule is a
bloated shell script has outlived its usefulness by far. (It would be
different if it was a nice, small, elegant script, but you have looked at
it, so you know why I am disgusted.)
Ciao,
Dscho
^ permalink raw reply
* Re: submodules' shortcomings, was Re: RFC: display dirty submodule working directory in git gui and gitk
From: Junio C Hamano @ 2010-01-05 9:33 UTC (permalink / raw)
To: Jens Lehmann
Cc: Johannes Schindelin, Git Mailing List, Shawn O. Pearce,
Paul Mackerras, Heiko Voigt, Lars Hjemli, Avery Pennarun
In-Reply-To: <4B42F425.4010901@web.de>
Jens Lehmann <Jens.Lehmann@web.de> writes:
> Am 04.01.2010 23:29, schrieb Johannes Schindelin:
> ...
>> - submodules were designed with a strong emphasis on not being forced to
>> check them out. But Git makes it very unconvenient to actually check
>> submodules out, let alone check them out at clone-time. And it is
>> outright impossible to _enforce_ a submodule to be checked out.
>
> Absolutely. But i think the group mappings discussed by Junio and Heiko
> are a good starting point to solve that problem:
> http://thread.gmane.org/gmane.comp.version-control.git/130928/
>
> This should be solvable by putting the necessary information into
> .gitmodules and have git clone use it.
I sense there is a chicken and egg problem, but I'll let it pass for now.
>> - among other use cases, submodules are recommended for sharing content
>> between two different repositories. But it is part of the design that it
>> is _very_ easy to forget to commit, or push the changes in the submodule
>> that are required for the integrity of the superproject.
>
> Definitely (and if i got that right, svn externals have the same problem).
>
> What about checking for every submodule before a push in the superproject
> that its HEAD is on a remote branch? I don't think we can provide full
> safety here, but we could handle the 99% case of a forgotten push in the
> submodule. This could even be done with a rather simple hook (if we had a
> pre-push hook that is :-).
You don't need "pre-push" hook, if the eventual goal is to integrate this
into "git push" proper; it can notice submodule directories, descending
into them, check if the remote lacks the necessary commit and invoke "git
push" via run_command() interface as needed.
>> - related are the use cases where it is desired not to have a fixed
>> submodule tip committed to the superproject, but always to update to the
>> current, say, master (like Subversion's externals). This use case has
>> been wished away by the people who implemented submodules in Git. But
>> reality has this nasty habit of ignoring your wishes, does it not?
>
> Having read up about svn externals in the meantime, what about something
> like this:
> - Add a command like "git submodule forward" (as update is already in
> use) that takes an optional -b <branchname>. It does a fetch in the
> submodule, then tries to fast forward (or rebase) to master or the
> branch given and stages this commit in the superproject. This should
> be the equivalent to doing an "svn update" in a repo with externals.
> Or am i missing something?
> (And we could avoid the detached HEAD in the fast forward case by
> really checking out the branch in the submodule)
> - We could also add an option to "git submodule add" to specify the
> default branch name for forward.
Instead of recording a specific submodule commit in the superproject, we
could record a branch name (this would need a separate "gitlink" type of
object we toyed around during the early days of submodule design) to say
"the tip of the branch".
But there is a difference between a distributed system and a centralized
one like Subversion. When you say "tip of the branch", you have to say
"which repository". If your position is that _any_ repository will do as
long as the commit is at the tip of the named branch, that is like saying
you don't care what commit it really is, as you are free to muck with
branch heads in your copy of submodule repository, by adding commits, or
resetting new ones away. For that matter, your 'master' branch in the
submodule repository may not build-on/fork-from the 'master' branch in the
upstream of it, so even "tip of the branch by _this name_" is still fuzzy.
I am not saying "any commit will do" is necessarily a bad position to
take. But people who claim they want to say "this branch" need to realize
what they are really saying: whatever you record in the superproject
commit is immaterial. In other words, "this superproject will work no
matter which version of submodule is checked out at its location".
Thatv actually is a very valid thing to say in some situations (Dscho
mentioned different versions of artwork checked out as a submodule in a
developer's superproject to build an app). Interestingly enough, some
people seem to think that we place too much importance on not having to
check out submodules, but it indeed is a very natural extention of "any
commit will do". If the configuration you chose for your build does not
depend on any files from there, it will truly be "any commit will do",
including "nothing checked out there is just fine".
So it is not necessarily a bad thing if the commit checked out in the
submodule repository is different from what the superproject records in
its index when a commit is made in the superproject. We allow committing
with local changes in regular files, while we do notify the users about
them to avoid mistakes. We should give the same kind of notification
about submodules, but the "local changes" need to be thought out more
carefully than plain files in the superproject itself. Does uncommitted
changes in the index of submodule repository count? Local changes in the
work tree files? What about untracked files that the user might have
forgot to add? Should they be warned? What about the commit in the
submodule repository being a non-descendant of the commit recorded in the
HEAD of the superproject's tree, resulting in a non-ff change at the
submodule level?
What this also means is that it is important to
(1) be able to simply be a user of the submodule (in such a scenario, the
developer who uses artwork from designer's repository does _not_ want
to commit the submodule, but he does want to have a recent checkout
of it, and he might even make some tweaks); and
(2) being able to commit the state of the superproject, even if there is
a mismatch between the submodule commit recorded in the superproject
and the actual version that is checked into the authoritative
submodule project by the designer (perhaps he hasn't pulled in the
submodule while traveling).
In other words, even if the default is made to "always clone and checkout
all the submodules, and before allowing anything be done in the higher
levels of superprojects, submodules must be made in sync with their
latest", there has to be a way to override such a rigid constraints for
the resulting system to be usable.
> I think in the long run to make submodules first class citizens the
> following submodule commands must be obsoleted by their regular git
> parts: init (by git clone), status (by git status), update (by git
> checkout), summary (already in git diff thanks to your patch) and sync
> (maybe Avery's idea of only relying on .gitmodules and not copying data
> int .git/config would solve this).
I think "clone" has a chicken-and-egg problem. If all of your project
participant are expected to check out all the submodules, are expected to
make commits in all of them, and essentially have to track everything in
sync, then "clone" can obviously do that without asking what kind of
participant you are [*1*]. Otherwise, you need to have some mechanism
(e.g. "group mapping" you mentioned earlier) for the user to specify "I am
interested in these submodules" before the actual sub-clones to happen,
but until you clone the superproject that has some description for that
mechanism to use, and the user to see what's available, you cannot say
what kind of participant you are. It has to become two-step process;
either "clone" going interactive in the middle, or you let the clone to
happen and then "submodule init" to express that information.
[Footnote]
*1* of course, in such a scenario you have to question what you are using
submodules for.
^ permalink raw reply
* Re: [PATCH v4] Smart-http documentation: add example of how to execute from userdir
From: Junio C Hamano @ 2010-01-05 8:23 UTC (permalink / raw)
To: Tarmigan Casebolt; +Cc: git, Tay Ray Chuan, Shawn O. Pearce
In-Reply-To: <1262678381-86653-1-git-send-email-tarmigan+git@gmail.com>
Tarmigan Casebolt <tarmigan+git@gmail.com> writes:
> +Depending on the global configuration of the web server, the
> +"FollowSymLinks" or "SymLinksIfOwnerMatch" options might be needed.
> +If the web server does not follow any symbolic links, the
> +'git-http-backend' executable may be copied into the cgi-bin directory
> +and renamed to 'git' to acheive the same effect, but it will also need
> +to be manually updated whenever a new version of 'git-http-backend' is
> +installed.
Hmph, has Apache heard of hardlinks? If not, wouldn't this be much
simpler?
cat >git <<\EOF
#!/bin/sh
exec /path/to/libexec/git-core/git-http-backend "$@"
EOF
chmod +x git
^ permalink raw reply
* [PATCH] Teach --[no-]rerere-autoupdate option to merge, revert and friends
From: Junio C Hamano @ 2010-01-05 8:16 UTC (permalink / raw)
To: git
In-Reply-To: <7vskal5c11.fsf@alter.siamese.dyndns.org>
Introduce a command line option to override rerere.autoupdate configuration
variable to make it more useful.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
I've had this in my private tree for quite a while and just noticed that
I haven't sent it out. A convenince configuration option to allow a
potentially dangerous mode of operation must always come with an explicit
way to disable it when necessary.
Documentation/git-merge.txt | 7 ++++++-
builtin-commit.c | 2 +-
builtin-merge.c | 4 +++-
builtin-rerere.c | 23 ++++++++++++++++-------
builtin-revert.c | 4 +++-
git-am.sh | 6 +++++-
git-rebase.sh | 6 +++++-
parse-options.c | 7 +++++++
parse-options.h | 3 +++
rerere.c | 8 +++++---
rerere.h | 10 ++++++++--
t/t4200-rerere.sh | 15 +++++++++++++++
12 files changed, 77 insertions(+), 18 deletions(-)
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index e886c2e..6747031 100644
--- a/Documentation/git-merge.txt
+++ b/Documentation/git-merge.txt
@@ -10,7 +10,7 @@ SYNOPSIS
--------
[verse]
'git merge' [-n] [--stat] [--no-commit] [--squash] [-s <strategy>]...
- [-m <msg>] <remote>...
+ [--[no-]rerere-autoupdate] [-m <msg>] <remote>...
'git merge' <msg> HEAD <remote>...
DESCRIPTION
@@ -33,6 +33,11 @@ include::merge-options.txt[]
used to give a good default for automated 'git merge'
invocations.
+--rerere-autoupdate::
+--no-rerere-autoupdate::
+ Allow the rerere mechanism to update the index with the
+ result of auto-conflict resolution if possible.
+
<remote>...::
Other branch heads to merge into our branch. You need at
least one <remote>. Specifying more than one <remote>
diff --git a/builtin-commit.c b/builtin-commit.c
index e93a647..72e0f0b 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -1150,7 +1150,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
"new_index file. Check that disk is not full or quota is\n"
"not exceeded, and then \"git reset HEAD\" to recover.");
- rerere();
+ rerere(0);
run_hook(get_index_file(), "post-commit", NULL);
if (!quiet)
print_summary(prefix, commit_sha1);
diff --git a/builtin-merge.c b/builtin-merge.c
index 56a1bb6..c3faa6b 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -52,6 +52,7 @@ static struct strategy **use_strategies;
static size_t use_strategies_nr, use_strategies_alloc;
static const char *branch;
static int verbosity;
+static int allow_rerere_auto;
static struct strategy all_strategy[] = {
{ "recursive", DEFAULT_TWOHEAD | NO_TRIVIAL },
@@ -170,6 +171,7 @@ static struct option builtin_merge_options[] = {
"allow fast-forward (default)"),
OPT_BOOLEAN(0, "ff-only", &fast_forward_only,
"abort if fast-forward is not possible"),
+ OPT_RERERE_AUTOUPDATE(&allow_rerere_auto),
OPT_CALLBACK('s', "strategy", &use_strategies, "strategy",
"merge strategy to use", option_parse_strategy),
OPT_CALLBACK('m', "message", &merge_msg, "message",
@@ -790,7 +792,7 @@ static int suggest_conflicts(void)
}
}
fclose(fp);
- rerere();
+ rerere(allow_rerere_auto);
printf("Automatic merge failed; "
"fix conflicts and then commit the result.\n");
return 1;
diff --git a/builtin-rerere.c b/builtin-rerere.c
index 343d6cd..7ec602c 100644
--- a/builtin-rerere.c
+++ b/builtin-rerere.c
@@ -101,15 +101,24 @@ static int diff_two(const char *file1, const char *label1,
int cmd_rerere(int argc, const char **argv, const char *prefix)
{
struct string_list merge_rr = { NULL, 0, 0, 1 };
- int i, fd;
-
+ int i, fd, flags = 0;
+
+ if (2 < argc) {
+ if (!strcmp(argv[1], "-h"))
+ usage(git_rerere_usage);
+ if (!strcmp(argv[1], "--rerere-autoupdate"))
+ flags = RERERE_AUTOUPDATE;
+ else if (!strcmp(argv[1], "--no-rerere-autoupdate"))
+ flags = RERERE_NOAUTOUPDATE;
+ if (flags) {
+ argc--;
+ argv++;
+ }
+ }
if (argc < 2)
- return rerere();
-
- if (!strcmp(argv[1], "-h"))
- usage(git_rerere_usage);
+ return rerere(flags);
- fd = setup_rerere(&merge_rr);
+ fd = setup_rerere(&merge_rr, flags);
if (fd < 0)
return 0;
diff --git a/builtin-revert.c b/builtin-revert.c
index 151aa6a..857ca2e 100644
--- a/builtin-revert.c
+++ b/builtin-revert.c
@@ -38,6 +38,7 @@ static const char * const cherry_pick_usage[] = {
static int edit, no_replay, no_commit, mainline, signoff;
static enum { REVERT, CHERRY_PICK } action;
static struct commit *commit;
+static int allow_rerere_auto;
static const char *me;
@@ -57,6 +58,7 @@ static void parse_args(int argc, const char **argv)
OPT_BOOLEAN('r', NULL, &noop, "no-op (backward compatibility)"),
OPT_BOOLEAN('s', "signoff", &signoff, "add Signed-off-by:"),
OPT_INTEGER('m', "mainline", &mainline, "parent number"),
+ OPT_RERERE_AUTOUPDATE(&allow_rerere_auto),
OPT_END(),
};
@@ -395,7 +397,7 @@ static int revert_or_cherry_pick(int argc, const char **argv)
die ("Error wrapping up %s", defmsg);
fprintf(stderr, "Automatic %s failed.%s\n",
me, help_msg(commit->object.sha1));
- rerere();
+ rerere(allow_rerere_auto);
exit(1);
}
if (commit_lock_file(&msg_file) < 0)
diff --git a/git-am.sh b/git-am.sh
index 4838cdb..2f46fda 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -30,6 +30,7 @@ skip skip the current patch
abort restore the original branch and abort the patching operation.
committer-date-is-author-date lie about committer date
ignore-date use current timestamp for author date
+rerere-autoupdate update the index with reused conflict resolution if possible
rebasing* (internal use for git-rebase)"
. git-sh-setup
@@ -135,7 +136,7 @@ It does not apply to blobs recorded in its index."
export GIT_MERGE_VERBOSITY=0
fi
git-merge-recursive $orig_tree -- HEAD $his_tree || {
- git rerere
+ git rerere $allow_rerere_autoupdate
echo Failed to merge in the changes.
exit 1
}
@@ -293,6 +294,7 @@ resolvemsg= resume= scissors= no_inbody_headers=
git_apply_opt=
committer_date_is_author_date=
ignore_date=
+allow_rerere_autoupdate=
while test $# != 0
do
@@ -340,6 +342,8 @@ do
committer_date_is_author_date=t ;;
--ignore-date)
ignore_date=t ;;
+ --rerere-autoupdate|--no-rerere-autoupdate)
+ allow_rerere_autoupdate="$1" ;;
-q|--quiet)
GIT_QUIET=t ;;
--)
diff --git a/git-rebase.sh b/git-rebase.sh
index b121f45..398ea73 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -50,6 +50,7 @@ diffstat=$(git config --bool rebase.stat)
git_am_opt=
rebase_root=
force_rebase=
+allow_rerere_autoupdate=
continue_merge () {
test -n "$prev_head" || die "prev_head must be defined"
@@ -118,7 +119,7 @@ call_merge () {
return
;;
1)
- git rerere
+ git rerere $allow_rerere_autoupdate
die "$RESOLVEMSG"
;;
2)
@@ -349,6 +350,9 @@ do
-f|--f|--fo|--for|--forc|force|--force-r|--force-re|--force-reb|--force-reba|--force-rebas|--force-rebase)
force_rebase=t
;;
+ --rerere-autoupdate|--no-rerere-autoupdate)
+ allow_rerere_autoupdate="$1"
+ ;;
-*)
usage
;;
diff --git a/parse-options.c b/parse-options.c
index f559411..10ec21f 100644
--- a/parse-options.c
+++ b/parse-options.c
@@ -633,3 +633,10 @@ int parse_opt_with_commit(const struct option *opt, const char *arg, int unset)
commit_list_insert(commit, opt->value);
return 0;
}
+
+int parse_opt_tertiary(const struct option *opt, const char *arg, int unset)
+{
+ int *target = opt->value;
+ *target = unset ? 2 : 1;
+ return 0;
+}
diff --git a/parse-options.h b/parse-options.h
index f295a2c..91c1500 100644
--- a/parse-options.h
+++ b/parse-options.h
@@ -123,6 +123,8 @@ struct option {
(h), PARSE_OPT_NOARG, NULL, (p) }
#define OPT_INTEGER(s, l, v, h) { OPTION_INTEGER, (s), (l), (v), "n", (h) }
#define OPT_STRING(s, l, v, a, h) { OPTION_STRING, (s), (l), (v), (a), (h) }
+#define OPT_UYN(s, l, v, h) { OPTION_CALLBACK, (s), (l), (v), NULL, \
+ (h), PARSE_OPT_NOARG, &parse_opt_tertiary }
#define OPT_DATE(s, l, v, h) \
{ OPTION_CALLBACK, (s), (l), (v), "time",(h), 0, \
parse_opt_approxidate_cb }
@@ -190,6 +192,7 @@ extern int parse_opt_abbrev_cb(const struct option *, const char *, int);
extern int parse_opt_approxidate_cb(const struct option *, const char *, int);
extern int parse_opt_verbosity_cb(const struct option *, const char *, int);
extern int parse_opt_with_commit(const struct option *, const char *, int);
+extern int parse_opt_tertiary(const struct option *, const char *, int);
#define OPT__VERBOSE(var) OPT_BOOLEAN('v', "verbose", (var), "be verbose")
#define OPT__QUIET(var) OPT_BOOLEAN('q', "quiet", (var), "be quiet")
diff --git a/rerere.c b/rerere.c
index 29f95f6..e0ac5bc 100644
--- a/rerere.c
+++ b/rerere.c
@@ -367,7 +367,7 @@ static int is_rerere_enabled(void)
return 1;
}
-int setup_rerere(struct string_list *merge_rr)
+int setup_rerere(struct string_list *merge_rr, int flags)
{
int fd;
@@ -375,6 +375,8 @@ int setup_rerere(struct string_list *merge_rr)
if (!is_rerere_enabled())
return -1;
+ if (flags & (RERERE_AUTOUPDATE|RERERE_NOAUTOUPDATE))
+ rerere_autoupdate = !!(flags & RERERE_AUTOUPDATE);
merge_rr_path = git_pathdup("MERGE_RR");
fd = hold_lock_file_for_update(&write_lock, merge_rr_path,
LOCK_DIE_ON_ERROR);
@@ -382,12 +384,12 @@ int setup_rerere(struct string_list *merge_rr)
return fd;
}
-int rerere(void)
+int rerere(int flags)
{
struct string_list merge_rr = { NULL, 0, 0, 1 };
int fd;
- fd = setup_rerere(&merge_rr);
+ fd = setup_rerere(&merge_rr, flags);
if (fd < 0)
return 0;
return do_plain_rerere(&merge_rr, fd);
diff --git a/rerere.h b/rerere.h
index 13313f3..10a94a4 100644
--- a/rerere.h
+++ b/rerere.h
@@ -3,9 +3,15 @@
#include "string-list.h"
-extern int setup_rerere(struct string_list *);
-extern int rerere(void);
+#define RERERE_AUTOUPDATE 01
+#define RERERE_NOAUTOUPDATE 02
+
+extern int setup_rerere(struct string_list *, int);
+extern int rerere(int);
extern const char *rerere_path(const char *hex, const char *file);
extern int has_rerere_resolution(const char *hex);
+#define OPT_RERERE_AUTOUPDATE(v) OPT_UYN(0, "rerere-autoupdate", (v), \
+ "update the index with reused conflict resolution if possible")
+
#endif
diff --git a/t/t4200-rerere.sh b/t/t4200-rerere.sh
index a6bc028..bb402c3 100755
--- a/t/t4200-rerere.sh
+++ b/t/t4200-rerere.sh
@@ -217,7 +217,22 @@ test_expect_success 'rerere.autoupdate' '
git checkout version2 &&
test_must_fail git merge fifth &&
test 0 = $(git ls-files -u | wc -l)
+'
+test_expect_success 'merge --rerere-autoupdate' '
+ git config --unset rerere.autoupdate
+ git reset --hard &&
+ git checkout version2 &&
+ test_must_fail git merge --rerere-autoupdate fifth &&
+ test 0 = $(git ls-files -u | wc -l)
+'
+
+test_expect_success 'merge --no-rerere-autoupdate' '
+ git config rerere.autoupdate true
+ git reset --hard &&
+ git checkout version2 &&
+ test_must_fail git merge --no-rerere-autoupdate fifth &&
+ test 2 = $(git ls-files -u | wc -l)
'
test_done
--
1.6.6.158.g8bda6.dirty
^ permalink raw reply related
* Re: submodules' shortcomings, was Re: RFC: display dirty submodule working directory in git gui and gitk
From: Jens Lehmann @ 2010-01-05 8:11 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Git Mailing List, Junio C Hamano, Shawn O. Pearce, Paul Mackerras,
Heiko Voigt, Lars Hjemli, Avery Pennarun
In-Reply-To: <alpine.DEB.1.00.1001042217370.4985@pacific.mpi-cbg.de>
Am 04.01.2010 23:29, schrieb Johannes Schindelin:
> You do remember the discussion at the Alles wird Git about the need for
> Subversion external-like behavior, right?
Yup. But never having used svn, let alone externals, i think i just
did not get it then ;-)
> - submodules were designed with a strong emphasis on not being forced to
> check them out. But Git makes it very unconvenient to actually check
> submodules out, let alone check them out at clone-time. And it is
> outright impossible to _enforce_ a submodule to be checked out.
Absolutely. But i think the group mappings discussed by Junio and Heiko
are a good starting point to solve that problem:
http://thread.gmane.org/gmane.comp.version-control.git/130928/
This should be solvable by putting the necessary information into
.gitmodules and have git clone use it.
> - among other use cases, submodules are recommended for sharing content
> between two different repositories. But it is part of the design that it
> is _very_ easy to forget to commit, or push the changes in the submodule
> that are required for the integrity of the superproject.
Definitely (and if i got that right, svn externals have the same problem).
What about checking for every submodule before a push in the superproject
that its HEAD is on a remote branch? I don't think we can provide full
safety here, but we could handle the 99% case of a forgotten push in the
submodule. This could even be done with a rather simple hook (if we had a
pre-push hook that is :-).
> - that use case -- sharing content between different repositories -- is
> not really supported by submodules, but rather an afterthought. This is
> all too obvious when you look at the restriction that the shared content
> must be in a single subdirectory.
I don't see that as a problem (and it's the same with svn externals, no?).
And having worked for a long time with a RCS variant which allowed
"projects" to contain an arbitrary list of files, i don't think this is
a problem (but forgetting to add new files to this list really is, so
putting everything in one directory is *much* safer IMHO).
And: almost all files were properly grouped in directories after a decade
of development even though that was not enforced by the scm at all.
> - related are the use cases where it is desired not to have a fixed
> submodule tip committed to the superproject, but always to update to the
> current, say, master (like Subversion's externals). This use case has
> been wished away by the people who implemented submodules in Git. But
> reality has this nasty habit of ignoring your wishes, does it not?
Having read up about svn externals in the meantime, what about something
like this:
- Add a command like "git submodule forward" (as update is already in
use) that takes an optional -b <branchname>. It does a fetch in the
submodule, then tries to fast forward (or rebase) to master or the
branch given and stages this commit in the superproject. This should
be the equivalent to doing an "svn update" in a repo with externals.
Or am i missing something?
(And we could avoid the detached HEAD in the fast forward case by
really checking out the branch in the submodule)
- We could also add an option to "git submodule add" to specify the
default branch name for forward.
> - while it might be called clever that the submodules' metadata are stored
> in .gitmodules in the superproject (and are therefore naturally tracked
> with Git), the synchronization with .git/config is performed exactly
> once -- when you initialize the submodule. You are likely to miss out
> on _every_ change you pulled into the superproject.
Yes. This synchronization could be either obsoleted by only using
.gitmodules or automated.
> Besides, as long as there is enough reason to have out-of-Git alternative
> solutions such as repo, submodules deserve to be 2nd-class citizens.
I think in the long run to make submodules first class citizens the
following submodule commands must be obsoleted by their regular git
parts: init (by git clone), status (by git status), update (by git
checkout), summary (already in git diff thanks to your patch) and sync
(maybe Avery's idea of only relying on .gitmodules and not copying data
int .git/config would solve this).
That would leave git submodule add, foreach and maybe a command to do
what svn update does for externals and another to manipulate things like
group membership etc..
Which reminds me of Sverre's quote from Alles Wird Git:
"Yes, it is possible. But it will be hard."
^ permalink raw reply
* [PATCH v4] Smart-http documentation: add example of how to execute from userdir
From: Tarmigan Casebolt @ 2010-01-05 7:59 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Tarmigan Casebolt, Tay Ray Chuan, Shawn O. Pearce
In-Reply-To: <905315641001042359h7850c6cdrf9160030aff67839@mail.gmail.com>
Smart-http may be an attactive and easy way for people to setup git
hosting on shared servers whose primary web server configuration they
do not control. To facilite this, provide an example of how it may be
done.
cc: Tay Ray Chuan <rctay89@gmail.com>
cc: Shawn O. Pearce <spearce@spearce.org>
Edited-by: Tay Ray Chuan <rctay89@gmail.com>
Signed-off-by: Tarmigan Casebolt <tarmigan+git@gmail.com>
---
Documentation/git-http-backend.txt | 33 +++++++++++++++++++++++++++++++--
1 files changed, 31 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-http-backend.txt b/Documentation/git-http-backend.txt
index 67aec06..7af1288 100644
--- a/Documentation/git-http-backend.txt
+++ b/Documentation/git-http-backend.txt
@@ -60,8 +60,8 @@ automatically by the web server.
EXAMPLES
--------
-All of the following examples map 'http://$hostname/git/foo/bar.git'
-to '/var/www/git/foo/bar.git'.
+Unless otherwise noted, the following examples map
+'http://$hostname/git/foo/bar.git' to '/var/www/git/foo/bar.git'.
Apache 2.x::
Ensure mod_cgi, mod_alias, and mod_env are enabled, set
@@ -144,6 +144,35 @@ ScriptAliasMatch \
ScriptAlias /git/ /var/www/cgi-bin/gitweb.cgi/
----------------------------------------------------------------
+In the following example, the repository at
+'/home/$username/devel/foo/bar.git' will be accessible at
+'http://$hostname/~$username/cgi-bin/git/foo/bar.git'.
+
+From UserDir on Apache 2.x::
+ One way to configure 'git-http-backend' to execute and serve
+ from a user directory (for example, on a shared hosting
+ provider), is to have a symbolic link named 'git' that points
+ from the cgi directory to the 'git-http-backend' executable in
+ libexec. The advantage is that this symbolic link always
+ points to the latest installed version; one does not have to
+ make any changes to the symbolic link when the installed
+ 'git-http-backend' is updated.
++
+----------------------------------------------------------------
+SetHandler cgi-script
+SetEnv GIT_PROJECT_ROOT /home/$username/devel
+----------------------------------------------------------------
++
+Also add any needed authentication to the .htaccess file as discussed
+in earlier examples.
++
+Depending on the global configuration of the web server, the
+"FollowSymLinks" or "SymLinksIfOwnerMatch" options might be needed.
+If the web server does not follow any symbolic links, the
+'git-http-backend' executable may be copied into the cgi-bin directory
+and renamed to 'git' to acheive the same effect, but it will also need
+to be manually updated whenever a new version of 'git-http-backend' is
+installed.
ENVIRONMENT
-----------
--
1.6.6
^ permalink raw reply related
* Re: [PATCH v3] Smart-http documentation: add example of how to execute from userdir
From: Tarmigan @ 2010-01-05 7:59 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, Tay Ray Chuan, git
In-Reply-To: <20100104140616.GB22872@spearce.org>
On Mon, Jan 4, 2010 at 6:06 AM, Shawn O. Pearce <spearce@spearce.org> wrote:
> Junio C Hamano <gitster@pobox.com> wrote:
>> I still see Cc: here; are people named above (and others commented on
>> earlier versions) happy with this round?
>
> I don't get why Options +SymLinksIfOwnerMatch is needed here.
>
> If we are linking to the root installed git-http-backend Apache
> will actually reject the link, because the link owner is likely to
> be $USER while the target is owned by root.
>
> So I really can't ACK this, the instructions don't jive with my
> understanding of the Apache configuration.
Fair enough.
There seem to be three reasonable ways to run from a userdir
(depending on what the global configuration allows):
- symlink to global git installation (if FollowSymLinks)
- symlink to user's git installation (if not FollowSymLink and only
SymLinkIfOwnerMatch)
- copy of git-http-backend binary (if no symlinks are followed)
The Options +SymLinksIfOwnerMatch is left over from when there was a
more detailed description of the second scenario and should probably
be removed now. The user may not have a choice about which of those
three can be used because it depends on the global server
configuration (which presumably the user does not control) so it's
difficult to provide instructions that will work for everyone. The
last option is likely to be the most portable, but also does not get
updated when the primary http-backend binary is updated.
Enumerating the details of setting up all of these configurations in
the man page seems excessive, but it would also be nice to have enough
information to still make it easy.
We could do one or more of the following:
- Remove the Options +SymLinksIfOwnerMatch as it is too specific to an
unknown configuration and let users figure out how to get symlinks to
work for their particular configuration
- Add a note to remind the user about SymLinksIfOwnerMatch or FollowSymLinks
- Emphasize copying git-http-backend binary into the cgi-bin directory
as that is likely the most portable across configurations
- Expand all three scenarios in detail
I'm inclined to do the first two with the following patch (cut-n-paste
warning) squashed in. I'll send the complete patch as a follow up.
Thanks,
Tarmigan
diff --git a/Documentation/git-http-backend.txt b/Documentation/git-http-backend
index 0485033..7af1288 100644
--- a/Documentation/git-http-backend.txt
+++ b/Documentation/git-http-backend.txt
@@ -160,13 +160,14 @@ From UserDir on Apache 2.x::
+
----------------------------------------------------------------
SetHandler cgi-script
-Options +SymLinksIfOwnerMatch
SetEnv GIT_PROJECT_ROOT /home/$username/devel
----------------------------------------------------------------
+
Also add any needed authentication to the .htaccess file as discussed
in earlier examples.
+
+Depending on the global configuration of the web server, the
+"FollowSymLinks" or "SymLinksIfOwnerMatch" options might be needed.
If the web server does not follow any symbolic links, the
'git-http-backend' executable may be copied into the cgi-bin directory
and renamed to 'git' to acheive the same effect, but it will also need
^ permalink raw reply related
* Re: What's cooking in git.git (Jan 2010, #01; Mon, 04)
From: Tay Ray Chuan @ 2010-01-05 7:28 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20100105064013.GB19025@coredump.intra.peff.net>
Hi,
On Tue, Jan 5, 2010 at 2:40 PM, Jeff King <peff@peff.net> wrote:
> On Mon, Jan 04, 2010 at 09:57:46PM -0800, Junio C Hamano wrote:
>
>> * tr/http-push-ref-status (2009-12-24) 6 commits
>> Daniel and Jeff commented on the earlier rounds; is everybody happy with
>> this v3? If so let's move it to 'next'. If not, please complain.
>
> I just posted a few comments, but I suspect the response will just
> involve Tay explaining why I'm wrong or confused. :) So no serious
> objections, but let's wait for this round of discussion.
thanks for taking the time to look at them; I'll be addressing your
concerns soon.
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: [PATCH] Documentation: reset: add some missing tables
From: Junio C Hamano @ 2010-01-05 6:47 UTC (permalink / raw)
To: Christian Couder
Cc: git, Linus Torvalds, Johannes Schindelin, Stephan Beyer,
Daniel Barkalow, Jakub Narebski, Paolo Bonzini, Johannes Sixt,
Stephen Boyd
In-Reply-To: <20100105055831.3539.26382.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> and while at it also explain why --merge option is disallowed in some
> cases.
>
> Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
> ---
> Documentation/git-reset.txt | 35 +++++++++++++++++++++++++++++------
> 1 files changed, 29 insertions(+), 6 deletions(-)
>
> I must say that I find it a bit strange (and difficult to explain) that
> we have:
>
> working index HEAD target working index HEAD
> ----------------------------------------------------
> B C C C --merge B C C
>
> while in the other cases, when it is allowed, --merge is like --hard.
That is probably because you don't explain what --merge option is _for_
well enough to your readers. If the reader understands it is to reset
away a half-merged conflicted result, starting from a potentially dirty
work tree, then it would be very obvious that the above is the right thing
to do.
As a prerequisite, the reader should be aware (otherwise they should read
some introductory git books, or http://gitster.livejournal.com/29060.html)
that a mergy operation can stop without completing a merge in two ways:
- If a path that is involved in a mergy operation has local changes in
the work tree, or if the index is dirty, the operation stops _without_
doing anything.
- If all paths that are involved in a mergy operation are clean in the
work tree, the operation is attempted. If a conflict happens at the
content level, the operation leaves the paths in conflicted state in
the index and leaves the conflict markers in the files in the work
tree. Be _very_ aware that even in this case, cleanly automerged paths
are updated in the index and the work tree.
In the first case, you do not have to run "reset --merge", as nothing was
done by the mergy operation (it happens to be safe to "reset --merge", as
the only thing you lose is a partial add, which you can easily redo from
the files in the working tree).
In the latter case, there are four classes of paths:
(1) Ones that are not involved in the merge at all, and were clean from
the beginning. The work tree file, the index and the HEAD would
match.
w=C i=C H=C
(2) Ones that are not involved in the merge at all, but were dirty when
you started the mergy operation. They have your local changes in the
work tree that you wanted to keep across the mergy operation.
w=B i=C H=C
(3) Ones that are involved in the merge, and were cleanly merged. By
definition, these paths did _not_ have local changes in the work tree
(otherwise the mergy operation would have stopped without doing
anything). These are updated in the index and the files in the work
tree matches the index after the mergy operation stops.
w=B i=B H=C
(4) Ones that are involved in the merge, and were conflicted. Again, by
definition, these paths did _not_ have local changes in the work tree
These are left in the index as conflicted, and the files in the work
tree have conflict markers after the mergy operation stops.
w=X i=U H=C
"reset --merge HEAD" is about going back to the state before you started
this mergy operation. You don't need to do anything to paths in (1), and
you want to reset paths in (3) and (4) back to the HEAD.
Think what you want to do to (2). By definition, they weren't involved in
the mergy operation (otherwise you couldn't have come this far), so the
difference between the index and the work tree is purely your local
changes, untouched by the mergy operation, and have not even been updated
in "cvs update" style. The right thing to do is simply leave them as they
are.
Side note. Explained in the opposite way, if the work tree file is
different from the index and the index is not unmerged, the difference
_only_ could have come from the local change before you started your
mergy operation. Any other change to the work tree files done by any
mergy operation will be matched to the index. So w=B i=C in (2) will
immediately tell you that the change is a local one that is unrelated
to the merge.
By the way, people often say that the index is good because it allows you
to make partial commits (i.e. "add -p"), but at the same time have this
mistaken notion that it is the _primary_ benefit of the index. Actually,
a lot more important benefit of the index is (3) above. When you are
dealing with a large merge with many paths, often a lot of them automerge
cleanly while some gives you conflicts. The automerged results are added
to the index and you do not have to see them in "git diff" (as their files
and the index match), to allow you concentrate on the conflicted ones very
easily.
^ permalink raw reply
* Re: How to exclude files from "git diff"
From: Jeff King @ 2010-01-05 6:45 UTC (permalink / raw)
To: H.J. Lu; +Cc: git
In-Reply-To: <6dc9ffc80912180909q2e9cbe30r7c802a2152c5954@mail.gmail.com>
On Fri, Dec 18, 2009 at 09:09:15AM -0800, H.J. Lu wrote:
> I have some bookkeeping files in my git repository. How do I
> exclude them from "git diff"? Does "git diff" support
>
> # git diff --exclude="foo.*.bar*"
No, I don't believe there is a way to do that. You would have to do
something like:
git diff $(git ls-files | grep -v whatever)
The usual concept of "exclusion" for git is not to track files at all
via the .gitignore mechanism. Are these files that have content you
really _want_ in the repository, but you just don't want to see them
when doing some diffs? Or are they files that could not be in the
repository at all?
-Peff
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2010, #01; Mon, 04)
From: Jeff King @ 2010-01-05 6:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Tay Ray Chuan, git
In-Reply-To: <7vskal5c11.fsf@alter.siamese.dyndns.org>
On Mon, Jan 04, 2010 at 09:57:46PM -0800, Junio C Hamano wrote:
> * tr/http-push-ref-status (2009-12-24) 6 commits
> Daniel and Jeff commented on the earlier rounds; is everybody happy with
> this v3? If so let's move it to 'next'. If not, please complain.
I just posted a few comments, but I suspect the response will just
involve Tay explaining why I'm wrong or confused. :) So no serious
objections, but let's wait for this round of discussion.
-Peff
^ permalink raw reply
* Re: [PATCH v3 2/6] t5541-http-push.sh: add test for unmatched, non-fast-forwarded refs
From: Jeff King @ 2010-01-05 6:35 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: git, Shawn O. Pearce, Daniel Barkalow, Junio C Hamano
In-Reply-To: <20091224154158.15ba580f.rctay89@gmail.com>
On Thu, Dec 24, 2009 at 03:41:58PM +0800, Tay Ray Chuan wrote:
> Test that when non-fast-forwarded refs cannot be matched without an
> explicit refspect, the push fails with a non-fast-forward ref status and
> help message.
I don't understand what you're testing here. If it's not matched, then
how is it a non-fast-forward? Isn't it simply unmatched?
Your test:
> +test_expect_failure 'push fails for non-fast-forward refs unmatched by remote helper' '
> + # create a dissimilarly-named ref so that git is unable to match the refs
> + git push origin master:retsam
> +
> + echo "change changed" > path2 &&
> + git commit -a -m path2 --amend &&
> +
> + # push master too. This ensures there is at least one '"'push'"' command to
> + # the remote helper and triggers interaction with the helper.
> + !(git push -v origin +master master:retsam >output 2>&1) &&
> +
> + grep "^ + [a-z0-9]\+\.\.\.[a-z0-9]\+[ ]*master -> master (forced update)$" output &&
> + grep "^ ! \[rejected\][ ]*master -> retsam (non-fast-forward)$" output &&
Looks like you're just testing the usual "master -> retsam is not a
fast-forward" case. I don't understand how this is different from the
previous tests. Can you elaborate?
-Peff
^ permalink raw reply
* Re: [PATCH v3 5/6] transport-helper.c::push_refs(): ignore helper-reported status if ref is not to be pushed
From: Jeff King @ 2010-01-05 6:32 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: git, Shawn O. Pearce, Daniel Barkalow, Junio C Hamano
In-Reply-To: <20091224154445.ad4b7a01.rctay89@gmail.com>
On Thu, Dec 24, 2009 at 03:44:45PM +0800, Tay Ray Chuan wrote:
> - ref->status = status;
> - ref->remote_status = msg;
> + switch (ref->status) {
> + case REF_STATUS_REJECT_NONFASTFORWARD:
> + case REF_STATUS_UPTODATE:
> + /*
> + * Earlier, the ref was marked not to be pushed, so ignore what
> + * the remote helper said about the ref.
> + */
> + continue;
> + default:
> + ref->status = status;
> + ref->remote_status = msg;
> + }
It seems like this should be checking for REF_STATUS_NONE explicitly
instead of trying to enumerate the reasons we might not have tried to
push. Shouldn't helpers _only_ be pushing REF_STATUS_NONE refs?
I think right now the two cases are equivalent, since non-ff and
uptodate are the only two states set before the helper is invoked. But
we have discussed in the past (and I still have a patch floating around
for) a REF_STATUS_REWIND which would treat strict rewinds differently
(silently ignoring them instead of making an error). Explicitly checking
REF_STATUS_NONE future-proofs against new states being added.
-Peff
^ 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