* Re: Fwd: after first git clone of linux kernel repository there are changed files in working dir
From: rdkrsr @ 2008-12-11 17:58 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.2.00.0812110934180.3340@localhost.localdomain>
Thank you, Linus and Brett, for your answers.
I'm not developing linux kernel, I just wanted to experiment with git.
And then I didn't know if this is a normal behaviour of git. I'm using
windows xp and msysgit for this. And the file system is NTFS. I'm
using dual boot to sporadicly use linux and tried also linux in
virtual box. But both isn't really good. Maybe one day I dare to use
linux as my primary OS.
Red
2008/12/11 Linus Torvalds <torvalds@linux-foundation.org>:
>
>
> On Thu, 11 Dec 2008, rdkrsr wrote:
>>
>> I'm sorry that I didn't answer to git mailing list address. So here
>> comes the email again.
>
> You have a broken filesystem.
>
>> $ git status
>> # On branch master
>> # Changed but not updated:
>> # (use "git add <file>..." to update what will be committed)
>> #
>> # modified: Documentation/IO-mapping.txt
>> # modified: include/linux/netfilter/xt_CONNMARK.h
>> # modified: include/linux/netfilter/xt_DSCP.h
>> # modified: include/linux/netfilter/xt_MARK.h
>> # modified: include/linux/netfilter/xt_RATEEST.h
> ...
>
> This is _exactly_ what happens if you try to develop the Linux kernel on a
> case-insensitive filesystem. The kernel source tree has several files that
> differ only in case, eg
>
> Documentation/IO-mapping.txt
> Documentation/io-mapping.txt
> include/linux/netfilter/xt_tcpmss.h
> include/linux/netfilter/xt_TCPMSS.h
> ..
>
> and if you try to check it out on a broken filesystem, then the second
> file will overwrite the first one, and git will think that you have
> modified it.
>
> OS X? Afaik, you can fix it by using NFS or UFS. And I think ZFS has a
> case-sensitive mode too (and it may even be the default). In fact, I think
> newer versions of OS X even allow that piece-of-sh*t HFS+ to be case
> sensitive (and thus make it much less sh*tty).
>
> Of course, there are reports of some Mac software breaking when they use a
> real filesystem, but hey, what else is new?
>
> Linus
>
^ permalink raw reply
* Re: Fwd: after first git clone of linux kernel repository there are changed files in working dir
From: Linus Torvalds @ 2008-12-11 17:41 UTC (permalink / raw)
To: rdkrsr; +Cc: git
In-Reply-To: <d304880b0812110915o6968050cufbb1e29c8bcea984@mail.gmail.com>
On Thu, 11 Dec 2008, rdkrsr wrote:
>
> I'm sorry that I didn't answer to git mailing list address. So here
> comes the email again.
You have a broken filesystem.
> $ git status
> # On branch master
> # Changed but not updated:
> # (use "git add <file>..." to update what will be committed)
> #
> # modified: Documentation/IO-mapping.txt
> # modified: include/linux/netfilter/xt_CONNMARK.h
> # modified: include/linux/netfilter/xt_DSCP.h
> # modified: include/linux/netfilter/xt_MARK.h
> # modified: include/linux/netfilter/xt_RATEEST.h
...
This is _exactly_ what happens if you try to develop the Linux kernel on a
case-insensitive filesystem. The kernel source tree has several files that
differ only in case, eg
Documentation/IO-mapping.txt
Documentation/io-mapping.txt
include/linux/netfilter/xt_tcpmss.h
include/linux/netfilter/xt_TCPMSS.h
..
and if you try to check it out on a broken filesystem, then the second
file will overwrite the first one, and git will think that you have
modified it.
OS X? Afaik, you can fix it by using NFS or UFS. And I think ZFS has a
case-sensitive mode too (and it may even be the default). In fact, I think
newer versions of OS X even allow that piece-of-sh*t HFS+ to be case
sensitive (and thus make it much less sh*tty).
Of course, there are reports of some Mac software breaking when they use a
real filesystem, but hey, what else is new?
Linus
^ permalink raw reply
* Re: [RFC/PATCH 4/3] gitweb: Incremental blame (proof of concept)
From: Jakub Narebski @ 2008-12-11 17:28 UTC (permalink / raw)
To: git; +Cc: Petr Baudis, Fredrik Kuivinen
In-Reply-To: <20081210200908.16899.36727.stgit@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
> This is tweaked up version of Petr Baudis <pasky@suse.cz> patch, which
> in turn was tweaked up version of Fredrik Kuivinen <frekui@gmail.com>'s
> proof of concept patch. It adds 'blame_incremental' view, which
> incrementally displays line data in blame view using JavaScript (AJAX).
[...]
> Patch by Petr Baudis this one is based on:
> http://permalink.gmane.org/gmane.comp.version-control.git/56657
>
> Original patch by Fredrik Kuivinen:
> http://article.gmane.org/gmane.comp.version-control.git/41361
>
> Snippet adding 'generated in' to gitweb, by Petr Baudis:
> http://article.gmane.org/gmane.comp.version-control.git/83306
>
> Should I post interdiff to Petr Baudis patch, and comments about
> difference between them? [...]
Here is the list of differences between Petr Baudis patch and the one
I have just send. No interdiff, as it is artificially large because
previous patch was based on much older version, so ranges does not
match.
Bugs I have made:
* I forgot to make some changes for git-instaweb.sh to have support
for incremental blame, namely dependency of 'git-instaweb' target
in Makefile on gitweb/blame.js, and lack of the following line in
git-instaweb.sh:
gitweb_blamejs $GIT_DIR/gitweb/blame.js
* Pasky's patch added support for href(...,-partial_query=>1) extra
parameter, which ensured that gitweb link had '?' in it, and used
it to generate 'baseUrl' parameter for startBlame. I have
misunderstood what baseUrl is about, and used $my_url there, while
it is partial URL for blame links: it is projectUrl.
Therefore links in blame table current 'blame_incremental' would
not work. I'm sorry about that, I thought I have checked it...
Intentionally omitted features:
* In patch this one is based on there was fixBlameLinks() JavaScript
function (put directly in the HTML head inside <script> element),
which was used in body.onLoad event to change 'a=blame' to
'a=blame_incremental' in links marked with class="blamelink".
First, this IMHO should be put as separate patch; you can test
'blame_incremental' view by hand-crafting gitweb URL. Second, it
would be not enough in current gitweb, as action can be put in
path_info. So either fixBlameLinks() should be made work in both
cases, or it should be done in different way, for example adding
'js=1' for all links, or doing JavaScript redirect from 'blame'
view (although this way we won't be able to view ordinary 'blame'
view without turning off JavaScript).
Differences in coding of the same features:
* In Pasky's patch git_blame (then named git_blame2) and
git_blame_incremental were just wrappers around git_blame_common;
in this patch git_blame_data is also wrapper (to avoid duplicating
permissions and parameter checking code).
* Instead of calculating title string for "Commit" column cell, and
necessary data for each row, we now calculate it once per commit
and save (cache) in 'commits' associative array (hash).
This is a bit of performance improvement, similar to the one in
"[PATCH 2/3] gitweb: Cache $parent_commit info in git_blame()"
for 'blame' view in gitweb. It is just using Date() and string
concatenation, and not extra fork.
* Variables holding manipulated elements are named a bit differently,
and calculated upfront:
td_sha1 instead of tr.firstChild
a_sha1 instead of ahsAnchor
a_linenr instead of lineAnchor
* There were a few of style changes in gitweb/blame.js; for example
it is used the following style of function definition
function functionName(arg1, arg2) {
thorough the code.
Fixes for bugs in Pasky's patch, and changes related to changes in
ordinary 'blame' output:
* handleResponse function was called only from XMLHttpRequest
onreadystatechange event. Not all browsers call onreadystatechange
each time the server flushes output (Firefox does that), so we use
a timer to check (poll) for changes.
See http://ajaxpatterns.org/HTTP_Streaming#Refactoring_Illustration
* The 'linenr' link was to line number commit.srcline, while it
should be to (commit.srcline + i), as commit.srcline is _start_
line in group, and not the line equivalent to current line in
source.
This might be thought a (mis)feature, and not a bug, though.
* Currently 'blame' view uses single cell (with rowspan="N") spanning
the whole group of lines blaming the same commit, instead of using
empty cells for subsequent lines in group. Therefore instead of
setting "shaAnchor.innerHTML = '';" to make subsequent cells in
"Commit" ('sha1') column empty (or rather to make link element <a>
in cell empty), we use "tr.removeChild(td_sha1);"
This change was made necessary by changes in the 'blame' view.
This also meant that the code checking if lines are in the same
group has to be changes; it was refactored into startOfGroup(tr)
function.
* The title for cells in "Commit" column used UTC (GMT) date and time
'Kay Sievers, 2005-08-07 19:49:46'
instead of the localtime format used currently by 'blame' view:
'Kay Sievers, 2005-08-07 21:49:46 +0200'
Current code uses neither, but 'commit'-like format:
'Kay Sievers, 2005-08-07 19:49:46 +0000 (21:49:46 +0200)'
New features (in short):
* 3-coloring of lines with blame data during incremental blaming
* Adding author initials below shortened SHA-1 of a commit
(if there is place for it, i.e. if group has more than 1 row)
* progress indicator: progress info and progress bar
* information about how long it took to run 'blame_data',
and how long it took to run JavaScript script
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: epic fsck SIGSEGV!
From: Linus Torvalds @ 2008-12-11 17:33 UTC (permalink / raw)
To: Junio C Hamano
Cc: Nicolas Pitre, R. Tyler Ballance, Johannes Sixt, Git Mailing List
In-Reply-To: <7v63lrupxk.fsf@gitster.siamese.dyndns.org>
On Wed, 10 Dec 2008, Junio C Hamano wrote:
>
> I'll consider this signed-off and do the usual forging
Yea. I've even tested it a bit now:
[torvalds@nehalem git]$ ulimit -s 1024
[torvalds@nehalem git]$ git fsck --full
Segmentation fault
[torvalds@nehalem git]$ ./git-fsck --full
dangling commit 3d00b49495ceff119de52dc5443731e2d8d84b6b
dangling commit 4e0a3c7de9af3cbb53cc421329f0579679edbb51
...
so it does seem to fix the issue, and the patch looks safe enough.
It passes all the tests, and works fine on the kernel repo too (ugh, four
minutes! I used to run git-fsck religiously every day back in the early
days, now I realized that I must not have done so in _months_, and my
kernel tree has grown and so has fsck time).
But obviously the true test for fsck is some complex corruption, and I
didn't test that. I can't imagine that it introduces any new problems
though - but the bugs you can't imagine are always the worst ones ;)
Linus
^ permalink raw reply
* Fwd: after first git clone of linux kernel repository there are changed files in working dir
From: rdkrsr @ 2008-12-11 17:15 UTC (permalink / raw)
To: git
In-Reply-To: <d304880b0812110142g41b80745ic09a7200e02dcdb0@mail.gmail.com>
I'm sorry that I didn't answer to git mailing list address. So here
comes the email again.
Here is what I did:
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/li
t linux-2.6
Initialize linux-2.6/.git
Initialized empty Git repository in c:/Dokumente und Einstellungen/Ge
Eigene Dateien/vbox/linux-2.6/.git/
remote: Counting objects: 980697, done.←[K
remote: Compressing objects: 100% (161545/161545), done.←[K
remote: Total 980697 (delta 818552), reused 978923 (delta 816954)←[K
Receiving objects: 100% (980697/980697), 236.14 MiB | 90 KiB/s, done.
Resolving deltas: 100% (818552/818552), done.
Checking out files: 100% (25254/25254), done.
$ cd linux-2.6
$ git status
# On branch master
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
#
# modified: Documentation/IO-mapping.txt
# modified: include/linux/netfilter/xt_CONNMARK.h
# modified: include/linux/netfilter/xt_DSCP.h
# modified: include/linux/netfilter/xt_MARK.h
# modified: include/linux/netfilter/xt_RATEEST.h
# modified: include/linux/netfilter/xt_TCPMSS.h
# modified: include/linux/netfilter_ipv4/ipt_CONNMARK.h
# modified: include/linux/netfilter_ipv4/ipt_DSCP.h
# modified: include/linux/netfilter_ipv4/ipt_ECN.h
# modified: include/linux/netfilter_ipv4/ipt_MARK.h
# modified: include/linux/netfilter_ipv4/ipt_TCPMSS.h
# modified: include/linux/netfilter_ipv4/ipt_TOS.h
# modified: include/linux/netfilter_ipv4/ipt_TTL.h
# modified: include/linux/netfilter_ipv6/ip6t_HL.h
# modified: include/linux/netfilter_ipv6/ip6t_MARK.h
# modified: net/ipv4/netfilter/ipt_ECN.c
# modified: net/ipv4/netfilter/ipt_TTL.c
# modified: net/ipv6/netfilter/ip6t_HL.c
# modified: net/netfilter/xt_CONNMARK.c
# modified: net/netfilter/xt_DSCP.c
# modified: net/netfilter/xt_MARK.c
# modified: net/netfilter/xt_RATEEST.c
# modified: net/netfilter/xt_TCPMSS.c
#
no changes added to commit (use "git add" and/or "git commit -a")
2008/12/10 Brett Simmers <swtaarrs@gmail.com>:
> On Wed, Dec 10, 2008 at 1:22 PM, rdkrsr <rdkrsr@googlemail.com> wrote:
>> I just fetched the sources without changing anything, but git diff
>> shows, that there are changes that are not yet updated (changed but not
>> updated: use git add to ...). Why is it like that?
>>
>> I use msysgit on windows, maybe that is one reason?
>
> What are the filenames? I've seen git on Windows get confused if a
> repository has two files that are the same except for the case of some
> of the letters (since both can't exist by default on NTFS).
>
> -Brett
>
^ permalink raw reply
* [JGIT PATCH 2/5 v2] Add copy(InputStream) to TemporaryBuffer
From: Shawn O. Pearce @ 2008-12-11 16:53 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <20081211155218.GF32487@spearce.org>
In some places we may find ourselves with an InputStream we
need to copy into a TemporaryBuffer, so we can flatten out the
entire stream to a single byte[]. Putting the copy loop here
is more useful then duplicating it in application level code.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
"Shawn O. Pearce" <spearce@spearce.org> wrote:
> Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
> > torsdag 11 december 2008 05:58:39 skrev Shawn O. Pearce:
> > > + final byte[] b = new byte[2048];
> >
> > Why not 8192 here too?
>
> Blargh, you're right. Actually what I should do is look to see
> if blocks != null, in which case I should alloc a block and read
> directly into it. That would avoid one copy of the data.
And now we do that...
diff --git a/org.spearce.jgit/src/org/spearce/jgit/util/TemporaryBuffer.java b/org.spearce.jgit/src/org/spearce/jgit/util/TemporaryBuffer.java
index b1ffd6e..761f359 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/util/TemporaryBuffer.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/util/TemporaryBuffer.java
@@ -42,6 +42,7 @@
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.IOException;
+import java.io.InputStream;
import java.io.OutputStream;
import java.util.ArrayList;
@@ -135,6 +136,39 @@ public void write(final byte[] b, int off, int len) throws IOException {
diskOut.write(b, off, len);
}
+ /**
+ * Copy all bytes remaining on the input stream into this buffer.
+ *
+ * @param in
+ * the stream to read from, until EOF is reached.
+ * @throws IOException
+ * an error occurred reading from the input stream, or while
+ * writing to a local temporary file.
+ */
+ public void copy(final InputStream in) throws IOException {
+ if (blocks != null) {
+ for (;;) {
+ Block s = last();
+ if (s.isFull()) {
+ if (reachedInCoreLimit())
+ break;
+ s = new Block();
+ blocks.add(s);
+ }
+
+ final int n = in.read(s.buffer, s.count, Block.SZ - s.count);
+ if (n < 1)
+ return;
+ s.count += n;
+ }
+ }
+
+ final byte[] tmp = new byte[Block.SZ];
+ int n;
+ while ((n = in.read(tmp)) > 0)
+ diskOut.write(tmp, 0, n);
+ }
+
private Block last() {
return blocks.get(blocks.size() - 1);
}
--
1.6.1.rc2.306.ge5d5e
--
Shawn.
^ permalink raw reply related
* Re: fatal output from git-show really wants a terminal
From: Boyd Stephen Smith Jr. @ 2008-12-11 16:51 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0812111015140.18321@eeepc-johanness>
[-- Attachment #1: Type: text/plain, Size: 2411 bytes --]
On Thursday 2008 December 11 03:15:47 you wrote:
>On Wed, 10 Dec 2008, Boyd Stephen Smith Jr. wrote:
>> On Wednesday 2008 December 10 13:46:50 you wrote:
>> >On Mittwoch, 10. Dezember 2008, Tim Olsen wrote:
>> >> It appears that when outputting a fatal error, git-show will choose
>> >> stdout over stderr if stdout is a terminal and stderr is not.
>> >
>> >This is by design.
>>
>> Then it is poor design. :P j/k
>
>Read up on the reasoning before trolling, will ya? It's all in the Git
>history.
Seeing how I'm new, and this message indicated I had screwed up, I starting
going through the 'git log' looking for a commit message that either
documented this behavior, or indicated the commit had documented this
behavior.
Initially, I was looking for 'stdout' or 'stderr', and found many unrelated
commits. I then figured it was part of the PAGER support, and began
searching for that. I did find an indication of why stdout and stderr are
both redirected to the PAGER's stdin -- but that makes sense to me; I wasn't
questioning it. At least not too much -- but when the user indicates stderr
and stdout should go to different locations, shouldn't they?
I was mainly questioning using a pager AT ALL when the git command is used in
a non-interactive environment, and how git detects an interactive invocation.
I feel this should be done the same way a (POSIX standard) shell detects
interactivity, and that in a non-interactive environment git should not
default to using PAGER.
Now, I certainly could have missed the commit message / commit with
rationale / documentation. 'git log' output is a long document, and I maybe
using the wrong keywords for my search. It also is not all the documentation
that is out there. I'm not afraid to RTFM; but I'm not having much luck
finding the right parts to R.
Finally, I didn't mean to offend. I was hoping the smiley (":P") and "j/k"
would indicate that a was only half serious and know that I don't have the
benefit of following the project closely for very long. I'm appreciative of
the hard work that goes into git and don't mean to belittle that effort.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss03@volumehost.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.org/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] Show a failure of rebase -p if the merge had a conflict
From: Johannes Sixt @ 2008-12-11 16:21 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Andreas Ericsson, Stephen Haberman, git, Junio C Hamano,
Johannes Sixt
This extends t3409-rebase-preserve-merges by a case where the merge that
is rebased has a conflict. Therefore, the rebase stops and expects that
the user resolves the conflict. However, currently rebase --continue
fails because .git/rebase-merge/author-script is missing.
The test script had allocated two identical clones, but only one of them
(clone2) was used. Now we use both as indicated in the comment. Also, an
instance of && was missing in the setup part.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
BTW, I'm not 100% sure whether the additional tests of what to expect
from the test if it did not fail are correct.
I am unable to fix the failure.
-- Hannes
[Sorry, Junio, for the resend. git send-email & PEBCAK. :-/ ]
t/t3409-rebase-preserve-merges.sh | 43 ++++++++++++++++++++++++++++++++----
1 files changed, 38 insertions(+), 5 deletions(-)
diff --git a/t/t3409-rebase-preserve-merges.sh b/t/t3409-rebase-preserve-merges.sh
index 8cde40f..02a6401 100755
--- a/t/t3409-rebase-preserve-merges.sh
+++ b/t/t3409-rebase-preserve-merges.sh
@@ -11,7 +11,7 @@ Run "git rebase -p" and check that merges are properly carried along
GIT_AUTHOR_EMAIL=bogus_email_address
export GIT_AUTHOR_EMAIL
-#echo 'Setting up:
+#Clone 1 (trivial merge):
#
#A1--A2 <-- origin/master
# \ \
@@ -19,7 +19,15 @@ export GIT_AUTHOR_EMAIL
# \
# B2 <-- origin/topic
#
-#'
+#Clone 2 (conflicting merge):
+#
+#A1--A2--B3 <-- origin/master
+# \ \
+# B1------M <-- topic
+# \
+# B2 <-- origin/topic
+#
+# In both cases, 'topic' is rebased onto 'origin/topic'.
test_expect_success 'setup for merge-preserving rebase' \
'echo First > A &&
@@ -37,12 +45,19 @@ test_expect_success 'setup for merge-preserving rebase' \
cd clone1 &&
git checkout -b topic origin/topic &&
git merge origin/master &&
- cd ..
+ cd .. &&
+
+ echo Fifth > B &&
+ git add B &&
+ git commit -m "Add different B" &&
git clone ./. clone2
cd clone2 &&
git checkout -b topic origin/topic &&
- git merge origin/master &&
+ test_must_fail git merge origin/master &&
+ echo Resolved > B &&
+ git add B &&
+ git commit -m "Merge origin/master into topic" &&
cd .. &&
git checkout topic &&
@@ -51,11 +66,29 @@ test_expect_success 'setup for merge-preserving rebase' \
'
test_expect_success 'rebase -p fakes interactive rebase' '
- cd clone2 &&
+ (
+ cd clone1 &&
git fetch &&
git rebase -p origin/topic &&
test 1 = $(git rev-list --all --pretty=oneline | grep "Modify A" | wc -l) &&
test 1 = $(git rev-list --all --pretty=oneline | grep "Merge commit" | wc -l)
+ )
+'
+
+test_expect_failure '--continue works after a conflict' '
+ (
+ cd clone2 &&
+ git fetch &&
+ test_must_fail git rebase -p origin/topic &&
+ test 2 = $(git ls-files B | wc -l) &&
+ echo Resolved again > B &&
+ test_must_fail git rebase --continue &&
+ git add B &&
+ git rebase --continue &&
+ test 1 = $(git rev-list --all --pretty=oneline | grep "Modify A" | wc -l) &&
+ test 1 = $(git rev-list --all --pretty=oneline | grep "Add different" | wc -l) &&
+ test 1 = $(git rev-list --all --pretty=oneline | grep "Merge origin" | wc -l)
+ )
'
test_done
--
1.6.1.rc2.22.gf3bf84
^ permalink raw reply related
* Re: [JGIT PATCH 2/5] Add copy(InputStream) to TemporaryBuffer
From: Shawn O. Pearce @ 2008-12-11 15:52 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <200812111640.34435.robin.rosenberg@dewire.com>
Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
> torsdag 11 december 2008 05:58:39 skrev Shawn O. Pearce:
> > In some places we may find it ourselves with an InputStream we
> > need to copy into a TemporaryBuffer, so we can flatten out the
> > entire stream to a single byte[]. Putting the copy loop here
> > is more useful then duplicating it in application level code.
> > + public void copy(final InputStream in) throws IOException {
> > + final byte[] b = new byte[2048];
>
> Why not 8192 here too?
Blargh, you're right. Actually what I should do is look to see
if blocks != null, in which case I should alloc a block and read
directly into it. That would avoid one copy of the data.
--
Shawn.
^ permalink raw reply
* [PATCH v3] submodule: Allow tracking of the newest revision of a branch in a submodule
From: Fabian Franz @ 2008-12-11 15:39 UTC (permalink / raw)
To: git; +Cc: hjemli, j.sixt, Fabian Franz
Submodules currently only allow tracking a specific revision
and each update in a submodule leads to a new commit in the
master repository. However some users may want to always track
the newest revision of a specific (named) tag or branch or HEAD.
For example the user might want to track a staging branch in all
submodules.
To allow this the "--track|-t <branch>" parameter was added to
git-submodule.sh, which is added to .gitmodules config file as
well as "track" parameter. This creates a new local branch on
checkout, which is tracking the remote branch in case the local
branch does not yet exist.
Technically the gitlink code was changed to always compare
successful (so no changes) in case the sha1 is null. In that
case no new commit is created when there are changes in the
submodule.
The submodule code is adding the file with 0000* on
"add".
Signed-off-by: Fabian Franz <git@fabian-franz.de>
---
>
>Fabian Franz schrieb:
>> Submodules currently only allow tracking a specific revision
>> and each update in a submodule leads to a new commit in the
>> master repository. However some users may want to always track
>> the newest revision of a specific (named) tag or branch or HEAD.
>> For example the user might want to track a staging branch in all
>> submodules.
>
>Personally, I don't particularly like this feature (but then, nobody
>forces me to use it ;) In which situation do you need this?
I have a development workflow in my company where we are independently
working on many components. And for some things I just always want to
have the newest revision without having to commit twice always.
>
>By tieing a project commit to a particular submodule commit the committer
>gives the guarantee: "I've tested this with this module version, and it
>works; all is ok." With this new feature, this guarantee vanishes, because
>the committer has no control over which version of the module will
>ultimately be used; it could be newer or it could be older.
I like this and because of that the --branch is optional. I also like that so much, that we have decided against Google Repo.
However I have both cases: Stable development, where I need one special version and "wild" development, where I always want the newest published one.
>
>I've reviewed the patch just from a shell code writer's point of view.
Okay, I added your suggestions.
Thanks for your feedback.
Best Wishes,
Fabian
Documentation/git-submodule.txt | 10 +++++++++-
git-submodule.sh | 35 +++++++++++++++++++++++++++++++++--
read-cache.c | 5 +++++
3 files changed, 47 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index babaa9b..9c29678 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -9,7 +9,7 @@ git-submodule - Initialize, update or inspect submodules
SYNOPSIS
--------
[verse]
-'git submodule' [--quiet] add [-b branch] [--] <repository> <path>
+'git submodule' [--quiet] add [-b branch] [-t|--track <branch>] [--] <repository> <path>
'git submodule' [--quiet] status [--cached] [--] [<path>...]
'git submodule' [--quiet] init [--] [<path>...]
'git submodule' [--quiet] update [--init] [--] [<path>...]
@@ -118,6 +118,10 @@ update::
If the submodule is not yet initialized, and you just want to use the
setting as stored in .gitmodules, you can automatically initialize the
submodule with the --init option.
++
+If you used --track or set the "track" option in .gitmodules this will
+automatically pull the newest updates from remote instead of tracking a
+specific revision.
summary::
Show commit summary between the given commit (defaults to HEAD) and
@@ -159,6 +163,10 @@ OPTIONS
--branch::
Branch of repository to add as submodule.
+-t::
+--track::
+ Branch/Tag/HEAD of repository to track in a submodule.
+
--cached::
This option is only valid for status and summary commands. These
commands typically use the commit found in the submodule HEAD, but
diff --git a/git-submodule.sh b/git-submodule.sh
index 2f47e06..16df528 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -5,7 +5,7 @@
# Copyright (c) 2007 Lars Hjemli
USAGE="[--quiet] [--cached] \
-[add <repo> [-b branch] <path>]|[status|init|update [-i|--init]|summary [-n|--summary-limit <n>] [<commit>]] \
+[add <repo> [-b branch] [--track|-t <branch>] <path>]|[status|init|update [-i|--init]|summary [-n|--summary-limit <n>] [<commit>]] \
[--] [<path>...]|[foreach <command>]|[sync [--] [<path>...]]"
OPTIONS_SPEC=
. git-sh-setup
@@ -16,6 +16,7 @@ command=
branch=
quiet=
cached=
+track=
#
# print stuff on stdout unless -q was specified
@@ -130,6 +131,11 @@ cmd_add()
-q|--quiet)
quiet=1
;;
+ -t|--track)
+ case "$2" in '') usage ;; esac
+ track=$2
+ shift
+ ;;
--)
shift
break
@@ -197,12 +203,14 @@ cmd_add()
(unset GIT_DIR; cd "$path" && git checkout -f -q ${branch:+-b "$branch" "origin/$branch"}) ||
die "Unable to checkout submodule '$path'"
fi
+ test -n "$track" && printf '160000 0000000000000000000000000000000000000000\t%s\n' "$path" | git update-index --index-info
git add "$path" ||
die "Failed to add submodule '$path'"
git config -f .gitmodules submodule."$path".path "$path" &&
git config -f .gitmodules submodule."$path".url "$repo" &&
+ git config -f .gitmodules submodule."$path".track "$track" &&
git add .gitmodules ||
die "Failed to register submodule '$path'"
}
@@ -277,6 +285,10 @@ cmd_init()
git config submodule."$name".url "$url" ||
die "Failed to register url for submodule path '$path'"
+ track=$(git config -f .gitmodules submodule."$name".track)
+ git config submodule."$name".track "$track" ||
+ die "Failed to register track for submodule path '$path'"
+
say "Submodule '$name' ($url) registered for path '$path'"
done
}
@@ -345,11 +357,29 @@ cmd_update()
then
force="-f"
fi
+ pull=
+ if [ "$sha1" = "0000000000000000000000000000000000000000" ]
+ then
+ track=$(git config submodule."$name".track)
+ : ${track:="master"}
+ # if the local branch does not yet exist, create it
+ ( unset GIT_DIR; cd "$path"; git-show-ref --heads --tags -q "$track" || git branch --track "$track" "origin/$track" )
+ sha1="$track"
+ pull=1
+ fi
+
(unset GIT_DIR; cd "$path" && git-fetch &&
git-checkout $force -q "$sha1") ||
die "Unable to checkout '$sha1' in submodule path '$path'"
say "Submodule path '$path': checked out '$sha1'"
+
+ if [ "$pull" = "1" ]
+ then
+ # Now pull new updates from origin
+ ( unset GIT_DIR; cd "$path"; git-pull ) || die "Unable to pull in submodule path '$path'"
+ fi
+
fi
done
}
@@ -596,7 +626,8 @@ cmd_status()
set_name_rev "$path" "$sha1"
if git diff-files --quiet -- "$path"
then
- say " $sha1 $path$revname"
+ track=$(git config submodule."$name".track)
+ say " $sha1 $path$revname${track:+ (tracking "$track")}"
else
if test -z "$cached"
then
diff --git a/read-cache.c b/read-cache.c
index 8579663..0c14b68 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -137,6 +137,11 @@ static int ce_compare_gitlink(struct cache_entry *ce)
*/
if (resolve_gitlink_ref(ce->name, "HEAD", sha1) < 0)
return 0;
+
+ // To be able to track newest revision
+ if (is_null_sha1(ce->sha1))
+ return 0;
+
return hashcmp(sha1, ce->sha1);
}
--
1.5.3.6
^ permalink raw reply related
* Re: [JGIT PATCH 2/5] Add copy(InputStream) to TemporaryBuffer
From: Robin Rosenberg @ 2008-12-11 15:40 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <1228971522-28764-3-git-send-email-spearce@spearce.org>
torsdag 11 december 2008 05:58:39 skrev Shawn O. Pearce:
> In some places we may find it ourselves with an InputStream we
> need to copy into a TemporaryBuffer, so we can flatten out the
> entire stream to a single byte[]. Putting the copy loop here
> is more useful then duplicating it in application level code.
> + public void copy(final InputStream in) throws IOException {
> + final byte[] b = new byte[2048];
Why not 8192 here too?
-- robin
^ permalink raw reply
* Re: [PATCH v2] submodule: Allow tracking of the newest revision of a branch in a submodule
From: Johannes Sixt @ 2008-12-11 14:24 UTC (permalink / raw)
To: Fabian Franz; +Cc: FabianFranz, git, hjemli
In-Reply-To: <1229001361-9301-1-git-send-email-git@fabian-franz.de>
Fabian Franz schrieb:
> Submodules currently only allow tracking a specific revision
> and each update in a submodule leads to a new commit in the
> master repository. However some users may want to always track
> the newest revision of a specific (named) tag or branch or HEAD.
> For example the user might want to track a staging branch in all
> submodules.
Personally, I don't particularly like this feature (but then, nobody
forces me to use it ;) In which situation do you need this?
By tieing a project commit to a particular submodule commit the committer
gives the guarantee: "I've tested this with this module version, and it
works; all is ok." With this new feature, this guarantee vanishes, because
the committer has no control over which version of the module will
ultimately be used; it could be newer or it could be older.
I've reviewed the patch just from a shell code writer's point of view.
> + [ -n "$track" ] && echo "160000 0000000000000000000000000000000000000000\t$path" | git update-index --index-info
We tend to use "test" instead of "[ ]".
You cannot rely on that echo or the shell translates "\t"; use printf.
test "$track" && printf '160000
0000000000000000000000000000000000000000\t%s\n' "$path" | git update-index
--index-info
(The line-wrapping is from my MUA; sorry.)
> @@ -327,10 +339,12 @@ cmd_update()
> say "Maybe you want to use 'update --init'?"
> continue
> fi
> + track=$(git config submodule."$name".track)
You don't need $track *here*, do you?
> if ! test -d "$path"/.git -o -f "$path"/.git
> then
> module_clone "$path" "$url" || exit
> +
> subsha1=
And this extra blank line is an accident, isn't it?
> + [ -z "$track" ] && track="HEAD"
Instead of this you can use a shell trick (but I don't know if it's portable):
: "${track:=HEAD}"
And I think you can even spare the quotes.
> + # if the local branch does not yet exist, create it
> + ( unset GIT_DIR; cd "$path"; git-show-ref --heads --tags -q "$track" || git branch --track "$track" "origin/$track" )
Ugh! A *branch* named "HEAD"?? I think you should reconsider this decision.
> + if [ "$pull" = "1" ]
if test "$pull"
> + then
> + # Now pull new updates from origin
> + ( unset GIT_DIR; cd "$path"; git-pull )
Wow! Creating new commits on the fly while doing a "git submodule update"!
Error check is missing here.
> @@ -596,7 +627,10 @@ cmd_status()
> set_name_rev "$path" "$sha1"
> if git diff-files --quiet -- "$path"
> then
> - say " $sha1 $path$revname"
> + track=$(git config submodule."$name".track)
> + tracking=
> + [ -n "$track" ] && tracking=" (tracking $track)"
> + say " $sha1 $path$revname$tracking"
The last three lines can be shortened to this:
say " $sha1 $path$revname${track:+ (tracking "$track")}"
-- Hannes
^ permalink raw reply
* [PATCH v2] submodule: Allow tracking of the newest revision of a branch in a submodule
From: Fabian Franz @ 2008-12-11 13:16 UTC (permalink / raw)
To: FabianFranz, git; +Cc: hjemli, Fabian Franz
Submodules currently only allow tracking a specific revision
and each update in a submodule leads to a new commit in the
master repository. However some users may want to always track
the newest revision of a specific (named) tag or branch or HEAD.
For example the user might want to track a staging branch in all
submodules.
To allow this the "--track|-t <branch>" parameter was added to
git-submodule.sh, which is added to .gitmodules config file as
well as "track" parameter. This creates a new local branch on
checkout, which is tracking the remote branch in case the local
branch does not yet exist.
Technically the gitlink code was changed to always compare
successful (so no changes) in case the sha1 is null. In that
case no new commit is created when there are changes in the
submodule.
The submodule code is adding the file with 0000* on
"add".
Signed-off-by: Fabian Franz <git@fabian-franz.de>
---
On Tue, Dec 9, 2008 at 01:57, Fabian Franz <git@xxxxxxxxxxxxxxx> wrote:
>> Technically the gitlink code was changed to read .git/HEAD.gitlink
>> if it exists instead of the normal HEAD. If you add 0000* as sha1
>> sum to .git/HEAD.gitlink the submodule code will always fetch HEAD.
>This feels like the porcelain "fooling" the plumbing. How about
>something like this instead:
>This should make the plumbing happy no matter which commit is actually
>checked out in the submodule (not actually tested...).
Yeah, that works, thank you very much.
>Then, cmd_update() can check if the requested sha1 is all '0' and
>fetch+checkout latest HEAD (or some branch) without playing games with
>.git/HEAD.gitlink.
Okay. I do agree that this solution is much nicer.
>Finally, cmd_add() needs to update the index in the
>containing repository with the magic '0*' sha1 if '--track' is
>specifed. This can be achieved by replacing 'git add $path' with 'echo
>$mode $sha1\t$path | git update-index --index-info'.
>What do you think?
I added that solution and it does work. However I see problems on remove (thought there is no submodule remove so far):
Neither a new git add nor a git rm nor a git-update-index --remove do work afterwards.
This can just be done by doing the above command with some non-null sha1.
>> @@ -327,10 +335,14 @@ cmd_update()
>> say "Maybe you want to use 'update --init'?"
>> continue
>> fi
>> + track=$(git config -f .gitmodules submodule."$name".track)
>I'm pretty certain that we don't want to use info from .gitmodules in
>cmd_update(). Instead, cmd_init() probably should move the info from
>.gitmodules into .git/config and cmd_update() should check the latter.
Okay, I did this, however now I need a flag for init to be able to specify -f or a initalways command shortcut, so I can do in script:
git checkout staging # changes track = staging in .gitmodules
git submodule init -f
git submodule update # changes all branches to staging
Should I add this in a different patch?
Talking about script: Is there a possibility for a checkout hook?
Does something like that exist? Or do I need to add this myself, too?
So my workflow really is:
git checkout master # done long before
[...]
git checkout staging
# => in submodules/client/
# Checked out submodules/client/ staging.
# => in submodules/client/component1/
# Checked out submodules/client/component/1 staging.
So I would like to have this recursively and I think a post checkout hook would be nice for that to achieve.
>Btw: cmd_status() probably also needs some modifications to handle
>this special case.
I added the special case.
Here is the new patch.
What do you think?
Or do we need a track and untrack command for the rm of a submodule to work properly?
Best Wishes,
Fabian
Documentation/git-submodule.txt | 10 +++++++++-
git-submodule.sh | 38 ++++++++++++++++++++++++++++++++++++--
read-cache.c | 5 +++++
3 files changed, 50 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index babaa9b..9c29678 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -9,7 +9,7 @@ git-submodule - Initialize, update or inspect submodules
SYNOPSIS
--------
[verse]
-'git submodule' [--quiet] add [-b branch] [--] <repository> <path>
+'git submodule' [--quiet] add [-b branch] [-t|--track <branch>] [--] <repository> <path>
'git submodule' [--quiet] status [--cached] [--] [<path>...]
'git submodule' [--quiet] init [--] [<path>...]
'git submodule' [--quiet] update [--init] [--] [<path>...]
@@ -118,6 +118,10 @@ update::
If the submodule is not yet initialized, and you just want to use the
setting as stored in .gitmodules, you can automatically initialize the
submodule with the --init option.
++
+If you used --track or set the "track" option in .gitmodules this will
+automatically pull the newest updates from remote instead of tracking a
+specific revision.
summary::
Show commit summary between the given commit (defaults to HEAD) and
@@ -159,6 +163,10 @@ OPTIONS
--branch::
Branch of repository to add as submodule.
+-t::
+--track::
+ Branch/Tag/HEAD of repository to track in a submodule.
+
--cached::
This option is only valid for status and summary commands. These
commands typically use the commit found in the submodule HEAD, but
diff --git a/git-submodule.sh b/git-submodule.sh
index 2f47e06..f25e744 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -5,7 +5,7 @@
# Copyright (c) 2007 Lars Hjemli
USAGE="[--quiet] [--cached] \
-[add <repo> [-b branch] <path>]|[status|init|update [-i|--init]|summary [-n|--summary-limit <n>] [<commit>]] \
+[add <repo> [-b branch] [--track|-t <branch>] <path>]|[status|init|update [-i|--init]|summary [-n|--summary-limit <n>] [<commit>]] \
[--] [<path>...]|[foreach <command>]|[sync [--] [<path>...]]"
OPTIONS_SPEC=
. git-sh-setup
@@ -16,6 +16,7 @@ command=
branch=
quiet=
cached=
+track=
#
# print stuff on stdout unless -q was specified
@@ -130,6 +131,11 @@ cmd_add()
-q|--quiet)
quiet=1
;;
+ -t|--track)
+ case "$2" in '') usage ;; esac
+ track=$2
+ shift
+ ;;
--)
shift
break
@@ -197,12 +203,14 @@ cmd_add()
(unset GIT_DIR; cd "$path" && git checkout -f -q ${branch:+-b "$branch" "origin/$branch"}) ||
die "Unable to checkout submodule '$path'"
fi
+ [ -n "$track" ] && echo "160000 0000000000000000000000000000000000000000\t$path" | git update-index --index-info
git add "$path" ||
die "Failed to add submodule '$path'"
git config -f .gitmodules submodule."$path".path "$path" &&
git config -f .gitmodules submodule."$path".url "$repo" &&
+ git config -f .gitmodules submodule."$path".track "$track" &&
git add .gitmodules ||
die "Failed to register submodule '$path'"
}
@@ -277,6 +285,10 @@ cmd_init()
git config submodule."$name".url "$url" ||
die "Failed to register url for submodule path '$path'"
+ track=$(git config -f .gitmodules submodule."$name".track)
+ git config submodule."$name".track "$track" ||
+ die "Failed to register track for submodule path '$path'"
+
say "Submodule '$name' ($url) registered for path '$path'"
done
}
@@ -327,10 +339,12 @@ cmd_update()
say "Maybe you want to use 'update --init'?"
continue
fi
+ track=$(git config submodule."$name".track)
if ! test -d "$path"/.git -o -f "$path"/.git
then
module_clone "$path" "$url" || exit
+
subsha1=
else
subsha1=$(unset GIT_DIR; cd "$path" &&
@@ -345,11 +359,28 @@ cmd_update()
then
force="-f"
fi
+ pull=
+ if [ "$sha1" = "0000000000000000000000000000000000000000" ]
+ then
+ [ -z "$track" ] && track="HEAD"
+ # if the local branch does not yet exist, create it
+ ( unset GIT_DIR; cd "$path"; git-show-ref --heads --tags -q "$track" || git branch --track "$track" "origin/$track" )
+ sha1="$track"
+ pull=1
+ fi
+
(unset GIT_DIR; cd "$path" && git-fetch &&
git-checkout $force -q "$sha1") ||
die "Unable to checkout '$sha1' in submodule path '$path'"
say "Submodule path '$path': checked out '$sha1'"
+
+ if [ "$pull" = "1" ]
+ then
+ # Now pull new updates from origin
+ ( unset GIT_DIR; cd "$path"; git-pull )
+ fi
+
fi
done
}
@@ -596,7 +627,10 @@ cmd_status()
set_name_rev "$path" "$sha1"
if git diff-files --quiet -- "$path"
then
- say " $sha1 $path$revname"
+ track=$(git config submodule."$name".track)
+ tracking=
+ [ -n "$track" ] && tracking=" (tracking $track)"
+ say " $sha1 $path$revname$tracking"
else
if test -z "$cached"
then
diff --git a/read-cache.c b/read-cache.c
index 8579663..0c14b68 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -137,6 +137,11 @@ static int ce_compare_gitlink(struct cache_entry *ce)
*/
if (resolve_gitlink_ref(ce->name, "HEAD", sha1) < 0)
return 0;
+
+ // To be able to track newest revision
+ if (is_null_sha1(ce->sha1))
+ return 0;
+
return hashcmp(sha1, ce->sha1);
}
--
1.6.1.rc2.1.g4859.dirty
^ permalink raw reply related
* Re: What's cooking in git.git (Nov 2008, #06; Wed, 26)
From: Nguyen Thai Ngoc Duy @ 2008-12-11 13:04 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, Shawn O. Pearce, Johannes Schindelin, git
In-Reply-To: <alpine.LNX.1.00.0812081223140.19665@iabervon.org>
On 12/9/08, Daniel Barkalow <barkalow@iabervon.org> wrote:
> > - for "git grep", we ignore path with CE_NO_CHECKOUT (while using
> > cache version for CE_VALID)
>
>
> Is this sufficient? I'd expect "git grep" to ignore paths that are outside
> the checked-out region, even when searching an arbitrary tree, and even
> when those files aren't in the index at all (i.e., the current commit
> doesn't have them). That is, I'd expect core.defaultsparse or the
> equivalent to limit the paths, normally giving this effect.
That's the point. CE_VALID does not define checkout area while
CE_NO_CHECKOUT does. If an entry is CE_VALID, it is still in checkout
area. But if it is CE_NO_CHECKOUT, "git grep" should ignore that path.
core.defaultsparse has nothing to do here.
> > > The question, then, is what happens when the index and core.defaultsparse
> > > disagree, either because the porcelain supports causing it or because the
> > > user has simply editting the config file or used plumbing to modify the
> > > index. That is, (1) we have index entries that say that the worktree is
> > > ignored, and the rules don't say they're outside the sparse checkout; do
> > > we care whether we expect the worktree to be empty or match the index?
> > > And, (2) we have index entries that say we do care about them, but the
> > > rules say they're outside the sparse checkout; what happens with these?
> >
> > The rule is CE_NO_CHECKOUT is king. core.defaultsparse only helps
> > setting CE_NO_CHECKOUT on new entries when they enter the index.
>
>
> This seems like a really bad idea to me. If you ask for a file that's
> outside your default area to be checked out, and then you switch branches
> and switch back, the file may or may not disappear (depending on whether
> the branch you switched to temporarily had it or not). Likewise, if you
> remove files, and then switch branches and back, the files may or may not
> reappear.
Well, if you set core.defaultsparse properly, those files should
appear/disappear as you wish (and as of now if you define your
checkout area with "git checkout --{include-,exclude-,}sparse" then
core.defaultsparse should be updated accordingly). I don't say
core.defaultsparse is perfect.
Anyway how do you suppose the tool to do in your case (checkout,
switch away then switch back)?
--
Duy
^ permalink raw reply
* Re: Specifying default checkout branch in url
From: Mikael Magnusson @ 2008-12-11 11:45 UTC (permalink / raw)
To: Resul Cetin; +Cc: git
In-Reply-To: <200812111221.36561.Resul-Cetin@gmx.net>
2008/12/11 Resul Cetin <Resul-Cetin@gmx.net>:
> Hi,
> I have the problem that I want to checkout a specific branch in a git-clone
> run. Someone at the debian-mentors mailing list[1] has suggested to use a url
> like git://git.myserver.org/project.git#branchname to checkout a branch with
> the name branchname by default. But this doesn't seem to work. Is there
> already another way to encode this in the url?
> More information why I cannot change HEAD of the repository can be found in a
> bug report against debcheckout[2].
>
> Regards,
> Resul
>
> [1] http://article.gmane.org/gmane.linux.debian.devel.mentors/34421
> [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=508433
Use a git init, remote add, fetch branchname:branchname sequence.
--
Mikael Magnusson
^ permalink raw reply
* Specifying default checkout branch in url
From: Resul Cetin @ 2008-12-11 11:21 UTC (permalink / raw)
To: git
Hi,
I have the problem that I want to checkout a specific branch in a git-clone
run. Someone at the debian-mentors mailing list[1] has suggested to use a url
like git://git.myserver.org/project.git#branchname to checkout a branch with
the name branchname by default. But this doesn't seem to work. Is there
already another way to encode this in the url?
More information why I cannot change HEAD of the repository can be found in a
bug report against debcheckout[2].
Regards,
Resul
[1] http://article.gmane.org/gmane.linux.debian.devel.mentors/34421
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=508433
^ permalink raw reply
* Re: fatal: $HOME not set
From: Johannes Sixt @ 2008-12-11 11:09 UTC (permalink / raw)
To: JD Guzman; +Cc: git
In-Reply-To: <003a01c95b7c$65b93a40$312baec0$@com>
JD Guzman schrieb:
> This is probably a really stupid question but I'm trying to run git outside
> of the shell provided by msysgit.
> Everything works however when I try to set config options I get the error in
> the subject line. I would suspect this is because the windows command
> prompt isn't providing any information about the user's home directory. My
> question is would this be something that I can set manually or does git rely
> on the OS to provide this information?
You can set it yourself to where you want git to store the .gitconfig
file. Do this in Settings->System->Advanced->Environment Variables,
section User variables. You can set it to %HOMEDRIVE%%HOMEPATH% in order
point it somewhere below C:\Documents and Settings.
-- Hannes
^ permalink raw reply
* fatal: $HOME not set
From: JD Guzman @ 2008-12-11 10:36 UTC (permalink / raw)
To: git
This is probably a really stupid question but I'm trying to run git outside
of the shell provided by msysgit.
Everything works however when I try to set config options I get the error in
the subject line. I would suspect this is because the windows command
prompt isn't providing any information about the user's home directory. My
question is would this be something that I can set manually or does git rely
on the OS to provide this information?
Regards,
JD Guzman
^ permalink raw reply
* Clarifying "invalid tag signature file" error message from git filter-branch (and others)
From: James Youngman @ 2008-12-11 10:14 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 852 bytes --]
What do the errors "error: char88: malformed tagger field" and "fatal:
invalid tag signature file" and "Could not create new tag object for
FINDUTILS-4_1-10" signify in the session below?
Are any of those errors correctable (I can re-run the tree rewrite
script as many times as needed, I'm just using it on a test repository
for now).
The script I'm invoking calls git filter-branch; I've attached the script.
$ bash ~/source/GNU/findutils/logrewrite.sh
fatal: Not a git repository
Rewrite 9afb13614381c4bfa22f515c18cbfe6f54798330 (1587/1587)
Ref 'refs/heads/master' was rewritten
FINDUTILS-4_1-10 -> FINDUTILS-4_1-10
(ce25eb352de8dc53a9a7805ba9efc1c9215d28c2 ->
79221244237bc408ced0c37f3c3476d53e665801)
error: char88: malformed tagger field
fatal: invalid tag signature file
Could not create new tag object for FINDUTILS-4_1-10
$
Thanks,
James.
[-- Attachment #2: logrewrite.sh --]
[-- Type: application/x-sh, Size: 1401 bytes --]
^ permalink raw reply
* Re: malloc fails when dealing with huge files
From: Johannes Schindelin @ 2008-12-11 9:11 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jonathan Blanton, git
In-Reply-To: <alpine.LFD.2.00.0812101121401.3340@localhost.localdomain>
Hi,
On Wed, 10 Dec 2008, Linus Torvalds wrote:
> However, git performance with big files would never be wonderful, and
> things like "git diff" would still end up reading not just the whole
> file, but _both_versions_ at the same time. Marking the big files as
> being no-diff might help, though.
Makes me wonder if we should not have a default cut-off, say, 10MB, at
which files are automatically tagged with the no-diff attribute (unless
overridden explicitely in .gitattributes)?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] modify/delete conflict resolution overwrites untracked file
From: Junio C Hamano @ 2008-12-11 8:13 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: git, Johannes Schindelin, Alex Riesen
In-Reply-To: <20081211080752.GA26709@localhost>
Clemens Buchacher <drizzd@aon.at> writes:
> On Wed, Dec 10, 2008 at 03:36:11PM -0800, Junio C Hamano wrote:
>> Clemens Buchacher <drizzd@aon.at> writes:
>> >
>> > "merge -s resolve" fails with
>> >
>> > Trying really trivial in-index merge...
>> > error: Merge requires file-level merging
>> > Nope.
>> > Trying simple merge.
>> > Simple merge failed, trying Automatic merge.
>> > ERROR: c1.c: Not handling case ae9304576a6ec3419b231b2b9c8e33a06f97f9fb ->
>> > -> 8173b675dc61bb578b411c769c9fb654625a7c4e
>> > fatal: merge program failed
>> > Automatic merge failed; fix conflicts and then commit the result.
>> >
>> > and therefore passes the test.
>>
>> Are you saying that:
>>
>> (1) the step should result in conflict and the merge should fail, but it
>> should not clobber c1.c nevertheless; and
>>
>> (2) resolve fails to merge (as expected), and it does not clobber c1.c
>> (as expected); therefore it passes the test.
>
> The latter.
I said "and" at the end of (1) so I do not understand your answer, but I
take it to mean that both (1) and (2) are true, judging from the rest of
your message.
>> If so, then you now established that it is a bug in merge-recursive,
>> right [implementors of recursive-in-C CC'ed]?
>
> Correct.
>
>> Or are you saying that the step should not fail to begin with?
>
> No...
Ok, thanks. Unfortunately my git day for this week is over, so I'll try
to find time to take a look at what recursive strategy does wrong over the
weekend, if nobody gets to it before me.
^ permalink raw reply
* Re: help needed: Splitting a git repository after subversion migration
From: Björn Steinbrink @ 2008-12-11 8:10 UTC (permalink / raw)
To: Thomas Jarosch; +Cc: Michael J Gruber, git
In-Reply-To: <200812101733.36221.thomas.jarosch@intra2net.com>
On 2008.12.10 17:33:28 +0100, Thomas Jarosch wrote:
> On Monday, 8. December 2008 18:34:20 Thomas Jarosch wrote:
> > 1. When I run "git rev-list --all --objects", I can see file names that
> > look like "SVN-branchname/directory/filename". Is it normal that "git svn"
> > creates a directory with the name of the branch and puts files below it?
>
> Ok, this seems to be a PEBKAC: In the history of the subversion repository,
> f.e. I once copied the "branches" root folder to tags/xyz. One revision later
> I noticed this and retagged the correct branch. git-svn imports all branches
> from the first tag, which is the correct thing to do :o)
>
> Now I'll manually check the history of the tags/ and branches/ folder
> for more funny tags and write down the revision. If I understood
> the git-svn man page correctly, I should be able to specifiy
> revision ranges it's going to import. I'll try to skip the broken tags.
As long as the breakage only involves branches/tags that are completely
useless, it's probably a lot easier to just delete them afterwards.
And if you accidently added changes to a tag, after it was created, it's
also easier to manually tag to right version in git, and just forgetting
about the additional commit.
And for a bunch of other cases, rebase -i/filter-branch are probably
also better options ;-)
Skipping revisions in a git-svn import sounds rather annoying and
error-prone.
Björn
^ permalink raw reply
* Re: [PATCH] modify/delete conflict resolution overwrites untracked file
From: Clemens Buchacher @ 2008-12-11 8:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin, Alex Riesen
In-Reply-To: <7voczjy55g.fsf@gitster.siamese.dyndns.org>
On Wed, Dec 10, 2008 at 03:36:11PM -0800, Junio C Hamano wrote:
> Clemens Buchacher <drizzd@aon.at> writes:
> >
> > "merge -s resolve" fails with
> >
> > Trying really trivial in-index merge...
> > error: Merge requires file-level merging
> > Nope.
> > Trying simple merge.
> > Simple merge failed, trying Automatic merge.
> > ERROR: c1.c: Not handling case ae9304576a6ec3419b231b2b9c8e33a06f97f9fb ->
> > -> 8173b675dc61bb578b411c769c9fb654625a7c4e
> > fatal: merge program failed
> > Automatic merge failed; fix conflicts and then commit the result.
> >
> > and therefore passes the test.
>
> Are you saying that:
>
> (1) the step should result in conflict and the merge should fail, but it
> should not clobber c1.c nevertheless; and
>
> (2) resolve fails to merge (as expected), and it does not clobber c1.c
> (as expected); therefore it passes the test.
The latter.
> If so, then you now established that it is a bug in merge-recursive,
> right [implementors of recursive-in-C CC'ed]?
Correct.
> Or are you saying that the step should not fail to begin with?
No. IMO, merge should fail and abort. That is, it should not modify the
working tree at all and tell the user that an untracked file is in the way.
The tests check that merge returns an error code and c1.c is not modified.
Test number 5 fails, unless the merge strategy resolve is used. While this
indicates a bug in the recursive strategy, I am not satisfied with the error
output of the resolve strategy either. It should output
"error: Untracked working tree file '...' would be overwritten by merge."
just like test number 2 does.
^ permalink raw reply
* Re: epic fsck SIGSEGV!
From: Junio C Hamano @ 2008-12-11 7:53 UTC (permalink / raw)
To: Linus Torvalds
Cc: Nicolas Pitre, R. Tyler Ballance, Johannes Sixt, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0812101930590.3340@localhost.localdomain>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> It has gotten no real testing. Caveat emptor. And I didn't even bother to
> check that it can run with less stack or that it makes any other
> difference.
A quick "git fsck --full" in a copy of git.git (eh, "not-so-quick" on a
not-so-quick machine, obviously) shows that the patch does reduce minor
faults significantly.
(without patch)
83.03user 0.60system 1:23.62elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+158275minor)pagefaults 0swaps
(with object_array patch)
82.88user 0.40system 1:23.28elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+95397minor)pagefaults 0swaps
^ permalink raw reply
* Re: How track evolution of *file* across many branches?
From: Alex Riesen @ 2008-12-11 7:34 UTC (permalink / raw)
To: chris; +Cc: git
In-Reply-To: <20081211071354.GA22730@seberino.org>
2008/12/11 <chris@seberino.org>:
> How track a file across multiple branches.
>
> Specifically...
>
> 1. How find all branches a file appears in?
>
> 2. How find changes in each branch for that one file?
>
gitk --all -- file1
^ 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