* Re: multi-project repos (was Re: Cleaning up git user-interface warts)
From: Carl Worth @ 2006-11-17 16:51 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Shawn Pearce, Han-Wen Nienhuys, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0611170836120.3349@woody.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 893 bytes --]
On Fri, 17 Nov 2006 08:45:39 -0800 (PST), Linus Torvalds wrote:
> > Although if you have reflog enabled on your current branch there
> > is a 1 character shorter syntax:
> >
> > gitk HEAD@{1}..
>
> Heh. With a finnish keyboard, that "@" is AltGr+'2', and the '{'/'}' is
> AltGr+'7'/'0', I guarantee that it's not "1 character shorter", it's
> "three pretty complicated characters longer" and "off the normal path
> where you hold your fingers on the keyboard ;)
It's not even all that convenient on a U.S. keyboard. My pinky suffers
a bit having to pop on and off of shift for the '{', '1', '}'. Then
again, I don't like having to hold shift down for all of ORIG_HEAD
either, (but it's definitely easier in comparison).
But since reflog does everything ORIG_HEAD does and more, shall we
just clean up the syntax somehow? Ideas anyone? And then fix the
documentation to explain that?
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Alexandre Julliard @ 2006-11-17 16:49 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ejkdhv$vog$2@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Alexandre Julliard wrote:
>
>> Junio C Hamano <junkio@cox.net> writes:
>>
>>> I would rather say "use 'git branch' to make sure if you are
>>> ready to merge". Who teaches not to use "git pull"?
>>
>> We do that for Wine. The problem is that we recommend using git-rebase
>> to make it easier for occasional developers to keep a clean history,
>> and rebase and pull interfere badly.
>
> What about proposed (and I think not accepted) merge strategy
> "rebase" (formerly called "subordinate" or something like that)?
That sounds very interesting. Has it ever been implemented, or only
discussed?
--
Alexandre Julliard
^ permalink raw reply
* Re: multi-project repos (was Re: Cleaning up git user-interface warts)
From: Carl Worth @ 2006-11-17 16:46 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Linus Torvalds, Han-Wen Nienhuys, Junio C Hamano, git
In-Reply-To: <20061117162605.GA32597@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 910 bytes --]
On Fri, 17 Nov 2006 11:26:05 -0500, Shawn Pearce wrote:
> Linus Torvalds <torvalds@osdl.org> wrote:
> > - "ORIG_HEAD" is very useful indeed, and it's the head _before_ a merge
...
> Although if you have reflog enabled on your current branch there
> is a 1 character shorter syntax:
>
> gitk HEAD@{1}..
Yes, this was my exact thought when reading what Linus
wrote. ORIG_HEAD might be fine and all, but it pales in functionality
compared to what reflog provides.
I would very much like to see reflog getting first-class citizen
support in git:
1. Be on by default
2. Get documented in all the right places, (much better than adding
documentation for ORIG_HEAD in my opinion)
3. Tighter integration with branch manipulations. Do we already delete
reflog when deleting a branch? We don't have a branch rename
operation, but if we get one, renaming the reflog should go
hand-in-hand, etc.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: multi-project repos (was Re: Cleaning up git user-interface warts)
From: Linus Torvalds @ 2006-11-17 16:45 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Han-Wen Nienhuys, Junio C Hamano, git
In-Reply-To: <20061117162605.GA32597@spearce.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1391 bytes --]
On Fri, 17 Nov 2006, Shawn Pearce wrote:
>
> Although if you have reflog enabled on your current branch there
> is a 1 character shorter syntax:
>
> gitk HEAD@{1}..
Heh. With a finnish keyboard, that "@" is AltGr+'2', and the '{'/'}' is
AltGr+'7'/'0', I guarantee that it's not "1 character shorter", it's
"three pretty complicated characters longer" and "off the normal path
where you hold your fingers on the keyboard ;)
And that's not even mentioning that '{'/'}' is a magic sequence for
filename expansion to the shell, so every time I see that, I have to think
about it (and it turns out that because there is no comma in between
there, it's ok. Otherwise you would need to quote it or escape them...)
So the reflog syntax is fine, but it's definitely not a "simple" syntax.
I'd only use it for things where I want something that ORIG_HEAD won't
give me ("ORIG_HEAD" you can type by just holding the shift key down all
the time, and letting your fingers dance over the keyboard, both on a US
and a Finnish keyboard).
And yes, I actually use a Finnish keyboard, still. Don't ask me why. I
don't actually need the åäö characters often enough for it to matter, and
I have used US keyboards elsewhere enough that I can switch between the
two without thinking, but I still ended up having my sister ship me a
keyboard from Finland when I wanted to upgrade..
Linus
^ permalink raw reply
* Re: [DRAFT] Branching and merging with git
From: Sean @ 2006-11-17 16:34 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git, Petr Baudis
In-Reply-To: <fcaeb9bf0611170819j57cda9e1ia4ecd4cd13956447@mail.gmail.com>
On Fri, 17 Nov 2006 23:19:23 +0700
"Nguyen Thai Ngoc Duy" <pclouds@gmail.com> wrote:
> Or.. find a way to merge cogito back to git :-)
> /me runs into a nearest bush.
Pasky has already given a lot to Git, and it would be great to see even
more merged back into Git where a consensus can be reached. In fact
Pasky has said that his plan is to push a lot more towards Git and
make Cogito a thinner UI layer. Either way, there's absolutely nothing
wrong with people choosing to use Cogito rather than Git. It's just
that the separate Cogito tool shouldn't have a place on the Git website
any more prominent than say StGit does.
The Git website should be a place where Git makes the best case
it can for _itself_, not for its sister tools. It's a distraction
and gets in the way of promoting Git as a stand alone tool. At
least one new user has complained that it was confusing.
Personally I have nothing against Cogito, I just think Pasky should
separate his role as Git webmaster from his role as Cogito author.
If people have good ideas for Git documentation, the website would be
a natural place for it, and it shouldn't have to compete with Cogito
tutorials etc.
^ permalink raw reply
* Re: [DRAFT] Branching and merging with git
From: Petr Baudis @ 2006-11-17 16:33 UTC (permalink / raw)
To: Marko Macek; +Cc: Nguyen Thai Ngoc Duy, git
In-Reply-To: <455DE275.8020000@gmx.net>
On Fri, Nov 17, 2006 at 05:25:25PM CET, Marko Macek wrote:
> Nguyen Thai Ngoc Duy wrote:
> >On 11/17/06, Sean <seanlkml@sympatico.ca> wrote:
> >>It would be nice to post this information on the Git website and not
> >>have it overshadowed by Cogito examples with paragraphs explaining how
> >>Cogito makes things easier. The current website distracts users away
> >>from learning Git or ever reading about this kind of information.
> >>Maybe we can pass a hat around for some funds for a separate Cogito
> >>website. ;o)
> >
> >Or.. find a way to merge cogito back to git :-)
> >/me runs into a nearest bush.
I think we are trying to figure that out in the last few days in those
mammoth threads. UI-wise with no big breakthroughs so far I guess,
though.
> The alternative would be to explain that git is a low level tool suitable
> mostly for integrators like Linus (that, and that Cogito and/or StGit
> should be used by developers/contributors).
This is in essence what many people (including Junio) are saying. I'm
not saying it's a totally great situation, hence the previous paragraph.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply
* Re: [DRAFT] Branching and merging with git
From: Marko Macek @ 2006-11-17 16:25 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git, Petr Baudis
In-Reply-To: <fcaeb9bf0611170819j57cda9e1ia4ecd4cd13956447@mail.gmail.com>
Nguyen Thai Ngoc Duy wrote:
> On 11/17/06, Sean <seanlkml@sympatico.ca> wrote:
>> It would be nice to post this information on the Git website and not
>> have it overshadowed by Cogito examples with paragraphs explaining how
>> Cogito makes things easier. The current website distracts users away
>> from learning Git or ever reading about this kind of information.
>> Maybe we can pass a hat around for some funds for a separate Cogito
>> website. ;o)
>
> Or.. find a way to merge cogito back to git :-)
> /me runs into a nearest bush.
I agree, this would certainly be the best solution. But it would imply
hiding the 'index' by default which would probably an incompatible change.
The alternative would be to explain that git is a low level tool suitable
mostly for integrators like Linus (that, and that Cogito and/or StGit should
be used by developers/contributors).
^ permalink raw reply
* Re: multi-project repos (was Re: Cleaning up git user-interface warts)
From: Shawn Pearce @ 2006-11-17 16:26 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Han-Wen Nienhuys, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0611161039160.3349@woody.osdl.org>
Linus Torvalds <torvalds@osdl.org> wrote:
> - "ORIG_HEAD" is very useful indeed, and it's the head _before_ a merge
> (or some other operations, like "git rebase" and "git reset": think of
> it as a "original head before we did some uncontrolled operation
> where we otherwise can't use HEAD^ or similar")
>
> I use "gitk ORIG_HEAD.." a lot, and if I don't like something I see
> when I do it, I end up doing "git reset --hard ORIG_HEAD" to undo a
> pull I've done. This is important exactly because ORIG_HEAD is _not_
> the same as the first parent of a merge, since a merge could have been
> just a fast-forward.
Although if you have reflog enabled on your current branch there
is a 1 character shorter syntax:
gitk HEAD@{1}..
as recent Git understands that to mean the value that HEAD just had,
which is also what is in ORIG_HEAD. Except that unlike ORIG_HEAD
it can also show even older values (e.g. HEAD@{3}, 3 ops back)
and it works very, very well on tracking branches. "What did I
just fetch in next?" `git log next@{1}..next`
--
^ permalink raw reply
* Re: [DRAFT] Branching and merging with git
From: Nguyen Thai Ngoc Duy @ 2006-11-17 16:19 UTC (permalink / raw)
To: Sean; +Cc: git, Petr Baudis
In-Reply-To: <BAYC1-PASMTP07C8A8D8E5E78173953CA9AEE80@CEZ.ICE>
On 11/17/06, Sean <seanlkml@sympatico.ca> wrote:
> It would be nice to post this information on the Git website and not
> have it overshadowed by Cogito examples with paragraphs explaining how
> Cogito makes things easier. The current website distracts users away
> from learning Git or ever reading about this kind of information.
> Maybe we can pass a hat around for some funds for a separate Cogito
> website. ;o)
Or.. find a way to merge cogito back to git :-)
/me runs into a nearest bush.
--
^ permalink raw reply
* Re: [DRAFT] Branching and merging with git
From: Sean @ 2006-11-17 15:57 UTC (permalink / raw)
To: Theodore Tso; +Cc: linux, git, Petr Baudis
In-Reply-To: <20061117153246.GA20065@thunk.org>
On Fri, 17 Nov 2006 10:32:46 -0500
Theodore Tso <tytso@mit.edu> wrote:
> It would be nice if there was an easy way to direct users through the
> documentation in a way which makes good pedagogical sense. Right now,
> one of the reasons why life gets hard for new users is that the
> current tutorials aren't enough for them to really undersatnd what's
> going on at a conceptual level. And if users start using "everyday
> git" as a crutch, without the right background concepts, the human
> brain naturally tries to intuit what's happening in the background,
> but without reading the background docs, git is different enough that
> they will probably get it wrong, which means more stuff that they have
> to unlearn later.
It would be nice to post this information on the Git website and not
have it overshadowed by Cogito examples with paragraphs explaining how
Cogito makes things easier. The current website distracts users away
from learning Git or ever reading about this kind of information.
Maybe we can pass a hat around for some funds for a separate Cogito
website. ;o)
> Maybe we should change git so that a "Fetch: " line in the remotes
> file works the same way as "Pull: ", and then recommend that people
> use "Fetch: " in order to reduce confusion, as opposed to simply
> explaining it away as "yet another example of the histororical
> fetch/pull confusion"?
That's quite a good idea. The name was fixed when the option to move
this info into the config file was added (remote.<name>.fetch). So
another option would be to show new users the config file method and
just damn the remotes file to a historical footnote.
^ permalink raw reply
* Re: [PATCH] git-checkout: allow pathspec to recover lost working tree directory
From: Petr Baudis @ 2006-11-17 15:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbqn8msuw.fsf@assigned-by-dhcp.cox.net>
On Wed, Nov 15, 2006 at 08:07:19PM CET, Junio C Hamano wrote:
> diff --git a/git-checkout.sh b/git-checkout.sh
> index eb28b29..737abd0 100755
> --- a/git-checkout.sh
> +++ b/git-checkout.sh
> @@ -112,7 +112,11 @@ Did you intend to checkout '$@' which ca
> git-ls-tree --full-name -r "$new" "$@" |
> git-update-index --index-info || exit $?
> fi
> - git-checkout-index -f -u -- "$@"
> +
> + # Make sure the request is about existing paths.
> + git-ls-files --error-unmatch -- "$@" >/dev/null || exit
> + git-ls-files -- "$@" |
> + git-checkout-index -f -u --stdin
> exit $?
> else
> # Make sure we did not fall back on $arg^{tree} codepath
Wouldn't it be better to fix git-checkout-index to checkout a whole
directory if specified?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply
* Re: [DRAFT] Branching and merging with git
From: Theodore Tso @ 2006-11-17 15:32 UTC (permalink / raw)
To: linux; +Cc: git
In-Reply-To: <20061116221701.4499.qmail@science.horizon.com>
On Thu, Nov 16, 2006 at 05:17:01PM -0500, linux@horizon.com wrote:
> I know it took me a while to get used to playing with branches, and I
> still get nervous when doing something creative. So I've been trying
> to get more comfortable, and wrote the following to document what I've
> learned.
>
> It's a first draft - I just finished writing it, so there are probably
> some glaring errors - but I thought it might be of interest anyway.
This is really, really good stuff that you've written! Have you any
thoughts or suggestions about where this text should end up?
Personally, I think this information is actually more important to an
end-user than the current "part two" of the tutorial, which discusses
the object database and the index file. Perhaps this should be "part
2", and the object database and index file should become "part 3"?
It might also be a good to consider moving some of the "discussion"
portion the top-level git(7) man page into the object database and
index file discussion. Right now, the best way to introduce git's
concepts (IMHO), is to start with the part 1 of the tutorial, then go
into the your draft branch/merging with git, then the current part 2
of the tutorial, and then direct folks to read the "discussion"
section of git(7). Only then do they really have enough background
understanding of the fundamental concepts of git that they won't get
confused when they start talking to other git users, on the git
mailing list, for example.
It would be nice if there was an easy way to direct users through the
documentation in a way which makes good pedagogical sense. Right now,
one of the reasons why life gets hard for new users is that the
current tutorials aren't enough for them to really undersatnd what's
going on at a conceptual level. And if users start using "everyday
git" as a crutch, without the right background concepts, the human
brain naturally tries to intuit what's happening in the background,
but without reading the background docs, git is different enough that
they will probably get it wrong, which means more stuff that they have
to unlearn later.
> * Git's representation of history
>
> As you recall from Git 101, there are exactly four kinds of objects in
> Git's object database. All of them have globally unique 40-character hex
> names made by hashing their type and contents. Blob objects record file
> contents; they contain bytes. Tree objects record directory contents;
> they contain file names, permissions, and the associated tree or blob
> object names. Tag objects are shareable pointers to other objects;
> they're generally used to store a digital signature.
Hmm... this assumes that you've read the Git(7) discussion first.
There is enough information here though that maybe you don't need to
say "as you recall". It might be enough to give a quick summary of
the concepts that are needed to understand the rest of your tutorial,
and then point to git(7) Discussion section for people who need to
learn more details.
> * Remotes files
>
> Note that branches to fetch are identified by "Pull: " lines in the
> remotes file. This is another example of the fetch/pull confusion.
> git-pull will be explained eventually.
Maybe we should change git so that a "Fetch: " line in the remotes
file works the same way as "Pull: ", and then recommend that people
use "Fetch: " in order to reduce confusion, as opposed to simply
explaining it away as "yet another example of the histororical
fetch/pull confusion"?
Thanks,
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Jakub Narebski @ 2006-11-17 13:45 UTC (permalink / raw)
To: git
In-Reply-To: <7v1wo3d6g4.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Marko Macek <marko.macek@gmx.net> writes:
>
>>>> BTW, currently there's a minor bug: git-diff HEAD doesn't work before
>>>> you make the first commit. Perhaps this should be special cased.
>>>
>>> That's only a _bug_ in your implementation of the synonym for
>>> "svn diff" which blindly used "git diff HEAD".
>>
>> My "implementation" is taken from git-diff man page. It seems obvious
>> that the situation before the first commit is just a special case if
>> we consider git-diff to be Porcelain (which I do).
>
> Yes, "git diff" is a Porcelain. No question about it.
>
> I do not consider the current behaviour of "git diff HEAD" that
> complains instead of giving runs of "foo is a new file and no
> diff is available for it" a bug; you asked for diff from some
> commit but the commit you gave was bogus (does not exist yet).
git diff --root HEAD, perhaps?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Jakub Narebski @ 2006-11-17 13:32 UTC (permalink / raw)
To: git
In-Reply-To: <8764dflj5o.fsf@wine.dyndns.org>
Alexandre Julliard wrote:
> Junio C Hamano <junkio@cox.net> writes:
>
>> I would rather say "use 'git branch' to make sure if you are
>> ready to merge". Who teaches not to use "git pull"?
>
> We do that for Wine. The problem is that we recommend using git-rebase
> to make it easier for occasional developers to keep a clean history,
> and rebase and pull interfere badly.
What about proposed (and I think not accepted) merge strategy
"rebase" (formerly called "subordinate" or something like that)?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Jakub Narebski @ 2006-11-17 13:25 UTC (permalink / raw)
To: git
In-Reply-To: <455C618A.7080309@xs4all.nl>
Han-Wen Nienhuys wrote:
> As another example: annoyances regarding program invocation
>
> - option handling: -x -f -z != -xfz , "--max-count 1" doesn't work,
> but needs an '='
That's true, and the probable cause is that git tries to first, avoid
dependency on options parsers like getopt/getopt_long/argp or popt for
commands in C, getopt for commands in shell, Getopt::Std/Getopt::Long for
commands in Perl, and something for commands in Python (if there are any
left); second, existing options parsers do not deal (I think) with
distinction between arguments to wrapper and arguments to command, '--' to
separate revisions from pathnames not options from arguments, and the whole
revisions and revision list specifying syntax (where "a --not b" is not
equivalent to "--not a b").
That said, perhaps we should craft our own options parsing (or modify
existing one)...
> - git --help lists an unordered set, which is too long scan quickly.
It is one page of alphabetically ordered commands.
git(7) gives whole list of commands, divided into categories, by the way.
> I'd expect that list to either contain everything or the minimum set for
> daily use. I.e. the set introduced in a first tutorial. Why are merge,
> prune, verify-tag there?
>
> Try "bzr help" for comparison.
I wonder why "repack" isn't there, if "prune" is.
> - --pretty option with wholly uninformative options full, medium,
> short, raw. It's not even documented what each option does.
And 'oneline' and undocumented 'email'. True, git lacks documentation (and
this one of main complaints in git survey).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: multi-project repos (was Re: Cleaning up git user-interface warts)
From: Jakub Narebski @ 2006-11-17 12:53 UTC (permalink / raw)
To: git
In-Reply-To: <455CF517.9000101@xs4all.nl>
Han-Wen Nienhuys wrote:
> Linus Torvalds escreveu:
>>> If I then do
>>>
>>> git --bare fetch git://git.sv.gnu.org/lilypond.git web/master:master
>>>
>>> it downloads the same stuff again.
>>
>> Right. So you can either
>> [..]
>> See?
>
> No, I don't understand. In the fetch all the objects with their SHA1s
> were already downloaded. I'd expect that the fetch with a refspec
> would simply write a HEAD and a refs/heads/master, and notice that all
> the actual data was already downloaded, and doesn't download it again.
But how git is to know that you have this already downloaded? Git compares
_refs_ on the local and remote side to calculate what needs to be
downloaded. It does not (and should not) send all the objects IDs local
side has.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Jakub Narebski @ 2006-11-17 12:25 UTC (permalink / raw)
To: git
In-Reply-To: <f2b55d220611162242s48dc42d6g4cbfd9173e712ff8@mail.gmail.com>
Michael K. Edwards wrote:
> Currently, it looks like "remotes" entries are
> created only by "git clone" or by hand. Junio, are there any plans to
> manage the contents of "remotes" through the tool instead of by hand?
Don't forget quite new work with managing remotes (and per-branch
configuration) in the config instead of separate remotes/ (or even older
branches/) file
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Karl Hasselström @ 2006-11-17 12:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, git
In-Reply-To: <7vac2sjs28.fsf@assigned-by-dhcp.cox.net>
On 2006-11-15 13:52:47 -0800, Junio C Hamano wrote:
> That means that updated "git merge" (not the current one) would not
> be able to assume it's parameter is a branch name, and still has to
> come up with the merge message "Merge <branch>".
Often, it would be a branch or a tag, so no problem there. For commits
in general, it should not be hard to compute the set of branches and
tags the commit is part of, and in the (probably) common case where
this set has exactly one element, the problem is solved. For the
remaining cases, it should not be too horrible to ask the user to
describe what is being merged.
--
Karl Hasselström, kha@treskal.com
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Junio C Hamano @ 2006-11-17 11:41 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Carl Worth, Michael K. Edwards, git
In-Reply-To: <Pine.LNX.4.63.0611171103150.13772@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> 5. Adding something like git-fetch --all to allow it to pick up all new
>> branches
>
> IIRC this idea was rejected, but I would find it useful. Especially with
> what Han-Wen said: you can store the branches you fetch with "git fetch
> --all <nick>" under .git/refs/remotes/<nick>/<branchname>.
With separate-remote layout, this can be done without risk of
tracking refname clashing with local refname, which was the
primary reason for an earlier reluctance.
While separate-remote layout also solves Carl's "do not want to
track tracking branches remote has" problem, local branch
namespace can have both for-others (not necessarily "public" but
could be "for colleagues") and throwaway branches, so --all is
probably not the right thing to do in most cases. But I am Ok
with the approach of seeing how well it works out in practice by
doing the simplest "--all" and giving options to restrict it
later.
^ permalink raw reply
* Re: [PATCH 4/5] allow deepening of a shallow repository
From: Junio C Hamano @ 2006-11-17 11:35 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0611171050440.13772@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> Although I am reasonably sure we can eventually make it work, it
>> is very subtle and fragile -- somebody touching this code can
>> easily break it.
>
> I fully agree. Even the OA did not understand the code fully ;-)
>
> How about adding "int force_reparse" to the signature of
> unregister_shallow()? (Just like we added "int cleanup" to
> get_merge_bases() to avoid pilot errors.)
I do not think that's where its fragility lies. It is that any
random place can later call parse_object() on the commit, after
you elaborately pre-parsed it with shallow so that it appears to
have fewer parents, with the expectation that nobody ever would
clear the parsed bit and cause it to be reparsed again. With
that assumption, find_common() manipulated the shallow entry
after setting that scheme up. A mechanism to prevent the commit
from getting re-parsed would have made it more robust.
^ permalink raw reply
* Re: [PATCH] gitweb: Atom feeds
From: Jakub Narebski @ 2006-11-17 11:36 UTC (permalink / raw)
To: Junio C Hamano, Andreas Fuchs; +Cc: git, Petr Baudis
In-Reply-To: <7v4psysazy.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Andreas Fuchs <asf@boinkor.net> writes:
>
>> Jakub Narebski wrote:
>>> Andreas Fuchs <asf@boinkor.net> wrote:
>>>
>>>> * Wrap the commit message in <pre>
>>> We use <div class="pre"> in "commit" view if I remember correctly.
>>
>> That's ok for rendered HTML output, but in my experience, the way feed
>> readers interpret that ranges from "badly" to "not at all"; it's better
>> to stick to explicit structure hints only in feeds. /-:
True. "<pre>" in RSS feed is better (I don't know if you can give CSS
for RSS, be it RSS 2.01 or Atom; rather not).
>> So, this is the only thing I haven't fixed in the attached patch (:
Good.
>> In addition to the above points, the attached patch emits a
>> Last-Changed: HTTP response header field, and doesn't compute the feed
>> body if the HTTP request type was HEAD. This helps keep the web server
>> load down for well-behaved feed readers that check if the feed needs
>> updating.
Very nice.
>> Hope you like it,
>
> Seems sane to me. Jakub, how do you like this one?
I like it. Ack.
> If it looks Ok to you, please arrange to include your one-liner
> that this depends on and forward a readily applicable patch with
> appropriate commit log message.
Which one liner? As far as I can see the patch does NOT use
href(-full=>1,...) but esc_url(...).
Perhaps this is for next patch.
BTW I have encountered something calles Atom Publishing Protocol (APP):
perhaps we should also add this in addition to currently used OPML.
--
Jakub Narebski
Torun, Poland
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Junio C Hamano @ 2006-11-17 11:29 UTC (permalink / raw)
To: Carl Worth; +Cc: Michael K. Edwards, git
In-Reply-To: <87ejs2qvmb.wl%cworth@cworth.org>
Carl Worth <cworth@cworth.org> writes:
> What I have been doing up to this point is a little script I wrote
> that does git-ls-remote on the repository I want to track and writes a
> .git/remotes file to bring in all their branches. So if I want to see
> what behdad is up to, I first refresh his .git/remotes file with my:
>
> cairo-git-setup-remotes behdad
> then:
> git fetch behdad
>
> And I end up with a bunch of branch names with "behdad-" prefixes that
> I can explore or blow away if I'm no longer interested, (could have
> used a "behdad/" prefix as well).
I would suggest refs/remotes/behdad.
> So, yes, I'll definitely look into improving this. I think the details
> will involve:
>
> 1. Making clone do the --use-separate-remotes behavior by default
>
> 2. Taking advantage of that consistently for all branches instead of a
> special master:origin mapping in clone
This already should be the case if you use separate-remote. I
haven't run "clone --separate-remote" myself for a long time,
but the design was certainly to make it behave that way.
Specifically, map everything in refs/heads/ at remote to
refs/remotes/$origin/ with corresponding names, one-to-one.
I do not see much reason to change the mapping of master:origin
which is done for the traditional layout. The traditional
layout is not suitable for your workflow anyway, and that is why
you prefer separate-remote layout for your project, and I fully
agree it would suit you better.
> 3. Enhancing git-fetch (or other) to modify .git/remotes, (or was
> there a desire for some other branch-specific section in the config
> file?)
>
> 4. Making git-fetch handle the disappearance of a remote branch
> gracefully
>
> 5. Adding something like git-fetch --all to allow it to pick up all new
> branches
These three are easily done for separate-remote layout but at
that point you would not want --all but more powerful --mirror
(or --update if you want to use that word), which goes the whole
nine yards of noticing disappearance of remote branch, making
matching deletion of local tracking branch, updating
.git/remotes, etc. I've muttered something similar in a nearby
thread; see below.
> 6. Adding a "git update" that does a fetch for all appropriately
> marked remotes.
>
> On this last point, maybe we do something like:
>
> update=no|yes|all
>
> in .git/remotes. Then git-clone would set this up with update=all for
> origin so git-update would do a "fetch --all" on the origin
> repository. Then step 3 above would have to provide for setting this
> update option as appropriate.
I would prefer this to be kept in contrib/; it feels like it is
filling rather very narrow need.
> Anyway, something along those lines perhaps. Any feedback?
I muttered something less elaborate in the nearby thread.
Message-ID: <7vr6w78b4x.fsf@assigned-by-dhcp.cox.net>
Message-ID: <7v64dev88t.fsf@assigned-by-dhcp.cox.net>
The part that deals with manual configuration (the last point in
the first message, and the second in message its entirety) is
something your workflow would not need nor want to worry about,
but I think it is necessary for different ref namespace layouts
and different workflows. I think the automatable part (the
first two points in the "sensible thing to do" list in the first
message) is very relevant to what you talked about in your
message.
^ permalink raw reply
* Re: [DRAFT] Branching and merging with git
From: Jakub Narebski @ 2006-11-17 10:37 UTC (permalink / raw)
To: git
In-Reply-To: <20061116221701.4499.qmail@science.horizon.com>
linux@horizon.com wrote:
> * Remotes files
>
> You can specify what to fetch on the git-fetch command line. However,
> if you intend to monitor another repository on an ongoing basis,
> it's generally easier to set up a short-cut by placing the options in
> .git/remotes/<name>.
You can also set up this in config file (remote and branch sections),
in modern git.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Is there a way to trim old SHAs from a git tree (so it's not so large)?
From: Thomas Kolejka @ 2006-11-17 10:36 UTC (permalink / raw)
To: Timur Tabi; +Cc: git
In-Reply-To: <455B90AD.3060707@freescale.com>
-------- Original-Nachricht --------
Datum: Wed, 15 Nov 2006 16:11:57 -0600
Von: Timur Tabi <timur@freescale.com>
An: git@vger.kernel.org
Betreff: Is there a way to trim old SHAs from a git tree (so it\'s not so large)?
> After doing a "make mrproper" in my Linux git tree, the result is still
> 1.1GB
> of files. Compare that with just the tarball, which is just one-forth the
> size.
>
> Is there a way to "trim away" old commits from the repository, so that it
> just
> doesn't take up that much space? I don't care about any commits made in
> 2005.
> As long as I can still do "git pull" from the source repo to update
> mine,
> that's good enough.
>
> --
> Timur Tabi
> Linux Kernel Developer @ Freescale
Is it possible to do this with shallow clone?
Shallow clone the local repository my.git (which should be trimmed) starting from the last needed commit to a new local repository my_trimmed.git. And then remove my.git (with something like rm -rf my.git) and rename my_trimmed.git to my.git?
Thomas
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Johannes Schindelin @ 2006-11-17 10:11 UTC (permalink / raw)
To: Carl Worth; +Cc: Junio C Hamano, Michael K. Edwards, git
In-Reply-To: <87ejs2qvmb.wl%cworth@cworth.org>
Hi,
On Fri, 17 Nov 2006, Carl Worth wrote:
> 1. Making clone do the --use-separate-remotes behavior by default
Fully agree.
> 2. Taking advantage of that consistently for all branches instead of a
> special master:origin mapping in clone
Fully agree, too.
> 3. Enhancing git-fetch (or other) to modify .git/remotes, (or was
> there a desire for some other branch-specific section in the config
> file?)
I introduced the remote.<nick>.{url,fetch,push} entries into the config
with the goal to enhance -fetch to remember the current command line with
a setting. I was the only one to find that useful.
BTW I still would argue that it is better to write the remote information
into the config, because you have a saner way to manipulate that from
scripts than .git/remotes/<nick>.
> 4. Making git-fetch handle the disappearance of a remote branch
> gracefully
I think a message like "This remote branch no longer exists. Maybe you
want to use 'git branch -d <branch>' to remove it locally?" should
suffice.
> 5. Adding something like git-fetch --all to allow it to pick up all new
> branches
IIRC this idea was rejected, but I would find it useful. Especially with
what Han-Wen said: you can store the branches you fetch with "git fetch
--all <nick>" under .git/refs/remotes/<nick>/<branchname>.
> 6. Adding a "git update" that does a fetch for all appropriately
> marked remotes.
>
> On this last point, maybe we do something like:
>
> update=no|yes|all
>
> in .git/remotes. Then git-clone would set this up with update=all for
> origin so git-update would do a "fetch --all" on the origin
> repository. Then step 3 above would have to provide for setting this
> update option as appropriate.
First thought was: it is only useful if you want to track multiple
repositories. But next thought: if you mark the correct remotes in every
of your local repositories, you don't have to remember which nick your
upstream has. Yeah, I like it. But maybe do it as "git fetch --update" to
avoid more cluttering of the bindir?
Ciao,
Dscho
^ 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