* Re: qgit idea: interface for cherry-picking
From: Marco Costalba @ 2006-07-04 11:58 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Junio C Hamano
In-Reply-To: <e8d2eo$k44$1@sea.gmane.org>
On 7/4/06, Jakub Narebski <jnareb@gmail.com> wrote:
> Marco Costalba wrote:
>
> > QGit is not supposed to be a GUI replacement of git UI. QGit only let
> > users quickly call some commonly used commands. [...]
>
> It's a pity. Doing some of commands from visual history viewer, with view of
> branches etc. would be so much easier: like bisect, rebasing, cherry
> picking, reverting a commit...
>
In the past weeks I (with Pavel support) have implemented and pushed
the concept of "custom actions".
Is it possible to associate commands sequences, scripts and anything
else executable to a custom action. Actions can be called and run from
menu entry and corresponding output is grabbed by a terminal window.
Instead of hard code each git-native command, this way you have a
flexible framework to add shortcuts and menu entry for anything you
would like to be a click away. BTW I use this for stuff like git pull,
but also for 'make' and 'make install' because you have a window
terminal for feedback.
There is also the possibility to input command line parameters before
to run, useful, as example for a git pull action that asks for source
repository to pull from.
Is this something that can fulfill you request? do you need something
different? perhaps something as a "default to current selected SHA as
input argument" flag.
Marco
^ permalink raw reply
* Re: qgit idea: marking refs (heads and tags)
From: Marco Costalba @ 2006-07-04 12:03 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e8d3i6$ne9$1@sea.gmane.org>
On 7/4/06, Jakub Narebski <jnareb@gmail.com> wrote:
> One thing I sorely lack in qgit as compared to gitk (and even gitweb[*1*])
> is marking commits with refs (heads and tags, marked with different colors
> or different shape marker). gitk currently uses markers in short log line
> before text of commit summary, gitweb uses markers after (at the end) of
> commit log summary. In qgit head commits are marked as such, but not to
> which branche they belong[*2*].
Currently you have to select the head and the status bar will show
related information: branch, tag message, etc.
>
> And also somewhat (but to much lesser extent) showing explicitely sha1-ids
> for commit, parents, tree, referenced object (in tag), to copy'n'paste to
> shell.
>
Something as a typical browser "copy selected link" context menu entry?
Marco
^ permalink raw reply
* Re: git-fetch per-repository speed issues
From: Andreas Ericsson @ 2006-07-04 12:05 UTC (permalink / raw)
To: Matthias Kestenholz; +Cc: git
In-Reply-To: <20060704111838.GA4285@spinlock.ch>
Matthias Kestenholz wrote:
> * Andreas Ericsson (ae@op5.se) wrote:
>
>>Keith Packard wrote:
>>
>>>On Mon, 2006-07-03 at 20:40 -0700, Linus Torvalds wrote:
>>>
>>>
>>>
>>>> "And, it's painfully slow, even when the repository is up to date"
>>>>
>>>>and gave a 17-second time.
>>>
>>>
>>>It's faster this evening, down to 8 seconds using ssh and 4 seconds
>>>using git. I clearly need to force use of the git protocol. Anyone else
>>>like the attached patch?
>>
>>Since it changes the current meaning of ssh+git, I'm not exactly
>>thrilled. However, "git/ssh" or "ssh/git" would work fine for me. The
>>slash-separator could be used to say "fetch over this, push over that",
>>so we can end up with any valid protocol to use for fetches and another
>>one to push over.
>>
>
>
> If we would do such a thing, we would be probably better off
> allowing different URLs for pushing and pulling, because the git and
> ssh URLs will only be the same, if the git repositories are located
> in the root folder and I suspect that's almost never the case.
>
True. We use relative paths where I work, so for us either way would
work. Your way is better though.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: qgit idea: marking refs (heads and tags)
From: Jakub Narebski @ 2006-07-04 12:45 UTC (permalink / raw)
To: git
In-Reply-To: <e5bfff550607040503x75b1abdavbbeb80b41a454e7d@mail.gmail.com>
Marco Costalba wrote:
> On 7/4/06, Jakub Narebski <jnareb@gmail.com> wrote:
>> One thing I sorely lack in qgit as compared to gitk (and even gitweb[*1*])
>> is marking commits with refs (heads and tags, marked with different colors
>> or different shape marker). gitk currently uses markers in short log line
>> before text of commit summary, gitweb uses markers after (at the end) of
>> commit log summary. In qgit head commits are marked as such, but not to
>> which branche they belong[*2*].
>
> Currently you have to select the head and the status bar will show
> related information: branch, tag message, etc.
That is step in right direction, but still when viewing history as a whole
I'd like to know which branch is which. Head refs are marked, so it shouldn't
be much work (well, perhaps some on the GUI side) to add, as an option,
head name somewhere (before or after, or even somwehere else) along commit
"subject".
>> And also somewhat (but to much lesser extent) showing explicitely sha1-ids
>> for commit, parents, tree, referenced object (in tag), to copy'n'paste to
>> shell.
>
> Something as a typical browser "copy selected link" context menu entry?
Yes, "copy sha1 of selected link" would be nice.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: qgit idea: interface for cherry-picking
From: Jakub Narebski @ 2006-07-04 13:29 UTC (permalink / raw)
To: git
In-Reply-To: <e5bfff550607040458m1e6ea6bes44b3e3eba26856f0@mail.gmail.com>
Marco Costalba wrote:
> In the past weeks I (with Pavel support) have implemented and pushed
> the concept of "custom actions".
>
> Is it possible to associate commands sequences, scripts and anything
> else executable to a custom action. Actions can be called and run from
> menu entry and corresponding output is grabbed by a terminal window.
>
> Instead of hard code each git-native command, this way you have a
> flexible framework to add shortcuts and menu entry for anything you
> would like to be a click away. BTW I use this for stuff like git pull,
> but also for 'make' and 'make install' because you have a window
> terminal for feedback.
>
> There is also the possibility to input command line parameters before
> to run, useful, as example for a git pull action that asks for source
> repository to pull from.
>
> Is this something that can fulfill you request? do you need something
> different? perhaps something as a "default to current selected SHA as
> input argument" flag.
It would be nice (I don't know if feasible) that either to provide some kind
of parameters substitution in the likes of "%head" in the invocation line
for a script to be expanded to the sha1 or name of head of currently
selected commit.
Other solution would be to provide GUI for input of command line parameters,
e.g. combo-box (i.e. editable text field, with provided list of default
values) for repository (populated from .git/branches and .git/remotes),
option to select commit or use selected commit for head ref or just commit
ref, etc...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Add a custom ./configure script
From: Jakub Narebski @ 2006-07-04 13:50 UTC (permalink / raw)
To: git
In-Reply-To: <20060704004012.22639.44317.stgit@machine.or.cz>
Petr Baudis wrote:
> The patch is on top of pu, that is Jakub Narebski's autoconf patch, because
> it reuses most of its infrastructure and just replaces the configure script.
If you named it for example configure.sh, then autoconf generated version,
and your by hand created version could coexist.
For now I think it would be best to move autoconf related files (configure.ac,
config.mak.in) to the contrib/autoconf/ area. Then one would be able to
compare config.mak.autogen generated by ./configure from autoconf, and
your ./configure script.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH 2, proof of concept] autoconf: Use %configure in git.spec, autoconf dependency only in rpm target
From: Jakub Narebski @ 2006-07-04 14:09 UTC (permalink / raw)
To: git
In-Reply-To: <200607030156.50455.jnareb@gmail.com>
This is __Proof of Concept__ patch, which makes use of predefined
%configure rpm macro to define install dirs, using autoconf
generated ./configure script.
This patch introduces dependency on autoconf _only_ for rpm target during
build process.
---
Probably there is more portable way of ignoring diff exit status than
using '|| true', and probably better way to generate
"file creation"/"new file" patch from a working directory (only) file
(perhaps using git-diff too).
Sidenote 1: current git.spec.in doesn't allow building RPMS from a dirty
version:
error: line 3: Illegal char '-' in version: Version: 1.4.1.g1c7c-dirty
Is it intentional?
Sidenote 2: building rpm currently does compilation _twice_, once to generate
git-tar-tree, and once in the rpm build (in BuildRoot).
Makefile | 3 +++
git.spec.in | 6 ++++--
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index 3c2c257..8ad1a4a 100644
--- a/Makefile
+++ b/Makefile
@@ -721,6 +722,9 @@ dist: git.spec git-tar-tree
gzip -f -9 $(GIT_TARNAME).tar
rpm: dist
+ autoconf
+ diff -Nu /dev/null configure > git-add-autoconf-configure.patch || true
+ gzip -f -9 git-add-autoconf-configure.patch
$(RPMBUILD) -ta $(GIT_TARNAME).tar.gz
htmldocs = git-htmldocs-$(GIT_VERSION)
diff --git a/git.spec.in b/git.spec.in
index 8ccd256..9c02803 100644
--- a/git.spec.in
+++ b/git.spec.in
@@ -7,6 +7,7 @@ License: GPL
Group: Development/Tools
URL: http://kernel.org/pub/software/scm/git/
Source: http://kernel.org/pub/software/scm/git/%{name}-%{version}.tar.gz
+Patch0: git-add-autoconf-configure.patch.gz
BuildRequires: zlib-devel >= 1.2, openssl-devel, curl-devel, expat-devel %{!?_without_docs:, xmlto, asciidoc > 6.0.3}
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
Requires: git-core, git-svn, git-cvs, git-arch, git-email, gitk
@@ -72,15 +73,16 @@ Git revision tree visualiser ('gitk')
%prep
%setup -q
+%patch0 -p0
%build
+%configure
make %{_smp_mflags} CFLAGS="$RPM_OPT_FLAGS" WITH_OWN_SUBPROCESS_PY=YesPlease \
- prefix=%{_prefix} all %{!?_without_docs: doc}
+ all %{!?_without_docs: doc}
%install
rm -rf $RPM_BUILD_ROOT
make %{_smp_mflags} DESTDIR=$RPM_BUILD_ROOT WITH_OWN_SUBPROCESS_PY=YesPlease \
- prefix=%{_prefix} mandir=%{_mandir} \
install %{!?_without_docs: install-doc}
(find $RPM_BUILD_ROOT%{_bindir} -type f | grep -vE "arch|svn|cvs|email|gitk" | sed -e s@^$RPM_BUILD_ROOT@@) > bin-man-doc-files
--
1.4.0
^ permalink raw reply related
* Re: [PATCH 1/3] Add read_cache_from() and discard_cache()
From: Johannes Schindelin @ 2006-07-04 14:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7virmepfhx.fsf@assigned-by-dhcp.cox.net>
Hi,
On Mon, 3 Jul 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Okay. After reading the comment, I am quite certain we can just set the
> > index_file_timestamp to 0.
>
> Thanks.
>
> > So, I still think that these two lines should be in the cleanup part of
> > get_merge_bases().
>
> I think that is sane -- please make it so.
Ummm. After reading my original mail again: bad tobacco that was. Of
course, I meant discard_cache(), not get_merge_bases(). Setting
index_file_timestamp in get_merge_bases() would be wrong.
Sorry for the noise,
Dscho
^ permalink raw reply
* Re: [RFC] GIT user survey
From: Jakub Narebski @ 2006-07-04 15:28 UTC (permalink / raw)
To: git
In-Reply-To: <4d8e3fd30606240918m6b452314m6514b5e5fc86f147@mail.gmail.com>
Paolo Ciarrocchi wrote:
> I was wondering whether it could be a good idea to have a kind of "GIT
> users survey" when google pointed my eyes to this page:
> http://www.selenic.com/pipermail/mercurial/2006-April/007513.html
>
> So I modified the content of the survey and published a DRAFT here:
> http://paolo.ciarrocchi.googlepages.com/GITSurvey
Could you please add the final version (and of course results) on
Git Wiki (http://git.or.cz/gitwiki), like original one is on Mercurial
wiki: http://www.selenic.com/mercurial/wiki/index.cgi/UserSurvey ?
Thanks in advance
P.S. I wonder why my Mozilla 1.7.12 sees GITSurvey as binary/octet-stream
instead of text/plain file...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git-fetch per-repository speed issues
From: Jakub Narebski @ 2006-07-04 15:42 UTC (permalink / raw)
To: git
In-Reply-To: <1151949764.4723.51.camel@neko.keithp.com>
I wonder if the problem detected here is also responsible with results
of Jeremy Blosser benchmark comparing git with Mercurial
http://lists.ibiblio.org/pipermail/sm-discuss/2006-May/014586.html
where git wins for clone, status and log, but is slower for pull.
See summary at
http://git.or.cz/gitwiki/GitBenchmarks#head-85df1bb7f019c4c504e34cde43450ef69349882f
--
Jakub Narebski
^ permalink raw reply
* Re: git-fetch per-repository speed issues
From: Thomas Glanzmann @ 2006-07-04 16:30 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e8e28j$v8v$1@sea.gmane.org>
Hello,
> See summary at
> http://git.or.cz/gitwiki/GitBenchmarks#head-85df1bb7f019c4c504e34cde43450ef69349882f
thank you for clarifing! I finally understand why Solaris folks prefer
hg over git: It is dog slow. - So it fits the general philosophy behind
Solaris.
Thomas
^ permalink raw reply
* Re: [PATCH 1/3] Add read_cache_from() and discard_cache()
From: Junio C Hamano @ 2006-07-04 17:41 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0607041617290.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Ummm. After reading my original mail again: bad tobacco that was. Of
> course, I meant discard_cache(), not get_merge_bases(). Setting
> index_file_timestamp in get_merge_bases() would be wrong.
I was well aware you were talking about discard_cache(). I
think these two clean-ups are good to have there.
^ permalink raw reply
* Re: git-fetch per-repository speed issues
From: Junio C Hamano @ 2006-07-04 17:45 UTC (permalink / raw)
To: git; +Cc: jnareb
In-Reply-To: <e8e28j$v8v$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> I wonder if the problem detected here is also responsible with results
> of Jeremy Blosser benchmark comparing git with Mercurial
> http://lists.ibiblio.org/pipermail/sm-discuss/2006-May/014586.html
> where git wins for clone, status and log, but is slower for pull.
I had an impression, though the report does not talk about this
specific detail, that the extra time we are paying is because
the "git pull" test is done without suppressing the final
diffstat phase.
^ permalink raw reply
* Re: qgit idea: interface for cherry-picking
From: Marco Costalba @ 2006-07-04 18:23 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e5bfff550607040421id4e71efw38ee2bd773c949de@mail.gmail.com>
On 7/4/06, Marco Costalba <mcostalba@gmail.com> wrote:
> On 7/4/06, Junio C Hamano <junkio@cox.net> wrote:
> > "Marco Costalba" <mcostalba@gmail.com> writes:
> >
>
> I have started to implement the feature suggested by Jakub (patch in
> working dir only, not committed).
Ok. I have pushed two patches, the first with support for applying a
patch series in working dir only, i.e. without to create new commits,
the second to add "branch that a rev belongs to" info as in gitk, near
tags information was already there.
The difference with gitk is that only loaded branch/tags are
considered, this is to better scale.
Anyhow, due to little tricks ;-) , indexing is very fast, about 250ms
to index the whole Linux tree on my box.
Marco
^ permalink raw reply
* Re: qgit idea: interface for cherry-picking
From: Marco Costalba @ 2006-07-04 18:38 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Junio C Hamano
In-Reply-To: <e8dqfo$3ff$1@sea.gmane.org>
On 7/4/06, Jakub Narebski <jnareb@gmail.com> wrote:
> Marco Costalba wrote:
>
> >
> > Is this something that can fulfill you request? do you need something
> > different? perhaps something as a "default to current selected SHA as
> > input argument" flag.
>
> It would be nice (I don't know if feasible) that either to provide some kind
> of parameters substitution in the likes of "%head" in the invocation line
> for a script to be expanded to the sha1 or name of head of currently
> selected commit.
>
Well, I think that the indiscussed champion in this field is git-rev-parse
Please note that an action have not to be _one_ git command, but you
can assign a command sequence to an action, if the first command is
git-rev-parse probably you have what you need.
I have to better explain some implemantation details. In case a multi
line text is set as an action content, qgit wraps up the content in a
temporary script and run the script as a whole.
So you can use anything inside your action definition.
NOTE: this is possible because the input parameters are _always_
appended to the first line command only.
As example if the action 'test' is defined as:
echo
echo 2
echo 3
When you run 'test' and insert '1' when prompted for input
parameters the output will be:
1
2
3
Hope this helps.
Marco
^ permalink raw reply
* Re: Making perl scripts include the correct Git.pm
From: Marco Costalba @ 2006-07-04 19:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git
In-Reply-To: <7vwtavxyas.fsf@assigned-by-dhcp.cox.net>
On 7/3/06, Junio C Hamano <junkio@cox.net> wrote:
> Junio C Hamano <junkio@cox.net> writes:
>
> On the other front, I applied the --remove-empty --parents fix
> by Linus to "master". Since this broke gitk and qgit it might
> warrant a 1.4.1.1 hotfix.
>
Well on the qgit side the bug is plus or less harmless, you see some
spurious revisions in file annotation history and a warning message on
stderr, but not a show stopper.
Marco
^ permalink raw reply
* git2rss --- publish changes from git-log via RSS
From: Bennett Todd @ 2006-07-04 19:11 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1071 bytes --]
Just switched Bent Linux[1] from darcs to git (darcs is sexy, but I
can build git; ghc defeats me). So I hacked up a quick and simple
git2rss to replace my use of darcs2rss for publishing updates.
<URL:http://bent.latency.net/git2rss>
I hardcoded a couple of Bent-linux-specific bits in there, if
anybody else is actually interested in this, let me know, we can
discuss how to peel 'em out.
I like to read the back archives before posting to a list I've just
subscribed to, but couldn't find a downloadable version of the git
list. If anybody could point me to one, I'd appreciate it.
-Bennett
[1] Bent Linux probably isn't of interest to anybody else, it's my
mid-life crisis project, sound bite "unix as I came to love hear in
the early '80s, when she and I were both much younger, slimmer, and
healthier". uClibc, static linking only, no dynamic loading, no
i18n, nothing gui. Handy for building initrds, perhaps useful for
embedded applications. Nobody but a total crank like me would use it
as their favoured workstation OS.
<URL:http://bent.latency.net/bent/>
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git-fetch per-repository speed issues
From: Linus Torvalds @ 2006-07-04 19:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, jnareb
In-Reply-To: <7vk66tgt6n.fsf@assigned-by-dhcp.cox.net>
On Tue, 4 Jul 2006, Junio C Hamano wrote:
>
> I had an impression, though the report does not talk about this
> specific detail, that the extra time we are paying is because
> the "git pull" test is done without suppressing the final
> diffstat phase.
I'm pretty sure that was the reason for the particular hg issue. Looking
at the "clone" times, the problem is almost certainly not the actual
pulling.
The diffstat generation is often the largest part of a git merge. It's
gotten cheaper since the hg benchmarks were done (I think they were done
back before the integrated diff generation, so they also have the overhead
of executing a lot of external GNU diff processes), but it's still not
"cheap".
But I have to say that the diffstat at least for me is absolutely
invaluable.
Linus
^ permalink raw reply
* [PATCH] rev-list: free commit_list in ... handler
From: Rene Scharfe @ 2006-07-04 19:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin
Johannes noticed the missing call to free_commit_list() in the
patch from Santi to add ... support to rev-parse. Turns out I
forgot it too in rev-list. This patch is against the next branch
(3b1d06a).
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
diff --git a/revision.c b/revision.c
index 66390c9..a7750e6 100644
--- a/revision.c
+++ b/revision.c
@@ -817,6 +817,7 @@ int setup_revisions(int argc, const char
exclude = get_merge_bases(a, b, 1);
add_pending_commit_list(revs, exclude,
flags_exclude);
+ free_commit_list(exclude);
a->object.flags |= flags;
} else
a->object.flags |= flags_exclude;
^ permalink raw reply related
* Improve git-peek-remote
From: Linus Torvalds @ 2006-07-04 19:29 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
This makes git-peek-remote able to basically do everything that
git-ls-remote does (but obviously just for the native protocol, so no
http[s]: or rsync: support).
The default behaviour is the same, but you can now give a mixture of
"--refs", "--tags" and "--heads" flags, where "--refs" forces
git-peek-remote to only show real refs (ie none of the fakey tag lookups,
but also not the special pseudo-refs like HEAD and MERGE_HEAD).
The "--tags" and "--heads" flags respectively limit the output to just
regular tags and heads, of course.
You can still also ask to limit them by name too.
You can combine the flags, so
git peek-remote --refs --tags .
will show all local _true_ tags, without the generated tag lookups
(compare the output without the "--refs" flag).
And "--tags --heads" will show both tags and heads, but will avoid (for
example) any special refs outside of the standard locations.
I'm also planning on adding a "--ignore-local" flag that allows us to ask
it to ignore any refs that we already have in the local tree, but that's
an independent thing.
All this is obviously gearing up to making "git fetch" cheaper.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
cache.h | 6 +++++-
connect.c | 35 +++++++++++++++++++++++++++++++----
peek-remote.c | 28 +++++++++++++++++++++-------
send-pack.c | 2 +-
4 files changed, 58 insertions(+), 13 deletions(-)
diff --git a/cache.h b/cache.h
index 84770bf..7b5c91c 100644
--- a/cache.h
+++ b/cache.h
@@ -322,13 +322,17 @@ struct ref {
char name[FLEX_ARRAY]; /* more */
};
+#define REF_NORMAL (1u << 0)
+#define REF_HEADS (1u << 1)
+#define REF_TAGS (1u << 2)
+
extern int git_connect(int fd[2], char *url, const char *prog);
extern int finish_connect(pid_t pid);
extern int path_match(const char *path, int nr, char **match);
extern int match_refs(struct ref *src, struct ref *dst, struct ref ***dst_tail,
int nr_refspec, char **refspec, int all);
extern int get_ack(int fd, unsigned char *result_sha1);
-extern struct ref **get_remote_heads(int in, struct ref **list, int nr_match, char **match, int ignore_funny);
+extern struct ref **get_remote_heads(int in, struct ref **list, int nr_match, char **match, unsigned int flags);
extern int server_supports(const char *feature);
extern struct packed_git *parse_pack_index(unsigned char *sha1);
diff --git a/connect.c b/connect.c
index 9a87bd9..4422a0d 100644
--- a/connect.c
+++ b/connect.c
@@ -12,11 +12,40 @@ #include <signal.h>
static char *server_capabilities = NULL;
+static int check_ref(const char *name, int len, unsigned int flags)
+{
+ if (!flags)
+ return 1;
+
+ if (len > 45 || memcmp(name, "refs/", 5))
+ return 0;
+
+ /* Skip the "refs/" part */
+ name += 5;
+ len -= 5;
+
+ /* REF_NORMAL means that we don't want the magic fake tag refs */
+ if ((flags & REF_NORMAL) && check_ref_format(name) < 0)
+ return 0;
+
+ /* REF_HEADS means that we want regular branch heads */
+ if ((flags & REF_HEADS) && !memcmp(name, "heads/", 6))
+ return 1;
+
+ /* REF_TAGS means that we want tags */
+ if ((flags & REF_TAGS) && !memcmp(name, "tags/", 5))
+ return 1;
+
+ /* All type bits clear means that we are ok with anything */
+ return !(flags & ~REF_NORMAL);
+}
+
/*
* Read all the refs from the other end
*/
struct ref **get_remote_heads(int in, struct ref **list,
- int nr_match, char **match, int ignore_funny)
+ int nr_match, char **match,
+ unsigned int flags)
{
*list = NULL;
for (;;) {
@@ -43,10 +72,8 @@ struct ref **get_remote_heads(int in, st
server_capabilities = strdup(name + name_len + 1);
}
- if (ignore_funny && 45 < len && !memcmp(name, "refs/", 5) &&
- check_ref_format(name + 5))
+ if (!check_ref(name, name_len, flags))
continue;
-
if (nr_match && !path_match(name, nr_match, match))
continue;
ref = xcalloc(1, sizeof(*ref) + len - 40);
diff --git a/fetch-pack.c b/fetch-pack.c
diff --git a/peek-remote.c b/peek-remote.c
index a90cf22..2b30980 100644
--- a/peek-remote.c
+++ b/peek-remote.c
@@ -7,11 +7,11 @@ static const char peek_remote_usage[] =
"git-peek-remote [--exec=upload-pack] [host:]directory";
static const char *exec = "git-upload-pack";
-static int peek_remote(int fd[2])
+static int peek_remote(int fd[2], unsigned flags)
{
struct ref *ref;
- get_remote_heads(fd[0], &ref, 0, NULL, 0);
+ get_remote_heads(fd[0], &ref, 0, NULL, flags);
packet_flush(fd[1]);
while (ref) {
@@ -28,6 +28,7 @@ int main(int argc, char **argv)
int fd[2];
pid_t pid;
int nongit = 0;
+ unsigned flags = 0;
setup_git_directory_gently(&nongit);
@@ -35,22 +36,35 @@ int main(int argc, char **argv)
char *arg = argv[i];
if (*arg == '-') {
- if (!strncmp("--exec=", arg, 7))
+ if (!strncmp("--exec=", arg, 7)) {
exec = arg + 7;
- else
- usage(peek_remote_usage);
- continue;
+ continue;
+ }
+ if (!strcmp("--tags", arg)) {
+ flags |= REF_TAGS;
+ continue;
+ }
+ if (!strcmp("--heads", arg)) {
+ flags |= REF_HEADS;
+ continue;
+ }
+ if (!strcmp("--refs", arg)) {
+ flags |= REF_NORMAL;
+ continue;
+ }
+ usage(peek_remote_usage);
}
dest = arg;
break;
}
+
if (!dest || i != argc - 1)
usage(peek_remote_usage);
pid = git_connect(fd, dest, exec);
if (pid < 0)
return 1;
- ret = peek_remote(fd);
+ ret = peek_remote(fd, flags);
close(fd[0]);
close(fd[1]);
finish_connect(pid);
diff --git a/send-pack.c b/send-pack.c
index af93b11..4019a4b 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -239,7 +239,7 @@ static int send_pack(int in, int out, in
int expect_status_report = 0;
/* No funny business with the matcher */
- remote_tail = get_remote_heads(in, &remote_refs, 0, NULL, 1);
+ remote_tail = get_remote_heads(in, &remote_refs, 0, NULL, REF_NORMAL);
get_local_heads();
/* Does the other end support the reporting? */
^ permalink raw reply related
* Re: Improve git-peek-remote
From: Linus Torvalds @ 2006-07-04 20:01 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0607041222110.12404@g5.osdl.org>
On Tue, 4 Jul 2006, Linus Torvalds wrote:
>
> This makes git-peek-remote able to basically do everything that
> git-ls-remote does (but obviously just for the native protocol, so no
> http[s]: or rsync: support).
Btw, if it wasn't clear - it's not actually a git-ls-remote replacement
yet, even for native protocols. It doesn't actually do the remote URL
thing, so you can't do simple things like
git peek-remote origin
for example.
Things like "git fetch", that do their own remote parsing anyway, don't
actually care, but I thought I'd mention it anyway, just so nobody gets
surprised.
Linus
^ permalink raw reply
* Re: [PATCH] Additional merge-base tests
From: A Large Angry SCM @ 2006-07-04 20:08 UTC (permalink / raw)
To: Junio C Hamano, git
In-Reply-To: <7vpsgllsnp.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> A Large Angry SCM <gitzilla@gmail.com> writes:
>
>>> This is a good demonstration that merge-base may not give you
>>> minimal set for pathological cases. If you want to be through
>>> you could traverse everything to make sure we do not say 'S' is
>>> relevant, but that is quite expensive, so I think there will
>>> always be artifacts of horizon effect like this no matter how
>>> you try to catch it (didn't I keep saying that already?).
>> The problem is in mark_reachable_commits(); it is either superfluous
>> or it needs to parse_commit() those commits that haven't been parsed
>> yet that it needs to traverse.
>
> Yes, you could traverse everything. But that is not practical.
> We have known that the clean-up pass has this horizon effect,
> and it is a compromise.
The clean-up pass was devised to eliminate bases that are reachable from
other bases. It just doesn't look hard enough.
> If you apply this testing patch on top of yours, you will see
> that parsing more commits at that point makes the clean-up
> pass go all the way down to the root commit.
Yes, I was aware of graphs that would have that behavior.
The root of the problem is that the heuristic, that attempts to use
timestamps to detect that a commit is _not_ reachable from a given
commit, relies on the timestamps of commits with a reachability
relationship to have a relationship that matches the graph.
> We may alternatively not use the clean-up pass at all, but I
> suspect that might give us many false positives. I don't
> remember the details but I think we added it while fixing
> merge-base in the real life situation.
The history of the clean-up pass is that before it was added,
git-merge-base was returning a base reachable from another base, and the
base returned was, in some significant way, worse for merging. My
construct demonstrates that the clean-up pass only deals with special case.
> It may be interesting to run tests on real merges (I believe the
> kernel repository has a handful merges that have more than one
> merge bases) to see how effective the current clean-up pass is.
> It may turn out to be ineffective in practice, in which case we
> could kill it off.
Although a very important set of repositories to Git, the linux kernel
repositories may no longer be representative of the diversity of Git
use. Still, it would be interesting to know the outcome.
^ permalink raw reply
* Re: [PATCH] Additional merge-base tests
From: A Large Angry SCM @ 2006-07-04 20:18 UTC (permalink / raw)
To: Johannes Schindelin, git; +Cc: Junio C Hamano
In-Reply-To: <Pine.LNX.4.63.0607041019580.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> Hi,
>
> On Tue, 4 Jul 2006, Junio C Hamano wrote:
>
>> A Large Angry SCM <gitzilla@gmail.com> writes:
>>
>>>> This is a good demonstration that merge-base may not give you
>>>> minimal set for pathological cases. If you want to be through
>>>> you could traverse everything to make sure we do not say 'S' is
>>>> relevant, but that is quite expensive, so I think there will
>>>> always be artifacts of horizon effect like this no matter how
>>>> you try to catch it (didn't I keep saying that already?).
>>> The problem is in mark_reachable_commits(); it is either superfluous
>>> or it needs to parse_commit() those commits that haven't been parsed
>>> yet that it needs to traverse.
>> Yes, you could traverse everything. But that is not practical.
>> We have known that the clean-up pass has this horizon effect,
>> and it is a compromise.
>
> We could introduce a time.maximumSkew variable, and just walk only
> that much further when traversing the commits.
>
> So, if you do not trust your clients to have a proper ntp setup, just say
> "I trust my peers to be off at most 1 day". That would save lots vs
> traverse-everything.
The fuzz would only serve to mask, even more, that the heuristic is
broken. But, it would also allow the (broken) heuristic to be used _and_
let the user decide how much effort may be used to find the correct bases.
If this happens, it should be (yet another) user configurable; either,
per repository, command line, or both.
^ permalink raw reply
* Re: git-fetch per-repository speed issues
From: Junio C Hamano @ 2006-07-04 21:05 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0607041219540.12404@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> But I have to say that the diffstat at least for me is absolutely
> invaluable.
Oh, I absolutely agree with that and somebody who suggests to
turn it off by default needs a very good argument to convince
me.
^ permalink raw reply
* Re: git2rss --- publish changes from git-log via RSS
From: Jakub Narebski @ 2006-07-04 21:09 UTC (permalink / raw)
To: git
In-Reply-To: <20060704191135.GB10534@rahul.net>
Bennett Todd wrote:
> Just switched Bent Linux[1] from darcs to git (darcs is sexy, but I
> can build git; ghc defeats me). So I hacked up a quick and simple
> git2rss to replace my use of darcs2rss for publishing updates.
>
> <URL:http://bent.latency.net/git2rss>
Added to http://git.or.cz/gitwiki/InterfacesFrontendsAndTools#git2rss
Please correct/expand the info if needed.
BTW. gitweb includes RSS feed, see e.g.:
http://www.kernel.org/git/?p=git/git.git;a=rss
http://www.kernel.org/git/?p=git/git.git;a=opml
> I like to read the back archives before posting to a list I've just
> subscribed to, but couldn't find a downloadable version of the git
> list. If anybody could point me to one, I'd appreciate it.
Both GitWiki and Wikipedia
http://git.or.cz/gitwiki/GitCommunity
http://en.wikipedia.org/wiki/Git_%28software%29
mentions several git mailing list archives
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ 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