* Re: [RFC PATCH 6/8] Remove special casing of http, https and ftp
From: Daniel Barkalow @ 2009-12-01 19:15 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: git
In-Reply-To: <1259675838-14692-7-git-send-email-ilari.liusvaara@elisanet.fi>
On Tue, 1 Dec 2009, Ilari Liusvaara wrote:
> HTTP, HTTPS and FTP are no longer special to transport code. Also
> add support for FTPS (curl supports it so it is easy).
We've been through this extensively, and settled on having a special case
for URLs that specify a pure location. That is, the distinction between
http and ftp is at the level of how you get to the content for that
location, not what you do to interact with it. (Even with webdav or the
git-specific smart server support, we use the same detection method on all
locations, and ftp simply never has the possibility of having these
features detected.)
It would be fine to add "ftps" to the list of URL schemes that indicate a
pure location, except that it's plausible that ftps supports writing, but
obviously not by webdav, which is what the push support via curl will
attempt, so it's more likely to be confusing than helpful.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: multiple working directories for long-running builds (was: "git merge" merges too much!)
From: Greg A. Woods @ 2009-12-01 18:58 UTC (permalink / raw)
To: The Git Mailing List
In-Reply-To: <20091201185114.GC11235@dpotapov.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1701 bytes --]
At Tue, 1 Dec 2009 21:51:14 +0300, Dmitry Potapov <dpotapov@gmail.com> wrote:
Subject: Re: multiple working directories for long-running builds (was: "git merge" merges too much!)
>
> Obviously, switching branches while running build may produce very
> confusing results, but it is not any different than editing files by
> hands during built -- any concurrent modification may confuse the build
> system.
That's what I said. This is why multiple working directories is an
essential feature for any significantly large project.
> > I just disagreed that "git archive" was a reasonable alternative to
> > leaving the working directory alone during the entire time of the build.
>
> Using "git archive" allows you avoid running long time procedure such as
> full clean build and testing in the working tree. Also, it is guaranteed
> that you test exactly what you put in Git and some other garbage in your
> working tree does not affect the result.
Sure, but let's be very clear here: "git archive" is likely even more
impossible for some large projects to use than "git clone" would be to
use to create build directories.
Disk bandwidth is almost always more expensive than disk space.
> But my point was that switching
> between branches and recompile a few changed files may be faster than
> going to another working tree.
That's possibly going to generate even more unnecessary churn in the
working directory, and thus even more unnecessary re-compiles.
Multiple working directories are really the only sane solution
sometimes.
--
Greg A. Woods
Planix, Inc.
<woods@planix.com> +1 416 218 0099 http://www.planix.com/
[-- Attachment #2: Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* Re: non-US-ASCII file names (e.g. Hiragana) on Windows
From: Thomas Singer @ 2009-12-01 18:55 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Johannes Sixt, git
In-Reply-To: <m3k4x6na81.fsf@localhost.localdomain>
Jakub Narebski wrote:
> If you use Git from Java, why don't you just use JGit (www.jgit.org),
> which is Git implementation in Java?
We are using JGit for the read-only stuff and the Git command line
executable for all writing commands. We very much appreciate Shawn O.
Pearce' (and the other JGit developers') effort, but Git is a fast moving
target and (much) more complex than CVS or SVN, for which we use Java
libraries communicating with the corresponding server which adds another
sanity layer to the repository making repository corruption less likely than
direct access.
--
Best regards,
Thomas Singer
=============
syntevo GmbH
http://www.syntevo.com
http://blog.syntevo.com
^ permalink raw reply
* Re: "git merge" merges too much!
From: Greg A. Woods @ 2009-12-01 18:52 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: The Git Mailing List
In-Reply-To: <20091130192212.GA23181@dpotapov.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 4904 bytes --]
At Mon, 30 Nov 2009 22:22:12 +0300, Dmitry Potapov <dpotapov@gmail.com> wrote:
Subject: Re: "git merge" merges too much!
>
> The key difference comparing to what you may got used is that branches
> are normally based on the oldest branch in what this feature may be
> included. Thus normally changes are not backported to old branches,
> because you can merge them directly.
Hmmm... the idea of creating topic branches based on the oldest branch
where the feature might be used is indeed neither intuitive, nor is it
mentioned anywhere I've so far read about using topic branches in Git.
To use topic branches effectively this way, especially in managing local
and custom changes to a large remote project where separate working
directories are needed for long-running builds, I think some additional
software configuration management tool must be used to create
"configuration" branches where all the desired change sets (topic
branches) are merged.
I spent half my dreaming time early this morning running through
scenarios of how to use topic branches, with true merging (not
re-basing), in a usable work-flow.
At the moment I'm leaning towards a process where the configuration
branch is re-created for every build -- i.e. the merges are redone from
every topic branch to a freshly configured branch forked from the
locally supported release branch, hopefully making use of git-rerere to
solve most conflicts in as automated a fashion as is possible.
This may not be a sane thing to do though -- it may be too much work to
do for every fix. It somewhat goes against the current natural trend in
many of the projects I work on to develop changes on the trunk and then
back-port (some of) them to release branches.
Perhaps Stacked-Git really is the best answer. I will have to
investigate more.
> > > Yes, you must cherry-pick or use rebase (which is a more featureful
> > > version of the pipeline you mentioned).
> >
> > "git rebase" will not work for me unless it grows a "copy" option ,
> > i.e. one which does not delete the original branch (i.e. avoids the
> > "reset" phase of its operation).
>
> There is no reset phase...
By "reset phase" I meant this part, from git-rebase(1):
The current branch is reset to <upstream>, or <newbase> if the --onto
option was supplied. This has the exact same effect as git reset --hard
<upstream> (or <newbase>).
> It is just reassigning the head of branch to
> point to a different commit-id. If you want to copy a branch instead of
> rebasing the old one, you create a new branch (a new name) that points
> to the same commit as the branch that you want to copy, after that you
> rebase this new branch. You can do that like this:
>
> $ git branch new-foo foo
>
> $ git rebase --onto newbase oldbase new-foo
Hmmm.... I'll have to think about that. It makes some sense, but I
don't intuitively read the command-line parameters well enough to
predict the outcome in all of the scenarios I'm interested in.
what is "oldbase" there? I'm guessing it means "base of foo" (and for
the moment, "new-foo" too)?
It's confusing because the manual page uses the word "upstream" to
describe this parameter.
From my experiments it looks like what I might want to do to copy a
local branch to port its changes from one release branch to another is
something like this (where local-v2.0 is a branch with local changes
forked from release branch REL-v2.0, and I want to back-port these
changes to a new local branch forked from the release branch REL-v1.0):
$ git branch local-base-v1.0 REL-v1.0 # mark base of new branch
$ git branch local-v1.0 local-v2.0 # dup head of src branch
$ git rebase --onto local-base-v1.0 REL-v2.0 local-v1.0
$ git branch -d local-base-v1.0
The first and last steps may not be necessary if REL-v1.0 really is a
branch, but in my play project it is just a tag on the trunk. In the
case that it were really already a branch then hopefully this would do:
$ git branch local-v1.0 local-v2.0 # dup head of src branch
$ git rebase --onto REL-v1.0 REL-v2.0 local-v1.0
The trick here seems to be to invent the name of the new branch based on
where it's going to be rebased to.
I think this does suffice very nicely as a "git copy" operation!
> The "copy" does not have the problem of rebase, but it has a different
> problem: You have two series of commits instead of one. If you found
> a bug in one of those commits, you will have to patch each series
> separately. Also, git merge may produce additional conflicts... So,
> copying commits is not something that I would recommend to do often.
Indeed.
--
Greg A. Woods
+1 416 218-0098 VE3TCP RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com> Secrets of the Weird <woods@weird.com>
[-- Attachment #2: Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* Re: multiple working directories for long-running builds (was: "git merge" merges too much!)
From: Dmitry Potapov @ 2009-12-01 18:51 UTC (permalink / raw)
To: The Git Mailing List
In-Reply-To: <m1NFX19-000kn4C@most.weird.com>
On Tue, Dec 01, 2009 at 12:59:58PM -0500, Greg A. Woods wrote:
> At Tue, 1 Dec 2009 08:47:34 +0300, Dmitry Potapov <dpotapov@gmail.com> wrote:
> Subject: Re: "git merge" merges too much!
> >
> > On Mon, Nov 30, 2009 at 07:24:14PM -0500, Greg A. Woods wrote:
> > >
> > > Things get even weirder if you happen to be playing with older branches
> > > too -- most build tools don't have ability to follow files that go back
> > > in time as they assume any product files newer than the sources are
> > > already up-to-date, no matter how much older the sources might become on
> > > a second build.
> >
> > No, files do not go back in time when you switch between branches. The
> > timestamp on files is the time when they are written to your working
> > tree
>
> Hmmm, I didn't really say anything in particular about file timestamps
> -- I meant the file content may go back in time. More correctly I
> should have said that the file content may become inconsistent with the
> state of other files that have just been compiled.
There is no difference of content going back in time or forth. If a file
is changed, any decent build system should recompile the corresponding
files. If the build does not handle dependencies properly, you can end
up with inconsistent state just by editing some files.
> If the timestamps do not get set back to commit time, but rather are
> simply updated to move the last modify time to the time each change is
> made to a working file (which is as you said, to be expected),
More precisely, Git does not anything about modification time during
checkout. The system automatically updates the modification time when
a file is written, and Git does not mess with it.
> regardless of whether its content goes back in time or not, then this
> may or may not help a currently running build to figure out what really
> needs to be re-compiled.
Obviously, switching branches while running build may produce very
confusing results, but it is not any different than editing files by
hands during built -- any concurrent modification may confuse the build
system.
> I just disagreed that "git archive" was a reasonable alternative to
> leaving the working directory alone during the entire time of the build.
Using "git archive" allows you avoid running long time procedure such as
full clean build and testing in the working tree. Also, it is guaranteed
that you test exactly what you put in Git and some other garbage in your
working tree does not affect the result. But my point was that switching
between branches and recompile a few changed files may be faster than
going to another working tree.
Dmitry
^ permalink raw reply
* Re: Umlaut in filename makes troubles
From: Daniel Barkalow @ 2009-12-01 18:48 UTC (permalink / raw)
To: rick23; +Cc: git
In-Reply-To: <200912010815.14515.rick23@gmx.net>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2066 bytes --]
On Tue, 1 Dec 2009, rick23@gmx.net wrote:
> I have problems with my repository under slackware vs. windows. I
> created a repo in linux and every time I use it under msysgit, the
> files containing umlauts in the filename are marked as deleted (and
> vice versa).
>
> For instance: the repo perfectly synced under msysgit leads to:
>
> user@sauron:/media/disk-2$ git status |grep Auszug
> # deleted: "trunk/007_Literatur/Auszug aus Ergonomische
> Untersuchung des Lenkgef\374hles.docx"
> # "trunk/007_Literatur/Auszug aus Ergonomische Untersuchung des
> Lenkgef\303\274hles.docx"
So the directory contains the utf-8 name, but the index contains a latin-1
name, when you wrote it under Windows and are looking at it under Linux.
You probably want to use utf-8 for your repository, so that it's not
specific to your locale.
> in linux. But the file exists and is displayed correctly in the shell
> or in dolphin (my filemanager under X):
>
> user@sauron:/media/disk-2$ ls trunk/007_Literatur/Auszug*
> trunk/007_Literatur/Auszug aus Ergonomische Untersuchung des
> Lenkgefühles.docx
You've got a utf-8 filesystem, so the u-with-umlaut is the two-byte
sequence git is showing in the message as being present, not the single
byte that it's showing as deleted. It looks like you're actually using
utf-8 for what's on the usb stick, so you probably want the names listed
in the repository to match that, which means that the correct one here is
Linux.
> Can you please give me a hint what to do?
Convince Windows (or msysgit) to report filenames to git in utf-8. (I
don't know *how*, but that's *what* you probably want to do.)
Once you've got everything agreeing on the character set used for
filenames, you can disable "core.quotepath" to make the messages appear
with umlauts; if you turned that off before fixing the inconsistancy, it
would be much trickier to debug, because the "deleted" line would contain
something that your Linux display won't consider a valid character.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH/RFC] Allow curl to rewind the RPC read buffer at any time
From: Daniel Stenberg @ 2009-12-01 18:18 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Martin Storsj?, Tay Ray Chuan, git, Nicholas Miell, gsky51,
Clemens Buchacher, Mark Lodato, Johannes Schindelin
In-Reply-To: <20091201161428.GC21299@spearce.org>
On Tue, 1 Dec 2009, Shawn O. Pearce wrote:
> The #@!*@!* library should be able to generate two requests back-to-back to
> the same URL without needing to rewind the 2nd request.
If '#@!*@!*' is your pattern for matching libcurl or curl, then sure libcurl
certainly has no problem at all to send as many requests you like
back-to-back.
The rewinding business is only really necessary for multipass authentication
when Expect: 100-continue doesn't work (and thus libcurl has started to send
data that the server will discard and thus is needed to get sent again). And
that's not something you can blame "the #@!*@!* library" for, but rather your
server end and/or how HTTP is defined to work.
--
/ daniel.haxx.se
^ permalink raw reply
* Re: [RFC PATCH 6/8] Remove special casing of http, https and ftp
From: Shawn O. Pearce @ 2009-12-01 18:24 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: git
In-Reply-To: <1259675838-14692-7-git-send-email-ilari.liusvaara@elisanet.fi>
Ilari Liusvaara <ilari.liusvaara@elisanet.fi> wrote:
> HTTP, HTTPS and FTP are no longer special to transport code. Also
> add support for FTPS (curl supports it so it is easy).
...
> diff --git a/Makefile b/Makefile
> index 42744a4..be0be87 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1676,7 +1676,19 @@ git-http-push$X: revision.o http.o http-push.o $(GITLIBS)
> $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
> $(LIBS) $(CURL_LIBCURL) $(EXPAT_LIBEXPAT)
>
> -git-remote-curl$X: remote-curl.o http.o http-walker.o $(GITLIBS)
> +git-remote-http$X: remote-curl.o http.o http-walker.o $(GITLIBS)
> + $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
> + $(LIBS) $(CURL_LIBCURL) $(EXPAT_LIBEXPAT)
> +
> +git-remote-https$X: remote-curl.o http.o http-walker.o $(GITLIBS)
> + $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
> + $(LIBS) $(CURL_LIBCURL) $(EXPAT_LIBEXPAT)
> +
> +git-remote-ftp$X: remote-curl.o http.o http-walker.o $(GITLIBS)
> + $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
> + $(LIBS) $(CURL_LIBCURL) $(EXPAT_LIBEXPAT)
> +
> +git-remote-ftps$X: remote-curl.o http.o http-walker.o $(GITLIBS)
> $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
> $(LIBS) $(CURL_LIBCURL) $(EXPAT_LIBEXPAT)
These should all be hardlinks to a single executable, not duplicate
relinks of the same object files.
--
Shawn.
^ permalink raw reply
* Re: [PATCH/RFC] Add a --bouquet option to git rev-list
From: Junio C Hamano @ 2009-12-01 18:21 UTC (permalink / raw)
To: Nathan W. Panike; +Cc: Michael J Gruber, git
In-Reply-To: <d77df1110912010931l40472723v80ad675a92d23fa3@mail.gmail.com>
"Nathan W. Panike" <nathan.panike@gmail.com> writes:
>>> include_forks ()
>>> {
>>> local head="$(git show -s --pretty=format:'%H' HEAD)";
>>> echo "HEAD $(git for-each-ref --format='%(refname)' \
>>> refs/heads refs/remotes | while read ref; do \
>>> if test "$(git merge-base HEAD ${ref}^{commit})" != ""; \
>>> then echo ${ref}; fi; done)"
>>> }
Because you have to traverse the entire history from tips of refs to know
if the histories to reach them are disjoint, this is fundamentally a very
expensive operation and will not scale to projects with deep histories.
If a low-level support for this kind of thing is necessary, then I do not
think it should just be "give me set of refs that is related to HEAD". I
suspect that is too inflexible to be useful in other situations.
A command to list refs (i.e. not as rev-list argument that shows list of
commits, but as a new feature of for-each-ref) with new criteria might
have wider use (I am just thinking aloud). Something like
- among these refs (you would specify this with --all, --heads, or prefix
'refs/heads refs/remotes'), list only the ones related to this and that
ref (here you would give HEAD or whatever you want to check with as
argument)"; and
- its counterpart "list the ones that are _not_ related" with the same
input.
As to the implementation, instead of running get_merge_bases() number of
times (a naive implementation would be O(n*m), I guess), I think it may
make sense to run the traversal in parallel, similar to the way done in
show-branches (but the termination condition would be different).
^ permalink raw reply
* Re: [PATCH] get_ref_states: strdup entries and free util in stale list
From: Bert Wesarg @ 2009-12-01 18:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Jay Soffian, git
In-Reply-To: <36ca99e90912010105r428a7bfdw63928e8a5515bd1d@mail.gmail.com>
On Tue, Dec 1, 2009 at 10:05, Bert Wesarg <bert.wesarg@googlemail.com> wrote:
> There are still invalid reads of size 4. I think the problem is the
> flex array member of 'struct ref' and strlen(). If its worth I can
> look into this.
A short heads-up, here is the valgrind error I get for this invalid read:
==27305== Invalid read of size 4
==27305== at 0x4936AF: copy_ref (remote.c:870)
==27305== by 0x4942E4: get_fetch_map (remote.c:1271)
==27305== by 0x44473E: get_remote_ref_states (builtin-remote.c:271)
==27305== by 0x446DCE: cmd_remote (builtin-remote.c:1022)
==27305== by 0x4045F0: handle_internal_command (git.c:257)
==27305== by 0x404B8F: main (git.c:482)
==27305== Address 0x5b5ba38 is 104 bytes inside a block of size 107 alloc'd
==27305== at 0x4C24477: calloc (vg_replace_malloc.c:418)
==27305== by 0x4B09AD: xcalloc (wrapper.c:75)
==27305== by 0x493924: alloc_ref_with_prefix (remote.c:853)
==27305== by 0x46653B: get_remote_heads (connect.c:96)
==27305== by 0x4A9347: get_refs_via_connect (transport.c:453)
==27305== by 0x4A7F14: transport_get_remote_refs (transport.c:895)
==27305== by 0x4445B6: get_remote_ref_states (builtin-remote.c:810)
==27305== by 0x446DCE: cmd_remote (builtin-remote.c:1022)
==27305== by 0x4045F0: handle_internal_command (git.c:257)
==27305== by 0x404B8F: main (git.c:482)
^ permalink raw reply
* Re: [PATCH] get_ref_states: strdup entries and free util in stale list
From: Bert Wesarg @ 2009-12-01 18:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Jay Soffian, git
In-Reply-To: <7v8wdm1ui1.fsf@alter.siamese.dyndns.org>
On Tue, Dec 1, 2009 at 18:20, Junio C Hamano <gitster@pobox.com> wrote:
> Bert Wesarg <bert.wesarg@googlemail.com> writes:
>
>>> - The ref abbrev_branch() is called and the address of whose substring is
>>> taken to be used as "name" in handle_one_branch() is refspec.src, but
>>> what goes to .util is refname that is refspec.dst---they are different
>>> strings and one is not a substring of the other.
>> I don't see you point here.
>
> Of course you don't ;-) because we were looking at different versions.
>
> I wanted to apply the same fix to both maint and master. For the code in
> 'master' your observation is 100% correct.
A quick test with my use case does not show errors in the maint
branch. So it should not be needed (except the memory leak fix of the
.util member). And valgrind confirms this.
Bert
>
^ permalink raw reply
* Re: multiple working directories for long-running builds (was: "git merge" merges too much!)
From: Greg A. Woods @ 2009-12-01 17:59 UTC (permalink / raw)
To: The Git Mailing List; +Cc: Dmitry Potapov
In-Reply-To: <20091201054734.GB11235@dpotapov.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 2257 bytes --]
At Tue, 1 Dec 2009 08:47:34 +0300, Dmitry Potapov <dpotapov@gmail.com> wrote:
Subject: Re: "git merge" merges too much!
>
> On Mon, Nov 30, 2009 at 07:24:14PM -0500, Greg A. Woods wrote:
> >
> > Things get even weirder if you happen to be playing with older branches
> > too -- most build tools don't have ability to follow files that go back
> > in time as they assume any product files newer than the sources are
> > already up-to-date, no matter how much older the sources might become on
> > a second build.
>
> No, files do not go back in time when you switch between branches. The
> timestamp on files is the time when they are written to your working
> tree
Hmmm, I didn't really say anything in particular about file timestamps
-- I meant the file content may go back in time. More correctly I
should have said that the file content may become inconsistent with the
state of other files that have just been compiled.
If the timestamps do not get set back to commit time, but rather are
simply updated to move the last modify time to the time each change is
made to a working file (which is as you said, to be expected),
regardless of whether its content goes back in time or not, then this
may or may not help a currently running build to figure out what really
needs to be re-compiled. Likely it won't even for a recursive-make
style update build, but certainly not for one where all build actions
are pre-determined before any of them are started.
If the content of one or more files goes back in time to an earlier
state while the compile is happening then ultimately the result must be
considered to be undefined. The best you can hope for is a break in the
compile.
This is why I agreed with you that a build should never be done in a
working directory where any file editing or VCS action is occurring
simultaneously.
I just disagreed that "git archive" was a reasonable alternative to
leaving the working directory alone during the entire time of the build.
It is not really reasonable for large projects any more than stopping
all work on the sources is reasonable.
--
Greg A. Woods
Planix, Inc.
<woods@planix.com> +1 416 218 0099 http://www.planix.com/
[-- Attachment #2: Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* Re: [PATCH/RFC] Allow curl to rewind the RPC read buffer
From: Junio C Hamano @ 2009-12-01 17:49 UTC (permalink / raw)
To: Martin Storsjö
Cc: Tay Ray Chuan, git, Nicholas Miell, gsky51, Clemens Buchacher,
Mark Lodato, Johannes Schindelin
In-Reply-To: <alpine.DEB.2.00.0912011232450.5582@cone.home.martin.st>
Martin Storsjö <martin@martin.st> writes:
> As long as the current rpc read buffer is the first one, we're able to
> rewind without need for additional buffering.
... and if the current buffer isn't the first one, what do we do?
> +#ifndef NO_CURL_IOCTL
> +curlioerr rpc_ioctl(CURL *handle, int cmd, void *clientp)
> +{
> + struct rpc_state *rpc = clientp;
> +
> + switch (cmd) {
> + case CURLIOCMD_NOP:
> + return CURLIOE_OK;
> +
> + case CURLIOCMD_RESTARTREAD:
> + if (rpc->initial_buffer) {
> + rpc->pos = 0;
> + return CURLIOE_OK;
> + }
> + fprintf(stderr, "Unable to rewind rpc post data - try increasing http.postBuffer\n");
> + return CURLIOE_FAILRESTART;
> +
> + default:
> + return CURLIOE_UNKNOWNCMD;
> + }
> +}
> +#endif
What will this result in? A failed request, then the user increases
http.postBuffer, and re-runs the entire command? I am not suggesting the
code should do it differently (e.g. retry with a larger buffer without
having the user to help it). At least not yet. That is why my first
question above was "what do we do?" and not "what should we do?".
I am primarily interested in _documenting_ the expected user experience in
the failure case, so that people can notice the message, run "git grep" to
find the above line and then run "git blame" to find the commit to read
its log message to understand what is going on.
^ permalink raw reply
* Re: [PATCH/RFC] Add a --bouquet option to git rev-list
From: Nathan W. Panike @ 2009-12-01 17:31 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <4B14CF47.5020808@drmicha.warpmail.net>
Hello,
On Tue, Dec 1, 2009 at 2:09 AM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> Nathan W. Panike venit, vidit, dixit 30.11.2009 21:55:
>> Add a command line option to rev-list so the command 'git rev-list --bouquet'
>> shows all revisions that are ancestors of refs which share history with HEAD.
>>
>> Signed-off-by: Nathan W. Panike <nathan.panike@gmail.com>
>> ---
>> I have a repository with the following structure:
>>
>> B
>> /
>> A'--A--C
>> \
>> D
>>
>> E'--E
>>
>> Thus the command 'git merge base E A' returns nothing, as there is no common
>> history. The E history contains stuff that is derived from the other history
>> (A, B, C, or D). Often I find myself doing the following:
>
> Either I don't understand the diagram or your term "derived". If
> "derived" means "on some branch of a merge" and E is derived from A, B,
> C, or D, then (since B, C, D is derived from A, and from A') E is
> derived from A', and they will have a merge base.
>
"Derived" in my case means that E is processed from a snapshot of the
tree at, say, A.
> Are these diagrams really disconnected from each other?
Yes. I started the history of E with plumbing using git commit-tree,
without a -p flag specifying a parent
>
>> git checkout C
>> gitk $(include_forks) &
>> <View history, make changes, merges, et cetera>
>> git checkout E
>> <go back to gitk, only see history for B, C, etc>
>>
>> Now the 'include_forks' command is a bash function in my .bashrc:
>>
>> include_forks ()
>> {
>> local head="$(git show -s --pretty=format:'%H' HEAD)";
>> echo "HEAD $(git for-each-ref --format='%(refname)' \
>> refs/heads refs/remotes | while read ref; do \
>> if test "$(git merge-base HEAD ${ref}^{commit})" != ""; \
>> then echo ${ref}; fi; done)"
>> }
>>
>> The shell thus intercepts my command and I must restart gitk to see the history
>> of E.
>>
>> With this patch, I can issue the command 'gitk --bouquet' and when I checkout
>> E, I can 'reload' in gitk and see the history of E automatically.
>
> What would your patch do in the example you gave above? Which refs would
> it cause gitk (rev-list) to show?
>
I wish to be concrete, so let us suppose you use a default clone of
git.git. Further, suppose you are on origin/master.
Then, with my patch,
git rev-list --bouquet
should be an---admittedly less efficient---equivalent to
git rev-list --all --not refs/remotes/origin/html
refs/remotes/origin/man refs/remotes/origin/todo
> Michael
>
Thanks,
Nathan Panike
^ permalink raw reply
* Re: non-US-ASCII file names (e.g. Hiragana) on Windows
From: Jakub Narebski @ 2009-12-01 17:24 UTC (permalink / raw)
To: Thomas Singer; +Cc: Johannes Sixt, git
In-Reply-To: <4B150747.2030900@syntevo.com>
Thomas Singer <thomas.singer@syntevo.com> writes:
> Johannes Sixt wrote:
>> Thomas Singer schrieb:
>>>
>>> Is it a German Windows limitation, that far-east characters are not
>>> supported on it (but work fine on a Japanese Windows), are there different
>>> (mysys)Git versions available or is this a configuration issue?
>>
>> It is a matter of configuration.
>>
>> Since 8 bits are not sufficient to support Japanese alphabet in addition
>> to the German alphabet, programs that are not Unicode aware -- such as git
>> -- have to make a decision which alphabet they support. The decision is
>> made by picking a "codepage".
>>
>> On German Windows, you are in codepage 850 (in the console). The filenames
>> (that actually are in Unicode) are converted to bytes according to
>> codepage 850 *before* git sees them. If your filenames contain Hiragana,
>> they are substituted by the "unknown character" marker because there is no
>> place for them in codepage 850.
[...]
>> Corollary: Stick to ASCII file names.
>>
>> There have been suggestions to switch the console to codepage 65001
>> (UTF-8), but I have never heard of success reports. I'm not saying it does
>> not work, though.
>
> Thanks for the detailed explanation. I know the differences between bytes
> and characters and the needed *encoding* to convert from one to another, but
> I did not know how Git handles it. I'm quite surprised, that -- as I
> understand you -- msys-Git (or Git at all?) is not able to handle all
> characters (aka unicode) at the same time. I expected it would be better
> than older tools, e.g. SVN.
The problem is not with Git, as Git is (currently) agnostic with
respect to filename encoding; for Git filenames are opaque NUL ('\0)
terminated binary data. There is some infrastructure to convert
between filename encodings and other filename quirks (like
case-insensivity), though...
The problem is with MS Windows *console*, from which you invoke git
commands, and which does translation from filename encoding used by
the filesystem to encoding / codepage used by console.
> BTW, we are invoking the Git executable from Java. Is there automatically a
> console "around" Git? Should we invoke a shell-script (which sets the
> console's code page) instead of the Git executable directly?
If you use Git from Java, why don't you just use JGit (www.jgit.org),
which is Git implementation in Java?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH v2 5/6] run test suite without dashed git-commands in PATH
From: Jakub Narebski @ 2009-12-01 17:24 UTC (permalink / raw)
To: Matthew Ogilvie; +Cc: git, Junio Hamano
In-Reply-To: <1259561971-25730-6-git-send-email-mmogilvi_git@miniinfo.net>
Matthew Ogilvie <mmogilvi_git@miniinfo.net> writes:
> diff --git a/t/README b/t/README
> index 4e1d7dd..8c5d892 100644
> --- a/t/README
> +++ b/t/README
> @@ -75,6 +75,14 @@ appropriately before running "make".
> As the names depend on the tests' file names, it is safe to
> run the tests with this option in parallel.
>
> +--with-dashes::
> + By default tests are run without dashed forms of
> + commands (like git-commit) in the PATH (it only uses
> + wrappers from TOP/git-bin). Use this option to include TOP
> + in the PATH, which conains all the dashed forms of commands.
> + This option is currently implied by other options like --valgrind
> + and GIT_TEST_INSTALLED.
> +
Shouldn't it be 'TOP/bin-wrappers' and not 'TOP/git-bin'?
Shouldn't TOP be explained somewhere, or is it obvious in the context?
s/conains/contains/.
> +else # normal case, use ../bin-wrappers only unless $with_dashes:
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Transplant branch from another repository
From: Dale Farnsworth @ 2009-12-01 16:53 UTC (permalink / raw)
To: jeenuv, git
In-Reply-To: <hf2t2i$l2b$1@xyzzy.farnsworth.org>
> Say, I have two repositories A and B (local, independent, but similar
> - they are for content tracking and not collaboration purposes). A has
> a branch 'a', which I want to have in B. What I mean is that I'd like
> to have the sequence of changes in the branch 'a' to be present in B,
> thus creating an independent branch 'b' in B.
>
> Is there any way to achieve this? One thing that I could think of is
> to use 'format-patch' to generate the list of patch files from A. But
> I don't see how to convert those patches to a sequence of commits in
> repo B. I could do a 'git apply patches/*' but then all patches
> collapse to one single commit. If format-patch is a/the way, could
> somebody tell me how to get this done? Or are there any alternatives?
>
> FWIW: I'm running Git under Cygwin, and sendmail isn't configured.
Try "cd B; git fetch A a:b"
-Dale
Dale Farnsworth
^ permalink raw reply
* Re: [PATCH] get_ref_states: strdup entries and free util in stale list
From: Junio C Hamano @ 2009-12-01 17:20 UTC (permalink / raw)
To: Bert Wesarg; +Cc: Johannes Schindelin, Jay Soffian, git
In-Reply-To: <36ca99e90912010132iee0d42fo933aeb12833ad1ad@mail.gmail.com>
Bert Wesarg <bert.wesarg@googlemail.com> writes:
>> - The ref abbrev_branch() is called and the address of whose substring is
>> taken to be used as "name" in handle_one_branch() is refspec.src, but
>> what goes to .util is refname that is refspec.dst---they are different
>> strings and one is not a substring of the other.
> I don't see you point here.
Of course you don't ;-) because we were looking at different versions.
I wanted to apply the same fix to both maint and master. For the code in
'master' your observation is 100% correct.
^ permalink raw reply
* Re: [RFC PATCH 0/8] Git remote helpers to implement smart transports.
From: Ilari Liusvaara @ 2009-12-01 17:19 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Sverre Rabbelier, git
In-Reply-To: <20091201165245.GF21299@spearce.org>
On Tue, Dec 01, 2009 at 08:52:45AM -0800, Shawn O. Pearce wrote:
> Sverre Rabbelier <srabbelier@gmail.com> wrote:
> > On Tue, Dec 1, 2009 at 14:57, Ilari Liusvaara
> > <ilari.liusvaara@elisanet.fi> wrote:
> > > This series implements extensions to remote helpers for carrying smary
> > > transports. It is against next, because master doesn't contain necressary
> > > patches (the allow specifying remote helper in url one).
> >
> > Could you please explain how this relates to Shawn's smart http series
> > and the sr/vcs-helper series?
Ability to easily implement smart transports with underlying full-duplex
connection. The smart http stuff has loads of code to reimplement smart
transport client side.
> Or better, why this is even necessary?
>
> I thought git:// over TCP is pretty simple and efficient, and fairly
> widely deployed. Smart http(s):// will be in 1.6.6 and available
> soon, and isn't all that ugly.
I consider the authentication parts of smart http pretty ugly. TLS has some
nicer methods, but support for those is nonexistent. Also, I consider piggy-
backing on HTTP when you can have full-duplex connectivity ugly.
> Since the introduction of git:// nobody has asked for another
> protocol... other than wanting to make http:// as efficient as
> git:// is. Which is now done.
Incorrect. I have seen requests for gits:// (and in fact, I have plans to
implement that protocol).
> So why do we need this?
For instance, to support new types of authentication for smart transports
without patching client git binaries (SSH has lots of failure modes that
are quite nasty to debug) or abusing GIT_PROXY (yuck).
If the server can also handle authentication, it has a lot better idea
where things go wrong and can give better errors to logs or to client
(of course, not too much can be leaked to client or it will be too useful
for attack, but that's seperate topic).
> The sr/vcs-helper series makes sense if you want to make SVN, Hg,
> or P4 remotes act transparently like Git remotes. But that's not
> embedding the git:// protocol inside of another protocol, its doing a
> full up conversion from a non-Git set of semantics to Git semantics.
This is not about embedding git:// protol inside another. Its about
carrying the subprotocols. These transports share with git:// as much
as file:// and ssh:// share with git:// (note that service request is
given as command, not inside data pipe).
And IIRC, the only thing this needs from sr/vcs-helper is the patch to
allow selecting helper with URL. The first versions of series did contain
self-standing functionality equivalent to that, but that got dropped as
equivalent functionality appeared in upstream.
-Ilari
^ permalink raw reply
* [PATCH 2/2] gitweb: Add link to other blame implementation in blame views
From: Jakub Narebski @ 2009-12-01 16:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Stephen Boyd, git, Martin Koegler
In-Reply-To: <200912011751.12172.jnareb@gmail.com>
Add link to 'blame_incremental' action (which requires JavaScript) in
'blame' view, and add link to 'blame' action in 'blame_incremental'
view.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index bb2d29c..ca36761 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -5006,6 +5006,17 @@ sub git_blame_common {
my $formats_nav =
$cgi->a({-href => href(action=>"blob", -replay=>1)},
"blob") .
+ " | ";
+ if ($format eq 'incremental') {
+ $formats_nav .=
+ $cgi->a({-href => href(action=>"blame", javascript=>0, -replay=>1)},
+ "blame") . " (non-incremental)";
+ } else {
+ $formats_nav .=
+ $cgi->a({-href => href(action=>"blame_incremental", -replay=>1)},
+ "blame") . " (incremental)";
+ }
+ $formats_nav .=
" | " .
$cgi->a({-href => href(action=>"history", -replay=>1)},
"history") .
--
1.6.5.3
^ permalink raw reply related
* Re: [PATCH/RFC] Allow curl to rewind the RPC read buffer at any time
From: Martin Storsjö @ 2009-12-01 16:59 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Tay Ray Chuan, git, Nicholas Miell, gsky51, Clemens Buchacher,
Mark Lodato, Johannes Schindelin
In-Reply-To: <20091201161428.GC21299@spearce.org>
On Tue, 1 Dec 2009, Shawn O. Pearce wrote:
> In the case of git-receive-pack requests, we might be uploading an
> entire project to an empty repository on the remote side. This could
> be 8 GiB worth of data if the project was something huge like KDE.
> We can't assume that we should malloc 8 GiB of memory to buffer
> the payload.
True, fair enough. This was mostly a proof of concept of how this could be
implemented, but with these comments for you, it's clear that this isn't a
feasible solution at all. There's no acute need for it either.
> The *correct* way to support an arbitrary rewind is to modify the
> outgoing channel from remote-curl to its protocol engine (client.in
> within the rpc_service method) to somehow request the protocol engine
> (aka git-send-pack or git-fetch-pack) to stop and regenerate the
> current request.
That's a good idea!
> Another approach would be to modify http-backend (and the protocol)
> to support an "auth ping" request prior to spooling out the entire
> payload if its more than an http.postBuffer size. Basically we
> do what the "Expect: 100-continue" protocol is supposed to do,
> but in the application layer rather than the HTTP/1.1 layer, so
> our CGI actually gets invoked.
That's also quite a good idea, especially if it would be done in a way so
that it's certain that the same curl session will be reused, instead of
getting a potentially new curl session when using get_active_slot().
> This unfortunately still relies on the underlying libcurl to not
> discard the authentication data after that initial "auth ping".
> But to be honest, I think that is a reasonable expectation. The
> #@!*@!* library should be able to generate two requests back-to-back
> to the same URL without needing to rewind the 2nd request.
Yeah, as long as the same curl session is preserved, this should be no
problem.
// Martin
^ permalink raw reply
* [PATCH 1/2] gitweb: Make linking to actions requiring JavaScript a feature
From: Jakub Narebski @ 2009-12-01 16:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Stephen Boyd, git, Martin Koegler
In-Reply-To: <200912011751.12172.jnareb@gmail.com>
Let gitweb turn some links (like 'blame' links) into linking to
actions which require JavaScript (like 'blame_incremental' action)
only if 'javascript-actions' feature is enabled.
This means that links to such actions would be present only if both
JavaScript is enabled, and 'javascript-actions' feature is enabled.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index a80cbd3..bb2d29c 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -432,6 +432,13 @@ our %feature = (
'timed' => {
'override' => 0,
'default' => [0]},
+
+ # Enable turning some links into links to actions which require
+ # JavaScript to run (like 'blame_incremental'). Disabled by default.
+ # Project specific override is currently not supported.
+ 'javascript-actions' => {
+ 'override' => 0,
+ 'default' => [0]},
);
sub gitweb_get_feature {
@@ -3326,7 +3333,7 @@ sub git_footer_html {
qq!startBlame("!. href(action=>"blame_data", -replay=>1) .qq!",\n!.
qq! "!. href() .qq!");\n!.
qq!</script>\n!;
- } else {
+ } elsif (gitweb_check_feature('javascript-actions')) {
print qq!<script type="text/javascript">\n!.
qq!window.onload = fixLinks;\n!.
qq!</script>\n!;
--
1.6.5.3
^ permalink raw reply related
* Re: [RFC/PATCH] gitweb: Make linking to actions requiring JavaScript a feature
From: Jakub Narebski @ 2009-12-01 16:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Stephen Boyd, git, Martin Koegler
In-Reply-To: <7v4oob8pap.fsf@alter.siamese.dyndns.org>
On Tue, 1 Dec 2009, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > I had to step back a bit and ask myself what we are trying to achieve
> > here. When the current blame and incremental one are both working
> > perfectly and well, will there be a reason for the end users to choose
> > between them when they click?
> >
> > My answer is no. If the incremental one gives nicer user experience in
> > all cases, it will be shown without the non-incremental one; if the
> > incremental one makes the server or network load too heavy, a site owner
> > may decide to show only the non-incremental one.
> >
> > That makes my addLinks suggestion a change that would help _only_ while we
> > are working kinks out of the incremental one.
> >
> > Let's not waste too much effort doing that. Sorry for suggesting.
> >
> > Letting the site owner choose if the site wants to set the "incremental if
> > possible" boolean would be more than adequate, I think.
>
> Sorry, but I guess I dropped the ball after this message. If I understand
> correctly, the conclusion is that I can apply the patch in this one
>
> From: Jakub Narebski <jnareb@gmail.com>
> Subject: [RFC/PATCH] gitweb: Make linking to actions requiring JavaScript a feature
> Date: Thu, 26 Nov 2009 21:12:15 +0100
> Message-ID: <200911262112.16280.jnareb@gmail.com>
>
> and shipping 1.6.6 with it (perhaps setting 'default' to '[0]' instead)
> would be both reasonably safe and allows easy experimentation by willing
> site owners (or individual gitweb deployment), right?
Yes, I think it is right.
As a followup to this mail I have sent modified version of patch mentioned
above, only with default setting for 'javascript-actions' changed to '[0]'
(disabled), and new patch adding link to 'blame_incremental' action in an
ordinary 'blame' view and vice versa, so even if 'javascript-actions' is
turned off one can experiment with AJAX-y blame.
gitweb/gitweb.perl | 21 +++++++++++++++++++--
1 files changed, 19 insertions(+), 2 deletions(-)
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [RFC PATCH 0/8] Git remote helpers to implement smart transports.
From: Shawn O. Pearce @ 2009-12-01 16:52 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: Sverre Rabbelier, git
In-Reply-To: <fabb9a1e0912010812t4de8027dj1faf828051d1adc2@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> wrote:
> On Tue, Dec 1, 2009 at 14:57, Ilari Liusvaara
> <ilari.liusvaara@elisanet.fi> wrote:
> > This series implements extensions to remote helpers for carrying smary
> > transports. It is against next, because master doesn't contain necressary
> > patches (the allow specifying remote helper in url one).
>
> Could you please explain how this relates to Shawn's smart http series
> and the sr/vcs-helper series?
Or better, why this is even necessary?
I thought git:// over TCP is pretty simple and efficient, and fairly
widely deployed. Smart http(s):// will be in 1.6.6 and available
soon, and isn't all that ugly.
Since the introduction of git:// nobody has asked for another
protocol... other than wanting to make http:// as efficient as
git:// is. Which is now done.
So why do we need this?
The sr/vcs-helper series makes sense if you want to make SVN, Hg,
or P4 remotes act transparently like Git remotes. But that's not
embedding the git:// protocol inside of another protocol, its doing a
full up conversion from a non-Git set of semantics to Git semantics.
--
Shawn.
^ permalink raw reply
* Re: [PATCH/RFC] Allow curl to rewind the RPC read buffer
From: Martin Storsjö @ 2009-12-01 16:51 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Tay Ray Chuan, git, Nicholas Miell, gsky51, Clemens Buchacher,
Mark Lodato, Johannes Schindelin
In-Reply-To: <20091201160150.GB21299@spearce.org>
On Tue, 1 Dec 2009, Shawn O. Pearce wrote:
> Martin Storsj? <martin@martin.st> wrote:
> > When using multi-pass authentication methods, the curl library may need
> > to rewind the read buffers used for providing data to HTTP POST, if data
> > has been output before a 401 error is received.
>
> In theory, since the cURL session stays active, we would have
> received the 401 authentication error during the initial
> "GET $GIT_DIR/info/refs?service=git-$service" request, and the subsequent
> "POST $GIT_DIR/git-$service" requests would automatically include the
> authentication data.
>
> That's theory. Reality doesn't always agree with my theories. :-)
As Tay said - his "maintain curl sessions" patch should make this
redundant in most cases. But in case request pattern gets changed or if
the curl session for some other reason isn't able to authenticate on the
first try, this is a quite non-intrusive way of ensuring that these
requests can be restarted.
// Martin
^ 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