* Re: Feature request: Store comments on branches
From: Jeff King @ 2009-10-21 14:13 UTC (permalink / raw)
To: B Smith-Mannschott; +Cc: Thomas Adam, Patrick Schoenfeld, git
In-Reply-To: <28c656e20910210656m5ad597b9h7668e33eeb86b096@mail.gmail.com>
On Wed, Oct 21, 2009 at 03:56:51PM +0200, B Smith-Mannschott wrote:
> >> What do others think about this? Would this be useful
> >> for others, too?
> >
> > This feature is already being worked on as "git notes" -- see the "pu"
> > branch, I think it's still in there, unless it has graduated to next;
> > I forget now.
>
> Really? I was under the impression that the nodes were meant to
> annotate commits, or more generally things with SHA-1 IDs. (commits,
> tress, blobs). The SHA-1 ID a branch uses to refer to its HEAD commit
> changes with every commit, and the branch itself doesn't have an ID,
> just a name.
Yes, I think you are right. If I understand the OP, he really just wants
to annotate the refs themselves, not the commits they point to. So you
could probably get away with setting a "branch.$name.description" config
variable and then showing it during "git branch". The downside of such a
scheme is that it is purely local -- there's no way of pushing or
pulling your descriptions (which is maybe a feature, if you are thinking
of the descriptions as something only for you yourself to see).
A related technique is to maintain a separate meta repository which has
a list of branches, their status, etc. This is what Junio does with the
'todo' branch of git.git. The advantage is that it is fully version
controlled, and you can do much more than just set descriptions (e.g.,
'todo' also has scripts for maintaining the list of topic branches,
calculating branch dependencies, building the pu branch, etc). The
disadvantage is that it's a lot more work to set up and maintain.
-Peff
^ permalink raw reply
* [bug][bisected] git-svn with root branches
From: Daniel Cordero @ 2009-10-21 14:41 UTC (permalink / raw)
To: Adam Brewster, Eric Wong; +Cc: git
Hello,
when trying to clone a svn repo with the command-line:
$ git svn clone -b / http://svn.collab.net/repos/svn/
(that is, each folder in the root of the repo should be considered it's
own branch)
the clone sometimes[1] fails saying:
ref: 'refs/remotes/' ends with a trailing slash, this is not permitted by git nor Subversion
The offending config is:
[svn-remote "svn"]
url = http://svn.collab.net/repos/svn
branches = /*:refs/remotes/*
This used to work in the past; I bisected the bad commit to
commit 6f5748e14cc5bb0a836b649fb8e2d6a5eb166f1d
Author: Adam Brewster <adambrewster@gmail.com>
Date: Tue Aug 11 23:14:03 2009 -0400
svn: allow branches outside of refs/remotes
Thanks in advance.
[1] It does work when the URL has at least 1 folder of depth
(e.g. suffix "trunk" to the above URL).
Its config section is:
[svn-remote "svn"]
url = http://svn.collab.net/repos/svn
branches = trunk//*:refs/remotes/*
^ permalink raw reply
* Re: [PATCH] git push: say that --tag can't be used with --all or --mirror in help text
From: Jeff King @ 2009-10-21 14:42 UTC (permalink / raw)
To: Nanako Shiraishi
Cc: Junio C Hamano, Miklos Vajna, Sebastian Pipping, git,
Bjorn Gustavsson
In-Reply-To: <20091019125701.6117@nanako3.lavabit.com>
On Mon, Oct 19, 2009 at 12:57:01PM +0900, Nanako Shiraishi wrote:
> - OPT_BOOLEAN( 0 , "tags", &tags, "push tags"),
> + OPT_BOOLEAN( 0 , "tags", &tags, "push tags (can't be used with --all nor --mirror"),
Hmm. We apparently all managed to miss this typo. It's visually hard to
notice because of the ")" closing the macro.
-- >8 --
Subject: [PATCH] push: fix typo in usage
Missing ")".
Signed-off-by: Jeff King <peff@peff.net>
---
builtin-push.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-push.c b/builtin-push.c
index 7d78711..019c986 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -181,7 +181,7 @@ int cmd_push(int argc, const char **argv, const char *prefix)
OPT_BIT( 0 , "all", &flags, "push all refs", TRANSPORT_PUSH_ALL),
OPT_BIT( 0 , "mirror", &flags, "mirror all refs",
(TRANSPORT_PUSH_MIRROR|TRANSPORT_PUSH_FORCE)),
- OPT_BOOLEAN( 0 , "tags", &tags, "push tags (can't be used with --all or --mirror"),
+ OPT_BOOLEAN( 0 , "tags", &tags, "push tags (can't be used with --all or --mirror)"),
OPT_BIT( 0 , "purge", &flags,
"remove locally deleted refs from remote",
TRANSPORT_PUSH_PURGE),
--
1.6.5.1.139.g6f544.dirty
^ permalink raw reply related
* keeping track of where a patch begins
From: E R @ 2009-10-21 14:45 UTC (permalink / raw)
To: git
Hi,
We've started to use git at work. Developers create branches for their
patches (which we call "tickets" because they are related to our
ticketing system), and those branches are picked up by an integration
team and merged together to form a release. Hopefully this is not too
unconventional.
Ideally a developer will start their ticket branch from a previous
release. However, occasionally a developer working on multiple tickets
will forget to switch back to a release node when creating a new
ticket branch. Then code from the first ticket inadvertently gets
added to the second ticket, and this is a problem if integration
decides to include the second ticket in the release but not the first.
What solutions have you come up with to either to catch or prevent
this from happening? It is possible to determine what node a branch
started from?
It seems that somehow the node that the patch begins at has to be
either identified, marked or remembered, and it might have to done
outside of git. Then the integration team or other tools can validate
the starting node to ensure that it complies with the build process.
Thanks,
ER
^ permalink raw reply
* drawbacks to svn server + git-svn vs git server?
From: Dexter Riley @ 2009-10-21 15:05 UTC (permalink / raw)
To: git
Hello. My group is currently using subversion on our version control server,
but would like to move to git as a client. We are considering using
git-svn, to avoid revalidating the server software. My question is, are
there any major disadvantages to using git-svn versus git? I know that the
git repository would be smaller. I'm more concerned about possible svn
repository corruption, performance when pushing large merges back to svn,
and any gotchas you might have encountered.
Any advice would be greatly appreciated.
Thanks,
Ed
--
View this message in context: http://www.nabble.com/drawbacks-to-svn-server-%2B-git-svn-vs-git-server--tp25994334p25994334.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Feature request: Store comments on branches
From: Bill Lear @ 2009-10-21 15:05 UTC (permalink / raw)
To: Patrick Schoenfeld; +Cc: git
In-Reply-To: <20091021133702.GA470@lisa>
On Wednesday, October 21, 2009 at 15:37:03 (+0200) Patrick Schoenfeld writes:
>Hi,
>
>I regulary work with various branches, that I call by the number
>of an associated bug tracking / support tracking number. That
>makes it clear to which ticket a given branch belongs.
>In this case I would find it very useful, if I could associate
>short comments with a branch, which would be shown when
>doing a 'git branch'. This way I could see what this branch
>about, without looking up the ticket information.
>
>Obvious the workaround is to name the branches different,
>but this is sometimes not convenient and may result in quiet
>long branch names.
For now, we do just this. We use Jira for bug reporting. When we
create a new Jira bug, we use the Jira Id as the base and then tack on
a short suffix:
% git checkout -b ADM-417_service_deploy_race_condition
We are also working on tools that would, among other things, obviate
this. For example:
% git branch
* ADM-417
ADM-312
master
% jira describe
ADM-417: Service deployments have logging race condition on first start
% jira describe -l ADM-312
ADM-312: Portal permissions set incorrectly for WEP users
Description: The portal permissions get whacked whenever ...
Assigned To: John Smith <jsmith@ourhouse.com>
Status: In Progress
[...]
The 'jira' command just connects to our Jira server and performs
actions directly on the Jira server for current or whichever branch,
etc.
Bill
^ permalink raw reply
* Re: drawbacks to svn server + git-svn vs git server?
From: Pascal Obry @ 2009-10-21 15:19 UTC (permalink / raw)
To: Dexter Riley; +Cc: git
In-Reply-To: <25994334.post@talk.nabble.com>
Le 21/10/2009 17:05, Dexter Riley a écrit :
> Hello. My group is currently using subversion on our version control server,
> but would like to move to git as a client. We are considering using
> git-svn, to avoid revalidating the server software. My question is, are
> there any major disadvantages to using git-svn versus git? I know that the
> git repository would be smaller. I'm more concerned about possible svn
> repository corruption, performance when pushing large merges back to svn,
> and any gotchas you might have encountered.
Something that come to mind immediately is that you'll loose merge
information as Subversion has linear history. I understand that recent
Subversion versions have added some information about merges but I don't
think git-svn handles this (I don't even know if it makes sense or not:).
If you have a single integrator you'll also loose the author name. Keep
in mind also that git-svn is slower to get new commits from the upstream
repository.
I've used git-svn for a while now without any trouble. And I can say
that I won't move back to using an svn client.
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net - http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B
^ permalink raw reply
* [RFC] What to you think about a loose status for submodules?
From: Heiko Voigt @ 2009-10-21 16:01 UTC (permalink / raw)
To: git; +Cc: Jens Lehmann, Lars Hjemli
Hi,
for some time now I have been thinking about submodules which are
not checked out by default. So for example if you have a project which
consist of the submodules:
project/core
/help
/app
...
Consider the situation that 'help' is really big because it is a user
friendly application ;)
So you usually do not need the help folder to develop the application
but it still is tied to a certain revision.
For such a workflow I would like to implement what I call 'loose'
submodules. Where a
git clone project.git
cd project
git submodule init && git submodule update
would omit the 'help' folder. But in case I specify it directly like
git submodule init help
it would update to the recorded revision.
Of course the relation would be configurable. E.g.:
git config submodule."name".relation loose
and the opposite as
git config submodule."name".relation tight
Initially the implementation would only deal with the initialization
case. As a second step I would like to deal with the situation whether a
submodule should be shown as changed or not. What do you think about such
an extension?
cheers Heiko
^ permalink raw reply
* Re: drawbacks to svn server + git-svn vs git server?
From: Dmitry Potapov @ 2009-10-21 16:05 UTC (permalink / raw)
To: Pascal Obry; +Cc: Dexter Riley, git
In-Reply-To: <4ADF2666.1070908@obry.net>
On Wed, Oct 21, 2009 at 05:19:02PM +0200, Pascal Obry wrote:
> Le 21/10/2009 17:05, Dexter Riley a écrit :
>> Hello. My group is currently using subversion on our version control server,
>> but would like to move to git as a client. We are considering using
>> git-svn, to avoid revalidating the server software. My question is, are
>> there any major disadvantages to using git-svn versus git? I know that the
>> git repository would be smaller. I'm more concerned about possible svn
>> repository corruption, performance when pushing large merges back to svn,
>> and any gotchas you might have encountered.
>
> Something that come to mind immediately is that you'll loose merge
> information as Subversion has linear history. I understand that recent
> Subversion versions have added some information about merges but I don't
> think git-svn handles this (I don't even know if it makes sense or not:).
AFAIK, SVN remembers what changesets have been merged and what are not
(on per file basis). So, it is more like cherry-pick with some automatic
tracking than git merge, and stored separately for each file in the repo.
So, I do not think it is easy to map svn merge concept to git one...
Inability to do merges mean that you have to track what changes what
branch by hands, which is very inconvenient if you have a few long
living branches.
Another long standing issue with git-svn was automatic end-of-line
conversion. It did not work with git-svn and the last time I heard about
it, it was disabled for repository created by git-svn. Probably, it may
not difficult to correct, but no one has looked at that closely....
> If you have a single integrator you'll also loose the author name.
Right... And if everyone has the right to commit then git-svn will
automatically rebase your changes during 'dcommit' on top of changes
made by other people, which means that you put into the repository a
different state than one you have actually tested.
Dmitry
^ permalink raw reply
* [PATCH v5 0/8] imap-send: Windows support
From: Erik Faye-Lund @ 2009-10-21 17:04 UTC (permalink / raw)
To: git; +Cc: msysgit, Erik Faye-Lund
Here's the 5th iteration of my patches for
Windows-compatibility in imap-send.
- Patch 1-3 is about getting rid of or rewriting
code with portability issues.
- Patch 4 fixes a compilation error on Windows
- Patch 5 enables compilation of imap-send
- Patch 6-7 enables SSL-suport for mingw
- Patch 8 enables imap-send and SSL for msvc
The only change compared to the previous iteration
is that patch 7 and 8 enables NEEDS_CRYPTO_WITH_SSL.
Please note that I haven't tested Patch 8 with
NEEDS_CRYPTO_WITH_SSL under MSVC, as I don't have a
working setup with both msysgit and MSVC installed.
I'd love it if someone with such a working setup
could verify that it works, preferrably also with
BLK_SHA1 enabled.
Erik Faye-Lund (6):
imap-send: use separate read and write fds
imap-send: use run-command API for tunneling
imap-send: fix compilation-error on Windows
imap-send: build imap-send on Windows
mingw: wrap SSL_set_(w|r)fd to call _get_osfhandle
mingw: enable OpenSSL
Jeff King (1):
imap-send: remove useless uid code
Marius Storm-Olsen (1):
MSVC: Enable OpenSSL, and translate -lcrypto
Makefile | 6 +-
compat/mingw.h | 21 ++++
compat/vcbuild/scripts/clink.pl | 3 +
contrib/buildsystems/engine.pl | 3 +
imap-send.c | 226 +++++++++------------------------------
5 files changed, 79 insertions(+), 180 deletions(-)
^ permalink raw reply
* [PATCH v5 3/8] imap-send: use run-command API for tunneling
From: Erik Faye-Lund @ 2009-10-21 17:04 UTC (permalink / raw)
To: git; +Cc: msysgit, Erik Faye-Lund
In-Reply-To: <1256144691-2908-3-git-send-email-kusmabite@gmail.com>
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
imap-send.c | 37 ++++++++++++++++---------------------
1 files changed, 16 insertions(+), 21 deletions(-)
diff --git a/imap-send.c b/imap-send.c
index 7216453..72ed640 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -24,6 +24,7 @@
#include "cache.h"
#include "exec_cmd.h"
+#include "run-command.h"
#ifdef NO_OPENSSL
typedef void *SSL;
#endif
@@ -940,8 +941,7 @@ static struct store *imap_open_store(struct imap_server_conf *srvc)
struct imap_store *ctx;
struct imap *imap;
char *arg, *rsp;
- int s = -1, a[2], preauth;
- pid_t pid;
+ int s = -1, preauth;
ctx = xcalloc(sizeof(*ctx), 1);
@@ -952,29 +952,24 @@ static struct store *imap_open_store(struct imap_server_conf *srvc)
/* open connection to IMAP server */
if (srvc->tunnel) {
- imap_info("Starting tunnel '%s'... ", srvc->tunnel);
+ const char *argv[4];
+ struct child_process tunnel = {0};
- if (socketpair(PF_UNIX, SOCK_STREAM, 0, a)) {
- perror("socketpair");
- exit(1);
- }
+ imap_info("Starting tunnel '%s'... ", srvc->tunnel);
- pid = fork();
- if (pid < 0)
- _exit(127);
- if (!pid) {
- if (dup2(a[0], 0) == -1 || dup2(a[0], 1) == -1)
- _exit(127);
- close(a[0]);
- close(a[1]);
- execl("/bin/sh", "sh", "-c", srvc->tunnel, NULL);
- _exit(127);
- }
+ argv[0] = "sh";
+ argv[1] = "-c";
+ argv[2] = srvc->tunnel;
+ argv[3] = NULL;
- close(a[0]);
+ tunnel.argv = argv;
+ tunnel.in = -1;
+ tunnel.out = -1;
+ if (start_command(&tunnel))
+ die("cannot start proxy %s", argv[0]);
- imap->buf.sock.fd[0] = a[1];
- imap->buf.sock.fd[1] = dup(a[1]);
+ imap->buf.sock.fd[0] = tunnel.out;
+ imap->buf.sock.fd[1] = tunnel.in;
imap_info("ok\n");
} else {
--
1.6.4.msysgit.0
^ permalink raw reply related
* [PATCH v5 1/8] imap-send: remove useless uid code
From: Erik Faye-Lund @ 2009-10-21 17:04 UTC (permalink / raw)
To: git; +Cc: msysgit, Jeff King, Erik Faye-Lund
In-Reply-To: <1256144691-2908-1-git-send-email-kusmabite@gmail.com>
From: Jeff King <peff@peff.net>
The imap-send code is based on code from isync, a program
for syncing imap mailboxes. Because of this, it has
inherited some code that makes sense for isync, but not for
imap-send.
In particular, when storing a message, it does one of:
- if the server supports it, note the server-assigned
unique identifier (UID) given to each message
- otherwise, assigned a random UID and store it in the
message header as X-TUID
Presumably this is used in isync to be able to synchronize
mailstores multiple times without duplication. But for
imap-send, the values are useless; we never do anything
with them and simply forget them at the end of the program.
This patch removes the useless code. Not only is it nice for
maintainability to get rid of dead code, but the removed
code relied on the existence of /dev/urandom, which made it
a portability problem for non-Unix platforms.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
imap-send.c | 155 ++++------------------------------------------------------
1 files changed, 11 insertions(+), 144 deletions(-)
diff --git a/imap-send.c b/imap-send.c
index 3847fd1..8da7a94 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -123,9 +123,6 @@ static int nfvasprintf(char **strp, const char *fmt, va_list ap)
return len;
}
-static void arc4_init(void);
-static unsigned char arc4_getbyte(void);
-
struct imap_server_conf {
char *name;
char *tunnel;
@@ -489,52 +486,6 @@ static int nfsnprintf(char *buf, int blen, const char *fmt, ...)
return ret;
}
-static struct {
- unsigned char i, j, s[256];
-} rs;
-
-static void arc4_init(void)
-{
- int i, fd;
- unsigned char j, si, dat[128];
-
- if ((fd = open("/dev/urandom", O_RDONLY)) < 0 && (fd = open("/dev/random", O_RDONLY)) < 0) {
- fprintf(stderr, "Fatal: no random number source available.\n");
- exit(3);
- }
- if (read_in_full(fd, dat, 128) != 128) {
- fprintf(stderr, "Fatal: cannot read random number source.\n");
- exit(3);
- }
- close(fd);
-
- for (i = 0; i < 256; i++)
- rs.s[i] = i;
- for (i = j = 0; i < 256; i++) {
- si = rs.s[i];
- j += si + dat[i & 127];
- rs.s[i] = rs.s[j];
- rs.s[j] = si;
- }
- rs.i = rs.j = 0;
-
- for (i = 0; i < 256; i++)
- arc4_getbyte();
-}
-
-static unsigned char arc4_getbyte(void)
-{
- unsigned char si, sj;
-
- rs.i++;
- si = rs.s[rs.i];
- rs.j += si;
- sj = rs.s[rs.j];
- rs.s[rs.i] = sj;
- rs.s[rs.j] = si;
- return rs.s[(si + sj) & 0xff];
-}
-
static struct imap_cmd *v_issue_imap_cmd(struct imap_store *ctx,
struct imap_cmd_cb *cb,
const char *fmt, va_list ap)
@@ -1198,88 +1149,20 @@ static int imap_make_flags(int flags, char *buf)
return d;
}
-#define TUIDL 8
-
-static int imap_store_msg(struct store *gctx, struct msg_data *data, int *uid)
+static int imap_store_msg(struct store *gctx, struct msg_data *data)
{
struct imap_store *ctx = (struct imap_store *)gctx;
struct imap *imap = ctx->imap;
struct imap_cmd_cb cb;
- char *fmap, *buf;
const char *prefix, *box;
- int ret, i, j, d, len, extra, nocr;
- int start, sbreak = 0, ebreak = 0;
- char flagstr[128], tuid[TUIDL * 2 + 1];
+ int ret, d;
+ char flagstr[128];
memset(&cb, 0, sizeof(cb));
- fmap = data->data;
- len = data->len;
- nocr = !data->crlf;
- extra = 0, i = 0;
- if (!CAP(UIDPLUS) && uid) {
- nloop:
- start = i;
- while (i < len)
- if (fmap[i++] == '\n') {
- extra += nocr;
- if (i - 2 + nocr == start) {
- sbreak = ebreak = i - 2 + nocr;
- goto mktid;
- }
- if (!memcmp(fmap + start, "X-TUID: ", 8)) {
- extra -= (ebreak = i) - (sbreak = start) + nocr;
- goto mktid;
- }
- goto nloop;
- }
- /* invalid message */
- free(fmap);
- return DRV_MSG_BAD;
- mktid:
- for (j = 0; j < TUIDL; j++)
- sprintf(tuid + j * 2, "%02x", arc4_getbyte());
- extra += 8 + TUIDL * 2 + 2;
- }
- if (nocr)
- for (; i < len; i++)
- if (fmap[i] == '\n')
- extra++;
-
- cb.dlen = len + extra;
- buf = cb.data = xmalloc(cb.dlen);
- i = 0;
- if (!CAP(UIDPLUS) && uid) {
- if (nocr) {
- for (; i < sbreak; i++)
- if (fmap[i] == '\n') {
- *buf++ = '\r';
- *buf++ = '\n';
- } else
- *buf++ = fmap[i];
- } else {
- memcpy(buf, fmap, sbreak);
- buf += sbreak;
- }
- memcpy(buf, "X-TUID: ", 8);
- buf += 8;
- memcpy(buf, tuid, TUIDL * 2);
- buf += TUIDL * 2;
- *buf++ = '\r';
- *buf++ = '\n';
- i = ebreak;
- }
- if (nocr) {
- for (; i < len; i++)
- if (fmap[i] == '\n') {
- *buf++ = '\r';
- *buf++ = '\n';
- } else
- *buf++ = fmap[i];
- } else
- memcpy(buf, fmap + i, len - i);
-
- free(fmap);
+ cb.dlen = data->len;
+ cb.data = xmalloc(cb.dlen);
+ memcpy(cb.data, data->data, data->len);
d = 0;
if (data->flags) {
@@ -1288,26 +1171,14 @@ static int imap_store_msg(struct store *gctx, struct msg_data *data, int *uid)
}
flagstr[d] = 0;
- if (!uid) {
- box = gctx->conf->trash;
- prefix = ctx->prefix;
- cb.create = 1;
- if (ctx->trashnc)
- imap->caps = imap->rcaps & ~(1 << LITERALPLUS);
- } else {
- box = gctx->name;
- prefix = !strcmp(box, "INBOX") ? "" : ctx->prefix;
- cb.create = 0;
- }
- cb.ctx = uid;
+ box = gctx->name;
+ prefix = !strcmp(box, "INBOX") ? "" : ctx->prefix;
+ cb.create = 0;
ret = imap_exec_m(ctx, &cb, "APPEND \"%s%s\" %s", prefix, box, flagstr);
imap->caps = imap->rcaps;
if (ret != DRV_OK)
return ret;
- if (!uid)
- ctx->trashnc = 0;
- else
- gctx->count++;
+ gctx->count++;
return DRV_OK;
}
@@ -1483,7 +1354,6 @@ int main(int argc, char **argv)
{
struct msg_data all_msgs, msg;
struct store *ctx = NULL;
- int uid = 0;
int ofs = 0;
int r;
int total, n = 0;
@@ -1491,9 +1361,6 @@ int main(int argc, char **argv)
git_extract_argv0_path(argv[0]);
- /* init the random number generator */
- arc4_init();
-
setup_git_directory_gently(&nongit_ok);
git_config(git_imap_config, NULL);
@@ -1540,7 +1407,7 @@ int main(int argc, char **argv)
break;
if (server.use_html)
wrap_in_html(&msg);
- r = imap_store_msg(ctx, &msg, &uid);
+ r = imap_store_msg(ctx, &msg);
if (r != DRV_OK)
break;
n++;
--
1.6.4.msysgit.0
^ permalink raw reply related
* [PATCH v5 5/8] imap-send: build imap-send on Windows
From: Erik Faye-Lund @ 2009-10-21 17:04 UTC (permalink / raw)
To: git; +Cc: msysgit, Erik Faye-Lund
In-Reply-To: <1256144691-2908-5-git-send-email-kusmabite@gmail.com>
Since the POSIX-specific tunneling code has been replaced
by the run-command API (and a compile-error has been
cleaned away), we can now enable imap-send on Windows
builds.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index fea237b..0d13af3 100644
--- a/Makefile
+++ b/Makefile
@@ -354,6 +354,7 @@ EXTRA_PROGRAMS =
PROGRAMS += $(EXTRA_PROGRAMS)
PROGRAMS += git-fast-import$X
PROGRAMS += git-hash-object$X
+PROGRAMS += git-imap-send$X
PROGRAMS += git-index-pack$X
PROGRAMS += git-merge-index$X
PROGRAMS += git-merge-tree$X
@@ -1075,7 +1076,6 @@ EXTLIBS += -lz
ifndef NO_POSIX_ONLY_PROGRAMS
PROGRAMS += git-daemon$X
- PROGRAMS += git-imap-send$X
endif
ifndef NO_OPENSSL
OPENSSL_LIBSSL = -lssl
--
1.6.4.msysgit.0
^ permalink raw reply related
* [PATCH v5 4/8] imap-send: fix compilation-error on Windows
From: Erik Faye-Lund @ 2009-10-21 17:04 UTC (permalink / raw)
To: git; +Cc: msysgit, Erik Faye-Lund
In-Reply-To: <1256144691-2908-4-git-send-email-kusmabite@gmail.com>
mmsystem.h (included from windows.h) defines DRV_OK to 1. To avoid
an error due to DRV_OK redefenition, this patch undefines the old
definition (i.e the one from mmsystem.h) before defining DRV_OK.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
imap-send.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/imap-send.c b/imap-send.c
index 72ed640..69e6142 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -94,6 +94,7 @@ struct msg_data {
unsigned int crlf:1;
};
+#undef DRV_OK
#define DRV_OK 0
#define DRV_MSG_BAD -1
#define DRV_BOX_BAD -2
--
1.6.4.msysgit.0
^ permalink raw reply related
* [PATCH v5 6/8] mingw: wrap SSL_set_(w|r)fd to call _get_osfhandle
From: Erik Faye-Lund @ 2009-10-21 17:04 UTC (permalink / raw)
To: git; +Cc: msysgit, Erik Faye-Lund
In-Reply-To: <1256144691-2908-6-git-send-email-kusmabite@gmail.com>
SSL_set_fd (and friends) expects a OS file handle on Windows, not
a file descriptor as on UNIX(-ish).
This patch makes the Windows version of SSL_set_fd behave like the
UNIX versions, by calling _get_osfhandle on it's input.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
compat/mingw.h | 21 +++++++++++++++++++++
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/compat/mingw.h b/compat/mingw.h
index 5b5258b..6907345 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -124,6 +124,27 @@ static inline int waitpid(pid_t pid, int *status, unsigned options)
return -1;
}
+#ifndef NO_OPENSSL
+#include <openssl/ssl.h>
+static inline int mingw_SSL_set_fd(SSL *ssl, int fd)
+{
+ return SSL_set_fd(ssl, _get_osfhandle(fd));
+}
+#define SSL_set_fd mingw_SSL_set_fd
+
+static inline int mingw_SSL_set_rfd(SSL *ssl, int fd)
+{
+ return SSL_set_rfd(ssl, _get_osfhandle(fd));
+}
+#define SSL_set_rfd mingw_SSL_set_rfd
+
+static inline int mingw_SSL_set_wfd(SSL *ssl, int fd)
+{
+ return SSL_set_wfd(ssl, _get_osfhandle(fd));
+}
+#define SSL_set_wfd mingw_SSL_set_wfd
+#endif
+
/*
* implementations of missing functions
*/
--
1.6.4.msysgit.0
^ permalink raw reply related
* [PATCH v5 8/8] MSVC: Enable OpenSSL, and translate -lcrypto
From: Erik Faye-Lund @ 2009-10-21 17:04 UTC (permalink / raw)
To: git; +Cc: msysgit, Marius Storm-Olsen, Erik Faye-Lund
In-Reply-To: <1256144691-2908-8-git-send-email-kusmabite@gmail.com>
From: Marius Storm-Olsen <mstormo@gmail.com>
We don't use crypto, but rather require libeay32 and
ssleay32. handle it in both the Makefile msvc linker
script, and the buildsystem generator.
Signed-off-by: Marius Storm-Olsen <mstormo@gmail.com>
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
Makefile | 2 +-
compat/vcbuild/scripts/clink.pl | 3 +++
contrib/buildsystems/engine.pl | 3 +++
3 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 986483b..1e1a2f2 100644
--- a/Makefile
+++ b/Makefile
@@ -900,7 +900,7 @@ ifdef MSVC
GIT_VERSION := $(GIT_VERSION).MSVC
pathsep = ;
NO_PREAD = YesPlease
- NO_OPENSSL = YesPlease
+ NEEDS_CRYPTO_WITH_SSL = YesPlease
NO_LIBGEN_H = YesPlease
NO_SYMLINK_HEAD = YesPlease
NO_IPV6 = YesPlease
diff --git a/compat/vcbuild/scripts/clink.pl b/compat/vcbuild/scripts/clink.pl
index f9528c0..8a2112f 100644
--- a/compat/vcbuild/scripts/clink.pl
+++ b/compat/vcbuild/scripts/clink.pl
@@ -29,6 +29,9 @@ while (@ARGV) {
push(@args, "zlib.lib");
} elsif ("$arg" eq "-liconv") {
push(@args, "iconv.lib");
+ } elsif ("$arg" eq "-lcrypto") {
+ push(@args, "libeay32.lib");
+ push(@args, "ssleay32.lib");
} elsif ("$arg" =~ /^-L/ && "$arg" ne "-LTCG") {
$arg =~ s/^-L/-LIBPATH:/;
push(@args, $arg);
diff --git a/contrib/buildsystems/engine.pl b/contrib/buildsystems/engine.pl
index 20bd061..d506717 100644
--- a/contrib/buildsystems/engine.pl
+++ b/contrib/buildsystems/engine.pl
@@ -315,6 +315,9 @@ sub handleLinkLine
$appout = shift @parts;
} elsif ("$part" eq "-lz") {
push(@libs, "zlib.lib");
+ } elsif ("$part" eq "-lcrypto") {
+ push(@libs, "libeay32.lib");
+ push(@libs, "ssleay32.lib");
} elsif ($part =~ /^-/) {
push(@lflags, $part);
} elsif ($part =~ /\.(a|lib)$/) {
--
1.6.4.msysgit.0
^ permalink raw reply related
* [PATCH v5 2/8] imap-send: use separate read and write fds
From: Erik Faye-Lund @ 2009-10-21 17:04 UTC (permalink / raw)
To: git; +Cc: msysgit, Erik Faye-Lund
In-Reply-To: <1256144691-2908-2-git-send-email-kusmabite@gmail.com>
This is a patch that enables us to use the run-command
API, which is supported on Windows.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
imap-send.c | 37 +++++++++++++++++++++++--------------
1 files changed, 23 insertions(+), 14 deletions(-)
diff --git a/imap-send.c b/imap-send.c
index 8da7a94..7216453 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -151,7 +151,7 @@ struct imap_list {
};
struct imap_socket {
- int fd;
+ int fd[2];
SSL *ssl;
};
@@ -301,8 +301,12 @@ static int ssl_socket_connect(struct imap_socket *sock, int use_tls_only, int ve
ssl_socket_perror("SSL_new");
return -1;
}
- if (!SSL_set_fd(sock->ssl, sock->fd)) {
- ssl_socket_perror("SSL_set_fd");
+ if (!SSL_set_rfd(sock->ssl, sock->fd[0])) {
+ ssl_socket_perror("SSL_set_rfd");
+ return -1;
+ }
+ if (!SSL_set_wfd(sock->ssl, sock->fd[1])) {
+ ssl_socket_perror("SSL_set_wfd");
return -1;
}
@@ -324,11 +328,12 @@ static int socket_read(struct imap_socket *sock, char *buf, int len)
n = SSL_read(sock->ssl, buf, len);
else
#endif
- n = xread(sock->fd, buf, len);
+ n = xread(sock->fd[0], buf, len);
if (n <= 0) {
socket_perror("read", sock, n);
- close(sock->fd);
- sock->fd = -1;
+ close(sock->fd[0]);
+ close(sock->fd[1]);
+ sock->fd[0] = sock->fd[1] = -1;
}
return n;
}
@@ -341,11 +346,12 @@ static int socket_write(struct imap_socket *sock, const char *buf, int len)
n = SSL_write(sock->ssl, buf, len);
else
#endif
- n = write_in_full(sock->fd, buf, len);
+ n = write_in_full(sock->fd[1], buf, len);
if (n != len) {
socket_perror("write", sock, n);
- close(sock->fd);
- sock->fd = -1;
+ close(sock->fd[0]);
+ close(sock->fd[1]);
+ sock->fd[0] = sock->fd[1] = -1;
}
return n;
}
@@ -358,7 +364,8 @@ static void socket_shutdown(struct imap_socket *sock)
SSL_free(sock->ssl);
}
#endif
- close(sock->fd);
+ close(sock->fd[0]);
+ close(sock->fd[1]);
}
/* simple line buffering */
@@ -911,7 +918,7 @@ static void imap_close_server(struct imap_store *ictx)
{
struct imap *imap = ictx->imap;
- if (imap->buf.sock.fd != -1) {
+ if (imap->buf.sock.fd[0] != -1) {
imap_exec(ictx, NULL, "LOGOUT");
socket_shutdown(&imap->buf.sock);
}
@@ -939,7 +946,7 @@ static struct store *imap_open_store(struct imap_server_conf *srvc)
ctx = xcalloc(sizeof(*ctx), 1);
ctx->imap = imap = xcalloc(sizeof(*imap), 1);
- imap->buf.sock.fd = -1;
+ imap->buf.sock.fd[0] = imap->buf.sock.fd[1] = -1;
imap->in_progress_append = &imap->in_progress;
/* open connection to IMAP server */
@@ -966,7 +973,8 @@ static struct store *imap_open_store(struct imap_server_conf *srvc)
close(a[0]);
- imap->buf.sock.fd = a[1];
+ imap->buf.sock.fd[0] = a[1];
+ imap->buf.sock.fd[1] = dup(a[1]);
imap_info("ok\n");
} else {
@@ -1043,7 +1051,8 @@ static struct store *imap_open_store(struct imap_server_conf *srvc)
goto bail;
}
- imap->buf.sock.fd = s;
+ imap->buf.sock.fd[0] = s;
+ imap->buf.sock.fd[1] = dup(s);
if (srvc->use_ssl &&
ssl_socket_connect(&imap->buf.sock, 0, srvc->ssl_verify)) {
--
1.6.4.msysgit.0
^ permalink raw reply related
* [PATCH v5 7/8] mingw: enable OpenSSL
From: Erik Faye-Lund @ 2009-10-21 17:04 UTC (permalink / raw)
To: git; +Cc: msysgit, Erik Faye-Lund
In-Reply-To: <1256144691-2908-7-git-send-email-kusmabite@gmail.com>
Since we have OpenSSL in msysgit now, enable it to support SSL
encryption for imap-send.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 0d13af3..986483b 100644
--- a/Makefile
+++ b/Makefile
@@ -952,7 +952,7 @@ else
ifneq (,$(findstring MINGW,$(uname_S)))
pathsep = ;
NO_PREAD = YesPlease
- NO_OPENSSL = YesPlease
+ NEEDS_CRYPTO_WITH_SSL = YesPlease
NO_LIBGEN_H = YesPlease
NO_SYMLINK_HEAD = YesPlease
NO_IPV6 = YesPlease
--
1.6.4.msysgit.0
^ permalink raw reply related
* [PATCH] Document the delta attribute
From: Nasser Grainawi @ 2009-10-21 17:11 UTC (permalink / raw)
To: Git Mailing List
After spending a bit of time searching through the pack-objects source
I figured a small blurb of text documenting the existence of this attribute
would be useful.
Feel free to enhance/improve/correct the text.
Nasser
Signed-off-by: Nasser Grainawi <nasser@codeaurora.org>
---
Documentation/gitattributes.txt | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index 1195e83..132e7b3 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -577,6 +577,16 @@ If this attribute is not set or has an invalid value, the
value of the
(See linkgit:git-config[1]).
+Packing objects
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+`delta`
+^^^^^^^^^^
+
+Delta compression will not be attempted for files and directories with
+the attribute `delta` unset.
+
+
USING ATTRIBUTE MACROS
----------------------
--
1.6.5
^ permalink raw reply related
* Re: [RFC] pull/fetch rename
From: Daniel Barkalow @ 2009-10-21 17:12 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Thomas Rast, git
In-Reply-To: <20091021115740.GA25049@atjola.homenet>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 12514 bytes --]
On Wed, 21 Oct 2009, Björn Steinbrink wrote:
> On 2009.10.21 00:22:18 -0400, Daniel Barkalow wrote:
> > On Wed, 21 Oct 2009, Björn Steinbrink wrote:
> >
> > > 3) User expects "pull" to update all branch heads that have a configured
> > > upstream
> > >
> > > 08:31 dimsuz hi guys! suppose i'm currently on master. then run git
> > > fetch. which delivers updates to master and other
> > > branches. I don't merge anything, but do checkout some
> > > branch (which is not master). Question: will these new
> > > updates get into this branch automatically after i check
> > > it out? question2: will branch master contain those
> > > updates when i ckeck it out later?
> > > 08:32 Circuitsoft dimsuz. After a fetch, no.
> > > 08:33 Circuitsoft However, if you pull, any branches that were set
> > > up as local tracking branches will get updated.
> > > 08:33 Circuitsoft Otherwise, only remote tracking branches will be
> > > updated.
> > >
> > > http://colabti.de/irclogger/irclogger_log/git?date=2009-10-20#l969
> > > (No idea about that one, have seen that once before, but it's definitely
> > > not even remotely as common as the others)
> >
> > I'd guess that's due to having local branches with no local changes, just
> > to avoid detached HEAD, and therefore thinking it's normal to have a bunch
> > of local branches that could be updated without merges. But I'm on a crazy
> > "everybody really wants detached HEAD and is needlessly scared" kick, and
> > I'm probably reading too much into it.
>
> Just to clarify: I didn't mean the question (which I didn't really
> understand) in this case, but the answer from Circuitsoft (second to
> last line). But maybe you also meant that? The question confuses me
> enough not to be able to follow.
Yeah. I think that Circuitsoft, and a lot of the people in these
conversations, have local branches they never commit to, and only update
with pull, and only use the --track feature to maintain these branches,
and may not even ever use "git pull" for anything other than to maintain
these branches. That would give the impression that "git pull" always
leaves the current branch holding the commit that the remote branch is
holding (i.e., "reset --hard") and the guess that this could apply to
non-current branches.
But these local branches don't actually give the users any benefit,
because they're always the same as the ref in remotes/ unless they're
out-of-date.
> > > 4) User expects "pull" to create branches
> > >
> > > 07:25 fynn Hey, I just pulled a branch from remote, and I don't see
> > > it in "git branch"
> > > 07:25 doener fynn: if you "pull" that means "fetch this and merge it
> > > to what I have checked out"
> > > 07:25 fynn doener: hm, I just did "git pull" and it showed the new
> > > branch
> > > 07:26 fynn but I don't see it in my branches...
> > > 07:26 fynn doener: should I create that branch as a tracking branch
> > > first?
> > > 07:26 doener fynn: you're looking at "git branch -r" or "git branch
> > > -a", right?
> > > 07:26 fynn doener: yeah, I'm seeing it in origin/foo, but not
> > > local.
> > > 07:26 doener fynn: the "git fetch" should have created a remote
> > > tracking branch, as usual, not a local branch head
> > > (which would be shown by just "git branch")
> > > 07:27 fynn doener: OK, what should I do to create it locally then?
> > > 07:28 doener fynn: just the usual "git branch foo origin/foo", or to
> > > checkout at the same time: "git checkout -b foo
> > > origin/foo" or "git checkout -t origin/foo" (shortcut)
> > >
> > > http://colabti.de/irclogger/irclogger_log/git?date=2009-10-19#l830
> > > (Note how my "fetch this and merge it" is actually inaccurate for just
> > > "git pull", there is no "this" and that case. I took "pulled a branch"
> > > to mean that he did "git pull <remote> <branch>", which wouldn't have
> > > created/update the remote tracking branch [or did patches for that go
> > > in? I lost track...])
> >
> > That sounds like a real converse of "push", including creating like-named
> > local branches. Or, perhaps, this is someone expecting that "pull" is like
> > "clone" in creating an initial local branch with the name and value of a
> > specified remote branch.
>
> Reading that one again, I realize that I've still been confused by the
> "pulled a branch". What happened was that the user did "git pull", which
> ran "git fetch <remote>", which fetched a new branch head and has shown
> that. At that point, the user (and me) got confused for maybe two reasons:
>
> a) He didn't clearly distinguish between the fetch and the merge part.
> The new branch wasn't pulled, but just fetched. That caused the user to
> think that he "pulled the branch" (wrong terminology), which in term
> confused me (wrong use-case assumed).
Right; when pull shows a branch, it's the fetching step. But I think that
shouldn't have been confusing to you; the merging step certainly doesn't
show anything interesting.
> b) He expected local branch heads to be created, instead of remote
> tracking branches. If my memory doesn't play tricks on me, that's
> actually not to be expected from that specific user (I think we told him
> about remote tracking branches before, and the last part of the
> conversation actually suggests that, too). If I don't forget, I'll try
> to get feedback from him the next time he's around.
He seems to get the thing about remote tracking branches (he says that got
created); he's fine on the "pull = fetch + (X)" portion, but he's got (X)
wrong, and thinks that creates a local branch.
That's why I think he may be confused by clone's behavior, because clone
does: (create a repo), fetch something, and create a co-named local
branch. If clone were init + pull (wrong, but a reasonable guess), then
clone - init = fetch + checkout -b; so I think he's not totally lost but
rather just wrong about what compound operations "pull" is.
> > > 5) User possibly expecting "pull" to be able to act as "reset --hard"
> > >
> > > 21:01 aidan What do I do about this: html/config/core.php: needs
> > > update
> > > 21:02 aidan git pull (gives that)
> > > 21:02 Ilari aidan: You have uncommitted changes to that file...
> > > 21:15 aidan Ilari: how can I just pull master and overwrite any
> > > changes?
> > >
> > > http://colabti.de/irclogger/irclogger_log/git?date=2009-10-18#l2130
> > > (I'm not sure about that one, "overwrite any changes" might mean "drop
> > > uncommitted changes and merge" or "just get me the remote's state,
> > > dropping my commits and uncommitted changes". Most of the time I've seen
> > > similar requests, the user wanted the latter).
> >
> > So I think that's a desire for "git checkout ." first of all (with the
> > assumption that the content without modifications has to come from
> > somewhere remote). I don't know what's up with people not wanting to save
> > their commits, though.
>
> You haven't seen the multitude of "I have merge conflicts and just want
> to take theirs/mine" requests. That often gets more weird than just
> "drop my commits" ;-)
Ah, okay; I tend to think of those as content-focused, rather than
history-focused. Like, I think people often run into: "I reformatted files
A and B and made important changes to file A; someone else made important
changes to file B; I get a awful merge conflict in file B." I bet it's
common to want to keep your commit history, but throw away their
conflicting changes in the resulting content.
There's also the occasional case where the right solution is to rename a
branch to "things-that-seemed-like-a-good-idea-at-the-time", create a new
branch from upstream with the old name, and never speak of it again.
But this is all a different topic.
> > > 6) User says "pull" but probably means "fetch"
> > >
> > > 14:08 Alien_Freak once I have a clone of a repo I know you can do
> > > a checkout tag but is there anyway to pull just
> > > the tag?
> > >
> > > http://colabti.de/irclogger/irclogger_log/git?date=2009-10-16#l1664
> > > (There was no answer, thus it's hard to tell, but I guess he wanted
> > > something like:
> > > git init; git fetch --no-tags url tag <tag>; git checkout <tag>
> > > At least I'm quite sure he didn't mean "pull" as in "git pull")
> >
> > I don't know; you can actually do:
> >
> > $ git init; git pull --no-tags <url> tag <tag>
> >
> > It updates the master branch and working directory from (nothing) to the
> > fetched tag.
>
> Hm, yeah, that works (didn't think of it), but it's a rather special
> case. Teaching that might lead to misunderstandings about what "pull"
> does, I think. It would look somewhat like "fetch + reset --hard".
Well, "merge" looks like "reset --hard" any time it's a fast forward.
I don't think this is a good thing to teach, but if the answer to what the
user wants to do when saying "How can I just pull a tag in a single
command" is "pull tag <foo>", it's hard to say that's a misuse of the
term.
> > > 8) "reset --hard" again
> > >
> > > 20:10 roger_padactor i commited then did a pull how do i get back to
> > > my commit. the pull over wrote the files
> > > 20:11 merlin83 roger_padactor: you can't, pull == fetch + hard
> > > reset to latest commit
> > >
> > > http://colabti.de/irclogger/irclogger_log/git?date=2009-10-14#l2306
> > > (Someone being told that pull is fetch + reset --hard is actually new to
> > > me. Only saw that as an expectation previously.)
> >
> > That's odd. How could you not notice that it doesn't actually do that,
> > even if you try to get it to?
>
> Hm? roger_padactor noticed that "pull" changed his files and wants to go
> back. And merlin83 says that that is impossible because pull supposedly
> does reset --hard. There's nothing in there (I could see) that suggests
> that anyone tried to make "pull" do "reset --hard".
I'm surprised that merlin83 can think that pull = fetch + reset --hard;
people often seem to try to do fetch + reset --hard with pull, but it
doesn't actually work for them.
> merlin83 basically made three mistakes, I think:
> 1) Assume that roger_padactor was talking about uncommitted changes
> 2) Assume that pull is fetch + reset --hard
> 3) Assume that you can't undo a reset --hard for committed changes
>
> (OK, 3) isn't actually valid when you consider 1), but 1) is so invalid
> that I kept 3). After all, "pull" would complain about a dirty tree...)
>
>
> > Actually, I wonder if the right formula is update = fetch + checkout.
> > There are a lot of people (IMHO) want "git fetch origin; git checkout
> > origin/master", and I think their first idea is "git update", but that
> > doesn't exist, and they find "pull" as the closest thing.
>
> That has a precondition that the user is already using a detached HEAD.
> Otherwise that fetch + checkout would likely mean that the get baffled
> when they do:
> git checkout master
> git update
> git checkout foo
> git checkout master
>
> Seeing that "master" is out of date "again".
Agreed; I think:
$ git checkout master
$ git update
You are on a local branch. Local branches are under your complete control,
so there is nowhere to get updates from. If you would like to merge remote
commits into your local branch, you could use "git pull". If you would
rather look at a remote branch, you could use "git checkout <some
plausible remote branch>".
Of course, without this message:
$ git checkout master
$ git update
would be the same as:
$ git chekcout master
$ git fetch
$ git checkout master
which would already not show any changes. (I'm thinking of the target of
the checkout in update-with-no-target as being whatever you typed last
time, and the fetch being whatever fetch normally updates that target.)
Personally, I often run:
$ git fetch; git checkout origin/next
This suggests that this is a useful combination of commands.
> I agree though, that users might look for "git update" and because it is
> missing, they just look for the closest thing. Adding Junio's statement
> that users seem to want recipes instead of flexibility (and seeing
> "update" as just "get me new stuff from upstream" without meaning any
> specific method of updating), I think that "git update" could be a "recipe
> collection" tool. I'll hack that into my proof-of-concept thing (which
> I hope to have ready for a RFC next week).
I'll be interested to see that.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [PATCH] modernize fetch/merge/pull examples
From: Clemens Buchacher @ 2009-10-21 17:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Björn Steinbrink, Daniel Barkalow, Thomas Rast, git
In-Reply-To: <7vk4ypb71j.fsf@alter.siamese.dyndns.org>
The "git pull" documentation has examples which follow an outdated
style. Update the examples to use "git merge" where appropriate and
move the examples to the corresponding manpages.
Furthermore,
o show that pull is equivalent to fetch and merge, which is still a
frequently asked question,
o explain the default fetch refspec.
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
---
On Tue, Oct 20, 2009 at 11:22:16PM -0700, Junio C Hamano wrote:
> For example, I am in favor of deprecating the "pull $there $src:$dst"
> notation.
A first step in that direction.
Clemens
Documentation/git-fetch.txt | 29 +++++++++++++++++++++++++
Documentation/git-merge.txt | 33 +++++++++++++++++++++++++++++
Documentation/git-pull.txt | 49 +++---------------------------------------
3 files changed, 66 insertions(+), 45 deletions(-)
diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt
index d3164c5..c76077d 100644
--- a/Documentation/git-fetch.txt
+++ b/Documentation/git-fetch.txt
@@ -37,6 +37,35 @@ include::pull-fetch-param.txt[]
include::urls-remotes.txt[]
+
+EXAMPLES
+--------
+
+* Update the remote-tracking branches:
++
+------------------------------------------------
+$ git fetch origin
+------------------------------------------------
++
+The above command copies all branches from the remote refs/heads/
+namespace and stores them to the local refs/remotes/origin/ namespace,
+unless the branch.<name>.fetch option is used to specify a non-default
+refspec.
+
+* Using refspecs explicitly:
++
+------------------------------------------------
+$ git fetch origin +pu:pu maint:tmp
+------------------------------------------------
++
+This updates (or creates, as necessary) branches `pu` and `tmp` in
+the local repository by fetching from the branches (respectively)
+`pu` and `maint` from the remote repository.
++
+The `pu` branch will be updated even if it is does not fast-forward;
+the others will not be.
+
+
SEE ALSO
--------
linkgit:git-pull[1]
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index d05f324..2a41d62 100644
--- a/Documentation/git-merge.txt
+++ b/Documentation/git-merge.txt
@@ -212,6 +212,39 @@ You can work through the conflict with a number of tools:
common ancestor, 'git show :2:filename' shows the HEAD
version and 'git show :3:filename' shows the remote version.
+
+EXAMPLES
+--------
+
+* Bundle branches `fixes` and `enhancements` on top of
+ the current branch, making an Octopus merge:
++
+------------------------------------------------
+$ git merge fixes enhancements
+------------------------------------------------
+
+* Merge branch `obsolete` into the current branch, using `ours`
+ merge strategy:
++
+------------------------------------------------
+$ git merge -s ours obsolete
+------------------------------------------------
+
+* Merge branch `maint` into the current branch, but do not make
+ a commit automatically:
++
+------------------------------------------------
+$ git merge --no-commit maint
+------------------------------------------------
++
+This can be used when you want to include further changes to the
+merge, or want to write your own merge commit message.
++
+You should refrain from abusing this option to sneak substantial
+changes into a merge commit. Small fixups like bumping
+release/version name would be acceptable.
+
+
SEE ALSO
--------
linkgit:git-fmt-merge-msg[1], linkgit:git-pull[1],
diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
index 7578623..de2bcd6 100644
--- a/Documentation/git-pull.txt
+++ b/Documentation/git-pull.txt
@@ -131,54 +131,13 @@ $ git pull origin next
------------------------------------------------
+
This leaves a copy of `next` temporarily in FETCH_HEAD, but
-does not update any remote-tracking branches.
-
-* Bundle local branch `fixes` and `enhancements` on top of
- the current branch, making an Octopus merge:
-+
-------------------------------------------------
-$ git pull . fixes enhancements
-------------------------------------------------
-+
-This `git pull .` syntax is equivalent to `git merge`.
-
-* Merge local branch `obsolete` into the current branch, using `ours`
- merge strategy:
-+
-------------------------------------------------
-$ git pull -s ours . obsolete
-------------------------------------------------
-
-* Merge local branch `maint` into the current branch, but do not make
- a commit automatically:
+does not update any remote-tracking branches. Using remote-tracking
+branches, the same can be done by invoking fetch and merge:
+
------------------------------------------------
-$ git pull --no-commit . maint
+$ git fetch origin
+$ git merge origin/next
------------------------------------------------
-+
-This can be used when you want to include further changes to the
-merge, or want to write your own merge commit message.
-+
-You should refrain from abusing this option to sneak substantial
-changes into a merge commit. Small fixups like bumping
-release/version name would be acceptable.
-
-* Command line pull of multiple branches from one repository:
-+
-------------------------------------------------
-$ git checkout master
-$ git fetch origin +pu:pu maint:tmp
-$ git pull . tmp
-------------------------------------------------
-+
-This updates (or creates, as necessary) branches `pu` and `tmp` in
-the local repository by fetching from the branches (respectively)
-`pu` and `maint` from the remote repository.
-+
-The `pu` branch will be updated even if it is does not fast-forward;
-the others will not be.
-+
-The final command then merges the newly fetched `tmp` into master.
If you tried a pull which resulted in a complex conflicts and
--
1.6.5.1
^ permalink raw reply related
* Re: [RFC] pull/fetch rename
From: Clemens Buchacher @ 2009-10-21 17:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Björn Steinbrink, Daniel Barkalow, Thomas Rast, git
In-Reply-To: <7vk4ypb71j.fsf@alter.siamese.dyndns.org>
On Tue, Oct 20, 2009 at 11:22:16PM -0700, Junio C Hamano wrote:
> For example, I am in favor of deprecating the "pull $there $src:$dst"
> notation. Before we standardized on the separate remote layout, it was
> sometimes handy to be able to use $dst that is a local branch, but these
> days, especially when repository $there has remote.$there.fetch mapping
> configured so that we can compute from $src what remote tracking branch we
> should store the fetched commit, the flexibility is more confusing than it
> is useful.
I emphatically agree. I was always uncomfortable with the refspec syntax,
because it is too flexible. Why would I ever want to access branch refs
other than refs/heads/ on the remote, and why would I ever want to write
directly to the local refs/heads/ namespace (in a non-bare repo), as opposed
to refs/remotes/<name>? Unless he wants to do something unusual, the user
should not be confronted with questions like that.
Clemens
^ permalink raw reply
* Re: [PATCH 3/3] git checkout --nodwim
From: Avery Pennarun @ 2009-10-21 17:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Riesen, git, Johannes Schindelin, Jay Soffian
In-Reply-To: <7v7huspjg0.fsf@alter.siamese.dyndns.org>
On Sun, Oct 18, 2009 at 3:53 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Alex Riesen <raa.lkml@gmail.com> writes:
>
>> On Sun, Oct 18, 2009 at 10:01, Junio C Hamano <gitster@pobox.com> wrote:
>>> + OPT_SET_INT(0, "nodwim", &dwim_new_local_branch,
>>> + "do not dwim local branch creation", 0),
>>
>> Isn't there a special negation support for --no-something in parse-options?
>
> There probably is, but this is a whetherbaloon patch without documentation
> and pretty much Porcelain only, so I took the lazy route.
>
> Helping hands in polishing it up is very welcome.
I find the idea of an option for "don't do what I mean" to be pretty
entertaining. Or maybe just misleading :)
Have fun,
Avery
^ permalink raw reply
* confusion with git diff-tree output
From: David Roundy @ 2009-10-21 17:43 UTC (permalink / raw)
To: git
Hi all,
I've been struggling with trying to figure out how to make diff-tree
output the actual files changed. Below is the output when I run
diff-tree on a given commit. It reports that the directory is
modified, rather than that a single file within that directory is
modified. I can find out what *file* was modified by running
diff-tree -p --raw, which gives me output similar to what I expected
from a plain old diff-tree. Is there a flag that will make diff-tree
give this information?
As background, what I really want is --name-only, which rarely reports
the files modified, instead reporting the directories as modified, and
I've been struggling to figure out what is going on. The
documentation seems to imply that the --raw diff output will report
modified files, and I haven't found anything indicating when it would
report the directories containing the modified files instead.
Thanks!
David
$ git diff-tree fd99a198222c14cf42fee82087a13467ff4a8205
fd99a198222c14cf42fee82087a13467ff4a8205
:040000 040000 8cdb796ea801da99c34d8f60045d8eb08fbb0e41
66b67ea1763799c0b2ac01f6803177ca870f6544 M Iolaus
$ git diff-tree fd99a198222c14cf42fee82087a13467ff4a8205 -p --raw
fd99a198222c14cf42fee82087a13467ff4a8205
:100644 100644 dab4c531f3f69f08e5dc202ad8b6dfad9e8855fe
0e3f305e641a6440bb478765dfcd089e0420c155 M Iolaus/Lcs2.hs
diff --git a/Iolaus/Lcs2.hs b/Iolaus/Lcs2.hs
index dab4c53..0e3f305 100644
--- a/Iolaus/Lcs2.hs
+++ b/Iolaus/Lcs2.hs
(changes cut)
^ permalink raw reply
* Re: confusion with git diff-tree output
From: Jan Krüger @ 2009-10-21 17:51 UTC (permalink / raw)
To: David Roundy; +Cc: git
In-Reply-To: <117f2cc80910211043q3a92a7b6o15464cc049ee33dc@mail.gmail.com>
> David Roundy <roundyd@physics.oregonstate.edu> wrote:
> I've been struggling with trying to figure out how to make diff-tree
> output the actual files changed. Below is the output when I run
> diff-tree on a given commit. It reports that the directory is
> modified, rather than that a single file within that directory is
> modified.
Tree objects are recursively nested, i.e.
> 66b67ea1763799c0b2ac01f6803177ca870f6544 M Iolaus
is a reference to another tree object... and since a file in that
subtree changed, a new tree object that contains a different file
record is now referenced as "Iolaus".
By default git diff-tree doesn't recurse, but you can use -r for that.
Which is documented, I might add. ;)
Jan
^ 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