Re: [git-users] How can I contribute with translations?

[Philip Oakley]

There are opportunities on the main Git project.

https://github.com/git-l10n/git-po/ maintained by Jiang Xin 



There are opportunities for the git-scm book

 https://git-scm.com/book/en/v2 look at the left side menu (and an older blog 
https://git-scm.com/blog/2009/08/19/translate-this.html)
  - Original Message - 
  From: nelson6...@gmail.com 
  To: Git for human beings 
  Sent: Wednesday, July 20, 2016 6:31 PM
  Subject: [git-users] How can I contribute with translations?


  Hi!

  I would like to help with Spanish translation, but I didn't found a Git 
project in Transifex or another link to translate.

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] Marking a branch "closed"?

[Charles Manning]

On Wed, Jul 20, 2016 at 6:06 PM, Michael  wrote:

>
> On 2016-07-19, at 11:02 PM, Charles Manning  wrote:
>
> Squashing makes sense if you have a really ratty bunch of checkins with
> work-in-progress checkins etc., but unless it's a trivial topic branch I
> would still typically make the final set of commits into a few logical
> steps.
>
> It costs pretty much nothing to leave old topic branches around (but a few
> thousand "nothings" can add up :-)).
>
> Once you've merged a topic branch you can safely delete the branch with no
> harm (apart from losing the branch itself).
>
> As Gergely says it depends on your workflow.
>
> For example let's say you are using some fault tracking database (eg.
> trac). It often makes sense to do the fix on a topic branch  (eg.
> fix-trac-1234). If you leave the branch in place after merging it you can
> then refer to the branch in the trac notes and see what fixes were used to
> fix the bug (and reopen the bug if it needs another kick).
>
>
> This actually is why I'd like to keep the old "messy work-in-progress"
> history, so I can see what had to be done should it be necessary to go
> back. I still would like some way to be able to see, at a glance, "This
> branch is marked as committed, so I don't have to worry that I forgot about
> it".
>
>
Well as you can see from this thread, there is no "one true way".

By "messy work in progress, I mean those little checkins along the way when
you're doing little experiments, deleting them and trying something else.

I will often do little WIP checkins so I don't lose say 15 minutes of work.
They are not useful commits in themselves,

It is generally worth cleaning those up so that you end up with fewer
"logical" commits without all the little mis-steps.
But why not just start off keep the closed topic branches. If you don't
like them you can always delete them later.

I would suggest giving them a fixed format so that they are easy to filter
out and delete/rename later,\


> ---
> Entertaining minecraft videos
> http://YouTube.com/keybounce
>
> --
> You received this message because you are subscribed to the Google Groups
> "Git for human beings" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to git-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] Marking a branch "closed"?

[Konstantin Khomoutov]

On Wed, 20 Jul 2016 14:08:50 -0400
wor...@alum.mit.edu (Dale R. Worley) wrote:

> > Lets say I've got a topic branch. I've made a bunch of commits. It's
> > messy. But it's done.
> 
> > What do I do with the leftover? I thought I could tag it as
> > "closed", but I can't use the same tag more than once. What's the
> > best way to mark it as done, or should I just delete the branch
> > label and let it be garbage collected/deleted?
> 
> Why not tag the branch tip with "_closed"?
> 
> And if you need to reopen the branch, just delete the tag.

My personal approach to this is two fold:

1) If a (feature / bugfix) branch was fully merged (usually to some
   mainline) there really is no sense to keep it longer, and so
   I just delete it.

2) If a branch is not going to be merged anywhere, it's typically
   either a dead-end or a postponed idea.

   In the first case I _replace_ the branch with an annotated tag
   which explains why that was a dead end.  That is, a tag pointing
   to the branch's tip is created, and the branch itself is deleted
   afterwards.  In the latter case the branch just lives on.
   Attaching an annotated tag to its tip looks OK to me.

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] Marking a branch "closed"?

[Dale R. Worley]

Michael  writes:
> Lets say I've got a topic branch. I've made a bunch of commits. It's
> messy. But it's done.

> What do I do with the leftover? I thought I could tag it as "closed",
> but I can't use the same tag more than once. What's the best way to
> mark it as done, or should I just delete the branch label and let it
> be garbage collected/deleted?

Why not tag the branch tip with "_closed"?

And if you need to reopen the branch, just delete the tag.

Dale

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] Need Suggestions on Git Bitbucket or Stash

[Konstantin Khomoutov]

On Wed, 20 Jul 2016 07:41:52 -0700 (PDT)
Sanjiv Kumar  wrote:

[...]
> I am looking for inputs and suggestions on the following workflow:
> 
> 1. Can we do the contributions stuff in public repo using
> stash/bitbucket? I think we can do it using forking and pull.

This question is irrelevant to Git: Git-as-a-software-package allows
two ways of "getting stuff from the outside":

* Fetching data from a remote Git repository and then merging it
  into the local one.

* Applying textual patches.

Basically, what most folks know as "pull request" these days is some
feature in the web interface of certain Git hosting providers which
allows a developer to nominate a branch of their choice in one of
their repos to be considered by the upstream developers for inclusion
(merging) into their original repository.
Not too many people know that the stock Git actually includes the
`git request-pull` command which allows the developer to prod the devs
of the upstream project with the informaition necessary for them to
obtain, inspect and integrate the changes done against the upstream
projects.  In a sense, what Github et al offer in this venue is
slightly modified and web-ified solution which does not change the
essense of the matter: Git is able to grab the specified history from
any remote repository and integrate it into a local one.

So, yes.

> 2. Can we sync the two repos (private and public) unidirectional and 
> bidirectional? This we will decide later on if we need to implement 
> unidirectional or bidirectional.

I'm afraid of the word "sync"; I hope this is just an unfortunately
selected term.  Synchronizing means you have two pieces of information
and either make one of them a complete replica of the other (one-way
sync) or somehow make each of them contain all the data the other one
has, plus its own.  While the first one is simple with Git (but IMO has
no sense outside of making backups) the second one is not -- starting
right with the need to have exact semantics of such sync up front
before attempting to implement it.

On the other hand, if you drop this "sync" bit, you get the model
everyone uses :-)
Basically your public repo in this model only ever receives
specific updates from your internal repos.  You push what you deem is
OK for publishing, and on a schedule you deem as appropriate.
Having a proper mental model for a public repository in a world of
distributed CM systems requires certain mindset; for me, [1] was an
eye-opener, so I recommend you to read it and understand what it talks
about.  This explanation is for much larger scale Git deployment that
you seem to be envisioning, but this is exactly what helps to grasp the
ideas behing public vs private repositories.

1. http://lwn.net/Articles/246381/

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[git-users] How can I contribute with translations?

[nelson6e65]

Hi!

I would like to help with *Spanish *translation, but I didn't found a Git 
project in Transifex or another link to 
translate.

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[git-users] Need Suggestions on Git Bitbucket or Stash

[Sanjiv Kumar]

Hi Guys,

I have two Git repos hosted on stash or bitbucket. We want to implement the 
open source repo kind of contribution just like in github. One of my repo 
is public (accessible in my premises) and another one is private.

I am looking for inputs and suggestions on the following workflow:

1. Can we do the contributions stuff in public repo using stash/bitbucket? 
I think we can do it using forking and pull.
2. Can we sync the two repos (private and public) unidirectional and 
bidirectional? This we will decide later on if we need to implement 
unidirectional or bidirectional.

Any kind of inputs/suggests are highly appreciated.

Thanks,
Sanjiv

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.