Re: [PATCHv2] gitk: Replace next and prev buttons with down and up arrows.

2014-01-21 Thread Marc Branchaud
On 13-12-18 11:04 AM, Marc Branchaud wrote: Users often find that next and prev do the opposite of what they expect. For example, next moves to the next match down the list, but that is almost always backwards in time. Replacing the text with arrows makes it clear where the buttons will take

Re: [PATCH 3/3] reset: Print a warning when user uses git reset during a merge

2014-03-14 Thread Marc Branchaud
On 14-03-14 12:37 AM, Andrew Wong wrote: During a merge, --mixed is most likely not what the user wants. Using --mixed during a merge would leave the merged changes and new files mixed in with the local changes. The user would have to manually clean up the work tree, which is non-trivial. In

Re: [PATCH 3/3] reset: Print a warning when user uses git reset during a merge

2014-03-15 Thread Marc Branchaud
On 14-03-14 04:55 PM, Junio C Hamano wrote: So I am OK with eventually error out by default, but not OK with we know better than the user and will not allow it at all. Can I interpret that as you being OK with my proposed Cowardly refusing approach? M. -- To unsubscribe

Pull is Evil (was: Re: A failing attempt to use Git in a centralized environment)

2014-04-30 Thread Marc Branchaud
On 14-04-28 02:41 PM, Junio C Hamano wrote: Marat Radchenko ma...@slonopotamus.org writes: Problem #1: TortoiseGit GUI windows for common tasks have a heck lots of controls that a common Git user will never need. Do people around TortoiseGit lurk on this list? Otherwise this may not be

Re: Pull is Evil

2014-04-30 Thread Marc Branchaud
On 14-04-30 10:55 AM, Junio C Hamano wrote: Marc Branchaud marcn...@xiplink.com writes: But I'm definitely biased because I think pull is pretty much broken: * New users are encouraged to use pull, but all too often the default fetch-then-merge behaviour doesn't match their expectations

Re: Pull is Evil

2014-04-30 Thread Marc Branchaud
On 14-04-30 04:01 PM, Junio C Hamano wrote: Maybe I was unclear. I didn't mean replace 'pull' with 'update' everywhere. I meant Introduce 'update' that lets integrate your history into that from the remote, which is to integrate in a direction opposite from how 'pull' does. That's

Re: Pull is Evil

2014-04-30 Thread Marc Branchaud
On 14-04-30 04:14 PM, Felipe Contreras wrote: Marc Branchaud wrote: All that said, I don't object to any attempts at improving the command either. But I also don't see any kind of improvement that would lead me to start using git pull let alone recommending it to new users. What is wrong

Re: Pull is Evil

2014-05-01 Thread Marc Branchaud
On 14-05-01 05:46 AM, brian m. carlson wrote: On Wed, Apr 30, 2014 at 05:25:59PM -0500, Felipe Contreras wrote: Marc Branchaud wrote: On 14-04-30 04:14 PM, Felipe Contreras wrote: What is wrong when `git pull` merges a fast-forward? Nothing. Everything. It depends. It depends on what? I

Re: [git] Re: Pull is Evil

2014-05-01 Thread Marc Branchaud
On 14-05-01 01:56 PM, W. Trevor King wrote: On Thu, May 01, 2014 at 11:20:44AM -0400, Marc Branchaud wrote: On 14-05-01 05:46 AM, brian m. carlson wrote: git checkout maintenance-branch # Update our maintenance branch to the latest from the main repo. git pull --ff-only git pull

Re: Pull is Evil

2014-05-01 Thread Marc Branchaud
On 14-05-01 03:22 PM, Felipe Contreras wrote: Marc Branchaud wrote: What's more, it seems to me that the only real advantage git pull provides here is a less typing compared to the non-pull equivalent: git fetch main-repo git checkout main-repo/maintenance-branch git fetch developer

Re: [git] Re: Pull is Evil

2014-05-01 Thread Marc Branchaud
On 14-05-01 02:30 PM, W. Trevor King wrote: I find a local branch useful to mark the amount of the upstream branch that I've reviewed. The reflog helps a bit, but I may go several fetches between reviews. For newbies, I recommend avoiding detached HEADs, where possible, so they don't have

Pull is Mostly Evil

2014-05-02 Thread Marc Branchaud
(Apologies for not CCing all the folks who've participated in the Pull is Evil thread -- I couldn't find a good branch of that thread for this message.) OK, so maybe git pull is just Mostly Evil. People seem to have found many different ways to make it work for them. But in reality git pull

Re: Pull is Mostly Evil

2014-05-09 Thread Marc Branchaud
After poking this hornet's nest I pretty much have stood back and not participated in the ensuing discussions. But having unleashed the hornets I feel I should at least say something, if only to assure people that I'm not ignoring their plight. There have been various proposals to modify

Re: [PATCH v13 11/11] Documentation: add documentation for 'git interpret-trailers'

2014-08-20 Thread Marc Branchaud
On 14-08-16 12:06 PM, Christian Couder wrote: While at it add git-interpret-trailers to command-list.txt. Signed-off-by: Christian Couder chrisc...@tuxfamily.org Signed-off-by: Junio C Hamano gits...@pobox.com --- Documentation/git-interpret-trailers.txt | 308

Re: [PATCH v13 11/11] Documentation: add documentation for 'git interpret-trailers'

2014-08-21 Thread Marc Branchaud
On 14-08-20 11:39 PM, Christian Couder wrote: On Thu, Aug 21, 2014 at 12:05 AM, Marc Branchaud marcn...@xiplink.com wrote: On 14-08-16 12:06 PM, Christian Couder wrote: + +* after them it's only possible to have some lines that contain only + spaces, and then a patch; the patch part

Re: Relative submodule URLs

2014-08-22 Thread Marc Branchaud
On 14-08-19 12:07 PM, Robert Dailey wrote: On Mon, Aug 18, 2014 at 3:55 PM, Jonathan Nieder jrnie...@gmail.com wrote: Thanks for reporting. The remote used is the default remote that git fetch without further arguments would use: get_default_remote () {

Re: Relative submodule URLs

2014-08-28 Thread Marc Branchaud
, but not today. Both Heiko and Robert took issue with this statement of mine: On 14-08-22 12:00 PM, Marc Branchaud wrote: A branch should fork the entire repo, including its submodules. The implication is that if you want to push that branch somewhere, that somewhere needs to be able to accept the forks

Re: Relative submodule URLs

2014-08-29 Thread Marc Branchaud
On 14-08-28 03:35 PM, Heiko Voigt wrote: On Thu, Aug 28, 2014 at 01:44:18PM -0400, Marc Branchaud wrote: Heiko also said this: On Fri, Aug 22, 2014 at 12:00:07PM -0400, Marc Branchaud wrote: With relative-path submodules, the push's target repo *must* also have the submodules in their proper

Re: [PATCH 22/32] checkout: support checking out into a new working directory

2014-09-02 Thread Marc Branchaud
On 14-09-02 08:27 AM, Duy Nguyen wrote: After reading this multiple checkout mode in git-checkout.txt, I'm tempted to rewrite it like this. I think the example makes it clearer what I mean. If nobody has any comments, I'm going to send v2 with this (and other comments collected so far)

Re: [PATCH 22/32] checkout: support checking out into a new working directory

2014-09-08 Thread Marc Branchaud
On 14-09-08 06:52 AM, Duy Nguyen wrote: While we're changing the terms, I wonder if primary working directory and secondary working directories are better than main checkout and linked checkout. I might have a slight preference for main/linked, because primary/secondary can imply that there

Re: [PATCH v2 22/32] checkout: support checking out into a new working directory

2014-09-11 Thread Marc Branchaud
On 14-09-10 06:41 PM, Nguyễn Thái Ngọc Duy wrote: git checkout --to sets up a new working directory with a .git file pointing to $GIT_DIR/worktrees/id. It then executes git checkout again on the new worktree with the same arguments except --to is taken out. The second checkout execution, which

Re: [PATCH v2 23/32] prune: strategies for linked checkouts

2014-09-11 Thread Marc Branchaud
On 14-09-10 06:41 PM, Nguyễn Thái Ngọc Duy wrote: (alias R=$GIT_COMMON_DIR/worktrees/id) - linked checkouts are supposed to keep its location in $R/gitdir up to date. The use case is auto fixup after a manual checkout move. - linked checkouts are supposed to update mtime of $R/gitdir.

Re: [PATCH v2 23/32] prune: strategies for linked checkouts

2014-09-12 Thread Marc Branchaud
On 14-09-11 11:06 PM, Eric Sunshine wrote: On Thu, Sep 11, 2014 at 11:36 AM, Marc Branchaud marcn...@xiplink.com wrote: On 14-09-10 06:41 PM, Nguyễn Thái Ngọc Duy wrote: (alias R=$GIT_COMMON_DIR/worktrees/id) - linked checkouts are supposed to keep its location in $R/gitdir up to date

Re: [PATCH v2 22/32] checkout: support checking out into a new working directory

2014-09-22 Thread Marc Branchaud
On 14-09-21 05:50 AM, Duy Nguyen wrote: On Sun, Sep 21, 2014 at 10:10 AM, Eric Sunshine sunsh...@sunshineco.com wrote: Would it make sense for this rule of thumb summary to be presented first, and then the explanation of that rule after, rather than the reverse as is currently the case?

Re: [PATCH v2 23/32] prune: strategies for linked checkouts

2014-09-22 Thread Marc Branchaud
On 14-09-21 06:29 AM, Duy Nguyen wrote: Here we go again. Thanks both for the suggestions. The documentation looks good to me. FWIW: Signed-off-by: Marc Branchaud marcn...@xiplink.com M. -- 8 -- Subject: [PATCH] prune: strategies for linked checkouts (alias R

Re: [PATCH v2 28/32] gc: support prune --worktrees

2014-09-22 Thread Marc Branchaud
On 14-09-21 06:43 AM, Duy Nguyen wrote: And this is the update as suggested in 23/32 [1] [1] http://thread.gmane.org/gmane.comp.version-control.git/256210/focus=256849 Looks good! FWIW: Signed-off-by: Marc Branchaud marcn...@xiplink.com M. -- 8 -- Subject: [PATCH] gc

Re: [PATCH] clone: --dissociate option to mark that reference is only temporary

2014-10-15 Thread Marc Branchaud
On 14-10-14 03:57 PM, Junio C Hamano wrote: While use of the --reference option to borrow objects from an existing local repository of the same project is an effective way to reduce traffic when cloning a project over the network, it makes the resulting borrowing repository dependent on the

Re: [PATCH] clone: --dissociate option to mark that reference is only temporary

2014-10-15 Thread Marc Branchaud
On 14-10-15 01:29 PM, Junio C Hamano wrote: Marc Branchaud marcn...@xiplink.com writes: I think things would be more understandable if the option was --dissociate repository and was an explicit alternative to --reference: [[--reference | --dissociate] repository] I'm still not liking

Re: [PATCH] clone: --dissociate option to mark that reference is only temporary

2014-10-15 Thread Marc Branchaud
On 14-10-15 05:33 PM, Junio C Hamano wrote: Marc Branchaud marcn...@xiplink.com writes: On 14-10-15 01:29 PM, Junio C Hamano wrote: $ git clone \ --reference=/local/pool/linux.git \ --borrow=../my/neighbour/linux-hack.git \ git://git.kernel.org/./linux.git

Re: [PATCH] clone: --dissociate option to mark that reference is only temporary

2014-10-16 Thread Marc Branchaud
On 14-10-15 05:50 PM, Junio C Hamano wrote: Marc Branchaud marcn...@xiplink.com writes: Yes, but we're cloning gko, not the neighbour. Doesn't that mean that the clone operation won't know about any of the neighbour's refs? No. --reference (and a natural implementation of --borrow, I

Re: [PATCH] git-tag man: when to use lightweight or annotated tags

2013-07-25 Thread Marc Branchaud
On 13-07-25 09:45 AM, Daniele Segato wrote: From d0f4eca712e7cf74286bfab306763a8a571b6c95 Mon Sep 17 00:00:00 2001 From: Daniele Segato daniele.seg...@gmail.com Date: Thu, 25 Jul 2013 15:33:18 +0200 Subject: [PATCH] git-tag man: when to use lightweight or annotated tags stress the

Re: [PATCH] git-tag man: when to use lightweight or annotated tags

2013-07-26 Thread Marc Branchaud
On 13-07-26 04:46 AM, Daniele Segato wrote: From 34fdcb56e5784699ffa327ebfcd2c5cd99b61d2d Mon Sep 17 00:00:00 2001 From: Daniele Segato daniele.seg...@gmail.com Date: Thu, 25 Jul 2013 15:33:18 +0200 Subject: [PATCH] git-tag man: when to use lightweight or annotated tags When sending a patch

Re: [PATCHv3] git-tag man: when to use lightweight or annotated tags

2013-07-26 Thread Marc Branchaud
of your patch with the fixups I would recommend. I'm happy with Peff's version. Reviewed-by: Marc Branchaud marcn...@xiplink.com (Daniele, don't feel put off because Jonathan I are accepting Peff's text. If you think it still needs improving please speak up!) M. -- 8 -- From

Re: [PATCH] git-tag man: when to use lightweight or annotated tags

2013-07-26 Thread Marc Branchaud
On 13-07-26 01:19 PM, Daniele Segato wrote: By the way which is your role in the community? Don't want to be rude, I just don't know who I'm talking about :) the documentation maintainer? I'm just a git user and (very) occasional contributor. There's not much structure to the git community.

Re: [PATCH] More typofixes.

2013-07-29 Thread Marc Branchaud
On 13-07-29 04:18 AM, Ondřej Bílka wrote: Hi, I improved my tool and it catched following additional typos. As with any big project best way to catch errors is to have automated checks that catch them ( Other possibility would be to read everything ten times to get error rate down but

Re: [PATCH] More typofixes.

2013-07-29 Thread Marc Branchaud
...@seznam.cz Signed-off-by: Junio C Hamano gits...@pobox.com Looks good. Reviewed-by: Marc Branchaud marcn...@xiplink.com M. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http

Re: [PATCH] Documentation: fix typos in man pages

2013-07-30 Thread Marc Branchaud
On 13-07-29 05:15 PM, Øystein Walle wrote: Signed-off-by: Øystein Walle oys...@gmail.com --- I thought I'd take part in the typo fixing frenzy :) I have some other potential typos lines up. Right now the docs refer to both 'filesystem' and 'file system', as well as both 'testsuite' and

[PATCH] Specify UK English for the documentation source files.

2013-07-30 Thread Marc Branchaud
This will hopefully avoid questions over which spelling and grammar should be used. Translators are of course free to create localizations for other English dialects. Signed-off-by: Marc Branchaud marcn...@xiplink.com --- Although I'm Canadian I figured en_CA would be a little too parochial. I

[PATCH v2] Provide some linguistic guidance for the documentation.

2013-08-01 Thread Marc Branchaud
This will hopefully avoid questions over which spelling and grammar should be used. Translators are of course free to create localizations for other specific English dialects. Signed-off-by: Marc Branchaud marcn...@xiplink.com --- A little less stringent now. Documentation/CodingGuidelines

Re: [PATCH v2] Provide some linguistic guidance for the documentation.

2013-08-01 Thread Marc Branchaud
On 13-08-01 11:10 AM, Marc Branchaud wrote: This will hopefully avoid questions over which spelling and grammar should be used. Translators are of course free to create localizations for other Oops, I should have removed the word other here. M. specific English dialects

[PATCH v3] Provide some linguistic guidance for the documentation.

2013-08-01 Thread Marc Branchaud
This will hopefully avoid questions over which spelling and grammar should be used. Translators are of course free to create localizations for specific English dialects. Signed-off-by: Marc Branchaud marcn...@xiplink.com --- On 13-08-01 02:21 PM, Junio C Hamano wrote: Marc Branchaud marcn

Re: [PATCH v2] Provide some linguistic guidance for the documentation.

2013-08-02 Thread Marc Branchaud
On 13-08-02 02:25 AM, Jonathan Nieder wrote: Junio C Hamano wrote: Is that accurate? My impression has been: The documentation liberally mixes US and UK English (en_US/UK) norms for spelling and grammar, which is somewhat unfortunate. In an ideal world, it would have been

Re: git repack vs git gc --aggressive

2012-08-13 Thread Marc Branchaud
On 12-08-10 04:09 PM, Junio C Hamano wrote: Felix Natter fnat...@gmx.net writes: I have a few questions about this: As I am coming from large depth is harmful school, I would recommend - git repack -a -d -f with large --window with reasonably short --depth once, So something like

Re: [PATCH] gitk: Synchronize highlighting in file view when scrolling diff

2012-09-19 Thread Marc Branchaud
On 12-09-18 07:46 PM, Paul Mackerras wrote: On Tue, Sep 18, 2012 at 07:57:54AM +0200, Stefan Haller wrote: Whenever the diff pane scrolls, highlight the corresponding file in the file list on the right. For a large commit with many files and long per-file diffs, this makes it easier to keep

Re: submodule: if $command was not matched, don't parse other args

2012-09-24 Thread Marc Branchaud
On 12-09-23 01:36 PM, Jens Lehmann wrote: Am 22.09.2012 22:31, schrieb Junio C Hamano: Ramkumar Ramachandra artag...@gmail.com writes: diff --git a/git-submodule.sh b/git-submodule.sh index a7e933e..dfec45d 100755 --- a/git-submodule.sh +++ b/git-submodule.sh @@ -1108,7 +1108,15 @@ do

Re: What's cooking in git.git (Sep 2012, #09; Thu, 27)

2012-09-28 Thread Marc Branchaud
On 12-09-27 11:38 PM, Junio C Hamano wrote: * mb/remote-default-nn-origin (2012-07-11) 6 commits - Teach get_default_remote to respect remote.default. - Test that plain git fetch uses remote.default when on a detached HEAD. - Teach clone to set remote.default. - Teach git remote about

Re: push race

2012-10-15 Thread Marc Branchaud
On 12-10-15 10:09 AM, Ævar Arnfjörð Bjarmason wrote: On Mon, Oct 15, 2012 at 11:14 AM, Angelo Borsotti angelo.borso...@gmail.com wrote: Hello, FWIW we have a lot of lemmings pushing to the same ref all the time at $work, and while I've seen cases where: 1. Two clients try to push 2.

Re: [PATCH] Documentation/git-push.txt: explain better cases where --force is dangerous

2013-06-17 Thread Marc Branchaud
On 13-06-17 01:52 PM, Matthieu Moy wrote: The behavior of git push --force is rather clear when it updates only one remote ref, but running it when pushing several branches can really be dangerous. Warn the users a bit more and give them the alternative to push only one branch. Signed-off-by:

Re: [PATCH 7/7] push: document --lockref

2013-07-09 Thread Marc Branchaud
On 13-07-09 04:37 PM, Junio C Hamano wrote: Johannes Sixt j...@kdbg.org writes: Am 09.07.2013 21:53, schrieb Junio C Hamano: +--lockref:: +--lockref=refname:: +--lockref=refname:expect:: ... +This is meant to make `--force` safer to use. This is a contradiction. --force means I mean it,

Re: [RFC] Add a new email notification script to contrib

2012-11-08 Thread Marc Branchaud
On 12-11-08 04:42 AM, Michael Haggerty wrote: On 11/07/2012 10:47 PM, Ævar Arnfjörð Bjarmason wrote: On Fri, Jul 20, 2012 at 12:01 PM, Michael Haggerty mhag...@alum.mit.edu wrote: On 07/14/2012 08:59 AM, mhag...@alum.mit.edu wrote: Add a new Python script,

Re: [RFC] Add a new email notification script to contrib

2012-11-08 Thread Marc Branchaud
On 12-11-08 07:17 AM, Michael Haggerty wrote: On 11/08/2012 12:39 PM, Ævar Arnfjörð Bjarmason wrote: [...] I'm glad it's getting some use. Thanks for the feedback. I'll test it out some more, the issues I've had with it so far in migrating from the existing script + some custom hacks we

Re: [RFC] Add a new email notification script to contrib

2012-11-08 Thread Marc Branchaud
On 12-11-08 11:37 AM, Ævar Arnfjörð Bjarmason wrote: On Thu, Nov 8, 2012 at 5:24 PM, Marc Branchaud mbranch...@xiplink.com wrote: I'd like there to be one list that always gets everything, and the other lists should get subsets of the everything list. Since it supports multiple mailing lists

Re: Topics currently in the Stalled category

2012-11-21 Thread Marc Branchaud
On 12-11-20 07:05 PM, Junio C Hamano wrote: Here is a list of stalled topics I am having trouble deciding what to do (the default is to dismiss them around feature freeze). [ snip ] * mb/remote-default-nn-origin (2012-07-11) 6 commits - Teach get_default_remote to respect

Re: [PATCH v2] gitk: read and write a repository specific configuration file

2012-12-05 Thread Marc Branchaud
On 12-12-04 07:49 PM, Łukasz Stelmach wrote: Enable gitk read and write repository specific configuration file: .git/k if the file exists. To make gitk use the local file simply create one, e.g. with the touch(1) command. This is very useful if one uses different views for different

Weird problem with git-submodule.sh

2012-12-07 Thread Marc Branchaud
Hi all, This is with git 1.8.0.1 on all the machines involved. One of our build machines is having trouble with git submodule: $ git submodule init external/openssl No submodule mapping found in .gitmodules for path '' (.gitmodules and other aspects of the repo are fine -- the

Re: Weird problem with git-submodule.sh

2012-12-07 Thread Marc Branchaud
On 12-12-07 12:54 PM, Junio C Hamano wrote: Marc Branchaud marcn...@xiplink.com writes: This is with git 1.8.0.1 on all the machines involved. One of our build machines is having trouble with git submodule: ... Any ideas? How and why is the IFS set differently only on one of your build

Re: Weird problem with git-submodule.sh

2012-12-07 Thread Marc Branchaud
On 12-12-07 02:11 PM, Junio C Hamano wrote: Marc Branchaud marcn...@xiplink.com writes: On 12-12-07 12:54 PM, Junio C Hamano wrote: Marc Branchaud marcn...@xiplink.com writes: This is with git 1.8.0.1 on all the machines involved. One of our build machines is having trouble with git

Re: Weird problem with git-submodule.sh

2012-12-07 Thread Marc Branchaud
On 12-12-07 03:23 PM, Junio C Hamano wrote: Marc Branchaud marcn...@xiplink.com writes: sh-setup: protect from exported IFS Many scripted Porcelains rely on being able to split words at the default $IFS characters, i.e. SP, HT and LF. If the user exports a non-default IFS

Re: Weird problem with git-submodule.sh

2012-12-07 Thread Marc Branchaud
On 12-12-07 03:23 PM, Junio C Hamano wrote: Marc Branchaud marcn...@xiplink.com writes: sh-setup: protect from exported IFS Many scripted Porcelains rely on being able to split words at the default $IFS characters, i.e. SP, HT and LF. If the user exports a non-default IFS

Re: [PATCH] sh-setup: work around unset IFS bug in some shells

2012-12-07 Thread Marc Branchaud
I like your patch's subject line better than mine. M. On 12-12-07 05:34 PM, Junio C Hamano wrote: With an unset IFS, field splitting is supposed to act as if IFS is set to the usual SP HT LF, but Marc Branchaud reports that the shell on FreeBSD 7.2 gets this wrong

(bug?) Inconsistent workdir file timestamps after initial clone.

2012-12-11 Thread Marc Branchaud
Hi all, Occasionally when doing a fresh clone of a repo, if the clock ticks at just the wrong time the checked-out files end up with different timestamps. The effect of this can be that, when make is run in the workdir it'll decide that some files are out of date and try to rebuild them. (In

Re: (bug?) Inconsistent workdir file timestamps after initial clone.

2012-12-11 Thread Marc Branchaud
On 12-12-11 04:27 PM, Junio C Hamano wrote: Marc Branchaud marcn...@xiplink.com writes: Occasionally when doing a fresh clone of a repo, if the clock ticks at just the wrong time the checked-out files end up with different timestamps. The effect of this can be that, when make is run

Re: (bug?) Inconsistent workdir file timestamps after initial clone.

2012-12-12 Thread Marc Branchaud
On 12-12-11 05:30 PM, Junio C Hamano wrote: Marc Branchaud marcn...@xiplink.com writes: My point is that the initial checkout into an empty working directory should create all files with the same timestamp. Or, to be a bit more precise, whenever git-checkout *creates* files in the work dir

Re: [PATCH v2] submodule: add 'deinit' command

2012-12-13 Thread Marc Branchaud
On 12-12-12 05:25 PM, Jens Lehmann wrote: So unless people agree that deinit should also remove the work tree I'll prepare some patches teaching all git commands to consistently ignore deinitialized submodules. Opinions? I agree with Trevor's suggestion that deinit should restore the user to

Re: [PATCH 0/4] Support triangular workflows

2013-03-18 Thread Marc Branchaud
On 13-03-18 10:25 AM, Jeff King wrote: On Mon, Mar 18, 2013 at 06:46:11PM +0530, Ramkumar Ramachandra wrote: I've put off implementing remote.default corresponding to remote.pushdefault, as Jeff suggested in [1], because it's currently not an itch; apart from the obvious symmetry, I don't

Re: [PATCH 2/6] Teach remote.c about the remote.default configuration setting.

2012-07-06 Thread Marc Branchaud
On 12-07-06 03:31 PM, Junio C Hamano wrote: Marc Branchaud marcn...@xiplink.com writes: On 12-07-05 06:50 PM, Junio C Hamano wrote: - effective_remote_name is the name of the remote tracked by the current branch, or is default_remote_name if the current branch doesn't have a remote

Re: [PATCH 3/6] Teach clone to set remote.default.

2012-07-06 Thread Marc Branchaud
On 12-07-06 03:39 PM, Junio C Hamano wrote: Marc Branchaud marcn...@xiplink.com writes: If remote.default isn't set, then if someone does git remote rename origin foo the default remote will still be origin (modulo the currently-checked-out branch stuff). Why? Erm, actually

Re: [PATCH 3/6] Teach clone to set remote.default.

2012-07-06 Thread Marc Branchaud
On 12-07-06 04:43 PM, Marc Branchaud wrote: So why change git clone to always set remote.default if the functionality remains the same either way? To me it makes a more consistent implementation. Since git remote add sets remote.default if it's adding the first remote to the repository

Re: [PATCH 2/6] Teach remote.c about the remote.default configuration setting.

2012-07-11 Thread Marc Branchaud
On 12-07-11 02:21 PM, Junio C Hamano wrote: marcn...@xiplink.com writes: From: Marc Branchaud marcn...@xiplink.com The code now has a default_remote_name and an effective_remote_name: - default_remote_name is set by remote.default in the config, or is origin if remote.default doesn't

Re: [PATCH 3/6] Teach git remote about remote.default.

2012-07-11 Thread Marc Branchaud
On 12-07-11 02:27 PM, Junio C Hamano wrote: marcn...@xiplink.com writes: From: Marc Branchaud marcn...@xiplink.com The rename and rm commands now handle the case where the remote being changed is the default remote. handle the case is way underspecified. Until I peeked the patch, I

Re: [PATCH 2/6] Teach remote.c about the remote.default configuration setting.

2012-07-13 Thread Marc Branchaud
On 12-07-11 06:04 PM, Junio C Hamano wrote: Marc Branchaud marcn...@xiplink.com writes: On 12-07-11 02:21 PM, Junio C Hamano wrote: marcn...@xiplink.com writes: From: Marc Branchaud marcn...@xiplink.com The code now has a default_remote_name and an effective_remote_name

Re: [PATCH 3/6] Teach git remote about remote.default.

2012-07-13 Thread Marc Branchaud
On 12-07-11 05:55 PM, Junio C Hamano wrote: Marc Branchaud marcn...@xiplink.com writes: What about a warning displayed if remote.default is not set? Something like: This repository does not have an explicitly configured default remote. Selecting origin as the default remote

Re: [RFC] Add a new email notification script to contrib

2012-07-16 Thread Marc Branchaud
On 12-07-14 02:59 AM, mhag...@alum.mit.edu wrote: From: Michael Haggerty mhag...@alum.mit.edu Add a new Python script, contrib/hooks/post-receive-multimail.py, that can be used to send notification emails describing pushes into a git repository. This script is derived from

Re: [RFC/PATCH] clone: introduce clone.submoduleGitDir to relocate $GITDIR

2013-04-15 Thread Marc Branchaud
In general I think it is a mistake to overload git clone with the notion of adding a submodule. If I want to *add* something to a repository, I'll use some kind of add command. To me git clone is not the kind of verb I would expect to add something to some distant-parent .git directory. Instead

Re: [RFC/PATCH] clone: introduce clone.submoduleGitDir to relocate $GITDIR

2013-04-15 Thread Marc Branchaud
On 13-04-15 02:00 PM, Ramkumar Ramachandra wrote: Junio C Hamano wrote: I do not think the addition Ram is envisioning in the patch will prevent you from teaching add to do that. An implemention of such an addition indeed would most likely use the same --separate-git-dir mechanism anyway.

Re: [RFC/PATCH] clone: introduce clone.submoduleGitDir to relocate $GITDIR

2013-04-15 Thread Marc Branchaud
On 13-04-15 01:50 PM, Junio C Hamano wrote: Marc Branchaud mbranch...@xiplink.com writes: In general I think it is a mistake to overload git clone with the notion of adding a submodule. I agree with that principle, but my understanding is that this effort is not about teaching git clone

Re: [RFC/PATCH] clone: introduce clone.submoduleGitDir to relocate $GITDIR

2013-04-15 Thread Marc Branchaud
On 13-04-15 02:50 PM, Junio C Hamano wrote: Marc Branchaud marcn...@xiplink.com writes: After that clone or init creates a repository, you still have to add if you want to make it a submodule to the toplevel. To me it makes more sense to move the .git directory when the user invokes git

Re: [RFC/PATCH] clone: introduce clone.submoduleGitDir to relocate $GITDIR

2013-04-16 Thread Marc Branchaud
On 13-04-16 04:13 AM, Ramkumar Ramachandra wrote: Jeff King wrote: So there is some information that is per-clone (the objects, the remote tips), but there is some information that is per-submodule (where our local branches are, the index, the worktree). I can see why it is advantageous to

Re: [RFC/PATCH] clone: introduce clone.submoduleGitDir to relocate $GITDIR

2013-04-16 Thread Marc Branchaud
On 13-04-16 04:17 AM, Ramkumar Ramachandra wrote: Marc Branchaud wrote: If git add is all about specifying what lives under paths in the worktree, what's wrong with letting git add go beyond specifying just files? Syntax aside for the moment, I think a command like git add git-repo

Re: [RFC/PATCH] clone: introduce clone.submoduleGitDir to relocate $GITDIR

2013-04-16 Thread Marc Branchaud
On 13-04-16 04:21 AM, Ramkumar Ramachandra wrote: Junio C Hamano wrote: It does not relieve git add (or git submodulea add) from the responsibility of moving .git directory. It only reduces the need to do so. When the user says add and the repository has .git directory in it, add (or

[PATCH] Fix grammar in the 1.8.3 release notes.

2013-04-29 Thread Marc Branchaud
Signed-off-by: Marc Branchaud marcn...@xiplink.com --- This started out as an attempt to make the backward compatibility notes more parsable, but then I just kept going... M. Documentation/RelNotes/1.8.3.txt | 145 +++ 1 file changed, 72

Re: [PATCH] Fix grammar in the 1.8.3 release notes.

2013-04-30 Thread Marc Branchaud
On 13-04-29 05:15 PM, Junio C Hamano wrote: Marc Branchaud marcn...@xiplink.com writes: This started out as an attempt to make the backward compatibility notes more parsable, but then I just kept going... Thanks. * git bundle did not like a bundle created using a commit without

Re: [PATCH] Fix grammar in the 1.8.3 release notes.

2013-05-01 Thread Marc Branchaud
On 13-05-01 04:24 AM, Lukas Fleischer wrote: On Tue, Apr 30, 2013 at 10:28:21AM -0400, Marc Branchaud wrote: On 13-04-29 05:15 PM, Junio C Hamano wrote: Marc Branchaud marcn...@xiplink.com writes: This started out as an attempt to make the backward compatibility notes more parsable

lets vs. let's (was: Re: [PATCH v3] Add new @ shortcut for HEAD)

2013-05-01 Thread Marc Branchaud
On 13-05-01 06:31 AM, Thomas Adam wrote: On 1 May 2013 11:12, Eric Sunshine sunsh...@sunshineco.com wrote: On Wed, May 1, 2013 at 5:51 AM, Felipe Contreras felipe.contre...@gmail.com wrote: So HEAD@{0}~0^0 is too much to type, but we can remove '^0', and we can remove '~0', and we can remove

Re: Local tag killer

2013-09-24 Thread Marc Branchaud
On 13-09-24 03:51 AM, Jeff King wrote: On Sat, Sep 21, 2013 at 08:42:26AM +0200, Michael Haggerty wrote: I think it would be preferable if --prune would *not* affect tags, and if there were an extra option like --prune-tags that would have to be used explicitly to cause tags to be pruned.

Re: [ANNOUNCE] Git v1.8.4.1

2013-09-27 Thread Marc Branchaud
On 13-09-27 02:52 PM, Jonathan Nieder wrote: The latest maintenance release Git v1.8.4.1 is now available. The release tarballs are found at: http://alioth.debian.org/~jrnieder-guest/git/ and their SHA-1 checksums are: 49004a8dfcbb7c0848147737d9877fd7313a42ec git-1.8.4.1.tar.gz

Re: Local tag killer

2013-09-30 Thread Marc Branchaud
On 13-09-29 12:29 AM, Michael Haggerty wrote: On 09/28/2013 11:42 PM, Johan Herland wrote: On Sat, Sep 28, 2013 at 2:20 PM, Michael Haggerty mhag...@alum.mit.edu wrote: [...] * How would somebody (e.g., an interim maintainer) suck down tags from a project into his own refs/tags/*

Re: Local tag killer

2013-09-30 Thread Marc Branchaud
On 13-09-30 11:52 AM, Nicolas Pitre wrote: On Mon, 30 Sep 2013, Marc Branchaud wrote: Why would there be ambiguity warnings? The fetch command shouldn't issue any warnings, since all the remotes' names get safely tucked away in distinct namespaces. Are we talking about DWIM warnings

Re: Local tag killer

2013-09-30 Thread Marc Branchaud
On 13-09-30 04:08 PM, Nicolas Pitre wrote: On Mon, 30 Sep 2013, Marc Branchaud wrote: On 13-09-30 11:52 AM, Nicolas Pitre wrote: Consider that I have in my Linux kernel tree: - a remote branch corresponding to Linus' master tree - multiple remote branches corresponding to Linux stable

Re: Local tag killer

2013-09-30 Thread Marc Branchaud
On 13-09-30 06:44 PM, Nicolas Pitre wrote: On Mon, 30 Sep 2013, Marc Branchaud wrote: On 13-09-30 04:08 PM, Nicolas Pitre wrote: Again, in the cases where there is actually a SHA1 conflict between all possible tags that match a tag short-end then listing them and asking the user to be more

Re: Local tag killer

2013-10-01 Thread Marc Branchaud
On 13-09-30 11:28 PM, Nicolas Pitre wrote: But with my proposal, you'd get a message saying that the tag baz is ambigous, and that you'd have to use either libfoo/baz or libbar/baz. Yes, and that's good. I agree with your proposal. Sorry if that wasn't clear. M. -- To

Re: gitk next/prev buttons

2013-10-08 Thread Marc Branchaud
On 13-09-30 10:31 PM, Lucas Sandery [three am design] wrote: The next and prev buttons are lacking consistency and logic. For RTL languages previous is almost always on the left, and next on the right. The words are contradictory, next actually goes to backwards chronologically, and prev goes

Re: gitk next/prev buttons

2013-10-08 Thread Marc Branchaud
On 13-10-08 03:36 PM, Jonathan Nieder wrote: In a branchy history, it is possible for the next matching commit to actually be newer. Chronologically, yes. Gitk will often display a history like this (here the numbers represent commit dates, so 1 is the oldest commit, and I've rotated this 90

[PATCH] gitk: Rename next and prev buttons to older and newer.

2013-10-08 Thread Marc Branchaud
Users often find that next and prev do the opposite of what they expect. For example, next moves to the next match down the list, but that is almost always backwards in time. Renaming next to older and prev to newer makes it clear where the buttons will take the user. --- (Apologies to Lucas

Re: [PATCH v2] gitk: Add a horizontal scrollbar for commit history

2013-10-30 Thread Marc Branchaud
On 13-10-30 08:47 AM, Nicolas Cornu wrote: This is useful on all our repos, every times, as we put a tag per day. If the HEAD didn't move during 150 days, we got 150 tags. So, it depends, maybe can I put it as an option in Edit Preferences? Eek, even with a scrollbar, 150 tags seems like a

Re: [PATCH v2] gitk: Add a horizontal scrollbar for commit history

2013-10-30 Thread Marc Branchaud
On 13-10-30 10:49 AM, Nicolas Cornu wrote: 2013/10/30 Marc Branchaud marcn...@xiplink.com: On 13-10-30 08:47 AM, Nicolas Cornu wrote: This is useful on all our repos, every times, as we put a tag per day. If the HEAD didn't move during 150 days, we got 150 tags. So, it depends, maybe can I

Re: [PATCH v2] gitk: Add a horizontal scrollbar for commit history

2013-11-04 Thread Marc Branchaud
On 13-10-31 05:05 AM, Paul Mackerras wrote: On Wed, Oct 30, 2013 at 01:47:08PM +0100, Nicolas Cornu wrote: This is useful on all our repos, every times, as we put a tag per day. If the HEAD didn't move during 150 days, we got 150 tags. Here is a patch that I did some time ago but have never

Re: What's cooking in git.git (Nov 2013, #02; Wed, 6)

2013-11-07 Thread Marc Branchaud
On 13-11-06 07:01 PM, Junio C Hamano wrote: There is a proposed rewording of advice message from git push patch, which is tentatively queued near the tip of 'pu' for now; it would be nice to get a few more sets of eyeballs. I am not sure if we should merge it before the 1.8.5 final, yet (we

Re: [PATCH v3] push: Enhance unspecified push default warning

2013-11-08 Thread Marc Branchaud
On 13-11-08 01:02 PM, Junio C Hamano wrote: Matthieu Moy matthieu@grenoble-inp.fr writes: Jonathan Nieder jrnie...@gmail.com writes: When push.default is set to 'matching', git will push local branches to remote branches that already exist with the same (matching) name. Yes,

Re: [PATCH v3] push: Enhance unspecified push default warning

2013-11-11 Thread Marc Branchaud
On 13-11-11 12:02 PM, Junio C Hamano wrote: Is everybody happy with this version? Looks good. M. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at

  1   2   3   >