* Re: [ANNOUNCE] CGit v0.1-pre
From: Lars Hjemli @ 2006-12-11 18:38 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0612111016220.12500@woody.osdl.org>
On 12/11/06, Linus Torvalds <torvalds@osdl.org> wrote:
>
>
> On Mon, 11 Dec 2006, Lars Hjemli wrote:
> >
> > Ok. Code speeks louder than words, so I'll blatantly paste the key functions:
>
> Yeah, they're still buggy:
>
> > int cache_unlock(struct cacheitem *item)
> > {
> > close(item->fd);
> > return (rename(fmt("%s.lock", item->name), item->name) == 0);
> > }
> ...
> > if (!cache_exist(item)) {
> > if (!cache_lock(item)) {
> > sleep(1);
> > goto top;
> > }
> > if (!cache_exist(item))
> > cgit_fill_cache(item);
> > cache_unlock(item);
>
> What do you think happens if that last "cache_exist()" returned true?
>
> That's right: the "cache_unlock()" will now OVERWRITE the valid cache with
> the (empty) lock-file that you didn't fill in.
>
> Oops.
>
Wow, that's embarrassing.
Thanks for the debugging, I'll try to actually fix it this time :-)
--
^ permalink raw reply
* Re: Collection of stgit issues and wishes
From: Yann Dirson @ 2006-12-11 18:41 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Catalin Marinas, git
In-Reply-To: <200612110002.05847.jnareb@gmail.com>
On Mon, Dec 11, 2006 at 12:02:05AM +0100, Jakub Narebski wrote:
> Catalin Marinas wrote:
> > On 10/12/06, Jakub Narebski <jnareb@gmail.com> wrote:
>
> >> The git commands StGit uses to perform operations automatically record
> >> changes in branches in reflog. What StGit does not provide is the "reason".
> >> You do use git-update-ref?
> >
> > Yes, only for updating HEAD. The refs in refs/patches/<branch>/ are
> > written directly. I initialy wanted to add patch history support using
> > reflogs and added "git-update-ref -m ..." for the patch commits but I
> > found slow the pushing operation a bit. Do you only want to track the
> > reflogs for HEAD?
>
> Yes, I want for StGit to provide reasons when updating HEAD.
Apart from the use-case you described in a later mail, this could
provide a path to series-level logging (one of the points in my list);
since the meaningful changes in a series involve changing the HEAD, we
would the have most the needed info that way.
Operations just shuffling the stack (eg. "float -s", or "push XXX;
push --undo") would probably require putting the series file itself
^ permalink raw reply
* Re: [RFC \ WISH] Add -o option to git-rev-list
From: Marco Costalba @ 2006-12-11 18:59 UTC (permalink / raw)
To: Linus Torvalds
Cc: Git Mailing List, Junio C Hamano, Alex Riesen, Shawn Pearce
In-Reply-To: <Pine.LNX.4.64.0612111003140.12500@woody.osdl.org>
On 12/11/06, Linus Torvalds <torvalds@osdl.org> wrote:
>
>
>
> However, you seem to continually ignore the thing I've asked you to do
> several times: try with a cold-cache situation.
Yes. I will test it. I was testing with warm cache also to my
curiosity about comparing pipes with temporary file reading as data
exchange facility. So I needed to avoid HD artifacts.
>
>
> At that point, you'd actually do something that gitk can't do at all,
> namely work well for the cold-cache not-very-packed large-repository
> case. ]
>
Removing --topo-order from launch parameters is very simple, see from
gitstartup.cpp:
bool Git::startRevList(SCRef args, FileHistory* fh) {
QString initCmd("git rev-list --header --boundary --parents ");
if (!isMainHistory(fh)) {
// fetch history from all branches so any revision in
// main view that changes the file is always found
SCRef allBranches = getAllRefSha(BRANCH).join(" ");
initCmd.append("--remove-empty " + allBranches + " -- ");
} else
initCmd.append("--topo-order ");
return startParseProc(initCmd + args, fh);
}
It is already removed from file history fetching because there the
history it's _almost_ linear and you gain the speed without noticing
the different graph layout. But for main view I fear that complicated
branch structures could became difficult to follow without
--topo-order. Perhaps an option in settings?
> To see this in practice (even with hot-caches), do something like the
> following on the full historic Linux archive:
>
> time sh -c "git rev-list HEAD | head"
> time sh -c "git rev-list --topo-order HEAD | head"
>
> where for me, the firstone takes 0.002s, and the second one takes 0.878s.
>
This is the data:
$ pwd
/git/linux-2.6
bash-3.1$ time sh -c "git rev-list HEAD | head"
200d018eff4be3a1fb9823441cfcebb7de86a677
f0647a52974daccbe20990fb6341f07792445fe0
c25c79d80e02db1bd993426f979c5f1b42a0f132
9fd32cfbb602f3e5e898faa61d83c4a7897bd48a
ed99e2bc1dc5dc54eb5a019f4975562dbef20103
773ff78838ca3c07245e45c06235e0baaa5f710a
52ffe760ea9ec407292d093c3f06c1cda5187228
14b36af46a1d3652aff6734ea24816995dff8123
eb991b39385c7b04923d701764a34694ec54b53d
88032b322a38b37335c8cb2e3473a45c81d280eb
0.08user 0.02system 0:00.10elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+3631minor)pagefaults 0swaps
bash-3.1$ time sh -c "git rev-list --topo-order HEAD | head"
200d018eff4be3a1fb9823441cfcebb7de86a677
f0647a52974daccbe20990fb6341f07792445fe0
c25c79d80e02db1bd993426f979c5f1b42a0f132
9fd32cfbb602f3e5e898faa61d83c4a7897bd48a
ed99e2bc1dc5dc54eb5a019f4975562dbef20103
773ff78838ca3c07245e45c06235e0baaa5f710a
52ffe760ea9ec407292d093c3f06c1cda5187228
14b36af46a1d3652aff6734ea24816995dff8123
eb991b39385c7b04923d701764a34694ec54b53d
33ec32fae0e2c4433bfd1e74cbde6cb16604a719
2.84user 0.12system 0:03.05elapsed 97%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+12086minor)pagefaults 0swaps
Also the long awaited ;-)
$ time sh -c "git rev-list --header --boundary --parents --topo-order
HEAD | cat > /dev/null"
3.75user 0.55system 0:04.42elapsed 97%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+18822minor)pagefaults 0swaps
$ time sh -c "git rev-list --header --boundary --parents --topo-order
HEAD > /tmp/tmp.txt; cat /tmp/tmp.txt > /dev/null"
3.50user 0.30system 0:03.92elapsed 97%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+18800minor)pagefaults 0swaps
^ permalink raw reply
* Re: [RFC \ WISH] Add -o option to git-rev-list
From: Linus Torvalds @ 2006-12-11 19:25 UTC (permalink / raw)
To: Marco Costalba
Cc: Git Mailing List, Junio C Hamano, Alex Riesen, Shawn Pearce
In-Reply-To: <e5bfff550612111059g35f1aa2dmdead17a60f5dfca8@mail.gmail.com>
On Mon, 11 Dec 2006, Marco Costalba wrote:
>
> $ time sh -c "git rev-list --header --boundary --parents --topo-order HEAD | cat > /dev/null"
> $ time sh -c "git rev-list --header --boundary --parents --topo-order HEAD > /tmp/tmp.txt; cat /tmp/tmp.txt > /dev/null"
Btw, for me the numbers aren't stable enough to be al lthat final, but
doing it multiple times on the kernel archive I get:
real 0m0.947s
real 0m1.046s
real 0m0.943s
real 0m0.868s
for the pipe case, and
real 0m0.953s
real 0m1.056s
real 0m1.060s
real 0m0.968s
for the temp-file. IOW, no real difference. Just doing the "> /dev/null"
directly is more consistent (no task-switching, SMP effects, or cache
conflicts) at
real 0m0.806s
real 0m0.806s
real 0m0.805s
real 0m0.808s
but one recurrent theme is definitely true: the "cat" part is a noticeable
overhead. But that in itself means that git-rev-list is just so efficient
that even just basically copying its output is going to be measurable.
Which is obviously a good thing, but it means that it's not very
interesting in the big picture (ie I bet the real overheads are going to
be elsewhere if you actually expect to draw anything on the screen).
^ permalink raw reply
* Re: git-svnimport breakage as of git-1.4.4
From: Dongsheng Song @ 2006-12-11 20:00 UTC (permalink / raw)
To: Sasha Khapyorsky; +Cc: Daniel Drake, git
In-Reply-To: <20061210114735.GA11107@sashak.voltaire.com>
Sorry, I assume you have see http://tortoisesvn.tigris.org/:
username : guest
password : ""
2006/12/10, Sasha Khapyorsky <sashak@voltaire.com>:
> On 11:49 Sun 10 Dec , Dongsheng Song wrote:
> > I met the broken too, when I downgrade to 1.4.3.4, it's fine.
> >
> > I have not test your patch, but you can try your self,
> >
> > http://tortoisesvn.tigris.org/svn/tortoisesvn
> >
> > and the master branch(today) fail between r6000~r7000 too
>
> Thanks for the link. but I cannot access - this requires
> username/password authentication.
>
> Sasha
^ permalink raw reply
* Re: [RFC \ WISH] Add -o option to git-rev-list
From: Josef Weidendorfer @ 2006-12-11 20:28 UTC (permalink / raw)
To: Marco Costalba
Cc: Linus Torvalds, Git Mailing List, Junio C Hamano, Alex Riesen,
Shawn Pearce
In-Reply-To: <e5bfff550612111059g35f1aa2dmdead17a60f5dfca8@mail.gmail.com>
On Monday 11 December 2006 19:59, Marco Costalba wrote:
> On 12/11/06, Linus Torvalds <torvalds@osdl.org> wrote:
> >
> >
> >
> > However, you seem to continually ignore the thing I've asked you to do
> > several times: try with a cold-cache situation.
>
> Yes. I will test it. I was testing with warm cache also to my
> curiosity about comparing pipes with temporary file reading as data
> exchange facility. So I needed to avoid HD artifacts.
Hi,
I just looked at the QProcess implementation in Qt 3.3.6, as I was
curious.
Qt does a big select() call in the event loop. If there is data
available from the child process, it is reading in chunks of a
maximum of 4096 bytes, with a select() call inbetween to see if
there is still data available. After every read, the read data
is concatenated into the read buffer.
For the slow/cold cache case, this probably is the best *if* the
consumer application can act as fast as possible when data is
sent. Which makes it a good fit to avoid --topo-order and do
some redrawing of the graph yourself if needed. For sure, this
gives the fastest visual appeareance. You could start filling
the list after e.g. 30 revs are read.
Obviously, there is some possibility for improvement _when_ you
know that you want to read in large amounts of data in big
chunks, given that QProcess uses at least two system calls every
4 kB.
A general question: How many context switches are involved in such
a producer/consumer scenario, given that the consumer writes one
line at a time, and the consumer uses poll/select to wait for the
data?
Is there some possibility to make the kernel write-combine single
small producer writes into bigger chunks, which will be delivered
at once (or smaller data only after a small timeout)?
^ permalink raw reply
* Re: [RFC \ WISH] Add -o option to git-rev-list
From: Linus Torvalds @ 2006-12-11 20:40 UTC (permalink / raw)
To: Josef Weidendorfer
Cc: Marco Costalba, Git Mailing List, Junio C Hamano, Alex Riesen,
Shawn Pearce
In-Reply-To: <200612112128.06485.Josef.Weidendorfer@gmx.de>
On Mon, 11 Dec 2006, Josef Weidendorfer wrote:
>
> A general question: How many context switches are involved in such
> a producer/consumer scenario, given that the consumer writes one
> line at a time, and the consumer uses poll/select to wait for the
> data?
> Is there some possibility to make the kernel write-combine single
> small producer writes into bigger chunks, which will be delivered
> at once (or smaller data only after a small timeout)?
The data will be write-combined.
The kernel doesn't context-switch after a write() to a pipe if there is
space left (and usually the pipe buffer is 64kB with current kernels, so
there obviously will be), unless the reader has a higher priority for some
reason (ie the reader has been waiting a long time).
So _normally_ you'll see many many writes in one go, and only see context
switching when the kernel pipe buffer fills up.
^ permalink raw reply
* Re: git-svnimport breakage as of git-1.4.4
From: Sasha Khapyorsky @ 2006-12-11 20:49 UTC (permalink / raw)
To: Daniel Drake; +Cc: git
In-Reply-To: <1165847230.13854.2.camel@systems03.lan.brontes3d.com>
On 09:27 Mon 11 Dec , Daniel Drake wrote:
> On Fri, 2006-12-08 at 22:32 +0200, Sasha Khapyorsky wrote:
> > > # git-svnimport -v -i -C repo -r https://server repo
> >
> > Is this 'server' public? Can I rerun this git-svnimport?
>
> Sorry, it is not.
>
> > @@ -906,7 +912,7 @@ sub commit_all {
> > my ($changed_paths, $revision, $author, $date, $message, $pool) = @_;
> > my %p;
> > while(my($path,$action) = each %$changed_paths) {
> > - $p{$path} = [ $action->action,$action->copyfrom_path, $action->copyfrom_rev, $path ];
> > + $p{$path} = [ $action->action,$svn_dir$action->copyfrom_path, $action->copyfrom_rev, $svn_dir$path ];
>
> This is not valid perl - I think you wanted $svn_dir . $path
Yes, sorry.
>
> After making that modification it's not fixed though:
>
> Fetching from 1 to 10742 ...
> Tree ID 4b825dc642cb6eb9a060e54bf8d69288fbee4904
> Committed change 1:/ 2004-12-22 22:53:27)
> Committing initial tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904
> Commit ID 2614c05ac4c5f24eb89cea056a7d46c909084d8c
> Writing to refs/heads/origin
> DONE: 1 origin 2614c05ac4c5f24eb89cea056a7d46c909084d8c
> perl: subversion/libsvn_subr/path.c:377: svn_path_basename: Assertion
> `is_canonical (path, len)' failed.
> Aborted
Maybe I'm starting to understand. Your svn url (url which points to svn
repository) is https://server/repo and not just https://server, right?
If so, please remove the patch (you don't need it) and rerun:
git-svnimport -v -i -C repo -r https://server/repo
^ permalink raw reply
* Re: git-svnimport breakage as of git-1.4.4
From: Sasha Khapyorsky @ 2006-12-11 20:50 UTC (permalink / raw)
To: Dongsheng Song; +Cc: Daniel Drake, git
In-Reply-To: <4b3406f0612111200o65352771r454d5ced0ac99f08@mail.gmail.com>
On 04:00 Tue 12 Dec , Dongsheng Song wrote:
> Sorry, I assume you have see http://tortoisesvn.tigris.org/:
>
> username : guest
> password : ""
Thanks, I can grab svn log now. Which command line you are using?
^ permalink raw reply
* Re: [RFC \ WISH] Add -o option to git-rev-list
From: Josef Weidendorfer @ 2006-12-11 20:54 UTC (permalink / raw)
To: Linus Torvalds
Cc: Marco Costalba, Git Mailing List, Junio C Hamano, Alex Riesen,
Shawn Pearce
In-Reply-To: <Pine.LNX.4.64.0612111238560.3515@woody.osdl.org>
On Monday 11 December 2006 21:40, Linus Torvalds wrote:
> On Mon, 11 Dec 2006, Josef Weidendorfer wrote:
> > A general question: How many context switches are involved in such
> > a producer/consumer scenario, given that the consumer writes one
> > line at a time, and the consumer uses poll/select to wait for the
> > data?
> > Is there some possibility to make the kernel write-combine single
> > small producer writes into bigger chunks, which will be delivered
> > at once (or smaller data only after a small timeout)?
>
> The data will be write-combined.
>
> The kernel doesn't context-switch after a write() to a pipe if there is
> space left (and usually the pipe buffer is 64kB with current kernels, so
> there obviously will be), unless the reader has a higher priority for some
> reason (ie the reader has been waiting a long time).
Ah, thanks.
So the implementation in Qt's QProcess is a little bit pessimistic, probably
to make it work fine with other UNIXs out there.
^ permalink raw reply
* Re: git-svnimport breakage as of git-1.4.4
From: Dongsheng Song @ 2006-12-11 21:01 UTC (permalink / raw)
To: Sasha Khapyorsky; +Cc: Daniel Drake, git
In-Reply-To: <20061211205006.GD1003@sashak.voltaire.com>
$ cat svn2git-tortoisesvn.sh
#!/bin/sh
export LC_ALL=C
export WC_ROOT=/home/cauchy/wc/git
export REPO_NAME=tortoisesvn
echo "[`date`] Start import & pack ..."
mr=0
while [ $mr -le 9000 ]; do
if test -f $WC_ROOT/$REPO_NAME/.git/SVN2GIT_HEAD; then
echo "[`date`] clean up ..."
cd $WC_ROOT/$REPO_NAME
git-read-tree -m -u SVN2GIT_HEAD HEAD && rm -f .git/SVN2GIT_HEAD
echo "[`date`] clean up finished"
fi
mr=$(($mr + 1000))
echo "[`date`] Start import up to revison $mr ..."
git-svnimport -v -i -r -o master -l $mr -C $WC_ROOT/$REPO_NAME
http://tortoisesvn.tigris.org/svn/tortoisesvn
echo "[`date`] Finish import up to revison $mr"
cd $WC_ROOT/$REPO_NAME && git-repack -a -d --window=64 --depth=64
echo "[`date`] Finish repack revison $mr"
cd $WC_ROOT/$REPO_NAME && find .git -name pack | xargs ls -l
done
echo "[`date`] Finished import & pack"
2006/12/12, Sasha Khapyorsky <sashak@voltaire.com>:
> On 04:00 Tue 12 Dec , Dongsheng Song wrote:
> > Sorry, I assume you have see http://tortoisesvn.tigris.org/:
> >
> > username : guest
> > password : ""
>
> Thanks, I can grab svn log now. Which command line you are using?
>
> Sasha
^ permalink raw reply
* Re: git-svnimport breakage as of git-1.4.4
From: Daniel Drake @ 2006-12-11 21:03 UTC (permalink / raw)
To: Sasha Khapyorsky; +Cc: git
In-Reply-To: <20061211204904.GC1003@sashak.voltaire.com>
On Mon, 2006-12-11 at 22:49 +0200, Sasha Khapyorsky wrote:
> Maybe I'm starting to understand. Your svn url (url which points to svn
> repository) is https://server/repo and not just https://server, right?
Yes, and then under that we have https://server/repo/trunk
> If so, please remove the patch (you don't need it) and rerun:
>
> git-svnimport -v -i -C repo -r https://server/repo
Ah, that fixes it. However, in versions before 1.4.4, either invokation
style works.
Thanks,
--
Daniel Drake
Brontes Technologies, A 3M Company
^ permalink raw reply
* Re: [RFC \ WISH] Add -o option to git-rev-list
From: Linus Torvalds @ 2006-12-11 21:14 UTC (permalink / raw)
To: Josef Weidendorfer
Cc: Marco Costalba, Git Mailing List, Junio C Hamano, Alex Riesen,
Shawn Pearce
In-Reply-To: <200612112154.56166.Josef.Weidendorfer@gmx.de>
On Mon, 11 Dec 2006, Josef Weidendorfer wrote:
>
> So the implementation in Qt's QProcess is a little bit pessimistic, probably
> to make it work fine with other UNIXs out there.
I suspect it may actually have been performance-optimized for Linux-2.4,
where the pipe buffer size was one page (so if you got a full 4kB on x86,
you'd know that the buffer was fully emptied).
And it actually does end up depending on the load too. For example, the
4kB can also happen to match the default buffer size in stdio (or in the
QT IO buffering equivalent), and in that case you know that any _writer_
that uses stdio buffering will usually use that as the blocksize, so you
have reasons beyond the kernel to think that maybe a certain particular
blocksize is more common than others.
And if that's the case, then if you know that _usually_ the read() would
return -EAGAIN, then it's actually better to return to the main loop and
select(), on the assumption that quite often, the select will be the right
thing (and if it isn't, it will just return immediately anyway, and you
can do the second read).
In other words, it's really a "tuning thing" that depends on the IO
patterns of the apps involved, and the underlying pattern of the OS can
affect it too.
Of course, most of the time it doesn't make _that_ much of a difference,
especially when system calls are reasonably cheap (and they largely are,
under Linux). So you can certainly see the effects of this, but the
effects will vary so much on the load and other issues that it's hard to
say that there is "one correct way" to do things.
For example, very subtle issues can be at play:
- using a larger buffer and having fewer system calls can be
advantageous in many cases. But certainly not always.
HOWEVER. If you have two processes that both do very little with the
data (generating it _or_ using it), and process switching is cheap
thanks to address space identifiers or clever TLB's, then a small
buffer may actually be much better, if it means that the whole working
set fits in the L2 cache.
So a large buffer with fewer system calls may actually be _bad_, if
only because it causes things to go to L3 or memory. In contrast, if
you can re-use a smaller buffer, you'll stay in the L2 cache better.
Same goes for the L1 cache too, but that's really only noticeable for
true micro-benchmarks. Sadly, people often do performance analysis with
microbenches, so they can actually tune their setup for something that
is NOT what people actually see in real life.
In general, if you re-use your buffer, try to keep it small enough that
it stays hot in the L2 can be a good thing. Using 8kB or 16kB buffers
and 64-128 system calls can actually be a lot BETTER than using a 1MB
buffer and a single system call.
Examples of this is stdio. Making your stdio buffers bigger simply
often isn't a good idea. The system call cost of flushing the buffer
simply isn't likely to be the highest cost.
- real-time or fairness issues. Sometimes you are better off doing a
round-robin thing in the main select() loop over 10 smaller buffers
than over ten big buffers (or over a single mainloop call-out that
keeps doing read() until the buffer is entirely empty).
This is not likely to be an issue with qgit-like behaviour (whether you
process a 4kB buffer or 64kB buffer in one go is simply not going to
make a visible difference to a user interface), but it can make a
difference for "server" apps with latency issues. You do not want one
busy client to basically freeze out all the other clients by just
keeping its queue filled all teh time.
So returning to the main loop may actually be the right thing after
each read(), not for performance reasons, but because it gives a nicer
load pattern. It may perform _worse_, but it may well give a smoother
feel to the system!
- simplicity. The main select() loop does the looping anyway, so avoiding
looping in the callouts simplifies the system. And since it's not
necessarily the right thing to do to loop in the individual routines
_anyway_ (see above), why not?
So I don't think there is a right answer here. I suspect QProcess does ok.
^ permalink raw reply
* [PATCH/RFC] Add support for push globbed refspecs
From: Andy Parkins @ 2006-12-11 21:33 UTC (permalink / raw)
To: git
Just as we now have glob support in fetch refspecs, this patch adds
support for globs in the push refspecs. In other words you can do:
[remote "globs"]
url = proto://host/repo.git
push = refs/heads/*:refs/remotes/from_me/*
With this, a git-push will then do a normal directory glob on the local
ref path; whatever it finds will have the matching part extracted and
inserted into the remote half of the refspec.
Note the following:
- subdirectories aren't supported
- globs with more than one "*" will probably go /very/ wrong
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
I'm not sure this is the right way to have done this.
My feeling is that perhaps a for_each_ref() call and some string
manipulation would have been better. What'd you all reckon?
builtin-push.c | 70 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 70 insertions(+), 0 deletions(-)
diff --git a/builtin-push.c b/builtin-push.c
index d23974e..e60db71 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -5,6 +5,7 @@
#include "refs.h"
#include "run-command.h"
#include "builtin.h"
+#include <glob.h>
#define MAX_URI (16)
@@ -22,6 +23,75 @@ static int refspec_nr;
static void add_refspec(const char *ref)
{
int nr = refspec_nr + 1;
+ char *globpos_local = NULL,
+ *globpos_remote = NULL,
+ *separator = NULL;
+ char *buffer;
+
+ /* See if the ref is a globref */
+ buffer = xmalloc(strlen(ref)+1);
+ strcpy(buffer, ref);
+ separator = strstr(buffer, ":");
+ if (separator != NULL)
+ globpos_remote = strstr(separator, "*");
+ globpos_local = strstr(buffer, "*");
+
+ /* If globpos is set, then we have enough information to perform
+ * the expansion */
+ if( globpos_remote != NULL && globpos_local != NULL) {
+ glob_t globres;
+ int ret;
+ unsigned int i;
+ unsigned int gitpathlen;
+ char *newrefspec;
+
+ /* Break the refspec into chunks:
+ * <localref>:<remote_prefix>*<remoteref_suffix>
+ */
+ *separator = '\0';
+ separator++;
+ *globpos_remote = '\0';
+ globpos_remote++;
+ /* Now buffer points at localref; separator points at
+ * remoteref prefix, globpos_remote points at remoteref suffix */
+
+ /* Fetch all the matching local refs */
+ globres.gl_offs = 0;
+ ret = glob(git_path("%s", buffer), GLOB_ERR, NULL, &globres);
+ gitpathlen = strlen( git_path("") );
+
+ if (ret == 0) {
+ for (i = 0; i < globres.gl_pathc; i++) {
+ char *p, *q;
+
+ p = globres.gl_pathv[i] + gitpathlen + (globpos_local - buffer);
+ q = p + strlen(p) - strlen(globpos_local+1);
+
+ newrefspec = xmalloc(
+ strlen(globres.gl_pathv[i] + gitpathlen)
+ + strlen(separator)
+ + (q-p)
+ + strlen( globpos_remote)
+ + 1 + 1 );
+
+ sprintf( newrefspec, "%s:%s%.*s%s",
+ globres.gl_pathv[i] + gitpathlen,
+ separator,
+ q-p, p,
+ globpos_remote );
+
+ add_refspec( newrefspec );
+ }
+ }
+
+ /* tidy up */
+ globfree( &globres );
+
+ /* Don't add the globspec */
+ return;
+ }
+ free(buffer);
+
refspec = xrealloc(refspec, nr * sizeof(char *));
refspec[nr-1] = ref;
refspec_nr = nr;
--
1.4.4.1.GIT
^ permalink raw reply related
* Re: git-svnimport breakage as of git-1.4.4
From: Sasha Khapyorsky @ 2006-12-11 22:03 UTC (permalink / raw)
To: Daniel Drake; +Cc: git
In-Reply-To: <1165870980.31329.3.camel@systems03.lan.brontes3d.com>
On 16:03 Mon 11 Dec , Daniel Drake wrote:
> On Mon, 2006-12-11 at 22:49 +0200, Sasha Khapyorsky wrote:
> > Maybe I'm starting to understand. Your svn url (url which points to svn
> > repository) is https://server/repo and not just https://server, right?
>
> Yes, and then under that we have https://server/repo/trunk
>
> > If so, please remove the patch (you don't need it) and rerun:
> >
> > git-svnimport -v -i -C repo -r https://server/repo
>
> Ah, that fixes it. However, in versions before 1.4.4, either invokation
> style works.
Frankly I think that it was bug. And I will see how to restore this. :)
^ permalink raw reply
* [PATCH] Colourise git-branch output
From: Andy Parkins @ 2006-12-11 22:10 UTC (permalink / raw)
To: git
I wanted to have a visual indication of which branches are local and which are
remote in git-branch -a output; however Junio was concerned that someone might
be using the output in a script. This patch addresses the problem by colouring
the git-branch output - which in "auto" mode won't be activated.
I've based it off the colouring code for builtin-diff.c; which means there is a
branch.color configuration variable that needs setting to something before the
color will appear.
This patch chooses green for local, red for remote and bold green for current.
As yet, there is no support for changing the colors using the config file; but
it wouldn't be hard to add.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
I know Junio isn't keen on adding colour all over the place in git; but I
think it's appropriate here. When running in "git-branch -a" mode (or even
"git-branch -r" mode for that matter), because the "refs/remotes" prefix is
stripped from the branch name, there is no way to distinguish between local
and remote branches. Colouring them makes it easy to see which is which,
but more importantly doesn't break any scripts because the colour would be
automatically disabled.
builtin-branch.c | 64 +++++++++++++++++++++++++++++++++++++++++++++++++----
1 files changed, 59 insertions(+), 5 deletions(-)
diff --git a/builtin-branch.c b/builtin-branch.c
index 3d5cb0e..1c1fa8f 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -5,6 +5,7 @@
* Based on git-branch.sh by Junio C Hamano.
*/
+#include "color.h"
#include "cache.h"
#include "refs.h"
#include "commit.h"
@@ -17,6 +18,38 @@ static const char builtin_branch_usage[] =
static const char *head;
static unsigned char head_sha1[20];
+static int branch_use_color;
+static char branch_colors[][COLOR_MAXLEN] = {
+ "\033[m", /* reset */
+ "", /* PLAIN (normal) */
+ "\033[31m", /* REMOTE (red) */
+ "\033[32m", /* LOCAL (green) */
+ "\033[1;32m", /* CURRENT (boldgreen) */
+};
+enum color_branch {
+ COLOR_BRANCH_RESET = 0,
+ COLOR_BRANCH_PLAIN = 1,
+ COLOR_BRANCH_REMOTE = 2,
+ COLOR_BRANCH_LOCAL = 3,
+ COLOR_BRANCH_CURRENT = 4,
+};
+
+int git_branch_config(const char *var, const char *value)
+{
+ if (!strcmp(var, "branch.color")) {
+ branch_use_color = git_config_colorbool(var, value);
+ return 0;
+ }
+ return git_default_config(var, value);
+}
+
+const char *branch_get_color(enum color_branch ix)
+{
+ if (branch_use_color)
+ return branch_colors[ix];
+ return "";
+}
+
static int in_merge_bases(const unsigned char *sha1,
struct commit *rev1,
struct commit *rev2)
@@ -183,6 +216,7 @@ static void print_ref_list(int kinds, int verbose, int abbrev)
int i;
char c;
struct ref_list ref_list;
+ int color;
memset(&ref_list, 0, sizeof(ref_list));
ref_list.kinds = kinds;
@@ -191,18 +225,38 @@ static void print_ref_list(int kinds, int verbose, int abbrev)
qsort(ref_list.list, ref_list.index, sizeof(struct ref_item), ref_cmp);
for (i = 0; i < ref_list.index; i++) {
+ switch( ref_list.list[i].kind ) {
+ case REF_LOCAL_BRANCH:
+ color = COLOR_BRANCH_LOCAL;
+ break;
+ case REF_REMOTE_BRANCH:
+ color = COLOR_BRANCH_REMOTE;
+ break;
+ default:
+ color = COLOR_BRANCH_PLAIN;
+ break;
+ }
+
c = ' ';
if (ref_list.list[i].kind == REF_LOCAL_BRANCH &&
- !strcmp(ref_list.list[i].name, head))
+ !strcmp(ref_list.list[i].name, head)) {
c = '*';
+ color = COLOR_BRANCH_CURRENT;
+ }
if (verbose) {
- printf("%c %-*s", c, ref_list.maxwidth,
- ref_list.list[i].name);
+ printf("%c %s%-*s%s", c,
+ branch_get_color(color),
+ ref_list.maxwidth,
+ ref_list.list[i].name,
+ branch_get_color(COLOR_BRANCH_RESET));
print_ref_info(ref_list.list[i].sha1, abbrev);
}
else
- printf("%c %s\n", c, ref_list.list[i].name);
+ printf("%c %s%s%s\n", c,
+ branch_get_color(color),
+ ref_list.list[i].name,
+ branch_get_color(COLOR_BRANCH_RESET));
}
free_ref_list(&ref_list);
@@ -253,7 +307,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
int kinds = REF_LOCAL_BRANCH;
int i;
- git_config(git_default_config);
+ git_config(git_branch_config);
for (i = 1; i < argc; i++) {
const char *arg = argv[i];
--
1.4.4.1.geeee8
^ permalink raw reply related
* [PATCH] Add verbose comments to split_msg()
From: Andy Parkins @ 2006-12-11 22:12 UTC (permalink / raw)
To: git
I was going to fix a bug in imap-send that was making it include the "From "
line from git-format-patch in the message sent to the IMAP server. So I
commented up what split_msg already does.
It turns out the bug was fixed in commit
e0b0830726286287744cc9e1a629a534bbe75452. So comments only, no fix needed.
(cherry picked from 3d5b1768f15b5cd430b869f416e72f4f3afe3d4a commit)
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
imap-send.c | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/imap-send.c b/imap-send.c
index a6a6568..110bd54 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -1216,35 +1216,48 @@ split_msg( msg_data_t *all_msgs, msg_data_t *msg, int *ofs )
{
char *p, *data;
+ /* Clear this message's slot */
memset( msg, 0, sizeof *msg );
+ /* If we've run out of data, stop*/
if (*ofs >= all_msgs->len)
return 0;
+ /* Point at the next message chunk */
data = &all_msgs->data[ *ofs ];
+ /* This message length is at most, the length of all messages
+ * minus our current position */
msg->len = all_msgs->len - *ofs;
+ /* If there isn't enough data remaining for a whole message or there
+ * is no , give up */
if (msg->len < 5 || strncmp( data, "From ", 5 ))
return 0;
+ /* Find the end of the "From " line */
p = strchr( data, '\n' );
if (p) {
+ /* Skip this line from the outgoing buffer */
p = &p[1];
msg->len -= p-data;
*ofs += p-data;
data = p;
}
+ /* Find the next message (if any) */
p = strstr( data, "\nFrom " );
if (p)
msg->len = &p[1] - data;
+ /* Alloc enough space for this message */
msg->data = xmalloc( msg->len + 1 );
if (!msg->data)
return 0;
+ /* Copy the message from "all" to it's own holder and terminate */
memcpy( msg->data, data, msg->len );
msg->data[ msg->len ] = 0;
+ /* Move the data pointer to the next message */
*ofs += msg->len;
return 1;
}
--
1.4.4.1.geeee8
^ permalink raw reply related
* [PATCH] Comment -p mode for cat-file
From: Andy Parkins @ 2006-12-11 22:13 UTC (permalink / raw)
To: git
In-Reply-To: <f323e83a37efd3b913004666f2fc104578a92833.1165875140.git.andyparkins@gmail.com>
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
builtin-cat-file.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/builtin-cat-file.c b/builtin-cat-file.c
index 6c16bfa..e7997ee 100644
--- a/builtin-cat-file.c
+++ b/builtin-cat-file.c
@@ -121,12 +121,16 @@ int cmd_cat_file(int argc, const char **argv, const char *prefix)
die("Not a valid object name %s", argv[2]);
/* custom pretty-print here */
+ /* Special print tree types using ls-tree
+ * git-ls-tree argv[1] */
if (!strcmp(type, tree_type))
return cmd_ls_tree(2, argv + 1, NULL);
+ /* For everything else, read the object itself */
buf = read_sha1_file(sha1, type, &size);
if (!buf)
die("Cannot read object %s", argv[2]);
+ /* if the object is a tag, use pprint_tag() above */
if (!strcmp(type, tag_type)) {
pprint_tag(sha1, buf, size);
return 0;
--
1.4.4.1.geeee8
^ permalink raw reply related
* [PATCH] Comment diff_tree
From: Andy Parkins @ 2006-12-11 22:13 UTC (permalink / raw)
To: git
In-Reply-To: <f323e83a37efd3b913004666f2fc104578a92833.1165875140.git.andyparkins@gmail.com>
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
tree-diff.c | 17 ++++++++++++++---
1 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/tree-diff.c b/tree-diff.c
index 37d235e..009dd17 100644
--- a/tree-diff.c
+++ b/tree-diff.c
@@ -160,33 +160,44 @@ static void show_entry(struct diff_options *opt, const char *prefix, struct tree
int diff_tree(struct tree_desc *t1, struct tree_desc *t2, const char *base, struct diff_options *opt)
{
+ /* While there are entries left in t1 or t2... */
while (t1->size | t2->size) {
if (opt->nr_paths && t1->size && !interesting(t1, base, opt)) {
+ /* If there are paths left in t1, and the current path is
+ * not interesting, skip it and try the next path in t1 */
update_tree_entry(t1);
continue;
}
if (opt->nr_paths && t2->size && !interesting(t2, base, opt)) {
+ /* If there are paths left in t2, and the current path is
+ * not interesting, skip it and try the next path in t2 */
update_tree_entry(t2);
continue;
}
+ /* Here if either
+ * - Either t1 or t2 path is available and interesting
+ * - No paths available */
if (!t1->size) {
+ /* If there is no path left in t1, then t2 is a new path */
show_entry(opt, "+", t2, base);
update_tree_entry(t2);
continue;
}
if (!t2->size) {
+ /* If there is no path left in t2, then t1 is a remed path */
show_entry(opt, "-", t1, base);
update_tree_entry(t1);
continue;
}
+ /* If both paths are available and interesting then it is a change */
switch (compare_tree_entry(t1, t2, base, opt)) {
- case -1:
+ case -1: /* Finished with the path in t1 */
update_tree_entry(t1);
continue;
- case 0:
+ case 0: /* Finished with both paths */
update_tree_entry(t1);
/* Fallthrough */
- case 1:
+ case 1: /* Finished with the path in t2 */
update_tree_entry(t2);
continue;
}
--
1.4.4.1.geeee8
^ permalink raw reply related
* [PATCH] Add comments to update_tree_entry()
From: Andy Parkins @ 2006-12-11 22:13 UTC (permalink / raw)
To: git
In-Reply-To: <f323e83a37efd3b913004666f2fc104578a92833.1165875140.git.andyparkins@gmail.com>
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
tree-walk.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/tree-walk.c b/tree-walk.c
index 14cc5ae..5363366 100644
--- a/tree-walk.c
+++ b/tree-walk.c
@@ -37,6 +37,11 @@ static void entry_extract(struct tree_desc *t, struct name_entry *a)
void update_tree_entry(struct tree_desc *desc)
{
+ /* Each tree is represented by a buffer containing hashes followed
+ * by space followed by filename; separated with NUL. To move to the
+ * next entry we simply move forward by strlen() (which skips the filename)
+ * then skip the hash and the space. */
+ /* This function should really be called skip_tree_entry() */
const void *buf = desc->buf;
unsigned long size = desc->size;
int len = strlen(buf) + 1 + 20;
--
1.4.4.1.geeee8
^ permalink raw reply related
* [PATCH] Uninstall rule for top level Makefile
From: Andy Parkins @ 2006-12-11 22:14 UTC (permalink / raw)
To: git
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
Makefile | 14 ++++++++++++++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index a1861de..51c1747 100644
--- a/Makefile
+++ b/Makefile
@@ -821,6 +821,20 @@ install-doc:
$(MAKE) -C Documentation install
+### Uninstallation rules
+
+uninstall:
+ rm -f $(subst %,$(DESTDIR_SQ)$(gitexecdir_SQ)/%,$(ALL_PROGRAMS))
+ rm -f '$(DESTDIR_SQ)$(bindir_SQ)/git$X'
+ rm -f '$(DESTDIR_SQ)$(bindir_SQ)/gitk'
+ $(MAKE) -C templates DESTDIR='$(DESTDIR_SQ)' uninstall
+ $(MAKE) -C perl uninstall
+ if test 'z$(bindir_SQ)' != 'z$(gitexecdir_SQ)'; \
+ then \
+ rm -f '$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X'
+ rm -f '$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X'; \
+ fi
+ $(foreach p,$(BUILT_INS), rm -f '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p';)
### Maintainer's dist rules
--
1.4.4.1.geeee8
^ permalink raw reply related
* Re: [PATCH] Colourise git-branch output
From: Junio C Hamano @ 2006-12-11 22:47 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200612112210.08327.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> writes:
> I wanted to have a visual indication of which branches are
> local and which are remote in git-branch -a output; however
> Junio was concerned that someone might be using the output in
> a script. This patch addresses the problem by colouring the
> git-branch output - which in "auto" mode won't be activated.
Hmm.
"git branch --color" does not seem to work, so is this config
only?
> As yet, there is no support for changing the colors using the
> config file; but it wouldn't be hard to add.
I am not sure about that. Would it be something like this?
[branch.color]
remote = purple
local = yellow
I wonder what would happen when you have a branch called
"color". Would the above cause "git-fetch" to fetch from
"purple" remote by default?
^ permalink raw reply
* Re: stgit: No patches to pop
From: Jakub Narebski @ 2006-12-11 22:54 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0612111426s3e0c671eqca31558e47d4348b@mail.gmail.com>
Catalin Marinas wrote:
> On 11/12/06, Jakub Narebski <jnareb@gmail.com> wrote:
>> Catalin Marinas wrote:
>>
>>>> I also get things like:
>>>>
>>>> % stg pop second
>>>> popping patch "third"... done
>>>> Now at patch "second"
>>>
>>> In version 0.11, the "pop" command is equivalent to "goto". I changed
>>> this in the latest version (in the StGIT repository) so that "pop
>>> <patch>" tries to only extract that patch from the stack by popping
>>> all the patches to the given one and pushing them back without the one
>>> you specified. It also supports patch ranges (i.e. patch1..patch4).
>>
>> That is kind of strange. Pop should work like pop does, for example
>> the one in Perl or Python, removing n elements from the stack of applied
>> patches. Not work as "float <patch>"...
>
> Probably I wasn't clear enough. The "pop" operations are as follows:
>
> 1. "stg pop" only removes the top patch from the applied patches
> 2. "stg pop <patch>.." is equivalent to popping all patches to <patch>
> (including the latter)
> 3. "stg pop <patch>" is equivalent to "stg float <patch>; stg pop".
> 4. "stg pop <patch list or range>" is equivalent to "stg float <patch
> list or range>; stg pop <all the patches in the list or range>"
>
> These feature was Yann's idea and I find it to be more in line with
> the "push" command.
Nice, and easy to understand. By the way, the same works with "stg push",
doesn't it?
--
Jakub Narebski
^ permalink raw reply
* trouble with git cvsimport
From: Ian Molton @ 2006-12-11 23:28 UTC (permalink / raw)
To: git
Hi.
I imported a CVS repo with git cvsimport, which went well enough,
however subsequent repeats of the same command arent updating the git
repo. whats up?
command Im using is:
git-cvsimport -d:local:/home/ian/projects/hh.org_cvs/cvs/ -k -m -p x -o
^ permalink raw reply
* Re: [PATCH] Colourise git-branch output
From: Sean @ 2006-12-12 0:38 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200612112210.08327.andyparkins@gmail.com>
On Mon, 11 Dec 2006 22:10:08 +0000
Andy Parkins <andyparkins@gmail.com> wrote:
> +int git_branch_config(const char *var, const char *value)
> +{
> + if (!strcmp(var, "branch.color")) {
> + branch_use_color = git_config_colorbool(var, value);
> + return 0;
> + }
> + return git_default_config(var, value);
> +}
As Junio already highlighted, the "branch.*" namespace is for actual
branch names. This config option should go into "color.branch" or some
other spot.
^ 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