* [PATCH 2/2] gitweb: add section support to gitweb project listing.
From: Gustavo Sverzut Barbieri @ 2008-07-29 2:34 UTC (permalink / raw)
To: git; +Cc: gitster, Gustavo Sverzut Barbieri
In-Reply-To: <1217298868-16513-2-git-send-email-barbieri@profusion.mobi>
Section headers will be optionally displayed when projects dirnames or
owner names changes (depending on sort order), making it easier to
find projects in large setups.
Signed-off-by: Gustavo Sverzut Barbieri <barbieri@profusion.mobi>
---
gitweb/gitweb.css | 7 +++++
gitweb/gitweb.perl | 73 +++++++++++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 79 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.css b/gitweb/gitweb.css
index aa0eeca..44abc4c 100644
--- a/gitweb/gitweb.css
+++ b/gitweb/gitweb.css
@@ -235,6 +235,13 @@ tr.dark:hover {
background-color: #edece6;
}
+tr.section td {
+ background-color: #d9d8d1;
+ border-top: 1px solid #000000;
+ border-left: 1px solid #000000;
+ font-weight: bold;
+}
+
td {
padding: 2px 5px;
font-size: 100%;
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index c5675cf..c99cea3 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -15,7 +15,7 @@ use CGI::Carp qw(fatalsToBrowser);
use Encode;
use Fcntl ':mode';
use File::Find qw();
-use File::Basename qw(basename);
+use File::Basename qw(basename dirname);
binmode STDOUT, ':utf8';
BEGIN {
@@ -82,6 +82,9 @@ our $projects_list_description_width = 25;
# valid values are none, project, descr, owner, and age
our $default_projects_order = "project";
+# use sections to separate projects by dirname, helps usability
+our $use_sections = 1;
+
# show repository only if this file exists
# (only effective if this variable evaluates to true)
our $export_ok = "++GITWEB_EXPORT_OK++";
@@ -3631,6 +3634,66 @@ sub print_sort_th_num {
print_sort_th(0, @_);
}
+sub print_section_tr {
+ my ($n_cols, $section) = @_;
+ print "<tr class=\"section\"><td colspan=\"$n_cols\">$section</td></tr>\n";
+}
+
+sub print_section_internal {
+ my ($order, $n_cols, $current, $getter) = @_;
+ my $current_value = $getter->($current);
+
+ if (!$current_value) {
+ return 0;
+ }
+
+ my $last_value = '';
+ if ($current > 0) {
+ $last_value = $getter->($current - 1);
+ }
+
+ if ($current_value ne $last_value) {
+ print_section_tr($n_cols, $current_value);
+ return 1;
+ }
+
+ return 0;
+}
+
+sub print_section_project {
+ my ($order, $n_cols, $current, $projects) = @_;
+
+ sub get_section_project {
+ my ($index) = @_;
+ return dirname(@$projects[$index]->{'path'});
+ }
+
+ return print_section_internal($order, $n_cols, $current, \&get_section_project);
+}
+
+sub print_section_owner {
+ my ($order, $n_cols, $current, $projects) = @_;
+
+ sub get_section_owner {
+ my ($index) = @_;
+ return @$projects[$index]->{'owner'};
+ }
+
+ return print_section_internal($order, $n_cols, $current, \&get_section_owner);
+}
+
+sub print_section {
+ my ($order, $n_cols, $current, $projects) = @_;
+
+ if ($order eq 'project') {
+ return print_section_project($order, $n_cols, $current, $projects);
+ } elsif ($order eq 'owner') {
+ return print_section_owner($order, $n_cols, $current, $projects);
+ }
+
+ return 0;
+}
+
sub git_project_list_body {
my ($projlist, $order, $from, $to, $extra, $no_header) = @_;
@@ -3658,9 +3721,17 @@ sub git_project_list_body {
print "<th></th>\n" . # for links
"</tr>\n";
}
+ my $n_cols = $check_forks ? 6 : 5;
my $alternate = 1;
for (my $i = $from; $i <= $to; $i++) {
my $pr = $projects[$i];
+
+ if ($use_sections) {
+ if (print_section($order, $n_cols, $i, \@projects)) {
+ $alternate = 1;
+ }
+ }
+
if ($alternate) {
print "<tr class=\"dark\">\n";
} else {
--
1.5.5.2
^ permalink raw reply related
* Re: [PATCH] Make use of stat.ctime configurable
From: Junio C Hamano @ 2008-07-29 2:49 UTC (permalink / raw)
To: David Brown
Cc: Linus Torvalds, Alex Riesen, Johannes Schindelin, Johannes Sixt,
git
In-Reply-To: <20080729014120.GA26807@old.davidb.org>
David Brown <git@davidb.org> writes:
> On Mon, Jul 28, 2008 at 06:31:24PM -0700, Junio C Hamano wrote:
>>Linus Torvalds <torvalds@linux-foundation.org> writes:
>>
>>> The kernel does caching really well, and the kernel is fast as
>>> hell, so _of_course_ when you benchmark, using kernel data
>>> structures looks good, especially if you benchmark against code
>>> that isn't well written for the particular usage case.
>>
>>Ok. While I have your attention on st_ctime, let me ask you a stupid
>>question. Why does "rename(old, new)" change st_ctime when you move a
>>regular file?
>
> A simple answer might be that posix requires it.
I would understand that an obvious implementation would be to link to new
and then unlink the old, and the link count of the moved entity needs to
change (although in the end, the increment and decrement would cancel out)
in each step, so it would be convenient for the implementation to update
ctime in both steps; however my reading of POSIX does not seem to require
it.
The only mention of ctime I find is about updating the parent directories
of old and new, as contents of both change so do their mtime and ctime
obviously need to change. But it does not talk about ctime of the entity
being moved.
Additionally, the only way rename(2) is described to fail with EMLINK is
when renaming an directory and the parent of the new location cannot have
any more links; which implies that it does not have to fail if the first
step of link+unlink overflows the link count of old.
Ah, I found in the informative Application Usage section that this is
implementation dependent.
Sorry for the noise.
^ permalink raw reply
* Re: Bizarre missing changes (git bug?)
From: Roman Zippel @ 2008-07-29 2:59 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Tim Harper, git
In-Reply-To: <alpine.LFD.1.10.0807272148030.3486@nehalem.linux-foundation.org>
Hi,
On Sun, 27 Jul 2008, Linus Torvalds wrote:
> You don't actually understand how git works, do you?
Probably not and to be honest I don't care, all I want is my history - the
correct one. All I know it's in there somehow and all I care is how to get
it out of there.
Right now you're giving me the choice between a crappy incomplete history
or a crappy history full of useless information. That's it? As long as
your challenge involves being compared to crappy history, I'm not
interested. If the solution should involve a switch "--correct-history"
or I have to wait for the result, I don't care, because it's the correct
history I want. As long as you're trying to sell me crappy history I'm not
buying it.
Can we please get past this and look at what is required to produce the
correct history?
Fact is based on the current git-log output it's simply impossible to
produce the correct history without reading the whole history first, since
the very last commit can still be relevant for an earlier merge to connect
it properly into the graph. This means we need some extra information
before even starting to scan through the commits. Luckily this information
can be cached once it has been generated and it also can be updated
incrementally. E.g. this information could be generated while generating
the pack, so you only had to scan the commits which haven't been packed
yet, but it's also possible to update it when merging/pulling new data.
It's also not much information that is needed, all that is needed is list
of commits per file (which are are usually only a few, mostly even none),
which git-log can use, so it knows that these are important while scanning
the tree.
Technically I don't see a really hard problem to implement this, the
problem for me is only that I have no idea where to start this within git
and how to integrate it. The other problem (over which I have absolutely
no control) is whether anyone actually wants to produce a correct history.
I hope there is someone, otherwise there would be no need for "git-log
--full-history" (which is also used by git-web), this e.g. produces a nice
example in kernel/printk.c, where git-web produces two commits (search for
tty_write_message), for which none of the front ends can tell me usefully
how it fits into the history (they either don't show it at all or it's
lost in "gitk --full-history").
bye, Roman
^ permalink raw reply
* Re: Bizarre missing changes (git bug?)
From: Martin Langhoff @ 2008-07-29 3:15 UTC (permalink / raw)
To: Roman Zippel; +Cc: Linus Torvalds, Tim Harper, git
In-Reply-To: <Pine.LNX.4.64.0807281241180.6791@localhost.localdomain>
On Tue, Jul 29, 2008 at 2:59 PM, Roman Zippel <zippel@linux-m68k.org> wrote:
> Can we please get past this and look at what is required to produce the
> correct history?
Roman - correct is --full-history -- any simplification that makes it
easy on your eyes *is* a simplification. And consumers that want to do
nice user-friendly simplification like gitk does can hang off the data
stream.
> it's also possible to update it when merging/pulling new data.
If that's what you want to do, you can prototype it with a hook on
fetch and commit. That is definitely an area that hasn't been explored
- what nicer (but expensive) views on the history we have can be
afforded by pre-computing things on fetch and commit hooks.
cheers,
m
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* Re: Bizarre missing changes (git bug?)
From: Linus Torvalds @ 2008-07-29 3:29 UTC (permalink / raw)
To: Roman Zippel; +Cc: Tim Harper, git
In-Reply-To: <Pine.LNX.4.64.0807281241180.6791@localhost.localdomain>
On Tue, 29 Jul 2008, Roman Zippel wrote:
>
> Right now you're giving me the choice between a crappy incomplete history
> or a crappy history full of useless information. That's it? As long as
> your challenge involves being compared to crappy history, I'm not
> interested.
No, my challenges have not been about "crappy history" but about
performance and about getting it right. The reason I pointed you to
lib/vsprintf.c had nothing to do with crappiness, and had everythign to do
with just picking a random example of something where you absolutely
*HAVE* to simplify history.
The fact that it simplifies to a linear one is totally immaterial. You
continue to miss the point. Over and over AND OVER again!
> Can we please get past this and look at what is required to produce the
> correct history?
I'm not even going to bother with this argument.
You dismiss all my issues, and then you continue to talk about "correct",
even though it isn't a correctness thing - it's a difference of opinion.
Me, I *much* prefer the simplified history. That _is_ the correct one for
me.
And the sad part is, what you want is there. It's a command line switch
away. You were told in the very first message what the switch was. If you
don't want to use "--full-history", you can actually use "git whatchanged"
instead of "git log", and it implies the switch without you even having to
type it.
So it's all there. Use it. Just don't bother adding me to the cc to your
inane flames, because I'm fed up with the fact that you can't actually be
bothered to read my emails, and just want to flame.
And quite frankly, I've seen that behaviour from you before, when it comes
to other things. So go away. Write the code. Come back with patches. In
the meantime, we've told you what to do: use --full-history if you really
want it.
Linus
^ permalink raw reply
* Re: Bizarre missing changes (git bug?)
From: Linus Torvalds @ 2008-07-29 3:33 UTC (permalink / raw)
To: Roman Zippel; +Cc: Tim Harper, git
In-Reply-To: <alpine.LFD.1.10.0807282023290.3334@nehalem.linux-foundation.org>
On Mon, 28 Jul 2008, Linus Torvalds wrote:
>
> And quite frankly, I've seen that behaviour from you before, when it comes
> to other things. So go away. Write the code. Come back with patches. In
> the meantime, we've told you what to do: use --full-history if you really
> want it.
Btw, if you really do end up wanting to actually do something about it, I
can already tell you that trying to do so in "git log" isn't going to be
useful. Do it in "gitk" instead, and make gitk simplify the --full-history
output.
I tried to explain to you the why part earlier (go back and look for
"incremental" and "topo-sort"), but it all seemed to fly right by you, and
you started repeating your ranting instead.
IOW, put up or shut up.
Linus
^ permalink raw reply
* [PATCH 1/2 v2] gitweb: sort projects by path.
From: Gustavo Sverzut Barbieri @ 2008-07-29 3:59 UTC (permalink / raw)
To: git; +Cc: gitster, Gustavo Sverzut Barbieri
In-Reply-To: <1217298868-16513-2-git-send-email-barbieri@profusion.mobi>
Projects are paths, so they should be sorted in pieces, not as a
whole, so a/x will be come before a-b/x.
Signed-off-by: Gustavo Sverzut Barbieri <barbieri@profusion.mobi>
---
New version that fix cmp_paths. Unlike I though initially, $#list
reports the last element index, not the list length. Nonetheless the
last component must be compared only if the list lengths are the same,
otherwise we'll get $root/a/a.git before $root/b.git and sections will
look ugly (group elements of the same level together).
gitweb/gitweb.perl | 42 +++++++++++++++++++++++++++++++++++++-----
1 files changed, 37 insertions(+), 5 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 90cd99b..06c9901 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3574,17 +3574,45 @@ sub fill_project_list_info {
return @projects;
}
+sub cmp_paths {
+ my ($a, $b) = @_;
+ my @la = split('/', $a);
+ my @lb = split('/', $b);
+ my $last;
+
+ if ($#la < $#lb) {
+ $last = $#la;
+ } else {
+ $last = $#lb;
+ }
+
+ for (my $i = 0; $i < $last; $i++) {
+ my $r = $la[$i] cmp $lb[$i];
+ if ($r != 0) {
+ return $r;
+ }
+ }
+
+ if ($#la == $#lb) {
+ return $la[$last] cmp $lb[$last];
+ } else {
+ return $#la <=> $#lb;
+ }
+}
+
# print 'sort by' <th> element, either sorting by $key if $name eq $order
# (changing $list), or generating 'sort by $name' replay link otherwise
sub print_sort_th {
- my ($str_sort, $name, $order, $key, $header, $list) = @_;
+ my ($sort_mode, $name, $order, $key, $header, $list) = @_;
$key ||= $name;
$header ||= ucfirst($name);
if ($order eq $name) {
- if ($str_sort) {
+ if ($sort_mode == 2) {
+ @$list = sort {cmp_paths($a->{$key}, $b->{$key})} @$list;
+ } elsif ($sort_mode == 1) {
@$list = sort {$a->{$key} cmp $b->{$key}} @$list;
- } else {
+ } elsif ($sort_mode == 0) {
@$list = sort {$a->{$key} <=> $b->{$key}} @$list;
}
print "<th>$header</th>\n";
@@ -3596,6 +3624,10 @@ sub print_sort_th {
}
}
+sub print_sort_th_path {
+ print_sort_th(2, @_);
+}
+
sub print_sort_th_str {
print_sort_th(1, @_);
}
@@ -3620,8 +3652,8 @@ sub git_project_list_body {
if ($check_forks) {
print "<th></th>\n";
}
- print_sort_th_str('project', $order, 'path',
- 'Project', \@projects);
+ print_sort_th_path('project', $order, 'path',
+ 'Project', \@projects);
print_sort_th_str('descr', $order, 'descr_long',
'Description', \@projects);
print_sort_th_str('owner', $order, 'owner',
--
1.5.5.2
^ permalink raw reply related
* Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy
From: Jeff King @ 2008-07-29 4:31 UTC (permalink / raw)
To: sverre; +Cc: Johannes Schindelin, Git Mailinglist, Miklos Vajna
In-Reply-To: <bd6139dc0807281709u43218e97p8ba239f3e520e10@mail.gmail.com>
On Tue, Jul 29, 2008 at 02:09:18AM +0200, Sverre Rabbelier wrote:
> > If the result should become the state of 'x', too, I would then just
> > 'git push origin y:x'.
>
> But this means that everybody doing a 'git pull' on that repo will get
> complaints when pulling, right? Should they just send out a message to
> all their users that they'll need to rebase all their changes now?
> (Not being sarcastic, am trying to work out what the recommended
> workflow is here.)
I think you are missing the fact that he is doing this push _after_
having merged the history into master via "-s ours". So it is a
fast-forward to push at that point.
-Peff
^ permalink raw reply
* Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy
From: Jeff King @ 2008-07-29 4:38 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: sverre, Git Mailinglist, Miklos Vajna
In-Reply-To: <alpine.DEB.1.00.0807290123300.2725@eeepc-johanness>
On Tue, Jul 29, 2008 at 01:27:44AM +0200, Johannes Schindelin wrote:
> > So the logical sequence was:
> >
> > git checkout production
> > git merge -s theirs master
>
> To me, this suggests that they were too married to 'production' being the
> "dominant" branch.
Perhaps. But I see this as an operation on the production branch: "pull
in master's changes, forgetting ours". In your workflow (git checkout
master && git merge -s ours production && git push origin
master:production) we perform an operation on master, which doesn't seem
as intuitive to me.
Not to mention that we might not _control_ master. What about (and I
think Sverre mentioned something like this previously):
I forked the kernel and made some changes. Some of my changes got
applied upstream. The others are now obsolete. Now I want to bring
myself in sync with Linus, but I want to keep my history (either
because the history is interesting to me, or because others are basing
their work on it).
Then your workflow, while still possible within the local repository,
means you are munging the "linus" branch, which seems wrong. That branch
is probably even just a tracking branch, which you would not want to
build on, anyway.
-Peff
^ permalink raw reply
* Re: [PATCH] Modify mingw_main() workaround to avoid link errors
From: Steffen Prohaska @ 2008-07-29 4:46 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Junio C Hamano
In-Reply-To: <1217186640.488ccb50a934a@webmail.nextra.at>
On Jul 27, 2008, at 9:24 PM, Johannes Sixt wrote:
> Zitat von Steffen Prohaska <prohaska@zib.de>:
>
>>
>> On Jul 26, 2008, at 10:37 PM, Johannes Sixt wrote:
>>
>>> Zitat von Steffen Prohaska <prohaska@zib.de>:
>>>> With MinGW's
>>>>
>>>> gcc.exe (GCC) 3.4.5 (mingw special)
>>>> GNU ld version 2.17.50 20060824
>>>>
>>>> the old define caused link errors:
>>>>
>>>> git.o: In function `main':
>>>> C:/msysgit/git/git.c:500: undefined reference to `mingw_main'
>>>> collect2: ld returned 1 exit status
>>>>
>>>> The modified define works.
>>>
>>> I have the same tools, but not this error. ???
>>
>> I cleaned my work tree and built several times but did not
>> find out what exactly is causing the error. So I came up
>> with the modified define, which declares the static
>> mingw_main in global scope. I have no clue why I see the
>> error that you don't have.
>
> Neither do I. But a strange line number you have there. In 01d9b2d
> (from
> mingw.git) I have 'exit(1)' in line 500 of git.c.
I have the same in line 500. I am still wondering what this could
mean. But I do not yet now :-(
Steffen
^ permalink raw reply
* [trivial fast-export PATCH] Fix typo in documentation
From: Nick Andrew @ 2008-07-29 4:50 UTC (permalink / raw)
To: git
Fix typo in documentation
"hg-fast-import" should be "hg-fast-export" everywhere it is used.
Signed-off-by: Nick Andrew <nick@nick-andrew.net>
---
hg-fast-export.txt | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/hg-fast-export.txt b/hg-fast-export.txt
index 1b8bb1c..ede56a9 100644
--- a/hg-fast-export.txt
+++ b/hg-fast-export.txt
@@ -1,4 +1,4 @@
-hg-fast-import.(sh|py) - mercurial to git converter using git-fast-import
+hg-fast-export.(sh|py) - mercurial to git converter using git-fast-import
Legal
=====
@@ -16,7 +16,7 @@ Using hg-fast-export is quite simple for a mercurial repository <repo>:
mkdir repo-git # or whatever
cd repo-git
git init
- hg-fast-import.sh -r <repo>
+ hg-fast-export.sh -r <repo>
Incremental imports to track hg repos is supported, too.
@@ -31,7 +31,7 @@ again.
Notes/Limitations
=================
-hg-fast-import supports multiple branches but only named branches with exaclty
+hg-fast-export supports multiple branches but only named branches with exactly
one head each. Otherwise commits to the tip of these heads within branch
will get flattened into merge commits.
@@ -42,11 +42,11 @@ when importing a small number of changesets per incremental import).
Design
======
-hg-fast-import.py was designed in a way that doesn't require a 2-pass mechanism
+hg-fast-export.py was designed in a way that doesn't require a 2-pass mechanism
or any prior repository analysis: if just feeds what it finds into
git-fast-import. This also implies that it heavily relies on strictly
linear ordering of changesets from hg, i.e. its append-only storage
-model so that changesets hg-fast-import already saw never get modified.
+model so that changesets hg-fast-export already saw never get modified.
Todo
====
^ permalink raw reply related
* Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy
From: Jeff King @ 2008-07-29 5:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, sverre, Git Mailinglist, Miklos Vajna
In-Reply-To: <7vsktto78y.fsf@gitster.siamese.dyndns.org>
On Mon, Jul 28, 2008 at 05:37:33PM -0700, Junio C Hamano wrote:
> I sense a slightly broken workflow here, whether the "-s theirs" strategy
> is used or the merge is done in the other direction using "-s ours"
> strategy.
>
> Remember, when you create a merge commit between one history and another,
> you are making this statement:
>
> I have looked at the tree state and the development history behind
> both of these commits, and came up with this tree, which I believe
> suits the purpose of _my_ history better than either of them.
Right, that is precisely what I wanted to say. These are the histories
of the devel and stable branches, and now they both are the contents of
stable. In this case, "I have looked at all of the commits in stable
that were _not_ in devel, and confirmed that they have moral equivalents
in devel".
> That is why, after making such a merge with "git merge other", you won't
> see any output from "git log ..other", which asks "what do I have yet to
> merge?" Everything that was included in other is now in your history and
> there is nothing you have to worry about having left out anymore.
Right, that is just what I wanted.
> So if you suspect that the sutuation "in case those fixes needed to be
> looked at later" ever arises, such a merge should *not* be recorded as a
> proper merge on the 'stable' branch, because at that point when you are
> doing that "-s theirs" merge (and this applies equally to the case where
> you make "-s ours" merge as well), you actually have not looked at "those
> fixes" closely enough to make the above statement with confidence.
No, I had looked at them with confidence. I just didn't want history
thrown away for two reasons:
- historical interest; some of the commits had counterparts in devel
that were done differently (because the two branches had diverged),
but it might later be interesting to see how and why the stable
changes were done (e.g., if a similar situation arose)
- this project did not rebase, favoring the simplicity of "git pull"
over clean history.
Bear in mind that this project was not very big. I think devel had ~20
commits, and stable had about ~5. So it was easy to get such confidence.
> Even though having said all of the above, I would actually prefer such a
> "pull all of the devel down to stable" be done with this workflow instead:
>
> (1) go to 'devel';
> (2) merge all of 'stable';
> (3) look at the result and prove it is perfect;
> (4) go to 'stable';
> (5) merge 'devel'.
>
> The last step would be a fast-forward, and you do not need "-s theirs"
> anywhere in this procedure. Step (2) can be helped with "-s ours" (which
> have the same issue I discussed above), but the result is checked before
> it hits the 'stable' (presumably more precious branch), which is
> conceptually a big difference. This is where the existing asymmetry
> between theirs and ours comes from.
Of course you can do this (and that is, in fact, exactly what I did).
But there is no point discussing "what hits stable" since neither branch
is precious. All of this is happening in a private repo that nobody is
looking at. So it really is a case of thinking about it as "devel
subsumes stable, and then stable becomes devel" versus "stable is
discarded in favor of master".
I think both are equally valid ways of looking at what is happening. The
only differences will be:
- the commit message will be reversed ("Merge X into Y"). And this
really comes down to "how would I want to see this presented in 3
months when I look at it?". And either is valid, depending on how you
think of the problem (but I think in both cases, you owe it to
future readers to write a bit of text saying _why_ such a strategy
was OK to use).
- the parents will be swapped. Using "-s theirs" should let you ask
"what changes did I make on my stable branch" using
"--first-parent". I don't know how useful that is, as I don't
actively work on that project anymore.
-Peff
^ permalink raw reply
* Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy
From: Jeff King @ 2008-07-29 5:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: sverre, Johannes Schindelin, Git Mailinglist, Miklos Vajna
In-Reply-To: <7vvdyppv4c.fsf@gitster.siamese.dyndns.org>
On Mon, Jul 28, 2008 at 02:16:35PM -0700, Junio C Hamano wrote:
> The quoted sentence by me in that message was after I explained why "per
> hunk theirs" aka "-Xtheirs" was not such a great idea I further went on to
> say "by the way, '-s theirs' is even worse and here is why".
Your reason was "it keeps your crap in the history". And while I
generally am in favor of getting rid of crap and keeping a clean
history, I think it is very much dependent on the individual project's
preferences. IOW, that history might not contain "crap" but rather
now-obsolete changes that are of historical interest.
But I do agree that -Xtheirs is crap. ;)
-Peff
^ permalink raw reply
* Re: [Fundamental problem with relative system paths] [PATCH 2/2] run-command (Windows): Run dashless "git <cmd>"
From: Steffen Prohaska @ 2008-07-29 5:15 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Junio C Hamano, Johannes Schindelin, Shawn O. Pearce
In-Reply-To: <1217277453.488e2e0db0f41@webmail.nextra.at>
On Jul 28, 2008, at 10:37 PM, Johannes Sixt wrote:
> Zitat von Steffen Prohaska <prohaska@zib.de>:
>
>> This might solve a fundamental problem we have with the
>> computation of system directories based on relative paths
>> in combination with the new gitexecpath 'libexec/git-core'.
>> The problem is that the program 'git' is hardlinked to
>> directories with different depth. It is either used as
>> 'bin/git' (1 directory) or as 'libexec/git-core/git-*'
>> (2 directories). Thus, using the same relative path
>> in system_path() yields different results when starting from the
>> two locations. I recognized the problem because /etc/gitconfig
>> is no longer be read.
>>
>> The patch below might fix the problem by always calling 'bin/git'
>> for builtin commands. The computation in system_path() would
>> always start from 'bin' and thus yields predictable results. I
>> am not sure however if it fully solves the problem because other
>> code paths might run the dashed forms directly.
>
> This paragraph should go into the commit message.
I'll send an updated patch including a commit message defending
the change more offensively.
>> I think the only way to verify correctness would be to stop
>> installing the dashed forms for builtins. If they were not
>> installed they could not be called. The only entry point for all
>> builtins would be 'bin/git'. I don't think we want to stop
>> installing the dashed forms right away.
>>
>> So what shall we do?
>
> Your patches make a lot of sense.
Unfortunately, I am sure that they do not solve the problem fully, even
if we removed the dashed forms completely. I'll send a second patch
that
modifies the Makefile to stop installing the BUILT_INS. It might be
useful for debugging.
Steffen
^ permalink raw reply
* Re: git-scm.com
From: Shawn O. Pearce @ 2008-07-29 5:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Tom Werner, git
In-Reply-To: <7vk5f5ptwu.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > Also note that one of the major gripe with you making money off of Git
> > could be the following: we have over 500 contributors, and most of them --
> > first and foremost of all, the two major contributors, Junio and Shawn --
> > cannot make money from Git. Envy is wrong, but it is real.
>
> I do not talk for Shawn, but I think that comment misses the mark by a
> large margin, at least for me.
I'm glad you guys think so highly of my contributions, but I am
only a small cog in the big machine known as "git". I just happen
to like very-fine grained commits for any changes, which skews my
commit count upwards a bit. There are _many_ contributors in that
"Primary Authors" list on git-scm.com who deserve attention too. :)
> I haven't been in this for money. The original motivation of my
> involvement was to help sending Linus back to the kernel as quickly as
> possible, but now I primarily do this for fun. Doing it for money would
> risk removing the fun factor.
>
> What I personally lack right now is time and mental bandwidth.
Well, here you could have spoken for me I think. I do git because
I find it fun, rewarding, and challenging. Though these days it
has been a little bit more work and a little bit less fun-challenge
as I am plowing through code for egit, but its a labor of love.
My contributions to Git are also about giving back, in return for
the benefit I have gained over the years from using Linux, and the
thousands of other open source packages that make it all work.
I'm not big on kernel hacking (though I did try it for about 6
months) so this is one way I can put a few pennys back in the open
source take-a-penny/leave-a-penny penny jar.
More recently I may be in a position where my new employer might
be able to make some contribution to the community through part of
my time. I shall see if it winds up detracting from the fun aspect
of it for me. Personally I tend to get so focused on something that
I have a very hard time moving away from it, and just want to focus
on that one thing and do it well. Doing it at day-job may make
that easier, and reduce stress on me, in turn making it more fun.
> [...] Corporate sponsors that can pay back in money but not in
> patches may be able to find other ways to help us, but I do not offhand
> know what's the most effective way for them to do so if they wanted to.
I don't know how much kernel.org needs support, but we rely heavily
on kernel.org for our main distribution site of git. Its a drop
in the bucket compared to the Linux kernel activity itself, but I
imagine that the right sort of Linux-friendly (and Git-friendly)
corporate sponsor could really help kernel.org out. Of course only
so much help is really useful, and I have no idea what kernel.org's
financial (and staff time) situtation is like, so I'll shut up now.
Pasky's repo.or.cz is another huge area that the community relies
upon. Fortunately Pasky has been able to offer its services freely,
but in the future it may reach a point where corporate support
for adminstration assitance, duct-tape development, bandwidth or
hardware, may be extremely beneficial.
--
Shawn.
^ permalink raw reply
* [FOR DEBUGGING] Stop installing BUILT_INS
From: Steffen Prohaska @ 2008-07-29 5:17 UTC (permalink / raw)
To: Johannes Sixt
Cc: git, Junio C Hamano, Johannes Schindelin, Shawn O. Pearce,
Steffen Prohaska
In-Reply-To: <1217308647-23673-1-git-send-email-prohaska@zib.de>
---
Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index b2bc0ef..e416ec7 100644
--- a/Makefile
+++ b/Makefile
@@ -1366,7 +1366,7 @@ endif
ln -f "$$bindir/git$X" "$$execdir/git$X" || \
cp "$$bindir/git$X" "$$execdir/git$X"; \
fi && \
- { $(foreach p,$(BUILT_INS), $(RM) "$$execdir/$p" && ln "$$execdir/git$X" "$$execdir/$p" ;) } && \
+ { $(foreach p,$(BUILT_INS), $(RM) "$$execdir/$p" ;) } && \
$(RM) "$$execdir/git$X" && \
./check_bindir "z$$bindir" "z$$execdir" "$$bindir/git-add$X"
--
1.6.0.rc0.79.gb0320
^ permalink raw reply related
* [PATCH 2/2 v2] run-command (Windows): Run dashless "git <cmd>" (solves part of problem with system_path)
From: Steffen Prohaska @ 2008-07-29 5:17 UTC (permalink / raw)
To: Johannes Sixt
Cc: git, Junio C Hamano, Johannes Schindelin, Shawn O. Pearce,
Steffen Prohaska
In-Reply-To: <BF5B7CBE-ACA8-4D81-8FC0-8A7901205854@zib.de>
We prefer running the dashless form, so we should use it in MinGW's
start_command(), too.
This solves a fundamental problem we have with the computation of system
directories based on relative paths in combination with the new
gitexecpath 'libexec/git-core'. The problem is that the program 'git'
is hardlinked to directories with different depth. It is either used as
'bin/git' (1 directory) or as 'libexec/git-core/git-*' (2 directories).
Thus, using the same relative path in system_path() yields different
results when starting from the two locations. I recognized the problem
because /etc/gitconfig is no longer read.
This commit fixes the problem by always calling 'bin/git' for builtin
commands. The computation in system_path() thus always starts from
'bin' and yields predictable results. This is however only part of a
full solution to the problem outlined above. Remaining problems are:
- Other code paths might run the dashed forms directly.
- We have non-builtins that are implemented in C, e.g. fast-import.c.
These non-builtins will still compute wrong paths.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Acked-by: Johannes Sixt <johannes.sixt@telecom.at>
---
run-command.c | 11 ++++-------
1 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/run-command.c b/run-command.c
index 6e29fdf..a3b28a6 100644
--- a/run-command.c
+++ b/run-command.c
@@ -119,9 +119,8 @@ int start_command(struct child_process *cmd)
}
#else
int s0 = -1, s1 = -1, s2 = -1; /* backups of stdin, stdout, stderr */
- const char *sargv0 = cmd->argv[0];
+ const char **sargv = cmd->argv;
char **env = environ;
- struct strbuf git_cmd;
if (cmd->no_stdin) {
s0 = dup(0);
@@ -165,9 +164,7 @@ int start_command(struct child_process *cmd)
}
if (cmd->git_cmd) {
- strbuf_init(&git_cmd, 0);
- strbuf_addf(&git_cmd, "git-%s", cmd->argv[0]);
- cmd->argv[0] = git_cmd.buf;
+ cmd->argv = prepare_git_cmd(cmd->argv);
}
cmd->pid = mingw_spawnvpe(cmd->argv[0], cmd->argv, env);
@@ -175,9 +172,9 @@ int start_command(struct child_process *cmd)
if (cmd->env)
free_environ(env);
if (cmd->git_cmd)
- strbuf_release(&git_cmd);
+ free(cmd->argv);
- cmd->argv[0] = sargv0;
+ cmd->argv = sargv;
if (s0 >= 0)
dup2(s0, 0), close(s0);
if (s1 >= 0)
--
1.6.0.rc0.79.gb0320
^ permalink raw reply related
* Re: [RFC/PATCH v3] merge-base: teach "git merge-base" to accept more than 2 arguments
From: Christian Couder @ 2008-07-29 5:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin, Miklos Vajna, Jakub Narebski
In-Reply-To: <7vabg2wovf.fsf@gitster.siamese.dyndns.org>
Le lundi 28 juillet 2008, Junio C Hamano a écrit :
> Christian Couder <chriscool@tuxfamily.org> writes:
>
> > +static struct commit *get_commit_reference(const char *arg)
> > +{
> > + unsigned char revkey[20];
> > + if (get_sha1(arg, revkey))
> > + die("Not a valid object name %s", arg);
> > + return lookup_commit_reference(revkey);
> > +}
>
> This returns a NULL when you feed a tree to the command, and...
>
> > int cmd_merge_base(int argc, const char **argv, const char *prefix)
> > {
> > + struct commit **rev;
> > int show_all = 0;
> > + int rev_nr = 0;
> >
> > git_config(git_default_config, NULL);
> >
> > @@ -38,15 +48,18 @@ int cmd_merge_base(int argc, const char **argv,
> > const char *prefix) usage(merge_base_usage);
> > argc--; argv++;
> > }
> > + if (argc < 3)
> > usage(merge_base_usage);
> > +
> > + rev = xmalloc((argc - 1) * sizeof(*rev));
> > +
> > + do {
> > + struct commit *r = get_commit_reference(argv[1]);
> > + if (!r)
> > + return 1;
>
> ... the command silently exits with 1.
In "master" there is:
rev1 = lookup_commit_reference(rev1key);
rev2 = lookup_commit_reference(rev2key);
if (!rev1 || !rev2)
return 1;
return show_merge_base(rev1, rev2, show_all);
so I think you found a bug in the current code.
I will post a patch to fix it soon.
It will "die" (with an error ùmessage) in case "lookup_commit_reference"
returns NULL. I hope it's ok.
Thanks,
Christian.
^ permalink raw reply
* [FOR DEBUGGING] Stop installing BUILT_INS
From: Steffen Prohaska @ 2008-07-29 5:19 UTC (permalink / raw)
To: Johannes Sixt
Cc: git, Junio C Hamano, Johannes Schindelin, Shawn O. Pearce,
Steffen Prohaska
In-Reply-To: <1217308784-25408-1-git-send-email-prohaska@zib.de>
---
Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index b2bc0ef..e416ec7 100644
--- a/Makefile
+++ b/Makefile
@@ -1366,7 +1366,7 @@ endif
ln -f "$$bindir/git$X" "$$execdir/git$X" || \
cp "$$bindir/git$X" "$$execdir/git$X"; \
fi && \
- { $(foreach p,$(BUILT_INS), $(RM) "$$execdir/$p" && ln "$$execdir/git$X" "$$execdir/$p" ;) } && \
+ { $(foreach p,$(BUILT_INS), $(RM) "$$execdir/$p" ;) } && \
$(RM) "$$execdir/git$X" && \
./check_bindir "z$$bindir" "z$$execdir" "$$bindir/git-add$X"
--
1.6.0.rc0.79.gb0320
^ permalink raw reply related
* [PATCH 2/2 v2] run-command (Windows): Run dashless "git <cmd>" (solves part of problem with system_path)
From: Steffen Prohaska @ 2008-07-29 5:19 UTC (permalink / raw)
To: Johannes Sixt
Cc: git, Junio C Hamano, Johannes Schindelin, Shawn O. Pearce,
Steffen Prohaska
In-Reply-To: <766FEC61-619E-4A13-A21B-0734D83074C5@zib.de>
We prefer running the dashless form, so we should use it in MinGW's
start_command(), too.
This solves a fundamental problem we have with the computation of system
directories based on relative paths in combination with the new
gitexecpath 'libexec/git-core'. The problem is that the program 'git'
is hardlinked to directories with different depth. It is either used as
'bin/git' (1 directory) or as 'libexec/git-core/git-*' (2 directories).
Thus, using the same relative path in system_path() yields different
results when starting from the two locations. I recognized the problem
because /etc/gitconfig is no longer read.
This commit fixes the problem by always calling 'bin/git' for builtin
commands. The computation in system_path() thus always starts from
'bin' and yields predictable results. This is however only part of a
full solution to the problem outlined above. Remaining problems are:
- Other code paths might run the dashed forms directly.
- We have non-builtins that are implemented in C, e.g. fast-import.c.
These non-builtins will still compute wrong paths.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Acked-by: Johannes Sixt <johannes.sixt@telecom.at>
---
run-command.c | 11 ++++-------
1 files changed, 4 insertions(+), 7 deletions(-)
My previous mail was in the wrong thread. Apologies. This one
will be correctly threaded.
Steffen
diff --git a/run-command.c b/run-command.c
index 6e29fdf..a3b28a6 100644
--- a/run-command.c
+++ b/run-command.c
@@ -119,9 +119,8 @@ int start_command(struct child_process *cmd)
}
#else
int s0 = -1, s1 = -1, s2 = -1; /* backups of stdin, stdout, stderr */
- const char *sargv0 = cmd->argv[0];
+ const char **sargv = cmd->argv;
char **env = environ;
- struct strbuf git_cmd;
if (cmd->no_stdin) {
s0 = dup(0);
@@ -165,9 +164,7 @@ int start_command(struct child_process *cmd)
}
if (cmd->git_cmd) {
- strbuf_init(&git_cmd, 0);
- strbuf_addf(&git_cmd, "git-%s", cmd->argv[0]);
- cmd->argv[0] = git_cmd.buf;
+ cmd->argv = prepare_git_cmd(cmd->argv);
}
cmd->pid = mingw_spawnvpe(cmd->argv[0], cmd->argv, env);
@@ -175,9 +172,9 @@ int start_command(struct child_process *cmd)
if (cmd->env)
free_environ(env);
if (cmd->git_cmd)
- strbuf_release(&git_cmd);
+ free(cmd->argv);
- cmd->argv[0] = sargv0;
+ cmd->argv = sargv;
if (s0 >= 0)
dup2(s0, 0), close(s0);
if (s1 >= 0)
--
1.6.0.rc0.79.gb0320
^ permalink raw reply related
* Re: [PATCHv2] git-mv: Keep moved index entries inact
From: Junio C Hamano @ 2008-07-29 5:23 UTC (permalink / raw)
To: Petr Baudis; +Cc: Johannes Schindelin, SZEDER Gábor, git
In-Reply-To: <7vod4ho6uq.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Petr Baudis <pasky@suse.cz> writes:
>
>> On Mon, Jul 28, 2008 at 12:19:19PM -0700, Junio C Hamano wrote:
>>> We need to refresh the entry to pick up potential ctime changes.
>>>
>>> read-cache.c | 7 ++++++-
>>> builtin-ls-files.c | 21 +++++++++++++++------
>>> 2 files changed, 21 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/read-cache.c b/read-cache.c
>>> index 1cae361..834096f 100644
>>
>> Oops, silly me. Sorry for being slower than you at fixing this. ;-)
>
> I did think about ctime issues when I applied the patch.
Actually I changed my mind.
I think it is wrong for something as low-level as rename_index_entry_at()
to unconditionally look at the working tree and try refreshing the entry.
The next caller of this function may not even require a working tree.
I think Dscho is correct; expecting the saved cacheinfo to stay fresh
across rename does not make much sense. What we care about with "git mv"
is that we keep what the user staged, i.e. kind of blob and the contents.
It cannot be guaranteed if the index entry is stat clean or not, as
st_ctime may or may not be updated across rename(2) according to POSIX.
So let's do this instead.
-- >8 --
t7001: fix "git mv" test
The test assumed that we can keep the cached stat information fresh across
rename(2); many filesystems however update st_ctime (and POSIX allows them
to do so), so that assumption does not hold. We can explicitly refresh
the index for the purpose of the test, as the only thing we are interested
in is the staged contents and the mode bits are preserved across "mv".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
t/t7001-mv.sh | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/t/t7001-mv.sh b/t/t7001-mv.sh
index b0fa407..910a28c 100755
--- a/t/t7001-mv.sh
+++ b/t/t7001-mv.sh
@@ -185,6 +185,7 @@ test_expect_success 'git mv should overwrite symlink to a file' '
! test -e moved &&
test -f symlink &&
test "$(cat symlink)" = 1 &&
+ git update-index --refresh &&
git diff-files --quiet
'
@@ -202,6 +203,7 @@ test_expect_success 'git mv should overwrite file with a symlink' '
git mv -f symlink moved &&
! test -e symlink &&
test -h moved &&
+ git update-index --refresh &&
git diff-files --quiet
'
^ permalink raw reply related
* Re: [PATCH 2/2 v2] run-command (Windows): Run dashless "git <cmd>" (solves part of problem with system_path)
From: Shawn O. Pearce @ 2008-07-29 5:24 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Johannes Sixt, git, Junio C Hamano, Johannes Schindelin
In-Reply-To: <1217308647-23673-1-git-send-email-prohaska@zib.de>
Steffen Prohaska <prohaska@zib.de> wrote:
> We prefer running the dashless form, so we should use it in MinGW's
> start_command(), too.
...
> - We have non-builtins that are implemented in C, e.g. fast-import.c.
> These non-builtins will still compute wrong paths.
This feels wrong to me. fast-import probably won't be adversly
impacted by not being able to read /etc/gitconfig, unless the user
has set something like core.deltaBaseCacheLimit and is doing an
incremental import. But other non-builtins may be impacted.
It feels like we're fixing this in the wrong place. If the issue
is we don't find our installation directory correctly, we should
find our installation directory correctly, not work around it by
calling builtins through the git wrapper.
Though I can see where it may be a good idea to at some point
in the future (git 1.7?) stop creating the redundant builtin
links under libexec/git-core.
--
Shawn.
^ permalink raw reply
* Re: [Fundamental problem with relative system paths] [PATCH 2/2] run-command (Windows): Run dashless "git <cmd>"
From: Junio C Hamano @ 2008-07-29 5:29 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Steffen Prohaska, git, Johannes Schindelin, Shawn O. Pearce
In-Reply-To: <1217277453.488e2e0db0f41@webmail.nextra.at>
Johannes Sixt <johannes.sixt@telecom.at> writes:
> Zitat von Steffen Prohaska <prohaska@zib.de>:
> ...
>> The patch below might fix the problem by always calling 'bin/git'
>> for builtin commands. The computation in system_path() would
>> always start from 'bin' and thus yields predictable results. I
>> am not sure however if it fully solves the problem because other
>> code paths might run the dashed forms directly.
>
> This paragraph should go into the commit message.
> ...
> Your patches make a lot of sense.
I was almost going to suggest doing this everywhere not just on Windows,
but execv_git_cmd() on the POSIX side already runs "git" wrapper, so this
patch makes them in line, finally.
>> -- 8< --
>> We prefer running the dashless form, so we should use it in
>> MinGW's start_command(), too.
>>
>> Signed-off-by: Steffen Prohaska <prohaska@zib.de>
>
> Acked-by: Johannes Sixt <johannes.sixt@telecom.at>
>
> -- Hannes
^ permalink raw reply
* Re: Bizarre missing changes (git bug?)
From: Jeff King @ 2008-07-29 5:31 UTC (permalink / raw)
To: Roman Zippel; +Cc: Linus Torvalds, Tim Harper, git
In-Reply-To: <Pine.LNX.4.64.0807281241180.6791@localhost.localdomain>
On Tue, Jul 29, 2008 at 04:59:01AM +0200, Roman Zippel wrote:
> Right now you're giving me the choice between a crappy incomplete history
> or a crappy history full of useless information. That's it? As long as
> your challenge involves being compared to crappy history, I'm not
> interested. If the solution should involve a switch "--correct-history"
> or I have to wait for the result, I don't care, because it's the correct
> history I want. As long as you're trying to sell me crappy history I'm not
> buying it.
>
> Can we please get past this and look at what is required to produce the
> correct history?
You seem to be indicating here (and elsewhere in the thread) that there
exists some history graph for which neither "git log" nor "git log
--full-history" produces the output you want, but that there is some
better output (even if it might take more time to compute).
Perhaps I am just slow, but I haven't been able to figure out what that
history is, or what the "correct" output should be. Can you try to state
more clearly what it is you are looking for?
-Peff
^ permalink raw reply
* Re: Hackontest ideas?
From: Shawn O. Pearce @ 2008-07-29 5:31 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Petr Baudis, git
In-Reply-To: <20080729001016.GT32057@genesis.frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> wrote:
> On Tue, Jul 29, 2008 at 02:01:03AM +0200, Petr Baudis <pasky@ucw.cz> wrote:
> >
> > (What feature in Git or a Git-related tool would you implement, given 24
> > hours staight and unlimited pizza supply?)
>
> Restartable git-clone? :-)
>
> It was a GSoC idea this year, but in the end nobody started working on
> it.
>
> (I was about to work on it, but finally my 'builtin-merge' application
> was accepted.)
Yea, we eventually decided it was probably too small for a
GSoC project. Given how quickly you put together your git-merge
project, I'm actually happy we got you working on git-merge and
not restartable clone, as I think you may have finished restartable
clone in 24 hours and then said "now what mr. mentor?" ;-)
Pasky, et.al.:
How about smart fetch/push over HTTP? E.g. a CGI (or extension to
gitweb) that does native pack transport over HTTP rather than dumb
object traversal with GET and WebDAV LOCK/PUT. Note that the push
side doesn't need to support tell-me-more extension, making it a
fairly trivial GET, POST (or PUT) sequence.
--
Shawn.
^ 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