* Re: [PATCH] (experimental) per-topic shortlog.
From: Junio C Hamano @ 2006-11-29 0:57 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20061128131139.GA10874@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Just for fun, I took a look at what we might see by ordering commits by
> their "amount of blamedness". That is, the count of lines introduced by
> a commit which were not later superseded. The script I used is below:
>
> #!/bin/sh
>
> start=$1; shift
> end=$1; shift
>
> start_sha1=`git-rev-parse $start^{}`
> git-rev-list --parents $start..$end >revs
> echo $start_sha1 >>revs
> for i in `git-diff --raw -r $start $end | cut -f2`; do
> echo blaming $i... >&2
> git-blame -l -S revs $i | cut -d' ' -f1
> done |
> grep -v $start_sha1 |
> sort | uniq -c | sort -rn |
> while read count hash; do
> echo "$count `git-rev-list --max-count=1 --pretty=oneline $hash`"
> done
>
> The top 15 for v1.4.3 to v1.4.4 are:
>
> 1604 6973dcaee76ef7b7bfcabd2f26e76205aae07858 Libify diff-files.
Something is SERIOUSLY wrong.
That commit is not even between v1.4.3 and v1.4.4.
^ permalink raw reply
* Re: git and bzr
From: Joseph Wakeling @ 2006-11-29 2:23 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, bazaar-ng
In-Reply-To: <Pine.LNX.4.64.0611271834090.30076@woody.osdl.org>
Thanks to everyone for your very detailed responses. :-)
On the subject of blame and pulling patches from unrelated branches,
Jakub Narebski wrote:
> In git repository can have unrelated branches. So you can fetch unrelated
> repository into your repository, and merge/cherry-pick from there
> if needed.
Sean wrote:
> The Git cherry-pick command lets you grab specific commits from
> other branches in your repo. But cherry-pick works at the commit
> level, there is no easy way to grab a single function for instance
> and merge just its history into another branch.
Linus Torvalds wrote:
> pickaxe wasn't in the released version back when the discussions were
> raging, but it's there now. Except it's really called "git blame" these
> days (and "git annotate") since it's taken over both of those duties.
>
> However...
>
>> A frustration with bzr is that pulling or
>> merging patches from another branch or repo requires them to share the
>> same HEAD. Is this a requirement in git or can I say, "Hey, I like that
>> particular function in project XXX, I'm going to pull that individual
>> bit of code and its development history into project YYY"?
>
> ... it's not _quite_ that smart. It will only look for sources to new
> functions from existing sources in the tree that preceded the commit that
> added the function, so it will _not_ see it coming from another branch or
> another project entirely.
>
> So when you ask for code annotations (use the "-C" flag to see code moved
> across from other files), it will still limit itself to just a particular
> input set, and not go gallivating over all possible branches and projects
> you might have in your repository.
So ... if I understand correctly, I can get patches from somewhere else,
but in the branch history, I will not be able to tell the difference
from having simply newly created them?
With regards to git blame/pickaxe/annotate, the idea of tracking *code*
rather than files was one thing that really excited me when I read about
it in the earlier discussion, and is probably the main reason I'm trying
out git. I'd like to understand this properly so is there a simple
exercise I can do to demonstrate its capabilities? I tried an
experiment where I created one file with two lines, then cut one of the
lines, pasted it into a new file, and committed both changes at the same
time. But git blame -C on the second file just gives me the
time/date/sha1 of its creation, and no indication that the line was
taken from elsewhere.
Back to the more basic queries ... one more difference I've observed
from bzr, after playing around for a while, involves the commands to
undo changes and commits. It looks like git reset combines the
capabilities of both bzr uncommit and bzr revert: I can undo changes
since the last commit by resetting to HEAD, and I can undo commits by
resetting to HEAD^ or earlier.
Some things here I'm not quite sure about:
(1) the difference between git reset --soft and git reset --mixed,
probably because I don't understand the way the index works, the
difference between changed, updated and committed.
(2) How to remove changes made to an individual file since the last commit.
Last, could someone explain the git merge command? git pull seems to do
many things which I would need to use bzr merge for---I can "pull"
between branches which have diverged, for example. I don't understand
quite what git merge does that's different, and when to use one or the
other.
Many thanks again to everyone,
^ permalink raw reply
* [PATCH 1/3] git-svn: color support for the log command
From: Eric Wong @ 2006-11-29 2:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Eric Wong
* match LESS environment settings to those in pager.c
* parse diff.color and pager.color settings in the
config file, and pass --color to git-log
* --color and --pager= settings are supported
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-svn.perl | 67 ++++++++++++++++++++++++++++++++++++++++-----------------
1 files changed, 47 insertions(+), 20 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index c3ad5ec..d8d8716 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -60,6 +60,7 @@ nag_lib() unless $_use_lib;
my $_optimize_commits = 1 unless $ENV{GIT_SVN_NO_OPTIMIZE_COMMITS};
my $sha1 = qr/[a-f\d]{40}/;
my $sha1_short = qr/[a-f\d]{4,40}/;
+my $_esc_color = qr/(?:\033\[(?:(?:\d+;)*\d*)?m)*/;
my ($_revision,$_stdin,$_no_ignore_ext,$_no_stop_copy,$_help,$_rmdir,$_edit,
$_find_copies_harder, $_l, $_cp_similarity, $_cp_remote,
$_repack, $_repack_nr, $_repack_flags, $_q,
@@ -68,7 +69,8 @@ my ($_revision,$_stdin,$_no_ignore_ext,$
$_limit, $_verbose, $_incremental, $_oneline, $_l_fmt, $_show_commit,
$_version, $_upgrade, $_authors, $_branch_all_refs, @_opt_m,
$_merge, $_strategy, $_dry_run, $_ignore_nodate, $_non_recursive,
- $_username, $_config_dir, $_no_auth_cache, $_xfer_delta);
+ $_username, $_config_dir, $_no_auth_cache, $_xfer_delta,
+ $_pager, $_color);
my (@_branch_from, %tree_map, %users, %rusers, %equiv);
my ($_svn_co_url_revs, $_svn_pg_peg_revs);
my @repo_path_split_cache;
@@ -135,6 +137,8 @@ my %cmd = (
'show-commit' => \$_show_commit,
'non-recursive' => \$_non_recursive,
'authors-file|A=s' => \$_authors,
+ 'color' => \$_color,
+ 'pager=s' => \$_pager,
} ],
'commit-diff' => [ \&commit_diff, 'Commit a diff between two trees',
{ 'message|m=s' => \$_message,
@@ -759,16 +763,17 @@ sub show_log {
}
}
+ config_pager();
my $pid = open(my $log,'-|');
defined $pid or croak $!;
if (!$pid) {
exec(git_svn_log_cmd($r_min,$r_max), @args) or croak $!;
}
- setup_pager();
+ run_pager();
my (@k, $c, $d);
while (<$log>) {
- if (/^commit ($sha1_short)/o) {
+ if (/^${_esc_color}commit ($sha1_short)/o) {
my $cmt = $1;
if ($c && cmt_showable($c) && $c->{r} != $r_last) {
$r_last = $c->{r};
@@ -777,25 +782,25 @@ sub show_log {
}
$d = undef;
$c = { c => $cmt };
- } elsif (/^author (.+) (\d+) ([\-\+]?\d+)$/) {
+ } elsif (/^${_esc_color}author (.+) (\d+) ([\-\+]?\d+)$/) {
get_author_info($c, $1, $2, $3);
- } elsif (/^(?:tree|parent|committer) /) {
+ } elsif (/^${_esc_color}(?:tree|parent|committer) /) {
# ignore
- } elsif (/^:\d{6} \d{6} $sha1_short/o) {
+ } elsif (/^${_esc_color}:\d{6} \d{6} $sha1_short/o) {
push @{$c->{raw}}, $_;
- } elsif (/^[ACRMDT]\t/) {
+ } elsif (/^${_esc_color}[ACRMDT]\t/) {
# we could add $SVN->{svn_path} here, but that requires
# remote access at the moment (repo_path_split)...
- s#^([ACRMDT])\t# $1 #;
+ s#^(${_esc_color})([ACRMDT])\t#$1 $2 #;
push @{$c->{changed}}, $_;
- } elsif (/^diff /) {
+ } elsif (/^${_esc_color}diff /) {
$d = 1;
push @{$c->{diff}}, $_;
} elsif ($d) {
push @{$c->{diff}}, $_;
- } elsif (/^ (git-svn-id:.+)$/) {
+ } elsif (/^${_esc_color} (git-svn-id:.+)$/) {
($c->{url}, $c->{r}, undef) = extract_metadata($1);
- } elsif (s/^ //) {
+ } elsif (s/^${_esc_color} //) {
push @{$c->{l}}, $_;
}
}
@@ -901,12 +906,30 @@ sub cmt_showable {
return defined $c->{r};
}
+sub log_use_color {
+ return 1 if $_color;
+ my $dc;
+ chomp($dc = `git-repo-config --get diff.color`);
+ if ($dc eq 'auto') {
+ if (-t *STDOUT || (defined $_pager &&
+ `git-repo-config --bool --get pager.color` !~ /^false/)) {
+ return ($ENV{TERM} && $ENV{TERM} ne 'dumb');
+ }
+ return 0;
+ }
+ return 0 if $dc eq 'never';
+ return 1 if $dc eq 'always';
+ chomp($dc = `git-repo-config --bool --get diff.color`);
+ $dc eq 'true';
+}
+
sub git_svn_log_cmd {
my ($r_min, $r_max) = @_;
my @cmd = (qw/git-log --abbrev-commit --pretty=raw
--default/, "refs/remotes/$GIT_SVN");
push @cmd, '-r' unless $_non_recursive;
push @cmd, qw/--raw --name-status/ if $_verbose;
+ push @cmd, '--color' if log_use_color();
return @cmd unless defined $r_max;
if ($r_max == $r_min) {
push @cmd, '--max-count=1';
@@ -2533,14 +2556,18 @@ sub tz_to_s_offset {
return ($1 * 60) + ($tz * 3600);
}
-sub setup_pager { # translated to Perl from pager.c
- return unless (-t *STDOUT);
- my $pager = $ENV{PAGER};
- if (!defined $pager) {
- $pager = 'less';
- } elsif (length $pager == 0 || $pager eq 'cat') {
- return;
+# adapted from pager.c
+sub config_pager {
+ $_pager ||= $ENV{GIT_PAGER} || $ENV{PAGER};
+ if (!defined $_pager) {
+ $_pager = 'less';
+ } elsif (length $_pager == 0 || $_pager eq 'cat') {
+ $_pager = undef;
}
+}
+
+sub run_pager {
+ return unless -t *STDOUT;
pipe my $rfd, my $wfd or return;
defined(my $pid = fork) or croak $!;
if (!$pid) {
@@ -2548,8 +2575,8 @@ sub setup_pager { # translated to Perl f
return;
}
open STDIN, '<&', $rfd or croak $!;
- $ENV{LESS} ||= '-S';
- exec $pager or croak "Can't run pager: $!\n";;
+ $ENV{LESS} ||= 'FRSX';
+ exec $_pager or croak "Can't run pager: $! ($_pager)\n";
}
sub get_author_info {
--
1.4.4.1.g22a08
^ permalink raw reply related
* [PATCH 2/3] git-svn: documentation updates
From: Eric Wong @ 2006-11-29 2:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Eric Wong
In-Reply-To: <1164768702941-git-send-email-normalperson@yhbt.net>
Eliminate 'commit' from some places and plug 'dcommit' more.
Also update the section --id (GIT_SVN_ID) usage since we
have multi-init/multi-fetch now.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
Documentation/git-svn.txt | 40 +++++++++++++++++++---------------------
1 files changed, 19 insertions(+), 21 deletions(-)
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index a764d1f..a45067e 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -49,7 +49,7 @@ latest revision.
Note: You should never attempt to modify the remotes/git-svn
branch outside of git-svn. Instead, create a branch from
-remotes/git-svn and work on that branch. Use the 'commit'
+remotes/git-svn and work on that branch. Use the 'dcommit'
command (see below) to write git commits back to
remotes/git-svn.
@@ -274,7 +274,7 @@ ADVANCED OPTIONS
-b<refname>::
--branch <refname>::
-Used with 'fetch' or 'commit'.
+Used with 'fetch', 'dcommit' or 'commit'.
This can be used to join arbitrary git branches to remotes/git-svn
on new commits where the tree object is equivalent.
@@ -368,7 +368,7 @@ SVN was very wrong.
Basic Examples
~~~~~~~~~~~~~~
-Tracking and contributing to an Subversion managed-project:
+Tracking and contributing to a Subversion-managed project:
------------------------------------------------------------------------
# Initialize a repo (like git init-db):
@@ -377,10 +377,9 @@ Tracking and contributing to an Subversi
git-svn fetch
# Create your own branch to hack on:
git checkout -b my-branch remotes/git-svn
-# Commit only the git commits you want to SVN:
- git-svn commit <tree-ish> [<tree-ish_2> ...]
-# Commit all the git commits from my-branch that don't exist in SVN:
- git-svn commit remotes/git-svn..my-branch
+# Do some work, and then commit your new changes to SVN, as well as
+# automatically updating your working HEAD:
+ git-svn dcommit
# Something is committed to SVN, rebase the latest into your branch:
git-svn fetch && git rebase remotes/git-svn
# Append svn:ignore settings to the default git exclude file:
@@ -404,26 +403,24 @@ which can lead to merge commits reversin
DESIGN PHILOSOPHY
-----------------
Merge tracking in Subversion is lacking and doing branched development
-with Subversion is cumbersome as a result. git-svn completely forgoes
-any automated merge/branch tracking on the Subversion side and leaves it
-entirely up to the user on the git side. It's simply not worth it to do
-a useful translation when the original signal is weak.
+with Subversion is cumbersome as a result. git-svn does not do
+automated merge/branch tracking by default and leaves it entirely up to
+the user on the git side.
[[tracking-multiple-repos]]
TRACKING MULTIPLE REPOSITORIES OR BRANCHES
------------------------------------------
-This is for advanced users, most users should ignore this section.
-
Because git-svn does not care about relationships between different
branches or directories in a Subversion repository, git-svn has a simple
hack to allow it to track an arbitrary number of related _or_ unrelated
-SVN repositories via one git repository. Simply set the GIT_SVN_ID
-environment variable to a name other other than "git-svn" (the default)
-and git-svn will ignore the contents of the $GIT_DIR/svn/git-svn directory
-and instead do all of its work in $GIT_DIR/svn/$GIT_SVN_ID for that
-invocation. The interface branch will be remotes/$GIT_SVN_ID, instead of
-remotes/git-svn. Any remotes/$GIT_SVN_ID branch should never be modified
-by the user outside of git-svn commands.
+SVN repositories via one git repository. Simply use the --id/-i flag or
+set the GIT_SVN_ID environment variable to a name other other than
+"git-svn" (the default) and git-svn will ignore the contents of the
+$GIT_DIR/svn/git-svn directory and instead do all of its work in
+$GIT_DIR/svn/$GIT_SVN_ID for that invocation. The interface branch will
+be remotes/$GIT_SVN_ID, instead of remotes/git-svn. Any
+remotes/$GIT_SVN_ID branch should never be modified by the user outside
+of git-svn commands.
[[fetch-args]]
ADDITIONAL FETCH ARGUMENTS
@@ -486,7 +483,8 @@ If you are not using the SVN::* Perl lib
conflicting changeset to SVN at a bad moment (right before you commit)
causing a conflict and your commit to fail, your svn working tree
($GIT_DIR/git-svn/tree) may be dirtied. The easiest thing to do is
-probably just to rm -rf $GIT_DIR/git-svn/tree and run 'rebuild'.
+probably just to rm -rf $GIT_DIR/git-svn/tree and run 'rebuild'. You
+can avoid this problem entirely by using 'dcommit'.
We ignore all SVN properties except svn:executable. Too difficult to
map them since we rely heavily on git write-tree being _exactly_ the
--
1.4.4.1.g22a08
^ permalink raw reply related
* [PATCH 3/3] git-svn: fix multi-init
From: Eric Wong @ 2006-11-29 2:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Eric Wong
In-Reply-To: <11647687042130-git-send-email-normalperson@yhbt.net>
After the bugfix to connect to repositories where the user has
limited read permissions, multi-init was broken due to our
SVN::Ra connection being limited to working in a subdirectory;
so we now create a new Ra connection for init-ing branches
and another for tags
Along with that fix, allow the user to use the command-line
option flags for multi-init (--revision being the most notable;
but also --no-auth-cache, --config-dir, --username (for passing
to SVN), and --shared/--template for passing to git-init-db
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-svn.perl | 13 +++++++++----
1 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index d8d8716..3891122 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -124,7 +124,12 @@ my %cmd = (
'no-graft-copy' => \$_no_graft_copy } ],
'multi-init' => [ \&multi_init,
'Initialize multiple trees (like git-svnimport)',
- { %multi_opts, %fc_opts } ],
+ { %multi_opts, %init_opts,
+ 'revision|r=i' => \$_revision,
+ 'username=s' => \$_username,
+ 'config-dir=s' => \$_config_dir,
+ 'no-auth-cache' => \$_no_auth_cache,
+ } ],
'multi-fetch' => [ \&multi_fetch,
'Fetch multiple trees (like git-svnimport)',
\%fc_opts ],
@@ -3316,11 +3321,11 @@ sub libsvn_commit_cb {
sub libsvn_ls_fullurl {
my $fullurl = shift;
- $SVN ||= libsvn_connect($fullurl);
+ my $ra = libsvn_connect($fullurl);
my @ret;
my $pool = SVN::Pool->new;
- my ($dirent, undef, undef) = $SVN->get_dir($SVN->{svn_path},
- $SVN->get_latest_revnum, $pool);
+ my $r = defined $_revision ? $_revision : $ra->get_latest_revnum;
+ my ($dirent, undef, undef) = $ra->get_dir('', $r, $pool);
foreach my $d (keys %$dirent) {
if ($dirent->{$d}->kind == $SVN::Node::dir) {
push @ret, "$d/"; # add '/' for compat with cli svn
--
1.4.4.1.g22a08
^ permalink raw reply related
* Re: [PATCH 0/2] Making "git commit" to mean "git commit -a".
From: Junio C Hamano @ 2006-11-29 3:06 UTC (permalink / raw)
To: Carl Worth; +Cc: git
In-Reply-To: <871wnnwi3k.wl%cworth@cworth.org>
Carl Worth <cworth@cworth.org> writes:
>> The problem I have with the new behaviour is that it goes
>> against the mental model when I start doing anything nontrivial
>> (I would not use words as strong as "totally breaks the mental
>> model", but it comes close). I am not sure how well I can
>> express this, but the short of it is that "grokking index" is
>> not about understanding how the index works, but about trusting
>> that git does the right thing to the index and you do not have
>> to worry about it all the time.
>
> Frankly, I do not currently trust git to always do the right thing
> with the index.
This clearly shows that I did not express myself well. You are
correct that there are commands that ignore the index by default
(a notable example "git apply" has been given by both of us),
and you do have to know about what the commands you use do to
the index.
What I meant by "do not have to worry about" is not about the
index operations each command invocation involves. Of course
you need to know (unless you will do a "commit -a" at the end)
that git apply without --index will leave the index out of sync
relative to your working tree, for example.
What you do _not_ have to worry about all the time is the local
changes you do not want to go in your next commit but still want
to keep in your working tree. Although it probably is not
kosher from the purist point of view, it is very convenient to
be able to keep truly local changes (say, my GIT-VERSION-GEN,
everybody's change to Makefile to set "prefix=/usr/local", or
"#define DEBUG 1" in one of the C files you are currently
mucking with) that you have no intention of committing, while
you want to record the changes to the paths you worked on so far
with patch application, merging and edit + update-index in your
next commit. You record the latter in the index using git tools
to build what you want to have in your next commit in the index
in each step (again, each step you may have to be aware what you
are doing). After you update the index, you can forget about
them -- because the index remembers them for you. They are in
the state you tentatively decided is good for the next commit.
You do not have to worry about the local changes you still have
that you do not want to have in the commit because you do not
run update-index on them, and you can trust that git does not
automatically do so either, so they stay local.
>> Once I am done, I can ask "git diff" and expect it to show my
>> local changes I have no intention of committing for now
>> (e.g. GIT-VERSION-GEN in the working tree has v1.4.5-rc1.GIT
>> long before I plan to start the rc1 cycle to constantly remind
>> me what the next version will be, which is a trick I picked up
>> from Linus), and "git diff --cached" would show exactly what I
>> will commit.
>
> I understand the trick, and I'm not proposing anything that would
> preclude it. But I really don't find it a compelling argument for the
> default behavior of git-commit.
The above paragraph is not the important part of my message.
What was much more important is what immediately followed it,
which you did not quote:
And at that point, I trust "git commit" to do the right thing --
the damn thing I just checked with "git diff --cached" _is_ what
will be committed.
Like it or not, git was designed by and for people who use the
index to work in a dirty worktree. The "-a" option to "git
commit" is politely explained as the "--all" option, but its
true pronunciation is "screw the index -- I rightfully haven't
been paying attention to the index (my workflow did not require
me to) because I know all the changes in my worktree are what I
want in the next commit" option.
The "screw the index" attitude is not a wrong thing per-se. It
is perfectly a good habit to always work in a worktree that
exactly matches HEAD after each commit, and the only index
manipulation you would (unfortunately) need to do between your
own two commits are "git add" (for this use pattern, "git rm" is
an unnecessary thing to do -- just saying "rm" is enough). Then
"git diff" (without --cached but perhaps with paths) would serve
as a preview for your next commit because you are going to do
the "screw the index" commit (except that unfortunate "git add"
thing, which we _could_ fix with "intent to add" entries in the
index) and you would be happy with the similarity to CVS.
Once you use "I care about the index" workflow, however, you
will see more areas where git's index shine. For example, "git
diff" starts to take a more useful role. "I care about the
index" attitude means you let the index be the incremental
staging area for your next commit, and when you reach a good
"snapshot" point you update the index with various means
provided by git. "git diff" will show "what could further be
added to the next commit" without talking about what you already
decided are good earlier and updated the index with. As we
already discussed, "git merge" will update the index for cleanly
merged paths to let you concentrate on more interesting cases
(i.e. merge conflicts). To people who care about the index, the
next commit preview is "git diff --cached", not "git diff HEAD".
What git promises to them is not to update-index the local
changes they have without being told and without their knowing.
This is where "git commit" that does "-a" by default goes quite
against the underlying mental model of git. You staged what
should appear in the next commit in the index because you did
not want to worry about the local changes you still want to keep
in your working tree. Doing the "screw the index" commit by
default to these people is slap in the face. You do not want to
get your index suddenly screwed at the final moment of making
the commit, which happened to me when I did "commit --amend"
with the version with those two patches applied.
Don't get me wrong. I know there are cases that it is useful to
always commit with "-a", but that really has to be opt-in. When
I work in my alternate "trivial fixes only" repository, I use
the "screw the index" workflow myself. When I run git apply and
the patch does not apply, I use "git apply --reject" and fix the
mess by hand, and at that point I do not care if that operation
updates the index for the paths involved or not (although I do
check if the patch tries to add new paths -- they need to be
told to git even whey you take the "screw the index" attitude),
and I do not bother running update-index on them either. But
that is possible only because I know I am going to commit the
final result with "screw the index" option.
"grokking the index" is not about knowing how the index could be
used in your workflow. It is about actually using the index to
stage your next commit. Somebody a bit smarter than me once
said that if you deny the index you are denying git. Although I
would not say it that strongly, because "screw the index" is
also a valid workflow to use (arguably part of) git, "screw the
index" at the commit time _has_ _to_ be a conscious act.
^ permalink raw reply
* Re: git and bzr
From: Linus Torvalds @ 2006-11-29 3:51 UTC (permalink / raw)
To: Joseph Wakeling; +Cc: git, bazaar-ng
In-Reply-To: <456CEF31.8080600@webdrake.net>
On Wed, 29 Nov 2006, Joseph Wakeling wrote:
>
> So ... if I understand correctly, I can get patches from somewhere else,
> but in the branch history, I will not be able to tell the difference
> from having simply newly created them?
Think of it this way: if the _patch_ looks like it's a code movement, then
"git blame" will show it as a code movement. Ie, if the patch (to a human)
looks like it's moving a function from one file into another (which in a
patch will obviously be a question of removing it from one file, and
adding it to another), then git will also see it that way, and then "git
blame" will also follow its history as it moved.
But if somebody sends you a patch that just adds a new function that
didn't exist in that context at all, then "git blame" won't ever realize
that that new function was taken from another branch entirely.
> With regards to git blame/pickaxe/annotate, the idea of tracking *code*
> rather than files was one thing that really excited me when I read about
> it in the earlier discussion, and is probably the main reason I'm trying
> out git. I'd like to understand this properly so is there a simple
> exercise I can do to demonstrate its capabilities? I tried an
> experiment where I created one file with two lines, then cut one of the
> lines, pasted it into a new file, and committed both changes at the same
> time. But git blame -C on the second file just gives me the
> time/date/sha1 of its creation, and no indication that the line was
> taken from elsewhere.
Actually, I think you found a bug.
Now, with small changes, "git blame -C" will just ignore copies entirely,
so your particular test might not have even been supposed to work, but
trying with a new git repo with two bigger files checked in at the initial
commit, I'm actually not seeing "git blame -C" do the right thing even for
real code movement.
And the problem seems to go to the "root commit": if the file existed in
the root, the logic in "git blame" to diff against the (nonexistent)
parent of the root commit won't do the right thing, and that just confuses
git blame entirely.
I think Junio screwed up at some point. I'll send him a bug-report once
I've triaged this a bit more, but I can recreate your breakage if I start
a new git database and create two files in the root, and move data between
them in the second commit (but if I instead create the second file in the
second commit, and do the movement in the third commit, git blame -C works
again ;).
> Back to the more basic queries ... one more difference I've observed
> from bzr, after playing around for a while, involves the commands to
> undo changes and commits. It looks like git reset combines the
> capabilities of both bzr uncommit and bzr revert: I can undo changes
> since the last commit by resetting to HEAD, and I can undo commits by
> resetting to HEAD^ or earlier.
I'm not quite sure what "bzr revert" does. Git does have a "revert" too,
but it will append a _new_ commit that actually undoes the commit you're
asking to revert. If you want to just "undo history" (whether it's one
commit or many - I don't see why it would be different) then yes, "git
reset" is the thing to use.
I _suspect_ that bzr people use "uncommit" to undo a commit in order to
fix it up. In git, you could do that with "git reset" and a new commit,
but the normal thing to do is just to fix it up, and then do
git commit --amend
instead (which amends the last commit to include whatever fixups you did).
> Some things here I'm not quite sure about:
> (1) the difference between git reset --soft and git reset --mixed,
> probably because I don't understand the way the index works, the
> difference between changed, updated and committed.
You'd generally not want to use "--soft" unless you know what the index
really is. Once you do know about all the index issues, you'll know why
it's different from "--mixed", but in general, no normal person would ever
use _either_ --soft (because not changing the index is too confusing if
you don't know about it) or --mixed (because it's the default).
So in reality, you should use
git reset
to reset everything but the actual working tree (and it will talk about
the files that no longer match the state you are resetting _to_, if any
such files exist), or
git reset --hard
to reset everything.
Any other usage is strictly for hardcore people only, and if you don't
know you want to use it, you shouldn't even consider it.
In fact, I'm pretty hardcore, and I don't think I've ever really used
"--soft". It's largely been replaced by "git commit --amend", because
amending a commit used to be the only reason to use "--soft", really.
So it might even be worthwhile just dropping "--soft" and "--mixed"
altogether, but in the meantime, you might as well just ignore them.
> (2) How to remove changes made to an individual file since the last commit.
"git checkout file"
> Last, could someone explain the git merge command?
I argued that we should never teach people to use it at all (because "git
pull" really does everything it can do), but people on the git list said
people are used to merging, so it exists, and these days the syntax is
more usable than it used to be.
> git pull seems to do many things which I would need to use bzr merge
> for---I can "pull" between branches which have diverged, for example.
> I don't understand quite what git merge does that's different, and when
> to use one or the other.
Heh. I'm with you. I'm in the "don't use 'git merge' at all" camp, but it
was argued that people coming from non-git backgrounds would find it
too confusing to just use "git pull" for merging ;)
^ permalink raw reply
* [PATCH 1/2] Set HOME to the test directory to avoid reading ~/.stgitrc
From: Pavel Roskin @ 2006-11-29 3:59 UTC (permalink / raw)
To: git, Catalin Marinas
This makes the tests more system independent and allows better testing
for "stg mail" command.
Signed-off-by: Pavel Roskin <proski@gnu.org>
---
t/test-lib.sh | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 6339c54..459d5cb 100755
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -193,7 +193,8 @@ test_done () {
# Test the binaries we have just built. The tests are kept in
# t/ subdirectory and are run in trash subdirectory.
PATH=$(pwd)/..:$PATH
-export PATH
+HOME=$(pwd)/trash
+export PATH HOME
# Test repository
^ permalink raw reply related
* [PATCH 2/2] Don't require config file for "stg mail"
From: Pavel Roskin @ 2006-11-29 3:59 UTC (permalink / raw)
To: git, Catalin Marinas
In-Reply-To: <20061129035925.6118.78329.stgit@dv.roinet.com>
When calculating the string to be used in the From: field, don't require
it to come from the configuration file. Instead, reuse already known
authname and authemail values as the default. They can be taken from
the GIT_AUTHOR_NAME and GIT_AUTHOR_EMAIL environment variables.
Signed-off-by: Pavel Roskin <proski@gnu.org>
---
stgit/commands/mail.py | 15 +++++----------
1 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/stgit/commands/mail.py b/stgit/commands/mail.py
index 176d7a2..70b091f 100644
--- a/stgit/commands/mail.py
+++ b/stgit/commands/mail.py
@@ -122,18 +122,13 @@ options = [make_option('-a', '--all',
action = 'store_true')]
-def __get_sender():
- """Return the 'authname <authemail>' string as read from the
- configuration file
+def __get_sender(authname, authemail):
+ """Return the string to be used in the From: field
"""
if config.has_option('stgit', 'sender'):
return config.get('stgit', 'sender')
- elif config.has_option('stgit', 'authname') \
- and config.has_option('stgit', 'authemail'):
- return '%s <%s>' % (config.get('stgit', 'authname'),
- config.get('stgit', 'authemail'))
else:
- raise CmdException, 'unknown sender details'
+ return '%s <%s>' % (authname, authemail)
def __parse_addresses(addresses):
"""Return a two elements tuple: (from, [to])
@@ -298,7 +293,7 @@ def __edit_message(msg):
def __build_cover(tmpl, total_nr, msg_id, options):
"""Build the cover message (series description) to be sent via SMTP
"""
- sender = __get_sender()
+ sender = __get_sender(authname, authemail)
if options.version:
version_str = ' %s' % options.version
@@ -372,7 +367,7 @@ def __build_message(tmpl, patch, patch_nr, total_nr, msg_id, ref_id, options):
commname = p.get_commname();
commemail = p.get_commemail();
- sender = __get_sender()
+ sender = __get_sender(authname, authemail)
fromauth = '%s <%s>' % (authname, authemail)
if fromauth != sender:
^ permalink raw reply related
* Bug in "git blame -C"
From: Linus Torvalds @ 2006-11-29 4:27 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
Ok, this is interesting.
Try this sequence (which is a good sequence for showign how something like
"git blame -C" _should_ work, but only ends up showing that it doesn't at
all, because of some bug ;^):
#
# create 'testing' repository
#
mkdir testing
cd testing/
git init-db
#
# copy git.c and sha1_file.c there and commit initial
# (Just to get _some_ initial state)
#
cp ~/git/git.c .
cp ~/git/sha1_file.c .
git add git.c sha1_file.c
git commit -m Initial
#
# move the prepend_to_path() function from git.c to
# sha1_file.c (I did it to just after the
# #ifndef O_NOATIME
# block of preprocessor stuff
#
em git.c sha1_file.c
git commit -a -m Movement
git log -p
and the result of that "git log -p" should show something like
commit a583b5aee68b89b7d554b8f900a95057e8ed61d9
Author: Linus Torvalds <torvalds@woody.osdl.org>
Date: Tue Nov 28 20:13:00 2006 -0800
Movement
diff --git a/git.c b/git.c
index 357330e..43c01fd 100644
--- a/git.c
+++ b/git.c
@@ -18,28 +18,6 @@
const char git_usage_string[] =
"git [--version] [--exec-path[=GIT_EXEC_PATH]] [-p|--paginate] [--bare] [--git-dir=GIT_DIR] [--help] COMMAND [AR
-static void prepend_to_path(const char *dir, int len)
-{
- const char *old_path = getenv("PATH");
- char *path;
- int path_len = len;
...
diff --git a/sha1_file.c b/sha1_file.c
index 63f416b..20168aa 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -22,6 +22,28 @@
#endif
#endif
+static void prepend_to_path(const char *dir, int len)
+{
+ const char *old_path = getenv("PATH");
+ char *path;
+ int path_len = len;
+
...
to show how that top commit moved the function. Ok, everything looks fine
so far.
For the surreal behaviour, now do
git blame -C sha1_file.c
and watch the result make no sense what-so-ever. It doesn't show the
movement at all. It shows that everything in that file came from the
original commit, even though the file obviously did change since.
Which is kind of "true", but it's still _wrong_. Yes, all the data comes
from the same (initial) commit, but it doesn't come from the same _files_
in the same commit, so the fact that we don't see the filenames and
original lines in those filenames is _broken_. The commit information is
right, but it's decided not to show all the _other_ information that is
crucial..
So this shows two problems:
- the line numbers that "git blame -C" shows are the current line numbers
only, not the line numbers it came from in the version it shows. That
makes them useless. We _know_ the current linenumbers. What we want to
know is what they were in the commit that they came from.
So right now, the line number information that "git blame -C" shows is
just the same thing we could have gotten by doing a "cat -n file".
- "git blame -C" has apparently decided that it doesn't need to show
filenames that things came from, because they all came from the same
commit, but that's not a logical thing to compare. "same commit" does
not mean "same filename", so not showing the filename makes no sense.
I tried to bisect this a bit, but I don't think pickaxe has ever gotten
this right, so I couldn't find a place where it was correct to start
bisecting at ;)
^ permalink raw reply
* Re: [PATCH 0/2] Making "git commit" to mean "git commit -a".
From: Nicolas Pitre @ 2006-11-29 4:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Carl Worth, git
In-Reply-To: <7virgzuf38.fsf@assigned-by-dhcp.cox.net>
On Tue, 28 Nov 2006, Junio C Hamano wrote:
> What you do _not_ have to worry about all the time is the local
> changes you do not want to go in your next commit but still want
> to keep in your working tree.
This argument has its converse. What you should _not_ have to worry
about all the time is whether your index really includes all the changes
you want included in your next commit.
And whether wanting to leave local changes in the working directory
without commiting them actually happen more often than wanting to commit
every changes is arguable.
What should be pretty consensual though, is the fact that having
experienced GIT users add an alias for "commit" actually becoming "comit
-i" to preserve the current behavior is much easier than asking new GIT
users do the same but with "commit -a".
So in that context I think having commit without arguments meaning
commit -a is a pretty sensible default. And I don't think it has any
influence on the "learning about the index" issue.
^ permalink raw reply
* Re: Bug in "git blame -C"
From: Junio C Hamano @ 2006-11-29 5:48 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0611282013430.3395@woody.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> So this shows two problems:
>
> - the line numbers that "git blame -C" shows are the current line numbers
> only, not the line numbers it came from in the version it shows. That
> makes them useless. We _know_ the current linenumbers. What we want to
> know is what they were in the commit that they came from.
>
> So right now, the line number information that "git blame -C" shows is
> just the same thing we could have gotten by doing a "cat -n file".
Please use -f -n, which gives the origin filename and origin linenumber.
f9c03ba7 sha1_file.c 22 (Junio 2006-11-28 21:10:50 -0800 22) #endif
f9c03ba7 sha1_file.c 23 (Junio 2006-11-28 21:10:50 -0800 23) #endif
f9c03ba7 sha1_file.c 24 (Junio 2006-11-28 21:10:50 -0800 24)
f9c03ba7 git.c 21 (Junio 2006-11-28 21:10:50 -0800 25) static v..
f9c03ba7 git.c 22 (Junio 2006-11-28 21:10:50 -0800 26) {
f9c03ba7 git.c 23 (Junio 2006-11-28 21:10:50 -0800 27) co..
f9c03ba7 git.c 24 (Junio 2006-11-28 21:10:50 -0800 28) ch..
f9c03ba7 git.c 25 (Junio 2006-11-28 21:10:50 -0800 29) in..
> - "git blame -C" has apparently decided that it doesn't need to show
> filenames that things came from, because they all came from the same
> commit, but that's not a logical thing to compare. "same commit" does
> not mean "same filename", so not showing the filename makes no sense.
This is definitely a bug, and I am sorry to have sent you to a
wild goose chase (a root commit corner case that did not exist).
I am not sure how often you would want the origin line-number,
and I think it is debatable if we should turn show-number on in
this case, but we should definitely turn show-name on when two
paths are involved; that's what -C is about.
For that matter, I do not think the line number in the final
revision is interesting at all; they are there for hysterical
raisins only (I know pickaxe imitated blame which inherited it
from annotate).
Something like this?
diff --git a/builtin-blame.c b/builtin-blame.c
index 066dee7..eee0b90 100644
--- a/builtin-blame.c
+++ b/builtin-blame.c
@@ -1344,29 +1344,30 @@ static void output(struct scoreboard *sb, int option)
{
struct blame_entry *ent;
- if (option & OUTPUT_PORCELAIN) {
- for (ent = sb->ent; ent; ent = ent->next) {
- struct blame_entry *oth;
- struct origin *suspect = ent->suspect;
- struct commit *commit = suspect->commit;
- if (commit->object.flags & MORE_THAN_ONE_PATH)
+ for (ent = sb->ent; ent; ent = ent->next) {
+ struct blame_entry *oth;
+ struct origin *suspect = ent->suspect;
+ struct commit *commit = suspect->commit;
+
+ if (strcmp(suspect->path, sb->path) &&
+ !(option & OUTPUT_PORCELAIN))
+ option |= OUTPUT_SHOW_NAME | OUTPUT_SHOW_NUMBER;
+ if (commit->object.flags & MORE_THAN_ONE_PATH)
+ continue;
+ for (oth = ent->next; oth; oth = oth->next) {
+ if ((oth->suspect->commit != commit) ||
+ !strcmp(oth->suspect->path, suspect->path))
continue;
- for (oth = ent->next; oth; oth = oth->next) {
- if ((oth->suspect->commit != commit) ||
- !strcmp(oth->suspect->path, suspect->path))
- continue;
- commit->object.flags |= MORE_THAN_ONE_PATH;
- break;
- }
+ commit->object.flags |= MORE_THAN_ONE_PATH;
+ break;
}
}
for (ent = sb->ent; ent; ent = ent->next) {
if (option & OUTPUT_PORCELAIN)
emit_porcelain(sb, ent);
- else {
+ else
emit_other(sb, ent, option);
- }
}
}
@@ -1438,8 +1439,6 @@ static void find_alignment(struct scoreboard *sb, int *option)
if (!(suspect->commit->object.flags & METAINFO_SHOWN)) {
suspect->commit->object.flags |= METAINFO_SHOWN;
get_commit_info(suspect->commit, &ci, 1);
- if (strcmp(suspect->path, sb->path))
- *option |= OUTPUT_SHOW_NAME;
num = strlen(suspect->path);
if (longest_file < num)
longest_file = num;
^ permalink raw reply related
* Re: Bug in "git blame -C"
From: Junio C Hamano @ 2006-11-29 6:21 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <7vu00iu7lb.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Linus Torvalds <torvalds@osdl.org> writes:
>
>> - "git blame -C" has apparently decided that it doesn't need to show
>> filenames that things came from, because they all came from the same
>> commit, but that's not a logical thing to compare. "same commit" does
>> not mean "same filename", so not showing the filename makes no sense.
>
> This is definitely a bug,
A replacement patch that should be much cleaner and to the
point.
---
diff --git a/builtin-blame.c b/builtin-blame.c
index 066dee7..4090a80 100644
--- a/builtin-blame.c
+++ b/builtin-blame.c
@@ -1435,11 +1435,12 @@ static void find_alignment(struct scoreboard *sb, int *option)
struct commit_info ci;
int num;
+ if (strcmp(suspect->path, sb->path))
+ *option |= OUTPUT_SHOW_NAME | OUTPUT_SHOW_NUMBER;
+
if (!(suspect->commit->object.flags & METAINFO_SHOWN)) {
suspect->commit->object.flags |= METAINFO_SHOWN;
get_commit_info(suspect->commit, &ci, 1);
- if (strcmp(suspect->path, sb->path))
- *option |= OUTPUT_SHOW_NAME;
num = strlen(suspect->path);
if (longest_file < num)
longest_file = num;
^ permalink raw reply related
* [PATCH (take 3)] git blame -C: fix output format tweaks when crossing file boundary.
From: Junio C Hamano @ 2006-11-29 6:32 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <7vmz6au626.fsf@assigned-by-dhcp.cox.net>
We used to get the case that more than two paths came from the
same commit wrong when computing the output width and deciding
to turn on --show-name option automatically. When we find that
lines that came from a path that is different from what we
started digging from, we should always turn --show-name on, and
we should count the name length for all files involved.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* BLUSH. Both of the previous ones were botched.
Third time lucky, hopefully.
builtin-blame.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/builtin-blame.c b/builtin-blame.c
index 066dee7..53fed45 100644
--- a/builtin-blame.c
+++ b/builtin-blame.c
@@ -1435,14 +1435,14 @@ static void find_alignment(struct scoreboard *sb, int *option)
struct commit_info ci;
int num;
+ if (strcmp(suspect->path, sb->path))
+ *option |= OUTPUT_SHOW_NAME;
+ num = strlen(suspect->path);
+ if (longest_file < num)
+ longest_file = num;
if (!(suspect->commit->object.flags & METAINFO_SHOWN)) {
suspect->commit->object.flags |= METAINFO_SHOWN;
get_commit_info(suspect->commit, &ci, 1);
- if (strcmp(suspect->path, sb->path))
- *option |= OUTPUT_SHOW_NAME;
- num = strlen(suspect->path);
- if (longest_file < num)
- longest_file = num;
num = strlen(ci.author);
if (longest_author < num)
longest_author = num;
--
1.4.4.1.gad0c3-dirty
^ permalink raw reply related
* Re: Hyphens and hiding core commands
From: Michael S. Tsirkin @ 2006-11-29 7:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Theodore Tso, Carl Worth, git
In-Reply-To: <7vu00k3pao.fsf@assigned-by-dhcp.cox.net>
> +------------------------------------------------
> +$ cat >~/.gitconfig
> +[user]
> + name = Your Name Comes Here
> + email = you@yourdomain.example.com
> +^D
> +------------------------------------------------
I used to use the ^D convention when explaining git
to beginners and I noticed some people try to cut-and-paste it.
So the following might be a better way to put it:
+$ cat <<EOF >~/.gitconfig
+[user]
+ name = Your Name Comes Here
+ email = you@yourdomain.example.com
+EOF
--
^ permalink raw reply
* Re: [PATCH 2/3] git-svn: documentation updates
From: Steven Grimm @ 2006-11-29 7:29 UTC (permalink / raw)
To: Eric Wong; +Cc: Junio C Hamano, git
In-Reply-To: <11647687042130-git-send-email-normalperson@yhbt.net>
Eric Wong wrote:
> Eliminate 'commit' from some places and plug 'dcommit' more.
> Also update the section --id (GIT_SVN_ID) usage since we
> have multi-init/multi-fetch now.
>
In the spirit of the "should the -a option be the default in
git-commit?" discussion... What are the chances that a future version of
git-svn could change the "dcommit" command to "commit" and the current
"commit" to something else? I know it's a historical artifact, but given
that git-svn is (by definition) aimed at Subversion users who are
probably used to running "svn commit", it seems like making "git-svn
commit" be the thing you usually want to run would be a good thing. One
less habit to unlearn.
^ permalink raw reply
* Re: [PATCH 0/2] Making "git commit" to mean "git commit -a".
From: Junio C Hamano @ 2006-11-29 7:44 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Carl Worth, git
In-Reply-To: <Pine.LNX.4.64.0611282322320.9647@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> This argument has its converse. What you should _not_ have to worry
> about all the time is whether your index really includes all the changes
> you want included in your next commit.
That's what we have "git diff" with various output options for;
I often do "git diff --stat" or "git diff --name-status" when I
know I am about to commit in a dirty working tree. I suspect
that I am not getting your point.
> And whether wanting to leave local changes in the working directory
> without commiting them actually happen more often than wanting to commit
> every changes is arguable.
I do not think anybody is talking about which happens more
often. "screw the index" people do not have to worry about the
index during the course of their changes in the working tree
toward the next commit, and the only time they need to tell git
(which _IS_ a system based on the index, dammit) about what they
want to do with the index is at the commit time, and they tell
git to "screw the index" by passing "-a" to "git commit". In
other words, "-a" at commit time is a magic incantation to allow
them to be casual about index manipulation before reaching the
point to commit. They do not have to worry about differences
between "git rm --force" vs "/bin/rm" nor "git apply" vs "git
apply --index").
It might make sense to have a configuration in .git/config that
says "user.workingtreeistheking = true". This should obviously
affect what "git commit" does by default, but it also should
change the behaviour of other commands to suit the "screw the
index" workflow better.
For example, the configuration should probably make "git diff"
(without an explicit --cached nor HEAD) pretend it was asked to
show diff between HEAD and the working tree, because the user
chose not to care about the index. Not caring about the index
is different from consciously keeping the index clean; for
example, running "git apply --index" by mistake when he meant to
say "git apply" should be tolerated, and Porcelain-ish that is
working under workingtreeistheking mode should behave as if the
index does not exist. In other words, the index is _not_ a
staging area towards the next commit for him; the working tree
is.
I thought Cogito largely follows that model, so it certainly is
possible to do things that way. And I would not mind if the
changes are cleanly done and maintainable. I am NOT going to
say that I will refuse to maintain the code that implements the
workingtreeistheking half of the system, although it is very
unlikely that I would ever enable that configuration in my
repositories.
Would that make people happy? I do not think so. I think it
will lead to more confusion to have two majorly different
semantics in the same set of tools.
^ permalink raw reply
* Re: git and bzr
From: Junio C Hamano @ 2006-11-29 8:07 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Joseph Wakeling
In-Reply-To: <Pine.LNX.4.64.0611281906520.3395@woody.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> And the problem seems to go to the "root commit": if the file existed in
> the root, the logic in "git blame" to diff against the (nonexistent)
> parent of the root commit won't do the right thing, and that just confuses
> git blame entirely.
>
> I think Junio screwed up at some point. I'll send him a bug-report once
> I've triaged this a bit more, but I can recreate your breakage if I start
> a new git database and create two files in the root, and move data between
> them in the second commit (but if I instead create the second file in the
> second commit, and do the movement in the third commit, git blame -C works
> again ;).
Is it safe to assume that the "automatically turning --show-name
on" fixes this issue and it does not have anything to do with
the root commit? Given the way the "passing the blame"
algorithm works, there should not be anything special about the
root commit --- if some blame remains in a commit:path pair, and
if the commit does not have parents, it takes the blame right
away without needing to run any diff.
> In fact, I'm pretty hardcore, and I don't think I've ever really used
> "--soft". It's largely been replaced by "git commit --amend", because
> amending a commit used to be the only reason to use "--soft", really.
> So it might even be worthwhile just dropping "--soft" and "--mixed"
> altogether, but in the meantime, you might as well just ignore them.
Everything in the above paragraph is correct.
>> git pull seems to do many things which I would need to use bzr merge
>> for---I can "pull" between branches which have diverged, for example.
>> I don't understand quite what git merge does that's different, and when
>> to use one or the other.
>
> Heh. I'm with you. I'm in the "don't use 'git merge' at all" camp, but it
> was argued that people coming from non-git backgrounds would find it
> too confusing to just use "git pull" for merging ;)
Interesting. I had exactly the same response as yours when I
read Joseph's message ;-).
^ permalink raw reply
* [PATCH] Add --bool and --int to the OPTIONS section
From: Andy Parkins @ 2006-11-29 8:25 UTC (permalink / raw)
To: git
In-Reply-To: <7vd5772unw.fsf@assigned-by-dhcp.cox.net>
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
I did look for just such an option, but didn't find it because it wasn't in
the OPTIONS list of the git-repo-config man page. If there is an OPTIONS
section it should include all options, otherwise it's no use as a quick
reference.
Your template commit message is an excellent idea, but I don't like the idea
of simply hard coding sign off line into it; it means that there are then two
locations in the .git tree that I'd have to edit to change my name.
Therefore any template would have to support token expansion so that "S-o-B:
$REPOSITORY_EMAIL" would be possible. Even better would be support
for "$GIT_STATUS_OUTPUT" and "$GIT_DIFF_OUTPUT" so that the commit message is
completely templated.
Documentation/git-repo-config.txt | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-repo-config.txt
b/Documentation/git-repo-config.txt
index 8199615..5bede9a 100644
--- a/Documentation/git-repo-config.txt
+++ b/Documentation/git-repo-config.txt
@@ -77,6 +77,12 @@ OPTIONS
-l, --list::
List all variables set in config file.
+--bool::
+ git-repo-config will ensure that the output is "true" or "false"
+
+--int::
+ git-repo-config will ensure that the output is a simple decimal number
+
ENVIRONMENT
-----------
--
1.4.3.GIT-dirty
^ permalink raw reply related
* Re: [PATCH 2/3] git-svn: documentation updates
From: Eric Wong @ 2006-11-29 8:54 UTC (permalink / raw)
To: Steven Grimm; +Cc: Junio C Hamano, git
In-Reply-To: <456D36CE.1060300@midwinter.com>
Steven Grimm <koreth@midwinter.com> wrote:
> Eric Wong wrote:
> >Eliminate 'commit' from some places and plug 'dcommit' more.
> >Also update the section --id (GIT_SVN_ID) usage since we
> >have multi-init/multi-fetch now.
> >
>
> In the spirit of the "should the -a option be the default in
> git-commit?" discussion... What are the chances that a future version of
> git-svn could change the "dcommit" command to "commit" and the current
> "commit" to something else? I know it's a historical artifact, but given
> that git-svn is (by definition) aimed at Subversion users who are
> probably used to running "svn commit", it seems like making "git-svn
> commit" be the thing you usually want to run would be a good thing. One
> less habit to unlearn.
I've been considering something along those lines. I'm interested in
renaming the current 'commit' command to something else (it still has
its uses), but I haven't figured out what to call it...
Also, something that can wrap (git commit && git svn dcommit) into one
step would be nice.
--
^ permalink raw reply
* Re: [PATCH] Trim hint printed when gecos is empty.
From: Johannes Schindelin @ 2006-11-29 9:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andy Parkins, git
In-Reply-To: <7v3b834e75.fsf@assigned-by-dhcp.cox.net>
Hi,
On Tue, 28 Nov 2006, Junio C Hamano wrote:
> Johannes, Andy's interpretation is in line with the policy in
> SubmittingPatches. S-o-b is about warranty of provenance, and not about
> correctness or cheering (Acked-by).
Fair enough.
Ciao,
^ permalink raw reply
* Re: [BUG] git shortlog: need a range!
From: Johannes Schindelin @ 2006-11-29 9:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8xhv2uj1.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 667 bytes --]
Hi,
On Tue, 28 Nov 2006, Junio C Hamano wrote:
> I just got this:
>
> $ git shortlog --since=Oct.20 --until=Nov.20 master
> fatal: Need a range!
>
> Why isn't this a range?
It really is not. Think about this scenario:
A - B - C
\ /
D
where both B and D were done after Oct.20, but not A. Then you do not have
a range, i.e. you cannot represent the same in the form X..Y.
However, this only shows that my reasoning in shortlog was wrong. It was
meant to prevent accidentally traversing the _whole_ history (which does
take some time), but maybe even this is something people want to do?
Therefore: Ack on René's patch.
Ciao,
Dscho
^ permalink raw reply
* Re: can I remove or move a tag in a remote repository?
From: Johannes Schindelin @ 2006-11-29 9:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jim Meyering, git
In-Reply-To: <7virgz1bz7.fsf@assigned-by-dhcp.cox.net>
Hi,
On Tue, 28 Nov 2006, Junio C Hamano wrote:
> Jim Meyering <jim@meyering.net> writes:
>
> > Here's the problem:
> > When I try to push the new tags, git-push fails:
> >
> > $ git-push -f --tags ssh+git://git.sv.gnu.org/srv/git/coreutils master:refs/heads/master
> > updating 'refs/tags/cvs-head'
> > from 2fd3fd29a8b40be695bc2327c8cd3bd33e521100
> > to db18f53ffb221e9957124d8af81c11a7e350ac3b
> > ...
> > Total 1, written 1 (delta 0), reused 0 (delta 0)
> > Unpacking 1 objects
> > error: denying non-fast forward; you should pull first
> >
> > I get the same error also when using --force.
>
> I think this is due to overeager receive.denyNonFastForwards
> configuration setting at the repository you are pushing into.
>
> I _think_ what receive-pack does in this case is totally wrong.
> It should either:
>
> (1) deny overwriting existing tags -- tags are meant to be
> immutable so it should not allow them to be "updated"
> regardless of fast-forwardness, or
>
> (2) allow overwriting things under refs/tags/ without any
> fast-forward checking. After all, a tag could point at a
> tree or a blob, and there is no fast-forwardness among
> trees.
>
> The client side check in "git fetch" takes the latter viewpoint,
> and I think we should be consistent with it.
>
> Johannes, what do you think? Does the following patch look sane
> to you?
It does if you agree that (2) is correct.
But I don't agree. cvs-head really should be a head IMHO, not a tag,
because cvs-head really tracks a branch.
I also think that git-fetch silently updating tags is wrong. Rather, it
should warn that the tags are different. But I've been wrong before.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Add --bool and --int to the OPTIONS section
From: Johannes Schindelin @ 2006-11-29 10:09 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200611290825.40953.andyparkins@gmail.com>
Hi,
On Wed, 29 Nov 2006, Andy Parkins wrote:
> Signed-off-by: Andy Parkins <andyparkins@gmail.com>
> ---
You might want to use a more-to-the-point subject, and move this into the
commit message:
> I did look for just such an option, but didn't find it because it wasn't
> in the OPTIONS list of the git-repo-config man page. If there is an
> OPTIONS section it should include all options, otherwise it's no use as
> a quick reference.
And this belongs into another mail:
> Your template commit message is an excellent idea, but I don't like the idea
> of simply hard coding sign off line into it; it means that there are then two
> locations in the .git tree that I'd have to edit to change my name.
> [...]
But to answer your concern: you would do this as a hook, which is a script
in which you do not put your name directly. Rather, this script gets the
current author name by calling either git-var or git-repo-config.
Ciao,
Dscho
^ permalink raw reply
* Re: What's in git.git
From: Johannes Schindelin @ 2006-11-29 10:21 UTC (permalink / raw)
To: Carl Worth; +Cc: Junio C Hamano, git
In-Reply-To: <87zmabv0i7.wl%cworth@cworth.org>
Hi,
On Tue, 28 Nov 2006, Carl Worth wrote:
> On Sat, 25 Nov 2006 02:12:38 -0800, Junio C Hamano wrote:
> > * The new "--depth $n" parameter to git clone/fetch tries to
> > limit the commit ancestry depth to $n.
> [...]
> Has though been given to make the depth selection consistent with
> other limiting options for rev-parse and rev-list? For example, I'd
> like to be able to use --since to get a shallow clone, (so should
> --depth instead be --max-count?, and can we re-use some existing
> machinery here?).
I briefly considered that, but decided against it, for two reasons: 1) it
puts the burden of calculation on the server, and 2) I was not at all sure
if the whole shallow stuff would be useful to begin with (and therefore
avoided complicated stuff as much as possible).
> > Petr Baudis (1):
> > Make git-clone --use-separate-remote the default
> ...
> > Junio C Hamano (19):
> > git-merge: make it usable as the first class UI
>
> Also very exciting. Please do keep up the user-interface improvements,
> everybody.
I concur.
Ciao,
Dscho
^ 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