* Re: newby question about merge.
From: picca @ 2007-05-16 6:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vabw5iws8.fsf@assigned-by-dhcp.cox.net>
On Tue, 15 May 2007 14:47:51 -0700
Junio C Hamano <junkio@cox.net> wrote:
> picca <picca@synchrotron-soleil.Fr> writes:
>
> > Is it possible to add this git cat-file -p :2:filename > filename in
> > the man page of git-merge in the resolve conflict part ?
> >
> > Or a link to the documentation speaking of this stage part.
>
> See:
>
> http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#conflict-resolution
>
> As this walk through section from the user manual's already
> talks about it, I am not sure if we would want to duplicate its
> wording in git-merge manual page.
I had already red this manual but did not catch up that the :2:configure
was the git path of the files I want to retreive. In fact I was missing
the git-cat-file part and the git path.
regards, frederic
^ permalink raw reply
* Re: [StGIT PATCH] Don't use patches/<branch>/current
From: Karl Hasselström @ 2007-05-16 6:27 UTC (permalink / raw)
To: Yann Dirson; +Cc: Catalin Marinas, git
In-Reply-To: <20070515214952.GQ19253@nan92-1-81-57-214-146.fbx.proxad.net>
On 2007-05-15 23:49:52 +0200, Yann Dirson wrote:
> On Tue, May 15, 2007 at 10:36:05PM +0100, Catalin Marinas wrote:
>
> > I think it would be useful to have a version file (probably per
> > branch) and just upgrade when a mismatch is detected (in the
> > __init__ function).
>
> Sounds reasonable, but I'd rather keep that in the config file (eg.
> branch.<name>.stgit.formatversion).
I agree that explicit versioning would be a good idea -- doing
explicit upgrades at well-defined points is good headache prevention.
And I agree that the config file is a good place to put it.
I'll probably have time to whip up a patch later today. I think I'll
call the old "old" format 0, the old "new" format 1, and then use
successive integers from then on. I'll make a single version bump for
the format changes you've alreay applied, and re-do the
format-changing patches you haven't applied yet so that they have
version bumping integrated.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: Losing branches (whee, data loss)
From: Junio C Hamano @ 2007-05-16 6:12 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Git Mailing List
In-Reply-To: <464A940C.3080906@garzik.org>
Jeff Garzik <jeff@garzik.org> writes:
> Grumble!
>
> When all this started, the branch 'upstream-fixes' exists, and branch
> 'tmp' does not exist. This is my local clone of
> git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
>
> [jgarzik@pretzel libata-dev]$ git branch -m upstream-fixes tmp
> error: Could not open config file!
> fatal: Branch rename failed
Sorry to hear that.
We used to have a problem with "branch -m" when you did not have
a .git/config file (or it was unwritable). I think 1.5.0.X
series and 1.5.1 release had this bug; 1.5.1.1 and later should
have the appropriate fix.
Was this really a "whee, data loss", I wonder...?
^ permalink raw reply
* Re: Losing branches (whee, data loss)
From: Jeff Garzik @ 2007-05-16 5:54 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Git Mailing List
In-Reply-To: <8c5c35580705152248w254e4201w65da1e1ad229f6ee@mail.gmail.com>
Lars Hjemli wrote:
> On 5/16/07, Jeff Garzik <jeff@garzik.org> wrote:
>> [jgarzik@pretzel libata-dev]$ git branch -m upstream-fixes tmp
>> error: Could not open config file!
>> fatal: Branch rename failed
>
> This should have been fixed in v1.5.1.1, what version do you run?
[jgarzik@core ~]$ rpm -q git-core
git-core-1.5.0.6-1.fc6
>> [jgarzik@pretzel libata-dev]$ git-branch -m upstream-fixes tmp
>> fatal: A branch named 'tmp' already exists.
>>
>> [jgarzik@pretzel libata-dev]$ git branch -D tmp
>> Deleted branch tmp.
>
> Could you try to run "git log -g" and see if it finds your lost branch?
Doesn't seem to..
Thanks,
Jeff
^ permalink raw reply
* [PATCH] Fixed link in user-manual
From: Steffen Prohaska @ 2007-05-16 5:48 UTC (permalink / raw)
To: git; +Cc: Steffen Prohaska
link to git-mergetool was broken.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
Documentation/user-manual.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 13db969..dd1578d 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1357,7 +1357,7 @@ $ gitk --merge
These will display all commits which exist only on HEAD or on
MERGE_HEAD, and which touch an unmerged file.
-You may also use gitlink:git-mergetool, which lets you merge the
+You may also use gitlink:git-mergetool[1], which lets you merge the
unmerged files using external tools such as emacs or kdiff3.
Each time you resolve the conflicts in a file and update the index:
--
1.5.1.2
^ permalink raw reply related
* Re: Losing branches (whee, data loss)
From: Lars Hjemli @ 2007-05-16 5:48 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Git Mailing List
In-Reply-To: <464A940C.3080906@garzik.org>
On 5/16/07, Jeff Garzik <jeff@garzik.org> wrote:
> [jgarzik@pretzel libata-dev]$ git branch -m upstream-fixes tmp
> error: Could not open config file!
> fatal: Branch rename failed
This should have been fixed in v1.5.1.1, what version do you run?
> [jgarzik@pretzel libata-dev]$ git-branch -m upstream-fixes tmp
> fatal: A branch named 'tmp' already exists.
>
> [jgarzik@pretzel libata-dev]$ git branch -D tmp
> Deleted branch tmp.
Could you try to run "git log -g" and see if it finds your lost branch?
--
larsh
^ permalink raw reply
* Re: Smart fetch via HTTP?
From: Martin Langhoff @ 2007-05-16 5:25 UTC (permalink / raw)
To: Jan Hudec; +Cc: git
In-Reply-To: <20070515201006.GD3653@efreet.light.src>
On 5/16/07, Jan Hudec <bulb@ucw.cz> wrote:
> Did anyone already think about fetching over HTTP working similarly to the
> native git protocol?
Do the indexes have enough info to use them with http ranges? It'd be
chunkier than a smart protocol, but it'd still work with dumb servers.
cheers,
m
^ permalink raw reply
* Losing branches (whee, data loss)
From: Jeff Garzik @ 2007-05-16 5:18 UTC (permalink / raw)
To: Git Mailing List
Grumble!
When all this started, the branch 'upstream-fixes' exists, and branch
'tmp' does not exist. This is my local clone of
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
[jgarzik@pretzel libata-dev]$ git branch -m upstream-fixes tmp
error: Could not open config file!
fatal: Branch rename failed
[jgarzik@pretzel libata-dev]$ git-branch -m upstream-fixes tmp
fatal: A branch named 'tmp' already exists.
[jgarzik@pretzel libata-dev]$ git branch -D tmp
Deleted branch tmp.
[jgarzik@pretzel libata-dev]$ git-branch -m upstream-fixes tmp
error: refname refs/heads/upstream-fixes not found
fatal: Branch rename failed
^ permalink raw reply
* Re: [PATCH] user-manual: Add section on ignoring files
From: J. Bruce Fields @ 2007-05-16 3:30 UTC (permalink / raw)
To: Johan Herland; +Cc: git, Junio C Hamano, Randal L. Schwartz, Jakub Narebski
In-Reply-To: <200705160231.40486.johan@herland.net>
On Wed, May 16, 2007 at 02:31:40AM +0200, Johan Herland wrote:
> The todo list at the end of the user manual says that something must be
> said about .gitignore. Also, there seems to be a lack of documentation
> on how to choose between the various types of ignore files (.gitignore
> vs. .git/info/exclude, etc.).
Thanks for doing this!
> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -1188,6 +1188,75 @@ description. Tools that turn commits into email, for example, use
> the first line on the Subject line and the rest of the commit in the
> body.
>
> +[[ignoring-files]]
> +Ignoring files
> +--------------
This looks like a sensible place to add it....
> +A project will often generate files that you do 'not' want to track with git.
> +This typically includes files generated by a build process or temporary
> +backup files made by your editor. Of course, 'not' tracking files with git
> +is just a matter of 'not' calling "`git add`" on them. But it quickly becomes
> +annoying to have these untracked files lying around; e.g. they make
> +"`git add .`" and "`git commit -a`" practically useless, and they keep
> +showing up in the output of "`git status`", etc.
It might be cute to introduce this with an example; "suppose you just
imported a new project into git, build it, and run git-status. The
output you get might look like:..." etc.
> +Git therefore provides "exclude patterns" for telling git which files to
> +actively ignore. Exclude patterns are thoroughly explained in the
> +"Exclude Patterns" section of the gitlink:git-ls-files[1] manual page,
> +but the heart of the concept is simply a list of files which git should
> +ignore. Entries in the list may contain globs to specify multiple files,
> +or may be prefixed by "`!`" to explicitly include (un-ignore) a previously
> +excluded (ignored) file (i.e. later exclude patterns override earlier ones).
It might simplify things just to start off by talking about .gitignore
exclusively, rather than talking about exclude patterns in general;
something like: "Git therefore allows you to provide .gitignore files,
which consist of a list of entries, processed in order from top to
bottom, each telling git about some files to ignore...."
Then introduce the other options at the end: "for exclude patterns that
you want to be used just by one repo, or by a group of repos on one
computer, you can use .git/info/exclude or core.excludesfile." In fact,
I'd be *almost* tempted just to leave the discussion of these local
exclude files at that, and refer elsewhere for the details. Do people
really find them useful?
But those are nits. I'll happily take it as is and then revise
later....
--b.
^ permalink raw reply
* [PATCH] Re: pull/push inconsistencies
From: Daniel Barkalow @ 2007-05-16 2:50 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <46a038f90705151553h553ae9d3kc3d43af72f385a42@mail.gmail.com>
On Wed, 16 May 2007, Martin Langhoff wrote:
> My second issue is that git-push does not update
> remotes/<repo>/<headname> so if I do git-push && gitk --all it looks
> as if I haven't pushed. Misleading again. :-/
This patch is based on my "remote" series, currently in "pu". I'm not 100%
sure that this is the right behavior for the case where the change isn't a
fast-forward; if the push worked, it just assumes that you don't care if
the tracking ref would be rewound, even if the fetch wouldn't force it.
In this case, you must have rewound your head, and forced the push, so
it's implausible that you want the tracking ref to go strictly forward
when you've made the source of the ref rewind.
-Daniel
*This .sig left intentionally blank*
---- cut here ----
Update local tracking refs when pushing
This also adds a --remote option to send-pack, which specifies the
configured remote being used. It is provided automatically by
git-push, and must match the url (which is still needed, since there
could be multiple urls).
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
---
builtin-push.c | 9 +++++++--
send-pack.c | 55 ++++++++++++++++++++++++++++++++++++++++++++++---------
2 files changed, 53 insertions(+), 11 deletions(-)
diff --git a/builtin-push.c b/builtin-push.c
index 0e602f3..6084899 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -178,8 +178,13 @@ static int do_push(const char *repo)
if (!prefixcmp(dest, "http://") ||
!prefixcmp(dest, "https://"))
sender = "http-push";
- else if (thin)
- argv[dest_argc++] = "--thin";
+ else {
+ char *rem = xmalloc(strlen(remote->name) + 10);
+ sprintf(rem, "--remote=%s", remote->name);
+ argv[dest_argc++] = rem;
+ if (thin)
+ argv[dest_argc++] = "--thin";
+ }
argv[0] = sender;
argv[dest_argc++] = dest;
while (dest_refspec_nr--)
diff --git a/send-pack.c b/send-pack.c
index 6851043..eabadbe 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -177,7 +177,7 @@ static int receive_status(int in)
return ret;
}
-static int send_pack(int in, int out, int nr_refspec, char **refspec)
+static int send_pack(int in, int out, struct remote *remote, int nr_refspec, char **refspec)
{
struct ref *ref;
int new_refs;
@@ -214,18 +214,19 @@ static int send_pack(int in, int out, int nr_refspec, char **refspec)
new_refs = 0;
for (ref = remote_refs; ref; ref = ref->next) {
char old_hex[60], *new_hex;
- int delete_ref;
+ int will_delete_ref;
if (!ref->peer_ref)
continue;
- delete_ref = is_null_sha1(ref->peer_ref->new_sha1);
- if (delete_ref && !allow_deleting_refs) {
+
+ will_delete_ref = is_null_sha1(ref->peer_ref->new_sha1);
+ if (will_delete_ref && !allow_deleting_refs) {
error("remote does not support deleting refs");
ret = -2;
continue;
}
- if (!delete_ref &&
+ if (!will_delete_ref &&
!hashcmp(ref->old_sha1, ref->peer_ref->new_sha1)) {
if (verbose)
fprintf(stderr, "'%s': up-to-date\n", ref->name);
@@ -252,7 +253,7 @@ static int send_pack(int in, int out, int nr_refspec, char **refspec)
*/
if (!force_update &&
- !delete_ref &&
+ !will_delete_ref &&
!is_null_sha1(ref->old_sha1) &&
!ref->force) {
if (!has_sha1_file(ref->old_sha1) ||
@@ -276,7 +277,7 @@ static int send_pack(int in, int out, int nr_refspec, char **refspec)
}
}
hashcpy(ref->new_sha1, ref->peer_ref->new_sha1);
- if (!delete_ref)
+ if (!will_delete_ref)
new_refs++;
strcpy(old_hex, sha1_to_hex(ref->old_sha1));
new_hex = sha1_to_hex(ref->new_sha1);
@@ -291,7 +292,7 @@ static int send_pack(int in, int out, int nr_refspec, char **refspec)
else
packet_write(out, "%s %s %s",
old_hex, new_hex, ref->name);
- if (delete_ref)
+ if (will_delete_ref)
fprintf(stderr, "deleting '%s'\n", ref->name);
else {
fprintf(stderr, "updating '%s'", ref->name);
@@ -301,6 +302,28 @@ static int send_pack(int in, int out, int nr_refspec, char **refspec)
fprintf(stderr, "\n from %s\n to %s\n",
old_hex, new_hex);
}
+ if (remote) {
+ struct refspec rs;
+ rs.src = ref->name;
+ remote_find_tracking(remote, &rs);
+ if (rs.dst) {
+ struct ref_lock *lock;
+ fprintf(stderr, " Also local %s\n", rs.dst);
+ if (will_delete_ref) {
+ if (delete_ref(rs.dst, NULL)) {
+ error("Failed to delete");
+ }
+ } else {
+ lock = lock_any_ref_for_update(rs.dst, NULL);
+ if (!lock)
+ error("Failed to lock");
+ else
+ write_ref_sha1(lock, ref->new_sha1,
+ "update by push");
+ }
+ free(rs.dst);
+ }
+ }
}
packet_flush(out);
@@ -345,6 +368,8 @@ int main(int argc, char **argv)
char **heads = NULL;
int fd[2], ret;
pid_t pid;
+ char *remote_name = NULL;
+ struct remote *remote = NULL;
setup_git_directory();
git_config(git_default_config);
@@ -362,6 +387,10 @@ int main(int argc, char **argv)
receivepack = arg + 7;
continue;
}
+ if (!prefixcmp(arg, "--remote=")) {
+ remote_name = arg + 9;
+ continue;
+ }
if (!strcmp(arg, "--all")) {
send_all = 1;
continue;
@@ -394,10 +423,18 @@ int main(int argc, char **argv)
usage(send_pack_usage);
verify_remote_names(nr_heads, heads);
+ if (remote_name) {
+ remote = remote_get(remote_name);
+ if (!remote_has_uri(remote, dest)) {
+ die("Destination %s is not a uri for %s",
+ dest, remote_name);
+ }
+ }
+
pid = git_connect(fd, dest, receivepack);
if (pid < 0)
return 1;
- ret = send_pack(fd[0], fd[1], nr_heads, heads);
+ ret = send_pack(fd[0], fd[1], remote, nr_heads, heads);
close(fd[0]);
close(fd[1]);
ret |= finish_connect(pid);
--
1.5.2.rc2.90.gc593-dirty
^ permalink raw reply related
* Re: pull/push inconsistencies
From: Junio C Hamano @ 2007-05-16 2:30 UTC (permalink / raw)
To: Martin Langhoff; +Cc: J. Bruce Fields, Junio C Hamano, Git Mailing List
In-Reply-To: <46a038f90705151851i9027e01x993300b1b50d0285@mail.gmail.com>
"Martin Langhoff" <martin.langhoff@gmail.com> writes:
>> I understand him to be saying that it *doesn't* do that, and that he
>> *wants* it to.
>
> I'm probably in a bad-communication day :-/
Sorry, I think I am lacking my medication :-/
> I have locally .git/refs/remotes/origin/foo, and the remote repo has
> refs/heads/foo. I don't have .git/refs/heads/foo in this case. When I
> do git-push, it doesn't really change the remote repo, but it _tells_
> me it has.
>
> So - behaviour-wise, it's fine. It's not changing the remote repo. But
> it tells me it does. It's just plain weird and misleading...
I would agree with that it is misleading or plain wrong if it
says it updated something that it didn't.
>> People think of refs/remotes/origin as a cache of the origin
>> repository's branch heads, and they expect it to be updated on write
>> (push) as well as read (fetch).
>
> Yes ;-)
On a related note, I think recent series from Daniel, parked in
'pu' while 1.5.2 is prepared, contained a new feature to update
the refs/remotes/origin/* on the pushing repository after
git-push, to save one round of fetch (that is, pretend that you
fetched immediately after you pushed).
^ permalink raw reply
* Re: pull/push inconsistencies
From: Martin Langhoff @ 2007-05-16 1:51 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <20070516014002.GA8062@fieldses.org>
On 5/16/07, J. Bruce Fields <bfields@fieldses.org> wrote:
> On Tue, May 15, 2007 at 06:22:29PM -0700, Junio C Hamano wrote:
> > "Martin Langhoff" <martin.langhoff@gmail.com> writes:
> >
> > > There are 2 things that I see as wrong...
> > > - local .git/refs/remote/origin/foo and refs/heads/foo match - why is
> > > git-push talking about updating them?
> >
> > Ooo...
> >
> > Do you mean if you have refs/remotes/origin/foo locally, and
> > push into a repository that has refs/heads/foo (but not
> > refs/remotes/origin/foo), the push results in refs/heads/foo
> > getting updated? If that is what is happening (without any
> > refspecs to instruct git-push to do so) that sounds quite buggy.
> > I need to look into the code for this one.
>
> I understand him to be saying that it *doesn't* do that, and that he
> *wants* it to.
I'm probably in a bad-communication day :-/
I have locally .git/refs/remotes/origin/foo, and the remote repo has
refs/heads/foo. I don't have .git/refs/heads/foo in this case. When I
do git-push, it doesn't really change the remote repo, but it _tells_
me it has.
So - behaviour-wise, it's fine. It's not changing the remote repo. But
it tells me it does. It's just plain weird and misleading...
> People think of refs/remotes/origin as a cache of the origin
> repository's branch heads, and they expect it to be updated on write
> (push) as well as read (fetch).
Yes ;-)
cheers,
martin
^ permalink raw reply
* Re: pull/push inconsistencies
From: J. Bruce Fields @ 2007-05-16 1:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Martin Langhoff, Git Mailing List
In-Reply-To: <7v646th8a2.fsf@assigned-by-dhcp.cox.net>
On Tue, May 15, 2007 at 06:22:29PM -0700, Junio C Hamano wrote:
> "Martin Langhoff" <martin.langhoff@gmail.com> writes:
>
> > There are 2 things that I see as wrong...
> > - local .git/refs/remote/origin/foo and refs/heads/foo match - why is
> > git-push talking about updating them?
>
> Ooo...
>
> Do you mean if you have refs/remotes/origin/foo locally, and
> push into a repository that has refs/heads/foo (but not
> refs/remotes/origin/foo), the push results in refs/heads/foo
> getting updated? If that is what is happening (without any
> refspecs to instruct git-push to do so) that sounds quite buggy.
> I need to look into the code for this one.
I understand him to be saying that it *doesn't* do that, and that he
*wants* it to.
People think of refs/remotes/origin as a cache of the origin
repository's branch heads, and they expect it to be updated on write
(push) as well as read (fetch).
--b.
^ permalink raw reply
* Re: pull/push inconsistencies
From: Junio C Hamano @ 2007-05-16 1:22 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <46a038f90705151811o2159aa5ai84a13e77e790e376@mail.gmail.com>
"Martin Langhoff" <martin.langhoff@gmail.com> writes:
> There are 2 things that I see as wrong...
> - local .git/refs/remote/origin/foo and refs/heads/foo match - why is
> git-push talking about updating them?
Ooo...
Do you mean if you have refs/remotes/origin/foo locally, and
push into a repository that has refs/heads/foo (but not
refs/remotes/origin/foo), the push results in refs/heads/foo
getting updated? If that is what is happening (without any
refspecs to instruct git-push to do so) that sounds quite buggy.
I need to look into the code for this one.
And I think earlier one I was confused that I thought you were
talking about pushing into refs/heads/branch (where branch is
checked out). Sorry.
> - matching refs should ignore .git/refs/remote
>
> ... the 'matching refs' thing will
> ignore the local .git/refs/remotes directory. AFAICS it's the only
> sane thing to do.
I think you are probably right in that matching only heads and
perhaps tags is a sane thing to do (even tags/ is debatable, as
they are supposed to be immutable by convention). As a matter
of fact I do not recall which part of refs/ namespace it looks
at, but it is a very old part of the system and I would not be
surprised if it silently assumed that there are only heads and
tags there (and not explicitly matching heads and tags only).
^ permalink raw reply
* Re: pull/push inconsistencies
From: Martin Langhoff @ 2007-05-16 1:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vtzudhayr.fsf@assigned-by-dhcp.cox.net>
On 5/16/07, Junio C Hamano <junkio@cox.net> wrote:
> "Martin Langhoff" <martin.langhoff@gmail.com> writes:
> > When tracking several branches from a repo, git-pull does a fetch (of
> > all the remote heads) and merges _only the tracking branch currently
> > checked out_. That's ok. However, if I checkout another tracking
> > branch and issue git-pull, the merge does not happen because git-fetch
> > finds nothing new on the remote side. git-pull should merge anyway if
> > remotes/origin/<trackinghead> is ahead of the local head.
>
> That's my expectation and I am a bit surprised if it doesn't.
I'll try get a repro script then.
> > My second issue is that git-push does not update
> > remotes/<repo>/<headname> so if I do git-push && gitk --all it looks
> > as if I haven't pushed. Misleading again. :-/
>
> The standard answer is not to push into a live repository
> without understanding what you are doing.
I don't quite understand that statement. I think I know what I am
doing: telling git-push to push new commits from matching local refs
to remote refs safely (only ff, unless there's a + in the
configuration for that head).
Why can't git match that the remote is the remote in .git/refs/remotes
and put the right data SHA1 in .git/refs/remotes/<headname>?
...
> And pushing into live repository using 'matching refs' is almost
> always a mistake, unless the user knows what he is doing.
Hey - I'm only using it because you've recommended it as a migration
path! ;-) Combined with tracking branches, it works great.
> > Third issue - if I do
> >
> > # we start with a cloned repo that is in sync with
> > # its "origin" repo. No local commits to speak of...
> > # git-fetch brings updates to 3 remote branches - none affecting the current
> > # checked out branch...
> > git-fetch
> > git-commit some/path
> > git-push
> >
> > the output of git-push will show _4_ branches being pushed. For some
> > reason git-push says that it's pushing remotes/origin/branchname ->
> > origin/branchname for all the branches fetched recently -- and not
> > modified! I expect only _1_ branch to be named during push - the only
> > one.
>
> git-push without parameters and configuration pushes matching
> branches. This has been true from day one. Again, I think we
> should be able to make this safer so that "git-push" in cloned
> repository would do something more restricted (perhaps limiting
> to refs/heads?), but I do not think of a universally acceptable
> canned configuration.
There are 2 things that I see as wrong...
- local .git/refs/remote/origin/foo and refs/heads/foo match - why is
git-push talking about updating them?
- matching refs should ignore .git/refs/remote
But perhaps I'm naive in thinking that the 'matching refs' thing will
ignore the local .git/refs/remotes directory. AFAICS it's the only
sane thing to do.
cheers,
martin
^ permalink raw reply
* Re: [PATCH] Add an option to git-ls-tree to display also the size of object
From: Junio C Hamano @ 2007-05-16 1:07 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200705160254.38463.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Junio C Hamano wrote:
>> Jakub Narebski <jnareb@gmail.com> writes:
>>> Junio C Hamano wrote:
>
>>>> Also I suspect that having to show the size of a tree object,
>>>> expressed in terms of the canonical representation, might
>>>> force packv4 aware ls-tree to convert its traversal efficient
>>>> representation to the canonical one only to get its size.
>>>
>>> It still will be accessible, but perhaps it would be less efficient
>>> with v4 pack. It is I think acceptable that -l needs more CPU (and I/O)
>>> time...
>>
>> Shawn answered this better than I could. I am moderately
>> negative on the size of tree objects part.
>>
>> But modulo these details, I agree that being able to get the
>> size of each blob would be useful.
>
> We can always return ' ', '-', or '0' as size for tree entries.
> I wonder what to do about commits/gitlinks/subprojects...
The same "the size of this type of object is not given", I would
say.
^ permalink raw reply
* Re: [PATCH] Add an option to git-ls-tree to display also the size of object
From: Jakub Narebski @ 2007-05-16 0:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vps51hacw.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>> Junio C Hamano wrote:
>>> Also I suspect that having to show the size of a tree object,
>>> expressed in terms of the canonical representation, might
>>> force packv4 aware ls-tree to convert its traversal efficient
>>> representation to the canonical one only to get its size.
>>
>> It still will be accessible, but perhaps it would be less efficient
>> with v4 pack. It is I think acceptable that -l needs more CPU (and I/O)
>> time...
>
> Shawn answered this better than I could. I am moderately
> negative on the size of tree objects part.
>
> But modulo these details, I agree that being able to get the
> size of each blob would be useful.
We can always return ' ', '-', or '0' as size for tree entries.
I wonder what to do about commits/gitlinks/subprojects...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] user-manual: Add section on ignoring files
From: Junio C Hamano @ 2007-05-16 0:42 UTC (permalink / raw)
To: Johan Herland; +Cc: git, Randal L. Schwartz, Jakub Narebski
In-Reply-To: <200705160231.40486.johan@herland.net>
Johan Herland <johan@herland.net> writes:
> +This typically includes files generated by a build process or temporary
> +backup files made by your editor. Of course, 'not' tracking files with git
> +is just a matter of 'not' calling "`git add`" on them. But it quickly becomes
> +annoying to have these untracked files lying around; e.g. they make
> +"`git add .`" and "`git commit -a`" practically useless, and they keep
I think we would want to s/and "`git commit -a`//; if you start
tracking the file, .gitignore would not interfere with it AFAIK.
Other than that,
Acked-by: Junio C Hamano <junkio@cox.net>
^ permalink raw reply
* Re: Smart fetch via HTTP?
From: Junio C Hamano @ 2007-05-16 0:38 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Jan Hudec, git
In-Reply-To: <20070515232946.GR3141@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Jan Hudec <bulb@ucw.cz> wrote:
>> Did anyone already think about fetching over HTTP working similarly to the
>> native git protocol?
>
> No work has been done on this (that I know of) but I've discussed
> it to some extent with Simon 'corecode' Schubert on #git, and I
> think he also brought it up on the mailing list not too long after.
>
> I've certainly thought about adding some sort of pack-objects
> frontend into gitweb.cgi for this exact purpose. It is really
> quite easy, except for the negotation of what the client has. ;-)
>
>> Than a question is how to implement it. The current protocol is stateful on
>> both sides, but the stateless nature of HTTP more or less requires the
>> protocol to be stateless on the server.
>>
>> I think it would be possible to use basically the same protocol as now, but
>> make it stateless for server. That is server first sends it's heads and than
>> client repeatedly sends all it's wants and some haves until the server acks
>> all of them and sends the pack.
>
> I think Simon was talking about doubling the number of haves the
> client sends in each request. So the client POSTs initially all
> of its current refs; then current refs and their parents; then 4
> commits back, then 8, etc. The server replies to each POST request
> with either a "send more please" or the packfile.
I kinda' like the bundle suggestion ;-)
^ permalink raw reply
* Re: [PATCH] Add an option to git-ls-tree to display also the size of object
From: Junio C Hamano @ 2007-05-16 0:37 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200705160119.10802.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Junio C Hamano wrote:
>> Jakub Narebski <jnareb@gmail.com> writes:
>>
>> > Add -l/--long/--size option to git-ls-tree command, which displays
>> > object size of an entry after object id (left-justified with minimum
>> > width of 7 characters).
>>
>> Not a NAK at all (but not an ACK either yet), but just asking
>> questions on some design considerations.
>
> I guess I should use [PATCH/RFC] for this patch...
I do not see any need for that. As far as I am concerned, all
the [PATCH] are RFCs ;-)
>> * Do these options do different things? If not, why have more
>> than one (or two, --long and its shorthand -l)?
>
> The idea was to have output similar (if possible by git-ls-tree
> machinery) to 'ls -l' output, hence -l/--long, but actually it is
> about --size.
"ls -l" is about long (it is not "long to show everything the
system knows", but "longer than usual), so I think it is Ok to
say "ls-tree -l" and people would understand.
>> * Why pad to 7 places? Do we have a similar padding elsewhere?
>> Will this ever used by non-scripts? How does this padding
>> affect parsers other than Perl that read this information?
>
> Padding is added here to make output more human-readable. And I guess
> padding of 7 places is default for 'ls -l'.
Ok, "it is to make the output also consumable more easily by
humans" is a very reasonable answer.
>> Also I suspect that having to show the size of a tree object,
>> expressed in terms of the canonical representation, might
>> force packv4 aware ls-tree to convert its traversal efficient
>> representation to the canonical one only to get its size.
>
> It still will be accessible, but perhaps it would be less efficient
> with v4 pack. It is I think acceptable that -l needs more CPU (and I/O)
> time...
Shawn answered this better than I could. I am moderately
negative on the size of tree objects part.
But modulo these details, I agree that being able to get the
size of each blob would be useful.
^ permalink raw reply
* [PATCH] user-manual: Add section on ignoring files
From: Johan Herland @ 2007-05-16 0:31 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Randal L. Schwartz, Jakub Narebski
In-Reply-To: <7v1whhis16.fsf@assigned-by-dhcp.cox.net>
The todo list at the end of the user manual says that something must be
said about .gitignore. Also, there seems to be a lack of documentation
on how to choose between the various types of ignore files (.gitignore
vs. .git/info/exclude, etc.).
This patch adds a section on ignoring files which try to introduce how
to tell git about ignored files, and how the different strategies
complement eachother.
The syntax of exclude patterns is explained in a simplified manner, with
a reference to git-ls-files(1) which already contains a more thorough
explanation.
Signed-off-by: Johan Herland <johan@herland.net>
---
Revised version with fixes from Junio and Jakub. Thanks. :)
Documentation/user-manual.txt | 71 +++++++++++++++++++++++++++++++++++++++-
1 files changed, 69 insertions(+), 2 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index a7abeaa..750e55a 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1188,6 +1188,75 @@ description. Tools that turn commits into email, for example, use
the first line on the Subject line and the rest of the commit in the
body.
+[[ignoring-files]]
+Ignoring files
+--------------
+
+A project will often generate files that you do 'not' want to track with git.
+This typically includes files generated by a build process or temporary
+backup files made by your editor. Of course, 'not' tracking files with git
+is just a matter of 'not' calling "`git add`" on them. But it quickly becomes
+annoying to have these untracked files lying around; e.g. they make
+"`git add .`" and "`git commit -a`" practically useless, and they keep
+showing up in the output of "`git status`", etc.
+
+Git therefore provides "exclude patterns" for telling git which files to
+actively ignore. Exclude patterns are thoroughly explained in the
+"Exclude Patterns" section of the gitlink:git-ls-files[1] manual page,
+but the heart of the concept is simply a list of files which git should
+ignore. Entries in the list may contain globs to specify multiple files,
+or may be prefixed by "`!`" to explicitly include (un-ignore) a previously
+excluded (ignored) file (i.e. later exclude patterns override earlier ones).
+The following example should illustrate such patterns:
+
+-------------------------------------------------
+# Lines starting with '#' are considered comments.
+# Ignore foo.txt.
+foo.txt
+# Ignore (generated) html files,
+*.html
+# except foo.html which is maintained by hand.
+!foo.html
+# Ignore objects and archives.
+*.[oa]
+-------------------------------------------------
+
+The next question is where to put these exclude patterns so that git can
+find them. Git looks for exclude patterns in the following files:
+
+`.gitignore` files in your working tree:::
+ You may store multiple `.gitignore` files at various locations in your
+ working tree. Each `.gitignore` file is applied to the directory where
+ it's located, including its subdirectories. Furthermore, the
+ `.gitignore` files can be tracked like any other files in your working
+ tree; just do a "`git add .gitignore`" and commit. `.gitignore` is
+ therefore the right place to put exclude patterns that are meant to
+ be shared between all project participants, such as build output files
+ (e.g. `\*.o`), etc.
+`.git/info/exclude` in your repo:::
+ Exclude patterns in this file are applied to the working tree as a
+ whole. Since the file is not located in your working tree, it does
+ not follow push/pull/clone like `.gitignore` can do. This is therefore
+ the place to put exclude patterns that are local to your copy of the
+ repo (i.e. 'not' shared between project participants), such as
+ temporary backup files made by your editor (e.g. `\*~`), etc.
+The file specified by the `core.excludesfile` config directive:::
+ By setting the `core.excludesfile` config directive you can tell git
+ where to find more exclude patterns (see gitlink:git-config[1] for
+ more information on configuration options). This config directive
+ can be set in the per-repo `.git/config` file, in which case the
+ exclude patterns will apply to that repo only. Alternatively, you
+ can set the directive in the global `~/.gitconfig` file to apply
+ the exclude pattern to all your git repos. As with the above
+ `.git/info/exclude` (and, indeed, with git config directives in
+ general), this directive does not follow push/pull/clone, but remain
+ local to your repo(s).
+
+[NOTE]
+In addition to the above alternatives, there are git commands that can take
+exclude patterns directly on the command line. See gitlink:git-ls-files[1]
+for an example of this.
+
[[how-to-merge]]
How to merge
------------
@@ -3184,8 +3253,6 @@ Think about how to create a clear chapter dependency graph that will
allow people to get to important topics without necessarily reading
everything in between.
-Say something about .gitignore.
-
Scan Documentation/ for other stuff left out; in particular:
howto's
some of technical/?
--
1.5.1.4
^ permalink raw reply related
* Re: pull/push inconsistencies
From: Junio C Hamano @ 2007-05-16 0:24 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Git Mailing List
In-Reply-To: <46a038f90705151553h553ae9d3kc3d43af72f385a42@mail.gmail.com>
"Martin Langhoff" <martin.langhoff@gmail.com> writes:
> I am noticing some UI inconsistencies with pull/push. Not sure where
> they are -- and quite busy atm -- if they are in bash I might be able
> to hunt them down and fix. In case anyone else cares...
>
> --
>
> When tracking several branches from a repo, git-pull does a fetch (of
> all the remote heads) and merges _only the tracking branch currently
> checked out_. That's ok. However, if I checkout another tracking
> branch and issue git-pull, the merge does not happen because git-fetch
> finds nothing new on the remote side. git-pull should merge anyway if
> remotes/origin/<trackinghead> is ahead of the local head.
That's my expectation and I am a bit surprised if it doesn't.
> My second issue is that git-push does not update
> remotes/<repo>/<headname> so if I do git-push && gitk --all it looks
> as if I haven't pushed. Misleading again. :-/
The standard answer is not to push into a live repository
without understanding what you are doing.
I've been debating this myself, but I do not think of a good
canned configuration to satisfy different workflows.
- Central repository setup a la CVS would want to:
$ git clone $remote
would create
[remote "origin"]
url = $remote
pull = refs/heads/*:refs/remotes/origin/*
and would want to rely on the "only-fast-forward" safety to
push into the corresonding branch.
$ git push
would push only corresponding branch, so there is no need for
configuration.
However, this is usually good only for the CVS-style shared
central bare repository.
- When using multiple private repositories, hopping between
mothership and satellite, often the arrangement to allow
fetch and push be symmetrical is desired:
satellite$ git clone $mothership
would create:
[remote "origin"]
url = $mothership
pull = refs/heads/*:refs/remotes/origin/*
on the satellite. But if mothership could push into
satellite, you would also want to have
[remote "satellite"]
url = $satellite
push = refs/heads/*:refs/remotes/origin/*
to make "git push satellite" run on mothership and "git fetch
origin" run on satellite be equivalent.
In this workflow, it is clear that a push from the mothership
alone would not affect the working tree of the satellite; in
fact, pushing into tracking branches from the mothership is
arranged to mirror fetching into tracking branches from the
satellite, with the explicit purpose of not affecting the
working tree of the satellite, so there is less room for
confusion.
However, we cannot make this the default, which would break
the traditional CVS-style shared central repository
- A developer who publishes to his public distribution point
(bare):
public$ git clone --bare $my_private_repo
private$ git push $public
This pushes the matching refs between the two, which is the
right thing, without any configuration. You would not
accidentally publish newly created throwaway branches you
used while working inside the private repository.
Unfortunately, historically "git-push" was publisher's tool (the
last workflow was the primary target). Later central bare
repository support was also documented. The second workflow is
not very well supported.
And pushing into live repository using 'matching refs' is almost
always a mistake, unless the user knows what he is doing.
> Third issue - if I do
>
> # we start with a cloned repo that is in sync with
> # its "origin" repo. No local commits to speak of...
> # git-fetch brings updates to 3 remote branches - none affecting the current
> # checked out branch...
> git-fetch
> git-commit some/path
> git-push
>
> the output of git-push will show _4_ branches being pushed. For some
> reason git-push says that it's pushing remotes/origin/branchname ->
> origin/branchname for all the branches fetched recently -- and not
> modified! I expect only _1_ branch to be named during push - the only
> one.
git-push without parameters and configuration pushes matching
branches. This has been true from day one. Again, I think we
should be able to make this safer so that "git-push" in cloned
repository would do something more restricted (perhaps limiting
to refs/heads?), but I do not think of a universally acceptable
canned configuration.
> None of the above are showstoppers, but the user feedback of these
> commands - the very core workflow for beginners - is quite confusing.
Yes, git is distributed and perhaps the expectation to be able
to "git push" without saying where to and what to push is coming
from some centralized system mindset. If somehow we can disable
"git push" before a sensible refspecs are configured, that would
be an improvement for new users, but the "push matching refs"
behaviour is very handy for already established workflows of
people who publish things.
When pushing into your public distribution point, which does
_NOT_ have remotes/* hierarchy by definition, what will match
between your private working repository and your public
distribution point are heads/ and tags/ and all goes well. You
do not want to accidentally push your new throwaway branches.
^ permalink raw reply
* Re: [PATCH] gitweb: Do not use absolute font sizes
From: Jakub Narebski @ 2007-05-15 23:59 UTC (permalink / raw)
To: Jan Hudec; +Cc: David Kågedal, git
In-Reply-To: <20070515150912.GA3653@efreet.light.src>
On Thu, 15 May 2007, Jan Hudec wrote:
> On Mon, May 14, 2007 at 18:06:54 -0700, David Kågedal wrote:
>> Unfortunately, the problem is that too many web sites explicitly
>> select extra small font sizes, which means that you have to select a
>> "standard" font size in your browser that is a bit larger than you'd
>> actually like.
>
> IMHO gitweb should explicitely request being somewhat smaller than normal,
> because it has good use for long lines. Normally I want to set font so large,
> that more than ~120 characters won't fit on the screen, since otherwise pages
> that don't use margins are simply unreadable. However gitweb presents a table
> with several columns, so having wider line is OK for it. Therefore explicit
> 'font-size: small' would make sense.
And thanks to commit 63fcbe00 by Pasky
"gitweb: Do not use absolute font sizes"
it has to be added in only one place:
diff --git a/gitweb/gitweb.css b/gitweb/gitweb.css
index b57c8be..02623cb 100644
--- a/gitweb/gitweb.css
+++ b/gitweb/gitweb.css
@@ -1,5 +1,6 @@
body {
font-family: sans-serif;
+ font-size: small;
border: solid #d9d8d1;
border-width: 1px;
margin: 10px;
^ permalink raw reply related
* [PATCH] gitweb: Separate search regexp from search text
From: Jakub Narebski @ 2007-05-15 23:56 UTC (permalink / raw)
To: git
Separate search text, which is saved in $searchtext global variable,
and is used in links, as default value for the textfield in search
form, and for pickaxe search, from search regexp, which is saved in
$search_regexp global variable, and is used as parameter to --grep,
--committer or --author options to git-rev-list, and for searching
commit body in gitweb. For now $search_regexp is unconditionallt
equal to quotemeta($searchtext), meaning that we always search for
fixed string.
This fixes bug where 'next page' links for 'search' view didn't work
for searchtext containing quotable characters, like `@'.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
There was similar patch; bit of bandaid (without commit message IIRC),
but I cannot find it to add Originally-by:/Suggested-by: acknowledgement
header, not Noticed-by: header...
gitweb/gitweb.perl | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index a13043d..549e027 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -365,6 +365,7 @@ if (defined $page) {
}
our $searchtext = $cgi->param('s');
+our $search_regexp;
if (defined $searchtext) {
if ($searchtext =~ m/[^a-zA-Z0-9_\.\/\-\+\:\@ ]/) {
die_error(undef, "Invalid search parameter");
@@ -372,7 +373,7 @@ if (defined $searchtext) {
if (length($searchtext) < 2) {
die_error(undef, "At least two characters are required for search parameter");
}
- $searchtext = quotemeta $searchtext;
+ $search_regexp = quotemeta $searchtext;
}
our $searchtype = $cgi->param('st');
@@ -3244,7 +3245,7 @@ sub git_search_grep_body {
esc_html(chop_str($co{'title'}, 50)) . "<br/>");
my $comment = $co{'comment'};
foreach my $line (@$comment) {
- if ($line =~ m/^(.*)($searchtext)(.*)$/i) {
+ if ($line =~ m/^(.*)($search_regexp)(.*)$/i) {
my $lead = esc_html($1) || "";
$lead = chop_str($lead, 30, 10);
my $match = esc_html($2) || "";
@@ -4626,7 +4627,7 @@ sub git_search {
} elsif ($searchtype eq 'committer') {
$greptype = "--committer=";
}
- $greptype .= $searchtext;
+ $greptype .= $search_regexp;
my @commitlist = parse_commits($hash, 101, (100 * $page), $greptype);
my $paging_nav = '';
--
1.5.1.4
^ permalink raw reply related
* Re: [PATCH] user-manual: Add section on ignoring files
From: Johan Herland @ 2007-05-15 23:31 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <f2dffu$so6$2@sea.gmane.org>
On Wednesday 16 May 2007, Jakub Narebski wrote:
> Johan Herland wrote:
>
> > +A project will often generate files that you do 'not' want to track with git.
> > +This typically includes files generated by a build process or temporary
> > +backup files made by your editor. Of course, 'not' tracking files with git
> > +is just a matter of 'not' calling "git add" on them. But it might be
> > +annoying to have these untracked files automatically showing up in the
> > +output of "git status", in the commit message template, etc.
>
> _And_ ignored files affect globbing and path patterns ("git add ." or
> "git add *.txt"would not add ignored files), and --all options
> ("git commit -a" would not commit changed but ignored files).
Yes, of course. I forgot about that "minor" point...
Have fun!
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ 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