* Re: [PATCH] Allow curl to rewind the read buffers
From: Martin Storsjö @ 2009-04-01 16:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbprg1h3m.fsf@gitster.siamese.dyndns.org>
On Wed, 1 Apr 2009, Junio C Hamano wrote:
> It may be obvious to people proficient in cURL, but I had to guess that
> you perhaps meant to say "when using multi-pass authentication methods,
> cURL library may need to rewind the read buffers (depending on what is fed
> by the server), and in order to allow the library to do so, we need to
> tell it how by providing the way to manipulate the buffers we supply with
> these IOCTL callbacks."
>
> Do I understand you correctly?
Yeah, that's exactly correct.
> My point is that the your two-line statement of fact (with a bit more
> explanation of the fact that follows) was clear but it was unclear to me
> how that fact translates to the need of what the patch does. We would
> want the commit log message to be helpful to people who look at the code 6
> months down the line and wonder why these lines were added.
The original commit comment was a bit vague in retrospect, yes. I'll reply
with an updated version soon.
Thanks!
// Martin
^ permalink raw reply
* [PATCH] Allow curl to rewind the read buffers
From: Martin Storsjö @ 2009-04-01 16:48 UTC (permalink / raw)
To: git
In-Reply-To: <7vbprg1h3m.fsf@gitster.siamese.dyndns.org>
When using multi-pass authentication methods, the curl library may
need to rewind the read buffers (depending on how much already has
been fed to the server) used for providing data to HTTP PUT, POST or
PROPFIND, and in order to allow the library to do so, we need to tell
it how by providing either an ioctl callback or a seek callback.
This patch adds an ioctl callback, which should be usable on older
curl versions (since 7.12.3) than the seek callback (introduced in
curl 7.18.0).
Some HTTP servers (such as Apache) give an 401 error reply immediately
after receiving the headers (so no data has been read from the read
buffers, and thus no rewinding is needed), but other servers (such
as Lighttpd) only replies after the whole request has been sent and
all data has been read from the read buffers, making rewinding necessary.
Signed-off-by: Martin Storsjo <martin@martin.st>
---
Updated comment to better describe the potential need for this.
http-push.c | 24 ++++++++++++++++++++++++
http.c | 19 +++++++++++++++++++
http.h | 7 +++++++
3 files changed, 50 insertions(+), 0 deletions(-)
diff --git a/http-push.c b/http-push.c
index 6ce5a1d..7dc0dd4 100644
--- a/http-push.c
+++ b/http-push.c
@@ -567,6 +567,10 @@ static void start_put(struct transfer_request *request)
curl_easy_setopt(slot->curl, CURLOPT_INFILE, &request->buffer);
curl_easy_setopt(slot->curl, CURLOPT_INFILESIZE, request->buffer.buf.len);
curl_easy_setopt(slot->curl, CURLOPT_READFUNCTION, fread_buffer);
+#ifndef NO_CURL_IOCTL
+ curl_easy_setopt(slot->curl, CURLOPT_IOCTLFUNCTION, ioctl_buffer);
+ curl_easy_setopt(slot->curl, CURLOPT_IOCTLDATA, &request->buffer);
+#endif
curl_easy_setopt(slot->curl, CURLOPT_WRITEFUNCTION, fwrite_null);
curl_easy_setopt(slot->curl, CURLOPT_CUSTOMREQUEST, DAV_PUT);
curl_easy_setopt(slot->curl, CURLOPT_UPLOAD, 1);
@@ -1267,6 +1271,10 @@ static struct remote_lock *lock_remote(const char *path, long timeout)
curl_easy_setopt(slot->curl, CURLOPT_INFILE, &out_buffer);
curl_easy_setopt(slot->curl, CURLOPT_INFILESIZE, out_buffer.buf.len);
curl_easy_setopt(slot->curl, CURLOPT_READFUNCTION, fread_buffer);
+#ifndef NO_CURL_IOCTL
+ curl_easy_setopt(slot->curl, CURLOPT_IOCTLFUNCTION, ioctl_buffer);
+ curl_easy_setopt(slot->curl, CURLOPT_IOCTLDATA, &out_buffer);
+#endif
curl_easy_setopt(slot->curl, CURLOPT_FILE, &in_buffer);
curl_easy_setopt(slot->curl, CURLOPT_WRITEFUNCTION, fwrite_buffer);
curl_easy_setopt(slot->curl, CURLOPT_URL, url);
@@ -1508,6 +1516,10 @@ static void remote_ls(const char *path, int flags,
curl_easy_setopt(slot->curl, CURLOPT_INFILE, &out_buffer);
curl_easy_setopt(slot->curl, CURLOPT_INFILESIZE, out_buffer.buf.len);
curl_easy_setopt(slot->curl, CURLOPT_READFUNCTION, fread_buffer);
+#ifndef NO_CURL_IOCTL
+ curl_easy_setopt(slot->curl, CURLOPT_IOCTLFUNCTION, ioctl_buffer);
+ curl_easy_setopt(slot->curl, CURLOPT_IOCTLDATA, &out_buffer);
+#endif
curl_easy_setopt(slot->curl, CURLOPT_FILE, &in_buffer);
curl_easy_setopt(slot->curl, CURLOPT_WRITEFUNCTION, fwrite_buffer);
curl_easy_setopt(slot->curl, CURLOPT_URL, url);
@@ -1584,6 +1596,10 @@ static int locking_available(void)
curl_easy_setopt(slot->curl, CURLOPT_INFILE, &out_buffer);
curl_easy_setopt(slot->curl, CURLOPT_INFILESIZE, out_buffer.buf.len);
curl_easy_setopt(slot->curl, CURLOPT_READFUNCTION, fread_buffer);
+#ifndef NO_CURL_IOCTL
+ curl_easy_setopt(slot->curl, CURLOPT_IOCTLFUNCTION, ioctl_buffer);
+ curl_easy_setopt(slot->curl, CURLOPT_IOCTLDATA, &out_buffer);
+#endif
curl_easy_setopt(slot->curl, CURLOPT_FILE, &in_buffer);
curl_easy_setopt(slot->curl, CURLOPT_WRITEFUNCTION, fwrite_buffer);
curl_easy_setopt(slot->curl, CURLOPT_URL, repo->url);
@@ -1766,6 +1782,10 @@ static int update_remote(unsigned char *sha1, struct remote_lock *lock)
curl_easy_setopt(slot->curl, CURLOPT_INFILE, &out_buffer);
curl_easy_setopt(slot->curl, CURLOPT_INFILESIZE, out_buffer.buf.len);
curl_easy_setopt(slot->curl, CURLOPT_READFUNCTION, fread_buffer);
+#ifndef NO_CURL_IOCTL
+ curl_easy_setopt(slot->curl, CURLOPT_IOCTLFUNCTION, ioctl_buffer);
+ curl_easy_setopt(slot->curl, CURLOPT_IOCTLDATA, &out_buffer);
+#endif
curl_easy_setopt(slot->curl, CURLOPT_WRITEFUNCTION, fwrite_null);
curl_easy_setopt(slot->curl, CURLOPT_CUSTOMREQUEST, DAV_PUT);
curl_easy_setopt(slot->curl, CURLOPT_HTTPHEADER, dav_headers);
@@ -1910,6 +1930,10 @@ static void update_remote_info_refs(struct remote_lock *lock)
curl_easy_setopt(slot->curl, CURLOPT_INFILE, &buffer);
curl_easy_setopt(slot->curl, CURLOPT_INFILESIZE, buffer.buf.len);
curl_easy_setopt(slot->curl, CURLOPT_READFUNCTION, fread_buffer);
+#ifndef NO_CURL_IOCTL
+ curl_easy_setopt(slot->curl, CURLOPT_IOCTLFUNCTION, ioctl_buffer);
+ curl_easy_setopt(slot->curl, CURLOPT_IOCTLDATA, &buffer);
+#endif
curl_easy_setopt(slot->curl, CURLOPT_WRITEFUNCTION, fwrite_null);
curl_easy_setopt(slot->curl, CURLOPT_CUSTOMREQUEST, DAV_PUT);
curl_easy_setopt(slot->curl, CURLOPT_HTTPHEADER, dav_headers);
diff --git a/http.c b/http.c
index eae74aa..3e8d548 100644
--- a/http.c
+++ b/http.c
@@ -44,6 +44,25 @@ size_t fread_buffer(void *ptr, size_t eltsize, size_t nmemb, void *buffer_)
return size;
}
+#ifndef NO_CURL_IOCTL
+curlioerr ioctl_buffer(CURL *handle, int cmd, void *clientp)
+{
+ struct buffer *buffer = clientp;
+
+ switch (cmd) {
+ case CURLIOCMD_NOP:
+ return CURLIOE_OK;
+
+ case CURLIOCMD_RESTARTREAD:
+ buffer->posn = 0;
+ return CURLIOE_OK;
+
+ default:
+ return CURLIOE_UNKNOWNCMD;
+ }
+}
+#endif
+
size_t fwrite_buffer(const void *ptr, size_t eltsize, size_t nmemb, void *buffer_)
{
size_t size = eltsize * nmemb;
diff --git a/http.h b/http.h
index 905b462..26abebe 100644
--- a/http.h
+++ b/http.h
@@ -37,6 +37,10 @@
#define CURLE_HTTP_RETURNED_ERROR CURLE_HTTP_NOT_FOUND
#endif
+#if LIBCURL_VERSION_NUM < 0x070c03
+#define NO_CURL_IOCTL
+#endif
+
struct slot_results
{
CURLcode curl_result;
@@ -67,6 +71,9 @@ struct buffer
extern size_t fread_buffer(void *ptr, size_t eltsize, size_t nmemb, void *strbuf);
extern size_t fwrite_buffer(const void *ptr, size_t eltsize, size_t nmemb, void *strbuf);
extern size_t fwrite_null(const void *ptr, size_t eltsize, size_t nmemb, void *strbuf);
+#ifndef NO_CURL_IOCTL
+extern curlioerr ioctl_buffer(CURL *handle, int cmd, void *clientp);
+#endif
/* Slot lifecycle functions */
extern struct active_request_slot *get_active_slot(void);
--
1.6.0.2
^ permalink raw reply related
* [PATCH v2] Add configuration variable for sign-off to format-patch
From: Heiko Voigt @ 2009-04-01 17:51 UTC (permalink / raw)
To: Jeff King; +Cc: git, Junio C Hamano
In-Reply-To: <20090401102610.GC26181@coredump.intra.peff.net>
If you regularly create patches which require a Signed-off: line you may
want to make it your default to add that line. It also helps you not to forget
to add the -s/--signoff switch.
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
---
This adds a note about the purpose of the Signed-off-by: line to the
Documentation this is the interdiff:
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 9ccc28c..27cb7f1 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -717,7 +717,10 @@ format.thread::
format.signoff::
A boolean value which lets you enable the `-s/--signoff` option of
- format-patch by default.
+ format-patch by default. *Note:* Adding the Signed-off-by: line to a
+ patch should be a conscious act and means that you certify you have
+ the rights to submit this work under the same open source license.
+ Please see the 'SubmittingPatches' document for further discussion.
gc.aggressiveWindow::
The window size parameter used in the delta compression
Documentation/config.txt | 7 +++++++
Documentation/git-format-patch.txt | 1 +
builtin-log.c | 23 ++++++++++++++++-------
3 files changed, 24 insertions(+), 7 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index ad22cb8..27cb7f1 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -715,6 +715,13 @@ format.thread::
A true boolean value is the same as `shallow`, and a false
value disables threading.
+format.signoff::
+ A boolean value which lets you enable the `-s/--signoff` option of
+ format-patch by default. *Note:* Adding the Signed-off-by: line to a
+ patch should be a conscious act and means that you certify you have
+ the rights to submit this work under the same open source license.
+ Please see the 'SubmittingPatches' document for further discussion.
+
gc.aggressiveWindow::
The window size parameter used in the delta compression
algorithm used by 'git-gc --aggressive'. This defaults
diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index c2eb5fa..c25ea10 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -197,6 +197,7 @@ more than one.
numbered = auto
cc = <email>
attach [ = mime-boundary-string ]
+ signoff = true
------------
diff --git a/builtin-log.c b/builtin-log.c
index c7a5772..d77b7fb 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -465,6 +465,7 @@ static void add_header(const char *value)
#define THREAD_SHALLOW 1
#define THREAD_DEEP 2
static int thread = 0;
+static int do_signoff = 0;
static int git_format_config(const char *var, const char *value, void *cb)
{
@@ -514,6 +515,10 @@ static int git_format_config(const char *var, const char *value, void *cb)
thread = git_config_bool(var, value) && THREAD_SHALLOW;
return 0;
}
+ if (!strcmp(var, "format.signoff")) {
+ do_signoff = git_config_bool(var, value);
+ return 0;
+ }
return git_log_config(var, value, cb);
}
@@ -865,13 +870,7 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
}
else if (!strcmp(argv[i], "--signoff") ||
!strcmp(argv[i], "-s")) {
- const char *committer;
- const char *endpos;
- committer = git_committer_info(IDENT_ERROR_ON_NO_NAME);
- endpos = strchr(committer, '>');
- if (!endpos)
- die("bogus committer info %s", committer);
- add_signoff = xmemdupz(committer, endpos - committer + 1);
+ do_signoff = 1;
}
else if (!strcmp(argv[i], "--attach")) {
rev.mime_boundary = git_version_string;
@@ -923,6 +922,16 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
}
argc = j;
+ if(do_signoff) {
+ const char *committer;
+ const char *endpos;
+ committer = git_committer_info(IDENT_ERROR_ON_NO_NAME);
+ endpos = strchr(committer, '>');
+ if (!endpos)
+ die("bogus committer info %s", committer);
+ add_signoff = xmemdupz(committer, endpos - committer + 1);
+ }
+
for (i = 0; i < extra_hdr_nr; i++) {
strbuf_addstr(&buf, extra_hdr[i]);
strbuf_addch(&buf, '\n');
--
1.6.2.1.424.g0b27.dirty
^ permalink raw reply related
* Re: [PATCH] Add configuration variable for sign-off to format-patch
From: Heiko Voigt @ 2009-04-01 17:53 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git, Junio C Hamano
In-Reply-To: <49D27359.1040703@op5.se>
On Tue, Mar 31, 2009 at 09:47:37PM +0200, Andreas Ericsson wrote:
> Can we please make it "formatpatch.signoff" or some such instead? Just
> plain "format" is a bit too generic for my taste.
But all options for format-patch are already beginning with format. So
probably leave it like this for consistency reasons.
cheers Heiko
^ permalink raw reply
* Re: [PATCH v2] Add configuration variable for sign-off to format-patch
From: Sverre Rabbelier @ 2009-04-01 17:55 UTC (permalink / raw)
To: Heiko Voigt; +Cc: Jeff King, git, Junio C Hamano
In-Reply-To: <20090401175153.GA90421@macbook.lan>
Heya,
On Wed, Apr 1, 2009 at 19:51, Heiko Voigt <hvoigt@hvoigt.net> wrote:
> format.signoff::
> A boolean value which lets you enable the `-s/--signoff` option of
> - format-patch by default.
> + format-patch by default. *Note:* Adding the Signed-off-by: line to a
> + patch should be a conscious act and means that you certify you have
> + the rights to submit this work under the same open source license.
> + Please see the 'SubmittingPatches' document for further discussion.
Which brings us to the question... what about projects that do not
have such a file?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH 1/8] mergetool: use tabs consistently
From: Junio C Hamano @ 2009-04-01 17:56 UTC (permalink / raw)
To: David Aguilar; +Cc: Charles Bailey, git
In-Reply-To: <20090331063613.GA20690@gmail.com>
David Aguilar <davvid@gmail.com> writes:
> On 0, Charles Bailey <charles@hashpling.org> wrote:
>> On Mon, Mar 30, 2009 at 01:44:01AM -0700, Junio C Hamano wrote:
>>
>> I don't much like [1/8] though. I'm all in favour of consistency, but
>> this patch touches most of the lines in git-mergetool and tries to go
>> the opposite way to the consistency drive that we were trying to
>> introduce gradually (i.e. only through lines materially affected by
>> subsequent patches) in:
>
> Sounds good. I'll re-roll and give the refactoring another go.
>
> I think we can definitely do better, and more importantly, I
> think we can decouple things by using less globals.
>
> Junio, did you have any comments about patch v2
> "difftool: add support for difftool.prompt config variable"?
I only took a cursory look but it; you did seem to have based it on the
one I queued in 'pu' with a typo-fixup and it looked fine.
Thanks.
^ permalink raw reply
* Re: Segfault on merge with 1.6.2.1
From: Clemens Buchacher @ 2009-04-01 18:06 UTC (permalink / raw)
To: Michael Johnson; +Cc: Miklos Vajna, git
In-Reply-To: <op.urnad7jbso3nzr@sulidor.mdjohnson.us>
On Tue, Mar 31, 2009 at 02:14:21AM -0500, Michael Johnson wrote:
> It would appear that the patch has already been applied to 1.6.2.1.
I don't think it has. But judging from the stack trace this bug is unrelated
to the patch anyways.
If nobody else is dealing with this I'd like to have a look at it. Could you
please send me a copy of the repo.
Thanks,
Clemens
^ permalink raw reply
* More help with "pull" please
From: John Dlugosz @ 2009-04-01 19:28 UTC (permalink / raw)
To: git
I've actually given up on using "git pull" at all, preferring to fetch
first, examine in gitk, and then decide whether to merge or whatever.
The problem I have is that it seems to always want to merge "something"
with the current checked-out branch. It always throws the remote HEAD
into the mix, or if fetch lines are set up in the configuration file,
takes the first thing on there regardless of which branch I'm currently
checked out. Maybe I'm wrong, but I just re-read the man page, forward
and backwards, and am more bewildered than ever.
Anyway, I want to help out a co-worker who has a more specialized
situation that may be right for a pull. Also, I'll talk him through
cloning the remote from the beginning, so the config files won't be all
strange or not setup from the previous users.
The only remaining issue is the remote in question: it is not a bare
repository, and may be in use locally as well, at least for maintenance.
So I can't trust its HEAD to be anything reasonable at any given time.
This person wants to track a remote branch tip. When that advances or
otherwise changes on the remote, update the working tree to match. It
will always use the same branch, let's call it ReleaseCandidate for this
discussion.
My question is: What is the easiest way to create this local repository
and operate it so that he can just keep it following that branch on the
remote?
Thanks,
--John
(excuse the footer; it's not my idea)
TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
If you received this in error, please contact the sender and delete the material from any computer.
^ permalink raw reply
* Re: "git clone --depth <depth>" producing history with <depth + 1> commits?
From: Sebastian Pipping @ 2009-04-01 19:39 UTC (permalink / raw)
To: git
In-Reply-To: <49CBB490.8040908@hartwork.org>
Sebastian Pipping wrote:
> Is "git clone --depth 1 <ropository>" expected to give a history
> with 2 commits? "--depth 2" gives 3 commits, "--depth 0" all.
>
> Is that by design or a bug?
Anyone? Is "git clone --depth 1 <ropository>" really
supposed to produce a history holding _two_ commits? Why so?
Sebastian
^ permalink raw reply
* Re: More help with "pull" please
From: Tomas Carnecky @ 2009-04-01 20:15 UTC (permalink / raw)
To: John Dlugosz; +Cc: git
In-Reply-To: <450196A1AAAE4B42A00A8B27A59278E70A7D4D9A@EXCHANGE.trad.tradestation.com>
On Apr 1, 2009, at 9:28 PM, John Dlugosz wrote:
> I've actually given up on using "git pull" at all, preferring to fetch
> first, examine in gitk, and then decide whether to merge or whatever.
>
> The problem I have is that it seems to always want to merge
> "something"
> with the current checked-out branch. It always throws the remote HEAD
> into the mix, or if fetch lines are set up in the configuration file,
> takes the first thing on there regardless of which branch I'm
> currently
> checked out. Maybe I'm wrong, but I just re-read the man page,
> forward
> and backwards, and am more bewildered than ever.
When you create a branch, you can tell git which remote branch it
tracks, like this:
$ git branch --track mynext origin/next
So whenever you are on brach 'mynext' and do a git-pull, it will fetch
and merge origin/next.
You can do the same with the git-checkout command:
$ git checkout --track origin/next
This will create a local branch 'next' which tracks 'origin/next'
> Anyway, I want to help out a co-worker who has a more specialized
> situation that may be right for a pull. Also, I'll talk him through
> cloning the remote from the beginning, so the config files won't be
> all
> strange or not setup from the previous users.
>
> The only remaining issue is the remote in question: it is not a bare
> repository, and may be in use locally as well, at least for
> maintenance.
> So I can't trust its HEAD to be anything reasonable at any given time.
>
> This person wants to track a remote branch tip. When that advances or
> otherwise changes on the remote, update the working tree to match. It
> will always use the same branch, let's call it ReleaseCandidate for
> this
> discussion.
>
> My question is: What is the easiest way to create this local
> repository
> and operate it so that he can just keep it following that branch on
> the
> remote?
$ git clone $url XXX
$ cd XXX
$ git checkout --trach origin/ReleaseCandidate
...
$ git pull # will automatically fetch and merge origin/ReleaseCandidate
tom
^ permalink raw reply
* Re: [PATCH] builtin-clone.c: fix memory leak in cmd_clone()
From: Ali Gholami Rudi @ 2009-04-01 20:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7v3acs1gyf.fsf@gitster.siamese.dyndns.org>
Hi,
Junio C Hamano <gitster@pobox.com> wrote:
> Yup, I'll queue (I won't have time today to work on git it seems) the
Thanks.
> other two patches from you, but I was going to drop this one---unless your
> plan was to make cmd_clone() callable more than once in order to use it in
> say a C rewrite of git submodule or something like that.
The only problem in builtin-clone.c seems to be remove_junk() which is
called from a signal handler or atexit(). cmd_clone() can be changed to
register this function only once.
remove_junk() uses junk_* global variables which are overwritten in each
cmd_clone() call. Since no concurrent cmd_clone() is allowed (?) and we
only care about the last one, this does not seem to be an issue.
I'll probably send a new patch tomorrow.
Regards,
Ali
^ permalink raw reply
* [PATCH v2] Cleanup warning about known issues in cvsimport documentation
From: Heiko Voigt @ 2009-04-01 20:24 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20090331194940.GB23184@coredump.intra.peff.net>
Not all statements were complete sentences.
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
---
I corrected the typos. This is the interdiff:
diff --git a/Documentation/git-cvsimport.txt b/Documentation/git-cvsimport.txt
index ba6a50b..d7bab13 100644
--- a/Documentation/git-cvsimport.txt
+++ b/Documentation/git-cvsimport.txt
@@ -176,7 +176,7 @@ Problems related to timestamps:
to be used for ordering commits changes may show up in the wrong
order.
* If any files were ever "cvs import"ed more than once (e.g., import of
- more than one vendor release) the HEAD will be incorrect.
+ more than one vendor release) the HEAD contains the wrong content.
* If the timestamp order of different files cross the revision order
within the commit matching time window the order of commits may be
wrong.
@@ -187,7 +187,7 @@ Problems related to branches:
* All files from the branching point are added to a branch even if
never added in cvs.
* This applies to files added to the source branch *after* a daughter
- branch was created: If previously no commit was made on the daugther
+ branch was created: if previously no commit was made on the daughter
branch they will erroneously be added to the daughter branch in git.
Problems related to tags:
Documentation/git-cvsimport.txt | 20 +++++++++++---------
1 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/Documentation/git-cvsimport.txt b/Documentation/git-cvsimport.txt
index e1fd047..d7bab13 100644
--- a/Documentation/git-cvsimport.txt
+++ b/Documentation/git-cvsimport.txt
@@ -173,24 +173,26 @@ ISSUES
Problems related to timestamps:
* If timestamps of commits in the cvs repository are not stable enough
- to be used for ordering commits
+ to be used for ordering commits changes may show up in the wrong
+ order.
* If any files were ever "cvs import"ed more than once (e.g., import of
- more than one vendor release)
+ more than one vendor release) the HEAD contains the wrong content.
* If the timestamp order of different files cross the revision order
- within the commit matching time window
+ within the commit matching time window the order of commits may be
+ wrong.
Problems related to branches:
- * Branches on which no commits have been made are not imported
+ * Branches on which no commits have been made are not imported.
* All files from the branching point are added to a branch even if
- never added in cvs
- * files added to the source branch *after* a daughter branch was
- created: If previously no commit was made on the daugther branch they
- will erroneously be added to the daughter branch in git
+ never added in cvs.
+ * This applies to files added to the source branch *after* a daughter
+ branch was created: if previously no commit was made on the daughter
+ branch they will erroneously be added to the daughter branch in git.
Problems related to tags:
-* Multiple tags on the same revision are not imported
+* Multiple tags on the same revision are not imported.
If you suspect that any of these issues may apply to the repository you
want to import consider using these alternative tools which proved to be
--
1.6.2.1.424.g0b27.dirty
^ permalink raw reply related
* Re: On git 1.6 (novice's opinion)
From: Heiko Voigt @ 2009-04-01 20:37 UTC (permalink / raw)
To: Ulrich Windl; +Cc: Andreas Ericsson, Russ Dill, H.Merijn Brand, git
In-Reply-To: <49D35454.12423.D32681@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de>
On Wed, Apr 01, 2009 at 11:47:31AM +0200, Ulrich Windl wrote:
> So I really don't see that relying on file dates is much better than
> doing a full rebuild. That's specifically true if you pull a new tree:
> If I understand things right, EVERY file will have a current date, so
> you'll rebuild everything anyway. So you could also have the "real
> file dates" and then do "make clean; make all". I see no benefit from
> either approach.
I am not sure if you understand it right. When switching branches git
will only touch the files that have changed between your old and your
new tree. make will then only build those files that are actually
different between those two trees because they have been given a newer
date than their target files. All other files in your working copy will
not be touched.
cheers Heiko
^ permalink raw reply
* Re: Detached HEAD warning (again)
From: Junio C Hamano @ 2009-04-01 20:41 UTC (permalink / raw)
To: Pieter de Bie; +Cc: Git Mailing List
In-Reply-To: <9099EAF5-6B43-4F15-A905-9E21B45B7AE9@ai.rug.nl>
Pieter de Bie <pdebie@ai.rug.nl> writes:
> I strongly remember there being a discussion about this a few weeks ago,
> but I can't find it. Basically, someone wanted to introduce a warning
> every time someone commits on a detached HEAD. This was shot down
> because there already is a big warning when you detach your HEAD (with
> which I agree).
>
> However, someone here: http://news.ycombinator.com/item?id=538619
> pointed to an example here: http://book.git-scm.com/5_submodules.html ,
> which works with submodules:
>
> $ git submodule update --init
> # sub/ is created
> $ (cd sub && touch a && git add a && git commit -am "Add new file")
> [detached HEAD 8641889] Add new file
> 0 files changed, 0 insertions(+), 0 deletions(-)
> create mode 100644 a
>
> $ git submodule update
> $ ls sub/a
> ls: sub/a: No such file or directory
>
> Now, it DOES say 'detached HEAD', but I still think this is something
> easily missed and something that can cause a lot of confusion. Perhaps a
> warning in such cases wouldn't hurt?
There are two distinct uses of detached HEAD state.
* Sight-see. Jump around in various points in history in order to check
the contents inside work tree. "git checkout vX.Y.Z" tag to build the
released version and running bisect are examples of such uses.
* Rebuilding history outside of any branch. You could:
... on "topic" that is to be rewritten ...
$ git checkout -b topic-2
$ git rebase -i master
... check the result, compare it with the original ...
$ git show-branch topic topic-2
$ git diff topic topic-2
... wrap it up ...
$ git branch -f topic
$ git checkout topic
$ git branch -D topic-2
but it often is more convenient to detach the HEAD at the fork point of
it:
$ git checkout topic^0
$ git rebase -i master
$ git show-branch topic HEAD
$ git diff topic HEAD
$ git branch -f topic
$ git checkout topic
When switching branches between superproject branches that have different
commits at one submodule, you may need to have a checkout of the matching
commit in the submodule directory. From the superproject's point of view,
a submodule is not something you are developing directly (you may debug
and perform other observation of what is in submodule) inside its context,
iow inside the superproject's checkout. A submodule is a shared resource
among multiple superprojects, does not belong to a particular
superproject, and inside one particular superproject's context is not the
best place to be developing it. In such a workflow, the submodule
checkout is used only in "sightseeing" mode, and the user should not even
be thinking about making commits in there to affect the submodule's
history. There is no need for a huge warning.
Side note. In such a workflow, when you find issues in submodule
inside the context of the superproject checkout, you address them
there first, perhaps by even making commits, but then you take the
changes back to a standalone checkout the submodule repository you
keep elsewhere (perhaps you would pull and may even need to
merge), independently validate the result, perhaps within the
context of some other superproject that shares the submodule,
before advancing the branch tip. And then you fetch the result
back to the submodule checkout you started from.
Things get complex _only_ when you start using the submodule checkout that
is contained within a superproject work tree as the primary place to
advance history of the submodule. Otherwise, your submodule "repository"
embedded within the superproject checkout do not even have to have any
branch. Its HEAD can always be detached.
A few random thoughts to reduce the need of detached HEAD in the submodule
context, if the user chooses to use it to develop history:
* Perhaps "git submodule update" may want an optional parameter for the
users to tell "update by switching to this branch in the submodule",
instead of detaching HEAD? The submodule checkout may or may not what
the superproject records for the path as the result, but after that an
add followed by a commit in the superproject will record the fact that
you now want to bind a new commit at the tip of the submoudle branch to
the submodule path.
* Perhaps "git submodule" may want to learn a feature for the users to
optinally express "In my workflow, when I am on superproject branch
'xyzzy', I want branch 'frotz' in this submodule" to facilitate the
above?
* When we switch branches while you have local changes to a blob in your
work tree, you take them with you if two branches record the same blob
at the path, and need to force a merge if two branches record different
blobs. In a similar way, perhaps when the commit recorded in the
superproject tree does not match what the tip of the submodule branch
switched to with the new feature suggested above, "submodule update"
can fail and give the user a chance to force a merge?
^ permalink raw reply
* [PATCH] Documentation: git-svn: fix trunk/fetch svn-remote key typo
From: Wesley J. Landaker @ 2009-04-01 21:02 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 519 bytes --]
Fix the git-svn documentation svn-remote example section talking about
tags and branches by using the proper key "fetch" instead of "trunk".
Using "trunk" actually might be nice, but it doesn't currently work.
The fetch line for the trunk was also reordered to be at the top of the
list, since most people think about the trunk/tags/branches trio in that
logical order.
Signed-off-by: Wesley J. Landaker <wjl@icecavern.net>
---
Documentation/git-svn.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
[-- Attachment #2: fa96799d745c94a691cb71a3768afc328718416c.diff --]
[-- Type: text/x-patch, Size: 726 bytes --]
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index cda3389..64f1c55 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -672,9 +672,9 @@ listed below are allowed:
------------------------------------------------------------------------
[svn-remote "project-a"]
url = http://server.org/svn
+ fetch = trunk/project-a:refs/remotes/project-a/trunk
branches = branches/*/project-a:refs/remotes/project-a/branches/*
tags = tags/*/project-a:refs/remotes/project-a/tags/*
- trunk = trunk/project-a:refs/remotes/project-a/trunk
------------------------------------------------------------------------
Keep in mind that the '*' (asterisk) wildcard of the local ref
^ permalink raw reply related
* [PATCHv2 0/2] Make local branches behave like remote branches when --tracked
From: Michael J Gruber @ 2009-04-01 21:42 UTC (permalink / raw)
To: git; +Cc: Daniel Barkalow, Johannes Schindelin, Junio C Hamano
In-Reply-To: <49CD0440.6010304@drmicha.warpmail.net>
This mini series makes local branches behave the same as remote ones
when they are used as --tracked branches. This means differences are
reported by git status and git checkout, and also that the soon to be
released tracking branch short cut (aka BEL) will work.
v2 adds a more detailed commit message to 2/2 and fixes up formatting.
Also, the simplification of remote refs is now unchanged, and local refs
are simplified in the same way. This may lead to ambiguous refs just
like before this series. Unique simplification (which several places may
benefit from) is left for a future series.
Michael J Gruber (2):
Test for local branches being followed with --track
Make local branches behave like remote branches when --tracked
remote.c | 7 +++++--
t/t6040-tracking-info.sh | 10 +++++++++-
2 files changed, 14 insertions(+), 3 deletions(-)
^ permalink raw reply
* [PATCHv2 1/2] Test for local branches being followed with --track
From: Michael J Gruber @ 2009-04-01 21:42 UTC (permalink / raw)
To: git; +Cc: Daniel Barkalow, Johannes Schindelin, Junio C Hamano
In-Reply-To: <1238622169-5238-1-git-send-email-git@drmicha.warpmail.net>
According to the documentation, it is perfectly okay to follow local
branches using the --track option. Introduce a test which checks whether
they behave the same. Currently 1 test fails.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
t/t6040-tracking-info.sh | 10 +++++++++-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/t/t6040-tracking-info.sh b/t/t6040-tracking-info.sh
index ba90601..2a2b6b6 100755
--- a/t/t6040-tracking-info.sh
+++ b/t/t6040-tracking-info.sh
@@ -29,7 +29,9 @@ test_expect_success setup '
git checkout -b b4 origin &&
advance e &&
advance f
- )
+ ) &&
+ git checkout -b follower --track master &&
+ advance g
'
script='s/^..\(b.\)[ 0-9a-f]*\[\([^]]*\)\].*/\1 \2/p'
@@ -56,6 +58,12 @@ test_expect_success 'checkout' '
grep "have 1 and 1 different" actual
'
+test_expect_failure 'checkout with local tracked branch' '
+ git checkout master &&
+ git checkout follower >actual
+ grep "is ahead of" actual
+'
+
test_expect_success 'status' '
(
cd test &&
--
1.6.2.1.507.g0e68d
^ permalink raw reply related
* [PATCHv2 2/2] Make local branches behave like remote branches when --tracked
From: Michael J Gruber @ 2009-04-01 21:42 UTC (permalink / raw)
To: git; +Cc: Daniel Barkalow, Johannes Schindelin, Junio C Hamano
In-Reply-To: <1238622169-5238-2-git-send-email-git@drmicha.warpmail.net>
This makes sure that local branches, when followed using --track, behave
the same as remote ones (e.g. differences being reported by git status
and git checkout). This fixes 1 known failure.
The fix is done within branch_get(): The first natural candidate,
namely remote_find_tracking(), does not have all the necessary info
because in general there is no remote struct for '.', and we don't want
one because it would show up in other places as well.
branch_get(), on the other hand, has access to merge_names[] (in
addition to merge[]) and therefore can set up the followed branch
easily.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
remote.c | 7 +++++--
t/t6040-tracking-info.sh | 2 +-
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/remote.c b/remote.c
index 2b037f1..d12140e 100644
--- a/remote.c
+++ b/remote.c
@@ -1170,8 +1170,9 @@ struct branch *branch_get(const char *name)
for (i = 0; i < ret->merge_nr; i++) {
ret->merge[i] = xcalloc(1, sizeof(**ret->merge));
ret->merge[i]->src = xstrdup(ret->merge_name[i]);
- remote_find_tracking(ret->remote,
- ret->merge[i]);
+ if (remote_find_tracking(ret->remote, ret->merge[i])
+ && !strcmp(ret->remote_name, "."))
+ ret->merge[i]->dst = xstrdup(ret->merge_name[i]);
}
}
}
@@ -1451,6 +1452,8 @@ int format_tracking_info(struct branch *branch, struct strbuf *sb)
base = branch->merge[0]->dst;
if (!prefixcmp(base, "refs/remotes/")) {
base += strlen("refs/remotes/");
+ } else if (!prefixcmp(base, "refs/heads/")) {
+ base += strlen("refs/heads/");
}
if (!num_theirs)
strbuf_addf(sb, "Your branch is ahead of '%s' "
diff --git a/t/t6040-tracking-info.sh b/t/t6040-tracking-info.sh
index 2a2b6b6..3d6db4d 100755
--- a/t/t6040-tracking-info.sh
+++ b/t/t6040-tracking-info.sh
@@ -58,7 +58,7 @@ test_expect_success 'checkout' '
grep "have 1 and 1 different" actual
'
-test_expect_failure 'checkout with local tracked branch' '
+test_expect_success 'checkout with local tracked branch' '
git checkout master &&
git checkout follower >actual
grep "is ahead of" actual
--
1.6.2.1.507.g0e68d
^ permalink raw reply related
* How to sync two svn repositories via git?
From: Josef Wolf @ 2009-04-01 22:30 UTC (permalink / raw)
To: git
Hello,
I have two subversion repositories which I would like to synchronize via
git-svn. For this, I have set up a git repository and configured two
branches to track the subversion repositories via git-svn:
mkdir test-sync
cd test-sync
git svn init --stdlayout file://$REPOSDIR/svn-first
for repos in svn-first svn-second; do
git config svn-remote.$repos.url file://$REPOSDIR/$repos
git config svn-remote.$repos.fetch trunk:refs/remotes/$repos/trunk
git config svn-remote.$repos.branches branches/*:refs/remotes/$repos/*
git config svn-remote.$repos.tags tags/*:refs/remotes/$repos/tags/*
git svn fetch -R $repos
git checkout -b $repos $repos/trunk
done
git gc
This gives me two remote and two local branches:
master
svn-first
* svn-second
svn-first/trunk
svn-second/trunk
The first step I'd like to do is to "mirror" the manual merges that were
done between the subversion repositories in the past:
git checkout svn-first
git merge -s ours --log commit-of-the-first-merge-in-svn-second
git checkout svn-second
git merge -s ours --log commit-of-the-first-merge-in-svn-first
This seems to work, but git-gui shows conflicts. How can I get conflicts
when I use the "-s ours" merge strategy?
^ permalink raw reply
* Re: [PATCH 03/10] Add a mergetool-lib scriptlet for holding common merge tool functions
From: Markus Heidelberg @ 2009-04-01 22:39 UTC (permalink / raw)
To: David Aguilar; +Cc: gitster, charles, git
In-Reply-To: <1238590514-41893-4-git-send-email-davvid@gmail.com>
David Aguilar, 01.04.2009:
>
> diff --git a/git-mergetool-lib.sh b/git-mergetool-lib.sh
> +valid_tool () {
> + case "$1" in
> + kdiff3 | kompare | tkdiff | xxdiff | meld | opendiff | emerge | vimdiff | gvimdiff | ecmerge)
> + if test "$1" = "kompare" && ! diff_mode; then
> + return 1
> + fi
> + ;; # happy
> + *)
> + if ! test -n "$(get_custom_cmd "$1")"; then
Better this?
if test -z "$(get_custom_cmd "$1")"; then
> + return 1
> + fi ;;
For consistency:
fi
;;
^ permalink raw reply
* Re: [PATCH 08/10] mergetool-lib: introduce run_mergetool
From: Markus Heidelberg @ 2009-04-01 22:47 UTC (permalink / raw)
To: David Aguilar; +Cc: gitster, charles, git
In-Reply-To: <1238590514-41893-9-git-send-email-davvid@gmail.com>
David Aguilar, 01.04.2009:
> diff --git a/git-mergetool-lib.sh b/git-mergetool-lib.sh
> +run_mergetool () {
> + base_present="$2"
> + if diff_mode; then
> + base_present="false"
> + fi
> + if test -z "$base_present"; then
> + base_present="true"
> + fi
> +
> + case "$1" in
> + kdiff3)
> + if $base_present; then
> + ("$merge_tool_path" --auto \
> + --L1 "$MERGED (Base)" --L2 "$MERGED (Local)" --L3 "$MERGED (Remote)" \
> + -o "$MERGED" "$BASE" "$LOCAL" "$REMOTE" > /dev/null 2>&1)
> + else
> + ("$merge_tool_path" --auto \
> + --L1 "$MERGED (Local)" --L2 "$MERGED (Remote)" \
> + -o "$MERGED" "$LOCAL" "$REMOTE" > /dev/null 2>&1)
> + fi
> + status=$?
> + ;;
> + kompare)
> + "$merge_tool_path" "$LOCAL" "$REMOTE"
> + status=$?
> + ;;
> + tkdiff)
> + if $base_present; then
> + "$merge_tool_path" -a "$BASE" -o "$MERGED" "$LOCAL" "$REMOTE"
> + else
> + if diff_mode; then
Query merge_mode instead of diff_mode as in all the other places.
> + "$merge_tool_path" "$LOCAL" "$REMOTE"
> + else
> + "$merge_tool_path" -o "$MERGED" "$LOCAL" "$REMOTE"
> + fi
> + fi
> + status=$?
> + ;;
> + meld)
> + merge_mode && touch "$BACKUP"
> + if merge_mode; then
> + "$merge_tool_path" "$LOCAL" "$MERGED" "$REMOTE"
Put the touch command into the if then block as in the other places.
> + else
> + "$merge_tool_path" "$LOCAL" "$REMOTE"
> + fi
> + check_unchanged
> + ;;
> + vimdiff)
> + if merge_mode; then
> + touch "$BACKUP"
> + "$merge_tool_path" -c "wincmd l" "$LOCAL" "$MERGED" "$REMOTE"
> + check_unchanged
> + else
> + "$merge_tool_path" -c "wincmd l" "$LOCAL" "$REMOTE"
> + fi
> + ;;
> + gvimdiff)
> + if merge_mode; then
> + touch "$BACKUP"
> + "$merge_tool_path" -c "wincmd l" -f "$LOCAL" "$MERGED" "$REMOTE"
> + check_unchanged
> + else
> + "$merge_tool_path" -c "wincmd l" -f "$LOCAL" "$REMOTE"
> + fi
> + ;;
> + xxdiff)
> + merge_mode && touch "$BACKUP"
> + if $base_present; then
> + "$merge_tool_path" -X --show-merged-pane \
> + -R 'Accel.SaveAsMerged: "Ctrl-S"' \
> + -R 'Accel.Search: "Ctrl+F"' \
> + -R 'Accel.SearchForward: "Ctrl-G"' \
> + --merged-file "$MERGED" "$LOCAL" "$BASE" "$REMOTE"
> + else
> + merge_mode && extra=--show-merged-pane
> + "$merge_tool_path" -X $extra \
> + -R 'Accel.SaveAsMerged: "Ctrl-S"' \
> + -R 'Accel.Search: "Ctrl+F"' \
> + -R 'Accel.SearchForward: "Ctrl-G"' \
> + --merged-file "$MERGED" "$LOCAL" "$REMOTE"
> + fi
> + check_unchanged
> + ;;
> + opendiff)
> + merge_mode && touch "$BACKUP"
> + if $base_present; then
> + "$merge_tool_path" "$LOCAL" "$REMOTE" \
> + -ancestor "$BASE" -merge "$MERGED" | cat
> + else
> + "$merge_tool_path" "$LOCAL" "$REMOTE" \
> + -merge "$MERGED" | cat
> + fi
> + check_unchanged
> + ;;
> + ecmerge)
> + merge_mode && touch "$BACKUP"
> + if $base_present; then
> + "$merge_tool_path" "$BASE" "$LOCAL" "$REMOTE" \
> + --default --mode=merge3 --to="$MERGED"
> + else
> + "$merge_tool_path" "$LOCAL" "$REMOTE" \
> + --default --mode=merge2 --to="$MERGED"
> + fi
> + check_unchanged
> + ;;
> + emerge)
> + if $base_present; then
> + "$merge_tool_path" -f emerge-files-with-ancestor-command \
> + "$LOCAL" "$REMOTE" "$BASE" "$(basename "$MERGED")"
> + else
> + "$merge_tool_path" -f emerge-files-command \
> + "$LOCAL" "$REMOTE" "$(basename "$MERGED")"
> + fi
> + status=$?
> + ;;
> + *)
> + if test -n "$merge_tool_cmd"; then
> + if merge_mode &&
> + test "$merge_tool_trust_exit_code" = "false"; then
> + touch "$BACKUP"
> + ( eval $merge_tool_cmd )
> + check_unchanged
> + else
> + ( eval $merge_tool_cmd )
> + status=$?
> + fi
> + fi
> + ;;
> + esac
> +}
^ permalink raw reply
* RE: More help with "pull" please
From: John Dlugosz @ 2009-04-01 22:53 UTC (permalink / raw)
To: Tomas Carnecky; +Cc: git
In-Reply-To: <4659A860-4AF5-4E34-B38E-60C926E2BAE1@dbservice.com>
> When you create a branch, you can tell git which remote branch it
> tracks, like this:
>
> $ git branch --track mynext origin/next
>
> So whenever you are on brach 'mynext' and do a git-pull, it will fetch
> and merge origin/next.
>
> You can do the same with the git-checkout command:
>
> $ git checkout --track origin/next
>
> This will create a local branch 'next' which tracks 'origin/next'
>
OK, that works by adding something to the config file, right? The docs
don't say, but does mention "having Pull: <refspec> lines for a
<repository>". Does tracking add Pull: lines, or is that another
feature?
>
> $ git clone $url XXX
> $ cd XXX
> $ git checkout --track origin/ReleaseCandidate
> ...
> $ git pull # will automatically fetch and merge
origin/ReleaseCandidate
According to the manpage on pull, "While git-pull run without any
explicit <refspec> parameter takes default <refspec>s from Pull: lines,
it merges only the first <refspec> found into the current branch, after
fetching all the remote refs."
Also, "When no refspec was given on the command line ... If
branch.<name>.merge configuration for the current branch <name> exists,
that is the name of the branch at the remote site that is merged." So
is that yet again different from having Pull: lines? If so, I'm fine if
no "Pull:" lines exist, or it would merge the first refspec found there.
Also, "Normally the branch merged in is the HEAD of the remote
repository, but the choice is determined by the branch.<name>.remote and
branch.<name>.merge options; see git-config(1) for details." That
agrees with the previous. If branch.<name>.merge configuration exists,
I don't need to worry about the remote HEAD.
> $ git checkout --track origin/ReleaseCandidate
That command does not work. It compains that --track can only be used
with -b, etc.
I think
git checkout -b origin/ReleaseCandidate
is the correct shortcut?
git checkout -b ReleaseCandidate origin/ReleaseCandidate
did work. I know that --track is automatic if the second argument is
remote.
--John
TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
If you received this in error, please contact the sender and delete the material from any computer.
^ permalink raw reply
* Re: [PATCH 10/10] mergetool: use run_mergetool from git-mergetool-lib
From: Markus Heidelberg @ 2009-04-01 22:54 UTC (permalink / raw)
To: David Aguilar; +Cc: gitster, charles, git
In-Reply-To: <1238590514-41893-11-git-send-email-davvid@gmail.com>
David Aguilar, 01.04.2009:
> This refactors git-mergetool to use run_mergetool.
>
> Signed-off-by: David Aguilar <davvid@gmail.com>
> ---
> git-mergetool.sh | 96 +++--------------------------------------------------
> 1 files changed, 6 insertions(+), 90 deletions(-)
>
> diff --git a/git-mergetool.sh b/git-mergetool.sh
> index 957993c..2c6b325 100755
> --- a/git-mergetool.sh
> +++ b/git-mergetool.sh
> @@ -190,96 +190,12 @@ merge_file () {
> read ans
> fi
>
> - case "$merge_tool" in
> - kdiff3)
> - if base_present ; then
> - ("$merge_tool_path" --auto --L1 "$MERGED (Base)" --L2 "$MERGED (Local)" --L3 "$MERGED (Remote)" \
> - -o "$MERGED" "$BASE" "$LOCAL" "$REMOTE" > /dev/null 2>&1)
> - else
> - ("$merge_tool_path" --auto --L1 "$MERGED (Local)" --L2 "$MERGED (Remote)" \
> - -o "$MERGED" "$LOCAL" "$REMOTE" > /dev/null 2>&1)
> - fi
> - status=$?
> - ;;
> - tkdiff)
> - if base_present ; then
> - "$merge_tool_path" -a "$BASE" -o "$MERGED" "$LOCAL" "$REMOTE"
> - else
> - "$merge_tool_path" -o "$MERGED" "$LOCAL" "$REMOTE"
> - fi
> - status=$?
> - ;;
> - meld)
> - touch "$BACKUP"
> - "$merge_tool_path" "$LOCAL" "$MERGED" "$REMOTE"
> - check_unchanged
> - ;;
> - vimdiff)
> - touch "$BACKUP"
> - "$merge_tool_path" -c "wincmd l" "$LOCAL" "$MERGED" "$REMOTE"
> - check_unchanged
> - ;;
> - gvimdiff)
> - touch "$BACKUP"
> - "$merge_tool_path" -c "wincmd l" -f "$LOCAL" "$MERGED" "$REMOTE"
> - check_unchanged
> - ;;
> - xxdiff)
> - touch "$BACKUP"
> - if base_present ; then
> - "$merge_tool_path" -X --show-merged-pane \
> - -R 'Accel.SaveAsMerged: "Ctrl-S"' \
> - -R 'Accel.Search: "Ctrl+F"' \
> - -R 'Accel.SearchForward: "Ctrl-G"' \
> - --merged-file "$MERGED" "$LOCAL" "$BASE" "$REMOTE"
> - else
> - "$merge_tool_path" -X --show-merged-pane \
> - -R 'Accel.SaveAsMerged: "Ctrl-S"' \
> - -R 'Accel.Search: "Ctrl+F"' \
> - -R 'Accel.SearchForward: "Ctrl-G"' \
> - --merged-file "$MERGED" "$LOCAL" "$REMOTE"
> - fi
> - check_unchanged
> - ;;
> - opendiff)
> - touch "$BACKUP"
> - if base_present; then
> - "$merge_tool_path" "$LOCAL" "$REMOTE" -ancestor "$BASE" -merge "$MERGED" | cat
> - else
> - "$merge_tool_path" "$LOCAL" "$REMOTE" -merge "$MERGED" | cat
> - fi
> - check_unchanged
> - ;;
> - ecmerge)
> - touch "$BACKUP"
> - if base_present; then
> - "$merge_tool_path" "$BASE" "$LOCAL" "$REMOTE" --default --mode=merge3 --to="$MERGED"
> - else
> - "$merge_tool_path" "$LOCAL" "$REMOTE" --default --mode=merge2 --to="$MERGED"
> - fi
> - check_unchanged
> - ;;
> - emerge)
> - if base_present ; then
> - "$merge_tool_path" -f emerge-files-with-ancestor-command "$LOCAL" "$REMOTE" "$BASE" "$(basename "$MERGED")"
> - else
> - "$merge_tool_path" -f emerge-files-command "$LOCAL" "$REMOTE" "$(basename "$MERGED")"
> - fi
> - status=$?
> - ;;
> - *)
> - if test -n "$merge_tool_cmd"; then
> - if test "$merge_tool_trust_exit_code" = "false"; then
> - touch "$BACKUP"
> - ( eval $merge_tool_cmd )
> - check_unchanged
> - else
> - ( eval $merge_tool_cmd )
> - status=$?
> - fi
> - fi
> - ;;
> - esac
> + present=false
> + base_present &&
> + present=true
> +
> + run_mergetool "$merge_tool" "$present"
> + status=$?
This last line has to be deleted, because the variable 'status' set in
run_mergetool would be overwritten then. In this case the merge will
succeed even if it didn't and the file will be staged.
> if test "$status" -ne 0; then
> echo "merge of $MERGED failed" 1>&2
> mv -- "$BACKUP" "$MERGED"
^ permalink raw reply
* Re: More help with "pull" please
From: Tomas Carnecky @ 2009-04-01 23:14 UTC (permalink / raw)
To: John Dlugosz; +Cc: git
In-Reply-To: <450196A1AAAE4B42A00A8B27A59278E70A7D4E71@EXCHANGE.trad.tradestation.com>
On Apr 2, 2009, at 12:53 AM, John Dlugosz wrote:
>> When you create a branch, you can tell git which remote branch it
>> tracks, like this:
>>
>> $ git branch --track mynext origin/next
>>
>> So whenever you are on brach 'mynext' and do a git-pull, it will
>> fetch
>> and merge origin/next.
>>
>> You can do the same with the git-checkout command:
>>
>> $ git checkout --track origin/next
>>
>> This will create a local branch 'next' which tracks 'origin/next'
>>
>
> OK, that works by adding something to the config file, right? The
> docs
> don't say, but does mention "having Pull: <refspec> lines for a
> <repository>". Does tracking add Pull: lines, or is that another
> feature?
I think Pull: lines are not used anymore in newer repositories.
Tracking is done through the 'branch.<name>.remote' and
'branch.<name>.merge' config options (which are automatically set by
git-branch/git-checkout when you use --track).
>>
>> $ git clone $url XXX
>> $ cd XXX
>> $ git checkout --track origin/ReleaseCandidate
>> ...
>> $ git pull # will automatically fetch and merge
> origin/ReleaseCandidate
>
> According to the manpage on pull, "While git-pull run without any
> explicit <refspec> parameter takes default <refspec>s from Pull:
> lines,
> it merges only the first <refspec> found into the current branch,
> after
> fetching all the remote refs."
>
> Also, "When no refspec was given on the command line ... If
> branch.<name>.merge configuration for the current branch <name>
> exists,
> that is the name of the branch at the remote site that is merged." So
> is that yet again different from having Pull: lines? If so, I'm
> fine if
> no "Pull:" lines exist, or it would merge the first refspec found
> there.
>
> Also, "Normally the branch merged in is the HEAD of the remote
> repository, but the choice is determined by the branch.<name>.remote
> and
> branch.<name>.merge options; see git-config(1) for details." That
> agrees with the previous. If branch.<name>.merge configuration
> exists,
> I don't need to worry about the remote HEAD.
I'd say forget about Pull: because you won't see any of that in newer
repositories. Instead, just use --track when checking out a branch you
intend to follow. And, more as an implementation detail than anything
else, remember that the tracking is done through the above mentioned
config options (which you can set/change using git-config or directly
by editing the .git/config file).
>
>> $ git checkout --track origin/ReleaseCandidate
>
> That command does not work. It compains that --track can only be used
> with -b, etc.
>
> I think
> git checkout -b origin/ReleaseCandidate
>
> is the correct shortcut?
>
> git checkout -b ReleaseCandidate origin/ReleaseCandidate
>
> did work. I know that --track is automatic if the second argument is
> remote.
Maybe it's because I'm using a fairly recent version
(1.6.2.1.307.g91408).
tom
^ permalink raw reply
* RE: More help with "pull" please
From: John Dlugosz @ 2009-04-01 23:26 UTC (permalink / raw)
To: Tomas Carnecky; +Cc: git
In-Reply-To: <F364AB31-EC5B-4719-834E-58613BDBC433@dbservice.com>
> I think Pull: lines are not used anymore in newer repositories.
...
> I'd say forget about Pull: because you won't see any of that in newer
> repositories. Instead, just use --track when checking out a branch you
> intend to follow. And, more as an implementation detail than anything
> else, remember that the tracking is done through the above mentioned
> config options (which you can set/change using git-config or directly
> by editing the .git/config file).
OK, the documentation is clear if I ignore that.
I expect it to be "well behaved" if I'm on a tracking branch and give it
no arguments, or if the single refspec argument is the correct remote
for the branch I'm on. Otherwise (not a tracking branch) the docs just
say "It's complicated, backward compatibility" and presumably involves
those non-existent Pull: lines and the state of the remote's HEAD.
> Maybe it's because I'm using a fairly recent version
> (1.6.2.1.307.g91408).
I'm running git version (1.6.2.msysgit.0.186.gf7512), and I assume my
coworker's was a bit older.
--John
TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
If you received this in error, please contact the sender and delete the material from any computer.
^ 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