* Re: [EGIT PATCH 4/6] Add tags to the graphical history display.
From: Robin Rosenberg @ 2008-10-06 21:58 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20081006080834.GC27516@spearce.org>
måndagen den 6 oktober 2008 10.08.34 skrev Shawn O. Pearce:
> FYI, my comments don't fully cover this patch yet.
>
> > - protected PlotCommit(final AnyObjectId id) {
> > + protected PlotCommit(final AnyObjectId id, final Ref[] tags) {
> > super(id);
> > + this.refs = tags;
>
> this.refs isn't final. There is no reason to be adding it to the
> constructor and having this ripple effect all the way up into the
> RevWalk class.
Eh, it doesn't, ecept I added a methos to RevWalk than can return tags,
which it doesn't unless the information is attached.
> Maybe PlotWalk should override next() and only set PlotCommit.refs on
> things returned from super.next()? This way we only do tag lookup
> on commits that the filtering rules have said should be shown in
> to the application, but the refs should still be inserted prior to
> the application seeing the RevCommit.
I missed something here I think. Thanks. Maybe I thought... doesn't matter.
I'll rewrite the changes in and related to this completely.
> > @@ -54,6 +66,7 @@
> > public PlotWalk(final Repository repo) {
> > super(repo);
> > super.sort(RevSort.TOPO, true);
> > + reverseRefMap = repo.getAllRefsByPeeledObjectId();
>
> I wonder if this shouldn't be done as part of the StartGenerator
> (or something like it but specialized for PlotWalk). I only say
> that because a reused PlotWalk may want to make sure its ref map
> is current with the repository its about to walk against.
noted.
> You are inside of a PlotWalk, which extends RevWalk, which has very
> aggressive caching of RevCommit and RevTag data instances, and very
> fast parsers. Much faster than the legacy Commit and Tag classes.
Maybe we should rid us of them completely and make new commit from
these classes of possible more lightweight ones. The old classes were
straightforward but are on overtime now.
> I think we should use the RevCommit and RevTag classes to handle
> sorting here. RevCommit already has the committer time cached
> and stored in an int. RevCommit probably should learn to do the
> same for its "tagger" field. The tiny extra bloat (1 word) that
> adds to a RevTag instance is worth it when we consider implementing
> something like this and/or git-describe where sorting tags by their
> dates is useful.
As you noted earlier we usually have at most one ref per commit to sort.
Not much to optimize for speed here with current repos. For a one-element
list the compare routine wil not even be invoked.
>
> > + tags = list.toArray(new Ref[list.size()]);
>
> I wonder if using a Ref[] here even makes sense given that the data
> is stored in a List<Ref>. I use RevCommit[] inside of RevCommit
> generally because the number of entries in the array is 1 or 2 and
> the array is smaller than say an ArrayList.
>
> In hindsight those RevCommit[] probably should be a List<RevCommit>
> with different list implementations based on the number of parents
> needed:
>
> 0 parents: Collections.emptyList()
> 1 parent: Collections.singletonList()
> 2 parents: some especialized AbstractList subclass
> 3 parents: ArrayList
>
> I think it would actually use less memory per instance, which is
> a huge bonus, but we'd pay a downcasting penalty on each access.
> HotSpot is supposed to be really good at removing the downcast
> penalty from say java.util.List, but I don't if it can beat a typed
> array access.
I guess measuring is the right way. For these small arrays, my bet
is that List is way faster because we do not need any bounds checking.
Hotspot is reasonably good at optimizing those away, but that won't
help for much small arrays.
> Sorry I got off on a bit of a tangent here. I'm just trying to
> point out that the primary reason I've usd an array before is
> probably moot here since the data is already in a List.
Could it be that arrays are often better then lists.
> > diff --git a/org.spearce.jgit/src/org/spearce/jgit/revwalk/RevWalk.java b/org.spearce.jgit/src/org/spearce/jgit/revwalk/RevWalk.java
> > index d7e4c58..41d57c6 100644
> > --- a/org.spearce.jgit/src/org/spearce/jgit/revwalk/RevWalk.java
> > +++ b/org.spearce.jgit/src/org/spearce/jgit/revwalk/RevWalk.java
> > @@ -53,6 +53,7 @@
>
> IMHO this class shouldn't need to be modified.
>
> > @@ -541,7 +542,7 @@ public RevTree lookupTree(final AnyObjectId id) {
> > public RevCommit lookupCommit(final AnyObjectId id) {
> > RevCommit c = (RevCommit) objects.get(id);
> > if (c == null) {
> > - c = createCommit(id);
> > + c = createCommit(id, getTags(id));
>
> This code is performance critical to commit parsing. Trying to
> lookup tags for every commit we evaluate, especially ones that we
> will never show in the UI (because they are uninteresting) but that
> we still need to parse in order to derive the merge base is just
> a huge waste of time.
>
> Same applies for the lookupAny and parseAny methods.
>
Ack.
-- robin
^ permalink raw reply
* Re: [StGit PATCH 5/6] Refresh the main stg man page
From: Samuel Tardieu @ 2008-10-06 21:30 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Karl Hasselström, git
In-Reply-To: <b0943d9e0810061414ja87488k6aef65fec0856144@mail.gmail.com>
>>>>> "Catalin" == Catalin Marinas <catalin.marinas@gmail.com> writes:
Catalin> I wouldn't advertise the refreshing of "any" patch as it
Catalin> doesn't always work (it actually fails in a lot of cases). Or
Catalin> at least we could mention that there are some restrictions.
Does it? I use it all the times.
Sam
--
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/
^ permalink raw reply
* Re: [StGit PATCH 6/6] Refresh and expand the tutorial (not finished)
From: Catalin Marinas @ 2008-10-06 21:25 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20081005160203.19886.33463.stgit@yoghurt>
2008/10/5 Karl Hasselström <kha@treskal.com>:
> This is a first pass at expanding the tutorial, fixing its formatting,
> and updating it with the new things that have happened in StGit.
>
> There are a number of things still left to do in the second half of
> the document; they are tagged with "TODO".
Thanks for this. Even with the TODOs, I think we can merge them into
the master branch so that I have the same copy as you. Do you plan to
do more work on the tutorial (so that we don't duplicate)?
> -Layout of the .git directory
Should we mention the metadata storage somewhere? This is probably too
advanced for the tutorial but might be useful to have it in a
development document (for other to understand where we keep things).
Actually, is the automatically generated documentation from the new
infrastructure enough?
--
Catalin
^ permalink raw reply
* Re: [FYI][PATCH] Customizing the WinGit installer
From: Abdelrazak Younes @ 2008-10-06 21:19 UTC (permalink / raw)
To: Johannes.Schindelin
Cc: Linus Torvalds, Jakub Narebski, Petr Baudis, msysgit, git
In-Reply-To: <alpine.DEB.1.00.0810061959280.22125@pacific.mpi-cbg.de.mpi-cbg.de>
On 06/10/2008 20:01, Johannes Schindelin wrote:
> Hi,
>
> On Mon, 6 Oct 2008, Linus Torvalds wrote:
>
>> On Mon, 6 Oct 2008, Johannes Schindelin wrote:
>>> Well, I consider it a courtesy to the msysGit people to leave it where
>>> it is.
>> Umm. I consider it to be UNACCEPTABLY STUPID to claim "courtesy" if it
>> actually makes something just more irritating to users.
>>
>> I absolutely detest clicking through EULA's or other self-serving crap.
>> I hate software that bothers me with their license details. Nobody reads
>> those things anyway, and an extra click or an extra window I didn't ask
>> for - _especially_ in open source software - is just a bug.
>>
>> Bugs aren't "courtesy". Not to the user, and certainly not to the
>> developer.
>
> It is not a bug. It is a message that tells the Windows user that this is
> GPLed software, and that they are free to copy it. Windows users (and
> developers on Windows are more of users than developers) are often not
> aware of that fact.
Well, maybe so called "Windows pseudo-developers" do not feel welcome to
participate to this particular project? Or maybe this project has not
reached yet the minimum visibility threshold? git has a lot of
contributors on Linux because it is visible there. Do you think all
users of git on Linux systematically contributes?
Don't get me wrong, I am truly thankful for msysgit but, IMHO, if you
produce and publish a free software you should just accept and be glad
that it is used. Otherwise, just don't publish it.
> That is the reason why many Open Source projects do not bother on Linux,
> but do bother on Windows.
And a lot other projects do not bother with this even on Windows and Mac
too.
Regards,
Abdel.
^ permalink raw reply
* Re: [StGit PATCH 5/6] Refresh the main stg man page
From: Catalin Marinas @ 2008-10-06 21:15 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20081005160157.19886.7137.stgit@yoghurt>
2008/10/5 Karl Hasselström <kha@treskal.com>:
> + * You can easily 'rebase' your patch stack on top of any other Git
> + branch. (The 'base' of a patch stack is the most recent Git commit
> + that is not an StGit patch.) For example, if you started making
You may want to move the bracket before the dot.
--
Catalin
^ permalink raw reply
* Re: [StGit PATCH 5/6] Refresh the main stg man page
From: Catalin Marinas @ 2008-10-06 21:14 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20081005160157.19886.7137.stgit@yoghurt>
2008/10/5 Karl Hasselström <kha@treskal.com>:
> Update the text to reflect what's happened in StGit in the last few
> releases. Also, consistently capitalize the names "Git" and "StGit".
I need to change the websites as well (BTW, I gave you admin rights on
the gna.org project page).
> --- a/Documentation/stg.txt
> +++ b/Documentation/stg.txt
[...]
> + * After making changes to the worktree, you can incorporate the
> + changes into an existing patch; this is called 'refreshing'. You
> + may refresh any patch, not just the topmost one.
I wouldn't advertise the refreshing of "any" patch as it doesn't
always work (it actually fails in a lot of cases). Or at least we
could mention that there are some restrictions.
> + * You can easily 'rebase' your patch stack on top of any other Git
> + branch.
It might be better with something like "on top of a different Git
commit". The first thought when reading the above is that you can move
the patch stack to a different Git branch easily, which is not the
case (you need to cherry-pick the patches).
> + * The patch stack is just some extra metadata attached to regular
> + Git commits, so you can continue to use Git tools along with
> + StGit.
Again, this is with some restrictions (or there aren't any with the
new infrastructure?).
> + Tracking changes from a remote branch, while maintaining local
> + modifications against that branch, possibly with the intent of
> + sending some patches upstream. You can modify your patch stack as
> + much as you want, and when your patches are finally accepted
> + upstream, the permanent recorded Git history will contain just the
> + final sequence of patches, and not the messy sequence of edits that
> + produced them.
Maybe we could mention that the local history is also clean, not only
the upstream tree (though you mention it later in a different hunk).
--
Catalin
^ permalink raw reply
* Re: What's cooking in git/spearce.git (Oct 2008, #01; Mon, 06)
From: Jeff King @ 2008-10-06 21:03 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20081006165943.GG8203@spearce.org>
On Mon, Oct 06, 2008 at 09:59:43AM -0700, Shawn O. Pearce wrote:
> * jk/diff-convfilter (Sun Oct 5 17:43:45 2008 -0400) 4 commits
> - diff: add filter for converting binary to text
> - diff: introduce diff.<driver>.binary
> - diff: unify external diff and funcname parsing code
> - t4012: use test_cmp instead of cmp
>
> A general cleanup on how diff drivers are implemented. Its still
> missing documentation updates and tests but doesn't break anything
> current as far as I can tell. It needs more review before it can
> be slated for 'next'.
I should note, too, that this is in direct competition with Matthieu
Moy's "Implementation of a textconv filter for easy custom diff" posted
about a week ago. So if you are reviewing this series, please review
both and decide which you think is more sensible.
-Peff
^ permalink raw reply
* Re: [StGit PATCH 4/6] Add 1.0 TODO items from recent discussion by private mail
From: Catalin Marinas @ 2008-10-06 20:50 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20081005160151.19886.30979.stgit@yoghurt>
2008/10/5 Karl Hasselström <kha@treskal.com>:
> +- Convert the remaining commands to the new infrastructure.
> +
> +- Go through the design of the UI and make sure there's nothing hard
> + to change in there that we'll regret later.
> +
> +- Write a user guide. I'm thinking a document on the order of 10-30
> + pages that'll explain why one would want to use StGit, and how.
> +
> +- Make sure the rest of the documentation is in good shape.
Actually, at least for these kind of things we should still keep this
file. We could drop it after 1.0.
--
Catalin
^ permalink raw reply
* Re: What's cooking in git/spearce.git (Oct 2008, #01; Mon, 06)
From: Stephen Haberman @ 2008-10-06 20:48 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20081006165943.GG8203@spearce.org>
> * sh/maint-rebase3 (Sun Oct 5 23:26:52 2008 -0500) 1 commit
> - rebase--interactive: fix parent rewriting for dropped commits
>
> A replacement for sh/maint-intrebase. Its in pu because I have
> gotten 3 different versions of this patch, two of them posted a
> full 4 days after I merged the first version into next. I felt
> burned by the patch author for not keeping up with my tree, so I'm
> not merging the patch to next.
>
> At this point its going to sit in pu until Junio comes back.
> I think the topic needs a few more days to settle to see if the
> patch author is going to submit any more revisions.
All fair enough.
Sorry for not keeping up with your tree--this was the first I heard my
first patch had made it into next, so I kept submitting new ones not
really knowing why they weren't generating feedback. My fault for not
actively looking into the pu/next thing--I'll know what to do next time.
Thanks,
Stephen
^ permalink raw reply
* Re: [StGit PATCH 2/6] Remove TODO items that have already been addressed
From: Catalin Marinas @ 2008-10-06 20:43 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20081005160140.19886.92390.stgit@yoghurt>
2008/10/5 Karl Hasselström <kha@treskal.com>:
> TODO | 9 ---------
> 1 files changed, 0 insertions(+), 9 deletions(-)
We could also drop this file entirely since we have a Tasks list on
the gna.org project page.
--
Catalin
^ permalink raw reply
* Re: [msysGit] [FYI][PATCH] Customizing the WinGit installer
From: Heikki Orsila @ 2008-10-06 20:11 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Linus Torvalds, Jakub Narebski, Petr Baudis, msysgit, git
In-Reply-To: <alpine.DEB.1.00.0810061959280.22125@pacific.mpi-cbg.de.mpi-cbg.de>
On Mon, Oct 06, 2008 at 08:01:38PM +0200, Johannes Schindelin wrote:
> It is not a bug. It is a message that tells the Windows user that this is
> GPLed software, and that they are free to copy it. Windows users (and
> developers on Windows are more of users than developers) are often not
> aware of that fact.
>
> That is the reason why many Open Source projects do not bother on Linux,
> but do bother on Windows.
It's pointless and harmful to present any non-relevant information for
users. I simply hate programs that waste my precious seconds. I want it
NOW, not soon. Developers can tell the license if they want to
distribute it, but users do not need it at all.
> So I guess we simply disagree here.
I disagree VIOLENTLY with you. I've been utterly struck with this
Windows crap here.. I spent a day installing stupid trivial software
and answering pointless EULAs. I REALLY REALLY hate extra questions..
This is my 20th reboot..
--
Heikki Orsila
heikki.orsila@iki.fi
http://www.iki.fi/shd
^ permalink raw reply
* Re: how to restrict commit for a repo
From: Miklos Vajna @ 2008-10-06 19:58 UTC (permalink / raw)
To: Dilip M; +Cc: Git Mailing List
In-Reply-To: <c94f8e120810061012p29210247sfd3c1b3c05e871ee@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 569 bytes --]
On Mon, Oct 06, 2008 at 10:42:06PM +0530, Dilip M <dilipm79@gmail.com> wrote:
> > Have you seen contrib/hooks/update-paranoid?
>
> Miklos, I am totally new to this tool ( don't know SVN too).
That's good, since your mind is clear yet. :)
> Can you please consider giving some more info...or guiding me to some
> good links...:)
>
> Thanks in advance..
In general, I would suggest reading the user manual and everyday.txt,
both are under Documentation/.
Second, read man githooks, and then you'll understand how to use the
mentioned hook.
HTH
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Use "git_config_string" to simplify "remote.c" code in "handle_config"
From: David Bryson @ 2008-10-06 19:53 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0810061610400.22125@pacific.mpi-cbg.de.mpi-cbg.de>
Johannes,
On Mon, Oct 06, 2008 at 04:13:17PM +0200 or thereabouts, Johannes Schindelin wrote:
> Hi,
>
> On Thu, 2 Oct 2008, David Bryson wrote:
>
> >
> > Signed-off-by: David Bryson <david@statichacks.org>
> >
> > I tried to keep with the naming/coding conventions that I found in
> > remote.c. Feedback welcome.
> >
> > ---
>
> Usually this comment goes after the --- but other than that, the form is
> as perfect as you can wish for.
I see, still trying to remember all the little tricks for proper
submission, thanks.
> > @@ -314,15 +315,15 @@ static int handle_config(const char *key, const char *value, void *cb)
> > return 0;
> > branch = make_branch(name, subkey - name);
> > if (!strcmp(subkey, ".remote")) {
> > - if (!value)
> > - return config_error_nonbool(key);
> > - branch->remote_name = xstrdup(value);
> > + if (git_config_string(&v, key, value) )
> > + return -1;
> > + branch->remote_name = v;
>
> What is the reason not to write
>
> if (git_config_string(&branch->remote_name, key, value))
> return -1;
The only reason is it did not come to mind ;-) But it does make the
statement somewhat clearer.
> ? (Also note that we do not like the space between the two closing
> parentheses.)
An oversight to be sure and not intentional, I read the CodingGuidelines
very carefully ;-)
Dave
^ permalink raw reply
* Re: [PATCH] Use "git_config_string" to simplify "remote.c" code in "handle_config"
From: David Bryson @ 2008-10-06 19:49 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0810041546w5eed8859vd8266bb66425ebd3@mail.gmail.com>
On Sun, Oct 05, 2008 at 12:46:29AM +0200 or thereabouts, Alex Riesen wrote:
> >
>
> You can redeclare of the variable in the contexts where
> it is used and not even rename it: it is close to its users then.
I'm not sure I understand entirely, care to elaborate a bit more ?
^ permalink raw reply
* Re: [msysGit] [FYI][PATCH] Customizing the WinGit installer
From: Linus Torvalds @ 2008-10-06 19:47 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jakub Narebski, Petr Baudis, msysgit, git
In-Reply-To: <alpine.DEB.1.00.0810061959280.22125@pacific.mpi-cbg.de.mpi-cbg.de>
On Mon, 6 Oct 2008, Johannes Schindelin wrote:
>
> It is not a bug.
If it's unwanted functionality, that's a bug. That's kind of the whole
(and only) difference between "bug" and "feature". Do people want it?
And Petr made it clear that he didn't want it. And I can certainly
understand why - so it's not just some confused user. As such, it's
clearly not a feature, and is clearly a bug.
Linus
^ permalink raw reply
* Re: [QGIT PATCH] Rework the commit confirmation box a bit
From: Marco Costalba @ 2008-10-06 19:03 UTC (permalink / raw)
To: Abdelrazak Younes; +Cc: Git Mailing List
In-Reply-To: <48E9D659.1090503@lyx.org>
On Mon, Oct 6, 2008 at 11:11 AM, Abdelrazak Younes <younes@lyx.org> wrote:
> The problem was that the dialog was too big for my whenever too many files
> were changed. Now, the list of changed files is only shown whenever they are
> less than 20; otherwise it is shown in the detailed text accessible though
> the 'Show Detail' button.
> ---
Thanks,
patch applied and pushed.
Marco
^ permalink raw reply
* Re: git://oss.sgi.com broke
From: Daniel Barkalow @ 2008-10-06 17:58 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andrew Morton, xfs-masters, git
In-Reply-To: <alpine.LFD.2.00.0810061005540.3208@nehalem.linux-foundation.org>
On Mon, 6 Oct 2008, Linus Torvalds wrote:
> On Fri, 3 Oct 2008, Andrew Morton wrote:
> >
> > y:/usr/src/git26> git --version
> > git version 1.5.6.rc0
> >
> > y:/usr/src/git26> cat .git/branches/git-xfs
> > git://oss.sgi.com:8090/xfs/xfs-2.6.git#master
>
> Hmm. That's the really old and deprecated branch format.
>
> I'm getting a "Connection refused" from oss.sgi.com, and I think there's
> possibly something broken there, but quite independently of that, maybe we
> can try to teach you another way to set up remote branches?
>
> In your .git/config file, use
>
> [remote "git-xfs"]
> url = git://oss.sgi.com:8090/xfs/xfs-2.6.git
> fetch = master
>
> because the whole .git/branches/<branch-name> thing is fairly deprecated,
> and cannot handle some things that the .git/config file format can (like
> saying where to fetch into, or how to push back etc).
I think Andrew convinced us to undeprecate that format, because he wants
to be able to configure each branch with one line in a separate file. In
any case, remote.c takes care of these things seemlessly.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [msysGit] [FYI][PATCH] Customizing the WinGit installer
From: Robin Burchell @ 2008-10-06 17:54 UTC (permalink / raw)
To: Linus Torvalds
Cc: Johannes Schindelin, Jakub Narebski, Petr Baudis, msysgit, git
In-Reply-To: <alpine.LFD.2.00.0810061031380.3208@nehalem.linux-foundation.org>
On Mon, Oct 6, 2008 at 6:34 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> I absolutely detest clicking through EULA's or other self-serving crap. I
> hate software that bothers me with their license details. Nobody reads
> those things anyway, and an extra click or an extra window I didn't ask
> for - _especially_ in open source software - is just a bug.
>
I'll just jump in and add my (admittedly inexperienced) $0.02 -
namely, my confusion as to why the GPL would be displayed in place of
a EULA when ...it's not a EULA. It is not about how the software may
be used at all:
Activities other than copying, distribution and modification are not
covered by this License; they are outside its scope. The act of running
the Program is not restricted, and the output from the Program is
covered only if its contents constitute a work based on the Program
(independent of having been made by running the Program). Whether that
is true depends on what the Program does.
^ permalink raw reply
* Re: [FYI][PATCH] Customizing the WinGit installer
From: Johannes Schindelin @ 2008-10-06 18:01 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jakub Narebski, Petr Baudis, msysgit, git
In-Reply-To: <alpine.LFD.2.00.0810061031380.3208@nehalem.linux-foundation.org>
Hi,
On Mon, 6 Oct 2008, Linus Torvalds wrote:
> On Mon, 6 Oct 2008, Johannes Schindelin wrote:
> >
> > Well, I consider it a courtesy to the msysGit people to leave it where
> > it is.
>
> Umm. I consider it to be UNACCEPTABLY STUPID to claim "courtesy" if it
> actually makes something just more irritating to users.
>
> I absolutely detest clicking through EULA's or other self-serving crap.
> I hate software that bothers me with their license details. Nobody reads
> those things anyway, and an extra click or an extra window I didn't ask
> for - _especially_ in open source software - is just a bug.
>
> Bugs aren't "courtesy". Not to the user, and certainly not to the
> developer.
It is not a bug. It is a message that tells the Windows user that this is
GPLed software, and that they are free to copy it. Windows users (and
developers on Windows are more of users than developers) are often not
aware of that fact.
That is the reason why many Open Source projects do not bother on Linux,
but do bother on Windows.
So I guess we simply disagree here.
Ciao,
Dscho
^ permalink raw reply
* Re: [msysGit] [FYI][PATCH] Customizing the WinGit installer
From: Bruce Stephens @ 2008-10-06 17:51 UTC (permalink / raw)
To: Linus Torvalds
Cc: Johannes Schindelin, Jakub Narebski, Petr Baudis, msysgit, git
In-Reply-To: <alpine.LFD.2.00.0810061031380.3208@nehalem.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
[...]
> I absolutely detest clicking through EULA's or other self-serving crap. I
> hate software that bothers me with their license details. Nobody reads
> those things anyway, and an extra click or an extra window I didn't ask
> for - _especially_ in open source software - is just a bug.
By coincidence, I recently bought an Asus EEE PC which comes with a
Quick Use Guide whose first step on Launching First Run Wizard reads
"Toggle 'I agree with this license' and click 'Next' to continue.",
very sensibly not bothering to suggest that the user read the license.
[...]
^ permalink raw reply
* [PATCH] Do not use errno when pread() returns 0
From: Samuel Tardieu @ 2008-10-06 17:28 UTC (permalink / raw)
To: git; +Cc: Samuel Tardieu
If we use pread() while at the end of the file, it will return 0, which is
not an error from the operating system point of view. In this case, errno
has not been set and must not be used.
Signed-off-by: Samuel Tardieu <sam@rfc1149.net>
---
index-pack.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/index-pack.c b/index-pack.c
index 2e4c088..73860bf 100644
--- a/index-pack.c
+++ b/index-pack.c
@@ -365,8 +365,11 @@ static void *get_data_from_pack(struct object_entry *obj)
data = src;
do {
ssize_t n = pread(pack_fd, data + rdy, len - rdy, from + rdy);
- if (n <= 0)
+ if (n < 0)
die("cannot pread pack file: %s", strerror(errno));
+ if (!n)
+ die("premature end of pack file, %lu bytes missing",
+ len - rdy);
rdy += n;
} while (rdy < len);
data = xmalloc(obj->size);
--
tg: (395ff9b..) short-pread (depends on: spearce/next)
^ permalink raw reply related
* Re: [xfs-masters] git://oss.sgi.com broke
From: Samuel Tardieu @ 2008-10-06 17:37 UTC (permalink / raw)
To: Russell Cattelan; +Cc: xfs-masters, git, Andrew Morton, Daniel Berlin
In-Reply-To: <48EA3D63.2080703@thebarn.com>
[resent, Daniel's address got mangled on my side]
>>>>> "Russell" == Russell Cattelan <cattelan@thebarn.com> writes:
Russell> I'm using 1.5.6.4 on my remote client and it did a clone
Russell> just fine. Ahh but indeed a fetch failed ... But it also
Russell> fails with using v1.5.6.5 of git-daemon ...
I also have an error with "fetch" (while it works with "clone") on
git://gcc.gnu.org/git/gcc.git
The error I get is from index-pack.c:get_index_from_pack():
% git fetch
remote: Generating pack...
remote: Done counting 6230 objects.
remote: Result has 3856 objects.
remote: Deltifying 3856 objects...
remote: 100% (3856/3856) done
remote: Total 3856 (delta 3234), reused 7 (delta 5)
Receiving objects: 100% (3856/3856), 6.99 MiB | 50 KiB/s, done.
fatal: premature end of pack file, 1858 bytes missing
fatal: index-pack failed
(the "premature end of pack file" message comes from a patch I
just submitted, before that it was a bogus error message due
to an improper use of errno)
I am using the latest spearce/next GIT, I don't know what version
runs on the FSF machine. Daniel, do you have this info?
Sam
--
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/
^ permalink raw reply
* Re: [xfs-masters] git://oss.sgi.com broke
From: Samuel Tardieu @ 2008-10-06 17:34 UTC (permalink / raw)
To: Russell Cattelan; +Cc: xfs-masters, git, Andrew Morton, Daniel Berlin
In-Reply-To: <48EA3D63.2080703@thebarn.com>
>>>>> "Russell" == Russell Cattelan <cattelan@thebarn.com> writes:
Russell> I'm using 1.5.6.4 on my remote client and it did a clone
Russell> just fine. Ahh but indeed a fetch failed ... But it also
Russell> fails with using v1.5.6.5 of git-daemon ...
I also have an error with "fetch" (while it works with "clone") on
git://gcc.gnu.org/git/gcc.git
The error I get is from index-pack.c:get_index_from_pack():
% git fetch
remote: Generating pack...
remote: Done counting 6230 objects.
remote: Result has 3856 objects.
remote: Deltifying 3856 objects...
remote: 100% (3856/3856) done
remote: Total 3856 (delta 3234), reused 7 (delta 5)
Receiving objects: 100% (3856/3856), 6.99 MiB | 50 KiB/s, done.
fatal: premature end of pack file, 1858 bytes missing
fatal: index-pack failed
(the "premature end of pack file" message comes from a patch I
just submitted, before that it was a bogus error message due
to an improper use of errno)
I am using the latest spearce/next GIT, I don't know what version
runs on the FSF machine. Daniel, do you have this info?
Sam
--
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/
^ permalink raw reply
* Re: [msysGit] [FYI][PATCH] Customizing the WinGit installer
From: Linus Torvalds @ 2008-10-06 17:34 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jakub Narebski, Petr Baudis, msysgit, git
In-Reply-To: <alpine.DEB.1.00.0810061810360.22125@pacific.mpi-cbg.de.mpi-cbg.de>
On Mon, 6 Oct 2008, Johannes Schindelin wrote:
>
> Well, I consider it a courtesy to the msysGit people to leave it where
> it is.
Umm. I consider it to be UNACCEPTABLY STUPID to claim "courtesy" if it
actually makes something just more irritating to users.
I absolutely detest clicking through EULA's or other self-serving crap. I
hate software that bothers me with their license details. Nobody reads
those things anyway, and an extra click or an extra window I didn't ask
for - _especially_ in open source software - is just a bug.
Bugs aren't "courtesy". Not to the user, and certainly not to the
developer.
Linus
^ permalink raw reply
* Re: [xfs-masters] git://oss.sgi.com broke
From: Russell Cattelan @ 2008-10-06 17:30 UTC (permalink / raw)
To: xfs-masters; +Cc: git, Andrew Morton
In-Reply-To: <20081003121903.6c9a7ebc.akpm@linux-foundation.org>
Andrew Morton wrote:
> y:/usr/src/git26> git --version
> git version 1.5.6.rc0
>
> y:/usr/src/git26> cat .git/branches/git-xfs
> git://oss.sgi.com:8090/xfs/xfs-2.6.git#master
>
> y:/usr/src/git26> git-fetch git-xfs
> remote: usage: git-pack-objects [{ -q | --progress | --all-progress }]
> remote: [--max-pack-size=N] [--local] [--incremental]
> remote: [--window=N] [-remote: -window-memory=N] [--depth=N]
> remote: [--no-reuse-delta] [--no-reuse-object] [--delta-base-offset]
> remote: [--threads=N] [--non-empty] [--reremote: vs [--unpacked | --all]*] [--reflog]
> remote: [--stdout | base-name] [--keep-unreachable] [<ref-list | <object-list]
> remote: aborting due to possible repository corruption on the remote side.
> fatal: protocol error: bad pack header
>
> It was OK yesterday.
>
> (cc'ing the git list in case this is an faq?)
>
> The last two error messages there look wrong/misleading?
>
>
Ok not sure exactly what was wrong but it looks like there was some
confusion
with older git bits still install on oss.
I manually cleaned everything from the system and reinstalled git from a
fresh "make rpm" rpm.
Please try your pull again and see if the problem is resolved.
-Russell
^ 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