Archiving off old branches
I've got a branch for each bug/issue and it was getting a bit
unwieldy. A little searching suggested this
# archive off the BUG-123 branch
git update-ref refs/closed/BUG-123 BUG-123
git branch -D BUG-123
which seems to do exactly what I want -- branches are archived off so
they still have refs, but they don't appear in the output of git
branch.
Reading up on git help update-ref, it states that it updates the
name safely. As best I can tell, the above process does something
like
cd .git/refs
mkdir -p closed
mv heads/BUG-123 closed
Is there something unsafe about this? The advantage to the latter
would be that I could do a bunch of them easily:
mv heads/BUG-{123,234,345,456,567} closed
but I want to make sure I'm not screwing something up unsafely. Is
there some key element to update-ref's safety that I'm missing?
-tkc
--
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: Archiving off old branches
On 2014-04-23 10:58, Jonathan Nieder wrote: Tim Chase wrote: cd .git/refs mkdir -p closed mv heads/BUG-123 closed That breaks with packed refs (see git-pack-refs(1)), which are a normal thing to encounter after garbage collection. Hope that helps, Very much so. Alrighty...based on that alone, I'll stick to my archive script that calls update-ref and then deletes the branch. Thanks, -tkc -- 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: Our official home page and logo for the Git project
On 2014-04-11 13:32, Javier Domingo Cansino wrote: I have never thought on that logo as the Git logo (the red one), and thought it was [1]. Mainly because the logo itself has git inside. [1] Git logo: http://git-osx-installer.googlecode.com/files/GitLogo.jpg -- Like Javier, I too assumed that this was the git logo. As a side note, I was surprised how hard/expensive it is to find a simple tshirt with either git logo on it. I received a free bzr shirt at PyCon a while back, but since I actually *use* git, I'd rather give it the advocacy love. -tkc -- 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
A little git humor: a git man page generator
This crossed my path recently via the fossil mailing list http://git-man-page-generator.lokaltog.net/ but I thought folks here might enjoy the humor :-) (and I hadn't seen mention of it here on the list yet) -tkc -- 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: Using - for previous branch failing with rebase
On 2014-03-16 23:37, Junio C Hamano wrote: Tim Chase g...@tim.thechases.com writes: Is this just an interface inconsistency or is there a some technical reason this doesn't work (or, has it been addressed/fixed, and just not pulled into Debian Stable's 1.7.10.4 version of git)? It is merely that nobody thought rebase would benefit from such a short-hand, I think. Teach more commands that operate on branch names about - shorthand for the branch we were previously on, like we did for git merge - sometime after we introduced git checkout - has been sitting in my leftover bits list at http://git-blame.blogspot.com/p/leftover-bits.html for quite some time. Hint, hint... Not sure if the Hint, hint was intended for me, as I'm not exactly a git hacker. I did find another place where I reached for it instinctively (now that I use it regularly with checkout/merge): git-diff. git checkout some_branch #hack git commit -m ... git checkout other_branch # hmm...what's different between these branches? git diff - which I would have expected to act something like git diff some_branch..other_branch Just for the archives. -tkc (or possibly the reverse) -- 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
Using - for previous branch failing with rebase
I recently learned that there are several places where git allows use of - to refer to the previous branch, e.g. git checkout -b dev # hack, hack git checkout master git merge - git checkout - However, it doesn't seem to understand - in the context of a rebase: git checkout branch_a # hack git commit -a git checkout branch_b # hack git commit -a git rebase - # I'd expect to rebase onto branch_a but I get fatal: Needed a single revision invalid upstream - Issuing git rebase branch_a does exactly what I'd expect (as git checkout - puts me on branch_a). Is this just an interface inconsistency or is there a some technical reason this doesn't work (or, has it been addressed/fixed, and just not pulled into Debian Stable's 1.7.10.4 version of git)? Thanks, -tkc -- 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
branch annotations?
Is there any way to associate some sort of note with a branch that would be shown when listing them? While I currently have things like issue/QA-42, it would be nice to have a note associated with it so I could do something like $ git branch --show-notes issue/CR-88: make sure NoSQL engines support .CSV file backends issue/QA-31: add missile launch codes * issue/QA-42: support flying cars master as I currently need to flip back and forth between my git/terminal and my issue-tracker to know that, if I need to be adding missile launch codes, I need to be working on QA-31. I know there are note features elsewhere for commits, and I know that git-branch supports showing the most recent commit (that's not always enough info to discern the branch's purpose). Thanks for any ideas on how to ease this pain-point, :-) -tkc -- 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: branch annotations?
On 2013-11-25 15:55, Johan Herland wrote: git branch --edit-description allows you to write a descriptive string for your branch. AFAICS, however, it currently only shows up when using request-pull. It does not show up in any git branch command. IMHO that should be fixed. As a workaround, you can use this one-liner: git for-each-ref --format %(refname:short) refs/heads/ | while read branch; do echo $branch - $(git config branch.$branch.description); done That works like a charm. Thanks! -tkc -- 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
defaulting git stash to --keep-index
Having lost add -p work enough times when stashing, I finally dug into the docs to see how to prevent it, discovering that --keep-index does exactly what I want. However, now I have trouble remembering to add the --keep-index until after I've shot myself in the foot. How do I go about getting git stash to default to --keep-index? I've played around a little with aliases, but haven't found the right incantation. The existence of --no-keep-index suggests there's some way to make --keep-index the default, but I'm missing it. Thanks, -tkc -- 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 - fossil bridging?
Has there been any development on git-fossil bridging? I know one can spew fastimports between the two for an initial synchronization, but I'd like to have a continuous bridge; something like git-svn. I have fossil on one machine (mostly a public machine, for bug-tracking, wiki, etc that fossil does nicely) while using git locally and pushing change-sets out to the fossil repo. Any tips? My current experimentation just houses both in the same location with my git master branch manually synced with the fossil repo (which is really all I need which does simplify matters greatly, though it would be nice to sync multiple branches if the functionality was there). Thanks, -tkc -- 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: Git - fossil bridging?
On 2013-11-17 14:43, Kyle J. McKay wrote: Sounds like you want to write a 'git-remote-fossil' helper so you can do something like: git clone fossil::http://sqlite.org/src Pretty much. Or at least something akin to git-svn where one would do git fossil clone http://some.fossil.url/path/to/repo.fossil # hack hack git commit # possibly some git-branch, git-merge, git-rebase, git-cherry-pick # lather, rinse, repeat git fossil push # or git fossil dcommit I've not played with the git+hg or git+bzr bridges to see if they'd have a more useful interface that would better map to fossil. If so, imagine that's what I typed above ;-) -tkc -- 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: coming from git, understanding mercurial branching
On 2013-09-06 12:39, Tay Ray Chuan wrote: First: recognize Mercurial's branches are entirely different beasts from Git's. They just happen to be given a same sequence of characters, b-r-a-n-c-h. The similarities end there! Yeah, I'm trying to create a mental map between what Git means by branching, and what Mercurial means by branching. As you say, they seem to be entirely different beasts. often the docs suggest cloning instead of branching; Are you referring to this? $ hg clone https://... master $ cd master # hack... $ cd .. $ hg clone https://... fix1 Usually I see this written as $ cd .. $ hg clone master fix1 but otherwise, yes. $ cd fix1 # hack... $ cd../master $ hg pull ../fix1 $ hg merge ... In git, you would have your master branch, checkout -b fix1, then merge them back to master when you're done. The above describes how one would do this in mercurial. Mercurial has this cloning-branch thing, a branch command, and something called bookmarks which all seem to have different behaviors (and corresponding reasons to choose them) and yet all be loosely referred to as branching. Cloning litters the drive with duplicate checkouts (even if they use hard-linking for the repo behind the scenes, there's still a lot of time spent writing. The git equiv of this hg suite would be almost identical, cloning a local checkout); the 2nd and 3rd are more branch-related and what I'm trying to grok. -tkc -- 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: coming from git, understanding mercurial branching
On 2013-09-06 17:51, Konstantin Khomoutov wrote: I found this guide [1] very useful back in the time I tried to grok Mercurial. 1. http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/ Indeed, after reading it, that's the most sense I've been able to make of Mercurial's strange branching. I guess it boils down to the following rough heuristic: - if you want to dink around locally, but don't want to publish your branches (yet), default to bookmarks using hg bookmark - once you want a branch to be public, consider making a real branch using hg branch - if you want complete isolation in case you screw up something like merging, use a clone I still prefer Git's way, but at least I'm not left scratching my head when I have to play with Mercurial branches. Thanks, all. -tkc -- 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
coming from git, understanding mercurial branching
I've got a pretty good grasp on git's rather straightforward branching, but am trying to wrap my head around Mercurial's branching. There seem to be several flavors, some default to push-public, while others are private; some are tracked in history, while others seem more ephemeral; often the docs suggest cloning instead of branching; detached heads seem more normal in the Mercurial world. Do any git users here have good understanding Mercurial branches for the git user resources they've found helpful when working with Mercurial? Preferably a for dummies resource with illustrations comparison charts so I can see the big picture. Thanks -tkc PS: I've read a couple Mercurial resources including http://mercurial.selenic.com/wiki/GitConcepts but it didn't really dig into comparing the mental models used in branching. -- 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: Proper URI for svn clone on a network share (Win32)
On 2013-08-14 12:49, Tim Chase wrote: c:\temp git svn clone file:///x:/path/to/repo/trunk/utils/project1 but get various failures. My best-effort (above) gets me as far as actually starting some sort of clone but it dies with Permission denied: Can't open '/tmp/report.tmp': Permission denied at /usr/lib/perl5/site_perl/Git/SVN.pm line 1210 PS: I don't really care much about pushing back to svn, existing svn branches or tags, or username mapping. If needed, I can apply patches out of git which is far less painful than switching/merging branches in svn. So I can be a little rough-shod with cloning the svn repo. PPS: in case it matters: C:\work\utils\temp\iosgit version git version 1.8.3.msysgit.0 Just tickling this thread. I tried John Keeping's suggestions on setting TMPDIR to some known location, but I continue getting the same error about Can't open '/tmp/report.tmp': Permission denied... both in cmd.exe and within the bash.exe that comes with msysgit. In additional peculiarity from my testing, if I point a true Linux shell at the same network-mounted drive, it seems to work just fine: tim@host:/tmp$ git svn clone file:///mnt/svnroot/trunk/utils/project1 tim@host:/tmp$ git --version git version 1.5.6.5 (yeah, that's a REALLY ancient version of git on an old Debian Lenny box, but if *that* works, 1.8.x shouldn't have ANY trouble with it) Any further ideas? -tkc -- 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: Proper URI for svn clone on a network share (Win32)
On 2013-08-15 09:00, John Keeping wrote: On Wed, Aug 14, 2013 at 06:26:57PM -0500, Tim Chase wrote: On 2013-08-14 12:49, Tim Chase wrote: If it makes any difference, this is within a cmd.exe shell (with $PATH set appropriately so git is being found). Just a follow-up, I tried it within the bashish shell included in the git install and got the same error regarding /tmp/report.tmp. It seems that report.tmp is something that SVN creates and for some reason the svn on your system is trying to create it in a Unix style temporary directory. What happens if you export TMPDIR=C:/Windows/Temp before running git-svn? Still getting the same results. I tried: 1) cmd.exe with my local temp dir: c:\temp TEMPDIR=%TEMP% c:\temp git svn clone file:///x:/path/to/repo/trunk/utils/project1 2) cmd.exe with the windows temp dir as you specify: c:\temp TEMPDIR=c:\windows\temp c:\temp git svn clone file:///x:/path/to/repo/trunk/utils/project1 3) git's bash.exe with inline variable definition: $ TEMPDIR=c:/Windows/Temp git svn clone file:///x:/path/to/repo/trunk/utils/project1 4) git's bash.exe with exported variable: $ export TEMPDIR=c:/Windows/Temp $ git svn clone file:///x:/path/to/repo/trunk/utils/project1 All of them died with the complaint about /tmp/report.tmp Thanks for the suggestion though. At least we've determined one thing that *isn't* the issue ;-) -tkc -- 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: Proper URI for svn clone on a network share (Win32)
On 2013-08-15 12:35, John Keeping wrote: Just a follow-up, I tried it within the bashish shell included in the git install and got the same error regarding /tmp/report.tmp. It seems that report.tmp is something that SVN creates and for some reason the svn on your system is trying to create it in a Unix style temporary directory. What happens if you export TMPDIR=C:/Windows/Temp before running git-svn? Still getting the same results. This should be TMPDIR - note the missing 'E'! I wish I could blame it on my doofus mistype, but I tried the same 4 operations as my previous email, using TMPDIR this time instead of TEMPDIR but got the same errors regarding /tmp/report.tmp. You may also need to export TMPDIR but I don't know how cmd.exe decides what environment variables to export to subprocesses. From my understanding/experimentation, cmd.exe acts as if all environment variables are exported all the time (i.e., there is no such thing as a local non-exported environment variable). Any further ideas to try? Thanks, -tkc -- 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
Proper URI for svn clone on a network share (Win32)
I've been sparring with the proper syntax and hope someone can give me the magic I'm missing. I want to do something of the form c:\temp git svn clone file:///x:/path/to/repo/trunk/utils/project1 but get various failures. My best-effort (above) gets me as far as actually starting some sort of clone but it dies with Permission denied: Can't open '/tmp/report.tmp': Permission denied at /usr/lib/perl5/site_perl/Git/SVN.pm line 1210 If it makes any difference, this is within a cmd.exe shell (with $PATH set appropriately so git is being found). Am I missing something in the URL syntax to get it to clone my svn repo with less drama? -tkc PS: I don't really care much about pushing back to svn, existing svn branches or tags, or username mapping. If needed, I can apply patches out of git which is far less painful than switching/merging branches in svn. So I can be a little rough-shod with cloning the svn repo. PPS: in case it matters: C:\work\utils\temp\iosgit version git version 1.8.3.msysgit.0 . -- 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: Proper URI for svn clone on a network share (Win32)
On 2013-08-14 12:49, Tim Chase wrote: If it makes any difference, this is within a cmd.exe shell (with $PATH set appropriately so git is being found). Just a follow-up, I tried it within the bashish shell included in the git install and got the same error regarding /tmp/report.tmp. -tkc -- 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: Off-line deverloper workflow?
On 2013-06-27 20:46, Woody Wu wrote: I have a colleague who has to left our office for three month, but still need to work on the project which is hosted on our in-office git repository. Problem is that our company has firewall, it's not possible or not allowed to access the company LAN outside the building. So I want to ask you expert, can you suggest a best practice of git workflow that suitable to my situation? It would help to know a little more about the information flow and the starting conditions. - Was a clone of code made before leaving your office or does your colleague need to obtain the initial copy too? - How securely do you need to transfer matters? (email? shared external service like Dropbox/Box.com/etc) - How frequently do updates need to be made? - In which direction do commits flow? Just from your colleague back to the office, or are there other updates happening in the office that your colleague needs to pull down to keep in sync? Without such answers, it's a little hard to suggest more than transmitting either patch files or bundles using any of the following: email, a shared cloud drive, a shared host out accessible on the net, or sneakernet media (flash-drive or CD/DVD, perhaps via the postal system), or possibly other means. You may want to read more at git help format-patch git help am git help bundle -tkc -- 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: Splitting a commit with rebase -i and keeping a commit message
On 2013-04-16 19:29, David Aguilar wrote:
On Tue, Apr 16, 2013 at 6:38 PM, Tim Chase g...@tim.thechases.com
wrote:
git commit -am Long-bodied commit comment about b.txt changes
# whoops, just wanted B
Save the commit's ID here so that we can reuse its message later:
orig_commit=$(git rev-parse HEAD)
git rebase -i HEAD^^
# change the Added b.txt... commit to edit
git reset HEAD^ # pull the changes out of the pending commit
git add a.txt
git commit -m Tweaked a.txt
git add b.txt
git commit ${MAGIC_HERE}
...reuse the commit message by passing the -c option to git
commit:
git commit --reset-author -c $orig_commit
Wild guess or not, using -c worked great. With the appropriate
section of the docs now in hand, I discovered that it could even be
simplified to just
git commit -c ORIG_HEAD [...]
as rebase stashes that information away for me already as ORIG_HEAD.
Thanks!
-tkc
--
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
clean/smudge filters on .zip/.tgz files
Various programs that I use ([Open|Libre]Office, Vym, etc) use a zipped/.tgz'ed file format, usually containing multiple (usually) plain-text files within. I'm trying to figure out a way for git to treat these as virtual directories for purposes of merging/diffing. Reading up on clean/smudge filters, it looks like they expect one file coming in and one file going out, rather than one file on one side and a directory-tree of files on the other side. I tried creating my own pair of clean/smudge filters that would uncompress the files, but there's no good way put multiple files on stdout. Has anybody else played with such a scheme for uncompressing files as they go into git and recompressing them as they come back out? -tkc -- 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: [ANNOUNCE] Git v1.8.2-rc0
On 2013-02-17 16:52, Junio C Hamano wrote: * Color specifiers, e.g. %C(blue)Hello%C(reset), used in the --format= option of git log and friends can be disabled when the output is not sent to a terminal by prefixing them with auto,, e.g. %C(auto,blue)Hello%C(auto,reset). Thanks so much! It has long annoyed me that I had to maintain pairs of nigh-identical aliases, one with colors for output on my terminal, the other alias uncolored for piping to further commands. -tkc -- 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
Preventing merges from one branch into others
[tried IRC to no avail] I've been trying to find a way to prevent myself from merging a client-specific branch back into my dev/master branches. Is there an easy/straightforward way to do this (perhaps via a hook)? I didn't see any sort of pre-merge hook script. Visualized: A - B - C [dev] \ - Q - R - S [customer-specific] and I want to ensure that changes Q/R/S never find their way back into dev. So I was hoping some sort of hey, you're an idiot for trying to merge $CUSTOMER_BRANCH back into dev/master warning. :-) -tkc -- 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] minor diff between gitweb docs and actual template for $GIT/description
The documentation for gitweb gives one description of the default content for the $GIT/description, the description template has other text. One of these two patches should be applied to bring them into order (applying both would just reverse the problem). Or, both could be changed to the same new text. -tkc (not subscribed to the actual git ML, just git-us...@googlegroups.com) diff --git a/Documentation/gitweb.txt b/Documentation/gitweb.txt index 168e8bf..7c4cb69 100644 --- a/Documentation/gitweb.txt +++ b/Documentation/gitweb.txt @@ -227,7 +227,7 @@ description (or `gitweb.description`):: repository). Plain text file; HTML will be escaped. By default set to + --- -Unnamed repository; edit this file to name it for gitweb. +Unnamed repository; edit this file 'description' to name the repository. --- + from the template during repository creation, usually installed in diff --git a/templates/this--description b/templates/this--description index 498b267..c6f25e8 100644 --- a/templates/this--description +++ b/templates/this--description @@ -1 +1 @@ -Unnamed repository; edit this file 'description' to name the repository. +Unnamed repository; edit this file to name it for gitweb.
Re: [PATCH] minor diff between gitweb docs and actual template for $GIT/description
On 01/10/13 20:22, Jonathan Nieder wrote: (+cc: Jakub, who maintains gitweb) Hi Tim, Tim Chase wrote: The documentation for gitweb gives one description of the default content for the $GIT/description, the description template has other text. One of these two patches should be applied to bring them into order (applying both would just reverse the problem). Or, both could be changed to the same new text. May we have your sign-off? (See Documentation/SubmittingPatches for what this means.) Hahahahah...a one liner doc-fix copy/pasting code from one place in the codebase to another? If you need it, you've got it: For my one line diff: Signed-off-by: Tim Chase g...@tim.thechases.com Otherwise, consider my contribution CC0 or public domain or whatever suits you best. Or take my patch as a bug report and make the fix yourself. :-) The patches should have been based off the master branch of github.com/git/git, FWIW. -tkc @gumnos -- 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: misleading diff-hunk header
On 08/24/12 09:29, Jeff King wrote:
On Tue, Aug 21, 2012 at 10:52:03AM -0700, Junio C Hamano wrote:
diff.{type}.xfuncname seems to start searching backwards in
from the beginning of the hunk, not the first differing line.
[...]
@@ -4,4 +4,5 @@ int call_me(int maybe)
int main()
{
+ return 0;
}
misleadingly suggesting that the change occurred in the call_me()
function, rather than in main()
I think that's intentional, and matches what 'diff -p' does.
...
xdiff/xemit.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/xdiff/xemit.c b/xdiff/xemit.c
index 277e2ee..5f9c0e0 100644
--- a/xdiff/xemit.c
+++ b/xdiff/xemit.c
@@ -131,7 +131,7 @@ int xdl_emit_diff(xdfenv_t *xe, xdchange_t *xscr,
xdemitcb_t *ecb,
if (xecfg-flags XDL_EMIT_FUNCNAMES) {
long l;
-for (l = s1 - 1; l = 0 l funclineprev; l--) {
+for (l = s1; l = 0 l funclineprev; l--) {
const char *rec;
long reclen = xdl_get_rec(xe-xdf1, l, rec);
long newfunclen = ff(rec, reclen, funcbuf,
In the case we were discussing then, the modified function started on
the first line of context. But as Tim's example shows, it doesn't
necessarily have to. I think it would make more sense to start counting
from the first modified line.
Junio mentions that it matches the diff -p output, though I'd
consider that a bug in diff as well, since the diff(1) man/info
pages state -p Show which C function each change is in. In the
above (both with diff -p and with git), the change was clearly in
main() but it's not showing main(). Documented behavior and
implemented behavior conflict.
Starting at the first differing line rather than the first line of
context in the hunk would ameliorate this. It doesn't address what
happens if multiple functions were changed in the same hunk, but at
least it becomes correct for the first one. More complex code might
be doable to split hunks if an xfuncname match occurs between two
disjoint changes in the same hunk. But for my purposes here, the
above should suffice.
-tkc
--
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: misleading diff-hunk header
On 08/24/12 11:44, Jeff King wrote:
With the old code, you'd get:
diff --git a/old b/new
index f384549..1066a25 100644
--- a/old
+++ b/new
@@ -2,3 +2,3 @@ one
two
-three
+three -- modified
four
So the hunk header is showing you something useful; the element just
above your context. But with my patch, you'd see:
diff --git a/old b/new
index f384549..1066a25 100644
--- a/old
+++ b/new
@@ -2,3 +2,3 @@ two
two
-three
+three -- modified
four
I.e., it shows the element just before the change, which is already in
the context anyway. So it's actually less useful. Although note that the
current behavior is not all that useful, either; it is not really giving
you any information about the change, but rather just showing one extra
line of context.
So I would say that which you would prefer might depend on exactly what
you are diffing. But I would also argue that in any case where the new
code produces a worse result, the hunk header was not all that useful to
begin with.
If the documented purpose of diff -p (and by proxy
diff.{type}.xfuncname) is to show the name of the *function*
containing the changed lines, and all you have is a list of lines
with no function names, it's pretty arbitrary to call either
behavior worse. :-)
-tkc
--
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
misleading diff-hunk header
[posted originally to git-users@ but advised this would be a better
forum]
diff.{type}.xfuncname seems to start searching backwards in
from the beginning of the hunk, not the first differing line.
To reproduce:
$ mkdir tmp
$ cd tmp
$ git init
$ cat foo.c EOF
int call_me(int maybe)
{
}
int main()
{
}
EOF
$ git add foo.c
$ git commit -m Initial checkin
$ ed foo.c
# main() should return 0
$i
return 0;
.
wq
$ git diff
The diff returns a header line of
@@ -4,4 +4,5 @@ int call_me(int maybe)
int main()
{
+ return 0;
}
misleadingly suggesting that the change occurred in the call_me()
function, rather than in main()
I'm running 1.7.2.5 from Debian Stable if that makes a difference.
Is this expected/proper behavior?
-tkc
FWIW, I stumbled across this tinkering with
diff.{typename}.xfuncname detailed in gitattributes(5)
--
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
misleading diff-hunk header
[posted originally to git-users@ but advised this would be a better
forum]
diff.{type}.xfuncname seems to start searching backwards in
from the beginning of the hunk, not the first differing line.
To reproduce:
$ mkdir tmp
$ cd tmp
$ git init
$ cat foo.c EOF
int call_me(int maybe)
{
}
int main()
{
}
EOF
$ git add foo.c
$ git commit -m Initial checkin
$ ed foo.c
# main() should return 0
$i
return 0;
.
wq
$ git diff
The diff returns a header line of
@@ -4,4 +4,5 @@ int call_me(int maybe)
int main()
{
+ return 0;
}
misleadingly suggesting that the change occurred in the call_me()
function, rather than in main()
I'm running 1.7.2.5 from Debian Stable if that makes a difference.
Is this expected/proper behavior?
-tkc
FWIW, I stumbled across this tinkering with
diff.{typename}.xfuncname detailed in gitattributes(5)
--
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: misleading diff-hunk header
On 08/21/12 10:22, Thomas Rast wrote:
Tim Chase g...@tim.thechases.com writes:
diff.{type}.xfuncname seems to start searching backwards in
from the beginning of the hunk, not the first differing line.
[...]
@@ -4,4 +4,5 @@ int call_me(int maybe)
int main()
{
+ return 0;
}
misleadingly suggesting that the change occurred in the call_me()
function, rather than in main()
I think that's intentional, and matches what 'diff -p' does. It gives
you the context before the hunk. After all, if a new function starts in
the leading context lines, you can see that in the usual diff data.
Okay...I tested diff -p and can't argue (much) with historical
adherence. It just makes it hard for me to gather some stats on the
functions that changed, and requires that I look in more than one
place (both in the header, and in the leading context) rather than
having a single authoritative place to grep.
Then again, diff -p only seems to support C functions, while git
supports bibtex, cpp, html, java, objc, pascal, php, python, ruby,
and tex out-of-the-box, with the option to build your own
function-finder, so pure adherence to history gets a little muddied.
Thanks for your thoughts,
-tkc
--
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
