* Re: [ANNOUNCE] TopGit v0.3
From: martin f krafft @ 2008-09-12 18:14 UTC (permalink / raw)
To: Petr Baudis, Jan Nieuwenhuizen, git
In-Reply-To: <20080912131530.GZ10360@machine.or.cz>
[-- Attachment #1: Type: text/plain, Size: 561 bytes --]
also sprach Petr Baudis <pasky@suse.cz> [2008.09.12.1415 +0100]:
> I'm stopping to see any way how to sanely support dependency
> removal without history rewriting, since we rely on Git for our
> all changes propagation.
I've considered this question a lot before and could not come up
with anything; you cannot undo a merge.
--
martin | http://madduck.net/ | http://two.sentenc.es/
it may look like i'm just sitting here doing nothing.
but i'm really actively waiting
for all my problems to go away.
spamtraps: madduck.bogus@madduck.net
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] Update RPM spec for the new location of git-cvsserver.
From: Quy Tonthat @ 2008-09-12 16:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
git-cvsserver has been moved from libexecdir to bindir.
Signed-off-by: Quy Tonthat <qtonthat@gmail.com>
---
git.spec.in | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/git.spec.in b/git.spec.in
index c6492e5..6733b6f 100644
--- a/git.spec.in
+++ b/git.spec.in
@@ -145,6 +145,7 @@ rm -rf $RPM_BUILD_ROOT
%files cvs
%defattr(-,root,root)
%doc Documentation/*git-cvs*.txt
+%{_bindir}/git-cvsserver
%{_libexecdir}/git-core/*cvs*
%{!?_without_docs: %{_mandir}/man1/*cvs*.1*}
%{!?_without_docs: %doc Documentation/*git-cvs*.html }
@@ -188,6 +189,9 @@ rm -rf $RPM_BUILD_ROOT
# No files for you!
%changelog
+* Fri Sep 12 2008 Quy Tonthat <qtonthat@gmail.com>
+- move git-cvsserver to bindir.
+
* Sun Jun 15 2008 Junio C Hamano <gitster@pobox.com>
- Remove curl from Requires list.
--
1.6.0.2.1q
^ permalink raw reply related
* Re: git-gui: more issues with diff parsing
From: Jakub Narebski @ 2008-09-12 18:01 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Michele Ballabio, git
In-Reply-To: <20080912152345.GE22960@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> The diff is weird:
>
> $ git-diff-index --cached -p --no-color -U5 \
> d6e02aa06c91c711d98ae06e6e69c5de5841a5e5 -- g
> diff --git a/g b/g
> deleted file mode 100644
> index e69de29..1a010b1
> diff --git a/g b/g
> new file mode 120000
> index e69de29..1a010b1
> --- /dev/null
> +++ b/g
> @@ -0,0 +1 @@
> +file
> \ No newline at end of file
>
> Notice how we get two diffs for the same file? That's why git-gui
> is choking on this particular change. It expected only one diff
> for the path it gave to Git. It got two back. In cases like this
> we may not be able to support line or hunk application as the patch
> is really two different patches against that path. :-|
Hmmm... it looks _exactly_ like a problem I had with writing
"syntax highlighting" (and linkage) for the patchset part of
'commitdiff' and 'blobdiff' views, namely that typechange
(file to symlink and vice versa) generates two patches for
single difftree (raw diff format output) line.
See git_patchset_body in gitweb/gitweb.perl, and is_patch_split
function, and commit message of 0cec6db (gitweb: Fix and simplify
"split patch" detection), which tells about alternate solution.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: CGit and repository list
From: Shawn O. Pearce @ 2008-09-12 17:45 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Petr Baudis, git
In-Reply-To: <200809121940.43471.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> wrote:
> Dnia piątek 12. września 2008 18:05, Petr Baudis napisał:
> > On Fri, Sep 12, 2008 at 05:54:29PM +0200, Jakub Narebski wrote:
> >>
> >> P.S. Could you please gather some statistics to compare the period
> >> before and after installing "smart" HTTP server (and after smart
> >> clients became widespread).
> >
> > What kind of statistics?
>
> In short: check how "smart" HTTP protocol would improve things.
The real improvement is on the client side; how long does it take
to do a clone or a fetch with dumb HTTP vs. with smart HTTP. The
latency is horrible for dumb HTTP if the repository is not packed,
or bad if it just repacked and you have to download everything again.
Knowing the transfer time of each request start-to-finish and the
total time for a "session" (e.g. a period of where that IP appears
actively requesting in the logs) would tell you how long a given
client needs to do a fetch or clone.
--
Shawn.
^ permalink raw reply
* Re: CGit and repository list
From: Jakub Narebski @ 2008-09-12 17:40 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20080912160538.GB10360@machine.or.cz>
Dnia piątek 12. września 2008 18:05, Petr Baudis napisał:
> On Fri, Sep 12, 2008 at 05:54:29PM +0200, Jakub Narebski wrote:
>>
>> P.S. Could you please gather some statistics to compare the period
>> before and after installing "smart" HTTP server (and after smart
>> clients became widespread).
>
> What kind of statistics?
In the simplest case just some averaged system load (perhaps load
average from uptime, or from top, or from /proc) before and after.
Perhaps bandwidth used per week or something like that too.
If you have time and interest, CPU load, disk IO, network IO or
network bandwidth used, and average time to serve request (latency)
for fetching via HTTP protocol, for "dumb" and "smart" clients,
perhaps averaged over number of requests. (I don't know unfortunately
how to get such data).
In short: check how "smart" HTTP protocol would improve things.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: git-gui: more issues with diff parsing
From: Junio C Hamano @ 2008-09-12 17:06 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Michele Ballabio, git
In-Reply-To: <20080912152345.GE22960@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Notice how we get two diffs for the same file? That's why git-gui
> is choking on this particular change. It expected only one diff
> for the path it gave to Git. It got two back. In cases like this
> we may not be able to support line or hunk application as the patch
> is really two different patches against that path. :-|
>
>> The following patch seems to fix this particular issue, but I don't think
>> it's the right fix...
>
> I don't think that is the right fix, but the one that I just tried to
> write to do clear_diff when we see the second diff --git line didn't
> work either. Plus we probably need to disable the hunk apply code.
You will have the same issue not for submodules, too. A typechange has
always been expressed as delete followed by create.
Probably you already have learned the nature of change (i.e. create?
modify? delete? typechange?) when you populate the list of files with
changes that could be staged, which means by the time the user picks from
the liast you already know if it is a typechange.
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Stephen R. van den Berg @ 2008-09-12 16:43 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20080912161911.GA12096@coredump.intra.peff.net>
Jeff King wrote:
>On Fri, Sep 12, 2008 at 05:54:27PM +0200, Stephen R. van den Berg wrote:
>> True. But repopulating this cache after cloning means that you have to
>> calculate the patch-id of *every* commit in the repository. It sounds
>> like something to avoid, but maybe I'm overly concerned, I have only a
>> vague idea on how computationally intensive this is.
>For a rough estimate, try:
> time git log -p | git patch-id >/dev/null
On my system that results in 2ms per commit on average. Not huge, but
not small either, I guess. Running it results in real waiting time, it
all depends on how patient the user is.
--
Sincerely,
Stephen R. van den Berg.
"Father's Day: Nine months before Mother's Day."
^ permalink raw reply
* Re: CGit and repository list
From: Shawn O. Pearce @ 2008-09-12 16:22 UTC (permalink / raw)
To: Petr Baudis; +Cc: Jakub Narebski, Lars Hjemli, git
In-Reply-To: <20080912162037.GC10360@machine.or.cz>
Petr Baudis <pasky@suse.cz> wrote:
> >
> > Disk IO and network IO consumed probably. The kernel.org folks are
> > hoping the smart HTTP server can lower their loads a bit by being
> > more careful about what we send to the client.
>
> To check whether it actually matters for me, I have counted HTTP
> requests for info/refs: 42 per hour for the last 5.5 days. So it might.
> 28% of the requests are web crawlers.
>
> For objects/../, it is more fun - 1942 requests per hour. 46% is
> accounted for web crawlers. I will put up a robots.txt. ;-)
Is Googlebot trying to make those loose objects searchable?
I wonder what byte sequence I should try in the search bar...
;-)
--
Shawn.
^ permalink raw reply
* Re: CGit and repository list
From: Petr Baudis @ 2008-09-12 16:20 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Jakub Narebski, Lars Hjemli, git
In-Reply-To: <20080912160854.GL22960@spearce.org>
On Fri, Sep 12, 2008 at 09:08:54AM -0700, Shawn O. Pearce wrote:
> Petr Baudis <pasky@suse.cz> wrote:
> > On Fri, Sep 12, 2008 at 05:54:29PM +0200, Jakub Narebski wrote:
> >
> > > P.S. Could you please gather some statistics to compare the period
> > > before and after installing "smart" HTTP server (and after smart
> > > clients became widespread).
> >
> > What kind of statistics?
>
> Disk IO and network IO consumed probably. The kernel.org folks are
> hoping the smart HTTP server can lower their loads a bit by being
> more careful about what we send to the client.
To check whether it actually matters for me, I have counted HTTP
requests for info/refs: 42 per hour for the last 5.5 days. So it might.
28% of the requests are web crawlers.
For objects/../, it is more fun - 1942 requests per hour. 46% is
accounted for web crawlers. I will put up a robots.txt. ;-)
--
Petr "Pasky" Baudis
The next generation of interesting software will be done
on the Macintosh, not the IBM PC. -- Bill Gates
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Jeff King @ 2008-09-12 16:19 UTC (permalink / raw)
To: Stephen R. van den Berg; +Cc: git
In-Reply-To: <20080912155427.GB2915@cuci.nl>
On Fri, Sep 12, 2008 at 05:54:27PM +0200, Stephen R. van den Berg wrote:
> True. But repopulating this cache after cloning means that you have to
> calculate the patch-id of *every* commit in the repository. It sounds
> like something to avoid, but maybe I'm overly concerned, I have only a
> vague idea on how computationally intensive this is.
For a rough estimate, try:
time git log -p | git patch-id >/dev/null
-Peff
^ permalink raw reply
* Re: CGit and repository list
From: Lars Hjemli @ 2008-09-12 16:12 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Jakub Narebski, Petr Baudis, git
In-Reply-To: <20080912160006.GI22960@spearce.org>
On Fri, Sep 12, 2008 at 6:00 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
> Jakub Narebski <jnareb@gmail.com> wrote:
>> Petr Baudis wrote:
>> >
>> > this finally tripped me over and I wanted to quickly add cgit as an
>> > alternate viewing interface at repo.or.cz. [...]
>>
>> Or you can wait a little while for "smart" HTTP server, which I guess
>> also generates automatically or/and on the fly objects/info/packs and
>> info/refs required by "dumb" protocols clients (including old HTTP
>> clients).
>
> The automatic generation of objects/info/packs and info/refs is
> planned for support in the smart CGI, but it doesn't help the
> "gitweb URL is same as clone URL" concept. For that you need your
> HTTP server to know how to issue some requests to gitweb and others
> to the smart CGI or to the filesystem.
In the case of cgit this should work transparently.
>
>> P.S. Could you please gather some statistics to compare the period
>> before and after installing "smart" HTTP server (and after smart
>> clients became widespread).
>
> Well, it would help if there was a working implementation of the
> "smart" HTTP server. ;-)
I'll try to come up with a prototype for the smart server as part of cgit ;-)
--
larsh
^ permalink raw reply
* Re: CGit and repository list
From: Shawn O. Pearce @ 2008-09-12 16:08 UTC (permalink / raw)
To: Petr Baudis; +Cc: Jakub Narebski, Lars Hjemli, git
In-Reply-To: <20080912160538.GB10360@machine.or.cz>
Petr Baudis <pasky@suse.cz> wrote:
> On Fri, Sep 12, 2008 at 05:54:29PM +0200, Jakub Narebski wrote:
>
> > P.S. Could you please gather some statistics to compare the period
> > before and after installing "smart" HTTP server (and after smart
> > clients became widespread).
>
> What kind of statistics?
Disk IO and network IO consumed probably. The kernel.org folks are
hoping the smart HTTP server can lower their loads a bit by being
more careful about what we send to the client.
--
Shawn.
^ permalink raw reply
* Re: CGit and repository list
From: Petr Baudis @ 2008-09-12 16:05 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Lars Hjemli, git
In-Reply-To: <200809121754.30277.jnareb@gmail.com>
On Fri, Sep 12, 2008 at 05:54:29PM +0200, Jakub Narebski wrote:
> Petr Baudis wrote:
> > On Fri, Sep 12, 2008 at 04:36:11PM +0200, Lars Hjemli wrote:
> > >
> > > <plug>
> > > Current cgit also allows cloning over http using the same url as for
> > > browsing the repo, i.e. you may
> > >
> > > $ git clone http://hjemli.net/git/cgit
> > >
> > > This has one advantage over just publishing the repo; you don't have
> > > to run `git-update-server-info` (thanks to the work done by Shawn O.
> > > Pearce on git-http-backend, which is shamelessly reimplemented in
> > > cgit).
> > > </plug>
> >
> > this finally tripped me over and I wanted to quickly add cgit as an
> > alternate viewing interface at repo.or.cz. [...]
>
> Or you can wait a little while for "smart" HTTP server, which I guess
> also generates automatically or/and on the fly objects/info/packs and
> info/refs required by "dumb" protocols clients (including old HTTP
> clients).
It is more like that this prodded me to have a look at cgit again, think
of it and realize that it should be pretty easy for me to add cgit to
repo.or.cz. This is just a bonus. :-)
I have already mailed Shawn immediately after the original proposal
was posted that I'm willing to put this up on repo.or.cz as soon as
something tangible is ready.
> P.S. Could you please gather some statistics to compare the period
> before and after installing "smart" HTTP server (and after smart
> clients became widespread).
What kind of statistics?
--
Petr "Pasky" Baudis
The next generation of interesting software will be done
on the Macintosh, not the IBM PC. -- Bill Gates
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Theodore Tso @ 2008-09-12 16:00 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Jakub Narebski, Stephen R. van den Berg, Linus Torvalds,
Sam Vilain, git
In-Reply-To: <48CA8D6A.4000303@gnu.org>
On Fri, Sep 12, 2008 at 05:40:26PM +0200, Paolo Bonzini wrote:
> > But it is not true that "you can always generate the cache from the
> > git repository" in this case; the patch-id that is to be saved is
> > _original_ patch-id of cherry-picked (or reverted) changeset.
>
> He's proposing storing the original patch id in the commit message, and
> caching the commit SHA->patch id association on the side.
>
Actually its the association in the other direction which you'd want
to cache. It's fast given the commit SHA to dig the original patch id
out of the commit message. What is harder is given a patch id X, to
find all of the commits which either (a) have a patch id of X, or (b)
have a commit message indicating that the original patch-id was X. So
having a database which caches this information, so given a patch-id,
you can quickly look up the related commits, is what I believe Sam was
proposing, and which I think would solve the problem quite nicely.
- Ted
^ permalink raw reply
* Re: CGit and repository list
From: Shawn O. Pearce @ 2008-09-12 16:00 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Petr Baudis, Lars Hjemli, git
In-Reply-To: <200809121754.30277.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> wrote:
> Petr Baudis wrote:
> >
> > this finally tripped me over and I wanted to quickly add cgit as an
> > alternate viewing interface at repo.or.cz. [...]
>
> Or you can wait a little while for "smart" HTTP server, which I guess
> also generates automatically or/and on the fly objects/info/packs and
> info/refs required by "dumb" protocols clients (including old HTTP
> clients).
The automatic generation of objects/info/packs and info/refs is
planned for support in the smart CGI, but it doesn't help the
"gitweb URL is same as clone URL" concept. For that you need your
HTTP server to know how to issue some requests to gitweb and others
to the smart CGI or to the filesystem.
> P.S. Could you please gather some statistics to compare the period
> before and after installing "smart" HTTP server (and after smart
> clients became widespread).
Well, it would help if there was a working implementation of the
"smart" HTTP server. ;-)
Right now I haven't been able to touch the project for two weeks
straight. I'm hoping to be able to put 2 full days into it next
week. Lets see how that plan works.
--
Shawn.
^ permalink raw reply
* Re: CGit and repository list
From: Jakub Narebski @ 2008-09-12 15:54 UTC (permalink / raw)
To: Petr Baudis; +Cc: Lars Hjemli, git
In-Reply-To: <20080912145804.GF10544@machine.or.cz>
Petr Baudis wrote:
> On Fri, Sep 12, 2008 at 04:36:11PM +0200, Lars Hjemli wrote:
> >
> > <plug>
> > Current cgit also allows cloning over http using the same url as for
> > browsing the repo, i.e. you may
> >
> > $ git clone http://hjemli.net/git/cgit
> >
> > This has one advantage over just publishing the repo; you don't have
> > to run `git-update-server-info` (thanks to the work done by Shawn O.
> > Pearce on git-http-backend, which is shamelessly reimplemented in
> > cgit).
> > </plug>
>
> this finally tripped me over and I wanted to quickly add cgit as an
> alternate viewing interface at repo.or.cz. [...]
Or you can wait a little while for "smart" HTTP server, which I guess
also generates automatically or/and on the fly objects/info/packs and
info/refs required by "dumb" protocols clients (including old HTTP
clients).
P.S. Could you please gather some statistics to compare the period
before and after installing "smart" HTTP server (and after smart
clients became widespread).
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Stephen R. van den Berg @ 2008-09-12 15:54 UTC (permalink / raw)
To: Theodore Tso
Cc: Linus Torvalds, Sam Vilain, Jakub Narebski, Paolo Bonzini, git
In-Reply-To: <20080912145802.GV5082@mit.edu>
Theodore Tso wrote:
>On Fri, Sep 12, 2008 at 07:47:39AM +0200, Stephen R. van den Berg wrote:
>> It would probably become computationally prohibitive to use it between
>> long lived permanent branches. In that case it would need to be
>> augmented by the sha1 of the originating commit.
>Nope, as Sam suggested in his original message (but which got clipped
>by Linus when he was replying) all you have to do is to have a
>separate local database which ties commits and patch-id's together as
>a cache/index.
True. But repopulating this cache after cloning means that you have to
calculate the patch-id of *every* commit in the repository. It sounds
like something to avoid, but maybe I'm overly concerned, I have only a
vague idea on how computationally intensive this is.
>I know you seem to be resistent to caches, but caches are **good**
>because they are local information, which by definition can be
>implementation-dependent; you can always generate the cache from the
>git repository if for some reason you need to extend it. It also
>means that if it turns out you need to index reationships a different
>way, you can do that without having to make fundamental (incompatible)
>changes in the git object.
I fully agree that caches are good.
And yes I seem to resist the idea to create a cache at every whim, but
that mostly is because I want to avoid that everyone invents their own
mini-database for each and every data access they want to accellerate.
I mean, ideally, any database/index/accellerator structure you'd need
can reuse the SHA1 object database index, or maybe one or two other
semi-standard index types, and git would provide suitable library
functions for all three solutions. And if that would be the case, I'll
gladly throw in an extra cache or index at anytime to speed up the
particular access pattern I'm trying to make useable. But as far as I
can see, those library functions have not materialised yet, so I'm
hesitant to create yet another private database structure just for my
access patterns; and simply pulling in libdb or sqlite without agreement
that those libs are (re)used in a lot of places in git seems a bit
bloat-prone.
>local caches are database indexes. Just because you need an index in
>a particular direction to optimize a query or loopup operation does
>***not*** imply that you need to make a fundamental, globally visible,
>database schema change or git object layout which breaks compatibility
>for everybody.
It's not a certainty that changing the git object layout has to break
compatibility (it should be reasonably possible to add columns to the
schema without breaking anything, to stay with the database paradigm),
but I agree that creating another index can be considered better than
extending the schema.
--
Sincerely,
Stephen R. van den Berg.
"Father's Day: Nine months before Mother's Day."
^ permalink raw reply
* Re: RFC: perhaps a "new file" should not be deleted by "git reset --hard"
From: Miklos Vajna @ 2008-09-12 15:41 UTC (permalink / raw)
To: Eric Raible
Cc: Jeff Whiteside, Elijah Newren, Changsheng Jiang, Git Mailing List
In-Reply-To: <279b37b20809111649h77666a46u362dddfa1b40e0ca@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 344 bytes --]
On Thu, Sep 11, 2008 at 04:49:54PM -0700, Eric Raible <raible@gmail.com> wrote:
> What advantages does "git read-tree -m HEAD" have over "git reset" or
> "git rm --cached <file list>"?
Nothing. I should stop advertising that I still use a lot of plumbing
when a porcelain like 'git reset' does the job as well. ;-(
Thanks for the correction.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Paolo Bonzini @ 2008-09-12 15:40 UTC (permalink / raw)
To: Jakub Narebski
Cc: Theodore Tso, Stephen R. van den Berg, Linus Torvalds, Sam Vilain,
git
In-Reply-To: <200809121711.32448.jnareb@gmail.com>
>> I know you seem to be resistent to caches, but caches are **good**
>> because they are local information, which by definition can be
>> implementation-dependent; you can always generate the cache from the
>> git repository if for some reason you need to extend it. [...]
>
> But it is not true that "you can always generate the cache from the
> git repository" in this case; the patch-id that is to be saved is
> _original_ patch-id of cherry-picked (or reverted) changeset.
He's proposing storing the original patch id in the commit message, and
caching the commit SHA->patch id association on the side.
Paolo
^ permalink raw reply
* Re: [PATCH] git-gui: I18n fix sentence parts into full sentences for translation again.
From: Shawn O. Pearce @ 2008-09-12 15:39 UTC (permalink / raw)
To: Christian Stimming; +Cc: Alexander Gavrilov, git
In-Reply-To: <200809121232.14364.stimming@tuhh.de>
Christian Stimming <stimming@tuhh.de> wrote:
> Am Freitag, 12. September 2008 12:23 schrieb Alexander Gavrilov:
> > On Fri, Sep 12, 2008 at 1:17 PM, Christian Stimming <stimming@tuhh.de>
> wrote:
> > >- set op_question [mc "Force resolution to %s?
> > >-Note that the diff shows only conflicting changes.
> > >+ set op_question [strcat $targetquestion "\n" \
> > >+[mc "Note that the diff shows only conflicting changes.
> >
> > ...
> >
> > > - $target [short_path $current_diff_path]]
> > > + $targetquestion [short_path $current_diff_path]]]
> >
> > You should remove this $target completely -- there is no %s to match it
> > anymore.
>
> Oh - right. Thanks for pointing this out. Please modify the patch accordingly.
Fixed and applied. Thanks, both.
--
Shawn.
^ permalink raw reply
* Re: git-gui: more issues with diff parsing
From: Shawn O. Pearce @ 2008-09-12 15:23 UTC (permalink / raw)
To: Michele Ballabio; +Cc: git
In-Reply-To: <200809091030.04507.barra_cuda@katamail.com>
Michele Ballabio <barra_cuda@katamail.com> wrote:
> The patch
> git-gui: Fix diff parsing for lines starting with "--" or "++"
> seems to have introduced some glitches. With this sequence:
Oy.
> git init
> touch g
> git add g
> git commit -m"g is a file"
> rm g
> echo "vvvv" > file
> ln -s file g
> git add g file
> git gui
>
> Now clicking on "g" in the staged changes, git-gui gives this line:
> error: Unhandled 2 way diff marker: {d}
The diff is weird:
$ git-diff-index --cached -p --no-color -U5 d6e02aa06c91c711d98ae06e6e69c5de5841a5e5 -- g
diff --git a/g b/g
deleted file mode 100644
index e69de29..1a010b1
diff --git a/g b/g
new file mode 120000
index e69de29..1a010b1
--- /dev/null
+++ b/g
@@ -0,0 +1 @@
+file
\ No newline at end of file
Notice how we get two diffs for the same file? That's why git-gui
is choking on this particular change. It expected only one diff
for the path it gave to Git. It got two back. In cases like this
we may not be able to support line or hunk application as the patch
is really two different patches against that path. :-|
> The following patch seems to fix this particular issue, but I don't think
> it's the right fix...
I don't think that is the right fix, but the one that I just tried to
write to do clear_diff when we see the second diff --git line didn't
work either. Plus we probably need to disable the hunk apply code.
I'll look at it again when I can get more time.
--
Shawn.
^ permalink raw reply
* Re: [StGit PATCH] add option to import series directly from a tar archive
From: Karl Hasselström @ 2008-09-12 15:44 UTC (permalink / raw)
To: Clark Williams; +Cc: Samuel Tardieu, git
In-Reply-To: <48CA674B.9080900@gmail.com>
On 2008-09-12 07:57:47 -0500, Clark Williams wrote:
> then write a test to keep Karl happy,
Technically, you write the test to make sure that your new feature
works as intended and won't break in the future. But since that's
rather a mouthful, I guess "Karl" will do as an acronym. ;-)
> then try to come up with a way to deal with importing patches that
> don't have complete email addresses, no descriptions, etc. Once I
> get through that, I'll see if we can deal with weirdly rooted patch
> series.
Nice.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: StGit question
From: Karl Hasselström @ 2008-09-12 15:40 UTC (permalink / raw)
To: Clark Williams; +Cc: git, Catalin Marinas
In-Reply-To: <48CA6367.9020300@gmail.com>
On 2008-09-12 07:41:11 -0500, Clark Williams wrote:
> Ahhhh, no I hadn't found this. Cool! I wonder if I could save the
> series in the branch, so that someone could just checkout the branch
> and do:
>
> $ stg uncommit $(cat stg-series)
The patch stack log contains all the required info, so this should be
doable (given that you share your <branchname>.stgit branch, which is
the patch stack log).
> Or, maybe I'll look at adding a --series or --file option to
> uncommit?
Sure, that sounds like a good idea. I believe there are existing
commands that take a series file argument; check what they call their
flag.
> I suspect some chicken-and-egg problems here, but this is workable.
> And when you're talking >500 patches, anything you can do to
> automate is a wonderful thing :).
Nice to know StGit is being used with series of that size. I usually
never go beyond about 30 myself, so there are certain types of
scalability problems that I won't see.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Jakub Narebski @ 2008-09-12 15:11 UTC (permalink / raw)
To: Theodore Tso
Cc: Stephen R. van den Berg, Linus Torvalds, Sam Vilain,
Paolo Bonzini, git
In-Reply-To: <20080912145802.GV5082@mit.edu>
Theodore Tso wrote:
> On Fri, Sep 12, 2008 at 07:47:39AM +0200, Stephen R. van den Berg wrote:
>>>
>>>You could add it as a
>>>
>>> Original-patch-id: <sha1>
>>
>> That will probably work fine when operating locally on (short) temporary
>> branches.
>>
>> It would probably become computationally prohibitive to use it between
>> long lived permanent branches. In that case it would need to be
>> augmented by the sha1 of the originating commit.
>
> Nope, as Sam suggested in his original message (but which got clipped
> by Linus when he was replying) all you have to do is to have a
> separate local database which ties commits and patch-id's together as
> a cache/index.
>
> I know you seem to be resistent to caches, but caches are **good**
> because they are local information, which by definition can be
> implementation-dependent; you can always generate the cache from the
> git repository if for some reason you need to extend it. [...]
But it is not true that "you can always generate the cache from the
git repository" in this case; the patch-id that is to be saved is
_original_ patch-id of cherry-picked (or reverted) changeset.
OTOH it is not much different from reflog information, which also
cannot be regenerated from object database.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: CGit and repository list
From: Lars Hjemli @ 2008-09-12 15:10 UTC (permalink / raw)
To: Petr Baudis; +Cc: Jakub Narebski, git, Kristian Høgsberg
In-Reply-To: <20080912145804.GF10544@machine.or.cz>
On Fri, Sep 12, 2008 at 4:58 PM, Petr Baudis <pasky@suse.cz> wrote:
> it seems that cgit
> requires all the repositories explicitly listed in the config file.
> Do you plan to remove this limitation in the future?
Not really, I'd rather add another command (or a commandline option)
to generate an include-file for cgitrc by scanning directory-trees for
git repos. I've CC'd Kristian since I believe he's got such a script
running for freedesktop.org; if so, maybe it could be included/used as
basis for something similar in cgit?
--
larsh
^ 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