* Re: [PATCH 2/1] gitweb: Use fixed string for "next" link in commitdiff view
From: Petr Baudis @ 2006-10-24 11:49 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git
In-Reply-To: <200610240008.08325.jnareb@gmail.com>
Dear diary, on Tue, Oct 24, 2006 at 12:08:08AM CEST, I got a letter
where Jakub Narebski <jnareb@gmail.com> said that...
> Use fixed string instead of shortened SHA1 identifier of commit
> as a name for "mext" link in commitdiff view.
>
> Signed-off-by: Jakub Narebski <jnareb@gmail.com>
So I've read what the patch actually does this time, and I really
dislike it.
> Junio C Hamano wrote:
> > Jakub Narebski <jnareb@gmail.com> writes:
> >
> >> Add a kind of "next" link in the bottom part of navigation bar for
> >> "commitdiff" view.
> >>
> >> For commitdiff between two commits:
> >> (from: _commit_)
> >> For commitdiff for one single parent commit:
> >> (parent: _commit_)
> >> For commitdiff for one merge commit
> >> (merge: _commit_ _commit_ ...)
> >> For commitdiff for root (parentless) commit
> >> (initial)
> >> where _link_ denotes hyperlink. SHA1 is shortened to 7 characters on
> >> display, everything is perhaps unnecessary esc_html on display.
> >
> > I always hated gitweb diffs that prefix each filepair with their
> > full 40-byte SHA-1 blob object names. It just adds noise to the
> > output without adding any meaningful information.
I agree, using the shortened SHA1 would be definitely an improvement
here, but
> > Would it even be necessary to use any SHA-1 name in these cases,
> > I wonder. Would it make the page less useful if we replace all
> > of the above _commit_ with a fixed string, say, "parent"?
I really disagree here - what's the point of not using SHA-1? The extra
string carries zero information in comparison with the previous state
and I just can't see how it *improves* stuff. If you're walking in a
maze and making marks on walls, it's still more useful if you have
corridors named by "A", "B", "C", "D" on junctions if you sometimes want
to walk back to the marked corridors.
--
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
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: [PATCH] Make git-branch a builtin
From: Petr Baudis @ 2006-10-24 11:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn Pearce, git
In-Reply-To: <7vy7r6qkmg.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Tue, Oct 24, 2006 at 08:43:35AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Shawn Pearce <spearce@spearce.org> writes:
>
> >> > Wouldn't it make more sense to just include the full SHA1 of the
> >> > file we are deleting rather than the entire 131 line negative diff?
> >>
> >> How would you do "git apply -R" on something like that?
> >
> > Uh, you have the full SHA1 in the index line. So you just have to
> > reattach that blob to the named path... pretty simple actually.
>
> Bzzzt; wrong answer.
>
> Think of a future when you can shallowly clone near the tip of
> git repository that does not have shell-script git-branch.sh
> anymore. You cannot expect to already have the preimage of the
> patch in such a case. You would still want to be able to revert
> the change with "git apply -R".
Hmm, how is this argument not applying to binary diffs you can't revert
either?
--
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
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: [PATCH] Fix bad usage of mkpath in builtin-branch.sh
From: Petr Baudis @ 2006-10-24 11:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Lars Hjemli, git
In-Reply-To: <7vlkn6qkh2.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Tue, Oct 24, 2006 at 08:46:49AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Lars Hjemli <hjemli@gmail.com> writes:
>
> > When checking if a branch start point referred to a commit-object,
> > the result of mkpath() was used as argument to get_sha1(), which
> > didn't work out as planned.
> >
> > Now it's xstrdup'd first.
> >
> > Signed-off-by: Lars Hjemli <hjemli@gmail.com>
> > ---
> > builtin-branch.c | 5 ++++-
> > 1 files changed, 4 insertions(+), 1 deletions(-)
> >
> > diff --git a/builtin-branch.c b/builtin-branch.c
> > index ffc2db0..f86bf68 100755
>
> I've already fixed up this perm-mode breakage (and other
> breakages, possibly) so when I am done with these patches
> tonight please resync with me.
I have made my fair share of inadverent mode changes as well (I don't
even know how that *happenned*), and I don't seem to be alone; since
this is something you are doing only rarely anyway, perhaps we should
try to make mode changes more visible?
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: FILE MODE HAS CHANGED!!!!111 pERHAPS A MISTAKE? @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
;-))
--
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
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: [PATCH] gitweb: Show project's README.html if available
From: Petr Baudis @ 2006-10-24 11:30 UTC (permalink / raw)
To: Luben Tuikov; +Cc: Junio C Hamano, git
In-Reply-To: <350280.74860.qm@web31804.mail.mud.yahoo.com>
Dear diary, on Tue, Oct 24, 2006 at 10:43:08AM CEST, I got a letter
where Luben Tuikov <ltuikov@yahoo.com> said that...
> --- Petr Baudis <pasky@suse.cz> wrote:
> > If the repository includes a README.html file, show it in the summary page.
> > The usual "this should be in the config file" argument does not apply here
> > since this can be larger and having such a big string in the config file
> > would be impractical.
> >
> > I don't know if this is suitable upstream, but it's one of the repo.or.cz
> > custom modifications that I've thought could be interesting for others
> > as well.
> >
> > Compared to the previous patch, this adds the '.html' extension to the
> > filename, so that it's clear it is, well, HTML.
> >
> > Signed-off-by: Petr Baudis <pasky@suse.cz>
> > ---
>
> Why not instead re-submit a patch implementing what was discussed
> in this thread bearing the same name:
>
> http://marc.theaimsgroup.com/?t=116044914900001&r=1&w=2
This implements
http://marc.theaimsgroup.com/?l=git&m=116047939517299&w=2
I see no other ideas I could take there except various naming proposals
and perhaps using File::Copy but I'll wait until someone does a
gitweb-wide change for the latter.
I don't really care _what_ name it bears, but I'd like to have it
included. :-)
--
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
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: [PATCH] gitweb: Make search type a popup menu
From: Petr Baudis @ 2006-10-24 11:27 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ehkfis$6da$1@sea.gmane.org>
Dear diary, on Tue, Oct 24, 2006 at 09:33:12AM CEST, I got a letter
where Jakub Narebski <jnareb@gmail.com> said that...
> Petr Baudis wrote:
>
> > This makes the multiple search types actually usable by the user;
> > if you don't read the gitweb source, you don't even have an idea
> > that you can write things like that there.
>
> This is I think good change, although I'm not sure if I like changing
> using search operators to using additional CGI parameter.
>
> Having help page for search is _certainly_ very good change. Perhaps
> we should put it out-of-line, not embedded? Just a thought...
You mean out-of-file? I've pondered it but I think this is simpler than
having yet another external file with yet another configuration option,
and the help file is not anyway likely something you will want to
customize per-site.
> This patch changes search box into something similar to Google
> "Advanced Search". Yet Google "Advanced Search" box generates search
> query using search operators. Search operators are just more powerfull.
> I know that gitweb doesn't use this power now (it uses only one operator,
> first if I remember correctly), but we can do this in the future
> (e.g. searching for both author and specified string in commit message,
> or searching for given author OR given committer). Well, we can always
> change it back...
Well, yes, that's something we can do when we actually implement the
operators, but I think doing it this way is less powerful, but much more
*useful* since users not familiar with gitweb will have an actual idea
on how to use it, and gitweb is something that will have 90% of users
not familiar with it. So perhaps have an "extended" search type which
will accept the keywords?
--
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
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: Pushing vs. alternates
From: Petr Baudis @ 2006-10-24 11:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmz7muvqu.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Tue, Oct 24, 2006 at 07:29:45AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Petr Baudis <pasky@ucw.cz> writes:
>
> > I don't have time to code that myself right now, so I'm just tossing
> > an idea around - pushing to a directory with alternates set up should
> > avoid sending objects that are already in the alternate object database.
>
> That is probably only relevant for the first time, since
> subsequent pushes have refs from its own repository that tracks
> the tips of branches that was pushed for the last time.
Well, I would send haves for the alternate repository anyway, since: you
push your kernel branch, half a year passes, you merge with new
development and want to push again; you really do not want to push
everything that happenned over the last half a year. And sending the
extra haves shouldn't hurt, right?
> And first time usage when you are initializing the repository
> with alternates, you have direct access to that repository
> (that's how you can set up alternates), you can as easily do the
> initial fetch/clone as well at that time.
I don't understand this paragraph. This mail is about pushing, not
fetch/clone. You can only push if your login access is reduced to
git-shell, and something external could've set up your alternates.
--
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
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-24 10:27 UTC (permalink / raw)
To: git; +Cc: bazaar-ng
In-Reply-To: <vpq64eakpnh.fsf@ecrins.imag.fr>
Matthieu Moy wrote:
> "Matthew D. Fuller" <fullermd@over-yonder.net> writes:
>
>>> For example, how long does it take to do an arbitrary "undo" (ie
>>> forcing a branch to an earlier state) [...]
>>
>> I don't understand the thrust of this, either. As I understand the
>> operation you're talking about, it doesn't have anything to do with a
>> branch; you'd just be whipping the working tree around to different
>> versions. That should be O(diff) on any modern VCS.
> There are two things to do:
>
> * Mark the tree as corresponding to a different revision in the past.
[...]
> * Then, do the "merge" to make your tree up to date. You can hardly do
> faster than git and its unpacked format, but this is at the cost of
> disk space. But as you say, in almost any modern VCS, that's
> O(diff). In a space-efficient format, that's just the tradeoff you
> make between full copies of a file and delta-compression.
Actually, this would be "checkout" (in git terminology), i.e. overwriting
the files which differ in current revision, and the revision we rewind (do
undo) to. (That's of course simplification omitting for example removing
and creating files.) Which would be O(changed files) which is lower bound
and cannot be faster. Finding which files changed is also O(changed files),
with a little bit of O(directory depth) in git, with very small constant.
And even in the case of packed format, it wouldn't be O(diff)/O(history),
but O(delta length) where delta length is maximum length of delta chain
in pack, by default set to 10. Well, constant is a bit larges because git
additionally gzip-compresses (even in loose, i.e. unpacked format).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: renames in StGIT
From: Catalin Marinas @ 2006-10-24 10:25 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Sean, git
In-Reply-To: <20061024091620.GB29265@diana.vm.bytemark.co.uk>
On 24/10/06, Karl Hasselström <kha@treskal.com> wrote:
> On 2006-10-24 09:48:44 +0100, Catalin Marinas wrote:
> > Step 3 above is handled per file by the
> > stgit.gitmergeonefile.merge() function. This is the place where we
> > should have the rename detection. Since, the majority of the patches
> > don't rename files and, in most cases, the push finishes at step 2,
> > it is probably safe to extend this function and the users won't
> > notice a speed difference.
> >
> > I'll add it to the TODO list.
>
> Sounds good. I had a feeling it ought to be basically free in the
> majority of cases, so I'm glad to learn I'm right. :-)
Might be even simpler for 'push' but I need to do more tests - instead
of calling git-read-tree in git.merge(), just call git-merge-recursive
which handles renames and it's fully tested. My simple test detected
renames when pushing patches (both rename in base and rename in
patch). I still have to do some tweaking and write proper tests (and
probably make it less verbose).
--
Catalin
^ permalink raw reply
* Re: updating only changed files source directory?
From: Jakub Narebski @ 2006-10-24 10:13 UTC (permalink / raw)
To: Han-Wen Nienhuys; +Cc: git
In-Reply-To: <453DE1F5.5010803@xs4all.nl>
Han-Wen Nienhuys wrote:
> Jakub Narebski escreveu:
>> Han-Wen Nienhuys wrote:
>>
>> I see that you are using fairly low level commands (plumbing commands)
>>
>>> git-http-fetch -a <branch> <url>
>>> wget <url>/refs/head/<branch> ## dump to <myrepo>/refs/head/<branch>
>>
>> instead of setting $GIT_DIR/remotes/origin file and using "git fetch".
>> BTW. "git fetch" will not update branch you are on, unless --update-head-ok
>> option is used.
>
> I tried fetch, but was put off by the warnings because I didn't have
> --update-head-ok. Using lowlevel commands is my way of making sure that
> Git doesn't assume it needs to do anything intelligent.
You can either have additional branch which is not tracking branch
(you don't fetch into this branch), and on which you are always on,
called for example 'check-out' (and which can be used for git-reset
solution to checking out files to external directory), and use
git-fetch without --update-head-ok, or (if the repository is bare
repository, without working area) use --update-head-ok.
>>> git --git-dir <myrepo> read-tree <committish>
>>>
>>> cd <srcdir>
>>> git --git-dir <myrepo> checkout-index -a -f
>>
>> instead of
>> git --git-dir=<myrepo> checkout <branch>
>> (-f is Force a re-read of everything)
git-checkout-index(1):
-f|--force
forces overwrite of existing files
So probably you would get what you want if you lose '-f'.
> Yes, however,
>
> git checkout
>
> changes the state of the repository, which is something I want to prevent.
Well, git-reset also changes state of repository, but it changes only
the branch we have created exactly for this purpose.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: VCS comparison table
From: Martin Langhoff @ 2006-10-24 10:11 UTC (permalink / raw)
To: Erik Bågfors; +Cc: Linus Torvalds, Jakub Narebski, bazaar-ng, git
In-Reply-To: <845b6e870610240052l70ad72f4ma30065f151828dfd@mail.gmail.com>
On 10/24/06, Erik Bågfors <zindar@gmail.com> wrote:
> It's Erik :)
Sorry Erik!
> Let's make one thing clear. Revnos are NOT stored with the revision,
> they are not "names" of the revision. They are basically just
> shortcuts to specific revisions, that only makes sence in the context
> of a branch.
My bad. The revnos examples discussed looked quite Arch-like. As Arch
took them seriously, I thought bzr did too.
Probably quite a few people here thought as much, and got hot under
the t-shirt about it ;-)
Now, the thing about they shorthand is that we have quite a few means
of using shorthand in GIT that don't rely on revnos. We have the whole
^branchname stuff. And when you are looking at gitk it's pretty
obvious which are your recent "local" commits.
...
> 2. treating "leftmost" parrent special is bad/good
> 2. This is something I do care about. For me, this is the only
> logical way of doing it. It might be because I am used to it now, but
> when I started to look at bzr/hg/git/darcs/etc, I just got a so much
> more clear view of the history when running a standard log command,
> that it was one of the first things that attracted me to bzr. This is
> just a user talking.
> There might be technical reasons why it's better to not do it, but for
> me it works the way I expect, therefore I'm happy
Can you give us a quick example of why you got such a clearer picture?
> 3. plugins are useless/useful
Hmmmm. It's more of a unix/C/pipes tradition vs dynamically typed &
compiled scripting language tradition.
> 4. And now, storing branch information should be done manually (if
> wanted) and not automatically.
> 4. No comment.
Probably not. But if someone is using branchnames to identify "lines
of work" and hoping that metadata will remain attached there, it's
probably a bad long-term approach.
But following what you said earlier about that info being transient
and "local", then I was 200% wrong, and thinking of Arch/Bazaar usage
patterns.
cheers,
martin
^ permalink raw reply
* Re: VCS comparison table
From: Matthieu Moy @ 2006-10-24 9:51 UTC (permalink / raw)
To: Matthew D. Fuller; +Cc: Linus Torvalds, bazaar-ng, git
In-Reply-To: <20061023222131.GB17019@over-yonder.net>
"Matthew D. Fuller" <fullermd@over-yonder.net> writes:
>> For example, how long does it take to do an arbitrary "undo" (ie
>> forcing a branch to an earlier state) [...]
>
> I don't understand the thrust of this, either. As I understand the
> operation you're talking about, it doesn't have anything to do with a
> branch; you'd just be whipping the working tree around to different
> versions. That should be O(diff) on any modern VCS.
There are two things to do:
* Mark the tree as corresponding to a different revision in the past.
This is roughly "echo 'revision@id-123' > .bzr/checkout/last-revision"
in bzr. Obviously, writting the file is O(1), but computing the
revision identifier if you say "bzr switch -r 42" (I'm not sure
switch accepts this BTW), you have to load the revision history.
Indeed, bzr would load it anyway to make sure that the revision you
switch to is in the revision history.
In bzr, you have .bzr/branch/revision-history for each branch, which
is a newline-separated list of revision-identifiers. In the case of
bzr.dev, for example, this file is 112KB as of now. This is
O(history), with "history" being the length of the path from HEAD to
the initial commit, following the leftmost ancestor (i.e. number of
revisions in a centralized workflow, and less than this otherwise).
That said, the constant factor is very small. For example, on
bzr.dev, I did "grep -n some-rev-id" (which does revid-to-revno), it
takes 0.004 seconds (Vs 0.003 seconds to grep in /dev/null
instead ;-) ), so you'd need many orders of magnitude before this
becomes a limitation.
Linus's point AIUI is that this will _never_ be a limitation of git.
* Then, do the "merge" to make your tree up to date. You can hardly do
faster than git and its unpacked format, but this is at the cost of
disk space. But as you say, in almost any modern VCS, that's
O(diff). In a space-efficient format, that's just the tradeoff you
make between full copies of a file and delta-compression.
--
Matthieu
^ permalink raw reply
* Re: updating only changed files source directory?
From: Han-Wen Nienhuys @ 2006-10-24 9:50 UTC (permalink / raw)
To: git
In-Reply-To: <ehkgfs$af6$1@sea.gmane.org>
Jakub Narebski escreveu:
> Han-Wen Nienhuys wrote:
>
>> I have some questions and remarks
>
> I see that you are using fairly low level commands (plumbing commands)
>
>> git-http-fetch -a <branch> <url>
>> wget <url>/refs/head/<branch> ## dump to <myrepo>/refs/head/<branch>
>
> instead of setting $GIT_DIR/remotes/origin file and using "git fetch".
> BTW. "git fetch" will not update branch you are on, unless --update-head-ok
> option is used.
I tried fetch, but was put off by the warnings because I didn't have
--update-head-ok. Using lowlevel commands is my way of making sure that
Git doesn't assume it needs to do anything intelligent.
>> git --git-dir <myrepo> read-tree <committish>
>>
>> cd <srcdir>
>> git --git-dir <myrepo> checkout-index -a -f
>
> instead of
> git --git-dir=<myrepo> checkout <branch>
> (-f is Force a re-read of everything)
Yes, however,
checkout
changes the state of the repository, which is something I want to prevent.
>> * As far as I can see, there is no reason to have only one index in a
>> git repository. Why isn't it possible to specify an alternate
>> index-file with an option similar to --git-dir ?
>
> --git-dir is alternative to setting GIT_DIR. You can use GIT_INDEX_FILE
> to specify alternate index file. Documented in git(7), section
> "ENVIRONMENT VARIABLES".
Silly me, I overlooked in the manpage. Note that it is standard to put
the environment section at the end of the manpage. Right now it's
somewhere in the middle.
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* [PATCH] git-svn: fix symlink-to-file changes when using command-line svn 1.4.0
From: Eric Wong @ 2006-10-24 9:50 UTC (permalink / raw)
To: Uwe Zeisberger, Junio C Hamano; +Cc: git
In-Reply-To: <20061018085948.GA27357@cepheus.pub>
I incorrectly thought this was hopelessly broken in svn 1.4.0,
but now it's just broken in that the old method didn't work. It
looks like svn propdel and svn propset must be used now and the
(imho) more obvious svn rm --force && svn add no longer works.
make -C t full-svn-test should now work
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-svn.perl | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 54d2356..37ecc51 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -1501,10 +1501,13 @@ sub svn_checkout_tree {
apply_mod_line_blob($m);
svn_check_prop_executable($m);
} elsif ($m->{chg} eq 'T') {
- sys(qw(svn rm --force),$m->{file_b});
- apply_mod_line_blob($m);
- sys(qw(svn add), $m->{file_b});
svn_check_prop_executable($m);
+ apply_mod_line_blob($m);
+ if ($m->{mode_a} =~ /^120/ && $m->{mode_b} !~ /^120/) {
+ sys(qw(svn propdel svn:special), $m->{file_b});
+ } else {
+ sys(qw(svn propset svn:special *),$m->{file_b});
+ }
} elsif ($m->{chg} eq 'A') {
svn_ensure_parent_path( $m->{file_b} );
apply_mod_line_blob($m);
--
1.4.3.2.g125940
^ permalink raw reply related
* Re: A note from the maintainer
From: Jakub Narebski @ 2006-10-24 9:37 UTC (permalink / raw)
To: git
In-Reply-To: <7vk62qhy4k.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> * Mailing list.
>
> The development is primarily done on this mailing list you are
> reading right now.
>
> If you have patches, please send them to the list, following
> Documentation/SubmittingPatches.
>
> The list is available at various public sites as well:
>
> http://news.gmane.org/gmane.comp.version-control.git
> http://marc.theaimsgroup.com/?l=git
It is also available via GMane NNTP (mail to news) interface as
nntp://news.gmane.org/gmane.comp.version-control.git
so you can read it using your favourite news reader, without need
to be subscribed to mailing list.
It is better to send patches via email, not via news as 1.) news reader are
more likely to munge whitespace, 2) mail<->news gateway might munge
whitespace on it's own, though.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: VCS comparison table
From: Jelmer Vernooij @ 2006-10-24 9:30 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Erik B?gfors, bazaar-ng, git, Jakub Narebski
In-Reply-To: <Pine.LNX.4.64.0610231623340.3962@g5.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 978 bytes --]
On Mon, Oct 23, 2006 at 04:24:30PM -0700, Linus Torvalds wrote:
> On Tue, 24 Oct 2006, Erik B?gfors wrote:
> > I don't see any problem doing a "gitk --all" equivalent in bzr.
> The problem? How do you show a commit that is _common_ to two branches,
> but has different revision names in them?
It'll have the same revision name. The revision no's will be
different, sure, but that's not a problem.
> Do you _finally_ see what is so wrong with this whole per-branch naming?
revnos are the only naming bit that is branch-specific.
I guess one way of looking at revnos is to regard them completely as a
command-line ui thing. They're not explicitly stored anywhere on
disk but just an easy way for users to refer to revisions on a
per-branch basis.
The graphical frontends to bzr, for example, don't know about revno's but
only about revids.
Cheers,
Jelmer
--
Jelmer Vernooij <jelmer@samba.org> - http://jelmer.vernstok.nl/
Currently playing:
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: [PATCH 2/1 (amend)] gitweb: Use fixed string for "next" link in commitdiff view
From: Jakub Narebski @ 2006-10-24 9:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfydehy2q.fsf@assigned-by-dhcp.cox.net>
Dnia wtorek 24. października 2006 11:17, Junio C Hamano napisał:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> Use fixed string instead of shortened SHA1 identifier of commit
>> as a name for "mext" link in commitdiff view.
>>
>> While at it make sure that we don't mistake option for a second
>> commit.
>>
>> Signed-off-by: Jakub Narebski <jnareb@gmail.com>
>> ---
>
> Q1. (amend) to fix what?
Petr "Pasky" Baudis wrote:
>> } else {
>> # merge commit
>> $formats_nav .=
>> - ' (merge: ' .
>> + ' (' .
[...]
> For people not used to git, it would be more informative to keep the
> 'merge' text there.
It also fixes detection if it is diff of two specified commits. Although
$hash_parent is set to '--root' for rootloess commit later, we could
have it set by hand. This is also preparation for later using '--cc'
(although we wouldn't generate such URL, I don't think).
> Q2. "mext"?
Oops.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH 2/1 (amend)] gitweb: Use fixed string for "next" link in commitdiff view
From: Junio C Hamano @ 2006-10-24 9:17 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200610241104.18517.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Use fixed string instead of shortened SHA1 identifier of commit
> as a name for "mext" link in commitdiff view.
>
> While at it make sure that we don't mistake option for a second
> commit.
>
> Signed-off-by: Jakub Narebski <jnareb@gmail.com>
> ---
Q1. (amend) to fix what?
Q2. "mext"?
^ permalink raw reply
* A note from the maintainer
From: Junio C Hamano @ 2006-10-24 9:16 UTC (permalink / raw)
To: git
Since there seem to be many new people on the git list, I
thought it might be worthwhile to talk about how git.git is
managed, and how you can work with it.
* Mailing list.
The development is primarily done on this mailing list you are
reading right now.
If you have patches, please send them to the list, following
Documentation/SubmittingPatches.
The list is available at various public sites as well:
http://news.gmane.org/gmane.comp.version-control.git
http://marc.theaimsgroup.com/?l=git
Many active members of development community hang around on #git
IRC channel as well. Its log is available at:
http://colabti.de/irclogger/irclogger_logs/git
[jc: Does anybody know a shortcut for "Today's" page on this
site? It irritates me having to click the latest link on this
page to get to the latest]
* Repositories and branches.
My public git.git repository is at:
git://git.kernel.org/pub/scm/git/git.git/
It is mirrored at Pasky's repo.or.cz as well.
There are three branches in git.git repository that are not
about the source tree of git: "todo", "html" and "man". The
first one is meant to contain TODO list for me, but I am not
good at maintaining such a list so it is not as often updated as
I would have liked. It also contains some helper scripts I
use to maintain it.
The "html" and "man" are autogenerated documentation from the
tip of the "master" branch; the tip of "html" is extracted to be
visible at kernel.org at:
http://www.kernel.org/pub/software/scm/git/docs/
The script to auto-maintain these two documentation branches are
found in "todo" branch as dodoc.sh script, if you are interested.
There are four branches in git.git repository that track the
source tree of git: "master", "maint", "next", and "pu".
The "master" branch is meant to contain what are reasonably
tested and ready to be used in a production setting. There
could occasionally be minor breakages or brown paper bag bugs
but they are not expected to be anything major. Every now and
then, a "feature release" is cut from the tip of this branch and
they typically are named with three dotted decimal digits. The
last such release was v1.4.3 done on Oct 18th.
Whenever a feature release is made, "maint" branch is forked off
from "master" at that point. Obvious, safe and urgent fixes
after a feature release are applied to this branch and
maintenance releases are cut from it. The maintenance releases
are typically named with four dotted decimal, named after the
feature release they are updates to; the last such release was
v1.4.3.2 was done tonight. Usually new development will never
go to this branch. This branch is also pulled into "master" to
propagate the fixes forward.
A trivial and safe enhancement goes directly on top of "master".
A new development, either initiated by myself or more often you
found your own itch to scratch, does not usually happen on
"master", however. Instead, it is forked into a separate topic
branch from the tip of "master", and first tested in isolation;
I may make minimum fixups at this point. Usually there are a
handful such topic branches that are running ahead of "master"
in git.git repository. I do not publish the tip of these
branches in my public repository, however, partly to keep the
number of branches that downstream developers need to worry
about and primarily because I am lazy.
I judge the quality of topic branches, taking advices from the
mailing list discussions. Some of them start out as "good idea
but obviously is broken in some areas (e.g. breaks the existing
testsuite)" and then with some more work (either by the original
contributor or help from other people on the list) becomes "more
or less done and can now be tested by wider audience". Luckily,
most of them start out in the latter, better shape.
The "next" branch is to merge and test topic branches in the
latter category with "master". In general it should always
contain the tip of "master". They may not be quite production
ready, but are expected to work more or less without major
breakage. I usually use "next" version of git for my own work.
"next" is where new and exciting things take place.
The above three branches, "master", "maint" and "next" are never
rewound, so you should be able to safely track them (that means
the topics that have been merged into "next" are not rebased).
The "pu" (proposed updates) branch bundles all the remaining
topic branches. The topic branches and "pu" are subject to
rebasing in general. Especially "pu" is almost always rewound
to the tip of "next" and reconstructed to contain the remaining
topic branches. What this means is that immediately after
cloning from git.git, it is advisable to mark "pu" in your
remotes/origin that it does not necessarily fast-forwards, like
this:
$ cat .git/remotes/origin
URL: git://git.kernel.org/pub/scm/git/git.git
Pull: refs/heads/master:refs/heads/origin
Pull: refs/heads/maint:refs/heads/maint
Pull: refs/heads/next:refs/heads/next
Pull: +refs/heads/pu:refs/heads/pu
When a topic that was in "pu" proves to be in testable shape, it
graduates to "next". This is done by:
git checkout next
git pull . that-topic-branch
Sometimes, an idea that looked promising turns out to be not so
hot and the topic can be dropped from "pu" in such a case.
A topic that is in "next" is _expected_ to be tweaked and fixed
to perfection before it is merged to "master". It is done by:
git checkout master
git pull . that-topic-branch
git branch -d that-topic-branch
However, being in "next" is not a guarantee to appear in the
next release (being in "master" _is_ such a guarantee), or even
in _any_ future release. There even was a case that a topic
needed a few reverting before graduating to "master".
^ permalink raw reply
* Re: renames in StGIT
From: Karl Hasselström @ 2006-10-24 9:16 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Sean, git
In-Reply-To: <b0943d9e0610240148s15d6ec5ch6114360a603fcd71@mail.gmail.com>
On 2006-10-24 09:48:44 +0100, Catalin Marinas wrote:
> Actually, it might not be a big performance impact. For diff
> generation in the export and mail commands, we should have a flag.
Agreed.
> The push operation might not need a flag since it will only checks
> renames if all the other operations failed. A push with merge
> detection has the steps below (if one succeeds, push is finished):
>
> 1. check (exact) patch merges by reverse-applying the diff
> 2. apply the diff with git-diff | git-apply since this is faster
> than a three-way merge
> 3. try a three-way merge between head, bottom and top
>
> Step 3 above is handled per file by the
> stgit.gitmergeonefile.merge() function. This is the place where we
> should have the rename detection. Since, the majority of the patches
> don't rename files and, in most cases, the push finishes at step 2,
> it is probably safe to extend this function and the users won't
> notice a speed difference.
>
> I'll add it to the TODO list.
Sounds good. I had a feeling it ought to be basically free in the
majority of cases, so I'm glad to learn I'm right. :-)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* [PATCH 2/1 (amend)] gitweb: Use fixed string for "next" link in commitdiff view
From: Jakub Narebski @ 2006-10-24 9:04 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20061023232117.GV20017@pasky.or.cz>
Use fixed string instead of shortened SHA1 identifier of commit
as a name for "mext" link in commitdiff view.
While at it make sure that we don't mistake option for a second
commit.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 17 +++++++----------
1 files changed, 7 insertions(+), 10 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 4241d5c..9c81214 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3289,17 +3289,14 @@ sub git_commitdiff {
hash=>$hash, hash_parent=>$hash_parent)},
"raw");
- if (defined $hash_parent) {
+ if (defined $hash_parent && $hash_parent !~ m/^-/) {
# commitdiff with two commits given
- my $hash_parent_short = $hash_parent;
- if ($hash_parent =~ m/^[0-9a-fA-F]{40}$/) {
- $hash_parent_short = substr($hash_parent, 0, 7);
- }
+ # second "commit" is not in fact diff option
$formats_nav .=
- ' (from: ' .
+ ' (' .
$cgi->a({-href => href(action=>"commitdiff",
hash=>$hash_parent)},
- esc_html($hash_parent_short)) .
+ 'from') .
')';
} elsif (!$co{'parent'}) {
# --root commitdiff
@@ -3307,10 +3304,10 @@ sub git_commitdiff {
} elsif (scalar @{$co{'parents'}} == 1) {
# single parent commit
$formats_nav .=
- ' (parent: ' .
+ ' (' .
$cgi->a({-href => href(action=>"commitdiff",
hash=>$co{'parent'})},
- esc_html(substr($co{'parent'}, 0, 7))) .
+ 'parent') .
')';
} else {
# merge commit
@@ -3319,7 +3316,7 @@ sub git_commitdiff {
join(' ', map {
$cgi->a({-href => href(action=>"commitdiff",
hash=>$_)},
- esc_html(substr($_, 0, 7)));
+ 'parent');
} @{$co{'parents'}} ) .
')';
}
--
1.4.2.1
^ permalink raw reply related
* Re: [PATCH] gitweb: Restore object-named links in item lists
From: Jakub Narebski @ 2006-10-24 8:51 UTC (permalink / raw)
To: git
In-Reply-To: <20061024033610.7959.4028.stgit@rover>
Petr Baudis wrote:
> This restores the redundant links removed earlier. It supersedes my patch
> to stick slashes to tree entries.
I would put those "redundant links" in separate column (like for git_tags).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: renames in StGIT
From: Catalin Marinas @ 2006-10-24 8:48 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Sean, git
In-Reply-To: <20061024081732.GA29265@diana.vm.bytemark.co.uk>
On 24/10/06, Karl Hasselström <kha@treskal.com> wrote:
> On 2006-10-23 12:53:44 -0400, Sean wrote:
> > There are some situation where it would be really quite handy. The
> > performance of the human having to hand resolve a failed push
> > because of renames is often worse ;o) If it does become a
> > performance problem, perhaps you could make it an optional parameter
> > to "stg push".
>
> Yes, this is my opinion too, both for patch generation and pushing.
> Having it always on is a bad idea at least for patch generation for
> obvious reasons, and may be a bad idea for pushing for performance
> reasons, but I definitely think there should be a flag to enable it.
Actually, it might not be a big performance impact. For diff
generation in the export and mail commands, we should have a flag.
The push operation might not need a flag since it will only checks
renames if all the other operations failed. A push with merge
detection has the steps below (if one succeeds, push is finished):
1. check (exact) patch merges by reverse-applying the diff
2. apply the diff with git-diff | git-apply since this is faster than
a three-way merge
3. try a three-way merge between head, bottom and top
Step 3 above is handled per file by the stgit.gitmergeonefile.merge()
function. This is the place where we should have the rename detection.
Since, the majority of the patches don't rename files and, in most
cases, the push finishes at step 2, it is probably safe to extend this
function and the users won't notice a speed difference.
I'll add it to the TODO list.
--
Catalin
^ permalink raw reply
* Re: [PATCH] gitweb: Show project's README.html if available
From: Luben Tuikov @ 2006-10-24 8:43 UTC (permalink / raw)
To: Petr Baudis, Junio C Hamano; +Cc: git
In-Reply-To: <20061024032346.4185.85330.stgit@rover>
--- Petr Baudis <pasky@suse.cz> wrote:
> If the repository includes a README.html file, show it in the summary page.
> The usual "this should be in the config file" argument does not apply here
> since this can be larger and having such a big string in the config file
> would be impractical.
>
> I don't know if this is suitable upstream, but it's one of the repo.or.cz
> custom modifications that I've thought could be interesting for others
> as well.
>
> Compared to the previous patch, this adds the '.html' extension to the
> filename, so that it's clear it is, well, HTML.
>
> Signed-off-by: Petr Baudis <pasky@suse.cz>
> ---
Why not instead re-submit a patch implementing what was discussed
in this thread bearing the same name:
http://marc.theaimsgroup.com/?t=116044914900001&r=1&w=2
Luben
>
> gitweb/gitweb.perl | 8 ++++++++
> 1 files changed, 8 insertions(+), 0 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 3b26ec3..81adc71 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -2538,6 +2538,14 @@ sub git_summary {
> }
> print "</table>\n";
>
> + if (-s "$projectroot/$project/README.html") {
> + if (open my $fd, "$projectroot/$project/README.html") {
> + print "<div class=\"title\">readme</div>\n";
> + print $_ while (<$fd>);
> + close $fd;
> + }
> + }
> +
> open my $fd, "-|", git_cmd(), "rev-list", "--max-count=17",
> git_get_head_hash($project)
> or die_error(undef, "Open git-rev-list failed");
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH] gitweb: Restore object-named links in item lists
From: Luben Tuikov @ 2006-10-24 8:38 UTC (permalink / raw)
To: Petr Baudis, Junio C Hamano; +Cc: git
In-Reply-To: <20061024033610.7959.4028.stgit@rover>
--- Petr Baudis <pasky@suse.cz> wrote:
> This restores the redundant links removed earlier. It supersedes my patch
> to stick slashes to tree entries.
>
> Sorry about the previous version of the patch, an unrelated snapshot link
> addition to tree entries slipped through (and it it didn't even compile);
> I've dropped the idea of snapshot links in tree entries in the meantime
> anyway.
>
> Signed-off-by: Petr Baudis <pasky@suse.cz>
> ---
http://marc.theaimsgroup.com/?t=116059799500003&r=1&w=2
Luben
>
> gitweb/gitweb.perl | 28 ++++++++++++++++++++++------
> 1 files changed, 22 insertions(+), 6 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 4a2025c..661d1dd 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -1793,16 +1793,18 @@ sub git_print_tree_entry {
> file_name=>"$basedir$t->{'name'}", %base_key),
> -class => "list"}, esc_html($t->{'name'})) . "</td>\n";
> print "<td class=\"link\">";
> + print $cgi->a({-href => href(action=>"blob", hash=>$t->{'hash'},
> + file_name=>"$basedir$t->{'name'}", %base_key)},
> + "blob");
> if ($have_blame) {
> - print $cgi->a({-href => href(action=>"blame", hash=>$t->{'hash'},
> + print " | " .
> + $cgi->a({-href => href(action=>"blame", hash=>$t->{'hash'},
> file_name=>"$basedir$t->{'name'}", %base_key)},
> "blame");
> }
> if (defined $hash_base) {
> - if ($have_blame) {
> - print " | ";
> - }
> - print $cgi->a({-href => href(action=>"history", hash_base=>$hash_base,
> + print " | " .
> + $cgi->a({-href => href(action=>"history", hash_base=>$hash_base,
> hash=>$t->{'hash'}, file_name=>"$basedir$t->{'name'}")},
> "history");
> }
> @@ -1819,8 +1821,12 @@ sub git_print_tree_entry {
> esc_html($t->{'name'}));
> print "</td>\n";
> print "<td class=\"link\">";
> + print $cgi->a({-href => href(action=>"tree", hash=>$t->{'hash'},
> + file_name=>"$basedir$t->{'name'}", %base_key)},
> + "tree");
> if (defined $hash_base) {
> - print $cgi->a({-href => href(action=>"history", hash_base=>$hash_base,
> + print " | " .
> + $cgi->a({-href => href(action=>"history", hash_base=>$hash_base,
> file_name=>"$basedir$t->{'name'}")},
> "history");
> }
> @@ -1903,6 +1909,9 @@ sub git_difftree_body {
> print $cgi->a({-href => "#patch$patchno"}, "patch");
> print " | ";
> }
> + print $cgi->a({-href => href(action=>"blob", hash=>$diff{'from_id'},
> + hash_base=>$parent, file_name=>$diff{'file'})},
> + "blob") . " | ";
> print $cgi->a({-href => href(action=>"blame", hash_base=>$parent,
> file_name=>$diff{'file'})},
> "blame") . " | ";
> @@ -1948,6 +1957,9 @@ sub git_difftree_body {
> }
> print " | ";
> }
> + print $cgi->a({-href => href(action=>"blob", hash=>$diff{'to_id'},
> + hash_base=>$hash, file_name=>$diff{'file'})},
> + "blob") . " | ";
> print $cgi->a({-href => href(action=>"blame", hash_base=>$hash,
> file_name=>$diff{'file'})},
> "blame") . " | ";
> @@ -1988,6 +2000,9 @@ sub git_difftree_body {
> }
> print " | ";
> }
> + print $cgi->a({-href => href(action=>"blob", hash=>$diff{'from_id'},
> + hash_base=>$parent, file_name=>$diff{'from_file'})},
> + "blob") . " | ";
> print $cgi->a({-href => href(action=>"blame", hash_base=>$parent,
> file_name=>$diff{'from_file'})},
> "blame") . " | ";
> @@ -2155,6 +2170,7 @@ sub git_shortlog_body {
> href(action=>"commit", hash=>$commit), $ref);
> print "</td>\n" .
> "<td class=\"link\">" .
> + $cgi->a({-href => href(action=>"commit", hash=>$commit)}, "commit") . " | " .
> $cgi->a({-href => href(action=>"commitdiff", hash=>$commit)}, "commitdiff") . " | " .
> $cgi->a({-href => href(action=>"tree", hash=>$commit, hash_base=>$commit)}, "tree");
> if (gitweb_have_snapshot()) {
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-24 8:37 UTC (permalink / raw)
To: Erik Bågfors; +Cc: Martin Langhoff, Linus Torvalds, bazaar-ng, git
In-Reply-To: <845b6e870610240052l70ad72f4ma30065f151828dfd@mail.gmail.com>
Erik Bågfors wrote:
> I think this disussion is getting out of hand.
>
> There are a few things that are being discussed
> 1. Revnos are bad/good
> 2. treating "leftmost" parrent special is bad/good
> 3. plugins are useless/useful
> 4. And now, storing branch information should be done manually (if
> wanted) and not automatically.
>
> 1. I don't really care, I haven't seen any confusion based on it, but
> I don't have a very strong opinion about it either.
To use revnos[*1*] you have to have branch as path through DAG. Bzr does
that by treating first parent special, which leads to empty merges
in fast-forward case.
Using revnos as implemented in bzr leads to some (perhaps unforeseen)
consequences.
[*1*] Meaning that revnos won't change on you.
> 2. This is something I do care about. For me, this is the only
> logical way of doing it. It might be because I am used to it now, but
> when I started to look at bzr/hg/git/darcs/etc, I just got a so much
> more clear view of the history when running a standard log command,
> that it was one of the first things that attracted me to bzr. This is
> just a user talking.
Git has reflog for when you are interested in branch tip history
(which also stores "reason" for branch tip change: pull, amending
a commit, rebase,...). Git doesn't unfortunately have git-ref-log
command (or --ref option to git-log) to display reflog in user friendly
format.
Git users are used to use graphical history viewers (mainly gitk and
qgit, but there is also gitview, tig and git-browser) more to have
clear view of history, view that log cannot provide.
That said I _thing_ that caring about "branch identity" is just
something you are used to, perhaps because bzr doesn't have wonderfull
git log limiting specifiers aka. builtin git log searching (a..b,
a...b, --max-count, -- <path>, --committer, --grep etc.).
> There might be technical reasons why it's better to not do it, but for
> me it works the way I expect, therefore I'm happy
I think it would be better to maintain "branch identity" separately and
not in DAG, but that might have other problems I have not seen.
> 3. This is just silly
I think the discussion/arguments were twofold.
First, Bazaar-NG has plugin infrastructure "for free" because it is
written in Python, which allows modules loading and monkey-patching.
Git core is written in C, and git is not yet fully libified.
Second, all that can be done with plugins except for core changes can be
done in Git writing scripts (this also allows for fast prototyping).
All except core changes can be done writing few lines in C, but you
have to compile against some version of Git, and don't have advantages
of bultin command; git is OSS project.
> 4. No comment.
Storing branch information could be done automatically on demand ;-)
--
Jakub Narebski
Poland
^ 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