* Re: [PATCHv2] git-mv: Keep moved index entries inact
From: Johannes Schindelin @ 2008-07-28 18:24 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: Junio C Hamano, Petr Baudis, git
In-Reply-To: <alpine.DEB.1.00.0807281610270.8986@racer>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2110 bytes --]
Hi,
On Mon, 28 Jul 2008, Johannes Schindelin wrote:
> On Mon, 28 Jul 2008, Johannes Schindelin wrote:
>
> > On Mon, 28 Jul 2008, SZEDER Gábor wrote:
> >
> > > there is a race somewhere in these 'git-mv: Keep moved index entries
> > > inact' changes.
> > >
> > > The test cases 'git mv should overwrite symlink to a file' or 'git
> > > mv should overwrite file with a symlink' fail occasionaly. It's
> > > quite non-deterministic: I have run t7001-mv.sh in a loop (see
> > > below) and one or the other usually fails around 50 runs (but
> > > sometimes only after 150). Adding some tracing echos to the tests
> > > shows that both tests fail when running 'git diff-files' at the end.
> >
> > To make it more convenient to test: with this patch it fails all the
> > time:
>
> Ooops. Seems like I changed the test 23 to fail, instead of test 24.
> However, I think it is the same bug: the index is newer by one second,
> so it seems that the patch for builtin-mv.c did not really keep the data
> "intact".
>
> Note that a test case should use test-chmtime to force this scenario,
> not sleep a second.
>
> Unfortunately, I already spent my Git time budget for today, so the ball
> is out of my half for now.
Hah! I had a few minutes, and this is my analysis:
Just try to "mv" a file, and look at the _ctime_ before and after. Yes,
that is right, at least on my system (ext3) it _changes_.
So the test 23 and 24 in t7001-mv.sh are totally bogus. They purport to
test that git-mv retains the whole meta-information in the cache and
therefore the index does not need to be updated.
However, it _does_ need to be updated, exactly because ctime changed.
Only that the test failed to test what it tried to test, instead
succeeding erroneously, just because the index was racy most of the time
and got silently updated.
So, this is the analysis. The fixes will have to be done by somebody
else, because /me goes running now.
(Possible fixes I envisage: update ctime via stat() after rename(), or
just give up and scrap the whole "leave cache_entry inact" thing.)
Ciao,
Dscho
^ permalink raw reply
* Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy
From: Miklos Vajna @ 2008-07-28 18:14 UTC (permalink / raw)
To: sverre; +Cc: Git Mailinglist, Johannes Schindelin
In-Reply-To: <bd6139dc0807280754x76b6ffedg6bf756dfce23f1e3@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 448 bytes --]
On Mon, Jul 28, 2008 at 04:54:17PM +0200, Sverre Rabbelier <alturin@gmail.com> wrote:
> So, in short: what does the list think about adding
> "git-merge-theirs", that does (although possibly less 'hackish'):
>
> cat > git-merge-theirs << EOF
> #!/bin/sh
> eval git read-tree --reset -u \\\$\$#
> EOF
Isn't this the stupid one?
It's perfect for my testing needs, but this is not something that people
should ever use on a real repo.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: git-scm.com
From: Tom Werner @ 2008-07-28 18:12 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.DEB.1.00.0807281201350.2725@eeepc-johanness>
On Mon, Jul 28, 2008 at 3:50 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> On Sun, 27 Jul 2008, Tom Werner wrote:
>> I find it a bit confusing that some here seem to have a strong dislike
>> for GitHub. It's true that we haven't been active on the developer list
>> or in the #git channel on freenode, but we are constantly in #github and
>> have answered a *great* many questions from developers that are new to
>> git.
>
> Speaking for myself, I will probably direct some users from #git to
> #github, then.
>
> The deeper reasoning: if you really do help by that channel, by all means
> I want to provide you with the opportunity to do so.
By all means! The users might be a bit confused about why you're
sending them to #github, but we're happy to help them out if you don't
care to. We actually employ a support person to man the channel and
help out where he can.
>> Perhaps it is the commercial aspect of GitHub that offends.
>
> In my opinion you can be as commercial as you want. Nevertheless, I would
> like to see some direct benefit for me, too, for obvious reasons. That
> does not need to be money; like Junio said, watching out for user
> questions on the Git list would already be very useful, in two respects:
>
> - the core developers have more time for hacking on Git itself (which
> would be good both for the developers as well as for you),
Using this same logic, it follows that we GitHub developers would be
better suited to hacking on GitHub (which would be good for the git
community). There are only so many hours in the day. I've had many a
GitHub user tell me that the GitHub interface and functionality helped
them finally understand git and feel comfortable switching to it from
SVN or CVS. It seems we can help bigger populations of git users by
making the site as clear and easy to use as possible, so that is what
we choose to do.
> - if your advices can be enhanced (such as my gripe that "git show" is not
> even so much as mentioned, in spite of being _the_ porcelain to inspect
> objects in Git's object database, not cat-file, whose only role in
> tutorials can be to shoo new users away) it will be early, which again
> is a win-win situation for both core developers as well as for you, and
Can you clarify what you are referring to here? I'm not sure I understand.
> - just as in the past, I fully expect the main thrust of the major changes
> in Git to be driven by user experience (just think of Git 1.5.0), and by
> driving users away (and indeed, by driving yourself away, a bunch of
> power-users), you would make that much more unlikely to happen in the
> future. So, having you closer to the Git mailing list and #git would
> again be a win-win situation.
I totally agree with the direction that 1.5 has taken git. You guys
are doing an awesome job with user experience. As I come across
usability problems I'll be sure to bring them up here in the future.
>> Having had to implement a git-daemon replacement that fit our needs, I
>> have some ideas on how to improve git-daemon and fetch-pack with
>> regards to error messages and logging.
>
> I might mention here that I think you are committing one of the biggest
> sins in Open Source: you do not reap the full power of the community.
>
> I am sure, if you would have mentioned your needs first, possibly followed
> by an early version of a patch, git-daemon would already be enhanced to
> your liking, and these enhancements would be available to everyone
> (including me, for example). But maybe that being available to everyone
> is not in the best interest of a commercial outfit?
The problem is that I'm only a casual C coder. It takes me a while to
figure out what's going on in the git source. We needed a way to serve
public git repositories from a hashed directory structure (e.g.
/a/b/c/user/repo.git) and we needed it fast. In a few days worth of
coding Erlang, I was able to meet that need (and also add logging and
better error messages returned to the client). If I had, as you
suggest, created a badly written patch and asked for help on the list,
I'd probably still be trying to solve the problem. It's dubious that
anyone other than us currently needs to satisfy the hashed directory
requirement, and as such I would not assume or expect that anyone
would be motivated to spend a bunch of time helping a C amateur
satisfy that need. In the end I was responsible for making it work,
and I did that the best and most efficient way I knew how.
Like I said before, I'm happy to share my suggestions for better error
messages and logging behavior, but I'm probably not going to be much
help with providing patches.
>> We like to design from first principles, see how good we can do, and
>> then get feedback from the users.
>
> Maybe this is so contrary to Open Source that many are uncomfortable with
> it.
>
> Also note that one of the major gripe with you making money off of Git
> could be the following: we have over 500 contributors, and most of them --
> first and foremost of all, the two major contributors, Junio and Shawn --
> cannot make money from Git. Envy is wrong, but it is real.
This is clearly false and does not do Junio or Shawn justice. It's not
hard to imagine that these two (or any of the other contributors)
could make money doing training for git at companies that have adopted
it, or as consultants to firms that use git in novel ways, or as
authors of git books. Scott Chacon gets paid right now to work on
tools that use git as an underlying file system. In fact, by helping
bring corporate interest to git, GitHub is paving the way for more and
more people to make money from git if they so choose. I wouldn't be
surprised if, down the road, Junio could be paid to hack on git full
time via corporate sponsorship. The continuing advancement of git is
of interest to a great many people. Some of which would gladly pay for
it.
Tom Preston-Werner
github.com/mojombo
^ permalink raw reply
* Re: short log and email address
From: Mark Brown @ 2008-07-28 18:11 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910807281106y56f8b67ao86f78822c4b4ad58@mail.gmail.com>
On Mon, Jul 28, 2008 at 02:06:06PM -0400, Jon Smirl wrote:
> Using the -e option in shortlog changes the results by spitting things
> out by email address instead of leaving them combined by name. That's
> probably not what you want. Instead you want everything combined by
> name and then display the most recent email address used.
Apart from anything else you're assuming that people's names are
globally unique - they aren't. I'm aware of several Mark Browns active
in the free software world, for example.
--
"You grabbed my hand and we fell into it, like a daydream - or a fever."
^ permalink raw reply
* short log and email address
From: Jon Smirl @ 2008-07-28 18:06 UTC (permalink / raw)
To: Git Mailing List
Using the -e option in shortlog changes the results by spitting things
out by email address instead of leaving them combined by name. That's
probably not what you want. Instead you want everything combined by
name and then display the most recent email address used.
Is there some way to fix this for the future? Maybe use Reply-to:
instead of From: on email import?
998 David S. Miller <davem@sunset.davemloft.net>
689 David S. Miller <davem@davemloft.net>
6 David S. Miller <davem@huronp11.davemloft.net>
5 David S. Miller <davem@hutch.davemloft.net>
4 David S. Miller <davem@bnsf.davemloft.net>
2 David S. Miller <davem@t1000.davemloft.net>
2 David S. Miller <davem@ultra5.davemloft.net>
1 David S. Miller <davem@goma.davemloft.net>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH] Optional grouping of projects by category.
From: Sébastien Cevey @ 2008-07-28 18:03 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3zlo3u2r2.fsf@localhost.localdomain>
At Sun, 27 Jul 2008 01:53:43 -0700 (PDT), Jakub Narebski wrote:
> Thanks a lot. I don't know if it is a good time, with git being in
> feature freeze, and GSoC project about adding caching to gitweb in
> the works, but I'll take this patch and resend it if needed. I'll
> try to comment on it soon.
Great, looking forward to that, thanks!
--
Sébastien Cevey / inso.cc
^ permalink raw reply
* [StGIT] Not working on Windows with msysgit.
From: Jurko Gospodnetić @ 2008-07-28 17:29 UTC (permalink / raw)
To: git
Hi.
I believe StGIT fails to work on Windows with msysgit installed
because of the way it runs its external executables. It assumes that the
executable is available on the path and is named exactly 'git'.
This however is not the case on Windows with msysgit installed. There
the 'git executable' is a batch script named git.cmd and stgit fails to
find it causing all git calls to return an error code.
Popen() calls in StGIT's run.py module seem to run their executables
(git & gitk only as far as I saw from the sources) directly instead of
running them through the shell in order to have the shell try all the
default extensions (configured on Windows using the PATHEXT environment
variable).
One 'fix' that corrects this in all the use cases on Windows that I
tried is to add the shell=True parameter to all Popen() calls in StGIT's
run.py module (one in __run_io() and one in __run_noio()). This would
however require more testing as I do not know how this would affect
other OSs or whether there might be some problems with how Windows's
default cmd shell handles quoting in the executed command lines. I do
recall Python having some serious problems with these quoting in
executed commands... something about external quotes getting stripped in
some cases... I might be able to dig up a workaround from somewhere if
needed...
I'm using Windows XP SP3 and my git/StGIT/Python version information is:
> Stacked GIT 0.14.3
> git version 1.5.6.1.1071.g76fb
> Python version 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)]
Anyone using StGIT on Windows with sysgit?
The place where I originally detected this problem is that StGIT
fails to read the stgit.editor configuration option with
Windows/msysgit. I think it got so far though only because I also had
cygwin git a bit later on the path.
Best regards,
Jurko Gospodnetić
^ permalink raw reply
* [StGit] StGit documentation on its configuration file usage.
From: Jurko Gospodnetić @ 2008-07-28 17:01 UTC (permalink / raw)
To: git
Hi.
StGIT's project page links to the
http://wiki.procode.org/cgi-bin/wiki.cgi/StGIT_Tutorial page for its
tutorial information.
There the 'Configuration file' notes state that StGIT uses
/etc/stgitrc, ~/.stgitrc and then .git/stgitrc configuration files in
that order and that there is an example configuration file under the
examples folder. However, grepping through the StGIT sources I found no
references to the stgitrc file but only wrappers for using the native
GIT configuration system. Also, looking at the examples folder I found
only an example that seems to indicate that StGIT's configuration
options should be integrated with other regular GIT configuration options.
Did I miss something? Or is this wiki information outdated?
Testing this I see that StGIT does not read the git configuration
correctly on Windows with msysgit anyway, but that's a story for a
different thread.
Best regards,
Jurko Gospodnetić
^ permalink raw reply
* Importing patches from email, which address?
From: Jon Smirl @ 2008-07-28 16:59 UTC (permalink / raw)
To: Git Mailing List
When working with the list of author emails for the kernel, I noticed
that a lot of the author's email address are from internal mail
servers. How is the handled in git (stgit, etc..)? Is the import using
the email From:, would it be better to use Reply-to:?
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: gitk crashing on Windows.
From: Eric Raible @ 2008-07-28 16:29 UTC (permalink / raw)
To: git
In-Reply-To: <g6kmqf$q9p$1@ger.gmane.org>
Jurko Gospodnetić <jurko.gospodnetic <at> docte.hr> writes:
>
> Hi.
>
> When you run gitk from a git repository on Windows it starts up and
> starts updating its 'Row X/Y' output labels. This lasts for a few
> seconds but if you terminate the application before this updating is
> complete you get a Windows message stating:
>
> 'Wish Application has encountered a problem and needs to close. We
> are sorry for the inconvenience.'
>
> and the standard 'Send Error Report'/'Don't Send' buttons.
>
> Hope this helps.
>
> Best regards,
> Jurko Gospodnetić
Though I can't find the relevant commit at the moment
I believe that this is one already fixed in the latest
from git://repo.or.cz/git/mingw/4msysgit.git.
- Eric
^ permalink raw reply
* Re: git submodules
From: Pierre Habouzit @ 2008-07-28 16:23 UTC (permalink / raw)
To: Git ML
In-Reply-To: <20080728162003.GA4584@artemis.madism.org>
[-- Attachment #1: Type: text/plain, Size: 749 bytes --]
On Mon, Jul 28, 2008 at 04:20:03PM +0000, Pierre Habouzit wrote:
> It also has the absolutely nice property to share objects, so that
> projects that replaced a subdirectory with a submodule don't see their
> checkouts grow too large.
Especially it "fixes" git-new-workdir, which becomes really
inefficient (storage and typing-wise) when submodules are in use, since
it doesn't share git_dir's for the submodules (this could also be hacked
together, but again, it's so much more convenient if we have only _one_
git_dir per repository that ... oh well)
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Make use of stat.ctime configurable
From: Petr Baudis @ 2008-07-28 16:20 UTC (permalink / raw)
To: Alex Riesen
Cc: Junio C Hamano, Johannes Schindelin, Linus Torvalds,
Johannes Sixt, git
In-Reply-To: <20080728063128.GA4234@blimp.local>
On Mon, Jul 28, 2008 at 08:31:28AM +0200, Alex Riesen wrote:
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index 1a13abc..552c134 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -149,6 +149,13 @@ core.safecrlf::
> `core.autocrlf`, git will reject the file. The variable can
> be set to "warn", in which case git will only warn about an
> irreversible conversion but continue the operation.
> +
> +core.trustctime::
> + If false, the ctime differences between the index and the
> + working copy are ignored; useful when the inode change time
> + is regularly modified by something outside Git (file system
> + crawlers and some backup systems).
> + See linkgit:git-update-index[1]. True by default.
> +
> CRLF conversion bears a slight chance of corrupting data.
> autocrlf=true will convert CRLF to LF during commit and LF to
Somehow, this particular position of the new hunk does not feel like the
best choice. ;-)
Petr "Pasky" Baudis
^ permalink raw reply
* git submodules
From: Pierre Habouzit @ 2008-07-28 16:20 UTC (permalink / raw)
To: Git ML
[-- Attachment #1: Type: text/plain, Size: 2813 bytes --]
While trying to sum up some things I'd like submodules to do, and things
like that, I came to ask myself why the heck we were doing things the
way we currently do wrt submodules.
This question is related to the `.git` directories of submodules. I
wonder why we didn't chose to use a new reference namespace
(refs/submodules/$path/$remote/$branch).
This would have the net benefit that most of the plumbing tasks would be
easier if they have to deal with submodules, because they aren't in this
uncomfortable situation where they have to recurse into another git
directory to know what to do.
It also has the absolutely nice property to share objects, so that
projects that replaced a subdirectory with a submodule don't see their
checkouts grow too large.
We probably still want submodules to act like plain independant git
repositories, but one can still *fake* that this way: submodules have
only a .git/config file (also probably an index and a couple of things
like that, but that's almost a different issue for what I'm considering
now) that has the setting:
[core]
submodule = true
This could make all the builtins look for the real $GIT_DIR up, which in
turn gives the submodule "name". Then, for this submodule, every
reference, remote name, ... would be virtualized using the
"remote/$submodule_name" prefix. IOW, in a submodule "some/sub/module"
the branch "origin/my/topic/branch" is under:
refs/submodules/some/sub/module/origin/my/topic/branch
<-- submod. --><-- submod. --><-- --><-- branch -->
namespace path/name remote
Note that this doesn't mean that we must rip out .gitmodules, because
it's needed to help splitting the previous reference name properly, and
for bootstrapping purposes.
Having that, one can probably extend most of the porcelains in _very_
straightforward ways. For example, a local topic branch `topic` would be
the union of the supermodule `topic` branch, and all the
`refs/submodules/$names/topic` ones.
Most importantly, it would help implementing that tries to make your
submodules stay _on branch_. One irritating problem with submodules, is
that when someone else commited, and that you git submodule update,
you're on a detached head. Absolutely horrible. If you see your current
branch (assume it's master), then when you do that, you would update
your `refs/submodules/$name/master` references instead and keep the
submodule HEADs `on branch`. Of course we can _probably_ hack something
together along those lines with the current setup, but it would be _so_
much more convenient this way...
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Make use of stat.ctime configurable
From: Linus Torvalds @ 2008-07-28 16:09 UTC (permalink / raw)
To: David Brown
Cc: Alex Riesen, Junio C Hamano, Johannes Schindelin, Johannes Sixt,
git
In-Reply-To: <20080728160446.GA16351@old.davidb.org>
On Mon, 28 Jul 2008, David Brown wrote:
> On Mon, Jul 28, 2008 at 08:31:28AM +0200, Alex Riesen wrote:
>
> > because there are situations where it produces too much false
> > positives. Like when file system crawlers keep changing it when
> > scanning and using the ctime for marking scanned files.
>
> That's interesting, since most backup software uses the ctime to determine
> file changes.
It really is just Beagle that is (was? I can dream) a piece of
unbelievable crap.
Anybody who uses extended attributes as part of a indexing scheme is just
insane. Modifying the file you are indexing is not just fundamentally
wrong to begin with, but it will then also be incredibly inefficient to
read those entries one at a time.
And no other sane model would ever touch 'ctime'.
Oh, well. Making ctime configurable is not wrong per se. But if it's
Beagle that triggers this, the fix is sadly in the wrong place.
Linus
^ permalink raw reply
* Re: [PATCH] Make use of stat.ctime configurable
From: David Brown @ 2008-07-28 16:04 UTC (permalink / raw)
To: Alex Riesen
Cc: Junio C Hamano, Johannes Schindelin, Linus Torvalds,
Johannes Sixt, git
In-Reply-To: <20080728063128.GA4234@blimp.local>
On Mon, Jul 28, 2008 at 08:31:28AM +0200, Alex Riesen wrote:
>because there are situations where it produces too much false
>positives. Like when file system crawlers keep changing it when
>scanning and using the ctime for marking scanned files.
That's interesting, since most backup software uses the ctime to determine
file changes.
David
^ permalink raw reply
* q: git-fetch a tad slow?
From: Ingo Molnar @ 2008-07-28 16:01 UTC (permalink / raw)
To: git
here's another possibly stupid question.
Setup/background: distributed kernel testing cluster, there's a central
box with a git repo of the kernel, and lots of of testboxes that track
that repo over ssh transport. In each "iteration" a random kernel config
is generated, built and booted, and the booted up kernel is checked.
Performance of each iteration matters to total testing throughput, so i
try to optimize the critical path.
Problem: i noticed that git-fetch is a tad slow:
titan:~/tip> time git-fetch
real 0m2.372s
user 0m0.814s
sys 0m0.951s
There are hundreds of branches, so i thought fetching a single branch
alone would improve things:
titan:~/tip> time git-fetch origin master
real 0m0.942s
user 0m0.285s
sys 0m0.109s
But that's still slow - so i use a (lame) ad-hoc script instead:
titan:~/tip> time tip-fetch
real 0m0.246s
user 0m0.024s
sys 0m0.019s
... which ssh's to the repo to check tip/master by hand:
HEAD=$(git-log -1 --pretty=format:"%H" HEAD)
RHEAD=$(ssh server "cd tip; git-log master -1 --pretty=format:'%H'")
[ "$RHEAD" != "$HEAD" ] && {
[...]
}
... which script is lame/expensive on multiple levels but still is much
faster.
I'm wondering, am i missing something obvious? It seems most of the
overhead is local CPU overhead, so it's something in Git's domain and
not the expense of the ssh protocol. (which expense should be about 200
msecs)
Ingo
^ permalink raw reply
* Re: [PATCHv2] git-mv: Keep moved index entries inact
From: Johannes Schindelin @ 2008-07-28 15:14 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: Junio C Hamano, Petr Baudis, git
In-Reply-To: <alpine.DEB.1.00.0807281605330.8986@racer>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1132 bytes --]
Hi,
On Mon, 28 Jul 2008, Johannes Schindelin wrote:
> On Mon, 28 Jul 2008, SZEDER Gábor wrote:
>
> > there is a race somewhere in these 'git-mv: Keep moved index entries
> > inact' changes.
> >
> > The test cases 'git mv should overwrite symlink to a file' or 'git mv
> > should overwrite file with a symlink' fail occasionaly. It's quite
> > non-deterministic: I have run t7001-mv.sh in a loop (see below) and
> > one or the other usually fails around 50 runs (but sometimes only
> > after 150). Adding some tracing echos to the tests shows that both
> > tests fail when running 'git diff-files' at the end.
>
> To make it more convenient to test: with this patch it fails all the time:
Ooops. Seems like I changed the test 23 to fail, instead of test 24.
However, I think it is the same bug: the index is newer by one second, so
it seems that the patch for builtin-mv.c did not really keep the data
"intact".
Note that a test case should use test-chmtime to force this scenario, not
sleep a second.
Unfortunately, I already spent my Git time budget for today, so the ball
is out of my half for now.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCHv2] git-mv: Keep moved index entries inact
From: Johannes Schindelin @ 2008-07-28 15:06 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: Junio C Hamano, Petr Baudis, git
In-Reply-To: <20080728142023.GC6701@neumann>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1086 bytes --]
Hi,
On Mon, 28 Jul 2008, SZEDER Gábor wrote:
> there is a race somewhere in these 'git-mv: Keep moved index entries
> inact' changes.
>
> The test cases 'git mv should overwrite symlink to a file' or 'git mv
> should overwrite file with a symlink' fail occasionaly. It's quite
> non-deterministic: I have run t7001-mv.sh in a loop (see below) and
> one or the other usually fails around 50 runs (but sometimes only
> after 150). Adding some tracing echos to the tests shows that both
> tests fail when running 'git diff-files' at the end.
To make it more convenient to test: with this patch it fails all the time:
-- snipsnap --
t/t7001-mv.sh | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/t/t7001-mv.sh b/t/t7001-mv.sh
index b0fa407..6699abd 100755
--- a/t/t7001-mv.sh
+++ b/t/t7001-mv.sh
@@ -180,6 +180,7 @@ test_expect_success 'git mv should overwrite symlink to a file' '
echo 1 >moved &&
ln -s moved symlink &&
git add moved symlink &&
+ sleep 1 &&
test_must_fail git mv moved symlink &&
git mv -f moved symlink &&
! test -e moved &&
^ permalink raw reply related
* gitk crashing on Windows.
From: Jurko Gospodnetić @ 2008-07-28 14:58 UTC (permalink / raw)
To: git
Hi.
When you run gitk from a git repository on Windows it starts up and
starts updating its 'Row X/Y' output labels. This lasts for a few
seconds but if you terminate the application before this updating is
complete you get a Windows message stating:
'Wish Application has encountered a problem and needs to close. We
are sorry for the inconvenience.'
and the standard 'Send Error Report'/'Don't Send' buttons.
Hope this helps.
Best regards,
Jurko Gospodnetić
^ permalink raw reply
* theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy
From: Sverre Rabbelier @ 2008-07-28 14:54 UTC (permalink / raw)
To: Git Mailinglist; +Cc: Miklos Vajna, Johannes Schindelin
On Mon, Jul 28, 2008 at 15:12, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Note that what was asked for, and what Junio implemented before deciding
> that it would do more harm than good in git.git, is not the same as what
> you provide.
>
> Your -theirs is a strict opposite of -ours, i.e. the tree after the
> merge will be identical to the "merged" branch's tip's.
I've been wanting to mail about this for a few days now, but didn't
really know how to bring it up, this seems a good opportunity.
It has happened a few times on #git already that someone asked for the
merge strategies described above (e.g., _not_ the insane ones) for
what I deemed to be valid use cases. (The main reason was that they
wanted to merge with a conflicting branch, discarding the current
master, but still allowing people to 'git pull'.)
I was wondering what to tell those people? Will there ever be such a
version of 'merge theirs' (that is the strict opposite of 'ours')? Or
should they do:
$git checkout otherbranch
$git merge -s ours master
$git checkout master
$git merge otherbranch
Thus resulting in a 'wrong way around' merge as part of master? It
would say "Merge branch 'master' into otherbranch", while what
happened was "Merge branch 'otherbranch' into master".
So, in short: what does the list think about adding
"git-merge-theirs", that does (although possibly less 'hackish'):
cat > git-merge-theirs << EOF
#!/bin/sh
eval git read-tree --reset -u \\\$\$#
EOF
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCHv2] git-mv: Keep moved index entries inact
From: SZEDER Gábor @ 2008-07-28 14:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git
In-Reply-To: <7v8wvpm9cl.fsf@gitster.siamese.dyndns.org>
Hi,
there is a race somewhere in these 'git-mv: Keep moved index entries
inact' changes.
The test cases 'git mv should overwrite symlink to a file' or 'git mv
should overwrite file with a symlink' fail occasionaly. It's quite
non-deterministic: I have run t7001-mv.sh in a loop (see below) and
one or the other usually fails around 50 runs (but sometimes only
after 150). Adding some tracing echos to the tests shows that both
tests fail when running 'git diff-files' at the end.
Regards,
Gábor
---
#!/bin/bash
ret=0
i=0
while test $ret = 0 ; do
GIT_TEST_OPTS='--verbose --debug' make t7001-mv.sh
ret=$?
i=$((i+1))
done
echo "Failed at ${i}th run"
^ permalink raw reply
* Re: Branch renaming not updating the configuration correctly.
From: Jurko Gospodnetić @ 2008-07-28 14:06 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.DEB.1.00.0807281445340.8986@racer>
Hi Johannes.
>> -- .git/config: --
>> [branch "aaa"]
>> remote = .
>> merge = bbb
>> ------------------
>>
>> > git branch -m aaa patched
>> > git branch -m bbb original
>>
>> -- .git/config: --
>> [branch "patched"]
>> remote = .
>> merge = bbb
>> ------------------
>>
>> And as you can see above, the branch.patched.merge configuration setting
>> did not get updated and still holds the old branch name 'bbb'.
>
> I deem this not an "important" bug.
Just wanted to chip in and report... not comfortable enough yet with
git from the user side to contribute with much else...
> We usually do not set up tracking information for local branches, and I
> still do not know valid common scenarios for that workflow.
I was playing around with setting up a local branch containing Boost
library sources as there is no official git repository for that project.
They hold their main repository under subversion and have currently
closed down their main development branch for changes while a new
release is being prepared. As I do _hate_ svn branching/merging I
thought git should be perfect for the task of tracking my own changes to
the project and this whole 'project' would give me a chance to get
better acquainted with the tool :-).
Crossing the SVN/Git boundary however is causing a problem since I
use Windows and 'git svn' does not seem to be supported here. My initial
idea was to manually update my own personal 'origin/master' branch (svn
checkout & then manually commit to the my git branch) and then update
other branches containing my patches from there. Locally-tracking
branches seemed like a perfect fit for that.
Any other suggested patterns/organizations/solutions I should try out
in this case?
> But hey, if it really bothers you, and you can come up with a
> non-intrusive patch (i.e. a patch that does not punish all users that do
> _not_ set up locally-tracking branches), I am sure it will be welcomed.
Heh... it'll take a little more time for me to get comfortable enough
with git to attempt something like that. :-) Still an infant user here,
happy with reporting what I find and hoping I don't miss something too
obvious or find & report something already reported. :-)
Best regards,
Jurko Gospodnetić
^ permalink raw reply
* Re: [PATCH] Allow building without any git installed
From: Shawn O. Pearce @ 2008-07-28 13:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, git
In-Reply-To: <7vsktutrh5.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> This is a follow-up patch to 49fa65a (Allow the built-in exec path to be
> relative to the command invocation path, 2008-07-23). Without specific
> gitexecdir passed from the command line, git-gui's build procedure would
> try to figure out the value for it by running an installed git.
Ack. I noticed this yesterday while looking at the git Makefile but
forgot to send a patch for it myself. Thanks Junio.
> diff --git a/Makefile b/Makefile
> index 798a2f2..7e30b30 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1067,7 +1067,7 @@ endif
>
> all::
> ifndef NO_TCLTK
> - $(QUIET_SUBDIR0)git-gui $(QUIET_SUBDIR1) all
> + $(QUIET_SUBDIR0)git-gui $(QUIET_SUBDIR1) gitexecdir='$(gitexec_instdir_SQ)' all
> $(QUIET_SUBDIR0)gitk-git $(QUIET_SUBDIR1) all
> endif
> $(QUIET_SUBDIR0)perl $(QUIET_SUBDIR1) PERL_PATH='$(PERL_PATH_SQ)' prefix='$(prefix_SQ)' all
--
Shawn.
^ permalink raw reply
* Re: Branch renaming not updating the configuration correctly.
From: Johannes Schindelin @ 2008-07-28 13:49 UTC (permalink / raw)
To: Jurko Gospodnetić; +Cc: git
In-Reply-To: <g6ki09$81c$1@ger.gmane.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 841 bytes --]
Hi,
On Mon, 28 Jul 2008, Jurko Gospodnetić wrote:
> -- .git/config: --
> [branch "aaa"]
> remote = .
> merge = bbb
> ------------------
>
> > git branch -m aaa patched
> > git branch -m bbb original
>
> -- .git/config: --
> [branch "patched"]
> remote = .
> merge = bbb
> ------------------
>
> And as you can see above, the branch.patched.merge configuration setting
> did not get updated and still holds the old branch name 'bbb'.
I deem this not an "important" bug.
We usually do not set up tracking information for local branches, and I
still do not know valid common scenarios for that workflow.
But hey, if it really bothers you, and you can come up with a
non-intrusive patch (i.e. a patch that does not punish all users that do
_not_ set up locally-tracking branches), I am sure it will be welcomed.
Ciao,
Dscho
^ permalink raw reply
* Branch renaming not updating the configuration correctly.
From: Jurko Gospodnetić @ 2008-07-28 13:36 UTC (permalink / raw)
To: git
Hi.
I noticed that the .git/config file is not updated completely in case
you create two branches aaa and bbb, set the repository up so it
automatically merges changes from bbb into aaa and then rename the branches:
Here is an exact list of commands and config file contents
illustrating the problem:
> git branch aaa
> git branch bbb
> git config --add branch.aaa.remote .
> git config --add branch.aaa.merge bbb
-- .git/config: --
[branch "aaa"]
remote = .
merge = bbb
------------------
> git branch -m aaa patched
> git branch -m bbb original
-- .git/config: --
[branch "patched"]
remote = .
merge = bbb
------------------
And as you can see above, the branch.patched.merge configuration
setting did not get updated and still holds the old branch name 'bbb'.
Hope this helps.
Best regards,
Jurko Gospodnetić
^ 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