* Re: How to check new commit availability without full fetch?
From: Robin Rosenberg @ 2010-01-11 7:31 UTC (permalink / raw)
To: SLONIK.AZ; +Cc: Git Mailing List
In-Reply-To: <ee2a733e1001100312j786108fct1b4c8abd0acc5afc@mail.gmail.com>
söndagen den 10 januari 2010 12.12.09 skrev Leo Razoumov:
> Hi List,
> I am trying to find a way to check availability of new commits
> *before* doing fetch or pull. Unfortunately, neither fetch nor pull
> take "--dry-run" option (unlike push)
Fetch has --dry-run. It's a fairly new option. The drawback is that it
still does the fetch, but it does not update the refs. If you re.run it
again it'll be quicker.
A faster option is to use ls-remote, but you'll have to parse the data
yourself and compare with your remote refs to see what refs has changed,
and that will not tell you /what/ the changes are.
-- robin
^ permalink raw reply
* Re: How to check new commit availability without full fetch?
From: Junio C Hamano @ 2010-01-11 8:09 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: SLONIK.AZ, Git Mailing List
In-Reply-To: <201001110831.28278.robin.rosenberg@dewire.com>
Robin Rosenberg <robin.rosenberg@dewire.com> writes:
> söndagen den 10 januari 2010 12.12.09 skrev Leo Razoumov:
>> Hi List,
>> I am trying to find a way to check availability of new commits
>> *before* doing fetch or pull. Unfortunately, neither fetch nor pull
>> take "--dry-run" option (unlike push)
>
> Fetch has --dry-run. It's a fairly new option. The drawback is that it
> still does the fetch, but it does not update the refs. If you re.run it
> again it'll be quicker.
Doesn't that worry us if it really is quicker?
If --dry-run doesn't update the refs, why do the objects that were
transferred by them not get asked the next time? There must be a bug
somewhere, but it is getting late already, so I'll leave it to experts in
the transfer area to figure it out...
^ permalink raw reply
* [PATCH 0/6] Re: Documentation: warn prominently against merging with dirty trees
From: Jonathan Nieder @ 2010-01-11 8:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Rast, Petr Baudis, git
In-Reply-To: <20100111041318.GA9806@progeny.tock>
Jonathan Nieder wrote:
> Junio C Hamano wrote:
>> You need to be able to tell the two ways in which a "mergy" operation can
>> "fail" apart [*1*].
>
> Thanks for bringing this up. The manual does not emphasize that
> point at all, but it should.
Maybe something like this (patch 4) could help. This should pass
through Thomas’s tree to avoid conflicts with his other changes; but
of course, I would be glad to hear any thoughts you have before then.
Jonathan Nieder (6):
Documentation: clarify one-line description for merge
Documentation: merge: add an overview
Documentation: merge: move configuration section to the end
Documentation: emphasize when git merge terminates early
Documentation: merge: add a section about fast-forward
Documentation: merge: tweak HOW MERGE WORKS section
Documentation/git-merge.txt | 149 ++++++++++++++++++++++++++----------------
1 files changed, 92 insertions(+), 57 deletions(-)
^ permalink raw reply
* [PATCH/RFC 1/6] Documentation: clarify one-line description for merge
From: Jonathan Nieder @ 2010-01-11 8:27 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Thomas Rast, Petr Baudis
In-Reply-To: <20100111082123.GA23742@progeny.tock>
The 'git merge' command is generally not used to tie completely
independent projects together (though it can be used to do that)
but to reconcile branches of development that may have diverged.
Try to make this clearer in its one-line description.
Cc: Petr Baudis <pasky@suse.cz>
Cc: Junio C Hamano <gitster@pobox.com>
Cc: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
I am not sure this is an improvement at all. Mostly I wanted to
convey the idea of code forks being reconciled, but the resulting
phrase is not nearly as nice.
Documentation/git-merge.txt | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index e886c2e..394ad0a 100644
--- a/Documentation/git-merge.txt
+++ b/Documentation/git-merge.txt
@@ -3,8 +3,7 @@ git-merge(1)
NAME
----
-git-merge - Join two or more development histories together
-
+git-merge - Re-join diverging branches of development
SYNOPSIS
--------
--
1.6.6
^ permalink raw reply related
* [PATCH 2/6] Documentation: merge: add an overview
From: Jonathan Nieder @ 2010-01-11 8:30 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Thomas Rast, Petr Baudis
In-Reply-To: <20100111082123.GA23742@progeny.tock>
The reader unfamiliar with the concepts of branching and merging
would have been completely lost. Try to help him with a diagram.
The diagram comes from the 'git rebase' manual page.
Cc: Petr Baudis <pasky@suse.cz>
Cc: Junio C Hamano <gitster@pobox.com>
Cc: Thomas Rast <trast@student.ethz.ch>,
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Does this tell enough of the story?
Documentation/git-merge.txt | 27 +++++++++++++++++++++++++--
1 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index 394ad0a..fe190e2 100644
--- a/Documentation/git-merge.txt
+++ b/Documentation/git-merge.txt
@@ -14,8 +14,31 @@ SYNOPSIS
DESCRIPTION
-----------
-This is the top-level interface to the merge machinery
-which drives multiple merge strategy scripts.
+Incorporates changes leading up to the named commits into the
+current branch. This command is used by 'git pull' to incorporate
+remote changes from another repository and may be used by hand to
+merge changes from one branch into another.
+
+Assume the following history exists and the current branch is
+"`master`":
+
+------------
+ A---B---C topic
+ /
+ D---E---F---G master
+------------
+
+Then "`git merge topic`" will apply the changes from `A`, `B`,
+and `C` to the work tree, and if they do not conflict with any
+changes from `master`, will store the result in a new commit along
+with the names of the two parent commits and a log message from the
+user describing the changes.
+
+------------
+ A---B---C topic
+ / \
+ D---E---F---G---H master
+------------
The second syntax (<msg> `HEAD` <remote>) is supported for
historical reasons. Do not use it from the command line or in
--
1.6.6
^ permalink raw reply related
* [PATCH 4/6] Documentation: emphasize when git merge terminates early
From: Jonathan Nieder @ 2010-01-11 8:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Rast, Petr Baudis, git
In-Reply-To: <20100111082123.GA23742@progeny.tock>
A merge-based operation in git can fail in two ways:
- One that stops before touching anything (either your index was
dirty and nothing happened, or your index was clean but you
had local modifications in your work tree).
- Another that goes ahead and results in conflicts.
The 'git merge' manual explains half of the first case as follows:
| A merge is always between the current `HEAD` and one or more
| commits (usually, branch head or tag), and the index file must
| match the tree of `HEAD` commit (i.e. the contents of the last commit)
| when it starts out.
The placement of this sentence makes it easy to skip over, and
its formulation is perhaps too formal to be memorable.
So give this point its own section and expand upon it. Most of
the added text is taken from <http://gitster.livejournal.com/25801.html>.
Cc: Petr Baudis <pasky@suse.cz>,
Cc: Junio C Hamano <gitster@pobox.com>
Cc: Thomas Rast <trast@student.ethz.ch>
Not-signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
This is not signed off because most of the text is from Junio’s
blog. I hope that is okay.
Documentation/git-merge.txt | 34 ++++++++++++++++++++++++----------
1 files changed, 24 insertions(+), 10 deletions(-)
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index e29bb97..8950aa4 100644
--- a/Documentation/git-merge.txt
+++ b/Documentation/git-merge.txt
@@ -60,6 +60,28 @@ include::merge-options.txt[]
least one <remote>. Specifying more than one <remote>
obviously means you are trying an Octopus.
+PRE-MERGE CHECKS
+----------------
+
+In some other version control systems, you merge/update and then
+commit, with the risk of clobbering your changes with humongous
+conflicts. You shouldn't be pulling or merging if you haven't got
+your own work into good shape and committed it locally (see also
+linkgit:git-stash[1]).
+
+But novices can make this mistake, and 'git pull' and 'git merge'
+will stop without doing anything when local uncommitted changes
+overlap with files that 'git pull'/'git merge' may need to update.
+
+Also, to avoid unrelated changes in the recorded commit, 'git
+pull' and 'git merge' abort if there are any changes registered
+in the index relative to the contents of the `HEAD` commit.
+(One exception is when the changed index entries are already in
+the same state that would result from the merge anyway.)
+
+If all named commits are already ancestors of `HEAD`, 'git merge'
+will exit early with the message "Already up-to-date."
+
include::merge-strategies.txt[]
@@ -70,17 +92,9 @@ HOW MERGE WORKS
---------------
A merge is always between the current `HEAD` and one or more
-commits (usually, branch head or tag), and the index file must
-match the tree of `HEAD` commit (i.e. the contents of the last commit)
-when it starts out. In other words, `git diff --cached HEAD` must
-report no changes. (One exception is when the changed index
-entries are already in the same state that would result from
-the merge anyway.)
-
-Three kinds of merge can happen:
+commits (usually, branch head or tag).
-* The merged commit is already contained in `HEAD`. This is the
- simplest case, called "Already up-to-date."
+Two kinds of merge can happen:
* `HEAD` is already contained in the merged commit. This is the
most common case especially when invoked from 'git pull':
--
1.6.6
^ permalink raw reply related
* [PATCH 5/6] Documentation: merge: add a section about fast-forward
From: Jonathan Nieder @ 2010-01-11 8:39 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Thomas Rast, Petr Baudis
In-Reply-To: <20100111082123.GA23742@progeny.tock>
Novices sometimes find the behavior of 'git merge' in the
fast-forward case surprising. Add a section to the manual to
describe it more thoroughly.
Cc: Petr Baudis <pasky@suse.cz>,
Cc: Junio C Hamano <gitster@pobox.com>
Cc: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Documentation/git-merge.txt | 31 ++++++++++++++++++-------------
1 files changed, 18 insertions(+), 13 deletions(-)
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index 8950aa4..ec9c6d3 100644
--- a/Documentation/git-merge.txt
+++ b/Documentation/git-merge.txt
@@ -82,6 +82,20 @@ the same state that would result from the merge anyway.)
If all named commits are already ancestors of `HEAD`, 'git merge'
will exit early with the message "Already up-to-date."
+FAST-FORWARD MERGE
+------------------
+
+Often the current branch head is an ancestor of the named commit.
+This is the most common case especially when invoked from 'git
+pull': you are tracking an upstream repository, you have committed
+no local changes, and now you want to update to a newer upstream
+revision. In this case, a new commit is not needed to store the
+combined history; instead, the `HEAD` (along with the index) is
+updated to point at the named commit, without creating an extra
+merge commit.
+
+This behavior can be suppressed with the `--no-ff` option.
+
include::merge-strategies.txt[]
@@ -94,19 +108,10 @@ HOW MERGE WORKS
A merge is always between the current `HEAD` and one or more
commits (usually, branch head or tag).
-Two kinds of merge can happen:
-
-* `HEAD` is already contained in the merged commit. This is the
- most common case especially when invoked from 'git pull':
- you are tracking an upstream repository, have committed no local
- changes and now you want to update to a newer upstream revision.
- Your `HEAD` (and the index) is updated to point at the merged
- commit, without creating an extra merge commit. This is
- called "Fast-forward".
-
-* Both the merged commit and `HEAD` are independent and must be
- tied together by a merge commit that has both of them as its parents.
- The rest of this section describes this "True merge" case.
+Except in a fast-forward merge (see above), the branches to be
+merged must be tied together by a merge commit that has both of them
+as its parents.
+The rest of this section describes this "True merge" case.
The chosen merge strategy merges the two commits into a single
new source tree.
--
1.6.6
^ permalink raw reply related
* [PATCH 6/6] Documentation: tweak How Merge Works
From: Jonathan Nieder @ 2010-01-11 8:43 UTC (permalink / raw)
To: git; +Cc: Thomas Rast, Petr Baudis, Junio C Hamano
In-Reply-To: <20100111082123.GA23742@progeny.tock>
Change heading to TRUE MERGE. The whole manual page is about how
merges work.
Start to explain what it means to merge two commits into a single
tree.
Do not assume the commits named on the 'git merge' command line
come from another repository. For simplicity, still assume they
are branch heads for now, though.
Do not give start any list items with `code`; a toolchain bug
makes the resulting nroff look wrong.
Recommend reset --merged for safely cancelling a failed merge.
Cc: Petr Baudis <pasky@suse.cz>
Cc: Junio C Hamano <gitster@pobox.com>
Cc: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Documentation/git-merge.txt | 56 +++++++++++++++++++-----------------------
1 files changed, 25 insertions(+), 31 deletions(-)
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index ec9c6d3..7ae0f65 100644
--- a/Documentation/git-merge.txt
+++ b/Documentation/git-merge.txt
@@ -96,62 +96,56 @@ merge commit.
This behavior can be suppressed with the `--no-ff` option.
-include::merge-strategies.txt[]
-
-
-If you tried a merge which resulted in complex conflicts and
-want to start over, you can recover with 'git-reset'.
-
-HOW MERGE WORKS
----------------
-
-A merge is always between the current `HEAD` and one or more
-commits (usually, branch head or tag).
+TRUE MERGE
+----------
Except in a fast-forward merge (see above), the branches to be
merged must be tied together by a merge commit that has both of them
as its parents.
The rest of this section describes this "True merge" case.
-The chosen merge strategy merges the two commits into a single
-new source tree.
When things merge cleanly, this is what happens:
-1. The results are updated both in the index file and in your
- working tree;
-2. Index file is written out as a tree;
+1. A version reconciling the changes from all branches to be
+ merged is written to the index file and your working tree;
+2. The index file is written out as a tree;
3. The tree gets committed; and
4. The `HEAD` pointer gets advanced.
Because of 2., we require that the original state of the index
file matches exactly the current `HEAD` commit; otherwise we
-will write out your local changes already registered in your
+would write out your local changes already registered in your
index file along with the merge result, which is not good.
Because 1. involves only those paths differing between your
-branch and the remote branch you are pulling from during the
-merge (which is typically a fraction of the whole tree), you can
-have local modifications in your working tree as long as they do
-not overlap with what the merge updates.
-
-When there are conflicts, the following happens:
+branch and the other branches (which is typically a fraction of
+the whole tree), you can have local modifications in your
+working tree as long as they do not overlap with what the merge
+updates.
-1. `HEAD` stays the same.
+When it is not obvious how to reconcile the changes, the following
+happens:
-2. Cleanly merged paths are updated both in the index file and
+1. The `HEAD` pointer stays the same.
+2. The `MERGE_HEAD` ref is set to point to the other branch head.
+3. Paths that merged cleanly are updated both in the index file and
in your working tree.
-
-3. For conflicting paths, the index file records up to three
+4. For conflicting paths, the index file records up to three
versions; stage1 stores the version from the common ancestor,
- stage2 from `HEAD`, and stage3 from the remote branch (you
+ stage2 from `HEAD`, and stage3 from `MERGE_HEAD` (you
can inspect the stages with `git ls-files -u`). The working
tree files contain the result of the "merge" program; i.e. 3-way
- merge results with familiar conflict markers `<<< === >>>`.
-
-4. No other changes are done. In particular, the local
+ merge results with familiar conflict markers `<<<` `===` `>>>`.
+5. No other changes are done. In particular, the local
modifications you had before you started merge will stay the
same and the index entries for them stay as they were,
i.e. matching `HEAD`.
+If you tried a merge which resulted in complex conflicts and
+want to start over, you can recover with `git reset --merged`.
+
+include::merge-strategies.txt[]
+
+
HOW CONFLICTS ARE PRESENTED
---------------------------
--
1.6.6
^ permalink raw reply related
* Re: [PATCH] Remove empty directories when checking out a commit with fewer submodules
From: Johannes Schindelin @ 2010-01-11 8:57 UTC (permalink / raw)
To: Peter Collingbourne; +Cc: git
In-Reply-To: <1263178794-3140-1-git-send-email-peter@pcc.me.uk>
Hi,
On Mon, 11 Jan 2010, Peter Collingbourne wrote:
> Change the unlink_entry function to use rmdir to remove submodule
> directories.
NAK. We should not even try to _unlink_ submodule subdirectories; it
would be _way_ too easy to lose data that way. Remember, submodules are a
totally different beast from regular files. They can contain valuable,
yet uncommitted data, that is not even meant to be committed.
So you say if the submodule directories are empty, it is safe? Not so.
They will never be empty: there is always .git/, and _that_ can contain
valuable information that you do not want to throw away, too. Think of
unpushed branches, for example. That would be _fatal_ if you rmdir() that
for me.
So please, no,
Dscho
^ permalink raw reply
* Re: [PATCH 2/2] Use $(git rev-parse --show-toplevel) in cd_to_toplevel()
From: Steven Drake @ 2010-01-11 9:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7viqb9w0c8.fsf@alter.siamese.dyndns.org>
On Sun, 10 Jan 2010, Junio C Hamano wrote:
> (3) Please avoid referring to external resource in the commit log message
> whenever makes sense; the log should be understandable on its own.
> Because the first paragraph of your message describes the issue the
> patch addresses very well already, you don't need "See NetBSD..." and
> URL. If you want to have them to help the reviewers, place such
> reference after the three-dash line, just like you wrote "This is a
> revision..." You would help reviewers even more if you added a
> pointer to your earlier patch after that sentence;
Wondered wether I should have put the extra info after the three-dashes or
not, now I know.
I also made sure my second email had References and In-Reply-To headers to
my first email.
> (4) Sign your patch, before the three-dash line.
Opps forgot '--signoff', I've put format.signoff=ture in .gitconfig to solve
that problem.
Perhaps a warning message from format-patch of the form:
WARNING: You have not added a "Signed-off-by:" line did you mean to!
> Please line-break immediately after &&; it makes it easier to read in
> general, and it would make "cd" stand out in this particular case, as it
> is the most important part of this particular function.
Good point, althought did you mean as a general shell script coding rule or
just in this particular case.
Thanks for the feedback. Did you want me to resend the signed and cleaned up
patches direct to you?
--
Steven
^ permalink raw reply
* Re: [PATCH] Remove empty directories when checking out a commit with fewer submodules
From: Johan Herland @ 2010-01-11 9:32 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Peter Collingbourne
In-Reply-To: <alpine.DEB.1.00.1001110954410.4985@pacific.mpi-cbg.de>
On Monday 11 January 2010, Johannes Schindelin wrote:
> Hi,
>
> On Mon, 11 Jan 2010, Peter Collingbourne wrote:
> > Change the unlink_entry function to use rmdir to remove submodule
> > directories.
>
> NAK. We should not even try to _unlink_ submodule subdirectories; it
> would be _way_ too easy to lose data that way. Remember, submodules
> are a totally different beast from regular files. They can contain
> valuable, yet uncommitted data, that is not even meant to be
> committed.
>
> So you say if the submodule directories are empty, it is safe? Not
> so. They will never be empty: there is always .git/, and _that_ can
> contain valuable information that you do not want to throw away, too.
> Think of unpushed branches, for example. That would be _fatal_ if
> you rmdir() that for me.
>
> So please, no,
I believe what Peter is referring to is the _empty_ directories (and
that includes no .git/) that are placeholders for submodules that are
deliberately not cloned/checked out. This lets you do things like:
git clone url:to/some/project
cd project
git checkout some-other-branch-with-different-submodules
git submodule update --init
Of course, once you clone/checkout a submodule, there will be contents
in that directory (including the .git/), and Git should not try to
remove it.
Have fun! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [PATCH] Remove empty directories when checking out a commit with fewer submodules
From: Johannes Schindelin @ 2010-01-11 9:45 UTC (permalink / raw)
To: Johan Herland; +Cc: git, Peter Collingbourne
In-Reply-To: <201001111032.45637.johan@herland.net>
Hi,
On Mon, 11 Jan 2010, Johan Herland wrote:
> On Monday 11 January 2010, Johannes Schindelin wrote:
> > Hi,
> >
> > On Mon, 11 Jan 2010, Peter Collingbourne wrote:
> > > Change the unlink_entry function to use rmdir to remove submodule
> > > directories.
> >
> > NAK. We should not even try to _unlink_ submodule subdirectories; it
> > would be _way_ too easy to lose data that way. Remember, submodules
> > are a totally different beast from regular files. They can contain
> > valuable, yet uncommitted data, that is not even meant to be
> > committed.
> >
> > So you say if the submodule directories are empty, it is safe? Not
> > so. They will never be empty: there is always .git/, and _that_ can
> > contain valuable information that you do not want to throw away, too.
> > Think of unpushed branches, for example. That would be _fatal_ if
> > you rmdir() that for me.
> >
> > So please, no,
>
> I believe what Peter is referring to is the _empty_ directories (and
> that includes no .git/) that are placeholders for submodules that are
> deliberately not cloned/checked out. This lets you do things like:
>
> git clone url:to/some/project
> cd project
> git checkout some-other-branch-with-different-submodules
> git submodule update --init
>
> Of course, once you clone/checkout a submodule, there will be contents
> in that directory (including the .git/), and Git should not try to
> remove it.
Yes, this might very well have been my confusion. Peter, could you please
refer to such submodules as "uninitialized" rather than "empty" in the
future? This would help simple minds like mine to understand you better.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Remove empty directories when checking out a commit with fewer submodules
From: Junio C Hamano @ 2010-01-11 9:53 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Peter Collingbourne, git
In-Reply-To: <alpine.DEB.1.00.1001110954410.4985@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> NAK. We should not even try to _unlink_ submodule subdirectories; it
> would be _way_ too easy to lose data that way. Remember, submodules are a
> totally different beast from regular files. They can contain valuable,
> yet uncommitted data, that is not even meant to be committed.
>
> So you say if the submodule directories are empty, it is safe? Not so.
> They will never be empty: there is always .git/...
NACK on NAK.
Don't worry, your data will be safe. The only case rmdir would actually
remove it is (1) you check out superproject that has submodule A, but you
choose not to "submodule init/update" it, because you don't need a
checkout of that part of the tree for your job, and then (2) you switch to
a different version of the superproject that doesn't anymore (or didn't
back then) have that submodule. In such a use case, you will have only an
empty directory for A in step (1). The unnecessary empty directory A will
be left behind, even after switching to a version that shouldn't have the
directory there in step (2), if you do not rmdir it. So the patch is a
strict bugfix (it attempted to unlink, which is a bug; it really meant
"rmdir" and not "rm -rf" which you seem to be worried about).
It is a separate matter to _enhance_ the codepath to actually either (A)
refuse to overwrite (if the version of the superproject you are switching
to in step (2) had a regular file or a directory that is part of the
superproject there, and/or (B) move it away to somewhere safe (recall the
discussion of ".git/modules/$submodule" hierarchy of the superproject?)
automatically when it will disappear. Such enhancements will help people
who _do_ "submodule init/update" the submodule in step (1) and switch to a
version of the superproject that lacks it in step (2).
^ permalink raw reply
* Re: [PATCH 2/2] Use $(git rev-parse --show-toplevel) in cd_to_toplevel()
From: Junio C Hamano @ 2010-01-11 9:58 UTC (permalink / raw)
To: Steven Drake; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LNX.2.00.1001112114140.9352@vqena.qenxr.bet.am>
Steven Drake <sdrake@xnet.co.nz> writes:
>> (4) Sign your patch, before the three-dash line.
>
> Opps forgot '--signoff', I've put format.signoff=ture in .gitconfig to solve
> that problem.
>
> Perhaps a warning message from format-patch of the form:
> WARNING: You have not added a "Signed-off-by:" line did you mean to!
1. It is usually a good idea to make it a habit of running "commit -s",
iow, record your sign-off at _commit time_, when working on a project
that uses the convention. You may start contributing by sending a
pull-request instead of patches later.
2. scripts/checkpatch.pl script in the Linux kernel project is a good tool
to check your patch before submission; you run it as:
$ perl checkpatch.pl --no-tree 0001-my-changes.patch
>> Please line-break immediately after &&; it makes it easier to read in
>> general, and it would make "cd" stand out in this particular case, as it
>> is the most important part of this particular function.
>
> Good point, althought did you mean as a general shell script coding rule or
> just in this particular case.
"In general" as a general style suggestion, and "show 'cd' at the
beginning on its own line" as a more reason to do so for this specific
case.
> Thanks for the feedback. Did you want me to resend the signed and cleaned up
> patches direct to you?
Or to the list.
I could actually have fixed them up and commit myself, instead of
responding with comments that can be seen as if I were nitpicking.
The reason why I chose not to was because I hoped you would keep
contributing to this project more in the future (I see you have already
another commit in our history, and you seem to be reasonably competent,
judging from the patch description and the way you communicate in the
discussion). And I wanted to make sure your future patches are easier to
handle for me ;-).
Thanks.
^ permalink raw reply
* Re: [PATCH 2/6] Documentation: merge: add an overview
From: Junio C Hamano @ 2010-01-11 10:09 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, Thomas Rast, Petr Baudis
In-Reply-To: <20100111083028.GB23806@progeny.tock>
Jonathan Nieder <jrnieder@gmail.com> writes:
> The reader unfamiliar with the concepts of branching and merging
> would have been completely lost. Try to help him with a diagram.
Good idea.
> DESCRIPTION
> -----------
> -This is the top-level interface to the merge machinery
> -which drives multiple merge strategy scripts.
> +Incorporates changes leading up to the named commits into the
> +current branch.
Having "since the histories diverged" somewhere in this first sentence
would clarify the concepts better, I think.
> +Assume the following history exists and the current branch is
> +"`master`":
> +
> +------------
> + A---B---C topic
> + /
> + D---E---F---G master
> +------------
> +
> +Then "`git merge topic`" will apply the changes from `A`, `B`,
> +and `C` to the work tree, and if they do not conflict with any
> +changes from `master`, will store the result in a new commit along
> +with the names of the two parent commits and a log message from the
> +user describing the changes.
- Don't spell A, B and C out; technically we don't do that, and
conceptually "changes since E until C" is exactly the same.
- Don't talk about "what it does" first, but talk about "what it is used
for" iow "why do you want to use it".
- "What it is used for" doesn't have to talk about "if it does not
conflict" yet; it is merely a lower-level detail that the main part of
the document can teach the users to help the tool achieve its goal
(i.e. "what it is used for") when it cannot do so automatically.
`git merge topic` is used to replay the change the topic has made
since it diverged from master's history (i.e. E) until its current
commit (i.e. C) on top of master, and store the result in a new
commit along with....
> +------------
> + A---B---C topic
> + / \
> + D---E---F---G---H master
> +------------
>
> The second syntax (<msg> `HEAD` <remote>) is supported for
> historical reasons. Do not use it from the command line or in
> --
> 1.6.6
^ permalink raw reply
* [PATCH] Add missing #include to support TIOCGWINSZ on Solaris
From: Nguyễn Thái Ngọc Duy @ 2010-01-11 10:41 UTC (permalink / raw)
To: git; +Cc: Nguyễn Thái Ngọc Duy
On Linux TIOCGWINSZ is defined somehwere in ioctl.h, which is already
included. On Solaris we also need to include termios.h. Without this
term_columns() in help.c will think TIOCGWINSZ is not supported and
always return 80 columns.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
Solaris noob here. Somebody should check if it affects other platforms.
git-compat-util.h | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/git-compat-util.h b/git-compat-util.h
index e5e9f39..de3a70e 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -90,6 +90,7 @@
#include <sys/poll.h>
#include <sys/socket.h>
#include <sys/ioctl.h>
+#include <termios.h>
#ifndef NO_SYS_SELECT_H
#include <sys/select.h>
#endif
--
1.6.4.1.401.gc69a7
^ permalink raw reply related
* Re: [PATCH] Threaded grep (was: Re: [PATCH] grep: do not do external grep on skip-worktree entries)
From: Fredrik Kuivinen @ 2010-01-11 10:42 UTC (permalink / raw)
To: Linus Torvalds; +Cc: peff, gitster, miles, pclouds, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.1001080956270.7821@localhost.localdomain>
[I messed up the Cc list when I sent the first mail in this thread, so
it didn't reach git@vger. This time it's fixed for real. Sorry for the
extra copy.]
On Fri, Jan 8, 2010 at 19:04, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
>
> On Fri, 8 Jan 2010, Fredrik Kuivinen wrote:
>>
>> I only have access to a couple of boxes with more than one core so
>> some more testing would be greatly appreciated. On the boxes I have
>> tested this on the added parallelism roughly cut the time to grep the
>> linux kernel in half (compared to the built-in grep). It also compares
>> favourably to the external GNU grep (these are best of three runs):
>
> On my box (in all cases best-of-five):
>
> - "NO_THREADS=1 git grep --no-ext-grep qwerty":
>
> real 0m0.945s
> user 0m0.808s
> sys 0m0.128s
>
> - "git grep --no-ext-grep qwerty":
>
> real 0m0.402s
> user 0m1.116s
> sys 0m0.216s
>
> - "git grep qwerty":
>
> real 0m0.408s
> user 0m0.176s
> sys 0m0.152s
>
> so it _just_ beat the external grep thanks to using 330% CPU time. An
> improvement, yes, but the CPU wastage is kind of sad. It really would be
> nice to see if we could get rid of the stupid per-line overhead some way.
I agree. The per-line thing seems to be fixed with Junios recent patch.
> Btw, there does seem to be some unnecessary synchronization there, because
> if I pick a pattern that has no matches at all, my best parallel number
> goes down to 0.316. But the variation in times for the parallel one is so
> big that I don't know how relevant that all is.
>
> I suspect you need more threads than CPU's due to the waiting (so that
> other threads can pick up the slack when one thread ends up waiting to
> output). Or don't wait at all, and queue it up instead.
Yes, you are right, there is some unnecessary synchronization. I am
working on a new patch which queues the output instead.
- Fredrik
^ permalink raw reply
* Re: [PATCH] grep: do not do external grep on skip-worktree entries
From: Linus Torvalds @ 2010-01-11 15:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Miles Bader, Jeff King, Nguyen Thai Ngoc Duy, git
In-Reply-To: <7vvdf9402f.fsf@alter.siamese.dyndns.org>
On Sun, 10 Jan 2010, Junio C Hamano wrote:
>
> Here is an experimental patch; first, some numbers (hot cache best of 5 runs).
Without testing it, I can already ACK it. It looks like the
ObviouslyRightThing(tm) to do. But I'll run some numbers too.
One thing that worries me - but that is independent of this patch - is
that I don't think our 'grep' function works correctly (neither the
'fixmatch()' one or the 'regexec()' one) when there are NUL characters in
a file. Maybe I shouldn't care, but it worries me a bit.
Linus
^ permalink raw reply
* [PATCH] rebase--interactive: Ignore comments and blank lines in peek_next_command
From: Michael Haggerty @ 2010-01-11 15:56 UTC (permalink / raw)
To: git; +Cc: gitster, Johannes.Schindelin, Michael Haggerty
Previously, blank lines and/or comments within a series of
squash/fixup commands would confuse "git rebase -i" into thinking that
the series was finished. It would therefore require the user to edit
the commit message for the squash/fixup commits seen so far. Then,
after continuing, it would ask the user to edit the commit message
again.
Ignore comments and blank lines within a group of squash/fixup
commands, allowing them to be processed in one go.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
This patch applies to master. It does not conflict with either
mh/rebase-fixup or ns/rebase-auto-squash.
git-rebase--interactive.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index d529328..6ed57e2 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -322,7 +322,7 @@ make_squash_message () {
}
peek_next_command () {
- sed -n "1s/ .*$//p" < "$TODO"
+ sed -n -e "/^#/d" -e "/^$/d" -e "s/ .*//p" -e "q" < "$TODO"
}
do_next () {
--
1.6.6.137.g5b1417
^ permalink raw reply related
* Re: [PATCH] grep: do not do external grep on skip-worktree entries
From: Linus Torvalds @ 2010-01-11 15:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Miles Bader, Jeff King, Nguyen Thai Ngoc Duy, git
In-Reply-To: <alpine.LFD.2.00.1001110739280.13040@localhost.localdomain>
On Mon, 11 Jan 2010, Linus Torvalds wrote:
>
> Without testing it, I can already ACK it. It looks like the
> ObviouslyRightThing(tm) to do. But I'll run some numbers too.
Ok, some good news, some meh news, and some bad news.
The good news: the trivial numbers look good. It's noticeably faster than
external grep for me when it does the 'fixmatch()' case, quite probably
because fixmatch() on at least Linux/x86-64 (which is the only case I
really care about) uses SSE to do the string ops.
So on my Nehalem:
[torvalds@nehalem linux]$ time git grep qwerty > /dev/null
real 0m0.418s
user 0m0.204s
sys 0m0.136s
[torvalds@nehalem linux]$ time git grep --no-ext-grep qwerty > /dev/null
real 0m0.309s
user 0m0.168s
sys 0m0.136s
and since that simple fixmatch case is the common one for me, I'm happy.
The meh news: this shows how grep is faster than regexec() due to being a
smarter algorithm. For the non-fixed case (I used "qwerty.*as"), the
numbers are
- built-in:
real 0m0.548s
user 0m0.384s
sys 0m0.152s
- external:
real 0m0.415s
user 0m0.176s
sys 0m0.160s
so it really is just 'strstr()' that is faster. But This is a 'meh',
because I don't really care, and the new code is still way faster than the
old one. And I'd be personally willing to just drop the external grep if
this is the worst problem.
[ I worry a bit that some libc implementations of 'strstr' may suck, but I
wouldn't lose sleep over it. ]
The bad news is that you broke multi-line greps:
git grep --no-ext-grep -2 qwerty.*as
results in:
drivers/char/keyboard.c-unsigned char kbd_sysrq_xlate[KEY_MAX + 1] =
drivers/char/keyboard.c- "\000\0331234567890-=\177\t" /* 0x00 - 0x0f */
drivers/char/keyboard.c: "qwertyuiop[]\r\000as" /* 0x10 - 0x1f */
when the _correct_ result is
drivers/char/keyboard.c-unsigned char kbd_sysrq_xlate[KEY_MAX + 1] =
drivers/char/keyboard.c- "\000\0331234567890-=\177\t" /* 0x00 - 0x0f */
drivers/char/keyboard.c: "qwertyuiop[]\r\000as" /* 0x10 - 0x1f */
drivers/char/keyboard.c- "dfghjkl;'`\000\\zxcv" /* 0x20 - 0x2f */
drivers/char/keyboard.c- "bnm,./\000*\000 \000\201\202\203\204\205" /* 0x30 - 0x3f */
ie it didn't do the "two lines after" thing.
That said, the external grep also gets this wrong (a different way),
because it gets all the extra noise due to unnecessary separation lines,
so for the external grep I actually get
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
drivers/char/keyboard.c-unsigned char kbd_sysrq_xlate[KEY_MAX + 1] =
drivers/char/keyboard.c- "\000\0331234567890-=\177\t" /* 0x00 - 0x0f */
drivers/char/keyboard.c: "qwertyuiop[]\r\000as" /* 0x10 - 0x1f */
drivers/char/keyboard.c- "dfghjkl;'`\000\\zxcv" /* 0x20 - 0x2f */
drivers/char/keyboard.c- "bnm,./\000*\000 \000\201\202\203\204\205" /* 0x30 - 0x3f */
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
but that's a long-standing problem, and is more "ugly" than "wrong grep
results".
Linus
^ permalink raw reply
* [PATCH 1/4] git-svn: fix the trivial case of 'src and dst not in the same repo' during branch/tag
From: Igor Mironov @ 2010-01-11 16:20 UTC (permalink / raw)
To: git; +Cc: Eric Wong
This fixes the following issue:
$ git svn branch -t --username=svnuser --commit-url=https://myproj.domain.com/svn mytag
Copying http://myproj.domain.com/svn/trunk at r26 to https://myproj.domain.com/svn/tags/mytag...
Trying to use an unsupported feature: Source and dest appear not to be in the same repository (src: 'http://myproj.domain.com/svn/trunk'; dst: 'https://myproj.domain.com/svn/tags/mytag') at /usr/lib/git-core/git-svn line 623
Signed-off-by: Igor Mironov <igor.a.mironov@gmail.com>
---
git-svn.perl | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 650c9e5..3f7ccc1 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -710,6 +710,10 @@ sub cmd_branch {
my ($lft, $rgt) = @{ $glob->{path} }{qw/left right/};
my $dst = join '/', $remote->{url}, $lft, $branch_name, ($rgt || ());
+ if ($dst=~"^https:" && $src=~"^http:") {
+ $src=~s/^http:/https:/;
+ }
+
my $ctx = SVN::Client->new(
auth => Git::SVN::Ra::_auth_providers(),
log_msg => sub {
--
1.6.6.106.ge2de8
^ permalink raw reply related
* [PATCH 2/4] git-svn: use commiturl in preference to url when constructing dst for branch/tag
From: Igor Mironov @ 2010-01-11 16:21 UTC (permalink / raw)
To: git; +Cc: Eric Wong
When constructing a destination URL, use the property 'commiturl' if it is specified in the configuration file; otherwise take 'url' as usual. This accommodates the scenario where a user only wants to involve the writable repository in operations performing a commit and defaults everything else to a read-only URL.
Signed-off-by: Igor Mironov <igor.a.mironov@gmail.com>
---
git-svn.perl | 12 +++++++++++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 3f7ccc1..3bdd8d3 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -708,7 +708,17 @@ sub cmd_branch {
}
}
my ($lft, $rgt) = @{ $glob->{path} }{qw/left right/};
- my $dst = join '/', $remote->{url}, $lft, $branch_name, ($rgt || ());
+ my $url;
+ if (defined $_commit_url) {
+ $url = $_commit_url;
+ } else {
+ $url = eval { command_oneline('config', '--get',
+ "svn-remote.$gs->{repo_id}.commiturl") };
+ if (!$url) {
+ $url = $remote->{url};
+ }
+ }
+ my $dst = join '/', $url, $lft, $branch_name, ($rgt || ());
if ($dst=~"^https:" && $src=~"^http:") {
$src=~s/^http:/https:/;
--
1.6.6.106.ge2de8
^ permalink raw reply related
* [PATCH 3/4] git-svn: support options --username and --commit-url in branch/tag
From: Igor Mironov @ 2010-01-11 16:21 UTC (permalink / raw)
To: git; +Cc: Eric Wong
Add ability to specify on the command line the username to perform the operation as and the writable URL of the repository to perform it on.
Signed-off-by: Igor Mironov <igor.a.mironov@gmail.com>
---
git-svn.perl | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 3bdd8d3..0da6c67 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -155,12 +155,16 @@ my %cmd = (
{ 'message|m=s' => \$_message,
'destination|d=s' => \$_branch_dest,
'dry-run|n' => \$_dry_run,
- 'tag|t' => \$_tag } ],
+ 'tag|t' => \$_tag,
+ 'username=s' => \$Git::SVN::Prompt::_username,
+ 'commit-url=s' => \$_commit_url } ],
tag => [ sub { $_tag = 1; cmd_branch(@_) },
'Create a tag in the SVN repository',
{ 'message|m=s' => \$_message,
'destination|d=s' => \$_branch_dest,
- 'dry-run|n' => \$_dry_run } ],
+ 'dry-run|n' => \$_dry_run,
+ 'username=s' => \$Git::SVN::Prompt::_username,
+ 'commit-url=s' => \$_commit_url } ],
'set-tree' => [ \&cmd_set_tree,
"Set an SVN repository to a git tree-ish",
{ 'stdin' => \$_stdin, %cmt_opts, %fc_opts, } ],
--
1.6.6.106.ge2de8
^ permalink raw reply related
* Re: [PATCH] grep: do not do external grep on skip-worktree entries
From: Junio C Hamano @ 2010-01-11 16:22 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Miles Bader, Jeff King, Nguyen Thai Ngoc Duy, git
In-Reply-To: <alpine.LFD.2.00.1001110748560.13040@localhost.localdomain>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> The bad news is that you broke multi-line greps:
>
> git grep --no-ext-grep -2 qwerty.*as
>
> results in:
>
> drivers/char/keyboard.c-unsigned char kbd_sysrq_xlate[KEY_MAX + 1] =
> drivers/char/keyboard.c- "\000\0331234567890-=\177\t" /* 0x00 - 0x0f */
> drivers/char/keyboard.c: "qwertyuiop[]\r\000as" /* 0x10 - 0x1f */
Meh. I checked pre-context codepath before sending the patch and was very
satisfied that René did the right thing in 49de321 (grep: handle pre
context lines on demand, 2009-07-02), but somehow forgot about the post
context codepath.
An ObviouslyRightThing fix is this two-liner. We shouldn't lookahead if
we want to do something more than just skipping when we see an unmatch for
the line we are currently looking at.
grep.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/grep.c b/grep.c
index 940e200..ac0ce0b 100644
--- a/grep.c
+++ b/grep.c
@@ -719,6 +719,8 @@ static int grep_buffer_1(struct grep_opt *opt, const char *name,
int hit;
if (try_lookahead
+ && !(last_hit
+ && lno <= last_hit + opt->post_context)
&& look_ahead(opt, &left, &lno, &bol))
break;
eol = end_of_line(bol, &left);
^ permalink raw reply related
* Re: How to check new commit availability without full fetch?
From: Leo Razoumov @ 2010-01-11 16:22 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.1001102055070.10143@xanadu.home>
On 2010-01-10, Nicolas Pitre <nico@fluxnic.net> wrote:
>
> You still don't answer my question though. Again, _why_ do you need to
> know about remote commit availability without fetching them?
>
I use git to track almost all my data (code and otherwise) and spread
it between several computers. I end up with several local repos having
the same local branches. It happens once in a while that I fetch into
a given remote/foo from several local foo branches from different
machines and the operation fails. It happens because the commits have
not been yet consistently distributed among the repos. To do the
forensics and figure out who should update whom first I need a quick
and non-destructive way to fetch dry-run.
--Leo--
^ 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