Re: [git-users] Will GIT allow me to do this?? show tag history and where it was pinned on to which branch in the past

[Andrew Acevedo]

thanks Konstantin & Dale for your detail reply, much appreciated.

I had to re-read the post several times as git is new to me and not 
familiar with the commands. But it's now clear the direction that I will 
take.

Specifically, I will setup a main codebase branch and individual branches 
which represent each customer.
This way, I can quickly tell who is up to date etc  And the codebranch will 
reset the customer branch once it's up to date.

many thanks for your input

Andrew


On Monday, 25 April 2016 21:22:35 UTC+10, Konstantin Khomoutov wrote:

> On Sun, 24 Apr 2016 17:00:55 -0700 (PDT) 
> Andrew Acevedo  wrote: 
>
> > I'm not familiar with git, but can the same tag be moved around on 
> > several branches and a history is kept which position on the branch 
> > it's been pinned too before? 
>
> No. 
> The only place where movement of "refs" (which are heads (branches) and 
> tags)) is recorded is the so-called "reflog" (see `git help reflog`) 
> but it has some properties which make it unfit for what you're 
> after: 
>
> * It only is there as a safety measure against occasional "oopsies" 
>   where you, say, moved the head of a branch several commits back. 
>
> * The reflog is local to a particular repository, and its contents is 
>   neither pushed nor fetched, and it's impossible to do this. 
>
> * Bare repositories (those usually used to serve as "shared" -- think 
>   of repos hosted on Github etc) by default have their reflog disabled. 
>
> But what you think you should use tags for appears to be wrong. 
> I'll try to explain this commending your example situation inline. 
>
> > I have 4 customers on the same program but on different versions. e.g 
> > Customer A, Customer B etc. 
> > 
> > Customer A has version 10 of helloworld.cpp 
> > 
> > Customer B has version 4 of helloworld.cpp 
> > 
> > Customer B requires an urgent hot fix on top of version 4 for 
> > helloworld.cpp and can’t take the latest version 10. 
> > 
> > Using this setup in mind, 
> > 
> > http://nvie.com/files/Git-branching-model.pdf 
> > 
> >  Is it possible to setup git to show at a glance which version they 
> > are all up too? 
>
> Well, first thing first: in Git, branches and tags are mere ways to 
> reference particular commits.  The only difference between them is that 
> you can "advance" a branch by recording a new commit on it but you 
> can't update a tag in any way.  This difference is semantical: tags 
> are there to mark fixed points in the history while branches are there 
> to support distinct lines of development. 
>
> > and using tags to keep track of the earlier versions which was 
> > released to customers. So that I can determine quickly which version 
> > Customer B had before it had version 4, so that I can quickly roll 
> > back if necessary to their earliest version? 
>
> Well, if I understood your problem statement correctly, you basically 
> want to roll your development in a way that the repository contains 
> branches for abstract versions of your code base, like ver4 and ver10. 
> Am I right? 
>
> If yes, then the question of keeping the information about which 
> customer got which version is really orthogonal to the repository, and 
> I'm not sure why you'd want to keep it there (why not in some external 
> corporate resource like, say, a wiki?). 
>
> On the other hand, there are ways to keep this information in the 
> repository: 
>
> * Dedicate a special branch to store your release information 
>   in a simple text file (or whatever else which would be more convenient 
>   for you) or a set of files -- say, one file per customer. 
>
>   Each time you deploy a new version to a customer, check out that 
>   dedicated branch, update the information there, commit, push. 
>
>   To create a dedicated branch (not connected to any other branch) 
>   use the combo explained in `git help checkout`: 
>
> $ git checkout --orphan relinfo 
> $ git rm -rf . 
> ... 
> $ git commit 
>
>   To save time spent on checkouts when maintaining such a branch, 
>   you might employ the `git-new-workdir` facility. 
>
>   The matter of exploring the history of deploying releases then 
>   becomes studying the output of `git log relinfo` etc. 
>
> * Have per-customer branches along with "pristine" branches for 
>   different versions of your code base. 
>
>   Then, when you're about to deploy a new version to a customer, 
>   merge the branch containing that version of the codebase 
>   to the customer's branch (you might force this merge to be "true" 
>   even though it could have been resolved to a fast-forward case -- 
>   to record the time you switched the customer's code base, and maybe 
>   add some notes on this in the merge commit message). 
>
>   Instead of merging, you could just hard-reset the customer branch 
>   to the tip of the branch containing the new version.  Basically, 
>   if you have no special customization for customers, this is the same 
>   than plain 

Re: [git-users] Will GIT allow me to do this?? show tag history and where it was pinned on to which branch in the past

[Konstantin Khomoutov]

On Sun, 24 Apr 2016 17:00:55 -0700 (PDT)
Andrew Acevedo  wrote:

> I'm not familiar with git, but can the same tag be moved around on
> several branches and a history is kept which position on the branch
> it's been pinned too before?

No.
The only place where movement of "refs" (which are heads (branches) and
tags)) is recorded is the so-called "reflog" (see `git help reflog`)
but it has some properties which make it unfit for what you're
after:

* It only is there as a safety measure against occasional "oopsies"
  where you, say, moved the head of a branch several commits back.

* The reflog is local to a particular repository, and its contents is
  neither pushed nor fetched, and it's impossible to do this.

* Bare repositories (those usually used to serve as "shared" -- think
  of repos hosted on Github etc) by default have their reflog disabled.

But what you think you should use tags for appears to be wrong.
I'll try to explain this commending your example situation inline.

> I have 4 customers on the same program but on different versions. e.g 
> Customer A, Customer B etc.
> 
> Customer A has version 10 of helloworld.cpp
> 
> Customer B has version 4 of helloworld.cpp
> 
> Customer B requires an urgent hot fix on top of version 4 for 
> helloworld.cpp and can’t take the latest version 10.
> 
> Using this setup in mind,
> 
> http://nvie.com/files/Git-branching-model.pdf
> 
>  Is it possible to setup git to show at a glance which version they
> are all up too?

Well, first thing first: in Git, branches and tags are mere ways to
reference particular commits.  The only difference between them is that
you can "advance" a branch by recording a new commit on it but you
can't update a tag in any way.  This difference is semantical: tags
are there to mark fixed points in the history while branches are there
to support distinct lines of development.

> and using tags to keep track of the earlier versions which was
> released to customers. So that I can determine quickly which version
> Customer B had before it had version 4, so that I can quickly roll
> back if necessary to their earliest version?

Well, if I understood your problem statement correctly, you basically
want to roll your development in a way that the repository contains
branches for abstract versions of your code base, like ver4 and ver10.
Am I right?

If yes, then the question of keeping the information about which
customer got which version is really orthogonal to the repository, and
I'm not sure why you'd want to keep it there (why not in some external
corporate resource like, say, a wiki?).

On the other hand, there are ways to keep this information in the
repository:

* Dedicate a special branch to store your release information
  in a simple text file (or whatever else which would be more convenient
  for you) or a set of files -- say, one file per customer.

  Each time you deploy a new version to a customer, check out that
  dedicated branch, update the information there, commit, push.

  To create a dedicated branch (not connected to any other branch)
  use the combo explained in `git help checkout`:

$ git checkout --orphan relinfo
$ git rm -rf .
...
$ git commit

  To save time spent on checkouts when maintaining such a branch,
  you might employ the `git-new-workdir` facility.

  The matter of exploring the history of deploying releases then
  becomes studying the output of `git log relinfo` etc.

* Have per-customer branches along with "pristine" branches for
  different versions of your code base.

  Then, when you're about to deploy a new version to a customer,
  merge the branch containing that version of the codebase
  to the customer's branch (you might force this merge to be "true"
  even though it could have been resolved to a fast-forward case --
  to record the time you switched the customer's code base, and maybe
  add some notes on this in the merge commit message).

  Instead of merging, you could just hard-reset the customer branch
  to the tip of the branch containing the new version.  Basically,
  if you have no special customization for customers, this is the same
  than plain merging explained above without forcing a non-fast-forward
  merge.
  Should you adopt this approach, each time you update the customer's
  branch this way, you could decorate it with a tag -- possibly
  annotated -- explaining which version was deployed.

Note that while branches and tags are not explicitly namespaced, it's
easy to emulate it by adopting a simple policy -- say, the names of
tags marking versions of software deployed to customers might have
the form /, like in "acme-ltd/v4.1.1".
Git is fine with this (but don't use things which systems with non-POSIX
filesystems won't like -- so basically avoid having ":" and trailing
"."-s in your branch and tag names if you want them to be subject to
successful checkout on Windows.

> I have searched for tag examples for a commit but havent seen any

Re: [git-users] Will GIT allow me to do this?? show tag history and where it was pinned on to which branch in the past

[Dale R. Worley]

Andrew Acevedo  writes:
> I'm not familiar with git, but can the same tag be moved around on several 
> branches and a history is kept which position on the branch it's been 
> pinned too before?

I might be wrong, but I think the behavior (at least, the default
behavior) is to log the past values of a tag into the corresponding file
in .git/logs/tags.  But it's possible that sufficiently old values
recorded in the log file are eventually removed.

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] Is Git for me?

[Max Hodges]

Yes having a version tracking system set up can serve as a recovery tool in
the event of data loss, but other backup strategies have more to offer. Git
as backup is likely to demand ever growing space requirements as it lacks
pruning and rotation schedules. Also it depends on the user to actively
push everything out for backup which is all backwards. A backup system
typically pulls all the files, so If you neglect to add it to tracking,
commit and push, you put data at risk.

Other issues with using git for backup is that it does not preserve most
filesystem metadata. Specifically, git does not record:

   - file groups
   - file owners
   - file permissions (other than is this executable)
   - extended attributes

Although their might be workarounds to that, and I suppose Git as backup is
better than no backup at all.

On Mon, Oct 8, 2012 at 8:47 AM, Charles Manning cdhmann...@gmail.comwrote:

 I think git is great for backup. Here's why:

 With svn etc there is a central server. If that fails, then you are
 screwed.

 With git, all the clones have exactly the same data, including history
 etc. There is no master except by convention. If the master server
 dies, then just repopulate it from a client and you have everything
 restored.

 I use git all the time even if the code does not leave one machine. It
 allows me to track changes and experiment and easily give my clients
 patches.



 On Sun, Oct 7, 2012 at 5:38 PM, Max Hodges m...@whiterabbitpress.com
 wrote:
  Git is for version tracking--most often for code, but it could also be
 used
  to track any files. Its not a backup tool and its not a deployment tool.
  Tracking changes to your source code is a very useful function. Sometimes
  during development you realize you're taken a wrong turn, and a tool like
  Git allows you to backtrack very easily. Also sometimes you may comment
 out
  a lot of lines while you're refactoring some code. With Git you no longer
  need to comment them out. Just delete them, because you can always
 compare
  your new code with an older version. So this makes your code a bit more
  clean.
 
  I'd recommend Git any software development project. Source code version
  tracking is as fundamental as testing. Its the professional way to
 develop.
 
  If you don't care about the benefits of source code tracking, and are
 only
  looking for a backup solution, then there are more simple ways to
  implementing a backup, including a simply copy command to an external
 hard
  drive or USB thumb drive.
 
  As far as setting up your code for tracking, its extremely easy. You can
 use
  a GUI to manage things--I use the SmartGit GUI, but the command-line
  tutorials like this one are still very useful to get familiar with the
  concepts and capabilities:
  http://gitimmersion.com/
 
  airborne IR cameras huh? for spotting the tell-tale footprints of grow
 light
  marijuana production by chance?
 
  Cheers!
 
  --
  You received this message because you are subscribed to the Google Groups
  Git for human beings group.
  To post to this group, send email to git-users@googlegroups.com.
  To unsubscribe from this group, send email to
  git-users+unsubscr...@googlegroups.com.
  For more options, visit this group at
  http://groups.google.com/group/git-users?hl=en.

 --
 You received this message because you are subscribed to the Google Groups
 Git for human beings group.
 To post to this group, send email to git-users@googlegroups.com.
 To unsubscribe from this group, send email to
 git-users+unsubscr...@googlegroups.com.
 For more options, visit this group at
 http://groups.google.com/group/git-users?hl=en.



-- 
You received this message because you are subscribed to the Google Groups Git 
for human beings group.
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
git-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/git-users?hl=en.

Re: [git-users] Is Git for me?

[Charles Manning]

I think git is great for backup. Here's why:

With svn etc there is a central server. If that fails, then you are screwed.

With git, all the clones have exactly the same data, including history
etc. There is no master except by convention. If the master server
dies, then just repopulate it from a client and you have everything
restored.

I use git all the time even if the code does not leave one machine. It
allows me to track changes and experiment and easily give my clients
patches.



On Sun, Oct 7, 2012 at 5:38 PM, Max Hodges m...@whiterabbitpress.com wrote:
 Git is for version tracking--most often for code, but it could also be used
 to track any files. Its not a backup tool and its not a deployment tool.
 Tracking changes to your source code is a very useful function. Sometimes
 during development you realize you're taken a wrong turn, and a tool like
 Git allows you to backtrack very easily. Also sometimes you may comment out
 a lot of lines while you're refactoring some code. With Git you no longer
 need to comment them out. Just delete them, because you can always compare
 your new code with an older version. So this makes your code a bit more
 clean.

 I'd recommend Git any software development project. Source code version
 tracking is as fundamental as testing. Its the professional way to develop.

 If you don't care about the benefits of source code tracking, and are only
 looking for a backup solution, then there are more simple ways to
 implementing a backup, including a simply copy command to an external hard
 drive or USB thumb drive.

 As far as setting up your code for tracking, its extremely easy. You can use
 a GUI to manage things--I use the SmartGit GUI, but the command-line
 tutorials like this one are still very useful to get familiar with the
 concepts and capabilities:
 http://gitimmersion.com/

 airborne IR cameras huh? for spotting the tell-tale footprints of grow light
 marijuana production by chance?

 Cheers!

 --
 You received this message because you are subscribed to the Google Groups
 Git for human beings group.
 To post to this group, send email to git-users@googlegroups.com.
 To unsubscribe from this group, send email to
 git-users+unsubscr...@googlegroups.com.
 For more options, visit this group at
 http://groups.google.com/group/git-users?hl=en.

-- 
You received this message because you are subscribed to the Google Groups Git 
for human beings group.
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
git-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/git-users?hl=en.