* Re: [PATCH] handle concurrent pruning of packed objects
From: Junio C Hamano @ 2006-06-02 16:10 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20060602160456.GA8957@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> That shouldn't make a difference for correctness, even if the old packs
> are still there. If you have an object in two packs, then it doesn't
> matter which one you pull it from. The main impacts I can think of are:
> 1. The old pack may already be mapped, and it would be more efficient
> to use it. However, the new pack will be mapped on first use, so it
> will be used from then on.
> 2. The pack list can grow without bound. However, for this to matter,
> you'd have to do many prunes during the course of a single git
> command.
I agree 100% on "shouldn't" part. What I wonder is if everybody
works correctly if we mmap the same file (all available .idx are
mapped all the time, and we map .pack LRU) twice. But I realize
we have NO_MMAP configuration for unfortunate platforms to work
it around so that wouldn't be a big deal.
^ permalink raw reply
* [PATCH] sha1_file: avoid re-preparing duplicate packs
From: Jeff King @ 2006-06-02 16:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk67zbksv.fsf@assigned-by-dhcp.cox.net>
When adding packs, skip the pack if we already have it in the packed_git
list. This might happen if we are re-preparing our packs because of a
missing object.
---
On Fri, Jun 02, 2006 at 09:10:24AM -0700, Junio C Hamano wrote:
> I agree 100% on "shouldn't" part. What I wonder is if everybody
> works correctly if we mmap the same file (all available .idx are
This patch avoids duplicates in the packed_git list. It's not necessary
under Linux, at least, but it just seems cleaner, and it's simple to do.
The list might still have packs that are now gone. I didn't want to
purge anything from the packed_git list since I'm not clear on whether
other code might have pointers into the mmap'd portion.
sha1_file.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index 696e53f..aea0f40 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -617,6 +617,12 @@ static void prepare_packed_git_one(char
/* we have .idx. Is it a file we can map? */
strcpy(path + len, de->d_name);
+ for (p = packed_git; p; p = p->next) {
+ if (!memcmp(path, p->pack_name, len + namelen - 4))
+ break;
+ }
+ if (p)
+ continue;
p = add_packed_git(path, len + namelen, local);
if (!p)
continue;
--
1.3.3.gfb825
^ permalink raw reply related
* http-fetch troubles
From: Junio C Hamano @ 2006-06-02 17:38 UTC (permalink / raw)
To: git, Becky Bruce; +Cc: Nick Hengeveld
In-Reply-To: <7vhd34dptq.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Nick Hengeveld <nickh@reactrix.com> writes:
>
>> - "git push" seems to pass --thin by default to http-push, which
>> subsequently barfs because that's not a valid http-push option.
>> Should it be? Should it be silently ignored? Should git-push not
>> default to --thin when pushing with HTTP transport?
>
> The way I understand http-push works is that it does not use
> packed transfer, so I presume even if we give --thin as a hint
> it cannot even take advantage of it. Probably we should stop
> passing --thin to http transport (git native one uses it as a
> cue that it can generate baseless deltas in the resulting pack).
>
>> - when I clone, http-fetch outputs a whole bunch of
>> "error: Could not read ..." messages - is that expected?
>
> The clone over http seems to be severely broken in "next" right
> now. The one in "master" seems to be OK. bisecting suggests
> the breakage is coming from the tree parser rewrite.
>
> bisect points at 136f2e548a34f1f504b0f062f87ddf33e8d6e83b.
I've pushed out Nick's http-fetch fixes in "master" to see if it
fixes problems for people. Right now the one in "next" branch
seems to be having unrelated problems coming from another topic
which I haven't started tracking down yet.
^ permalink raw reply
* Re: [PATCH] sha1_file: avoid re-preparing duplicate packs
From: Linus Torvalds @ 2006-06-02 17:47 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20060602164932.GA10216@coredump.intra.peff.net>
On Fri, 2 Jun 2006, Jeff King wrote:
>
> This patch avoids duplicates in the packed_git list. It's not necessary
> under Linux, at least, but it just seems cleaner, and it's simple to do.
I think it's a good idea even under Linux, since on 32-bit machines, one
of the constraints we have may simply be virtual memory space to map
things into. With big packs, avoiding mapping them twice is a good idea.
Linus
^ permalink raw reply
* Re: Clean up sha1 file writing
From: H. Peter Anvin @ 2006-06-02 18:44 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Matthias Lederhofer, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0605241145490.5623@g5.osdl.org>
Linus Torvalds wrote:
>
> On Wed, 24 May 2006, Matthias Lederhofer wrote:
>
>>> checking for partial writes
>> Just out of interest: is this to be safe on any OS or should this
>> be checked always?
>
> Any POSIX-conformant OS/filesystem should always do a full write for a
> regular file, unless a serious error happens.
>
Actually, at least Linux won't, if the object is larger than 2 GB on a 64-bit system :)
-hpa
^ permalink raw reply
* Re: [PATCH] Ability to automaticaly push tags to remote repositories.
From: Petr Baudis @ 2006-06-02 20:58 UTC (permalink / raw)
To: Krzysiek Pawlik; +Cc: Git Mailing List
In-Reply-To: <442BD562.3030207@people.pl>
Dear diary, on Thu, Mar 30, 2006 at 02:56:02PM CEST, I got a letter
where Krzysiek Pawlik <krzysiek.pawlik@people.pl> said that...
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> - From `cg-push --long-help`:
>
> - -t TAG::
> Tells cg-push to also push the given tag. Note that in the
> future, cg-push should push tags automatically. Also note
> that even if you pass `cg-push` the '-t' arguments, your
> HEAD is still pushed as well in addition to the tags.
>
> One of possible ways of doing it is in attached patch. Comments,
> suggestions?
Well, this works properly only when you ever push to a single
repository, which many people don't. Besides, if you have two branches,
push branch A but tag a commit only on branch B, you will now be pushing
an invalid tag since the other end won't have the branch B and thus the
tagged commit.
A better way would be to use git-ls-remote --tags to get the list of
remote tags and compare that with the list of local tags, then push
those tags that tag commits on the branch we are pushing and the other
end does not have them.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply
* Re: Clean up sha1 file writing
From: Linus Torvalds @ 2006-06-02 21:17 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Matthias Lederhofer, Git Mailing List
In-Reply-To: <44808710.1080000@zytor.com>
On Fri, 2 Jun 2006, H. Peter Anvin wrote:
> Linus Torvalds wrote:
> >
> > Any POSIX-conformant OS/filesystem should always do a full write for a
> > regular file, unless a serious error happens.
> >
>
> Actually, at least Linux won't, if the object is larger than 2 GB on a 64-bit
> system :)
Yeah, true.
In the end, you should always have the loop. That way, you never have to
worry about what kind of file descriptor it is, what kind of filesystem
you're running on, and what the limits of ssize_t might be.
Linus
^ permalink raw reply
* Re: [PATCH] A Perforce importer for git.
From: Alex Riesen @ 2006-06-02 21:20 UTC (permalink / raw)
To: Sean; +Cc: git
In-Reply-To: <20060602094357.ee3d8407.seanlkml@sympatico.ca>
Sean, Fri, Jun 02, 2006 15:43:57 +0200:
> "Alex Riesen" <raa.lkml@gmail.com> wrote:
>
> > BTW, can I suggest to import the _currently_ synced state?
> >
>
> Note that it never syncs specifically to head, it explicitly asks for
> each revision along the branch and tt doesn't know anything about your
> working state, it can only import commits.
So did get that part right (I didn't actually tried your script, just
read the code).
> Are you looking for the ability to create a single git branch which has
Well, I'm not quite sure it's at all possible... Perforce has a
strange ways for doing history: it is kept for each file (as in CVS),
but you can bundle changes in many files into one "change".
Perforce also has no branches (in the GIT's meaning of the term).
These by Perforce are just server-side directories, without any
relevance to the source whatsoever (just copies).
> the history of the combined view of your stitched together client mappings
> rather than the independent branches held by the server?
I'm rather looking for a ability to manage a single branch where
import "sync" events appear as a merge of changes to the files
involved in the sync. I just haven't figured out yet how to "break" a
Perforce change into changes to single files and import that broken up
commit into git as a merge.
I hope that was clear enough... I think understanding how cvs/svn
imports work should help here - Perforce is actually nothing very
different from them.
^ permalink raw reply
* Re: [PATCH] ciabot: fix post-update hook description
From: Petr Baudis @ 2006-06-02 21:50 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git
In-Reply-To: <20060529000959.GA2061@diku.dk>
Thanks, all four patches applied. :)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply
* Re: http-fetch troubles
From: Junio C Hamano @ 2006-06-02 22:15 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: git, Linus Torvalds
In-Reply-To: <7vac8vbgqg.fsf_-_@assigned-by-dhcp.cox.net>
I think this fixes the http trouble with tree parser change in
the "next" branch.
-- >8 --
fetch.c: do not call process_tree() from process_tree().
This function reads a freshly fetched tree object, and schedules
the objects pointed by it for further fetching, so calling lookup-tree
and doing process_tree() recursively from there does not make
much sense. We need to use process() on it to make sure we
fetch it first.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/fetch.c b/fetch.c
index ec2d8c3..107504b 100644
--- a/fetch.c
+++ b/fetch.c
@@ -46,13 +46,20 @@ static int process_tree(struct tree *tre
desc.buf = tree->buffer;
desc.size = tree->size;
while (tree_entry(&desc, &entry)) {
+ struct object *obj = NULL;
+
if (S_ISDIR(entry.mode)) {
struct tree *tree = lookup_tree(entry.sha1);
- process_tree(tree);
- } else {
+ if (tree)
+ obj = &tree->object;
+ }
+ else {
struct blob *blob = lookup_blob(entry.sha1);
- process(&blob->object);
+ if (blob)
+ obj = &blob->object;
}
+ if (!obj || process(obj))
+ return -1;
}
free(tree->buffer);
tree->buffer = NULL;
^ permalink raw reply related
* Re: http-fetch troubles
From: Linus Torvalds @ 2006-06-02 22:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nick Hengeveld, git
In-Reply-To: <7vmzcv9pba.fsf@assigned-by-dhcp.cox.net>
On Fri, 2 Jun 2006, Junio C Hamano wrote:
>
> I think this fixes the http trouble with tree parser change in
> the "next" branch.
Ahh, my bad. That happened as a bug in my original understanding of that
fetch.c thing.
Your fix looks obviously fine,
Linus
^ permalink raw reply
* Re: Importing Mozilla CVS into git
From: Jon Smirl @ 2006-06-03 0:09 UTC (permalink / raw)
To: Keith Packard; +Cc: git
In-Reply-To: <1149220518.5521.43.camel@neko.keithp.com>
If I parsecvs this pair it fails:
/home/jonsmirl/mozilla/mozilla/dom/src/base/nsFocusController.h,v
/home/jonsmirl/mozilla/mozilla/dom/src/base/nsGlobalWindow.cpp,v
[jonsmirl@jonsmirl foo]$ ../parsecvs <sm2
defaulting to local storage area
Load: nsGlobalWindow.cpp,v ....................* 2 of 2
Warning: branch point MOZILLA_1_0_BRANCH -> master matched by date
fatal: Not a valid object name (null)
git-read-tree '(null)' failed
[jonsmirl@jonsmirl foo]$
But parsecvs works on each of them individually.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: http-fetch troubles
From: Becky Bruce @ 2006-06-03 1:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Nick Hengeveld
In-Reply-To: <7vac8vbgqg.fsf_-_@assigned-by-dhcp.cox.net>
Woohoo! The stuff you moved to master (which is what I was building
from, not "next", as Nick pointed out) has fixed the git-http-fetch
segfault problem I was seeing.
Thanks!
-Becky
On Jun 2, 2006, at 12:38 PM, Junio C Hamano wrote:
> Junio C Hamano <junkio@cox.net> writes:
>
>> Nick Hengeveld <nickh@reactrix.com> writes:
>>
>>> - "git push" seems to pass --thin by default to http-push, which
>>> subsequently barfs because that's not a valid http-push option.
>>> Should it be? Should it be silently ignored? Should git-push not
>>> default to --thin when pushing with HTTP transport?
>>
>> The way I understand http-push works is that it does not use
>> packed transfer, so I presume even if we give --thin as a hint
>> it cannot even take advantage of it. Probably we should stop
>> passing --thin to http transport (git native one uses it as a
>> cue that it can generate baseless deltas in the resulting pack).
>>
>>> - when I clone, http-fetch outputs a whole bunch of
>>> "error: Could not read ..." messages - is that expected?
>>
>> The clone over http seems to be severely broken in "next" right
>> now. The one in "master" seems to be OK. bisecting suggests
>> the breakage is coming from the tree parser rewrite.
>>
>> bisect points at 136f2e548a34f1f504b0f062f87ddf33e8d6e83b.
>
> I've pushed out Nick's http-fetch fixes in "master" to see if it
> fixes problems for people. Right now the one in "next" branch
> seems to be having unrelated problems coming from another topic
> which I haven't started tracking down yet.
>
>
^ permalink raw reply
* Re: http-fetch troubles
From: Junio C Hamano @ 2006-06-03 1:24 UTC (permalink / raw)
To: Becky Bruce; +Cc: git, Nick Hengeveld
In-Reply-To: <1C422237-D48C-4A30-9BDD-5C165222873D@freescale.com>
Becky Bruce <Becky.Bruce@freescale.com> writes:
> Woohoo! The stuff you moved to master (which is what I was building
> from, not "next", as Nick pointed out) has fixed the git-http-fetch
> segfault problem I was seeing.
>
> Thanks!
Thanks Nick for fixing, and Becky for confirming.
... and I take all the credit ;-).
I haven't pushed it out yet, but I believe "next" is also good
to go.
^ permalink raw reply
* Re: http-fetch troubles
From: Linus Torvalds @ 2006-06-03 2:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Becky Bruce, git, Nick Hengeveld
In-Reply-To: <7virnj9gkf.fsf@assigned-by-dhcp.cox.net>
On Fri, 2 Jun 2006, Junio C Hamano wrote:
>
> ... and I take all the credit ;-).
I always knew you'd work out as a maintainer.
Linus
^ permalink raw reply
* Re: Importing Mozilla CVS into git
From: Jon Smirl @ 2006-06-03 4:28 UTC (permalink / raw)
Cc: git
In-Reply-To: <9e4733910606011755n29a149f2m1409c5a23888f1c5@mail.gmail.com>
On 6/1/06, Jon Smirl <jonsmirl@gmail.com> wrote:
> With the attached patch you can parse the entire Mozilla tree. The
> tree has over 100,000 files in it and about 300 branches.
I was a little low with these counts, more like 110,000 files and some
parts of the tree have 1,000 branches. Total tree size is 3GB.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* A test failing with python 2.2 -- ok?
From: Geoff Russell @ 2006-06-03 6:48 UTC (permalink / raw)
To: git
Hi,
I'm not sure how far back you are supporting, but I'm running a python
2.2 machine
and make test fails with a missing python module. Whatever criss-cross merges
are, I don't need them, but figured if you were intending to support older
environments, then you may be interested.
Cheers,
Geoff Russell
$ git --version
git version 1.3.3.g61ef-dirty
$ make test
*** t6021-merge-criss-cross.sh ***
....
Traceback (most recent call last):
File "/usr/local/LINUX/GIT/git/t/../git-merge-recursive", line 10, in ?
from heapq import heappush, heappop
ImportError: No module named heapq
-------------------------------------------------------
^ permalink raw reply
* Re: A test failing with python 2.2 -- ok?
From: Sean @ 2006-06-03 7:12 UTC (permalink / raw)
To: geoff; +Cc: geoffrey.russell, git
In-Reply-To: <93c3eada0606022348l3c39f966u781327b14b0bc3d5@mail.gmail.com>
On Sat, 3 Jun 2006 16:18:32 +0930
"Geoff Russell" <geoffrey.russell@gmail.com> wrote:
> I'm not sure how far back you are supporting, but I'm running a python
> 2.2 machine
> and make test fails with a missing python module. Whatever criss-cross merges
> are, I don't need them, but figured if you were intending to support older
> environments, then you may be interested.
Hi Geoff,
You need Python version 2.3 or newer; from the INSTALL file:
- "python" 2.3 or more recent; if you have 2.3, you may need
to build with "make WITH_OWN_SUBPROCESS_PY=YesPlease".
Sean
^ permalink raw reply
* Re: http-fetch troubles
From: Junio C Hamano @ 2006-06-03 7:58 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Becky Bruce, git, Nick Hengeveld
In-Reply-To: <Pine.LNX.4.64.0606021925350.5498@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Fri, 2 Jun 2006, Junio C Hamano wrote:
>>
>> ... and I take all the credit ;-).
>
> I always knew you'd work out as a maintainer.
>
> Linus
Thanks for the compliment. I realize that is your way to take
the credit ;-).
^ permalink raw reply
* Re: git reset --hard not removing some files
From: Junio C Hamano @ 2006-06-03 8:48 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Martin Waitz
In-Reply-To: <7vhd33d2q2.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> I would agree in the reproduction recipe Martin gave there is no
> problem but feature, but at the same time I suspect the recent
> "reset --hard simplification" has introduced a true regression.
> ...
> $ git ls-files -u
> 100644 b1b716105590454bfc4c0247f193a04088f39c7f 1 file1
> 100644 2e0996000b7e9019eabcad29391bf0f5c7702f0b 3 file1
> $ ls
> file0 file1 file2
> $ git reset --hard
> $ ls
> file0 file1 file2
>
> We used to remove file1 from the working tree in this case. One
> of the most important reason to use "git reset --hard" is to
> recover from a conflicted, failed merge.
I think this patch fixes the regression. Comments?
-- >8 --
read-tree --reset: update working tree file for conflicted paths.
The earlier "git reset --hard" simplification stopped removing
leftover working tree files from a failed automerge, when
switching back to the HEAD version that does not have the
paths.
This patch, instead of removing the unmerged paths from the
index, drops them down to stage#0 but marks them with mode=0
(the same "to be deleted" marker we internally use for paths
deleted by the merge). one_way_merge() function and the
functions it calls already know what to do with them -- if the
tree we are reading has the path the working tree file is
overwritten, and if it doesn't the working tree file is
removed.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
builtin-read-tree.c | 19 +++++++++++++++----
1 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/builtin-read-tree.c b/builtin-read-tree.c
index 716f792..71edaf6 100644
--- a/builtin-read-tree.c
+++ b/builtin-read-tree.c
@@ -753,6 +753,8 @@ static int read_cache_unmerged(void)
{
int i, deleted;
struct cache_entry **dst;
+ int unmerged = 0;
+ struct cache_entry *last = NULL;
read_cache();
dst = active_cache;
@@ -760,16 +762,22 @@ static int read_cache_unmerged(void)
for (i = 0; i < active_nr; i++) {
struct cache_entry *ce = active_cache[i];
if (ce_stage(ce)) {
- deleted++;
+ unmerged++;
+ if (last && !strcmp(ce->name, last->name)) {
+ deleted++;
+ continue;
+ }
invalidate_ce_path(ce);
- continue;
+ last = ce;
+ ce->ce_mode = 0;
+ ce->ce_flags &= ~htons(CE_STAGEMASK);
}
if (deleted)
*dst = ce;
dst++;
}
active_nr -= deleted;
- return deleted;
+ return unmerged;
}
static void prime_cache_tree_rec(struct cache_tree *it, struct tree *tree)
@@ -850,7 +858,10 @@ int cmd_read_tree(int argc, const char *
continue;
}
- /* This differs from "-m" in that we'll silently ignore unmerged entries */
+ /* This differs from "-m" in that we'll silently ignore
+ * unmerged entries and overwrite working tree files that
+ * correspond to them.
+ */
if (!strcmp(arg, "--reset")) {
if (stage || merge)
usage(read_tree_usage);
^ permalink raw reply related
* Re: A test failing with python 2.2 -- ok?
From: Johannes Schindelin @ 2006-06-03 9:13 UTC (permalink / raw)
To: geoff; +Cc: git
In-Reply-To: <93c3eada0606022348l3c39f966u781327b14b0bc3d5@mail.gmail.com>
Hi,
On Sat, 3 Jun 2006, Geoff Russell wrote:
> I'm not sure how far back you are supporting, but I'm running a python
> 2.2 machine and make test fails with a missing python module. Whatever
> criss-cross merges are, I don't need them, but figured if you were
> intending to support older environments, then you may be interested.
Python 2.2 is too old, even if you import some missing modules. But you
can always set "NO_PYTHON=YesPlease" in config.mak.
Hth,
Dscho
^ permalink raw reply
* Gitk feature - show nearby tags
From: Paul Mackerras @ 2006-06-03 9:38 UTC (permalink / raw)
To: git
I just pushed out an update to the "new" branch of the gitk.git
repository, which adds a feature that I have often wished for: it will
now show the nearest preceding and following tags when you select a
commit. This is very useful if you need to identify which release was
the first to incorporate a particular patch, or if you need to know
which release a patch might have been based on.
(Specifically, it shows the tags for all tagged descendents that are
not descendents of another tagged descendent of the selected commit,
and the tags for all tagged ancestors that are not ancestors of
another tagged ancestor of the selected commit.)
Since there is a one-off computation that gitk does to work this out,
which takes an appreciable time (about 1.5 seconds on my G5 on the
kernel repository), I have made gitk do the computation in the
background, and update the diff/file display window when it's done.
There is also a checkbox in the preferences window where you can turn
it off if you don't want gitk to do this computation.
Comments/suggestions welcome.
Paul.
^ permalink raw reply
* Re: gitk on Windows: layout problem
From: Paul Mackerras @ 2006-06-03 9:43 UTC (permalink / raw)
To: git; +Cc: git
In-Reply-To: <20060530185441.GA10985@nospam.com>
Rutger Nijlunsing writes:
> Is this a known problem? gitk-du-jour on Windows starts up with an
> unusable layout. Screenshot attached.
Is that using Tk with the cygwin X server, or the native Windows Tk
port?
Paul.
^ permalink raw reply
* Re: Gitk feature - show nearby tags
From: Junio C Hamano @ 2006-06-03 10:29 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git, Jonas Fonseca
In-Reply-To: <17537.22675.678700.118093@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> writes:
> I just pushed out an update to the "new" branch of the gitk.git
> repository, which adds a feature that I have often wished for: it will
> now show the nearest preceding and following tags when you select a
> commit. This is very useful if you need to identify which release was
> the first to incorporate a particular patch, or if you need to know
> which release a patch might have been based on.
Another thing that would equally be useful is to show which
branch a particular commit is on, so for example I can pick one
commit while doing "gitk next" to view the next branch and see
which topic it belongs to, and "gitk this-topic" to see which
commits on that topic, if any, are not yet in the "next" branch.
For a graphical interface like gitk it may not be such a big
deal (you can always follow the line), but an interface like tig
that shows commits in a linear fashion it would make a big
difference in usability.
BTW, what's the maintenance/rewind policy on the "new" branch of
gitk.git? If you are never going to rewind it, I could pull it
in "next" (and keep pulling your "master" in my "master") for
wider exposure if you like.
^ permalink raw reply
* Re: Gitk feature - show nearby tags
From: Marco Costalba @ 2006-06-03 11:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Paul Mackerras, git, Jonas Fonseca
In-Reply-To: <7vslmm8rcd.fsf@assigned-by-dhcp.cox.net>
On 6/3/06, Junio C Hamano <junkio@cox.net> wrote:
> Paul Mackerras <paulus@samba.org> writes:
>
> > I just pushed out an update to the "new" branch of the gitk.git
> > repository, which adds a feature that I have often wished for: it will
> > now show the nearest preceding and following tags when you select a
> > commit. This is very useful if you need to identify which release was
> > the first to incorporate a particular patch, or if you need to know
> > which release a patch might have been based on.
>
> Another thing that would equally be useful is to show which
> branch a particular commit is on, so for example I can pick one
> commit while doing "gitk next" to view the next branch and see
> which topic it belongs to, and "gitk this-topic" to see which
> commits on that topic, if any, are not yet in the "next" branch.
>
If I have understood correctly the patch runs a 'git rev-list --all
--topo-order --parents'
and then does a tree walking.
I am wandering if there exist any native git way to found the previous tag.
As example given a selected revision with id <sha> is it possible to
do something like this to fond the ancestor?
1) get the tag list with git-peek-remote or something similar if tags
are not already loaded
2) given the tagList vector with n elements run
git-rev-list --topo-order <sha> ^tagList[0] ^tagList[1] ....
^tagList[n-1]
3) take the last sha spit out by git-rev-list, be it <lastSha>.
4) Previous nearest tag is the parent of lastSha
I've missed something?
Marco
^ 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