* Re: git build on msys fails (and fix)
From: dhruva @ 2008-12-01 12:02 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Git, msysGit
In-Reply-To: <4933D10E.6020706@viscovery.net>
Hello,
On Mon, Dec 1, 2008 at 5:27 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> dhruva schrieb:
>> I got the mob branch and I fail to see the Makefile. I decided to
>> just add the pthread related files and push so that someone could
>> build, I get authentication failures. I had tried to push perl
>> sometime back when I had a gcc compiler perl (before strawberry perl)
>> and had similar problems. I am fairly certain I am doing something
>> wrong but cannot figure it out!
>
> msysgit.git is *not* a git.git clone; it is the MSYS/MinGW environment to
> build git.git on Windows.
>
> You should apply the steps 1. to 4. that you mentioned in an earlier mail
> and push the result; but you cannot apply 5. because that is a change to
> git itself.
I request someone to just pull the archive I have placed just this
time, I will try again for other patches. I will create a clone in a
separate folder for msysgit and keep it ready. Unknowingly, I just
cleaned up the remote and lost all the changes I had pulled earlier :(
-dhruva
--
Contents reflect my personal views only!
^ permalink raw reply
* Re: git build on msys fails (and fix)
From: Johannes Sixt @ 2008-12-01 11:57 UTC (permalink / raw)
To: dhruvakm; +Cc: Git, msysGit
In-Reply-To: <e3f230850812010348w793e17c2q6ab92cf9b2c04972@mail.gmail.com>
dhruva schrieb:
> I got the mob branch and I fail to see the Makefile. I decided to
> just add the pthread related files and push so that someone could
> build, I get authentication failures. I had tried to push perl
> sometime back when I had a gcc compiler perl (before strawberry perl)
> and had similar problems. I am fairly certain I am doing something
> wrong but cannot figure it out!
msysgit.git is *not* a git.git clone; it is the MSYS/MinGW environment to
build git.git on Windows.
You should apply the steps 1. to 4. that you mentioned in an earlier mail
and push the result; but you cannot apply 5. because that is a change to
git itself.
-- Hannes
^ permalink raw reply
* Re: Is rebase always destructive?
From: Johan Herland @ 2008-12-01 11:54 UTC (permalink / raw)
To: git; +Cc: Csaba Henk
In-Reply-To: <slrngj7jch.2srb.csaba-ml@beastie.creo.hu>
On Monday 01 December 2008, Csaba Henk wrote:
> Hi,
>
> When doing a rebase, I can find a number of reasons for which one
> might feel like to preserve the rebased branch (that is, perform an
> operation which copies the branch over a new base, not moves).
>
> - For example, a successful rebase doesn't necessarily mean that the
> code, as of the rebased branch, is consistent and compiles. That
> is, the rebase can be broken even if git can put things together
> diff-wise. In such a case I wouldn't be happy to lose the original
> instance of the branch.
>
> - Or I might want to build different versions of the program, and
> each version of it needs a given set of fixes (the same one). Then
> rebasing my bugfix branch is not a good idea, I'd much rather copy it
> over all those versions.
>
> I can't see any option for rebase which would yield this cp-like
> behaviour. Am I missing something? Or people don't need such a
> feature? (Then give me some LART please, my mind is not yet gittified
> enough to see why is this not needed.) Or is it usually done by other
> means, not rebase?
The operation you refer to as "cp-like" rebase behaviour is equivalent
to cherry-picking a range of commits. The latter has been discussed
extensively on this list, although I'm not sure any conclusion has been
reached.
I would also very much like to have this operation available in either
form ("git rebase --copy" or "git cherry-pick from..to"), although I'd
probably prefer the "git cherry-pick from..to" form.
Have fun! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: git build on msys fails (and fix)
From: dhruva @ 2008-12-01 11:48 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Git, msysGit
In-Reply-To: <e3f230850812010252i67d9846cg439b5951485ee7fe@mail.gmail.com>
Hi,
I got the mob branch and I fail to see the Makefile. I decided to
just add the pthread related files and push so that someone could
build, I get authentication failures. I had tried to push perl
sometime back when I had a gcc compiler perl (before strawberry perl)
and had similar problems. I am fairly certain I am doing something
wrong but cannot figure it out!
I have kept the minimum pthread files needed to build in the following location:
http://dhruvakm.googlepages.com/pthread.tar.gz (40kb)
You need to modify Makefile to add for MinGW:
THREADED_DELTA_SEARCH = YesPlease
-dhruva
--
Contents reflect my personal views only!
^ permalink raw reply
* Re: timestamps not git-cloned
From: Jakub Narebski @ 2008-12-01 11:44 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: jidanni, git
In-Reply-To: <4933A9B1.3070904@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> I see a lot of ranting but no patches from you. Since you're the one
> with the itch, why not just submit a patch and see if distro packagers
> start using it?
>
> Some words of advice though; Make it optional, or it'll be dropped on
> the floor. For bonus points, make it calculate timestamps only for a
> path-spec delimited set of files. That'll cut down expected runtime
> by a *huge* amount for something like the linux kernel.
I think the old idea of 'tree blame' (search archives) would be a good
interface for this feature... if you decide to write it.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Is rebase always destructive?
From: Csaba Henk @ 2008-12-01 11:41 UTC (permalink / raw)
To: git
Hi,
When doing a rebase, I can find a number of reasons for which one might
feel like to preserve the rebased branch (that is, perform an operation
which copies the branch over a new base, not moves).
- For example, a successful rebase doesn't necessarily mean that the
code, as of the rebased branch, is consistent and compiles. That is,
the rebase can be broken even if git can put things together diff-wise.
In such a case I wouldn't be happy to lose the original instance of
the branch.
- Or I might want to build different versions of the program, and each
version of it needs a given set of fixes (the same one). Then rebasing
my bugfix branch is not a good idea, I'd much rather copy it over all
those versions.
I can't see any option for rebase which would yield this cp-like
behaviour. Am I missing something? Or people don't need such a feature?
(Then give me some LART please, my mind is not yet gittified enough to
see why is this not needed.) Or is it usually done by other means, not
rebase?
Thanks
Csaba
^ permalink raw reply
* Re: A better approach to diffing and merging
From: Jakub Narebski @ 2008-12-01 11:41 UTC (permalink / raw)
To: Ian Clarke; +Cc: git
In-Reply-To: <823242bd0811291012g15c4d442qa5d7afc9cc762b20@mail.gmail.com>
"Ian Clarke" <ian.clarke@gmail.com> writes:
> Apologies if this is off-topic, but I recently had an idea for a
> better way to do diffs and merging which I thought may be of interest
> to those on this list.
[...]
> While I'm no merging expert, it seems that most merging algorithms do
> it on a line-by-line basis, treating source code as nothing but a list
> of lines of text. It got me thinking, what if the merging algorithm
> understood the structure of the source code it is trying to merge?
>
> So the idea is this:
>
> Provide the merge algorithm with the grammar of the programming
> language, perhaps in the form of a Bison grammar file, or some other
> standardized way to represent a grammar.
>
> The merge algorithm then uses this to parse the files to be diffed
> and/or merged into trees, and then the diff and merge are treated as
> operations on these trees. These operations may include creating,
> deleting, or moving nodes or branches, renaming nodes, etc. There has
> been quite a bit (pdf) of academic research on this topic, although I
> haven't yet found off-the-shelf code that will do what we need.
First, as Brian Dessent said it would be hard to generate parse tree
in the presence of compile-time configuration (using preprocessor
in C/C++, but in principle this applies to programs in any language;
not only you have to know conditionals, but also compile options).
And for dynamic languages you would have to take care about
self-modifying programs.
Second, from what I understand we have _good_, established algorithms
for merging sequences (which includes sequence of lines, or sequence
of words), and for merging special kinds of trees that are
representations of directory structure. I haven't read link to
mentioned research, but I think that it is still unproven research,
and not something well established and well tested.
Third, it would require embedding knowledge about various programming
languages (including C, shell, Perl, TeX) and document formats
(including XML, HTML, AsciiDoc) in version control system...
> Still, it shouldn't be terribly hard to implement.
So, try to provide us with some proof-of-concept patches, then.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: two questions about the format of loose object
From: Jakub Narebski @ 2008-12-01 11:32 UTC (permalink / raw)
To: Liu Yubao; +Cc: Junio C Hamano, git list
In-Reply-To: <4933AE55.2090007@gmail.com>
Liu Yubao <yubao.liu@gmail.com> writes:
> Junio C Hamano wrote:
> > Liu Yubao <yubao.liu@gmail.com> writes:
> >
> > A hint for understanding why loose objects are compressed is that
> > packfiles were invented much later in the history of git.
> >
> > These are both good questions, and it might have made a difference if they
> > were posed in early April 2005.
> >
> > At this point, the plain and clear answer to both of these "Why not"
> > questions is "because that is the way it is and it is costly to change
> > them now in thousands of repositories people use every day."
[...]
>
> Thanks for your explanation, but I doubt if it's too costly to change the
> format of loose object, after all this doesn't change the format of pack
> file and affect git-pull/fetch of old git client.
[...]
> cons:
>
> * old git client can't read loose objects in new format
> (People degrade git rarely and old git can read pack files
> generated by new git, so it's not a big problem)
You forgot about "dumb" protocols, namely HTTP and (deprecated) rsync
(and IIRC also FTP), which doesn't generate packfiles, and would get
loose object in format intelligible for old clients.
IIRC this was main reason why core.legacyHeaders = false was abandoned.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 0/2] gitweb: patch view
From: Jakub Narebski @ 2008-12-01 11:02 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Petr Baudis, Junio C Hamano
In-Reply-To: <cb7bb73a0811301710i383105b0j80b8dbf4563f93ca@mail.gmail.com>
On Mon, 1 December 2008, Giuseppe Bilotta wrote:
> On Mon, Dec 1, 2008 at 1:45 AM, Jakub Narebski <jnareb@gmail.com> wrote:
>> On Sun, 30 Nov 2008, Giuseppe Bilotta wrote:
>>> On Sun, Nov 30, 2008 at 2:06 AM, Jakub Narebski <jnareb@gmail.com> wrote:
>>>> On Sat, 29 Nov 2008, Giuseppe Bilotta wrote:
>>>
>>>> By the way, we still might want to add somehow X-Git-Url and X-Git-Tag
>>>> headers later to 'patch' ('patchset') output format.
>>>
>>> Yeah, I've been thinking about it, but I couldn't find an easy and
>>> robust way to do it. Plus, should we add them for each patch, or just
>>> once for the whole patchset?
>>
>> True, that is a complication. Perhaps they should be added only for
>> single patch?
>
> Although that's rather easy to implement technically, it also creates
> some kind of inconsistency.
Well, it is problem also from technical point of view. Currently we can
just stream (dump) git-format-patch output to browser (not forgetting
adding '--encoding=utf8' if it is not used already), and do not need
to have markers between commits. It is very simple code, which is its
own advantage.
>From theoretical point of view corrected X-Git-Tag functioning as
a kind of ref marker but for the raw (text/plain) output could be added
for each end every patch, so there would be no inconsistency for _this_
extra header.
I don't know what can be done about X-Git-URL.
>>> Considering I think commitdiff is ugly and long, you can guess my
>>> opinion on format_patch 8-P. 'patchset' might be a good candidate,
>>> considering it's what it does when both hash_parent and hash are
>>> given.
>>
>> True, 'patchset' might be even better, especially that it hints
>> what it does for a range a..b (not diff of endpoints, but series
>> of patches).
>
> Good, I'll rename it.
I just don't know if it would be best name. Perhaps 'patches' would
be better?
[...]
>>> * diff(_plain): do what commitdiff(_plain) currently does for
>>> parent..hash views, modulo something to be discussed for commit
>>> messages (a shortlog rather maybe?)
>>
>> Equivalent of "git diff" (or "git diff-tree").
>>
>> Diffstat, or dirstat might be a good idea. Shortlog... I am not sure.
>> Diff is about endpoints, and they can be in reverse, too.
>>
>> There is a problem how to denote endpoints.
>
> Hm? Doesn't parent..hash work? Or are you talking about something else?
Errr... I meant here for the user, not for gitweb. To somehow denote
before patch itself the endpoints. Just like for diff _for_ a commit
we have commit message denoting :-).
>>> * patch[set?][_plain?]: format-patch style output (maybe with option
>>> for HTML stuff too)
>>
>> Equivalent of "git format-patch".
>>
>> Actually the HTML format would be more like "git log -p", so perhaps
>> that could be handled simply as a version of 'log' view (perhaps via
>> @extra_options aka 'opt' parameter).
>
> This is starting to get complicated ... I'm not sure how far in this I
> can go with this patchset, so for the time being I'll probably just
> stick to refining the (plain) patchset feature.
What I meant here is that it would be IMHO enough to have 'patch' view
(or whatever it ends up named) be raw format / plain/text format only,
and leave HTML equivalent for extra options/extra format to 'log' view.
[...]
>>>>> The second patch exposes it from commitdiff view (obviosly), but also
>>>>> from shortlog view, when less than 16 patches are begin shown.
>>>>
>>>> Why this nonconfigurable limit?
>>>
>>> Because the patch was actually a quick hack for the proof of concept
>>> 8-) I wasn't even sure the patch idea would have been worth it (as
>>> opposed to email-izing commitdiff_plain).
>>
>> Ah.
>>
>> Well, we might want to impose some limit to avoid generating and sending
>> patchset for a whole history. Perhaps to page size (100), or some similar
>> number?
>
> The reason why I chose 16 is that (1) it's a rather commonly used
> 'small' number across gitweb and (2) it's a rather acceptable
> 'universal' upper limit for patchsets. There _are_ a few patchbombs
> that considerably overtake that limit, but observe that this limit is
> not an arbitrary limit on patchsets generated by the 'patchset' view,
> but only a condition for which a link is generated from shortlog view.
I see.
> We may want to have TWO limits here: one is the absolute maximum limit
> to the number of patches dumped in a patchset (to prevent DoS attacks
> by repeated requests of the whole history), and the other one is the
> limit for autogenerated patchset links.
A pageful (100 commits) as hard limit against DoS attacks?
[...]
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: git build on msys fails (and fix)
From: dhruva @ 2008-12-01 10:52 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Git, msysGit
In-Reply-To: <e3f230850812010132g48fcdf2fm46310b601990e51d@mail.gmail.com>
Hi,
On Mon, Dec 1, 2008 at 3:02 PM, dhruva <dhruvakm@gmail.com> wrote:
> On Mon, Dec 1, 2008 at 2:36 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
>> dhruva schrieb:
>>> Hello,
>>> I build git on msys environment regularly. With the recent changes to
>>> add cache preload facility (commit ID:
>>> 671c9b7e315db89081cc69f83a8f405e4aca37bc) brings in dependency on
>>> pthreads. This is not available in the msys distribution which was
>>> part of the git build distro. I installed libpthread for mingw to get
>>> the related headers and libraries. I had to make some minor changes to
>>> libpthread installation. I copied the 'setjmp.h' from my other mingw
>>> installation and had to had edit it to remove some mingw specific
>>> macros.
>>>
>>> @:/e/users/dhruva/stub/repo/git/git
>>> [520]$ diff -u /e/tools/gnu/include/setjmp.h /mingw/include/setjmp.h
>>> --- /e/tools/gnu/include/setjmp.h Sun Oct 5 04:01:15 2008
>>> +++ /mingw/include/setjmp.h Sun Nov 30 16:18:00 2008
>>> @@ -36,7 +36,7 @@
>>> * The function provided by CRTDLL which appears to do the actual work
>>> * of setjmp.
>>> */
>>> -_CRTIMP int __cdecl __MINGW_NOTHROW _setjmp (jmp_buf);
>>> +int __cdecl _setjmp (jmp_buf);
>>>
>>> #define setjmp(x) _setjmp(x)
>>>
>>> @@ -44,7 +44,7 @@
>>> * Return to the last setjmp call and act as if setjmp had returned
>>> * nVal (which had better be non-zero!).
>>> */
>>> -_CRTIMP void __cdecl __MINGW_NOTHROW longjmp (jmp_buf, int)
>>> __MINGW_ATTRIB_NORETURN;
>>> +void __cdecl longjmp (jmp_buf, int);
>>>
>>> #ifdef __cplusplus
>>> }
>>>
>>> Also,
>>> had to copy a pthread library with a dfferent name to the standard name:
>>> $cp libpthreadGC2.a libpthread.a
>>>
>>> The build went fine and am using the new binaries.
>>
>> Would you please push your addition to the mob branch of
>> git://repo.or.cz/msysgit.git? The push URL is repo.or.cz:/srv/git/msysgit.git
>>
>> (But notice that some commits are on the mob branch currently that are not
>> in any other branch; hence, you better build on top of them so that they
>> are not lost when you push to mob.)
>>
>> -- Hannes
>>
>
> I am not using git from the above repo. I am using it from:
> git://git2.kernel.org/pub/scm/git/git.git
>
> I will clone from the repo you have mentioned and push my changes,
> that will take some time. I have started the clone now...
I added a new remote to pull changes from the msys repo and it is
taking a long time (bad network). In the meantime for some wanting to
play:
1. I downloaded pthreads for windows from:
ftp://sourceware.org/pub/pthreads-win32/pthreads-w32-2-8-0-release.exe
2. Extracted and copied the headers, libraries to
msysgit/mingw/include and msysgit/mingw/lib folders. I made a copy of
DLL in bin folder too so that runtime can pick it.
3. I copied msysgit/mingw/lib/libpthreadGC2.a as
msysgit/mingw/lib/libpthread.a as -lpthread needs a lib with that name
4. Copied the setjmp.h header referred by pthread.h from my native
mingw installation and modified it (refer my earlier mail). The
modified contents of the new file that needs to go under
msysgit/mingw/include/setjmp.h:
/*
* setjmp.h
* This file has no copyright assigned and is placed in the Public Domain.
* This file is a part of the mingw-runtime package.
* No warranty is given; refer to the file DISCLAIMER within the package.
*
* Declarations supporting setjmp and longjump, a method for avoiding
* the normal function call return sequence. (Bleah!)
*
*/
#ifndef _SETJMP_H_
#define _SETJMP_H_
/* All the headers include this file. */
#include <_mingw.h>
#ifndef RC_INVOKED
#ifdef __cplusplus
extern "C" {
#endif
/*
* The buffer used by setjmp to store the information used by longjmp
* to perform it's evil goto-like work. The size of this buffer was
* determined through experimentation; it's contents are a mystery.
* NOTE: This was determined on an i386 (actually a Pentium). The
* contents could be different on an Alpha or something else.
*/
#define _JBLEN 16
#define _JBTYPE int
typedef _JBTYPE jmp_buf[_JBLEN];
/*
* The function provided by CRTDLL which appears to do the actual work
* of setjmp.
*/
int __cdecl _setjmp (jmp_buf);
#define setjmp(x) _setjmp(x)
/*
* Return to the last setjmp call and act as if setjmp had returned
* nVal (which had better be non-zero!).
*/
void __cdecl longjmp (jmp_buf, int);
#ifdef __cplusplus
}
#endif
#endif /* Not RC_INVOKED */
#endif /* Not _SETJMP_H_ */
5. I modified git Makefile as:
diff --git a/Makefile b/Makefile
index 649cfb8..71f995d 100644
--- a/Makefile
+++ b/Makefile
@@ -776,6 +776,7 @@ ifneq (,$(findstring MINGW,$(uname_S)))
NO_PERL_MAKEMAKER = YesPlease
NO_POSIX_ONLY_PROGRAMS = YesPlease
NO_ST_BLOCKS_IN_STRUCT_STAT = YesPlease
+ THREADED_DELTA_SEARCH = YesPlease
COMPAT_CFLAGS += -D__USE_MINGW_ACCESS -DNOGDI -Icompat
-Icompat/regex -Icompat/fnmatch
COMPAT_CFLAGS += -DSNPRINTF_SIZE_CORR=1
COMPAT_CFLAGS += -DSTRIP_EXTENSION=\".exe\"
-dhruva
--
Contents reflect my personal views only!
^ permalink raw reply related
* Re: how to hide some branches
From: Pascal Obry @ 2008-12-01 10:20 UTC (permalink / raw)
To: Pete Harlan; +Cc: git list
In-Reply-To: <4932F2FD.9030603@pcharlan.com>
Pete Harlan a écrit :
>>From a suggestion by Jakub Narebski, I use an alias "lb" that shows
> the most recently-active 8 branches:
>
> for-each-ref --format='%(refname:short)' \
> --sort=-authordate --count=8 refs/heads/
Thanks, I like this one. Probably the best approach to me.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
* Re: [PATCH] Makefile: introduce NO_PTHREADS
From: Mike Ralphson @ 2008-12-01 9:57 UTC (permalink / raw)
To: Johannes Sixt, Junio C Hamano; +Cc: Git Mailing List, Linus Torvalds, dhruvakm
In-Reply-To: <4933A058.3050101@viscovery.net>
2008/12/1 Johannes Sixt <j.sixt@viscovery.net>
>
> Johannes Sixt schrieb:
> > Mike Ralphson schrieb:
> >> 2008/11/17 Johannes Sixt <j.sixt@viscovery.net>:
> >>> Mike Ralphson schrieb:
> >>>> 2008/11/15 Linus Torvalds <torvalds@linux-foundation.org>:
> >>>>> On Sat, 15 Nov 2008, Junio C Hamano wrote:
> >>>>>> This introduces make variable NO_PTHREADS for platforms that lack the
> >>>>>> support for pthreads library or people who do not want to use it for
> >>>>>> whatever reason. When defined, it makes the multi-threaded index
> >>>>>> preloading into a no-op, and also disables threaded delta searching by
> >>>>>> pack-objects.
> >>>>> ...
> >
> > :-( Maybe NO_PTHREADS is indeed the safer choice? I'm not going to dig
> > into this today, though. (I'm on AIX 4.3.something.)
> >
> >>> BTW, this needs to be squashed in, because we don't have pthreads on Windows:
> >>>...
>
> you said you would resend the patch, but I think you forgot about it.
> Would you do that now, please?
Not forgotten, just slow. The current state I believe is we should
have NO_PTHREADS for AIX < v5. THREADED_DELTA_SEARCH and the new
multi-threaded lstat are actually ok on AIX 5.3 at least - though I
couldn't see any performance benefit on my repo / hardware
combination.
But now after dhruva's observation I'm unsure what the desired change
is for Windows. 8-(
Mike
^ permalink raw reply
* Re: A better approach to diffing and merging
From: Karl Hasselström @ 2008-12-01 9:54 UTC (permalink / raw)
To: Brian Dessent; +Cc: Ian Clarke, git
In-Reply-To: <4931F2DC.CE9B1E35@dessent.net>
On 2008-11-29 17:56:44 -0800, Brian Dessent wrote:
> Ian Clarke wrote:
>
> > Provide the merge algorithm with the grammar of the programming
> > language, perhaps in the form of a Bison grammar file, or some
> > other standardized way to represent a grammar.
>
> There's a huge flaw in that approach for C/C++: in order to parse
> C/C++ you have to first preprocess it -- consider the twisty mazes
> that #ifdef/#else/#endif can create. But in order to preprocess
> source code you need a whole heap of extra information that is not
> in the repository (or if it is, cannot be automatically extracted.)
But it's probably not necessary to parse the input files exactly. All
you have to do is parse it well enough that the diff of the parse
trees is interesting.
And in practice, you'd probably also generate the "normal" diff, and
then fall back to that one if the parse tree diff was worse.
> The idea may have value for langauges that are easy to parse and do
> not have all this preprocessor cruft, but I just don't see how it
> would be able to provide anything useful for non-trivial changes to
> real world C/C++, which require human eyes to decipher.
I think it could work. But there would be quite a bit of heuristics
involved to get the "approximate" parsing right, so I'm pretty sure
there's no way to find out without actually trying to build the thing.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* [ANNOUNCE] GIT 1.6.1-rc1
From: Junio C Hamano @ 2008-12-01 9:54 UTC (permalink / raw)
To: git
As promised, 1.6.1-rc1 is found at the usual places, and from here on we
will be in bugfixes-only mode until 1.6.1 final. I also think there
probably are a few more patches on 'next' (e.g. the first patch on the
gp/gitweb-feature topic, which is a pure bugfix) that haven't merged to
'master' but should.
^ permalink raw reply
* Re: git build on msys fails (and fix)
From: dhruva @ 2008-12-01 9:32 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Git, msysGit
In-Reply-To: <4933A922.7080300@viscovery.net>
On Mon, Dec 1, 2008 at 2:36 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> dhruva schrieb:
>> Hello,
>> I build git on msys environment regularly. With the recent changes to
>> add cache preload facility (commit ID:
>> 671c9b7e315db89081cc69f83a8f405e4aca37bc) brings in dependency on
>> pthreads. This is not available in the msys distribution which was
>> part of the git build distro. I installed libpthread for mingw to get
>> the related headers and libraries. I had to make some minor changes to
>> libpthread installation. I copied the 'setjmp.h' from my other mingw
>> installation and had to had edit it to remove some mingw specific
>> macros.
>>
>> @:/e/users/dhruva/stub/repo/git/git
>> [520]$ diff -u /e/tools/gnu/include/setjmp.h /mingw/include/setjmp.h
>> --- /e/tools/gnu/include/setjmp.h Sun Oct 5 04:01:15 2008
>> +++ /mingw/include/setjmp.h Sun Nov 30 16:18:00 2008
>> @@ -36,7 +36,7 @@
>> * The function provided by CRTDLL which appears to do the actual work
>> * of setjmp.
>> */
>> -_CRTIMP int __cdecl __MINGW_NOTHROW _setjmp (jmp_buf);
>> +int __cdecl _setjmp (jmp_buf);
>>
>> #define setjmp(x) _setjmp(x)
>>
>> @@ -44,7 +44,7 @@
>> * Return to the last setjmp call and act as if setjmp had returned
>> * nVal (which had better be non-zero!).
>> */
>> -_CRTIMP void __cdecl __MINGW_NOTHROW longjmp (jmp_buf, int)
>> __MINGW_ATTRIB_NORETURN;
>> +void __cdecl longjmp (jmp_buf, int);
>>
>> #ifdef __cplusplus
>> }
>>
>> Also,
>> had to copy a pthread library with a dfferent name to the standard name:
>> $cp libpthreadGC2.a libpthread.a
>>
>> The build went fine and am using the new binaries.
>
> Would you please push your addition to the mob branch of
> git://repo.or.cz/msysgit.git? The push URL is repo.or.cz:/srv/git/msysgit.git
>
> (But notice that some commits are on the mob branch currently that are not
> in any other branch; hence, you better build on top of them so that they
> are not lost when you push to mob.)
>
> -- Hannes
>
I am not using git from the above repo. I am using it from:
git://git2.kernel.org/pub/scm/git/git.git
I will clone from the repo you have mentioned and push my changes,
that will take some time. I have started the clone now...
-dhruva
--
Contents reflect my personal views only!
^ permalink raw reply
* Re: Overwriting untracked working tree files (when identical)
From: Andreas Ericsson @ 2008-12-01 9:28 UTC (permalink / raw)
To: Asheesh Laroia; +Cc: git
In-Reply-To: <alpine.DEB.2.00.0811290018340.15382@vellum.laroia.net>
Asheesh Laroia wrote:
> I was using git earlier today and got the familiar error:
>
> "Untracked working tree file 'filename’ would be overwritten by merge"
>
> As it happens, I know that filename in my local filesystem and filename
> in the remote git branch have the same contents.
>
> Would it make sense for git to check for this possibility, and if the
> working tree file is the same as the file being merged in with that
> filename, allow the overwrite?
>
That depends. git uses the work-tree to merge things. If one file is the
same as that about to be written, it *might* make sense to clobber it,
but what if it's identical to the expected merge-result? Git can't know
that, but it's almost certainly a much saner approach than the other
case, where the merge can go wahoonie-shaped at a later stage and thus
require conflict resolution (which might well end up with the user
getting fed up and doing "git reset --hard" to start over). For such
cases, the file would appear to disappear, and that's a bad thing.
Overall, I think it's best if this is left as-is. The code would be too
complex for the gain it provides.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: two questions about the format of loose object
From: Liu Yubao @ 2008-12-01 9:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git list
In-Reply-To: <7voczws3np.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Liu Yubao <yubao.liu@gmail.com> writes:
>
>
> A hint for understanding why loose objects are compressed is that
> packfiles were invented much later in the history of git.
>
> These are both good questions, and it might have made a difference if they
> were posed in early April 2005.
>
> At this point, the plain and clear answer to both of these "Why not"
> questions is "because that is the way it is and it is costly to change
> them now in thousands of repositories people use every day."
>
> In other words, it is not interesting anymore to raise these questions
> now, especially as a suggestion to change the system, unless they are
> accompanied by arguments that convinces everybody that the cost of such a
> change outweighs the benefits, and a clear transition plans how to upgrade
> everybody's existing repositories without any pain.
>
Thanks for your explanation, but I doubt if it's too costly to change the
format of loose object, after all this doesn't change the format of pack
file and affect git-pull/fetch of old git client.
I ask the "why not" questions because I doubt if I miss some technical points
that the change isn't worth at all in fact.
If no severe technical problem will occur, I think it's worth breaking
*forward* compatibility for better performance and I'm willing to implement
it.
Some cons and pros.
cons:
* old git client can't read loose objects in new format
(People degrade git rarely and old git can read pack files
generated by new git, so it's not a big problem)
pros:
* avoid compressing and uncompressing loose objects that are likely
frequently used when you are coding/merging
* share loose objects among multipe git processes
* the new code path is simpler although we will have more code paths for
compatibility
Best regards,
Liu Yubao
^ permalink raw reply
* Re: [PATCH 3/3] git add --intent-to-add: do not let an empty blob committed by accident
From: Junio C Hamano @ 2008-12-01 9:24 UTC (permalink / raw)
To: Jeff King; +Cc: Shawn O. Pearce, Johannes Schindelin, git
In-Reply-To: <20081130191444.GC10981@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Fri, Nov 28, 2008 at 07:56:34PM -0800, Junio C Hamano wrote:
> ...
>> case WRITE_TREE_UNMERGED_INDEX:
>> - die("%s: error building trees; the index is unmerged?", me);
>> + die("%s: error building trees", me);
>
> This caught me by surprise while reading, but I assume the rationale is
> "now there is a new, different reason not to be able to build the trees,
> so our guess is less likely to be correct". I wonder if we can do better
> by actually passing out a more exact error value (though it looks like
> we will already have said "foo: not added yet" by that point anyway, so
> maybe it is just pointless to say more).
The places that detect the "unmerged" (and then newly added "intent-only")
entries already have issued error messages in the codepath that leads to
this error.
>> diff --git a/t/t3701-add-interactive.sh b/t/t3701-add-interactive.sh
>
> Why in t3701?
Good question. Brain fart, perhaps.
^ permalink raw reply
* Re: more merge strategies : feature request
From: Andreas Ericsson @ 2008-12-01 9:18 UTC (permalink / raw)
To: Caleb Cushing; +Cc: git
In-Reply-To: <81bfc67a0811290848m6cb219c0y71a7266001096f2d@mail.gmail.com>
Caleb Cushing wrote:
> conflict: this strategy would always resolve in a merge conflict
> allowing you to use git mergetool to piece the files back together.
>
> no-overwrite: if a change from the branch being merged in would
> overwrite something in the current branch don't merge it. (I think it
> needs a better name)
>
If you could come up with use-cases where each would be useful, I
think you'd have a much easier time to gain acceptance for your
suggestions. Right now, you're saying "I want a red button" but
you're not explaining what it's for.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: timestamps not git-cloned
From: Andreas Ericsson @ 2008-12-01 9:09 UTC (permalink / raw)
To: jidanni; +Cc: git
In-Reply-To: <87k5am3uom.fsf@jidanni.org>
jidanni@jidanni.org wrote:
> Well all I know is from the simple user who does e.g.,
> # aptitude install linux-doc-2.6.26
> # ls -lt /usr/share/doc/linux-doc-2.6.26/Documentation/
> he thinks "gosh, can't tell what's new vs. what hasn't changed in years".
>
They won't be able to do that anyway, since a spelling correction
would update the timestamp anyway. The only way of finding out if
there are *content* changes (which is really what matters) is to
use some sort of history-browser for those documents. Git is good
for that. The sort of people who really need to know when the docs
change can be exptected to have a higher technical knowledge than
the end-users, so it's not too much to ask that they use such a
history browsing tool to find out what's new (or simply "diff").
Either way, timestamps on documents are a very poor way of finding
out when something really changed.
> OK, now I know why this is tolerable upstream: they all use git.
>
> But for the lowly user downstream who gets what git-archive produces,
> it seems like a step backwards: "who threw away the timestamp of when
> each file was last changed?".
>
> OK, http://git.or.cz/gitwiki/ContentLimitations says this is by design.
>
> And OK, thinking "file by file" is old fashioned, I read. The non-git
> end user should just get used to reading ChangeLogs, if any, and stop
> doing ls -lt.
>
> But you must admit, /usr/share/doc/linux-doc-2.6.26/Documentation/
> etc. are aimed for reading without git.
>
Well, /usr/bin/less doesn't require git to function, so I fail to see
what the fuzz is all about.
> Anyways, if just in case any individual file modification time
> information can still be pried from the 40 byte IDs or whatever, I
> would suggest using it by default in git-archive at least, and maybe
> even git-clone etc.
>
It can, but it's a fairly expensive operation, tracking each files
SHA1 backwards in time to see when the commit was done that last made
any changes to it. It's not something you want to do for an archive
containing 26K files. Trust me on this.
> Just letting you know my 'valuable first impressions'. I expect once I
> start smoking more of this "git" stuff, I too will become comfortably
> numb to aforementioned lowly user problem, so you would never know
> unless I hereby first told you before it was too late.
I see a lot of ranting but no patches from you. Since you're the one
with the itch, why not just submit a patch and see if distro packagers
start using it?
Some words of advice though; Make it optional, or it'll be dropped on
the floor. For bonus points, make it calculate timestamps only for a
path-spec delimited set of files. That'll cut down expected runtime
by a *huge* amount for something like the linux kernel.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git build on msys fails (and fix)
From: Johannes Sixt @ 2008-12-01 9:06 UTC (permalink / raw)
To: dhruva; +Cc: Git, msysGit
In-Reply-To: <e3f230850811300302y68992b9doe4897d97d513de3a@mail.gmail.com>
dhruva schrieb:
> Hello,
> I build git on msys environment regularly. With the recent changes to
> add cache preload facility (commit ID:
> 671c9b7e315db89081cc69f83a8f405e4aca37bc) brings in dependency on
> pthreads. This is not available in the msys distribution which was
> part of the git build distro. I installed libpthread for mingw to get
> the related headers and libraries. I had to make some minor changes to
> libpthread installation. I copied the 'setjmp.h' from my other mingw
> installation and had to had edit it to remove some mingw specific
> macros.
>
> @:/e/users/dhruva/stub/repo/git/git
> [520]$ diff -u /e/tools/gnu/include/setjmp.h /mingw/include/setjmp.h
> --- /e/tools/gnu/include/setjmp.h Sun Oct 5 04:01:15 2008
> +++ /mingw/include/setjmp.h Sun Nov 30 16:18:00 2008
> @@ -36,7 +36,7 @@
> * The function provided by CRTDLL which appears to do the actual work
> * of setjmp.
> */
> -_CRTIMP int __cdecl __MINGW_NOTHROW _setjmp (jmp_buf);
> +int __cdecl _setjmp (jmp_buf);
>
> #define setjmp(x) _setjmp(x)
>
> @@ -44,7 +44,7 @@
> * Return to the last setjmp call and act as if setjmp had returned
> * nVal (which had better be non-zero!).
> */
> -_CRTIMP void __cdecl __MINGW_NOTHROW longjmp (jmp_buf, int)
> __MINGW_ATTRIB_NORETURN;
> +void __cdecl longjmp (jmp_buf, int);
>
> #ifdef __cplusplus
> }
>
> Also,
> had to copy a pthread library with a dfferent name to the standard name:
> $cp libpthreadGC2.a libpthread.a
>
> The build went fine and am using the new binaries.
Would you please push your addition to the mob branch of
git://repo.or.cz/msysgit.git? The push URL is repo.or.cz:/srv/git/msysgit.git
(But notice that some commits are on the mob branch currently that are not
in any other branch; hence, you better build on top of them so that they
are not lost when you push to mob.)
-- Hannes
^ permalink raw reply
* Re: [PATCH] Makefile: introduce NO_PTHREADS
From: dhruva @ 2008-12-01 8:48 UTC (permalink / raw)
To: Johannes Sixt
Cc: Mike Ralphson, Junio C Hamano, Git Mailing List, Linus Torvalds
In-Reply-To: <4933A058.3050101@viscovery.net>
Hello,
I am able to compile and use git by defining THREADED_DELTA_SEARCH
and copying setjmp.h from mingw (www.mingw.org) to msys include folder
with small changes to it. If it does add value, we should try to
enable this by default.
-dhruva
On Mon, Dec 1, 2008 at 1:59 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> Johannes Sixt schrieb:
>> Mike Ralphson schrieb:
>>> 2008/11/17 Johannes Sixt <j.sixt@viscovery.net>:
>>>> Mike Ralphson schrieb:
>>>>> 2008/11/15 Linus Torvalds <torvalds@linux-foundation.org>:
>>>>>> On Sat, 15 Nov 2008, Junio C Hamano wrote:
>>>>>>> This introduces make variable NO_PTHREADS for platforms that lack the
>>>>>>> support for pthreads library or people who do not want to use it for
>>>>>>> whatever reason. When defined, it makes the multi-threaded index
>>>>>>> preloading into a no-op, and also disables threaded delta searching by
>>>>>>> pack-objects.
>>>>>> Ack. Makes sense.
>>>>> I'd be minded to make this the default on AIX to keep the prerequisite
>>>>> list as small as possible, then people can opt-in for the performance
>>>>> benefits if required.
>>>> Is pthreads not a standard shipment on AIX? I would set NO_PTHREADS only
>>>> if we know in advance that there are many installations without pthreads.
>>>> (And I don't know what the situation is.)
>>> I should have dug a bit further, it seems to be present on my 5.3
>>> machines but I still need to determine whether it got installed by
>>> default. Either way it must need some other link flags...
>>
>> I tried compiling with THREADED_DELTA_SEARCH=Yes, and it fails with
>>
>> CC builtin-pack-objects.o
>> In file included from /usr/include/sys/pri.h:29,
>> from /usr/include/sys/sched.h:38,
>> from /usr/include/sched.h:52,
>> from /usr/include/pthread.h:43,
>> from builtin-pack-objects.c:22:
>> /usr/include/sys/proc.h:203: parse error before "crid_t"
>> /usr/include/sys/proc.h:212: parse error before "p_class"
>> /usr/include/sys/proc.h:355: parse error before '}' token
>>
>> :-( Maybe NO_PTHREADS is indeed the safer choice? I'm not going to dig
>> into this today, though. (I'm on AIX 4.3.something.)
>>
>>>> BTW, this needs to be squashed in, because we don't have pthreads on Windows:
>>>>
>>>> diff --git a/Makefile b/Makefile
>>>> index ffc9531..3a30b8c 100644
>>>> --- a/Makefile
>>>> +++ b/Makefile
>>>> @@ -769,6 +769,7 @@ ifneq (,$(findstring MINGW,$(uname_S)))
>>>> NO_STRCASESTR = YesPlease
>>>> NO_STRLCPY = YesPlease
>>>> NO_MEMMEM = YesPlease
>>>> + NO_PTHREADS = YesPlease
>>>> NEEDS_LIBICONV = YesPlease
>>>> OLD_ICONV = YesPlease
>>>> NO_C99_FORMAT = YesPlease
>>>>
>>> Ta. Ok to add your S-o-B on a squashed patch?
>>
>> Sure. Use this address please:
>>
>> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
>
> Mike,
>
> you said you would resend the patch, but I think you forgot about it.
> Would you do that now, please?
>
> -- Hannes
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Contents reflect my personal views only!
^ permalink raw reply
* Re: [PATCH] Makefile: introduce NO_PTHREADS
From: Johannes Sixt @ 2008-12-01 8:29 UTC (permalink / raw)
To: Mike Ralphson; +Cc: Junio C Hamano, Git Mailing List, Linus Torvalds
In-Reply-To: <4921548E.6070802@viscovery.net>
Johannes Sixt schrieb:
> Mike Ralphson schrieb:
>> 2008/11/17 Johannes Sixt <j.sixt@viscovery.net>:
>>> Mike Ralphson schrieb:
>>>> 2008/11/15 Linus Torvalds <torvalds@linux-foundation.org>:
>>>>> On Sat, 15 Nov 2008, Junio C Hamano wrote:
>>>>>> This introduces make variable NO_PTHREADS for platforms that lack the
>>>>>> support for pthreads library or people who do not want to use it for
>>>>>> whatever reason. When defined, it makes the multi-threaded index
>>>>>> preloading into a no-op, and also disables threaded delta searching by
>>>>>> pack-objects.
>>>>> Ack. Makes sense.
>>>> I'd be minded to make this the default on AIX to keep the prerequisite
>>>> list as small as possible, then people can opt-in for the performance
>>>> benefits if required.
>>> Is pthreads not a standard shipment on AIX? I would set NO_PTHREADS only
>>> if we know in advance that there are many installations without pthreads.
>>> (And I don't know what the situation is.)
>> I should have dug a bit further, it seems to be present on my 5.3
>> machines but I still need to determine whether it got installed by
>> default. Either way it must need some other link flags...
>
> I tried compiling with THREADED_DELTA_SEARCH=Yes, and it fails with
>
> CC builtin-pack-objects.o
> In file included from /usr/include/sys/pri.h:29,
> from /usr/include/sys/sched.h:38,
> from /usr/include/sched.h:52,
> from /usr/include/pthread.h:43,
> from builtin-pack-objects.c:22:
> /usr/include/sys/proc.h:203: parse error before "crid_t"
> /usr/include/sys/proc.h:212: parse error before "p_class"
> /usr/include/sys/proc.h:355: parse error before '}' token
>
> :-( Maybe NO_PTHREADS is indeed the safer choice? I'm not going to dig
> into this today, though. (I'm on AIX 4.3.something.)
>
>>> BTW, this needs to be squashed in, because we don't have pthreads on Windows:
>>>
>>> diff --git a/Makefile b/Makefile
>>> index ffc9531..3a30b8c 100644
>>> --- a/Makefile
>>> +++ b/Makefile
>>> @@ -769,6 +769,7 @@ ifneq (,$(findstring MINGW,$(uname_S)))
>>> NO_STRCASESTR = YesPlease
>>> NO_STRLCPY = YesPlease
>>> NO_MEMMEM = YesPlease
>>> + NO_PTHREADS = YesPlease
>>> NEEDS_LIBICONV = YesPlease
>>> OLD_ICONV = YesPlease
>>> NO_C99_FORMAT = YesPlease
>>>
>> Ta. Ok to add your S-o-B on a squashed patch?
>
> Sure. Use this address please:
>
> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Mike,
you said you would resend the patch, but I think you forgot about it.
Would you do that now, please?
-- Hannes
^ permalink raw reply
* Re: two questions about the format of loose object
From: Junio C Hamano @ 2008-12-01 8:25 UTC (permalink / raw)
To: Liu Yubao; +Cc: git list
In-Reply-To: <493399B7.5000505@gmail.com>
Liu Yubao <yubao.liu@gmail.com> writes:
> In current implementation the loose objects are compressed:
>
> loose object = deflate(typename + <space> + size + '\0' + data)
>
> In sha1_file.c:unpack_sha1_file():
> 1) unpack_sha1_header() inflates first 8KB
> 2) parse_sha1_header() gets object's size
> 3) unpack_sha1_reset() allocates a (1+size) bytes buffer and
> copy the first 8KB without header to it.
>
> * Question 1:
> Why not ...
> * Question 2:
> Why not ...
A hint for understanding why loose objects are compressed is that
packfiles were invented much later in the history of git.
These are both good questions, and it might have made a difference if they
were posed in early April 2005.
At this point, the plain and clear answer to both of these "Why not"
questions is "because that is the way it is and it is costly to change
them now in thousands of repositories people use every day."
In other words, it is not interesting anymore to raise these questions
now, especially as a suggestion to change the system, unless they are
accompanied by arguments that convinces everybody that the cost of such a
change outweighs the benefits, and a clear transition plans how to upgrade
everybody's existing repositories without any pain.
^ permalink raw reply
* Re: how to hide some branches
From: Peter Krefting @ 2008-12-01 8:01 UTC (permalink / raw)
To: Pascal Obry; +Cc: git list
In-Reply-To: <493261C9.4040608@obry.net>
Pascal Obry:
> I'd like to hide some (not removing them).
> Is there a solution for this?
git branch --no-merged
shows only the branches that has not been merged into your current
working branch. That might be one solution.
I don't know if it is possible to set it as a default option, but I
would also appreciate such a feature.
I use the "git branch --merged" to move away merged branches into a
different "namespace" (branch "a" becomes "merged/a"):
for branch in $(git branch --merged master | egrep -v 'merged|master');
do
git branch -m "$branch" "merged/$branch"
done
--
\\// Peter - http://www.softwolves.pp.se/
^ 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