* 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
* Re: [PATCH 2/2] learn to pick/revert into unborn branch
From: Christian Couder @ 2012-12-23 7:01 UTC (permalink / raw)
To: Martin von Zweigbergk; +Cc: Junio C Hamano, git, Ramkumar Ramachandra
In-Reply-To: <CANiSa6i0-Z=FkPnSJxgT+3ABHTzgOTNNNUb=wHQpm2DKAN_UOw@mail.gmail.com>
On Sun, Dec 23, 2012 at 7:24 AM, Martin von Zweigbergk
<martinvonz@gmail.com> wrote:
>
> 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.
>
> 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.
> 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 agree that it would be nice if it worked.
Thanks,
Christian.
^ permalink raw reply
* Re: [PATCH 2/2] learn to pick/revert into unborn branch
From: Martin von Zweigbergk @ 2012-12-23 6:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Ramkumar Ramachandra
In-Reply-To: <7vr4mhpi0l.fsf@alter.siamese.dyndns.org>
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. In my
opinion, whenever possible, operations on an unborn branch should
behave exactly as they would on an arbitrary commit whose tree just
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, but that
almost seems like an implementation detail, i.e whether we're adding a
parent or adding no parent (when on unborn branch) to the list of
parents.
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 think many users, like me,
think of unborn branches as having an empty tree, rather than being a
special state before history is created. Sure, such thinking is not
technically correct, but it still seems to be some people's intuition
(including mine).
>> Cherry-picking anything other than a commit that only adds files, will
>> naturally result in conflicts. Similarly, revert also works, but will
>> result in conflicts unless the specified revision only deletes files.
>
> You may be able to make it "work" for some definition of "work", but
> I am not sure how useful it is.
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.
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.
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 could resend as part of my rebase series (called mz/rebase-range at
some point) once that's done. Then we can discuss another solution in
the scope of that series if we don't agree on allowing on cherry-pick
on an unborn branch.
Btw, I have another series, which I'll send after 1.8.1, that teaches
"git reset" to work on an unborn branch (among other things). We might
want to decide to support both or neither of the commands on an unborn
branch.
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.
>
> 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?
>
> I can understand that it may sometimes make sense to do
>
> $ git show --diff-filter=A $that_commit | git apply
>
> as a way to further update the uncommitted state you have in the
> working tree, so I can sort of buy that --no-commit case might make
> some sense (but if you make a commit after "cherry-pick --no-commit",
> you still get the log message from that commit, which does not
> explain the other things you have in your working tree) in a limited
> situation.
>
> It seems to me that the only case that may make sense is to grab the
> contents from an existing tree, which might be better served with
>
> $ git checkout $that_commit -- $these_paths_I_am_interested_in
>
>> Cherry-picking anything other than a commit that only adds files, will
>> naturally result in conflicts. Similarly, revert also works, but will
>> result in conflicts unless the specified revision only deletes files.
>
> You may be able to make it "work" for some definition of "work", but
> I am not sure how useful it is.
>
> Puzzled...
>
^ permalink raw reply
* Re: [PATCH 2/2] log: add log.mailmap configuration option
From: Junio C Hamano @ 2012-12-23 4:26 UTC (permalink / raw)
To: Antoine Pelisse; +Cc: git
In-Reply-To: <1356195512-4846-3-git-send-email-apelisse@gmail.com>
Antoine Pelisse <apelisse@gmail.com> writes:
> This patch provides a new configuration option 'log.mailmap' to
> automatically use the --use-mailmap option from git-show, git-log and
> git-whatchanged commands.
>
> Signed-off-by: Antoine Pelisse <apelisse@gmail.com>
> ---
> I'm wondering if it would be needed to add a no-use-mailmap option to
> log command so that it can cancel this configuration option.
The usual way for adding a new feature is to add a --enable-feature
long-option without any configuration variable to let users try it
out in the field, and then add the configuration to let it be
default for users who opt in. The first step should also allow a
command line option to disable (which should come for free if you
use parse-options API correctly).
> Documentation/config.txt | 4 ++++
> builtin/log.c | 8 +++++++-
> t/t4203-mailmap.sh | 24 ++++++++++++++++++++++++
> 3 files changed, 35 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index bf8f911..226362a 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -1509,6 +1509,10 @@ log.showroot::
> Tools like linkgit:git-log[1] or linkgit:git-whatchanged[1], which
> normally hide the root commit will now show it. True by default.
>
> +log.mailmap::
> + If true, makes linkgit:git-log[1], linkgit:git-show[1], and
> + linkgit:git-whatchanged[1] assume `--use-mailmap`.
> +
> mailmap.file::
> The location of an augmenting mailmap file. The default
> mailmap, located in the root of the repository, is loaded
> diff --git a/builtin/log.c b/builtin/log.c
> index d2bd8ce..f6936ff 100644
> --- a/builtin/log.c
> +++ b/builtin/log.c
> @@ -31,6 +31,7 @@ static int default_abbrev_commit;
> static int default_show_root = 1;
> static int decoration_style;
> static int decoration_given;
> +static int use_mailmap;
> static const char *fmt_patch_subject_prefix = "PATCH";
> static const char *fmt_pretty;
>
> @@ -138,7 +139,7 @@ static void cmd_log_init_finish(int argc, const char **argv, const char *prefix,
> if (source)
> rev->show_source = 1;
>
> - if (mailmap) {
> + if (mailmap || use_mailmap) {
> rev->mailmap = xcalloc(1, sizeof(struct string_list));
> read_mailmap(rev->mailmap, NULL);
> }
> @@ -358,6 +359,11 @@ static int git_log_config(const char *var, const char *value, void *cb)
> }
> if (!prefixcmp(var, "color.decorate."))
> return parse_decorate_color_config(var, 15, value);
> + if (!strcmp(var, "log.mailmap")) {
> + use_mailmap = git_config_bool(var, value);
> + return 0;
> + }
> +
> if (grep_config(var, value, cb) < 0)
> return -1;
> return git_diff_ui_config(var, value, cb);
> diff --git a/t/t4203-mailmap.sh b/t/t4203-mailmap.sh
> index e16187f..7d4d31c 100755
> --- a/t/t4203-mailmap.sh
> +++ b/t/t4203-mailmap.sh
> @@ -255,6 +255,21 @@ test_expect_success 'Log output with --use-mailmap' '
> '
>
> cat >expect <<\EOF
> +Author: CTO <cto@company.xx>
> +Author: Santa Claus <santa.claus@northpole.xx>
> +Author: Santa Claus <santa.claus@northpole.xx>
> +Author: Other Author <other@author.xx>
> +Author: Other Author <other@author.xx>
> +Author: Some Dude <some@dude.xx>
> +Author: A U Thor <author@example.com>
> +EOF
> +
> +test_expect_success 'Log output with log.mailmap' '
> + git -c log.mailmap=True log | grep Author >actual &&
> + test_cmp expect actual
> +'
> +
> +cat >expect <<\EOF
> Author: Santa Claus <santa.claus@northpole.xx>
> Author: Santa Claus <santa.claus@northpole.xx>
> EOF
> @@ -263,6 +278,15 @@ test_expect_success 'Grep author with --use-mailmap' '
> git log --use-mailmap --author Santa | grep Author >actual &&
> test_cmp expect actual
> '
> +cat >expect <<\EOF
> +Author: Santa Claus <santa.claus@northpole.xx>
> +Author: Santa Claus <santa.claus@northpole.xx>
> +EOF
> +
> +test_expect_success 'Grep author with log.mailmap' '
> + git -c log.mailmap=True log --author Santa | grep Author >actual &&
> + test_cmp expect actual
> +'
>
> >expect
>
> --
> 1.7.9.5
^ permalink raw reply
* Re: [PATCH 2/2] learn to pick/revert into unborn branch
From: Junio C Hamano @ 2012-12-23 4:02 UTC (permalink / raw)
To: Martin von Zweigbergk; +Cc: git, Ramkumar Ramachandra
In-Reply-To: <1356117013-20613-2-git-send-email-martinvonz@gmail.com>
Martin von Zweigbergk <martinvonz@gmail.com> writes:
> @@ -435,8 +437,9 @@ static int do_pick_commit(struct commit *commit, struct replay_opts *opts)
> else
> parent = commit->parents->item;
>
> - if (opts->allow_ff && parent && !hashcmp(parent->object.sha1, head))
> - return fast_forward_to(commit->object.sha1, head);
> + if (opts->allow_ff &&
> + (parent && !hashcmp(parent->object.sha1, head) || !parent && unborn))
Style (from GNU); please avoid (A && B || C) and spell the
precedence between && and || explicitly, i.e.
((A && B) || C)
> + git rm --cached -r . &&
> + rm -rf * &&
Not "git rm -rf ." and as two separate steps?
^ permalink raw reply
* Re: [PATCH 2/2] learn to pick/revert into unborn branch
From: Junio C Hamano @ 2012-12-23 3:24 UTC (permalink / raw)
To: Martin von Zweigbergk; +Cc: git, Ramkumar Ramachandra
In-Reply-To: <1356117013-20613-2-git-send-email-martinvonz@gmail.com>
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?
I can understand that it may sometimes make sense to do
$ git show --diff-filter=A $that_commit | git apply
as a way to further update the uncommitted state you have in the
working tree, so I can sort of buy that --no-commit case might make
some sense (but if you make a commit after "cherry-pick --no-commit",
you still get the log message from that commit, which does not
explain the other things you have in your working tree) in a limited
situation.
It seems to me that the only case that may make sense is to grab the
contents from an existing tree, which might be better served with
$ git checkout $that_commit -- $these_paths_I_am_interested_in
> Cherry-picking anything other than a commit that only adds files, will
> naturally result in conflicts. Similarly, revert also works, but will
> result in conflicts unless the specified revision only deletes files.
You may be able to make it "work" for some definition of "work", but
I am not sure how useful it is.
Puzzled...
^ permalink raw reply
* [ANNOUNCE] Git v1.8.1-rc3
From: Junio C Hamano @ 2012-12-23 2:53 UTC (permalink / raw)
To: git; +Cc: Linux Kernel
A release candidate Git v1.8.1-rc3 is now available for testing
at the usual places.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
c0ad509fb6a91babc43cf790405dbd95c68c986f git-1.8.1.rc3.tar.gz
8396960d1e4384a861f98cdd29e2b2693152f7c9 git-htmldocs-1.8.1.rc3.tar.gz
f73c52e016ddecac6ee0e6a5852b763e13e444a9 git-manpages-1.8.1.rc3.tar.gz
Note that the toolchain used to preformat the latter two tarballs
has been updated (I am using AsciiDoc 8.6.8 now), which hopefully
have fixed the malformatted pages Gentoo folks noticed in some pages
that use ``pretty quotes''.
The following public repositories all have a copy of the v1.8.1-rc3
tag and the master branch that the tag points at:
url = git://repo.or.cz/alt-git.git
url = https://code.google.com/p/git-core/
url = git://git.sourceforge.jp/gitroot/git-core/git.git
url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
(not) url = https://github.com/gitster/git
Git v1.8.1 Release Notes (draft)
========================
Backward compatibility notes
----------------------------
In the next major release (not *this* one), we will change the
behavior of the "git push" command.
When "git push [$there]" does not say what to push, we have used the
traditional "matching" semantics so far (all your branches were sent
to the remote as long as there already are branches of the same name
over there). We will use the "simple" semantics that pushes the
current branch to the branch with the same name, only when the current
branch is set to integrate with that remote branch. There is a user
preference configuration variable "push.default" to change this, and
"git push" will warn about the upcoming change until you set this
variable in this release.
"git branch --set-upstream" is deprecated and may be removed in a
relatively distant future. "git branch [-u|--set-upstream-to]" has
been introduced with a saner order of arguments to replace it.
Updates since v1.8.0
--------------------
UI, Workflows & Features
* Command-line completion scripts for tcsh and zsh have been added.
* A new remote-helper interface for Mercurial has been added to
contrib/remote-helpers.
* We used to have a workaround for a bug in ancient "less" that
causes it to exit without any output when the terminal is resized.
The bug has been fixed in "less" version 406 (June 2007), and the
workaround has been removed in this release.
* Some documentation pages that used to ship only in the plain text
format are now formatted in HTML as well.
v * "git-prompt" scriptlet (in contrib/completion) can be told to paint
pieces of the hints in the prompt string in colors.
* A new configuration variable "diff.context" can be used to
give the default number of context lines in the patch output, to
override the hardcoded default of 3 lines.
* When "git checkout" checks out a branch, it tells the user how far
behind (or ahead) the new branch is relative to the remote tracking
branch it builds upon. The message now also advises how to sync
them up by pushing or pulling. This can be disabled with the
advice.statusHints configuration variable.
* "git config --get" used to diagnose presence of multiple
definitions of the same variable in the same configuration file as
an error, but it now applies the "last one wins" rule used by the
internal configuration logic. Strictly speaking, this may be an
API regression but it is expected that nobody will notice it in
practice.
* "git log -p -S<string>" now looks for the <string> after applying
the textconv filter (if defined); earlier it inspected the contents
of the blobs without filtering.
* "git format-patch" learned the "--notes=<ref>" option to give
notes for the commit after the three-dash lines in its output.
* "git log --grep=<pcre>" learned to honor the "grep.patterntype"
configuration set to "perl".
* "git replace -d <object>" now interprets <object> as an extended
SHA-1 (e.g. HEAD~4 is allowed), instead of only accepting full hex
object name.
* "git rm $submodule" used to punt on removing a submodule working
tree to avoid losing the repository embedded in it. Because
recent git uses a mechanism to separate the submodule repository
from the submodule working tree, "git rm" learned to detect this
case and removes the submodule working tree when it is safe to do so.
* "git send-email" used to prompt for the sender address, even when
the committer identity is well specified (e.g. via user.name and
user.email configuration variables). The command no longer gives
this prompt when not necessary.
* "git send-email" did not allow non-address garbage strings to
appear after addresses on Cc: lines in the patch files (and when
told to pick them up to find more recipients), e.g.
Cc: Stable Kernel <stable@k.org> # for v3.2 and up
The command now strips " # for v3.2 and up" part before adding the
remainder of this line to the list of recipients.
* "git submodule add" learned to add a new submodule at the same
path as the path where an unrelated submodule was bound to in an
existing revision via the "--name" option.
* "git submodule sync" learned the "--recursive" option.
* "diff.submodule" configuration variable can be used to give custom
default value to the "git diff --submodule" option.
* "git symbolic-ref" learned the "-d $symref" option to delete the
named symbolic ref, which is more intuitive way to spell it than
"update-ref -d --no-deref $symref".
Foreign Interface
* "git cvsimport" can be told to record timezones (other than GMT)
per-author via its author info file.
* The remote helper interface to interact with subversion
repositories (one of the GSoC 2012 projects) has been merged.
* The documentation for git(1) was pointing at a page at an external
site for the list of authors that no longer existed. The link has
been updated to point at an alternative site.
Performance, Internal Implementation, etc.
* Compilation on Cygwin with newer header files are supported now.
* A couple of low-level implementation updates on MinGW.
* The logic to generate the initial advertisement from "upload-pack"
(i.e. what is invoked by "git fetch" on the other side of the
connection) to list what refs are available in the repository has
been optimized.
* The logic to find set of attributes that match a given path has
been optimized.
* Use preloadindex in "git diff-index" and "git update-index", which
has a nice speedup on systems with slow stat calls (and even on
Linux).
Also contains minor documentation updates and code clean-ups.
Fixes since v1.8.0
------------------
Unless otherwise noted, all the fixes since v1.8.0 in the maintenance
track are contained in this release (see release notes to them for
details).
* The configuration parser had an unnecessary hardcoded limit on
variable names that was not checked consistently.
* The "say" function in the test scaffolding incorrectly allowed
"echo" to interpret "\a" as if it were a C-string asking for a
BEL output.
* "git mergetool" feeds /dev/null as a common ancestor when dealing
with an add/add conflict, but p4merge backend cannot handle
it. Work it around by passing a temporary empty file.
* "git log -F -E --grep='<ere>'" failed to use the given <ere>
pattern as extended regular expression, and instead looked for the
string literally.
* "git grep -e pattern <tree>" asked the attribute system to read
"<tree>:.gitattributes" file in the working tree, which was
nonsense.
* A symbolic ref refs/heads/SYM was not correctly removed with "git
branch -d SYM"; the command removed the ref pointed by SYM
instead.
* Update "remote tracking branch" in the documentation to
"remote-tracking branch".
* "git pull --rebase" run while the HEAD is detached tried to find
the upstream branch of the detached HEAD (which by definition
does not exist) and emitted unnecessary error messages.
* The refs/replace hierarchy was not mentioned in the
repository-layout docs.
* Various rfc2047 quoting issues around a non-ASCII name on the
From: line in the output from format-patch have been corrected.
* Sometimes curl_multi_timeout() function suggested a wrong timeout
value when there is no file descriptor to wait on and the http
transport ended up sleeping for minutes in select(2) system call.
A workaround has been added for this.
* For a fetch refspec (or the result of applying wildcard on one),
we always want the RHS to map to something inside "refs/"
hierarchy, but the logic to check it was not exactly right.
(merge 5c08c1f jc/maint-fetch-tighten-refname-check later to maint).
* "git diff -G<pattern>" did not honor textconv filter when looking
for changes.
* Some HTTP servers ask for auth only during the actual packing phase
(not in ls-remote phase); this is not really a recommended
configuration, but the clients used to fail to authenticate with
such servers.
(merge 2e736fd jk/maint-http-half-auth-fetch later to maint).
* "git p4" used to try expanding malformed "$keyword$" that spans
across multiple lines.
* Syntax highlighting in "gitweb" was not quite working.
* RSS feed from "gitweb" had a xss hole in its title output.
* "git config --path $key" segfaulted on "[section] key" (a boolean
"true" spelled without "=", not "[section] key = true").
* "git checkout -b foo" while on an unborn branch did not say
"Switched to a new branch 'foo'" like other cases.
* Various codepaths have workaround for a common misconfiguration to
spell "UTF-8" as "utf8", but it was not used uniformly. Most
notably, mailinfo (which is used by "git am") lacked this support.
* We failed to mention a file without any content change but whose
permission bit was modified, or (worse yet) a new file without any
content in the "git diff --stat" output.
* When "--stat-count" hides a diffstat for binary contents, the total
number of added and removed lines at the bottom was computed
incorrectly.
* When "--stat-count" hides a diffstat for unmerged paths, the total
number of affected files at the bottom of the "diff --stat" output
was computed incorrectly.
* "diff --shortstat" miscounted the total number of affected files
when there were unmerged paths.
* "update-ref -d --deref SYM" to delete a ref through a symbolic ref
that points to it did not remove it correctly.
----------------------------------------------------------------
Changes since v1.8.1-rc2 are as follows:
Adam Spiers (2):
SubmittingPatches: add convention of prefixing commit messages
Documentation: move support for old compilers to CodingGuidelines
Chris Rorvick (2):
Documentation/git-checkout.txt: clarify usage
Documentation/git-checkout.txt: document 70c9ac2 behavior
Jeff King (5):
.mailmap: match up some obvious names/emails
.mailmap: fix broken entry for Martin Langhoff
.mailmap: normalize emails for Jeff King
.mailmap: normalize emails for Linus Torvalds
contrib: update stats/mailmap script
John Keeping (1):
Documentation: don't link to example mail addresses
Junio C Hamano (5):
fetch --tags: clarify documentation
README: it does not matter who the current maintainer is
t7004: do not create unneeded gpghome/gpg.conf when GPG is not used
Documentation: Describe "git diff <blob> <blob>" separately
Git 1.8.1-rc3
Nguyễn Thái Ngọc Duy (1):
index-format.txt: clarify what is "invalid"
Sebastian Leske (4):
git-svn: Document branches with at-sign(@).
git-svn: Recommend use of structure options.
git-svn: Expand documentation for --follow-parent
git-svn: Note about tags.
Sitaram Chamarty (1):
clarify -M without % symbol in diff-options
Stefano Lattarini (1):
README: Git is released under the GPLv2, not just "the GPL"
Thomas Ackermann (3):
Remove misleading date from api-index-skel.txt
Remove duplicate entry in ./Documentation/Makefile
Move ./technical/api-command.txt to ./howto/new-command.txt
^ permalink raw reply
* Re: [PATCH v2] mergetools/p4merge: Honor $TMPDIR for the /dev/null placeholder
From: David Aguilar @ 2012-12-23 1:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeremy Morton, git
In-Reply-To: <CAJDDKr54XBtU4J-A8T9LwXAPL6E8M2_0kaTxH_-LZCAR0fwN+g@mail.gmail.com>
On Sat, Dec 22, 2012 at 1:56 PM, David Aguilar <davvid@gmail.com> wrote:
> FWIW I'm seeing a "Bus Error" when doing "git update-index --refresh"
> in a repository with large files on a 32bit machine. I'm not sure if
> that counts as a regression since the same error occurs in 1.7.10.4
> (debian testing).
>
> I'll start another thread on this topic in case anyone is interested.
Nevermind. The machine is an old salvaged laptop and its disk
probably has some bad blocks.
I wasn't able to copy the bad repo since 'cp' kept failing to
copy the index file. I/O errors.. After deleting the borked
index the problems went away, so I'll chalk this up to
failing hardware. Sorry for the false alarm.
--
David
^ permalink raw reply
* Re: Pushing symbolic references to remote repositories?
From: Sitaram Chamarty @ 2012-12-23 1:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andreas Schwab, Dun Peal, Shawn Pearce, Git ML
In-Reply-To: <7vy5gqq6w8.fsf@alter.siamese.dyndns.org>
On Sat, Dec 22, 2012 at 11:57 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Andreas Schwab <schwab@linux-m68k.org> writes:
>
>> This is not limited to HEAD, any ref may want to be set up as a symref
>> at a remote repo. For example, I want to set up a symref master ->
>> trunk at a repository I have no shell access to.
>
> That is exactly the "hosting side does not give you an easy way so
> pushing seems to be one plausible but not necessarily has to be the
> only way" case, so it is already covered in the discussion.
Just a minor FYI (and at the risk of tooting my own horn) but if the
hosting side is gitolite, you can.set it up so that any user with
write permissions to the repo can run 'git symbolic-ref' with
arbitrary arguments even though he does not get a shell.
The "-m <reason>" has some constraints because gitolite does not allow
a lot of characters in arguments to remote commands but that's mostly
useless unless you have core.logAllRefUpdates set anyway.
^ 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