* locate commit by file
From: Ittay Dror @ 2008-11-04 8:11 UTC (permalink / raw)
To: Git Mailing List
Hi,
Given a file, is there an easy way (e.g., not bisectig) to find the
latest commit where the file content is the same?
Meaning: I have a file /tmp/A and I want to file the latest commit where
a/b/A is identical (content wise) to /tmp/A.
Thank you,
Ittay
--
--
Ittay Dror <ittay.dror@gmail.com>
^ permalink raw reply
* Re: [RFC PATCH] gitweb: Support filtering projects by .htaccess files.
From: Francis Galiegue @ 2008-11-04 7:42 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Alexander Gavrilov, git
In-Reply-To: <200811040124.36708.jnareb@gmail.com>
Le mardi 04 novembre 2008, Jakub Narebski a écrit :
[...]
> >
> > As to what repository is accessible to whom, does gitweb really have
> > an internal mechanism for this? Wouldn't it be "better" is privately
> > accessible projects were available on another website to start with?
>
> The problem is that Apache has to decide whether to deny or grant access
> based on URL, not on path in filesystem. Perhaps that is possible...
>
It is, with <Location> or <LocationMatch>. You can use mod_access directives
within these (or mod_auth* ones).
--
Francis Galiegue, fg@one2team.com
[ATTENTION - CHANGEMENT D'ADRESSE !]
40 av Raymond Poincaré, 75016 PARIS
+33178945570, +33683877875
^ permalink raw reply
* Re: Repo corrupted somehow?
From: Andrew Arnott @ 2008-11-04 7:34 UTC (permalink / raw)
To: git
In-Reply-To: <216e54900811032309s51c8cb1fr64054ff18c450b1d@mail.gmail.com>
I guess I was still in the middle of a rebase. git rebase --abort
sort of ultimately fixed it.
On Mon, Nov 3, 2008 at 11:09 PM, Andrew Arnott <andrewarnott@gmail.com> wrote:
> I was just git commit'ing, and then I was doing a git rebase to squash
> several commits into one when the rebase failed. I then did a
> git checkout -f master
> git reset --hard
> but no matter what I do, git thinks that several files have changed.
> The diff shows all the lines in these several files removed and then
> added, yet without any changes made to them. git reset --hard doesn't
> revert the change. When I jump around history with git checkout these
> files remain in their "changed" state. I even tried "git clone" to
> create a whole new repo, but one of these several files STILL
> registered as changed before I made any changes.
>
> Any idea what's wrong and how to recover?
>
> Observe the below command buffer: (I can upload my repo so you can
> clone it and perhaps repro it if you want).
>
> Andrew@LACKY /c/git/dotnetoauth
> $ git status
> # On branch master
> # Changed but not updated:
> # (use "git add <file>..." to update what will be committed)
> #
> # modified: tools/Documentation.targets
> # modified: tools/DotNetOpenAuth.Common.Settings.targets
> # modified: tools/DotNetOpenAuth.Versioning.targets
> # modified:
> tools/Sandcastle/Presentation/vs2005/Content/reference_content.xml
> # modified: tools/libcheck.ps1
> # modified: tools/sandcastle.targets
> #
> no changes added to commit (use "git add" and/or "git commit -a")
>
> Andrew@LACKY /c/git/dotnetoauth
> $ git reset --hard
> HEAD is now at 13d37b8 Patching up the bad merges in the phases.
>
> Andrew@LACKY /c/git/dotnetoauth
> $ git status
> # On branch master
> # Changed but not updated:
> # (use "git add <file>..." to update what will be committed)
> #
> # modified: tools/Documentation.targets
> # modified: tools/DotNetOpenAuth.Common.Settings.targets
> # modified: tools/DotNetOpenAuth.Versioning.targets
> # modified:
> tools/Sandcastle/Presentation/vs2005/Content/reference_content.xml
> # modified: tools/libcheck.ps1
> # modified: tools/sandcastle.targets
> #
> no changes added to commit (use "git add" and/or "git commit -a")
>
^ permalink raw reply
* [PATCH v2 1/2] contrib/hooks/post-receive-email: Put rev display in separate function
From: Pete Harlan @ 2008-11-04 7:19 UTC (permalink / raw)
To: Andy Parkins, git; +Cc: Pete Harlan
In-Reply-To: <7v7i7kthkc.fsf@gitster.siamese.dyndns.org>
The display of a revision in an email-appropriate format is done in
two places with similar code. In preparation for making that display
more complex, move it into a separate function that handles both cases.
Signed-off-by: Pete Harlan <pgit@pcharlan.com>
---
contrib/hooks/post-receive-email | 41 +++++++++++++++++++++++++++++--------
1 files changed, 32 insertions(+), 9 deletions(-)
diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email
index 4136895..2cd373d 100644
--- a/contrib/hooks/post-receive-email
+++ b/contrib/hooks/post-receive-email
@@ -224,13 +224,7 @@ generate_create_branch_email()
echo ""
echo $LOGBEGIN
- # This shows all log entries that are not already covered by
- # another ref - i.e. commits that are now accessible from this
- # ref that were previously not accessible
- # (see generate_update_branch_email for the explanation of this
- # command)
- git rev-parse --not --branches | grep -v $(git rev-parse $refname) |
- git rev-list --pretty --stdin $newrev
+ show_new_revisions
echo $LOGEND
}
@@ -390,8 +384,7 @@ generate_update_branch_email()
echo ""
echo $LOGBEGIN
- git rev-parse --not --branches | grep -v $(git rev-parse $refname) |
- git rev-list --pretty --stdin $oldrev..$newrev
+ show_new_revisions
# XXX: Need a way of detecting whether git rev-list actually
# outputted anything, so that we can issue a "no new
@@ -591,6 +584,36 @@ generate_delete_general_email()
echo $LOGEND
}
+
+# --------------- Miscellaneous utilities
+
+#
+# Show new revisions as the user would like to see them in the email.
+#
+show_new_revisions()
+{
+ # This shows all log entries that are not already covered by
+ # another ref - i.e. commits that are now accessible from this
+ # ref that were previously not accessible
+ # (see generate_update_branch_email for the explanation of this
+ # command)
+
+ # Revision range passed to rev-list differs for new vs. updated
+ # branches.
+ if [ "$change_type" = create ]
+ then
+ # Show all revisions exclusive to this (new) branch.
+ revspec=$newrev
+ else
+ # Branch update; show revisions not part of $oldrev.
+ revspec=$oldrev..$newrev
+ fi
+
+ git rev-parse --not --branches | grep -v $(git rev-parse $refname) |
+ git rev-list --pretty --stdin $revspec
+}
+
+
send_mail()
{
if [ -n "$envelopesender" ]; then
--
1.6.0.3.533.ge0502
^ permalink raw reply related
* [PATCH v2 2/2] contrib/hooks/post-receive-email: Make revision display configurable
From: Pete Harlan @ 2008-11-04 7:19 UTC (permalink / raw)
To: Andy Parkins, git; +Cc: Pete Harlan
In-Reply-To: <7v7i7kthkc.fsf@gitster.siamese.dyndns.org>
Add configuration option hooks.showrev, letting the user override how
revisions will be shown in the commit email.
Signed-off-by: Pete Harlan <pgit@pcharlan.com>
---
contrib/hooks/post-receive-email | 18 +++++++++++++++++-
1 files changed, 17 insertions(+), 1 deletions(-)
diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email
index 2cd373d..28a3c0e 100644
--- a/contrib/hooks/post-receive-email
+++ b/contrib/hooks/post-receive-email
@@ -38,6 +38,12 @@
# hooks.emailprefix
# All emails have their subjects prefixed with this prefix, or "[SCM]"
# if emailprefix is unset, to aid filtering
+# hooks.showrev
+# The shell command used to format each revision in the email, with
+# "%s" replaced with the commit id. Defaults to "git rev-list -1
+# --pretty %s", displaying the commit id, author, date and log
+# message. To list full patches separated by a blank line, you
+# could set this to "git show -C %s; echo".
#
# Notes
# -----
@@ -610,7 +616,16 @@ show_new_revisions()
fi
git rev-parse --not --branches | grep -v $(git rev-parse $refname) |
- git rev-list --pretty --stdin $revspec
+ if [ -z "$custom_showrev" ]
+ then
+ git rev-list --pretty --stdin $revspec
+ else
+ git rev-list --stdin $revspec |
+ while read onerev
+ do
+ eval $(printf "$custom_showrev" $onerev)
+ done
+ fi
}
@@ -650,6 +665,7 @@ recipients=$(git config hooks.mailinglist)
announcerecipients=$(git config hooks.announcelist)
envelopesender=$(git config hooks.envelopesender)
emailprefix=$(git config hooks.emailprefix || echo '[SCM] ')
+custom_showrev=$(git config hooks.showrev)
# --- Main loop
# Allow dual mode: run from the command line just like the update hook, or
--
1.6.0.3.533.ge0502
^ permalink raw reply related
* [PATCH v2 0/2] post-receive-email configurable rev display
From: Pete Harlan @ 2008-11-04 7:19 UTC (permalink / raw)
To: Andy Parkins, git; +Cc: Pete Harlan
In-Reply-To: <7v7i7kthkc.fsf@gitster.siamese.dyndns.org>
This is the second version of the user-configurable revision display
patch. The first version decreased the efficiency of the default
case, while this avoids it thanks to a suggestion by Junio.
The first version of this patch also failed to customize the display
of revisions included in newly-created branches; this version displays
those revisions in the same manner as for updated branches.
The two places (new vs. updated branches) where the original code
displayed revisions used similar code. The first patch in this series
factors that out to a separate routine that handles both cases, in
order to avoid duplicating the code introduced in the second patch.
Pete Harlan (2):
contrib/hooks/post-receive-email: Put rev display in separate
function
contrib/hooks/post-receive-email: Make revision display configurable
contrib/hooks/post-receive-email | 57 ++++++++++++++++++++++++++++++++------
1 files changed, 48 insertions(+), 9 deletions(-)
^ permalink raw reply
* Repo corrupted somehow?
From: Andrew Arnott @ 2008-11-04 7:09 UTC (permalink / raw)
To: git
I was just git commit'ing, and then I was doing a git rebase to squash
several commits into one when the rebase failed. I then did a
git checkout -f master
git reset --hard
but no matter what I do, git thinks that several files have changed.
The diff shows all the lines in these several files removed and then
added, yet without any changes made to them. git reset --hard doesn't
revert the change. When I jump around history with git checkout these
files remain in their "changed" state. I even tried "git clone" to
create a whole new repo, but one of these several files STILL
registered as changed before I made any changes.
Any idea what's wrong and how to recover?
Observe the below command buffer: (I can upload my repo so you can
clone it and perhaps repro it if you want).
Andrew@LACKY /c/git/dotnetoauth
$ git status
# On branch master
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
#
# modified: tools/Documentation.targets
# modified: tools/DotNetOpenAuth.Common.Settings.targets
# modified: tools/DotNetOpenAuth.Versioning.targets
# modified:
tools/Sandcastle/Presentation/vs2005/Content/reference_content.xml
# modified: tools/libcheck.ps1
# modified: tools/sandcastle.targets
#
no changes added to commit (use "git add" and/or "git commit -a")
Andrew@LACKY /c/git/dotnetoauth
$ git reset --hard
HEAD is now at 13d37b8 Patching up the bad merges in the phases.
Andrew@LACKY /c/git/dotnetoauth
$ git status
# On branch master
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
#
# modified: tools/Documentation.targets
# modified: tools/DotNetOpenAuth.Common.Settings.targets
# modified: tools/DotNetOpenAuth.Versioning.targets
# modified:
tools/Sandcastle/Presentation/vs2005/Content/reference_content.xml
# modified: tools/libcheck.ps1
# modified: tools/sandcastle.targets
#
no changes added to commit (use "git add" and/or "git commit -a")
^ permalink raw reply
* RE: why not TortoiseGit
From: Li Frank @ 2008-11-04 6:36 UTC (permalink / raw)
To: Nigel Magnay; +Cc: Scott Chacon, Andreas Ericsson, Ian Hilt, git
In-Reply-To: <320075ff0811030200q606b76a8i16496cf7b8b1b7d2@mail.gmail.com>
I also think it is best choose base on Tortoise SVN. TortoriseGIt
should be in windows platform only because it is extension of explore.
Best regards
Frank Li
-----Original Message-----
From: Nigel Magnay [mailto:nigel.magnay@gmail.com]
Sent: Monday, November 03, 2008 6:00 PM
To: Li Frank-B20596
Cc: Scott Chacon; Andreas Ericsson; Ian Hilt; git@vger.kernel.org
Subject: Re: why not TortoiseGit
> I read some code of TortoiseSVN and TortoiseHg Code.
> At beginning, TortoiseGit can git command to get information like
Qgit.
> After linkable library ready, replace "git command".
>
> I think TortoiseGit can start base on below way.
>
> 1. Base on TortoiseHg, It is python Script. Replace below hg
> operator with Git.
> 2. Base on TortoiseSVN, It is developed with C++. Need VS2008.
> ToritoiseSVN provide some built in diff and merge tools.
> 3. Base on Qgit, which provide some basic UI, such comment dialogbox,
> history view and file annotate.
>
>
TortoiseSVN is a good place to start because it separates out the
windows icon decorators into a separate DLL (shared with TortoiseCVS).
This is significant, as these are a finite resource in the windows
shell, and so having a TortoiseSVN + TortoiseGIT on one machine and you
might run out, and I'd imagine lots of people wanting both.
On the minus side, building (Tortoise)SVN requires a lot of environment
setup just to get it to build - most of which can be immediately thrown
away as it's specific to SVN.
But it doesn't look like a hard project to me, just requires stripping
out a lot of junk and re-patching callouts to a git executable (which
could be the standard git tools) and a minimal git library that knows if
files are dirty.
^ permalink raw reply
* Re: Intensive rename detection
From: Andrew Arnott @ 2008-11-04 6:36 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Linus Torvalds, git
In-Reply-To: <20081104061647.GA18297@coredump.intra.peff.net>
Yes, on git status. I'm afraid I don't know how to look up the
reference you gave.
On Mon, Nov 3, 2008 at 10:16 PM, Jeff King <peff@peff.net> wrote:
> On Mon, Nov 03, 2008 at 10:02:37PM -0800, Andrew Arnott wrote:
>
>> Hmmm.... actually on second run I am still getting the too many files
>> warning. I put the [diff] section in a ~/.gitconfig file, a
>> .gitconfig file in the root of my repo, and in the .git/config file,
>> but none of them seem to get rid of the message.
>
> Where are you getting the warning? On "git status"?
>
> If so, then this is an instance of the problem I mentioned here:
>
> [PATCH v3 7/8] wt-status: load diff ui config
> 20081026044935.GG21047@coredump.intra.peff.net
>
> (sorry, I would link to gmane, but it seems to be down at the moment).
> Junio, maybe it is worth applying after all (we could also do just the
> diff "basic" config instead).
>
> -Peff
>
^ permalink raw reply
* Re: Intensive rename detection
From: Jeff King @ 2008-11-04 6:16 UTC (permalink / raw)
To: Andrew Arnott; +Cc: Junio C Hamano, Linus Torvalds, git
In-Reply-To: <216e54900811032202h5c82e3a9j30100e5b82f6a16a@mail.gmail.com>
On Mon, Nov 03, 2008 at 10:02:37PM -0800, Andrew Arnott wrote:
> Hmmm.... actually on second run I am still getting the too many files
> warning. I put the [diff] section in a ~/.gitconfig file, a
> .gitconfig file in the root of my repo, and in the .git/config file,
> but none of them seem to get rid of the message.
Where are you getting the warning? On "git status"?
If so, then this is an instance of the problem I mentioned here:
[PATCH v3 7/8] wt-status: load diff ui config
20081026044935.GG21047@coredump.intra.peff.net
(sorry, I would link to gmane, but it seems to be down at the moment).
Junio, maybe it is worth applying after all (we could also do just the
diff "basic" config instead).
-Peff
^ permalink raw reply
* Re: Intensive rename detection
From: Andrew Arnott @ 2008-11-04 6:02 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <216e54900811032119h4cb51327v2d85712acc444185@mail.gmail.com>
Hmmm.... actually on second run I am still getting the too many files
warning. I put the [diff] section in a ~/.gitconfig file, a
.gitconfig file in the root of my repo, and in the .git/config file,
but none of them seem to get rid of the message.
I'm running git version 1.5.5.1015.g9d258
Is that too old for this removal of a file rename limit?
On Mon, Nov 3, 2008 at 9:19 PM, Andrew Arnott <andrewarnott@gmail.com> wrote:
> Awesome. Per Linus' tip, I just noticed at the top of a long list of
> messages git said:
> warning: too many files, skipping inexact rename detection
>
> So I added the config file change, and that did the trick. Thanks, everyone!
>
> Here's a related but slightly different question: I've been stashing
> and unstashing in the midst of all these renames and refactoring, and
> now I'm left with some files listed in git status 3 times. I
> understand why this is, but I don't know the best way to proceed. Git
> is telling me:
>
> $ git status | grep MessageBase
> src/DotNetOAuth/Messages/MessageBase.cs: needs merge
> src/DotNetOAuth/OAuth/Messages/MessageBase.cs: needs merge
> src/DotNetOpenAuth/Messages/MessageBase.cs: needs merge
> # unmerged: src/DotNetOAuth/Messages/MessageBase.cs
> # unmerged: src/DotNetOAuth/OAuth/Messages/MessageBase.cs
> # unmerged: src/DotNetOpenAuth/Messages/MessageBase.cs
>
> I want to end up with MessageBase.cs in
> src/DotNetOpenAuth/OAuth/Messages/MessageBase.cs, which ironically is
> none of these three. And the couple of lines that changed in the file
> need to be merged. Only two of these listed files exist on disk. How
> can I best leverage git to merge the two files on disk while moving it
> to a new location?
>
>> On Mon, Nov 3, 2008 at 8:22 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>>>
>>>
>>> On Mon, 3 Nov 2008, Andrew Arnott wrote:
>>> >
>>> > I'm refactoring a library including renaming both files and
>>> > directories. A few lines of each file are also changed, but they are
>>> > substantially unchanged in content. I've done a git add to put all my
>>> > changes into the index, but a git status shows that git only detected
>>> > a few of the renames... most of them are delete-add operations. Is
>>> > there anything I can do to help git recognize the rename so that
>>> > history is preserved across this commit?
>>>
>>> How many renames do you have? Modern versions of git will do any number of
>>> exact renames, but the (rather expensive) inexact rename detection has a
>>> default limit of something fairly small.
>>>
>>> You could try adding
>>>
>>> [diff]
>>> renamelimit=0
>>>
>>> to your ~/.gitconfig file. It can be quite expensive though.
>>>
>>> Linus
>>
>
^ permalink raw reply
* Re: How to send patch series without storing them to disk?
From: Liu Yubao @ 2008-11-04 6:01 UTC (permalink / raw)
To: Ian Hilt; +Cc: git
In-Reply-To: <alpine.LFD.2.00.0811032242080.1791@sys-0.hiltweb.site>
Ian Hilt wrote:
> On Mon, 3 Nov 2008, Liu Yubao wrote:
>> Hi,
>> I tried to send one patch using git-send-email, it reported "Syntax: AUTH mechanism".
>> git send-email --from <myemail> --to <my-another-email> \
>> --smtp-pass <mypass> --smtp-user <myaccount> \
>> --smtp-server <the-smtp-server> \
>> --smtp-encryption auth \
>> 0001-just-a-test.patch
>>
>> The parameters about smtp are right, I tested with msmtp. What's wrong?
>>
>> I have MIME::Base64 and Authen::SASL installed and the smtp server doesn't use
>> ssl and tls.
>
> Try removing --smtp-encryption and add --envelope-sender <youremail>.
>
I traced the related Perl modules and found Authen::SASL in Ubuntu Gutsy is buggy,
the problem is resolved after I install the module from CPAN.
>
> Ian
>
^ permalink raw reply
* Re: libxdiff and patience diff
From: Johannes Schindelin @ 2008-11-04 5:39 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: davidel, Git ML
In-Reply-To: <20081104004001.GB29458@artemis.corp>
Hi,
On Tue, 4 Nov 2008, Pierre Habouzit wrote:
> I've been working tonight, trying to make libxdiff support the patience
> diff algorithm, but I've totally failed, because I _thought_ I
> understood what xdl_split was doing, but it appears I don't.
I thought about it, too, at the GitTogether, although I want to finish my
jGit diff first.
The main idea I had about patience diff is that you can reuse a lot of
functions in libxdiff.
But the requirement of taking just unique lines/hashes into account, and
_after_ splitting up, _again_ determine uniqueness _just_ in the
between-hunk part made me think that it may be wiser to have a separate
function for the patience diff stuff.
Basically, you would start to have libxdiff split the lines and hash them
as normal, but then determine the unique hashes (I'd start with the
smaller text, just to have a better chance to end up with unique hashes).
Once they are determined, you can search for those exact lines (hash
first) in the post-document.
Once that is done, you'd have to find the longest common subsequence,
which you could do using the existing infrastructure, but that would
require more work (as we already know the lines are unique).
After that, you would have to recurse to the same algorithm _between_
known chunks. Eventually, that would have to resort to classical libxdiff
(if there are no, or not enough, unique lines).
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Jeff King @ 2008-11-04 5:20 UTC (permalink / raw)
To: Junio C Hamano
Cc: Pierre Habouzit, Sam Vilain, git, Johannes Schindelin,
Scott Chacon, Tom Preston-Werner, J.H., Christian Couder,
Kai Blin
In-Reply-To: <7v4p2ov0zt.fsf@gitster.siamese.dyndns.org>
On Mon, Nov 03, 2008 at 03:33:10PM -0800, Junio C Hamano wrote:
> By the way, didn't we add a feature to let you say "git push $there :"
> which is to do what "git push --matching $there" would do?
Oh, indeed: a83619d (add special "matching refs" refspec) from April.
So given that, I think my arguments for "--matching" are pointless.
-Peff
^ permalink raw reply
* Re: Intensive rename detection
From: Andrew Arnott @ 2008-11-04 5:19 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <216e54900811032107p159e98ecn8958f0a78efde8f2@mail.gmail.com>
Awesome. Per Linus' tip, I just noticed at the top of a long list of
messages git said:
warning: too many files, skipping inexact rename detection
So I added the config file change, and that did the trick. Thanks, everyone!
Here's a related but slightly different question: I've been stashing
and unstashing in the midst of all these renames and refactoring, and
now I'm left with some files listed in git status 3 times. I
understand why this is, but I don't know the best way to proceed. Git
is telling me:
$ git status | grep MessageBase
src/DotNetOAuth/Messages/MessageBase.cs: needs merge
src/DotNetOAuth/OAuth/Messages/MessageBase.cs: needs merge
src/DotNetOpenAuth/Messages/MessageBase.cs: needs merge
# unmerged: src/DotNetOAuth/Messages/MessageBase.cs
# unmerged: src/DotNetOAuth/OAuth/Messages/MessageBase.cs
# unmerged: src/DotNetOpenAuth/Messages/MessageBase.cs
I want to end up with MessageBase.cs in
src/DotNetOpenAuth/OAuth/Messages/MessageBase.cs, which ironically is
none of these three. And the couple of lines that changed in the file
need to be merged. Only two of these listed files exist on disk. How
can I best leverage git to merge the two files on disk while moving it
to a new location?
> On Mon, Nov 3, 2008 at 8:22 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>>
>>
>> On Mon, 3 Nov 2008, Andrew Arnott wrote:
>> >
>> > I'm refactoring a library including renaming both files and
>> > directories. A few lines of each file are also changed, but they are
>> > substantially unchanged in content. I've done a git add to put all my
>> > changes into the index, but a git status shows that git only detected
>> > a few of the renames... most of them are delete-add operations. Is
>> > there anything I can do to help git recognize the rename so that
>> > history is preserved across this commit?
>>
>> How many renames do you have? Modern versions of git will do any number of
>> exact renames, but the (rather expensive) inexact rename detection has a
>> default limit of something fairly small.
>>
>> You could try adding
>>
>> [diff]
>> renamelimit=0
>>
>> to your ~/.gitconfig file. It can be quite expensive though.
>>
>> Linus
>
^ permalink raw reply
* Re: CRLF support bugs (was: Re: .gitattributes glob matching broken)
From: Jeff King @ 2008-11-04 5:14 UTC (permalink / raw)
To: Hannu Koivisto; +Cc: git
In-Reply-To: <83y700alzf.fsf_-_@kalahari.s2.org>
On Mon, Nov 03, 2008 at 05:05:24PM +0200, Hannu Koivisto wrote:
> I suspect one part of that "oddness" was caused by git applying its
> heuristics in checkout as it doesn't use .gitattributes at that
> time.
It _does_ apply them in checkout, you just didn't have a .gitattributes
file yet. So it is part of the same problem.
> For example, it seems that it recognized some of my .sh
> files as text files and the rest as binary files. I suppose I was
> correct to assume that it would be stupid to rely on git guessing
> file type and the only sensible way is to use .gitattributes. If
I think it depends on what's in your scripts, since many people have not
had trouble with the auto-detection. Perhaps some are UTF-16 which
contain NULs?
If the auto-detection is not working, I am sure people would love to see
samples of what fooled it (since it is, after all, just a guess, and we
would like to make the guess more accurate).
> > To "fix" this, you can then do a "git reset --hard" which will respect
> > your .gitattributes (since it is now checked out). And further file
> > creation and checkout should work OK.
>
> Since I'm trying to launch git in a company environment, I think I
> can't rely on people remembering to do that.
Oh, absolutely. I think this is a shortcoming in git. The reset is
simply a workaround until it is actually fixed.
> Actually, even if .gitattributes were applied in checkout, I think
> the whole CRLF support is broken by design because people will have
> to remember to use -n in clone, then enable core.autocrlf support
> and then checkout. This makes it unneccessarily complicated to
Yes, that is a little bit annoying. I think there are four options:
- people set core.autocrlf in their global ~/.gitconfig. The downside,
as you mentioned, is that you might not want it for all projects
- clone should take an extra "options" parameter which can set this up
after doing the 'init'. Like:
git clone -O core.autocrlf=true /path/to/repo
- after setting autocrlf, people need to tell git to re-checkout with
the updated settings. I don't know of a straightforward way to tell
git everything needs to be updated. So I would do:
git ls-files | xargs touch
git reset --hard
which is not ideal. Probably some sort of "re-checkout" option to
git-checkout would be better.
- you could do this "re-checkout" automagically when core.autocrlf is
set via "git config". There are two obvious problems with this
magic, though:
- that may not be what the user wants, if they have work in
progress in the directory. And normally calling "git config"
has no such side effects, so it is certainly unexpected.
- we don't even know when the config is updated, since the user
may simply edit the file behind git's back
So that is a little too magic for my taste.
> I think CRLF conversion support should have some attribute (be it
> .gitattributes attribute or something else) that is somehow
> inherited from the parent repository. It would basically say that
> "you should use platform's native line end type for text files with
> this repository and its children". To go with that, one would
> maybe have a configuration option to tell what that platform
> default line end type is (just in case someone wants to pretend
> Cygwin is Unix or something like that).
I think others have complained before about something like this, in that
it really is a _local_ decision and not a _project_ decision to make. I
am fortunate enough to work exclusively on platforms with sane line
endings, so I don't know what is normal.
But if you really wanted to do such a thing for some set of corporate
users, maybe it would make sense to have a "clone" hook that runs after
init and can set up any relevant config (e.g., by copying certain config
values from the parent repo).
-Peff
^ permalink raw reply
* Re: Merging two projects
From: Jeff King @ 2008-11-04 4:56 UTC (permalink / raw)
To: Andrew Arnott; +Cc: git
In-Reply-To: <216e54900811031933n346e8c68se9226e79366c3eb6@mail.gmail.com>
On Mon, Nov 03, 2008 at 07:33:21PM -0800, Andrew Arnott wrote:
> I have two projects, both with histories, that I want to merge into
> just one library. I'd like to preserve both histories, perhaps as if
> there were two branches being merged into one. (Although each project
> has its own branches that will make the history interesting).
>
> Is there a standard way to do this?
You have two options:
- just merge the history as if they were two branches:
# make a new combined repo
mkdir merged && cd merged && git init
# pull in each library
for lib in lib1 lib2; do
git fetch /path/to/$lib master:$lib
git checkout $lib
# do any pre-merging fixups
mkdir $lib
mv * $lib
git add -u
git add $lib
git commit -m "move files into $lib in preparation for project merge"
done
# and then merge; order isn't really important
git checkout lib1
git merge lib2
This method is nice because it preserves the original histories, and
you can still merge from the original projects (if people are still
working on them as individual projects).
Note that this is basically what the subtree merge strategy does, so
you could also use that. I showed all the steps here to give a sense
of what is going on, and because you might want to do additional
fixups besides moving files into the subtree.
- The other alternative is rewriting the history. The advantage here
is that the history looks as if the projects had always been part of
the repo, so there is no big rename event. You can even annotate the
commit messages to indicate which project is being worked on.
The downside, of course, is that having rewritten history, merges
with the original project become more difficult. But that is not a
problem if you are going to throw away the original repositories.
You can accomplish this with filter-branch:
mkdir merged && cd merged && git init
for lib in lib1 lib2; do
git fetch /path/to/$lib master:$lib
git checkout $lib
git filter-branch -f \
--index-filter '
git ls-files -s |
sed "s,\t,&'$lib'/," |
GIT_INDEX_FILE=$GIT_INDEX_FILE.new \
git update-index --index-info &&
mv $GIT_INDEX_FILE.new $GIT_INDEX_FILE' \
--msg-filter "sed '1s/^/[$lib] /'" \
$lib
done
and then merge the resulting branches as usual.
Hope that helps.
-Peff
^ permalink raw reply
* Re: [Announce] teamGit v0.0.4
From: Abhijit Bhopatkar @ 2008-11-04 4:43 UTC (permalink / raw)
To: Alex Riesen; +Cc: Matthieu Moy, git
In-Reply-To: <20081103182834.GA4180@blimp.localdomain>
On Mon, Nov 3, 2008 at 11:58 PM, Alex Riesen <raa.lkml@gmail.com> wrote:
> Abhijit Bhopatkar, Mon, Nov 03, 2008 14:35:24 +0100:
>> teamGit is a GUI for git,
>> in its final roadmap it aims to aid small closed teams to use git,
>
> What special features does it offer to aid small closed teams?
> Why are they "closed"?
Opps s/closed/close :D , i didn't mean closed vs open etc.
Close means physically close or atleast on the same lan/intranet.
Currently it has no such features as i am concentrating on getting the
base right.
in future i plan to add collaboration facilities like auto
push/pull/rebase to central branch,
auto remote branch management etc.
Abhijt
^ permalink raw reply
* Re: Intensive rename detection
From: Jeff King @ 2008-11-04 4:31 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andrew Arnott, git
In-Reply-To: <alpine.LFD.2.00.0811032021210.3419@nehalem.linux-foundation.org>
On Mon, Nov 03, 2008 at 08:22:34PM -0800, Linus Torvalds wrote:
> How many renames do you have? Modern versions of git will do any number of
> exact renames, but the (rather expensive) inexact rename detection has a
> default limit of something fairly small.
I was about to say "git should have complained about turning off the
requested rename detection", but I forgot that we silenced that warning
except for merges.
Maybe it makes sense for "status" or a single "diff" (but definitely not
"log", where it isn't even clear which diff caused it!). I dunno. I find
it clutter for anything except a merge, but if that is in fact what is
happening here, it might have produced one slightly less confused user.
-Peff
^ permalink raw reply
* Re: [PATCH] push: fix local refs update if already up-to-date
From: Jeff King @ 2008-11-04 4:26 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: git, Junio C Hamano
In-Reply-To: <20081104000745.GA28480@localhost>
On Tue, Nov 04, 2008 at 01:07:45AM +0100, Clemens Buchacher wrote:
> git push normally updates local refs only after a successful push. If
> the remote already has the updates -- pushed indirectly through
> another repository, for example -- we forget to update local tracking
> refs.
I think this goal is a good enhancement.
> The hashcpy for new_ref is now executed more often than absolutely
> necessary. But this is not a critical path, right? So I decided to keep
> things simple.
No, I don't think the loop is tight enough to care about an extra
hashcpy. The minimally invasive change would be to just set
ref->new_sha1 in the UPTODATE code path. IOW, just:
diff --git a/builtin-send-pack.c b/builtin-send-pack.c
index 298bd71..b8788f2 100644
--- a/builtin-send-pack.c
+++ b/builtin-send-pack.c
@@ -454,6 +454,7 @@ static int do_send_pack(int in, int out, struct remote *remote, const char *dest
if (!ref->deletion &&
!hashcmp(ref->old_sha1, new_sha1)) {
ref->status = REF_STATUS_UPTODATE;
+ hashcpy(ref->new_sha1, new_sha1);
continue;
}
Your patch makes ref->new_sha1 "valid" for every status case. Ordinarily
I would be in favor of that, since it reduces coupling with other parts
of the code (which have to know _which_ status flags provide a useful
value in ->new_sha1). But in this case, I think the value we would be
sticking in is not necessarily useful for every status flag we end up
setting; so any consumers of the ref structure still need to know which
flags set it. So even though it has a defined value, it is not really
"valid" in all cases.
> @@ -224,7 +224,7 @@ static void update_tracking_ref(struct remote *remote, struct ref *ref)
> {
> struct refspec rs;
>
> - if (ref->status != REF_STATUS_OK)
> + if (ref->status != REF_STATUS_OK && ref->status != REF_STATUS_UPTODATE)
> return;
>
> rs.src = ref->name;
Hmm. I was hoping to see more in update_tracking_ref. With your patch,
we end up calling update_ref for _every_ uptodate ref, which results in
writing a new unpacked ref file for each one. And that _is_ a
performance problem for people with large numbers of refs.
So I think we need a check to make sure we aren't just updating with the
same value. Something like:
diff --git a/builtin-send-pack.c b/builtin-send-pack.c
index 4c17f48..0e66e8f 100644
--- a/builtin-send-pack.c
+++ b/builtin-send-pack.c
@@ -237,8 +237,17 @@ static void update_tracking_ref(struct remote *remote, struct ref *ref)
rs.dst = NULL;
if (!remote_find_tracking(remote, &rs)) {
+ unsigned char old_tracking_sha1[20];
+
if (args.verbose)
fprintf(stderr, "updating local tracking ref '%s'\n", rs.dst);
+
+ if (!resolve_ref(rs.dst, old_tracking_sha1, 0, NULL) ||
+ !hashcmp(old_tracking_sha1, ref->new_sha1)) {
+ free(rs.dst);
+ return;
+ }
+
if (ref->deletion) {
delete_ref(rs.dst, NULL, 0);
} else
Though I am not happy that we have to look up the tracking ref for every
uptodate ref. I think it shouldn't be a big performance problem with
packed refs, though, since they are cached (i.e., we pay only to compare
the hashes, not touch the filesystem for each ref).
> +test_expect_success 'push updates local refs (2)' '
Nit: Just reading the test, it is hard to see what is interesting about
it (though obviously I can blame it back to your commit :) ). Maybe a
more descriptive title like 'push updates uptodate local refs' would
make sense.
-Peff
^ permalink raw reply related
* Re: Intensive rename detection
From: Linus Torvalds @ 2008-11-04 4:23 UTC (permalink / raw)
To: Andrew Arnott; +Cc: git
In-Reply-To: <alpine.LFD.2.00.0811032021210.3419@nehalem.linux-foundation.org>
On Mon, 3 Nov 2008, Linus Torvalds wrote:
>
> You could try adding
>
> [diff]
> renamelimit=0
>
> to your ~/.gitconfig file. It can be quite expensive though.
Oh, and obviously Junio is right that some create/deletes won't be seen as
renames anyway, if you changed enough of the file and/or if the files in
question are so small that they end up being considered rewrites just
because of that.
Linus
^ permalink raw reply
* Re: Intensive rename detection
From: Linus Torvalds @ 2008-11-04 4:22 UTC (permalink / raw)
To: Andrew Arnott; +Cc: git
In-Reply-To: <216e54900811031718o4cc81294sc0c32be1e71b9372@mail.gmail.com>
On Mon, 3 Nov 2008, Andrew Arnott wrote:
>
> I'm refactoring a library including renaming both files and
> directories. A few lines of each file are also changed, but they are
> substantially unchanged in content. I've done a git add to put all my
> changes into the index, but a git status shows that git only detected
> a few of the renames... most of them are delete-add operations. Is
> there anything I can do to help git recognize the rename so that
> history is preserved across this commit?
How many renames do you have? Modern versions of git will do any number of
exact renames, but the (rather expensive) inexact rename detection has a
default limit of something fairly small.
You could try adding
[diff]
renamelimit=0
to your ~/.gitconfig file. It can be quite expensive though.
Linus
^ permalink raw reply
* Re: How to send patch series without storing them to disk?
From: Ian Hilt @ 2008-11-04 4:04 UTC (permalink / raw)
To: Liu Yubao; +Cc: git
In-Reply-To: <490EC57E.4080200@gmail.com>
On Mon, 3 Nov 2008, Liu Yubao wrote:
> Hi,
>
> I want to send patches like this:
>
> git format-patch --stdout --no-color -C --thread -n $oldrev..$newrev | ...send...
>
> It seems git-send-email can't read email from stdin.
Currently there is a discussion on the git mailing list concerning a way
to make the following possible:
git send-email $oldrev..$newrev
Here's some more information,
<http://marc.info/?l=git&w=2&r=1&s=git+send-email&q=b>
Ian
^ permalink raw reply
* Re: How to send patch series without storing them to disk?
From: Ian Hilt @ 2008-11-04 3:50 UTC (permalink / raw)
To: Liu Yubao; +Cc: git
In-Reply-To: <490EC57E.4080200@gmail.com>
On Mon, 3 Nov 2008, Liu Yubao wrote:
> Hi,
>
> I want to send patches like this:
>
> git format-patch --stdout --no-color -C --thread -n $oldrev..$newrev | ...send...
>
> It seems git-send-email can't read email from stdin.
>
>
> I tried to send one patch using git-send-email, it reported "Syntax: AUTH mechanism".
> git send-email --from <myemail> --to <my-another-email> \
> --smtp-pass <mypass> --smtp-user <myaccount> \
> --smtp-server <the-smtp-server> \
> --smtp-encryption auth \
> 0001-just-a-test.patch
>
> The parameters about smtp are right, I tested with msmtp. What's wrong?
>
> I have MIME::Base64 and Authen::SASL installed and the smtp server doesn't use
> ssl and tls.
Try removing --smtp-encryption and add --envelope-sender <youremail>.
Ian
^ permalink raw reply
* Merging two projects
From: Andrew Arnott @ 2008-11-04 3:33 UTC (permalink / raw)
To: git
I have two projects, both with histories, that I want to merge into
just one library. I'd like to preserve both histories, perhaps as if
there were two branches being merged into one. (Although each project
has its own branches that will make the history interesting).
Is there a standard way to do this?
Thanks.
^ 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