* 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
* [PATCH v3 4/5] stash list: use new %g formats instead of sed
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>
With the new formats, we can rewrite 'git stash list' in terms of an
appropriate pretty format, instead of hand-editing with sed. This has
the advantage that it obeys the normal settings for git-log, notably
the pager.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
git-stash.sh | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/git-stash.sh b/git-stash.sh
index 4febbbf..f8847c1 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -205,8 +205,7 @@ have_stash () {
list_stash () {
have_stash || return 0
- git log --no-color --pretty=oneline -g "$@" $ref_stash -- |
- sed -n -e 's/^[.0-9a-f]* refs\///p'
+ git log --format="%gd: %gs" -g "$@" $ref_stash --
}
show_stash () {
--
1.6.5.116.gfe4b9
^ permalink raw reply related
* [PATCH v3 3/5] Introduce new pretty formats %g[sdD] for reflog information
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>
Add three new --pretty=format escapes:
%gD long reflog descriptor (e.g. refs/stash@{0})
%gd short reflog descriptor (e.g. stash@{0})
%gs reflog message
This is achieved by passing down the reflog info, if any, inside the
pretty_print_context struct.
We use the newly refactored get_reflog_selector(), and give it some
extra functionality to extract a shortened ref. The shortening is
cached inside the commit_reflogs struct; the only allocation of it
happens in read_complete_reflog(), where it is initialised to 0. Also
add another helper get_reflog_message() for the message extraction.
Note that the --format="%h %gD: %gs" tests may not work in real
repositories, as the --pretty formatter doesn't know to leave away the
": " on the last commit in an incomplete (because git-gc removed the
old part) reflog. This equivalence is nevertheless the main goal of
this patch.
Thanks to Jeff King for reviews and the %gd testcase.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Documentation/pretty-formats.txt | 3 +++
commit.h | 1 +
log-tree.c | 1 +
pretty.c | 17 +++++++++++++++++
reflog-walk.c | 35 ++++++++++++++++++++++++++++++++---
reflog-walk.h | 8 ++++++++
t/t6006-rev-list-format.sh | 18 ++++++++++++++++++
7 files changed, 80 insertions(+), 3 deletions(-)
diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
index 2a845b1..cc0ea56 100644
--- a/Documentation/pretty-formats.txt
+++ b/Documentation/pretty-formats.txt
@@ -123,6 +123,9 @@ The placeholders are:
- '%s': subject
- '%f': sanitized subject line, suitable for a filename
- '%b': body
+- '%gD': reflog selector, e.g., `refs/stash@\{1\}`
+- '%gd': shortened reflog selector, e.g., `stash@\{1\}`
+- '%gs': reflog subject
- '%Cred': switch color to red
- '%Cgreen': switch color to green
- '%Cblue': switch color to blue
diff --git a/commit.h b/commit.h
index 011766d..15cb649 100644
--- a/commit.h
+++ b/commit.h
@@ -70,6 +70,7 @@ struct pretty_print_context
const char *after_subject;
enum date_mode date_mode;
int need_8bit_cte;
+ struct reflog_walk_info *reflog_info;
};
extern int non_ascii(int);
diff --git a/log-tree.c b/log-tree.c
index f57487f..8e782fc 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -409,6 +409,7 @@ void show_log(struct rev_info *opt)
ctx.date_mode = opt->date_mode;
ctx.abbrev = opt->diffopt.abbrev;
ctx.after_subject = extra_headers;
+ ctx.reflog_info = opt->reflog_info;
pretty_print_commit(opt->commit_format, commit, &msgbuf, &ctx);
if (opt->add_signoff)
diff --git a/pretty.c b/pretty.c
index d6d57eb..fc65fca 100644
--- a/pretty.c
+++ b/pretty.c
@@ -7,6 +7,7 @@
#include "mailmap.h"
#include "log-tree.h"
#include "color.h"
+#include "reflog-walk.h"
static char *user_format;
@@ -701,6 +702,22 @@ static size_t format_commit_item(struct strbuf *sb, const char *placeholder,
case 'd':
format_decoration(sb, commit);
return 1;
+ case 'g': /* reflog info */
+ switch(placeholder[1]) {
+ case 'd': /* reflog selector */
+ case 'D':
+ if (c->pretty_ctx->reflog_info)
+ get_reflog_selector(sb,
+ c->pretty_ctx->reflog_info,
+ c->pretty_ctx->date_mode,
+ (placeholder[1] == 'd'));
+ return 2;
+ case 's': /* reflog message */
+ if (c->pretty_ctx->reflog_info)
+ get_reflog_message(sb, c->pretty_ctx->reflog_info);
+ return 2;
+ }
+ return 0; /* unknown %g placeholder */
}
/* For the rest we have to parse the commit header. */
diff --git a/reflog-walk.c b/reflog-walk.c
index 596bafe..caba4f7 100644
--- a/reflog-walk.c
+++ b/reflog-walk.c
@@ -8,6 +8,7 @@
struct complete_reflogs {
char *ref;
+ const char *short_ref;
struct reflog_info {
unsigned char osha1[20], nsha1[20];
char *email;
@@ -243,15 +244,26 @@ void fake_reflog_parent(struct reflog_walk_info *info, struct commit *commit)
void get_reflog_selector(struct strbuf *sb,
struct reflog_walk_info *reflog_info,
- enum date_mode dmode)
+ enum date_mode dmode,
+ int shorten)
{
struct commit_reflog *commit_reflog = reflog_info->last_commit_reflog;
struct reflog_info *info;
+ const char *printed_ref;
if (!commit_reflog)
return;
- strbuf_addf(sb, "%s@{", commit_reflog->reflogs->ref);
+ if (shorten) {
+ if (!commit_reflog->reflogs->short_ref)
+ commit_reflog->reflogs->short_ref
+ = shorten_unambiguous_ref(commit_reflog->reflogs->ref, 0);
+ printed_ref = commit_reflog->reflogs->short_ref;
+ } else {
+ printed_ref = commit_reflog->reflogs->ref;
+ }
+
+ strbuf_addf(sb, "%s@{", printed_ref);
if (commit_reflog->flag || dmode) {
info = &commit_reflog->reflogs->items[commit_reflog->recno+1];
strbuf_addstr(sb, show_date(info->timestamp, info->tz, dmode));
@@ -263,6 +275,23 @@ void get_reflog_selector(struct strbuf *sb,
strbuf_addch(sb, '}');
}
+void get_reflog_message(struct strbuf *sb,
+ struct reflog_walk_info *reflog_info)
+{
+ struct commit_reflog *commit_reflog = reflog_info->last_commit_reflog;
+ struct reflog_info *info;
+ size_t len;
+
+ if (!commit_reflog)
+ return;
+
+ info = &commit_reflog->reflogs->items[commit_reflog->recno+1];
+ len = strlen(info->message);
+ if (len > 0)
+ len--; /* strip away trailing newline */
+ strbuf_add(sb, info->message, len);
+}
+
void show_reflog_message(struct reflog_walk_info *reflog_info, int oneline,
enum date_mode dmode)
{
@@ -272,7 +301,7 @@ void show_reflog_message(struct reflog_walk_info *reflog_info, int oneline,
struct strbuf selector = STRBUF_INIT;
info = &commit_reflog->reflogs->items[commit_reflog->recno+1];
- get_reflog_selector(&selector, reflog_info, dmode);
+ get_reflog_selector(&selector, reflog_info, dmode, 0);
if (oneline) {
printf("%s: %s", selector.buf, info->message);
}
diff --git a/reflog-walk.h b/reflog-walk.h
index 74c9096..7bd2cd4 100644
--- a/reflog-walk.h
+++ b/reflog-walk.h
@@ -3,6 +3,8 @@
#include "cache.h"
+struct reflog_walk_info;
+
extern void init_reflog_walk(struct reflog_walk_info** info);
extern int add_reflog_for_walk(struct reflog_walk_info *info,
struct commit *commit, const char *name);
@@ -10,5 +12,11 @@ extern void fake_reflog_parent(struct reflog_walk_info *info,
struct commit *commit);
extern void show_reflog_message(struct reflog_walk_info *info, int,
enum date_mode);
+extern void get_reflog_message(struct strbuf *sb,
+ struct reflog_walk_info *reflog_info);
+extern void get_reflog_selector(struct strbuf *sb,
+ struct reflog_walk_info *reflog_info,
+ enum date_mode dmode,
+ int shorten);
#endif
diff --git a/t/t6006-rev-list-format.sh b/t/t6006-rev-list-format.sh
index 59d1f62..7f61ab0 100755
--- a/t/t6006-rev-list-format.sh
+++ b/t/t6006-rev-list-format.sh
@@ -162,4 +162,22 @@ test_expect_success 'empty email' '
}
'
+test_expect_success '"%h %gD: %gs" is same as git-reflog' '
+ git reflog >expect &&
+ git log -g --format="%h %gD: %gs" >actual &&
+ test_cmp expect actual
+'
+
+test_expect_success '"%h %gD: %gs" is same as git-reflog (with date)' '
+ git reflog --date=raw >expect &&
+ git log -g --format="%h %gD: %gs" --date=raw >actual &&
+ test_cmp expect actual
+'
+
+test_expect_success '%gd shortens ref name' '
+ echo "master@{0}" >expect.gd-short &&
+ git log -g -1 --format=%gd refs/heads/master >actual.gd-short &&
+ test_cmp expect.gd-short actual.gd-short
+'
+
test_done
--
1.6.5.116.gfe4b9
^ permalink raw reply related
* [PATCH v3 2/5] reflog-walk: refactor the branch@{num} formatting
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>
We'll use the same output in an upcoming commit, so refactor its
formatting (which was duplicated anyway) into a separate function.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
reflog-walk.c | 54 ++++++++++++++++++++++++++++++++----------------------
1 files changed, 32 insertions(+), 22 deletions(-)
diff --git a/reflog-walk.c b/reflog-walk.c
index 5623ea6..596bafe 100644
--- a/reflog-walk.c
+++ b/reflog-walk.c
@@ -241,36 +241,46 @@ void fake_reflog_parent(struct reflog_walk_info *info, struct commit *commit)
commit->object.flags &= ~(ADDED | SEEN | SHOWN);
}
-void show_reflog_message(struct reflog_walk_info *info, int oneline,
+void get_reflog_selector(struct strbuf *sb,
+ struct reflog_walk_info *reflog_info,
+ enum date_mode dmode)
+{
+ struct commit_reflog *commit_reflog = reflog_info->last_commit_reflog;
+ struct reflog_info *info;
+
+ if (!commit_reflog)
+ return;
+
+ strbuf_addf(sb, "%s@{", commit_reflog->reflogs->ref);
+ if (commit_reflog->flag || dmode) {
+ info = &commit_reflog->reflogs->items[commit_reflog->recno+1];
+ strbuf_addstr(sb, show_date(info->timestamp, info->tz, dmode));
+ } else {
+ strbuf_addf(sb, "%d", commit_reflog->reflogs->nr
+ - 2 - commit_reflog->recno);
+ }
+
+ strbuf_addch(sb, '}');
+}
+
+void show_reflog_message(struct reflog_walk_info *reflog_info, int oneline,
enum date_mode dmode)
{
- if (info && info->last_commit_reflog) {
- struct commit_reflog *commit_reflog = info->last_commit_reflog;
+ if (reflog_info && reflog_info->last_commit_reflog) {
+ struct commit_reflog *commit_reflog = reflog_info->last_commit_reflog;
struct reflog_info *info;
+ struct strbuf selector = STRBUF_INIT;
info = &commit_reflog->reflogs->items[commit_reflog->recno+1];
+ get_reflog_selector(&selector, reflog_info, dmode);
if (oneline) {
- printf("%s@{", commit_reflog->reflogs->ref);
- if (commit_reflog->flag || dmode)
- printf("%s", show_date(info->timestamp,
- info->tz,
- dmode));
- else
- printf("%d", commit_reflog->reflogs->nr
- - 2 - commit_reflog->recno);
- printf("}: %s", info->message);
+ printf("%s: %s", selector.buf, info->message);
}
else {
- printf("Reflog: %s@{", commit_reflog->reflogs->ref);
- if (commit_reflog->flag || dmode)
- printf("%s", show_date(info->timestamp,
- info->tz,
- dmode));
- else
- printf("%d", commit_reflog->reflogs->nr
- - 2 - commit_reflog->recno);
- printf("} (%s)\nReflog message: %s",
- info->email, info->message);
+ printf("Reflog: %s (%s)\nReflog message: %s",
+ selector.buf, info->email, info->message);
}
+
+ strbuf_release(&selector);
}
}
--
1.6.5.116.gfe4b9
^ permalink raw reply related
* [PATCH v3 1/5] Refactor pretty_print_commit arguments into a struct
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>
pretty_print_commit() has a bunch of rarely-used arguments, and
introducing more of them requires yet another update of all the call
sites. Refactor most of them into a struct to make future extensions
easier.
The ones that stay "plain" arguments were chosen on the grounds that
all callers put real arguments there, whereas some callers have 0/NULL
for all arguments that were factored into the struct.
We declare the struct 'const' to ensure none of the callers are bitten
by the changed (no longer call-by-value) semantics.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
builtin-branch.c | 3 ++-
builtin-checkout.c | 3 ++-
builtin-log.c | 3 ++-
builtin-merge.c | 7 +++++--
builtin-rev-list.c | 7 ++++---
builtin-shortlog.c | 9 ++++++---
builtin-show-branch.c | 4 ++--
commit.h | 19 +++++++++++++------
log-tree.c | 20 ++++++++++----------
pretty.c | 27 ++++++++++++++-------------
10 files changed, 60 insertions(+), 42 deletions(-)
diff --git a/builtin-branch.c b/builtin-branch.c
index 9f57992..05e876e 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -387,8 +387,9 @@ static void print_ref_item(struct ref_item *item, int maxwidth, int verbose,
commit = item->commit;
if (commit && !parse_commit(commit)) {
+ struct pretty_print_context ctx = {0};
pretty_print_commit(CMIT_FMT_ONELINE, commit,
- &subject, 0, NULL, NULL, 0, 0);
+ &subject, &ctx);
sub = subject.buf;
}
diff --git a/builtin-checkout.c b/builtin-checkout.c
index d050c37..075a49f 100644
--- a/builtin-checkout.c
+++ b/builtin-checkout.c
@@ -302,8 +302,9 @@ static void show_local_changes(struct object *head)
static void describe_detached_head(char *msg, struct commit *commit)
{
struct strbuf sb = STRBUF_INIT;
+ struct pretty_print_context ctx = {0};
parse_commit(commit);
- pretty_print_commit(CMIT_FMT_ONELINE, commit, &sb, 0, NULL, NULL, 0, 0);
+ pretty_print_commit(CMIT_FMT_ONELINE, commit, &sb, &ctx);
fprintf(stderr, "%s %s... %s\n", msg,
find_unique_abbrev(commit->object.sha1, DEFAULT_ABBREV), sb.buf);
strbuf_release(&sb);
diff --git a/builtin-log.c b/builtin-log.c
index 25e21ed..207a361 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -1304,8 +1304,9 @@ int cmd_cherry(int argc, const char **argv, const char *prefix)
if (verbose) {
struct strbuf buf = STRBUF_INIT;
+ struct pretty_print_context ctx = {0};
pretty_print_commit(CMIT_FMT_ONELINE, commit,
- &buf, 0, NULL, NULL, 0, 0);
+ &buf, &ctx);
printf("%c %s %s\n", sign,
sha1_to_hex(commit->object.sha1), buf.buf);
strbuf_release(&buf);
diff --git a/builtin-merge.c b/builtin-merge.c
index b6b8428..c69a305 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -264,6 +264,7 @@ static void squash_message(void)
struct strbuf out = STRBUF_INIT;
struct commit_list *j;
int fd;
+ struct pretty_print_context ctx = {0};
printf("Squash commit -- not updating HEAD\n");
fd = open(git_path("SQUASH_MSG"), O_WRONLY | O_CREAT, 0666);
@@ -285,13 +286,15 @@ static void squash_message(void)
if (prepare_revision_walk(&rev))
die("revision walk setup failed");
+ ctx.abbrev = rev.abbrev;
+ ctx.date_mode = rev.date_mode;
+
strbuf_addstr(&out, "Squashed commit of the following:\n");
while ((commit = get_revision(&rev)) != NULL) {
strbuf_addch(&out, '\n');
strbuf_addf(&out, "commit %s\n",
sha1_to_hex(commit->object.sha1));
- pretty_print_commit(rev.commit_format, commit, &out, rev.abbrev,
- NULL, NULL, rev.date_mode, 0);
+ pretty_print_commit(rev.commit_format, commit, &out, &ctx);
}
if (write(fd, out.buf, out.len) < 0)
die_errno("Writing SQUASH_MSG");
diff --git a/builtin-rev-list.c b/builtin-rev-list.c
index 4ba1c12..42cc8d8 100644
--- a/builtin-rev-list.c
+++ b/builtin-rev-list.c
@@ -96,9 +96,10 @@ static void show_commit(struct commit *commit, void *data)
if (revs->verbose_header && commit->buffer) {
struct strbuf buf = STRBUF_INIT;
- pretty_print_commit(revs->commit_format, commit,
- &buf, revs->abbrev, NULL, NULL,
- revs->date_mode, 0);
+ struct pretty_print_context ctx = {0};
+ ctx.abbrev = revs->abbrev;
+ ctx.date_mode = revs->date_mode;
+ pretty_print_commit(revs->commit_format, commit, &buf, &ctx);
if (revs->graph) {
if (buf.len) {
if (revs->commit_format != CMIT_FMT_ONELINE)
diff --git a/builtin-shortlog.c b/builtin-shortlog.c
index 4d4a3c8..8aa63c7 100644
--- a/builtin-shortlog.c
+++ b/builtin-shortlog.c
@@ -158,9 +158,12 @@ void shortlog_add_commit(struct shortlog *log, struct commit *commit)
sha1_to_hex(commit->object.sha1));
if (log->user_format) {
struct strbuf buf = STRBUF_INIT;
-
- pretty_print_commit(CMIT_FMT_USERFORMAT, commit, &buf,
- DEFAULT_ABBREV, "", "", DATE_NORMAL, 0);
+ struct pretty_print_context ctx = {0};
+ ctx.abbrev = DEFAULT_ABBREV;
+ ctx.subject = "";
+ ctx.after_subject = "";
+ ctx.date_mode = DATE_NORMAL;
+ pretty_print_commit(CMIT_FMT_USERFORMAT, commit, &buf, &ctx);
insert_one_record(log, author, buf.buf);
strbuf_release(&buf);
return;
diff --git a/builtin-show-branch.c b/builtin-show-branch.c
index be95930..9f13caa 100644
--- a/builtin-show-branch.c
+++ b/builtin-show-branch.c
@@ -293,8 +293,8 @@ static void show_one_commit(struct commit *commit, int no_name)
struct commit_name *name = commit->util;
if (commit->object.parsed) {
- pretty_print_commit(CMIT_FMT_ONELINE, commit,
- &pretty, 0, NULL, NULL, 0, 0);
+ struct pretty_print_context ctx = {0};
+ pretty_print_commit(CMIT_FMT_ONELINE, commit, &pretty, &ctx);
pretty_str = pretty.buf;
}
if (!prefixcmp(pretty_str, "[PATCH] "))
diff --git a/commit.h b/commit.h
index f4fc5c5..011766d 100644
--- a/commit.h
+++ b/commit.h
@@ -63,6 +63,15 @@ enum cmit_fmt {
CMIT_FMT_UNSPECIFIED,
};
+struct pretty_print_context
+{
+ int abbrev;
+ const char *subject;
+ const char *after_subject;
+ enum date_mode date_mode;
+ int need_8bit_cte;
+};
+
extern int non_ascii(int);
extern int has_non_ascii(const char *text);
struct rev_info; /* in revision.h, it circularly uses enum cmit_fmt */
@@ -71,12 +80,10 @@ enum cmit_fmt {
extern void get_commit_format(const char *arg, struct rev_info *);
extern void format_commit_message(const struct commit *commit,
const void *format, struct strbuf *sb,
- enum date_mode dmode);
-extern void pretty_print_commit(enum cmit_fmt fmt, const struct commit*,
- struct strbuf *,
- int abbrev, const char *subject,
- const char *after_subject, enum date_mode,
- int need_8bit_cte);
+ const struct pretty_print_context *context);
+extern void pretty_print_commit(enum cmit_fmt fmt, const struct commit *commit,
+ struct strbuf *sb,
+ const struct pretty_print_context *context);
void pp_user_info(const char *what, enum cmit_fmt fmt, struct strbuf *sb,
const char *line, enum date_mode dmode,
const char *encoding);
diff --git a/log-tree.c b/log-tree.c
index f7d54f2..f57487f 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -277,10 +277,9 @@ void show_log(struct rev_info *opt)
struct strbuf msgbuf = STRBUF_INIT;
struct log_info *log = opt->loginfo;
struct commit *commit = log->commit, *parent = log->parent;
- int abbrev = opt->diffopt.abbrev;
int abbrev_commit = opt->abbrev_commit ? opt->abbrev : 40;
- const char *subject = NULL, *extra_headers = opt->extra_headers;
- int need_8bit_cte = 0;
+ const char *extra_headers = opt->extra_headers;
+ struct pretty_print_context ctx = {0};
opt->loginfo = NULL;
if (!opt->verbose_header) {
@@ -347,8 +346,8 @@ void show_log(struct rev_info *opt)
*/
if (opt->commit_format == CMIT_FMT_EMAIL) {
- log_write_email_headers(opt, commit, &subject, &extra_headers,
- &need_8bit_cte);
+ log_write_email_headers(opt, commit, &ctx.subject, &extra_headers,
+ &ctx.need_8bit_cte);
} else if (opt->commit_format != CMIT_FMT_USERFORMAT) {
fputs(diff_get_color_opt(&opt->diffopt, DIFF_COMMIT), stdout);
if (opt->commit_format != CMIT_FMT_ONELINE)
@@ -405,11 +404,12 @@ void show_log(struct rev_info *opt)
/*
* And then the pretty-printed message itself
*/
- if (need_8bit_cte >= 0)
- need_8bit_cte = has_non_ascii(opt->add_signoff);
- pretty_print_commit(opt->commit_format, commit, &msgbuf,
- abbrev, subject, extra_headers, opt->date_mode,
- need_8bit_cte);
+ if (ctx.need_8bit_cte >= 0)
+ ctx.need_8bit_cte = has_non_ascii(opt->add_signoff);
+ ctx.date_mode = opt->date_mode;
+ ctx.abbrev = opt->diffopt.abbrev;
+ ctx.after_subject = extra_headers;
+ pretty_print_commit(opt->commit_format, commit, &msgbuf, &ctx);
if (opt->add_signoff)
append_signoff(&msgbuf, opt->add_signoff);
diff --git a/pretty.c b/pretty.c
index f5983f8..d6d57eb 100644
--- a/pretty.c
+++ b/pretty.c
@@ -442,7 +442,7 @@ struct chunk {
struct format_commit_context {
const struct commit *commit;
- enum date_mode dmode;
+ const struct pretty_print_context *pretty_ctx;
unsigned commit_header_parsed:1;
unsigned commit_message_parsed:1;
@@ -711,11 +711,11 @@ static size_t format_commit_item(struct strbuf *sb, const char *placeholder,
case 'a': /* author ... */
return format_person_part(sb, placeholder[1],
msg + c->author.off, c->author.len,
- c->dmode);
+ c->pretty_ctx->date_mode);
case 'c': /* committer ... */
return format_person_part(sb, placeholder[1],
msg + c->committer.off, c->committer.len,
- c->dmode);
+ c->pretty_ctx->date_mode);
case 'e': /* encoding */
strbuf_add(sb, msg + c->encoding.off, c->encoding.len);
return 1;
@@ -741,13 +741,13 @@ static size_t format_commit_item(struct strbuf *sb, const char *placeholder,
void format_commit_message(const struct commit *commit,
const void *format, struct strbuf *sb,
- enum date_mode dmode)
+ const struct pretty_print_context *pretty_ctx)
{
struct format_commit_context context;
memset(&context, 0, sizeof(context));
context.commit = commit;
- context.dmode = dmode;
+ context.pretty_ctx = pretty_ctx;
strbuf_expand(sb, format, format_commit_item, &context);
}
@@ -900,18 +900,18 @@ void pp_remainder(enum cmit_fmt fmt,
}
void pretty_print_commit(enum cmit_fmt fmt, const struct commit *commit,
- struct strbuf *sb, int abbrev,
- const char *subject, const char *after_subject,
- enum date_mode dmode, int need_8bit_cte)
+ struct strbuf *sb,
+ const struct pretty_print_context *context)
{
unsigned long beginning_of_body;
int indent = 4;
const char *msg = commit->buffer;
char *reencoded;
const char *encoding;
+ int need_8bit_cte = context->need_8bit_cte;
if (fmt == CMIT_FMT_USERFORMAT) {
- format_commit_message(commit, user_format, sb, dmode);
+ format_commit_message(commit, user_format, sb, context);
return;
}
@@ -946,8 +946,9 @@ void pretty_print_commit(enum cmit_fmt fmt, const struct commit *commit,
}
}
- pp_header(fmt, abbrev, dmode, encoding, commit, &msg, sb);
- if (fmt != CMIT_FMT_ONELINE && !subject) {
+ pp_header(fmt, context->abbrev, context->date_mode, encoding,
+ commit, &msg, sb);
+ if (fmt != CMIT_FMT_ONELINE && !context->subject) {
strbuf_addch(sb, '\n');
}
@@ -956,8 +957,8 @@ void pretty_print_commit(enum cmit_fmt fmt, const struct commit *commit,
/* These formats treat the title line specially. */
if (fmt == CMIT_FMT_ONELINE || fmt == CMIT_FMT_EMAIL)
- pp_title_line(fmt, &msg, sb, subject,
- after_subject, encoding, need_8bit_cte);
+ pp_title_line(fmt, &msg, sb, context->subject,
+ context->after_subject, encoding, need_8bit_cte);
beginning_of_body = sb->len;
if (fmt != CMIT_FMT_ONELINE)
--
1.6.5.116.gfe4b9
^ permalink raw reply related
* Re: [RFC PATCH 1/4] Document the HTTP transport protocol
From: Shawn O. Pearce @ 2009-10-16 14:21 UTC (permalink / raw)
To: Mike Hommey; +Cc: H. Peter Anvin, Antti-Juhani Kaijanaho, git
In-Reply-To: <20091016071942.GC3009@glandium.org>
Mike Hommey <mh@glandium.org> wrote:
> On Thu, Oct 15, 2009 at 10:59:25PM -0700, H. Peter Anvin wrote:
> > On 10/10/2009 03:12 AM, Antti-Juhani Kaijanaho wrote:
> > > On 2009-10-09, Junio C Hamano <gitster@pobox.com> wrote:
> > >>> +If there is no repository at $GIT_URL, the server MUST respond with
> > >>> +the '404 Not Found' HTTP status code.
> > >>
> > >> We may also want to add
> > >>
> > >> If there is no object at $GIT_URL/some/path, the server MUST respond
> > >> with the '404 Not Found' HTTP status code.
> > >>
> > >> to help dumb clients.
> > >
> > > In both cases - is it really necessary to forbid the use of 410 (Gone)?
My original text got taken a bit out of context here. I guess MUST
was too strong of a word. I more ment something like:
If there is no repository at $GIT_URL, the server MUST NOT respond
with '200 OK' and a valid info/refs response. A server SHOULD
respond with '404 Not Found', '410 Gone', or any other suitable
HTTP status code which does not imply the resource exists as
requested.
> > 410 means "we once had it, it's no longer here, no idea where it went."
> > It's a largely useless code...
>
> There is an additional meaning to it, that is "it will never ever
> return". It thus has a stronger meaning than 404. Sadly, not even search
> engine spiders consider it as a hint to not crawl there in the future...
I know. I broke a URL on a site back in Janurary, MSN keeps crawling
it anyway. F'king spiders.
--
Shawn.
^ 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