* gitk's copy pasteboard doesn't persist after it quits
From: Jonathan del Strother @ 2007-11-22 11:44 UTC (permalink / raw)
To: git
On OS X, if I load gitk, copy a sha1, then quit, the sha1 isn't put
into the system-wide pasteboard. It's definitely copied - I can paste
it back into the sha1 field - but it seems to be some sort of local
pasteboard that's specific to gitk
If I switch to another app, the sha1 is stored in the pasteboard
correctly, and I can then quit gitk and still have it available. I'm
guessing that gitk (or Tcl/Tk) is syncing with the system-wide
pasteboard on focus change, but not on quit.
I'm using the version of gitk in 388afe7881b, and Tcl 8.4.7
Any suggestions on fixing / working around this?
Jon
^ permalink raw reply
* Re: [PATCH] rebase -i: move help to end of todo file
From: Junio C Hamano @ 2007-11-22 11:46 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0711221113360.27959@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> How about this? I am hesitant to remove _everything_, since quite
> a few people seem to be allergic to man pages, so they fire up
> rebase -i without any clue.
Oh, I wouldn't dream of suggesting complete removal of the help
text, but leaving the single line at the beginning is not an
improvement. What's on that single line is not particularly
useful but that is a separate issue.
Moving everything down will hurt ONLY when (1) the rebase is
about a large series (more than 24 commits in vt100) AND (2) the
user hasn't run "rebase -i" before and does not know that there
is a reminder insn at the end. Now is it likely for a newbie to
run "rebase -i" with 20-30 commits and that invocation is his
first "rebase -i" invocation in his life?
The new help line at the end is helpful, by the way. I always
had "Huh?" moment, and did ^Z followed by kill %% instead.
^ permalink raw reply
* Re: Adding push configuration to .git/config
From: Junio C Hamano @ 2007-11-22 11:49 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Steffen Prohaska, Nico -telmich- Schottelius, git
In-Reply-To: <Pine.LNX.4.64.0711221120300.27959@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> I have to say that I slowly grow an antipathy for "git push" without
> parameters. _All_ of the confusions with push that I saw stem from being
> too lazy to say where and what you want to push.
The same thing can be said for "fetch" by the way.
^ permalink raw reply
* Re: [PATCH 0/5] Colors for git-add--interactive
From: Jeff King @ 2007-11-22 11:57 UTC (permalink / raw)
To: Dan Zwell
Cc: Junio C Hamano, Shawn O. Pearce, Wincent Colaiuta,
Git Mailing List, Jonathan del Strother, Johannes Schindelin,
Frank Lichtenheld, Jakub Narebski
In-Reply-To: <20071122045437.46ee4638@paradox.zwell.net>
On Thu, Nov 22, 2007 at 04:54:37AM -0600, Dan Zwell wrote:
> - Does not always properly color the output of git-diff --cc, because
> the diff-coloring regular expressions do not match every diff line.
> I'm not sure that git-add--interactive normally gets used in the same
> situations as git-diff --cc. They don't seem to work well, together,
> from the little that I tested (without the color patches applied).
> There are a few solutions, but I haven't thought of one that's both
> reliable and clean. My impression is that diff --cc is called any time
> that HEAD has two parents. Is this correct?
I think the only time that git-add--interactive is likely to see a
combined diff is when you have unmerged entries in the index. Something
like:
$ mkdir foo && cd foo && git init
$ touch file && git add file && git commit -m added
$ echo master >file && git commit -a -m master
$ git checkout -b other HEAD^
$ echo other >file && git commit -a -m other
$ git merge master
$ git diff
-Peff
^ permalink raw reply
* Re: Adding push configuration to .git/config
From: Andreas Ericsson @ 2007-11-22 11:59 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Steffen Prohaska, Nico -telmich- Schottelius,
git
In-Reply-To: <7v7ika5wld.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>> I have to say that I slowly grow an antipathy for "git push" without
>> parameters. _All_ of the confusions with push that I saw stem from being
>> too lazy to say where and what you want to push.
>
> The same thing can be said for "fetch" by the way.
I disagree, since "fetch" at worst will auto-update the remote-tracking
branches only, while "push" may publish changes that are downright
wrong and never meant for publishing. What's worse is that fixing up
published history is a whole lot messier than it is to fix ones own
remote-tracking branches.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] bundle create: keep symbolic refs' names instead of resolving them
From: Johannes Schindelin @ 2007-11-22 12:03 UTC (permalink / raw)
To: Santi Béjar; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0711211652470.27959@racer.site>
Hi,
On Wed, 21 Nov 2007, Johannes Schindelin wrote:
>
> When creating a bundle, symbolic refs used to be resolved to the
> non-symbolic refs they point to before being written to the list
> of contained refs. I.e. "git bundle create a1.bundle HEAD master"
> would show something like
>
> 388afe7881b33102fada216dd07806728773c011 refs/heads/master
> 388afe7881b33102fada216dd07806728773c011 refs/heads/master
Aaargh.
My patch broke "git bundle create x master". I somehow believed that
resolve_ref () would turn "master" into "refs/heads/master", which it does
not do.
So please ignore this patch.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 2/5] Don't return 'undef' in case called in a vector context.
From: Jeff King @ 2007-11-22 12:06 UTC (permalink / raw)
To: Dan Zwell
Cc: Git Mailing List, Junio C Hamano, Shawn O. Pearce,
Wincent Colaiuta, Jonathan del Strother, Johannes Schindelin,
Frank Lichtenheld, Jakub Narebski
In-Reply-To: <20071122045534.435f01bb@paradox.zwell.net>
On Thu, Nov 22, 2007 at 04:55:34AM -0600, Dan Zwell wrote:
> Previously, the Git->repository()->config('non-existent.key')
> evaluated to as true in a vector context. Call 'return' with
> no argument, instead.
I think the reason this works is a subtle issue (well, I had to look it
up, anyway): return without an argument automatically checks the calling
context and returns the empty list in a list context. So we are
returning an empty list now, instead of a list containing a single
undef. I think it might be useful to explain this a bit better in the
commit message.
-Peff
^ permalink raw reply
* Re: [PATCH 3/5] Added config_default($key, $default) to Git.pm
From: Jeff King @ 2007-11-22 12:14 UTC (permalink / raw)
To: Dan Zwell
Cc: Git Mailing List, Junio C Hamano, Shawn O. Pearce,
Wincent Colaiuta, Jonathan del Strother, Johannes Schindelin,
Frank Lichtenheld, Jakub Narebski
In-Reply-To: <20071122045552.30ca55c2@paradox.zwell.net>
On Thu, Nov 22, 2007 at 04:55:52AM -0600, Dan Zwell wrote:
> Method returns a configuration value if defined, or the default
> value that was passed in, otherwise.
>
> The main purpose of this method is to allow the empty string to
> be a valid configuration option, and to replace the following
> construct:
>
> $val = $repo->config('my.key') || $default_val
The config subroutine does not currently take a third argument. Is there
a particular reason not to make $repo->config('my.key', $default_val)
the equivalent of config_default?
> +in situations where the empty string is an acceptable return value.
> +This method may also be called in a vector context, when expecting
The term "vector context" is not commonly used. Most of the perl
documentation calls it "list context" (try googling for each and seeing
the hit numbers).
-Peff
^ permalink raw reply
* Re: [PATCH 4/5] Let git-add--interactive read colors from configuration
From: Jeff King @ 2007-11-22 12:18 UTC (permalink / raw)
To: Dan Zwell
Cc: Git Mailing List, Junio C Hamano, Shawn O. Pearce,
Wincent Colaiuta, Jonathan del Strother, Johannes Schindelin,
Frank Lichtenheld, Jakub Narebski
In-Reply-To: <20071122045606.0232fc2d@paradox.zwell.net>
On Thu, Nov 22, 2007 at 04:56:06AM -0600, Dan Zwell wrote:
> + # Grab the 3 main colors in git color string format, with sane
> + # (visible) defaults:
> + $prompt_color = Git::color_to_ansi_code(
> + scalar $repo->config_default('color.interactive.prompt',
> + 'bold blue'));
And by the same token as the last message, given that config_* take only
two arguments, is there a reason not to extend them so that
$repo->config_bool('my.key', 0);
handles the default. Then I think you could simplify this to just:
$repo->config_color('color.interactive.prompt', 'bold blue');
and hide the color_to_ansi_code messiness from the script altogether.
-Peff
^ permalink raw reply
* [REPLACEMENT PATCH] bundle create: keep symbolic refs' names instead of resolving them
From: Johannes Schindelin @ 2007-11-22 12:24 UTC (permalink / raw)
To: Santi B?jar, gitster; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0711211652470.27959@racer.site>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2101 bytes --]
When creating a bundle, symbolic refs used to be resolved to the
non-symbolic refs they point to before being written to the list
of contained refs. I.e. "git bundle create a1.bundle HEAD master"
would show something like
388afe7881b33102fada216dd07806728773c011 refs/heads/master
388afe7881b33102fada216dd07806728773c011 refs/heads/master
instead of
388afe7881b33102fada216dd07806728773c011 HEAD
388afe7881b33102fada216dd07806728773c011 refs/heads/master
Introduce a special handling so that the symbolic refs are listed
with the names passed on the command line.
Noticed by Santi Béjar.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
... and this patch actually does not break the test suite.
bundle.c | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/bundle.c b/bundle.c
index e4d60cd..9b9b916 100644
--- a/bundle.c
+++ b/bundle.c
@@ -6,6 +6,7 @@
#include "revision.h"
#include "list-objects.h"
#include "run-command.h"
+#include "refs.h"
static const char bundle_signature[] = "# v2 git bundle\n";
@@ -232,11 +233,17 @@ int create_bundle(struct bundle_header *header, const char *path,
struct object_array_entry *e = revs.pending.objects + i;
unsigned char sha1[20];
char *ref;
+ const char *display_ref;
+ int flag;
if (e->item->flags & UNINTERESTING)
continue;
if (dwim_ref(e->name, strlen(e->name), sha1, &ref) != 1)
continue;
+ if (!resolve_ref(e->name, sha1, 1, &flag))
+ flag = 0;
+ display_ref = (flag & REF_ISSYMREF) ? e->name : ref;
+
/*
* Make sure the refs we wrote out is correct; --max-count and
* other limiting options could have prevented all the tips
@@ -287,7 +294,7 @@ int create_bundle(struct bundle_header *header, const char *path,
ref_count++;
write_or_die(bundle_fd, sha1_to_hex(e->item->sha1), 40);
write_or_die(bundle_fd, " ", 1);
- write_or_die(bundle_fd, ref, strlen(ref));
+ write_or_die(bundle_fd, display_ref, strlen(display_ref));
write_or_die(bundle_fd, "\n", 1);
free(ref);
}
--
1.5.3.6.1977.g54d30
^ permalink raw reply related
* Re: [PATCH 5/5] Added diff hunk coloring to git-add--interactive
From: Jeff King @ 2007-11-22 12:25 UTC (permalink / raw)
To: Dan Zwell
Cc: Git Mailing List, Junio C Hamano, Shawn O. Pearce,
Wincent Colaiuta, Jonathan del Strother, Johannes Schindelin,
Frank Lichtenheld, Jakub Narebski
In-Reply-To: <20071122045624.405e2b2b@paradox.zwell.net>
On Thu, Nov 22, 2007 at 04:56:24AM -0600, Dan Zwell wrote:
> - else { # set up colors
> - # Grab the 3 main colors in git color string format, with sane
> - # (visible) defaults:
> - $prompt_color = Git::color_to_ansi_code(
> - scalar $repo->config_default('color.interactive.prompt',
> - 'bold blue'));
These were just added in the last patch. I know sometimes it is worth
showing the progression of work as the patches go, but in this case, I
think it is simpler for the reviewers if the first patch which adds a
chunk of code does it in the final way (even if you need to just say "I
did it this way because there will be reasons later on.").
> + sub get_color {
> + my ($key, $default) = @_;
> + return Git::color_to_ansi_code(
> + scalar $repo->config_default($key, $default));
> + }
Ah, so you agree that this is a good route. I think this should probably
be Git::config_color.
There is also a subtle issue, which is that it pulls the "$repo"
variable from the outer lexical scope (as Git::config_color, it would
take it as the first parameter).
> + $prompt_color = get_color('color.interactive.prompt', 'bold blue');
> + $header_color = get_color('color.interactive.header', 'bold');
> + $help_color = get_color('color.interactive.help', 'red bold');
> + $normal_color = Git::color_to_ansi_code('normal');
Yeah, much nicer to read.
> + if ($diff_use_color) {
> + $new_color = get_color('color.diff.new', 'green');
> + $old_color = get_color('color.diff.old', 'red');
> + $fraginfo_color = get_color('color.diff.frag', 'cyan');
> + $metainfo_color = get_color('color.diff.meta', 'bold');
> + $normal_color = Git::color_to_ansi_code('normal');
> + # Not implemented:
> + #$whitespace_color = get_color('color.diff.whitespace',
> + #'normal red');
Unfortunately, there is a historical wart that probably still needs
supporting, which is that the original names were diff.color.*. Or have
we officially removed support for that yet?
-Peff
^ permalink raw reply
* Re: [PATCH] rebase -i: move help to end of todo file
From: Johannes Schindelin @ 2007-11-22 12:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbq9m5wpa.fsf@gitster.siamese.dyndns.org>
Hi,
On Thu, 22 Nov 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > How about this? I am hesitant to remove _everything_, since quite
> > a few people seem to be allergic to man pages, so they fire up
> > rebase -i without any clue.
>
> Oh, I wouldn't dream of suggesting complete removal of the help
> text,
I meant to "move" everything. Sorry.
> but leaving the single line at the beginning is not an improvement.
> What's on that single line is not particularly useful but that is a
> separate issue.
Okay, so you'd like this better?
-- snipsnap --
[PATCH] rebase -i: move help to end of todo file
Many editors start in the first line, so the 9-line help text was an
annoyance. So move it to the end.
Requested by Junio.
While at it, add a hint how to abort the rebase.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
git-rebase--interactive.sh | 14 ++++++++------
t/t3404-rebase-interactive.sh | 3 ++-
2 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index a6dc72a..58fde89 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -479,8 +479,13 @@ do
SHORTUPSTREAM=$(git rev-parse --short $UPSTREAM)
SHORTHEAD=$(git rev-parse --short $HEAD)
SHORTONTO=$(git rev-parse --short $ONTO)
- cat > "$TODO" << EOF
-# Rebasing $SHORTUPSTREAM..$SHORTHEAD onto $SHORTONTO
+ git rev-list $MERGES_OPTION --pretty=oneline --abbrev-commit \
+ --abbrev=7 --reverse --left-right --cherry-pick \
+ $UPSTREAM...$HEAD | \
+ sed -n "s/^>/pick /p" > "$TODO"
+ cat >> "$TODO" << EOF
+
+# Rebase $SHORTUPSTREAM..$SHORTHEAD onto $SHORTONTO
#
# Commands:
# pick = use commit
@@ -488,12 +493,9 @@ do
# squash = use commit, but meld into previous commit
#
# If you remove a line here THAT COMMIT WILL BE LOST.
+# However, if you remove everything, the rebase will be aborted.
#
EOF
- git rev-list $MERGES_OPTION --pretty=oneline --abbrev-commit \
- --abbrev=7 --reverse --left-right --cherry-pick \
- $UPSTREAM...$HEAD | \
- sed -n "s/^>/pick /p" >> "$TODO"
has_action "$TODO" ||
die_abort "Nothing to do"
diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
index f1039d1..907c7f9 100755
--- a/t/t3404-rebase-interactive.sh
+++ b/t/t3404-rebase-interactive.sh
@@ -149,7 +149,8 @@ test_expect_success 'stop on conflicting pick' '
diff -u expect .git/.dotest-merge/patch &&
diff -u expect2 file1 &&
test 4 = $(grep -v "^#" < .git/.dotest-merge/done | wc -l) &&
- test 0 = $(grep -v "^#" < .git/.dotest-merge/git-rebase-todo | wc -l)
+ test 0 = $(grep -ve "^#" -e "^$" < .git/.dotest-merge/git-rebase-todo |
+ wc -l)
'
test_expect_success 'abort' '
--
1.5.3.6.1977.g54d30
^ permalink raw reply related
* Re: [PATCH] rebase -i: move help to end of todo file
From: Jeff King @ 2007-11-22 12:31 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0711221225570.27959@racer.site>
On Thu, Nov 22, 2007 at 12:30:10PM +0000, Johannes Schindelin wrote:
> I meant to "move" everything. Sorry.
>
> > but leaving the single line at the beginning is not an improvement.
> > What's on that single line is not particularly useful but that is a
> > separate issue.
>
> Okay, so you'd like this better?
I like it much better (I was about to send the same complaint about the
top line, but Junio beat me to it).
-Peff
^ permalink raw reply
* Re: Git in a Nutshell guide
From: Jonas Juselius @ 2007-11-22 13:15 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <fhsc7b$k4g$1@ger.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1214 bytes --]
I'm planning to write a section in the "Nutshell guide" on rewriting
history and rebasing. I have a question related to rewriting history. As
usual, I'll assume that the part of the history I'm mucking with has not
been pushed or pulled by anyone.
Suppose I have been working on some topic branch for a while and been
overly trigger happy, i.e. I have produced a ridiculous number of
commits along the way. At some point when I'm done I want to publish my
changes, but doing so would create an insanely obese history full of
near nonsense commits. What I want to do is to slim down the commit log
into pieces that actually makes sense. What is the preferred (or best,
most convenient) way of doing this? The way I have done this previously
is essentially:
1. git branch -m mytopic tmp_mytopic # rename
2. git branch mytopci tmp_mytpoic~42 # go back in history
Loop:
3.1 git log; git diff; git annotate...
3.2 git diff tmp_mytopic~42..tmp_mytopic~33 | git-apply
3.3 git commit -m "sane commit message" -a
4. git branch -d tmp_mytopic
If I need to reorder commits I can first use git-rebase -i to get
everything streamlined. There must be a better way of doing this, right?
.jonas.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 2/4] Teach git-add--interactive to accept a file path to patch
From: Wincent Colaiuta @ 2007-11-22 13:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7vlk8q5xj4.fsf@gitster.siamese.dyndns.org>
El 22/11/2007, a las 12:29, Junio C Hamano escribió:
> It is quite valid for users to run:
>
> git add -i \*.sh
>
> and be able to choose from a list which paths to stage (as a
> whole), as well as choose from a list which files to run the
> per-hunk staging interface. "git add \*.sh" won't give you any
> chance to choose which ones to stage, and that's what we have
> "-i" (interactive) mode in "git add" for.
>
> I think you can massage "git add --partial foo" given by the
> user internally into "git-add--interactive -i --patch foo". I
> strongly suspect that "direct to patch subcommand" mode needs
> more than just initially jumping into the subcommand (for
> example, you would want to exit when the patch selection
> interaction ends, without going back to the main menu)
This will become especially important if we decide to allow "git
commit --interactive" to accept a path spec as well (although exactly
when we should exit isn't immediately clear to me); I didn't touch
this for the time-being because builtin-commit is getting very close
to replacing git-commit.sh.
> and we
> would want a signal stronger than mere presense of pathspecs to
> trigger such a specialized behaviour.
>
> By the way, the arguments on the command line to git commands
> after "--" are generally pathspecs, iow, patterns to specify
> groups of files. Please do not introduce unnecessary
> inconsistencies to the UI by requiring them to be exact pathname
> only in this particular mode of the command and nowhere else.
Well, I it wasn't my intention to introduce any such requirement. The
path parameters get passed in and eventually handed over unmodified to:
git diff-files -p --
Which was what was previously in the parse_diff function. It turns out
that if you pass something like \*.sh to git-diff-files then it won't
match, but it's not a restriction that I chose to impose, rather it's
a consequence of the way git-diff-files works. Are there options we
could pass to avoid that restriction?
In any case, one good thing to come out of this discussion is the
ability to use pathspecs to limit the number of files displayed when
in interactive mode. But it wasn't what I was originally aiming for.
My initial goal was to have git-add--interactive do something useful
and convenient when you type:
git add -i foo
If we don't jump straight to the subcommand then the user has to:
- press 5 or p, then Enter
- press 1, then Enter
This was easier than it was before (same number of keystrokes, but
fewer files to visually scan in the list of candidates), but it's
still not that much easier.
Or if we add some kind of "--patch" switch, instead do:
git add -i --patch foo
Once again, not that easy but you could always set up a Git alias, I
guess, as a shortcut. Not sure whether this is offers enough of a
workflow improvement to make it worthwhile (ie. you may as well just
fire up git-gui).
> There was one funny thing I fixed up. The arguments to the
> interactive_add() function in builtin-add.c was like this:
>
> int interactive_add(const char **argv, int argc)
>
> Anybody who writes a function with such a signature and do not
> notice its craziness before sending it out either (1) has never
> programmed in C, (2) did not review the code before submitting,
> or (3) worked too hard and was too tired.
>
> I suspect, judging from the timestamp of your message, it was
> (3) this time. The collaborative development is not a race ---
> don't work too hastily and too hard; please relax and review
> after a good night's sleep before sending things out.
In any case I've rebased and squished the changes down to a nice 4-
patch series, incorporating all the feedback given so far. Will sit on
it a while before sending it out, as you suggest. But I don't really
have a clear idea where to go forward from here.
Cheers,
Wincent
^ permalink raw reply
* git-svn: surprising behaviors/bugs?
From: Gustaf Hendeby @ 2007-11-22 13:37 UTC (permalink / raw)
To: git
I've been running git for most my stuff for some time now, and am
really pleased with what it has to offer. However, all my coworkers
aren't gitified yet, and therefore I sometimes have to work with svn.
I've learned to appreciate git-svn for this, since it lets me utilize
the strengths of git and still allows for my coworkers to think I use
their svn setup. Thanks to all who contribute to this wonderful
tools!
In my work with git-svn I have stumbled upon the following two
unexpected behaviors. Basically, am I doing/understanding something
wrong, or is this buggy behavior in git-svn? (I'm presently using git
1.5.3.6, but have been experiencing these things for a while.)
1. I don't really like svn's committer info, so I got an authorsfile
set. This works great when I'm fetching/dcommitting from the
top-directory in my git checkout (the one with .git in), however, if
I'm in a subdirectory the authorsfile doesn't kick in and I get the
svn commiter info. This is not a big deal, but a bit surprising and
my history gets a bit ugly.
2. My second problem involves getting the support in git-svn for tags
and branches to work. Having a standard layout of the svn repository,
in this case
/source/project/(trunk|branch|tags)
svn clone -s only works as expected sometimes. Sometimes I only get
the revision history, not including any actual content (ie none files
of the files under control turns up in git) from the clone. When I
get this problem I usually clone the trunk only, and add tags myself.
This is far from optimal, and also error prone. Other times, the
clone works as expected and gives me the tags and branches and all the
content.
I think the problem occurs when I'm not the owner of the svn
repository, and only have access (read/write) to the
project/(trunk|branch|tag) part, and don't have any access at all to
source. Ie, svn ls works for /source/project and
/source/project/trunk etc, but not /source (where I returns 403
Forbidden access). All svn access is through a svn-server that I
can't control myself.
I've had a quick look in git-svn.perl, but the code is to beyond my
limited perl knowledge. I'd be happy to provide more details if
anyone is interested in looking deeper into this. Any ideas or
comments are greatly appreciated!
/Gustaf
^ permalink raw reply
* [PATCH] git-svn: add support for pulling author from From: and Signed-off-by:
From: Andy Whitcroft @ 2007-11-22 13:44 UTC (permalink / raw)
To: git
Add support for pulling the real author of a commit from the From:
and first Signed-off-by: fields of the SVN commit message.
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
---
This is a feature that git-svnimport had and I have just
discovered that git-svnimport was deleted some time back
but due to the install strategy I seem to have an old
one in there which I was still using; and so had not noticed
its official removal. Ouch.
Perhaps we should install a "gone" stub for things which are
removed for one release to partly catch this.
---
git-svn.perl | 36 +++++++++++++++++++++++++++++-------
1 files changed, 29 insertions(+), 7 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 5b1deea..a99982d 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -80,6 +80,7 @@ my %fc_opts = ( 'follow-parent|follow!' => \$Git::SVN::_follow_parent,
'quiet|q' => \$_q,
'repack-flags|repack-args|repack-opts=s' =>
\$Git::SVN::_repack_flags,
+ 'use-log-author' => \$Git::SVN::_use_log_author,
%remote_opts );
my ($_trunk, $_tags, $_branches, $_stdlayout);
@@ -1048,7 +1049,8 @@ use strict;
use warnings;
use vars qw/$default_repo_id $default_ref_id $_no_metadata $_follow_parent
$_repack $_repack_flags $_use_svm_props $_head
- $_use_svnsync_props $no_reuse_existing $_minimize_url/;
+ $_use_svnsync_props $no_reuse_existing $_minimize_url
+ $_use_log_author/;
use Carp qw/croak/;
use File::Path qw/mkpath/;
use File::Copy qw/copy/;
@@ -1873,11 +1875,17 @@ sub do_git_commit {
croak "$log_entry->{revision} = $c already exists! ",
"Why are we refetching it?\n";
}
- $ENV{GIT_AUTHOR_NAME} = $ENV{GIT_COMMITTER_NAME} = $log_entry->{name};
- $ENV{GIT_AUTHOR_EMAIL} = $ENV{GIT_COMMITTER_EMAIL} =
- $log_entry->{email};
+ $ENV{GIT_AUTHOR_NAME} = $log_entry->{name};
+ $ENV{GIT_AUTHOR_EMAIL} = $log_entry->{email};
$ENV{GIT_AUTHOR_DATE} = $ENV{GIT_COMMITTER_DATE} = $log_entry->{date};
+ $ENV{GIT_COMMITTER_NAME} = (defined $log_entry->{commit_name})
+ ? $log_entry->{commit_name}
+ : $log_entry->{name};
+ $ENV{GIT_COMMITTER_EMAIL} = (defined $log_entry->{commit_email})
+ ? $log_entry->{commit_email}
+ : $log_entry->{email};
+
my $tree = $log_entry->{tree};
if (!defined $tree) {
$tree = $self->tmp_index_do(sub {
@@ -2165,7 +2173,16 @@ sub make_log_entry {
$log_entry{log} .= "\n";
my $author = $log_entry{author} = check_author($log_entry{author});
my ($name, $email) = defined $::users{$author} ? @{$::users{$author}}
- : ($author, undef);
+ : ($author, undef);
+
+ my ($commit_name, $commit_email) = ($name, $email);
+ if ($_use_log_author) {
+ if ($log_entry{log} =~ /From:\s+(.*?)\s+<(.*)>\s*\n/) {
+ ($name, $email) = ($1, $2);
+ } elsif ($log_entry{log} =~ /Signed-off-by:\s+(.*?)\s+<(.*)>\s*\n/) {
+ ($name, $email) = ($1, $2);
+ }
+ }
if (defined $headrev && $self->use_svm_props) {
if ($self->rewrite_root) {
die "Can't have both 'useSvmProps' and 'rewriteRoot' ",
@@ -2188,23 +2205,28 @@ sub make_log_entry {
remove_username($full_url);
$log_entry{metadata} = "$full_url\@$r $uuid";
$log_entry{svm_revision} = $r;
- $email ||= "$author\@$uuid"
+ $email ||= "$author\@$uuid";
+ $commit_email ||= "$author\@$uuid";
} elsif ($self->use_svnsync_props) {
my $full_url = $self->svnsync->{url};
$full_url .= "/$self->{path}" if length $self->{path};
remove_username($full_url);
my $uuid = $self->svnsync->{uuid};
$log_entry{metadata} = "$full_url\@$rev $uuid";
- $email ||= "$author\@$uuid"
+ $email ||= "$author\@$uuid";
+ $commit_email ||= "$author\@$uuid";
} else {
my $url = $self->metadata_url;
remove_username($url);
$log_entry{metadata} = "$url\@$rev " .
$self->ra->get_uuid;
$email ||= "$author\@" . $self->ra->get_uuid;
+ $commit_email ||= "$author\@" . $self->ra->get_uuid;
}
$log_entry{name} = $name;
$log_entry{email} = $email;
+ $log_entry{commit_name} = $commit_name;
+ $log_entry{commit_email} = $commit_email;
\%log_entry;
}
^ permalink raw reply related
* [PATCH] Tweak git-quiltimport to allow more flexible series format
From: Alexey Dobriyan @ 2007-11-22 13:48 UTC (permalink / raw)
To: git; +Cc: adobriyan
Make quiltimport also understand comments following patch name.
Signed-off-by: Alexey Dobriyan <adobriyan@sw.ru>
---
git-quiltimport.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/git-quiltimport.sh
+++ b/git-quiltimport.sh
@@ -63,7 +63,7 @@ tmp_info="$tmp_dir/info"
commit=$(git rev-parse HEAD)
mkdir $tmp_dir || exit 2
-for patch_name in $(grep -v '^#' < "$QUILT_PATCHES/series" ); do
+for patch_name in $(sed -e 's/#.*//' < "$QUILT_PATCHES/series" ); do
if ! [ -f "$QUILT_PATCHES/$patch_name" ] ; then
echo "$patch_name doesn't exist. Skipping."
continue
^ permalink raw reply
* Re: Git in a Nutshell guide
From: Jonathan del Strother @ 2007-11-22 14:19 UTC (permalink / raw)
To: Jonas Juselius; +Cc: git
In-Reply-To: <1195737303.19260.27.camel@localhost>
On 22 Nov 2007, at 13:15, Jonas Juselius wrote:
> I'm planning to write a section in the "Nutshell guide" on rewriting
> history and rebasing. I have a question related to rewriting
> history. As
> usual, I'll assume that the part of the history I'm mucking with has
> not
> been pushed or pulled by anyone.
> Suppose I have been working on some topic branch for a while and been
> overly trigger happy, i.e. I have produced a ridiculous number of
> commits along the way. At some point when I'm done I want to publish
> my
> changes, but doing so would create an insanely obese history full of
> near nonsense commits. What I want to do is to slim down the commit
> log
> into pieces that actually makes sense. What is the preferred (or best,
> most convenient) way of doing this? The way I have done this
> previously
> is essentially:
>
> 1. git branch -m mytopic tmp_mytopic # rename
> 2. git branch mytopci tmp_mytpoic~42 # go back in history
> Loop:
> 3.1 git log; git diff; git annotate...
> 3.2 git diff tmp_mytopic~42..tmp_mytopic~33 | git-apply
> 3.3 git commit -m "sane commit message" -a
> 4. git branch -d tmp_mytopic
>
> If I need to reorder commits I can first use git-rebase -i to get
> everything streamlined. There must be a better way of doing this,
> right?
I may be missing something here, but you know that you can edit
commits and squash commits together (using something like "git rebase
--interactive mytopic~42"), right?
^ permalink raw reply
* Re: Git in a Nutshell guide
From: Johannes Schindelin @ 2007-11-22 14:24 UTC (permalink / raw)
To: Jonas Juselius; +Cc: Jakub Narebski, git
In-Reply-To: <1195737303.19260.27.camel@localhost>
Hi,
On Thu, 22 Nov 2007, Jonas Juselius wrote:
> Suppose I have been working on some topic branch for a while and been
> overly trigger happy, i.e. I have produced a ridiculous number of
> commits along the way. At some point when I'm done I want to publish my
> changes, but doing so would create an insanely obese history full of
> near nonsense commits. What I want to do is to slim down the commit log
> into pieces that actually makes sense. What is the preferred (or best,
> most convenient) way of doing this? The way I have done this previously
> is essentially:
>
> 1. git branch -m mytopic tmp_mytopic # rename
> 2. git branch mytopci tmp_mytpoic~42 # go back in history
> Loop:
> 3.1 git log; git diff; git annotate...
> 3.2 git diff tmp_mytopic~42..tmp_mytopic~33 | git-apply
> 3.3 git commit -m "sane commit message" -a
> 4. git branch -d tmp_mytopic
>
> If I need to reorder commits I can first use git-rebase -i to get
> everything streamlined. There must be a better way of doing this, right?
Yes, you can squash commits into previous commits with rebase -i. Just
replace the second "pick" command (and if you want to squash more than
two, the later commands, too) with "squash".
Hth,
Dscho
^ permalink raw reply
* [PATCH] git-gui: fix a typo in lib/commit.tcl
From: Michele Ballabio @ 2007-11-22 15:20 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
---
lib/commit.tcl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lib/commit.tcl b/lib/commit.tcl
index 5723812..e62201a 100644
--- a/lib/commit.tcl
+++ b/lib/commit.tcl
@@ -184,7 +184,7 @@ You must stage at least 1 file before you can commit.
A good commit message has the following format:
-- First line: Describe in one sentance what you did.
+- First line: Describe in one sentence what you did.
- Second line: Blank
- Remaining lines: Describe why this change is good.
}
--
1.5.3.5
^ permalink raw reply related
* Re: [PATCH] Fix segmentation fault when user doesn't have access permission to the repository.
From: Alex Riesen @ 2007-11-22 16:09 UTC (permalink / raw)
To: André Goddard Rosa; +Cc: gitster, Git Mailing List
In-Reply-To: <b8bf37780711211659i4d621533o6a3b97349bb75f8c@mail.gmail.com>
André Goddard Rosa, Thu, Nov 22, 2007 01:59:00 +0100:
> @@ -487,8 +490,13 @@ static int do_fetch(struct transport *transport,
> die("Don't know how to fetch from %s", transport->url);
>
> /* if not appending, truncate FETCH_HEAD */
> - if (!append)
> - fclose(fopen(git_path("FETCH_HEAD"), "w"));
> + if (!append) {
> + char *filename = git_path("FETCH_HEAD");
> + int fd = fopen(filename, "w");
This should have been "FILE *fp", not "int fd".
> + if (!fd)
> + return error("cannot open %s: %s\n", filename, strerror(errno));
> + fclose(fd);
> + }
>
> ref_map = get_ref_map(transport, refs, ref_count, tags, &autotags);
>
> --
> 1.5.3.6.861.gd794-dirty
>
^ permalink raw reply
* git-svn rebase issues (the commiter gets changed)
From: Kelvie Wong @ 2007-11-22 16:15 UTC (permalink / raw)
To: git
When using git-svn rebase (I'm not sure if this happens with a regular
rebase as well, I use use git-svn primarily at work), the following
oddity happens:
kelvie@mudd (working) qt $ git-cat-file commit
c27e6207c9078d4225288d55454d6577f0135c16
tree 13d9ef9cc67f5e6381d7697e5794c0ab5f72c729
parent b9eb187d3029c5f9a816cb8f5473d9b239952d53
author kwong <kwong@e2d93294-a71b-0410-9dca-e2ea525a67c9> 1195596864 +0000
committer cscrimgeour
<cscrimgeour@e2d93294-a71b-0410-9dca-e2ea525a67c9> 1195691944 +0000
Qt/FME Extensions: QFMEDialog/QFMEWizard -> Windows only, for now
This is also a reapplication of r39657, which got rolled back.
These have dependencies on QWinWidget (which is a part of the MFC/Qt Migration
Solution), and thus, it does not build without it.
<kw>
kelvie@mudd (working) qt $ git-cat-file commit
7075991c67c6d409ec2315dfeef6f45dd328485b
tree 13d9ef9cc67f5e6381d7697e5794c0ab5f72c729
parent b9eb187d3029c5f9a816cb8f5473d9b239952d53
author kwong <kwong@e2d93294-a71b-0410-9dca-e2ea525a67c9> 1195596864 +0000
committer Kelvie Wong <Kelvie.Wong@safe.com> 1195747291 +0000
Qt/FME Extensions: QFMEDialog/QFMEWizard -> Windows only, for now
This is also a reapplication of r39657, which got rolled back.
These have dependencies on QWinWidget (which is a part of the MFC/Qt Migration
Solution), and thus, it does not build without it.
<kw>
These are both the exact same commit (the tree, parent, and author are
equivalent).
Sometimes (not always), the committer in a commit changes to be the
committer of the parent (svn) commit. This only happens to the
commits whose parent is the SVN commit. In the above example,
cscrimgeour is a SVN user, who obviously could not have changed my
code; the proper commit is the one at the bottom.
Both of these are the first local commit that I have rebased onto SVN.
--
Kelvie Wong
^ permalink raw reply
* [PATCH 0/5] Colors for git-add--interactive
From: Dan Zwell @ 2007-11-22 10:54 UTC (permalink / raw)
To: Dan Zwell
Cc: Jeff King, Junio C Hamano, Shawn O. Pearce, Wincent Colaiuta,
Git Mailing List, Jonathan del Strother, Johannes Schindelin,
Frank Lichtenheld, Jakub Narebski
In-Reply-To: <20071110180109.34febc3f@paradox.zwell.net>
There are several changes since the last iteration of the
"colors for git-add--interactive" patch set:
- Added parentheses around arguments to all user-defined functions.
- Reading the configuration is done in a more organized, robust, and
cleaner way.
- Fixed bug where color keys could inappropriately match ("colored"
should not match "red", for example).
- Users can now set a particular color key to the empty string, and
this is equivalent to setting it to "normal". (This is the behavior
exhibited by git-diff.)
- Color configuration information is case insensitive.
- Added warnings when color configuration keys contain invalid tokens.
- Refactored a few variables for stylistic reasons.
Issues:
- Does not always properly color the output of git-diff --cc, because
the diff-coloring regular expressions do not match every diff line.
I'm not sure that git-add--interactive normally gets used in the same
situations as git-diff --cc. They don't seem to work well, together,
from the little that I tested (without the color patches applied).
There are a few solutions, but I haven't thought of one that's both
reliable and clean. My impression is that diff --cc is called any time
that HEAD has two parents. Is this correct?
Dan
^ permalink raw reply
* Re: Git in a Nutshell guide
From: jhud7196 @ 2007-11-22 16:37 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200711212232.33791.jnareb@gmail.com>
> Dnia środa 21. listopada 2007 20:45, Jan Hudec napisał:
>> On Wed, Nov 21, 2007 at 00:57:28 +0100, Jakub Narebski wrote:
>
>>> 2. Git has some historical cruft, including the fact that it began as
>>> series of low level tools (plumbing) and became proper SCM
>>> (acquired
>>> proper porcelain) later, what can be even now seen in
>>> documentation...
>
> What I meant here that some of important documentation can be only
> found in plumbing commands man pages.
Yes, that's true. And does indeed make /writing/ the book harder, because
the information is harder to compile. Fortunately it should not make it
so much harder to read.
>>> 3. Explanation of some features (like object model) would be much
>>> easier
>>> with some graphics (diagrams etc.), but chosen documentation
>>> format,
>>> AsciiDoc, doesn't make it easy...
>>
>> I dare to disagree here. Asciidoc supports generating image tags for
>> respective output formats and it really does not look hard. We could
>> have
>> PNGs and if we wanted higher press quality even SVG or EPS and convert
>> them
>> to PNGs for the HTML version (and use EPS for latex output).
>
> The problem is that 1) language used to generate images must be easy
> to understand and readable in text form (so sources are enough to
> understand); 2) one of the main formats is manpage (although that would
> not matter for "Git Guide" / "The Git Book").
Ad 1), I don't think we have to generate the images. For most images
it is easier to just draw them in a vector image editor.
As you say, 2) does not matter for "Git Guide"/"The Git Book". The man
pages will have to do without graphics or with Ascii-art replacements.
> Should we choose PIC? Or perhaps DOT? I can write little MetaPost, but
> I don't think that would be good format for git diagrams, even if it
> can be converted to PDF, SVG and PNG.
I'd use DOT for things that can be done with it (ie. visualizing
histories) and just hand-draw the rest in SVG (prefered) or PNG
(for illustrations).
--
Jan Hudec <bulb@ucw.cz>
^ 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