* Re: Invalid dates in git log
From: Junio C Hamano @ 2007-12-12 18:57 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, Eirik Bjørsnøs, git
In-Reply-To: <Pine.LNX.4.64.0712121457280.27959@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Wed, 12 Dec 2007, Junio C Hamano wrote:
>
>> Author: Len Brown <len.brown@intel.com>
>> AuthorDate: Fri Apr 5 00:07:45 2019 -0500
>> Commit: Len Brown <len.brown@intel.com>
>> CommitDate: Tue Jul 12 00:12:09 2005 -0400
>>
>> author Len Brown <len.brown@intel.com> 1554440865 -0500
>> committer Len Brown <len.brown@intel.com> 1121141529 -0400
>>
>> [...] It looks like quite a random timestamp, and committer timestamp
>> look reasonable, relative to the other commits around it.
>
> It is quite possible that Len Brown had a similar problem to what I
> experienced yesterday: my clock was set one hour and 22 years into the
> future, but I have no idea how that happened. My only guess is a
> half-succeeded ntpdate call, but somehow I doubt that.
But how would you explain the more reasonable committer date?
I am guessing that this particular commit was rebased (using rebase,
rebase -i, stgit, guilt or something else), and whatever tool that was
used had some thinko that broke the author timestamp (and zone).
Nah, exonerate guilt and rebase -i from the list. The commit is from
July 2005 which means there wasn't much usable tool for rebasing in the
core distribution. Interactive rebase did not exist back then, and
rebase was done with "git-commit-script -m", which took an existing
commit and used its metainformation when creating a commit. This was
almost totally different codepath from what we have now. Not even
format-patch nor applymbox existed.
StGIT 0.4 (initial) was Jul 10, 2005, so it is _possible_ (I do not know
about plausibility) that it had an early bug that caused this, but if we
really want to figure it out we need to ask Len what was used, and I
suspect the most likely answer is "are you crazy enough to expect me to
remember?".
I am personally more interested in the other one, which was much more
recent incident, though.
^ permalink raw reply
* Re: [PATCH (amend)] diff: Make numstat machine friendly also for renames (and copies)
From: Junio C Hamano @ 2007-12-12 19:07 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200712121131.01471.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> BTW. I have noticed something strange with current (after my two
> patches) diffstat code:
>
> 3606:[gitweb/web@git]# ./git diff-tree -C -C -r --stat gitweb/test~8
> 0456a2ba58efb0e1d5f7421d5a8a2278e3b15ebc
> .../test/file with spaces\tand\ttabs" | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
> 3607:[gitweb/web@git]# ./git diff-tree -C -C -r --numstat gitweb/test~8
> 0456a2ba58efb0e1d5f7421d5a8a2278e3b15ebc
> 3 1 gitweb/test/file with spaces "gitweb/test/file with spaces\tand\ttabs"
If you are wondering about the lack of => in --stat when --numstat is
showing rename, there is nothing strange going on. "filename scaling"
done in --stat happens way later than pprint_rename() in the current
code structure (essentially, it chomps at the last slash to keep the
long "path" fit within the given space). --stat (not --numstat) is for
human consumption and showing longer part of the name of postimage is
more important if we do not have enough room, and most tools that enable
rename use --summary with --stat anyway, so the rename information for
such an oddball long path can be found out elsewhere in the output if
needed.
^ permalink raw reply
* [egit] How-to use egit
From: Wink Saville @ 2007-12-12 19:12 UTC (permalink / raw)
To: git
Robin et. al,
I cloned egit from git://repo.or.cz/egit and imported it into my workspace
following the instructions in INSTALL I did successfully compile although
there were 1115 warnings but no compilation errors.
I then exported to a archive org.spearce.egit.jar and then copied this file
to /usr/eclipse/plugin/ I then restarted Eclipse. But I don't see any
evidence
that I properly installed the plugin. BUT I've never compiled or installed
a plugin by hand before so I may have not done this correctly.
Anyway, I need a small nudge on what to do next or maybe redo what I've
done correctly. Note, currently my entire workspace is in a git repository
and it's config file is:
wink@ic2d1:$ cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
url = git://192.168.0.8/eclipse-workspace.git
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
[gui]
geometry = 918x909+633+116 107 218
With the working copy named "workspace".
Cheers,
Wink Saville
^ permalink raw reply
* [PATCH] Teach git-gui to split hunks
From: Johannes Schindelin @ 2007-12-12 19:37 UTC (permalink / raw)
To: Jason Sewall; +Cc: Shawn O. Pearce, David, Marco Costalba, Andy Parkins, git
In-Reply-To: <31e9dd080712121050i45981ed5u845b71f0e73aa8e2@mail.gmail.com>
When you select the context menu item "Split Hunk" in the diff area,
git-gui will now split the current hunk so that a new hunk starts at
the current position.
For this to work, apply has to be called with --unidiff-zero, since
the new hunks can start or stop with a "-" or "+" line.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Wed, 12 Dec 2007, Jason Sewall wrote:
> On Dec 12, 2007 1:15 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >
> > I had a patch for splitting hunks in git-gui in August, but
> > there were some issues that I did not yet resolve. If you
> > want to work on it, I'll gladly share that patch with you.
>
> Sure, send it along. I'm not going to make any promises, but I
> could probably find time poke around in there.
This was the next step that I did not yet quite complete:
+proc get_context_lines {line_number context_count direction variable} {
+ global ui_diff
+ upvar result $variable
+
+ set count 0
+ set result ""
+ for {set i $line_number} {$count < $context_count} {incr i $direction} {
+ switch -exact -- [$ui_diff get $i.0] {
+ " " {
+ append result [$ui_diff get $i.0 "$i.lineend"]
+ incr count
+ }
+ "-" {
+ append result [$ui_diff get $i.0 "$i.lineend"]
+ incr count
+ }
+ "@" {
+ return $count
+ }
+ "" {
+ return $count
+ }
+ }
+ }
+}
Of course, this function would be used to add some context
to the new hunk boundaries (if needed), and to adjust the contexts
of the remaining hunks whenever some hunk was applied.
... and then get rid of that ugly unidiff-zero option.
git-gui.sh | 4 +++
lib/diff.tcl | 75 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 78 insertions(+), 1 deletions(-)
diff --git a/git-gui.sh b/git-gui.sh
index 1fca11f..0798d41 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -2567,6 +2567,10 @@ $ctxm add command \
-command {apply_hunk $cursorX $cursorY}
set ui_diff_applyhunk [$ctxm index last]
lappend diff_actions [list $ctxm entryconf $ui_diff_applyhunk -state]
+$ctxm add command \
+ -label [mc "Split Hunk"] \
+ -command {split_hunk $cursorX $cursorY}
+lappend diff_actions [list $ctxm entryconf [$ctxm index last] -state]
$ctxm add separator
$ctxm add command \
-label [mc "Decrease Font Size"] \
diff --git a/lib/diff.tcl b/lib/diff.tcl
index 43565e4..0c3f790 100644
--- a/lib/diff.tcl
+++ b/lib/diff.tcl
@@ -289,6 +289,79 @@ proc read_diff {fd} {
}
}
+proc split_hunk {x y} {
+ global current_diff_path current_diff_header current_diff_side
+ global ui_diff ui_index file_states
+
+ if {$current_diff_path eq {} || $current_diff_header eq {}} return
+ if {![lock_index apply_hunk]} return
+
+ set c_lno [lindex [split [$ui_diff index @$x,$y] .] 0]
+ set s_idx [$ui_diff search -backwards -regexp ^@@ $c_lno.0 0.0]
+ if {$s_idx eq {} || $s_idx >= [expr $c_lno - 1]} {
+ unlock_index
+ return
+ }
+ set s_lno [lindex [split $s_idx .] 0]
+
+ # the first hunk will look like this: @@ -$m1,$m2 +$p1,$p2 @@
+ # the second hunk will look like this: @@ -$m3,$m4 +$p3,$p4 @@
+
+ # get original hunk numbers
+ set hunk_line [$ui_diff get $s_idx "$s_idx lineend"]
+ set re "@@ +-(\[0-9\]+)(,(\[0-9\]+))? +\\+(\[0-9\]+)(,(\[0-9\]+))? *@@"
+ if {![regexp $re $hunk_line dummy m1 dummy m4 p1 dummy p4] ||
+ $m1 == 0 || $p1 == 0} { # create/delete file
+ unlock_index
+ return
+ }
+ if {$m4 == ""} {
+ set m4 1
+ }
+ if {$p4 == ""} {
+ set p4 1
+ }
+
+ # count changes
+ set m2 0
+ set p2 0
+ for {set l [expr $s_lno + 1]} {$l < $c_lno} {incr l} {
+ switch -exact -- [$ui_diff get $l.0] {
+ " " {
+ incr m2
+ incr p2
+ }
+ "+" {
+ incr p2
+ }
+ "-" {
+ incr m2
+ }
+ }
+ }
+
+ # We could check if {$m2 == $p2 && $m2 == [expr $c_lno - $s_lno]}
+ # and just remove the hunk. But let's not be too clever here.
+
+ set m3 [expr $m1 + $m2]
+ set m4 [expr $m4 - $m2]
+ set p3 [expr $p1 + $p2]
+ set p4 [expr $p4 - $p2]
+
+ if {$m4 == 0 && $p4 == 0} {
+ index_unlock
+ return
+ }
+
+ $ui_diff configure -state normal
+ $ui_diff delete $s_idx "$s_idx lineend"
+ $ui_diff insert $s_idx "@@ -$m1,$m2 +$p1,$p2 @@" d_@
+ $ui_diff insert $c_lno.0 "@@ -$m3,$m4 +$p3,$p4 @@\n" d_@
+ $ui_diff configure -state disabled
+
+ unlock_index
+}
+
proc apply_hunk {x y} {
global current_diff_path current_diff_header current_diff_side
global ui_diff ui_index file_states
@@ -296,7 +369,7 @@ proc apply_hunk {x y} {
if {$current_diff_path eq {} || $current_diff_header eq {}} return
if {![lock_index apply_hunk]} return
- set apply_cmd {apply --cached --whitespace=nowarn}
+ set apply_cmd {apply --cached --whitespace=nowarn --unidiff-zero}
set mi [lindex $file_states($current_diff_path) 0]
if {$current_diff_side eq $ui_index} {
set failed_msg [mc "Failed to unstage selected hunk."]
--
1.5.3.7.2250.g3893
^ permalink raw reply related
* Re: [PATCH 2/4] Extract and improve whitespace check from "git apply"
From: Junio C Hamano @ 2007-12-12 19:39 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: git
In-Reply-To: <1197476582-18956-3-git-send-email-win@wincent.com>
Wincent Colaiuta <win@wincent.com> writes:
> diff --git a/ws.c b/ws.c
> index 52c10ca..884d373 100644
> --- a/ws.c
> +++ b/ws.c
> +unsigned check_whitespace(const char *line, int len, unsigned ws_rule)
> +{
> + ...
> + if (ws_rule & WS_TRAILING_SPACE) {
> + /* Lines start with "+" or "-" so length is at least 1 */
> + if (line[len - 1] == '\n') {
> + if (isspace(line[len - 2]))
> + result |= WS_TRAILING_SPACE;
> + }
I like the direction, but I think it would make much more sense if you
make check_whitespace() not about "a line in a patch that adds a line",
but about "here is a line, check if that is acceptable". IOW, make line
variable zero-based (and len = strlen(line)). The change would mean
that existing callers need to be modified to do something like:
if (line[0] == '+')
check_whitespace(line+1, len-1, ...);
but at the same time we could conceivably teach "git show" to show
whitespace errors in a blob, i.e. "git show --show-ws-error HEAD:ws.c"
by using such a check_whitespace().
The highlighting code may need similar changes. I was actually hoping
you would consolidate the logic there that decides which segment of the
string to highlight, and the logic in check_whitespace() to decide if
there is an error to begin with. Conceptually, if emit_line_with_ws()
decides there is nothing to highlight with DIFF_WHITESPACE color, that
means there is no whitespace error on the line and vice-versa, no?
^ permalink raw reply
* Re: Something is broken in repack. Why not with fork and pipes?
From: Johannes Schindelin @ 2007-12-12 19:41 UTC (permalink / raw)
To: J.C. Pizarro
Cc: Linus Torvalds, Andreas Ericsson, David Miller, Nicolas Pitre,
jonsmirl, Junio C Hamano, gcc, git
In-Reply-To: <998d0e4a0712121047m3cb09f37qc3157b96e5d171e7@mail.gmail.com>
Hi,
On Wed, 12 Dec 2007, J.C. Pizarro wrote:
> It's good idea if it's for 24/365.25 that it does
> autorepack-compute-again-again-again-those-unexplored-deltas of
> git repositories in realtime. :D
This sentence does not parse.
> Some body can do "git clone" that it could give smaller that one hour ago :D
Neither does this.
> To Linus, Why don't you forget the threaded implementation of your
> repo-pack?
Please do a little research before you ask such questions: it is neither
Linus who did it, nor is it better to use processes than threads.
Besides, your proposal has nothing to do with the issue of this thread
(memory consumption).
Ciao,
Dscho
^ permalink raw reply
* Re: git annotate runs out of memory
From: Daniel Berlin @ 2007-12-12 19:43 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Davide Libenzi, Git Mailing List
In-Reply-To: <alpine.LFD.0.9999.0712111548200.25032@woody.linux-foundation.org>
On 12/11/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>
> Daniel, this is obviously on top of the patches that fix the memory leak.
Thanks, these patches work *great*.
I'm starting to have a few users who have no experience with git or hg
try their daily workflow with it, to see what UI issues they come up
with :)
^ permalink raw reply
* Re: v1.5.4 plans
From: Junio C Hamano @ 2007-12-12 19:50 UTC (permalink / raw)
To: Eric Wong; +Cc: David D. Kilzer, git
In-Reply-To: <20071212184022.GB28377@untitled>
Eric Wong <normalperson@yhbt.net> writes:
> David:
>
> I also noticed some race-conditions on this test when running this on my
> Centrino laptop (my fastest box, but I rarely use it for git
> development) and having git on my USB thumb drive. I'm pretty sure
> these were caused by inconsistencies in handling timestamps on symlinks
> vs timestamps on the files they link to.
I actually saw that for the first time on my primary box during the
nightly rebuild last night. I'll disable the test for now --- if we can
spot and fix the race by the release, that's good, otherwise, shipping
the test disabled is also fine, too.
^ permalink raw reply
* Re: git-cvsexportcommit fails for huge commits
From: Martin Langhoff @ 2007-12-12 19:58 UTC (permalink / raw)
To: Jeff King; +Cc: Markus Klinik, git
In-Reply-To: <20071212083154.GB7676@coredump.intra.peff.net>
On Dec 12, 2007 9:31 PM, Jeff King <peff@peff.net> wrote:
> We will make our commits
> in two CVS invocations, but since CVS isn't atomic _anyway_, we
> shouldn't mind losing the atomicity.
Quick note -- I used to understand that cvs was not atomic, but
reading the on-the-wire protocol has taught me otherwise. Modern
versions of cvs are actually quite atomic-ish -- the protocol expects
the client to give all the relevant data to the server, and then say
"yep, that was all", and only _then_ the server does its commit.
So if the client dies or cancels along the way, nothing ever happens
on the server side.
Still, I suspect that the _server_ is not atomic, so if the server
process dies or finds a problem along the way, you could end up with a
half-commit in the repository, and maybe some hosed ,v files.
IOWs, the protocol *is* atomic, and this patch does make things
slightly more brittle. Perhaps require an option to be set before we
do this?
m
^ permalink raw reply
* Re: [PATCH] Don't cache DESTDIR in perl/perl.mak.
From: Pierre Habouzit @ 2007-12-12 20:02 UTC (permalink / raw)
To: Eric Wong; +Cc: Junio C Hamano, Gerrit Pape, git
In-Reply-To: <20071212180050.GA18980@untitled>
[-- Attachment #1: Type: text/plain, Size: 1714 bytes --]
On Wed, Dec 12, 2007 at 06:01:48PM +0000, Eric Wong wrote:
> Junio C Hamano <gitster@pobox.com> wrote:
> > Hmph. That's reverting this:
> >
> > commit 4c5cf8c44ce06a79da5bafd4a92e6d6f598cea2e
> > Author: Eric Wong <normalperson@yhbt.net>
> > Date: Sun Aug 13 04:13:25 2006 -0700
> >
> > pass DESTDIR to the generated perl/Makefile
> >
> > Makes life for binary packagers easier, as the Perl modules will
> > be installed inside DESTDIR.
> >
> > Signed-off-by: Eric Wong <normalperson@yhbt.net>
> > Signed-off-by: Junio C Hamano <junkio@cox.net>
> >
> > Eric, care to comment?
>
> I used to make a statically linked binary package for working on an
> ancient box that didn't have a lot of libraries I wanted, and I probably
> just called `make install' into DESTDIR as a single step without calling
> `make' alone without DESTDIR argument, or I had DESTDIR set in
> config.mak
Actually this fact generated a bug in debian packaging because git is
built then installed twice in different DESTDIRS, then parts of the
install is pruned (the two installs are arch-dependant and
arch-independant files install so it's a very good reason in term of
packaging).
The fact that perl.mak caches the DESTDIR make it install things in
the wrong place because it doesn't honour make DESTDIR=foo install and
always use the cached value instead, which is wrong.
I think Gerrit won't care if it's cached or not, he just cares that it
still honours environment if present.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Teach git-gui to split hunks
From: Junio C Hamano @ 2007-12-12 20:18 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Jason Sewall, Shawn O. Pearce, David, Marco Costalba,
Andy Parkins, git
In-Reply-To: <Pine.LNX.4.64.0712121931050.27959@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> When you select the context menu item "Split Hunk" in the diff area,
> git-gui will now split the current hunk so that a new hunk starts at
> the current position.
>
> For this to work, apply has to be called with --unidiff-zero, since
> the new hunks can start or stop with a "-" or "+" line.
> ...
I still have conceptual problem with this whole thing. For example,
what does that MEAN to split this hunk from your patch...
> @@ -296,7 +369,7 @@ proc apply_hunk {x y} {
> if {$current_diff_path eq {} || $current_diff_header eq {}} return
> if {![lock_index apply_hunk]} return
>
> - set apply_cmd {apply --cached --whitespace=nowarn}
> + set apply_cmd {apply --cached --whitespace=nowarn --unidiff-zero}
> set mi [lindex $file_states($current_diff_path) 0]
> if {$current_diff_side eq $ui_index} {
> set failed_msg [mc "Failed to unstage selected hunk."]
... by clicking between the '-' and '+' lines, and apply only one half?
Well, the question was not very well stated. I know what it means --
remove that old line, without replacing with the corrected/updated one.
The real question is how would that be useful?
^ permalink raw reply
* Re: [ANNOUNCE] ugit: a pyqt-based git gui // was: Re: If you would write git from scratch now, what would you change?
From: Brett Schwarz @ 2007-12-12 20:20 UTC (permalink / raw)
To: Shawn O. Pearce, Jason Sewall; +Cc: David, Marco Costalba, Andy Parkins, git
Not to belabor the point, but just some comments, since this seems
to come up often enough...
> Jason Sewall <jasonsewall@gmail.com> wrote:
> > I don't know much about graphical toolkits and the like, but I think
> > that the more modern ones have fancy features like antialiasing and
> > subpixel rendering, which makes a big difference when you're working
> > on a laptop with a tiny screen.
>
> Oh, that's a good point. On my Mac OS X system with the aqua port
> of Tk the fonts render just as good as anything else on this box.
> I guess the Aqua port of Tk is just better than the X11 port of
> Tk is. :)
>
Yes, it is a known issue that Tk on unix still has the "old look"
out of the box. Some of this is just due to how the defaults
for some of the options are shipped. The default options for 8.5
have changed, so it is a little better, but Tile is really better.
The same with fonts. Anti-aliased fonts for unix have not been
supported, but in 8.5 they are.
8.5 is due out by the end of this week I believe.
> > The qt stuff fits better with the rest of my system better too (even
> > though I'm using gnome) - it's entirely the result of Tk being
> > lightweight and a million years old, when UI conventions were
> > different (like every menu being detachable, and antique scrollbars).
> > I'm not here to start a toolkit flame war (we had a toolkit dogpile on
> > the list last week, I think) I'm just pointing out that Tk is from a
> > different era.
>
> Yes. The tile extension in 8.5 should actually improve this quite
> a bit; as I understand it there is a GTK backend for Tk with that
> set of extensions, making the UI look more modern on X11, assuming
> GTK was available when Tk was compiled, etc...
>
Tile will ship with 8.5, but it is also an extension that can be used
with 8.4.
Here's some screenshots to give you an example of Tk with Tile with
Qt theme (add-on theme).
http://personal1.iddeo.es/andresgarci/getleft/english/snaps.html
http://sk1project.org/modules.php?name=Products&product=sk1
(scroll down towards bottom)
and generic Tile screenshots:
http://tktable.sourceforge.net/tile/screenshots/unix.html
> I have yet to make git-gui use the tile extension. Its however
> planned to happen in the near-ish future.
>
> > I use git-gui and gitk for my git graphical needs because they rock
> > and at the end of the day, the fonts and antialiasing aren't that big
> > of a deal, especially since I'm usually doing quick scans and searches
> > over the information those tools display, not reading novels in them.
>
> Good points. Features win over pretty most of the time. But at
> some point pretty is important; especially to new user adoption.
> Plus if you are looking at it all day long it shouldn't be jarring
> to the eyes. But git-gui still isn't even where I want it ot
> be feature-wise. E.g. I'd *love* to teach it inotify support,
> so you don't even need to have that Rescan button.
I have not used it, but this may help in regards to the
inotify stuff:
http://wiki.tcl.tk/3643
Cheers,
--brett
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
^ permalink raw reply
* Re: [PATCH] Teach git-gui to split hunks
From: Johannes Schindelin @ 2007-12-12 20:39 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jason Sewall, Shawn O. Pearce, David, Marco Costalba,
Andy Parkins, git
In-Reply-To: <7vk5nj7jkp.fsf@gitster.siamese.dyndns.org>
Hi,
On Wed, 12 Dec 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > When you select the context menu item "Split Hunk" in the diff area,
> > git-gui will now split the current hunk so that a new hunk starts at
> > the current position.
> >
> > For this to work, apply has to be called with --unidiff-zero, since
> > the new hunks can start or stop with a "-" or "+" line. ...
>
> I still have conceptual problem with this whole thing. For example,
> what does that MEAN to split this hunk from your patch...
>
> > @@ -296,7 +369,7 @@ proc apply_hunk {x y} {
> > if {$current_diff_path eq {} || $current_diff_header eq {}} return
> > if {![lock_index apply_hunk]} return
> >
> > - set apply_cmd {apply --cached --whitespace=nowarn}
> > + set apply_cmd {apply --cached --whitespace=nowarn --unidiff-zero}
> > set mi [lindex $file_states($current_diff_path) 0]
> > if {$current_diff_side eq $ui_index} {
> > set failed_msg [mc "Failed to unstage selected hunk."]
>
> ... by clicking between the '-' and '+' lines, and apply only one half?
>
> Well, the question was not very well stated. I know what it means --
> remove that old line, without replacing with the corrected/updated one.
> The real question is how would that be useful?
The thing is: sometimes there is a patch which contains just one garbage
line. (I am talking about my current working tree, so you are not allowed
to be offended by my language in this case.)
The thing I would like to do is right click on that line, start a new
hunk, then right click on the next line to start yet another hunk, and
apply this and the first hunk.
It is a lazy way to edit a patch.
Ciao,
Dscho
^ permalink raw reply
* git-pull followed by git-gc often yields *much* bigger pack than git-pull alone
From: Nix @ 2007-12-12 20:47 UTC (permalink / raw)
To: git
I've seen this intermittently, but this is a particularly extreme
example. This happens to be with 1.5.3.7, but I've seen the same
symptoms back in git 1.4.x. I assumed it was something I was doing wrong
then, but I'm no longer so sure.
,----
| hades /usr/packages/poppler/poppler% ls -al .git/objects/pack
| drwxr-xr-x 2 compiler hackers 2048 2007-12-12 20:35 .
| drwxr-xr-x 9 compiler hackers 2048 2007-12-12 20:35 ..
| -r--r--r-- 1 compiler hackers 149288 2007-10-25 23:51 pack-f5a84fe3e212f9dc62a65aee617be4bf1387cb2b.idx
| -rw-r--r-- 1 compiler hackers 0 2007-12-06 14:45 pack-f5a84fe3e212f9dc62a65aee617be4bf1387cb2b.keep
| -r--r--r-- 1 compiler hackers 1610421 2007-10-25 23:51 pack-f5a84fe3e212f9dc62a65aee617be4bf1387cb2b.pack
|
| hades /usr/packages/poppler/poppler% git-count-objects
| 0 objects, 0 kilobytes
|
| hades /usr/packages/poppler/poppler% git-remote update
| Updating origin
| remote: Generating pack...
| remote: Done counting 491 objects.
| remote: Result has 351 objects.
| remote: Deltifying 351 objects.
| remote: 100% (351/351) done
| remote: Total 351, written 351 (delta 274), reused 0 (delta 0)
| * refs/remotes/origin/master: fast forward to branch 'master' of git://git.freedesktop.org/git/poppler/poppler
| old..new: ab0a6c3..f24259c
| * refs/remotes/origin/poppler-0.6: fast forward to branch 'poppler-0.6' of git://git.freedesktop.org/git/poppler/poppler
| old..new: 5c321d3..db1e360
| Auto-following refs/tags/poppler-0.6.2
| Auto-following refs/tags/poppler-0.6.3
| remote: Generating pack...
| remote: Done counting 2 objects.
| remote: Deltifying 2 objects.
| remote: /2) done
| remote: Total 2, written 2 (delta 0), reused 0 (delta 0)
| Unpacking 2 objects...
| 100% (2/2) done
| * refs/tags/poppler-0.6.2: storing tag 'poppler-0.6.2' of git://git.freedesktop.org/git/poppler/poppler
| tag: 26470b3
| * refs/tags/poppler-0.6.3: storing tag 'poppler-0.6.3' of git://git.freedesktop.org/git/poppler/poppler
| tag: fdf7e0b
|
| hades /usr/packages/poppler/poppler% ls -al .git/objects/pack
| drwxr-xr-x 2 compiler hackers 2048 2007-12-12 20:35 .
| drwxr-xr-x 6 compiler hackers 2048 2007-12-12 20:35 ..
| -r--r--r-- 1 compiler hackers 12080 2007-12-12 20:35 pack-f534c957f3ee7f3f1046dee0081fcc315d9698bb.idx
| -r--r--r-- 1 compiler hackers 678643 2007-12-12 20:35 pack-f534c957f3ee7f3f1046dee0081fcc315d9698bb.pack
| -r--r--r-- 1 compiler hackers 149288 2007-10-25 23:51 pack-f5a84fe3e212f9dc62a65aee617be4bf1387cb2b.idx
| -rw-r--r-- 1 compiler hackers 0 2007-12-06 14:45 pack-f5a84fe3e212f9dc62a65aee617be4bf1387cb2b.keep
| -r--r--r-- 1 compiler hackers 1610421 2007-10-25 23:51 pack-f5a84fe3e212f9dc62a65aee617be4bf1387cb2b.pack
`----
OK, so that's a 662Kb packfile, 351/274...
[... a couple of trivial merges, then ...]
,----
| hades /usr/packages/poppler/poppler% git-count-objects
| 5 objects, 10 kilobytes
|
| hades /usr/packages/poppler/poppler% git-gc
| Generating pack...
| Done counting 827 objects.
| Deltifying 827 objects...
| 100% (827/827) done
| Writing 827 objects...
| 100% (827/827) done
| Total 827 (delta 393), reused 695 (delta 331)
| Pack pack-5145ce9770077cee99795fc21cfcc6ea30eb6d47 created.
| Removing unused objects 100%...
| Done.
|
| hades /usr/packages/poppler/poppler% ls -al .git/objects/pack
| drwxr-xr-x 2 compiler hackers 2048 2007-12-12 20:36 .
| drwxr-xr-x 4 compiler hackers 2048 2007-12-12 20:36 ..
| -r--r--r-- 1 compiler hackers 20912 2007-12-12 20:36 pack-5145ce9770077cee99795fc21cfcc6ea30eb6d47.idx
| -r--r--r-- 1 compiler hackers 1144055 2007-12-12 20:36 pack-5145ce9770077cee99795fc21cfcc6ea30eb6d47.pack
| -r--r--r-- 1 compiler hackers 149288 2007-10-25 23:51 pack-f5a84fe3e212f9dc62a65aee617be4bf1387cb2b.idx
| -rw-r--r-- 1 compiler hackers 0 2007-12-06 14:45 pack-f5a84fe3e212f9dc62a65aee617be4bf1387cb2b.keep
| -r--r--r-- 1 compiler hackers 1610421 2007-10-25 23:51 pack-f5a84fe3e212f9dc62a65aee617be4bf1387cb2b.pack
`----
The git-gc figures are wildly different from the original server-side
packing, as is the size of the resulting packfile.
This has me scared to do git-gc, which is presumably not good if we're
supposed to get into the habit of running it whenever we have a spare
moment :)
A while back I did a git-gc on the kernel and watched as a 10Mb pack
resulting from a git-pull blew right up to 130Mb: I had to zap the .keep
file, do a complete repack, and blow a backup CD to get the space
back. (This only happens if you have .keep files lying around: if git-gc
is allowed to amalgamate all your packs, it doesn't do this.)
Possibly-relevant .gitconfig settings:
[core]
legacyheaders=false
deltabasecachelimit=32m
[pack]
window=50
aggressiveWindow=100
depth=100
[repack]
usedeltabaseoffset=true
(yes, those windows and depths are intentionally high. I was hoping that
maybe the servers were running with enormous windows... it didn't help.)
--
`The rest is a tale of post and counter-post.' --- Ian Rawlings
describes USENET
^ permalink raw reply
* Re: [PATCH] Teach git-gui to split hunks
From: Jean-François Veillette @ 2007-12-12 20:50 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Jason Sewall, Shawn O. Pearce, David,
Marco Costalba, Andy Parkins, git
In-Reply-To: <7vk5nj7jkp.fsf@gitster.siamese.dyndns.org>
> Well, the question was not very well stated. I know what it means --
> remove that old line, without replacing with the corrected/updated
> one.
> The real question is how would that be useful?
I often get big hunk just because I modified whitespaces around
relevent pieces of code, the ability to segment the changes and only
pick isolated and specific lines for a commit (not commiting
whitespaces surrounding real code changes) would be very welcome.
Maybe I should know better, but the actual hunk selection in git gui
is quite good already, but the ability to be more precise on how a
hunk is defined is a welcome change.
- jfv
^ permalink raw reply
* Re: git-pull followed by git-gc often yields *much* bigger pack than git-pull alone
From: linux @ 2007-12-12 21:53 UTC (permalink / raw)
To: git, nix; +Cc: linux
Pre-gc:
> -r--r--r-- 1 compiler hackers 12080 2007-12-12 20:35 pack-f534c957f3ee7f3f1046dee0081fcc315d9698bb.idx
> -r--r--r-- 1 compiler hackers 678643 2007-12-12 20:35 pack-f534c957f3ee7f3f1046dee0081fcc315d9698bb.pack
Post-gc:
> -r--r--r-- 1 compiler hackers 20912 2007-12-12 20:36 pack-5145ce9770077cee99795fc21cfcc6ea30eb6d47.idx
> -r--r--r-- 1 compiler hackers 1144055 2007-12-12 20:36 pack-5145ce9770077cee99795fc21cfcc6ea30eb6d47.pack
The fact that the index file has grown so much indicates that it's sucking in a bunch of
extra objects from the .keep pack, and you're seeing the duplication.
I'm not sure how that's happening, though. I thought the --local flag to git-pack-objects told
it not to do that.
^ permalink raw reply
* Re: git-pull followed by git-gc often yields *much* bigger pack than git-pull alone
From: Nix @ 2007-12-12 22:06 UTC (permalink / raw)
To: linux; +Cc: git
In-Reply-To: <20071212215303.29921.qmail@science.horizon.com>
On 12 Dec 2007, linux@horizon.com verbalised:
> Pre-gc:
>> -r--r--r-- 1 compiler hackers 12080 2007-12-12 20:35 pack-f534c957f3ee7f3f1046dee0081fcc315d9698bb.idx
>> -r--r--r-- 1 compiler hackers 678643 2007-12-12 20:35 pack-f534c957f3ee7f3f1046dee0081fcc315d9698bb.pack
>
> Post-gc:
>> -r--r--r-- 1 compiler hackers 20912 2007-12-12 20:36 pack-5145ce9770077cee99795fc21cfcc6ea30eb6d47.idx
>> -r--r--r-- 1 compiler hackers 1144055 2007-12-12 20:36 pack-5145ce9770077cee99795fc21cfcc6ea30eb6d47.pack
>
> The fact that the index file has grown so much indicates that it's sucking in a bunch of
> extra objects from the .keep pack, and you're seeing the duplication.
I thought it had to be doing that (hence the increase in object counts
given by the git-gc runs), but wasn't sure if this behaviour was
intentional.
> I'm not sure how that's happening, though. I thought the --local flag to git-pack-objects told
> it not to do that.
This isn't true if alternates are in use, but this repo is alternate-free.
--
`The rest is a tale of post and counter-post.' --- Ian Rawlings
describes USENET
^ permalink raw reply
* Re: v1.5.4 plans
From: David D. Kilzer @ 2007-12-12 22:21 UTC (permalink / raw)
To: Junio C Hamano, Eric Wong; +Cc: git
In-Reply-To: <7vodcv7kw6.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> Eric Wong <normalperson@yhbt.net> writes:
>
> > I also noticed some race-conditions on this test when running this on my
> > Centrino laptop (my fastest box, but I rarely use it for git
> > development) and having git on my USB thumb drive. I'm pretty sure
> > these were caused by inconsistencies in handling timestamps on symlinks
> > vs timestamps on the files they link to.
>
> I actually saw that for the first time on my primary box during the
> nightly rebuild last night. I'll disable the test for now --- if we can
> spot and fix the race by the release, that's good, otherwise, shipping
> the test disabled is also fine, too.
I'll see if I can reproduce it and figure out where the race is happening.
Dave
^ permalink raw reply
* Re: [PATCH 2/4] Extract and improve whitespace check from "git apply"
From: Wincent Colaiuta @ 2007-12-12 22:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vsl277ldc.fsf@gitster.siamese.dyndns.org>
El 12/12/2007, a las 20:39, Junio C Hamano escribió:
> I like the direction, but I think it would make much more sense if you
> make check_whitespace() not about "a line in a patch that adds a
> line",
> but about "here is a line, check if that is acceptable". IOW, make
> line
> variable zero-based (and len = strlen(line)). The change would mean
> that existing callers need to be modified to do something like:
>
> if (line[0] == '+')
> check_whitespace(line+1, len-1, ...);
Yes, good point. As you say, it can then potentially be used for any
line, not just lines in patches.
> but at the same time we could conceivably teach "git show" to show
> whitespace errors in a blob, i.e. "git show --show-ws-error HEAD:ws.c"
> by using such a check_whitespace().
>
> The highlighting code may need similar changes. I was actually hoping
> you would consolidate the logic there that decides which segment of
> the
> string to highlight, and the logic in check_whitespace() to decide if
> there is an error to begin with. Conceptually, if emit_line_with_ws()
> decides there is nothing to highlight with DIFF_WHITESPACE color, that
> means there is no whitespace error on the line and vice-versa, no?
You're dead right. As I said in my original message, there is a *lot*
of diff code and I basically only looked at enough of it to figure out
what changes would be necessary to implement what I wanted. I hadn't
looked inside emit_line_with_ws but it is an obvious site of
duplication and as you point out there is definitely scope for more
refactoring here; instead of doing the whitespace checking in three
places (the three that I know about so far) we can do it in just one
place. I'll see what I can cook up.
Cheers,
Wincent
^ permalink raw reply
* Re: [PATCH] Teach git-gui to split hunks
From: Junio C Hamano @ 2007-12-12 22:54 UTC (permalink / raw)
To: Jean-François Veillette
Cc: Johannes Schindelin, Jason Sewall, Shawn O. Pearce, David,
Marco Costalba, Andy Parkins, git
In-Reply-To: <7A812021-DCEC-49D4-895B-2DCBEFA7CA2E@yahoo.ca>
Jean-François Veillette <jean_francois_veillette@yahoo.ca> writes:
>> Well, the question was not very well stated. I know what it means --
>> remove that old line, without replacing with the corrected/updated
>> one.
>> The real question is how would that be useful?
>
> I often get big hunk just because I modified whitespaces around
> relevent pieces of code, the ability to segment the changes and only
> pick isolated and specific lines for a commit (not commiting
> whitespaces surrounding real code changes) would be very welcome.
> Maybe I should know better, but the actual hunk selection in git gui
> is quite good already, but the ability to be more precise on how a
> hunk is defined is a welcome change.
Oh, I wasn't questioning the usefulness of hunk splitting in general.
It is sometimes useful and that is why we have "add -i".
If you have something like this:
@@ -j,k +l,m @@
common 1
common 2
-preimage
+postimage
common 3
-deleted
common 4
common 5
I think it makes sense to split it into two logical (overlapping) hunks:
@@ -j,(k-3) +l,(m-2) @@
common 1
common 2
-preimage
+postimage
common 3
and
@@ -j,(k-3) +l,(m-3) @@
common 3
-deleted
common 4
common 5
and being able to apply one of them independent from the other, or
re-combine them back into one hunk.
I was just questioning if it makes sense to split a hunk like this in
the middle of -/+ lines:
@@ -j,k +l,m @@
common
common
-pre 1
-pre 2
-pre 3
+post 1
+post 2
common
You could split between "-pre 2" and "-pre 3", but I do not think that
would be so useful. It is a different story if you allowed the above to
first be transformed into this way (assuming that "pre 1" and "pre 2"
corresponds to "post 1"):
@@ -j,k +l,m @@
common
common
-pre 1
-pre 2
+post 1
-pre 3
+post 2
common
and then be split between "+post 1" and "-pre 3". That may make sense
in some context.
^ permalink raw reply
* Re: [PATCH] Teach git-gui to split hunks
From: Wincent Colaiuta @ 2007-12-12 23:02 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Jason Sewall, Shawn O. Pearce, David,
Marco Costalba, Andy Parkins, git
In-Reply-To: <7vk5nj7jkp.fsf@gitster.siamese.dyndns.org>
El 12/12/2007, a las 21:18, Junio C Hamano escribió:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>> When you select the context menu item "Split Hunk" in the diff area,
>> git-gui will now split the current hunk so that a new hunk starts at
>> the current position.
>>
>> For this to work, apply has to be called with --unidiff-zero, since
>> the new hunks can start or stop with a "-" or "+" line.
>> ...
>
> I still have conceptual problem with this whole thing. For example,
> what does that MEAN to split this hunk from your patch...
>
>> @@ -296,7 +369,7 @@ proc apply_hunk {x y} {
>> if {$current_diff_path eq {} || $current_diff_header eq {}} return
>> if {![lock_index apply_hunk]} return
>>
>> - set apply_cmd {apply --cached --whitespace=nowarn}
>> + set apply_cmd {apply --cached --whitespace=nowarn --unidiff-zero}
>> set mi [lindex $file_states($current_diff_path) 0]
>> if {$current_diff_side eq $ui_index} {
>> set failed_msg [mc "Failed to unstage selected hunk."]
>
> ... by clicking between the '-' and '+' lines, and apply only one
> half?
>
> Well, the question was not very well stated. I know what it means --
> remove that old line, without replacing with the corrected/updated
> one.
> The real question is how would that be useful?
I don't know if it would be useful, but I think the more important
concern here is consistency. ie. it should split hunks the same way
"git add -i" does. Both "git gui" and "git add -i" are official parts
of Git, so in the interests of coherency they should share the same
concept of "what it means to split a hunk".
"git add -i" considers any hunk where a there are multiple groups of
deletions and/or insertions separated by context lines to be
"splittable" (on the boundaries defined by those intervening context
line), and all others to be unsplittable. I think this is a fairly
intuitive way to conceptualize splitting, so if it comes down to
making "git gui" split like "git add -i", or making "git add -i" split
like this patch proposes that "git gui" should do it, then I'd vote
for the former.
Cheers,
Wincent
^ permalink raw reply
* Exporting git tags/branches to svn tags/branches?
From: Pär-Ola Nilsson @ 2007-12-12 23:08 UTC (permalink / raw)
To: git
Hi!
I have svn repository with a standard layout:
branches
tags
RELEASE1_0
RELEASE1_1
...
trunk
I have cloned this with:
git-svn clone -s url
Now for the question:
Can I create new tags/branches on the git side and have them appear on
the svn side?
For example, create a new release, RELEASE2_0, in git and push this to
the svn repository as "tags/RELEASE2_0".
Pär-Ola Nilsson
^ permalink raw reply
* Re: [PATCH 1/2] git-help: add "help.format" config variable.
From: Junio C Hamano @ 2007-12-13 1:41 UTC (permalink / raw)
To: Christian Couder; +Cc: git
In-Reply-To: <7vr6hs8erq.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Christian Couder <chriscool@tuxfamily.org> writes:
>
>> diff --git a/git.c b/git.c
>> index 4f9876e..d46b63d 100644
>> --- a/git.c
>> +++ b/git.c
>> @@ -324,7 +324,7 @@ static void handle_internal_command(int argc, const char **argv)
>> { "gc", cmd_gc, RUN_SETUP },
>> { "get-tar-commit-id", cmd_get_tar_commit_id },
>> { "grep", cmd_grep, RUN_SETUP | USE_PAGER },
>> - { "help", cmd_help },
>> + { "help", cmd_help, RUN_SETUP },
>> #ifndef NO_CURL
>> { "http-fetch", cmd_http_fetch, RUN_SETUP },
>> #endif
>
> It would be _NICE_ if we read configuration when we are in a git
> repository, but I am afraid this change is unnice -- the users used to
> be able to say "git help" from anywhere didn't they? Now they will get
> "Not a git repository". It needs to do an optional repository
> discovery, not a mandatory one RUN_SETUP causes.
It turns out that the earlier git-browse-help is already broken with
respect to this.
-- >8 --
[PATCH] git-help -w: do not require to be in git repository
The users used to be able to say "git help cat-file" from anywhere, but
the browse-help script insisted to be in a git repository, which caused
"git help -w cat-file" to barf outside. Correct it.
While at it, remove leftover debugging "echo".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
git-browse-help.sh | 13 ++++++++-----
git-sh-setup.sh | 45 ++++++++++++++++++++++++++-------------------
2 files changed, 34 insertions(+), 24 deletions(-)
diff --git a/git-browse-help.sh b/git-browse-help.sh
index 817b379..b465911 100755
--- a/git-browse-help.sh
+++ b/git-browse-help.sh
@@ -17,8 +17,10 @@
#
USAGE='[--browser=browser|--tool=browser] [cmd to display] ...'
-SUBDIRECTORY_OK=Yes
-OPTIONS_SPEC=
+
+# This must be capable of running outside of git directory, so
+# the vanilla git-sh-setup should not be used.
+NONGIT_OK=Yes
. git-sh-setup
# Install data.
@@ -37,7 +39,7 @@ valid_tool() {
}
init_browser_path() {
- browser_path=`git config browser.$1.path`
+ test -z "$GIT_DIR" || browser_path=`git config browser.$1.path`
test -z "$browser_path" && browser_path=$1
}
@@ -69,7 +71,8 @@ do
shift
done
-if test -z "$browser"; then
+if test -z "$browser" && test -n "$GIT_DIR"
+then
for opt in "help.browser" "web.browser"
do
browser="`git config $opt`"
@@ -91,7 +94,7 @@ if test -z "$browser" ; then
else
browser_candidates="w3m links lynx"
fi
- echo "browser candidates: $browser_candidates"
+
for i in $browser_candidates; do
init_browser_path $i
if type "$browser_path" > /dev/null 2>&1; then
diff --git a/git-sh-setup.sh b/git-sh-setup.sh
index 5aa62dd..b366761 100755
--- a/git-sh-setup.sh
+++ b/git-sh-setup.sh
@@ -122,26 +122,33 @@ get_author_ident_from_commit () {
LANG=C LC_ALL=C sed -ne "$pick_author_script"
}
-# Make sure we are in a valid repository of a vintage we understand.
-if [ -z "$SUBDIRECTORY_OK" ]
+# Make sure we are in a valid repository of a vintage we understand,
+# if we require to be in a git repository.
+if test -n "$NONGIT_OK"
then
- : ${GIT_DIR=.git}
- test -z "$(git rev-parse --show-cdup)" || {
- exit=$?
- echo >&2 "You need to run this command from the toplevel of the working tree."
- exit $exit
- }
+ if git rev-parse --git-dir >/dev/null 2>&1
+ then
+ : ${GIT_DIR=.git}
+ fi
else
- GIT_DIR=$(git rev-parse --git-dir) || {
- exit=$?
- echo >&2 "Failed to find a valid git directory."
- exit $exit
+ if [ -z "$SUBDIRECTORY_OK" ]
+ then
+ : ${GIT_DIR=.git}
+ test -z "$(git rev-parse --show-cdup)" || {
+ exit=$?
+ echo >&2 "You need to run this command from the toplevel of the working tree."
+ exit $exit
+ }
+ else
+ GIT_DIR=$(git rev-parse --git-dir) || {
+ exit=$?
+ echo >&2 "Failed to find a valid git directory."
+ exit $exit
+ }
+ fi
+ test -n "$GIT_DIR" && GIT_DIR=$(cd "$GIT_DIR" && pwd) || {
+ echo >&2 "Unable to determine absolute path of git directory"
+ exit 1
}
+ : ${GIT_OBJECT_DIRECTORY="$GIT_DIR/objects"}
fi
-
-test -n "$GIT_DIR" && GIT_DIR=$(cd "$GIT_DIR" && pwd) || {
- echo >&2 "Unable to determine absolute path of git directory"
- exit 1
-}
-
-: ${GIT_OBJECT_DIRECTORY="$GIT_DIR/objects"}
--
1.5.3.7-1170-g8d08
^ permalink raw reply related
* Re: [PATCH 0/2] [RFT] git-svn: more efficient revision -> commit mapping
From: Sam Vilain @ 2007-12-13 2:42 UTC (permalink / raw)
To: Eric Wong; +Cc: Junio C Hamano, git, Harvey Harrison
In-Reply-To: <20071212180510.GB18980@untitled>
Eric Wong wrote:
> Sam (or anybody else using useSvmProps:
>
> Do you have any feedback with svmProps enabled?
3682645 120 -rw-rw-r-- 1 samv samv 121893 Dec 13 14:05
tags/debian_version_1_2_0beta1@2972/.rev_db.d29f7b36-84ff-0310-85ce-ba787dbd31ca
=>
-3683050 4 -rw-rw-r-- 1 samv samv 48 Dec 13 14:26
./tags/debian_version_1_2_0beta1@2972/.rev_map.d29f7b36-84ff-0310-85ce-ba787dbd31ca
git-log --all | grep git-svn | tail -3
git-svn-id:
file:///home/samv/.svk/local/mirror/fai/branches/source-dist@2971
d29f7b36-84ff-0310-85ce-ba787dbd31ca
git-svn-id: svn+ssh://svn.debian.org/svn/fai/trunk@2
ba5ec265-b0fb-0310-8e1a-cf9e4c2b1591
git-svn-id: svn+ssh://svn.debian.org/svn/fai/trunk@1
ba5ec265-b0fb-0310-8e1a-cf9e4c2b1591
So, the remapping is still working fine.
The one that failed there is not a new bug. Here's the fix anyway
though :-)
Subject: [PATCH] git-svn: fix --use-svm-props and --follow-parent
If, when using --follow-parent, it finds that the parent is an SVM
path, *and* the SVM path is not at the root of the corresponding SVN
repository (the usual case when using SVK), then the logic in
Git::SVN::ra will not find the correct source repository. This is
because the freshly created RA object is missing the path. So, set
this after creation.
Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz>
---
git-svn.perl | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 54d7844..3e5fd82 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -2189,6 +2189,7 @@ sub find_parent_branch {
$ref_id .= '-' while find_ref($ref_id);
print STDERR "Initializing parent: $ref_id\n";
$gs = Git::SVN->init($new_url, '', $ref_id, $ref_id, 1);
+ $gs->{path} = $branch_from;
}
my ($r0, $parent) = $gs->find_rev_before($r, 1);
if (!defined $r0 || !defined $parent) {
--
1.5.3.5
^ permalink raw reply related
* What's in git.git (stable frozen)
From: Junio C Hamano @ 2007-12-13 2:47 UTC (permalink / raw)
To: git
In-Reply-To: <7vve78qhtf.fsf@gitster.siamese.dyndns.org>
The tip of 'master' is now tagged as 1.5.4-rc0. Tarballs are found in
the usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.5.4.rc0.tar.{gz,bz2} (tarball)
git-htmldocs-1.5.4.rc0.tar.{gz,bz2} (preformatted docs)
git-manpages-1.5.4.rc0.tar.{gz,bz2} (preformatted docs)
I've also built a set of preview RPM packages. They are found in:
http://www.kernel.org/pub/software/scm/git/testing/
I am not an RPM person. It would be really appreciated if experts help
out finding and fixing any bug in the packaging. I do not want to
repeat the firefighting we needed with 1.5.3.1.
----------------------------------------------------------------
* The 'master' branch has these since the last announcement.
Alex Riesen (1):
Fix git-fast-export for zero-sized blobs
Alexandre Julliard (1):
git.el: Added a menu for git-status-mode.
Charles Bailey (1):
Fix clone not to ignore depth when performing a local clone
Christian Couder (5):
git-help: add -i|--info option to display info page.
Documentation: describe -i/--info option to "git-help"
git-help: add -w|--web option to display html man page in a browser.
Use {web,instaweb,help}.browser config options.
Documentation: describe -w/--web option to "git-help".
Daniel Barkalow (1):
Add more checkout tests
Eric Wong (2):
git-svn: replace .rev_db with a more space-efficient .rev_map format
git-svn: reinstate old rev_db optimization in new rev_map
Eyvind Bernhardsen (1):
Fix mis-markup of the -p, --patch option in git-add(1)
Gerrit Pape (1):
Don't cache DESTDIR in perl/perl.mak.
Jakub Narebski (1):
autoconf: Check asciidoc version to automatically set ASCIIDOC8
Jeff King (6):
don't mention index refreshing side effect in git-status docs
Add git-browse-help to .gitignore
Support GIT_PAGER_IN_USE environment variable
git-svn: get color config from --get-colorbool
shortlog: document -e option
git-clone: print an error message when trying to clone empty repo
Johannes Sixt (1):
Fix a typo in checkout.sh and cleanup one-line help messages
Junio C Hamano (18):
git-shortlog -e: show e-mail address as well
Re-fix ls-remote
Update draft Release Notes for 1.5.4
Documentation: add gitman.info target
git-help -i: invoke info with document and node name
git-help -i: show info documentation from matching version of git
send-email: do not muck with initial-reply-to when unset.
commit: do not add extra LF at the end of the summary.
Support a merge with conflicting gitlink change
blame: drop blob data after passing blame to the parent
shortlog: default to HEAD when the standard input is a tty
git-diff --numstat -z: make it machine readable
disable t9119 for now.
Documentation: rename git.texi to user-manual.texi
git.spec.in: remove python_path
git-help -w: do not require to be in git repository
RPM spec: Adjust htmldir
GIT 1.5.4-rc0
Linus Torvalds (1):
"git tag -u keyname" broken
Mike Hommey (4):
git-send-email.perl: Really add angle brackets to In-Reply-To if
necessary
Cleanup variables in http.[ch]
Fix small memory leaks induced by diff_tree_setup_paths
Fix XML parser leaks in http-push
Nguyễn Thái Ngọc Duy (1):
Remove repo version check from setup_git_directory
Nicolas Pitre (1):
pack-objects: more threaded load balancing fix with often changed paths
Pierre Habouzit (1):
Invert numbers and names in the git-shortlog summary mode.
Wincent Colaiuta (5):
Interactive editor tests for commit-msg hook
Style fixes for pre-commit hook tests
Use "whitespace" consistently
Documentation: minor grammar fix for "git apply"
Fix "diff --check" whitespace detection
^ 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