* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-22 19:27 UTC (permalink / raw)
To: Matthew D. Fuller; +Cc: Carl Worth, bazaar-ng, git, Erik Bågfors
In-Reply-To: <20061022185350.GW75501@over-yonder.net>
On Son, Oct 22, 2006 Matthew D. Fuller wrote:
> On Sun, Oct 22, 2006 at 07:25:41AM -0700 I heard the voice of
> Carl Worth, and lo! it spake thus:
>>
>> git pull . mainline
>
> This throws me a little. I'd expect it to Just Do It when it's
> fast-forwarding, but if it's doing a merge, I'd prefer it to stop and
> wait before creating the commit, even if there are no textual
> conflicts. I realize you can just look at it afterward and back out
> the commit if necessary, but still...
Or you can use --no-commit option to git pull, and commit later.
But it is true that you can always amend the commit with
got commit --amend, even if the commit is merge.
>> Ah, I hadn't realized that bzr commits stored an "originating
>> branch" inside them.
>
> Every branch has a nickname, settable with 'bzr nick' (defaulting to
> whatever the directory it's in is), and that's stored as a text field
> in each commit. It's mostly cosmetic, but it's handy to see at a
> glance.
If I remember correctly Linus argued against it, because branch
name is something local to repository (most common example is
"mine 'master' is yours 'origin'").
There was proposal for "note" header for notes like merge algorithm
used, or branch name, visible only in 'raw' mode, but it wasn't
implemented.
>> The mainline..featureA syntax literally just means:
>>
>> the set of commits that are reachable by featureA
>> and excluding the set of commits reachable by mainline
>
> From what I can gather from this, though, that means that when I merge
> stuff from featureA into mainline (and keep on with other stuff in
> featureA), I'll no longer be able to see those older commits from this
> command. And I'll see merged revisions from branches other than
> mainline (until they themselves get merged into mainline), correct?
> It sounds more like a 'bzr missing --mine-only' than looking down a
> mainline in log...
That's true. That is what history viewers are for (gitk, qgit, tig,
gitview, git-show-branch, git-browser) are for.
And there is always reflog (if you enable it, of course).
^ permalink raw reply
* Re: VCS comparison table
From: David Clymer @ 2006-10-22 19:18 UTC (permalink / raw)
To: Jakub Narebski
Cc: Matthew D. Fuller, Andreas Ericsson, Linus Torvalds, Carl Worth,
bazaar-ng, git
In-Reply-To: <200610212141.51829.jnareb@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 9321 bytes --]
On Sat, 2006-10-21 at 21:41 +0200, Jakub Narebski wrote:
> Matthew D. Fuller wrote:
> > On Sat, Oct 21, 2006 at 04:08:18PM +0200 I heard the voice of
> > Jakub Narebski, and lo! it spake thus:
> >> Dnia sobota 21. października 2006 15:01, Matthew D. Fuller napisał:
>
> >> 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.
> >
> > This is obviously some new meaning of "centralization" bearing no
> > resemblance whatsoever to how I understand the word.
>
> Perhaps I'd better use "star topology bias" instead of "centralization
> bias".
>
> > In git, apparently, you don't give a crap about a branch's identity
> > (alternately expressible as "it has none"), and so you throw it away
> > all the time. Given that, revnos even if git had them would never be
> > of ANY use to you, so it's no wonder you have no use for the notion.
>
> In git branches are lightweight. Branch names are local to repository.
> Repositories have identity. Bzr "branch" is strange mix of one-branch
> git repository and git branch.
>
> Git main workflow is fully decentralized workflow. All clones of the
> same repository are created equal. In bzr the suggested workflow
> (with revnos) forces one (or more) branches to be mainline (use "merge",
> get empty-merges, revnos don't change) and leaf (use "pull", revnos
> change).
>
> > I DO give a crap about my branchs' identities. I WANT them to retain
> > them. If I have 8 branches, they have 8 identities. When I merge one
> > into another, I don't WANT it to lose its identity. When I merge a
> > branch that's a strict superset of second into that second, I don't
> > WANT the second branch to turn into a copy of the first. If I wanted
> > that, I'd just use the second branch, or make another copy of it. I
> > don't WANT to copy it. I just want to merge the changes in, and keep
> > on with my branch's current identity.
>
> I don't understand. If I merge 'next' branch into 'master' in git, I
> still have two branches: 'master' and 'next'.
>
> And I don't understand why you are so hung on branch identities. Yes, if
> somebody clones your 'repo' repository, he can have your 'master' branch
> (refs/heads/master) named 'repo' (refs/heads/repo) or 'repo/master'
> (refs/remotes/repo/master), but why that matters to you. It is _his_
> (or her ;-) clone.
>
I think you missed the point. Speaking for myself, I want to maintain
the identity of _my_ branches. If you clone one of them, I _don't_ care.
That's your branch. Branch identity as presented here is not intended to
be globally significant. It's locally significant.
> > Now, we can discuss THAT distinction. I'm not _opposed_ to git's
> > model per se, and I can think of a lot of cases where it's be really
> > handy. But those aren't most of my cases. And as long as we don't
> > agree on branch identity, it's completely pointless to keep yakking
> > about revnos, because they're a direct CONSEQUENCE of that difference
> > in mental model. See? They're an EFFECT, not a CAUSE. If bzr didn't
> > have revnos, I'd STILL want my branch to keep its identity. You could
> > name the mainline revisions after COLORS if you wanted, and I'd still
> > want my branch to keep its identity. Aren't we through rehashing the
> > same discussion about the EFFECTS?
>
> For revnos to work you MUST have one "branch" to be considered
> special, the hub in star topology. This very much precludes fully
> distributed development.
>
> BTW. I get that you can use revids in revnos in bzr for fully
> distributed and not star-topology geared development. But
> Bazaar-NG revids are uglier that Git commit-ids.
OK, just to clarify what you are saying here:
1. revnos don't work because they don't serve the same purpose as revids
or git's SHA1 commit ids.
2. bzr does not support fully distributed development because revnos
"don't work" as stated in #1.
3. Ok, bzr does support distributed development, I just say it doesn't
because I think revids are ugly.
Thus, revids are ugly.
Is this really the argument you want to be making? I'm not disagreeing
with you; it's just that I'm not sure it's relevant.
Can we just put the whole "revnos don't work" thing to rest?
Revnos are only intended to be significant relative to a given branch.
They are not intended to serve as an absolute, global identifier.
Revnos + a url _are_ globally significant, but are not static except in
certain topologies.
Revids are globally significant and static in any topology.
If a user does not like or cannot use revnos, they may use revids.
Revnos are not a tool to be used for every job. In no way does that mean
that they are broken.
If a given developer or group of developers primarily use revnos or
revids, it _may_ indicate that _they_ have a bias towards central (or
star) or distributed development, but does not necessarily have any
bearing on the capability of the VCS being used.
>
> [...]
> >> 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.
> >
> > If I don't tell you my branch has something in it ready to grab, you
> > shouldn't merge it. It probably won't work, and is quite likely to
> > set your computer on fire, slaughter and fillet your pet goldfish, and
> > make demons fly out of your nose. If you wanna get stuck with all my
> > incomplete WIP, let's just use a CVS module and be done with it.
>
> In git I can fetch your changes but I don't need to merge them. Take
> for example Junio 'pu' (proposed updates) branch: this is the branch
> you shouldn't merge as it's history is constantly being rewritten.
>
> If you don't want for your WIP to be publicly available, you don't
> publish it. For example as far as I understand Junio works on Git
> in his private repository, with many, many feature branches, but
> he does push to public [bare] repository only some subset of branches,
> and we can fetch/pull only those.
>
> But still, if I am impatient I can pull from Junio every hour, and
> I don't get 24 totally useless empty merge messages if he took day
> off and didn't publish any changes till day later.
>
> >> 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 [...]
> >
> > Funny, since this reads to me EXACTLY like the bzr flow of "upstream
> > branch I pull" and "my branch I merge from upstream" that's getting
> > kvetched around...
>
> But please, have you realized that in this workflow the two clones
> of the same repository are totally symmetrical? One's 'master' is
> another 'origin' and vice versa. After pull on one side, and pull
> on the other side (without any changes in between) we have the same
> contents, and the same revision names (commit-ids in git), even if
> the changes (revisions) got to those clones in different order.
> In bzr those two "branches" would get different revnos. No symmetry.
> Full distributed vs star topology (one branch "central", hence
> "centralized" - I don't mean need to access to one central repository,
> although...)
I think that when I attempt to pull from one branch to another, if they
are identical, neither branch changes. Merging + pulling results in
identical history, causing revnos on the pulling branch to change. Just
merging maintains divergent views of the same history.
Perhaps bzr has a central bias in the view that each developer has the
option of seeing their own branch as the central focus of his/her
development. This view would be the same from each branch; each
developer views his/her own branch as special. If the developer does not
want to view their own branch specially, they would merge + pull rather
than just merging. If I remember correctly, abentley covered this
earlier in this whole "VCS comparison table" thread.
Anyway, much of this seems to be a disagreement over the definition of
"distributed VCS." Perhaps this is too simplistic, but to my inexpert
eyes, these appear to be the positions of each side:
Bzr: Branches and all shared history may be stored locally in disparate
locations, and all VCS functions are available locally.
Git: Same thing, except that all shared history must also be identically
ordered.
Did I get that right?
In general, as a mere _user_ of distributed VCS, all I care about is if
I can accurately point you to a particular commit or set of commits, and
that you can access them either in shared history or in a given branch.
The fact that the VCS does not require a central branch and facilitates
code interchange, means to me that it is distributed. As long as all
major uses are fully supported, being slightly biased toward one use
case or another is not a distinction I consider to be worth making.
-davidc
--
gpg-key: http://www.zettazebra.com/files/key.gpg
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: VCS comparison table
From: Matthew D. Fuller @ 2006-10-22 18:53 UTC (permalink / raw)
To: Carl Worth; +Cc: Erik Bågfors, bazaar-ng, git, Jakub Narebski
In-Reply-To: <87zmbozau2.wl%cworth@cworth.org>
On Sun, Oct 22, 2006 at 07:25:41AM -0700 I heard the voice of
Carl Worth, and lo! it spake thus:
>
> git pull . mainline
This throws me a little. I'd expect it to Just Do It when it's
fast-forwarding, but if it's doing a merge, I'd prefer it to stop and
wait before creating the commit, even if there are no textual
conflicts. I realize you can just look at it afterward and back out
the commit if necessary, but still...
> Ah, I hadn't realized that bzr commits stored an "originating
> branch" inside them.
Every branch has a nickname, settable with 'bzr nick' (defaulting to
whatever the directory it's in is), and that's stored as a text field
in each commit. It's mostly cosmetic, but it's handy to see at a
glance.
> This special treatment influences or directly causes many of the
> things in bzr that we've been discussing:
[...]
> I've been arguing that all of these impacts are dubious. But I can
> understand that a bzr user hearing arguments against them might fear
> that they would lose the ability to be able to see a view of commits
> that "belong" to a particular branch.
Dead center.
> The mainline..featureA syntax literally just means:
>
> the set of commits that are reachable by featureA
> and excluding the set of commits reachable by mainline
>From what I can gather from this, though, that means that when I merge
stuff from featureA into mainline (and keep on with other stuff in
featureA), I'll no longer be able to see those older commits from this
command. And I'll see merged revisions from branches other than
mainline (until they themselves get merged into mainline), correct?
It sounds more like a 'bzr missing --mine-only' than looking down a
mainline in log...
> I haven't been able to find something similar in bzr yet. Does it
> exist?
The branch: (head) and ancestor: (latest common rev) revspecs let you
refer to the respective bits of other branches, which I think would
fill this role.
> It avoids a lot of the things in bzr that look so bizarre to people
> coming from git.
Well, what would be the fun in that? 8-}
--
Matthew Fuller (MF4839) | fullermd@over-yonder.net
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.
^ permalink raw reply
* [PATCH 2/2] Better installation instructions
From: Karl Hasselström @ 2006-10-22 18:46 UTC (permalink / raw)
To: Alexandre Julliard; +Cc: git
In-Reply-To: <20061022184108.4093.65651.stgit@localhost>
From: Karl Hasselström <kha@yoghurt.hemma.treskal.com>
Provide some more detailed installation instructions, for the
elisp-challenged among us.
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
contrib/emacs/vc-git.el | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/contrib/emacs/vc-git.el b/contrib/emacs/vc-git.el
index 1ec228f..535ce97 100644
--- a/contrib/emacs/vc-git.el
+++ b/contrib/emacs/vc-git.el
@@ -23,7 +23,10 @@
;; system.
;;
;; To install: put this file on the load-path and add GIT to the list
-;; of supported backends in `vc-handled-backends'.
+;; of supported backends in `vc-handled-backends'; the following line,
+;; placed in your ~/.emacs, will accomplish this:
+;;
+;; (add-to-list 'vc-handled-backends 'GIT)
;;
;; TODO
;; - changelog generation
^ permalink raw reply related
* [PATCH 1/2] ignore-errors requires cl
From: Karl Hasselström @ 2006-10-22 18:46 UTC (permalink / raw)
To: Alexandre Julliard; +Cc: git
In-Reply-To: <20061022184108.4093.65651.stgit@localhost>
From: Karl Hasselström <kha@yoghurt.hemma.treskal.com>
vc-git complains that it can't find the definition of ignore-errors
unless I (require 'cl). So I guess the correct place to do that is in
the file itself.
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
contrib/emacs/vc-git.el | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/contrib/emacs/vc-git.el b/contrib/emacs/vc-git.el
index 4189c4c..1ec228f 100644
--- a/contrib/emacs/vc-git.el
+++ b/contrib/emacs/vc-git.el
@@ -30,6 +30,8 @@
;; - working with revisions other than HEAD
;;
+(require 'cl)
+
(defvar git-commits-coding-system 'utf-8
"Default coding system for git commits.")
^ permalink raw reply related
* [PATCH 0/2] Two minor fixes for vc-git
From: Karl Hasselström @ 2006-10-22 18:41 UTC (permalink / raw)
To: Alexandre Julliard; +Cc: git
I'm a total newbie when it comes to elisp, so you may want to take
these with a pinch of salt. But vc-git was quite broken for me without
this fix, so I guess _something_ has to be done about it ...
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: Commit-ish shortcut for immediate parent range
From: Linus Torvalds @ 2006-10-22 18:25 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0610221017180.3962@g5.osdl.org>
On Sun, 22 Oct 2006, Linus Torvalds wrote:
>
> So the thing to do is just
>
> git show 3435fdb4c
>
> and be happy.
Btw, if you really _only_ want the diff, you can do either
git-diff-tree -p 3435fdb4c
which is the traditional "core" command for this. Somewhat sadly, I don't
think we have a way to actually turn _off_ the description printing, so
while you can turn off the _diff_ with "-s", the best you can do wrt the
commit message is probably to use "--pretty=oneline" to cut it down to a
single line.
I wonder if we should have a "--pretty=none" thing, so that you can use
the "higher-level" git commands without seeing the log message.
Hmm..
Linus
^ permalink raw reply
* Re: [PATCH 1/2] New stg command: assimilate
From: Karl Hasselström @ 2006-10-22 18:12 UTC (permalink / raw)
To: Petr Baudis; +Cc: Catalin Marinas, git
In-Reply-To: <20061022174308.GQ20017@pasky.or.cz>
On 2006-10-22 19:43:08 +0200, Petr Baudis wrote:
> Dear diary, on Sun, Oct 22, 2006 at 03:08:02PM CEST, I got a letter
> where Karl Hasselström <kha@treskal.com> said that...
>
> > Introduce an "assimilate" command, with no options. It takes any
> > GIT commits committed on top of your StGIT patch stack and
> > converts them into StGIT patches.
>
> Hmm, isn't this what stg uncommit does?
>
> Well, I'm not sure if what uncommit takes is from below the stack or
> above the stack, but if it's the former, it would still IMHO make
> more sense to just tell that StGIT with a switch or something.
Yes, you're correct in that uncommit and assimilate add existing
commits to the StGIT stack, but in different ends: uncommit grows the
stack by incorporating commits that precede it, while assimilate grows
the stack by incorporating commits that follows it.
The reason I decided to make a separate command is that the two
actions have different use cases: uncommit is for when you want to use
StGIT to manipulate commits that are already made; whereas assimilate
is for the case when you were happily using StGIT to manage a patch
series, and for whatever reason some regular GIT commits were made on
top of that stack, jamming any further StGIT manipulation.
The UIs are slightly different as a consequence: for uncommit, you
tell the command explicitly how many commits you want it to convert,
while assimilate will simply eat as much as it can (if it didn't,
there would still be git commits on top of your StGIT series, and it'd
still be jammed).
uncommit is really the opposite of commit. assimilate might just as
well have been called "fsck" or "cleanup".
Of course, my usability study had only one participant, and he was
rather biased since he's also the patch author, so this need not be
the final word on the matter.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH 1/2] New stg command: assimilate
From: Petr Baudis @ 2006-10-22 17:43 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Catalin Marinas, git
In-Reply-To: <20061022130802.17015.50188.stgit@localhost>
Dear diary, on Sun, Oct 22, 2006 at 03:08:02PM CEST, I got a letter
where Karl Hasselström <kha@treskal.com> said that...
> From: Karl Hasselström <kha@treskal.com>
>
> Introduce an "assimilate" command, with no options. It takes any GIT
> commits committed on top of your StGIT patch stack and converts them
> into StGIT patches.
Hmm, isn't this what stg uncommit does?
Well, I'm not sure if what uncommit takes is from below the stack or
above the stack, but if it's the former, it would still IMHO make more
sense to just tell that StGIT with a switch or something.
--
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: Commit-ish shortcut for immediate parent range
From: Linus Torvalds @ 2006-10-22 17:25 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200610221548.42048.andyparkins@gmail.com>
On Sun, 22 Oct 2006, Andy Parkins wrote:
>
> Git's commit-ish is very powerful. I was wondering however, if there was a
> shortcut for (for example)?
>
> git-diff 3435fdb4c^..3435fdb4c
>
> That is - the short range of a particular commit's parent to that commit; like
>
> git-diff 3435fdb4c!
Umm. That's not actually a very sensible operation. It's only sensible in
the special case of "diff", and for that special case, what we do is to
actually just say that the _command_ is special, not the range.
It's called "git show".
So the thing to do is just
git show 3435fdb4c
and be happy.
Anyway, there's two kinds of commands wrt revision ranges in git:
- "git diff"
- everything else
That may sound strange, but it's true. "git diff" doesn't really do
"revision ranges". It does "two revision endpoints", which is literally
very different from just about any other git command. All the other
commands really think of commits as a "set of individual commits" (where
sometimes the "set" is admittedly just a single commit).
So the reason for you wanting that "3435fdb4c^..3435fdb4c" is not that
it's a particularly useful thing in _general_, it's that "git diff" wants
two endpoints, and you want to have that describe a single commit.
Hopefully this explains why it's the _command_ that is special, and not
the range. The range makes no sense.
Linus
^ permalink raw reply
* Re: [PATCH] Build in shortlog
From: A Large Angry SCM @ 2006-10-22 17:22 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, junkio
In-Reply-To: <Pine.LNX.4.63.0610221322370.14200@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
[...]
> diff --git a/Makefile b/Makefile
> index 018dad2..0beda57 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -106,7 +106,7 @@ uname_P := $(shell sh -c 'uname -p 2>/de
>
> # CFLAGS and LDFLAGS are for the users to override from the command line.
>
> -CFLAGS = -g -O2 -Wall
> +CFLAGS = -g -O0 -Wall
> LDFLAGS =
> ALL_CFLAGS = $(CFLAGS)
> ALL_LDFLAGS = $(LDFLAGS)
> @@ -178,7 +178,7 @@ SCRIPT_SH = \
[...]
This part of your patch needs some explanation.
^ permalink raw reply
* Re: VCS comparison table
From: Linus Torvalds @ 2006-10-22 17:12 UTC (permalink / raw)
To: Tim Webster; +Cc: git, Aaron Bentley, bazaar-ng, Jakub Narebski
In-Reply-To: <72877ab10610220049i602ab936m11181f1a2daf2aee@mail.gmail.com>
On Sun, 22 Oct 2006, Tim Webster wrote:
> On 10/22/06, Linus Torvalds <torvalds@osdl.org> wrote:
> >
> > > project/file-1
> > > project/file-2
> > > project/.git-1
> > > project/.git-2
> >
> > Ok, that's just insane.
> [snip]
> > Anyway. Git certainly allows you to do some really insane things. The
> > above is just the beginning - it's not even talking about alternate object
> > directories where you can share databases _partially_ between two
> > otherwise totally independent repositories etc.
>
>
> Perhaps this is insane, but it does not make sense to track all config
> files in etc as though they belong in a single repo.
Oh, ok, now I see what you're going after.
Right - if you track system directories in a repo, you'd quite possibly
end up with multiple repositories. Although even then, I'd actually
suggest that as a git user, you would only have one actual repository, and
just multiple branches that have a disjoint set of files (again, it's
certainly possible to have file overlap too, of course).
But the usage I would seriously suggest is to _not_ do development "inside
/etc" itself. You'd have those git repositories somewhere else, say in
"/usr/src/etc-repo" or similar, and then you'd have a few extra wrappers
to help your particular usage. I have a few reasons for this:
- I think being in /etc and doing development is just fundamentally scary
in itself, because if you do something wrong in the current directory,
you're just pretty badly off. It's better to have a "buffer zone" that
you do development in, and when you're happy, you do a "install"
command or something.
- I think developing as "root" is totally broken, and some of the files
you are tracking may not even be _readable_ to normal users in their
real form, so you can't even do trivial things like "diff" as a normal
user otherwise. So again, the solution to this would be to do
development somewhere else, and have specific wrappers (with "sudo" as
appropriate, and your developer ID obviously specially in the sudo
files) to do those special "realdiff" and "install" commands.
- finally: when you work with almost any SCM designed for source control,
you're almost inevitably going to have to have some "special" way to
track the things that source control usually does _not_ track because
it makes no sense for source code. So you'd have to have some special
file that tracks ownership/group/full permissions information, and
perhaps special devices (if you're tracking things like /dev).
Again, the way to solve this would tend to be to have a few helper
scripts that use regular file-contents that _describe_ these things to
do "realdiff" and "install".
In other words, for at least three _totally_ different reasons, you really
don't want to do tracking/development directly in /etc, but you want to
have a buffer zone to do it. And once you have that, you might as well do
_that_ as the repository, and just add a few specialty commands (let's
call them "plugins" to make everybody happy) to do the special things.
And once you have that kind of setup, you're really better off with
more of a "several branches for different kinds of files" or even totally
different repositories. That's a detail, and I don't think anybody really
cares.
Anyway, to make this slightly more grounded in examples, let me give a
quick overview of what I'd do if I did this with git. Not a "real" setup
at all, but kind of a "maybe something like this" - so don't get _too_
hung up about the details, ok? It's just a rough draft kind of thing.
First off, let's just say that I want to track /etc/group, /etc/passwd and
/etc/shadow as one "thing". Whether that thing is a repository of its own
or a branch in a bigger repository doesn't matter (right now I'm only
doing those three), and quite frankly, I'm not going to even go into
whether it _really_ makes sense to track "groups" and the passwd files
together, but it's just an example, ok?
What I'd do is roughly:
# set up the new repo (or branch, or..)
mkdir identity-repo
cd identity-repo
git init-db
# copy the data, set up a PERMISSIONS file to track extra info
sudo cp /etc/group /etc/passwd /etc/shadow .
sudo chown user:user *
cat <<EOF > PERMISSIONS
group root:root 0644
passwd root:root 0644
shadow root:root 0400
EOF
git add .
git commit -m "Initial setup"
and now I have the initial setup, together with permissions and user/group
information on the things, all ready to track. I can do development in
this as if it was a normal source-code repository.
So now I can do "work work work commit commit commit" as if these files
were nothign special. What else do I need? I need the "plugins" to
actually expose (install) my work, and perhaps to check that /etc matches
what I expect (and nobody else did anything behind my back that I'd need
to merge).
Let's call them "install" and "realdiff" as I did above, ok?
And again, I'm not going to even claim that the above two "plugins" are
the right ones (maybe you want other operations too to interact with the
"real" installed files), and I'm not going to really get all the details
right, but here's kind of how you _might_ do it.
To create the script (let's make it shell, because that's what I'm used
to, but it could be anything) "git-install" in your git binary directory,
and make it do something like this:
#!/bin/sh
while read name chown chmod
do
cp $name $name.tmp &&
sudo chown $chown $name.tmp &&
sudo chmod $chmod $name.tmp &&
sudo mv $name.tmp /etc/$name
done < PERMISSIONS
and make it executable.
Now, you can work in your git directory, and when you're happy, you can do
git install
to actually copy it into the _real_ directory in /etc.
See? You can do something similar for "realdiff", that would compare the
contents in /etc with what you have now in your development tree (where
you want to script the thing to compare the PERMISSIONS file too).
And note: if you do the "plugin scripts" properly, they can work for _all_
your repositories that track different files in /etc. So you can work in
many different repos, and track different files in each, and "git install"
will do the right thing for each, regardless of the actual files you're
tracking.
Doesn't this sound like a workable situation? You get all the normal SCM
tools (looking at history etc), and there's only a few special things you
need to do when you actually want to install a specific version.
Btw: none of this is really "git-specific". The above tells you how to do
local "git plugins", and it's obviously fairly trivial, but I suspect any
SCM can be used in this manner.
Linus
^ permalink raw reply
* Re: VCS comparison table
From: Petr Baudis @ 2006-10-22 16:02 UTC (permalink / raw)
To: Carl Worth; +Cc: Jeff Licquia, Jakub Narebski, bazaar-ng, git
In-Reply-To: <8764ed1b7z.wl%cworth@cworth.org>
Dear diary, on Sun, Oct 22, 2006 at 01:49:04AM CEST, I got a letter
where Carl Worth <cworth@cworth.org> said that...
> Almost none of the power of git is exposed by gitweb. It's really not
> worth comparing. (Now a gitweb-alike that provided all the kinds of
> very easy browsing and filtering of the history like gitk and git
> might be nice to have.)
http://repo.or.cz/git-browser/by-commit.html?r=linux-2.6.git
It could use plenty of improvement, though.
--
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-22 15:50 UTC (permalink / raw)
Cc: bazaar-ng, git
In-Reply-To: <20061016035326.GA8654@hope.sourcefrog.net>
On 14 Oct 2006, Jakub Narebski <jnareb@gmail.com> wrote:
> Jon Smirl wrote:
>
>> It refers to this comparison chart between source control systems.
>> http://bazaar-vcs.org/RcsComparisons
>
> It is quite obvious that comparison of programs of given type (SMC)
> on some program site (Bazaar-NG) is usually biased towards said program,
> perhaps unconsciously: by emphasizing the features which were important
> for developers of said program.
There are also clashes with SCM terminology used differently by different
projects, which are sometimes couled with differences in philosophy,
and sometimes by different undestanding of given name.
For example "lightweight checkouts" and "normal/heavyweight checkout"
are from what I gather, is supporting "CVS/centralized model" and
"disconnected CVS model" (i.e. we can commit changes locally with
no network access, and we save local changes), at least when we
do "checkout" remotely and not on one local filesystem out-of-the-box.
^ permalink raw reply
* Re: Commit-ish shortcut for immediate parent range
From: Jakub Narebski @ 2006-10-22 15:11 UTC (permalink / raw)
To: git
In-Reply-To: <200610221548.42048.andyparkins@gmail.com>
Andy Parkins wrote:
> Git's commit-ish is very powerful. I was wondering however, if there was a
> shortcut for (for example)?
>
> git-diff 3435fdb4c^..3435fdb4c
Thats "git-diff 3435fdb4c^ 3435fdb4c" - diff need pair of things
(one or more might be implied/default), not DAG.
> That is - the short range of a particular commit's parent to that commit; like
>
> git-diff 3435fdb4c!
>
> Or similar.
Or similar. You have to use git-diff-tree, not git-diff as git-diff
uses working tree as second tree if second argument is not given
(and index as first tree if first argument is not given).
$ git diff-tree -p 3435fdb4c
(-p to show patch instead of "whatchanged" output) shows diff to parent
of commit 3435fdb4c (if commit is merge commit, show nothing; use -m
or -c or --cc then).
By the way 3435fdb4c.. means 3435fdb4c..HEAD, and ..3435fdb4c means
HEAD..3435fdb4c (where HEAD means current branch).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: VCS comparison table
From: Matthieu Moy @ 2006-10-22 15:05 UTC (permalink / raw)
To: Matthew D. Fuller; +Cc: Sean, bazaar-ng, git
In-Reply-To: <20061022145658.GV75501@over-yonder.net>
"Matthew D. Fuller" <fullermd@over-yonder.net> writes:
> On Sun, Oct 22, 2006 at 10:24:54AM -0400 I heard the voice of
> Sean, and lo! it spake thus:
>>
>> Light goes on. Okay. So a bzr "branch" is only ever editable on a
>> single machine. So there is no distributed development on top of a
>> bzr "branch". Everyone else just has read-only copies of it.
>
> Ah! Yes, that's exactly[0] right. Mark up another of those "so
> obvious we never think to state it" thought-patterns :|
Well, I'm not sure you talk about the same thing still. Adding my
2cents:
If ~/branch1 is a branch, I can get a read-write "copy" of it with
$ bzr branch ~/branch1 ~/branch2
which will roughly be equivalent to
$ cp -r ~/branch1 ~/branch2
Whether they are at this point "the same branch" or "two distinct
branches with same content" is just a matter of vocabulary since there
is no real "branch identity" AFAIK in bzr.
Now, if you commit in ~/branch1, then ~/branch2 is out of date with
it. If you commit also to ~/branch2, then you get two divergent
branches.
(and obviously, I could have done the same with branches in different
machines)
--
Matthieu
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-22 15:04 UTC (permalink / raw)
To: Erik Bågfors
Cc: Carl Worth, Jan Hudec, bazaar-ng, Linus Torvalds,
Andreas Ericsson, git
In-Reply-To: <845b6e870610220748q681984e8ld371c64a37b99544@mail.gmail.com>
Erik Bågfors wrote:
> On 10/22/06, Carl Worth <cworth@cworth.org> wrote:
>>
>> git log --no-merges mainline..featureA
>>
>> The mainline..featureA syntax literally just means:
>>
>> the set of commits that are reachable by featureA
>> and excluding the set of commits reachable by mainline
>>
[...]
>> And this syntax is almost universally accepted by git commands. so you
>> can visualize a chunk of the DAG with:
>>
>> gitk mainline..featureA
>>
>> Or export it as patches with:
>>
>> git format-patch mainline..featureA
>>
>> I haven't been able to find something similar in bzr yet. Does it
>> exist?
>
> If I understand you correctly, you'll get the same thing with "bzr missing".
>
> $ bzr missing ../mainline/
> You have 1 extra revision(s):
> ------------------------------------------------------------
> revno: 2
> committer: Erik Bågfors <erik@bagfors.nu>
> branch nick: newbranch
> timestamp: Sun 2006-10-22 16:43:10 +0200
> message:
> hepp
>
>
> You are missing 1 revision(s):
> ------------------------------------------------------------
> revno: 2
> committer: Erik Bågfors <erik@bagfors.nu>
> branch nick: mainline
> timestamp: Sun 2006-10-22 16:42:53 +0200
> message:
> hej
That is (roughly) equivalent of
$ git log mainline...featureA
(which would give all commits which are _either_ in mainline,
xor in featureA, although not separated; --topo-order might help), or
$ git show-branch mainline featureA
> You can also run "bzr missing" with "--theirs-only" or "--mine-only"
> to get only one way.
That would be equivalent of
$ git log mainline..featureA
(--theirs-only), or
$ git log featureA..mainline
(--mine-only).
> To get the patches you can run "bzr bundle ../mainline", but then
> we're back to the discussion that it currently gives a "big patch" for
> viewing, but when you merge it, you get each revision separately.
What about
$ gitk mainline..featureA
i.e. showing selected part of DAG in graphical history viewer?
And of course syntax is even more powerfull, e.g.
$ git log maint master --not next
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: VCS comparison table
From: Erik Bågfors @ 2006-10-22 14:48 UTC (permalink / raw)
To: Carl Worth
Cc: Jakub Narebski, Jan Hudec, bazaar-ng, Linus Torvalds,
Andreas Ericsson, git
In-Reply-To: <87zmbozau2.wl%cworth@cworth.org>
Thanks for this mail, this makes me happy to see. The tools are pretty
much the same but have some different view on how to do things..
On 10/22/06, Carl Worth <cworth@cworth.org> wrote:
>
> git log --no-merges mainline..featureA
>
> The mainline..featureA syntax literally just means:
>
> the set of commits that are reachable by featureA
> and excluding the set of commits reachable by mainline
>
> It's an extraordinarily powerful thing to say, and its exactly what
> you want here. And it's more than a "show mainline" thing, since
> theses sets of commits can consist of arbitrarily complex DAG
> subsets. This syntax is just a really useful way to slice up the DAG.
>
> And this syntax is almost universally accepted by git commands. so you
> can visualize a chunk of the DAG with:
>
> gitk mainline..featureA
>
> Or export it as patches with:
>
> git format-patch mainline..featureA
>
> I haven't been able to find something similar in bzr yet. Does it
> exist?
If I understand you correctly, you'll get the same thing with "bzr missing".
$ bzr missing ../mainline/
You have 1 extra revision(s):
------------------------------------------------------------
revno: 2
committer: Erik Bågfors <erik@bagfors.nu>
branch nick: newbranch
timestamp: Sun 2006-10-22 16:43:10 +0200
message:
hepp
You are missing 1 revision(s):
------------------------------------------------------------
revno: 2
committer: Erik Bågfors <erik@bagfors.nu>
branch nick: mainline
timestamp: Sun 2006-10-22 16:42:53 +0200
message:
hej
You can also run "bzr missing" with "--theirs-only" or "--mine-only"
to get only one way.
To get the patches you can run "bzr bundle ../mainline", but then
we're back to the discussion that it currently gives a "big patch" for
viewing, but when you merge it, you get each revision separately.
/Erik
^ permalink raw reply
* Re: VCS comparison table
From: Matthew D. Fuller @ 2006-10-22 14:56 UTC (permalink / raw)
To: Sean; +Cc: bazaar-ng, git
In-Reply-To: <20061022102454.b9dea693.seanlkml@sympatico.ca>
On Sun, Oct 22, 2006 at 10:24:54AM -0400 I heard the voice of
Sean, and lo! it spake thus:
>
> Light goes on. Okay. So a bzr "branch" is only ever editable on a
> single machine. So there is no distributed development on top of a
> bzr "branch". Everyone else just has read-only copies of it.
Ah! Yes, that's exactly[0] right. Mark up another of those "so
obvious we never think to state it" thought-patterns :|
Distributed development proper only happens on 'projects', not
branches. In practice, we say "we're all working on branch X", in the
sense that we use it as a base to work from and intend to merge our
stuff into it, but strictly speaking we're all working on our own
branches that just merge from/into X from time to time.
That's also why we use the phrases "merge from" and "merge to", rather
than "merge WITH". Of course, where possible, we could 'fast-forward'
to X rather than merge from it, at which point we'd then momentarily
have exactly X, but culturally we don't seem to like doing that.
[0] There are a few very special-case exceptions, notably around the
'checkout' concept or where people are very carefully manually
maintaining sync, but they're irrelevant in this case; and they ARE
star-pattern developments that could be said to be 'centralized'. Now
I grok where that's coming from.
--
Matthew Fuller (MF4839) | fullermd@over-yonder.net
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.
^ permalink raw reply
* [PATCH] Remove uneccessary strncmp call in imap-send count_messages
From: Andy Parkins @ 2006-10-22 14:53 UTC (permalink / raw)
To: git
The strncmp() call in count_messages() was doing the same comparison that
strstr() did, so there was no need to call it. A little rewrite and
count_messages() is simpler.
Obviously no huge benefit, as it's not frequently called. I'm just getting
familiar with git.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
imap-send.c | 13 ++++++-------
1 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/imap-send.c b/imap-send.c
index 16804ab..cfac17b 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -1198,15 +1198,14 @@ count_messages( msg_data_t *msg )
int count = 0;
char *p = msg->data;
- while (1) {
- if (!strncmp( "From ", p, 5 )) {
- count++;
+ while (p) {
+ p = strstr( p, "From " );
+ if ( p != NULL ) {
+ if ( p == msg->data || *(p-1) == '\n' ) {
+ count++;
+ }
p += 5;
}
- p = strstr( p+5, "\nFrom ");
- if (!p)
- break;
- p++;
}
return count;
}
--
1.4.2.3
^ permalink raw reply related
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-22 14:55 UTC (permalink / raw)
To: Carl Worth
Cc: Erik Bågfors, Jan Hudec, bazaar-ng, Linus Torvalds,
Andreas Ericsson, git
In-Reply-To: <87zmbozau2.wl%cworth@cworth.org>
Carl Worth wrote:
> Erik Bågfors wrote:
>> If I understand it correctly, in git, you don't really know what has
>> been committed as part of this branch/repo, and what has been
>> committed in another branch/repo (this is my understanding from
>> reading this thread, I might be wrong, feel free to correct me again
>> :) )
>
> You're correct that git doesn't _store_ any sort of "branch ownership"
> in the commit object. But this is a huge feature. It avoids a lot of
> the things in bzr that look so bizarre to people coming from git.
Because "branch ownership" is obvously local, we have reflog, which is
local and not propagated. Reflog uses the following format
oldsha1 SP newsha1 SP committer TAB reason LF
where reason might be "commit: <commit description/title/subject>"
or "commit (amend): <commit description>", "am: <commit
description>" (applied mail patch), "reset --hard HEAD^" (dropped
top commit), "branch: Created from origin^0", or "pull origin: In-index
merge".
We have not yet tools to examine reflog (e.g. change committer
info with it's timestamp to human readable format) yet.
--
Jakub Narebski
Poland
^ permalink raw reply
* Commit-ish shortcut for immediate parent range
From: Andy Parkins @ 2006-10-22 14:48 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 351 bytes --]
Hello,
Git's commit-ish is very powerful. I was wondering however, if there was a
shortcut for (for example)?
git-diff 3435fdb4c^..3435fdb4c
That is - the short range of a particular commit's parent to that commit; like
git-diff 3435fdb4c!
Or similar.
Andy
--
Dr Andrew Parkins, M Eng (Hons), AMIEE
andyparkins@gmail.com
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-22 14:39 UTC (permalink / raw)
To: Erik Bågfors
Cc: Jan Hudec, bazaar-ng, Linus Torvalds, Carl Worth,
Andreas Ericsson, git
In-Reply-To: <845b6e870610220711t8040a13g3dedbe18a2949ce1@mail.gmail.com>
Erik Bågfors wrote:
> On 10/22/06, Jakub Narebski <jnareb@gmail.com> wrote:
>> Erik Bågfors wrote:
>>> Jakub Narębski wrote:
>>
>>>> For example git encourages using many short and longer-lived feature
>>>> branches; I don't see bzr encouraging this workflow.
>>>
>>> Why not? I think it really does. And due to the fact that merges are
>>> merges and will show up as such, I think it's very suitable for
>>> feature branches.
>>
>> I think I haven't properly explained what "feature branch" means.
>> "Feature branch" is short (or medium) lived branch, created for
>> development of one isolated feature. When feature is in stable
>> stage, we merge feature branch and forget about it. We are not
>> interested in the fact that given feature was developed on given
>> branch. BTW. for example in published git.git repository are
>> only available in the form of "digest" 'pu' (proposed updates)
>> branch.
>
> That's what I'm talking about too.
> For example, in my bzr bzr-repo I have
> bzr.init-repo-tree/
> bzr.aliases/
> bzr.dev/
Due to the fact that git uses separate namespace for branch names,
and not position on filesystem, one would probably use 'dev'
(or 'master', or perhaps 'next'), 'aliases' and 'init-repo-tree'
as branch names. No need for 'bzr.' prefix to distingush
branches from other directories for user.
Git does use convention like above for bare repositories
(clones of repositories without working tree; working tree
is associated with repository, not with branch), e.g. git.git
or linux-2.6.18.y.git though.
> and others...
> In bzr.aliases for example, I built the support for defining aliases
> in the bzr config file. That was a unique feature that didn't exist in
> any other branch. The branch survived about 17 days before it was
> merged into bzr.dev. During that time, I merge in another branch
> twice. The branch I merged at this time was NOT bzr.dev, but rather
> another branch, from one of the main developers. The reason I merged
> his branch was that I needed a bugfix (or two? :) ) that he had done,
> but that wasn't approved in bzr.dev yet.
That is also quite common. Merging 'master' into feature branch,
or 'next' into feature branch. One could of course cherry-pick
only the bugfix... can you do this in bzr?
> After a time, his branch was merged into bzr.dev, shortly thereafter,
> so was my branch.
>
> After my branch was merged, I forgot about it. I still have it laying
> around on my computer because it really doesn't take up any extra
> space (since it's in a shared repository), but I really have forgotten
> about it.
Usually after feature branch is merged (or fast-forwarded) we delete
it. All the parentage information is in DAG anyway. We can later
attach new branch with the same name to the point where the branch was.
> This is typically how all features in bzr are created.
> Short/medium/long-lived feature branches.
Like I said, in git.git development we use development branches
(e.g. 'master', 'maint', 'next'), tracking branches (e.g. 'origin',
'linus'), feature branches (e.g. 'jc/pickaxe', 'np/pack'), "helper"
branches storing somewhat unrelated ('html' and 'man' branches for
autogenerated documentation) or unrelated ('todo' for TODO notes)
wtr. code stored to the main project, "digest" branches (e.g. 'pu'
branch in git.git, which is merge of WIP feature branches to be
published, and does not fast-forward), and temporary branches (for
example for shelving current work).
From long, to medium, to short, to extremly short lived.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: VCS comparison table
From: Matthieu Moy @ 2006-10-22 14:27 UTC (permalink / raw)
To: Jakub Narebski
Cc: Aaron Bentley, bazaar-ng, Jeff King, Linus Torvalds, Carl Worth,
Andreas Ericsson, git
In-Reply-To: <200610212020.08539.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> What about grandparent of commit (d8a60^^ or d8a60~2 in git),
> or choosing one of the parents in merge commit (d8a60^2 is second
> parent of a commit)? before:before:753 ?
Yes, "before:" can take any revision specifier, including
"before:something-else".
--
Matthieu
^ permalink raw reply
* Re: VCS comparison table
From: Erik Bågfors @ 2006-10-22 14:11 UTC (permalink / raw)
To: Jakub Narebski
Cc: bazaar-ng, Linus Torvalds, Andreas Ericsson, Carl Worth,
Jan Hudec, git
In-Reply-To: <200610221524.00408.jnareb@gmail.com>
On 10/22/06, Jakub Narebski <jnareb@gmail.com> wrote:
> Erik Bågfors wrote:
> > Jakub Narębski wrote:
>
> >> For example git encourages using many short and longer-lived feature
> >> branches; I don't see bzr encouraging this workflow.
> >
> > Why not? I think it really does. And due to the fact that merges are
> > merges and will show up as such, I think it's very suitable for
> > feature branches.
>
> I think I haven't properly explained what "feature branch" means.
> "Feature branch" is short (or medium) lived branch, created for
> development of one isolated feature. When feature is in stable
> stage, we merge feature branch and forget about it. We are not
> interested in the fact that given feature was developed on given
> branch. BTW. for example in published git.git repository are
> only available in the form of "digest" 'pu' (proposed updates)
> branch.
That's what I'm talking about too.
For example, in my bzr bzr-repo I have
bzr.init-repo-tree/
bzr.aliases/
bzr.dev/
and others...
In bzr.aliases for example, I built the support for defining aliases
in the bzr config file. That was a unique feature that didn't exist in
any other branch. The branch survived about 17 days before it was
merged into bzr.dev. During that time, I merge in another branch
twice. The branch I merged at this time was NOT bzr.dev, but rather
another branch, from one of the main developers. The reason I merged
his branch was that I needed a bugfix (or two? :) ) that he had done,
but that wasn't approved in bzr.dev yet.
After a time, his branch was merged into bzr.dev, shortly thereafter,
so was my branch.
After my branch was merged, I forgot about it. I still have it laying
around on my computer because it really doesn't take up any extra
space (since it's in a shared repository), but I really have forgotten
about it.
This is typically how all features in bzr are created.
Short/medium/long-lived feature branches.
/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