* Re: Git Rebase blows away GIT_AUTHOR_NAME
From: Erik Faye-Lund @ 2011-01-14 9:55 UTC (permalink / raw)
To: Tor Arntsen; +Cc: JT Olds, Jeff King, git, torvalds
In-Reply-To: <AANLkTi=PTgmOSC7pRLjujO5fi9Wdp69Jmj4zCkhGSYSz@mail.gmail.com>
(CC'ed Linus, as he wrote mailinfo's sanity-checking -- sorry, forgot
to actually CC him the first time)
On Fri, Jan 14, 2011 at 10:24 AM, Tor Arntsen <tor@spacetec.no> wrote:
> On Fri, Jan 14, 2011 at 09:56, Erik Faye-Lund <kusmabite@gmail.com> wrote:
>> On Fri, Jan 14, 2011 at 9:45 AM, Tor Arntsen <tor@spacetec.no> wrote:
>>> I think I've mentioned this before in another thread, but first/last
>>> name isn't universal, not even within countries where it's the common
>>> form. When I was as student there was a fellow student from another
>>> scandinavian country and his legal, full name consisted of a single
>>> letter.
>>>
>>
>> I'm curious, what Scandinavian country was this? Because as a
>> Norwegian, I know a lot of people from all Scandinavian country, yet
>> I've never heard of such names. In Norway, I the shortest legal name
>> I've ever heard of was five characters.
>
> Sweden (I'm Norwegian too - this guy was a Swede studying in Norway).
> Admittedly I have only that single example, and it was back in the
> late seventies. His name was accepted as legal by Statens Lånekasse
> (bank for students) and when the loans arrived his single-letter name
> would be found at the very end of the long lists of wide listing-paper
> printouts from the bank that was stiched up on the billboard wall
> outside the administration offices. The loans arrived a couple of
> times per year but we always had to go looking - the rest of us were
> just amazed that we could really find that single letter down there
> and he wasn't bs'ing the rest of us about his name.
>
> I'm not sure why there's a 3-letter limit on git author names.. but I
> would suggest it should be set down to 1 letter minimum.. below that
> would, I think, be overdoing it..
>
Linus, you wrote sanity_check (from 2744b23). Do you remember if there
were any specific reason for the minimum length of 3 of an
author-name? It seems that in Sweden, legal names can be even a single
letter (see Tor's comment)...
^ permalink raw reply
* Re: Git Rebase blows away GIT_AUTHOR_NAME
From: Erik Faye-Lund @ 2011-01-14 9:53 UTC (permalink / raw)
To: Tor Arntsen; +Cc: JT Olds, Jeff King, git
In-Reply-To: <AANLkTi=PTgmOSC7pRLjujO5fi9Wdp69Jmj4zCkhGSYSz@mail.gmail.com>
(CC'ed Linus, as he wrote mailinfo's sanity-checking)
On Fri, Jan 14, 2011 at 10:24 AM, Tor Arntsen <tor@spacetec.no> wrote:
> On Fri, Jan 14, 2011 at 09:56, Erik Faye-Lund <kusmabite@gmail.com> wrote:
>> On Fri, Jan 14, 2011 at 9:45 AM, Tor Arntsen <tor@spacetec.no> wrote:
>>> I think I've mentioned this before in another thread, but first/last
>>> name isn't universal, not even within countries where it's the common
>>> form. When I was as student there was a fellow student from another
>>> scandinavian country and his legal, full name consisted of a single
>>> letter.
>>>
>>
>> I'm curious, what Scandinavian country was this? Because as a
>> Norwegian, I know a lot of people from all Scandinavian country, yet
>> I've never heard of such names. In Norway, I the shortest legal name
>> I've ever heard of was five characters.
>
> Sweden (I'm Norwegian too - this guy was a Swede studying in Norway).
> Admittedly I have only that single example, and it was back in the
> late seventies. His name was accepted as legal by Statens Lånekasse
> (bank for students) and when the loans arrived his single-letter name
> would be found at the very end of the long lists of wide listing-paper
> printouts from the bank that was stiched up on the billboard wall
> outside the administration offices. The loans arrived a couple of
> times per year but we always had to go looking - the rest of us were
> just amazed that we could really find that single letter down there
> and he wasn't bs'ing the rest of us about his name.
>
> I'm not sure why there's a 3-letter limit on git author names.. but I
> would suggest it should be set down to 1 letter minimum.. below that
> would, I think, be overdoing it..
>
Linus, you wrote sanity_check (from 2744b23). Do you remember if there
were any specific reason for the minimum length of 3 of an
author-name? It seems that in Sweden, legal names can be even a single
letter (see Tor's comment)...
^ permalink raw reply
* Re: Git Rebase blows away GIT_AUTHOR_NAME
From: Tor Arntsen @ 2011-01-14 9:24 UTC (permalink / raw)
To: kusmabite; +Cc: JT Olds, Jeff King, git
In-Reply-To: <AANLkTimONqL4=E4Unrsj9PU5u57KGXrmO6xWUOCLorgs@mail.gmail.com>
On Fri, Jan 14, 2011 at 09:56, Erik Faye-Lund <kusmabite@gmail.com> wrote:
> On Fri, Jan 14, 2011 at 9:45 AM, Tor Arntsen <tor@spacetec.no> wrote:
>> I think I've mentioned this before in another thread, but first/last
>> name isn't universal, not even within countries where it's the common
>> form. When I was as student there was a fellow student from another
>> scandinavian country and his legal, full name consisted of a single
>> letter.
>>
>
> I'm curious, what Scandinavian country was this? Because as a
> Norwegian, I know a lot of people from all Scandinavian country, yet
> I've never heard of such names. In Norway, I the shortest legal name
> I've ever heard of was five characters.
Sweden (I'm Norwegian too - this guy was a Swede studying in Norway).
Admittedly I have only that single example, and it was back in the
late seventies. His name was accepted as legal by Statens Lånekasse
(bank for students) and when the loans arrived his single-letter name
would be found at the very end of the long lists of wide listing-paper
printouts from the bank that was stiched up on the billboard wall
outside the administration offices. The loans arrived a couple of
times per year but we always had to go looking - the rest of us were
just amazed that we could really find that single letter down there
and he wasn't bs'ing the rest of us about his name.
I'm not sure why there's a 3-letter limit on git author names.. but I
would suggest it should be set down to 1 letter minimum.. below that
would, I think, be overdoing it..
-Tor
^ permalink raw reply
* Re: working with a large repository and git svn
From: Michael Haggerty @ 2011-01-14 9:23 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Ramkumar Ramachandra, Joe Corneli, git,
Love Hörnquist Åstrand
In-Reply-To: <20110114082931.GC11343@burratino>
On 01/14/2011 09:29 AM, Jonathan Nieder wrote:
> . Is svn okay with non-monotonic dates? (If not, then the committer
> date would need to be used.)
Subversion can tolerate non-monotonic dates with one caveat: it breaks
the find-revision-by-date feature (e.g., "svn update -r '{2010-12-25}'")
for the time intervals with non-monotonic dates. This is a seldom-used
feature and therefore its sacrifice is often accepted, for example when
the history of the Subversion project itself was migrated into the
Apache project's Subversion repository.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* bug: request-pull broken when remote name contains a slash
From: Uwe Kleine-König @ 2011-01-14 9:06 UTC (permalink / raw)
To: git
Hello,
the remotes in my linux repo look as follows:
[remote "ptx/ukl"]
url = git://git.pengutronix.de/git/ukl/linux-2.6.git
push = +refs/heads/*:refs/heads/*
fetch = +refs/heads/*:refs/remotes/ptx/ukl/*
[remote "ptx/otheruser"]
url = git://git.pengutronix.de/git/otheruser/linux-2.6.git
fetch = +refs/heads/*:refs/remotes/ptx/otheruser/*
[remote "ptx/yetanotheruser"]
url = git://git.pengutronix.de/git/yetanotheruser/linux-2.6.git
fetch = +refs/heads/*:refs/remotes/ptx/yetanotheruser/*
unfortunately this makes sending request pulls uncomfortable:
ukl@octopus:~/gsrc/linux-2.6$ git request-pull HEAD^ ptx/ukl
The following changes since commit a08948812b30653eb2c536ae613b635a989feb6f:
Merge branch 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/staging (2011-01-10 08:57:46 -0800)
are available in the git repository at:
ptx/ukl mxs/for-2.6.38
...
The reason for that is in git-parse-remote.sh:get_data_source() which
assumes that a remote with a slash is a filename and so get_remote_url
doesn't use $(git config --get "remote.$1.url") but ptx/ukl directly.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: Applying .gitattributes text/eol changes
From: Marc Strapetz @ 2011-01-14 9:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael J Gruber, git
In-Reply-To: <7vd3o01iw9.fsf@alter.siamese.dyndns.org>
>> What do you think about "git checkout --fix-eols" option as an
>> alternative? Its uses cases are more limited, though.
>
> What does it do? "git checkout --fix-eols $path" will overwrite $path
> with the data at $path in the index? Perhaps you can use the "-f" option.
>
> Adding an option to "checkout" might be better than update-index from the
> UI point of view, but the issue is not just "eols". "eol" is a mere
> special case of smudge filter that controls how the contents from the
> repository are modified before getting written out to the working tree.
So there could be a "--thoroughly" option which will skip the stat check
(checkout_entry) and instead perform the procedure already outlined for
rebase:
> open object
> read from the object
> deflate and write to a temporary file
> open the existing file
> read from the file and compare it to the temporary we just wrote
> if same, delete, otherwise rename the temporary file.
AFAIU, this change will effect mainly checkout struct, checkout_entry
and write_entry. write_entry already deals with temporary files, so that
shouldn't be too complex!?
--
Best regards,
Marc Strapetz
=============
syntevo GmbH
http://www.syntevo.com
http://blog.syntevo.com
On 14.01.2011 00:30, Junio C Hamano wrote:
> Marc Strapetz <marc.strapetz@syntevo.com> writes:
>
>> So your suggestion is to fix "git update-index --really-refresh", so
>
> The option is about telling git: "Earlier I promised I wouldn't touch
> these paths by setting their assume-unchanged bit, but I touched them.
> Please refresh the cached stat information in the index, ignoring the
> promise I didn't keep."
>
> I do not think it is a good idea to conflate your "Everything is suspect
> because smudge filter has changed; please recompute all" request into the
> same option. People who use assume-unchanged would probably want "Please
> rescan because I changed smudge filter" request to be carried out while
> still honoring the assume-unchanged bit they set earlier.
>
>> Anyway, I'm still wondering if it will resolve the "git reset --hard"
>> problem of re-checking out every file, even if content is already
>> identical in the working tree. I think that part has to be fixed, too.
>
> There is not much to fix there. If you removed the index, then there is no
> information to tell you that "content is already identical" unless you
> actually check things out and compare. By the time you found it out, you
> already have done the checkout.
>
> IOW, the current code does:
>
> open object
> read from the object
> deflate and write to the destination file
>
> while your "fix" needs to look like this:
>
> open object
> read from the object
> deflate and write to a temporary file
> open the existing file
> read from the file and compare it to the temporary we just wrote
> if same, delete, otherwise rename the temporary file.
>
> just for the rare case where there is an untracked file that the user is
> willing to overwrite (we are discussing "rm .git/index && reset --hard"
> here) happens to have the same contents. Not a good enough reason to add
> unwelcome complexity to the codepath.
>
>> What do you think about "git checkout --fix-eols" option as an
>> alternative? Its uses cases are more limited, though.
>
> What does it do? "git checkout --fix-eols $path" will overwrite $path
> with the data at $path in the index? Perhaps you can use the "-f" option.
>
> Adding an option to "checkout" might be better than update-index from the
> UI point of view, but the issue is not just "eols". "eol" is a mere
> special case of smudge filter that controls how the contents from the
> repository are modified before getting written out to the working tree.
>
>
>
>
^ permalink raw reply
* Re: Git Rebase blows away GIT_AUTHOR_NAME
From: Erik Faye-Lund @ 2011-01-14 8:56 UTC (permalink / raw)
To: Tor Arntsen; +Cc: JT Olds, Jeff King, git
In-Reply-To: <AANLkTikk7Xdiey76Dmy848_B4qNX2-Vbis7p=E8vtNL9@mail.gmail.com>
On Fri, Jan 14, 2011 at 9:45 AM, Tor Arntsen <tor@spacetec.no> wrote:
> On Thu, Jan 13, 2011 at 19:20, Erik Faye-Lund <kusmabite@gmail.com> wrote:
>>[..] Besides, a name of
>> two characters aren't really sane. You'd need at least three
>> characters to form a first/last name pair.
>
> I think I've mentioned this before in another thread, but first/last
> name isn't universal, not even within countries where it's the common
> form. When I was as student there was a fellow student from another
> scandinavian country and his legal, full name consisted of a single
> letter.
>
I'm curious, what Scandinavian country was this? Because as a
Norwegian, I know a lot of people from all Scandinavian country, yet
I've never heard of such names. In Norway, I the shortest legal name
I've ever heard of was five characters.
^ permalink raw reply
* [RFC/PATCH 2/1] fixup! Documentation: start to explain what git replace is for
From: Jonathan Nieder @ 2011-01-14 8:49 UTC (permalink / raw)
To: Maaartin; +Cc: git, Jakub Narebski, Aleksey Shumkin
In-Reply-To: <loom.20110112T232501-316@post.gmane.org>
Some tweaks suggested by Maaartin:
- use a transliteration for Aleksey's name.
- clarify that there will only be one parentless commit in a typical
branch
- use variables so the recipe is easier to test by copy and paste
- remove unintended "-i" argument to sed
While at it, make a few miscellaneous grammar tweaks and make sure
each line of the example raw commit appears on a separate line.
The formatting is still not great for that --- there is too much
space between lines.
Still to do: check whether this actually works and add a test script
to make sure it keeps working.
Improved-by: Maaartin <grajcar1@seznam.cz>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Can be tested with
make -C Documentation git-replace.1
man Documentation/git-replace.1
.
Maaartin wrote:
> Jonathan Nieder writes:
[side note: please do not prune the cc list; I only stumbled on this
message in the online archive by luck]
>> +. The following example comes from ??????? ??????:
>
> I know unicode exists already for many years, but in cygwin I get just a bunch
> of question marks instead of the name. So I'd suggest to replace "Алексей
> Шумкин" by "Alexej Shumkin" or whatever his preferred transcription is.
Makes sense.
>> +<1> Find all parentless commits in the 'master' branch;
>> +for 'master' read the branch holding v2.5 history.
>
> Aren't you later calling it "FIRST" and assuming there's only one?
Hmm. I want to say that there _could_ be multiple parentless commits
in the v2.5 history and we are treating one of them as its root (just
like git master has multiple parentless ancestors but e83c5163 is
conventionally considered its beginning). Not sure how to write that
clearly.
> Isn't the combination of "-i" (=in-place edit) with redirection wrong?
Good catch (the "-i" is a typo).
> +$ objectId=$(git hash-object -t commit -w new)
> +$ git replace FIRST $objectId
>
> This is easier for people just willing to use it without much thinking, and
> also for those having no idea that git-hash-object creates a new object.
Right, thanks.
Documentation/git-replace.txt | 40 ++++++++++++++++++++++------------------
1 files changed, 22 insertions(+), 18 deletions(-)
diff --git a/Documentation/git-replace.txt b/Documentation/git-replace.txt
index 02e5de8..5829901 100644
--- a/Documentation/git-replace.txt
+++ b/Documentation/git-replace.txt
@@ -68,16 +68,17 @@ $ git cat-file commit foo <3>
<2> show information about the true commit 'foo'
<3> show information about the replacement commit 'bar'
-. The following example comes from Алексей Шумкин:
+. The following example comes from Aleksey Shumkin:
+
1.5 years ago I had sources of a project in another version control
system. And I had two branches: v2.4 and v2.5.
-They differed enough at that moment and laid in two different folders.
+They differed enough at that moment and lay in two different folders.
Then I learned about Git and I decided to try to use this DVCS.
I created two git repositories: one for each branch.
-So v2.4 has its own git repo and v2.5 (and above) has another one.
+So v2.4 has one git repo and v2.5 (and above) has another one.
+
-Now I'd like to merge them as v2.5 was a continuous branch from v2.4,
+Now I'd like to merge them as if v2.5 were a continuous development
+from v2.4,
but without rebasing (i.e. without a global change to the v2.5
repository, which already has other branches). It should look like
the last commit of from the v2.4 branch is a parent of the first
@@ -89,25 +90,28 @@ use the more modern replace mechanism. Below are untested step-by-step
instructions.
+
--------------------------------------------------
-$ git rev-list master --parents | grep -v ' ' <1>
-$ git rev-parse v2.4 <2>
-$ git cat-file commit FIRST >tmp <3>
-$ sed -i "/^tree / a \\
-parent $(git rev-parse v2.4)" <tmp >new <4>
-$ git hash-object -t commit -w new <5>
-$ git replace FIRST <object id from hash-object> <6>
-$ git show FIRST
-$ git log --graph --oneline -3 FIRST <7>
+$ git rev-list master --parents | grep -v ' '
+$ first=$(git rev-list master --parents | grep -v ' ') <1>
+$ git rev-parse v2.4 <2>
+$ git cat-file commit $first >tmp <3>
+$ sed "/^tree / a \\
+parent $(git rev-parse v2.4)" <tmp >new <4>
+$ new_commit=$(git hash-object -t commit -w new) <5>
+$ git replace $first $new_commit <6>
+$ git show $first
+$ git log --graph --oneline -3 $first <7>
--------------------------------------------------
+
-<1> Find all parentless commits in the 'master' branch;
-for 'master' read the branch holding v2.5 history.
+<1> List all parentless commits in the 'master' branch and
+call the appropriate one (in this case the only one) $first.
+Instead of 'master' one would use the branch holding v2.5
+history.
<2> Find the last commit of v2.4.
<3> Save the current state of the first commit of v2.5 to a file.
<4> Edit this file, adding 'parent' line between 'tree' and 'author'
-headers, so the header of this file looks like the following:
- tree 13d050266e05f7c66000240814199fcf3b559d43
- parent ada9983c4256f5a7bac1f7f0e29d52011741d6aa
+headers, so the header of this file looks like the following: +
+ tree 13d050266e05f7c66000240814199fcf3b559d43 +
+ parent ada9983c4256f5a7bac1f7f0e29d52011741d6aa +
author Jakub Narebski <jnareb@gmail.com> 1294231771 +0100
<5> Add the newly created object to the repository.
<6> Use it as a replacement.
--
1.7.4.rc2
^ permalink raw reply related
* Re: Git Rebase blows away GIT_AUTHOR_NAME
From: Tor Arntsen @ 2011-01-14 8:45 UTC (permalink / raw)
To: kusmabite; +Cc: JT Olds, Jeff King, git
In-Reply-To: <AANLkTik15iV9SOv6rRL5+DQkAZ4JwBGTS+gqS3nXy2hN@mail.gmail.com>
On Thu, Jan 13, 2011 at 19:20, Erik Faye-Lund <kusmabite@gmail.com> wrote:
>[..] Besides, a name of
> two characters aren't really sane. You'd need at least three
> characters to form a first/last name pair.
I think I've mentioned this before in another thread, but first/last
name isn't universal, not even within countries where it's the common
form. When I was as student there was a fellow student from another
scandinavian country and his legal, full name consisted of a single
letter.
-Tor
^ permalink raw reply
* Re: Applying .gitattributes text/eol changes
From: Michael J Gruber @ 2011-01-14 8:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Marc Strapetz, git
In-Reply-To: <7vd3o01iw9.fsf@alter.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 14.01.2011 00:30:
> Marc Strapetz <marc.strapetz@syntevo.com> writes:
>
>> So your suggestion is to fix "git update-index --really-refresh", so
>
> The option is about telling git: "Earlier I promised I wouldn't touch
> these paths by setting their assume-unchanged bit, but I touched them.
> Please refresh the cached stat information in the index, ignoring the
> promise I didn't keep."
>
> I do not think it is a good idea to conflate your "Everything is suspect
> because smudge filter has changed; please recompute all" request into the
> same option. People who use assume-unchanged would probably want "Please
> rescan because I changed smudge filter" request to be carried out while
> still honoring the assume-unchanged bit they set earlier.
What I meant was to introduce a new option --refresh-stat or something.
We have solved the "stale stat info problem" (changed dev nums after
reboot) in a different way meanwhile, but I think there was a different
case (can't come up with the thread right now) where something like this
could have helped.
>
>> Anyway, I'm still wondering if it will resolve the "git reset --hard"
>> problem of re-checking out every file, even if content is already
>> identical in the working tree. I think that part has to be fixed, too.
>
> There is not much to fix there. If you removed the index, then there is no
> information to tell you that "content is already identical" unless you
> actually check things out and compare. By the time you found it out, you
> already have done the checkout.
>
> IOW, the current code does:
>
> open object
> read from the object
> deflate and write to the destination file
>
> while your "fix" needs to look like this:
>
> open object
> read from the object
> deflate and write to a temporary file
> open the existing file
> read from the file and compare it to the temporary we just wrote
> if same, delete, otherwise rename the temporary file.
>
> just for the rare case where there is an untracked file that the user is
> willing to overwrite (we are discussing "rm .git/index && reset --hard"
> here) happens to have the same contents. Not a good enough reason to add
> unwelcome complexity to the codepath.
>
>> What do you think about "git checkout --fix-eols" option as an
>> alternative? Its uses cases are more limited, though.
>
> What does it do? "git checkout --fix-eols $path" will overwrite $path
> with the data at $path in the index? Perhaps you can use the "-f" option.
>
> Adding an option to "checkout" might be better than update-index from the
> UI point of view, but the issue is not just "eols". "eol" is a mere
> special case of smudge filter that controls how the contents from the
> repository are modified before getting written out to the working tree.
Exactly, this is a more general issue. The typical answer to these
issues is that you change attributes and filters only occasionally, so
the cost of a rm .git/index && git reset --hard is irrelevant. But still
there should be a less scary way of (really) refreshing the index. Also
note that the cost of the command itself is only a part of the picture -
in the OP's case (which is a bit convoluted, of course) "cost" is really
command execution + the cost of the consequences (rebuilding triggered
by unnecessary touches). For the typical use cases, the existing options
and command paths do the perfectly sane and efficient thing.
Michael
^ permalink raw reply
* Re: working with a large repository and git svn
From: Jonathan Nieder @ 2011-01-14 8:29 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Joe Corneli, git, Love Hörnquist Åstrand
In-Reply-To: <20110114080554.GA1735@kytes>
Ramkumar Ramachandra wrote:
> Joe Corneli writes:
>>> I think the state of the art is currently git2svn
>>
>> Thanks, that did indeed work, though, for the record it uses committer
>> name and email in the log that it generates, not author name and
>> email, but no worries!
>
> That should be easy enough to fix with something like this (warning:
> untested). A more elegant solution would actually use some sort of
> user-configurable mapping from Git authors/ committers to SVN authors
> though.
Thanks for the cc. (cc-ing lha, as I should have before.)
I suppose if svn will show only one of the two (committer and author)
then it is better to show the author. Possible complications:
. The author lines in fast-import streams are optional.
. Existing users of the incremental import facility might not want the
meaning of svn:author to change between imports. _If_ that is a
problem then a command-line option to switch behaviors might help.
. Is svn okay with non-monotonic dates? (If not, then the committer
date would need to be used.)
Modulo those complications I like the idea. (Though I haven't read
the implementation, which follows for reference.)
>
> Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
> --8<--
> diff --git a/git2svn b/git2svn
> index 2380775..3856696 100755
> --- a/git2svn
> +++ b/git2svn
> @@ -261,12 +261,8 @@ COMMAND: while (!eof(IN)) {
> $commit{Mark} = $1;
> $next = next_line($IN);
> }
> - if ($next =~ m/author +(.*)/) {
> - $commit{Author} = $1;
> - $next = next_line($IN);
> - }
> - unless ($next =~ m/committer +(.+) +<([^>]+)> +(\d+) +[+-](\d+)$/) {
> - die "missing comitter: $_";
> + unless ($next =~ m/author +(.+) +<([^>]+)> +(\d+) +[+-](\d+)$/) {
> + die "missing author: $_";
> }
>
> $commit{CommitterName} = $1;
> @@ -275,6 +271,9 @@ COMMAND: while (!eof(IN)) {
> $commit{CommitterTZ} = $4;
>
> $next = next_line($IN);
> + if ($next =~ m/committer +(.*)/) {
> + $next = next_line($IN);
> + }
> my $log = read_data($IN, $next);
>
> $next = next_line($IN);
^ permalink raw reply
* Re: working with a large repository and git svn
From: Ramkumar Ramachandra @ 2011-01-14 8:05 UTC (permalink / raw)
To: Joe Corneli; +Cc: git, Jonathan Nieder
In-Reply-To: <AANLkTikCvjDqUpL-=srVKcMQx+NM6bV7FabmJ+4sPqD7@mail.gmail.com>
Hi Joe,
Joe Corneli writes:
> > I think the state of the art is currently git2svn
>
> Thanks, that did indeed work, though, for the record it uses committer
> name and email in the log that it generates, not author name and
> email, but no worries!
That should be easy enough to fix with something like this (warning:
untested). A more elegant solution would actually use some sort of
user-configurable mapping from Git authors/ committers to SVN authors
though.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
--8<--
diff --git a/git2svn b/git2svn
index 2380775..3856696 100755
--- a/git2svn
+++ b/git2svn
@@ -261,12 +261,8 @@ COMMAND: while (!eof(IN)) {
$commit{Mark} = $1;
$next = next_line($IN);
}
- if ($next =~ m/author +(.*)/) {
- $commit{Author} = $1;
- $next = next_line($IN);
- }
- unless ($next =~ m/committer +(.+) +<([^>]+)> +(\d+) +[+-](\d+)$/) {
- die "missing comitter: $_";
+ unless ($next =~ m/author +(.+) +<([^>]+)> +(\d+) +[+-](\d+)$/) {
+ die "missing author: $_";
}
$commit{CommitterName} = $1;
@@ -275,6 +271,9 @@ COMMAND: while (!eof(IN)) {
$commit{CommitterTZ} = $4;
$next = next_line($IN);
+ if ($next =~ m/committer +(.*)/) {
+ $next = next_line($IN);
+ }
my $log = read_data($IN, $next);
$next = next_line($IN);
^ permalink raw reply related
* Re: cvsimport still not working with cvsnt
From: Jonathan Nieder @ 2011-01-14 7:44 UTC (permalink / raw)
To: Guy Rouillier
Cc: Martin Langhoff, Emil Medve, git, Pascal Obry, Clemens Buchacher
In-Reply-To: <4D2FEF49.8070205@burntmail.com>
Guy Rouillier wrote:
> Martin, thanks for the reply. Have you had a chance to read the
> entire thread? The matching test was suggested by Emil.
To summarize, Emil originally (2008)[1] suggested only checking
~/.cvs/cvspass when ~/.cvspass fails to open. There was no response
at the time, perhaps because nobody interested saw the message.
Guy, two years later[2], wrote:
| I do see one possible issue with the supplied modifications. At work,
| we upgraded from CVS to CVSNT. So, my home directory has both
| .cvspass (from the original CVS) and .cvs/cvspass (after the conversion to
| CVSNT.) Sloppy housekeeping on my part, I admit, but probably not
| uncommon. The supplied patch would pick up the original CVS file and
| would fail. (BTW, this is true only of the git-cvsimport.perl script
and recommended erroring out if both files exist to make this easier
to diagnose.
Emil's advice: if this is an important use case to you, maybe it would
be served better by looking at both files?
> This is my first patch submission. What is the process for reaching
> consensus?
See Documentation/SubmittingPatches, "An ideal patch flow".
My take: you learn what you can from others' advice, but ultimately
the idea is to just make those changes that make the patch better
(where better can mean featureful or simpler and more maintainable ---
this is not meant to be an excuse for overengineering). In most cases
apparent conflicts are not real conflicts at all but signs of distinct
design goals to be balanced or reconciled.
Hope that helps,
Jonathan
[1] http://thread.gmane.org/gmane.comp.version-control.git/77109
[2] http://thread.gmane.org/gmane.comp.version-control.git/163979
^ permalink raw reply
* Re: working with a large repository and git svn
From: Joe Corneli @ 2011-01-14 7:43 UTC (permalink / raw)
To: git
In-Reply-To: <20110113032300.GB9184@burratino>
> I think the state of the art is currently git2svn
Thanks, that did indeed work, though, for the record it uses committer
name and email in the log that it generates, not author name and
email, but no worries!
Joe
^ permalink raw reply
* Re: cvsimport still not working with cvsnt
From: Guy Rouillier @ 2011-01-14 6:38 UTC (permalink / raw)
To: Martin Langhoff
Cc: Emil Medve, Jonathan Nieder, git, Pascal Obry, Clemens Buchacher
In-Reply-To: <AANLkTikreDJmUPfwNJ2ABivrafjvQNN6WrytNMAcse4A@mail.gmail.com>
On 1/10/2011 10:38 AM, Martin Langhoff wrote:
> On Mon, Jan 10, 2011 at 2:33 AM, Guy Rouillier<guyr@burntmail.com> wrote:
>> Here is my patch for accomplishing the above. As this is my first time
>> submitting a patch, please let me know the correct procedure if
>> submitting a diff here is not appropriate. Thanks.
>
> The concept of what the patch is doing is good, but I'd recommend
>
> @cvspasslocations = ($ENV{'HOME'}."/cvspass", $ENV{'HOME'}."/.cvs/cvspass")
>
> foreach $cvspass (@cvspasslocations) {
> open(...
>
> and forgo the "matching" test.
>
Martin, thanks for the reply. Have you had a chance to read the entire
thread? The matching test was suggested by Emil.
This is my first patch submission. What is the process for reaching
consensus?
--
Guy Rouillier
^ permalink raw reply
* [ANNOUNCE] Git 1.7.4-rc2
From: Junio C Hamano @ 2011-01-14 6:33 UTC (permalink / raw)
To: git
A release candidate Git 1.7.4-rc2 is available at the usual places
for testing:
http://www.kernel.org/pub/software/scm/git/
git-1.7.4.rc2.tar.{gz,bz2} (source tarball)
git-htmldocs-1.7.4.rc2.tar.{gz,bz2} (preformatted docs)
git-manpages-1.7.4.rc2.tar.{gz,bz2} (preformatted docs)
The RPM binary packages for a few architectures are found in:
testing/git-*-1.7.4.rc2-1.fc13.$arch.rpm (RPM)
Hopefully we can declare victory soon and cut the final mid-next week.
----------------------------------------------------------------
Changes since v1.7.4-rc1 include nothing spectacular.
Anders Kaseorg (1):
Mark gitk script executable
Brandon Casey (3):
trace.c: ensure NULL is not passed to printf
t0001,t1510,t3301: use sane_unset which always returns with status 0
t3032: limit sed branch labels to 8 characters
Jeff King (1):
docs: explain diff.*.binary option
Jonathan Nieder (3):
diff: funcname and word patterns for perl
gitweb: make logo optional
t9010: svnadmin can fail even if available
Junio C Hamano (2):
userdiff/perl: catch BEGIN/END/... and POD as headers
Git 1.7.4-rc2
Matthieu Moy (1):
commit: suggest --amend --reset-author to fix commiter identity
Michael J Gruber (1):
RelNotes/1.7.4: minor fixes
Ramsay Allan Jones (7):
lib-git-svn.sh: Move web-server handling code into separate function
t9157-*.sh: Add an svn version check
t6038-*.sh: Pass the -b (--binary) option to sed on cygwin
t3032-*.sh: Pass the -b (--binary) option to sed on cygwin
t3032-*.sh: Do not strip CR from line-endings while grepping on MinGW
t4135-*.sh: Skip the "backslash" tests on cygwin
t9157-*.sh: Make the svn version check more precise
StephenB (1):
git svn: fix the final example in man page
Sylvain Rabot (2):
gitweb: add extensions to highlight feature map
gitweb: remove unnecessary test when closing file descriptor
Thomas Rast (4):
Documentation/git-archive: spell --worktree-attributes correctly
Documentation/githooks: post-rewrite-copy-notes never existed
submodule: fix relative url parsing for scp-style origin
t0000: quote TAP snippets in test code
^ permalink raw reply
* Git SRV support for clients
From: William King @ 2011-01-14 4:57 UTC (permalink / raw)
To: git
Is there any interest, other than mine, for SRV client support for git?
I looked into the code and it appears that SRV support could be enabled
by a patch in the file connect.c, in the function
git_tcp_connect_sock(). If the getaddrinfo() call were to be replaced
with an api call that supports SRV records.
I looked into udns which is cross platform, and async(which would allow
a SRV lookup as well as an A record lookup at the same time to avoid the
'long first query SRV issue').
Any thoughts?
-William King
^ permalink raw reply
* Presenting myself to the community and GSoC 2011
From: João Paulo Melo de Sampaio @ 2011-01-14 0:43 UTC (permalink / raw)
To: GIT Mailing List
Hello, people.
I intend to present myself to the community here. I'll keep it as
short as possible.
My name is João Sampaio. I am a Computer Engineering student at
Federal University of São Carlos, from Brazil. I'm very proud to be a
student of one of the best Computer Engineering courses in the
country. I'm 21. My English is 98% fluent, which means that I can read
and write everything but I might miss a couple words or sentences here
and there over voice communication like Skype and phone and you might
not understand what I'm saying, eventually. Nothing we can't overcome,
though. My mother language is Portuguese.
I've used only Linux (mainly Ubuntu) for a few years now. Therefore,
I'm familiar with UNIX systems and it's code production tools (gcc,
gdb, vim, ...). I've never put my C knowlegdes to real test, but I'm
very much confident in them. This is the first real project I intend
to contribute to. I also know C++, PHP and Python for programming
languages and (X)HTML and CSS for the web.
I'd like to state here that I'm interested in participating in Google
Summer of Code this year, and as I've heard early applicants get
better chances, here I am. I've already started studying Git and I've
installed and am testing it in my computer. I have had very little
previous experience with version control systems, but I'm a fast
learner. I have a few friends that already participated in previous
GSoC and they are also giving me some hints.
I want to participate in the Git project because (a) I find version
control an interesting subject; (b) I'm much more motivated to work
with low-level languages like C than high-level, in which most other
projects are written on (even though I do like Python a lot); and (c)
Git is widely used in important projects and it would be awesome to
have my name related to it.
If I happen to capture your attention, I'd be willing to talk to you,
especially if you are going to be a mentor in GSoC! I'm excited to get
involved and we can already start to know each other to get ready for
GSoC, if you want!
Thank you for your time,
--
João Paulo Melo de Sampaio
jpmelos@jpmelos.com
Computer Engineering Student @ UFSCar
Website: http://www.jpmelos.com
^ permalink raw reply
* noob question
From: Harry Johnson @ 2011-01-13 23:58 UTC (permalink / raw)
To: git
I am completely new to git and have only read the tutorial as well as
some git for subversion users documentation. Our company is
considering switching from subversion to git and I have been doing
some experimenting and have run across a potential problem. Our
systems are kubuntu/linux.
I have used git-svn to create a git repo from our subversion repo. I
have done this as user foo which is just an account that is used for
doing central builds. I have then cloned this as repo as myself,
harry. My thought is that the repo owned by foo would be a central
repo that all of the developers, including myself, could clone and to
which we could then 'git push' our changes. The nightly builds would
then simply build whatever was currently in the foo repo. This of
course completely ignores the complexity of branches at this point but
like I said, I am experimenting. I did a test of this and what I found
when checking the git log is that while the changes I made and checked
into my repo clearly showed me as the author, the same changes after
being pushed to foo's repo showed a different author.
So two things.. First should the author have been preserved? How can I
make sure that it is?
Second, and probably the better question. Am I too focused on the
subversion methodology? Is there a better way of managing a central
build scheme using git?
Thanks!
-Harry
^ permalink raw reply
* Re: Resumable clone/Gittorrent (again)
From: Sam Vilain @ 2011-01-13 23:40 UTC (permalink / raw)
To: Luke Kenneth Casson Leighton
Cc: Nguyen Thai Ngoc Duy, Nicolas Pitre, Git Mailing List
In-Reply-To: <AANLkTi=3ikJ2UNNCW582CT7LQ7o2DBZ1hXJhPfMUNbKk@mail.gmail.com>
On 14/01/11 00:39, Luke Kenneth Casson Leighton wrote:
> On Sun, Jan 9, 2011 at 5:48 PM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
>> On Sun, Jan 9, 2011 at 8:55 PM, Luke Kenneth Casson Leighton
>> <luke.leighton@gmail.com> wrote:
>>> you still have to come up with a mapping from "chains" to "pieces".
>>> in the bittorrent protocol the mapping is done *entirely* implicitly
>>> and algorithmically.
>> Given a commit SHA-1, the mapping can be done algorithmically because
>> the graph from the commit tip is fixed. Perhaps not mapping all at
>> once, but as you have more pieces in the graph, you can map more.
> you're _sure_ about this? what happens when new commits get added,
> and change that graph? are you _certain_ that you can write an
> algorithm which is capable of generating exactly the same mapping,
> even as more commits are added to the repository being mirrored, or,
> does that situation not matter?
For a given set of start and end points, and a given sort algorithm,
walking the commit tree can yield deterministic results.
You need to first make sure topological sanity prevails, then order by
commit date where there are ties. git rev-list --date-order does this.
There is the possibility of commits with the same commit date, so if you
need to be really particular you can tie break on those, too.
Did you look at any of the previous research I linked to before?
Sam
^ permalink raw reply
* Re: Applying .gitattributes text/eol changes
From: Junio C Hamano @ 2011-01-13 23:30 UTC (permalink / raw)
To: Marc Strapetz; +Cc: Michael J Gruber, git
In-Reply-To: <4D2F12EE.4020400@syntevo.com>
Marc Strapetz <marc.strapetz@syntevo.com> writes:
> So your suggestion is to fix "git update-index --really-refresh", so
The option is about telling git: "Earlier I promised I wouldn't touch
these paths by setting their assume-unchanged bit, but I touched them.
Please refresh the cached stat information in the index, ignoring the
promise I didn't keep."
I do not think it is a good idea to conflate your "Everything is suspect
because smudge filter has changed; please recompute all" request into the
same option. People who use assume-unchanged would probably want "Please
rescan because I changed smudge filter" request to be carried out while
still honoring the assume-unchanged bit they set earlier.
> Anyway, I'm still wondering if it will resolve the "git reset --hard"
> problem of re-checking out every file, even if content is already
> identical in the working tree. I think that part has to be fixed, too.
There is not much to fix there. If you removed the index, then there is no
information to tell you that "content is already identical" unless you
actually check things out and compare. By the time you found it out, you
already have done the checkout.
IOW, the current code does:
open object
read from the object
deflate and write to the destination file
while your "fix" needs to look like this:
open object
read from the object
deflate and write to a temporary file
open the existing file
read from the file and compare it to the temporary we just wrote
if same, delete, otherwise rename the temporary file.
just for the rare case where there is an untracked file that the user is
willing to overwrite (we are discussing "rm .git/index && reset --hard"
here) happens to have the same contents. Not a good enough reason to add
unwelcome complexity to the codepath.
> What do you think about "git checkout --fix-eols" option as an
> alternative? Its uses cases are more limited, though.
What does it do? "git checkout --fix-eols $path" will overwrite $path
with the data at $path in the index? Perhaps you can use the "-f" option.
Adding an option to "checkout" might be better than update-index from the
UI point of view, but the issue is not just "eols". "eol" is a mere
special case of smudge filter that controls how the contents from the
repository are modified before getting written out to the working tree.
^ permalink raw reply
* git diff
From: Carter Lamb @ 2011-01-13 22:46 UTC (permalink / raw)
To: git
In-Reply-To: <AANLkTi=ASvicFGaaDfqxjOxJELWPLKsQwvk7rEeT36Fh@mail.gmail.com>
I use git diff --summary --numstat <commit> to report the files
modified, created, and deleted between the current commit and some
prior commit. The --stat and --numstat options count the lines added
and deleted for each file. Is there a way to report the lines modified
for each file. For example:
Given content below for commit 1:
aaaaa
ccccc
Given content below for commit 2:
aaaaa
bbbbb
ccccc
Given content below for commit 3:
Aaaaa
Bbbbb
ccccc
ddddd
git diff --numstat between commits 1 and 2 will report one line added.
git diff --numstat between commits 2 and 3 will report three lines
added and two lines deleted.
I'd like to see the diff between commits 2 and 3 report two lines
modified and one line added.
Can this be done?
Best,
Carter
^ permalink raw reply
* Re: [RFC/PATCH 0/2] unpack-trees: handle lstat failures in verify_absent
From: Clemens Buchacher @ 2011-01-13 20:20 UTC (permalink / raw)
To: Jonathan Nieder
Cc: git, gitster, Nguyễn Thái Ngọc Duy, Alex Riesen
In-Reply-To: <20110113022415.GA8635@burratino>
On Wed, Jan 12, 2011 at 08:24:15PM -0600, Jonathan Nieder wrote:
>
> Here are two cases where we ignore the result from lstat in
> unpack_trees. I think we rather shouldn't ignore it. Sane?
Looks good. Thanks.
But in addition to the ones you fixed, lstat errors returned by
lstat_cache_matchlen() in check_leading_path() are also ignored.
I was actually hoping to restructure this into two functions.
1) check_path() to see if we need to overwrite anything (leading
directory _or_ file of the same name)
2) check_ok_to_remove() to check if we can safely overwrite that
directory or file
All the lstat handling would go into check_path(), and
check_ok_to_remove() can reuse the stat returned by check_path().
But right now I can't say when I will find the time.
Clemens
^ permalink raw reply
* Re: Git unpack-objects on Windows
From: Jonathan Nieder @ 2011-01-13 19:40 UTC (permalink / raw)
To: Kevin Sheedy; +Cc: git, Johannes Sixt, users
In-Reply-To: <1294926881696-5918228.post@n2.nabble.com>
(+cc: users@cvs2svn so the web page can be improved)
Kevin Sheedy wrote[1]:
> git init
> cat cvs2svn-tmp/git-blob.dat cvs2svn-tmp/git-dump.dat | git fast-import
You're almost there. I'd suggest two steps:
gitk --all; # reconnaissance
git checkout
Hope that helps,
Jonathan
[1] following http://cvs2svn.tigris.org/cvs2git.html
^ permalink raw reply
* Re: [PATCH] gitk: Take only numeric version components when computing $git_version
From: Jonathan Nieder @ 2011-01-13 19:22 UTC (permalink / raw)
To: Mathias Lafeldt; +Cc: Anders Kaseorg, Paul Mackerras, Junio C Hamano, git
In-Reply-To: <4D2C5F3E.2020007@debugon.org>
Mathias Lafeldt wrote:
> Anders Kaseorg wrote:
>> This fixes errors running with release candidate versions of Git:
>> Error in startup script: expected version number but got "1.7.4-rc0"
[...]
> People don't seem to use gitk with the RC releases because nobody else
> complains...
GIT-VERSION-GEN contains:
DEF_VER=v1.7.4-rc1
[...]
if test -f version
then
[...]
elif test -d .git -o -f .git &&
[...]
then
VN=$(echo "$VN" | sed -e 's/-/./g');
else
VN="$DEF_VER"
fi
So after building from a tarball generated with "git archive", "git version"
produces v1.7.4-rc1, producing errors from gitk, but after building
from the git repo or a tarball generated with "make dist", the version
is v1.7.4.rc1 (which gitk accepts).
Anders's fix looks good to me for robustness reasons anyway, so
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Maybe the substitution in GIT-VERSION-GEN should say something like
VN=$(echo "$VN" | sed -e 's/-\([^r]\)/.\1/g')
meaning the result for tagged rcs would not depend on whether git is
present? Alternatively, DEF_VER could be set to v1.7.4.rc1, which
does not seem as nice to me.
^ 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