* Re: [PATCH] Update packfile transfer protocol documentation
From: Shawn O. Pearce @ 2009-11-02 23:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Scott Chacon, git list
In-Reply-To: <7vzl74trmc.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> Scott Chacon <schacon@gmail.com> writes:
> > +
> > +A pack-file MUST be sent if either create or update command is used.
>
> Easier to read if MUST is followed by "_even_ if", like so:
>
> ... MUST be sent when a create or update command is used, even if the
> server already has all the necessary objects.
>
> Shouldn't we say "the client MUST NOT make reference update request if
> everything is up to date" which would imply that in practice there is no
> reason to send an empty pack data?
Create a new branch to point at an existing object. Branch creation
causes a pack to be expected, but if you are creating a new branch
that points at an existing object there is nothing to pack. E.g.:
git remote add -f A user@host:proj.git
git push A A/master:refs/heads/new-branch
causes a 0 object pack file to be sent, assuming the remote project's
master branch has not changed in between the two commands.
> > + pack-file = "PACK" 24*(OCTET)
>
> Curious---where does this 24 come from?
Hmmph. Its wrong actually. I was trying to write the minimum
number of bytes that make up a pack file, which is actually 28.
(12 in the header minus 4 as "PACK" was already spelled out, plus
20 in the footer for the SHA-1).
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Update packfile transfer protocol documentation
From: Junio C Hamano @ 2009-11-03 0:36 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Scott Chacon, git list
In-Reply-To: <20091102235707.GV10505@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Junio C Hamano <gitster@pobox.com> wrote:
> ...
>> Shouldn't we say "the client MUST NOT make reference update request if
>> everything is up to date" which would imply that in practice there is no
>> reason to send an empty pack data?
>
> Create a new branch to point at an existing object. Branch creation
> causes a pack to be expected, but if you are creating a new branch
> that points at an existing object there is nothing to pack. E.g.:
>
> git remote add -f A user@host:proj.git
> git push A A/master:refs/heads/new-branch
>
> causes a 0 object pack file to be sent, assuming the remote project's
> master branch has not changed in between the two commands.
Ahh, you are right. Thanks.
^ permalink raw reply
* Re: [PATCH] Update packfile transfer protocol documentation
From: Shawn O. Pearce @ 2009-11-03 0:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Scott Chacon, git list
In-Reply-To: <7vtyxctpf8.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
> > Junio C Hamano <gitster@pobox.com> wrote:
> > ...
> >> Shouldn't we say "the client MUST NOT make reference update request if
> >> everything is up to date" which would imply that in practice there is no
> >> reason to send an empty pack data?
Creating new branch quirk aside, I do agree with this. Clients
shouldn't send no-op updates if it knows in advance the update is
a no-op.
--
Shawn.
^ permalink raw reply
* Problem signing a tag
From: Joshua J. Kugler @ 2009-11-03 0:58 UTC (permalink / raw)
To: git
Nobody on the git IRC channel responded to this question, even after
asking it a few times, so I thought I'd try here.
I'm having trouble signing a tag. I'm using this command:
git tag -u EAFD344D14EA086E -F .git/TAG_EDITMSG tag_name
I type in my passphrase, and am then told:
error: gpg failed to sign the tag
error: unable to sign the tag
However, if I use this command:
gpg -s -u EAFD344D14EA086E
and use the same passphrase, it works fine. Is there any way to find out
why a key-signing is failing?
This is git 1.6.5.2 and gpg 1.4.9
Thanks!
j
--
Joshua Kugler
Part-Time System Admin/Programmer
http://www.eeinternet.com
PGP Key: http://pgp.mit.edu/ ID 0x14EA086E
^ permalink raw reply
* Re: using merge subtree and move it..
From: Milos Jakubicek @ 2009-11-03 2:57 UTC (permalink / raw)
To: git
In-Reply-To: <48C64911.4020202@posdata.co.kr>
SungHyun Nam wrote:
>
>
> BTW, I have no idea how I can push 'local changes in subtree' to remote.
> The 'Additional tips' in using-merge-subtree.txt said it is
> possible using subtree. But don't know how? Could someone show me
> a sample command/setup sequence?
>
I found out:
edit your .git/config file and in the [remote "remotename"] section, copy
the "fetch =" line as "push =" line (with same content after "="). Then by
"git push remotename" you'll just push the relevant subtree.
--
View this message in context: http://n2.nabble.com/using-merge-subtree-and-move-it-tp1076542p3936273.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* git subtree issues
From: morgflast @ 2009-11-03 3:56 UTC (permalink / raw)
To: git
So, I went ahead and did this
$ git remote add -f vw_extensions git@github.com:sibblingz/vw_extensions.git
(1)
$ git merge -s ours --no-commit vw_extensions/master (2)
$ git read-tree --prefix=some/directory/vw_extensions -u
vw_extensions/master (3)
$ git commit -m "Merge B project as our subdirectory"
And that all seems to work ok.
Then, I went to another directory where i had vw_extensions cloned, and made
a change to the README file, and pushed it.
I went back to my first project, and did this, to try to pull those changes:
git pull -s subtree vw_extensions master remote: Counting objects: 5, done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 3 (delta 2), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From git@github.com:sibblingz/vw_extensions
* branch master -> FETCH_HEAD
Already uptodate!
Merge made by subtree.
However, when I looked at the README file in the first project, the changes
weren't there. I was wondering if anyone might have any suggestions about
what to do.
Thanks!
Daniel
--
View this message in context: http://old.nabble.com/git-subtree-issues-tp26159961p26159961.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: git pull --rebase and losing commits
From: Randal L. Schwartz @ 2009-11-03 4:27 UTC (permalink / raw)
To: Peter Krefting; +Cc: Git Mailing List
In-Reply-To: <alpine.DEB.2.00.0911021318400.3919@ds9.cixit.se>
>>>>> "Peter" == Peter Krefting <peter@softwolves.pp.se> writes:
Peter> git pull --rebase --strategy=ours origin master
"No good can come of this."
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
^ permalink raw reply
* how to rebase backwards
From: bill lam @ 2009-11-03 5:45 UTC (permalink / raw)
To: git
I want to rebase a new branch onto an earlier commit
original:
E is a newly created branch from D and not yet modified
E
/
-- A -- B -- C -- D
new: what I wanted
B'-- C' -- E for deployment
/
-- A -- B -- C -- D trunk
so that I can continue to change all commits from B to C without
affecting E
I try (not sure if correct) doing it by
git rebase --onto A B E
but then there is a lot of conflict/both modified files. What will be
the correct way to do it?
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
^ permalink raw reply
* Re: git pull --rebase and losing commits
From: Peter Krefting @ 2009-11-03 7:01 UTC (permalink / raw)
To: Thomas Rast, Björn Steinbrink; +Cc: Git Mailing List
In-Reply-To: <20091102151022.GA3995@atjola.homenet>
Thomas Rast:
> Not very surprising if you use the 'ours' strategy, which doesn't merge at
> all but instead takes the 'ours' side (IIRC that's the upstream for a
> rebase, but I always have these mixed up).
Sounds like it should be called "theirs", then. Or the documentation should
be clarify.
> So what happens is that git-rebase rebuilds some commit C from your side
> on some base B from the remote, but the 'ours' strategy turns the *tree*
> for C' into that of B.
Right. I thought it was working on the individual blobs (I want it to
automatically resolve conflicts by applying the version that is in the
repository I am running the rebase from, no matter what).
Björn Steinbrink:
> The "ours" strategy doesn't just avoid merge conflicts, it avoids making
> any changes at all. The ours strategy means "just keep our state, just
> pretend that we've merged". And rebase will see that there were no
> changes and conclude:
>
> Already applied: 0001 test commit
>
> And thus it will drop the commit.
I've seen that message show up in my logs a couple of times. I'd better drop
the --strategy=ours, then. :-/
Now to figure out if it is possible to get a setup like this working at all.
Maybe dropping rebase in favour of regular merge may help a bit, but I still
want it to auto-resolve any conflicts for me.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: [PATCH 0/4] Cygwin MSVC patches
From: Johannes Sixt @ 2009-11-03 7:08 UTC (permalink / raw)
To: Ramsay Jones; +Cc: Junio C Hamano, GIT Mailing-list, mstormo
In-Reply-To: <4AE8C3FD.2020300@ramsay1.demon.co.uk>
Ramsay Jones schrieb:
> Johannes Sixt wrote:
>> Ramsay Jones schrieb:
>>> With these patches, the msvc build on cygwin seems to be working fine.
>> What is "the msvc build on cygwin"?
>
> The same as the msvc build on msys-MinGW, but replace msys-MinGW
> with Cygwin ;-)
>
>> Is it "git built with msvc, then run in cygwin"?
>
> Yes, but... *in theory* the cygwin msvc-built binaries could be transferred
> to an msys system and they should work (exactly as the msvc build on msys).
> Since I don't have an msys installation, I can't test that... so I won't
> guarantee it will work!
>
> Any git needs a (bash-like) shell, perl, Tcl/Tk, ... etc.
Just to check I understand correctly: you are running "make MSVC=1" on
cygwin, and then you are using the resulting binaries with the POSIX tools
from cygwin.
-- Hannes
^ permalink raw reply
* Re: [PATCH 1/4] MSVC: Fix an "unresolved symbol" linker error on cygwin
From: Johannes Sixt @ 2009-11-03 7:21 UTC (permalink / raw)
To: Ramsay Jones; +Cc: Junio C Hamano, GIT Mailing-list, Marius Storm-Olsen
In-Reply-To: <4AE74408.7080103@ramsay1.demon.co.uk>
Ramsay Jones schrieb:
> When the NO_MMAP build variable is set, which is the case by
> default on cygwin, the msvc linker complains:
>
> error LNK2001: unresolved external symbol _getpagesize
Make up your mind: use the cygwin configuration or use the MSVC
configuration. MSVC doesn't define NO_MMAP for a reason. Where is the problem?
I understand that you run into this error if you define NO_MMAP in your
config.mak. I don't know whether we support NO_MMAP as a knob for to tweak
the builds on all platforms. If this is the case (Junio?), then your
justification must be updated.
-- Hannes
^ permalink raw reply
* Re: [PATCH 2/4] Makefile: merge two Cygwin configuration sections into one
From: Johannes Sixt @ 2009-11-03 7:22 UTC (permalink / raw)
To: Ramsay Jones
Cc: Junio C Hamano, GIT Mailing-list, Marius Storm-Olsen, dpotapov
In-Reply-To: <4AE745FB.1060902@ramsay1.demon.co.uk>
Ramsay Jones schrieb:
> diff --git a/Makefile b/Makefile
> index fea237b..8e1cfc5 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -782,6 +782,8 @@ ifeq ($(uname_O),Cygwin)
> NO_MMAP = YesPlease
> NO_IPV6 = YesPlease
> X = .exe
> + COMPAT_OBJS += compat/cygwin.o
> + UNRELIABLE_FSTAT = UnfortunatelyYes
> endif
> ifeq ($(uname_S),FreeBSD)
> NEEDS_LIBICONV = YesPlease
> @@ -891,10 +893,6 @@ ifeq ($(uname_S),HP-UX)
> NO_SYS_SELECT_H = YesPlease
> SNPRINTF_RETURNS_BOGUS = YesPlease
> endif
> -ifneq (,$(findstring CYGWIN,$(uname_S)))
> - COMPAT_OBJS += compat/cygwin.o
> - UNRELIABLE_FSTAT = UnfortunatelyYes
> -endif
> ifdef MSVC
> GIT_VERSION := $(GIT_VERSION).MSVC
> pathsep = ;
I think this an obviously good change even outside this series.
-- Hannes
^ permalink raw reply
* Re: [PATCH 3/4] Makefile: keep MSVC and Cygwin configuration separate
From: Johannes Sixt @ 2009-11-03 7:27 UTC (permalink / raw)
To: Ramsay Jones; +Cc: Junio C Hamano, GIT Mailing-list, Marius Storm-Olsen
In-Reply-To: <4AE74659.6020503@ramsay1.demon.co.uk>
Ramsay Jones schrieb:
> Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
> ---
> Makefile | 13 ++++++++++---
> 1 files changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 8e1cfc5..12c8249 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -658,6 +658,14 @@ EXTLIBS =
> # Platform specific tweaks
> #
>
> +ifdef MSVC
> + # When building with msvc, on MinGW or Cygwin, we
> + # override the uname settings to make it easier to
> + # keep the configuration sections separate
> + uname_S = Windows
> + uname_O = Windows
> +endif
> +
> # We choose to avoid "if .. else if .. else .. endif endif"
> # because maintaining the nesting to match is a pain. If
> # we had "elif" things would have been much nicer...
> @@ -893,7 +901,7 @@ ifeq ($(uname_S),HP-UX)
> NO_SYS_SELECT_H = YesPlease
> SNPRINTF_RETURNS_BOGUS = YesPlease
> endif
> -ifdef MSVC
> +ifeq ($(uname_S),Windows)
> GIT_VERSION := $(GIT_VERSION).MSVC
> pathsep = ;
> NO_PREAD = YesPlease
> @@ -945,7 +953,7 @@ else
> BASIC_CFLAGS += -Zi -MTd
> endif
> X = .exe
> -else
> +endif
> ifneq (,$(findstring MINGW,$(uname_S)))
> pathsep = ;
> NO_PREAD = YesPlease
> @@ -994,7 +1002,6 @@ else
> NO_PTHREADS = YesPlease
> endif
> endif
> -endif
>
> -include config.mak.autogen
> -include config.mak
I like the direction of this change, but I think that you must use ':='
assignment, and I would put this right after the uname_* assignments at
the beginning of the Makefile:
uname_V := $(shell sh -c 'uname -v 2>/dev/null || echo not')
+ifdef MSVC
+ uname_S := Windows
+ uname_O := Windows # avoid cygwin configuration
+endif
-- Hannes
^ permalink raw reply
* Re: Problem signing a tag
From: Alex Riesen @ 2009-11-03 7:31 UTC (permalink / raw)
To: Joshua J. Kugler; +Cc: git
In-Reply-To: <200911021558.17550.joshua@eeinternet.com>
On Tue, Nov 3, 2009 at 01:58, Joshua J. Kugler <joshua@eeinternet.com> wrote:
> Nobody on the git IRC channel responded to this question, even after
> asking it a few times, so I thought I'd try here.
>
> I'm having trouble signing a tag. I'm using this command:
>
> git tag -u EAFD344D14EA086E -F .git/TAG_EDITMSG tag_name
>
> I type in my passphrase, and am then told:
>
> error: gpg failed to sign the tag
> error: unable to sign the tag
>
> However, if I use this command:
>
> gpg -s -u EAFD344D14EA086E
>
> and use the same passphrase, it works fine. Is there any way to find out
> why a key-signing is failing?
What does "echo $?" after it prints? IOW, maybe plain gpg fails too,
without printing anything special, and you don't pay attention to the
exit code. Git does. And it runs "gpg -bsau <key-id>".
^ permalink raw reply
* Re: [PATCH 4/4] win32: Improve the conditional inclusion of WIN32 API code
From: Johannes Sixt @ 2009-11-03 7:41 UTC (permalink / raw)
To: Ramsay Jones; +Cc: Junio C Hamano, GIT Mailing-list, Marius Storm-Olsen
In-Reply-To: <4AE746C6.9060409@ramsay1.demon.co.uk>
Ramsay Jones schrieb:
> After experimenting with several win32 compilers, it is clear
> that the _WIN32 macro should be used to guard the inclusion
> of the main WIN32 API header files, particularly in the main
> git-compat-util.h header. In addition, the cygwin build should
> restrict the use of the WIN32 API to compat/cygwin.c
>
> In order to avoid mistakes with the use of WIN32 and _WIN32
> macros, define a new WIN32_API macro, with a single point of
> definition in git-compat-util.h, to isolate WIN32 specific
> code.
IMO, the name "WIN32_API" is very misleading. It suggests that it can be
used to protect sections of code that use the API. But in fact all places
outside (and even some places in) the compatibility layer use "WIN32" to
protect *platform* specific code (as opposed to the API specific code).
In this light, the name "WIN32" isn't to the point, either, but it does at
least not pretend that the code is about API.
Therefore, I think that a better change would be to treat _WIN32 and WIN32
as synonyms, and to make sure that both are defined if at least one of
them is defined.
It may be that I understand something incorrectly; but then I blame the
justification that you gave. In this case, it would be helpful to reword
the commit message, and perhaps add some results from your experiments.
-- Hannes
^ permalink raw reply
* Re: how to rebase backwards
From: Junio C Hamano @ 2009-11-03 7:43 UTC (permalink / raw)
To: bill lam; +Cc: git
In-Reply-To: <20091103054510.GB7117@debian.b2j>
bill lam <cbill.lam@gmail.com> writes:
> I want to rebase a new branch onto an earlier commit
>
> original:
> E is a newly created branch from D and not yet modified
>
> E
> /
> -- A -- B -- C -- D
I sense a grave misconception here. If you have "not yet modified"
anything at all since D, then E does *not* even exist.
Remember, a branch is just a pointer pointing at a commit. You can have
more than one such pointers pointing at the same commit. So, if you have
been working on 'master' branch, building up to D, your history would look
like this:
---A---B---C---D
^ master
And you would "create a branch", say "hack", like this:
$ git checkout -b hack
What happens to your history when you do so is this:
v hack
---A---B---C---D
^ master
The same commit "D", pointed by two branches, 'master' and 'hack'.
If you start editing files at this point, before making a commit, nothing
in the history changes. But once you make a commit E while on branch
'hack' (since you ran "git checkout -b hack" above), the history changes
into this:
E
/^ hack
---A---B---C---D
^ master
> new: what I wanted
>
> B'-- C' -- E for deployment
> /
> -- A -- B -- C -- D trunk
>
> so that I can continue to change all commits from B to C without
> affecting E
>
> I try (not sure if correct) doing it by
> git rebase --onto A B E
This asks to replay C, D and E in this order on top of A, to create
C'--D'--E'
/
-- A
which is different from what you described earlier.
Assuming that you did actually commit to create E, after branching 'hack'
off of 'master', i.e. your history looks like this:
E
/^ hack
---A---B---C---D
^ master
the way to create what you want would actually be
$ git checkout -b deploy master^ ;# branch deploy at "C"
$ git cherry-pick hack ;# replay E on top of it
which would make a history of this shape.
v deploy
E' E
/ /^ hack
---A---B---C---D
^ master
If you need to later tweak B and C (only) for deployment branch, you could
further rewrite B and/or C with
$ git rebase -i A
to rewrite everything since A leading to the tip of your current branch
(i.e. E'), to result in
v deploy
B'--C'--E"
/
/ E' E
/ / /^ hack
---A---B---C---D
^ master
Now, you may not want to keep both 'hack' and 'deploy'. Perhaps you
forked 'deploy' and modified for E but it was done on top of D that you
did not want to include in 'deploy' by mistake. IOW, you might have done
this:
E
/^ deploy
---A---B---C---D
^ master
Another way to make 'deploy' point at the result of replaying E on top of
C when your history looks like this is (assuming you are on 'deploy'):
$ git reset --hard HEAD^^ ;# reset to "C"
$ git cherry-pick @{1} ;# cherry-pick "E"
That would give you a history of this shape:
v deploy
E' E
/ /
---A---B---C---D
^ master
Note that the original commit "E" becomes dangling and it will eventually
be garbage-collected.
^ permalink raw reply
* Re: [PATCH 2/4] Makefile: merge two Cygwin configuration sections into one
From: Junio C Hamano @ 2009-11-03 7:46 UTC (permalink / raw)
To: Johannes Sixt
Cc: Ramsay Jones, Junio C Hamano, GIT Mailing-list,
Marius Storm-Olsen, dpotapov
In-Reply-To: <4AEFDA3F.2070405@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Ramsay Jones schrieb:
>> diff --git a/Makefile b/Makefile
>> index fea237b..8e1cfc5 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -782,6 +782,8 @@ ifeq ($(uname_O),Cygwin)
>> NO_MMAP = YesPlease
>> NO_IPV6 = YesPlease
>> X = .exe
>> + COMPAT_OBJS += compat/cygwin.o
>> + UNRELIABLE_FSTAT = UnfortunatelyYes
>> endif
>> ifeq ($(uname_S),FreeBSD)
>> NEEDS_LIBICONV = YesPlease
>> @@ -891,10 +893,6 @@ ifeq ($(uname_S),HP-UX)
>> NO_SYS_SELECT_H = YesPlease
>> SNPRINTF_RETURNS_BOGUS = YesPlease
>> endif
>> -ifneq (,$(findstring CYGWIN,$(uname_S)))
>> - COMPAT_OBJS += compat/cygwin.o
>> - UNRELIABLE_FSTAT = UnfortunatelyYes
>> -endif
>> ifdef MSVC
>> GIT_VERSION := $(GIT_VERSION).MSVC
>> pathsep = ;
>
> I think this an obviously good change even outside this series.
Thanks; I think this one makes sense.
^ permalink raw reply
* Re: [PATCH 1/4] MSVC: Fix an "unresolved symbol" linker error on cygwin
From: Junio C Hamano @ 2009-11-03 8:09 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Ramsay Jones, GIT Mailing-list, Marius Storm-Olsen
In-Reply-To: <4AEFD9E2.6060004@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Ramsay Jones schrieb:
>> When the NO_MMAP build variable is set, which is the case by
>> default on cygwin, the msvc linker complains:
>>
>> error LNK2001: unresolved external symbol _getpagesize
>
> Make up your mind: use the cygwin configuration or use the MSVC
> configuration. MSVC doesn't define NO_MMAP for a reason. Where is the problem?
>
> I understand that you run into this error if you define NO_MMAP in your
> config.mak. I don't know whether we support NO_MMAP as a knob for to tweak
> the builds on all platforms. If this is the case (Junio?), then your
> justification must be updated.
I don't _mind_ per-se if platform people add good support for building
with both using and not using mmap(), even though I do not see a strong
need for supporting NO_MMAP configuration, on a platform with a working
good-quality mmap(), either emulation or native.
How does Cygwin-ness of the build environment affect the end result when
you build with MSVC? I am not a Windows person, so I am only guessing,
but I suspect that the result does not pull any library nor crt0 from what
people usually consider "Cygwin environment". It feels that the "default
configuration of Cygwin" that insists on NO_MMAP is the guilty party here.
The logic to set NO_MMAP on Cygwin obviously predates MSVC support, so it
probably was perfectly sane to say "We are compiling on Cygwin, and by
definition we use gcc to compile, link with the Cygwin libraries, and
mmap() support there is weak and we are better off with NO_MMAP from
performance (or correctness) standpoint".
If we are supporting use of MSVC as compiler toolchain on Cygwin, that
statement may no longer be true [*1*].
Shouldn't this be solved by teaching the Makefile about this new "Cygwin
but using MSVC as compiler toolchain" combination? "Even on Cygwin, if we
are using MSVC, here are the compat layers we want to use and here are
what the underlying C library and POSIX emulation layer gives us."
So it really boils down to this question. Is there _anything_ in the end
result that should be affected by Cygwin-ness of the build environment
when you build with MSVC?
Here are what I see in the Cygwin section:
NO_D_TYPE_IN_DIRENT = YesPlease
NO_D_INO_IN_DIRENT = YesPlease
NO_STRCASESTR = YesPlease
NO_MEMMEM = YesPlease
NO_MKSTEMPS = YesPlease
NO_SYMLINK_HEAD = YesPlease
NEEDS_LIBICONV = YesPlease
NO_FAST_WORKING_DIRECTORY = UnfortunatelyYes
NO_TRUSTABLE_FILEMODE = UnfortunatelyYes
OLD_ICONV = UnfortunatelyYes
NO_MMAP = YesPlease
NO_IPV6 = YesPlease
These all look very much like they depend on the way how C runtime library
and the POSIX emulation layer are set up. Perhaps these should be used
only when compiling with gcc and linking with glibc on Cygwin (which is
the norm)?
[Footnote]
*1* Notice "if" at the beginning of this sentence---I am not qualified to
make a judgement without help from area experts here. Is it a sane thing
to run Cygwin and still use MSVC as the compiler toolchain? Is it
commonly done? I have no idea.
^ permalink raw reply
* Error in Git
From: Ravindra @ 2009-11-03 8:51 UTC (permalink / raw)
To: git
Hi,
When i execute the git command for the url git://git.openezx.org/sgh-i900.git I am getting the following error,
Please let me know how to solve this.
error: waitpid (async) failed
fatal: error in sideband demultiplexer
Regards,
Ravindra K.
^ permalink raw reply
* Re: how to rebase backwards
From: bill lam @ 2009-11-03 9:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: bill lam, git
In-Reply-To: <7vocnkt5o4.fsf@alter.siamese.dyndns.org>
Thank you for detail explanation. From what you described, I begin
with master commit D,
$ git checkout -b deploy
$ git commit --allow-empty -m deploy
E
/^ deploy
---A---B---C---D
^ master
$ git rebase -i A
v deploy
B'--C'--D'--E'
/
---A---B---C---D
^ master
since E is an empty commit, I suppose content of D' E' and D are
identical at this point. Is that correct?
If several months later, I forget which is the common ancestor for
master and deploy, how do I generate the above graph or identify
commit A as the common ancestor for these two branches?
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
^ permalink raw reply
* Re: [PATCH] Re: Gitk --all error when there are more than 797 refs in a repository
From: Paul Mackerras @ 2009-11-03 9:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pat Thoyts, Johannes Sixt, Murphy, John, git
In-Reply-To: <7vd45io7da.fsf@alter.siamese.dyndns.org>
Junio C Hamano writes:
> Paul Mackerras <paulus@samba.org> writes:
>
> > If git log had an argument to tell it to mark those commits that were
> > a starting point or a finishing point, then I could simplify this
> > logic enormously, plus we wouldn't have to pass a long parameter list
> > to git log. It may still turn out to be necessary to add a negative
> > argument for each previous starting point, though, when refreshing the
> > list.
> >
> > I think the simplest fix for now is to arrange to take the
> > non-optimized path on windows when the list of revs gets too long,
> > i.e., set $vcanopt($view) to 0 and take that path. That means that
> > refreshing the view will be slow, but I think it's the best we can do
> > at this point.
>
> Hmph.
>
> The negative ones you can learn by giving --boundary, but I do not think
> the set of starting points are something you can get out of log output.
>
> Even if you could, you would have the same issue giving them from the
> command line anyway. The right solution would likely to be to give the
> same --stdin option as rev-list to "git log", I think.
A --stdin option to git log would be great, but it doesn't seem to be
implemented yet. How hard would it be to add?
Paul.
^ permalink raw reply
* Re: git pull --rebase and losing commits
From: Johannes Schindelin @ 2009-11-03 9:52 UTC (permalink / raw)
To: Peter Krefting; +Cc: Thomas Rast, Björn Steinbrink, Git Mailing List
In-Reply-To: <alpine.DEB.2.00.0911030757400.15633@ds9.cixit.se>
Hi,
On Tue, 3 Nov 2009, Peter Krefting wrote:
> Thomas Rast:
>
> > Not very surprising if you use the 'ours' strategy, which doesn't merge at
> > all but instead takes the 'ours' side (IIRC that's the upstream for a
> > rebase, but I always have these mixed up).
>
> Sounds like it should be called "theirs", then.
Why should it be called "theirs" when it takes "ours"?
Note: the thing I think Thomas wanted to clarify is that this strategy
does not _resolve conflicts_ to "our" version, but it just outright
ignores "theirs". IOW, after a merge with the "ours" strategy,
"HEAD^{tree}" and "HEAD^^{tree}" will point to _exactly the same object_.
If you want to use any merge strategy, you must understand what it does
first. There is no way around that. No change in UI, or in the core code
of Git, can relieve you of this obligation.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Re: Gitk --all error when there are more than 797 refs in a repository
From: Alex Riesen @ 2009-11-03 10:04 UTC (permalink / raw)
To: Junio C Hamano
Cc: Pat Thoyts, Johannes Sixt, Murphy, John, Paul Mackerras, git
In-Reply-To: <7v1vlzvjtg.fsf@alter.siamese.dyndns.org>
On Tue, Sep 22, 2009 at 02:39, Junio C Hamano <gitster@pobox.com> wrote:
> Pat Thoyts <patthoyts@users.sourceforge.net> writes:
>> if {$revs eq {}} {
>> set revs HEAD
>> + } elseif {$revs eq "--all"} {
>> + return $revs
>> }
>
> That looks like an ugly hack (aka sweeping the issue under the rug).
>
And it is a race condition. By the time git log has got --all list of references
it may look completely different to what gitk has.
^ permalink raw reply
* Re: git pull --rebase and losing commits
From: Peter Krefting @ 2009-11-03 10:12 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Thomas Rast, Björn Steinbrink, Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0911031047510.4985@pacific.mpi-cbg.de>
Johannes Schindelin:
>> Sounds like it should be called "theirs", then.
> Why should it be called "theirs" when it takes "ours"?
Because it took "their" (= upstream) tree, not "our" (= local branch) tree.
Seems to me the name is a bit confusing in the case of a rebase, as I am
"merging" my changes *onto* the upstream, not the other way round as would
be the case with a regular merge.
> Note: the thing I think Thomas wanted to clarify is that this strategy
> does not _resolve conflicts_ to "our" version, but it just outright
> ignores "theirs". IOW, after a merge with the "ours" strategy,
> "HEAD^{tree}" and "HEAD^^{tree}" will point to _exactly the same object_.
And in the case of a rebase, the other way around: With --rebase
--strategy=ours, I am basically asking to throw all my local commits away?
> If you want to use any merge strategy, you must understand what it does
> first. There is no way around that. No change in UI, or in the core code
> of Git, can relieve you of this obligation.
No, that is why I recommended that what needed clarification was the
documentation. I read the documentation of "ours":
"This resolves any number of heads, but the result of the merge is
always the current branch head. It is meant to be used to
supersede old development history of side branches."
and thought that it meant that it
a) could resolve a merge conflict, no matter the number of branches involved
("resolves any number of heads").
b) would replace any merge conflict with the contents in the current
repository's branch ("result of the merge is always the current branch head").
Apparently, the "used to supersede old development history" means that it
actually throws the entire contents of one of the branches out, which is not
what I wanted. I didn't understand that from the documentation, however.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: git pull --rebase and losing commits
From: Thomas Rast @ 2009-11-03 10:12 UTC (permalink / raw)
To: Peter Krefting; +Cc: Björn Steinbrink, Git Mailing List
In-Reply-To: <alpine.DEB.2.00.0911030757400.15633@ds9.cixit.se>
Peter Krefting wrote:
> Thomas Rast:
>
> > Not very surprising if you use the 'ours' strategy, which doesn't merge at
> > all but instead takes the 'ours' side (IIRC that's the upstream for a
> > rebase, but I always have these mixed up).
>
> Sounds like it should be called "theirs", then. Or the documentation should
> be clarify.
The problem isn't that ours and theirs are swapped, it's that in a
rebase, the 'ours' side is the upstream and 'theirs' is the commit you
are currently rebasing. This makes sort of sense, because you are
rebuilding your commit on top of the upstream (or actually, the so-far
rebuilt commits, starting with the upstream), so the merge happens
"on" the upstream.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ 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