GIT vs Other: Need argument

GIT vs Other: Need argument

[Pietro Mascagni]

I am dealing with idiots. I'd rather not argue with them, but sadly I
cannot ignore them as they are my "seniors".

So, in 15 seconds, how does one argue that GIT is vastly superior to
other version control software, especially CVS.

Thanks,
P.

Re: GIT vs Other: Need argument

[Matthieu Moy]

"Pietro Mascagni" <pietromas@gmail.com> writes:

> So, in 15 seconds, how does one argue that GIT is vastly superior to
> other version control software, especially CVS.

Vs CVS, in 15 seconds, I'd say:

* Atomic commits. CVS makes it hard to get back to a consistant state
  in the past. What does it mean, for example to checkout revision 1.5
  of a project in CVS (hint: nothing, it's meaningfull for a file
  only).

* Rename management.

* Performance.

* Perhaps your boss will be interested in the "data integrity" (i.e.
  git fsck) problem too.

You have also the joker argument "Linus Torvalds is very intelligent,
and he gave up with CVS looong ago", but it might or might not work.

If you have to argue against SVN, you'll need more than 15
seconds ;-).

-- 
Matthieu

Re: GIT vs Other: Need argument

[Andy Parkins]

On Tuesday 2007 April 17 10:13, Matthieu Moy wrote:

> * Atomic commits. CVS makes it hard to get back to a consistant state
>   in the past. What does it mean, for example to checkout revision 1.5
>   of a project in CVS (hint: nothing, it's meaningfull for a file
>   only).
>
> * Rename management.
>
> * Performance.
>
> * Perhaps your boss will be interested in the "data integrity" (i.e.
>   git fsck) problem too.

Don't forget
 * Can work offline

-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com

Re: GIT vs Other: Need argument

[Alex Riesen]

On 4/17/07, Andy Parkins <andyparkins@gmail.com> wrote:
>
> Don't forget
>  * Can work offline
>

Bad argument with seniors. Being able to take your work home
considered security breach. Being able to work indepently of the
clueless technical support team considered inability to delegate
(like "pass the blame on").

This one is already tried with the described effect.

Re: GIT vs Other: Need argument

[Martin Langhoff]

On 4/17/07, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
> If you have to argue against SVN, you'll need more than 15
> seconds ;-).

 - Same branch/merge limitations as CVS: knows how to branch, not how
to merge :-/

 - Repository corruption / Berkeley DB

cheers,


martin

Re: GIT vs Other: Need argument

[Linus Torvalds]

On Tue, 17 Apr 2007, Matthieu Moy wrote:
> 
> * Perhaps your boss will be interested in the "data integrity" (i.e.
>   git fsck) problem too.

The data integrity thing is a lot more than just fsck.

I care a lot about my data, and it's an area where a *lot* of systems fall 
down. CVS is just about the worst (basically no checksums or sanity 
checking anywhere), and you can pretty much have total data corruption 
without ever even _realizing_, until you try to get some old version.

Even more interesting with CVS is that you can have total data corruption 
and you'll not realize it *even*as* you use the data. Lots of people and 
projects have been known to happily move *,v files around and edit the 
CVS repo files by hand to make things look right, which means that not 
only did you do a "rename" in CVS, you actually renamed *retroactively* 
too - you made history look wrong!

So with CVS, you actually have no guarantees what-so-ever that when you 
check out something old, you'll get what you actually used to have. You 
can tag things as much as you want - if people end up editing the CVS 
files (and people *do* that), you'll never have any indication that the 
history you checked out isn't the "real" history. So you can check out 
some old version that you made a release to a customer off, and may be 
totally unable to recreate the customer problem, because the release you 
checked out doesn't even compile any more!

You can actually do the same with most other SCM's. It may need somebody 
who is actually malicious, but even that isn't necessarily the case. Lots 
of SCM's don't have any checksums *at*all* on their data - the only way 
you'd ever know that something bad happened and you had disk corruption, 
is when you check something out and it just looks corrupted!

In other words, in a lot of SCM's, you're actually *lucky* if the 
corruption is so serious that it's not just a subtle "data is wrong" 
thing, it's so pervasive that you actually get an error from the SCM.

In git, every *single* piece of data is not just checksummed, it's 
CHECKSUMMED. Yeah, we use CRC's and Adler32 for some things, but even 
those are actually *also* protected at a higher level by real 
cryptographic hashes. You simply *cannot* corrupt data by mistake and not 
know about it. You can lose it, you can corrupt it, but it *will* be 
noticed.

If that doesn't make you feel good about your data, I don't know what 
will. Git will not replace backups in any way, shape, or form (although 
you can obviously use git itself to _do_ those backups - the joy of 
distributed SCMS), but it will tell you when you *need* those backups. 

Guaranteed.

And I can tell you that that is actually very rare. I doubt *any* 
commercial SCM will come even close. They might have checksums, but 
nothing really strong. It might be a CRC or even weaker. Or it might be 
nothing at all (and sadly, that's the *common* case).

				Linus

Re: GIT vs Other: Need argument

[Matthieu Moy]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> On Tue, 17 Apr 2007, Matthieu Moy wrote:
>> 
>> * Perhaps your boss will be interested in the "data integrity" (i.e.
>>   git fsck) problem too.
>
> The data integrity thing is a lot more than just fsck.

I have to revise my latin ;-). I meant _e. g._ git fsck, and the fact
that just given the full revision ID, you can make sure that both the
data and the history are uncorrupted is obviously a strong point for
data integrity, but not the only one (things like "add, don't replace"
policy is another).

-- 
Matthieu

Re: GIT vs Other: Need argument

[Martin Langhoff]

On 4/17/07, Pietro Mascagni <pietromas@gmail.com> wrote:
> So, in 15 seconds, how does one argue that GIT is vastly superior to
> other version control software, especially CVS.

Adding some ammunition:

 - Old school SCMs allow you to branch, but are unable to keep track
of merges in any meaningful way. Every time you merge, history is
lost. GIT (and other DSCMs) have excellent branching _and_ merging
facilities.

 - Speed (try it on you project repo, or if the project is new, on a
repo sized to what you'd expectyour project to be).

 - Disconnected development. Checkouts on your laptop, continue
working when the server is down.

 - Extremely powerful and flexible if you are using the SCM to manage
the deployment.

 - Behaves transactionally, even when doing things like applying patches

 - Anon GIT is much easier to run (via http)

 - If the team is large, of for any reason the code needs review, you
can setup a tiered review/merge scheme like the linux team does --
instead of a shared repo, each developer has their own repos, and
integrators review and merge (or reject!).

 - Signed tags for releases

And yet... If the project ends up using CVS, you can setup your
cvs->git gateway. Even if you are always at the office, and just use
CVS most of the time, It's enormously useful to be able to call gitk,
use pickaxe, etc. And just by having those tools around your project
will probably benefit.

cheers,


martin

Re: GIT vs Other: Need argument

[Alex Riesen]

On 4/17/07, Martin Langhoff <martin.langhoff@gmail.com> wrote:
>
>  - Old school SCMs allow you to branch, but are unable to keep track
> of merges in any meaningful way. Every time you merge, history is
> lost. GIT (and other DSCMs) have excellent branching _and_ merging
> facilities.
>

This one was a bad argument too. Curiously, and I cannot explain why,
ability to branch is considered a weakness of GIT ("because it confuses
the integrators", them being old mean men). The Perforce is said to
be "vastly superior to everything" on these grounds: "it also has
branching support, but luckily(!) it is hard enough for simple
developers. Was not their (Perforce's) fault, they just included it
to keep up with the market". Almost exact wording (I had to translate it).

Re: GIT vs Other: Need argument

[Dana How]

On 4/17/07, Alex Riesen <raa.lkml@gmail.com> wrote:
> On 4/17/07, Martin Langhoff <martin.langhoff@gmail.com> wrote:
> >  - Old school SCMs allow you to branch, but are unable to keep track
> > of merges in any meaningful way. Every time you merge, history is
> > lost. GIT (and other DSCMs) have excellent branching _and_ merging
> > facilities.
> This one was a bad argument too. Curiously, and I cannot explain why,
> ability to branch is considered a weakness of GIT ("because it confuses
> the integrators", them being old mean men). The Perforce is said to
> be "vastly superior to everything" on these grounds: "it also has
> branching support, but luckily(!) it is hard enough for simple
> developers. Was not their (Perforce's) fault, they just included it
> to keep up with the market". Almost exact wording (I had to translate it).

You are also trying to gain traction in a Perforce environment?
I'd be interested in any more details you might have;
I'm just starting.  Email me directly if you like.

Thanks,
-- 
Dana L. How  danahow@gmail.com  +1 650 804 5991 cell

Re: GIT vs Other: Need argument

[Alex Riesen]

On 4/25/07, Dana How <danahow@gmail.com> wrote:
> On 4/17/07, Alex Riesen <raa.lkml@gmail.com> wrote:
> > On 4/17/07, Martin Langhoff <martin.langhoff@gmail.com> wrote:
> > >  - Old school SCMs allow you to branch, but are unable to keep track
> > > of merges in any meaningful way. Every time you merge, history is
> > > lost. GIT (and other DSCMs) have excellent branching _and_ merging
> > > facilities.
> > This one was a bad argument too. Curiously, and I cannot explain why,
> > ability to branch is considered a weakness of GIT ("because it confuses
> > the integrators", them being old mean men). The Perforce is said to
> > be "vastly superior to everything" on these grounds: "it also has
> > branching support, but luckily(!) it is hard enough for simple
> > developers. Was not their (Perforce's) fault, they just included it
> > to keep up with the market". Almost exact wording (I had to translate it).
>
> You are also trying to gain traction in a Perforce environment?
> I'd be interested in any more details you might have;

Well, as I have failed on every attempt get the idea through,
I am not sure I _have_ any useful details which can be shared.
Right at this moment I'm working on importing/exporting scripts
which hopefully can impress my colleagues enough to use git
(P4 is almost universally hated). The problem is complicated
by the fact we have to use a homegrown program which replaces
"p4 sync" (as it is somewhat handicapped in its ability to specify
what revision of what part of a project to sync).
At the moment there 4 scripts: one to workaround the mentioned
tool (unrelated to git), one to put the data into index (must use
perforce to get the real names of the files, the local names
constantly get mangled by windows), one to commit the index
along with information about the clients state (mappings aka
client specification, revision lists and custom information this
dumb tool of ours needs) and one to export git changes.
All this is very loosely connected and integrated, so I can use
them independent of each other. This also means that there
is a lot of hand work to do, though. I can share the last three
scripts, if anyone interested (the first is of no use to anyone,
except me).

Re: GIT vs Other: Need argument

[Tomash Brechko]

On Tue, Apr 17, 2007 at 10:02:18 +0100, Pietro Mascagni wrote:
> So, in 15 seconds, how does one argue that GIT is vastly superior to
> other version control software, especially CVS.

I think you are not talking about choosing SCM for a new project, as
it is even _hard to imagine_ that one would consider CVS nowadays :).
And if you are trying to convince people to do the migration from CVS
to GIT, then technical points alone won't probably help you.  GIT, and
actually most modern SCMs, are superior to CVS not simply because they
have some CVS's features improved, and some nice features added.
Modern SCMs implement completely different workflow model.  GIT's own
power in its rich toolset, but until people learn (or at least are
willing to learn) what the workflow is, and how it is supported by
these tools, there's little advantage in migration.  You can't really
explain why 'git commit; git push' into some central repository is
better than 'cvs commit', and pushing after every commit is what
people will be doing at first ;).  You should also realize that the
whole process is probably already built around CVS (CVS-specific
hooks, scripts that access CVS, say, for nightly testing, etc), that
would also have to be reimplemented.

You may consider another route: create a GIT mirror of CVS repository,
and update it, say, daily, with git-cvsimport.  Clone from this
mirror, and work with your own GIT tree, pushing back to CVS with
git-cvsexportcommit.  Yes, you will be dealing with problems that
wouldn't be there in the first place if everyone would use GIT, and
you will basically use CVS workflow, but still, this way is quite
manageable.  Then approach the most promising guy in the company, and
explain to him how you benefit from using GIT (gitk/qgit, git-bisect,
StGIT are among your friends here :)).  As the saying goes, "Better to
see once, then to hear about a hundred of times".  You are not
interested in instant migration, and then being blamed if anything
would go wrong.  When you will grow sufficient number of GIT experts
in your company, then you will raise the migration question again.


Good luck!

-- 
   Tomash Brechko

Re: GIT vs Other: Need argument

[Guilhem Bonnefille]

I'm new to Git, but completly crazy of it.

In my point of view, in corporate team, lot of people does not
want/need the power offered by Git.
So, my conclusion is the better model in a corporate is a centralyzed
repo with some users using Git as "frontend". Other people will simply
use the native tools for accessing the repo.

I didn't try Git with CVS repo but seems less usable in day to day
work than a SVN repo with git-svn FANTASTIC tool.

So the problem is simply now: how to convince people to migrate from
CVS to SVN. This will be really less difficult as CVS and SVN are
quite similar.

On 4/17/07, Tomash Brechko <tomash.brechko@gmail.com> wrote:
> On Tue, Apr 17, 2007 at 10:02:18 +0100, Pietro Mascagni wrote:
> > So, in 15 seconds, how does one argue that GIT is vastly superior to
> > other version control software, especially CVS.
>
> I think you are not talking about choosing SCM for a new project, as
> it is even _hard to imagine_ that one would consider CVS nowadays :).
> And if you are trying to convince people to do the migration from CVS
> to GIT, then technical points alone won't probably help you.  GIT, and
> actually most modern SCMs, are superior to CVS not simply because they
> have some CVS's features improved, and some nice features added.
> Modern SCMs implement completely different workflow model.  GIT's own
> power in its rich toolset, but until people learn (or at least are
> willing to learn) what the workflow is, and how it is supported by
> these tools, there's little advantage in migration.  You can't really
> explain why 'git commit; git push' into some central repository is
> better than 'cvs commit', and pushing after every commit is what
> people will be doing at first ;).  You should also realize that the
> whole process is probably already built around CVS (CVS-specific
> hooks, scripts that access CVS, say, for nightly testing, etc), that
> would also have to be reimplemented.
>
> You may consider another route: create a GIT mirror of CVS repository,
> and update it, say, daily, with git-cvsimport.  Clone from this
> mirror, and work with your own GIT tree, pushing back to CVS with
> git-cvsexportcommit.  Yes, you will be dealing with problems that
> wouldn't be there in the first place if everyone would use GIT, and
> you will basically use CVS workflow, but still, this way is quite
> manageable.  Then approach the most promising guy in the company, and
> explain to him how you benefit from using GIT (gitk/qgit, git-bisect,
> StGIT are among your friends here :)).  As the saying goes, "Better to
> see once, then to hear about a hundred of times".  You are not
> interested in instant migration, and then being blamed if anything
> would go wrong.  When you will grow sufficient number of GIT experts
> in your company, then you will raise the migration question again.
>
>
> Good luck!
>
> --
>    Tomash Brechko
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


-- 
Guilhem BONNEFILLE
-=- #UIN: 15146515 JID: guyou@im.apinc.org MSN: guilhem_bonnefille@hotmail.com
-=- mailto:guilhem.bonnefille@gmail.com
-=- http://nathguil.free.fr/

Re: GIT vs Other: Need argument

[Andy Parkins]

On Tuesday 2007, April 17, Guilhem Bonnefille wrote:
> I'm new to Git, but completly crazy of it.
>
> In my point of view, in corporate team, lot of people does not
> want/need the power offered by Git.
> So, my conclusion is the better model in a corporate is a centralyzed
> repo with some users using Git as "frontend". Other people will
> simply use the native tools for accessing the repo.

Git has you covered there - it works better than other version control 
systems for that model too.  I do it all the time; the only difference 
is that with git it's not the tool doesn't force the choice on you.

If you want a central repo, just make one - designate one repository as 
central, put it in the .git/config file for each of the others and away 
you go.  Pretend it's centralised if you want; you and your colleagues 
need never know otherwise.

What's even better is that everything will also work faster, take less 
diskspace and be heavily backed up just by everyone doing their normal 
work.


Andy

-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com

Re: GIT vs Other: Need argument

[Shawn O. Pearce]

Andy Parkins <andyparkins@gmail.com> wrote:
> On Tuesday 2007, April 17, Guilhem Bonnefille wrote:
> > So, my conclusion is the better model in a corporate is a centralyzed
> > repo with some users using Git as "frontend". Other people will
> > simply use the native tools for accessing the repo.
> 
> Git has you covered there - it works better than other version control 
> systems for that model too.  I do it all the time; the only difference 
> is that with git it's not the tool doesn't force the choice on you.

Actually my day-job corporate repo is probably more secured in
Git than in PVCS Version Manager, even though every developer
has the entire history on their laptop.

Basically with PVCS users cannot save their work-in-progress very
well, so they copy files onto random network shares to make backups.
Our checked out tree is only about 120 MiB or so, but we have (and
I'm not kidding) over 3 GiB worth of various copies of the source
on an open network drive that anyone in the company can access, even
if they aren't authorized to view the source code of the product...

Now that developers have switched to Git, they have stopped making
those copies onto the network drive.  Why?  Simple, the network drive
copy takes longer (and more effort) than `git commit; git push`!
Users are all pushing to private branch spaces on the server, so
their work isn't merged until they really are ready for it, and
that server is backed up to secure tapes nightly, so all-in-all
its a much better situation.

-- 
Shawn.

Re: GIT vs Other: Need argument

[Marcin Kasperski]

Let me add some salt. At the moment, there are at least two immediate 
show-stoppers
for using git in many organizations:

a) Windows are unsupported
b) Learning curve is too steep. Unclear relationship git-vs-cogito makes 
it even worse.

Third is also very likely:

c) Lack of reasonable subproject support (plus detailed permission model).

 From tools similar to git, Mercurial performs significantly better (at 
least it works
on Win and is easy to learn, although some GUI would be needed in most cases
before it could be truly implemented).

PS I am in related pos, long years ago I introduced CVS to my org - 
replacing
CMS on VMS, RCS on Unix and manual copies on Win, now I am sensing 
possibilities, but...

PS2 I am not sure whether git aims to handle corporate cases, or even 
whether it should,
those remarks are addressed rather to those who consider using it in 
such situation, than
to those who wrote it.

Re: GIT vs Other: Need argument

[Johannes Schindelin]

Hi,

On Tue, 17 Apr 2007, Marcin Kasperski wrote:

> a) Windows are unsupported

Wrong.

> b) Learning curve is too steep. Unclear relationship git-vs-cogito makes it
> even worse.

Not so wrong. But then, it is clear that git is git is git. If you find it 
too complicated, soon enough somebody says "use cogito instead" and you'll 
find out about that.

> c) Lack of reasonable subproject support (plus detailed permission 
> model).

It is just being introduced into Git.

And we're back to Alex' point: if you want to make a feature a first class 
citizen, you have to invest a little energy in it. But experience shows 
that it _is_ possible to get something completely new into Git quite fast.

BTW the most striking argument pro Git I can think of is showing people 
how fast you can find out things. Like who wrote it, or more importantly 
_where_ the code is for a certain feature. Searching through `git log -p` 
is really fast, and it becomes even faster when you use "-Sblub".

And I really blew my audience away when I imported some CVS tracked 
project into Git, and showed all the features on that repository, 
_without_ much work.

I mean, you can do with CVS, SVN, HG, etc. almost the same as with Git. 
But with Git, I find it faster and easier. BTW much of that does come from 
the scriptable nature of Git. It _is_ much easier to write a short and 
simple script than to work on a plugin.

Ciao,
Dscho

Re: GIT vs Other: Need argument

[Linus Torvalds]

On Wed, 18 Apr 2007, Johannes Schindelin wrote:
> 
> On Tue, 17 Apr 2007, Marcin Kasperski wrote:
> > 
> > a) Windows are unsupported
> 
> Wrong.

It's a bit more work to set up though, and it has a lot less mindshare, 
and testing, obviously.

So yes, windows is a step-child. I'd love for it to not be one, and we'll 
get there, but it's clearly not as supported as the unix side. We still 
use a fair number of shell scripts (which in turn use unix commands and 
pipelines).

We'll get away from it. I think GSoC will help here.

> > b) Learning curve is too steep. Unclear relationship git-vs-cogito makes it
> > even worse.
> 
> Not so wrong. But then, it is clear that git is git is git. If you find it 
> too complicated, soon enough somebody says "use cogito instead" and you'll 
> find out about that.

Actually, at this stage, I really think cogito just *complicates* git 
usage. It hasn't been well-supported lately, and asking for help with 
cogito means that a lot of people can't help you. And you still end up 
using git commands for anything fancier.

So I don't think it's even true that new people should be pointed at cg 
any more.

What _is_ true is that git is simply different from CVS. I don't think 
it's necessarily harder to understand or use (in fact, I would argue that 
git is a lot _easier_ to understand), but it is *different*, and it has a 
ton more capabilities.

But compare setting up a git repository with setting up a CVS repository.
With git, it's literally "git init", and you're done. No need to worry 
about CVSROOT issues etc. Everything is self-contained. CVS is *hard* to 
get into, by comparison.

But being different means that *if* you already know CVS, you actually 
have a lot of unlearning of idiotic and bad habits, _and_ you need to 
learn that things that were so hard and scary under CVS that you either 
never learnt them, or quickly learnt to avoid ("branches" and "merging") 
are just so _easy_ under git, that they are discussed in the very first 
chapters of "getting started".

I can pretty much guarantee that 95% of all CVS users have never done a 
branch or a merge, even if they have used it for *years*. And yet, in git, 
we kind of take both of those for granted, and make them visible pretty 
much from day one. 

Git is just *easier*. But it is also different, and people are used to 
things being so hard that you'd never use them.

In a CVS world, you never even *need* to learn about branches and merging, 
because no normal user is ever actually expected to use either. In 
contrast, in the git world, pretty much every project uses multiple 
branches, and you are introduced to them at a minimum as the "origin" 
branches even for projects that just have one. So you're getting all these 
concepts that were so hard in CVS that you never ever even learnt to do 
them!

So people coming from CVS/SVN have a double shock: they are supposed to 
learn things that they "know" are hard (because CVS/SVN made them so damn 
hard - don't tell me that SVN branching is easy, because it is *not* easy. 
It may be cheaper to create a branch, but it has _all_ the same idiocies 
that CVS has once it's created). And on top of that, they have to re-learn 
something new.

So I really don't think cogito is the answer any more. The answer simply 
is: you have to learn that branches are *simple*. That's a big hurdle for 
some people. It's not the learning part that is hard, it's the 
*unlearning*. CVS/SVN has taught people that some things are complicated, 
and git uses those "complicated" things every day.

People who come from a CVS background would be *shocked* to learn that I 
do multiple merges a day. In fact, in the two years we've used git, we've 
had 3300 merges - and that's just counting the *nontrivial* ones that 
didn't just fast-forward. That's roughly an *average* of 4.5 merges a day. 
EVERY DAY. For two years.

In the CVS/SVN kind of mindset, a merge is something you do once a month, 
and you gird your loins for it. And it's usually just an expert, and only 
used for complex projects. A normal user would _never_ do a merge!

			Linus

Re: GIT vs Other: Need argument

[Nicolas Pitre]

On Wed, 18 Apr 2007, Linus Torvalds wrote:

> Actually, at this stage, I really think cogito just *complicates* git 
> usage. It hasn't been well-supported lately, and asking for help with 
> cogito means that a lot of people can't help you. And you still end up 
> using git commands for anything fancier.

Maybe someone should nuke the prominent mention of Cogito at the top of 
http://www.kernel.org/git/ then, and replace it with the appropriate Git 
equivalent.


Nicolas

Re: GIT vs Other: Need argument

[Bill Lear]

On Wednesday, April 18, 2007 at 09:07:55 (-0700) Linus Torvalds writes:
>...
>Actually, at this stage, I really think cogito just *complicates* git 
>usage. ...

As a relative newbie to git, I agree.  At our company, we did not even
seriously consider using cogito.  Just easier to jump right in to the
frosty waters.

>What _is_ true is that git is simply different from CVS. I don't think 
>it's necessarily harder to understand or use (in fact, I would argue that 
>git is a lot _easier_ to understand), but it is *different*, and it has a 
>ton more capabilities.

Well, differences can lead to difficulties.

Here are a few of the differential difficulties we have faced:

1) There seems to be an innate desire on our part to just "update this
branch from that one on that repository".  We have been caught several
times pulling onto the wrong branch, pushing onto the wrong one,
because we assumed the behavior of push/pull was "update this branch,
the one I am on right now, and ONLY this branch", but what we got was
a cross-branch merge.  Coming from a CVS background, and there not
having "undo" very easy, this caused severe stress.  Easy enough to
undo, once we understood, but does not obviate the stress.

2) Addressing of branches.  When to use bare 'git pull/push', when to
use 'git pull/push branch' when to use 'git pull/push branch:branch',
have been continually confusing to us.

3) Funkiness of non-bare repos ---- we really got stung trying to push
into one.  Seemed like it took us days to figure out what was going
on.

4) Near disaster using git with ssh to push to our company repo.  In
our company, we have a very loosy-goosy IT group.  We started using
git with ssh and had serious permissions problems.  If we had used the
git protocol from the start, that would have avoided this mess, but
support for that came too late.

Git has gotten much better than when we started with it just at the
beginning of this year.  Remote support, branch tracking, lots of
stuff has gotten much, much better.

I could go on and on about the good things, but it is important to
caution --- not frighten --- newbies with tales from others who have
been stung.


Bill

Re: GIT vs Other: Need argument

[Matthieu Moy]

Bill Lear <rael@zopyra.com> writes:

> On Wednesday, April 18, 2007 at 09:07:55 (-0700) Linus Torvalds writes:
>>...
>>Actually, at this stage, I really think cogito just *complicates* git 
>>usage. ...
>
> As a relative newbie to git, I agree.  At our company, we did not even
> seriously consider using cogito.  Just easier to jump right in to the
> frosty waters.

Same for me.

As a beginner, I went to http://git.or.cz/, clicked "crash courses",
and since I didn't find "git from scratch", I clicked "git for CVS
users" (I know CVS, but haven't used it for a long time, I'm mostly a
bzr user converted from GNU Arch).

There, the commands are not "git something", but "cg something". Well,
not always, at least. Indeed, there's still a "git blame", a reference
to "git-rev-parse manpage".

Then, I can't even find it in the tutorial, but somewhere, it should
be mentionned to say who I am in ~/.gitconfig.

So, Cogito can not be seen as "a revision control, using git as a
back-end". It's definitely an additional layer, not hiding all of git.

And then, comming to the mailing list, and looking at other websites,
I can see git commands here and there. I started to manage branches
using cogito, tried git commands related to branches, and realized
that they used a totally different interface.

So, cogito has probably been of a real use at the beginning, where git
was said to be almost unuseable without anything else (I didn't try
git at that time), but I don't think it's the case anymore.

-- 
Matthieu

Re: GIT vs Other: Need argument

[Nicolas Pitre]

On Wed, 18 Apr 2007, Matthieu Moy wrote:

> Then, I can't even find it in the tutorial, but somewhere, it should
> be mentionned to say who I am in ~/.gitconfig.

One of the very first thing you can find in Documentation/tutorial.txt 
is:

	It is a good idea to introduce yourself to git with your name and
	public email address before doing any operation.  The easiest
	way to do so is:

	------------------------------------------------
	$ git config --global user.name "Your Name Comes Here"
	$ git config --global user.email you@yourdomain.example.com
	------------------------------------------------


Nicolas

Re: GIT vs Other: Need argument

[Matthieu Moy]

Nicolas Pitre <nico@cam.org> writes:

> On Wed, 18 Apr 2007, Matthieu Moy wrote:
>
>> Then, I can't even find it in the tutorial, but somewhere, it should
>> be mentionned to say who I am in ~/.gitconfig.

I was talking about the "Git for CVS users" crash course, which is the
one I was naturally pointed to looking for documentation.

> One of the very first thing you can find in Documentation/tutorial.txt 
> is:

This tutorial should _really_ be advertized better on
http://git.or.cz/. Probably in the frame "crash courses", and on
http://git.or.cz/course/index.html

Indeed, most of the content of http://git.or.cz/#documentation should
also appear on http://git.or.cz/course/index.html IMHO.

That's a detail, but once you've clicked "Git crash course", the
tutorial is not reachable anymore.

(all that said, I think the documentation has already greatly improved
since I started a few weeks ago. Continue the good job!)

-- 
Matthieu

Re: GIT vs Other: Need argument

[Petr Baudis]

On Thu, Apr 19, 2007 at 03:16:32PM CEST, Matthieu Moy wrote:
> Nicolas Pitre <nico@cam.org> writes:
> > One of the very first thing you can find in Documentation/tutorial.txt 
> > is:
> 
> This tutorial should _really_ be advertized better on
> http://git.or.cz/. Probably in the frame "crash courses", and on
> http://git.or.cz/course/index.html
> 
> Indeed, most of the content of http://git.or.cz/#documentation should
> also appear on http://git.or.cz/course/index.html IMHO.
> 
> That's a detail, but once you've clicked "Git crash course", the
> tutorial is not reachable anymore.

I have added the tutorial to the crash course section, but it should
somehow integrated to the website... I wonder if that's easily possible
without getting out of sync. I've also clearly labelled the CVS/SVN
crash courses to be Cogito-focused. I'll wait for list feedback in order
to decide what to do with them further.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Ever try. Ever fail. No matter. // Try again. Fail again. Fail better.
		-- Samuel Beckett

Re: GIT vs Other: Need argument

[Matthieu Moy]

Petr Baudis <pasky@suse.cz> writes:

> I have added the tutorial to the crash course section, but it should
> somehow integrated to the website...

While you're there, the homepage still points to 1.5.1 while 1.5.1.1
is the latest.

-- 
Matthieu

Re: GIT vs Other: Need argument

[Theodore Tso]

On Wed, Apr 18, 2007 at 07:43:05PM +0200, Matthieu Moy wrote:
> As a beginner, I went to http://git.or.cz/, clicked "crash courses",
> and since I didn't find "git from scratch", I clicked "git for CVS
> users" (I know CVS, but haven't used it for a long time, I'm mostly a
> bzr user converted from GNU Arch).
> 
> There, the commands are not "git something", but "cg something". Well,
> not always, at least. Indeed, there's still a "git blame", a reference
> to "git-rev-parse manpage".
> 
> Then, I can't even find it in the tutorial, but somewhere, it should
> be mentionned to say who I am in ~/.gitconfig.

Yeah, one of the biggest source of confusion is that a lot of the
resources available on http://git.or.cz refers very heavily to cg, but
most of the discussion on the git mailing list doesn't involve using
cg, and as some have argued, it's not clear cg is very useful; at this
point, given the advances in git's usability in the 1.5 series.

So what I normally tell new users is to *not* look at
http://git.or.cz, since more than once people have taken off points on
git's usability because of the fact that some of the tutorials (in
particular the "git for CVS users") are really talkinga about cogito,
not git, and this gets highly confusing for many new users.

Instead, I tell people they should look at this:

	http://www.kernel.org/pub/software/scm/git/docs/

... and reference the tutorials off of this site.  It seems to me that
the documentation and tutorials on this site tends to get update much
more frequently and religiously than the resources on http://git.or.cz
--- although there is still some good stuff there that isn't
elsewhere.  But unfortunately, for a new user, the fact that they have
to filter out information that might be out of date, or
cogito-specific, from what is relevant, makes it such that I can't
really recommend that site to new users.

> So, cogito has probably been of a real use at the beginning, where git
> was said to be almost unuseable without anything else (I didn't try
> git at that time), but I don't think it's the case anymore.

Yep; and unfortunately, at this point, using cg probably is more
confusing compared to just simply using raw git all by itself.

						- Ted

Re: GIT vs Other: Need argument

[Guilhem Bonnefille]

On 4/18/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> What _is_ true is that git is simply different from CVS. I don't think
> it's necessarily harder to understand or use (in fact, I would argue that
> git is a lot _easier_ to understand), but it is *different*, and it has a
> ton more capabilities.

Yes, but I think that, as Git has ton more capabilities, user has to
understand more things than with CVS.

I don't know lot of corporate teams, but here, our developers are
REALLY not motivated by VCS. It's only a way to share work. And I'm
not talking about concurrent modification: lot of people in my office
really think that the better model is the locked one.
These people won't be the guy who set up the repo. These people only
expect a system to:
- retrieve and merge the job done by other people
- archive their job for other people.
Nothing more. No interest for topic branches (they are simple minded
;-)), no interest for data integrity (it's "not their job"),
interested in problem with connected system ("hey, CVS server is down,
would you like a coffee while waiting IT detects that ?")...

So for such people, I really think raw Git is much more complicated
than CVS/SVN.

-- 
Guilhem BONNEFILLE
-=- #UIN: 15146515 JID: guyou@im.apinc.org MSN: guilhem_bonnefille@hotmail.com
-=- mailto:guilhem.bonnefille@gmail.com
-=- http://nathguil.free.fr/

Re: GIT vs Other: Need argument

[Linus Torvalds]

On Wed, 18 Apr 2007, Guilhem Bonnefille wrote:
> 
> Yes, but I think that, as Git has ton more capabilities, user has to
> understand more things than with CVS.

I do agree.

The whole "branch" thing is something you can ignore in CVS, but it's 
simply very hard to ignore in git, because even *if* you just follow 
another repository, git kind of forces you to be aware of the difference 
between "local branch" and "remote tracking branch".

I think that's fairly fundamental to being distributed, though. 

> I don't know lot of corporate teams, but here, our developers are
> REALLY not motivated by VCS. It's only a way to share work. And I'm
> not talking about concurrent modification: lot of people in my office
> really think that the better model is the locked one.

Sure. At one level they may even be right. It's just that the locked model 
obviously doesn't work past a certain scenario. But explaining that to 
somebody who doesn't even think outside his own scenario is pointless.

So no question: git has a level of abstraction and perhaps requires a 
higher-level view than RCS and CVS do. And I can well imagine that it is 
seen as more "difficult" because of that.

I just haev to say that I worked with CVS at a commercial company for 
seven years, and I *did* do things like branches and merges etc, and 
despite workign with it at that level (not that I was the expert by any 
means: we had a person who came in with the main job literally being the 
tools around CVS to make branching more convenient etc), I seriously feel 
that CVS was a *lot* harder to get into than it is to get into git.

> So for such people, I really think raw Git is much more complicated
> than CVS/SVN.

I do wonder what we could do about that. I think you can use git in the 
"SVN tracker only" model, and I really thought it was pretty damn simple, 
but ...

		Linus

Re: GIT vs Other: Need argument

[Daniel Barkalow]

On Wed, 18 Apr 2007, Linus Torvalds wrote:

> On Wed, 18 Apr 2007, Guilhem Bonnefille wrote:
> > 
> > Yes, but I think that, as Git has ton more capabilities, user has to
> > understand more things than with CVS.
> 
> I do agree.
> 
> The whole "branch" thing is something you can ignore in CVS, but it's 
> simply very hard to ignore in git, because even *if* you just follow 
> another repository, git kind of forces you to be aware of the difference 
> between "local branch" and "remote tracking branch".
> 
> I think that's fairly fundamental to being distributed, though. 

I actually disagree here. CVS users are obviously familiar with "how far 
have I updated from the server". With CVS the "local branch" and "remote 
tracking branch" are qualitatively different, and with git they're 
qualitatively the same, but the user doesn't have to care. Particularly 
with the new refs layout, it's pretty easy to ignore, as long as the 
upstream repository isn't using branches for anything this particular user 
cares about.

You can just tell people, "Before you merge upstream changes, you have to 
commit, so that if the merge gets screwed up you don't lose your work." 
And they say, "Oh. That's useful." And they don't need to know the 
technical reasons this is both possible and necessary.

(Of course, branches are really helpful once you have a need for them, but 
there's no reason to learn about them before that point.)

	-Daniel
*This .sig left intentionally blank*

Re: GIT vs Other: Need argument

[Michael K. Edwards]

Suppose I were dealing with career software developers, backed by real
money, who also happened to be intelligent, thoughtful people, and I
wanted to make the case for git vs. CVS/SVN.  I'd start by handing
them copies of the O'Reilly Perforce book and suggesting that they
read it cover to cover.  Focus on the chapters on how well organized
development and release branches, and good tracking of feature/fix
propagation among them, can help you cope with the vagaries of
real-life software development.

Then I'd explain the relative merits of Perforce and git -- on one
hand, availability and quality of documentation, training, tech
support, and Windows versions; on the other hand, a genuinely
distributed design, which means that you don't need psychic powers to
arrive at a sane branch structure.  Specifically, git's design makes
private branches ultra-cheap for the developers that use them and
zero-impact on the release infrastructure, and the integrity of
_content_ and _history_ doesn't rely on any resemblance between my
branch layout and yours.  Speed, scalability, zero license cost, and
the hypothetical ability to hack on it yourself are nice too, but
they're basically fringe issues unless you're so big that you can't
just throw money at the problem -- in which case they're still fringe
issues because you're the enterprise-customer tail that wags the
vendor dog.  (If you're big _and_ cash-poor, or if you're stuck on a
VC system so badly designed that no amount of money thrown at the
problem will help, you have a different problem.)

If you do this right, it should be clear that CVS is in the dust on
all fronts and SVN doesn't (AFAICT) have any advantage over Perforce
that git doesn't have more of.  You might also mention that git was
designed by Linus to systematically not suck, and has been
successfully handed over to a strong maintenance/enhancement team that
works in public view.  And Linus is still here policing to keep
suckage from creeping in.  ;-)  The hypothetical smart developers will
then agree to go with either Perforce or git, depending on which the
people who have to do the hard work -- release managers and the IT
Morlocks -- are most comfortable with.

If you take this route, be prepared to wind up with Perforce.  It's
got its weaknesses, and I prefer git myself, but you could certainly
do a lot worse.  I'm not as anti-SVN as Linus, but there aren't many
workflows for which I would recommend it over Perforce.  Personally, I
wouldn't voluntarily introduce any other version control system into
the discussion, because the others that I've used in the course of one
day job or another suck massively by comparison, and the ones I
haven't used (or have only toyed with) don't appear to have any
compelling advantage over git.  (Having _marginally_ better
documentation isn't much to brag about).

Until someone writes a good book on git and sets up shop as a
commercial support organization, presenting Perforce vs. git as a
classic buy/build decision is probably the best you can do.  (You
don't have to "build" git, of course, but you'd have to build your own
in-house training and tech support capability.)  I say this as someone
who routinely sits in the "release manager" chair, uses git by choice,
and is currently suffering the pain and agony of migrating a perfectly
good git-based integration process to Perforce, simply because it
appears to be the right thing for this developer organization.
(Doubtless this colors my opinion du jour.)

Cheers,
- Michael

Re: GIT vs Other: Need argument

[Johannes Schindelin]

Hi,

On Wed, 18 Apr 2007, Guilhem Bonnefille wrote:

> I don't know lot of corporate teams, but here, our developers are
> REALLY not motivated by VCS. It's only a way to share work. And I'm
> not talking about concurrent modification: lot of people in my office
> really think that the better model is the locked one.
> These people won't be the guy who set up the repo. These people only
> expect a system to:
> - retrieve and merge the job done by other people
> - archive their job for other people.

How is that not concurrent? If it really was not, there would be no need 
to merge.

And let's face it: merging with CVS is cumbersome. Why? Exactly because 
CVS pretends (and tries to make you, too!) that there is just one branch.

Guess what. There are two branches. And they are conflicting. So, once you 
really looked at the problem you really should agree that branches are the 
natural mental model to deal with conflicts.

> So for such people, I really think raw Git is much more complicated than 
> CVS/SVN.

I imagine that somebody dedicated enough -- i.e. not me -- could set up 
some standard aliases which do the CVS/SVN equivalent; we'd probably need 
to support something like

	[alias]
		ci = commit -a && push origin

which should not be all that hard.

Ciao,
Dscho

Re: GIT vs Other: Need argument

[Matthieu Moy]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> How is that not concurrent? If it really was not, there would be no need 
> to merge.

It can be concurrent, but on different files. Concurrency and merge at
the filetree level, but never within a file. I've worked in a team
where the "corporate" use of a VCS was following this model. Not
locking a file before editing it was considered a mistake.

>> So for such people, I really think raw Git is much more complicated than 
>> CVS/SVN.
>
> I imagine that somebody dedicated enough -- i.e. not me -- could set up 
> some standard aliases which do the CVS/SVN equivalent; we'd probably need 
> to support something like
>
> 	[alias]
> 		ci = commit -a && push origin
>
> which should not be all that hard.

It depends on how you implement that.

There have been a discussion crossposted here and on the bzr ML. The
author of cogito added a similar feature to cogito.

But to emulate the centralized model, you need more than that, you
have to

1) make sure you're up to date with upstream
2) commit
3) push

and to do it correctly, 1) must be checked during all the procedure,
and doing it in a transactional way is not trivial.

bzr has a notion of "bound branches". That is, when you commit to a
bound branch, you also commit to the master branch. And the UI for
that is to use "bzr checkout master-branch". I agree the centralized
model is inferior in general, but there are several cases where this
is handy. One of them being to teach a newbie: "see, learn checkout,
update, commit, add, mv, remove and you know how to use it". Another,
for me, is to avoid forgetting to push ;-).

-- 
Matthieu

Re: GIT vs Other: Need argument

[Johannes Schindelin]

Hi,

On Wed, 18 Apr 2007, Linus Torvalds wrote:

> On Wed, 18 Apr 2007, Johannes Schindelin wrote:
> > 
> > On Tue, 17 Apr 2007, Marcin Kasperski wrote:
> > > 
> > > a) Windows are unsupported
> > 
> > Wrong.
> 
> It's a bit more work to set up though, and it has a lot less mindshare, 
> and testing, obviously.

Given the fact that Hannes is working not only _on_, but _with_ it, tells 
me that it works well enough for any Windows user (remember, they are used 
to rebooting their machines several times a day, just to keep them 
running).

> So yes, windows is a step-child. I'd love for it to not be one, and 
> we'll get there, but it's clearly not as supported as the unix side. We 
> still use a fair number of shell scripts (which in turn use unix 
> commands and pipelines).

Of course, the Windows users' "I want, but I don't contribute" mindset 
does not help either.

> We'll get away from it. I think GSoC will help here.

Unfortunately not as much as I hoped for. Since Google slashed our number 
of projects, we could not get funding for a developer who promised to make 
a Windows installer, and to work on the user experience on Windows.

Pity.

> Actually, at this stage, I really think cogito just *complicates* git 
> usage.

Hmm. However, I have to say that cogito serves/d another purpose quite 
well: Look at what came from cogito into git. Loads of useful 
enhancements. So, I really have to point to "at this stage", because that 
sure was not true 18 months ago.

> What _is_ true is that git is simply different from CVS. I don't think 
> it's necessarily harder to understand or use (in fact, I would argue 
> that git is a lot _easier_ to understand), but it is *different*, and it 
> has a ton more capabilities.

I guess that we should not say that Git is complicated. People tend to 
believe that, but it is simply not true. The basic steps are easy. Really 
easy.

But Git does not keep you there.

> So people coming from CVS/SVN have a double shock: they are supposed to 
> learn things that they "know" are hard (because CVS/SVN made them so damn 
> hard - don't tell me that SVN branching is easy, because it is *not* easy. 
> It may be cheaper to create a branch, but it has _all_ the same idiocies 
> that CVS has once it's created).

It is also dog slow.

Ciao,
Dscho

Re: GIT vs Other: Need argument

[Alex Riesen]

On 4/19/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> to rebooting their machines several times a day, just to keep them
> running).

That's not true! We only need to reboot them once a week to defragment
VFAT and NTFS volumes and cleanup the registry. Well, sometime the
antivirus software hangs up our machines and there of course always
are some malicious programs around. But we do not reboot them several
times a day. On a good day, at leas#$^%$#%^$#!!!!

Re: GIT vs Other: Need argument

[Christian MICHON]

On 4/19/07, Johannes Schindelin wrote:
> Given the fact that Hannes is working not only _on_, but _with_ it, tells
> me that it works well enough for any Windows user (remember, they are used
> to rebooting their machines several times a day, just to keep them
> running).

untrue, but very funny :)

My experience (offtopic, I know):

In one day, I actually reboot more often my qemu instances with my linux
test kernels than the current XP host crashes in a year.

-- 
Christian

Re: GIT vs Other: Need argument

[Johannes Schindelin]

Hi,

On Thu, 19 Apr 2007, Christian MICHON wrote:

> On 4/19/07, Johannes Schindelin wrote:
>
> > Given the fact that Hannes is working not only _on_, but _with_ it, 
> > tells me that it works well enough for any Windows user (remember, 
> > they are used to rebooting their machines several times a day, just to 
> > keep them running).
> 
> untrue, but very funny :)

Oh, but it is true! That's personal experience. My typical answer: "You 
needed to reboot? What is a 'reboot'?"

> My experience (offtopic, I know):
> 
> In one day, I actually reboot more often my qemu instances with my linux 
> test kernels than the current XP host crashes in a year.

With a linux test kernel. Yeah, right. So, you compare an experimental 
test kernel -- which I gather you stress test? -- with an XP kernel where 
you probably do not even check mails while running QEmu, for fear that it 
crashes? *lol*!

Ciao,
Dscho

Re: GIT vs Other: Need argument

[Christian MICHON]

On 4/19/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Oh, but it is true! That's personal experience. My typical answer: "You
> needed to reboot? What is a 'reboot'?"

I agree it was the case in the past.

> > My experience (offtopic, I know):
> >
> > In one day, I actually reboot more often my qemu instances with my linux
> > test kernels than the current XP host crashes in a year.
>
> With a linux test kernel. Yeah, right. So, you compare an experimental
> test kernel -- which I gather you stress test? -- with an XP kernel where
> you probably do not even check mails while running QEmu, for fear that it
> crashes? *lol*!

let me rephrase:
- I run some test on about a kernel I regenerate about > 20 times
a day [I'm making a distro right now...]
- my host XP crashes less than 20 times in a year

I was not comparing both kernels: I would not be spending time on
building a linux distro if I was not convinced linux is far superior :)

-- 
Christian

Re: GIT vs Other: Need argument

[Linus Torvalds]

On Thu, 19 Apr 2007, Johannes Schindelin wrote:
> 
> > Actually, at this stage, I really think cogito just *complicates* git 
> > usage.
> 
> Hmm. However, I have to say that cogito serves/d another purpose quite 
> well: Look at what came from cogito into git. Loads of useful 
> enhancements. So, I really have to point to "at this stage", because that 
> sure was not true 18 months ago.

Absolutely. I think there are still some pieces of cogito that we might 
want to migrate into git too, although they're fairly esoteric (ie the 
whole history rewriting thing). And I think we still have some places 
where git is influenced by cogito doing things differently (ie the whole 
branch tracking stuff) where we may want to change our default behaviour 
or extend on things.

So yes, "at this stage" was the operative word.

> I guess that we should not say that Git is complicated. People tend to 
> believe that, but it is simply not true. The basic steps are easy. Really 
> easy.
> 
> But Git does not keep you there.

I agree. And to some degree I suspect that the documentation pushes some 
of the advanced things a bit *too* eagerly.

Of course, with many of the projects that use git being very 
branch-oriented, I guess some of that is inevitable. You can't *not* 
mention branches, simply because even people who only track other peoples 
work do end up often needing to know about it, or at least hearing about 
them..

		Linus

Re: GIT vs Other: Need argument

[Marcin Kasperski]

>> I guess that we should not say that Git is complicated. People tend to 
>> believe that, but it is simply not true. (...)
>
> I agree. And to some degree I suspect that the documentation pushes some 
> of the advanced things a bit *too* eagerly. (...)
As I am among those, who think that git *is* complicated, I decided to 
sit down, and find out why
exactly I think so. Here are the top words/options/concepts, which I 
faced almost immediately while
trying GIT, and which I find confusing:

rebase
index
revtree
reset
ref / refs
rev-list
rev-parse

At the same time, concepts like add, rm, commit, push, pull, merge are 
natural and easily understandable.

Re: GIT vs Other: Need argument

[Linus Torvalds]

On Thu, 19 Apr 2007, Marcin Kasperski wrote:
> > 
> > I agree. And to some degree I suspect that the documentation pushes some of
> > the advanced things a bit *too* eagerly. (...)
>
> As I am among those, who think that git *is* complicated, I decided to 
> sit down, and find out why exactly I think so. Here are the top 
> words/options/concepts, which I faced almost immediately while trying 
> GIT, and which I find confusing:
> 
> rebase
> index
> revtree
> reset
> ref / refs
> rev-list
> rev-parse

Yes. I think it might be a good idea to write some kind of tutorial aimed 
for two very simple cases. Because there are really two cases that stand 
out as being (a) common and (b) something you start out with!

 - Case #1 would be using git basically as a "anonymous CVS" replacement 
   to track somebody others project.

   None of the above are ever really needed for that case, and I think all 
   you really want to learn is:

	git clone
	git pull

	gitk
	git log HEAD@{2.days.ago}..
	gitk HEAD@{1}.. some-file-or-directory

   and not a whole lot more (maybe pointing them at gitweb repos and 
   telling them what the thing can do).  In other words, you want to teach 
   people to just fetch the repo, and perhaps how to see what has changed 
   lately.

   In an advanced section for this usage case might be things like

	git bisect

   to teach people who track other peoples repository how to help those 
   other people find bugs when something goes wrong. But that would 
   literally be an "advanced topic".

 - Case #2 is the "how to start tracking your own project".

   In some ways, it's even *more* trivial, becuase if you start a new 
   project, you usually start from scratch (or perhaps from some CVS 
   import), with just one branch, and your first worry is not even how to 
   export it yet, but how to just *use* it for development.

   So for case #2, we'd never even mention "git clone/pull" or branches, 
   but instead we'd just talk about

	git init	(and "git cvsimport" or something)
	git add/rm/commit
	git diff/show
	git reset
	git checkout

   and walk through an everyday problem set of just some _very_ basic 
   situations. Explain the whole "content" thing, so that people 
   understand why "git add <filename>" + "git diff" doesn't actually show 
   the filename at all, and what the difference between "git diff" and 
   "git diff HEAD" is.

Those two usage cases actually cover a lot of trivial CVS usage already. A 
lot of people probably don't need to learn about branches AT ALL,  or 
about concurrent development, or anything like that. 

And the good news is that once you are very comfy with the two trivial 
cases, it's much easier to *later* explain how those two can actually be 
combined. In other words, there's probably not any reason at all to even 
start to talk about merging and branches until people are actually ready 
for it, and start asking you "so what happens if I've made changes and 
want to update to the most recent version". 

Similarly, you generally don't want to actually start serving your 
projects to others until long after you've started using the thing for 
development, so early on, it's probably perfectly fine to tell people: 
don't worry about setting up a server or gitweb, just be happy in the 
knowledge that it *can* be done, and has been done for big projects, so 
when you actually want to do that, you can do all these fancy things, but 
you shouldn't worry about it _yet_.

			Linus

Re: GIT vs Other: Need argument

[Carl Worth]

[-- Attachment #1: Type: text/plain, Size: 1641 bytes --]

On Thu, 19 Apr 2007 13:57:35 -0700 (PDT), Linus Torvalds wrote:
>  - Case #1 would be using git basically as a "anonymous CVS" replacement
>    to track somebody others project.

I'd extend this to also say "tracking a specific branch" in some
project.

When I raised this recently, Junio suggested something like the
following:

	git config --global branch.autosetupmerge true	[*]
	git clone <URL>
	git checkout -b <branch> origin/<branch>
	git pull

I haven't gotten around to replying to that message yet, but the
thrust of my reply would be that that does actually work, but it's not
even close to the ease with which one can track the default branch as
Linus described:

>    None of the above are ever really needed for that case, and I think all
>    you really want to learn is:
>
> 	git clone
> 	git pull

So, currently, all non-default branches have a sort of second-class
status from the point of view of users that just want to track
them.

Compare this to svn, for example. Now, svn has an insanely broken
model for what a branch actually is, while git's model is sane.  But I
think that with svn the "anonymously tracking a branch" use case isn't
any harder for any one branch compared to any other, (it's just a
matter of starting with the right URL). I'd love to see git achieve
the same thing.

-Carl

[*] Is the command I have above even correct? What Junio actually
suggested was:

	$ cat >>$HOME/.gitconfig <<\EOF
	[branch]
		autosetupmerge
	EOF

But I can't find a way to use git-config create a block that looks
like that. I'm just guessing that "autosetupmerge = true" works
equivalently, but I could be wildly wrong.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: GIT vs Other: Need argument

[Josef Weidendorfer]

On Monday 23 April 2007, Carl Worth wrote:
> On Thu, 19 Apr 2007 13:57:35 -0700 (PDT), Linus Torvalds wrote:
> >  - Case #1 would be using git basically as a "anonymous CVS" replacement
> >    to track somebody others project.
> 
> I'd extend this to also say "tracking a specific branch" in some
> project.
> 
> When I raised this recently, Junio suggested something like the
> following:
> 
> 	git config --global branch.autosetupmerge true	[*]
> 	git clone <URL>
> 	git checkout -b <branch> origin/<branch>
> 	git pull
> 
> I haven't gotten around to replying to that message yet, but the
> thrust of my reply would be that that does actually work, but it's not
> even close to the ease with which one can track the default branch as
> Linus described:

The commands above are not needed for pure tracking, but instead prepare
a local development branch for you to work on, and where you can pull
upstream changes with "git pull".
For tracking a remote $branch, it should be enough to do

 git clone
 git fetch

and you get the any (*) remote $branch as "remotes/origin/$branch".

Josef


(*) Perhaps the "any" is too much for wanting to track one branch only?

> 
> >    None of the above are ever really needed for that case, and I think all
> >    you really want to learn is:
> >
> > 	git clone
> > 	git pull
> 
> So, currently, all non-default branches have a sort of second-class
> status from the point of view of users that just want to track
> them.
> 
> Compare this to svn, for example. Now, svn has an insanely broken
> model for what a branch actually is, while git's model is sane.  But I
> think that with svn the "anonymously tracking a branch" use case isn't
> any harder for any one branch compared to any other, (it's just a
> matter of starting with the right URL). I'd love to see git achieve
> the same thing.
> 
> -Carl
> 
> [*] Is the command I have above even correct? What Junio actually
> suggested was:
> 
> 	$ cat >>$HOME/.gitconfig <<\EOF
> 	[branch]
> 		autosetupmerge
> 	EOF
> 
> But I can't find a way to use git-config create a block that looks
> like that. I'm just guessing that "autosetupmerge = true" works
> equivalently, but I could be wildly wrong.
> 

Re: GIT vs Other: Need argument

[Carl Worth]

[-- Attachment #1: Type: text/plain, Size: 1232 bytes --]

On Mon, 23 Apr 2007 21:52:58 +0200,Josef Weidendorfer wrote:
> The commands above are not needed for pure tracking, but instead prepare
> a local development branch for you to work on, and where you can pull
> upstream changes with "git pull".
> For tracking a remote $branch, it should be enough to do
>
>  git clone
>  git fetch
>
> and you get the any (*) remote $branch as "remotes/origin/$branch".

By "tracking" I mean the ability to get the working-tree state to
match that of some remote-tracking branch and then be able to
periodically do some command, ("git pull"), to make the working-tree
reflect the latest state of that remote branch.

So the fact that at any given point I can say:

	git checkout origin/<branch>

and get into a detached-HEAD where the working-tree matches what I
last fetched, doesn't quite do the job. From there, there's nothing
like "git pull" to usefully bring the working-tree state up to the
latest. Issuing "git pull" from the detached HEAD state does fetch,
but then complains:

	You are not currently on a branch; you must explicitly
	specify which branch you wish to merge:
	  git pull <remote> <branch>

So, no, the current git-clone alone does not get me to where I'd like
to be.

-Carl

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: GIT vs Other: Need argument

[Junio C Hamano]

Carl Worth <cworth@cworth.org> writes:

> When I raised this recently, Junio suggested something like the
> following:
>
> 	git config --global branch.autosetupmerge true	[*]
> 	git clone <URL>
> 	git checkout -b <branch> origin/<branch>
> 	git pull
>
> I haven't gotten around to replying to that message yet, but the
> thrust of my reply would be that that does actually work, but it's not
> even close to the ease with which one can track the default branch as
> Linus described:
>
>>    None of the above are ever really needed for that case, and I think all
>>    you really want to learn is:
>>
>> 	git clone
>> 	git pull
>
> So, currently, all non-default branches have a sort of second-class
> status from the point of view of users that just want to track
> them.

It is true that non default ones are second class status.
That's why they are not "default" ;-).

The autosetup configuration needs to be done once for the user
(not tied to any project), so you are talking about difference
between:

	git clone
        git pull
        git pull
        git pull
        git pull
        git pull
	...

vs

	git clone
        git checkout -b next origin/next
        git pull
        git pull
        git pull
        git pull
        git pull
	...

'git clone' step in both are done only once per project's
working tree, 'git checkout -b' step is done once for the
particular branch you are interested in, and after that you will
doing 'git pull' every day or every minute.  I do not think one
extra step is a big enough deal to make second class citizens
scream about inequality.

Re: GIT vs Other: Need argument

[Carl Worth]

[-- Attachment #1: Type: text/plain, Size: 1825 bytes --]

On Mon, 23 Apr 2007 15:23:38 -0700, Junio C Hamano wrote:
> It is true that non default ones are second class status.
> That's why they are not "default" ;-).

Sure, but different users have different needs. I use the default
branch for where I want developers to base most new commits, (a
"development" branch), but for some of these "anonymous tracking only"
users, a "stable" branch can be the only branch of interest. So I'd
really like to be able to publish branches on more equal footing.

> The autosetup configuration needs to be done once for the user
> (not tied to any project), so you are talking about difference
> between:

Well, it's not so simple to write off the autosetup configuration
step. Even if it only has to happen once, I still need to teach users
how to do it.

And that's an extra step compared to any other SCM tool one might be
interested in comparing git too, (which is the original topic).

So the current git sequence to get to being able to do just "git pull"
to track a specific branch is:

	# Something to setup autosetup (once per user account)
	git clone <url>
	git checkout -b <branch> origin/<branch>

I know that that's a single command in many other systems, and it
seems a very useful case to target. Is there any argument against
adding a single command that does exactly the above, (with the
modification that the autosetup thing could be done as local instead
of global configuration). And with the recent talk about phasing
cogito out and just merging its functionality into git itself, why not
just use the cogito syntax for this:

	git clone <url>#<branch>

At that point, git would be supporting this use case as well as any
other tool out there, (and git can still support things like tracking
_multiple_ branches in better ways than other tools as it does
already).

-Carl

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: GIT vs Other: Need argument

[Linus Torvalds]

On Mon, 23 Apr 2007, Carl Worth wrote:
>
> And with the recent talk about phasing cogito out and just merging its 
> functionality into git itself, why not just use the cogito syntax for 
> this:
> 
> 	git clone <url>#<branch>

That's a fundamentally weaker operation than the current "git clone", so I 
really don't think it's a good idea. The syntax also absolutely sucks, 
it's so horribly non-unixy.

I'd personally be ok with a

	git clone --default=<branch> <url>

to create something where "master" defaults to some other remote branch, 
but that just addresses the syntax. And quite frankly, I don't think we 
*need* to. We shoud just tell people how _easy_ it is to track some other 
branch now.

So I don't really see the problem with just saying:

 - the remote *has* a default branch. That's the one you get by default 
   with "git clone".

 - if you want to track another branch, you should just tell git that you 
   want to track it, and switch to that instead:

	git branch --track mybranch origin/otherbranch
	git checkout mybranch

   and be happy with it.

Yes, it's two extra commands, but they aren't *that* hard to explain, 
after all. You really can basically explain each stage both very simply 
and naturally with just

 - first you clone the repository. This gets you all remote branches, and 
   sets "master" to track the default remote branch.

	git clone remote [local-dir]

 - then, you create a new branch that you want to track another of the 
    branches in origin

	git branch --track mybranch origin/otherbranch

 - then you check that branch out

	git checkout mybranch

and notice how each stage really was not only pretty logical, but even the 
command to do it didn't really look *that* strange: even without the 
explanation of what the commands are doing, somebody reading just the pure 
commands could probably _guess_ what they do!

Really, all three stages are pretty simple, and they are not really that 
hard to explain. And it's not even like you do this very often - so this 
is the _perfect_ kind of thing to have on a "git reference card" kind of 
thing (think O'Reilly reference card series).

So I _really_ think that if we just had the "this is how to use 'git' as a 
replacement for 'anonymous CVS'-like usage" documentation, you could 
explain all of this very concisely, and with absolutely zero confusion 
even to a total non-git person. Give a few example command lines from real 
life (eg, tracking the "next" branch from git itself), and make it easy to 
find, and you're all done.

The advantage is that unlike that *idiotic* cogito syntax, you don't 
actually *lose* anything. If somebody says "but I'd like to track *two* 
branches", the sequence is _exactly_ the same. There is no "special magic" 
at clone time.

And the syntax is also much clearer. No magic and horribly non-unixy 
URL#branch syntax.

			Linus

Re: GIT vs Other: Need argument

[Brian Gernhardt]

On Apr 23, 2007, at 7:24 PM, Linus Torvalds wrote:

> So I don't really see the problem with just saying:
>
>  - the remote *has* a default branch. That's the one you get by  
> default
>    with "git clone".
>
>  - if you want to track another branch, you should just tell git  
> that you
>    want to track it, and switch to that instead:
>
> 	git branch --track mybranch origin/otherbranch
> 	git checkout mybranch
>
>    and be happy with it.
>
> Yes, it's two extra commands, but they aren't *that* hard to explain,
> after all. You really can basically explain each stage both very  
> simply
> and naturally with just

It's even better than that.  Just use "git checkout --track -b  
mybranch origin/otherbranch".  Slightly cumbersome, but is only one  
command.  And easily explained: "Checkout a tracking branch named  
mybranch for origin/otherbranch".

And the --track can be removed by using branch.autosetupmerge for  
people who always want it.

Actually the man page appears to be minorly incorrect.  It has "[-b  
[ --track | --no-track ]", which doesn't work.  Git gives me "git  
checkout: updating paths is incompatible with switching branches/ 
forcing".  I think it's interpreting --track as the new branch name.   
I'll send a patch reversing the order of the arguments in the man page.

~~ Brian

Re: GIT vs Other: Need argument

[Daniel Barkalow]

On Mon, 23 Apr 2007, Linus Torvalds wrote:

> On Mon, 23 Apr 2007, Carl Worth wrote:
> >
> > And with the recent talk about phasing cogito out and just merging its 
> > functionality into git itself, why not just use the cogito syntax for 
> > this:
> > 
> > 	git clone <url>#<branch>
> 
> That's a fundamentally weaker operation than the current "git clone", so I 
> really don't think it's a good idea. The syntax also absolutely sucks, 
> it's so horribly non-unixy.
> 
> I'd personally be ok with a
> 
> 	git clone --default=<branch> <url>
> 
> to create something where "master" defaults to some other remote branch, 
> but that just addresses the syntax. And quite frankly, I don't think we 
> *need* to. We shoud just tell people how _easy_ it is to track some other 
> branch now.

I've converted all my coworkers to git recently, and it was helpful to be 
able to go two weeks without explaining branches, due to the fact that our 
repositories only have one branch each (at least that people care about). 
It was also nice that, when one of them did learn about branches, he had 
the two weeks of experience with the absolute basics. I think that a first 
time user should be able to get, from the clone command:

[remote "origin"]
	url = ...
	fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
	remote = origin
	merge = refs/heads/<something>

if the first-time user's first repository for learning has the interesting 
stuff in a non-default branch. Now, a second-time user can learn about 
branches, but I think that branches are confusing and scary if you don't 
already have a bit of experience with the operations that affect a branch.

Obviously, if you want to track two branches in one repository, you need 
to know how to *have* additional local branches, but you can put off 
learning that until you recognize the need for it, if there's any easy way 
to get your initial branch to track the remote branch you're interested 
in.

Someone can get work done with clone, add, commit -a, pull, and push (or 
format-patch). Two commands and an additional fundamental concept is a lot 
of overhead at that stage.

For that matter, I sometimes want a repository where master tracks a 
branch that isn't default for other people and "mainline" tracks the 
upstream master, which requires a small amount of config file editing, and 
can't be made to just happen.

	-Daniel
*This .sig left intentionally blank*

Re: GIT vs Other: Need argument

[Junio C Hamano]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> I'd personally be ok with a
>
> 	git clone --default=<branch> <url>
>
> to create something where "master" defaults to some other remote branch, 
> but that just addresses the syntax. And quite frankly, I don't think we 
> *need* to. We should just tell people how _easy_ it is to track some other 
> branch now.

I agree with this (and everything you said in your message).
Keep the semantics the same, except that behave as if remote
HEAD pointed at a different branch than what it really points
at.

If Carl is also happy with the syntax, we can conclude this
discussion and:

 (1) have that as an enhancement to git-clone;

 (2) add a how-to document or a section to the manual to teach
     people how to track one or more branches, based on the
     messages already posted on this thread.

Re: GIT vs Other: Need argument

[J. Bruce Fields]

On Mon, Apr 23, 2007 at 10:15:04PM -0700, Junio C Hamano wrote:
> If Carl is also happy with the syntax, we can conclude this
> discussion and:
> 
>  (1) have that as an enhancement to git-clone;
> 
>  (2) add a how-to document or a section to the manual to teach
>      people how to track one or more branches, based on the
>      messages already posted on this thread.

Note that we almost have the tutorials for the "two very simple cases"
that Linus identifies:

	- case #1, the "anonymous CVS" replacement: chapter 2 of
	  user-manual.txt (the first chapter after the quick start) covers
	  this.  Perhaps in greater generality than necessary, and maybe
	  detached heads and/or --track should be mentioned earlier.

	- tutorial.txt, the "how to start tracking your own project"
	  case, starts with git-init, git-add, etc.

One problem is that it's not immediately obvious which one to look at
for each case.

--b.

Re: GIT vs Other: Need argument

[Linus Torvalds]

On Tue, 24 Apr 2007, J. Bruce Fields wrote:
> 
> Note that we almost have the tutorials for the "two very simple cases"
> that Linus identifies:
> 
> 	- case #1, the "anonymous CVS" replacement: chapter 2 of
> 	  user-manual.txt (the first chapter after the quick start) covers
> 	  this.  Perhaps in greater generality than necessary, and maybe
> 	  detached heads and/or --track should be mentioned earlier.
> 
> 	- tutorial.txt, the "how to start tracking your own project"
> 	  case, starts with git-init, git-add, etc.
> 
> One problem is that it's not immediately obvious which one to look at
> for each case.

Well, I think they really should be documents of their own, so that you 
can read about the "CVS tracking" or so without even worrying about the 
fact that you didn't read the whole thing.

And they should be easy to find. I agree that we do actually have a fair 
amount of docs, but it seems that people don't tend to *find* them. The 
user-manual, for example, is great, but I've seen people on the #git logs 
apparently not realize it exists ;)

For example, the git homepage has a "documentation" thing, which only 
lists the tutorial, not the user manual explicitly. You _can_ get to the 
user manual (go to the online version of the Documentation directory and 
note the "still work in progress"), but even if you do actually find 
yourself there, the user manual itself is actually a bit scary to start 
with.

So I think we could just make the initial impression a bit easier. The 
tutorial comes fairly close to the "tracking your own" thing, I agree, 
but maybe we could have the documentation listed in order of complexity, 
and having a way for people to know *which* doc they should start with 
when they are at http://git.or.cz/ (or the wikipedia page), so that if 
you're only interested in the "tracking somebody else", you could easily 
find and read just a single simple documentation thing. Hmm?

			Linus

Re: GIT vs Other: Need argument

[J. Bruce Fields]

On Tue, Apr 24, 2007 at 08:01:50AM -0700, Linus Torvalds wrote:
> Well, I think they really should be documents of their own, so that you 
> can read about the "CVS tracking" or so without even worrying about the 
> fact that you didn't read the whole thing.

Sure.  There may be some tension between making more separate documents
and keeping them all findable.  Well, it just means we need some easy
way to index them.

> And they should be easy to find. I agree that we do actually have a fair 
> amount of docs, but it seems that people don't tend to *find* them. The 
> user-manual, for example, is great, but I've seen people on the #git logs 
> apparently not realize it exists ;)
> 
> For example, the git homepage has a "documentation" thing, which only 
> lists the tutorial, not the user manual explicitly. You _can_ get to the 
> user manual (go to the online version of the Documentation directory and 
> note the "still work in progress"), but even if you do actually find 
> yourself there, the user manual itself is actually a bit scary to start 
> with.
> 
> So I think we could just make the initial impression a bit easier. The 
> tutorial comes fairly close to the "tracking your own" thing, I agree, 
> but maybe we could have the documentation listed in order of complexity, 
> and having a way for people to know *which* doc they should start with 
> when they are at http://git.or.cz/ (or the wikipedia page), so that if 
> you're only interested in the "tracking somebody else", you could easily 
> find and read just a single simple documentation thing. Hmm?

Yeah.  So we can try to figure out a small set of clearly labeled entry
points into the documentation, and I'll work with Petr Baudis to make
sure they're at the top of the git home page.  And I suppose the same
set should appear on the main git man page.  Anywhere else?  Maybe
Documentation/ needs its own index.html....

--b.

Making git disappear when talking about my code (was: Re: GIT vs Other: Need argument)

[Carl Worth]

[-- Attachment #1: Type: text/plain, Size: 7164 bytes --]

On Mon, 23 Apr 2007 22:15:04 -0700, Junio C Hamano wrote:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
> > I'd personally be ok with a
> >
> > 	git clone --default=<branch> <url>
...
> If Carl is also happy with the syntax, we can conclude this
> discussion and:
>
>  (1) have that as an enhancement to git-clone;

I think it's a useful enhancement. It would let me at least document
something like "tracking this project's stable branch" with a single
command, which I think is useful. But I don't know that I would be
totally happy yet. :-)

So please allow me to comment on the syntax a bit. Linus, you claimed
that <url>#<branch> isn't "unixy" enough for your taste. What does
that mean exactly? Is it that two logically independent things are
crammed into a single argument instead of being passed as second
arguments? Or something else?

Here's the reason I want both the URL and the branch to appear as a
single string, (but I don't really care about the precise syntax). I
really want to be able to say "see my branch at <string>" and have
that <string> be a complete and self-contained description of the
branch that can be used in several different ways including:

* Cloning a new repository to track that branch as the default

* Begin tracking that branch as a new branch within an existing
  repository

* Viewing that branch's history in a web browser.

So in my dream world I'd publish a single URL+branch string that could
be fed directly to "git clone", something like "git track", or to a web
browser and the user would get exactly what was desired in all
cases. (As for http:// vs. git:// in the URL, I hope someone could
recommend the right magic to make things efficient in my dream world.)

So that idea also addresses the problem that Linus had with adding
some special "tracking" feature that would only be available for a
single branch and only at the time of clone. Of course that would be
undesirable, and that's why I've been talking about something like
"git track" to add the exact same functionality for tracking
subsequent branches after the clone.

When I last mentioned "git track", Junio pointed out that the existing
"git remote add <remote> URL" and "git checkout --track -b <branch>
<remote>/<branch>"[*] is more powerful anyway. I totally agree that
it's great to be able to add a remote like this, and to be able to
then use the <remote> alias to refer to the URL.

But the whole "git remote add" doesn't help and actually gets in the
way in the use case I'm trying to address. The problem is that if the
user has already created a remote alias for the URL I'm advertising, I
can't take advantage of that in my instructions since I don't know
what local name the user used for it.

Here's the kind of email I'd like to be able to write in my dream
world:

[1]	I've just written some very fancy feature for our cool project
	which you can see at <string> and clone or track with
	git. Please try it out and give me feedback.

And from here, readers could paste <string> into a web browser to see
the branch's history, (I'd also like some branch-specific description
to appear), and also be presented with exact commands for cloning or
tracking the branch with git, ("git clone <string>" or "git track
<string>").

Even if the user didn't view the URL I gave in a web browser, there's
enough detail in my message to guess that "git clone <string>" and
"git track <string>" would be useful commands. Or without guessing
required, users would learn this after seeing the commands once or
twice in a web browser or whatever.

So in my dream world, a sentence like the above gives any user all the
information they need to start using git to get at my code. And notice
that my text gets to focus on my features and my project which is what
I care about in a message like this, and doesn't get bogged down in
sharing details about how to use git.

So compare the current situation with my dream world. The closest I
can get know is something like:

[2]	I've just written some very fancy feature for our cool project
	which you can see in gitweb at <gitweburl>. To track this
	branch, do "git remote add cworth <url>; git checkout --track
	-b <branch> cworth/<branch>" if you already have some clone of
	our project. Otherwise do "git clone <url>; git checkout
	--track -b <branch>". Please try it out and give me feedback.

So adding "clone --default" would help shorten the last command, but
wouldn't really help simplify the rest of this stuff. And it's really
all noise when what I want to be talking about is my code, not the
syntax of various git commands.

Now, someone might complain that I'm setting up a strawman with a
paragraph like that---that I'm throwing too much git talk into that
paragraph and that something more realistic with current git would
look like this:

[3]	I've just written some very fancy feature for our cool project
	which is available in the <branch> branch at <url>. Please try
	it out and give me feedback.

I agree that that paragraph is more like what people are actually
doing with git-based projects today. But this paragraph is definitely
not as functional as my dream-world paragraph. What I don't like about
this one is how much knowledge this assumes on the part of the
user. If the user wants to see things in gitweb, they'll have to know
how to construct a URL for that. If they want to start tracking the
branch in an existing clone, they'll have to know the "remote add" and
"checkout --track" commands to do that.

Some people do know all that stuff and keep it current in their
heads. Some people will have done this before but will have to dig in
their mental memory banks or re-check a git reference card before they
can get at the code. And plenty of people will have have never used
git at all so will have to go learn about it. Where to go to learn?

There are enough obstacles there that some of these people won't be
successful and will never end up looking at my code, (which is not
what I want---I want as many people as possible to have an effortless
experience in getting at my code). And there are enough obstacles
there that even those who do make it through can easily get the
impression that "git is hard".

The only way I know to avoid those obstacles is to do like I did in
paragraph [2] and at least give the user all the pointers they need so
that they don't need to look anything up. But there again, there's so
much "git speak" that it still looks hard, and it definitely distracts
from what I'm really wanting to talk about.

This is what I'm referring to in the subject where I say that I'd like
git to be able to disappear into the background when I'm talking about
my code.

Does that description help you understand what I'm looking for when I
propose a new syntax for <url> plus <branch> that could be accepted by
both "clone" and also propose a new "track" command that could accept
the same syntax?

-Carl

[*] I don't know if that command is exactly right---there is a lot to
have to remember to put that command together, (and in a precise
order!), which is another reason I think the current approach is much
harder than it should be.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Making git disappear when talking about my code (was: Re: GIT vs Other: Need argument)

[Carl Worth]

[-- Attachment #1: Type: text/plain, Size: 1977 bytes --]

On Wed, 25 Apr 2007 06:12:32 -0700, Carl Worth wrote:
> [2]	I've just written some very fancy feature for our cool project
> 	which you can see in gitweb at <gitweburl>. To track this
> 	branch, do "git remote add cworth <url>; git checkout --track
> 	-b <branch> cworth/<branch>" if you already have some clone of
> 	our project. Otherwise do "git clone <url>; git checkout
> 	--track -b <branch>". Please try it out and give me feedback.

Oops. I just noticed that that last command is wrong. Instead of "git
checkout --track -b <branch>" that should of course be "git checkout
--track -b <branch> origin/<branch>".

And no, I didn't intentionally botch that to be able to make a
point. But now, I will make the point: the current syntax is hard to
remember. It _is_ powerful, and I do personally use it and like it,
(and if I made the mistake above at the command line it would have
been obvious to me how to fix it, and would have been no big deal).

So I'm not suggesting replacing any of the remote stuff---I'd just
like to have something easier to suggest to people who aren't yet
familiar with remotes and remote-tracking branches, (and something
simple enough that I could get it right when writing an email without
git around to complain if I botch the syntax).

So I'd imagine "git track <url>#<branch>" as being implemented
directly with the existing remote stuff, (lookup and use an existing
remote for <url> if it exists, otherwise create a new one and name it
with some mangling of <url>, or complain politely if the mangling
would clash with an existing remote with the same name but a different
URL---which would be extremely unlikely).

Anyway, as usual I seem to find myself with just enough time and
motivation to talk about what I'd like, but not enough to code it up.
So feel free to ignore me if you disagree, and please feel free to be
inspired to code something up if you agree.

And thanks to everyone that has worked to make git so excellent!

-Carl

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Making git disappear when talking about my code (was: Re: GIT vs Other: Need argument)

[Linus Torvalds]

On Wed, 25 Apr 2007, Carl Worth wrote:
> 
> Oops. I just noticed that that last command is wrong. Instead of "git
> checkout --track -b <branch>" that should of course be "git checkout
> --track -b <branch> origin/<branch>".

No, it really should be

	git branch --track newbranch origin/oldbranch

followed by

	git checkout newbranch

and then it's not so hard. It's two commands, but it's two _simpler_ 
commands, that make sense on their own. Don't use the complex version: 
it's a "expert mode" command that just knows how to do both.

Alternatively, we *could* make just

	git checkout --track branch

be a shorthand for

	git checkout --track -b branch origin/branch

when "branch" doesn't exist, but origin/branch does. With the "--track", 
it's already unambiguous (you cannot track a detached head, so we know we 
want a branch.

			Linus

Re: Making git disappear when talking about my code (was: Re: GIT vs Other: Need argument)

[Carl Worth]

[-- Attachment #1: Type: text/plain, Size: 2352 bytes --]

On Wed, 25 Apr 2007 07:55:49 -0700 (PDT), Linus Torvalds wrote:
> Alternatively, we *could* make just
>
> 	git checkout --track branch
>
> be a shorthand for
>
> 	git checkout --track -b branch origin/branch
>
> when "branch" doesn't exist, but origin/branch does. With the "--track",
> it's already unambiguous (you cannot track a detached head, so we know we
> want a branch.

I like that a lot, thanks! Things that make the command-line simpler
with no loss in functionality nor introducing any ambiguity are really
nice.

And I'd even follow that up to propose making "git checkout branch"
(where branch doesn't exist but remote/<something>/branch does), do
something new, (not detached head, nor creating a local tracking
branch), that would allow the following:

1. Using "git checkout branch" to examine the working-tree status of a
   branch.

	This functionality exists already, but with a fairly obnoxious
	detached head warning.

2. Subsequently using "git pull" to track that remote branch

	This functionality is currently missing without creating a
	local branch first. This is an inconvenience compared to the
	pre-separate-remotes git where "git checkout next" followed by
	a sequence of "git pull" was enough to track a branch.

	Now, old git also had the huge defect that it was too easy to
	screw everything up by committing to what should have been
	treated as a read-only tracking branch, which is where the
	next point comes in.

3. Allow a commit from this state, by *then* creating the explicit
   local branch setup to track the remote-tracking branch.

	That is, under this proposal the command sequence of:

		git checkout branch
		# hack
		git commit

	Would get one to the exact same state as today's sequence of:

		git branch --track branch origin/branch
		git checkout branch
		# hack
		git commit

	Which to me just looks like making git easier to use.

	Of course, git could complain politely if the branch name it
	wanted to create were taken already and instruct the user how
	to create a new name for the tracking branch before the
	commit.

Is that a totally insane idea? (The answer might very well depend on
some details of the implementation---presumably .git/HEAD would have
to store both the name of the remote-tracking branch as well as the
sha1 to which it corresponded at the time of the checkout.)

-Carl

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Making git disappear when talking about my code (was: Re: GIT vs Other: Need argument)

[Nicolas Pitre]

On Wed, 25 Apr 2007, Carl Worth wrote:

> And I'd even follow that up to propose making "git checkout branch"
> (where branch doesn't exist but remote/<something>/branch does), do
> something new, (not detached head, nor creating a local tracking
> branch), that would allow the following:
> 
> 1. Using "git checkout branch" to examine the working-tree status of a
>    branch.
> 
> 	This functionality exists already, but with a fairly obnoxious
> 	detached head warning.

With all the safeties (reflogs, etc) this warning could be toned down 
even more now.

> 2. Subsequently using "git pull" to track that remote branch
> 
> 	This functionality is currently missing without creating a
> 	local branch first. This is an inconvenience compared to the
> 	pre-separate-remotes git where "git checkout next" followed by
> 	a sequence of "git pull" was enough to track a branch.
> 
> 	Now, old git also had the huge defect that it was too easy to
> 	screw everything up by committing to what should have been
> 	treated as a read-only tracking branch, which is where the
> 	next point comes in.
> 
> 3. Allow a commit from this state, by *then* creating the explicit
>    local branch setup to track the remote-tracking branch.
> 
> 	That is, under this proposal the command sequence of:
> 
> 		git checkout branch
> 		# hack
> 		git commit
> 
> 	Would get one to the exact same state as today's sequence of:
> 
> 		git branch --track branch origin/branch
> 		git checkout branch
> 		# hack
> 		git commit
> 
> 	Which to me just looks like making git easier to use.

I don't feel comfortable with that.

To me it looks like Git would perform some hardcoded magic without 
helping the user understanding what is going on.  Worse: it can perform 
all those operations even if that is not what you wanted.

I much prefer multiple simple commands that perform basic and 
understandable operations than a single complex one with more magic in 
it.  If it was just me I'd eliminate the pull command and a pull would 
always be a fetch followed by a merge...

I understand your desire for people to get at your code as quickly and 
easy as possible, but that conflicts with our desire for people to 
really understand the basics of Git.  Creating magic commands with 
hardcoded defaults for a one-click-does-all behavior isn't helping 
that understanding at all.

If you really want people to get at your code with no Git consideration 
what so ever, then just direct them at the corresponding gitweb and/or 
git-archive invocations with --remote=<repo> to store a local copy.

> 	Of course, git could complain politely if the branch name it
> 	wanted to create were taken already and instruct the user how
> 	to create a new name for the tracking branch before the
> 	commit.
> 
> Is that a totally insane idea? (The answer might very well depend on
> some details of the implementation---presumably .git/HEAD would have
> to store both the name of the remote-tracking branch as well as the
> sha1 to which it corresponded at the time of the checkout.)

And why again isn't detached head just fine for your usage scenario 
instead? Only the "obnoxious" warning?


Nicolas

Re: Making git disappear when talking about my code (was: Re: GIT vs Other: Need argument)

[Carl Worth]

[-- Attachment #1: Type: text/plain, Size: 2484 bytes --]

On Wed, 25 Apr 2007 14:07:23 -0400 (EDT), Nicolas Pitre wrote:
> With all the safeties (reflogs, etc) this warning could be toned down
> even more now.

That would definitely help.

> To me it looks like Git would perform some hardcoded magic without
> helping the user understanding what is going on.

That's a fine argument.

> If you really want people to get at your code with no Git consideration
> what so ever, then just direct them at the corresponding gitweb and/or
> git-archive invocations with --remote=<repo> to store a local copy.

But that's just it. It's not that I want people to get at my code with
no git consideration. I believe that git provides the best way to get
at my code, (since it allows not just getting at a single snapshot
like git-archive would), but it allows for getting at everything in
the past as well, and easily getting at stuff in the future.

It's more that I want a single way to talk about some branch I've just
published, (necessarily both a url and a branch), and I assume an
audience with a wide range of git experience, (from none to lots).
So I'm just looking for a simple way to advertise the branch that will
work for the whole audience, (gitweb and git-archive aren't going to
be much use for the experienced git user---except in an indirect way
where the user could manually extract the useful parts of the
instructions out of the noise).

> And why again isn't detached head just fine for your usage scenario
> instead? Only the "obnoxious" warning?

No ability to easily follow the branch as new stuff comes along.

Compare what one used to be able to do with pre-separate-remotes git:

	git clone git://git.kernel.org/pub/scm/git/git.git
	git checkout next
	git pull # occasionally

to what you have now:

	git clone git://git.kernel.org/pub/scm/git/git.git
	git checkout origin/next

And what's step 3 to follow this branch? Certainly, doing "git fetch"
occasionally brings in the data, but there's no simple way to use
detached head to just "follow along".

So then the user has to learn new concepts like creating a tracking
branch:

	git branch --track next origin/next
	git checkout next
	git pull # occasionally

You can say that's just a series of simple commands, but it's still
more concepts and commands than other systems, (including past
versions of git).

And for the user that's really just doing read-only branch tracking, I
don't see where there's much benefit coming from the extra concepts
and commands.

-Carl

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Making git disappear when talking about my code

[Junio C Hamano]

Carl Worth <cworth@cworth.org> writes:

> It's more that I want a single way to talk about some branch I've just
> published, (necessarily both a url and a branch), and I assume an
> audience with a wide range of git experience, (from none to lots).

Why would you want to add another syntax that can talk about
only one branch?  It shows that you care only about talking
about single branch, making things harder for other people who
might want to talk about two branches or more.

I would agree with you that if you are talking to total git
newbie, you cannot get away with message like [3] in your
original and you would need some instructions you added in your
example [2].  But I suspect that is true for any new system.  If
somebody has never seen cvs and your project is hosted at cvs,
and if you want to be really helpful, I think you have to tell
"cvs -d :pserver:... co cworth-project" somewhere in your
message.

But that does not have to be in the main part of the
announcement, like this (this is your [2]):

    I've just written some very fancy feature for our cool project
    which you can see in gitweb at <gitweburl>. To track this
    branch, do "git remote add cworth <url>; git checkout --track
    -b <branch> cworth/<branch>" if you already have some clone of
    our project. Otherwise do "git clone <url>; git checkout
    --track -b <branch>". Please try it out and give me feedback.

You can say instead:

    I've just written some very fancy feature for our cool project
    which is available in the <branch> branch at <url>. Please try
    it out and give me feedback. [*1*]

    [Footnote]

    *1* If you have never used git, here are the ways to get at
        the cool project ...

	 <<< instruction here >>>

	If you have been tracking the upstream of the cool
	project, alternatively you can do this to get to my
	fancy feature as a new branch in your repository ...

	 <<< instruction here >>>

Re: Making git disappear when talking about my code

[Nicolas Pitre]

On Wed, 25 Apr 2007, Junio C Hamano wrote:

> I would agree with you that if you are talking to total git
> newbie, you cannot get away with message like [3] in your
> original and you would need some instructions you added in your
> example [2].  But I suspect that is true for any new system.  If
> somebody has never seen cvs and your project is hosted at cvs,
> and if you want to be really helpful, I think you have to tell
> "cvs -d :pserver:... co cworth-project" somewhere in your
> message.

You forget about "cvs -d :pserver:... login" that needs to be performed 
as well.


Nicolas

Re: Making git disappear when talking about my code

[Carl Worth]

[-- Attachment #1: Type: text/plain, Size: 2358 bytes --]

On Wed, 25 Apr 2007 12:17:30 -0700, Junio C Hamano wrote:
> Carl Worth <cworth@cworth.org> writes:
>
> > It's more that I want a single way to talk about some branch I've just
> > published, (necessarily both a url and a branch), and I assume an
> > audience with a wide range of git experience, (from none to lots).
>
> Why would you want to add another syntax that can talk about
> only one branch?

As mentioned elsewhere in the thread, I'm fine with a space for a
separator instead of a '#'. I really didn't intend to get hung up on
that kind of syntactic issue.

The question is how much work is involved in getting from:

	Checkout my new work:

		<url> <branch>

to where the user can just start tracking it (read-only). Right now,
in many cases the user has to slice that up and pass the <url> to some
commands and the <branch> to other commands (see below).

> You can say instead:
>
>     I've just written some very fancy feature for our cool project
>     which is available in the <branch> branch at <url>. Please try
>     it out and give me feedback. [*1*]

OK, and I'll fill in the holes in your footnote. I'm perfectly fine
with assuming the user already has a clone of the project, (they can
find well-published instructions for that on the project site), so
then what's left is:

	*1* From within your git clone of the project, do the following (if
	    you haven't made a remote for my repository before):

		git remote add cworth <url>

	    Finally, you can start tracking my branch with the following:

		git fetch cworth
		git branch --track <branch> cworth/<branch>
		git checkout <branch>

	    And use "git pull" periodically to stay abreast of future work I
	    do on that branch.

That's workable, but notice that every occurrence of "cworth" in the
above is really getting in the user's way. Once a user knows a bit
more about git and remotes, it can be really useful to take advantage
of them. For example, when I'm interested in inspecting a newly
announced branch like this from someone for whom I have already setup
a remote I often do:

	git fetch <someone>
	git log ..<someone>/<branch>

And that's really nice and easy, (yes, multiple-branch tracking in a
single repository *is* the one true way).

But I don't think forcing the remote-creation on the user, (as in my
footnote), is actually making things easier.

-Carl

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Making git disappear when talking about my code (was: Re: GIT vs Other: Need argument)

[Nicolas Pitre]

On Wed, 25 Apr 2007, Carl Worth wrote:

> Compare what one used to be able to do with pre-separate-remotes git:
> 
> 	git clone git://git.kernel.org/pub/scm/git/git.git
> 	git checkout next
> 	git pull # occasionally
> 
> to what you have now:
> 
> 	git clone git://git.kernel.org/pub/scm/git/git.git
> 	git checkout origin/next

But if you _create_ a new branch in your repository, Git will pick it up 
automatically now with a fetch operation, which the previous branch 
layout didn't allow for.


Nicolas

Re: Making git disappear when talking about my code (was: Re: GIT vs Other: Need argument)

[Linus Torvalds]

On Wed, 25 Apr 2007, Carl Worth wrote:
> 
> So please allow me to comment on the syntax a bit. Linus, you claimed
> that <url>#<branch> isn't "unixy" enough for your taste. What does
> that mean exactly?

It means *exactly* what it says. 

That is a horrible syntax. It's not how we do *any* other commands. It's 
web-centric in a way git simply IS NOT.

What's so special about '#' that makes it wonderful for this special case? 
NOTHING.

And to make matters worse, it's fundamentally TOO WEAK: The 'url#branch' 
syntax would be limited to clones, because a "pull" and "fetch" _needs_ 
something more powerful. So if we introduce that syntax, we're forever 
cursed with having two incompatible and independent syntaxes for this, 
because (a) people will then say "why not pull", and (b) it's NOT A GOOD 
SYNTAX, so we'd support the old syntax for pull/fetch too.

So don't go there. It's simply a broken idea. Is that so hard to just 
admit?

		Linus

Re: Making git disappear when talking about my code (was: Re: GIT vs Other: Need argument)

[Daniel Barkalow]

On Wed, 25 Apr 2007, Carl Worth wrote:

> On Mon, 23 Apr 2007 22:15:04 -0700, Junio C Hamano wrote:
> > Linus Torvalds <torvalds@linux-foundation.org> writes:
> >
> > > I'd personally be ok with a
> > >
> > > 	git clone --default=<branch> <url>
> ...
> > If Carl is also happy with the syntax, we can conclude this
> > discussion and:
> >
> >  (1) have that as an enhancement to git-clone;
> 
> I think it's a useful enhancement. It would let me at least document
> something like "tracking this project's stable branch" with a single
> command, which I think is useful. But I don't know that I would be
> totally happy yet. :-)
> 
> So please allow me to comment on the syntax a bit. Linus, you claimed
> that <url>#<branch> isn't "unixy" enough for your taste. What does
> that mean exactly? Is it that two logically independent things are
> crammed into a single argument instead of being passed as second
> arguments? Or something else?

Linus has stated a preference on the lkml for being told about branches in 
the syntax used for anonymous pulls: URL branchname.

That is, you say:

  Please pull from:
    git://server/path branch

And he cuts and pastes into the command line:

  git pull git://server/path branch

Now, this syntax isn't available for git-clone, because git-clone puts the 
optional directory to create after the URL. But, in an ideal world, this 
is how it would work; you could see a pull request, and just type "git 
some-command <paste>".

> Here's the reason I want both the URL and the branch to appear as a
> single string, (but I don't really care about the precise syntax). I
> really want to be able to say "see my branch at <string>" and have
> that <string> be a complete and self-contained description of the
> branch that can be used in several different ways including:
> 
> * Cloning a new repository to track that branch as the default
> 
> * Begin tracking that branch as a new branch within an existing
>   repository

Here, you probably need to specify what you want the new branch to be, 
because it will often be the case that the remote branch will be "master" 
in a repository with a long unrecognizable URL, and you need to be able to 
switch to and away from the branch in some sane way. On the other hand, 
the user will presumably never care too deeply about the remote, aside 
from that git remembers stuff appropriately. I say, use the hash of the 
URL as the name of the remote, and provide some shorthand for the tracking 
branch that would be merged by default into the current head, and you're 
set. I.e.:

git track new-name URL [branch]

creates and checks out a new branch "new-name" with the config:

[remote "hash of URL"]
	url = URL
	fetch = +refs/heads/*:refs/remotes/hash of URL/*
[branch "new-name"]
	remote = "hash of URL"
	merge = refs/heads/[branch]

When on this branch, you update with "git pull" (which already works, 
given this configuration). And there would just need to be a better way of 
doing "git log remotes/hash of URL/branch..HEAD", which should probably be 
something like "git log MERGE..HEAD", with MERGE being magic for the thing 
that tracks the current branch's "merge" setting.

Incidentally, I'm not seeing the case of wanting to track multiple 
branches from the same repository as nearly as likely for a novice as 
wanting to track multiple branches from different repositories. I think 
the likely order of being interested in things is:

1. The project's maintainer's repository, exactly one of maint, master, or 
   next.
2. Somebody else's repository for some interesting feature, master
3. Somebody else's repository for all interesting features, some branch
4. Repository from 3, additional branches
5. Maintainer's repository, multiple branches.

With the most common case for two tracking branches being master from two 
repositories, such that upstream branch names are most often useless for 
distinguishing anything.

	-Daniel
*This .sig left intentionally blank*

Re: Making git disappear when talking about my code

[Junio C Hamano]

Daniel Barkalow <barkalow@iabervon.org> writes:

> Linus has stated a preference on the lkml for being told about branches in 
> the syntax used for anonymous pulls: URL branchname.
>
> That is, you say:
>
>   Please pull from:
>     git://server/path branch
>
> And he cuts and pastes into the command line:
>
>   git pull git://server/path branch
>
> Now, this syntax isn't available for git-clone, because git-clone puts the 
> optional directory to create after the URL. But, in an ideal world, this 
> is how it would work; you could see a pull request, and just type "git 
> some-command <paste>".

I think I already suggested this to Carl once, but if you 
forget about 'git clone' in this case (or any other cases), your
example would just work.

	$ git init
        $ git pull git://server/path branch

Re: Making git disappear when talking about my code

[Linus Torvalds]

On Wed, 25 Apr 2007, Junio C Hamano wrote:
> 
> I think I already suggested this to Carl once, but if you 
> forget about 'git clone' in this case (or any other cases), your
> example would just work.
> 
>    $ git init
>    $ git pull git://server/path branch

The problem with this is that it doesn't set up tracking, so while it 
*works*, you are now forever doomed to re-do that

	git pull git://server/path branch

to update, and if you then ever give the wrong branch name you'll try to 
merge and get really confused as a beginner.

		Linus

Re: Making git disappear when talking about my code

[Nicolas Pitre]

On Wed, 25 Apr 2007, Junio C Hamano wrote:

> I think I already suggested this to Carl once, but if you 
> forget about 'git clone' in this case (or any other cases), your
> example would just work.
> 
> 	$ git init
>         $ git pull git://server/path branch

Ah, goodie!


Nicolas

Re: Making git disappear when talking about my code

[Daniel Barkalow]

On Wed, 25 Apr 2007, Junio C Hamano wrote:

> Daniel Barkalow <barkalow@iabervon.org> writes:
> 
> > Linus has stated a preference on the lkml for being told about branches in 
> > the syntax used for anonymous pulls: URL branchname.
> >
> > That is, you say:
> >
> >   Please pull from:
> >     git://server/path branch
> >
> > And he cuts and pastes into the command line:
> >
> >   git pull git://server/path branch
> >
> > Now, this syntax isn't available for git-clone, because git-clone puts the 
> > optional directory to create after the URL. But, in an ideal world, this 
> > is how it would work; you could see a pull request, and just type "git 
> > some-command <paste>".
> 
> I think I already suggested this to Carl once, but if you 
> forget about 'git clone' in this case (or any other cases), your
> example would just work.
> 
> 	$ git init
>         $ git pull git://server/path branch

It works for Linus's usage, where he expects to get all the info again 
next time there's more useful stuff. I don't think this configures things 
so that:

	$ git init
	$ git pull git://server/path branch
	... wait a couple of weeks and forget the URL ...
	$ git pull

works. (Although I haven't actually checked, so I could be totally wrong)

	-Daniel
*This .sig left intentionally blank*

Re: Making git disappear when talking about my code (was: Re: GIT vs Other: Need argument)

[Carl Worth]

[-- Attachment #1: Type: text/plain, Size: 3609 bytes --]

On Wed, 25 Apr 2007 15:44:11 -0400 (EDT), Daniel Barkalow wrote:
> Linus has stated a preference on the lkml for being told about branches in
> the syntax used for anonymous pulls: URL branchname.

That's a fine syntax too.

> Now, this syntax isn't available for git-clone, because git-clone puts the
> optional directory to create after the URL. But, in an ideal world, this
> is how it would work; you could see a pull request, and just type "git
> some-command <paste>".

Yes. That's exactly what I'm talking about, being able to very easily
just paste the branch specifier to a git command. And yes, it would
be convenient if one could do this for as many commands as
possible. The fact that git-clone can't accept this syntax is
unfortunate, (and maybe that is the only reason I was inclined to add
the '#' character).

> Here, you probably need to specify what you want the new branch to be,
> because it will often be the case that the remote branch will be "master"
> in a repository with a long unrecognizable URL, and you need to be able to
> switch to and away from the branch in some sane way. On the other hand,
> the user will presumably never care too deeply about the remote, aside
> from that git remembers stuff appropriately. I say, use the hash of the
> URL as the name of the remote, and provide some shorthand for the tracking
> branch that would be merged by default into the current head, and you're
> set. I.e.:
>
> git track new-name URL [branch]

OK, that still allows for pasting the URL and branch, but the user has
to know not only "git track" but also that she must invent a local for
the branch and insert that into the command as well. And it's hard for
me to help the user on this point (at least in a cut-and-pasteable
way), since the whole point of that argument is to create an entry in
a private namespace that I don't know anything about.

How about making that optional at least? That is create a local branch
named <branch> for:

	git track URL <branch>

but also allow something like:

	git track --as <newbranch> URL <branch>

> creates and checks out a new branch "new-name" with the config:
>
> [remote "hash of URL"]
> 	url = URL
> 	fetch = +refs/heads/*:refs/remotes/hash of URL/*
> [branch "new-name"]
> 	remote = "hash of URL"
> 	merge = refs/heads/[branch]

Yes, this is the kind of stuff I'd like to see. Just create a remote
on behalf of the user with whatever unique name you want, (or use an
existing remote if one already exists for the given URL).

> Incidentally, I'm not seeing the case of wanting to track multiple
> branches from the same repository as nearly as likely for a novice as
> wanting to track multiple branches from different repositories.

Yes, I would agree with that.

> With the most common case for two tracking branches being master from two
> repositories, such that upstream branch names are most often useless for
> distinguishing anything.

Ah, that's an interesting point.

It's interesting because it's obviously the case for some projects,
but it's also not the case for some, (like the cairo project that I
care about). Maybe we're still overly accustomed to our "central"
mentality, but we don't really have a lot of interesting "master"
branches in our personal repositories. Instead, the central repository
has "master" and one branch for each stable maintenance series, then
each developer's personal repository has a collection of topic
branches for stuff that is cooking.

I guess we just don't have sub-maintainers maintaining entire
collections of patches with git like you get with the kernel for
example.

-Carl

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Making git disappear when talking about my code (was: Re: GIT vs Other: Need argument)

[Daniel Barkalow]

On Wed, 25 Apr 2007, Carl Worth wrote:

> On Wed, 25 Apr 2007 15:44:11 -0400 (EDT), Daniel Barkalow wrote:
> 
> > Here, you probably need to specify what you want the new branch to be,
> > because it will often be the case that the remote branch will be "master"
> > in a repository with a long unrecognizable URL, and you need to be able to
> > switch to and away from the branch in some sane way. On the other hand,
> > the user will presumably never care too deeply about the remote, aside
> > from that git remembers stuff appropriately. I say, use the hash of the
> > URL as the name of the remote, and provide some shorthand for the tracking
> > branch that would be merged by default into the current head, and you're
> > set. I.e.:
> >
> > git track new-name URL [branch]
> 
> OK, that still allows for pasting the URL and branch, but the user has
> to know not only "git track" but also that she must invent a local for
> the branch and insert that into the command as well. And it's hard for
> me to help the user on this point (at least in a cut-and-pasteable
> way), since the whole point of that argument is to create an entry in
> a private namespace that I don't know anything about.

Well, it's not only a private namespace, it's a namespace of stuff that 
should be meaningful to the user. Sure, there's a certain extent to which 
what's meaningful to the publisher is likely to be meaningful to the user, 
but I've used "subproject" to refer to a "submodule2" remote branch, 
because that's what I was naming the feature in my head, and I wouldn't 
have found the 2 intuitive in general (it was the second attempt at an 
implementation). It's fundamentally a local alias for a global name.

On the other hand, it might be good if the publisher could give 
instructions with an option that prompts the user with a sensible default, 
given the arguments and the state of the repository.

> > With the most common case for two tracking branches being master from two
> > repositories, such that upstream branch names are most often useless for
> > distinguishing anything.
> 
> Ah, that's an interesting point.
> 
> It's interesting because it's obviously the case for some projects,
> but it's also not the case for some, (like the cairo project that I
> care about). Maybe we're still overly accustomed to our "central"
> mentality, but we don't really have a lot of interesting "master"
> branches in our personal repositories. Instead, the central repository
> has "master" and one branch for each stable maintenance series, then
> each developer's personal repository has a collection of topic
> branches for stuff that is cooking.

I think there's likely to be a reasonably large variation in what 
repositories exist and what branches they have. People could easily have a 
repository per topic, with a branch per stable series (with experimental 
work being potentially queued for a relatively far future series). There 
could be shared repositories for features that multiple people work on, 
with per-person branches. People do all sorts of things, and even within a 
project, they don't all have to be the same, so long as the "URL branch" 
format works for everybody who has to get a branch. But that also means 
that it's hard to find a reliable meaningful sub-part of that format.

	-Daniel
*This .sig left intentionally blank*

Re: Making git disappear when talking about my code (was: Re: GIT vs Other: Need argument)

[Nicolas Pitre]

On Wed, 25 Apr 2007, Daniel Barkalow wrote:

> Linus has stated a preference on the lkml for being told about branches in 
> the syntax used for anonymous pulls: URL branchname.
> 
> That is, you say:
> 
>   Please pull from:
>     git://server/path branch
> 
> And he cuts and pastes into the command line:
> 
>   git pull git://server/path branch
> 
> Now, this syntax isn't available for git-clone, because git-clone puts the 
> optional directory to create after the URL. But, in an ideal world, this 
> is how it would work; you could see a pull request, and just type "git 
> some-command <paste>".

Maybe git-pull could be made usable just as well from an empty 
repository (isn't it already?) as a substitute for clone.


Nicolas

Re: GIT vs Other: Need argument

[Junio C Hamano]

Carl Worth <cworth@cworth.org> writes:

> So, currently, all non-default branches have a sort of second-class
> status from the point of view of users that just want to track
> them.

For some time when people compared hg and git they said git
supports multiple branches in repository more naturally.  And
using more than one branch in a single repository, especially in
one with a working tree, is more convenient for certain things,
such as comparing the branches (both "diff A B" and "log A..B").

But that does not necessarily mean we are forced to use as small
number of repositories as possible and use branches to represent
related work.

If for example all the kernel related repositories in kernel.org
were actually represented as a single repository with hundreds
of branches, with default set to Linus's 'master', people who
would want to track subsystem maintainers' trees would feel less
convenient as they always have to first clone (perhaps with -n
because they are not interested in a checkout of Linus's tree)
and then 'checkout -b' for the subsystem branch of their choice.

But that is not how the kernel group organize the repositories
for their project.  Each subsystem maintainer have his own tree
or trees, and a repository can be about a topic or various
degree of doneness.  So at that level, all repositories are
equal and it is just a matter of picking the right URL to clone
from.

Instead of trying to make each branch the target of 'clone'
intended for one class of audience as your message implies, you
could publish one repository (you might arrange them to share
the objects via alternates to reduce storage requirements, but
that is an implementation detail and invisible to your users)
per an intended class of your audience.  Your work, inside one
repository done on multiple branches, could be pushed into more
than one repositories, each of which has "the default" (and
possibly "only") branch set to point at the theme of your branch
in your local repository.

I think something like this might even work out of the box.  On
the public box you publish your branch A and B on, have three
repositories (i.e. number of branches plus one) like this:


	cw-master.git/
        cw-A.git/
        cw-B.git/

Everything under cw-$X.git (for X in A B) are symlinks to the
corresponding place in cw-master.git/, except HEAD.  Make
cw-A.git/HEAD points at refs/heads/A while cw-B.git/HEAD points
at refs/heads/B.

And the maintainer (you) would push into cw-master.git/ and tell
people about cw-$X.git repositories but not necessarily about
cw-master.git/ repository.

Do not complain that the above is cumbersome to set up, not just
yet.  That is not my point.  The point is that you are trying to
solve this from the consumer side, but I am wondering if this is
actually a problem on the publisher side.  And _if_ the problem
is on the publishing side, git-clone on the client side to track
different branch is not the way to solve that problem.  Rather,
git-clone (or maybe a new program git-publish-repository) to
make it easier to set up the publishing side might be what we
need.

Re: GIT vs Other: Need argument

[Johannes Schindelin]

Hi,

On Thu, 19 Apr 2007, Linus Torvalds wrote:

> On Thu, 19 Apr 2007, Johannes Schindelin wrote:
> 
> You can't *not* mention branches, simply because even people who only 
> track other peoples work do end up often needing to know about it, or at 
> least hearing about them..

Well, there is the classical case of an upstream which never merges from 
you, John R. Developer. You have two branches, upstream and local. But Jim 
R. Developer did not work with Git before, just CVS. To Jim, these are not 
two branches. Still, Git operations are easy, and Jim does not have to 
understand branches to track upstream (keeping local changes).

That is a very valid use scenario, at least from my point of view, since I 
use it quite often.

As an example, for me, "next" is upstream, and I keep some changes local, 
either because Junio refused to merge them, or because they are useful to 
nobody except me.

Of course, these _are_ two branches, but I don't have to realize that when 
working with Git in that manner.

Ciao,
Dscho

History cleanup/rewriting script for git

[Jan Harkes]

On Thu, Apr 19, 2007 at 09:43:50AM -0700, Linus Torvalds wrote:
> On Thu, 19 Apr 2007, Johannes Schindelin wrote:
> > Hmm. However, I have to say that cogito serves/d another purpose quite 
> > well: Look at what came from cogito into git. Loads of useful 
> > enhancements. So, I really have to point to "at this stage", because that 
> > sure was not true 18 months ago.
> 
> Absolutely. I think there are still some pieces of cogito that we might 
> want to migrate into git too, although they're fairly esoteric (ie the 
> whole history rewriting thing). And I think we still have some places 

I actually have a fairly simple history rewriting script (written in python)
that I used when I converted some CVS archives to git. It is really intended
for such an initial import and history cleanup case so it doesn't deal with
reflogs and such.

Basic workflow I used is,

- Import CVS archive into a git repository
- Use gitk + the grafts file to clean up history as much as feasible
- Run git-rewrite-history.py which will
    - write out new commit objects with the corrected set of parents
    - copy existing refs to .git/newrefs, pointing them at the new commits.

- start gitk --all to see the tree before the rewrite.
- mv .git/refs .git/oldrefs ; mv .git/newrefs .git/refs
- start a second gitk --all to see the tree after the rewrite.
- compare gitk output to check if everything matches up.

- run git repack/prune/gc to get rid of the old commits, or clone the repo.

Jan

--8<-----------------------------------------------------------------------

#!/usr/bin/python

import os, sys

def git_write_object(type, blob):
    stdin, stdout = os.popen2("git-hash-object -t %s -w --stdin" % type)
    stdin.write(blob)
    stdin.close()
    return stdout.readline().strip()

def git_commits(branch):
    f = os.popen('git-rev-list --parents --header --topo-order %s' % branch)
    buf = ''
    while 1:
	buf = buf + f.read(4096)
	if not buf: break
	if not '\0' in buf: continue
	commit, buf = buf.split('\0', 1)
	yield Commit(commit)

def git_update_ref(name, hash):
    os.system('git-update-ref "%s" "%s"' % (name, hash))

grafts = []
pending = []
rewriteable = []
remap = {}
todo = 0
class Commit:
    def __init__(self, commit):
	global grafts
	lines = commit.split('\n')
	parts = lines.pop(0).split()
	self.hash, self.parents = parts[0], parts[1:]

	self.tree = lines.pop(0)

	parents = []
	while lines[0][:7] == 'parent ':
	    parents = parents + lines.pop(0).split()[1:]

	if parents != self.parents:
	    grafts.append(self.hash)

	commit = []
	while 1:
	    line = lines.pop(0)
	    commit.append(line)
	    if not line: break

	for line in lines:
	    commit.append(line[4:])
	self.commit = '\n'.join(commit)

	self.wait = 0
	self.children = []

    def mark(self):
	global todo, pending
	self.wait = self.wait + 1
	if self.wait == 1:
	    todo = todo + 1
	    for child in self.children:
		pending.append(child.hash)

    def pick(self):
	global rewriteable
	self.wait = self.wait - 1
	if not self.wait:
	    rewriteable.append(self)

    def fixup(self, old_hash, new_hash):
	i = self.parents.index(old_hash)
	self.parents[i] = new_hash
	self.pick()

    def rehash(self):
	global todo, remap
	todo = todo - 1

	blob = self.tree + '\n'
	for parent in self.parents:
	    blob = blob + 'parent %s\n' % parent
	blob = blob + self.commit

	new_hash = git_write_object('commit', blob)
	remap[self.hash] = new_hash

	for child in self.children:
	    child.fixup(self.hash, new_hash)

print "Reading commits... ",
commits = {}
for commit in git_commits('--all'):
    commits[commit.hash] = commit
print "read %d commits, found %d grafts" % (len(commits), len(grafts))

print "Setting up reverse linkage"
for commit in commits.values():
    for parent in commit.parents:
	commits[parent].children.append(commit)

print "Propagating graft information... ",
# first mark all commits that will have to be rewritten.
for commit in grafts:
    commits[commit].mark()

for commit in pending:
    commits[commit].mark()

# pick those commits that do not depend on any earlier rewrites
for commit in grafts:
    commits[commit].pick()
print "%d commits need to be rewritten" % todo

print "Rewriting commits... "
while rewriteable:
    print "\rrewriting %5d/%5d commits" % (len(rewriteable), todo),
    rewriteable.pop().rehash()
print "done..."

print "Rewriting refs..."
for ref in os.popen('git-for-each-ref'):
    hash, type, name = ref.split()
    if type != 'commit': continue

    if remap.has_key(hash):
	hash = remap[hash]

    # write updated refs to .git/newrefs
    git_update_ref('new' + name, hash)

print "done..."

Re: History cleanup/rewriting script for git

[Johannes Schindelin]

Hi,

On Fri, 20 Apr 2007, Jan Harkes wrote:

> On Thu, Apr 19, 2007 at 09:43:50AM -0700, Linus Torvalds wrote:
> > On Thu, 19 Apr 2007, Johannes Schindelin wrote:
> >
> > > Hmm. However, I have to say that cogito serves/d another purpose 
> > > quite well: Look at what came from cogito into git. Loads of useful 
> > > enhancements. So, I really have to point to "at this stage", because 
> > > that sure was not true 18 months ago.
> > 
> > Absolutely. I think there are still some pieces of cogito that we 
> > might want to migrate into git too, although they're fairly esoteric 
> > (ie the whole history rewriting thing). And I think we still have some 
> > places
> 
> I actually have a fairly simple history rewriting script (written in 
> python) that I used when I converted some CVS archives to git.

Telling by your description, cg-admin-rewrite-hist is more capable. And I 
think it should not be too complicated to rewrite the cogito specific 
parts, what with the parts we added to Git with cogito as a model. And it 
is in Perl... which makes it more portable than Python in my part of the 
world.

Ciao,
Dscho

Re: History cleanup/rewriting script for git

[Petr Baudis]

On Fri, Apr 20, 2007 at 08:39:25PM CEST, Johannes Schindelin wrote:
> Telling by your description, cg-admin-rewrite-hist is more capable. And I 
> think it should not be too complicated to rewrite the cogito specific 
> parts, what with the parts we added to Git with cogito as a model. And it 
> is in Perl... which makes it more portable than Python in my part of the 
> world.

It is in shell, actually. (Well, bash, but I think [[ is the only
bashism in that one.) And it was specifically written to be as
independent of Cogito as possible, I think it uses only Cogito's cool
commandline parsing routines. ;-)

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Ever try. Ever fail. No matter. // Try again. Fail again. Fail better.
		-- Samuel Beckett

Re: History cleanup/rewriting script for git

[Jan Harkes]

On Fri, Apr 20, 2007 at 08:39:25PM +0200, Johannes Schindelin wrote:
> On Fri, 20 Apr 2007, Jan Harkes wrote:
> > On Thu, Apr 19, 2007 at 09:43:50AM -0700, Linus Torvalds wrote:
> > > On Thu, 19 Apr 2007, Johannes Schindelin wrote:
> > >
> > > > Hmm. However, I have to say that cogito serves/d another purpose 
> > > > quite well: Look at what came from cogito into git. Loads of useful 
> > > > enhancements. So, I really have to point to "at this stage", because 
> > > > that sure was not true 18 months ago.
> > > 
> > > Absolutely. I think there are still some pieces of cogito that we 
> > > might want to migrate into git too, although they're fairly esoteric 
> > > (ie the whole history rewriting thing). And I think we still have some 
> > > places
> > 
> > I actually have a fairly simple history rewriting script (written in 
> > python) that I used when I converted some CVS archives to git.
> 
> Telling by your description, cg-admin-rewrite-hist is more capable. And I 
> think it should not be too complicated to rewrite the cogito specific 
> parts, what with the parts we added to Git with cogito as a model. And it 
> is in Perl... which makes it more portable than Python in my part of the 
> world.

As I wrote this a while ago, before reflogs and packed refs, and I only
needed it for the initial conversion, it only had to write out new
commit objects and retarget branch heads and simple tags. If
cg-admin-rewrite-hist can do better and can be merged into git-core I
would say that is a win-win situation for everyone.

Something like this should be available to allow people to reconstruct
their merge history or fix up empty 'file was added on branch foo'
commits that are left around after the initial import from another VCS.

Personally, I don't think it should ever be used for any published
repositories or branches. Most fixups before publishing can already be
done by rebasing or amending a commit, so this would only be useful for
that intial import where there are in fact a lot of scattered changes
all over the place, or to reconstruct a merge that went bad. But really
in that case, it is probably better to redo the merge correctly and
rebase any commits that might have gone in after the bad merge.

Jan

Re: GIT vs Other: Need argument

[Marcin Kasperski]

> Actually, at this stage, I really think cogito just *complicates* git 
> usage. 

Agreed.

> So I don't think it's even true that new people should be pointed at cg 
> any more.

Google points to git.or.cz ;-)

> But compare setting up a git repository with setting up a CVS repository.
> With git, it's literally "git init", and you're done. No need to worry 
> about CVSROOT issues etc. Everything is self-contained. CVS is *hard* to 
> get into, by comparison.

I am in no way advocating CVS, but to be fair in such comparison, one
should mention also effort of *publishing* git repository and making it
available to remote clients. Initialized and configured CVS (or
subversion, or perforce, or ...) repo is something ready to be used by
remote clients.

Getting correct ssh keys in correct places is - for instance -
noticeable problem for many people. Especially if they use clients
(like plink) which natively use alternative key save format. Etc...

> So people coming from CVS/SVN have a double shock: they are supposed to 
> learn things that they "know" are hard (because CVS/SVN made them so damn 
> hard - don't tell me that SVN branching is easy, because it is *not* easy. 

The way SVN implemented branching (and tagging!) simply killed the idea
of using this tool seriously. IMO. Let's leave it.

I agree that git introduces plenty of excellent concepts. What it needs
is better docs (also, clearly known **SINGLE** master doc, just sth like
subversion book), cleaned command line interface (I feel that there are
just too many lowlevel commands visible for beginning user, maybe at
least one could split them into git-* for mere mortals and gitadm-* for
repository hackers), portability, and finally GUI.

				Best regards

Re: GIT vs Other: Need argument

[Johannes Schindelin]

Hi,

On Thu, 19 Apr 2007, Marcin Kasperski wrote:

[BTW: who said the following? You skipped that information.]

> > So I don't think it's even true that new people should be pointed at cg 
> > any more.
> 
> Google points to git.or.cz ;-)

How does Google point to something? You mean the last time you ran the 
search, the top find _for you_ was git.or.cz?

> > But compare setting up a git repository with setting up a CVS 
> > repository. With git, it's literally "git init", and you're done. No 
> > need to worry about CVSROOT issues etc. Everything is self-contained. 
> > CVS is *hard* to get into, by comparison.
> 
> I am in no way advocating CVS, but to be fair in such comparison, one
> should mention also effort of *publishing* git repository and making it
> available to remote clients. Initialized and configured CVS (or
> subversion, or perforce, or ...) repo is something ready to be used by
> remote clients.

No. Not at all. It took me _one day_ to publish my first CVS repository. 
It took me exactly 10 seconds to do that with Git.

If you are referring to readily-usable CVS services like sourceforge's, 
you are comparing apples with sentences.

> Getting correct ssh keys in correct places is - for instance -
> noticeable problem for many people. Especially if they use clients
> (like plink) which natively use alternative key save format. Etc...

I fail to see how you need ssh keys in order to publish a Git repository.

> I agree that git introduces plenty of excellent concepts. What it needs
> is better docs (also, clearly known **SINGLE** master doc, just sth like
> subversion book),

Does that mean you are volunteering?

> cleaned command line interface (I feel that there are
> just too many lowlevel commands visible for beginning user, maybe at
> least one could split them into git-* for mere mortals and gitadm-* for
> repository hackers),

Does that mean we can expect patches from you?

> portability,

Which platform are you having in mind?

> and finally GUI.

Does that mean you will provide patches? A good starting point is git-gui, 
IMHO.

Ciao,
Dscho

Re: GIT vs Other: Need argument

[Marcin Kasperski]

> > Google points to git.or.cz ;-)
> 
> How does Google point to something? You mean the last time you ran the 
> search, the top find _for you_ was git.or.cz?

Exactly. Searches for git documentation, git tutorial, git version
control pointed there.


> > I agree that git introduces plenty of excellent concepts. What it needs
> > is better docs (also, clearly known **SINGLE** master doc, just sth like
> > subversion book),
> 
> Does that mean you are volunteering?

No, as I do not have necessary knowledge. But I can volunteer to review
one.

> > cleaned command line interface (I feel that there are
> > just too many lowlevel commands visible for beginning user, maybe at
> > least one could split them into git-* for mere mortals and gitadm-* for
> > repository hackers),
> 
> Does that mean we can expect patches from you?

Not sure what is your point Johannes, but if you wanted to say that if
somebody is not actively developing git, he should not make any comments
regarding this, you could try doing this in a more straightforward
manner.

Re: GIT vs Other: Need argument

[Johannes Schindelin]

Hi,

On Thu, 19 Apr 2007, Marcin Kasperski wrote:

> > > cleaned command line interface (I feel that there are just too many 
> > > lowlevel commands visible for beginning user, maybe at least one 
> > > could split them into git-* for mere mortals and gitadm-* for 
> > > repository hackers),
> > 
> > Does that mean we can expect patches from you?
> 
> Not sure what is your point Johannes, but if you wanted to say that if 
> somebody is not actively developing git, he should not make any comments 
> regarding this, you could try doing this in a more straightforward 
> manner.

No. I said that tongue-in-cheek.

But my point was: Since the current developers evidently are comfortable 
with the current set of command line options, and the consistency thereof, 
it needs more than some hand waving comments about what you want changed, 
and how.

To state it clearly: if you have any concrete wishes as to the 
clarification of Git, and to make it easier for beginners (at the same 
time not making it harder on others), I will be very glad to know them. 
And I think that the list will welcome these equally eagerly.

Ciao,
Dscho

Re: GIT vs Other: Need argument

[J. Bruce Fields]

On Thu, Apr 19, 2007 at 02:42:39PM +0200, Marcin Kasperski wrote:
> > > I agree that git introduces plenty of excellent concepts. What it needs
> > > is better docs (also, clearly known **SINGLE** master doc, just sth like
> > > subversion book),
> > 
> > Does that mean you are volunteering?
> 
> No, as I do not have necessary knowledge. But I can volunteer to review
> one.

That would be great--see Documentation/user-manual.txt.  (Or
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html.)

Patches welcomed, but so is general review.  It's not my highest
priority, unfortunately, so I may be a little slow to address comments,
but I'll get to them eventually.

I don't expect it to ever be a *single* master doc--I still want to
leave a lot of the details to the man pages, for example, and I expect
there'll always be a need for some shortcut howto's and tutorials.   I
suppose we could include much of that into appendices some day if it
helped findability.

--b.

Re: GIT vs Other: Need argument

[Theodore Tso]

On Thu, Apr 19, 2007 at 02:33:31PM +0200, Johannes Schindelin wrote:
> > > So I don't think it's even true that new people should be pointed at cg 
> > > any more.
> > 
> > Google points to git.or.cz ;-)
> 
> How does Google point to something? You mean the last time you ran the 
> search, the top find _for you_ was git.or.cz?

I just checked today.  If you go to http://www.google.com, and enter
"git", and then click on "I'm feeling lucky", you will go to
http://git.or.cz.  One of the first links you will then see,
misleading titled in a box labelled, "Git crash courses", are "Git for
CVS users", and "Git for SVN users", and both of these getting started
documents reference cg commands and only cg commands.

So when projects downgrade git as having confusing documentation, and
tutorials that contradict each other about how to do things, this is
very likely one of the reasons why.

							- Ted

[ANNOUNCE] Cogito is for sale

[Petr Baudis]

On Wed, Apr 18, 2007 at 06:07:55PM CEST, Linus Torvalds wrote:
> Actually, at this stage, I really think cogito just *complicates* git 
> usage. It hasn't been well-supported lately, and asking for help with 
> cogito means that a lot of people can't help you. And you still end up 
> using git commands for anything fancier.

And at this stage, I actually rather agree.

I've been torn apart about this for few weeks now, struggling to get
some time (and strong motivation) to dive through the dusty cogito
patchqueues etc., and wondering what to actually *do* about Cogito.
I have been actually inclined to, hmm, "phase out" Cogito for some time
already, but then always some very nice mail from a Cogito user comes
and throws me in doubts. But this thread pushed me over the edge.  ;-)

I agree that by now, the situation is too confusing and while I'm not
happy with everything in Git, I believe that by now the best way is to
just fix Git. Therefore, I'm announcing that I don't plan to add any (at
least any significant) new features to Cogito. Sorry to all the Cogito
users, it is a hard decision for me, but by now I believe that it is
much more effective to just focus on Git.

If anyone else wants to take over Cogito maintainership, you're most
welcome: let me know, please! The "patch queue" means just filtering
=git mailbox, but I have some WIP code to add the .git/config "remotes"
support to Cogito, if you are interested.

Until someone else steps out to maintain Cogito, I'm not going to
abandon Cogito absolutely. I still plan to dive through the patch queue
as soon as possible and then continue integrating bugfixes and/or
smaller-scale changes necessary for newer Git versions. I'll maybe also
write a trivial more-or-less 1:1 cg->git porcelain wrapper for those
who trained their fingers to 'cg' instead of 'git'; but maybe it's best
just to retrain. ;-)


About git homepage:

The very least I wanted to do at any rate with git.or.cz ASAP is to
switch the crash courses to git-oriented ones too. I think git more or
less got to a reasonable point when this is a sane idea. Do you have any
tips on exactly what zero-level introductory material I should put there
instead of the Cogito crash courses, or should we write new ones
(perhaps based on the current ones)? I probably won't have much time to
write a lot of stuff, but I'll gladly use whatever reasonable anyone
suggests/writes, and I have no qualms to just give well-known people
push access to the homepage repository.

Live and prosper,

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Ever try. Ever fail. No matter. // Try again. Fail again. Fail better.
		-- Samuel Beckett

Re: [ANNOUNCE] Cogito is for sale

[Matthieu Moy]

Petr Baudis <pasky@suse.cz> writes:

> Therefore, I'm announcing that I don't plan to add any (at least any
> significant) new features to Cogito.

I believe this is the right decision, but anyway, thanks for your work
on cogito!

-- 
Matthieu

Re: [ANNOUNCE] Cogito is for sale

[Junio C Hamano]

Petr Baudis <pasky@suse.cz> writes:

> I agree that by now, the situation is too confusing and while I'm not
> happy with everything in Git, I believe that by now the best way is to
> just fix Git. Therefore, I'm announcing that I don't plan to add any (at
> least any significant) new features to Cogito. Sorry to all the Cogito
> users, it is a hard decision for me, but by now I believe that it is
> much more effective to just focus on Git.

I applaud this; I know this must have been a hard decision for
you to make.

> About git homepage:
>
> The very least I wanted to do at any rate with git.or.cz ASAP is to
> switch the crash courses to git-oriented ones too. I think git more or
> less got to a reasonable point when this is a sane idea.

I would agree, at this point.

When git.or.cz started offering those introductory pages, the
Porcelain-ish scripts (that is correct, "scripts", as there were
no "built-in" -- even "git diff" unified driver was a shell
script to driver diff-index, diff-files and diff-tree) shipped
with the core git was infinitely less pleasant to normal people,
especially the ones who have not seen the early days of git core
which shipped with almost none.  When you and I talked about
what text to put on git.or.cz, it was an obvious and easy thing
to agree on that newbie documentation should be based on Cogito,
and you did all the work to put the site together.

    I am saying this now for new people on the list, as I heard
    an incorrect "theory" that you have been advertising Cogito
    on git.or.cz site against the community's best interest,
    even when nobody seems to talk about it these days on the
    list anymore.

Since the early days of my involvement in git project, I said my
goal was to keep the plumbing stable, enhance the plumbing in
such a way that any and all Porcelains can do what they want
without resorting to Porcelain-specific hacks, so that the
resulting repositories can interoperate no matter what Porcelain
was used on top of the plumbing.  I worded that goal as "make
the choice of Porcelains irrelevant".  While that ideal still
stands, we ended up having rich enough Porcelain in the core
distribution.  To some people, this might look as if we are
making alternative Porcelains irrelevant instead, but that is
not the case.  Many features and workflows that are now
supported by the core Porcelain were first invented outside
(e.g. "automated tag following while fetching" came from
Cogito), and the core Porcelain does not ship with special
purpose features and expect alternative/augmentative Porcelains
to fill the niche (an existing example is that people who want
patch management use StGIT or guilt).  I am reasonably sure that
there still are features and workflows that Cogito supports
better, and given time and motivated users and contributors,
hopefully they will be ported to the core Porcelain.

I would thank you for your effort to ease adoption of git family
of tools to new people with Cogito; I would ask the list to do
the same.

And I look forward to see your continued involvement to make git
better.

Re: [ANNOUNCE] Cogito is for sale

[Johannes Schindelin]

On Thu, 19 Apr 2007, Junio C Hamano wrote:

> I would thank you for your effort to ease adoption of git family of 
> tools to new people with Cogito; I would ask the list to do the same.

Definitely. Thanks, Pasky. A lot of the user-friendliness we have in Git 
now, as opposed to, say, June 2005, is because of cogito. It was sort of a 
"next" for ui enhancements, and it is sort of sad that this is gone now.

Ciao,
Dscho

Re: GIT vs Other: Need argument

[Johannes Schindelin]

Hi Marcin,

[re-Cc:ing list]

On Thu, 19 Apr 2007, Marcin Kasperski wrote:

> 
> > > a) Windows are unsupported
> > 
> > Wrong.
> 
> He he, I even downloaded minGW version, just to find that git-pull is 
> bash script...

So what? Do you think a Python program is a native Windows application?

> > > b) Learning curve is too steep. Unclear relationship git-vs-cogito 
> > > makes it even worse.
> > 
> > Not so wrong. But then, it is clear that git is git is git. If you 
> > find it too complicated, soon enough somebody says "use cogito 
> > instead" and you'll find out about that.
> 
> As I already said: cogito at the moment does not make life easier, but 
> only confuses. Also, we talked about windows in previous sentence, 
> cogito is a bunch of shell scripts...

Again, so what?

> > I mean, you can do with CVS, SVN, HG, etc. almost the same as with 
> > Git. But with Git, I find it faster and easier. BTW much of that does 
> > come from the scriptable nature of Git. It _is_ much easier to write a 
> > short and simple script than to work on a plugin.
> 
> That's double edged sword. The more useful shell scripts, the more 
> unportable tool.

Wrong.

Wrong, wrong, wrong. Shell runs on more machines than Python, for example. 
And if you do not use things like bash arrays, scripts are _perfectly_ 
portable.

It's the same as with HTML. If you really want to make life hard on users, 
you can make it unportable. Alas, that's what most web designers in their 
infinite wisdom do.

Besides, it is not the length of a shell script which makes it unportable. 
For example, some aspects of cogito scripts prevented me from using it. So 
much that I gave up on it.

There are other reasons to prefer C over shell, performance comes to mind.

Ciao,
Dscho

Re: GIT vs Other: Need argument

[Marcin Kasperski]

(I am not trying to make flame-war, so I restrict to 

> > He he, I even downloaded minGW version, just to find that git-pull is 
> > bash script...
> 
> So what? Do you think a Python program is a native Windows application?

Who cares... Mercurial binary build distributes hg as .exe (made by
py2exe or some other converter). The net point is that when I type 'hg'
in windows console, I get running mercurial. When I type 'git-pull' I
get error.

> > That's double edged sword. The more useful shell scripts, the more 
> > unportable tool.
> 
> Wrong.
> 
> Wrong, wrong, wrong. Shell runs on more machines than Python, for example. 
> And if you do not use things like bash arrays, scripts are _perfectly_ 
> portable.

Hmm. At the moment I am using more or less frequently: Debian Linux,
Tru64 Unix, OpenVMS, Windows XP. Python works well on all of those.
Shell scripts work on the first one and partially on the second one.

(yesss, I tried using Cygwin, this is NOT the way to go)

Re: GIT vs Other: Need argument

[Johannes Schindelin]

Hi,

On Thu, 19 Apr 2007, Marcin Kasperski wrote:

> > And if you do not use things like bash arrays, scripts are _perfectly_ 
> > portable.
> 
> Hmm. At the moment I am using more or less frequently: Debian Linux,
> Tru64 Unix, OpenVMS, Windows XP. Python works well on all of those.
> Shell scripts work on the first one and partially on the second one.
> 
> (yesss, I tried using Cygwin, this is NOT the way to go)

Heh, without an explanation as to why, this sure sounds like an invitation 
to a very flamy war.

Ciao,
Dscho

Re: GIT vs Other: Need argument

[Marcin Kasperski]

> but git is definitely no harder to learn 
> than anything else.  I browsed through the mecurial tutorial 
> yesterday - and as well as being significantly less powerful than git, 
> it's no easier.

Mercurial is easier to learn, because it has better docs and slightly
simpler command line (all those -a, -p, ... options which one always
forgets to add). I tried it.
In fact, I did the experiment about month ago. I wanted to give a try
to distributed vc tool. I started from GIT, played a bit with it, and
abandoned it because a) I did not know whether I am expected to use git,
or cg, b) While reading docs many times I had the feeling that something
strange and unclear is going behind the hood.

Then I took mercurial and in a few hours I felt I know all the important
things.

> (I can't believe this one - if you want to branch a mercurial repository 
> you have to have another complete checkout.  Erm... the checkout takes 
> up more space than the repository - why do I need another copy? Anyway, 
> git is no harder than Mercurial here)

AFAIK you are wrong, they are able to link some files while cloning, so
you loose space only if you switch machine or filesystem. Also, recent
mercurial has initial within-repo branches support. But I am not really
the best person to conduct git-vs-hg discussion.

> "(Note for Windows users: Mercurial is missing a merge program" - that 
> Windows support isn't looking quite so hot now.

Mercurial on windows works well with kdiff3 or tortoisemerge, you must
only install one of them. 

> > c) Lack of reasonable subproject support (plus detailed permission
> > model).
> 
> Mercurial has no native subproject support either - it requires a 
> plugin, git's is in development.

As I said, I am not conducting hg-vs-git discussion. I just happened 
to introduce and manage VC system in corporate environment, so I am able
to point that this is important feature.

> As for permissions, well Shawn has often spoken of his hook scripts that 
> implement very strong permissions (and he has done so again in this 
> thread).

I am not quite sure how can you forbid johny to see the code
in ./secret, while johny must checkout whole repo...

Permissions are not only about writing.

> Depends what you want - I installed cygwin 

This is really not an option for typical windows user. Believe me.
Maybe it could be, if cygwin managed to create normal setup program
one day...

Let me retype it: I am not complaining. GIT developers are not forced to
think about win users, or about corporate needs. But if they are, it is
reasonable to know the problems.

Re: GIT vs Other: Need argument

[Alex Riesen]

On 4/19/07, Marcin Kasperski <Marcin.Kasperski@softax.pl> wrote:
>
> Let me retype it: I am not complaining. GIT developers are not forced to
> think about win users, or about corporate needs. But if they are, it is
> reasonable to know the problems.
>

Windows (and, by extension, most corporate) users are used to both:
complain and suffer. What they cannot imagine is _doing_ something.
It just does not fit in their heads.

A user feels the need to restrict access to some trees in a git repository?
He'll start looking, asking, and maybe even raving about the missing
feature on some official channel. What never occurs to him is just
implementing it. And he'll be outraged if you suggest it (and, yes, it was
tried. The person felt insulted and is sulking till this day)

Besides, it looks like we need them: the stupid, lazy and numerous
windows users. I sometimes ask myself what for did I try to explain
merging and distributed workflow to my peers? The most reasonable
answer so far: so they don't bother me with their stupid work flow.
Don't like it though: people don't like to be called stupid (or anything
they do), and I happen to like most of them anyway.
And I start coding workarounds (the recent is git-remote, why the
hell must it be coded in perl?)

Re: GIT vs Other: Need argument

[Andy Parkins]

On Thursday 2007 April 19 12:59, Marcin Kasperski wrote:
> > but git is definitely no harder to learn
> > than anything else.  I browsed through the mecurial tutorial
> > yesterday - and as well as being significantly less powerful than git,
> > it's no easier.
>
> Mercurial is easier to learn, because it has better docs and slightly
> simpler command line (all those -a, -p, ... options which one always
> forgets to add). I tried it.
> In fact, I did the experiment about month ago. I wanted to give a try
> to distributed vc tool. I started from GIT, played a bit with it, and
> abandoned it because a) I did not know whether I am expected to use git,
> or cg, b) While reading docs many times I had the feeling that something
> strange and unclear is going behind the hood.

In terms of normal operation, there aren't many switches one actually needs to 
remember.  The only one I can think of is "-a" for commit - however, that's 
just to make it work like mercurial - a seasoned git user won't use many 
switches.  My daily grind consists of

 git add file.c
 git commit
 git add file.c
 git commit
 git add -i
 git commit

(Interactive mode for git-add is a joy to use - I don't know if Mercurial has 
anything similar).

Now, to your point.  I think you're right.  What I said was that git actually 
is easier; however if you looked at some of the documentation you would 
incorrectly assume that that was not the case.

> > (I can't believe this one - if you want to branch a mercurial repository
> > you have to have another complete checkout.  Erm... the checkout takes
> > up more space than the repository - why do I need another copy? Anyway,
> > git is no harder than Mercurial here)
>
> AFAIK you are wrong, they are able to link some files while cloning, so

Can't be.  I'm talking about the working directory not the repository - if the 
files are linked back to the originals, then it's not a separately editable 
set of files is it?

> you loose space only if you switch machine or filesystem. Also, recent
> mercurial has initial within-repo branches support. But I am not really
> the best person to conduct git-vs-hg discussion.

I'm glad that Mercurial is getting in-repo branches, they're great.  I really 
wouldn't want to live without them now I have them.

> > "(Note for Windows users: Mercurial is missing a merge program" - that
> > Windows support isn't looking quite so hot now.
>
> Mercurial on windows works well with kdiff3 or tortoisemerge, you must
> only install one of them.

Aren't they manual merge tools?  I think "merge" is for merging automatically, 
and moaning about conflicts if they turn up - /then/ you go to tortoisemerge.

> As I said, I am not conducting hg-vs-git discussion. I just happened
> to introduce and manage VC system in corporate environment, so I am able
> to point that this is important feature.

I appreciate that - I don't want to start a fight.  My point should probably 
have been more directly focussed on git (which was what I wanted to do) - 
it's my opinion that git is in fact easier than Mercurial; however, it's 
public face is not letting people see that.

> > As for permissions, well Shawn has often spoken of his hook scripts that
> > implement very strong permissions (and he has done so again in this
> > thread).
>
> I am not quite sure how can you forbid johny to see the code
> in ./secret, while johny must checkout whole repo...

Me either - the only permissions that could have been relevant are those 
needed to push to the central repository.  As I said, git can cope there 
without trouble.

> Permissions are not only about writing.

That one is true - perhaps one day git will get partial clone support to match 
it's shallow clones - then it would be possible to put permissions on the 
read of a central repository.  Can Mercurial do that?

> > Depends what you want - I installed cygwin
>
> This is really not an option for typical windows user. Believe me.
> Maybe it could be, if cygwin managed to create normal setup program
> one day...

I'm not an expert in Windows by any means - all I did was run setup.exe and 
picked git and ssh from the list.  It doesn't get much easier.

> Let me retype it: I am not complaining. GIT developers are not forced to
> think about win users, or about corporate needs. But if they are, it is
> reasonable to know the problems.

Absolutely - I certainly haven't taken anything you've written as a complaint.  
If anything I find it interesting because I think it confirms what I 
thought - git is not short on features or usability, it's just got a PR 
problem.


Andy
-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com

Re: GIT vs Other: Need argument

[Shawn O. Pearce]

Marcin Kasperski <Marcin.Kasperski@softax.pl> wrote:
> > As for permissions, well Shawn has often spoken of his hook scripts that 
> > implement very strong permissions (and he has done so again in this 
> > thread).

I just posted it as a contrib patch.  Maybe Junio will be willing
to carry it around in his tree.  If not, gmane now has it.  :-)
 
> I am not quite sure how can you forbid johny to see the code
> in ./secret, while johny must checkout whole repo...
> 
> Permissions are not only about writing.

Indeed.  But subsetting a repository by path like that is ugly
in any DVCS.  Which is why most don't do it.  Probably better
to subset by repository, aka the subproject support.

Because odds are that if you are hiding a directory (johny cannot see
./secret) then you probably also need to hide all commit messages of
all commits that affected ./secret too.  And if those commits were to
also modify stuff in ./public, then that starts to get really iffy.
Better to just make a very clear distinction at the repository level.
 
> > Depends what you want - I installed cygwin 
> 
> This is really not an option for typical windows user. Believe me.
> Maybe it could be, if cygwin managed to create normal setup program
> one day...

Yea.  I've had a number of Git users get burned by the
git-merge-recursive script changing to git-merge-recursive.exe,
and Cygwin's installer left git-merge-recursive in the directory
when upgrading, but deleted some of the supporting Python modules.
So they were unable to execute a merge.

Better, one user succeeded in doing a `git merge -s ours foo`,
completely tossing away the work of 20+ users over 3 months,
because their HEAD was very old and their merge-recursive was
utterly broken...  They did not mean to do an ours style merge, it
just happened that merge-recursive didn't do squat...  because it
was the old Python version, partially installed...

I found out about the breakage only after those 20+ users managed
to cram another 80 or so commits onto the top of that bad merge.
Which meant that I couldn't just rewind the tree to redo the merge.
I actually had to redo the merge as a new commit ontop of the bad
history.  Without losing any of the new changes.  Ick.

Thankfully just the week before I taught merge-recursive how to
take trees (and not commits), allowing me to use it to carry the
changes through whilest ignoring the bad merge base history.

So anyway, my Git-on-Cygwin installer is now:

	...on the master system...
	make clean &&
	make prefix=/usr/local/git &&
	rm -rf /usr/local/git &&
	make install prefix=/usr/local/git &&
	tar jcf update-git.tar.bz2 /usr/local/git

	...and on other systems...
	cd / &&
	rm -rf /usr/local/git &&
	tar jxf update-git.tar.bz2

because dammit, that works, all of the time.  Unlike Cygwin's
setup.exe.

-- 
Shawn.

Re: GIT vs Other: Need argument

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Shawn O. Pearce on 4/20/2007 12:22 AM:
>> Maybe it could be, if cygwin managed to create normal setup program
>> one day...
> 
> Yea.  I've had a number of Git users get burned by the
> git-merge-recursive script changing to git-merge-recursive.exe,
> and Cygwin's installer left git-merge-recursive in the directory
> when upgrading, but deleted some of the supporting Python modules.
> So they were unable to execute a merge.

Please report these sorts of bugs to the cygwin list, so that the cygwin
team can be aware of them and work towards fixing them.

> 
> Better, one user succeeded in doing a `git merge -s ours foo`,
> completely tossing away the work of 20+ users over 3 months,
> because their HEAD was very old and their merge-recursive was
> utterly broken...  They did not mean to do an ours style merge, it
> just happened that merge-recursive didn't do squat...  because it
> was the old Python version, partially installed...
> 
> I found out about the breakage only after those 20+ users managed
> to cram another 80 or so commits onto the top of that bad merge.
> Which meant that I couldn't just rewind the tree to redo the merge.
> I actually had to redo the merge as a new commit ontop of the bad
> history.  Without losing any of the new changes.  Ick.
> 
> Thankfully just the week before I taught merge-recursive how to
> take trees (and not commits), allowing me to use it to carry the
> changes through whilest ignoring the bad merge base history.
> 
> So anyway, my Git-on-Cygwin installer is now:
> 
> 	...on the master system...
> 	make clean &&
> 	make prefix=/usr/local/git &&
> 	rm -rf /usr/local/git &&
> 	make install prefix=/usr/local/git &&
> 	tar jcf update-git.tar.bz2 /usr/local/git
> 
> 	...and on other systems...
> 	cd / &&
> 	rm -rf /usr/local/git &&
> 	tar jxf update-git.tar.bz2
> 
> because dammit, that works, all of the time.  Unlike Cygwin's
> setup.exe.
> 

- --
Don't work too hard, make some time for fun as well!

Eric Blake             ebb9@byu.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGKLoa84KuGfSFAYARAlVwAKCL++zyeKO5iomF/gUQuRP6+N5qkgCfZpHa
3OrAwLmpJ4IbFpUiuj27jRw=
=Dyjw
-----END PGP SIGNATURE-----

Re: GIT vs Other: Need argument

[Guilhem Bonnefille]

On 4/17/07, Andy Parkins <andyparkins@gmail.com> wrote:
> On Tuesday 2007, April 17, Guilhem Bonnefille wrote:
> > I'm new to Git, but completly crazy of it.
> >
> > In my point of view, in corporate team, lot of people does not
> > want/need the power offered by Git.
> > So, my conclusion is the better model in a corporate is a centralyzed
> > repo with some users using Git as "frontend". Other people will
> > simply use the native tools for accessing the repo.
>
> Git has you covered there - it works better than other version control
> systems for that model too.  I do it all the time; the only difference
> is that with git it's not the tool doesn't force the choice on you.
>
> If you want a central repo, just make one - designate one repository as
> central, put it in the .git/config file for each of the others and away
> you go.  Pretend it's centralised if you want; you and your colleagues
> need never know otherwise.

In fact, the most important problem (in my case) is that there are
people that really don't want/need Git features. These people consider
that CVS/SVN are constraints and not usefull tools. They are not
interested in what a VCS can offer. I have success with CVS/SVN
because we now use Eclipse which offers an easy to use GUI for CVS/SVN
actions.
An other point is that CVS/SVN actions for our developers are
"trivial": update or commit, nothing more (even tags are made by
"power" users, so working with branches...). With Git, you have to
ALWAYS remember that you have a repo locally which is different than
the central repo. I think this point is quite confusing for people not
interested in the features offered by having a "private" repo.

This is why I think my corporate friends will brake if I try to
propose Git for everybody.

In my mind, git-svn or even git-svnserve, are THE tools to introduce
Git in teams not convinced by the power of DVCS. Or perhaps someone
will create a porcelain that offers the same simple interface of
CVS/SVN and will integrate it in all the fantastic IDE ;-)
-- 
Guilhem BONNEFILLE
-=- #UIN: 15146515 JID: guyou@im.apinc.org MSN: guilhem_bonnefille@hotmail.com
-=- mailto:guilhem.bonnefille@gmail.com
-=- http://nathguil.free.fr/

Re: GIT vs Other: Need argument

[Andy Parkins]

On Wednesday 2007 April 18 13:40, Guilhem Bonnefille wrote:

> An other point is that CVS/SVN actions for our developers are
> "trivial": update or commit, nothing more (even tags are made by

> In my mind, git-svn or even git-svnserve, are THE tools to introduce
> Git in teams not convinced by the power of DVCS. Or perhaps someone
> will create a porcelain that offers the same simple interface of
> CVS/SVN and will integrate it in all the fantastic IDE ;-)

It's already there.  The git porcelain can do almost anything.  If you were so 
inclined you could write a fake svn command that translated all those calls 
to git.

svn add = git add
svn update = git pull
svn commit = git commit -a && git push

I'm fairly convinced that the reason everyone thinks git is hard is because 
they're introduced to too much of it too quickly.

git /is/ easy.  It's more powerful, so there are more knobs, but if you don't 
want to use those knobs - don't.



Andy
-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com

Re: GIT vs Other: Need argument

[Steven Grimm]

Andy Parkins wrote:
> svn update = git pull
>   

That's not quite equivalent, and it's one of the biggest annoyances svn 
users seem to have when starting up with git in my observation (having 
gone through it myself and watched a few other people at my company do 
so.) svn update will merge upstream changes into your locally edited but 
not yet committed files. git pull will just complain if you have 
uncommitted local edits to files that changed upstream.

To avoid that problem, my workflow often looks like

git commit -a -m "dummy revision"
git fetch
git rebase origin/master
git reset --soft HEAD^

which IMO is something the tool should be doing for me. Cogito's 
cg-update would do this for me, but Cogito hasn't kept up with recent 
git changes so aside from cg-admin-rewritehist I never use it. Please 
tell me if the above is doable in fewer commands, by the way.

-Steve

Re: GIT vs Other: Need argument

[Jakub Narebski]

Steven Grimm wrote:

> Andy Parkins wrote:
>> svn update = git pull
>>   
> 
> That's not quite equivalent, and it's one of the biggest annoyances svn 
> users seem to have when starting up with git in my observation (having 
> gone through it myself and watched a few other people at my company do 
> so.) svn update will merge upstream changes into your locally edited but 
> not yet committed files. git pull will just complain if you have 
> uncommitted local edits to files that changed upstream.

In my opinion the update-then-commit workflow CVS and SVN forces on users
is one of the more annoying features, forcing the user to resolve conflicts
if he/she wants to be up-to-date.

The update-then-commit assumes that you merge on update local modifications
with current server version, assuming that ancestor is current local
committed version. This makes off-line committing impossible, and makes
rare updates (server version advanced by more than one commit) unnecessary
hard.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: GIT vs Other: Need argument

[Steven Grimm]

Jakub Narebski wrote:
> In my opinion the update-then-commit workflow CVS and SVN forces on users
> is one of the more annoying features, forcing the user to resolve conflicts
> if he/she wants to be up-to-date.
>   

I'm not eager to jump to svn's defense -- there's a reason I'm using git 
and trying to get my coworkers to do the same -- but how does git allow 
you to stay up to date without resolving conflicts? Granted that git is 
smarter about resolving certain kinds of conflicts automatically, but 
fundamentally if the latest revision you've pulled down (from any kind 
of version control system) makes a change that conflicts with a local 
change (whether or not you've committed it locally first) you're going 
to have to resolve it by hand, yes?

Also, last I checked, git wouldn't let me push into a branch that had 
revisions I hadn't yet pulled down. Isn't that just another way of 
enforcing an update-then-commit workflow? If anything, svn wins in that 
area -- it allows me to commit without updating as long as my change 
doesn't touch any files that have changed upstream.

One can argue about whether allowing partial commits like that is a good 
idea, but it's just not true that svn forces you to always update before 
you commit, and if you're pushing into a branch that other people are 
also updating, the ability to commit files that didn't change upstream 
means it is actually *less* insistent on update-then-commit than git is 
(if you take "commit" to mean "commit-and-push" on the git side as was 
suggested in the message I replied to originally.)

Unless, of course, I'm misinterpreting you here.

> The update-then-commit assumes that you merge on update local modifications
> with current server version, assuming that ancestor is current local
> committed version. This makes off-line committing impossible, and makes
> rare updates (server version advanced by more than one commit) unnecessary
> hard.

That last point is completely counter to my experience. At my company 
(where the svn repository is still the official code base) the 
repository is constantly changing. I'll sometimes let hundreds or even 
thousands of revisions go by between updates of my svn client. When I'm 
at a good point to do integration testing and I'm using an svn client 
instead of a git-svn one, I type "svn up", do roughly the same manual 
conflict resolution I'd do after a "git pull" that brought down a 
similar number of new revisions -- often none at all if I'm the only one 
working on a particular corner of the code base -- and I'm good to go. 
What's unnecessarily hard about that? How would it be any better in git?

Local commit capability is absolutely a huge win in git, though, and is 
one of the main features I use to sell people on it internally. No 
argument there. I just don't like being *forced* to do a local commit 
when I have no reason to do so other than to satisfy the version control 
tool. I end up either cluttering my history with dummy revisions or 
having to type extra commands to get rid of them.

And in particular -- this being the original topic of the thread -- when 
an svn user sees me doing that, they do not immediately think of the 
fact that merging between immutable revisions may have some benefits. 
They see me typing four commands (commit, fetch, rebase, reset) to do 
the same thing they can do in one command with svn, and conclude that 
git is harder to use. That some of them choose to use it anyway is a 
testament to how great git is in other areas.

-Steve

Re: GIT vs Other: Need argument

[Jakub Narebski]

Steven Grimm wrote:
> Jakub Narebski wrote:

>> In my opinion the update-then-commit workflow CVS and SVN forces on users
>> is one of the more annoying features, forcing the user to resolve conflicts
>> if he/she wants to be up-to-date.
>>   
> 
> I'm not eager to jump to svn's defense -- there's a reason I'm using git 
> and trying to get my coworkers to do the same -- but how does git allow 
> you to stay up to date without resolving conflicts? Granted that git is 
> smarter about resolving certain kinds of conflicts automatically, but 
> fundamentally if the latest revision you've pulled down (from any kind 
> of version control system) makes a change that conflicts with a local 
> change (whether or not you've committed it locally first) you're going 
> to have to resolve it by hand, yes?

The answer is that in git you can separate _having_ most current version
from the server (git fetch) and _merging_ your work with current version
from the server (git pull).

> Also, last I checked, git wouldn't let me push into a branch that had 
> revisions I hadn't yet pulled down. Isn't that just another way of 
> enforcing an update-then-commit workflow? If anything, svn wins in that 
> area -- it allows me to commit without updating as long as my change 
> doesn't touch any files that have changed upstream.
> 
> One can argue about whether allowing partial commits like that is a good 
> idea, but it's just not true that svn forces you to always update before 
> you commit, and if you're pushing into a branch that other people are 
> also updating, the ability to commit files that didn't change upstream 
> means it is actually *less* insistent on update-then-commit than git is 
> (if you take "commit" to mean "commit-and-push" on the git side as was 
> suggested in the message I replied to originally.)
> 
> Unless, of course, I'm misinterpreting you here.

I just think the commit _then_ merge (or commit-then-update) workflow is
much, much better than update-then-commit one.

-- 
Jakub Narebski
Poland

Re: GIT vs Other: Need argument

[Johannes Schindelin]

Hi,

On Thu, 19 Apr 2007, Jakub Narebski wrote:

> Steven Grimm wrote:
>
> > One can argue about whether allowing partial commits like that is a 
> > good idea, but it's just not true that svn forces you to always update 
> > before you commit, and if you're pushing into a branch that other 
> > people are also updating, the ability to commit files that didn't 
> > change upstream means it is actually *less* insistent on 
> > update-then-commit than git is (if you take "commit" to mean 
> > "commit-and-push" on the git side as was suggested in the message I 
> > replied to originally.)
> > 
> > Unless, of course, I'm misinterpreting you here.
> 
> I just think the commit _then_ merge (or commit-then-update) workflow is 
> much, much better than update-then-commit one.

Let me pick up the ball here. Once you did your share of conflicting 
merges, you _will_ realize how much better it is to merge when you are at 
a relatively stable state, i.e. you can test things (if only to make sure 
that the merge did not introduce strange side effects). And guess what, at 
such a stage I would commit anyway.

It is so much easier to resolve conflicts if you can look at both sides, 
and can actually go to both sides to test things out, or even just 
generate the diff to one side. This is just not possible with a dirty 
merge. Exactly because you knowingly lost the current state, you cannot do 
diffs with it.

Needless to say (but I do it nevertheless, since I am in a chatty mood), I 
_never_ can be seen doing the 4-command equivalent of `svn up`. I only 
pull when I have a clean state. (Note: this also leads to a more 
structured way of working, which does prevent errors.)

Ciao,
Dscho

Re: GIT vs Other: Need argument

[Julian Phillips]

On Thu, 19 Apr 2007, Johannes Schindelin wrote:

> Hi,
>
> On Thu, 19 Apr 2007, Jakub Narebski wrote:
>
>> Steven Grimm wrote:
>>
>>> One can argue about whether allowing partial commits like that is a
>>> good idea, but it's just not true that svn forces you to always update
>>> before you commit, and if you're pushing into a branch that other
>>> people are also updating, the ability to commit files that didn't
>>> change upstream means it is actually *less* insistent on
>>> update-then-commit than git is (if you take "commit" to mean
>>> "commit-and-push" on the git side as was suggested in the message I
>>> replied to originally.)
>>>
>>> Unless, of course, I'm misinterpreting you here.
>>
>> I just think the commit _then_ merge (or commit-then-update) workflow is
>> much, much better than update-then-commit one.
>
> Let me pick up the ball here. Once you did your share of conflicting
> merges, you _will_ realize how much better it is to merge when you are at
> a relatively stable state, i.e. you can test things (if only to make sure
> that the merge did not introduce strange side effects). And guess what, at
> such a stage I would commit anyway.
>
> It is so much easier to resolve conflicts if you can look at both sides,
> and can actually go to both sides to test things out, or even just
> generate the diff to one side. This is just not possible with a dirty
> merge. Exactly because you knowingly lost the current state, you cannot do
> diffs with it.

Not only that, but there is then a _record_ that Joe Developer had to 
merge your work into his (or vice versa) ...

-- 
Julian

  ---
"MacDonald has the gift on compressing the largest amount of words into
the smallest amount of thoughts."
 		-- Winston Churchill

Re: GIT vs Other: Need argument

[Steven Grimm]

Johannes Schindelin wrote:
> Let me pick up the ball here. Once you did your share of conflicting 
> merges, you _will_ realize how much better it is to merge when you are at 
> a relatively stable state, i.e. you can test things (if only to make sure 
> that the merge did not introduce strange side effects). And guess what, at 
> such a stage I would commit anyway.
>   

That's a great workflow if you're working on relatively discrete, 
standalone changes. A lot of the time, when I'm working on an isolated 
change, I do just that, and I merge when I'm stable just like you 
describe. That's probably the vastly most common mode of operation for 
distributed open-source projects, which obviously were git's initial 
target audience.

However, it is frequently NOT the mode of operation for development at a 
company where two or more people are working on implementing the same 
new feature in a highly collaborative way, often sitting across the room 
from one another. In that situation, it's frequently the case that, for 
example, I'm coding and discover I need some new utility method that Joe 
can easily factor out of the code he just checked in. So he does his 
quick refactoring, commits that change, and I pull it into my sandbox 
where I am *not* yet at a stable stopping point because I was waiting 
for his change in order to finish and/or test my change. Or, more 
commonly, I discover a bug in his code and he checks in a fix I want to 
pick up.

That's the use case for dirty working-copy merges. It is extremely 
common in my experience. Actually I can't think of a single company I've 
worked at in ~20 years of professional programming, from huge ones to 
small startups, where that wasn't a frequent working style, especially 
during crunch times or initial implementation.

The XP people even have a name for it: "continuous integration." 
(Granted, that's not *exactly* what that term means, but "update early 
and often" is a pretty important part of the CI workflow.)

> It is so much easier to resolve conflicts if you can look at both sides, 
> and can actually go to both sides to test things out, or even just 
> generate the diff to one side. This is just not possible with a dirty 
> merge. Exactly because you knowingly lost the current state, you cannot do 
> diffs with it.
>   

I don't disagree, but that's only an issue given the underlying 
assumption that you will be integrating only occasionally, and thus will 
tend to pull massive numbers of changes with lots of conflicts. If you 
know there will be at most one or two conflicts (or more likely none at 
all) because your last pull was twenty minutes ago and there have only 
been three other pushes since then, it's not an issue. That's the 
typical situation in a continuous-integration shop. I'd say 95% -- to be 
ridiculously conservative -- of the "svn up" commands that are run at my 
company result in no conflicts at all.

When a large conflict is a once-every-couple-of-months event because 
you've resolved all the trivial conflicts as they've appeared along the 
way, optimizing your daily workflow for the "what if I need to resolve a 
big hairy conflict?" case just doesn't make much sense.

> Needless to say (but I do it nevertheless, since I am in a chatty mood), I 
> _never_ can be seen doing the 4-command equivalent of `svn up`. I only 
> pull when I have a clean state. (Note: this also leads to a more 
> structured way of working, which does prevent errors.)
>   

And out of curiosity, are you using git for distributed, relatively 
autonomous development, or for collaboration with a high level of 
interdependency between developers?

-Steve

Re: GIT vs Other: Need argument

[Johannes Schindelin]

Hi,

On Thu, 19 Apr 2007, Steven Grimm wrote:

> Johannes Schindelin wrote:
>
> > Let me pick up the ball here. Once you did your share of conflicting 
> > merges, you _will_ realize how much better it is to merge when you are 
> > at a relatively stable state, i.e. you can test things (if only to 
> > make sure that the merge did not introduce strange side effects). And 
> > guess what, at such a stage I would commit anyway.
> 
> That's a great workflow if you're working on relatively discrete, 
> standalone changes. A lot of the time, when I'm working on an isolated 
> change, I do just that, and I merge when I'm stable just like you 
> describe. That's probably the vastly most common mode of operation for 
> distributed open-source projects, which obviously were git's initial 
> target audience.

It is also possible (and I do that) when merging often. I use cherry-pick 
for that. At a later stage, I merge, and this mostly succeeds, since the 
merge is really a 3-way merge (with the obvious results).

> And out of curiosity, are you using git for distributed, relatively 
> autonomous development, or for collaboration with a high level of 
> interdependency between developers?

I use Git virtually everywhere it can be used:

- backups
- personal projects
- configuration files
- documents
- collaboration with other people
- tracking CVS
- ...

Ciao,
Dscho

Re: GIT vs Other: Need argument

[Junio C Hamano]

Steven Grimm <koreth@midwinter.com> writes:

> And in particular -- this being the original topic of the thread --
> when an svn user sees me doing that, they do not immediately think of
> the fact that merging between immutable revisions may have some
> benefits. They see me typing four commands (commit, fetch, rebase,
> reset) to do the same thing they can do in one command with svn, and
> conclude that git is harder to use.

No arguments there.  While I know I will never use such a
workflow myself, I think it makes sense to _allow_ local
changes to be merged to the new revision if the user chooses to
use such a workflow.

The necessary places to change are limited to the Porcelain-ish
layer, and adding '-m' option to "git pull", just like "git
checkout" has the corresponding option to allow merging local
changes, should not be a rocket science.  In fact, I vaguely
recall keeping a couple of patches to do so in 'pu' several
months ago, perhaps for a few weeks.

Maybe git has matured too much.  In earlier days, people
complained about lack of features and existence of misfeatures,
and bashed the maintainer with patches.  These days, the bashing
is done with more words and less patches.

Re: GIT vs Other: Need argument

[Junio C Hamano]

Junio C Hamano <junkio@cox.net> writes:

> Steven Grimm <koreth@midwinter.com> writes:
>
>> And in particular -- this being the original topic of the thread --
>> when an svn user sees me doing that, they do not immediately think of
>> the fact that merging between immutable revisions may have some
>> benefits. They see me typing four commands (commit, fetch, rebase,
>> reset) to do the same thing they can do in one command with svn, and
>> conclude that git is harder to use.
>
> No arguments there.  While I know I will never use such a
> workflow myself, I think it makes sense to _allow_ local
> changes to be merged to the new revision if the user chooses to
> use such a workflow.

Actually, there is one thing that makes this much easier to do
in SVN.  It is its centralized nature.

If you have this sequence:

	(1) update and sync with the repository
        (2) you work alone, without committing
        (3) while you do (2), other people make commits
        (4) you update from the repository

Because of its central nature, the commits made in (3) are
always proper descendant of the commit you are basing your work
on in (2).  So at point (4), the resolution you would need to
perform is this "merge".

          (2).............M?
         /               . 
	1-----3a-3b-3c-3d

    Notational convention: Solid lines and unparenthesized
    letters are actual commits and ancestry in these pictures.
    Letters in parentheses and dotted lines are locally modified
    states and derivations of these states from commits.

But because there is no "commit" that records the work you did
in (2) alone, you can afford to 3-way merge whatever conflict
you get at M and you do not even record M as a merge.  The
result simply becomes a proper descendant of 3, which is still
uncommitted local change.

                          (2')
                         .
	1-----3a-3b-3c-3d


The patch series I "vaguely recalled" in my previous message
handled this special case where the branch being merged
(i.e. 3d) was a fast-forward of the current commit (i.e. 1).

However, in git, you do not necessarily work that way.  As you
admitted, the ability to commit locally is what's different.


          2a---2b..(2c)...M?
         /               .
	1-----3a-3b-3c-3d

If (4) happened after you've accmulated local commits 2a, and
2b, and you have local changes (your state 2c is different from
your tip, 2b, but is uncommitted, and kept in the working tree
alone), you usually do not want to resolve the mess to make a
commit M, pretend M is a proper descendant of 3d, depending on
the final structure you are trying to achieve (the mess may come
from interactions between 3's and 2a or 2b, or interactions
between 3's and 2c).

There are three possible commit ancestry structures you would
want to eventually reach, and three distinct sets of steps to
reach those structures.

 1. Perfect what you were in the middle of, and then perform a
    merge.  IOW, you don't have to update from remote when you
    are not ready.

          2a---2b---2c----M
         /               / 
	1-----3a-3b-3c-3d

 2. Merge what has already been committed, excluding your
    unproven WIP that is in the working tree, and roll forward
    your local changes on top of it.

          2a---2b---------M..(2c')
         /               / 
	1-----3a-3b-3c-3d

 3. Always serialize by rebasing.  The structure you would want
    to end up with is like this:

                         2a'-2b'.(2c')
                        /
	1-----3a-3b-3c-3d

Among these three workflows, what is most natural in git is the
first one.  The tool natively supports it well.

For the second workflow, you would:

    2-a. first make a tentative commit 2c

	$ git commit

                 --2c
                /
          2a---2b
         /
	1-----3a-3b-3c-3d

    2-b. merge what was ready on your end and the other side:

	$ git checkout HEAD^ && git merge origin

                 --2c
                /
          2a---2b---------M
         /               / 
	1-----3a-3b-3c-3d

    2-c. roll forward the local change you have in 2c:

	$ git rebase --onto HEAD master
        $ git reset HEAD^

          2a---2b---------M...(2c')
         /               / 
	1-----3a-3b-3c-3d


This probably is the next best organization.  But you have to
realize that this requires you to resolve potential conflict
when creating M and then another conflict when rolling forward
your local changes.

    We probably could help automating this, but your "git pull"
    session transcript need to look like this:

	$ git pull origin
        First stashing away of your local changes...
	Resolving conflicts between 2b and 3d.
	Conflicted merge.  Please resolve and commit.
	$ edit ; test
        $ git commit ;# to record M
	Committed the merge result.
        You have stashed local changes further to roll forward.
        $ git unstash local-changes
        Resolving conflicts between M and 2c.
	Local changes conflicted during roll-forward.
        Leaving resulting mess in the working tree for you to sort out.
	$ 


To end up with the third graph, you would:

    3-a. first make a tentative commit 2c

	$ git commit

                 --2c
                /
          2a---2b
         /
	1-----3a-3b-3c-3d

    3-b. rebase

	$ git rebase origin

                          2a'--2b'--2c
                         /
	1-----3a-3b-3c-3d

    3-c. reset

	$ git reset HEAD^

                          2a'--2b'..(2c')
                         /
	1-----3a-3b-3c-3d


and I think that is what you have been doing.  Both the final
structure and the workflow are least "git-like" among these
three.

    If you want to automate this, you can use this four-liner
    shell script:

	#!/bin/sh
        git commit || exit
	git fetch origin || exit
        git rebase origin || exit
	git reset HEAD^

    Store this in $HOME/bin/git-sgpull, if you may, and you can
    even say "git sgpull" to invoke it.

    When 'rebase' does not get conflict, which is the bast case
    you are primarily complaining about, having to type three
    commands, this will run to the end with this single command
    and you will feel happier.

    When 'rebase' gets conflict, however, you would need to
    resolve and have it keep going, but that is something you
    cannot avoid.  You would need to remember that the final
    "reset HEAD^" needs to be issued from your shell, but that
    should be obvious.

Re: GIT vs Other: Need argument

[Steven Grimm]

Thanks for that detailed writeup. It squares pretty well with my 
understanding.


Junio C Hamano wrote:
>           (2).............M?
>          /               . 
> 	1-----3a-3b-3c-3d
>
> [...]
>                           (2')
>                          .
> 	1-----3a-3b-3c-3d
>
>
> The patch series I "vaguely recalled" in my previous message
> handled this special case where the branch being merged
> (i.e. 3d) was a fast-forward of the current commit (i.e. 1).
>   

I think this is actually the case I'd be most concerned about getting 
right for those people who are coming from svn and want to change their 
workflow as little as possible at first. The class of people who would 
exclusively use an "svnish-commit" alias that did "git commit;git push" 
-- that is, who never do local commits -- would always find themselves 
with this setup.

>  3. Always serialize by rebasing.  The structure you would want
>     to end up with is like this:
>
>                          2a'-2b'.(2c')
>                         /
> 	1-----3a-3b-3c-3d
>   

You are correct in pointing out later on that my fetch+rebase workflow 
fits this structure. And for my particular environment it's actually the 
only one I can use a lot of the time, because I'm usually pushing to a 
shared git-svn repository (or working in a git-svn repo of my own), from 
which the changes will get committed back to svn. Eric Wong has warned 
that git-svn doesn't deal well with merges; it expects linear history. 
So for now this is the structure I need to end up with, at least until 
git-svn learns how to deal with nonlinear ancestry, if that's even 
possible at all given svn's inherent limitations.

I look forward to the day when git has built up enough critical mass 
here that we can just switch over to it completely and ditch that kind 
of restriction. With that happy day in mind, I'd still love to see the 
other workflows made as painless as possible, so more comments below.

> For the second workflow, you would:
>
>     2-a. first make a tentative commit 2c
>     2-b. merge what was ready on your end and the other side:
>     2-c. roll forward the local change you have in 2c:
>
>     We probably could help automating this, but your "git pull"
>     session transcript need to look like this:
>
> 	$ git pull origin
>         First stashing away of your local changes...
> 	Resolving conflicts between 2b and 3d.
> 	Conflicted merge.  Please resolve and commit.
> 	$ edit ; test
>         $ git commit ;# to record M
> 	Committed the merge result.
>         You have stashed local changes further to roll forward.
>         $ git unstash local-changes
>         Resolving conflicts between M and 2c.
> 	Local changes conflicted during roll-forward.
>         Leaving resulting mess in the working tree for you to sort out.
>   

I wonder if it makes sense to automate that even more and make git pull 
behave a bit statefully like rebase does:

    $ git pull origin
    Stashing local changes.
    Resolving conflicts, pass 1.
    Conflicts! Please resolve.
    $ edit ; test
    $ git pull --continue
    Committing revision M.
    Unstashing your local changes.
    Resolving conflicts, pass 2.
    Local changes conflicted during roll-forward. Sort it out.
    $

When git pull --continue does the commit, it *might* be nice for it to 
do a variant of commit -a: if the user has modified all the conflicting 
files, *and* not done an update-index on any of them manually, then do 
the update-index implicitly. (That "and" part would be to prevent it 
from tripping up experienced git users who want to manually mark the 
conflicting files as resolved by running update-index.) I'm not sure 
that's actually a good idea, though it'd save some commands most of the 
time; the danger, of course, is that you could end up committing a 
half-resolved file by accident. But then I guess there's nothing 
preventing you from doing that with update-index today.

But that's attractive because it's exactly two git commands in the most 
complex case (conflicts in the merge of committed revisions) and only 
one git command in the simplest cases (no conflicts or conflicts only in 
the working copy edits.) In the case of no working copy edits, 
--continue would just do the commit for you.

To make pull and rebase even more consistent, one could also allow git 
pull --abort to roll back the pull during a conflict resolution, whether 
or not it's a working-copy-edits one. People might find that a handy 
shortcut in other workflows too; it would probably just do a hard reset 
back to the pre-merge revision in the no-working-copy-edits case. 
Obviously that wouldn't be new functionality, just an arguably slightly 
more intuitive way to do it than what exists now.

>     If you want to automate this, you can use this four-liner
>     shell script:
>
> 	#!/bin/sh
>         git commit || exit
> 	git fetch origin || exit
>         git rebase origin || exit
> 	git reset HEAD^
>   

Actually I think I like the idea of making that a little more robust and 
having it take a --continue option like I described above. No reason it 
can't keep track of its current state. I will spend some time this 
weekend doing that.

-Steve

Re: GIT vs Other: Need argument

[Junio C Hamano]

Steven Grimm <koreth@midwinter.com> writes:

> I wonder if it makes sense to automate that even more and make git
> pull behave a bit statefully like rebase does:

Making things stateful may help, but when done without thinking
the consequence through, it would make things more confusing.

By the way, I never liked the way 'git rebase --continue' works.

Don't get me wrong.  I think it *was* a vast improvement.
Before 'git rebase --continue' was introduced, you needed to
know the implementation detail of 'git rebase' well enough to
know that you have to say 'git am --resolved' after resolving
the conflicts.  Compared to that, being able to tell rebase to
"continue" is much nicer.

But in practice, after 'git rebase' stops on a conflicting
merge, I spend many braincycles to come up with a sensible merge
and then many CPU cycles to run test, and by the time I do the
final "git diff" to make sure everything look right and
"update-index" them, I often end up getting confused and find me
asking this question: what was I doing?  Was I resolving the
merge because I merged, or was I in the middle of a rebase, or
was I applying from a mailbox?

I do not know what would happen if I say "git commit" at that
point, but I suspect it would be unpleasant, so I have never
tried it myself.  But it takes nontrivial amount of effort to
convince myself that 'git rebase --continue' is what I want to
do next, not 'git commit' nor 'git am --resolved'.

And I suspect the reason this is confusing to me is not that
rebase keeps state but that the state is not made more obvious
to prevent mistakes from happening.  Earlier I mentioned perhaps
we would want "git, whatnow?" command to remind people what they
were in the middle of and suggest what the next step would be.
Or perhaps "git, continue" command that makes the obvious next
step to happen would be helpful.

I am very much afraid that introducing more hidden state without
such "what now?"  framework in place would make things more
confusing and harder to use, not easier.

> When git pull --continue does the commit, it *might* be nice for it to
> do a variant of commit -a: if the user has modified all the
> conflicting files, *and* not done an update-index on any of them
> manually, then do the update-index implicitly. (That "and" part would
> be to prevent it from tripping up experienced git users who want to
> manually mark the conflicting files as resolved by running
> update-index.) I'm not sure that's actually a good idea, though it'd
> save some commands most of the time; the danger, of course, is that
> you could end up committing a half-resolved file by accident. But then
> I guess there's nothing preventing you from doing that with
> update-index today.

Running update-index by hand is a conscious act on the part of
the user.  You cannot compare it with silently doing the
equivanent without telling the user and screwing up.

Re: GIT vs Other: Need argument

[Shawn O. Pearce]

Junio C Hamano <junkio@cox.net> wrote:
> And I suspect the reason this is confusing to me is not that
> rebase keeps state but that the state is not made more obvious
> to prevent mistakes from happening.  Earlier I mentioned perhaps
> we would want "git, whatnow?" command to remind people what they
> were in the middle of and suggest what the next step would be.
> Or perhaps "git, continue" command that makes the obvious next
> step to happen would be helpful.

You use bash, right?  What about teaching your PS1 how to show
you if you are in the middle of a rebase?  Doesn't it show you
the current branch already?  ;-)

-- 
Shawn.

Re: GIT vs Other: Need argument

[Jakub Narebski]

Junio C Hamano <junkio@cox.net> wrote:
> Steven Grimm <koreth@midwinter.com> writes:
> 
>> I wonder if it makes sense to automate that even more and make git
>> pull behave a bit statefully like rebase does:
> 
> Making things stateful may help, but when done without thinking
> the consequence through, it would make things more confusing.
> 
> By the way, I never liked the way 'git rebase --continue' works.
[...]
> in practice, after 'git rebase' stops on a conflicting
> merge, I spend many braincycles to come up with a sensible merge
> and then many CPU cycles to run test, and by the time I do the
> final "git diff" to make sure everything look right and
> "update-index" them, I often end up getting confused and find me
> asking this question: what was I doing?  Was I resolving the
> merge because I merged, or was I in the middle of a rebase, or
> was I applying from a mailbox?
> 
> I do not know what would happen if I say "git commit" at that
> point, but I suspect it would be unpleasant, so I have never
> tried it myself.  But it takes nontrivial amount of effort to
> convince myself that 'git rebase --continue' is what I want to
> do next, not 'git commit' nor 'git am --resolved'.
> 
> And I suspect the reason this is confusing to me is not that
> rebase keeps state but that the state is not made more obvious
> to prevent mistakes from happening.  Earlier I mentioned perhaps
> we would want "git, whatnow?" command to remind people what they
> were in the middle of and suggest what the next step would be.
> Or perhaps "git, continue" command that makes the obvious next
> step to happen would be helpful.

You have even implemented "git explain" command, but it didn't get
into git. Perhaps it is time to resurrect it.
 
> I am very much afraid that introducing more hidden state without
> such "what now?"  framework in place would make things more
> confusing and harder to use, not easier.

It would be nice to have such "git explain" command, both for use
in scripts (and perhaps also in builtins), and for the user (perhaps
"git status" should use it, too). 

And it could be used to implement "git continue" and "git abort" 
commands... (or "git, continue" and "git, abort" ;-).

-- 
Jakub Narebski
Poland

Re: GIT vs Other: Need argument

[Karl Hasselström]

On 2007-04-19 16:30:12 -0700, Junio C Hamano wrote:

> But in practice, after 'git rebase' stops on a conflicting merge, I
> spend many braincycles to come up with a sensible merge and then
> many CPU cycles to run test, and by the time I do the final "git
> diff" to make sure everything look right and "update-index" them, I
> often end up getting confused and find me asking this question: what
> was I doing? Was I resolving the merge because I merged, or was I in
> the middle of a rebase, or was I applying from a mailbox?

This is the main selling point of StGIT, in my opinion. It keeps track
of stuff for you when you rebase, so you won't accidentally forget
things. The extra help isn't needed much when everything goes
smoothly, but as soon as you get a conflict or three in the middle of
rebasing a largish stack, it's invaluable to just be able to say "stg
series" to see which patches have been applied to HEAD, and which are
still floating in limbo.

The usability increase is very palpable; without it, I wouldn't even
attempt many of the rebasings I do, even though they are technically
perfectly possible to do with just git.

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle

Re: GIT vs Other: Need argument

[Junio C Hamano]

Karl Hasselström <kha@treskal.com> writes:

> This is the main selling point of StGIT, in my opinion. It keeps track
> of stuff for you when you rebase, so you won't accidentally forget
> things. The extra help isn't needed much when everything goes
> smoothly, but as soon as you get a conflict or three in the middle of
> rebasing a largish stack, it's invaluable to just be able to say "stg
> series" to see which patches have been applied to HEAD, and which are
> still floating in limbo.

I do not think we are talking about the same thing.  In your
example, you perfectly well remember that you were in the middle
of StGIT operation.  The problem I described is that sometimes I
do not even recall if I was rebasing or merging after resolving
conflicts.  If I *knew* I was in the middle of a rebase, I know
where to look (.dotest/ has all the necessary "state" for
rebase/am to continue) to remind me where I was.

Re: GIT vs Other: Need argument

[Petr Baudis]

On Fri, Apr 20, 2007 at 12:39:43PM CEST, Junio C Hamano wrote:
> The problem I described is that sometimes I
> do not even recall if I was rebasing or merging after resolving
> conflicts.  If I *knew* I was in the middle of a rebase, I know
> where to look (.dotest/ has all the necessary "state" for
> rebase/am to continue) to remind me where I was.

In Cogito, cg-status always tell you that you're in the middle of
something special if you are. Perhaps git status could let you know as
well. (It wouldn't be as easy to see since git status seems so verbose
though compared to cg-status; that has been one of my pet peeves, though
I suppose it's unlikely to change. ;-)

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Ever try. Ever fail. No matter. // Try again. Fail again. Fail better.
		-- Samuel Beckett

Re: GIT vs Other: Need argument

[Junio C Hamano]

Steven Grimm <koreth@midwinter.com> writes:

> When git pull --continue does the commit, it *might* be nice for it to
> do a variant of commit -a: if the user has modified all the
> conflicting files, *and* not done an update-index on any of them
> manually,...

How do you propose to detect that?  We do not record the
conflicted semi-merged state we leave the user to sort out
anywhere else, and I do not think we would want to stash away a
hidden duplicates of all unmerged files somewhere only for this
application.  That feels too wasteful and messy.  You also need
to worry about how to garbage collect such copies if you go that
route.

-- >8 --
By the way, I've been wondering if giving "git add" an ability
to do "git commit -a" without actual committing.

	$ edit edit edit
        $ git add -u

would run "git add" for all modified (and deleted) files.

I picked "-u" instead of "-a" because I wanted to stress that
this is about "updating" (which has connotation that it is
relative to something, and in this case it is relative to the
current "index"), and not about "all", which "-a" would imply.

Hmm?

 builtin-add.c |   58 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 57 insertions(+), 1 deletions(-)

diff --git a/builtin-add.c b/builtin-add.c
index 9ec2925..5e6748f 100644
--- a/builtin-add.c
+++ b/builtin-add.c
@@ -8,10 +8,15 @@
 #include "dir.h"
 #include "exec_cmd.h"
 #include "cache-tree.h"
+#include "diff.h"
+#include "diffcore.h"
+#include "commit.h"
+#include "revision.h"
 
 static const char builtin_add_usage[] =
-"git-add [-n] [-v] [-f] [--interactive | -i] [--] <filepattern>...";
+"git-add [-n] [-v] [-f] [--interactive | -i] [-u] [--] <filepattern>...";
 
+static int take_all_worktree_changes;
 static const char *excludes_file;
 
 static void prune_directory(struct dir_struct *dir, const char **pathspec, int prefix)
@@ -92,6 +97,44 @@ static void fill_directory(struct dir_struct *dir, const char **pathspec)
 		prune_directory(dir, pathspec, baselen);
 }
 
+static void update_callback(struct diff_queue_struct *q,
+			    struct diff_options *opt, void *cbdata)
+{
+	int i, verbose;
+
+	verbose = *((int *)cbdata);
+	for (i = 0; i < q->nr; i++) {
+		struct diff_filepair *p = q->queue[i];
+		const char *path = p->one->path;
+		switch (p->status) {
+		default:
+			die("unexpacted diff status %c", p->status);
+		case DIFF_STATUS_UNMERGED:
+		case DIFF_STATUS_MODIFIED:
+			add_file_to_cache(path, verbose);
+			break;
+		case DIFF_STATUS_DELETED:
+			remove_file_from_cache(path);
+			if (verbose)
+				printf("remove '%s'\n", path);
+			break;
+		}
+	}
+}
+
+static void update_all(int verbose)
+{
+	struct rev_info rev;
+	init_revisions(&rev, "");
+	setup_revisions(0, NULL, &rev, NULL);
+	rev.diffopt.output_format = DIFF_FORMAT_CALLBACK;
+	rev.diffopt.format_callback = update_callback;
+	rev.diffopt.format_callback_data = &verbose;
+	if (read_cache() < 0)
+		die("index file corrupt");
+	run_diff_files(&rev, 0);
+}
+
 static int git_add_config(const char *var, const char *value)
 {
 	if (!strcmp(var, "core.excludesfile")) {
@@ -156,8 +199,20 @@ int cmd_add(int argc, const char **argv, const char *prefix)
 			verbose = 1;
 			continue;
 		}
+		if (!strcmp(arg, "-u")) {
+			take_all_worktree_changes = 1;
+			continue;
+		}
 		usage(builtin_add_usage);
 	}
+
+	if (take_all_worktree_changes) {
+		if (i < argc)
+			die("-u and explicit paths are incompatible");
+		update_all(verbose);
+		goto finish;
+	}
+
 	if (argc <= i) {
 		fprintf(stderr, "Nothing specified, nothing added.\n");
 		fprintf(stderr, "Maybe you wanted to say 'git add .'?\n");
@@ -207,6 +262,7 @@ int cmd_add(int argc, const char **argv, const char *prefix)
 	for (i = 0; i < dir.nr; i++)
 		add_file_to_cache(dir.entries[i]->name, verbose);
 
+ finish:
 	if (active_cache_changed) {
 		if (write_cache(newfd, active_cache, active_nr) ||
 		    close(newfd) || commit_locked_index(&lock_file))

Re: GIT vs Other: Need argument

[Steven Grimm]

Junio C Hamano wrote:
> How do you propose to detect that?  We do not record the
> conflicted semi-merged state we leave the user to sort out
> anywhere else, and I do not think we would want to stash away a
> hidden duplicates of all unmerged files somewhere only for this
> application.  That feels too wasteful and messy.  You also need
> to worry about how to garbage collect such copies if you go that
> route.
>   

We wouldn't need to store duplicates. Just the SHA1s of the semi-merged 
files would suffice. Actually, just the modification times would 
probably suffice, but the hashes are cheap to compute and slightly more 
robust. We could put those in a single file (the same place we'd record 
the fact that the user is in the middle of a conflicted pull) which is 
removed by --continue or --abort.

Alternately, we could rerun the merge that produced the semi-merged 
files in the first place; presumably it will produce exactly the same 
results it did the first time and we can compare that against the 
working copy. But I like storing the hashes better since it's cheaper 
and less convoluted.

> By the way, I've been wondering if giving "git add" an ability
> to do "git commit -a" without actual committing.
>
> 	$ edit edit edit
>         $ git add -u
>
> would run "git add" for all modified (and deleted) files.
>   

I'm not sure I'd ever use this, personally. Pretty much the only time I 
find the "add everything" functionality useful is when I'm about to 
commit, and commit -a covers that case fine. But other people might find 
it helpful.

-Steve

Re: GIT vs Other: Need argument

[Yann Dirson]

On Wed, Apr 18, 2007 at 02:26:17PM +0100, Andy Parkins wrote:
> On Wednesday 2007 April 18 13:40, Guilhem Bonnefille wrote:
> 
> > An other point is that CVS/SVN actions for our developers are
> > "trivial": update or commit, nothing more (even tags are made by
> 
> > In my mind, git-svn or even git-svnserve, are THE tools to introduce
> > Git in teams not convinced by the power of DVCS. Or perhaps someone
> > will create a porcelain that offers the same simple interface of
> > CVS/SVN and will integrate it in all the fantastic IDE ;-)
> 
> It's already there.  The git porcelain can do almost anything.  If you were so 
> inclined you could write a fake svn command that translated all those calls 
> to git.
> 
> svn add = git add
> svn update = git pull
> svn commit = git commit -a && git push

It's even possible to write those as git aliases, so you can have "git
update" and "git ci" behave as cvs/svn users would expect.

Re: GIT vs Other: Need argument

[Sam Vilain]

Guilhem Bonnefille wrote:
> I'm new to Git, but completly crazy of it.
>
> In my point of view, in corporate team, lot of people does not
> want/need the power offered by Git.
> So, my conclusion is the better model in a corporate is a centralyzed
> repo with some users using Git as "frontend". Other people will simply
> use the native tools for accessing the repo.
>
> I didn't try Git with CVS repo but seems less usable in day to day
> work than a SVN repo with git-svn FANTASTIC tool.
>
> So the problem is simply now: how to convince people to migrate from
> CVS to SVN. This will be really less difficult as CVS and SVN are
> quite similar.
>   

Once git-svnserver is available, it should be possible to work the other
way, too - use git as the repository format and support Subversion users
through a subversion interface flavour.  Then you don't lose the merge
tracking and fast checkout performance for those who can use the native
protocol.

Sam.

Re: GIT vs Other: Need argument

[Yann Dirson]

On Tue, Apr 17, 2007 at 02:45:20PM +0400, Tomash Brechko wrote:
> I think you are not talking about choosing SCM for a new project, as
> it is even _hard to imagine_ that one would consider CVS nowadays :).

Don't think that.  Some people used to CVS still say "it does the job,
and I know the tool", and look suspciously on those youngsters trying
push anything they did not even heard of (I'd push for git today, but
18 months ago all I had to push for was svn).  And only after months
of "here svn/git would have done better", and regularly showing off
gitk (git-cvsimport is not a panacea, but it helps), can they be ready
to hear.

But by then more people have been made to meet CVS because of a new
project using it, and it will take more time that we would like to see
it retire from the scene...

Re: GIT vs Other: Need argument

[Dana How]

On 4/17/07, Tomash Brechko <tomash.brechko@gmail.com> wrote:
> On Tue, Apr 17, 2007 at 10:02:18 +0100, Pietro Mascagni wrote:
> > So, in 15 seconds, how does one argue that GIT is vastly superior to
> > other version control software, especially CVS.
> ... You can't really
> explain why 'git commit; git push' into some central repository is
> better than 'cvs commit', and pushing after every commit is what
> people will be doing at first ;).
Yes, your point here is very real --
this perception that git imposes an "extra step"
is one thing I'm trying to avoid right now.  I think I've almost succeeded...
-- 
Dana L. How  danahow@gmail.com  +1 650 804 5991 cell