| From | Subject | Date |
|---|---|---|
| Daniel Barkalow | [PATCH] Merge non-first refs that match first refspec
The code only looked at the first ref in the map of refs when looking
for matches for the first refspec in the case where there is not
per-branch configuration of ref to merge. This is often sufficient,
but not always. Make the logic clearer and test everything in the map.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
---
I ran all the usual tests with this, and it seems like it should fix a bug
you saw, but I don't have the test case to make sure.
builtin-fetch.c | 7 ++++---...
| Sep 27, 11:52 pm 2007 |
| Johannes Schindelin | [PATCH] alloc_ref(): allow for trailing NUL
The parameter name "namelen" suggests that you pass the equivalent of
strlen() to the function alloc_ref(). However, this function did not
allocate enough space to put a NUL after the name.
Since struct ref does not have any member to describe the length of the
string, this just does not make sense.
So make space for the NUL.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
remote.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/remote...
| Sep 27, 10:57 pm 2007 |
| Dan Nicholson | Re: [PATCH] quiltimport: Skip non-existent patches
I forgot to mention the rationale for this patch vs. what Junio sent. The issue
with Junio's patch is that the failure will occur before $tmp_patch is created
because the script tries to feed git-mailinfo a non-existent patch
($patch_name). You'll only get past the mailinfo if $patch_name exists.
The marker setting may still be useful in this context, though, to suppress the
"doesn't exist" message.
--
Dan
-
| Sep 27, 4:39 pm 2007 |
| Junio C Hamano | Re: [PATCH] quiltimport: Skip non-existent patches
Thanks. I did not know what "marker" meant by the original
context and assumed there is a file referred to by the series
file but there is no patch in that file. Instead it seems that
a series file can contain something that is _not_ a file and
that is called the marker, right?
-
| Sep 27, 4:50 pm 2007 |
| Dan Nicholson | Re: [PATCH] quiltimport: Skip non-existent patches
I'm actually not a quilt user, but I tested out that patch on a repo
with a series containing a non-existent patch. I'm not sure what's
actually in Geerd's "marker", but I believe it's just random text.
When you run the command `quilt series', it just lists what's in the
series file (minus any comments). And when you run `quilt push' with a
non-existent patch, it says "Patch foo.patch does not exist; applied
empty patch"
So, I think the consistent thing to do is what's in my patch: just
skip t...
| Sep 27, 5:45 pm 2007 |
| Junio C Hamano | Re: [PATCH] quiltimport: Skip non-existent patches
Thanks for your helpful explanation. So perhaps we can do this
on top of yours to be safer and more consistent.
---
git-quiltimport.sh | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-quiltimport.sh b/git-quiltimport.sh
index 880c81d..627e023 100755
--- a/git-quiltimport.sh
+++ b/git-quiltimport.sh
@@ -79,8 +79,8 @@ for patch_name in $(grep -v '^#' < "$QUILT_PATCHES/series" ); do
git mailinfo "$tmp_msg" "$tmp_patch" \
<"$QUILT_PATCHES/$patch_name...
| Sep 27, 6:02 pm 2007 |
| Dan Nicholson | Re: [PATCH] quiltimport: Skip non-existent patches
That's seems fine. IIUC, mailinfo will only create an empty patch if
there's no actual patch content in the original mail/patch. In that
case, you probably do want to skip and not bomb. I'd changed my patch
to do 'if ! [ -s "$patch" ]' to catch an empty file, but this is
probably better. Hmm, checking `quilt push' on a patch with no actual
patch bombs. Here's the output:
$ quilt push
Applying patch foo.patch
patch: **** Only garbage was found in the patch input.
Patch foo.patch does not apply (...
| Sep 27, 6:20 pm 2007 |
| Denis Cheng | [PATCH] gitview: revamped to use string.join, stripped a fun...
Signed-off-by: Denis Cheng <crquan@gmail.com>
---
contrib/gitview/gitview | 13 +------------
1 files changed, 1 insertions(+), 12 deletions(-)
diff --git a/contrib/gitview/gitview b/contrib/gitview/gitview
index 5931766..2eb72b1 100755
--- a/contrib/gitview/gitview
+++ b/contrib/gitview/gitview
@@ -36,17 +36,6 @@ except ImportError:
re_ident = re.compile('(author|committer) (?P<ident>.*) (?P<epoch>\d+) (?P<tz>[+-]\d{4})')
-def list_to_string(args, skip):
- cou...
| Sep 27, 3:55 pm 2007 |
| Dan Farina | backup or mirror a repository
Hello list,
I have been poking around on IRC and gmane, but haven't yet seen a
solution to my problem:
What I really want is something semantically identical to a recursive
copy of my entire git repository on one machine sent to another machine.
Right now I can't simply use "rsync -ar --delete ..." because the pack
changes names, thus fooling rsync and sending a bunch of bits over the
network.
I saw git-mirror on gmane and asked around in IRC, but the former seems
to have died sometime last N...
| Sep 27, 3:35 pm 2007 |
| Johannes Schindelin | Re: backup or mirror a repository
Hi,
I guess you're looking for "git remote add --mirror origin <url>". AFAIK
this is not in any released version yet, though.
Ciao,
Dscho
-
| Sep 27, 5:56 pm 2007 |
| Dan Farina | Re: backup or mirror a repository
I just tried a bleeding edge git with --mirror.
It's close, except (unless there is some other provision to take care of
this) remote branch deletes. (Which, after more gmane trolling, seemed
to be "git remote rm", which doesn't seem present just yet).
Of course, it is completely possible I'm using it incorrectly. In brief,
I did "git init" "git remote add --mirror backup <url>" "git
pull" (perhaps I should have used "git remote update"?) And the behavior
of this is more or less what I wa...
| Sep 27, 8:51 pm 2007 |
| Johannes Schindelin | Re: backup or mirror a repository
Hi,
"git pull" without further parameters accesses the remote "origin", not
"backup", and it merges _one_ branch into the current branch.
What you should have done is "git fetch backup".
Or use "origin" instead of "backup" right from the start, and then use
"git fetch".
You want to remove branches from the local repo which are no longer there
on the remote side?
Then "git remote prune" is for you. For details, please see the man page.
Ciao,
Dscho
-
| Sep 27, 9:56 pm 2007 |
| Dan Farina | Re: backup or mirror a repository
Ah, I thought for some reason there'd be a "remove" (since the other
operations have long names) and, much like "ls-remote" there'd be some
"rm-remote." An insane presupposition of mine from having too little
I did use "pull backup" (my error for being sloppy and omitting it from
my mail) and it does work provided I do the dirty thing of doing a
subsequent reset --hard (I thought perhaps things were not yet
I did look at prune and update, but my problem is the opposite: I want
something that wi...
| Sep 27, 10:37 pm 2007 |
| Kelvie Wong | Mergetool generating blank files (1.5.3)
At work, I've been using a git-svn import for my daily workflow (still
somewhat of a git newbie, but now has come to the point where it's
tough to work without it), and while rebasing from svn (on a rather
old branch), I found that the mergetool option does not work too well
for me.
I am using version 1.5.3 and I have tried all of the different diff
tools (save opendiff) that are supported by git -- but in the middle
of a rebase, whenever I run the mergetool, the LOCAL, REMOTE, and BASE
temporary ...
| Sep 27, 2:31 pm 2007 |
| Pierre Habouzit | Re: Mergetool generating blank files (1.5.3)
Which tool are you using ? kdiff3 ? I've noticed that it often fails
miserably, or worse, create bad merges silentely with it.
And as none of the other merge tool that are supported are able to
either do 3way merges, or have a decent UI (that definitely seems to be
exclusive features) I've given up on git-mergetool (and to be fair, it
sucks, because it could be _sooo_ useful sometimes).
--=20
=C2=B7O=C2=B7 Pierre Habouzit
=C2=B7=C2=B7O madcod...
| Sep 27, 2:57 pm 2007 |
| Kelvie Wong | Re: Mergetool generating blank files (1.5.3)
I've tried all of the ones that were supported, the result is the same
-- blank files in all three windows.
It is because git mergetool fails to generate these files for whatever
reason (the filebasename.{REMOTE,LOCAL,BASE}.* files). I don't know
why this happens.
As for merge utilities, all I need is something that looks for the
first <<<<<, and lets me choose which version I want (either top or
bottom), plain and simple :/ I don't even need/want a gui.
But oh well, I guess t...
| Sep 27, 3:24 pm 2007 |
| Junio C Hamano | Re: Mergetool generating blank files (1.5.3)
Can you run git-mergetool under "sh -x"?
That is,
$ sh -x git-mergetool
around ll.160-170 these files are created.
-
| Sep 27, 3:58 pm 2007 |
| Kelvie Wong | Re: Mergetool generating blank files (1.5.3)
#######################################
$ sh -x /usr/local/bin/git-mergetool --tool=meld
+ USAGE=[--tool=tool] [file to merge] ...
+ SUBDIRECTORY_OK=Yes
+ . git-sh-setup
+ unset CDPATH
+ [ -z ]
+ LONG_USAGE=Usage: /usr/local/bin/git-mergetool [--tool=tool] [file
to merge] ...
+ [ -z Yes ]
+ git rev-parse --git-dir
+ GIT_DIR=/home/kelvie/src/trunk/.git
+ test -n /home/kelvie/src/trunk/.git
+ cd /home/kelvie/src/trunk/.git
+ pwd
+ GIT_DIR=/home/kelvie/src/trunk/.git
+ : /home/kelvie/src/tru...
| Sep 27, 4:12 pm 2007 |
| Junio C Hamano | Re: Mergetool generating blank files (1.5.3)
Wild guess. Are you running this from a subdirectory? I have a
mild suspicion that mergetool is not subdirectory safe. Can you
try running it from the toplevel of the work tree?
-
| Sep 27, 4:28 pm 2007 |
| Kelvie Wong | Re: Mergetool generating blank files (1.5.3)
Egads, it's alive!
I was in a subdirectory (most of my work is in that one subdirectory
anyways :p), but running it on the top level did indeed work as
expected.
Thanks,
Kelvie
--
Kelvie
-
| Sep 27, 4:38 pm 2007 |
| Junio C Hamano | Re: Mergetool generating blank files (1.5.3)
Thanks for spotting a bug. It claims to be subdirectory safe at
the top of the script but apparently it isn't.
And I do not see a reason why it cannot be made subdirectory
safe.
-
| Sep 27, 4:47 pm 2007 |
| Junio C Hamano | Re: Mergetool generating blank files (1.5.3)
It _could_ be just the matter of doing this, although I cannot
test it right now (at work and have no access to any of the
backends). Care to try it from a subdirectory and report
failure or success?
---
git-mergetool.sh | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/git-mergetool.sh b/git-mergetool.sh
index a0e44f7..018db58 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -12,6 +12,7 @@ USAGE='[--tool=tool] [file to merge] ...'
SUBDIRECTORY_OK=Yes
. ...
| Sep 27, 4:51 pm 2007 |
| Kelvie Wong | Re: Mergetool generating blank files (1.5.3)
At least with emerge, this isn't so simple -- emacs tries to save it
as ${absolute_PWD}/${PWD_relative_to_toplevel}/$filename
(which of course doesn't exist yet).
In meld it works fine, however; haven't tried the other ones.
--
Kelvie
-
| Sep 27, 5:17 pm 2007 |
| Kelvie Wong | Re: Mergetool generating blank files (1.5.3)
Hrm, on closer inspection, the old version of the mergetool script did this too.
It looks like the bug I mentioned does get fixed by that, and this is
a bug in emacs (or the way it's called).
--
Kelvie
-
| Sep 27, 5:22 pm 2007 |
| Junio C Hamano | Re: Mergetool generating blank files (1.5.3)
Actually, it seems that mergetool can take paths arguments, and
they need to be adjusted, so here is a fixed patch.
---
git-mergetool.sh | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/git-mergetool.sh b/git-mergetool.sh
index a0e44f7..56ec993 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -12,6 +12,8 @@ USAGE='[--tool=tool] [file to merge] ...'
SUBDIRECTORY_OK=Yes
. git-sh-setup
require_work_tree
+directory_prefix=$(git rev-parse --show-prefix)
+c...
| Sep 27, 5:33 pm 2007 |
| Junio C Hamano | Re: Mergetool generating blank files (1.5.3)
When mergetool is run from a subdirectory, "ls-files -u" nicely
limits the output to conflicted files in that directory, but
we need to give the full path to cat-file plumbing to grab the
contents of stages.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* I earlier sent one with cd_to_toplevel but I think the
approach in this patch is nicer.
git-mergetool.sh | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/git-mergetool.sh b/git-mergetool.sh
...
| Sep 27, 5:41 pm 2007 |
| Theodore Tso | Re: Mergetool generating blank files (1.5.3)
Acked-by: "Theodore Ts'o" <tytso@mit.edu>
- Ted
-
| Sep 27, 6:35 pm 2007 |
| Kelvie Wong | Re: Mergetool generating blank files (1.5.3)
--- a/git-mergetool 2007-09-24 09:08:23.000000000 -0700
+++ b/git-mergetool 2007-09-27 15:04:15.000000000 -0700
@@ -12,6 +12,7 @@
SUBDIRECTORY_OK=Yes
. git-sh-setup
require_work_tree
+prefix=$(git rev-parse --show-prefix)
# Returns true if the mode reflects a symlink
is_symlink () {
@@ -162,9 +163,9 @@
local_mode=`git ls-files -u -- "$path" | awk '{if ($3==2) print $1;}'`
remote_mode=`git ls-files -u -- "$path" | awk '{if ($3==3) print $1;}'`
- base_present ...
| Sep 27, 6:23 pm 2007 |
| Theodore Tso | Re: Mergetool generating blank files (1.5.3)
It's not that emacs sets $PWD via its first argument, but the output
file is passed from emerge-files*-command to stashed in the per-buffer
variable emerge-file-out, which in turn gets passed to the emacs lisp
file write-file, which is what gets run when you run C-x C-w --- and
write-file interprets a relative pathname based on the containing
Yep, I've checked both emacs21 and emacs23-snapshot, and they both use
write-file, so this seems to be a long-standing bug (and I would call
it that) in eme...
| Sep 27, 6:52 pm 2007 |
| Jeff King | Re: Mergetool generating blank files (1.5.3)
Huh? I use xxdiff all the time, and it works fine.
-Peff
-
| Sep 27, 3:12 pm 2007 |
| Pierre Habouzit | Re: Mergetool generating blank files (1.5.3)
I'm sorry but I find that the UI is terrible.
--=20
=C2=B7O=C2=B7 Pierre Habouzit
=C2=B7=C2=B7O madcoder@debia=
n.org
OOO http://www.madism.org
| Sep 27, 3:16 pm 2007 |
| Jeff King | Re: Mergetool generating blank files (1.5.3)
Fair enough.
-Peff
-
| Sep 27, 3:41 pm 2007 |
| Russ Brown | Re: Mergetool generating blank files (1.5.3)
What about meld? That does 3-way merge, and the UI is fine.
--
Russ
-
| Sep 27, 3:00 pm 2007 |
| Pierre Habouzit | Re: Mergetool generating blank files (1.5.3)
Indeed, it seems that since the last time I tested it, it now does
diff3 merging. I should reevaluate it :)
--=20
=C2=B7O=C2=B7 Pierre Habouzit
=C2=B7=C2=B7O madcoder@debia=
n.org
OOO http://www.madism.org
| Sep 27, 3:11 pm 2007 |
| Theodore Tso | Re: Mergetool generating blank files (1.5.3)
Pierre,
FYI, kdiff3, meld, xxdiff, opendiff (on MacOSX), and emerge all
support 3-way merge.
- Ted
-
| Sep 27, 6:23 pm 2007 |
| Pierre Habouzit | Re: Mergetool generating blank files (1.5.3)
I know, but:
* kdiff3 often take decisions behind your back, and results in broken
merges, so it's a no-go ;
* xxdiff has (IMHO) a very bad and non-intuitive UI, I never get to
make it work ;
* I don't use macos (opendiff) ;
* emerge is emacs right ? :)
Though I gave meld another chance, and it works really better than it
used to, so I may give it a try :) Let's hope I won't be disappointed by
meld :)
--=20
=C2=B7O=C2=B7 Pierre Habouzit
=C2=B7=C2=B7O ...
| Sep 27, 6:28 pm 2007 |
| Brett Schwarz | Re: Relating to some syntax error in the gitk script
What version of Tcl are you running? You should be using >= 8.4
____________________________________________________________________________________
Yahoo! oneSearch: Finally, mobile search
that gives answers, not web links.
http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC
-
| Sep 27, 1:00 pm 2007 |
| martin f krafft | ignoring non-submodule subrepositories
Hello,
I have a repository inside another, and for several reasons, I do
not want to use git-submodule in this case. My issue is that
git-status lists the subrepository as untracked.
Of course, I could add it to .gitignore alright, but instead
I wonder whether it would not make sense to ignore subdirectories
themselves containing .git/ directories, not explicitly so as to not
mess with git-submodule, but implicitly.
Thoughts?
--=20
martin; (greetings from the heart of the sun....
| Sep 27, 1:07 pm 2007 |
| Junio C Hamano | Re: ignoring non-submodule subrepositories
I've had a line "/Meta" in my .git/info/excludes ever since I
started to maintain the 'todo' branch (which is managed in an
independent repository situated there, and pushed into the
'todo' branch of git.git), and having to have that line never
bothered me.
While I do not think of a reason offhand not to ignore anything
that has .git/ and is not a subproject, other than that ignoring
might interfere your adding such a separate project as a
subproject. I know "git add" would countermand the igno...
| Sep 27, 3:29 pm 2007 |
| David Kastrup | Re: What's cooking in git.git (topics)
Linear probing is pretty efficient with regard to keeping memory
access locality. With a reasonable table filling ratio (not more than
something like 75%, for which it is necessary to know the maximum
number of hashable entries in advance), there is no gain to be
expected in either speed or even memory usage (the waste of 25% is
offset by not needing space for link pointers) with escape lists.
Linear probing hashes are quite hard to resize: if the maximum member
count is _not_ to be guessed in adv...
| Sep 27, 9:46 am 2007 |
| Pierre Habouzit | [PATCH] strbuf_read_file enhancement, and use it.
* make strbuf_read_file take a size hint (works like strbuf_read)
* use it in a couple of places.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
I just noticed someone introduced a nice strbuf_read_file API, so here is
a patch that diverts this nice idea to simplify git further.
builtin-apply.c | 12 ++----------
builtin-blame.c | 8 ++------
builtin-tag.c | 19 +++++++------------
strbuf.c | 4 ++--
strbuf.h | 2 +-
5 files changed, 14 insertio...
| Sep 27, 9:36 am 2007 |
| Pierre Habouzit | [PATCH] strbuf_read_file enhancement, and use it.
* make strbuf_read_file take a size hint (works like strbuf_read)
* use it in a couple of places.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
oh boy, once again I sent a half baked patch. okay, I'll stop for today :/
strbuf_read_file returns 0 or -1, not the size read.
builtin-apply.c | 12 ++----------
builtin-blame.c | 8 ++------
builtin-tag.c | 19 +++++++------------
strbuf.c | 4 ++--
strbuf.h | 2 +-
5 files changed, 14 insertions(+)...
| Sep 27, 9:25 am 2007 |
| Pierre Habouzit | git push (mis ?)behavior
There is a behavior of git-push that is the most annoying thing while
working with a central-repository: `git push` without any arguments
insists on pushing every local refspec that match one in origin.
While it's perfectly correct when you push to a public repository (you
do that seldom, and usually only after having prepared it with care),
it's not true for the central-repository layout. At work, I often have
this situation:
[I'm in the devel branch, would be next for git e.g.]
... hac...
| Sep 27, 9:04 am 2007 |
| Junio C Hamano | Re: git push (mis ?)behavior
The default is not --all but "matching branches", iow, what you
have never published yet never goes out.
Having said that, I would agree that in some workflows "I am on
this branch and I would want to push only this branch" would be
the norm, and the norm even be "and this branch 'foo' is called
identically as 'foo' at the remote site as well".
Don't worry about me when discussing to change the default.
Myself, I also often push only one or two branches. A typical
workflow for me while workin...
| Sep 27, 3:22 pm 2007 |
| Pierre Habouzit | Re: git push (mis ?)behavior
Sounds like a plan to me.
--=20
=C2=B7O=C2=B7 Pierre Habouzit
=C2=B7=C2=B7O madcoder@debia=
n.org
OOO http://www.madism.org
| Sep 27, 3:36 pm 2007 |
| Wincent Colaiuta | Re: git push (mis ?)behavior
I kind of agree. Without reading the git-push man page I would
intuitively expect "git push" with no arguments to push only the
Ah, nice alias! Thanks for sharing it.
Cheers,
Wincent
-
| Sep 27, 9:30 am 2007 |
| Benoit SIGOURE | Re: git push (mis ?)behavior
Same thing here, got bitten the same way.
--=20
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
| Sep 27, 11:28 am 2007 |
| Michele Ballabio | [PATCH] git-gui: fix typo in lib/blame.tcl
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
---
lib/blame.tcl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lib/blame.tcl b/lib/blame.tcl
index a911c3c..00ecf21 100644
--- a/lib/blame.tcl
+++ b/lib/blame.tcl
@@ -905,7 +905,7 @@ method _open_tooltip {cur_w} {
set author_time {}
catch {set author_name $header($cmit,author)}
catch {set summary $header($cmit,summary)}
- catch {set author_time [foramt_date $header($cmit,author-time)]}
+...
| Sep 27, 8:53 am 2007 |
| Shawn O. Pearce | Re: [PATCH] git-gui: fix typo in lib/blame.tcl
Shame on me. Thanks for the fix. :-)
--
Shawn.
-
| Sep 27, 10:14 pm 2007 |
| Ritwik Ghosh | Relating to some syntax error in the gitk script
Hi,
When I am running the gitk command I get the following error message:-
========================================================================
===========================
Error in startup script: syntax error in expression "$i >= [llength
$argv] && $revtreeargs ne {}"
while executing
"if {$i >= [llength $argv] && $revtreeargs ne {}} {
# no -- on command line, but some arguments (other than -d)
if {[catch {
set f [eval exec..."
(file "./gi...
| Sep 27, 8:22 am 2007 |
| previous day | today | next day |
|---|---|---|
| September 26, 2007 | September 27, 2007 | September 28, 2007 |
| Andrew Morton | -mm merge plans for 2.6.23 |
| Greg Kroah-Hartman | [PATCH 004/196] Chinese: add translation of SubmittingPatches |
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Gabriel C | Re: [Announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS] |
git: | |
| Gerrit Renker | [PATCH 03/37] dccp: List management for new feature negotiation |
| David Miller | [GIT]: Networking |
| Thomas Jarosch | Re: TCP connection stalls under 2.6.24.7 |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
