* Re: Many gits are offline this week
From: Shawn O. Pearce @ 2007-10-07 23:09 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Daniel Barkalow, Randal L. Schwartz, Paolo Ciarrocchi, git
In-Reply-To: <Pine.LNX.4.64.0710072331050.4174@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Sun, 7 Oct 2007, Daniel Barkalow wrote:
>
> > For that matter, gitweb is essentially a limited porcelain. And this
> > points out that all VCSes have alternative porcelains, but git is
> > unusual in having convenient plumbing to support and encourage this.
>
> I do not consider viewers "porcelain". And gitweb is essentially just a
> viewer.
So you don't consider gitk to be porcelain? I do. The plumbing
output of git-rev-list is uh, ugly. gitk may still not be the best
looking application on the internet but it sure beats looking at
rev-list output by eye.
Porcelain is really anything that calls plumbing to make the task
of invoking or processing the output of plumbing easier on the
human using it. That's it. Obviously you can work Git by just the
plumbing. Just like you can compute SHA-1 by hand. You just choose
not to as the time it would take is more than you want to invest.
Or have left in this mortal existance...
I almost always forget about the web interfaces. There's a number
of them and I don't use them often enough to really think about it.
I don't know why I always forget about them. I never forget about
StGit or qgit, and yet I never use those either...
--
Shawn.
^ permalink raw reply
* Re: Many gits are offline this week
From: Johannes Schindelin @ 2007-10-07 22:31 UTC (permalink / raw)
To: Daniel Barkalow
Cc: Shawn O. Pearce, Randal L. Schwartz, Paolo Ciarrocchi, git
In-Reply-To: <Pine.LNX.4.64.0710071457580.23070@iabervon.org>
Hi,
On Sun, 7 Oct 2007, Daniel Barkalow wrote:
> For that matter, gitweb is essentially a limited porcelain. And this
> points out that all VCSes have alternative porcelains, but git is
> unusual in having convenient plumbing to support and encourage this.
I do not consider viewers "porcelain". And gitweb is essentially just a
viewer.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Make strbuf_cmp inline, constify its arguments and optimize it a bit
From: Alex Riesen @ 2007-10-07 22:31 UTC (permalink / raw)
To: Wincent Colaiuta
Cc: David Kastrup, Miles Bader, Pierre Habouzit, Timo Hirvonen, git,
Junio C Hamano
In-Reply-To: <EF81F7DD-73C7-4B6F-92D2-4A143CA05365@wincent.com>
Wincent Colaiuta, Mon, Oct 08, 2007 00:12:17 +0200:
> El 7/10/2007, a las 23:54, Alex Riesen escribió:
>
> >>... All the rest pretty much
> >>was worse than what we started from in that it needed to reevaluate
> >>more conditions and turned out more complicated and obfuscate even to
> >>the human reader.
> >
> >it _is_ smaller. And it is _measurably_ faster on that thing I have at
> >home (and old p4).
>
> Can we see the numbers and the steps used to obtain them? I'm also a
> little bit confused about how an inlined function can lead to a
> smaller executable... or did you just mean lines-of-code?
I did mean the bytes of object code. I never said it produces a
smaller executable.
I compiled with gcc -O2 and -O4, gcc 4.1.2 (Ubuntu 4.1.2-0ubuntu4).
Cut the functions out into their own files and compile them to get the
object code. Compile with -S (assembly) to examine the generated code.
Compare.
#include <stdint.h>
#include <unistd.h>
#include <stdlib.h>
#include <sys/time.h>
#include <stdio.h>
#include <string.h>
struct strbuf {
size_t alloc;
size_t len;
char *buf;
};
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;
}
int strbuf_cmp1(struct strbuf *a, struct strbuf *b)
{
int cmp;
if (a->len < b->len) {
cmp = memcmp(a->buf, b->buf, a->len);
return cmp ? cmp : -1;
} else {
cmp = memcmp(a->buf, b->buf, b->len);
return cmp ? cmp : a->len != b->len;
}
}
int main(int argc, char *argv[], char *envp[])
{
struct strbuf s1 = {
.alloc = 0,
.len = 50,
.buf = "01234567890123456789012345678901234567890123456789",
};
struct strbuf s2 = {
.alloc = 0,
.len = 50,
.buf = "0123456789012345678901234567890123456789",
};
struct strbuf s3 = {
.alloc = 0,
.len = 50,
.buf = "0123456789012345678901234567890123456789012345678x",
};
struct timeval tv1, tv2, diff;
unsigned n;
int result;
#define CYCLES 0xffffffffu
strbuf_cmp1(&s1, &s2);
strbuf_cmp1(&s2, &s3);
result = 0;
gettimeofday(&tv1, NULL);
for (n = CYCLES; n--; ) {
result += strbuf_cmp1(&s1, &s2);
result += strbuf_cmp1(&s2, &s3);
result += strbuf_cmp1(&s1, &s3);
result += strbuf_cmp1(&s1, &s1);
result += n;
}
gettimeofday(&tv2, NULL);
timersub(&tv2, &tv1, &diff);
printf("ph=%ld.%ld (%d)\n", diff.tv_sec, diff.tv_usec, result);
strbuf_cmp2(&s1, &s2);
strbuf_cmp2(&s2, &s3);
result = 0;
gettimeofday(&tv1, NULL);
for (n = CYCLES; n--; ) {
result += strbuf_cmp2(&s1, &s2);
result += strbuf_cmp2(&s2, &s3);
result += strbuf_cmp2(&s1, &s3);
result += strbuf_cmp2(&s1, &s1);
result += n;
}
gettimeofday(&tv2, NULL);
timersub(&tv2, &tv1, &diff);
printf("ar=%ld.%ld (%d)\n", diff.tv_sec, diff.tv_usec, result);
return 0;
}
^ 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 22:24 UTC (permalink / raw)
To: Alex Riesen; +Cc: Frank Lichtenheld, git
In-Reply-To: <20071007221920.GF2765@steel.home>
On 10/7/07, Alex Riesen <raa.lkml@gmail.com> wrote:
<snip>
> 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?
Elijah
^ permalink raw reply
* Re: [PATCH] setup/rev-parse: allow HEAD to be spelled 'head'
From: Sam Vilain @ 2007-10-07 22:23 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0710071747340.4174@racer.site>
Johannes Schindelin wrote:
> P.S.: seems you have quite cute coworkers.
http://xkcd.com/322/
^ 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 22:19 UTC (permalink / raw)
To: Elijah Newren; +Cc: Frank Lichtenheld, git
In-Reply-To: <51419b2c0710071500x318ee734n9db6ca9e6daa3196@mail.gmail.com>
Elijah Newren, Mon, Oct 08, 2007 00:00:51 +0200:
> On 10/7/07, Frank Lichtenheld <frank@lichtenheld.de> wrote:
> > On Sun, Oct 07, 2007 at 03:23:59PM -0600, Elijah Newren wrote:
> > > The following set of instructions will duplicate my problem with a
> > > smaller repo; why is the local git repository bigger after running
> > > git-filter-branch rather than smaller as I'd expect? I'm probably
> > > missing something obvious, but I have no idea what it is.
> >
> > The usual suspect would be the reflog.
>
> The git-filter-branch documentation mentions creating refs/original
> under .git. Unfortunately, it doesn't contain any links or
> documentation on how I'd clean those out and I haven't been able to
> figure it out. I asked on #git how to clean these out and got some
> answers that didn't work (git branch -d and something else I don't
> remember).
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)
^ permalink raw reply
* Re: [PATCH] Make strbuf_cmp inline, constify its arguments and optimize it a bit
From: Wincent Colaiuta @ 2007-10-07 22:12 UTC (permalink / raw)
To: Alex Riesen
Cc: David Kastrup, Miles Bader, Pierre Habouzit, Timo Hirvonen, git,
Junio C Hamano
In-Reply-To: <20071007215432.GC2765@steel.home>
El 7/10/2007, a las 23:54, Alex Riesen escribió:
>> ... All the rest pretty much
>> was worse than what we started from in that it needed to reevaluate
>> more conditions and turned out more complicated and obfuscate even to
>> the human reader.
>
> it _is_ smaller. And it is _measurably_ faster on that thing I have at
> home (and old p4).
Can we see the numbers and the steps used to obtain them? I'm also a
little bit confused about how an inlined function can lead to a
smaller executable... or did you just mean lines-of-code?
Cheers,
Wincent
^ 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 22:08 UTC (permalink / raw)
To: Elijah Newren; +Cc: git
In-Reply-To: <51419b2c0710071423y1b194f22gb6ccaa57303029d1@mail.gmail.com>
Elijah Newren, Sun, Oct 07, 2007 23:23:59 +0200:
> # Try to recompress and clean up, then check the new size
> git gc --aggressive --prune
> du -ks . # 10580K !?!?!?
> du -ks .git # 10564K
git-filter-branch makes a backup of your original references:
$ git filter-branch --help
...
Always verify that the rewritten version is correct: The original refs,
if different from the rewritten ones, will be stored in the namespace
refs/original/.
...
These will keep your big files in repository.
^ 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 22:00 UTC (permalink / raw)
To: Frank Lichtenheld; +Cc: git
In-Reply-To: <20071007213817.GJ31659@planck.djpig.de>
On 10/7/07, Frank Lichtenheld <frank@lichtenheld.de> wrote:
> On Sun, Oct 07, 2007 at 03:23:59PM -0600, Elijah Newren wrote:
> > The following set of instructions will duplicate my problem with a
> > smaller repo; why is the local git repository bigger after running
> > git-filter-branch rather than smaller as I'd expect? I'm probably
> > missing something obvious, but I have no idea what it is.
>
> The usual suspect would be the reflog.
The git-filter-branch documentation mentions creating refs/original
under .git. Unfortunately, it doesn't contain any links or
documentation on how I'd clean those out and I haven't been able to
figure it out. I asked on #git how to clean these out and got some
answers that didn't work (git branch -d and something else I don't
remember). So...how do I fix the reflog, and then repack to have a
pack under 11MB in size?
Thanks,
Elijah
^ permalink raw reply
* Re: [PATCH] Make strbuf_cmp inline, constify its arguments and optimize it a bit
From: Alex Riesen @ 2007-10-07 21:57 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <851wc6lwkc.fsf@lola.goethe.zz>
David Kastrup, Sun, Oct 07, 2007 18:27:15 +0200:
> Alex Riesen <raa.lkml@gmail.com> writes:
> >> > +static inline int strbuf_cmp(const struct strbuf *a, const 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;
> >> > +}
> >>
> >> My guess is that you are conflating two issues about speed here: the
> >> inlining will like speed the stuff up. But having to evaluate the
> >> (a->len < b->len) comparison twice will likely slow it down.
> >
> > 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!
^ permalink raw reply
* Re: [PATCH] Make strbuf_cmp inline, constify its arguments and optimize it a bit
From: Alex Riesen @ 2007-10-07 21:54 UTC (permalink / raw)
To: David Kastrup
Cc: Miles Bader, Pierre Habouzit, Timo Hirvonen, git, Junio C Hamano
In-Reply-To: <857ilylxhm.fsf@lola.goethe.zz>
David Kastrup, Sun, Oct 07, 2007 18:07:17 +0200:
> Miles Bader <miles@gnu.org> writes:
>
> > Pierre Habouzit <madcoder@debian.org> writes:
> >>> strbuf->buf is always non-NULL and NUL-terminated so you could just do
> >>>
> >>> static inline int strbuf_cmp(const struct strbuf *a, const struct strbuf *b)
> >>> {
> >>> int len = a->len < b->len ? a->len : b->len;
> >>> return memcmp(a->buf, b->buf, len + 1);
> >>> }
> >>
> >> doesn't work, because a buffer can have (in some very specific cases)
> >> an embeded NUL.
> >
> > Couldn't you then just do:
> >
> > int len = a->len < b->len ? a->len : b->len;
> > int cmp = memcmp(a->buf, b->buf, len);
> > if (cmp == 0)
> > cmp = b->len - a->len;
> > return cmp;
> >
> > [In the case where one string is a prefix of the other, then the longer
> > one is "greater".]
> >
> > ?
>
> I fail to see where this variant is simpler than what we started the
> journey of simplification from.
>
> The only change I consider worth checking from the whole series in
> this thread is making the function inline.
It also makes arguments const (which admittedly wont make it faster).
> ... All the rest pretty much
> was worse than what we started from in that it needed to reevaluate
> more conditions and turned out more complicated and obfuscate even to
> the human reader.
it _is_ smaller. And it is _measurably_ faster on that thing I have at
home (and old p4).
^ permalink raw reply
* Re: [PATCH 1/2] Have a filter_start/filter_end API.
From: Alex Riesen @ 2007-10-07 21:50 UTC (permalink / raw)
To: Pierre Habouzit, Linus Torvalds, Junio C Hamano, git
In-Reply-To: <20071007165218.GE10024@artemis.corp>
Pierre Habouzit, Sun, Oct 07, 2007 18:52:18 +0200:
> So, maybe there is a way to rename strbuf_start_filter so that it's
> more straightforward. The way to use the API is:
>
> @ char *to_free = NULL;
> @ if ((src is inside dst && need_realloc) || operation is not in-place)
> @ to_free = strbuf_detach(dst, NULL);
> @ strbuf_make_room(dst, needed_size);
Why do you have to play these games with src being inside/outside?
Don't you know where src already is? AFAICS in convert.c crlf_to_git -
you do. And everywhere else you know this fact too.
> // do whatever you want with src and dst
>
> free(to_free);
>
> strbuf_start_filter tries to implement the block marked with `@'. Of
> course:
> * need_realloc == (needed_size >= dst->alloc)
> * src is inside dst means:
> src > dst->buf && src < dst->buf + dst->alloc
in convert.c it is never "inside". It is _exactly_ the ->buf.
No need for generic "inside" check. Just test if src == ->buf.
And AFAICS, there is no other users of the function.
> Though, those are both things that I find ugly to "know" in convert.c.
> How things are allocated in strbufs is one of the few things we don't
> want to assume anywhere outside of the strbuf module.
src is outside of strbuf scope. It is not internal to struct strbuf.
The caller must already know if it is inside of the given strbuf
instance.
need_realloc is covered by make_room, isn't it?
I'd suggest just fix the caller, it is simple in convert.c: just use
ret, which contains exactly this information. If you insist on editing
in-place, which makes your routines really need the in-placeability
informaion. Just give it to them, better explicitely. All of this
makes the routines very convert.c specific, which is the reason why I
argument to have them just there and nowhere else.
Alternatively, one can memdup ->buf (as it is the input for next
filter) every time a filter modifies it (which is safe, but simple,
slow, requires memory, and may fragment heap):
/* simplified */
int convert_to_git(const char *path, const char *src, size_t len, struct strbuf *dst)
{
int crlf = CRLF_GUESS;
int ident = 0, ret = 0;
char *filter = NULL;
const char *tmp = src;
ret |= apply_filter(path, tmp, len, dst, filter);
if (ret) {
tmp = xmemdupz(dst->buf, dst->len);
len = dst->len;
}
if (crlf_to_git(path, tmp, len, dst, crlf)) {
ret |= 1;
if (tmp != src)
free((void*)tmp);
tmp = xmemdupz(dst->buf, dst->len);
len = dst->len;
}
ret |= ident_to_git(path, tmp, len, dst, ident);
if (tmp != src)
free((void*)tmp);
return ret;
}
It is just to show that nothing like strbuf_start_filter is _needed_
at all.
^ permalink raw reply
* Re: git fetch -- double fetch
From: Andy Whitcroft @ 2007-10-07 21:44 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0710071728570.4174@racer.site>
On Sun, Oct 07, 2007 at 05:29:38PM +0100, Johannes Schindelin wrote:
> Hi,
>
> 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.
-apw
^ permalink raw reply
* Re: [PATCH] git-svn: respect Subversion's [auth] section configuration values
From: Eric Wong @ 2007-10-07 21:43 UTC (permalink / raw)
To: Eygene Ryabinkin; +Cc: Sam Vilain, git
In-Reply-To: <20071007101437.GB3943@void.codelabs.ru>
Eygene Ryabinkin <rea-git@codelabs.ru> wrote:
> Eric, Sam, good day.
> Sun, Oct 07, 2007 at 02:24:43PM +1300, Sam Vilain wrote:
> > Eygene Ryabinkin wrote:
> > > Parameters 'store-passwords' and 'store-auth-creds' from Subversion's
> > > configuration (~/.subversion/config) were not respected. This was
> > > fixed: the default values for these parameters are set to 'yes' to
> > > follow Subversion behaviour.
> > >
> >
> > I saw this in the svn api before. It really is a strange API, requiring
> > the user to get things like this right.
>
> Yes, the need to parse the configuration and set some flags is
> rather strange. Looks like nobody cared to stuff the code like
> I had added to the configuration file parsing routines.
I think I started to look at it a while back and forgot about it :)
> > You can use no warnings 'once';
>
> Great, thanks for the pointer! Eric, do you want me to produce
> another patch or you'll correct mine?
Go ahead and produce another patch. I haven't had much time to
work on git lately.
--
Eric Wong
^ permalink raw reply
* Re: Trying to use git-filter-branch to compress history by removing large, obsolete binary files
From: Frank Lichtenheld @ 2007-10-07 21:38 UTC (permalink / raw)
To: Elijah Newren; +Cc: git
In-Reply-To: <51419b2c0710071423y1b194f22gb6ccaa57303029d1@mail.gmail.com>
On Sun, Oct 07, 2007 at 03:23:59PM -0600, Elijah Newren wrote:
> The following set of instructions will duplicate my problem with a
> smaller repo; why is the local git repository bigger after running
> git-filter-branch rather than smaller as I'd expect? I'm probably
> missing something obvious, but I have no idea what it is.
The usual suspect would be the reflog.
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* Re: Status of kha/experimental
From: Karl Hasselström @ 2007-10-07 21:33 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Yann Dirson, David Kågedal, Git Mailing List
In-Reply-To: <b0943d9e0710071418o6a664981i9d31db980c04bc50@mail.gmail.com>
On 2007-10-07 22:18:44 +0100, Catalin Marinas wrote:
> How stable is the kha/experimental branch? Since there are more and
> more bugs added to the tracking system, I'll have to start looking
> at them before a 0.14 release. Is it worth merging the
> kha/experimental now or we better wait for after 0.14?
The idea is that experimental contains changes that need testing, but
may not yet be ready for your master. (They are generally safe,
though; I run StGit from my experimental branch at work, for example.)
When I decide that they are ready, I move them to safe. If there are
any patches you feel should be in safe rather than experimental, just
ask. Or you could just take them directly from experimental without
asking, of course. :-)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* [PATCH] git-gui: offer a list of recent repositories on startup
From: Steffen Prohaska @ 2007-10-07 21:28 UTC (permalink / raw)
To: spearce; +Cc: git, msysgit, Steffen Prohaska
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.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
git-gui/lib/choose_repository.tcl | 47 +++++++++++++++++++++++++++++++++++++
1 files changed, 47 insertions(+), 0 deletions(-)
The commit is also available on branch
steffen/git-gui-openrecent in 4msysgit.
Shawn,
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.
Steffen
diff --git a/git-gui/lib/choose_repository.tcl b/git-gui/lib/choose_repository.tcl
index 16bf67c..bfc8780 100644
--- a/git-gui/lib/choose_repository.tcl
+++ b/git-gui/lib/choose_repository.tcl
@@ -116,9 +116,26 @@ constructor pick {} {
-text [mc "Open Existing Repository"] \
-variable @action \
-value open
+ label $w_body.space
+ label $w_body.recentlabel \
+ -anchor w \
+ -text "Select Recent Repository:"
+ listbox $w_body.recentlist \
+ -relief flat \
+ -width 50 \
+ -height 10 \
+ -exportselection false \
+ -selectmode select
+ foreach p [_get_recentrepos] {
+ $w_body.recentlist insert end $p
+ }
+ bind $w_body.recentlist <<ListboxSelect>> [cb _open_recent]
pack $w_body.new -anchor w -fill x
pack $w_body.clone -anchor w -fill x
pack $w_body.open -anchor w -fill x
+ pack $w_body.space -anchor w -fill x
+ pack $w_body.recentlabel -anchor w -fill x
+ pack $w_body.recentlist -anchor w -fill x
pack $w_body -fill x -padx 10 -pady 10
frame $w.buttons
@@ -171,6 +188,34 @@ method _invoke_next {} {
}
}
+proc _get_recentrepos {} {
+ set recent [list]
+ foreach p [get_config gui.recentrepos] {
+ if {[file isdirectory [file join $p .git]]} {
+ lappend recent $p
+ }
+ }
+ return [lsort $recent]
+}
+
+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
+}
+
+method _open_recent {} {
+ set id [$w_body.recentlist curselection]
+ set local_path [$w_body.recentlist get $id]
+ _do_open2 $this
+}
+
method _next {} {
destroy $w_body
_do_$action $this
@@ -893,6 +938,8 @@ method _do_open2 {} {
return
}
+ _append_recentrepos $local_path
+
set ::_gitdir .git
set ::_prefix {}
set done 1
--
1.5.3.mingw.1.110.gef4c8
^ permalink raw reply related
* Trying to use git-filter-branch to compress history by removing large, obsolete binary files
From: Elijah Newren @ 2007-10-07 21:23 UTC (permalink / raw)
To: git
Hi,
I'm using git-cvsimport to import some CVS repos, which unfortunately
included dozens of large regression test output files in their ancient
history...some of which measure hundreds of megabytes in size. I'd
like to prune them out of the git history (I don't have access to
prune them out of the CVS history), but I'm running into problems.
The following set of instructions will duplicate my problem with a
smaller repo; why is the local git repository bigger after running
git-filter-branch rather than smaller as I'd expect? I'm probably
missing something obvious, but I have no idea what it is.
The steps:
# 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
Thanks,
Elijah
^ permalink raw reply
* Status of kha/experimental
From: Catalin Marinas @ 2007-10-07 21:18 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Yann Dirson, David Kågedal, Git Mailing List
Hi Karl,
How stable is the kha/experimental branch? Since there are more and
more bugs added to the tracking system, I'll have to start looking at
them before a 0.14 release. Is it worth merging the kha/experimental
now or we better wait for after 0.14?
Thanks.
--
Catalin
^ permalink raw reply
* Re: [PATCH] Support tags in uncommit - use git_id instead of rev_parse
From: Catalin Marinas @ 2007-10-07 21:06 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <1191447892.31052.5.camel@dv>
On 03/10/2007, Pavel Roskin <proski@gnu.org> wrote:
> On Wed, 2007-10-03 at 21:35 +0100, Catalin Marinas wrote:
>
> > Without this patch, the 'stg uncommit -t patch' fails with 'Unknown
> > revision: patch'. With the patch applied, it still fails but with
> > 'Commit ... does not have exactly one parent'. I don't say that the
> > first one is good but I don't think the latter is clearer. The 'stg
> > uncommit --help' states that the '--to' option takes a commit argument
> > but if one passes a patch name the error message gets pretty
> > confusing.
>
> Actually, 'Commit ... does not have exactly one parent' means that stg
> misinterpreted the patch name as some non-existing hash and started
> iterating back until it hit the first merge.
>
> Perhaps stgit should make sure that the hash is valid before walking the
> commit tree. If it's not, stgit could provide a better message.
OK, I applied your patch but I'll have to look into the error message
to make it more meaningful. Thanks.
--
Catalin
^ permalink raw reply
* Re: [StGIT PATCH] Better diagnostic for wrong branch configuration.
From: Catalin Marinas @ 2007-10-07 21:04 UTC (permalink / raw)
To: Yann Dirson; +Cc: git
In-Reply-To: <20071005204452.30902.60246.stgit@gandelf.nowhere.earth>
On 05/10/2007, Yann Dirson <ydirson@altern.org> wrote:
> If the branch.*.merge parameter does not name a valid remote head,
> stgit would not rebase after a fetch, and would write instead
> 'Rebasing to "None" ... done'.
Applied, thanks. I'll try it tomorrow with my StGIT over SVN
configuration as well (it works OK with the latter patches).
--
Catalin
^ permalink raw reply
* [PATCH] makefile: Add a cscope target
From: Kristof Provost @ 2007-10-07 20:45 UTC (permalink / raw)
To: Frank Lichtenheld; +Cc: git, Alex Riesen
In-Reply-To: <20071006142442.GA4635@luggage>
The current makefile supports ctags but not cscope. Some people prefer
cscope (I do), so this patch adds a cscope target.
Signed-off-by: Kristof Provost <Kristof@provost-engineering.be>
---
This version of the patch includes the fix for the missing [ Frank spotted,
and adds 'cscope*' to the .gitignore list as Alex suggested.
While I did that I noticed that 'tags' and 'TAGS' were also missing.
It's also in the (hopefully) right format. Thank to Johannes Schindelin
for pointing out my mistakes.
.gitignore | 3 +++
Makefile | 8 ++++++--
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/.gitignore b/.gitignore
index e0b91be..62afef2 100644
--- a/.gitignore
+++ b/.gitignore
@@ -171,3 +171,6 @@ config.status
config.mak.autogen
config.mak.append
configure
+tags
+TAGS
+cscope*
diff --git a/Makefile b/Makefile
index 8db4dbe..e2790c8 100644
--- a/Makefile
+++ b/Makefile
@@ -947,6 +947,10 @@ tags:
$(RM) tags
$(FIND) . -name '*.[hcS]' -print | xargs ctags -a
+cscope:
+ $(RM) cscope*
+ $(FIND) . -name '*.[hcS]' -print | xargs cscope -b
+
### Detect prefix changes
TRACK_CFLAGS = $(subst ','\'',$(ALL_CFLAGS)):\
$(bindir_SQ):$(gitexecdir_SQ):$(template_dir_SQ):$(prefix_SQ)
@@ -1093,7 +1097,7 @@ clean:
$(LIB_FILE) $(XDIFF_LIB)
$(RM) $(ALL_PROGRAMS) $(BUILT_INS) git$X
$(RM) $(TEST_PROGRAMS)
- $(RM) *.spec *.pyc *.pyo */*.pyc */*.pyo common-cmds.h TAGS tags
+ $(RM) *.spec *.pyc *.pyo */*.pyc */*.pyo common-cmds.h TAGS tags cscope*
$(RM) -r autom4te.cache
$(RM) configure config.log config.mak.autogen config.mak.append config.status config.cache
$(RM) -r $(GIT_TARNAME) .doc-tmp-dir
@@ -1111,7 +1115,7 @@ endif
$(RM) GIT-VERSION-FILE GIT-CFLAGS GIT-GUI-VARS
.PHONY: all install clean strip
-.PHONY: .FORCE-GIT-VERSION-FILE TAGS tags .FORCE-GIT-CFLAGS
+.PHONY: .FORCE-GIT-VERSION-FILE TAGS tags cscope .FORCE-GIT-CFLAGS
### Check documentation
#
--
1.5.3.4.207.g1aae
^ permalink raw reply related
* Re: How to pick a commit from another git tree?
From: Alex Riesen @ 2007-10-07 20:10 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: git
In-Reply-To: <000101c80907$d461a810$04ac10ac@Jocke>
Joakim Tjernlund, Sun, Oct 07, 2007 19:31:00 +0200:
> This is probably a somewhat stupid question but I havn't had a need until now so here goes:
> There is a commit in David Millers tree:
> http://git.kernel.org/?p=linux/kernel/git/davem/bak-net-2.6.24.git;a=commit;h=bbb4c0c35a4c2aed5e025b668c8dfc99c5b74cff
> that hasn't made it into 2.6.23, but will go into 2.6.24.
> I need this fix on top of 2.6.23(once it is released).
$ git fetch git://git.kernel.org/pub/scm/linux/kernel/git/davem/bak-net-2.6.24.git
$ git cherry-pick bbb4c0c35a4c2aed5e025b668c8dfc99c5b74cff
> Now I wonder how to best add this fix to my tree. Once this fix hits linus tree and I pull
> linus tree, I don't wan't a conflict as I already have this fix in my tree.
Depending on the state the Davids tree ends up when it is merge into
Linus' tree you may or may not get a conflict. It is not in your hands
either way.
> Should I just pull Davids tree? Or should I cherry-pick this one commit?
> Or something else?
I would just cherry-pick it, and revert it (or hard-reset my tree to
Linus' tree) if it conflicts later.
^ permalink raw reply
* Re: [PATCH 1/4] git-gui i18n: Add more words to glossary.
From: Christian Stimming @ 2007-10-07 20:42 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Johannes Schindelin, git
In-Reply-To: <20071007180559.GA2137@spearce.org>
Am Sonntag, 7. Oktober 2007 20:05 schrieb Shawn O. Pearce:
> Christian Stimming <stimming@tuhh.de> wrote:
> > Signed-off-by: Christian Stimming <stimming@tuhh.de>
> >
> > ---
> > po/glossary/git-gui-glossary.pot | 12 ++++++++++--
> > po/glossary/git-gui-glossary.txt | 2 ++
> > 2 files changed, 12 insertions(+), 2 deletions(-)
>
> What version is this series applied to? It rejects against my
> currently published master on repo.or.cz.
It rejects? The patch were intended against master on git-gui.git on
repo.or.cz; the base for the patches was
1952aa1d5735ccbedd832620e43db3e03fc77088
I might have messed up some line wrappings... if that is the case, I can of
course resend and try harder to send them correctly.
Christian
^ permalink raw reply
* Re: Many gits are offline this week
From: Randal L. Schwartz @ 2007-10-07 19:37 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Paolo Ciarrocchi, git
In-Reply-To: <20071007170153.GX2137@spearce.org>
>>>>> "Shawn" == Shawn O Pearce <spearce@spearce.org> writes:
Shawn> What, no mention of git-gui as a porcelain? It has more users
Shawn> than qgit according to the survey. Maybe rephrase the porcelains
Shawn> on slide 15 as:
Shawn> Other porcelain exists:
Shawn> - StGit ("stacked git"), guilt
Shawn> - tig (curses-based viewer)
Shawn> - qgit, git-gui
git-gui should have been mentioned with "the git distro". Fixed.
Shawn> On slide 26 you say "gitk mytopic origin" shows the changes back to
Shawn> the common ancestor. That's what "gitk mytopic...origin" would do.
Shawn> Note the three dots instead of the space. The space will cause
Shawn> gitk to show all history back to the beginning of time.
Darned inconsistency! Sometimes, it's a space. Sometimes it's two dots.
Sometimes, it's three dots. I know, there's reasons for that, but it's still
hard for the newbie.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ 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