* [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
* gitweb atom feeds broken (on repo.or.cz only?)
From: Sebastian Pipping @ 2009-09-27 17:35 UTC (permalink / raw)
To: git, Petr Baudis; +Cc: Robert Buchholz
hello git list, hello petr!
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].
their rss neighbors seemed not to be affected where i looked.
a fix would be cool still, as the atom feeds contain more detailed content.
sorry for the noise in case repo.or.cz runs customized atom generation.
sebastian
[1] http://repo.or.cz/w/dottout.git?a=atom
[2]
http://feedvalidator.org/check.cgi?url=http%3A%2F%2Frepo.or.cz%2Fw%2Fdottout.git%3Fa%3Datom
^ permalink raw reply
* New script: build-git
From: Øyvind A. Holm @ 2009-09-27 13:33 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1114 bytes --]
It’s important to have the bleeding-edge Git installed on all computers
I use, so I created a bash script to automatically download, install and
test new versions from the master branch. It’s been maturing now for
some weeks, and works fine on all computers I use, which is Ubuntu and
Debian based. It’s built with paranoia in mind to avoid accidents, and
places each version under its separate directory structure under
/usr/local by default, but that’s easily configurable.
In case someone else has use for such a script, it’s available from
git://github.com/sunny256/build-git.git
http://github.com/sunny256/build-git.git
or
git://gitorious.org/build-git/build-git.git
http://git.gitorious.org/build-git/build-git.git
Comments and patches/enhancements welcome.
Regards,
Øyvind
+-| Øyvind A. Holm <sunny@sunbase.org> - N 60.39548° E 5.31735° |-+
| OpenPGP: 0xFB0CBEE894A506E5 - http://www.sunbase.org/pubkey.asc |
| Fingerprint: A006 05D6 E676 B319 55E2 E77E FB0C BEE8 94A5 06E5 |
+------------| 47ab564a-ab68-11de-8e10-00248cd5cf1e |-------------+
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Deciding between Git/Mercurial
From: Anteru @ 2009-09-27 12:24 UTC (permalink / raw)
To: git
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 ...
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?
I'm using msysgit on Windows, and personally I'm happy with it, but my
co-workers constantly nag that Mercurial has superior portability ...
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
the rationale behind this decision for git, and is it possible to
emulate Mercurial's behavior somehow?
Integration into tools: We're using Trac currently, which also has a
nice binding to Mercurial (well, obviously easy to do as Mercurial is
written in Python, just as Trac itself), while the git support is in
development and looks quite alpha'ish. Do you plan to make it easier to
integrate git with other tools by providing bindings to other languages,
or is this a low-priority issue?
So far, my key arguments are that git is more robust (more projects
using it, larger developer base), of course git's excellent performance
and the much better support for SVN, which is important for us as we can
slowly migrate from SVN->Git, while hgmercurial is still in the making
(and Python's SVN->Hg switch is for instance waiting for it).
Cheers,
Anteru
^ permalink raw reply
* Re: git log --pretty=format:%h prints (unrequired) abbreviated sha
From: alexandrul @ 2009-09-27 10:40 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <e5bfff550909261455g4eef8432jbb90048417deecba@mail.gmail.com>
Marco Costalba wrote:
> Hi Alexandrul,
>
> Now it works !!!! :-) :-)
>
> It was a virus ! I have run Malwarebytes Anti-malware 1.41 and it
> found some virus (I send you the logs in attachment), after removing
> them the problem disappeared.
>
> I have Kaspersky as antivirus, but, although a very good antivirus it
> failed to identify them.
>
> I didn't know this Malwarebytes, but it seems very powerful.
>
> Thanks anyhow for your exceptional help, I have really appreciated that !!!!
>
>
> Thanks again
> Marco
>
You are welcome.
Unfortunately, Kaspersky and Malwarebytes target different threats, but
both of them are very good at what they do.
Have a nice day,
A.
^ permalink raw reply
* Re: Interim maintainer tree
From: Jeff King @ 2009-09-27 8:54 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20090925160504.GW14660@spearce.org>
On Fri, Sep 25, 2009 at 09:05:04AM -0700, Shawn O. Pearce wrote:
> Junio is on vaction for the next week. In his absence Peff and I
> are trying to keep up with current patches in my fork:
>
> git://repo.or.cz/git/spearce.git
> http://repo.or.cz/r/git/spearce.git
I've collected a few more topics in my repo:
git://github.com/peff/git.git
Rather than cook my own, slightly different 'next', I'm just publishing
the tips of the topics themselves. Which means they are subject to
rewinding until you merge them into 'next', at which point I will leave
them stable.
What's in there now is:
as/parseopt-ambiguous
Fix for "git branch --no-merge" with my test added. Should be ready
for next.
jk/reflog-date
My reflog fix. Should be ready for next.
mr/gitweb-snapshot
v5, replacing what Junio had in pu. Should probably stay in pu until
we hear from Jakub.
mr/instaweb
Looked OK to me, but I have no capacity to actually test it.
Unlikely to break anything else, though, so probably ready to cook
in next.
mv/lock-error
My tweaked version, which got the OK from Miklos. Ready for next, I
think.
np/clone-smaller
Nico's fix to stop copying unnecessary objects during clone. Patch
looks sane, I confirmed that it fixes the issue, and it doesn't seem
to break normal clones. Ready to cook in next, I think.
-Peff
^ permalink raw reply
* Re: [PATCH] gitweb: fix spelling errors in comments
From: Miklos Vajna @ 2009-09-27 8:54 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20090927083507.GA25891@coredump.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 1208 bytes --]
On Sun, Sep 27, 2009 at 04:35:07AM -0400, Jeff King <peff@peff.net> wrote:
> > The plural form of "id" is "ids", not "id's", right?
>
> It is a matter of some debate, actually. As an abbreviation, it should
> rightly be "ID", and therefore "IDs". Most style manuals indicate that
> no apostrophe should be used these days, unless it is an abbreviation
> separated by dots (e.g., "I.D.'s").
>
> Some disagree, and some indicate that you should use an apostrophe where
> it may be visually more clear (for example, in single-letter
> abbreviations like "A's").
>
> There is a nice summary of some style guides here:
>
> http://answers.google.com/answers/threadview?id=499296
>
> Honestly, for such an informal bit of text as a code comment, I'm not
> sure it is worth nit-picking the grammar (e.g., we should be
> writing SHA-1 everywhere, and we obviously don't). I'll let Shawn decide
> whether he wants to apply or not.
As a non-native I did not know to resolve "id's" to "id is" or "id has",
and once I figured it out, I thought about sending a patch.
Though, if that helps, I can resend it with "Blobs defined by
non-textual hash IDs can be cached" to be more readable.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] git branch -D: give a better error message when lockfile creation fails
From: Miklos Vajna @ 2009-09-27 8:49 UTC (permalink / raw)
To: Jeff King; +Cc: Matthieu.Moy, spearce, git
In-Reply-To: <20090927082123.GD15393@coredump.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 355 bytes --]
On Sun, Sep 27, 2009 at 04:21:23AM -0400, Jeff King <peff@peff.net> wrote:
> Maybe it is just me, but that extra die() that should never be reached
> is terribly ugly. I would do it with two functions, one that dies and
> one that doesn't, with a helper to format the message. IOW, this:
Okay, that's fine with me - thanks for providing a patch as well.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] gitweb: fix spelling errors in comments
From: Jeff King @ 2009-09-27 8:35 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <1254007953-1961-1-git-send-email-vmiklos@frugalware.org>
On Sun, Sep 27, 2009 at 01:32:33AM +0200, Miklos Vajna wrote:
> Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
> ---
> gitweb/gitweb.perl | 10 +++++-----
> 1 files changed, 5 insertions(+), 5 deletions(-)
>
> The plural form of "id" is "ids", not "id's", right?
It is a matter of some debate, actually. As an abbreviation, it should
rightly be "ID", and therefore "IDs". Most style manuals indicate that
no apostrophe should be used these days, unless it is an abbreviation
separated by dots (e.g., "I.D.'s").
Some disagree, and some indicate that you should use an apostrophe where
it may be visually more clear (for example, in single-letter
abbreviations like "A's").
There is a nice summary of some style guides here:
http://answers.google.com/answers/threadview?id=499296
Honestly, for such an informal bit of text as a code comment, I'm not
sure it is worth nit-picking the grammar (e.g., we should be
writing SHA-1 everywhere, and we obviously don't). I'll let Shawn decide
whether he wants to apply or not.
-Peff
^ permalink raw reply
* Re: git stash list shows timestamp in stead of "stash number", when setting date = local for log in config
From: Alf Kristian Støyle @ 2009-09-27 8:25 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Jeff King, git
In-Reply-To: <20090925222920.GZ14660@spearce.org>
Hi guys, thanks for the explanation, and thanks for fixing this. I
wasn't aware that stash just is a reflog.
- Alf
On Sat, Sep 26, 2009 at 00:29, Shawn O. Pearce <spearce@spearce.org> wrote:
> Jeff King <peff@peff.net> wrote:
>> On Tue, Sep 15, 2009 at 04:56:41PM +0200, Alf Kristian St??yle wrote:
>> > When doing a "git stash list" I get this strange stash record:
>> > stash@{Tue Sep 15 16:28:12 2009}: WIP on master: 2262276 ...
>> >
>> > I have a global config setting on log:
>> >
>> > [log]
>> > date = local
>> >
>> > If setting the date config to default or removing the setting, the
>> > stash record looks correct:
>> > stash@{0}: WIP on master: 2262276 ...
>>
>> The patch below implements the former. The only downside I can think of
>> is if somebody is relying on "log.date" to set the output format for
>> reflogs, because they really like the date version better. In that case,
>> I think we should wait for them to complain (which I doubt will happen),
>> and then add a log.reflogDates config option to appease them.
>>
>> Shawn, reflogs are your thing. Any comments?
>
> I agree. I doubt anyone is relying on log.date to reformat the
> output of `git reflog show` or `git stash list`, so this is probably
> a reasonable change to make. Even if they were trying to use that,
> its a bug.
>
> Care to wrap this up in a patch?
>
> --
> Shawn.
>
^ permalink raw reply
* Re: [PATCH] Remove various dead assignments and dead increments found by the clang static analyzer
From: Giuseppe Scrivano @ 2009-09-27 8:21 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jeff King, git, Johannes Schindelin, Sverre Rabbelier
In-Reply-To: <alpine.LFD.2.00.0909262038470.4997@xanadu.home>
Nicolas Pitre <nico@fluxnic.net> writes:
> And the compiler (at least gcc) is indeed smart enough to realize that
> nothing uses the result from the last statement, and does optimize away
> the code associated to it already. So this patch is unlikely to change
> anything to the compiled result.
Right, and gcc can do many other amazing things. But still it is used a
variable that is never accessed, removing it can make the code slightly
more readable.
Cheers,
Giuseppe
^ 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