* 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: [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: 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 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: 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 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: 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: 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: 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: 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: 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: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: 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: 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: 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: [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: [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
* 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: 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
* 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: [PATCH] git-gui: offer a list of recent repositories on startup
From: Shawn O. Pearce @ 2007-10-07 23:30 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git, msysgit
In-Reply-To: <11917925011987-git-send-email-prohaska@zib.de>
Steffen Prohaska <prohaska@zib.de> wrote:
> If git-gui is started outside a work tree the repository
> chooser will offer a list of recently opend repositories.
> Clicking on an entry directly opens the repository.
>
> The list of recently opened repositories is stored in the
> config as gui.recentrepos. If the list grows beyond 10
> entries it will be truncated.
>
> Note, only repositories that are opened through the
> repository chooser will get added to the recent list.
> Repositories opened from the shell will not yet be added.
I think that all makes a lot of sense. Three comments below about
this patch in particular.
> I'd suggest to reduce the number of clicks needed to open or
> clone an existing directory that is not in the list of
> recent repositories. First choosing from the radiobuttons
> and then clicking next is one click to much. There are no
> options to combine. Choosing from the list should
> immediately trigger the action.
>
> We could either put 'Create/Clone/Open New Repository' into
> the Repository menu and only present the recent repository
> list. Or we could offer push buttons for the other actions.
I agree entirely. That "Next" button is stupid stupid stupid.
What was I smoking that day? :-)
I'm concerned about putting them into the Repository menu only
as then the main window is competely void and users are sort of
wondering what they should do next. I think we should actually
do both. Put them into the menu and as push buttons on the window.
> + label $w_body.space
> + label $w_body.recentlabel \
> + -anchor w \
> + -text "Select Recent Repository:"
This string needs to be i18n'd with [mc ...].
> + listbox $w_body.recentlist \
Please make a field in this class called say "w_recentlist"
so you can use that field name instead of $w_body.recentlist.
This simplifies the code if we ever have to change the actual path
that the widget resides at, such as to alter the layout.
> +proc _append_recentrepos {path} {
> + set recent [get_config gui.recentrepos]
> + if {[lsearch $recent $path] < 0} {
> + lappend recent $path
> + }
> + if {[llength $recent] > 10} {
> + set recent [lrange $recent 1 end]
> + }
> + regsub -all "\[{}\]" $recent {"} recent
> + git config --global gui.recentrepos $recent
> +}
Why treat this as a Tcl list in a single value? Why not make it
a true multi-value configuration entry in ~/.gitconfig, like how
remote.$name.fetch is a multi-value entry? Does Windows allow
you to put " in a path name? Because the above regex will make
a list of paths that contains " in one of the entries invalid.
I think you also want to have this function return back immediately
if [lsearch $recent $path] >= 0 as then you don't invoke git-config
to perform a no-op change in the configuration file. As you well
know forking on Windows is a major cost. We shouldn't run git-config
just because the user opened a recent repository.
--
Shawn.
^ permalink raw reply
* StGit kha safe branch updated
From: Karl Hasselström @ 2007-10-07 23:29 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
These are the assimilate patches, plus the two new series I just
mailed out.
The following changes since commit 764d110156e4951ca5671a700ee2402fa3597734:
Yann Dirson (1):
Better diagnostic for wrong branch configuration.
are available in the git repository at:
git://repo.or.cz/stgit/kha.git safe
Karl Hasselström (16):
Teach "stg assimilate" to repair patch reachability
Test the new powers of "stg assimilate"
Let "stg assimilate" handle missing patches
Add --ack/--sign options to "stg new"
New test: "stg pop --keep"
Fix up the help text for "stg edit"
Don't split long and short description in "stg edit"
Make a common superclass for all StGit exceptions
Simplify debug level error checking
Discard stderr output from git-rev-parse
Remove the --force flag to "stg rebase" and "stg pull"
Infrastructure for current directory handling
New test: Try "stg push" in a subdirectory
Make "stg push" subdirectory safe
New test: try "stg refresh" in a subdirectory
Make "stg refresh" subdirectory safe
stgit/commands/add.py | 1 +
stgit/commands/applied.py | 1 +
stgit/commands/assimilate.py | 199 +++++++++++++++++++++++++++++++----------
stgit/commands/branch.py | 1 +
stgit/commands/clean.py | 1 +
stgit/commands/clone.py | 1 +
stgit/commands/commit.py | 1 +
stgit/commands/common.py | 88 +++++++++++++++---
stgit/commands/copy.py | 1 +
stgit/commands/delete.py | 1 +
stgit/commands/diff.py | 1 +
stgit/commands/edit.py | 34 ++++----
stgit/commands/export.py | 1 +
stgit/commands/files.py | 1 +
stgit/commands/float.py | 1 +
stgit/commands/fold.py | 1 +
stgit/commands/goto.py | 1 +
stgit/commands/hide.py | 1 +
stgit/commands/id.py | 1 +
stgit/commands/imprt.py | 1 +
stgit/commands/init.py | 1 +
stgit/commands/log.py | 1 +
stgit/commands/mail.py | 1 +
stgit/commands/new.py | 7 +-
stgit/commands/patches.py | 1 +
stgit/commands/pick.py | 1 +
stgit/commands/pop.py | 1 +
stgit/commands/pull.py | 6 +-
stgit/commands/push.py | 1 +
stgit/commands/rebase.py | 6 +-
stgit/commands/refresh.py | 1 +
stgit/commands/rename.py | 1 +
stgit/commands/resolved.py | 1 +
stgit/commands/rm.py | 1 +
stgit/commands/series.py | 1 +
stgit/commands/show.py | 1 +
stgit/commands/sink.py | 1 +
stgit/commands/status.py | 1 +
stgit/commands/sync.py | 1 +
stgit/commands/top.py | 1 +
stgit/commands/unapplied.py | 1 +
stgit/commands/uncommit.py | 1 +
stgit/commands/unhide.py | 1 +
stgit/config.py | 3 +-
stgit/exception.py | 3 +
stgit/git.py | 6 +-
stgit/gitmergeonefile.py | 3 +-
stgit/main.py | 17 ++---
stgit/run.py | 5 +-
stgit/stack.py | 20 +++-
stgit/utils.py | 3 +-
t/t1204-pop-keep.sh | 42 +++++++++
t/t1205-push-subdir.sh | 55 +++++++++++
t/t1301-assimilate.sh | 12 +--
t/t1302-assimilate-interop.sh | 59 ++++++++++++
t/t2100-pull-policy-fetch.sh | 14 ---
t/t2102-pull-policy-rebase.sh | 24 -----
t/t2300-refresh-subdir.sh | 27 ++++++
58 files changed, 514 insertions(+), 156 deletions(-)
create mode 100644 stgit/exception.py
create mode 100755 t/t1204-pop-keep.sh
create mode 100755 t/t1205-push-subdir.sh
create mode 100755 t/t1302-assimilate-interop.sh
create mode 100755 t/t2300-refresh-subdir.sh
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: Trying to use git-filter-branch to compress history by removing large, obsolete binary files
From: Johannes Schindelin @ 2007-10-07 23:28 UTC (permalink / raw)
To: Elijah Newren; +Cc: Frank Lichtenheld, git
In-Reply-To: <51419b2c0710071624v79dc02d2g35a265add50dd46d@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:
> >
> > > So...how do I fix the reflog, and then repack to have a pack under
> > > 11MB in size?
> >
> > Just clone it. The clone will be much smaller.
>
> $ 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.
Ciao,
Dscho
^ permalink raw reply
* Re: git fetch -- double fetch
From: Johannes Schindelin @ 2007-10-07 23:25 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: git
In-Reply-To: <20071007214433.GA30833@shadowen.org>
Hi,
On Sun, 7 Oct 2007, Andy Whitcroft wrote:
> On Sun, Oct 07, 2007 at 05:29:38PM +0100, Johannes Schindelin wrote:
>
> > On Sat, 6 Oct 2007, Andy Whitcroft wrote:
> >
> > > I have recently been seeing repeated fetching of some branches. I
> > > feel this has happened in at least three of my repos on three
> > > distinct projects:
> > >
> > > apw@pinky$ git fetch origin
> > > remote: Generating pack...
> > > remote: Done counting 5 objects.
> > > remote: Deltifying 5 objects...
> > > remote: 100% (5/5) done
> > > Unpacking 5 objects...
> > > remote: Total 5 (delta 0), reused 0 (delta 0)
> > > 100% (5/5) done
> > > * refs/remotes/origin/master: fast forward to branch 'master' of ssh://git@abat-dev/var/www/git/abat
> > > old..new: ce046f0..41c9dde
> > > * refs/remotes/origin/master: fast forward to branch 'master' of ssh://git@abat-dev/var/www/git/abat
> > > old..new: ce046f0..41c9dde
> >
> > What does "git config --get-all remote.origin.fetch" say?
>
> apw@pinky$ git config --get-all remote.origin.fetch
> +refs/heads/master:refs/remotes/origin/master
> +refs/heads/*:refs/remotes/origin/*
> apw@pinky$
>
> I don't think that I did anything to this config, I think that is what
> the clone setup for me.
Actually, I am quite certain that git clone does not produce the first
line; But I think that it was necessary to put in some line like that in
older git, where the first ref was the one being merged by a pull.
But as I suspected, and Daniel replied, too, your issue is that both lines
match "master".
You might want to delete the first line, and use "branch.<name>.remote"
and "branch.<name>.merge" to force pull to merge "master" instead.
In the long run, it might be a good idea to cull duplicates in git-fetch,
but for the moment I have enough other stuff to do ;-)
Ciao,
Dscho
^ permalink raw reply
* [StGit PATCH 5/5] Make "stg refresh" subdirectory safe
From: Karl Hasselström @ 2007-10-07 23:25 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20071007231949.13070.49517.stgit@yoghurt>
Make "stg refresh" subdirectory safe by letting it internally cd up to
the top of the worktree. This is possibly not the best long-term fix;
one could argue that the refresh subroutine should instead be safe to
run from a subdirectory. However, refreshing from a subdirectory
currently only refreshes changes that are in the index, and not
changes in the working directory, and that has to be fixed.
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
stgit/commands/refresh.py | 2 +-
t/t2300-refresh-subdir.sh | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/stgit/commands/refresh.py b/stgit/commands/refresh.py
index b283892..f032375 100644
--- a/stgit/commands/refresh.py
+++ b/stgit/commands/refresh.py
@@ -37,7 +37,7 @@ options. The '--force' option is useful when a commit object was
created with a different tool but the changes need to be included in
the current patch."""
-directory = DirectoryHasRepository()
+directory = DirectoryGotoToplevel()
options = [make_option('-f', '--force',
help = 'force the refresh even if HEAD and '\
'top differ',
diff --git a/t/t2300-refresh-subdir.sh b/t/t2300-refresh-subdir.sh
index d1c7168..bdd27c5 100755
--- a/t/t2300-refresh-subdir.sh
+++ b/t/t2300-refresh-subdir.sh
@@ -15,7 +15,7 @@ test_expect_success 'Refresh from a subdirectory' '
[ "$(stg status)" = "" ]
'
-test_expect_failure 'Refresh again' '
+test_expect_success 'Refresh again' '
echo foo2 >> foo.txt &&
echo bar2 >> bar/bar.txt &&
cd bar &&
^ permalink raw reply related
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