* Re: [PATCH 25/27] Documentation: Spelling fixes
From: Ben Clifford @ 2006-06-04 10:42 UTC (permalink / raw)
To: Horst.H.von.Brand; +Cc: git, Junio C Hamano, Horst H. von Brand
In-Reply-To: <1149366517875-git-send-email->
Horst,
> The default post-update hook, when enabled, runs
> `git-update-server-info` to keep the information used by dumb
> -transports (eg, http) up-to-date. If you are publishing
> +transports (e.g.,, http) up-to-date. If you are publishing
> a git repository that is accessible via http, you should
> probably enable this hook.
just one extra , there
(btw private mail to you keeps bouncing here with various declarations
that you do not exist)
--
^ permalink raw reply
* Re: Gitk feature - show nearby tags
From: Junio C Hamano @ 2006-06-04 10:42 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <e5bfff550606040333h1180bbep88fa90ea9928d062@mail.gmail.com>
"Marco Costalba" <mcostalba@gmail.com> writes:
>> Sorry, in the example time flows from left to right. If you
>> exclude g then you are excluding everything that is reachable
>> from g so you would not see "f".
>>
> From today git:
>
> tag list is:
>
> v1.3.3 1b9bc5a7b7434d771726011613a00cb202bd9f44
> v1.3.2 7abd7117ec57b8c3c2a469db62c7811fdac5c655
> v1.3.1 7d09fbe4ab7f080a8f8f5dcef7e0f3edf5e26019
> v1.3.0 4baff50551545e2b6825973ec37bcaf03edb95fe
>
> selected sha is ccb365047a1081455b767867f0887e7b4334f9d8
> (Allow "git repack" users to specify repacking window/depth)
>
> $ git-rev-list --topo-order ccb365047a1081455b767867f0887e7b4334f9d8
> ^1b9bc5a7b7434d771726011613a00cb202bd9f44
> ^7abd7117ec57b8c3c2a469db62c7811fdac5c655
> ^7d09fbe4ab7f080a8f8f5dcef7e0f3edf5e26019
> ^4baff50551545e2b6825973ec37bcaf03edb95fe
>
> ccb365047a1081455b767867f0887e7b4334f9d8
> ...
> cd2bdc5309461034e5cc58e1d3e87535ed9e093b
>
> Parent of cd2bdc5309461034e5cc58e1d3e87535ed9e093b is
>
> 4baff50551545e2b6825973ec37bcaf03edb95fe
>
> aka tag v1.3.0
>
> Am I missing something?
No, just that I am not getting what you are trying to prove
here. The tags are all older than your chosen commit.
$ git-rev-list --topo-order ^v1.3.0 ^v1.3.1 ^v1.3.2 ^v1.3.3 e923eff
would show nothing -- and you propose to find out that commit is
between v1.3.1 and v1.3.2 by using the information that the
command gives an empty result but I do not know how?
$ git show-branch v1.3.1 e923eff v1.3.2
does show it is between these two, but that is because it avoids
the 2^N permutations by using 1-bit per revision that it wants to
check the reachability across.
^ permalink raw reply
* Re: Gitk feature - show nearby tags
From: Marco Costalba @ 2006-06-04 10:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <e5bfff550606040333h1180bbep88fa90ea9928d062@mail.gmail.com>
On 6/4/06, Marco Costalba <mcostalba@gmail.com> wrote:
> On 6/4/06, Junio C Hamano <junkio@cox.net> wrote:
> > "Marco Costalba" <mcostalba@gmail.com> writes:
> >
> > > In a less corner case, just to better explaing my idea, consider this:
> > >
> > > a---b---d---e---f---g---h
> > > t1 \ / t3
> > > ---c
> > > t2
> > >
> > > Where our sha1 is still "e", in this case
> > >
> > > git-rev-list --topo-order <e> ^a ^c ^g
> > >
> > > gives, as last revision in output list, "f"
> > > Then parentOf(<f>) is <g> and our looked for tag is t3
> >
> > Sorry, in the example time flows from left to right. If you
> > exclude g then you are excluding everything that is reachable
> > from g so you would not see "f".
To better explain what I mean, that's the algorithm :
cmd = "git-rev-list --topo-order --parents " + sha;
for (uint i = 0; i < tagList.count(); i++)
cmd.append(" ^" + tagList[i]);
output = run(cmd);
if (output.isEmpty()) {
parent = parentOf(sha);
return (parent && parent->isTag()) ? parent->tag() : NO_TAG;
}
lastSha = getLastLine(output);
parent = parentOf(lastSha);
return (parent && parent->isTag()) ? parent->tag() : NO_TAG;
^ permalink raw reply
* Re: Gitk feature - show nearby tags
From: Marco Costalba @ 2006-06-04 10:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbqt9ck05.fsf@assigned-by-dhcp.cox.net>
On 6/4/06, Junio C Hamano <junkio@cox.net> wrote:
> "Marco Costalba" <mcostalba@gmail.com> writes:
>
> > In a less corner case, just to better explaing my idea, consider this:
> >
> > a---b---d---e---f---g---h
> > t1 \ / t3
> > ---c
> > t2
> >
> > Where our sha1 is still "e", in this case
> >
> > git-rev-list --topo-order <e> ^a ^c ^g
> >
> > gives, as last revision in output list, "f"
> > Then parentOf(<f>) is <g> and our looked for tag is t3
>
> Sorry, in the example time flows from left to right. If you
> exclude g then you are excluding everything that is reachable
> from g so you would not see "f".
>
From today git:
tag list is:
v1.3.3 1b9bc5a7b7434d771726011613a00cb202bd9f44
v1.3.2 7abd7117ec57b8c3c2a469db62c7811fdac5c655
v1.3.1 7d09fbe4ab7f080a8f8f5dcef7e0f3edf5e26019
v1.3.0 4baff50551545e2b6825973ec37bcaf03edb95fe
selected sha is ccb365047a1081455b767867f0887e7b4334f9d8
(Allow "git repack" users to specify repacking window/depth)
$ git-rev-list --topo-order ccb365047a1081455b767867f0887e7b4334f9d8
^1b9bc5a7b7434d771726011613a00cb202bd9f44
^7abd7117ec57b8c3c2a469db62c7811fdac5c655
^7d09fbe4ab7f080a8f8f5dcef7e0f3edf5e26019
^4baff50551545e2b6825973ec37bcaf03edb95fe
ccb365047a1081455b767867f0887e7b4334f9d8
85e6326cc3e7c272566c60a39741f84391830d49
4262c1b0c38613a8c5ae729bd4d3f18f0df3ec44
24735cfc500feb2a8dba9f140080ab3476363d28
caef71a5354ca162cc5a6914a7a643efbc9ae28a
34e98ea56414adc5a582e6368e8ec9c109dbee48
3a624b346db02a07b0317743b362d1a15c6c3c18
965f803c323bb72a9dedbbc8f7ba00bbadb6cf58
b073f26b256cded6252bafd34982eb6f69d2a4b6
a4d34e2db5565e6b75f79f9d3938aa9151e72e44
eab144ac49c18d981261c2d0ba964d6380d9f1da
9153983310a169a340bd1023dccafd80b70b05bc
db89665fbf86d4e0166b2f252a939ed8bf6782fe
78fff6ebbafe2d23464a2b059104954bfe8732c7
cb8f64b4e3f263c113b7a2f156af74b810e969ff
d4ed9793fd981ea5a35ebaa8e337446bb29f6d55
b2934926dd7455de61577c1dfdf4c12d224e7ae0
ba1d45051e050cbcf68ccccacea86a4b6ecde731
5b84f4d87a1bd58c7540e9ea82ee3673ecddbad5
7594c4b2d7cc81f806453402aefe1bf71ae6dd53
6b9c58f4669b3832ed2830f0cb1a307ea6bc6063
8c1f0b44c59530dea8007a9f5b69d0fac6aea3b1
8e8f998739db6526fe890fabc88c866759bc2ac3
cd2bdc5309461034e5cc58e1d3e87535ed9e093b
Parent of cd2bdc5309461034e5cc58e1d3e87535ed9e093b is
4baff50551545e2b6825973ec37bcaf03edb95fe
aka tag v1.3.0
Am I missing something?
^ permalink raw reply
* Re: Gitk feature - show nearby tags
From: Junio C Hamano @ 2006-06-04 10:10 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <7vbqt9ck05.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> "Marco Costalba" <mcostalba@gmail.com> writes:
>
>> In a less corner case, just to better explaing my idea, consider this:
>>
>> a---b---d---e---f---g---h
>> t1 \ / t3
>> ---c
>> t2
>>
>> Where our sha1 is still "e", in this case
>>
>> git-rev-list --topo-order <e> ^a ^c ^g
>>
>> gives, as last revision in output list, "f"
>> Then parentOf(<f>) is <g> and our looked for tag is t3
>
> Sorry, in the example time flows from left to right. If you
> exclude g then you are excluding everything that is reachable
> from g so you would not see "f".
>
> Even if your example is different from what I gave (which had
> "a" as the root commit) and h is the root commit, your ^a and ^c
> would exclude everything that is reachable from either a or c,
> so you would get an empty set. So your "last revision in
> output" would not be "f" either.
BTW, that was exactly what I meant by "2^N permutations of
tags". If you exclude all tags that are older than "e" then
your algorithm would work beautifully, but the algorithm is
about finding out which tags are older than "e" to begin with,
so...
^ permalink raw reply
* Re: Gitk feature - show nearby tags
From: Junio C Hamano @ 2006-06-04 10:06 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <e5bfff550606040254n1449b62ta70c209ad8e1a0c@mail.gmail.com>
"Marco Costalba" <mcostalba@gmail.com> writes:
> In a less corner case, just to better explaing my idea, consider this:
>
> a---b---d---e---f---g---h
> t1 \ / t3
> ---c
> t2
>
> Where our sha1 is still "e", in this case
>
> git-rev-list --topo-order <e> ^a ^c ^g
>
> gives, as last revision in output list, "f"
> Then parentOf(<f>) is <g> and our looked for tag is t3
Sorry, in the example time flows from left to right. If you
exclude g then you are excluding everything that is reachable
from g so you would not see "f".
Even if your example is different from what I gave (which had
"a" as the root commit) and h is the root commit, your ^a and ^c
would exclude everything that is reachable from either a or c,
so you would get an empty set. So your "last revision in
output" would not be "f" either.
^ permalink raw reply
* Re: Gitk feature - show nearby tags
From: Marco Costalba @ 2006-06-04 9:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Paul Mackerras, git, Jonas Fonseca
In-Reply-To: <7vodx9cm3g.fsf@assigned-by-dhcp.cox.net>
On 6/4/06, Junio C Hamano <junkio@cox.net> wrote:
> "Marco Costalba" <mcostalba@gmail.com> writes:
>
> > 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
>
> Sorry, I do not understand what you are doing here at all.
> Suppose you have this simple history.
>
> (root)
>
> a---b---d---e---f---g
> t1 \ / t3
> ---c
> t2
>
> and <sha1> in (2) is "e". When tagList = (t1, t2, t3), the
> above rev-list would return empty.
This is enough!
Empty list is an useful and enough information.
It means:
1) Parent of current revision ("e" in our case) is a tag, indeed our seeked tag.
2) If previous point is not true then there are no previous tags.
In a less corner case, just to better explaing my idea, consider this:
a---b---d---e---f---g---h
t1 \ / t3
---c
t2
Where our sha1 is still "e", in this case
git-rev-list --topo-order <e> ^a ^c ^g
gives, as last revision in output list, "f"
Then parentOf(<f>) is <g> and our looked for tag is t3
Marco
^ permalink raw reply
* Re: Gitk feature - show nearby tags
From: Marco Costalba @ 2006-06-04 9:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Paul Mackerras, git, Jonas Fonseca
In-Reply-To: <7vk67xclx7.fsf@assigned-by-dhcp.cox.net>
On 6/4/06, Junio C Hamano <junkio@cox.net> wrote:
> "Marco Costalba" <mcostalba@gmail.com> writes:
>
> > What you suggest we need it's a kind of history of tags.
>
> I do not understand what you mean by "history of tags". Are you
> talking about "tag v1.0.0 was pointing at X commit yesterday but
> now today it points at Y commit"?
>
> > And, according to Paul suggestions, not only tags, but merge revisions
> > between tags.
> >
> > A more general and IMHO very powerful tool could be something like
> >
> > git-rev-list --top-order --parents --selected-only HEAD -- <sha 1>
> > <sha 2> ..... <sha n>
> >
> > Where git rev list gives the history, with modified parents, of the
> > given revisions _only_ plus the merging revisions among them.
>
> You completely lost me here. The '--' markers are to mean "from
> here on the parameters are not revisions but are path limiters",
> so you are doing something else. What are these <sha1#1>, <sha1#2>,...
> in this? Are they revisions (i.e. commit object names)?
Yes they are.
Insted of path limiters I meant revisions limiters.
Given a revision history like
a
b--|
| f
| g
c
d
e
git-rev-list --top-order --parents --selected-only HEAD -- <a> <g> <d>
Should output something like
a
b--|
| g
d
Of course with modified parent information as does git-rev-list
--parents -- foo.c
^ permalink raw reply
* Re: [ANNOUNCE qgit-1.3]
From: Marco Costalba @ 2006-06-04 9:32 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, linux-kernel
In-Reply-To: <e5u8fk$ju6$1@sea.gmane.org>
On 6/4/06, Jakub Narebski <jnareb@gmail.com> wrote:
> Marco Costalba wrote:
>
> > This is qgit-1.3
> [...]
> > NEW IN THIS RELEASE
> >
> > Main focus of this release is usability.
> >
> > The big feature is the use of tabs instead of independent windows.
> >
> > This change alone could be enough for a release. It's a big rewrite of UI
> > code to let browsing revisions and patches quicker and easier.
>
> Of course that is advantage _only_ if the tabs are independend, and one
> (usually) doesn't need to view them simultaneously, e.g. side by side.
>
Actually they are.
One for revisions list, one for patches and one for file content.
File content tab is indipendent from previous two (of course it can be
synced on request).
> Just my 3 eurocents ;-)
Well, at today exchange rate should be 'my 2.3 eurocents' :-)
Marco
^ permalink raw reply
* Re: git reset --hard not removing some files
From: Junio C Hamano @ 2006-06-04 9:31 UTC (permalink / raw)
To: Martin Waitz; +Cc: git
In-Reply-To: <20060604091601.GN14325@admingilde.org>
Martin Waitz <tali@admingilde.org> writes:
> hoi :)
>
> On Fri, Jun 02, 2006 at 07:57:57AM -0700, Junio C Hamano wrote:
>> 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.
>
> This may have been the bug that bit me.
> Thanks for finding it although I was not able to reproduce it myself!
I found this somewhat the hard way myself. I have:
[pull]
twohead = resolve
in my .git/config -- IOW, I usually do not use recursive
strategy myself. When a merge with resolve strategy fails (and
with recent trend to busyboxify git commands, many merges
between my topics and "next" and/or "master" do), I relied on
"reset --hard" followed by the same merge of the topic using
"pull -s recursive" to recover things, but it didn't. When
pulling a branch with builtin-*.c names into another branch with
older names, regressed "reset --hard" left builtin-*.c files
behind, and then the next merge attempt complained by saying my
untracked working tree files would be overwritten X-<.
^ permalink raw reply
* Re: Gitk feature - show nearby tags
From: Junio C Hamano @ 2006-06-04 9:25 UTC (permalink / raw)
To: Marco Costalba; +Cc: Paul Mackerras, Junio C Hamano, git, Jonas Fonseca
In-Reply-To: <e5bfff550606040008m4dbf02bdga4f4e6bc2d2fe9d@mail.gmail.com>
"Marco Costalba" <mcostalba@gmail.com> writes:
> What you suggest we need it's a kind of history of tags.
I do not understand what you mean by "history of tags". Are you
talking about "tag v1.0.0 was pointing at X commit yesterday but
now today it points at Y commit"?
> And, according to Paul suggestions, not only tags, but merge revisions
> between tags.
>
> A more general and IMHO very powerful tool could be something like
>
> git-rev-list --top-order --parents --selected-only HEAD -- <sha 1>
> <sha 2> ..... <sha n>
>
> Where git rev list gives the history, with modified parents, of the
> given revisions _only_ plus the merging revisions among them.
You completely lost me here. The '--' markers are to mean "from
here on the parameters are not revisions but are path limiters",
so you are doing something else. What are these <sha1#1>, <sha1#2>,...
in this? Are they revisions (i.e. commit object names)?
^ permalink raw reply
* Re: Gitk feature - show nearby tags
From: Junio C Hamano @ 2006-06-04 9:21 UTC (permalink / raw)
To: Marco Costalba; +Cc: Junio C Hamano, Paul Mackerras, git, Jonas Fonseca
In-Reply-To: <e5bfff550606030416s2ef6182crbde1395dd29e5b94@mail.gmail.com>
"Marco Costalba" <mcostalba@gmail.com> writes:
> 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
Sorry, I do not understand what you are doing here at all.
Suppose you have this simple history.
(root)
a---b---d---e---f---g
t1 \ / t3
---c
t2
and <sha1> in (2) is "e". When tagList = (t1, t2, t3), the
above rev-list would return empty. For tagList = (t1, t2), the
rev-list would return "e", and then "d". Parent of "d" are "b"
and "c", and c is tagged but b is not. So if you are willing to
try 2^N permutations of what tagList to use, then the above
sequence, with a bit of tweak to step (4) to see which parents
are tagged, would yield the closest tag in the past of "e", but
is that what you are suggesting?
^ permalink raw reply
* Re: [ANNOUNCE qgit-1.3]
From: Jakub Narebski @ 2006-06-04 9:17 UTC (permalink / raw)
To: git; +Cc: linux-kernel
In-Reply-To: <e5bfff550606040155v14565312na26f8c866f0fc32d@mail.gmail.com>
Marco Costalba wrote:
> This is qgit-1.3
[...]
> NEW IN THIS RELEASE
>
> Main focus of this release is usability.
>
> The big feature is the use of tabs instead of independent windows.
>
> This change alone could be enough for a release. It's a big rewrite of UI
> code to let browsing revisions and patches quicker and easier.
Of course that is advantage _only_ if the tabs are independend, and one
(usually) doesn't need to view them simultaneously, e.g. side by side.
Just my 3 eurocents ;-)
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: git reset --hard not removing some files
From: Martin Waitz @ 2006-06-04 9:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7vhd33d2q2.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 411 bytes --]
hoi :)
On Fri, Jun 02, 2006 at 07:57:57AM -0700, Junio C Hamano wrote:
> 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.
This may have been the bug that bit me.
Thanks for finding it although I was not able to reproduce it myself!
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [ANNOUNCE qgit-1.3]
From: Marco Costalba @ 2006-06-04 8:55 UTC (permalink / raw)
To: git, linux-kernel
This is qgit-1.3
With qgit you will be able to browse revisions history, view patch content
and changed files, graphically following different development branches.
FEATURES
- View revisions, diffs, files history, files annotation, archive tree.
- Commit changes visually cherry picking modified files.
- Apply or format patch series from selected commits, drag and
drop commits between two instances of qgit.
- qgit implements a GUI for the most common StGIT commands like push/pop
and apply/format patches. You can also create new patches or refresh
current top one using the same semantics of git commit, i.e. cherry
picking single modified files.
NEW IN THIS RELEASE
Main focus of this release is usability.
The big feature is the use of tabs instead of independent windows.
This change alone could be enough for a release. It's a big rewrite of UI
code to let browsing revisions and patches quicker and easier.
An whole set of key and mouse bindings has been introduced to support tab
navigation, see handbook (F1) for details.
Also changes in annotation/file viewer and StGIT integration.
Please note that you will need git 1.3.0 or newer.
DOWNLOAD
Tarball is
http://prdownloads.sourceforge.net/qgit/qgit-1.3.tar.bz2?download
Git archive is
git://git.kernel.org/pub/scm/qgit/qgit.git
See http://digilander.libero.it/mcostalba/ for detailed download information.
INSTALLATION
git 1.3.0 is required.
To install from tarball:
./configure
make
make install
To install from git archive:
autoreconf -i
./configure
make
make install
Or check the shipped README for detailed information.
CHANGELOG
from 1.3rc1 to 1.3
- added another powerful key binding to switch pages: <Alt+wheel>
- add refresh button to main toolbar
- disable back and forward buttons when not in a git archive
- patch viewer should not parse HTML
- strip debug info when installing qgit
- move 'Settings...' at the end of Edit menu
- fix code range filtering in case of multi indipendent branches
- actually support embedded Qt, make configuration code more robust
(Pavel Roskin)
- always select at first revision after opening a repository
from 1.2 to 1.3rc1
- convert UI to use tabs instead of independent windows
- use key bindings to quickly change view
- use 's' key to quickly hide/unhide secondary panes in current view
- use a standard 'find text' (CTRL+F) dialog across views
- add support for filter a given substring or regexp through patches content
- highlight matched filter patterns in diff viewer
- add up/down one revision key binding
- double clicking on file list now shows the patch
- improve file content loading time
- add support for hide/unhide annotation in file viewer
- fix 'format patch series' broken in multi revision case
- fix search for StGIT patches only under current stg branch directory
- fix don't be confused by out-of-date parent IDs of unapplied patches
(Pavel Roskin)
- fix show ref names in pop-up menu also for applied StGIT patches
- fix unable to push and pop patches if "check working dir" is enabled
- add support for finding Qt on SuSE-9.2 for x86_64 (Pavel Roskin)
For a complete changelog see shipped ChangeLog file or git repository
revision's history
Marco
^ permalink raw reply
* Re: Gitk feature - show nearby tags
From: Marco Costalba @ 2006-06-04 7:08 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Junio C Hamano, git, Jonas Fonseca
In-Reply-To: <17538.16015.53244.876090@cargo.ozlabs.ibm.com>
On 6/4/06, Paul Mackerras <paulus@samba.org> wrote:
> Marco Costalba writes:
>
> > If I have understood correctly the patch runs a 'git rev-list --all
> > --topo-order --parents'
> > and then does a tree walking.
>
> Yes, that's right. It means that gitk can show the nearest tags even
> if they aren't included in the current view.
>
> > I am wandering if there exist any native git way to found the previous tag.
>
> I don't know of any. Doing the tree walking in Tcl turned out to be
> not too much of an overhead, though; it does the whole kernel
> repository in 1.5 seconds on my G5.
>
> > 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?
>
> I'm not sure exactly what that would do, but gitk can show more than
> one tag (the term "nearest tag" is only a shorthand approximation for
> what it does). For example, if you have two tagged commits where
> neither is an ancestor of the other, and do a merge of the two, gitk
> will show both tags when you select the merge.
What you suggest we need it's a kind of history of tags.
Currently we can run
git-rev-list --top-order --parents HEAD -- foo.c
and we get an history of file foo.c *with modified parents*
Junio, could be possible have something like
git-rev-list --top-order --parents --tags
with the history of tags ?
And, according to Paul suggestions, not only tags, but merge revisions
between tags.
A more general and IMHO very powerful tool could be something like
git-rev-list --top-order --parents --selected-only HEAD -- <sha 1>
<sha 2> ..... <sha n>
Where git rev list gives the history, with modified parents, of the
given revisions _only_ plus the merging revisions among them.
This could be used for tags (got from git-peek-remote), for branches
and in general for a given set of interesting revisions.
Once we have the history of tags, perhaps requested once at startup,
we can get the previous tags of a given revision, our original
problem, with
git-rev-list --topo-order <sha> ^tagList[0] ^tagList[1] ....
^tagList[n-1] ^merge[0] ... ^merge[k]
And have one or more tags according if results is a rev in tagList or
mergeList. Having the tag history it's easy to look up _all_ the tag
ancestors.
Marco
P.S: another use of
git-rev-list --top-order --parents --selected-only HEAD -- <sha 1>
<sha 2> ..... <sha n>
could be this:
Currently both qgit and gitk can filter revisions with a given set of
filter rules, but the results are shown together with the other
revisions or as a list of matching revisions with no useful graph
information.
We could feed git-rev-list --top-order --parents --selected-only with
the list of matching revisions and have a pretty and sensible graph
too.
^ permalink raw reply
* Re: Importing Mozilla CVS into git
From: Jakub Narebski @ 2006-06-04 7:05 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0606031631480.5498@g5.osdl.org>
On Sun, 4 Jun 2006, Linus Torvalds wrote:
> On Sun, 4 Jun 2006, Robin Rosenberg (list subscriber) wrote:
>>
>> (Yet) Another problem is that many windows tools use CR LF as the line ending.
>> Almost all windows editors default to CRLF and some detect existing line
>> endings. No editing with notepad anymore. Of course that is a problem
>> regardless of whether a git or cvs client is used. You'll get these big
>> everything-changed commits that alter between CRLF and LF.
>
> The only sane approach there (if you want to be at all cross-platform) is
> to just force everybody to _commit_ in UNIX '\n'-only format. Especially
> as most Windows tools probably handle that fine on reading (just have
> trouble writing them).
>
> And that shouldn't actually be that hard to do. The most trivial approach
> is to have just a pre-trigger on commits, but let's face it, that would
> not be a good "full" solution. A better one is to just make the whole
> "git update-index" thing just have a "automatically ignore CR/LF" mode.
Why wouldn't it be good solution?
BTW. wouldn't Mercurial encode/decode filters
http://www.selenic.com/mercurial/wiki/index.cgi/EncodeDecodeFilter
be a better solution than modifying files by "git update-index",
with all problems it can cause (not detected binary files, text files
which have to be in CR/LF line ending,...).
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: git daemon directory munging?
From: Junio C Hamano @ 2006-06-04 6:27 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0606031722340.5498@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> diff --git a/connect.c b/connect.c
> index 54f7bf7..36c5d04 100644
> --- a/connect.c
> +++ b/connect.c
> @@ -374,7 +374,7 @@ static int git_tcp_connect(int fd[2], co
>
> fd[0] = sockfd;
> fd[1] = sockfd;
> - packet_write(sockfd, "%s %s\n", prog, path);
> + packet_write(sockfd, "%s %s%c%s%c%s\n", prog, path, 0, host, 0, port);
> return 0;
> }
Adding host like HTTP does with Host: header makes sense but I
think the accept side can usually tell what the port it accepted
the connection to is.
^ permalink raw reply
* Re: More verbose "git fetch"?
From: Junio C Hamano @ 2006-06-04 6:25 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <7v7j3xebg6.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Linus Torvalds <torvalds@osdl.org> writes:
>
>> Has it always spit out those annoying
>>
>> xyz: same as branch 'xyz' of so-and-so-repo
>>
>> even without "-v"? I thought I killed them at some point, but
>> either they're back, or I'm just confused.
>
> "same" is protected with [ "$verboase" ] only on the tag side
> but not on the head side, which I think is a bug. Will fix.
...like this.
---
diff --git a/git-fetch.sh b/git-fetch.sh
index 69bd810..6ee755c 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -166,7 +166,7 @@ fast_forward_local () {
mb=$(git-merge-base "$local" "$2") &&
case "$2,$mb" in
$local,*)
- echo >&2 "* $1: same as $3"
+ [ "$verbose" ] && echo >&2 "* $1: same as $3"
;;
*,$local)
echo >&2 "* $1: fast forward to $3"
^ permalink raw reply related
* Re: More verbose "git fetch"?
From: Junio C Hamano @ 2006-06-04 5:28 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0606031809550.5498@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Has it always spit out those annoying
>
> xyz: same as branch 'xyz' of so-and-so-repo
>
> even without "-v"? I thought I killed them at some point, but
> either they're back, or I'm just confused.
"same" is protected with [ "$verboase" ] only on the tag side
but not on the head side, which I think is a bug. Will fix.
^ permalink raw reply
* Using subversion tools on Mozilla CVS
From: Jon Smirl @ 2006-06-04 3:09 UTC (permalink / raw)
To: git
I found this tool written in Python for importing CVS into Subversion.
It seems to be handling the Mozilla CVS repository with fewer problems
than parsecvs.
http://cvs2svn.tigris.org/cvs2svn.html
Since I'm not a native Python speaker, anyone else want to give a try
at changing it to support git?
It found these symbols to be ambiguous, so I manually forced them the
way they look like they should be.
cvs2svn --trunk-only -s svntest \
--force-tag=THUNDERBIRD_0_7_RELEASE --force-tag=CVS \
--force-branch=JAVADEV_RTM_20001102 \
--force-branch=XPCOM_BRANCH_LANDING_981104 \
--force-branch=MOZILLA_1_3_BRANCH \
--force-branch=N3 \
--force-branch=SeaMonkey_M4_BRANCH \
--force-branch=NORMANDY_BRANCH \
--force-branch=FASTLOAD_20010529_BRANCH \
--force-branch=MozillaSourceClassic_19981026_BRANCH \
--force-branch=RDF_19981124_BRANCH \
--force-branch=OTIS_TEST_BRANCH \
--force-branch=Netscape61_PR1_Mini_BRANCH \
--force-branch=XPCOM20_BRANCH \
--force-branch=XPC_IDISP_20020417_BRANCH \
--force-branch=RDF_122898_BRANCH \
--force-branch=MOZILLA_1_4_BRANCH \
--force-branch=Netscape_20000922_BRANCH \
--force-branch=NETSCAPE_7_0_OEM_BRANCH \
--force-branch=RDF_19990407_BRANCH \
--force-branch=ALERT_SERVICE_BRANCH \
--force-branch=SeaMonkey_M12_BRANCH \
--force-branch=SpiderMonkey140_NES40Rtm_Branch \
mozilla/mozilla
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: gitk on Windows: layout problem
From: Martin Langhoff @ 2006-06-04 2:30 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, git
In-Reply-To: <Pine.LNX.4.63.0605302121410.11532@wbgn013.biozentrum.uni-wuerzburg.de>
On 5/31/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> This is a known problem. See
>
> http://article.gmane.org/gmane.comp.version-control.git/18209
Indeed. MacOSX has the same problem, and that patch "fixes" it too.
It's a bit of a hack but I think it should be merged in, conditional
on OS naturally.
cheers,
m
^ permalink raw reply
* Re: Importing Mozilla CVS into git
From: Bertrand Jacquin @ 2006-06-04 2:24 UTC (permalink / raw)
To: Linus Torvalds
Cc: Robin Rosenberg (list subscriber), Martin Langhoff, Jon Smirl,
Keith Packard, git
In-Reply-To: <Pine.LNX.4.64.0606031631480.5498@g5.osdl.org>
On 6/4/06, Linus Torvalds <torvalds@osdl.org> wrote:
>
>
> On Sun, 4 Jun 2006, Robin Rosenberg (list subscriber) wrote:
> >
> > (Yet) Another problem is that many windows tools use CR LF as the line ending.
> > Almost all windows editors default to CRLF and some detect existing line
> > endings. No editing with notepad anymore. Of course that is a problem
> > regardless of whether a git or cvs client is used. You'll get these big
> > everything-changed commits that alter between CRLF and LF.
>
> The only sane approach there (if you want to be at all cross-platform) is
> to just force everybody to _commit_ in UNIX '\n'-only format. Especially
> as most Windows tools probably handle that fine on reading (just have
> trouble writing them).
>
> And that shouldn't actually be that hard to do. The most trivial approach
> is to have just a pre-trigger on commits, but let's face it, that would
> not be a good "full" solution. A better one is to just make the whole
> "git update-index" thing just have a "automatically ignore CR/LF" mode.
>
> Which really shouldn't be that hard. I think it's literally a matter of
> teaching "index_fd()" in sha1_file.c to recognize text-files, and remove
> CR/LF from them. All done (except to add the flag that enables the
> detection, of course - just so that sane systems won't have the overhead
> or the "corrupt binary files" issue).
>
> Something like this is TOTALLY UNTESTED!
>
> (You also need to teach "diff" to ignore differences in cr/lf, and this
> patch is bad because it's unconditional, and probably doesn't work
> anyway, but hey, the idea is possibly sound. Maybe)
Is it also apply for binary files ? It could corrupt files as well.
If end-user application don't understand '\n' but '\r\n', you can have
bad issues (I think to notepad here (yes crappy, but ..)). Couldn't it
be configurable ?
--
# Beber : beber@gna.org
# IM : beber@jabber.fr
# http://guybrush.ath.cx, irc://irc.freenode.net/#{e.fr,gentoofr}
^ permalink raw reply
* Re: [PATCH 0/27] Documentation: Spelling fixes
From: Horst von Brand @ 2006-06-04 2:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Horst.H.von.Brand, git
In-Reply-To: <7vk67xenfe.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Most do not seem to be typoes, depending on where you learned
> the language (XYZour vs XYZor; ok, Ok, and OK; ie vs i.e.). I
> favour the latter two changes myself, but honestly, I do not
> deeply care that much. The rest are real typos.
>
> It seems that 1/27 did not make here, nor either of the two big
> mailing list archives (gmane and marc).
Just resent it alone.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ permalink raw reply
* Re: Gitk feature - show nearby tags
From: Paul Mackerras @ 2006-06-04 1:59 UTC (permalink / raw)
To: Marco Costalba; +Cc: Junio C Hamano, git, Jonas Fonseca
In-Reply-To: <e5bfff550606030416s2ef6182crbde1395dd29e5b94@mail.gmail.com>
Marco Costalba writes:
> If I have understood correctly the patch runs a 'git rev-list --all
> --topo-order --parents'
> and then does a tree walking.
Yes, that's right. It means that gitk can show the nearest tags even
if they aren't included in the current view.
> I am wandering if there exist any native git way to found the previous tag.
I don't know of any. Doing the tree walking in Tcl turned out to be
not too much of an overhead, though; it does the whole kernel
repository in 1.5 seconds on my G5.
> 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?
I'm not sure exactly what that would do, but gitk can show more than
one tag (the term "nearest tag" is only a shorthand approximation for
what it does). For example, if you have two tagged commits where
neither is an ancestor of the other, and do a merge of the two, gitk
will show both tags when you select the merge. It doesn't actually
happen in the kernel repository, though, because the tags there form a
linear list (at least the tags in the upstream repository do).
Paul.
^ 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