* Re: [egit-dev] Re: jgit problems for file paths with non-ASCII characters
From: Thomas Singer @ 2009-11-26 13:09 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: EGit developer discussion, Marc Strapetz, git
In-Reply-To: <20091126005423.GM11919@spearce.org>
> But as you said, this still doesn't make the Apple normal form
> any easier. Though if we know we are on such a strange filesystem
> we might be able to assume the paths in the repository are equally
> damaged. Or not.
Well, if the git-core folks could standardize on, e.g., composed UTF-8
(rather then just UTF-8), for storing file names in the repository, then
everything should be clear, isn't it?
--
Best regards,
Thomas Singer
=============
syntevo GmbH
http://www.syntevo.com
http://blog.syntevo.com
Shawn O. Pearce wrote:
> Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
>> onsdag 25 november 2009 14:47:25 skrev Marc Strapetz:
>>> I have noticed that jgit converts file paths to UTF-8 when querying the
>>> repository.
> ...
>>> Is this a bug or a misconfiguration of my repository? I'm using jgit
>>> (commit e16af839e8a0cc01c52d3648d2d28e4cb915f80f) on Windows.
>> A bug.
>>
>> The problem here is that we need to allow multiple encodings since there
>> is no reliable encoding specified anywhere.
>
> This is a design fault of both Linux and git. git gets a byte
> sequence from readdir and stores that as-is into the repository.
> We have no way of knowing what that encoding is. So now everyone
> touching a Git repository is screwed.
>
>> The approach I advocate is
>> the one we use for handling encoding in general. I.e. if it looks like UTF-8,
>> treat it like that else fallback. This is expensive however
>
> We should try to work harder with the git-core folks to get character
> set encoding for file names worked out. We might be able to use a
> configuration setting in the repository to tell us what the proper
> encoding should be, and if not set, assume UTF-8.
>
>> and then we have
>> all the other issues with case insensitive name and the funny property that
>> unicode has when it allows characters to be encoding using multiple sequences
>> of code points as empoloyed by Apple.
>
> But as you said, this still doesn't make the Apple normal form
> any easier. Though if we know we are on such a strange filesystem
> we might be able to assume the paths in the repository are equally
> damaged. Or not.
>
^ permalink raw reply
* Re: [PATCH (resend)] Let core.excludesfile default to ~/.gitexcludes.
From: Bert Wesarg @ 2009-11-26 13:01 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Matthieu Moy, git, gitster
In-Reply-To: <4B0E6DC9.3070105@drmicha.warpmail.net>
On Thu, Nov 26, 2009 at 13:00, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> Matthieu Moy venit, vidit, dixit 26.11.2009 11:35:
>> Most users will set it to ~/.gitsomething. ~/.gitignore would conflict
>> with per-directory ignore file if ~/ is managed by Git, so ~/.gitexcludes
>> is a sane default.
>
> I'm sorry to jump in so late, and this may sound like bike-shedding, but
> right now we have
>
> .git/info/exclude
> .gitignore
>
> and this would add
>
> ~/.gitexcludes
>
> That is, three terms, or two, where one comes in two variations
> (exclude/exludes). I always wondered why we have two.
>
> The reason for .gitignore is most probably the similarity to
> .${othervcs}ignore, and that is a valid reason.
>
> I know we have ~/.gitconfig for the global version of .git/config, and
> maybe that was just no good idea either. But I don't even dare
> suggesting to rename it ~/.gitglobalconfig.
>
> So, in line at least with our term "global" (per user) config, I would
> suggest to use "~/.gitglobalignore" for the global ignore file. Maybe,
> eventually, we'll manage to rename .git/info/excludes to .git/info/ignore.
>
> On a somewhat larger scale, a good alternative strategy would be to have
> a directory "~/.gitglobal/" in which Git would look for
> ~/.gitglobal/config and
> ~/.gitglobal/info/ignore or
> ~/.gitglobal/ignore
>
> i.e. mirroring the repo structure or at least bundling everything in a
> single dir, which would also be a good place for a global svnauthors
> file and such, and for other global configuration files we don't think
> of right now.
I would vote for that too. Its more future-proof than a single new
file. Also I would suggest to name this dir ~/.gitrc/. On the other
hand the --global option to git config specifies the .gitconfig in
your HOME.
Bert
>
> Michael
^ permalink raw reply
* Re: [PATCH (resend)] Let core.excludesfile default to ~/.gitexcludes.
From: Paolo Bonzini @ 2009-11-26 12:49 UTC (permalink / raw)
To: git
In-Reply-To: <4B0E6DC9.3070105@drmicha.warpmail.net>
On 11/26/2009 01:00 PM, Michael J Gruber wrote:
> I'm sorry to jump in so late, and this may sound like bike-shedding, but
> right now we have
>
> .git/info/exclude
> .gitignore
>
> and this would add
>
> ~/.gitexcludes
>
> That is, three terms, or two, where one comes in two variations
> (exclude/exludes). I always wondered why we have two.
Would you be fine with ~/.gitexclude?
Paolo
^ permalink raw reply
* Re: Working on merged branches whilst seeing current master
From: Tim Mazid @ 2009-11-26 12:45 UTC (permalink / raw)
To: git
In-Reply-To: <1258044562803-3994102.post@n2.nabble.com>
rhlee wrote:
>
>
> Tim Mazid wrote:
>>
>> Actually, there's no reason you couldn't just 'git reset HEAD^' once you
>> realise that the branch isn't ready. If you want to see the changes from
>> master, you could just merge that into your branch. If you just want to
>> see the content in master, you could use gitk or gitg, which allows you
>> to view files at any commit.
>>
>> Personally, I merge master into my branches, test and check, and fix,
>> then merge the branch into master. This sometimes results in a
>> fast-forward, if you haven't made changes to master. If you don't like
>> that, you can always use the --no-ff option, though.
>>
>
> I don't think 'git reset HEAD^' would work in my case as that only goes
> back one commit. I may have made many other changes on the master branch
> that I want to keep.
>
> By merging from master into your branch, like you said, you get a nice
> graph view that shows what you've brought into your branch from master
> since you last left off. But doesn't this goes against the idea that
> branches should be independent, by bringing in changes from master?
>
Yup, you only need to 'git reset HEAD^' on the master branch to undo the
merge. Isn't that what you wanted?
And yeah, I suppose it kind of does. But once again, you can 'git reset
HEAD^'. And since you're merging master INTO the branches, you are keeping
the branches independent, anyway.
--
View this message in context: http://n2.nabble.com/Working-on-merged-branches-whilst-seeing-current-master-tp3987667p4070977.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Merge priority
From: Howard Miller @ 2009-11-26 12:44 UTC (permalink / raw)
To: git
I'm not sure this is even a sensible question....
I have a whole bunch of customer branches with all manner of local
tweaks and modifications. I also have a stable branch with all my
security patches and bug fixes. They do share common ancestry.
I now want to update all my customer branches with the latest fixes
and patches. Naively, I would just check out each branch and merge the
stable branch - job done. However, is it sensible to ask if there is a
way to say that the stable branch is more important if there are
conflicts. Or should I be using rebase instead (which I still don't
really understand). I'm trying to reduce my workload as there are
loads of branches to do.
Cheers :-)
^ permalink raw reply
* [StGit] push/pull stacked patches
From: Kurt Harriman @ 2009-11-26 12:17 UTC (permalink / raw)
To: git
Suppose two developers are collaborating on a series of patches.
What is the best way to synchronize their repositories, including
the StGit state?
Even if both repositories are StGit-enabled, the patch metadata
and unapplied patches don't seem to be transferred by push/pull.
Applied patches are transferred as ordinary commits, losing
their patch names and their place in the patch stack.
It seems that a remote branch cannot have a patch stack.
Instead of using push/pull, a patch series can be transferred
using stg export/import, but this is error-prone, requiring
extra steps, and changes the commit timestamp and SHA1.
Stg export/import are good for distributing the final version
of a patch series; but ungitly for back-and-forth collaboration.
Is there a better way?
^ permalink raw reply
* Re: [PATCH] Give the hunk comment its own color
From: Bert Wesarg @ 2009-11-26 12:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7vaayjebu5.fsf@alter.siamese.dyndns.org>
Junio,
may I kindly remind you of this patch. If it is only the nen-existing
consensus of the default color, than please use the die.
Kind regards,
Bert Wesarg
^ permalink raw reply
* Re: [PATCH (resend)] Let core.excludesfile default to ~/.gitexcludes.
From: Michael J Gruber @ 2009-11-26 12:00 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git, gitster
In-Reply-To: <1259231726-5218-1-git-send-email-Matthieu.Moy@imag.fr>
Matthieu Moy venit, vidit, dixit 26.11.2009 11:35:
> Most users will set it to ~/.gitsomething. ~/.gitignore would conflict
> with per-directory ignore file if ~/ is managed by Git, so ~/.gitexcludes
> is a sane default.
I'm sorry to jump in so late, and this may sound like bike-shedding, but
right now we have
.git/info/exclude
.gitignore
and this would add
~/.gitexcludes
That is, three terms, or two, where one comes in two variations
(exclude/exludes). I always wondered why we have two.
The reason for .gitignore is most probably the similarity to
.${othervcs}ignore, and that is a valid reason.
I know we have ~/.gitconfig for the global version of .git/config, and
maybe that was just no good idea either. But I don't even dare
suggesting to rename it ~/.gitglobalconfig.
So, in line at least with our term "global" (per user) config, I would
suggest to use "~/.gitglobalignore" for the global ignore file. Maybe,
eventually, we'll manage to rename .git/info/excludes to .git/info/ignore.
On a somewhat larger scale, a good alternative strategy would be to have
a directory "~/.gitglobal/" in which Git would look for
~/.gitglobal/config and
~/.gitglobal/info/ignore or
~/.gitglobal/ignore
i.e. mirroring the repo structure or at least bundling everything in a
single dir, which would also be a good place for a global svnauthors
file and such, and for other global configuration files we don't think
of right now.
Michael
^ permalink raw reply
* Re: [PATCH/RFC 02/11] strbuf: add non-variadic function strbuf_vaddf()
From: Paolo Bonzini @ 2009-11-26 11:13 UTC (permalink / raw)
To: git; +Cc: msysgit
In-Reply-To: <40aa078e0911260238rd0c90cag126709d1de5f50de@mail.gmail.com>
On 11/26/2009 11:38 AM, Erik Faye-Lund wrote:
> In practice it seems that something like the following works
> portably-enough for many applications, dunno if it's something we'll
> be happy with:
> #ifndef va_copy
> #define va_copy(a,b) ((a) = (b))
> #endif
Yes, this is correct.
Paolo
^ permalink raw reply
* Re: [RFC/PATCHv8 08/10] fast-import: Proper notes tree manipulation using the notes API
From: Johan Herland @ 2009-11-26 11:10 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, gitster
In-Reply-To: <20091126024655.GR11919@spearce.org>
On Thursday 26 November 2009, Shawn O. Pearce wrote:
> Johan Herland <johan@herland.net> wrote:
> > This patch teaches 'git fast-import' to use the notes API to
> > organize
>
> ...
>
> > This patch is substantially different from the previous iteration.
> > Unloading (and reloading) the notes tree along with its
> > corresponding branch was relatively straightforward to fix, but
> > avoiding the destroying and re-adding of all the notes in every
> > commit was much harder. After 3-4 attempts at a simpler (but
> > fundamentally broken) approach, I finally landed on this. I'm not
> > satisfied with the amount of code introduced by this patch, and
> > would be happy if someone found a better/shorter/more elegant way
> > to solve this problem.
>
> Yea, I agree, I'm not happy with the amount of complex code added
> to implement this. But I can't say there's a better way to do it
> and still reuse the notes code. Maybe its just worth breaking away
> from the notes code altogether? fast-import also implements its
> own pack formatting functions because reusing them from pack-objects
> was just too ugly.
Ok, I will attempt to redo the patch without reusing the notes code. I
have couple of ideas on how to get it done, but probably won't have the
time to implement them until next week...
> Aside from a few minor nits below though, I could ACK this, it at
> least avoids the nasty corners that can arise when there are a lot
> of branches and tries to minimize the cost when there are many notes.
>
> > diff --git a/fast-import.c b/fast-import.c
> > +
> > +static void add_to_replace_list(
> > + struct tree_entry_replace **replace_list,
> > + const char *old_path, const char *new_path)
> > +{
> > + struct tree_entry_replace *r = (struct tree_entry_replace *)
> > + xmalloc(sizeof(struct tree_entry_replace));
> > + r->next = (*replace_list)->next;
> > + r->old_path = xstrdup(old_path);
> > + r->new_path = xstrdup(new_path);
> > + (*replace_list)->next = r;
> > + *replace_list = r;
>
> Really? I don't get why you are replacing the head's next with r
> only to then replace head itself with r.
>
> > @@ -2265,6 +2540,18 @@ static void parse_new_commit(void)
> > break;
> > }
> >
> > + if (notes) {
> > + /* reconcile diffs between b->branch_tree and the notes tree */
> > + struct reconcile_notes_tree_helper_data d;
> > + struct tree_entry_replace *replace_list =
> > + xcalloc(1, sizeof(struct tree_entry_replace));
>
> Oh, I see. The issue I had with understanding add_to_replace_list()
> is due to this spot allocating a blank header node. Normally we do
> this with a pointer to a pointer and initialize NULL:
>
> struct tree_entry_replace *list = NULL;
> struct tree_entry_replace **replace_list = &list;
>
> Can we avoid this blank header node? I think it comlicates the code,
> e.g. in process_replace_list() you have to skip over the blank node
> by testing for both paths being NULL.
The main problem is that I need to grow a linked list at the far end,
while keeping a reference to the first element, so that
process_replace_list() traverse the list in the correct order (FIFO).
However, I agree that my approach to doing so may have been somewhat
ham-fisted... Will redo (unless the alternative approach above renders
this code obsolete).
BTW, while we're on the topic, this whole code is only present because I
assume it's not possible to edit the fast-import tree structure _while_
traversing it. Is this assumption correct, or are there ways to get
around maintaining a separate edit list that is applied to the tree
structure afterwards?
Thanks for the review! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [PATCH/RFC 01/11] mingw: add network-wrappers for daemon
From: Martin Storsjö @ 2009-11-26 11:03 UTC (permalink / raw)
To: kusmabite; +Cc: msysgit, git, dotzenlabs
In-Reply-To: <40aa078e0911260246j47fa36d5t421de7c1d07d5cca@mail.gmail.com>
On Thu, 26 Nov 2009, Erik Faye-Lund wrote:
> Yeah, I saw your patches, and realized that I needed to rebase my work
> at some point, but none of the repos I usually pull from seems to
> contain the patches yet. Rebasing will be a requirement before this
> can be applied for sure.
Ok, great! I tried applying it on the latest master, and it wasn't too
much of work.
> > Also, the getaddrinfo-compatibility wrappers perhaps may need some minor
> > updates to handle the use cases needed for setting up listening sockets.
>
> I expect you're referring to IPv6 support in the wrappers this patch
> adds? Unfortunately IPv6 isn't something I'm very familiar with, but
> I'll give it a go unless someone else provides some patches...
No, sorry for being unclear.
When IPv6 is enabled, name lookups go through getaddrinfo instead of
gethostbyname. Since getaddrinfo isn't available on Win2k (and switching
between getaddrinfo/gethostbyname happens at compile time when IPv6 is
enabled), we have to provide a small getaddrinfo stub, implemented in
terms of gethostbyname. This currently implements only parts of the
getaddrinfo interface - enough for the way getaddrinfo was used this far.
git-daemon uses getaddrinfo in a slightly different way (for setting up
listening sockets), and thus uses parameters that our current getaddrinfo
stub doesn't support. The patch I sent to this thread a moment ago adds
support for the way git-daemon uses getaddrinfo.
I tested this patch series on top of the latest master, with IPv6 support,
and found a slight problem caused by the IPv6 support. If IPv6 isn't
enabled, git-daemon always listens on one single socket, otherwise it may
listen on two separate sockets, one for v4 and one for v6.
This causes problems with the mingw poll() replacement, which has a
special case for polling one single fd - otherwise it tries to use some
emulation that currently only works for pipes. I didn't try to make any
proper fix for this though. I tested git-daemon by hacking it to listen on
only one of the sockets, and that worked well for both v4 and v6.
So, in addition to the getaddrinfo patch I sent, the mingw poll()
replacement needs some updates to handle polling multiple sockets. Except
from that, things seem to work, at a quick glance.
// Martin
^ permalink raw reply
* Re: [PATCH/RFC 01/11] mingw: add network-wrappers for daemon
From: Erik Faye-Lund @ 2009-11-26 10:46 UTC (permalink / raw)
To: Martin Storsjö; +Cc: msysgit, git, dotzenlabs
In-Reply-To: <alpine.DEB.2.00.0911261015140.14228@cone.home.martin.st>
On Thu, Nov 26, 2009 at 9:24 AM, Martin Storsjö <martin@martin.st> wrote:
> Hi,
>
> First of all, great that you're working on adding daemon support for
> windows!
Thanks. I meant to send this out a couple of weeks ago, but I wasn't
able to find the time until now.
Also, I wouldn't have come this far without going tired of it without
Mike's patches, so some credit should go to him for doing good initial
work!
> On Thu, 26 Nov 2009, Erik Faye-Lund wrote:
>
>> +static void wsa_init(void)
>> {
>> + static int initialized = 0;
>> WSADATA wsa;
>>
>> + if (initialized)
>> + return;
>> +
>> if (WSAStartup(MAKEWORD(2,2), &wsa))
>> die("unable to initialize winsock subsystem, error %d",
>> WSAGetLastError());
>> atexit((void(*)(void)) WSACleanup);
>> + initialized = 1;
>> +}
>
> Something similar to this was merged into master recently as part of my
> mingw/ipv6 patches, so by rebasing your patch on top of that, this patch
> will probably get a bit smaller.
Yeah, I saw your patches, and realized that I needed to rebase my work
at some point, but none of the repos I usually pull from seems to
contain the patches yet. Rebasing will be a requirement before this
can be applied for sure.
>
> Also, the getaddrinfo-compatibility wrappers perhaps may need some minor
> updates to handle the use cases needed for setting up listening sockets.
I expect you're referring to IPv6 support in the wrappers this patch
adds? Unfortunately IPv6 isn't something I'm very familiar with, but
I'll give it a go unless someone else provides some patches...
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* [PATCH] Improve the mingw getaddrinfo stub to handle more use cases
From: Martin Storsjö @ 2009-11-26 10:43 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: msysgit, git, dotzenlabs, Erik Faye-Lund
In-Reply-To: <alpine.DEB.2.00.0911261015140.14228@cone.home.martin.st>
Allow the node parameter to be null, which is used for getting
the default bind address.
Also allow the hints parameter to be null, to improve standard
conformance of the stub implementation a little.
Signed-off-by: Martin Storsjo <martin@martin.st>
---
This patch adds support for the getaddrinfo parameters used by git-daemon,
as mentioned earlier.
compat/mingw.c | 20 +++++++++++++-------
1 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/compat/mingw.c b/compat/mingw.c
index 0653560..17d1314 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -913,19 +913,22 @@ static int WSAAPI getaddrinfo_stub(const char *node, const char *service,
const struct addrinfo *hints,
struct addrinfo **res)
{
- struct hostent *h = gethostbyname(node);
+ struct hostent *h = NULL;
struct addrinfo *ai;
struct sockaddr_in *sin;
- if (!h)
- return WSAGetLastError();
+ if (node) {
+ h = gethostbyname(node);
+ if (!h)
+ return WSAGetLastError();
+ }
ai = xmalloc(sizeof(struct addrinfo));
*res = ai;
ai->ai_flags = 0;
ai->ai_family = AF_INET;
- ai->ai_socktype = hints->ai_socktype;
- switch (hints->ai_socktype) {
+ ai->ai_socktype = hints ? hints->ai_socktype : 0;
+ switch (ai->ai_socktype) {
case SOCK_STREAM:
ai->ai_protocol = IPPROTO_TCP;
break;
@@ -937,14 +940,17 @@ static int WSAAPI getaddrinfo_stub(const char *node, const char *service,
break;
}
ai->ai_addrlen = sizeof(struct sockaddr_in);
- ai->ai_canonname = strdup(h->h_name);
+ ai->ai_canonname = h ? strdup(h->h_name) : NULL;
sin = xmalloc(ai->ai_addrlen);
memset(sin, 0, ai->ai_addrlen);
sin->sin_family = AF_INET;
if (service)
sin->sin_port = htons(atoi(service));
- sin->sin_addr = *(struct in_addr *)h->h_addr;
+ if (h)
+ sin->sin_addr = *(struct in_addr *)h->h_addr;
+ else
+ sin->sin_addr.s_addr = INADDR_ANY;
ai->ai_addr = (struct sockaddr *)sin;
ai->ai_next = 0;
return 0;
--
1.6.4.4
^ permalink raw reply related
* Re: [PATCH/RFC 02/11] strbuf: add non-variadic function strbuf_vaddf()
From: Erik Faye-Lund @ 2009-11-26 10:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: msysgit, git, dotzenlabs, Alex Riesen
In-Reply-To: <7vskc2ksnn.fsf@alter.siamese.dyndns.org>
On Thu, Nov 26, 2009 at 1:59 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Erik Faye-Lund <kusmabite@googlemail.com> writes:
>
>> +void strbuf_vaddf(struct strbuf *sb, const char *fmt, va_list ap)
>> {
>> int len;
>>
>> if (!strbuf_avail(sb))
>> strbuf_grow(sb, 64);
>> len = vsnprintf(sb->buf + sb->len, sb->alloc - sb->len, fmt, ap);
>> if (len < 0)
>> die("your vsnprintf is broken");
>> if (len > strbuf_avail(sb)) {
>> strbuf_grow(sb, len);
>> len = vsnprintf(sb->buf + sb->len, sb->alloc - sb->len, fmt, ap);
>> if (len > strbuf_avail(sb)) {
>> die("this should not happen, your snprintf is broken");
>> }
>
> Hmm, I would have expected to see va_copy() somewhere in the patch text.
> Is it safe to reuse ap like this in two separate invocations of
> vsnprintf()?
>
I think your expectation is well justified, this seems to be a
portability-bug waiting to happen. Sorry for missing this prior to
sending out - on Windows this is known to work, and this function is
currently only used from the Windows implementation of syslog.
How kosher is it to use va_copy in the git-core, considering that it's
C99? A quick grep reveals only one occurrence of va_copy in the
source, and that's in compat/winansi.c. Searching the history of next
reveals that Alex Riesen (CC'd) already removed one occurrence
(4bf5383), so I'm starting to get slightly scared it might not be OK.
In practice it seems that something like the following works
portably-enough for many applications, dunno if it's something we'll
be happy with:
#ifndef va_copy
#define va_copy(a,b) ((a) = (b))
#endif
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* [PATCH (resend)] Let core.excludesfile default to ~/.gitexcludes.
From: Matthieu Moy @ 2009-11-26 10:35 UTC (permalink / raw)
To: git, gitster; +Cc: Matthieu Moy
In-Reply-To: <1258840832-22130-1-git-send-email-Matthieu.Moy@imag.fr>
Most users will set it to ~/.gitsomething. ~/.gitignore would conflict
with per-directory ignore file if ~/ is managed by Git, so ~/.gitexcludes
is a sane default.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
(just resending since the patch seems to have got lost in the process)
Documentation/config.txt | 1 +
dir.c | 9 ++++++++-
2 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 7ff2d1d..9fc527c 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -408,6 +408,7 @@ core.excludesfile::
of files which are not meant to be tracked. "{tilde}/" is expanded
to the value of `$HOME` and "{tilde}user/" to the specified user's
home directory. See linkgit:gitignore[5].
+ Default: ~/.gitexcludes.
core.editor::
Commands such as `commit` and `tag` that lets you edit
diff --git a/dir.c b/dir.c
index 3a8d3e6..a6a6291 100644
--- a/dir.c
+++ b/dir.c
@@ -944,9 +944,16 @@ void setup_standard_excludes(struct dir_struct *dir)
dir->exclude_per_dir = ".gitignore";
path = git_path("info/exclude");
+ if (!excludes_file) {
+ const char *home = getenv("HOME");
+ char *user_gitignore = malloc(strlen(home) + strlen("/.gitexcludes") + 1);
+ strcpy(user_gitignore, home);
+ strcat(user_gitignore, "/.gitexcludes");
+ excludes_file = user_gitignore;
+ }
if (!access(path, R_OK))
add_excludes_from_file(dir, path);
- if (excludes_file && !access(excludes_file, R_OK))
+ if (!access(excludes_file, R_OK))
add_excludes_from_file(dir, excludes_file);
}
--
1.6.5.3.435.g5f2e3.dirty
^ permalink raw reply related
* Re: [egit] Git repository with multiple eclipse projects ?
From: Yann Simon @ 2009-11-26 8:39 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Yann Dirson, git
In-Reply-To: <20091126004817.GL11919@spearce.org>
2009/11/26 Shawn O. Pearce <spearce@spearce.org>:
> Yann Dirson <ydirson@linagora.com> wrote:
>> It also does not look like it would be possible to use the "share"
>> functionnality to setup such a repository from multiple projects (or
>> from a project set), right ?
>
> Nope, I don't think this is supported right now. You need to
> initialize the git repository by hand in the higher level directory
> that holds the projects.
That was the question I initialy understood.
^ permalink raw reply
* Re: OS X and umlauts in file names
From: Thomas Singer @ 2009-11-26 8:28 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Daniel Barkalow, git
In-Reply-To: <m21vjmkyxh.fsf@igel.home>
Hi Andreas,
Thank you for this hint. When trying
toms-mac-mini:git-umlauts tom$ git stage $'U\314\210berla\314\210nge.txt'
git shows me no error or other output, but invoking 'git status' again shows
no difference, the file is still showing up as new file.
I've also tried to use double backslashes, but I could not enter a backslash
in the OS X Terminal (works fine in other applications). :(
--
Tom
Andreas Schwab wrote:
> Thomas Singer <thomas.singer@syntevo.com> writes:
>
>> I've did following:
>>
>> toms-mac-mini:git-umlauts tom$ ls
>> Überlänge.txt
>> toms-mac-mini:git-umlauts tom$ git status
>> # On branch master
>> #
>> # Initial commit
>> #
>> # Changes to be committed:
>> # (use "git rm --cached <file>..." to unstage)
>> #
>> # new file: "U\314\210berla\314\210nge.txt"
>> #
>> toms-mac-mini:git-umlauts tom$ git stage "U\314\210berla\314\210nge.txt"
>> fatal: pathspec 'U\314\210berla\314\210nge.txt' did not match any files
>
> Try $'U\314\210berla\314\210nge.txt' instead.
> "U\314\210berla\314\210nge.txt" is the same as
> "U\\314\\210berla\\314\\210nge.txt" to the shell.
>
> Andreas.
>
^ permalink raw reply
* Re: [PATCH/RFC 01/11] mingw: add network-wrappers for daemon
From: Martin Storsjö @ 2009-11-26 8:24 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: msysgit, git, dotzenlabs, Erik Faye-Lund
In-Reply-To: <1259196260-3064-2-git-send-email-kusmabite@gmail.com>
Hi,
First of all, great that you're working on adding daemon support for
windows!
On Thu, 26 Nov 2009, Erik Faye-Lund wrote:
> +static void wsa_init(void)
> {
> + static int initialized = 0;
> WSADATA wsa;
>
> + if (initialized)
> + return;
> +
> if (WSAStartup(MAKEWORD(2,2), &wsa))
> die("unable to initialize winsock subsystem, error %d",
> WSAGetLastError());
> atexit((void(*)(void)) WSACleanup);
> + initialized = 1;
> +}
Something similar to this was merged into master recently as part of my
mingw/ipv6 patches, so by rebasing your patch on top of that, this patch
will probably get a bit smaller.
Also, the getaddrinfo-compatibility wrappers perhaps may need some minor
updates to handle the use cases needed for setting up listening sockets.
// Martin
^ permalink raw reply
* Re: Please help with GIT install problem.
From: Tom G. Christensen @ 2009-11-26 7:44 UTC (permalink / raw)
To: Stephan T.; +Cc: git
In-Reply-To: <377205.65475.qm@web30806.mail.mud.yahoo.com>
Stephan T. wrote:
> Hello there,
>
> My system is a:
> % uname -a
> Linux naboo 2.4.21-50.ELsmp #1 SMP Tue May 8 17:18:29 EDT 2007 i686 i686 i386 GNU/Linux
>
Looks like you're on RHEL 3 or a derivative.
> Trying to install "git-1.6.5.3". Configure goes happily to the end but make gives me the following error:
>
>> make
> CC fast-import.o
> In file included from /usr/include/openssl/ssl.h:179,
> from git-compat-util.h:138,
> from builtin.h:4,
> from fast-import.c:143:
> /usr/include/openssl/kssl.h:72:18: krb5.h: No such file or directory
> In file included from /usr/include/openssl/ssl.h:179,
> from git-compat-util.h:138,
> from builtin.h:4,
> from fast-import.c:143:
> /usr/include/openssl/kssl.h:134: syntax error before "krb5_enctype"
>
>
> What is missing on my system?
>
You need to add "-I/usr/kerberos/include" to CFLAGS to build with
openssl on el3.
Instead of doing your own build you could install the packages I
maintain for my own use:
http://jupiterrise.com/tmp/git-el3
This is just a temporary location, in the future I hope so have this in
rpmforge.
Not that perl-Git will require perl-Error from rpmforge
(http://packages.sw.be/perl-Error)
-tgc
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2009, #06; Wed, 25)
From: Johan Herland @ 2009-11-26 7:37 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Junio C Hamano, Daniel Barkalow, git
In-Reply-To: <fabb9a1e0911251715u661ce0aem79a4d700d552e105@mail.gmail.com>
On Thursday 26 November 2009, Sverre Rabbelier wrote:
> Heya,
>
> On Thu, Nov 26, 2009 at 02:03, Junio C Hamano <gitster@pobox.com> wrote:
> > * sr/vcs-helper (2009-11-18) 12 commits
> > - Add Python support library for remote helpers
> > - Basic build infrastructure for Python scripts
> > - Allow helpers to report in "list" command that the ref is unchanged
> > - Fix various memory leaks in transport-helper.c
> > - Allow helper to map private ref names into normal names
> > - Add support for "import" helper command
> > - Allow specifying the remote helper in the url
> > - Add a config option for remotes to specify a foreign vcs
> > - Allow fetch to modify refs
> > - Use a function to determine whether a remote is valid
> > - Allow programs to not depend on remotes having urls
> > - Fix memory leak in helper method for disconnect
> >
> > Replaced again, and looking good. Perhaps Daniel has some comments?
>
> Indeed, Johan, Daniel, is the current version good for next?
As I replied to an earlier "What's cooking" email, it all looks good to me,
but I would really like Daniel's ACK on the transport layer parts.
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [PATCH 1/8] git-merge-file --ours, --theirs
From: Nanako Shiraishi @ 2009-11-26 7:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Avery Pennarun, git
In-Reply-To: <7vvdgxbwav.fsf@alter.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com> writes:
> In any case, where does Avery's credit go? Is there a point in helping to
> polish others' patches?
>
> It is recoded on the Signed-off-by line. When somebody passes a patch
> from somebody else, an S-o-b is added for DCO purposes, but it also leaves
> the "patch trail"---these people looked at the patch, spent effort to make
> sure it is suitable for inclusion by reviewing, polishing, and enhancing.
> A subsystem maintainer, or anybody who helps to polish others
> contribution, may not necessarily have his name as the "author" of the
> patch, and if the patch forwarding is done via e-mail, his name won't be
> on the "committer" line either. But the contribution is still noted and
> appreciated, and the hint to pay attention to is by counting non-author
> S-o-b and Tested-by lines in the commit messages.
I understand. Thank you for a detailed explanation.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: cvsexportcommit dies when applying an (empty) merge commit
From: Robin Rosenberg @ 2009-11-26 6:51 UTC (permalink / raw)
To: Nick Woolley; +Cc: git
In-Reply-To: <4B0D1C1A.60707@yahoo.co.uk>
onsdag 25 november 2009 12:59:22 skrev Nick Woolley:
> Hi,
>
> I have a git repository with a merge point on the master branch. This
> merge commit is empty, and just contains a commit message:
>
> Merge commit 'otherbranch'
>
> I'm trying to export this branch into CVS using git-cvsexportcommit (the
> latest version from the master branch). It's actually done in a wrapper
> script [1] but the command that gets invoked is essentially:
>
> git cvsexportcommit -p -v -u -w 'cvscheckout/HEAD/my-cvs-module' -c \
> <parent commit> <commit>
>
> Where <commit> is the empty merge commit. However this invocation dies and
> aborts the process of exporting the branch half way.
>
> The fatal error I get is:
>
> Applying to CVS commit <commit> from parent <parent commit>
> Checking if patch will apply
> Applying
> error: No changes
> cannot patch at /usr/lib/git-core/git-cvsexportcommit line 324.
>
[....]
> Is the existing behaviour deliberately fatal, or is this worth supplying a
> patch for?
I'm not the only contributor, but I'd say its a omission. cvsexportcommit
doesn't export commits. It export deltas, that is the change relative to one
of the parents. It is reasonable that cvsexportcommit can "export" an
empty commit by doing nothing and exiting with 0. Printing some kind of
warning seems reasonable too.
- robin
^ permalink raw reply
* Re: [PATCH 1/8] git-merge-file --ours, --theirs
From: Junio C Hamano @ 2009-11-26 7:05 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Avery Pennarun, git
In-Reply-To: <20091126153726.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Quoting Junio C Hamano <gitster@pobox.com>
>
>> Except for parse-optification, this one is more or less a verbatim copy of
>> my patch, and I think I probably deserve an in-body "From: " line for this
>> [PATCH 1/8], [PATCH 6/8] and [PATCH 8/8] to take the full authorship of
>> them.
>
> Could you give an guideline to decide when to take authorship and when to
> give it to others? The above seems somewhat arbitrary to me.
It might seem that way to you, as you do not write much C, but I am
reasonably sure Avery understands after having worked on the series.
Imagine that Avery were an area expert (the subsystem maintainer) on "git
merge" and downwards, and somebody who did not know that "merge" has
already been rewritten in C, nor some parts of the system have been
rewritten to use parse-options, submitted a patch series for review and
Avery is helping to polish it up [*1*].
As the subsystem maintainer, Avery looks at the patches, updates parts of
the code that is based on obsolete infrastructure, adds lacking tests and
documentation as necessary, and forwards the tested result upwards for
inclusion. How would the messages from Avery to me look?
Patches that were majorly reworked should be attributed to Avery, and
obviously new patches that are added for missing tests should be, too.
For example, changes made to git-merge.sh by the original submitter must
be discarded and redone from scratch to builtin-merge.c, and if you look
at the changes, it would be quite obvious that the original patch wouldn't
have served as anything more than giving the specification.
But the ones with minor updates should retain the original authorship.
It unfortunately is not black-and-white, though.
In any case, where does Avery's credit go? Is there a point in helping to
polish others' patches?
It is recoded on the Signed-off-by line. When somebody passes a patch
from somebody else, an S-o-b is added for DCO purposes, but it also leaves
the "patch trail"---these people looked at the patch, spent effort to make
sure it is suitable for inclusion by reviewing, polishing, and enhancing.
A subsystem maintainer, or anybody who helps to polish others
contribution, may not necessarily have his name as the "author" of the
patch, and if the patch forwarding is done via e-mail, his name won't be
on the "committer" line either. But the contribution is still noted and
appreciated, and the hint to pay attention to is by counting non-author
S-o-b and Tested-by lines in the commit messages.
cf. http://lwn.net/SubscriberLink/363456/50efdecf49af77ba/ check the last
table.
[Footnote]
*1* That somebody happens to be me from 18 months ago, but the important
point here is that the person is not Avery as the subsystem maintainer (in
other words, it is immaterial that it happens to be the same person as the
toplevel maintainer).
^ permalink raw reply
* Re: [PATCH 1/8] git-merge-file --ours, --theirs
From: Nanako Shiraishi @ 2009-11-26 6:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Avery Pennarun, git
In-Reply-To: <7vy6ltdd2l.fsf@alter.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com>
> Except for parse-optification, this one is more or less a verbatim copy of
> my patch, and I think I probably deserve an in-body "From: " line for this
> [PATCH 1/8], [PATCH 6/8] and [PATCH 8/8] to take the full authorship of
> them.
Could you give an guideline to decide when to take authorship and when to
give it to others? The above seems somewhat arbitrary to me.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [PATCH 1/8] git-merge-file --ours, --theirs
From: Junio C Hamano @ 2009-11-26 6:17 UTC (permalink / raw)
To: Avery Pennarun; +Cc: git
In-Reply-To: <d243a513ffb8da4272f7a0e13a711f9b65195c25.1259201377.git.apenwarr@gmail.com>
"Avery Pennarun" <apenwarr@gmail.com> writes:
> ...
> A larger problem is that this tends to encourage a bad workflow by
> allowing them to record such a mixed up half-merge result as a full commit
> without auditing. This commit does not tackle this latter issue. In git,
> we usually give long enough rope to users with strange wishes as long as
> the risky features is not on by default.
Typo/Grammo. "risky features are not on by default".
> (Patch originally by Junio Hamano <gitster@pobox.com>.)
>
> Signed-off-by: Avery Pennarun <apenwarr@gmail.com>
Except for parse-optification, this one is more or less a verbatim copy of
my patch, and I think I probably deserve an in-body "From: " line for this
[PATCH 1/8], [PATCH 6/8] and [PATCH 8/8] to take the full authorship of
them.
> diff --git a/xdiff/xdiff.h b/xdiff/xdiff.h
> index 4da052a..2cce49d 100644
> --- a/xdiff/xdiff.h
> +++ b/xdiff/xdiff.h
> @@ -58,6 +58,11 @@ extern "C" {
> #define XDL_MERGE_ZEALOUS_ALNUM 3
> #define XDL_MERGE_LEVEL_MASK 0x0f
>
> +/* merge favor modes */
> +#define XDL_MERGE_FAVOR_OURS 0x0010
> +#define XDL_MERGE_FAVOR_THEIRS 0x0020
> +#define XDL_MERGE_FAVOR(flags) (((flags)>>4) & 3)
This is a bad change. It forces the high-level layer of the resulting
code to be aware that the favor bits are shifted by 4 and it is different
from what the low-level layer expects. If I were porting it to
parse-options, I would have kept OURS = 1 and THEIRS = 2 as the original
patch, and instead did something like:
ret = xdl_merge(mmfs + 1, mmfs + 0, names[0], mmfs + 2, names[2],
- &xpp, merge_level | merge_style, &result);
+ &xpp, XDL_MERGE_FLAGS(merge_level, merge_style, merge_favor), &result);
with an updated definition like this:
#define XDL_MERGE_FLAGS(level, style, favor) ((level)|(style)|((favor)<<4)
^ 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