* Re: [PATCH 2/2] git-remote: add verbose mode
From: Junio C Hamano @ 2008-11-17 10:15 UTC (permalink / raw)
To: crquan; +Cc: git
In-Reply-To: <1226913150-26088-2-git-send-email-crquan@gmail.com>
crquan@gmail.com writes:
> From: Denis ChengRq <crquan@gmail.com>
>
> Signed-off-by: Cheng Renquan <crquan@gmail.com>
Your other one (I am assuming the other one is also from you) has "From:
Cheng Renquan <crquan@gmail.com>" and this is "From: Denis ChengRq
<crquan@gmail.com>". We'd prefer to keep the same person under a single
name in "git shortlog" list. Under which name do you want to be known?
Please describe in what sense this is "verbose", iow, what additional
information is added by this patch, in your proposed commit log message.
> @@ -40,10 +40,13 @@ static int opt_parse_track(const struct option *opt, const char *arg, int not)
> return 0;
> }
>
> -static int fetch_remote(const char *name)
> +static int fetch_remote(const char *name, const char *url)
> {
> const char *argv[] = { "fetch", name, NULL };
> - printf("Updating %s\n", name);
> + if (verbose)
> + printf("Updating %s (%s)\n", name, url);
Are you guaranteeing that url is not NULL at this point in the code?
If so how?
How does this "--verbose" command the users give "git remote" relate to
the "--verbose" option the underlying "git fetch" has? IOW, do you tell
"git fetch" to be verbose as well? If so, how? If not, why not?
^ permalink raw reply
* Re: [PATCH 1/2] remote short help message updated
From: Junio C Hamano @ 2008-11-17 10:15 UTC (permalink / raw)
To: crquan; +Cc: git
In-Reply-To: <1226913150-26088-1-git-send-email-crquan@gmail.com>
crquan@gmail.com writes:
> From: Cheng Renquan <crquan@gmail.com>
>
> Synced from git help remote.
>
> Signed-off-by: Cheng Renquan <crquan@gmail.com>
We strongly prefer writing commit log message in imperative mood, like:
[PATCH] git-remote: match usage string with the manual pages
The patch itself looks good. Thanks.
^ permalink raw reply
* Re: [PATCH] gitweb: fixes to gitweb feature check code
From: Junio C Hamano @ 2008-11-17 10:09 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Giuseppe Bilotta, git, Petr Baudis, Junio C Hamano
In-Reply-To: <200811171028.19807.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Dnia poniedziałek 17. listopada 2008 07:10, Giuseppe Bilotta napisał:
>> On Mon, Nov 17, 2008 at 2:02 AM, Jakub Narebski <jnareb@gmail.com> wrote:
>
> [...]
>> > First, you forgot the signoff, but you have addressed that already.
>> >
>> >
>> > Second, I thought at first that it would be good for the patch to also
>> > simplify %feature hash, using "'default' => 1" instead of current bit
>> > convoluted "'default' => [1]", at the cost of bit more code for
>> > defensive programming. But now I think that if it is to be done,
>> > it should be put as separate patch.
>>
>> Is this an ACK? 8-D
>
> I'm sorry. Yes, it is.
Are you sure, even with those unnecessary changes from list context
assignments to scalar ones?
^ permalink raw reply
* Re: [PATCH] Makefile: introduce NO_PTHREADS
From: Mike Ralphson @ 2008-11-17 10:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, Git Mailing List, Linus Torvalds
In-Reply-To: <alpine.LFD.2.00.0811150915240.3468@nehalem.linux-foundation.org>
2008/11/15 Linus Torvalds <torvalds@linux-foundation.org>:
>
> On Sat, 15 Nov 2008, Junio C Hamano wrote:
>>
>> This introduces make variable NO_PTHREADS for platforms that lack the
>> support for pthreads library or people who do not want to use it for
>> whatever reason. When defined, it makes the multi-threaded index
>> preloading into a no-op, and also disables threaded delta searching by
>> pack-objects.
>
> Ack. Makes sense.
I'd be minded to make this the default on AIX to keep the prerequisite
list as small as possible, then people can opt-in for the performance
benefits if required.
I'll wait a little while to see if anyone else reports the same for
other platforms and then submit a patch.
Mike
^ permalink raw reply
* Re: [PATCH] gitweb: fixes to gitweb feature check code
From: Jakub Narebski @ 2008-11-17 9:28 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Petr Baudis, Junio C Hamano
In-Reply-To: <cb7bb73a0811162210iadb7511rc3474272c8e60c59@mail.gmail.com>
Dnia poniedziałek 17. listopada 2008 07:10, Giuseppe Bilotta napisał:
> On Mon, Nov 17, 2008 at 2:02 AM, Jakub Narebski <jnareb@gmail.com> wrote:
[...]
> > First, you forgot the signoff, but you have addressed that already.
> >
> >
> > Second, I thought at first that it would be good for the patch to also
> > simplify %feature hash, using "'default' => 1" instead of current bit
> > convoluted "'default' => [1]", at the cost of bit more code for
> > defensive programming. But now I think that if it is to be done,
> > it should be put as separate patch.
>
> Is this an ACK? 8-D
I'm sorry. Yes, it is.
Acked-by: Jakub Narebski <jnareb@gmail.com>
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH 2/2] git-remote: add verbose mode
From: crquan @ 2008-11-17 9:12 UTC (permalink / raw)
To: git
In-Reply-To: <1226913150-26088-1-git-send-email-crquan@gmail.com>
From: Denis ChengRq <crquan@gmail.com>
Signed-off-by: Cheng Renquan <crquan@gmail.com>
---
builtin-remote.c | 19 +++++++++++++------
1 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/builtin-remote.c b/builtin-remote.c
index d032f25..8a9f4b5 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c
@@ -14,7 +14,7 @@ static const char * const builtin_remote_usage[] = {
"git remote rm <name>",
"git remote show [-n] <name>",
"git remote prune [-n | --dry-run] <name>",
- "git remote update [group]",
+ "git remote update [-v | --verbose] [group]",
NULL
};
@@ -40,10 +40,13 @@ static int opt_parse_track(const struct option *opt, const char *arg, int not)
return 0;
}
-static int fetch_remote(const char *name)
+static int fetch_remote(const char *name, const char *url)
{
const char *argv[] = { "fetch", name, NULL };
- printf("Updating %s\n", name);
+ if (verbose)
+ printf("Updating %s (%s)\n", name, url);
+ else
+ printf("Updating %s\n", name);
if (run_command_v_opt(argv, RUN_GIT_CMD))
return error("Could not fetch %s", name);
return 0;
@@ -117,7 +120,7 @@ static int add(int argc, const char **argv)
return 1;
}
- if (fetch && fetch_remote(name))
+ if (fetch && fetch_remote(name, url))
return 1;
if (master) {
@@ -769,8 +772,12 @@ static int prune(int argc, const char **argv)
static int get_one_remote_for_update(struct remote *remote, void *priv)
{
struct string_list *list = priv;
+
if (!remote->skip_default_update)
- string_list_append(xstrdup(remote->name), list);
+ string_list_append(remote->name, list)->util =
+ remote->url_nr > 0
+ ? (void *)remote->url[remote->url_nr-1] : NULL;
+
return 0;
}
@@ -818,7 +825,7 @@ static int update(int argc, const char **argv)
result = for_each_remote(get_one_remote_for_update, &list);
for (i = 0; i < list.nr; i++)
- result |= fetch_remote(list.items[i].string);
+ result |= fetch_remote(list.items[i].string, list.items[i].util);
/* all names were strdup()ed or strndup()ed */
list.strdup_strings = 1;
--
1.6.0.2
^ permalink raw reply related
* [PATCH 1/2] remote short help message updated
From: crquan @ 2008-11-17 9:12 UTC (permalink / raw)
To: git
From: Cheng Renquan <crquan@gmail.com>
Synced from git help remote.
Signed-off-by: Cheng Renquan <crquan@gmail.com>
---
builtin-remote.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/builtin-remote.c b/builtin-remote.c
index 71696b5..d032f25 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c
@@ -8,12 +8,12 @@
#include "refs.h"
static const char * const builtin_remote_usage[] = {
- "git remote",
- "git remote add <name> <url>",
+ "git remote [-v | --verbose]",
+ "git remote add [-t <branch>] [-m <master>] [-f] [--mirror] <name> <url>",
"git remote rename <old> <new>",
"git remote rm <name>",
- "git remote show <name>",
- "git remote prune <name>",
+ "git remote show [-n] <name>",
+ "git remote prune [-n | --dry-run] <name>",
"git remote update [group]",
NULL
};
--
1.6.0.2
^ permalink raw reply related
* [PATCH] request-pull: make usage string match manpage
From: Stefan Naewe @ 2008-11-17 8:57 UTC (permalink / raw)
To: git; +Cc: Stefan Naewe
The usage string of 'git request-pull' differs from he manpage
which gives the correct 'synopsis'.
Signed-off-by: Stefan Naewe <stefan.naewe@atlas-elektronik.com>
---
git-request-pull.sh | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/git-request-pull.sh b/git-request-pull.sh
index 073a314..9088019 100755
--- a/git-request-pull.sh
+++ b/git-request-pull.sh
@@ -4,9 +4,9 @@
# This file is licensed under the GPL v2, or a later version
# at the discretion of Linus Torvalds.
-USAGE='<commit> <url> [<head>]'
-LONG_USAGE='Summarizes the changes since <commit> to the standard output,
-and includes <url> in the message generated.'
+USAGE='<start> <url> [<end>]'
+LONG_USAGE='Summarizes the changes between two commits to the standard output,
+and includes the given URL in the generated summary.'
SUBDIRECTORY_OK='Yes'
OPTIONS_SPEC=
. git-sh-setup
--
1.5.6.5
^ permalink raw reply related
* [PATCH] gitweb: fix encode handling for site_{header,footer}
From: Tatsuki Sugiura @ 2008-11-17 7:53 UTC (permalink / raw)
To: git
All non-ASCII chars of site_{header,footer} will be broken
by perl IO layer without decoding to utf8.
Here is a fix to just call to_utf8 for inputs from these files.
Signed-off-by: Tatsuki Sugiura <sugi@nemui.org>
---
gitweb/gitweb.perl | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 933e137..79ca5c2 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2929,7 +2929,7 @@ EOF
if (-f $site_header) {
open (my $fd, $site_header);
- print <$fd>;
+ print map {to_utf8($_)} <$fd>;
close $fd;
}
@@ -3018,7 +3018,7 @@ sub git_footer_html {
if (-f $site_footer) {
open (my $fd, $site_footer);
- print <$fd>;
+ print map {to_utf8($_)} <$fd>;
close $fd;
}
--
1.5.6.5
^ permalink raw reply related
* Re: git to libgit2 code relicensing
From: Andreas Ericsson @ 2008-11-17 7:24 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Christian Couder, Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0811162159280.30769@pacific.mpi-cbg.de>
Johannes Schindelin wrote:
> Hi,
>
> On Sun, 16 Nov 2008, Andreas Ericsson wrote:
>
>> With the current list of ok's 73.09% of the code in git.git seems to be
>> relicenseable for the purpose of libgit2. That will provide quite a
>> kickstart.
>
> I doubt it. Most of that code was written with the execute-once
> mentality. And with the we-have-posix mentality.
>
"Copy-rewrite", naturally. Being able to lift much of the data-munging code
is a great benefit. It's basically just the revision traversal (which is
heavy on state-dependant code) that I haven't quite figured out how to do
yet, but I believe Shawn's idea of using revision pools is most likely the
way to go. Each application has to make sure a pool isn't modified by more
than one thread, but each application can have as many pools as it likes.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: publish since current state?
From: Andreas Ericsson @ 2008-11-17 7:21 UTC (permalink / raw)
To: Gennady Kushnir; +Cc: git
In-Reply-To: <96ed5eac0811161242o4c800e37u7c96872a9a4351ef@mail.gmail.com>
Gennady Kushnir wrote:
> Hello list.
> I'm going to publish my work into online public repository.
> I have several months of previous history in my local git repo. And I
> don't want to make it all public.
> Is it possible to publish just a shallow copy of my repository storing
> my current tree?
Yes. Look for 'grafts' in the documentation. You'll have to create a
new repository containing only the most recent code first, and then
create the grafts-file in that repository and copy the object database
from the old repository into the new one.
> I'd also like to keep my local history private but push new commits
> from it into that online repo.
>
The grafts solution will work like that, assuming you don't publish
your grafts-file.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: GIT and SCC
From: Andreas Ericsson @ 2008-11-17 7:05 UTC (permalink / raw)
To: Jan Hudec
Cc: Theodore Tso, Martin Terreni, Mike Ralphson, Shawn O. Pearce, git
In-Reply-To: <20081116215134.GA4719@efreet.light.src>
Jan Hudec wrote:
> On Wed, Nov 05, 2008 at 14:38:25 -0500, Theodore Tso wrote:
>> On Wed, Nov 05, 2008 at 09:23:55PM +0200, Martin Terreni wrote:
>>> http://en.wikipedia.org/wiki/SCC_compliant
>>>
>>> It is probably not much, but this is what I could find in a minute. many
>>> VC system have a SCC complaint API (apart of the native). This protocol
>>> was created by M$ is used by many systems so they are not bound to a
>>> specific VC tool.
>> It's a closed-source, undocumented API that you can only get access to
>> by signing a Microsoft NDA. From the WinMerge API:
>>
>> SCC API is closed API (no public documentation available) some
>> IDE's (e.g. Visual Studio) use. There apparently have couple
>> of reverse-engineered free implementations for SCC API. Status
>> of those are unknown.
>>
>> WARNING: Be very sure you are not submitting any code behing
>> NDA for WinMerge. WinMerge is Open Source so it is not legal
>> to do. And what is worse it would prevent anybody reading that
>> code working with SCC (and perhaps also VCS) support.
>>
>
> I don't really know what this interface is about, but:
> - For VS6 and newer, source control plugin can be implemented by creating
> a dll exporting particular set of controls. This is documented in help
> files that come with VS2005 SDK which is freely downloadable from M$ web,
> so I don't think that would be under NDA.
> - For VS2003 and newer (ie. the .NET based versions), plugins can be
> implemented for almost anything, including source control, by creating
> .net assembly exporting classes that implement some particular interfaces.
> These interfaces are documented in the abovementioned SDK, so again no NDA
> needed.
> I actually started writing such plugin some months back, but since I can only
> work on it at $work (don't have Windooze at ~, not to mention VS2005 license
> -- the SDK is free to download, but requires full, non-express, studio) and
> since it does not look like I could get them use Git at $work anytime soon,
> I didn't work on it too much. Still I could share the basic skeleton and
> the knowledge I have if somebody wanted to move that somewhere.
>
I'm interested. Please email me off-list. I'll pass it on to the monodevelop
people and see what happens. Hopefully they can reuse the same interface so
that mono plugins all of a sudden work everywhere.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] gitweb: fixes to gitweb feature check code
From: Giuseppe Bilotta @ 2008-11-17 6:10 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Petr Baudis, Junio C Hamano
In-Reply-To: <200811170202.27893.jnareb@gmail.com>
On Mon, Nov 17, 2008 at 2:02 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Sat, 15 Nov 2008, Giuseppe Bilotta wrote:
>
>> The gitweb_check_feature routine was being used for two different
>> purposes: retrieving the actual feature value (such as the list of
>> snapshot formats or the list of additional actions), and to check if a
>> feature was enabled.
>>
>> For the latter use, since all features return an array, it led to either
>> clumsy code or subtle bugs, with disabled features appearing enabled
>> because (0) evaluates to 1.
>>
>> We fix these bugs, and simplify the code, by separating feature (list)
>> value retrieval (gitweb_get_feature) from boolean feature check (i.e.
>> retrieving the first/only item in the feature value list). Usage of
>> gitweb_check_feature across gitweb is replaced by the appropriate call
>> wherever needed.
>> ---
>
> First, you forgot the signoff, but you have addressed that already.
>
>
> Second, I thought at first that it would be good for the patch to also
> simplify %feature hash, using "'default' => 1" instead of current bit
> convoluted "'default' => [1]", at the cost of bit more code for
> defensive programming. But now I think that if it is to be done,
> it should be put as separate patch.
Is this an ACK? 8-D
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: purging unwanted history
From: Geoff Russell @ 2008-11-17 3:03 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: git
In-Reply-To: <20081117022714.GC3911@atjola.homenet>
On Mon, Nov 17, 2008 at 12:57 PM, Björn Steinbrink <B.Steinbrink@gmx.de> wrote:
> On 2008.11.17 03:24:12 +0100, Björn Steinbrink wrote:
>> On 2008.11.17 10:56:23 +1030, Geoff Russell wrote:
>> > I have a repository with 5 years worth of history, I only want to keep
>> > 1 year, so I want to purge the first 4 years. As it happens, the
>> > repository only has a single branch which should simplify the problem.
>>
>> Use filter-branch to drop the parents on the first commit you want to
>> keep, and then drop the old cruft.
>>
>> Let's say $drop is the hash of the latest commit you want to drop. To
>> keep things sane and simple, make sure the first commit you want to
>> keep, ie. the child of $drop, is not a merge commit. Then you can use:
>>
>> git filter-branch --parent-filter "sed -e 's/-p $drop//'" \
>> --tag-name-filter cat -- \
>> --all ^$drop
>>
>> The above rewrites the parents of all commits that come "after" $drop.
>>
>> Check the results with gitk.
>>
>>
>> Then, to clean out all the old cruft.
>>
>> First, the backup references from filter-branch:
>>
>> git for-each-ref --format='%(refname)' refs/original | \
>> while read ref
>> do
>> git update-ref -d "$ref"
>> done
>>
>> Then clean your reflogs:
>> git reflog expire --expire=0 --all
>>
>> And finally, repack and drop all the old unreachable objects:
>> git repack -ad
>> git prune # For objects that repack -ad might have left around
>>
>> At that point, everything leading up to and including $drop should be
>> gone.
>
> Hm, on second thought, if you have tags referencing some of the old
> history, they'll still be around, I think. Just delete those before you
> start the rewriting.
>
> And of course do the above with a copy of your repo. Just in case.
>
> Björn
>
Great, I've just tested this and it is exactly what I want. I'm still
getting my head around
why, but understanding will arrive with a little more thought.
Many thanks,
Geoff
--
6 Fifth Ave,
St Morris, S.A. 5068
Australia
Ph: 041 8805 184 / 08 8332 5069
^ permalink raw reply
* Re: purging unwanted history
From: Björn Steinbrink @ 2008-11-17 2:27 UTC (permalink / raw)
To: Geoff Russell; +Cc: git
In-Reply-To: <20081117022412.GB3911@atjola.homenet>
On 2008.11.17 03:24:12 +0100, Björn Steinbrink wrote:
> On 2008.11.17 10:56:23 +1030, Geoff Russell wrote:
> > I have a repository with 5 years worth of history, I only want to keep
> > 1 year, so I want to purge the first 4 years. As it happens, the
> > repository only has a single branch which should simplify the problem.
>
> Use filter-branch to drop the parents on the first commit you want to
> keep, and then drop the old cruft.
>
> Let's say $drop is the hash of the latest commit you want to drop. To
> keep things sane and simple, make sure the first commit you want to
> keep, ie. the child of $drop, is not a merge commit. Then you can use:
>
> git filter-branch --parent-filter "sed -e 's/-p $drop//'" \
> --tag-name-filter cat -- \
> --all ^$drop
>
> The above rewrites the parents of all commits that come "after" $drop.
>
> Check the results with gitk.
>
>
> Then, to clean out all the old cruft.
>
> First, the backup references from filter-branch:
>
> git for-each-ref --format='%(refname)' refs/original | \
> while read ref
> do
> git update-ref -d "$ref"
> done
>
> Then clean your reflogs:
> git reflog expire --expire=0 --all
>
> And finally, repack and drop all the old unreachable objects:
> git repack -ad
> git prune # For objects that repack -ad might have left around
>
> At that point, everything leading up to and including $drop should be
> gone.
Hm, on second thought, if you have tags referencing some of the old
history, they'll still be around, I think. Just delete those before you
start the rewriting.
And of course do the above with a copy of your repo. Just in case.
Björn
^ permalink raw reply
* Re: purging unwanted history
From: Björn Steinbrink @ 2008-11-17 2:24 UTC (permalink / raw)
To: Geoff Russell; +Cc: git
In-Reply-To: <93c3eada0811161626h69929cd7va3fa4007a2341bae@mail.gmail.com>
On 2008.11.17 10:56:23 +1030, Geoff Russell wrote:
> I have a repository with 5 years worth of history, I only want to keep
> 1 year, so I want to purge the first 4 years. As it happens, the
> repository only has a single branch which should simplify the problem.
Use filter-branch to drop the parents on the first commit you want to
keep, and then drop the old cruft.
Let's say $drop is the hash of the latest commit you want to drop. To
keep things sane and simple, make sure the first commit you want to
keep, ie. the child of $drop, is not a merge commit. Then you can use:
git filter-branch --parent-filter "sed -e 's/-p $drop//'" \
--tag-name-filter cat -- \
--all ^$drop
The above rewrites the parents of all commits that come "after" $drop.
Check the results with gitk.
Then, to clean out all the old cruft.
First, the backup references from filter-branch:
git for-each-ref --format='%(refname)' refs/original | \
while read ref
do
git update-ref -d "$ref"
done
Then clean your reflogs:
git reflog expire --expire=0 --all
And finally, repack and drop all the old unreachable objects:
git repack -ad
git prune # For objects that repack -ad might have left around
At that point, everything leading up to and including $drop should be
gone.
HTH
Björn
^ permalink raw reply
* Re: Re: git rev-list ordering
From: Johannes Schindelin @ 2008-11-17 1:35 UTC (permalink / raw)
To: Ian Hilt; +Cc: sverre, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0811162001550.28544@sys-0.hiltweb.site>
Hi,
On Sun, 16 Nov 2008, Ian Hilt wrote:
> On Sun, 16 Nov 2008, Johannes Schindelin wrote:
>
> > On Sat, 15 Nov 2008, Ian Hilt wrote:
> >
> > > On Sat, 15 Nov 2008, Sverre Rabbelier wrote:
> > > > The --reverse is applied after the --max-count, so you are seeing
> > > > the reverse of one commit ;). For comparison, have a look at:
> > > >
> > > > $ git rev-list --reverse --max-count=2
> > >
> > > Ah, I see. So if you didn't want the sorting to take a long time
> > > for many commits, you would limit the output to n commits, then sort
> > > the output. Is this the logic behind this design?
> >
> > Yes. It is by design, since the guy who wrote the initial --reverse
> > support cannot think of an interesting situation where you need to
> > list the oldest n commits.
>
> I see. Well, the situation in which I found this to be needed was while
> trying to figure out how to find the next commit on branch X while on a
> detached head from that branch without counting how many commits back I
> was. In other words,
>
> $ git checkout X~4
> $ # now I want X~3 without using a number or carets
> $ git checkout $(git rev-list --reverse ..X | head -1)
> -- or --
> $ git checkout $(git rev-list ..X | tail -1)
This could break down horribly when there was branching going on.
However, in case you are certain there is only one child of X~4, I'd
suggest doing this:
$ git checkout $(git rev-list --parents --all ^HEAD |
sed -n "s/ .*$(git rev-parse HEAD).*$//p")
IOW I would list all revisions with parents, and filter out all which do
not have the current one as parent.
Hth,
Dscho
^ permalink raw reply
* Re: git-bugzilla
From: Jakub Narebski @ 2008-11-17 1:23 UTC (permalink / raw)
To: Steve Frécinaux; +Cc: git
In-Reply-To: <492089EA.60205@gmail.com>
Steve Frécinaux <nudrema@gmail.com> writes:
> Here is a chunk of code I wrote a few time ago, to post patches to
> bugzilla, modelled mostly after git-format-patch/git-send-email.
>
> You can find it there:
> http://code.istique.net/?p=git-bugzilla.git
>
> It is written in perl and requires WWW::Mechanize.
[...]
Added to http://git.or.cz/gitwiki/InterfacesFrontendsAndTools
Thanks.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git rev-list ordering
From: Ian Hilt @ 2008-11-17 1:21 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: sverre, Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0811162215370.30769@pacific.mpi-cbg.de>
On Sun, 16 Nov 2008, Johannes Schindelin wrote:
> Hi,
>
> On Sat, 15 Nov 2008, Ian Hilt wrote:
>
> > On Sat, 15 Nov 2008, Sverre Rabbelier wrote:
> > > The --reverse is applied after the --max-count, so you are seeing the
> > > reverse of one commit ;). For comparison, have a look at:
> > >
> > > $ git rev-list --reverse --max-count=2
> >
> > Ah, I see. So if you didn't want the sorting to take a long time for
> > many commits, you would limit the output to n commits, then sort the
> > output. Is this the logic behind this design?
>
> Yes. It is by design, since the guy who wrote the initial --reverse
> support cannot think of an interesting situation where you need to list
> the oldest n commits.
I see. Well, the situation in which I found this to be needed was while
trying to figure out how to find the next commit on branch X while on a
detached head from that branch without counting how many commits back I
was. In other words,
$ git checkout X~4
$ # now I want X~3 without using a number or carets
$ git checkout $(git rev-list --reverse ..X | head -1)
-- or --
$ git checkout $(git rev-list ..X | tail -1)
So maybe there's a better way to do this. I don't know. If the commits
were reversed _then_ limited I wouldn't need to use the pipe to
head/tail. Not that that is a problem, it just seemed like it should
work with reverse and max-count.
^ permalink raw reply
* Re: [PATCHv3 2/4] gitweb: git_get_heads_list accepts an optional list of refs.
From: Jakub Narebski @ 2008-11-17 1:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Giuseppe Bilotta, git, Petr Baudis
In-Reply-To: <7vod0f37gr.fsf@gitster.siamese.dyndns.org>
On Sun, 16 Nov 2008, Junio C Hamano wrote:
> Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
>
> > git_get_heads_list(limit, class1, class2, ...) can now be used to retrieve
> > refs/class1, refs/class2 etc. Defaults to ('heads') or ('heads', 'remotes')
> > depending on the remote_heads option.
> >
> > Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
> > ---
> > gitweb/gitweb.perl | 11 +++++++----
> > 1 files changed, 7 insertions(+), 4 deletions(-)
> >
> > diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> > index e1f81f6..0512020 100755
> > --- a/gitweb/gitweb.perl
> > +++ b/gitweb/gitweb.perl
> > @@ -2681,15 +2681,18 @@ sub parse_from_to_diffinfo {
> > ## parse to array of hashes functions
> >
> > sub git_get_heads_list {
> > - my $limit = shift;
> > + my ($limit, @class) = @_;
> > + unless (defined @class) {
> > + my $remote_heads = gitweb_check_feature('remote_heads');
> > + @class = ('heads', $remote_heads ? 'remotes' : undef);
> > + }
> > + my @refs = map { "refs/$_" } @class;
>
> Makes sense, except that I'd suggest passing a hash of "refs/$path" =>
> $class as I illustrated in my comments to [1/4], instead of passing a list
> of ("head", "remote"), because that will later allow you to have
> multi-level $path that does not necessarily limited to a $class that is a
> substring of $path, and doing so does not make the code any more complex.
> There is another reason to do so I'll mention in I comment on [3/4].
By the way, with %head_class hash passed as reference git_get_head_list
could be done in such way, that you can write
git_get_heads_list(\%head_class);
instead of longer
git_get_heads_list(undef, \%head_class);
when there is no limit(er).
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] gitweb: fixes to gitweb feature check code
From: Jakub Narebski @ 2008-11-17 1:02 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Petr Baudis, Junio C Hamano
In-Reply-To: <1226759165-6894-1-git-send-email-giuseppe.bilotta@gmail.com>
On Sat, 15 Nov 2008, Giuseppe Bilotta wrote:
> The gitweb_check_feature routine was being used for two different
> purposes: retrieving the actual feature value (such as the list of
> snapshot formats or the list of additional actions), and to check if a
> feature was enabled.
>
> For the latter use, since all features return an array, it led to either
> clumsy code or subtle bugs, with disabled features appearing enabled
> because (0) evaluates to 1.
>
> We fix these bugs, and simplify the code, by separating feature (list)
> value retrieval (gitweb_get_feature) from boolean feature check (i.e.
> retrieving the first/only item in the feature value list). Usage of
> gitweb_check_feature across gitweb is replaced by the appropriate call
> wherever needed.
> ---
First, you forgot the signoff, but you have addressed that already.
Second, I thought at first that it would be good for the patch to also
simplify %feature hash, using "'default' => 1" instead of current bit
convoluted "'default' => [1]", at the cost of bit more code for
defensive programming. But now I think that if it is to be done,
it should be put as separate patch.
--
Jakub Narebski
Poland
^ permalink raw reply
* purging unwanted history
From: Geoff Russell @ 2008-11-17 0:26 UTC (permalink / raw)
To: git
I have a repository with 5 years worth of history, I only want to keep
1 year, so I want to purge the
first 4 years. As it happens, the repository only has a single branch
which should
simplify the problem.
Cheers,
Geoff Russell
P.S. Apologies, but I've asked this question before but didn't get an
answer which
I understood or which worked, so perhaps my description of the problem
was faulty. This
is a second attempt.
^ permalink raw reply
* Re: "secret key not available". "unable to sign the tag".
From: Linus Torvalds @ 2008-11-17 0:16 UTC (permalink / raw)
To: Jeff King; +Cc: Gary Yang, git
In-Reply-To: <20081115035743.GA19633@coredump.intra.peff.net>
On Fri, 14 Nov 2008, Jeff King wrote:
>
> You need to tell git who you are, since it is unable to deduce it from
> doing host lookups. Try:
>
> git config --global user.email garyyang6@yahoo.com
>
> or whatever email address you used when you created the key, and then
> gpg should find it appropriately.
Side note: sometimes you might want to use a different key than the one
you use for authorship. Then you can use
[user]
SigningKey = key
(or "git config user.signingkey xyz" if you don't want to edit the
config file manually).
This can be especially useful if you use different keys for different
projects, even if you want to be known under the same name in both. Or
because you want to have the local hostname in your commit logs, but your
gpg key is using some externally visible "official" email address.
Linus
^ permalink raw reply
* [ANN] codeswarm.rb v1.0
From: Felipe Contreras @ 2008-11-16 23:29 UTC (permalink / raw)
To: Ruby Talk, git list; +Cc: Peter Burns
Hi,
codeswarm.rb is a rewrite of Michael Ogawa's code_swarm in ruby using cairo.
For an example see:
http://www.youtube.com/watch?v=PxjLbj8oT1k
For the original code:
http://code.google.com/p/codeswarm
The format of the events xml file is compatible with code_swarm's one,
and the physics engine is basically the same.
The code is less than 500 lines of code, so it should be fairly hackable.
http://github.com/felipec/codeswarm.rb
Enjoy :)
--
Felipe Contreras
^ permalink raw reply
* Re: [EGIT PATCH 4/7 v3] Handle peeling of loose refs.
From: Shawn O. Pearce @ 2008-11-16 22:37 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <1226705099-18066-4-git-send-email-robin.rosenberg@dewire.com>
Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
> For packed refs we got peeling automatically from packed-refs,
> but for loose tags we have to follow the tags and get the leaf
> object in order to comply with the documentation.
I merged your series, but I squashed the following into the patch
I am replying to:
.../src/org/spearce/jgit/lib/Repository.java | 12 ++++++++----
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java b/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
index 5088150..c953531 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
@@ -942,13 +942,17 @@ public String getBranch() throws IOException {
}
/**
- * Peel a possibly unpeeled ref and updates it. If the ref cannot be peeled
- * the peeled id is set to {@link ObjectId#zeroId()}
+ * Peel a possibly unpeeled ref and updates it.
+ * <p>
+ * If the ref cannot be peeled (as it does not refer to an annotated tag)
+ * the peeled id stays null, but {@link Ref#isPeeled()} will be true.
*
* @param ref
* The ref to peel
- * @return The same, an updated ref with peeled info or a new instance with
- * more information
+ * @return <code>ref</code> if <code>ref.isPeeled()</code> is true; else a
+ * new Ref object representing the same data as Ref, but isPeeled()
+ * will be true and getPeeledObjectId will contain the peeled object
+ * (or null).
*/
public Ref peel(final Ref ref) {
return refs.peel(ref);
--
1.6.0.4.969.g58a38
--
Shawn.
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox