* 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
* Re: Gitk feature - show nearby tags
From: Paul Mackerras @ 2006-06-04 1:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy7wedvyx.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano writes:
> That would be useful I think.
Done. It was pretty easy with the infrastructure for doing the tags
in place.
> Yes, but I rarely if ever pull "next" as a whole into "master".
I see. In that case it probably would be good if you pulled the gitk
"new" branch into "next".
Paul.
^ permalink raw reply
* More verbose "git fetch"?
From: Linus Torvalds @ 2006-06-04 1:11 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
Is it just me who has been getting less accepting, or has "git fetch"
gotten more verbose?
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.
Linus
^ permalink raw reply
* Re: [PATCH 0/27] Documentation: Spelling fixes
From: Junio C Hamano @ 2006-06-04 1:09 UTC (permalink / raw)
To: Horst.H.von.Brand; +Cc: git
In-Reply-To: <33723.2579863214$1149366476@news.gmane.org>
Thanks.
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).
^ permalink raw reply
* git clone takes ages on a slow link
From: Anton Blanchard @ 2006-06-04 1:01 UTC (permalink / raw)
To: git
Hi,
I tried cloning a local repository when connected over a slow (1 second+
latency) link. It took forever (I gave up after 10 minutes). If I ran
it in the background it took a few seconds.
I think the ticker is over anxious.
# git clone -l linux-2.6 linux-2.6-test
0 blocks
Checking files out...
5% (1060/19552) done <---- performance bottleneck
Anton
^ permalink raw reply
* Re: git daemon directory munging?
From: Linus Torvalds @ 2006-06-04 0:42 UTC (permalink / raw)
To: Jon Loeliger; +Cc: git
In-Reply-To: <E1FmgFV-0001i6-Kc@jdl.com>
On Sat, 3 Jun 2006, Jon Loeliger wrote:
>
> <jdl> Thus, I'd use something like:
> --map-base=www.foo.com/pub/scm:/pub/foo/scm
> --map-base=www.bar.com/pub/scm=/pub/bar/scm
The bigger problem is that nothing actually passes in the hostname to
git-daemon in the first place. By the time the git-daemon is contacted,
the hostname is long gone ;(
Now, you can just extend the git protocol to just pass in the host too.
You can in fact do this in a backwards-compatible manner (old git-daemons
will just ignore it, and new git daemons will automatically notice new
clients) with something evil like the appended.
Not tested (and this actualyl doesn't make the daemon _use_ the data, it
just adds a comment - the rest "is left as an exercise for the reader")
Linus
---
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;
}
diff --git a/daemon.c b/daemon.c
index 776749e..61e0af9 100644
--- a/daemon.c
+++ b/daemon.c
@@ -267,7 +267,7 @@ static int upload(char *dir)
static int execute(void)
{
static char line[1000];
- int len;
+ int len, n;
alarm(init_timeout ? init_timeout : timeout);
len = packet_read_line(0, line, sizeof(line));
@@ -276,6 +276,14 @@ static int execute(void)
if (len && line[len-1] == '\n')
line[--len] = 0;
+ n = strlen(line);
+ if (n != len) {
+ /* Cool, we have hidden info at the end */
+ /* Parse the hostname and the port, and */
+ /* leave some room for expansion for */
+ /* the future .. */
+ }
+
if (!strncmp("git-upload-pack ", line, 16))
return upload(line+16);
^ permalink raw reply related
* git daemon directory munging?
From: Jon Loeliger @ 2006-06-04 0:13 UTC (permalink / raw)
To: git
Scrapped right off the #git IRC channel...
<jdl> I stumbled across some git-daemon quirk for which I'd like opinions on
possible solutions. [18:56]
<jdl> I run a server that houses multiple virtual hosts on one physical
machine.
<jdl> It has multiple Apache based websites on it, and I want to front
multiple git repositories with gitweb. That all works fine. [18:57]
<jdl> But when I set up my repository stores, ie the /pub/scm/repo.git places,
it falls apart.
<jdl> I want to maintain separate sets of git repos for each virtual site.
[18:58]
<jdl> That is, www.foo.com can't see the repos of www.bar.com and vice versa.
<jdl> So I have an Apache directory set up that maps www.foo.com/pub/scm to
some place like /pub/foo/scm using an alias for /pub/scm. [18:59]
<jdl> Similarly, for www.bar.com I map /pub/scm to /pub/bar/scm
<jdl> Now, when I clone using http: all is well as it correctly maps the URL
using the Apache Alias entry. [19:00]
<jdl> However, when cloning via git: it doesn't do the Alias mapping based on
the given website prefix part of the URL.
<jdl> I would have to clone using git://www.foo.com/pub/foo/scm even though I
would clone using http://www.foo.com/pub/scm/ [19:01]
<jdl> So my proposed solution is to setup a genarlization of the git-daemon
-baser-path=path argument.
<jdl> Instead of a single --base-path, there are potentially multiple
--base-path entries that match multiple a URL prefixes. [19:02]
<jdl> Thus, I'd use something like:
--map-base=www.foo.com/pub/scm:/pub/foo/scm
--map-base=www.bar.com/pub/scm=/pub/bar/scm [19:04]
<dormando> mod_rewrite for git :|
<jdl> Quick prefix hack, yeah. [19:05]
<jdl> Um, stop me before I hack....? :-) [19:06]
<dormando> you're going to end up needing something that supports basic
regexes before long
<dormando> I can't think of many cases where you'd want to directly map like
that, and especially in that specific manner. [19:07]
<jdl> I can't hear you.
<dormando> sorry.
* dormando was going to have similar problems for his hosting service
^ permalink raw reply
* Re: [PATCH] Cleanup git-send-email.perl:extract_valid_email
From: Horst von Brand @ 2006-06-04 0:10 UTC (permalink / raw)
To: Eric Wong; +Cc: Horst H. von Brand, git, Junio C Hamano, Ryan Anderson
In-Reply-To: <20060603224935.GA10324@hand.yhbt.net>
Eric Wong <normalperson@yhbt.net> wrote:
> "Horst H. von Brand" <vonbrand@inf.utfsm.cl> wrote:
> > - Fix the regular expressions for local addresses
> > - Fix the fallback regexp for non-local addresses, simplify the logic
> >
> > Signed-off-by: Horst H. von Brand <vonbrand@inf.utfsm.cl>
> > ---
> > git-send-email.perl | 9 +++------
> > 1 files changed, 3 insertions(+), 6 deletions(-)
> >
> > diff --git a/git-send-email.perl b/git-send-email.perl
> > index ed1d89b..a7a7797 100755
> > --- a/git-send-email.perl
> > +++ b/git-send-email.perl
> > @@ -314,18 +314,15 @@ sub extract_valid_address {
> > my $address = shift;
> >
> > # check for a local address:
> > - return $address if ($address =~ /^([\w\-]+)$/);
> > + return $address if ($address =~ /^([\w\-.]+)$/);
>
> I keep forgetting this, '+' is a valid (and useful) setup, too.
Oops...
> > if ($have_email_valid) {
> > return Email::Valid->address($address);
> > } else {
> > # less robust/correct than the monster regexp in Email::Valid,
> > # but still does a 99% job, and one less dependency
> > - my $cleaned_address;
> > - if ($address =~ /([^\"<>\s]+@[^<>\s]+)/) {
> > - $cleaned_address = $1;
> > - }
> > - return $cleaned_address;
> > + $address =~ /([\w\-.]+@[\w\-.]+)/;
> > + return $1;
>
> Actually, I'm retracting my earlier ack on this. This is way too
> restrictive. I'd rather allow an occasional invalid email address than
> to reject valid ones. I generally trust git users to know what they're
> doing when entering email addresses[1].
>
> *, $, ^, +, = are all valid characters in the username portion (not sure
> about local accounts, though), and I'm sure there are more that I don't
> know about.
As a general principle, I prefer to check what is legal instead of trying
to filter out what isn't.
--
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: Importing Mozilla CVS into git
From: Linus Torvalds @ 2006-06-03 23:47 UTC (permalink / raw)
To: Robin Rosenberg (list subscriber)
Cc: Martin Langhoff, Jon Smirl, Keith Packard, git
In-Reply-To: <200606040116.38036.robin.rosenberg.lists@dewire.com>
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)
Linus
---
diff --git a/sha1_file.c b/sha1_file.c
index aea0f40..6dc6a3f 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1740,9 +1740,30 @@ int index_pipe(unsigned char *sha1, int
return ret;
}
+static unsigned long autodetect_crlf(unsigned char *src, unsigned long size)
+{
+ unsigned long newsize = 0;
+ unsigned char *dst = src;
+ unsigned char last = 0;
+
+ while (size) {
+ unsigned char c = *src++;
+ if (last == '\r' && c == '\n') {
+ dst[-1] = '\n';
+ } else {
+ newsize++;
+ dst++;
+ if (dst != src)
+ dst[-1] = c;
+ }
+ last = c;
+ }
+ return newsize;
+}
+
int index_fd(unsigned char *sha1, int fd, struct stat *st, int write_object, const char *type)
{
- unsigned long size = st->st_size;
+ unsigned long size = st->st_size, use_size;
void *buf;
int ret;
unsigned char hdr[50];
@@ -1755,12 +1776,15 @@ int index_fd(unsigned char *sha1, int fd
if (buf == MAP_FAILED)
return -1;
- if (!type)
+ use_size = size;
+ if (!type) {
type = blob_type;
+ use_size = autodetect_crlf(buf, size);
+ }
if (write_object)
- ret = write_sha1_file(buf, size, type, sha1);
+ ret = write_sha1_file(buf, use_size, type, sha1);
else {
- write_sha1_file_prepare(buf, size, type, sha1, hdr, &hdrlen);
+ write_sha1_file_prepare(buf, use_size, type, sha1, hdr, &hdrlen);
ret = 0;
}
if (size)
^ 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