* How to import a exist git repository into another git repository?
From: Edmond Halley @ 2011-01-05 6:50 UTC (permalink / raw)
To: git; +Cc: Halley
Hi,
I have two exit repos A and B. I would like A becomes part of B. For example:
original:
A
|-- a.cpp
`-- Makefile
B
|-- b.cpp
`-- Makefile
combined:
B
|-- b.cpp
|-- Makefile
`-- A
|-- a.cpp
`-- Makefile
The git log of repo A is kept in the combined repo.
I try google but the following methods turn out they do not work like
what I want. I can not view the log of original repo A after
combining.
1) http://stackoverflow.com/questions/1683531/how-to-import-existing-git-repository-into-another
Fail at the following command.
git checkout -b ZZZ other/master
error: Untracked working tree file 'Makefile' would be overwritten by merge.
2) http://thread.gmane.org/gmane.comp.version-control.git/5126/
git log only give the lastest commit message. I do not know how to get
the log if orignal repo A.
Thank you!
Best regards,
Halley
^ permalink raw reply
* Re: [minor BUG] cherry-pick -x doesn't work if a conflict occurs
From: Uwe Kleine-König @ 2011-01-05 6:50 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <24C35180-AED6-4848-9F05-908831F911F9@dewire.com>
On Wed, Jan 05, 2011 at 07:31:05AM +0100, Robin Rosenberg wrote:
>
> 29 dec 2010 kl. 15:16 skrev Uwe Kleine-König:
>
> > Hello,
> >
> > when hitting a conflict cherry-pick suggests using
> >
> > git commit -c $sha1
> >
> > but the resulting (suggested) commit log doesn't have the extra
> > reference requested by -x.
> >
>
> The man page says -x only takes effect when you do not have a conflict, so there
> is no bug.
ah, I wonder if this is intended or just documenting a short-coming :-)
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: How to import a exist git repository into another git repository?
From: Andrew Garber @ 2011-01-05 7:02 UTC (permalink / raw)
To: git; +Cc: Edmond Halley
In-Reply-To: <AANLkTi=ahqFz=NVMrhtf+u2fJR_PAW-vcXgNYcce=2R+@mail.gmail.com>
What you're looking for is subtree merge:
http://progit.org/book/ch6-7.html
http://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html
- Andrew Garber
On Tue, Jan 4, 2011 at 10:50 PM, Edmond Halley <halleyinvent@gmail.com> wrote:
> Hi,
>
> I have two exit repos A and B. I would like A becomes part of B. For example:
> original:
> A
> |-- a.cpp
> `-- Makefile
>
> B
> |-- b.cpp
> `-- Makefile
>
> combined:
> B
> |-- b.cpp
> |-- Makefile
> `-- A
> |-- a.cpp
> `-- Makefile
>
> The git log of repo A is kept in the combined repo.
>
> I try google but the following methods turn out they do not work like
> what I want. I can not view the log of original repo A after
> combining.
> 1) http://stackoverflow.com/questions/1683531/how-to-import-existing-git-repository-into-another
> Fail at the following command.
> git checkout -b ZZZ other/master
> error: Untracked working tree file 'Makefile' would be overwritten by merge.
>
> 2) http://thread.gmane.org/gmane.comp.version-control.git/5126/
> git log only give the lastest commit message. I do not know how to get
> the log if orignal repo A.
>
> Thank you!
>
> Best regards,
> Halley
> --
> 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
>
^ permalink raw reply
* Re: False positives in git diff-index
From: Alexander Gladysh @ 2011-01-05 7:46 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20110105061515.GA12163@sigill.intra.peff.net>
On Wed, Jan 5, 2011 at 06:15, Jeff King <peff@peff.net> wrote:
> On Wed, Jan 05, 2011 at 06:07:35AM +0000, Alexander Gladysh wrote:
>> > But using that script, I can't replicate your problem. Can you try
>> > running it on the same box you're having trouble with? That might at
>> > least tell us if it's your environment or something more complex going
>> > on.
>> Thank you. I tried it, and, unfortunately, it does not reproduce the
>> problem.
> Oh well, thanks for trying.
> Going back to your original reproduction recipe, can you change the
> "diff-index" line to actually report on what it thinks is different?
> That is, drop the "--quiet" and have it actually produce a patch?
----> Rebuilding manifest...
Making manifest for .
Generating index.html for .
:100644 100644 483a7292436daecc9bea0ab265ee19d587b14298
0000000000000000000000000000000000000000
M cluster/localhost-ag/rocks/index.html
:100644 100644 fcb9ff896fd1a1bd15663fa9be19b250789d4a25
0000000000000000000000000000000000000000
M cluster/localhost-ag/rocks/manifest
These are the two files, which are overridden with identical content.
(See below, looks like I realized who to blame.)
If I read this correctly, Git tells me that the files are deleted. No?
Anyway, I checked, looks like that files are overridden (by
fopen("name", "w")), never explicitly deleted. If it is important, I
will checkout strace.
Contunuing with the script:
----> Comitting changed manifest...
2edcbfabc11f9bbab4fc8c059490cba9ae196d27
# On branch ag/git-debugging
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# typechange: cluster/localhost-ag/versions/versions-current.lua
#
no changes added to commit (use "git add" and/or "git commit -a")
Suddenly: no changes.
> It would be interesting to see what is different, and how that compares
> with the "git status" you run just prior to it (and whether it matches
> the file you "git add"ed just above).
Git status before:
$ git status
# On branch ag/git-debugging
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# typechange: cluster/localhost-ag/versions/versions-current.lua
#
no changes added to commit (use "git add" and/or "git commit -a")
> You haven't told us much about your build process. Are you absolutely
> sure that there couldn't be another process on the system manipulating
> the files between the various runs?
No other process. But see below.
> Are you running on top of any special filesystem that might not meet the
> consistency guarantees we expect (though in that case, I would assume my
> trivial script would have reproduced).
And here I have to say "Oops".
My apologies, I should have realized this before: my project is
mounted on VMWare's HGFS.
(That is: VMWare Fusion Ubuntu Guest -> HGFS -> OS X 10.6 Host files.)
The problem is not reproduced if I copy the project to the native fs
in the guest machine.
But the problem is also not reproduced if I execute your script on the HGFS.
So, does that mean that HGFS violates consistency guarantees?
Alexander.
^ permalink raw reply
* Re: False positives in git diff-index
From: Jeff King @ 2011-01-05 8:08 UTC (permalink / raw)
To: Alexander Gladysh; +Cc: git
In-Reply-To: <AANLkTimFbodDe=DMj5kkR749sG8bDTxyjDCtOEvmDkRd@mail.gmail.com>
On Wed, Jan 05, 2011 at 07:46:19AM +0000, Alexander Gladysh wrote:
> ----> Rebuilding manifest...
> Making manifest for .
> Generating index.html for .
> :100644 100644 483a7292436daecc9bea0ab265ee19d587b14298
> 0000000000000000000000000000000000000000
> M cluster/localhost-ag/rocks/index.html
> :100644 100644 fcb9ff896fd1a1bd15663fa9be19b250789d4a25
> 0000000000000000000000000000000000000000
> M cluster/localhost-ag/rocks/manifest
>
> These are the two files, which are overridden with identical content.
> (See below, looks like I realized who to blame.)
>
> If I read this correctly, Git tells me that the files are deleted. No?
No, it just means that the files are stat-dirty with respect to the
index. For example:
$ git init
$ touch file && git add file && git commit -m one
$ touch file
$ git diff-files
:100644 100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0000000000000000000000000000000000000000 M file
$ git update-index --refresh
$ git diff-files
<no output>
But in your case, the stat information should be up to date, since you
just ran update-index. But see below.
> > Are you running on top of any special filesystem that might not meet the
> > consistency guarantees we expect (though in that case, I would assume my
> > trivial script would have reproduced).
>
> And here I have to say "Oops".
>
> My apologies, I should have realized this before: my project is
> mounted on VMWare's HGFS.
>
> (That is: VMWare Fusion Ubuntu Guest -> HGFS -> OS X 10.6 Host files.)
>
> The problem is not reproduced if I copy the project to the native fs
> in the guest machine.
>
> But the problem is also not reproduced if I execute your script on the HGFS.
>
> So, does that mean that HGFS violates consistency guarantees?
Hmm. That could be the problem. It may not violate traditional
consistency guarantees, but I wonder if it is returning slightly
different stat information between the program runs. That would mean
"git status" does an index refresh and puts some stat information in the
index, but the followup "git diff-index" might see different stat
information.
That's just a theory, though. You might try the patch below:
diff --git a/read-cache.c b/read-cache.c
index 4f2e890..1b415a3 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -283,6 +283,8 @@ int ie_match_stat(const struct index_state *istate,
return DATA_CHANGED | TYPE_CHANGED | MODE_CHANGED;
changed = ce_match_stat_basic(ce, st);
+ if (changed)
+ fprintf(stderr, "changed (%u): %s\n", changed, ce->name);
/*
* Within 1 second of this sequence:
The number in parentheses is the bitwise-or of the things git found that
caused the stat information to be stale (the actual flags are the
*_CHANGED defines in cache.h, but I was too lazy to write a
pretty-printer). If you can get the output from diff-files for the error
case, we can at least see why git thinks the cache is stale.
-Peff
^ permalink raw reply related
* [ANNOUNCE] New version of TFS2Git script
From: Wilbert van Dolleweerd @ 2011-01-05 8:58 UTC (permalink / raw)
To: git
Hello,
I've released a new version of my TFS2Git script. With this script you
can convert Microsoft Team Foundation Server repositories to Git.
You can find the script at https://github.com/WilbertOnGithub/TFS2GIT.
See the readme there for instructions about its usage.
New features:
- The ability to import only part of the history
- An option to map TFS accounts to Git usernames
Needed:
- Powershell
- MsysGit
- Access to the commandline tools of Team Foundation Server.
Tested with Microsoft Team Foundation Server 2008, but should also
work with 2005/2010.
Hope it is useful for other people. Patches and contributions are
welcomed through the usual Github channels.
--
Kind regards,
Wilbert van Dolleweerd
Blog: http://walkingthestack.wordpress.com/
Twitter: http://www.twitter.com/wvandolleweerd
^ permalink raw reply
* Re: [RFC][PATCH] git-send-email: added support for S/MIME
From: Roberto Sassu @ 2011-01-05 9:22 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <201101042036.36208.trast@student.ethz.ch>
Hi Thomas
On Tuesday, January 04, 2011 08:36:36 pm Thomas Rast wrote:
> Roberto Sassu wrote:
> > The script git-send-email.perl has been modified in order to add support
> > for messages with S/MIME format.
>
> Does git-am need symmetric support to decode the message?
I think git-am does not require any modification on the code,
because it already supports emails with Content-Type
'multipart'. One example comes from git-format-patch which
can generate patches with this format by adding the option
'--attach'.
Regards
Roberto Sassu
^ permalink raw reply
* Re[2]: [PATCH 2/3] Fixes bug: git-svn: svn.pathnameencoding is not respected with dcommit/set-tree
From: Алексей Шумкин @ 2011-01-05 11:44 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Eric Wong
In-Reply-To: <201101041818.09365.trast@student.ethz.ch>
As I already said I'm newbie in submitting/distributing patches
but I'll try :)
Tuesday, January 4, 2011, 8:18:09 PM, you wrote:
TR> Zapped wrote:
>> git-svn dcommit/set-tree fails when svn.pathnameencoding is set for native OS encoding (e.g. cp1251 for Windows) though git-svn fetch/clone works well
TR> I'll let Eric judge whether loading the encoding here is the right
TR> fix, but here too the commit message states only what is broken, not
TR> why you fixed it that way. Can you elaborate a bit?
TR> Also, this should be easy to cover with a test case, can you make one?
>> git-svn.perl | 1 +
>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/git-svn.perl b/git-svn.perl
>> index 757de82..399bf4c 100755
>> --- a/git-svn.perl
>> +++ b/git-svn.perl
>> @@ -4451,6 +4451,7 @@ sub new {
>> $self->{path_prefix} = length $self->{svn_path} ?
>> "$self->{svn_path}/" : '';
>> $self->{config} = $opts->{config};
>> + $self->{pathnameencoding} = Git::config('svn.pathnameencoding');
>> return $self;
>> }
>>
>>
--
С уважением,
Алексей Шумкин mailto:zapped@mail.ru
^ permalink raw reply
* Re: rebase parents, or tracking upstream but removing non-distributable bits
From: Alexandre Oliva @ 2011-01-05 11:44 UTC (permalink / raw)
To: Jakub Narebski, Yann Dirson; +Cc: Jonathan Nieder, git
In-Reply-To: <m37heqdfck.fsf@localhost.localdomain>
On Dec 30, 2010, Jakub Narebski <jnareb@gmail.com> wrote:
> They are not sent by default, but they (refs/replace/*) can be send as
> any other ref.
Oh, doh, I was modeling them after grafts, but indeed the replace refs,
unlike grafts, can be sent out. Which doesn't really help, since they'd
be sent out in addition to the objectionable stuff.
Unless the idea is to replace the other way round, i.e., instead of
cleaned-up commit replacing contaminated commit, mark the contaminated
commit as replacing the cleaned-up one. I haven't explored this
possibility, for it dids't seem to make much sense at first.
> * you replace merge-turned-ordinary commit with a proper merge
> commit
Aah... and this would presumably enable further merges onto my local
tree, but I'd public commits that lost history and relationship with
their upstream commits.
I'm aiming at something better than this, something more like the result
of filter-branch, but with improvements for git pull/merge that (i) use
some ref/original mapping (that provides nearly equivalent info to that
of the weak parent idea I proposed before) to tell where we are, what we
have and what needs rewriting, and (ii) perform rewriting of each
brought in commit, keeping local history isomorphic to that of upstream,
and updating the remapping. Ideally, (iii) have means for merge to use
the remapping backwards, so that one could merge from the cleaned-up
branch to the contaminated branch, or even to publish the remapping as
equivalences rather than unidirectional mappings. Perhaps storing them
as trees (or some other format) rather than as long lists of refs would
make them more efficient to deal with, especially after packing.
More details about what we're after in the thread containing:
http://www.mail-archive.com/gnu-linux-libre@nongnu.org/msg00903.html
As for the rewriting itself (which I regard as a solved problem, it's
compatibility between rewritten branches that I'm trying to adress), I'm
thinking of making manual changes to the trees whose commits introduced
undesirable content, taking note of the contaminated and clean objects,
and then writing a script to remap with git filter-branch the contents
of the index for each commit, replacing contaminated with clean file, or
removing fully-contaminated file.
> Though I think that better solution would be feature-branch based
> workflow.
We are not in a position to influence how upstream does their
development, and I suppose this would be the case in many (but not all)
of the situations I described as motivators.
On Dec 30, 2010, Yann Dirson <ydirson@free.fr> wrote:
>> I'm under the impression that this could not just work, but also make
>> rebasing in general (especially the hard case) far less problematic, for
>> git would be able to relate a rebased commit with an original commit.
> I suppose that by "hard case" you mean forking off a branch that gets
> rebased later ?
I meant the case described as “hard case” in the git-rebase man page:
http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html
Hard case: The changes are not the same.
This happens if the subsystem rebase had conflicts, or used
--interactive to omit, edit, squash, or fixup commits; or if the
upstream used one of commit --amend, reset, or filter-branch.
> This problem suggests a more generic one: how to "merge back" most
> changes from a branch while still not merging some specific changes ?
Thanks for the suggestion. That made me think that, more than a
parent/child relationship, the original and rewritten commits should be
perceived as siblings as far as merges are concerned, when a
correspondence/equivalence table is given. Hopefully this wouldn't be
too much of a change to merge and rebase.
Am I making sense? Does this seem generally useful, say, for someone
trying to do participate in the development of unencumbered portions of
a (patent|copyright|contractually|restriction)-encumbered project?
--
Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/ FSF Latin America board member
Free Software Evangelist Red Hat Brazil Compiler Engineer
^ permalink raw reply
* Re[2]: [PATCH 1/3] Fixes bug: git-diff: class methods are not detected in hunk headers for Pascal
From: Алексей Шумкин @ 2011-01-05 11:53 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <201101041813.45053.trast@student.ethz.ch>
Hello, Thomas
TR> But the last line very conspicuously already mentions 'class', so why
TR> does it fail?
Yes, As you already discovered that last line match for class/record
definition but not for class methods.
I did as you said I changed commit message (also included
"Acked-by:"). So should I re-submit patch to the maillist as a new one
or as an answer to this thread?
TR> Zapped wrote:
>> Signed-off-by: Zapped <zapped@mail.ru>
TR> As Junio already said, please provide a real name for the sign-off.
TR> But I also found the commit message and content confusing, probably
TR> because I haven't programmed Pascal for 15 years.
TR> You said
TR> Fixes bug: git-diff: class methods are not detected in hunk headers for Pascal
>> PATTERNS("pascal",
>> - "^((procedure|function|constructor|destructor|interface|"
>> + "^(((class[ \t]+)?(procedure|function)|constructor|destructor|interface|"
>> "implementation|initialization|finalization)[ \t]*.*)$"
>> "\n"
>> "^(.*=[ \t]*(class|record).*)$",
TR> But the last line very conspicuously already mentions 'class', so why
TR> does it fail?
TR> I had to look up a bit of Pascal syntax. Google helped with
TR> http://www.freepascal.org/docs-html/ref/ref.html
TR> which answers this. Also, as stated in SubmittingPatches, we
TR> generally word the messages as stating the behaviour of the changed
TR> version in the present tense. So a better commit message would be
TR> userdiff: match Pascal class methods
TR> Class declarations were already covered by the second pattern, but
TR> class methods have the 'class' keyword in front too. Account for
TR> it.
TR> Signed-off-by: Алексей Крезов <zapped@mail.ru>
TR> Ok, now I feel silly for only having a two-liner despite my
TR> complaints.
TR> That being said, I have now verified that the patch is good, and, you
TR> can include my
TR> Acked-by: Thomas Rast <trast@student.ethz.ch>
TR> in a reroll if you fix the above.
^ permalink raw reply
* [PATCH] Document escaping of special characters in gitignore files
From: Jakub Narebski @ 2011-01-05 13:38 UTC (permalink / raw)
To: git; +Cc: Bruce Korb, avarab, Jakub Narebski
You can use backslash to escape special characters, like '#' or '*',
in gitignore files.
Requested-by: Bruce Korb <bruce.korb@gmail.com>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
This patch was originally send 10 Sep 2010, but I guess it was lost
because it appeared only deep in thread inside response, and not as
well separated patch. I have found about it when I got conflict
merging current code.
It applies on top of current 'master'.
Documentation/gitignore.txt | 7 +++++++
templates/info--exclude | 1 +
2 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt
index 7dc2e8b..20abc20 100644
--- a/Documentation/gitignore.txt
+++ b/Documentation/gitignore.txt
@@ -68,6 +68,7 @@ Patterns have the following format:
for readability.
- A line starting with # serves as a comment.
+ Use `\#` for a literal # character starting filename.
- An optional prefix '!' which negates the pattern; any
matching file excluded by a previous pattern will become
@@ -98,6 +99,12 @@ Patterns have the following format:
For example, "/{asterisk}.c" matches "cat-file.c" but not
"mozilla-sha1/sha1.c".
+ - You can escape special characters using backslash.
+ For example, "{backslash}#*" matches files beginning in `#`
+ (otherwise it would be considered comment),
+ and "{backslash}!*{backslash}?" matches files starting with `!`
+ (negate pattern prefix) and ending with `?` (glob wildcard).
+
NOTES
-----
diff --git a/templates/info--exclude b/templates/info--exclude
index a5196d1..2ebaf0d 100644
--- a/templates/info--exclude
+++ b/templates/info--exclude
@@ -4,3 +4,4 @@
# exclude patterns (uncomment them if you want to use them):
# *.[oa]
# *~
+# \#*#
--
1.7.3
^ permalink raw reply related
* Re: [PATCH 1/3] Fixes bug: git-diff: class methods are not detected in hunk headers for Pascal
From: Thomas Rast @ 2011-01-05 14:23 UTC (permalink / raw)
To: Алексей Шумкин
Cc: git
In-Reply-To: <4510264083.20110105145302@mail.ru>
Алексей Шумкин wrote:
> I did as you said I changed commit message (also included
> "Acked-by:"). So should I re-submit patch to the maillist as a new one
> or as an answer to this thread?
It doesn't matter that much; most people resend as a reply to some
email in the thread. Just don't distribute the reroll all across the
thread :-)
What you can do now that you have an Ack, or if you feel otherwise
confident that this patch is ready for inclusion, is Cc it to Junio.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* git fails on large repo clone on intermittent, or intermittently-high-latency, connections
From: Zenaan Harkness @ 2011-01-05 14:28 UTC (permalink / raw)
To: git
Hi, I am trying to clone opentaps.git. The following is my third try,
and I am giving up now. As you can see I pressed <Return> every now
and then, and for the last long while, absolutely nothing downloading
- the connection has clearly died once again. My last run was
yesterday and I left it run overnight.
I cannot download (with a git clone/ initial repo), more than roughly
100MiB. I am on a satellite connection. I have also experienced this
with wireless connection about 18 months ago.
I have in the middle there (a few months ago) spent a couple months at
a friend's place, and never had the same problem - nice ADSL2+
connection, ~1.5MiB/s connections. As you can see with my satellite
(rural) and also with my older wireless (also rural) connections, I do
not get more than about 64KiB/s, but it's usually slower, and I've
always had satellite latency issues in the order of 450ms, and
sometimes the odd dropout.
As opposed to git, wget on the other hand not only retries and
continues from where it left off when it retries (HTTP protocol)
(default retry 10 times I think), but I can completely INTerrupt wget,
and start it again from an entirely different computer if I want
(using wget's --continue option), and it will (with HTTP) happily
continue right where it left off, and eventually my download
completes.
NOT so with git! :
$ git clone git://gitorious.org/opentaps/opentaps.git opentaps.git
Cloning into opentaps.git...
remote: Counting objects: 105724, done.
remote: Compressing objects: 100% (30417/30417), done.
Receiving objects: 5% (5888/105724), 10.44 MiB | 21 KiB/s
Receiving objects: 5% (5898/105724), 12.18 MiB | 51 KiB/s
Receiving objects: 5% (5920/105724), 17.47 MiB | 38 KiB/s
Receiving objects: 5% (5923/105724), 19.64 MiB | 23 KiB/s
Receiving objects: 5% (5939/105724), 30.01 MiB | 27 KiB/s
Receiving objects: 5% (6184/105724), 41.00 MiB | 47 KiB/s
Receiving objects: 7% (7818/105724), 52.77 MiB | 58 KiB/s
Receiving objects: 8% (9170/105724), 67.66 MiB | 56 KiB/s
Receiving objects: 10% (11309/105724), 70.57 MiB | 24 KiB/s
Receiving objects: 12% (13413/105724), 82.43 MiB | 29 KiB/s
Receiving objects: 12% (13495/105724), 96.81 MiB | 39 KiB/s
Receiving objects: 12% (13495/105724), 101.57 MiB | 47 KiB/s
Receiving objects: 12% (13523/105724), 142.64 MiB | 27 KiB/s
<here it died, after over an hour dead, I killed it completely>
Git cannot operate robustly with larger repos, it appears to me, on
internet connections with even slightly flaky links.
I've googled for a tar-ball of the git repo for opentaps, but found nothing.
What can I do to work around my flaky link?
How hard would it be to add a wget-like mode to git, for the initial
repo download?
TIA
Zen
^ permalink raw reply
* Re: [PATCH 1/3] Fixes bug: git-diff: class methods are not detected in hunk headers for Pascal
From: Thomas Rast @ 2011-01-05 14:31 UTC (permalink / raw)
To: Алексей Шумкин
Cc: git
In-Reply-To: <201101051523.55749.trast@student.ethz.ch>
Thomas Rast wrote:
> Алексей Шумкин wrote:
> > I did as you said I changed commit message (also included
> > "Acked-by:"). So should I re-submit patch to the maillist as a new one
> > or as an answer to this thread?
>
> It doesn't matter that much; most people resend as a reply to some
> email in the thread. Just don't distribute the reroll all across the
> thread :-)
BTW speaking of series (and sorry for not pointing this out earlier):
Since these patches are not related to each other at all, it's better
if you treat them as separate, not as a series. Making a series is
sort of an "all or nothing" hint, meaning that if something holds up
one patch in the series, Junio will treat the whole series as stalled,
etc.
So probably it's better if you resend the acked patch alone, to show
that it can stand on its own. Then later repeat the same for the
other two patches when you have them ready.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* RE: [PATCH v2] Fix false positives in t3404 due to SHELL=/bin/false
From: Vallon, Justin @ 2011-01-05 15:04 UTC (permalink / raw)
To: 'Junio C Hamano', Jonathan Nieder
Cc: Matthieu Moy, Robin H. Johnson, git@vger.kernel.org
In-Reply-To: <7vmxngdys8.fsf@alter.siamese.dyndns.org>
>-----Original Message-----
>From: Junio C Hamano [mailto:gitster@pobox.com]
>Sent: Tuesday, January 04, 2011 6:39 PM
>To: Jonathan Nieder
>Cc: Matthieu Moy; Vallon, Justin; Robin H. Johnson; git@vger.kernel.org
>Subject: Re: [PATCH v2] Fix false positives in t3404 due to
>SHELL=/bin/false
>
>Jonathan Nieder <jrnieder@gmail.com> writes:
>
>> Matthieu Moy wrote:
>>>
>>> (my bad, I wrote this SHELL= without exporting it. Since bash
>>> re-exports already exported variables when they are assigned, and my
>>> /bin/sh points to bash, I didn't notice)
>>
>> Isn't that how export works in all Bourne-style shells? For example:
>>
>> $ env var=outside dash -c '
>> var=inside;
>> dash -c "echo \$var"
>> '
>> inside
>> $
>>
>> Maybe in the failing case SHELL was not exported but just set to
>> /bin/false in .bashrc or similar?
>
>Thanks, you saved me some time responding ;-)
>
>Matthieu's diagnosis is only half correct in that bash is why he didn't
>notice the problem, but if in this sequence
>
> var=foo
> export var
> var=bar
> some-command
>
>some-command does not see "bar" as the value of environment variable
>"var", your shell is not POSIX (there is no such thing as "re-exporting").
But, when you say "your shell", you are really referring to /bin/sh, because this behavior is being observed in t/t3404-rebase-interactive.sh. Which leads to...
Robin: have you observed the problem with Gentoo's /bin/sh?
X=1 ; export X ; /bin/sh -c 'X= ; env | grep ^X='
If so, I would qualify the export with a comment about the mis-behavior:
# Reexport in case sh is non-POSIX
export SHELL
(or, just unset SHELL)
Else, I don't think the re-export is needed (something else is causing your trouble).
>Because POSIX shells are required to mark variables they inherit from the
>environment with the export attribute, your tests will run with SHELL
>exported to the environment if your usual shell is bash (i.e. SHELL is
>already exported to processes it spawns), even if you use another POSIX
>shell to run your git and tests. That makes the issue doubly harder to
>notice.
I don't really follow this. The #! line is /bin/sh. The user's $SHELL does not come into play. Either SHELL is in /bin/sh's environment and it should be cleared in the child, or it isn't and it won't matter.
--
-Justin
^ permalink raw reply
* Re: git fails on large repo clone on intermittent, or intermittently-high-latency, connections
From: Jakub Narebski @ 2011-01-05 15:26 UTC (permalink / raw)
To: Zenaan Harkness; +Cc: git
In-Reply-To: <AANLkTinkhmHpAQjraviKjqFAczThR5GtT_qdyf6Sb3nm@mail.gmail.com>
Zenaan Harkness <zen@freedbms.net> writes:
> Hi, I am trying to clone opentaps.git. The following is my third try,
> and I am giving up now. As you can see I pressed <Return> every now
> and then, and for the last long while, absolutely nothing downloading
> - the connection has clearly died once again. My last run was
> yesterday and I left it run overnight.
>
> I cannot download (with a git clone/ initial repo), more than roughly
> 100MiB. I am on a satellite connection. I have also experienced this
> with wireless connection about 18 months ago.
>
> I have in the middle there (a few months ago) spent a couple months at
> a friend's place, and never had the same problem - nice ADSL2+
> connection, ~1.5MiB/s connections. As you can see with my satellite
> (rural) and also with my older wireless (also rural) connections, I do
> not get more than about 64KiB/s, but it's usually slower, and I've
> always had satellite latency issues in the order of 450ms, and
> sometimes the odd dropout.
>
> As opposed to git, wget on the other hand not only retries and
> continues from where it left off when it retries (HTTP protocol)
> (default retry 10 times I think), but I can completely INTerrupt wget,
> and start it again from an entirely different computer if I want
> (using wget's --continue option), and it will (with HTTP) happily
> continue right where it left off, and eventually my download
> completes.
[...]
> What can I do to work around my flaky link?
Ask project in question to provide bundle of repository for seeding
initial clone (see git-bundle manpage); this is an ordinary file, and
can be downloaded via HTTP or even P2P.
>
> How hard would it be to add a wget-like mode to git, for the initial
> repo download?
Very hard; tthough "resumable clone" was often requested (25%
responders in "Git User's Survey 2010", see [1]), and there was even
some discussion about possible implementation, it was not implemented
yet, even as proof of concept.
The trouble is that packfile is *generated for a client*, and
bit-for-bit representation of said pack can vary (e.g. if
multithreaded packing is enabled; usually a good idea).
[1]: https://git.wiki.kernel.org/index.php/GitSurvey2010#17._Which_of_the_following_features_would_you_like_to_see_implemented_in_git.3F
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Document escaping of special characters in gitignore files
From: Andreas Schwab @ 2011-01-05 15:53 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Bruce Korb, avarab
In-Reply-To: <1294234732-20094-1-git-send-email-jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt
> index 7dc2e8b..20abc20 100644
> --- a/Documentation/gitignore.txt
> +++ b/Documentation/gitignore.txt
> @@ -68,6 +68,7 @@ Patterns have the following format:
> for readability.
>
> - A line starting with # serves as a comment.
> + Use `\#` for a literal # character starting filename.
Should this be written as `{backslash}#`?
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Resumable clone/Gittorrent (again)
From: Nguyen Thai Ngoc Duy @ 2011-01-05 16:23 UTC (permalink / raw)
To: Git Mailing List; +Cc: Nicolas Pitre, Luke Kenneth Casson Leighton
Hi,
I've been analyzing bittorrent protocol and come up with this. The
last idea about a similar thing [1], gittorrent, was given by Nicolas.
This keeps close to that idea (i.e the transfer protocol must be around git
objects, not file chunks) with a bit difference.
The idea is to transfer a chain of objects (trees or blobs), including
base object and delta chain. Objects are chained in according to
worktree layout, e.g. all objects of path/to/any/blob will form a
chain, from a commit tip down to the root commits. Chains can have
gaps, and don't need to start from commit tip. The transfer is
resumable because if a delta chain is corrupt at some point, we can
just request another chain from where it stops. Base object is
obviously resumable.
We start by fetching all commit contents reachable from a commit tip.
This is a chain, therefore resumable. From there each commit can be
examined. Missing trees and blobs will be fetched as chains. Everytime
a delta is received, we can recreate the new object and verify it (we
should have its SHA-1 from its parent trees/commits).
Because these chains are quite independent, in a sense that a blob
chain is independent from another blob chain (but requires tree
chains, of course). We can fetch as many as we want in parallel, once
we're done with the commit chain.
The last thing I like about these chains is that the number of chains
is reasonable. It won't increase too fast over time (as compared to
the number of commits). As such it maps well to BitTorrent's "pieces".
When a new gittorrent comes in, a running client can advertise what
chain it has with a bitmap (*).
So it all looks good to me. It is resumable and verifiable. It can be
fetched in parallel from many servers. It maps pretty good to
BitTorrent (which means we can reuse BitTorrent design). All transfer
should be compressed so the amount of transfer is also acceptable (not
as optimized as upload-pack, but hopefully overhead is low). A minor
point is latest commit (in full) will be available as soon as
possible.
One thing about reachability test. In order to avoid this test in an
expensive way every time a chain is requested, the requested chain
must be in SHA-1 extended form, starting from commit tip (e.g.
$SHA1~12^2~34...). Parsing and following that syntax is cheaper, I
hope.
Comments?
[1] http://article.gmane.org/gmane.comp.version-control.git/155222
(*) BitTorrent stores list of pieces in .torrent file. The bitmap
reflects what pieces a client has so other clients can ask for pieces
from it. If we follow the same way, we can create a list of all
possible directories/files in a repository in .gittorrent file, then
gittorrent client can advertise with bitmaps too, perhaps two-bit map
(not fetched, fetching, fully fetched).
--
Duy
^ permalink raw reply
* Re: [minor BUG] cherry-pick -x doesn't work if a conflict occurs
From: Jay Soffian @ 2011-01-05 16:28 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: Robin Rosenberg, git
In-Reply-To: <20110105065047.GJ25121@pengutronix.de>
2011/1/5 Uwe Kleine-König <u.kleine-koenig@pengutronix.de>:
>> The man page says -x only takes effect when you do not have a conflict, so there
>> is no bug.
> ah, I wonder if this is intended or just documenting a short-coming :-)
I think it's intended as it's no longer the original commit, but
personally I think it should be configurable (I'd like -x to be
configurable as well). For now, I use the following "recommit" script
after a cherry-pick conflict.
#!/bin/sh
# Used after a cherry-pick conflicts to commit with the original
# authorship (commit -c) but keep the newly generated commit message
#
self=$(cd "$(dirname "$0")" && pwd -P)/$(basename "$0")
. "$(git --exec-path)/git-sh-setup"
require_work_tree
cd_to_toplevel
test -f .git/MERGE_MSG || die "No .git/MERGE_MSG"
if test "$GIT_EDITOR" = "$self"
then
cat .git/MERGE_MSG > .GIT/COMMIT_EDITMSG
exit 0
fi
if sha1=$(sed -ne \
's/^(cherry picked from commit \([a-f0-9]\{40\}\))$/\1/p' .git/MERGE_MSG)
then
export GIT_EDITOR="$self"
git commit -c $sha1
fi
j.
^ permalink raw reply
* Re: [minor BUG] cherry-pick -x doesn't work if a conflict occurs
From: Jay Soffian @ 2011-01-05 16:37 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: Robin Rosenberg, git, Shawn O. Pearce
In-Reply-To: <AANLkTimi8s7QRYuEgr2x=bqwEuFPqUUQF4E=f=_PsoV0@mail.gmail.com>
2011/1/5 Jay Soffian <jaysoffian@gmail.com>:
> 2011/1/5 Uwe Kleine-König <u.kleine-koenig@pengutronix.de>:
>> ah, I wonder if this is intended or just documenting a short-coming :-)
>
> I think it's intended as it's no longer the original commit, but
Ah, seems to be a documented short-coming after-all:
http://thread.gmane.org/gmane.comp.version-control.git/61737/focus=61933
j.
^ permalink raw reply
* Re: Tracking branches and pulling on remote
From: Jeff King @ 2011-01-05 16:44 UTC (permalink / raw)
To: Maaartin-1; +Cc: git
In-Reply-To: <4D249EFA.5050408@seznam.cz>
On Wed, Jan 05, 2011 at 05:40:26PM +0100, Maaartin-1 wrote:
> > $ git config remote.origin.fetch
> > +refs/heads/*:refs/remotes/origin/*
> >
> > which is a superset of what you added. If you run the git config command
> > I did above, what do you see?
>
> No, there had been just the single line
>
> refs/heads/master:refs/remotes/origin/master
Ah, OK, then that is the culprit. And the config line you added was a
reasonable solution (though you may consider simply switching it to a
wildcard to cover any future branches, too).
> OK, I swapped origin and upstream and made aliases
> fetchboth = !"git fetch; git fetch upstream"
> fetup = fetch upstream
> which is about everything I need for now.
Cool. You can also use "git fetch --all" to do the equivalent of your
fetchboth.
-Peff
^ permalink raw reply
* Re: Tracking branches and pulling on remote
From: Maaartin-1 @ 2011-01-05 16:40 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20110105050108.GA5884@sigill.intra.peff.net>
On 11-01-05 06:01, Jeff King wrote:
> On Wed, Jan 05, 2011 at 12:58:47AM +0000, Maaartin wrote:
>
>> 1.
>> I'm using git for couple of months and still don't get it. In a new repo a have
>> two branches: master and X. I pushed both to the server, everything seems to
>> work. However, there's origin/master but no origin/X in my repo. When I execute
>> git fetch --all -v
>> only master gets fetched. I've created an entry in the .git/config, no change.
>> I've tried things like
>> git branch --track X origin/X
>> and all of them ends with an error message. Finally I've found out that
>> git config --add remote.origin.fetch refs/heads/X:refs/remotes/origin/X
>> seems to do it, was it right?
>
> There should already have been a remote.origin.fetch that looked like:
>
> $ git config remote.origin.fetch
> +refs/heads/*:refs/remotes/origin/*
>
> which is a superset of what you added. If you run the git config command
> I did above, what do you see?
No, there had been just the single line
refs/heads/master:refs/remotes/origin/master
and after my change I got
refs/heads/X:refs/remotes/origin/X
error: More than one value for the key remote.origin.fetch:
refs/heads/master:refs/remotes/origin/master
It was probably my fault, I may have copied a config file from elsewhere
(and adapted the URL).
> If you have a wildcard line like the one
> above (which is added during the initial clone), then the config you
> added would have done nothing.
I see.
> Are you absolutely sure that the branch was pushed to the remote side in
> the first place? How did you push it?
Yes, I'm sure. I don't remember how I did it, probably using
git push origin master
I think it's clear now.
>> 2.
>> I'd like to do some (at least for now) private changes on a foreign project. The
>> ideal way I think about would be the following:
>> - my local repo is linked to my own server (for backup purposes and for private
>> cooperation with a college)
>> - the repo on my server is linked to the github hosting the project
>> Now, I'd need to do something like
>> ssh myserver git fetch
>> and everything would be fine. I can do it this way, but I'd prefer something like
>> git remote fetch
>> or even
>> git fetch --remote-too
>> which would first make my server fetch from its origin and then my local repo
>> fetch from my server. Is there such a thing? Would you recommend me doing it in
>> a different way?
>
> There isn't really a shortcut for the two-level thing you're trying to
> do. But consider rearranging your topology to always pull to the local
> repo, and then push changes up to your backup/collaboration server.
>
> Something like:
>
> $ git clone http://github.com/whatever/project.git
> $ cd project
> $ git remote add myserver myserver:/path/to/backup repo
>
> and then your workflow is:
>
> : hmm, I feel like working on project. what happened upstream?
> $ git pull ;# or git fetch origin; gitk origin... ; git merge origin
> $ hack hack hack
> : ok, now I have some work to show to my collaborator
> $ git push myserver
>
> or possibly:
>
> : ok, now what has my collaborator been up to
> $ git fetch myserver
> $ gitk myserver/topic
> : I like it, let's merge
> $ git merge myserver/topic
> : Now push back my merge
> $ git push myserver
>
> You might also find it convenient to swap which remote is "origin"
> (since it is the default for "git push" without arguments). That is, you
> primarily consider your local repo to be a clone of what's on
> "myserver", but you occasionally fetch and merge changes from upstream,
> like:
>
> : ok, what has my collaborator been working on?
> $ git pull
> : and what has upstream been up to?
> $ git fetch upstream
> : oh, neat stuff. let's merge it
> $ git merge upstream
> : and then let's publish it so our collaborator will also work on top
> : of it
> $ git push ;# implicitly to origin
>
> How you want to set it up really depends on which mental model
> represents your workflow best.
OK, I swapped origin and upstream and made aliases
fetchboth = !"git fetch; git fetch upstream"
fetup = fetch upstream
which is about everything I need for now.
Thanks, Maaartin.
^ permalink raw reply
* Re: Resumable clone/Gittorrent (again)
From: Luke Kenneth Casson Leighton @ 2011-01-05 16:56 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Git Mailing List, Nicolas Pitre
In-Reply-To: <AANLkTinUV9Z_w85Gz13J+bm8xqnxJ9jBJXJm9bn5Y2ec@mail.gmail.com>
On Wed, Jan 5, 2011 at 4:23 PM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> Hi,
>
> I've been analyzing bittorrent protocol and come up with this. The
> last idea about a similar thing [1], gittorrent, was given by Nicolas.
> This keeps close to that idea (i.e the transfer protocol must be around git
> objects, not file chunks) with a bit difference.
> So it all looks good to me. It is resumable and verifiable. It can be
> fetched in parallel from many servers. It maps pretty good to
> BitTorrent (which means we can reuse BitTorrent design). All transfer
> should be compressed so the amount of transfer is also acceptable (not
> as optimized as upload-pack, but hopefully overhead is low). A minor
> point is latest commit (in full) will be available as soon as
> possible.
ok. what i wasn't aware of, about the bittorrent protocol, was that
multiple files, when placed into the same .torrent, are just
concatenated as one monolithic data block. the "chunking" is just
then slapped on top of that. the end result is that it's possible
that, if you want to get one specific file (or, in this case "object"
whether it be commit, blob or tree) then you *might* end up getting
two more "chunks" than you actually need, which, worst case could end
up being 2.999x the actual data really required.
_this_ is the reason why people such as cameron dale criticised
bittorrent as a hierarchical / multi-file delivery mechanism (and
abandoned it in favour of apt-p2p), and i didn't understand this at
the time enough to be able to point out that i'd assumed they knew
what i was thinking :)
what i was thinking was "duhh!" don't slap multiple files into a
single .torrent, put each file (or, in this case "object" whether it
be commit, blob, tree or other) into a separate torrent! that's all -
problem goes away!
now that of course leaves you with the problem that you now have
potentially hundreds if not thousands or tens of thousands of
.torrents to deal with, publish, find etc. etc. and the solution to
_that_ is to give the name of the .torrent file something
meaningful.... like.... ooo, how about... the object's md5 sum? :)
so _that_ problem's solved, which leaves just one more problem: how
to find such a ridiculously large number of objects in the first
place, and, surprise-surprise, there's a perfect solution to that, as
well, called DHTs. and, surprise-surprise, what do you need as the
DHT key? something like a 128-bit key? ooo, how about ... the
object's md5 sum? that's 128-bit, that'll do :)
but, better than that: there happens to have been announced very
recently an upgraded version of a bittorrent client, which claims to
be fantastic as it's no longer dependent on "internet search" sites,
because surprise-surprise, it uses peer-to-peer DHT to do the search
queries.
so not only is there a solution to the problems but also there's even
a suitable codebase to work from in order to create a working
prototype.
now i just have to find the damn thing... ah yes, it's called Tribler.
l.
^ permalink raw reply
* Re: Resumable clone/Gittorrent (again)
From: Thomas Rast @ 2011-01-05 17:13 UTC (permalink / raw)
To: Luke Kenneth Casson Leighton
Cc: Nguyen Thai Ngoc Duy, Git Mailing List, Nicolas Pitre
In-Reply-To: <AANLkTimHb8O6s_KfhSGqvStZkEGWvPeAVcqQkYoyk49j@mail.gmail.com>
Luke Kenneth Casson Leighton wrote:
> now that of course leaves you with the problem that you now have
> potentially hundreds if not thousands or tens of thousands of
> .torrents to deal with, publish, find etc. etc.
Umm, I'm counting 202400 objects in my git.git and 1799525 in a clone
of linux-2.6.git. So I'm not sure how far you want to split things
into single transfers, but going all the way down to objects will
massively hurt performance.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* --find-copies-harder finds fewer copies/renames than -C does
From: Stefan Haller @ 2011-01-05 17:46 UTC (permalink / raw)
To: git
I was surprised to find out that --find-copies-harder can, under certain
circumstances, detect fewer renames than -C does for a given commit.
After some digging I think I understand now why this is so, but I find
it extremely unintuitive, and would like to know what other people think
about it. I had expected --find-copies-harder to always detect at least
as many copies/renames as -C, and possibly more, but never less.
The case I had is this: I have a repo with about 10.000 files, and a
commit with 14 files being moved to a different folder; half of them
where unmodified moves, the other half had one-line modifications
(similarity index 97% or so).
"git show -C --name-status <commit>" detects all 14 files as renames;
"git show --find-copies-harder --name-status <commit>" only shows the
unmodified moves as renames, the ones with modifications are shown as
delete plus add.
The reason for this seems to be the condition
"num_create * num_src > rename_limit * rename_limit" in diffcore_rename;
--find-copies-harder exeeds the limit, so it turns off inexact rename
dectection *completely*, while -C stays well below the limit.
I had expected --find-copies-harder to still do inexact rename detection
among the changed files in the commit in this case, and turn it off only
for the unmodified files; I'm not familiar enough with the code to tell
whether that would be easy to implement though.
Any thoughts?
--
Stefan Haller
Berlin, Germany
http://www.haller-berlin.de/
^ 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