After cloning a local repository with "git clone file://...", the resulting repo had one big pack file, as expected, but also a matching ".keep" file. Certainly this is a bug, isn't it? The same happens if I clone git.git. I used git 1.5.6.1 but observed the same with the current master. I bisected this behavior to commit fa740529 by Shawn O. Pearce (CC'ing him). Since this dates back to 2007, I wonder if maybe only I am seeing this, but I cannot think of any reason for it. (I already mention...

On some setups, apache will say: apache2: Could not reliably determine the server's fully qualified domain name, using $(IP_address) for ServerName Avoid this message polluting tests output by setting a ServerName in apache configuration. --- t/lib-httpd/apache.conf | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/t/lib-httpd/apache.conf b/t/lib-httpd/apache.conf index a447346..4717c2d 100644 --- a/t/lib-httpd/apache.conf +++ b/t/lib-httpd/apache.conf @@ -1,3 +1,4 @@ ...

When USE_CURL_MULTI is undefined, git http-push doesn't work, so it's useless to test it. --- I wasted too much time wondering why the 3rd and 4th tests were failing before realizing I was building against an ancient libcurl, thus having a non working git http-push. This would avoid other people to do the same. t/t5540-http-push.sh | 7 +++++++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/t/t5540-http-push.sh b/t/t5540-http-push.sh index 6cd8b45..147ff98 100755 --- a/...

Actually, the 3rd is failing too, but fails to report an error because git push returns no error code in cases where it says: No refs in common and none specified; doing nothing. Mike --

git http-push doesn't handle packed-refs, and now the new builtin-clone created packed refs, the http-push test fails. Mark the current failure as such, and also catch third test's failure that went unreported because git push doesn't return an error code when it says: No refs in common and none specified; doing nothing. Which it does when http-push can't get a list of refs recursively from $URL/refs/. Signed-off-by: Mike Hommey <mh@glandium.org> --- Feel free to squash this in the p...

Not very easily, and that is very deliberate. The objects fetched will become dangling if you allowed such a mode of operation, and will immediately become subject to gc. As Avery said, when the user asks "what's the status" in the superproject, "the superproject binds a commit you do not have locally at these paths" is a perfectly valid answer, and as Dscho argues, it is not good to avoid giving that answer by running fetch behind the user's back. And the thing is, if you do the "without upda...

Yes. After "git fetch $random_place master && git log ..FETCH_HEAD" to inspect what the other guy is up to, if you do not like what you see, you do want the objects that are only reachable from FETCH_HEAD to go away (note that it is not counted as the root of fsck traversal for this exact reason). --

Hi, (I don't subscribe to this list, so please copy me in on replies) Mac OS X 10.5.4, Git 1.5.6.2 I use FileVault for my home directory: my files are stored on an encrypted disk image which is mounted on my home (/Users/jonathon). When I run "sudo make install", perllocal.pod gets written to: /Users/jonathon/System/Library/Perl/5.8.8/darwin-thread-multi-2level/ perllocal.pod under my home directory instead of at the root of the drive. Presumably this is because it's writing to /Syst...

I haven't checked to see if none of the callers of start_command() assumes the current behaviour and is printing this information itself instead, but other than that, your justification feels very sensible. --

Hi, So what about <<<<<<< This hunk contains ===== anythin ======= Hello ======= somethin else >>>>>>> problem! If you fix it, I think you should do it properly, and analyze the index. Ciao, Dscho --

If I read the code correctly, this case is not a problem at all because what is important is the content between <<< and >>> : even if you match the wrong === marker, you will match the first one only, then parsing will success and preimage file will be OK. Also because we always match in the same order the sha1 will be the same. Anyway, I do not know how to match the right === marker. Olivier. --

If you have a better fix send a patch or at least give me some clues. Olivier. --

--- imap-send.c | 631 ++++++++++++++++++++++++++++------------------------------- 1 files changed, 301 insertions(+), 330 deletions(-) diff --git a/imap-send.c b/imap-send.c index d138726..59ef4eb 100644 --- a/imap-send.c +++ b/imap-send.c @@ -102,14 +102,14 @@ typedef struct { static int Verbose, Quiet; -static void imap_info( const char *, ... ); -static void imap_warn( const char *, ... ); +static void imap_info(const char *, ...); +static void imap_warn(const char *, ...); -stat...

How do you propose I fix this? I attached the patch last time to avoid the problem of line wrapping. -- Rob Shearman --

Allow SSL to be used when a imaps:// URL is used for the host name. Also, automatically use TLS when not using imaps:// by using the IMAP STARTTLS command, if the server supports it. Tested with Courier and Gimap IMAP servers. --- Documentation/git-imap-send.txt | 5 +- Makefile | 4 +- imap-send.c | 166 +++++++++++++++++++++++++++++++++++---- 3 files changed, 157 insertions(+), 18 deletions(-) diff --git a/Documentation/git-imap-send.txt b/...

Hmm, it makes "rebase -i" different, too. Luckily, I haven't pushed anything out, so I can rewind and all I lose is just a few dozens of minutes. The one from Brian has another serious issue. That patch does not allow you to refer to ORIG_HEAD during conflict resolution, which is quite different from how "merge" lets you use ORIG_HEAD. We need to set ORIG_HEAD upfront if we want to tell user that ORIG_HEAD can be reliably used across workflows the same way to name where we were before. When...

Yeah, I was scratching my head about the discrepancy between the revision comment and the patch in the previous one. Having said that, thanks to updates to git-rebase, rebased_branch@{1} has useful information these days, so I do not see much practical upside, even though I _will_ apply this patch, just for the sake of consistency. We would make it _appear_ rebase and merge are interchangeable even more. But the thing is, I am not convinced if promoting that appearance is necessarily a good thi...

And in both cases, you could use HEAD@{1} instead of ORIG_HEAD. Mike --

No you cannot. Read what I wrote again. I never said HEAD@{1} ;-) --

The idea behind ORIG_HEAD is to have an anchoring point before an operation that moves your HEAD in a drastic way. Think if it as a poor-man's reflog -- in fact it predates reflog. That is why reset saves away the HEAD before it does its thing, so that you can easily say "Oops, I did not mean it -- reset ORIG_HEAD" to flip back to the previous state. Both a fast-forward merge and a real merge can be undone by resetting back to ORIG_HEAD. So in that sense: (1) ORIG_HEAD is not strictly nec...

I'm not sure if the last part is improvement, and it wouldn't be better to say rather than r1..r2 / ^r1 r2 are "commits that are reachable from r2, excluding those commits which are reachable from r1" (which translates into set difference / subtracting set of commits. -- Jakub Narebski Poland ShadeHawk on #git --

I understand, and the replacement you proposed is better, as it does not require understanding of [mathematical] set operations. I just think that "commits that are reachable from r2, excluding those commits which are reachable from r1" could be better than "commits that are reachable from r2 but not from r1". -- Jakub Narebski Poland --

You can inspect HEAD's reflog for individual steps, or the branch's reflog for the aggregated moves (try rebasing a few patches on 'test' branch and $ git log -g HEAD@{now} $ git log -g test@{now} Please don't complain that interface to specify timestamp output is dirty to me -- I share the same feeling, and it was not my invention. But at least it works ;-) --

You can always use _branch_ reflog, either in the <branch>@{1} form, or in @{1} shortcut form. @{1} should be equovalent to ORIG_HEAD even for rebase. -- Jakub Narebski Poland ShadeHawk on #git --

Perhaps something like this for "git am" (only minimally tested). -- >8 -- am: record ORIG_HEAD so that we can quickly undo a large series This teaches "git-am" to record the commit before it starts its work in ORIG_HEAD, so that application of a large series can be undone by resetting to it. Signed-off-by: Junio C Hamano <gitster@pobox.com> --- git-am.sh | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/git-am.sh b/git-am.sh index 2c517ed..818b4e5 100755...