* Re: remotes/* for "foreign" archives
From: Randal L. Schwartz @ 2006-11-21 16:53 UTC (permalink / raw)
To: Seth Falcon; +Cc: git
In-Reply-To: <m2y7q4bzo7.fsf@ziti.local>
>>>>> "Seth" == Seth Falcon <sethfalcon@gmail.com> writes:
Seth> This sort of integration could be quite cool. But I think the most
Seth> common use of git-svn is with rebase and not pull. My experience
Seth> with git-svn and pull is that I very quickly ended up making broken
Seth> commits to svn --- I've had much better luck rebasing.
Well, you'd still be using "git-fetch origin" then, transparently,
and your push command could do your preferred thing.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
^ permalink raw reply
* Re: Is there a way to trim old SHAs from a git tree (so it's not so large)?
From: Shawn Pearce @ 2006-11-21 16:56 UTC (permalink / raw)
To: Timur Tabi; +Cc: Thomas Kolejka, git
In-Reply-To: <45632EC6.5030902@freescale.com>
Timur Tabi <timur@freescale.com> wrote:
> >Shallow clone is a development feature still being working on in
> >Junio's 'pu' branch of git.git. It has a few issues still to be
> >worked out so it hasn't been made part of one of the more stable
> >branches yet (like 'next', 'master', or 'maint').
>
> Well, until it's available on an official git release, it doesn't help me.
One of the reasons its hanging out in 'pu' still is that there is
a lack of people who are interested in the feature, and thus not
enough people are testing it. Perhaps you might be able to lend
a hand in that regard?
--
^ permalink raw reply
* Re: Is there a way to trim old SHAs from a git tree (so it's not so large)?
From: Johannes Schindelin @ 2006-11-21 16:57 UTC (permalink / raw)
To: Timur Tabi; +Cc: Shawn Pearce, Thomas Kolejka, git
In-Reply-To: <45632EC6.5030902@freescale.com>
Hi,
On Tue, 21 Nov 2006, Timur Tabi wrote:
> Shawn Pearce wrote:
>
> > Shallow clone is a development feature still being working on in
> > Junio's 'pu' branch of git.git. It has a few issues still to be
> > worked out so it hasn't been made part of one of the more stable
> > branches yet (like 'next', 'master', or 'maint').
>
> Well, until it's available on an official git release, it doesn't help
> me.
Well, if you help it, it will be available on an official git release
soon!
Ciao,
Dscho
^ permalink raw reply
* Re: Is there a way to trim old SHAs from a git tree (so it's not so large)?
From: Timur Tabi @ 2006-11-21 17:01 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Thomas Kolejka, git
In-Reply-To: <20061121165656.GC22006@spearce.org>
Shawn Pearce wrote:
> Timur Tabi <timur@freescale.com> wrote:
>>> Shallow clone is a development feature still being working on in
>>> Junio's 'pu' branch of git.git. It has a few issues still to be
>>> worked out so it hasn't been made part of one of the more stable
>>> branches yet (like 'next', 'master', or 'maint').
>> Well, until it's available on an official git release, it doesn't help me.
>
> One of the reasons its hanging out in 'pu' still is that there is
> a lack of people who are interested in the feature, and thus not
> enough people are testing it. Perhaps you might be able to lend
> a hand in that regard?
Sure, I can do that! Can you give me some pointers? I've never done
development on git itself, so I don't know Junio or his pu (sorry, I couldn't
resist :-)).
--
Timur Tabi
^ permalink raw reply
* Re: git-show --stat on first commit
From: Peter Baumann @ 2006-11-21 17:11 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0611210820100.3338@woody.osdl.org>
On 2006-11-21, Linus Torvalds <torvalds@osdl.org> wrote:
>
>
> On Tue, 21 Nov 2006, Peter Baumann wrote:
>>
>> Why not make --root the default? I also stumbled over this behaviour and
>> even asked on this list.
>
> I suspect we should make the thing a config option, and default it to
> "on".
>
That would be great.
> I personally do _not_ want to see the root commit, because for the kernel,
> it's a honking huge import that does not make sense as a "diff". It's not
> really a diff against anything, after all - it's an import.
>
> That's really the reason why git defaults to not showing the root diff at
> all: exactly because for the kernel, the initial commit was state that
> "just came to be", and I found it both illogical and annoying to see it as
> a diff, since that commit really was a "black hole" where previous history
> just disappeared.
>
> But if you have the _full_ history with a new project, "--root" by default
> probably makes tons of sense.
>
I am aware of the import problem, especially from the kernel history.
And I think handling this behaviour as a config option is the right thing,
because most of the time if someone imports a project into git he
will import the whole history, especially if he is using one of the
cvs/svn importers. A "halfway import" as seen in the kernel repo is a
special case and it is unlikely seen again.
Peter
^ permalink raw reply
* Re: git-show --stat on first commit
From: Peter Baumann @ 2006-11-21 17:16 UTC (permalink / raw)
To: git
In-Reply-To: <ejv8pc$cig$1@sea.gmane.org>
On 2006-11-21, Jakub Narebski <jnareb@gmail.com> wrote:
> Peter Baumann wrote:
>
>> On 2006-11-21, Santi Béjar <sbejar@gmail.com> wrote:
>>> On 11/21/06, Andy Parkins <andyparkins@gmail.com> wrote:
>>>> Hello,
>>>>
>>>> I'm sure this one will be known about already. git-show --stat on the the
>>>> first commit doesn't show anything. I assume it's because git-diff-tree has
>>>> nothing to diff against (although shouldn't that be an everything-new diff?).
>>>>
>>>> Given the above; does anyone have a suggestion for what I could use as a
>>>> replacement? Even just a list of the new files would be useful.
>
> You can always use git-ls-tree
>
>>> $ git show --stat --root
>>>
>>> In general the initial commit diff (or stat) is hidden, but perhaps it
>>> make sense to show it in "git show", you asked fo this specifically.
>>
>> Why not make --root the default? I also stumbled over this behaviour and
>> even asked on this list.
>>
>> In my opinion this will help new users which are supprised that they
>> can't get the diff of the inital commit (which is totaly non-intuitiv behavior).
>>
>> And one less "wart" to clean, which another thread is all about. :-)
>
> Because for projects imported into git first commit diff is huge,
> and not very interesting. By the way, git show by default doesn't show
> diff for merges (you need --cc for that), nor rename detection (you need
> -M for that).
>
> But you can always set default diff-tree options, including --root, --cc
> and -M in the show.difftree configuration variable (either in repo config,
> or in user config). It is IMHO better solution than changing defaults.
Ah. I wasn't aware of this. Thank for this nice tip.
Peter
^ permalink raw reply
* Re: git-show --stat on first commit
From: Linus Torvalds @ 2006-11-21 17:20 UTC (permalink / raw)
To: Peter Baumann; +Cc: git
In-Reply-To: <slrnem6cpn.6vh.Peter.B.Baumann@xp.machine.xx>
On Tue, 21 Nov 2006, Peter Baumann wrote:
>
> And I think handling this behaviour as a config option is the right thing,
> because most of the time if someone imports a project into git he
> will import the whole history, especially if he is using one of the
> cvs/svn importers. A "halfway import" as seen in the kernel repo is a
> special case and it is unlikely seen again.
Actually, I see "halfway imports" all the time.
I've found that some of the git things like "git grep" etc are _so_
convenient, that whenever I get a source tar-ball for _anything_, I tend
to do
zcat < xyz-123.tar.gz | tar xvf -
cd xyz-123
git init-db
git add
git commit -m "Import xyz-123"
the first thing I do. Even if I never end up changing anything in that
archive, it's just that convenient (and fast - sure, doing the hashing and
compression means that the "git add" might not be truly instantaneous, but
it's definitely fast enough that for almost all projects, doing this is so
cheap that you don't need to care).
And _especially_ for things like this, being able to do "git log -p" to
check the small trivial one-liners that I might do is nice (it happens -
my pine4.64 import these days has three small commits to add buildnotes
and handle UTF-8 input etc).
And again, that's when you do _not_ want to see "--root". Because it's
never what you actually care about.
So I think imports are important. They may be throw-away trees like mine,
but they're still useful.
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: J. Bruce Fields @ 2006-11-21 18:01 UTC (permalink / raw)
To: Martin Waitz; +Cc: Linus Torvalds, Junio C Hamano, Jakub Narebski, git
In-Reply-To: <20061120233333.GD20736@admingilde.org>
On Tue, Nov 21, 2006 at 12:33:34AM +0100, Martin Waitz wrote:
> On Mon, Nov 20, 2006 at 06:25:07PM -0500, J. Bruce Fields wrote:
> > Would it also be possible to allow the "Tree:" line in the commit object
> > to refer to a commit, or does the root of the project need to be a
> > special case?
>
> this would then be something like the branch-archival proposal.
Do you have any pointers to previous discussion? (A couple obvious
searches don't turn up anything for me.)
^ permalink raw reply
* Re: git-show --stat on first commit
From: Petr Baudis @ 2006-11-21 18:06 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Peter Baumann, git
In-Reply-To: <Pine.LNX.4.64.0611210820100.3338@woody.osdl.org>
On Tue, Nov 21, 2006 at 05:31:30PM CET, Linus Torvalds wrote:
> git didn't end up doing that (and I'm personally pretty happy about it),
> but it was one of the things I was kind of thinking about: a "git import"
> kind of thing would have created an initial commit which was pre-populated
> with the thing to import, and a "git init-db" would have created an
> initial root commit that was empty.
>
> That would have made the current "don't show the root diff" behaviour very
> natural (and you'd still have gotten the initial diff for a new project),
> but on the other hand, it would have had that annoying unnecessary "init"
> commit, and you'd _still_ have wanted to have something like "--root" in
> order to show the import commit as a patch (which you _sometimes_ want to
> do).
It's being asked by users time by time (first in April last year ;) and
I'm not sure about any good answer I should tell them, so is the reason
for not doing the implicit empty commit that it would be "annoying" I
suppose in the log output?
Is that a reason good enough?
It would solve some of these annoying corner cases nicely, and you can
still hide this empty commit from log output etc.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
The meaning of Stonehenge in Traflamadorian, when viewed from above, is:
"Replacement part being rushed with all possible speed."
^ permalink raw reply
* Re: git-show --stat on first commit
From: Horst H. von Brand @ 2006-11-21 18:14 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ejv8pc$cig$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> wrote:
> Peter Baumann wrote:
> > On 2006-11-21, Santi Béjar <sbejar@gmail.com> wrote:
> >> On 11/21/06, Andy Parkins <andyparkins@gmail.com> wrote:
[...]
> >> In general the initial commit diff (or stat) is hidden, but perhaps it
> >> make sense to show it in "git show", you asked fo this specifically.
> > Why not make --root the default? I also stumbled over this behaviour and
> > even asked on this list.
> > In my opinion this will help new users which are supprised that they
> > can't get the diff of the inital commit (which is totaly non-intuitiv
> > behavior).
> > And one less "wart" to clean, which another thread is all about. :-)
Count me in! A freshly created repo should be just empty, not some strange
construction that isn't a real repo. The empty set /is/ real useful, you
know. Even if it is just for symmetry.
> Because for projects imported into git first commit diff is huge,
> and not very interesting.
That isn't your call to make. Sure, if I just untarred something large and
gitified it, I /know/ the diff to "before" is huge, and not really
informative, and I'll abstain from asking for it. But if I just started a
project with a half dozen files, I'd like to see what came before, or look
at the difference to "5 commits back" (which just happens to be every
change, as there are 4 commits in all).
The main focus here is on large(ish) projects with a lot of history, but if
you want to be able to get some mindshare you will have to look at the
other end, projects just getting off the ground.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
^ permalink raw reply
* Re: git-show --stat on first commit
From: Jakub Narebski @ 2006-11-21 18:16 UTC (permalink / raw)
To: git
In-Reply-To: <20061121180643.GC7201@pasky.or.cz>
Petr Baudis wrote:
> On Tue, Nov 21, 2006 at 05:31:30PM CET, Linus Torvalds wrote:
>> git didn't end up doing that (and I'm personally pretty happy about it),
>> but it was one of the things I was kind of thinking about: a "git import"
>> kind of thing would have created an initial commit which was pre-populated
>> with the thing to import, and a "git init-db" would have created an
>> initial root commit that was empty.
>>
>> That would have made the current "don't show the root diff" behaviour very
>> natural (and you'd still have gotten the initial diff for a new project),
>> but on the other hand, it would have had that annoying unnecessary "init"
>> commit, and you'd _still_ have wanted to have something like "--root" in
>> order to show the import commit as a patch (which you _sometimes_ want to
>> do).
>
> It's being asked by users time by time (first in April last year ;) and
> I'm not sure about any good answer I should tell them, so is the reason
> for not doing the implicit empty commit that it would be "annoying" I
> suppose in the log output?
git repo-config show.difftree --root
git repo-config whatchanged.difftree --root
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git-show --stat on first commit
From: Petr Baudis @ 2006-11-21 18:21 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ejvfng$cj6$1@sea.gmane.org>
On Tue, Nov 21, 2006 at 07:16:44PM CET, Jakub Narebski wrote:
> Petr Baudis wrote:
>
> > On Tue, Nov 21, 2006 at 05:31:30PM CET, Linus Torvalds wrote:
> >> git didn't end up doing that (and I'm personally pretty happy about it),
> >> but it was one of the things I was kind of thinking about: a "git import"
> >> kind of thing would have created an initial commit which was pre-populated
> >> with the thing to import, and a "git init-db" would have created an
> >> initial root commit that was empty.
> >>
> >> That would have made the current "don't show the root diff" behaviour very
> >> natural (and you'd still have gotten the initial diff for a new project),
> >> but on the other hand, it would have had that annoying unnecessary "init"
> >> commit, and you'd _still_ have wanted to have something like "--root" in
> >> order to show the import commit as a patch (which you _sometimes_ want to
> >> do).
> >
> > It's being asked by users time by time (first in April last year ;) and
> > I'm not sure about any good answer I should tell them, so is the reason
> > for not doing the implicit empty commit that it would be "annoying" I
> > suppose in the log output?
>
> git repo-config show.difftree --root
> git repo-config whatchanged.difftree --root
That means extra pointless setup and is besides the point anyway, I was
asking about empty commits, not default command settings.
BTW, the other frequent reason why empty commits come up so frequently
is a FAQ "how do I create an unrelated branch in my repository" - their
idea is that they will create a new branch starting with an empty commit
(of course noone would think of anything like that in inferior VCSes
because replacing the checked out trees would took forever; how cool Git
is!).
(The answer is usually "create the branch in a separate repo and then
fetch it to the original one". But it feels a bit kludgy given the
otherwise seamless support for unrelated branches. (Not that I ever was
a big fan of unrelated long-lived branches in general.))
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
The meaning of Stonehenge in Traflamadorian, when viewed from above, is:
"Replacement part being rushed with all possible speed."
^ permalink raw reply
* Re: git-show --stat on first commit
From: Shawn Pearce @ 2006-11-21 18:34 UTC (permalink / raw)
To: Petr Baudis; +Cc: Jakub Narebski, git
In-Reply-To: <20061121182135.GD7201@pasky.or.cz>
Petr Baudis <pasky@suse.cz> wrote:
> BTW, the other frequent reason why empty commits come up so frequently
> is a FAQ "how do I create an unrelated branch in my repository" - their
> idea is that they will create a new branch starting with an empty commit
> (of course noone would think of anything like that in inferior VCSes
> because replacing the checked out trees would took forever; how cool Git
> is!).
>
> (The answer is usually "create the branch in a separate repo and then
> fetch it to the original one". But it feels a bit kludgy given the
> otherwise seamless support for unrelated branches. (Not that I ever was
> a big fan of unrelated long-lived branches in general.))
Or just abuse git-symbolic-ref:
rm .git/index
git symbolic-ref HEAD refs/heads/unrelated-branch
git add ...
git commit ...
see, so simple. And no need to create an unrelated repository and
pull across to this one...
--
^ permalink raw reply
* Re: git-show --stat on first commit
From: Olivier Galibert @ 2006-11-21 18:38 UTC (permalink / raw)
To: Peter Baumann; +Cc: git
In-Reply-To: <slrnem6cpn.6vh.Peter.B.Baumann@xp.machine.xx>
On Tue, Nov 21, 2006 at 06:11:19PM +0100, Peter Baumann wrote:
> And I think handling this behaviour as a config option is the right thing,
> because most of the time if someone imports a project into git he
> will import the whole history, especially if he is using one of the
> cvs/svn importers. A "halfway import" as seen in the kernel repo is a
> special case and it is unlikely seen again.
Not all projects run on a public VCS. Hell, not all projects run on a
VCS at all. And in the CVS case, you don't always have enough access
to actually download the repository, which afaik is needed for
importing.
OG.
^ permalink raw reply
* Re: Is there a way to trim old SHAs from a git tree (so it's not so large)?
From: Shawn Pearce @ 2006-11-21 18:39 UTC (permalink / raw)
To: Timur Tabi; +Cc: Thomas Kolejka, git
In-Reply-To: <456330CD.9080503@freescale.com>
Timur Tabi <timur@freescale.com> wrote:
> Shawn Pearce wrote:
> >Timur Tabi <timur@freescale.com> wrote:
> >>>Shallow clone is a development feature still being working on in
> >>>Junio's 'pu' branch of git.git. It has a few issues still to be
> >>>worked out so it hasn't been made part of one of the more stable
> >>>branches yet (like 'next', 'master', or 'maint').
> >>Well, until it's available on an official git release, it doesn't help me.
> >
> >One of the reasons its hanging out in 'pu' still is that there is
> >a lack of people who are interested in the feature, and thus not
> >enough people are testing it. Perhaps you might be able to lend
> >a hand in that regard?
>
> Sure, I can do that! Can you give me some pointers? I've never done
> development on git itself, so I don't know Junio or his pu (sorry, I
> couldn't resist :-)).
Junio C Hamano is the Git maintainer. His published Git repository
is here:
http://www.kernel.org/pub/scm/git/git.git/
though it oddly has pack files from Jun 2006 in the wrong directory.
Weird. Anyway...
If you clone from that URL, or better though the native Git protocol:
git://www.kernel.org/pub/scm/git/git.git
you will get a branch called `pu`, which is the set of "Proposed
Updates" to Git that Junio and others are currently working on.
You can then checkout a branch off that, and build it:
git checkout -b pu-build pu
make
finally you can either run from that directory (see INSTALL file)
or you can install the binary somewhere else. We don't really
recommend using `pu` for production level work, so make sure you
have a backup of any repository you run it on. :)
--
^ permalink raw reply
* Re: git-show --stat on first commit
From: Carl Worth @ 2006-11-21 18:39 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Peter Baumann, git
In-Reply-To: <Pine.LNX.4.64.0611210820100.3338@woody.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 3026 bytes --]
On Tue, 21 Nov 2006 08:31:30 -0800 (PST), Linus Torvalds wrote:
> I suspect we should make the thing a config option, and default it to
> "on".
Agreed. That would be fabulous!
> That's really the reason why git defaults to not showing the root diff at
> all: exactly because for the kernel, the initial commit was state that
> "just came to be", and I found it both illogical and annoying to see it as
> a diff, since that commit really was a "black hole" where previous history
> just disappeared.
Ah, that's a rationale I wouldn't have guessed.
> There's also another reason for the root being special, which is purely
> git-internal: the root really has no parents at all, and the normal "git
> diff" is "diff against parents".
This is the rationale I was guessing was the cause. It clearly takes
a special case in the code to show the root diff, and --root seemed
like that special-case implementation leaking into the interface,
(where, usually, the user wouldn't expect the first commit to be any
different than any other).
This looks like yet another case where a feature was added, and a new
command-line option with it, when what was really wanted was a new
default.
> git didn't end up doing that (and I'm personally pretty happy about it),
It seems a reasonable enough decision, but it does have some
impacts. Several of the tools don't work in the strange state between
git-init and the first git-commit. Some of these are getting worked
out now, (such as pull), but Junio was still objecting to fixing diff
to work.
There's a decision to have git's internals support this intermediate
state, but all the tools should be made completely functional. This is
an important things to get right, since this is the first state in
which a new user will have her repository, (right after doing
git-init-db as the first step in the tutorial). So it's important to
make this state functional and not have to explain the "strange"
implementation details "Normally, you would have a branch HEAD at this
point, so these commands would usually work even though they don't
yet, etc. etc."
> So having a config option would solve the problem,
If the default is fixed, yes.
> but what annoys me
> right now about the config options is that we really should have a
> graphical front-end to setting those things or something, because while
> _I_ don't have any issues with editing a ".git/config" file, I think we're
> getting to the point where a lot of our problems are really about "you can
> do it, but you have to know a lot about git to even know you can do it".
I agree with that statement. But I also think that for the "new user
problems" a new graphical tool for twiddling git options wouldn't make
the system any less imposing. On the other hand, getting the defaults
to be less surprising would definitely help, (and configuration
options can be used to good effect to allow "old-timers" to maintain
the behavior they're used to as defaults change).
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git-show --stat on first commit
From: Andy Parkins @ 2006-11-21 18:39 UTC (permalink / raw)
To: git
In-Reply-To: <20061121182135.GD7201@pasky.or.cz>
On Tuesday 2006, November 21 18:21, Petr Baudis wrote:
> (The answer is usually "create the branch in a separate repo and then
> fetch it to the original one". But it feels a bit kludgy given the
> otherwise seamless support for unrelated branches. (Not that I ever was
> a big fan of unrelated long-lived branches in general.))
Just as kludgy, but I did this today by writing the name of the new branch
in .git/HEAD then doing
for file in $(git-ls-files); do git-update-index --force-remove $file; done
Before creating the new files and "git-commit"ing.
Andy
--
Dr Andrew Parkins, M Eng (Hons), AMIEE
^ permalink raw reply
* Re: git-show --stat on first commit
From: Shawn Pearce @ 2006-11-21 18:42 UTC (permalink / raw)
To: Olivier Galibert; +Cc: Peter Baumann, git
In-Reply-To: <20061121183853.GA61605@dspnet.fr.eu.org>
Olivier Galibert <galibert@pobox.com> wrote:
> On Tue, Nov 21, 2006 at 06:11:19PM +0100, Peter Baumann wrote:
> > And I think handling this behaviour as a config option is the right thing,
> > because most of the time if someone imports a project into git he
> > will import the whole history, especially if he is using one of the
> > cvs/svn importers. A "halfway import" as seen in the kernel repo is a
> > special case and it is unlikely seen again.
>
> Not all projects run on a public VCS. Hell, not all projects run on a
> VCS at all. And in the CVS case, you don't always have enough access
> to actually download the repository, which afaik is needed for
> importing.
There is a tool floating around the 'net that will download
a CVS repository and recreate the ,v files locally for you.
cvssuck appears to be its name:
http://freshmeat.net/projects/cvssuck/
--
^ permalink raw reply
* Re: git-show --stat on first commit
From: Petr Baudis @ 2006-11-21 18:48 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200611211839.58709.andyparkins@gmail.com>
On Tue, Nov 21, 2006 at 07:39:56PM CET, Andy Parkins wrote:
> On Tuesday 2006, November 21 18:21, Petr Baudis wrote:
>
> > (The answer is usually "create the branch in a separate repo and then
> > fetch it to the original one". But it feels a bit kludgy given the
> > otherwise seamless support for unrelated branches. (Not that I ever was
> > a big fan of unrelated long-lived branches in general.))
>
> Just as kludgy, but I did this today by writing the name of the new branch
> in .git/HEAD then doing
>
> for file in $(git-ls-files); do git-update-index --force-remove $file; done
>
> Before creating the new files and "git-commit"ing.
Ok, this approach looks actually reasonable (contrary to the frequently
suggested rm approach, which is rather dangerous).
Perhaps git checkout --empty could do this?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
The meaning of Stonehenge in Traflamadorian, when viewed from above, is:
"Replacement part being rushed with all possible speed."
^ permalink raw reply
* Re: git-show --stat on first commit
From: Shawn Pearce @ 2006-11-21 18:52 UTC (permalink / raw)
To: Petr Baudis; +Cc: Andy Parkins, git
In-Reply-To: <20061121184817.GE7201@pasky.or.cz>
Petr Baudis <pasky@suse.cz> wrote:
> On Tue, Nov 21, 2006 at 07:39:56PM CET, Andy Parkins wrote:
> > for file in $(git-ls-files); do git-update-index --force-remove $file; done
> >
> > Before creating the new files and "git-commit"ing.
>
> Ok, this approach looks actually reasonable (contrary to the frequently
> suggested rm approach, which is rather dangerous).
>
> Perhaps git checkout --empty could do this?
Or perhaps just delete .git/index?
Any git-update-index --add or git-add command will immediately create
an empty index. Indeed this is the initial state after git-init-db,
since there is no HEAD to load into the index there is no index...
--
^ permalink raw reply
* [PATCH] Teach SubmittingPatches about git-commit -s
From: Paolo Ciarrocchi @ 2006-11-21 18:55 UTC (permalink / raw)
To: git
[PATCH] Teach SubmittingPatches about git-commit -s
As discussed on git mailing list let's teach the reader about
the possiblity to have automatically signed off the commit running
the git-commit -s command
Signed-off-by: Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com>
---
Documentation/SubmittingPatches | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 8a3d316..20193cc 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -149,6 +149,7 @@ then you just add a line saying
Signed-off-by: Random J Developer <random@developer.example.org>
+This line can be automatically added by git if you run the git-commit command with the -s option
Some people also put extra tags at the end. They'll just be ignored for
now, but you can do this to mark internal company procedures or just
point out some special detail about the sign-off.
--
1.4.4.gef06
^ permalink raw reply related
* Re: git-show --stat on first commit
From: Petr Baudis @ 2006-11-21 19:04 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Andy Parkins, git
In-Reply-To: <20061121185259.GA22461@spearce.org>
On Tue, Nov 21, 2006 at 07:52:59PM CET, Shawn Pearce wrote:
> Petr Baudis <pasky@suse.cz> wrote:
> > On Tue, Nov 21, 2006 at 07:39:56PM CET, Andy Parkins wrote:
> > > for file in $(git-ls-files); do git-update-index --force-remove $file; done
> > >
> > > Before creating the new files and "git-commit"ing.
> >
> > Ok, this approach looks actually reasonable (contrary to the frequently
> > suggested rm approach, which is rather dangerous).
> >
> > Perhaps git checkout --empty could do this?
>
> Or perhaps just delete .git/index?
>
> Any git-update-index --add or git-add command will immediately create
> an empty index. Indeed this is the initial state after git-init-db,
> since there is no HEAD to load into the index there is no index...
But your working tree has still the contents of the old branch.
Sure, you could possibly just remove the files and then the index at
once but that are just details.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
The meaning of Stonehenge in Traflamadorian, when viewed from above, is:
"Replacement part being rushed with all possible speed."
^ permalink raw reply
* Re: git-show --stat on first commit
From: Petr Baudis @ 2006-11-21 19:05 UTC (permalink / raw)
To: Olivier Galibert; +Cc: Peter Baumann, git
In-Reply-To: <20061121183853.GA61605@dspnet.fr.eu.org>
On Tue, Nov 21, 2006 at 07:38:53PM CET, Olivier Galibert wrote:
> On Tue, Nov 21, 2006 at 06:11:19PM +0100, Peter Baumann wrote:
> > And I think handling this behaviour as a config option is the right thing,
> > because most of the time if someone imports a project into git he
> > will import the whole history, especially if he is using one of the
> > cvs/svn importers. A "halfway import" as seen in the kernel repo is a
> > special case and it is unlikely seen again.
>
> Not all projects run on a public VCS. Hell, not all projects run on a
> VCS at all. And in the CVS case, you don't always have enough access
> to actually download the repository, which afaik is needed for
> importing.
It isn't needed. It's probably much slower over the net but that's how I
created the glibc-cvs.git repository (at repo.or.cz); cvsps can operate
over the network.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
The meaning of Stonehenge in Traflamadorian, when viewed from above, is:
"Replacement part being rushed with all possible speed."
^ permalink raw reply
* Re: git-show --stat on first commit
From: Junio C Hamano @ 2006-11-21 19:15 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0611210820100.3338@woody.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Tue, 21 Nov 2006, Peter Baumann wrote:
>>
>> Why not make --root the default? I also stumbled over this behaviour and
>> even asked on this list.
>
> I suspect we should make the thing a config option, and default it to
> "on".
>
> I personally do _not_ want to see the root commit, because for the kernel,
> it's a honking huge import that does not make sense as a "diff". It's not
> really a diff against anything, after all - it's an import.
>
> That's really the reason why git defaults to not showing the root diff at
> all: exactly because for the kernel, the initial commit was state that
> "just came to be", and I found it both illogical and annoying to see it as
> a diff, since that commit really was a "black hole" where previous history
> just disappeared.
>
> But if you have the _full_ history with a new project, "--root" by default
> probably makes tons of sense.
I agree fully with the above. Let's make it happen.
^ permalink raw reply
* Re: git-show --stat on first commit
From: Junio C Hamano @ 2006-11-21 19:31 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20061121182135.GD7201@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> On Tue, Nov 21, 2006 at 07:16:44PM CET, Jakub Narebski wrote:
>..
>> git repo-config show.difftree --root
>> git repo-config whatchanged.difftree --root
>
> That means extra pointless setup and is besides the point anyway, I was
> asking about empty commits, not default command settings.
I agree with you. Personally, I think:
- show is where the user is asking for _that_ particular
commit, so it can safely default to --root, always. No
option is needed.
- what we want for log and underlying rev-list is majorly
dependent of the nature of the root commit. Per repository
(or even per root) option which defaults to "on" (I was
going to say "off" to be backward compatible and convenient
for "me", but even Linus says "on" so I am playing along)
would make sense.
So just "core.showroot = yes | no" would be the only thing we
would need, I think. Unless we do fancier "core.hideroot =
SHA1-1 SHA1-2 ..." to say "these root should not be shown",
that is.
> BTW, the other frequent reason why empty commits come up so frequently
> is a FAQ "how do I create an unrelated branch in my repository" - their
> idea is that they will create a new branch starting with an empty commit
> (of course noone would think of anything like that in inferior VCSes
> because replacing the checked out trees would took forever; how cool Git
> is!).
I wrote something about this after reading #git log several days
ago where somebody named Insount (sp?) was talking about
"elegant idea" of the empty initial commit, but did not send it
and kept silent about it. As Linus said in an earlier message,
I've thought about this and am personally happy about the
current way of not having it, and here is why.
Interestingly, I already talked about "show --root" in the
message that I did not send -- I think you made this the right
thread to post it in ;-)
-- >8 --
Subject: empty initial commit
Don't do it. It is stupid.
I'm imitating somebody who says "I am so right that it
hurts". Don't worry, I'll come back to my usual self
and talk about what is wrong with our current tools and
what needs to be fixed shortly ;-).
(1) Your claim that it is elegant because it removes a special
case is bogus, because you are not removing special cases
anyway.
The initial commit _is_ special. The first real example in
"everyday" document begins by creating the initial commit out of
an extracted tarball. You would _actively_ want to special case
that commit. Its diff from nothingness is so uninteresting
while inspecting the development history of the project that we
do not even show it in "git log -p" output unless explicitly
asked with "--root" option, for example [side note: we might
want to default to --root for "git show", which clearly
indicates that the user is interested in that particular one
commit]. If you introduce the fake "epoch" commit, then you
have to move that special case logic elsewhere and squelch the
output when the parent is a commit with an empty tree, instead
of the current logic which is to omit it when it is the root
commit. You have to have special case either way.
(2) A branch yet to be born (i.e. a freshly initialized
repository whose HEAD points at refs/heads/master that does
not exist yet) and a branch whose tip points at a fake
"epoch" commit are fundamentally different.
Let's remember our GIT 101. Two commits that happen to have the
same tree are not equivalent, because a commit represents both
the then-current state when it was made _and_ the development
history that led to it. The development history is represented
by chains of commits.
Earlier Linus and I updated git-pull to allow pulling into a
branch yet to be born because a branch yet to be born _is_ an
ancestor of any commit and can be fast-forwarded. There was no
branch and there was no earlier history.
You cannot say the same thing for a branch that points at a root
commit that has an empty tree. For one thing it would record
authorship information and stuff so it won't be "THE universal
void". You can have infinite (well, bounded by 2^160 because we
use SHA-1 to name objects) such root commits, and they are not
equivalent. Does that mean a true root commit (not your fake
commit) can be a child of 2^160 empty parents that are all
alike? Which one of them do you choose to record as its parent
and why?
If you start two branches with your scheme, they will have two
different fake root commits -- when merging these two branches
that were independently born, should these fake root commits be
treated as equivalents for merge-base computation? If so that
introduces a very special case that we currently do not need in
a very deep place. But we can already do a merge without common
ancestor just fine (I've done one myself and Linus did two), so
these 2^160 empty fake commits are not adding value to the
system.
Of course, you could use "THE truly universal void" commit that is
by convention created in every git repository that has some
agreed-upon author/committer/log information as that fake root
and uniformly use it everywhere to solve the above, to emulate
what we already do. But we have been doing fine without such a
fake commit, thank you.
So it's stupid to introduce such a fake commit. Don't do it.
Now, back to my usual self.
I suspect that an independent branch creation inside an existing
repository is not an everyday event, and your complaint is
primarily coming from the fact that you somehow wanted to do
that recently and there was not a canned way to do so, not
because you need to do that very often and the tool is lacking.
But for the moment, let's say it is an everyday event and making
it easy to do so adds to the general value of our toolset.
I think the real shortcoming of the current set of tools is that
while it allows you to be initially on a yet-to-be-born branch,
it does not offer you a way to be on another yet-to-be-born
branch once you created the first branch.
The command "git branch $newbranch" wants a commit to begin the
newly created branch at. Another, "git checkout -b $newbranch",
has the same property. If you do not give the starting commit,
they conveniently defaults to HEAD, which is inconvenient for
what you want.
So it _is_ cumbersome to create (or, "not to create") and be on
a yet-to-be-born branch, and as a consequence, it is not
possible unless you go down to bare plumbing level to start two
unrelated histories in one repository. We do not give you a
direct way to do that. An obvious workaround is to create a new
repository to start a separate history afresh and fetch that
branch in, but if an independent branch creation had a valid
purpose and were an everyday event, it certainly is merely a
workaround and shows that the toolset is lacking.
Maybe a new option "git checkout --void $newbranchname", which
does a rough equivalent of:
new="refs/heads/$newbranchname"
git show-ref -q --verify "$new" &&
die "branch $newbranchname already exists"
# git ls-files -z | xargs -0 rm -f
rm -f .git/index
git symbolic-ref HEAD "$new"
is what you would want to add. I am undecided about the
commented out part to remove everything from the working tree,
though. On one hand, if you are running "git init-db" in a
directory full of files from an extracted tarball, we would not
touch any existing files, but on the other hand, since we are
interested in creating a totally unrelated history, losing
tracked files feels more like the right thing to do.
In any case, I suspect you need to have a bit more convincing
and persuasive argument why creating and maintaining more than
one, totally unrelated histories in a single repository is
necessary.
And "git.git has more than one roots and it looks kinda cool" is
not a convincing argument at all. For one thing, these roots
were not created in a single repository. The true git root was
done in Linus's dircache project back when there was no multiple
branches, gitk, git-tools and gitweb were all done in their own
separate repositories and later merged in to be part of the
current tip of the master.
Todo, html and man roots all come from their own separate
repositories and because they are not part of the history of the
git development they are still independent.
The real reason I have "todo" in git.git was because the parent
directory /pub/scm/git/ was not writable to me at kernel.org and
I was too lazy to ask for ownership/permission changed when I
took over /pub/scm/git/git.git; I otherwise would have created a
separate git-todo.git next to git.git there.
And the reason html and man roots are in git.git is because
having "todo" in git.git turned out to be not-so-disastrous as I
feared when I first did so, and it seemed like an interesting
way to experiment on the "central place to distribute unrelated
stuff" idea. But they come from their own separate
repositories.
By the way, I would solve B1..B100 merge issue without special
casing by:
git checkout -b merged B$(pick-randomly 1 100)
i=1
while test $i -le 100
do
git pull . B$i
i=$(($i + 1))
done
Starting from a randomly picked parent and starting from an void
(created with "git checkout --void" we discussed above) would
give you exactly the same result because pulling B$i on top of
B$i (or something that already has merged B$i) is a fast
forward.
^ 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