* Re: [PATCH] Python scripts audited for minimum compatible version and checks added.
From: Pete Wyckoff @ 2012-12-24 13:36 UTC (permalink / raw)
To: Eric S. Raymond; +Cc: git
In-Reply-To: <20121220141855.05DAA44105@snark.thyrsus.com>
esr@thyrsus.com wrote on Thu, 20 Dec 2012 09:13 -0500:
> diff --git a/git-p4.py b/git-p4.py
> index 551aec9..ec060b4 100755
> --- a/git-p4.py
> +++ b/git-p4.py
> @@ -12,6 +12,11 @@ import optparse, sys, os, marshal, subprocess, shelve
> import tempfile, getopt, os.path, time, platform
> import re, shutil
>
> +if sys.hexversion < 0x02040000:
> + # The limiter is the subprocess module
> + sys.stderr.write("git-p4.py: requires Python 2.4 or later.")
> + sys.exit(1)
> +
> verbose = False
If 2.3 does not have the subprocess module, this script will fail
at the import, and not run your version test.
All the uses of sys.stderr.write() should probably include a
newline. Presumably you used write instead of print to avoid
2to3 differences.
The name of this particular script, as users would type it, is
"git p4"; no dash and no ".py".
Many of your changes have these three problems; I just picked on
my favorite one.
> diff --git a/git-remote-testgit.py b/git-remote-testgit.py
> index 5f3ebd2..22d2eb6 100644
> --- a/git-remote-testgit.py
> +++ b/git-remote-testgit.py
> @@ -31,6 +31,11 @@ from git_remote_helpers.git.exporter import GitExporter
> from git_remote_helpers.git.importer import GitImporter
> from git_remote_helpers.git.non_local import NonLocalGit
>
> +if sys.hexversion < 0x01050200:
> + # os.makedirs() is the limiter
> + sys.stderr.write("git-remote-testgit.py: requires Python 1.5.2 or later.")
> + sys.exit(1)
> +
This one, though, is a bit of a lie because git_remote_helpers
needs 2.4, and you add that version enforcement in the library.
I assume what you're trying to do here is to make the
version-related failures more explicit, rather than have users
parse an ImportError traceback, e.g. That seems somewhat useful
for people with ancient installs.
But what about the high-end of the version range? I'm pretty
sure most of these scripts will throw syntax errors on >= 3.0,
how should we catch that before users see it?
-- Pete
^ permalink raw reply
* Re: Find the starting point of a local branch
From: Nguyen Thai Ngoc Duy @ 2012-12-24 11:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Tomas Carnecky, Seth Robertson, Woody Wu, git
In-Reply-To: <7vmwx4newy.fsf@alter.siamese.dyndns.org>
On Mon, Dec 24, 2012 at 1:27 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
>
>> On Mon, Dec 24, 2012 at 12:34 PM, Tomas Carnecky
>> <tomas.carnecky@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?
I looked briefly at reflog before writing my previous mail and noticed
that when I create a new branch (usually using "git checkout -b branch
ref") it does not record the base commit.
> 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.
We could at least invalidate the recorded base in reflog and let user
define a new one (I hope).
--
Duy
^ permalink raw reply
* Re: Find the starting point of a local branch
From: Nguyen Thai Ngoc Duy @ 2012-12-24 11:16 UTC (permalink / raw)
To: Jeff King; +Cc: Seth Robertson, Woody Wu, git
In-Reply-To: <20121224061938.GA25186@sigill.intra.peff.net>
On Mon, Dec 24, 2012 at 1:19 PM, Jeff King <peff@peff.net> wrote:
> 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.
Rebasing is exactly why I want this. Merge base works most of the time
until you rewrite upstream (which I do sometimes). There are also
cases when I create a branch without upstream, or when upstream is
renamed. Still, making "rebase -i --topic" == "rebase -i $(git
merge-base HEAD @{upstream})" would be cool.
--
Duy
^ permalink raw reply
* Re: Find the starting point of a local branch
From: Kevin @ 2012-12-24 9:12 UTC (permalink / raw)
To: Woody Wu; +Cc: Seth Robertson, git
In-Reply-To: <20121224073103.GA10793@zuhnb712>
On Mon, Dec 24, 2012 at 8:31 AM, Woody Wu <narkewoody@gmail.com> wrote:
> 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.
Each commit refers to it's parent. If you take a branch, and keep
following the first parent of the commits, you will finally reach the
root commit (the first commit made). You don't see any branches, it's
just one straight line. That's why git can't tell you where a branch
started, because it all looks like a single branch to git.
With merge-base, you basically give git two branches, and git finds
the first ancestor that is common to both branches.
See [1] for an example. If you follow the arrows from branch a, you
get from E to A (note that commit C doesn't know about commit F
pointing to it). So it looks like there is only a single branch.
If you do git merge-base a b, git sees both branches have commit C in
common, and reports that as the merge-base.
[1]: http://g.jk.gs/9W.png
^ permalink raw reply
* Re: Find the starting point of a local branch
From: Woody Wu @ 2012-12-24 7:31 UTC (permalink / raw)
To: Seth Robertson; +Cc: git
In-Reply-To: <201212240409.qBO49wkV020768@no.baka.org>
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.
^ permalink raw reply
* Re: [PATCH 2/2] learn to pick/revert into unborn branch
From: Martin von Zweigbergk @ 2012-12-24 7:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Ramkumar Ramachandra
In-Reply-To: <7v4njcpof8.fsf@alter.siamese.dyndns.org>
On Sun, Dec 23, 2012 at 11:18 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Martin von Zweigbergk <martinvonz@gmail.com> writes:
>> On Sat, Dec 22, 2012 at 7:24 PM, Junio C Hamano <gitster@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).
^ permalink raw reply
* Re: Find the starting point of a local branch
From: Junio C Hamano @ 2012-12-24 6:27 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Tomas Carnecky, Seth Robertson, Woody Wu, git
In-Reply-To: <CACsJy8DkA-J+ds1eHBqrRyiZrOigORTtxVeEQpZjGHrBR+QjCQ@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> On Mon, Dec 24, 2012 at 12:34 PM, Tomas Carnecky
> <tomas.carnecky@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.
^ permalink raw reply
* Re: Find the starting point of a local branch
From: Jeff King @ 2012-12-24 6:19 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Seth Robertson, Woody Wu, git
In-Reply-To: <CACsJy8CNd3W_WUMbZ1QZ4ReZ5ziX90QejK9mh1TMs0ig33kGMw@mail.gmail.com>
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
^ permalink raw reply
* Re: Find the starting point of a local branch
From: Nguyen Thai Ngoc Duy @ 2012-12-24 5:45 UTC (permalink / raw)
To: Tomas Carnecky; +Cc: Seth Robertson, Woody Wu, git
In-Reply-To: <1356327291-ner-6552@calvin>
On Mon, Dec 24, 2012 at 12:34 PM, Tomas Carnecky
<tomas.carnecky@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
^ permalink raw reply
* Re: Find the starting point of a local branch
From: Tomas Carnecky @ 2012-12-24 5:34 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy, Seth Robertson; +Cc: Woody Wu, git
In-Reply-To: <CACsJy8CNd3W_WUMbZ1QZ4ReZ5ziX90QejK9mh1TMs0ig33kGMw@mail.gmail.com>
On Mon, 24 Dec 2012 12:28:45 +0700, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> On Mon, Dec 24, 2012 at 11:09 AM, Seth Robertson <in-gitvger@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>?
^ permalink raw reply
* Re: Find the starting point of a local branch
From: Nguyen Thai Ngoc Duy @ 2012-12-24 5:28 UTC (permalink / raw)
To: Seth Robertson; +Cc: Woody Wu, git
In-Reply-To: <201212240409.qBO49wkV020768@no.baka.org>
On Mon, Dec 24, 2012 at 11:09 AM, Seth Robertson <in-gitvger@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
^ permalink raw reply
* Re: [PATCH] Python scripts audited for minimum compatible version and checks added.
From: Eric S. Raymond @ 2012-12-24 5:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7vr4mgnj2v.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com>:
> Junio C Hamano <gitster@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 < 0x02040000:
> > # 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>
^ permalink raw reply
* Re: [PATCH] Python scripts audited for minimum compatible version and checks added.
From: Junio C Hamano @ 2012-12-24 4:57 UTC (permalink / raw)
To: esr; +Cc: Jeff King, git
In-Reply-To: <7vk3sc2hx9.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@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 < 0x02040000:
> # 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.
^ permalink raw reply
* Re: Find the starting point of a local branch
From: Seth Robertson @ 2012-12-24 4:09 UTC (permalink / raw)
To: Woody Wu; +Cc: git
In-Reply-To: <20121224035825.GA17203@zuhnb712>
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
^ permalink raw reply
* Find the starting point of a local branch
From: Woody Wu @ 2012-12-24 3:58 UTC (permalink / raw)
To: git
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.
^ permalink raw reply
* Re: cvsps, parsecvs, svn2git and the CVS exporter mess
From: Eric S. Raymond @ 2012-12-23 22:45 UTC (permalink / raw)
To: Heiko Voigt
Cc: Yann Dirson, Michael Haggerty, Antoine Pelisse, Bart Massey,
Keith Packard, David Mansfield, git
In-Reply-To: <20121223202111.GB29354@book-mint>
Heiko Voigt <hvoigt@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>
^ permalink raw reply
* Re: [PATCH 2/2] learn to pick/revert into unborn branch
From: Philip Oakley @ 2012-12-23 20:27 UTC (permalink / raw)
To: Junio C Hamano, Christian Couder
Cc: Martin von Zweigbergk, Git List, Ramkumar Ramachandra
In-Reply-To: <7vzk14o9sk.fsf@alter.siamese.dyndns.org>
From: "Junio C Hamano" <gitster@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 <martinvonz@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.couder@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
^ permalink raw reply
* Re: cvsps, parsecvs, svn2git and the CVS exporter mess
From: Heiko Voigt @ 2012-12-23 20:21 UTC (permalink / raw)
To: Eric S. Raymond
Cc: Yann Dirson, Michael Haggerty, Antoine Pelisse, Bart Massey,
Keith Packard, David Mansfield, git
In-Reply-To: <20121222173649.04C5B44119@snark.thyrsus.com>
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
^ permalink raw reply
* Re: Re: Re: Re: Change in cvsps maintainership, abd a --fast-export option
From: Heiko Voigt @ 2012-12-23 19:57 UTC (permalink / raw)
To: Eric S. Raymond; +Cc: Michael Haggerty, git
In-Reply-To: <20121222141519.GA2080@thyrsus.com>
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
^ permalink raw reply
* Re: [PATCH 2/2] learn to pick/revert into unborn branch
From: Junio C Hamano @ 2012-12-23 19:35 UTC (permalink / raw)
To: Martin von Zweigbergk; +Cc: git, Ramkumar Ramachandra
In-Reply-To: <7v4njcpof8.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@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.
^ permalink raw reply
* Re: [PATCH 2/2] learn to pick/revert into unborn branch
From: Junio C Hamano @ 2012-12-23 19:20 UTC (permalink / raw)
To: Christian Couder; +Cc: Martin von Zweigbergk, git, Ramkumar Ramachandra
In-Reply-To: <CAP8UFD0GsqPSk-WstydjZHXc5WSmDJimfRcx4Mn7Uyw0s3LdpA@mail.gmail.com>
Christian Couder <christian.couder@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'?"
^ permalink raw reply
* Re: [PATCH 2/2] learn to pick/revert into unborn branch
From: Junio C Hamano @ 2012-12-23 19:18 UTC (permalink / raw)
To: Martin von Zweigbergk; +Cc: git, Ramkumar Ramachandra
In-Reply-To: <CANiSa6i0-Z=FkPnSJxgT+3ABHTzgOTNNNUb=wHQpm2DKAN_UOw@mail.gmail.com>
Martin von Zweigbergk <martinvonz@gmail.com> writes:
> On Sat, Dec 22, 2012 at 7:24 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Martin von Zweigbergk <martinvonz@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".
^ permalink raw reply
* Using Eclipse git plugin
From: Dennis Putnam @ 2012-12-23 16:16 UTC (permalink / raw)
To: git@vger.kernel.org
[-- Attachment #1: Type: text/plain, Size: 488 bytes --]
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.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]
^ permalink raw reply
* Re: Push Windows to Linux Repository Problem
From: Dennis Putnam @ 2012-12-23 15:28 UTC (permalink / raw)
Cc: git@vger.kernel.org
In-Reply-To: <m27go9dtnn.fsf@linux-m68k.org>
[-- Attachment #1: Type: text/plain, Size: 635 bytes --]
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 <dap1@bellsouth.net> writes:
>
>> I keep getting "fatal: Could not read from remote repository."
> Can you "git ls-remote" the repository?
>
> Andreas.
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]
^ permalink raw reply
* Re: Push Windows to Linux Repository Problem
From: Andreas Schwab @ 2012-12-23 9:06 UTC (permalink / raw)
To: Dennis Putnam; +Cc: git@vger.kernel.org
In-Reply-To: <50D65090.4010303@bellsouth.net>
Dennis Putnam <dap1@bellsouth.net> writes:
> I keep getting "fatal: Could not read from remote repository."
Can you "git ls-remote" the repository?
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ 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