* Re: How can I tell if a file has been updated upstream?
From: Timur Tabi @ 2010-02-05 16:56 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20100205164407.GA27498@spearce.org>
On Fri, Feb 5, 2010 at 10:44 AM, Shawn O. Pearce <spearce@spearce.org> wrote:
> You can't tell a particular file, but you could use something like
> `git ls-remote refs/heads/master` to see what the branch is at,
$ git ls-remote refs/heads/master
fatal: 'refs/heads/master' does not appear to be a git repository
fatal: The remote end hung up unexpectedly
So maybe you meant this:
$ git ls-remote ssh://git.am.freescale.net/git/timur/bin refs/heads/master
20fbe12069038057cbd0d66c5a673956f7792c7d refs/heads/master
I can use this to compare with the local HEAD. However, this only
tells me that the repository as a whole has changed. I was hoping
there would be a way to see if just the one file has change. I.e. how
can I get the HEAD of a *file* in a remote repository.
> I do this in repo, only I run `git fetch` once per day for the
> end-user. That way the objects are local, and I can use a local
> check to see if there are updates that need to be pulled into the
> executable working directory.
Yeah, I'm not keen on performing an actual download, even if it's just a fetch.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: How can I tell if a file has been updated upstream?
From: Junio C Hamano @ 2010-02-05 16:50 UTC (permalink / raw)
To: Timur Tabi; +Cc: git
In-Reply-To: <ed82fe3e1002050823gec57827j184c9c4cff4f4a45@mail.gmail.com>
Timur Tabi <timur@freescale.com> writes:
> The reason I ask is that I have a set of Python scripts that I
> distribute via git (other people in the company clone my repository).
> I want my script, every time it's run, to check if an update is
> available, and ask the user to do "git pull".
So whenever I run your script it calls home, spend a roundtrip time, and
nags me to update? I don't want to be working with you unless I can go
without running that script less often than once a week ;-)
You need to teach it how to call home. How do your users "clone"? Some
over git://, some others over ssh://, yet some others over local
filesystem? Also how do they run the script? Directly out of the
repository work tree, or is there a "make install" step involved?
If your users are running from the work tree copy unmodified, then you
would need to look at sys.argv[0] to find out where it is, use that to
find the repository, and using its .git/config learn how the user pulls
from your repository (i.e. git config remote.origin.url), and at the same
time which version it is (i.e. git rev-parse HEAD). If "make install" is
involved, then you would hardcode the necessary information during the
build process to the script your users would run.
At runtime, you would run "ls-remote HEAD" and compare with the version
you are running. It may be stale, or it may not be.
How big is the script? It _might_ be faster to distribute a launcher that
downloads the real script every time it runs and runs that fresh copy that
is guaranteed to be the latest than doing all the hassle of the above.
^ permalink raw reply
* Re: How can I tell if a file has been updated upstream?
From: Shawn O. Pearce @ 2010-02-05 16:44 UTC (permalink / raw)
To: Timur Tabi; +Cc: git
In-Reply-To: <ed82fe3e1002050823gec57827j184c9c4cff4f4a45@mail.gmail.com>
Timur Tabi <timur@freescale.com> wrote:
> Is there a way for me to tell if a particular file in my repository
> has an update in the upstream repository? For example, the SHA of the
> HEAD is different in the remote repository than it is of the HEAD in
> the local repository.
>
> The reason I ask is that I have a set of Python scripts that I
> distribute via git (other people in the company clone my repository).
> I want my script, every time it's run, to check if an update is
> available, and ask the user to do "git pull".
You can't tell a particular file, but you could use something like
`git ls-remote refs/heads/master` to see what the branch is at,
and compare that to the last known commit. If its changed, then
suggest the user do a fetch.
I do this in repo, only I run `git fetch` once per day for the
end-user. That way the objects are local, and I can use a local
check to see if there are updates that need to be pulled into the
executable working directory.
--
Shawn.
^ permalink raw reply
* How can I tell if a file has been updated upstream?
From: Timur Tabi @ 2010-02-05 16:23 UTC (permalink / raw)
To: git
Is there a way for me to tell if a particular file in my repository
has an update in the upstream repository? For example, the SHA of the
HEAD is different in the remote repository than it is of the HEAD in
the local repository.
The reason I ask is that I have a set of Python scripts that I
distribute via git (other people in the company clone my repository).
I want my script, every time it's run, to check if an update is
available, and ask the user to do "git pull".
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH] push: Use sideband channel for hook messages
From: Erik Faye-Lund @ 2010-02-05 16:14 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Shawn O. Pearce, Junio C Hamano, git
In-Reply-To: <4B6C3E9C.7040009@viscovery.net>
On Fri, Feb 5, 2010 at 4:51 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> Shawn O. Pearce schrieb:
>> Johannes Sixt <j.sixt@viscovery.net> wrote:
>>> What would you think about passing both channels to the async callback,
>>> and the communicating parties must agree on which channel they communicate
>>> by closing the unused one? It would require slight changes to all current
>>> async users, though. (It also requires in the threaded case that we pass
>>> dup()s of the pipe channels.)
>>
>> Yup, I could do that. I feel like it might be over-engineering the
>> solution a bit. But I'll respin the patch by splitting it apart,
>> and doing a bidirectional async here, since you asked nicely.
>
> I do agree about the over-engineering aspect. I mentioned it because in
> one patch in the past Erik Faye-Lund also extended the async
> infrastructure for bidirectional communication to use it in git-daemon
> (Windows port).
Just for reference, here's the latest version I wrote of that patch,
in case it's useful to have a peak at or something:
http://repo.or.cz/w/git/kusma.git/commit/682d90a174fc128910c1c8a4f81edb3cf9f0d9e2
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* Re: [PATCH 1/4] gitweb: notes feature
From: Junio C Hamano @ 2010-02-05 16:10 UTC (permalink / raw)
To: Johan Herland; +Cc: Giuseppe Bilotta, Jakub Narebski, git, Johannes Schindelin
In-Reply-To: <201002051136.43738.johan@herland.net>
Johan Herland <johan@herland.net> writes:
> I already maintain a TODO list at the end of the cover letter to the notes
> series. Here is a preview of it (I plan to send the next iteration of
> jh/notes as soon as v1.7.0 is released):
> ...
Random additional thoughts.
* Futureproofing
We have to admit that our notes support, especially on the output side, is
still in its infancy. We may want to advertise it as such -- highly
experimental and subject to change.
* format-patch
To add notes to format-patch output, we might want to do something like:
$ git format-patch --notes-ref=commits --notes-ref=amlog -1
and produce:
From 8bff7c5383ed833bd1df9c8d85c00a27af3e5b02 Mon Sep 17 00:00:00 2001
From: Andrew Myrick <amyrick@apple.com>
Date: Sat, 30 Jan 2010 03:14:22 +0000
Subject: [PATCH] git-svn: persistent memoization
X-Notes: pulled on Fri Feb 5 07:36:12 2010 -0800
from git://git.bogomips.org/git-svn.git/
X-Notes-amlog: <1264821262-28322-1-git-send-email-amyrick@apple.com>
Make memoization of the svn:mergeinfo processing functions persistent with
...
Points to notice:
- There is no point forcing users to spell "--notes-ref" parameter
starting from refs/notes/; we should DWIM if they are missing;
- We would want to allow more than one notes hierarchy specified. This
would affect format_note() function---take list of struct notes_tree,
perhaps;
- Allow callers of tell format_note() to add the name of the notes
hierarchy the note came from (or just always add it if it is not the
default "refs/notes/commits").
- For format-patch that produces a mbox output, the email header part may
be a better place to put notes (obeying the usual "indent by one space
to continue the line" convention).
* "log --format=%N" and "log --show-notes"
Currently %N expands to the hardcoded "log --show-notes" default format.
We can probably keep it that way. When the user asked for a non default
notes hierarchy (i.e. other than refs/notes/commits), we may want to
adjust "Notes:" string to use "Notes-%s:" to show which hierarchy it came
from, and concatenate them together.
For "log --show-notes" output, we also might want to move the notes to the
header part like I illustrated above in format-patch output, instead of
"start with unindented Notes: and indented body at the end". I.e. instead
of showing this:
$ git log --notes-ref=amlog -1 4d0cc22
commit 4d0cc2243778b38c3759c6a08f4f1ed64155a070
Author: Junio C Hamano <gitster@pobox.com>
Date: Thu Feb 4 11:10:44 2010 -0800
fast-import: count --max-pack-size in bytes
Similar in spirit to 07cf0f2 (make --max-pack-size argument to 'git
...
Acked-by: Nicolas Pitre <nico@fluxnic.net>
Notes:
<7v4olwbyvf.fsf_-_@alter.siamese.dyndns.org>
show it like this:
$ git log --notes-ref=amlog -1 4d0cc22
commit 4d0cc2243778b38c3759c6a08f4f1ed64155a070
Author: Junio C Hamano <gitster@pobox.com>
Date: Thu Feb 4 11:10:44 2010 -0800
Notes-amlog: <7v4olwbyvf.fsf_-_@alter.siamese.dyndns.org>
fast-import: count --max-pack-size in bytes
Similar in spirit to 07cf0f2 (make --max-pack-size argument to 'git
...
Acked-by: Nicolas Pitre <nico@fluxnic.net>
^ permalink raw reply
* Re: [PATCH] push: Use sideband channel for hook messages
From: Johannes Sixt @ 2010-02-05 15:51 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20100205153252.GC19255@spearce.org>
Shawn O. Pearce schrieb:
> Johannes Sixt <j.sixt@viscovery.net> wrote:
>> What would you think about passing both channels to the async callback,
>> and the communicating parties must agree on which channel they communicate
>> by closing the unused one? It would require slight changes to all current
>> async users, though. (It also requires in the threaded case that we pass
>> dup()s of the pipe channels.)
>
> Yup, I could do that. I feel like it might be over-engineering the
> solution a bit. But I'll respin the patch by splitting it apart,
> and doing a bidirectional async here, since you asked nicely.
I do agree about the over-engineering aspect. I mentioned it because in
one patch in the past Erik Faye-Lund also extended the async
infrastructure for bidirectional communication to use it in git-daemon
(Windows port). Meanwhile, he's abandoned this approach because there were
unsurmountable obstacles elsewhere; so if you introduce bidi now, it would
not immediately buy us anything.
It's your draw.
-- Hannes
^ permalink raw reply
* Re: notes TODOs (was: Re: [PATCH 1/4] gitweb: notes feature)
From: Jakub Narebski @ 2010-02-05 15:27 UTC (permalink / raw)
To: Johan Herland; +Cc: Giuseppe Bilotta, Junio C Hamano, git, Johannes Schindelin
In-Reply-To: <201002051546.19406.johan@herland.net>
On Fri, 5 Feb 2010, Johan Herland wrote:
> On Friday 05 February 2010, Giuseppe Bilotta wrote:
> > If I may be allowed to add a suggestion to put in the list, I would
> > like to see notes attachable to named refs (branch heads in
> > particular). From a cursory reading of your patches currently in pu
> > it would seem that you explicitly prohibit this case currently.
> > However, this has many possible uses, ranging from longer branch
> > descriptions to tracking information to improve survival in case of
> > remote rebases.
>
> Nope. There is no explicit prohibition on anything. On a fundamental
> level, Git-notes simply maps a given SHA1 (the annotated object) to
> another SHA1 (the object holding the annotation itself). In principle
> you can annotate _any_ SHA1, it doesn't even have to exist as a git
> object!
I guess that it isn't currently possible to map _path_ (here: fully
qualified name of ref, i.e. "refs/heads/master" in example) to SHA1
rather than SHA1 to SHA1, as fan-outs assumes mapping of SHA1 (to
object).
>
> In fact, something like the following abomination should solve
> your "problem" quite easily:
>
> git notes add $(echo "refs/heads/master" | git hash-object --stdin)
>
> (...washing my hands...)
This actually annotates (existing or not) _blob_ object with
"refs/heads/master" as contents (git-hash-object defaults to -t blob).
>
> > And one last comment: how do notes behave wrt to cloning and remote
> > handling? Am I correct in my understanding that notes are
> > (presently) local only? Would it make sense to have them cloned to
> > something like the refs/notes/remotes/* namespace?
>
> They are no more local than any other ref, except that they are
> outside the refspecs that are "usually" pushed/fetched (refs/heads/
> and refs/tags/).
>
> git push <remote> refs/notes/<foo>
> git fetch <remote> refs/notes/<foo>[:refs/notes/<foo>]
> etc.
>
> should all work as expected.
It would be nice, but I guess not possible, to have notes autofollowed
on fetch, like tags are autofollowed...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] push: Use sideband channel for hook messages
From: Shawn O. Pearce @ 2010-02-05 15:32 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, git
In-Reply-To: <4B6C07E3.5030705@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> wrote:
> Shawn O. Pearce schrieb:
> > Rather than sending hook messages over stderr, and losing them
> > entirely on git:// and smart HTTP transports,
>
> I don't think "losing them entirely" is true for the git:// protocol:
> git-daemon writes receive-pack's stderr to the syslog.
>
> The question is whether hook errors are intended for the remote side or
> for the repository owner. Generally, I'd say for the latter. But since
> your patch is about pushing, a repository owner must already trust the
> remote side, and then it can be argued that in this case errors can be
> sent to the remote.
I think everyone expects hook errors on the client.
Most people push over authenticated SSH, where hook messages come
back on stderr. For these folks, if they wanted something in syslog,
they'd send it there directly from the hook.
I doubt there are many anonymous pushes allowed over git://. But,
yea, sure, I could see someone setting up their server with an
update hook to only permit pushes to the refs/heads/mob branch and
logging access failures to syslog by echoing to stderr. I think
these people are in the vast minority, and might not even want this
behavior by default. Maybe I'm just a jerk, but if they want their
hooks to continue to echo to syslog rather than to the client,
they can build a patch on top of this to git daemon which passes
a flag down into receive-pack to disable the side band channel.
> > diff --git a/run-command.c b/run-command.c
> > index cf2d8f7..7d1fd88 100644
> > @@ -228,6 +231,8 @@ fail_pipe:
> >
> > if (need_err)
> > close(fderr[1]);
> > + else if (cmd->err)
> > + close(cmd->err);
>
> This requires similar adjustments in the Windows part.
>
> Documentation/technical/api-runcommand.txt should be an update, too.
Ouch, good catch. Will fix.
> > @@ -326,10 +331,19 @@ static unsigned __stdcall run_thread(void *data)
> > int start_async(struct async *async)
> > {
> > int pipe_out[2];
> > + int proc_fd, call_fd;
> >
> > if (pipe(pipe_out) < 0)
> > return error("cannot create pipe: %s", strerror(errno));
> > - async->out = pipe_out[0];
> > +
> > + if (async->is_reader) {
> > + proc_fd = pipe_out[0];
> > + call_fd = pipe_out[1];
> > + } else {
> > + call_fd = pipe_out[0];
> > + proc_fd = pipe_out[1];
> > + }
> > + async->out = call_fd;
>
> I don't particularly like this approach because it restricts the async
> procedures to a one-way communication.
Well, its always been one way. With the async function writing to the
main application consumer.
> What would you think about passing both channels to the async callback,
> and the communicating parties must agree on which channel they communicate
> by closing the unused one? It would require slight changes to all current
> async users, though. (It also requires in the threaded case that we pass
> dup()s of the pipe channels.)
Yup, I could do that. I feel like it might be over-engineering the
solution a bit. But I'll respin the patch by splitting it apart,
and doing a bidirectional async here, since you asked nicely.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Remove .git auto detection from setup_git_env()
From: Jeff King @ 2010-02-05 15:12 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1265370468-6147-1-git-send-email-pclouds@gmail.com>
On Fri, Feb 05, 2010 at 06:47:48PM +0700, Nguyễn Thái Ngọc Duy wrote:
> When GIT_DIR environment variable is not specified, .git will be
> searched if a repository is needed. Currently this can be done in two
> places: setup_git_directory_gently() and setup_git_env().
>
> The one in setup_git_env() is no longer correct and should IMHO have
> been removed since the introduction of setup_git_directory_gently() in
> d288a70. Having two ways of auto detection may lead to obscure errors
> because .git may be misdetected by setup_git_env(),
> automatically called via git_path(), which is all over the place.
>
> This patch makes setup_git_env() die if GIT_DIR is not explictly
> set. That's setup_git_directory_gently()'s job. If you ever want to
> touch things inside $GIT_DIR, you should have already called
> setup_git_directory_gently().
>
> This patch breaks commands (in a good way) and obviously not for
> mainline. I still have to go through "make test" to see how many are
> impacted. But I think this is a good change. Am I missing something?
It has been a while since I looked at this code, but I think this is a
good direction forward. I remember trying something like this and
getting discouraged at all of the ensuing breakage. So if you can track
down all of the fallouts and fix them, I think we will be better off in
the long run.
-Peff
^ permalink raw reply
* Re: [PATCH] fix an error message in git-push so it goes to stderr
From: Jeff King @ 2010-02-05 15:06 UTC (permalink / raw)
To: Larry D'Anna; +Cc: git
In-Reply-To: <20100205004140.GA2841@cthulhu>
On Thu, Feb 04, 2010 at 07:41:40PM -0500, Larry D'Anna wrote:
> Having it go to standard output interferes with git-push --porcelain.
> ---
> builtin-push.c | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/builtin-push.c b/builtin-push.c
> index 5633f0a..0a27072 100644
> --- a/builtin-push.c
> +++ b/builtin-push.c
> @@ -124,9 +124,9 @@ static int push_with_options(struct transport *transport, int flags)
> return 0;
>
> if (nonfastforward && advice_push_nonfastforward) {
> - printf("To prevent you from losing history, non-fast-forward updates were rejected\n"
> - "Merge the remote changes before pushing again. See the 'Note about\n"
> - "fast-forwards' section of 'git push --help' for details.\n");
> + fprintf(stderr, "To prevent you from losing history, non-fast-forward updates were rejected\n"
> + "Merge the remote changes before pushing again. See the 'Note about\n"
> + "fast-forwards' section of 'git push --help' for details.\n");
I agree that stderr is a more sensible place for such a message to go,
but shouldn't the porcelain output format just suppress it entirely? The
whole point of it is to be machine readable, and this text is
a. formatted for humans
b. totally redundant with the machine-readable information presented
earlier
-Peff
^ permalink raw reply
* Re: notes TODOs (was: Re: [PATCH 1/4] gitweb: notes feature)
From: Johan Herland @ 2010-02-05 14:46 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: Junio C Hamano, Jakub Narebski, git, Johannes Schindelin
In-Reply-To: <cb7bb73a1002050444y55f57696gb1b3bd06ab9261ac@mail.gmail.com>
On Friday 05 February 2010, Giuseppe Bilotta wrote:
> On Fri, Feb 5, 2010 at 11:36 AM, Johan Herland wrote:
> > - Better integration with rebase/amend/cherry-pick. Optionally
> > bring notes across a commit rewrite. Controlled by command-line
> > options and/or config variables. Add "git notes move" and "git
> > notes copy" to suit. Junio says:
> > I used to fix minor issues (styles, decl-after-stmt, etc.) using
> > rebase-i long after running "am" in bulk, but these days I find
> > myself going back to my "inbox" and fix them in MUA; this is
> > only because I know these notes do not propagate across rebases
> > and amends -- adjusting the workflow to the tool's limitation is
> > not very good.
>
> It might be useful to this purpose to have a notes.<refname>.* config
> space, like for branches. This would allows us to define
> per-namespace attribute for notes, such as whether or not they get
> across rebases, whether or not (and how) they are output in
> format-patch, in logs, etc
Yes, that is a possibility, but first we need the infrastructure itself
for doing this.
> > - Junio says:
> > The interface to tell tools to use which notes ref to use should
> > be able to say "these refs", not just "this ref" i.e.
> > GIT_NOTES_REF=a:b just like PATH=a:b:c...); I am fairly certain
> > that we would want to store different kind of information in
> > separate notes trees and aggregate them, as we gain experience with
> > notes.
>
> I would say that this only makes sense when reading notes, since when
> you are writing a note you probably want to add it to a single
> specific namespace.
Of course.
> > - Junio says:
> > There should be an interface to tell tools to use which notes refs
> > via command line options; "!alias" does not TAB-complete, and "git
> > lgm" above doesn't, either. "git log --notes=notes/amlog
> > --notes=notes/other" would probably be the way to go.
>
> As mentioned elsewhere in this thread, this might be better as a git
> option rather than a subcommand option: git --notes-ref=amlog:other
> log or git --notes-ref={amlog,other} log.
Maybe. Making it a git option makes it (GIT_NOTES_REF/--notes-ref)
consistent with things like GIT_WORK_TREE/--work-tree and
GIT_DIR/--git-dir, but then I'm not sure whether notes will affect the
behaviour of enough commands to warrant it becoming a git option.
Consider for example the -m/--message subcommand option which can be
applied to several subcommands (commit, tag, notes, etc.), but that
does not make it a candidate for "promotion" to a git option (i.e.
git -m "foo" commit).
> If I may be allowed to add a suggestion to put in the list, I would
> like to see notes attachable to named refs (branch heads in
> particular). From a cursory reading of your patches currently in pu
> it would seem that you explicitly prohibit this case currently.
> However, this has many possible uses, ranging from longer branch
> descriptions to tracking information to improve survival in case of
> remote rebases.
Nope. There is no explicit prohibition on anything. On a fundamental
level, Git-notes simply maps a given SHA1 (the annotated object) to
another SHA1 (the object holding the annotation itself). In principle
you can annotate _any_ SHA1, it doesn't even have to exist as a git
object!
In fact, something like the following abomination should solve
your "problem" quite easily:
git notes add $(echo "refs/heads/master" | git hash-object --stdin)
(...washing my hands...)
> And one last comment: how do notes behave wrt to cloning and remote
> handling? Am I correct in my understanding that notes are (presently)
> local only? Would it make sense to have them cloned to something like
> the refs/notes/remotes/* namespace?
They are no more local than any other ref, except that they are outside
the refspecs that are "usually" pushed/fetched (refs/heads/ and
refs/tags/).
git push <remote> refs/notes/<foo>
git fetch <remote> refs/notes/<foo>[:refs/notes/<foo>]
etc.
should all work as expected.
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* notes TODOs (was: Re: [PATCH 1/4] gitweb: notes feature)
From: Giuseppe Bilotta @ 2010-02-05 12:44 UTC (permalink / raw)
To: Johan Herland; +Cc: Junio C Hamano, Jakub Narebski, git, Johannes Schindelin
On Fri, Feb 5, 2010 at 11:36 AM, Johan Herland <johan@herland.net> wrote:
>
> I already maintain a TODO list at the end of the cover letter to the notes
> series. Here is a preview of it (I plan to send the next iteration of
> jh/notes as soon as v1.7.0 is released):
>
>
> - Suggestion by Matthieu Moy and Sverre Rabbelier:
> Add notes support to git-format-patch, where note contents in
> refs/notes/format-patch are added to the "comments section"
> (i.e. following the '---' separator) of generated patches.
>
> - Better integration with rebase/amend/cherry-pick. Optionally bring
> notes across a commit rewrite. Controlled by command-line options
> and/or config variables. Add "git notes move" and "git notes copy"
> to suit. Junio says:
> I used to fix minor issues (styles, decl-after-stmt, etc.) using
> rebase-i long after running "am" in bulk, but these days I find
> myself going back to my "inbox" and fix them in MUA; this is
> only because I know these notes do not propagate across rebases
> and amends -- adjusting the workflow to the tool's limitation is
> not very good.
It might be useful to this purpose to have a notes.<refname>.* config
space, like for branches. This would allows us to define per-namespace
attribute for notes, such as whether or not they get across rebases,
whether or not (and how) they are output in format-patch, in logs, etc
> - Junio says:
> The interface to tell tools to use which notes ref to use should be
> able to say "these refs", not just "this ref" i.e. GIT_NOTES_REF=a:b
> just like PATH=a:b:c...); I am fairly certain that we would want to
> store different kind of information in separate notes trees and
> aggregate them, as we gain experience with notes.
I would say that this only makes sense when reading notes, since when
you are writing a note you probably want to add it to a single
specific namespace.
For multiple refs I was thinking about shell expansion patterns, with
syntax such as {a,b} rather than a:b; even shell globs might make
sense (so e.g. * would mean 'all existing notes ref namespaces', bug*
all namespaces starting with bug, etc).
Of course the use of multiple namespaces also means that users
(whether human or script) need to be able to teel which namespace each
note comes from.
> - Junio says:
> There should be an interface to tell tools to use which notes refs via
> command line options; "!alias" does not TAB-complete, and "git lgm"
> above doesn't, either. "git log --notes=notes/amlog --notes=notes/other"
> would probably be the way to go.
As mentioned elsewhere in this thread, this might be better as a git
option rather than a subcommand option: git --notes-ref=amlog:other
log or git --notes-ref={amlog,other} log.
If I may be allowed to add a suggestion to put in the list, I would
like to see notes attachable to named refs (branch heads in
particular). From a cursory reading of your patches currently in pu it
would seem that you explicitly prohibit this case currently. However,
this has many possible uses, ranging from longer branch descriptions
to tracking information to improve survival in case of remote rebases.
And one last comment: how do notes behave wrt to cloning and remote
handling? Am I correct in my understanding that notes are (presently)
local only? Would it make sense to have them cloned to something like
the refs/notes/remotes/* namespace?
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: [PATCH] push: Use sideband channel for hook messages
From: Ilari Liusvaara @ 2010-02-05 12:07 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20100205033748.GA19255@spearce.org>
On Thu, Feb 04, 2010 at 07:37:48PM -0800, Shawn O. Pearce wrote:
> Rather than sending hook messages over stderr, and losing them
> entirely on git:// and smart HTTP transports, receive-pack now
> puts them onto a multiplexed sideband channel if the send-pack
> client asks for the side-band-64k capablity. This ensures that
> hooks from the server can report their detailed error messages,
> if any, no matter what git-aware transport is being used.
>
> When the side band channel is being used the push client will wind up
> prefixing all server messages with "remote: ", just like fetch does.
I tested this a bit with git-remote-gits / git-daemon2. Seems to
work.
-Ilari
^ permalink raw reply
* Re: [PATCH] push: Use sideband channel for hook messages
From: Johannes Sixt @ 2010-02-05 11:58 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20100205033748.GA19255@spearce.org>
Shawn O. Pearce schrieb:
> Rather than sending hook messages over stderr, and losing them
> entirely on git:// and smart HTTP transports,
I don't think "losing them entirely" is true for the git:// protocol:
git-daemon writes receive-pack's stderr to the syslog.
The question is whether hook errors are intended for the remote side or
for the repository owner. Generally, I'd say for the latter. But since
your patch is about pushing, a repository owner must already trust the
remote side, and then it can be argued that in this case errors can be
sent to the remote.
> diff --git a/run-command.c b/run-command.c
> index cf2d8f7..7d1fd88 100644
> --- a/run-command.c
> +++ b/run-command.c
> @@ -94,6 +94,9 @@ fail_pipe:
> else if (need_err) {
> dup2(fderr[1], 2);
> close_pair(fderr);
> + } else if (cmd->err > 1) {
> + dup2(cmd->err, 2);
> + close(cmd->err);
> }
>
> if (cmd->no_stdout)
> @@ -228,6 +231,8 @@ fail_pipe:
>
> if (need_err)
> close(fderr[1]);
> + else if (cmd->err)
> + close(cmd->err);
>
> return 0;
> }
This requires similar adjustments in the Windows part.
Documentation/technical/api-runcommand.txt should be an update, too.
> @@ -326,10 +331,19 @@ static unsigned __stdcall run_thread(void *data)
> int start_async(struct async *async)
> {
> int pipe_out[2];
> + int proc_fd, call_fd;
>
> if (pipe(pipe_out) < 0)
> return error("cannot create pipe: %s", strerror(errno));
> - async->out = pipe_out[0];
> +
> + if (async->is_reader) {
> + proc_fd = pipe_out[0];
> + call_fd = pipe_out[1];
> + } else {
> + call_fd = pipe_out[0];
> + proc_fd = pipe_out[1];
> + }
> + async->out = call_fd;
I don't particularly like this approach because it restricts the async
procedures to a one-way communication.
What would you think about passing both channels to the async callback,
and the communicating parties must agree on which channel they communicate
by closing the unused one? It would require slight changes to all current
async users, though. (It also requires in the threaded case that we pass
dup()s of the pipe channels.)
-- Hannes
^ permalink raw reply
* [PATCH] Remove .git auto detection from setup_git_env()
From: Nguyễn Thái Ngọc Duy @ 2010-02-05 11:47 UTC (permalink / raw)
To: git; +Cc: Nguyễn Thái Ngọc Duy
When GIT_DIR environment variable is not specified, .git will be
searched if a repository is needed. Currently this can be done in two
places: setup_git_directory_gently() and setup_git_env().
The one in setup_git_env() is no longer correct and should IMHO have
been removed since the introduction of setup_git_directory_gently() in
d288a70. Having two ways of auto detection may lead to obscure errors
because .git may be misdetected by setup_git_env(),
automatically called via git_path(), which is all over the place.
This patch makes setup_git_env() die if GIT_DIR is not explictly
set. That's setup_git_directory_gently()'s job. If you ever want to
touch things inside $GIT_DIR, you should have already called
setup_git_directory_gently().
This patch breaks commands (in a good way) and obviously not for
mainline. I still have to go through "make test" to see how many are
impacted. But I think this is a good change. Am I missing something?
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
environment.c | 4 +---
setup.c | 4 +++-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/environment.c b/environment.c
index 739ec27..b609569 100644
--- a/environment.c
+++ b/environment.c
@@ -67,9 +67,7 @@ static void setup_git_env(void)
{
git_dir = getenv(GIT_DIR_ENVIRONMENT);
if (!git_dir)
- git_dir = read_gitfile_gently(DEFAULT_GIT_DIR_ENVIRONMENT);
- if (!git_dir)
- git_dir = DEFAULT_GIT_DIR_ENVIRONMENT;
+ die("GIT_DIR not properly set");
git_object_dir = getenv(DB_ENVIRONMENT);
if (!git_object_dir) {
git_object_dir = xmalloc(strlen(git_dir) + 9);
diff --git a/setup.c b/setup.c
index 710e2f3..ae1ba52 100644
--- a/setup.c
+++ b/setup.c
@@ -396,8 +396,10 @@ const char *setup_git_directory_gently(int *nongit_ok)
die("Repository setup failed");
break;
}
- if (is_git_directory(DEFAULT_GIT_DIR_ENVIRONMENT))
+ if (is_git_directory(DEFAULT_GIT_DIR_ENVIRONMENT)) {
+ set_git_dir(DEFAULT_GIT_DIR_ENVIRONMENT);
break;
+ }
if (is_git_directory(".")) {
inside_git_dir = 1;
if (!work_tree_env)
--
1.7.0.rc0.54.gd33ef
^ permalink raw reply related
* Re: reverting vs resetting
From: Mihamina Rakotomandimby @ 2010-02-05 11:21 UTC (permalink / raw)
To: git
In-Reply-To: <vpqwryskrbi.fsf@bauges.imag.fr>
> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> :
> So would I, and to complement Junio's answer
Thank you all.
--
Architecte Informatique chez Blueline/Gulfsat:
Administration Systeme, Recherche & Developpement
+261 34 29 155 34 / +261 33 11 207 36
^ permalink raw reply
* Re: [PATCH 1/4] gitweb: notes feature
From: Johan Herland @ 2010-02-05 10:36 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: Junio C Hamano, Jakub Narebski, git, Johannes Schindelin
In-Reply-To: <cb7bb73a1002041538m64c6a6b3p5ee8bbaf0d78457@mail.gmail.com>
On Friday 05 February 2010, Giuseppe Bilotta wrote:
> On Thu, Feb 4, 2010 at 10:03 PM, Junio C Hamano <gitster@pobox.com> wrote:
> > I expect more ideas from needs by end-user would come, as we gain
> > experience with using notes in real projects. You will certainly find
> > some other needs of your own, like the "not an environment but a
> > command line option" which Jakub mentioned, and "multiple hierarchies"
> > like both you and I found need for. Share them and let us together
> > make the notes mechanism nicer to use.
>
> Collecting those ideas together would also help define some sort of
> roadmap, or at least have a clear idea of what's needed, to help drive
> the design of the features themselves. Maybe we could start a TODO
> page on the wiki collecting these ideas?
I already maintain a TODO list at the end of the cover letter to the notes
series. Here is a preview of it (I plan to send the next iteration of
jh/notes as soon as v1.7.0 is released):
- Suggestion by Matthieu Moy and Sverre Rabbelier:
Add notes support to git-format-patch, where note contents in
refs/notes/format-patch are added to the "comments section"
(i.e. following the '---' separator) of generated patches.
- Better integration with rebase/amend/cherry-pick. Optionally bring
notes across a commit rewrite. Controlled by command-line options
and/or config variables. Add "git notes move" and "git notes copy"
to suit. Junio says:
I used to fix minor issues (styles, decl-after-stmt, etc.) using
rebase-i long after running "am" in bulk, but these days I find
myself going back to my "inbox" and fix them in MUA; this is
only because I know these notes do not propagate across rebases
and amends -- adjusting the workflow to the tool's limitation is
not very good.
- Junio says:
The interface to tell tools to use which notes ref to use should be
able to say "these refs", not just "this ref" i.e. GIT_NOTES_REF=a:b
just like PATH=a:b:c...); I am fairly certain that we would want to
store different kind of information in separate notes trees and
aggregate them, as we gain experience with notes.
- Junio says:
There should be an interface to tell tools to use which notes refs via
command line options; "!alias" does not TAB-complete, and "git lgm"
above doesn't, either. "git log --notes=notes/amlog --notes=notes/other"
would probably be the way to go.
- Add a "git notes grep" subcommand: Junio says:
While reviewing the "inbox", I sometimes wonder if I applied a message
to somewhere already, but there is no obvious way to grep in the notes
tree and get the object name that a note is attached to. Of course I
know I can "git grep -c johan@herland.net notes/amlog" and it will give
me something like:
notes/amlog:65807ee697a28cb30b8ad38ebb8b84cebd3f255d:1
notes/amlog:c789176020d6a008821e01af8b65f28abc138d4b:1
but this won't scale and needs scripting to mechanize, once we start
rebalancing the notes tree with different fan-outs. The end user (me
in this case) is interested in "set of objects that match this grep
criteria", not "the pathnames the notes tree's implementation happens
to use to store notes for them in the hierarchy".
- Handle note objects that are not blobs, but trees
(- Rewrite fast-import notes code to use new notes API with non-note
support)
Have fun! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [PATCH] git-svn: persistent memoization
From: Eric Wong @ 2010-02-05 10:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, sam, Andrew Myrick
In-Reply-To: <49FDA6F7-21D8-4280-A6A7-80EC2F749EA9@apple.com>
Andrew Myrick <amyrick@apple.com> wrote:
> On Jan 31, 2010, at 8:03 PM, Eric Wong wrote:
> > Andrew Myrick <amyrick@apple.com> wrote:
> >> Make memoization of the svn:mergeinfo processing functions persistent with
> >> Memoize::Storable so that the memoization tables don't need to be regenerated
> >> every time the user runs git-svn fetch.
> >>
> >> The Memoize::Storable hashes are stored in ENV{GIT_DIR}/svn/caches.
> >
> > Hi Andrew,
> >
> > Perhaps "$ENV{GIT_DIR}/svn/.caches" is better here since older versions
> > of git svn used "$ENV{GIT_DIR}/svn/$refname" in the top-level and
> > "caches" may conflict with existing repos.
> >
> >> -use File::Path qw/mkpath/;
> >> +use File::Path qw/mkpath make_path/;
> >
> > File::Path::make_path is very recent not in Perls distributed by most
> > vendors. My 5.10.0 installation (Debian stable) doesn't have it, and I
> > also don't see a good reason to use it over the traditional mkpath.
> >
> > I think I'll squash the following patch and Ack. Let me know if
> > you have any objections, thanks.!
> > (also wraps long lines to 80 chars)
>
> Makes sense to me. Thanks, Eric.
Hi Junio,
I've acked and pushed this out to git://git.bogomips.org/git-svn
Andrew Myrick (1):
git-svn: persistent memoization
Sorry for the delay, my mind has slipped. Thanks to Andrew
for the patch and reminder.
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] git-clean: fix the description of the default behavior
From: Michael J Gruber @ 2010-02-05 9:06 UTC (permalink / raw)
To: Jay Soffian; +Cc: git, Junio C Hamano
In-Reply-To: <76718491002041316x31f02e0bq5c47a2a96aadb6f4@mail.gmail.com>
Jay Soffian venit, vidit, dixit 04.02.2010 22:16:
> On Thu, Feb 4, 2010 at 11:01 AM, Michael J Gruber
> <git@drmicha.warpmail.net> wrote:
>> fatal: clean.requireForce defaults to true and -n or -f not given; refusing to clean
>
> Bike shed:
>
> fatal: clean.requireForce defaults to true and neither -n nor -f
> given; refusing to clean
>
> j.
Assuming you're not git-am, you do read between "---" and diff, don't
you? ;)
Michael
^ permalink raw reply
* Re: reverting vs resetting
From: Matthieu Moy @ 2010-02-05 8:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Avery Pennarun, Mihamina Rakotomandimby, Git Mailing List
In-Reply-To: <7v1vh0jh0p.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> git branch andy_failed_experiment
> git reset --hard HEAD~50
> ;# and perhaps revert Bob's change here as well
So would I, and to complement Junio's answer: keeping a failure
followed by a repair means this experiment will appear more or less
forever in the output of "git log", "git blame", will break "git
bisect" on that part of history, and so on. Putting it on a separate
branch avoids this, and keeps it in a safe place to show newcommers:
"see, here's what you should not do" ;-).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH 1/4] gitweb: notes feature
From: Giuseppe Bilotta @ 2010-02-05 8:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git, Johannes Schindelin, Johan Herland
In-Reply-To: <7vaavosdqq.fsf@alter.siamese.dyndns.org>
On Fri, Feb 5, 2010 at 1:55 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> Still, 1 or 2 git commands per commit is a bit too much (with shortlog
>> displaying 100 commits per page)
>
> But who said you need to display notes for all commits by default?
>
> It could be a thing that you would get _on demand_, just like patch text
> or diffstat is given only on demand by going to the commitdiff page.
But while diffstat or patch text always make sense for _any_ commit,
since you always have them; notes don't, in the sense that you might
not have notes in most of the commits, and you might actually be
looking for commits with notes.
At the very least, a view like shortlog should give an indicator that
a commit has notes, and possible the namespaces where its notes are
(e.g., you're only browsing for bugzilla notes).
Anyway, since git cat-file --batch, or --batch-check if we only want
the indicator, (didn't know about these options, btw, thanks a bunch)
means that we can get all the notes with a single extra call, what's
the problem with displaying them? ;-)
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: reverting vs resetting
From: Junio C Hamano @ 2010-02-05 7:09 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Mihamina Rakotomandimby, Git Mailing List
In-Reply-To: <32541b131002042248x5461d904r276b184533ac492a@mail.gmail.com>
Avery Pennarun <apenwarr@gmail.com> writes:
> On Fri, Feb 5, 2010 at 1:12 AM, Mihamina Rakotomandimby
> <mihamina@gulfsat.mg> wrote:
>> When we decided to giveup, we decided to get back to the configuration
>> before Bob broke it. But it would be interesting to see Andy's history.
>>
>> Reverting or resetting?
>
> Try this:
>
> git checkout HEAD~5 .
> git commit -m "reverted back to the version before this mess"
Caveat: if Andy added new paths while experimenting, the above won't
remove it. You would need something like this instead:
git read-tree -m -u HEAD~50
git commit -m "reverted back to the version before this mess"
But this all assumes that the futile experiment is worth keeping. I
highly doubt it.
I would recommend to do this:
git branch andy_failed_experiment
git reset --hard HEAD~50
;# and perhaps revert Bob's change here as well
There is no sane reason to keep the failed experiment that added nothing
of value to the history leading to the tip of the 'master' branch.
I am using the word _value_ but keep in mind that value is relative to the
purpose you have in mind. The purpose of the 'master' branch presumably
is to keep and to improve on a working configuration of the gateway box.
For that particular purpose, you have to admit that Andy's futzing around
didn't add anything of value in the result. Hence, that shouldn't be kept
in its history.
Andy and other people may be able to learn from the failed experiment
later, so it is perfectly Ok to keep the series of random hacks in a
separate branch to study at their leisure. The purpose of the branch is
different from that of the 'master': it is to serve as a catalog of
things/ideas that did _not_ work.
^ permalink raw reply
* Re: [PATCH] grep: simple test for operation in a bare repository
From: Junio C Hamano @ 2010-02-05 6:50 UTC (permalink / raw)
To: René Scharfe; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <4B6B653A.8060909@lsrfire.ath.cx>
René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> There are five more sites in git.c, path.c and setup.c where $GIT_DIR
> is set directly with setenv(). I wonder if they should better call
> set_git_dir() instead, too.
>
>
> diff --git a/setup.c b/setup.c
> index 710e2f3..5fb9b25 100644
> --- a/setup.c
> +++ b/setup.c
> @@ -406,7 +406,7 @@ const char *setup_git_directory_gently(int *nongit_ok)
> cwd[offset] = '\0';
> setenv(GIT_DIR_ENVIRONMENT, cwd, 1);
> } else
> - setenv(GIT_DIR_ENVIRONMENT, ".", 1);
> + set_git_dir(".");
> check_repository_format_gently(nongit_ok);
> return NULL;
> }
Yeah, shouldn't the other setenv() we see in the context need a similar
change as well?
^ permalink raw reply
* Re: reverting vs resetting
From: Avery Pennarun @ 2010-02-05 6:48 UTC (permalink / raw)
To: Mihamina Rakotomandimby; +Cc: Git Mailing List
In-Reply-To: <20100205091223.6b4cffb1@pbmiha.malagasy.com>
On Fri, Feb 5, 2010 at 1:12 AM, Mihamina Rakotomandimby
<mihamina@gulfsat.mg> wrote:
> When we decided to giveup, we decided to get back to the configuration
> before Bob broke it. But it would be interesting to see Andy's history.
>
> Reverting or resetting?
Try this:
git checkout HEAD~5 .
git commit -m "reverted back to the version before this mess"
Replace HEAD~5 with the revision you want it to look like. But don't
forget the "." in the checkout line! All the magic is in there. When
you specify a path ("."), git won't change the revision HEAD points
to, but it will change all the files and the index to the ones from
the specified version. Then you can commit these files, producing
effectively a single commit that undoes a bunch of previous ones.
Have fun,
Avery
^ 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