Re: Can `git blame` show the date that each line was merged?
On Tue, Jun 4, 2013 at 11:56 AM, Jeff King p...@peff.net wrote: Aside: in some trial and error I notice this oddity: $ git blame --merges usage: git blame [options] [rev-opts] [rev] [--] file [rev-opts] are documented in git-rev-list(1) ... Your problem is not the presence of --merges here, but that you forgot the necessary file argument. Try git blame --merges foo.c. Oops. Thanks. -- Matt McClure http://matthewlmcclure.com http://www.mapmyfitness.com/profile/matthewlmcclure -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
override merge.ff = false using --ff-only
I naively tried to override merge.ff = false using --ff-only on the command line. I expected that it would override the configured default and perform a fast-forward merge. Instead, it said: $ git config -l | grep -F 'merge.ff' merge.ff=false $ git merge --ff-only foo fatal: You cannot combine --no-ff with --ff-only. On the other hand, I see that --ff works just fine in the same initial state. $ git merge --ff foo Updating b869407..17b5495 Fast-forward ... 4 files changed, 2 insertions(+), 5 deletions(-) Would it be better if --ff-only refused to merge only if the commits themselves prevented fast-forwarding? -- Matt McClure http://matthewlmcclure.com http://www.mapmyfitness.com/profile/matthewlmcclure -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Avoiding broken Gitweb links and deleted objects
On Fri, May 10, 2013 at 12:22 PM, Junio C Hamano gits...@pobox.com wrote: I think what I missed is that the same logic to ignore side branches whose history gets cauterised with such an ours merge may apply to an ours merge that people already make, but the latter may want to take both histories into account. So I guess it is not such a great idea. The particular proposed implementation? Or the broader idea to save loose commits more permanently? I'm still interested in a solution for the latter. -- Matt McClure http://matthewlmcclure.com http://www.mapmyfitness.com/profile/matthewlmcclure -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Avoiding broken Gitweb links and deleted objects
On Fri, May 10, 2013 at 3:34 AM, William Swanson swanson...@gmail.com wrote: I started working on something like this a few weeks ago, but eventually came to the conclusion that this information does not belong in the commit graph itself. A better approach, I think, would be to enhance the reflogs to the point where they can provide this information in a reliable manner. Is there a way to push/pull reflogs among different repositories? In my original scenario: 1. the commits are created on a developer machine 2. pushed to a central origin repository running Gitweb 3. the branch is rebased on the developer machine 4. the branch is push --force'd to the origin Later, git push tells me: warning: There are too many unreachable loose objects; run 'git prune' to remove them. or I want to delete old topic branch HEADs to improve performance. But I never want to let Git delete the underlying commit objects since there could be Gitweb links pointing at them. -- Matt McClure http://matthewlmcclure.com http://www.mapmyfitness.com/profile/matthewlmcclure -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Avoiding broken Gitweb links and deleted objects
On Wed, May 8, 2013 at 12:05 PM, Matt McClure matthewlmccl...@gmail.com wrote: On Wed, May 8, 2013 at 10:41 AM, Johannes Sixt j.s...@viscovery.net wrote: git gc moves unreachable objects that were packed before to the loose object store, from where they can be pruned. Thanks. That was the piece I was missing. I assumed `git gc` did the opposite. That begs a follow-up question. It sounds as though Git will typically delete unreachable objects. My team often shares links like https://git.example.com/foo.git/log/d59051721bb0a3758f7c6ea0452bac122a377645?hp=0055e0959cd13780494fe33832bae9bcf91e4a90 . If I later rebase the branch containing those commits and d590517 becomes unreachable, do I risk that link breaking when Git deletes d590517? What's a good strategy for avoiding breaking those links? -- Matt McClure http://matthewlmcclure.com http://www.mapmyfitness.com/profile/matthewlmcclure -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
`git prune` doc or implementation defect, or user misunderstanding
The `git prune` documentation says: This runs git fsck --unreachable using all the refs available in refs/, optionally with additional set of objects specified on the command line, and prunes all unpacked objects unreachable from any of these head objects from the object database. In addition, it prunes the unpacked objects that are also found in packs by running git prune-packed. Note that unreachable, packed objects will remain. If this is not desired, see git-repack(1). My interpretation of that is that `git prune` will not prune packed objects by default. The following behavior seems inconsistent with that interpretation. [git@438587-beefcake01 panama.git]$ git prune -n | wc -l 9210 [git@438587-beefcake01 panama.git]$ git fsck --unreachable | wc -l 9468 [git@438587-beefcake01 panama.git]$ git gc --no-prune Counting objects: 531223, done. Delta compression using up to 24 threads. Compressing objects: 100% (109848/109848), done. Writing objects: 100% (531223/531223), done. Total 531223 (delta 405288), reused 530894 (delta 404961) [git@438587-beefcake01 panama.git]$ git prune -n | wc -l 9468 [git@438587-beefcake01 panama.git]$ git fsck --unreachable | wc -l 9468 It looks like `git prune -n` is telling me that it would prune the objects that I just packed. What am I misunderstanding? -- Matt McClure http://matthewlmcclure.com http://www.mapmyfitness.com/profile/matthewlmcclure -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Avoiding broken Gitweb links and deleted objects
On Wed, May 8, 2013 at 12:05 PM, Matt McClure matthewlmccl...@gmail.com wrote: On Wed, May 8, 2013 at 10:41 AM, Johannes Sixt j.s...@viscovery.net wrote: git gc moves unreachable objects that were packed before to the loose object store, from where they can be pruned. Thanks. That was the piece I was missing. I assumed `git gc` did the opposite. That begs a follow-up question. It sounds as though Git will typically delete unreachable objects. My team often shares links like https://git.example.com/foo.git/log/d59051721bb0a3758f7c6ea0452bac122a377645?hp=0055e0959cd13780494fe33832bae9bcf91e4a90 . If I later rebase the branch containing those commits and d590517 becomes unreachable, do I risk that link breaking when Git deletes d590517? What's a good strategy for avoiding breaking those links? -- Matt McClure http://matthewlmcclure.com http://www.mapmyfitness.com/profile/matthewlmcclure -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] difftool: don't overwrite modified files
On Mon, Mar 25, 2013 at 5:44 PM, John Keeping j...@keeping.me.uk wrote: Instead of copying unconditionally when the files differ, create and index from the working tree files and only copy the temporary file back if it was modified and the working tree file was not. If both files have been modified, print a warning and exit with an error. When there's a conflict, does difftool save both conflicting files? Or only the working tree copy? I think it should preserve both copies on disk. -- Matt McClure http://www.matthewlmcclure.com http://www.mapmyfitness.com/profile/matthewlmcclure -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
patch series vs. multiple files changed in a commit; storytelling history vs. literal creation history
I've read Documentation/SubmittingPatches, followed some of the discussion on this list, and looked over some of the recent commit history. I'm impressed by the strong culture of review that produces readable patches and commit messages, but I think there are some gaps in my understanding of the prevailing process here. Most of the code I've worked on has been closed source, and the commit histories tend to reflect what I'd call the literal creation history. Reading the Git history, my impression is that it reflects a different storytelling history. In some cases, that might be the same as the creation history, but in general the emphasis is on telling a coherent story of the changes to the other developers rather than communicating all the messy details of how you arrived at the order of that story. Is that right? What are the Git project's rules of thumb for when to create a patch series vs. putting changes to multiple files in a single commit/patch? As a patch series evolves before landing on an upstream branch, do you typically make corrections to the original series in new commits, or update the respective commits from the original series in a new series of analogous commits? -- Matt McClure http://www.matthewlmcclure.com http://www.mapmyfitness.com/profile/matthewlmcclure -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/3] t7800: fix tests when difftool uses --no-symlinks
On Sun, Mar 24, 2013 at 1:19 AM, Junio C Hamano gits...@pobox.com wrote: Admittedly I do not use difftool myself, and I have long assumed that difftool users are using the tools to _view_ the changes, but apparently some of the tools let the user muck with what is shown, and also apparently people seem to like the fact that they can make changes. So I've led to believe the update in difftool, take the change back to working tree, either by making symbolic links or copying them back behaviour was a _feature_. Definitely. Here's how I use it: http://matthewlmcclure.com/s/2013/03/14/use-emacs-dircmp-mode-as-a-git-difftool.html -- Matt McClure http://www.matthewlmcclure.com http://www.mapmyfitness.com/profile/matthewlmcclure -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/3] t7800: fix tests when difftool uses --no-symlinks
On Sun, Mar 24, 2013 at 8:36 AM, John Keeping j...@keeping.me.uk wrote: In the non-symlink case I think a user might find it surprising if the (unmodified) file used by their diff tool were suddenly copied over the working tree wiping out the changes they have just made. That's exactly what I was describing here: http://thread.gmane.org/gmane.comp.version-control.git/217979/focus=218006 -- Matt McClure http://www.matthewlmcclure.com http://www.mapmyfitness.com/profile/matthewlmcclure -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] difftool: Make directory diff symlink working tree
On Wed, Mar 13, 2013 at 4:24 AM, David Aguilar dav...@gmail.com wrote:
This is a nice straightforward approach.
As Junio mentioned, a good next step would be this patch
in combination with making the truly temporary files
created by dir-diff readonly.
Will that need a win32 platform check?
Does anyone want to take this and whip it into a proper patch?
An attempt:
From 429ae282ffd7202b6d2fb024a92dea543b8af376 Mon Sep 17 00:00:00 2001
From: Matt McClure matthewlmccl...@gmail.com
Date: Wed, 13 Mar 2013 11:14:22 -0400
Subject: [PATCH] difftool: Make directory diff symlink working tree
...primarily so that a user can edit working tree files in his difftool.
difftool -d formerly knew how to symlink to the working tree when the
work tree contains uncommitted changes. In practice, prior to this
change, it would not symlink to the working tree in case there were no
uncommitted changes, even when the user invoked difftool with the form:
git difftool -d [--options] commit [--] [path...]
This form is to view the changes you have in your working tree
relative to the named commit. You can use HEAD to compare it
with the latest commit, or a branch name to compare with the tip
of a different branch.
Instead, prior to this change, difftool would use the file's blob SHA1
to find its content in the index rather than use the working tree
content. This change teaches `git difftool` to compare the blob SHA1 to
the file's working tree blob SHA1 and use the working tree file if the
SHA1s are the same.
Author: John Keeping j...@keeping.me.uk
Conversation:
http://thread.gmane.org/gmane.comp.version-control.git/217979/focus=218014
---
git-difftool.perl | 21 ++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/git-difftool.perl b/git-difftool.perl
index 0a90de4..5f093ae 100755
--- a/git-difftool.perl
+++ b/git-difftool.perl
@@ -83,6 +83,21 @@ sub exit_cleanup
exit($status | ($status 8));
}
+sub use_wt_file
+{
+ my ($repo, $workdir, $file, $sha1, $symlinks) = @_;
+ my $null_sha1 = '0' x 40;
+
+ if ($sha1 eq $null_sha1) {
+ return 1;
+ } elsif (not $symlinks) {
+ return 0;
+ }
+
+ my $wt_sha1 = $repo-command_oneline('hash-object', $workdir/$file);
+ return $sha1 eq $wt_sha1;
+}
+
sub setup_dir_diff
{
my ($repo, $workdir, $symlinks) = @_;
@@ -159,10 +174,10 @@ EOF
}
if ($rmode ne $null_mode) {
- if ($rsha1 ne $null_sha1) {
- $rindex .= $rmode $rsha1\t$dst_path\0;
- } else {
+ if (use_wt_file($repo, $workdir, $dst_path, $rsha1,
$symlinks)) {
push(@working_tree, $dst_path);
+ } else {
+ $rindex .= $rmode $rsha1\t$dst_path\0;
}
}
}
--
1.8.1.5
--
Matt McClure
http://www.matthewlmcclure.com
http://www.mapmyfitness.com/profile/matthewlmcclure
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: difftool -d symlinks, under what conditions
On Tue, Nov 27, 2012 at 7:41 AM, Matt McClure matthewlmccl...@gmail.com wrote: On Tuesday, November 27, 2012, David Aguilar wrote: It seems that there is an edge case here that we are not accounting for: unmodified worktree paths, when checked out into the temporary directory, can be edited by the tool when comparing against older commits. These edits will be lost. Yes. That is exactly my desired use case. I want to make edits while I'm reviewing the diff. I took a crack at implementing the change to make difftool -d use symlinks more aggressively. I've tested it lightly, and it works for the limited cases I've tried. This is my first foray into the Git source code, so it's entirely possible that there are unintended side effects and regressions if other features depend on the same code path and make different assumptions. https://github.com/matthewlmcclure/git/compare/difftool-directory-symlink-work-tree Your thoughts on the change? -- Matt McClure http://www.matthewlmcclure.com http://www.mapmyfitness.com/profile/matthewlmcclure -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: difftool -d symlinks, under what conditions
On Tue, Mar 12, 2013 at 5:06 PM, John Keeping j...@keeping.me.uk wrote: On Tue, Mar 12, 2013 at 01:39:17PM -0700, Junio C Hamano wrote: What is the situation when you do not want symbolic links? When you're not comparing the working tree. If we can reliably say the RHS is the working tree then it could be unconditional, but I haven't thought about how to do that - I can't see a particularly easy way to check for that; Agreed. From what I can see, the only form of the diff options that compares against the working tree is git difftool -d [--options] commit [--] [path...] At first, I thought that the following cases were also working tree cases, but actually they use the HEAD commit. git difftool -d commit1.. git difftool -d commit1... is it sufficient to say there is no more than one non-option to the left of '--' and '--cached' is not among the options? An alternative approach would be to reuse git-diff's option parsing and make it tell git-difftool when git-diff sees the working tree case. At this point, I haven't seen an obvious place in the source where git-diff makes that choice, but if someone could point me in the right direction, I think I'd actually prefer that approach. What do you think? -- Matt McClure http://www.matthewlmcclure.com http://www.mapmyfitness.com/profile/matthewlmcclure -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: difftool -d symlinks, under what conditions
On Tue, Mar 12, 2013 at 5:43 PM, Matt McClure matthewlmccl...@gmail.com wrote:
On Tue, Mar 12, 2013 at 5:06 PM, John Keeping j...@keeping.me.uk wrote:
is it sufficient to say
there is no more than one non-option to the left of '--' and '--cached'
is not among the options?
An alternative approach would be to reuse git-diff's option parsing
and make it tell git-difftool when git-diff sees the working tree
case. At this point, I haven't seen an obvious place in the source
where git-diff makes that choice, but if someone could point me in the
right direction, I think I'd actually prefer that approach. What do
you think?
There's an interesting comment in cmd_diff:
/*
* We could get N tree-ish in the rev.pending_objects list.
* Also there could be M blobs there, and P pathspecs.
*
* N=0, M=0:
* cache vs files (diff-files)
* N=0, M=2:
* compare two random blobs. P must be zero.
* N=0, M=1, P=1:
* compare a blob with a working tree file.
*
* N=1, M=0:
* tree vs cache (diff-index --cached)
*
* N=2, M=0:
* tree vs tree (diff-tree)
*
* N=0, M=0, P=2:
* compare two filesystem entities (aka --no-index).
*
* Other cases are errors.
*/
whereas inspecting rev.pending in the compare against working tree
case, I see:
(gdb) p rev.pending
$3 = {
nr = 1,
alloc = 64,
objects = 0x100807a00
}
(gdb) p *rev.pending.objects
$4 = {
item = 0x100831a48,
name = 0x7fff5fbff8f8 HEAD^,
mode = 12288
}
Given the cases listed in the comment, I assume cmd_diff must
interpret this case as:
* N=1, M=0:
* tree vs cache (diff-index --cached)
The description of that case is confusing or wrong given that
git-diff-index(1) says:
--cached
do not consider the on-disk file at all
***
cmd_diff executes this case:
else if (ents == 1)
result = builtin_diff_index(rev, argc, argv);
So it looks like I could short-circuit in builtin_diff_index or
something it calls -- e.g., run_diff_index -- to get git-diff to tell
git-difftool that it's the working tree case. I see that
run_diff_index does:
diff_set_mnemonic_prefix(revs-diffopt, c/, cached ? i/ : w/);
So that looks like a good place where the code is already deciding
that it's the working tree case -- w/, though surprisingly to me:
(gdb) p revs-diffopt
$12 = {
...
a_prefix = 0x1001c25aa a/,
b_prefix = 0x1001c25ad b/,
...
So diff_set_mnemonic_prefix doesn't actually use the w/ value passed
to it because:
if (!options-b_prefix)
options-b_prefix = b;
Maybe if I could prevent b_prefix from getting set earlier, I could
get some variant of git-diff to emit the w/ for git-difftool.
--
Matt McClure
http://www.matthewlmcclure.com
http://www.mapmyfitness.com/profile/matthewlmcclure
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: difftool -d symlinks, under what conditions
On Mar 12, 2013, at 4:16 PM, Junio C Hamano gits...@pobox.com wrote: Matt McClure matthewlmccl...@gmail.com writes: An alternative approach would be to reuse git-diff's option parsing I do not think you want to go there. That wouldn't solve the third case in my previous message, no? I think I don't fully understand your third bullet. * If you are comparing two trees, and especially if your RHS is not HEAD, you will send everything to a temporary without symlinks. Any edit made by the user will be lost. I think you're suggesting to use a symlink any time the content of any given RHS revision is the same as the working tree. I imagine that might confuse me as a user. It would create circumstances where some files are symlinked and others aren't for reasons that won't be straightforward. I imagine solving that case, I might instead implement a copy back to the working tree with conflict detection/resolution. Some earlier iterations of the directory diff feature used copy back without conflict detection and created situations where I clobbered my own changes by finishing a directory diff after making edits concurrently. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] difftool: Make directory diff symlink work tree
On Mar 12, 2013, at 1:25 PM, John Keeping j...@keeping.me.uk wrote: When I tried this I got the expected behaviour even without this patch. git diff --raw commit emits the null SHA1 if the working tree file's stat differs from the blob corresponding to commit. Is that the case you observed? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] difftool: Make directory diff symlink work tree
On Tue, Mar 12, 2013 at 3:24 PM, John Keeping j...@keeping.me.uk wrote: When I tried this I got the expected behaviour even without this patch. It turns out that an uncommitted, but *staged* change emits the SHA1 of the blob rather than the null SHA1. Do you get the desired behaviour if you git reset before using difftool? I tried this: $ git diff --raw HEAD^ :100644 100644 f35de0f... ead9399... M diff-lib.c $ git reset HEAD^ Unstaged changes after reset: M diff-lib.c $ git diff --raw :100644 100644 f35de0f... 000... M diff-lib.c $ git difftool -d and the last command did indeed create symlinks into my working tree rather than file copies. So... it seems that using git-reset is at least a workaround to get the symlink behavior I want as a user, though the dance I have to do is a little more awkward than `git difftool -d HEAD^` would be. If so I think you want some new mode of operation for difftool instead of this patch which will also affect unrelated commands. Are you suggesting that difftool do the reset work above given a new option or by default? -- Matt McClure http://www.matthewlmcclure.com http://www.mapmyfitness.com/profile/matthewlmcclure -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: difftool -d symlinks, under what conditions
On Tuesday, November 27, 2012, David Aguilar wrote: It seems that there is an edge case here that we are not accounting for: unmodified worktree paths, when checked out into the temporary directory, can be edited by the tool when comparing against older commits. These edits will be lost. Yes. That is exactly my desired use case. I want to make edits while I'm reviewing the diff. When we can do that then we avoid needing to have a temporary directory altogether for any dir-diffs that involve the worktree. I think the temporary directory is still a good thing. Without it, the directory diff tool would have no way to distinguish a file added in the diff from a file that was preexisting and unmodified. -- Matt McClure http://www.matthewlmcclure.com http://www.mapmyfitness.com/profile/matthewlmcclure -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
