* Re: [PATCH 1/2] gitweb: Fix file links in "grep" search
From: Thomas Perl @ 2012-01-13 14:09 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git
In-Reply-To: <201201052126.49087.jnareb@gmail.com>
Hi,
2012/1/5 Jakub Narebski <jnareb@gmail.com>:
> There were two bugs in generating file links (links to "blob" view),
> one hidden by the other. The correct way of generating file link is
>
> href(action=>"blob", hash_base=>$co{'id'},
> file_name=>$file);
>
> It was $co{'hash'} (this key does not exist, and therefore this is
> undef), and 'hash' instead of 'hash_base'.
> [...]
> Thomas, could you check if this fixes your issue?
Sorry for taking a bit longer to respond on this one, but I just got
around to test all problematic cases that I described with the patch
applied - it fixes the problem for me (i.e. I can successfully grep in
non-master branches and then clicking the link brings me to the right
location).
As far as I'm concerned, the patch can be applied and fixes the bug.
Thanks for the quick fix! :)
Thomas
^ permalink raw reply
* Re: thin packs ending up fat
From: Jeff King @ 2012-01-13 15:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Nicolas Pitre
In-Reply-To: <7vmx9sysqe.fsf@alter.siamese.dyndns.org>
On Thu, Jan 12, 2012 at 11:19:37PM -0800, Junio C Hamano wrote:
> I wanted to make sure I understood the root cause of the issue and the
> approach the patch takes to address it, instead of committing something
> that smelled correct. And the only way I know to do so is to write it
> down.
I use something of the same technique myself...
> Especiallly, before coming up with the description, I was wondering if
> this kind of symptom appears in non-thin cases, but after writing down the
> justification for this patch, it became clear that we wouldn't have to
> worry too much about that case. In a non-thin pack, we need to record one
> object at least in a delta family in inflated base form, so we may as well
> send that one near the tip that is already in that form for that, letting
> the existing "avoid futile delta" heuristics to kick in. Other objects in
> the same delta family will delta against it.
Exactly. You asked earlier why my one-liner patch was not in the first
message. It's because it was only through writing the first message that
I came to the same realization. :)
-Peff
^ permalink raw reply
* Re: fetch for bare repository
From: Carlos Martín Nieto @ 2012-01-13 15:18 UTC (permalink / raw)
To: Dmitry A. Ashkadov; +Cc: git
In-Reply-To: <4F103797.7060906@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2363 bytes --]
On Fri, Jan 13, 2012 at 05:54:31PM +0400, Dmitry A. Ashkadov wrote:
> 13.01.2012 17:40, Carlos Martín Nieto пишет:
> >On Fri, Jan 13, 2012 at 02:42:03PM +0400, Dmitry A. Ashkadov wrote:
> >>Hello!
> >>
> >>I can't understand how to fetch branches from external repository
> >>for bare repository.
> >What you probably want is a mirror (git clone --mirror). Unless you
> >tell git that you want a mirror, it's going to assume that you want a
> >bare repo to push your own changes up to it. Such a repo has no need
> >to be kept up to date, so clone doesn't set up any fetch refspecs.
>
> I don't have access to an origin repository. So, I need bare
> repository and push changes up to it. So, I think the word "mirror"
> isn't applicable to private repository.
When you say access here, do you mean that you can't push to it? When
I say access later on, it means being able to fetch from it.
Otherwise I don't see how you could have cloned from it. If your
private repository's braches to reflect what's upstream, I'd call that
a mirror.
>
> >Stepping back, do you need to fetch those branches into the private
> >repo? If you still have access to the main repo and that's where the
> >main project development is happening, why not use upstream's repo to
> >get those changes to your local repo (as in the one you use to work)?
> >It sounds like you're trying to replicate a centralised VCS'
> >workflow. Git works like a network and you can merge a branch from
> >upstream if you need to and then push to the private repo.
>
> Yes, I can add one more remote to my local repository, then fetch
> changes from it and push it to private repository. But I thought
> that update private repository is the best way.
Best way to achieve what? If you want your private repo to reflect
what's upstream, doing the inital clone with --mirror (or setting the
remote.origin.fetch config variable to "+refs/*:refs/*", which is the
main difference) will let you run 'git fetch' on that repo and get the
changes.
But what I was asking was whether you actually need to bother with
that operation. If you need to merge or rebase from upstream, a push
will include those new changes, as they're now in your branch, so what
advantage do you get from copying those branches from upstream if
they're just the same?
cmn
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: thin packs ending up fat
From: Jeff King @ 2012-01-13 15:55 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: git, Nicolas Pitre
In-Reply-To: <CACBZZX567mHKXDtTcb+zFKtr2ZvcssF+O=w-x86PfNh+5tTpRg@mail.gmail.com>
On Fri, Jan 13, 2012 at 09:28:43AM +0100, Ævar Arnfjörð Bjarmason wrote:
> On Thu, Jan 12, 2012 at 23:15, Jeff King <peff@peff.net> wrote:
>
> I'd be interested in testing this on some other repos I have. How
> exactly did you get this:
>
> > -- >8 --
> > 8b0e15fa95e11965f18c8d2585dc8ffd9bfc9356 ^7f41b6bbe3181dc4d1687db036bf22316997a1bf
> > 34c4461ae3b353e8c931565d5527b98ed12e3735 ^8b0e15fa95e11965f18c8d2585dc8ffd9bfc9356
> > 463b0ea22b5b9a882e8140d0308433d8cbd0d1fe ^34c4461ae3b353e8c931565d5527b98ed12e3735
> > 288396994f077eec7e7db0017838a5afbfbf81e3 ^463b0ea22b5b9a882e8140d0308433d8cbd0d1fe
> > 05f6edcd2a418a88eeb953d51408a6aeef312f5c ^288396994f077eec7e7db0017838a5afbfbf81e3
> > 08cfdbb88cd6225b4fc4b8a3cecd0e01758c835d ^05f6edcd2a418a88eeb953d51408a6aeef312f5c
>
> From this:
>
> > In the first, I used the reflog entries from my
> > refs/remotes/origin/master ref.
>
> I can't make "git reflog refs/remotes/..." show me anything similar.
I just looked in the reflog file directly:
perl -alne 'print "$F[1] ^$F[0]"' \
.git/logs/refs/remotes/origin/master
Note that these are just an approximation of what was fetched each time.
The real fetches packed objects for other refs, too. But with respect to
this patch, the result should be the same (since the interesting thing
is the graph boundaries that are packed, so the size of the slice of
history is what's important).
The other slight inaccuracy is that my tests repack the whole repo, and
then simulate old fetches from that repo. When I actually fetched
7f415b6..8b0e15fa from upstream, all of those later commits didn't
actually exist yet. And therefore the blobs in those tip commits were
actually more likely to be non-delta, and therefore this optimization is
more likely to help (because we already re-tried deltas if the target
object was delta'd against something else).
At least in theory. In practice, the variance of the improvement it
provides to each pack is so quite high. Some packs don't benefit at all,
because the preferred bases simply aren't that useful, or are perhaps
already being used. Some packs can have improvements in the 70-80%
range.
The numbers I reported were averaged over all of the packs in the
dataset. You can see individual packs with the script I provided
earlier:
# before patch
./test-pack <dataset-fetch >output-fetch-before
# after patch
./test-pack <dataset-fetch >output-fetch-after
# collate results
paste output-fetch-{before,after} |
perl -alne 'print "$F[0] $F[2] " .
int(0.5 + (($F[0] - $F[2]) / $F[0] * 100))'
The output is below. You can also feed the percentages through this poor
man's graph generator to see just how wildly it varies:
perl -alne 'print "*" x $F[2]'
-Peff
-- >8 --
154471 92495 40
41970 24681 41
102816 71062 31
21089 21089 0
57900 13345 77
75666 61518 19
163516 107785 34
44913 15795 65
85452 77832 9
102034 93336 9
10095 8283 18
86078 65495 24
1854 1854 0
16079 8125 49
13830 7119 49
1283 1283 0
4697 2633 44
4584 3818 17
21535 18953 12
3800 3800 0
13963 10215 27
4453 4073 9
1029 598 42
111233 68267 39
879 879 0
96628 86206 11
3287 3287 0
71212 20832 71
132916 100268 25
170716 40959 76
1830 1262 31
243950 133932 45
64588 31546 51
1108 1108 0
6488 6488 0
101179 64014 37
114760 18969 83
23443 19445 17
28207 28080 0
2317 2317 0
110890 53555 52
5660 5543 2
18683 18683 0
4709 4709 0
^ permalink raw reply
* [PATCH v2 0/2] git-show-ref: fix asciidoc formatting
From: mhagger @ 2012-01-13 16:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Thomas Rast, Michael Haggerty
From: Michael Haggerty <mhagger@alum.mit.edu>
This topic was discussed before [1]. I hereby try again, with a bit
more information in the commit messages for posterity.
The patches apply to master or maint, whatever you prefer.
[1] http://comments.gmane.org/gmane.comp.version-control.git/183940
Michael Haggerty (2):
git-show-ref: fix escaping in asciidoc source
git-show-ref doc: typeset regexp in fixed width font
Documentation/git-show-ref.txt | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
--
1.7.8.3
^ permalink raw reply
* [PATCH v2 1/2] git-show-ref: fix escaping in asciidoc source
From: mhagger @ 2012-01-13 16:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Thomas Rast, Michael Haggerty
In-Reply-To: <1326472756-15227-1-git-send-email-mhagger@alum.mit.edu>
From: Michael Haggerty <mhagger@alum.mit.edu>
Two "^" characters were incorrectly being interpreted as markup for
superscripting. Fix them by writing them as attribute references
"{caret}".
Although a single "^" character in a paragraph cannot be
misinterpreted in this way, also write other "^" characters as
"{caret}" in the interest of good hygiene (unless they are in literal
paragraphs, of course, in which context attribute references are not
recognized).
Spell "{}" consistently, namely *not* quoted as "\{\}". Since the
braces are empty, they cannot be interpreted as an attribute
reference, and either spelling is OK. So arbitrarily choose one
variation and use it consistently.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
Documentation/git-show-ref.txt | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-show-ref.txt b/Documentation/git-show-ref.txt
index 3c45895..8dfcbe3 100644
--- a/Documentation/git-show-ref.txt
+++ b/Documentation/git-show-ref.txt
@@ -44,7 +44,7 @@ OPTIONS
-d::
--dereference::
- Dereference tags into object IDs as well. They will be shown with "^{}"
+ Dereference tags into object IDs as well. They will be shown with "{caret}{}"
appended.
-s::
@@ -73,9 +73,9 @@ OPTIONS
--exclude-existing[=<pattern>]::
Make 'git show-ref' act as a filter that reads refs from stdin of the
- form "^(?:<anything>\s)?<refname>(?:{backslash}{caret}\{\})?$"
+ form "{caret}(?:<anything>\s)?<refname>(?:{backslash}{caret}{})?$"
and performs the following actions on each:
- (1) strip "^{}" at the end of line if any;
+ (1) strip "{caret}{}" at the end of line if any;
(2) ignore if pattern is provided and does not head-match refname;
(3) warn if refname is not a well-formed refname and skip;
(4) ignore if refname is a ref that exists in the local repository;
--
1.7.8.3
^ permalink raw reply related
* [PATCH v2 2/2] git-show-ref doc: typeset regexp in fixed width font
From: mhagger @ 2012-01-13 16:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Thomas Rast, Michael Haggerty
In-Reply-To: <1326472756-15227-1-git-send-email-mhagger@alum.mit.edu>
From: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
Optional; I think it looks better.
Documentation/git-show-ref.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-show-ref.txt b/Documentation/git-show-ref.txt
index 8dfcbe3..fcee000 100644
--- a/Documentation/git-show-ref.txt
+++ b/Documentation/git-show-ref.txt
@@ -73,7 +73,7 @@ OPTIONS
--exclude-existing[=<pattern>]::
Make 'git show-ref' act as a filter that reads refs from stdin of the
- form "{caret}(?:<anything>\s)?<refname>(?:{backslash}{caret}{})?$"
+ form "`{caret}(?:<anything>\s)?<refname>(?:{backslash}{caret}{})?$`"
and performs the following actions on each:
(1) strip "{caret}{}" at the end of line if any;
(2) ignore if pattern is provided and does not head-match refname;
--
1.7.8.3
^ permalink raw reply related
* Bug! Git merge also fails with a wrong error message
From: Yves Goergen @ 2012-01-13 17:37 UTC (permalink / raw)
To: git
In-Reply-To: <loom.20120112T193624-86@post.gmane.org>
I have updates to this issue.
After asking several people who didn't believe me,
after all I could pass all checks to ensure that
the file in question really is tracked, despite the error
message telling it is not. (The file has a history, it is
part of the branch,
git status behaves as expected when I rename it, and so on.)
I had found a workaround hack to access my
data again: I have cloned the repo
into another directory, then switched to
the branch in there (it actually
worked) and used BeyondCompare to manually(!)
switch my original repo and
working directory by copying some (not all) files
in .git and all differences in
the working directory.
That worked fine at first, I could commit to that branch.
Today I wanted to merge that branch into master again.
Switching to master was
fine, but merging from the form-refactoring branch
now fails for the very same
"reason":
-----
git.exe merge --no-commit form-refactoring
error: The following untracked working tree files
would be overwritten by merge:
Form1.Designer.cs
Please move or remove them before you can merge.
Aborting
-----
Again, that file is NOT untracked. Git just fails
processing its own data. I
cannot move that file because it is part of the
other branch and must be merged now.
Am I now supposed to checkout both branches and
do the merge somehow on my own?
Maybe it's not a good idea to use branching and
then rename, create and delete
files on that branch, as switching and merging
fail completely afterwards. And
in the end, maybe Git isn't all that good and
some of the alternatives with real
file tracking should be preferred.
I, for one, have lost a great amount of trust
in Git in the last two days.
(Sorry for the formatting mess, but the stupid Gmane
post editor forced me to do that or it wouldn't
accept my message... Don't you have a real mailing
list, if there's no web forum??)
^ permalink raw reply
* Re: Bug! Git merge also fails with a wrong error message
From: Jeff King @ 2012-01-13 17:50 UTC (permalink / raw)
To: Yves Goergen; +Cc: git
In-Reply-To: <loom.20120113T181805-423@post.gmane.org>
On Fri, Jan 13, 2012 at 05:37:38PM +0000, Yves Goergen wrote:
> After asking several people who didn't believe me,
> after all I could pass all checks to ensure that
> the file in question really is tracked, despite the error
> message telling it is not. (The file has a history, it is
> part of the branch,
> git status behaves as expected when I rename it, and so on.)
Whether a file in the working tree is tracked or not does not have to do
with the history, but rather with whether it is mentioned in the index.
Does the file appear in "git ls-files"?
It sounds like you are perhaps making changes in the working tree and
index, and then trying to checkout/merge on top of that. In that case
"git status" would report the file as renamed, but it's possible the
file is still in the working tree. From git's perspective the file is no
longer tracked, but the operations you are requesting would overwrite
the new contents (and git is being safe by refusing to do so).
Generally you don't want to merge with uncommitted changes like this.
You would want to commit them and then do your merge.
But even if you do commit, the question still remains: if you have
committed the removal of this file, then why is it still there? Is
something else creating it after you have deleted it?
-Peff
^ permalink raw reply
* Re: Bug! Git merge also fails with a wrong error message
From: Carlos Martín Nieto @ 2012-01-13 17:56 UTC (permalink / raw)
To: Yves Goergen; +Cc: git
In-Reply-To: <loom.20120113T181805-423@post.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2790 bytes --]
On Fri, Jan 13, 2012 at 05:37:38PM +0000, Yves Goergen wrote:
> I have updates to this issue.
You still haven't told us what version of (msys)git you're using nor
have you provided a transcript of your session or found a minimal
reproducible example.
Gmane is a mailing list viewer and there /only/ is the real maling
list. The e-mail you provided for yourself looks bogus, but if it
isn't, you'll notice we communicate via e-mail.
>
> After asking several people who didn't believe me,
> after all I could pass all checks to ensure that
> the file in question really is tracked, despite the error
> message telling it is not. (The file has a history, it is
> part of the branch,
> git status behaves as expected when I rename it, and so on.)
>
> I had found a workaround hack to access my
> data again: I have cloned the repo
> into another directory, then switched to
> the branch in there (it actually
> worked) and used BeyondCompare to manually(!)
> switch my original repo and
> working directory by copying some (not all) files
> in .git and all differences in
> the working directory.
>
> That worked fine at first, I could commit to that branch.
>
> Today I wanted to merge that branch into master again.
> Switching to master was
> fine, but merging from the form-refactoring branch
> now fails for the very same
> "reason":
>
> -----
> git.exe merge --no-commit form-refactoring
>
> error: The following untracked working tree files
> would be overwritten by merge:
> Form1.Designer.cs
> Please move or remove them before you can merge.
> Aborting
> -----
>
> Again, that file is NOT untracked. Git just fails
> processing its own data. I
> cannot move that file because it is part of the
> other branch and must be merged now.
>
> Am I now supposed to checkout both branches and
> do the merge somehow on my own?
>
> Maybe it's not a good idea to use branching and
> then rename, create and delete
> files on that branch, as switching and merging
> fail completely afterwards. And
> in the end, maybe Git isn't all that good and
> some of the alternatives with real
> file tracking should be preferred.
>
> I, for one, have lost a great amount of trust
> in Git in the last two days.
>
> (Sorry for the formatting mess, but the stupid Gmane
> post editor forced me to do that or it wouldn't
> accept my message... Don't you have a real mailing
> list, if there's no web forum??)
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Carlos Martín Nieto | http://cmartin.tk
"¿Cómo voy a decir bobadas si soy mudo?" -- CACHAI
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: Bug? Git checkout fails with a wrong error message
From: Yves Goergen @ 2012-01-13 17:46 UTC (permalink / raw)
To: Holger Hellmuth; +Cc: git
In-Reply-To: <4F1028AD.9080701@ira.uka.de>
On 13.01.2012 13:50 CE(S)T, Holger Hellmuth wrote:
> Important information missing: What version of git are you using? Should
> the version number begin with 1.6 or even lower you will get the advice
> to update your version to something non-ancient. Lots of bug-fixes
> happened in-between.
The first bug happened with msysGit 1.7.6 and 1.7.8, the second one
(reported now) with 1.7.8. That update didn't change a thing.
> I assume .cs is a C source file for visual studio, not a generated file,
> right ?
.cs is C# code and .Designer.cs files are used internally by the Visual
Studio designer. They're not supposed to be edited by the programmer and
contain lots of stuff that changes all the time. So they are generated
and presented in a different way.
> git does not record renames like cvs/svn do. It operates on snapshots
> and infers renames through comparisions. So if the next commit has a
> file missing and the same or similar file contents under some different
> path, it reports it as a rename. You can try -M with git log or git diff
> so that git expends more effort to detect renames+edits. Or you could
> avoid doing renames and edits of the same file in the same commit.
I renamed the file and created a new one with the same name. Is it so
simple to crash the Git repository?
>> -----
>> git.exe checkout form-refactoring
>>
>> Aborting
>> error: The following untracked working tree files would be overwritten by
>> checkout:
>> Form1.Designer.cs
>> Please move or remove them before you can switch branches.
>> -----
>
> You didn't mention that filename before (please assume people not
> accustomed to the ways of Visual Studio 2010). Is that another file you
> renamed and created new in the form-refactoring branch?
Form1.cs, Form1.Designer.cs and Form1.resx all belong together and are
renamed atomically. If I rename "Form1" in the project, actually these 3
files are renamed on disk.
> What does git diff -- Form1.Designer.cs' say?
Nothing.
> What does 'git diff form-refactoring -- Form1.Designer.cs' say?
All lines deleted.
Will this message also appear on the mailing list where I posted my
first message with Gmane? (That's the only thing I've found on the
official Git website.)
--
Yves Goergen "LonelyPixel" <nospam.list@unclassified.de>
Visit my web laboratory at http://beta.unclassified.de
^ permalink raw reply
* Re: Bug! Git merge also fails with a wrong error message
From: Yves Goergen @ 2012-01-13 18:49 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20120113175040.GC9373@sigill.intra.peff.net>
On 13.01.2012 18:50 CE(S)T, Jeff King wrote:
> Whether a file in the working tree is tracked or not does not have to do
> with the history, but rather with whether it is mentioned in the index.
I'm not using the index. In fact I don't even know how that what I have
read about it can be useful.
> Does the file appear in "git ls-files"?
Yes, it's in the list along with all other files.
> It sounds like you are perhaps making changes in the working tree and
> index, and then trying to checkout/merge on top of that. In that case
> "git status" would report the file as renamed, but it's possible the
> file is still in the working tree. From git's perspective the file is no
> longer tracked, but the operations you are requesting would overwrite
> the new contents (and git is being safe by refusing to do so).
Here's the git status output:
# On branch master
nothing to commit (working directory clean)
I have switched to master and the very next action was trying the merge.
There's no change in the working directory, and nothing uncommitted.
--
Yves Goergen "LonelyPixel" <nospam.list@unclassified.de>
Visit my web laboratory at http://beta.unclassified.de
^ permalink raw reply
* Re: Bug! Git merge also fails with a wrong error message
From: Jeff King @ 2012-01-13 18:54 UTC (permalink / raw)
To: Yves Goergen; +Cc: git
In-Reply-To: <4F107CAD.1020103@unclassified.de>
On Fri, Jan 13, 2012 at 07:49:17PM +0100, Yves Goergen wrote:
> On 13.01.2012 18:50 CE(S)T, Jeff King wrote:
> > Whether a file in the working tree is tracked or not does not have to do
> > with the history, but rather with whether it is mentioned in the index.
>
> I'm not using the index. In fact I don't even know how that what I have
> read about it can be useful.
Whether you realize it or not, git is using the index to store state.
When you "git add", "git rm", or "git mv", it is updating the index.
> > Does the file appear in "git ls-files"?
>
> Yes, it's in the list along with all other files.
Then it should be considered tracked, and there's a bug.
I notice that in your first mail, you mentioned a problem with
"checkout", and in the second one, a problem with "merge". Do you still
have the repo around with the "checkout" problem? If so, is the file
also in your "git ls-files" output in that repo?
It is much more likely to me that there is a bug in the merge than in
regular checkout (because merge has many complex corner cases
surrounding the 3-way merge, whereas checkout is simply moving from one
state to another). I'd like to make sure we're not seeing two different
problems.
> Here's the git status output:
> # On branch master
> nothing to commit (working directory clean)
>
> I have switched to master and the very next action was trying the merge.
> There's no change in the working directory, and nothing uncommitted.
Which version of git are you using? There were many bugs fixed around
this area of merge around the v1.7.7 timeframe.
-Peff
^ permalink raw reply
* mySysGit
From: Srinivas Rao @ 2012-01-12 23:56 UTC (permalink / raw)
To: msysgit@googlegroups.com; +Cc: git@vger.kernel.org
[-- Attachment #1: Type: text/plain, Size: 345 bytes --]
Hello,
When I try to connect to an ubuntu box which I am trying to setup as a git server, and then try to ssh through from my local machine, I see the following error. I have already generated the keys and setup the public key on the server.
ssh: connect to host 10.192.27.131 port 22: Bad file number
any ideas ?
Thanks much,
Sri
[-- Attachment #2: Type: text/html, Size: 2311 bytes --]
^ permalink raw reply
* Re: Bug! Git merge also fails with a wrong error message
From: Yves Goergen @ 2012-01-13 18:59 UTC (permalink / raw)
To: Carlos Martín Nieto, Yves Goergen, git
In-Reply-To: <20120113175617.GE2850@centaur.lab.cmartin.tk>
On 13.01.2012 18:56 CE(S)T, Carlos Martín Nieto wrote:
> You still haven't told us what version of (msys)git you're using nor
> have you provided a transcript of your session or found a minimal
> reproducible example.
In case one of my other mails didn't arrive, the Git version is 1.7.8.
There is no session transcript because I use TortoiseGit and I'm not
going to add a screencast here.
> Gmane is a mailing list viewer and there /only/ is the real maling
> list. The e-mail you provided for yourself looks bogus, but if it
> isn't, you'll notice we communicate via e-mail.
Well, I am very confused. Starting from git-scm.com, the only support
site is a mailing list, and the hyperlink on that word sends me to Gmane
which says I am in a newsgroup called "gmane.comp.version-control.git".
Since I don't have access to the news system, I need to use the Gmane
website. I don't know exactly what it is. I know mailing lists, but that
doesn't look like one at all. There's not even a subscription page or
address. For users of the modern web who are not familiar with 70s nntp
technology and cannot use a mailing list by merely knowing its address,
this is very support-unfriendly. I almost would have considered that the
official Git website doesn't want to offer any support at all. In that
case I would likely have searched for an alternative and switched right
away. Assuming I could have extracted the remainders of my source code
from the broken Git repository.
So am I now subscribed to that "git@vger.kernel.org" mailing list and do
my posts show up there? I have no idea what's going on, neither in my
repository, nor in this mailing list. Confusing and intransparent.
--
Yves Goergen "LonelyPixel" <nospam.list@unclassified.de>
Visit my web laboratory at http://beta.unclassified.de
^ permalink raw reply
* Re: Bug! Git merge also fails with a wrong error message
From: Yves Goergen @ 2012-01-13 19:05 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20120113185436.GA13522@sigill.intra.peff.net>
On 13.01.2012 19:54 CE(S)T, Jeff King wrote:
> Whether you realize it or not, git is using the index to store state.
> When you "git add", "git rm", or "git mv", it is updating the index.
I'm using TortoiseGit most of the time and that doesn't expose the
concept of an "index". I edit files as usual, then select "commit" and
get the commit dialogue. In there I enter the commit message and select
all files to commit. I can add new files right there. There is no
two-step procedure.
> I notice that in your first mail, you mentioned a problem with
> "checkout", and in the second one, a problem with "merge". Do you still
> have the repo around with the "checkout" problem? If so, is the file
> also in your "git ls-files" output in that repo?
Yes, I have made a backup of the repo right after the initial problem
arose. And the git ls-files output is the same regarding that file.
> Which version of git are you using? There were many bugs fixed around
> this area of merge around the v1.7.7 timeframe.
msysGit 1.7.8 on Windows XP SP3. It's a "preview" but since Git is so
old now and there's been nothing but "previews", I consider msysGit's
meaning of the word "preview" as "stable".
--
Yves Goergen "LonelyPixel" <nospam.list@unclassified.de>
Visit my web laboratory at http://beta.unclassified.de
^ permalink raw reply
* Re: [PATCH] merge: Make merge strategy message follow the diffstat
From: Junio C Hamano @ 2012-01-13 19:12 UTC (permalink / raw)
To: Paul Gortmaker
Cc: Linus Torvalds, Mark Brown, Liam Girdwood, linux-kernel,
Git Mailing List
In-Reply-To: <20120111184026.GA23952@windriver.com>
Paul Gortmaker <paul.gortmaker@windriver.com> writes:
> By moving the message after the diffstat, there is a better chance that
> people will be aware they've done a pointless merge commit.
>
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
I think the goal of the change may be worthy, but a few points:
- What does "automsg" mean? Is "auto" in contrast to "manual"? Even
better, wouldn't it be far simpler to just use
if (msg && verbosity >= 0)
printf("%s\n", msg);
and get rid of this mysteriously named variable altogether?
- Wouldn't it make more sense to move "No merge message -- not updating
HEAD" also to the end?
- After applying this patch, does the tests still pass?
Thanks.
^ permalink raw reply
* Re: [PATCH 1/2] gitweb: Fix file links in "grep" search
From: Junio C Hamano @ 2012-01-13 19:18 UTC (permalink / raw)
To: Thomas Perl; +Cc: Jakub Narebski, git
In-Reply-To: <CA+uOhx7QwRQJzyYBCkmVDBRCMt0i_ZqS=sfTG0VmNiVv2dVoww@mail.gmail.com>
Thomas Perl <th.perl@gmail.com> writes:
> As far as I'm concerned, the patch can be applied and fixes the bug.
Thanks.
^ permalink raw reply
* Re: [PATCH] merge: Make merge strategy message follow the diffstat
From: Nguyen Thai Ngoc Duy @ 2012-01-13 19:27 UTC (permalink / raw)
To: Junio C Hamano
Cc: Paul Gortmaker, Linus Torvalds, Mark Brown, Liam Girdwood,
linux-kernel, Git Mailing List
In-Reply-To: <7vaa5rzaax.fsf_-_@alter.siamese.dyndns.org>
On Sat, Jan 14, 2012 at 2:12 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Paul Gortmaker <paul.gortmaker@windriver.com> writes:
>
>> By moving the message after the diffstat, there is a better chance that
>> people will be aware they've done a pointless merge commit.
>>
>> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
>
> I think the goal of the change may be worthy
Still, diffstat from a fetch/pull is sometimes too verbose. It'd be
better if we have something that fit in one screen (dirstat or maybe
just a first few lines from diffstat then ellipsis) then refer users
to "git diff --stat HEAD@{1}" for more detail stat.
--
Duy
^ permalink raw reply
* Re: Bug? Git checkout fails with a wrong error message
From: Holger Hellmuth @ 2012-01-13 19:28 UTC (permalink / raw)
To: Yves Goergen; +Cc: git, Jeff King, Carlos Martín Nieto
In-Reply-To: <4F106DDF.4040408@unclassified.de>
Added Peff and Carlos to the CC so they see this part of the thread too.
On 13.01.2012 18:46, Yves Goergen wrote:
> On 13.01.2012 13:50 CE(S)T, Holger Hellmuth wrote:
>> Important information missing: What version of git are you using? Should
>> the version number begin with 1.6 or even lower you will get the advice
>> to update your version to something non-ancient. Lots of bug-fixes
>> happened in-between.
>
> The first bug happened with msysGit 1.7.6 and 1.7.8, the second one
> (reported now) with 1.7.8. That update didn't change a thing.
>
>> I assume .cs is a C source file for visual studio, not a generated file,
>> right ?
>
> .cs is C# code and .Designer.cs files are used internally by the Visual
> Studio designer. They're not supposed to be edited by the programmer and
> contain lots of stuff that changes all the time. So they are generated
> and presented in a different way.
Is it possible that Visual Studio changes them while you are comitting?
>> git does not record renames like cvs/svn do. It operates on snapshots
>> and infers renames through comparisions. So if the next commit has a
>> file missing and the same or similar file contents under some different
>> path, it reports it as a rename. You can try -M with git log or git diff
>> so that git expends more effort to detect renames+edits. Or you could
>> avoid doing renames and edits of the same file in the same commit.
>
> I renamed the file and created a new one with the same name. Is it so
> simple to crash the Git repository?
Who said anything about crash? git simply doesn't care whether a change
is because of a rename. It isn't special or different to any change you
can make to a file
>>> -----
>>> git.exe checkout form-refactoring
>>>
>>> Aborting
>>> error: The following untracked working tree files would be overwritten by
>>> checkout:
>>> Form1.Designer.cs
>>> Please move or remove them before you can switch branches.
>>> -----
>>
>> You didn't mention that filename before (please assume people not
>> accustomed to the ways of Visual Studio 2010). Is that another file you
>> renamed and created new in the form-refactoring branch?
>
> Form1.cs, Form1.Designer.cs and Form1.resx all belong together and are
> renamed atomically. If I rename "Form1" in the project, actually these 3
> files are renamed on disk.
As an aside, if .Designer.cs is generated automatically from Form1.cs it
shouldn't be tracked at all. Maybe tortoise git has a global gitignore
with a line "*.Designer.cs" in it to account for that fact. Maybe this
lead to the error message?
>> What does git diff -- Form1.Designer.cs' say?
>
> Nothing.
>
>> What does 'git diff form-refactoring -- Form1.Designer.cs' say?
>
> All lines deleted.
Really all lines? That would indicate that you don't have a file
Form1.Designer.cs (or an empty one) in your working directory in branch
master. In case there is no file (as seen by git) the output of diff
should compare with /dev/null aka the void aka <I don't know how this
prints on the windows side>. Also notice the line "deleted file mode ..."
> git diff master -- zumf
diff --git a/zumf b/zumf
deleted file mode 100644
index 925eccd..0000000
--- a/zumf
+++ /dev/null
@@ -1 +0,0 @@
Or did you just mean "all the shown lines in the diff were fronted by a
minus sign"? Which would just indicate that the file in form-refactoring
is a superset of the one in master.
(As you can see, actual reproduction of command line output is very
helpful to avoid ambiguity and can give further hints)
^ permalink raw reply related
* Re: Bug! Git merge also fails with a wrong error message
From: Jakub Narebski @ 2012-01-13 19:34 UTC (permalink / raw)
To: Yves Goergen; +Cc: Carlos Martín Nieto, git
In-Reply-To: <4F107F16.30009@unclassified.de>
Yves Goergen <nospam.list@unclassified.de> writes:
> On 13.01.2012 18:56 CE(S)T, Carlos Martín Nieto wrote:
> > Gmane is a mailing list viewer and there /only/ is the real maling
> > list. The e-mail you provided for yourself looks bogus, but if it
> > isn't, you'll notice we communicate via e-mail.
>
> Well, I am very confused. Starting from git-scm.com, the only support
> site is a mailing list, and the hyperlink on that word sends me to Gmane
> which says I am in a newsgroup called "gmane.comp.version-control.git".
Note however that the _text_ of the hyperlink is
git@vger.kernel.org mailing list
> Since I don't have access to the news system, I need to use the Gmane
> website. I don't know exactly what it is.
GMane is an e-mail to news gateway, and a mailing list archive. It
exposes mailing list as a newsgroup, so it can be read and written to
via newsreader (via Usenet).
Perhaps better solution would be to use mailto:git@vger.kernel.org
link, and add a sentence about archives / alternative interfaces.
> I know mailing lists, but that
> doesn't look like one at all. There's not even a subscription page or
> address.
git@vger.kernel.org is a public non-subscribe mailing list; you don't
need to subscribe to post requests there. Note that it is a custom on
this mailing list to always include all participants in given
(sub)thread directly in Cc, so you should get responses to your emails
even if you are not subscribed.
[...]
> So am I now subscribed to that "git@vger.kernel.org" mailing list and do
> my posts show up there? I have no idea what's going on, neither in my
> repository, nor in this mailing list. Confusing and non-transparent.
If you send email to git@vger.kernel.org, it would also appear on
GMane.
--
Jakub Narebski
^ permalink raw reply
* Re: [PATCH] merge: Make merge strategy message follow the diffstat
From: Linus Torvalds @ 2012-01-13 19:49 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy
Cc: Junio C Hamano, Paul Gortmaker, Mark Brown, Liam Girdwood,
linux-kernel, Git Mailing List
In-Reply-To: <CACsJy8BmFgssTAh=1U7JgBsGG-tSaWXQzZeODND3icXY3QUxug@mail.gmail.com>
On Fri, Jan 13, 2012 at 11:27 AM, Nguyen Thai Ngoc Duy
<pclouds@gmail.com> wrote:
>
> Still, diffstat from a fetch/pull is sometimes too verbose. It'd be
> better if we have something that fit in one screen (dirstat or maybe
> just a first few lines from diffstat then ellipsis) then refer users
> to "git diff --stat HEAD@{1}" for more detail stat.
Yeah, I've wanted that. Show the beginning, the end, and the summary
line of the diffstat would be lovely.
It would be lovely in "git commit" too. Not just
Modified: filename
but a diffstat that shows now many lines.
And what I've *really* wanted is to actually see the diff itself if it
is small. So some kind of "dynamic summary": for one-liners (or
ten-liners), show the whole diff. For medium-sized changes, show the
whole diffstat. And for really big changes, show an outline and the
"768 files changed, 179851 lines added, 7630 lines removed" stats.
IOW, whatever fits in, say, 50 lines or less.
That would be absolutely lovely if somebody were to do it.
Linus
^ permalink raw reply
* Re: [PATCH v2 2/2] git-show-ref doc: typeset regexp in fixed width font
From: Junio C Hamano @ 2012-01-13 19:51 UTC (permalink / raw)
To: mhagger; +Cc: git, Thomas Rast
In-Reply-To: <1326472756-15227-3-git-send-email-mhagger@alum.mit.edu>
mhagger@alum.mit.edu writes:
> From: Michael Haggerty <mhagger@alum.mit.edu>
>
>
> Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
> ---
> Optional; I think it looks better.
I agree it looks better, too, as long as everybody's copy of AsciiDoc
groks it. I see "`<something>`" in many places in the other pages, so this
should be safe.
Thanks for resending. Will queue.
^ permalink raw reply
* Re: [PATCH v4 00/10] nd/clone-detached
From: Junio C Hamano @ 2012-01-13 19:52 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1326439322-15648-1-git-send-email-pclouds@gmail.com>
Thanks, replaced (and updated comment strings read much better).
There were some conlicts I had to resolve while merging this to 'pu'.
I would appreciate it if you can eyeball it to make sure I didn't make
silly mistakes there.
Thanks.
^ permalink raw reply
* [ANNOUNCE] Git 1.7.9.rc1
From: Junio C Hamano @ 2012-01-13 19:55 UTC (permalink / raw)
To: git; +Cc: Linux Kernel
A release candidate Git 1.7.9.rc1 is available for testing.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
b97f10508f16b4117499cdfc4df9b19c725027d5 git-1.7.9.rc1.tar.gz
3064fc295a46440a91ca3f5fa622f5f1d40d3ba4 git-htmldocs-1.7.9.rc1.tar.gz
332e12061823d8def0fb823fa7798093bbe41279 git-manpages-1.7.9.rc1.tar.gz
Also the following public repositories all have a copy of the v1.7.9.rc1
tag and the master branch that the tag points at:
url = git://repo.or.cz/alt-git.git
url = https://code.google.com/p/git-core/
url = git://git.sourceforge.jp/gitroot/git-core/git.git
url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
url = https://github.com/gitster/git
Git v1.7.9 Release Notes (draft)
========================
Updates since v1.7.8
--------------------
* gitk updates accumulated since early 2011.
* git-gui updated to 0.16.0.
* git-p4 (in contrib/) updates.
* Git uses gettext to translate its most common interface messages
into the user's language if translations are available and the
locale is appropriately set. Distributors can drop in new PO files
in po/ to add new translations.
* The code to handle username/password for HTTP transaction used in
"git push" & "git fetch" learned to talk "credential API" to
external programs to cache or store them, to allow integration with
platform native keychain mechanisms.
* The prompted input in the terminal use our own getpass() replacement
when possible. HTTP transactions used to ask username without echoing
back what was typed, but with this change you will see it as you type.
* The internal of "revert/cherry-pick" has been tweaked to prepare
building more generic "sequencer" on top of the implementation that
drives them.
* "git rev-parse FETCH_HEAD" after "git fetch" without specifying
what to fetch from the command line will now show the commit that
would be merged if the command were "git pull".
* "git add" learned to stream large files directly into a packfile
instead of writing them into individual loose object files.
* "git checkout -B <current branch> <elsewhere>" is a more intuitive
way to spell "git reset --keep <elsewhere>".
* "git checkout" and "git merge" learned "--no-overwrite-ignore" option
to tell Git that untracked and ignored files are not expendable.
* "git commit --amend" learned "--no-edit" option to say that the
user is amending the tree being recorded, without updating the
commit log message.
* "git commit" and "git reset" re-learned the optimization to prime
the cache-tree information in the index, which makes it faster to
write a tree object out after the index entries are updated.
* "git commit" detects and rejects an attempt to stuff NUL byte in
the commit log message.
* "git commit" learned "-S" to GPG-sign the commit; this can be shown
with the "--show-signature" option to "git log".
* fsck and prune are relatively lengthy operations that still go
silent while making the end-user wait. They learned to give progress
output like other slow operations.
* The set of built-in function-header patterns for various languages
knows MATLAB.
* "git log --format='<format>'" learned new %g[nNeE] specifiers to
show information from the reflog entries when warlking the reflog
(i.e. with "-g").
* "git pull" can be used to fetch and merge an annotated/signed tag,
instead of the tip of a topic branch. The GPG signature from the
signed tag is recorded in the resulting merge commit for later
auditing.
* "git log" learned "--show-signature" option to show the signed tag
that was merged that is embedded in the merge commit. It also can
show the signature made on the commit with "git commit -S".
* "git branch --edit-description" can be used to add descriptive text
to explain what a topic branch is about.
* "git fmt-merge-msg" learned to take the branch description into
account when preparing a merge summary that "git merge" records
when merging a local branch.
* "git request-pull" has been updated to convey more information
useful for integrators to decide if a topic is worth merging and
what is pulled is indeed what the requestor asked to pull,
including:
- the tip of the branch being requested to be merged;
- the branch description describing what the topic is about;
- the contents of the annotated tag, when requesting to pull a tag.
* "git pull" learned to notice 'pull.rebase' configuration variable,
which serves as a global fallback for setting 'branch.<name>.rebase'
configuration variable per branch.
* "git tag" learned "--cleanup" option to control how the whitespaces
and empty lines in tag message are cleaned up.
* "gitweb" learned to show side-by-side diff.
Also contains minor documentation updates and code clean-ups.
Fixes since v1.7.8
------------------
Unless otherwise noted, all the fixes since v1.7.8 in the maintenance
releases are contained in this release (see release notes to them for
details).
----------------------------------------------------------------
Changes since v1.7.9-rc0 are as follows:
Ben Walton (1):
Use perl instead of sed for t8006-blame-textconv test
Carlos Martín Nieto (1):
archive: re-allow HEAD:Documentation on a remote invocation
Clemens Buchacher (1):
credentials: unable to connect to cache daemon
Jeff King (5):
send-email: multiedit is a boolean config option
attr: don't confuse prefixes with leading directories
attr: drop misguided defensive coding
attr: fix leak in free_attr_elem
thin-pack: try harder to use preferred base objects as base
Junio C Hamano (11):
attr.c: make bootstrap_attr_stack() leave early
attr.c: clarify the logic to pop attr_stack
Documentation: rerere's rr-cache auto-creation and rerere.enabled
Prepare for 1.7.6.6
Prepare for 1.7.7.6
Prepare for 1.7.8.4
request-pull: use the real fork point when preparing the message
Update draft release notes to 1.7.6.6
Update draft release notes to 1.7.7.6
Update draft release notes to 1.7.8.4
Git 1.7.9-rc1
Matthieu Moy (1):
gitweb: accept trailing "/" in $project_list
Michael Haggerty (3):
receive-pack: move more work into write_head_info()
show_ref(): remove unused "flag" and "cb_data" arguments
write_head_info(): handle "extra refs" locally
Nguyễn Thái Ngọc Duy (1):
t2203: fix wrong commit command
Sebastian Schuberth (2):
t9200: On MSYS, do not pass Windows-style paths to CVS
git-cvsexportcommit: Fix calling Perl's rel2abs() on MSYS
Thomas Rast (1):
mailinfo documentation: accurately describe non -k case
^ 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