* Re: basic question about push
From: Jeff King @ 2010-01-25 11:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Russ Paielli, git
In-Reply-To: <7vzl43723t.fsf@alter.siamese.dyndns.org>
On Sun, Jan 24, 2010 at 11:08:06AM -0800, Junio C Hamano wrote:
> > http://git.wiki.kernel.org/index.php/GitFaq#push-is-reverse-of-fetch
>
> I saw somebody referred to this entry and refused to study the entry
> immediately after seeing the word "firewalled", saying "my environment is
> not firewalled", without trying to judge if the description applies to his
> case. This was understandable; the workflow will apply in non-firewalled
> case just as well, even though "firewalled" case may be the easiest to see
> why it is recommended.
>
> Perhaps the title of the entry needs to be rewritten to clarify that this
> is not _limited_ to a firewalled situation?
I agree, and just tweaked the title and text a bit. After doing that, I
realized that you had already done so a few hours ago, too. :) So
between the two of us, hopefully it is better.
-Peff
^ permalink raw reply
* Re: [PATCH] Handle UNC paths everywhere
From: Robin Rosenberg @ 2010-01-25 11:01 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: kusmabite, git, Johannes Sixt, Junio C Hamano,
Johannes Schindelin
In-Reply-To: <fabb9a1e1001250222n6912905fqfd2e76f8d4496bb7@mail.gmail.com>
måndagen den 25 januari 2010 11.22.19 skrev Sverre Rabbelier:
> Heya,
>
> On Mon, Jan 25, 2010 at 11:11, Erik Faye-Lund <kusmabite@googlemail.com>
wrote:
> > C:\Users\kusma>dir \\mongo\code
> > The request is not supported.
> >
> > C:\Users\kusma>explorer \\mongo\code
> > <login on the gui>
> >
> > C:\Users\kusma>dir \\mongo\code
> > Volume in drive \\mongo\code is Code
> > Volume Serial Number is 04C3-0225
>
> Ah, that's very interesting. Not sure that will help MSysGit a lot though.
>
Could you perhaps *try* it before claiming it won't work? I suggest you
use forward slashes to avoid quoting problems.
-- robin
^ permalink raw reply
* Re: git status showing phantom modifications
From: Tay Ray Chuan @ 2010-01-25 11:03 UTC (permalink / raw)
To: Michael Ludwig; +Cc: git@vger.kernel.org
In-Reply-To: <9B3C1167-7667-4B1F-BEE5-F47FE89F8692@xing.com>
Hi,
On Mon, Jan 25, 2010 at 6:41 PM, Michael Ludwig <michael.ludwig@xing.com> wrote:
> michael@wladimir:/cygdrive/m/REPOS6.TECH.git/comp :-) git st
> # On branch master
> # Changed but not updated:
> # (use "git add <file>..." to update what will be committed)
> # (use "git checkout -- <file>..." to discard changes in working directory)
> #
> # modified: mw/wsdl-version.txt
> # modified: net/httpsrvr/iis6.wodo
> # ... and about 100 more of that ...
try running git diff. I suspect the changes are to filemodes. What
does your git config look like regarding this (particularly
core.fileMode)?
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: [PATCH] Handle UNC paths everywhere
From: Sverre Rabbelier @ 2010-01-25 11:06 UTC (permalink / raw)
To: Robin Rosenberg
Cc: kusmabite, git, Johannes Sixt, Junio C Hamano,
Johannes Schindelin
In-Reply-To: <201001251201.23064.robin.rosenberg@dewire.com>
Heya,
On Mon, Jan 25, 2010 at 12:01, Robin Rosenberg
<robin.rosenberg@dewire.com> wrote:
>> Ah, that's very interesting. Not sure that will help MSysGit a lot though.
>>
>
> Could you perhaps *try* it before claiming it won't work? I suggest you
> use forward slashes to avoid quoting problems.
Actually, I can't, cos I don't have a MSysGit build environment, I'm
just saying that in the environment I tested it in, I didn't have to
log in, so I suspect that it won't work, I'm not claiming anything.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: basic question about push
From: Jeff King @ 2010-01-25 11:08 UTC (permalink / raw)
To: Jay Soffian; +Cc: Russ Paielli, git, Junio C Hamano
In-Reply-To: <76718491001241559u103d2e8j38687b41bd5401a1@mail.gmail.com>
On Sun, Jan 24, 2010 at 06:59:10PM -0500, Jay Soffian wrote:
> > http://git.wiki.kernel.org/index.php/GitFaq#push-is-reverse-of-fetch
>
> Aside, and I think we've discussed this before, but I wonder if it
> would make sense to:
>
> a) Add an option to clone such as "-p [<name>] | --push-as[=<name>]"
> where <name> defaults to $(uname -n | cut -f1 -d.) This would setup
> the cloned repo with a push refspec
> "+refs/heads/*:refs/remotes/<name>/*". e.g.:
>
> $ git clone -o host1 -p host2 ssh://host1/~/repo.git
> $ cat repo/.git/config
> ...
> [remote "host1"]
> url = ssh://host1/~/repo.git
> fetch = +refs/heads/*:refs/remotes/host1/*
> push = +refs/heads/*:refs/remotes/host2/*
One problem with this scheme is that it actually does two things:
1. Tells git to push into the refs/remotes/host2/ hierarchy instead of
refs/heads/.
2. Overrides matching behavior to push all heads.
Point (2) is less of a problem than it is without (1) in the sense that
you are pushing to a unique namespace, so you don't have to worry as
much about your crappy half-finished branches filling up the main branch
namespace. But you might not want them publicized at all, either because
they are embarrassingly bad or simply because it is cruft that you will
encounter later and wonder "is this branch, which is missing from my
local repositor (presumably from a long-ago deletion) but present
upstream of any value at all?"
I can't think offhand of a way to get the behavior of (1) without (2).
I know we have a shorthand refspec for "matching", but this would not
strictly be matching. It is "convert refs/heads/X into
refs/remotes/blah/X, and _then_ match".
If we had a refspec that worked in that manner, I would think it's a
pretty good idea (even to turn it on by default for non-bare repos).
> b) The controversial part: make this option the default the default
> when cloning from a non-bare repo. There would need to be some way to
> turn it off.
Hmm. Do we reliably know from the client side whether a remote is bare
or not?
> Of course, I'm not sure this would be any less confusing for users.
> Would they wonder why they have to merge to see their pushed changes
> reflected on the pushed-to repo?
Yes, I think we would still have the FAQ of "I pushed my changes, where
did they go?" but at least the answer would be "git merge foo" and not
"what you are doing is confusing to git and you need to figure out what
kind of workflow you want, redo your push, and then git merge foo".
Which seems like an improvement to me. ;)
-Peff
^ permalink raw reply
* Re: [PATCH] Handle UNC paths everywhere
From: Erik Faye-Lund @ 2010-01-25 11:17 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Robin Rosenberg, git, Johannes Sixt, Junio C Hamano,
Johannes Schindelin
In-Reply-To: <fabb9a1e1001250306l2b9aba53s6a884b618a80063b@mail.gmail.com>
On Mon, Jan 25, 2010 at 12:06 PM, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> Heya,
>
> On Mon, Jan 25, 2010 at 12:01, Robin Rosenberg
> <robin.rosenberg@dewire.com> wrote:
>>> Ah, that's very interesting. Not sure that will help MSysGit a lot though.
>>>
>>
>> Could you perhaps *try* it before claiming it won't work? I suggest you
>> use forward slashes to avoid quoting problems.
>
> Actually, I can't, cos I don't have a MSysGit build environment, I'm
> just saying that in the environment I tested it in, I didn't have to
> log in, so I suspect that it won't work, I'm not claiming anything.
>
For shares that doesn't require login, I can list files without doing
anything. Remember that Windows might try some saved password in the
background when you open the folder in explorer, so not seeing a
password-prompt might not be the same thing as the share not needing
login.
Perhaps "net use \\mongo\code" would have been a better example than
using explorer? I don't have the setup where I am right now to test
that it does what I expect it to, though.
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* Re: [RFC PATCH 10/10] gitweb: Show appropriate "Generating..." page when regenerating cache (WIP)
From: Jakub Narebski @ 2010-01-25 11:46 UTC (permalink / raw)
To: Petr Baudis
Cc: git, John 'Warthog9' Hawley,
John 'Warthog9' Hawley
In-Reply-To: <20100124222417.GC9553@machine.or.cz>
On Sun, 24 Jan 2010, Petr Baudis wrote:
> I have stupid question, common to both the original patch and this
> RFC.
>
> > [RFC PATCH 10/10] gitweb: Show appropriate "Generating..." page when
> > regenerating cache (WIP)
>
> Just why is a "Generating..." page appropriate?
>
> I have to admit I hate it; can you please at least make it
> configurable? Why is it needed at all? It [...] confuses
> non-interactive HTTP clients [...]
First, if I understand the code correctly HTTP clients which do not
honor metaredirect (http-equiv refresh) would get page which looks
the following
<html>
Generating...
</html>
<html>
Gitweb page
</html>
Second, gitweb can always check User-Agent header, and serve
"Generating..." page only to web browsers:
unless (defined $cgi->user_agent() &&
$cgi->user_agent() =~ /\b(Mozilla|Opera)\b/i) {
return;
}
or something like that.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: git status showing phantom modifications
From: Michael Ludwig @ 2010-01-25 11:43 UTC (permalink / raw)
To: git@vger.kernel.org
In-Reply-To: <be6fef0d1001250303p2c12381ao7d3a8a1d48eebb56@mail.gmail.com>
Am 25.01.2010 um 12:03 schrieb Tay Ray Chuan:
> On Mon, Jan 25, 2010 at 6:41 PM, Michael Ludwig <michael.ludwig@xing.com> wrote:
>> michael@wladimir:/cygdrive/m/REPOS6.TECH.git/comp :-) git st
>> # On branch master
>> # Changed but not updated:
>> # (use "git add <file>..." to update what will be committed)
>> # (use "git checkout -- <file>..." to discard changes in working directory)
>> #
>> # modified: mw/wsdl-version.txt
>> # modified: net/httpsrvr/iis6.wodo
>> # ... and about 100 more of that ...
>
> try running git diff. I suspect the changes are to filemodes. What
> does your git config look like regarding this (particularly
> core.fileMode)?
Running git diff informed me there were no changes to content, which is
what I forgot to add to the description of the problem.
Unfortunately, right now I'm not at the system where this occurred, so
I can't say what git config looks like. I did not, however, make any
customization other than user.email and alias.st and some others.
Reading up about core.fileMode in git-config(1), I think you've pointed
me to the solution. I should probably just set it to false. If that doesn't
solve the issue, I'll report back.
Google also found me an old patch that might be related to the problem:
[PATCH] Force core.filemode to false on Cygwin.
http://marc.info/?l=git&m=116754085018507&w=2
--
Michael.Ludwig (#) XING.com
^ permalink raw reply
* [PATCH] git_connect: use use_shell instead of explicit "sh", "-c"
From: Johannes Sixt @ 2010-01-25 12:32 UTC (permalink / raw)
To: Jeff King; +Cc: Git Mailing List
From: Johannes Sixt <j6t@kdbg.org>
This is a followup to ac0ba18 (run-command: convert simple callsites to
use_shell, 2009-12-30), for consistency.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
Jeff,
is there a reason that this was not part of the original patch?
-- Hannes
connect.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/connect.c b/connect.c
index db965c9..3a12562 100644
--- a/connect.c
+++ b/connect.c
@@ -613,8 +613,7 @@ struct child_process *git_connect(int fd[2], const
char *url_orig,
NULL
};
conn->env = env;
- *arg++ = "sh";
- *arg++ = "-c";
+ conn->use_shell = 1;
}
*arg++ = cmd.buf;
*arg = NULL;
--
1.7.0.rc0.39.g31c5d
^ permalink raw reply related
* Re: [PATCH] git_connect: use use_shell instead of explicit "sh", "-c"
From: Jeff King @ 2010-01-25 13:01 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Git Mailing List
In-Reply-To: <4B5D8F6C.1040407@viscovery.net>
On Mon, Jan 25, 2010 at 01:32:44PM +0100, Johannes Sixt wrote:
> This is a followup to ac0ba18 (run-command: convert simple callsites to
> use_shell, 2009-12-30), for consistency.
>
> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
> ---
> Jeff,
>
> is there a reason that this was not part of the original patch?
No, I must have just missed it (I don't remember omitting it for a
particular reason at the time, and after looking at it now, it looks
sane to me).
After this, git grep '"sh"' turns up only two uses: one in the
run-command code use_shell code path, and the other in builtin-help.c.
The one in builtin-help is hard to change, as it relies on direct exec
instead of run-command.
-Peff
^ permalink raw reply
* Re: [RFC PATCH 10/10] gitweb: Show appropriate "Generating..." page when regenerating cache (WIP)
From: Petr Baudis @ 2010-01-25 13:02 UTC (permalink / raw)
To: Jakub Narebski
Cc: git, John 'Warthog9' Hawley,
John 'Warthog9' Hawley
In-Reply-To: <201001251246.40237.jnareb@gmail.com>
On Mon, Jan 25, 2010 at 12:46:39PM +0100, Jakub Narebski wrote:
> On Sun, 24 Jan 2010, Petr Baudis wrote:
> > I have stupid question, common to both the original patch and this
> > RFC.
> >
> > > [RFC PATCH 10/10] gitweb: Show appropriate "Generating..." page when
> > > regenerating cache (WIP)
> >
> > Just why is a "Generating..." page appropriate?
> >
> > I have to admit I hate it; can you please at least make it
> > configurable? Why is it needed at all? It [...] confuses
> > non-interactive HTTP clients [...]
>
> First, if I understand the code correctly HTTP clients which do not
> honor metaredirect (http-equiv refresh) would get page which looks
> the following
>
> <html>
> Generating...
> </html>
> <html>
> Gitweb page
> </html>
To be clear, I conjectured it confuses non-interactive HTTP clients from
one of the TODOs in your patch series - I'm not sure about it myself. :)
> Second, gitweb can always check User-Agent header, and serve
> "Generating..." page only to web browsers:
>
> unless (defined $cgi->user_agent() &&
> $cgi->user_agent() =~ /\b(Mozilla|Opera)\b/i) {
> return;
> }
>
> or something like that.
I'm not too happy with this. What about Safari? Opera? ELinks? There's a
lot of web browsers.
Most of the issues can be worked around, but I'm not sure why to go
through all the trouble. I just personally don't see the value in having
the placeholder in there at all, to me it is distracting UI even if all
the technicalities are put aside.
But if it will be possible to turn this off eventually, it's all your
call whether to bother implementing it. :-)
--
Petr "Pasky" Baudis
A lot of people have my books on their bookshelves.
That's the problem, they need to read them. -- Don Knuth
^ permalink raw reply
* [PATCH 2/2] filter-branch: Add tests for submodules
From: Michal Sojka @ 2010-01-25 13:06 UTC (permalink / raw)
To: git; +Cc: Johannes.Schindelin, Michal Sojka
In-Reply-To: <1264424786-26231-1-git-send-email-sojkam1@fel.cvut.cz>
The test 'rewrite submodule with another content' passes only with the
previous patch.
Signed-off-by: Michal Sojka <sojkam1@fel.cvut.cz>
---
t/t7003-filter-branch.sh | 26 ++++++++++++++++++++++++++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/t/t7003-filter-branch.sh b/t/t7003-filter-branch.sh
index 9503875..39d4153 100755
--- a/t/t7003-filter-branch.sh
+++ b/t/t7003-filter-branch.sh
@@ -306,4 +306,30 @@ test_expect_success '--remap-to-ancestor with filename filters' '
test $orig_invariant = $(git rev-parse invariant)
'
+test_expect_success 'setup submodule' '
+ rm -rf * .*
+ git init &&
+ test_commit file &&
+ mkdir submod &&
+ submodurl="$PWD/submod"
+ ( cd submod &&
+ git init &&
+ test_commit file-in-submod ) &&
+ git submodule add "$submodurl"
+ git commit -m "added submodule" &&
+ test_commit add-file &&
+ ( cd submod && test_commit add-in-submodule ) &&
+ git add submod &&
+ git commit -m "changed submodule"
+'
+
+test_expect_success 'rewrite submodule with another content' '
+ git filter-branch --tree-filter "test -d submod && {
+ rm -rf submod &&
+ git rm -rf --quiet submod &&
+ mkdir submod &&
+ : > submod/file
+ } || :"
+'
+
test_done
--
1.6.6
^ permalink raw reply related
* filter-branch fix and tests
From: Michal Sojka @ 2010-01-25 13:06 UTC (permalink / raw)
To: git; +Cc: Johannes.Schindelin
Hi,
this is resend of the patch I sent two weeks ago. I've extended the commit
message to address Johannes' question and in the second patch I've added tests
for the fix.
Michal
^ permalink raw reply
* [PATCH 1/2] filter-branch: Fix to allow replacing submodules with another content
From: Michal Sojka @ 2010-01-25 13:06 UTC (permalink / raw)
To: git; +Cc: Johannes.Schindelin, Michal Sojka
In-Reply-To: <1264424786-26231-1-git-send-email-sojkam1@fel.cvut.cz>
When git filter-branch is used to replace a submodule with another
content, it always fails on the first commit. Consider a repository with
submod directory containing a submodule. If I want to remove the
submodule and replace it with a file, the following command fails.
git filter-branch --tree-filter 'rm -rf submod &&
git rm -q submod &&
mkdir submod &&
touch submod/file'
The error message is:
error: submod: is a directory - add files inside instead
The reason is that git diff-index, which generates the first part of the
list of files updated by the tree filter, emits also the removed
submodule even if it was replaced by a real directory.
Adding --ignored-submodules solves the problem for me and
tests in t7003-filter-branch.sh pass correctly.
If somebody wants to replace one revision of the module with another, it
can be done with --index-filter. Using --tree-filter for this has no
sense since --tree-filter "git submodule update --init" fails with
Clone of '/tmp/submod' into submodule path 'submod' failed
so that the revision must be replaced only in index.
Signed-off-by: Michal Sojka <sojkam1@fel.cvut.cz>
---
git-filter-branch.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index 195b5ef..d4ac7fb 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -331,7 +331,7 @@ while read commit parents; do
die "tree filter failed: $filter_tree"
(
- git diff-index -r --name-only $commit &&
+ git diff-index -r --name-only --ignore-submodules $commit &&
git ls-files --others
) > "$tempdir"/tree-state || exit
git update-index --add --replace --remove --stdin \
--
1.6.6
^ permalink raw reply related
* Re: [RFC PATCH 10/10] gitweb: Show appropriate "Generating..." page when regenerating cache (WIP)
From: Jakub Narebski @ 2010-01-25 13:48 UTC (permalink / raw)
To: Petr Baudis
Cc: git, John 'Warthog9' Hawley,
John 'Warthog9' Hawley
In-Reply-To: <20100125130230.GE9553@machine.or.cz>
On Mon, Jan 25, 2010, Petr Baudis wrote:
> On Mon, Jan 25, 2010 at 12:46:39PM +0100, Jakub Narebski wrote:
>> On Sun, 24 Jan 2010, Petr Baudis wrote:
>>> I have stupid question, common to both the original patch and this
>>> RFC.
>>>
>>>> [RFC PATCH 10/10] gitweb: Show appropriate "Generating..." page when
>>>> regenerating cache (WIP)
>>>
>>> Just why is a "Generating..." page appropriate?
>>>
>>> I have to admit I hate it; can you please at least make it
>>> configurable? Why is it needed at all? It [...] confuses
>>> non-interactive HTTP clients [...]
>> Second, gitweb can always check User-Agent header, and serve
>> "Generating..." page only to web browsers:
>>
>> unless (defined $cgi->user_agent() &&
>> $cgi->user_agent() =~ /\b(Mozilla|Opera)\b/i) {
>> return;
>> }
>>
>> or something like that.
>
> I'm not too happy with this. What about Safari? Opera? ELinks? There's a
> lot of web browsers.
The "Mozilla" part would catch all "Mozilla compatibile" web browsers,
including Firefox (and other Gecko-based web browsers), Internet Explorer,
WebKit based browsers including Safari and Chrome and Konqueror.
The "Opera" part would catch Opera.
http://www.nczonline.net/blog/2010/01/12/history-of-the-user-agent-string/
As to other web browsers like Elinks, Lynx, w3m, Dillo, etc.: the issue
is whether they honor '<meta http-equiv="refresh" content="0" />'.
I think it is better to stay on the safe side; it is not disaster if web
browser is not shown "Generating..." page where it could (but see
explanation below).
> Most of the issues can be worked around, but I'm not sure why to go
> through all the trouble. I just personally don't see the value in having
> the placeholder in there at all, to me it is distracting UI even if all
> the technicalities are put aside.
The issue that "Generating..." page tries to solve is, I think, the
following.
Some actions, like 'blame' view or pickaxe search, or grep search,
can take quite a long time to generate, with times counted in
tens of seconds. It is not that visible for non-caching, because
gitweb streams output so we have at least _some_ output upfront quite
fast.
Now those patches (mine and J.H. both) make gitweb use locking
(it is IIRC configurable in J.H. patch) to make only one process
generate the page if it is missing from cache, or is stale. Now
if it is missing, we have to wait until it is generated in full
before being able to show it to client. While it is possible to
"tee" output (using PerlIO::tee, or Capture::Tiny, or tie like
CGI::Cache) writing it simultaneously to browser and to cache for
the process that is generating data, it is as far as I understand
it impossible for processes which are waiting for data. Therefore
the need for "Generating..." page, so the user does not think that
web server hung or something, and is not generating output.
We can try to reduce occurrences of cache miss stampedes by using
'expires_variance' feature[1] from CHI - Unified caching interface.
We can also turn off locking and tee output to have some output upfront
as an activity indicator instead of this "Generating..." page.
[1]: http://search.cpan.org/~jswartz/CHI-0.33/lib/CHI.pm#set
> But if it will be possible to turn this off eventually, it's all your
> call whether to bother implementing it. :-)
In my implementation it is (or rather would be) as simple as just
not passing 'generating_info' => \&git_generating_data_html in the
GitwebCache::SimpleFileCache constructor.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [RFC PATCH 10/10] gitweb: Show appropriate "Generating..." page when regenerating cache (WIP)
From: Petr Baudis @ 2010-01-25 13:56 UTC (permalink / raw)
To: Jakub Narebski
Cc: git, John 'Warthog9' Hawley,
John 'Warthog9' Hawley
In-Reply-To: <201001251448.27513.jnareb@gmail.com>
On Mon, Jan 25, 2010 at 02:48:26PM +0100, Jakub Narebski wrote:
> Now those patches (mine and J.H. both) make gitweb use locking
> (it is IIRC configurable in J.H. patch) to make only one process
> generate the page if it is missing from cache, or is stale. Now
> if it is missing, we have to wait until it is generated in full
> before being able to show it to client. While it is possible to
> "tee" output (using PerlIO::tee, or Capture::Tiny, or tie like
> CGI::Cache) writing it simultaneously to browser and to cache for
> the process that is generating data, it is as far as I understand
> it impossible for processes which are waiting for data. Therefore
> the need for "Generating..." page, so the user does not think that
> web server hung or something, and is not generating output.
Ah, ok, so the message is there to cover up for a technical problem. ;-)
I didn't quite realize. Then, it would be great to tweak the mechanisms
so that the user does not really have to wait.
So, I wonder about two things:
(i) How often does it happen that two requests for the same page are
received? Has anyone measured it? Or is at least able to make
a minimally educated guess? IOW, isn't this premature optimization?
(ii) Can't the locked gitwebs do the equivalent of tail -f?
P.S.: Again the disclaimer - if this is "too hard", it's better to
accept patches like they are, then improve this later. But perhaps
a better solution would be not to clutter the code by optimizing this
case at all if it's not clear it really matters in the real world.
Petr "Pasky" Baudis
^ permalink raw reply
* Re: [PATCH] rebase -p: Preserve fast-forwardable merges
From: Johannes Schindelin @ 2010-01-25 14:10 UTC (permalink / raw)
To: Alex Scarborough; +Cc: git, Junio C Hamano, Michael Haggerty
In-Reply-To: <dd10f5481001222329i58e7b709m2c547c74161b6771@mail.gmail.com>
Hi,
On Fri, 22 Jan 2010, Alex Scarborough wrote:
> Previously, rebase -p would not preserve a merge commit if the merge
> could be resolved as a fast-forward. rebase -p now passes --no-ff to
> git merge when recreating a merge commit, which ensures that merge
> commits created with git merge --no-ff are preserved.
For my use case (well, it used to be my use case), namely keeping a number
of topic branches on top of an upstream up-to-date, this is not the
desired action. In my use case, merged topic branches should just vanish,
and not even leave a merge commit.
> First patch, so here's hoping neither I nor my mail client messed up
> too much.
I think you did real fine, even providing a test case, which not many
submitters do!
Ciao,
Dscho
^ permalink raw reply
* Re: Modern Git GUI
From: Johannes Schindelin @ 2010-01-25 14:25 UTC (permalink / raw)
To: Matthieu Moy; +Cc: André Harms, git
In-Reply-To: <vpq636resro.fsf@bauges.imag.fr>
Hi,
On Sun, 24 Jan 2010, Matthieu Moy wrote:
> If you decide to go on with your project, either you want to carry it
> out alone, or you'll have to convince other developers to join. In the
> second case, a good starting point would be to explain why the other GUI
> are not good enough, and why you can't just contribute to them.
Actually, a much better way would be to be positive, not negative. I.e.
to show something you did, which hopefully entices others to use your
project (and maybe contribute to it).
Ciao,
Dscho
^ permalink raw reply
* Re: Modern Git GUI
From: John Tapsell @ 2010-01-25 14:30 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.DEB.1.00.1001251524190.8733@intel-tinevez-2-302>
2010/1/25 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> Hi,
>
> On Sun, 24 Jan 2010, Matthieu Moy wrote:
>
>> If you decide to go on with your project, either you want to carry it
>> out alone, or you'll have to convince other developers to join. In the
>> second case, a good starting point would be to explain why the other GUI
>> are not good enough, and why you can't just contribute to them.
>
> Actually, a much better way would be to be positive, not negative. I.e.
> to show something you did, which hopefully entices others to use your
> project (and maybe contribute to it).
Actually in this case, I don't think that would be good enough. My
first thought would be "why didn't he just add this feature to an
existing GUI rather than reinventing the wheel yet again". So there
would really have to be good reasons why the other GUIs aren't a good
enough starting point
^ permalink raw reply
* Re: [PATCH] git-gui: use different icon for new and modified files in the index
From: Shawn O. Pearce @ 2010-01-25 15:35 UTC (permalink / raw)
To: Peter Oberndorfer; +Cc: Git Mailing List
In-Reply-To: <201001241954.19626.kumbayo84@arcor.de>
Peter Oberndorfer <kumbayo84@arcor.de> wrote:
> This allows to quickly differentiate between new and modified files
> in the index without selecting the file and looking at the diff.
>
> Signed-off-by: Peter Oberndorfer <kumbayo84@arcor.de>
Thanks.
> While creating the patch i found out that file_parttick seems to be unused.
Yup, it is unused. Thanks for noticing, I removed it.
--
Shawn.
^ permalink raw reply
* [PATCH] Add test-run-command to .gitignore
From: Alejandro Riveira Fernández @ 2010-01-25 15:56 UTC (permalink / raw)
To: git
Add test-run-command to .gitignore so it does not pollute
git status output.
Signof-of-by: Alejandro Riveira Fernández <ariveira@gmail.com>
diff --git a/.gitignore b/.gitignore
index 83cf1b7..8df8f88 100644
--- a/.gitignore
+++ b/.gitignore
@@ -166,6 +166,7 @@
/test-match-trees
/test-parse-options
/test-path-utils
+/test-run-command
/test-sha1
/test-sigchain
/common-cmds.h
^ permalink raw reply related
* Re: [PATCH] t5541-http-push: make grep expression check for one line only
From: Junio C Hamano @ 2010-01-25 17:47 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: git, Junio C Hamano
In-Reply-To: <1264405343-2984-1-git-send-email-rctay89@gmail.com>
Tay Ray Chuan <rctay89@gmail.com> writes:
> Simplify the grep expressions in the non-fast-forward tests to check
> only for the first line of the non-fast-forward warning - having that
> line should be enough assurance that the full warning is printed.
>
> In the first place, grep can't deal with expressions for multiple
> lines.
This shows that nobody has ever run this test since January 8th, not even
the original author?
Hmmm.
Thanks.
>
> Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
> ---
> t/t5541-http-push.sh | 12 ++++--------
> 1 files changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/t/t5541-http-push.sh b/t/t5541-http-push.sh
> index 83a8e14..53f54a2 100755
> --- a/t/t5541-http-push.sh
> +++ b/t/t5541-http-push.sh
> @@ -105,10 +105,8 @@ test_expect_success 'non-fast-forward push show ref status' '
> '
>
> test_expect_success 'non-fast-forward push shows help message' '
> - grep \
> -"To prevent you from losing history, non-fast-forward updates were rejected
> -Merge the remote changes before pushing again. See the '"'non-fast-forward'"'
> -section of '"'git push --help'"' for details." output
> + grep "To prevent you from losing history, non-fast-forward updates were rejected" \
> + output
> '
>
> test_expect_success 'push fails for non-fast-forward refs unmatched by remote helper' '
> @@ -126,10 +124,8 @@ test_expect_success 'push fails for non-fast-forward refs unmatched by remote he
> grep "^ + [a-f0-9]*\.\.\.[a-f0-9]* *master -> master (forced update)$" output &&
> grep "^ ! \[rejected\] *master -> retsam (non-fast-forward)$" output &&
>
> - grep \
> -"To prevent you from losing history, non-fast-forward updates were rejected
> -Merge the remote changes before pushing again. See the '"'non-fast-forward'"'
> -section of '"'git push --help'"' for details." output
> + grep "To prevent you from losing history, non-fast-forward updates were rejected" \
> + output
> '
>
> stop_httpd
> --
> 1.6.6
^ permalink raw reply
* Re: [PATCH] t5541-http-push: make grep expression check for one line only
From: Junio C Hamano @ 2010-01-25 17:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Tay Ray Chuan, git
In-Reply-To: <7v7hr63wm7.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Tay Ray Chuan <rctay89@gmail.com> writes:
>
>> Simplify the grep expressions in the non-fast-forward tests to check
>> only for the first line of the non-fast-forward warning - having that
>> line should be enough assurance that the full warning is printed.
>>
>> In the first place, grep can't deal with expressions for multiple
>> lines.
>
> This shows that nobody has ever run this test since January 8th, not even
> the original author?
>
> Hmmm.
Actually, if you grep with a pattern with multiple lines, it is equivalent
to giving each of these lines as a separate pattern from the command line.
So it is understandable that the tests passed. They were checking if
these match, but it doesn't check (and grep is not designed to) if the
first pattern matched the first line, the second to second, etc.
So I'd say something like...
Don't feed multiple-line pattern to grep and expect them to match with
lines in order.
Simplify the grep expressions in the non-fast-forward tests to check
only for the first line of the non-fast-forward warning - having that
line should be enough assurance that the full warning is printed.
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
instead.
^ permalink raw reply
* Re: [PATCH] Handle UNC paths everywhere
From: Johannes Schindelin @ 2010-01-25 17:34 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git, Johannes Sixt, Junio C Hamano
In-Reply-To: <201001250155.47664.robin.rosenberg@dewire.com>
Hi,
On Mon, 25 Jan 2010, Robin Rosenberg wrote:
> >From 37a74ccd395d91e5662665ca49d7f4ec49811de0 Mon Sep 17 00:00:00 2001
> From: Robin Rosenberg <robin.rosenberg@dewire.com>
> Date: Mon, 25 Jan 2010 01:41:03 +0100
> Subject: [PATCH] Handle UNC paths everywhere
>
> In Windows paths beginning with // are knows as UNC paths. They are
> absolute paths, usually referring to a shared resource on a server.
And even a simple "cd" with them does not work.
> Examples of legal UNC paths
>
> \\hub\repos\repo
> \\?\unc\hub\repos
> \\?\d:\repo
>
> Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
> ---
> cache.h | 2 +-
> compat/basename.c | 2 +-
> compat/mingw.h | 8 +++++++-
> connect.c | 2 +-
> git-compat-util.h | 9 +++++++++
> path.c | 2 +-
> setup.c | 2 +-
> sha1_file.c | 20 ++++++++++++++++++++
> transport.c | 2 +-
> 9 files changed, 42 insertions(+), 7 deletions(-)
Ouch. You should know better than to clutter non-Windows-specific parts
with that ugly kludge.
> diff --git a/cache.h b/cache.h
> index 767a50e..8f63640 100644
> --- a/cache.h
> +++ b/cache.h
> @@ -648,7 +648,7 @@ int safe_create_leading_directories_const(const char
> *path);
> char *enter_repo(char *path, int strict);
> static inline int is_absolute_path(const char *path)
> {
> - return path[0] == '/' || has_dos_drive_prefix(path);
> + return path[0] == '/' || has_win32_abs_prefix(path);
Why? We can still keep the name. Well, maybe not, see below.
> diff --git a/compat/mingw.h b/compat/mingw.h
> index 1b528da..d1aa8be 100644
> --- a/compat/mingw.h
> +++ b/compat/mingw.h
> @@ -210,7 +210,13 @@ int winansi_fprintf(FILE *stream, const char *format,
> ...) __attribute__((format
> * git specific compatibility
> */
>
> -#define has_dos_drive_prefix(path) (isalpha(*(path)) && (path)[1] == ':')
> +#define has_dos_drive_prefix(path) \
> + (isalpha(*(path)) && (path)[1] == ':')
Why?
> +#define has_unc_prefix(path) \
> + (is_dir_sep((path)[0]) && is_dir_sep((path)[1]))
> +#define has_win32_abs_prefix(path) \
> + (has_dos_drive_prefix(path) || has_unc_prefix(path))
"c:hello.txt" is not an absolute path.
> diff --git a/connect.c b/connect.c
> index 7945e38..9d4556c 100644
> --- a/connect.c
> +++ b/connect.c
> @@ -535,7 +535,7 @@ struct child_process *git_connect(int fd[2], const char
> *url_orig,
> end = host;
>
> path = strchr(end, c);
> - if (path && !has_dos_drive_prefix(end)) {
> + if (path && !has_win32_abs_prefix(end)) {
> if (c == ':') {
Why? Do we really have to exclude UNC paths from that ":" handling?
> diff --git a/git-compat-util.h b/git-compat-util.h
> index ef60803..0de9dac 100644
> --- a/git-compat-util.h
> +++ b/git-compat-util.h
> @@ -170,6 +170,15 @@ extern char *gitbasename(char *);
> #define has_dos_drive_prefix(path) 0
> #endif
>
> +#ifndef has_unc_prefix
> +#define has_unc_prefix(path) 0
> +#endif
> +
> +#ifndef has_win32_abs_prefix
> +#error no abs
Yeah, sure. I do have abs, thank you very much.
In general, I am _very_ worried about your patch. It does not acknowledge
that there is a fundamental difference between DOS drive prefixes and UNC
paths, and not being able to "cd" to the latter is just a symptom.
I am also not quite sure if you can get away with having the same offset
for both: if I have "C:\blah" and strip off "C:", I always have a
directory separator to bounce against, whereas I do not have that if I
strip off the two "\\" of a UNC path. Besides, I maintain that the host
name, and maybe even the share name, should not ever be stripped off!
At least a discussion is missing from the commit message.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Handle UNC paths everywhere
From: Erik Faye-Lund @ 2010-01-25 17:57 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Robin Rosenberg, git, Johannes Sixt, Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.1001251553150.8733@intel-tinevez-2-302>
On Mon, Jan 25, 2010 at 6:34 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Mon, 25 Jan 2010, Robin Rosenberg wrote:
>
>> >From 37a74ccd395d91e5662665ca49d7f4ec49811de0 Mon Sep 17 00:00:00 2001
>> From: Robin Rosenberg <robin.rosenberg@dewire.com>
>> Date: Mon, 25 Jan 2010 01:41:03 +0100
>> Subject: [PATCH] Handle UNC paths everywhere
>>
>> In Windows paths beginning with // are knows as UNC paths. They are
>> absolute paths, usually referring to a shared resource on a server.
>
> And even a simple "cd" with them does not work.
>
But it does, at least for me - both in bash and cmd.exe. I just need
to log on to the server first, unless it's a public share.
--
Erik "kusma" Faye-Lund
^ 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