* Re: [PATCH 1/4] git-gui i18n: Add more words to glossary.
From: Johannes Schindelin @ 2007-10-07 23:31 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Christian Stimming, git
In-Reply-To: <20071007231231.GD2137@spearce.org>
Hi,
On Sun, 7 Oct 2007, Shawn O. Pearce wrote:
> If you are sending a series like that and its all po translation stuff
> that is unlikely to need commenting on feel free to just dump it all out
> as a single mbox (`git format-patch --stdout`) and attach it to the
> email. Less chance of the MUA mangling the message.
In this case, I suggest just pushing it to git-gui-i18n.git, maybe as a
temporary branch "for-shawn", and send a pull request. That's the best
way to ensure that nothing gets mangled.
Ciao,
Dscho
P.S.: Yeah, I haven't been really good with i18n recently; will try to put
more work into it soon.
^ permalink raw reply
* Re: Trying to use git-filter-branch to compress history by removing large, obsolete binary files
From: Elijah Newren @ 2007-10-07 23:38 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Frank Lichtenheld, git
In-Reply-To: <Pine.LNX.4.64.0710080028301.4174@racer.site>
Hi,
On 10/7/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Sun, 7 Oct 2007, Elijah Newren wrote:
<snip>
> > $ git clone test test2
> > <snip>
> > $ du -hs test
> > 11M test
> > $ du -hs test2
> > 11M test2
> >
> > Any other ideas?
>
> Yep. Maybe it is necessary to run "git gc" in test2.
Sweet, finally solved! That brings test2 down to 340K.
However, the solution seems somewhat involved...it requires running
git-filter-branch, git reset, removing the .git/refs/original/
directory, editing .git/packed-refs in some editor, running git reflog
expire, cloning the resulting repository, and running git gc yet
again. It seems like there has to be an easier way. (Anyone have
one?)
Oh, and git-filter-branch could really use some explanatory note about
how to actually complete rewriting the history.
Thanks,
Elijah
^ permalink raw reply
* StGit kha experimental branch updated
From: Karl Hasselström @ 2007-10-07 23:39 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20071007232943.GA1262@diana.vm.bytemark.co.uk>
There's nothing new here; it's all just rebased on top of the updated
safe branch. In order, we have
* David's patches that remove the "top" and "bottom" patch fields.
These need a format version upgrade function (trivial), but are
otherwise ready, I think.
* David's conflict refactoring series, with some fixes by me, and
removal of some commands that become superfluous. Almost ready,
but it makes ugly conflict markers, and "stg resolved" should
probably be removed.
The following changes since commit 2299c463794f214b750ecc33e24779243ddc5aff:
Karl Hasselström (1):
Make "stg refresh" subdirectory safe
are available in the git repository at:
git://repo.or.cz/stgit/kha.git experimental
David Kågedal (9):
Check bottom and invariants
Remove the 'bottom' field
Remove the 'top' field
Split git.merge into two functions
Leave working dir and index alone after failed (conflicting) push
Added a test case to check what happens when push finds a conflict
Simplify merge_recursive
Use the output from merge-recursive to list conflicts
Ask git about unmerged files
Karl Hasselström (9):
Better error message if merge fails
Fix "stg resolved" to work with new conflict representation
Refactoring: pass more than one file to resolved()
We keep the different stages of a conflict in the index now
Clean up the logic in "stg resolved"
"stg status --reset" is not needed anymore
Remove "stg add"
Remove "stg rm"
Remove "stg cp"
Documentation/stg-cp.txt | 63 --------------------------
Documentation/tutorial.txt | 22 +++++----
stgit/commands/add.py | 44 ------------------
stgit/commands/common.py | 25 +++-------
stgit/commands/copy.py | 45 ------------------
stgit/commands/pick.py | 2 +-
stgit/commands/resolved.py | 70 ++++++++++-------------------
stgit/commands/rm.py | 48 --------------------
stgit/commands/status.py | 34 +++++---------
stgit/commands/sync.py | 1 -
stgit/git.py | 72 +++++++++++++++++------------
stgit/gitmergeonefile.py | 99 ++++++++++++++++++++++------------------
stgit/main.py | 6 ---
stgit/run.py | 3 +
stgit/stack.py | 65 +++++++++++----------------
t/t0002-status.sh | 11 +++--
t/t1200-push-modified.sh | 2 +-
t/t1202-push-undo.sh | 4 +-
t/t1203-push-conflict.sh | 70 +++++++++++++++++++++++++++++
t/t1204-pop-keep.sh | 2 +-
t/t1205-push-subdir.sh | 4 +-
t/t1300-uncommit.sh | 4 +-
t/t1301-assimilate.sh | 2 +-
t/t1400-patch-history.sh | 4 +-
t/t1500-float.sh | 14 +++---
t/t1600-delete-one.sh | 12 +++---
t/t1601-delete-many.sh | 2 +-
t/t1700-goto-top.sh | 2 +-
t/t2000-sync.sh | 8 ++--
t/t2100-pull-policy-fetch.sh | 4 +-
t/t2101-pull-policy-pull.sh | 4 +-
t/t2102-pull-policy-rebase.sh | 4 +-
t/t2300-refresh-subdir.sh | 2 +-
33 files changed, 295 insertions(+), 459 deletions(-)
delete mode 100644 Documentation/stg-cp.txt
delete mode 100644 stgit/commands/add.py
delete mode 100644 stgit/commands/copy.py
delete mode 100644 stgit/commands/rm.py
create mode 100755 t/t1203-push-conflict.sh
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH 1/4] git-gui i18n: Add more words to glossary.
From: Shawn O. Pearce @ 2007-10-07 23:39 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Christian Stimming, git
In-Reply-To: <Pine.LNX.4.64.0710080029430.4174@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Sun, 7 Oct 2007, Shawn O. Pearce wrote:
>
> > If you are sending a series like that and its all po translation stuff
> > that is unlikely to need commenting on feel free to just dump it all out
> > as a single mbox (`git format-patch --stdout`) and attach it to the
> > email. Less chance of the MUA mangling the message.
>
> In this case, I suggest just pushing it to git-gui-i18n.git, maybe as a
> temporary branch "for-shawn", and send a pull request. That's the best
> way to ensure that nothing gets mangled.
Yea, that's an even better option. :-)
--
Shawn.
^ permalink raw reply
* Re: [StGit PATCH 4/8] Don't split long and short description in "stg edit"
From: David Brown @ 2007-10-07 23:40 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Catalin Marinas, git
In-Reply-To: <20071007231735.12626.81744.stgit@yoghurt>
On Mon, Oct 08, 2007 at 01:17:35AM +0200, Karl Hasselström wrote:
>"stg edit" used to present the patch information like this:
>
> Short description
>
> From: ...
> Date: ...
>
> Long description
>
>If the project follows the git convention with a single-line short
>description and follwed by a blank line and the rest of the
>description, this merely looks a little odd. However, for projects
>that don't follow that convention, presenting the first line
>separately is actively inconvenient; for example, it breaks emacs's
>fill-paragraph command.
I think this fix is better to begin with. I found it especially confusing
when there was only a single line commit message. Now the header looks
like a header :-)
David
^ permalink raw reply
* Re: Trying to use git-filter-branch to compress history by removing large, obsolete binary files
From: Alex Riesen @ 2007-10-07 23:40 UTC (permalink / raw)
To: Elijah Newren; +Cc: Frank Lichtenheld, git
In-Reply-To: <51419b2c0710071524q16e9c593s2722dffc826e560d@mail.gmail.com>
Elijah Newren, Mon, Oct 08, 2007 00:24:49 +0200:
> On 10/7/07, Alex Riesen <raa.lkml@gmail.com> wrote:
> > rm -rf .git/refs/original/refs/heads/<the branch where HEAD pointed to>
> > (assuming you haven't repacked yet)
> >
> > or just edit .git/packed-refs and remove everything "refs/original"
> > which fits the criteria
> >
> > > So...how do I fix the reflog, and then repack to have a
> > > pack under 11MB in size?
> >
> > git reflog expire --all (it is a bit to much. You can just edit
> > .git/logs/* in any text editor)
>
> So...
>
> $ du -hs .
> 11M .
> $ rm -rf .git/refs/original/
> $ vi .git/packed-refs
> # Remove the line referring to refs/original...
> $ git reflog expire --all
> $ git gc --aggressive --prune
> $ du -hs .
> 11M .
>
> It's still 11MB.
>
> Any other ideas?
you missed something. Your example compresses to about 124k.
^ permalink raw reply
* Re: Trying to use git-filter-branch to compress history by removing large, obsolete binary files
From: Dmitry Potapov @ 2007-10-07 23:43 UTC (permalink / raw)
To: Elijah Newren; +Cc: Alex Riesen, Frank Lichtenheld, git
In-Reply-To: <51419b2c0710071524q16e9c593s2722dffc826e560d@mail.gmail.com>
On Sun, Oct 07, 2007 at 04:24:49PM -0600, Elijah Newren wrote:
> $ git reflog expire --all
> $ git gc --aggressive --prune
I believe this should work:
git reflog expire --all --expire-unreachable=0
git gc --prune
Warning: all unreachable references will be removed!
Dmitry
^ permalink raw reply
* Re: Trying to use git-filter-branch to compress history by removing large, obsolete binary files
From: Elijah Newren @ 2007-10-08 0:09 UTC (permalink / raw)
To: Alex Riesen; +Cc: Frank Lichtenheld, git
In-Reply-To: <20071007234039.GH2765@steel.home>
On 10/7/07, Alex Riesen <raa.lkml@gmail.com> wrote:
> you missed something. Your example compresses to about 124k.
What version of git are you running? I reran all the steps to which
you responded (repeated below for clarity) with git-1.5.3.3 and still
get 11MB. Also, you must have different filesystem extents than me
since an empty git repo takes 196k here[1], so I don't think any repo
is going to get down to 124k.
My understanding of the steps you suggest would work:
# Make a small repo
mkdir test
cd test
git init
echo hi > there
git add there
git commit -m 'Small repo'
# Add a random 10M binary file
dd if=/dev/urandom of=testme.txt count=10 bs=1M
git add testme.txt
git commit -m 'Add big binary file'
# Remove the 10M binary file
git rm testme.txt
git commit -m 'Remove big binary file'
# Compress the repo, see how big the repo is
git gc --aggressive --prune
du -ks . # 10548K
du -ks .git # 10532K
# Try to rewrite history to remove the binary file
git-filter-branch --tree-filter 'rm -f testme.txt' HEAD
git reset --hard
# Try to recompress and clean up, then check the new size
git gc --aggressive --prune
du -ks . # 10580K !?!?!?
du -ks .git # 10564K
# Do the stuff Alex suggests to trim the history
rm -rf .git/refs/original/
vi .git/packed-refs
# Use vi to remove the line referring to refs/original...
git reflog expire --all
git gc --aggressive --prune
du -ks . # Still 10564K
Thanks,
Elijah
[1] An empty git repo takes 196k for me, as can be seen by:
$mkdir tmp
$cd tmp
$git init
$du -hs .
196K .
^ permalink raw reply
* Re: Trying to use git-filter-branch to compress history by removing large, obsolete binary files
From: Elijah Newren @ 2007-10-08 0:22 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Alex Riesen, Frank Lichtenheld, git
In-Reply-To: <20071007234346.GA29433@potapov>
On 10/7/07, Dmitry Potapov <dpotapov@gmail.com> wrote:
> On Sun, Oct 07, 2007 at 04:24:49PM -0600, Elijah Newren wrote:
> > $ git reflog expire --all
> > $ git gc --aggressive --prune
>
> I believe this should work:
>
> git reflog expire --all --expire-unreachable=0
> git gc --prune
Yes, this seems to work. So the history-rewriting steps are
git-filter-branch --tree-filter 'rm -f testme.txt' HEAD
git reset --hard
rm -rf .git/refs/original/
vi .git/packed-refs
# Use vi to remove the line referring to refs/original...
git reflog expire --all --expire-unreachable=0
git gc --prune
Seems like a wrapper is needed. :-)
> Warning: all unreachable references will be removed!
What other scenarios could lead to unreachable references? I don't
know how to determine whether this is safe or not (except that these
were test repositories anyway, so I don't care what happens to them).
Thanks!
Elijah
^ permalink raw reply
* Re: Trying to use git-filter-branch to compress history by removing large, obsolete binary files
From: Johannes Schindelin @ 2007-10-08 0:34 UTC (permalink / raw)
To: Elijah Newren; +Cc: Frank Lichtenheld, git
In-Reply-To: <51419b2c0710071638p6dcc0c7cm2a813c22758e6f32@mail.gmail.com>
Hi,
On Sun, 7 Oct 2007, Elijah Newren wrote:
> On 10/7/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On Sun, 7 Oct 2007, Elijah Newren wrote:
> <snip>
> > > $ git clone test test2
> > > <snip>
> > > $ du -hs test
> > > 11M test
> > > $ du -hs test2
> > > 11M test2
> > >
> > > Any other ideas?
> >
> > Yep. Maybe it is necessary to run "git gc" in test2.
>
> Sweet, finally solved! That brings test2 down to 340K.
>
> However, the solution seems somewhat involved...it requires running
> git-filter-branch, git reset, removing the .git/refs/original/
> directory, editing .git/packed-refs in some editor, running git reflog
> expire, cloning the resulting repository, and running git gc yet again.
> It seems like there has to be an easier way. (Anyone have one?)
It should be as easy as git filter-branch and git clone.
> Oh, and git-filter-branch could really use some explanatory note about
> how to actually complete rewriting the history.
It does what it should do. It is _your_ task to look at refs/original/*
if everything went alright. Then you just delete the checked refs.
What made your case so cumbersome was that you wanted the big objects out
_now_, instead of having them in for a grace period. BTW this grace
period is in place to help _you_, not the program. (In case you fscked up
and need those objects back.)
Ciao,
Dscho
^ permalink raw reply
* Re: Trying to use git-filter-branch to compress history by removing large, obsolete binary files
From: Elijah Newren @ 2007-10-08 0:47 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Frank Lichtenheld, git
In-Reply-To: <Pine.LNX.4.64.0710080129480.4174@racer.site>
On 10/7/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> It should be as easy as git filter-branch and git clone.
Yes, a git filter-branch, git clone, AND git gc in the clone avoids
all those funny ref editing commands. However, cloning a 5.6GB repo
(the size of one of the real repos I'm dealing with) will likely take
a long time (and may push me past the limits of disk space), so using
other steps to avoid the need to clone actually seems nicer.
> > Oh, and git-filter-branch could really use some explanatory note about
> > how to actually complete rewriting the history.
>
> It does what it should do. It is _your_ task to look at refs/original/*
> if everything went alright. Then you just delete the checked refs.
>
> What made your case so cumbersome was that you wanted the big objects out
> _now_, instead of having them in for a grace period. BTW this grace
> period is in place to help _you_, not the program. (In case you fscked up
> and need those objects back.)
Sure, I think that's a sane default. And I think it's fine that it
should be my task to look at the refs to check that everything worked
okay and delete them. But it's nearly impossible to figure out how to
do that! _That_ is my complaint. I got multiple misleading or
incomplete answers (both on this list and in #git) before getting some
working solutions, so this task is obviously far from trivial. I
really think that adding instructions about how to check and delete
the relevant refs would be a very useful addition to the
documentation.
Thanks everyone for the help!
Elijah
^ permalink raw reply
* Re: Trying to use git-filter-branch to compress history by removing large, obsolete binary files
From: J. Bruce Fields @ 2007-10-08 1:00 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Elijah Newren, Frank Lichtenheld, git
In-Reply-To: <Pine.LNX.4.64.0710080129480.4174@racer.site>
On Mon, Oct 08, 2007 at 01:34:07AM +0100, Johannes Schindelin wrote:
> It does what it should do. It is _your_ task to look at refs/original/*
> if everything went alright. Then you just delete the checked refs.
It seems odd to me, by the way, that filter-branch has its own
home-grown backup mechanism. Lots of other commands can "lose" commits,
but none of them keep an extra backup like this.
And I find it tedious for quicker jobs which it might otherwise be
useful for (e.g. rewrites of commits in my tree not yet in upstream),
unless I wrap it in a script that cleans up after itself.
--b.
^ permalink raw reply
* Re: Trying to use git-filter-branch to compress history by removing large, obsolete binary files
From: Johannes Schindelin @ 2007-10-08 1:06 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Elijah Newren, Frank Lichtenheld, git
In-Reply-To: <20071008010033.GA25654@fieldses.org>
Hi,
On Sun, 7 Oct 2007, J. Bruce Fields wrote:
> On Mon, Oct 08, 2007 at 01:34:07AM +0100, Johannes Schindelin wrote:
> > It does what it should do. It is _your_ task to look at refs/original/*
> > if everything went alright. Then you just delete the checked refs.
>
> It seems odd to me, by the way, that filter-branch has its own
> home-grown backup mechanism. Lots of other commands can "lose" commits,
> but none of them keep an extra backup like this.
The rationale was this: filter-branch recently learnt how to rewrite many
branches, and it might be tedious to find out which ones. But then, there
is git log --no-walk --all, so maybe I really should get rid of
refs/original/*?
I'd like to have some comments from the heavier filter-branch users on
that...
Ciao,
Dscho
^ permalink raw reply
* Re: Trying to use git-filter-branch to compress history by removing large, obsolete binary files
From: Dmitry Potapov @ 2007-10-08 1:06 UTC (permalink / raw)
To: Elijah Newren; +Cc: Alex Riesen, Frank Lichtenheld, git
In-Reply-To: <51419b2c0710071722k576c06d9i2f4dce730eae2059@mail.gmail.com>
On Sun, Oct 07, 2007 at 06:22:28PM -0600, Elijah Newren wrote:
>
> git-filter-branch --tree-filter 'rm -f testme.txt' HEAD
> git reset --hard
> rm -rf .git/refs/original/
> vi .git/packed-refs
> # Use vi to remove the line referring to refs/original...
> git reflog expire --all --expire-unreachable=0
> git gc --prune
>
> Seems like a wrapper is needed. :-)
Actually, I would rather not, because you rarely need to remove anything
immediately, and 30 days delay is reasonable time to give you a chance
to recover that you removed accidentally. You can reduce it by setting
appropriate value for gc.reflogExpireUnreachable in your configuration.
The only thing you need to do is to remove .git/refs/original/heads/something
after you are sure that git-filter-branch did exactly what you wanted.
>
> > Warning: all unreachable references will be removed!
>
> What other scenarios could lead to unreachable references?
Any re-writing of history leads to that.
> I don't
> know how to determine whether this is safe or not (except that these
> were test repositories anyway, so I don't care what happens to them).
Git logs all your action, so even re-writing history would not be
so disastrous if you suddenly realized that you did something wrong.
The history is stored for 30 days by default. Usually, you do not
need to mess with Git internals like you did above. Your useless
files still will disappear after being unreachable for 30 days.
OTOH, if you want to have a clean repository immediately, I believe
'git clone' is a better option. After you made a local clone using
it, 'git gc' should remove old garbage.
Dmitry
^ permalink raw reply
* Re: [PATCH] Make strbuf_cmp inline, constify its arguments and optimize it a bit
From: Miles Bader @ 2007-10-08 1:45 UTC (permalink / raw)
To: Alex Riesen
Cc: Wincent Colaiuta, David Kastrup, Pierre Habouzit, Timo Hirvonen,
git, Junio C Hamano
In-Reply-To: <20071007223140.GG2765@steel.home>
Alex Riesen <raa.lkml@gmail.com> writes:
> int strbuf_cmp2(struct strbuf *a, struct strbuf *b)
> {
> int len = a->len < b->len ? a->len: b->len;
> int cmp = memcmp(a->buf, b->buf, len);
> if (cmp)
> return cmp;
> return a->len < b->len ? -1: a->len != b->len;
> }
BTW, why are you making such effort to return only -1, 0, or 1 in the
last line? memcmp/strcmp make no such guarantee; e.g. glibc says:
The `strcmp' function compares the string S1 against S2, returning
a value that has the same sign as the difference between the first
differing pair of characters (interpreted as `unsigned char'
objects, then promoted to `int').
If the two strings are equal, `strcmp' returns `0'.
A consequence of the ordering used by `strcmp' is that if S1 is an
initial substring of S2, then S1 is considered to be "less than"
S2.
So I think the last line can just be:
return a->len - b->len;
-miles
--
Suburbia: where they tear out the trees and then name streets after them.
^ permalink raw reply
* Re: [PATCH] Make git-clean a builtin
From: Jeff King @ 2007-10-08 2:04 UTC (permalink / raw)
To: Shawn Bohrer; +Cc: git, gitster
In-Reply-To: <11917040461528-git-send-email-shawn.bohrer@gmail.com>
On Sat, Oct 06, 2007 at 03:54:06PM -0500, Shawn Bohrer wrote:
> +static int remove_directory(const char *path)
> +{
> [...]
> + chdir(path);
> [...]
> + chdir("..");
This doesn't always put you back where you started, due to symlinks. For
example:
cat >foo.c <<'EOF'
int main(int argc, char **argv) {
chdir(argv[1]);
chdir("..");
execlp("ls", 0);
}
EOF
gcc -o foo foo.c
ln -s /tmp sub
./foo sub
will show that you end up in the root directory. Something like this is
more robust:
fd = open(".", O_RDONLY);
chdir(path);
...
fchdir(fd);
In general, you shouldn't end up there because you don't actually
recurse for symlinks, but there is a race condition (and losing it means
you start recursively removing unintended directories -- oops).
On top of which, this line from the same function isn't very portable:
+ if (dir->d_type == DT_DIR)
since POSIX specifies nothing but dir->d_name (Solaris, for example,
doesn't define d_type). You need to stat the file.
All of that being said, I think a lot of this is already done in
dir.[ch]. At the very least, you should be able to use
remove_dir_recursively, and for bonus points you can get rid of the
start_command call to ls-files by just walking the dir tree yourself.
I don't know if the latter is required, but it's nice when the
C-ification actually cleans up a bit and uses the internal C interfaces
(which are more efficient and often more clear to read) rather than just
converting shell to C.
-Peff
^ permalink raw reply
* Re: [PATCH] Make git-clean a builtin
From: Jeff King @ 2007-10-08 2:08 UTC (permalink / raw)
To: Shawn Bohrer; +Cc: git, gitster
In-Reply-To: <20071008020435.GA20050@coredump.intra.peff.net>
On Sun, Oct 07, 2007 at 10:04:35PM -0400, Jeff King wrote:
> This doesn't always put you back where you started, due to symlinks. For
> example:
> [and other complaints]
Oops, didn't see that there was another thread for the reworked patch.
My comments still stand, but it looks like others have weighed in as
well. Sorry.
-Peff
^ permalink raw reply
* Re: [PATCH] Make git-clean a builtin
From: Linus Torvalds @ 2007-10-08 2:17 UTC (permalink / raw)
To: Jeff King; +Cc: Shawn Bohrer, git, gitster
In-Reply-To: <20071008020435.GA20050@coredump.intra.peff.net>
On Sun, 7 Oct 2007, Jeff King wrote:
>
> fd = open(".", O_RDONLY);
> chdir(path);
> ...
> fchdir(fd);
fchdir() is not portable.
I think it would be better to not chdir() at all. Yes, that means having
to prepend the prefix to the names, but that is what git generally does
(for that - and other - reasons).
Linus
^ permalink raw reply
* Re: [PATCH] Make strbuf_cmp inline, constify its arguments and optimize it a bit
From: Jeff King @ 2007-10-08 2:19 UTC (permalink / raw)
To: Alex Riesen; +Cc: David Kastrup, git
In-Reply-To: <20071007215749.GD2765@steel.home>
On Sun, Oct 07, 2007 at 11:57:49PM +0200, Alex Riesen wrote:
> > > Can't the result of the expression be reused in compiled?
> > > Isn't it a common expression?
> >
> > No, since the call to memcmp might change a->len or b->len. A
>
> Huh?! How's that? It is not even given them!
But they are non-local variables (they are part of structs passed in as
pointers), so that translation unit has no idea how they are allocated.
They could be globals that memcmp mucks with as a side effect.
That being said, standards-conforming compilers _can_ realize that
memcmp is a special, standards-defined function with no side effects and
act accordingly. gcc provides the 'pure' function attribute for this
purpose, which is used by glibc.
-Peff
^ permalink raw reply
* Re: [PATCH] Make git-clean a builtin
From: Jeff King @ 2007-10-08 2:22 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Shawn Bohrer, git, gitster
In-Reply-To: <alpine.LFD.0.999.0710071916510.23684@woody.linux-foundation.org>
On Sun, Oct 07, 2007 at 07:17:50PM -0700, Linus Torvalds wrote:
> fchdir() is not portable.
>
> I think it would be better to not chdir() at all. Yes, that means having
> to prepend the prefix to the names, but that is what git generally does
> (for that - and other - reasons).
I was using the "even Solaris has it!" test, but yes, it's not POSIX. I
don't know how common it actually is (for curiosity's sake, do you know
of a common platform that lacks it?). But I do agree that just building
up the path and avoiding the chdir at all is simple and portable.
-Peff
^ permalink raw reply
* Re: Trying to use git-filter-branch to compress history by removing large, obsolete binary files
From: Sam Vilain @ 2007-10-08 2:28 UTC (permalink / raw)
To: Elijah Newren; +Cc: Johannes Schindelin, Frank Lichtenheld, git
In-Reply-To: <51419b2c0710071747w14d0c265x2de42fca50552394@mail.gmail.com>
Elijah Newren wrote:
> On 10/7/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>> It should be as easy as git filter-branch and git clone.
>
> Yes, a git filter-branch, git clone, AND git gc in the clone avoids
> all those funny ref editing commands. However, cloning a 5.6GB repo
> (the size of one of the real repos I'm dealing with) will likely take
> a long time (and may push me past the limits of disk space), so using
> other steps to avoid the need to clone actually seems nicer.
You can just delete the logs and references that you don't want and run
git gc --prune.
However.
git gc creates a new pack before deleting the old one. Garbage
collection usually does this; make a copy of everything to a new place
and then free all of the old space. If *that* is a problem, ie you
don't have enough space for two copies of the repository and the junk,
you'll have to do a partial import, leave the junk you don't want
unpacked, cleanup and prune, then finish the import. Which sounds like
a lot of hassle when you should really just find a place with more space
to work with!
Sam.
^ permalink raw reply
* [PATCH 1/2] rev-list: implement --bisect-all
From: Christian Couder @ 2007-10-08 3:34 UTC (permalink / raw)
To: Junio Hamano; +Cc: git
This is Junio's patch with some stuff to make --bisect-all
compatible with --bisect-vars.
This option makes it possible to see all the potential
bisection points. The best ones are displayed first.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
builtin-rev-list.c | 98 +++++++++++++++++++++++++++++++++++++++++++++-------
log-tree.c | 2 +-
log-tree.h | 1 +
3 files changed, 87 insertions(+), 14 deletions(-)
diff --git a/builtin-rev-list.c b/builtin-rev-list.c
index 33726b8..0943b76 100644
--- a/builtin-rev-list.c
+++ b/builtin-rev-list.c
@@ -9,6 +9,7 @@
#include "revision.h"
#include "list-objects.h"
#include "builtin.h"
+#include "log-tree.h"
/* bits #0-15 in revision.h */
@@ -39,6 +40,7 @@ static const char rev_list_usage[] =
" special purpose:\n"
" --bisect\n"
" --bisect-vars"
+" --bisect-all"
;
static struct rev_info revs;
@@ -74,6 +76,7 @@ static void show_commit(struct commit *commit)
parents = parents->next;
}
}
+ show_decorations(commit);
if (revs.commit_format == CMIT_FMT_ONELINE)
putchar(' ');
else
@@ -278,6 +281,57 @@ static struct commit_list *best_bisection(struct commit_list *list, int nr)
return best;
}
+struct commit_dist {
+ struct commit *commit;
+ int distance;
+};
+
+static int compare_commit_dist(const void *a_, const void *b_)
+{
+ struct commit_dist *a, *b;
+
+ a = (struct commit_dist *)a_;
+ b = (struct commit_dist *)b_;
+ if (a->distance != b->distance)
+ return b->distance - a->distance; /* desc sort */
+ return hashcmp(a->commit->object.sha1, b->commit->object.sha1);
+}
+
+static struct commit_list *best_bisection_sorted(struct commit_list *list, int nr)
+{
+ struct commit_list *p;
+ struct commit_dist *array = xcalloc(nr, sizeof(*array));
+ int cnt, i;
+
+ for (p = list, cnt = 0; p; p = p->next) {
+ int distance;
+ unsigned flags = p->item->object.flags;
+
+ if (revs.prune_fn && !(flags & TREECHANGE))
+ continue;
+ distance = weight(p);
+ if (nr - distance < distance)
+ distance = nr - distance;
+ array[cnt].commit = p->item;
+ array[cnt].distance = distance;
+ cnt++;
+ }
+ qsort(array, cnt, sizeof(*array), compare_commit_dist);
+ for (p = list, i = 0; i < cnt; i++) {
+ struct name_decoration *r = xmalloc(sizeof(*r) + 100);
+ struct object *obj = &(array[i].commit->object);
+
+ sprintf(r->name, "dist=%d", array[i].distance);
+ r->next = add_decoration(&name_decoration, obj, r);
+ p->item = array[i].commit;
+ p = p->next;
+ }
+ if (p)
+ p->next = NULL;
+ free(array);
+ return list;
+}
+
/*
* zero or positive weight is the number of interesting commits it can
* reach, including itself. Especially, weight = 0 means it does not
@@ -292,7 +346,8 @@ static struct commit_list *best_bisection(struct commit_list *list, int nr)
* or positive distance.
*/
static struct commit_list *do_find_bisection(struct commit_list *list,
- int nr, int *weights)
+ int nr, int *weights,
+ int find_all)
{
int n, counted;
struct commit_list *p;
@@ -351,7 +406,7 @@ static struct commit_list *do_find_bisection(struct commit_list *list,
clear_distance(list);
/* Does it happen to be at exactly half-way? */
- if (halfway(p, nr))
+ if (!find_all && halfway(p, nr))
return p;
counted++;
}
@@ -389,19 +444,22 @@ static struct commit_list *do_find_bisection(struct commit_list *list,
weight_set(p, weight(q));
/* Does it happen to be at exactly half-way? */
- if (halfway(p, nr))
+ if (!find_all && halfway(p, nr))
return p;
}
}
show_list("bisection 2 counted all", counted, nr, list);
- /* Then find the best one */
- return best_bisection(list, nr);
+ if (!find_all)
+ return best_bisection(list, nr);
+ else
+ return best_bisection_sorted(list, nr);
}
static struct commit_list *find_bisection(struct commit_list *list,
- int *reaches, int *all)
+ int *reaches, int *all,
+ int find_all)
{
int nr, on_list;
struct commit_list *p, *best, *next, *last;
@@ -434,14 +492,13 @@ static struct commit_list *find_bisection(struct commit_list *list,
weights = xcalloc(on_list, sizeof(*weights));
/* Do the real work of finding bisection commit. */
- best = do_find_bisection(list, nr, weights);
-
+ best = do_find_bisection(list, nr, weights, find_all);
if (best) {
- best->next = NULL;
+ if (!find_all)
+ best->next = NULL;
*reaches = weight(best);
}
free(weights);
-
return best;
}
@@ -468,6 +525,7 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)
int i;
int read_from_stdin = 0;
int bisect_show_vars = 0;
+ int bisect_find_all = 0;
git_config(git_default_config);
init_revisions(&revs, prefix);
@@ -490,6 +548,11 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)
bisect_list = 1;
continue;
}
+ if (!strcmp(arg, "--bisect-all")) {
+ bisect_list = 1;
+ bisect_find_all = 1;
+ continue;
+ }
if (!strcmp(arg, "--bisect-vars")) {
bisect_list = 1;
bisect_show_vars = 1;
@@ -536,9 +599,11 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)
if (bisect_list) {
int reaches = reaches, all = all;
- revs.commits = find_bisection(revs.commits, &reaches, &all);
+ revs.commits = find_bisection(revs.commits, &reaches, &all,
+ bisect_find_all);
if (bisect_show_vars) {
int cnt;
+ char hex[41];
if (!revs.commits)
return 1;
/*
@@ -550,15 +615,22 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)
* A bisect set of size N has (N-1) commits further
* to test, as we already know one bad one.
*/
- cnt = all-reaches;
+ cnt = all - reaches;
if (cnt < reaches)
cnt = reaches;
+ strcpy(hex, sha1_to_hex(revs.commits->item->object.sha1));
+
+ if (bisect_find_all) {
+ traverse_commit_list(&revs, show_commit, show_object);
+ printf("------\n");
+ }
+
printf("bisect_rev=%s\n"
"bisect_nr=%d\n"
"bisect_good=%d\n"
"bisect_bad=%d\n"
"bisect_all=%d\n",
- sha1_to_hex(revs.commits->item->object.sha1),
+ hex,
cnt - 1,
all - reaches - 1,
reaches - 1,
diff --git a/log-tree.c b/log-tree.c
index 2319154..f766758 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -15,7 +15,7 @@ static void show_parents(struct commit *commit, int abbrev)
}
}
-static void show_decorations(struct commit *commit)
+void show_decorations(struct commit *commit)
{
const char *prefix;
struct name_decoration *decoration;
diff --git a/log-tree.h b/log-tree.h
index e82b56a..b33f7cd 100644
--- a/log-tree.h
+++ b/log-tree.h
@@ -12,5 +12,6 @@ int log_tree_diff_flush(struct rev_info *);
int log_tree_commit(struct rev_info *, struct commit *);
int log_tree_opt_parse(struct rev_info *, const char **, int);
void show_log(struct rev_info *opt, const char *sep);
+void show_decorations(struct commit *commit);
#endif
--
1.5.3.4.208.g996ad
^ permalink raw reply related
* [PATCH 2/2] Bisect: implement "bisect dunno" to mark untestable revisions.
From: Christian Couder @ 2007-10-08 3:34 UTC (permalink / raw)
To: Junio Hamano; +Cc: git
When there are some dunno revisions, we add the '--bisect-all'
option to "git rev-list --bisect-vars". Then we filter out the
dunno revisions from the result of the rev-list command, and we
modify the "bisect_rev" var accordingly.
We don't always use "--bisect-all" because it is slower
than "--bisect-vars" or "--bisect".
When we cannot find for sure the first bad commit because of
dunno commits, we print the hash of each possible first bad
commit and then we exit with code 2.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
git-bisect.sh | 127 +++++++++++++++++++++++++++++++++++++++++--
t/t6030-bisect-porcelain.sh | 71 ++++++++++++++++++++++++
2 files changed, 193 insertions(+), 5 deletions(-)
diff --git a/git-bisect.sh b/git-bisect.sh
index 388887a..c556318 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -17,6 +17,8 @@ git bisect replay <logfile>
replay bisection log.
git bisect log
show bisect log.
+git bisect dunno [<rev>...]
+ mark <rev>... untestable revisions.
git bisect run <cmd>...
use <cmd>... to automatically bisect.'
@@ -143,7 +145,7 @@ bisect_write_bad() {
bisect_good() {
bisect_autostart
- case "$#" in
+ case "$#" in
0) revs=$(git rev-parse --verify HEAD) || exit ;;
*) revs=$(git rev-parse --revs-only --no-flags "$@") &&
test '' != "$revs" || die "Bad rev input: $@" ;;
@@ -153,7 +155,6 @@ bisect_good() {
rev=$(git rev-parse --verify "$rev^{commit}") || exit
bisect_write_good "$rev"
echo "git-bisect good $rev" >>"$GIT_DIR/BISECT_LOG"
-
done
bisect_auto_next
}
@@ -164,6 +165,28 @@ bisect_write_good() {
echo "# good: "$(git show-branch $rev) >>"$GIT_DIR/BISECT_LOG"
}
+bisect_dunno() {
+ bisect_autostart
+ case "$#" in
+ 0) revs=$(git rev-parse --verify HEAD) || exit ;;
+ *) revs=$(git rev-parse --revs-only --no-flags "$@") &&
+ test '' != "$revs" || die "Bad rev input: $@" ;;
+ esac
+ for rev in $revs
+ do
+ rev=$(git rev-parse --verify "$rev^{commit}") || exit
+ bisect_write_dunno "$rev"
+ echo "git-bisect dunno $rev" >>"$GIT_DIR/BISECT_LOG"
+ done
+ bisect_auto_next
+}
+
+bisect_write_dunno() {
+ rev="$1"
+ echo "$rev" >"$GIT_DIR/refs/bisect/dunno-$rev"
+ echo "# dunno: "$(git show-branch $rev) >>"$GIT_DIR/BISECT_LOG"
+}
+
bisect_next_check() {
missing_good= missing_bad=
git show-ref -q --verify refs/bisect/bad || missing_bad=t
@@ -206,17 +229,104 @@ bisect_auto_next() {
bisect_next_check && bisect_next || :
}
+search_dunno() {
+ _hash="$1"
+ _dunno="$2"
+
+ for _val in $_dunno ; do
+ case $_hash in $_val) return 1 ;; esac
+ done
+ return 0
+}
+
+filter_dunno() {
+ _eval="$1"
+ _dunno="$2"
+
+ if [ -z "$_dunno" ]; then
+ eval $_eval
+ return
+ fi
+
+ # Let's parse the output of:
+ # "git rev-list --bisect-vars --bisect-all ..."
+ eval $_eval | while read hash line
+ do
+ case "$VARS,$FOUND,$TRIED,$hash" in
+ # We display some vars.
+ 1,*,*,*) echo "$hash $line" ;;
+
+ # Split line.
+ ,*,*,---*) ;;
+
+ # We had nothing to search.
+ ,,,bisect_rev*)
+ echo "bisect_rev="
+ VARS=1
+ ;;
+
+ # We did not find a good bisect rev.
+ # This should happen only if the "bad"
+ # commit is also a "dunno" commit.
+ ,,*,bisect_rev*)
+ echo "bisect_rev=$TRIED"
+ VARS=1
+ ;;
+
+ # We are searching.
+ ,,*,*)
+ TRIED="${TRIED:+$TRIED|}$hash"
+ if search_dunno "$hash" "$_dunno" ; then
+ echo "bisect_rev=$hash"
+ echo "bisect_tried=\"$TRIED\""
+ FOUND=1
+ fi
+ ;;
+
+ # We have already found a rev to be tested.
+ ,1,*,bisect_rev*) VARS=1 ;;
+ ,1,*,*) ;;
+
+ # ???
+ *) die "filter_dunno error " \
+ "VARS: '$VARS' " \
+ "FOUND: '$FOUND' " \
+ "TRIED: '$TRIED' " \
+ "hash: '$hash' " \
+ "line: '$line'"
+ ;;
+ esac
+ done
+}
+
+exit_if_dunno_commits () {
+ _tried=$1
+ if expr "$_tried" : ".*[|].*" > /dev/null ; then
+ echo "There are only 'dunno' commit left to test."
+ echo "The first bad commit could be any of:"
+ echo "$_tried" | sed -e 's/[|]/\n/g'
+ echo "We cannot bisect more!"
+ exit 2
+ fi
+}
+
bisect_next() {
- case "$#" in 0) ;; *) usage ;; esac
+ case "$#" in 0) ;; *) usage ;; esac
bisect_autostart
bisect_next_check good
+ dunno=$(git for-each-ref --format='%(objectname)' \
+ "refs/bisect/dunno-*" | tr '[\012]' ' ') || exit
+
+ BISECT_OPT=''
+ test -n "$dunno" && BISECT_OPT='--bisect-all'
+
bad=$(git rev-parse --verify refs/bisect/bad) &&
good=$(git for-each-ref --format='^%(objectname)' \
"refs/bisect/good-*" | tr '[\012]' ' ') &&
- eval="git rev-list --bisect-vars $good $bad --" &&
+ eval="git rev-list --bisect-vars $BISECT_OPT $good $bad --" &&
eval="$eval $(cat "$GIT_DIR/BISECT_NAMES")" &&
- eval=$(eval "$eval") &&
+ eval=$(filter_dunno "$eval" "$dunno") &&
eval "$eval" || exit
if [ -z "$bisect_rev" ]; then
@@ -224,11 +334,16 @@ bisect_next() {
exit 1
fi
if [ "$bisect_rev" = "$bad" ]; then
+ exit_if_dunno_commits "$bisect_tried"
echo "$bisect_rev is first bad commit"
git diff-tree --pretty $bisect_rev
exit 0
fi
+ # We should exit here only if the "bad"
+ # commit is also a "dunno" commit (see above).
+ exit_if_dunno_commits "$bisect_rev"
+
echo "Bisecting: $bisect_nr revisions left to test after this"
echo "$bisect_rev" >"$GIT_DIR/refs/heads/new-bisect"
git checkout -q new-bisect || exit
@@ -363,6 +478,8 @@ case "$#" in
bisect_bad "$@" ;;
good)
bisect_good "$@" ;;
+ dunno)
+ bisect_dunno "$@" ;;
next)
# Not sure we want "next" at the UI level anymore.
bisect_next "$@" ;;
diff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh
index 03cdba5..7f41a46 100755
--- a/t/t6030-bisect-porcelain.sh
+++ b/t/t6030-bisect-porcelain.sh
@@ -71,6 +71,63 @@ test_expect_success 'bisect start with one bad and good' '
git bisect next
'
+# $HASH1 is good, $HASH4 is bad, we dunno about $HASH3
+# but $HASH2 is bad,
+# so we should find $HASH2 as the first bad commit
+test_expect_success 'bisect dunno: successfull result' '
+ git bisect reset &&
+ git bisect start $HASH4 $HASH1 &&
+ git bisect dunno &&
+ git bisect bad > my_bisect_log.txt &&
+ grep "$HASH2 is first bad commit" my_bisect_log.txt &&
+ git bisect reset
+'
+
+# $HASH1 is good, $HASH4 is bad, we dunno about $HASH3 and $HASH2
+# so we should not be able to tell the first bad commit
+# among $HASH2, $HASH3 and $HASH4
+test_expect_success 'bisect dunno: cannot tell between 3 commits' '
+ git bisect start $HASH4 $HASH1 &&
+ git bisect dunno || return 1
+
+ if git bisect dunno > my_bisect_log.txt
+ then
+ echo Oops, should have failed.
+ false
+ else
+ test $? -eq 2 &&
+ grep "first bad commit could be any of" my_bisect_log.txt &&
+ ! grep $HASH1 my_bisect_log.txt &&
+ grep $HASH2 my_bisect_log.txt &&
+ grep $HASH3 my_bisect_log.txt &&
+ grep $HASH4 my_bisect_log.txt &&
+ git bisect reset
+ fi
+'
+
+# $HASH1 is good, $HASH4 is bad, we dunno about $HASH3
+# but $HASH2 is good,
+# so we should not be able to tell the first bad commit
+# among $HASH3 and $HASH4
+test_expect_success 'bisect dunno: cannot tell between 2 commits' '
+ git bisect start $HASH4 $HASH1 &&
+ git bisect dunno || return 1
+
+ if git bisect good > my_bisect_log.txt
+ then
+ echo Oops, should have failed.
+ false
+ else
+ test $? -eq 2 &&
+ grep "first bad commit could be any of" my_bisect_log.txt &&
+ ! grep $HASH1 my_bisect_log.txt &&
+ ! grep $HASH2 my_bisect_log.txt &&
+ grep $HASH3 my_bisect_log.txt &&
+ grep $HASH4 my_bisect_log.txt &&
+ git bisect reset
+ fi
+'
+
# We want to automatically find the commit that
# introduced "Another" into hello.
test_expect_success \
@@ -99,6 +156,20 @@ test_expect_success \
grep "$HASH4 is first bad commit" my_bisect_log.txt &&
git bisect reset'
+# $HASH1 is good, $HASH5 is bad, we dunno about $HASH3
+# but $HASH4 is good,
+# so we should find $HASH5 as the first bad commit
+HASH5=
+test_expect_success 'bisect dunno: add line and then a new test' '
+ add_line_into_file "5: Another new line." hello &&
+ HASH5=$(git rev-parse --verify HEAD) &&
+ git bisect start $HASH5 $HASH1 &&
+ git bisect dunno &&
+ git bisect good > my_bisect_log.txt &&
+ grep "$HASH5 is first bad commit" my_bisect_log.txt &&
+ git bisect reset
+'
+
#
#
test_done
--
1.5.3.4.208.g996ad
^ permalink raw reply related
* Re: [PATCH 1/2] rev-list: implement --bisect-all
From: Johannes Schindelin @ 2007-10-08 3:44 UTC (permalink / raw)
To: Christian Couder; +Cc: Junio Hamano, git
In-Reply-To: <20071008053438.6a829b91.chriscool@tuxfamily.org>
Hi,
On Mon, 8 Oct 2007, Christian Couder wrote:
> This option makes it possible to see all the potential bisection points.
> The best ones are displayed first.
Would it not be better to pass --bisect-vars a list of commits that we do
not want to see? It could then mark them as "DUNNO", and still just
output a single commit.
IMHO such a logic does not belong into a shell script, but into the C
core.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 2/2] Bisect: implement "bisect dunno" to mark untestable revisions.
From: Johannes Schindelin @ 2007-10-08 3:49 UTC (permalink / raw)
To: Christian Couder; +Cc: Junio Hamano, git
In-Reply-To: <20071008053450.a52d7c5e.chriscool@tuxfamily.org>
Hi,
On Mon, 8 Oct 2007, Christian Couder wrote:
> diff --git a/git-bisect.sh b/git-bisect.sh
> index 388887a..c556318 100755
> --- a/git-bisect.sh
> +++ b/git-bisect.sh
> @@ -143,7 +145,7 @@ bisect_write_bad() {
>
> bisect_good() {
> bisect_autostart
> - case "$#" in
> + case "$#" in
White space breakage.
> @@ -153,7 +155,6 @@ bisect_good() {
> rev=$(git rev-parse --verify "$rev^{commit}") || exit
> bisect_write_good "$rev"
> echo "git-bisect good $rev" >>"$GIT_DIR/BISECT_LOG"
> -
?
> @@ -164,6 +165,28 @@ bisect_write_good() {
> echo "# good: "$(git show-branch $rev) >>"$GIT_DIR/BISECT_LOG"
> }
>
> +bisect_dunno() {
> + bisect_autostart
> + case "$#" in
> + 0) revs=$(git rev-parse --verify HEAD) || exit ;;
> + *) revs=$(git rev-parse --revs-only --no-flags "$@") &&
> + test '' != "$revs" || die "Bad rev input: $@" ;;
> + esac
> + for rev in $revs
> + do
> + rev=$(git rev-parse --verify "$rev^{commit}") || exit
> + bisect_write_dunno "$rev"
> + echo "git-bisect dunno $rev" >>"$GIT_DIR/BISECT_LOG"
Should the last line not be put into bisect_write_dunno? OTOH this is the
only call site of that function, so I strongly doubt that the function
(consisting of 3 lines, where the first is 'rev="$1"') is necessary at
all.
> @@ -206,17 +229,104 @@ bisect_auto_next() {
> bisect_next_check && bisect_next || :
> }
>
> +search_dunno() {
> + _hash="$1"
> + _dunno="$2"
> +
> + for _val in $_dunno ; do
> + case $_hash in $_val) return 1 ;; esac
> + done
This would be faster as
case " $1" in " $2") return 1 ;; esac
I guess.
But as I said in the other reply, I think this logic belongs into the C
core, instead of generating mostly useless information, passing it down to
the script, and filtering it out again.
Thanks,
Dscho
^ 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