* Re: Submodules
From: Johannes Schindelin @ 2007-08-07 22:50 UTC (permalink / raw)
To: Dmitry Kakurin; +Cc: git
In-Reply-To: <a1bbc6950708071537xfa6b9a0ne8cf66e345fa31b4@mail.gmail.com>
Hi,
completely forgot: submodules do not need to be checked out. So, if there
is a submodule you are not interested in working on, you can leave it.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] tests: added d2u to have unix style testfiles even in textmode
From: Steffen Prohaska @ 2007-08-07 22:49 UTC (permalink / raw)
To: git, torvalds, gitster; +Cc: Steffen Prohaska
In-Reply-To: <11865269472595-git-send-email-prohaska@zib.de>
This is needed if the content of files is compared with
precomputed sha1s or stored expected results.
***WARNING***
This patch is useful for testing and illustrating the problem
but not thought to be applied to any official git branch.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
t/t0000-basic.sh | 2 +-
t/t0020-crlf.sh | 8 ++++----
t/t0021-conversion.sh | 4 ++--
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/t/t0000-basic.sh b/t/t0000-basic.sh
index 4e49d59..bf71ce6 100755
--- a/t/t0000-basic.sh
+++ b/t/t0000-basic.sh
@@ -91,7 +91,7 @@ test_expect_success \
mkdir path2 path3 path3/subp3
for p in path0 path2/file2 path3/file3 path3/subp3/file3
do
- echo "hello $p" >$p
+ echo "hello $p" | d2u >$p
ln -s "hello $p" ${p}sym
done
test_expect_success \
diff --git a/t/t0020-crlf.sh b/t/t0020-crlf.sh
index fe1dfd0..52dc739 100755
--- a/t/t0020-crlf.sh
+++ b/t/t0020-crlf.sh
@@ -21,10 +21,10 @@ test_expect_success setup '
git repo-config core.autocrlf false &&
- for w in Hello world how are you; do echo $w; done >one &&
+ for w in Hello world how are you; do echo $w; done | d2u >one &&
mkdir dir &&
- for w in I am very very fine thank you; do echo $w; done >dir/two &&
- for w in Oh here is NULQin text here; do echo $w; done | q_to_nul >three &&
+ for w in I am very very fine thank you; do echo $w; done | d2u >dir/two &&
+ for w in Oh here is NULQin text here; do echo $w; done | q_to_nul | d2u >three &&
git add . &&
git commit -m initial &&
@@ -34,7 +34,7 @@ test_expect_success setup '
two=`git rev-parse HEAD:dir/two` &&
three=`git rev-parse HEAD:three` &&
- for w in Some extra lines here; do echo $w; done >>one &&
+ for w in Some extra lines here; do echo $w; done | d2u >>one &&
git diff >patch.file &&
patched=`git hash-object --stdin <one` &&
git read-tree --reset -u HEAD &&
diff --git a/t/t0021-conversion.sh b/t/t0021-conversion.sh
index a839f4e..9ca11bb 100755
--- a/t/t0021-conversion.sh
+++ b/t/t0021-conversion.sh
@@ -57,7 +57,7 @@ test_expect_success expanded_in_repo '
echo "\$Id:NoSpaceAtFront \$"
echo "\$Id:NoSpaceAtEitherEnd\$"
echo "\$Id: NoTerminatingSymbol"
- } > expanded-keywords &&
+ } | d2u > expanded-keywords &&
{
echo "File with expanded keywords"
@@ -68,7 +68,7 @@ test_expect_success expanded_in_repo '
echo "\$Id: 4f21723e7b15065df7de95bd46c8ba6fb1818f4c \$"
echo "\$Id: 4f21723e7b15065df7de95bd46c8ba6fb1818f4c \$"
echo "\$Id: NoTerminatingSymbol"
- } > expected-output &&
+ } | d2u > expected-output &&
git add expanded-keywords &&
git commit -m "File with keywords expanded" &&
--
1.5.1.2
^ permalink raw reply related
* Re: Submodules
From: Dmitry Kakurin @ 2007-08-07 23:10 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0708072344450.14781@racer.site>
Yeah, I've already went thru these. But I want (much) more details.
I can ask a bunch of random questions on this list, like:
* Why after 'submodule update' it becomes detached, what if I want it
to stay on certain branch?
* How do I control which branches are fetched?
* What if I do 'commit -a' standing in /super, will /super/submodule
commit as well?
* What if I'm standing in /super/submodule and do 'commit -a'? Will
super notice it in any way?
But I was hoping that it's all summarized somewhere already.
- Dmitry
On 8/7/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Tue, 7 Aug 2007, Dmitry Kakurin wrote:
>
> > Where can I find more information about submodules?
> > I'm interested in both internal implementation details and how to use them.
>
> Most information is found in git-submodule.sh, although
> Documentation/git-submodule.txt has beginnings of a good documentation.
>
> The basic idea is this:
>
> A subdirectory contains a self-contained project.
>
> Once that project is at a stage you want to have in the superproject, you
> can commit that submodule state, much like a subdirectory.
>
> However, the history can progress in much coarser steps for the
> superproject. IOW an ideal case for msysgit.git, where we want to have a
> stable version which can be checked out with GitMe.
>
> Also, find more about submodules here:
>
> http://git.or.cz/gitwiki/SubprojectSupport?highlight=%28submodule%29
>
> Ciao,
> Dscho
^ permalink raw reply
* Re: git on Cygwin: Not a valid object name HEAD
From: Steffen Prohaska @ 2007-08-07 23:20 UTC (permalink / raw)
To: Git Mailing List
Cc: Linus Torvalds, Mark Levedahl, Junio C Hamano, Shawn O. Pearce,
Sebastian Schuberth
In-Reply-To: <A80CCC35-DE1E-4A0B-9144-A8165AF6C98A@zib.de>
I apologize, I didn't check the size of the attachment
in the previous mail (which probably got blocked from
the list).
This time with a link to the logfile.
On Aug 8, 2007, at 12:46 AM, Steffen Prohaska wrote:
> The tests are running. t0000-basic and t0010-racy-git pass. I'll
> send a testlog later. It's running inside a virtual machine on a
> laptop, so it may take some more time.
>
> I suspect the tests will report a lot of errors. At least all
> tests that compare 'echo' output with precomputed sha1's or
> expected results that come with the tests should fail. I haven't
> fully understood the details of line conversion of cygwin. Some
> work may be needed to eliminate false fails from the tests, e.g. by
> adding 'd2u', and find the real problems.
I attached the log of a testrun on an textmode mounted directory
in cygwin with the two recently sent patches applied.
It doesn't look too bad, but it's far from perfect:
1470 ok to 637 FAIL
http://www.zib.de/prohaska/hidden/2007/git-cygwin-textmode/
testlog-2007-08-08.txt
Steffen
^ permalink raw reply
* Re: Submodules
From: Dmitry Kakurin @ 2007-08-07 23:31 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0708072349400.14781@racer.site>
This is exactly the level of details I'm talking about:
* how come sumbodules are not initialized when I do a clone of super.
I expect to be able to build super after I clone it. Is there a new
(undocumented) flag to clone?
* is it OK to *not* init a submodule? will super become unhappy? Can I
do commits to super in this case?
* why submodules should be listed in 2 places: in .submodules and in
super/.git/config?
- Dmitry
P.S. There is an old saying "One fool can ask so many questions that a
thousand wise man would not be able to answer" :-)
On 8/7/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> completely forgot: submodules do not need to be checked out. So, if there
> is a submodule you are not interested in working on, you can leave it.
^ permalink raw reply
* Re: Submodules
From: Johannes Schindelin @ 2007-08-08 0:07 UTC (permalink / raw)
To: Dmitry Kakurin; +Cc: git
In-Reply-To: <a1bbc6950708071631w5d232e92gd0fa27158b27b5c3@mail.gmail.com>
Hi,
On Tue, 7 Aug 2007, Dmitry Kakurin wrote:
> * how come sumbodules are not initialized when I do a clone of super.
> I expect to be able to build super after I clone it. Is there a new
> (undocumented) flag to clone?
There might be. But one of the reasons submodules are not just tree
objects is that you should be able _not_ to check out all of them (think
KDE).
> * why submodules should be listed in 2 places: in .submodules and in
> super/.git/config?
Well, URLs can change. Therefore, .submodules has what is considered the
current URL, but you can change it yourself in .git/config. (At least
that is how I understood it.)
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-p4: Fix support for symlinks.
From: Scott Lamb @ 2007-08-08 1:36 UTC (permalink / raw)
To: Brian Swetland; +Cc: Junio C Hamano, Simon Hausmann, git, Han-Wen Nienhuys
In-Reply-To: <20070807091049.GA13308@bulgaria>
Brian Swetland wrote:
> One observation on git-p4 -- it's a little memory hungry when processing
> large syncs. I haven't tried incremental syncs on top of the initial
> one though -- if it's only the initial that's expensive it's not that
> big a deal.
>
> It seemed to top out around 988MB resident. The branch I was importing
> is about 562MB when checked out and the resulting git repository is
> about 175MB.
While importing each change, I think git-p4 puts into memory two copies
of the contents of all changed files, one in p4CmdList and one in
readP4Files. (That's the raw contents, not just the delta.) I don't
think there's any fundamental reason it couldn't stream them instead.
So incremental syncs may or may not take less memory. If the first
change imports a huge project and no subsequent change ever touches all
those files at once, then yeah. But if, say, you periodically change the
copyright dates in all files in the repository, you'll have this memory
usage whenever syncing such a change.
As long as we're listing git-p4 complaints, here are a couple of mine:
1) coding style. *self-nag* Simon Hausmann mentioned he was happy to
accept patches...and I made one up a while ago; I just need to do a
merge and final check that I haven't broken anything before sending it off.
2) it breaks on tempfile purges. My previous employer has these in their
repository, and I think for the moment they're working around it by
treating a "purge" as a "delete". If I read the Perforce documentation
right, though, only the latest version of a tempfile's contents is kept
in the repository anyway. Their history can't be captured accurately, so
the proper thing is probably to omit tempfiles entirely. (And deleting
files when they become tempfiles and creating files when they become a
normal type.)
Best regards,
Scott
--
Scott Lamb <http://www.slamb.org/>
^ permalink raw reply
* [PATCH] gitk - enable selected patch text on Windows
From: Mark Levedahl @ 2007-08-08 1:40 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Git Mailing List, Mark Levedahl
In-Reply-To: <1186440352826-git-send-email-mdl123@verizon.net>
On windows, mouse input follows the keyboard focus, so to allow selecting
text from the patch canvas we must not shift focus back to the top level.
This change has no negative impact on X, so we don't explicitly test
for Win32 on this change. This provides similar selection capability
as already available using X-Windows.
Signed-off-by: Mark Levedahl <mdl123@verizon.net>
---
This version enforces setting focus to the top level window whenever a
scrolling command is issued. The first version lacked that and could allow
some letters to erroneously appear in the patch window. This was purely
cosmetic but annoying to one co-worker on a very slow machine.
gitk | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/gitk b/gitk
index f74ce51..84f5ee4 100755
--- a/gitk
+++ b/gitk
@@ -955,8 +955,8 @@ proc bindkey {ev script} {
# set the focus back to the toplevel for any click outside
# the entry widgets
proc click {w} {
- global entries
- foreach e $entries {
+ global ctext entries
+ foreach e [concat $entries $ctext] {
if {$w == $e} return
}
focus .
@@ -4565,6 +4565,7 @@ proc sellastline {} {
proc selnextline {dir} {
global selectedline
+ focus .
if {![info exists selectedline]} return
set l [expr {$selectedline + $dir}]
unmarkmatches
@@ -4645,6 +4646,7 @@ proc godo {elt} {
proc goback {} {
global history historyindex
+ focus .
if {$historyindex > 1} {
incr historyindex -1
@@ -4658,6 +4660,7 @@ proc goback {} {
proc goforw {} {
global history historyindex
+ focus .
if {$historyindex < [llength $history]} {
set cmd [lindex $history $historyindex]
--
1.5.3.rc4.25.gade7b9
^ permalink raw reply related
* [PATCH] gitk - Handle MouseWheel events on Windows
From: Mark Levedahl @ 2007-08-08 1:40 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Git Mailing List, Mark Levedahl
In-Reply-To: <11865372352543-git-send-email-mdl123@verizon.net>
Windows, unlike X-Windows, sends mousewheel events by default to the
window that has keyboard focus and uses the MouseWheel event to do so.
The window to be scrolled must be able to take focus, but gitk's panels
are disabled so cannot take focus. For all these reasons, a different
design is needed to use the mousewheel on Windows. The approach here is
to bind the mousewheel events to the top level window and redirect them
based upon the current mouse position.
Signed-off-by: Mark Levedahl <mdl123@verizon.net>
---
This version is a slight clean-up of the original, collapsing two
if/else blocks into a single conditional assignment.
gitk | 27 +++++++++++++++++++++++++--
1 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/gitk b/gitk
index 84f5ee4..eb2b194 100755
--- a/gitk
+++ b/gitk
@@ -823,8 +823,13 @@ proc makewindow {} {
pack .ctop -fill both -expand 1
bindall <1> {selcanvline %W %x %y}
#bindall <B1-Motion> {selcanvline %W %x %y}
- bindall <ButtonRelease-4> "allcanvs yview scroll -5 units"
- bindall <ButtonRelease-5> "allcanvs yview scroll 5 units"
+ if {[tk windowingsystem] == "win32"} {
+ bind . <MouseWheel> { windows_mousewheel_redirector %W %X %Y %D }
+ bind $ctext <MouseWheel> { windows_mousewheel_redirector %W %X %Y %D ; break }
+ } else {
+ bindall <ButtonRelease-4> "allcanvs yview scroll -5 units"
+ bindall <ButtonRelease-5> "allcanvs yview scroll 5 units"
+ }
bindall <2> "canvscan mark %W %x %y"
bindall <B2-Motion> "canvscan dragto %W %x %y"
bindkey <Home> selfirstline
@@ -918,6 +923,24 @@ proc makewindow {} {
-command rmbranch
}
+# Windows sends all mouse wheel events to the current focused window, not
+# the one where the mouse hovers, so bind those events here and redirect
+# to the correct window
+proc windows_mousewheel_redirector {W X Y D} {
+ global canv canv2 canv3
+ set w [winfo containing -displayof $W $X $Y]
+ if {$w ne ""} {
+ set u [expr {$D < 0 ? 5 : -5}]
+ if {$w == $canv || $w == $canv2 || $w == $canv3} {
+ allcanvs yview scroll $u units
+ } else {
+ catch {
+ $w yview scroll $u units
+ }
+ }
+ }
+}
+
# mouse-2 makes all windows scan vertically, but only the one
# the cursor is in scans horizontally
proc canvscan {op w x y} {
--
1.5.3.rc4.25.gade7b9
^ permalink raw reply related
* Re: [PATCH] unpack-trees.c: assume submodules are clean during check-out
From: Eran Tromer @ 2007-08-08 1:41 UTC (permalink / raw)
To: skimo; +Cc: Junio C Hamano, git
In-Reply-To: <20070807085149.GH999MdfPADPa@greensroom.kotnet.org>
On 2007-08-07 04:51, Sven Verdoolaege wrote:
> Surely this is a lot worse than occasionally committing something you
> didn't plan to commit, and only if you are performing a known "dangerous"
> operation.
>
Are you saying that
$ git reset --hard HEAD && vi foo && git commit -a
is a "known dangerous" operation that can record corrupted content even
though you didn't touch it? This is very bad news indeed! I don't see
any such warnings in the documentation.
So, when I'm sure all the edits I did in the work tree are fine, how
*do* I safely make a commit without manually inspecting the changed
files list, or manually listing the changed files for "git add", or
manually running "git submodule update", or manually checking whether
there happens to be some submodules in this project, some other such
cumbersome measure?
> You may have done several supermodule checkouts since you last changed
> the submodule.
True, that approach won't work. I can imagine some logic to
conditionally update ORIG_HEAD, but it gets messy and fragile. Looks
like brokenness is just inevitable when you let the state get stale and
then merrily read it out as if it's fresh.
So.... Maybe we can tackle this head-on? Let index entries be explicitly
marked as "adrift", meaning we just don't touch the work tree for these
entries -- neither reads nor writes. It's used when the piece of
content, say a submodule, is allowed to drift arbitrarily in the work
tree in a way that doesn't represent meaningful edits that should be
reflected in commits, diffs, etc.
For example:
- "git checkout" sets the "adrift" flag on all (modified?) submodules
- "git submodule update" undrifts ("moores?") the submodules
- "git commit -a" skips files that are adrift, and likewise "git add .",
"git diff" etc. (perhaps with some warning?)
- "git add <path>" undrifts <path> and proceeds as usual
- "git status" reports drifting files as such and doesn't bother to
check them in the work tree
- When merging into the work tree, drifting files are left as such
And why stop at submodules? If there's a large blob you don't want to
check out, just "git drift <path>" it. To set whole *directories*
adrift, we can piggybacking on the empty-directory support (i.e., add a
directory entry to the index and set it adrift). So this could be the
basis of partial-checkout support.
Does this sound reasonable?
Eran
^ permalink raw reply
* Re: [PATCH] tests: added d2u to have unix style testfiles even in textmode
From: Linus Torvalds @ 2007-08-08 3:03 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git, gitster
In-Reply-To: <11865269472121-git-send-email-prohaska@zib.de>
On Wed, 8 Aug 2007, Steffen Prohaska wrote:
>
> This is needed if the content of files is compared with
> precomputed sha1s or stored expected results.
>
> ***WARNING***
> This patch is useful for testing and illustrating the problem
> but not thought to be applied to any official git branch.
Quite frankly, *much* rather than having d2u everywhere, why not make the
default for DOS/Windows be to have
[core]
autocrlf=true
and then none of this should hopefully be needed.
(We still need to write the internal git objects using O_BINARY to make
sure that cygwin doesn't corrupt binary data, but that's a totally
different issue).
Linus
^ permalink raw reply
* Re: [PATCH] Add --show-touched option to show "diff --git" line when contents are unchanged
From: Linus Torvalds @ 2007-08-08 3:07 UTC (permalink / raw)
To: Junio C Hamano
Cc: Steven Grimm, Johannes Schindelin, Jean-Fran?ois Veillette,
Matthieu Moy, git
In-Reply-To: <7v4pjc9czm.fsf@assigned-by-dhcp.cox.net>
[ Slow at responding to email, sorry ]
On Mon, 6 Aug 2007, Junio C Hamano wrote:
>
> That's essentially the patch I sent out in another thread allows
> you to do, and some of these people even Acked them, but there
> is one minor issue. "git diff" output is paged, and that "not
> up to date" warning, if it is given to stderr, would not be
> usually seen.
I agree. I wouldn't send it to stderr, I'd literally make it part of the
output.
Everybody who takes patches will accept crud afterwards, since the normal
thing is to email them around, so there's no real downside to adding some
status output at the end. It shouldn't screw anything up, but people will
hopefully notice (sure, if you exit the pager without looking at it all
you wouldn't notice, but that's _already_ true, so..)
Linus
^ permalink raw reply
* Re: [PATCH] Add --show-touched option to show "diff --git" line when contents are unchanged
From: Linus Torvalds @ 2007-08-08 3:42 UTC (permalink / raw)
To: Steven Grimm
Cc: Johannes Schindelin, Jean-Fran?ois Veillette, Matthieu Moy,
Junio C Hamano, git
In-Reply-To: <46B80993.3080409@midwinter.com>
On Tue, 7 Aug 2007, Steven Grimm wrote:
>
> Actually, though this will probably make people roll their eyes, before this
> discussion I would have guessed that "git status" would be the command that
> would tell you the index was out of date, and that there'd be a separate
> command (say, "git update-index"?) that you could then use to sync things up
> again.
Well, historically, you literally would just do
git update-index --refresh
to do that.
"git status" is fairly newfangled, and is purely because users from other
SCM's expected that kind of command to exist. The fact that as part of it
running it does that update-index is really just a side effect.
Linus
^ permalink raw reply
* Re: [PATCH] Add --show-touched option to show "diff --git" line when contents are unchanged
From: Junio C Hamano @ 2007-08-08 3:44 UTC (permalink / raw)
To: Linus Torvalds
Cc: Steven Grimm, Johannes Schindelin, Jean-Fran?ois Veillette,
Matthieu Moy, git
In-Reply-To: <alpine.LFD.0.999.0708072004150.23971@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> Everybody who takes patches will accept crud afterwards, since the normal
> thing is to email them around, so there's no real downside to adding some
> status output at the end. It shouldn't screw anything up, but people will
> hopefully notice (sure, if you exit the pager without looking at it all
> you wouldn't notice, but that's _already_ true, so..)
Well, at least "hundreds of empty diff" has a value of getting
attention for even such a use case, so you _could_ argue this
patch is a regression ;-)
In any case, this will go in as part of the first batch after
1.5.3, I would guess.
^ permalink raw reply
* Re: git on Cygwin: Not a valid object name HEAD
From: Linus Torvalds @ 2007-08-08 3:47 UTC (permalink / raw)
To: Junio C Hamano
Cc: Steffen Prohaska, Mark Levedahl, Git Mailing List,
Shawn O. Pearce, Sebastian Schuberth
In-Reply-To: <7vejif56a2.fsf@assigned-by-dhcp.cox.net>
On Tue, 7 Aug 2007, Junio C Hamano wrote:
>
> > @@ -2023,6 +2027,12 @@ int move_temp_to_file(const char *tmpfile, const char *filename)
> > ...
> > +static void close_or_die(int fd, const char *file)
> > +{
> > + if (close(fd))
> > + die("unable to close %s (%s)", file, strerror(errno));
> > +}
> > +
>
> And I like this even better ;-).
Gaah, that was unintentional. Just random noise I had in my tree, and
didn't even realize made it into the patch.
That "close_or_die()" was because I saw somebody report a write error
without the error string, apparently because the error only got reported
on the close (probably NFS). This way you see if the reason the close
failed was due to out of diskspace or whatever.
But I should have split them up properly - the close_or_die() part
obviously had nothing to do with the O_BINARY part. Feel free to take it
regardless, or split it yourself.
Linus
^ permalink raw reply
* Re: resumable git-clone?
From: Shawn O. Pearce @ 2007-08-08 3:59 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Git Mailing List
In-Reply-To: <fcaeb9bf0708070623p24f1cae2q2af959a89738c4e8@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> I was on a crappy connection and it was frustrated seeing git-clone
> reached 80% then failed, then started over again. Can we support
> resumable git-clone at some level? I think we could split into several
> small packs, keep fetched ones, just get missing packs until we have
> all.
This is uh, difficult over the native git protocol. The problem
is the native protocol negotiates what the client already has and
what it needs by comparing sets of commits. If the client says
"I have commit X" then the server assumes it has not only commit
X _but also every object reachable from it_.
Now packfiles are organized to place commits at the front of the
packfile. So a truncated download will give the client a whole
host of commits, like maybe all of them, but none of the trees
or blobs associated with them as those come behind the commits.
Worse, the commits are sorted most recent to least recent. So if
the client claims he has the very first commit he received, that
is currently an assertion that he has the entire repository.
I have been thinking about this resumable fetch idea for the native
protocol for a few days now, like since the last time it came up
on #git.
One possiblity is to have the client store locally in a temporary
file the list of wants and the list of haves it sent to the server
during the last fetch.
During a resume of a packfile download we actually just replay this
list of wants/haves, even if the server has newer data. We also tell
the server which object we last successfully downloaded (its SHA-1).
The server would only accept the resumed want list if all of the
wants are reachable from its current refs. If one or more aren't
then they are just culled from the want list; this way you can still
successfully resume a download of say git.git where pu rebases often.
You just might not get pu without going back for it.
If the server always performs a very stable (meaning we don't ever
change the sorting order!) and deterministic sorting of the objects
in the packfile then given the same list of wants/haves and a
"prior" point it can pickup from where it left off.
At worst we are retransmitting one whole object again, e.g. the
client had all but the last byte of the object, so it was no good.
I'm willing to say we do the full object retransmission in case the
object was recompressed on the server between the first fetch and
the second. It just simplifies the restart.
Probably not that difficult. The hardest part is committing to the
object sorting order so that when we ask for a restart we *know*
we didn't miss an object.
> I didn't clone via http so I don't know if http supports resumable.
This would have a better chance at doing a resume. Looking at the
code it looks like we do in fact resume a packfile download if it
was truncated.
--
Shawn.
^ permalink raw reply
* Re: git on Cygwin: Not a valid object name HEAD
From: Brian Downing @ 2007-08-08 4:25 UTC (permalink / raw)
To: Steffen Prohaska
Cc: Linus Torvalds, Mark Levedahl, Junio C Hamano, Git Mailing List,
Shawn O. Pearce, Sebastian Schuberth
In-Reply-To: <A80CCC35-DE1E-4A0B-9144-A8165AF6C98A@zib.de>
On Wed, Aug 08, 2007 at 12:46:49AM +0200, Steffen Prohaska wrote:
> I started to run the tests on cygwin in textmode. I chose the
> following setup.
In addition to all the other stuff discussed, I believe you also need
to worry about the binaryness of stdin and stdout.
Looking at:
http://www.cygwin.com/cygwin-ug-net/using-textbinary.html
I think this can be achieved by putting something like:
setmode(0, O_BINARY);
setmode(1, O_BINARY);
at the start of git's main().
When I was trying to get this to work, I did this as well as fixing up
open() and fopen() calls as has already been discussed. What got me
to quit, however, was that I never found a decent way to make the Git
shell scripts binary safe, and enough of the system was in shell as to
make it pretty much useless for everyday use.
Looking at the examples on the above page:
To illustrate the various rules, we provide scripts to delete CRs from
files by using the tr program, which can only write to standard output.
The script
#!/bin/sh
# Remove \r from the file given as argument
tr -d '\r' < "$1" > "$1".nocr
will not work on a text mounted systems because the \r will be
reintroduced on writing. However scripts such as
#!/bin/sh
# Remove \r from the file given as argument
tr -d '\r' | gzip | gunzip > "$1".nocr
work fine. In the first case (assuming the pipes are binary) we rely
on gunzip to set its output to binary mode, possibly overriding the
mode used by the shell.
was all it took to convince me this was probably a fool's errand.
I wound up fixing our software so it would build on a binary mount,
which I decided was a much more sane solution.
-bcd
^ permalink raw reply
* Re: [PATCH] tests: added d2u to have unix style testfiles even in textmode
From: Steffen Prohaska @ 2007-08-08 5:00 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, gitster
In-Reply-To: <alpine.LFD.0.999.0708071959470.23971@woody.linux-foundation.org>
On Aug 8, 2007, at 5:03 AM, Linus Torvalds wrote:
> On Wed, 8 Aug 2007, Steffen Prohaska wrote:
>>
>> This is needed if the content of files is compared with
>> precomputed sha1s or stored expected results.
>>
>> ***WARNING***
>> This patch is useful for testing and illustrating the problem
>> but not thought to be applied to any official git branch.
>
> Quite frankly, *much* rather than having d2u everywhere, why not
> make the
> default for DOS/Windows be to have
>
> [core]
> autocrlf=true
>
> and then none of this should hopefully be needed.
Thanks for that idea. I'll check how far I can get with it.
Steffen
^ permalink raw reply
* Re: 'pu' branch for StGIT
From: Pavel Roskin @ 2007-08-08 5:03 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git, Catalin Marinas, Yann Dirson
In-Reply-To: <20070807022043.GA8482@diana.vm.bytemark.co.uk>
On Tue, 2007-08-07 at 04:20 +0200, Karl Hasselström wrote:
> So I finally got my act together and published a 'pu'-like branch for
> StGIT. Get it at git://repo.or.cz/stgit/kha.git; gitweb at
> http://repo.or.cz/w/stgit/kha.git.
Just a word of warning. This version converts all branches to version
3, so that the standard StGIT won't work with them anymore.
Also, "stg import" commits the patch, which seems wrong to me.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: git on Cygwin: Not a valid object name HEAD
From: Steffen Prohaska @ 2007-08-08 5:46 UTC (permalink / raw)
To: Brian Downing
Cc: Linus Torvalds, Mark Levedahl, Junio C Hamano, Git Mailing List,
Shawn O. Pearce, Sebastian Schuberth
In-Reply-To: <20070808042513.GP21692@lavos.net>
On Aug 8, 2007, at 6:25 AM, Brian Downing wrote:
> On Wed, Aug 08, 2007 at 12:46:49AM +0200, Steffen Prohaska wrote:
>> I started to run the tests on cygwin in textmode. I chose the
>> following setup.
>
> In addition to all the other stuff discussed, I believe you also need
> to worry about the binaryness of stdin and stdout.
>
> Looking at:
>
> http://www.cygwin.com/cygwin-ug-net/using-textbinary.html
>
> I think this can be achieved by putting something like:
>
> setmode(0, O_BINARY);
> setmode(1, O_BINARY);
>
> at the start of git's main().
I agree. This is my understanding as well.
> When I was trying to get this to work, I did this as well as fixing up
> open() and fopen() calls as has already been discussed. What got me
> to quit, however, was that I never found a decent way to make the Git
> shell scripts binary safe, and enough of the system was in shell as to
> make it pretty much useless for everyday use.
Did you find a way, maybe not as decent as you wished?
> Looking at the examples on the above page:
>
> To illustrate the various rules, we provide scripts to delete
> CRs from
> files by using the tr program, which can only write to standard
> output.
> The script
>
> #!/bin/sh
> # Remove \r from the file given as argument
> tr -d '\r' < "$1" > "$1".nocr
>
> will not work on a text mounted systems because the \r will be
> reintroduced on writing. However scripts such as
>
> #!/bin/sh
> # Remove \r from the file given as argument
> tr -d '\r' | gzip | gunzip > "$1".nocr
>
> work fine. In the first case (assuming the pipes are binary) we
> rely
> on gunzip to set its output to binary mode, possibly overriding
> the
> mode used by the shell.
>
> was all it took to convince me this was probably a fool's errand.
Yeah, it looks quite crazy. I started to search for an
option that would force the shell to provide redirection
in binary mode, overriding the standard rules. I found
the igncr option [1], which is not what I need. But
apparently there have been some efforts to deal with
line endings in bash beyond the cygwin standard rules.
Maybe there's a useful option that I haven't found yet.
[1] http://cygwin.com/ml/cygwin-announce/2007-01/msg00015.html
> I wound up fixing our software so it would build on a binary mount,
> which I decided was a much more sane solution.
Well, our software already builds and I was not even aware
that there is a problem with git on cygwin until I asked
more people to test it. I naively chose the default option
because I didn't have a reason to do otherwise. But
apparently there is an option, and people use this option.
My fear is that the first impression of git is too bad on
Windows if it can't handle textmode. I can't recommend it.
People will make me responsible for recommending them a
tool that only cause troubles or forces them to reconfigure
their cygwin, which worked for them for years. I even
remember that we had a policy to explicitly set cygwin
to textmode to avoid problems with cvs commits in combination
with Visual Studio 6.
Steffen
^ permalink raw reply
* Re: git on Cygwin: Not a valid object name HEAD
From: Sebastian Schuberth @ 2007-08-08 7:55 UTC (permalink / raw)
To: git; +Cc: Steffen Prohaska, Mark Levedahl, Linus Torvalds, Shawn O. Pearce
In-Reply-To: <7vir7r56cs.fsf@assigned-by-dhcp.cox.net>
> Hopefully fopen() would not barf upon seeing "b", and O_BINARY
> can be ifdefed to 0 on platforms where it is not applicable and
> or'ed in to the flags. As long as they can be proven to be
> useful on Cygwin, I do not see an issue.
According to
http://www.cygwin.com/faq/faq.api.html#faq.api.cr-lf
adding those flags should be okay:
"Note that because the open/fopen switches are defined by ANSI, they
exist under most flavors of Unix; open/fopen will just ignore the switch
since they have no meaning to UNIX."
--
Sebastian Schuberth
^ permalink raw reply
* Man-pages in user manual (was: [ANNOUNCE] GIT 1.5.3-rc4)
From: David Kastrup @ 2007-08-08 8:11 UTC (permalink / raw)
To: git
In-Reply-To: <20070805223105.GC12168@fieldses.org>
"J. Bruce Fields" <bfields@fieldses.org> writes:
> On Mon, Aug 06, 2007 at 12:15:24AM +0200, David Kastrup wrote:
>> Or things like including the manual pages in an appendix or elsewhere.
>> Any chance for that? Slim, at least for me.
>
> I'd like to do exactly that at some point. I was hoping it would be as
> simple as just adding a bunch of include:: statements, but there's
> probably some more obstacles. If someone had the time to look into what
> would be required to get it working, I'd be grateful.
Well, I posted already a patch set (or rather, several iterations)
that built info documentation from the user manual. I only got a
single comment from Jakub about notices in INSTALL, and about the awk
dependency. The last iteration from yesterday addressed both AFAICT.
Since it does not affect existing Makefile targets at all, I hope that
it may end up in 1.5.3.
However, independently from info, I think the git documentation should
be structured into one or more standalone documents that make sense as
a single DocBook document (and ultimately a printed PDF) each. Of
course this will benefit generating info, but it will also give other
people better documentation into their hands.
I digress.
Concerning your request
> If someone had the time to look into what would be required to get
> it working, I'd be grateful.
I did some digging and some trying. The inclusion of the manual pages
will not work out of the box: they have different markup and logical
sectioning levels.
However, AsciiDoc does provide mechanisms that could be used for
including this sort of stuff, by just matching the markup used in the
man page sources and replacing it with the appropriate headers or
markup for the DocBook case.
To figure this out, read up on the following parts:
<URL:http://www.methods.co.nz/asciidoc/userguide.html#toc67>
<URL:http://www.methods.co.nz/asciidoc/userguide.html#toc71>
<URL:http://www.methods.co.nz/asciidoc/userguide.html#toc75>
It turns out, however, that this may be doing it the hard way: There
is a way to have sections/appendices consisting of just manual pages:
<URL:http://www2.informatik.hu-berlin.de/~draheim/doc/docbook-manpages.html>
So it may be easiest to just create a <reference> section in the XML,
include the man pages in there, and see what the various DocBook
converters make of that.
Of course, in such a document one would want to change the gitlink
macros to actually point to the included reference rather than an
outside resource.
That would have to be done in Documentation/asciidoc.conf as far as I
can see.
There are already autogenerated files cmds*.txt that contain lists of
the various manpages. One could either use them directly (with a
temporary gitlink definition that includes a manual page rather than
referring to it), or generate similar files with a more
straightforward relation of content and behavior.
--
David Kastrup
^ permalink raw reply
* Re: [PATCH] Add --show-touched option to show "diff --git" line when contents are unchanged
From: Johannes Schindelin @ 2007-08-08 8:26 UTC (permalink / raw)
To: Linus Torvalds
Cc: Junio C Hamano, Steven Grimm, Jean-Fran?ois Veillette,
Matthieu Moy, git
In-Reply-To: <alpine.LFD.0.999.0708072004150.23971@woody.linux-foundation.org>
Hi,
On Tue, 7 Aug 2007, Linus Torvalds wrote:
> Everybody who takes patches will accept crud afterwards, since the
> normal thing is to email them around, so there's no real downside to
> adding some status output at the end. It shouldn't screw anything up,
> but people will hopefully notice (sure, if you exit the pager without
> looking at it all you wouldn't notice, but that's _already_ true, so..)
But then, you could output the message _twice_: first possibly in-between
patches ("WARNING: ...") and then at the end.
However, I have the slight suspicion that people will not even notice. I
mean, we had bug reports on merge-recursive, where the reporter failed to
even acknowledge the fact that merge-recursive said that there were
conflicts, and even listed them.
So I have the slight suspicion that all this will accomplish is "shut the
darn thing up", and old-timers will have a harder time, since they no
longer spot easily when they did a Dumb Thing and left the index out of
sync.
Slightly negative.
Ciao,
Dscho
^ permalink raw reply
* Re: Git doesn't like symlinks?
From: Rogan Dawes @ 2007-08-08 8:29 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <46A09A2B.3030205@dawes.za.net>
Rogan Dawes wrote:
> Hi folks,
>
> I have been tasked with doing some development against an external SVN
> repo, and keeping it largely in sync with an internal directory.
>
> Seeing as how this is a git list, I obviously decided to do this using
> git :-)
>
> So, I have a local git repo with my local changes from the SVN repo, and
> I can push them to the SVN repo without too many problems. The problem
> arises when I try to sync with the local directory.
>
> Since the local directory's structure doesn't match the repo exactly, I
> figured I could work around that by using a symlink to get to the right
> place.
>
> ie. the local dir is
> C:\local\blah\release\5.2\<contents>
>
> and the structure of the SVN (and hence git) repo is:
> /top/main/<contents>
>
> where <contents> is/should be identical between the two places.
>
> Obviously, git won't work correctly in the local dir, so I tried the
> following (on Cygwin)
>
> $ cd /tmp
> $ ~/git/contrib/workdir/git-new-workdir /my/git/repo/ repo-local
> $ cd repo-local/top
> $ rm -rf main/
> $ ln -s /c/local/blah/release/5.2/ main/
> $ git status
>
> This worked, and showed me that there were a few files out of sync.
>
> I decided to copy over one of the files from git to the local dir:
>
> $ git checkout top/main/some/file
>
> And git deleted my "main" symlink, and replaced it with a real dir,
> containing "some/file".
>
> Everything _else_ was now "missing".
>
> Any ideas on how I can get this to work? I know this is not strictly
> what git was designed for, but it could do a really good job if it would
> only leave my symlink alone.
>
> Rogan
So, for anyone else caught in this awkward position, the answer is not
to use a symlink, but to use cygwin's mount command instead.
$ cd /tmp
$ ~/git/contrib/workdir/git-new-workdir /my/git/repo/ repo-local
$ cd repo-local/top
$ rm -rf main/
$ mkdir main/
$ mount 'C:\local\blah\release\5.2\' /tmp/repo-local/top/main/
And everything works as expected.
Regards,
Rogan
^ permalink raw reply
* Re: [PATCH] Add --show-touched option to show "diff --git" line when contents are unchanged
From: Junio C Hamano @ 2007-08-08 8:43 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Linus Torvalds, Steven Grimm, Jean-Fran?ois Veillette,
Matthieu Moy, git
In-Reply-To: <Pine.LNX.4.64.0708080923580.14781@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> So I have the slight suspicion that all this will accomplish is "shut the
> darn thing up", and old-timers will have a harder time, since they no
> longer spot easily when they did a Dumb Thing and left the index out of
> sync.
The hardest hit would be old-timers who try to be friendly by
trying to help new people, who has much less chance to notice
and report these much less prominent warnings, over e-mail or
irc.
^ 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