* 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: Timur Tabi @ 2006-11-21 16:52 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Thomas Kolejka, git
In-Reply-To: <20061121163206.GA22006@spearce.org>
Shawn Pearce wrote:
> Twice the size of a normal tarball isn't too bad, considering that
> you have the _complete_ history in the pack and yet the normal
> tarball has no history at all.
That is true. However, for the particular project I'm working on, double the
size is not really acceptable.
My goal is to provide a source tree that is "git enabled", so that user can use
git command to fetch, apply, and create patches. Currently, we're just handing
out tarballs, so we want to move people to the 21st century.
> 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.
--
Timur Tabi
^ permalink raw reply
* Re: git-show --stat on first commit
From: Shawn Pearce @ 2006-11-21 16:47 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Peter Baumann, git
In-Reply-To: <Pine.LNX.4.64.0611210820100.3338@woody.osdl.org>
Linus Torvalds <torvalds@osdl.org> wrote:
> So having a config option would solve the problem, 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".
Funny; I recently thought about rewriting Documentation/config.txt
into a format that was not only easily read by asciidoc but which
also had enough annotation data to render a Tk based UI from.
That way we could always have the configuration option editor match
the current set of configuration options, and also offer good help
for them. E.g. use a checkbox for booleans, a tk_optionMenu for
choice lists, and offer up the asciidoc text as "help" on the option.
Its sort of in the back of my mind as something I'd like to do
in git-gui, but right now branch management (creating, deleting,
merging) is more important.
Right now git-gui does have a GUI editor for its own configuration
data that it keeps in "gui" sections of .git/config and
~/.gitconfig, and lets the user view and edit both.
--
^ permalink raw reply
* Re: git-show --stat on first commit
From: Linus Torvalds @ 2006-11-21 16:31 UTC (permalink / raw)
To: Peter Baumann; +Cc: git
In-Reply-To: <slrnem694k.4lm.Peter.B.Baumann@xp.machine.xx>
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.
> And one less "wart" to clean, which another thread is all about. :-)
I really don't think it's a wart - see above - but it depends on the
project.
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". So from a purely implementation
standpoint, the "root" case is actually a special case, and for a while I
was kind of wondering whether I should do what a lot of other SCM's seem
to do, namely start out with an "empty root" when doing "git init-db".
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).
So having a config option would solve the problem, 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".
^ 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:32 UTC (permalink / raw)
To: Timur Tabi; +Cc: Thomas Kolejka, git
In-Reply-To: <45632957.5070205@freescale.com>
Timur Tabi <timur@freescale.com> wrote:
> Thomas Kolejka wrote:
>
> >Is it possible to do this with shallow clone?
>
> Maybe. How do you do a shallow clone? I tried "git clone" followed by
> "git-repack", and that helped a lot, but the result was still twice the
> size of a normal tarball. I don't see any "shallow" option to the clone
> command, and git-shallow-pack doesn't exist on my installation.
Twice the size of a normal tarball isn't too bad, considering that
you have the _complete_ history in the pack and yet the normal
tarball has no history at all.
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').
--
^ 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 16:29 UTC (permalink / raw)
To: Thomas Kolejka; +Cc: git
In-Reply-To: <20061117103611.183640@gmx.net>
Thomas Kolejka wrote:
> Is it possible to do this with shallow clone?
Maybe. How do you do a shallow clone? I tried "git clone" followed by
"git-repack", and that helped a lot, but the result was still twice the size of
a normal tarball. I don't see any "shallow" option to the clone command, and
git-shallow-pack doesn't exist on my installation.
--
Timur Tabi
^ permalink raw reply
* Re: git-show --stat on first commit
From: Jakub Narebski @ 2006-11-21 16:18 UTC (permalink / raw)
To: git
In-Reply-To: <slrnem694k.4lm.Peter.B.Baumann@xp.machine.xx>
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.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git-show --stat on first commit
From: Peter Baumann @ 2006-11-21 16:08 UTC (permalink / raw)
To: git
In-Reply-To: <8aa486160611210609h1c2d229ekf0b5e8aeb4f21f11@mail.gmail.com>
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.
>
> $ 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.
>
> Santi
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. :-)
Peter
^ permalink raw reply
* Re: Merging in commits from a non-common ancestors
From: Jakub Narebski @ 2006-11-21 15:41 UTC (permalink / raw)
To: git
In-Reply-To: <1164122884.28560.210.camel@okra.transitives.com>
Alex Bennee wrote:
> I've been experimenting with using git alongside our CVS to manage my
> own development. In an ideal world I would have a full git tree with all
> the baselines tagged in it so merging is painless. However for the time
> being I have written a script to import a cvs tag into a git tree (that
> ignores the CVS gubbins). However one of the things I want to achieve is
> the ability to easily move hacks/patches from one tree to another.
>
> The problem is that these tree's don't have common ancestor's in the git
> tree as I haven't imported all our baselines. However the individual
> commits should apply, I'm just not sure how to tell git to apply the
> commits as patches rather than try and work out the full differences
> between the two trees. Of course I'd like git to keep the commit
> messages.
git cherry-pick. It uses patching instead of merging.
Or git-format-patch plus git-am.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Merging in commits from a non-common ancestors
From: Alex Bennee @ 2006-11-21 15:28 UTC (permalink / raw)
To: Git Mailing List
Hi,
I've been experimenting with using git alongside our CVS to manage my
own development. In an ideal world I would have a full git tree with all
the baselines tagged in it so merging is painless. However for the time
being I have written a script to import a cvs tag into a git tree (that
ignores the CVS gubbins). However one of the things I want to achieve is
the ability to easily move hacks/patches from one tree to another.
The problem is that these tree's don't have common ancestor's in the git
tree as I haven't imported all our baselines. However the individual
commits should apply, I'm just not sure how to tell git to apply the
commits as patches rather than try and work out the full differences
between the two trees. Of course I'd like git to keep the commit
messages.
Am I missing something blindingly obvious?
--
Alex, homepage: http://www.bennee.com/~alex/
In seeking the unattainable, simplicity only gets in the way. --
Epigrams in Programming, ACM SIGPLAN Sept. 1982
^ permalink raw reply
* Re: remotes/* for "foreign" archives
From: Seth Falcon @ 2006-11-21 15:13 UTC (permalink / raw)
To: git
In-Reply-To: <86r6vwkfti.fsf@blue.stonehenge.com>
merlyn@stonehenge.com (Randal L. Schwartz) writes:
> It occurred to me after posting this, and while still thinking about the
> presentation I'm writing, that it'd be interesting if "get-fetch" could hide
> this from me.
>
> If the file in remotes/origin looked something like:
>
> Pull: !git-svn multi-fetch trunk
> Push: !git-svn commit
>
> then git-fetch and git-push could treat "origin" as a "foreign" branch
> and indirect through these commands.
>
> Then I could just use "git-pull" naively, and it would git-fetch origin,
> invoking git-svn multi-fetch trunk to update it, and later I could
> git-push and it would use git-svn commit.
This sort of integration could be quite cool. But I think the most
common use of git-svn is with rebase and not pull. My experience
with git-svn and pull is that I very quickly ended up making broken
commits to svn --- I've had much better luck rebasing.
^ permalink raw reply
* remotes/* for "foreign" archives (was Re: tracking many cvs/svn/git remote archives)
From: Randal L. Schwartz @ 2006-11-21 14:57 UTC (permalink / raw)
To: git
In-Reply-To: <86y7q6m3zm.fsf@blue.stonehenge.com>
>>>>> "Randal" == Randal L Schwartz <merlyn@stonehenge.com> writes:
Randal> *-GIT*)
Randal> ## first, update "origin":
Randal> case $i in
Randal> *-GIT)
Randal> git-fetch
Randal> ;;
Randal> *-GITCVS)
Randal> git-cvsimport -k -i $(git-repo-config getcvs.gitcvsargs)
Randal> ;;
Randal> *-GITSVN)
Randal> ## be sure to have origin "ref: refs/remotes/git-svn"
Randal> git-svn multi-fetch
Randal> ;;
Randal> esac
It occurred to me after posting this, and while still thinking about the
presentation I'm writing, that it'd be interesting if "get-fetch" could hide
this from me.
If the file in remotes/origin looked something like:
Pull: !git-svn multi-fetch trunk
Push: !git-svn commit
then git-fetch and git-push could treat "origin" as a "foreign" branch
and indirect through these commands.
Then I could just use "git-pull" naively, and it would git-fetch origin,
invoking git-svn multi-fetch trunk to update it, and later I could
git-push and it would use git-svn commit.
This idea is half baked, but it could definitely hide the various foreign
adaptors from the invocation line, allowing layered tools to use them
transparently.
--
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: git-show --stat on first commit
From: Santi Béjar @ 2006-11-21 14:09 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200611211341.48862.andyparkins@gmail.com>
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.
$ 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.
^ permalink raw reply
* Re: git-show --stat on first commit
From: Jakub Narebski @ 2006-11-21 14:01 UTC (permalink / raw)
To: git
In-Reply-To: <200611211341.48862.andyparkins@gmail.com>
Andy Parkins wrote:
> 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?).
Yes, and git-diff-tree requires --root option if you want to generate
creation diff for initial (parentless, root) commit.
> 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.
git show --stat --root
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* git-show --stat on first commit
From: Andy Parkins @ 2006-11-21 13:41 UTC (permalink / raw)
To: git
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.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Jerome Lovy @ 2006-11-21 13:25 UTC (permalink / raw)
To: git
In-Reply-To: <87velgs9hx.wl%cworth@cworth.org>
On Wed, 15 Nov 2006, Carl Worth wrote:
> Well, one of the problems is that with current git I can teach, (and I
> have), that there's a conceptual:
>
> pull = fetch + merge
>
> But then shortly after I have to teach an interface notion:
>
> merge = pull .
>
> So there's this goofy circular notion that people end up with
> mentally. If we fix it so that a local merge really is performed with
> "git merge <branch>" instead of "git pull . <branch>" then teaching
> pull=fetch+merge really is a lot easier.
On a conceptual level, can we not perhaps explain that if
pull = fetch + merge
then
merge = pull - fetch
and that the latter (pull - fetch) happens to be expressed with the
interface as 'git pull .' ?
My 2 cents.
Jérôme
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Martin Waitz @ 2006-11-21 11:49 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ejuit4$mg$1@sea.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1141 bytes --]
hoi :)
On Tue, Nov 21, 2006 at 11:04:46AM +0100, Jakub Narebski wrote:
> "bind" header in commit objects is meant as a kind of shortcut, to ease
> reachability checking (you don't need to recurse into directories).
Well, but you already have to recurse to find all objects which are
reachable by a commit, so you don't loose anything.
> > The advantage in your proposal would be that submodules would
> > be visible immediately when looking at the commit,
> > without having to traverse the entire tree.
> > This may be worthwhile when showing the combined history of parent
> > and submodules.
>
> That was the idea.
On the other hand that only has to be done once anyway.
After you traversed the tree once you can create your own
(in memory) cache of submodules connected to the tree.
While walking the commits backwards, you only have to check those
parts of the tree which have changed.
So it may even be suitable for larger repositories.
But clearly it is not as low as with the in-commit cache.
So we have to weight complexity of the data storage with
runtime complexity. Opinions?
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [BUG] StGit removed git branch of the same name as StGit branch
From: Karl Hasselström @ 2006-11-21 10:56 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Carl Worth, Jakub Narebski, git
In-Reply-To: <tnx64d9xgex.fsf@arm.com>
On 2006-11-21 10:06:30 +0000, Catalin Marinas wrote:
> I personally don't like mixing StGIT and GIT commands unnecessarily,
> unless there is no other option (like "git log" since "stg log" has
> a different meaning). There are people (including me) who use StGIT
> almost exclusively, without relying on the GIT commands. That's why
> I duplicated some of the GIT commands.
I, on the other hand, tend to freely mix git and stgit commands. For
example, I often commit things with the git emacs modes, but I do all
my merging with stgit.
This is all very straightforward once you learn that stgit just adds a
thin layer of extra metadata on top of git. All the really valuable
information is stored in git; what stgit adds is e.g. convenient names
for patches, and the distinction between commits that are patches and
commits that aren't (so that you won't edit supposedly immutable
history by mistake). To me, stgit is a convenient way to edit git
history, which happens to make patchset maintenance very easy.
However, interoperability could be much better than it is. I think
stgit maintains too much extra metadata on top of what git already
has.
--
Karl Hasselström, kha@treskal.com
^ permalink raw reply
* Re: [BUG] StGit removed git branch of the same name as StGit branch
From: Jakub Narebski @ 2006-11-21 10:48 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <tnx1wnxxfu3.fsf@arm.com>
Catalin Marinas wrote:
> Jakub Narebski <jnareb@gmail.com> wrote:
>> By the way, why "stg branch --delete" doesn't remove reflog? Not that I'm
>> complaining, because it sure saved some work when resurrecting branch, and
>> I didn't loose reflog info.
>
> Reflogs came into GIT after the StGIT branch command and never looked
> at them in detail. And maybe it should not touch the reflog info,
> especially for situations like this, unless GIT has a mechanism for a
> trash bin (StGIT has one for patches - .git/patches/<branch>/trash/ -
> but undocumented)
Well, I'm asking because "git branch -D" deletes also reflog. So I'm
worrying if StGit works with packed refs (although one usually do not
pack branches/heads, only tags).
--
Jakub Narebski
^ permalink raw reply
* Re: [BUG] StGit removed git branch of the same name as StGit branch
From: Catalin Marinas @ 2006-11-21 10:19 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ejuj2a$2ot$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> wrote:
> Catalin Marinas wrote:
>> I've never thought anyone would see a different meaing for the
>> "branch" command. What you wanted to do was the reverse of the "init"
>> command. Maybe something like "uninit" or a "--uninit" option to
>> "branch".
>
> Yes, that is what I wanted. "stg branch --unmanage" or something
> like that.
I'll put it on my to-do list.
> By the way, why "stg branch --delete" doesn't remove reflog? Not that I'm
> complaining, because it sure saved some work when resurrecting branch, and
> I didn't loose reflog info.
Reflogs came into GIT after the StGIT branch command and never looked
at them in detail. And maybe it should not touch the reflog info,
especially for situations like this, unless GIT has a mechanism for a
trash bin (StGIT has one for patches - .git/patches/<branch>/trash/ -
but undocumented)
--
^ permalink raw reply
* Re: [BUG] StGit removed git branch of the same name as StGit branch
From: Jakub Narebski @ 2006-11-21 10:07 UTC (permalink / raw)
To: git
In-Reply-To: <b0943d9e0611210126x493848d9xae006af835fc62c7@mail.gmail.com>
Catalin Marinas wrote:
> On 20/11/06, Jakub Narebski <jnareb@gmail.com> wrote:
>> When removing stg branch (I wanted to remove
>> heads/base/gitweb/web) using "stg branch --delete gitweb/web" it
>> deleted also git branch when I wanted to remove only the StGit managed
>> indicator. Fortunately I was able to recover the branch from reflog, as
>> StGit didn't delete reflog with deletion of git branch.
>>
>> Perhaps that is correct behavior... but certainly unexpected.
>
> I've never thought anyone would see a different meaing for the
> "branch" command. What you wanted to do was the reverse of the "init"
> command. Maybe something like "uninit" or a "--uninit" option to
> "branch".
Yes, that is what I wanted. "stg branch --unmanage" or something like that.
By the way, why "stg branch --delete" doesn't remove reflog? Not that I'm
complaining, because it sure saved some work when resurrecting branch, and
I didn't loose reflog info.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [BUG] StGit removed git branch of the same name as StGit branch
From: Catalin Marinas @ 2006-11-21 10:06 UTC (permalink / raw)
To: Carl Worth; +Cc: Jakub Narebski, git
In-Reply-To: <87y7q5y8s6.wl%cworth@cworth.org>
Carl Worth <cworth@cworth.org> wrote:
> From my inspection, StGit works just fine in its "standalone SCM"
> role, but falls over somewhat if using it as an additional tool
> alongside git itself for a few reasons:
>
> * There's a two-world-view problem with extra commands just to
> translate back and forth (assimilate, commit, uncommit, etc.)
I initially opposed to commands like "uncommit" since people shouldn't
modify the history. I currently see the assimilate/uncommit only as a
way to fix mistakes of committing with GIT when you actually wanted an
StGIT patch. I rarely use these commands.
I use StGIT in maintainer mode as well and the only additional command
is "commit" to permanently store the patches and freeze the history
before pushing the changes to the public repository.
> * The new references that StGit introduces can lead to collisions, (it
> happened to me anyway---I ended up having to rm -r .git/refs/bases
> or whatever just to make the ambiguity go away and let me get work
> done with git again).
I find the refs/bases useful, for example when invoking gitk I can see
where the base of the stack is. You can also use the base in plain
"git" commands.
> So, for use as something separate from git, StGit might be just
> fine. Otherwise, for being just another tool for users of "git" the
> command-line tool, I agree that the current StGit design is a
> mistake.
I personally don't like mixing StGIT and GIT commands unnecessarily,
unless there is no other option (like "git log" since "stg log" has a
different meaning). There are people (including me) who use StGIT
almost exclusively, without relying on the GIT commands. That's why I
duplicated some of the GIT commands.
I don't think there is a problem with StGIT's design but rather a
workflow one (which neither GIT nor StGIT have clearly documented it,
you can see many people writing their own scripts to do the things
they need). For example, I thought "uncommit" only as a way to fix a
mistaken commit but someone posted a bug report that it wasn't
possible to uncommit hundreds of commits and going over merges. This
was not the intended behaviour but you can't force people not to be
inventive :-).
> I'd much prefer to have a minimal set of new "git" sub-commands that
> introduce the new functionality without a separate command namespace
> and several sub-commands with redundant functionality compared to
> existing git sub-commands.
I find the GIT command space to be pretty cramped and without a clear
separation between low-level commands and porcelain ones. Adding even
more functionality for patch management would scare beginners even
more (had the GNU Arch experience where you need a steep learning
curve).
--
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Jakub Narebski @ 2006-11-21 10:04 UTC (permalink / raw)
To: git
In-Reply-To: <20061121062158.GF20736@admingilde.org>
Martin Waitz wrote:
> On Tue, Nov 21, 2006 at 01:42:22AM +0100, Jakub Narebski wrote:
>> Perhaps it would be best to join those two subproject support
>> solutions together: "bind" tree/commit mount header in commit
>> object, and "commit" entry in a tree.
>
> But which is the autoritative source then?
> Does it give any more information?
Both should contain the same information, otherwise repository is corrupt
(is in inconsistent state).
"bind" header in commit objects is meant as a kind of shortcut, to ease
reachability checking (you don't need to recurse into directories).
> The advantage in your proposal would be that submodules would
> be visible immediately when looking at the commit,
> without having to traverse the entire tree.
> This may be worthwhile when showing the combined history of parent
> and submodules.
That was the idea.
> But still this looks like "caching submodule information in the
> commit object" and I do not know if we really want to do that.
Well, we would be repeating information, sure. But we can put additional
information in "bind" header except sha1 of commit and mount point...
although I cannot think what... :)
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [BUG] StGit removed git branch of the same name as StGit branch
From: Catalin Marinas @ 2006-11-21 9:26 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200611202201.45521.jnareb@gmail.com>
On 20/11/06, Jakub Narebski <jnareb@gmail.com> wrote:
> I have used StGit (wonderfull tool) to manage patches on git branch
> gitweb/web. Unfortunately, I have named stg branch the same as git
> branch.
Well, there is no such thing as a stg branch. StGIT shares the branch
structure with GIT and the "branch" command works on the whole GIT
branch, with some additional things for handling the patches. Once a
GIT branch is StGIT-initialised (either by being created with "stg
branch" or by "stg init") it will always remain a StGIT branch and get
a reference in refs/bases/.
> When removing stg branch (I wanted to remove
> heads/base/gitweb/web) using "stg branch --delete gitweb/web" it
> deleted also git branch when I wanted to remove only the StGit managed
> indicator. Fortunately I was able to recover the branch from reflog, as
> StGit didn't delete reflog with deletion of git branch.
>
> Perhaps that is correct behavior... but certainly unexpected.
I've never thought anyone would see a different meaing for the
"branch" command. What you wanted to do was the reverse of the "init"
command. Maybe something like "uninit" or a "--uninit" option to
"branch".
--
^ permalink raw reply
* Re: Feature request: git-pull -e/--edit
From: Johannes Schindelin @ 2006-11-21 9:19 UTC (permalink / raw)
To: Eran Tromer; +Cc: Horst H. von Brand, Junio C Hamano, git
In-Reply-To: <4561FDA9.6060807@tromer.org>
Hi,
On Mon, 20 Nov 2006, Eran Tromer wrote:
> On 2006-11-20 19:09, Horst H. von Brand wrote:
> >>
> >> A------------F master
> >> \ /
> >> B--C--D--E
> >>
> >> Yes, E and F have identical trees.
There has been only _one_ line of history, so why introduce what was not
there?
It sounds more like you do not trust "E" to be something especially
useful, but in that case you should not merge it to begin with.
Ciao,
^ 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