* Re: git-format-patch little gripe
From: Sean @ 2006-11-25 15:30 UTC (permalink / raw)
To: Jeff King; +Cc: Luben Tuikov, git
In-Reply-To: <20061103185026.GA28566@coredump.intra.peff.net>
On Fri, 3 Nov 2006 13:50:26 -0500
Jeff King <peff@peff.net> wrote:
> For my own workflow, I don't want to have to pick the commit out of
> rev-list (or log) output. I want to find it and hit a button to say "OK,
> now mail this patch." So I put _all_ of my patches into an mbox, and
> then browse them with mutt. Sort of a poor man's patch browser, but then
> I'm ready to jump into mailing them immediately.
>
> I use the following script:
>
> #!/bin/sh
> root=${1:-origin}
> git-format-patch -s --stdout $root >.mbox
> mutt -f .mbox
> rm -f .mbox
If your mail setup support imap, the patches can be dumped directly into
it rather than having to go through an mbox. For instance you can have
something like this in your ~/.gitconfig:
[imap]
Host = imap.server.com
Folder = "Drafts"
User = uname
Pass = password
And then the above command line becomes:
git-format-patch -s --stdout $root | git-imap-send
To move all the patches into your imap drafts folder to be accessed
by whatever email client you use.
Sean
^ permalink raw reply
* Re: git-format-patch little gripe
From: Jeff King @ 2006-11-25 15:39 UTC (permalink / raw)
To: Sean; +Cc: git
In-Reply-To: <20061125103033.2ea742d3.seanlkml@sympatico.ca>
On Sat, Nov 25, 2006 at 10:30:33AM -0500, Sean wrote:
> If your mail setup support imap, the patches can be dumped directly into
> it rather than having to go through an mbox. For instance you can have
> something like this in your ~/.gitconfig:
Sure, I could. But if you have a client which supports mboxes, it's
probably better to use the mbox. With your solution, I send the patch to
the imap server, then fire up the mail client and re-download the
patch, possibly mark it up, and then send it out by smtp. The latency
increase can be noticeable, especially for big patches and slow imap
servers.
> To move all the patches into your imap drafts folder to be accessed
> by whatever email client you use.
Oh come on, Real Men just edit the mbox in vi. :)
^ permalink raw reply
* Re: git-format-patch little gripe
From: Sean @ 2006-11-25 15:42 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20061125153949.GA11136@coredump.intra.peff.net>
On Sat, 25 Nov 2006 10:39:49 -0500
Jeff King <peff@peff.net> wrote:
> On Sat, Nov 25, 2006 at 10:30:33AM -0500, Sean wrote:
>
> > If your mail setup support imap, the patches can be dumped directly into
> > it rather than having to go through an mbox. For instance you can have
> > something like this in your ~/.gitconfig:
>
> Sure, I could. But if you have a client which supports mboxes, it's
> probably better to use the mbox. With your solution, I send the patch to
> the imap server, then fire up the mail client and re-download the
> patch, possibly mark it up, and then send it out by smtp. The latency
> increase can be noticeable, especially for big patches and slow imap
> servers.
Yeah, I didn't mean it as a better replacement for your use, just as
an option that might suit some people better. It works out well here.
> > To move all the patches into your imap drafts folder to be accessed
> > by whatever email client you use.
>
> Oh come on, Real Men just edit the mbox in vi. :)
Damn.. caught in my skirt again.. ;o)
^ permalink raw reply
* Re: [PATCH 3/5] get_shallow_commits: Avoid memory leak if a commit has been reached already.
From: Anand Kumria @ 2006-11-25 17:22 UTC (permalink / raw)
To: git
In-Reply-To: <87slg8uc0l.fsf@wine.dyndns.org>
On Fri, 24 Nov 2006 15:58:50 +0100, Alexandre Julliard wrote:
> Signed-off-by: Alexandre Julliard <julliard@winehq.org>
> ---
> shallow.c | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/shallow.c b/shallow.c
> index 2db1dc4..3d53d17 100644
> --- a/shallow.c
> +++ b/shallow.c
> @@ -60,7 +60,9 @@ struct commit_list *get_shallow_commits(
> commit = NULL;
> continue;
> }
> - commit->util = xcalloc(1, sizeof(int));
> + if (!commit->util)
> + commit->util = xmalloc(sizeof(int));
> + *(int *)commit->util = 0;
> cur_depth = 0;
Hi,
Any reason you didn't do:
if (!commit->util)
commit->util = xcalloc(1, sizeof(int));
That would seem to be the same.
Regards,
Anand
^ permalink raw reply
* Re: [PATCH 3/5] get_shallow_commits: Avoid memory leak if a commit has been reached already.
From: Johannes Schindelin @ 2006-11-25 18:49 UTC (permalink / raw)
To: Anand Kumria; +Cc: git
In-Reply-To: <ek9u4f$vmk$1@sea.gmane.org>
Hi,
On Sat, 25 Nov 2006, Anand Kumria wrote:
> Any reason you didn't do:
>
> if (!commit->util)
> commit->util = xcalloc(1, sizeof(int));
xmalloc() does not initialize the memory. Therefore, it is usually
preferred if you initialize the memory yourself. In this case, the memory
is initialized to 0, even if it is not allocated.
It may be a minor performance issue, but it is a good habit to use xcalloc
only if it is needed.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Linus Torvalds @ 2006-11-25 18:57 UTC (permalink / raw)
To: Yann Dirson; +Cc: Shawn Pearce, Junio C Hamano, Jakub Narebski, git
In-Reply-To: <20061125111235.GO5443@nan92-1-81-57-214-146.fbx.proxad.net>
On Sat, 25 Nov 2006, Yann Dirson wrote:
>
> > This lets you then perform a bisect within the
> > submodule when you identify the supermodule commit which caused
> > the breakage.
>
> That is, first bisect the supermodule (which naturally bisects the
> submodule with rough granularity, assuming there are many submodule
> commits for at least some supermodule commits), then bisect the submodule
> between the two commits identified at supermodule level, right ?
Right. That is how you _must_ do it.
The reason is:
- the supermodule will not track every release of the submodule. One of
the biggest reasons for using submodules in the first place is that the
submodules have their own development _independently_ of the
supermodule, and usually the supermodule will import new versions of
submodules only occasionally (eg the supermodule might choose to track
only major releases of the submodule, for example)
(And yes, I realize that this is not necessarily the only submodule
usage: sometimes the submodules are literally _only_ developed as
submodules, and you'd never develop them independently. It depends on
the situation)
- As a resule of the above, you MUST NOT do bisection at the submodule
level at first: it's entirely possible that the supermodule never ever
actually used the submodule state at a finer granularity, and
"bisecting" into such state would be idiotic (it's really no different
from "bisecting" a regular commit by splitting up a commit into patches
against individual files - sure, it's a smaller granularity, but it's a
granularity that never _existed_, and was never tested or intended to
work!)
So yes, you should expect that
(a) submodule changes "jump around" in the supermodule - even to the
point of going backwards in time as far as the submodule is concerned
(ie the supermodule might have tested a new release of a submodule,
committed that, found a problem, and decided to just go back to an
earlier version of the submodule again, and committed that again)
(b) This implies very much that there can be a n:m relationship between
submodule and supermodule commits. A supermodule commit does _not_
imply a commit in the submodule (it might commit changes to the
top-level makefile or to _another_ submodule), but equally, a
submodule commit does _not_ imply a commit in the supermodule
(because the submodule might be independently changed in some other
repository where it's the _primary_ development, not a submodule)
So you shouldn't expect submodules to be very "tightly" coupled, and I
don't think you even want the workflow to _be_ that tight. I think it's ok
if submodules show up as such, and that "git diff" etc don't try to make
it all "seamless".
It often _shouldn't_ be seamless: you should be able to commit to a
supermodule without committing the submodule state: it's really no
different from committing individual files (it migth be somethign that is
_discouraged_ as a workflow for some project, the same way you might
discourage using "git commit one/file" over "git commit -a", and for the
same reason: you're committing some state that doesn't match what your
tree actually looks like).
Similarly, doing a "git commit -a" within a submodule should really just
commit _that_ submodule, and not even _try_ to know about supermodules
etc, because the submodule really should be a totally independent git
repository.
[ Side note: you may well want to set up submodules so that they share the
object store with the supermodule: that may be the simplest way to make
operations that traverse things recursively work out, since it means
that you can do object lookups for everythign you traverse without
having to even think about it.
On the other hand, this could equally easily be done by just making
every submodule an "alternates" directory in the supermodule: that keeps
the object databases separate, but means that anybody in the supermodule
will always be able to look up all the objects in the submodules. So
even here, we certainly _can_ keep things separated, without even
introducing any new concepts. ]
So I actually think that submodules should at least start out as something
rather independent, where a "commit -a" in the supermodule will _only_
commit the supermodule itself - and if you haven't committed the submodule
yet, you'll just get the current HEAD state of the submodule.
Add some trivial help in "git status" to _warn_ about the fact that
submodules haven't been committed and are dirty, but I really think that
it should be a very explicit thing where you really do see things as
submodules, not as "one big module".
^ permalink raw reply
* Re: [PATCH 5/5] fetch-pack: Do not fetch tags for shallow clones.
From: Johannes Schindelin @ 2006-11-25 19:01 UTC (permalink / raw)
To: Alexandre Julliard; +Cc: git
In-Reply-To: <87k61kubya.fsf@wine.dyndns.org>
Hi,
the other 4 patches look good to me (fixing a few typos/thinkos). However,
I think there must be a way to fetch tags for clones, when it is possible
for fetches. Especially since fetch gets closer to including the features
needed for "clone" (regexes for remote names, storing packs, ...)
Ciao,
Dscho
P.S.: I just realized that send-pack and receive-pack are not at all aware
of shallow repos. Maybe both should check for a shallow repo, and die() on
it?
^ permalink raw reply
* Re: Calling all bash completion experts..
From: Linus Torvalds @ 2006-11-25 19:08 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Git Mailing List
In-Reply-To: <20061125071351.GE4528@spearce.org>
On Sat, 25 Nov 2006, Shawn Pearce wrote:
>
> I added the nospace option because of the completion for fetch/push,
> cat-file, diff-tree and ls-tree.
>
> The problem is the file completion for e.g. cat-file. We don't
> want a space added after we complete a directory name, so you can
> complete further, e.g.:
>
> git cat-file -p ma<tab>con<tab>comp<tab>git-com<tab>
But that's how directory completion _always_ works. Completion doesn't add
spaces to directories anyway, it adds a "/".
The branch-name thing is well-taken: you don't want to add a space after a
branch-name, although neither do you want to add a ":" by default.
So "nospace" after a branch (or tag) name sounds sane, but nowhere else
that I can see.
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Steven Grimm @ 2006-11-25 19:19 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0611251037000.6991@woody.osdl.org>
Linus Torvalds wrote:
> So I actually think that submodules should at least start out as something
> rather independent, where a "commit -a" in the supermodule will _only_
> commit the supermodule itself - and if you haven't committed the submodule
> yet, you'll just get the current HEAD state of the submodule.
That would make it impossible to atomically commit a change that affects
two submodules, yes? I think cross-submodule commit is highly desirable
and will be a fairly common use case for submodules if it's supported.
For example, if you have "client" and "server" submodules and someone
makes a protocol change, you don't want some unwitting developer to pull
just half of the change and end up with incompatible code in the two
submodules.
I have no problem with making the "only commit the supermodule" behavior
the default and requiring a command-line option for the "commit
everything" case, but I think "commit everything" is useful. And
honestly IMO it should be the default since it'll behave in a less
surprising way; when I do a "commit -a" I expect all my changes to be
committed, whether they're in submodules or not.
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Linus Torvalds @ 2006-11-25 19:30 UTC (permalink / raw)
To: Steven Grimm; +Cc: git
In-Reply-To: <45689747.3020403@midwinter.com>
On Sat, 25 Nov 2006, Steven Grimm wrote:
> Linus Torvalds wrote:
> > So I actually think that submodules should at least start out as something
> > rather independent, where a "commit -a" in the supermodule will _only_
> > commit the supermodule itself - and if you haven't committed the submodule
> > yet, you'll just get the current HEAD state of the submodule.
>
> That would make it impossible to atomically commit a change that affects two
> submodules, yes?
No. Quite the reverse. What you do is:
(a) commit both submodules INDEPENDENTLY.
(b) then commit the supermodule that contains the submodules.
And note how the important part here is that committing in a submodule
DOES NOT AFFECT THE SUPERMODULE AT ALL!
The git trees are _independent_. That's important. You should _not_ try to
mix them up and make a commit in one commit anything AT ALL in some other
tree, exctly because it gets impossible to do (a) interesting things and
(b) atomic commits otherwise.
Note that this is true also in the case of a submodule that itself
contains a submodule. That doesn't change anything - you still need to be
able to view _each_ layer as an independent thing.
^ permalink raw reply
* Re: [PATCH 3/5] get_shallow_commits: Avoid memory leak if a commit has been reached already.
From: Junio C Hamano @ 2006-11-25 19:44 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0611251947310.30004@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Sat, 25 Nov 2006, Anand Kumria wrote:
>
>> Any reason you didn't do:
>>
>> if (!commit->util)
>> commit->util = xcalloc(1, sizeof(int));
>
> xmalloc() does not initialize the memory. Therefore, it is usually
> preferred if you initialize the memory yourself. In this case, the memory
> is initialized to 0, even if it is not allocated.
>
> It may be a minor performance issue, but it is a good habit to use xcalloc
> only if it is needed.
I think you could pretend the commit->util field to be of some
kind of int and avoid the allocation altogether ;-).
^ permalink raw reply
* Re: Wierd tag errors from current 'next'
From: Junio C Hamano @ 2006-11-25 20:08 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: git
In-Reply-To: <456845E0.1050001@shadowen.org>
Andy Whitcroft <apw@shadowen.org> writes:
> I just was fetching some updates from a repository which I sync from CVS
> into my development repository. I got the following wierd errors about
> a tag during the fetch, it seemed to fix itself by the end ... hmmmm.
>
> apw@pinky$ git fetch
> error: refs/tags/v0_72_3 does not point to a valid object!
> error: refs/tags/v0_72_3 does not point to a valid object!
> remote: Generating pack...
> remote: Done counting 42 objects.
> remote: Result has 28 objects.
> remote: Deltifying 28 objects.
> remote: 100% (28/28) done
> remote: Total 28, written 28 (delta 20), reused 20 (delta 12)
> Unpacking 28 objects
> 100% (28/28) done
That sounds as if we are checking the refs/tags/v0_72_3 before
we get the object itself. "does not point to a valid object!"
message comes from do_one_ref() in refs.c which means your
repository had $GIT_DIR/refs/tags/v0_72_3 before that object was
retrieved.
Which is _bad_. Could you reproduce and bisect it?
^ permalink raw reply
* [RFD] making separate-remote layout easier to use
From: Junio C Hamano @ 2006-11-25 21:53 UTC (permalink / raw)
To: git
Now separate-remote layout is the default for newly cloned
repositories, I think it is a good time to make further effort
to make things easier to use. Here are some of the ideas off
the top of my head.
* Do not change what branch the sole local branch is named.
In the current implementation, we find out what branch the
remote HEAD points at, and match the name of the sole local
branch to it. HEAD of most central distribution point
repositories that use git with the default configuration have
HEAD pointing at refs/heads/master and a cloned repository would
continue to use refs/heads/master as the sole local branch when
it starts as before, but some projects may use alternate
wordings such as 'main', and a new repository would have
refs/heads/main branch when cloned from such a repository
instead. I think this behaviour is a reasonable default, so
let's keep this.
Distribution point repositories are of interest here, because
that is what most people clone from, and this message is about
making the default easier to use by those casual cloners.
* Change the default contents of $GIT_DIR/remotes/origin
Currently we list all the remote branches that exist when the
clone is made, making sure that the branch pointed at by HEAD at
the remote is listed first. The intent is to track every branch
at the remote but merge in the "primary" branch to us.
Two issues that have been raised about this is:
- the intent to track every branch is good, but the current
implementation means we would not notice new branches at the
remote.
- merging the "primary" branch is good only when the user is on
the corresponding "primary" branch. It is usually a wrong
thing to do when on another branch.
The first issue can be solved, with the help of recent "glob
pattern refspec in fetch" from Andy. I am thinking about making
the default contents of $GIT_DIR/remotes/origin to be:
URL: <url of the cloned repository>
Pull: +refs/heads/<primary>:refs/remotes/<origin>/<primary>
Pull: +refs/heads/*:refs/remotes/<origin>/*
to address this issue.
Side note: <primary> is what HEAD pointed at at the
remote when the clone was made, and <origin> is usually
'origin' but "git clone -o $origin" can override it.
Forcing with '+' is debatable, but with separate-remote layout,
remotes/*/ hierarchy is to track what the remote has, and you
cannot do much else other than noticing and warning when the
remote end does funny things to its refs anyway, so I think
having '+' might be a better default.
The right thing to do to address the second issue is less clear.
If the "upstream" has two more-or-less equally prominent
branches, say 'main' and 'test', it may make sense to use
corresponding two branches on the local side and merge 'main'
from the remote when on local 'main' and merge 'test' when on
local 'test'. Even when dealing with a specific topic branch,
that would hold true for most of the time. A topic branch
refs/heads/bug#2073 to work on the bug 2073 can be published at
the central distribution point. The proposed updates to
$GIT_DIR/remotes/origin file would track it with
refs/remotes/origin/bug#2073 and interested people can create a
local branch refs/heads/bug#2073 from it and work on it, which
makes it easy to polish a topic branch in a collaborative way.
I am not sure if 'merge in corresponding branch' is the only
valid workflow, however. I am reluctant to make the system
automatically do so if the solution makes other workflows more
painful to follow. Automatically merging remotes/origin/$foo
when on $foo branch is not good enough, in other words (also,
there may be a hierarchy under remotes/ other than origin). It
might make sense to introduce "Merge: " in remotes/ file and if
they are present use "Pull: " only to decide what are fetched
and use "Merge: " to decide what is merged (if we were doing the
system from scratch, the former would have been named "Fetch: "
but it is too late now).
^ permalink raw reply
* Re: [RFD] making separate-remote layout easier to use
From: Jakub Narebski @ 2006-11-25 22:25 UTC (permalink / raw)
To: git
In-Reply-To: <7v1wnr19do.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Now separate-remote layout is the default for newly cloned
> repositories, I think it is a good time to make further effort
> to make things easier to use. Here are some of the ideas off
> the top of my head.
[...]
> * Change the default contents of $GIT_DIR/remotes/origin
The question is: do we continue to use remotes/ file, or do we
save remotes info in the config file: remote.<name>.url,
remote.<name>.fetch, remote.<name>.push and branch.<name>.merge
(in our case '[remote "origin"]' section)?
> Currently we list all the remote branches that exist when the
> clone is made, making sure that the branch pointed at by HEAD at
> the remote is listed first. The intent is to track every branch
> at the remote but merge in the "primary" branch to us.
>
> Two issues that have been raised about this is:
>
> - the intent to track every branch is good, but the current
> implementation means we would not notice new branches at the
> remote.
>
> - merging the "primary" branch is good only when the user is on
> the corresponding "primary" branch. It is usually a wrong
> thing to do when on another branch.
>
> The first issue can be solved, with the help of recent "glob
> pattern refspec in fetch" from Andy. I am thinking about making
> the default contents of $GIT_DIR/remotes/origin to be:
>
> URL: <url of the cloned repository>
> Pull: +refs/heads/<primary>:refs/remotes/<origin>/<primary>
> Pull: +refs/heads/*:refs/remotes/<origin>/*
>
> to address this issue.
I hope that it also works with the remote.origin config file
section instead of $GIT_DIR/remotes/origin
> Side note: <primary> is what HEAD pointed at at the
> remote when the clone was made, and <origin> is usually
> 'origin' but "git clone -o $origin" can override it.
>
> Forcing with '+' is debatable, but with separate-remote layout,
> remotes/*/ hierarchy is to track what the remote has, and you
> cannot do much else other than noticing and warning when the
> remote end does funny things to its refs anyway, so I think
> having '+' might be a better default.
Perhaps, perhaps not. It would be nice to have configuration option
that would tell that history of given branch is being changed, and
the ability to ask about it remotely, so git-clone would be able
to add this + _when needed_ automatically.
But it's a fact that with separate remote the need to use fast-forward
check is lessened, and it might be more important to not confuse first
time user with having to modify $GIT_DIR/remotes/origin or remote.origin
config section to fetch from the repository he/she cloned from.
> The right thing to do to address the second issue is less clear.
> If the "upstream" has two more-or-less equally prominent
> branches, say 'main' and 'test', it may make sense to use
> corresponding two branches on the local side and merge 'main'
> from the remote when on local 'main' and merge 'test' when on
> local 'test'. Even when dealing with a specific topic branch,
> that would hold true for most of the time. A topic branch
> refs/heads/bug#2073 to work on the bug 2073 can be published at
> the central distribution point. The proposed updates to
> $GIT_DIR/remotes/origin file would track it with
> refs/remotes/origin/bug#2073 and interested people can create a
> local branch refs/heads/bug#2073 from it and work on it, which
> makes it easy to polish a topic branch in a collaborative way.
>
> I am not sure if 'merge in corresponding branch' is the only
> valid workflow, however. I am reluctant to make the system
> automatically do so if the solution makes other workflows more
> painful to follow. Automatically merging remotes/origin/$foo
> when on $foo branch is not good enough, in other words (also,
> there may be a hierarchy under remotes/ other than origin). It
> might make sense to introduce "Merge: " in remotes/ file and if
> they are present use "Pull: " only to decide what are fetched
> and use "Merge: " to decide what is merged (if we were doing the
> system from scratch, the former would have been named "Fetch: "
> but it is too late now).
If you add "Merge: " in remotes/, then please add it also in
remote section in config file. Config file has now
branch.<branchname>.merge (and it would be nice if clone would
set ou this for local branches corresponding to remote branches),
but it is not the same.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [RFD] making separate-remote layout easier to use
From: Junio C Hamano @ 2006-11-25 23:19 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ekafpm$fs7$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Junio C Hamano wrote:
>
>> Now separate-remote layout is the default for newly cloned
>> repositories, I think it is a good time to make further effort
>> to make things easier to use. Here are some of the ideas off
>> the top of my head.
> [...]
>> * Change the default contents of $GIT_DIR/remotes/origin
>
> The question is: do we continue to use remotes/ file, or do we
> save remotes info in the config file: remote.<name>.url,
> remote.<name>.fetch, remote.<name>.push and branch.<name>.merge
> (in our case '[remote "origin"]' section)?
It is not "the question"; it is irrelevant because
$GIT_DIR/remotes/origin and [remote "origin"] are pretty much
interchangeable, and will hopefully continue to be.
[remote "origin"]
url = master.kernel.org:/pub/scm/git/git.git/
fetch = +refs/heads/master:refs/remotes/origin/master
fetch = +refs/heads/*:refs/remotes/origin/*
would be the way to express the equilvalent of the example in
the previous message.
^ permalink raw reply
* Re: [RFD] making separate-remote layout easier to use
From: Jakub Narebski @ 2006-11-25 23:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvel3yuzz.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> Junio C Hamano wrote:
>>
>>> Now separate-remote layout is the default for newly cloned
>>> repositories, I think it is a good time to make further effort
>>> to make things easier to use. Here are some of the ideas off
>>> the top of my head.
>> [...]
>>> * Change the default contents of $GIT_DIR/remotes/origin
>>
>> The question is: do we continue to use remotes/ file, or do we
>> save remotes info in the config file: remote.<name>.url,
>> remote.<name>.fetch, remote.<name>.push and branch.<name>.merge
>> (in our case '[remote "origin"]' section)?
>
> It is not "the question"; it is irrelevant because
> $GIT_DIR/remotes/origin and [remote "origin"] are pretty much
> interchangeable, and will hopefully continue to be.
>
> [remote "origin"]
> url = master.kernel.org:/pub/scm/git/git.git/
> fetch = +refs/heads/master:refs/remotes/origin/master
> fetch = +refs/heads/*:refs/remotes/origin/*
>
> would be the way to express the equilvalent of the example in
> the previous message.
Well, the question is if git-clone would generate appropriate config
entries in addition to or instead of $GIT_DIR/remotes/origin file...
By the way, what do you think about extended refspec syntax, namely
in addition to <remote name>:<local name> it would allow to say
<remote name>:<local name>:<local branch to merge into>?
--
Jakub Narebski
^ permalink raw reply
* Re: [PATCH 3/5] get_shallow_commits: Avoid memory leak if a commit has been reached already.
From: Johannes Schindelin @ 2006-11-25 23:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wnr2twq.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sat, 25 Nov 2006, Junio C Hamano wrote:
> I think you could pretend the commit->util field to be of some kind of
> int and avoid the allocation altogether ;-).
I actually thought about that, and found it too dangerous. But of course,
since we need at least a 32-bit architecture, chances are very high that a
pointer is castable to an int.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Yann Dirson @ 2006-11-25 23:49 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Steven Grimm, git
In-Reply-To: <Pine.LNX.4.64.0611251128170.3483@woody.osdl.org>
On Sat, Nov 25, 2006 at 11:30:47AM -0800, Linus Torvalds wrote:
> The git trees are _independent_. That's important.
I'm not sure how independant you mean them to be. The approach I've
tried to describe so far assumes that, although you can look at each
submodule independently from the supermodule or any other submodule, you
can still look at the supermodule as a single tree of it own.
Eg, so that if one part of an appliance/ modules ends up promoted to a
lib/ module, GIT can still show that as a move within the supermodule.
If we insist that the submodules get committed independently before we
make a supermodule commit tying those together, I fear it may make things
like such "move/copy detection" more tricky ?
Also, I'd rather expect "git-commit -a" outside of any submodule to
commit everything in the supermodule, triggering submodule commits as an
intermediate step when needed - just like "git-commit -a" does not
require to manually specify subdirectories to inclue in the commit. I'd
rather expect a special flag to exclude submodules from a commit.
Best regards,
--
^ permalink raw reply
* [PATCH] Use new .git/config for storing "origin" shortcut repository
From: Andy Parkins @ 2006-11-26 0:03 UTC (permalink / raw)
To: git
In-Reply-To: <ekafpm@sea.gmane.org>
If .git/remotes/ is now deprecated, then git-clone shouldn't use it.
This patch adds the analogous definitions to .git/config using
git-repo-config calls.
For example what was previously .git/remotes/origin
URL: proto://host/path
Pull: refs/heads/master:refs/heads/origin
Is now added to .git/config as
[remote "origin"]
url = proto://host/path
fetch = refs/heads/master:refs/heads/origin
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
I'm not sure if I'm correct in thinking that .git/remotes is deprecated. If it is,
this patch makes git-clone use .git/config instead.
Personally I like it, I think there should be as small a number of places for
configuring the repository as possible.
git-clone.sh | 9 ++++-----
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/git-clone.sh b/git-clone.sh
index 9ed4135..1057a26 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -373,9 +373,8 @@ then
*) origin_track="$remote_top/$origin"
git-update-ref "refs/heads/$origin" "$head_sha1" ;;
esac &&
- echo >"$GIT_DIR/remotes/$origin" \
- "URL: $repo
-Pull: refs/heads/$head_points_at:$origin_track" &&
+ git-repo-config remote."$origin".url "$repo" &&
+ git-repo-config remote."$origin".fetch "refs/heads/$head_points_at:$origin_track" &&
(cd "$GIT_DIR/$remote_top" && find . -type f -print) |
while read dotslref
do
@@ -389,8 +388,8 @@ Pull: refs/heads/$head_points_at:$origin_track" &&
then
continue
fi
- echo "Pull: refs/heads/${name}:$remote_top/${name}"
- done >>"$GIT_DIR/remotes/$origin" &&
+ git-repo-config remote."$origin".fetch "refs/heads/${name}:$remote_top/${name}"
+ done &&
case "$use_separate_remote" in
t)
rm -f "refs/remotes/$origin/HEAD"
--
1.4.4.1.gb38c-dirty
^ permalink raw reply related
* Re: [PATCH] Use new .git/config for storing "origin" shortcut repository
From: Johannes Schindelin @ 2006-11-26 0:48 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200611260003.31025.andyparkins@gmail.com>
Hi,
On Sun, 26 Nov 2006, Andy Parkins wrote:
> - echo "Pull: refs/heads/${name}:$remote_top/${name}"
> - done >>"$GIT_DIR/remotes/$origin" &&
> + git-repo-config remote."$origin".fetch "refs/heads/${name}:$remote_top/${name}"
> + done &&
This hunk is wrong: "git-repo-config remote.bla.fetch b" will _overwrite_
remoter.bla.fetch. To avoid that, you have to use "git repo-config
remote.bla.fetch b ^$". (The last argument is a regular expression which
has to be matched by the value-to-be-oreplaced.)
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Sven Verdoolaege @ 2006-11-26 1:14 UTC (permalink / raw)
To: Yann Dirson; +Cc: Linus Torvalds, Steven Grimm, git
In-Reply-To: <20061125234908.GC24909@nan92-1-81-57-214-146.fbx.proxad.net>
FWIW, here's my view on this issue.
On Sun, Nov 26, 2006 at 12:49:08AM +0100, Yann Dirson wrote:
> Also, I'd rather expect "git-commit -a" outside of any submodule to
> commit everything in the supermodule, triggering submodule commits as an
> intermediate step when needed - just like "git-commit -a" does not
> require to manually specify subdirectories to inclue in the commit. I'd
> rather expect a special flag to exclude submodules from a commit.
A commit should record the content changes that have been made, not change
any content itself. Some VCSs change the contents of a file when you
commit them (e.g., keyword substitution). Git, rightly, doesn't do that.
Likewise, when you commit in the superproject, it should simply record
the changes to the "content" of the subproject and not change it.
And the content of the subproject is a commit, so a commit in the
superproject should not change the content of the subproject by creating
another commit in the subproject.
^ permalink raw reply
* [PATCH] gitweb: Make project description in projects list link to summary view
From: Jakub Narebski @ 2006-11-26 1:18 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
Make (shortened) project description in the "projects list" view
hyperlink to the "summary" view of the project. Project names are
sometimes short; having project description be hyperling gives larger
are to click. While at it, display full description on mouseover via
'title' attribute to introduced link.
Additionally, fix whitespace usage in modified git_project_list_body
subroutine: tabs are for indent, spaces are for align.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 13 ++++++++-----
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index fac7923..0477507 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2441,6 +2441,7 @@ sub git_project_list_body {
($pr->{'age'}, $pr->{'age_string'}) = @aa;
if (!defined $pr->{'descr'}) {
my $descr = git_get_project_description($pr->{'path'}) || "";
+ $pr->{'descr_long'} = to_utf8($descr);
$pr->{'descr'} = chop_str($descr, 25, 5);
}
if (!defined $pr->{'owner'}) {
@@ -2476,7 +2477,7 @@ sub git_project_list_body {
} else {
print "<th>" .
$cgi->a({-href => href(project=>undef, order=>'project'),
- -class => "header"}, "Project") .
+ -class => "header"}, "Project") .
"</th>\n";
}
if ($order eq "descr") {
@@ -2485,7 +2486,7 @@ sub git_project_list_body {
} else {
print "<th>" .
$cgi->a({-href => href(project=>undef, order=>'descr'),
- -class => "header"}, "Description") .
+ -class => "header"}, "Description") .
"</th>\n";
}
if ($order eq "owner") {
@@ -2494,7 +2495,7 @@ sub git_project_list_body {
} else {
print "<th>" .
$cgi->a({-href => href(project=>undef, order=>'owner'),
- -class => "header"}, "Owner") .
+ -class => "header"}, "Owner") .
"</th>\n";
}
if ($order eq "age") {
@@ -2503,7 +2504,7 @@ sub git_project_list_body {
} else {
print "<th>" .
$cgi->a({-href => href(project=>undef, order=>'age'),
- -class => "header"}, "Last Change") .
+ -class => "header"}, "Last Change") .
"</th>\n";
}
print "<th></th>\n" .
@@ -2528,7 +2529,9 @@ sub git_project_list_body {
}
print "<td>" . $cgi->a({-href => href(project=>$pr->{'path'}, action=>"summary"),
-class => "list"}, esc_html($pr->{'path'})) . "</td>\n" .
- "<td>" . esc_html($pr->{'descr'}) . "</td>\n" .
+ "<td>" . $cgi->a({-href => href(project=>$pr->{'path'}, action=>"summary"),
+ -class => "list", -title => $pr->{'descr_long'}},
+ esc_html($pr->{'descr'})) . "</td>\n" .
"<td><i>" . chop_str($pr->{'owner'}, 15) . "</i></td>\n";
print "<td class=\"". age_class($pr->{'age'}) . "\">" .
$pr->{'age_string'} . "</td>\n" .
--
1.4.4.1
^ permalink raw reply related
* Re: [RFC] Submodules in GIT
From: Yann Dirson @ 2006-11-26 1:32 UTC (permalink / raw)
To: skimo; +Cc: Linus Torvalds, Steven Grimm, git
In-Reply-To: <20061126011420.GI20094MdfPADPa@greensroom.kotnet.org>
On Sun, Nov 26, 2006 at 02:14:20AM +0100, Sven Verdoolaege wrote:
> Likewise, when you commit in the superproject, it should simply record
> the changes to the "content" of the subproject and not change it.
> And the content of the subproject is a commit, so a commit in the
> superproject should not change the content of the subproject by creating
> another commit in the subproject.
I've realized after suggesting that how much that idea was inadequate -
sorry for the noise.
However, I'm not yet buying the idea that "the content of the subproject
is a commit" :)
Best regards,
--
^ permalink raw reply
* [PATCH] git-svn: allow SVN:: lib users to track the root of the repository (again)
From: Eric Wong @ 2006-11-26 1:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Eric Wong
I broke this again in 747fa12cef73b6ca04fffaddaad7326cf546cdea.
Thanks to merlyn for pointing this out to me on IRC.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-svn.perl | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 0a47b1f..de4e74a 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -2919,8 +2919,12 @@ sub libsvn_fetch {
my $p = $SVN->{svn_path};
foreach my $f (keys %$paths) {
my $m = $paths->{$f}->action();
- $f =~ s#^/\Q$p\E/##;
- next if $f =~ m#^/#;
+ if (length $p) {
+ $f =~ s#^/\Q$p\E/##;
+ next if $f =~ m#^/#;
+ } else {
+ $f =~ s#^/##;
+ }
if ($m =~ /^[DR]$/) {
print "\t$m\t$f\n" unless $_q;
process_rm($gui, $last_commit, $f);
--
1.4.4.1.gf64d
^ permalink raw reply related
* Re: [PATCH] Use new .git/config for storing "origin" shortcut repository
From: Shawn Pearce @ 2006-11-26 3:02 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200611260003.31025.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> wrote:
> If .git/remotes/ is now deprecated, then git-clone shouldn't use it.
> This patch adds the analogous definitions to .git/config using
> git-repo-config calls.
>
> For example what was previously .git/remotes/origin
> URL: proto://host/path
> Pull: refs/heads/master:refs/heads/origin
> Is now added to .git/config as
> [remote "origin"]
> url = proto://host/path
> fetch = refs/heads/master:refs/heads/origin
>
> Signed-off-by: Andy Parkins <andyparkins@gmail.com>
> ---
> I'm not sure if I'm correct in thinking that .git/remotes is deprecated. If it is,
> this patch makes git-clone use .git/config instead.
>
> Personally I like it, I think there should be as small a number of places for
> configuring the repository as possible.
I agree. There's all sorts of advantages to setting up remotes by
the config file. Its also easier to load and work with in git-gui.
:-)
I've switched to the config file syntax completely, and a few folks
I work with have done the same, citing that it is easier to have
everything in one file.
--
^ 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