* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Junio C Hamano @ 2009-10-16 20:19 UTC (permalink / raw)
To: Julian Phillips
Cc: Björn Steinbrink, Daniel Barkalow, James Pickens, Jeff King,
Nicolas Pitre, Jay Soffian, git
In-Reply-To: <alpine.LNX.2.00.0910162029460.31673@reaper.quantumfyre.co.uk>
Julian Phillips <julian@quantumfyre.co.uk> writes:
> On Fri, 16 Oct 2009, Junio C Hamano wrote:
>
>> Julian Phillips <julian@quantumfyre.co.uk> writes:
>> ...
>>> I don't care what git has to do, I'm talking about the user experience
>>
>> But Bj?rn is showing two commands the _user_ has to type, iow, the comment
>> is about the user experience.
>
> Only Currently. My point was that _if_ we wanted to support this sort
> of thing, then we can make is simpler to do by providing a simple
> command for the user.
>
> The point I wanted to make was that the decision on what to do should
> be driven by the user's experience - not by the fact that it is easier
> to implement something else.
Sorry, but I do not see in what way what you said in the thread connects
to the above three lines. Are you talking about this one from you a few
messages back?
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.
I am not seeing "not the implementation ease but the user experience"
drive in this suggestion. If you are driving from the user experience
point of view, I would have instead suggested:
How about:
$ git checkout origin/master
$ git fetch
and fetch happily updates the tracked branch, without affecting the
HEAD state (nor index nor the work tree, of course).
User experience here is:
* Let's checkout what the upstream has on the master. I am at least
aware that git is distributed and does not go to the network unless
I tell it to, and am aware that origin/master is the state of the
upsream _when I told git to look at it the last time_. So I'll get
the state I talked with the upstream the last time, and that is what
I want to look at.
* Hmm, there may be even more updates since I talked with the upstream
the last time. Let's tell git to fetch. I already know that this
updates origin/master to a more recent state.
Isn't it much cleaner and less confusing? And with these kind of
awareness, the user can choose to do various things from here, e.g.:
* Oh, fetch did fetched something. I want the updated state. Let's
check it out with "git checkout origin/master"; or
* Ok, what changed since I last talked with the upstream? I have one
end of the state already checked out, and I updated origin/master
with their latest, so I can say "git diff HEAD origin/master".
Notice in the latter the user can be a neophyte who hasn't learned reflogs
yet.
> My interest in this thread is solely that it might provide a mechanism
> to find out which tag was checked out.
Hmm, what is lacking in "git describe HEAD" for that? I am not
complaining that you might be asking for something that exists, but I _do_
want to know if something that exists is not a satisfactory solution and
if so how it can be improved.
^ permalink raw reply
* Re: Introduction and Wikipedia and Git Blame
From: Junio C Hamano @ 2009-10-16 20:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: jamesmikedupont@googlemail.com, Johannes Schindelin, git
In-Reply-To: <7v7huvuptn.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> "jamesmikedupont@googlemail.com" <jamesmikedupont@googlemail.com> writes:
>
>>> 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 think this is one of the most conprehensive write-up on the algorithm:
>
> http://thread.gmane.org/gmane.comp.version-control.git/28826/focus=28895
>
> The whole thread (at least what I wrote in it) is worth reading if you
> want to understand what the current code does. The first message in the
> thread talks about "NEEDSWORK" label on an unimplemented part of the code,
> and says "we could", but these gaps were since filled.
Ah, nevermind. The thread is the definitive description of the blame
algorithm, but I agree with Dscho that in this case, you either have to
change blame itself to do this "byte-wise" comparison internally between
versions, or re-do the blame logic yourself like Dscho suggests. Dscho is
right in this case; an unmodifled blame engine, unless you feed a history
that is converted to use the byte-per-line format, won't help you at all.
So it would be either between rolling a custom byte-wise blame algorithm
yourself and teaching a new byte-wise mode to existing blame engine.
Sorry for making the task sound much easier than it would be.
^ permalink raw reply
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Julian Phillips @ 2009-10-16 19:48 UTC (permalink / raw)
To: Junio C Hamano
Cc: Björn Steinbrink, Daniel Barkalow, James Pickens, Jeff King,
Nicolas Pitre, Jay Soffian, git
In-Reply-To: <7vvdiftb0d.fsf@alter.siamese.dyndns.org>
On Fri, 16 Oct 2009, Junio C Hamano wrote:
> Julian Phillips <julian@quantumfyre.co.uk> writes:
>
>>> 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
>
> But Bj?rn is showing two commands the _user_ has to type, iow, the comment
> is about the user experience.
Only Currently. My point was that _if_ we wanted to support this sort of
thing, then we can make is simpler to do by providing a simple command for
the user.
The point I wanted to make was that the decision on what to do should be
driven by the user's experience - not by the fact that it is easier to
implement something else.
My interest in this thread is solely that it might provide a mechanism to
find out which tag was checked out. So, I'm just chucking in my $0.02 as
a user. My suggestions are probably complete rubbish, as I haven't really
had time to think them through... Sorry.
--
Julian
---
Look, just gimme some inner peace, or I'll mop the floor with ya!
-- Homer Simpson
El Viaje Misterioso de Nuestro Homer
^ permalink raw reply
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Junio C Hamano @ 2009-10-16 19:05 UTC (permalink / raw)
To: Julian Phillips
Cc: Björn Steinbrink, Daniel Barkalow, 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>
Julian Phillips <julian@quantumfyre.co.uk> writes:
>> 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
But Björn is showing two commands the _user_ has to type, iow, the comment
is about the user experience.
^ 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 19:01 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, Johannes Schindelin, git
In-Reply-To: <m33a5jfc6p.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
> I don't remember what were original parameters to w(72,4,8) means...
"man git-shortlog" look for -w.
^ permalink raw reply
* Re: Introduction and Wikipedia and Git Blame
From: Junio C Hamano @ 2009-10-16 19:00 UTC (permalink / raw)
To: jamesmikedupont@googlemail.com; +Cc: Johannes Schindelin, git
In-Reply-To: <ee9cc730910161100r71818303v343f555151db4dcc@mail.gmail.com>
"jamesmikedupont@googlemail.com" <jamesmikedupont@googlemail.com> writes:
>> 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 think this is one of the most conprehensive write-up on the algorithm:
http://thread.gmane.org/gmane.comp.version-control.git/28826/focus=28895
The whole thread (at least what I wrote in it) is worth reading if you
want to understand what the current code does. The first message in the
thread talks about "NEEDSWORK" label on an unimplemented part of the code,
and says "we could", but these gaps were since filled.
^ permalink raw reply
* 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
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