* Re: Moving git
From: Todd Zullinger @ 2009-10-16 18:42 UTC (permalink / raw)
To: Richard Lee; +Cc: git
In-Reply-To: <25928820.post@talk.nabble.com>
[-- Attachment #1: Type: text/plain, Size: 893 bytes --]
Richard Lee wrote:
> The reason I had problem with git remote rm was because I was using
> version 1.5.2 as I installed it from yum. (This is what I hate about
> CentOS, all the repositories are old as dirt.)
Not that it's much newer, but if you use the EPEL repository, 1.5.5.6
is available.
> I compiled version 1.6.5 and the command was there.
And if it helps, the Fedora package is intended to be able to build
cleanly on CentOS as well -- though it depends on some macro settings
available in the buildsys-macros package found at:
http://buildsys.fedoraproject.org/buildgroups/rhel5/
...in the proper directory for your architecture.
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Every time I close the door on reality, it comes in through the
windows.
[-- Attachment #2: Type: application/pgp-signature, Size: 542 bytes --]
^ permalink raw reply
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Daniel Barkalow @ 2009-10-16 18:29 UTC (permalink / raw)
To: Julian Phillips
Cc: Björn Steinbrink, James Pickens, Jeff King, Junio C Hamano,
Nicolas Pitre, Jay Soffian, git
In-Reply-To: <alpine.LNX.2.00.0910161821230.30589@reaper.quantumfyre.co.uk>
On Fri, 16 Oct 2009, Julian Phillips wrote:
> It was the approach that I was trying to suggest rather than the actual
> commands. The point I was trying to make was how, as a user, I would be happy
> to git behave.
>
> So, I try to run fetch, git says "ooh, now that would be dangerous - you can
> force it happen by running "git foo", but you will then be in situation X,
> which you can then recover from by running "git bar", though you may need to
> run "git stash" to save any edits you have made" or something similar.
>
> Now as a user I know that I have tried to do something a bit unusual, but I
> don't have to run to the mailing list or #git saying "I just did X Y Z and
> everything is now FUBARed". I can even proceed to do the unusal thing, as git
> itself has given me the information I need to sort things out afterwards.
The thing is that that sequence shouldn't be unusual or dangerous or
require sorting things out afterwards. In the current version of git, it's
a completely normal thing to do that behaves nicely and does what the user
almost certainly wants. We *could* horribly break it, and then add
messages to tell the user they're doing something that's now horribly
broken, and tell the user how to cope with the fact that what they want to
do involves something that's horribly broken, and roll our eyes when users
who have only used working systems like SVN or git 1.6.X ignore the
message and can't figure out what's going on. Or we could just not break
it in the first place.
SVN doesn't think that your working directory is supposed to change when
someone else makes a commit. Git shouldn't think your working directory
should change when you find out that someone made a commit. If you want to
see now commits, you do "svn up" or "git checkout".
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH 3/3] Add proof-of-concept %[w(width,in1,in2)<<any-string>>%] implementation
From: Jakub Narebski @ 2009-10-16 18:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vk4yvuu79.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>> maybe "rewrap" would be a better name than "w"?
>
> Perhaps, but I do not know if wrap() is even better. The only reason I
> said w() here is because I saw you used w() and this is meant to be a
> superset replacement for it, as this can re-wrap anything, not just one
> particular field from the commit object.
wrap(initial_prefix, subsequent_prefix, columns) would for example
follow somewhat Text::Wrap syntax, together with 'fill'. With columns
being 0, not set, or negative it could simply indent result; this way
we finally would be able to get default git-log / git-rev-list format
using --pretty format.
I don't remember what were original parameters to w(72,4,8) means...
>
>> On Fri, 16 Oct 2009, Junio C Hamano wrote:
>>
>>> #1 "%[" introduces the nested string function.
>>>
>>> #2 After that, a name identifies what function to call.
>>>
>>> #3 The function parses its parameters ("(72,4,8)" in the above example),
>>> and makes a nested expansion on the remainder of the format string.
>>
>> Can't we parse it once, i.e. the first time?
>
> I may be missing the issue you are raising here, but it parses the string
> only once; it stuffs the expansion of the enclosed string into a separate
> buffer (while noting where it ends), applies the function to the result
> obtained in the separate buffer and appends the result of the function
> application to the main buffer, and the main expansion resumes where the
> nested one finished.
Do I understand it correctly that generic syntax is the following:
%[function(params) format specifiers]
which would run given function, with given extra parameters, on the
result of expansion of the rest of the group? That is a very
powerfull syntax... I wonder how other tools solved such problem...
BTW. can we have this also for git-for-each-ref format parameter?
Note that for single parameter we have different syntax (for
git-for-each-ref), namely
%(field:modifier)
which could be expanded to allow for parametrized modifiers with one
of the following:
%(field:modifier=param)
%(field:modifier[param])
%(field:modifier(param))
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Introduction and Wikipedia and Git Blame
From: jamesmikedupont @ 2009-10-16 18:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vbpk7w9qx.fsf@alter.siamese.dyndns.org>
On Fri, Oct 16, 2009 at 7:04 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>> Then I would make modified "texts" from the blob of the file in the
>> current revision and its parent revision, by inserting newlines after
>> every single byte (probably replacing the original newlines by other
>> values, such as \x01).
>>
>> The reason for this touchup is that the diff machinery in Git only handles
>> line-based diffs.
>>
>> Then you can parse the hunk headers, adjust the offsets accordingly,...
>
> I would agree that text converted to "byte-per-line" format would be the
> easiest way to re-use the diff engine, but if you go one more step, you
> can even reusel the blame engine as well. You convert the text into
> "byte-in-hex-and-lf" (e.g. "AB C\n" becomes "41\n42\n20\n43\n0a\n") and
> feed it into existing blame and have it produce script-readable output,
> instead of feeding that to your reinvention of blame using diff engine.
>
> You would need to postprocess the computed result (either by diff or
> blame) to lay out the final text output in either case anyway, and making
> the existing blame engine do the work for you would be a better approach,
> I think.
Please can you tell me what is the basic algorithm of the blame engine?
I will have to start reading code
How can it tell the author a given line and I like the idea of one
line per char, even the newlines would be encoded that way. If it is a
unicode char, it might be multibyte.
The script would get the blame per byte and then recode that into
something visible.
od the octal dump utility comes to mind,
od x1 -w1 will output the file in one byte widths.
Now what about the ability to just pipe the file via some tool and
then run blame on that. It would just start the line with the byte
offset and blame would emit the blame for that offset and emit the
text that is following it.
so for example :
od x1 -w1 somefile :
///////////////////////////////
Offset value
======= ======
0052752 065347
0052754 030356
0052756 035741
0052760 136302
0052762 035346
Here we see the lines are 0052760 - 0052762 =2 apart.
and then if you want wider diffs :
od some file
////////////////////////////////////////////
Offset values
======= ====== ====== ====== ====== ====== ====== ====== ======
0074520 051754 162613 057705 155520 047032 043654 175550 062704
0074540 164400 060340 123434 030350 040457 136010 042270 170525
0074560 165053 124677 125776 031370 000006 102076 060060 052434
0074600 176452 140240 074007 130113 100424 020010 130773 103467
0074620 052776 052421 021544 101357 120035 107562 072641 053636
Here we see the lines are 0074520 - 0074540 = 20 apart.
That way the blame tool will not be concerned with the formatting or
content, the users can write filters like they want, and blame would
only expect a byte offset...
That way, we could write something like this :
grep -b x Test.xml
0:<?xml version="1.0" encoding="UTF-8"?>
39:<gpx
107: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
then we would get blames for those byte offsets, very simple.
We could reduce this down to : make blame take a list of byte positions.
grep -b \n Test.gpx would be the standard behavior, emit the blame per newline.
mike
^ permalink raw reply
* Re: [PATCH RFC] git describe without refs distinguishes dirty working tree
From: Shawn O. Pearce @ 2009-10-16 17:39 UTC (permalink / raw)
To: Jean Privat; +Cc: git
In-Reply-To: <dffdbd190910160812h6d6a876el8261a622b5439b30@mail.gmail.com>
Jean Privat <jean@pryen.org> wrote:
> git describe without refs still works on HEAD but append "-dirty" if the
> working three is dirty. If the working tree is clean, nothing is appended.
>
> Previous behavior can be achieved by specifying "HEAD".
>
> Many build scripts use `git describe` to produce a version number.
> However, additional git commands are required to distinguish builds done
> with a clean tree from builds done with a dirty tree.
> This patch helps the writing of these scripts since `git describe` do
> the intended thing.
>
> This new behavior could affect existing scripts by producing version
> number like v1.0.4-14-g2414721-dirty-dirty.
> These scripts could be easily fixed by explicitly using HEAD when calling
> `git describe` and works with any version of git.
>
> Signed-off-by: Jean Privat <jean@pryen.org>
Yea, I think this is reasonable and sane thing to do.
Acked-by: Shawn O. Pearce <spearce@spearce.org>
> Note that documentation of `git describe` did not mentioned the behavior
> of the command when no committish is specified.
> However, since it is still a behavior change. If the patch is accepted,
> it could target version 1.7.
Yea, 1.7 may be safer for this, but also many scripts are based
on the GIT-VERSION-GEN in git.git which uses HEAD as an explicit
argument. So they might actually be OK with this change.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Julian Phillips @ 2009-10-16 17:31 UTC (permalink / raw)
To: Björn Steinbrink
Cc: Daniel Barkalow, James Pickens, Jeff King, Junio C Hamano,
Nicolas Pitre, Jay Soffian, git
In-Reply-To: <20091016143041.GA11821@atjola.homenet>
On Fri, 16 Oct 2009, Bj?rn Steinbrink wrote:
> On 2009.10.16 13:15:35 +0100, Julian Phillips wrote:
>> On Thu, 15 Oct 2009, Daniel Barkalow wrote:
>>
>>> On Thu, 15 Oct 2009, James Pickens wrote:
>>>
>>>> How about not detaching the head at all if the user checks out any ref, and
>>>> reject commits if he checked out a tag or remote branch. For example:
>>>>
>>>> $ git checkout origin/master
>>>> $ git status
>>>> # On branch origin/master
>>>> $ git commit ;# complain
>>>
>>> $ git checkout origin/master
>>> $ git fetch
>>> $ git checkout origin/next
>>> Uncommited file '...' would be overwritten.
>>
>> How about:
>>
>> $ git checkout origin/master
>> $ git fetch
>> Refusing to fetch, as it would update a checkedout branch
>> "git fetch -f" will force the update, but you will need to run "git
>> reset --hard HEAD" to update your checkout to match.
>
> That would redefine -f (currently means "allow non-fast-forward
> updates"), the flag that allows the checked out branch head to be
> updated is -u, --update-head-ok, and is for internal use only.
>
> And suggesting "reset --hard" seems wrong, that just kills any
> uncommitted changes.
Ok, so the commands were wrong. Not important.
It was the approach that I was trying to suggest rather than the actual
commands. The point I was trying to make was how, as a user, I would be
happy to git behave.
So, I try to run fetch, git says "ooh, now that would be dangerous - you
can force it happen by running "git foo", but you will then be in
situation X, which you can then recover from by running "git bar", though
you may need to run "git stash" to save any edits you have made" or
something similar.
Now as a user I know that I have tried to do something a bit unusual, but
I don't have to run to the mailing list or #git saying "I just did X Y Z
and everything is now FUBARed". I can even proceed to do the unusal
thing, as git itself has given me the information I need to sort things
out afterwards.
> And such uncommitted changes would be lost in the big "undo the fetch
> update" diff. So you'd have to do:
> git reset --soft HEAD@{1}
> git checkout --merge HEAD@{1}
>
> to keep them, while updating to the new state of the remote tracking
> branch. Not quite intuitive, is it?
I don't care what git has to do, I'm talking about the user experience -
if we have to write some new code to support it, that really isn't a
terribly hard thing to do. UIs should be driven down from the user
interaction not up from the implementation.
--
Julian
---
Captain: "Catalyzer's a nothing part, captain."
Mal: "It's nothing until you don't got one. Then it appears to be everything."
--Episode #8, "Out of Gas"
^ permalink raw reply
* Re: [PATCH RFC] git describe without refs distinguishes dirty working tree
From: Junio C Hamano @ 2009-10-16 17:26 UTC (permalink / raw)
To: Jean Privat; +Cc: git
In-Reply-To: <dffdbd190910160812h6d6a876el8261a622b5439b30@mail.gmail.com>
Jean Privat <jean@pryen.org> writes:
> ...
> This new behavior could affect existing scripts by producing version
> number like v1.0.4-14-g2414721-dirty-dirty.
> These scripts could be easily fixed by explicitly using HEAD when calling
> `git describe` and works with any version of git.
>
> Signed-off-by: Jean Privat <jean@pryen.org>
> ---
>
> Initially, I wanted to add an option `--worktree` that works on HEAD and
> appends "-dirty" when the working tree is dirty. After rethink I
> realized that users (me included) should prefer to describe the working
> tree by default, and only describe HEAD if HEAD was explicitly specified.
>
> Note that documentation of `git describe` did not mentioned the behavior
> of the command when no committish is specified.
> However, since it is still a behavior change. If the patch is accepted,
> it could target version 1.7.
> ---
> Documentation/git-describe.txt | 5 ++++-
> builtin-describe.c | 18 +++++++++++++++++-
> t/t6120-describe.sh | 8 ++++++++
> 3 files changed, 29 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt
> index b231dbb..c49ecc8 100644
> --- a/Documentation/git-describe.txt
> +++ b/Documentation/git-describe.txt
> @@ -8,7 +8,7 @@ git-describe - Show the most recent tag that is
> reachable from a commit
Here is an indication of a linewrapped and broken patch that discourages
me to look further.
As to the new _ability_, I think it would make sense to reduce the need
for an extra invocation of "is the work tree dirty" and this addition is a
welcomed one in that sense. However, as you already are aware of, this
will break existing scripts; it should not trigger for them.
How about "describe --dirty" and "describe --dirty=-mod" (the latter
creates v1.6.5-15-gc274db7-mod"), possibly with a short version of options
if this proves to be useful and frequently used from interactive sessions?
I personally think this does not deserve to have a short option (as you
said in the log message, it is primarily a way to make up a version number
string, and give interactive users a sense of where in the history he is.
If you want to know if your tree is dirty, depending on the reason _why_
you want to know it and what you want to do with the information after
learning your tree is dirty, "status", "diff --stat", "add -i" are more
appropriate and useful tools) but you (and others) may bring up use cases
that I didn't think of when I wrote the beginning of this sentence ;-)
^ permalink raw reply
* Re: [PATCH 3/3] Add proof-of-concept %[w(width,in1,in2)<<any-string>>%] implementation
From: Junio C Hamano @ 2009-10-16 17:25 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0910161331350.4985@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> maybe "rewrap" would be a better name than "w"?
Perhaps, but I do not know if wrap() is even better. The only reason I
said w() here is because I saw you used w() and this is meant to be a
superset replacement for it, as this can re-wrap anything, not just one
particular field from the commit object.
> On Fri, 16 Oct 2009, Junio C Hamano wrote:
>
>> #1 "%[" introduces the nested string function.
>>
>> #2 After that, a name identifies what function to call.
>>
>> #3 The function parses its parameters ("(72,4,8)" in the above example),
>> and makes a nested expansion on the remainder of the format string.
>
> Can't we parse it once, i.e. the first time?
I may be missing the issue you are raising here, but it parses the string
only once; it stuffs the expansion of the enclosed string into a separate
buffer (while noting where it ends), applies the function to the result
obtained in the separate buffer and appends the result of the function
application to the main buffer, and the main expansion resumes where the
nested one finished.
^ permalink raw reply
* Re: [PATCH 2/3] strbuf_nested_expand(): allow expansion to interrupt in the middle
From: Junio C Hamano @ 2009-10-16 17:22 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0910161329270.4985@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Fri, 16 Oct 2009, Junio C Hamano wrote:
>
>> consumed = fn(sb, format, context);
>> - if (consumed)
>> + if ((ssize_t) consumed < 0)
>> + break;
>
> Would it not be much better to fix the signature of fn in a separate
> commit before this one?
Yes, I considered it and it is a reasonable thing to do if this were to
become a real series for includion, but I thought it would add unnecessary
noise to the patch when the main purpose of posting the series is still to
be a proof-of-concept for discussing the design and future directions
(including "it should not have any future---it is useless code churn for
supporting only one example user 'rewrap'").
Please remind and yell at me if (1) this turns out to be going in the
right direction and (2) I forget to fix it when I redo the series after
discussion to apply them for real.
Thanks.
^ permalink raw reply
* Re: Moving git
From: Matthieu Moy @ 2009-10-16 17:10 UTC (permalink / raw)
To: Richard Lee; +Cc: git
In-Reply-To: <25928820.post@talk.nabble.com>
Richard Lee <richard@webdezign.co.uk> writes:
> The reason I had problem with git remote rm was because I was using version
> 1.5.2 as I installed it from yum. (This is what I hate about CentOS, all the
> repositories are old as dirt.) I compiled version 1.6.5 and the command was
> there.
It's a good idea to have a recent version of Git. The
user-friendlyness of Git is progressing quickly, and each new version
brings a myriad of little details that will make your life easier
while learning Git ;-).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: Introduction and Wikipedia and Git Blame
From: Junio C Hamano @ 2009-10-16 17:04 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: jamesmikedupont@googlemail.com, git
In-Reply-To: <alpine.DEB.1.00.0910161548550.4985@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Then I would make modified "texts" from the blob of the file in the
> current revision and its parent revision, by inserting newlines after
> every single byte (probably replacing the original newlines by other
> values, such as \x01).
>
> The reason for this touchup is that the diff machinery in Git only handles
> line-based diffs.
>
> Then you can parse the hunk headers, adjust the offsets accordingly,...
I would agree that text converted to "byte-per-line" format would be the
easiest way to re-use the diff engine, but if you go one more step, you
can even reusel the blame engine as well. You convert the text into
"byte-in-hex-and-lf" (e.g. "AB C\n" becomes "41\n42\n20\n43\n0a\n") and
feed it into existing blame and have it produce script-readable output,
instead of feeding that to your reinvention of blame using diff engine.
You would need to postprocess the computed result (either by diff or
blame) to lay out the final text output in either case anyway, and making
the existing blame engine do the work for you would be a better approach,
I think.
^ permalink raw reply
* Re: Moving git
From: Richard Lee @ 2009-10-16 17:04 UTC (permalink / raw)
To: git
In-Reply-To: <25926819.post@talk.nabble.com>
Hi all,
Thank you to Matthieu Moy and Santi Béjar who both told me to check
.git/config.
The reason why I had problems was because I was using git config --get-all
(with no regex). I then used git config -l and saw the remote local path to
the repository that I used to clone.
The reason I had problem with git remote rm was because I was using version
1.5.2 as I installed it from yum. (This is what I hate about CentOS, all the
repositories are old as dirt.) I compiled version 1.6.5 and the command was
there. I think the ability probably was there in 1.5.2, but you probably had
to do some extra magic stuff to completely remove the repository. And by
trying to git remote prune didn't help either as I had deleted the local
repository.
I now could "git remote rm origin" with no problems after moving the whole
git directory.
Richard
--
View this message in context: http://www.nabble.com/Moving-git-tp25926819p25928820.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Moving git
From: Matthieu Moy @ 2009-10-16 16:11 UTC (permalink / raw)
To: Richard; +Cc: git
In-Reply-To: <8440EA2C12E50645A68C4AA988716651244654@SERVER.webdezign.local>
"Richard" <richard@webdezign.co.uk> writes:
> Hi Matthieu,
>
>
> Thanks for replying.
>
> Basically, I used git-svn to import from git. I'm trying to get rid of
> the origin branch. (I probably should have used the no-metdata switch).
>
> The command I used was
>
> git branch prune origin
>
> I tried "git remote rm origin" which worked on my local win32 machine,
> but the linux server I was working on did not recognise "git remote rm".
>
> I'm pretty sure git stores the current git directory as I've seen the
> --git-dir and --work-tree environment variables.
Git doesn't store them by default for the current repository. "git
rev-parse --git-dir" guesses where your .git/ directory is (looking
for ./.git/, ../.git, and so on). OTOH, Git stores URLs for remote
repositories (see .git/config).
> Plus I also noticed on msysgit gives " Local uncommitted changes,
> not checked in to index" sometimes, when I move the directory.
I don't know msysgit, but I guess you'll have problems if your
repository is on a FAT filesystem. Is it the case?
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* RE: Moving git
From: Richard @ 2009-10-16 15:45 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqk4yv2ws6.fsf@bauges.imag.fr>
Hi Matthieu,
Thanks for replying.
Basically, I used git-svn to import from git. I'm trying to get rid of
the origin branch. (I probably should have used the no-metdata switch).
The command I used was
git branch prune origin
I tried "git remote rm origin" which worked on my local win32 machine,
but the linux server I was working on did not recognise "git remote rm".
I'm pretty sure git stores the current git directory as I've seen the
--git-dir and --work-tree environment variables. Plus I also noticed on
msysgit gives " Local uncommitted changes, not checked in to index"
sometimes, when I move the directory.
Regards,
Richard
-----Original Message-----
From: Matthieu Moy [mailto:Matthieu.Moy@grenoble-inp.fr]
Sent: 16 October 2009 16:17
To: Richard
Cc: git@vger.kernel.org
Subject: Re: Moving git
Richard Lee <richard@webdezign.co.uk> writes:
> Hi Git forum,
>
> I've just started using git yesterday, so I'm very new. So please
excuse if
> I've done something the wrong way.
>
> I cloned a git directory/repository? and then moved it. I'm trying to
prune
> branches and it gives
Which command did you type?
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Nicolas Pitre @ 2009-10-16 15:44 UTC (permalink / raw)
To: Daniel Barkalow
Cc: Björn Steinbrink, Junio C Hamano, Jeff King, James Pickens,
Jay Soffian, git
In-Reply-To: <alpine.LNX.2.00.0910160128400.32515@iabervon.org>
On Fri, 16 Oct 2009, Daniel Barkalow wrote:
> What's the state before the "git checkout HEAD~2"?
It is HEAD@{1}.
> I know I often find my git.git repos on "* (no branch)", and I don't
> remember if I checked that out as origin/master or origin/next.
Just have a look at the output of "git reflog". Pretty unambiguous IMHO.
Nicolas
^ permalink raw reply
* Re: Moving git
From: Santi Béjar @ 2009-10-16 15:41 UTC (permalink / raw)
To: Richard Lee; +Cc: git
In-Reply-To: <25926819.post@talk.nabble.com>
On Fri, Oct 16, 2009 at 4:58 PM, Richard Lee <richard@webdezign.co.uk> wrote:
> I cloned a git directory/repository? and then moved it.
So you moved the original repository. Then you have to update the url
in the new/cloned repositories. I would edit .git/config and changed
the url entries with the new value.
HTH,
Santi
^ permalink raw reply
* Re: Moving git
From: Matthieu Moy @ 2009-10-16 15:17 UTC (permalink / raw)
To: Richard Lee; +Cc: git
In-Reply-To: <25926819.post@talk.nabble.com>
Richard Lee <richard@webdezign.co.uk> writes:
> Hi Git forum,
>
> I've just started using git yesterday, so I'm very new. So please excuse if
> I've done something the wrong way.
>
> I cloned a git directory/repository? and then moved it. I'm trying to prune
> branches and it gives
Which command did you type?
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* [PATCH RFC] git describe without refs distinguishes dirty working tree
From: Jean Privat @ 2009-10-16 15:12 UTC (permalink / raw)
To: git
git describe without refs still works on HEAD but append "-dirty" if the
working three is dirty. If the working tree is clean, nothing is appended.
Previous behavior can be achieved by specifying "HEAD".
Many build scripts use `git describe` to produce a version number.
However, additional git commands are required to distinguish builds done
with a clean tree from builds done with a dirty tree.
This patch helps the writing of these scripts since `git describe` do
the intended thing.
This new behavior could affect existing scripts by producing version
number like v1.0.4-14-g2414721-dirty-dirty.
These scripts could be easily fixed by explicitly using HEAD when calling
`git describe` and works with any version of git.
Signed-off-by: Jean Privat <jean@pryen.org>
---
Initially, I wanted to add an option `--worktree` that works on HEAD and
appends "-dirty" when the working tree is dirty. After rethink I
realized that users (me included) should prefer to describe the working
tree by default, and only describe HEAD if HEAD was explicitly specified.
Note that documentation of `git describe` did not mentioned the behavior
of the command when no committish is specified.
However, since it is still a behavior change. If the patch is accepted,
it could target version 1.7.
---
Documentation/git-describe.txt | 5 ++++-
builtin-describe.c | 18 +++++++++++++++++-
t/t6120-describe.sh | 8 ++++++++
3 files changed, 29 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt
index b231dbb..c49ecc8 100644
--- a/Documentation/git-describe.txt
+++ b/Documentation/git-describe.txt
@@ -8,7 +8,7 @@ git-describe - Show the most recent tag that is
reachable from a commit
SYNOPSIS
--------
-'git describe' [--all] [--tags] [--contains] [--abbrev=<n>] <committish>...
+'git describe' [--all] [--tags] [--contains] [--abbrev=<n>] [<committish>...]
DESCRIPTION
-----------
@@ -18,6 +18,9 @@ shown. Otherwise, it suffixes the tag name with the number of
additional commits on top of the tagged object and the
abbreviated object name of the most recent commit.
+Without any committish, `git describe` opperates on HEAD and
+appends "-dirty" if the working tree is dirty.
+
By default (without --all or --tags) `git describe` only shows
annotated tags. For more information about creating annotated tags
see the -a and -s options to linkgit:git-tag[1].
diff --git a/builtin-describe.c b/builtin-describe.c
index df67a73..4105d9c 100644
--- a/builtin-describe.c
+++ b/builtin-describe.c
@@ -5,6 +5,7 @@
#include "builtin.h"
#include "exec_cmd.h"
#include "parse-options.h"
+#include "diff.h"
#define SEEN (1u<<0)
#define MAX_TAGS (FLAG_BITS - 1)
@@ -23,6 +24,13 @@ static int max_candidates = 10;
static int found_names;
static const char *pattern;
static int always;
+static int dirty; /* Is working tree dirty? */
+
+/* diff-index command arguments to check if working tree is dirty. */
+static const char *diff_index_args[] = {
+ "diff-index", "--quiet", "HEAD", "--", NULL
+};
+
struct commit_name {
struct tag *tag;
@@ -208,6 +216,8 @@ static void describe(const char *arg, int last_one)
display_name(n);
if (longformat)
show_suffix(0, n->tag ? n->tag->tagged->sha1 : sha1);
+ if (dirty)
+ printf("-dirty");
printf("\n");
return;
}
@@ -265,7 +275,10 @@ static void describe(const char *arg, int last_one)
if (!match_cnt) {
const unsigned char *sha1 = cmit->object.sha1;
if (always) {
- printf("%s\n", find_unique_abbrev(sha1, abbrev));
+ printf("%s", find_unique_abbrev(sha1, abbrev));
+ if (dirty)
+ printf("-dirty");
+ printf("\n");
return;
}
die("cannot describe '%s'", sha1_to_hex(sha1));
@@ -300,6 +313,8 @@ static void describe(const char *arg, int last_one)
display_name(all_matches[0].name);
if (abbrev)
show_suffix(all_matches[0].depth, cmit->object.sha1);
+ if (dirty)
+ printf("-dirty");
printf("\n");
if (!last_one)
@@ -360,6 +375,7 @@ int cmd_describe(int argc, const char **argv,
const char *prefix)
}
if (argc == 0) {
+ dirty = cmd_diff_index(ARRAY_SIZE(diff_index_args) - 1,
diff_index_args, prefix);
describe("HEAD", 1);
} else {
while (argc-- > 0) {
diff --git a/t/t6120-describe.sh b/t/t6120-describe.sh
index 8c7e081..8938fc6 100755
--- a/t/t6120-describe.sh
+++ b/t/t6120-describe.sh
@@ -123,6 +123,14 @@ test_expect_success 'rename tag Q back to A' '
test_expect_success 'pack tag refs' 'git pack-refs'
check_describe A-* HEAD
+test_expect_success 'set-up dirty working tree' '
+ echo >>file
+'
+
+check_describe "A-*[0-9a-f]-dirty"
+
+check_describe "A-*[0-9a-f]" HEAD
+
test_expect_success 'set-up matching pattern tests' '
git tag -a -m test-annotated test-annotated &&
echo >>file &&
--
1.6.5
^ permalink raw reply related
* Moving git
From: Richard Lee @ 2009-10-16 14:58 UTC (permalink / raw)
To: git
Hi Git forum,
I've just started using git yesterday, so I'm very new. So please excuse if
I've done something the wrong way.
I cloned a git directory/repository? and then moved it. I'm trying to prune
branches and it gives
]fatal: '/var/www/vhosts/mydomain.co.uk/b2.git': unable to chdir or not a
git archive
fatal: The remote end hung up unexpectedly
ls-remote --heads /var/www/vhosts/mydomain.co.uk/b2.git: command returned
error: 1
b2.git was the cloned bare thing I create following the instruction here:
http://book.git-scm.com/4_setting_up_a_private_repository.html
Is there someway I can get git to update the git base directory?
Richard
--
View this message in context: http://www.nabble.com/Moving-git-tp25926819p25926819.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [RFC PATCH v3 00/17] Return of smart HTTP
From: Shawn O. Pearce @ 2009-10-16 14:31 UTC (permalink / raw)
To: Mark Lodato; +Cc: git
In-Reply-To: <ca433830910152120l1bd358ads6401572ccc05b29@mail.gmail.com>
Mark Lodato <lodatom@gmail.com> wrote:
> On Wed, Oct 14, 2009 at 11:36 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
> > This series is still lacking:
> >
> > ??* The HTTP protocol documentation
> > ??* Tests for the smart http transport code (existing tests pass)
>
> * Dumb HTTP push support
I'm not interested in implementing a WebDAV server. 13 years
ago when WebDAV was the new shiny I considered it. Today, bleh,
no desire.
> It would be really nice if git-http-backend supported dumb pushing
> over WebDAV. Currently, to support both smart and dumb pushing, one
> has to configure Apache in a very awkward and confusing way (if it is
> even possible - I'm still trying to figure it out).
Sure, its confusing, its one reason nobody uses it. Another is
that pushing over WebDAV is slow and error prone, locks get taken
and have to get released, its a general mess.
> Without some way
> to support older clients, it will be very hard to transition to the
> new protocol.
Why?
Smart HTTP is primarily about improving the situation for a client
fetching from the server. If the server happens to allow writes,
users will just have to upgrade to a new enough version of Git that
understands the push variant of the protocol.
If users don't want to upgrade, or can't upgrade, then you can't
push over HTTP. Simple.
Really, what it comes down to is, I don't think it matters that
we don't have backwards compatiblity for pushing through WebDAV.
If you think it matters, you are free to write a patch series on
top of mine which adds the functionality. But don't wait for me
to do it, it won't happen.
> Also, your examples use "DocumentRoot /pub/git", but I think most
> people would want to have their main website as the DocumentRoot, have
> the URL "/git" serve the repositories through gitweb, and have that
> same "/git" URL be `git clone'-able.
Why not have git-http-backend exec gitweb when it gets a request
for the repository itself? Why do you have to go through such
contortions in Apache for this? The two CGIs are shipped in the
same software package, surely one could actually invoke the other.
> The Apache configuration for
> this is complicated and non-intuitive, so I think an example of this
> in the documentation is warranted. The following accomplishes what I
> describe, except it does not work with dump HTTP push, and does not
> allow anonymous read-only access. (I am currently trying to figure
> out how to do both of these things.)
Yes, I'd like to have examples in the git-http-backend manpage.
I put a couple in there already, but they don't consider gitweb
because I assumed we'd find a way to have gitweb be invoked out
of git-http-backend. Unfortunately that hasn't happened yet.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Björn Steinbrink @ 2009-10-16 14:30 UTC (permalink / raw)
To: Julian Phillips
Cc: Daniel Barkalow, James Pickens, Jeff King, Junio C Hamano,
Nicolas Pitre, Jay Soffian, git
In-Reply-To: <alpine.LNX.2.00.0910161311460.28491@reaper.quantumfyre.co.uk>
On 2009.10.16 13:15:35 +0100, Julian Phillips wrote:
> On Thu, 15 Oct 2009, Daniel Barkalow wrote:
>
> >On Thu, 15 Oct 2009, James Pickens wrote:
> >
> >>How about not detaching the head at all if the user checks out any ref, and
> >>reject commits if he checked out a tag or remote branch. For example:
> >>
> >>$ git checkout origin/master
> >>$ git status
> >># On branch origin/master
> >>$ git commit ;# complain
> >
> >$ git checkout origin/master
> >$ git fetch
> >$ git checkout origin/next
> >Uncommited file '...' would be overwritten.
>
> How about:
>
> $ git checkout origin/master
> $ git fetch
> Refusing to fetch, as it would update a checkedout branch
> "git fetch -f" will force the update, but you will need to run "git
> reset --hard HEAD" to update your checkout to match.
That would redefine -f (currently means "allow non-fast-forward
updates"), the flag that allows the checked out branch head to be
updated is -u, --update-head-ok, and is for internal use only.
And suggesting "reset --hard" seems wrong, that just kills any
uncommitted changes.
And such uncommitted changes would be lost in the big "undo the fetch
update" diff. So you'd have to do:
git reset --soft HEAD@{1}
git checkout --merge HEAD@{1}
to keep them, while updating to the new state of the remote tracking
branch. Not quite intuitive, is it?
Björn
^ permalink raw reply
* Re: [PATCH v3 3/8] imap-send: use run-command API for tunneling
From: Erik Faye-Lund @ 2009-10-16 14:27 UTC (permalink / raw)
To: Johannes Sixt; +Cc: msysgit, git
In-Reply-To: <200910142158.59073.j6t@kdbg.org>
Sorry about the late reply, lots of things to do.
On Wed, Oct 14, 2009 at 9:58 PM, Johannes Sixt <j6t@kdbg.org> wrote:
> On Dienstag, 13. Oktober 2009, Erik Faye-Lund wrote:
>> I'm really unsure if it's worth the hassle.
>
> We already depend on the existence of a Bourne shell for our scripted
> commands. There are already more places in the code that run "sh"
> than "/bin/sh".
OK, you've got me convinced. I'll update the patch with this tweak.
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* Re: [RFC PATCH 1/4] Document the HTTP transport protocol
From: Antti-Juhani Kaijanaho @ 2009-10-16 14:23 UTC (permalink / raw)
To: git
In-Reply-To: <4AD80BBD.8080504@zytor.com>
On 2009-10-16, H. Peter Anvin <hpa@zytor.com> wrote:
> 410 means "we once had it, it's no longer here, no idea where it went."
> It's a largely useless code...
That's not a reason to forbid it methinks. And I quite like the difference
between "oops, mistyped the URI" and "oops, that URI is no longer valid".
--
Mr. Antti-Juhani Kaijanaho, Jyvaskyla, Finland
^ permalink raw reply
* Re: Introduction and Wikipedia and Git Blame
From: jamesmikedupont @ 2009-10-16 14:23 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0910161548550.4985@pacific.mpi-cbg.de>
Johannes,
Thanks for your input,
comments below.
mfg,
mike
On Fri, Oct 16, 2009 at 4:11 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Fri, 16 Oct 2009, jamesmikedupont@googlemail.com wrote:
>
>> On Fri, Oct 16, 2009 at 1:26 PM, Johannes Schindelin
>> <Johannes.Schindelin@gmx.de> wrote:
>> >> Here is the discussion on foundation-l :
>> >> http://www.gossamer-threads.com/lists/wiki/foundation/181163
>> >
>> > I found the link to the bazaar repository there, but do you have a Git
>> > repository, too?
>>
>> Not yet. Where should I put it? Any suggestions.
>
> github.com has a nice interface.
>
> BTW after reading some of the code, I am a bit surprised that you did not
> do it as a .php script outputting fast-import capable text...
I dont really know php, and I dont have a debugger or any tools in it....
Really cannot understand how people can work in such an environment.
I have done all my hacking work as perl scripts.
These can be rewritten in c later on.
> Okay, so basically you want to analyze the text on a word-by-word basis
> rather than line-by-line.
yes.
>
> Or maybe even better: you want to analyze the text character-by-character.
> That would also nicely circumvent to specify just what makes a word a word
> (subject for a lot of heated discussion during the design of the
> --color-words=<regex> patch).
Yes, Someone suggested in irc to review the color-words , I have the
source code now and will be looking into that.
>
> Basically, if I had to implement that, I would not try to modify
> builtin-blame.c, but write a new program linking to libgit.a, calling the
> revision walker on the file you want to calculate the blame for. (One of
> the best examples is probably in builtin-shortlog.c.)
>
> Then I would introduce a linked-list structure which will hold the blamed
> regions in this form:
>
> struct region {
> int start;
> struct region *next;
> };
>
> Initially, this would have a start element with the start offset 0
> pointing to the end element with start offset being set to the size of the
> blob.
>
> Most likely you will have to add members to this struct, such as the
> original offsets (as you will have to adjust the offsets to the different
> file revisions while you go back in time), and the commit it was
> attributed to.
>
> Then I would make modified "texts" from the blob of the file in the
> current revision and its parent revision, by inserting newlines after
> every single byte (probably replacing the original newlines by other
> values, such as \x01).
>
> The reason for this touchup is that the diff machinery in Git only handles
> line-based diffs.
>
> Then you can parse the hunk headers, adjust the offsets accordingly, and
> attribute the +++ regions to the current commit (by construction, the
> offsets are equal to the line number in the hunk header). Here it is most
> likely necessary to split the regions.
>
> You should also have a counter how many regions are still unattributed so
> you can stop early.
Ok this sounds like a plan. I think that will be a good outline to
start some work.
I will let you know when I have made some progress.
thanks,
mike
^ permalink raw reply
* [PATCH v3 5/5] stash list: drop the default limit of 10 stashes
From: Thomas Rast @ 2009-10-16 14:20 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Jef Driesen, Nanako Shiraishi, git
In-Reply-To: <cover.1255701207.git.trast@student.ethz.ch>
'git stash list' had an undocumented limit of 10 stashes, unless other
git-log arguments were specified. This surprised at least one user,
but possibly served to cut the output below a screenful without using
a pager.
Since the last commit, 'git stash list' will fire up a pager according
to the same rules as the 'git log' it calls, so we can drop the limit.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
git-stash.sh | 5 -----
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/git-stash.sh b/git-stash.sh
index f8847c1..f796c2f 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -382,11 +382,6 @@ test -n "$seen_non_option" || set "save" "$@"
case "$1" in
list)
shift
- if test $# = 0
- then
- set x -n 10
- shift
- fi
list_stash "$@"
;;
show)
--
1.6.5.116.gfe4b9
^ permalink raw reply related
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