* Re: Working with remotes; cloning remote references
From: Peter Harris @ 2008-10-16 19:20 UTC (permalink / raw)
To: Marc Branchaud; +Cc: git
In-Reply-To: <48F7852F.109@xiplink.com>
On Thu, Oct 16, 2008 at 2:17 PM, Marc Branchaud wrote:
> From this point of view (and please correct me if I'm wrong), it would be
> good if "git clone" had an option to include a repo's remote references in
> the clone. The clone's origin reference would point to the original repo as
> usual, but all the other remotes would be in the clone.
"git clone" doesn't have this option, but you can turn it on
immediately after with something similar to:
git config --add remote.origin.fetch +refs/remotes/*:refs/remotes/*
(which I use for fanning-out my git-svn repos)
See "git help fetch" for further documentation.
Peter Harris
^ permalink raw reply
* [JGIT PATCH] Fix the build script to make jgit.jar, jgit.src non-executable
From: Shawn O. Pearce @ 2008-10-16 19:57 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
Silly copy and paste error included these unncessary chmods.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
make_jgit.sh | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/make_jgit.sh b/make_jgit.sh
index a15f73f..2969e6e 100755
--- a/make_jgit.sh
+++ b/make_jgit.sh
@@ -95,7 +95,6 @@ java org.spearce.jgit.pgm.build.JarLinkUtil \
-include org.spearce.jgit/bin2 \
-file META-INF/MANIFEST.MF=$T_MF \
>$O_JAR+ &&
-chmod 555 $O_JAR+ &&
mv $O_JAR+ $O_JAR &&
echo "Created $O_JAR." &&
@@ -103,7 +102,6 @@ java org.spearce.jgit.pgm.build.JarLinkUtil \
-include org.spearce.jgit/src \
-file META-INF/MANIFEST.MF=$T_MF \
>$O_SRC+ &&
-chmod 555 $O_SRC+ &&
mv $O_SRC+ $O_SRC &&
echo "Created $O_SRC." &&
--
1.6.0.2.711.gf1ba4
^ permalink raw reply related
* Re: [PATCH] Teach/Fix git-pull/git-merge --quiet and --verbose
From: Tuncer Ayaz @ 2008-10-16 20:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vtzbdjcb8.fsf@gitster.siamese.dyndns.org>
On Thu, Oct 16, 2008 at 8:15 AM, Junio C Hamano <gitster@pobox.com> wrote:
> "Tuncer Ayaz" <tuncer.ayaz@gmail.com> writes:
>
>> On Thu, Oct 16, 2008 at 2:07 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>> "Tuncer Ayaz" <tuncer.ayaz@gmail.com> writes:
>>>
>>>> On Wed, Oct 15, 2008 at 9:06 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>>>> "Tuncer Ayaz" <tuncer.ayaz@gmail.com> writes:
>>>>>
>> Would you prefer to leave -v out?
>
> Not at all.
>
> Perhaps there is a deeper misunderstanding.
Perhaps there was one :-)
> It makes perfect sense _at the end user interface level_ to have -v and -q
> as two separate options, perhaps with "later one wins" semantics. Another
> possible semantics is "-q and -v are mutually incompatible", but I think
> "later one wins" makes it much more usable from the end user's point of view.
>
> The only thing I was objecting to was your repeated (verbose || !quiet)
> expression in the _implementation_, which would have been much easier to
> read and maintain, if it were expressed as a single variable "verbosity"
> that can have one of three values.
This leaves no space for speculation and is as clear as it gets :D
> IOW,
>
> static enum { QUIET, NORMAL, VERBOSE } verbosity = NORMAL;
> ...
>
> if (!strcmp("--quiet", arg))
> verbosity = QUIET;
> else if (!strcmp("--verbose", arg))
> verbosity = VERBOSE;
> else ...
>
> ...
> if (verbosity > QUIET)
> print informational message;
> if (verbosity > NORMAL)
> print verbose message;
>
> See?
Yeah, no problem with that.
How do you propose we should integrate this with the
existing usage of parse_options() and OPT_ macros?
I want to keep using it and not redo argv handling
from scratch in builtin-fetch/builtin-merge.
^ permalink raw reply
* Re: Detached checkout will clobber branch head when using symlink HEAD
From: Matt Draisey @ 2008-10-16 20:11 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20081016191751.GB14707@coredump.intra.peff.net>
On Thu, 2008-10-16 at 15:17 -0400, Jeff King wrote:
> Hmm. I don't think we have shipped with a symlink HEAD for quite a long
> time. Using one obviously doesn't work with detached HEAD, but also
> would fail with packed refs. I don't know if we ever deprecated it.
I am using the following system defaults:
core.prefersymlinkrefs=true
gc.packrefs=false
so almost all my git repositories are still using a symlink HEAD.
I have some old scripts That I use occasionally and still depend on it.
Using detached checkout is the only problem I've had.
^ permalink raw reply
* Re: Git and tagging hook
From: Jan Hudec @ 2008-10-16 20:15 UTC (permalink / raw)
To: Kristis Makris; +Cc: Andreas Ericsson, Jakub Narebski, git, scmbug-users
In-Reply-To: <1224007401.4073.40.camel@localhost>
On Tue, Oct 14, 2008 at 11:03:21 -0700, Kristis Makris wrote:
> I have two use cases:
>
> (1) A developer maintains besides his local copy a local bug-tracking
> system in which he tracks his changes. We would like to apply various
> verification policies when he commits or tags. For example, for tagging
> we wants to ensure that he tags giving consistent labels to his
> intermediate builds. e.g. as in:
>
> http://files.mkgnu.net/files/scmbug/SCMBUG_RELEASE_0-26-9/manual/html-single/manual.html#VERIFICATION-CHECKS-CONVENTION-BASED-LABELING
That already requires using additional interface to git alone. Using an alias
for creating tags that are synchronized with that local bug-tracker is not
that much more complex than IMHO. Besides you will sometimes want to use git
tags, branches, commits and other things *without* synchronizing them to the
local bug-tracker even if you usually synchronize -- they are often very
useful for manipulating changes.
> Or he may want to have Git force him to also supply a log message along
> with a tag, so that he can remember later more accurately why a tag was
> created and what it really captures. Even if Git (or other SCM systems)
> don't natively support log messages on tags. Scmbug plans to implement
> this.
>
> http://bugzilla.mkgnu.net/show_bug.cgi?id=219
Git does support log messages on tags. It has unannotated tags (which are
just refs) and annotated tags which have a special tag object with the log
message (and optionally PGP signature).
> (2) I would like to apply various verification policies when work from a
> local repository is finally merged with the central repository. I assume
> there can/will be a central repository, and there is one "software
> product" that is being released somewhere among the many copies.
>
> When its time to merge local changes to a central repository, the
> verification policies may deem that changes are not acceptable to be
> merged with the mainline. e.g. because log messages are too short,
> commits during the merge are issued against bugs in "a central"
> bugtracker that are either closed, assigned to someone else, or just
> plain wrong bug-numbers that belong to other products:
>
> http://files.mkgnu.net/files/scmbug/SCMBUG_RELEASE_0-26-9/manual/html-single/manual.html#VERIFICATION-CHECKS-VALID-LOG-MESSAGE-SIZE
> http://files.mkgnu.net/files/scmbug/SCMBUG_RELEASE_0-26-9/manual/html-single/manual.html#VERIFICATION-CHECKS-OPEN-BUG-STATE
> http://files.mkgnu.net/files/scmbug/SCMBUG_RELEASE_0-26-9/manual/html-single/manual.html#VERIFICATION-CHECKS-VALID-BUG-OWNER
> http://files.mkgnu.net/files/scmbug/SCMBUG_RELEASE_0-26-9/manual/html-single/manual.html#VERIFICATION-CHECKS-VALID-PRODUCT-NAME
>
> (I'm not very clear whether this is how Git works)
>
> Does someone get to write-up a brand new log comment during the merge
> and the merge totally disregards older log comments? My understanding
> is that log comments on the local copy are preserved (and will need to
> be mapped to bug-numbers in the central bug-tracker.
Indeed, the locally made commits are transfered to the upstream repository as
they are. In fact, because the commit id is a SHA1 checksum of all it's
content, including the message and the parent ids (and therefore complete
history), when the commit message is changed, it is no longer the same
commit.
However, git provides many tools (commit --amend, rebase -i, filter-branch)
and has additional extensions (stgit, topgit), that make it easy to create
a new commit based on another one with some change. This is extremely useful
and many people use it really often.
Such new commit will not replace the previous one -- it has different
checksum -- so it's not good thing to do when other people already based
further changes on your commit. But it's very useful for handling work in
progress, quickly diverting to different tasks, making experiments and such.
Therefore it's the push that casts things in stone, but before that you can
easily take back and redo both commits and tags. Additionally it's very
useful to sometimes do commits and tags that you intend to replace later just
to temporarily record some interesting state eg. to divert to other bug that
suddenly got higher priority or to try out different approach.
Thus you only want to run the checks as warnings locally and probably want to
have an option to avoid them in a particular case for performance reasons
(all this stuff is so useful because it's fast). And since the tags that are
ment for publication you will usually pull shortly after making them and
because creating a tag is rather simple, I would say that running the check
on push is sufficient there and the alias helps if you'd really want to run
the check earlier. For commits you can of course use the pre-commit and
post-commit hooks.
> [...]
> The local tag is useful to the local user and his local bug-tracker. He
> can have tag operations intercepted so that the tag names show up as
> versions in his bug-tracker. In this way he can keep track of which bugs
> still exist or have recently been introduced/discovered to his local
> copy, before he decides to publish his polished, final version:
>
> http://files.mkgnu.net/files/scmbug/SCMBUG_RELEASE_0-26-9/manual/html-single/manual.html#TAGS
>
> And his "local bug-tracker" may be reachable on the web and useful by
> others that take a peek at the users progress (even fetching it with
> Git).
I would rather recommend having per-developer branches (you can actually have
branch hierarchies, so it's rather per-developer branch directories) on the
central repo, where the users would push their work they consider final
enough to show to anybody. Than you can have a "pending" (or "for review" or
both or whatever) state in the central bug-tracker for issues with fixes on
such developer branches. That saves the hassle of installing per-developer
trackers and gives developer more freedom to create temporary stuff locally.
That is not to say that your use case makes no sense. I am just trying to
suggest a workflow, that might fit better with the existing practices used
with git and maybe requiring less work to implement.
As for people replacing their local commits, this is common especially in
Linux (and Git) development model. For Linux patches need to be sent split
into logical steps to make it easier to review them, which is quite important
for a critical piece of code like kernel. But everybody will inevitably make
mistakes when implementing the changes; these mistakes must not appear in the
final submission though, because they would interfere with review. When
developing in Git, each commit will produce one patch in the submission, so
people go and redo their commits multiple times to make them as much readable
as possible and fix bugs they made earlier.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
^ permalink raw reply
* Re: Detached checkout will clobber branch head when using symlink HEAD
From: Nicolas Pitre @ 2008-10-16 20:20 UTC (permalink / raw)
To: Matt Draisey; +Cc: Jeff King, Junio C Hamano, git
In-Reply-To: <1224187863.2796.15.camel@localhost>
On Thu, 16 Oct 2008, Matt Draisey wrote:
> On Thu, 2008-10-16 at 15:17 -0400, Jeff King wrote:
>
> > Hmm. I don't think we have shipped with a symlink HEAD for quite a long
> > time. Using one obviously doesn't work with detached HEAD, but also
> > would fail with packed refs. I don't know if we ever deprecated it.
>
> I am using the following system defaults:
>
> core.prefersymlinkrefs=true
> gc.packrefs=false
>
> so almost all my git repositories are still using a symlink HEAD.
> I have some old scripts That I use occasionally and still depend on it.
> Using detached checkout is the only problem I've had.
A symlink HEAD and detached checkouts are simply incompatible.
Nicolas
^ permalink raw reply
* Re: Detached checkout will clobber branch head when using symlink HEAD
From: Jeff King @ 2008-10-16 20:22 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Matt Draisey, Junio C Hamano, git
In-Reply-To: <alpine.LFD.2.00.0810161619330.26244@xanadu.home>
On Thu, Oct 16, 2008 at 04:20:32PM -0400, Nicolas Pitre wrote:
> > so almost all my git repositories are still using a symlink HEAD.
> > I have some old scripts That I use occasionally and still depend on it.
> > Using detached checkout is the only problem I've had.
>
> A symlink HEAD and detached checkouts are simply incompatible.
Agreed, but I think the complaint is not that it doesn't work, but that
it silently clobbers the current branch when you try it.
-Peff
^ permalink raw reply
* [PATCHv6 0/5] gitweb: PATH_INFO enhancement
From: Giuseppe Bilotta @ 2008-10-16 20:27 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
Sixth attempt for my gitweb PATH_INFO patchset, whose purpose is to
reduce the use of CGI parameters by embedding as many parameters as
possible in the URL path itself, provided the pathinfo feature is
enabled.
The new typical gitweb URL is therefore in the form
$project/$action/$parent:$file..$hash:$file
(with useless parts stripped). Backwards compatibility for old-style
$project/$hash[:$file] URLs is kept, as long as $hash is not a refname
whose name happens to match a git action.
The main implementation is provided by paired patches (#1#2, #4#5)
that implement parsing and generation of the new style URLs.
Patch #3 is a minor improvement to the URL syntax that allows web
sites to be properly browsable in raw mode.
The patchset depends on my previous input parameter handling patch
currently waiting in 'next'. This resend fixes a couple of problems
I found in v5.
Giuseppe Bilotta (5):
gitweb: parse project/action/hash_base:filename PATH_INFO
gitweb: generate project/action/hash URLs
gitweb: use_pathinfo filenames start with /
gitweb: parse parent..current syntax from PATH_INFO
gitweb: generate parent..current URLs
gitweb/gitweb.perl | 124 +++++++++++++++++++++++++++++++++++++++++++++++----
1 files changed, 114 insertions(+), 10 deletions(-)
^ permalink raw reply
* [PATCHv6 1/5] gitweb: parse project/action/hash_base:filename PATH_INFO
From: Giuseppe Bilotta @ 2008-10-16 20:27 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1224188831-17767-1-git-send-email-giuseppe.bilotta@gmail.com>
This patch enables gitweb to parse URLs with more information embedded
in PATH_INFO, reducing the need for CGI parameters. The typical gitweb
path is now $project/$action/$hash_base:$file_name or
$project/$action/$hash
This is mostly backwards compatible with the old-style gitweb paths,
$project/$branch[:$filename], except when it was used to access a branch
whose name matches a gitweb action.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 37 +++++++++++++++++++++++++++++++------
1 files changed, 31 insertions(+), 6 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index c5254af..6d0dc26 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -534,23 +534,48 @@ sub evaluate_path_info {
return if $input_params{'action'};
$path_info =~ s,^\Q$project\E/*,,;
+ # next, check if we have an action
+ my $action = $path_info;
+ $action =~ s,/.*$,,;
+ if (exists $actions{$action}) {
+ $path_info =~ s,^$action/*,,;
+ $input_params{'action'} = $action;
+ }
+
+ # list of actions that want hash_base instead of hash
+ my @wants_base = (
+ 'tree',
+ 'history',
+ );
+
my ($refname, $pathname) = split(/:/, $path_info, 2);
if (defined $pathname) {
- # we got "project.git/branch:filename" or "project.git/branch:dir/"
+ # we got "branch:filename" or "branch:dir/"
# we could use git_get_type(branch:pathname), but it needs $git_dir
$pathname =~ s,^/+,,;
if (!$pathname || substr($pathname, -1) eq "/") {
- $input_params{'action'} = "tree";
+ $input_params{'action'} ||= "tree";
$pathname =~ s,/$,,;
} else {
- $input_params{'action'} = "blob_plain";
+ $input_params{'action'} ||= "blob_plain";
}
$input_params{'hash_base'} ||= $refname;
$input_params{'file_name'} ||= $pathname;
} elsif (defined $refname) {
- # we got "project.git/branch"
- $input_params{'action'} = "shortlog";
- $input_params{'hash'} ||= $refname;
+ # we got "branch". in this case we have to choose if we have to
+ # set hash or hash_base.
+ #
+ # Most of the actions without a pathname only want hash to be
+ # set, except for the ones specified in @wants_base that want
+ # hash_base instead. It should also be noted that hand-crafted
+ # links having 'history' as an action and no pathname or hash
+ # set will fail, but that happens regardless of PATH_INFO.
+ $input_params{'action'} ||= "shortlog";
+ if (grep {$input_params{'action'} eq $_} @wants_base) {
+ $input_params{'hash_base'} ||= $refname;
+ } else {
+ $input_params{'hash'} ||= $refname;
+ }
}
}
evaluate_path_info();
--
1.5.6.5
^ permalink raw reply related
* [PATCHv6 2/5] gitweb: generate project/action/hash URLs
From: Giuseppe Bilotta @ 2008-10-16 20:27 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1224188831-17767-2-git-send-email-giuseppe.bilotta@gmail.com>
When generating path info URLs, reduce the number of CGI parameters by
embedding action and hash_parent:filename or hash in the path.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 33 ++++++++++++++++++++++++++++++---
1 files changed, 30 insertions(+), 3 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 6d0dc26..5337d40 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -724,14 +724,41 @@ sub href (%) {
my ($use_pathinfo) = gitweb_check_feature('pathinfo');
if ($use_pathinfo) {
- # use PATH_INFO for project name
+ # try to put as many parameters as possible in PATH_INFO:
+ # - project name
+ # - action
+ # - hash or hash_base:filename
+
+ # When the script is the root DirectoryIndex for the domain,
+ # $href here would be something like http://gitweb.example.com/
+ # Thus, we strip any trailing / from $href, to spare us double
+ # slashes in the final URL
+ $href =~ s,/$,,;
+
+ # Then add the project name, if present
$href .= "/".esc_url($params{'project'}) if defined $params{'project'};
delete $params{'project'};
- # Summary just uses the project path URL
- if (defined $params{'action'} && $params{'action'} eq 'summary') {
+ # Summary just uses the project path URL, any other action is
+ # added to the URL
+ if (defined $params{'action'}) {
+ $href .= "/".esc_url($params{'action'}) unless $params{'action'} eq 'summary';
delete $params{'action'};
}
+
+ # Finally, we put either hash_base:file_name or hash
+ if (defined $params{'hash_base'}) {
+ $href .= "/".esc_url($params{'hash_base'});
+ if (defined $params{'file_name'}) {
+ $href .= ":".esc_url($params{'file_name'});
+ delete $params{'file_name'};
+ }
+ delete $params{'hash'};
+ delete $params{'hash_base'};
+ } elsif (defined $params{'hash'}) {
+ $href .= "/".esc_url($params{'hash'});
+ delete $params{'hash'};
+ }
}
# now encode the parameters explicitly
--
1.5.6.5
^ permalink raw reply related
* [PATCHv6 3/5] gitweb: use_pathinfo filenames start with /
From: Giuseppe Bilotta @ 2008-10-16 20:27 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1224188831-17767-3-git-send-email-giuseppe.bilotta@gmail.com>
When using path info, make filenames start with a / (right after the :
that separates them from the hash base). This minimal change allows
relative navigation to work properly when viewing HTML files in raw
('blob_plain') mode.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 5337d40..49730f3 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -727,7 +727,7 @@ sub href (%) {
# try to put as many parameters as possible in PATH_INFO:
# - project name
# - action
- # - hash or hash_base:filename
+ # - hash or hash_base:/filename
# When the script is the root DirectoryIndex for the domain,
# $href here would be something like http://gitweb.example.com/
@@ -746,11 +746,11 @@ sub href (%) {
delete $params{'action'};
}
- # Finally, we put either hash_base:file_name or hash
+ # Finally, we put either hash_base:/file_name or hash
if (defined $params{'hash_base'}) {
$href .= "/".esc_url($params{'hash_base'});
if (defined $params{'file_name'}) {
- $href .= ":".esc_url($params{'file_name'});
+ $href .= ":/".esc_url($params{'file_name'});
delete $params{'file_name'};
}
delete $params{'hash'};
--
1.5.6.5
^ permalink raw reply related
* [PATCHv6 4/5] gitweb: parse parent..current syntax from PATH_INFO
From: Giuseppe Bilotta @ 2008-10-16 20:27 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1224188831-17767-4-git-send-email-giuseppe.bilotta@gmail.com>
This patch makes it possible to use an URL such as
$project/somebranch..otherbranch:/filename to get a diff between
different version of a file. Paths like
$project/$action/somebranch:/somefile..otherbranch:/otherfile are parsed
as well.
All '*diff' actions and in general actions that use $hash_parent[_base]
and $file_parent can now get all of their parameters from PATH_INFO
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 36 ++++++++++++++++++++++++++++++++++--
1 files changed, 34 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 49730f3..1a7b0b9 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -548,7 +548,12 @@ sub evaluate_path_info {
'history',
);
- my ($refname, $pathname) = split(/:/, $path_info, 2);
+ # horrible regexp to catch
+ # [$hash_parent_base[:$file_parent]..]$hash_parent[:$file_name]
+ my ($parentrefname, $parentpathname, $refname, $pathname) =
+ ($path_info =~ /^(?:(.+?)(?::(.+))?\.\.)?(.+?)(?::(.+))?$/);
+
+ # first, analyze the 'current' part
if (defined $pathname) {
# we got "branch:filename" or "branch:dir/"
# we could use git_get_type(branch:pathname), but it needs $git_dir
@@ -557,7 +562,13 @@ sub evaluate_path_info {
$input_params{'action'} ||= "tree";
$pathname =~ s,/$,,;
} else {
- $input_params{'action'} ||= "blob_plain";
+ # the default action depends on whether we had parent info
+ # or not
+ if ($parentrefname) {
+ $input_params{'action'} ||= "blobdiff_plain";
+ } else {
+ $input_params{'action'} ||= "blob_plain";
+ }
}
$input_params{'hash_base'} ||= $refname;
$input_params{'file_name'} ||= $pathname;
@@ -577,6 +588,27 @@ sub evaluate_path_info {
$input_params{'hash'} ||= $refname;
}
}
+
+ # next, handle the 'parent' part, if present
+ if (defined $parentrefname) {
+ # a missing pathspec defaults to the 'current' filename, allowing e.g.
+ # someproject/blobdiff/oldrev..newrev:/filename
+ if ($parentpathname) {
+ $parentpathname =~ s,^/+,,;
+ $parentpathname =~ s,/$,,;
+ $input_params{'file_parent'} ||= $parentpathname;
+ } else {
+ $input_params{'file_parent'} ||= $input_params{'file_name'};
+ }
+ # we assume that hash_parent_base is wanted if a path was specified,
+ # or if the action wants hash_base instead of hash
+ if (defined $input_params{'file_parent'} ||
+ grep {$input_params{'action'} eq $_} @wants_base) {
+ $input_params{'hash_parent_base'} ||= $parentrefname;
+ } else {
+ $input_params{'hash_parent'} ||= $parentrefname;
+ }
+ }
}
evaluate_path_info();
--
1.5.6.5
^ permalink raw reply related
* [PATCHv6 5/5] gitweb: generate parent..current URLs
From: Giuseppe Bilotta @ 2008-10-16 20:27 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1224188831-17767-5-git-send-email-giuseppe.bilotta@gmail.com>
If use_pathinfo is enabled, href now creates links that contain paths in
the form $project/$action/oldhash:/oldname..newhash:/newname for actions
that use hash_parent etc.
If any of the filename contains two consecutive dots, it's kept as a CGI
parameter since the resulting path would otherwise be ambiguous.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 30 +++++++++++++++++++++++++-----
1 files changed, 25 insertions(+), 5 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 1a7b0b9..f4642e7 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -759,7 +759,8 @@ sub href (%) {
# try to put as many parameters as possible in PATH_INFO:
# - project name
# - action
- # - hash or hash_base:/filename
+ # - hash_parent or hash_parent_base:/file_parent
+ # - hash or hash_base:/file_name
# When the script is the root DirectoryIndex for the domain,
# $href here would be something like http://gitweb.example.com/
@@ -778,17 +779,36 @@ sub href (%) {
delete $params{'action'};
}
- # Finally, we put either hash_base:/file_name or hash
+ # Next, we put hash_parent_base:/file_parent..hash_base:/file_name,
+ # stripping nonexistent or useless pieces
+ $href .= "/" if ($params{'hash_base'} || $params{'hash_parent_base'}
+ || $params{'hash_parent'} || $params{'hash'});
if (defined $params{'hash_base'}) {
- $href .= "/".esc_url($params{'hash_base'});
- if (defined $params{'file_name'}) {
+ if (defined $params{'hash_parent_base'}) {
+ $href .= esc_url($params{'hash_parent_base'});
+ # skip the file_parent if it's the same as the file_name
+ delete $params{'file_parent'} if $params{'file_parent'} eq $params{'file_name'};
+ if (defined $params{'file_parent'} && $params{'file_parent'} !~ /\.\./) {
+ $href .= ":/".esc_url($params{'file_parent'});
+ delete $params{'file_parent'};
+ }
+ $href .= "..";
+ delete $params{'hash_parent'};
+ delete $params{'hash_parent_base'};
+ } elsif (defined $params{'hash_parent'}) {
+ $href .= esc_url($params{'hash_parent'}). "..";
+ delete $params{'hash_parent'};
+ }
+
+ $href .= esc_url($params{'hash_base'});
+ if (defined $params{'file_name'} && $params{'file_name'} !~ /\.\./) {
$href .= ":/".esc_url($params{'file_name'});
delete $params{'file_name'};
}
delete $params{'hash'};
delete $params{'hash_base'};
} elsif (defined $params{'hash'}) {
- $href .= "/".esc_url($params{'hash'});
+ $href .= esc_url($params{'hash'});
delete $params{'hash'};
}
}
--
1.5.6.5
^ permalink raw reply related
* Re: Detached checkout will clobber branch head when using symlink HEAD
From: Matt Draisey @ 2008-10-16 20:28 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jeff King, Junio C Hamano, git
In-Reply-To: <alpine.LFD.2.00.0810161619330.26244@xanadu.home>
On Thu, 2008-10-16 at 16:20 -0400, Nicolas Pitre wrote:
> A symlink HEAD and detached checkouts are simply incompatible.
Not necessarily. The symlinking code will unlink the original inode
each time it creates a new symlink anyway. It is simply a matter of
creating a new file in its place.
^ permalink raw reply
* Re: Working with remotes; cloning remote references
From: Marc Branchaud @ 2008-10-16 20:29 UTC (permalink / raw)
To: git; +Cc: git
In-Reply-To: <eaa105840810161220k26eebd48q8de606597f2be055@mail.gmail.com>
Peter Harris wrote:
>
> "git clone" doesn't have this option, but you can turn it on
> immediately after with something similar to:
> git config --add remote.origin.fetch +refs/remotes/*:refs/remotes/*
> (which I use for fanning-out my git-svn repos)
Thanks for the pointer (and the quick reply).
That doesn't seem to be what I'm looking for, though -- perhaps I'm
missing something? The above puts the remotes in the .git/refs/remotes
directory, but the .git/config file doesn't have them.
More specifically, if I clone the main repository and run the above and
then fetch, then AFAICT I'm still not linked to the external mirrors in
the clone. In particular, I can't refer to an external project in the
subtree pull:
$ git pull -s subtree external2 master
fatal: 'external2': unable to chdir or not a git archive
(Where 'external2' is the name of the remote in the main repo.) Also,
the only remote in the config file is still just the origin.
(As an aside, the above "git config --add" incantation causes problems
if run inside a clone of a clone:
$ git clone main clone-of-main
$ git clone clone-of-main clone-of-clone-of-main
$ cd clone-of-clone-of-main
$ git config --add remote.origin.fetch \
+refs/remotes/*:refs/remotes/*
$ git pull
fatal: refs/remotes/origin/master tracks both
refs/remotes/origin/master and refs/heads/master
)
You did say "something similar" in your reply -- am I not seeing
something obvious?
Marc
^ permalink raw reply
* Re: Detached checkout will clobber branch head when using symlink HEAD
From: Nicolas Pitre @ 2008-10-16 20:30 UTC (permalink / raw)
To: Jeff King; +Cc: Matt Draisey, Junio C Hamano, git
In-Reply-To: <20081016202202.GA9487@coredump.intra.peff.net>
On Thu, 16 Oct 2008, Jeff King wrote:
> On Thu, Oct 16, 2008 at 04:20:32PM -0400, Nicolas Pitre wrote:
>
> > > so almost all my git repositories are still using a symlink HEAD.
> > > I have some old scripts That I use occasionally and still depend on it.
> > > Using detached checkout is the only problem I've had.
> >
> > A symlink HEAD and detached checkouts are simply incompatible.
>
> Agreed, but I think the complaint is not that it doesn't work, but that
> it silently clobbers the current branch when you try it.
That is unacceptable indeed.
Nicolas
^ permalink raw reply
* Re: Feedback outside of the user survey
From: Christian Jaeger @ 2008-10-16 20:32 UTC (permalink / raw)
To: Richard Hartmann; +Cc: Garry Dolley, git
In-Reply-To: <2d460de70810160618u1803375aj913145a5060e5308@mail.gmail.com>
Richard Hartmann wrote:
> On Thu, Oct 16, 2008 at 13:56, Garry Dolley <gdolley@arpnetworks.com> wrote:
>
>
>> I know from an external point of view, it seems pulling a subdir
>> wouldn't be a big deal; but if you look at git internals, you start
>> to realize why it's an option that isn't on the table.
>>
Hm, I don't see a fundamental technical problem which would prevent one
from implementing the ability to checkout only a subdirectory into the
working directory (i.e. to add options to Git to make it reflect the
working directory as being a subdirectory of what is in Git's database).
At this level I don't see anything inherently different from SVN--except
maybe for directory renames: if someone else is renaming the directory
you've checked out, what should happend with your checkout? Git's
filebased rename tracking would just lead to everything vanishing from
your checkout. I don't know what happens in SVN, maybe it keeps track of
the directory rename and still sends you the changes of the directory
you've checked out even if it has now a different name on the server?
Anyway, an unavoidable difference is that you have to always clone the
whole Git *database*. With SVN the database stays on the server, with
Git it is being cloned. Just as I expect SVN to need the whole database
to be able to work (tracking renames across directories etc.), Git needs
the whole database too. So implementing subdirectory workingdir
checkouts wouldn't help reduce the bandwidth and storage necessary for
getting at the database.
>
> That's my understanding as well. And you can simply branch
> out a subdir when you want to work on it.
>
I guess what you are referring to is
$ git clone git://foo.com/bar.git
$ cd bar
$ rm -rf *
$ git checkout somesubdir
Now you've got only somesubdir/ below bar/. This solves the rename
problem insofar, as somesubdir will just be renamed if someone else
commits a "git mv somesubdir somethingelse" and you pull that change.
But there's also another caveat: "git status" will of course report the
other files as deleted, which is an accident waiting to happen when you
next run "git commit -a".
(In any case, this is just thinking louder than I deserve, as there's no
code at all in Git written by me.)
Christian.
^ permalink raw reply
* Re: Detached checkout will clobber branch head when using symlink HEAD
From: Jeff King @ 2008-10-16 20:39 UTC (permalink / raw)
To: Matt Draisey; +Cc: Junio C Hamano, git
In-Reply-To: <1224187863.2796.15.camel@localhost>
On Thu, Oct 16, 2008 at 04:11:03PM -0400, Matt Draisey wrote:
> I am using the following system defaults:
>
> core.prefersymlinkrefs=true
> gc.packrefs=false
>
> so almost all my git repositories are still using a symlink HEAD.
> I have some old scripts That I use occasionally and still depend on it.
> Using detached checkout is the only problem I've had.
In your position I would consider updating my scripts. But I guess you
could also try to work up a patch that makes detached HEAD work
(replacing the symlink with a file, then bringing back the symlink when
you're on a branch). In the meantime, here is a cleaned-up version of my
patch, with a proper commit message and a test.
-- >8 --
do not clobber symlinked ref with detached HEAD
The default configuration for git uses a symref for HEAD.
When we detach the HEAD, we can simply write the detached
commit sha1 into the HEAD file.
It is still possible to use symlinks for HEAD (either by
setting it up manually, or by using core.prefersymlinkrefs).
In that case, moving to a detached HEAD is impossible, since
we have nowhere to store the sha1.
However, the current code doesn't realize this and actually
writes into the HEAD file anyway, meaning that it overwrites
the value of the currently checked out branch.
Instead, let's detect in the locking mechanism that we have
a symlink but the caller requested that we lock the original
ref name instead of its linked destination. This has two
advantages:
- we don't have to add an extra stat call, since we
discover the symlink during normal ref resolution
- any code to update a ref should lock it, meaning that we
should catch any other similar instances
Signed-off-by: Jeff King <peff@peff.net>
---
refs.c | 9 ++++++++-
refs.h | 1 +
t/t7202-checkout-symlink.sh | 19 +++++++++++++++++++
3 files changed, 28 insertions(+), 1 deletions(-)
create mode 100755 t/t7202-checkout-symlink.sh
diff --git a/refs.c b/refs.c
index b680750..b4b3865 100644
--- a/refs.c
+++ b/refs.c
@@ -446,8 +446,11 @@ const char *resolve_ref(const char *ref, unsigned char *sha1, int reading, int *
buffer[len] = 0;
strcpy(ref_buffer, buffer);
ref = ref_buffer;
- if (flag)
+ if (flag) {
+ if (!(*flag & REF_ISSYMREF))
+ *flag |= REF_OUTER_IS_SYMLINK;
*flag |= REF_ISSYMREF;
+ }
continue;
}
}
@@ -817,6 +820,10 @@ static struct ref_lock *lock_ref_sha1_basic(const char *ref, const unsigned char
}
ref = resolve_ref(orig_ref, lock->old_sha1, mustexist, &type);
}
+ if (type & REF_OUTER_IS_SYMLINK && flags & REF_NODEREF) {
+ error("unable to directly lock symbolic link '%s'", orig_ref);
+ goto error_return;
+ }
if (type_p)
*type_p = type;
if (!ref) {
diff --git a/refs.h b/refs.h
index 06ad260..9b0dcd9 100644
--- a/refs.h
+++ b/refs.h
@@ -12,6 +12,7 @@ struct ref_lock {
#define REF_ISSYMREF 01
#define REF_ISPACKED 02
+#define REF_OUTER_IS_SYMLINK 04
/*
* Calls the specified function for each ref file until it returns nonzero,
diff --git a/t/t7202-checkout-symlink.sh b/t/t7202-checkout-symlink.sh
new file mode 100755
index 0000000..cf09f5f
--- /dev/null
+++ b/t/t7202-checkout-symlink.sh
@@ -0,0 +1,19 @@
+#!/bin/sh
+
+test_description='checkout with symlinked HEAD'
+. ./test-lib.sh
+
+test_expect_success 'setup' '
+ echo one > file && git add file && git commit -m one &&
+ echo two > file && git add file && git commit -m two &&
+ ln -sf refs/heads/master .git/HEAD
+'
+
+test_expect_success 'checkout detached HEAD does not clobber ref' '
+ test_must_fail git checkout HEAD^ &&
+ echo two >expect &&
+ git log -1 --pretty=tformat:%s >actual
+ test_cmp actual expect
+'
+
+test_done
--
1.6.0.2.711.gf1ba4.dirty
^ permalink raw reply related
* Re: Rebasing Multiple branches at once...
From: Toby Allsopp @ 2008-10-16 20:27 UTC (permalink / raw)
To: git; +Cc: Rick Moynihan
In-Reply-To: <48F730D0.9040008@calicojack.co.uk>
[-- Attachment #1: Type: text/plain, Size: 1017 bytes --]
On Fri, Oct 17 2008, Rick Moynihan wrote:
> Hi,
>
> I have a master branch, a dev branch and a number of feature branches
> from dev. And I was wondering if there was an easy way to rebase dev
> and all of it's sub-branches onto master.
>
> I know I can run this as a series of commands, and use --onto to do
> this, but was wondering if there was an easier way. As running:
>
> git rebase master
>
> when on the dev branch only rebases dev and not it's dependent
> branches.
I have a Perl script I use to rebase a number of topic branches as the
remote tracking branches they're based on move. It handles the case of
topic based on other topics. It is designed specifically for my
workflow, which is tracking a central Subversion repository using
git-svn, but I don't think it relies on using git-svn. Anyway, you
might find it useful for inspiration.
The script outputs a sequence of commands and leaves the running of them
up to you because you may need to resolve conflicts at any point.
Regards,
Toby.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: git-rebase-branches --]
[-- Type: text/x-perl, Size: 2748 bytes --]
#!/usr/bin/perl
# Rebases master and everything based on master to the new trunk. Use
# after a git-svn-fetch.
use strict;
use warnings;
use Getopt::Long;
use List::Util qw(first);
use Git;
my $dry_run;
GetOptions("dry-run|n" => \$dry_run)
or die "usage error";
sub ref2branch {
my $ref = shift;
$ref =~ s,^refs/heads/,,
or die "Not a branch: '$ref'";
return $ref;
}
my $repo = Git->repository();
my %remotes_by_name;
my %remotes_by_hash;
my %remote_revs;
for ($repo->command('for-each-ref', 'refs/remotes')) {
my ($hash, undef, $ref) = split;
$remotes_by_name{$ref} = $hash;
$remotes_by_hash{$hash} = $ref;
$remote_revs{$ref} = [$repo->command('rev-list', $ref)];
}
my %heads_by_name;
my %heads_by_hash;
for ($repo->command('for-each-ref', 'refs/heads')) {
my ($hash, undef, $ref) = split;
$heads_by_name{$ref} = $hash;
$heads_by_hash{$hash} = $ref;
}
my %roots;
my %heads_by_parent;
for my $head (sort keys %heads_by_name) {
#print STDERR "Considering $head\n";
my $parent;
my $last_rev;
for my $rev ($repo->command('rev-list', $head, '--not', keys %remotes_by_name)) {
my $maybe_parent = $heads_by_hash{$rev};
if ($maybe_parent && $maybe_parent ne $head) {
#print STDERR " found parent $maybe_parent\n";
$parent = $maybe_parent;
last;
}
$last_rev = $rev;
}
if ($parent) {
push @{$heads_by_parent{$parent}}, $head;
} elsif ($last_rev) {
my $remote_base = $repo->command_oneline('rev-parse', "$last_rev^");
my @remotes;
#print STDERR " last rev $last_rev $remote_base\n";
for my $remote_name (sort keys %remotes_by_name) {
my $remote = first { $_ eq $remote_base } @{$remote_revs{$remote_name}};
if (defined($remote) && $remote eq $remote_base) {
#print STDERR " found remote $remote_name\n";
push @remotes, $remote_name;
}
}
if (@remotes == 1) {
$roots{$head} = $remotes[0];
} else {
print STDERR "WARNING: Not exactly one candidate remote for $head: ",
join(' ', @remotes), "\n";
}
}
}
for my $root (sort keys %roots) {
my $remote = $roots{$root};
my $short_root = ref2branch($root);
$remote =~ s,^refs/,,;
print "git rebase $remote $short_root\n";
rebase_tree($root);
}
sub rebase_tree {
my ($parent) = @_;
for my $head (@{$heads_by_parent{$parent}}) {
my $short_parent = ref2branch($parent);
my $short_head = ref2branch($head);
print "git rebase --onto $short_parent $heads_by_name{$parent} $short_head\n";
rebase_tree($head);
}
}
^ permalink raw reply
* Re: Working with remotes; cloning remote references
From: Peter Harris @ 2008-10-16 20:45 UTC (permalink / raw)
To: Marc Branchaud; +Cc: git
In-Reply-To: <48F7A42E.70200@xiplink.com>
On Thu, Oct 16, 2008 at 4:29 PM, Marc Branchaud wrote:
> Peter Harris wrote:
>>
>> "git clone" doesn't have this option, but you can turn it on
>> immediately after with something similar to:
>> git config --add remote.origin.fetch +refs/remotes/*:refs/remotes/*
>> (which I use for fanning-out my git-svn repos)
>
> Thanks for the pointer (and the quick reply).
>
> That doesn't seem to be what I'm looking for, though -- perhaps I'm missing
> something? The above puts the remotes in the .git/refs/remotes directory,
> but the .git/config file doesn't have them.
Ah. I believe I misunderstood what you wanted. Perhaps you want "git
remote add", then? Unfortunately, you have to know what your remotes
are outside of git for this. Perhaps a script in the root of your
repository you can run to set this up after the initial clone?
I seem to recall some discussion of allowing a .gitconfig to be in
repositories (similar to .gitignore), but the idea was shot down for
security reasons.
> (As an aside, the above "git config --add" incantation causes problems if
> run inside a clone of a clone:
>
> You did say "something similar" in your reply -- am I not seeing something
> obvious?
I said "something similar" because you probably actually want
git config --add remote.$remote.fetch +refs/remotes/*:refs/remotes/$remote/*
(or other names of your own choosing) so that multiple remote remotes
don't stomp on each other.
Unless you want to be able to address the remotes by name, in which
case you want "git remote add" instead (see above).
Peter Harris
^ permalink raw reply
* Re: Detached checkout will clobber branch head when using symlink HEAD
From: Nicolas Pitre @ 2008-10-16 20:47 UTC (permalink / raw)
To: Matt Draisey; +Cc: Jeff King, Junio C Hamano, git
In-Reply-To: <1224188939.2796.22.camel@localhost>
On Thu, 16 Oct 2008, Matt Draisey wrote:
> On Thu, 2008-10-16 at 16:20 -0400, Nicolas Pitre wrote:
> > A symlink HEAD and detached checkouts are simply incompatible.
>
> Not necessarily. The symlinking code will unlink the original inode
> each time it creates a new symlink anyway. It is simply a matter of
> creating a new file in its place.
True. I didn't think it all through initially.
Nicolas
^ permalink raw reply
* Re: Rebasing Multiple branches at once...
From: Miklos Vajna @ 2008-10-16 21:00 UTC (permalink / raw)
To: Rick Moynihan; +Cc: git
In-Reply-To: <48F7542B.1050909@calicojack.co.uk>
[-- Attachment #1: Type: text/plain, Size: 602 bytes --]
On Thu, Oct 16, 2008 at 03:48:11PM +0100, Rick Moynihan <rick@calicojack.co.uk> wrote:
> Yes, but my understanding is that it's only harmful if you publish the
> branch (or dependent branches) which are being rebased.
>
> So rebasing is very bad in these circumstances, but I fail to see why it's
> bad if these branches are kept private.
Ah, I thought you publish your branches.
One reason may be that if you use merge, no history is lost, if you use
rebase, history is in the reflogs, so it'll be lost after some time. But
if you know what you are doing, then this is not a problem.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 1/7] gitk: Enhance UI popup and accelerator handling.
From: Paul Mackerras @ 2008-10-16 21:55 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: git
In-Reply-To: <1223449540-20457-2-git-send-email-angavrilov@gmail.com>
Alexander Gavrilov writes:
> - Popups are supposed to be marked transient, otherwise
> the WM creates them in strange places. Besides, at
> least under kwin, transients are automatically kept
> above their parent.
I agree with most of the places where you add wm transient commands,
but in the case of the list of references (showrefs), I think of that
as a long-lived window that one would normally place beside the main
window. (In fact, it should be a pane in the main window, but I
couldn't think of a place for it. Maybe I should split the
bottom-right pane in two.)
So I don't think the wm transient in showrefs is what we want.
Comments?
Paul.
^ permalink raw reply
* Re: [PATCH 1/7] gitk: Enhance UI popup and accelerator handling.
From: Alexander Gavrilov @ 2008-10-16 22:08 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <18679.47194.852924.385301@cargo.ozlabs.ibm.com>
On Fri, Oct 17, 2008 at 1:55 AM, Paul Mackerras <paulus@samba.org> wrote:
> Alexander Gavrilov writes:
>> - Popups are supposed to be marked transient, otherwise
>> the WM creates them in strange places. Besides, at
>> least under kwin, transients are automatically kept
>> above their parent.
>
> I agree with most of the places where you add wm transient commands,
> but in the case of the list of references (showrefs), I think of that
> as a long-lived window that one would normally place beside the main
> window. (In fact, it should be a pane in the main window, but I
> couldn't think of a place for it. Maybe I should split the
> bottom-right pane in two.)
>
> So I don't think the wm transient in showrefs is what we want.
> Comments?
On the other hand, wm transient makes it always stay on top of the
main window. If the main window is maximized, it is useful.
Btw, gitk probably should not save its geometry if the window is
maximized, because when it is started again the window is too large.
Alexander
^ permalink raw reply
* Re: Working with remotes; cloning remote references
From: Marc Branchaud @ 2008-10-16 22:09 UTC (permalink / raw)
To: Peter Harris; +Cc: git
In-Reply-To: <eaa105840810161345r69c9f05j66bb850085f561e7@mail.gmail.com>
Peter Harris wrote:
>
> Ah. I believe I misunderstood what you wanted. Perhaps you want "git
> remote add", then? Unfortunately, you have to know what your remotes
> are outside of git for this. Perhaps a script in the root of your
> repository you can run to set this up after the initial clone?
I think we're converging onto the same track.
Yes, I do want to use "git remote add". My point is basically that,
having done various git-remote-adds in the main repository, I'd like to
avoid having to redo them in a clone of that repository.
A script would work, sure, but to me this seems like something git
should handle for me. If I have to re-establish my connections to the
remotes whenever I want to pull in updates, then I don't see much point
in keeping the remotes defined in any git repo.
> I seem to recall some discussion of allowing a .gitconfig to be in
> repositories (similar to .gitignore), but the idea was shot down for
> security reasons.
I think I can understand why that would be undesirable, but I don't know
if something like that would be necessary for what I'm talking about.
Marc
^ 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