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/. It then executes "git checkout"
> again on the new worktree with the same arguments except "--to" is
> taken out. The second checkout execution
On 14-09-10 06:41 PM, Nguyễn Thái Ngọc Duy wrote:
> (alias R=$GIT_COMMON_DIR/worktrees/)
>
> - 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/gitd
On 14-09-11 11:06 PM, Eric Sunshine wrote:
> On Thu, Sep 11, 2014 at 11:36 AM, Marc Branchaud wrote:
>> On 14-09-10 06:41 PM, Nguyễn Thái Ngọc Duy wrote:
>>> (alias R=$GIT_COMMON_DIR/worktrees/)
>>>
>>> - linked checkouts are supposed to keep its location in
On 14-09-21 05:50 AM, Duy Nguyen wrote:
> On Sun, Sep 21, 2014 at 10:10 AM, Eric Sunshine
> 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?
>
> You mean like
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
M.
> -- 8< --
> Subject: [PATCH] prune: strategies for linked checkouts
>
> (alias R=$GIT_CO
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
M.
> -- 8< --
> Subject: [PATCH]
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 t
On 14-10-15 01:29 PM, Junio C Hamano wrote:
> Marc Branchaud writes:
>
>> I think things would be more understandable if the option was "--dissociate
>> " and was an explicit alternative to --reference:
>> [[--reference | --dissociate] ]
>>
>&g
On 14-10-15 05:33 PM, Junio C Hamano wrote:
> Marc Branchaud 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 \
>
On 14-10-15 05:50 PM, Junio C Hamano wrote:
> Marc Branchaud 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
On 14-04-28 02:41 PM, Junio C Hamano wrote:
> Marat Radchenko 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 something we ca
On 14-04-30 10:55 AM, Junio C Hamano wrote:
> Marc Branchaud 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'
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".
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 alon
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?
>>>
>>
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 rep
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
>> gi
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 h
(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 pul
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 git-pull
On 14-05-29 06:42 PM, Junio C Hamano wrote:
> While it is not *wrong* per-se to say that pulling a rewound/rebased
> branch will lead to an unnecessary merge conflict, that is not what
> the leading "+" sign to allow non-fast-forward update of remote-tracking
> branch is at all.
>
> Signed-off-by:
On 14-05-29 06:42 PM, Junio C Hamano wrote:
> - "Branches" is a more common way to say "heads" in these days.
>
> - Remote-tracking branches are used a lot more these days and it is
>worth mentioning that it is one of the primary side effects of
>the command to update them.
>
> - Avoid
On 14-05-30 01:52 PM, Junio C Hamano wrote:
> Marc Branchaud writes:
>
>> On 14-05-29 06:42 PM, Junio C Hamano wrote:
>>> +
>>> +The names of refs that are fetched, together with the object names
>>> +they point at, are written to `.git/FETCH_HEAD`. T
Signed-off-by: Marc Branchaud
---
Documentation/git-fetch.txt | 30 +-
1 file changed, 21 insertions(+), 9 deletions(-)
This patch applies on top of your 1/5. It:
* De-emphasizes the FETCH_HEAD stuff by moving it to the end of the
DESCRIPTION section,
* States
On 14-05-30 01:54 PM, Junio C Hamano wrote:
> Marc Branchaud writes:
>>
>> Then start the next sentence with
>>
>> In this case, you would want
>
> I somehow find that "in this case" redundant, given that "for such
> branches"
On 14-06-03 06:16 PM, Junio C Hamano wrote:
> It is misleading to mention that that does not store is to
> fetch the ref into FETCH_HEAD, because a refspec that does store is
> also to fetch the LHS into FETCH_HEAD. It is doubly misleading to
> list it as part of "short-cut". stands for a refsp
On 14-06-03 06:16 PM, Junio C Hamano wrote:
> Replace desription of old-style "Pull:" lines in remotes/
> configuration with modern remote.*.fetch variables.
>
> As this note applies only to "git pull", enable it only
> in git-pull manual page.
>
> Signed-off-by: Junio C Hamano
> ---
> Document
On 14-06-03 06:16 PM, Junio C Hamano wrote:
> Since the introduction of opportunisitic updates of remote-tracking
> branches, started at around f2690487 (fetch: opportunistically
> update tracking refs, 2013-05-11) with a few updates in v1.8.4 era,
> the remote.*.fetch configuration always kicks in
On 14-06-03 06:16 PM, Junio C Hamano wrote:
> To resurrect a misleading mention removed in the previous step,
> add a section to explain how the remote-tracking configuration
> interacts with the refspecs given as the command-line arguments.
>
> Signed-off-by: Junio C Hamano
> ---
> Documentatio
On 14-06-04 06:17 PM, Junio C Hamano wrote:
> Marc Branchaud writes:
>
> [jc: omitted good suggestions I'll use in amending]
>
>>> + the refspecs to be used to fetch. The example above will fetch
>>
>> /to be used//
>
> I have a problem with that c
Signed-off-by: Marc Branchaud
---
Documentation/git-fetch.txt| 4 ++--
Documentation/pull-fetch-param.txt | 17 ++---
2 files changed, 16 insertions(+), 5 deletions(-)
On 14-06-04 06:17 PM, Junio C Hamano wrote:
>
> Perhaps
>
> ... `remote..fetch` values
On 14-06-04 06:28 PM, Junio C Hamano wrote:
> Marc Branchaud writes:
>
>>> Teach the command to pay attention to the --refmap=:
>>> command-line options that can be used to override the use of
>>> configured remote.*.fetch as the refmap.
>>
>> (You
Signed-off-by: Marc Branchaud
---
Documentation/git-fetch.txt| 4 ++--
Documentation/pull-fetch-param.txt | 18 ++
2 files changed, 16 insertions(+), 6 deletions(-)
On 14-06-05 06:12 PM, Junio C Hamano wrote:
>
>> + parameters are not normally specifi
On 14-07-16 12:01 PM, Fabian Ruch wrote:
> Hi Marc,
>
> I forgot to cc your mailbox when I posted this patch last week. Do you
> still remember whether there was a particular reason why
> pick_one_preserving_merges wasn't touched by the commit b499549 ("Teach
> rebase the --no-ff option."), by any
Signed-off-by: Marc Branchaud
---
(Note that I did not reflow lines to keep them a specific length.)
Documentation/RelNotes/2.1.0.txt | 108 +++
1 file changed, 53 insertions(+), 55 deletions(-)
diff --git a/Documentation/RelNotes/2.1.0.txt b/Documentation
On 14-08-04 06:31 PM, Junio C Hamano wrote:
>
> * "git grep" learned grep.fullname configuration variable to force
>"--full-name" to be default. This may cause regressions on
>scripted users that do not expect this new behaviour.
Should this be noted in the backward compatibility notes?
On 14-08-05 02:43 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Marc Branchaud writes:
>> ...
>>> @@ -87,22 +87,20 @@ UI, Workflows & Features
>>> * "git mergetool" learned to drive the vimdiff3 backend.
>>>
>>>
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
> Signed-off-by: Junio C Hamano
> ---
> Documentation/git-interpret-trailers.txt | 308
> +++
> command-list.txt
On 14-08-20 11:39 PM, Christian Couder wrote:
> On Thu, Aug 21, 2014 at 12:05 AM, Marc Branchaud 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 t
On 14-08-19 12:07 PM, Robert Dailey wrote:
> On Mon, Aug 18, 2014 at 3:55 PM, Jonathan Nieder wrote:
>> Thanks for reporting. The remote used is the default remote that "git
>> fetch" without further arguments would use:
>>
>> get_default_remote () {
>> curr_branch=$(git s
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 http://vger.kernel.org/majordomo-i
On 13-11-13 06:07 PM, Junio C Hamano wrote:
> A release candidate Git v1.8.5-rc2 is now available for testing
> at the usual places.
[ snip ]
> Updates since v1.8.4
>
>
> Foreign interfaces, subsystems and ports.
>
> * "git-svn" used with SVN 1.8.0 when talking over https
---
Mostly just tweaks, although I did change the "foo^{tag}" description a lot.
M.
Documentation/RelNotes/1.8.5.txt | 158 ---
1 file changed, 80 insertions(+), 78 deletions(-)
diff --git a/Documentation/RelNotes/1.8.5.txt b/Documentation/Re
Oops:
Signed-off-by: Marc Branchaud
Sorry!
(I have at long last automated s-o-b in my git repo...)
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://vger.
On 13-11-18 01:49 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Marc Branchaud writes:
>>
>>>> Foreign interfaces, subsystems and ports.
>>>>
>>>> * "git-svn" used with SVN 1.8.0 when talking over https:// connection
&g
On 13-11-18 01:42 PM, Junio C Hamano wrote:
> Marc Branchaud writes:
>
>> Mostly just tweaks, although I did change the "foo^{tag}" description a lot.
>
> Thanks. It is surprising that one can make so many typoes in a
> single document ;-)
>
>> @@ -55,7
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 the user.
On 13-12-19 10:15 AM, Adam Spiers wrote:
> Hi all,
>
> If I launch gitk, switch the lower right pane from Patch view mode to
> Tree view, expand a few directories, and then changing to viewing a
> different commit, the tree automatically collapses again. This is
> really annoying when trying to v
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 ar
Signed-off-by: Marc Branchaud
---
Documentation/RelNotes/2.2.0.txt | 102 +++
1 file changed, 51 insertions(+), 51 deletions(-)
diff --git a/Documentation/RelNotes/2.2.0.txt b/Documentation/RelNotes/2.2.0.txt
index d4001c5..9d9d5d5 100644
--- a/Documentation
On 14-11-28 09:31 AM, Michael Haggerty wrote:
> On 11/27/2014 06:46 PM, Torsten Bögershausen wrote:
>> On 2014-11-25 01.28, Michael Haggerty wrote:
>> []
>>> Let me list the aspects of our mailing list workflow that I find
>>> cumbersome as a contributor and reviewer:
>>>
>>> * Submitting patches t
Signed-off-by: Marc Branchaud
---
I did a bit of googling but couldn't find some standard that says the
application name goes at the end of the title bar. But this is how all the
browsers and other apps I use regularly do things.
M.
gitk | 2 +-
1 file changed, 1 inse
The first patch simply changes the title from "gitk: " to " - gitk",
which is the title layout used by most of the applications on my Kubuntu box.
The second patch is the one that I'm more keen to see accepted. It relies
on the first only in that it follows the new title layout.
Signed-off-by: Marc Branchaud
---
I often open multiple gitk windows in the same working directory to examine
other branches or refs in the repo. This change allows me to distinguish
which window is showing what.
This is an RFC because it doesn't behave great with views. I don't us
On 15-01-06 12:51 PM, Marc Branchaud wrote:
> The first patch simply changes the title from "gitk: " to " - gitk",
> which is the title layout used by most of the applications on my Kubuntu box.
>
> The second patch is the one that I'm more keen to see accept
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.
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.
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
>> wrote:
>> [...]
>>> * How would somebody (e.g., an interim maintainer) suck down tags from
>>> a project into his own refs/tags/* namespace? (Wou
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
>> namespace
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
>
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
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.
--
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 "
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
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.
---
(Apologie
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
On 13-10-30 10:49 AM, Nicolas Cornu wrote:
> 2013/10/30 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.
>>&
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
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, y
On 13-11-08 01:02 PM, Junio C Hamano wrote:
> Matthieu Moy writes:
>
>> Jonathan Nieder 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, that's better than the original
On 15-02-22 12:38 PM, Michael J Gruber wrote:
> "git status" carefully names a detached HEAD "at" resp. "from" a rev or
> ref depending on whether the detached HEAD has moved since. "git branch"
> always uses "from", which can be confusing, because a status-aware user
> would interpret this as move
On 15-02-22 02:21 PM, Junio C Hamano wrote:
> Michael J Gruber writes:
>
>> "git status" carefully names a detached HEAD "at" resp. "from" a rev or
>> ref depending on whether the detached HEAD has moved since. "git branch"
>> always uses "from", which can be confusing, because a status-aware use
On 15-02-23 11:24 AM, Michael J Gruber wrote:
> Marc Branchaud venit, vidit, dixit 23.02.2015 16:12:
>> On 15-02-22 12:38 PM, Michael J Gruber wrote:
>>> "git status" carefully names a detached HEAD "at" resp. "from" a rev or
>>> ref dep
On 15-01-06 12:51 PM, Marc Branchaud wrote:
> The first patch simply changes the title from "gitk: " to " - gitk",
> which is the title layout used by most of the applications on my Kubuntu box.
>
> The second patch is the one that I'm more keen to see accept
Signed-off-by: Marc Branchaud
---
I did a bit of googling but couldn't find some standard that says the
application name goes at the end of the title bar. But this is how all the
browsers and other apps I use regularly do things.
M.
gitk | 2 +-
1 file changed, 1 inse
Signed-off-by: Marc Branchaud
---
I often open multiple gitk windows in the same working directory to examine
other branches or refs in the repo. This change allows me to distinguish
which window is showing what.
M.
gitk | 7 ++-
1 file changed, 6 insertions(+), 1
On 15-03-24 07:06 PM, Paul Mackerras wrote:
> On Mon, Mar 23, 2015 at 12:03:37PM -0700, Junio C Hamano wrote:
>>
>> Is it a good time for me to pull from you, or do you recommend me to
>> wait for a bit, expecting more? We'll go in the pre-release freeze
>> soon-ish, so I thought I should ping.
>
If the current view is the "Command line" view, show the command line
arguments instead of the view name.
Signed-off-by: Marc Branchaud
---
This is v2 of my previous "Show the command-line revs in the window title" RFC
patch. (I'm having trouble accessing gmane, o
Signed-off-by: Marc Branchaud
---
I noticed this today. I think this change is needed for getcommitlines to
work properly with translated gitk's.
M.
gitk | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gitk b/gitk
index 90419e3..fd5b50a 100755
--- a
On 15-03-24 07:06 PM, Paul Mackerras wrote:
> On Mon, Mar 23, 2015 at 12:03:37PM -0700, Junio C Hamano wrote:
>>
>> Is it a good time for me to pull from you, or do you recommend me to
>> wait for a bit, expecting more? We'll go in the pre-release freeze
>> soon-ish, so I thought I should ping.
>
On 13-07-09 04:37 PM, Junio C Hamano wrote:
> Johannes Sixt writes:
>
>> Am 09.07.2013 21:53, schrieb Junio C Hamano:
>>> +--lockref::
>>> +--lockref=::
>>> +--lockref=:::
>>> ...
>>> +This is meant to make `--force` safer to use.
>>
>> This is a contradiction. "--force" means "I mean it, dude",
On 13-07-25 09:45 AM, Daniele Segato wrote:
> From d0f4eca712e7cf74286bfab306763a8a571b6c95 Mon Sep 17 00:00:00 2001
> From: Daniele Segato
> Date: Thu, 25 Jul 2013 15:33:18 +0200
> Subject: [PATCH] git-tag man: when to use lightweight or annotated tags
>
> stress the difference between the two w
On 13-07-26 04:46 AM, Daniele Segato wrote:
> From 34fdcb56e5784699ffa327ebfcd2c5cd99b61d2d Mon Sep 17 00:00:00 2001
> From: Daniele Segato
> 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 to the list it's not n
"naming" ones like "git describe".
>
> Here is a re-send of your patch with the fixups I would recommend.
I'm happy with Peff's version.
Reviewed-by: Marc Branchaud
(Daniele, don't feel put off because Jonathan & I are accepting Peff's text.
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 communi
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 b
ed-off-by: Ondřej Bílka
> Signed-off-by: Junio C Hamano
Looks good.
Reviewed-by: Marc Branchaud
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://vger.kernel.org/majordomo-info.html
On 13-07-29 05:15 PM, Øystein Walle wrote:
> Signed-off-by: Øystein Walle
> ---
> 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 'test suite'.
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
---
Although I'm Canadian I figured en_CA would be a little too parochial. I
don't hav
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
---
A little less stringent now.
Documentation/CodingGuidelines | 6
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.
> specif
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
---
On 13-08-01 02:21 PM, Junio C Hamano wrote:
> Marc Branchaud writes:
>
&g
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 bette
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
>> wrote:
>>> On 07/14/2012 08:59 AM, mhag...@alum.mit.edu wrote:
Add a new Python script, contrib/hooks/post-receive-multimail.py
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
On 12-11-08 11:37 AM, Ævar Arnfjörð Bjarmason wrote:
> On Thu, Nov 8, 2012 at 5:24 PM, Marc Branchaud 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
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 remote.de
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
>
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
On 12-12-07 12:54 PM, Junio C Hamano wrote:
> Marc Branchaud 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
101 - 200 of 234 matches
Mail list logo
