Re: Push Windows to Linux Repository Problem
Dennis Putnam d...@bellsouth.net writes: I keep getting fatal: Could not read from remote repository. Can you git ls-remote the repository? Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. -- 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: Push Windows to Linux Repository Problem
Hi Andreas, Thanks for the reply and no, I could not. However, you put me on the right track. Since I was only pushing/pulling from Windows to/from my Linux repository, I did not realize that an SSH session from the Linux back to Windows would ever be necessary. I don't really understand why but apparently it is. I never set up that backwards connection. Once I did, everything started working. On 12/23/2012 4:06 AM, Andreas Schwab wrote: Dennis Putnam d...@bellsouth.net writes: I keep getting fatal: Could not read from remote repository. Can you git ls-remote the repository? Andreas. signature.asc Description: OpenPGP digital signature
Using Eclipse git plugin
This may be more of an Eclipse question than a git question but hopefully someone on this list knows both. I now have a working git central repository (on Linux) and a local repository clone (on Windows). I can see and edit my files in Eclipse, commit them and push them to the remote repository. The problem I am having now is developing my code in Eclipse. It seems I can no longer run the code as the 'Run as Application' menu item is missing. How do I test my code now? TIA. signature.asc Description: OpenPGP digital signature
Re: [PATCH 2/2] learn to pick/revert into unborn branch
Martin von Zweigbergk martinv...@gmail.com writes: On Sat, Dec 22, 2012 at 7:24 PM, Junio C Hamano gits...@pobox.com wrote: Martin von Zweigbergk martinv...@gmail.com writes: From the user's point of view, it seems natural to think that cherry-picking into an unborn branch should work, so make it work, with or without --ff. I actually am having a hard time imagining how that could ever be natural. Fair enough. What's natural is of course very subjective. ... happens to be empty. Of course, pretty much any operation that needs more than the tree (indirectly) pointed to by HEAD would fail the whenever possible clause. I realize that cherry-pick _does_ need the current commit to record the parent of the resulting commit,... Yes, and I do not think it is an implementation detail. I am not opposed to an internal use of the cherry-pick machinery to implement a corner case of rebase -i: 1. Your first commit adds Makefile and hello.c, to build the Hello world program. 2. Your second commmit adds goodbye.c and modifies Makefile, to add the Goodbye world program. 3. You run rebase -i --root to get this insn sheet: pick Add Makefile and hello.c for Hello world pick Add goodbye.c for Goodbye world and swap them: pick Add goodbye.c for Goodbye world pick Add Makefile and hello.c for Hello world 4. The first one conflicts, as it wants to add new bits in Makefile that does not exist. You edit it and make the result pretend as if goodbye.c were the first program you added to the project (i.e. adding the common build infrastructure bits you did not change from the real first commit back to Makefile, but making sure it does not yet mention hello.c). 5. rebase --continue will give you conflicts for the second one too, and your resolution is likely to match the tip before you started the whole rebase -i. In step 4., you would be internally using the cherry-pick machinery to implement the step of rebase -i sequence. That is what I would call an implementation detail. And that is cherry-picking to the root. It transplants something that used to depend on the entire history behind it to be the beginning of the history so its log needs to be adjusted, but rebase -i can choose to always make it conflict and force the user to write a correct log message, so it won't expose the fundamental flaw you would add if you allowed the end-user facing cherry-pick to pick something to create a new root commit without interaction. In the same way, I think git reset should work on an unborn branch, even though there is no commit that we can be modifying index and working tree to match (from man page). I agree that git reset without any commit parameter to reset the index and optionally the working tree (with --hard) should reset from an empty tree when you do not yet have any commit. If HEAD points at an existing commit, its tree is what you reset the contents from. If you do not have any commit yet, by definition that tree is an empty tree. But I do not think it has anything to do with cherry-pick to empty, so I do not agree with In the same way at all. As for use cases, I didn't consider that much more than that it might be useful for implementing git rebase --root. I haven't implemented that yet, so I can't say for sure that it will work out. I think it makes sense only as an internal implementation detail of rebase -i --root. One use case might be to rewrite history by creating an new unborn branch and picking the initial commit and a subset of other commits. If you mean, in the above sample history, to git cherry-pick the commit that starts the Hello world and then do something else on top of the resulting history, how would that be different from forking from that existing root commit? Anyway, I didn't implement it because I thought it would be very useful, but mostly because I just thought it should work (for completeness). I would not exactly call X complete if X works in one way in most cases and it works in quite a different way in one other case, only because it would have to barf if it wanted to work in the same way as in most cases, and the different behaviour is chosen only because X that does something is better than X that stops in an impossible situation and barfs. -- 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 2/2] learn to pick/revert into unborn branch
Christian Couder christian.cou...@gmail.com writes: I agree that it would be nice if it worked. That is not saying anything. Yes, it would be nice if everything worked. But the question in the thread is with what definition of 'work'? -- 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 2/2] learn to pick/revert into unborn branch
Junio C Hamano gits...@pobox.com writes: Yes, and I do not think it is an implementation detail. I am not opposed to an internal use of the cherry-pick machinery to implement a corner case of rebase -i: ... In step 4., you would be internally using the cherry-pick machinery to implement the step of rebase -i sequence. That is what I would call an implementation detail. And that is cherry-picking to the root. It transplants something that used to depend on the entire history behind it ... Just to add another example, I do not think I would be opposed to the case where you edit the root commit in the above example, i.e. keeping the Hello world as the root commit, but modifying its tree and/or log message. The internal impemenation detail has to first chery-pick that existing commit on top of a void state before it gives the user a chance to tweak the tree and commit the result with a modified log message. Just like commit --amend can be used to amend the root commit, it logically makes sense the recreated commit records nothing as its parent if done when HEAD is not valid yet. -- 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: Re: Re: Re: Change in cvsps maintainership, abd a --fast-export option
On Sat, Dec 22, 2012 at 09:15:19AM -0500, Eric S. Raymond wrote: sr@snark:~/WWW/cvsps/fixrepos$ git clone http://repo.or.cz/w/cvsps-hv.git Cloning into 'cvsps-hv'... fatal: http://repo.or.cz/w/cvsps-hv.git/info/refs not valid: is this a git repository? That link refers to the webpage of the repository. The clone url is found on that page. Use this address for cloning: git://repo.or.cz/cvsps-hv.git Cheers Heiko -- 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: cvsps, parsecvs, svn2git and the CVS exporter mess
Hi, On Sat, Dec 22, 2012 at 12:36:48PM -0500, Eric S. Raymond wrote: If we can agree on this, I'll start a public repo, and contribute my Python framework - it's more capable than any of the shell harnesses out there because it can easily drive interleaved operations on multiple checkout directories. Please share so we can have a look. BTW, where can I find your cvsps code? Anybody who is still interested in this problem should contribute tests. Heiko Voigt, I'd particularly like you in on this. If it does not take to much effort I could port my tests to the new framework. Since I currently are not in active need of cvs conversions its not of big interest to me anymore. But if it does not take too much time I am happy to help. From my past cvs conversion experiences my personal guess is that cvs2svn will win this competition. Cheers Heiko -- 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 2/2] learn to pick/revert into unborn branch
From: Junio C Hamano gits...@pobox.com Sent: Sunday, December 23, 2012 3:24 AM Subject: Re: [PATCH 2/2] learn to pick/revert into unborn branch Martin von Zweigbergk martinv...@gmail.com writes: From the user's point of view, it seems natural to think that cherry-picking into an unborn branch should work, so make it work, with or without --ff. I actually am having a hard time imagining how that could ever be natural. When you are on an unborn branch, you may have some files in your working tree, and some of them may even be registered to the index, but the index is merely for your convenience to create your first commit, and as far as the history is concered, it does not matter. By definition you do not have any history in such a state. What does it even mean to cherry-pick another commit, especially without the --no-commit option? The resulting commit will carry the message taken from the original commit, but does what it says match what you have done? From: Junio C Hamano Sent: Sunday, December 23, 2012 7:20 PM Subject: Re: [PATCH 2/2] learn to pick/revert into unborn branch Christian Couder christian.cou...@gmail.com writes: I agree that it would be nice if it worked. That is not saying anything. Yes, it would be nice if everything worked. But the question in the thread is with what definition of 'work'? -- From the dumb user perspective, I would have thought that the first commit to be cherry picked for an unborn branch would be the complete commit, which is then planted as the branch's start commit. We tend to talk of cherry picking commits, though the documentation does say 'the changes introduced', which allows such a (mistaken) user perspective for this particular case. It is only in retrospect, and a bit of extra thought, that one could see that the commit's message would not actually describe the new situation and should have been edited. That doesn't mean that it would be right to allow such an initilisation of an unborn branch, it's more an explanation of how the idea may have developed. Philip -- 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: cvsps, parsecvs, svn2git and the CVS exporter mess
Heiko Voigt hvo...@hvoigt.net: Please share so we can have a look. BTW, where can I find your cvsps code? https://gitorious.org/cvsps Developments of the last 48 hours: 1. Andreas Schwab sent me a patch that uses commitids wherever the history has them - this makes all the time-skew problems go away. I added code to warn if commitids aren't present, so users will get a clear indication of when time-skew problems might bite them versus when that is happily impossible. 2. I've scrapped a lot of obsolete code and options. The repo head version uses what used to be called cvs-direct mode all the time now; it works, and the effect on performance is major. This also means that cvsps doesn't need to use any local CVS commands or even have CVS installed where it runs. From my past cvs conversion experiences my personal guess is that cvs2svn will win this competition. That could be. But right now cvsps has one significant advantage over cvs2git (which parsecvs might share) - it's *blazingly* fast. So fast that I scrapped all the local-caching logic; there seems no point to it at today's network speeds, and that's one less layer of complications to go wrong. I've removed a couple hundred lines of code and the program works better and faster than it did before. That's having a good day! -- a href=http://www.catb.org/~esr/;Eric S. Raymond/a -- 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
Find the starting point of a local branch
Hi, list How can I find out what's the staring reference point (a commit number or tag name) of a locally created branch? I can use gitk to find out it but this method is slow, I think there might be a command line to do it quickly. Thanks in advance. -- woody I can't go back to yesterday - because I was a different person then. -- 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: Find the starting point of a local branch
In message 20121224035825.GA17203@zuhnb712, Woody Wu writes: How can I find out what's the staring reference point (a commit number or tag name) of a locally created branch? I can use gitk to find out it but this method is slow, I think there might be a command line to do it quickly. The answer is more complex than you probably suspected. Technically, `git log --oneline mybranch | tail -n 1` will tell you the starting point of any branch. But...I'm sure that isn't what you want to know. You want to know what commit was I at when I typed `git branch mybranch`? The problem is git doesn't record this information and doesn't have the slightest clue. But, you say, I can use `gitk` and see it. See? Right there. That isn't (necessarily) the starting point of the branch, it is the place where your branch diverged from some other branch. Git is actually quite able to tell you when the last time your branch diverged from some other branch. `git merge-base mybranch master` will tell you this, and is probably the answer you were looking for. Note that this is the *last* divergence. If your branch diverged and merged previously that will not be reported. Even worse, if you did a fast-forward merge (I recommend against them in general) then it is impossible to discover about what the independent pre-merge history was really like. -Seth Robertson -- 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] Python scripts audited for minimum compatible version and checks added.
Junio C Hamano gits...@pobox.com writes: I needed something like this on top of it to get it pass t5800. diff --git a/git_remote_helpers/git/__init__.py b/git_remote_helpers/git/__init__.py index 776e891..5047fd4 100644 --- a/git_remote_helpers/git/__init__.py +++ b/git_remote_helpers/git/__init__.py @@ -1,3 +1,5 @@ +import sys + if sys.hexversion 0x0204: # The limiter is the subprocess module sys.stderr.write(git_remote_helpers: requires Python 2.4 or later.) Ping? Is the above the best fix for the breakage? If it weren't __init__, I'd silently squash it in, but the filename feels a bit more magic than the ordinary *.py files, so I was worried there may be some other rules involved what can and cannot go in to such a file, hence I've been waiting for an ack or alternatives. Thanks. -- 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] Python scripts audited for minimum compatible version and checks added.
Junio C Hamano gits...@pobox.com: Junio C Hamano gits...@pobox.com writes: I needed something like this on top of it to get it pass t5800. diff --git a/git_remote_helpers/git/__init__.py b/git_remote_helpers/git/__init__.py index 776e891..5047fd4 100644 --- a/git_remote_helpers/git/__init__.py +++ b/git_remote_helpers/git/__init__.py @@ -1,3 +1,5 @@ +import sys + if sys.hexversion 0x0204: # The limiter is the subprocess module sys.stderr.write(git_remote_helpers: requires Python 2.4 or later.) Ping? Is the above the best fix for the breakage? Sorry, I missed this the first time around. Yes, I think it is. If it weren't __init__, I'd silently squash it in, but the filename feels a bit more magic than the ordinary *.py files, so I was worried there may be some other rules involved what can and cannot go in to such a file, hence I've been waiting for an ack or alternatives. Nope, no special rules. -- a href=http://www.catb.org/~esr/;Eric S. Raymond/a -- 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: Find the starting point of a local branch
On Mon, Dec 24, 2012 at 11:09 AM, Seth Robertson in-gitv...@baka.org wrote: In message 20121224035825.GA17203@zuhnb712, Woody Wu writes: How can I find out what's the staring reference point (a commit number or tag name) of a locally created branch? I can use gitk to find out it but this method is slow, I think there might be a command line to do it quickly. The answer is more complex than you probably suspected. Technically, `git log --oneline mybranch | tail -n 1` will tell you the starting point of any branch. But...I'm sure that isn't what you want to know. You want to know what commit was I at when I typed `git branch mybranch`? The problem is git doesn't record this information and doesn't have the slightest clue. Maybe we should store this information. reflog is a perfect place for this, I think. If this information is reliably available, git rebase can be told to rebase my whole branch instead of my choosing the base commit for it. -- Duy -- 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: Find the starting point of a local branch
On Mon, 24 Dec 2012 12:28:45 +0700, Nguyen Thai Ngoc Duy pclo...@gmail.com wrote: On Mon, Dec 24, 2012 at 11:09 AM, Seth Robertson in-gitv...@baka.org wrote: In message 20121224035825.GA17203@zuhnb712, Woody Wu writes: How can I find out what's the staring reference point (a commit number or tag name) of a locally created branch? I can use gitk to find out it but this method is slow, I think there might be a command line to do it quickly. The answer is more complex than you probably suspected. Technically, `git log --oneline mybranch | tail -n 1` will tell you the starting point of any branch. But...I'm sure that isn't what you want to know. You want to know what commit was I at when I typed `git branch mybranch`? The problem is git doesn't record this information and doesn't have the slightest clue. Maybe we should store this information. reflog is a perfect place for this, I think. If this information is reliably available, git rebase can be told to rebase my whole branch instead of my choosing the base commit for it. What's the starting point of the branch if I type: git branch foo commit-ish? -- 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: Find the starting point of a local branch
On Mon, Dec 24, 2012 at 12:34 PM, Tomas Carnecky tomas.carne...@gmail.com wrote: Maybe we should store this information. reflog is a perfect place for this, I think. If this information is reliably available, git rebase can be told to rebase my whole branch instead of my choosing the base commit for it. What's the starting point of the branch if I type: git branch foo commit-ish? You start working off commit-ish so I think the starting point would be commit-ish. -- Duy -- 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: Find the starting point of a local branch
On Mon, Dec 24, 2012 at 12:28:45PM +0700, Nguyen Thai Ngoc Duy wrote: You want to know what commit was I at when I typed `git branch mybranch`? The problem is git doesn't record this information and doesn't have the slightest clue. Maybe we should store this information. reflog is a perfect place for this, I think. If this information is reliably available, git rebase can be told to rebase my whole branch instead of my choosing the base commit for it. Is that what you really want, though? We record the upstream branch already, and you can calculate the merge base with that branch to see which commits are unique to your branch. In simple cases, that is the same as where did I start the branch. In more complex cases, it may not be (e.g., if you merged some of the early commits in the branch already). But in that latter case, would you really want to rebase those commits that had been merged? The reason that git does not bother storing where did I start this branch is that it is usually not useful. The right question is usually what is the merge base. There are exceptions, of course (e.g., if you are asking something like what work did I do while checked out on the 'foo' branch). But for merging and rebasing, I think the computed merge-base is much more likely to do what people want. -Peff -- 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: Find the starting point of a local branch
Nguyen Thai Ngoc Duy pclo...@gmail.com writes:
On Mon, Dec 24, 2012 at 12:34 PM, Tomas Carnecky
tomas.carne...@gmail.com wrote:
Maybe we should store this information. reflog is a perfect place for
this, I think. If this information is reliably available, git rebase
can be told to rebase my whole branch instead of my choosing the
base commit for it.
What's the starting point of the branch if I type: git branch foo
commit-ish?
You start working off commit-ish so I think the starting point would
be commit-ish.
Yeah, that sounds sensible. Don't we already have it in the reflog,
though?
What is trickier is when you later transplant it to some other base
(perhaps prepare a topic on 'master', realize it should better apply
to 'maint' and move it there). If the user did the transplanting by
hand, reflog would probably not have enough information, e.g. after
$ git checkout maint^0
$ git log --oneline master..topic
$ git cherry-pick $one_of_the_commit_names_you_see_in_the_above
$ git cherry-pick $another_commit_name_you_see_in_the_above
...
$ git branch -f topic
no reflog other than HEAD@{} will tell you that you were at maint^0,
so the reflog of topic wouldn't know it forked from there, either.
--
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 2/2] learn to pick/revert into unborn branch
On Sun, Dec 23, 2012 at 11:18 AM, Junio C Hamano gits...@pobox.com wrote: Martin von Zweigbergk martinv...@gmail.com writes: On Sat, Dec 22, 2012 at 7:24 PM, Junio C Hamano gits...@pobox.com wrote: I am not opposed to an internal use of the cherry-pick machinery to implement a corner case of rebase -i: 3. You run rebase -i --root to get this insn sheet: pick Add Makefile and hello.c for Hello world pick Add goodbye.c for Goodbye world and swap them: pick Add goodbye.c for Goodbye world pick Add Makefile and hello.c for Hello world Right, and as you point out in your later message, editing the initial commit is another (and more useful) use case. It could of course be special cased in git rebase, but I think doing it git cherry-pick is the right thing to do. Hopefully git-rebase.sh can then just reset to the void state and git-rebase--interactive.sh can just continue without knowing or caring whether it got started on an unborn branch. Hmm... I just realized the branch in unborn branch really means we don't have unborn detached HEAD, do we? So some more tricks are probably necessary after all. :-( [...] It transplants something that used to depend on the entire history behind it to be the beginning of the history so its log needs to be adjusted, but rebase -i can choose to always make it conflict and force the user to write a correct log message, so it won't expose the fundamental flaw you would add if you allowed the end-user facing cherry-pick to pick something to create a new root commit without interaction. If I understand you correctly, you are suggesting that git rebase should set the action from pick to edit for the first commit in the insn sheet if it is not a root commit. git rebase -i --root doesn't currently do that, but it certainly could. I agree that git reset without any commit parameter to reset the index and optionally the working tree (with --hard) should reset from an empty tree when you do not yet have any commit. Good to hear. But I do not think it has anything to do with cherry-pick to empty, so I do not agree with In the same way at all. See later comment. One use case might be to rewrite history by creating an new unborn branch and picking the initial commit and a subset of other commits. If you mean, in the above sample history, to git cherry-pick the commit that starts the Hello world and then do something else on top of the resulting history, how would that be different from forking from that existing root commit? True, the result would be the same. The user's thought process might be a little different (let me start from scratch vs let me start almost from scratch), but that's a very minor difference that I'm sure any user would quickly overcome. Anyway, I didn't implement it because I thought it would be very useful, but mostly because I just thought it should work (for completeness). I would not exactly call X complete if X works in one way in most cases and it works in quite a different way in one other case, only because it would have to barf if it wanted to work in the same way as in most cases, and the different behaviour is chosen only because X that does something is better than X that stops in an impossible situation and barfs. I agree, of course, but I don't see the behavior as different. When thinking about behavior around the root of the history, I imagine that all root commits actually have a parent, and that they all have the same parent. I also imagine that on an unborn branch, instead of being invalid, HEAD points to that same single root commit with an empty tree. Despite this model not matching git's, I find that this helps me reason about what the behavior of various commands should be. With this reasoning, cherry-picking into an unborn branch is no different from cherry-picking into any commit with an empty tree (which of course would be rare, but not forbidden). -- 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: Find the starting point of a local branch
On Sun, Dec 23, 2012 at 11:09:58PM -0500, Seth Robertson wrote: In message 20121224035825.GA17203@zuhnb712, Woody Wu writes: How can I find out what's the staring reference point (a commit number or tag name) of a locally created branch? I can use gitk to find out it but this method is slow, I think there might be a command line to do it quickly. The answer is more complex than you probably suspected. Technically, `git log --oneline mybranch | tail -n 1` will tell you the starting point of any branch. But...I'm sure that isn't what you want to know. You want to know what commit was I at when I typed `git branch mybranch`? Yes, this is exactly I want to know. The problem is git doesn't record this information and doesn't have the slightest clue. But, you say, I can use `gitk` and see it. See? Right there. That isn't (necessarily) the starting point of the branch, it is the place where your branch diverged from some other branch. Git is actually quite able to tell you when the last time your branch diverged from some other branch. `git merge-base mybranch master` will tell you this, and is probably the answer you were looking for. This is not working to me since I have more than one local branch that diverged from the master, and in fact, the branch I have in question was diverged from another local branch. With the method of 'git merge-base', I have to remember a branch tree in my brain. But thanks anyway, I see you guys's discussions and it's a little hard to understand to me at the moment. Currently, I still have to use gitk with narrowed outputs. Note that this is the *last* divergence. If your branch diverged and merged previously that will not be reported. Even worse, if you did a fast-forward merge (I recommend against them in general) then it is impossible to discover about what the independent pre-merge history was really like. -Seth Robertson -- woody I can't go back to yesterday - because I was a different person then. -- 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
