* [EGIT PATCH 1/7] Test the origName part of the key vs the ref itself
From: Robin Rosenberg @ 2008-11-07 22:07 UTC (permalink / raw)
To: spearce; +Cc: git, Robin Rosenberg
In-Reply-To: <1226095664-13759-1-git-send-email-robin.rosenberg@dewire.com>
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
.../tst/org/spearce/jgit/lib/RefUpdateTest.java | 10 ++++++++++
1 files changed, 10 insertions(+), 0 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 6e2cfa8..12f9ada 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
@@ -39,6 +39,8 @@
import java.io.File;
import java.io.IOException;
+import java.util.Map;
+import java.util.Map.Entry;
import org.spearce.jgit.lib.RefUpdate.Result;
@@ -127,4 +129,12 @@ public void testDeleteEmptyDirs() throws IOException {
private void assertExists(final boolean expected, final String name) {
assertEquals(expected, new File(db.getDirectory(), name).exists());
}
+
+ public void testRefKeySameAsOrigName() {
+ Map<String, Ref> allRefs = db.getAllRefs();
+ for (Entry<String, Ref> e : allRefs.entrySet()) {
+ assertEquals(e.getKey(), e.getValue().getOrigName());
+
+ }
+ }
}
--
1.6.0.3.578.g6a50
^ permalink raw reply related
* [EGIT PATCH 2/7] Add constant for "refs/"
From: Robin Rosenberg @ 2008-11-07 22:07 UTC (permalink / raw)
To: spearce; +Cc: git, Robin Rosenberg
In-Reply-To: <1226095664-13759-2-git-send-email-robin.rosenberg@dewire.com>
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
.../src/org/spearce/jgit/lib/Constants.java | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/Constants.java b/org.spearce.jgit/src/org/spearce/jgit/lib/Constants.java
index f316881..9613d07 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/lib/Constants.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/lib/Constants.java
@@ -216,6 +216,9 @@
/** Prefix for tag refs */
public static final String R_TAGS = "refs/tags/";
+ /** Prefix for any ref */
+ public static final String R_REFS = "refs/";
+
/** Logs folder name */
public static final String LOGS = "logs";
--
1.6.0.3.578.g6a50
^ permalink raw reply related
* [J/E-GIT PATCH 0/7] Tag decoration v2
From: Robin Rosenberg @ 2008-11-07 22:07 UTC (permalink / raw)
To: spearce; +Cc: git, Robin Rosenberg
This is a cleaned up version of the tag decoration patch set. It
also draws the labels slightly nicer, especially when the background
has alternating colors for each row.
-- robin
Robin Rosenberg (7):
Test the origName part of the key vs the ref itself
Add constant for "refs/"
Keep original ref name when reading refs
Handle peeling of loose refs.
Add a method to get refs by object Id
Add tags to the graphical history display.
Add decorate option to log program
.../egit/ui/internal/history/SWTCommit.java | 5 +-
.../egit/ui/internal/history/SWTPlotRenderer.java | 71 ++++++++++++++++++-
.../spearce/egit/ui/internal/history/SWTWalk.java | 2 +-
.../src/org/spearce/jgit/pgm/Log.java | 33 +++++++++
.../tst/org/spearce/jgit/lib/RefUpdateTest.java | 10 +++
.../org/spearce/jgit/awtui/AWTPlotRenderer.java | 46 ++++++++++++
.../src/org/spearce/jgit/lib/Constants.java | 3 +
org.spearce.jgit/src/org/spearce/jgit/lib/Ref.java | 77 ++++++++++++++++++--
.../src/org/spearce/jgit/lib/RefDatabase.java | 71 ++++++++++++++----
.../src/org/spearce/jgit/lib/RefUpdate.java | 14 ++---
.../src/org/spearce/jgit/lib/Repository.java | 47 ++++++++++++
.../spearce/jgit/revplot/AbstractPlotRenderer.java | 23 ++++++-
.../src/org/spearce/jgit/revplot/PlotCommit.java | 8 ++-
.../src/org/spearce/jgit/revplot/PlotWalk.java | 60 +++++++++++++++-
14 files changed, 432 insertions(+), 38 deletions(-)
^ permalink raw reply
* [RFC PATCH 0/4] deny push to current branch of non-bare repo
From: Jeff King @ 2008-11-07 22:07 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Sam Vilain
The short of it is that it's dangerous, we see people confused by it
(there was another one just yesterday), and it's a FAQ:
http://git.or.cz/gitwiki/GitFaq#head-b96f48bc9c925074be9f95c0fce69bcece5f6e73
The FAQ even says "don't do this until you know what you are doing." So
the safety valve is configurable, so that those who know what they are
doing can switch it off.
And it's even on Sam's "UI improvements" list. :)
Patch 4/4 is the interesting one. 1/4 is a cleanup I saw while fixing
tests. 2/4 is a cleanup to prepare for 3/4. And 3/4 fixes a bunch of
tests which were inadvertently doing such a push (but didn't care
because they didn't look at the working directory).
-Peff
^ permalink raw reply
* pull --preserve-merges
From: Stephen Haberman @ 2008-11-07 22:01 UTC (permalink / raw)
To: git
Hi,
Awhile ago I brought up wanting to have a "rebase with preserve merges"
option for `git pull`:
http://thread.gmane.org/gmane.comp.version-control.git/96513
Andreas had a patch to help by supporting manually typing out `git pull
--rebase --preserve-merges`:
http://thread.gmane.org/gmane.comp.version-control.git/96593
And then I did another small copy/paste patch on top to add a config
setting of `branch.<name>.preservemerges` much like the existing
`branch.<name>.rebase`.
The patches haven't gotten an explicit "no" that I noticed, nor have
they been applied...is there anything I can do to move them along?
Resubmit them or what not?
Thanks,
Stephen
^ permalink raw reply
* Re: Issue updating files during a checkout from a remote push
From: Jeff King @ 2008-11-07 21:59 UTC (permalink / raw)
To: Steve Walker; +Cc: git
In-Reply-To: <09C2A669-2B99-4490-9C95-FCCD76C03D61@idibu.com>
On Thu, Nov 06, 2008 at 06:17:54PM +0100, Steve Walker wrote:
> Sorry to keep answering my own questions directly after posting...
>
> I just tried with a 'git commit -f' and the files updated.
There is no "-f" option to commit. Did you mean "checkout -f"?
If that is the case, then yes, that will "fix" your problem in that it
brings the HEAD, index, and working tree into sync. But it is dangerous
in that it throws away any local changes you might have had.
If you did really mean "commit" then that is also a bad solution. It
creates a new commit on top of the recently pushed work that reverts all
of the changes made by the recently pushed work.
-Peff
^ permalink raw reply
* Re: Issue updating files during a checkout from a remote push
From: Jeff King @ 2008-11-07 21:56 UTC (permalink / raw)
To: Steve Walker; +Cc: git
In-Reply-To: <334B3AB1-125A-4163-BEBC-9A73C4F569B5@idibu.com>
On Thu, Nov 06, 2008 at 06:04:20PM +0100, Steve Walker wrote:
> The overall issue is that with files that have been pushed into our repo
> on our server, when we then check out into local working copy the new
> files appear, but the updated files dont update even though the output
> suggests it has. The flow I'm doing:
The short answer is: don't push into the current branch of a non-bare
repo.
> 2. On my local box I change file, add it, commit, then push it from my
> local box to our server repo:
OK, so this updates the HEAD of the receiving repository. But the index
and working tree are untouched.
> 3. It all looks good, on my server if i do a 'git log' I can see in the
> latest update:
Right, because the HEAD has been updated.
> 4. So I check out:
>
> oneworld:/home/beta_idibu/public_html# git checkout master
> M .gitignore
> M steve-git-test.txt
> M steve-git-test2.txt
> M steve-git-test3.txt
> Already on branch "master"
> oneworld:/home/beta_idibu/public_html#
But you were already _on_ master, so git shouldn't need to touch the
index and working tree. But the contents of master have changed out from
under you, so it looks like you have modifications.
So generally you don't want to push to the current branch, but there is
no safety valve disallowing it (and I will post a patch series in a
minute which introduces one). In the past, people have suggested doing a
merge with the working tree, but that is not desirable for two reasons:
1. you are changing the working tree out from under whoever's repo you
push into
2. the merge might not be clean, in which case the user needs to
resolve conflicts. But the user isn't even doing stuff in the
now-conflicted repository. So the suggested workflow is instead to
go to that repo and do a 'pull'
So depending on what you want to accomplish, there are a number of
alternative workflows:
- if you just want to publish refs, you can use a bare repo without a
working tree at all (git --bare init, or git clone --bare).
- if you just want to throw away working tree changes on a push (e.g.,
you are pushing to a production server whose working tree is kept up
to date), you can do that automatically with a post-receive hook. But
it will never be the default, because we don't want to throw anything
away unless the user has explicitly told us to do so.
- if you are working in repos A and B, and you want to get changes from
B to A, then you would generally go to A and "git pull B". But
sometimes that is not possible (e.g., you can only make network
connections one way). In that case, you can push to a "remote" branch
on A, and then merge from there when you're at A. E.g.,:
/repo/B$ git push /repo/A master:refs/remotes/B/master
/repo/B$ cd /repo/A
/repo/A$ git merge B/master
-Peff
^ permalink raw reply
* Re: absurdly slow git-diff
From: Linus Torvalds @ 2008-11-07 21:37 UTC (permalink / raw)
To: Abhijit Menon-Sen, Pierre Habouzit, Davide Libenzi; +Cc: Git Mailing List
In-Reply-To: <20081107200126.GA20284@toroid.org>
On Sat, 8 Nov 2008, Abhijit Menon-Sen wrote:
>
> If anyone's interested, the files are http://toroid.org/misc/1 and
> http://toroid.org/misc/2
Btw, you can see this by just doing
git diff 1 2
without even doing "git init" or doing any actual git repository.
> Does anyone understand why this slowdown might happen or have
> suggestions about where I should look for it?
Sure. It's actually fairly simple. You're hitting a O(n^2) thing (possibly
higher), and it's triggered by the fact that almost all your lines are
identical, ie you have a file that basically has 40,000 lines of each of
xxxx: xxx, xx xxx xxxx xx:xx:xx +xxxx
xx: xxxx xxxxxxxxxxx <xxxx@xxxx.xxx>
xxxx: xxxx xxxxxxxxxxx <xxxx@xxxx.xxx>
and 30,000 of
* xxxxx xxxxx (xxxxxx.xxxx xxx xxxxx (\Xxxxxx) xxxxxx.xxxxxx {xxx}
with a smattering of others. And this is a case where the internal git
implementation does really badly. And nobody has really cared before,
because nobody has ever had a case that mattered.
There's a number of different 'diff' algorithms, and it looks like GNU
diff has one that avoids the O(n^2) case for this case.
I'm adding Davide as the original author of the diff library to the cc.
I'm also adding Pierre, since he was talking about trying to implement
another diff algorithm (although I'm not at all sure that the patience
diff really would help this case at all).
Linus
^ permalink raw reply
* Re: absurdly slow git-diff
From: Mike Hommey @ 2008-11-07 21:28 UTC (permalink / raw)
To: Abhijit Menon-Sen; +Cc: git
In-Reply-To: <20081107200126.GA20284@toroid.org>
On Sat, Nov 08, 2008 at 01:31:27AM +0530, Abhijit Menon-Sen wrote:
> I have a 240k-line file, and I change one character on every sixth line.
> The resulting diff gives git serious indigestion:
>
> $ git --version
> git version 1.6.0.3.640.g6331a
> $ mkdir a; cd a; git init
> Initialized empty Git repository in /home/ams/a/.git/
> $ cp ../1 .; git add 1; git commit -q -m 1
> $ cp ../2 1; git add 1; git commit -q -m 2
You don't need to go that far. You can stop at cp ../2 1 and run git
diff from there.
All the time is spent in the two loops in
xdiff/xprepare.c:xdl_cleanup_records, on line 400 and 412.
I'll leave the rest of the investigation to people actually knowing this
code ;)
Mike
^ permalink raw reply
* Re: [PATCH 2/3] Introduce rename factorization in diffcore.
From: Junio C Hamano @ 2008-11-07 21:11 UTC (permalink / raw)
To: Yann Dirson; +Cc: git
In-Reply-To: <20081107203952.GJ5158@nan92-1-81-57-214-146.fbx.proxad.net>
Yann Dirson <ydirson@altern.org> writes:
> On Fri, Nov 07, 2008 at 12:19:14PM -0800, Junio C Hamano wrote:
>> I am afraid that this is totally unacceptable, as you yourself mentioned,
>> the end result is unapplicable with any existing tool and would confuse
>> viewers like gitk and gitweb.
>
> Well, other tools will still have to be taught about a new syntax, if
> they're going to use the new flag - just like it was for --rename.
You are mistaken. For a patch, you are dealing with two different
parties: producer and consumer. If you are adding new feature to the
producer, the output format should be desigend to allow the consumer tell
that it is something it does not know how to handle.
Marking a non patch with "diff --git" to trigger the logic to signal the
beginning of a patch to git-apply (and perhaps other tools) is a non
starter.
And for this "we are giving a patch that your git-apply can apply and gitk
can show, but by the way we also think the whole directory foo moved to
new location bar" is merely an additional information. You should still
be able to apply the patch with tools that are unaware of this new
directory move detection feature.
^ permalink raw reply
* Re: [minor usability suggestion] git rebase <upstream> --onto <newbase> ?
From: Junio C Hamano @ 2008-11-07 21:06 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Ingo Molnar, git
In-Reply-To: <alpine.LNX.1.00.0811071504110.19665@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> "git log origin/master -p" works, though.
That's an accident. Do not rely on it.
^ permalink raw reply
* Re: git-push and $GIT_DIR/branches
From: Martin Koegler @ 2008-11-07 20:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vljvvh61y.fsf@gitster.siamese.dyndns.org>
On Fri, Nov 07, 2008 at 08:08:57AM -0800, Junio C Hamano wrote:
> mkoegler@auto.tuwien.ac.at (Martin Koegler) writes:
>
> > I think, that the git-push behaviour is a bit unlogical in conjunction
> > with $GIT_DIR/branches.
>
> That is because it is illogical to use $GIT_DIR/branches in conjunction
> with git; the former is a backward compatibility wart with Cogito which is
> now dead.
I'm aware, that $GIT_DIR/branches origins from Cogito and are not
recommended. But eg. Documentation/urls-remotes.txt does not reflect
this.
I asume, that you [and probably many other] are not very interrested
in this feature. But would you accept a patch changing the push
refspec to HEAD:refs/heads/<head>?
mfg Martin Kögler
^ permalink raw reply
* Re: [PATCH 2/3] Introduce rename factorization in diffcore.
From: Yann Dirson @ 2008-11-07 20:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3ai3gugt.fsf@gitster.siamese.dyndns.org>
On Fri, Nov 07, 2008 at 12:19:14PM -0800, Junio C Hamano wrote:
> I am afraid that this is totally unacceptable, as you yourself mentioned,
> the end result is unapplicable with any existing tool and would confuse
> viewers like gitk and gitweb.
Well, other tools will still have to be taught about a new syntax, if
they're going to use the new flag - just like it was for --rename.
That makes me think that it could be interesting to have a header
telling which diff extensions it is using. It could even be
interesting to come with a cross-vc convention, which would ease the
interchange of modern patch files (I suppose some other tools already
have their own extensions for file renames).
What about some hint like the following ?
|extended diff features: git:rename git:binary git:filetypes
|extended diff features: git:unixperms git:dir-rename
Maybe we could leave "filetype" and "unixperms" out, since these do
not replace an information that would otherwise be present in a
standard diff anyway, and would just be ignored by a tool not
supporting them.
> I think it would be a much better approach to emit a hint that talks about
> directory rename in a format that does not fool usual "patch" application
> tools. E.g.
>
> |directory moved with similarity index 82%
> |rename from ppc
> |rename from foo
> |diff --git a/ppc/sha1.h b/foo/sha1.h
> |similarity index 85%
> |rename from ppc/sha1.h
> |rename to foo/sha1.h
> |index 9b34f76..8fce4b7 100644
> |--- ppc/sha1.h
> |+++ foo/sha1.h
> |@@ ...
So you're favoring the "patch is not textually splittable approach".
Don't you think it would be good to add some sort of hint about this
as a patch header ?
> IOW, do not add anything that begins with "diff --git" if it is not a
> patch.
OK.
^ permalink raw reply
* absurdly slow git-diff
From: Abhijit Menon-Sen @ 2008-11-07 20:01 UTC (permalink / raw)
To: git
I have a 240k-line file, and I change one character on every sixth line.
The resulting diff gives git serious indigestion:
$ git --version
git version 1.6.0.3.640.g6331a
$ mkdir a; cd a; git init
Initialized empty Git repository in /home/ams/a/.git/
$ cp ../1 .; git add 1; git commit -q -m 1
$ cp ../2 1; git add 1; git commit -q -m 2
$ time git show HEAD > x
git show HEAD > x 309.88s user 0.46s system 97% cpu 5:17.06 total
(I use commit -q above not only for brevity; for the second commit,
calculating the diffstat takes the same five minutes that git show,
git log -p, git log --stat etc. all take.)
Note that diff(1) can handle the patch fine:
$ time diff -u ../1 ../2 >/dev/null
diff -u ../1 ../2 > /dev/null 0.30s user 0.06s system 69% cpu 0.519 total
If anyone's interested, the files are http://toroid.org/misc/1 and
http://toroid.org/misc/2
Does anyone understand why this slowdown might happen or have
suggestions about where I should look for it?
Thanks.
-- ams
^ permalink raw reply
* Re: [PATCH 2/3] Introduce rename factorization in diffcore.
From: Junio C Hamano @ 2008-11-07 20:19 UTC (permalink / raw)
To: Yann Dirson; +Cc: git
In-Reply-To: <20081107193957.GI5158@nan92-1-81-57-214-146.fbx.proxad.net>
Yann Dirson <ydirson@altern.org> writes:
> The direct transposition of the raw output of a dir rename with a
> change would yield something like:
>
> |diff --git a/ppc/ b/foo
> |similarity index 100%
> |rename from ppc/
> |rename to foo/
> |diff --git a/ppc/sha1.h b/foo/sha1.h
> |--- ppc/sha1.h
> |+++ foo/sha1.h
> |...
>
> This would have the usefulness I'm looking for, in that the content
> modifications would not be "hidden" among a whole lot af individual
> file rename hunks.
I am afraid that this is totally unacceptable, as you yourself mentioned,
the end result is unapplicable with any existing tool and would confuse
viewers like gitk and gitweb.
I think it would be a much better approach to emit a hint that talks about
directory rename in a format that does not fool usual "patch" application
tools. E.g.
|directory moved with similarity index 82%
|rename from ppc
|rename from foo
|diff --git a/ppc/sha1.h b/foo/sha1.h
|similarity index 85%
|rename from ppc/sha1.h
|rename to foo/sha1.h
|index 9b34f76..8fce4b7 100644
|--- ppc/sha1.h
|+++ foo/sha1.h
|@@ ...
IOW, do not add anything that begins with "diff --git" if it is not a
patch.
^ permalink raw reply
* Re: [minor usability suggestion] git rebase <upstream> --onto <newbase> ?
From: Daniel Barkalow @ 2008-11-07 20:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ingo Molnar, git
In-Reply-To: <7vej1ngztd.fsf@gitster.siamese.dyndns.org>
On Fri, 7 Nov 2008, Junio C Hamano wrote:
> Ingo Molnar <mingo@elte.hu> writes:
>
> > earth4:~/tip> git rebase 685aebb --onto linus
> > Current branch core/urgent is up to date.
> > ...
> > For example "git log" is exemplary in this area as it accepts just
> > about any permutation of parameters thrown at it, ...
>
> Not really.
>
> There may be oddball commands whose parameter order have been established
> differently long before "git log" came, but almost all of them now use the
> same convention used by the "git log" family, which is flags/options then
> revs (and then paths if the operation makes sense with paths). And rebase
> is not one of the oddball ones.
>
> Your "rebase" example is a rev then a flag/option, which is not how any
> other git command take its command line parameters.
"git log origin/master -p" works, though. It's paths, not revisions, that
can't appear before options (or revisions).
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH 2/3] Introduce rename factorization in diffcore.
From: Yann Dirson @ 2008-11-07 19:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy6zwgx3i.fsf@gitster.siamese.dyndns.org>
On Thu, Nov 06, 2008 at 05:10:09PM -0800, Junio C Hamano wrote:
> Yann Dirson <ydirson@altern.org> writes:
>
> > Rename factorization tries to group together files moving from and to
> > identical directories - the most common case being directory renames.
> > We do that by first identifying groups of bulk-moved files, and then
> > hiding those of the individual renames which carry no other
> > information (further name change, or content changes).
> > This feature is activated by the new --factorize-renames diffcore
> > flag.
>
> I have a mixed feeling about this one, primarily because I cannot
> visualize how a useful output should look like. Unless you rename one
> directory to another without any content changes, you would have to say
> "this directory changed to that, and among the paths underneath them, this
> file have this content change in addition".
Right. This is something I have already thought about, without taking
the time to finalize. So let's have a try.
The direct transposition of the raw output of a dir rename with a
change would yield something like:
|diff --git a/ppc/ b/foo
|similarity index 100%
|rename from ppc/
|rename to foo/
|diff --git a/ppc/sha1.h b/foo/sha1.h
|--- ppc/sha1.h
|+++ foo/sha1.h
|...
This would have the usefulness I'm looking for, in that the content
modifications would not be "hidden" among a whole lot af individual
file rename hunks.
But if we want to make this more generally useful (eg. allow other
tools to apply such patches), we need to be careful. A typical patch
file can usually be seen as a sequence of changes which can be applied
independently (at least in order). It is obvious that this is not
true for the above output. So we could also consider making this
patch output sequential with something like:
|diff --git a/ppc/ b/foo
|similarity index 100%
|rename from ppc/
|rename to foo/
|diff --git a/foo/sha1.h b/foo/sha1.h
|--- foo/sha1.h
|+++ foo/sha1.h
|...
However, such output would possibly be confusing, eg. when looking at
it from gitk and looking for commits which modify ppc/sha1.h.
A solution to this could be to add an annotation such as:
|diff --git a/ppc/ b/foo
|similarity index 100%
|rename from ppc/
|rename to foo/
|diff --git a/foo/sha1.h b/foo/sha1.h
|--- foo/sha1.h (previously ppc/sha1.h)
|+++ foo/sha1.h
|...
That would make the "git diff" format diverge a bit more from the
standard, but since a full-fledged git patch already cannot be used by
standard patch tools, it should not be a big issue - we should just be
careful about choosing a suitable format if we go that way.
But as we already change the patch format, we could also simply say
that we don't care about the patch being "litterally splittable", add
a "this is a non-splittable whole" note at the beginning of the patch
output, and go with the litteral solution shown as first example.
How do you feel wrt this ?
> A related feature that would benefit from something like your change
> without any downside/complication of output format issues is to boost
> rename similarity score of a path when its neighbouring paths are moved to
> the same location.
Yes, that could be triggered by distinct switches.
Doing this would be related to detecting "directory splits" (ie. when
some files are really not moved, or moved into several dirs instead of
being all moved to the same target dir). We can start by detecting
dir-splits, then shift the scoring threshold and do another pass on
split dirs.
^ permalink raw reply
* Re: [PATCH v2 3/3] pack-objects: honor '.keep' files
From: Shawn O. Pearce @ 2008-11-07 19:25 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Brandon Casey, Junio C Hamano, Git Mailing List, Nicolas Pitre
In-Reply-To: <4913F859.8070500@op5.se>
Andreas Ericsson <ae@op5.se> wrote:
>
> Only -d should honor .keep, imo. .keep-files is nothing about "don't copy
> objects from this file" and all about "never delete this file".
>
> The only muddying comes from you, who decided that .keep-files should
> have impact on anything else than deleting the protected pack. Before that,
> .keep files had a clear semantic, and repack's documentation was correct.
>
> How do you explain .keep-files now? "protects pack-files that will forever
> be used"? Then why the hell is it called ".keep" instead of "eternal"?
The _intent_ behind .keep files has always been to avoid copying
the objects into a new pack during git-repack, because the objects
are held in a pack that cannot be deleted.
Sadly the implementation has never quite worked right, which is
what led to this patch series I think.
--
Shawn.
^ permalink raw reply
* Re: [PATCH/RFC v3] git add -i: Answer questions with a single keypress
From: Jeff King @ 2008-11-07 19:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk5bgiy18.fsf@gitster.siamese.dyndns.org>
On Thu, Nov 06, 2008 at 09:06:59AM -0800, Junio C Hamano wrote:
> Thanks. And thanks, Jeff, for being a good reviewer.
You're welcome. I'm trying to lead by example. :)
-Peff
^ permalink raw reply
* Re: [PATCH/RFC v3] git add -i: Answer questions with a single keypress
From: Jeff King @ 2008-11-07 19:19 UTC (permalink / raw)
To: Suraj N. Kurapati; +Cc: git
In-Reply-To: <200811060815.16797.sunaku@gmail.com>
On Thu, Nov 06, 2008 at 08:15:16AM -0800, Suraj N. Kurapati wrote:
> v1 and v2 make the mistake of setting raw mode, which prevent the user from
> pressing Control-C to exit the program. v3 fixes this by using cbreak mode.
OK, makes sense.
> The git-svn.perl script also uses Term::ReadKey. Since it is already in the
> git source repository, I thought it was okay to use Term::ReadKey.
We are not always consistent with such things, and git-add--interactive
is a little "more core" than git-svn, I think. Still, maybe I am being
overly cautious. We can always try it and see who complains. ;)
I think considering this improvement:
> > - This only enhances one particular input, the patch loop. It is
> > probably worth being consistent and allowing these behavior for other
> > menus (though the numeric inputs are a bit trickier).
>
> Understood.
it makes sense to factor the ReadKey procedure into a separate function
anyway. At which point it should be easy enough to substitute in the
original behavior if there is no ReadKey.
Side note: I don't know if such people exist, but I suppose it is
possible that somebody would _prefer_ the old behavior. In which case
factoring it out will also make it easier to predicate the behavior on a
config variable, if people want that.
-Peff
^ permalink raw reply
* [BUG] git-log --follow incompatibile with --max-count
From: Jakub Narebski @ 2008-11-07 18:38 UTC (permalink / raw)
To: git; +Cc: Blucher, Guy
First, it is a bit strange that while "git log" understand '--follow'
option, "git rev-parse" (the plumbing equivalent to be used in scripts)
does not.
Second, somehow "git log --follow <filename>" is incompatible with
'-n' / '--max-count':
$ git log --max-count=10 --follow --pretty=oneline --abbrev-commit gitweb/gitweb.perl
f24dce1... gitweb: Separate features with no project specific override
61b4606... gitweb: Better processing format string in custom links in navbar
$ git log --max-count=10 --pretty=oneline --abbrev-commit gitweb/gitweb.perl
f24dce1... gitweb: Separate features with no project specific override
61b4606... gitweb: Better processing format string in custom links in navbar
8db49a7... gitweb: generate parent..current URLs
b0be383... gitweb: parse parent..current syntax from PATH_INFO
3550ea7... gitweb: use_pathinfo filenames start with /
b02bd7a... gitweb: generate project/action/hash URLs
d8c2882... gitweb: parse project/action/hash_base:filename PATH_INFO
1b2d297... gitweb: refactor input parameters parse/validation
3e3d4ee... Merge branch 'pb/gitweb-tagcloud' into pb/gitweb
0d1d154... gitweb: Support for simple project search form
$ git log --max-count=10 --pretty=oneline --abbrev-commit gitweb/gitweb.perl | wc -l
10
Without '--nax-count' it works correctly:
$ git log --pretty=oneline --abbrev-commit gitweb/gitweb.perl | wc -l
446
$ git log --follow --pretty=oneline --abbrev-commit gitweb/gitweb.perl | wc -l
485
Both bugs were noticed by Guy Blucher when writing 'historyfollow'
patch for gitweb:
"[RFC] gitweb: add 'historyfollow' view that follows renames"
Msg-ID: <054F21930D24A0428E5B4588462C7AED0149B4B8@ednex512.dsto.defence.gov.au>
http://permalink.gmane.org/gmane.comp.version-control.git/99199
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [minor usability suggestion] git rebase <upstream> --onto <newbase> ?
From: Junio C Hamano @ 2008-11-07 18:23 UTC (permalink / raw)
To: Ingo Molnar; +Cc: git
In-Reply-To: <20081107092035.GA1339@elte.hu>
Ingo Molnar <mingo@elte.hu> writes:
> earth4:~/tip> git rebase 685aebb --onto linus
> Current branch core/urgent is up to date.
> ...
> For example "git log" is exemplary in this area as it accepts just
> about any permutation of parameters thrown at it, ...
Not really.
There may be oddball commands whose parameter order have been established
differently long before "git log" came, but almost all of them now use the
same convention used by the "git log" family, which is flags/options then
revs (and then paths if the operation makes sense with paths). And rebase
is not one of the oddball ones.
Your "rebase" example is a rev then a flag/option, which is not how any
other git command take its command line parameters.
> Or at least we should print some sort of warning/error?
With that I agree with. Patches? ;-)
^ permalink raw reply
* Re: multiple-commit cherry-pick?
From: Linus Torvalds @ 2008-11-07 18:08 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, Miles Bader, git
In-Reply-To: <20081107071231.GA4063@blimp.localdomain>
On Fri, 7 Nov 2008, Alex Riesen wrote:
>
> Does not work if there are ranges given :-/
> It'd be very nice to have: git show #c1..$c2 $c3 $c4 $c5..$c6
Yeah, we've very fundamentally never supported that. Not for show, but
also not for anything else (ie "gitk a..b c..d" does _not_ give you two
ranges).
It's easy to see why once you understand what 'a..b' really means (ie it
just expands to '^a' and 'b'), and how it's not really a "range" operation
as much as a set operation that interacts with all the other arguments
too. But unless you're very aware of that, it can be surprising.
Linus
^ permalink raw reply
* Re: [PATCH] checkout: Don't crash when switching away from an invalid branch.
From: Johannes Schindelin @ 2008-11-07 18:05 UTC (permalink / raw)
To: Alexandre Julliard; +Cc: git
In-Reply-To: <871vxnbhbh.fsf@wine.dyndns.org>
Hi,
On Fri, 7 Nov 2008, Alexandre Julliard wrote:
> I have a tree where for some reason HEAD was pointing to an invalid
> commit. I'm not sure how this happened, but git checkout should be able
> to recover from that situation without crashing.
Agree.
> diff --git a/builtin-checkout.c b/builtin-checkout.c
> index 57b94d2..7c1b8cd 100644
> --- a/builtin-checkout.c
> +++ b/builtin-checkout.c
> @@ -47,7 +47,8 @@ static int post_checkout_hook(struct commit *old, struct commit *new,
>
> memset(&proc, 0, sizeof(proc));
> argv[0] = name;
> - argv[1] = xstrdup(sha1_to_hex(old->object.sha1));
> + argv[1] = old ? xstrdup(sha1_to_hex(old->object.sha1))
> + : "0000000000000000000000000000000000000000";
I guess you want to use the variable null_sha1 here.
> @@ -492,10 +493,13 @@ static void update_refs_for_switch(struct checkout_opts *opts,
> }
>
> old_desc = old->name;
> - if (!old_desc)
> + if (!old_desc && old->commit)
> old_desc = sha1_to_hex(old->commit->object.sha1);
> - strbuf_addf(&msg, "checkout: moving from %s to %s",
> - old_desc, new->name);
> + if (old_desc)
> + strbuf_addf(&msg, "checkout: moving from %s to %s",
> + old_desc, new->name);
> + else
> + strbuf_addf(&msg, "checkout: moving to %s", new->name);
Why not
old_desc ? old_desc : "(invalid)"
?
> diff --git a/t/t2011-checkout-invalid-head.sh b/t/t2011-checkout-invalid-head.sh
> new file mode 100755
Nice!
Thank you,
Dscho
^ permalink raw reply
* [PATCH] checkout: Don't crash when switching away from an invalid branch.
From: Alexandre Julliard @ 2008-11-07 17:02 UTC (permalink / raw)
To: git
I have a tree where for some reason HEAD was pointing to an invalid
commit. I'm not sure how this happened, but git checkout should be
able to recover from that situation without crashing.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
---
builtin-checkout.c | 14 +++++++++-----
t/t2011-checkout-invalid-head.sh | 18 ++++++++++++++++++
2 files changed, 27 insertions(+), 5 deletions(-)
create mode 100755 t/t2011-checkout-invalid-head.sh
diff --git a/builtin-checkout.c b/builtin-checkout.c
index 57b94d2..7c1b8cd 100644
--- a/builtin-checkout.c
+++ b/builtin-checkout.c
@@ -47,7 +47,8 @@ static int post_checkout_hook(struct commit *old, struct commit *new,
memset(&proc, 0, sizeof(proc));
argv[0] = name;
- argv[1] = xstrdup(sha1_to_hex(old->object.sha1));
+ argv[1] = old ? xstrdup(sha1_to_hex(old->object.sha1))
+ : "0000000000000000000000000000000000000000";
argv[2] = xstrdup(sha1_to_hex(new->object.sha1));
argv[3] = changed ? "1" : "0";
argv[4] = NULL;
@@ -492,10 +493,13 @@ static void update_refs_for_switch(struct checkout_opts *opts,
}
old_desc = old->name;
- if (!old_desc)
+ if (!old_desc && old->commit)
old_desc = sha1_to_hex(old->commit->object.sha1);
- strbuf_addf(&msg, "checkout: moving from %s to %s",
- old_desc, new->name);
+ if (old_desc)
+ strbuf_addf(&msg, "checkout: moving from %s to %s",
+ old_desc, new->name);
+ else
+ strbuf_addf(&msg, "checkout: moving to %s", new->name);
if (new->path) {
create_symref("HEAD", new->path, msg.buf);
@@ -551,7 +555,7 @@ static int switch_branches(struct checkout_opts *opts, struct branch_info *new)
* a new commit, we want to mention the old commit once more
* to remind the user that it might be lost.
*/
- if (!opts->quiet && !old.path && new->commit != old.commit)
+ if (!opts->quiet && !old.path && old.commit && new->commit != old.commit)
describe_detached_head("Previous HEAD position was", old.commit);
if (!old.commit) {
diff --git a/t/t2011-checkout-invalid-head.sh b/t/t2011-checkout-invalid-head.sh
new file mode 100755
index 0000000..764bb0a
--- /dev/null
+++ b/t/t2011-checkout-invalid-head.sh
@@ -0,0 +1,18 @@
+#!/bin/sh
+
+test_description='checkout switching away from an invalid branch'
+
+. ./test-lib.sh
+
+test_expect_success 'setup' '
+ echo hello >world &&
+ git add world &&
+ git commit -m initial
+'
+
+test_expect_success 'checkout master from invalid HEAD' '
+ echo 0000000000000000000000000000000000000000 >.git/HEAD &&
+ git checkout master --
+'
+
+test_done
--
1.6.0.3.669.g76740
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply related
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