* Re: bug? - git-checkout treeish paths ignores deleted files
From: Mark Levedahl @ 2007-10-09 3:39 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Git Mailing List
In-Reply-To: <3B0685AB-0725-4473-8AE6-359F93851C10@wincent.com>
Wincent Colaiuta wrote:
> El 9/10/2007, a las 2:58, Mark Levedahl escribió:
>
>> Shouldn't "git checkout topic path" make the directory tree rooted
>> at path identical to what is on branch topic? It doesn't.
>>
>>
>
> No, the behaviour is correct.
>
> - first you removed the file on the topic branch; at the same time you
> removed it from your working tree
> - then you switched back to the master branch and so the file was
> added back to your working tree
> - then you switched back to the topic branch, and seeing as the file
> "a" is not being tracked in the topic branch Git doesn't touch it
>
> In general, Git only meddles with stuff that you've told it to track.
> This is actually a good thing in most cases because it makes some
> workflows involving dirty trees or trees with untracked content
> somewhat more convenient.
>
> Cheers,
> Wincent
>
>
I'm not convinced...
"git checkout branch dir" should make dir have the same value it would
get if I just did "git checkout branch". The latter command will ignore
files only if they are untracked in *both* HEAD and branch. I fail to
see why the path-limited version of git-checkout should give a different
result on the part it is asked to affect than the non-path limited
version. This is very inconsistent and I'm having a hard time
understanding what workflow it will help.
Mark
^ permalink raw reply
* Re: bug? - git-checkout treeish paths ignores deleted files
From: Wincent Colaiuta @ 2007-10-09 1:52 UTC (permalink / raw)
To: Mark Levedahl; +Cc: Git Mailing List
In-Reply-To: <470AD21E.6070906@gmail.com>
El 9/10/2007, a las 2:58, Mark Levedahl escribió:
> Shouldn't "git checkout topic path" make the directory tree
> rooted at path identical to what is on branch topic? It doesn't.
>
> Try this:
>
> mkdir test
> cd test
> git init
> touch a b
> git add a b
> git commit -m 'base'
> git checkout -b topic
> git rm a
> git commit -m 'removed a'
> git checkout master
> git checkout topic .
>
> ...and the result is...
> ls
> a b
>
> instead of
> b
No, the behaviour is correct.
- first you removed the file on the topic branch; at the same time
you removed it from your working tree
- then you switched back to the master branch and so the file was
added back to your working tree
- then you switched back to the topic branch, and seeing as the file
"a" is not being tracked in the topic branch Git doesn't touch it
In general, Git only meddles with stuff that you've told it to track.
This is actually a good thing in most cases because it makes some
workflows involving dirty trees or trees with untracked content
somewhat more convenient.
Cheers,
Wincent
^ permalink raw reply
* Re: confused about a conflict during octopus merging
From: Linus Torvalds @ 2007-10-09 1:21 UTC (permalink / raw)
To: martin f krafft; +Cc: git discussion list
In-Reply-To: <20071009003156.GA30498@lapse.madduck.net>
On Tue, 9 Oct 2007, martin f krafft wrote:
>
> I am a little confused why the following yields a conflict:
Octopus merges are special. Don't use them unless you really know what
you're doing. And generally not even then ;)
> $ git merge master second
> Trying simple merge with bb5f1b4f3a8cbfcbc9dbc97cc823f3ca05db2db1
> Trying simple merge with 7370737ff3aa6540a425db015e194766d2cbda2e
> Simple merge did not work, trying automatic merge.
> Added d in both, but differently.
> error: Could not read .merge_file_mCwa4W
> ERROR: Merge conflict in d
> fatal: merge program failed
> Automatic merge failed; fix conflicts and then commit the result.
>
> I don't understand why these conflict. I mean, sure, it makes sense:
> after merging master, file d is at d2. Now when merging second, it
> tries to replace d by its ancestor, d1.
Right. It makes total sense, because an octopus merge is simply always
going to create a whole new merge commit that goes through the sources one
by one, and merges them in - and if you do that, then you get a conflict
in "d".
> What I don't understand is why Git does not understand that commit
> d is part of the path of arriving at d2, so when 'second' is merged,
> Git *should* really see that the change to file d in 'second' (d1)
> is an ancestor of the already present d2 commit, and *not* conflict.
>
> What am I misunderstanding here?
Octopus merges do *not* fast-forward. Maybe they should. But they don't.
So when the octopus merge starts merging in "master" into the "merger"
branch, it will *not* just fast-forward the branch to "master". Instead,
if will generate a new tree that is basically the merged state: but that
new tree is *not* the same as the master commit, it's literally a merge of
the two branches - which in practice means that it has the same *content*
as master, but it's not at that commit.
So that first stage of the octopus merge has gone fine, but it didn't
really do what you expected.
And so now we have a half-way done octopus merge, with the first branch
added. Now it merges in the second branch ("second"), and it *still* has
the merge base being the original merge base, namely "merger".
And from that standpoint, it really *is* a conflict.
I do think that
- octopus merges should probably refuse to happen when a branch isn't a
"merge" at all, but a fast-forward.
*or*
- we should make octopus-merges smarter, and for each branch that is a
fast-forward, it really just fast-forwards.
but I don't think the current behaviour is "wrong", it's just not what you
expected.
If you think of octopus merges as a really stupid thing where git will
mindlessly do a three-way merge based on the *current* state with all the
branches you name, then you get the current octopus merge. You just
expected it to be smarter than it is, probably because you compare it to
the *real* merge.
Linus
^ permalink raw reply
* bug? - git-checkout treeish paths ignores deleted files
From: Mark Levedahl @ 2007-10-09 0:58 UTC (permalink / raw)
To: Git Mailing List
Shouldn't "git checkout topic path" make the directory tree rooted at
path identical to what is on branch topic? It doesn't.
Try this:
mkdir test
cd test
git init
touch a b
git add a b
git commit -m 'base'
git checkout -b topic
git rm a
git commit -m 'removed a'
git checkout master
git checkout topic .
...and the result is...
ls
a b
instead of
b
Mark
^ permalink raw reply
* Re: [TIG PATCH] Add missing = for comparison in obsolete actions check.
From: Jonas Fonseca @ 2007-10-09 0:53 UTC (permalink / raw)
To: James Bowes; +Cc: git
In-Reply-To: <20071008173034.GA27292@crux.toronto.redhat.com>
James Bowes <jbowes@dangerouslyinc.com> wrote Mon, Oct 08, 2007:
> Signed-off-by: James Bowes <jbowes@dangerouslyinc.com>
> ---
> tig.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/tig.c b/tig.c
> index 933d083..30c505b 100644
> --- a/tig.c
> +++ b/tig.c
> @@ -1184,7 +1184,7 @@ option_bind_command(int argc, char *argv[])
> }
>
> request = get_request(argv[2]);
> - if (request = REQ_NONE) {
> + if (request == REQ_NONE) {
> const char *obsolete[] = { "cherry-pick" };
> size_t namelen = strlen(argv[2]);
> int i;
Oops, thanks. I should readd -Wall to CFLAGS in my config.make file.
--
Jonas Fonseca
^ permalink raw reply
* confused about a conflict during octopus merging
From: martin f krafft @ 2007-10-09 0:31 UTC (permalink / raw)
To: git discussion list
[-- Attachment #1: Type: text/plain, Size: 2419 bytes --]
Dear list,
I am a little confused why the following yields a conflict:
$ git init
$ touch a; git add a; git commit -ma
Created initial commit 0ba90cc: a
0 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 a
# create merger branch for later
$ git branch merger
# create a file
$ date > d; git add d; git commit -md1
Created commit 89d22eb: d
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 d
# branch off a second branch and populate it
$ git checkout -b second
Switched to a new branch "second"
$ touch b; git add b; git commit -mb
Created commit 7370737: b
0 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 b
# modify file changed in previous commit
$ git checkout master
Switched to branch "master"
$ date >> d; git add d; git commit -md2
Created commit bb5f1b4: d2
1 files changed, 1 insertions(+), 1 deletions(-)
Now the tree structure is
x -- master: d2
| x -- second: b
|/
x d1
|
x -- merger: a
# now octopus-merge master+second into merger
$ git checkout merger
Switched to branch "merger"
$ git merge master second
Trying simple merge with bb5f1b4f3a8cbfcbc9dbc97cc823f3ca05db2db1
Trying simple merge with 7370737ff3aa6540a425db015e194766d2cbda2e
Simple merge did not work, trying automatic merge.
Added d in both, but differently.
error: Could not read .merge_file_mCwa4W
ERROR: Merge conflict in d
fatal: merge program failed
Automatic merge failed; fix conflicts and then commit the result.
I don't understand why these conflict. I mean, sure, it makes sense:
after merging master, file d is at d2. Now when merging second, it
tries to replace d by its ancestor, d1.
What I don't understand is why Git does not understand that commit
d is part of the path of arriving at d2, so when 'second' is merged,
Git *should* really see that the change to file d in 'second' (d1)
is an ancestor of the already present d2 commit, and *not* conflict.
What am I misunderstanding here?
Thanks,
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
"distrust all those who love you extremely
upon a very slight acquaintance and without any visible reason."
-- lord chesterfield
spamtraps: madduck.bogus@madduck.net
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] mergetool: support absolute paths to tools by git config merge.<tool>path
From: Theodore Tso @ 2007-10-08 22:01 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <20071008215729.GC31713@thunk.org>
On Mon, Oct 08, 2007 at 05:57:29PM -0400, Theodore Tso wrote:
> This patch doesn't work the config file doesn't specify an explicit
> mergetool via merge.tool. The reason for that is this loop:
Err, let me try that again. "This patch doesn't work IF the config
file doesn't specify an explicit > mergetool via merge.tool."
Sorry about the missing conjuction; the sentence doesn't make much
sense without it...
- Ted
^ permalink raw reply
* Re: [PATCH] mergetool: support absolute paths to tools by git config merge.<tool>path
From: Frank Lichtenheld @ 2007-10-08 22:00 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Theodore Ts'o, git
In-Reply-To: <11918785613855-git-send-email-prohaska@zib.de>
On Mon, Oct 08, 2007 at 11:22:40PM +0200, Steffen Prohaska wrote:
> This commit adds a mechanism to provide absolute paths to the
> commands called by 'git mergetool'. A path can be specified
> in the configuation variable merge.<toolname>path.
Why not merge.<toolname>.path?
This would it make easy to introduce new variables of the form
merge.<toolname>.<var> later if needed. I also think it is more
consistent with names of existing configuration variables.
(think branch.<name>.<var> or remote.<name>.<var>)
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* Re: [PATCH] mergetool: support absolute paths to tools by git config merge.<tool>path
From: Theodore Tso @ 2007-10-08 21:57 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <11918785613855-git-send-email-prohaska@zib.de>
On Mon, Oct 08, 2007 at 11:22:40PM +0200, Steffen Prohaska wrote:
> This commit adds a mechanism to provide absolute paths to the
> commands called by 'git mergetool'. A path can be specified
> in the configuation variable merge.<toolname>path.
This patch doesn't work the config file doesn't specify an explicit
mergetool via merge.tool. The reason for that is this loop:
for i in $merge_tool_candidates; do
if test $i = emerge ; then
cmd=emacs
else
cmd=$i
fi
if type $cmd > /dev/null 2>&1; then
merge_tool=$i
break
fi
done
is only checking to see if $cmd is in the path; it's not looking up
the merge.<toolname>path variable in this loop.
I guess the other question is whether we would be better off simply
telling the user to specify an absolute pathname in merge.tool, and
then having git-mergetool strip off the directory path via basename,
and then on window systems, stripping off the .EXE or .COM suffix, and
then downcasing the name so that something like "C:\Program
Files\ECMerge\ECMerge.exe" gets translated to "ecmerge". Would I be
right in guessing that the reason why you used merge.<toolname>path
approach was to avoid this messy headache?
- Ted
^ permalink raw reply
* Re: [PATCH] mergetool: add support for ECMerge
From: Theodore Tso @ 2007-10-08 21:44 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <11918785611059-git-send-email-prohaska@zib.de>
On Mon, Oct 08, 2007 at 11:22:41PM +0200, Steffen Prohaska wrote:
> Add support for ECMerge available from
> http://www.elliecomputing.com/Products/merge_overview.asp
Hmm. A propietary merge tool. It's not that much code, so I guess....
I note though that it claims on the web page that they are integrated
with "most famous SCM's", but they don't include git. If we add this
support, are they going to change their web page? :-)
Also, ECmerge is supported on Linux, Solaris, MacOS X, and Windows.
Which platforms have you tested on? My guess is that if it works on
Linux, it'll probably work on Solaris and MacOS, but is it a fair
guess you haven't tested under Windows? Not that most Windows systems
are going to be able to use git-mergetool since it's a bash script,
unless they are using Cygwin or some such.
- Ted
^ permalink raw reply
* [PATCH] mergetool: support absolute paths to tools by git config merge.<tool>path
From: Steffen Prohaska @ 2007-10-08 21:22 UTC (permalink / raw)
To: Theodore Ts'o; +Cc: git, Steffen Prohaska
This commit adds a mechanism to provide absolute paths to the
commands called by 'git mergetool'. A path can be specified
in the configuation variable merge.<toolname>path.
This mechanism is especially useful on Windows, where external
programs are unlikely to be in the path.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
Documentation/git-mergetool.txt | 5 ++
git-mergetool.sh | 81 ++++++++++++++++++++++-----------------
2 files changed, 51 insertions(+), 35 deletions(-)
diff --git a/Documentation/git-mergetool.txt b/Documentation/git-mergetool.txt
index 6c32c6d..6b97aaa 100644
--- a/Documentation/git-mergetool.txt
+++ b/Documentation/git-mergetool.txt
@@ -31,6 +31,11 @@ If a merge resolution program is not specified, 'git mergetool'
will use the configuration variable merge.tool. If the
configuration variable merge.tool is not set, 'git mergetool'
will pick a suitable default.
++
+You can explicitly provide a full path to the tool by setting the
+configuration variable merge.<tool>path. For example, you
+can configure the absolute path to kdiff3 by setting merge.kdiff3path.
+Otherise, 'git mergetool' assumes the tool is available in PATH.
Author
------
diff --git a/git-mergetool.sh b/git-mergetool.sh
index 9f4f313..7f6c16f 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -192,10 +192,10 @@ merge_file () {
case "$merge_tool" in
kdiff3)
if base_present ; then
- (kdiff3 --auto --L1 "$path (Base)" --L2 "$path (Local)" --L3 "$path (Remote)" \
+ ("$merge_tool_path" --auto --L1 "$path (Base)" --L2 "$path (Local)" --L3 "$path (Remote)" \
-o "$path" -- "$BASE" "$LOCAL" "$REMOTE" > /dev/null 2>&1)
else
- (kdiff3 --auto --L1 "$path (Local)" --L2 "$path (Remote)" \
+ ("$merge_tool_path" --auto --L1 "$path (Local)" --L2 "$path (Remote)" \
-o "$path" -- "$LOCAL" "$REMOTE" > /dev/null 2>&1)
fi
status=$?
@@ -203,35 +203,35 @@ merge_file () {
;;
tkdiff)
if base_present ; then
- tkdiff -a "$BASE" -o "$path" -- "$LOCAL" "$REMOTE"
+ "$merge_tool_path" -a "$BASE" -o "$path" -- "$LOCAL" "$REMOTE"
else
- tkdiff -o "$path" -- "$LOCAL" "$REMOTE"
+ "$merge_tool_path" -o "$path" -- "$LOCAL" "$REMOTE"
fi
status=$?
save_backup
;;
meld|vimdiff)
touch "$BACKUP"
- $merge_tool -- "$LOCAL" "$path" "$REMOTE"
+ "$merge_tool_path" -- "$LOCAL" "$path" "$REMOTE"
check_unchanged
save_backup
;;
gvimdiff)
touch "$BACKUP"
- gvimdiff -f -- "$LOCAL" "$path" "$REMOTE"
+ "$merge_tool_path" -f -- "$LOCAL" "$path" "$REMOTE"
check_unchanged
save_backup
;;
xxdiff)
touch "$BACKUP"
if base_present ; then
- xxdiff -X --show-merged-pane \
+ "$merge_tool_path" -X --show-merged-pane \
-R 'Accel.SaveAsMerged: "Ctrl-S"' \
-R 'Accel.Search: "Ctrl+F"' \
-R 'Accel.SearchForward: "Ctrl-G"' \
--merged-file "$path" -- "$LOCAL" "$BASE" "$REMOTE"
else
- xxdiff -X --show-merged-pane \
+ "$merge_tool_path" -X --show-merged-pane \
-R 'Accel.SaveAsMerged: "Ctrl-S"' \
-R 'Accel.Search: "Ctrl+F"' \
-R 'Accel.SearchForward: "Ctrl-G"' \
@@ -243,18 +243,18 @@ merge_file () {
opendiff)
touch "$BACKUP"
if base_present; then
- opendiff "$LOCAL" "$REMOTE" -ancestor "$BASE" -merge "$path" | cat
+ "$merge_tool_path" "$LOCAL" "$REMOTE" -ancestor "$BASE" -merge "$path" | cat
else
- opendiff "$LOCAL" "$REMOTE" -merge "$path" | cat
+ "$merge_tool_path" "$LOCAL" "$REMOTE" -merge "$path" | cat
fi
check_unchanged
save_backup
;;
emerge)
if base_present ; then
- emacs -f emerge-files-with-ancestor-command "$LOCAL" "$REMOTE" "$BASE" "$(basename "$path")"
+ "$merge_tool_path" -f emerge-files-with-ancestor-command "$LOCAL" "$REMOTE" "$BASE" "$(basename "$path")"
else
- emacs -f emerge-files-command "$LOCAL" "$REMOTE" "$(basename "$path")"
+ "$merge_tool_path" -f emerge-files-command "$LOCAL" "$REMOTE" "$(basename "$path")"
fi
status=$?
save_backup
@@ -297,17 +297,23 @@ do
shift
done
+valid_tool() {
+ case "$1" in
+ kdiff3 | tkdiff | xxdiff | meld | opendiff | emerge | vimdiff | gvimdiff)
+ ;; # happy
+ *)
+ return 1
+ ;;
+ esac
+}
+
if test -z "$merge_tool"; then
merge_tool=`git config merge.tool`
- case "$merge_tool" in
- kdiff3 | tkdiff | xxdiff | meld | opendiff | emerge | vimdiff | gvimdiff | "")
- ;; # happy
- *)
+ test -n "$merge_tool" || valid_tool "$merge_tool" || {
echo >&2 "git config option merge.tool set to unknown tool: $merge_tool"
echo >&2 "Resetting to default..."
unset merge_tool
- ;;
- esac
+ }
fi
if test -z "$merge_tool" ; then
@@ -345,24 +351,29 @@ if test -z "$merge_tool" ; then
fi
fi
-case "$merge_tool" in
- kdiff3|tkdiff|meld|xxdiff|vimdiff|gvimdiff|opendiff)
- if ! type "$merge_tool" > /dev/null 2>&1; then
- echo "The merge tool $merge_tool is not available"
- exit 1
- fi
- ;;
- emerge)
- if ! type "emacs" > /dev/null 2>&1; then
- echo "Emacs is not available"
- exit 1
- fi
- ;;
- *)
- echo "Unknown merge tool: $merge_tool"
+valid_tool "$merge_tool" || {
+ echo >&2 "Unknown merge_tool $merge_tool"
exit 1
- ;;
-esac
+}
+
+if test -z "$merge_tool_path" ; then
+ merge_tool_path=`git config merge.${merge_tool}path`
+ if test -z "$merge_tool_path" ; then
+ case "$merge_tool" in
+ emerge)
+ merge_tool_path=emacs
+ ;;
+ *)
+ merge_tool_path=$merge_tool
+ ;;
+ esac
+ fi
+fi
+
+if ! type "$merge_tool_path" > /dev/null 2>&1; then
+ echo "The merge tool $merge_tool is not available as '$merge_tool_path'"
+ exit 1
+fi
if test $# -eq 0 ; then
files=`git ls-files -u | sed -e 's/^[^ ]* //' | sort -u`
--
1.5.3.3.127.g40d17
^ permalink raw reply related
* [PATCH] mergetool: add support for ECMerge
From: Steffen Prohaska @ 2007-10-08 21:22 UTC (permalink / raw)
To: Theodore Ts'o; +Cc: git, Steffen Prohaska
In-Reply-To: <11918785613855-git-send-email-prohaska@zib.de>
Add support for ECMerge available from
http://www.elliecomputing.com/Products/merge_overview.asp
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
Documentation/git-mergetool.txt | 2 +-
git-mergetool.sh | 12 +++++++++++-
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-mergetool.txt b/Documentation/git-mergetool.txt
index 6b97aaa..ece7718 100644
--- a/Documentation/git-mergetool.txt
+++ b/Documentation/git-mergetool.txt
@@ -25,7 +25,7 @@ OPTIONS
-t or --tool=<tool>::
Use the merge resolution program specified by <tool>.
Valid merge tools are:
- kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, and opendiff
+ kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge, and opendiff
+
If a merge resolution program is not specified, 'git mergetool'
will use the configuration variable merge.tool. If the
diff --git a/git-mergetool.sh b/git-mergetool.sh
index 7f6c16f..39f6595 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -250,6 +250,16 @@ merge_file () {
check_unchanged
save_backup
;;
+ ecmerge)
+ touch "$BACKUP"
+ if base_present; then
+ "$merge_tool_path" "$BASE" "$LOCAL" "$REMOTE" --mode=merge3 --to="$path"
+ else
+ "$merge_tool_path" "$LOCAL" "$REMOTE" --mode=merge2 --to="$path"
+ fi
+ check_unchanged
+ save_backup
+ ;;
emerge)
if base_present ; then
"$merge_tool_path" -f emerge-files-with-ancestor-command "$LOCAL" "$REMOTE" "$BASE" "$(basename "$path")"
@@ -299,7 +309,7 @@ done
valid_tool() {
case "$1" in
- kdiff3 | tkdiff | xxdiff | meld | opendiff | emerge | vimdiff | gvimdiff)
+ kdiff3 | tkdiff | xxdiff | meld | opendiff | emerge | vimdiff | gvimdiff | ecmerge)
;; # happy
*)
return 1
--
1.5.3.3.127.g40d17
^ permalink raw reply related
* Re: Git User's Survey 2007 unfinished summary continued
From: Jakub Narebski @ 2007-10-08 20:55 UTC (permalink / raw)
To: git
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=surveydata.csv
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 (Google searches)
* helpful error messages
* source code, reading the parts of git in shell script
* cogito
* using git in a live project / experimenting / trial and error
(That I was able to just delete the entire repository and start
over. That all my mistakes stayed local and didn't affect upstream
repos.)
* working on an established project that had documented processes for
using git
* writing code for both plumbing and Porcelain
writing documentation / tutorial for project / article
* understanding the internal representation of the repository;
good / simple design, basic principles; understanding concepts
* experience of working in software industry;
prior experience with version control systems (GNU Arch, SVN, BK, hg)
* version 1.5
* gitk, qgit; git-gui
One of more interesting:
* We hired a consultant to give us a tutorial
08. What did you find hardest?
TO DO
596 / 683 non-empty responses
Some of the responses:
* the level of complexity
* user interface:
too much / inconsistent commands, too many / cryptic options
distinction between plumbing and porcelain
many ways to do a task
insufficient error messages
'git <cmd> --help' prints manpage, not concise help summary
* obtuse command messages
* weak porcelain
e.g. git-update-index very central
* git-merge was plumbing
* remote / tracking branches
fetching, pushing and pulling, synchronizing repositories
the fact that push is not an opposite of pull
understanding the difference between committing and publishing
* handling multiple remote repositories
* merge vs rebase, deciding on proper workflow
working with topic branches
modifying a patch series
* merge defaults (which branch gets merged)
* git vs StGIT: slightly different merge conflict handling
* making it work in non-POSIX environments
working with git on case-insensitive and other strange filesystems
compiling on exotic OS, for example AIX
generating man pages
* lack of / bad / outdated / insufficient / badly structured docs
hard to find something in the documentation
git lingo in documentation, documentation for users who know git
using Cogito in some of documentation
* understanding of concepts, thinking in git way
understanding basic concepts and terminology
* distributed SCM concepts, paradigm shift
idea of non-linear history
* index (staging area): understanding, having it visible
* git-diff not showing added files
* commands named differently from equivalents in other SCM
differences from other SCM: git-commit needs '-a' to commit all
changes, strange semantics of git-add, multiple branches in repo
understanding terminology
* importing history from other SCM (bzr, svn)
* reverting changes, amending commit, undoing a commit
* keeping track of where am I, of which version I'm working with
finding which branch the change was made on
* lerning to use it as maintainer
maintaining "perfect patch series", keeping history clean
rewritig history before 'git rebase -i'
* dealing with merge conflicts
figuring how to undo failed merge and restart it
* learning conventions git expects but didn't document clearly
like commit message formatting
* setting up shared repo / shared server
setting up remote repository
* dealing with modified files (dirty tree) when switching branches,
merging (pulling) and rebasing
* checking out past revisions (or tagged revisions) with the
intention to return to newer revision
* creating independent branch, i.e. branch without ancestry
* exploring the history and previous versions of particular files
which are renamed and/or moved around, especially before --follow
was added
* some hot-shot peple in the community (on the mailing list)
* setting up gitweb
* having to use CLI interface
* no <some language> documentation
More interesting:
* All idiosyncrasies that make (made) sense for Linus' workflow but
aren't really orthogonal or predictable.
* Listening to whiners complain about how hard it was to learn
* Thinking outside the narrow box defined by previous SCMs.
* Not having used an SCM before!
* Following the explosive growth of features.
* Having a day job taking most of my time away from git.
* Convincing my boss to use it.
Conclusions:
- some of the things got corrected, like separate remote layout being
default for non-bare repositories, using git-add (porcelain)
instead of git-update-index (plumbing) in documentation and command
messages, promoting git-merge to porcelain, creating git-remote for
managing multiple repositories and remote branches, better
documentation including creating git user's manual.
- some things are hard because of historical reasons, such like
naming of commands, or consistency of options, and would be
difficult to change.
- doing things "git way", such as making index visible (and requiring
'git commit -a' to commit changes in all files), or rename
detection instead of rename tracking, or storing filenames and file
contents 'as-is' (without translation) are I think here to stay
- some of things are intrinsically hard, and would stay that way,
for example the distributed SCM concept, or nonlinear history.
How you use GIT
~~~~~~~~~~~~~~~
22. What projects do you track (or download) using GIT
(or git web interface)?
TO TABULARIZE
560 / 683 non-empty responses
A note: this question was meant to list projects which one _tracks_,
not the ones he/she maintains, meaning the projects in the remotes
(section).
Tracked projects can be divided into the following categories:
* undisclosed: proprietary code / work projects, own projects, etc.
* Linux kernel an kernel related projects (like udev or kvm)
* git related: git, gitk, git-gui, git-gui-i18n, stgit, tig,...
* freedesktop (and related) projects: XCB, Compiz, Mesa3D, Cairo,...
* Linux distributions: Source Mage, Slind,... (a few)
* tracked via git-svn, e.g. nsd, KDE, GIMP, FreeCiv
* others with official git repositories (like XMMS2 or ELinks)
* others with unofficial git repositories (like OpenOffice.org)
There are more that 100 different projects tracked mentioned in survey
(not all of them _choose_ git as their SCM).
Internationalization
~~~~~~~~~~~~~~~~~~~~
32. What do you need translated?
TO TABULARIZE
172 / 683 non-empty responses
Summary of responses, without count (which I guess is most important):
* user interface: command messages and error messages
* GUI: git-gui, gitk
* man pages and commands usage
('git <cmd> --help' , git <cmd> --usage')
* user's manual, tutorials, intro, howtos
* website / homepage
--
Jakub Narebski
Poland
(temporarily away from Internet)
^ permalink raw reply
* Re: Clean up "git log" format with DIFF_FORMAT_NO_OUTPUT
From: Linus Torvalds @ 2007-10-08 20:55 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano
In-Reply-To: <alpine.LFD.0.999.0710081342530.4964@woody.linux-foundation.org>
On Mon, 8 Oct 2007, Linus Torvalds wrote:
>
> This fixes an unnecessary empty line that we add to the log message when
> we generate diffs, but don't actually end up printing any due to having
> DIFF_FORMAT_NO_OUTPUT set.
Btw, this seems to break a few tests, where the test assumed the extra
newlines at the end of commands like "git show -s" (which also triggered
the extra unnecessary padding between commit text and the suppressed
diff).
I think the patch is correct, but the tests obviously would need fixing
before this patch should be applied.
Linus
^ permalink raw reply
* Clean up "git log" format with DIFF_FORMAT_NO_OUTPUT
From: Linus Torvalds @ 2007-10-08 20:46 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano
In-Reply-To: <alpine.LFD.0.999.0710081337490.4964@woody.linux-foundation.org>
This fixes an unnecessary empty line that we add to the log message when
we generate diffs, but don't actually end up printing any due to having
DIFF_FORMAT_NO_OUTPUT set.
This can happen with pickaxe or with rename following. The reason is that
we normally add an empty line between the commit and the diff, but we do
that even for the case where we've then suppressed the actual printing of
the diff.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---
log-tree.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/log-tree.c b/log-tree.c
index 2319154..62edd34 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -304,7 +304,8 @@ int log_tree_diff_flush(struct rev_info *opt)
* output for readability.
*/
show_log(opt, opt->diffopt.msg_sep);
- if (opt->verbose_header &&
+ if ((opt->diffopt.output_format & ~DIFF_FORMAT_NO_OUTPUT) &&
+ opt->verbose_header &&
opt->commit_format != CMIT_FMT_ONELINE) {
int pch = DIFF_FORMAT_DIFFSTAT | DIFF_FORMAT_PATCH;
if ((pch & opt->diffopt.output_format) == pch)
^ permalink raw reply related
* Fix embarrassing "git log --follow" bug
From: Linus Torvalds @ 2007-10-08 20:42 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano
It turns out that I completely broke "git log --follow" with my recent
patch to revision.c ("Fix revision log diff setup, avoid unnecessary diff
generation", commit b7bb760d5ed4881422673d32f869d140221d3564).
Why? Because --follow obviously requires the diff machinery to function,
exactly the same way pickaxe does.
So everybody is away right now, but considering that nobody even noticed
this bug, I don't think it matters. But for the record, here's the trivial
one-liner fix (well, two, since I also fixed the comment).
Because of the nature of the bug, if you ask for patches when following
(which is one of the things I normally do), the bug is hidden, because
then the request for diff output will automatically also enable the diffs
themselves.
So while "git log --follow <filename>" didn't work, adding a "-p"
magically made it work again even without this fix.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---
revision.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/revision.c b/revision.c
index 5d294be..e76da0d 100644
--- a/revision.c
+++ b/revision.c
@@ -1241,8 +1241,8 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, const ch
if (revs->diffopt.output_format & ~DIFF_FORMAT_NO_OUTPUT)
revs->diff = 1;
- /* Pickaxe needs diffs */
- if (revs->diffopt.pickaxe)
+ /* Pickaxe and rename following needs diffs */
+ if (revs->diffopt.pickaxe || revs->diffopt.follow_renames)
revs->diff = 1;
if (revs->topo_order)
^ permalink raw reply related
* Re: Merge problems with git-mingw
From: Lars Hjemli @ 2007-10-08 19:59 UTC (permalink / raw)
To: Peter Karlsson; +Cc: git, Johannes Sixt
In-Reply-To: <Pine.LNX.4.64.0710081555480.29570@ds9.cixit.se>
[Johannes CC'ed as the mingw.git maintainer]
On 10/8/07, Peter Karlsson <peter@softwolves.pp.se> wrote:
> $ git var GIT_COMMITTER_IDENT
> usage: git-var [-l | <variable>]
Does 'git var -l' work as expected? Also, could you try the latest
git-package provided by the cygwin installer? If CRLF-handling was
your problem, take a look at the description of core.autocrlf with
'git help config'.
[This does look like an issue with running mingw.git under Cygwin.
Johannes, is this even supposed to work?]
--
larsh
^ permalink raw reply
* Re: Trying to use git-filter-branch to compress history by removing large, obsolete binary files
From: J. Bruce Fields @ 2007-10-08 19:05 UTC (permalink / raw)
To: Theodore Tso
Cc: Johannes Sixt, Johannes Schindelin, Elijah Newren,
Frank Lichtenheld, git
In-Reply-To: <20071008163701.GA5868@thunk.org>
On Mon, Oct 08, 2007 at 12:37:01PM -0400, Theodore Tso wrote:
> I think what makes git-filter-branch different is that you can change
> a large amount of history with git-filter-branch, including large
> numbers of tags, etc. The reflog is quite sufficient to recover from
> a screwed up "git commit --amend". But I don't think the reflog is
> going to be sufficient given the kinds of changes that
> git-filter-branch can potentially do to your repository. Maybe
> default of --backup vs --no-backup could be changed via a config
> parameter, but I think the default is of backing up refs is a good
> think....
Yeah, it's clearly designed with rewriting a whole repo in mind.
It might also be handy, though, as a quick way to rewrite a single
branch. (E.g., "add 'Acked-by: Joe' to everything in 'for-upstream' not
in 'origin'", or "rename foo to bar in every commit in 'topic' not in
'origin'".).
I find the current defaults awkward for that case. Maybe it'd make
sense to treat the two cases differently.
> Perhaps a solution would be to add "git-filter-branch --cleanup" that
> that clears the reflog and wipes the backed up tags; perhaps first
> asking interactively if the user is really sure he/she wants to do
> this.
Maybe.
--b.
^ permalink raw reply
* Re: [PATCH 1/4] git-gui i18n: Add more words to glossary.
From: Christian Stimming @ 2007-10-08 19:43 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Johannes Schindelin, git
In-Reply-To: <20071007233937.GG2137@spearce.org>
Am Montag, 8. Oktober 2007 01:39 schrieb Shawn O. Pearce:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On Sun, 7 Oct 2007, Shawn O. Pearce wrote:
> > > If you are sending a series like that and its all po translation stuff
> > > that is unlikely to need commenting on feel free to just dump it all
> > > out as a single mbox (`git format-patch --stdout`) and attach it to the
> > > email. Less chance of the MUA mangling the message.
> >
> > In this case, I suggest just pushing it to git-gui-i18n.git, maybe as a
> > temporary branch "for-shawn", and send a pull request. That's the best
> > way to ensure that nothing gets mangled.
>
> Yea, that's an even better option. :-)
All pushed to git-gui-i18n.git mob branch now. I hope you can easily merge
them over.
Maybe po/git-gui.pot should be updated by you on git-gui.git and (by Dscho?)
on git-gui-i18n.git as well.
In other news, according to http://marc.info/?l=git&m=119170887523610&w=2
(almost last paragraph) people are already recognizing the localized
versions, but this also means the translations have to be watched out for so
that they will get updated as completely as possible especially before the
next release.
http://wiki.gnucash.org/wiki/index.php?title=String_Freeze&oldid=2022 is an
example on how the gnucash project tried to communicate to its translators
how the special "string freeze" period (i.e. a few weeks before the release)
will be handled in order to get a finalized translation for the actual
release. I don't know how formal you want to put this, but at least *some*
period of string freeze would be very good. As for the German translation,
I'd prefer any period length greater than 10 days in order to verify a
complete translation...
Regards,
Christian
^ permalink raw reply
* Re: [PATCH] Make strbuf_cmp inline, constify its arguments and optimize it a bit
From: Alex Riesen @ 2007-10-08 18:51 UTC (permalink / raw)
To: Florian Weimer
Cc: Pierre Habouzit, Miles Bader, Wincent Colaiuta, David Kastrup,
Timo Hirvonen, git, Junio C Hamano
In-Reply-To: <82k5py6l6f.fsf@mid.bfk.de>
Florian Weimer, Mon, Oct 08, 2007 10:54:32 +0200:
> And "int len" in the first line of the function body should be
> "size_t len".
right. Missed that.
^ permalink raw reply
* Re: [PATCH 1/2] Have a filter_start/filter_end API.
From: Alex Riesen @ 2007-10-08 18:48 UTC (permalink / raw)
To: Pierre Habouzit, Linus Torvalds, Junio C Hamano, git
In-Reply-To: <20071008072947.GB22552@artemis.corp>
Pierre Habouzit, Mon, Oct 08, 2007 09:29:47 +0200:
> On Sun, Oct 07, 2007 at 09:50:41PM +0000, Alex Riesen wrote:
> > Pierre Habouzit, Sun, Oct 07, 2007 18:52:18 +0200:
> > > Though, those are both things that I find ugly to "know" in convert.c.
> > > How things are allocated in strbufs is one of the few things we don't
> > > want to assume anywhere outside of the strbuf module.
> >
> > src is outside of strbuf scope. It is not internal to struct strbuf.
> > The caller must already know if it is inside of the given strbuf
> > instance.
> >
> > need_realloc is covered by make_room, isn't it?
>
> Internally yes, but make_room may move the buffer, if that happens,
> there is nothing we can do, in the case where we point inside (or at the
> begining of - fwiw it's the same here) the buffer
update the outside pointer you can. But I actually lost all interest:
personally I never use the filters and deeply despise the reasons
caused their existence.
> > I'd suggest just fix the caller, it is simple in convert.c: just use
> > ret, which contains exactly this information. If you insist on editing
> > in-place, which makes your routines really need the in-placeability
> > informaion. Just give it to them, better explicitely. All of this
> > makes the routines very convert.c specific, which is the reason why I
> > argument to have them just there and nowhere else.
> >
> > Alternatively, one can memdup ->buf (as it is the input for next
> > filter) every time a filter modifies it (which is safe, but simple,
> > slow, requires memory, and may fragment heap):
>
> This is exactly what we are trying to avoid with the current form.
I take this suggestion back. Do not use memdup, as it is slow,
requires lots of memory and may fragment heap. Sorry for repeating.
> Given how you try to micro-optimize strbuf_cmp I'm a bit lost here…
>
I didn't. It just happened. If I _wanted_ to optimize anything I
wouldn't start with a function which is used exactly one time in a
program with a name like "rerere" which is not even used in default
configuration.
^ permalink raw reply
* Re: [PATCH] Make git-clean a builtin
From: Linus Torvalds @ 2007-10-08 18:27 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Jeff King, Shawn Bohrer, git, gitster
In-Reply-To: <4709D027.3090003@viscovery.net>
On Mon, 8 Oct 2007, Johannes Sixt wrote:
> Jeff King schrieb:
> > On Sun, Oct 07, 2007 at 07:17:50PM -0700, Linus Torvalds wrote:
> >
> > > fchdir() is not portable.
> >
> > I was using the "even Solaris has it!" test, but yes, it's not POSIX. I
> > don't know how common it actually is (for curiosity's sake, do you know
> > of a common platform that lacks it?).
>
> Windows. ;)
Not just windows. Almost no "older" Unix has it. Including older versions
of Linux.
Linus
^ permalink raw reply
* [TIG PATCH] Add missing = for comparison in obsolete actions check.
From: James Bowes @ 2007-10-08 17:30 UTC (permalink / raw)
To: fonseca; +Cc: git
Signed-off-by: James Bowes <jbowes@dangerouslyinc.com>
---
tig.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tig.c b/tig.c
index 933d083..30c505b 100644
--- a/tig.c
+++ b/tig.c
@@ -1184,7 +1184,7 @@ option_bind_command(int argc, char *argv[])
}
request = get_request(argv[2]);
- if (request = REQ_NONE) {
+ if (request == REQ_NONE) {
const char *obsolete[] = { "cherry-pick" };
size_t namelen = strlen(argv[2]);
int i;
--
1.5.3.4.1155.gfe96ee
^ permalink raw reply related
* Re: Trying to use git-filter-branch to compress history by removing large, obsolete binary files
From: Theodore Tso @ 2007-10-08 16:37 UTC (permalink / raw)
To: J. Bruce Fields
Cc: Johannes Sixt, Johannes Schindelin, Elijah Newren,
Frank Lichtenheld, git
In-Reply-To: <20071008143650.GC2902@fieldses.org>
On Mon, Oct 08, 2007 at 10:36:50AM -0400, J. Bruce Fields wrote:
> Having it by default leave these backups around, even when everything
> succeeds, makes for unnecessary cleanup work in the normal case, and is
> inconsistent with the behavior of other git commands that destroy or
> rewrite history.
I think what makes git-filter-branch different is that you can change
a large amount of history with git-filter-branch, including large
numbers of tags, etc. The reflog is quite sufficient to recover from
a screwed up "git commit --amend". But I don't think the reflog is
going to be sufficient given the kinds of changes that
git-filter-branch can potentially do to your repository. Maybe
default of --backup vs --no-backup could be changed via a config
parameter, but I think the default is of backing up refs is a good
think....
Perhaps a solution would be to add "git-filter-branch --cleanup" that
that clears the reflog and wipes the backed up tags; perhaps first
asking interactively if the user is really sure he/she wants to do
this.
- Ted
^ permalink raw reply
* Re: [StGit PATCH 6/6] Let some commands work with detached HEAD
From: Karl Hasselström @ 2007-10-08 15:34 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20071008085540.9734.60137.stgit@yoghurt>
On 2007-10-08 10:55:41 +0200, Karl Hasselström wrote:
> --- a/stgit/commands/diff.py
> +++ b/stgit/commands/diff.py
> @@ -42,7 +42,7 @@ rev = '([patch][//[bottom | top]]) | <tree-ish> | base'
> If neither bottom nor top are given but a '//' is present, the command
> shows the specified patch (defaulting to the current one)."""
>
> -directory = DirectoryHasRepository()
> +directory = DirectoryHasRepository(needs_current_series = False)
> options = [make_option('-r', '--range',
> metavar = 'rev1[..[rev2]]', dest = 'revs',
> help = 'show the diff between revisions'),
This hunk shouldn't be here, since diff does use crt_series. (The
commit message also has to be modified accordingly.)
So, we don't have a single test that tries to run "stg diff". Duh.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox