This is continuation of partial summary of Git User's Survey 2007,

ending at state from 28 September 2007.
The survey can be found here:

  http://www.survey.net.nz/survey.php?94e135ff41e871a1ea5bcda3ee1856d9

  http://tinyurl.com/26774s
The data this summary is based on can be found here:

  http://git.or.cz/gitwiki/GitSurvey2007?action=AttachFile&do=get&target=s...

  http://tinyurl.com/yusomo
----

There were 683 individual responses
About you

~~~~~~~~~
00. Date of response
  Date                           | Count

  ------------------------------------------

  Before                         | 7

  During                         | 584

  After                          | 92

  ------------------------------------------
The ranges 'before', 'during' and 'after' refers to official duration

of Git User's Survey 2007, from 20 August 2007 to 10 September 2007.

Actually they are corrected to take into account the fact that local

date on survey's server (or UTC date) might be different from local

date on user computer, so duration of survey is taken as from

2007-08-19 to 2007-09-11.
Most responses are from the start of survey, 20 and 21 August (133 and

103 responses respectively).  If anyone is interested I can provide

full date by date histogram.
Getting started with GIT

~~~~~~~~~~~~~~~~~~~~~~~~
07. What helped you most in learning to use it?
  TO DO

  646 / 683 non-empty responses
Some of the responses:

 * documentation (generic)

 * man pages

 * examples / usage cases in man pages

 * everyday GIT, tutorials and user's manual

 * wiki examples

 * reading mailing list / comp.version-control.git

 * people on IRC (not only #git)

 * advice from other users / friends / colleagues

 * (unofficial) documentation on the web: guides, articles, blogs etc.

   [here probably should be a sublist of them, with count]

 * a development community and/or its documentation, mailing list

   e.g. WINE wiki, Source Mage GNU/Linux development community

 * Google...
[ message continues ]

This is continuation of partial summary of Git User's Survey 2007,

ending at state from 28 September 2007.

(response ident "46f95167c967b").
The survey can be found here:

  http://www.survey.net.nz/survey.php?94e135ff41e871a1ea5bcda3ee1856d9

  http://tinyurl.com/26774s
The data this summary is base on can be found here:
----

There were 683 individual responses
Other SCMs

~~~~~~~~~~
13. What would you require from GIT to enable you to change,

    if you use other SCM for your project?
  TO DO

  474 / 683 non-empty responses
List of answers, without count (which for this question is, I think,

less important), divided into broad categories, is shown below
Generic

 * being more user-friendly, easier to use

   more friendly output from commands

   better and clearer error messages

   stable command semantics

 * reduced number of (visible) commands

   clear separation of plumbing and porcelain

 * consistent set of commands

   consistency if command flags

 * easier to learn (easier learning curve)

 * more stability

 * support UTF-16
 * A clearer UI. Read the monotone list archive. 70% of the mails are

   UI related. The result is an clear and easy to use intuitive UI

   that does what you expect in most cases.
Performance

 * better performance on massive trees (FreeBSD)

 * good speed on NTFS (MS WIndows)
Documentation

 * a good documentation

   user/installation documentation

   troubleshooting guide

   'Git For Dummies', 'The Git Book'

 * documented workflows (including centralized repo workflow, or at

   least documenting how and why replace it with better workflow)

 * development model tutorials

   more example usage

   best practices

   case studies

 * guide for designing a branch policy for a shared repository

 * screencasts

 * documentation in one's native language

 * good in-depth administative documentation

 * maybe git-tutor program
Specific features

 * partial-tree checkouts (partial checkout)

   checking out arbitrary subdirector...
[ message continues ]

We may find support for Git on SourceForge in the future, but not

on Google Projects anytime soon, if ever.
At the Google Summer of Code Mentor Summit last Saturday Dscho had a

short chat with someone from the Google Code group.  Apparently they

did at least look at Git briefly but concluded that they cannot

implement it on their site as our backend storage database is just

plain files on the local filesystem.
One of the reasons (probably among many but whatever) that I think

Google hired the "SVN guys" as employees is to develop a Google

specific backend for SVN (replaces fsfs and bdb) that stores the

SVN revision data in a Google BigTable cell rather than on the

local filesystem.  This allows Google to efficently manage the

entire site, including distributed replication, hot failover, etc...

BigTable is one of their key technologies at this point.
If you don't know about BigTable but want to know more you can

search for details about it via this awesome search engine I have

heard about: http://www.google.com/ :-)
I've managed to glean enough details on BigTable to know that the

Git backend is *not* easily layered on top of it.  But the SVN

fsfs backend is actually fairly easy to translate into BigTable,

so I imagine it didn't take the "SVN guys" very long to develop

the new backend, test it, and thus deploy SVN onto Google Projects.
Funny aside: If you really want to know about BigTable apparently

you also need to visit (one of?) the men's room in building 43

on the second floor.  There were tutorial posters hanging on the

wall describing how to use BigTable and Sawzall to summerize a

large dataset.  Most pubs hang sports pages from the local paper;

Google hangs BigTable documentation.  Nerds.  All of 'em.
--

Shawn.

-

Hi,
Jakub, thank you very much for doing this.  It is a very tedious work, and

I deem it invaluable.
I had the same problem, and somebody pointed me to

http://ircatwork.com/cgi-bin/irc/irc.cgi
I find it always a little strange how people want to use something like

git, but are unwilling to ask.  Is this such a big attack on the manliness 
Frankly, expectations like these make me want to bang somebody's head on 
I think it'd be a good idea to put it on git://git.kernel.org/, linked

right before the links to the man pages.  Who has permissions to change 
OMG Ponies!
Seriously again, is the cheetah taken already?
Speaking of cheetah: there is a project called git-cheetah, its goal being

to provide a TortoiseCVS lookalike for git.
Just wanted to mention it, in case people want it, and are not too shy to 
I am neither, but FWIW I did not have the impression that it is in its own

little niche.
At the GSoC mentor summit, I encountered a rather different stance: people

did not _know_ what distributed SCM means, and were rather afraid of the

concept.  Some of them seemed to fight changing their known procedures

tooth and nail.  Which is fine by me (I don't have to force anybody to

use git, thankyouverymuch).
A word about the GitFAQ... there was one suggestion that there should be a

FAQ maintainer.
I really have to ask myself why not more people just edit the GitFAQ on

the wiki.  I mean, that is the whole purpose of it being on the wiki.

It's not hard either.
Less hard in any case than to find a volunteer for a FAQ maintainer -- I

mean, if most are too busy/lazy/shy to edit the FAQ at all, how do they

expect somebody else to step up?
Ciao,

Dscho
-

The "barriers to entry" / "data model" comment came from me :)
"Find out why people find git hard to learn and eliminate those barriers

to entry" is what we do with usability tests e.g. in GNOME.  You ask

people to use your software to accomplish well-defined tasks ("send a

mail to foo@bar.com", "using the word processor, copy this fancy printed

layout").  Then, you see how they *expect* your software to work, you

see in which places it doesn't behave like that, and you fix it.  This

produces very good results.  For Git in particular this could be things

like, "Import this project from SVN, fix a bug, commit the patch", or

"You are a maintainer, merge in these two branches from two

contributors".
"Make git more task-oriented rather than data-model-oriented" is about

making the tool adapt to what you usually want to do, instead of making

*you* adapt to the way the tool wants to work.  Many commands in Git

have documentation like
  "option --foo updates the refs without modifying the index.  Requires

  a clean working tree"
This is gibberish for people who are not very familiar with Git's

internals.  "Git for computer scientists" provides a *very nice*

explanation of the DAG and refs and tags, but unfortunately it doesn't

explain the index, why you would want to know about it, etc.
Git introduces a lot of terminlogy:  refs, index, working tree, remotes,

origin, HEAD (which is not the same as CVS HEAD!), detached head,

rebasing, porcelains, etc.  Even the basic documentation is hard to read

when you don't know all the terms yet.
It's nice that Git lets you manipulate the repository in all kinds of

ways, but presenting porcelains at the same level as plumbing makes

things hard for users to learn.  I was just in our Beijing office,

teaching people about development tools and Git in particular.
  Federico: "get Git from this location"
  Beijing hacker: tap tap tap, "okay, it's installed now"
  Federico "Git commands all start with 'git'"
  Beijing hacker: git<T...
[ message continues ]

And what every major corporation who's serious about UI's do. Windows

works the way it does because that's how idiots expect it to work. Sad but

true. If our aim is world domination, we need not cater to the morons, but
I like it. So much so that I'll see if I can get a non-programmer at work
I agree completely. It wouldn't be hard to make git-apply figure out if

it's being fed something that 'am' would normally want, and if it's being

fed it inside a git repo. If so, make it work just like 'am'.

git-applypatch was deprecated a long time ago and has already been removed.
Personally, I can't help but think that the numerous times I've heard "oh

gods, that's a lot of commands" should finally mean something. I've started

taking a look at which of them one can bundle together. If we can drop the

porcelainish commands down to ~30 or so, and hide the plumbing from git-<tab>

listings, the initial hurdle people have to jump would be significantly lower.
--

Andreas Ericsson                   andreas.ericsson@op5.se

OP5 AB                             www.op5.se

Tel: +46 8-230225                  Fax: +46 8-230231

-

Maybe we could group commands into more categories?
plumbing: should be hidden from the 'normal' user. Porcelain

   should be sufficient for every standard task.
core porcelain: this is what everyone needs who works in a

   pure git based workflow based on push/pull. You can't use

   git without these commands. But these commands are already

   sufficient to solve most of your tasks.
mail porcelain: the list will probably hate me for this, but

   I think all commands needed to create and send patches per

   mail are not essential. I suspect that I'll _never_ ask

   my colleagues at work to send me a patch by mail. They'll

   always push it to a shared repo.
import/export: Many commands are only used for importing

   from or exporting to other version control systems. Examples

   are git-cvs*, git-svn*. They are not needed once you switched

   to git.
admin: Some commands are not used in a typical workflow. For

   example git-filter-branch or git-fsck have a more admin

   flavor.
There might be more categories. I am not sure because there

a quite a few commands that I _never_ used and have no clear

idea about what they do.
So here are a few questions:
Could we find a small set of core porcelain commands that

completely cover a typical workflow? The core section of the

manual should only refer to those commands. Absolutely no

plumbing should be needed to tweak things. In principle, a

typical user should be able to work if _all other_ commands

except for core porcelain are hidden from his PATH.
Another section in the manual should describe a workflow based

on sending patches around. Obviously the mail porcelain is

needed for this.
... and so forth.
I don't know if we really want to hide the commands from PATH.

But maybe we should consider grouping them into subdirectories,

or provide another way to for the user to focus on the core

porcelain.
	Steffen
-

The problem is division between what is porcelain and what is plumbing.

Some commands are right on border (git-fsck, git-update-index, git-rev-parse

comes to mind).
But it should be fairly easy to:

 1. put only porcelain in bash / zsh completion ('git <tab>' shows

only porcelain

 2. move plumbing out of PATH, but use exec-dir instead.
Usually mail porcelain is in separate binary package, git-mail for

RPMS packages for example. But iMVHO git-format-patch is as often used
These are a few commands only. I'm not sure about how to separate

those from ordinary commands.
The problem here I suppose might lie with the same reason why

(almost?) all Office Lite systems failed: because even if 80% of people

use only 20% of functaionality, it is not the _same_ 20%.
--

Jakub Narebski

-

Hi,
Sorry, but my impression from the latest mails was that the commands are

fine.  What is lacking is a nice, _small_ collection of recommended

workflows.  And when we have agreed on such a set of workflows, we

optimize the hell out of them.  Only this time it is not performance, but

user-friendliness.
Hmm?
Ciao,

Dscho
-

http://www.kernel.org/pub/software/scm/git/docs/everyday.html would be a

good starting point, I think.
--

Andreas Ericsson                   andreas.ericsson@op5.se

OP5 AB                             www.op5.se

Tel: +46 8-230225                  Fax: +46 8-230231

-

Hi,
I don't think so.  Way too few authors were involved in writing this

document, so it is not "typical" in and of itself.
I'd really like people to respond not so much with broad and general

statements to my mail (those statements tend to be rather useless to find

how to make git more suitable to newbies), but rather with concrete top

ten lists of what they do daily.
My top ten list:
- git diff

- git commit

- git status

- git fetch

- git rebase

- git pull

- git cherry-pick

- git bisect

- git push

- git add
Of course, my list is somewhat skewed (because I am quite comfortable with

the commands git provided; otherwise I would have provided -- unlike

others, probably -- patches, and would have fought -- also unlike others

-- to get them in, such as --color-words).
So again, I'd like people who did _not_ tweak git to their likings to tell

the most common steps they do.  My hope is that we see things that are

good practices, but could use an easier user interface.
Ciao,

Dscho

-

Maybe not top 10 per se, but here are a couple of my common command

sequences and some comments about how they could maybe be simplified. I

mostly use git to talk to an svn repo, which in some sense is a corner

case but which I suspect is both (a) really common already, and (b)

potentially even *more* common if we can make git an even easier way to

work with svn repositories.
Pulling updates from svn:
git stash

git svn rebase

git stash apply
A "git svn up" command could do the above automatically (svn users are

accustomed to doing "svn up" with dirty working copies.)
Committing my work:
git commit -a

(ask someone for a code review, usually involves "git diff" or "git show")

git commit --amend (to indicate in my commit message who did the review)

git svn rebase

git svn dcommit
This isn't too bad as is. I could save myself the "git commit --amend"

if there were an option to "git svn dcommit" to pop up a commit message

editor (using the existing text as the default, of course) but it

doesn't bother me much.
A more extreme possibility which I predict approximately 0 people on

this list will like: if the working copy is dirty but there is no local

commit, "git svn dcommit" could pop up an editor for a commit message,

make a local commit, then send it to svn. That would simplify the

git-based workflow even further for svn users who don't care about local

versioning. I'm not sure *I* even like this idea, mind you, but it would

certainly address the "Why this extra step I don't need in svn?"

complaint svn users sometimes raise.
Working in a topic branch:
git checkout whateverbranch

git svn rebase

git commit -a   (a bunch of times)

git checkout -b temp trunk

git merge --squash whateverbranch

git commit

(get code review)

git commit --amend

git svn dcommit
This could be shortened a bit with the above idea (edit commit message)

plus an option to git-svn dcommit to squash everything into one svn commit.
Of course, whether adding more options li...
[ message continues ]

I'm not so sure we'd want to hide commands that git-gurus simply do not

use, such as git-blame. In my opinion, we should just locate the highest

level available of UI tool that implements a particular feature and have

that listed in the git[- ]<tab> view.
I doubt many people on this list regularly use git-blame but it's a

command that's definitely non-trivial to script out using only the

"proper" commands, and CVS/SVN users expect it to be there, so it's

probably worth listing anyhow.
Similarly, it might be helpful to have help topics the gdb way, like

"git help patches". It's one of those things that people have come to

expect from a software tool, so perhaps we should humor them? Given gits

"every help topic is a man-page" idiom, this shouldn't require any real

technical effort.
Such topics should probably include

merge/merges/merging - overview of various ways of putting two lines of

development back together

patch/patches - how to create, send and apply

tags/branches/refs - what they are, why they're good, link to merging
I'm currently swanked with day-job work, but I'll see if I can get some

prototype docs done later this week and check if it requires any code

support. If anyone's well-versed in asciidoc HTML-indexing and wants to

provide pointers to what I should think about for generating those topic

menus as html docs, feel free to chuck me an email.
--

Andreas Ericsson                   andreas.ericsson@op5.se

OP5 AB                             www.op5.se

Tel: +46 8-230225                  Fax: +46 8-230231

-

Hmmm, I don't really want to turn the "summary" thread into oodles of

sub-threads, but here goes :)
Personally I find git-blame *EXTREMELY* useful.  The workflow is:
1. Bug #12345 for FooApp gets assigned to you.
2. git-svn clone fooapp's repository
3. git checkout -b my-bugfix-branch-for-12345
4. debug debug debug
5. "WTF?  Who wrote this crappy code?"
6. git blame culprit-file.c
7. "Oh, it was $person with $commit_id... what were they thinking at the

time?"
8. git show $commit_id
9. "Oh, I see their intentions now... what was going on at that time?"
10. git log <date range around $commit_id>
11. etc.
Git-blame is very nice for code archaeology (long explanation at
This would be simply fantastic.  If those help topics suggested

workflows, I'd be delighted :)  Feel free to poke me if you write up

some text; I'd love to help on this.
  Federico
-

You don't need blame for that (by the way, as git-blame is slow, you

can try -L option to limit range of lines; it is a pity that 'git gui

blame' does not support it yet). You can use 'pickaxe search', i.e.

"git log -S'<crappy code>'". Sometimes it is better than git-blame...
--

Jakub Narebski

-

On 10/22/07, Andreas Ericsson <ae@op5.se> wrote:
Very good idea. It is definitely something that can be worked on.
By the way, what do you think about "spying" version of git, specially

marked release which gathers statistics of porcelain used, with

frequency of its use, and git-sendstats command added in this release?
--

Jakub Narebski

-

I like it and I'd use it. What's more interesting is that I could

probably get my co-workers to do the same.
--

Andreas Ericsson                   andreas.ericsson@op5.se

OP5 AB                             www.op5.se

Tel: +46 8-230225                  Fax: +46 8-230231

-

Hi,
I like Wincent's approach, scanning .bash_history.
Ciao,

Dscho
-

Hi,
I was not talking about commands that git gurus simply do not use.  I 
From the survey it is utterly clear that the available UI tools are still

not good enough.
So once again, what operations involving git do people use regularly?
<rationale>There is a good chance that git is not optimised for most

people's daily workflows, as project maintainers seemed to be much more

forthcoming with patches, and therefore maintainers' tasks are much more

optimised than in other SCMs.</rationale>
Ciao,

Dscho
P.S.: If nobody replies with actual daily workflows to this mail, I'll

just assume that this complaint in the user survey was just bullocks, and

no change in git is needed.
-

For working on gitweb in git.git repository.

1. Fetch (when I am on topic branch) or pull (in rare cases I am on master)

2. "stg rebase origin"

3. work, work, work, using StGIT to generate perfect patch series

(going back and forth between patches, reordering patches, adding

patch in the middle of series, concatenating two patches, etc.; for

example when I notice that something should be changed in previous

patch, be it either bug noticed just now, or change in preparatory

patch to better suit main one)

4. fetch and rebase just between publishing

5. git format-patch to generate patch series; use git-shortlog or

grepping for patches subjects and git-diff --stat to generate

introductory email. Unfortunately StGIT template for introductory

email does have neither shortlog nor diffstat fields to atomatically

fill. Add comments to patches if needed.

6. Either use KMail + attach inline (no word wrap), or git-send-mail

(with sendmail configured to use gmail account; now I could use simply

git-send-mail configuration in user config) to send patches to git

mailing list

7. Push changes (if I don't forget) to repo.or.cz repository (jnareb-git.git).
--

Jakub Narebski

-

It does now! (I don't think it's in any released version yet, though.)
--

Karl Hasselström, kha@treskal.com

      www.treskal.com/kalle

-

That is nice to hear.
By the way, there is SRPM for StGIT in

http://homepage.ntlworld.com/cmarinas/stgit/

(I need it because I have Python 2.4), but it is not listed on downloads page...
--

Jakub Narebski

-

I never thought anyone would need it. I find the .tar.gz better.
BTW, what is the problem with Python 2.4? Was the RPM built for a

different version? The upcoming 0.14 release will be based on Python 2.5

but we keep the compatibility with 2.4 (we dropped 2.3).
--

Catalin
-

I'll leave the webpage question to Catalin, but I'm curious about the

Python version remark. What exactly is the problem?
--

Karl Hasselström, kha@treskal.com

      www.treskal.com/kalle

-

If I remember correctly the StGIT RPM requires python 2.5

(and is build using python 2.5, so install with --force doesn't work).
BTW. SRPM is better than tar.gz because I can simply do "rpmbuild

--rebuild" to get binary RPM to install.
--

Jakub Narebski

-

Hmm. That's overkill, considering that only 2.4 is actually required

(and until recently, we tried to be careful to only require 2.3).
--

Karl Hasselström, kha@treskal.com

      www.treskal.com/kalle

-

The following are workflows that would be very useful for my cow-orkers

and project peers.
End-user workflows:
* Clone from another SCM (mostly svn).  Make a local branch to implement

something in various commits.  Rebase to the "latest upstream sources"

when you are done, and then do the equivalent to "svn dcommit" to upload

your final changes to the other SCM.  The use case for this is to fix a

complicated bug in GNOME, which uses SVN.
* While you are doing that, produce a patchset that you can send to the

maintainers for review.  I love "git-format-patch -n --thread --stdout >

foo", but it's pretty painful to have to 1. look up git-format-patch's

options in the man page (if you use --stdout, shouldn't -n and --thread

be turned on by default?); 2. import "foo" into Evolution to then be

able to edit the zeroth mail, and then be able to use Evo's SMTP

configuration to send out the mails while preserving the threading.
* Clone a git repository which has several interesting branches.  Figure

out which branch you are interested in.  Create a local branch based on

that; do your changes there.  Keep your code up to date (rebase?  when

to fetch / pull / etc?).
* You have a personal branch with a bunch of commits:  a mess of "real

work", "remove debugging printf", "fix typo", etc.  Reformat / reorder

those patches into something suitable for submission.  [I just found out

about git rebase --interactive and it's *FANTASTIC* for this!]
Maintainer workflows:
* Start a personal project in git and publish it for others to clone.

Assume several possible setups:  dumb web server with no git installed,

git installed but no git-daemon, git installed with git-daemon running.

I've found that publishing is not trivial at all; it's a rather

cumbersome multi-step process.
* Several of your contributors publish their own git repositories.

Integrate changes from them, or review them.  This interesting because

you'll have to do a lot of navigation in repos with which you aren't

famili...
[ message continues ]

All operations in my laptop since May:
    621 git log

    614 git diff

    510 git status

    378 git grep

    203 git checkout

    166 git add

    159 git commit

    106 git fetch

     87 git branch

     61 git help

     55 git am

     49 git ls-files

     48 git format-patch

     46 git show

     46 git reset

     46 git clone

     44 git cherry-pick

     42 git merge

     36 git apply

     26 git cherry

     25 git push

     25 git describe

     24 git rev-list

     20 git rebase

     18 git pull

     17 gitview

     16 git shortlog

     15 git revert

     15 git cat-file

     12 git name-rev

     11 git update-index

     11 git ls-tree

     11 git count-objects

     10 git tag

      9 git send-email

      9 git rev-parse

      7 git svn

      7 git read-tree

      6 git repack

      6 git fsck

      4 git init

      4 git clean

      3 git rm

      3 git gc

      2 git submodule

      2 git prune

      2 git ls

      2 gitk

      2 git gui

      2 git config

      1 git mailinfo

      1 git lost-found

--

Duy

-

Here are my top ten commands, sorted by the number of times they

appear in my ~/.bash_history:
533 status

342 diff

252 commit

234 add

123 checkout

116 log

106 push

97 config

83 show

83 branch
Not very scientific, but it gives a rough idea of how one Git newbie

(using it for several months) with a very basic workflow uses Git.
Cheers,

Wincent
-

from my (short, 500) .bash_history:
     26 am

     22 gitk

     21 fetch

     15 reset

     10 log

      9 merge

      8 cherry-pick

      7 status

      5 commit

      4 svn

      4 push

      4 gc

      4 diff

      3 gui

      3 format-patch

      2 pull

      2 clone

      1 show

      1 rebase

      1 grep

      1 cat-file

      1 branch

      1 apply
branch, cat-file and show are actually fairly common, the history just

shorted and I lost them.
-

Hi,
Thanks.  That's a really good idea.  I did the same, and it turns out that

my list was wrong:
     68 log

     50 fetch

     36 show

     33 diff

     19 grep

     19 commit

     14 ps (my alias which runs -p status)

     10 config

      8 rebase

      8 push
Everybody who wants to find out the same: this is how I did it:
cat .bash_history |

	tr ";" "\\n" |

	sed -n "s/^ *git[- ]\([^ ]*\).*$/\1/p" |

	sort |

	uniq -c |

	sort -r -n
One thing that I realised by looking at my list: It probably makes more

sense teaching people about "fetch" in the beginning, teach other parts

about git, and only then "push".
We tend to teach people about "fetch" and "push" at the same time, but

this is not consistent with any workflow.
Ciao,

Dscho
-

My list
     61 show

     35 gitk

     31 diff

     23 fetch

     12 reset

     12 blame

     11 clone

     11 checkout

     10 remote

     10 rebase

      9 status

      5 commit

      4 branch

      3 clean

      2 revert

      2 merge

      2 ls-remote

      2 gui
-- robin

-

Sounds like a good idea. Here's mine (my .bash_history is limited to

500 commands, though):
$ cat ~/.bash_history | grep ^git | cut -c5- | cut -d' ' -f1 | sort |

uniq -c | sort -nr | head -10

  64 status

  37 diff

  23 push

  13 checkout

  12 add

   9 log

   9 commit

   8 rebase

   8 branch

   5 count-objects
Dave.

-

diff

qgit

commit

fetch

rebase

merge

status

push

cherry-pick

grep

bisect

add

show-ref
If I were to suggest any improvements, it'd be to change the semantics

of git-pull to always update the local branches set up to be merged with

the remote tracking branches when they, prior to fetching, pointed to

the same commit, such that when
$ git show-ref master

d4027a816dd0b416dc8c7b37e2c260e6905f11b6 refs/heads/master

d4027a816dd0b416dc8c7b37e2c260e6905f11b6 refs/remotes/origin/master
refs/heads/master gets set to refs/remotes/origin/master post-fetch.
This would save me from this command sequence, which I currently have to

do for git.
git fetch

git checkout next

git merge spearce/next

git checkout master

git merge spearce/master

git checkout maint

git merge spearce/maint

git checkout pu

git reset --hard spearce/pu
<rinse and repeat for every tracked branch>
git could definitely help here. I want the local branches to be

up-to-date with the remote ones, because I frequently run diffs against

the various branches to see if anything that I should be aware of has

changed, and just as frequently I forget to add that 'origin/' prefix,

which means I *might* be looking at old code.
I usually do that on internal projects, where we have "master", "next",

"testing", and "stable" branches for pretty much every repo. We have 54

git repos. The typing adds up. This is also one of the most frequent

causes of confusion for my (even) less git-savvy co-workers. The

argument usually goes like this:

"Umm... Peter, why did you commit your fix on top of 7 weeks old code?"

"Oh? I did git-pull first, just as you said, so it should have been the

latest, shouldn't it?"

"Well, what branch were you on when you pulled?"

"Err.. does that matter? I didn't have any local modifications on the

branch when I pulled, so it should have just updated it."
What's happened prior to such an argument is usually this:

next or master is inevitably checked out. The user does git-...
[ message continues ]

Hi,
In general, this should fail.  Because you are expected to have local

changes in the local branches.  What you describe suggests that you should

not use the branch name "master" at all, but "origin/master".
That said, there is a pretty simple way to achieve what you want (even if

it does not help the confusion you create between local and remote

branches):
	git config --add remote.origin.fetch master:master
Of course, when you checkout "master" and pull then, you'll get even more

problems, _exactly_ because you muddled up the clear distinction between

local and remote branches.
Ciao,

Dscho
-

If you push your changes to the origin soon after making them, you'll only

have local changes if somebody else changed something while you were

working on a change. You're expected to create local changes in the local

branches, but you shouldn't generally sit on them forever, and when you've

pushed them, you no longer have any difference in content between local

and remote.
If the project has multiple branches in the central repository, and you

make changes for each of them at different times, but only one each day,

the normal case will be to have local changes sitting in at most one of

the branches, and, in particular, no local changes left in any branch

other than HEAD.
	-Daniel

*This .sig left intentionally blank*

-

BS argument. Git knows when I haven't got any changes on my local

branches, and it can be fairly safely assumed that when I feel like

making any, I'd like to make them off as fresh a tip as possible unless

I explicitly tell git otherwise.
Nice hint though. I'm working on a patch for it now but I've only looked 
No. I want the ability to commit locally without it affecting my

upstream tracking branches, but I also want to make sure that when I

want to work on some branch I don't frequently touch, git will make sure

it's kept up-to-speed with the branch I explicitly have told it to merge

with, without me having to remember if I was on that branch when I last

did git-pull (I might not have a network connection), and without having 
That's not what I want at all. I must have been unclear in my original

post. I'm talking about git doing automatically what every single user

I've ever talked to wants it to do, which is to maintain the state of

sync that the "local-and-modifiable" branches had with the

"local-non-modifiable-aka-remote-tracking" branches. Note that the state

of sync is more important to users than git never ever touching the

branches that they *could* have (but don't have) changes on.
--

Andreas Ericsson                   andreas.ericsson@op5.se

OP5 AB                             www.op5.se

Tel: +46 8-230225                  Fax: +46 8-230231

-

[cut]
It would be I think possible to make git behave as you want, although I'd rather

(at least at first) have behaviour described above turned on by some option

or config variable. I guess that it would be not that hard to make script to do

what you ant (and probably it would be best if you tried your idea that way).
There are the following caveats.

1. For each local branch that is to be updated on pull, this branch

must be marked as tracking some branch of some repository. This has to

be explicitely done; for example by creating those branches using

--track option.

2. Git can do a merge with conflicts _only_ if that branch is checked

out. So for all local branches which you want to get updated using

"git pull --update-all <repo>" (or something like that), the merge

with remote branch should be either fast-forward, trivial merge, or

merge without conflicts. "git pull --update-all <repo>" would return

then list of updated branches and list of branches which cannot be

updated.
So... are you going to try to implement that?

--

Jakub Narebski

-

Yes, but only for fast-forward cases. When there *are* local changes,

the user must decide when to merge those, since he/she may not be done

with them. It doesn't make sense to merge local canges on a not checked

out branch automagically, because then we end up in the very unclear

semantics that Dscho (and myself) fear.
Also, as Steffen pointed out in his mail, this will make "git pull"

largely symmetrical with "git push", which *does* update all the remote

branches, but only if the update results in a fast-forward.
--

Andreas Ericsson                   andreas.ericsson@op5.se

OP5 AB                             www.op5.se

Tel: +46 8-230225                  Fax: +46 8-230231

-

True, and only the branches matching the remote currently pulled

should be considered. Tracking branches pointing to a different
Andreas' proposal contains an important requirement that

avoids this problem. His proposal states "when they, prior

to fetching, pointed to the same commit [the head in remotes

pointed to]". That is only fast-forwards are needed, which
Maybe Andreas' proposal could be extended as you describe.

But I don't think any merging should automatically be done. I'd

only support fast forwards. Merging always includes a risk

of unexpected changes to the code; even if there are no merge

conflicts detected by git. I think it is reasonable to leave

all such cases to the user for manual resolution. Supporting

fast-forward should be sufficient.
	Steffen
-

Hi,
You know what I do not like with this proposal?  The whole _point_ of this

discussion is to make git _easier_.  Go ahead, try to explain to a

complete git newbie the proposed behaviour.  I have a pound here which

says that there is _no_ _way_ that this newbie says "well, that's easy".
Some people may not get this, but git has a reputation of being

complicated, and my "BS" argument was, is, and will be, that we should

keep clear and simple semantics, because they are the _only_ way to battle

that reputation.
Ciao,

Dscho
-

I try to explain the workflow that I'd use the feature for.

Maybe an easier setup could be used to achieve the same.

Any suggestions for a simpler setup are welcome.
The workflow is used by a group of developers that all have

access to a shared repository. One major goal is to keep the

setup for most developers simple. They are new to git and

as few commands as possible should be sufficient to start

working. Besides the typical stable branches (master, next)

shared topic branches should be available that can be used

to develop and review features before they are merged to the

stable branches. Patches are not send by email.
So here's the setup:
The central shared repo is called project-shared.git and contains,

for example, the following branches:

    master

    next

    work/topicA

    work/topicB

    ...
Developers clone the repo and check out the branches they are

interested in. For example a developer may want to track next

and work on topicB:
    git clone ssh://central.example.com/project-shared.git project

    cd project

    git checkout -b next origin/next

    git checkout -b work/topicB origin/work/topicB
This is sufficient. No adding of remotes is needed. Neither

is a private repository on a server required. After cloning,

developers have all they need.
Later work/topicB has new commits and should be pushed:
    git push origin
The default behaviour of push is fine. Only matching branches

are pushed.
_But_, origin is a shared repository. Therefore branches may

have advanced and git push may report
error: remote 'refs/heads/next' is not a strict subset of local ref

'refs/heads/next'. maybe you are not up-to-date and need to pull first?
So here's the problem. The developer didn't do anything wrong.

But git complaints with an error. Git also recommends to run

pull, so the developer runs "git pull". But this doesn't help,

because it's only updating work/topicB and "git push" will

complain with the very same error.
What you need to do ...
[ message continues ]

Or just
	git push origin work/topicB
Actually I push to my public repo from multiple working repositories

(because usually I work on my laptop, but sometimes I do work from a

different machine), so the above can still happen.
--b.

-

git pull. Not git push. git pull operates on one working branch

at a time (by default), whereas git push uploads and fast-forwards

all the common branches (by default). I want git pull to work like

git push.
--

Andreas Ericsson                   andreas.ericsson@op5.se

OP5 AB                             www.op5.se

Tel: +46 8-230225                  Fax: +46 8-230231

-

This asymmetry is also part of what makes Git hard to learn at first.
There is a lot of new terminology to learn:
  refs

  remotes

  fast-forwarding

  rebasing

  origin

  master

  HEAD (which is not quite the same as good old CVS's HEAD)

  etc.
The solution is not, "have a good glossary" (which is needed, anyway),

but to make the documentation introduce those concepts at the right

time, instead of being chock-full of them from the beginning :)
Carl Worth's git-ification of the Mercurial book chapter is very nice in

this regard; it doesn't dump all the terminology on you, but rather

takes its time to introduce each concept when you are ready to know

about it [1].
It's kind of sad that the first thing "man git-push" tells you is this:
       git-push - Update remote refs along with associated objects
So you go, "refs?  associated objects?  whaaaaaat?" :)
Imagine someone learning the GIMP a few versions ago.  "I want to make

this photo sharper".  You go to the Filters/Enhance menu and you see
  Laplace

  Sobel

  Sharpen

  Unsharp mask
All of those sharpen the image.  Which one do you pick?
[1] http://cworth.org/hgbook-git/
  Federico
-

Not to an end user that has no idea or desire to learn about git remotes

or anything else. They see "ok, push updates all the remote branches, but

only if it's a fast-forward". They also see "righto, git pull updates all

the local branches, and even merges and does other funny things", but they

*don't* understand why git-pull (in their eyes) only update ONE branch that

they can actually check out. From a technical standpoint, fetch and push

are the same, but from the user perspective, push and pull seem much more

alike.
--

Andreas Ericsson                   andreas.ericsson@op5.se

OP5 AB                             www.op5.se

Tel: +46 8-230225                  Fax: +46 8-230231

-

Hi,
At some point you _have_ to expect your users to learn something.  In the

git documentation, we never pretend that pull is anything else than "fetch

+ merge".
So this assumption of your end user is a lack of training, really.
Ciao,

Dscho
-

I typically describe in detail every step they need to get

there work done. I expect that a few, simple commands that can

be used per copy & paste should solve 90% of the cases.
Some users will learn more, some will refuse to learn

more. Users from the second group will typically consult a

more experienced user if they hit a problem. At at that point

they are forced to learn.
I don't expect that all users know all details and the users

expect that their daily workflow is well supported with a

few commands.
	Steffen

-

I understand.  I was just suggesting that if the goal was to avoid the

error message on push, then specifying the branch to push explicitly
That strikes me as a less complete solution, since it only helps in the

case where the other branches all happen to be unmodified locally (hence

can be fast-forwarded).  In other cases the "git push" will still emit a

spurious error.
--b.

-

A better way to avoid that error message is ofcourse to make sure one

always starts development off of the latest version of the particular
For a corporate environment with multiple modules, the scenario where the

upstream is modified and the local branches aren't is more common than

anything else. The failure on push happens because developers do
git pull; # Yup, gotta do that to get the latest changes

git checkout whatever; # Here's where I want to work

work work work
If the tool can make it happen as few times as possible, that's good

enough for me. It's a lot easier to explain to my co-workers that

their push failed because someone else worked on it simultaneously

and pushed before they did, rather than telling them that they did

the pull/checkout sequence in the wrong order.
In the one scenario, it's "oh, I see". In the other, it's "god damn

piece of shit tool". Simple as that.
--

Andreas Ericsson                   andreas.ericsson@op5.se

OP5 AB                             www.op5.se

Tel: +46 8-230225                  Fax: +46 8-230231

-

Well, but then there's something you should really think

about. Then you _have_ local changes that are not at the remote.

You need to handle them somehow. Maybe you forgot to push

earlier and now the remote advanced.
Btw, the 'new' git pull should already have reported a warning

that it failed to fast forward the local branch. git pull

should have suggested to explicitly merge the branch with

local changes.
	Steffen

-

Perhaps, but not necessarily; you may have some branches with local

changes that you're content to leave unpushed (and un-updated).
So the case where this proposal helps is the case where:

	- the user hasn't learned how to name individual branches on the

	  push commandline, or has learned to do so, but wants less

	  typing, and

	- the user has one or more unmodified copies of remote branches

	  lying around, and

	- the user minds being reminded that those copies are out of

	  date, and

	- the user either has no *modified* copies of local branches, or

	  has some but doesn't mind being reminded that they're out of

	  date on each push.
--b.

-

Personally, I don't dare to work that way. But if you do want

to keep local changes on branches that would normally be pushed

but you do not want to push them now, you must not call "git

push" without arguments in the first place. Then you'll never

see the error emitted by push.
I put local changes that I do not intend to change right away

on a special branch for/<branch>. I only merge them to <branch>

if I decided to push them, and then I push them soon (maybe
Well, as I wrote above "git push" is a too sharp knife for

me. I _never_ have local changes that I don't intend to push.
I see your point. These are may requirements to make the

proposed behaviour of "git pull" useful. But I'd recommend to

use git exactly as you described when working with a shared

repository:
Just use "git pull" and "git push" and everything will be fine

if you work as follows:

- Use the same branch names that are used on the origin.

- Only check out branches locally that you are especially interested in.

- Only put changes on those branches if you intend to push them.

- Use "git pull" before you start to prepare branches for

   "git push".

- Keep you privat work on branches that are named differently

   from branches in the shared repository.
	Steffen
-

Sure, but that won't change. The only thing I'm proposing is that

local copies of remote branches are automatically fast-forwarded

on every pull, but only if
* the branch has no modifications what so ever

* the branch is set up to auto-merge with the particular branch

fetched from the particular remote
I really don't see any downsides what so ever with this. Those
Extremely common case for a large group of users. The worst part is

that this problem can get extremely annoying pretty quickly, with a

large number of repos and a large number of branches, whereas the

one dev per repo folks will never have big worries about it.
--

Andreas Ericsson                   andreas.ericsson@op5.se

OP5 AB                             www.op5.se

Tel: +46 8-230225                  Fax: +46 8-230231

-

You can't check what got added in your pull, e.g you can't review the new

code with something like
	gitk next..origin/next
I often do something like this, just to see what got changed. So at least

in my opinion you have to add a third point:
  * the branch has no modifications what so ever

  * the branch is set up to auto-merge with the particular branch

    fetched from the particular remote

				AND

  * the user set a config option to always autofastfoward if the above

    conditions are true! This could be implemented as a global option with

    a per branch overwrite.
Only if this option is added so a user can mark a branch to never

autofastforward (but it is still possible to  have an auto-merge config) you won't

loose valuable information.
-Peter

-

I'd be fine with that, except I think it's fairly dangerous to have

different defaults. The two first points are sort of the core of the
Sure. I was thinking something along these lines:
[branch "foo"]

	remote = bar

	merge = some-branch

	autofastforward = false
Or use git-fetch. git-pull is "fetch + merge". Conceptually, I don't

think it'll be any problem what so ever telling anyone that the branches

that aren't currently checked out get merged automatically only if they

result in a fast-forward.
--

Andreas Ericsson                   andreas.ericsson@op5.se

OP5 AB                             www.op5.se

Tel: +46 8-230225                  Fax: +46 8-230231

-

If I run git pull <remote> and have a auto-merge setup, I would merge the

remote side into my local branch. Then doing
	gitk ORIG_HEAD..
does the trick for to review what got added _and_ merged into my local

branch. I can't use this for other local branches not checked out. And as

I normally want to merge, your suggested behaviour is fine with me *IFF*
I aggree. And thats why I think your autofastforward should be set to

"false" per default, so that the distinction between local and remote

branches would still be clearly defined. Changing this would confuse new

users a lot more, me thinks.
Thats exactlcy what I had in mind. Maybe and a
[core]

	global_autofastforward = true
so you could have a sane default for every branch which is missing the
I'm not so sure about that.
-Peter

-

Hi,
It would be a matter of seconds until someone asks "why only

fast-forwards?  Would it not be _much_ better to merge _always_?  Stupid

git."
And all because the concept of "local" vs "remote" was blurred.
Ciao,

Dscho
-

It's already blurred, since we have git-pull instead of just git-fetch.

pull is the dwim version of fetch for anyone who isn't frequently pulling

from multiple repos that aren't configured as remotes (99% of git's users).

It really is. You configure it to merge this and that branch to those and

these branches. Sometimes it does and sometimes it doesn't, and the decision

is based on what branch you're currently on.
Only git-fetch has the clear local vs remote distinction, because it *never*

merges anything.
On a side-note, I'm starting to see why hg has gotten such a user-base.

Their docs focus on one repo per branch, which doesn't have this problem at

all.
So in short, letting "git-pull" fast-forward (or rebase; I like that idea)

the local copies of the remote tracking branches onto those remote tracking

branches will make life easier for:

* People who collaborate with others in a shared environment, where branch

  heads frequently change in the mothership repo but all development is

  supposed to be done at the tip of those mothership branches anyway.

  Nearly all corporate users fall into this category.

* People who just want to track and test the latest and greatest version of

  software X. Sometimes trying latest stable, and sometimes going with the

  freshest beta. They won't want to do "git merge beta origin/beta" after

  having done "git checkout beta", but they sure as hell don't want to run

  anything but the latest either. They may contribute once in a while, but

  generally just want to make sure they've got the bleeding edge.
--

Andreas Ericsson                   andreas.ericsson@op5.se

OP5 AB                             www.op5.se

Tel: +46 8-230225                  Fax: +46 8-230231

-

Hi,
Huh?  How is "I ask git pull to fetch the remote branch, and merge it into

my local branch" a blurring of local vs remote branch?
The local branch is still the local branch where it is _my_ responsibility

to update or change anything.  The remote branch is not.  If at all, I can

push -- iff it fast-forwards.
The fact that you can set up local mirroring branches (with "git remote

add") which are only updated via "git fetch" is _no_ blurring of the

concepts: we make it quite explicit that you cannot check them out.  They

are not local branches.
Hth,

Dscho
-

True. So git pull saves you exactly one command. The various fetch-all-git-

repos-and-update-all-fast-forward-branches in circulation at the office

save us ~500 commands each time they're run. Or rather, they *could* do

that, but you can't know until you've run it.
So what should I do to make what I want possible, without having git-pull

muddy the waters of local vs remote? There's clearly a user desire for it,

besides that of my eight co-workers and myself. Introduce git-<cmd-156>?
--

Andreas Ericsson                   andreas.ericsson@op5.se

OP5 AB                             www.op5.se

Tel: +46 8-230225                  Fax: +46 8-230231

-

Hi,
As I pointed out, there is no way to sensibly have 500 _local_ branches

lying around.
It is ridiculous to assume that you have to have local branches for all

the stable, maintenance, whatever branches.
When you have to change something, you branch, hack, develop, commit,

push, and then _clean up_ after yourself.  No need to clutter your 
If you _insist_ on your workflow, hey, git is a free program, and you can

do what you want to do with an alias easily enough.  You can even make

that alias part of the templates, so you can force your desires down the

throat of every of your coworkers.
However, that does not mean that you can insist on support for your

workflow in upstream git.
Ciao,

Dscho
-

error: The branch 'next' is not a strict subset of your current HEAD.

If you are sure you want to delete it, run 'git branch -D next'.
So you want me to tell all the developers they should use "git branch

-D maint" instead, so they can bypass the built-in security checks? No
With a git alias? No. There aren't even any switches in git to make it do

what I want. With a shell alias? Sure, it's doable, but cumbersome. With a

shell-script I can get it done, but it's ugly, inefficient and has to parse

everything twice. It's also a time-sink, and time is something I don't have
They're the ones that requested I hack it into git, but the result would
I'm not. We're currently discussing the pros and the cons, and I'm spending

my free 20 minutes every night working on a patch-series to make git-pull

a built-in and then implementing the switch/config-option/whatever that

makes it do what I want it to do. Apart from Junio, that's how everyone

that wants a feature implemented has to do it, so I'd hardly call that

insisting. If Junio decides the patch does something evil, I'll have to

settle for cherry-picking it into whatever branch I want to build from.
On a side note; I'd *love* for it to have a rebase option as well. Perhaps

I'll do that next. In the mean-time, I'd settle for just updating locally

modifiable copies of tracking branches that I've already configured git to

merge with a tracking branch when it happens to be a fast-forward.
--

Andreas Ericsson                   andreas.ericsson@op5.se

OP5 AB                             www.op5.se

Tel: +46 8-230225                  Fax: +46 8-230231

-

Maybe the solution here is to let "git branch -d" succeed if the

branch is a subset of HEAD or the branch it is tracking? That way,

deleting would succeed if upstream has all your commits.
--

Karl Hasselström, kha@treskal.com

      www.treskal.com/kalle

-

Deleting branches sitting on a ref reachable from any other locally

checked out branch certainly works. Since this is done to protect

commits from being pruned, and prune honors remote tracking branches

when deciding which commits are unreachable, I see no harm in letting

branches pointing to commits reachable from any remote tracking branch

be deleted.
--

Andreas Ericsson                   andreas.ericsson@op5.se

OP5 AB                             www.op5.se

Tel: +46 8-230225                  Fax: +46 8-230231

-

You're not forced to pull. Just use "git fetch" if you

want to do this. Or is something missing if you'd be
I (and, as I understood, Andreas, too) want to change the

default. Because we believe that git would be easier to use

in workflows based on a shared repository.
But if we fail to convince the list, maybe a global

configuration variable that configures "git pull" to autoforward

branches as propose would be a nearly equally good solution.
However, I think it is dangerous to introduce many of such

configuration options. Explaining the behaviour of git will

become harder. The behaviour will become dependent on the

local configuration and eventually the first question before

answering a question will be "send me the output of 'git config

--list'. I need to see how your git is configured."
	Steffen
-

Hi,
I am more concerned about having very fuzzy meanings of our nomenclature.

As of now, "pull = fetch + merge".  You want to change that, and I am sure

that it is harder to explain, Andreas' insistence on my being wrong

notwithstanding.
Whenever I told people "pull = fetch + merge", they got it.  Often I would

start a talk about git by introducing distributed development.  By stating

that working in a working directory is already forking, only without

commiting.  Then I'd go into details, by saying that there are multiple

repositories, and that you can update local copies of the remote branches

by "git fetch".  And you can merge by "git merge".  And then I would write

down on the blackboard -- the first written thing in my talk! -- pull =

fetch + merge.
My "pupils" _always_ liked the preciseness of the nomenclature.  And they

made many less mistakes because they had a clear mental model of what is 
And here I have to disagree strongly.  In a workflow based on a shared

repository, you do not want to merge.  You want to rebase.  First thing

you do when switching to another branch is fetch + rebase (that's why I

want an option to "pull --rebase" other branches).
But _even if_ you merge instead of rebase, I fail to see how the current

situation is different from CVS (which many people maintain is _easier_

than gi), where first thing you do is to "cvs update".  Just for git it is

"git pull".
But I think I have to drive my message home again: if what you desire

becomes reality, you take away the clear distinction between local

and remote branches.  In fact, those branches are neither local (because

the next pull will automatically update them with remote changes, but

_only_ if they fast-forward) nor remote (because you plan to work on them

locally).
But here is a proposal which should make you and your developers happy,

_and_ should be even easier to explain:
Work with topic branches.  And when you're done, delete them.
So the beginning of the ...
[ message continues ]

This is a *very* powerful concept.  Unfortunately, it is not 100% clear

in the documentation, at least not when you are reading about

fetch/merge/pull initially.
After reading the user's manual, I just could not understand what

"fetch" does, and therefore "merge" and "pull" did not make sense.  I

could not understand where Git stored the new changes from upstream

while also keeping my working directory in the same state it was.  After

10 years of using CVS/SVN, the assumption you have is, "whenever I get

changes from the remote repository, they will be visible in my working

copy (and merge conflicts are a fact of life)".
Some time later, I ran into "Git for computer scientists" and then

finally I got it, thanks to the nice diagrams and explanation.  I

realized how powerful a concept "fetch" is:  THIS is the right way to

examine what upstream worked on while you did your own local work.
Once you understand what's going on, however, it is not obvious how to

*visualize* the state of things after you do "git fetch".  Probably

"gitk --all" is the correct way to do it, but the presentation is not

ideal --- you have to hunt down the list of commits until you find your

own "master" (or whatever branch), and *there* is where you can say,

"oh, this is where we diverged; now let's see what I'll get when I

rebase later".
So, a few problems so far, with possible solutions:
* The docs do not make it easy to understand what git-fetch does.  Can

we just cut&paste most of "Git for computer scientists" into the Git

user's manual?).
* It's not obvious how to visualize the state after git-fetch, i.e.

"gitk --all" is not the first thing that occurs to you.  Maybe git-fetch

should suggest you to run "gitk --all" when your remotes get changes, so

that you can see what's going on?
* It's hard to find the "divergence point" in gitk's display, since you

have to scroll down the reverse-chronological list of commits until you

find your local refs and where they started diverging.  Would the...
[ message continues ]

It is a common workflow to run "git fetch; git rebase origin/<foo>" Where

foo is the remote tracking branch.  git-rebase should default to using

the remote tracking branch if no other ref is given.
Signed-off-by: Steven Walter <stevenrwalter@gmail.com>

---

 git-rebase.sh |   13 ++++++++++++-

 1 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/git-rebase.sh b/git-rebase.sh

index 058fcac..1a2b51b 100755

--- a/git-rebase.sh

+++ b/git-rebase.sh

@@ -261,8 +261,19 @@ case "$diff" in

 	;;

 esac
-# The upstream head must be given.  Make sure it is valid.

 upstream_name="$1"

+# Default to the remote tracking branch if we have one

+if [ -z "$upstream_name" ]

+then

+	curr_branch=$(git symbolic-ref -q HEAD)

+	curr_branch=${curr_branch//refs\/heads\//}

+	merge=$(git config branch.$curr_branch.merge)

+	remote=$(git config branch.$curr_branch.remote)

+	fetch=$(git config remote.$remote.fetch)

+

+	expanded=$(git fetch--tool expand-refs-wildcard "0000000000000000000000000000000000000000 $merge" "$remote" "$fetch")

+	upstream_name=${expanded/#*:/}

+fi

 upstream=`git rev-parse --verify "${upstream_name}^0"` ||

     die "invalid upstream $upstream_name"
--

1.5.3.4.1.gb4ad62-dirty
-

Hi,
This is potentially dangerous, as git-rebase does not use a detached HEAD

to replay the operations.  Therefore you cannot go back easily when

you started "git rebase" just to see its usage, and instead it did

unwanted things.
So I really think that you need a patch before this one, so that
	git reset --hard <branchname>@{1}
goes back to the pre-merge state after an inadvertent rebase.  (Note: this

behaviour is already implemented in rebase -i, because detached HEAD was

available at that time, as opposed to the time when git-rebase was

written.)
Ciao,

Dscho

-

I like it. :)
--

Andreas Ericsson                   andreas.ericsson@op5.se

OP5 AB                             www.op5.se

Tel: +46 8-230225                  Fax: +46 8-230231

-

It's definitely not a simple cut-and-paste--even with permission from

the author of "Git for computer scientists", fitting this in would

require rethinking the ordering of topics in the manual.  Also, there's

the restriction that we'd like to keep it looking good in plain ascii,

so diagrams have to be done in ascii somehow.
But as for using ideas from "Git for computer scientists", and/or

rethinking the ordering of the user's manual to make it more helpful.

Yes, that would be great!  Let me know what I can do to help.
--b.

-

Oh, that can be done.  It's easier to move text around than to
Hmm, what's the rationale for this?  I'd assume that most people read

the user's manual as a web page (or as bedside reading if they can print

a PDF thereof), where diagrams can be pretty.
  Federico
-

It misses the point though. Machines should work while humans are

lounging. If the humans have to read a lot to get the machines to
man pages.
--

Andreas Ericsson                   andreas.ericsson@op5.se

OP5 AB                             www.op5.se

Tel: +46 8-230225                  Fax: +46 8-230231

-

I think he's talking about Documentation/user-manual.txt, which isn't

turned into man pages.  (Might be nice if it could be though, I

suppose.)
--b.

-

There have always been a lot of complaints about the difficulty of

building the documentation.  (I don't know why; at least on Debian all

you need is an "apt-get build-dep git-core".)  And our response has been

"no problem, you can just read the source."  That's a big reason why
Yeah.  Heck, I just read it by pointing my web browser at kernel.org's

html copy....
So you might get some sympathy for a request for fancier diagrams, I

don't know.  It would require some more discussion, so I'd rather not

have other improvements blocked by this.
--b.

-

Exactly, because I do not work on those branches alone. These

are _shared_ branches. I can work on such a branch with a

group of developers. I'm willing to accept this bit of chaos.
Your rebase workflow is not possible if more than one dev wants

to work on the topic branch together.
Eventually you can linearize such a topic branch using rebase.

But you need to agree first that everyone else needs to delete
Again, if you want to share the topic branch the situation gets

more complex.
I absolutely agree that for purely local work topic branches that
Maybe. I know git quite well now and in a shared workflow "git pull"

with auto-fast-forward would help me. I often need to run "for each

local branch: git checkout ; git merge" to get rid of the errors

reported by "git push".
	Steffen

-

Hi,
It is not just a chaos.  I see a serious problem here.  On _your_

computer, you do _not_ have a shared branch.  Which is visible _even_ in

your modified work flow when you have unpushed changes.
So your desired illusion that your local branches are anything but local 
Why not?  I do it all the time.  CVS users do it all the time, for that 
No, you can linearize your branch already while cleaning up your local 
Hardly so.  In my proposed solution to your problem, there is nothing 
The problem I see here: you know git quite well.  Others don't, and will

be mightily confused why pull updates local branches sometimes, and

sometimes not.
Ciao,

Dscho
-

Ofcourse it is. People might pull from it. That's the whole point of a
For 200 branches at a time, where any of them might have changed? Do they

*really* go into all those branches and make really, really sure they run

git pull before they ever do anything? Isn't there a teensy weensy risk of

them forgetting that sometime when they really meant to do it?
On the other hand, if they absolutely *must* fork a branch at a specific

point in history (rather than "the latest published work this branch has"),

won't they run gitk/qgit/git-log/whatever, regardless of where their branch
Do you know this, or are you just guessing? I'm getting the exact same

confusion with the current behaviour. "Why the hell doesn't git update

all the branches I told the damn stupid tool to auto-merge when I pull?"

frequently echoes around the office. My co-workers aren't interested in

learning about git internals, or its reasons for doing what it does.

They don't give a damn about local vs remote namespaces for their branches.

They want to get some work done the smoothest way possible, but with our

small forest of repositories and the bushel of branches in each repo

makes life difficult for them, because they just can't imagine that

git doesn't do what they told it to, which is "this branch tracks that".

They may work on "this", but still want it to track "that" so they don't

have to run "git-update-all.sh", or "git-walk-everything.sh" or any other

of a dozen small and near-identical scripts floating around the office.
--

Andreas Ericsson                   andreas.ericsson@op5.se

OP5 AB                             www.op5.se

Tel: +46 8-230225                  Fax: +46 8-230231

-

Hi,
I slowly start to understand why your users are confused.  _Nobody_ works

on 200 branches at the same time.  (No, maintainers don't count: they do

not work _on_ the branches, but _with_; they merge them.)
When you're done with a topic, why do you leave it around?  Cluttering up 
That's easy.  A merge can have conflicts.  Conflicts need a working

directory.  You cannot have multiple working directories.  (Actually, you

can, with git-new-workdir, which would break down _horribly_ with your

desired change.)
Oh?  You don't have local changes?  Then why _on earth_ do you have a

local branch?
Ciao,

Dscho
-

We have 91 repositories at work. Roughly 60 of those are in active use.

The active repos are organized pretty much like the git repo with

'master', 'next' and 'maint'. We *do* work on all branches, but not

every day, ofcourse. They're NOT topic branches. We implement features

on topic-branches that we DO throw away, but those branches HAVE to be

there for us to be able to handle supporting of old versions as well as

implementing new features in a sane way. Throwing them away locally would

mean having to re-create them very frequently, and since they have to

exist in the upstream repo, "git fetch" would fetch and re-create them

every single time anyway.
So please, pretty please just drop the entire "use topic branches" argument.
Because it's convenient, ofcourse. Don't you have 'maint', 'next' and 'master'

in your clone of git.git? I'm guessing at least 99% of the people on this

list have those branches lying around in their clones, even if they only

ever use 'next' and/or 'master'.
--

Andreas Ericsson                   andreas.ericsson@op5.se

OP5 AB                             www.op5.se

Tel: +46 8-230225                  Fax: +46 8-230231

-

I find it just as easy to say: "git checkout origin/maint" or "git

checkout origin/next" when I want to examine some other branch.
If I want to make a change against maint, then I follow up "git

checkout origin/maint" with a "git checkout -b <topic-name>".  Part of

the reason though, why I *want* to keep the topic branch around is

precisely because I don't get to push to the central repository.  So I

want to keep it around so either (a) the central maintainer can pull

from me, and I delete it only after he's done the pull, or (b) so I

can use git-chery so I can see when patches that I created and sent

via git-format-patch and git-send-email have been accepted.
You're using a diferent workflow, and with users who aren't interested

in learning the fine points of git.  But main issue is that git isn't

optimized for what you want to do.  So I can suggest a couple of

different approaches.  One is to simply do things the 'hg' way.

Explicitly set up different repos for the different branches.  It's

more inefficient, but it does work.  And if the bulk of your users

are, ah, "aggressive ignorant" about git --- and many developers don't

care about learning the fine points of their tools, and a successful

software company needs to learn how to leverage the skills of such

mid-level engineers (only at a startup or if you are at Google can you

insist only only hiring the best and brightest) --- then it might be

that the 'hg' approach is easier.  Certainly that was the approach

Larry McVoy has always used with BitKeeper, and he is focused on

meeting the needs of his corporate customers.
Another would be to set up a wrapper script for "git-clone" that

creates a separate local working directory for each branch.  So for

example, it might do something like this:
#!/bin/sh

# Usage: get-repo <URL> [dir]

URL=$1

dir=$2

branches=`git-ls-remote --heads $URL | sed -e 's;.*/;;'`

if [ "$dir"x = "x" ]; then dir=`basename $URL`; fi

git clone $URL .temp-repo

mkdir $dir

cd $dir

for i in ...
[ message continues ]

Except that <topic-name> in this case will always be maint, since

only small bugfixes go on that branch. We tried using different-named

branches earlier, but the "git push <local-branch>" behaviour was

much too common, and we ended up with far too many randomly named
That makes diffing harder to do, and for those few long-living topics

that get pushed to mothership, there's no logical way for the user to

get only that branch. With the *:refs/remotes/foo/* config thing, this
Not really, I'm afraid. Apart from missing out on the auto-download of

new repos you get with "fetch = refs/heads/*:refs/remotes/origin/*",
We have

maint = maintenance code. some repos have several maint-branches

master = integration-tested code that will end up in next release

testing = unit-tested features, ready for integration testing
We can't really do without them, but perhaps I can do what Dscho

suggested in another email and force everyone to delete their

locally-modifiable branches once they're done making changes to

them. It'll end up being more commands to run for a single fix,

but at least it's not error-prone.
--

Andreas Ericsson                   andreas.ericsson@op5.se

OP5 AB                             www.op5.se

Tel: +46 8-230225                  Fax: +46 8-230231

-

You mean new branches, right?
And of course it's inelegant.  You just told us we were dealing with

CVS-brain-damaged corporate developers who can't be bothered to learn

about the fine points of using things the git way.  And I thought you

said there were only a few branches, "master", maint", etc. and all

the developers worked on were the tips of the branches of the

corporate mothership repository.  
It's like complaining that a car with manual transmission is too hard

to drive, and then when someone points out how this could be done with

an automatic transmission, and then complaining that that you don't

have the fine control of a manual transmission.  Well, of course you

don't!  Having that fine control requires that you *learn* how to use

that fine control correctly.
The solution I presented is more elegant than what hg does with

separate repositories, but sure, it does require disk space.  But this

disk space is cheap, even when compared with the salary costs of

CVS-damanged developers.  :-)
						- Ted

-

Ignore the corporate developers who use SCMs only because their company

requires them to.  Git is not the right thing for them; some

Eclipse-based monstrosity probably is.  It's like the horrendous

Oracle-based expense-reporting thing we have to use at Novell; I use it

because they make me, not because I'm particularly excited about

reporting expenses :)
However, *do think* of the free software developers who have been using

CVS forever.  You won't make friends among them if you keep saying, "you

use CVS?  You are brain-damaged, then."  CVS has been as good/bad to

them as to anyone else, and they are probably delighted to get a better

solution.  That solution needs to take into account the concepts to

which they have been exposed for the past N years.  Just because your

new concepts are better, doesn't mean that their old ones were wrong in

their time.
You don't find quantum physicists saying, "... yeah, like Newton's

brain-damaged followers" :)
  Federico
-

Oh, one does get this sort of comments.  Predominantly from those who

understand neither theory.
--

David Kastrup, Kriemhildstr. 15, 44793 Bochum

-

Quite contrary to what I think, and quite contrary to what Linus said in

his google speach. The problem with using a chainsaw instead of a tooth-

pick is that it's much easier to hurt yourself with a chainsaw. It's a
Nobody's particularly excited about reporting expenses. That's why there

are so few OSS solutions for it, and the ones that exist suck horribly

because whoever got the job of making the system knew his users would
Well, perhaps they were. CVS was a fairly important learning phase, much

like Thomas Edison who first discovered 2000 ways of not making a light-

bulb. It doesn't make them less valuable though, and the reason to keep

going until perfection is reached is that machines are made for work, and

humans are made for fun.
--

Andreas Ericsson                   andreas.ericsson@op5.se

OP5 AB                             www.op5.se

Tel: +46 8-230225                  Fax: +46 8-230231

-

I think I misunderstand Andreas' problem statement.  What I proposed

is useful for corporate developers who are deeply confused by

branches, especially when a single working directory is constantly

jumping back and forth between several branches.  (Having the current

branch in your bash prompt is a *big* help here, but we can't count on

them having it.)
So setting up a solution where each branch gets its own working

directory is a great solution where you have some number of newbie

developers in a company that get easily confused, while still

providing advanced users the ability to use the full power of git, and

giving both the newbie and advanced users the advantages of

disconnected operations.  And, of course, hopefully some day the

newbie users will grow up to become advanced users.
Right now I suspect a number of projects who have picked hg or bzr do

so because the traditional git model is too confusing to newbie users.

So for those people, creating the model where branch == a separate

directory may make life easier for them.  That's probably the one

thing that bzr does much better than git; it has a number of modes

which act as training wheels for the easily confused user.  For

example, the bzr's "bound branch" requires you to have network access,

since anything that modifies the local repository requires hitting the

remote server as well.  Horrible!  Gives you all of the downsides of

CVS!  But it allows some users to use the SCM is CVS-style mode, while

allowing more advanced users to use it in a more distributed mode.
So I think it *is* useful to help the corporate developers, because

that means there are more git users --- and someday some of us on this

list might have to work at such a company, and better that they use
Fair enough.  I used the term somewhat toungue-in-cheek, and I

probably should have said "newbie user" instead.
							- Ted

-

It's probably just a matter of writing a "git for CVS users" document.
Mike

-

First google hit for "git for CVS users":
	http://www.kernel.org/pub/software/scm/git/docs/cvs-migration.html
patches welcomed....
--b.

-

Yes. The few topic-branches that require input from several people are

distributed this way for peer review and trouble-shooting. It's nifty

if they're automatically downloaded, but not so much of an issue that
No, they're just surprised that what they thought would be automatic

isn't, and the curse about it when they put themselves in trouble by

forgetting about it. I've done it myself, and I've been using git since
It depends. For small bugfixes we sometimes commit directly on the

checked out branch. For larger issues we usually create a topic branch

and hack away, creating nicely ordered patch-series and such, but those

topic branches must be created from the tip of the upstream tracking

branch. What Dscho suggested would definitely work, but that would

mean I'd have to tell my co-workers to use 'git branch -D', which I'm

quite reluctant to do. One solution to that particular problem is

ofcourse to hack the delete-command of git-branch to honor remote

tracking branches when calculating dependencies, so the local branches

can safely be removed when they're done with them.
However, there's still this issue:

$ git checkout -b foo origin/pu

Branch foo set up to track remote branch refs/remotes/origin/pu.

Switched to a new branch "foo"
git checkout will say that every time a branch is created from a

tracking branch, unless one tells it --no-track (which people don't

learn about unless they're really into git), so it's quite natural

that people think git will actually make sure, within reasonable

limits, that 'foo' is kept in sync with refs/remotes/origin/pu.

That's not the case, however.
So we could either change the message to be:

"Branch foo set up to track remote branch refs/remotes/origin/pu,

provided you only ever issue git-pull while having branch foo

checked out."
Or we could make 'git checkout -b' default to --no-track, perhaps

giving annoying messages everytime someone "git-checkout -b"'s a

remote tracking branch.

Or we could make git-pull keep git checkout's ...
[ message continues ]

The thing is, if you have 200 local branches (because you

interact with 50 repositories with 4 primary branches each), you

do not constantly check all of them out anyway.  And the only

place that staleness of the local tracking fork matters is when

you check it out (that is, as long as you train your users that

the way to check differences with the upstream 'pu' in your case

is by doing operations with 'origin/pu' not with your local

'foo').
With that in mind, how about making "git checkout foo", after

foo is set up thusly, to show:
	git log --pretty=oneline --left-right origin/pu...foo
if (and only if) they have diverged?  Then you can deal with the

staleness of local tracking fork 'foo' in any way you want.
You could even go one step further and make this "checkout foo",

in addition to or instead of showing the above left-right log,
 - automatically run "git merge origin/pu" if it is a

   fast-forward, and say it did _not_ run that merge if it is

   not a fast-forward;
 - automatically run "git merge origin/pu" always, even if it is

   not a fast-forward;
 - automatically run "git rebase origin/pu" always;
Would that make your life easier?

-

Probably, although I think the confusion of 'foo' being something

else than 'origin/pu' after it's been checked out would be hard

to explain. I'll see how the patch turns out. If it all goes tits
That it would, except the confusion would then be that it's automatically

rebased for the branches one currently hasn't got checked out while pulling,

and the branch that *is* checked out gets merged (crazy, yes), so those

who prefer the rebase would get what they want by doing something completely

bonkers, such as:
git checkout -b just-gonna-pull HEAD^

git pull

git checkout whatever-other-branch-they-were-on
(yes, "aggresively ignorant", I think Ted said in an earlier mail)
It'd probably be better to go with Dscho's suggestion, although I'm not quite

sure what that was any more. It involved automagical rebasing on fetch or pull

though.
--

Andreas Ericsson                   andreas.ericsson@op5.se

OP5 AB                             www.op5.se

Tel: +46 8-230225                  Fax: +46 8-230231

-

git pull's automagic and the automatic behaviour of git checkout

proposed by Junio should always do the same. git pull should

be changed to act a if your three commands were fused into it

(but obviously implemented differently).
I think teaching "git checkout" a dwim mode is quite

interesting.  The required work to bring a local branch

up-to-date with a remote branch is deferred until really needed.

An then "git checkout" does the right thing. A lot of automagic

but definitely intriguing.
	Steffen
-

I think it would be better to implement it as a different command that

would do all those weird and tedious dwim things that suit a particular

kind of developer, but only so long as those operations succeed without

conflicts.
So for example the flow could go something like this;

---

read_branch_merge_config();
git fetch
if prefetch(local == remote_tracking)

	set ref local to match ref remote_tracking;

else if (--safe-rebase)

	try_rebase local onto remote_tracking;

---
It's such a common operation that I really do think it's worth

having support for it. Perhaps with a "--try-rebase" option to

git-pull.
If we then add a a "--push-after-pull" (to work on the current

branch only) we have the "git sync" alias readily available to

accommodate the average reluctant git user, and I'm sure gui

hackers could do wonders with it, especially on windows, where

people seem accustomed to a lot of things happening when clicking
Yup, and it can be done with a post-checkout hook (which I notice

there are no examples for, so I've added that to my ever-growing

todo).
--

Andreas Ericsson                   andreas.ericsson@op5.se

OP5 AB                             www.op5.se

Tel: +46 8-230225                  Fax: +46 8-230231

-

Hi,
I already explained in another mail (wasn't it even the one you replied

to?) how this can be done more efficiently.
Ciao,

Dscho
-

This is an interesting situation. If we find a good solution

that is accepted by the average developer in daily work. We

can probably learn a lot.
	Steffen

-

What actually wonders me why you guys do have 200 local branches. I

usually just create a local branch from the remote IFF I'd like to do some

work on it. And for inspecting a remote branch, a detached HEAD works just as

fine ...
-Peter

-

50+ repositories, with stable, testing and maint branches. Some repos have more

than that, so it amounts to roughly 200 branches. Each branch can be modified by

anyone (we're a small company - everyone still works everywhere), but all changes

should be done to the tip of the upstream branch. Especially for maint this is a

bit of a problem, since we frequently have consultants out and about, and they

sometimes find a bug that they commit locally to their own repo. They're in a

hurry though, and have no connection to the mothership repo so they can't git-pull

to get up to date. They aren't exactly developers, but savvy enough to fix a few

simple bugs, but the concept of the locally-modifiable branches not being updated

to their remote-tracking counterparts with each git-pull is just incomprehensible

to them. To me, that suggests that we're doing something wrong.
--

Andreas Ericsson                   andreas.ericsson@op5.se

OP5 AB                             www.op5.se

Tel: +46 8-230225                  Fax: +46 8-230231

-

Johannes described a workflow using rebase. It would create

a very clean history avoiding long "parallel roads" and it

mimics what experience git users would probably do: Just work

if you have no connection but cleanup your work by using rebase

before pushing it.
Johannes, and Peter, too, propose to delete local branches

asap to avoid the third copy besides the copy on the server

and the copy in remotes. They suggest that local branches

should be absolutely reserved for local work.
However, my feeling is that the current tools make it too hard

to work the way described. Therefore it's hard to sell such a

workflow to an unexperienced developer. For example checking

out a remote branch for doing some local work, pushing this

work, and cleaning up requires
    git checkout -b <branch> origin/<branch>

    # work work ...

    git push origin <branch>

    git checkout <don-t-work-here>

    git branch -D <branch>
These are a lot of commands and some of them look quite

redundant.  Nearly every command contains <branch>. Why isn't is

sufficient to tell the name of the branch I'm working on once.

And '-D' looks even dangerous to me because it overrides all

safety checks. This should not be needed in daily work.
Here are some questions:

Do you think a workflow using rebase is feasible for

unexperienced git users?

What would be needed to bring such a workflow down to a few,

simple and reliable commands?
I think the general question is what I described in a previous

mail: You have a shared repository containing stable and topic

branches. Provide a workflow that is as simple as possible

for as many as possible developers. The average developer

should need nothing more than equivalents of "cvs update",

"cvs commit" for daily work if there are no conflicts. Note,

there are no redundant branch names allowed in the commands.

If a developer doesn't switch branches there's no need to

tell the branch name. "git pull ; ... ; git push" is simple

b...
[ message continues ]

Ok, there is not a fundamental difference between local branches

that automatically merge from remotes and local branches that

are purely local and _never_ merge anything automatically. Both

are only local branches.
But these two types of branches already behave differently when

I call "git pull". There is already some kind of "illusion"

that some local branches are more tightly connected to remote

branches than others.
"git pull" could help to make the illusion even better. The

illusion would be better if it was easier to keep the heads

of the local branches near to the heads of branches they
You're right. You can rebase your local changes on top of the new

shared remote head. And this is probably the best thing you can do

to get a clean history. Maybe it should be easier.
So, do I understand correctly, what you propose is:

- never merge but only rebase

- Due to lacking support for this in "git pull", never use

   git pull when working with shared branches but instead _always_ use

   "git fetch; git rebase origin/<branch_I'm_on>".
So you say that one of the first messages in "git for CVS users",

"The equivalent of cvs update is git pull origin" [1], is wrong.

I don't think I'm able to sell your proposed workflow with the current

documentation. But maybe I try if I'm absolutely convinced that it

is superior.
Well if you have several local branches checked out that are

shared with others you run into the "git push" problem again ...
Isn't this a bit dangerous? It forces to overwrite master

no matter what's on it. You don't see diffstats nor a fast
I'd like to see "git push" here. But to make this work without

error you'd need to _delete_ master after you pushed. Otherwise

it could happen that you later work on a different shared

branch and "git push" would complain about master. "git push"

would recommend to do a "git pull" and we're back where the

discussion started.
Or do you propose to delete master at this point? That is do

you propose to _never_...
[ message continues ]

Hi,
Actually, not really.  For refs/remotes/* you expect them to change

possibly at the same time.  For your local branches, I'd expect them only

to change when I am actually working on them (and yes, that includes a 
It should.  Thus my question about best practices (which is technically in

this thread, but we are in a subthread which permuted into "I want git

pull to behave differently")
Hehe.  You just experienced the tremendous speed at which git moves.  In

the beginning, we really thought that "git pull" is all you'll ever want

to have.
But in the meantime, one of the biggest Enemies of the Rebase (yours

truly) converted to an avid fan of it, because it really helps 
Do the same as I, always say "git push origin master" (of course, you

should exchange "master" with whatever branch you want to push).  Be 
Yeah, I should have said something like "git branch -m master" 
I think it is not asking too much for the user to be a bit more precise.

If you really do not trust your developers to be capable of that, point 
Actually, the last two commands would better be
	git checkout HEAD^{commit}
If there really is an inconsistent behaviour, then we'll have to fix that.

We should not introduce inconsistent behaviour on top of that.
Ciao,

Dscho

-

Well, I'm lazy. git already knows everything. It knows that

the current branch is associated with a specific remote and it

pushes matching branches by default. And I took care to not

pollute the namespace. All my branches are named identical

in all repositories I'm dealing with. It's reasonable to want
Well I was more precise and got lazy over time. Now the most I do

is "git push --dry-run" and if it looks good I do "git push".

Most of the time I just say "git push".
As I pointed out earlier, "git push origin <some-branch>" can create

a new branch on the remote. "git push" never creates a new branch.
It's not inconsistent. It's an option of a branch. Git supports two

flavours of local branches. Some branches automatically merge and other

don't.
	Steffen

-

Hm.  There's gotta be more efficient ways to do that.  Maybe "git push .

origin/branch:branch" for each local "branch"?
But I'm still a little confused why you don't just want to "git push

name-of-branch" and avoid the whole problem.
--b.

-

There are two points:
- The current implementation of "git push" creates a remote branch

   if it does not yet exist. I want a safety net: "git push" only pushes

   if the remote branch already exists. In a sense "git push" is safer

   than "git push branch-with-typo". I use "git push branchname"

   exclusively for _creating_ new branches on the remote.
- Sometimes I updated two local branches and want to push. "git push"

   just works.
I started to believe that "git push" should always do the right

thing. Maybe it is not possible, but actually "git push" always

does the right thing for me if I ignore the error messages

about local branches that need merging. I tend to merge all

such branches right away, although it is a bit of a hassel.

Otherwise, there will be a day I'll miss an important error.
What concerns me more is how to explain the behaviour to others.

Right now, I can't tell them that "git push" just works but need

to go into a lot of details.
	Steffen

-

The downsides are that it makes the behavior of pull slightly more

complicated, and that it changes long-established default behavior of a

major subcommand.  (Those aren't huge disadvantages, but they are
OK, but that was one part of a four-"and" clause.  I don't see any

absolute clincher here, but on balance I think the disadvantages win

out.
--b.

-

Hi,
Aha.  So you want to make sure that the local branches are no longer

"purely" local.  And you want to stop updating them when unpushed changes

are in the local branches.
Seems I cannot help you.
Ciao,

Dscho
-

To me, it's more along the lines of "let git help me not make the

mistake of hacking on a six-week old codebase when I've explicitly asked

it to merge these and those remote tracking branches into these and

those local branches". Not updating those branches when there *are*

changes on them is something users can understand and will probably also 
Well, I knew that much from the start so I didn't ask you to, and since

you seem to fail to grasp what I had in mind, I'm sure you'd botch the

implementation anyway. Thanks for not quite offering though ;-)
I'm sure you'll review the patch though, and I'm equally sure I will

appreciate your technical comments rather a lot more than this current

bickering about a feature it seems I can't express clearly enough in words.
--

Andreas Ericsson                   andreas.ericsson@op5.se

OP5 AB                             www.op5.se

Tel: +46 8-230225                  Fax: +46 8-230231

-

I'd love this behavior, FWIW.
The "branches should not track their origin by default" seems suited

only to Linux kernel maintainers who frequently pull from many different

people, not to "random hacker who wants to keep track of a project he

doesn't maintain" :)
  Federico
-

Hi,
The problem I see here is not that the kernel folks would suffer, but that

the behaviour would not be easy to explain.  Which is a sure way to not

only give people rope, but put their heads in the noose.
Not having clear semantics is prone to lead to misunderstandings, and

mistakes.
IOW while I trust you when you say it would make things easier for you, I

am quite certain it would make things much harder for a substantial part

of the rest of humanity.
Ciao,

Dscho
-

Did this change recently? I just wrote a long message arguing for the

"autosetupmerge = 1" behavior by default, but when I tested with

1.5.3.4 it seems to be there already.
Am I seeing that correctly?
If so, thank you and congratulations! Not having to pass --track nor

manually configure autosetupmerge to get this very useful behavior is

a very nice change!
A nice followup would be to improve the documentation for "git pull"

to better indicate some of the smarts that are now inherent in it.
I'll take a whack at that, (just as soon as I finish reading the rest

of this giant thread...).
-Carl

Here's also an interesting asymmetry. By default, git push

updates all remote branches matching a local branch. But git

pull "updates" only the current local branch to the state of

the remote head (by updating all local copies of the remote

branches, but merging only a single of these heads).
Maybe this asymmetry adds to the confusion. I see arguments

for both behaviours:

1) In both cases, update only the branch you're on

or

2) in both cases update all matching branches.

(btw, if I do not intend to merge at all, you can always use

"git fetch".)
	Steffen
-

Agreed. /usr/libexec/git/ seems to me to be the ideal spot for
Disagreed, for obvious reasons. Many OSS projects are patch-centric

and developed much like git. OTOH, having to run "git format-patch"

rather than "git-format-patch" probably isn't so hampering that we
But very nifty for incremental imports. I track several CVS repos

that I continuously import. They're also self-explanatory, so

they don't add much to the clutter. Same reasons as above though;

there's no real reason not to invoke them as "git cvsimport" rather
git-filter-branch could definitely live its life hidden somewhere.

git-fsck probably should stay with the plumbing, as it's used by

other porcelainish programs more often than run directly by the
Note that this is already possible, using a libexec-dir and

passing --exec-dir to the git wrapper. The only thing that isn't

done is deciding what's *definitely* plumbing. Once that's defined,

the makefile can install plumbing to a separate directory and
Hiding the really core plumbing and getting rid of redundant

programs (git-am, git-apply, git-applypatch, ...) would do wonders,

methinks.
--

Andreas Ericsson                   andreas.ericsson@op5.se

OP5 AB                             www.op5.se

Tel: +46 8-230225                  Fax: +46 8-230231

-

/usr/libexec is against the Filesystem Hierarchy Standard (FHS).

It is better to use /usr/lib/git/ for that.
Dmitry

-

Hi,
Yeah, I was arguing a bit about obsoleting the "git-*" programs.  But it

seems that we are not getting it anytime soon.
FWIW try this:
	git<Space><Tab>
or even better:
	git<Enter>
Ciao,

Dscho
-

Hmm, this didn't work.  I'm still using git 1.5.4.2 from the

stock openSUSE 10.3 packages --- did this get added in a newer version?
  Federico
-

That is what "Git User's Manual" (and tutorials) is for. And there is

glossary in documentation.
It is better to use bash (or zsh) completion, than rely on completion

of commands names.
Beijing hacker: git <Tab>
I think git-cherry will soon be obsoleted and removed, such like

git-applymbox and it companion git-applypatch are being obsoleted by

git-am.
git-am applies series of patches _with description_ from messagebox,

creating commits if patch applies without conflicts. It requires git

extended patch for sensible operation; it is best when patch is result

of git-format-patch. git-apply is to apply GNU patch (optionally git

patch) to working area, or working area and index, but do not create a

commit. It is improved version of GNU patch utility (it understands

git extended diff syntax), but it is not meant (alone) to work with

commits send by email.
--

Jakub Narebski

-

Since no-one else has mentioned it, I -- and I suspect some others --

try to use the "beer round" model with FOSS. When I go out for drinks

with people from work, I don't try and keep a precisely tally of who

has bought a drink for me and so whom I shoud buy a drink, and worry

about what how the accounting changes if me or someone goes home

early. I generally take the view that all the imbalances will roughly

balance out over the future. Sure you keep an eye out for complete

freeloaders, but you don't get overexcited about a temporary

imbalance.
Likewise, I will sometimes make suggestions -- hopefully politely --

of various projects where my skills don't fit. (Eg, I'm not going to

add non-trivial features to the git shell scripts because I just don't

know non-trivial shell.) Hopefully some minor patch I've submitted

somewhere has, possibly through helping someone else who's helped

someone else.... , helped you some minuscule amount.
I'm perfectly fine with someone politely saying "no developers are

interested in this, so it won't happen if you don't implement it

yourself", but when you accuse people who just bring up a possible

feature of being free-loaders it makes them question whether other

projects would be more productive places to spend one's time.
It's the difference between being told "I suspect you'll have to do it

yourself" and "how dare you even ask that! do it yourself!".
--

cheers, dave tweed__________________________

david.tweed@gmail.com

Rm 124, School of Systems Engineering, University of Reading.

"we had no idea that when we added templates we were adding a Turing-

complete compile-time language." -- C++ standardisation committee

-

Not everybody likes getting the kind of treatment you find fit to dish
And you wonder that people are unwilling to ask for things on the

list?  When even mentioning something in a _survey_ makes core

developers want to bang their heads against a wall?
I find it a pity that my suggestion to ask about how comfortable

people are with the tone on the list did not make it into the survey.

Enough core developers make the tone sufficiently unconstructive to

make it quite understandable that people are unwilling to ask

questions here, in order to avoid getting their heads banged against a

wall, virtual or not.
--

David Kastrup, Kriemhildstr. 15, 44793 Bochum

-

I think next to last question in the survey
 61. Did you have problems getting GIT help on mailing list or on IRC channel?

     What were it? What could be improved?
was the place to put complaints about git mailing list. I didn't want

to add separate question because this survey has too many questions

(is too long) already.
--

Jakub Narebski

-

What if there are no problems getting help once you submit to letting

your head get bashed in?
The problem is not with getting help on the list: the list is

bristling with competent people.  The problem is the price to pay in

self-esteem and comfort.
--

David Kastrup, Kriemhildstr. 15, 44793 Bochum

-

I'm trying to see this negative tone that apparently exists on the

list. As a long-time lurker, I only see a fairly standard open-source

expectation of basic knowledge and strong opinion. The list is fairly

good about point people to existing documentation. If you do something

that somebody thinks is stupid, they'll tell you so. They don't coddle

you here, but they are more than willing to help.
-

I never said that this list was not competent or helpful.
Anyway: if everybody had the same impression, we would not need a

survey, right?
--

David Kastrup, Kriemhildstr. 15, 44793 Bochum

-

"What could be improved?"
--

Jakub Narebski

-

Well, everybody knows who wanted to have that question in the survey, and 
My experience is that people come here, ask questions, and get served.

Often to stay.  So it cannot be that bad.
That is the problem of most surveys.  Usually you can see that after

50-75% of the questions, people are too bored, and just stop the survey

right then and there.  Or, if forced, give stupid answers because they are

annoyed with them.
Given that only one answer hinted at that AFAIR (it was something along

the lines "I already wasted too much time on this survey, so I cannot work

on git" or some such), I think you did a good job, though.
Again, thanks for all the work that you did/will do.  I know how tedious

it is to evaluate such surveys, especially the free form answers.  Must

have taken you days of real effort.
Ciao,

Dscho
-

And would it not be good to corroborate that "who" is alone with his

opinion?  The purpose of a survey is to get, not to push opinions.  So

why fear the question?
--

David Kastrup, Kriemhildstr. 15, 44793 Bochum

-

Well, he does have a point that they could have been more specific.
But, yes, "I wish we could get people to be more specific" might be the

better way to put it.
--b.

-

Hi,
Yes, there are politer ways to phrase it.
My main point is -- and always was -- that I'd like people to realise how

much it depends on _them_ if (and when) their wishes come true.
Ciao,

Dscho
-

Dscho, that's just not fair.
The fact is, stating what you wish for *is* taking an action. Starting to

complain about people stating their wishes (which you have done several

times) is simply unreasonable.
You don't have to *do* what they wish for, but I really wish you stopped

complaining about people bringing up their hopes for improvement.
Complain about it when somebody asks for something *stupid*. Explain why

it would be wrong to do something like that. But don't complain about

people having wish-lists, even if those people may not work on them.
Not everybody is a "doer". It's important to get input from people who are

just plain users, or hope to be.
		Linus

-

Hi,
Fair enough, I'll shut up about these issues.
A pity, but you're probably right.
Ciao,

Dscho
-

It's not a pity, and he's most definitely right. Users tend to think in terms

of "I'd like to get this task done" while coders tend to think in terms of

"this would be cool/possible to implement". The reason git actually *works* so

great is, I'm sure, the fact that it was originally designed around a very specific

need by someone thinking like a *user*. The fact that it happened to be a pretty

competent programmer just meant he could express his wishes as algorithms in a

programming language and make it happen.
I'm 100% sure that if Linus had been so interested in SCM's that he'd abandoned

the Linux kernel to be full-time maintainer for git instead, it would have had

all sorts of oddities in it that nobody uses, just because they're possible to

do.
I also think Linus made a very wise decision in picking Junio to maintain it. So

far, I haven't seen him accept a single feature-patch into git that wasn't

explained to solve a specific problem.
--

Andreas Ericsson                   andreas.ericsson@op5.se

OP5 AB                             www.op5.se

Tel: +46 8-230225                  Fax: +46 8-230231

-

While I hold Junio's technical judgment in high regard, it is actually

the area of communication skills and conversation tone where I would

really wish more to follow his example.
--

David Kastrup, Kriemhildstr. 15, 44793 Bochum

-

I agree with both of you.  My understanding of Dscho's original

comment was that people weren't saying *what* specifically their

wish-list was, which means we have no hope as a community of meeting

their requests.
Carl and Andy both had submitted a long list of very specific issues

that they had with Git.  The result of those lists being posted was

a number of people contributed improvements that lead us to 1.5.

Nobody can argue with that.
But just saying "MY GOD FIX THE UI" is not a wishlist item (yes,

that was a real survey answer).  It provides the community no

chance to understand what parts of the UI we need to work on, and

what parts the end-user is OK with or just hasn't even tried to use.
--

Shawn.

-

My interpretation of that answer is that your average user

(specifically Windows user) is more focused on a graphical interface,

and will mean GUI when they say UI.
The core plumbing in git is solid. The porcelain, with the 1.5 series,

makes git simpler to use from the command line. Now, the GUI available

for git is seriously lacking.
If you look at the GUI tools available for CVS, SVN, Perforce and

others, these offer you the complete functionality of those tools from

within them. They provide command line tools for those that need them,

but also come with a GUI application that allows the user to manage

their files within the source control system they are using (e.g.

WinCVS and P4V), shell integration (e.g. TortoiseCVS/SVN), IDE

integration and others.
At the moment, git has a good timeline view of commits through the

GUI, but have found the mingw version to be slow in places (I can't

remember when, but was likely before some performance improvements in

that area were made) and haven't tried out the Linux version yet. This

is a good starting point to build on, but to be more useful it needs

to extend to all of git's functionality.
- Reece

-

I'm not sure I agree with that. Here's the section on git from the

"Comparison with other systems" part of the Mercurial book. I'll

reproduce it in its entirety here and add my own comments about each

paragraph.
 > Git is a distributed revision control tool that was developed for

managing the

 > Linux kernel source tree. Like Mercurial, its early design was

somewhat influenced

 > by Monotone.
No argument there.
 > Git has an overwhelming command set, with version 1.5.0 providing 139

 > individual commands. It has a reputation for being difficult to

learn. It does not have

 > a user manual, only documentation for individual commands.
The part about the user manual is bunk (and was bunk in version 1.5.0,

IIRC, so I'm not sure where he gets that.) But the first part of that is

the key here. I admit that's even bitten me from time to time. I

couldn't remember the name of the "git-instaweb" command just yesterday;

doing "ls /usr/local/bin/git-*" was, I'd have to agree, pretty overwhelming.
We could probably solve that by tucking the plumbing commands away in a

lib or libexec directory and only exposing the porcelain commands in the

directory the end user is likely to look at.
But that's just an aspect of a more general fact: it's hard to use git

without getting exposed to the plumbing at least a little. Another

example is the manpages: try to look up the commonly-used options to

"git diff" (porcelain) and you will be forced to learn about "git

rev-parse" (plumbing).
The point is, though, that this is a valid complaint about git's UI that

has nothing to do with GUIs.
 > In terms of performance, git is extremely fast. There are several

common cases

 > in which it is faster than Mercurial, at least on Linux. However, its

performance

 > on (and general support for) Windows is, at the time of writing, far

behind that of

 > Mercurial.
A fair statement, though of course that's been improving by leaps and

bounds of late...
[ message continues ]

BTW I have patches here reworking the progress code for a more compact

display which should mitigate this issue quite a bit.
Nicolas

-

git-gui is scraping the output of the current progress meter using

a regex and then building a graphical progress bar from that output.
Any change in how git produces the progress bar should still keep

it in a form that git-gui can regex match and scrape, preferably

without needing to know what version of git it is pulling that

output from.  For example just teach git-gui to try two different

regexps, new format and if that doesn't match then try the old

(aka current) format.
--

Shawn.

-

I think my new format might be easier for you as the "title" and the

actual percentage and count is now on the same line.
Nicolas

-

Hi,
That might have been an advantage if Shawn did not do the code already.

As it is, he'll have to maintain two different regexes, _and_ detect when

to use which.
Ciao,

Dscho
-

As "plumbing" goes, "git rev-parse" isn't that bad, and the reference

here (to the "SPECIFYING REVISIONS" section) strikes me as reasonable.

We could factor out the common documentation into a separate (hopefully

more user-friendly) manpage about specifying revisions, I guess, and

refer to it everywhere instead of git-rev-parse.  I don't know--any
One frequent use case is the case of a tester that wants to try out a

bugfix in some topic branch.  You want to tell them: "please test the

fix-that-bug branch in git://myproject.org/~me/repo.git".  They need to

get that checked out somehow.  And they should be able to do it without

re-cloning every time.
That's one motivation, among others, for including git-branch (and

git-remote) very early.
Though actually the quickest way to checkout an arbitrary revision is

with detached heads, and that doesn't require learning git-branch right

away.  I've tried rewriting the user-manual start that way but wasn't

happy with the result and didn't get too far.  (See
Yes, there's a lot of low-hanging fruit here for someone that's

interested in streamlining the default git command output.  The

challenge is to get it a little terser while still being helpful (and

preserving progress meters, and not obscuring what's going on any more

than necessary).
--b.

-

But the *easiest* way, where "easiest" means "involves the fewest commands

with smallest risk of fscking up your own repo", is to do
git clone <other-devs-repo> other-devs-repo

cd other-devs-repo

git checkout -b thebug <the-bug-hash>
The proper command-sequence for any other way of doing it will inevitably

be different depending on whether or not the user has changes in his

worktree or not, whether or not those changes conflict with the bug-spot,

whether or not he's got the other developer's repo added as a remote, etc,

etc.
Too many ifs, really, whereas the first way is guaranteed to work exactly

the same way everytime, at the cost of almost always being ridiculously

suboptimal.
--

Andreas Ericsson                   andreas.ericsson@op5.se

OP5 AB                             www.op5.se

Tel: +46 8-230225                  Fax: +46 8-230231

-

Hi,
I'd just do
	git checkout <the-bug>^{commit}
and be done...
Ciao,

Dscho
-

The detached-HEAD approach also has the advantage that you don't leave

around stuff (new branch heads) that may have to be cleaned up or

modified in the future.  So you can tell someone about
	git clone git://url/

	git fetch origin

	git checkout <whatever>

	git remote add remotename git://other-url/

	git fetch remotename
and as long as they're not making changes, that's pretty much all

they'll ever need to do to checkout any version.
Sure, you can tell them to reclone every time, but I think they'll get

frustrated with that pretty soon.
--b.

-

So:
	if (have_bug_in_repo)

		do_the_dscho_way()

	else ...
See what I mean?
--

Andreas Ericsson                   andreas.ericsson@op5.se

OP5 AB                             www.op5.se

Tel: +46 8-230225                  Fax: +46 8-230231

-

(Pedantry alert: "hg pull" is equivalent to "git fetch" and doesn't

update the working copy. I'll talk here about the "hg pull; hg update"

pair which seems to be standard procedure in hg land.)
Here's a simple example in each system to demonstrate the difference.
---

 mkdir parent

 cd parent

 git init

 echo 'my baloney has a first name' > song.txt

 echo "it's o-s-c-a-r" >> song.txt

 echo 'my baloney has a last name' >> song.txt

 git add song.txt

 git commit -m "test file"

 cd ..

 git clone parent child

 cd parent

 echo "it's m-a-y-e-r" >> song.txt

 git commit -a -m "another line in the song"

 cd ../child

 perl -pi -e 's/first name/given name/' song.txt

 git pull

---
Result: "fatal: Entry 'song.txt not uptodate. Cannot merge."
---

 mkdir hgparent

 cd hgparent

 hg init

 echo 'my baloney has a first name' > song.txt

 echo "it's o-s-c-a-r" >> song.txt

 echo 'my baloney has a last name' >> song.txt

 hg add song.txt

 hg commit -m "test file"

 cd ..

 hg clone hgparent hgchild

 cd hgparent

 echo "it's m-a-y-e-r" >> song.txt

 hg commit -m "another line in the song"

 cd ../hgchild

 perl -pi -e 's/first name/given name/' song.txt

 hg pull

 hg update

---
Result: "0 files updated, 1 files merged, 0 files removed, 0 files

unresolved" and the file contains the change from the parent plus the

change from the child, with the latter still an uncommitted edit that

shows up in "hg diff".
-Steve

-

Heh. I do agree that some people just ask for unreasonable or stupid

things (or maybe they are just really bad at explaining them, and may have

something non-stupid in mind but just cannot articulate it).
And I also agree that there are tons of people who are just lazy and don't

even bother to try to explain themselves.
And I'll flame people myself. I can't even say that's a rare event. So I

shouldn't throw _too_ many stones, or one of them might bounce back. 
But at the same time, just accepting that there are people who will

potentially never really be productive members of society (whether

"society" is git or something bigger), is probably a good idea. They

aren't worth complaining about: they don't generally tend to take anything

away from the community unless the community itself reacts negatively to

them.
			Linus

-

I'll also point out that being a 'productive member of society' may have a

wider definition then you may think initially.
is a sysadmin who never contribures a line of code, but switches hundreds

of servers to linux and assists friends in migrating to Linux a productive

member? he doesn't contribute any code, so some people would say no, but

in spreading the use he is increasing the number of potential contributers

so others would say yes.
keep this in mind before you assume that someone isn't worth anything.
David Lang

-

I actually meant it in the absolutely most narrow possible meaning: you

take the least productive person imaginable, who is certainly not going to

do anything at all, and in the end, who cares? It's not like nonproductive

people really hurt.
Some people in the open source / free software world get really upset

about "freeloaders". I think that's silly. First off, I agree with you

that a lot of people don't even end up being freeloaders - even if you

never code a single line of code, there are ton of ways to be usefully

involved (and some of them will be entirely invisible to any developer -

helping random people outside the development lists, for example).
But more importantly, even somebody who really isn't productive at all

generally can't be messing things up either - so it's a nonissue. Unless

it results in tons of flaming ...
		Linus

-

He did not write "vague phrasings like this".  He wrote

"_expectations_ like these make [him] want to bang somebody's head on
It is something entirely different.
--

David Kastrup, Kriemhildstr. 15, 44793 Bochum

-

I recently attended a fairly large opensource conference in germany, where

companies that somehow do business around the opensource network

monitoring tool named Nagios gather and drink themselves and each other

into insensibility once a year. I ran into much the same issues there, even though

it would have made all our lives a whole lot easier if we could pull patches from

each others repositories.
--

Andreas Ericsson                   andreas.ericsson@op5.se

OP5 AB                             www.op5.se

Tel: +46 8-230225                  Fax: +46 8-230231

-

It's called "User". And since this is the Git _User's_ Survey, I guess

you will have to live with that. And anyway, where in the above you find

something about "expectation" rather than "suggestion"?
Gruesse,

--

Frank Lichtenheld <frank@lichtenheld.de>

www: http://www.djpig.de/

-

Hi,
"Figure out" sounds to me like an imperative.
But my real point is: these guys know exactly what they find hard in git.

Why don't they just come and tell us?
Just like Carl Worth did, way back when.  And it worked, didn't it?  Git

1.5 is vastly more user friendly than pre 1.5.
Ciao,

Dscho
-

I'm neither too.  But I don't think Git is in a niche.  OK, well,

in the overall world of software development its certainly in the

niche of version control, as uh, it doesn't do Enterprise Resource

Planning and Large Scale Embezzlement of Monies (ERPaLSEM).
Actually I've seen a number of people on the interweb saying things

like they were switching their project to Git because they felt

it had more staying power than say Monotone or Mercurial, partly

because the kernel devs were actively using it, partly because the

file formats are so simple and sane, and partly because lots of
Yes, this attitude *shocked the hell out of me*.  I really did not

expect it.  I nearly keeled over and died when I realized what the

folks in the back corner of the room were saying.
WINE uses Git.  Some folks were outright pissed off that there

was only one committer in WINE.  I think they felt the project

was maybe going to die because there was only one committer who

could apply patches.  That may wind up being true (there's only so

far that one human can scale without trusted helpers for different

submodules of a large system) but its not Git's fault, or any other

DVCS's fault for that matter.  At least its easy to fork WINE.
On the other hand active participants of two major organizations (KDE

and Eclipse) are starting to seriously look at Git.  The interest

in Git is growing in both of those groups, which can only be good

for us.  We'll learn more about how these groups do development,

and how we can best help them to accomplish more.
--

Shawn.

-

Well, hey, we asked for suggestions.  Think of it as a project someone

might want to work on, rather than as a command.
I don't know what they mean by "make git more task-oriented rather than

data-model-oriented", but the first suggestion ("Find out why people

find git hard to learn...") is certainly something I'd enjoy working on

if I found the time.
--b.

-

Nah, the Debian problem is just bad timing. Debian stable is stuck with

1.4.4 which is unfortunate but not fixable. unstable is very fast with

updates and backports.org is very good, too (but lacks at least 10 days

due to upload policy).
Gruesse,

--

Frank Lichtenheld <frank@lichtenheld.de>

www: http://www.djpig.de/

-