Junio C Hamano writes:
> You raised a good point on the issue of external dependencies may
> impact Git as a whole, even for those who are not interested in the
> particular remote helpers at all. I'll have to think about it.
(As I'm sure you know, but starting from the beginning.) There are
Felipe Contreras writes:
> Greg Troxel wrote:
>> In a packaging system, dependencies are much more troublesome.
>> Dependencies have to be declared, and the build limited to use only
>> those declared dependencies, in order to get repeatable builds and
>> binary p
Junio C Hamano writes:
> Peff already covered (1)---it is highly doubtful that a merge is
> "almost always wrong". In fact, if that _were_ the case, we should
> simply be defaulting to rebase, not failing the command and asking
> between merge and rebase like jc/pull-training-wheel topic did.
>
Clearly there is the possibility of creating a corrupt repository when
receiving objects and updating refs, if a crash or power failure causes
data not to get written to disk but that data is pointed to. Journaling
mitigates this, but I'd argue that programs should function safely with
only the g
Matthieu Moy writes:
> What I suggest instead is to edit/track/share template configuration
> files like
>
> ~/.gitconfig.in
> email = me@HOSTNAME@
>
> and then script something like sed -e "s/@HOSTNAME@/$(hostname)/" <
> ~/.gitconfig.in > ~/.gitconfig.
>
> You may also use the include.path func
Jeff King writes:
> On Sat, Aug 10, 2013 at 11:59:21AM +0200, Michael Haggerty wrote:
>
>> I intentionally don't set user.email in my ~/.gitconfig because I use
>> different identities (on the same machine) depending on what project I
>> am committing to (open-source vs. work). After I clone a
Junio C Hamano writes:
> I seem to get a failure from
>
> git ls-files "a*"
>
> in t/t-basic.sh if I link with platform's fnmatch().
Not what you asked, but on NetBSD 5.1, libc fnmatch is used, and with
git 1.8.0.1 that test passes.
This prompted me to look at the rest of the tests. A
[mkstemp truncating output on error]
diff --git c/wrapper.c w/wrapper.c
index 68739aa..a066e2e 100644
--- c/wrapper.c
+++ w/wrapper.c
@@ -229,7 +229,7 @@ int xmkstemp(char *template)
int saved_errno = errno;
const char *nonrelative_template;
-
While one can add tree objects to the index, this is not currently
useful. Therefore, use "git ls-tree -r" as the example to be fed to
--index-info. Add a section explaining about expected index contents.
(Thanks to Junio for explaining this to me in August of 2011.)
Signed-off-by: G
we are using git since may and all is working fine for all of us
(almost 20 people) on our workstations. However, when we clone our
repositories to the cluster, only and only there
we are having many problems similiar to this post:
What filesystem tests have you run on lustre? I would r
Junio C Hamano writes:
> [query about NetBSD-6]
> The "2.7" bit certainly looks fishy, as users should be able to
> choose between "2.6" and "2.7" (and possibly "3.0"), IIUC.
>
> + PYTHON_PATH = /usr/pkg/bin/python2.7
> + PERL_PATH = /usr/pkg/bin/perl
(I am one of the people who maint
Junio C Hamano writes:
> I would appreciate if somebody with more familiarlity with the
> platform can suggest a better alternative than applying the
> following patch to our Makefile. Right now I have an equivalent of
> this change in config.mak locally when building on the said
> platform.
I
Junio C Hamano writes:
> Greg Troxel writes:
>
>> I realize a README.foo file for N different systems could be clutter,
>> but having these checked in would provide the concise help that people
>> on any of those platforms need.
>
> Our Makefile documents knobs p
Junio C Hamano writes:
> I forgot to mention that we also ship configure (and keep track of
> configure.ac) so that optionally people can let autoconf machinery
> to create config.mak.autogen to be included at the same place as
> handcrafted config.mak in their build process. I do not offhand
>
Junio C Hamano writes:
>> [OLD_ICONV]
> It refers to the type of the second parameter to iconv(); OLD_ICONV
> makes it take "const char *", as opposed to "char *", the latter of
> which matches
>
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/iconv.html
I just wanted to follow
Junio C Hamano writes:
> Don't get too offended by the "OLD_" prefix to that symbol, by the
> way. I do not think "old" means "old and broken hence fixed in
> newer version and you are low life if you live on a platform that
> has to define it" ;-).
Thanks - it did throw me at the beginning, b
René Scharfe writes:
> invalid_ref() constructs a test case description using its last argument,
> but the shell seems to split it up into two pieces if it contains a
> space. Minimal test case:
This is indeed a bug in NetBSD's shell, which I reported after finding
this test case problem, and
René Scharfe writes:
> The test fails for me on NetBSD 6.0.1 and reports:
>
> ok 1 - ref name '' is invalid
> ok 2 - ref name '/' is invalid
> ok 3 - ref name '/' is invalid with options --allow-onelevel
> ok 4 - ref name '/' is invalid with options --normalize
> er
As one of the people who helps maintain git packages in pkgsrc, my
initial reaction is negative to adding a ruby dependency. There are
several not-entirely-related reasons:
git is a core tool that people use on almost the smallest of boxes,
perhaps even replacing rcs for managing local config fi
Felipe Contreras writes:
> On Thu, Jun 6, 2013 at 9:54 AM, Greg Troxel wrote:
>>
>> git is a core tool that people use on almost the smallest of boxes,
>> perhaps even replacing rcs for managing local config files. On such
>> machines, even perl may be large, but
I'm trying to setup a workflow to track vendor releases (upstream).
Each new release are provided as an archive of source code, data,
documentation, etc.
I've been doing more or less this. A few comments:
I suggest that you not view CRLF->LF as a "patch". I would do EOL
hygiene as a
Ralf Thielow writes:
> On Sat, Sep 22, 2012 at 11:57 PM, Sascha Cunz wrote:
>> Original:
>> ... and I wonder if you are in the middle of another rebase.
>>
>> German git translation:
>> ... und es wäre verwunderlich, wenn ein Neuaufbau bereits im Gange ist.
>>
>> And a re-translation back to En
I suggest that you read (all of)
http://www.git-scm.com/book
and then perhaps ask a question based on more understanding of the merge
model and ancestry tracking. The short answer is that git will work
quite well in terms of conflict management if your development practices
are sane.
pg
23 matches
Mail list logo
