* Re: [msysGit] [PATCH v5 0/8] imap-send: Windows support
From: Johannes Schindelin @ 2009-10-22 17:42 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: git, msysgit, Erik Faye-Lund
In-Reply-To: <1256144691-2908-1-git-send-email-kusmabite@gmail.com>
Hi,
On Wed, 21 Oct 2009, Erik Faye-Lund wrote:
> Here's the 5th iteration of my patches for Windows-compatibility in
> imap-send.
>
> - Patch 1-3 is about getting rid of or rewriting
> code with portability issues.
> - Patch 4 fixes a compilation error on Windows
> - Patch 5 enables compilation of imap-send
> - Patch 6-7 enables SSL-suport for mingw
> - Patch 8 enables imap-send and SSL for msvc
>
> The only change compared to the previous iteration
> is that patch 7 and 8 enables NEEDS_CRYPTO_WITH_SSL.
>
> Please note that I haven't tested Patch 8 with
> NEEDS_CRYPTO_WITH_SSL under MSVC, as I don't have a
> working setup with both msysgit and MSVC installed.
>
> I'd love it if someone with such a working setup
> could verify that it works, preferrably also with
> BLK_SHA1 enabled.
If there are no objections, I will apply them tomorrow.
Ciao,
Dscho
^ permalink raw reply
* remove broken refloc
From: Tobias Richter @ 2009-10-22 16:57 UTC (permalink / raw)
To: git
Hi,
>From using git-svn I've imported a (git-wise) broken reference. This isn't
a huge problem, as I don't need that ref anyway. But 'git gc' no longer
works and that results in frequent errors when updating:
$ git gc
error: cannot lock ref 'refs/remotes/release_7.5.'
error: failed to run reflog
As far as I understand I could expire that ref, but that fails as well:
$ git reflog expire --expire=0 --all
error: cannot lock ref 'refs/remotes/release_7.5.'
Is there a way to forcefully remove that broken ref?
Then I may be able to stop git-svn from re-importing that using the config,
I hope.
Thanks,
Tobias
^ permalink raw reply
* Re: ks/precompute-completion (was Re: What's cooking in git.git (Oct 2009, #04; Wed, 21))
From: Sverre Rabbelier @ 2009-10-22 17:11 UTC (permalink / raw)
To: Stephen Boyd; +Cc: Junio C Hamano, git, Kirill Smelkov, Shawn O. Pearce
In-Reply-To: <4AE0190E.8020803@gmail.com>
Heya,
On Thu, Oct 22, 2009 at 03:34, Stephen Boyd <bebarino@gmail.com> wrote:
> Junio C Hamano wrote:
>> * ks/precompute-completion (2009-10-05) 1 commit.
>> (merged to 'next' on 2009-10-14 at adf722a)
>> + Speedup bash completion loading
>>
>> Are people happy with this?
>
> No. I now have rebase.sh, am.sh, etc. in my completion
I would really like it if running 'make && make install' in git.git
would also build the completion script, I don't want to have to
remember to run 'cd contrib/completion && make' every time we get new
completion options :P.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: git bisect Vs branch
From: Santi Béjar @ 2009-10-22 16:50 UTC (permalink / raw)
To: Grégory Romé; +Cc: git
In-Reply-To: <4AE07EEB.2010101@maxim-ic.com>
On Thu, Oct 22, 2009 at 5:48 PM, Grégory Romé <gregory.rome@maxim-ic.com> wrote:
> Considering the following story what is the method to find the regression
> with bisect?
>
> I cloned a git repository (origin) which derives from another one
> (first-origin). A merge is done from first-origin to origin at each stable
> release (identified by a tag).
>
> first-origin/master *---A---------B-----------------------C-
> \ \ \
> origin/master ----------B'----------U-----------C'-
> \ \ \ master
> ------------U'----------C''-
>
> Now, after that I merged C' I fixed the conflicts and compiled without error
> but I have a regression. It could come from any commit between B and C or U
> and C', and I need to modify my code to correct the issue.
>
> I would like to find the commit which introduce this regression by using git
> bisect but as the history is not linear it is not so easy (1). It though to
> create a linear history but I have no idea how to proceed...
You just have to proceed as normal, but you may test more commits than
with a linear history.
The only problem is iff the culprit is a merge commit (as in the
user-manual chapter you linked). And the "problem" is to know where
exactly in the (merge) commit is the bug, but not the procedure.
HTH,
Santi
^ permalink raw reply
* Re: [PATCH] describe: when failing, tell the user about options that work
From: Alex Riesen @ 2009-10-22 16:40 UTC (permalink / raw)
To: Thomas Rast; +Cc: Eugene Sajine, git
In-Reply-To: <f1e86b9095d63c6541d0a8df6a1cf8eadfe247bb.1256226187.git.trast@student.ethz.ch>
On Thu, Oct 22, 2009 at 17:44, Thomas Rast <trast@student.ethz.ch> wrote:
> @@ -259,7 +260,14 @@ static void describe(const char *arg, int last_one)
> printf("%s\n", find_unique_abbrev(sha1, abbrev));
> return;
> }
> - die("cannot describe '%s'", sha1_to_hex(sha1));
> + if (unannotated_cnt)
> + die("cannot describe '%s'"
> + " with only\nannotated tags. Try --tags.",
> + sha1_to_hex(sha1));
> + else
> + die("cannot describe '%s'"
> + " with tags\nTry --always, or create some tags.",
> + sha1_to_hex(sha1));
These are quite verbose. Could they be conditional on something like
advice.describeHints?
^ permalink raw reply
* git bisect Vs branch
From: Grégory Romé @ 2009-10-22 15:48 UTC (permalink / raw)
To: git
Considering the following story what is the method to find the
regression with bisect?
I cloned a git repository (origin) which derives from another one
(first-origin). A merge is done from first-origin to origin at each
stable release (identified by a tag).
first-origin/master *---A---------B-----------------------C-
\ \ \
origin/master ----------B'----------U-----------C'-
\ \ \
master ------------U'----------C''-
Now, after that I merged C' I fixed the conflicts and compiled without
error but I have a regression. It could come from any commit between B
and C or U and C', and I need to modify my code to correct the issue.
I would like to find the commit which introduce this regression by using
git bisect but as the history is not linear it is not so easy (1). It
though to create a linear history but I have no idea how to proceed...
Thanks,
Grégory
(1)
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#bisect-merges
^ permalink raw reply
* Proper attribution for modified files
From: alexandrul @ 2009-10-22 16:23 UTC (permalink / raw)
To: Git Mailing List
Hi,
I have started from git-instaweb script and modified it
in order to support my custom setup. The original script
starts with:
#!/bin/sh
#
# Copyright (c) 2006 Eric Wong
#
What would be the proper attribution to place in my modified script
in order to make it available for public download?
Have a nice day,
A.
^ permalink raw reply
* [PATCH] describe: when failing, tell the user about options that work
From: Thomas Rast @ 2009-10-22 15:44 UTC (permalink / raw)
To: Eugene Sajine; +Cc: git
In-Reply-To: <76c5b8580910220810n389d065di349339ab38909ef7@mail.gmail.com>
Users seem to call git-describe without reading the manpage, and then
wonder why it doesn't work with unannotated tags by default.
Make a minimal effort towards seeing if there would have been
unannotated tags, and tell the user. Specifically, we say that --tags
could work if we found any unannotated tags. If not, we say that
--always would have given results.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Eugene Sajine wrote:
> [git-describe fails if you don't have annotated tags]
>
> Thanks! It is working ok.
> Although it is probably not the best error handling.
> I believe git should fail with some meaningful message in this case...
We already had most of the information available, so hey, why not.
builtin-describe.c | 16 ++++++++++++----
1 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/builtin-describe.c b/builtin-describe.c
index 2dcfd3d..1ffa0d8 100644
--- a/builtin-describe.c
+++ b/builtin-describe.c
@@ -96,8 +96,6 @@ static int get_name(const char *path, const unsigned char *sha1, int flag, void
if (!all) {
if (!prio)
return 0;
- if (!tags && prio < 2)
- return 0;
}
add_to_known_names(all ? path + 5 : path + 10, commit, prio, sha1);
return 0;
@@ -184,6 +182,7 @@ static void describe(const char *arg, int last_one)
struct possible_tag all_matches[MAX_TAGS];
unsigned int match_cnt = 0, annotated_cnt = 0, cur_match;
unsigned long seen_commits = 0;
+ unsigned int unannotated_cnt = 0;
if (get_sha1(arg, sha1))
die("Not a valid object name %s", arg);
@@ -217,7 +216,9 @@ static void describe(const char *arg, int last_one)
seen_commits++;
n = c->util;
if (n) {
- if (match_cnt < max_candidates) {
+ if (!tags && !all && n->prio < 2) {
+ unannotated_cnt++;
+ } else if (match_cnt < max_candidates) {
struct possible_tag *t = &all_matches[match_cnt++];
t->name = n;
t->depth = seen_commits - 1;
@@ -259,7 +260,14 @@ static void describe(const char *arg, int last_one)
printf("%s\n", find_unique_abbrev(sha1, abbrev));
return;
}
- die("cannot describe '%s'", sha1_to_hex(sha1));
+ if (unannotated_cnt)
+ die("cannot describe '%s'"
+ " with only\nannotated tags. Try --tags.",
+ sha1_to_hex(sha1));
+ else
+ die("cannot describe '%s'"
+ " with tags\nTry --always, or create some tags.",
+ sha1_to_hex(sha1));
}
qsort(all_matches, match_cnt, sizeof(all_matches[0]), compare_pt);
--
1.6.5.1.70.g1383ae
^ permalink raw reply related
* Re: What's cooking in git.git (Oct 2009, #03; Mon, 19)
From: Johannes Schindelin @ 2009-10-22 15:33 UTC (permalink / raw)
To: Johan Herland; +Cc: Junio C Hamano, git
In-Reply-To: <200910191125.19997.johan@herland.net>
Hi Johan,
On Mon, 19 Oct 2009, Johan Herland wrote:
> On Monday 19 October 2009, Junio C Hamano wrote:
> > * jh/notes (2009-10-09) 22 commits.
> > - fast-import: Proper notes tree manipulation using the notes API
> > - Refactor notes concatenation into a flexible interface for combining notes
> > - Notes API: Allow multiple concurrent notes trees with new struct notes_tree
> > - Notes API: for_each_note(): Traverse the entire notes tree with a callback
> > - Notes API: get_note(): Return the note annotating the given object
> > - Notes API: add_note(): Add note objects to the internal notes tree structure
> > - Notes API: init_notes(): Initialize the notes tree from the given notes ref
> > - Notes API: get_commit_notes() -> format_note() + remove the commit restriction
> > - Add selftests verifying concatenation of multiple notes for the same commit
> > - Refactor notes code to concatenate multiple notes annotating the same object
> > - Add selftests verifying that we can parse notes trees with various fanouts
> > - Teach the notes lookup code to parse notes trees with various fanout schemes
> > - Teach notes code to free its internal data structures on request
> > - Add '%N'-format for pretty-printing commit notes
> > - Add flags to get_commit_notes() to control the format of the note string
> > - t3302-notes-index-expensive: Speed up create_repo()
> > - fast-import: Add support for importing commit notes
> > - Teach "-m <msg>" and "-F <file>" to "git notes edit"
> > - Add an expensive test for git-notes
> > - Speed up git notes lookup
> > - Add a script to edit/inspect notes
> > - Introduce commit notes
>
> > Is this good for 'next' now?
>
> Not all of it.
>
> I suspect the first 14 patches are stable and 'next'-worthy, although
> it would be nice if Dscho had the time to ACK them.
As you probably realized, I have little time for Git these days (mainly
due to work), so please do not wait for me.
Ciao,
Dscho
^ permalink raw reply
* Re: What's cooking in git.git (Oct 2009, #04; Wed, 21)
From: skillzero @ 2009-10-22 15:31 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Jakub Narebski, Junio C Hamano, Git Mailing List
In-Reply-To: <fcaeb9bf0910220415v69c22ed9o4ab85b8858fbf187@mail.gmail.com>
On Thu, Oct 22, 2009 at 4:15 AM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> On Thu, Oct 22, 2009 at 3:46 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>> Junio C Hamano <gitster@pobox.com> writes:
>>> * nd/sparse (2009-08-20) 19 commits.
>>> - sparse checkout: inhibit empty worktree
>>> - Add tests for sparse checkout
>>> - read-tree: add --no-sparse-checkout to disable sparse checkout support
>>> - unpack-trees(): ignore worktree check outside checkout area
>>> - unpack_trees(): apply $GIT_DIR/info/sparse-checkout to the final index
>>> - unpack-trees(): "enable" sparse checkout and load $GIT_DIR/info/sparse-checkout
>>> - unpack-trees.c: generalize verify_* functions
>>> - unpack-trees(): add CE_WT_REMOVE to remove on worktree alone
>>> - Introduce "sparse checkout"
>>> - dir.c: export excluded_1() and add_excludes_from_file_1()
>>> - excluded_1(): support exclude files in index
>>> - unpack-trees(): carry skip-worktree bit over in merged_entry()
>>> - Read .gitignore from index if it is skip-worktree
>>> - Avoid writing to buffer in add_excludes_from_file_1()
>>> - Teach Git to respect skip-worktree bit (writing part)
>>> - Teach Git to respect skip-worktree bit (reading part)
>>> - Introduce "skip-worktree" bit in index, teach Git to get/set this bit
>>> - Add test-index-version
>>> - update-index: refactor mark_valid() in preparation for new options
>>
>> Hmmm... what is happening with that series?
>
> Junio concerned about CE_MATCH_IGNORE_VALID being used by both
> assume-unchanged and skip-worktree bits, which I did not resolve yet.
> I should really get back to the series when I have time.
Just an FYI, but I've been using this series for a while. I'm actually
relying on sparse support in our internal build system (via my private
build with this series) so I hope it doesn't go away :) I haven't
really noticed any problems (I thought the index state got out of sync
once, but I couldn't reproduce the problem later). Here's some
feedback though:
1. I found it confusing to have to append '/' to directories in the
sparse pattern list for directories. I always forget it requires them.
It would be nice to support the same rules as .gitignore in terms of
'/'.
2. It would be nice to have built-in support for a sparse modules file
and switching between them. Maybe .gitmodules could support "module"
or "sparsemodule" sections to list the patterns for that sparse
module. I've written a simple script to do this and it's what I use.
It just parses the INI-style file:
[module "MyProject"]
App1
Shared1
!FolderIDontWant
Then I have a "module" script to read that file for a specified module
and switch to it:
git module switch MyProject
The script just parses `git show HEAD:.gitmodules` (so it works
without a working directory) and switches sparse modules by enabling
sparse, writing info/sparse-checkout, and doing a checkout:
sub cmd_switch
{
# Enable sparse.
my $currentCmd = "git config core.sparsecheckout true";
system( $currentCmd ) == 0 or die( "error: $currentCmd\n" );
# Write sparse patterns.
my $gitDir = `git rev-parse --git-dir`;
chop( $gitDir );
my $sparsePath = $gitDir . "/info/sparse-checkout";
if( $? != 0 ) { die( "error: read git directory failed $?\n" ); }
open( FILE, ">", $sparsePath ) or die( "error: can't open '$sparsePath'\n" );
foreach( @{$gModules->{$gModuleName}} )
{
print( FILE "$_\n" );
}
close( FILE );
# Checkout using new sparse patterns.
system( "git checkout" ) == 0 or die( "error: switch module failed\n" );
}
That said, the current level of sparse support provided by this series
is good enough for me because I can build my own scripts like this on
top of it to automate things.
^ permalink raw reply
* Re: git describe is failing
From: Eugene Sajine @ 2009-10-22 15:10 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <200910221702.39452.trast@student.ethz.ch>
> man git-describe:
>
> DESCRIPTION
> The command finds the most recent tag that is reachable from a
> commit.
> [...]
> By default (without --all or --tags) git describe only shows
> annotated tags. For more information about creating annotated
> tags see the -a and -s options to git-tag(1).
>
> If there is no such tag, it refuses to work. Annotate your tags, or
> try --always.
>
> --
> Thomas Rast
> trast@{inf,student}.ethz.ch
>
Thanks! It is working ok.
Although it is probably not the best error handling.
I believe git should fail with some meaningful message in this case...
Thanks,
Eugene
^ permalink raw reply
* Re: git describe is failing
From: Thomas Rast @ 2009-10-22 15:02 UTC (permalink / raw)
To: Eugene Sajine; +Cc: git
In-Reply-To: <76c5b8580910220747w709d2b41s4f7b121e421e843c@mail.gmail.com>
Eugene Sajine wrote:
> $ git describe
>
> gives:
>
> fatal: cannot describe 'SHA-1'
man git-describe:
DESCRIPTION
The command finds the most recent tag that is reachable from a
commit.
[...]
By default (without --all or --tags) git describe only shows
annotated tags. For more information about creating annotated
tags see the -a and -s options to git-tag(1).
If there is no such tag, it refuses to work. Annotate your tags, or
try --always.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: git describe is failing
From: Mikael Magnusson @ 2009-10-22 14:59 UTC (permalink / raw)
To: Eugene Sajine; +Cc: git
In-Reply-To: <76c5b8580910220747w709d2b41s4f7b121e421e843c@mail.gmail.com>
2009/10/22 Eugene Sajine <euguess@gmail.com>:
> Hi,
>
> I have a test repo which I'm playing with. It has about 15 commits and
> one branch only (master) and couple of tags. Somehow it got to a state
> when
>
> $ git describe
>
> gives:
>
> fatal: cannot describe 'SHA-1'
>
> The command is working ok with my other repo. It doesn't seem that the
> test repo is corrupted. I can commit, push and pull, see the history
> with gitk... How can I check or repair it?
>
> Thanks,
> Eugene
Your tags are probably not annotated (lightweight tags), use git
describe --tags.
--
Mikael Magnusson
^ permalink raw reply
* git describe is failing
From: Eugene Sajine @ 2009-10-22 14:47 UTC (permalink / raw)
To: git; +Cc: Eugene Sajine
Hi,
I have a test repo which I'm playing with. It has about 15 commits and
one branch only (master) and couple of tags. Somehow it got to a state
when
$ git describe
gives:
fatal: cannot describe 'SHA-1'
The command is working ok with my other repo. It doesn't seem that the
test repo is corrupted. I can commit, push and pull, see the history
with gitk... How can I check or repair it?
Thanks,
Eugene
^ permalink raw reply
* Re: [RFC PATCH v3 00/17] Return of smart HTTP
From: Daniel Barkalow @ 2009-10-22 14:46 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Junio C Hamano, Shawn O. Pearce, Johan Herland, git
In-Reply-To: <20091022192149.6117@nanako3.lavabit.com>
On Thu, 22 Oct 2009, Nanako Shiraishi wrote:
> Quoting "Shawn O. Pearce" <spearce@spearce.org>
>
> > Actually, after some further research, the bug is not Johan's but is
> > actually Daniel's. Johan, I apologize for claiming it was your bug.
> > ...
> > Long story short, transport_close() is what is supposed to perform
> > the work that disconnect_helper does, as its the final thing right
> > before we free the struct transport block. Free'ing the data block
> > inside of the fetch or push functions is wrong.
> >
> > Its fine to close the helper and restart it within the single
> > lifespan of a struct transport, but dammit, don't free the
> > struct helper_data until transport_close().
>
> Ping? Are there any progress on this issue?
Ah, right. Shawn's analysis is correct, and I should have a different
function to just finish the helper, but leave the rest of the data alone.
(when I wrote it originally, I didn't have anything other than the
connection in there, so it was right to clear it, but now there's a real
helper_data and it needs to do the right things).
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [PATCH] Documentation/git-pull.txt: Add subtitles above included option files
From: Jari Aalto @ 2009-10-22 14:14 UTC (permalink / raw)
To: git
In-Reply-To: <20091022192152.6117@nanako3.lavabit.com>
Signed-off-by: Jari Aalto <jari.aalto@cante.net>
---
Documentation/git-pull.txt | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Quoting Junio C Hamano <gitster@pobox.com>
>
>> Ah, in your defense ;-) I think you looked only at git-fetch.txt without
>> checking where else this file is included. Then the patch certainly is
>> understandable. It would probably make git-fetch.{1,html} easier to scan,
>> while making things not worse for git-pull.{1,html}
>
> Can't we introduce subsections in the OPTIONS section to
> group them together, like this (sorry, not a patch)?
>
> OPTIONS
> -------
>
> Options related to merging <---- added
> ~~~~~~~~~~~~~~~~~~~~~~~~~~ <---- added
> include::merge-options.txt[]
diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
index 7578623..51534dd 100644
--- a/Documentation/git-pull.txt
+++ b/Documentation/git-pull.txt
@@ -26,6 +26,10 @@ Also note that options meant for 'git-pull' itself and underlying
OPTIONS
-------
+
+Options related to merging
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
include::merge-options.txt[]
:git-pull: 1
@@ -47,6 +51,9 @@ unless you have read linkgit:git-rebase[1] carefully.
--no-rebase::
Override earlier --rebase.
+Options related to fetching
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
include::fetch-options.txt[]
include::pull-fetch-param.txt[]
--
1.6.4.3
^ permalink raw reply related
* Re: [PATCH] Documentation/fetch-options.txt: order options alphabetically
From: Jeff King @ 2009-10-22 11:25 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Junio C Hamano, Jari Aalto, git
In-Reply-To: <20091022192152.6117@nanako3.lavabit.com>
On Thu, Oct 22, 2009 at 07:21:52PM +0900, Nanako Shiraishi wrote:
> > Ah, in your defense ;-) I think you looked only at git-fetch.txt without
> > checking where else this file is included. Then the patch certainly is
> > understandable. It would probably make git-fetch.{1,html} easier to scan,
> > while making things not worse for git-pull.{1,html}
>
> Can't we introduce subsections in the OPTIONS section to
> group them together, like this (sorry, not a patch)?
Yes, that was my first thought when reading this thread, too (sorry, no
patch here, either. I need to sleep and then get on a plane).
-Peff
^ permalink raw reply
* Re: What's cooking in git.git (Oct 2009, #04; Wed, 21)
From: Nguyen Thai Ngoc Duy @ 2009-10-22 11:15 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <m3ljj3es02.fsf@localhost.localdomain>
On Thu, Oct 22, 2009 at 3:46 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>> * nd/sparse (2009-08-20) 19 commits.
>> - sparse checkout: inhibit empty worktree
>> - Add tests for sparse checkout
>> - read-tree: add --no-sparse-checkout to disable sparse checkout support
>> - unpack-trees(): ignore worktree check outside checkout area
>> - unpack_trees(): apply $GIT_DIR/info/sparse-checkout to the final index
>> - unpack-trees(): "enable" sparse checkout and load $GIT_DIR/info/sparse-checkout
>> - unpack-trees.c: generalize verify_* functions
>> - unpack-trees(): add CE_WT_REMOVE to remove on worktree alone
>> - Introduce "sparse checkout"
>> - dir.c: export excluded_1() and add_excludes_from_file_1()
>> - excluded_1(): support exclude files in index
>> - unpack-trees(): carry skip-worktree bit over in merged_entry()
>> - Read .gitignore from index if it is skip-worktree
>> - Avoid writing to buffer in add_excludes_from_file_1()
>> - Teach Git to respect skip-worktree bit (writing part)
>> - Teach Git to respect skip-worktree bit (reading part)
>> - Introduce "skip-worktree" bit in index, teach Git to get/set this bit
>> - Add test-index-version
>> - update-index: refactor mark_valid() in preparation for new options
>
> Hmmm... what is happening with that series?
Junio concerned about CE_MATCH_IGNORE_VALID being used by both
assume-unchanged and skip-worktree bits, which I did not resolve yet.
I should really get back to the series when I have time.
--
Duy
^ permalink raw reply
* Re: [PATCH] Documentation/fetch-options.txt: order options alphabetically
From: Nanako Shiraishi @ 2009-10-22 10:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jari Aalto, git
In-Reply-To: <7vhbts3285.fsf@alter.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com>
> Ah, in your defense ;-) I think you looked only at git-fetch.txt without
> checking where else this file is included. Then the patch certainly is
> understandable. It would probably make git-fetch.{1,html} easier to scan,
> while making things not worse for git-pull.{1,html}
Can't we introduce subsections in the OPTIONS section to
group them together, like this (sorry, not a patch)?
OPTIONS
-------
Options related to merging <---- added
~~~~~~~~~~~~~~~~~~~~~~~~~~ <---- added
include::merge-options.txt[]
:git-pull: 1
--rebase::
Instead of a merge, perform a rebase after fetching. If
there is a remote ref for the upstream branch, and this branch
was rebased since last fetched, the rebase uses that information
to avoid rebasing non-local changes. To make this the default
for branch `<name>`, set configuration `branch.<name>.rebase`
to `true`.
+
[NOTE]
This is a potentially _dangerous_ mode of operation.
It rewrites history, which does not bode well when you
published that history already. Do *not* use this option
unless you have read linkgit:git-rebase[1] carefully.
--no-rebase::
Override earlier --rebase.
Options related to fetching <---- added
~~~~~~~~~~~~~~~~~~~~~~~~~~~ <---- added
include::fetch-options.txt[]
include::pull-fetch-param.txt[]
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [RFC PATCH v3 00/17] Return of smart HTTP
From: Nanako Shiraishi @ 2009-10-22 10:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, Daniel Barkalow, Johan Herland, git
In-Reply-To: <20091015204543.GP10505@spearce.org>
Quoting "Shawn O. Pearce" <spearce@spearce.org>
> Actually, after some further research, the bug is not Johan's but is
> actually Daniel's. Johan, I apologize for claiming it was your bug.
> ...
> Long story short, transport_close() is what is supposed to perform
> the work that disconnect_helper does, as its the final thing right
> before we free the struct transport block. Free'ing the data block
> inside of the fetch or push functions is wrong.
>
> Its fine to close the helper and restart it within the single
> lifespan of a struct transport, but dammit, don't free the
> struct helper_data until transport_close().
Ping? Are there any progress on this issue?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [RFC/PATCH] git-merge: forbid fast-forward and up-to-date when --no-commit is given
From: Nanako Shiraishi @ 2009-10-22 10:21 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Clemens Buchacher, Bjorn Steinbrink, Daniel Barkalow,
Thomas Rast
In-Reply-To: <7vpr8g1l2a.fsf_-_@alter.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com>
> Traditionally "git merge --no-commit" meant just that: do not create a new
> commit even when a merge succeeds. But this leads to confusion when the
> merged commit is a descendant of the current commit, in which case we
> succeed the merge by fast-forwarding and without creating a new commit.
> Also when the merged commit is already a part of the history, we succeeded
> without doing anything.
>
> Error out when --no-commit is given but the merge would result in a
> fast-forward or an up-to-date.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
>
> * This is the first alternative. I think it makes more sense than the
> other one, but I am unsure, as I obviously do not get confused when
> --no-commit becomes no-op due to a fast-forward nor an up-to-date and
> am rather happy with the current behaviour.
I think this is good (but I am saying this only from your
description without understanding the updated code), but
the change breaks --squash to merge a branch, doesn't it?
% git checkout feature # from your master branch
% work; git commit; work; git commit
% git checkout master # go back to your master branch
% git merge --squash feature
This is a useful way to clean up changes that were built
in small steps that turned out to be worth only a commit.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [RFC] pull/fetch rename
From: Thomas Rast @ 2009-10-22 9:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Björn Steinbrink, Daniel Barkalow, git
In-Reply-To: <7vk4ypb71j.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Björn Steinbrink <B.Steinbrink@gmx.de> writes:
>
> > So that's ten days of #git. I left out a bunch of duplications (most
> > were "pull == fetch", "pull == update" and "pull to update
> > non-checked-out branch").
>
> Interesting; this shows that people who do not understand what "pull" does
> expect different behaviour from "pull", use the word "pull" to express
> what they want to happen, expect other people interpret the word to mean
> the way they think it does. At the same time, judging from different
> behaviour expected by these people, push/pull asymmetry does not seem to
> have much to do with the confusion.
This of course is where our conclusions differ. I haven't counted
them, but Björn (thanks again for the excellent survey) points out
that most duplicates are confusion with fetch, (imagined) update or
"update to not checked out branch".
Pull is none of these, but if it was (current) fetch, at least the
first group of people would have had the right idea of what it does.
> I am actually even Ok, at least in the long run (like in 3 years), if we
> were to deprecate the refspecs with colon given on the command line to
> "pull" and "fetch" altogether [*1*].
As an aside, there are actually some use-cases, e.g., to grab the
git-svn refs from a freshly cloned repository you would run:
git fetch origin refs/remotes/*:refs/remotes/*
(and then 'git svn init' etc.) I've also had some weird requests on
IRC that could be solved by clever (and of course dangerous) use of
'git fetch . glob:otherglob'.
Hiding that power behind an option could be a good idea though.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* [PATCH] Documentation/merge-options.txt: order options in alphabetical groups
From: Jari Aalto @ 2009-10-22 9:24 UTC (permalink / raw)
To: git
Signed-off-by: Jari Aalto <jari.aalto@cante.net>
---
Documentation/merge-options.txt | 79 ++++++++++++++++++++-------------------
1 files changed, 41 insertions(+), 38 deletions(-)
The --option and --no-options have been grouped together as in:
--option
--no-option
The alphabetical order is according to the --option.
diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt
index adadf8e..f1fdb65 100644
--- a/Documentation/merge-options.txt
+++ b/Documentation/merge-options.txt
@@ -1,43 +1,42 @@
--q::
---quiet::
- Operate quietly.
-
--v::
---verbose::
- Be verbose.
+--commit::
+--no-commit::
+ Perform the merge and commit the result. This option can
+ be used to override --no-commit.
---stat::
- Show a diffstat at the end of the merge. The diffstat is also
- controlled by the configuration option merge.stat.
+ With --no-commit perform the merge but pretend the merge
+ failed and do not autocommit, to give the user a chance to
+ inspect and further tweak the merge result before committing.
--n::
---no-stat::
- Do not show a diffstat at the end of the merge.
+--ff::
+--no-ff::
+ Do not generate a merge commit if the merge resolved as
+ a fast-forward, only update the branch pointer. This is
+ the default behavior of git-merge.
---summary::
---no-summary::
- Synonyms to --stat and --no-stat; these are deprecated and will be
- removed in the future.
+ With --no-ff Generate a merge commit even if the merge
+ resolved as a fast-forward.
--log::
+--no-log::
In addition to branch names, populate the log message with
one-line descriptions from the actual commits that are being
merged.
---no-log::
- Do not list one-line descriptions from the actual commits being
- merged.
+ With --no-log do not list one-line descriptions from the
+ actual commits being merged.
---no-commit::
- Perform the merge but pretend the merge failed and do
- not autocommit, to give the user a chance to inspect and
- further tweak the merge result before committing.
---commit::
- Perform the merge and commit the result. This option can
- be used to override --no-commit.
+--stat::
+-n::
+--no-stat::
+ Show a diffstat at the end of the merge. The diffstat is also
+ controlled by the configuration option merge.stat.
+
+ With -n or --no-stat do not show a diffstat at the end of the
+ merge.
--squash::
+--no-squash::
Produce the working tree and index state as if a real
merge happened (except for the merge information),
but do not actually make a commit or
@@ -47,18 +46,9 @@
top of the current branch whose effect is the same as
merging another branch (or more in case of an octopus).
---no-squash::
- Perform the merge and commit the result. This option can
- be used to override --squash.
---no-ff::
- Generate a merge commit even if the merge resolved as a
- fast-forward.
-
---ff::
- Do not generate a merge commit if the merge resolved as
- a fast-forward, only update the branch pointer. This is
- the default behavior of git-merge.
+ With --no-squash perform the merge and commit the result. This
+ option can be used to override --squash.
-s <strategy>::
--strategy=<strategy>::
@@ -67,3 +57,16 @@
If there is no `-s` option, a built-in list of strategies
is used instead ('git-merge-recursive' when merging a single
head, 'git-merge-octopus' otherwise).
+
+--summary::
+--no-summary::
+ Synonyms to --stat and --no-stat; these are deprecated and will be
+ removed in the future.
+
+-q::
+--quiet::
+ Operate quietly.
+
+-v::
+--verbose::
+ Be verbose.
--
1.6.4.3
^ permalink raw reply related
* Re: [PATCH] Documentation/fetch-options.txt: order options alphabetically
From: Jari Aalto @ 2009-10-22 9:23 UTC (permalink / raw)
To: git
In-Reply-To: <7vhbts3285.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> I think you looked only at git-fetch.txt without
> checking where else this file is included. Then the patch certainly is
> understandable. It would probably make git-fetch.{1,html} easier to scan,
> while making things not worse for git-pull.{1,html}
Yes. Unfortunately there doesn't seem to be a way to arrange all nicely,
so perhaps you could accept the following patch to accompany with it. At
least there would be ordered "git-fetch" and semi ordered "git-pull".
Subject: [PATCH] Documentation/merge-options.txt: order options in alphabetical groups
Jari
^ permalink raw reply
* Re: [PATCH] modernize fetch/merge/pull examples
From: Thomas Rast @ 2009-10-22 8:51 UTC (permalink / raw)
To: Clemens Buchacher
Cc: Junio C Hamano, Björn Steinbrink, Daniel Barkalow, git
In-Reply-To: <20091021172123.GB27495@localhost>
Clemens Buchacher wrote:
> On Tue, Oct 20, 2009 at 11:22:16PM -0700, Junio C Hamano wrote:
>
> > For example, I am in favor of deprecating the "pull $there $src:$dst"
> > notation.
>
> A first step in that direction.
I think this is a good change independently of the deprecation.
> +------------------------------------------------
> +$ git fetch origin +pu:pu maint:tmp
> +------------------------------------------------
[...]
> +The `pu` branch will be updated even if it is does not fast-forward;
> +the others will not be.
I think to a new user it is not immediately clear if this means "will
not be updated, period" or "will not be updated if ...". How about
The `pu` branch will always be updated; the `tmp` branch only if it
is a fast-forward update.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ 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