* Re: [PATCH] compat/mingw.c: MSVC build must use ANSI Win32 API's
From: Johannes Sixt @ 2009-09-28 8:10 UTC (permalink / raw)
To: Michael Wookey; +Cc: Marius Storm-Olsen, git, Shawn O. Pearce
In-Reply-To: <d2e97e800909280047l5da52ffdxd86589cda4542f46@mail.gmail.com>
Michael Wookey schrieb:
> 2009/9/28 Johannes Sixt <j.sixt@viscovery.net>:
>> Michael Wookey schrieb:
>>> 2009/9/22 Marius Storm-Olsen <mstormo@gmail.com>:
>>>> Michael Wookey said the following on 22.09.2009 11:17:
>>>>> 2009/9/22 Marius Storm-Olsen <mstormo@gmail.com>:
>>>>>> Michael, how are you trying to compile git? With the IDE or the
>>>>>> GNU Make? Which version of MSVC? If you use the IDE, can you make
>>>>>> sure it doesn't contain the UNICODE define in the compiler
>>>>>> section of the properties of the projects?
>>>>> I'm using the VS 2008 Professional IDE (the solution doesn't open
>>>>> in VS 2005). I made no changes to the build settings. In the
>>>>> Preprocessor section of the project, UNICODE is defined.
>>>> Were these projects generated with the Vcproj generator in
>>>> contrib/buildsystem, with the Qmake generator, or the projects from Frank's
>>>> repo?
>>> The project was generated from the vcproj generator in
>>> contrib/buildsystem from git.git/master.
>> What's the status of this?
>
> I was hoping that this gets included into git.git because it fixes a
> real issue with MSVC builds. Since Junio is away, perhaps Shawn can
> take the patch into his interim tree?
>
> BTW - would you mind giving this patch an ack?
As I said, the patch looks fine. However, in the commit message you say:
MSVC builds define UNICODE which results in the "WIDE" variation of
Win32 API's being used.
But since Marius has built the code without your patch, this justification
must be incomplete. I won't give a formal Ack until this is clarified.
Please work with Marius to figure out why your build uses UNICODE while
Marius's doesn't.
-- Hannes
^ permalink raw reply
* Re: [PATCH] compat/mingw.c: MSVC build must use ANSI Win32 API's
From: Michael Wookey @ 2009-09-28 7:47 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Marius Storm-Olsen, git, Shawn O. Pearce
In-Reply-To: <4AC05BA5.4050106@viscovery.net>
2009/9/28 Johannes Sixt <j.sixt@viscovery.net>:
> Michael Wookey schrieb:
>> 2009/9/22 Marius Storm-Olsen <mstormo@gmail.com>:
>>> Michael Wookey said the following on 22.09.2009 11:17:
>>>> 2009/9/22 Marius Storm-Olsen <mstormo@gmail.com>:
>>>>> Michael, how are you trying to compile git? With the IDE or the
>>>>> GNU Make? Which version of MSVC? If you use the IDE, can you make
>>>>> sure it doesn't contain the UNICODE define in the compiler
>>>>> section of the properties of the projects?
>>>> I'm using the VS 2008 Professional IDE (the solution doesn't open
>>>> in VS 2005). I made no changes to the build settings. In the
>>>> Preprocessor section of the project, UNICODE is defined.
>>> Were these projects generated with the Vcproj generator in
>>> contrib/buildsystem, with the Qmake generator, or the projects from Frank's
>>> repo?
>>
>> The project was generated from the vcproj generator in
>> contrib/buildsystem from git.git/master.
>
> What's the status of this?
I was hoping that this gets included into git.git because it fixes a
real issue with MSVC builds. Since Junio is away, perhaps Shawn can
take the patch into his interim tree?
BTW - would you mind giving this patch an ack?
> Do Sebastian Schuberth's patches
> http://article.gmane.org/gmane.comp.version-control.msysgit/7152
> http://article.gmane.org/gmane.comp.version-control.msysgit/7153
>
> make a difference?
Unfortunately, no. Those patches do not make a difference.
^ permalink raw reply
* Re: gitweb atom feeds broken (on repo.or.cz only?)
From: Tay Ray Chuan @ 2009-09-28 7:23 UTC (permalink / raw)
To: Sebastian Pipping; +Cc: git, Petr Baudis, Robert Buchholz
In-Reply-To: <4ABFA258.8020301@hartwork.org>
Hi,
On Mon, Sep 28, 2009 at 1:35 AM, Sebastian Pipping
<webmaster@hartwork.org> wrote:
> i noticed that the atom feeds generated by repo.or.cz's gitweb (e.g.
> [1]) show no content in firefox 3.5.2. this seems to be due to invalid
> xml in it as shown by running [1] through feedvalidator, results at [2].
it's a case of a misspelled tag. In the <author> tag <B> is closed by a </b>.
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: [PATCH] git-am: force egrep to use correct characters set
From: Jeff King @ 2009-09-28 7:16 UTC (permalink / raw)
To: Christian Himpel; +Cc: git
In-Reply-To: <20090928065519.GA24773@lamagra.informatik.uni-ulm.de>
On Mon, Sep 28, 2009 at 08:55:19AM +0200, Christian Himpel wrote:
> > Do you happen to know a charset in which this is a problem, just for
> > reference?
>
> No, I don't know any charset with stray ascii-chars. I just listened
> attentively, when I read the part about the mixed alphabet characters in
> the grep(1) manpage.
>
> I did some quick checks just now. It seems the characters (' ' to '~')
> are in any locale, offered by glibc, at the same place.
>
> Maybe, we can just leave the charset as it is and ignore this patch,
> until someone complains.
Thanks for looking into it. My question was more of a "how bad is this,
and should we be fixing these other callsites, too". But I think 0-7 is
probably a pretty safe range in any charset.
Usually with portability issues, I am inclined to say "wait for a
problem", as we try to code to match actual reality instead of
documentation or standards. But in this case, we are unlikely to test
with strange charsets (or even know which strange charsets exist;
checking what's in glibc is reasonable, but I have no idea what else is
out there in other countries), and that the resulting bug would be
subtle and hard to find, it probably makes sense to be a little
defensive.
-Peff
^ permalink raw reply
* Re: [PATCH] git-am: force egrep to use correct characters set
From: Christian Himpel @ 2009-09-28 6:55 UTC (permalink / raw)
To: Jeff King; +Cc: Christian Himpel, git
In-Reply-To: <20090927074015.GB15393@coredump.intra.peff.net>
On Sun, Sep 27, 2009 at 03:40:15AM -0400, Jeff King wrote:
> On Fri, Sep 25, 2009 at 06:43:20PM +0200, Christian Himpel wrote:
>
> > According to egrep(1) the US-ASCII table is used when LC_ALL=C is set.
> > We do not rely here on the LC_ALL value we get from the environment.
>
> Hmm. Probably makes sense here, as it is a wide enough range that it may
> pick up other stray non-ascii characters in other charsets (though as
> the manpage notes, the likely thing is to pick up A-Z along with a-z,
> which is OK here as we encompass both in our range).
>
> There are two other calls to egrep with brackets (both in
> git-submodule.sh), but they are just [0-7], which is presumably OK in
> just about any charset.
>
> Do you happen to know a charset in which this is a problem, just for
> reference?
No, I don't know any charset with stray ascii-chars. I just listened
attentively, when I read the part about the mixed alphabet characters in
the grep(1) manpage.
I did some quick checks just now. It seems the characters (' ' to '~')
are in any locale, offered by glibc, at the same place.
Maybe, we can just leave the charset as it is and ignore this patch,
until someone complains.
Regards,
chressie
>
> -Peff
^ permalink raw reply
* Re: [PATCH] compat/mingw.c: MSVC build must use ANSI Win32 API's
From: Johannes Sixt @ 2009-09-28 6:45 UTC (permalink / raw)
To: Michael Wookey; +Cc: Marius Storm-Olsen, git
In-Reply-To: <d2e97e800909220254sc677abeia220c19f6ef5bd28@mail.gmail.com>
Michael Wookey schrieb:
> 2009/9/22 Marius Storm-Olsen <mstormo@gmail.com>:
>> Michael Wookey said the following on 22.09.2009 11:17:
>>> 2009/9/22 Marius Storm-Olsen <mstormo@gmail.com>:
>>>> Michael, how are you trying to compile git? With the IDE or the
>>>> GNU Make? Which version of MSVC? If you use the IDE, can you make
>>>> sure it doesn't contain the UNICODE define in the compiler
>>>> section of the properties of the projects?
>>> I'm using the VS 2008 Professional IDE (the solution doesn't open
>>> in VS 2005). I made no changes to the build settings. In the
>>> Preprocessor section of the project, UNICODE is defined.
>> Were these projects generated with the Vcproj generator in
>> contrib/buildsystem, with the Qmake generator, or the projects from Frank's
>> repo?
>
> The project was generated from the vcproj generator in
> contrib/buildsystem from git.git/master.
What's the status of this? Do Sebastian Schuberth's patches
http://article.gmane.org/gmane.comp.version-control.msysgit/7152
http://article.gmane.org/gmane.comp.version-control.msysgit/7153
make a difference?
-- Hannes
^ permalink raw reply
* Re: [JGIT PATCH 7/9] removing eclipse project files
From: Robin Rosenberg @ 2009-09-28 6:42 UTC (permalink / raw)
To: Jonas Fonseca
Cc: Mark Struberg, MatthiasSohn, git@vger.kernel.org,
spearce@spearce.org
In-Reply-To: <200909280834.45360.robin.rosenberg.lists@dewire.com>
Oh, dear. I should not reply to e-mail this time of the day....
^ permalink raw reply
* Re: [JGIT PATCH 7/9] removing eclipse project files
From: Robin Rosenberg @ 2009-09-28 6:34 UTC (permalink / raw)
To: Jonas Fonseca
Cc: Mark Struberg, MatthiasSohn, git@vger.kernel.org,
spearce@spearce.org
In-Reply-To: <2c6b72b30909271921y4b191f1fo42b1ffb5f08d3468@mail.gmail.com>
måndag 28 september 2009 04:21:36 skrev Jonas Fonseca <jonas.fonseca@gmail.com>:
> On Sun, Sep 27, 2009 at 15:52, Robin Rosenberg
> <robin.rosenberg.lists@dewire.com> wrote:
> > lördag 26 september 2009 22:10:16 skrev Mark Struberg <struberg@yahoo.de>:
> >> And there is a lot more which imho cannot be set for a project. So checking in the xml sounds like it is way more powerful isn't? And we would have this
> >
> > For JGit, not really. Everything that is not project settings should be left as the default. The only reason is tool constraints. I'm not well versed
> > enough to tell what neatbeans does here.
>
> It is my impression that NetBeans has far better integration with
> maven. In terms of code formatting NetBeans supports
> exporting/importing project specific settings, but I have never
> personally used that.
I was thinking of (project) settings for controlling warnings/errors and formatting.
-- robin
^ permalink raw reply
* Re: git clone sending unneeded objects
From: Nicolas Pitre @ 2009-09-28 4:18 UTC (permalink / raw)
To: Jason Merrill; +Cc: Shawn O. Pearce, Matthieu Moy, git, Hin-Tak Leung
In-Reply-To: <4ABEEB92.1020307@redhat.com>
On Sun, 27 Sep 2009, Jason Merrill wrote:
> On 09/26/2009 10:04 PM, Shawn O. Pearce wrote:
> > Actually, if those refs have not changed, quickfetch should kick in
> > and realize that all 410610 objects are reachable locally without
> > errors, permitting the client to avoid the object transfer.
> >
> > However, if *ANY* of those refs were to change to something you
> > don't actually have, quickfetch would fail, and we would need to
> > fetch all 410610 objects.
>
> Right. That seems unfortunate to me; couldn't fetch do a bit more checking
> before it decides to download the whole world again?
The quickfetch test could be turned into a filter so refs that are
already available locally could simply not be fetched on a per ref
basis. But that would be a rather expensive test which couldn't keep
its "quick" qualifier anymore, and so for a case that shouldn't have
happened normally anyway if git didn't have a bug with its clone
operation as I've explained already.
Nicolas
^ permalink raw reply
* Re: thoughts on a possible "pre-upload" hook
From: Sitaram Chamarty @ 2009-09-28 3:02 UTC (permalink / raw)
To: Adam Brewster; +Cc: git
In-Reply-To: <c376da900909271901q1667ecacw730ba5180a558f3b@mail.gmail.com>
On Mon, Sep 28, 2009 at 7:31 AM, Adam Brewster <adambrewster@gmail.com> wrote:
>> As git is used more and more in corporate-type environments, at some
>> point it becomes convenient to have *branches* (or more accurately,
>> refs) that are not readable. The simplest way to do this (from git's
>> point of view) is to allow a "pre-upload" hook, rather like the
>> "pre-receive" hook or "update" hook.
>>
>
> What's the benefit of this over using multiple repositories?
Over a long pm chat over irc with Ilari, I have come to the same
conclusion. I was hoping there would be some administrative
convenience or workflow convenience to doing this, but whether there
is or not is debatable, and even if there is, there are enough failure
modes to make this have a lot of caveats.
--
Sitaram
^ permalink raw reply
* [PATCH] git-gui: add small screen compatibility
From: Vietor Liu @ 2009-09-28 2:38 UTC (permalink / raw)
To: spearce; +Cc: git, Vietor Liu
The Netbook screen likes 800*480 1024*600. The git-gui's display
should be hide some buttons(ie 'Commit','Push') and 'Status bar'.
Signed-off-by: Vietor Liu <vietor.liu@gmail.com>
---
git-gui/git-gui.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-gui/git-gui.sh b/git-gui/git-gui.sh
index 14b92ba..6af9db2 100755
--- a/git-gui/git-gui.sh
+++ b/git-gui/git-gui.sh
@@ -3054,7 +3054,7 @@ frame .vpane.lower.diff.body
set ui_diff .vpane.lower.diff.body.t
text $ui_diff -background white -foreground black \
-borderwidth 0 \
- -width 80 -height 15 -wrap none \
+ -width 80 -height 0 -wrap none \
-font font_diff \
-xscrollcommand {.vpane.lower.diff.body.sbx set} \
-yscrollcommand {.vpane.lower.diff.body.sby set} \
--
1.6.5.rc2.dirty
^ permalink raw reply related
* Re: [JGIT PATCH 7/9] removing eclipse project files
From: Jonas Fonseca @ 2009-09-28 2:21 UTC (permalink / raw)
To: Robin Rosenberg
Cc: Mark Struberg, MatthiasSohn, git@vger.kernel.org,
spearce@spearce.org
In-Reply-To: <200909272152.33224.robin.rosenberg.lists@dewire.com>
On Sun, Sep 27, 2009 at 15:52, Robin Rosenberg
<robin.rosenberg.lists@dewire.com> wrote:
> lördag 26 september 2009 22:10:16 skrev Mark Struberg <struberg@yahoo.de>:
>> And there is a lot more which imho cannot be set for a project. So checking in the xml sounds like it is way more powerful isn't? And we would have this
>
> For JGit, not really. Everything that is not project settings should be left as the default. The only reason is tool constraints. I'm not well versed
> enough to tell what neatbeans does here.
It is my impression that NetBeans has far better integration with
maven. In terms of code formatting NetBeans supports
exporting/importing project specific settings, but I have never
personally used that.
--
Jonas Fonseca
^ permalink raw reply
* Re: thoughts on a possible "pre-upload" hook
From: Adam Brewster @ 2009-09-28 2:01 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: git
In-Reply-To: <2e24e5b90909220320rbd5fd1l40c7898656445232@mail.gmail.com>
> As git is used more and more in corporate-type environments, at some
> point it becomes convenient to have *branches* (or more accurately,
> refs) that are not readable. The simplest way to do this (from git's
> point of view) is to allow a "pre-upload" hook, rather like the
> "pre-receive" hook or "update" hook.
>
What's the benefit of this over using multiple repositories?
For a simple case where you have public branches and private branches,
you use public.git and private.git. A post-update hook in private.git
can automatically push the appropriate branches to public.git (in
which case they don't worry about public.git at all) or they can do it
themselves.
For more complex access control, give each sub-unit that needs to
share work a repository that's only readable by the members of that
unit. Each developer works in his own repo. When something is ready
for a wider audience, he pushes it to a team repo. When a team leader
has something that's ready to move up, he pushes to a group repo, etc.
--
Adam
^ permalink raw reply
* [PATCH] gitk: Refresh the index
From: Christian Jaeger @ 2009-09-27 23:43 UTC (permalink / raw)
To: git; +Cc: Christian Jaeger
If one or more tracked files changed non-tracked metadata like mtime,
gitk would report it as "Local uncommitted changes, not checked in to
index" even if no actual changes have been made. (Clicking on the
"Local uncommitted changes.." entry would show the file but without
any diff.)
This refreshes the index in readdiffindex to avoid this and make gitk
behave more like "git status" instead.
Signed-off-by: Christian Jaeger <chrjae@gmail.com>
---
gitk | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
* NOTE: I'm not subscribed to the mailing list. *
diff --git a/gitk b/gitk
index a0214b7..bb0e8e1 100755
--- a/gitk
+++ b/gitk
@@ -4898,6 +4898,7 @@ proc readdiffindex {fd serial inst} {
}
# now see if there are any local changes not checked in to the index
+ exec git update-index -q --refresh
set cmd "|git diff-files"
if {$vfilelimit($curview) ne {}} {
set cmd [concat $cmd -- $vfilelimit($curview)]
--
1.6.4.4
^ permalink raw reply related
* Re: [PATCH 7/6 (v4)] support for commit grafts, slight change to general mechanism
From: Nick Edelen @ 2009-09-27 22:44 UTC (permalink / raw)
To: Nick Edelen, Junio C Hamano, Nicolas Pitre, Johannes Schindelin,
Sam Vilain
In-Reply-To: <op.uzv4dyuotdk399@sirnot.private>
Adds support for graft commits in rev-cache (w/ test), and slightly alters
graft mechanism. Before, parse_commit() checked the graft list on every
commit. Now register_commit_graft() preemptively loads graft commits into
memory, and sets a new 'graft' flag in the object. This allows awareness of
the commits' medical history without searching a (normally private) array upon
each commit.
Signed-off-by: Nick Edelen <sirnot@gmail.com>
---
In my infinite wisdom, I had forgotten to actually load the graft file in the
mechanism change. This rectifies the error, fixing test t6001-rev-list-graft.
(this was the only test that I found rev-cache to break; if you find others
please tell me!)
builtin-rev-cache.c | 14 ++++++++++++--
commit.c | 27 +++++++++++++++++++++++++--
object.h | 3 ++-
rev-cache.c | 32 ++++++++++++++++++++++++++++++++
t/t6017-rev-cache-list.sh | 6 ++++++
5 files changed, 77 insertions(+), 5 deletions(-)
diff --git a/builtin-rev-cache.c b/builtin-rev-cache.c
index 4c1766d..b36bc39 100644
--- a/builtin-rev-cache.c
+++ b/builtin-rev-cache.c
@@ -102,8 +102,18 @@ static int test_rev_list(int argc, const char *argv[])
flags ^= UNINTERESTING;
else if (!strcmp(argv[i], "--objects"))
revs.tree_objects = revs.blob_objects = 1;
- else
- handle_revision_arg(argv[i], &revs, flags, 1);
+ else {
+ struct commit_graft graft;
+
+ if (argv[i][0] == ':') {
+ handle_revision_arg(argv[i] + 1, &revs, flags, 1);
+
+ hashcpy(graft.sha1, revs.pending.objects[revs.pending.nr - 1].item->sha1);
+ graft.nr_parent = -1;
+ register_commit_graft(&graft, 0);
+ } else
+ handle_revision_arg(argv[i], &revs, flags, 1);
+ }
}
setup_revisions(0, 0, &revs, 0);
diff --git a/commit.c b/commit.c
index b7485c4..dd0e3ca 100644
--- a/commit.c
+++ b/commit.c
@@ -99,6 +99,7 @@ static int commit_graft_pos(const unsigned char *sha1)
int register_commit_graft(struct commit_graft *graft, int ignore_dups)
{
+ struct commit *commit;
int pos = commit_graft_pos(graft->sha1);
if (0 <= pos) {
@@ -123,6 +124,12 @@ int register_commit_graft(struct commit_graft *graft, int ignore_dups)
(commit_graft_nr - pos - 1) *
sizeof(*commit_graft));
commit_graft[pos] = graft;
+
+ commit = lookup_commit(graft->sha1);
+ commit->object.graft = 1;
+ commit->object.parsed = 0;
+ parse_commit(commit); /* in case commit was already parsed */
+
return 0;
}
@@ -221,6 +228,7 @@ int write_shallow_commits(int fd, int use_pack_protocol)
int unregister_shallow(const unsigned char *sha1)
{
+ struct commit *commit;
int pos = commit_graft_pos(sha1);
if (pos < 0)
return -1;
@@ -229,6 +237,12 @@ int unregister_shallow(const unsigned char *sha1)
sizeof(struct commit_graft *)
* (commit_graft_nr - pos - 1));
commit_graft_nr--;
+
+ commit = lookup_commit(sha1);
+ commit->object.graft = 0;
+ commit->object.parsed = 0;
+ parse_commit(commit);
+
return 0;
}
@@ -255,7 +269,13 @@ int parse_commit_buffer(struct commit *item, void *buffer, unsigned long size)
while (pop_commit(pptr))
; /* clear anything from cache */
- graft = lookup_commit_graft(item->object.sha1);
+ /* make sure .graft flag is initialized */
+ prepare_commit_graft();
+ if (item->object.graft)
+ graft = lookup_commit_graft(item->object.sha1);
+ else
+ graft = 0;
+
while (bufptr + 48 < tail && !memcmp(bufptr, "parent ", 7)) {
struct commit *new_parent;
@@ -283,7 +303,10 @@ int parse_commit_buffer(struct commit *item, void *buffer, unsigned long size)
continue;
pptr = &commit_list_insert(new_parent, pptr)->next;
}
- }
+ item->object.graft = 1;
+ } else
+ item->object.graft = 0;
+
item->date = parse_commit_date(bufptr, tail);
return 0;
diff --git a/object.h b/object.h
index 89dd0c4..f848e0f 100644
--- a/object.h
+++ b/object.h
@@ -22,7 +22,7 @@ struct object_array {
};
#define TYPE_BITS 3
-#define FLAG_BITS 27
+#define FLAG_BITS 26
/*
* The object type is stored in 3 bits.
@@ -30,6 +30,7 @@ struct object_array {
struct object {
unsigned parsed : 1;
unsigned used : 1;
+ unsigned graft : 1;
unsigned type : TYPE_BITS;
unsigned flags : FLAG_BITS;
unsigned char sha1[20];
diff --git a/rev-cache.c b/rev-cache.c
index 6c96297..f7b1cd2 100644
--- a/rev-cache.c
+++ b/rev-cache.c
@@ -664,9 +664,41 @@ static int traverse_cache_slice_1(struct rc_slice_header *head, unsigned char *m
}
} else if (!ipath_nr && co->date <= date)
slop--;
+ else if (!ipath_nr && !upath_nr)
+ break;
else
slop = SLOP;
+ /* before opening further topo-relations, check if the parenting has had medical attention */
+ if (obj->graft) {
+ struct commit_list *list;
+
+ parse_commit(co);
+ obj->flags &= ~FACE_VALUE;
+ last_objects[path] = 0;
+
+ /* we're only interested in its indirect influence */
+ for (list = co->parents; list; list = list->next) {
+ struct rc_index_entry *iep;
+ struct object *po = &list->item->object;
+
+ iep = search_index(po->sha1);
+ if (!iep || hashcmp(idx_caches + 20 * iep->cache_index, head->sha1)) {
+ if (!(obj->flags & UNINTERESTING) && !(po->flags & UNINTERESTING))
+ ioutside = 1;
+ }
+ }
+
+ /* an abrupt end */
+ myworkp = &commit_list_insert(co, myworkp)->next;
+ if (entry->uninteresting)
+ upath_nr--;
+ else
+ ipath_nr--;
+ paths[path] = 0;
+ continue;
+ }
+
/* open parents */
if (entry->merge_nr) {
int j, off = index + sizeof(struct rc_object_entry_ondisk);
diff --git a/t/t6017-rev-cache-list.sh b/t/t6017-rev-cache-list.sh
index 3286560..6ada7ac 100755
--- a/t/t6017-rev-cache-list.sh
+++ b/t/t6017-rev-cache-list.sh
@@ -92,6 +92,7 @@ git-rev-list --topo-order HEAD --not HEAD~2 >proper_commit_list_limited2
git-rev-list --topo-order HEAD >proper_commit_list
git-rev-list --objects HEAD >proper_object_list
git-rev-list HEAD --max-age=$min_date --min-age=$max_date >proper_list_date_limited
+git-rev-cache test HEAD :HEAD~2 >proper_shallow_list
cache_sha1=`git-rev-cache add HEAD 2>output.err`
@@ -252,4 +253,9 @@ test_expect_success 'test --ignore-size function in fuse' '
test -e .git/rev-cache/$cache_sha1
'
+test_expect_success 'check graft handling' '
+ git-rev-cache test HEAD :HEAD~2 >list
+ test_cmp list proper_shallow_list
+'
+
test_done
--
tg: (ceb0b39..) t/revcache/graft (depends on: t/revcache/names)
^ permalink raw reply related
* Re: [JGIT PATCH 7/9] removing eclipse project files
From: Robin Rosenberg @ 2009-09-27 19:52 UTC (permalink / raw)
To: Mark Struberg; +Cc: MatthiasSohn, git@vger.kernel.org, spearce@spearce.org
In-Reply-To: <892492.1652.qm@web27801.mail.ukl.yahoo.com>
lördag 26 september 2009 22:10:16 skrev Mark Struberg <struberg@yahoo.de>:
>
> As you already pointed to: we have to clearly separate between settings stored in the project itself and settings stored in the workspace. The first are by far not all settings needed, the 2nd are not checked in to git anyway. Maybe I didn't find it yet, but is there an ability to set formatter settings for XML (e.g. Tabs vs spaces policy)? I was only able to specify this for the whole workspace and not on a per project basis.
Those are workspace settings in the 3.4, not checked 3.,5 yet. You could add
it to bugzilla as a feature request. All settings should be available as project settings I think.
> And there is a lot more which imho cannot be set for a project. So checking in the xml sounds like it is way more powerful isn't? And we would have this
For JGit, not really. Everything that is not project settings should be left as the default. The only reason is tool constraints. I'm not well versed
enough to tell what neatbeans does here.
> feature for a lot non-Eclipse users too (e.g. for Jonas who hacks the nbgit NetBeans plugin based on JGit (again: EGit is a different story!)).
I'm not sure keeping netbeans settings would be a problem, but that is
about how much we could do
>
> >
> > We use 3.3 (well I think the last user dropped it
> > recently), 3.4 and 3.5. I often have to fix up new projects
> > but that is typically a one-time per eclipse project
> > problem. (typically the JRE gets bound to a specific install
> > location).
> >
> > The .launch files is another story since they change format
> > all the time.
>
> And the profiler settings, and and and. It's sad, but the list is long :(
Yep...
> We can also let the eclipse settings files checked in currently if you like. But I'd be happy if we continue collecting information and then make a decision.
I definitely think we should keep them until we find an alternate solution. The
projects settings are way too useful to be thrown out.
-- robin
^ permalink raw reply
* Re: Deciding between Git/Mercurial
From: Erik Faye-Lund @ 2009-09-27 19:34 UTC (permalink / raw)
To: newsgroups; +Cc: git
In-Reply-To: <h9odqq$ig9$1@ger.gmane.org>
On Sun, Sep 27, 2009 at 9:18 PM, Anteru
<newsgroups@catchall.shelter13.net> wrote:
> Don't get me wrong with Git+msysgit on Windows, the point is simply if
> we switch to git, can we expect that Windows will be supported for the
> foreseeable future or is it possible that git may simply drop Windows
> support completely? For Mercurial, this is a non-issue, as it is written
> in Python, and Python will support both Windows and Linux.
The chance of Windows support being dropped from git is very unlikely
- there's way too many people depending on git for Windows already for
that to happen. Besides, git is open source, so you can always fix
Windows issues yourself.
As for Mercurial, Python programs aren't automatically portable to
Windows either. But I expect that they have the same very close to
zero chance of having Windows support dropped as git has.
> As I said, I'm happy with using msysgit, but I cannot find any roadmap
> etc. which helps me to determine how git and Windows is going to
> continue (for instance, I can find some complaints that git's
> performance is bad on Windows due to cygwin's fork()/exec(), is this
> likely to get ever "fixed"? I guess git# will solve this as soon as it's
> ready?)
Git (neither mainline nor msysgit) doesn't have any official roadmap
as far as I know. People just hack away on what they feel is
important. If you want to make sure something gets done, chip in the
development-time yourself.
As for the fork()-performance, this is only an issue for some tools
(if any at all - I don't think this issue exists in msysgit). In my
experience, git on Windows is faster than any other VCS I've ever used
on Windows.
--
Erik "kusma" Faye-Lund
kusmabite@gmail.com
(+47) 986 59 656
^ permalink raw reply
* Re: Deciding between Git/Mercurial
From: Alex Riesen @ 2009-09-27 19:31 UTC (permalink / raw)
To: newsgroups; +Cc: git
In-Reply-To: <h9odqq$ig9$1@ger.gmane.org>
On Sun, Sep 27, 2009 at 21:18, Anteru <newsgroups@catchall.shelter13.net> wrote:
> Don't get me wrong with Git+msysgit on Windows, the point is simply if
> we switch to git, can we expect that Windows will be supported for the
> foreseeable future or is it possible that git may simply drop Windows
> support completely? ...
Despite what I said, this is very unlikely (sadly). There are active developers
whose professional life happens in Windows. Besides, the project is open-
source and no one can stop you from taking over the maintainership of a port.
> As I said, I'm happy with using msysgit, but I cannot find any roadmap
There isn't any. Roadmaps are for projects with a guaranteed end of life :-p
> etc. which helps me to determine how git and Windows is going to
> continue (for instance, I can find some complaints that git's
> performance is bad on Windows due to cygwin's fork()/exec(), is this
> likely to get ever "fixed"?
Not likely. OTOH, msysGIT does not have that part of performance problem.
^ permalink raw reply
* Re: Deciding between Git/Mercurial
From: Anteru @ 2009-09-27 19:18 UTC (permalink / raw)
To: git
In-Reply-To: <585748.13758.qm@web27802.mail.ukl.yahoo.com>
Mark Struberg schrieb:
> Another thing to consider: For what kind of project/language do you need git? What build tools are you using and how good is the integration into both git and hg?
The project is running on Windows/Linux (Windows being the primary
development platform, and we also expect most users to run Windows.)
For tooling, we use Trac at the moment (good integration with SVN), but
we're evaluating GitTrac, Trac/Mercurial and Redmine now (+ possible
migration paths.) For our build system, it's a non-issue anyway, as
git/mercurial have command line clients, and that's all we need.
Don't get me wrong with Git+msysgit on Windows, the point is simply if
we switch to git, can we expect that Windows will be supported for the
foreseeable future or is it possible that git may simply drop Windows
support completely? For Mercurial, this is a non-issue, as it is written
in Python, and Python will support both Windows and Linux.
As I said, I'm happy with using msysgit, but I cannot find any roadmap
etc. which helps me to determine how git and Windows is going to
continue (for instance, I can find some complaints that git's
performance is bad on Windows due to cygwin's fork()/exec(), is this
likely to get ever "fixed"? I guess git# will solve this as soon as it's
ready?)
Cheers,
Anteru
^ permalink raw reply
* Re: cgit suggestion
From: Alexey Nezhdanov @ 2009-09-27 19:02 UTC (permalink / raw)
To: hjemli; +Cc: git
In-Reply-To: <e95c2db40909252314t12abb6e2w9b6e9c34c7a724a5@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1036 bytes --]
Hello Lars.
Here is the diff. It adds feature of downloading 'named' tarball from the tag
description page.
On Saturday 26 September 2009 10:14:19 Alexey Nezhdanov wrote:
> Hello Lars.
> Discovered a cgit for myself throught the LWN article:
> http://lwn.net/Articles/351798/
>
> Great thing! I'm impressed, will use it instead of gitweb (when I'll need a
> web interface anyway ;-P).
> Came upon a thing though that I consider to be an inconvenience.
>
> When I click on a tag, for instance:
> http://hjemli.net/git/cgit/tag/?id=v0.8.2.2
> there is no download link of assotiated object. And if I click on a 'tagged
> object' I get download links, but they are referenced by SHA-1 format.
> So they can not be used as a .orig.tar.gz package or even just stored 'for
> a future use' since SHA-1 is not human readable.
> So I propose putting download links onto tag page for the objects of type
> 'tree' and 'commit'.
> If you want me to write a patch - I'll do.
>
> Regards
> Alexey Nezhdanov.
--
Sincerely yours
Alexey Nezhdanov
[-- Attachment #2: 0001-Ad-hoc-tarball-downloads-from-the-tag-description-pa.patch --]
[-- Type: text/x-diff, Size: 1612 bytes --]
From b70365dfab8bb9ade733ea8387880b2b2cf4baa4 Mon Sep 17 00:00:00 2001
From: Alexey Nezhdanov <snakeru@gmail.com>
Date: Sun, 27 Sep 2009 23:00:29 +0400
Subject: [PATCH] Ad-hoc tarball downloads from the tag description page.
Signed-off-by: Alexey Nezhdanov <snakeru@gmail.com>
---
ui-tag.c | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/ui-tag.c b/ui-tag.c
index c2d72af..da93b7a 100644
--- a/ui-tag.c
+++ b/ui-tag.c
@@ -76,6 +76,12 @@ void cgit_print_tag(char *revname)
html("<tr><td>Tagged object</td><td>");
cgit_object_link(tag->tagged);
html("</td></tr>\n");
+ if (ctx.repo->snapshots) {
+ html("<tr><th>download</th><td class='sha1'>");
+ cgit_print_snapshot_links(ctx.qry.repo, ctx.qry.head,
+ revname, ctx.repo->snapshots);
+ html("</td></tr>");
+ }
html("</table>\n");
print_tag_content(info->msg);
} else {
@@ -86,6 +92,12 @@ void cgit_print_tag(char *revname)
html("<tr><td>Tagged object</td><td>");
cgit_object_link(obj);
html("</td></tr>\n");
+ if (ctx.repo->snapshots) {
+ html("<tr><th>download</th><td class='sha1'>");
+ cgit_print_snapshot_links(ctx.qry.repo, ctx.qry.head,
+ revname, ctx.repo->snapshots);
+ html("</td></tr>");
+ }
html("</table>\n");
}
return;
--
1.5.6.3
^ permalink raw reply related
* Re: Deciding between Git/Mercurial
From: Pascal Obry @ 2009-09-27 18:55 UTC (permalink / raw)
To: newsgroups; +Cc: git
In-Reply-To: <h9o9qr$548$1@ger.gmane.org>
Le 27/09/2009 20:10, Anteru a écrit :
> Yeah, well, the main question here is actually: Is improved support for
> Windows one of the goals of future git development, or is this a
> complete non-issue?
I think it is a non-issue as Git compile out of the box with Cygwin.
Since many years I'm building Git almost daily from master under my
Windows box using Cygwin. git-svn works like a charm too.
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net - http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B
^ permalink raw reply
* Re: Deciding between Git/Mercurial
From: Mark Struberg @ 2009-09-27 18:51 UTC (permalink / raw)
To: newsgroups, Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0909271144o26743e05uac3132cdc5b530b@mail.gmail.com>
Another thing to consider: For what kind of project/language do you need git? What build tools are you using and how good is the integration into both git and hg?
LieGrue,
strub
--- On Sun, 9/27/09, Alex Riesen <raa.lkml@gmail.com> wrote:
> From: Alex Riesen <raa.lkml@gmail.com>
> Subject: Re: Deciding between Git/Mercurial
> To: newsgroups@catchall.shelter13.net
> Cc: git@vger.kernel.org
> Date: Sunday, September 27, 2009, 8:44 PM
> On Sun, Sep 27, 2009 at 20:10, Anteru
> <newsgroups@catchall.shelter13.net>
> wrote:
> > Yeah, well, the main question here is actually: Is
> improved support for
> > Windows one of the goals of future git development, or
> is this a
> > complete non-issue?
>
> I just hope it is not. Improved Windows support mostly
> means lots of dead code (and that's the best outcome),
> which no other platform can use.
> --
> 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
>
^ permalink raw reply
* Re: Deciding between Git/Mercurial
From: Alex Riesen @ 2009-09-27 18:44 UTC (permalink / raw)
To: newsgroups; +Cc: git
In-Reply-To: <h9o9qr$548$1@ger.gmane.org>
On Sun, Sep 27, 2009 at 20:10, Anteru <newsgroups@catchall.shelter13.net> wrote:
> Yeah, well, the main question here is actually: Is improved support for
> Windows one of the goals of future git development, or is this a
> complete non-issue?
I just hope it is not. Improved Windows support mostly
means lots of dead code (and that's the best outcome),
which no other platform can use.
^ permalink raw reply
* Re: Deciding between Git/Mercurial
From: Anteru @ 2009-09-27 18:10 UTC (permalink / raw)
To: git
In-Reply-To: <200909272001.48180.robin.rosenberg.lists@dewire.com>
Robin Rosenberg wrote:
> You have to read carefully. This (or the mercurial list) may not be the
> most objective sources of information.
Sure, but at the moment, I'm advocating pro-git, so I'm biased as well :)
> Might be somewhat true, but msysgit works very well. Not sure how
> mercurial handles unicode issues. CRLF issues seems to be ignored (not handled).
Yeah, well, the main question here is actually: Is improved support for
Windows one of the goals of future git development, or is this a
complete non-issue?
Cheers,
Anteru
^ permalink raw reply
* Re: Deciding between Git/Mercurial
From: Robin Rosenberg @ 2009-09-27 18:01 UTC (permalink / raw)
To: newsgroups; +Cc: git
In-Reply-To: <h9nlhj$heq$1@ger.gmane.org>
söndag 27 september 2009 14:24:32 skrev Anteru <newsgroups@catchall.shelter13.net>:
> Hi,
>
> I'm currently evaluating DVCS for a project, and we're at a point where
> it comes down to either Mercurial or Git. Right now, I'm advocating for
> Git, while my co-workers like Mercurial, so I'd like to provide some
> good arguments in favor of git. Unfortunately, I'm not a git expert, so
> I hope I can get some help here ...
You have to read carefully. This (or the mercurial list) may not be the
most objective sources of information.
> First of all, what's the matter with git and Windows, is there some
> long-term commitment to make git work on Windows as well as on Linux?
Besides msysgit there is JGit and a port of it to C# (and thus any dotnet-ish
language). The msysgit teams seems very committed and passionate about
the project, but they need more assistance from genuine Windows users. Note
that the current model of file locking can never work as well on Windows
as it does on Unix. Something better is needed for flawless operation.
> I'm using msysgit on Windows, and personally I'm happy with it, but my
> co-workers constantly nag that Mercurial has superior portability ...
Might be somewhat true, but msysgit works very well. Not sure how
mercurial handles unicode issues. CRLF issues seems to be ignored (not handled).
> Mercurial's revision number system: With git, I get an SHA1 hash for
> every commit, but it's not possible to see whether Hash1 is newer than
> Hash2, while Mecurial also adds a running number to each commit. What's
But those numbers cannot be communicated since they are local to your
clone.
> the rationale behind this decision for git, and is it possible to
> emulate Mercurial's behavior somehow?
git-cvsserver has to do something along those line The numbering is
per file.
Maintainers tend to tag versions using the common numbered schem
and that is typically enough.
-- robin
^ 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