* Re: Problems with GIT under Windows - "not uptodate"
From: skillzero @ 2009-09-01 18:19 UTC (permalink / raw)
To: david.hagood; +Cc: git
In-Reply-To: <a21e6af7ee05f56fd8c02d0955af1c72.squirrel@localhost>
On Tue, Sep 1, 2009 at 8:46 AM, <david.hagood@gmail.com> wrote:
> I am having a problem trying to support my poor, deluded cow-orkers who
> use Windows and need to use GIT.
>
> The scenario goes something like this:
>
> They have a local repo, they have changes on their branch, they are
> staging a commit to the master branch on their local.
>
> They do a "git merge" and the merge has conflicts. They need to undo the
> merge, so they do a "git reset --hard".
>
> From that point onward, if they try to access the origin repository (e.g.
> "git pull") they get the error message
>
> Error: Entry "Some file name" not uptodate: cannot merge.
>
> We've tried "git reset --hard; git pull ." We've tried "git reset --hard;
> git checkout -f master". Neither seems to fix this.
>
> We Linux users don't see this.
>
> I conjecture it is something to do with DOS's CR/LF line endings (the
> files in question are a type of XML file which ALWAYS have CR/LF endings,
> even under Linux) - perhaps *something* in the GIT processing chain is
> trying to do a CR/LF -> LF conversion, and screwing things up.
>
> Does anybody have any suggestions on what I am doing wrong (Please, not
> "you are using Windows")?
Yeah I run into the same thing on Windows if somebody accidentally
checks in a CRLF file. Do you have core.autocrlf on? If you do, I
think the problem is that it's going to try to convert the line
endings on every checkout/etc, but since the file is already CRLF (not
LF as is normally in the repository), it's going to make the file look
different every time.
It seems like you want core.autocrlf to be false or you want a
.gitattributes file to override it on a per-file basis for the files
you know are CRLF (i.e. the ones that are CRLF even on the Linux
side).
^ permalink raw reply
* Re: Problems with GIT under Windows - "not uptodate"
From: david.hagood @ 2009-09-01 18:25 UTC (permalink / raw)
To: skillzero; +Cc: david.hagood, git
In-Reply-To: <2729632a0909011119l3a19447ds9d4896a27ac488c1@mail.gmail.com>
> It seems like you want core.autocrlf to be false or you want a
> .gitattributes file to override it on a per-file basis for the files
> you know are CRLF (i.e. the ones that are CRLF even on the Linux
> side).
That's what I've been leaning toward: a .gitattributes in that directory
like this:
*.xml -crlf diff merge
Does that sound reasonable?
^ permalink raw reply
* Re: A note from the maintainer: Follow-up questions (MaintNotes)
From: Junio C Hamano @ 2009-09-01 19:09 UTC (permalink / raw)
To: David Chanters; +Cc: git
In-Reply-To: <ac3d41850909010958l890bf2fyda6e61e3cb082c2a@mail.gmail.com>
David Chanters <david.chanters@googlemail.com> writes:
> 2009/9/1 Junio C Hamano <gitster@pobox.com>:
>> $ git log --oneline --first-parent origin/master..origin/pu
>>
>> would be a handy way to view where the tip of each branch is.
>
> Yes it is - thanks for that! I presume that (in other workflows --
> not necessarily git,git's) that using git-resurrect.sh would be
> preferable to the git-log suggestion above if the topic branch wanting
> to be "resurrected" had several merge points?
AFAIK the script is an (attempt of) automating the inspecting of the above
output and manually choosing which one to use. As automation, it may be
handy, and as automation, it may have bugs ;-).
> Makes sense - and on that note - in our current workflow of using Git,
> we have a feature branch, call it "featureA" which is forked from
> "master" (where our stable code lives) -- but obviously over time, if
> bugfixes happen and get released, what do we do about then ensuring
> that featureA also benefits from these bug-fixes? Since invariably
> people will want to develop using the bug-fixes, but "featureA" long
> since branched from "master" at a point in the past, before the
> bug-fixes?
That is one of the most common misconception people new to the topic
branch workflow have [*1*].
In general, you do not want to merge fixes or other changes from
integration branches back into a topic branch such as featureA. The
purpose of a topic branch is to brew the topic and the topic alone in
isolation to perfection. Once you start merging 'maint' or 'master' into
'featureA', the output from "git log featureA" ceases to be "the work I
did to polish the feature A". The branch becomes "this contains the work
related to feature A, but overwhelmingly consists of other unrelated
random stuff". It would be useless as a topic branch, because you cannot
tell which ones are the changes to achieve the goal of the topic anymore.
When you test featureA, you would test the topic branch itself, and while
doing so, you will of course see bugs that have been fixed since you
forked from the mainline. Do not get distracted by them; you did not fork
the featureA topic in order to fix them in the first place!
Of course, when you test the whole system including the addition of
featureA, you would want to make sure that fixes and enhancements that
happened on the mainline since you forked the topic branch work well with
what you did on the topic.
For that kind of integration testing, either use a temporary branch to
test trial integration:
$ git checkout -b test master ;# start with everything else they did
$ git merge featureA ;# ... and try my topic with that
$ test..test..test
and once you are done, you can get rid of the test branch
$ git checkout master
$ git branch -D test
You can alternatively have a dedicated branch for early integration
testing. That is what 'next' branch is used for in git.git project.
$ git checkout next
$ git merge featureA ;# ... merge the update
$ test..test..test
... yeek, my changes were buggy ...
$ git reset --hard HEAD^ ;# get rid of the change
$ git checkout featureA
$ fix..fix..fix
$ git checkout next
$ git merge featureA ;# ... try again
$ test..test..test
... this time it is good and I am happy ...
[Footnote]
*1* I think I have had a chance to answer this question in a lot more
detail at least twice in the past couple of weeks on this list, and both
times it was very frustrating for me, not because I did not want to answer
them, but because I've written it in length in my upcoming book but
pointing to it would not help people who asked the question because it is
in Japanese. I've been writing on a handful of topics I thought were
worthy of general consumption on my blog while writing the book, but this
is one of the topics that I haven't "backported" there yet X-<.
^ permalink raw reply
* Re: unmerged files listed in the beginning of git-status
From: Johannes Sixt @ 2009-09-01 19:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: bill lam, git
In-Reply-To: <7vljkypqfi.fsf@alter.siamese.dyndns.org>
On Dienstag, 1. September 2009, Junio C Hamano wrote:
> bill lam <cbill.lam@gmail.com> writes:
> > git-status show unmerged files
> > with a clause of explanation. This is very helpful. However these
> > unmerged files are listed in the beginning and followed by modified
> > files,
>
> "git status" is preview of what git commit does. The "Changes to be
> committed" section is given at the beginning of the output because it is
> the most important one. But while reviewing the conflicts, you would want
> to notice conflicted paths more than what are already resolved and staged.
>
> It used to be that unmerged paths were mixed together with locally
> modified paths in the "Changed but not updated" list, after the "Changes
> to be committed" list. This made the unmerged paths harder to spot than
> necessary.
>
> To remedy this, unmerged ones are now:
>
> (1) placed in a new, separate section that appears only when there are
> unmerged paths, to make the fact that there is something unusual
> going on (i.e. conflicts) stand out; and
>
> (2) the new section is given at the top of the status output to give
> these unmerged paths more prominence.
But this is very inconvenient if you merge a branch that touched many files,
of which only a few have conflicts. In this case, the unmerged entries are
scrolled out of view. If you want to copy-paste them into a 'git add' command
then (at least my) xterm (and Windows's CMD, BTW) keeps scrolling down to the
command line, and since I cannot bulk-select all of them at once, I have to
scroll up in order select any individual of them.
Note that I do not complain about the "out of view" part (because if a list is
long there is inevitably something that becomes invisible), but about
the "must scroll around" part.
> But unmerged entries are something you need to deal with _first_ before
> being able to go further, so in that sense it is more important than
> anything else in the traditional output.
This is actually an argument to place the unmerged entries *last* because this
is what will be visible after 'git status' finished. Remember that we don't
pass its output through the pager.
> In the output, "the most important part first" rule is unlikely to change,
> if only because this is what you are shown when committing in the editor,
> and even in 1.7.0 when "git status" stops being "git commit --dry-run"
> because we would still keep consistency of the two outputs,
Of course, this argument is irrelevant for the placement of the list of
unmerged entries because by the time you enter the commit message editor,
this list is empty.
-- Hannes
^ permalink raw reply
* [PATCH] Make git status print a helpful death message if the disk is full
From: David Reiss @ 2009-09-01 19:51 UTC (permalink / raw)
To: git
The old behavior just said that it failed. Now it includes the error
information, which makes it much easier to debug.
There is a risk that some failure paths could result in misleading error
messages that actually make debugging more difficult.
Signed-off-by: David Reiss <dreiss@facebook.com>
---
builtin-commit.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index 4bcce06..3527c73 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -256,7 +256,7 @@ static char *prepare_index(int argc, const char **argv, const char *prefix)
refresh_cache(REFRESH_QUIET);
if (write_cache(fd, active_cache, active_nr) ||
close_lock_file(&index_lock))
- die("unable to write new_index file");
+ die("unable to write new_index file: %s", strerror(errno));
commit_style = COMMIT_NORMAL;
return index_lock.filename;
}
@@ -275,7 +275,7 @@ static char *prepare_index(int argc, const char **argv, const char *prefix)
refresh_cache(REFRESH_QUIET);
if (write_cache(fd, active_cache, active_nr) ||
commit_locked_index(&index_lock))
- die("unable to write new_index file");
+ die("unable to write new_index file: %s", strerror(errno));
commit_style = COMMIT_AS_IS;
return get_index_file();
}
@@ -318,7 +318,7 @@ static char *prepare_index(int argc, const char **argv, const char *prefix)
refresh_cache(REFRESH_QUIET);
if (write_cache(fd, active_cache, active_nr) ||
close_lock_file(&index_lock))
- die("unable to write new_index file");
+ die("unable to write new_index file: %s", strerror(errno));
fd = hold_lock_file_for_update(&false_lock,
git_path("next-index-%"PRIuMAX,
--
1.6.0.4
^ permalink raw reply related
* [PATCH] status: list unmerged files after staged files
From: Johannes Sixt @ 2009-09-01 20:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: bill lam, git
In-Reply-To: <200909012140.08953.j6t@kdbg.org>
The list of unmerged files is considered rather important because after
a conflicted merge they need attention. Since the output of git status does
not go through the pager, the end of the output remains immediately visible
in the terminal window. By placing unmerge entries after staged entries,
the user can see them immediately.
Moreover, keeping the unmerge entries at the top is inconvenient if a merge
touched many files, but only a few conflicted: After the conflicts were
resolved, the user will conduct a 'git add' command. In order to do that
with copy-and-paste, the user must scroll the terminal window up, and must
do so for each individual entry (because terminal windows commonly scroll
down automatically on the paste operation to make the cursor visible).
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
wt-status.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/wt-status.c b/wt-status.c
index 3395456..85f3fcb 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -561,8 +561,8 @@ void wt_status_print(struct wt_status *s)
color_fprintf_ln(s->fp, color(WT_STATUS_HEADER, s), "#");
}
- wt_status_print_unmerged(s);
wt_status_print_updated(s);
+ wt_status_print_unmerged(s);
wt_status_print_changed(s);
if (s->submodule_summary)
wt_status_print_submodule_summary(s);
--
1.6.4.2.280.gb16ab
^ permalink raw reply related
* Re: [PATCH] Make git status print a helpful death message if the disk is full
From: Junio C Hamano @ 2009-09-01 20:19 UTC (permalink / raw)
To: David Reiss; +Cc: git
In-Reply-To: <4A9D7B54.5020902@facebook.com>
Don't we have die_errno() or something since at least 1.6.4?
^ permalink raw reply
* [PATCH-v2] Make git status print a helpful death message if the disk is full
From: David Reiss @ 2009-09-01 20:27 UTC (permalink / raw)
To: git
The old behavior just said that it failed. Now it includes the error
information, which makes it much easier to debug.
There is a risk that some failure paths could result in misleading error
messages that actually make debugging more difficult.
Signed-off-by: David Reiss <dreiss@facebook.com>
---
Sorry I missed that.
builtin-commit.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index 4bcce06..7feb598 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -256,7 +256,7 @@ static char *prepare_index(int argc, const char **argv, const char *prefix)
refresh_cache(REFRESH_QUIET);
if (write_cache(fd, active_cache, active_nr) ||
close_lock_file(&index_lock))
- die("unable to write new_index file");
+ die_errno("unable to write new_index file");
commit_style = COMMIT_NORMAL;
return index_lock.filename;
}
@@ -275,7 +275,7 @@ static char *prepare_index(int argc, const char **argv, const char *prefix)
refresh_cache(REFRESH_QUIET);
if (write_cache(fd, active_cache, active_nr) ||
commit_locked_index(&index_lock))
- die("unable to write new_index file");
+ die_errno("unable to write new_index file");
commit_style = COMMIT_AS_IS;
return get_index_file();
}
@@ -318,7 +318,7 @@ static char *prepare_index(int argc, const char **argv, const char *prefix)
refresh_cache(REFRESH_QUIET);
if (write_cache(fd, active_cache, active_nr) ||
close_lock_file(&index_lock))
- die("unable to write new_index file");
+ die_errno("unable to write new_index file");
fd = hold_lock_file_for_update(&false_lock,
git_path("next-index-%"PRIuMAX,
--
1.6.0.4
^ permalink raw reply related
* Re: [PATCH] Make git status print a helpful death message if the disk is full
From: Thomas Rast @ 2009-09-01 20:35 UTC (permalink / raw)
To: David Reiss; +Cc: git, Junio C Hamano
In-Reply-To: <4A9D7B54.5020902@facebook.com>
[-- Attachment #1: Type: Text/Plain, Size: 1042 bytes --]
David Reiss wrote:
> The old behavior just said that it failed. Now it includes the error
> information, which makes it much easier to debug.
>
> There is a risk that some failure paths could result in misleading error
> messages that actually make debugging more difficult.
[...]
> if (write_cache(fd, active_cache, active_nr) ||
> close_lock_file(&index_lock))
> - die("unable to write new_index file");
> + die("unable to write new_index file: %s", strerror(errno));
Junio C Hamano wrote:
> Don't we have die_errno() or something since at least 1.6.4?
Yes. And during the conversion, I ignored call sites like this one
precisely because I did not (and still do not) have enough knowledge
of the index and lock file machinery to decide at what stage I need to
read errno to get the *real* error message. You're of course welcome
to dig into the code to verify that the above is correct, but I am
against blindly hoping that it gives the right error.
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] status: list unmerged files after staged files
From: Junio C Hamano @ 2009-09-01 20:38 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, bill lam, git
In-Reply-To: <200909012213.54611.j6t@kdbg.org>
Johannes Sixt <j6t@kdbg.org> writes:
> Moreover, keeping the unmerge entries at the top is inconvenient if a merge
> touched many files, but only a few conflicted: After the conflicts were
> resolved, the user will conduct a 'git add' command. In order to do that
> with copy-and-paste, the user must scroll the terminal window up, and must
> do so for each individual entry (because terminal windows commonly scroll
> down automatically on the paste operation to make the cursor visible).
I actually was expecting that you would move this at the very bottom after
untracked list for the above reason, and also because this part is only
shown while running status (that was a good point you made in the previous
message) and never in commit.
>
> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
> ---
> wt-status.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/wt-status.c b/wt-status.c
> index 3395456..85f3fcb 100644
> --- a/wt-status.c
> +++ b/wt-status.c
> @@ -561,8 +561,8 @@ void wt_status_print(struct wt_status *s)
> color_fprintf_ln(s->fp, color(WT_STATUS_HEADER, s), "#");
> }
>
> - wt_status_print_unmerged(s);
> wt_status_print_updated(s);
> + wt_status_print_unmerged(s);
> wt_status_print_changed(s);
> if (s->submodule_summary)
> wt_status_print_submodule_summary(s);
> --
> 1.6.4.2.280.gb16ab
^ permalink raw reply
* [JGIT] potential incompatibility with old git repos.
From: Mark Struberg @ 2009-09-01 21:07 UTC (permalink / raw)
To: Shawn Spearce, robin.rosenberg; +Cc: git
Hi Shawn, Robin!
I'm happy to spend some time on the maven-scm-providers-jgit again, but spotted a problem with running the latest version of JGIT on my test repository [1]. This test repo has been created a good while ago (~nov 2007) with git 1.3.54 or so and has been edited on various computers.
It works with native git but crashes with both SimpleRepository#clone [2] and jgit.
jgit fails with "cannot checkout; no HEAD advertised by remote"
in guessHEAD
JGIT used to work on this repo until a few weeks. I tracked it down with git bisect and found commit
72b1f0d334729a49cc52e4762093148be62bea39
to be the bad one.
I glimpsed at the code and it appears that the new code in RefDatabase#readLine is not Windows CR+LF aware. (This hits me although I use Linux because our SVN at apache.org seems to have it stored with CR+LF.)
Patch will follow.
txs and LieGrue,
strub
[1] http://github.com/struberg/maven-scm-providers-git/tree/a66e9470ea087030bb8bd40edb2cab22a2de0e6a/maven-scm-provider-gittest/src/main/resources/repository/test-repo
[2] http://github.com/sonatype/JGit/tree/struberg
^ permalink raw reply
* [JGIT PATCH] fixed error in whitespace handling of RefDatabase#readLine
From: Mark Struberg @ 2009-09-01 21:18 UTC (permalink / raw)
To: Shawn Spearce, robin.rosenberg; +Cc: git
jgit fails with "cannot checkout; no HEAD advertised by remote"
in guessHEAD on some repositories.
JGIT used to work on my test repo for the maven-scm-providers-git until a few weeks. I tracked it down with git bisect and found commit 72b1f0d334729a49cc52e4762093148be62bea39 to be the bad one.
I glimpsed at the code and it appears that the new code in RefDatabase#readLine is not Windows CR+LF aware. (This hits me although I use Linux because our SVN at apache.org seems to have it stored with CR+LF.)
Fixed by subsequently removing all Character.isWhitespaceChar() from the end of the buffer
Signed-off-by: Mark Struberg <struberg@yahoo.de>
---
.../src/org/spearce/jgit/lib/RefDatabase.java | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/RefDatabase.java b/org.spearce.jgit/src/org/spearce/jgit/lib/RefDatabase.java
index ba4b654..477dc62 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/lib/RefDatabase.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/lib/RefDatabase.java
@@ -500,8 +500,12 @@ private static String readLine(final File file)
int n = buf.length;
if (n == 0)
return null;
- if (buf[n - 1] == '\n')
+
+ // remove trailing whitespaces
+ while (n > 0 && Character.isWhitespace(buf[n - 1])) {
n--;
+ }
+
return RawParseUtils.decode(buf, 0, n);
}
--
1.6.2.5
^ permalink raw reply related
* [PATCH v2] status: list unmerged files last
From: Johannes Sixt @ 2009-09-01 21:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: bill lam, git
In-Reply-To: <7vy6oy9z9r.fsf@alter.siamese.dyndns.org>
The list of unmerged files is considered rather important because after
a conflicted merge they need attention. Since the output of git status does
not go through the pager, the end of the output remains immediately visible
in the terminal window. By placing unmerge entries at the end of the list,
the user can see them immediately.
Moreover, keeping the unmerge entries at the top is inconvenient if a merge
touched many files, but only a few conflicted: After the conflicts were
resolved, the user will conduct a 'git add' command. In order to do that
with copy-and-paste, the user must scroll the terminal window up, and must
do so for each individual entry (because terminal windows commonly scroll
down automatically on the paste operation to make the cursor visible).
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
On Dienstag, 1. September 2009, Junio C Hamano wrote:
> Johannes Sixt <j6t@kdbg.org> writes:
> > Moreover, keeping the unmerge entries at the top is inconvenient if a
> > merge touched many files, but only a few conflicted: After the conflicts
> > were resolved, the user will conduct a 'git add' command. In order to do
> > that with copy-and-paste, the user must scroll the terminal window up,
> > and must do so for each individual entry (because terminal windows
> > commonly scroll down automatically on the paste operation to make the
> > cursor visible).
>
> I actually was expecting that you would move this at the very bottom after
> untracked list for the above reason, and also because this part is only
> shown while running status (that was a good point you made in the previous
> message) and never in commit.
So you would not mind a more "drastic" change?
This version 2 can be regarded as a real improvement with the argument
above, whereas version 1 would only correct something of some
sort of regression, compared to v1.6.4.
(Originally I didn't dare to change too much and thought keeping staged
files together would make sense.)
-- Hannes
wt-status.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/wt-status.c b/wt-status.c
index 3395456..60d8425 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -561,7 +561,6 @@ void wt_status_print(struct wt_status *s)
color_fprintf_ln(s->fp, color(WT_STATUS_HEADER, s), "#");
}
- wt_status_print_unmerged(s);
wt_status_print_updated(s);
wt_status_print_changed(s);
if (s->submodule_summary)
@@ -570,6 +569,7 @@ void wt_status_print(struct wt_status *s)
wt_status_print_untracked(s);
else if (s->commitable)
fprintf(s->fp, "# Untracked files not listed (use -u option to show untracked
files)\n");
+ wt_status_print_unmerged(s);
if (s->verbose)
wt_status_print_verbose(s);
--
1.6.4.2.280.gb16ab
^ permalink raw reply related
* [JGIT PATCH] move the 'empty-line' check in RefDatabase#readLine down a bit to after we removed all the whitespaces.
From: Mark Struberg @ 2009-09-01 21:41 UTC (permalink / raw)
To: Shawn Spearce, robin.rosenberg; +Cc: git
This way we consistently return null regardless if the line is empty or if it does only contain whitespaces.
Signed-off-by: Mark Struberg <struberg@yahoo.de>
---
.../src/org/spearce/jgit/lib/RefDatabase.java | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/RefDatabase.java b/org.spearce.jgit/src/org/spearce/jgit/lib/RefDatabase.java
index 477dc62..acc835b 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/lib/RefDatabase.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/lib/RefDatabase.java
@@ -498,14 +498,15 @@ private static String readLine(final File file)
throws FileNotFoundException, IOException {
final byte[] buf = NB.readFully(file, 4096);
int n = buf.length;
- if (n == 0)
- return null;
// remove trailing whitespaces
while (n > 0 && Character.isWhitespace(buf[n - 1])) {
n--;
}
-
+
+ if (n == 0)
+ return null;
+
return RawParseUtils.decode(buf, 0, n);
}
--
1.6.2.5
^ permalink raw reply related
* Re: What's cooking in git.git (Aug 2009, #06; Sun, 30)
From: Nick Edelen @ 2009-09-01 22:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7viqg48nxi.fsf@alter.siamese.dyndns.org>
> * ne/rev-cache (2009-08-21) 6 commits
> . support for path name caching in rev-cache
> . full integration of rev-cache into git, completed test suite
> . administrative functions for rev-cache, start of integration into git
> . support for non-commit object caching in rev-cache
> . basic revision cache system, no integration or features
> . man page and technical discussion for rev-cache
>
> Updated but seems to break upload-pack tests when merged to 'pu'; given
> what this series touches, breakages in that area are expected.
> May discard if a working reroll comes, to give it a fresh start.
I vaguely remember something concerning those tests when starting the
project. I'm a bit disconnected from everything right now, but I'll
try to get those fixed as soon as I can.
^ permalink raw reply
* Re: Problems with GIT under Windows - "not uptodate"
From: Johannes Schindelin @ 2009-09-01 22:56 UTC (permalink / raw)
To: Eric Raible; +Cc: git, david.hagood
In-Reply-To: <loom.20090901T184650-434@post.gmane.org>
Hi,
Eric, is there any good reason you neglect netiquette? I re-added David
to the Cc: list.
On Tue, 1 Sep 2009, Eric Raible wrote:
> <david.hagood <at> gmail.com> writes:
>
> > Error: Entry "Some file name" not uptodate: cannot merge.
> >
> > We've tried "git reset --hard; git pull ." We've tried "git reset --hard;
> > git checkout -f master". Neither seems to fix this.
>
> http://article.gmane.org/gmane.comp.version-control.git/122862
To summarize: the suggestion is "rm .git/index && git reset --hard".
I have to stress the same point as in "reset --hard considered harmful" a
while back, though.
Actually, I started writing a patch to provide "git checkout --fix-crlf"
some weeks ago, but I constantly run out of time to finish it.
Ciao,
Dscho
^ permalink raw reply
* Re: [JGIT PATCH] fixed error in whitespace handling of RefDatabase#readLine
From: Shawn O. Pearce @ 2009-09-01 23:15 UTC (permalink / raw)
To: Mark Struberg; +Cc: robin.rosenberg, git
In-Reply-To: <196796.47610.qm@web27808.mail.ukl.yahoo.com>
Mark Struberg <struberg@yahoo.de> wrote:
> jgit fails with "cannot checkout; no HEAD advertised by remote"
> in guessHEAD on some repositories.
...
> @@ -500,8 +500,12 @@ private static String readLine(final File file)
> int n = buf.length;
> if (n == 0)
Whitespace damage here, the patch won't apply as-is.
Also, please line wrap your commit message.
--
Shawn.
^ permalink raw reply
* Re: Problems with GIT under Windows - "not uptodate"
From: Eric Raible @ 2009-09-01 23:16 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, david.hagood
In-Reply-To: <alpine.DEB.1.00.0909020052550.8306@pacific.mpi-cbg.de>
On Tue, Sep 1, 2009 at 3:56 PM, Johannes
Schindelin<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> Eric, is there any good reason you neglect netiquette? I re-added David
> to the Cc: list.
Thanks. Frankly I (stupidly) assumed that gmane.org would handle it.
Educate me (if you would): if I read the git list via gmane, what's the
best way to follow up?
^ permalink raw reply
* [JGIT PATCH (RESEND) 1/3] Allow RefUpdate.setExpectedOldObjectId to accept RevCommit
From: Shawn O. Pearce @ 2009-09-01 23:16 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git, Shawn O. Pearce
RevCommit overrides .equals() such that it only implements a
reference equality test. If the expected old ObjectId was set
by the application to a RevCommit instance, it would always fail,
resulting in LOCK_FAILURE. Instead use AnyObject.equals() to compare
the value, ignoring the possibly overloaded equals in RevCommit.
Signed-off-by: Shawn O. Pearce <sop@google.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
.../tst/org/spearce/jgit/lib/RefUpdateTest.java | 52 ++++++++++++++++++++
.../src/org/spearce/jgit/lib/RefUpdate.java | 2 +-
2 files changed, 53 insertions(+), 1 deletions(-)
diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/RefUpdateTest.java b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/RefUpdateTest.java
index 800c0a4..a8ccf43 100644
--- a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/RefUpdateTest.java
+++ b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/RefUpdateTest.java
@@ -45,6 +45,7 @@
import org.spearce.jgit.lib.RefUpdate.Result;
import org.spearce.jgit.revwalk.RevCommit;
+import org.spearce.jgit.revwalk.RevWalk;
public class RefUpdateTest extends RepositoryTestCase {
@@ -397,6 +398,57 @@ public void testUpdateRefLockFailureWrongOldValue() throws IOException {
}
/**
+ * Try modify a ref forward, fast forward, checking old value first
+ *
+ * @throws IOException
+ */
+ public void testUpdateRefForwardWithCheck1() throws IOException {
+ ObjectId ppid = db.resolve("refs/heads/master^");
+ ObjectId pid = db.resolve("refs/heads/master");
+
+ RefUpdate updateRef = db.updateRef("refs/heads/master");
+ updateRef.setNewObjectId(ppid);
+ updateRef.setForceUpdate(true);
+ Result update = updateRef.update();
+ assertEquals(Result.FORCED, update);
+ assertEquals(ppid, db.resolve("refs/heads/master"));
+
+ // real test
+ RefUpdate updateRef2 = db.updateRef("refs/heads/master");
+ updateRef2.setExpectedOldObjectId(ppid);
+ updateRef2.setNewObjectId(pid);
+ Result update2 = updateRef2.update();
+ assertEquals(Result.FAST_FORWARD, update2);
+ assertEquals(pid, db.resolve("refs/heads/master"));
+ }
+
+ /**
+ * Try modify a ref forward, fast forward, checking old commit first
+ *
+ * @throws IOException
+ */
+ public void testUpdateRefForwardWithCheck2() throws IOException {
+ ObjectId ppid = db.resolve("refs/heads/master^");
+ ObjectId pid = db.resolve("refs/heads/master");
+
+ RefUpdate updateRef = db.updateRef("refs/heads/master");
+ updateRef.setNewObjectId(ppid);
+ updateRef.setForceUpdate(true);
+ Result update = updateRef.update();
+ assertEquals(Result.FORCED, update);
+ assertEquals(ppid, db.resolve("refs/heads/master"));
+
+ // real test
+ RevCommit old = new RevWalk(db).parseCommit(ppid);
+ RefUpdate updateRef2 = db.updateRef("refs/heads/master");
+ updateRef2.setExpectedOldObjectId(old);
+ updateRef2.setNewObjectId(pid);
+ Result update2 = updateRef2.update();
+ assertEquals(Result.FAST_FORWARD, update2);
+ assertEquals(pid, db.resolve("refs/heads/master"));
+ }
+
+ /**
* Try modify a ref that is locked
*
* @throws IOException
diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/RefUpdate.java b/org.spearce.jgit/src/org/spearce/jgit/lib/RefUpdate.java
index 69399ec..8dffed2 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/lib/RefUpdate.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/lib/RefUpdate.java
@@ -466,7 +466,7 @@ private Result updateImpl(final RevWalk walk, final Store store)
if (expValue != null) {
final ObjectId o;
o = oldValue != null ? oldValue : ObjectId.zeroId();
- if (!expValue.equals(o))
+ if (!AnyObjectId.equals(expValue, o))
return Result.LOCK_FAILURE;
}
if (oldValue == null)
--
1.6.4.1.341.gf2a44
^ permalink raw reply related
* [JGIT PATCH (RESEND) 2/3] Work around Sun javac compiler error in RefUpdate
From: Shawn O. Pearce @ 2009-09-01 23:16 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git, Shawn O. Pearce
In-Reply-To: <1251847010-9992-1-git-send-email-spearce@spearce.org>
Sun's javac, version 5 and 6, apparently miscompiles the for loop
which is looking for a conflicting ref name in the existing set of
refs for this repository.
Debugging this code showed the control flow to return LOCK_FAILURE
when startsWith returned false, which is highly illogical and the
exact opposite of what we have written here.
Sun's javap tool was unable to disassemble the compiled method.
Instead it simply failed to produce anything about updateImpl.
So my remark about the code being compiled wrong is only a guess
based on how I observed the behavior, and not by actually studying
the resulting instructions.
Eclipse's JDT appears to have compiled the updateImpl method
correctly, and produces a working executable. But this is a
much less common compiler to build Java libraries with.
This refactoring to extract the name conflicting test out into
its own method appears to work around the Sun javac bug, and the
resulting class works correctly with either compiler. The code is
also more clear, so its a gain either way.
Signed-off-by: Shawn O. Pearce <sop@google.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
.../src/org/spearce/jgit/lib/RefUpdate.java | 26 +++++++++++++-------
1 files changed, 17 insertions(+), 9 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/RefUpdate.java b/org.spearce.jgit/src/org/spearce/jgit/lib/RefUpdate.java
index 8dffed2..8226e10 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/lib/RefUpdate.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/lib/RefUpdate.java
@@ -449,15 +449,8 @@ private Result updateImpl(final RevWalk walk, final Store store)
RevObject newObj;
RevObject oldObj;
- int lastSlash = getName().lastIndexOf('/');
- if (lastSlash > 0)
- if (db.getRepository().getRef(getName().substring(0, lastSlash)) != null)
- return Result.LOCK_FAILURE;
- String rName = getName() + "/";
- for (Ref r : db.getAllRefs().values()) {
- if (r.getName().startsWith(rName))
- return Result.LOCK_FAILURE;
- }
+ if (isNameConflicting())
+ return Result.LOCK_FAILURE;
lock = new LockFile(looseFile);
if (!lock.lock())
return Result.LOCK_FAILURE;
@@ -490,6 +483,21 @@ private Result updateImpl(final RevWalk walk, final Store store)
}
}
+ private boolean isNameConflicting() throws IOException {
+ final String myName = getName();
+ final int lastSlash = myName.lastIndexOf('/');
+ if (lastSlash > 0)
+ if (db.getRepository().getRef(myName.substring(0, lastSlash)) != null)
+ return true;
+
+ final String rName = myName + "/";
+ for (Ref r : db.getAllRefs().values()) {
+ if (r.getName().startsWith(rName))
+ return true;
+ }
+ return false;
+ }
+
private static RevObject safeParse(final RevWalk rw, final AnyObjectId id)
throws IOException {
try {
--
1.6.4.1.341.gf2a44
^ permalink raw reply related
* [JGIT PATCH (RESEND) 3/3] Fix DirCache.findEntry to work on an empty cache
From: Shawn O. Pearce @ 2009-09-01 23:16 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git, Shawn O. Pearce
In-Reply-To: <1251847010-9992-2-git-send-email-spearce@spearce.org>
If the cache has no entries, we want to return -1 rather than throw
ArrayIndexOutOfBoundsException. This binary search loop was stolen
from some other code which contained a test before the loop to see if
the collection was empty or not, but we failed to include that here.
Flipping the loop around to a standard while loop ensures we test
the condition properly first.
Signed-off-by: Shawn O. Pearce <sop@google.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
.../spearce/jgit/dircache/DirCacheBasicTest.java | 6 ++++++
.../src/org/spearce/jgit/dircache/DirCache.java | 6 ++----
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/dircache/DirCacheBasicTest.java b/org.spearce.jgit.test/tst/org/spearce/jgit/dircache/DirCacheBasicTest.java
index b3097ac..4d737c0 100644
--- a/org.spearce.jgit.test/tst/org/spearce/jgit/dircache/DirCacheBasicTest.java
+++ b/org.spearce.jgit.test/tst/org/spearce/jgit/dircache/DirCacheBasicTest.java
@@ -39,6 +39,7 @@
import java.io.File;
+import org.spearce.jgit.lib.Constants;
import org.spearce.jgit.lib.RepositoryTestCase;
public class DirCacheBasicTest extends RepositoryTestCase {
@@ -182,4 +183,9 @@ public void testBuildThenClear() throws Exception {
assertEquals(0, dc.getEntryCount());
}
+ public void testFindOnEmpty() throws Exception {
+ final DirCache dc = DirCache.newInCore();
+ final byte[] path = Constants.encode("a");
+ assertEquals(-1, dc.findEntry(path, path.length));
+ }
}
diff --git a/org.spearce.jgit/src/org/spearce/jgit/dircache/DirCache.java b/org.spearce.jgit/src/org/spearce/jgit/dircache/DirCache.java
index bfb7925..9f0810a 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/dircache/DirCache.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/dircache/DirCache.java
@@ -583,8 +583,6 @@ public void unlock() {
* information. If < 0 the entry does not exist in the index.
*/
public int findEntry(final String path) {
- if (entryCnt == 0)
- return -1;
final byte[] p = Constants.encode(path);
return findEntry(p, p.length);
}
@@ -592,7 +590,7 @@ public int findEntry(final String path) {
int findEntry(final byte[] p, final int pLen) {
int low = 0;
int high = entryCnt;
- do {
+ while (low < high) {
int mid = (low + high) >>> 1;
final int cmp = cmp(p, pLen, sortedEntries[mid]);
if (cmp < 0)
@@ -603,7 +601,7 @@ else if (cmp == 0) {
return mid;
} else
low = mid + 1;
- } while (low < high);
+ }
return -(low + 1);
}
--
1.6.4.1.341.gf2a44
^ permalink raw reply related
* Re: Problems with GIT under Windows - "not uptodate"
From: Johannes Schindelin @ 2009-09-01 23:19 UTC (permalink / raw)
To: Eric Raible; +Cc: git, david.hagood
In-Reply-To: <279b37b20909011616x60fc7bfav22daca1bc7bfc714@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 560 bytes --]
Hi,
On Tue, 1 Sep 2009, Eric Raible wrote:
> On Tue, Sep 1, 2009 at 3:56 PM, Johannes
> Schindelin<Johannes.Schindelin@gmx.de> wrote:
>
> > Eric, is there any good reason you neglect netiquette? I re-added
> > David to the Cc: list.
>
> Thanks. Frankly I (stupidly) assumed that gmane.org would handle it.
> Educate me (if you would): if I read the git list via gmane, what's the
> best way to follow up?
No idea. I read the mails in a normal mail program. You'll have to find
out yourself how to behave nicely with GMane's interface.
Ciao,
Dscho
^ permalink raw reply
* Re: [JGIT PATCH (RESEND) 1/3] Allow RefUpdate.setExpectedOldObjectId to accept RevCommit
From: Shawn O. Pearce @ 2009-09-01 23:18 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <1251847010-9992-1-git-send-email-spearce@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> wrote:
> Subject: Re: [JGIT PATCH (RESEND) 1/3] Allow RefUpdate.setExpectedOldObjectId to accept RevCommit
Sorry, this is not a resend, its the first time I've sent it...
--
Shawn.
^ permalink raw reply
* Re: [PATCH v2] status: list unmerged files last
From: Junio C Hamano @ 2009-09-02 0:18 UTC (permalink / raw)
To: Johannes Sixt; +Cc: bill lam, git
In-Reply-To: <200909012325.45739.j6t@kdbg.org>
Johannes Sixt <j6t@kdbg.org> writes:
> The list of unmerged files is considered rather important because after
> a conflicted merge they need attention. Since the output of git status does
> not go through the pager, the end of the output remains immediately visible
> in the terminal window. By placing unmerge entries at the end of the list,
> the user can see them immediately.
>
> Moreover, keeping the unmerge entries at the top is inconvenient if a merge
> touched many files, but only a few conflicted: After the conflicts were
> resolved, the user will conduct a 'git add' command. In order to do that
> with copy-and-paste, the user must scroll the terminal window up, and must
> do so for each individual entry (because terminal windows commonly scroll
> down automatically on the paste operation to make the cursor visible).
>
> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
> On Dienstag, 1. September 2009, Junio C Hamano wrote:
>
>> I actually was expecting that you would move this at the very bottom after
>> untracked list for the above reason, and also because this part is only
>> shown while running status (that was a good point you made in the previous
>> message) and never in commit.
>
> So you would not mind a more "drastic" change?
Well, it's not really about what _I_ like or mind. It is primarily about
what the list collectively thinks. I'd like to let other eyeballs and
brains to weigh in, as I am known to pick the worst layout from the UI
point of view as you saw in this thread already ;-).
> (Originally I didn't dare to change too much and thought keeping staged
> files together would make sense.)
Yes, unmerged ones are modified and the index knows about them, but you
haven't told git what you want to commit yet, so they are in the same
category as "changed but not updated" in that sense, but unlike "changed
but not updated", you cannot leave them as they are before proceeding, so
they are worse.
The "keeping related things together" argument does mean your v1 is better
than this patch, as you had "unmerged" next to "changed but not updated".
I personally think the "keep related things together" argument makes much
more sense than the "close to the bottom is easier to cut and paste"
argument, as I tend to focus at the top of the output when looking at the
status output and almost never cut & paste using mouse (screen for
rectangular cutting and pasting works wonderfully), but it probably is
just me. And remember that I am only just one of the users, nothing more.
Sadly, "keep related things together" and "as close to the bottom as
possible" are not quite compatible, and we can pick one or the other, but
not both.
If I were to pick the middle ground, I would probably move it immediately
after the call to wt_status_print_changed(), with "keeping related things
together" as the primary justification. It would be an incidental benefit
that it moves the part slightly closer to the bottom and gives it a better
chance of staying on the screen.
But I am not a great UI designer ;-)
^ permalink raw reply
* Re: [PATCH v2] status: list unmerged files last
From: bill lam @ 2009-09-02 0:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, bill lam, git
In-Reply-To: <7vtyzmxkpr.fsf@alter.siamese.dyndns.org>
On Tue, 01 Sep 2009, Junio C Hamano wrote:
> Sadly, "keep related things together" and "as close to the bottom as
> possible" are not quite compatible, and we can pick one or the other, but
> not both.
>
> If I were to pick the middle ground, I would probably move it immediately
> after the call to wt_status_print_changed(), with "keeping related things
> together" as the primary justification. It would be an incidental benefit
> that it moves the part slightly closer to the bottom and gives it a better
> chance of staying on the screen.
I can only speak of my personal experience that during rebase -i,
there is no (or very few) untracked files in the list so that the
sequence "modified, unmerged, untracked" is also a good alternative.
(I hope the mail-followup-to is correct this time)
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
^ 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