* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-21 13:05 UTC (permalink / raw)
To: git; +Cc: bazaar-ng
In-Reply-To: <20061021123027.GB29843@artax.karlin.mff.cuni.cz>
Jan Hudec wrote:
> On Fri, Oct 20, 2006 at 12:05:35AM -0400, Aaron Bentley wrote:
>> Tim Webster wrote:
>> > Also svn does not allow files in the same directory to live in
>> > multiple repos
>>
>> It would surprise me if many SCMs that support atomic commit also
>> support intermixing files from multiple repos in the same directory.
>
> In fact I think svk would. You would have to switch them by setting
> an environment variable, but it's probably doable. That is because
> unlike other version control systems, it does not store the information
> about checkout in the checkout, but in the central directory and that
> can be set. I don't know git well enough to tell whether git could do
> the same by setting GIT_DIR.
You can very simply embed one "clothed" repository into another in GIT,
like shown below
project/.git
project/subdir/
project/subdir/file
project/subproject/
project/subproject/.git
project/subproject/file
...
It depends on circumstances if one wants files belonging to subdirectory
be ignored by top repository. You would want to ignore .git/ directory,
though.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: VCS comparison table
From: Jan Hudec @ 2006-10-21 13:15 UTC (permalink / raw)
To: Jakub Narebski; +Cc: bazaar-ng, git
In-Reply-To: <ehd5u7$c5g$1@sea.gmane.org>
On Sat, Oct 21, 2006 at 03:05:22PM +0200, Jakub Narebski wrote:
> Jan Hudec wrote:
>
> > On Fri, Oct 20, 2006 at 12:05:35AM -0400, Aaron Bentley wrote:
> >> Tim Webster wrote:
> >> > Also svn does not allow files in the same directory to live in
> >> > multiple repos
> >>
> >> It would surprise me if many SCMs that support atomic commit also
> >> support intermixing files from multiple repos in the same directory.
> >
> > In fact I think svk would. You would have to switch them by setting
> > an environment variable, but it's probably doable. That is because
> > unlike other version control systems, it does not store the information
> > about checkout in the checkout, but in the central directory and that
> > can be set. I don't know git well enough to tell whether git could do
> > the same by setting GIT_DIR.
>
> You can very simply embed one "clothed" repository into another in GIT,
> like shown below
>
> project/.git
> project/subdir/
> project/subdir/file
> project/subproject/
> project/subproject/.git
> project/subproject/file
> ...
>
> It depends on circumstances if one wants files belonging to subdirectory
> be ignored by top repository. You would want to ignore .git/ directory,
> though.
Yes, you can do that with bzr and most other tools I know of as well.
But I understand the original question as requesting the working trees
to be rooted at the same place (ie. all in /etc), because each has some
files and some directories that have to be placed next to each other.
--------------------------------------------------------------------------------
- Jan Hudec `Bulb' <bulb@ucw.cz>
^ permalink raw reply
* less -F ubuntu dapper.
From: Aneesh Kumar @ 2006-10-21 13:23 UTC (permalink / raw)
To: Git Mailing List
-F option for less in ubuntu Dapper is broken. It doesn't display
anyting if the file can be displayed in one page. Because of this the
recent chages to
96a035d1db9082d244867033020d0ceb571cf94e results in commands like git
show not showing the changes.
https://launchpad.net/distros/ubuntu/+source/less/+bug/67381
-aneesh
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-21 13:29 UTC (permalink / raw)
To: Jan Hudec; +Cc: bazaar-ng, git
In-Reply-To: <20061021131551.GC29843@artax.karlin.mff.cuni.cz>
Dnia sobota 21. października 2006 15:15, Jan Hudec napisał:
> On Sat, Oct 21, 2006 at 03:05:22PM +0200, Jakub Narebski wrote:
>> Jan Hudec wrote:
>>
>>> On Fri, Oct 20, 2006 at 12:05:35AM -0400, Aaron Bentley wrote:
>>>> Tim Webster wrote:
>>>>> Also svn does not allow files in the same directory to live in
>>>>> multiple repos
>>>>
>>>> It would surprise me if many SCMs that support atomic commit also
>>>> support intermixing files from multiple repos in the same directory.
>>>
>>> In fact I think svk would. You would have to switch them by setting
>>> an environment variable, but it's probably doable. That is because
>>> unlike other version control systems, it does not store the information
>>> about checkout in the checkout, but in the central directory and that
>>> can be set. I don't know git well enough to tell whether git could do
>>> the same by setting GIT_DIR.
>>
>> You can very simply embed one "clothed" repository into another in GIT,
>> like shown below
[...]
>> It depends on circumstances if one wants files belonging to subdirectory
>> be ignored by top repository. You would want to ignore .git/ directory,
>> though.
>
> Yes, you can do that with bzr and most other tools I know of as well.
> But I understand the original question as requesting the working trees
> to be rooted at the same place (ie. all in /etc), because each has some
> files and some directories that have to be placed next to each other.
You can separate working area from the repository (you don't need to have
repository in top directory of working area), but you must then provide
for each git command you do the location of repository, either via setting
GIT_DIR environmental variable (GIT_DIR=/path/to/repo.git git commit ...),
or use --git-dir option of git wrapper (git --git-dir=/path/to/repo.git diff),
as automatical detection of repository wouldn't work, of course.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re[2]: smile to you
From: Yana @ 2006-10-21 13:00 UTC (permalink / raw)
To: dccp
Hi
If you feel sad and lonely, go to my <a>page</a> and let's start chatting :)
http://findsomelove.com/myhoney
a rivederci:)
Yana
^ permalink raw reply
* Re: Alternate revno proposal (Was: Re: VCS comparison table)
From: Jan Hudec @ 2006-10-21 13:48 UTC (permalink / raw)
To: Alexander Belchenko; +Cc: bazaar-ng, git
In-Reply-To: <eh7c5t$gd1$1@sea.gmane.org>
On Thu, Oct 19, 2006 at 11:19:30AM +0300, Alexander Belchenko wrote:
> Jan Hudec ??????????:
> >Reading this thread I came to think, that the revnos should be assigned
> >to _all_ revisions _available_, in order of when they entered the
> >repository (there are some possible variations I will mention below)
> ...
> > - They would be the same as subversion and svk, and IIRC mercurial as
> > well, use, so:
> > - They would already be familiar to users comming from those systems.
> > - They are known to be useful that way. In fact for svk it's the only
> > way to refer to revisions and seem to work satisfactorily (though
> > note that svk is not really suitable to ad-hoc topologies).
>
> I think that SVN model of revision numbers is wrong. And apply it to bzr
> break many UI habits. Per example, when ones use svn and their repo has
> many branches you never could say what revisions belongs to mainline. So
> things like
> bzr diff -rM..N
> (where M and N absolute revisions numbers, and N = M+1(+2) etc.)
> will more complicated, because in this case you first need to run log
> command, remember actual numbers of those revisions.
Well, you need to run log anyway, because you usually want to see a diff
between some particular revisions, so you need to find them anyway.
On the other hand in subversion all revisions actually exist on all
branches, so svn diff -r N-1:N always shows changes introduced by
revision N, while here you would have to use before:N..N.
> And I each time frustrating to see that after mainline svn revision 1000
> might be mainline revision 1020. It's very-very-very confusing. May be
> only for me.
I got used to this pretty quickly when I used svk. And there it actually
happens much more often than in subversion itself, because you have the
mirrored branches and each commit on them also gets a revision number.
But yes, they feel more weird.
> There is 2 things why I don't want to switch to svn (if I can do my own
> choice): their strange tags implementation (their tags is the same as
> branches, so what difference?) and their revisions numbers.
>
> I also think that dotted revisions is not answer in this case, but it
> looks very logical and nice.
>
> I think bzr need to have a switch, a flag, probably in .bazaar.conf to
> show revno to user or revid. And user can easily select what model is
> more appropriate for him:
>
> * decentralized (with revno)
> * or distrubuted (with revid i.e. UUID)
Personally I'd like the ui to make the revision ids more visible since
they are the canonical way for refering to revisions and as shown among
other in this thread people who know something about distributed version
control are actually confused by them not being visible and think they
are not there.
> >Comments?
>
> -1 to make revno as in svn.
Hm, you are probably right. In any case it's more useful to teach the
users not to get attached to the revnos too much.
--------------------------------------------------------------------------------
- Jan Hudec `Bulb' <bulb@ucw.cz>
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-21 14:08 UTC (permalink / raw)
To: Matthew D. Fuller
Cc: Carl Worth, Aaron Bentley, Linus Torvalds, Andreas Ericsson,
bazaar-ng, git
In-Reply-To: <20061021130111.GL75501@over-yonder.net>
Dnia sobota 21. października 2006 15:01, Matthew D. Fuller napisał:
> On Fri, Oct 20, 2006 at 02:48:52PM -0700 I heard the voice of
> Carl Worth, and lo! it spake thus:
> >
> > The entire discussion is about how to name things in a distributed
> > system.
>
> I think we're getting into scratched-record-mode on this.
>
>
> Git: Revnos aren't globally unique or persistent.
>
> Bzr: Yes, we know.
>
> G: Therefore they're useless.
>
> B: No, they're very useful in [situation] and [situation], and we deal
> with [situation] all the time, and they work great for that.
>
> G: But they fall apart totally in [situation].
G: But revnos force centralized/star-topology development. And even in
[situation] have [disadvantages].
> B: Yes, so use revids there.
>
> G: So use revids everywhere.
>
> B: Revnos are handier tools for [situation] and [situation] for
> [reason] and [reason].
G: Shortened sha1 commit-ids are almost as handy.
> *brrrrrrrrrrrrrrrrip!!!* *skip back to start*
There _are_ terminology conflicts. For example bzr "branch" is roughly
equivalent to one-branch git "repository"; bzr "repository" is just
collection of branches sharing common storage, which is similar to set
of git "repositories" with .git/objects/ linked to common object
repository (storage area) or appropriately set alternates file
(although that is not common usage in git, and for example you would
have to be carefull with running git-prune); bzr "lightweight checkout"
is equivalent to nonexistent "lazy clone"/"remote alternates" discussed
on git mailing list but not implemented because of performance
concerns; bzr "normal checkout" is I think similar to git "shared
clone" (but shared clone is limited to repositories on the same
filesystem); bzr "heavyweight checkout" is roughly equivalent to
one-branch-only "clone" in git or cg (cg = Cogito).
And there are differences in opinion. For example "simple namespace for
revisions" which is important for bzr, is superficially simple for git
(as it works only for centralized approach, and for leaf repositories
you have to have access to central repository to get final revnos); on
the other hand "not simpleness" of git's sha1 identifiers is not that
complicated in everydays work, as one usually use branch and tag names,
<ref>~<n> and <ref1>..<ref2> syntax, sometimes shortened sha1 names and
full sha1 names only rarely. For bzr it is more important to tell from
revno which commit on branch was earlier, for git it is more important
that commitids never ever change; we can use git commands to check
which commit was earlier. For bzr plugins are important, for git it is
important to be easy to add new commands, using scripts for fast
prototyping.
> > It may be that the centralization bias
>
> I think it's more accurately describable as a branch-identity bias.
> The git claim seems to be that the two statements are identical, but I
> have some trouble swallowing that.
When two clones of the same repository (in git terminology), or two
"branches" (in bzr terminology), used by different people, cannot be
totally equivalent that is centralization bias. By equivalent I mean
that "old history" is exactly the same (the same diagram, the same
identifiers - make it usually used identifiers).
The fact that you have two different commands, "merge" vs "pull"
for using in one mother/mainline "branch" vs other "branches" tells
us that there is bias towards centralization.
> > I'm still not sure exactly what a bzr branch is, but it's clearly
> > something different from a git branch,
>
> The term is somewhat overloaded, which is why it's causing you trouble
> (and did me). It refers both to the conceptual entity ("a line of
> development" roughly, much like what 'branch' means in git and VCS in
> general), and to the physical location (directory, URL) where that
> branch is stored, and where it'll often have a working tree. Branches
> are always referred to by location, never by name.
I'd rather use other name then. Perhaps "forks" for physical "branch",
i.e. branch metadata (like revno to revid mapping) + object repository
or pointer to it + optionally working area/working files.
[...]
> > (since pull seems the only way to synch up without infinite new
> > merge commits being added back and forth).
>
> The infinite-merge-commits case doesn't happen in bzr-land because we
> generally don't merge other branches except when the branch owner says
> "Hey, I've got something for you to merge". If you were to setup a
> script to merge two branches back and forth until they were 'equal',
> yes, it'd churn away until you filled up your disk with the N bytes of
> metadata every new revision uses up.
And you say that bzr is not biased towards centralization? In git you
can just pull (fetch) to check if there were any changes, and if there
were not you don't get useless marker-merges.
Take for example two simple git scenarios:
1. Single branch repository. We have two clones of the same repository,
both with only one branch, 'master', both working on this branch, and
both considered equal. If only one person worked on branch, "pull"
would result in fast-forward. If both worked on branch, "pull" would
result in merge. This is the "diamond" example by Pasky, which
explained why git doesn't treat first parent like special - because of
fast forward. Bzr treats first parent/mainline/"the branch" special
therefore it generates superficial merge commits if we preserve revnos;
BTW doesn't "pull" clobber your changes?
2. But the preferred git workflow is to have two branches in each of two
clones. The 'origin' branch where you fetch changes from other
repository (so called "tracking branch") and you don't commit your
changes to (by convention, as git doesn't protect the branch from
commiting to, although it would refuse to fetch in non fast-forward
case unless forced). You put your work in the 'master' branch, and you
merge 'origin' branch into 'master'. This allows for example fetching
changes to 'origin' but _not_ merging them immediately into 'master',
for example if you are in the middle of some larger work byt want to
check what other side did to not to create conflict if not neccessary.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: VCS comparison table
From: Jan Hudec @ 2006-10-21 14:13 UTC (permalink / raw)
To: Sean; +Cc: Matthieu Moy, Linus Torvalds, bazaar-ng, git, Jakub Narebski
In-Reply-To: <20061017073839.3728d1e7.seanlkml@sympatico.ca>
On Tue, Oct 17, 2006 at 07:38:39AM -0400, Sean wrote:
> On Tue, 17 Oct 2006 13:19:08 +0200
> Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
>
> > 1) a working tree without any history information, pointing to some
> > other location for the history itself (a la svn/CVS/...).
> > (this is "light checkout")
>
> Git can do this from a local repository, it just can't do it from
> a remote repo (at least over the git native protocol). However,
> over gitweb you can grab and unpack a tarball from a remote repo.
> In practice this is probably enough support for such a feature.
>
> > 2) a bound branch. It's not _very_ different from a normal branch, but
> > mostly "commit" behaves differently:
> > - it commits both on the local and the remote branch (equivalent to
> > "commit" + "push", but in a transactional way).
> > - it refuses to commit if you're out of date with the branch you're
> > bound to.
> > (this is "heavy checkout")
>
> This doesn't sound right, at least in the spirit of git. Git really
> wants to have a local commit which you may or may not push to a
> remote repo at a later time. There is no upside to forcing it all to
> happen in one step, and a lot of downsides. Gits focus is to support
> distributed offline development, not requiring a remote repo to be
> available at commit time.
While there is no upside to forcing it all to _always_ happen in one
step, there are good reasons to allow it in particular cases.
The most common is if you work on something from two different computers
(at home and at work or from desktop or notebook or similar cases) and
want to be sure you don't forget to synchronize your changes.
You can always unbind the branch or do a commit --local, which allows
doing a local commit anyway (eg. when disconnected) and then the next
commit will require a merge if the branches diverged.
> > In both cases, this has the side effect that you can't commit if the
> > "upstream" branch is read-only. That's not fundamental, but handy.
>
> Again this seems really anti-git. There is no reason for your local
> branch to be marked read only just because some upstream branch is
> so marked.
Again, it only is if you want, and opt for, making it so. Eg. people who
often have many terminals with different current directories may use it
to protect themselves from accidentaly running commands in the wrong
one. You don't have to use it if you don't want to.
> > I use it for example to have several "checkouts" of the same branch on
> > different machines. When I commit, bzr tells me "hey, boss, you're out
> > of date, why don't you update first" if I'm out of date. And if commit
> > succeeds, I'm sure it is already commited to the main branch. I'm sure
> > I won't pollute my history with merges which would only be the result
> > of forgetting to update.
>
> This is exactly the same in Git. You really only ever push upstream
> when your local changes fast forward the remote, (ie. you're up to date).
> Git will warn you if your changes don't fast forward the remote.
In bzr push and pull only work for the fast-forward case. They operate
on branches and actually apply the changes on the target. But that's a
different thing. Bound branches are mainly about not forgetting to
synchronize it.
> > The more fundamental thing I suppose is that it allows people to work
> > in a centralized way (checkout/commit/update/...), and Bazaar was
> > designed to allow several different workflows, including the
> > centralized one.
>
> While Git really isn't meant to work in a centralized way there's nothing
> preventing such a work flow. It just requires the use of some surrounding
> infrastructure.
Bzr is meant to be used in both ways, depending on user's choice.
Therefore it comes with that infrastructure and you can choose whether
you want to use it or not.
--------------------------------------------------------------------------------
- Jan Hudec `Bulb' <bulb@ucw.cz>
^ permalink raw reply
* Re: VCS comparison table
From: Sean @ 2006-10-21 14:23 UTC (permalink / raw)
To: Jan Hudec; +Cc: Matthieu Moy, Linus Torvalds, bazaar-ng, git, Jakub Narebski
In-Reply-To: <20061021141328.GE29843@artax.karlin.mff.cuni.cz>
On Sat, 21 Oct 2006 16:13:28 +0200
Jan Hudec <bulb@ucw.cz> wrote:
> Bzr is meant to be used in both ways, depending on user's choice.
> Therefore it comes with that infrastructure and you can choose whether
> you want to use it or not.
>From what we've read on this thread, bzr appears to be biased towards
working with a central repo. That is the model that supports the use of
revnos etc that the bzr folks are so fond of. However Git is perfectly
capable of being used in any number of models, including centralized.
Git just doesn't make the mistake of training new users into using
features that are only stable in a limited number of those models.
Sean
^ permalink raw reply
* Re: VCS comparison table
From: Sean @ 2006-10-21 14:23 UTC (permalink / raw)
To: Jan Hudec; +Cc: Linus Torvalds, bazaar-ng, git, Matthieu Moy, Jakub Narebski
In-Reply-To: <20061021141328.GE29843@artax.karlin.mff.cuni.cz>
On Sat, 21 Oct 2006 16:13:28 +0200
Jan Hudec <bulb@ucw.cz> wrote:
> Bzr is meant to be used in both ways, depending on user's choice.
> Therefore it comes with that infrastructure and you can choose whether
> you want to use it or not.
>From what we've read on this thread, bzr appears to be biased towards
working with a central repo. That is the model that supports the use of
revnos etc that the bzr folks are so fond of. However Git is perfectly
capable of being used in any number of models, including centralized.
Git just doesn't make the mistake of training new users into using
features that are only stable in a limited number of those models.
Sean
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.4.3
From: Rene Scharfe @ 2006-10-21 14:29 UTC (permalink / raw)
To: Al Viro; +Cc: Linus Torvalds, Junio C Hamano, git
In-Reply-To: <20061021021235.GA29920@ftp.linux.org.uk>
Al Viro schrieb:
> Speaking of irritations... There is a major (and AFAICS fixable)
> suckitude in git-cherry.
[...]
> For one thing, there are better ways to do set comparison than creating
> a file for each element in one set and going through another checking
> if corresponding files exist (join(1) and sort(1) or just use perl hashes).
[...]
> Note that we are calculating a function of commit; it _never_ changes.
> Even if we don't just calculate and memorize it at commit time, a cache
> somewhere under .git would speed the things up a lot...
How about this patch? It does away with using temporary files and instead
creates persistent cache files under .git/patch-ids/. It is a very stupid
cache layout: file name = commit SHA1, file contents = patch ID. Perhaps
it needs fan-out directories like .git/objects/ has before it can be
considered for merge.
The set compare is stupid, too, but at least it is in-shell now, using a
space separated list and the is_in function.
And the cache file creation is not safe for multiple parallel git-cherry's.
It survives "make test" and is otherwise untested. Care to test drive
this prototype? :-D
Thanks,
René
diff --git a/git-cherry.sh b/git-cherry.sh
index 8832573..c88afc3 100755
--- a/git-cherry.sh
+++ b/git-cherry.sh
@@ -46,18 +46,29 @@ # not that the order in inup matters...
inup=`git-rev-list ^$ours $upstream` &&
ours=`git-rev-list $ours ^$limit` || exit
-tmp=.cherry-tmp$$
-patch=$tmp-patch
-mkdir $patch
-trap "rm -rf $tmp-*" 0 1 2 3 15
+is_in() {
+ what="$1"
+ while [ $# -gt 1 ]; do
+ shift
+ [ "$what" = "$1" ] && return 0
+ done
+ return 1
+}
+# prime patch-ID cache
+PATCH_ID_CACHE="$GIT_DIR/patch-ids"
+mkdir -p "$PATCH_ID_CACHE"
+for commit in $inup $ours; do
+ [ -f "$PATCH_ID_CACHE/$commit" ] && continue
+ set x `git-diff-tree -p $commit | git-patch-id`
+ echo "$2" >"$PATCH_ID_CACHE/$commit"
+done
+
+ids_inup=
for c in $inup
do
- git-diff-tree -p $c
-done | git-patch-id |
-while read id name
-do
- echo $name >>$patch/$id
+ read id <"$PATCH_ID_CACHE/$c"
+ ids_inup="$ids_inup $id"
done
LF='
@@ -66,10 +77,10 @@ LF='
O=
for c in $ours
do
- set x `git-diff-tree -p $c | git-patch-id`
- if test "$2" != ""
+ read id <"$PATCH_ID_CACHE/$c"
+ if test "$id" != ""
then
- if test -f "$patch/$2"
+ if is_in $id $ids_inup
then
sign=-
else
^ permalink raw reply related
* [ANNOUNCE] Stacked GIT 0.11
From: Catalin Marinas @ 2006-10-21 15:08 UTC (permalink / raw)
To: git, Linux Kernel Mailing List
Stacked GIT 0.11 release is available from http://www.procode.org/stgit/.
StGIT is a Python application providing similar functionality to Quilt
(i.e. pushing/popping patches to/from a stack) on top of GIT. These
operations are performed using GIT commands and the patches are stored
as GIT commit objects, allowing easy merging of the StGIT patches into
other repositories using standard GIT functionality.
The main features in this release:
* New 'float' command to bring a range patches to the top of the
stack. This command can also take a series file as a parameter,
allowing easy reordering of the patches
* Patch history support, accessible through the 'log [--graphical]' command
* Use the '..' syntax for patch ranges instead of ':'
* '--keep' option for 'pop' to preserve the local changes (useful to
add the modifications to a different patch)
* '--graphical' option for 'series' to invoke gitk instead of listing
the patches
* Automatically generate patch names for the 'import', 'pick' and
'uncommit' commands
* '--noreply' option for 'mail' to not send messages as replies to the
first one. This is useful for mailing lists filtering replies with a
different subject
* '--interactive' option for 'resolved' to invoke a graphical 3-way
merge tool (xxdiff or emacs)
* '--sign' and '--ack' options for 'refresh' to sign off or acknowledge a patch
* Diff colouring pager script added to the contrib directory
* Configurable low-level pull command (i.e. git-pull)
* '--auto' option for 'mail' to automatically cc the patch signers
* Debian package support files
* Bug fixes
Acknowledgements (generated with 'git shortlog'):
Catalin Marinas:
Do not use the pager when the output is empty
Get the patch name from the description
Add '--' to git-diff-index calls
Add a common function for reading template files
Automatically generate patch names for uncommit
Set the .txt extension to the StGIT commit message file
Use the ".." syntax for patch ranges
Use get-ref-list to get the commit parents
Add --keep option to pop
Allow empty commit messages
Add the --graphical option to series
Add patch history support
Add the --noreply option to 'mail'
TODO list update
Add the '--interactive' option to 'resolved'
Add --sign and --ack options to refresh
Fix the preserving of the local changes during pop
Add the diffcol.sh file to the contrib directory
Allow the git-pull command to be configurable
Add --auto option to 'mail'
Rearrange the patches with a given series file
Add Debian package support to StGIT
Release 0.11
Robin Rosenberg:
Fix the --cover option.
New command 'float' to move a patch to the top
Yann Dirson:
Add a --parent flag to "stgit pick".
--
Catalin
^ permalink raw reply
* New software uploaded by Cynthia on Oct 21 19:20:00 MSK 2006
From: Microsoft Software @ 2006-10-21 15:37 UTC (permalink / raw)
To: git
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit, Size: 6610 bytes --]
Cynthia has uploaded some new software for you!
Click here to view available updated software:
http://update.eroemka.com/?Cynthia
You may also want to check the manual pages for sio(4) for information
communications rate. On a USR Sportster 14,400 external modem, these
56:$2 = 1767990816
#include <sys/param.h>
libc. You can test this by running the Linux ldd on itself. Suppose
A router is a machine which forwards packets between two or more
See the Distributions menu for an estimation of how much free space
the operating system driver writers. It is by no means as smart as
register.
0xd8 read -
and for just one port - well, I think you've guessed already.
ethernet card, and be using ifconfig aliasing. The former is used if
use the Linux /proc filesystem (which is different from the optional
a local area network (Clone) route.
ctm_rmail program to unpack and apply them. You can actually use the
program you wish. The FreeBSD ports collection (see ``The Ports
echo 'killing pppd, PID=' ${pid}
in a package called a print job, which is sent to the LPD spooling
Basically, it's a directory tree that's been archived into a single
Try dialing into the system; be sure to use 8 bits, no parity, 1 stop
service you may consider allowing through, which comes from port
for efficient use of disk space and memory.
interfere with each other. One application crashing will not
Note: If you are having trouble building a kernel, make
rattan|line|diablo|lp|Diablo 630 Line Printer:\
6. Users, groups and security
fashion (or at all) if you post them only to one of the
inp 5 OK
[section for distributed patches -- can be empty]
Select the "fixit XXX" option. Insert the fixit.flp when prompted.
the official standard at hand:
through COM4 in the MS-DOS world. Note that if you have an
system; change the routed/gated startup parameters in /etc/netstart as
----- begin /etc/sliphome/slip.hosts -----
To see whether the LKM is loaded, run `modstat'.
the ports' private working directory (${WRKSRC}) and building it.
2. Turn off header pages (which are on by default) by inserting the sh
order to get your system up and running again, boot it only into
computer. The original install menu is displayed on the screen.
To prepare for installation from an MS-DOS partition, copy the files
Send mail to the FreeBSD-emulation mailing list <freebsd-
see if everything re-appears and works correctly.
even if the same printer is available from other hosts. The following
the contents of the FIFO are discarded.
or
5.4. Making Device Nodes
desired quota limits, the following command can be used to duplicate
rootfs 192.1.2.3:/rootfs/myclient
device mse0 at isa? port 0x23c tty irq 5 vector ms
Modern SCSI devices, particularly magnetic disks, support what is
status signals from the controller to the drive and vice-versa. The
/etc/sliphome/slip.hosts to find a matching line for the special user,
How do you handle other file formats, though?
this fashion. Each distribution should go into a subdirectory on the
the main FreeBSD distribution or the ports tree is a bad idea, and the
remove terminators from a device, carefully store them. You will need
};
input, which is the job to print. It then starts the PostScript
When the disk is in operation, the disk accesses are checked against
line 6:
11.4.7.2. Try Dialing In
versions are available to upgrade older SCSI host adapters. Some newer
effects when the serial connection is terminated.
#
spooling directory resides). It saves time as well since LPD
If you don't like this method, here's a completely different way of
You can combine lpr with the lptest program, introduced in section
/kernel -c
o Accessing a printer attached directly to a network. The printer
8.2. Setting quota limits
[janegrunt 10407] su
the ftp-URL ${MASTER_SITES}, which is set in the Makefile. It will
us go through the recommended steps to create the perfect port.
Do look at existing examples and the bsd.port.mk file before asking us
Many ports depend on other ports. There are five variables that you
Now we are ready to create the database. This only needs to run on the
return or CR). Many printers use the MS-DOS convention for repre-
in the discussion below. The first is your usual UNIX-style or
device ze0 at isa? port 0x300 net irq 5 iomem 0xd8000 vector
which you can include in your kernel but are not present in the
denied'' errors.
(abbreviation: st), magnetic disks (sd), cdroms (cd) etc. In case you
ISBN 0131510517
gzip -9nf ${PREFIX}/man/man1/xdl.1
one, until you have got all the distributions you want packed up in
inp 5 OK
Traditionally, a Baud Rate represents the number of bits that are
onto one or more additional physical lines.
When this script finishes, you will find that there are now wcd0c and
slip.hosts, which defines the SLIP users & their associated IP
system lets you control who can access a printer, both locally or
Ports Collection'' called pcemu which allows you to run many basic MS-
The lines beginning with a '#' sign are comments for the benefit of
/etc/hosts.equiv 15 bytes
running afoul of the law? We decided to take a dual-track approach:
tarball, is going to be something like:
fdformat -q fd0
and converting that into LaserJet/PCL-compatible data.
Zynx ZX342 or DEC DE435, will generally work as well. For 100Mbit
1 default:
o ftp.au.FreeBSD/pub/FreeBSD
and pass that data to the receiving DTE.
7 6 How many words are received
that is the kind of printer language for which we must make special
that shiny 2Gb disk: I own a system on which a pre-SCSI-1 disk, a
A common pitfall is to have an internal (flat)cable in a machine and
copies of each file in the job. Whether this is a good thing is up to
having set up principal jack with a null instance:
SCSI harddisks to a SCSI bus (e.g. an Emulex MD21 found in old Sun
To work around the 'slow response' problem, FreeBSD allows a tunable
7.6.5.1. Quick and Dirty Printer Accounting
The upshot of this is that I must force sendmail to re-examine the
appropriate mailing list you will reach both us and a concentrated
file and check messages on the console to track the problem
double-check that
New Password: <---- re-enter the password here
firewall entry.
The USR Sportster 14,400 external modem also has some DIP switches
hostname myclient.mydomain
echo "Usage: dds_changer [123456ne] raw-device-name
nameservers, and specifies some other information.
reboot to use your kernel. In case something goes wrong, there are
Some software distributions have attacked this problem by providing
^ permalink raw reply
* Re: [PATCH 2/2] Remove dead code after direct graph drawing
From: Josef Weidendorfer @ 2006-10-21 15:40 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <e5bfff550610202335rcb83ea8mf7ec2dd79ec6dd90@mail.gmail.com>
On Saturday 21 October 2006 08:35, you wrote:
> Josef,
>
> I think ther's a leak somewhere.
I am not really sure...
I just scrolled up and down through
the kernel repo with the page up/down keys (around 34K revisions).
On the first pass down, the memory increases by around 26 MB,
which could by correct, as you do setupData() lazy (no idea what
this function does...).
On the 2nd pass up again, I only get an increase of around 2 MB.
That could be other effects, as on further passes, I do not see
any change with pure scrolling.
> Checking memory use with ksysguard is see memory use going up
> scrolling up and down also on the same revisions list view subset.
>
> I'm not sure it depends on your patch though.
Can you compare with/without my patch?
I have no idea what could have introduced any leak here. I do not
create any new class instance / structures, but only get rid of pixmap
creations/deletions.
How did you check for leaks in the past?
Did you try valgrind (memcheck or massif)?
Josef
>
> Marco
>
>
^ permalink raw reply
* [PATCH 0/4] gitweb: Improving tree view (plus some cleanups)
From: Jakub Narebski @ 2006-10-21 15:50 UTC (permalink / raw)
To: git
This series of patches is road to patch introducing '..'
(up directory) link in "tree" view in gitweb; patches 1-3
corrects errors or inconistencies noticed in code generating
"tree" view.
Shortlog:
[PATCH 1/4] gitweb: Whitespace cleanup - tabs are for indent, spaces are for align (2)
[PATCH 2/4] gitweb: Do not esc_html $basedir argument to git_print_tree_entry
[PATCH 3/4] gitweb: Improve git_print_page_path
[PATCH 4/4] gitweb: Add '..' (up directory) to tree view if applicable.
Diffstat:
---
gitweb/gitweb.perl | 109 ++++++++++++++++++++++++++++++++--------------------
1 files changed, 68 insertions(+), 41 deletions(-)
--
Jakub Narebski
ShadeHawk on #git
Poland
^ permalink raw reply
* [PATCH 2/4] gitweb: Do not esc_html $basedir argument to git_print_tree_entry
From: Jakub Narebski @ 2006-10-21 15:53 UTC (permalink / raw)
To: git
In-Reply-To: <200610211750.49188.jnareb@gmail.com>
In git_tree, rename $base variable (which is passed as $basedir
argument to git_print_tree_entry) to $basedir. Do not esc_html
$basedir, as it is part of file_name ('f') argument in link and not
printed. Add '/' at the end only if $basedir is not empty (it is empty
for top directory) and doesn't end in '/' already.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
BUGFIX patch.
gitweb/gitweb.perl | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index c457884..209b318 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2834,7 +2834,7 @@ sub git_tree {
my $refs = git_get_references();
my $ref = format_ref_marker($refs, $hash_base);
git_header_html();
- my $base = "";
+ my $basedir = '';
my ($have_blame) = gitweb_check_feature('blame');
if (defined $hash_base && (my %co = parse_commit($hash_base))) {
my @views_nav = ();
@@ -2862,7 +2862,10 @@ sub git_tree {
print "<div class=\"title\">$hash</div>\n";
}
if (defined $file_name) {
- $base = esc_html("$file_name/");
+ $basedir = $file_name;
+ if ($basedir ne '' && substr($basedir, -1) ne '/') {
+ $basedir .= '/';
+ }
}
git_print_page_path($file_name, 'tree', $hash_base);
print "<div class=\"page_body\">\n";
@@ -2878,7 +2881,7 @@ sub git_tree {
}
$alternate ^= 1;
- git_print_tree_entry(\%t, $base, $hash_base, $have_blame);
+ git_print_tree_entry(\%t, $basedir, $hash_base, $have_blame);
print "</tr>\n";
}
--
1.4.2.1
^ permalink raw reply related
* [PATCH 3/4] gitweb: Improve git_print_page_path
From: Jakub Narebski @ 2006-10-21 15:53 UTC (permalink / raw)
To: git
In-Reply-To: <200610211750.49188.jnareb@gmail.com>
Add link to "tree root" (root directory) also for not defined name,
for example for "tree" action without defined "file_name" which means
"tree root".
Add " / " at the end of path when $type eq "tree".
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Consistency (and code simplification).
gitweb/gitweb.perl | 16 ++++++++--------
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 209b318..126cf3c 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1615,17 +1615,16 @@ sub git_print_page_path {
my $type = shift;
my $hb = shift;
- if (!defined $name) {
- print "<div class=\"page_path\">/</div>\n";
- } else {
+
+ print "<div class=\"page_path\">";
+ print $cgi->a({-href => href(action=>"tree", hash_base=>$hb),
+ -title => 'tree root'}, "[$project]");
+ print " / ";
+ if (defined $name) {
my @dirname = split '/', $name;
my $basename = pop @dirname;
my $fullname = '';
- print "<div class=\"page_path\">";
- print $cgi->a({-href => href(action=>"tree", hash_base=>$hb),
- -title => 'tree root'}, "[$project]");
- print " / ";
foreach my $dir (@dirname) {
$fullname .= ($fullname ? '/' : '') . $dir;
print $cgi->a({-href => href(action=>"tree", file_name=>$fullname,
@@ -1641,11 +1640,12 @@ sub git_print_page_path {
print $cgi->a({-href => href(action=>"tree", file_name=>$file_name,
hash_base=>$hb),
-title => $name}, esc_html($basename));
+ print " / ";
} else {
print esc_html($basename);
}
- print "<br/></div>\n";
}
+ print "<br/></div>\n";
}
# sub git_print_log (\@;%) {
--
1.4.2.1
^ permalink raw reply related
* [PATCH 1/4] gitweb: Whitespace cleanup - tabs are for indent, spaces are for align (2)
From: Jakub Narebski @ 2006-10-21 15:52 UTC (permalink / raw)
To: git
In-Reply-To: <200610211750.49188.jnareb@gmail.com>
Code should be aligned the same way, regardless of tab size.
Use tabs for indent, but spaces for align.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 60 ++++++++++++++++++++++++++--------------------------
1 files changed, 30 insertions(+), 30 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 035e85e..c457884 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1722,13 +1722,13 @@ sub git_print_tree_entry {
if ($t->{'type'} eq "blob") {
print "<td class=\"list\">" .
$cgi->a({-href => href(action=>"blob", hash=>$t->{'hash'},
- file_name=>"$basedir$t->{'name'}", %base_key),
- -class => "list"}, esc_html($t->{'name'})) . "</td>\n";
+ file_name=>"$basedir$t->{'name'}", %base_key),
+ -class => "list"}, esc_html($t->{'name'})) . "</td>\n";
print "<td class=\"link\">";
if ($have_blame) {
print $cgi->a({-href => href(action=>"blame", hash=>$t->{'hash'},
- file_name=>"$basedir$t->{'name'}", %base_key)},
- "blame");
+ file_name=>"$basedir$t->{'name'}", %base_key)},
+ "blame");
}
if (defined $hash_base) {
if ($have_blame) {
@@ -1740,8 +1740,8 @@ sub git_print_tree_entry {
}
print " | " .
$cgi->a({-href => href(action=>"blob_plain", hash_base=>$hash_base,
- file_name=>"$basedir$t->{'name'}")},
- "raw");
+ file_name=>"$basedir$t->{'name'}")},
+ "raw");
print "</td>\n";
} elsif ($t->{'type'} eq "tree") {
@@ -1809,7 +1809,7 @@ sub git_difftree_body {
print "<td>";
print $cgi->a({-href => href(action=>"blob", hash=>$diff{'to_id'},
hash_base=>$hash, file_name=>$diff{'file'}),
- -class => "list"}, esc_html($diff{'file'}));
+ -class => "list"}, esc_html($diff{'file'}));
print "</td>\n";
print "<td>$mode_chng</td>\n";
print "<td class=\"link\">";
@@ -1836,11 +1836,11 @@ sub git_difftree_body {
print " | ";
}
print $cgi->a({-href => href(action=>"blame", hash_base=>$parent,
- file_name=>$diff{'file'})},
- "blame") . " | ";
+ file_name=>$diff{'file'})},
+ "blame") . " | ";
print $cgi->a({-href => href(action=>"history", hash_base=>$parent,
- file_name=>$diff{'file'})},
- "history");
+ file_name=>$diff{'file'})},
+ "history");
print "</td>\n";
} elsif ($diff{'status'} eq "M" || $diff{'status'} eq "T") { # modified, or type changed
@@ -1861,8 +1861,8 @@ sub git_difftree_body {
}
print "<td>";
print $cgi->a({-href => href(action=>"blob", hash=>$diff{'to_id'},
- hash_base=>$hash, file_name=>$diff{'file'}),
- -class => "list"}, esc_html($diff{'file'}));
+ hash_base=>$hash, file_name=>$diff{'file'}),
+ -class => "list"}, esc_html($diff{'file'}));
print "</td>\n";
print "<td>$mode_chnge</td>\n";
print "<td class=\"link\">";
@@ -1873,19 +1873,19 @@ sub git_difftree_body {
print $cgi->a({-href => "#patch$patchno"}, "patch");
} else {
print $cgi->a({-href => href(action=>"blobdiff",
- hash=>$diff{'to_id'}, hash_parent=>$diff{'from_id'},
- hash_base=>$hash, hash_parent_base=>$parent,
- file_name=>$diff{'file'})},
- "diff");
+ hash=>$diff{'to_id'}, hash_parent=>$diff{'from_id'},
+ hash_base=>$hash, hash_parent_base=>$parent,
+ file_name=>$diff{'file'})},
+ "diff");
}
print " | ";
}
print $cgi->a({-href => href(action=>"blame", hash_base=>$hash,
- file_name=>$diff{'file'})},
- "blame") . " | ";
+ file_name=>$diff{'file'})},
+ "blame") . " | ";
print $cgi->a({-href => href(action=>"history", hash_base=>$hash,
- file_name=>$diff{'file'})},
- "history");
+ file_name=>$diff{'file'})},
+ "history");
print "</td>\n";
} elsif ($diff{'status'} eq "R" || $diff{'status'} eq "C") { # renamed or copied
@@ -1913,19 +1913,19 @@ sub git_difftree_body {
print $cgi->a({-href => "#patch$patchno"}, "patch");
} else {
print $cgi->a({-href => href(action=>"blobdiff",
- hash=>$diff{'to_id'}, hash_parent=>$diff{'from_id'},
- hash_base=>$hash, hash_parent_base=>$parent,
- file_name=>$diff{'to_file'}, file_parent=>$diff{'from_file'})},
- "diff");
+ hash=>$diff{'to_id'}, hash_parent=>$diff{'from_id'},
+ hash_base=>$hash, hash_parent_base=>$parent,
+ file_name=>$diff{'to_file'}, file_parent=>$diff{'from_file'})},
+ "diff");
}
print " | ";
}
print $cgi->a({-href => href(action=>"blame", hash_base=>$parent,
- file_name=>$diff{'from_file'})},
- "blame") . " | ";
+ file_name=>$diff{'from_file'})},
+ "blame") . " | ";
print $cgi->a({-href => href(action=>"history", hash_base=>$parent,
- file_name=>$diff{'from_file'})},
- "history");
+ file_name=>$diff{'from_file'})},
+ "history");
print "</td>\n";
} # we should not encounter Unmerged (U) or Unknown (X) status
@@ -2851,7 +2851,7 @@ sub git_tree {
# FIXME: Should be available when we have no hash base as well.
push @views_nav,
$cgi->a({-href => href(action=>"snapshot", hash=>$hash)},
- "snapshot");
+ "snapshot");
}
git_print_page_nav('tree','', $hash_base, undef, undef, join(' | ', @views_nav));
git_print_header_div('commit', esc_html($co{'title'}) . $ref, $hash_base);
--
1.4.2.1
^ permalink raw reply related
* [PATCH 4/4] gitweb: Add '..' (up directory) to tree view if applicable
From: Jakub Narebski @ 2006-10-21 15:54 UTC (permalink / raw)
To: git
In-Reply-To: <200610211750.49188.jnareb@gmail.com>
Adds '..' (up directory) link at the top of "tree" view listing,
if both $hash_base and $file_name are provided, and $file_name
is not empty string.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
This was meant to send as single patch...
gitweb/gitweb.perl | 24 ++++++++++++++++++++++++
1 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 126cf3c..c9e57f0 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2871,6 +2871,30 @@ sub git_tree {
print "<div class=\"page_body\">\n";
print "<table cellspacing=\"0\">\n";
my $alternate = 1;
+ # '..' (top directory) link if possible
+ if (defined $hash_base &&
+ defined $file_name && $file_name =~ m![^/]+$!) {
+ if ($alternate) {
+ print "<tr class=\"dark\">\n";
+ } else {
+ print "<tr class=\"light\">\n";
+ }
+ $alternate ^= 1;
+
+ my $up = $file_name;
+ $up =~ s!/?[^/]+$!!;
+ undef $up unless $up;
+ # based on git_print_tree_entry
+ print '<td class="mode">' . mode_str('040000') . "</td>\n";
+ print '<td class="list">';
+ print $cgi->a({-href => href(action=>"tree", hash_base=>$hash_base,
+ file_name=>$up)},
+ "..");
+ print "</td>\n";
+ print "<td class=\"link\"></td>\n";
+
+ print "</tr>\n";
+ }
foreach my $line (@entries) {
my %t = parse_ls_tree_line($line, -z => 1);
--
1.4.2.1
^ permalink raw reply related
* Re: VCS comparison table
From: Jan Hudec @ 2006-10-21 15:56 UTC (permalink / raw)
To: Aaron Bentley
Cc: Jakub Narebski, Matthieu Moy, bazaar-ng, Linus Torvalds,
Andreas Ericsson, Petr Baudis, Carl Worth, git
In-Reply-To: <453656F8.3000504@utoronto.ca>
On Wed, Oct 18, 2006 at 12:31:52PM -0400, Aaron Bentley wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Jakub Narebski wrote:
> > Aaron Bentley wrote:
> >
> >>Carl Worth wrote:
> >>>There are even more important reasons to prefer a series of
> >>>micro-commits over a mega-patch than just ease of merging.
> >>
> >>A bundle isn't a mega-patch. It contains all the source revisions. So
> >>when you merge or pull it, you get all the original revisions in your
> >>repository.
> >
> >
> > But what patch reviewer see is a mega-patch showing the changeset
> > of a whole "bundle", isn't it?
> > [...]
>
> Yes. Carl was saying that, aside from the issue of what a reviewer
> sees, a bundle is bad for other reasons. I am saying those other
> reasons don't apply. I wasn't addressing the issue of what a reviewer sees.
>
> To me, seeing the individual patches is like reading a book where every
> page has a different word on it, and so it's hard to put it together
> into a full sentence. I'm not saying my way is The Right Way, just my
> personal preference.
>
> For larger pieces of work, we try to split them up into logical units,
> and merge those units independently.
>
> The Bundle format can also support a patch-by-patch output, but we don't
> have UI to select that.
As for what the reviewer wants to see, I think it depends on what kind
of code it is. Kernel code is complex and does not have (at least I have
not heared of) unit-tests, so short patches are preferable for review.
And since C is of the more verbose languages, short patches mean
spliting them up into several pieces.
On the other hand bzr has unit-tests and python is less verbose, so the
single patch for a feature is not so big and is manageable. The patches
to bzr still come in logical steps, but usually one step per feature is
enough.
Also programmers usually don't develop even the single logical step as a
single commit. Instead they they also commit to backup their work,
when they try something they think they may in future return, when they
need to continue on another computer and so on. And these commits are
generally not logical steps. Also the steps are often not in a logical
order. Therefore showing diff for each commit in the bundle often does
not make sense.
So there is one bundle per logical step and therefore has a summary
diff. Individual bundles for individual steps are preferable anyway,
since the maintainer may decide to accept just some of them. A tool to
generate a series of bundles (either each with just one commit or each
with several commits) would be possible, just noone was interested
enough to do it yet.
--------------------------------------------------------------------------------
- Jan Hudec `Bulb' <bulb@ucw.cz>
^ permalink raw reply
* Re: less -F ubuntu dapper.
From: Sergey Vlasov @ 2006-10-21 16:01 UTC (permalink / raw)
To: Aneesh Kumar; +Cc: Git Mailing List
In-Reply-To: <cc723f590610210623sbee2075i5f2fd441cceb84ae@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2232 bytes --]
On Sat, 21 Oct 2006 18:53:35 +0530 Aneesh Kumar wrote:
> -F option for less in ubuntu Dapper is broken. It doesn't display
> anyting if the file can be displayed in one page.
Same here in ALT Linux (less-382-alt2). The problem appears only
when the terminal supports alternate screen, and less uses it.
BTW, try this (needs bash or zsh):
(for ((i=0; i < 20; ++i)) do echo $i; sleep 0.1; done) | less -F
You'll see that the text appears on the screen while the loop
outputs it, but disappears once the output finishes. If you use
"less -FX" instead, the text will not disappear, but in this case
less will not use the alternate screen, which is inconvenient when
the text is large (e.g., when you browse the text, parts of it
will be put into the scrollback buffer).
Because less must start displaying the text immediately after it
got some data, it cannot decide whether to use the alternate
screen depending on the text size. Therefore, if you want to use
the -F option on a terminal with alternate screen, you need to
turn off the alternate screen support with -X. But less cannot do
this automatically, because it does not really know about the
alternate screen (the -X option disables termcap initialization
and deinitialization strings, which can do arbitrary things, and
may actually be required on some obscure terminals).
It should be possible to add yet another option to less to make it
initially display the text on the alternate screen, and on EOF, if
the text fits on the screen, turn off the alternate screen,
_redisplay the text_ and exit. However, this option will have
even more assumptions about the terminal than -X (if the terminal
does not turn on alternate screen in its termcap initialization
string, there will be a horrible mess on screen), and you will get
flicker when the text is displayed multiple times.
> Because of this the recent chages to
> 96a035d1db9082d244867033020d0ceb571cf94e results in commands
> like git show not showing the changes.
Adding the -X option might break some terminals (and will irritate
users which used alternate screen before), so apparently the only
way to fix this breakage is to remove the -F option again...
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-21 16:13 UTC (permalink / raw)
To: Jan Hudec
Cc: Aaron Bentley, Matthieu Moy, bazaar-ng, Linus Torvalds,
Andreas Ericsson, Petr Baudis, Carl Worth, git
In-Reply-To: <20061021155624.GF29843@artax.karlin.mff.cuni.cz>
Jan Hudec wrote:
> Also programmers usually don't develop even the single logical step as a
> single commit. Instead they they also commit to backup their work,
In git you can backup your work on temporary branch; besides there
is git commit --amend to correct last commit.
> when they try something they think they may in future return, when they
> need to continue on another computer and so on. And these commits are
> generally not logical steps. Also the steps are often not in a logical
> order. Therefore showing diff for each commit in the bundle often does
> not make sense.
That is why before sending patch series based on some feature branch,
you should at least rebase the branch on top of current work, to ensure
that the series would apply cleanly.
If feature branch/patch series needs cleanup (going from "answer" to
"solution" http://lkml.org/lkml/2005/4/7/176), i.e. patch (commit)
reordering, joining two patches into one, patch splitting, you can
use git-cherry-pick, git-cherry-pick --no-commit and git commit --amend
combination, or git-format-patch, patch editing and reordering, and git-am.
Or just use StGit or pg.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: VCS comparison table
From: Erik Bågfors @ 2006-10-21 16:19 UTC (permalink / raw)
To: Sean
Cc: Jan Hudec, Linus Torvalds, bazaar-ng, git, Matthieu Moy,
Jakub Narebski
In-Reply-To: <BAYC1-PASMTP116A2EE9056E50B25534D5AE020@CEZ.ICE>
On 10/21/06, Sean <seanlkml@sympatico.ca> wrote:
> On Sat, 21 Oct 2006 16:13:28 +0200
> Jan Hudec <bulb@ucw.cz> wrote:
>
> > Bzr is meant to be used in both ways, depending on user's choice.
> > Therefore it comes with that infrastructure and you can choose whether
> > you want to use it or not.
>
> From what we've read on this thread, bzr appears to be biased towards
> working with a central repo. That is the model that supports the use of
> revnos etc that the bzr folks are so fond of. However Git is perfectly
> capable of being used in any number of models, including centralized.
> Git just doesn't make the mistake of training new users into using
> features that are only stable in a limited number of those models.
This is just plain wrong.
bzr is a fully decentralized VCS. I've read this thread for quite some
time now and I really cannot understand why people come to this
conclusion.
However, if you do want to work centralized, bzr has commands that
fits that workflow really good.
/Erik
--
google talk/jabber. zindar@gmail.com
SIP-phones: sip:erik_bagfors@gizmoproject.com
sip:17476714687@proxy01.sipphone.com
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-21 16:31 UTC (permalink / raw)
To: Erik Bågfors
Cc: Sean, Jan Hudec, Linus Torvalds, bazaar-ng, git, Matthieu Moy
In-Reply-To: <845b6e870610210919i6d086654g3881343e6a3c9f84@mail.gmail.com>
Erik Bågfors wrote:
> On 10/21/06, Sean <seanlkml@sympatico.ca> wrote:
>> On Sat, 21 Oct 2006 16:13:28 +0200
>> Jan Hudec <bulb@ucw.cz> wrote:
>>
>>> Bzr is meant to be used in both ways, depending on user's choice.
>>> Therefore it comes with that infrastructure and you can choose whether
>>> you want to use it or not.
>>
>> From what we've read on this thread, bzr appears to be biased towards
>> working with a central repo. That is the model that supports the use of
>> revnos etc that the bzr folks are so fond of. However Git is perfectly
>> capable of being used in any number of models, including centralized.
>> Git just doesn't make the mistake of training new users into using
>> features that are only stable in a limited number of those models.
>
> This is just plain wrong.
>
> bzr is a fully decentralized VCS. I've read this thread for quite some
> time now and I really cannot understand why people come to this
> conclusion.
>
> However, if you do want to work centralized, bzr has commands that
> fits that workflow really good.
Read carefully: bzr is _biased_ towards work with central repository.
Default workflow (as for example using revnos, as for example using
"merge" for one repository and "pull" for other) of bzr is geared
towards star topology, i.e. some centralized repository.
That to be said, it is supposed to be able to work in fully decentralized
way, using revids. But then for example you don't have "simple rev
namespace" (moreover you have _worse_ namespace than git's sha1 ids).
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: VCS comparison table
From: Erik Bågfors @ 2006-10-21 16:31 UTC (permalink / raw)
To: Jakub Narebski
Cc: Matthew D. Fuller, bazaar-ng, Linus Torvalds, Carl Worth,
Andreas Ericsson, git
In-Reply-To: <200610211608.18895.jnareb@gmail.com>
> There _are_ terminology conflicts. For example bzr "branch" is roughly
> equivalent to one-branch git "repository";
Agreed.
> bzr "repository" is just
> collection of branches sharing common storage,
Agreed
> which is similar to set
> of git "repositories" with .git/objects/ linked to common object
> repository (storage area) or appropriately set alternates file
> (although that is not common usage in git, and for example you would
> have to be carefull with running git-prune); bzr "lightweight checkout"
> is equivalent to nonexistent "lazy clone"/"remote alternates" discussed
> on git mailing list but not implemented because of performance
> concerns; bzr "normal checkout" is I think similar to git "shared
> clone" (but shared clone is limited to repositories on the same
> filesystem); bzr "heavyweight checkout" is roughly equivalent to
> one-branch-only "clone" in git or cg (cg = Cogito).
This is wrong. There are two kinds of checkouts
lightweight.. and "normal/heavyweight".
I think you are getting this alittle wrong, and I think the reason is
that you are thinking of repositories, while in bzr you normally think
of branches.
For example, I think (correct me if I'm wrong) that if I have a git
repository of a upstream linux-repo (Linus' for example). I guess
I'll use "pull" to keep my copy up to date with the upstream repo? If
I then would like to hack something special, I would "clone" the repo
and get a new repo and that's where I do my work. Is that correct?
In bzr you never (well...) clone a full repository, but you clone one
line-of-development (a branch). So "bzr branch" is always a
"one-branch-only "clone" in git or cg".
"bzr checkout" is a "bzr branch" followed by a setting saying
"whenever you commit here, commit in the master branch also".
"bzr checkout --lightweight" is a way to get only a snapshot of the
working tree out of a branch. Whenever you commit, it's done in the
remote branch.
/Erik
^ 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